From ae5a304a77cb9dbc48e614c9d55a77b0658c3184 Mon Sep 17 00:00:00 2001 From: jrakibi Date: Fri, 26 Sep 2025 15:14:21 +0100 Subject: [PATCH 1/5] update xml files --- .github/workflows/xmls_gen_cron_job.yml | 40 +- src/gpt_utils.py | 9 +- src/xml_utils.py | 277 ++++++++++++-- xml_threading_updater.py | 489 ++++++++++++++++++++++++ xmls_generator_production.py | 62 ++- 5 files changed, 848 insertions(+), 29 deletions(-) create mode 100644 xml_threading_updater.py diff --git a/.github/workflows/xmls_gen_cron_job.yml b/.github/workflows/xmls_gen_cron_job.yml index e1dc3e5791..452d1f4265 100644 --- a/.github/workflows/xmls_gen_cron_job.yml +++ b/.github/workflows/xmls_gen_cron_job.yml @@ -3,6 +3,22 @@ on: schedule: - cron: "0 1 * * *" # every day at 01:00 AM UTC workflow_dispatch: + inputs: + from_year: + description: 'Start year for processing range (e.g., 2020). If not specified, uses default 90 days.' + required: false + default: '' + type: string + to_year: + description: 'End year for processing range (e.g., 2024). If not specified, processes only from_year.' + required: false + default: '' + type: string + update_threading_only: + description: 'Only update threading structure without generating new files' + required: false + default: false + type: boolean repository_dispatch: permissions: @@ -18,6 +34,9 @@ jobs: ES_USERNAME: ${{ secrets.ES_USERNAME }} ES_PASSWORD: ${{ secrets.ES_PASSWORD }} ES_INDEX: ${{ secrets.ES_INDEX }} + FROM_YEAR: ${{ github.event.inputs.from_year }} + TO_YEAR: ${{ github.event.inputs.to_year }} + UPDATE_THREADING_ONLY: ${{ github.event.inputs.update_threading_only }} steps: - uses: actions/checkout@v2 @@ -49,6 +68,25 @@ jobs: if git diff --staged --quiet; then echo "No changes to commit" else - git commit -m "Updated newly generated xml files" + if [ "${{ github.event.inputs.update_threading_only }}" = "true" ]; then + COMMIT_MSG="Updated XML files with threading structure (threading update only)" + if [ -n "${{ github.event.inputs.from_year }}" ]; then + if [ -n "${{ github.event.inputs.to_year }}" ]; then + COMMIT_MSG="$COMMIT_MSG for years ${{ github.event.inputs.from_year }}-${{ github.event.inputs.to_year }}" + else + COMMIT_MSG="$COMMIT_MSG for year ${{ github.event.inputs.from_year }}" + fi + fi + git commit -m "$COMMIT_MSG" + elif [ -n "${{ github.event.inputs.from_year }}" ]; then + if [ -n "${{ github.event.inputs.to_year }}" ]; then + COMMIT_MSG="Updated XML files for years ${{ github.event.inputs.from_year }}-${{ github.event.inputs.to_year }} with threading structure" + else + COMMIT_MSG="Updated XML files for year ${{ github.event.inputs.from_year }} with threading structure" + fi + git commit -m "$COMMIT_MSG" + else + git commit -m "Updated newly generated XML files with threading structure" + fi git push fi diff --git a/src/gpt_utils.py b/src/gpt_utils.py index 7ec3ed2005..ae96f7d9db 100644 --- a/src/gpt_utils.py +++ b/src/gpt_utils.py @@ -275,8 +275,13 @@ def gpt_api(body, custom_prompt=None): def create_summary(body, custom_prompt=None): - summ = gpt_api(body, custom_prompt) - return summ + # TEMPORARILY DISABLED: AI calls commented out for threading testing + # summ = gpt_api(body, custom_prompt) + # return summ + + # Return placeholder summary for threading tests (no AI tokens used) + logger.info("🧪 AI DISABLED: Using placeholder summary for threading testing") + return f"[THREADING TEST] Placeholder summary for testing. Original body length: {len(body) if body else 0} characters. No AI tokens used." def generate_chatgpt_summary_for_prompt(summarization_prompt, max_tokens): diff --git a/src/xml_utils.py b/src/xml_utils.py index a26e661812..5f81711f9e 100644 --- a/src/xml_utils.py +++ b/src/xml_utils.py @@ -82,8 +82,49 @@ def read_xml_file(self, full_path): published = root.findall(".//atom:entry/atom:published", namespaces)[0].text # published = add_utc_if_not_present(published) indexed_at = ((datetime.now(timezone.utc)).replace(microsecond=0)).isoformat() + # Handle both old format (flat authors) and new format (threaded structure) authors = root.findall('atom:author/atom:name', namespaces) - author_list = [author.text for author in authors] + author_list = [] + + if authors: + # Old format: flat author list + author_list = [author.text for author in authors] + logger.info(f"📄 XML READER: Found {len(author_list)} authors in flat format") + else: + # New format: check for threaded structure + thread_elem = root.find('atom:thread', namespaces) + if thread_elem is not None: + # Extract authors from threaded structure + messages = thread_elem.findall('.//message') + author_list = [] + + def extract_authors_from_messages(parent_elem, depth=0): + for message in parent_elem.findall('./message'): + author_elem = message.find('author') + if author_elem is not None and author_elem.text: + # Format with threading info for display + reply_to = message.get('reply_to', '') + timestamp_elem = message.find('timestamp') + timestamp = timestamp_elem.text if timestamp_elem is not None else '' + + if depth > 0 and reply_to: + indent = " " * depth + author_display = f"{indent}↳ {author_elem.text} {timestamp} (replying to {reply_to})" + else: + author_display = f"{author_elem.text} {timestamp}" + + author_list.append(author_display) + + # Recursively process replies + replies_elem = message.find('replies') + if replies_elem is not None: + extract_authors_from_messages(replies_elem, depth + 1) + + extract_authors_from_messages(thread_elem) + logger.info(f"📄 XML READER: Found {len(author_list)} authors in threaded format") + else: + logger.warning("📄 XML READER: No authors found in either format") + author_list = [] link = root.findall(".//atom:entry/atom:link", namespaces)[0].get('href') if "bitcoin-dev" in link: @@ -139,6 +180,117 @@ def generate_xml(self, feed_data, xml_file): with open(xml_file, 'wb') as f: f.write(feed_xml) + def generate_threaded_xml(self, feed_data, xml_file, thread_data=None): + """Generate XML with threading information preserved using nested structure""" + + logger.info(f"🧵 XML THREADING: Starting threaded XML generation for {xml_file}") + logger.info(f"📊 XML THREADING: Thread data provided: {'Yes' if thread_data else 'No'}") + + # Create the base XML structure manually for better control + from xml.dom import minidom + + # Create root feed element + feed = ET.Element('feed', xmlns='http://www.w3.org/2005/Atom') + + # Add basic feed metadata + ET.SubElement(feed, 'id').text = str(feed_data['id']) + ET.SubElement(feed, 'title').text = feed_data['title'] + ET.SubElement(feed, 'updated').text = datetime.now(timezone.utc).isoformat() + + # Add generator info + generator = ET.SubElement(feed, 'generator', uri='https://lkiesow.github.io/python-feedgen', version='0.9.0') + generator.text = 'python-feedgen' + + if thread_data: + logger.info(f"📋 XML THREADING: Processing {len(thread_data)} threaded items") + + # Create thread structure + thread_element = ET.SubElement(feed, 'thread') + + # Build thread hierarchy + self._build_threaded_structure(thread_element, thread_data) + + logger.success(f"✅ XML THREADING: Built nested thread structure with {len(thread_data)} messages") + else: + logger.warning("⚠️ XML THREADING: No thread data, using flat author structure") + # Fallback to flat author list + for author in feed_data['authors']: + author_elem = ET.SubElement(feed, 'author') + ET.SubElement(author_elem, 'name').text = author + + # Add links + for link in feed_data['links']: + ET.SubElement(feed, 'link', href=link, rel='alternate') + + # Add main entry with summary + entry = ET.SubElement(feed, 'entry') + ET.SubElement(entry, 'id').text = str(feed_data['id']) + ET.SubElement(entry, 'title').text = feed_data['title'] + ET.SubElement(entry, 'updated').text = datetime.now(timezone.utc).isoformat() + ET.SubElement(entry, 'link', href=feed_data['url'], rel='alternate') + ET.SubElement(entry, 'published').text = feed_data['created_at'] + ET.SubElement(entry, 'summary').text = feed_data['summary'] + + # Pretty print and save XML + rough_string = ET.tostring(feed, 'unicode') + reparsed = minidom.parseString(rough_string) + pretty_xml = reparsed.toprettyxml(indent=" ") + + # Remove extra blank lines + pretty_xml = '\n'.join([line for line in pretty_xml.split('\n') if line.strip()]) + + with open(xml_file, 'w', encoding='utf-8') as f: + f.write(pretty_xml) + + def _build_threaded_structure(self, parent_element, thread_data): + """ + Build nested thread structure that exactly matches mailing list display order + + This creates a FLAT chronological list of messages with proper nesting attributes + for UI threading display, exactly like the mailing list shows. + """ + + logger.info(f"🔍 XML THREADING: Building structure for {len(thread_data)} messages in mailing list order") + + # Sort by thread_position to get mailing list chronological order + sorted_data = sorted(thread_data, key=lambda x: x.get('thread_position', 0)) + + logger.info("📋 Mailing list chronological order:") + for i, item in enumerate(sorted_data): + logger.info(f" {i+1}: {item['author']} (pos={item.get('thread_position', 0)}, depth={item.get('thread_depth', 0)})") + + # Create message elements in exact mailing list order - NO DEEP NESTING + for i, thread_item in enumerate(sorted_data): + msg_id = f"msg_{i+1}" + author_name = thread_item['author'] + timestamp = thread_item.get('created_at', '') + thread_depth = thread_item.get('thread_depth', 0) + reply_to = thread_item.get('reply_to_author', '') + parent_id = thread_item.get('parent_id', '') + anchor_id = thread_item.get('anchor_id', '') + + message = ET.Element('message') + message.set('id', msg_id) + message.set('depth', str(thread_depth)) + message.set('position', str(i)) + + if reply_to: + message.set('reply_to', reply_to) + if parent_id: + message.set('parent_id', str(parent_id)) + if anchor_id: + message.set('anchor', str(anchor_id)) + + ET.SubElement(message, 'author').text = author_name + ET.SubElement(message, 'timestamp').text = timestamp + + # Add directly to parent - FLAT structure in chronological order + parent_element.append(message) + + logger.info(f" 📧 {i+1}: '{author_name}' added (depth={thread_depth})") + + logger.success(f"✅ XML THREADING: Built flat structure with {len(sorted_data)} messages in perfect mailing list order") + def append_columns(self, df_dict, file, title, namespace): """ Extract specific information from the given XML file corresponding to @@ -178,6 +330,18 @@ def append_columns(self, df_dict, file, title, namespace): author_result = author_result.replace(":", "") author_result = author_result.replace("-", "") df_dict["authors"].append([author_result.strip()]) + + # Extract the body/summary from the XML + summary = root.find('atom:entry/atom:summary', namespace).text + df_dict["body"].append(summary) + + # Add default values for threading fields (since XML files don't contain this data) + # These will be None/0 for existing XML files, as threading data only comes from ElasticSearch + df_dict["thread_depth"].append(0) # Default to root level + df_dict["thread_position"].append(0) # Default position + df_dict["parent_id"].append(None) # No parent info in XML + df_dict["reply_to_author"].append(None) # No reply info in XML + df_dict["anchor_id"].append(None) # No anchor info in XML def file_not_present_df(self, columns, source_cols, df_dict, files_list, dict_data, data, title, combined_filename, namespace): @@ -195,7 +359,16 @@ def file_not_present_df(self, columns, source_cols, df_dict, files_list, dict_da datetime_obj = add_utc_if_not_present(dict_data[data]['_source'][col], iso_format=False) df_dict[col].append(datetime_obj) else: - df_dict[col].append(dict_data[data]['_source'][col]) + # Handle threading fields that might not exist in older documents + if col in ['thread_depth', 'thread_position', 'parent_id', 'reply_to_author', 'anchor_id']: + value = dict_data[data]['_source'].get(col, None) + if col == 'thread_depth' and value is None: + value = 0 # Default depth for root messages + elif col == 'thread_position' and value is None: + value = 0 # Default position + df_dict[col].append(value) + else: + df_dict[col].append(dict_data[data]['_source'][col]) # For each individual summary (XML file) that exists for the # given thread, extract and append their content to the dictionary @@ -213,18 +386,6 @@ def file_not_present_df(self, columns, source_cols, df_dict, files_list, dict_da if title == file_title: self.append_columns(df_dict, file, title, namespace) - - if combined_filename in file: - # TODO: the code will never reach this point - # as we are already filtering per thread title so no - # "Combined summary - X" filename will pass though - tree = ET.parse(file) - root = tree.getroot() - summary = root.find('atom:entry/atom:summary', namespace).text - df_dict["body"].append(summary) - else: - summary = root.find('atom:entry/atom:summary', namespace).text - df_dict["body"].append(summary) else: logger.info(f"file not present: {file}") @@ -271,15 +432,39 @@ def file_present_df(self, files_list, namespace, combined_filename, title, indiv logger.info("individual summaries are present but not combined ones ...") for file in individual_summaries_xmls_list: self.append_columns(df_dict, file, title, namespace) - tree = ET.parse(file) - root = tree.getroot() - summary = root.find('atom:entry/atom:summary', namespace).text - df_dict["body"].append(summary) def preprocess_authors_name(self, author_tuple): author_tuple = tuple(s.replace('+', '').strip() for s in author_tuple) return author_tuple + def sort_by_thread_display_order(self, df): + """ + Sort messages by proper mailing list display order (thread hierarchy) + to match the exact structure shown in mailing list archives. + + This uses chronological order as the primary sort within each thread level + to ensure the display matches the mailing list threading exactly. + """ + if len(df) <= 1: + return df + + logger.info(f"🔄 THREADING SORT: Sorting {len(df)} messages by mailing list display order") + + # Sort by creation time first - this gives us the base chronological order + # that mailing lists use for their threading display + df_sorted = df.sort_values('created_at', ascending=True).reset_index(drop=True) + + logger.success(f"✅ THREADING SORT: Successfully sorted {len(df_sorted)} messages by chronological order") + + # Log the sorted order for debugging + for i, row in df_sorted.iterrows(): + author_name = row['authors'][0] if row['authors'] else 'Unknown' + reply_to = row.get('reply_to_author', 'None') + created = str(row['created_at'])[:16] if 'created_at' in row else 'Unknown' + logger.info(f" 📧 {i}: {created} '{author_name}' -> '{reply_to}'") + + return df_sorted + def get_local_xml_file_paths(self, dev_url): """ Retrieve paths for all relevant local XML files based on the given domain @@ -299,7 +484,7 @@ def generate_new_emails_df(self, main_dict_data, dev_url): # Initialize a dictionary to store data for DataFrame construction, with predefined columns columns = ['_index', '_id', '_score'] source_cols = ['body_type', 'created_at', 'id', 'title', 'body', 'type', - 'url', 'authors'] + 'url', 'authors', 'thread_depth', 'thread_position', 'parent_id', 'reply_to_author', 'anchor_id'] df_dict = {col: [] for col in (columns + source_cols)} seen_titles = set() @@ -407,7 +592,8 @@ def generate_local_xml(cols, combine_flag, url): title_df['authors'] = title_df['authors'].apply(convert_to_tuple) title_df = title_df.drop_duplicates() title_df['authors'] = title_df['authors'].apply(self.preprocess_authors_name) - title_df = title_df.sort_values(by='created_at', ascending=False) + # Sort by proper thread display order instead of chronological order + title_df = self.sort_by_thread_display_order(title_df) logger.info(f"Number of docs for title: {title}: {len(title_df)}") # Handle threads with single and multiple documents differently @@ -443,6 +629,46 @@ def generate_local_xml(cols, combine_flag, url): # - the individual summaries of previous posts # - the actual content of newer posts combined_summary = create_summary(combined_body) + + # Prepare threading data if available + thread_data = [] + logger.info(f"🧵 SUMMARIZER THREADING: Checking for threading data in {len(title_df)} documents") + logger.info(f"📋 SUMMARIZER THREADING: Available columns: {list(title_df.columns)}") + + if 'thread_depth' in title_df.columns: + logger.success("✅ SUMMARIZER THREADING: Threading columns found! Processing...") + # Process rows in the order they appear in the sorted DataFrame + # This preserves the proper thread display order from sort_by_thread_display_order + for display_position, (idx, row) in enumerate(title_df.iterrows()): + # Extract anchor ID from the document ID (Elasticsearch format) + anchor_id = '' + if row.get('id'): + # ES document ID format: mailing-list-2025-07-m376871ab5341f27343e4e85b66d86ca373a5b857 + doc_id = str(row['id']) + if 'm' in doc_id and len(doc_id) > 20: + # Extract the hash part after the last 'm' + parts = doc_id.split('-m') + if len(parts) > 1: + anchor_id = 'm' + parts[-1] + logger.info(f" 🔗 ANCHOR EXTRACTION: doc_id='{doc_id}' -> anchor_id='{anchor_id}'") + + thread_item = { + 'author': row['authors'][0] if row['authors'] else 'Unknown', + 'created_at': str(row['created_at']), + 'thread_depth': row.get('thread_depth', 0), + 'thread_position': display_position, # Use display position, not original position + 'original_position': row.get('thread_position', 0), # Keep original for reference + 'reply_to_author': row.get('reply_to_author', ''), + 'parent_id': row.get('parent_id', ''), + 'anchor_id': anchor_id + } + thread_data.append(thread_item) + logger.info(f" 📧 SUMMARIZER THREADING: #{display_position}: '{thread_item['author']}' depth={thread_item['thread_depth']} -> '{thread_item['reply_to_author']}' anchor='{anchor_id}' (orig_pos: {thread_item['original_position']})") + + logger.success(f"✅ SUMMARIZER THREADING: Collected {len(thread_data)} items with threading data in proper display order") + else: + logger.warning("⚠️ SUMMARIZER THREADING: No 'thread_depth' column found - documents may not have threading data") + feed_data = { 'id': "2", 'title': 'Combined summary - ' + title, @@ -455,10 +681,17 @@ def generate_local_xml(cols, combine_flag, url): # We use a flag to check if the XML file for the # combined summary is generated for the first time if not flag: - # Generate XML only once for the first month-year and keep its path - self.generate_xml(feed_data, file_path) + # Generate XML with threading information if available + if thread_data: + logger.success(f"🎯 SUMMARIZER THREADING: Using THREADED XML generation for {file_path}") + logger.info(f"📊 SUMMARIZER THREADING: Will process {len(thread_data)} threaded items") + self.generate_threaded_xml(feed_data, file_path, thread_data) + else: + logger.warning(f"⚠️ SUMMARIZER THREADING: Using FLAT XML generation (no threading data) for {file_path}") + self.generate_xml(feed_data, file_path) std_file_path = file_path flag = True + logger.success(f"✅ SUMMARIZER THREADING: XML file generated successfully: {file_path}") else: # For subsequent month-year groups, copy the initially # created XML file instead of creating a new one diff --git a/xml_threading_updater.py b/xml_threading_updater.py new file mode 100644 index 0000000000..f362b9ce08 --- /dev/null +++ b/xml_threading_updater.py @@ -0,0 +1,489 @@ +import os +import time +from datetime import datetime +import sys +import xml.etree.ElementTree as ET +from xml.dom import minidom +from loguru import logger +import warnings + +from src.config import ES_INDEX +from src.elasticsearch_utils import ElasticSearchClient +from src.xml_utils import GenerateXML + +warnings.filterwarnings("ignore") + + +class XMLThreadingUpdater: + def __init__(self): + self.elastic_search = ElasticSearchClient() + self.gen = GenerateXML() + + def has_threading_structure(self, xml_file_path): + """Check if XML file already has threading structure""" + try: + tree = ET.parse(xml_file_path) + root = tree.getroot() + return root.find('.//{http://www.w3.org/2005/Atom}thread') is not None + except Exception as e: + logger.error(f"Error checking threading structure in {xml_file_path}: {e}") + return False + + def recover_authors_from_individual_files(self, links): + """Recover author information from individual XML files""" + authors = [] + namespaces = {'atom': 'http://www.w3.org/2005/Atom'} + + for link in links: + # Skip external links + if link.startswith('http'): + continue + + try: + # Convert relative link to file path + if link.startswith('bitcoin-dev/'): + file_path = f"static/{link}" + else: + file_path = link + + if os.path.exists(file_path): + tree = ET.parse(file_path) + root = tree.getroot() + + author_elem = root.find('.//atom:author/atom:name', namespaces) + published_elem = root.find('.//atom:entry/atom:published', namespaces) + + if author_elem is not None and published_elem is not None: + # Combine author and date like original format + author_with_date = f"{author_elem.text} {published_elem.text}" + authors.append(author_with_date) + + except Exception as e: + logger.warning(f"Could not read individual file {link}: {e}") + continue + + # Sort by date (chronological order) + try: + authors.sort(key=lambda x: x.split()[-1]) + except: + pass # If sorting fails, keep original order + + logger.info(f"🔧 AUTHOR RECOVERY: Recovered {len(authors)} authors from individual files") + return authors + + def extract_existing_summary_and_metadata(self, xml_file_path): + """Extract existing summary and metadata from XML file""" + try: + namespaces = {'atom': 'http://www.w3.org/2005/Atom'} + tree = ET.parse(xml_file_path) + root = tree.getroot() + + # Extract existing data + title_elem = root.find('.//atom:entry/atom:title', namespaces) + title = title_elem.text if title_elem is not None else None + + summary_elem = root.find('.//atom:entry/atom:summary', namespaces) + summary = summary_elem.text if summary_elem is not None else None + + url_elem = root.find('.//atom:entry/atom:link', namespaces) + url = url_elem.get('href') if url_elem is not None else None + + published_elem = root.find('.//atom:entry/atom:published', namespaces) + published = published_elem.text if published_elem is not None else None + + # Extract links to individual XML files + links = [] + link_elements = root.findall('.//atom:link[@rel="alternate"]', namespaces) + for link_elem in link_elements: + href = link_elem.get('href') + if href: + links.append(href) + + # Extract existing authors (IMPORTANT: preserve original authors) + authors = [] + author_elements = root.findall('.//atom:author/atom:name', namespaces) + for author_elem in author_elements: + if author_elem.text: + authors.append(author_elem.text) + + # If no authors found, try to recover from individual files + if not authors and links: + logger.warning("🔧 No authors found in combined file, attempting recovery from individual files...") + authors = self.recover_authors_from_individual_files(links) + + return { + 'title': title, + 'summary': summary, + 'url': url, + 'published': published, + 'links': links, + 'authors': authors + } + except Exception as e: + logger.error(f"Error extracting data from {xml_file_path}: {e}") + return None + + def get_threading_data_for_title(self, title, dev_url, max_retries=3): + """Fetch threading data from Elasticsearch with retry logic and proper error handling""" + for attempt in range(max_retries): + try: + # Add delay between attempts to let ES recover + if attempt > 0: + delay = 5 * attempt # Increasing delay: 5s, 10s, 15s + logger.warning(f"🔄 RETRY {attempt}/{max_retries}: Waiting {delay}s before retry for '{title}'") + time.sleep(delay) + + title_dict_data = self.elastic_search.fetch_data_based_on_title( + es_index=ES_INDEX, title=title, url=dev_url + ) + + if not title_dict_data: + logger.warning(f"No data found in ES for title: {title}") + return [] + + thread_data = [] + logger.info(f"🔍 THREADING UPDATER: Found {len(title_dict_data)} documents for title: {title}") + + # Sort by creation time to get proper chronological order + title_dict_data.sort(key=lambda x: x['_source']['created_at']) + + for display_position, doc in enumerate(title_dict_data): + source = doc['_source'] + + # Extract anchor ID from document ID + anchor_id = '' + if source.get('id'): + doc_id = str(source['id']) + if 'm' in doc_id and len(doc_id) > 20: + parts = doc_id.split('-m') + if len(parts) > 1: + anchor_id = 'm' + parts[-1] + + thread_item = { + 'author': source.get('authors', ['Unknown'])[0] if source.get('authors') else 'Unknown', + 'created_at': source.get('created_at', ''), + 'thread_depth': source.get('thread_depth', 0), + 'thread_position': display_position, + 'reply_to_author': source.get('reply_to_author', ''), + 'parent_id': source.get('parent_id', ''), + 'anchor_id': anchor_id + } + thread_data.append(thread_item) + + logger.info(f" 📧 THREADING UPDATER: #{display_position}: '{thread_item['author']}' depth={thread_item['thread_depth']} -> '{thread_item['reply_to_author']}' anchor='{anchor_id}'") + + return thread_data + + except Exception as e: + error_msg = str(e) + if "scroll" in error_msg.lower() or "500" in error_msg: + logger.error(f"❌ ES SCROLL ERROR (attempt {attempt+1}/{max_retries}) for title '{title}': {e}") + if attempt == max_retries - 1: + logger.error(f"❌ MAX RETRIES REACHED for title '{title}' - returning empty thread data") + return [] + else: + logger.error(f"❌ ES ERROR for title '{title}': {e}") + return [] + + return [] + + def update_xml_with_threading(self, xml_file_path, thread_data, existing_data): + """Update XML file with threading structure while preserving existing summary""" + try: + logger.info(f"🔄 THREADING UPDATER: Updating {xml_file_path} with threading structure") + + # Create new XML structure with threading + feed = ET.Element('feed', xmlns='http://www.w3.org/2005/Atom') + + # Add basic feed metadata + ET.SubElement(feed, 'id').text = "2" + ET.SubElement(feed, 'title').text = existing_data['title'] + ET.SubElement(feed, 'updated').text = datetime.now().isoformat() + '+00:00' + + # Add generator info + generator = ET.SubElement(feed, 'generator', uri='https://lkiesow.github.io/python-feedgen', version='0.9.0') + generator.text = 'python-feedgen' + + # Add threading structure if we have thread data + if thread_data: + logger.info(f"📋 THREADING UPDATER: Adding threading structure with {len(thread_data)} messages") + thread_element = ET.SubElement(feed, 'thread') + self.gen._build_threaded_structure(thread_element, thread_data) + else: + logger.warning("⚠️ THREADING UPDATER: No thread data available, keeping flat structure") + # PRESERVE ORIGINAL AUTHORS when no threading data + if existing_data.get('authors'): + logger.info(f"📋 THREADING UPDATER: Preserving {len(existing_data['authors'])} original authors") + for author_text in existing_data['authors']: + author_elem = ET.SubElement(feed, 'author') + ET.SubElement(author_elem, 'name').text = author_text + + # Add links to individual XML files + for link in existing_data['links']: + ET.SubElement(feed, 'link', href=link, rel='alternate') + + # Add main entry with existing summary (PRESERVE EXISTING SUMMARY) + entry = ET.SubElement(feed, 'entry') + ET.SubElement(entry, 'id').text = "2" + ET.SubElement(entry, 'title').text = existing_data['title'] + ET.SubElement(entry, 'updated').text = datetime.now().isoformat() + '+00:00' + ET.SubElement(entry, 'link', href=existing_data['url'], rel='alternate') + ET.SubElement(entry, 'published').text = existing_data['published'] + ET.SubElement(entry, 'summary').text = existing_data['summary'] # KEEP EXISTING SUMMARY + + # Pretty print and save XML + rough_string = ET.tostring(feed, 'unicode') + reparsed = minidom.parseString(rough_string) + pretty_xml = reparsed.toprettyxml(indent=" ") + + # Remove extra blank lines + pretty_xml = '\n'.join([line for line in pretty_xml.split('\n') if line.strip()]) + + # Write updated XML file + with open(xml_file_path, 'w', encoding='utf-8') as f: + f.write(pretty_xml) + + logger.success(f"✅ THREADING UPDATER: Successfully updated {xml_file_path} with threading structure") + return True + + except Exception as e: + logger.error(f"❌ THREADING UPDATER: Error updating {xml_file_path}: {e}") + return False + + def find_combined_xml_files(self, base_directory="static/bitcoin-dev"): + """Find all combined XML files that need threading updates""" + combined_files = [] + + for root, _, files in os.walk(base_directory): + for file in files: + if file.startswith('combined_') and file.endswith('.xml'): + file_path = os.path.join(root, file) + combined_files.append(file_path) + + logger.info(f"📁 THREADING UPDATER: Found {len(combined_files)} combined XML files") + return combined_files + + def extract_title_from_filename(self, xml_file_path): + """Extract the original title from combined XML filename""" + try: + # Get filename without path and extension + filename = os.path.basename(xml_file_path) + + # Try to extract title from existing XML first + existing_data = self.extract_existing_summary_and_metadata(xml_file_path) + if existing_data and existing_data['title']: + # Remove "Combined summary - " prefix to get original title + original_title = existing_data['title'].replace('Combined summary - ', '') + return original_title + + logger.warning(f"Could not extract title from {xml_file_path}") + return None + + except Exception as e: + logger.error(f"Error extracting title from {xml_file_path}: {e}") + return None + + def parse_date_from_path(self, xml_file_path): + """Extract year and month from XML file path""" + try: + path_parts = xml_file_path.split('/') + for part in path_parts: + if '_' in part and part.split('_')[-1].isdigit(): + month_name, year_str = part.split('_') + year = int(year_str) + + # Convert month name to number + month_map = { + 'Jan': 1, 'Feb': 2, 'March': 3, 'April': 4, 'May': 5, 'June': 6, + 'July': 7, 'Aug': 8, 'Sept': 9, 'Oct': 10, 'Nov': 11, 'Dec': 12 + } + month = month_map.get(month_name, 0) + return year, month + return None, None + except Exception as e: + logger.error(f"Error parsing date from path {xml_file_path}: {e}") + return None, None + + def should_process_file(self, xml_file_path, from_year=None, to_year=None, start_year=None, start_month=None, months_limit=None): + """Determine if file should be processed based on date filters""" + # Support both new (from_year/to_year) and old (start_year/start_month/months_limit) parameters for backward compatibility + if from_year or to_year: + # Use new year range logic + if not from_year and not to_year: + return True + + file_year, file_month = self.parse_date_from_path(xml_file_path) + if not file_year or not file_month: + return True # Process if we can't parse date + + # Check if file is within the year range + if from_year and file_year < from_year: + return False + if to_year and file_year > to_year: + return False + + return True + else: + # Use old logic for backward compatibility + if not start_year: + return True + + file_year, file_month = self.parse_date_from_path(xml_file_path) + if not file_year or not file_month: + return True # Process if we can't parse date + + # Check if file is before start date + if file_year < start_year: + return False + if file_year == start_year and start_month and file_month < start_month: + return False + + # Check if file is within months limit + if months_limit: + start_date = datetime(start_year, start_month or 1, 1) + file_date = datetime(file_year, file_month, 1) + months_diff = (file_date.year - start_date.year) * 12 + (file_date.month - start_date.month) + if months_diff >= months_limit: + return False + + return True + + def get_threading_data_for_title_multi_domain(self, title): + """Try to fetch threading data from multiple bitcoin-dev domains""" + dev_urls = [ + "https://mailing-list.bitcoindevs.xyz/bitcoindev/", # Primary + "https://gnusha.org/pi/bitcoindev/" # Fallback + ] + + for dev_url in dev_urls: + logger.info(f"🔍 Trying domain: {dev_url}") + thread_data = self.get_threading_data_for_title(title, dev_url) + if thread_data: + logger.success(f"✅ Found threading data in domain: {dev_url}") + return thread_data + + logger.warning(f"❌ No threading data found in any domain for: {title}") + return [] + + def update_all_threading(self, from_year=None, to_year=None, start_year=None, start_month=None, months_limit=None): + """Update all combined XML files with threading structure""" + + logger.info("🚀 THREADING UPDATER: Starting threading update for bitcoin-dev") + + # Log the date range being processed + if from_year or to_year: + if from_year and to_year: + date_info = f"for years {from_year}-{to_year}" + elif from_year: + date_info = f"for year {from_year}" + elif to_year: + date_info = f"up to year {to_year}" + logger.info(f"📅 THREADING UPDATER: Processing {date_info}") + elif start_year: + date_info = f"from {start_year}" + if start_month: + date_info += f"/{start_month:02d}" + if months_limit: + date_info += f" (limit: {months_limit} months)" + logger.info(f"📅 THREADING UPDATER: Processing {date_info}") + + # Find all combined XML files + combined_files = self.find_combined_xml_files() + + # Filter files by date criteria + files_to_process = [] + for xml_file_path in combined_files: + if self.should_process_file(xml_file_path, from_year, to_year, start_year, start_month, months_limit): + files_to_process.append(xml_file_path) + else: + file_year, file_month = self.parse_date_from_path(xml_file_path) + logger.info(f"⏭️ THREADING UPDATER: Skipping {xml_file_path} ({file_year}/{file_month:02d} outside range)") + + logger.info(f"📋 THREADING UPDATER: Will process {len(files_to_process)} files (skipped {len(combined_files) - len(files_to_process)})") + + combined_files = files_to_process + + updated_count = 0 + skipped_count = 0 + error_count = 0 + + for i, xml_file_path in enumerate(combined_files): + try: + logger.info(f"📁 PROGRESS: Processing file {i+1}/{len(combined_files)}: {xml_file_path}") + + # Files are already filtered, no need to skip here + + # Check if already has threading + if self.has_threading_structure(xml_file_path): + logger.info(f"✅ THREADING UPDATER: {xml_file_path} already has threading structure") + skipped_count += 1 + continue + + logger.info(f"🔄 THREADING UPDATER: Processing {xml_file_path}") + + # Extract existing data + existing_data = self.extract_existing_summary_and_metadata(xml_file_path) + if not existing_data: + logger.error(f"❌ THREADING UPDATER: Could not extract data from {xml_file_path}") + error_count += 1 + continue + + # Extract title + title = self.extract_title_from_filename(xml_file_path) + if not title: + logger.error(f"❌ THREADING UPDATER: Could not extract title from {xml_file_path}") + error_count += 1 + continue + + # Get threading data from Elasticsearch with multi-domain retry logic + thread_data = self.get_threading_data_for_title_multi_domain(title) + + # Update XML with threading + if self.update_xml_with_threading(xml_file_path, thread_data, existing_data): + updated_count += 1 + else: + error_count += 1 + + # Longer delay between ES queries to avoid scroll context exhaustion + if i < len(combined_files) - 1: # Don't sleep after last file + logger.info("⏸️ Waiting 2 seconds to avoid ES overload...") + time.sleep(2) + + # Progress report every 10 files + if (i + 1) % 10 == 0: + logger.info(f"📊 PROGRESS: {i+1}/{len(combined_files)} files processed. Updated: {updated_count}, Skipped: {skipped_count}, Errors: {error_count}") + + except Exception as e: + logger.error(f"❌ THREADING UPDATER: Error processing {xml_file_path}: {e}") + error_count += 1 + + logger.success(f"🎉 THREADING UPDATER: Completed! Updated: {updated_count}, Skipped: {skipped_count}, Errors: {error_count}") + + +if __name__ == "__main__": + # Get parameters from environment or command line + from_year = os.environ.get('FROM_YEAR') + to_year = os.environ.get('TO_YEAR') + # Support old environment variables for backward compatibility + start_year = os.environ.get('START_YEAR') + update_threading_only = os.environ.get('UPDATE_THREADING_ONLY', 'false').lower() == 'true' + + # Convert to integers + try: + from_year = int(from_year) if from_year else None + to_year = int(to_year) if to_year else None + start_year = int(start_year) if start_year else None + except ValueError as e: + logger.error(f"Invalid parameter format: {e}") + sys.exit(1) + + if len(sys.argv) > 1: + start_year = sys.argv[1] if sys.argv[1] else None + + updater = XMLThreadingUpdater() + + if update_threading_only or from_year or to_year or start_year: + logger.info("🧵 THREADING UPDATER: Running in threading update mode") + updater.update_all_threading(from_year=from_year, to_year=to_year, start_year=start_year) + else: + logger.info("ℹ️ THREADING UPDATER: No threading update requested") diff --git a/xmls_generator_production.py b/xmls_generator_production.py index ceacf1cf57..74fa16deef 100644 --- a/xmls_generator_production.py +++ b/xmls_generator_production.py @@ -1,4 +1,5 @@ import time +import os from datetime import datetime, timedelta import sys from loguru import logger @@ -7,25 +8,69 @@ from src.config import ES_INDEX from src.elasticsearch_utils import ElasticSearchClient from src.xml_utils import GenerateXML +from xml_threading_updater import XMLThreadingUpdater warnings.filterwarnings("ignore") if __name__ == "__main__": + # Get parameters from environment variables + from_year = os.environ.get('FROM_YEAR') + to_year = os.environ.get('TO_YEAR') + update_threading_only = os.environ.get('UPDATE_THREADING_ONLY', 'false').lower() == 'true' + + # Convert to integers + try: + from_year = int(from_year) if from_year else None + to_year = int(to_year) if to_year else None + except ValueError as e: + logger.error(f"Invalid parameter format: {e}") + sys.exit(1) + + logger.info(f"🚀 XML GENERATOR: Starting with FROM_YEAR={from_year}, TO_YEAR={to_year}, UPDATE_THREADING_ONLY={update_threading_only}") + + # If only updating threading, run the threading updater and exit + if update_threading_only: + logger.info("🧵 XML GENERATOR: Running in threading update mode only") + updater = XMLThreadingUpdater() + updater.update_all_threading(from_year=from_year, to_year=to_year) + logger.info("✅ XML GENERATOR: Threading update completed") + sys.exit(0) + gen = GenerateXML() elastic_search = ElasticSearchClient() + + # Only process bitcoin-dev, skip delvingbitcoin as requested dev_urls = [ - "https://delvingbitcoin.org/", "https://gnusha.org/pi/bitcoindev/", "https://mailing-list.bitcoindevs.xyz/bitcoindev/" ] + + logger.info("📋 XML GENERATOR: Processing only bitcoin-dev domains (skipping delvingbitcoin)") + # Calculate date range end_date = datetime.now() - start_date = end_date - timedelta(days=30) + + if from_year: + # Use specified year range + start_date = datetime(from_year, 1, 1) + if to_year: + # Use end of to_year as end date + end_date = datetime(to_year, 12, 31, 23, 59, 59) + logger.info(f"📅 XML GENERATOR: Processing year range {from_year}-{to_year}") + else: + # Process only from_year + end_date = datetime(from_year, 12, 31, 23, 59, 59) + logger.info(f"📅 XML GENERATOR: Processing single year {from_year}") + logger.info(f"📅 XML GENERATOR: Date range: {start_date.strftime('%Y-%m-%d')} to {end_date.strftime('%Y-%m-%d')}") + else: + # Use default 90 days + start_date = end_date - timedelta(days=90) + logger.info("📅 XML GENERATOR: Using default 90 days range") # yyyy-mm-dd end_date_str = end_date.strftime("%Y-%m-%d") start_date_str = start_date.strftime("%Y-%m-%d") - logger.info(f"start_data: {start_date_str}") + logger.info(f"start_date: {start_date_str}") logger.info(f"end_date_str: {end_date_str}") for dev_url in dev_urls: @@ -50,4 +95,13 @@ if count_main > 5: sys.exit(ex) - logger.info("Process Complete.") + # After processing, update threading for all XMLs (including newly created ones) + logger.info("🧵 XML GENERATOR: Starting threading update for all XMLs...") + try: + updater = XMLThreadingUpdater() + updater.update_all_threading(from_year=from_year, to_year=to_year) + logger.success("✅ XML GENERATOR: Threading update completed successfully") + except Exception as e: + logger.error(f"❌ XML GENERATOR: Error during threading update: {e}") + + logger.info("🎉 Process Complete.") From b8e61cbe56cbb5434b551c8955e72ff43b1d8deb Mon Sep 17 00:00:00 2001 From: urvishp80 Date: Fri, 26 Sep 2025 14:42:10 +0000 Subject: [PATCH 2/5] Updated XML files with threading structure (threading update only) for years 2022-2025 --- .../combined_-Pre-BIP-Fee-Accounts.xml | 281 ++++--- ...ed_7-Theses-on-a-next-step-for-BIP-119.xml | 92 ++- .../combined_A-Calculus-of-Covenants.xml | 36 +- .../combined_ANYPREVOUT-in-place-of-CTV.xml | 197 +++-- ...ting-transitory-soft-forks-e-g-for-CTV.xml | 17 +- ...ct-tweak-fields-for-PSBT-bip-psbt-p2c-.xml | 36 +- .../combined_BIP174-PSBT-test-vector.xml | 36 +- .../combined_CTV-Signet-Parameters.xml | 127 ++-- ...in-payment-pools-and-channel-factories.xml | 64 +- .../April_2022/combined_MuSig2-BIP.xml | 120 +-- ..._Multiple-ways-to-do-bitcoin-covenants.xml | 29 +- .../combined_Simple-step-one-for-quantum.xml | 57 +- .../April_2022/combined_Speedy-Trial.xml | 386 ++++++---- ...A-Taproot-Asset-Representation-Overlay.xml | 141 ++-- ...-measuring-user-support-for-Soft-Forks.xml | 148 ++-- ...mbined_User-Resisted-Soft-Fork-for-CTV.xml | 141 ++-- ...cally-reverting-transitory-soft-forks-.xml | 17 +- ...us-soft-fork-activations-are-attempted.xml | 13 +- ...d_What-to-expect-in-the-next-few-weeks.xml | 106 +-- ...ntation-integrated-with-Core-Lightning.xml | 92 ++- ...s-and-communication-on-merge-decisions.xml | 211 ++--- ...Bitcoin-fungibility-and-inscribed-sats.xml | 13 +- ...-Peer-to-Peer-Electronic-Market-System.xml | 43 +- ...in-payment-pools-and-channel-factories.xml | 64 +- .../combined_Merkleize-All-The-Things.xml | 155 ++-- ...ined_On-adaptor-security-in-protocols-.xml | 71 +- ...al-to-Remove-BIP35-P2P-mempool-Message.xml | 36 +- .../combined_RGB-protocol-announcement.xml | 64 +- ...t-ACKs-for-transaction-terminology-BIP.xml | 57 +- ...ed_TARO-Protocol-metadata-BIP-proposal.xml | 29 +- .../combined_Vaults-in-the-MATT-framework.xml | 43 +- ...nable-ZKP-based-spending-authorization.xml | 71 +- .../combined_Adding-New-BIP-Editors.xml | 719 ++++++++++-------- .../combined_BIP-for-OP-CHECKSIGFROMSTACK.xml | 40 +- .../combined_BIP-for-OP-INTERNALKEY.xml | 38 +- .../combined_Bitcoin-Core-26-1-released.xml | 37 +- ...ined-Transaction-Flags-Policy-Strategy.xml | 56 +- ...mbined_Great-Consensus-Cleanup-Revival.xml | 249 +++--- ...ons-of-using-pseudorandom-JSON-RPC-IDs.xml | 38 +- ...-Lamport-Signatures-no-changes-needed-.xml | 189 ++--- ...-signing-legacy-inputs-in-transactions.xml | 37 +- ...combined_The-Future-of-Bitcoin-Testnet.xml | 311 ++++---- .../combined_Updated-BIP-for-OP-CAT.xml | 46 +- ...nceptual-discussion-for-policy-changes.xml | 34 +- ...fine-Bitcoin-Subunits-as-Satoshis-Sats.xml | 39 +- ...Based-Interactive-Aggregate-Signatures.xml | 112 +-- ...bined_Does-anyone-still-need-testnet3-.xml | 67 +- .../combined_Introducing-Hourglass.xml | 88 ++- ...g-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml | 98 +-- ...Quantum-Signatures-and-Scaling-Bitcoin.xml | 76 +- ...nerability-affecting-Bitcoin-Core-29-0.xml | 31 +- ...t-Allowing-Quantum-Recovery-of-Bitcoin.xml | 173 ++++- ...asabi-Samourai-deanonymization-attacks.xml | 146 ++-- ...ax-OP-RETURN-standardness-restrictions.xml | 507 ++++++------ ...moving-checkpoints-in-Bitcoin-Core-v30.xml | 39 +- .../combined_Standard-Unstructured-Annex.xml | 68 +- ...ync-smarter-synchronization-with-hints.xml | 136 ++-- ...combined_The-Future-of-Bitcoin-Testnet.xml | 311 ++++---- .../combined_The-Tragic-Tale-of-BIP30.xml | 112 +-- .../combined_Unbreaking-testnet4.xml | 250 +++--- ...k1lab-a-Python-library-for-prototyping.xml | 41 +- ...A-method-for-BIP322-signing-delegation.xml | 13 +- ...erivation-Paths-in-a-Single-Descriptor.xml | 13 +- ...P-Proposal-Wallet-Labels-Export-Format.xml | 13 +- .../combined_BIP-notatether-signedmessage.xml | 71 +- ...e-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml | 13 +- ...rability-in-important-Bitcoin-projects.xml | 113 +-- .../Aug_2022/combined_More-uses-for-CTV.xml | 57 +- .../combined_New-BIP-Private-Payments.xml | 36 +- .../combined_New-Silent-Payment-version.xml | 13 +- ...community-process-to-specify-covenants.xml | 13 +- ...d_P2P-trading-replacement-transactions.xml | 50 +- ...ull-rbf-peers-for-fun-and-L2s-security.xml | 204 ++--- ...s-in-Bitcoin-Core-and-the-role-of-BIPs.xml | 43 +- ...t-anti-Sybil-with-anonymity-in-Bitcoin.xml | 36 +- .../combined_Regarding-BIP322-edge-cases.xml | 13 +- ...egarding-setting-a-lower-minrelaytxfee.xml | 155 ++-- ...ngly-Tail-Emission-Is-Not-Inflationary.xml | 13 +- ...tr-coinjoin-implementation-using-nostr.xml | 13 +- .../combined_Announcing-Libforesta.xml | 50 +- ...ivacy-preserving-Second-Layer-Solution.xml | 148 ++-- ...dresses-should-have-an-expiration-time.xml | 78 +- ...ed_BIP-for-Serverless-Payjoin-AdamISZ-.xml | 13 +- .../combined_BIP-for-Serverless-Payjoin.xml | 60 +- .../combined_Blinded-2-party-Musig2.xml | 250 +++--- ...ombined-CTV-APO-to-minimal-TXHASH-CSFS.xml | 43 +- ...mbined_Compressed-Bitcoin-Transactions.xml | 131 ++-- .../combined_Concern-about-Inscriptions-.xml | 17 +- ...ncern-about-Inscriptions-ashneverdawn-.xml | 17 +- .../combined_Concrete-MATT-opcodes.xml | 99 ++- ...t-4-pools-is-mining-full-RBF-right-now.xml | 13 +- ...ivate-Collaborative-Custody-with-FROST.xml | 36 +- ...Pull-req-to-enable-Full-RBF-by-default.xml | 13 +- ...-arbitrary-limits-on-OP-Return-outputs.xml | 13 +- ...ed_Sentinel-Chains-A-Novel-Two-Way-Peg.xml | 71 +- .../Aug_2023/combined_Serverless-Payjoin.xml | 29 +- ...Introducing-Validity-Proofs-to-Bitcoin.xml | 57 +- .../combined_segwit-naming-ambiguity.xml | 50 +- ...antage-of-The-Lack-of-Full-RBF-In-Core.xml | 319 ++++---- ...ctivation-based-on-nlocktime-signaling.xml | 67 +- .../combined_BIP-Draft-FROST-Signing-.xml | 33 +- ...ng-Attacks-under-Real-World-Conditions.xml | 63 +- ...nerable-To-Replacement-Cycling-Attacks.xml | 38 +- ...g-pools-stratumv2-and-oblivious-shares.xml | 74 +- ...T-Research-Fund-sponsored-by-StarkWare.xml | 54 +- .../Aug_2024/combined_OP-ZKP-updates.xml | 55 +- ...-towards-a-quantum-resistant-soft-fork.xml | 89 ++- ...abilities-affecting-Bitcoin-Core-v22-0.xml | 38 +- .../combined_Re-HODL-Tax-Proposal.xml | 83 +- ...093-Codex32-as-application-to-BIP-0085.xml | 68 +- ...ic-Curve-Operations-for-Bitcoin-Script.xml | 38 +- ...ecure-Asset-Verification-Escrow-QSAVE-.xml | 76 +- .../combined_-BIP-Proposal-OP-TWEAKADD.xml | 53 +- .../combined_-BIP-Proposal-Utreexo-Nodes.xml | 53 +- ...stant-Transition-Framework-for-Bitcoin.xml | 83 +- ...ined_A-Post-Quantum-Migration-Proposal.xml | 192 +++-- ...t-Allowing-Quantum-Recovery-of-Bitcoin.xml | 118 +-- ...-Wallets-Covenant-Only-Taproot-Outputs.xml | 31 +- .../combined_Introducing-Hourglass.xml | 88 ++- .../combined_New-BIP-Editors-1-Year-Later.xml | 38 +- ...ignatures-i-e-P256-mobile-HSM-support-.xml | 54 +- ...-when-restricted-to-script-path-spends.xml | 40 +- ...CKTEMPLATEVERIFY-and-CHECKSIGFROMSTACK.xml | 54 +- ...o-conf-apps-in-immediate-danger-angus-.xml | 13 +- ...RBF-Zero-conf-apps-in-immediate-danger.xml | 257 +------ .../combined_A-Bitcoin-NFT-System.xml | 32 +- ...-RBF-to-not-exclude-Zero-Conf-use-case.xml | 155 ++-- ...ned_Announcement-Full-RBF-Miner-Bounty.xml | 162 ++-- ...G-2nd-Meeting-Tuesday-20-Dec-18-00-UTC.xml | 29 +- .../combined_Bitcoin-Core-24-0-1-Released.xml | 36 +- ...RBF-Zero-conf-apps-in-immediate-danger.xml | 13 +- .../combined_Merkleize-All-The-Things.xml | 155 ++-- ...ed_Pseudocode-for-robust-tail-emission.xml | 13 +- ...patibility-Within-the-Bitcoin-Protocol.xml | 50 +- ...round-adding-a-bitcoin-core-maintainer.xml | 28 +- ...ined_bitcoin-dev-Digest-Vol-91-Issue-5.xml | 13 +- ...-listening-nodes-are-running-full-rbf-.xml | 13 +- ...ut-simple-transactions-at-disadvantage.xml | 82 +- ...of-profitable-fee-manipulation-attacks.xml | 46 +- ...Partial-Replacement-Cycling-Mitigation.xml | 56 +- ...BIP-number-request-for-wallet-policies.xml | 32 +- ...ing-and-on-chain-efficiency-covenants-.xml | 54 +- ...cheme-not-signature-to-economize-on-L1.xml | 105 +-- ...mbined_Ordinal-Inscription-Size-Limits.xml | 179 +++-- ...afely-With-Feerate-Dependent-Timelocks.xml | 113 +-- .../combined_Swift-Activation-CTV.xml | 91 +-- ...ignificant-tx-pinning-griefing-attacks.xml | 60 +- ...-Bitcoin-Unit-to-the-Base-Denomination.xml | 43 +- .../combined_Adding-New-BIP-Editors.xml | 719 ++++++++++-------- ...-Distributed-Key-Generation-for-FROST-.xml | 54 +- ...vacy-in-Chaumian-ecash-implementations.xml | 39 +- ...ombined_Covenants-Support-Bitcoin-Wiki.xml | 77 +- ...ESS-and-why-it-should-be-a-real-opcode.xml | 60 +- ...-Rate-Growth-and-Difficulty-Adjustment.xml | 38 +- ...nclusion-of-Old-Transactions-in-Blocks.xml | 69 +- ...Cryptography-in-Bitcoin-BIP-Submission.xml | 39 +- ...asabi-Samourai-deanonymization-attacks.xml | 146 ++-- ...Summary-Covenants-Support-Bitcoin-Wiki.xml | 97 +-- ...ed_TRUC-and-P2A-for-CTV-fee-management.xml | 40 +- ...-QC-signatures-with-clean-upgrade-path.xml | 103 +-- ...Alternative-to-OP-TAPLEAFUPDATEVERIFY-.xml | 127 ++-- ...A-Looping-Construct-For-Bitcoin-SCRIPT.xml | 57 +- .../combined_-Pre-BIP-Fee-Accounts.xml | 281 ++++--- ...curity-In-The-Presence-Of-51-Attackers.xml | 50 +- ...-standard-UTXOs-and-also-detected-burn.xml | 69 +- ...utrino-using-minimally-trusted-oracles.xml | 36 +- ...a-for-Tuesday-February-8th-at-12-00-PT.xml | 29 +- ...-for-Tuesday-February-22nd-at-12-00-PT.xml | 29 +- .../combined_CTV-Signet-Parameters.xml | 127 ++-- ...ombined_CTV-dramatically-improves-DLCs.xml | 83 +- ...tralized-BIP-47-payment-code-directory.xml | 13 +- ...rom-the-perspective-of-a-rational-user.xml | 29 +- .../combined_Draft-BIP-Ordinal-Numbers.xml | 120 +-- .../combined_Improving-RBF-Policy.xml | 175 +++-- ...-2-projects-with-multiple-RBF-policies.xml | 50 +- .../combined_OP-RETURN-inside-TapScript.xml | 113 +-- .../Feb_2022/combined_PathCoin.xml | 64 +- ...CKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml | 13 +- ...ntentious-soft-fork-activation-attempt.xml | 13 +- ...CKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml | 328 +++++--- .../combined_Thoughts-on-fee-bumping.xml | 194 +++-- ...ECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml | 13 +- .../Feb_2022/combined_Why-CTV-why-now-.xml | 13 +- ...tic-connections-in-Bitcoin-P2P-network.xml | 29 +- ...-RBF-to-not-exclude-Zero-Conf-use-case.xml | 155 ++-- .../Feb_2023/combined_BIP-for-OP-VAULT.xml | 176 +++-- ...-proposal-Fee-redistribution-contracts.xml | 43 +- ...G-4rd-Meeting-Tuesday-21-Feb-18-00-UTC.xml | 29 +- .../bitcoin-dev/Feb_2023/combined_Codex32.xml | 120 +-- ...TURN-VS-taproot-OP-FALSE-OP-IF-OP-PUSH.xml | 250 +++--- ...ckage-RBF-againstpackage-limit-pinning.xml | 13 +- ...mbined_Ordinal-Inscription-Size-Limits.xml | 179 +++-- ...ed_Pseudocode-for-robust-tail-emission.xml | 13 +- ...mbined_Purely-off-chain-coin-colouring.xml | 24 +- ...32m-address-for-future-segwit-versions.xml | 50 +- .../Feb_2023/combined_Refreshed-BIP324.xml | 169 ++-- ...ship-resistance-of-bitcoin-p2p-network.xml | 85 ++- ...ltiparty-protocols-with-Taproot-inputs.xml | 141 ++-- .../combined_Adding-New-BIP-Editors.xml | 719 ++++++++++-------- ...Due-to-UTXO-s-Required-For-Fee-Payment.xml | 120 +-- ...ace-by-Fee-Rate-Replacements-Are-Mined.xml | 53 +- ...ailing-List-Migration-Action-Required-.xml | 27 +- ...ithdrawal-Output-Specification-for-L2s.xml | 42 +- ...tions-with-fee-rates-below-1-sat-vbyte.xml | 61 +- ...nned-work-on-BIP-3-Updated-BIP-Process.xml | 37 +- .../combined_P2QRH-BIP-360-Update.xml | 152 ++-- ...t-Address-Migration-Protocol-QRAMP-BIP.xml | 138 ++-- ...asabi-Samourai-deanonymization-attacks.xml | 146 ++-- ...ed_Transaction-Validation-Optimization.xml | 38 +- ...t-transaction-in-a-group-not-the-first.xml | 38 +- ...on-the-Great-Consensus-Cleanup-Revival.xml | 128 ++-- ...ralized-Coordination-Free-Mining-Pools.xml | 162 ++-- .../combined_-Pre-BIP-Fee-Accounts.xml | 281 ++++--- ...dlc-dev-CTV-dramatically-improves-DLCs.xml | 13 +- ...ct-tweak-fields-for-PSBT-bip-psbt-p2c-.xml | 36 +- .../combined_Bitcoin-Legal-Defense-Fund.xml | 127 ++-- .../Jan_2022/combined_CTV-BIP-review.xml | 13 +- ...ombined_CTV-dramatically-improves-DLCs.xml | 83 +- ...nts-and-capabilities-in-the-UTXO-model.xml | 67 +- ...rom-the-perspective-of-a-rational-user.xml | 29 +- .../combined_Improving-RBF-Policy.xml | 175 +++-- ..._Nuke-notify-options-from-Bitcoin-Core.xml | 36 +- .../combined_OP-PUSH-KEY-BIP-118-0x01-Pun.xml | 29 +- ...mbined_On-the-regularity-of-soft-forks.xml | 90 +-- .../Jan_2022/combined_PathCoin.xml | 64 +- .../Jan_2022/combined_Renaming-full-nodes.xml | 29 +- ...ntentious-soft-fork-activation-attempt.xml | 13 +- ...CKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml | 328 +++++--- ...ombined_Take-2-Removing-the-Dust-Limit.xml | 67 +- .../bitcoin-dev/Jan_2022/combined_bip39.xml | 43 +- ...tic-connections-in-Bitcoin-P2P-network.xml | 29 +- .../combined_A-Bitcoin-NFT-System.xml | 32 +- ...ed-on-bitcoin-and-a-Bitcoin-NFT-system.xml | 29 +- ...ntation-integrated-with-Core-Lightning.xml | 92 ++- ...-RBF-to-not-exclude-Zero-Conf-use-case.xml | 155 ++-- ...G-3rd-Meeting-Tuesday-17-Jan-18-00-UTC.xml | 29 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 13 +- ...combined_OP-VAULT-a-new-vault-proposal.xml | 127 ++-- ...mbined_Ordinal-Inscription-Size-Limits.xml | 179 +++-- ...ed_Pseudocode-for-robust-tail-emission.xml | 13 +- ...32m-address-for-future-segwit-versions.xml | 50 +- .../Jan_2023/combined_Refreshed-BIP324.xml | 169 ++-- ...round-adding-a-bitcoin-core-maintainer.xml | 28 +- ...ned_SIGHASH-GROUP-vs-Ephemeral-anchors.xml | 29 +- .../Jan_2023/combined_Serverless-Payjoin.xml | 29 +- ...ombined_Using-OP-VAULT-to-improve-DLCs.xml | 29 +- ...Wallet-policies-for-descriptor-wallets.xml | 78 +- ...ned-transactions-but-no-ephemeral-keys.xml | 39 +- ...Protocols-Significantly-More-Expensive.xml | 92 ++- ...ut-simple-transactions-at-disadvantage.xml | 82 +- ...BIP-number-request-for-wallet-policies.xml | 32 +- .../combined_BIP-process-friction.xml | 98 +-- ...Due-to-UTXO-s-Required-For-Fee-Payment.xml | 115 +-- ...mbined_Compressed-Bitcoin-Transactions.xml | 131 ++-- ...Future-of-the-bitcoin-dev-mailing-list.xml | 28 +- ...ersion-field-to-BIP39-mnemonic-phrases.xml | 55 +- ...cheme-not-signature-to-economize-on-L1.xml | 105 +-- ...ivation-descriptor-and-PSBT-field-BIPs.xml | 38 +- .../combined_One-Shot-Replace-By-Fee-Rate.xml | 77 +- ...mbined_Ordinal-Inscription-Size-Limits.xml | 179 +++-- .../combined_Swift-Activation-CTV.xml | 91 +-- ...ignificant-tx-pinning-griefing-attacks.xml | 60 +- ...acks-on-Bitcoin-Miners-Block-Templates.xml | 42 +- ...tions-with-fee-rates-below-1-sat-vbyte.xml | 61 +- ...nclusion-of-Old-Transactions-in-Blocks.xml | 69 +- ...asabi-Samourai-deanonymization-attacks.xml | 146 ++-- ...Summary-Covenants-Support-Bitcoin-Wiki.xml | 97 +-- ...t-transaction-in-a-group-not-the-first.xml | 38 +- ...-QC-signatures-with-clean-upgrade-path.xml | 103 +-- .../combined_UTXO-checkpoint-transactions.xml | 15 +- ...ho-uses-or-wants-to-use-PSBTv2-BIP370-.xml | 61 +- ...ombined_-BIP-proposal-Private-Payments.xml | 99 ++- .../combined_Adding-SIGHASH-to-TXID.xml | 36 +- ...d_BGP-hijacking-on-Bitcoin-p2p-network.xml | 36 +- ...erivation-Paths-in-a-Single-Descriptor.xml | 13 +- ...Half-Aggregation-of-BIP-340-Signatures.xml | 43 +- ...bined_Bitcoin-covenants-are-inevitable.xml | 400 +++++----- ...f-Service-in-STONEWALLx2-p2p-coinjoin-.xml | 29 +- ...ombined_How-to-do-Proof-of-Micro-Burn-.xml | 64 +- .../combined_New-BIP-Private-Payments.xml | 36 +- .../July_2022/combined_No-Order-Mnemonic.xml | 113 +-- ...community-process-to-specify-covenants.xml | 13 +- ...ull-rbf-peers-for-fun-and-L2s-security.xml | 204 ++--- ...egarding-setting-a-lower-minrelaytxfee.xml | 155 ++-- ...lying-on-transaction-fees-for-security.xml | 260 ++++--- ...ngly-Tail-Emission-Is-Not-Inflationary.xml | 13 +- ..._TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml | 134 ++-- ...s-in-message-signing-verification-BIP-.xml | 64 +- ...ith-address-signing-without-compromise.xml | 43 +- .../combined_Announcing-Libforesta.xml | 50 +- .../combined_Blinded-2-party-Musig2.xml | 250 +++--- .../combined_Concern-about-Inscriptions-.xml | 47 +- ...ncern-about-Inscriptions-ashneverdawn-.xml | 17 +- .../combined_Concrete-MATT-opcodes.xml | 99 ++- ..._Denial-of-Service-using-Package-Relay.xml | 29 +- ...g-this-community-process-up-for-grabs-.xml | 61 +- ...Pull-req-to-enable-Full-RBF-by-default.xml | 13 +- ...ation-of-an-unstructured-taproot-annex.xml | 225 +++--- ...antage-of-The-Lack-of-Full-RBF-In-Core.xml | 319 ++++---- ...-Distributed-Key-Generation-for-FROST-.xml | 54 +- .../combined_BIP-Draft-FROST-Signing-.xml | 33 +- ...itcoin-Core-Security-Disclosure-Policy.xml | 46 +- ...mbined_Great-Consensus-Cleanup-Revival.xml | 249 +++--- ...terministic-Wallets-with-Token-support.xml | 42 +- ...g-pools-stratumv2-and-oblivious-shares.xml | 74 +- .../July_2024/combined_OP-ZKP-updates.xml | 55 +- ...-towards-a-quantum-resistant-soft-fork.xml | 89 ++- ...bilities-affecting-Bitcoin-Core-0-21-0.xml | 37 +- ...abilities-affecting-Bitcoin-Core-v22-0.xml | 38 +- ...-39-Mnemonics-with-Multisig-Extensions.xml | 32 +- ...al-Proof-of-Activity-Reclamation-PoAR-.xml | 78 +- .../combined_-BIP-Proposal-Utreexo-Nodes.xml | 53 +- ...ined_A-Post-Quantum-Migration-Proposal.xml | 192 +++-- ...e-bindable-transaction-bundle-proposal.xml | 145 ++-- ...t-Allowing-Quantum-Recovery-of-Bitcoin.xml | 118 +-- ...Based-Interactive-Aggregate-Signatures.xml | 112 +-- ...ed_Human-meaningful-witness-versioning.xml | 86 ++- ...gacy-signature-operations-non-standard.xml | 75 +- .../combined_New-BIP-Editors-1-Year-Later.xml | 38 +- ...d_OP-CAT-Enables-Winternitz-Signatures.xml | 75 +- ...ast-Log-for-Enhanced-User-Transparency.xml | 31 +- ...tralized-Satellite-Based-Bitcoin-Nodes.xml | 31 +- ...ignatures-i-e-P256-mobile-HSM-support-.xml | 54 +- ...-when-restricted-to-script-path-spends.xml | 40 +- .../combined_Unbreaking-testnet4.xml | 250 +++--- ...r-the-capabilities-enabled-by-CTV-CSFS.xml | 118 +-- ...ombined_-BIP-proposal-Private-Payments.xml | 99 ++- ...ants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml | 50 +- ...d_BGP-hijacking-on-Bitcoin-p2p-network.xml | 36 +- .../combined_BIP47-Prague-Discussion.xml | 29 +- ...bined_Bitcoin-covenants-are-inevitable.xml | 400 +++++----- .../June_2022/combined_MuSig2-BIP.xml | 120 +-- .../combined_Package-Relay-Proposal.xml | 162 ++-- .../combined_Packaged-Transaction-Relay.xml | 13 +- ...ull-rbf-peers-for-fun-and-L2s-security.xml | 204 ++--- ...t-anti-Sybil-with-anonymity-in-Bitcoin.xml | 36 +- ...ero-supply-chain-instead-of-sidechains.xml | 29 +- ...ps-does-not-linearize-its-transactions.xml | 17 +- ...ined_bitcoin-dev-Digest-Vol-85-Issue-4.xml | 13 +- ...ivacy-preserving-Second-Layer-Solution.xml | 148 ++-- ...st-needs-an-explicit-moderation-policy.xml | 43 +- ...-Peer-to-Peer-Electronic-Market-System.xml | 43 +- ...ormosa-proposed-improvement-upon-BIP39.xml | 43 +- ...s-nVersion-3-for-contracting-protocols.xml | 106 +-- ...at-layer-1-with-client-side-validation.xml | 13 +- ...ation-of-an-unstructured-taproot-annex.xml | 225 +++--- .../combined_Vaults-in-the-MATT-framework.xml | 43 +- ...Introducing-Validity-Proofs-to-Bitcoin.xml | 57 +- ...combined_postr-p2n-payjoin-using-nostr.xml | 13 +- ...ined_AOPP-2-0-using-OP-CAT-and-OP-CSFS.xml | 34 +- ...-Champion-Unreachable-Please-weigh-in-.xml | 30 +- ...mbined_Great-Consensus-Cleanup-Revival.xml | 249 +++--- ...with-lower-1-25x-replacement-threshold.xml | 38 +- .../combined_Network-partition-recovery.xml | 40 +- .../combined_OP-Expire-mempool-behavior.xml | 48 +- ...-towards-a-quantum-resistant-soft-fork.xml | 89 ++- ...t-Allowing-Quantum-Recovery-of-Bitcoin.xml | 118 +-- ...cate-Keys-in-BIP-390-musig-Expressions.xml | 39 +- ...ension-for-Manual-Seed-Phrase-Creation.xml | 16 +- .../June_2025/combined_CTV-CSFS-a-letter.xml | 464 ++++++----- ...tion-Relay-Taking-out-the-garbage-man-.xml | 131 ++-- ...Based-Interactive-Aggregate-Signatures.xml | 112 +-- ...P-Well-Known-Bitcoin-Identity-Endpoint.xml | 47 +- ...o-Santa-Claus-under-the-Lightning-Sun-.xml | 44 +- ...keys-are-actually-fully-quantum-secure.xml | 120 +-- ...d_OP-CAT-Enables-Winternitz-Signatures.xml | 75 +- ...veal-Fawkescoin-variant-as-a-soft-fork.xml | 105 +-- ...or-quantum-safe-migration-poison-pill-.xml | 141 ++-- ...ast-Log-for-Enhanced-User-Transparency.xml | 31 +- ...ar-configurable-data-blob-relay-policy.xml | 75 +- ...-in-different-coinjoin-implementations.xml | 45 +- ..._The-case-for-privatizing-Bitcoin-Core.xml | 102 +-- ...r-the-capabilities-enabled-by-CTV-CSFS.xml | 118 +-- ...various-post-quantum-signature-schemes.xml | 56 +- ...A-Looping-Construct-For-Bitcoin-SCRIPT.xml | 57 +- ...-Completeness-and-other-considerations.xml | 78 +- .../combined_BIP-Draft-Submission.xml | 29 +- ...sensus-Critical-Jets-Without-Softforks.xml | 71 +- ...g-5-Agenda-Tuesday-March-7th-12-00-PT-.xml | 50 +- ...ombined_CTV-dramatically-improves-DLCs.xml | 83 +- .../combined_CTV-vaults-in-the-wild.xml | 57 +- .../combined_Covenants-and-feebumping.xml | 50 +- ...tralized-BIP-47-payment-code-directory.xml | 13 +- .../combined_Improving-RBF-Policy.xml | 175 +++-- ...-Looping-Construct-For-Bitcoin-SCRIPT-.xml | 57 +- ...Meeting-Summary-Logs-for-CTV-Meeting-5.xml | 43 +- .../combined_OP-RETURN-inside-TapScript.xml | 113 +-- .../combined_One-testnet-to-rule-them-all.xml | 43 +- ...curring-bitcoin-LN-payments-using-DLCs.xml | 71 +- ...CKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml | 13 +- .../combined_Removing-the-Dust-Limit.xml | 266 ++++--- ...ate-payments-with-no-on-chain-overhead.xml | 78 +- .../March_2022/combined_Speedy-Trial.xml | 386 ++++++---- ...ined_Wasabi-Wallet-2-0-Testnet-Release.xml | 43 +- .../combined_bitcoin-scripting-and-lisp.xml | 176 +++-- ...empool-transaction-witness-replacement.xml | 29 +- .../March_2023/combined_BIP-for-OP-VAULT.xml | 176 +++-- ...-proposal-Fee-redistribution-contracts.xml | 43 +- ...Bitcoin-fungibility-and-inscribed-sats.xml | 13 +- ...in-payment-pools-and-channel-factories.xml | 64 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 13 +- .../March_2023/combined_Minimum-fees.xml | 13 +- ...treexo-signaling-in-testnet-and-signet.xml | 36 +- ...ty-Increase-with-a-Small-Quantum-Miner.xml | 31 +- ...ree-Relay-Attack-Exploiting-RBF-Rule-6.xml | 173 +++-- .../combined_Adding-New-BIP-Editors.xml | 719 ++++++++++-------- ...fficient-alternative-to-anchor-outputs.xml | 55 +- ...mbined_Great-Consensus-Cleanup-Revival.xml | 249 +++--- .../combined_OP-Expire-mempool-behavior.xml | 48 +- ...ree-Relay-Attack-Exploiting-RBF-Rule-6.xml | 17 +- ...combined_The-Future-of-Bitcoin-Testnet.xml | 311 ++++---- ..._-Recursive-covenant-with-CTV-and-CSFS.xml | 164 ++-- ...t-Allowing-Quantum-Recovery-of-Bitcoin.xml | 118 +-- .../combined_Consensus-Cleanup-BIP-draft.xml | 132 ++-- ...bined_Does-anyone-still-need-testnet3-.xml | 67 +- ...nned-work-on-BIP-3-Updated-BIP-Process.xml | 37 +- ...keys-are-actually-fully-quantum-secure.xml | 120 +-- ...g-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml | 98 +-- .../combined_P2QRH-BIP-360-Update.xml | 152 ++-- ...g-Dust-UTXOs-as-Miner-Transaction-Fees.xml | 64 +- ...t-Address-Migration-Protocol-QRAMP-BIP.xml | 138 ++-- ...t-Allowing-Quantum-Recovery-of-Bitcoin.xml | 173 ++++- .../combined_Slashing-covenants.xml | 38 +- .../combined_Standard-Unstructured-Annex.xml | 68 +- ...c-nodes-Covenants-Support-Bitcoin-Wiki.xml | 31 +- ...combined_The-Future-of-Bitcoin-Testnet.xml | 311 ++++---- .../combined_Time-to-add-CSFS-to-Signet-.xml | 85 ++- ...ined_UTXO-probing-attack-using-payjoin.xml | 81 +- .../combined_Unbreaking-testnet4.xml | 250 +++--- ...on-the-Great-Consensus-Cleanup-Revival.xml | 128 ++-- ...ants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml | 50 +- .../combined_-Pre-BIP-Fee-Accounts.xml | 281 ++++--- .../combined_A-Calculus-of-Covenants.xml | 36 +- .../combined_ANYPREVOUT-in-place-of-CTV.xml | 197 +++-- .../combined_Adding-SIGHASH-to-TXID.xml | 36 +- ...-address-fidelity-bond-for-BIP39-seeds.xml | 169 ++-- ...tion-introspection-to-stop-RBF-pinning.xml | 36 +- .../combined_CTV-BIP-Meeting-8-Notes.xml | 78 +- .../combined_CTV-BIP-Meeting-9-Notes.xml | 50 +- ...in-payment-pools-and-channel-factories.xml | 64 +- ...d_Improving-BIP-8-soft-fork-activation.xml | 64 +- ...echains-with-fidelity-bond-federations.xml | 29 +- .../May_2022/combined_MuSig2-BIP.xml | 120 +-- ..._Multiple-ways-to-do-bitcoin-covenants.xml | 29 +- .../combined_Package-Relay-Proposal.xml | 162 ++-- ...d_Password-protected-wallet-on-Taproot.xml | 29 +- ...ed_Pay-to-signature-hash-as-a-covenant.xml | 36 +- ...ate-payments-with-no-on-chain-overhead.xml | 78 +- .../combined_Speedy-covenants-OP-CAT2-.xml | 148 ++-- ...-measuring-user-support-for-Soft-Forks.xml | 148 ++-- ...Wallet-policies-for-descriptor-wallets.xml | 78 +- ...us-soft-fork-activations-are-attempted.xml | 13 +- .../combined_Working-Towards-Consensus.xml | 50 +- ...-Taproot-transactions-from-full-nodes-.xml | 13 +- ...ntation-integrated-with-Core-Lightning.xml | 92 ++- ...scheme-for-a-non-custodial-mining-pool.xml | 29 +- ...ivacy-preserving-Second-Layer-Solution.xml | 148 ++-- .../combined_Bitcoin-Core-24-1-released.xml | 33 +- ...s-and-communication-on-merge-decisions.xml | 211 ++--- ...d_Bitcoin-Transaction-Relay-over-Nostr.xml | 57 +- ...-Peer-to-Peer-Electronic-Market-System.xml | 43 +- ...with-less-steps-using-ALL-ANYONECANPAY.xml | 50 +- ...ormosa-proposed-improvement-upon-BIP39.xml | 43 +- .../combined_Merkleize-All-The-Things.xml | 155 ++-- ...ined_On-adaptor-security-in-protocols-.xml | 71 +- .../combined_Package-Relay-Proposal.xml | 162 ++-- ...al-to-Remove-BIP35-P2P-mempool-Message.xml | 36 +- ...le-disclosures-and-Bitcoin-development.xml | 64 +- ...t-ACKs-for-transaction-terminology-BIP.xml | 57 +- .../combined_Vaults-in-the-MATT-framework.xml | 43 +- ...pt-validation-to-reject-arbitrary-data.xml | 57 +- ...Introducing-Validity-Proofs-to-Bitcoin.xml | 57 +- ...nable-ZKP-based-spending-authorization.xml | 71 +- .../May_2023/combined_tx-max-fee.xml | 13 +- ...bined_A-Fool-s-Errand-or-should-I-try-.xml | 60 +- .../combined_Adding-New-BIP-Editors.xml | 719 ++++++++++-------- ...ycling-Attacks-Risks-on-L2s-beyond-LN-.xml | 40 +- .../May_2024/combined_BIP-21-Updates.xml | 32 +- .../May_2024/combined_BIP-322-use-case.xml | 55 +- .../combined_BIP-for-OP-CHECKSIGFROMSTACK.xml | 40 +- .../May_2024/combined_BIP-for-Testnet-4.xml | 40 +- ...mbined_Great-Consensus-Cleanup-Revival.xml | 249 +++--- ...s-the-average-size-of-blk-data-chosen-.xml | 31 +- ...or-secret-splitting-BIP39-seed-phrases.xml | 97 +-- ...-Lamport-Signatures-no-changes-needed-.xml | 189 ++--- ...-signing-legacy-inputs-in-transactions.xml | 37 +- ...combined_The-Future-of-Bitcoin-Testnet.xml | 311 ++++---- .../combined_bitcoin-bounty-program.xml | 31 +- ..._-Proposal-64-bit-arithmetic-in-Script.xml | 60 +- ...t-Allowing-Quantum-Recovery-of-Bitcoin.xml | 118 +-- ...fine-Bitcoin-Subunits-as-Satoshis-Sats.xml | 39 +- ...ension-for-Manual-Seed-Phrase-Creation.xml | 16 +- ...tion-Relay-Taking-out-the-garbage-man-.xml | 131 ++-- ...P-Well-Known-Bitcoin-Identity-Endpoint.xml | 47 +- ...keys-are-actually-fully-quantum-secure.xml | 120 +-- .../combined_Introducing-Hourglass.xml | 88 ++- ...veal-Fawkescoin-variant-as-a-soft-fork.xml | 105 +-- ...ar-configurable-data-blob-relay-policy.xml | 75 +- ...nerability-affecting-Bitcoin-Core-29-0.xml | 31 +- ...ension-for-Manual-Seed-Phrase-Creation.xml | 63 +- ...RBF-Zero-conf-apps-in-immediate-danger.xml | 352 ++++++++- ...ax-OP-RETURN-standardness-restrictions.xml | 507 ++++++------ ...moving-checkpoints-in-Bitcoin-Core-v30.xml | 39 +- ...ync-smarter-synchronization-with-hints.xml | 136 ++-- ...-in-different-coinjoin-implementations.xml | 45 +- .../combined_The-Tragic-Tale-of-BIP30.xml | 112 +-- .../May_2025/combined_Unbreaking-testnet4.xml | 250 +++--- ...various-post-quantum-signature-schemes.xml | 56 +- ...RBF-Zero-conf-apps-in-immediate-danger.xml | 257 +------ ...ned_Announcement-Full-RBF-Miner-Bounty.xml | 162 ++-- ...G-1st-Meeting-Tuesday-15-Nov-18-00-UTC.xml | 50 +- ...tions-Per-Second-with-stronger-privacy.xml | 302 ++++---- ...ned_Custom-signet-for-testing-full-RBF.xml | 36 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 13 +- .../combined_Merkleize-All-The-Things.xml | 155 ++-- .../Nov_2022/combined_MuSig2-BIP.xml | 120 +-- ...combined_On-mempool-policy-consistency.xml | 13 +- .../combined_Package-Relay-Proposal.xml | 162 ++-- ...etecting-pinning-of-jointly-funded-txs.xml | 43 +- .../Nov_2022/combined_Refreshed-BIP324.xml | 169 ++-- ...eized-Sum-Tree-and-explicit-miner-fee-.xml | 36 +- ...-with-the-Always-Replaceable-Invariant.xml | 52 +- ...t-in-Full-RBF-Spent-nVersion-Signaling.xml | 57 +- ...A-Taproot-Asset-Representation-Overlay.xml | 141 ++-- ...-BIP-125-Rule-3-Pinning-with-nLockTime.xml | 13 +- .../combined_Validity-Rollups-on-Bitcoin.xml | 64 +- ...Wallet-policies-for-descriptor-wallets.xml | 78 +- .../Nov_2022/combined_brickchain.xml | 99 ++- ...-Taproot-transactions-from-full-nodes-.xml | 13 +- ...osal-for-a-PSBT-for-descriptors-format.xml | 35 +- ...234-All-your-mempool-are-belong-to-us-.xml | 484 ++++++------ ...Future-of-the-bitcoin-dev-mailing-list.xml | 28 +- ...ing-and-on-chain-efficiency-covenants-.xml | 54 +- ...-by-Letting-Transactions-Expire-Safely.xml | 21 +- ...mpool-issues-for-bitcoin-second-layers.xml | 34 +- .../Nov_2023/combined_Ordinals-BIP-PR.xml | 173 +++-- ...ed_Proposed-BIP-for-MuSig2-Descriptors.xml | 32 +- ...mbined_Purely-off-chain-coin-colouring.xml | 24 +- ...caling-Lightning-With-Simple-Covenants.xml | 127 ++-- ...ed_The-Pinning-Replacement-Problem-Set.xml | 54 +- ...ersonalized-mnemonic-generation-scheme.xml | 31 +- ...ed_bitcoin-dev-Digest-Vol-102-Issue-15.xml | 16 +- ...tion-and-misaligned-incentive-concerns.xml | 18 +- .../Nov_2024/combined_BIP-21-Updates.xml | 32 +- .../combined_Bitcoin-Core-on-ARM-Windows-.xml | 30 +- ...s-to-the-previous-mailing-list-archive.xml | 38 +- ...combined_CHECKSIGFROMSTACK-VERIFY-ADD-.xml | 54 +- ...in-Bitcoin-via-160-bit-hash-collisions.xml | 56 +- ...ombined_Covenants-Support-Bitcoin-Wiki.xml | 77 +- ...mbined_Great-Consensus-Cleanup-Revival.xml | 249 +++--- .../Nov_2024/combined_Multi-byte-opcodes.xml | 60 +- ...-Lamport-Signatures-no-changes-needed-.xml | 189 ++--- .../Nov_2024/combined_Slashing-covenants.xml | 38 +- ...d-Covenants-via-BitVM-Integrity-Checks.xml | 37 +- ...RBF-Zero-conf-apps-in-immediate-danger.xml | 257 +------ ...nalysis-of-full-RBF-deployment-methods.xml | 43 +- ...HECKMULTISIG-using-an-extra-hint-field.xml | 29 +- ...est-majority-or-a-rational-one-re-rbf-.xml | 141 ++-- ...or-a-rational-one-re-rbf-Jeremy-Rubin-.xml | 13 +- ...kage-RBF-against-package-limit-pinning.xml | 112 ++- ...ckage-RBF-againstpackage-limit-pinning.xml | 13 +- ...144-lack-of-tx-witness-data-size-limit.xml | 29 +- .../Oct_2022/combined_MuSig2-BIP.xml | 120 +-- ...s-nVersion-3-for-contracting-protocols.xml | 106 +-- ...community-process-to-specify-covenants.xml | 13 +- ...combined_On-mempool-policy-consistency.xml | 13 +- .../combined_Packaged-Transaction-Relay.xml | 13 +- ...32-recurrent-address-derivation-scheme.xml | 36 +- .../Oct_2022/combined_Refreshed-BIP324.xml | 169 ++-- ...ss-transaction-size-policy-restriction.xml | 57 +- ...ent-Payment-v4-coinjoin-support-added-.xml | 43 +- ...A-Taproot-Asset-Representation-Overlay.xml | 141 ++-- ...rsion-of-Silent-Payment-implementation.xml | 36 +- ...out-addresses-to-prevent-address-reuse.xml | 71 +- ...rver-Outsourcing-handing-out-addresses.xml | 13 +- .../combined_Validity-Rollups-on-Bitcoin.xml | 64 +- ...istion-evaluating-soft-forks-on-signet.xml | 120 +-- .../Oct_2022/combined_brickchain.xml | 99 ++- ...2-Multiparticipant-Offchain-Mechanisms.xml | 74 +- ...drawal-to-lightning-requires-covenants.xml | 119 ++- ...ined_BitVM-Compute-Anything-on-Bitcoin.xml | 57 +- ...ge-in-calculation-of-hash-serialized-2.xml | 36 +- ...BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml | 29 +- ...mining-ScriptPubkeys-in-Bitcoin-Script.xml | 78 +- ...234-All-your-mempool-are-belong-to-us-.xml | 484 ++++++------ ...ing-and-on-chain-efficiency-covenants-.xml | 54 +- ...mistic-execution-of-arbitrary-programs.xml | 36 +- ...-by-Letting-Transactions-Expire-Safely.xml | 21 +- ...mpool-issues-for-bitcoin-second-layers.xml | 34 +- .../Oct_2023/combined_Ordinals-BIP-PR.xml | 173 +++-- ...ed_Proposed-BIP-for-MuSig2-Descriptors.xml | 32 +- ...ed_Proposed-BIP-for-MuSig2-PSBT-Fields.xml | 50 +- .../combined_Proposed-BIP-for-OP-CAT.xml | 17 +- .../Oct_2023/combined_Refreshed-BIP324.xml | 169 ++-- ...hannel-reserve-for-mobile-wallet-users.xml | 25 +- ...caling-Lightning-With-Simple-Covenants.xml | 127 ++-- ...h-cut-through-update-of-Taproot-leaves.xml | 64 +- ...n-Mainnet-Announcing-tapd-v0-3-0-alpha.xml | 29 +- .../Oct_2024/combined_BIP-DLEQ.xml | 31 +- ...ng-Attacks-under-Real-World-Conditions.xml | 63 +- .../Oct_2024/combined_OP-ZKP-updates.xml | 55 +- ...Cryptography-in-Bitcoin-BIP-Submission.xml | 39 +- ...e-packages-to-discourage-address-reuse.xml | 63 +- ...-Lamport-Signatures-no-changes-needed-.xml | 189 ++--- ...P-Proposal-Wallet-Labels-Export-Format.xml | 13 +- ...f-Service-in-STONEWALLx2-p2p-coinjoin-.xml | 29 +- .../Sept_2022/combined_More-uses-for-CTV.xml | 57 +- ...els-A-scalability-solution-for-Layer-1.xml | 29 +- ...s-nVersion-3-for-contracting-protocols.xml | 106 +-- ...community-process-to-specify-covenants.xml | 13 +- .../combined_Packaged-Transaction-Relay.xml | 13 +- ...32-recurrent-address-derivation-scheme.xml | 36 +- ...Analog-with-One-Time-Trusted-Setup-APO.xml | 36 +- ...rsion-of-Silent-Payment-implementation.xml | 36 +- ...d_Transcript-Online-Socratic-on-MuSig2.xml | 13 +- ...out-addresses-to-prevent-address-reuse.xml | 71 +- ...Wallet-policies-for-descriptor-wallets.xml | 78 +- ...istion-evaluating-soft-forks-on-signet.xml | 120 +-- ...tr-coinjoin-implementation-using-nostr.xml | 13 +- ...2-Multiparticipant-Offchain-Mechanisms.xml | 74 +- ...mbined_BIP-The-Taproot-Assets-Protocol.xml | 29 +- ...mbined_Compressed-Bitcoin-Transactions.xml | 131 ++-- .../combined_Concern-about-Inscriptions-.xml | 17 +- .../combined_Concrete-MATT-opcodes.xml | 99 ++- ...BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml | 29 +- ...mistic-execution-of-arbitrary-programs.xml | 36 +- ...riptors-xpub-derivation-and-miniscript.xml | 29 +- .../combined_Parameters-in-BIP21-URIs.xml | 36 +- ...caling-Lightning-With-Simple-Covenants.xml | 127 ++-- ...h-cut-through-update-of-Taproot-leaves.xml | 64 +- ...d_Trustless-2-way-peg-without-softfork.xml | 43 +- .../combined_Adding-New-BIP-Editors.xml | 719 ++++++++++-------- ...ng-Attacks-under-Real-World-Conditions.xml | 63 +- ...T-Research-Fund-sponsored-by-StarkWare.xml | 54 +- ..._OP-KEEPCHANGE-mitigating-dust-outputs.xml | 49 +- ...action-relay-protocol-to-a-new-version.xml | 39 +- ...-towards-a-quantum-resistant-soft-fork.xml | 89 ++- ...rability-affecting-Bitcoin-Core-24-0-1.xml | 30 +- ...e-and-Efficient-Client-Side-Validation.xml | 49 +- ...093-Codex32-as-application-to-BIP-0085.xml | 68 +- ...ic-Curve-Operations-for-Bitcoin-Script.xml | 38 +- ...elay-Policies-via-User-Defined-Scripts.xml | 157 ++-- ...ecure-Asset-Verification-Escrow-QSAVE-.xml | 76 +- .../combined_-BIP-Proposal-OP-TWEAKADD.xml | 53 +- ...ined_A-Post-Quantum-Migration-Proposal.xml | 192 +++-- ...-Wallets-Covenant-Only-Taproot-Outputs.xml | 31 +- 646 files changed, 32752 insertions(+), 25891 deletions(-) diff --git a/static/bitcoin-dev/April_2022/combined_-Pre-BIP-Fee-Accounts.xml b/static/bitcoin-dev/April_2022/combined_-Pre-BIP-Fee-Accounts.xml index 32397a76b2..b32742a9cf 100644 --- a/static/bitcoin-dev/April_2022/combined_-Pre-BIP-Fee-Accounts.xml +++ b/static/bitcoin-dev/April_2022/combined_-Pre-BIP-Fee-Accounts.xml @@ -1,98 +1,187 @@ - + 2 Combined summary - [Pre-BIP] Fee Accounts - 2023-08-02T05:17:55.394761+00:00 - - Jeremy Rubin 2022-05-02 15:59:49+00:00 - - - Peter Todd 2022-04-28 12:15:02+00:00 - - - Jeremy Rubin 2022-04-17 20:57:28+00:00 - - - Peter Todd 2022-04-15 14:52:47+00:00 - - - Jeremy Rubin 2022-04-11 13:18:10+00:00 - - - Peter Todd 2022-04-10 19:32:52+00:00 - - - Jeremy Rubin 2022-02-20 16:45:35+00:00 - - - ZmnSCPxj 2022-02-20 16:34:35+00:00 - - - Jeremy Rubin 2022-02-20 16:29:35+00:00 - - - Jeremy Rubin 2022-02-20 16:29:00+00:00 - - - ZmnSCPxj 2022-02-20 14:24:22+00:00 - - - ZmnSCPxj 2022-02-20 02:39:50+00:00 - - - ZmnSCPxj 2022-02-20 02:24:37+00:00 - - - Peter Todd 2022-02-19 20:35:20+00:00 - - - darosior 2022-02-19 17:20:19+00:00 - - - Peter Todd 2022-02-19 09:39:22+00:00 - - - Jeremy Rubin 2022-02-19 00:38:27+00:00 - - - Peter Todd 2022-02-18 23:50:07+00:00 - - - Jeremy Rubin 2022-02-10 08:08:59+00:00 - - - Peter Todd 2022-02-10 06:58:56+00:00 - - - Billy Tetrud 2022-01-20 05:23:12+00:00 - - - Jeremy 2022-01-19 20:08:23+00:00 - - - Billy Tetrud 2022-01-19 16:51:48+00:00 - - - Jeremy 2022-01-19 07:32:36+00:00 - - - Billy Tetrud 2022-01-19 04:53:21+00:00 - - - Jeremy 2022-01-19 02:51:42+00:00 - - - Billy Tetrud 2022-01-19 02:37:39+00:00 - - - Jeremy 2022-01-18 17:43:07+00:00 - - - Billy Tetrud 2022-01-18 16:12:36+00:00 - - - Jeremy 2022-01-01 20:04:00+00:00 - + 2025-09-26T14:34:09.820436+00:00 + python-feedgen + + + [bitcoin-dev] [Pre-BIP] Fee Accounts Jeremy + 2022-01-01T20:04:00.000Z + + + Billy Tetrud + 2022-01-18T16:12:00.000Z + + + Jeremy + 2022-01-18T17:43:00.000Z + + + Billy Tetrud + 2022-01-19T02:37:00.000Z + + + Jeremy + 2022-01-19T02:51:00.000Z + + + Billy Tetrud + 2022-01-19T04:53:00.000Z + + + Jeremy + 2022-01-19T07:32:00.000Z + + + Billy Tetrud + 2022-01-19T16:51:00.000Z + + + Jeremy + 2022-01-19T20:08:00.000Z + + + Billy Tetrud + 2022-01-20T05:23:00.000Z + + + Peter Todd + 2022-02-10T06:58:00.000Z + + + Jeremy Rubin + 2022-02-10T08:08:00.000Z + + + Peter Todd + 2022-02-18T23:50:00.000Z + + + Jeremy Rubin + 2022-02-19T00:38:00.000Z + + + Peter Todd + 2022-02-19T09:39:00.000Z + + + [bitcoin-dev] [Lightning-dev] " darosior + 2022-02-19T17:20:00.000Z + + + Peter Todd + 2022-02-19T20:35:00.000Z + + + ZmnSCPxj + 2022-02-20T02:24:00.000Z + + + ZmnSCPxj + 2022-02-20T02:39:00.000Z + + + ZmnSCPxj + 2022-02-20T14:24:00.000Z + + + Jeremy Rubin + 2022-02-20T16:29:00.000Z + + + [bitcoin-dev] " Jeremy Rubin + 2022-02-20T16:29:00.000Z + + + ZmnSCPxj + 2022-02-20T16:34:00.000Z + + + Jeremy Rubin + 2022-02-20T16:45:00.000Z + + + Peter Todd + 2022-04-10T19:32:00.000Z + + + Jeremy Rubin + 2022-04-11T13:18:00.000Z + + + Peter Todd + 2022-04-15T14:52:00.000Z + + + Jeremy Rubin + 2022-04-17T20:57:00.000Z + + + Peter Todd + 2022-04-28T12:15:00.000Z + + + Jeremy Rubin + 2022-05-02T15:59:00.000Z + + + [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions Peter Todd + 2022-06-14T11:12:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T11:39:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T11:53:00.000Z + + + rot13maxi + 2022-06-14T12:28:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T12:45:00.000Z + + + Bryan Bishop + 2022-06-14T13:55:00.000Z + + + digital vagabond + 2022-06-14T15:06:00.000Z + + + Peter Todd + 2022-06-14T15:22:00.000Z + + + Peter Todd + 2022-06-14T15:34:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T17:15:00.000Z + + + Andrew Poelstra + 2022-06-14T20:33:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-15T01:16:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-15T01:21:00.000Z + + + Peter Todd + 2022-06-19T11:04:00.000Z + + @@ -123,13 +212,13 @@ - python-feedgen + 2 Combined summary - [Pre-BIP] Fee Accounts - 2023-08-02T05:17:55.395761+00:00 + 2025-09-26T14:34:09.824904+00:00 - In a detailed email conversation, the participants discuss various aspects of blockchain technology, specifically focusing on Open Time Stamps (OTS). The discussion begins with a proposal for a correct timestamping service model, stating that any such service must adhere to the model to be reliable. The writer highlights the potential issues and unreliability that can arise if the model is not followed.Jeremy Rubin questions the appeal to authority in the Bitcoin-dev group and raises concerns about the formal correctness of OTS. He suggests the need for an actual specification for OTS to resolve these issues. The conversation then delves into the technical details of OTS, including its proof format and how it relates to transactions and Bitcoin blocks. The participants also discuss the concept of linearization and its relevance in a use-case scenario. They debate the advantages and disadvantages of different transaction models and fee accounts implementation, emphasizing the importance of flexibility and avoiding unnecessary costs.Additionally, the conversation touches upon the topic of necromancy attacks, where an earlier version of a transaction is resurrected by a third party for OTS. The potential benefits and drawbacks of such attacks are discussed, along with suggestions for mitigating their impact. The discussion expands to include the design of fee accounts and the need for explicit tagging or opt-in features. Different viewpoints are presented, highlighting the potential limitations and advantages of each approach.Another topic addressed is the use of Child Pays for Parent (CPFP) to solve issues related to relative locktimes in Bitcoin Vaults. The participants discuss the recommended design for Vaults and the need for additional features like RBF-able addable input/output or sponsors.The conversation concludes with discussions on the definition of pinning attacks, progress in committing data, and the potential risks associated with certain approaches in blockchain schemes. Overall, the email conversation covers a wide range of topics related to blockchain technology, providing insights into the challenges and considerations involved in implementing and improving timestamping services.Bitcoin developer Jeremy Rubin has proposed a new design to improve the fee-paying semantics in Bitcoin. The current system of paying fees in-band presents challenges for smart contracts and features such as fee bumping and DoS-resistant payment channels. Rubin's proposal suggests two approaches: using a special transaction called a "sponsor" to allow arbitrary fee appending, or implementing an account system as an extension block.The account system proposal involves defining a "fee account" output type that would have separate UTXO databases for deposits and withdrawals. Fee accounts would only be able to sign two types of transactions: one specifying a fee amount and a TXID, and another specifying a withdrawal amount, a fee, and an address. These transactions would be committed in an extension block merkle tree.Rubin argues that the proposed account system would make it easier to write smart contracts by separating the logic from the fees. The mempool logic would be updated to allow attaching fee account spends to transactions, with restrictions on accounts not being allowed to spend more than their balance. The design is considered scalable because adding fees to a transaction does not require adding inputs or outputs or tracking substantial amounts of new state.The proposal could also be modified to enhance privacy by implementing techniques like Tornado.cash or a trustless mixing protocol. Rubin suggests that a federated network could be used to bribe miners until a consensus upgrade is deployed, but acknowledges that this approach may introduce centralization.Overall, Rubin's proposal aims to address the limitations of the current fee-paying system in Bitcoin and provide more flexibility and scalability while considering privacy concerns. 2022-05-02T15:59:49+00:00 + In a detailed email conversation, the participants discuss various aspects of blockchain technology, specifically focusing on Open Time Stamps (OTS). The discussion begins with a proposal for a correct timestamping service model, stating that any such service must adhere to the model to be reliable. The writer highlights the potential issues and unreliability that can arise if the model is not followed.Jeremy Rubin questions the appeal to authority in the Bitcoin-dev group and raises concerns about the formal correctness of OTS. He suggests the need for an actual specification for OTS to resolve these issues. The conversation then delves into the technical details of OTS, including its proof format and how it relates to transactions and Bitcoin blocks. The participants also discuss the concept of linearization and its relevance in a use-case scenario. They debate the advantages and disadvantages of different transaction models and fee accounts implementation, emphasizing the importance of flexibility and avoiding unnecessary costs.Additionally, the conversation touches upon the topic of necromancy attacks, where an earlier version of a transaction is resurrected by a third party for OTS. The potential benefits and drawbacks of such attacks are discussed, along with suggestions for mitigating their impact. The discussion expands to include the design of fee accounts and the need for explicit tagging or opt-in features. Different viewpoints are presented, highlighting the potential limitations and advantages of each approach.Another topic addressed is the use of Child Pays for Parent (CPFP) to solve issues related to relative locktimes in Bitcoin Vaults. The participants discuss the recommended design for Vaults and the need for additional features like RBF-able addable input/output or sponsors.The conversation concludes with discussions on the definition of pinning attacks, progress in committing data, and the potential risks associated with certain approaches in blockchain schemes. Overall, the email conversation covers a wide range of topics related to blockchain technology, providing insights into the challenges and considerations involved in implementing and improving timestamping services.Bitcoin developer Jeremy Rubin has proposed a new design to improve the fee-paying semantics in Bitcoin. The current system of paying fees in-band presents challenges for smart contracts and features such as fee bumping and DoS-resistant payment channels. Rubin's proposal suggests two approaches: using a special transaction called a "sponsor" to allow arbitrary fee appending, or implementing an account system as an extension block.The account system proposal involves defining a "fee account" output type that would have separate UTXO databases for deposits and withdrawals. Fee accounts would only be able to sign two types of transactions: one specifying a fee amount and a TXID, and another specifying a withdrawal amount, a fee, and an address. These transactions would be committed in an extension block merkle tree.Rubin argues that the proposed account system would make it easier to write smart contracts by separating the logic from the fees. The mempool logic would be updated to allow attaching fee account spends to transactions, with restrictions on accounts not being allowed to spend more than their balance. The design is considered scalable because adding fees to a transaction does not require adding inputs or outputs or tracking substantial amounts of new state.The proposal could also be modified to enhance privacy by implementing techniques like Tornado.cash or a trustless mixing protocol. Rubin suggests that a federated network could be used to bribe miners until a consensus upgrade is deployed, but acknowledges that this approach may introduce centralization.Overall, Rubin's proposal aims to address the limitations of the current fee-paying system in Bitcoin and provide more flexibility and scalability while considering privacy concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_7-Theses-on-a-next-step-for-BIP-119.xml b/static/bitcoin-dev/April_2022/combined_7-Theses-on-a-next-step-for-BIP-119.xml index 74193cecf7..9f977baa9f 100644 --- a/static/bitcoin-dev/April_2022/combined_7-Theses-on-a-next-step-for-BIP-119.xml +++ b/static/bitcoin-dev/April_2022/combined_7-Theses-on-a-next-step-for-BIP-119.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - 7 Theses on a next step for BIP-119 - 2023-08-02T06:09:04.256087+00:00 - - Greg Sanders 2022-04-21 14:16:24+00:00 - - - alicexbt 2022-04-21 13:40:19+00:00 - - - Zac Greenwood 2022-04-21 12:49:19+00:00 - - - Robin Linus 2022-04-21 09:05:53+00:00 - - - Billy Tetrud 2022-04-21 04:03:05+00:00 - - - Michael Folkson 2022-04-20 22:04:03+00:00 - - - Robin Linus 2022-04-20 19:46:52+00:00 - - - Michael Folkson 2022-04-20 18:19:49+00:00 - - - Robin Linus 2022-04-20 17:13:02+00:00 - - - Michael Folkson 2022-04-20 13:24:52+00:00 - - - Jeremy Rubin 2022-04-19 17:31:54+00:00 - + 2025-09-26T14:33:54.766027+00:00 + python-feedgen + + + [bitcoin-dev] 7 Theses on a next step for BIP-119 Jeremy Rubin + 2022-04-19T17:31:00.000Z + + + Michael Folkson + 2022-04-20T13:24:00.000Z + + + Robin Linus + 2022-04-20T17:13:00.000Z + + + Michael Folkson + 2022-04-20T18:19:00.000Z + + + Robin Linus + 2022-04-20T19:46:00.000Z + + + Michael Folkson + 2022-04-20T22:04:00.000Z + + + Billy Tetrud + 2022-04-21T04:03:00.000Z + + + Robin Linus + 2022-04-21T09:05:00.000Z + + + Zac Greenwood + 2022-04-21T12:49:00.000Z + + + alicexbt + 2022-04-21T13:40:00.000Z + + + Greg Sanders + 2022-04-21T14:16:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - 7 Theses on a next step for BIP-119 - 2023-08-02T06:09:04.256087+00:00 + 2025-09-26T14:33:54.767353+00:00 - The ongoing debate over the activation of the CTV soft fork on Bitcoin Core has sparked contention among developers. Michael Folkson, a developer on the platform, has expressed concern that if the activation attempt causes uncertainty and confusion, it will make future soft forks with community consensus much harder to implement. Folkson urges developers to assume good faith unless accusing someone of being an NSA-adjacent asset.Folkson explains that the latest Bitcoin Core release candidate does not contain any new soft fork code, including CTV code or activation code. Running Bitcoin Core 23.0 out of the box will not signal for any new soft fork or enforce any new rules. However, most individuals who oppose the CTV soft fork have not logged their opposition on Jeremy's site, leading to exclusion in discussions.According to Folkson, if 90% of miners do not signal for the CTV soft fork, the activation attempt will fail. If 90% do signal, the fork could activate unless full nodes resist it. Folkson advises those opposed to voice their opposition, run full node software without CTV code, and consider running software rejecting CTV rules post-activation. The focus should be on resisting soft forks without community consensus and preventing fragmentation of Bitcoin into different assets.The email exchange between members of the Bitcoin community discusses the role of miners in deciding the fate of soft forks. It emphasizes the need for consensus-based decision-making and challenges the notion that miners have authority over soft forks. It also highlights the differing perspectives on the activation of CTV and the importance of evaluating alternatives and taking time to analyze changes to Bitcoin.In another email exchange, Robin criticizes Michael's opposition to CTV activation and accuses him of stalling protocol development. Robin argues that focusing on protocol development instead of unnecessary debates is crucial. Michael denies being a full-time CTV developer or advocate, expressing skepticism about its suitability for intended use cases. The exchange highlights the different viewpoints within the Bitcoin community and the need for constructive discussions.The email exchange between two members of the Bitcoin community discusses the activation of CTV and its potential use cases. The sender emphasizes the importance of analyzing new changes and compares the maturity of CTV with Taproot. They suggest evaluating alternatives and choosing the best tool available. The recipient raises concerns about chain split risks and urges opposition to the activation attempt.In another exchange, Robin challenges Michael's proposal for alternative covenant enabling proposals and questions his contribution to progress. Robin highlights Jeremy's extensive work on covenant enabling proposals and suggests that Michael should focus on finding a better solution instead of criticizing. Michael responds by expressing skepticism about CTV's suitability and suggesting actions for those opposing the activation attempt.Michael Folkson responds to Robin Linus's email opposing CTV activation, expressing doubts about its suitability without consensus. He suggests building use cases and comparing alternatives before activation. Robin criticizes Michael's lack of tangible contributions and urges him to work towards a solution rather than criticizing. Jeremy Rubin advocates for CTV activation and outlines the reasons supporting it.The debate focuses on the risks and benefits of CTV activation, with concerns about chain splits and the need for consensus-based decision-making. The discussions highlight the importance of constructive dialogue, evaluation of alternatives, and community consensus in protocol development.In his latest update, Jeremy emphasizes the importance of resisting soft forks that lack community consensus in order to prevent Bitcoin from splintering into numerous assets and blockchains with different combinations of active soft forks. He believes that CTV (Consensus-enforced Transaction Validity) is the right path forward and shares seven theses supporting this belief. Jeremy's detailed post on rubin.io, which is also archived on web.archive.org, provides further insights into his proposal.Jeremy's update serves as a precursor to the upcoming CTV meeting scheduled for today. He actively encourages feedback on his proposal and expresses his openness to constructive criticism. 2022-04-21T14:16:24+00:00 + The ongoing debate over the activation of the CTV soft fork on Bitcoin Core has sparked contention among developers. Michael Folkson, a developer on the platform, has expressed concern that if the activation attempt causes uncertainty and confusion, it will make future soft forks with community consensus much harder to implement. Folkson urges developers to assume good faith unless accusing someone of being an NSA-adjacent asset.Folkson explains that the latest Bitcoin Core release candidate does not contain any new soft fork code, including CTV code or activation code. Running Bitcoin Core 23.0 out of the box will not signal for any new soft fork or enforce any new rules. However, most individuals who oppose the CTV soft fork have not logged their opposition on Jeremy's site, leading to exclusion in discussions.According to Folkson, if 90% of miners do not signal for the CTV soft fork, the activation attempt will fail. If 90% do signal, the fork could activate unless full nodes resist it. Folkson advises those opposed to voice their opposition, run full node software without CTV code, and consider running software rejecting CTV rules post-activation. The focus should be on resisting soft forks without community consensus and preventing fragmentation of Bitcoin into different assets.The email exchange between members of the Bitcoin community discusses the role of miners in deciding the fate of soft forks. It emphasizes the need for consensus-based decision-making and challenges the notion that miners have authority over soft forks. It also highlights the differing perspectives on the activation of CTV and the importance of evaluating alternatives and taking time to analyze changes to Bitcoin.In another email exchange, Robin criticizes Michael's opposition to CTV activation and accuses him of stalling protocol development. Robin argues that focusing on protocol development instead of unnecessary debates is crucial. Michael denies being a full-time CTV developer or advocate, expressing skepticism about its suitability for intended use cases. The exchange highlights the different viewpoints within the Bitcoin community and the need for constructive discussions.The email exchange between two members of the Bitcoin community discusses the activation of CTV and its potential use cases. The sender emphasizes the importance of analyzing new changes and compares the maturity of CTV with Taproot. They suggest evaluating alternatives and choosing the best tool available. The recipient raises concerns about chain split risks and urges opposition to the activation attempt.In another exchange, Robin challenges Michael's proposal for alternative covenant enabling proposals and questions his contribution to progress. Robin highlights Jeremy's extensive work on covenant enabling proposals and suggests that Michael should focus on finding a better solution instead of criticizing. Michael responds by expressing skepticism about CTV's suitability and suggesting actions for those opposing the activation attempt.Michael Folkson responds to Robin Linus's email opposing CTV activation, expressing doubts about its suitability without consensus. He suggests building use cases and comparing alternatives before activation. Robin criticizes Michael's lack of tangible contributions and urges him to work towards a solution rather than criticizing. Jeremy Rubin advocates for CTV activation and outlines the reasons supporting it.The debate focuses on the risks and benefits of CTV activation, with concerns about chain splits and the need for consensus-based decision-making. The discussions highlight the importance of constructive dialogue, evaluation of alternatives, and community consensus in protocol development.In his latest update, Jeremy emphasizes the importance of resisting soft forks that lack community consensus in order to prevent Bitcoin from splintering into numerous assets and blockchains with different combinations of active soft forks. He believes that CTV (Consensus-enforced Transaction Validity) is the right path forward and shares seven theses supporting this belief. Jeremy's detailed post on rubin.io, which is also archived on web.archive.org, provides further insights into his proposal.Jeremy's update serves as a precursor to the upcoming CTV meeting scheduled for today. He actively encourages feedback on his proposal and expresses his openness to constructive criticism. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_A-Calculus-of-Covenants.xml b/static/bitcoin-dev/April_2022/combined_A-Calculus-of-Covenants.xml index fa0cfe7477..a945d3da7a 100644 --- a/static/bitcoin-dev/April_2022/combined_A-Calculus-of-Covenants.xml +++ b/static/bitcoin-dev/April_2022/combined_A-Calculus-of-Covenants.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - A Calculus of Covenants - 2023-08-02T06:07:59.342861+00:00 - - Keagan McClelland 2022-05-18 17:08:43+00:00 - - - Jeremy Rubin 2022-04-12 15:03:57+00:00 - - - Jeremy Rubin 2022-04-12 14:33:14+00:00 - + 2025-09-26T14:33:37.557243+00:00 + python-feedgen + + + [bitcoin-dev] A Calculus of Covenants Jeremy Rubin + 2022-04-12T14:33:00.000Z + + + Jeremy Rubin + 2022-04-12T15:03:00.000Z + + + Keagan McClelland + 2022-05-18T17:08:00.000Z + + - python-feedgen + 2 Combined summary - A Calculus of Covenants - 2023-08-02T06:07:59.342861+00:00 + 2025-09-26T14:33:37.557740+00:00 - The author presents a framework for understanding covenants in the context of building infrastructure for them. The focus is on local covenants, where only one coin is examined. The framework defines a covenant primitive as having a set of transaction intents, a verifier generator function, a prover generator function, impedance-matched proofs, and assumptions under which the covenant is verified.To instantiate a covenant, the user selects a specific element from the set of sets of transaction intents and generates a verifier and a prover function. This framework is then applied to analyze three covenants: plain CTV, 2-3 online multisig, and 3-3 presigned + deleted.The author also raises questions about the cardinality of an intent set, the composition of different covenants within an intent, and the unrollability of intents. While the framework assumes statelessness, it acknowledges that provers may need to maintain external state to prove.The author notes that the efficiency of a prover or verifier is not addressed in this framework. However, the framework is valuable for generating tooling that can integrate covenants into Sapio, a platform.Overall, this framework provides a comprehensive approach to analyzing covenants and offers insights into their practical use cases. 2022-05-18T17:08:43+00:00 + The author presents a framework for understanding covenants in the context of building infrastructure for them. The focus is on local covenants, where only one coin is examined. The framework defines a covenant primitive as having a set of transaction intents, a verifier generator function, a prover generator function, impedance-matched proofs, and assumptions under which the covenant is verified.To instantiate a covenant, the user selects a specific element from the set of sets of transaction intents and generates a verifier and a prover function. This framework is then applied to analyze three covenants: plain CTV, 2-3 online multisig, and 3-3 presigned + deleted.The author also raises questions about the cardinality of an intent set, the composition of different covenants within an intent, and the unrollability of intents. While the framework assumes statelessness, it acknowledges that provers may need to maintain external state to prove.The author notes that the efficiency of a prover or verifier is not addressed in this framework. However, the framework is valuable for generating tooling that can integrate covenants into Sapio, a platform.Overall, this framework provides a comprehensive approach to analyzing covenants and offers insights into their practical use cases. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_ANYPREVOUT-in-place-of-CTV.xml b/static/bitcoin-dev/April_2022/combined_ANYPREVOUT-in-place-of-CTV.xml index 0a43fc75a8..03cc0679ee 100644 --- a/static/bitcoin-dev/April_2022/combined_ANYPREVOUT-in-place-of-CTV.xml +++ b/static/bitcoin-dev/April_2022/combined_ANYPREVOUT-in-place-of-CTV.xml @@ -1,86 +1,115 @@ - + 2 Combined summary - ANYPREVOUT in place of CTV - 2023-08-02T06:12:38.421815+00:00 - - Swambo, Jacob 2022-05-03 16:40:22+00:00 - - - Jeremy Rubin 2022-05-03 15:51:18+00:00 - - - darosior 2022-05-03 10:38:52+00:00 - - - Billy Tetrud 2022-05-01 23:35:08+00:00 - - - Nadav Ivgi 2022-05-01 14:25:42+00:00 - - - Greg Sanders 2022-04-30 11:15:25+00:00 - - - Nadav Ivgi 2022-04-30 08:09:26+00:00 - - - Swambo, Jacob 2022-04-29 13:22:14+00:00 - - - Nadav Ivgi 2022-04-29 11:40:05+00:00 - - - Nadav Ivgi 2022-04-29 10:21:33+00:00 - - - darosior 2022-04-29 08:30:55+00:00 - - - Nadav Ivgi 2022-04-29 05:08:32+00:00 - - - Jeremy Rubin 2022-04-26 20:13:26+00:00 - - - Nadav Ivgi 2022-04-25 16:57:48+00:00 - - - Nadav Ivgi 2022-04-25 16:35:17+00:00 - - - darosior 2022-04-25 16:35:14+00:00 - - - darosior 2022-04-25 13:35:48+00:00 - - - Hampus Sjöberg 2022-04-25 13:34:25+00:00 - - - Erik Aronesty 2022-04-25 01:46:25+00:00 - - - Richard Myers 2022-04-24 20:41:54+00:00 - - - pushd 2022-04-22 17:14:50+00:00 - - - Luke Dashjr 2022-04-22 17:01:14+00:00 - - - pushd 2022-04-22 13:35:11+00:00 - - - darosior 2022-04-22 11:54:30+00:00 - - - rot13maxi 2022-04-22 11:44:24+00:00 - - - darosior 2022-04-22 11:11:41+00:00 - + 2025-09-26T14:33:52.613222+00:00 + python-feedgen + + + [bitcoin-dev] ANYPREVOUT in place of CTV darosior + 2022-04-22T11:11:00.000Z + + + rot13maxi + 2022-04-22T11:44:00.000Z + + + darosior + 2022-04-22T11:54:00.000Z + + + pushd + 2022-04-22T13:35:00.000Z + + + Luke Dashjr + 2022-04-22T17:01:00.000Z + + + pushd + 2022-04-22T17:14:00.000Z + + + Richard Myers + 2022-04-24T20:41:00.000Z + + + Erik Aronesty + 2022-04-25T01:46:00.000Z + + + Hampus Sjöberg + 2022-04-25T13:34:00.000Z + + + darosior + 2022-04-25T13:35:00.000Z + + + darosior + 2022-04-25T16:35:00.000Z + + + Nadav Ivgi + 2022-04-25T16:35:00.000Z + + + Nadav Ivgi + 2022-04-25T16:57:00.000Z + + + Jeremy Rubin + 2022-04-26T20:13:00.000Z + + + Nadav Ivgi + 2022-04-29T05:08:00.000Z + + + darosior + 2022-04-29T08:30:00.000Z + + + Nadav Ivgi + 2022-04-29T10:21:00.000Z + + + Nadav Ivgi + 2022-04-29T11:40:00.000Z + + + Swambo, Jacob + 2022-04-29T13:22:00.000Z + + + Nadav Ivgi + 2022-04-30T08:09:00.000Z + + + Greg Sanders + 2022-04-30T11:15:00.000Z + + + Nadav Ivgi + 2022-05-01T14:25:00.000Z + + + Billy Tetrud + 2022-05-01T23:35:00.000Z + + + darosior + 2022-05-03T10:38:00.000Z + + + Jeremy Rubin + 2022-05-03T15:51:00.000Z + + + Swambo, Jacob + 2022-05-03T16:40:00.000Z + + @@ -107,13 +136,13 @@ - python-feedgen + 2 Combined summary - ANYPREVOUT in place of CTV - 2023-08-02T06:12:38.421815+00:00 + 2025-09-26T14:33:52.615944+00:00 - The email thread discusses the debate within the Bitcoin developer community regarding the use of SIGHASH_ANYPREVOUT (APO) as an alternative to CTV's proposed covenant design. The author retracts their previous statement in favor of OP_CTV, realizing that both APOAS and CTV face a trade-off between flexibility and safety. They question the need for less restrictive templates and provide reasons why such templates may be necessary. They argue that disallowing RBF can make it difficult for attackers to create malicious alternatives, certain covenant-based applications may not be critical enough to require strict restrictions, and flexible signature messages can be used safely in trusted multi-party contexts.The author suggests that APOAS covenants, when combined with other SIGHASH modes and the ability to re-bind transactions, offer more flexibility than CTV covenants. They express their uncertainty about the safety of BIP-118 but believe that the recent debate is part of the maturation process and are glad for it.The discussion also focuses on the potential use of APO instead of CTV. Some argue that APO gets dangerously close to fully recursive covenants and suggest using smaller independent steps, like adding CTV and gradually introducing more flags and ergonomic Opcodes for covenants. Others believe that BIP118 could be a soft fork candidate that benefits more Bitcoin users, considering the interest in simple covenants and better off-chain protocols. There is also concern about the long-term storage of bitcoins in non-quantum-computer vulnerable-bare-CTV-covenants and the potential impact of a large-scale theft of bitcoins on the overall value of the cryptocurrency.In a conversation between Antoine and Jacob, they discuss the comparison between CTV and APO covenants. Antoine clarifies that both commit to the same template and that more powerful covenants could enable more interesting applications where CTV would be an optimization. However, in the short term, some request activating CTV to start playing with covenants before settling on a more useful covenant. Jacob argues that APOAS-based covenants tie the signature message algorithm to both the covenant commitment and transaction validation, introducing a trade-off between safety and flexibility. Antoine suggests separating the covenant commitment from the signatures to validate transactions, bypassing this trade-off.The email thread also discusses the use of BIP118 and its potential as a soft fork candidate. It is suggested that committing to the number of inputs instead of sha_sequences ensures txid stability for single input transactions. There is also discussion about whether APO-AS part of BIP118 may face opposition similar to BIP119.In another discussion on the Bitcoin-dev mailing list, the use cases of APOAS|SINGLE are explored. It is noted that APOAS|SINGLE is useful for vaults or spacechains but not for batch channels or congestion control. The debate revolves around the commitment to amount and its implications. The suggestions put forward include doing a tweaked version of BIP118 in place of or before BIP119 and making the commitment to amount optional behind a flag.The author acknowledges the benefits of using APOAS instead of CTV in the short-term, as it enables Eltoo. However, they argue that there is a point in favor of CTV in the long-term. They suggest separating the covenant commitment from the signatures to validate transactions, providing additional flexibility for new templates and enabling more utility for covenant-based applications.The author of a post on the Bitcoin-dev mailing list proposes using a tweaked version of BIP118 as an alternative to CTV. They argue that SIGHASH_ANYPREVOUTANYSCRIPT can emulate CTV if its "ANYONECANPAY" behavior is made optional. The author suggests that APO-AS covenants could cover the flagship use case of vaults and that potential use cases for APO should be explored. They propose that BIP118 could benefit more Bitcoin users and ask if people would oppose the APO-AS part of BIP118 for the same reasons they might oppose BIP119.Another member of the mailing list expresses doubts about the necessity and sufficiency of CTV, suggesting that pre-signed transactions could be used instead. They argue that APO-AS covenants can cover the same use cases as CTV and propose that CTV could be considered an optimization of APO. The member suggests that if onchain usage proves them wrong, CTV could still be rolled out as an optimization.In addition, there is discussion about the activation of CTV and SIGHASH_ANYPREVOUT, with concerns about scarce reviewer time. The fields covered by the CTV hash are similar to what the ANYPREVOUT_ANYSCRIPT's signature hash covers, but APO_AS does not commit to the number of inputs and the hash of the inputs' sequences. It is suggested that tweaking BIP118 could address these issues and make it more compatible with C 2022-05-03T16:40:22+00:00 + The email thread discusses the debate within the Bitcoin developer community regarding the use of SIGHASH_ANYPREVOUT (APO) as an alternative to CTV's proposed covenant design. The author retracts their previous statement in favor of OP_CTV, realizing that both APOAS and CTV face a trade-off between flexibility and safety. They question the need for less restrictive templates and provide reasons why such templates may be necessary. They argue that disallowing RBF can make it difficult for attackers to create malicious alternatives, certain covenant-based applications may not be critical enough to require strict restrictions, and flexible signature messages can be used safely in trusted multi-party contexts.The author suggests that APOAS covenants, when combined with other SIGHASH modes and the ability to re-bind transactions, offer more flexibility than CTV covenants. They express their uncertainty about the safety of BIP-118 but believe that the recent debate is part of the maturation process and are glad for it.The discussion also focuses on the potential use of APO instead of CTV. Some argue that APO gets dangerously close to fully recursive covenants and suggest using smaller independent steps, like adding CTV and gradually introducing more flags and ergonomic Opcodes for covenants. Others believe that BIP118 could be a soft fork candidate that benefits more Bitcoin users, considering the interest in simple covenants and better off-chain protocols. There is also concern about the long-term storage of bitcoins in non-quantum-computer vulnerable-bare-CTV-covenants and the potential impact of a large-scale theft of bitcoins on the overall value of the cryptocurrency.In a conversation between Antoine and Jacob, they discuss the comparison between CTV and APO covenants. Antoine clarifies that both commit to the same template and that more powerful covenants could enable more interesting applications where CTV would be an optimization. However, in the short term, some request activating CTV to start playing with covenants before settling on a more useful covenant. Jacob argues that APOAS-based covenants tie the signature message algorithm to both the covenant commitment and transaction validation, introducing a trade-off between safety and flexibility. Antoine suggests separating the covenant commitment from the signatures to validate transactions, bypassing this trade-off.The email thread also discusses the use of BIP118 and its potential as a soft fork candidate. It is suggested that committing to the number of inputs instead of sha_sequences ensures txid stability for single input transactions. There is also discussion about whether APO-AS part of BIP118 may face opposition similar to BIP119.In another discussion on the Bitcoin-dev mailing list, the use cases of APOAS|SINGLE are explored. It is noted that APOAS|SINGLE is useful for vaults or spacechains but not for batch channels or congestion control. The debate revolves around the commitment to amount and its implications. The suggestions put forward include doing a tweaked version of BIP118 in place of or before BIP119 and making the commitment to amount optional behind a flag.The author acknowledges the benefits of using APOAS instead of CTV in the short-term, as it enables Eltoo. However, they argue that there is a point in favor of CTV in the long-term. They suggest separating the covenant commitment from the signatures to validate transactions, providing additional flexibility for new templates and enabling more utility for covenant-based applications.The author of a post on the Bitcoin-dev mailing list proposes using a tweaked version of BIP118 as an alternative to CTV. They argue that SIGHASH_ANYPREVOUTANYSCRIPT can emulate CTV if its "ANYONECANPAY" behavior is made optional. The author suggests that APO-AS covenants could cover the flagship use case of vaults and that potential use cases for APO should be explored. They propose that BIP118 could benefit more Bitcoin users and ask if people would oppose the APO-AS part of BIP118 for the same reasons they might oppose BIP119.Another member of the mailing list expresses doubts about the necessity and sufficiency of CTV, suggesting that pre-signed transactions could be used instead. They argue that APO-AS covenants can cover the same use cases as CTV and propose that CTV could be considered an optimization of APO. The member suggests that if onchain usage proves them wrong, CTV could still be rolled out as an optimization.In addition, there is discussion about the activation of CTV and SIGHASH_ANYPREVOUT, with concerns about scarce reviewer time. The fields covered by the CTV hash are similar to what the ANYPREVOUT_ANYSCRIPT's signature hash covers, but APO_AS does not commit to the number of inputs and the hash of the inputs' sequences. It is suggested that tweaking BIP118 could address these issues and make it more compatible with C - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml b/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml index 64cfb52f8b..2048c1a11d 100644 --- a/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml +++ b/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Automatically reverting ("transitory") soft forks, e.g. for CTV - 2023-08-02T06:10:30.933585+00:00 + Combined summary - Automatically reverting ("transitory") soft forks, e.g. for CTV + 2025-09-26T14:33:35.444629+00:00 + python-feedgen ZmnSCPxj 2022-04-25 05:12:10+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 - Combined summary - Automatically reverting ("transitory") soft forks, e.g. for CTV - 2023-08-02T06:10:30.933585+00:00 + Combined summary - Automatically reverting ("transitory") soft forks, e.g. for CTV + 2025-09-26T14:33:35.444821+00:00 - In an email thread discussing the implementation of new features or opcodes in Bitcoin SCRIPT, a proposal is made to use real-world funds to prove demand. This involves using Smart Contracts Unchained and creating a mapping from Bitcoin SCRIPT opcodes to micro-opcodes. While this approach demonstrates real demand, there are concerns about security erosion and reliance on a federation. The possibility of reverting activated soft forks is discussed, but it is suggested that reverting without disrupting the network may not be possible. Concerns about specific covenant designs being discussed without actual implementations or sample usages are raised, with a suggestion to address this issue in the short-term. The focus of the discussion shifts to the implementation of covenants in Bitcoin, with arguments for and against CTV as the preferred design. The difficulty in choosing the "best" covenant design is acknowledged, along with the challenges and risks associated with doing a fork in Bitcoin. The lack of serious proposals other than CTV is noted, highlighting its simplicity and positive reviews. The potential uses of covenants, particularly vaults, are discussed, with CTV seen as a low-risk way to implement them. However, there is recognition of the need for more general covenant abilities and the time and effort required for their development. The practicality and utility of various covenant proposals are debated, with a preference for CTV due to its low-risk approach to vaulting. The criteria for adding a covenant to Bitcoin are outlined, including demonstrated use cases, alignment with Bitcoin's design, technical feasibility, and a well-reviewed implementation. The possibility of reverting to earlier consensus rules is also mentioned. The ongoing discussion about covenant designs is highlighted, with a lack of serious proposals other than CTV. The challenges of finding a preferable alternative and the need for complete specifications and tooling are discussed. Concerns about the long-term nature of CTV's use cases and its compatibility with a sunset period are raised. The suggestion is made to use CTV for most of the deployment to demonstrate real-world usage and convince others to make it permanent. Bitcoin developers discuss the best way to implement covenant functionality in Bitcoin, with no clear consensus on the best design. More data about user demand and usage is deemed necessary. The proposal of a transitory soft fork to activate different covenant designs is met with concerns about safety risks and recursion. Criticisms of CTV are discussed, including concerns about usage, maintenance burden, and the lack of consensus around concrete proposals for covenants. The need for real usage data and optimizing for demonstrated needs is emphasized. The risk and cost of doing a fork and the suggestion of adding "technical community consensus" as a factor in the process are also mentioned. The viability of the proposed BIP119 CTV is debated, with considerations of usage, maintenance burden, and consensus within the technical community. The importance of maintaining Bitcoin's culture of security and careful design is stressed. The possibility of modifying the witness discount in SegWit transactions through an additional soft fork is suggested, but concerns about potential confiscation of funds are raised. The variant of Speedy Trial being used and accusations of efforts to sabotage parallel UASF initiatives are also discussed. The importance of advocacy and improving logic is emphasized. The question of whether changes made by already activated soft forks can be reverted is raised, with suggestions for potential solutions. Concerns about increased weight making transactions invalid and criticism of the variant of Speedy Trial being used are expressed. The idea of making CTV an automatically reverting consensus change with an option to renew after five years is proposed. This allows experimentation with new features without permanent commitment. However, concerns about usage, maintenance burden, and the risk of losing money and potential miner censorship near the reversion date are raised. Alternative ways to activate CTV, such as a UASF client compatible with a speedy trial release, are suggested. The importance of allowing users to decide and preventing miner veto power is emphasized. Despite the downsides, an automatically reverting soft fork provides the opportunity to experiment with new features.The Bitcoin community expresses concerns about the future use of CTV due to maintenance and security issues. The proposal to automatically revert CTV as a consensus change after five years is discussed, allowing for experimentation without permanent commitment. However, there are potential risks such as the loss of funds and potential miner censorship. Further discussions on CTV are anticipated. A proposal is made to address criticisms against CTV by making it an automatically reverting consensus change with an option to renew, allowing for experimentation without permanent commitment. However, concerns about risks and potential miner censorship remain. Further discussions on CTV are expected. 2022-04-25T05:12:10+00:00 + In an email thread discussing the implementation of new features or opcodes in Bitcoin SCRIPT, a proposal is made to use real-world funds to prove demand. This involves using Smart Contracts Unchained and creating a mapping from Bitcoin SCRIPT opcodes to micro-opcodes. While this approach demonstrates real demand, there are concerns about security erosion and reliance on a federation. The possibility of reverting activated soft forks is discussed, but it is suggested that reverting without disrupting the network may not be possible. Concerns about specific covenant designs being discussed without actual implementations or sample usages are raised, with a suggestion to address this issue in the short-term. The focus of the discussion shifts to the implementation of covenants in Bitcoin, with arguments for and against CTV as the preferred design. The difficulty in choosing the "best" covenant design is acknowledged, along with the challenges and risks associated with doing a fork in Bitcoin. The lack of serious proposals other than CTV is noted, highlighting its simplicity and positive reviews. The potential uses of covenants, particularly vaults, are discussed, with CTV seen as a low-risk way to implement them. However, there is recognition of the need for more general covenant abilities and the time and effort required for their development. The practicality and utility of various covenant proposals are debated, with a preference for CTV due to its low-risk approach to vaulting. The criteria for adding a covenant to Bitcoin are outlined, including demonstrated use cases, alignment with Bitcoin's design, technical feasibility, and a well-reviewed implementation. The possibility of reverting to earlier consensus rules is also mentioned. The ongoing discussion about covenant designs is highlighted, with a lack of serious proposals other than CTV. The challenges of finding a preferable alternative and the need for complete specifications and tooling are discussed. Concerns about the long-term nature of CTV's use cases and its compatibility with a sunset period are raised. The suggestion is made to use CTV for most of the deployment to demonstrate real-world usage and convince others to make it permanent. Bitcoin developers discuss the best way to implement covenant functionality in Bitcoin, with no clear consensus on the best design. More data about user demand and usage is deemed necessary. The proposal of a transitory soft fork to activate different covenant designs is met with concerns about safety risks and recursion. Criticisms of CTV are discussed, including concerns about usage, maintenance burden, and the lack of consensus around concrete proposals for covenants. The need for real usage data and optimizing for demonstrated needs is emphasized. The risk and cost of doing a fork and the suggestion of adding "technical community consensus" as a factor in the process are also mentioned. The viability of the proposed BIP119 CTV is debated, with considerations of usage, maintenance burden, and consensus within the technical community. The importance of maintaining Bitcoin's culture of security and careful design is stressed. The possibility of modifying the witness discount in SegWit transactions through an additional soft fork is suggested, but concerns about potential confiscation of funds are raised. The variant of Speedy Trial being used and accusations of efforts to sabotage parallel UASF initiatives are also discussed. The importance of advocacy and improving logic is emphasized. The question of whether changes made by already activated soft forks can be reverted is raised, with suggestions for potential solutions. Concerns about increased weight making transactions invalid and criticism of the variant of Speedy Trial being used are expressed. The idea of making CTV an automatically reverting consensus change with an option to renew after five years is proposed. This allows experimentation with new features without permanent commitment. However, concerns about usage, maintenance burden, and the risk of losing money and potential miner censorship near the reversion date are raised. Alternative ways to activate CTV, such as a UASF client compatible with a speedy trial release, are suggested. The importance of allowing users to decide and preventing miner veto power is emphasized. Despite the downsides, an automatically reverting soft fork provides the opportunity to experiment with new features.The Bitcoin community expresses concerns about the future use of CTV due to maintenance and security issues. The proposal to automatically revert CTV as a consensus change after five years is discussed, allowing for experimentation without permanent commitment. However, there are potential risks such as the loss of funds and potential miner censorship. Further discussions on CTV are anticipated. A proposal is made to address criticisms against CTV by making it an automatically reverting consensus change with an option to renew, allowing for experimentation without permanent commitment. However, concerns about risks and potential miner censorship remain. Further discussions on CTV are expected. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_BIP-proposal-Pay-to-contract-tweak-fields-for-PSBT-bip-psbt-p2c-.xml b/static/bitcoin-dev/April_2022/combined_BIP-proposal-Pay-to-contract-tweak-fields-for-PSBT-bip-psbt-p2c-.xml index 8f881e5504..146a917455 100644 --- a/static/bitcoin-dev/April_2022/combined_BIP-proposal-Pay-to-contract-tweak-fields-for-PSBT-bip-psbt-p2c-.xml +++ b/static/bitcoin-dev/April_2022/combined_BIP-proposal-Pay-to-contract-tweak-fields-for-PSBT-bip-psbt-p2c-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c) - 2023-08-02T05:23:35.482429+00:00 - - Dr Maxim Orlovsky 2022-04-01 08:32:36+00:00 - - - Jeremy 2022-01-17 05:55:00+00:00 - - - Dr Maxim Orlovsky 2022-01-16 17:41:22+00:00 - + 2025-09-26T14:34:05.440328+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c) Dr Maxim Orlovsky + 2022-01-16T17:41:00.000Z + + + Jeremy + 2022-01-17T05:55:00.000Z + + + Dr Maxim Orlovsky + 2022-04-01T08:32:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c) - 2023-08-02T05:23:35.482429+00:00 + 2025-09-26T14:34:05.440849+00:00 - Dr. Maxim Orlovsky has proposed a new standard called BIP (Bitcoin Improvement Proposal) that aims to add pay-to-contract key tweaking data fields to PSBTs (Partially Signed Bitcoin Transactions). This proposal is an extension of the existing PSBT standard suggested by Andrew Poelstra in March 2019. The BIP proposal introduces a commitment called P2C, which creates a cryptographic commitment to some message using elliptic curve properties.The main objective of this proposal is to provide a universal method for spending previous outputs containing P2C tweaks. These tweaks are used to create a cryptographic commitment to a specific message. In order to spend an output containing a P2C commitment, the same commitment must be added to the corresponding private key. The proposal includes a new per-input type, PSBT_IN_P2C_TWEAK, which contains the compact public key serialization and a value that is added to the private key to produce valid signatures.This new field provides sufficient information for creating valid signatures for spending outputs containing tweaked public keys such as bare scripts, P2PK, P2PKH, P2SH, witness v0 P2WPKH and P2WSH, nested witness v0 P2WPKH-P2SH and P2WSH-P2SH, and witness v1 P2TR outputs. The proposal is compatible with existing consensus rules and does not require any modifications.It is important to note that this proposal only focuses on spending transaction outputs containing P2C tweaks and does not address the construction of new P2C commitments or transactions containing them in their outputs. The scope of the proposal is limited to the question of spending an output that previously contained a P2C commitment, without creating a new commitment or risking extra-blockchain value loss.External signers who may not have any information about the P2C commitment can use this proposal to produce valid signatures. However, it is worth mentioning that possible future witness versions, including witness v1 non-taproot outputs, may not be supported by this BIP and may require the addition of new fields to the PSBT inputs.In summary, Dr. Maxim Orlovsky's proposal aims to extend the PSBT standard by adding new fields for pay-to-contract key tweaking data. The proposal provides a universal method for spending previous outputs containing P2C tweaks and is compatible with existing consensus rules. It introduces a new per-input type, PSBT_IN_P2C_TWEAK, which contains the necessary information for creating valid signatures. However, it does not address the construction of new P2C commitments or transactions containing them in their outputs. 2022-04-01T08:32:36+00:00 + Dr. Maxim Orlovsky has proposed a new standard called BIP (Bitcoin Improvement Proposal) that aims to add pay-to-contract key tweaking data fields to PSBTs (Partially Signed Bitcoin Transactions). This proposal is an extension of the existing PSBT standard suggested by Andrew Poelstra in March 2019. The BIP proposal introduces a commitment called P2C, which creates a cryptographic commitment to some message using elliptic curve properties.The main objective of this proposal is to provide a universal method for spending previous outputs containing P2C tweaks. These tweaks are used to create a cryptographic commitment to a specific message. In order to spend an output containing a P2C commitment, the same commitment must be added to the corresponding private key. The proposal includes a new per-input type, PSBT_IN_P2C_TWEAK, which contains the compact public key serialization and a value that is added to the private key to produce valid signatures.This new field provides sufficient information for creating valid signatures for spending outputs containing tweaked public keys such as bare scripts, P2PK, P2PKH, P2SH, witness v0 P2WPKH and P2WSH, nested witness v0 P2WPKH-P2SH and P2WSH-P2SH, and witness v1 P2TR outputs. The proposal is compatible with existing consensus rules and does not require any modifications.It is important to note that this proposal only focuses on spending transaction outputs containing P2C tweaks and does not address the construction of new P2C commitments or transactions containing them in their outputs. The scope of the proposal is limited to the question of spending an output that previously contained a P2C commitment, without creating a new commitment or risking extra-blockchain value loss.External signers who may not have any information about the P2C commitment can use this proposal to produce valid signatures. However, it is worth mentioning that possible future witness versions, including witness v1 non-taproot outputs, may not be supported by this BIP and may require the addition of new fields to the PSBT inputs.In summary, Dr. Maxim Orlovsky's proposal aims to extend the PSBT standard by adding new fields for pay-to-contract key tweaking data. The proposal provides a universal method for spending previous outputs containing P2C tweaks and is compatible with existing consensus rules. It introduces a new per-input type, PSBT_IN_P2C_TWEAK, which contains the necessary information for creating valid signatures. However, it does not address the construction of new P2C commitments or transactions containing them in their outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_BIP174-PSBT-test-vector.xml b/static/bitcoin-dev/April_2022/combined_BIP174-PSBT-test-vector.xml index 915ab31f2d..266d9050d3 100644 --- a/static/bitcoin-dev/April_2022/combined_BIP174-PSBT-test-vector.xml +++ b/static/bitcoin-dev/April_2022/combined_BIP174-PSBT-test-vector.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP174 PSBT test vector - 2023-08-02T06:02:08.267280+00:00 - - Tobin Harding 2022-04-06 22:15:07+00:00 - - - Achow101 2022-04-05 23:21:17+00:00 - - - Tobin Harding 2022-04-05 22:55:18+00:00 - + 2025-09-26T14:34:01.177148+00:00 + python-feedgen + + + [bitcoin-dev] BIP174 PSBT test vector Tobin Harding + 2022-04-05T22:55:00.000Z + + + Achow101 + 2022-04-05T23:21:00.000Z + + + Tobin Harding + 2022-04-06T22:15:00.000Z + + - python-feedgen + 2 Combined summary - BIP174 PSBT test vector - 2023-08-02T06:02:08.267280+00:00 + 2025-09-26T14:34:01.177642+00:00 - Tobin Harding recently reached out to the bitcoin-dev mailing list, seeking assistance with parsing the extended private key seed from the BIP174 test vector. He explained that he was in the process of implementing the test vector PSBT workflow in Rust and had encountered an issue with generating the extended private key using the provided seed. Harding provided links to the BIP174 specification and the specific section of the workflow where the seed was required. In order to give context, he included the xpriv and seed values from the test vector. However, despite his attempts to decode the seed as both base64 and base58, he was still unable to create the extended private key.In response to Tobin's query, Achow101 clarified that the seed is actually encoded as a WIF (Wallet Import Format) private key. Decoding it as a WIF key will yield the 32 byte seed, which can then be used according to the specifications outlined in BIP 32.Andrew also chimed in on the email thread, confirming this information. 2022-04-06T22:15:07+00:00 + Tobin Harding recently reached out to the bitcoin-dev mailing list, seeking assistance with parsing the extended private key seed from the BIP174 test vector. He explained that he was in the process of implementing the test vector PSBT workflow in Rust and had encountered an issue with generating the extended private key using the provided seed. Harding provided links to the BIP174 specification and the specific section of the workflow where the seed was required. In order to give context, he included the xpriv and seed values from the test vector. However, despite his attempts to decode the seed as both base64 and base58, he was still unable to create the extended private key.In response to Tobin's query, Achow101 clarified that the seed is actually encoded as a WIF (Wallet Import Format) private key. Decoding it as a WIF key will yield the 32 byte seed, which can then be used according to the specifications outlined in BIP 32.Andrew also chimed in on the email thread, confirming this information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_CTV-Signet-Parameters.xml b/static/bitcoin-dev/April_2022/combined_CTV-Signet-Parameters.xml index f7f1da3fe4..4887e9ab18 100644 --- a/static/bitcoin-dev/April_2022/combined_CTV-Signet-Parameters.xml +++ b/static/bitcoin-dev/April_2022/combined_CTV-Signet-Parameters.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - CTV Signet Parameters - 2023-08-02T05:39:40.983139+00:00 - - Jeremy Rubin 2022-04-28 12:23:32+00:00 - - - Jeremy Rubin 2022-04-22 05:30:08+00:00 - - - Nadav Ivgi 2022-04-22 01:10:25+00:00 - - - Anthony Towns 2022-04-22 00:58:04+00:00 - - - Jeremy Rubin 2022-04-21 15:05:20+00:00 - - - Russell O'Connor 2022-04-21 13:22:21+00:00 - - - Jeremy Rubin 2022-04-21 06:25:05+00:00 - - - Jeremy Rubin 2022-04-21 06:16:09+00:00 - - - Anthony Towns 2022-04-21 05:03:51+00:00 - - - Anthony Towns 2022-04-21 02:36:00+00:00 - - - Buck O Perley 2022-04-20 17:13:19+00:00 - - - Nadav Ivgi 2022-04-20 17:05:36+00:00 - - - Anthony Towns 2022-04-20 02:31:07+00:00 - - - Jeremy Rubin 2022-02-22 03:19:23+00:00 - - - 0x0ff 2022-02-18 11:13:31+00:00 - - - Jeremy Rubin 2022-02-17 21:58:38+00:00 - + 2025-09-26T14:33:59.062298+00:00 + python-feedgen + + + [bitcoin-dev] CTV Signet Parameters Jeremy Rubin + 2022-02-17T21:58:00.000Z + + + 0x0ff + 2022-02-18T11:13:00.000Z + + + Jeremy Rubin + 2022-02-22T03:19:00.000Z + + + Anthony Towns + 2022-04-20T02:31:00.000Z + + + Nadav Ivgi + 2022-04-20T17:05:00.000Z + + + Buck O Perley + 2022-04-20T17:13:00.000Z + + + Anthony Towns + 2022-04-21T02:36:00.000Z + + + Anthony Towns + 2022-04-21T05:03:00.000Z + + + Jeremy Rubin + 2022-04-21T06:16:00.000Z + + + Jeremy Rubin + 2022-04-21T06:25:00.000Z + + + Russell O'Connor + 2022-04-21T13:22:00.000Z + + + Jeremy Rubin + 2022-04-21T15:05:00.000Z + + + Anthony Towns + 2022-04-22T00:58:00.000Z + + + Nadav Ivgi + 2022-04-22T01:10:00.000Z + + + Jeremy Rubin + 2022-04-22T05:30:00.000Z + + + Jeremy Rubin + 2022-04-28T12:23:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - CTV Signet Parameters - 2023-08-02T05:39:40.984135+00:00 + 2025-09-26T14:33:59.064092+00:00 - In a discussion on the Bitcoin scripting language, a member raised a question about the necessity of using DROP/1 when leaving a 32-byte hash on the stack. Another member clarified that it may not necessarily mean everyone is using Sapio to construct transactions, but they may be using sapio-miniscript or a different miniscript implementation compatible with sapio-miniscript's CTV fragment. The use of miniscript seems different than using Sapio, but the underlying point of the discussion remains unchanged.The conversation then shifted to the potential benefits of using bare CTV over segwit v0/v1. It was noted that bare CTV can save 34 or 67 bytes per histogram bucket, allowing for more buckets and greater feerate savings. Binning into 5 groups yields a higher feerate discount compared to binning into 4 groups. However, the knock-on effects of these changes are difficult to predict accurately. The cheapness of nodes in the graph can change the optimal graph and make simple comparisons inadequate. Bugs like nonstandard broadcasting would be fixed through testing, and the proposed changes are still in the "interesting thought experiment" stage.Regarding the use of bare CTV, it was mentioned that it only saves bytes when spending, and an extra 34 or 67 bytes of witness data is fairly immaterial. Real user data suggests that nobody will benefit from using bare CTV. Upgrading old hardware may be necessary to support new features. The potential benefits of using segwit v0 CTV for users with hardware modules or MPC Threshold Crypto that only support ECDSA signatures were also discussed.In the discussion on the bitcoin-dev mailing list, various participants shared their thoughts on the use of bare CTV in different contexts. Testing was emphasized as a crucial step in identifying bugs and ensuring consistency with proposed consensus and policy rules. The benefits of bare CTV were explored, including its potential to save space when batching transactions for customers with different fee priority levels. However, it was noted that real user data suggests that nobody will benefit from using bare CTV. The possibility of using OP_SUCCESSx in segwitv0 CTV was discussed, but it was concluded that upgrading old hardware may be necessary to support new features.The discussion on Consensus-enforced Transaction Verification (CTV) in Bitcoin highlighted the importance of testing and demonstrating major use cases before implementing new features. While there are working prototypes of CTV's use cases, they are not yet production-ready. The potential benefits of CTV were explored, such as combining batches into a root and N batch outputs, eliminating the need for inputs, signatures, and change outputs per batch. However, the limitations and additional blockspace usage of bare-CTV were questioned. The use of an OP_SUCCESS code from tapscript instead of bare-CTV was suggested as a better alternative. The justification for bare-CTV and its limitations were further discussed.A recent email thread focused on the testing and implementation of new feature proposals. The criteria for soft-forking a proposal into consensus code were discussed, emphasizing the need for real-life use cases and sufficient testing. CheckTemplateVerify (CTV), a feature enabling more complex smart contracts, was examined. While there are prototypes of CTV's major use cases, they are not yet production-ready. Sapio was highlighted as an example of CTV's versatility. The discussion also touched on other proposed features such as eltoo and TLUV, noting their current status and design considerations. It was suggested that consensus should not be rushed until use cases are fully fleshed out and demonstrated.In a bitcoin-dev post, the importance of decision making and testing before implementing changes was emphasized. The significance of hard numbers and clear metrics for evaluating proposals was questioned. The readiness and eagerness to use CheckTemplateVerify (CTV) and Taproot were compared. The usefulness of bare-CTV and its limitations were discussed, along with alternative options like using an OP_SUCCESS code from tapscript. The writer suggested defining clear metrics for evaluating proposals to facilitate decision making.In a discussion on the bitcoin-dev mailing list, a member questioned the necessity of DROP/1 in a specific context. Another participant explained that with Taproot's CLEANSTACK rule, leaving the 32-byte hash on the stack would not evaluate as true. The conversation also touched on the use of CastToBool() function in tapscript and the relevance of the MINIMALIF rule to CTV.Overall, the discussions revolve around the potential benefits, limitations, and testing of Consensus-enforced Transaction Verification (CTV) in Bitcoin. Various perspectives on the use of bare CTV, alternative implementations, and the need for clear metrics are presented.In a recent email thread on the bitcoin-dev mailing list, the lack of practical experimentation with CheckTemplateVerify (CTV) was discussed. Anthony Towns highlighted that there had been over 2,200 transactions on the CTV signet, but 2022-04-28T12:23:32+00:00 + In a discussion on the Bitcoin scripting language, a member raised a question about the necessity of using DROP/1 when leaving a 32-byte hash on the stack. Another member clarified that it may not necessarily mean everyone is using Sapio to construct transactions, but they may be using sapio-miniscript or a different miniscript implementation compatible with sapio-miniscript's CTV fragment. The use of miniscript seems different than using Sapio, but the underlying point of the discussion remains unchanged.The conversation then shifted to the potential benefits of using bare CTV over segwit v0/v1. It was noted that bare CTV can save 34 or 67 bytes per histogram bucket, allowing for more buckets and greater feerate savings. Binning into 5 groups yields a higher feerate discount compared to binning into 4 groups. However, the knock-on effects of these changes are difficult to predict accurately. The cheapness of nodes in the graph can change the optimal graph and make simple comparisons inadequate. Bugs like nonstandard broadcasting would be fixed through testing, and the proposed changes are still in the "interesting thought experiment" stage.Regarding the use of bare CTV, it was mentioned that it only saves bytes when spending, and an extra 34 or 67 bytes of witness data is fairly immaterial. Real user data suggests that nobody will benefit from using bare CTV. Upgrading old hardware may be necessary to support new features. The potential benefits of using segwit v0 CTV for users with hardware modules or MPC Threshold Crypto that only support ECDSA signatures were also discussed.In the discussion on the bitcoin-dev mailing list, various participants shared their thoughts on the use of bare CTV in different contexts. Testing was emphasized as a crucial step in identifying bugs and ensuring consistency with proposed consensus and policy rules. The benefits of bare CTV were explored, including its potential to save space when batching transactions for customers with different fee priority levels. However, it was noted that real user data suggests that nobody will benefit from using bare CTV. The possibility of using OP_SUCCESSx in segwitv0 CTV was discussed, but it was concluded that upgrading old hardware may be necessary to support new features.The discussion on Consensus-enforced Transaction Verification (CTV) in Bitcoin highlighted the importance of testing and demonstrating major use cases before implementing new features. While there are working prototypes of CTV's use cases, they are not yet production-ready. The potential benefits of CTV were explored, such as combining batches into a root and N batch outputs, eliminating the need for inputs, signatures, and change outputs per batch. However, the limitations and additional blockspace usage of bare-CTV were questioned. The use of an OP_SUCCESS code from tapscript instead of bare-CTV was suggested as a better alternative. The justification for bare-CTV and its limitations were further discussed.A recent email thread focused on the testing and implementation of new feature proposals. The criteria for soft-forking a proposal into consensus code were discussed, emphasizing the need for real-life use cases and sufficient testing. CheckTemplateVerify (CTV), a feature enabling more complex smart contracts, was examined. While there are prototypes of CTV's major use cases, they are not yet production-ready. Sapio was highlighted as an example of CTV's versatility. The discussion also touched on other proposed features such as eltoo and TLUV, noting their current status and design considerations. It was suggested that consensus should not be rushed until use cases are fully fleshed out and demonstrated.In a bitcoin-dev post, the importance of decision making and testing before implementing changes was emphasized. The significance of hard numbers and clear metrics for evaluating proposals was questioned. The readiness and eagerness to use CheckTemplateVerify (CTV) and Taproot were compared. The usefulness of bare-CTV and its limitations were discussed, along with alternative options like using an OP_SUCCESS code from tapscript. The writer suggested defining clear metrics for evaluating proposals to facilitate decision making.In a discussion on the bitcoin-dev mailing list, a member questioned the necessity of DROP/1 in a specific context. Another participant explained that with Taproot's CLEANSTACK rule, leaving the 32-byte hash on the stack would not evaluate as true. The conversation also touched on the use of CastToBool() function in tapscript and the relevance of the MINIMALIF rule to CTV.Overall, the discussions revolve around the potential benefits, limitations, and testing of Consensus-enforced Transaction Verification (CTV) in Bitcoin. Various perspectives on the use of bare CTV, alternative implementations, and the need for clear metrics are presented.In a recent email thread on the bitcoin-dev mailing list, the lack of practical experimentation with CheckTemplateVerify (CTV) was discussed. Anthony Towns highlighted that there had been over 2,200 transactions on the CTV signet, but - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml b/static/bitcoin-dev/April_2022/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml index 9af850445d..e25e71ac22 100644 --- a/static/bitcoin-dev/April_2022/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml +++ b/static/bitcoin-dev/April_2022/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Conjectures on solving the high interactivity issue in payment pools and channel factories - 2023-08-02T06:18:48.419381+00:00 - - Antoine Riard 2023-04-18 03:38:57+00:00 - - - jlspc 2023-03-17 20:54:51+00:00 - - - Billy Tetrud 2022-05-12 17:36:25+00:00 - - - ZmnSCPxj 2022-05-10 16:45:19+00:00 - - - Antoine Riard 2022-05-10 00:38:36+00:00 - - - Billy Tetrud 2022-05-01 22:53:13+00:00 - - - Antoine Riard 2022-04-28 13:18:05+00:00 - + 2025-09-26T14:33:33.281903+00:00 + python-feedgen + + + [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories Antoine Riard + 2022-04-28T13:18:00.000Z + + + Billy Tetrud + 2022-05-01T22:53:00.000Z + + + Antoine Riard + 2022-05-10T00:38:00.000Z + + + ZmnSCPxj + 2022-05-10T16:45:00.000Z + + + Billy Tetrud + 2022-05-12T17:36:00.000Z + + + jlspc + 2023-03-17T20:54:00.000Z + + + Antoine Riard + 2023-04-18T03:38:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Conjectures on solving the high interactivity issue in payment pools and channel factories - 2023-08-02T06:18:48.420890+00:00 + 2025-09-26T14:33:33.282784+00:00 - The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels. 2023-04-18T03:38:57+00:00 + The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_MuSig2-BIP.xml b/static/bitcoin-dev/April_2022/combined_MuSig2-BIP.xml index 74cf7342a4..fa3d0d0463 100644 --- a/static/bitcoin-dev/April_2022/combined_MuSig2-BIP.xml +++ b/static/bitcoin-dev/April_2022/combined_MuSig2-BIP.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 - - Jonas Nick 2022-11-03 14:43:22+00:00 - - - Jonas Nick 2022-10-11 15:34:23+00:00 - - - Jonas Nick 2022-10-03 20:41:08+00:00 - - - AdamISZ 2022-06-12 23:07:08+00:00 - - - AdamISZ 2022-05-26 17:34:47+00:00 - - - Jonas Nick 2022-05-26 15:32:33+00:00 - - - AdamISZ 2022-05-24 19:06:41+00:00 - - - AdamISZ 2022-05-23 22:09:52+00:00 - - - Jonas Nick 2022-05-23 15:56:54+00:00 - - - AdamISZ 2022-05-22 22:26:08+00:00 - - - Jonas Nick 2022-04-28 19:18:34+00:00 - - - Brandon Black 2022-04-28 15:33:42+00:00 - - - Olaoluwa Osuntokun 2022-04-28 03:53:59+00:00 - - - Olaoluwa Osuntokun 2022-04-28 01:47:33+00:00 - - - Jonas Nick 2022-04-05 22:57:13+00:00 - + 2025-09-26T14:33:50.457636+00:00 + python-feedgen + + + [bitcoin-dev] MuSig2 BIP Jonas Nick + 2022-04-05T22:57:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T01:47:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T03:53:00.000Z + + + Brandon Black + 2022-04-28T15:33:00.000Z + + + Jonas Nick + 2022-04-28T19:18:00.000Z + + + AdamISZ + 2022-05-22T22:26:00.000Z + + + Jonas Nick + 2022-05-23T15:56:00.000Z + + + AdamISZ + 2022-05-23T22:09:00.000Z + + + AdamISZ + 2022-05-24T19:06:00.000Z + + + Jonas Nick + 2022-05-26T15:32:00.000Z + + + AdamISZ + 2022-05-26T17:34:00.000Z + + + AdamISZ + 2022-06-12T23:07:00.000Z + + + Jonas Nick + 2022-10-03T20:41:00.000Z + + + Jonas Nick + 2022-10-11T15:34:00.000Z + + + Jonas Nick + 2022-11-03T14:43:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 + 2025-09-26T14:33:50.459329+00:00 - The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary 2022-11-03T14:43:22+00:00 + The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Multiple-ways-to-do-bitcoin-covenants.xml b/static/bitcoin-dev/April_2022/combined_Multiple-ways-to-do-bitcoin-covenants.xml index 29731ee6d4..367f3dfc01 100644 --- a/static/bitcoin-dev/April_2022/combined_Multiple-ways-to-do-bitcoin-covenants.xml +++ b/static/bitcoin-dev/April_2022/combined_Multiple-ways-to-do-bitcoin-covenants.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Multiple ways to do bitcoin covenants - 2023-08-02T06:18:07.113596+00:00 - - Billy Tetrud 2022-05-01 23:02:55+00:00 - - - alicexbt 2022-04-28 08:11:28+00:00 - + 2025-09-26T14:33:39.667876+00:00 + python-feedgen + + + [bitcoin-dev] Multiple ways to do bitcoin covenants alicexbt + 2022-04-28T08:11:00.000Z + + + Billy Tetrud + 2022-05-01T23:02:00.000Z + + - python-feedgen + 2 Combined summary - Multiple ways to do bitcoin covenants - 2023-08-02T06:18:07.113596+00:00 + 2025-09-26T14:33:39.668323+00:00 - The author of the context has been analyzing various covenant proposals with a focus on wallet vaults. Among the options discussed, CTV (Covenant Transaction Verification) is considered as the minimal covenant opcode that addresses malleability issues. Other proposed opcodes have potential undesirable effects when interacting with existing systems. Another option, TXHASH+CSFS, offers similar capabilities to CTV but is more complex due to additional features. APO wallet vaults are deemed hacky, inefficient, and limited in their functionality. TLUV + IN_OUT_AMOUNT allows for infinitely recursive covenants, but it has limitations with multi-input transactions. OP_CHECKOUTPUTVERIFY is an interesting opcode that enables recursive covenants but shares similar limitations as TLUV + IN_OUT_AMOUNT with multi-input transactions, and it also incurs high costs beyond simple covenants. While some of these covenant opcodes have been specified and analyzed to some extent, none except CTV (potentially TXHASH+CSFS) seem to be of sufficient quality to be implemented in Bitcoin in their current state. The author favors CTV due to its simplicity, efficiency in block space usage, and the ability to be utilized even without taproot.However, it is acknowledged that different developers may have preferences for alternative methods of implementing Bitcoin covenants for various reasons. Recent discussions and explorations have centered around CTV and other covenant proposals. One question raised was whether Bitcoin already has opcodes with overlapping features, and the answer is affirmative. It is indeed possible to have multiple ways to achieve Bitcoin covenants with some tradeoffs.The author also questions the tradeoffs between CTV, APO, TLUV, and TXHASH+CSFS. While the first question received answers from Jeremy and sheshek in the CTV chat, there is no clear consensus regarding the second question.When comparing the different options, the author reiterates their preference for CTV due to its simplicity, block space efficiency, and ability to be used independently of taproot. It is important to consider bare script to expose a public key in the case of an EC (Elliptic Curve) break, as relying solely on vaults can lead to potential vulnerabilities. Additionally, with the growing prevalence of quantum computing, it is unsustainable to force everyone into a quantum-unsafe position.However, it is acknowledged that other developers may have different preferences for implementing Bitcoin covenants. For example, Russel O'Connor favors the general OP_TXHASH design. 2022-05-01T23:02:55+00:00 + The author of the context has been analyzing various covenant proposals with a focus on wallet vaults. Among the options discussed, CTV (Covenant Transaction Verification) is considered as the minimal covenant opcode that addresses malleability issues. Other proposed opcodes have potential undesirable effects when interacting with existing systems. Another option, TXHASH+CSFS, offers similar capabilities to CTV but is more complex due to additional features. APO wallet vaults are deemed hacky, inefficient, and limited in their functionality. TLUV + IN_OUT_AMOUNT allows for infinitely recursive covenants, but it has limitations with multi-input transactions. OP_CHECKOUTPUTVERIFY is an interesting opcode that enables recursive covenants but shares similar limitations as TLUV + IN_OUT_AMOUNT with multi-input transactions, and it also incurs high costs beyond simple covenants. While some of these covenant opcodes have been specified and analyzed to some extent, none except CTV (potentially TXHASH+CSFS) seem to be of sufficient quality to be implemented in Bitcoin in their current state. The author favors CTV due to its simplicity, efficiency in block space usage, and the ability to be utilized even without taproot.However, it is acknowledged that different developers may have preferences for alternative methods of implementing Bitcoin covenants for various reasons. Recent discussions and explorations have centered around CTV and other covenant proposals. One question raised was whether Bitcoin already has opcodes with overlapping features, and the answer is affirmative. It is indeed possible to have multiple ways to achieve Bitcoin covenants with some tradeoffs.The author also questions the tradeoffs between CTV, APO, TLUV, and TXHASH+CSFS. While the first question received answers from Jeremy and sheshek in the CTV chat, there is no clear consensus regarding the second question.When comparing the different options, the author reiterates their preference for CTV due to its simplicity, block space efficiency, and ability to be used independently of taproot. It is important to consider bare script to expose a public key in the case of an EC (Elliptic Curve) break, as relying solely on vaults can lead to potential vulnerabilities. Additionally, with the growing prevalence of quantum computing, it is unsustainable to force everyone into a quantum-unsafe position.However, it is acknowledged that other developers may have different preferences for implementing Bitcoin covenants. For example, Russel O'Connor favors the general OP_TXHASH design. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Simple-step-one-for-quantum.xml b/static/bitcoin-dev/April_2022/combined_Simple-step-one-for-quantum.xml index a4b2c15d20..881b8a9dc6 100644 --- a/static/bitcoin-dev/April_2022/combined_Simple-step-one-for-quantum.xml +++ b/static/bitcoin-dev/April_2022/combined_Simple-step-one-for-quantum.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Simple step one for quantum - 2023-08-02T06:07:49.025580+00:00 - - Erik Aronesty 2022-04-11 18:17:22+00:00 - - - Olaoluwa Osuntokun 2022-04-11 18:07:29+00:00 - - - Lloyd Fournier 2022-04-09 21:40:38+00:00 - - - Christopher Allen 2022-04-08 23:35:57+00:00 - - - Christopher Allen 2022-04-08 23:33:24+00:00 - - - Erik Aronesty 2022-04-08 21:34:07+00:00 - + 2025-09-26T14:33:31.134419+00:00 + python-feedgen + + + [bitcoin-dev] Simple step one for quantum Erik Aronesty + 2022-04-08T21:34:00.000Z + + + Christopher Allen + 2022-04-08T23:33:00.000Z + + + Christopher Allen + 2022-04-08T23:35:00.000Z + + + Lloyd Fournier + 2022-04-09T21:40:00.000Z + + + Olaoluwa Osuntokun + 2022-04-11T18:07:00.000Z + + + Erik Aronesty + 2022-04-11T18:17:00.000Z + + - python-feedgen + 2 Combined summary - Simple step one for quantum - 2023-08-02T06:07:49.025580+00:00 + 2025-09-26T14:33:31.135247+00:00 - A recent discussion on the bitcoin-dev mailing list has proposed implementing a new address type that would be quantum safe. The suggested address type would combine secp256k1 and NTRU Prime, a post-quantum cryptography algorithm. While there are patent controversies surrounding NTRU Prime, a patent-free version called "sntrup" exists. The discussion also suggests adding a fee premium for using these addresses to address concerns about extra validation work for nodes. However, it is noted that this proposal may be premature as the results of the NIST Post-Quantum Cryptography competition have not been published yet.The NIST competition results are expected to be published by the end of April, with both NTRU and NTRU Prime making it to round three. However, there is some patent controversy associated with these algorithms. Erik Aronesty from bitcoin-dev has suggested implementing a similar address type and validation as a soft fork, allowing users to opt-in to quantum safe addresses. This approach would require additional work and validation for nodes, leading to the suggestion of adding a fee premium for using these addresses. While opinions on this idea differ, some believe it is too early to consider such measures.To address the issue of designing a PQ TR commitment in each key, a member of the Bitcoin community proposed creating a problem page on bitcoinproblems.org. This page would allow for a soft fork to enable spends in the event of quantum computing becoming a reality. The author/maintainer of the problem can be anyone who makes a PR to the repository, and the problem doesn't necessarily have to focus on a TR solution but could describe the problem with potential solution directions. Christopher Allen provided links to related resources, including a website and an academic paper.Christopher Allen also shared a link related to interesting research on quantum-safe approaches. The link provides information on software related to NTRU Prime. Additionally, he shared what he believes to be the original academic paper on the topic.In an email thread, Erik Aronesty expressed his opinion that quantum attacks are not a concern in the near future, comparing them to other technologies always "20 years away." While there have been reported approaches to quantum-attack resistance, many have fallen and more will likely fall in the next "20 years." Despite this, Christopher Allen found the research interesting and provided a link to the best approach. Blockchain Commons is willing to contribute a small grant if others fund the research.The proposal suggests implementing a similar address type and validation as a soft fork, followed by allowing people to opt-in to quantum safe addresses. It is acknowledged that this would require significant work and extra validation for nodes. To address this concern, adding a fee premium for using these addresses is considered reasonable. The writer does not endorse any action at this time, recognizing that it may be premature, but expresses willingness to create an NTRU bip or similar if there is sufficient support for the idea. This proposal was found on the OpenSSH release notes website. 2022-04-11T18:17:22+00:00 + A recent discussion on the bitcoin-dev mailing list has proposed implementing a new address type that would be quantum safe. The suggested address type would combine secp256k1 and NTRU Prime, a post-quantum cryptography algorithm. While there are patent controversies surrounding NTRU Prime, a patent-free version called "sntrup" exists. The discussion also suggests adding a fee premium for using these addresses to address concerns about extra validation work for nodes. However, it is noted that this proposal may be premature as the results of the NIST Post-Quantum Cryptography competition have not been published yet.The NIST competition results are expected to be published by the end of April, with both NTRU and NTRU Prime making it to round three. However, there is some patent controversy associated with these algorithms. Erik Aronesty from bitcoin-dev has suggested implementing a similar address type and validation as a soft fork, allowing users to opt-in to quantum safe addresses. This approach would require additional work and validation for nodes, leading to the suggestion of adding a fee premium for using these addresses. While opinions on this idea differ, some believe it is too early to consider such measures.To address the issue of designing a PQ TR commitment in each key, a member of the Bitcoin community proposed creating a problem page on bitcoinproblems.org. This page would allow for a soft fork to enable spends in the event of quantum computing becoming a reality. The author/maintainer of the problem can be anyone who makes a PR to the repository, and the problem doesn't necessarily have to focus on a TR solution but could describe the problem with potential solution directions. Christopher Allen provided links to related resources, including a website and an academic paper.Christopher Allen also shared a link related to interesting research on quantum-safe approaches. The link provides information on software related to NTRU Prime. Additionally, he shared what he believes to be the original academic paper on the topic.In an email thread, Erik Aronesty expressed his opinion that quantum attacks are not a concern in the near future, comparing them to other technologies always "20 years away." While there have been reported approaches to quantum-attack resistance, many have fallen and more will likely fall in the next "20 years." Despite this, Christopher Allen found the research interesting and provided a link to the best approach. Blockchain Commons is willing to contribute a small grant if others fund the research.The proposal suggests implementing a similar address type and validation as a soft fork, followed by allowing people to opt-in to quantum safe addresses. It is acknowledged that this would require significant work and extra validation for nodes. To address this concern, adding a fee premium for using these addresses is considered reasonable. The writer does not endorse any action at this time, recognizing that it may be premature, but expresses willingness to create an NTRU bip or similar if there is sufficient support for the idea. This proposal was found on the OpenSSH release notes website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Speedy-Trial.xml b/static/bitcoin-dev/April_2022/combined_Speedy-Trial.xml index 5765b9f371..42faedeb0a 100644 --- a/static/bitcoin-dev/April_2022/combined_Speedy-Trial.xml +++ b/static/bitcoin-dev/April_2022/combined_Speedy-Trial.xml @@ -1,167 +1,223 @@ - + 2 Combined summary - Speedy Trial - 2023-08-02T05:53:16.831910+00:00 - - Billy Tetrud 2022-04-27 02:35:49+00:00 - - - Erik Aronesty 2022-04-26 13:05:56+00:00 - - - Anthony Towns 2022-04-26 05:42:14+00:00 - - - Keagan McClelland 2022-04-25 17:26:09+00:00 - - - Anthony Towns 2022-04-25 17:00:12+00:00 - - - Keagan McClelland 2022-04-25 16:11:45+00:00 - - - Jorge Timón 2022-04-24 12:44:16+00:00 - - - Anthony Towns 2022-04-24 12:14:29+00:00 - - - Jorge Timón 2022-04-24 11:13:08+00:00 - - - Anthony Towns 2022-04-11 13:05:22+00:00 - - - Jorge Timón 2022-04-08 09:58:48+00:00 - - - pushd 2022-03-31 15:55:49+00:00 - - - Billy Tetrud 2022-03-31 15:34:26+00:00 - - - pushd 2022-03-31 14:19:36+00:00 - - - Billy Tetrud 2022-03-31 04:31:09+00:00 - - - pushd 2022-03-30 21:14:16+00:00 - - - Billy Tetrud 2022-03-30 20:10:49+00:00 - - - pushd 2022-03-30 10:34:45+00:00 - - - Anthony Towns 2022-03-30 04:21:06+00:00 - - - Jorge Timón 2022-03-28 08:31:18+00:00 - - - pushd 2022-03-26 12:59:12+00:00 - - - Anthony Towns 2022-03-26 01:45:46+00:00 - - - Jorge Timón 2022-03-24 18:30:09+00:00 - - - Kate Salazar 2022-03-23 22:34:21+00:00 - - - Anthony Towns 2022-03-22 23:49:51+00:00 - - - vjudeu at gazeta.pl 2022-03-22 16:37:01+00:00 - - - Eric Voskuil 2022-03-22 15:45:55+00:00 - - - Billy Tetrud 2022-03-22 15:19:30+00:00 - - - vjudeu at gazeta.pl 2022-03-21 15:56:03+00:00 - - - Billy Tetrud 2022-03-21 03:41:42+00:00 - - - vjudeu at gazeta.pl 2022-03-19 16:43:42+00:00 - - - ZmnSCPxj 2022-03-18 23:01:43+00:00 - - - Jorge Timón 2022-03-18 18:36:03+00:00 - - - Billy Tetrud 2022-03-17 15:38:53+00:00 - - - pushd 2022-03-17 14:34:49+00:00 - - - Jorge Timón 2022-03-17 14:04:32+00:00 - - - Jorge Timón 2022-03-17 12:18:11+00:00 - - - Jorge Timón 2022-03-17 12:08:25+00:00 - - - Jorge Timón 2022-03-17 11:32:24+00:00 - - - Billy Tetrud 2022-03-17 04:17:20+00:00 - - - Jeremy Rubin 2022-03-15 17:21:29+00:00 - - - Anthony Towns 2022-03-15 15:45:49+00:00 - - - Billy Tetrud 2022-03-12 17:52:59+00:00 - - - pushd 2022-03-12 17:11:29+00:00 - - - Russell O'Connor 2022-03-12 13:34:59+00:00 - - - Billy Tetrud 2022-03-11 16:26:21+00:00 - - - Jorge Timón 2022-03-11 14:04:29+00:00 - - - Russell O'Connor 2022-03-11 13:47:14+00:00 - - - Jorge Timón 2022-03-11 12:19:36+00:00 - - - pushd 2022-03-11 11:14:33+00:00 - - - Billy Tetrud 2022-03-11 05:41:58+00:00 - - - Luke Dashjr 2022-03-11 00:28:08+00:00 - - - Russell O'Connor 2022-03-11 00:12:19+00:00 - + 2025-09-26T14:33:41.856160+00:00 + python-feedgen + + + [bitcoin-dev] Speedy Trial Russell O'Connor + 2022-03-11T00:12:00.000Z + + + Luke Dashjr + 2022-03-11T00:28:00.000Z + + + Billy Tetrud + 2022-03-11T05:41:00.000Z + + + pushd + 2022-03-11T11:14:00.000Z + + + Jorge Timón + 2022-03-11T12:19:00.000Z + + + Russell O'Connor + 2022-03-11T13:47:00.000Z + + + Jorge Timón + 2022-03-11T14:04:00.000Z + + + Billy Tetrud + 2022-03-11T16:26:00.000Z + + + Russell O'Connor + 2022-03-12T13:34:00.000Z + + + pushd + 2022-03-12T17:11:00.000Z + + + Billy Tetrud + 2022-03-12T17:52:00.000Z + + + Anthony Towns + 2022-03-15T15:45:00.000Z + + + Jeremy Rubin + 2022-03-15T17:21:00.000Z + + + Billy Tetrud + 2022-03-17T04:17:00.000Z + + + Jorge Timón + 2022-03-17T11:32:00.000Z + + + Jorge Timón + 2022-03-17T12:08:00.000Z + + + Jorge Timón + 2022-03-17T12:18:00.000Z + + + Jorge Timón + 2022-03-17T14:04:00.000Z + + + pushd + 2022-03-17T14:34:00.000Z + + + Billy Tetrud + 2022-03-17T15:38:00.000Z + + + Jorge Timón + 2022-03-18T18:36:00.000Z + + + ZmnSCPxj + 2022-03-18T23:01:00.000Z + + + vjudeu + 2022-03-19T16:43:00.000Z + + + Billy Tetrud + 2022-03-21T03:41:00.000Z + + + vjudeu + 2022-03-21T15:56:00.000Z + + + Billy Tetrud + 2022-03-22T15:19:00.000Z + + + Eric Voskuil + 2022-03-22T15:45:00.000Z + + + vjudeu + 2022-03-22T16:37:00.000Z + + + Anthony Towns + 2022-03-22T23:49:00.000Z + + + Kate Salazar + 2022-03-23T22:34:00.000Z + + + Jorge Timón + 2022-03-24T18:30:00.000Z + + + Anthony Towns + 2022-03-26T01:45:00.000Z + + + pushd + 2022-03-26T12:59:00.000Z + + + Jorge Timón + 2022-03-28T08:31:00.000Z + + + Anthony Towns + 2022-03-30T04:21:00.000Z + + + pushd + 2022-03-30T10:34:00.000Z + + + Billy Tetrud + 2022-03-30T20:10:00.000Z + + + pushd + 2022-03-30T21:14:00.000Z + + + Billy Tetrud + 2022-03-31T04:31:00.000Z + + + pushd + 2022-03-31T14:19:00.000Z + + + Billy Tetrud + 2022-03-31T15:34:00.000Z + + + pushd + 2022-03-31T15:55:00.000Z + + + Jorge Timón + 2022-04-08T09:58:00.000Z + + + Anthony Towns + 2022-04-11T13:05:00.000Z + + + Jorge Timón + 2022-04-24T11:13:00.000Z + + + Anthony Towns + 2022-04-24T12:14:00.000Z + + + Jorge Timón + 2022-04-24T12:44:00.000Z + + + Keagan McClelland + 2022-04-25T16:11:00.000Z + + + Anthony Towns + 2022-04-25T17:00:00.000Z + + + Keagan McClelland + 2022-04-25T17:26:00.000Z + + + Anthony Towns + 2022-04-26T05:42:00.000Z + + + Erik Aronesty + 2022-04-26T13:05:00.000Z + + + Billy Tetrud + 2022-04-27T02:35:00.000Z + + @@ -215,13 +271,13 @@ - python-feedgen + 2 Combined summary - Speedy Trial - 2023-08-02T05:53:16.832917+00:00 + 2025-09-26T14:33:41.861646+00:00 - In the ongoing discussion within the Bitcoin community, consensus-building methods are being evaluated. Some propose setting specific criteria for determining consensus and involving non-developer stakeholders in the decision-making process. Ideas such as wallet votes and coin-weighted polling are being considered, but concerns about centralization pressures have been raised.On the technical side, there are questions regarding how nodes decide which blocks to orphan when only some of them need to signal. It has been clarified that in a semi-mandatory signaling system like BIP8, only "threshold" blocks are required to signal. If only a small percentage of miners fail to signal and the threshold is set high enough, no blocks will be orphaned. However, if any block would cause the entire threshold period to fail, it will be orphaned.The debate on whether miners or users should lead in decision-making continues, with the agreement that users ultimately lead and miners need to be prepared to upgrade their software. The concept of "evil" forks and the defense of Bitcoin against them is questioned, as defending against a fallacy of reification is not necessary. Systematically measuring user consensus without resorting to gaming the system or centralization is deemed challenging.Discussions between Anthony Towns and Jorge Timón delve into the advantages and disadvantages of bip8 and speedy trial. Towns argues that bip8 is not superior to speedy trial for activating bad soft forks, while Timón emphasizes the importance of considering user resistance. Keagan also points out that bip8 lacks mandatory signaling during the lock-in period, which makes it more difficult to counter a soft fork.Email exchanges between Towns and Timón further explore the topic of bip8 activation for bad soft forks. Towns maintains that bip8 is never superior to speedy trial, except when miners correctly identify a bad fork. Timón expresses frustration at feeling ignored, leading to the abrupt end of the conversation.The conversation expands to include other participants, discussing scenarios where bip8 fails compared to speedy trial. Timón presents hypothetical situations where bip8 with lot=true would activate an evil fork while speedy trial would block it. Towns argues that bip8 is designed for activating good proposals and that flawed ones should be stopped during the review process. The discussion becomes confrontational, with Timón accusing Towns of not understanding his points. Despite attempts at resolution, the conversation ends with Timón deciding to cease communication on the matter.Pushd raises concerns about the misconception that Bitcoin soft fork upgrades are decided by a majority vote of miners. They argue that this misunderstanding has been misused by mining pools in the past and creates a contentious environment. Billy Tetrud disagrees, suggesting that the solution lies in better explaining speedy trial to those who misunderstand it. Pushd counters by listing the downsides of this misunderstanding, including wasted time during the signaling period and giving miners an advantage over economic nodes. The need to address misconceptions and improve the understanding of soft fork activation mechanisms is emphasized.The discussion continues with a debate over whether changing the design or improving explanations is the solution to address the misconceptions. Different viewpoints are presented, with some advocating for a better activation method like BIP8/LOT=TRUE, while others argue for persistent explanation. The downsides of the current system, such as wasted time during signaling and the perception of voting, are highlighted. The conclusion emphasizes the importance of understanding the nuances of soft fork activation and finding ways to address any misconceptions.In a recent discussion on the bitcoin-dev mailing list, there is a debate about whether bitcoin upgrades are made based on miners' votes. While some argue that miners should have the power to approve changes, others believe that the confusion surrounding miner signaling and voting needs to be addressed through better explanations.The conversation explores different activation methods, including BIP 8/LOT=TRUE, which is seen as a simpler alternative. However, there are concerns about changing how Bitcoin is engineered for the sake of optics. Instead, it is suggested that explaining the speedy trial process more clearly can help prevent misunderstandings.The flaws in the speedy trial narrative are discussed, with concerns that it can mislead users into thinking that miner signaling is how Bitcoin upgrades are voted in. It is noted that flawed proposals making it through activation is a failure of the review process. The percentage of supermajority hashpower is decided by Bitcoin core developers, who can choose not to follow old or new consensus rules at any time.The conversation also touches on hypothetical scenarios, where someone being able to block a change is undesirable and could harm bitcoin. There is disagreement on whether solutions should allow blocking an evil fork, as it could also be used to block a good fork. The importance of rejecting bad premises and focusing on reasonable discussions is emphasized.In another thread, participants express their preferences for BIP 8's LOT parameter, citing its benefits of giving more power to users and reducing politics and controversies. The determination of an enemy or opposition in certain steps is questioned, and there is mention of parallel lines 2022-04-27T02:35:49+00:00 + In the ongoing discussion within the Bitcoin community, consensus-building methods are being evaluated. Some propose setting specific criteria for determining consensus and involving non-developer stakeholders in the decision-making process. Ideas such as wallet votes and coin-weighted polling are being considered, but concerns about centralization pressures have been raised.On the technical side, there are questions regarding how nodes decide which blocks to orphan when only some of them need to signal. It has been clarified that in a semi-mandatory signaling system like BIP8, only "threshold" blocks are required to signal. If only a small percentage of miners fail to signal and the threshold is set high enough, no blocks will be orphaned. However, if any block would cause the entire threshold period to fail, it will be orphaned.The debate on whether miners or users should lead in decision-making continues, with the agreement that users ultimately lead and miners need to be prepared to upgrade their software. The concept of "evil" forks and the defense of Bitcoin against them is questioned, as defending against a fallacy of reification is not necessary. Systematically measuring user consensus without resorting to gaming the system or centralization is deemed challenging.Discussions between Anthony Towns and Jorge Timón delve into the advantages and disadvantages of bip8 and speedy trial. Towns argues that bip8 is not superior to speedy trial for activating bad soft forks, while Timón emphasizes the importance of considering user resistance. Keagan also points out that bip8 lacks mandatory signaling during the lock-in period, which makes it more difficult to counter a soft fork.Email exchanges between Towns and Timón further explore the topic of bip8 activation for bad soft forks. Towns maintains that bip8 is never superior to speedy trial, except when miners correctly identify a bad fork. Timón expresses frustration at feeling ignored, leading to the abrupt end of the conversation.The conversation expands to include other participants, discussing scenarios where bip8 fails compared to speedy trial. Timón presents hypothetical situations where bip8 with lot=true would activate an evil fork while speedy trial would block it. Towns argues that bip8 is designed for activating good proposals and that flawed ones should be stopped during the review process. The discussion becomes confrontational, with Timón accusing Towns of not understanding his points. Despite attempts at resolution, the conversation ends with Timón deciding to cease communication on the matter.Pushd raises concerns about the misconception that Bitcoin soft fork upgrades are decided by a majority vote of miners. They argue that this misunderstanding has been misused by mining pools in the past and creates a contentious environment. Billy Tetrud disagrees, suggesting that the solution lies in better explaining speedy trial to those who misunderstand it. Pushd counters by listing the downsides of this misunderstanding, including wasted time during the signaling period and giving miners an advantage over economic nodes. The need to address misconceptions and improve the understanding of soft fork activation mechanisms is emphasized.The discussion continues with a debate over whether changing the design or improving explanations is the solution to address the misconceptions. Different viewpoints are presented, with some advocating for a better activation method like BIP8/LOT=TRUE, while others argue for persistent explanation. The downsides of the current system, such as wasted time during signaling and the perception of voting, are highlighted. The conclusion emphasizes the importance of understanding the nuances of soft fork activation and finding ways to address any misconceptions.In a recent discussion on the bitcoin-dev mailing list, there is a debate about whether bitcoin upgrades are made based on miners' votes. While some argue that miners should have the power to approve changes, others believe that the confusion surrounding miner signaling and voting needs to be addressed through better explanations.The conversation explores different activation methods, including BIP 8/LOT=TRUE, which is seen as a simpler alternative. However, there are concerns about changing how Bitcoin is engineered for the sake of optics. Instead, it is suggested that explaining the speedy trial process more clearly can help prevent misunderstandings.The flaws in the speedy trial narrative are discussed, with concerns that it can mislead users into thinking that miner signaling is how Bitcoin upgrades are voted in. It is noted that flawed proposals making it through activation is a failure of the review process. The percentage of supermajority hashpower is decided by Bitcoin core developers, who can choose not to follow old or new consensus rules at any time.The conversation also touches on hypothetical scenarios, where someone being able to block a change is undesirable and could harm bitcoin. There is disagreement on whether solutions should allow blocking an evil fork, as it could also be used to block a good fork. The importance of rejecting bad premises and focusing on reasonable discussions is emphasized.In another thread, participants express their preferences for BIP 8's LOT parameter, citing its benefits of giving more power to users and reducing politics and controversies. The determination of an enemy or opposition in certain steps is questioned, and there is mention of parallel lines - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml b/static/bitcoin-dev/April_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml index 04c7b66823..000c0cf0bf 100644 --- a/static/bitcoin-dev/April_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml +++ b/static/bitcoin-dev/April_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Taro: A Taproot Asset Representation Overlay - 2023-08-02T05:59:12.664244+00:00 - - Johan Torås Halseth 2022-11-07 13:51:12+00:00 - - - Olaoluwa Osuntokun 2022-11-05 00:35:53+00:00 - - - Johan Torås Halseth 2022-11-03 09:26:05+00:00 - - - Olaoluwa Osuntokun 2022-10-19 02:40:13+00:00 - - - Olaoluwa Osuntokun 2022-04-16 02:43:08+00:00 - - - Ruben Somsen 2022-04-15 13:14:40+00:00 - - - Bram Cohen 2022-04-11 21:29:31+00:00 - - - Olaoluwa Osuntokun 2022-04-11 19:51:55+00:00 - - - Olaoluwa Osuntokun 2022-04-11 18:21:14+00:00 - - - Bram Cohen 2022-04-11 00:30:29+00:00 - - - Ruben Somsen 2022-04-10 16:51:52+00:00 - - - Olaoluwa Osuntokun 2022-04-08 17:49:28+00:00 - - - Olaoluwa Osuntokun 2022-04-08 17:48:02+00:00 - - - Alex Schoof 2022-04-07 19:11:39+00:00 - - - Ruben Somsen 2022-04-07 17:14:03+00:00 - - - ZmnSCPxj 2022-04-06 00:43:23+00:00 - - - vjudeu at gazeta.pl 2022-04-05 20:23:05+00:00 - - - Olaoluwa Osuntokun 2022-04-05 15:06:03+00:00 - + 2025-09-26T14:33:48.308607+00:00 + python-feedgen + + + [bitcoin-dev] Taro: A Taproot Asset Representation Overlay Olaoluwa Osuntokun + 2022-04-05T15:06:00.000Z + + + [bitcoin-dev] " vjudeu + 2022-04-05T20:23:00.000Z + + + ZmnSCPxj + 2022-04-06T00:43:00.000Z + + + Ruben Somsen + 2022-04-07T17:14:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Alex Schoof + 2022-04-07T19:11:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2022-04-08T17:48:00.000Z + + + Olaoluwa Osuntokun + 2022-04-08T17:49:00.000Z + + + Ruben Somsen + 2022-04-10T16:51:00.000Z + + + Bram Cohen + 2022-04-11T00:30:00.000Z + + + Olaoluwa Osuntokun + 2022-04-11T18:21:00.000Z + + + Olaoluwa Osuntokun + 2022-04-11T19:51:00.000Z + + + Bram Cohen + 2022-04-11T21:29:00.000Z + + + Ruben Somsen + 2022-04-15T13:14:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2022-04-16T02:43:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Olaoluwa Osuntokun + 2022-10-19T02:40:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Johan Torås Halseth + 2022-11-03T09:26:00.000Z + + + Olaoluwa Osuntokun + 2022-11-05T00:35:00.000Z + + + Johan Torås Halseth + 2022-11-07T13:51:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Taro: A Taproot Asset Representation Overlay - 2023-08-02T05:59:12.664244+00:00 + 2025-09-26T14:33:48.310621+00:00 - During a discussion about the "utxo teleport" scheme, Johan and Olaoluwa express their opinions on its soundness and compatibility with LN channels. Johan believes that as long as tokens are not sent to a spent UTXO, the scheme is sound. However, he agrees with Olaoluwa's concern about losing the blockchain as the main synchronization point. Olaoluwa argues that the scheme may not be sound because the UTXO may no longer exist when the transaction hits the chain, and there is no total ordering for safety.In contrast, Taro's state transition model ensures everything is bound to a single synchronization point and has re-org safety traits like regular Bitcoin transactions. Olaoluwa also points out that the "utxo teleport" scheme is not ideal for anchoring assets in channels. With Taro, assets are committed to the funding output when the channel is created, providing better visibility. Additionally, the "utxo teleport" scheme requires additional synchronization, while Taro creates an on-chain taproot output that directly creates the new asset anchor/output. The sender and receiver can use the blockchain itself as a synchronization point.Johan suggests adding a "teleport" feature to Taro, which would allow token transfer to already spent TXOs, burning the tokens. This feature could be beneficial for LN channels, enabling the addition or topping up of tokens in open channels with proof of token transfer.Ruben raises concerns about the RGB protocol, which he believes apply to Taro as well. He notes that the Taro script is not enforced by Bitcoin, so those controlling the Bitcoin script can choose to ignore the Taro script and destroy Taro assets. However, Ruben acknowledges that Taro's design predates RGB and seems to have inspired it.The email exchange discusses issues with verifying asset provenance in Taro's specifications. Hiroki Gondo points out the possibility of asset inflation if an illicit copy of a UTXO is created in the asset tree. Laolu acknowledges the issue and mentions that they aim to address it by assuming a "no-op" state transition in the current spec. Gondo suggests setting a constraint that only explicitly changed UTXOs should change, rather than generating proofs for every unchanging UTXO.Olaoluwa announces the Taro protocol, which uses the Taproot script tree and MS-SMT hybrid merkle tree for tokenization and asset issuance on the Bitcoin chain. They mention that Taro supports Lightning Network integration and efficient proofs of non-existence.The email exchange explores the feasibility of adding a scripting language to Taro. Ruben argues that using Bitcoin script without an additional scripting language inside Taro is sufficient. Olaoluwa proposes an "issuance covenant" design sketch for certain collateralization requirements, which Ruben acknowledges could be useful. They also discuss the deterministic location of the Taro tree in the taproot tree and propose solutions.In another email exchange, Bram Cohen and Olaoluwa discuss witnesses in transactions and the potential usage of the annex field in taproot transactions. They talk about implementing partial reveal of data in the annex field and the philosophical question of its reserved use. They also discuss Taro's single event issuance and the provision for future issuance associated with discrete IDs under a single identifier. They address the terminology used for Taro assets, preferring to use widely used asset issuance/minting terminology instead of "colored coins."The email exchange further discusses the potential scripting layer in Taro, including a design sketch for an "issuance covenant" and the usage of Bitcoin covenants to enforce spending conditions on Taro assets. The email acknowledges that there are still questions to answer regarding the feasibility of these ideas.The email exchange between Olaoluwa Osuntokun and Bram Cohen discusses the limitations and tradeoffs of the Taro system. Witnesses for transactions need to be put into Bitcoin transactions despite the Bitcoin layer not understanding them. There needs to be a constraint on Taro transactions that is understood by the Bitcoin layer. Taro issuance is limited to a single event rather than potentially multiple events subject to special per-asset rules. Multiple Taro coins cannot consolidate their value into a single output because they only support a single linear history. Despite these limitations, there is nothing wrong with a system having well-documented limitations.Ruben and Olaoluwa discuss the Taro documentation and its relationship with RGB. Ruben had a bad experience with RGB's documentation and suggests rebuilding Taro from scratch. However, he believes Taro should still credit RGB in its documentation. The limitations of Taro in building scripting support were also discussed, where only certain types of smart contracts could be built due to Bitcoin's limitations in enforcing them. The conversation moved on to ways in which both RGB and Taro can prevent double spending or duplicate assets. Ruben explains potential issues with Taro's system, such as asset issuers choosing to issue assets in denomin 2022-11-07T13:51:12+00:00 + During a discussion about the "utxo teleport" scheme, Johan and Olaoluwa express their opinions on its soundness and compatibility with LN channels. Johan believes that as long as tokens are not sent to a spent UTXO, the scheme is sound. However, he agrees with Olaoluwa's concern about losing the blockchain as the main synchronization point. Olaoluwa argues that the scheme may not be sound because the UTXO may no longer exist when the transaction hits the chain, and there is no total ordering for safety.In contrast, Taro's state transition model ensures everything is bound to a single synchronization point and has re-org safety traits like regular Bitcoin transactions. Olaoluwa also points out that the "utxo teleport" scheme is not ideal for anchoring assets in channels. With Taro, assets are committed to the funding output when the channel is created, providing better visibility. Additionally, the "utxo teleport" scheme requires additional synchronization, while Taro creates an on-chain taproot output that directly creates the new asset anchor/output. The sender and receiver can use the blockchain itself as a synchronization point.Johan suggests adding a "teleport" feature to Taro, which would allow token transfer to already spent TXOs, burning the tokens. This feature could be beneficial for LN channels, enabling the addition or topping up of tokens in open channels with proof of token transfer.Ruben raises concerns about the RGB protocol, which he believes apply to Taro as well. He notes that the Taro script is not enforced by Bitcoin, so those controlling the Bitcoin script can choose to ignore the Taro script and destroy Taro assets. However, Ruben acknowledges that Taro's design predates RGB and seems to have inspired it.The email exchange discusses issues with verifying asset provenance in Taro's specifications. Hiroki Gondo points out the possibility of asset inflation if an illicit copy of a UTXO is created in the asset tree. Laolu acknowledges the issue and mentions that they aim to address it by assuming a "no-op" state transition in the current spec. Gondo suggests setting a constraint that only explicitly changed UTXOs should change, rather than generating proofs for every unchanging UTXO.Olaoluwa announces the Taro protocol, which uses the Taproot script tree and MS-SMT hybrid merkle tree for tokenization and asset issuance on the Bitcoin chain. They mention that Taro supports Lightning Network integration and efficient proofs of non-existence.The email exchange explores the feasibility of adding a scripting language to Taro. Ruben argues that using Bitcoin script without an additional scripting language inside Taro is sufficient. Olaoluwa proposes an "issuance covenant" design sketch for certain collateralization requirements, which Ruben acknowledges could be useful. They also discuss the deterministic location of the Taro tree in the taproot tree and propose solutions.In another email exchange, Bram Cohen and Olaoluwa discuss witnesses in transactions and the potential usage of the annex field in taproot transactions. They talk about implementing partial reveal of data in the annex field and the philosophical question of its reserved use. They also discuss Taro's single event issuance and the provision for future issuance associated with discrete IDs under a single identifier. They address the terminology used for Taro assets, preferring to use widely used asset issuance/minting terminology instead of "colored coins."The email exchange further discusses the potential scripting layer in Taro, including a design sketch for an "issuance covenant" and the usage of Bitcoin covenants to enforce spending conditions on Taro assets. The email acknowledges that there are still questions to answer regarding the feasibility of these ideas.The email exchange between Olaoluwa Osuntokun and Bram Cohen discusses the limitations and tradeoffs of the Taro system. Witnesses for transactions need to be put into Bitcoin transactions despite the Bitcoin layer not understanding them. There needs to be a constraint on Taro transactions that is understood by the Bitcoin layer. Taro issuance is limited to a single event rather than potentially multiple events subject to special per-asset rules. Multiple Taro coins cannot consolidate their value into a single output because they only support a single linear history. Despite these limitations, there is nothing wrong with a system having well-documented limitations.Ruben and Olaoluwa discuss the Taro documentation and its relationship with RGB. Ruben had a bad experience with RGB's documentation and suggests rebuilding Taro from scratch. However, he believes Taro should still credit RGB in its documentation. The limitations of Taro in building scripting support were also discussed, where only certain types of smart contracts could be built due to Bitcoin's limitations in enforcing them. The conversation moved on to ways in which both RGB and Taro can prevent double spending or duplicate assets. Ruben explains potential issues with Taro's system, such as asset issuers choosing to issue assets in denomin - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Towards-a-means-of-measuring-user-support-for-Soft-Forks.xml b/static/bitcoin-dev/April_2022/combined_Towards-a-means-of-measuring-user-support-for-Soft-Forks.xml index 4f8d00abbd..aabf25a989 100644 --- a/static/bitcoin-dev/April_2022/combined_Towards-a-means-of-measuring-user-support-for-Soft-Forks.xml +++ b/static/bitcoin-dev/April_2022/combined_Towards-a-means-of-measuring-user-support-for-Soft-Forks.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - Towards a means of measuring user support for Soft Forks - 2023-08-02T06:16:29.811662+00:00 - - Billy Tetrud 2022-05-01 22:41:44+00:00 - - - ZmnSCPxj 2022-04-30 06:14:45+00:00 - - - Billy Tetrud 2022-04-28 16:35:32+00:00 - - - Billy Tetrud 2022-04-28 16:09:36+00:00 - - - micaroni at gmail.com 2022-04-28 08:03:53+00:00 - - - ZmnSCPxj 2022-04-28 05:26:48+00:00 - - - Billy Tetrud 2022-04-28 05:18:06+00:00 - - - Nadav Ivgi 2022-04-28 00:16:57+00:00 - - - Erik Aronesty 2022-04-27 20:13:35+00:00 - - - Keagan McClelland 2022-04-27 18:32:33+00:00 - - - Jeremy Rubin 2022-04-27 17:54:16+00:00 - - - micaroni at gmail.com 2022-04-27 17:22:07+00:00 - - - Billy Tetrud 2022-04-27 16:17:51+00:00 - - - Ryan Grant 2022-04-27 15:27:23+00:00 - - - Erik Aronesty 2022-04-27 14:28:31+00:00 - - - Chris Riley 2022-04-27 14:01:57+00:00 - - - Billy Tetrud 2022-04-27 03:04:04+00:00 - - - Bryan Bishop 2022-04-26 20:39:44+00:00 - - - Keagan McClelland 2022-04-26 19:37:07+00:00 - + 2025-09-26T14:34:07.633257+00:00 + python-feedgen + + + [bitcoin-dev] Towards a means of measuring user support for Soft Forks Keagan McClelland + 2022-04-26T19:37:00.000Z + + + Bryan Bishop + 2022-04-26T20:39:00.000Z + + + Billy Tetrud + 2022-04-27T03:04:00.000Z + + + Chris Riley + 2022-04-27T14:01:00.000Z + + + Erik Aronesty + 2022-04-27T14:28:00.000Z + + + Ryan Grant + 2022-04-27T15:27:00.000Z + + + Billy Tetrud + 2022-04-27T16:17:00.000Z + + + micaroni + 2022-04-27T17:22:00.000Z + + + Jeremy Rubin + 2022-04-27T17:54:00.000Z + + + Keagan McClelland + 2022-04-27T18:32:00.000Z + + + Erik Aronesty + 2022-04-27T20:13:00.000Z + + + Nadav Ivgi + 2022-04-28T00:16:00.000Z + + + Billy Tetrud + 2022-04-28T05:18:00.000Z + + + ZmnSCPxj + 2022-04-28T05:26:00.000Z + + + micaroni + 2022-04-28T08:03:00.000Z + + + Billy Tetrud + 2022-04-28T16:09:00.000Z + + + Billy Tetrud + 2022-04-28T16:35:00.000Z + + + ZmnSCPxj + 2022-04-30T06:14:00.000Z + + + Billy Tetrud + 2022-05-01T22:41:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - Towards a means of measuring user support for Soft Forks - 2023-08-02T06:16:29.811662+00:00 + 2025-09-26T14:34:07.635508+00:00 - The discussion revolves around the concept of rationality and how it relates to different goals. The author argues that rationality is subjective and depends on individual goals. They suggest that consensus should be established around goals to streamline conversations and share ideas. A futures market for predictions is proposed as a means to better understand people's goals without revealing them directly. However, it is noted that persistent irrationalities embedded in the design of the human mind will still be difficult to break.In the context of Bitcoin governance, the conversation focuses on achieving consensus among stakeholders. There is a proposal to determine representation based on the economic influence of different constituencies, including holders, transactors, miners, and developers. Various mechanisms such as coin-weighted polling, transaction signaling, miner signaling, and developer consensus reviews are suggested to measure support. However, there are concerns about the limitations and potential gaming of these methods.The issue of soft fork activation in Bitcoin is discussed, including the threshold for activating consensus changes and the representation of different constituencies in this process. The mailing list members agree that technical consensus alone is not enough to assess user consensus, and more rigorous methods are needed. There is a proposal for transaction signaling to allow users to have sybil-resistant influence over miner decisions. Concerns are raised about potential manipulation and false consensus.The conversation also addresses the flaws of the Aumann Agreement Theorem in the context of democracy and consensus building. It is suggested that improving human thinking, gathering relevant information, and accurately laying out goals can address these flaws. The importance of understanding the preferences of non-experts and non-technical people is emphasized, and clear explanations of proposed changes are seen as crucial.Different proposals and ideas are presented throughout the discussion, including polling that is not programmatically connected to activation, time-locked weighted voting, and combining rejection of blocks and transaction fees for signaling upgrades. Anticipated objections and questions are raised regarding these proposals, highlighting the need for further discussion and analysis.Overall, the conversation revolves around finding a logical solution to achieve consensus in Bitcoin governance, considering individual goals, economic influence, and user preferences. The limitations of existing methods and the importance of clarity, inclusivity, and understanding are emphasized in the quest for effective decision-making processes.Keagan suggests using transactions themselves to signal for upgrades by utilizing the free bits in the version field of a transaction. This would provide users with sybil-resistant influence over miner decisions and allow them to pressure miners to act on their behalf. The proposal aims to address the breakdown in civility around the debate on soft-fork activation and create a mechanism for measuring social consensus. However, there are concerns raised about the potential manipulation and false consensus that could result from such a system. Some argue that this proposal could be seen as "pay to play," giving wealthier individuals more decision-making power. The author agrees that wealth should not be able to dominate consensus decisions and sees the proposed mechanism as an improvement over the current situation where influential people decide consensus.Implementing this proposal would require its own soft fork, but the author acknowledges that there are concerns about certain parties, such as CoinJoin pool operators and L2 protocol implementations, having power over deciding consensus. Despite these concerns, it is seen as an improvement over the current status quo.The forum discusses various questions related to the proposal, including whether it affords a better view into consensus than the current system of miner signaling, whether it can be gamed to give a worse view into consensus, and whether it measures the right thing. The author also queries whether a BIP specification should be written to detail out the proposal.In addition to this proposal, the Bitcoin community is also discussing other methods of measuring user support for soft-fork changes. One suggestion involves weighted polling of holders to gauge consensus. However, this would not be directly connected to the activation mechanism and would only provide a means of gauging some portion of consensus.Overall, the Bitcoin community is actively debating how to measure user support for proposed soft-fork changes, aiming to ensure that technical consensus aligns with user consensus. Various proposals and concerns have been raised, highlighting the challenges and considerations involved in accurately measuring consensus in the cryptocurrency space.McClelland has proposed a mechanism that allows users to pressure miners into taking action on their behalf by using transactions themselves as a signal for an upgrade. He suggests utilizing the "free" bits in the version field of a transaction, which are currently ignored, to create rules where a transaction signaling in favor of an upgrade must not be included in a block that does not signal in favor of it. This would give users sybil-resistant influence over miner decisions. The proposal aims to provide miners with a better understanding of what users want and could be incorporated as an auxiliary feature of the soft fork deployment scheme. However, there are anticipated objections to this idea, such as the argument that signaling is not equivalent to voting, the need for consensus before any deployment, and concerns that it would allow the wealthy to make consensus 2022-05-01T22:41:44+00:00 + The discussion revolves around the concept of rationality and how it relates to different goals. The author argues that rationality is subjective and depends on individual goals. They suggest that consensus should be established around goals to streamline conversations and share ideas. A futures market for predictions is proposed as a means to better understand people's goals without revealing them directly. However, it is noted that persistent irrationalities embedded in the design of the human mind will still be difficult to break.In the context of Bitcoin governance, the conversation focuses on achieving consensus among stakeholders. There is a proposal to determine representation based on the economic influence of different constituencies, including holders, transactors, miners, and developers. Various mechanisms such as coin-weighted polling, transaction signaling, miner signaling, and developer consensus reviews are suggested to measure support. However, there are concerns about the limitations and potential gaming of these methods.The issue of soft fork activation in Bitcoin is discussed, including the threshold for activating consensus changes and the representation of different constituencies in this process. The mailing list members agree that technical consensus alone is not enough to assess user consensus, and more rigorous methods are needed. There is a proposal for transaction signaling to allow users to have sybil-resistant influence over miner decisions. Concerns are raised about potential manipulation and false consensus.The conversation also addresses the flaws of the Aumann Agreement Theorem in the context of democracy and consensus building. It is suggested that improving human thinking, gathering relevant information, and accurately laying out goals can address these flaws. The importance of understanding the preferences of non-experts and non-technical people is emphasized, and clear explanations of proposed changes are seen as crucial.Different proposals and ideas are presented throughout the discussion, including polling that is not programmatically connected to activation, time-locked weighted voting, and combining rejection of blocks and transaction fees for signaling upgrades. Anticipated objections and questions are raised regarding these proposals, highlighting the need for further discussion and analysis.Overall, the conversation revolves around finding a logical solution to achieve consensus in Bitcoin governance, considering individual goals, economic influence, and user preferences. The limitations of existing methods and the importance of clarity, inclusivity, and understanding are emphasized in the quest for effective decision-making processes.Keagan suggests using transactions themselves to signal for upgrades by utilizing the free bits in the version field of a transaction. This would provide users with sybil-resistant influence over miner decisions and allow them to pressure miners to act on their behalf. The proposal aims to address the breakdown in civility around the debate on soft-fork activation and create a mechanism for measuring social consensus. However, there are concerns raised about the potential manipulation and false consensus that could result from such a system. Some argue that this proposal could be seen as "pay to play," giving wealthier individuals more decision-making power. The author agrees that wealth should not be able to dominate consensus decisions and sees the proposed mechanism as an improvement over the current situation where influential people decide consensus.Implementing this proposal would require its own soft fork, but the author acknowledges that there are concerns about certain parties, such as CoinJoin pool operators and L2 protocol implementations, having power over deciding consensus. Despite these concerns, it is seen as an improvement over the current status quo.The forum discusses various questions related to the proposal, including whether it affords a better view into consensus than the current system of miner signaling, whether it can be gamed to give a worse view into consensus, and whether it measures the right thing. The author also queries whether a BIP specification should be written to detail out the proposal.In addition to this proposal, the Bitcoin community is also discussing other methods of measuring user support for soft-fork changes. One suggestion involves weighted polling of holders to gauge consensus. However, this would not be directly connected to the activation mechanism and would only provide a means of gauging some portion of consensus.Overall, the Bitcoin community is actively debating how to measure user support for proposed soft-fork changes, aiming to ensure that technical consensus aligns with user consensus. Various proposals and concerns have been raised, highlighting the challenges and considerations involved in accurately measuring consensus in the cryptocurrency space.McClelland has proposed a mechanism that allows users to pressure miners into taking action on their behalf by using transactions themselves as a signal for an upgrade. He suggests utilizing the "free" bits in the version field of a transaction, which are currently ignored, to create rules where a transaction signaling in favor of an upgrade must not be included in a block that does not signal in favor of it. This would give users sybil-resistant influence over miner decisions. The proposal aims to provide miners with a better understanding of what users want and could be incorporated as an auxiliary feature of the soft fork deployment scheme. However, there are anticipated objections to this idea, such as the argument that signaling is not equivalent to voting, the need for consensus before any deployment, and concerns that it would allow the wealthy to make consensus - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_User-Resisted-Soft-Fork-for-CTV.xml b/static/bitcoin-dev/April_2022/combined_User-Resisted-Soft-Fork-for-CTV.xml index b92b310bda..e78e32a4f0 100644 --- a/static/bitcoin-dev/April_2022/combined_User-Resisted-Soft-Fork-for-CTV.xml +++ b/static/bitcoin-dev/April_2022/combined_User-Resisted-Soft-Fork-for-CTV.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - User Resisted Soft Fork for CTV - 2023-08-02T06:11:07.500399+00:00 - - alicexbt 2022-04-25 16:11:11+00:00 - - - ZmnSCPxj 2022-04-25 10:01:28+00:00 - - - Zac Greenwood 2022-04-25 09:06:09+00:00 - - - ZmnSCPxj 2022-04-25 05:36:48+00:00 - - - Peter Todd 2022-04-24 14:47:47+00:00 - - - Ryan Grant 2022-04-24 13:15:51+00:00 - - - Jorge Timón 2022-04-24 13:11:55+00:00 - - - Jorge Timón 2022-04-24 12:57:05+00:00 - - - Ryan Grant 2022-04-24 12:55:22+00:00 - - - Michael Folkson 2022-04-24 12:17:22+00:00 - - - Jorge Timón 2022-04-23 20:40:19+00:00 - - - Erik Aronesty 2022-04-23 14:48:30+00:00 - - - Billy Tetrud 2022-04-23 05:07:25+00:00 - - - Corey Haddad 2022-04-22 15:40:19+00:00 - - - Michael Folkson 2022-04-22 09:53:25+00:00 - - - Zac Greenwood 2022-04-22 09:03:51+00:00 - - - Keagan McClelland 2022-04-21 23:36:19+00:00 - - - Michael Folkson 2022-04-21 16:45:20+00:00 - + 2025-09-26T14:34:03.323888+00:00 + python-feedgen + + + [bitcoin-dev] User Resisted Soft Fork for CTV Michael Folkson + 2022-04-21T16:45:00.000Z + + + Keagan McClelland + 2022-04-21T23:36:00.000Z + + + Zac Greenwood + 2022-04-22T09:03:00.000Z + + + Michael Folkson + 2022-04-22T09:53:00.000Z + + + Corey Haddad + 2022-04-22T15:40:00.000Z + + + Billy Tetrud + 2022-04-23T05:07:00.000Z + + + Erik Aronesty + 2022-04-23T14:48:00.000Z + + + Jorge Timón + 2022-04-23T20:40:00.000Z + + + Michael Folkson + 2022-04-24T12:17:00.000Z + + + Ryan Grant + 2022-04-24T12:55:00.000Z + + + Jorge Timón + 2022-04-24T12:57:00.000Z + + + Jorge Timón + 2022-04-24T13:11:00.000Z + + + Ryan Grant + 2022-04-24T13:15:00.000Z + + + Peter Todd + 2022-04-24T14:47:00.000Z + + + ZmnSCPxj + 2022-04-25T05:36:00.000Z + + + Zac Greenwood + 2022-04-25T09:06:00.000Z + + + ZmnSCPxj + 2022-04-25T10:01:00.000Z + + + alicexbt + 2022-04-25T16:11:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - User Resisted Soft Fork for CTV - 2023-08-02T06:11:07.501399+00:00 + 2025-09-26T14:34:03.325908+00:00 - The context revolves around a debate within the Bitcoin community regarding the impact of increased use cases on the Bitcoin network. Tetrud and Zac express differing opinions, with Tetrud believing that more use cases would benefit Bitcoin by increasing its utility and adoption, while Zac argues that it could lead to higher transaction fees and strain the blockchain.The discussion then moves towards the maxim that any change in Bitcoin must benefit all users. Some members of the Bitcoin development community challenge this maxim, suggesting that changes benefiting the majority of users without negatively affecting the minority should still be implemented. The focus shifts to the potential benefits of Consensus-enforced Transaction Validity (CTV), which can provide improved security and reduced fees for all users. However, there are concerns about security caveats that need to be addressed.Contrary to the argument against CTV, the increase in use cases would not necessarily lead to increased transaction fees for everyone. Transaction fees are driven by demand for block space, not the number of use cases. The context emphasizes the importance of making Bitcoin useful and appealing, even in the face of high transaction fees.Michael Folkson opposes the activation of the CTV soft fork without community consensus. He believes that changes to Bitcoin's consensus rules should only be made with community support, as decentralized decision-making requires careful consideration of important aspects of Bitcoin. Folkson labels the effort to prevent the activation a User Resisted Soft Fork (URSF) and suggests creating an additional release that rejects blocks signaling for CTV.In response to the debate, Zac argues that any change increasing the number of use cases for Bitcoin affects all users and is not non-invasive, as it can drive up transaction fees. He supports the maxim that any change to Bitcoin must benefit all users and suggests that additions to the protocol should primarily benefit layer 2 solutions like Lightning Network.The Bitcoin community is preparing for a Speedy Trial signaling period for the CTV soft fork, which has caused surprise and anger among those who oppose its activation. The Bitcoin Core 23.0 release candidate does not include CTV code or activation code, and running this version will not signal for CTV. However, it is still possible that CTV could activate through another software release. Michael Folkson tentatively labels the effort as a User Resisted Soft Fork (URSF) and establishes a channel to monitor developments and discuss rejecting blocks that signal for CTV. He acknowledges that this approach is not ideal for consensus changes and warns against rushing the process. 2022-04-25T16:11:11+00:00 + The context revolves around a debate within the Bitcoin community regarding the impact of increased use cases on the Bitcoin network. Tetrud and Zac express differing opinions, with Tetrud believing that more use cases would benefit Bitcoin by increasing its utility and adoption, while Zac argues that it could lead to higher transaction fees and strain the blockchain.The discussion then moves towards the maxim that any change in Bitcoin must benefit all users. Some members of the Bitcoin development community challenge this maxim, suggesting that changes benefiting the majority of users without negatively affecting the minority should still be implemented. The focus shifts to the potential benefits of Consensus-enforced Transaction Validity (CTV), which can provide improved security and reduced fees for all users. However, there are concerns about security caveats that need to be addressed.Contrary to the argument against CTV, the increase in use cases would not necessarily lead to increased transaction fees for everyone. Transaction fees are driven by demand for block space, not the number of use cases. The context emphasizes the importance of making Bitcoin useful and appealing, even in the face of high transaction fees.Michael Folkson opposes the activation of the CTV soft fork without community consensus. He believes that changes to Bitcoin's consensus rules should only be made with community support, as decentralized decision-making requires careful consideration of important aspects of Bitcoin. Folkson labels the effort to prevent the activation a User Resisted Soft Fork (URSF) and suggests creating an additional release that rejects blocks signaling for CTV.In response to the debate, Zac argues that any change increasing the number of use cases for Bitcoin affects all users and is not non-invasive, as it can drive up transaction fees. He supports the maxim that any change to Bitcoin must benefit all users and suggests that additions to the protocol should primarily benefit layer 2 solutions like Lightning Network.The Bitcoin community is preparing for a Speedy Trial signaling period for the CTV soft fork, which has caused surprise and anger among those who oppose its activation. The Bitcoin Core 23.0 release candidate does not include CTV code or activation code, and running this version will not signal for CTV. However, it is still possible that CTV could activate through another software release. Michael Folkson tentatively labels the effort as a User Resisted Soft Fork (URSF) and establishes a channel to monitor developments and discuss rejecting blocks that signal for CTV. He acknowledges that this approach is not ideal for consensus changes and warns against rushing the process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml b/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml index bb67c95187..0e5e203ee4 100644 --- a/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml +++ b/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Vaulting (Was: Automatically reverting ("transitory") soft forks) - 2023-08-02T06:15:08.265648+00:00 + Combined summary - Vaulting (Was: Automatically reverting ("transitory") soft forks) + 2025-09-26T14:33:56.912712+00:00 + python-feedgen Billy Tetrud 2022-04-28 23:51:31+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 - Combined summary - Vaulting (Was: Automatically reverting ("transitory") soft forks) - 2023-08-02T06:15:08.265648+00:00 + Combined summary - Vaulting (Was: Automatically reverting ("transitory") soft forks) + 2025-09-26T14:33:56.912873+00:00 - The discussion on the bitcoin-dev mailing list revolves around the benefits and tradeoffs of using multisig versus a wallet vault. Nadav Ivgi highlights the primary benefit of a vault, which is the ability to keep primary wallet keys in deep cold storage for enhanced security. On the other hand, Billy Tetrud argues that the purpose of a wallet vault is to gain the security of a multisig wallet without having to sign using as many keys. The conversation also delves into the COV proposal in MES, which allows users to check if an output's scriptPubKey matches the corresponding script item from the stack, while accommodating wildcard values. Signing the transaction with the hot wallet key removes third-party malleability.The discussions explore different setups and approaches to securing Bitcoin transactions. The use of a warmer model for covenant-encumbered two-step spending with more frequently used keys is suggested, while keeping primary keys in deep cold storage for increased security. The viability of a CTV vault where the hot key signer is a multisig is discussed, with some arguing that it does not offer the advantages of either wallet type. The COV proposal in MES allows checking if the output's scriptPubKey matches the corresponding script item from the stack, with wildcard values available. However, the signing of the transaction with the hot wallet key eliminates malleability issues.The conversation also touches on the limitations and risks associated with different vault schemes. The theft of a hot wallet key is highlighted as a security concern in CTV-based vaults, as it may not be immediately apparent that the key has been stolen. The MES vault scheme is compared to the CTV vault, with the former offering more advantages for managing payments through a vault. Fee management and less constrained covenant designs are identified as areas that could benefit from further exploration.In addition, there are discussions about the limitations and potential solutions to security issues in vault proposals. The theft of a hot key and the possibility of waiting for the user to unvault their funds are identified as concerns. Alternative solutions such as the OP_BEFOREBLOCKVERIFY opcode and encoding transactions with OP_POS and OP_CD are proposed. The MES vault design is mentioned as one that commits to the destination address during unvaulting, but this requires a less constrained covenant design. The CTV vault is acknowledged as potentially containing the damage from a hot key theft more effectively, but fee management remains an issue.Overall, the discussions highlight the advantages and disadvantages of different wallet vault setups and COV proposals in MES. The focus is on security concerns, risk management, and exploring alternative approaches to address limitations. 2022-04-28T23:51:31+00:00 + The discussion on the bitcoin-dev mailing list revolves around the benefits and tradeoffs of using multisig versus a wallet vault. Nadav Ivgi highlights the primary benefit of a vault, which is the ability to keep primary wallet keys in deep cold storage for enhanced security. On the other hand, Billy Tetrud argues that the purpose of a wallet vault is to gain the security of a multisig wallet without having to sign using as many keys. The conversation also delves into the COV proposal in MES, which allows users to check if an output's scriptPubKey matches the corresponding script item from the stack, while accommodating wildcard values. Signing the transaction with the hot wallet key removes third-party malleability.The discussions explore different setups and approaches to securing Bitcoin transactions. The use of a warmer model for covenant-encumbered two-step spending with more frequently used keys is suggested, while keeping primary keys in deep cold storage for increased security. The viability of a CTV vault where the hot key signer is a multisig is discussed, with some arguing that it does not offer the advantages of either wallet type. The COV proposal in MES allows checking if the output's scriptPubKey matches the corresponding script item from the stack, with wildcard values available. However, the signing of the transaction with the hot wallet key eliminates malleability issues.The conversation also touches on the limitations and risks associated with different vault schemes. The theft of a hot wallet key is highlighted as a security concern in CTV-based vaults, as it may not be immediately apparent that the key has been stolen. The MES vault scheme is compared to the CTV vault, with the former offering more advantages for managing payments through a vault. Fee management and less constrained covenant designs are identified as areas that could benefit from further exploration.In addition, there are discussions about the limitations and potential solutions to security issues in vault proposals. The theft of a hot key and the possibility of waiting for the user to unvault their funds are identified as concerns. Alternative solutions such as the OP_BEFOREBLOCKVERIFY opcode and encoding transactions with OP_POS and OP_CD are proposed. The MES vault design is mentioned as one that commits to the destination address during unvaulting, but this requires a less constrained covenant design. The CTV vault is acknowledged as potentially containing the damage from a hot key theft more effectively, but fee management remains an issue.Overall, the discussions highlight the advantages and disadvantages of different wallet vault setups and COV proposals in MES. The focus is on security concerns, risk management, and exploring alternative approaches to address limitations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml b/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml index fc43c2fb36..85ecfcf73e 100644 --- a/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml +++ b/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - What to do when contentious soft fork activations are attempted - 2023-08-02T06:20:11.973401+00:00 + 2025-09-26T14:33:46.160602+00:00 + python-feedgen Jorge Timón 2022-05-07 01:57:39+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - What to do when contentious soft fork activations are attempted - 2023-08-02T06:20:11.973401+00:00 + 2025-09-26T14:33:46.160767+00:00 - The email conversation between Jorge Timón and John Tromp on the Bitcoin-dev mailing list has sparked a discussion on irony. Timón accused Tromp of making personal attacks against Andreas Antonopoulos for his opinions on bip8. However, Tromp pointed out that Timón himself had made a personal attack by calling Jeremy ignorant about bip8. This led to a discussion on how ironic it is that people who base their arguments on personal attacks are also the ones who complain the most about personal attacks.In a separate discussion on the bitcoin-dev mailing list, Jorge Timón questioned a claim made by Russell O'Connor about the design of Speedy Trial (ST). Timón found the claim strange and stated that the grace period for slower activation after lock-in was added to address concerns raised by people who disliked the proposal. However, he still believed that speedy trial was a bad proposal due to incorrect analysis. O'Connor responded by quoting his own blog post where he clarified that the design of speedy trial was not based on any activation philosophy about failing fast.In another email exchange, Jorge Timón suggested that it is unnecessary to personally attack Andreas for his opinions. He argued that the only reason Jeremy Rubin does not like BIP8 is because he is ignorant about it and has not reviewed it enough. However, John Tromp pointed out the irony in equating 'clueless about BIP119' with a personal attack and then calling Jeremy ignorant about BIP8. The conversation seems to revolve around differences of opinion regarding different Bitcoin Improvement Proposals (BIPs).In a separate email thread, Ryan Grant defends the OP_CTV covenant proposal after Jorge Timón questioned Andreas' criticism. Ryan argues that OP_CTV covenants cannot restrict any address that the sender does not control and criticizes Andreas for not code-reviewing BIP119 or the pull request. Ryan believes that Andreas did not look into the reason why the proposed client was safe and would not cause a chain split. The conversation also references Russell O'Connor's explanation for how Speedy Trials arose in the consensus process and how it was designed.The email threads also touch upon the concept of covenants in Bitcoin and the contributions made by individuals towards it. There is a mention of Bip8 and the importance of being open-minded to understand its analysis. The discussions revolve around the need for education, avoiding personal attacks, addressing misinformation, and looking at technical details when discussing contentious soft forks and covenant proposals.Michael Folkson expresses his thoughts on the recent attempt to activate a contentious soft fork and questions what should be done differently if such attempts happen again. He believes that it is unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split and suggests there should be a personal cost to dissuade them from trying it again. Folkson acknowledges that Bitcoin is a permissionless network and no authority can stop such attempts, but hopes that people will actively resist and prevent the network from being fundamentally broken.Overall, the email exchanges and threads highlight discussions on irony, differences of opinion regarding Bitcoin Improvement Proposals, the design of Speedy Trial, criticism of covenant proposals, addressing misinformation, and the recent attempt to activate a contentious soft fork. The conversations emphasize the importance of education, avoiding personal attacks, and considering technical details when discussing contentious topics in the Bitcoin community. 2022-05-07T01:57:39+00:00 + The email conversation between Jorge Timón and John Tromp on the Bitcoin-dev mailing list has sparked a discussion on irony. Timón accused Tromp of making personal attacks against Andreas Antonopoulos for his opinions on bip8. However, Tromp pointed out that Timón himself had made a personal attack by calling Jeremy ignorant about bip8. This led to a discussion on how ironic it is that people who base their arguments on personal attacks are also the ones who complain the most about personal attacks.In a separate discussion on the bitcoin-dev mailing list, Jorge Timón questioned a claim made by Russell O'Connor about the design of Speedy Trial (ST). Timón found the claim strange and stated that the grace period for slower activation after lock-in was added to address concerns raised by people who disliked the proposal. However, he still believed that speedy trial was a bad proposal due to incorrect analysis. O'Connor responded by quoting his own blog post where he clarified that the design of speedy trial was not based on any activation philosophy about failing fast.In another email exchange, Jorge Timón suggested that it is unnecessary to personally attack Andreas for his opinions. He argued that the only reason Jeremy Rubin does not like BIP8 is because he is ignorant about it and has not reviewed it enough. However, John Tromp pointed out the irony in equating 'clueless about BIP119' with a personal attack and then calling Jeremy ignorant about BIP8. The conversation seems to revolve around differences of opinion regarding different Bitcoin Improvement Proposals (BIPs).In a separate email thread, Ryan Grant defends the OP_CTV covenant proposal after Jorge Timón questioned Andreas' criticism. Ryan argues that OP_CTV covenants cannot restrict any address that the sender does not control and criticizes Andreas for not code-reviewing BIP119 or the pull request. Ryan believes that Andreas did not look into the reason why the proposed client was safe and would not cause a chain split. The conversation also references Russell O'Connor's explanation for how Speedy Trials arose in the consensus process and how it was designed.The email threads also touch upon the concept of covenants in Bitcoin and the contributions made by individuals towards it. There is a mention of Bip8 and the importance of being open-minded to understand its analysis. The discussions revolve around the need for education, avoiding personal attacks, addressing misinformation, and looking at technical details when discussing contentious soft forks and covenant proposals.Michael Folkson expresses his thoughts on the recent attempt to activate a contentious soft fork and questions what should be done differently if such attempts happen again. He believes that it is unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split and suggests there should be a personal cost to dissuade them from trying it again. Folkson acknowledges that Bitcoin is a permissionless network and no authority can stop such attempts, but hopes that people will actively resist and prevent the network from being fundamentally broken.Overall, the email exchanges and threads highlight discussions on irony, differences of opinion regarding Bitcoin Improvement Proposals, the design of Speedy Trial, criticism of covenant proposals, addressing misinformation, and the recent attempt to activate a contentious soft fork. The conversations emphasize the importance of education, avoiding personal attacks, and considering technical details when discussing contentious topics in the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_What-to-expect-in-the-next-few-weeks.xml b/static/bitcoin-dev/April_2022/combined_What-to-expect-in-the-next-few-weeks.xml index aa9a200026..4440c81c60 100644 --- a/static/bitcoin-dev/April_2022/combined_What-to-expect-in-the-next-few-weeks.xml +++ b/static/bitcoin-dev/April_2022/combined_What-to-expect-in-the-next-few-weeks.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - What to expect in the next few weeks - 2023-08-02T06:14:49.617807+00:00 - - alicexbt 2022-04-27 05:59:01+00:00 - - - Jeremy Rubin 2022-04-26 16:02:42+00:00 - - - Jeremy Rubin 2022-04-26 15:20:17+00:00 - - - Michael Folkson 2022-04-26 13:53:21+00:00 - - - Erik Aronesty 2022-04-26 13:42:43+00:00 - - - Jorge Timón 2022-04-26 11:40:19+00:00 - - - Anthony Towns 2022-04-26 10:47:51+00:00 - - - Melvin Carvalho 2022-04-26 06:39:36+00:00 - - - Jeremy Rubin 2022-04-26 05:48:20+00:00 - - - Michael Folkson 2022-04-25 22:26:36+00:00 - - - Michael Folkson 2022-04-23 10:03:15+00:00 - - - Billy Tetrud 2022-04-23 05:10:53+00:00 - - - Michael Folkson 2022-04-22 16:38:25+00:00 - + 2025-09-26T14:33:44.011635+00:00 + python-feedgen + + + [bitcoin-dev] What to expect in the next few weeks Michael Folkson + 2022-04-22T16:38:00.000Z + + + Billy Tetrud + 2022-04-23T05:10:00.000Z + + + Michael Folkson + 2022-04-23T10:03:00.000Z + + + Michael Folkson + 2022-04-25T22:26:00.000Z + + + Jeremy Rubin + 2022-04-26T05:48:00.000Z + + + Melvin Carvalho + 2022-04-26T06:39:00.000Z + + + Anthony Towns + 2022-04-26T10:47:00.000Z + + + Jorge Timón + 2022-04-26T11:40:00.000Z + + + Erik Aronesty + 2022-04-26T13:42:00.000Z + + + Michael Folkson + 2022-04-26T13:53:00.000Z + + + Jeremy Rubin + 2022-04-26T15:20:00.000Z + + + Jeremy Rubin + 2022-04-26T16:02:00.000Z + + + alicexbt + 2022-04-27T05:59:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - What to expect in the next few weeks - 2023-08-02T06:14:49.617807+00:00 + 2025-09-26T14:33:44.013162+00:00 - In a recent email to the bitcoin-dev mailing list, Michael Folkson expressed concern about the potential chaos that could arise in the Bitcoin community regarding consensus rules. He emphasized the importance of paying attention and making informed decisions on what software to run and support. Folkson acknowledged that those who were present during the period from 2015 to 2017 would have an idea of what to expect and highlighted the success of the right outcome in 2017. However, he cautioned against blindly trusting authorities, as it contradicts the ethos of Bitcoin and could be detrimental to the community.Folkson also voiced apprehension that crucial information may be withheld until the last moment and that certain parties might exploit a contentious soft fork activation attempt. He warned that these attempts could be deliberately convoluted to confuse participants. To mitigate this risk, Folkson recommended relying on the tried and trusted status quo, particularly Bitcoin Core. He advised individuals to consider alternative releases only if they possess comprehensive knowledge about them.Furthermore, Folkson invited those interested in resisting the contentious soft fork activation attempt of CTV to join ##ursf on Libera IRC. By joining this platform, individuals can collaborate with others who share similar concerns and work towards a resolution. Folkson expressed hope that the parties behind the activation attempt would reconsider their stance, allowing the community to refocus on more productive endeavors instead of resisting contentious soft forks.Overall, Folkson's message serves as a reminder for the Bitcoin community to remain vigilant and well-informed during a potential challenging period. It emphasizes the significance of relying on trusted sources and seeking detailed understanding before making decisions. The invitation to join ##ursf on Libera IRC provides a platform for like-minded individuals to come together and address the issues at hand. 2022-04-27T05:59:01+00:00 + In a recent email to the bitcoin-dev mailing list, Michael Folkson expressed concern about the potential chaos that could arise in the Bitcoin community regarding consensus rules. He emphasized the importance of paying attention and making informed decisions on what software to run and support. Folkson acknowledged that those who were present during the period from 2015 to 2017 would have an idea of what to expect and highlighted the success of the right outcome in 2017. However, he cautioned against blindly trusting authorities, as it contradicts the ethos of Bitcoin and could be detrimental to the community.Folkson also voiced apprehension that crucial information may be withheld until the last moment and that certain parties might exploit a contentious soft fork activation attempt. He warned that these attempts could be deliberately convoluted to confuse participants. To mitigate this risk, Folkson recommended relying on the tried and trusted status quo, particularly Bitcoin Core. He advised individuals to consider alternative releases only if they possess comprehensive knowledge about them.Furthermore, Folkson invited those interested in resisting the contentious soft fork activation attempt of CTV to join ##ursf on Libera IRC. By joining this platform, individuals can collaborate with others who share similar concerns and work towards a resolution. Folkson expressed hope that the parties behind the activation attempt would reconsider their stance, allowing the community to refocus on more productive endeavors instead of resisting contentious soft forks.Overall, Folkson's message serves as a reminder for the Bitcoin community to remain vigilant and well-informed during a potential challenging period. It emphasizes the significance of relying on trusted sources and seeking detailed understanding before making decisions. The invitation to join ##ursf on Libera IRC provides a platform for like-minded individuals to come together and address the issues at hand. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml b/static/bitcoin-dev/April_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml index ff89402056..45ec9333d9 100644 --- a/static/bitcoin-dev/April_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml +++ b/static/bitcoin-dev/April_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - A new Bitcoin implementation integrated with Core Lightning - 2023-08-02T08:48:39.136155+00:00 - - Matt Corallo 2023-05-06 05:58:55+00:00 - - - Vincenzo Palazzo 2023-04-30 15:22:01+00:00 - - - niftynei 2023-04-24 16:06:59+00:00 - - - Michael Folkson 2023-04-19 10:54:10+00:00 - - - Kostas Karasavvas 2023-04-19 09:05:10+00:00 - - - Michael Folkson 2023-04-18 17:06:14+00:00 - - - Michael Folkson 2023-01-16 15:45:36+00:00 - - - alicexbt 2023-01-15 13:04:05+00:00 - - - Michael Folkson 2023-01-14 20:45:38+00:00 - - - Fabian 2023-01-14 20:34:38+00:00 - - - Michael Folkson 2023-01-14 20:26:07+00:00 - + 2025-09-26T14:28:27.146651+00:00 + python-feedgen + + + [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning Michael Folkson + 2023-01-14T20:26:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Fabian + 2023-01-14T20:34:00.000Z + + + Michael Folkson + 2023-01-14T20:45:00.000Z + + + [bitcoin-dev] " alicexbt + 2023-01-15T13:04:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Michael Folkson + 2023-01-16T15:45:00.000Z + + + [bitcoin-dev] " Michael Folkson + 2023-04-18T17:06:00.000Z + + + Kostas Karasavvas + 2023-04-19T09:05:00.000Z + + + Michael Folkson + 2023-04-19T10:54:00.000Z + + + [bitcoin-dev] [Lightning-dev] " niftynei + 2023-04-24T16:06:00.000Z + + + Vincenzo Palazzo + 2023-04-30T15:22:00.000Z + + + Matt Corallo + 2023-05-06T05:58:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - A new Bitcoin implementation integrated with Core Lightning - 2023-08-02T08:48:39.136155+00:00 + 2025-09-26T14:28:27.148118+00:00 - Decisions within the Bitcoin community have been criticized for happening in a closed-off manner, with discussions taking place behind closed doors or in private IRC channels. Michael, however, believes that a more open and collaborative approach is needed. He suggests integrating a bare bones Knots style Bitcoin implementation with Core Lightning to create a simpler and more efficient solution. This would avoid the need to re-implement consensus code in a different language, which many developers see as a better option. However, there are concerns about the potential complexity and effort required for such integration.The email thread also addresses the decoupling of CLN from the block source, allowing for a separation of concerns and flexibility in choosing a block backend. The idea of "comingle"ing the peering of LN gossip and block data networks is raised, but it has not been seriously pursued in the LN side. Additionally, there is a discussion about fee calculation and the need for a unified approach to ensure proper functioning of Lightning nodes.Overall, the email thread sheds light on ongoing discussions and ideas for improving the scalability and functionality of the Bitcoin network. It highlights the challenges and opportunities in integrating full nodes and Lightning nodes, managing the Bitcoin Core project, and enhancing the overall ecosystem.The libbitcoinkernel project aimed to extract the consensus engine from Core, but it has proven difficult due to the elusive nature of consensus itself. As a result, the model of Knots style consensus compatible codebase forks of Bitcoin Core seems to be gaining traction. However, merging Bitcoin Core and Core Lightning into one codebase would be a monumental task, according to Michael. He is seeking input from individuals well-versed in both codebases to explore ambitious long-term projects that could potentially combine these two entities.Despite the perceived lull in the chaos surrounding soft fork activation, the Bitcoin community sees this as an opportune time to delve into ambitious endeavors, even if they are purely conceptual at this stage. By focusing on such projects, the community hopes to foster innovation and progress within the ecosystem. 2023-05-06T05:58:55+00:00 + Decisions within the Bitcoin community have been criticized for happening in a closed-off manner, with discussions taking place behind closed doors or in private IRC channels. Michael, however, believes that a more open and collaborative approach is needed. He suggests integrating a bare bones Knots style Bitcoin implementation with Core Lightning to create a simpler and more efficient solution. This would avoid the need to re-implement consensus code in a different language, which many developers see as a better option. However, there are concerns about the potential complexity and effort required for such integration.The email thread also addresses the decoupling of CLN from the block source, allowing for a separation of concerns and flexibility in choosing a block backend. The idea of "comingle"ing the peering of LN gossip and block data networks is raised, but it has not been seriously pursued in the LN side. Additionally, there is a discussion about fee calculation and the need for a unified approach to ensure proper functioning of Lightning nodes.Overall, the email thread sheds light on ongoing discussions and ideas for improving the scalability and functionality of the Bitcoin network. It highlights the challenges and opportunities in integrating full nodes and Lightning nodes, managing the Bitcoin Core project, and enhancing the overall ecosystem.The libbitcoinkernel project aimed to extract the consensus engine from Core, but it has proven difficult due to the elusive nature of consensus itself. As a result, the model of Knots style consensus compatible codebase forks of Bitcoin Core seems to be gaining traction. However, merging Bitcoin Core and Core Lightning into one codebase would be a monumental task, according to Michael. He is seeking input from individuals well-versed in both codebases to explore ambitious long-term projects that could potentially combine these two entities.Despite the perceived lull in the chaos surrounding soft fork activation, the Bitcoin community sees this as an opportune time to delve into ambitious endeavors, even if they are purely conceptual at this stage. By focusing on such projects, the community hopes to foster innovation and progress within the ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_Bitcoin-Core-maintainers-and-communication-on-merge-decisions.xml b/static/bitcoin-dev/April_2023/combined_Bitcoin-Core-maintainers-and-communication-on-merge-decisions.xml index d579db597a..fd4efb781d 100644 --- a/static/bitcoin-dev/April_2023/combined_Bitcoin-Core-maintainers-and-communication-on-merge-decisions.xml +++ b/static/bitcoin-dev/April_2023/combined_Bitcoin-Core-maintainers-and-communication-on-merge-decisions.xml @@ -1,92 +1,123 @@ - + 2 Combined summary - Bitcoin Core maintainers and communication on merge decisions - 2023-08-02T09:18:07.628839+00:00 - - Erik Aronesty 2023-05-11 18:48:39+00:00 - - - Steve Lee 2023-05-11 18:04:08+00:00 - - - alicexbt 2023-05-11 16:49:36+00:00 - - - Michael Folkson 2023-05-11 12:34:57+00:00 - - - Andrew Chow 2023-05-10 21:24:52+00:00 - - - Steve Lee 2023-05-10 18:29:56+00:00 - - - Michael Folkson 2023-05-10 17:22:37+00:00 - - - Steve Lee 2023-05-10 16:36:54+00:00 - - - Michael Folkson 2023-05-10 15:55:25+00:00 - - - Steve Lee 2023-05-10 02:44:59+00:00 - - - Bryan Bishop 2023-05-08 12:03:10+00:00 - - - Michael Folkson 2023-05-08 09:36:27+00:00 - - - David A. Harding 2023-05-07 17:35:52+00:00 - - - Michael Folkson 2023-05-07 07:03:02+00:00 - - - Aymeric Vitte 2023-04-20 14:25:30+00:00 - - - Erik Aronesty 2023-04-20 13:59:07+00:00 - - - Aymeric Vitte 2023-04-20 10:54:53+00:00 - - - Michael Folkson 2023-04-20 09:24:19+00:00 - - - Michael Folkson 2023-04-20 08:45:58+00:00 - - - Anthony Towns 2023-04-20 02:27:13+00:00 - - - Andrew Chow 2023-04-19 21:33:33+00:00 - - - alicexbt 2023-04-19 21:13:23+00:00 - - - Aymeric Vitte 2023-04-19 15:17:02+00:00 - - - Michael Folkson 2023-04-19 13:33:35+00:00 - - - alicexbt 2023-04-19 12:24:15+00:00 - - - Michael Folkson 2023-04-19 10:09:00+00:00 - - - Erik Aronesty 2023-04-19 00:56:48+00:00 - - - Michael Folkson 2023-04-18 12:40:44+00:00 - + 2025-09-26T14:28:18.652520+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson + 2023-04-18T12:40:00.000Z + + + Erik Aronesty + 2023-04-19T00:56:00.000Z + + + Michael Folkson + 2023-04-19T10:09:00.000Z + + + alicexbt + 2023-04-19T12:24:00.000Z + + + Michael Folkson + 2023-04-19T13:33:00.000Z + + + Aymeric Vitte + 2023-04-19T15:17:00.000Z + + + alicexbt + 2023-04-19T21:13:00.000Z + + + Andrew Chow + 2023-04-19T21:33:00.000Z + + + Anthony Towns + 2023-04-20T02:27:00.000Z + + + Michael Folkson + 2023-04-20T08:45:00.000Z + + + Michael Folkson + 2023-04-20T09:24:00.000Z + + + Aymeric Vitte + 2023-04-20T10:54:00.000Z + + + Erik Aronesty + 2023-04-20T13:59:00.000Z + + + Aymeric Vitte + 2023-04-20T14:25:00.000Z + + + Michael Folkson + 2023-05-07T07:03:00.000Z + + + David A. Harding + 2023-05-07T17:35:00.000Z + + + Michael Folkson + 2023-05-08T09:36:00.000Z + + + Bryan Bishop + 2023-05-08T12:03:00.000Z + + + Steve Lee + 2023-05-10T02:44:00.000Z + + + Michael Folkson + 2023-05-10T15:55:00.000Z + + + Steve Lee + 2023-05-10T16:36:00.000Z + + + Michael Folkson + 2023-05-10T17:22:00.000Z + + + Steve Lee + 2023-05-10T18:29:00.000Z + + + Andrew Chow + 2023-05-10T21:24:00.000Z + + + Michael Folkson + 2023-05-11T12:34:00.000Z + + + alicexbt + 2023-05-11T16:49:00.000Z + + + Steve Lee + 2023-05-11T18:04:00.000Z + + + Erik Aronesty + 2023-05-11T18:48:00.000Z + + @@ -115,13 +146,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core maintainers and communication on merge decisions - 2023-08-02T09:18:07.629835+00:00 + 2025-09-26T14:28:18.655738+00:00 - Bitcoin Core is currently facing challenges with its decision-making process for adding or blocking new maintainers. There are concerns that the current maintainers have too much power in deciding who can join the project. Some contributors argue that Bitcoin Core should function as a volunteer project where independent contributors merge different pull requests or patches. They believe that the controls on GitHub are simply because of the platform's structure. Additionally, there is confusion between Bitcoin Core and the bitcoin protocol itself. Several articles are provided to help understand the decentralized nature of Bitcoin governance.Michael Folkson raised his concerns about the decision-making process for new maintainers in an email to David A. Harding. He worried that long-term contributors might be excluded from important discussions and decision-making processes. He also questioned the transparency and justification behind blocking certain individuals. David responded by explaining that many organizations have their current members choose new members, highlighting the need to evaluate whether the current maintainers are capable of moving Bitcoin Core in the desired direction.The discussion also touched on the need for clear governance structures in open-source projects like Bitcoin Core. It was suggested that criteria should be established for selecting new maintainers in order to maintain the decentralized nature of the project and prevent power consolidation. The lack of transparent and consistent criteria could lead to contentious consensus changes without justification or rationale.Another issue raised in the context is the communication challenges within the Bitcoin Core project. Maintainers often merge pull requests without providing commentary, leading to frustration and confusion among contributors. The high number of open pull requests and issues makes it difficult to keep up with all the activity in the repository. Some contributors argue that maintainers do not need to provide commentary on every merge, as it becomes self-evident when the code is ready to be merged based on the number of acknowledgments (ACKs) from contributors.There are concerns about the transparency and accountability of the maintainers in Bitcoin Core, as they sometimes refuse to discuss merge decisions. This lack of communication can create problems and lead to confusion among casual observers. However, it is acknowledged that there is also a need to prevent malicious interference with the project.The Bitcoin Core project has also faced challenges with its communication process and maintainers stepping down. The lack of commentary on merges by maintainers has been attributed to their belief that it is self-evident when the code is ready for merging based on the number of ACKs from contributors. With several long-time maintainers stepping away, there may be delays in merging pull requests as the remaining maintainers may be less familiar with certain parts of the codebase.The concerns about communication and maintainers' decision-making process have prompted discussions on the need for more transparency, accountability, and clear governance structures within the Bitcoin Core project. It is suggested that dedicated communication channels be used for internal project decisions, and criteria be established for selecting new maintainers. Maintainers are encouraged to provide more commentary on merges to improve transparency and understanding among contributors.Overall, the Bitcoin Core project is grappling with issues related to the decision-making process for new maintainers, communication challenges, and the need for transparent and consistent criteria. The discussions highlight the importance of maintaining the decentralized nature of the project and ensuring clear governance structures in open-source projects.Merge decisions within Bitcoin Core have also come under scrutiny, with concerns about transparency and accountability. The author argues that if the transparency and accountability of merge decisions are not improved, it is unlikely to be better on the default signet. They suggest that the lack of transparency and justification in merge/non-merge decisions could lead to investing more heavily in consensus-compatible forks of Core or treating Core as a proprietary "open-source" project where merge decisions are not explained or justified openly.Michael Folkson emphasizes the importance of communication and transparency in the development process. He mentions that maintaining a pull request for an extended period without any commentary can be frustrating for the author. He emphasizes the need for openness and discussion around merge decisions, while acknowledging that not every pull request requires commentary for merging if it has received enough reviews, ACKs, and lacks controversy.The perception that the bitcoin-inquisition/default signet is seen as the only staging ground for consensus changes is also raised as a concern. The author warns that this perception could be dangerous if the maintainer(s) of that project have the same inclinations as a subset of the Core maintainers. To counter this, they suggest the possibility of creating a custom signet with more reviews, testing, and regular updates to challenge this perception.In summary, the email thread discusses the communication challenges within Bitcoin Core, particularly regarding pull requests and maintainer decisions. Michael Folkson expresses frustration with the lack of commentary provided by maintainers when merging pull requests and the prolonged periods without resolution. He argues for more transparency, accountability, and open discussion around merge decisions to avoid misunderstandings and contentious activations. Folkson also raises concerns about the perception of the default signet as the sole staging ground for consensus changes, suggesting alternatives to challenge this perception. The importance of competition and 2023-05-11T18:48:39+00:00 + Bitcoin Core is currently facing challenges with its decision-making process for adding or blocking new maintainers. There are concerns that the current maintainers have too much power in deciding who can join the project. Some contributors argue that Bitcoin Core should function as a volunteer project where independent contributors merge different pull requests or patches. They believe that the controls on GitHub are simply because of the platform's structure. Additionally, there is confusion between Bitcoin Core and the bitcoin protocol itself. Several articles are provided to help understand the decentralized nature of Bitcoin governance.Michael Folkson raised his concerns about the decision-making process for new maintainers in an email to David A. Harding. He worried that long-term contributors might be excluded from important discussions and decision-making processes. He also questioned the transparency and justification behind blocking certain individuals. David responded by explaining that many organizations have their current members choose new members, highlighting the need to evaluate whether the current maintainers are capable of moving Bitcoin Core in the desired direction.The discussion also touched on the need for clear governance structures in open-source projects like Bitcoin Core. It was suggested that criteria should be established for selecting new maintainers in order to maintain the decentralized nature of the project and prevent power consolidation. The lack of transparent and consistent criteria could lead to contentious consensus changes without justification or rationale.Another issue raised in the context is the communication challenges within the Bitcoin Core project. Maintainers often merge pull requests without providing commentary, leading to frustration and confusion among contributors. The high number of open pull requests and issues makes it difficult to keep up with all the activity in the repository. Some contributors argue that maintainers do not need to provide commentary on every merge, as it becomes self-evident when the code is ready to be merged based on the number of acknowledgments (ACKs) from contributors.There are concerns about the transparency and accountability of the maintainers in Bitcoin Core, as they sometimes refuse to discuss merge decisions. This lack of communication can create problems and lead to confusion among casual observers. However, it is acknowledged that there is also a need to prevent malicious interference with the project.The Bitcoin Core project has also faced challenges with its communication process and maintainers stepping down. The lack of commentary on merges by maintainers has been attributed to their belief that it is self-evident when the code is ready for merging based on the number of ACKs from contributors. With several long-time maintainers stepping away, there may be delays in merging pull requests as the remaining maintainers may be less familiar with certain parts of the codebase.The concerns about communication and maintainers' decision-making process have prompted discussions on the need for more transparency, accountability, and clear governance structures within the Bitcoin Core project. It is suggested that dedicated communication channels be used for internal project decisions, and criteria be established for selecting new maintainers. Maintainers are encouraged to provide more commentary on merges to improve transparency and understanding among contributors.Overall, the Bitcoin Core project is grappling with issues related to the decision-making process for new maintainers, communication challenges, and the need for transparent and consistent criteria. The discussions highlight the importance of maintaining the decentralized nature of the project and ensuring clear governance structures in open-source projects.Merge decisions within Bitcoin Core have also come under scrutiny, with concerns about transparency and accountability. The author argues that if the transparency and accountability of merge decisions are not improved, it is unlikely to be better on the default signet. They suggest that the lack of transparency and justification in merge/non-merge decisions could lead to investing more heavily in consensus-compatible forks of Core or treating Core as a proprietary "open-source" project where merge decisions are not explained or justified openly.Michael Folkson emphasizes the importance of communication and transparency in the development process. He mentions that maintaining a pull request for an extended period without any commentary can be frustrating for the author. He emphasizes the need for openness and discussion around merge decisions, while acknowledging that not every pull request requires commentary for merging if it has received enough reviews, ACKs, and lacks controversy.The perception that the bitcoin-inquisition/default signet is seen as the only staging ground for consensus changes is also raised as a concern. The author warns that this perception could be dangerous if the maintainer(s) of that project have the same inclinations as a subset of the Core maintainers. To counter this, they suggest the possibility of creating a custom signet with more reviews, testing, and regular updates to challenge this perception.In summary, the email thread discusses the communication challenges within Bitcoin Core, particularly regarding pull requests and maintainer decisions. Michael Folkson expresses frustration with the lack of commentary provided by maintainers when merging pull requests and the prolonged periods without resolution. He argues for more transparency, accountability, and open discussion around merge decisions to avoid misunderstandings and contentious activations. Folkson also raises concerns about the perception of the default signet as the sole staging ground for consensus changes, suggesting alternatives to challenge this perception. The importance of competition and - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml b/static/bitcoin-dev/April_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml index 23d25b7d9d..59754b704e 100644 --- a/static/bitcoin-dev/April_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml +++ b/static/bitcoin-dev/April_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin fungibility and inscribed sats - 2023-08-02T09:02:43.756693+00:00 + 2025-09-26T14:28:10.042709+00:00 + python-feedgen Kree Love 2023-04-20 23:06:17+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin fungibility and inscribed sats - 2023-08-02T09:02:43.756693+00:00 + 2025-09-26T14:28:10.042863+00:00 - In a detailed message, the author shares their personal journey with Bitcoin, starting from late 2010 when they saw it as an electronic cash system. However, they express concern about the current state of Bitcoin, noting that it has become more of an electronic asset rather than a peer-to-peer cash system due to regulation and artificially limited block sizes causing network congestion and high fees.The author also highlights the challenges faced in improving fungibility, citing regulatory hostility towards protocols like CoinJoin. They emphasize the importance of practical applications and global usability for Bitcoin to maintain its status as a global currency, despite pressure from governments, industrial lobbies, and cartels.Furthermore, the author believes that Non-Fungible Tokens (NFTs) distract from the ongoing efforts to ensure the safety and stability of Bitcoin as a reserve currency. However, they clarify that NFTs do not affect the fungibility of Bitcoin itself, as there is no token standard being used. These sats or UTXOs can be sold as regular Bitcoin on exchanges and consolidated for use like any other Bitcoin.The issue of Bitcoin fungibility is acknowledged as debatable by the author, who is actively working on implementing a coinjoin feature to prevent censorship of post-mix UTXOs on certain exchanges. They also mention the existence of the Ordinals theory, where some users believe in it and strive to understand how Bitcoin works.Developers are mentioned as being interested in building various things around Bitcoin, including BIP, DEX, libraries, and projects implementing PSBT. The author acknowledges not living in a first-world country and not attending bitdevs but expresses their desire for Bitcoin to be accessible to all.In conclusion, the author urges people to freely use Bitcoin without changing consensus rules, as this approach will ultimately benefit Bitcoin. The message was sent using Proton Mail secure email. 2023-04-20T23:06:17+00:00 + In a detailed message, the author shares their personal journey with Bitcoin, starting from late 2010 when they saw it as an electronic cash system. However, they express concern about the current state of Bitcoin, noting that it has become more of an electronic asset rather than a peer-to-peer cash system due to regulation and artificially limited block sizes causing network congestion and high fees.The author also highlights the challenges faced in improving fungibility, citing regulatory hostility towards protocols like CoinJoin. They emphasize the importance of practical applications and global usability for Bitcoin to maintain its status as a global currency, despite pressure from governments, industrial lobbies, and cartels.Furthermore, the author believes that Non-Fungible Tokens (NFTs) distract from the ongoing efforts to ensure the safety and stability of Bitcoin as a reserve currency. However, they clarify that NFTs do not affect the fungibility of Bitcoin itself, as there is no token standard being used. These sats or UTXOs can be sold as regular Bitcoin on exchanges and consolidated for use like any other Bitcoin.The issue of Bitcoin fungibility is acknowledged as debatable by the author, who is actively working on implementing a coinjoin feature to prevent censorship of post-mix UTXOs on certain exchanges. They also mention the existence of the Ordinals theory, where some users believe in it and strive to understand how Bitcoin works.Developers are mentioned as being interested in building various things around Bitcoin, including BIP, DEX, libraries, and projects implementing PSBT. The author acknowledges not living in a first-world country and not attending bitdevs but expresses their desire for Bitcoin to be accessible to all.In conclusion, the author urges people to freely use Bitcoin without changing consensus rules, as this approach will ultimately benefit Bitcoin. The message was sent using Proton Mail secure email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml b/static/bitcoin-dev/April_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml index 1eee121526..05b9cc04cd 100644 --- a/static/bitcoin-dev/April_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml +++ b/static/bitcoin-dev/April_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Civ Kit: A Peer-to-Peer Electronic Market System - 2023-08-02T09:14:15.352548+00:00 - - Antoine Riard 2023-06-30 03:46:32+00:00 - - - Chris Stewart 2023-05-09 15:09:16+00:00 - - - Antoine Riard 2023-05-01 17:47:46+00:00 - - - Antoine Riard 2023-04-13 14:10:01+00:00 - + 2025-09-26T14:28:14.355536+00:00 + python-feedgen + + + [bitcoin-dev] Civ Kit: A Peer-to-Peer Electronic Market System Antoine Riard + 2023-04-13T14:10:00.000Z + + + Antoine Riard + 2023-05-01T17:47:00.000Z + + + Chris Stewart + 2023-05-09T15:09:00.000Z + + + Antoine Riard + 2023-06-30T03:46:00.000Z + + - python-feedgen + 2 Combined summary - Civ Kit: A Peer-to-Peer Electronic Market System - 2023-08-02T09:14:15.352548+00:00 + 2025-09-26T14:28:14.356239+00:00 - The email thread discusses the concept of front-running in peer-to-peer marketplaces and the concern that bulletin board operators may front-run trades. However, there are security paradigms proposed to mitigate this risk, such as duplicating offers to multiple boards and monitoring latency anomalies. Running bulletin boards as federations with consensus rules is also suggested.The CivKit architecture aims to provide a flexible framework for peer-to-peer marketplaces, adapting to the needs of market participants. It aims to create a censorship-resistant and permissionless global trading system while addressing concerns like front-running. The paper delves into the architecture in detail, combining the Nostr architecture with Lightning onion routing infrastructure. The market boards are Nostr relays with a Lightning gateway, operating autonomously and in competition.The trades are escrowed under Bitcoin Script contracts, relying on moderations and know your peer oracles for adjudication. A consistent incentive framework for service operators is proposed through privacy-preserving credentials backed by Bitcoin payments. The authors plan to release code and modules gradually, leveraging the Lightning Dev Kit and Nostr libraries. They express their enthusiasm for collaborating with the community to standardize libraries and ensure interoperability between clients.The email provides links to various resources including the paper itself, external references like the Lightning Dev Kit and W3C DID Core specification, and the Privacy Pass project. The authors welcome feedback from readers and encourage an interactive dialogue. They provide a mailing list for further discussion and engagement with the Bitcoin development community. 2023-06-30T03:46:32+00:00 + The email thread discusses the concept of front-running in peer-to-peer marketplaces and the concern that bulletin board operators may front-run trades. However, there are security paradigms proposed to mitigate this risk, such as duplicating offers to multiple boards and monitoring latency anomalies. Running bulletin boards as federations with consensus rules is also suggested.The CivKit architecture aims to provide a flexible framework for peer-to-peer marketplaces, adapting to the needs of market participants. It aims to create a censorship-resistant and permissionless global trading system while addressing concerns like front-running. The paper delves into the architecture in detail, combining the Nostr architecture with Lightning onion routing infrastructure. The market boards are Nostr relays with a Lightning gateway, operating autonomously and in competition.The trades are escrowed under Bitcoin Script contracts, relying on moderations and know your peer oracles for adjudication. A consistent incentive framework for service operators is proposed through privacy-preserving credentials backed by Bitcoin payments. The authors plan to release code and modules gradually, leveraging the Lightning Dev Kit and Nostr libraries. They express their enthusiasm for collaborating with the community to standardize libraries and ensure interoperability between clients.The email provides links to various resources including the paper itself, external references like the Lightning Dev Kit and W3C DID Core specification, and the Privacy Pass project. The authors welcome feedback from readers and encourage an interactive dialogue. They provide a mailing list for further discussion and engagement with the Bitcoin development community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml b/static/bitcoin-dev/April_2023/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml index 9af850445d..eca82b7d89 100644 --- a/static/bitcoin-dev/April_2023/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml +++ b/static/bitcoin-dev/April_2023/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Conjectures on solving the high interactivity issue in payment pools and channel factories - 2023-08-02T06:18:48.419381+00:00 - - Antoine Riard 2023-04-18 03:38:57+00:00 - - - jlspc 2023-03-17 20:54:51+00:00 - - - Billy Tetrud 2022-05-12 17:36:25+00:00 - - - ZmnSCPxj 2022-05-10 16:45:19+00:00 - - - Antoine Riard 2022-05-10 00:38:36+00:00 - - - Billy Tetrud 2022-05-01 22:53:13+00:00 - - - Antoine Riard 2022-04-28 13:18:05+00:00 - + 2025-09-26T14:28:07.896302+00:00 + python-feedgen + + + [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories Antoine Riard + 2022-04-28T13:18:00.000Z + + + Billy Tetrud + 2022-05-01T22:53:00.000Z + + + Antoine Riard + 2022-05-10T00:38:00.000Z + + + ZmnSCPxj + 2022-05-10T16:45:00.000Z + + + Billy Tetrud + 2022-05-12T17:36:00.000Z + + + jlspc + 2023-03-17T20:54:00.000Z + + + Antoine Riard + 2023-04-18T03:38:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Conjectures on solving the high interactivity issue in payment pools and channel factories - 2023-08-02T06:18:48.420890+00:00 + 2025-09-26T14:28:07.897294+00:00 - The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels. 2023-04-18T03:38:57+00:00 + The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_Merkleize-All-The-Things.xml b/static/bitcoin-dev/April_2023/combined_Merkleize-All-The-Things.xml index 347923303d..f0da95c123 100644 --- a/static/bitcoin-dev/April_2023/combined_Merkleize-All-The-Things.xml +++ b/static/bitcoin-dev/April_2023/combined_Merkleize-All-The-Things.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - Merkleize All The Things - 2023-08-02T08:28:28.195475+00:00 - - Johan Torås Halseth 2023-05-30 07:34:09+00:00 - - - Salvatore Ingala 2023-05-28 10:24:14+00:00 - - - Johan Torås Halseth 2023-05-26 11:45:17+00:00 - - - Salvatore Ingala 2023-05-05 21:18:16+00:00 - - - Johan Torås Halseth 2023-05-04 08:34:07+00:00 - - - Salvatore Ingala 2023-05-01 21:15:20+00:00 - - - Salvatore Ingala 2023-05-01 13:11:08+00:00 - - - Johan Torås Halseth 2023-04-28 08:48:07+00:00 - - - Billy Tetrud 2022-12-13 06:59:27+00:00 - - - Salvatore Ingala 2022-12-01 08:47:22+00:00 - - - Rijndael 2022-11-30 22:09:33+00:00 - - - Rijndael 2022-11-30 19:42:08+00:00 - - - Salvatore Ingala 2022-11-12 15:04:20+00:00 - - - Antoine Riard 2022-11-11 21:49:58+00:00 - - - Salvatore Ingala 2022-11-10 09:42:30+00:00 - - - David A. Harding 2022-11-10 07:39:10+00:00 - - - Peter Todd 2022-11-09 12:07:33+00:00 - - - Bram Cohen 2022-11-08 23:34:32+00:00 - - - ZmnSCPxj 2022-11-08 12:01:11+00:00 - - - Salvatore Ingala 2022-11-08 09:17:42+00:00 - + 2025-09-26T14:28:12.225095+00:00 + python-feedgen + + + [bitcoin-dev] Merkleize All The Things Salvatore Ingala + 2022-11-08T09:17:00.000Z + + + ZmnSCPxj + 2022-11-08T12:01:00.000Z + + + Bram Cohen + 2022-11-08T23:34:00.000Z + + + Peter Todd + 2022-11-09T12:07:00.000Z + + + David A. Harding + 2022-11-10T07:39:00.000Z + + + Salvatore Ingala + 2022-11-10T09:42:00.000Z + + + Antoine Riard + 2022-11-11T21:49:00.000Z + + + Salvatore Ingala + 2022-11-12T15:04:00.000Z + + + Rijndael + 2022-11-30T19:42:00.000Z + + + Rijndael + 2022-11-30T22:09:00.000Z + + + Salvatore Ingala + 2022-12-01T08:47:00.000Z + + + Billy Tetrud + 2022-12-13T06:59:00.000Z + + + Johan Torås Halseth + 2023-04-28T08:48:00.000Z + + + Salvatore Ingala + 2023-05-01T13:11:00.000Z + + + Salvatore Ingala + 2023-05-01T21:15:00.000Z + + + Johan Torås Halseth + 2023-05-04T08:34:00.000Z + + + Salvatore Ingala + 2023-05-05T21:18:00.000Z + + + Johan Torås Halseth + 2023-05-26T11:45:00.000Z + + + Salvatore Ingala + 2023-05-28T10:24:00.000Z + + + Johan Torås Halseth + 2023-05-30T07:34:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - Merkleize All The Things - 2023-08-02T08:28:28.196514+00:00 + 2025-09-26T14:28:12.227527+00:00 - In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain. He provided a simpler game example to clarify the relationship between the covenant and the bisection protocol.Salvatore Ingala proposed MATT (Merkleize All The Things) as a method for enabling general 2023-05-30T07:34:09+00:00 + In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain. He provided a simpler game example to clarify the relationship between the covenant and the bisection protocol.Salvatore Ingala proposed MATT (Merkleize All The Things) as a method for enabling general - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_On-adaptor-security-in-protocols-.xml b/static/bitcoin-dev/April_2023/combined_On-adaptor-security-in-protocols-.xml index 70e2173c73..32f0b892da 100644 --- a/static/bitcoin-dev/April_2023/combined_On-adaptor-security-in-protocols-.xml +++ b/static/bitcoin-dev/April_2023/combined_On-adaptor-security-in-protocols-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - On adaptor security (in protocols) - 2023-08-02T09:22:26.483449+00:00 - - AdamISZ 2023-05-14 08:37:50+00:00 - - - Lloyd Fournier 2023-05-11 11:41:14+00:00 - - - AdamISZ 2023-05-11 05:12:39+00:00 - - - Lloyd Fournier 2023-05-08 04:37:48+00:00 - - - AdamISZ 2023-05-03 12:58:21+00:00 - - - AdamISZ 2023-05-01 18:37:27+00:00 - - - Lloyd Fournier 2023-05-01 04:23:30+00:00 - - - AdamISZ 2023-04-28 18:13:03+00:00 - + 2025-09-26T14:28:25.032600+00:00 + python-feedgen + + + [bitcoin-dev] On adaptor security (in protocols) AdamISZ + 2023-04-28T18:13:00.000Z + + + Lloyd Fournier + 2023-05-01T04:23:00.000Z + + + AdamISZ + 2023-05-01T18:37:00.000Z + + + AdamISZ + 2023-05-03T12:58:00.000Z + + + Lloyd Fournier + 2023-05-08T04:37:00.000Z + + + AdamISZ + 2023-05-11T05:12:00.000Z + + + Lloyd Fournier + 2023-05-11T11:41:00.000Z + + + AdamISZ + 2023-05-14T08:37:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - On adaptor security (in protocols) - 2023-08-02T09:22:26.483449+00:00 + 2025-09-26T14:28:25.033751+00:00 - In an email exchange between AdamISZ and Lloyd Fournier, they discuss the usefulness of single signer adaptors in Bitcoin. They conclude that single key signature adaptor in isolation is basically useless in a Bitcoin context but it could be useful in combination with another locking condition on the utxo such as another pubkey lock. They also discuss the canonical adaptor-based swap where Alice can encrypt the single-key signature for her payment to Bob, revealing the partial signature of Bob, on the payout from a multisig, to Alice. However, they mention that Alice can still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. Lloyd states that single signer adaptor signatures have been used as signature encryption in practice for years for the transaction signatures by DLC client implementations and are even used in channel implementations as well as atomic swaps.On May 11th, 2023, AdamISZ sent an email to Lloyd Fournier discussing a potential variant of the canonical adaptor based swap. He suggests that Alice can encrypt the single-key signature for her payment to Bob with the encryption key being T = sG, where s is the partial signature of Bob on the payout from a multisig to Alice. However, Lloyd points out that Alice could still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. He notes that a multisig is always necessary in these situations, but it need not be a key aggregated multisig like MuSig. Lloyd also mentions that there is no useful use of a single signer adaptor signature in Bitcoin without some kind of other spending constraint.On May 8th, 2023, Lloyd and AdamISZ had a conversation discussing the usefulness of single signer adaptors. Lloyd argues that they do provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret. He gives an example of holding a secret key for X and creating a signature adaptor with some encryption key Y with message m. If he does not create any further signatures on m, then any signature on m that is published necessarily reveals the secret on Y to him. This property can be useful in practice and has already been used for years by DLCs in production. However, AdamISZ struggles to understand this point and references Dryja's construct and single key Schnorr, stating that they are missing and therefore making them useless. Lloyd clarifies that he was not referencing the DLC oracle attestation protocol but rather pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for transaction signatures. There are even channel implementations using them as well as atomic swaps doing this.In an email exchange between AdamISZ and Lloyd Fournier via bitcoin-dev, they discuss the usefulness of single signer adaptors. Fournier argues that if a secret key is held for X and a signature adaptor is created with encryption key Y for message m, any signature on m published reveals the secret on Y to the holder of the secret key for X, making it a useful property in theory and practice. AdamISZ initially struggles to understand this concept but eventually acknowledges his error and admits to having a misconception about adaptors for years. They also discuss the framing of s' = k - t +H(R|P|m)x vs s' = k + H(R+T|P|m)x and a potential variant of the canonical adaptor based swap. Fournier clarifies that he was not referencing the DLC oracle attestation protocol, but rather pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for transaction signatures, making them a pretty useful thing. The conversation ends on a cordial note with cheers exchanged.In an email exchange between AdamISZ and Lloyd Fournier, they discussed the usefulness of single signer adaptors. While Fournier had previously claimed that they were useless as they did not provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret, AdamISZ disagreed. He argued that if he held a secret key for X and created a signature adaptor with some encryption key Y with message m and did not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to him. This property is useful in theory and practice. Fournier was confused by AdamISZ's statement and asked for clarification on what he meant by "any signature on m that is published reveals y." AdamISZ elaborated that if only one adaptor signature is generated on m and no other signatures on m are created, then a signature on m that appears under the key would reveal y to him. Fournier thought that the confusion might be about the DLC construct, which is analogous to single key Schnorr. However, AdamISZ clarified that he was not referencing the DLC oracle attestation protocol but was pointing out that 2023-05-14T08:37:50+00:00 + In an email exchange between AdamISZ and Lloyd Fournier, they discuss the usefulness of single signer adaptors in Bitcoin. They conclude that single key signature adaptor in isolation is basically useless in a Bitcoin context but it could be useful in combination with another locking condition on the utxo such as another pubkey lock. They also discuss the canonical adaptor-based swap where Alice can encrypt the single-key signature for her payment to Bob, revealing the partial signature of Bob, on the payout from a multisig, to Alice. However, they mention that Alice can still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. Lloyd states that single signer adaptor signatures have been used as signature encryption in practice for years for the transaction signatures by DLC client implementations and are even used in channel implementations as well as atomic swaps.On May 11th, 2023, AdamISZ sent an email to Lloyd Fournier discussing a potential variant of the canonical adaptor based swap. He suggests that Alice can encrypt the single-key signature for her payment to Bob with the encryption key being T = sG, where s is the partial signature of Bob on the payout from a multisig to Alice. However, Lloyd points out that Alice could still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. He notes that a multisig is always necessary in these situations, but it need not be a key aggregated multisig like MuSig. Lloyd also mentions that there is no useful use of a single signer adaptor signature in Bitcoin without some kind of other spending constraint.On May 8th, 2023, Lloyd and AdamISZ had a conversation discussing the usefulness of single signer adaptors. Lloyd argues that they do provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret. He gives an example of holding a secret key for X and creating a signature adaptor with some encryption key Y with message m. If he does not create any further signatures on m, then any signature on m that is published necessarily reveals the secret on Y to him. This property can be useful in practice and has already been used for years by DLCs in production. However, AdamISZ struggles to understand this point and references Dryja's construct and single key Schnorr, stating that they are missing and therefore making them useless. Lloyd clarifies that he was not referencing the DLC oracle attestation protocol but rather pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for transaction signatures. There are even channel implementations using them as well as atomic swaps doing this.In an email exchange between AdamISZ and Lloyd Fournier via bitcoin-dev, they discuss the usefulness of single signer adaptors. Fournier argues that if a secret key is held for X and a signature adaptor is created with encryption key Y for message m, any signature on m published reveals the secret on Y to the holder of the secret key for X, making it a useful property in theory and practice. AdamISZ initially struggles to understand this concept but eventually acknowledges his error and admits to having a misconception about adaptors for years. They also discuss the framing of s' = k - t +H(R|P|m)x vs s' = k + H(R+T|P|m)x and a potential variant of the canonical adaptor based swap. Fournier clarifies that he was not referencing the DLC oracle attestation protocol, but rather pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for transaction signatures, making them a pretty useful thing. The conversation ends on a cordial note with cheers exchanged.In an email exchange between AdamISZ and Lloyd Fournier, they discussed the usefulness of single signer adaptors. While Fournier had previously claimed that they were useless as they did not provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret, AdamISZ disagreed. He argued that if he held a secret key for X and created a signature adaptor with some encryption key Y with message m and did not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to him. This property is useful in theory and practice. Fournier was confused by AdamISZ's statement and asked for clarification on what he meant by "any signature on m that is published reveals y." AdamISZ elaborated that if only one adaptor signature is generated on m and no other signatures on m are created, then a signature on m that appears under the key would reveal y to him. Fournier thought that the confusion might be about the DLC construct, which is analogous to single key Schnorr. However, AdamISZ clarified that he was not referencing the DLC oracle attestation protocol but was pointing out that - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_Proposal-to-Remove-BIP35-P2P-mempool-Message.xml b/static/bitcoin-dev/April_2023/combined_Proposal-to-Remove-BIP35-P2P-mempool-Message.xml index 2b2eaa4bbf..b6224aea84 100644 --- a/static/bitcoin-dev/April_2023/combined_Proposal-to-Remove-BIP35-P2P-mempool-Message.xml +++ b/static/bitcoin-dev/April_2023/combined_Proposal-to-Remove-BIP35-P2P-mempool-Message.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Proposal to Remove BIP35 P2P 'mempool' Message - 2023-08-02T09:16:00.932771+00:00 - - 0xB10C 2023-05-01 13:24:26+00:00 - - - David A. Harding 2023-04-18 16:57:41+00:00 - - - Will Clark 2023-04-18 06:37:45+00:00 - + 2025-09-26T14:28:31.405454+00:00 + python-feedgen + + + [bitcoin-dev] Proposal to Remove BIP35 P2P 'mempool' Message Will Clark + 2023-04-18T06:37:00.000Z + + + David A. Harding + 2023-04-18T16:57:00.000Z + + + 0xB10C + 2023-05-01T13:24:00.000Z + + - python-feedgen + 2 Combined summary - Proposal to Remove BIP35 P2P 'mempool' Message - 2023-08-02T09:16:00.932771+00:00 + 2025-09-26T14:28:31.405945+00:00 - In response to a query about the BIP35 P2P `mempool` message, it has been revealed that Bitcoin Core only gates processing of mempool messages on NetPermissionFlags::Mempool when bloom filters are disabled. Despite being disabled by default, over 20% of nodes on the network have bloom filters enabled and respond to mempool messages with INV messages. An individual has reportedly been receiving around 20 mempool messages per hour to a well-connected NODE_BLOOM Bitcoin Core node from various user agents such as /BitcoinKit:0.1.0/, /bitcoinj:0.*.*/Bitcoin Wallet:*/, /WalletKit:0.1.0/, and /bread:2.1/. Moreover, the node responds to clients with INVs up to the maximum number of 50k entries and with smaller (bloom) filtered INVs.The conversation can be traced on a GitHub pull request comment [0] and the public key and signature of the commenter are also available as attachments. The `savemempool` RPC can be used to load the mempool directly into a client for trusted users. In the past, lightweight clients loaded a BIP37 filter and requested `mempool` using `getdata`. The node would then only send transactions matching the filter and false positives to the client. This approach reduced the amount of data transferred, which is crucial for lite clients with limited bandwidth or metered connections.During a backlog, the mempool contents in the `savemempool` format are about 300 MB, which is too much to transfer to lite clients. Although BIP37 and BIP35 interfaces are problematic, it's essential to build interfaces that enable people to use third-party wallets with their trusted nodes easily. It's possible to use `getheaders`, BIP157/8, and `getdata(block)` with their nodes to learn about all confirmed transactions affecting their wallet. Lite clients using a trusted node should receive a replacement for BIP35/7 support before those protocols are removed. Support for BIP324 and countersign should also be added to allow an authenticated and encrypted connection from a lite client to a trusted node. An authenticated connection is necessary to be secure, and it should ideally be encrypted.The author proposes the removal of BIP35 P2P `mempool` message, which is considered bad for privacy and relatively inefficient for trusted peers. The original intention of the message was to be publicly callable, but it is now gated behind stricter Net Permissions accessible to trusted peers only. An alternative for serving trusted clients could be using the `savemempool` RPC, although it currently has some shortcomings. Dumping and loading a dumped mempool to sync two trusted nodes or bootstrap one node makes more sense via RPC, but there is an argument to be made that syncing via P2P message would be more convenient.The author has a draft PR open for the removal of the mempool message, and before moving forward, they want to ensure that there are no active use cases or technical opposition to its removal. The author requests input on whether there are any parties who still directly rely on the BIP35 P2P `mempool` message and whether there will be any issues or negative consequences resulting from its removal. A quick search of node implementations shows that `btcd`, `libbitcoin`, and `BitcoinJ` all have BIP35 messages specified, but it's difficult to gauge upstream usage by other projects without outreach like this. The removal of the message would provide a small clean-up to the P2P codebase and bring the usual benefits in terms of maintainability. 2023-05-01T13:24:26+00:00 + In response to a query about the BIP35 P2P `mempool` message, it has been revealed that Bitcoin Core only gates processing of mempool messages on NetPermissionFlags::Mempool when bloom filters are disabled. Despite being disabled by default, over 20% of nodes on the network have bloom filters enabled and respond to mempool messages with INV messages. An individual has reportedly been receiving around 20 mempool messages per hour to a well-connected NODE_BLOOM Bitcoin Core node from various user agents such as /BitcoinKit:0.1.0/, /bitcoinj:0.*.*/Bitcoin Wallet:*/, /WalletKit:0.1.0/, and /bread:2.1/. Moreover, the node responds to clients with INVs up to the maximum number of 50k entries and with smaller (bloom) filtered INVs.The conversation can be traced on a GitHub pull request comment [0] and the public key and signature of the commenter are also available as attachments. The `savemempool` RPC can be used to load the mempool directly into a client for trusted users. In the past, lightweight clients loaded a BIP37 filter and requested `mempool` using `getdata`. The node would then only send transactions matching the filter and false positives to the client. This approach reduced the amount of data transferred, which is crucial for lite clients with limited bandwidth or metered connections.During a backlog, the mempool contents in the `savemempool` format are about 300 MB, which is too much to transfer to lite clients. Although BIP37 and BIP35 interfaces are problematic, it's essential to build interfaces that enable people to use third-party wallets with their trusted nodes easily. It's possible to use `getheaders`, BIP157/8, and `getdata(block)` with their nodes to learn about all confirmed transactions affecting their wallet. Lite clients using a trusted node should receive a replacement for BIP35/7 support before those protocols are removed. Support for BIP324 and countersign should also be added to allow an authenticated and encrypted connection from a lite client to a trusted node. An authenticated connection is necessary to be secure, and it should ideally be encrypted.The author proposes the removal of BIP35 P2P `mempool` message, which is considered bad for privacy and relatively inefficient for trusted peers. The original intention of the message was to be publicly callable, but it is now gated behind stricter Net Permissions accessible to trusted peers only. An alternative for serving trusted clients could be using the `savemempool` RPC, although it currently has some shortcomings. Dumping and loading a dumped mempool to sync two trusted nodes or bootstrap one node makes more sense via RPC, but there is an argument to be made that syncing via P2P message would be more convenient.The author has a draft PR open for the removal of the mempool message, and before moving forward, they want to ensure that there are no active use cases or technical opposition to its removal. The author requests input on whether there are any parties who still directly rely on the BIP35 P2P `mempool` message and whether there will be any issues or negative consequences resulting from its removal. A quick search of node implementations shows that `btcd`, `libbitcoin`, and `BitcoinJ` all have BIP35 messages specified, but it's difficult to gauge upstream usage by other projects without outreach like this. The removal of the message would provide a small clean-up to the P2P codebase and bring the usual benefits in terms of maintainability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_RGB-protocol-announcement.xml b/static/bitcoin-dev/April_2023/combined_RGB-protocol-announcement.xml index 8b5745ff0a..89298bc323 100644 --- a/static/bitcoin-dev/April_2023/combined_RGB-protocol-announcement.xml +++ b/static/bitcoin-dev/April_2023/combined_RGB-protocol-announcement.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - RGB protocol announcement - 2023-08-02T09:14:03.805942+00:00 - - Dr Maxim Orlovsky 2023-04-19 22:17:57+00:00 - - - David A. Harding 2023-04-19 19:37:53+00:00 - - - Dr Maxim Orlovsky 2023-04-18 23:16:05+00:00 - - - Dr Maxim Orlovsky 2023-04-18 00:47:24+00:00 - - - Federico Tenga 2023-04-16 07:15:58+00:00 - - - David A. Harding 2023-04-16 05:34:40+00:00 - - - Dr Maxim Orlovsky 2023-04-10 22:09:52+00:00 - + 2025-09-26T14:28:29.293270+00:00 + python-feedgen + + + [bitcoin-dev] RGB protocol announcement Dr Maxim Orlovsky + 2023-04-10T22:09:00.000Z + + + David A. Harding + 2023-04-16T05:34:00.000Z + + + Federico Tenga + 2023-04-16T07:15:00.000Z + + + Dr Maxim Orlovsky + 2023-04-18T00:47:00.000Z + + + Dr Maxim Orlovsky + 2023-04-18T23:16:00.000Z + + + David A. Harding + 2023-04-19T19:37:00.000Z + + + Dr Maxim Orlovsky + 2023-04-19T22:17:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - RGB protocol announcement - 2023-08-02T09:14:03.806928+00:00 + 2025-09-26T14:28:29.294180+00:00 - In an email exchange, Maxim Orlovsky discusses the distinction between Bitcoin contract settlements and BTC issuance. He emphasizes the need for trustless BTC design in lightning channels and mentions the potential of a new blockchain called RGB. RGB would enable smart contracts without requiring BTC/BTC* and offer various features on Lightning. The LNP/BP Standards Association is working on advancing bitcoin and lightning network protocols and seeks support from organizations and individuals.Orlovsky describes a hypothetical scenario where BTC is lifted to RGB (BTC*). He explains the structure of an RGB contract and the process of withdrawing Bob's BTC*. He also addresses the two designs for BTC* creation: lightning channels with trustlessness and on-chain "lifting" with semi-trust.In response to David Harding, Orlovsky clarifies that the RGB Node is not part of the current release and that LNP implementation is no longer required for using RGB on Lightning Network. They highlight the extensive documentation being written and the testing performed, including the use of a strict types system for data verification.Orlovsky discusses misconceptions and clarifies issues related to RGB development. They emphasize the importance of proper design and address concerns about lack of unit tests and demos. Orlovsky also shares the project's contributors and the developed type system.The conversation introduces an RGB lightning implementation based on LDK. David Harding raises concerns about non-publishable conditional statements' security in multiparty protocols. He questions the lack of unit tests and demos for LNP. Harding suggests that RGB's ambition and scope may limit its usefulness.RGB v0.10 has been released by Maxim Orlovsky and can be downloaded from the official website. RGB aims to build a programmability layer for Bitcoin and Lightning, enabling various use cases beyond tokens. However, client-side validation may not be enough for trustless multiparty settings. Concerns are raised about the status of RGB implementations, documentation, and testing.The RGB Network has developed the LNP/BP protocol, enabling token creation on the Bitcoin blockchain. The protocol is flexible, modular, and interoperable with other blockchains. The release of RGB v0.10 by the LNP/BP Standards Association brings full support for smart contracts to Bitcoin and Lightning after extensive development work. Companies are already upgrading their software to v0.10. Further development activities will focus on completing documentation, audits, Lightning network support, and a new smart contracting language called Contractum.Overall, the LNP/BP protocol enhances the versatility and usefulness of the Bitcoin blockchain, allowing for the creation of new assets and applications. 2023-04-19T22:17:57+00:00 + In an email exchange, Maxim Orlovsky discusses the distinction between Bitcoin contract settlements and BTC issuance. He emphasizes the need for trustless BTC design in lightning channels and mentions the potential of a new blockchain called RGB. RGB would enable smart contracts without requiring BTC/BTC* and offer various features on Lightning. The LNP/BP Standards Association is working on advancing bitcoin and lightning network protocols and seeks support from organizations and individuals.Orlovsky describes a hypothetical scenario where BTC is lifted to RGB (BTC*). He explains the structure of an RGB contract and the process of withdrawing Bob's BTC*. He also addresses the two designs for BTC* creation: lightning channels with trustlessness and on-chain "lifting" with semi-trust.In response to David Harding, Orlovsky clarifies that the RGB Node is not part of the current release and that LNP implementation is no longer required for using RGB on Lightning Network. They highlight the extensive documentation being written and the testing performed, including the use of a strict types system for data verification.Orlovsky discusses misconceptions and clarifies issues related to RGB development. They emphasize the importance of proper design and address concerns about lack of unit tests and demos. Orlovsky also shares the project's contributors and the developed type system.The conversation introduces an RGB lightning implementation based on LDK. David Harding raises concerns about non-publishable conditional statements' security in multiparty protocols. He questions the lack of unit tests and demos for LNP. Harding suggests that RGB's ambition and scope may limit its usefulness.RGB v0.10 has been released by Maxim Orlovsky and can be downloaded from the official website. RGB aims to build a programmability layer for Bitcoin and Lightning, enabling various use cases beyond tokens. However, client-side validation may not be enough for trustless multiparty settings. Concerns are raised about the status of RGB implementations, documentation, and testing.The RGB Network has developed the LNP/BP protocol, enabling token creation on the Bitcoin blockchain. The protocol is flexible, modular, and interoperable with other blockchains. The release of RGB v0.10 by the LNP/BP Standards Association brings full support for smart contracts to Bitcoin and Lightning after extensive development work. Companies are already upgrading their software to v0.10. Further development activities will focus on completing documentation, audits, Lightning network support, and a new smart contracting language called Contractum.Overall, the LNP/BP protocol enhances the versatility and usefulness of the Bitcoin blockchain, allowing for the creation of new assets and applications. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_Seeking-concept-ACKs-for-transaction-terminology-BIP.xml b/static/bitcoin-dev/April_2023/combined_Seeking-concept-ACKs-for-transaction-terminology-BIP.xml index b99a0eb619..25ab47a386 100644 --- a/static/bitcoin-dev/April_2023/combined_Seeking-concept-ACKs-for-transaction-terminology-BIP.xml +++ b/static/bitcoin-dev/April_2023/combined_Seeking-concept-ACKs-for-transaction-terminology-BIP.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Seeking concept ACKs for transaction terminology BIP - 2023-08-02T09:03:22.335529+00:00 - - Keagan McClelland 2023-05-10 20:20:53+00:00 - - - josibake 2023-04-21 09:36:08+00:00 - - - Vincenzo Palazzo 2023-04-11 12:27:27+00:00 - - - darosior 2023-04-06 09:03:14+00:00 - - - Andrew Poelstra 2023-04-05 22:05:11+00:00 - - - Murch 2023-04-05 18:54:15+00:00 - + 2025-09-26T14:28:22.919417+00:00 + python-feedgen + + + [bitcoin-dev] Seeking concept ACKs for transaction terminology BIP Murch + 2023-04-05T18:54:00.000Z + + + Andrew Poelstra + 2023-04-05T22:05:00.000Z + + + darosior + 2023-04-06T09:03:00.000Z + + + Vincenzo Palazzo + 2023-04-11T12:27:00.000Z + + + josibake + 2023-04-21T09:36:00.000Z + + + Keagan McClelland + 2023-05-10T20:20:00.000Z + + - python-feedgen + 2 Combined summary - Seeking concept ACKs for transaction terminology BIP - 2023-08-02T09:03:22.335529+00:00 + 2025-09-26T14:28:22.920286+00:00 - In an effort to minimize confusion and establish a shared vocabulary for discussions about transactions, Murch has proposed the creation of a shared terminology document. This proposal comes after Murch noticed that conversations often get sidetracked by the use of competing terms for transaction components. To address this issue, Murch has drafted an informational BIP (Bitcoin Improvement Proposal) that outlines terminology for various components and aspects of transactions.The purpose of the proposal is not to achieve perfect consistency but rather to establish a common vocabulary among participants. Murch acknowledges that there are already contradictory established terms, making it challenging to establish a single set of terms. However, the proposed BIP aims to provide a reference document that can help minimize miscommunication and speed up the process of reaching social consensus on transaction-related issues.Josie, a participant in Bitcoin developer education programs, has also recognized the struggle students face when trying to reconcile different terms used in various resources. To address this issue, Josie suggests having a reference document early in the curriculum to reduce cognitive load and establish a shared terminology. Josie emphasizes the importance of the "synonyms" field, which helps map various resources to a common vocabulary.Murch's draft of the BIP can be found on GitHub, where he has asked for feedback from the community on the proposal's creation. Vincent, one of the participants, expressed his agreement with the proposal, noting that he recently discovered he was using a different term to refer to `scriptPubKey`, which caused confusion.On April 5th, 2023, Murch sent an email to the bitcoin-dev mailing list proposing the creation of an informational BIP that would establish a shared vocabulary for various components and aspects of transactions. Murch highlighted the existence of many competing terms, which can lead to confusion during conversations about transactions. The proposed BIP aims to avoid this confusion by establishing a shared terminology. Murch's draft of the BIP is available on GitHub, and he invites the bitcoin-dev community to review it and provide feedback. Murch acknowledges that some established terms are contradictory, and therefore, the proposal does not aim for perfect consistency. Instead, its primary goal is to establish a shared vocabulary that will facilitate conversations about transactions.Antoine responded to Murch's email, expressing agreement with the proposed BIP. This shows that there is support within the community for establishing a shared vocabulary.Andrew Poelstra, Director of Research at Blockstream, also expressed interest in the proposed BIP, leaving the task of refining the terminology to others. The draft of the proposal can be accessed via the link provided on GitHub.Overall, Murch's proposal for a shared terminology document aims to address the issue of confusion caused by competing terms in discussions about transactions. By establishing a common vocabulary, miscommunication can be minimized, and the process of reaching social consensus on transaction-related matters can be expedited. 2023-05-10T20:20:53+00:00 + In an effort to minimize confusion and establish a shared vocabulary for discussions about transactions, Murch has proposed the creation of a shared terminology document. This proposal comes after Murch noticed that conversations often get sidetracked by the use of competing terms for transaction components. To address this issue, Murch has drafted an informational BIP (Bitcoin Improvement Proposal) that outlines terminology for various components and aspects of transactions.The purpose of the proposal is not to achieve perfect consistency but rather to establish a common vocabulary among participants. Murch acknowledges that there are already contradictory established terms, making it challenging to establish a single set of terms. However, the proposed BIP aims to provide a reference document that can help minimize miscommunication and speed up the process of reaching social consensus on transaction-related issues.Josie, a participant in Bitcoin developer education programs, has also recognized the struggle students face when trying to reconcile different terms used in various resources. To address this issue, Josie suggests having a reference document early in the curriculum to reduce cognitive load and establish a shared terminology. Josie emphasizes the importance of the "synonyms" field, which helps map various resources to a common vocabulary.Murch's draft of the BIP can be found on GitHub, where he has asked for feedback from the community on the proposal's creation. Vincent, one of the participants, expressed his agreement with the proposal, noting that he recently discovered he was using a different term to refer to `scriptPubKey`, which caused confusion.On April 5th, 2023, Murch sent an email to the bitcoin-dev mailing list proposing the creation of an informational BIP that would establish a shared vocabulary for various components and aspects of transactions. Murch highlighted the existence of many competing terms, which can lead to confusion during conversations about transactions. The proposed BIP aims to avoid this confusion by establishing a shared terminology. Murch's draft of the BIP is available on GitHub, and he invites the bitcoin-dev community to review it and provide feedback. Murch acknowledges that some established terms are contradictory, and therefore, the proposal does not aim for perfect consistency. Instead, its primary goal is to establish a shared vocabulary that will facilitate conversations about transactions.Antoine responded to Murch's email, expressing agreement with the proposed BIP. This shows that there is support within the community for establishing a shared vocabulary.Andrew Poelstra, Director of Research at Blockstream, also expressed interest in the proposed BIP, leaving the task of refining the terminology to others. The draft of the proposal can be accessed via the link provided on GitHub.Overall, Murch's proposal for a shared terminology document aims to address the issue of confusion caused by competing terms in discussions about transactions. By establishing a common vocabulary, miscommunication can be minimized, and the process of reaching social consensus on transaction-related matters can be expedited. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_TARO-Protocol-metadata-BIP-proposal.xml b/static/bitcoin-dev/April_2023/combined_TARO-Protocol-metadata-BIP-proposal.xml index 19544bf0e5..c830d864dd 100644 --- a/static/bitcoin-dev/April_2023/combined_TARO-Protocol-metadata-BIP-proposal.xml +++ b/static/bitcoin-dev/April_2023/combined_TARO-Protocol-metadata-BIP-proposal.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - TARO Protocol metadata BIP proposal - 2023-08-02T09:19:41.988480+00:00 - - Andrew Melnychuk Oseen 2023-04-26 22:11:36+00:00 - - - Adam Ivansky 2023-04-21 09:46:53+00:00 - + 2025-09-26T14:28:05.749557+00:00 + python-feedgen + + + [bitcoin-dev] TARO Protocol metadata BIP proposal Adam Ivansky + 2023-04-21T09:46:00.000Z + + + Andrew Melnychuk Oseen + 2023-04-26T22:11:00.000Z + + - python-feedgen + 2 Combined summary - TARO Protocol metadata BIP proposal - 2023-08-02T09:19:41.988480+00:00 + 2025-09-26T14:28:05.750169+00:00 - Adam Ivansky, the founder of Tiramisu Wallet, has submitted a Bitcoin Improvement Proposal (BIP) concerning the metadata structure of assets traded on TARO Protocol. Although the existing TARO BIP does not specifically address the format of asset metadata, it is crucial for facilitating the trading of various assets like NFTs, stablecoins, and synthetic assets. Through testing different use cases and observing external users, Ivansky has identified essential fields that should be included in the metadata, including the ticker, asset name, description, image representation, and details about the asset's creator. To ensure consistency and compatibility, Ivansky proposes that the metadata be structured as a JSON stored as a string. This proposed structure also incorporates elements from OpenSea's metadata standards, but differs in that it includes actual image data within the metadata. It is important to note that the metadata for TARO Protocol assets does not need to be excessively compact since this data is not directly written to the blockchain. Currently, the Tiramisu wallet on the testnet already utilizes some of these JSON fields.In order to refine and improve upon his proposal, Ivansky seeks feedback from the mailing list community. By establishing a standardized metadata structure, TARO Protocol can enhance its functionality and provide users with comprehensive information about the assets they are trading. The BIP for TARO can be found on Github, though it does not explicitly outline the metadata format. Therefore, Ivansky's proposal serves as an important step towards ensuring seamless asset trading on the TARO Protocol, driven by a well-defined and universally accepted metadata structure. 2023-04-26T22:11:36+00:00 + Adam Ivansky, the founder of Tiramisu Wallet, has submitted a Bitcoin Improvement Proposal (BIP) concerning the metadata structure of assets traded on TARO Protocol. Although the existing TARO BIP does not specifically address the format of asset metadata, it is crucial for facilitating the trading of various assets like NFTs, stablecoins, and synthetic assets. Through testing different use cases and observing external users, Ivansky has identified essential fields that should be included in the metadata, including the ticker, asset name, description, image representation, and details about the asset's creator. To ensure consistency and compatibility, Ivansky proposes that the metadata be structured as a JSON stored as a string. This proposed structure also incorporates elements from OpenSea's metadata standards, but differs in that it includes actual image data within the metadata. It is important to note that the metadata for TARO Protocol assets does not need to be excessively compact since this data is not directly written to the blockchain. Currently, the Tiramisu wallet on the testnet already utilizes some of these JSON fields.In order to refine and improve upon his proposal, Ivansky seeks feedback from the mailing list community. By establishing a standardized metadata structure, TARO Protocol can enhance its functionality and provide users with comprehensive information about the assets they are trading. The BIP for TARO can be found on Github, though it does not explicitly outline the metadata format. Therefore, Ivansky's proposal serves as an important step towards ensuring seamless asset trading on the TARO Protocol, driven by a well-defined and universally accepted metadata structure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_Vaults-in-the-MATT-framework.xml b/static/bitcoin-dev/April_2023/combined_Vaults-in-the-MATT-framework.xml index 4537d898ff..240408340f 100644 --- a/static/bitcoin-dev/April_2023/combined_Vaults-in-the-MATT-framework.xml +++ b/static/bitcoin-dev/April_2023/combined_Vaults-in-the-MATT-framework.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Vaults in the MATT framework - 2023-08-02T09:20:10.117249+00:00 - - Johan Torås Halseth 2023-06-02 13:25:39+00:00 - - - Salvatore Ingala 2023-05-02 08:21:01+00:00 - - - Michael Folkson 2023-05-01 14:18:29+00:00 - - - Salvatore Ingala 2023-04-24 19:37:20+00:00 - + 2025-09-26T14:28:20.801777+00:00 + python-feedgen + + + [bitcoin-dev] Vaults in the MATT framework Salvatore Ingala + 2023-04-24T19:37:00.000Z + + + Michael Folkson + 2023-05-01T14:18:00.000Z + + + Salvatore Ingala + 2023-05-02T08:21:00.000Z + + + Johan Torås Halseth + 2023-06-02T13:25:00.000Z + + - python-feedgen + 2 Combined summary - Vaults in the MATT framework - 2023-08-02T09:20:10.117249+00:00 + 2025-09-26T14:28:20.802514+00:00 - Bitcoin developer Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes two new opcodes (OP_CHECKINPUTCONTRACTVERIFY and OP_CHECKOUTPUTCONTRACTVERIFY) that enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data within it. These opcodes enable general smart contracts and fraud proofs. The proposal also discusses Simplicity, a proposal to replace Script with a better language, but notes that it is separate from the discussion on what features should be included in the language.Ingala's proposal for new opcodes allows for the creation and verification of covenant-style contracts. The opcodes can be used to embed data into P2TR output scripts and verify that the correct data is present in subsequent transactions. However, the author suggests adding an opcode like OP_SHA256CAT to allow the data embedding to commit to multiple pieces of data. There is also consideration for extending OP_CHECKOUTPUTCONTRACTVERIFY to apply for arbitrary inputs, allowing for more complex cross-input semantics.The post describes a specific example of a vault using the proposed opcodes. A vault is modeled as a simple state machine with two states: the initial vault UTXOs and the utxo produced by the trigger transaction during unvaulting. The post explains how these opcodes could be used in the context of a vault, which controls the behavior of coins. It also discusses preserving amount in covenant-style contracts, including approaches such as direct introspection on output amounts and deferred checks.The structure of the P2TR output scripts for both the vault and unvaulting state are described. The proposed vault implementation differs from OP_VAULT in that it does not support adding an additional output sent back to the same vault. The author argues that separating the ctv-hash from the scripts in the taptree makes it easier to program state machines that control the behavior of coins.Overall, the proposal presents new opcodes that could enable more complex covenant-style contracts on Bitcoin. The required engineering for a soft-fork is relatively straightforward if the desired features are implemented. However, the decision to implement these features should consider potential risks to Bitcoin caused by their effect on miners' incentives. Comments and feedback on the proposal are welcome from the Bitcoin community.Another aspect of Ingala's proposal involves P2TR-based vaults, which provide an added layer of protection for storing Bitcoin securely. These vaults allow users to specify spending conditions that must be met before funds can be withdrawn. The proposal includes parameters for the vault contract and describes the structure of the vault state [V] and unvaulting state [U]. It also discusses how the proposed opcodes can be used to create vaults comparable to those built with OP_VAULT.Ingala's proposal for smart contracts in Bitcoin has two core opcodes that can be used to create vaults comparable to those built with OP_VAULT. These opcodes enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data in the output. However, further implementation is required since the opcodes only operate on scriptPubkey and not on the amounts.In summary, Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes new opcodes to enhance Script and enable more complex covenant-style contracts. The proposal discusses the use of these opcodes in creating vaults and preserving amounts in covenant-style contracts. The structure of the P2TR output scripts for the vault and unvaulting state is described, highlighting the differences from OP_VAULT. The proposal aims to make it easier to program state machines that control the behavior of coins. Feedback from the Bitcoin community is welcomed on the proposal. 2023-06-02T13:25:39+00:00 + Bitcoin developer Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes two new opcodes (OP_CHECKINPUTCONTRACTVERIFY and OP_CHECKOUTPUTCONTRACTVERIFY) that enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data within it. These opcodes enable general smart contracts and fraud proofs. The proposal also discusses Simplicity, a proposal to replace Script with a better language, but notes that it is separate from the discussion on what features should be included in the language.Ingala's proposal for new opcodes allows for the creation and verification of covenant-style contracts. The opcodes can be used to embed data into P2TR output scripts and verify that the correct data is present in subsequent transactions. However, the author suggests adding an opcode like OP_SHA256CAT to allow the data embedding to commit to multiple pieces of data. There is also consideration for extending OP_CHECKOUTPUTCONTRACTVERIFY to apply for arbitrary inputs, allowing for more complex cross-input semantics.The post describes a specific example of a vault using the proposed opcodes. A vault is modeled as a simple state machine with two states: the initial vault UTXOs and the utxo produced by the trigger transaction during unvaulting. The post explains how these opcodes could be used in the context of a vault, which controls the behavior of coins. It also discusses preserving amount in covenant-style contracts, including approaches such as direct introspection on output amounts and deferred checks.The structure of the P2TR output scripts for both the vault and unvaulting state are described. The proposed vault implementation differs from OP_VAULT in that it does not support adding an additional output sent back to the same vault. The author argues that separating the ctv-hash from the scripts in the taptree makes it easier to program state machines that control the behavior of coins.Overall, the proposal presents new opcodes that could enable more complex covenant-style contracts on Bitcoin. The required engineering for a soft-fork is relatively straightforward if the desired features are implemented. However, the decision to implement these features should consider potential risks to Bitcoin caused by their effect on miners' incentives. Comments and feedback on the proposal are welcome from the Bitcoin community.Another aspect of Ingala's proposal involves P2TR-based vaults, which provide an added layer of protection for storing Bitcoin securely. These vaults allow users to specify spending conditions that must be met before funds can be withdrawn. The proposal includes parameters for the vault contract and describes the structure of the vault state [V] and unvaulting state [U]. It also discusses how the proposed opcodes can be used to create vaults comparable to those built with OP_VAULT.Ingala's proposal for smart contracts in Bitcoin has two core opcodes that can be used to create vaults comparable to those built with OP_VAULT. These opcodes enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data in the output. However, further implementation is required since the opcodes only operate on scriptPubkey and not on the amounts.In summary, Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes new opcodes to enhance Script and enable more complex covenant-style contracts. The proposal discusses the use of these opcodes in creating vaults and preserving amounts in covenant-style contracts. The structure of the P2TR output scripts for the vault and unvaulting state is described, highlighting the differences from OP_VAULT. The proposal aims to make it easier to program state machines that control the behavior of coins. Feedback from the Bitcoin community is welcomed on the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2023/combined_proposal-new-opcode-OP-ZKP-to-enable-ZKP-based-spending-authorization.xml b/static/bitcoin-dev/April_2023/combined_proposal-new-opcode-OP-ZKP-to-enable-ZKP-based-spending-authorization.xml index 681ca647a4..f9bb9a5af5 100644 --- a/static/bitcoin-dev/April_2023/combined_proposal-new-opcode-OP-ZKP-to-enable-ZKP-based-spending-authorization.xml +++ b/static/bitcoin-dev/April_2023/combined_proposal-new-opcode-OP-ZKP-to-enable-ZKP-based-spending-authorization.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - proposal: new opcode OP_ZKP to enable ZKP-based spending authorization - 2023-08-02T09:21:30.577946+00:00 - - ZmnSCPxj 2023-05-06 02:51:33+00:00 - - - Weiji Guo 2023-05-05 23:06:51+00:00 - - - ZmnSCPxj 2023-05-04 17:13:09+00:00 - - - Weiji Guo 2023-05-04 15:31:22+00:00 - - - ZmnSCPxj 2023-05-02 15:01:01+00:00 - - - Weiji Guo 2023-05-01 12:46:30+00:00 - - - ZmnSCPxj 2023-04-30 02:15:50+00:00 - - - Weiji Guo 2023-04-28 08:29:10+00:00 - + 2025-09-26T14:28:16.468688+00:00 + python-feedgen + + + [bitcoin-dev] proposal: new opcode OP_ZKP to enable ZKP-based spending authorization Weiji Guo + 2023-04-28T08:29:00.000Z + + + ZmnSCPxj + 2023-04-30T02:15:00.000Z + + + Weiji Guo + 2023-05-01T12:46:00.000Z + + + ZmnSCPxj + 2023-05-02T15:01:00.000Z + + + Weiji Guo + 2023-05-04T15:31:00.000Z + + + ZmnSCPxj + 2023-05-04T17:13:00.000Z + + + Weiji Guo + 2023-05-05T23:06:00.000Z + + + ZmnSCPxj + 2023-05-06T02:51:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - proposal: new opcode OP_ZKP to enable ZKP-based spending authorization - 2023-08-02T09:21:30.578945+00:00 + 2025-09-26T14:28:16.469816+00:00 - The discussion between Weiji and ZmnSCPxj revolves around the possibility of an attack on the fullnode mempool network. The attack involves flooding the network with non-aggregated transactions and confirming a single aggregated transaction with a lower feerate in cooperation with a miner. However, ZmnSCPxj argues that this attack is not feasible due to the high cost and the need for a separate, paid aggregator outside the mempool to prevent overload on the free mempool service.To prevent the attack on non-aggregated transactions, it is suggested that transactions should be made non-aggregatable with other transactions in the mempool. Aggregation should be arranged before the blockchain-level transaction hits the mempool. Signature aggregation within a single blockchain-level transaction is allowed, but not across transactions. Similarly, cross-input ZKP aggregation is acceptable, but not cross-transaction ZKP aggregation. It is recommended to disallow ZKP aggregation once a transaction could potentially hit the mempool and require paid services for aggregation outside of the unpaid, free mempool.Weiji proposes the use of ZKPs in Bitcoin transactions and suggests that specialized computing power vendors could optimize ZKP computations. Groth16 verification can be fast enough to handle thousands of OP_ZKP transactions even on a common full node. These transactions can be put into the mempool and open to aggregation by vendors. However, it is cautioned against treating these transactions with special rules as there is no guarantee that certain OP_ZKP transactions will be aggregated or recursively verified. The cost for standalone OP_ZKP transactions might be higher, incentivizing vendors to develop aggregation/recursive verification services.The discussion also addresses the issue of verification keys exceeding the maximum script element size. It is suggested to store verification keys in configurations and only use their hash in the `scriptPubKey`. Weight units for propagation of verification keys should be adjusted similarly to `scriptPubKey`s and amounts in block data. If verification keys are permanent, they should be weighted heavier than `scriptPubKey`s and amounts. If ZKP witnesses consume more resources, their weighting should be higher as well.The proposal of a new opcode, OP_ZKP, aims to enable zero-knowledge based spending authorization in Bitcoin. This would make the Bitcoin script Turing complete and enable various applications. Security concerns, system limitations, scalability, ZKP schemes, curve choices, potential uses, and ecology implications are discussed in the proposal. Proof aggregation and recursive verification are suggested for scalability, and Groth16-BN254 is proposed as an initial choice for ZKP schemes and curve choices.The potential impact of ZKPs on smart contracts, computation power vendors, and wallet applications is also explored. Service providers could work with miners to optimize transaction generation and propose bundles of transactions to be included in blocks. Challenges include maintaining off-network UTXO entries with high security and figuring out ways for smart contracts to call each other. The heavy-duty computation task of generating proof to authorize spending is addressed, suggesting that if no secret is involved, a wallet is not needed, and the ZKP proof could serve as proof of something happening or existing.Further discussion among developers and the community is required before any BIP can be requested. The article provides relevant links to support the ideas presented. 2023-05-06T02:51:33+00:00 + The discussion between Weiji and ZmnSCPxj revolves around the possibility of an attack on the fullnode mempool network. The attack involves flooding the network with non-aggregated transactions and confirming a single aggregated transaction with a lower feerate in cooperation with a miner. However, ZmnSCPxj argues that this attack is not feasible due to the high cost and the need for a separate, paid aggregator outside the mempool to prevent overload on the free mempool service.To prevent the attack on non-aggregated transactions, it is suggested that transactions should be made non-aggregatable with other transactions in the mempool. Aggregation should be arranged before the blockchain-level transaction hits the mempool. Signature aggregation within a single blockchain-level transaction is allowed, but not across transactions. Similarly, cross-input ZKP aggregation is acceptable, but not cross-transaction ZKP aggregation. It is recommended to disallow ZKP aggregation once a transaction could potentially hit the mempool and require paid services for aggregation outside of the unpaid, free mempool.Weiji proposes the use of ZKPs in Bitcoin transactions and suggests that specialized computing power vendors could optimize ZKP computations. Groth16 verification can be fast enough to handle thousands of OP_ZKP transactions even on a common full node. These transactions can be put into the mempool and open to aggregation by vendors. However, it is cautioned against treating these transactions with special rules as there is no guarantee that certain OP_ZKP transactions will be aggregated or recursively verified. The cost for standalone OP_ZKP transactions might be higher, incentivizing vendors to develop aggregation/recursive verification services.The discussion also addresses the issue of verification keys exceeding the maximum script element size. It is suggested to store verification keys in configurations and only use their hash in the `scriptPubKey`. Weight units for propagation of verification keys should be adjusted similarly to `scriptPubKey`s and amounts in block data. If verification keys are permanent, they should be weighted heavier than `scriptPubKey`s and amounts. If ZKP witnesses consume more resources, their weighting should be higher as well.The proposal of a new opcode, OP_ZKP, aims to enable zero-knowledge based spending authorization in Bitcoin. This would make the Bitcoin script Turing complete and enable various applications. Security concerns, system limitations, scalability, ZKP schemes, curve choices, potential uses, and ecology implications are discussed in the proposal. Proof aggregation and recursive verification are suggested for scalability, and Groth16-BN254 is proposed as an initial choice for ZKP schemes and curve choices.The potential impact of ZKPs on smart contracts, computation power vendors, and wallet applications is also explored. Service providers could work with miners to optimize transaction generation and propose bundles of transactions to be included in blocks. Challenges include maintaining off-network UTXO entries with high security and figuring out ways for smart contracts to call each other. The heavy-duty computation task of generating proof to authorize spending is addressed, suggesting that if no secret is involved, a wallet is not needed, and the ZKP proof could serve as proof of something happening or existing.Further discussion among developers and the community is required before any BIP can be requested. The article provides relevant links to support the ideas presented. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_Adding-New-BIP-Editors.xml b/static/bitcoin-dev/April_2024/combined_Adding-New-BIP-Editors.xml index 1a37caf149..9d0e99d0a1 100644 --- a/static/bitcoin-dev/April_2024/combined_Adding-New-BIP-Editors.xml +++ b/static/bitcoin-dev/April_2024/combined_Adding-New-BIP-Editors.xml @@ -1,308 +1,411 @@ - + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.152793+00:00 - - Murch 2024-12-10 22:37:00+00:00 - - - Mark Erhardt 2024-09-19 18:48:00+00:00 - - - Antoine Riard 2024-09-19 07:47:00+00:00 - - - Mark Erhardt 2024-09-18 18:25:00+00:00 - - - Murch 2024-05-13 18:33:00+00:00 - - - Antoine Riard 2024-04-25 06:42:00+00:00 - - - Anthony Towns 2024-04-23 22:15:00+00:00 - - - Ali Sherief 2024-04-22 04:28:00+00:00 - - - Steve Lee 2024-04-22 02:44:00+00:00 - - - Ava Chow 2024-04-22 00:06:00+00:00 - - - Matt Corallo 2024-04-21 23:01:00+00:00 - - - Antoine Riard 2024-04-21 20:48:00+00:00 - - - Michael Folkson 2024-04-21 19:18:00+00:00 - - - Ava Chow 2024-04-21 18:47:00+00:00 - - - Michael Folkson 2024-04-21 17:57:00+00:00 - - - Ava Chow 2024-04-21 16:39:00+00:00 - - - Michael Folkson 2024-04-21 11:43:00+00:00 - - - Ava Chow 2024-04-20 23:05:00+00:00 - - - Ava Chow 2024-04-20 22:47:00+00:00 - - - Michael Folkson 2024-04-20 22:21:00+00:00 - - - Steve Lee 2024-04-20 22:03:00+00:00 - - - Ava Chow 2024-04-20 21:37:00+00:00 - - - Steve Lee 2024-04-20 21:11:00+00:00 - - - Ava Chow 2024-04-20 21:08:00+00:00 - - - Ava Chow 2024-04-20 20:59:00+00:00 - - - Steve Lee 2024-04-20 20:46:00+00:00 - - - Michael Folkson 2024-04-20 19:59:00+00:00 - - - Ava Chow 2024-04-20 19:48:00+00:00 - - - Ava Chow 2024-04-20 19:14:00+00:00 - - - Olaoluwa Osuntokun 2024-04-19 22:32:00+00:00 - - - nsvrn 2024-04-17 23:58:00+00:00 - - - Ava Chow 2024-04-16 17:08:00+00:00 - - - NVK 2024-04-16 13:32:00+00:00 - - - Tim Ruffing 2024-04-16 12:34:00+00:00 - - - Matt Corallo 2024-04-15 17:50:00+00:00 - - - Sergi Delgado Segura 2024-04-11 14:22:00+00:00 - - - Ali Sherief 2024-04-07 10:11:00+00:00 - - - Larry Ruane 2024-04-05 19:18:00+00:00 - - - xBC 2024-04-04 12:58:00+00:00 - - - Niklas Goegge 2024-04-04 09:09:00+00:00 - - - Anthony Towns 2024-04-04 05:00:00+00:00 - - - Pieter Wuille 2024-04-03 19:44:00+00:00 - - - Fabian 2024-04-03 18:34:00+00:00 - - - Vasil Dimov 2024-04-03 17:24:00+00:00 - - - Juan Galt 2024-04-03 16:58:00+00:00 - - - Murch 2024-04-03 15:03:00+00:00 - - - Luke Dashjr 2024-04-02 15:39:00+00:00 - - - Gloria Zhao 2024-04-02 15:13:00+00:00 - - - Luke Dashjr 2024-04-02 14:28:00+00:00 - - - nvk 2024-04-02 14:24:00+00:00 - - - /dev /fd 2024-04-02 13:49:00+00:00 - - - Tim Ruffing 2024-04-02 13:17:00+00:00 - - - Michael Folkson 2024-04-02 08:18:00+00:00 - - - Ava Chow 2024-04-02 00:37:00+00:00 - - - /dev /fd 2024-04-01 23:55:00+00:00 - - - David A. Harding 2024-04-01 21:13:00+00:00 - - - Antoine Riard 2024-04-01 20:14:00+00:00 - - - Jonas Nick 2024-04-01 18:42:00+00:00 - - - Murch 2024-04-01 18:41:00+00:00 - - - Michael Folkson 2024-04-01 11:58:00+00:00 - - - /dev /fd 2024-04-01 06:21:00+00:00 - - - Ava Chow 2024-03-31 17:01:00+00:00 - - - Michael Folkson 2024-03-31 16:01:00+00:00 - - - Antoine Riard 2024-03-30 20:01:00+00:00 - - - Michael Folkson 2024-03-30 11:51:00+00:00 - - - Peter Todd 2024-03-30 04:04:00+00:00 - - - Keagan McClelland 2024-03-29 22:17:00+00:00 - - - Antoine Riard 2024-03-29 21:08:00+00:00 - - - /dev /fd 2024-03-29 05:24:00+00:00 - - - Michael Folkson 2024-03-29 02:34:00+00:00 - - - Matt Corallo 2024-03-28 21:19:00+00:00 - - - John C. Vernaleo 2024-03-28 20:59:00+00:00 - - - Matt Corallo 2024-03-28 20:31:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Antoine Riard 2024-03-28 19:42:00+00:00 - - - /dev /fd 2024-03-28 16:09:00+00:00 - - - Brandon Black 2024-03-28 15:50:00+00:00 - - - Murch 2024-03-28 13:02:00+00:00 - - - Matt Corallo 2024-03-27 23:54:00+00:00 - - - John C. Vernaleo 2024-03-27 23:39:00+00:00 - - - Murch 2024-03-27 23:36:00+00:00 - - - Murch 2024-03-27 21:25:00+00:00 - - - Chris Stewart 2024-03-14 11:56:00+00:00 - - - Jon A 2024-03-11 16:48:00+00:00 - - - Bitcoin Error Log 2024-03-10 17:27:00+00:00 - - - Michael Folkson 2024-03-09 10:46:00+00:00 - - - Keagan McClelland 2024-03-07 22:39:00+00:00 - - - Antoine Riard 2024-03-07 20:56:00+00:00 - - - Tim Ruffing 2024-02-28 16:31:00+00:00 - - - bitcoindevml.void 2024-02-28 11:12:00+00:00 - - - /dev /fd 2024-02-28 04:22:00+00:00 - - - Ava Chow 2024-02-27 23:26:00+00:00 - - - /dev /fd 2024-02-27 23:10:00+00:00 - - - Luke Dashjr 2024-02-27 22:57:00+00:00 - - - Luke Dashjr 2024-02-27 22:40:00+00:00 - - - Greg Tonoski 2024-02-27 21:48:00+00:00 - - - Léo Haf 2024-02-27 21:33:00+00:00 - - - Ava Chow 2024-02-27 20:11:00+00:00 - - - Ava Chow 2024-02-27 18:53:00+00:00 - + 2025-09-26T14:41:48.161006+00:00 + python-feedgen + + + Adding New BIP Editors 'Ava Chow' + 2024-02-27T18:53:00.000Z + + + Léo Haf' + 2024-02-27T20:11:00.000Z + + + Antoine Poinsot' + 2024-02-27T21:33:00.000Z + + + Greg Tonoski + 2024-02-27T21:48:00.000Z + + + Luke Dashjr + 2024-02-27T22:40:00.000Z + + + Ava Chow' + 2024-02-27T22:57:00.000Z + + + /dev /fd0 + 2024-02-27T23:10:00.000Z + + + Steve Lee + 2024-02-27T23:26:00.000Z + + + /dev /fd0 + 2024-02-28T04:22:00.000Z + + + bitcoin-dev-ml.void867 + 2024-02-28T11:12:00.000Z + + + Tim Ruffing + 2024-02-28T16:31:00.000Z + + + Antoine Riard + 2024-03-07T20:56:00.000Z + + + Keagan McClelland + 2024-03-07T22:39:00.000Z + + + Michael Folkson + 2024-03-09T10:46:00.000Z + + + Bitcoin Error Log + 2024-03-10T17:27:00.000Z + + + Jon A + 2024-03-11T16:48:00.000Z + + + Chris Stewart + 2024-03-14T11:56:00.000Z + + + Murch + 2024-03-27T21:25:00.000Z + + + Keagan McClelland + 2024-03-27T23:36:00.000Z + + + John C. Vernaleo + 2024-03-27T23:39:00.000Z + + + Matt Corallo + 2024-03-27T23:54:00.000Z + + + Murch + 2024-03-28T13:02:00.000Z + + + Brandon Black + 2024-03-28T15:50:00.000Z + + + /dev /fd0 + 2024-03-28T16:09:00.000Z + + + Antoine Riard + 2024-03-28T19:42:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Antoine Riard + 2024-03-28T20:31:00.000Z + + + John C. Vernaleo + 2024-03-28T20:59:00.000Z + + + Matt Corallo + 2024-03-28T21:19:00.000Z + + + Michael Folkson + 2024-03-29T02:34:00.000Z + + + /dev /fd0 + 2024-03-29T05:24:00.000Z + + + Antoine Riard + 2024-03-29T21:08:00.000Z + + + Keagan McClelland + 2024-03-29T22:17:00.000Z + + + Peter Todd + 2024-03-30T04:04:00.000Z + + + Michael Folkson + 2024-03-30T11:51:00.000Z + + + Antoine Riard + 2024-03-30T20:01:00.000Z + + + Michael Folkson + 2024-03-31T16:01:00.000Z + + + Ava Chow' + 2024-03-31T17:01:00.000Z + + + /dev /fd0 + 2024-04-01T06:21:00.000Z + + + Michael Folkson + 2024-04-01T11:58:00.000Z + + + Re: Adding New BIP Editors Murch + 2024-04-01T18:41:00.000Z + + + Jonas Nick + 2024-04-01T18:42:00.000Z + + + Antoine Riard + 2024-04-01T20:14:00.000Z + + + David A. Harding + 2024-04-01T21:13:00.000Z + + + /dev /fd0 + 2024-04-01T23:55:00.000Z + + + Ava Chow' + 2024-04-02T00:37:00.000Z + + + Michael Folkson + 2024-04-02T08:18:00.000Z + + + Time for an update to BIP2? Tim Ruffing + 2024-04-02T13:17:00.000Z + + + /dev /fd0 + 2024-04-02T13:49:00.000Z + + + nvk + 2024-04-02T14:24:00.000Z + + + Luke Dashjr + 2024-04-02T14:28:00.000Z + + + Gloria Zhao + 2024-04-02T15:13:00.000Z + + + Luke Dashjr + 2024-04-02T15:39:00.000Z + + + Murch + 2024-04-03T15:03:00.000Z + + + Juan Galt + 2024-04-03T16:58:00.000Z + + + Vasil Dimov + 2024-04-03T17:24:00.000Z + + + Fabian' + 2024-04-03T18:34:00.000Z + + + Pieter Wuille + 2024-04-03T19:44:00.000Z + + + Anthony Towns + 2024-04-04T05:00:00.000Z + + + Niklas Goegge + 2024-04-04T09:09:00.000Z + + + Adding New BIP Editors 0xB10C + 2024-04-04T12:58:00.000Z + + + Larry Ruane + 2024-04-05T19:18:00.000Z + + + Ali Sherief + 2024-04-07T10:11:00.000Z + + + Sergi Delgado Segura + 2024-04-11T14:22:00.000Z + + + Matt Corallo + 2024-04-15T17:50:00.000Z + + + Tim Ruffing + 2024-04-16T12:34:00.000Z + + + NVK + 2024-04-16T13:32:00.000Z + + + Ava Chow' + 2024-04-16T17:08:00.000Z + + + nsvrn' + 2024-04-17T23:58:00.000Z + + + Olaoluwa Osuntokun + 2024-04-19T22:32:00.000Z + + + Ava Chow' + 2024-04-20T19:14:00.000Z + + + NVK + 2024-04-20T19:48:00.000Z + + + Michael Folkson + 2024-04-20T19:59:00.000Z + + + Steve Lee + 2024-04-20T20:46:00.000Z + + + Ava Chow' + 2024-04-20T20:59:00.000Z + + + Ava Chow' + 2024-04-20T21:08:00.000Z + + + Steve Lee + 2024-04-20T21:11:00.000Z + + + Ava Chow' + 2024-04-20T21:37:00.000Z + + + Steve Lee + 2024-04-20T22:03:00.000Z + + + Michael Folkson + 2024-04-20T22:21:00.000Z + + + Ava Chow' + 2024-04-20T22:47:00.000Z + + + Ava Chow' + 2024-04-20T23:05:00.000Z + + + Michael Folkson + 2024-04-21T11:43:00.000Z + + + Ava Chow' + 2024-04-21T16:39:00.000Z + + + Michael Folkson + 2024-04-21T17:57:00.000Z + + + Ava Chow' + 2024-04-21T18:47:00.000Z + + + Michael Folkson + 2024-04-21T19:18:00.000Z + + + Antoine Riard + 2024-04-21T20:48:00.000Z + + + Matt Corallo + 2024-04-21T23:01:00.000Z + + + Ava Chow' + 2024-04-22T00:06:00.000Z + + + Steve Lee + 2024-04-22T02:44:00.000Z + + + Ali Sherief + 2024-04-22T04:28:00.000Z + + + Anthony Towns + 2024-04-23T22:15:00.000Z + + + Antoine Riard + 2024-04-25T06:42:00.000Z + + + Time for an update to BIP2? Murch + 2024-05-13T18:33:00.000Z + + + Murch + 2024-09-18T18:25:00.000Z + + + Antoine Riard + 2024-09-19T07:47:00.000Z + + + Murch + 2024-09-19T18:48:00.000Z + + + Murch + 2024-12-10T22:37:00.000Z + + @@ -403,21 +506,17 @@ - python-feedgen + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.153617+00:00 + 2025-09-26T14:41:48.170088+00:00 + 2024-12-10T22:37:00+00:00 In the realm of Bitcoin development, discussions pertaining to the enhancement of the Bitcoin Improvement Proposal (BIP) process have been prominent. A key focus has been on addressing the current bottleneck in managing BIPs, emphasized by Luke Dashjr's acknowledgment of his limited capacity to actively maintain the BIPs repository. This acknowledgment underscores the critical need for additional BIP editors to ensure an efficient and effective review and integration process for new proposals and amendments to existing ones. - The role of a BIP editor is significant, encompassing responsibilities such as assigning BIP numbers, merging pull requests for new proposals, making fixes to existing BIPs, and more, as outlined in BIP 2. The addition of new editors is envisaged as a pivotal measure to alleviate the backlog of submissions and augment the process's overall productivity. For the continuity and coherence of the BIP numbering system, it is imperative that any incoming editors concur on the established numbering scheme. - The selection criteria for new BIP editors highlight the necessity for candidates with a comprehensive background in Bitcoin development, showcasing a history of active participation and contributions. These individuals must possess the ability to impartially assess proposals, a quality that underscores the importance of objectivity in the role. - Within this context, Kanzure and RubenSomsen have been identified as exemplary candidates for the position of BIP editors. Their extensive involvement in Bitcoin development positions them as valuable additions to the editorial team. Their potential inclusion is anticipated to significantly ameliorate the management and advancement of the BIPs repository, offering substantial benefits to the Bitcoin development community. - This dialogue illustrates the collective effort within the Bitcoin developer ecosystem to refine the governance mechanisms surrounding BIPs. It emphasizes the commitment to ensuring that the process remains robust, transparent, and inclusive, facilitating the continuous evolution and improvement of Bitcoin. - 2024-12-10T22:37:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_BIP-for-OP-CHECKSIGFROMSTACK.xml b/static/bitcoin-dev/April_2024/combined_BIP-for-OP-CHECKSIGFROMSTACK.xml index 538de62f94..c4fd3c6da9 100644 --- a/static/bitcoin-dev/April_2024/combined_BIP-for-OP-CHECKSIGFROMSTACK.xml +++ b/static/bitcoin-dev/April_2024/combined_BIP-for-OP-CHECKSIGFROMSTACK.xml @@ -1,35 +1,37 @@ - + 2 Combined summary - BIP for OP_CHECKSIGFROMSTACK - 2024-05-16T02:00:33.101359+00:00 - - Brandon Black 2024-05-14 21:55:00+00:00 - - - Andrew Poelstra 2024-04-25 11:44:00+00:00 - - - Brandon Black 2024-04-25 05:12:00+00:00 - + 2025-09-26T14:41:39.467835+00:00 + python-feedgen + + + BIP for OP_CHECKSIGFROMSTACK Brandon Black + 2024-04-25T05:12:00.000Z + + + Andrew Poelstra + 2024-04-25T11:44:00.000Z + + + Brandon Black + 2024-05-14T21:55:00.000Z + + - python-feedgen + 2 Combined summary - BIP for OP_CHECKSIGFROMSTACK - 2024-05-16T02:00:33.101424+00:00 + 2025-09-26T14:41:39.468422+00:00 + 2024-05-14T21:55:00+00:00 The email from Andrew Poelstra, Director of Research at Blockstream, sheds light on considerations regarding the Bitcoin Improvement Proposal (BIP) focusing on enhancements in bitcoin script capabilities through the introduction of new opcodes related to cryptographic signature verification. These discussions are pivotal for understanding the proposal's implications on batch verification and the CHECKSIG FROM STACK (CSFS) functionalities. Specifically, Poelstra highlights the potential inclusion of a new opcode, CHECKSIGFROMSTACKADD (CSFSA), inspired by advanced miniscript applications presented by Rob Hamilton. The consideration for CSFSA stems from its anticipated common use and feasibility of implementation. Additionally, there's a debate on making CHECKSIGFROMSTACKVERIFY exclusively available to tapscript to align with BIP119 and CTV's objectives within legacy scripts. - Poelstra articulates concerns about maintaining consistency between the sets of public keys recognized by CSFS and those accepted by CHECKSIG operations. He suggests that diverging the types of public keys used by these functions could complicate future soft forks and development trajectories. Emphasizing uniformity, Poelstra argues against the necessity of differentiating public key sets for these operations, given the initial proposal's reliance on a single set for both functionalities. This stance underscores a broader reflection on the proposal's architectural decisions and their long-term implications on bitcoin's scripting language and operational integrity. - The proposal introduces OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY opcodes, aiming to extend bitcoin's script utility by allowing cryptographic checks against arbitrary data. This initiative represents a significant shift towards enhancing script functionalities beyond traditional transaction verification methods. The proposed opcodes, designed to conform with BIP 340 standards for Schnorr signatures, bring nuanced changes to bitcoin's scripting environment. They emphasize compatibility across script types, including legacy and segwitv0, through a soft-fork deployment strategy. The technical details underline strict adherence to public key size limitations and signature validation processes, reflecting a meticulous approach to integrating these opcodes without disrupting the existing ecosystem. - Further discussions in the proposal articulate the rationale behind distinct design choices, such as leveraging NOP5 for OP_CHECKSIGFROMSTACKVERIFY to ensure broad script compatibility and avoiding pre-hash message modifications in line with BIP 340 verification practices. The document also explores potential applications of the new opcodes, like improving Lightning Network symmetry and facilitating script-based delegation, highlighting their contribution to bitcoin's flexibility and functional depth. A reference implementation available on GitHub ([bitcoin/bitcoin29270](https://github.com/bitcoin/bitcoin/pull/29270)) offers a practical foundation for assessing the proposal's technical viability and alignment with bitcoin's developmental ethos. - In essence, the proposal for introducing OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY opcodes encapsulates a forward-looking enhancement to bitcoin's scripting capabilities. It carefully balances innovation with respect for the cryptocurrency's foundational principles, providing a detailed blueprint for augmenting bitcoin's transaction verification mechanisms and overall utility. - 2024-05-14T21:55:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_BIP-for-OP-INTERNALKEY.xml b/static/bitcoin-dev/April_2024/combined_BIP-for-OP-INTERNALKEY.xml index c9db82f119..d6824f8fd2 100644 --- a/static/bitcoin-dev/April_2024/combined_BIP-for-OP-INTERNALKEY.xml +++ b/static/bitcoin-dev/April_2024/combined_BIP-for-OP-INTERNALKEY.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - BIP for OP_INTERNALKEY - 2024-04-27T01:59:33.639252+00:00 - - Brandon Black 2024-04-26 16:03:00+00:00 - - - Garlo Nicon 2024-04-26 08:09:00+00:00 - - - Brandon Black 2024-04-25 05:22:00+00:00 - + 2025-09-26T14:41:43.689630+00:00 + python-feedgen + + + BIP for OP_INTERNALKEY Brandon Black + 2024-04-25T05:22:00.000Z + + + Garlo Nicon + 2024-04-26T08:09:00.000Z + + + Brandon Black + 2024-04-26T16:03:00.000Z + + - python-feedgen + 2 Combined summary - BIP for OP_INTERNALKEY - 2024-04-27T01:59:33.639299+00:00 + 2025-09-26T14:41:43.690295+00:00 + 2024-04-26T16:03:00+00:00 The introduction of the `OP_INTERNALKEY` opcode is a significant development within the Bitcoin scripting landscape, particularly for enhancing taproot script spends. This new opcode, proposed in a Bitcoin Improvement Proposal (BIP), aims to facilitate direct access to the taproot internal key, thereby offering a more efficient method for executing certain transactions. By replacing the `OP_SUCCESS203` opcode, `OP_INTERNALKEY` is tailored for scripts that execute under the leaf version `0xc0`, allowing for a more byte-efficient process in transactions that involve multiple parties or require additional conditions beyond the standard key path spend. - The rationale behind this proposal is to enable a smoother integration of script-based restrictions with the taproot internal key, which can lead to significant savings, notably 8 vBytes per transaction. This efficiency is crucial in scenarios such as hash-locked transactions where the internal key plays a pivotal role. The proposed opcode not only enhances transaction efficiency but also opens up new possibilities for secure, collective transaction agreements without the cumbersome overhead of control blocks typically associated with script path spending. - A reference implementation of `OP_INTERNALKEY` has been made available on GitHub ([reference implementation](https://github.com/bitcoin/bitcoin/pull/29269)), outlining how this addition could be seamlessly integrated into the current Bitcoin protocol via a soft fork. This approach ensures backward compatibility while addressing potential issues related to the transition from the `OP_SUCCESS203` behavior. Although still in the drafting phase, the proposal underscores ongoing discussions within the Bitcoin development community regarding its deployment and the broader implications for transaction scripting under the taproot framework. The openness of the BIP document, under the 3-clause BSD license, invites further review and contributions, reflecting the collaborative spirit of Bitcoin's evolution. - 2024-04-26T16:03:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_Bitcoin-Core-26-1-released.xml b/static/bitcoin-dev/April_2024/combined_Bitcoin-Core-26-1-released.xml index a36139b5a2..29a1a3d3da 100644 --- a/static/bitcoin-dev/April_2024/combined_Bitcoin-Core-26-1-released.xml +++ b/static/bitcoin-dev/April_2024/combined_Bitcoin-Core-26-1-released.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Bitcoin Core 26.1 released - 2024-04-18T02:00:26.806621+00:00 - - Peter Todd 2024-04-17 17:04:00+00:00 - - - Peter Todd 2024-04-10 19:50:00+00:00 - - - Gloria Zhao 2024-04-03 10:26:00+00:00 - + 2025-09-26T14:41:50.287319+00:00 + python-feedgen + + + Bitcoin Core 26.1 released Gloria Zhao + 2024-04-03T10:26:00.000Z + + + Peter Todd + 2024-04-10T19:50:00.000Z + + + Peter Todd + 2024-04-17T17:04:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Core 26.1 released - 2024-04-18T02:00:26.806679+00:00 + 2025-09-26T14:41:50.287860+00:00 + 2024-04-17T17:04:00+00:00 The recent updates in the Libre Relay and Bitcoin Core projects bring significant enhancements and new features for their users. The Libre Relay has introduced two key versions: 26.1, a stable update loaded with fixes and improvements, and 27.0rc1, a release candidate that offers experimental changes for developers and early adopters who wish to explore the cutting edge of technology. These versions are accessible via GitHub, with version 26.1 available at [Libre Relay v26.1](https://github.com/petertodd/bitcoin/tree/libre-relay-v26.1) and the release candidate for version 27.0 at [Libre Relay v27.0rc1](https://github.com/petertodd/bitcoin/tree/libre-relay-v27.0rc1). Additionally, Peter Todd's official website [Peter Todd's Official Website](https://petertodd.org) provides further insights and updates on these releases. For direct inquiries or feedback, communication can be established via email, following a specific format to ensure messages are directed appropriately. - Parallelly, the Bitcoin Core project announced the availability of its version 26.1, which can be downloaded from the [Bitcoin Core website](https://bitcoincore.org/bin/bitcoin-core-26.1/) or acquired through BitTorrent. This update is notable for its bug fixes, performance improvements, and updated translations aimed at refining user experience. Users upgrading from previous versions are advised to shut down their existing software properly before installing version 26.1 to ensure a smooth transition, especially when migrating from an end-of-life version. This version maintains support for older wallet versions, ensuring a broad compatibility across various operating systems, including Linux kernel-based systems, macOS 11.0 and newer, and Windows 7 and above. Among the highlighted updates are enhancements to wallet functionality, such as improved transaction scanning and keypool management for descriptor wallets, alongside various RPC fixes addressing issues like `getrawtransaction` segfaults and `.cookie` file retention problems. Moreover, version 26.1 improves P2P and network operations with adjustments to I2P session creation and block processing protocols. Development-wise, the release focuses on increasing stability and security, incorporating a hardened runtime on macOS builds and addressing specific build options. The continuous integration process also received updates to ensure more efficient operations across different environments. This collaborative effort involved numerous contributors, emphasizing the community-driven approach to developing and enhancing the Bitcoin Core software. - 2024-04-17T17:04:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_Draft-BIP-for-User-Defined-Transaction-Flags-Policy-Strategy.xml b/static/bitcoin-dev/April_2024/combined_Draft-BIP-for-User-Defined-Transaction-Flags-Policy-Strategy.xml index de6af7db71..38f3910bbf 100644 --- a/static/bitcoin-dev/April_2024/combined_Draft-BIP-for-User-Defined-Transaction-Flags-Policy-Strategy.xml +++ b/static/bitcoin-dev/April_2024/combined_Draft-BIP-for-User-Defined-Transaction-Flags-Policy-Strategy.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - Draft BIP for User-Defined Transaction Flags Policy & Strategy - 2024-04-17T02:03:49.167015+00:00 - - Antoine Riard 2024-04-16 02:01:00+00:00 - - - Keagan McClelland 2024-04-15 18:58:00+00:00 - - - Isaac Eiter 2024-04-14 20:12:00+00:00 - - - Peter Todd 2024-04-14 15:51:00+00:00 - - - Bitcoin Error Log 2024-04-14 15:09:00+00:00 - + 2025-09-26T14:41:35.164448+00:00 + python-feedgen + + + Draft BIP for User-Defined Transaction Flags Policy & Strategy Bitcoin Error Log + 2024-04-14T15:09:00.000Z + + + Peter Todd + 2024-04-14T15:51:00.000Z + + + Isaac Eiter + 2024-04-14T20:12:00.000Z + + + Keagan McClelland + 2024-04-15T18:58:00.000Z + + + Antoine Riard + 2024-04-16T02:01:00.000Z + + - python-feedgen + 2 Combined summary - Draft BIP for User-Defined Transaction Flags Policy & Strategy - 2024-04-17T02:03:49.167090+00:00 + 2025-09-26T14:41:35.165195+00:00 + 2024-04-16T02:01:00+00:00 The dialogue initially explores the technical and strategic challenges associated with integrating a direct transaction-relay infrastructure between Lightning nodes and miners, primarily focusing on potential misalignments in incentives. It highlights concerns over the introduction of privileged transaction-relay APIs, known as transaction accelerators, which prioritize transactions based on the reputation of mining pools rather than a standard fee rate market. This development raises fears about the erosion of a unified blockspace market, potentially leading to a loss of transparency and fairness in transaction processing prioritization. - Further examination reveals skepticism towards user intervention in blocking or promoting alternative transaction policies, such as Do Not Relay (DNR), within the Bitcoin network. The discussion posits that miner-driven interests may overshadow user preferences, potentially stagnating Bitcoin's growth despite community resistance. This perspective underscores the complex dynamics between miners' economic incentives and the broader network's health. Additionally, concerns are raised about the security and long-term viability of application-level mechanisms that might distort transaction propagation norms. - -On the topic of enhancing Bitcoin transactions for retail and service applications, the reliability of 0-confirmation transactions emerges as a critical issue. Given their vulnerability to fraud before block inclusion, suggestions like adding a "final" flag to denote completion are criticized for offering a false sense of security. The discourse emphasizes the non-viability of on-chain point-of-sale transactions within an economy fully integrated with Bitcoin, advocating for a pragmatic approach that values transaction verification over convenience. - +On the topic of enhancing Bitcoin transactions for retail and service applications, the reliability of 0-confirmation transactions emerges as a critical issue. Given their vulnerability to fraud before block inclusion, suggestions like adding a "final" flag to denote completion are criticized for offering a false sense of security. The discourse emphasizes the non-viability of on-chain point-of-sale transactions within an economy fully integrated with Bitcoin, advocating for a pragmatic approach that values transaction verification over convenience. The discussion also touches upon the support for forks like the Libre Relay and Full-RBF Peering versions, which facilitate full replace-by-fee (RBF) replacements. Mention of the significant hash rate backing full-RBF due to its fee-generating potential suggests a low likelihood of miners abandoning this practice. The conversation critiques opposition to full-RBF, recommending focus on productive technologies like the Lightning Network and suggesting official adoption in Bitcoin Core. - Finally, the proposed Bitcoin Improvement Proposal (BIP) by John Carvalho introduces user-defined transaction signals, Do-Not-Replace (DNR) and Replace-by-Fee (RBF), aiming to balance user autonomy with network efficiency. The proposal articulates a vision for more nuanced mempool policy management, leveraging these signals to adapt to varying transaction needs while maintaining Bitcoin’s decentralized principles. This initiative reflects a thoughtful approach to evolving Bitcoin's transaction processing landscape, proposing a blend of predictability, flexibility, and economic optimization through user-centric transaction flags. - 2024-04-16T02:01:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_Great-Consensus-Cleanup-Revival.xml b/static/bitcoin-dev/April_2024/combined_Great-Consensus-Cleanup-Revival.xml index 4509c7cd94..b3e9623069 100644 --- a/static/bitcoin-dev/April_2024/combined_Great-Consensus-Cleanup-Revival.xml +++ b/static/bitcoin-dev/April_2024/combined_Great-Consensus-Cleanup-Revival.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.043876+00:00 - - Antoine Riard 2024-11-28 05:18:00+00:00 - - - Murad Ali 2024-07-20 21:39:00+00:00 - - - Eric Voskuil 2024-07-20 20:29:00+00:00 - - - Antoine Riard 2024-07-18 17:39:00+00:00 - - - Eric Voskuil 2024-07-04 14:45:00+00:00 - - - Antoine Riard 2024-07-04 13:20:00+00:00 - - - Eric Voskuil 2024-07-03 23:29:00+00:00 - - - Eric Voskuil 2024-07-03 01:13:00+00:00 - - - Larry Ruane 2024-07-03 01:07:00+00:00 - - - Eric Voskuil 2024-07-02 15:57:00+00:00 - - - Antoine Poinsot 2024-07-02 10:23:00+00:00 - - - Antoine Riard 2024-07-02 02:36:00+00:00 - - - Eric Voskuil 2024-06-29 20:40:00+00:00 - - - Eric Voskuil 2024-06-29 20:29:00+00:00 - - - Antoine Riard 2024-06-29 01:53:00+00:00 - - - Eric Voskuil 2024-06-29 01:31:00+00:00 - - - Antoine Riard 2024-06-29 01:06:00+00:00 - - - Eric Voskuil 2024-06-28 17:14:00+00:00 - - - Antoine Poinsot 2024-06-27 09:35:00+00:00 - - - Eric Voskuil 2024-06-24 00:35:00+00:00 - - - Antoine Poinsot 2024-06-21 13:09:00+00:00 - - - Eric Voskuil 2024-06-18 13:02:00+00:00 - - - Antoine Poinsot 2024-06-18 08:13:00+00:00 - - - Eric Voskuil 2024-06-17 22:15:00+00:00 - - - Antoine Riard 2024-05-06 01:10:00+00:00 - - - Mark F 2024-04-30 22:20:00+00:00 - - - Antoine Riard 2024-04-25 06:08:00+00:00 - - - Antoine Poinsot 2024-04-18 10:04:00+00:00 - - - Mark F 2024-04-18 00:46:00+00:00 - - - Antoine Riard 2024-03-27 18:57:00+00:00 - - - Antoine Poinsot 2024-03-27 10:35:00+00:00 - - - Antoine Riard 2024-03-26 19:11:00+00:00 - - - Antoine Poinsot 2024-03-24 18:10:00+00:00 - + 2025-09-26T14:41:37.350234+00:00 + python-feedgen + + + Great Consensus Cleanup Revival 'Antoine Poinsot' + 2024-03-24T18:10:00.000Z + + + Antoine Riard + 2024-03-26T19:11:00.000Z + + + Antoine Poinsot' + 2024-03-27T10:35:00.000Z + + + Antoine Riard + 2024-03-27T18:57:00.000Z + + + Mark F + 2024-04-18T00:46:00.000Z + + + Antoine Poinsot' + 2024-04-18T10:04:00.000Z + + + Antoine Riard + 2024-04-25T06:08:00.000Z + + + Mark F + 2024-04-30T22:20:00.000Z + + + Antoine Riard + 2024-05-06T01:10:00.000Z + + + Eric Voskuil + 2024-06-17T22:15:00.000Z + + + Antoine Poinsot' + 2024-06-18T08:13:00.000Z + + + Eric Voskuil + 2024-06-18T13:02:00.000Z + + + Antoine Poinsot' + 2024-06-21T13:09:00.000Z + + + Eric Voskuil + 2024-06-24T00:35:00.000Z + + + Antoine Poinsot' + 2024-06-27T09:35:00.000Z + + + Eric Voskuil + 2024-06-28T17:14:00.000Z + + + Antoine Riard + 2024-06-29T01:06:00.000Z + + + Eric Voskuil + 2024-06-29T01:31:00.000Z + + + Antoine Riard + 2024-06-29T01:53:00.000Z + + + Eric Voskuil + 2024-06-29T20:29:00.000Z + + + Eric Voskuil + 2024-06-29T20:40:00.000Z + + + Antoine Riard + 2024-07-02T02:36:00.000Z + + + Antoine Poinsot' + 2024-07-02T10:23:00.000Z + + + Eric Voskuil + 2024-07-02T15:57:00.000Z + + + Larry Ruane + 2024-07-03T01:07:00.000Z + + + Eric Voskuil + 2024-07-03T01:13:00.000Z + + + Eric Voskuil + 2024-07-03T23:29:00.000Z + + + Antoine Riard + 2024-07-04T13:20:00.000Z + + + Eric Voskuil + 2024-07-04T14:45:00.000Z + + + Antoine Riard + 2024-07-18T17:39:00.000Z + + + Eric Voskuil + 2024-07-20T20:29:00.000Z + + + Murad Ali + 2024-07-20T21:39:00.000Z + + + Antoine Riard + 2024-11-28T05:18:00.000Z + + @@ -135,19 +171,16 @@ - python-feedgen + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.044085+00:00 + 2025-09-26T14:41:37.353581+00:00 + 2024-11-28T05:18:00+00:00 The conversation initiated by Antoine Poinsot sheds light on various aspects of the Bitcoin network's consensus mechanism, probing into areas that could benefit from improvement and adjustment. Poinsot zeroes in on concerns like the prolonged block validation times, which pose a threat to the network's overall efficacy and security framework. In response to this, he acknowledges existing solutions but proposes a supplementary strategy that caps the size of legacy transactions, aiming to bolster safety measures and ensure quicker validation processes. - Another significant point of discussion is the timewarp bug, which Poinsot indicates has not received the level of concern it rightfully demands. He emphasizes the critical need for addressing this flaw to safeguard the network’s stability. Moreover, the debate ventures into ensuring coinbase transaction uniqueness as a measure to circumvent the requirement for BIP30 validations beyond a specific block height, suggesting a potential pathway to streamline transaction verification while enhancing the network's security posture. - A nuanced proposal is introduced regarding the handling of transactions based on their sizes. Poinsot suggests maintaining the validity of transactions under 64 bytes while advocating for the invalidation of those exactly at this size threshold. This approach hints at a precise methodology aimed at refining transaction processing without imposing broad restrictions on transaction sizes. - The dialogue further extends an invitation to the community for additional insights, challenging others to identify possible disagreements, overlooked facets, or enhancements to the presented proposals. This initiative underscores a commitment to collaborative progress, aiming to cultivate a constructive forum for discussion that could lead to substantial improvements within the Bitcoin consensus mechanism. Through this exchange, Poinsot not only highlights key areas of concern but also catalyzes a broader dialogue aimed at fortifying the network against potential vulnerabilities and inefficiencies. - 2024-11-28T05:18:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_Security-implications-of-using-pseudorandom-JSON-RPC-IDs.xml b/static/bitcoin-dev/April_2024/combined_Security-implications-of-using-pseudorandom-JSON-RPC-IDs.xml index b1d8a1f82b..d8d85df86f 100644 --- a/static/bitcoin-dev/April_2024/combined_Security-implications-of-using-pseudorandom-JSON-RPC-IDs.xml +++ b/static/bitcoin-dev/April_2024/combined_Security-implications-of-using-pseudorandom-JSON-RPC-IDs.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Security implications of using pseudorandom JSON-RPC IDs - 2024-04-10T02:06:37.859800+00:00 - - Antoine Riard 2024-04-09 23:35:00+00:00 - - - Ali Sherief 2024-04-07 08:03:00+00:00 - - - Ali Sherief 2024-04-07 05:57:00+00:00 - + 2025-09-26T14:41:30.909873+00:00 + python-feedgen + + + Security implications of using pseudorandom JSON-RPC IDs Ali Sherief + 2024-04-07T05:57:00.000Z + + + Ali Sherief + 2024-04-07T08:03:00.000Z + + + Antoine Riard + 2024-04-09T23:35:00.000Z + + - python-feedgen + 2 Combined summary - Security implications of using pseudorandom JSON-RPC IDs - 2024-04-10T02:06:37.859846+00:00 + 2025-09-26T14:41:30.910452+00:00 + 2024-04-09T23:35:00+00:00 The forwarded email sheds light on a range of technical and security issues associated with the Bitcoin Core RPC protocol, specifically focusing on the use of pseudorandom JSON-RPC IDs and the potential vulnerabilities this practice may introduce. The discussion centers around the inherent risk in employing predictable or insufficiently random numbers for JSON-RPC request identifiers, which could lead systems to become susceptible to attacks such as replay and injection. Such attacks might allow an attacker to intercept or deduce the ID of a JSON-RPC call, leading to unauthorized commands or requests being issued. To counteract these vulnerabilities, the message underscores the importance of utilizing strong, cryptographically secure pseudorandom number generators (CSPRNGs). This approach is highlighted as a critical measure in safeguarding the integrity and confidentiality of communications between clients and servers within the Bitcoin network. - Furthermore, the conversation expands to consider broader security concerns that extend beyond Bitcoin development to include general web service and application security. This reflects a growing acknowledgment among developers of the necessity for stringent security protocols in all facets of system design and implementation. A [link](https://developer.bitcoin.org/devguide/security-practices.html) provided in the message serves both as a resource and a call to action, urging developers to engage with ongoing discussions and advancements in cybersecurity, particularly those related to cryptocurrency technologies. - Additionally, the email addresses concerns regarding the handling of UniValue JSON-RPC requests by Bitcoin Core's RPC server, highlighting the possibility of security breaches arising from the assignment of identical pseudorandom IDs to simultaneous JSON-RPC calls. Such scenarios could potentially lead to incorrect responses being sent to users, thereby jeopardizing the application's data exchange integrity. Despite thorough search efforts within the Bitcoin Core GitHub codebase, documentation or examples elucidating the storage and management mechanisms for these JSON-RPC requests remain scarce. The absence of clear information necessitates further exploration into how Bitcoin Core ensures the accurate association of each request with its corresponding response, especially in cases involving pseudorandom ID generation. Understanding the specific processes and safeguards implemented by Bitcoin Core to prevent response cross-contamination among different users' requests is deemed crucial for maintaining the system's reliability and confidentiality. - 2024-04-09T23:35:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml b/static/bitcoin-dev/April_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml index fa98b6b549..643117fb50 100644 --- a/static/bitcoin-dev/April_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml +++ b/static/bitcoin-dev/April_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) - 2024-11-18T02:30:36.698421+00:00 - - Ethan Heilman 2024-11-17 21:59:00+00:00 - - - Ethan Heilman 2024-11-16 14:55:00+00:00 - - - Xiaohui Liu 2024-11-15 21:54:00+00:00 - - - Garlo Nicon 2024-10-25 09:58:00+00:00 - - - Vicky 2024-10-25 00:20:00+00:00 - - - Antoine Riard 2024-05-11 02:53:00+00:00 - - - Andrew Poelstra 2024-05-09 12:46:00+00:00 - - - Ben Carman 2024-05-09 00:31:00+00:00 - - - Ethan Heilman 2024-05-07 16:05:00+00:00 - - - Andrew Poelstra 2024-05-07 14:34:00+00:00 - - - David A. Harding 2024-05-07 04:11:00+00:00 - - - Antoine Riard 2024-05-07 00:55:00+00:00 - - - Andrew Poelstra 2024-05-06 19:06:00+00:00 - - - David A. Harding 2024-05-06 18:56:00+00:00 - - - Andrew Poelstra 2024-05-06 16:48:00+00:00 - - - David A. Harding 2024-05-06 07:39:00+00:00 - - - Ethan Heilman 2024-05-01 20:02:00+00:00 - - - Antoine Riard 2024-05-01 03:46:00+00:00 - - - Ethan Heilman 2024-04-30 20:43:00+00:00 - - - Andrew Poelstra 2024-04-30 14:21:00+00:00 - - - Ethan Heilman 2024-04-30 13:25:00+00:00 - - - Matthew Zipkin 2024-04-30 12:32:00+00:00 - - - Ethan Heilman 2024-04-29 00:30:00+00:00 - + 2025-09-26T14:41:45.871841+00:00 + python-feedgen + + + Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) Ethan Heilman + 2024-04-29T00:30:00.000Z + + + Matthew Zipkin + 2024-04-30T12:32:00.000Z + + + Ethan Heilman + 2024-04-30T13:25:00.000Z + + + Andrew Poelstra + 2024-04-30T14:21:00.000Z + + + Ethan Heilman + 2024-04-30T20:43:00.000Z + + + Antoine Riard + 2024-05-01T03:46:00.000Z + + + Ethan Heilman + 2024-05-01T20:02:00.000Z + + + David A. Harding + 2024-05-06T07:39:00.000Z + + + Andrew Poelstra + 2024-05-06T16:48:00.000Z + + + David A. Harding + 2024-05-06T18:56:00.000Z + + + Andrew Poelstra + 2024-05-06T19:06:00.000Z + + + Antoine Riard + 2024-05-07T00:55:00.000Z + + + David A. Harding + 2024-05-07T04:11:00.000Z + + + Andrew Poelstra + 2024-05-07T14:34:00.000Z + + + Ethan Heilman + 2024-05-07T16:05:00.000Z + + + Ben Carman + 2024-05-09T00:31:00.000Z + + + Andrew Poelstra + 2024-05-09T12:46:00.000Z + + + Antoine Riard + 2024-05-11T02:53:00.000Z + + + Vicky + 2024-10-25T00:20:00.000Z + + + Garlo Nicon + 2024-10-25T09:58:00.000Z + + + Xiaohui Liu + 2024-11-15T21:54:00.000Z + + + Ethan Heilman + 2024-11-16T14:55:00.000Z + + + Ethan Heilman + 2024-11-17T21:59:00.000Z + + @@ -95,35 +121,24 @@ - python-feedgen + 2 Combined summary - Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) - 2024-11-18T02:30:36.698570+00:00 + 2025-09-26T14:41:45.874525+00:00 + 2024-11-17T21:59:00+00:00 The conversation explores innovative approaches to blockchain technology, particularly focusing on the implementation of covenants and introspection within Bitcoin's blockchain without necessitating OP_CAT. The dialogue delves into the limitations and potentials of utilizing opcodes like OP_SIZE for creating sophisticated contracts or covenants. It outlines a theoretical framework where an unlimited opcode set could enable small scripts capable of enforcing rules or conditions by introspecting the entire blockchain, potentially incorporating snarks to maintain script size while enhancing privacy and security through cryptographic methods. - The discussion also touches upon the complexities of implementing covenants in Bitcoin's scripting language, highlighting the technical challenges involved in parsing transaction fields without OP_CAT. This inquiry underscores the foundational aspects of Bitcoin's programmability and security features, emphasizing the need for developers to understand these mechanisms thoroughly. - Further, the conversation shifts to examining the security implications of using multiple private keys for generating specific addresses, illustrating the computational difficulty associated with this process through examples of one-byte and two-byte grinds. This illustration serves to highlight the nuanced strategy in multisignature setups within the Bitcoin protocol, showcasing how developers can leverage cryptographic signatures to balance accessibility and security according to the needs of a transaction or wallet. - In another part of the conversation, the focus shifts to the examination of ECDSA signature size distribution within Bitcoin's cryptographic framework, discussing the practicality of enhancing transaction security through signature batching. Additionally, Adam's proposal on Proof-of-Work locked outputs is explored as a more feasible approach than employing full Lamport signature schemes, further probing the security model and practical applications of these cryptographic enhancements in light of Bitcoin's operability constraints. - -Antoine's email to Ethan provides an in-depth analysis of cryptographic techniques related to transaction security and flexibility within blockchain technologies. It discusses vulnerabilities and innovations in Lamport and ECDSA/Schnorr signatures, emphasizing the potential risks and solutions to secure transactions against quantum computing threats. The concept of a "faux-ctv" variant leveraging BIP118 for no-input signatures is introduced, offering insights into the evolving landscape of blockchain security and transaction integrity. - +Antoine's email to Ethan provides an in-depth analysis of cryptographic techniques related to transaction security and flexibility within blockchain technologies. It discusses vulnerabilities and innovations in Lamport and ECDSA/Schnorr signatures, emphasizing the potential risks and solutions to secure transactions against quantum computing threats. The concept of a "faux-ctv" variant leveraging BIP118 for no-input signatures is introduced, offering insights into the evolving landscape of blockchain security and transaction integrity. Andrew Poelstra's insight into transaction signing processes within blockchain highlights the importance of sighash flags in ensuring transaction integrity, providing a deeper understanding of blockchain technology's technical nuances. His affiliation with Blockstream Research and contributions to the field are acknowledged, inviting further exploration of his work for those interested in blockchain advancements. - The dialogue between Ethan Heilman and David A. Harding sheds light on novel techniques to implement covenants in Bitcoin's scripting language, tapscript, despite opcode limitations. This conversation underlines ongoing explorations into expanding Bitcoin's scripting capabilities, reflecting broader interests in enhancing smart contract provisions on the platform. - A nuanced discussion among blockchain enthusiasts addresses several key points regarding fee bumping, signature validation, and quantum computing vulnerabilities in Bitcoin transactions. This exchange encapsulates a deep understanding of managing transaction fees, ensuring signature security, and preparing for technological threats to the cryptocurrency protocol. - Andrew Poelstra's method to bridge gaps between pre-Taproot and post-Taproot transaction outputs using anti-equivocation schemes exemplifies innovative solutions to enhance Bitcoin's security measures without relying on newer Schnorr signatures. This proposal underscores creative approaches to developing blockchain technology within the constraints of Bitcoin's scripting language. - The discussion between Antoine Riard and Andrew Poelstra, involving Matthew Zipkin and Ethan Heilman, revolves around the intricacies of integrating ECDSA and Schnorr signatures within Tapscript. This technical exploration reveals the complexity and potential confusion surrounding cryptographic and scripting innovations, reflecting efforts to evolve Bitcoin's scripting abilities for increased transaction verification and execution flexibility. - The conversation highlights a potential vulnerability in using Lamport public keys for blockchain transactions, pointing out the susceptibility to DoS attacks and issues related to signature algorithms like ECDSA. Concerns about the robustness of such schemes against attackers with considerable computational resources are raised, alongside discussions on improving the overall resilience of the system through technical adjustments. - This comprehensive summary encapsulates the multifaceted discussions on cryptographic techniques, security concerns, and innovative approaches to enhancing Bitcoin's functionality and security. The conversations reflect the collaborative effort and ongoing research within the blockchain community to address technical challenges and expand the capabilities of cryptocurrency platforms. - 2024-11-17T21:59:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_Test-cases-for-signing-legacy-inputs-in-transactions.xml b/static/bitcoin-dev/April_2024/combined_Test-cases-for-signing-legacy-inputs-in-transactions.xml index 06d49e7715..df63e86f7c 100644 --- a/static/bitcoin-dev/April_2024/combined_Test-cases-for-signing-legacy-inputs-in-transactions.xml +++ b/static/bitcoin-dev/April_2024/combined_Test-cases-for-signing-legacy-inputs-in-transactions.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Test cases for signing legacy inputs in transactions - 2024-05-04T03:09:42.518325+00:00 - - Ali Sherief 2024-05-02 10:29:00+00:00 - - - Edil Guimarães de Medeiros 2024-04-30 12:48:00+00:00 - - - Ali Sherief 2024-04-30 11:43:00+00:00 - + 2025-09-26T14:41:33.020192+00:00 + python-feedgen + + + Test cases for signing legacy inputs in transactions Ali Sherief + 2024-04-30T11:43:00.000Z + + + Edil Guimarães de Medeiros + 2024-04-30T12:48:00.000Z + + + Ali Sherief + 2024-05-02T10:29:00.000Z + + - python-feedgen + 2 Combined summary - Test cases for signing legacy inputs in transactions - 2024-05-04T03:09:42.518386+00:00 + 2025-09-26T14:41:33.020716+00:00 + 2024-05-02T10:29:00+00:00 The conversation delves into the complexities and considerations involved in using core to generate private keys and legacy transactions within a software framework. It touches upon the trust placed in core as a standard for transaction implementation, while also acknowledging the limitations of relying solely on one's own generated Core transactions due to the inability to cover all edge cases. This discussion reflects a broader acknowledgment within the network of the existing compatibility with core, despite potential flaws, suggesting an industry-wide acceptance of its role. However, it raises concerns over the simplicity of this approach, prompting a call for further scrutiny in relation to software development practices, particularly those concerning security and reliability in transaction processing. - Ali highlights the challenges encountered in testing reproducible legacy transactions, stemming primarily from the lack of crucial debugging information and the non-determinism introduced by using OpenSSL for signature creation. This situation underscores the difficulties developers face in ensuring the reliability of transaction constructors in BIP143 and the need for improved testing methodologies. The absence of raw legacy transactions accompanied by their private keys is identified as a significant obstacle, emphasizing the necessity for resources that offer comprehensive and deterministic data sets for effective software testing. This conversation points towards a pressing demand within the programming community for better testing environments that accommodate legacy transaction formats, thereby facilitating more reliable blockchain technology development and assessment. - 2024-05-02T10:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_The-Future-of-Bitcoin-Testnet.xml b/static/bitcoin-dev/April_2024/combined_The-Future-of-Bitcoin-Testnet.xml index 45054a7a94..18e7fa7e5b 100644 --- a/static/bitcoin-dev/April_2024/combined_The-Future-of-Bitcoin-Testnet.xml +++ b/static/bitcoin-dev/April_2024/combined_The-Future-of-Bitcoin-Testnet.xml @@ -1,134 +1,179 @@ - + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303256+00:00 - - Saint Wenhao 2025-04-25 17:19:00+00:00 - - - Garlo Nicon 2025-03-31 10:48:00+00:00 - - - Peter Todd 2024-05-04 17:13:00+00:00 - - - Peter Todd 2024-05-04 17:08:00+00:00 - - - Ali Sherief 2024-05-02 07:10:00+00:00 - - - Garlo Nicon 2024-05-01 15:30:00+00:00 - - - Matthew Bagazinski 2024-04-30 18:46:00+00:00 - - - Matt Corallo 2024-04-28 13:45:00+00:00 - - - Ali Sherief 2024-04-22 04:33:00+00:00 - - - Sjors Provoost 2024-04-16 17:30:00+00:00 - - - Garlo Nicon 2024-04-10 06:57:00+00:00 - - - Garlo Nicon 2024-04-09 18:28:00+00:00 - - - Peter Todd 2024-04-09 16:48:00+00:00 - - - coinableS 2024-04-09 04:29:00+00:00 - - - Garlo Nicon 2024-04-08 19:11:00+00:00 - - - K Calvin 2024-04-07 08:09:00+00:00 - - - Christian Decker 2024-04-07 07:20:00+00:00 - - - David A. Harding 2024-04-06 23:04:00+00:00 - - - Calvin Kim 2024-04-05 04:30:00+00:00 - - - Jameson Lopp 2024-04-04 12:47:00+00:00 - - - Calvin Kim 2024-04-04 08:14:00+00:00 - - - Andrew Poelstra 2024-04-03 19:35:00+00:00 - - - emsit 2024-04-03 18:18:00+00:00 - - - Anthony Towns 2024-04-03 04:19:00+00:00 - - - Jameson Lopp 2024-04-02 19:46:00+00:00 - - - Lukáš Kráľ 2024-04-02 18:36:00+00:00 - - - Jameson Lopp 2024-04-02 11:53:00+00:00 - - - Fabian 2024-04-01 22:01:00+00:00 - - - emsit 2024-04-01 19:22:00+00:00 - - - Warren Togami 2024-04-01 14:28:00+00:00 - - - Andrew Poelstra 2024-04-01 14:20:00+00:00 - - - Pieter Wuille 2024-04-01 13:37:00+00:00 - - - Fabian 2024-04-01 13:32:00+00:00 - - - Peter Todd 2024-04-01 13:25:00+00:00 - - - Jameson Lopp 2024-04-01 12:54:00+00:00 - - - Peter Todd 2024-03-31 21:29:00+00:00 - - - Nagaev Boris 2024-03-31 21:01:00+00:00 - - - Eric Voskuil 2024-03-31 17:21:00+00:00 - - - Peter Todd 2024-03-31 16:02:00+00:00 - - - Jameson Lopp 2024-03-31 14:57:00+00:00 - - - Luke Dashjr 2024-03-31 14:33:00+00:00 - - - Jameson Lopp 2024-03-31 13:19:00+00:00 - + 2025-09-26T14:41:52.471920+00:00 + python-feedgen + + + The Future of Bitcoin Testnet Jameson Lopp + 2024-03-31T13:19:00.000Z + + + Luke Dashjr + 2024-03-31T14:33:00.000Z + + + Jameson Lopp + 2024-03-31T14:57:00.000Z + + + Peter Todd + 2024-03-31T16:02:00.000Z + + + Eric Voskuil + 2024-03-31T17:21:00.000Z + + + Nagaev Boris + 2024-03-31T21:01:00.000Z + + + Peter Todd + 2024-03-31T21:29:00.000Z + + + Jameson Lopp + 2024-04-01T12:54:00.000Z + + + Andrew Poelstra + 2024-04-01T13:25:00.000Z + + + Fabian' + 2024-04-01T13:32:00.000Z + + + Pieter Wuille + 2024-04-01T13:37:00.000Z + + + Andrew Poelstra + 2024-04-01T14:20:00.000Z + + + Warren Togami + 2024-04-01T14:28:00.000Z + + + emsit + 2024-04-01T19:22:00.000Z + + + Fabian' + 2024-04-01T22:01:00.000Z + + + Jameson Lopp + 2024-04-02T11:53:00.000Z + + + Lukáš Kráľ + 2024-04-02T18:36:00.000Z + + + Jameson Lopp + 2024-04-02T19:46:00.000Z + + + Anthony Towns + 2024-04-03T04:19:00.000Z + + + emsit + 2024-04-03T18:18:00.000Z + + + Andrew Poelstra + 2024-04-03T19:35:00.000Z + + + Calvin Kim + 2024-04-04T08:14:00.000Z + + + Jameson Lopp + 2024-04-04T12:47:00.000Z + + + Calvin Kim + 2024-04-05T04:30:00.000Z + + + David A. Harding + 2024-04-06T23:04:00.000Z + + + Christian Decker + 2024-04-07T07:20:00.000Z + + + K Calvin + 2024-04-07T08:09:00.000Z + + + Garlo Nicon + 2024-04-08T19:11:00.000Z + + + coinableS + 2024-04-09T04:29:00.000Z + + + Peter Todd + 2024-04-09T16:48:00.000Z + + + Garlo Nicon + 2024-04-09T18:28:00.000Z + + + Garlo Nicon + 2024-04-10T06:57:00.000Z + + + Sjors Provoost' + 2024-04-16T17:30:00.000Z + + + Ali Sherief + 2024-04-22T04:33:00.000Z + + + Matt Corallo + 2024-04-28T13:45:00.000Z + + + Matthew Bagazinski + 2024-04-30T18:46:00.000Z + + + Garlo Nicon + 2024-05-01T15:30:00.000Z + + + Ali Sherief + 2024-05-02T07:10:00.000Z + + + Peter Todd + 2024-05-04T17:08:00.000Z + + + Peter Todd + 2024-05-04T17:13:00.000Z + + + Garlo Nicon + 2025-03-31T10:48:00.000Z + + + Saint Wenhao + 2025-04-25T17:19:00.000Z + + @@ -171,17 +216,15 @@ - python-feedgen + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303535+00:00 + 2025-09-26T14:41:52.476013+00:00 + 2025-04-25T17:19:00+00:00 The discourse surrounding the future and functionality of Bitcoin's testnet3 brings to light several pressing issues and proposals for its evolution. Testnet3, after 13 years of operation and reaching a block height of approximately 2.5 million, finds itself at a crossroads due to a significantly reduced block reward and operational challenges arising from an edge case bug that resets the mining difficulty to one. This anomaly has led to operational inconsistencies and raised concerns about the effective distribution of testnet coins, as detailed in Jameson Lopp’s comprehensive analysis available [here](https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/). Furthermore, the network faces exploitation through scammy airdrops and an unintended marketplace where TBTC is actively traded, deviating from its foundational principle that testnet coins should hold no real-world value. - In response to these challenges, several key questions and proposals are presented to the community. The potential for a testnet reset is considered, recognizing the need for substantial notice due to the extensive updates required for production systems. Additionally, addressing the difficulty reset bug emerges as a priority, with suggestions for a straightforward code fix that might necessitate a hard fork. This approach, while potentially disruptive, could naturally integrate into the network's dynamics if executed thoughtfully. The necessity of formalizing this process through a Bitcoin Improvement Proposal (BIP) or adopting a more informal implementation strategy remains a point of debate. - Moreover, the discussion extends to the possibility of deprecating testnet3 in favor of signet, highlighting an ongoing exploration of alternative testing environments that might better serve the needs of the Bitcoin development community. This conversation reflects a broader debate on balancing innovation and stability within Bitcoin's development platforms, emphasizing the importance of community feedback and collaborative decision-making in navigating the future of testnet3. The dialogue ultimately underscores the complexities of managing blockchain networks like Bitcoin, where technical adjustments must consider both their immediate impact and broader implications for developers, miners, and the ecosystem at large. - 2025-04-25T17:19:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2024/combined_Updated-BIP-for-OP-CAT.xml b/static/bitcoin-dev/April_2024/combined_Updated-BIP-for-OP-CAT.xml index 148f16edd5..488bda0601 100644 --- a/static/bitcoin-dev/April_2024/combined_Updated-BIP-for-OP-CAT.xml +++ b/static/bitcoin-dev/April_2024/combined_Updated-BIP-for-OP-CAT.xml @@ -1,37 +1,41 @@ - + 2 Combined summary - Updated BIP for OP_CAT - 2024-04-27T01:58:55.466369+00:00 - - Ethan Heilman 2024-04-26 00:34:00+00:00 - - - Ethan Heilman 2024-04-22 21:51:00+00:00 - - - Ali Sherief 2024-04-22 16:09:00+00:00 - - - Ethan Heilman 2024-04-16 19:03:00+00:00 - + 2025-09-26T14:41:41.578331+00:00 + python-feedgen + + + Updated BIP for OP_CAT Ethan Heilman + 2024-04-16T19:03:00.000Z + + + Ali Sherief + 2024-04-22T16:09:00.000Z + + + Ethan Heilman + 2024-04-22T21:51:00.000Z + + + Ethan Heilman + 2024-04-26T00:34:00.000Z + + - python-feedgen + 2 Combined summary - Updated BIP for OP_CAT - 2024-04-27T01:58:55.466421+00:00 + 2025-09-26T14:41:41.578942+00:00 + 2024-04-26T00:34:00+00:00 The Bitcoin Improvement Proposal (BIP) for OP_CAT has been a focal point of discussion within the cryptocurrency community. Ethan Heilman recently made a significant update to the proposal, specifically addressing the theoretical maximum of public keys that could be supported by OP_CAT scripts. This update was shared through a commit on GitHub, emphasizing the importance of clarity and utility in such proposals. Heilman's contribution is viewed as a response to suggestions from the community regarding the inclusion of a theoretical limit for tree signatures, aiming to enhance the comprehensiveness of the BIP. - Armin and Ali Sherief, the authors behind the OP_CAT BIP, have formally requested a BIP number for their proposal, indicating a step forward in its official recognition. Despite widespread discussions on social media platforms, particularly Twitter, it's important to note that no BIP number has been assigned to OP_CAT as of yet. This situation underscores the discrepancy between information circulated through official channels and that discussed on social media. - The recent updates to the OP_CAT BIP not only include a clarification of its technical capabilities but also introduce several key enhancements aimed at improving its overall framework. A new rationale section provides deeper insights into the proposal's objectives and benefits, while an expanded examination of backwards compatibility addresses integration with existing systems. Additionally, an updated reference implementation has been made available. The revised proposal is accessible via a pull request in the bitcoin/bips repository and as BINANA BIN-2024-0001, hosted on the Bitcoin Inquisition's GitHub page. These revisions are designed to ensure that the proposal is clearly understood and thoroughly evaluated by the broader Bitcoin community. - Furthermore, the dialogue surrounding the OP_CAT BIP highlights the evolving nature of Bitcoin's technical landscape. The consideration of tree signatures within this context points to the potential for innovative enhancements to Bitcoin's functionality. The progression of such ideas from mere concepts to integral components of Bitcoin's protocol reflects the dynamic interplay between theoretical exploration and practical application within the cryptocurrency ecosystem. - 2024-04-26T00:34:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_-meta-moving-conceptual-discussion-for-policy-changes.xml b/static/bitcoin-dev/April_2025/combined_-meta-moving-conceptual-discussion-for-policy-changes.xml index fede5733c6..7db0c4f490 100644 --- a/static/bitcoin-dev/April_2025/combined_-meta-moving-conceptual-discussion-for-policy-changes.xml +++ b/static/bitcoin-dev/April_2025/combined_-meta-moving-conceptual-discussion-for-policy-changes.xml @@ -1,29 +1,31 @@ - + 2 Combined summary - [meta] moving conceptual discussion for policy changes - 2025-05-01T02:57:27.120659+00:00 - - Sjors Provoost 2025-04-30 15:49:00+00:00 - - - Matthew Zipkin 2025-04-30 14:30:00+00:00 - + 2025-09-26T14:36:30.992023+00:00 + python-feedgen + + + [meta] moving conceptual discussion for policy changes 'Matthew Zipkin' + 2025-04-30T14:30:00.000Z + + + Sjors Provoost + 2025-04-30T15:49:00.000Z + + - python-feedgen + 2 Combined summary - [meta] moving conceptual discussion for policy changes - 2025-05-01T02:57:27.120698+00:00 + 2025-09-26T14:36:30.992465+00:00 + 2025-04-30T15:49:00+00:00 The discourse around managing feedback and concerns regarding pull requests (PRs) in the context of Bitcoin development reveals a nuanced understanding of community engagement and the challenges of online behavior. A recurring issue highlighted is the tendency for discussions to escalate on social media platforms, often leading to a barrage of impulsive and sometimes destructive comments. This phenomenon can be attributed to various factors, including the immediate visibility and reach provided by social media and the emotional reactions triggered when individuals feel their voices are not adequately heard through conventional channels such as GitHub or mailing lists. - To address these challenges, several proposals have been put forth aimed at streamlining the process of soliciting and integrating community feedback on proposed changes to Bitcoin Core. One suggestion involves imposing a delay between announcing a proposed change on the mailing list and the actual submission of the PR. This approach aims to mitigate the sense of surprise or urgency that may compel individuals to react impulsively. Furthermore, marking a PR as a draft with explicit instructions not to merge before a certain date could help set clear expectations and reduce misunderstandings. - -In an effort to foster more informed and constructive dialogue, it has also been proposed to introduce an intermediary step between the mailing list discussion and the PR submission. Utilizing GitHub "discussions" as a platform for this purpose could offer a structured environment for presenting comprehensive information about proposed changes, including pros, cons, frequently asked questions, and myth-busting. Engaging titles and summaries could serve to attract attention and drive traffic to these discussions, potentially transforming the initial burst of social media activity into a directed flow of interested stakeholders towards a centralized source of information. - +In an effort to foster more informed and constructive dialogue, it has also been proposed to introduce an intermediary step between the mailing list discussion and the PR submission. Utilizing GitHub "discussions" as a platform for this purpose could offer a structured environment for presenting comprehensive information about proposed changes, including pros, cons, frequently asked questions, and myth-busting. Engaging titles and summaries could serve to attract attention and drive traffic to these discussions, potentially transforming the initial burst of social media activity into a directed flow of interested stakeholders towards a centralized source of information. These strategies underscore the importance of giving well-intentioned community members ample opportunity to voice their opinions in a manner that is both respectful and constructive. By carefully managing the timeline and format of discussions surrounding policy changes or controversial code modifications, the Bitcoin development community can aim to reduce unnecessary friction and encourage a more productive exchange of ideas. - 2025-04-30T15:49:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_BIP-Proposal-Define-Bitcoin-Subunits-as-Satoshis-Sats.xml b/static/bitcoin-dev/April_2025/combined_BIP-Proposal-Define-Bitcoin-Subunits-as-Satoshis-Sats.xml index b7d74679be..1405613db1 100644 --- a/static/bitcoin-dev/April_2025/combined_BIP-Proposal-Define-Bitcoin-Subunits-as-Satoshis-Sats.xml +++ b/static/bitcoin-dev/April_2025/combined_BIP-Proposal-Define-Bitcoin-Subunits-as-Satoshis-Sats.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - BIP Proposal: Define Bitcoin Subunits as Satoshis/Sats - 2025-05-04T02:58:58.623663+00:00 - - Jakub Szwedo 2025-05-02 20:54:00+00:00 - - - Lucas André 2025-04-29 22:10:00+00:00 - - - OceanSlim 2025-04-29 12:18:00+00:00 - + 2025-09-26T14:36:43.757185+00:00 + python-feedgen + + + BIP Proposal: Define Bitcoin Subunits as Satoshis/Sats 'OceanSlim' + 2025-04-29T12:18:00.000Z + + + Lucas André + 2025-04-29T22:10:00.000Z + + + Jakub Szwedo + 2025-05-02T20:54:00.000Z + + - python-feedgen + 2 Combined summary - BIP Proposal: Define Bitcoin Subunits as Satoshis/Sats - 2025-05-04T02:58:58.623710+00:00 + 2025-09-26T14:36:43.757716+00:00 - The email highlights a proposal to integrate accessibility and voice/UI guidance into a Bitcoin Improvement Proposal (BIP) aimed at standardizing the terminology around Bitcoin's smallest unit. This suggested addition aims to make digital communication more inclusive, particularly for users of assistive technologies. It outlines a detailed approach towards ensuring that numerical values are accessible in screen readers, voice assistants, and other accessible interfaces. For instance, it recommends converting "1 sat" to "one satoshi" and provides a phonetic transcription to aid in pronunciation by speech-based technologies. To support these guidelines, it references resources on the International Phonetic Alphabet and a phonetics conversion tool, which could be instrumental in developing comprehensive accessibility standards. - -Furthermore, the email addresses the core purpose of the proposed BIP, which is to formally recognize "satoshi" as the standard term for the smallest Bitcoin unit, and "satoshis" for its plural form, with "sats" as an abbreviation. This effort seeks to eliminate inconsistencies in the terminology's usage across different platforms, without altering Bitcoin's unit structure. It distinguishes this BIP from previous proposals, such as BIP-176 and BIP-177, which focused on denomination changes rather than terminology standardization. The proposer encourages feedback and suggestions from the community to refine the proposal, which is available for review. This initiative underscores the importance of standardizing digital currency terminology while ensuring accessibility for all users, reflecting a commitment to inclusivity in technological development. 2025-05-02T20:54:00+00:00 + The email highlights a proposal to integrate accessibility and voice/UI guidance into a Bitcoin Improvement Proposal (BIP) aimed at standardizing the terminology around Bitcoin's smallest unit. This suggested addition aims to make digital communication more inclusive, particularly for users of assistive technologies. It outlines a detailed approach towards ensuring that numerical values are accessible in screen readers, voice assistants, and other accessible interfaces. For instance, it recommends converting "1 sat" to "one satoshi" and provides a phonetic transcription to aid in pronunciation by speech-based technologies. To support these guidelines, it references resources on the International Phonetic Alphabet and a phonetics conversion tool, which could be instrumental in developing comprehensive accessibility standards. +Furthermore, the email addresses the core purpose of the proposed BIP, which is to formally recognize "satoshi" as the standard term for the smallest Bitcoin unit, and "satoshis" for its plural form, with "sats" as an abbreviation. This effort seeks to eliminate inconsistencies in the terminology's usage across different platforms, without altering Bitcoin's unit structure. It distinguishes this BIP from previous proposals, such as BIP-176 and BIP-177, which focused on denomination changes rather than terminology standardization. The proposer encourages feedback and suggestions from the community to refine the proposal, which is available for review. This initiative underscores the importance of standardizing digital currency terminology while ensuring accessibility for all users, reflecting a commitment to inclusivity in technological development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml b/static/bitcoin-dev/April_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml index 9592354c5c..5db2167021 100644 --- a/static/bitcoin-dev/April_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml +++ b/static/bitcoin-dev/April_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures - 2025-07-18T03:07:52.835406+00:00 - - Jonas Nick 2025-07-17 13:15:00+00:00 - - - waxwing/ AdamISZ 2025-07-03 14:07:00+00:00 - - - Tim Ruffing 2025-07-02 11:36:00+00:00 - - - waxwing/ AdamISZ 2025-06-16 19:35:00+00:00 - - - waxwing/ AdamISZ 2025-04-30 15:54:00+00:00 - - - Jonas Nick 2025-04-30 07:59:00+00:00 - - - waxwing/ AdamISZ 2025-04-26 17:05:00+00:00 - - - waxwing/ AdamISZ 2025-04-26 15:30:00+00:00 - - - Jonas Nick 2025-04-25 16:41:00+00:00 - - - waxwing/ AdamISZ 2025-04-25 16:08:00+00:00 - - - Jonas Nick 2025-04-22 15:29:00+00:00 - - - waxwing/ AdamISZ 2025-04-19 16:28:00+00:00 - - - Jonas Nick 2025-04-17 16:27:00+00:00 - + 2025-09-26T14:36:50.305522+00:00 + python-feedgen + + + DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures Jonas Nick + 2025-04-17T16:27:00.000Z + + + waxwing/ AdamISZ + 2025-04-19T16:28:00.000Z + + + Jonas Nick + 2025-04-22T15:29:00.000Z + + + waxwing/ AdamISZ + 2025-04-25T16:08:00.000Z + + + Jonas Nick + 2025-04-25T16:41:00.000Z + + + waxwing/ AdamISZ + 2025-04-26T15:30:00.000Z + + + waxwing/ AdamISZ + 2025-04-26T17:05:00.000Z + + + Jonas Nick + 2025-04-30T07:59:00.000Z + + + waxwing/ AdamISZ + 2025-04-30T15:54:00.000Z + + + waxwing/ AdamISZ + 2025-06-16T19:35:00.000Z + + + Tim Ruffing + 2025-07-02T11:36:00.000Z + + + waxwing/ AdamISZ + 2025-07-03T14:07:00.000Z + + + Jonas Nick + 2025-07-17T13:15:00.000Z + + @@ -55,21 +71,17 @@ - python-feedgen + 2 Combined summary - DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures - 2025-07-18T03:07:52.835505+00:00 + 2025-09-26T14:36:50.307128+00:00 + 2025-07-17T13:15:00+00:00 The conversation between AdamISZ/waxwing and Tim delves into the intricacies of cryptographic signing protocols, focusing on their application in Bitcoin but acknowledging broader uses beyond blockchain technology. They discuss the efficiency of a signing protocol that reduces the computational demand by changing from constant time operations to ones that scale with the number of participants, considering trade-offs between signing and verification performance. The dialogue touches on the importance of designing systems that manage scaling effectively, especially for devices with limited computational resources. The exchange also explores the potential benefits of algebraic algorithms in cryptographic processes, highlighting their ease of integration into circuits for zero-knowledge proofs and their operational efficiencies due to fewer conditional branches or loops. - Further analysis on cryptographic protocols examines the security implications and operational efficiencies of using distinct ephemeral identifiers across participants. The discussion contrasts the computational inefficiencies introduced by this approach against the streamlined process achieved by employing a singular identifier, emphasizing the latter's advantages in reducing computation time without sacrificing security. This choice is framed within the context of enhancing transaction efficiency on the blockchain without introducing significant increases in signature size or verification costs. Additionally, the discourse addresses concerns related to ensuring the integrity of the signing process, particularly in identifying and mitigating disruptive behavior among participants, underscoring the necessity of honest coordinators and secure communication channels. - -A detailed exploration into cryptographic verification mechanisms reveals an innovative perspective on nonce reuse and its security ramifications, particularly comparing MuSig2 and DahLIAS protocols. The discussions shed light on DahLIAS's flexibility in verification processes, allowing for multiple public keys and messages as inputs, which diverges from MuSig2's rigid structure. This adaptability not only expands DahLIAS’s applicability but also introduces a nuanced layer of security by preventing attackers from exploiting nonce reuse through variable "b" values for each participant. This aspect underscores the ongoing efforts to refine cryptographic protocols, ensuring robust security against sophisticated attack vectors. - +A detailed exploration into cryptographic verification mechanisms reveals an innovative perspective on nonce reuse and its security ramifications, particularly comparing MuSig2 and DahLIAS protocols. The discussions shed light on DahLIAS's flexibility in verification processes, allowing for multiple public keys and messages as inputs, which diverges from MuSig2's rigid structure. This adaptability not only expands DahLIAS’s applicability but also introduces a nuanced layer of security by preventing attackers from exploiting nonce reuse through variable "b" values for each participant. This aspect underscores the ongoing efforts to refine cryptographic protocols, ensuring robust security against sophisticated attack vectors. The email exchanges delve into the theoretical underpinnings and practical considerations of cryptographic optimizations, emphasizing the significance of not compromising on security while seeking operational efficiencies. The discourse covers the security theorem for DahLIAS, highlighting its robustness against attacks unless specific cryptographic assumptions are violated. Additionally, the conversations pivot towards practical optimizations for single-party signers and the inclusion of such methodologies in academic papers versus Bitcoin Improvement Proposals (BIPs), arguing for a broader applicational relevance that warrants academic scrutiny. - Lastly, the discussions encapsulate a comprehensive overview of the CISA algorithm and its potential to streamline blockchain transactions by optimizing signature processes. This includes a nuanced analysis of nonce handling and the security considerations associated with aggregate signatures, particularly focusing on the compatibility with key tweaking and the implications for operational efficiency and security. The dialogue also extends to client-side validation concepts, proposing strategies to mitigate risks and enhance the security framework for digital signatures within the blockchain domain. - 2025-07-17T13:15:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Does-anyone-still-need-testnet3-.xml b/static/bitcoin-dev/April_2025/combined_Does-anyone-still-need-testnet3-.xml index c383cfb7b4..acf505b659 100644 --- a/static/bitcoin-dev/April_2025/combined_Does-anyone-still-need-testnet3-.xml +++ b/static/bitcoin-dev/April_2025/combined_Does-anyone-still-need-testnet3-.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Does anyone still need testnet3? - 2025-04-02T02:43:49.589965+00:00 - - Sjors Provoost 2025-04-01 09:06:00+00:00 - - - Garlo Nicon 2025-04-01 05:56:00+00:00 - - - Melvin Carvalho 2025-03-31 21:23:00+00:00 - - - Melvin Carvalho 2025-03-21 05:44:00+00:00 - - - Sjors Provoost 2025-03-14 09:31:00+00:00 - - - Andreas Schildbach 2025-03-14 09:12:00+00:00 - - - Sjors Provoost 2025-03-14 08:52:00+00:00 - + 2025-09-26T14:36:54.578300+00:00 + python-feedgen + + + Does anyone still need testnet3? Sjors Provoost + 2025-03-14T08:52:00.000Z + + + Andreas Schildbach' + 2025-03-14T09:12:00.000Z + + + Sjors Provoost + 2025-03-14T09:31:00.000Z + + + Melvin Carvalho + 2025-03-21T05:44:00.000Z + + + Sanket Kanjalkar + 2025-03-31T21:23:00.000Z + + + Garlo Nicon + 2025-04-01T05:56:00.000Z + + + Sjors Provoost + 2025-04-01T09:06:00.000Z + + @@ -31,19 +41,16 @@ - python-feedgen + 2 Combined summary - Does anyone still need testnet3? - 2025-04-02T02:43:49.590031+00:00 + 2025-09-26T14:36:54.579278+00:00 + 2025-04-01T09:06:00+00:00 The Bitcoin development community is actively exploring solutions to enhance the functionality and accessibility of test networks, addressing challenges such as the difficulty in obtaining coins for development purposes due to high transaction fees on testnet3. A novel proposal suggests creating an application to enable coin swapping between testnet3 and testnet4, potentially incorporating an Automated Market Maker (AMM) system to facilitate this process. This initiative aims to simplify resource acquisition for developers, fostering a more efficient testing environment within the Bitcoin ecosystem. - Testnet4 is currently experiencing frequent short reorganizations (reorgs), primarily due to the exploitation of a rule that allows mining difficulty to drop significantly after a period without new blocks. This scenario leads to a situation where the Median Time Past (MTP) on testnet4 is often set in the future, an anomaly diverging from the expected behavior. In response, a countermeasure involving strategic re-organization of blocks mined at artificially low difficulty has been proposed. Though this solution is still conceptual and not intended for direct incorporation into Bitcoin Core, it offers a potential pathway to increase the frequency of reorgs, serving as a valuable testbed for debugging and further exploration. - The integration of testnet4 within the Bitcoinj framework is underway, though not yet complete, with the next release (version 0.18) anticipated to take longer than 12 months. Despite these timelines, the current version of testnet3 remains a satisfactory testing ground, even with its challenges, which are deemed beneficial for stress-testing code. The commitment to support both testnets moving forward was confirmed, alongside a mention of btc-rpc-explorer, a self-hostable block explorer tool, which currently does not support testnet4. These developments highlight ongoing efforts to improve testing frameworks and tools, reflecting the community's dedication to enhancing the robustness of Bitcoin-related technologies. - Testnet4, proposed in BIP94 and supported by Bitcoin Core from version 28, addresses the limitations of using testnet3, including block storms that have made it increasingly impractical. This transition allows users to either adopt testnet4 or continue utilizing testnet3 by maintaining their node software independently, underscoring the blockchain community's commitment to backward compatibility and adaptability. The discussion also opens the possibility of creating a permissionless signet based purely on proof-of-work, indicating an innovative approach to improving network functionality. Feedback from developers reliant on testnet3 is encouraged to ensure that future versions of Bitcoin Core, such as v29, remain inclusive and accommodating, highlighting the importance of community input in guiding Bitcoin's technological evolution. Interested parties are invited to contribute to the dialogue through the provided [Github issue link](https://github.com/bitcoin/bitcoin/issues/), facilitating a comprehensive discourse on these advancements. - 2025-04-01T09:06:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Introducing-Hourglass.xml b/static/bitcoin-dev/April_2025/combined_Introducing-Hourglass.xml index d3ee97c592..ddb77715ad 100644 --- a/static/bitcoin-dev/April_2025/combined_Introducing-Hourglass.xml +++ b/static/bitcoin-dev/April_2025/combined_Introducing-Hourglass.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Introducing Hourglass - 2025-08-27T02:40:55.584812+00:00 - - Saint Wenhao 2025-08-23 17:49:00+00:00 - - - Hunter Beast 2025-05-04 06:00:00+00:00 - - - Francis Pouliot 2025-05-02 15:45:00+00:00 - - - Saint Wenhao 2025-05-02 13:58:00+00:00 - - - Agustin Cruz 2025-05-01 18:23:00+00:00 - - - Nagaev Boris 2025-05-01 17:38:00+00:00 - - - Jameson Lopp 2025-05-01 11:38:00+00:00 - - - Michael Tidwell 2025-04-30 03:01:00+00:00 - - - Hunter Beast 2025-04-29 22:38:00+00:00 - + 2025-09-26T14:36:37.425113+00:00 + python-feedgen + + + Introducing Hourglass Hunter Beast + 2025-04-29T22:38:00.000Z + + + Michael Tidwell + 2025-04-30T03:01:00.000Z + + + Jameson Lopp + 2025-05-01T11:38:00.000Z + + + Nagaev Boris + 2025-05-01T17:38:00.000Z + + + Agustin Cruz + 2025-05-01T18:23:00.000Z + + + Saint Wenhao + 2025-05-02T13:58:00.000Z + + + Francis Pouliot + 2025-05-02T15:45:00.000Z + + + Hunter Beast + 2025-05-04T06:00:00.000Z + + + Saint Wenhao + 2025-08-23T17:49:00.000Z + + @@ -39,25 +51,19 @@ - python-feedgen + 2 Combined summary - Introducing Hourglass - 2025-08-27T02:40:55.584889+00:00 + 2025-09-26T14:36:37.426306+00:00 + 2025-08-23T17:49:00+00:00 The discussion regarding the handling and security of Bitcoin in the face of potential quantum computing threats reveals a multifaceted approach to preserving the currency's stability and integrity. The conversation begins with an examination of the implications that quantum computing may have on Bitcoin, particularly focusing on Pay-to-PubKey (P2PK) coins. The proposal to limit P2PK spends to one per block is highlighted as a strategy to incite bidding wars among miners, potentially benefiting them through increased transaction fees derived from quantum-retrieved coins. This method is noted for its feasibility without necessitating any soft forks, leveraging existing operations like OP_SIZE combined with either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY to restrict coin spendability based on Proof of Work. This approach, detailed on [BitcoinTalk](https://bitcointalk.org/index.php?topic=5551080.msg65724436msg65724436), could enforce a time lock on transactions, varying the unlock period depending on the signature size. - The discourse also covers broader implications of trading volumes and price volatility on Bitcoin's security. Michael Tidwell's email criticizes a proposal to manage Bitcoin’s price through spending restrictions, arguing against viewing price volatility as a security issue due to the market's capacity to absorb significant Bitcoin quantities without destabilizing prices. This argument underscores the inherent price fluctuations within the cryptocurrency market and challenges the notion that artificial controls on spending could enforce price stability. - -Further, the conversation delves into strategies for transitioning Bitcoin to a quantum-resistant framework, suggesting that instead of permanently rendering coins inaccessible ("burning"), they could be temporarily "trapped" using a reversible mechanism. This would allow for a potential return to ECDSA if necessary, ensuring the continuity of historical blockchain transaction verifications. Such strategic foresight emphasizes preserving access to assets under new cryptographic standards, reflecting a cautious approach to future-proofing against quantum vulnerabilities. - +Further, the conversation delves into strategies for transitioning Bitcoin to a quantum-resistant framework, suggesting that instead of permanently rendering coins inaccessible ("burning"), they could be temporarily "trapped" using a reversible mechanism. This would allow for a potential return to ECDSA if necessary, ensuring the continuity of historical blockchain transaction verifications. Such strategic foresight emphasizes preserving access to assets under new cryptographic standards, reflecting a cautious approach to future-proofing against quantum vulnerabilities. The Quantum Resistant Address Migration Proposal (QRAMP) introduces a proactive measure against quantum-capable attackers by mandating the migration of unspent P2PK outputs to quantum-resistant addresses before a specified deadline. This initiative aims to invalidate unmoved coins post-deadline, safeguarding them from quantum exploitation by removing their spendability through consensus, illustrating an aggressive yet decisive strategy to protect the currency from quantum threats. - A nuanced perspective on the tactics a quantum computing capable entity might employ to maximize gains in the cryptocurrency space discusses the benefits of publicly broadcasting transactions to ensure their inclusion by other miners. This contrasts with a private broadcast, which limits UTXO claims to blocks mined by the entity itself. The discussion highlights strategic considerations for such entities, including diversifying UTXOs for broadcasting and self-mining to maintain mining momentum and streamline operations. - Boris Nagaev critiques a proposal aimed at dampening quantum attacks' economic impact, pointing out its inadequacy given the rapid capabilities of quantum computers to exploit cryptographic keys. Nagaev's skepticism extends to the strategy's inability to preemptively address high-value targets likely to be attacked first, indicating a need for a more comprehensive approach to mitigating potential quantum-induced economic shocks. - -Lastly, the dialogue explores the concept of allowing early P2PK coins to be "naturally recycled" without modifying their scripts, advocating for a method that respects Bitcoin's technical, cultural, and moral ethos over more drastic measures. This contemplation reflects on the possible scenarios involving mining pools and quantum computing entities, emphasizing the complex dynamics at play in securing Bitcoin against advanced technological threats without undermining its foundational principles. The significant attention to detail and consideration of various strategies and their implications underscore the community's commitment to navigating the evolving landscape of cryptocurrency security. - 2025-08-23T17:49:00+00:00 +Lastly, the dialogue explores the concept of allowing early P2PK coins to be "naturally recycled" without modifying their scripts, advocating for a method that respects Bitcoin's technical, cultural, and moral ethos over more drastic measures. This contemplation reflects on the possible scenarios involving mining pools and quantum computing entities, emphasizing the complex dynamics at play in securing Bitcoin against advanced technological threats without undermining its foundational principles. The significant attention to detail and consideration of various strategies and their implications underscore the community's commitment to navigating the evolving landscape of cryptocurrency security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_New-Proposal-String-Substring-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml b/static/bitcoin-dev/April_2025/combined_New-Proposal-String-Substring-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml index 2dc67fb5a4..20006bd7a3 100644 --- a/static/bitcoin-dev/April_2025/combined_New-Proposal-String-Substring-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml +++ b/static/bitcoin-dev/April_2025/combined_New-Proposal-String-Substring-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - New Proposal：String Substring Search in Bitcoin Script - OP_ISSUBSTR - 2025-04-10T02:36:16.758506+00:00 - - Anthony Towns 2025-04-08 18:04:00+00:00 - - - Martin Habovštiak 2025-04-01 15:35:00+00:00 - - - Pieter Wuille 2025-04-01 12:25:00+00:00 - - - Javier Mateos 2025-03-28 22:40:00+00:00 - - - Vojtěch Strnad 2025-03-20 00:23:00+00:00 - - - weichu deng 2025-03-19 09:07:00+00:00 - - - Rijndael 2025-03-18 21:33:00+00:00 - - - Erik Aronesty 2025-03-18 16:41:00+00:00 - - - weichu deng 2025-03-18 15:32:00+00:00 - - - Peter Todd 2025-03-17 16:54:00+00:00 - - - weichu deng 2025-03-17 16:14:00+00:00 - + 2025-09-26T14:36:58.828707+00:00 + python-feedgen + + + New Proposal：String Substring Search in Bitcoin Script - OP_ISSUBSTR weichu deng + 2025-03-17T16:14:00.000Z + + + Peter Todd + 2025-03-17T16:54:00.000Z + + + weichu deng + 2025-03-18T15:32:00.000Z + + + Erik Aronesty + 2025-03-18T16:41:00.000Z + + + Rijndael + 2025-03-18T21:33:00.000Z + + + weichu deng + 2025-03-19T09:07:00.000Z + + + Vojtěch Strnad + 2025-03-20T00:23:00.000Z + + + Javier Mateos + 2025-03-28T22:40:00.000Z + + + Pieter Wuille + 2025-04-01T12:25:00.000Z + + + Martin Habovštiak + 2025-04-01T15:35:00.000Z + + + Anthony Towns + 2025-04-08T18:04:00.000Z + + @@ -47,25 +61,19 @@ - python-feedgen + 2 Combined summary - New Proposal：String Substring Search in Bitcoin Script - OP_ISSUBSTR - 2025-04-10T02:36:16.758592+00:00 + 2025-09-26T14:36:58.830117+00:00 + 2025-04-08T18:04:00+00:00 In a recent discussion among programmers, the efficiency and potential limitations of using different opcodes in programming were examined, with a particular focus on Bitcoin script development. The conversation revolved around the OP_CAT operation and its alternatives for string manipulation, highlighting how certain operations could be more efficiently executed with opcodes designed for specific tasks like substring extraction. This dialogue sheds light on the nuanced considerations developers must make when choosing opcodes to express their logic, balancing efficiency with the natural language of coding. - The debate touched upon the structural adjustments within data management practices, inspired by the Rust programming community's approach to managing data arrays. By storing stack elements on the heap with a detailed structure that includes reference count, length, and data array, substring operations can be made more efficient and secure. This method effectively prevents stack overflow risks without compromising on operational functionality, offering insights into memory management strategies that enhance programming security and efficiency. - Furthermore, the conversation delved into the scripting nuances within cryptocurrency transactions, particularly in Bitcoin. It was argued that scripts should aim to verify information rather than compute it, advocating for a simplification in script design. By requiring specific inputs like coin position, scripts can streamline verification processes, making a case for minimizing computational functions within scripts to optimize performance and security. - Technical challenges of dynamic string handling in Bitcoin script development were also discussed. The limitations of OP_CAT in scenarios where the substring's position is not predetermined highlight a need for more flexible string manipulation tools. This points towards an ongoing dialogue within the Bitcoin developer community to explore robust solutions or alternative approaches that accommodate dynamic string operations, underlining the importance of evolving script functionalities to address practical development challenges. - An innovative approach to enhancing user interaction and security in a Bitcoin-based game was proposed, leveraging public key manipulation in a split format. This technique emphasizes the versatility and creative potential of Bitcoin's scripting language, illustrating how technical ingenuity can introduce novel mechanisms for user engagement within the cryptocurrency space. - The intricacies of implementing substring search functionalities in Bitcoin scripts were further explored, with discussions around the technical and security implications of reintroducing the OP_CAT operation. These exchanges underscore the careful consideration required to balance functional enhancements with security imperatives, reflecting a broader commitment within the Bitcoin development community to refine and advance the scripting capabilities of the cryptocurrency. - Finally, a new Bitcoin Improvement Proposal (BIP) introduces OP_ISSUBSTR and OP_ISSUBSTRVERIFY, aiming to reintroduce string operations in Bitcoin scripts. This proposal addresses the developmental challenges posed by the current lack of on-chain string logic processing capabilities, proposing a secure and efficient mechanism for substring verification. This initiative marks a significant step towards expanding the functionality and developer-friendliness of Bitcoin scripts, underscoring the community's proactive approach to addressing emerging challenges and enhancing the cryptocurrency's underlying technology. - 2025-04-08T18:04:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Post-Quantum-Signatures-and-Scaling-Bitcoin.xml b/static/bitcoin-dev/April_2025/combined_Post-Quantum-Signatures-and-Scaling-Bitcoin.xml index 52083d3856..207eb79808 100644 --- a/static/bitcoin-dev/April_2025/combined_Post-Quantum-Signatures-and-Scaling-Bitcoin.xml +++ b/static/bitcoin-dev/April_2025/combined_Post-Quantum-Signatures-and-Scaling-Bitcoin.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Post Quantum Signatures and Scaling Bitcoin - 2025-04-15T02:51:38.724547+00:00 - - Ethan Heilman 2025-04-14 19:35:00+00:00 - - - Pieter Wuille 2025-04-14 13:47:00+00:00 - - - Eli BenSasson 2025-04-05 20:40:00+00:00 - - - Matt Corallo 2025-04-05 17:39:00+00:00 - - - Ethan Heilman 2025-04-04 19:22:00+00:00 - - - Brandon Black 2025-04-04 18:43:00+00:00 - - - Dustin Ray 2025-04-04 17:17:00+00:00 - - - Ethan Heilman 2025-04-04 16:29:00+00:00 - + 2025-09-26T14:36:35.304216+00:00 + python-feedgen + + + Post Quantum Signatures and Scaling Bitcoin Ethan Heilman + 2025-04-04T16:29:00.000Z + + + Dustin Ray + 2025-04-04T17:17:00.000Z + + + Brandon Black + 2025-04-04T18:43:00.000Z + + + Ethan Heilman + 2025-04-04T19:22:00.000Z + + + Matt Corallo + 2025-04-05T17:39:00.000Z + + + Eli Ben-Sasson' + 2025-04-05T20:40:00.000Z + + + Pieter Wuille + 2025-04-14T13:47:00.000Z + + + Ethan Heilman + 2025-04-14T19:35:00.000Z + + @@ -35,23 +46,18 @@ - python-feedgen + 2 Combined summary - Post Quantum Signatures and Scaling Bitcoin - 2025-04-15T02:51:38.724626+00:00 + 2025-09-26T14:36:35.305427+00:00 + 2025-04-14T19:35:00+00:00 The discourse within the Bitcoin Development Mailing List illuminates the community's proactive stance on enhancing Bitcoin's resistance to quantum computing threats while maintaining its foundational principles. The conversation, spanning various aspects from cryptographic advancements to economic and technical challenges, outlines a multifaceted approach toward securing the future of Bitcoin in an evolving digital landscape. - A focal point of the discussion is the potential integration of post-quantum (PQ) cryptography within Bitcoin's framework, specifically addressing the efficiency and security of PQ signature schemes compared to current standards. The comparison between FALCON and edDSA signature verification times exemplifies the ongoing research and optimism regarding Bitcoin's adaptability to include more quantum-resistant signatures. This optimism is tempered by considerations of the schemes' resistance to quantum attacks and the practicality of their implementation without compromising Bitcoin's transaction throughput or network integrity. - Further, the debate extends to the implications of adopting non-hash-based PQ cryptography and the speculative nature of their long-term viability against quantum computational advancements. The discourse suggests a cautious approach, favoring hash-based solutions for their proven security and feasibility within Bitcoin's existing protocol. This perspective underscores the community's commitment to ensuring the cryptocurrency's resilience against quantum threats through pragmatic and thoroughly vetted enhancements. - Economic and technical challenges for node operators are also scrutinized, particularly the distinction between full relay nodes and blocks-only nodes. The conversation highlights concerns over the increasing operational costs and the proposed concept of transaction aggregation as a possible mitigation strategy. This approach could potentially lower verification costs and introduce new revenue streams for node operators, thereby sustaining the network's health and efficiency. However, the practical implementation of such a system remains a subject of inquiry, emphasizing the need for innovative solutions that align with Bitcoin's decentralized ethos. - Additionally, the dialogue touches upon the security of STARKs and their conjectured quantum resistance. The lack of formal security proofs for these cryptographic systems raises questions about their reliability and the necessity for further research to bolster their assumed defenses against quantum computing threats. This aspect of the conversation reflects the broader challenges facing the cryptographic community in developing quantum-resistant technologies that can be confidently integrated into existing digital infrastructures. - In conclusion, the discussions among Bitcoin developers and enthusiasts reveal a proactive and nuanced approach to enhancing the cryptocurrency's quantum resistance. While there is optimism about integrating advanced cryptographic solutions, there exists a careful consideration of the potential technical, economic, and security implications. The community's engagement with these complex issues signifies an ongoing effort to balance innovation with the preservation of Bitcoin's core values, ensuring its viability and integrity in the face of quantum computing advances. - 2025-04-14T19:35:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-29-0.xml b/static/bitcoin-dev/April_2025/combined_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-29-0.xml index 117b0f8b9d..942b1c26ab 100644 --- a/static/bitcoin-dev/April_2025/combined_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-29-0.xml +++ b/static/bitcoin-dev/April_2025/combined_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-29-0.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - Public disclosure of one vulnerability affecting Bitcoin Core <29.0 - 2025-05-17T02:44:59.318463+00:00 - - Antoine Poinsot 2025-05-16 14:41:00+00:00 - - - Antoine Poinsot 2025-04-28 19:00:00+00:00 - + 2025-09-26T14:36:41.646593+00:00 + python-feedgen + + + Public disclosure of one vulnerability affecting Bitcoin Core <29.0 'Antoine Poinsot' + 2025-04-28T19:00:00.000Z + + + Antoine Poinsot' + 2025-05-16T14:41:00.000Z + + - python-feedgen + 2 Combined summary - Public disclosure of one vulnerability affecting Bitcoin Core <29.0 - 2025-05-17T02:44:59.318502+00:00 + 2025-09-26T14:36:41.647137+00:00 + 2025-05-16T14:41:00+00:00 A recent security advisory has been issued for Bitcoin Core, pinpointing a low-severity issue that impacts versions of the software prior to 29.0. This version was released two weeks ago, marking an important update for users and developers concerned with maintaining the security and integrity of their operations within the Bitcoin ecosystem. The advisory brings attention to the continuous efforts by the Bitcoin Core team to identify and address vulnerabilities in a timely manner, ensuring the community is informed and can take necessary actions to mitigate risks. - The advisory and further details about this specific vulnerability are accessible on the Bitcoin Core project's website, ensuring transparency and easy access to critical information. This approach reflects the project's commitment to open communication and thoroughness in handling security issues, providing a reliable source for updates and advisories. - Moreover, the Bitcoin Core project has made available its full security disclosure policy, which outlines the protocols and procedures in place for managing, communicating, and resolving security vulnerabilities. This policy is a vital resource for developers, stakeholders, and users of Bitcoin Core, offering insights into the project's systematic approach to security. It lays out how advisories are handled from discovery through to resolution, emphasizing the importance of transparency and responsible management in the digital currency space. Access to the policy is intended to foster a deeper understanding of the project's dedication to security and the measures taken to protect users against potential threats. - 2025-05-16T14:41:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Re-Against-Allowing-Quantum-Recovery-of-Bitcoin.xml b/static/bitcoin-dev/April_2025/combined_Re-Against-Allowing-Quantum-Recovery-of-Bitcoin.xml index 63bffa019e..3fd4df0a00 100644 --- a/static/bitcoin-dev/April_2025/combined_Re-Against-Allowing-Quantum-Recovery-of-Bitcoin.xml +++ b/static/bitcoin-dev/April_2025/combined_Re-Against-Allowing-Quantum-Recovery-of-Bitcoin.xml @@ -1,29 +1,143 @@ - + 2 Combined summary - Re: Against Allowing Quantum Recovery of Bitcoin - 2025-05-02T02:48:52.887179+00:00 - - Michael Tidwell 2025-04-30 15:40:00+00:00 - - - Nadav Ivgi 2025-04-06 14:07:00+00:00 - - - Ben Sigman 2025-04-04 04:49:00+00:00 - - - Javier Mateos 2025-03-30 22:23:00+00:00 - - - Matt Corallo 2025-03-28 20:00:00+00:00 - - - Sjors Provoost 2025-03-25 08:16:00+00:00 - - - Matt Corallo 2025-03-25 01:06:00+00:00 - + 2025-09-26T14:36:48.154831+00:00 + python-feedgen + + + Jameson Lopp + 2025-03-16T14:15:00.000Z + + + Chris Riley + 2025-03-16T18:03:00.000Z + + + Nagaev Boris + 2025-03-16T19:44:00.000Z + + + Jameson Lopp + 2025-03-16T21:25:00.000Z + + + IdeA + 2025-03-16T22:56:00.000Z + + + Matt Corallo + 2025-03-17T12:00:00.000Z + + + Jameson Lopp + 2025-03-17T13:28:00.000Z + + + Sjors Provoost + 2025-03-18T12:48:00.000Z + + + Against Allowing Quantum Recovery of Bitcoin AstroTown + 2025-03-22T19:02:00.000Z + + + Agustin Cruz + 2025-03-24T11:19:00.000Z + + + Matt Corallo + 2025-03-25T01:06:00.000Z + + + Sjors Provoost + 2025-03-25T08:16:00.000Z + + + Matt Corallo + 2025-03-28T20:00:00.000Z + + + Javier Mateos + 2025-03-30T22:23:00.000Z + + + Ben Sigman' + 2025-04-04T04:49:00.000Z + + + Nadav Ivgi + 2025-04-06T14:07:00.000Z + + + Michael Tidwell + 2025-04-30T15:40:00.000Z + + + conduition' + 2025-05-25T19:03:00.000Z + + + Dustin Ray + 2025-05-25T23:03:00.000Z + + + Agustin Cruz + 2025-05-26T00:32:00.000Z + + + ArmchairCryptologist' + 2025-05-26T15:40:00.000Z + + + waxwing/ AdamISZ + 2025-05-28T01:07:00.000Z + + + Sjors Provoost + 2025-05-28T07:46:00.000Z + + + waxwing/ AdamISZ + 2025-05-28T21:15:00.000Z + + + waxwing/ AdamISZ + 2025-06-07T13:28:00.000Z + + + Jameson Lopp + 2025-06-08T14:04:00.000Z + + + Boris Nagaev + 2025-07-13T01:39:00.000Z + + + Jameson Lopp + 2025-07-13T12:34:00.000Z + + + Boris Nagaev + 2025-07-13T14:20:00.000Z + + + Ethan Heilman + 2025-07-13T16:01:00.000Z + + + Boris Nagaev + 2025-07-13T17:51:00.000Z + + + Pieter Wuille + 2025-07-13T19:28:00.000Z + + + Jameson Lopp + 2025-07-13T21:26:00.000Z + + @@ -31,23 +145,18 @@ - python-feedgen + 2 Combined summary - Re: Against Allowing Quantum Recovery of Bitcoin - 2025-05-02T02:48:52.887242+00:00 + 2025-09-26T14:36:48.158472+00:00 + 2025-04-30T15:40:00+00:00 The ongoing discussions within the Bitcoin development community highlight a proactive approach towards securing the cryptocurrency against potential quantum computing threats. A significant emphasis is placed on the introduction of post-quantum cryptographic (PQC) mechanisms to safeguard Bitcoin from vulnerabilities posed by quantum attackers. The innovative strategies proposed range from implementing soft forks that mandate certain transaction conditions to integrating new cryptographic standards. These proposals aim not only to enhance security but also to ensure the stability and functionality of the blockchain in the face of evolving technological threats. - One notable proposal involves adjusting the Bitcoin protocol to make it resilient against quantum attacks by introducing a system where transactions involving quantum-vulnerable coins allocate a major portion of the funds to timelocked outputs. This method proposes locking 99% of such funds for periods between 10 to 100 years, with the intention of delaying their usage and preventing market flooding. The remaining 1% would be freely spendable but also subject to a timelock, aiming to regulate its entry into the market and mitigate impacts on Bitcoin's value. This approach seeks to balance the need for security with the desire to avoid rewarding malicious actors excessively, thereby preserving market integrity. - The conversation extends to various methods for transitioning Bitcoin into a quantum-resistant state, including the introduction of rolling timeouts and quantum doomsday clocks. Amid these technical discussions, there's a consensus on the urgency of adopting PQC standards to protect against quantum vulnerabilities. Proposals like BIP 360 and adaptations of Taproot PQC are being considered, indicating a community-driven effort to evolve Bitcoin's cryptographic foundation. This phase marks a critical juncture in Bitcoin's development, underscoring the necessity of adaptation to maintain its resilience against future technological advances. - A strategic, phased approach to transitioning to quantum-resistant signatures has been suggested to mitigate risks without causing upheaval within the Bitcoin community. This includes allowing users to attach optional PQC keys to Taproot addresses as an immediate measure, followed by a soft fork to disable vulnerable signatures, incorporating a migration period for a smooth transition. The final stage involves phasing out old signatures gradually, accompanied by incentives to encourage adoption of secure transactions. This method emphasizes communication and inclusivity, aiming to facilitate a seamless transition without inducing panic or coercion among users. - Furthermore, Matt Corallo's proposition for a Probabilistic Check Quantum (PCQ) scheme introduces a nuanced approach to address concerns over asset freezes due to policy changes in key path spending. By offering a solution that minimizes disruption while maintaining user trust, this proposal reflects a deep understanding of the balance required between innovation and ensuring asset stability. It highlights the broader concern within the cryptocurrency community regarding how technological advancements might influence asset perception and value. - Lastly, the discourse acknowledges the challenges of adopting post-quantum schemes, emphasizing the importance of a freeze fork to preemptively secure Bitcoin against quantum computing threats. This discussion points to a growing recognition within the community of the need for PQC capabilities, driven by both current interest and the anticipation of future demands. Skepticism towards arguments against the adoption of PQC solutions underscores the ongoing debates and concerns about future-proofing Bitcoin in an era of rapidly advancing quantum computing technologies. - 2025-04-30T15:40:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml b/static/bitcoin-dev/April_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml index 1773738942..ab4bdef192 100644 --- a/static/bitcoin-dev/April_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml +++ b/static/bitcoin-dev/April_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks - 2025-04-10T02:34:59.225767+00:00 - - Yuval Kogman 2025-04-09 02:16:00+00:00 - - - Javier Mateos 2025-04-07 10:01:00+00:00 - - - Yuval Kogman 2025-04-04 19:59:00+00:00 - - - Yuval Kogman 2025-04-04 17:58:00+00:00 - - - Peter Todd 2025-04-04 16:42:00+00:00 - - - Yuval Kogman 2025-02-13 15:42:00+00:00 - - - /dev /fd 2025-02-12 10:17:00+00:00 - - - Yuval Kogman 2025-02-07 20:07:00+00:00 - - - Peter Todd 2025-02-04 22:22:00+00:00 - - - Yuval Kogman 2025-02-04 14:02:00+00:00 - - - waxwing/ AdamISZ 2025-01-24 16:38:00+00:00 - - - Peter Todd 2025-01-24 16:00:00+00:00 - - - Peter Todd 2025-01-23 16:25:00+00:00 - - - Yuval Kogman 2025-01-07 21:33:00+00:00 - - - waxwing/ AdamISZ 2025-01-07 15:56:00+00:00 - - - Yuval Kogman 2025-01-06 14:30:00+00:00 - - - Sjors Provoost 2025-01-06 13:07:00+00:00 - - - Yuval Kogman 2024-12-21 14:16:00+00:00 - + 2025-09-26T14:36:28.878656+00:00 + python-feedgen + + + Yuval Kogman + 2024-12-21T14:16:00.000Z + + + Sjors Provoost + 2025-01-06T13:07:00.000Z + + + Yuval Kogman + 2025-01-06T14:30:00.000Z + + + waxwing/ AdamISZ + 2025-01-07T15:56:00.000Z + + + Yuval Kogman + 2025-01-07T21:33:00.000Z + + + Peter Todd + 2025-01-23T16:25:00.000Z + + + Peter Todd + 2025-01-24T16:00:00.000Z + + + waxwing/ AdamISZ + 2025-01-24T16:38:00.000Z + + + Yuval Kogman + 2025-02-04T14:02:00.000Z + + + Peter Todd + 2025-02-04T22:22:00.000Z + + + Yuval Kogman + 2025-02-07T20:07:00.000Z + + + /dev /fd0 + 2025-02-12T10:17:00.000Z + + + Yuval Kogman + 2025-02-13T15:42:00.000Z + + + Peter Todd + 2025-04-04T16:42:00.000Z + + + Yuval Kogman + 2025-04-04T17:58:00.000Z + + + Yuval Kogman + 2025-04-04T19:59:00.000Z + + + Javier Mateos + 2025-04-07T10:01:00.000Z + + + Yuval Kogman + 2025-04-09T02:16:00.000Z + + @@ -75,23 +96,18 @@ - python-feedgen + 2 Combined summary - Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks - 2025-04-10T02:34:59.225885+00:00 + 2025-09-26T14:36:28.880576+00:00 + 2025-04-09T02:16:00+00:00 The discourse within the Bitcoin development community highlights several critical insights and concerns surrounding privacy, trust, and transparency in the operation of coinjoin implementations such as Wasabi Wallet and Samourai Wallet. At the core of these discussions is the acknowledgment of inherent vulnerabilities and the complexity of ensuring user anonymity against sophisticated deanonymization techniques. The dialogue surfaces a pivotal tension between the theoretical promise of privacy-enhancing technologies and their practical implementation challenges. - A central theme in the conversation revolves around the limitations and potential weaknesses of coinjoin protocols. Specifically, criticisms target the coordinators' ability to undermine the privacy guarantees through manipulating transaction processes, a risk exacerbated by a lack of transparency and possible rent-seeking behaviors. These concerns are not merely theoretical but are grounded in detailed technical analyses that reveal how malicious actors could exploit protocol design flaws for deanonymization purposes. - For instance, the critique of Whirlpool's vulnerability centers on the process of blind signing keys, which could enable a coordinator to clandestinely link outputs to inputs, thereby breaching the protocol's privacy assurances. Similarly, WabiSabi faces scrutiny over its handling of key consistency, with the protocol's reliance on clients registering Bitcoin UTXOs independently underpinning a methodological flaw. This flaw could allow inconsistent round IDs to be issued to clients, facilitating partitioning attacks that compromise user anonymity. Despite efforts to address these and other issues, such as poor coin selection practices and the misuse of Tor circuits, the fundamental challenge of verifying and controlling the public keys used for proof verification persists. - Moreover, the discussions delve into the economic models embedded within these systems, particularly focusing on coordination fees and anonymous credential mechanisms. While intended to fairly compensate for transaction coordination, these structures have inadvertently fallen short of preventing the misappropriation of user funds, highlighting a significant gap in balancing privacy enhancement with financial security. - The critiques extend beyond specific protocols to encompass broader themes of ethical responsibility, transparency in development practices, and the imperative for rigorous auditing. The need for a comprehensive approach to security, one that includes both cryptographic and non-cryptographic elements of privacy-sensitive code, is emphasized as essential for maintaining user trust and integrity within the Bitcoin ecosystem. - In summary, the discussions reflect a multifaceted debate on the evolution of cryptocurrency protocols, underscoring the ongoing challenge of innovating privacy-enhancing technologies while safeguarding against exploitation. This dynamic interplay between innovation, security, and ethical considerations encapsulates the current state of discourse in the Bitcoin development community, pointing towards a future where these tensions must be continually navigated to advance the field responsibly. - 2025-04-09T02:16:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Relax-OP-RETURN-standardness-restrictions.xml b/static/bitcoin-dev/April_2025/combined_Relax-OP-RETURN-standardness-restrictions.xml index e4eb3d4c40..6386e65148 100644 --- a/static/bitcoin-dev/April_2025/combined_Relax-OP-RETURN-standardness-restrictions.xml +++ b/static/bitcoin-dev/April_2025/combined_Relax-OP-RETURN-standardness-restrictions.xml @@ -1,218 +1,291 @@ - + 2 Combined summary - Relax OP_RETURN standardness restrictions - 2025-05-26T02:57:22.317291+00:00 - - waxwing/ AdamISZ 2025-05-25 15:53:00+00:00 - - - Bob Burnett 2025-05-21 18:12:00+00:00 - - - Pieter Wuille 2025-05-21 17:52:00+00:00 - - - Bob Burnett 2025-05-21 17:19:00+00:00 - - - Pieter Wuille 2025-05-21 14:47:00+00:00 - - - Bob Burnett 2025-05-21 13:38:00+00:00 - - - Sjors Provoost 2025-05-21 07:41:00+00:00 - - - Bob Burnett 2025-05-21 02:10:00+00:00 - - - Greg Maxwell 2025-05-20 23:12:00+00:00 - - - Antoine Poinsot 2025-05-20 16:26:00+00:00 - - - Antoine Poinsot 2025-05-14 15:54:00+00:00 - - - Anthony Towns 2025-05-12 13:47:00+00:00 - - - James OBeirne 2025-05-07 20:42:00+00:00 - - - pithosian 2025-05-07 16:55:00+00:00 - - - Greg Maxwell 2025-05-07 11:32:00+00:00 - - - pithosian 2025-05-07 01:20:00+00:00 - - - Sjors Provoost 2025-05-06 08:56:00+00:00 - - - Greg Maxwell 2025-05-05 23:55:00+00:00 - - - Peter Todd 2025-05-05 21:45:00+00:00 - - - Peter Todd 2025-05-05 21:34:00+00:00 - - - Peter Todd 2025-05-05 21:30:00+00:00 - - - Nagaev Boris 2025-05-05 14:32:00+00:00 - - - Greg Maxwell 2025-05-05 14:05:00+00:00 - - - Greg Maxwell 2025-05-05 11:42:00+00:00 - - - Anthony Towns 2025-05-05 09:18:00+00:00 - - - Bitcoin Error Log 2025-05-05 06:04:00+00:00 - - - Nagaev Boris 2025-05-04 20:04:00+00:00 - - - nsvrn 2025-05-03 05:14:00+00:00 - - - Martin Habovštiak 2025-05-03 02:02:00+00:00 - - - Greg Maxwell 2025-05-02 22:58:00+00:00 - - - Peter Todd 2025-05-02 20:43:00+00:00 - - - Peter Todd 2025-05-02 20:10:00+00:00 - - - Peter Todd 2025-05-02 20:03:00+00:00 - - - /dev /fd 2025-05-02 19:04:00+00:00 - - - Greg Tonoski 2025-05-02 18:56:00+00:00 - - - Peter Todd 2025-05-02 18:29:00+00:00 - - - Greg Maxwell 2025-05-02 17:36:00+00:00 - - - Greg Maxwell 2025-05-02 16:43:00+00:00 - - - nsvrn 2025-05-02 14:37:00+00:00 - - - Bob Burnett 2025-05-02 13:58:00+00:00 - - - Sjors Provoost 2025-05-02 11:16:00+00:00 - - - Anthony Towns 2025-05-02 09:51:00+00:00 - - - Anthony Towns 2025-05-02 06:34:00+00:00 - - - Greg Maxwell 2025-05-02 06:29:00+00:00 - - - PandaCute 2025-05-02 00:14:00+00:00 - - - Antoine Poinsot 2025-05-01 22:40:00+00:00 - - - Nagaev Boris 2025-05-01 19:33:00+00:00 - - - Andrew Toth 2025-05-01 17:40:00+00:00 - - - Chris Guida 2025-05-01 04:57:00+00:00 - - - Anthony Towns 2025-05-01 03:01:00+00:00 - - - Anthony Towns 2025-04-30 16:37:00+00:00 - - - Sjors Provoost 2025-04-30 16:30:00+00:00 - - - Nagaev Boris 2025-04-30 15:37:00+00:00 - - - Chris Guida 2025-04-30 05:39:00+00:00 - - - Jason Hughes 2025-04-30 00:10:00+00:00 - - - Martin Habovštiak 2025-04-29 19:20:00+00:00 - - - Sjors Provoost 2025-04-29 14:51:00+00:00 - - - Jason Hughes (wk) 2025-04-28 16:20:00+00:00 - - - Pieter Wuille 2025-04-26 12:48:00+00:00 - - - Sjors Provoost 2025-04-26 11:45:00+00:00 - - - Luke Dashjr 2025-04-26 11:35:00+00:00 - - - Sjors Provoost 2025-04-26 10:53:00+00:00 - - - Luke Dashjr 2025-04-26 09:50:00+00:00 - - - Peter Todd 2025-04-20 08:43:00+00:00 - - - Antoine Riard 2025-04-18 21:34:00+00:00 - - - Antoine Poinsot 2025-04-18 13:29:00+00:00 - - - Vojtěch Strnad 2025-04-18 13:06:00+00:00 - - - Greg Sanders 2025-04-18 12:54:00+00:00 - - - Sjors Provoost 2025-04-18 12:03:00+00:00 - - - Antoine Poinsot 2025-04-17 18:52:00+00:00 - + 2025-09-26T14:37:01.054849+00:00 + python-feedgen + + + Relax OP_RETURN standardness restrictions 'Antoine Poinsot' + 2025-04-17T18:52:00.000Z + + + Sjors Provoost + 2025-04-18T12:03:00.000Z + + + Greg Sanders + 2025-04-18T12:54:00.000Z + + + Vojtěch Strnad + 2025-04-18T13:06:00.000Z + + + Antoine Poinsot' + 2025-04-18T13:29:00.000Z + + + Antoine Riard + 2025-04-18T21:34:00.000Z + + + Peter Todd + 2025-04-20T08:43:00.000Z + + + Luke Dashjr + 2025-04-26T09:50:00.000Z + + + Sjors Provoost + 2025-04-26T10:53:00.000Z + + + Luke Dashjr + 2025-04-26T11:35:00.000Z + + + Sjors Provoost + 2025-04-26T11:45:00.000Z + + + Pieter Wuille + 2025-04-26T12:48:00.000Z + + + Jason Hughes (wk057) + 2025-04-28T16:20:00.000Z + + + Sjors Provoost + 2025-04-29T14:51:00.000Z + + + Martin Habovštiak + 2025-04-29T19:20:00.000Z + + + Jason Hughes + 2025-04-30T00:10:00.000Z + + + Chris Guida + 2025-04-30T05:39:00.000Z + + + Nagaev Boris + 2025-04-30T15:37:00.000Z + + + Sjors Provoost + 2025-04-30T16:30:00.000Z + + + Anthony Towns + 2025-04-30T16:37:00.000Z + + + Anthony Towns + 2025-05-01T03:01:00.000Z + + + Chris Guida + 2025-05-01T04:57:00.000Z + + + Andrew Toth + 2025-05-01T17:40:00.000Z + + + Nagaev Boris + 2025-05-01T19:33:00.000Z + + + Antoine Poinsot' + 2025-05-01T22:40:00.000Z + + + PandaCute + 2025-05-02T00:14:00.000Z + + + Re: Relax OP_RETURN standardness restrictions Greg Maxwell + 2025-05-02T06:29:00.000Z + + + Anthony Towns + 2025-05-02T06:34:00.000Z + + + Anthony Towns + 2025-05-02T09:51:00.000Z + + + Sjors Provoost + 2025-05-02T11:16:00.000Z + + + Bob Burnett + 2025-05-02T13:58:00.000Z + + + nsvrn' + 2025-05-02T14:37:00.000Z + + + Greg Maxwell + 2025-05-02T16:43:00.000Z + + + Greg Maxwell + 2025-05-02T17:36:00.000Z + + + Peter Todd + 2025-05-02T18:29:00.000Z + + + Greg Tonoski + 2025-05-02T18:56:00.000Z + + + /dev /fd0 + 2025-05-02T19:04:00.000Z + + + Removing OP_Return restrictions: Devil's Advocate Position Peter Todd + 2025-05-02T20:03:00.000Z + + + Peter Todd + 2025-05-02T20:10:00.000Z + + + Re: Relax OP_RETURN standardness restrictions Peter Todd + 2025-05-02T20:43:00.000Z + + + Greg Maxwell + 2025-05-02T22:58:00.000Z + + + Martin Habovštiak + 2025-05-03T02:02:00.000Z + + + nsvrn' + 2025-05-03T05:14:00.000Z + + + Nagaev Boris + 2025-05-04T20:04:00.000Z + + + Bitcoin Error Log + 2025-05-05T06:04:00.000Z + + + Anthony Towns + 2025-05-05T09:18:00.000Z + + + Greg Maxwell + 2025-05-05T11:42:00.000Z + + + Greg Maxwell + 2025-05-05T14:05:00.000Z + + + Nagaev Boris + 2025-05-05T14:32:00.000Z + + + Peter Todd + 2025-05-05T21:30:00.000Z + + + Weak blocks give an advantage to large miners Peter Todd + 2025-05-05T21:34:00.000Z + + + Peter Todd + 2025-05-05T21:45:00.000Z + + + Greg Maxwell + 2025-05-05T23:55:00.000Z + + + Sjors Provoost + 2025-05-06T08:56:00.000Z + + + pithosian + 2025-05-07T01:20:00.000Z + + + Greg Maxwell + 2025-05-07T11:32:00.000Z + + + pithosian + 2025-05-07T16:55:00.000Z + + + James O'Beirne + 2025-05-07T20:42:00.000Z + + + Anthony Towns + 2025-05-12T13:47:00.000Z + + + Antoine Poinsot' + 2025-05-14T15:54:00.000Z + + + Antoine Poinsot' + 2025-05-20T16:26:00.000Z + + + Greg Maxwell + 2025-05-20T23:12:00.000Z + + + Bob Burnett + 2025-05-21T02:10:00.000Z + + + Sjors Provoost + 2025-05-21T07:41:00.000Z + + + Bob Burnett + 2025-05-21T13:38:00.000Z + + + Pieter Wuille + 2025-05-21T14:47:00.000Z + + + Bob Burnett + 2025-05-21T17:19:00.000Z + + + Pieter Wuille + 2025-05-21T17:52:00.000Z + + + Bob Burnett + 2025-05-21T18:12:00.000Z + + + waxwing/ AdamISZ + 2025-05-25T15:53:00.000Z + + @@ -283,17 +356,15 @@ - python-feedgen + 2 Combined summary - Relax OP_RETURN standardness restrictions - 2025-05-26T02:57:22.317755+00:00 + 2025-09-26T14:37:01.062521+00:00 + 2025-05-25T15:53:00+00:00 The ongoing discussions within the Bitcoin Development Mailing List have brought to light several key points regarding the use and regulation of OP_RETURN outputs in Bitcoin transactions. Initially, the standardness rules were established with the intention of discouraging the blockchain from being used as a data storage system, aiming to make data embedding slightly inconvenient while still allowing for an alternative that was less harmful than other methods. These rules include limiting transactions to no more than one OP_RETURN output, which must also be under 83 bytes. However, developers have creatively found ways around these limitations, as exemplified by the Citrea bridge named Clementine, which uses Taproot outputs to embed data. - This inventive approach underscores the challenges of enforcing restrictions meant to discourage certain practices within the Bitcoin network. The effectiveness of these measures has been called into question, as they have inadvertently encouraged less desirable behaviors without significantly deterring the storage of arbitrary data on the blockchain. In response to these challenges, there is a proposal to remove restrictions related to OP_RETURN outputs. The proposed changes include eliminating the limit on the size of scriptPubKey for OP_RETURN outputs as an initial step, followed by removing the limitation on the number of OP_RETURN outputs per transaction. This approach is aimed at ceasing the promotion of harmful practices within the network by adjusting the standardness rules to better accommodate the evolving needs of various cryptographic schemes and protocols utilizing the blockchain. - These discussions reflect the dynamic nature of blockchain technology development and highlight the need for continuous adaptation of the network's regulatory framework to support innovation. By reconsidering the limitations placed on OP_RETURN outputs, the Bitcoin development community is exploring ways to optimize the blockchain's functionality while maintaining its integrity and security. The dialogue emphasizes the importance of balancing the encouragement of technological advancements with the prevention of misuse, illustrating the complexities involved in managing a decentralized digital currency like Bitcoin. - 2025-05-25T15:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Removing-checkpoints-in-Bitcoin-Core-v30.xml b/static/bitcoin-dev/April_2025/combined_Removing-checkpoints-in-Bitcoin-Core-v30.xml index 31dff304f0..ee185506be 100644 --- a/static/bitcoin-dev/April_2025/combined_Removing-checkpoints-in-Bitcoin-Core-v30.xml +++ b/static/bitcoin-dev/April_2025/combined_Removing-checkpoints-in-Bitcoin-Core-v30.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Removing checkpoints in Bitcoin Core v30 - 2025-05-03T02:57:40.508553+00:00 - - eric 2025-05-02 21:16:00+00:00 - - - Sjors Provoost 2025-04-28 16:25:00+00:00 - - - Sjors Provoost 2025-04-28 11:34:00+00:00 - + 2025-09-26T14:36:56.691941+00:00 + python-feedgen + + + Removing checkpoints in Bitcoin Core v30 Sjors Provoost + 2025-04-28T11:34:00.000Z + + + Sjors Provoost + 2025-04-28T16:25:00.000Z + + + eric + 2025-05-02T21:16:00.000Z + + - python-feedgen + 2 Combined summary - Removing checkpoints in Bitcoin Core v30 - 2025-05-03T02:57:40.508598+00:00 + 2025-09-26T14:36:56.692563+00:00 - In a comprehensive discussion on the Bitcoin Development Mailing List, the subject of checkpoints in the Bitcoin protocol was thoroughly examined. Checkpoints, initially implemented to safeguard against Denial of Service (DoS) attacks, have become a focal point due to their perceived potential to enhance performance. This has raised concerns over the possibility that their misuse for performance improvements could prompt the development of alternative Bitcoin Core or Libbitcoin versions exploiting "honest" checkpoints alongside a UTXO snapshot for accelerated performance. An experiment conducted on an M4 MacBook to evaluate the impact of checkpoints on Initial Block Download (IBD) times revealed that the difference in time with and without checkpoints up to block 295,000 was minimal, suggesting that the early blocks constituting only 3% of all transactions do not significantly benefit from checkpointing in terms of signature verification times. Moreover, it was argued that loading a UTXO snapshot at checkpoint height might offer a modest speedup, but this would only marginally improve efficiency. - -The conversation also delved into the `-assumevalid` feature as an alternative to checkpoints, suggesting its replacement with a combination of AssumeUTXO and SwiftSync to allow more efficient background validation while maintaining full validation capabilities. This proposal aims to boost blockchain performance without overly depending on checkpoints or compromising security against DoS attacks. The upcoming v30 release of Bitcoin Core will see the removal of checkpoints and all related support code, based on the assessment that these measures have become redundant following the introduction of headers pre-sync functionality in v24, which effectively counteracts low proof-of-work header spam attacks. The consensus among developers suggests that new checkpoints are unnecessary for adequate security against such threats. The dialogue also recognized the potential for network splits due to extremely large reorganizations, though such events are considered highly improbable. Despite the humorous attribution of these scenarios to aliens or the NSA, they underline a significant vulnerability in network resilience. The conversation acknowledges the existential risks posed by such catastrophic events to Bitcoin's value and utility, proposing a Bitcoin Improvement Proposal (BIP) to establish protocols for restoring network consistency and recommending the permanent activation of certain soft fork rules from the genesis block in the absence of the last checkpoint header. This proactive approach reflects a commitment to preserving Bitcoin's integrity against theoretical threats to its continuity and stability. Further details and technical rationale behind these decisions can be found through references to [Bitcoin Core Pull Request](https://github.com/bitcoin/bitcoin/pull/0) and [Headers Pre-Sync Functionality](https://github.com/bitcoin/bitcoin/pull/1). 2025-05-02T21:16:00+00:00 + In a comprehensive discussion on the Bitcoin Development Mailing List, the subject of checkpoints in the Bitcoin protocol was thoroughly examined. Checkpoints, initially implemented to safeguard against Denial of Service (DoS) attacks, have become a focal point due to their perceived potential to enhance performance. This has raised concerns over the possibility that their misuse for performance improvements could prompt the development of alternative Bitcoin Core or Libbitcoin versions exploiting "honest" checkpoints alongside a UTXO snapshot for accelerated performance. An experiment conducted on an M4 MacBook to evaluate the impact of checkpoints on Initial Block Download (IBD) times revealed that the difference in time with and without checkpoints up to block 295,000 was minimal, suggesting that the early blocks constituting only 3% of all transactions do not significantly benefit from checkpointing in terms of signature verification times. Moreover, it was argued that loading a UTXO snapshot at checkpoint height might offer a modest speedup, but this would only marginally improve efficiency. +The conversation also delved into the `-assumevalid` feature as an alternative to checkpoints, suggesting its replacement with a combination of AssumeUTXO and SwiftSync to allow more efficient background validation while maintaining full validation capabilities. This proposal aims to boost blockchain performance without overly depending on checkpoints or compromising security against DoS attacks. The upcoming v30 release of Bitcoin Core will see the removal of checkpoints and all related support code, based on the assessment that these measures have become redundant following the introduction of headers pre-sync functionality in v24, which effectively counteracts low proof-of-work header spam attacks. The consensus among developers suggests that new checkpoints are unnecessary for adequate security against such threats. The dialogue also recognized the potential for network splits due to extremely large reorganizations, though such events are considered highly improbable. Despite the humorous attribution of these scenarios to aliens or the NSA, they underline a significant vulnerability in network resilience. The conversation acknowledges the existential risks posed by such catastrophic events to Bitcoin's value and utility, proposing a Bitcoin Improvement Proposal (BIP) to establish protocols for restoring network consistency and recommending the permanent activation of certain soft fork rules from the genesis block in the absence of the last checkpoint header. This proactive approach reflects a commitment to preserving Bitcoin's integrity against theoretical threats to its continuity and stability. Further details and technical rationale behind these decisions can be found through references to [Bitcoin Core Pull Request](https://github.com/bitcoin/bitcoin/pull/0) and [Headers Pre-Sync Functionality](https://github.com/bitcoin/bitcoin/pull/1). - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Standard-Unstructured-Annex.xml b/static/bitcoin-dev/April_2025/combined_Standard-Unstructured-Annex.xml index 635969fb01..25c76f352c 100644 --- a/static/bitcoin-dev/April_2025/combined_Standard-Unstructured-Annex.xml +++ b/static/bitcoin-dev/April_2025/combined_Standard-Unstructured-Annex.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Standard Unstructured Annex - 2025-04-30T02:51:38.262133+00:00 - - Peter Todd 2025-04-29 02:59:00+00:00 - - - Russell OConnor 2025-04-28 16:25:00+00:00 - - - Russell OConnor 2025-04-28 16:13:00+00:00 - - - Antoine Riard 2025-04-09 22:55:00+00:00 - - - Peter Todd 2025-03-24 16:17:00+00:00 - - - Antoine Riard 2025-03-20 22:47:00+00:00 - - - Peter Todd 2025-03-20 00:27:00+00:00 - + 2025-09-26T14:36:26.696499+00:00 + python-feedgen + + + Standard Unstructured Annex Peter Todd + 2025-03-20T00:27:00.000Z + + + Antoine Riard + 2025-03-20T22:47:00.000Z + + + Peter Todd + 2025-03-24T16:17:00.000Z + + + Antoine Riard + 2025-04-09T22:55:00.000Z + + + Russell O'Connor' + 2025-04-28T16:13:00.000Z + + + Russell O'Connor' + 2025-04-28T16:25:00.000Z + + + Peter Todd + 2025-04-29T02:59:00.000Z + + @@ -31,21 +41,17 @@ - python-feedgen + 2 Combined summary - Standard Unstructured Annex - 2025-04-30T02:51:38.262195+00:00 + 2025-09-26T14:36:26.697406+00:00 + 2025-04-29T02:59:00+00:00 The discussion primarily focuses on a new rule proposal regarding the use of annexes within Bitcoin transactions. It introduces a stipulation that if any input within a transaction includes an annex, then all inputs must feature an annex, albeit they can be empty. This standardization aims to streamline transaction validation processes by enforcing a consistent approach to handling annexes, potentially simplifying the protocol's operation and enhancing its efficiency. The rule is designed to facilitate a uniform method for indicating approval of annex usage across transactions, distinguishing between having no annex and a zero-byte annex in an attempt to standardize participation in such transactions. - Further elaboration within the discussion addresses concerns around the potential for transaction pinning attacks in multi-party protocols due to the manipulation of annex sizes. The inclusion of an annex in each input does not inherently prevent a party from broadcasting a version of the transaction that is heavier and has a lower fee rate, which could complicate the transaction process. There's a dialogue about the need for strategies, like full Replace-By-Fee (RBF), to mitigate these risks, indicating ongoing explorations into more effective measures against such vulnerabilities. - An additional point of interest is the proposition of encoding schemes and versioning within Bitcoin's evolving framework, particularly in light of the Taproot upgrade. The suggested inclusion of a one-byte version number in payload data offers applications greater flexibility and domain separation, encouraging innovation while maintaining compatibility with future protocol enhancements. This approach reflects a broader movement towards refining Bitcoin's infrastructure to support complex functionalities and improve user experience through standardization and upgradability. - The conversation also touches on the emerging consensus favoring a tag-length-value (TLV) encoding scheme for annex data, highlighting the ongoing efforts to standardize and enhance functionality within the blockchain domain. This shift underscores the technological progress being made towards achieving a consensus on encoding practices, aiming to facilitate application upgrades and improve system interoperability. The proactive stance on integrating mechanisms to defend against potential annex-related exploits, such as witness-RBF combined with replace-by-fee-rate tactics, exemplifies the commitment to securing and advancing the network's capabilities. - Lastly, the discussion delves into the integration of taproot annex support, emphasizing the requirement for initiating all non-empty annexes with byte 0x00 to distinguish them from future consensus-relevant annexes. This measure seeks to ensure compatibility with potential soft-forks and maintain the integrity of the network's operations. The specification that all inputs must have an annex, serving as an opt-in feature, is highlighted as a crucial step towards mitigating the risk of transaction pinning attacks, reflecting the ongoing evolution of policies to enhance network security and efficiency. - 2025-04-29T02:59:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_SwiftSync-smarter-synchronization-with-hints.xml b/static/bitcoin-dev/April_2025/combined_SwiftSync-smarter-synchronization-with-hints.xml index 1b97857c6e..4fad71f655 100644 --- a/static/bitcoin-dev/April_2025/combined_SwiftSync-smarter-synchronization-with-hints.xml +++ b/static/bitcoin-dev/April_2025/combined_SwiftSync-smarter-synchronization-with-hints.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - SwiftSync - smarter synchronization with hints - 2025-05-05T02:52:46.682238+00:00 - - Nagaev Boris 2025-05-04 01:06:00+00:00 - - - Ruben Somsen 2025-05-03 16:24:00+00:00 - - - Greg Maxwell 2025-05-03 15:54:00+00:00 - - - Ruben Somsen 2025-05-03 14:55:00+00:00 - - - Greg Maxwell 2025-05-03 14:36:00+00:00 - - - Greg Maxwell 2025-05-03 13:57:00+00:00 - - - Weikeng Chen 2025-05-03 13:53:00+00:00 - - - Ruben Somsen 2025-05-03 13:42:00+00:00 - - - Greg Maxwell 2025-05-03 12:02:00+00:00 - - - Sanket Kanjalkar 2025-05-02 20:23:00+00:00 - - - Saint Wenhao 2025-05-02 19:15:00+00:00 - - - Greg Maxwell 2025-05-02 16:07:00+00:00 - - - Saint Wenhao 2025-05-02 13:38:00+00:00 - - - Ruben Somsen 2025-05-02 10:59:00+00:00 - - - Greg Maxwell 2025-05-02 06:47:00+00:00 - - - Ruben Somsen 2025-04-09 10:10:00+00:00 - + 2025-09-26T14:36:33.138561+00:00 + python-feedgen + + + SwiftSync - smarter synchronization with hints Ruben Somsen + 2025-04-09T10:10:00.000Z + + + Greg Maxwell + 2025-05-02T06:47:00.000Z + + + Ruben Somsen + 2025-05-02T10:59:00.000Z + + + Saint Wenhao + 2025-05-02T13:38:00.000Z + + + Greg Maxwell + 2025-05-02T16:07:00.000Z + + + Saint Wenhao + 2025-05-02T19:15:00.000Z + + + Sanket Kanjalkar + 2025-05-02T20:23:00.000Z + + + Greg Maxwell + 2025-05-03T12:02:00.000Z + + + Ruben Somsen + 2025-05-03T13:42:00.000Z + + + Weikeng Chen + 2025-05-03T13:53:00.000Z + + + Greg Maxwell + 2025-05-03T13:57:00.000Z + + + Greg Maxwell + 2025-05-03T14:36:00.000Z + + + Ruben Somsen + 2025-05-03T14:55:00.000Z + + + Greg Maxwell + 2025-05-03T15:54:00.000Z + + + Ruben Somsen + 2025-05-03T16:24:00.000Z + + + Nagaev Boris + 2025-05-04T01:06:00.000Z + + @@ -67,27 +86,20 @@ - python-feedgen + 2 Combined summary - SwiftSync - smarter synchronization with hints - 2025-05-05T02:52:46.682348+00:00 + 2025-09-26T14:36:33.140498+00:00 + 2025-05-04T01:06:00+00:00 In a series of exchanges on the Bitcoin Development Mailing List, participants delved into various aspects of blockchain technology's security and efficiency. The discussions covered topics from the potential vulnerabilities in transaction ID (TXID) handling to innovative approaches for optimizing synchronization mechanisms among nodes within the network. A key focus was on the cryptographic practices underlying Bitcoin's development, emphasizing the importance of rigorous scrutiny to ensure the robustness and integrity of the cryptocurrency. - One discussion explored the vulnerability associated with truncating transaction identifiers, highlighting a fundamental flaw in limiting TXID lengths. This could potentially enable attackers to negate the impact of accumulators through repeated operations, underscoring the need for careful consideration in cryptographic modifications. Another conversation introduced SwiftSync, an innovative method proposing to streamline the validation process by applying XOR logic to transaction identifiers. This approach aims to enhance network efficiency by reducing the computational load required for transaction verification, marking a significant shift towards optimizing blockchain functionality. - The dialogue further extended into the realm of cryptographic salt's role in securing transactions, suggesting that privacy and uniqueness are paramount for effective application. This detailed examination reflects ongoing debates among developers regarding optimization and security of cryptographic methods, illustrating the community's commitment to refining Bitcoin's underlying mechanisms. - Additionally, concerns were raised about using AES encryption over traditional hashing for proving relationships between unspent transaction outputs (UTXOs), with a focus on collision resistance and the choice of encryption mode. This discussion points to continued efforts in exploring new cryptographic techniques to secure transactions while enhancing privacy. - -Another notable exchange proposed bypassing conventional hashing techniques by directly managing transaction outputs, addressing potential manipulation vulnerabilities and suggesting optimizations like "hashPrevouts" for processing efficiency. This forward-looking perspective advocates for designing protocols that accommodate future enhancements, aiming for more efficient and secure transaction processing. - +Another notable exchange proposed bypassing conventional hashing techniques by directly managing transaction outputs, addressing potential manipulation vulnerabilities and suggesting optimizations like "hashPrevouts" for processing efficiency. This forward-looking perspective advocates for designing protocols that accommodate future enhancements, aiming for more efficient and secure transaction processing. The conversation also touched on optimizing SwiftSync by addressing practical challenges such as ordered block processing and space savings. Participants debated the feasibility of weaker hash functions versus the benefits of proof-of-work mechanisms, balancing efficiency with security requirements. This comprehensive analysis highlights the complex interplay between performance and security in blockchain development. - Greg Maxwell contributed insights on tagged hashes and the implications of hash grinding, emphasizing the need for robust security mechanisms against evolving threats. The discussions underscored the significance of cryptographic principles in maintaining blockchain technology's resilience. - Lastly, SwiftSync's introduction as a near-stateless validation technique marked a pivotal advancement. By utilizing hints about unspent outputs and leveraging hash aggregates, SwiftSync promises substantial speed-ups in blockchain validation without compromising security. The protocol's innovative approach to UTXO set management during Initial Block Download showcases the potential for significant efficiency gains, aligning with the broader goals of optimizing blockchain technology for better performance and reliability. - 2025-05-04T01:06:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_The-Future-of-Bitcoin-Testnet.xml b/static/bitcoin-dev/April_2025/combined_The-Future-of-Bitcoin-Testnet.xml index 45054a7a94..08245f762f 100644 --- a/static/bitcoin-dev/April_2025/combined_The-Future-of-Bitcoin-Testnet.xml +++ b/static/bitcoin-dev/April_2025/combined_The-Future-of-Bitcoin-Testnet.xml @@ -1,134 +1,179 @@ - + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303256+00:00 - - Saint Wenhao 2025-04-25 17:19:00+00:00 - - - Garlo Nicon 2025-03-31 10:48:00+00:00 - - - Peter Todd 2024-05-04 17:13:00+00:00 - - - Peter Todd 2024-05-04 17:08:00+00:00 - - - Ali Sherief 2024-05-02 07:10:00+00:00 - - - Garlo Nicon 2024-05-01 15:30:00+00:00 - - - Matthew Bagazinski 2024-04-30 18:46:00+00:00 - - - Matt Corallo 2024-04-28 13:45:00+00:00 - - - Ali Sherief 2024-04-22 04:33:00+00:00 - - - Sjors Provoost 2024-04-16 17:30:00+00:00 - - - Garlo Nicon 2024-04-10 06:57:00+00:00 - - - Garlo Nicon 2024-04-09 18:28:00+00:00 - - - Peter Todd 2024-04-09 16:48:00+00:00 - - - coinableS 2024-04-09 04:29:00+00:00 - - - Garlo Nicon 2024-04-08 19:11:00+00:00 - - - K Calvin 2024-04-07 08:09:00+00:00 - - - Christian Decker 2024-04-07 07:20:00+00:00 - - - David A. Harding 2024-04-06 23:04:00+00:00 - - - Calvin Kim 2024-04-05 04:30:00+00:00 - - - Jameson Lopp 2024-04-04 12:47:00+00:00 - - - Calvin Kim 2024-04-04 08:14:00+00:00 - - - Andrew Poelstra 2024-04-03 19:35:00+00:00 - - - emsit 2024-04-03 18:18:00+00:00 - - - Anthony Towns 2024-04-03 04:19:00+00:00 - - - Jameson Lopp 2024-04-02 19:46:00+00:00 - - - Lukáš Kráľ 2024-04-02 18:36:00+00:00 - - - Jameson Lopp 2024-04-02 11:53:00+00:00 - - - Fabian 2024-04-01 22:01:00+00:00 - - - emsit 2024-04-01 19:22:00+00:00 - - - Warren Togami 2024-04-01 14:28:00+00:00 - - - Andrew Poelstra 2024-04-01 14:20:00+00:00 - - - Pieter Wuille 2024-04-01 13:37:00+00:00 - - - Fabian 2024-04-01 13:32:00+00:00 - - - Peter Todd 2024-04-01 13:25:00+00:00 - - - Jameson Lopp 2024-04-01 12:54:00+00:00 - - - Peter Todd 2024-03-31 21:29:00+00:00 - - - Nagaev Boris 2024-03-31 21:01:00+00:00 - - - Eric Voskuil 2024-03-31 17:21:00+00:00 - - - Peter Todd 2024-03-31 16:02:00+00:00 - - - Jameson Lopp 2024-03-31 14:57:00+00:00 - - - Luke Dashjr 2024-03-31 14:33:00+00:00 - - - Jameson Lopp 2024-03-31 13:19:00+00:00 - + 2025-09-26T14:37:03.250356+00:00 + python-feedgen + + + The Future of Bitcoin Testnet Jameson Lopp + 2024-03-31T13:19:00.000Z + + + Luke Dashjr + 2024-03-31T14:33:00.000Z + + + Jameson Lopp + 2024-03-31T14:57:00.000Z + + + Peter Todd + 2024-03-31T16:02:00.000Z + + + Eric Voskuil + 2024-03-31T17:21:00.000Z + + + Nagaev Boris + 2024-03-31T21:01:00.000Z + + + Peter Todd + 2024-03-31T21:29:00.000Z + + + Jameson Lopp + 2024-04-01T12:54:00.000Z + + + Andrew Poelstra + 2024-04-01T13:25:00.000Z + + + Fabian' + 2024-04-01T13:32:00.000Z + + + Pieter Wuille + 2024-04-01T13:37:00.000Z + + + Andrew Poelstra + 2024-04-01T14:20:00.000Z + + + Warren Togami + 2024-04-01T14:28:00.000Z + + + emsit + 2024-04-01T19:22:00.000Z + + + Fabian' + 2024-04-01T22:01:00.000Z + + + Jameson Lopp + 2024-04-02T11:53:00.000Z + + + Lukáš Kráľ + 2024-04-02T18:36:00.000Z + + + Jameson Lopp + 2024-04-02T19:46:00.000Z + + + Anthony Towns + 2024-04-03T04:19:00.000Z + + + emsit + 2024-04-03T18:18:00.000Z + + + Andrew Poelstra + 2024-04-03T19:35:00.000Z + + + Calvin Kim + 2024-04-04T08:14:00.000Z + + + Jameson Lopp + 2024-04-04T12:47:00.000Z + + + Calvin Kim + 2024-04-05T04:30:00.000Z + + + David A. Harding + 2024-04-06T23:04:00.000Z + + + Christian Decker + 2024-04-07T07:20:00.000Z + + + K Calvin + 2024-04-07T08:09:00.000Z + + + Garlo Nicon + 2024-04-08T19:11:00.000Z + + + coinableS + 2024-04-09T04:29:00.000Z + + + Peter Todd + 2024-04-09T16:48:00.000Z + + + Garlo Nicon + 2024-04-09T18:28:00.000Z + + + Garlo Nicon + 2024-04-10T06:57:00.000Z + + + Sjors Provoost' + 2024-04-16T17:30:00.000Z + + + Ali Sherief + 2024-04-22T04:33:00.000Z + + + Matt Corallo + 2024-04-28T13:45:00.000Z + + + Matthew Bagazinski + 2024-04-30T18:46:00.000Z + + + Garlo Nicon + 2024-05-01T15:30:00.000Z + + + Ali Sherief + 2024-05-02T07:10:00.000Z + + + Peter Todd + 2024-05-04T17:08:00.000Z + + + Peter Todd + 2024-05-04T17:13:00.000Z + + + Garlo Nicon + 2025-03-31T10:48:00.000Z + + + Saint Wenhao + 2025-04-25T17:19:00.000Z + + @@ -171,17 +216,15 @@ - python-feedgen + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303535+00:00 + 2025-09-26T14:37:03.254652+00:00 + 2025-04-25T17:19:00+00:00 The discourse surrounding the future and functionality of Bitcoin's testnet3 brings to light several pressing issues and proposals for its evolution. Testnet3, after 13 years of operation and reaching a block height of approximately 2.5 million, finds itself at a crossroads due to a significantly reduced block reward and operational challenges arising from an edge case bug that resets the mining difficulty to one. This anomaly has led to operational inconsistencies and raised concerns about the effective distribution of testnet coins, as detailed in Jameson Lopp’s comprehensive analysis available [here](https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/). Furthermore, the network faces exploitation through scammy airdrops and an unintended marketplace where TBTC is actively traded, deviating from its foundational principle that testnet coins should hold no real-world value. - In response to these challenges, several key questions and proposals are presented to the community. The potential for a testnet reset is considered, recognizing the need for substantial notice due to the extensive updates required for production systems. Additionally, addressing the difficulty reset bug emerges as a priority, with suggestions for a straightforward code fix that might necessitate a hard fork. This approach, while potentially disruptive, could naturally integrate into the network's dynamics if executed thoughtfully. The necessity of formalizing this process through a Bitcoin Improvement Proposal (BIP) or adopting a more informal implementation strategy remains a point of debate. - Moreover, the discussion extends to the possibility of deprecating testnet3 in favor of signet, highlighting an ongoing exploration of alternative testing environments that might better serve the needs of the Bitcoin development community. This conversation reflects a broader debate on balancing innovation and stability within Bitcoin's development platforms, emphasizing the importance of community feedback and collaborative decision-making in navigating the future of testnet3. The dialogue ultimately underscores the complexities of managing blockchain networks like Bitcoin, where technical adjustments must consider both their immediate impact and broader implications for developers, miners, and the ecosystem at large. - 2025-04-25T17:19:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_The-Tragic-Tale-of-BIP30.xml b/static/bitcoin-dev/April_2025/combined_The-Tragic-Tale-of-BIP30.xml index 89fb7e11f1..24e9cfc06f 100644 --- a/static/bitcoin-dev/April_2025/combined_The-Tragic-Tale-of-BIP30.xml +++ b/static/bitcoin-dev/April_2025/combined_The-Tragic-Tale-of-BIP30.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - The Tragic Tale of BIP30 - 2025-05-11T02:52:46.926246+00:00 - - Eric Voskuil 2025-05-10 16:55:00+00:00 - - - Sjors Provoost 2025-05-10 16:17:00+00:00 - - - Eric Voskuil 2025-05-10 15:39:00+00:00 - - - eric 2025-05-02 21:09:00+00:00 - - - eric 2025-05-02 21:09:00+00:00 - - - Sjors Provoost 2025-04-29 15:28:00+00:00 - - - Ruben Somsen 2025-04-29 15:11:00+00:00 - - - Eric Voskuil 2025-04-28 12:39:00+00:00 - - - Sjors Provoost 2025-04-28 11:48:00+00:00 - - - eric 2025-04-27 21:01:00+00:00 - - - eric 2025-04-27 18:30:00+00:00 - - - Luke Dashjr 2025-04-27 18:20:00+00:00 - - - Ruben Somsen 2025-04-27 16:45:00+00:00 - + 2025-09-26T14:36:45.871622+00:00 + python-feedgen + + + The Tragic Tale of BIP30 Ruben Somsen + 2025-04-27T16:45:00.000Z + + + Luke Dashjr + 2025-04-27T18:20:00.000Z + + + eric + 2025-04-27T18:30:00.000Z + + + eric + 2025-04-27T21:01:00.000Z + + + Sjors Provoost + 2025-04-28T11:48:00.000Z + + + Eric Voskuil + 2025-04-28T12:39:00.000Z + + + Ruben Somsen + 2025-04-29T15:11:00.000Z + + + Sjors Provoost + 2025-04-29T15:28:00.000Z + + + eric + 2025-05-02T21:09:00.000Z + + + eric + 2025-05-02T21:09:00.000Z + + + Eric Voskuil + 2025-05-10T15:39:00.000Z + + + Sjors Provoost + 2025-05-10T16:17:00.000Z + + + Eric Voskuil + 2025-05-10T16:55:00.000Z + + @@ -55,25 +71,19 @@ - python-feedgen + 2 Combined summary - The Tragic Tale of BIP30 - 2025-05-11T02:52:46.926340+00:00 + 2025-09-26T14:36:45.873153+00:00 + 2025-05-10T16:55:00+00:00 The recent discussions within the Bitcoin Development Mailing List have illuminated several critical aspects and proposed changes to the Bitcoin protocol, focusing on the integrity and future direction of the blockchain. A significant point of contention revolves around the handling of consensus bugs and the role of checkpoints in mitigating potential chain splits. Specifically, the debate touches upon the implications of removing 14 checkpoints, which has been a topic of concern among developers due to the potential for causing chain splits, particularly relating to a consensus bug associated with BIP30. The removal of these checkpoints has led to a broader dialogue about the consistency and stability of the blockchain, urging a reevaluation of how technical decisions impact both the historical consistency and future integrity of the network. - Additionally, an interesting proposal has been introduced regarding the use of BIP54's nLockTime rule as a mechanism for forking the Bitcoin blockchain. This approach, which diverges from existing blocks by not adhering to BIP54 specifications, suggests a novel methodology for initiating forks, thereby highlighting the flexibility of blockchain protocols in accommodating new branches or versions. Such discussions underscore the evolving nature of blockchain technology and the creative avenues through which developers can navigate protocol limitations or design innovative solutions. - The conversation further extends to the technical intricacies of managing the Unspent Transaction Output (UTXO) set and addresses specific challenges such as duplicate transaction IDs (txids) and their impact on blockchain transactions. The dialogue reveals that certain assumptions regarding txid uniqueness have led to reevaluations of protocol effectiveness, specifically BIP30, which was designed to handle exceptions by eliminating duplicate entries. This discussion not only delves into the specifics of blockchain operations but also explores potential fixes and the interplay between different Bitcoin Improvement Proposals (BIPs), such as BIP34 and the Consensus Cleanup amendment, in enhancing protocol efficiency and security. - Moreover, there has been an acknowledgment of the need for a more detailed examination before implementing significant changes like the removal of checkpoints, reflecting a cautious approach to protocol modifications. The discourse emphasizes the balancing act between efficiency, security, and consensus within the cryptocurrency development community, highlighting the complexities involved in protocol development and the continuous effort required to address emerging challenges. - In terms of practical improvements to Bitcoin's transaction handling mechanisms, two specific solutions were proposed to address issues related to transaction overwrites and the creation of redundant UTXOs. These proposals aim to streamline the process by either reversing the effects of overwriting transactions or avoiding the creation of unnecessary UTXOs, although concerns regarding computational efficiency and the increased CPU time required for transaction verification were raised, suggesting that optimization remains a key challenge. - Finally, the discussions touched upon the implications of sunsetting BIP30 in favor of more efficient validation methods like utreexo, SwiftSync, and Zero-Knowledge Proof systems. The inefficiency of BIP30's UTXO set check has prompted suggestions for a system that caches coinbase TXIDs to prevent duplicates, potentially allowing for the complete sunset of BIP30. This reflects the ongoing pursuit of optimizing and securing the Bitcoin protocol against significant threats while maintaining its functionality and resilience. - These conversations within the Bitcoin Development Mailing List illustrate the proactive, forward-thinking approach of the developer community in addressing technical challenges, optimizing blockchain functionality, and ensuring the network's long-term stability and security. - 2025-05-10T16:55:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_Unbreaking-testnet4.xml b/static/bitcoin-dev/April_2025/combined_Unbreaking-testnet4.xml index 126bc0ac4c..6e8abdd233 100644 --- a/static/bitcoin-dev/April_2025/combined_Unbreaking-testnet4.xml +++ b/static/bitcoin-dev/April_2025/combined_Unbreaking-testnet4.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Unbreaking testnet4 - 2025-07-06T03:04:39.614598+00:00 - - Garlo Nicon 2025-07-05 04:31:00+00:00 - - - Saint Wenhao 2025-05-17 05:11:00+00:00 - - - pithosian 2025-05-12 20:19:00+00:00 - - - Saint Wenhao 2025-05-12 18:17:00+00:00 - - - pithosian 2025-05-12 12:05:00+00:00 - - - Anthony Towns 2025-05-12 05:21:00+00:00 - - - Garlo Nicon 2025-05-09 13:07:00+00:00 - - - Saint Wenhao 2025-05-06 11:48:00+00:00 - - - Greg Maxwell 2025-05-05 22:25:00+00:00 - - - Sjors Provoost 2025-04-28 18:50:00+00:00 - - - Saint Wenhao 2025-04-28 18:15:00+00:00 - - - Saint Wenhao 2025-04-28 13:33:00+00:00 - - - Sjors Provoost 2025-04-28 12:47:00+00:00 - - - emsit 2025-04-28 11:59:00+00:00 - - - pithosian 2025-04-28 11:48:00+00:00 - - - Jameson Lopp 2025-04-28 10:45:00+00:00 - - - Saint Wenhao 2025-04-28 06:11:00+00:00 - - - Jameson Lopp 2025-04-27 22:49:00+00:00 - - - Saint Wenhao 2025-04-27 11:44:00+00:00 - - - Saint Wenhao 2025-03-31 07:32:00+00:00 - - - Antoine Poinsot 2025-03-24 13:57:00+00:00 - - - Murch 2025-03-24 12:25:00+00:00 - - - Garlo Nicon 2025-03-24 07:00:00+00:00 - - - Murch 2025-03-21 21:20:00+00:00 - - - Melvin Carvalho 2025-03-20 18:58:00+00:00 - - - bitcoindevml.void 2025-03-19 17:03:00+00:00 - - - Melvin Carvalho 2025-03-19 09:11:00+00:00 - - - Garlo Nicon 2025-03-19 08:43:00+00:00 - - - Sjors Provoost 2025-03-19 08:32:00+00:00 - - - Sjors Provoost 2025-03-19 07:56:00+00:00 - - - Melvin Carvalho 2025-03-19 07:01:00+00:00 - - - Antoine Poinsot 2025-03-18 21:34:00+00:00 - - - Antoine Poinsot 2025-03-18 14:29:00+00:00 - + 2025-09-26T14:36:52.458242+00:00 + python-feedgen + + + Unbreaking testnet4 'Antoine Poinsot' + 2025-03-18T14:29:00.000Z + + + Melvin Carvalho + 2025-03-18T21:34:00.000Z + + + Garlo Nicon + 2025-03-19T07:01:00.000Z + + + Sjors Provoost + 2025-03-19T07:56:00.000Z + + + Sjors Provoost + 2025-03-19T08:32:00.000Z + + + Garlo Nicon + 2025-03-19T08:43:00.000Z + + + Melvin Carvalho + 2025-03-19T09:11:00.000Z + + + bitcoin-dev-ml.void867 + 2025-03-19T17:03:00.000Z + + + Melvin Carvalho + 2025-03-20T18:58:00.000Z + + + Murch + 2025-03-21T21:20:00.000Z + + + Garlo Nicon + 2025-03-24T07:00:00.000Z + + + Murch + 2025-03-24T12:25:00.000Z + + + Antoine Poinsot' + 2025-03-24T13:57:00.000Z + + + Saint Wenhao + 2025-03-31T07:32:00.000Z + + + Saint Wenhao + 2025-04-27T11:44:00.000Z + + + Jameson Lopp + 2025-04-27T22:49:00.000Z + + + Saint Wenhao + 2025-04-28T06:11:00.000Z + + + Jameson Lopp + 2025-04-28T10:45:00.000Z + + + pithosian + 2025-04-28T11:48:00.000Z + + + emsit' + 2025-04-28T11:59:00.000Z + + + Sjors Provoost + 2025-04-28T12:47:00.000Z + + + Saint Wenhao + 2025-04-28T13:33:00.000Z + + + Saint Wenhao + 2025-04-28T18:15:00.000Z + + + Sjors Provoost + 2025-04-28T18:50:00.000Z + + + Greg Maxwell + 2025-05-05T22:25:00.000Z + + + Saint Wenhao + 2025-05-06T11:48:00.000Z + + + Garlo Nicon + 2025-05-09T13:07:00.000Z + + + Anthony Towns + 2025-05-12T05:21:00.000Z + + + pithosian + 2025-05-12T12:05:00.000Z + + + Saint Wenhao + 2025-05-12T18:17:00.000Z + + + pithosian + 2025-05-12T20:19:00.000Z + + + Saint Wenhao + 2025-05-17T05:11:00.000Z + + + Garlo Nicon + 2025-07-05T04:31:00.000Z + + @@ -135,21 +171,17 @@ - python-feedgen + 2 Combined summary - Unbreaking testnet4 - 2025-07-06T03:04:39.614808+00:00 + 2025-09-26T14:36:52.461854+00:00 + 2025-07-05T04:31:00+00:00 The ongoing discourse within the Bitcoin development community underscores a collective drive towards refining the blockchain's testnet environment, aiming to bridge the gap between an ideal testing ground and the inherent challenges posed by current operational frameworks. Testnet4, introduced with aspirations to surmount the difficulties encountered in Testnet3—particularly those related to the difficulty reset mechanism—has paradoxically replicated similar challenges. The initiative to enable developers to mine blocks on less powerful devices like laptops, although well-intentioned, inadvertently led to exploitative practices that undermined the testnet's utility. This contradiction highlights a fundamental tension between maintaining a permissionless network, as is characteristic of Proof of Work (PoW) systems, and the necessity for a controlled environment conducive to development, such as that offered by Signet. - The debate extends to the question of how best to evolve the testnet framework without compromising its core objectives. A pivotal suggestion within this dialogue is the elimination of the difficulty reset rule from Testnet4 through a flag day hard fork slated for January 1, 2026. This proposed timeline provides ample opportunity for comprehensive review, integration into upcoming Bitcoin Core releases, and widespread adoption across existing infrastructure. This approach reflects a broader consideration of how to balance the need for an authentic replication of the Bitcoin mainnet against facilitating a practical and accessible platform for developers. - Further discussions have ventured into innovative solutions aimed at enhancing the testnet's functionality, including the development of a decentralized faucet by Antoine Poinsot. This tool represents a significant step towards lowering entry barriers for new developers and streamlining the testing process. Such initiatives underscore a concerted effort within the community to address the testnet's limitations, ensuring it remains a vital resource for fostering innovation and improving the robustness of Bitcoin's testing environments. - In parallel, conversations have also delved into technical aspects concerning the blockchain's code, particularly the `fPowAllowMinDifficultyBlocks` rule and its implications for block addition under specific circumstances. These discussions highlight the intricate nature of blockchain protocol management and the continuous efforts to strike a balance between flexibility, security, and fairness within the network's operation. - Overall, the dialogue within the Bitcoin Development Mailing List encapsulates a dynamic and ongoing process of reflection, critique, and collaborative problem-solving. It signifies a commitment among developers to not only navigate the complexities of blockchain technology but also to envision and implement changes that enhance its sustainability, efficacy, and inclusivity. - 2025-07-05T04:31:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2025/combined_secp256k1lab-a-Python-library-for-prototyping.xml b/static/bitcoin-dev/April_2025/combined_secp256k1lab-a-Python-library-for-prototyping.xml index 9c0e27385d..e3d306c4f3 100644 --- a/static/bitcoin-dev/April_2025/combined_secp256k1lab-a-Python-library-for-prototyping.xml +++ b/static/bitcoin-dev/April_2025/combined_secp256k1lab-a-Python-library-for-prototyping.xml @@ -1,33 +1,36 @@ - + 2 Combined summary - secp256k1lab: a Python library for prototyping - 2025-04-08T02:37:38.111641+00:00 - - Jonas Nick 2025-04-07 19:16:00+00:00 - - - waxwing/ AdamISZ 2025-04-01 13:01:00+00:00 - - - Jonas Nick 2025-04-01 08:41:00+00:00 - + 2025-09-26T14:36:39.536575+00:00 + python-feedgen + + + secp256k1lab: a Python library for prototyping Jonas Nick + 2025-04-01T08:41:00.000Z + + + waxwing/ AdamISZ + 2025-04-01T13:01:00.000Z + + + Jonas Nick + 2025-04-07T19:16:00.000Z + + - python-feedgen + 2 Combined summary - secp256k1lab: a Python library for prototyping - 2025-04-08T02:37:38.111687+00:00 + 2025-09-26T14:36:39.537154+00:00 + 2025-04-07T19:16:00+00:00 The discussion in the email revolves around the potential inclusion of advanced cryptographic techniques, specifically MuSig2 and adaptor signatures, within a new initiative aimed at enhancing Bitcoin's cryptographic infrastructure. The initiative in question has launched secp256k1lab, a Python library focused on the implementation of the secp256k1 elliptic curve, primarily for prototyping, experimentation, and educational purposes. However, it is important to note that this library is marked as INSECURE, indicating its unsuitability for use in production environments. The library is available for community access and contribution on GitHub at [secp256k1lab](https://github.com/secp256k1lab/secp256k1lab). - Secp256k1lab extends its functionality beyond basic elliptic curve cryptography operations to include Schnorr signatures according to BIP-340, supporting processes such as signing, verification, and key generation, as well as Elliptic Curve Diffie-Hellman (ECDH) for secure key exchange. This development stems from the project's connection with the ongoing ChillDKG Bitcoin Improvement Proposal (BIP), which seeks to enhance decentralized key generation protocols. By incorporating secp256k1lab, the developers aim to unify the approach to interacting with the secp256k1 curve across various BIPs, addressing the issue of minor but significant discrepancies between different implementations. This effort towards standardization is expected to improve both the usability and reliability of cryptographic functionalities critical to Bitcoin's infrastructure. - -The email correspondence also touches upon the expressed interests and inquiries from AdamISZ/waxwing regarding the scope of the project, particularly questioning whether there is room for integrating more complex cryptographic constructs such as MuSig2 and adaptor signatures. These features are deemed essential for advancing protocol development and have been highlighted as areas that previously required substantial effort in prototyping activities, as illustrated by the development of "pathcoin." The project maintainers responded, acknowledging the relevance of these advanced cryptographic features to the project's scope. They highlighted the ease with which MuSig2 could be added due to the existence of a Python reference implementation and test vectors, indicating a willingness to expand the project's capabilities in response to demonstrated demand and specific use cases such as the ChillDKG reference code. - +The email correspondence also touches upon the expressed interests and inquiries from AdamISZ/waxwing regarding the scope of the project, particularly questioning whether there is room for integrating more complex cryptographic constructs such as MuSig2 and adaptor signatures. These features are deemed essential for advancing protocol development and have been highlighted as areas that previously required substantial effort in prototyping activities, as illustrated by the development of "pathcoin." The project maintainers responded, acknowledging the relevance of these advanced cryptographic features to the project's scope. They highlighted the ease with which MuSig2 could be added due to the existence of a Python reference implementation and test vectors, indicating a willingness to expand the project's capabilities in response to demonstrated demand and specific use cases such as the ChillDKG reference code. Overall, the email exchange underscores a collaborative endeavor to broaden Bitcoin's cryptographic toolkit through secp256k1lab, facilitating innovation and education within the community while also contemplating the integration of more sophisticated cryptographic mechanisms to cater to evolving developmental needs. - 2025-04-07T19:16:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml b/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml index 90c13ac902..c81a11d54d 100644 --- a/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml +++ b/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A method for BIP322 signing delegation - 2023-08-02T07:16:51.606559+00:00 + 2025-09-26T14:26:10.364022+00:00 + python-feedgen Ali Sherief 2022-08-22 07:56:12+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - A method for BIP322 signing delegation - 2023-08-02T07:16:51.606559+00:00 + 2025-09-26T14:26:10.364175+00:00 - The message discusses an edge case that BIP322 only partially solves - Proof of Payment. In P2P transactions, there is always a risk that the other party will be dishonest and deny receiving payment. This type of dispute is rampant in cryptocurrencies as it can be used as a scam attempt to extract more money from the buyer. BIP322 signed messages can prove that the UTXO(s) belong to the buyer, but not *who* it was sent to.The proposal is to use P2WSH 2-of-2 multisig to solve this problem. The script challenge consists of something like OP_SHA256 OP_EQUAL. The idea behind the scheme is to make it verifiable to the public. Alice signs a BIP322 message from a UTXO and provides one of the signatures, Bob is forced to sign another BIP322 message from his address if he wants his money, and provides another signature. Both signatures are published on the blockchain. The signatures in the Multisig transaction prove who has control of which inputs, so it can be proven who paid who.A delegation scheme for privacy purposes has been proposed that utilizes multisig to make the possible delegatees known at signing time. This would replace the message challenge of "to_spend" with a 1-of-N standard P2WPKH multisig, where N is the number of people you want to be able to create the signature, and their respective pubkeys are included in the script. The possible delegatees are fixed at signature creation time and cannot be extended by creating more transactions. The challenge solution in "to_sign" is then replaced with a witness stack containing n ... 1 0. The signature is generated as if it were for a real P2WPKH-multisig transaction.The proposal has some advantages: no recursive transactions, address verification is provable, there is no opcode or new algorithm introduced, so no soft-fork is required, and signature fraud is still impossible to carry out. There is also a major privacy advantage in that only the delegatee who actually signs the message has a revealed public key, the others' are hidden. There are some disadvantages, such as everyone knows the public keys of the delegators, so there is no privacy. However, this is possibly a non-issue in light of the signature fraud problem. Additionally, Taproot is not widely deployed in applications yet.Moreover, some people have suggested writing this delegation scheme in TapScript, which could avoid revealing the unspent public keys. Single leaf k-of-n multisig is functionally identical to "Using a single OP_CHECKSIGADD-based script" described in BIP 0342, footnote 5, but it won't hide the non-signing public keys. That leaves multi-leaf k-of-k multisig, which swells as k increases, but for the purposes of delegation, K will always be 1, because we only utilize 1-n multisig signatures as per the previous message.This post discusses a proposal for BIP322 polishing, specifically regarding delegating signatures to other scriptPubKeys for privacy purposes. Instead of using a complicated transaction scheme, the proposal suggests using a multisig approach that makes possible delegatees known at signing time. The proposal outlines steps to replace the message challenge and challenge solution with a witness stack containing n...1 0, generating the signature as if it were for a real P2WPKH-multisig transaction. The pros of this approach are outlined, including no recursive transactions and provable address verification, while the con is that public keys of delegators are known, potentially compromising privacy. Input from others is requested, particularly from luke-jr who participated in the original Github discussion on delegation.A proposal has been made to solve the delegation problem in BIP322. This solution is built on Jeremy Rubin's transaction delegation post and allows a person to delegate signing to another person. This delegation can be useful for various purposes such as Lightning Network, CoinJoin, Mixers, and Silent Payments. The delegation works by signing a preliminary transaction with specific inputs and outputs. The signed message includes the Message, Address, and Signature. BIP322 specifies that the signature is just the raw transaction format of "to_sign". The address used can represent a kind of company; it can represent a channel, a coinjoin, or a silent payment. Bech32 is used to encode the "address" to make it look like a real address.The advantages of this scheme include privacy, arbitrary number of delegations, and delegated signatures can wrap Full and Full with UTXOs signing formats. There are no disadvantages to this scheme. The FAQ section clarifies how the delegation works, how to differentiate between non-delegated and delegated signatures, and how to verify a delegated BIP322 transaction if the address-hash is private. The proposal is cc'd to Kalle for consideration. 2022-08-22T07:56:12+00:00 + The message discusses an edge case that BIP322 only partially solves - Proof of Payment. In P2P transactions, there is always a risk that the other party will be dishonest and deny receiving payment. This type of dispute is rampant in cryptocurrencies as it can be used as a scam attempt to extract more money from the buyer. BIP322 signed messages can prove that the UTXO(s) belong to the buyer, but not *who* it was sent to.The proposal is to use P2WSH 2-of-2 multisig to solve this problem. The script challenge consists of something like OP_SHA256 OP_EQUAL. The idea behind the scheme is to make it verifiable to the public. Alice signs a BIP322 message from a UTXO and provides one of the signatures, Bob is forced to sign another BIP322 message from his address if he wants his money, and provides another signature. Both signatures are published on the blockchain. The signatures in the Multisig transaction prove who has control of which inputs, so it can be proven who paid who.A delegation scheme for privacy purposes has been proposed that utilizes multisig to make the possible delegatees known at signing time. This would replace the message challenge of "to_spend" with a 1-of-N standard P2WPKH multisig, where N is the number of people you want to be able to create the signature, and their respective pubkeys are included in the script. The possible delegatees are fixed at signature creation time and cannot be extended by creating more transactions. The challenge solution in "to_sign" is then replaced with a witness stack containing n ... 1 0. The signature is generated as if it were for a real P2WPKH-multisig transaction.The proposal has some advantages: no recursive transactions, address verification is provable, there is no opcode or new algorithm introduced, so no soft-fork is required, and signature fraud is still impossible to carry out. There is also a major privacy advantage in that only the delegatee who actually signs the message has a revealed public key, the others' are hidden. There are some disadvantages, such as everyone knows the public keys of the delegators, so there is no privacy. However, this is possibly a non-issue in light of the signature fraud problem. Additionally, Taproot is not widely deployed in applications yet.Moreover, some people have suggested writing this delegation scheme in TapScript, which could avoid revealing the unspent public keys. Single leaf k-of-n multisig is functionally identical to "Using a single OP_CHECKSIGADD-based script" described in BIP 0342, footnote 5, but it won't hide the non-signing public keys. That leaves multi-leaf k-of-k multisig, which swells as k increases, but for the purposes of delegation, K will always be 1, because we only utilize 1-n multisig signatures as per the previous message.This post discusses a proposal for BIP322 polishing, specifically regarding delegating signatures to other scriptPubKeys for privacy purposes. Instead of using a complicated transaction scheme, the proposal suggests using a multisig approach that makes possible delegatees known at signing time. The proposal outlines steps to replace the message challenge and challenge solution with a witness stack containing n...1 0, generating the signature as if it were for a real P2WPKH-multisig transaction. The pros of this approach are outlined, including no recursive transactions and provable address verification, while the con is that public keys of delegators are known, potentially compromising privacy. Input from others is requested, particularly from luke-jr who participated in the original Github discussion on delegation.A proposal has been made to solve the delegation problem in BIP322. This solution is built on Jeremy Rubin's transaction delegation post and allows a person to delegate signing to another person. This delegation can be useful for various purposes such as Lightning Network, CoinJoin, Mixers, and Silent Payments. The delegation works by signing a preliminary transaction with specific inputs and outputs. The signed message includes the Message, Address, and Signature. BIP322 specifies that the signature is just the raw transaction format of "to_sign". The address used can represent a kind of company; it can represent a channel, a coinjoin, or a silent payment. Bech32 is used to encode the "address" to make it look like a real address.The advantages of this scheme include privacy, arbitrary number of delegations, and delegated signatures can wrap Full and Full with UTXOs signing formats. There are no disadvantages to this scheme. The FAQ section clarifies how the delegation works, how to differentiate between non-delegated and delegated signatures, and how to verify a delegated BIP322 transaction if the address-hash is private. The proposal is cc'd to Kalle for consideration. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml index 52bbc02d9e..757f99d7c1 100644 --- a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml +++ b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2023-08-02T07:12:45.744421+00:00 + 2025-09-26T14:26:33.913889+00:00 + python-feedgen Dmitry Petukhov 2022-08-04 07:09:33+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2023-08-02T07:12:45.744421+00:00 + 2025-09-26T14:26:33.914059+00:00 - A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. The proposal uses tuples of 2022-08-04T07:09:33+00:00 + A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. The proposal uses tuples of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml index 66e991f8e4..de300f839c 100644 --- a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml +++ b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2023-08-02T07:20:37.832503+00:00 + 2025-09-26T14:26:23.216006+00:00 + python-feedgen Craig Raw 2022-09-26 08:23:18+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2023-08-02T07:20:37.833503+00:00 + 2025-09-26T14:26:23.216188+00:00 - The proposed standard aims to create a defined format for transferring labels that users have applied to transactions, addresses, inputs, or outputs in their wallets. The format uses the comma-separated values (CSV) format, which is widely supported. Each record in the CSV file consists of two fields: the reference to a transaction, address, input, or output, and the label applied to that reference. The proposal suggests using ZIP compression for the CSV file, with optional AES encryption.Some feedback on the proposal includes suggestions for improvements, such as adding a version byte to the header line, making the header line mandatory, and using an unsigned 32-bit integer for the second column. There are also suggestions to remove the optional encryption feature and not include input and output types in the export to avoid privacy leaks. Instead, commentators suggest adding a third column for item type identification.Despite disagreement on the use of CSV as a standard format, the goal of the proposal is to create a standardized format for importing and exporting wallet labels. The proposed format is a simple two-column CSV file, aiming to make label management more accessible to users and ensure compatibility between different wallet implementations. Feedback on the proposal is appreciated, and further improvements may be made based on the feedback received.The use of CSV for transferring labels between wallet applications is motivated by its wide accessibility and integration with existing processes and tools like Excel. However, there is some disagreement about using CSV, with suggestions to use JSON instead due to concerns about CSV compatibility and parsing effort. Despite this disagreement, the proposal aims to create a standard for importing and exporting labels from a wallet, regardless of the chosen data format.The proposal specifies a two-column CSV format, where the first column contains the reference to a transaction, address, input, or output, and the second column contains the label. The CSV file can be compressed using ZIP and optionally encrypted using AES. Importing applications may truncate labels if necessary, while exporting applications may omit records with no labels or labels of zero length.The proposal seeks to make label management accessible to users without technical expertise and reduce file size while ensuring compatibility. The discussion on the Bitcoin-dev mailing list provides insight into ongoing development work on the Bitcoin protocol and the collaborative nature of the Bitcoin development community.There is some disagreement about using CSV as the standard format for transferring labels, with suggestions to use JSON instead. One commenter suggests including descriptors in the format for advanced users. In response to a question about SLIP-0015, it is stated that SLIP-0015 has different design goals and limitations compared to the proposed BIP.The proposal allows for ZIP compression and optional AES encryption of the CSV file. The password for encryption should be the textual representation of the wallet's extended public key. The aim of this proposal is to create a standard for exporting and importing labels from a wallet, avoiding lock-in to a specific application, and making label management accessible to non-technical users.Feedback on the proposal is requested, and a reference implementation is yet to be determined. Suggestions for additions and changes to the format include adding a version byte, making the header line mandatory, requiring double quotes around the label, and writing a more robust importer algorithm. The proposal aims to standardize the export and import of labels using a simple CSV format. 2022-09-26T08:23:18+00:00 + The proposed standard aims to create a defined format for transferring labels that users have applied to transactions, addresses, inputs, or outputs in their wallets. The format uses the comma-separated values (CSV) format, which is widely supported. Each record in the CSV file consists of two fields: the reference to a transaction, address, input, or output, and the label applied to that reference. The proposal suggests using ZIP compression for the CSV file, with optional AES encryption.Some feedback on the proposal includes suggestions for improvements, such as adding a version byte to the header line, making the header line mandatory, and using an unsigned 32-bit integer for the second column. There are also suggestions to remove the optional encryption feature and not include input and output types in the export to avoid privacy leaks. Instead, commentators suggest adding a third column for item type identification.Despite disagreement on the use of CSV as a standard format, the goal of the proposal is to create a standardized format for importing and exporting wallet labels. The proposed format is a simple two-column CSV file, aiming to make label management more accessible to users and ensure compatibility between different wallet implementations. Feedback on the proposal is appreciated, and further improvements may be made based on the feedback received.The use of CSV for transferring labels between wallet applications is motivated by its wide accessibility and integration with existing processes and tools like Excel. However, there is some disagreement about using CSV, with suggestions to use JSON instead due to concerns about CSV compatibility and parsing effort. Despite this disagreement, the proposal aims to create a standard for importing and exporting labels from a wallet, regardless of the chosen data format.The proposal specifies a two-column CSV format, where the first column contains the reference to a transaction, address, input, or output, and the second column contains the label. The CSV file can be compressed using ZIP and optionally encrypted using AES. Importing applications may truncate labels if necessary, while exporting applications may omit records with no labels or labels of zero length.The proposal seeks to make label management accessible to users without technical expertise and reduce file size while ensuring compatibility. The discussion on the Bitcoin-dev mailing list provides insight into ongoing development work on the Bitcoin protocol and the collaborative nature of the Bitcoin development community.There is some disagreement about using CSV as the standard format for transferring labels, with suggestions to use JSON instead. One commenter suggests including descriptors in the format for advanced users. In response to a question about SLIP-0015, it is stated that SLIP-0015 has different design goals and limitations compared to the proposed BIP.The proposal allows for ZIP compression and optional AES encryption of the CSV file. The password for encryption should be the textual representation of the wallet's extended public key. The aim of this proposal is to create a standard for exporting and importing labels from a wallet, avoiding lock-in to a specific application, and making label management accessible to non-technical users.Feedback on the proposal is requested, and a reference implementation is yet to be determined. Suggestions for additions and changes to the format include adding a version byte, making the header line mandatory, requiring double quotes around the label, and writing a more robust importer algorithm. The proposal aims to standardize the export and import of labels using a simple CSV format. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_BIP-notatether-signedmessage.xml b/static/bitcoin-dev/Aug_2022/combined_BIP-notatether-signedmessage.xml index e1ba477563..cc3b13d4e3 100644 --- a/static/bitcoin-dev/Aug_2022/combined_BIP-notatether-signedmessage.xml +++ b/static/bitcoin-dev/Aug_2022/combined_BIP-notatether-signedmessage.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - BIP-notatether-signedmessage - 2023-08-02T07:14:47.143901+00:00 - - Ali Sherief 2022-08-05 10:52:41+00:00 - - - Pavol Rusnak 2022-08-05 09:12:20+00:00 - - - Ali Sherief 2022-08-05 07:39:38+00:00 - - - Luke Dashjr 2022-08-05 06:51:52+00:00 - - - Ali Sherief 2022-08-05 04:05:56+00:00 - - - Peter (Coinkite Inc) 2022-08-04 18:36:06+00:00 - - - Ali Sherief 2022-08-04 17:54:02+00:00 - - - Ali Sherief 2022-08-04 12:18:56+00:00 - + 2025-09-26T14:26:29.619274+00:00 + python-feedgen + + + [bitcoin-dev] BIP-notatether-signedmessage Ali Sherief + 2022-08-04T12:18:00.000Z + + + Ali Sherief + 2022-08-04T17:54:00.000Z + + + Peter (Coinkite Inc) + 2022-08-04T18:36:00.000Z + + + Ali Sherief + 2022-08-05T04:05:00.000Z + + + Luke Dashjr + 2022-08-05T06:51:00.000Z + + + Ali Sherief + 2022-08-05T07:39:00.000Z + + + Pavol Rusnak + 2022-08-05T09:12:00.000Z + + + Ali Sherief + 2022-08-05T10:52:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - BIP-notatether-signedmessage - 2023-08-02T07:14:47.143901+00:00 + 2025-09-26T14:26:29.620508+00:00 - Ali Sherief has created a new Bitcoin Improvement Proposal (BIP) called notatether-signedmessage. The BIP outlines a step-by-step process for signing and verifying messages from various types of Bitcoin addresses, including legacy, native/nested segwit, and taproot addresses. The BIP does not introduce a new signature format, except for the case of Taproot addresses. For Taproot addresses, a specific signature format is defined, consisting of a 1-byte header/recID, 64-byte signature, and 32-byte x-coordinate of a public key. This format is necessary to run the BIP340 Schnorr verify algorithm using only the signature. The BIP also integrates BIP137 signatures.Pavol Rusnak suggested that Ali should focus more on Taproot and position his BIP as strictly a "Taproot message signing BIP," rather than expanding on BIP137. Rusnak proposed that Ali move the algorithms and related content to the Bitcoin Wiki, leaving the BIP focused solely on Taproot. Ali plans to move the Taproot signature format to its own BIP in the future, as defining formats in an Informational BIP is considered unacceptable. Ultimately, Ali advocates for the adoption of BIP322, which he believes should have a user-friendly format similar to RFC2440.In another email conversation between Ali Sherief and Luke Dashjr, Ali proposes advancing a specific BIP before considering Taproot/Schnorr and two related extensions. The purpose of this BIP would be to provide a reference manual for correctly computing ECSDA sign/verify, addressing the issue of wallets not implementing sign/verify correctly due to the lack of a reference manual. However, Luke Dashjr expresses skepticism about the need for an additional message signing standard that does not address the problems with the current standard or BIP322, which, despite having superior message verification capabilities, is not widely used by wallets due to being a draft and incomplete.In an email sent on August 5th, 2022, Ali Sherief emphasizes the importance of advancing BIP322 as a priority. He acknowledges that BIP322 has superior message verification capabilities but notes that it is not currently used by wallets, likely due to its draft status and incompleteness. Ali likens BIP322 to a "bumper car" that enforces compliance with previous BIPs extending the message signing format, particularly BIP137. However, Luke Dashjr argues against the need for an additional message signing standard that does not address the existing problems.In response to a new BIP proposal by Ali Sherief for notatether-signedmessage, Luke Dashjr inquires about not helping Kalle with BIP322. Ali explains that while BIP322 may have superior message verification capabilities, it is not widely used by wallets, which rely on a mixture of legacy address sign/verify and nonstandard segwit sign/verify. Ali believes it is necessary to first establish a common ground for these different signing implementations before enforcing BIP322. He emphasizes the importance of ensuring widespread adoption of the proposed BIP for message signing and verification, along with implementing the legacy and segwit address components. Ali acknowledges that the Taproot signature format should be located in a newer Standards Track BIP that supersedes BIP137. Implementing this proposal will address only half of the existing problems, and the other half requires getting other wallet implementations to adopt the standard. He acknowledges that this task is non-trivial and suggests assigning a number to the BIP to facilitate progress. 2022-08-05T10:52:41+00:00 + Ali Sherief has created a new Bitcoin Improvement Proposal (BIP) called notatether-signedmessage. The BIP outlines a step-by-step process for signing and verifying messages from various types of Bitcoin addresses, including legacy, native/nested segwit, and taproot addresses. The BIP does not introduce a new signature format, except for the case of Taproot addresses. For Taproot addresses, a specific signature format is defined, consisting of a 1-byte header/recID, 64-byte signature, and 32-byte x-coordinate of a public key. This format is necessary to run the BIP340 Schnorr verify algorithm using only the signature. The BIP also integrates BIP137 signatures.Pavol Rusnak suggested that Ali should focus more on Taproot and position his BIP as strictly a "Taproot message signing BIP," rather than expanding on BIP137. Rusnak proposed that Ali move the algorithms and related content to the Bitcoin Wiki, leaving the BIP focused solely on Taproot. Ali plans to move the Taproot signature format to its own BIP in the future, as defining formats in an Informational BIP is considered unacceptable. Ultimately, Ali advocates for the adoption of BIP322, which he believes should have a user-friendly format similar to RFC2440.In another email conversation between Ali Sherief and Luke Dashjr, Ali proposes advancing a specific BIP before considering Taproot/Schnorr and two related extensions. The purpose of this BIP would be to provide a reference manual for correctly computing ECSDA sign/verify, addressing the issue of wallets not implementing sign/verify correctly due to the lack of a reference manual. However, Luke Dashjr expresses skepticism about the need for an additional message signing standard that does not address the problems with the current standard or BIP322, which, despite having superior message verification capabilities, is not widely used by wallets due to being a draft and incomplete.In an email sent on August 5th, 2022, Ali Sherief emphasizes the importance of advancing BIP322 as a priority. He acknowledges that BIP322 has superior message verification capabilities but notes that it is not currently used by wallets, likely due to its draft status and incompleteness. Ali likens BIP322 to a "bumper car" that enforces compliance with previous BIPs extending the message signing format, particularly BIP137. However, Luke Dashjr argues against the need for an additional message signing standard that does not address the existing problems.In response to a new BIP proposal by Ali Sherief for notatether-signedmessage, Luke Dashjr inquires about not helping Kalle with BIP322. Ali explains that while BIP322 may have superior message verification capabilities, it is not widely used by wallets, which rely on a mixture of legacy address sign/verify and nonstandard segwit sign/verify. Ali believes it is necessary to first establish a common ground for these different signing implementations before enforcing BIP322. He emphasizes the importance of ensuring widespread adoption of the proposed BIP for message signing and verification, along with implementing the legacy and segwit address components. Ali acknowledges that the Taproot signature format should be located in a newer Standards Track BIP that supersedes BIP137. Implementing this proposal will address only half of the existing problems, and the other half requires getting other wallet implementations to adopt the standard. He acknowledges that this task is non-trivial and suggests assigning a number to the BIP to facilitate progress. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml b/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml index ac60a80c05..86d8f7aa6c 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Huge wallets make Bitcoin Core unusable (Daemon+CLI & Qt) - 2023-08-02T07:19:07.652968+00:00 + 2025-09-26T14:26:27.506762+00:00 + python-feedgen Andrew Chow 2022-08-20 15:10:57+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Huge wallets make Bitcoin Core unusable (Daemon+CLI & Qt) - 2023-08-02T07:19:07.652968+00:00 + 2025-09-26T14:26:27.506895+00:00 - A developer named Felipe Micaroni Lalli raised two questions on the bitcoin-dev mailing list regarding the optimization of Bitcoin wallet module. The first question was about optimizing a large wallet without moving funds to a new one. In response, it was suggested to use removeprunedfunds RPC which can remove old transactions and speed up balance calculations and transaction creation. The second question was about improving cache usage by putting the entire wallet in memory. However, it was clarified that the wallet is already entirely in memory. The issue with the wallet module is a known one and changing it takes significant time as it is a large module in Bitcoin Core.A user named Felipe Micaroni Lalli posted on the bitcoin-dev forum about the issue he faced with a 5-year-old production server wallet, which had 2.079.337 transactions and 446.503 generated addresses and was around 273 MB in size. The wallet's performance started to degrade exponentially, with most commands timing out. Increasing the timeout and RPC threads in the config file worsened the situation. Even after moving the wallet.dat to a fast SSD disk and increasing cache size, performance wasn't sufficient. If loaded in Bitcoin-qt, the system became unresponsive, making it difficult to use. Felipe questioned if improvements could be made or if the wallet feature should be removed altogether.To run a large Bitcoin core wallet, just call `RemovePrunedFunds` on old transactions. However, it is tricky as one has to ensure that the transaction is "safe to remove." Transactions become unsafe if they have a wallet utxo that you haven't spent or recently spent. Additionally, if transaction B spends from transaction A, removing transaction B will make the wallet think transaction A is unspent when it is not. Thus, pruning should be done depth-first.Bitcoin Core becomes almost useless for the wallet feature since the standard client is slow to sync, hard to use, and not preferred by end-users who opt for Electrum or Wasabi. It also becomes useless for servers in production, forcing them to use third-party solutions for huge wallets. The only current "solution" for huge wallets is to create a new one and send the funds there from time to time, but it can cause privacy concerns and break monitoring of old addresses.Felipe suggested caching the entire wallet in memory, but some code optimization might also be necessary. He asked whether it was possible to optimize a huge wallet without moving funds to a new one, improving cache usage, reducing wallet size, ignoring old addresses, improving I/O treatment, and CPU usage in the main thread on Bitcoin-Qt to avoid window freezing on big and huge wallets. Felipe proposed an "autoarchivehugewallets=1" feature in the file config to create a new wallet and move funds automatically. Felipe included links to several related issues and tests that he thought could be useful for developers. He also mentioned another possible bug where even after moving funds to a new wallet, the old wallet shows an old balance. Rescanblockchain command takes a long time to fix it.A user with a 5-year-old wallet, containing 2.079.337 transactions, and 446.503 generated addresses, has experienced exponential performance degradation when using the Bitcoin Core client. Most of the commands, such as "getbalance", "walletpassphrase" and "getreceivedbyaddress", timed out, while the CPU was 100% used, making the machine almost unusable. The default configuration of 16 RPC threads and 15 min timeout and some attempt calls per mi did not help. Increasing the timeout and/or the RPC threads in the config file made things worse. Loading the wallet in the "bitcoin-qt" caused everything to become unresponsive, including the system (OS/UI).This is bad because the standard client becomes almost useless for the wallet feature. Wallet Qt is already unpopular among end-users, being slow to first sync, hard to use, and not modern. It becomes useless now also for servers in production, forcing them to use third-party solutions for huge wallets. Currently, the only "solution" for huge wallets is to create a new one and send the funds there from time to time. However, this solution is not elegant and can break old address monitoring, leading to privacy concerns and unifying lots of inputs in a big and expensive transaction. The issue could also potentially become an issue if we have LN nodes that use the Bitcoin Core wallet infrastructure behind to open/close many channels for a long time.The user suggests that if moving the wallet from an HDD to an SSD improved a lot, maybe caching the entire wallet in memory could improve even more, but some code optimization is necessary. The following questions were raised: Can we "optimize" a huge wallet without moving the funds to a new one? Can we improve the cache usage somehow? Is it possible to reduce the wallet size? Can we tell the CLI to ignore old addresses? 2022-08-20T15:10:57+00:00 + A developer named Felipe Micaroni Lalli raised two questions on the bitcoin-dev mailing list regarding the optimization of Bitcoin wallet module. The first question was about optimizing a large wallet without moving funds to a new one. In response, it was suggested to use removeprunedfunds RPC which can remove old transactions and speed up balance calculations and transaction creation. The second question was about improving cache usage by putting the entire wallet in memory. However, it was clarified that the wallet is already entirely in memory. The issue with the wallet module is a known one and changing it takes significant time as it is a large module in Bitcoin Core.A user named Felipe Micaroni Lalli posted on the bitcoin-dev forum about the issue he faced with a 5-year-old production server wallet, which had 2.079.337 transactions and 446.503 generated addresses and was around 273 MB in size. The wallet's performance started to degrade exponentially, with most commands timing out. Increasing the timeout and RPC threads in the config file worsened the situation. Even after moving the wallet.dat to a fast SSD disk and increasing cache size, performance wasn't sufficient. If loaded in Bitcoin-qt, the system became unresponsive, making it difficult to use. Felipe questioned if improvements could be made or if the wallet feature should be removed altogether.To run a large Bitcoin core wallet, just call `RemovePrunedFunds` on old transactions. However, it is tricky as one has to ensure that the transaction is "safe to remove." Transactions become unsafe if they have a wallet utxo that you haven't spent or recently spent. Additionally, if transaction B spends from transaction A, removing transaction B will make the wallet think transaction A is unspent when it is not. Thus, pruning should be done depth-first.Bitcoin Core becomes almost useless for the wallet feature since the standard client is slow to sync, hard to use, and not preferred by end-users who opt for Electrum or Wasabi. It also becomes useless for servers in production, forcing them to use third-party solutions for huge wallets. The only current "solution" for huge wallets is to create a new one and send the funds there from time to time, but it can cause privacy concerns and break monitoring of old addresses.Felipe suggested caching the entire wallet in memory, but some code optimization might also be necessary. He asked whether it was possible to optimize a huge wallet without moving funds to a new one, improving cache usage, reducing wallet size, ignoring old addresses, improving I/O treatment, and CPU usage in the main thread on Bitcoin-Qt to avoid window freezing on big and huge wallets. Felipe proposed an "autoarchivehugewallets=1" feature in the file config to create a new wallet and move funds automatically. Felipe included links to several related issues and tests that he thought could be useful for developers. He also mentioned another possible bug where even after moving funds to a new wallet, the old wallet shows an old balance. Rescanblockchain command takes a long time to fix it.A user with a 5-year-old wallet, containing 2.079.337 transactions, and 446.503 generated addresses, has experienced exponential performance degradation when using the Bitcoin Core client. Most of the commands, such as "getbalance", "walletpassphrase" and "getreceivedbyaddress", timed out, while the CPU was 100% used, making the machine almost unusable. The default configuration of 16 RPC threads and 15 min timeout and some attempt calls per mi did not help. Increasing the timeout and/or the RPC threads in the config file made things worse. Loading the wallet in the "bitcoin-qt" caused everything to become unresponsive, including the system (OS/UI).This is bad because the standard client becomes almost useless for the wallet feature. Wallet Qt is already unpopular among end-users, being slow to first sync, hard to use, and not modern. It becomes useless now also for servers in production, forcing them to use third-party solutions for huge wallets. Currently, the only "solution" for huge wallets is to create a new one and send the funds there from time to time. However, this solution is not elegant and can break old address monitoring, leading to privacy concerns and unifying lots of inputs in a big and expensive transaction. The issue could also potentially become an issue if we have LN nodes that use the Bitcoin Core wallet infrastructure behind to open/close many channels for a long time.The user suggests that if moving the wallet from an HDD to an SSD improved a lot, maybe caching the entire wallet in memory could improve even more, but some code optimization is necessary. The following questions were raised: Can we "optimize" a huge wallet without moving the funds to a new one? Can we improve the cache usage somehow? Is it possible to reduce the wallet size? Can we tell the CLI to ignore old addresses? - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml b/static/bitcoin-dev/Aug_2022/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml index 6a174a0cb6..34d059af85 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Mock introducing vulnerability in important Bitcoin projects - 2023-08-02T04:51:41.971421+00:00 - - Anthony Towns 2022-08-19 03:09:46+00:00 - - - Prayank 2021-11-18 20:29:24+00:00 - - - ZmnSCPxj 2021-10-04 03:59:34+00:00 - - - Luke Dashjr 2021-10-03 21:33:43+00:00 - - - Manuel Costa 2021-10-03 09:11:53+00:00 - - - Prayank 2021-10-02 09:19:37+00:00 - - - Ryan Grant 2021-10-01 20:15:56+00:00 - - - Prayank 2021-10-01 15:55:15+00:00 - - - ZmnSCPxj 2021-10-01 12:27:19+00:00 - - - Prayank 2021-10-01 03:03:00+00:00 - - - Ruben Somsen 2021-09-30 20:36:08+00:00 - - - Prayank 2021-09-27 23:19:40+00:00 - - - ZmnSCPxj 2021-09-27 10:13:02+00:00 - - - Prayank 2021-09-27 01:52:41+00:00 - + 2025-09-26T14:26:01.833845+00:00 + python-feedgen + + + [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects Prayank + 2021-09-27T01:52:00.000Z + + + ZmnSCPxj + 2021-09-27T10:13:00.000Z + + + Prayank + 2021-09-27T23:19:00.000Z + + + Ruben Somsen + 2021-09-30T20:36:00.000Z + + + Prayank + 2021-10-01T03:03:00.000Z + + + ZmnSCPxj + 2021-10-01T12:27:00.000Z + + + Prayank + 2021-10-01T15:55:00.000Z + + + Ryan Grant + 2021-10-01T20:15:00.000Z + + + Prayank + 2021-10-02T09:19:00.000Z + + + Manuel Costa + 2021-10-03T09:11:00.000Z + + + Luke Dashjr + 2021-10-03T21:33:00.000Z + + + ZmnSCPxj + 2021-10-04T03:59:00.000Z + + + Prayank + 2021-11-18T20:29:00.000Z + + + Anthony Towns + 2022-08-19T03:09:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Mock introducing vulnerability in important Bitcoin projects - 2023-08-02T04:51:41.971421+00:00 + 2025-09-26T14:26:01.835420+00:00 - In November 2021, Prayank announced an exercise to test the review process in three Bitcoin projects: Bitcoin Core, LND, and Bisq. They created a salted hash for the username and planned to create pull requests over the next six months. If vulnerabilities were caught during the review process, they would publicly announce them, but if not, they would privately reveal them later. However, after nine months, there has been no public report on the exercise, leaving it unclear whether any vulnerabilities have been introduced.The email conversation emphasizes the importance of regularly testing and verifying the review process in open-source Bitcoin projects. One participant suggests using commit messages with specific requirements to test the process against attacks. Another participant proposes that developers should be forced to opt-in to practice rounds of testing, as they cannot opt-out of potential real-world attacks. The email concludes by emphasizing the importance of independent thought during the review process.ZmnSCPxj suggests improving the review process to prevent attacks and waste contributors' time. They propose a scheme involving commit messages with specific requirements and the option for developers to opt-out of the study. However, they note that developers cannot opt out of potential NSA attacks.A discussion thread raises concerns about potential attempts to introduce vulnerabilities into Bitcoin Core codebase. Some proposals suggest a "Red Team exercise" to test the system's resilience. Others argue for improving the review process instead. The proposed exercise would involve public precommitments collected at ceremonial intervals, with community approval granted for the inserted security flaws.The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes are proposed, including a sortition system. The ideal process involves one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The process includes public precommitments and the use of block hashes as a random oracle.The post proposes a scheme to improve security in Bitcoin development using a sortition system. The scheme involves public precommitments collected at ceremonial intervals, with hash1 being a sortition ticket and hash2 being a public precommitment. The random oracle could be block hashes, and the red-team-concurrency difficulty parameter could control the selection process. The developer would have community approval to opportunistically insert a security flaw.The proposed exercise aims to improve the reputation factor and review attention for new pull requests. It suggests a secret sortition system to encourage more developers to participate without harming their reputation. The scheme includes public precommitments collected at ceremonial intervals and a red-team-concurrency difficulty parameter.The email exchange between Prayank and ZmnSCPxj discusses the importance of review processes in open-source Bitcoin projects. They agree on the necessity of reviews to catch vulnerabilities and caution against using unmerged PRs in production without careful review. Prayank proposes an exercise to test the review process by introducing vulnerability-adding PRs, while ZmnSCPxj emphasizes the need for private handling of any vulnerabilities found.The email discussion highlights the importance of review processes for ensuring security in Bitcoin development. The group agrees that relying on reviews is better for security and discusses the value of testing vulnerabilities in the review process. They propose a plan to create pseudonyms and introduce vulnerability-adding PRs to targets to test the review processes. The plan includes inserting random numbers among the commitments and publicly praising successful reviews.Prayank's proposal to conduct an exercise to study vulnerabilities in Bitcoin projects is met with caution. Ruben Somsen advises getting approval from contributors before proceeding to avoid causing mistrust and extra work for existing contributors. Prayank emphasizes reviewing pull requests based on code rather than author claims and asks whether trusting authors or having a good review process is better for security. They mention several Bitcoin projects they plan to test and note that x00 will assist them in the exercise.Prayank proposes an exercise to study vulnerabilities in Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating new GitHub accounts, studying issues in various Bitcoin projects, preparing pull requests to introduce vulnerabilities, and documenting the results. x00 will assist Prayank in this exercise, which has no fixed completion date.The email thread discusses introducing vulnerabilities in Bitcoin projects and observing how maintainers and reviewers respond. Ruben Somsen advises caution and suggests obtaining approval from contributors beforehand. ZmnSCPxj proposes a method using hash names and randomized salt as precommitments. They also highlight the potential impact on existing contributors and refer to a similar event in the Linux community.Prayank proposes an exercise to introduce vulnerabilities in Bitcoin projects and document the responses of maintainers and reviewers. They plan to create new GitHub accounts, study issues in various Bitcoin projects, and prepare pull requests to introduce vulnerabilities. They mention x00 as someone who will assist them in the exercise.In an email exchange, Prayank proposes an exercise to introduce vulnerabilities in various important Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating 2022-08-19T03:09:46+00:00 + In November 2021, Prayank announced an exercise to test the review process in three Bitcoin projects: Bitcoin Core, LND, and Bisq. They created a salted hash for the username and planned to create pull requests over the next six months. If vulnerabilities were caught during the review process, they would publicly announce them, but if not, they would privately reveal them later. However, after nine months, there has been no public report on the exercise, leaving it unclear whether any vulnerabilities have been introduced.The email conversation emphasizes the importance of regularly testing and verifying the review process in open-source Bitcoin projects. One participant suggests using commit messages with specific requirements to test the process against attacks. Another participant proposes that developers should be forced to opt-in to practice rounds of testing, as they cannot opt-out of potential real-world attacks. The email concludes by emphasizing the importance of independent thought during the review process.ZmnSCPxj suggests improving the review process to prevent attacks and waste contributors' time. They propose a scheme involving commit messages with specific requirements and the option for developers to opt-out of the study. However, they note that developers cannot opt out of potential NSA attacks.A discussion thread raises concerns about potential attempts to introduce vulnerabilities into Bitcoin Core codebase. Some proposals suggest a "Red Team exercise" to test the system's resilience. Others argue for improving the review process instead. The proposed exercise would involve public precommitments collected at ceremonial intervals, with community approval granted for the inserted security flaws.The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes are proposed, including a sortition system. The ideal process involves one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The process includes public precommitments and the use of block hashes as a random oracle.The post proposes a scheme to improve security in Bitcoin development using a sortition system. The scheme involves public precommitments collected at ceremonial intervals, with hash1 being a sortition ticket and hash2 being a public precommitment. The random oracle could be block hashes, and the red-team-concurrency difficulty parameter could control the selection process. The developer would have community approval to opportunistically insert a security flaw.The proposed exercise aims to improve the reputation factor and review attention for new pull requests. It suggests a secret sortition system to encourage more developers to participate without harming their reputation. The scheme includes public precommitments collected at ceremonial intervals and a red-team-concurrency difficulty parameter.The email exchange between Prayank and ZmnSCPxj discusses the importance of review processes in open-source Bitcoin projects. They agree on the necessity of reviews to catch vulnerabilities and caution against using unmerged PRs in production without careful review. Prayank proposes an exercise to test the review process by introducing vulnerability-adding PRs, while ZmnSCPxj emphasizes the need for private handling of any vulnerabilities found.The email discussion highlights the importance of review processes for ensuring security in Bitcoin development. The group agrees that relying on reviews is better for security and discusses the value of testing vulnerabilities in the review process. They propose a plan to create pseudonyms and introduce vulnerability-adding PRs to targets to test the review processes. The plan includes inserting random numbers among the commitments and publicly praising successful reviews.Prayank's proposal to conduct an exercise to study vulnerabilities in Bitcoin projects is met with caution. Ruben Somsen advises getting approval from contributors before proceeding to avoid causing mistrust and extra work for existing contributors. Prayank emphasizes reviewing pull requests based on code rather than author claims and asks whether trusting authors or having a good review process is better for security. They mention several Bitcoin projects they plan to test and note that x00 will assist them in the exercise.Prayank proposes an exercise to study vulnerabilities in Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating new GitHub accounts, studying issues in various Bitcoin projects, preparing pull requests to introduce vulnerabilities, and documenting the results. x00 will assist Prayank in this exercise, which has no fixed completion date.The email thread discusses introducing vulnerabilities in Bitcoin projects and observing how maintainers and reviewers respond. Ruben Somsen advises caution and suggests obtaining approval from contributors beforehand. ZmnSCPxj proposes a method using hash names and randomized salt as precommitments. They also highlight the potential impact on existing contributors and refer to a similar event in the Linux community.Prayank proposes an exercise to introduce vulnerabilities in Bitcoin projects and document the responses of maintainers and reviewers. They plan to create new GitHub accounts, study issues in various Bitcoin projects, and prepare pull requests to introduce vulnerabilities. They mention x00 as someone who will assist them in the exercise.In an email exchange, Prayank proposes an exercise to introduce vulnerabilities in various important Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_More-uses-for-CTV.xml b/static/bitcoin-dev/Aug_2022/combined_More-uses-for-CTV.xml index aba37621c5..a84c3a2c4d 100644 --- a/static/bitcoin-dev/Aug_2022/combined_More-uses-for-CTV.xml +++ b/static/bitcoin-dev/Aug_2022/combined_More-uses-for-CTV.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - More uses for CTV - 2023-08-02T07:17:28.431852+00:00 - - Antoine Riard 2022-09-19 01:22:43+00:00 - - - ZmnSCPxj 2022-08-20 03:03:52+00:00 - - - Jeremy Rubin 2022-08-19 21:01:25+00:00 - - - David A. Harding 2022-08-19 18:53:39+00:00 - - - Greg Sanders 2022-08-19 17:20:41+00:00 - - - James O'Beirne 2022-08-19 16:33:37+00:00 - + 2025-09-26T14:26:16.814884+00:00 + python-feedgen + + + [bitcoin-dev] More uses for CTV James O'Beirne + 2022-08-19T16:33:00.000Z + + + Greg Sanders + 2022-08-19T17:20:00.000Z + + + David A. Harding + 2022-08-19T18:53:00.000Z + + + Jeremy Rubin + 2022-08-19T21:01:00.000Z + + + ZmnSCPxj + 2022-08-20T03:03:00.000Z + + + Antoine Riard + 2022-09-19T01:22:00.000Z + + - python-feedgen + 2 Combined summary - More uses for CTV - 2023-08-02T07:17:28.431852+00:00 + 2025-09-26T14:26:16.815778+00:00 - The email thread and conversation on the bitcoin-dev mailing list revolve around the potential uses of OP_CHECKTEMPLATEVERIFY (CTV) in Bitcoin transactions. One use case discussed is congestion control, where CTV can be used to compress settlement commitments and facilitate later unpacking of the CTV outputs into the contract's true end state. This can help smooth fee rates and create a less spiky incentive to mine. Another potential application is atomic mining pool payouts, where a single OP_CTV output could pay out an arbitrary number of participants within a single coinbase. However, there are concerns raised about the design of atomic mining pool payouts, including weird dependencies between scriptpubkey, merkle root commitment, and CTV hash.The conversation also delves into L2 contracts and time-out based protocols, exploring the possibility of using layered commitments with OP_CTV to enable speedy settlement styles for these contracts. It is mentioned that predetermined sets of UTXOs in offchain cases can be implemented with a single UTXO that is an n-of-n multisignature or P2WSH revealing an OP_CTV.The advantages of Commitment Transaction Verification (CTV) compared to presigned transactions for trustless collaboration between multiple parties are discussed. While CTV is considered the most parsimonious way to settle into a single output, presigned transactions have their own benefits such as better privacy enhancement. In-script commitments using a non-secret point can reduce the amount of stored state and be deterministic. For large protocol trees, the savings can be substantial. The limitations of coinbase outputs and their impact on the number of participants in mining pools are also highlighted. Paying into batches of channels can compress payouts without a custodial relationship.A proposal is made to use SIGHASH_ALL | ANYONECANPAY to trustlessly collaborate and settle into a single CTV output, similar to coinjoins. The advantages of this method are discussed, but concerns are raised about compatibility with presigned transactions and the need for privacy upgrades to Lightning Network. The idea of using a single OP_CTV output for direct-from-coinbase payouts is also mentioned, but the size limitation on coinbase outputs restricts the number of participants in mining pools.James O'Beirne discusses the potential uses of CTV in Layer 2 protocols like payment channels and vaults. CTV can help compress settlement commitments and avoid protocol failures due to lack of block space. Direct-from-coinbase payouts are desirable for mining pools, but the size limitation on coinbase outputs limits the number of participants. CTV is seen as a simple concept and implementation that is likely to yield potential applications, especially with the possible increase in L2 usage.Overall, the discussions provide insights into the technicalities of implementing efficient L2 contracts, time-out based protocols, and congestion control using CTV. Various use cases and limitations are explored, with suggestions for alternative designs and improvements. The potential benefits of settlement compression and trustless collaboration are highlighted, while considering the implications for privacy and scalability. 2022-09-19T01:22:43+00:00 + The email thread and conversation on the bitcoin-dev mailing list revolve around the potential uses of OP_CHECKTEMPLATEVERIFY (CTV) in Bitcoin transactions. One use case discussed is congestion control, where CTV can be used to compress settlement commitments and facilitate later unpacking of the CTV outputs into the contract's true end state. This can help smooth fee rates and create a less spiky incentive to mine. Another potential application is atomic mining pool payouts, where a single OP_CTV output could pay out an arbitrary number of participants within a single coinbase. However, there are concerns raised about the design of atomic mining pool payouts, including weird dependencies between scriptpubkey, merkle root commitment, and CTV hash.The conversation also delves into L2 contracts and time-out based protocols, exploring the possibility of using layered commitments with OP_CTV to enable speedy settlement styles for these contracts. It is mentioned that predetermined sets of UTXOs in offchain cases can be implemented with a single UTXO that is an n-of-n multisignature or P2WSH revealing an OP_CTV.The advantages of Commitment Transaction Verification (CTV) compared to presigned transactions for trustless collaboration between multiple parties are discussed. While CTV is considered the most parsimonious way to settle into a single output, presigned transactions have their own benefits such as better privacy enhancement. In-script commitments using a non-secret point can reduce the amount of stored state and be deterministic. For large protocol trees, the savings can be substantial. The limitations of coinbase outputs and their impact on the number of participants in mining pools are also highlighted. Paying into batches of channels can compress payouts without a custodial relationship.A proposal is made to use SIGHASH_ALL | ANYONECANPAY to trustlessly collaborate and settle into a single CTV output, similar to coinjoins. The advantages of this method are discussed, but concerns are raised about compatibility with presigned transactions and the need for privacy upgrades to Lightning Network. The idea of using a single OP_CTV output for direct-from-coinbase payouts is also mentioned, but the size limitation on coinbase outputs restricts the number of participants in mining pools.James O'Beirne discusses the potential uses of CTV in Layer 2 protocols like payment channels and vaults. CTV can help compress settlement commitments and avoid protocol failures due to lack of block space. Direct-from-coinbase payouts are desirable for mining pools, but the size limitation on coinbase outputs limits the number of participants. CTV is seen as a simple concept and implementation that is likely to yield potential applications, especially with the possible increase in L2 usage.Overall, the discussions provide insights into the technicalities of implementing efficient L2 contracts, time-out based protocols, and congestion control using CTV. Various use cases and limitations are explored, with suggestions for alternative designs and improvements. The potential benefits of settlement compression and trustless collaboration are highlighted, while considering the implications for privacy and scalability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_New-BIP-Private-Payments.xml b/static/bitcoin-dev/Aug_2022/combined_New-BIP-Private-Payments.xml index cf05217d8c..d732a199fb 100644 --- a/static/bitcoin-dev/Aug_2022/combined_New-BIP-Private-Payments.xml +++ b/static/bitcoin-dev/Aug_2022/combined_New-BIP-Private-Payments.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - New BIP: Private Payments - 2023-08-02T07:14:07.713900+00:00 - - Alfred Hodler 2022-08-01 11:38:29+00:00 - - - Ruben Somsen 2022-07-30 13:41:36+00:00 - - - Alfred Hodler 2022-07-30 09:24:47+00:00 - + 2025-09-26T14:26:03.946835+00:00 + python-feedgen + + + [bitcoin-dev] New BIP: Private Payments Alfred Hodler + 2022-07-30T09:24:00.000Z + + + Ruben Somsen + 2022-07-30T13:41:00.000Z + + + Alfred Hodler + 2022-08-01T11:38:00.000Z + + - python-feedgen + 2 Combined summary - New BIP: Private Payments - 2023-08-02T07:14:07.713900+00:00 + 2025-09-26T14:26:03.947432+00:00 - In response to feedback from Ruben Somsen, Alfred Hodler has made several updates to his proposal for a new BIP that aims to enhance the privacy and future-proofing of two-party transactions. Ruben pointed out that the proposal introduces a scanning requirement to detect incoming notifications, which complicates light client implementation. He recommended that Alfred include this information in the BIP to ensure readers are aware of this downside.Ruben also noted that Alfred's proposal is similar to the BIP47 protocol improvement suggestions made in Prague, with the only difference being the addition of an extra ECDH calculation to hide the recipient payment code. This additional step leads to the scanning requirement, but allows users to broadcast notifications themselves instead of outsourcing them. Ruben suggested acknowledging this similarity and giving credit to the participants of the Prague discussion.Furthermore, Ruben advised Alfred to revisit the "Allowing collisions" paragraph from the Prague discussion, as it has the potential to reduce the size by up to 28 bytes. Despite these concerns, Ruben expressed support for Alfred's proposal and appreciated the effort put into working out details such as address formats.Alfred has taken Ruben's feedback into consideration and implemented some changes. He has incorporated Ruben's suggestion of using only the first four bytes of the notification code, as well as added Ruben as a co-author. Alfred explained that hiding the recipient in the notification not only allows Alice to send a notification herself, but also breaks the link between the notifier and Bob. This avoids social graph building issues and unique per-recipient notification addresses found in BIP47.However, light clients will need to rely on an OP_RETURN indexing service, which Alfred considers an acceptable inconvenience. This reliance reduces social metadata on the blockchain, prevents censorship of certain recipients by notification services, allows wallets to choose their level of outsourcing, and protects against attacks from adversaries monitoring notifications.Overall, Alfred's proposed BIP aims to enhance the privacy and future-proofing of two-party transactions. It builds upon the BIP47 protocol and offers increased privacy features. The proposal can be found on GitHub, and Alfred is seeking feedback to further refine it before it can be assigned a BIP number. Once the BIP is deemed viable, a reference implementation will be published. 2022-08-01T11:38:29+00:00 + In response to feedback from Ruben Somsen, Alfred Hodler has made several updates to his proposal for a new BIP that aims to enhance the privacy and future-proofing of two-party transactions. Ruben pointed out that the proposal introduces a scanning requirement to detect incoming notifications, which complicates light client implementation. He recommended that Alfred include this information in the BIP to ensure readers are aware of this downside.Ruben also noted that Alfred's proposal is similar to the BIP47 protocol improvement suggestions made in Prague, with the only difference being the addition of an extra ECDH calculation to hide the recipient payment code. This additional step leads to the scanning requirement, but allows users to broadcast notifications themselves instead of outsourcing them. Ruben suggested acknowledging this similarity and giving credit to the participants of the Prague discussion.Furthermore, Ruben advised Alfred to revisit the "Allowing collisions" paragraph from the Prague discussion, as it has the potential to reduce the size by up to 28 bytes. Despite these concerns, Ruben expressed support for Alfred's proposal and appreciated the effort put into working out details such as address formats.Alfred has taken Ruben's feedback into consideration and implemented some changes. He has incorporated Ruben's suggestion of using only the first four bytes of the notification code, as well as added Ruben as a co-author. Alfred explained that hiding the recipient in the notification not only allows Alice to send a notification herself, but also breaks the link between the notifier and Bob. This avoids social graph building issues and unique per-recipient notification addresses found in BIP47.However, light clients will need to rely on an OP_RETURN indexing service, which Alfred considers an acceptable inconvenience. This reliance reduces social metadata on the blockchain, prevents censorship of certain recipients by notification services, allows wallets to choose their level of outsourcing, and protects against attacks from adversaries monitoring notifications.Overall, Alfred's proposed BIP aims to enhance the privacy and future-proofing of two-party transactions. It builds upon the BIP47 protocol and offers increased privacy features. The proposal can be found on GitHub, and Alfred is seeking feedback to further refine it before it can be assigned a BIP number. Once the BIP is deemed viable, a reference implementation will be published. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml b/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml index be96d87301..b18d53f69e 100644 --- a/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml +++ b/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New Silent Payment version - 2023-08-02T07:17:05.138403+00:00 + 2025-09-26T14:26:08.214181+00:00 + python-feedgen Ali Sherief 2022-08-22 12:55:58+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - New Silent Payment version - 2023-08-02T07:17:05.138403+00:00 + 2025-09-26T14:26:08.214364+00:00 - A new version of Bitcoin's Silent Payment implementation has been introduced through a Pull Request update (PR #24897) on the Bitcoin codebase on GitHub. This updated version improves upon the previous implementation by eliminating manual steps and introducing a new descriptor type called "sp()". This descriptor type contains exactly one key and generates a unique 'silent-payment' address.The silent payment address can be used as one of the outputs in a transaction, alongside standard addresses. The "send" RPC automatically identifies and tweaks the silent payment address. The output generated is a standard Taproot script with HRP changed from "bc" to "sp" on the mainnet or "tsp" on testnet and signet.It is important to note that the introduction of silent payments does not affect the consensus or auditability rules. These silent transactions are still included in publicly auditable blocks. The only difference is that the addresses cannot be hierarchically derived with BIP44 or any other path.Some critics have expressed concerns about the auditability of these transactions. However, Ali, the developer behind this update, explains that the silent payments are still publicly auditable and adhere to the original consensus that gave Bitcoin fungibility. Despite this explanation, some critics remain skeptical.To facilitate the review process, a step-by-step signet tutorial has been created for testers to easily test this new version. Overall, this updated version of Bitcoin's Silent Payment implementation simplifies the process of making silent payments, making it easier and more efficient for users. 2022-08-22T12:55:58+00:00 + A new version of Bitcoin's Silent Payment implementation has been introduced through a Pull Request update (PR #24897) on the Bitcoin codebase on GitHub. This updated version improves upon the previous implementation by eliminating manual steps and introducing a new descriptor type called "sp()". This descriptor type contains exactly one key and generates a unique 'silent-payment' address.The silent payment address can be used as one of the outputs in a transaction, alongside standard addresses. The "send" RPC automatically identifies and tweaks the silent payment address. The output generated is a standard Taproot script with HRP changed from "bc" to "sp" on the mainnet or "tsp" on testnet and signet.It is important to note that the introduction of silent payments does not affect the consensus or auditability rules. These silent transactions are still included in publicly auditable blocks. The only difference is that the addresses cannot be hierarchically derived with BIP44 or any other path.Some critics have expressed concerns about the auditability of these transactions. However, Ali, the developer behind this update, explains that the silent payments are still publicly auditable and adhere to the original consensus that gave Bitcoin fungibility. Despite this explanation, some critics remain skeptical.To facilitate the review process, a step-by-step signet tutorial has been created for testers to easily test this new version. Overall, this updated version of Bitcoin's Silent Payment implementation simplifies the process of making silent payments, making it easier and more efficient for users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 140fe3148d..6d664cbb70 100644 --- a/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On a new community process to specify covenants - 2023-08-02T07:05:21.717413+00:00 + 2025-09-26T14:26:14.700951+00:00 + python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - On a new community process to specify covenants - 2023-08-02T07:05:21.718414+00:00 + 2025-09-26T14:26:14.701147+00:00 - The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest 2022-10-07T15:33:12+00:00 + The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_P2P-trading-replacement-transactions.xml b/static/bitcoin-dev/Aug_2022/combined_P2P-trading-replacement-transactions.xml index ef9cff688f..e48ad175d9 100644 --- a/static/bitcoin-dev/Aug_2022/combined_P2P-trading-replacement-transactions.xml +++ b/static/bitcoin-dev/Aug_2022/combined_P2P-trading-replacement-transactions.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - P2P trading replacement transactions - 2023-08-02T07:15:43.350522+00:00 - - alicexbt 2022-08-08 13:12:44+00:00 - - - Ali Sherief 2022-08-06 14:16:08+00:00 - - - alicexbt 2022-08-06 14:11:34+00:00 - - - Michael Folkson 2022-08-06 12:55:49+00:00 - - - alicexbt 2022-08-05 14:44:52+00:00 - + 2025-09-26T14:26:21.069783+00:00 + python-feedgen + + + [bitcoin-dev] P2P trading replacement transactions alicexbt + 2022-08-05T14:44:00.000Z + + + Michael Folkson + 2022-08-06T12:55:00.000Z + + + alicexbt + 2022-08-06T14:11:00.000Z + + + Ali Sherief + 2022-08-06T14:16:00.000Z + + + alicexbt + 2022-08-08T13:12:00.000Z + + - python-feedgen + 2 Combined summary - P2P trading replacement transactions - 2023-08-02T07:15:43.350522+00:00 + 2025-09-26T14:26:21.070530+00:00 - The email thread discusses the idea of trading replacement transactions for privacy. Alice and Bob can share outputs, which are swapped in the replacement transactions. A 2of3 multisig with Carol is required to prevent cheating. Trading of private keys is not required, and PGP is not needed to share them securely. The process is similar to an HTLC, but with the addition of trading private keys for actual trades. Taproot may be used to selectively reveal certain script branches, but details are unclear.The proposed implementation involves creating an API managed by Carol, using a 2of3 multisig with Alice, Bob, and Carol's keys. Alice and Bob create orders for replacement, either matched automatically or accepted manually by Bob. Bob locks 0.01 BTC in the multisig and shares outputs e2 and f2 with Alice. Alice signs tx2 and shares it with Bob. Alice locks 0.011 BTC in the multisig and shares outputs b2 and c2 with Bob. Bob signs tx2 and shares it with Alice. Both replacement transactions can be broadcasted, and funds are released from the multisig with a transaction having three outputs, with one output paying the fee which goes to Carol.The positives of this process are privacy, while the negatives include extra fees and time taken to manage everything with the API provided by Carol. It requires locking bitcoin with the same amount as used in tx1, and amounts could still be used to link transactions in some cases.The email thread discusses the concept of trading replacement transactions for privacy. The goal is to break the assumption that a replacement transaction is done only to use a higher fee rate with the same sender and recipient. This method offers an extra privacy option, and if the user selects it, everything happens in the background. The UX will be simple, and the user just needs to approve in between. This scheme aims to provide different levels of privacy from coinjoin and coinswap methods. However, the protocol's additional complexity raises questions about whether this is worth it.A two-party coinjoin can get you an output where it isn't clear to blockchain observers which output you control, and coinswap has you taking the coin history of your counterparty. The proposed method involves creating an API to manage trades that will use 2 of 3 multisig. Alice and Bob create orders for replacement, and they could be matched automatically using some algorithm or Bob manually accepts the offer. Two of three multisig is created with Alice, Bob, and Carol keys. Bob locks 0.01 BTC in it and shares outputs e2, f2 with Alice. Alice signs tx2 and shares the transaction with Bob. Alice locks 0.011 BTC in it and shares outputs b2, c2 with Bob. Bob signs tx2 and shares it with Alice. Both replacement transactions can be broadcasted, and funds are released from 2 of 3 multisig with a transaction having three outputs (one to pay fee which goes to Carol).Although this method would improve privacy, there are negatives like extra fees, time consumption, knowing details by Carol and other peers, and need to lock bitcoin with the same amount as used in tx1. However, if this method makes sense or a similar market to trade replacements in the future, it could help create a process in which a chain of replacements happens before Bitcoin reaches the destination, similar to a tor circuit.In a message to Bitcoin Developers, a user named 'alicexbt' asked whether it makes sense to trade replacement transactions for privacy. They shared basic details on how this could be done and requested opinions or suggestions for improvement. Another user named Michael replied, stating that he was struggling to understand the purpose of this scheme in terms of privacy, especially considering the added protocol complexity. He stated that a 2-party coinjoin or coinswap could offer similar privacy benefits without the extra complexity.Alicexbt's proposal involved creating an API managed by a third party named Carol, which would enable trades using a 2-of-3 multisig setup. Alice and Bob would create orders for replacement transactions, which would involve swapping outputs with a counterparty. The matching process could either be automated or done manually by Bob. Both parties would lock their bitcoin and share outputs with each other, before signing the transaction and broadcasting it. The positives of this scheme were increased privacy, while the negatives included extra fees, time, and the need to lock bitcoin with the same amount used in the initial transaction.The email is addressed to Bitcoin developers and discusses the concept of trading replacement transactions for privacy. The email includes a proposal by Alice to implement this idea, which involves creating two transactions (tx1 and tx2) with specific inputs and outputs. Bob also has his own set of transactions, and Carol creates an API to manage trades using a 2 of 3 multisig system. Alice and Bob create orders for replacement, which could be matched automatically using some algorithm or manually accepted by 2022-08-08T13:12:44+00:00 + The email thread discusses the idea of trading replacement transactions for privacy. Alice and Bob can share outputs, which are swapped in the replacement transactions. A 2of3 multisig with Carol is required to prevent cheating. Trading of private keys is not required, and PGP is not needed to share them securely. The process is similar to an HTLC, but with the addition of trading private keys for actual trades. Taproot may be used to selectively reveal certain script branches, but details are unclear.The proposed implementation involves creating an API managed by Carol, using a 2of3 multisig with Alice, Bob, and Carol's keys. Alice and Bob create orders for replacement, either matched automatically or accepted manually by Bob. Bob locks 0.01 BTC in the multisig and shares outputs e2 and f2 with Alice. Alice signs tx2 and shares it with Bob. Alice locks 0.011 BTC in the multisig and shares outputs b2 and c2 with Bob. Bob signs tx2 and shares it with Alice. Both replacement transactions can be broadcasted, and funds are released from the multisig with a transaction having three outputs, with one output paying the fee which goes to Carol.The positives of this process are privacy, while the negatives include extra fees and time taken to manage everything with the API provided by Carol. It requires locking bitcoin with the same amount as used in tx1, and amounts could still be used to link transactions in some cases.The email thread discusses the concept of trading replacement transactions for privacy. The goal is to break the assumption that a replacement transaction is done only to use a higher fee rate with the same sender and recipient. This method offers an extra privacy option, and if the user selects it, everything happens in the background. The UX will be simple, and the user just needs to approve in between. This scheme aims to provide different levels of privacy from coinjoin and coinswap methods. However, the protocol's additional complexity raises questions about whether this is worth it.A two-party coinjoin can get you an output where it isn't clear to blockchain observers which output you control, and coinswap has you taking the coin history of your counterparty. The proposed method involves creating an API to manage trades that will use 2 of 3 multisig. Alice and Bob create orders for replacement, and they could be matched automatically using some algorithm or Bob manually accepts the offer. Two of three multisig is created with Alice, Bob, and Carol keys. Bob locks 0.01 BTC in it and shares outputs e2, f2 with Alice. Alice signs tx2 and shares the transaction with Bob. Alice locks 0.011 BTC in it and shares outputs b2, c2 with Bob. Bob signs tx2 and shares it with Alice. Both replacement transactions can be broadcasted, and funds are released from 2 of 3 multisig with a transaction having three outputs (one to pay fee which goes to Carol).Although this method would improve privacy, there are negatives like extra fees, time consumption, knowing details by Carol and other peers, and need to lock bitcoin with the same amount as used in tx1. However, if this method makes sense or a similar market to trade replacements in the future, it could help create a process in which a chain of replacements happens before Bitcoin reaches the destination, similar to a tor circuit.In a message to Bitcoin Developers, a user named 'alicexbt' asked whether it makes sense to trade replacement transactions for privacy. They shared basic details on how this could be done and requested opinions or suggestions for improvement. Another user named Michael replied, stating that he was struggling to understand the purpose of this scheme in terms of privacy, especially considering the added protocol complexity. He stated that a 2-party coinjoin or coinswap could offer similar privacy benefits without the extra complexity.Alicexbt's proposal involved creating an API managed by a third party named Carol, which would enable trades using a 2-of-3 multisig setup. Alice and Bob would create orders for replacement transactions, which would involve swapping outputs with a counterparty. The matching process could either be automated or done manually by Bob. Both parties would lock their bitcoin and share outputs with each other, before signing the transaction and broadcasting it. The positives of this scheme were increased privacy, while the negatives included extra fees, time, and the need to lock bitcoin with the same amount used in the initial transaction.The email is addressed to Bitcoin developers and discusses the concept of trading replacement transactions for privacy. The email includes a proposal by Alice to implement this idea, which involves creating two transactions (tx1 and tx2) with specific inputs and outputs. Bob also has his own set of transactions, and Carol creates an API to manage trades using a 2 of 3 multisig system. Alice and Bob create orders for replacement, which could be matched automatically using some algorithm or manually accepted by - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml b/static/bitcoin-dev/Aug_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml index 3d26322659..e1a6b1397e 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml @@ -1,89 +1,119 @@ - + 2 Combined summary - Playing with full-rbf peers for fun and L2s security - 2023-08-02T06:48:58.631630+00:00 - - Antoine Riard 2022-08-24 01:56:14+00:00 - - - Antoine Riard 2022-07-09 15:06:43+00:00 - - - alicexbt 2022-07-08 19:44:24+00:00 - - - Greg Sanders 2022-07-08 15:09:33+00:00 - - - Peter Todd 2022-07-08 14:53:13+00:00 - - - alicexbt 2022-07-05 20:46:51+00:00 - - - Peter Todd 2022-06-27 13:46:46+00:00 - - - Greg Sanders 2022-06-27 12:03:38+00:00 - - - Peter Todd 2022-06-27 00:43:35+00:00 - - - alicexbt 2022-06-26 16:40:24+00:00 - - - Peter Todd 2022-06-23 19:13:47+00:00 - - - Antoine Riard 2022-06-21 23:45:48+00:00 - - - Antoine Riard 2022-06-21 23:43:23+00:00 - - - Peter Todd 2022-06-20 23:49:55+00:00 - - - Peter Todd 2022-06-19 10:42:15+00:00 - - - alicexbt 2022-06-17 04:54:11+00:00 - - - Antoine Riard 2022-06-17 01:34:17+00:00 - - - Greg Sanders 2022-06-16 13:24:03+00:00 - - - alicexbt 2022-06-16 12:47:15+00:00 - - - linuxfoundation.cndm1 at dralias.com 2022-06-16 05:43:33+00:00 - - - alicexbt 2022-06-16 01:45:42+00:00 - - - Greg Sanders 2022-06-16 01:02:39+00:00 - - - alicexbt 2022-06-16 00:16:52+00:00 - - - Peter Todd 2022-06-15 03:18:33+00:00 - - - Luke Dashjr 2022-06-15 02:53:58+00:00 - - - Peter Todd 2022-06-15 02:27:20+00:00 - - - Antoine Riard 2022-06-14 00:25:11+00:00 - + 2025-09-26T14:26:12.551810+00:00 + python-feedgen + + + [bitcoin-dev] Playing with full-rbf peers for fun and L2s security Antoine Riard + 2022-06-14T00:25:00.000Z + + + Peter Todd + 2022-06-15T02:27:00.000Z + + + Luke Dashjr + 2022-06-15T02:53:00.000Z + + + Peter Todd + 2022-06-15T03:18:00.000Z + + + alicexbt + 2022-06-16T00:16:00.000Z + + + Greg Sanders + 2022-06-16T01:02:00.000Z + + + alicexbt + 2022-06-16T01:45:00.000Z + + + linuxfoundation.cndm1 + 2022-06-16T05:43:00.000Z + + + alicexbt + 2022-06-16T12:47:00.000Z + + + Greg Sanders + 2022-06-16T13:24:00.000Z + + + Antoine Riard + 2022-06-17T01:34:00.000Z + + + alicexbt + 2022-06-17T04:54:00.000Z + + + Peter Todd + 2022-06-19T10:42:00.000Z + + + Peter Todd + 2022-06-20T23:49:00.000Z + + + Antoine Riard + 2022-06-21T23:43:00.000Z + + + Antoine Riard + 2022-06-21T23:45:00.000Z + + + Peter Todd + 2022-06-23T19:13:00.000Z + + + alicexbt + 2022-06-26T16:40:00.000Z + + + Peter Todd + 2022-06-27T00:43:00.000Z + + + Greg Sanders + 2022-06-27T12:03:00.000Z + + + Peter Todd + 2022-06-27T13:46:00.000Z + + + alicexbt + 2022-07-05T20:46:00.000Z + + + Peter Todd + 2022-07-08T14:53:00.000Z + + + Greg Sanders + 2022-07-08T15:09:00.000Z + + + alicexbt + 2022-07-08T19:44:00.000Z + + + Antoine Riard + 2022-07-09T15:06:00.000Z + + + Antoine Riard + 2022-08-24T01:56:00.000Z + + @@ -111,13 +141,13 @@ - python-feedgen + 2 Combined summary - Playing with full-rbf peers for fun and L2s security - 2023-08-02T06:48:58.631630+00:00 + 2025-09-26T14:26:12.554937+00:00 - The conversation discussed the vulnerability of open, p2p coinjoin services to DoS attacks. It was noted that attackers can disrupt rounds by failing to complete them or launching double-spend attacks. Mitigating these types of attacks is crucial to prevent malicious coinjoin service providers from outlawing competition. Punishing attackers in the case of failed relay transactions during coinjoin rounds is also challenging. The implementation of full-rbf as a policy in Bitcoin Core was proposed as a potential solution to improve the security and reliability of multi-party funded transactions. However, there are ongoing discussions and disagreements regarding the approach and its impact.Another proposal shared on GitHub aims to enable trustless DLCs on Bitcoin using dual-funded channels with Lightning Network-style HTLCs. This would provide a more secure and scalable solution for off-chain contracts. Antoine Riard suggests that users should be able to manage their LN usage by using better ISPs or adopting different mempool policies. Documentation was highlighted as important in helping users understand and navigate the complexities of RBF policies and mempool DoS vectors. Community engagement and collaboration are emphasized as necessary to advance the state of policy options in Bitcoin Core.The Lightning dual-funded channel proposal aims to increase the efficiency and usability of the Lightning network by allowing users to easily create secure and decentralized channels. The fund allocation and transaction signing process is outlined in the proposal. It has been shared on the bitcoin-dev mailing list where developers discuss technical aspects of Bitcoin.There have been discussions about the lack of basic options in Bitcoin Core for enabling/disabling different RBF policies. The implementation of full-RBF in Bitcoin Core is questioned, and the author suggests providing basic RBF policy options instead of removing the ability to disable certain policies. Antoine Riard proposes fixing the security vulnerabilities in multi-party funded transactions by enabling full-RBF as a policy in Bitcoin Core. He has submitted a patch for review and invites node operators to test full-RBF. Concerns about the impact of full-RBF on vulnerable projects and the lack of consensus among nodes and miners are raised. Some suggest using alternative implementations like Bitcoin Knots, which already has an option to disable all RBF policies. However, proponents argue that full-RBF is a simple and incentive-compatible step towards more robust layer two systems. Peter Todd suggests a similar approach to full-RBF but notes that he hasn't worked on the Bitcoin Core codebase in years.In summary, ongoing discussions revolve around the implementation of full-RBF in Bitcoin Core and its impact on multi-party funded transactions. The Lightning dual-funded channel proposal aims to improve the efficiency and usability of the Lightning network. Developers are encouraged to provide basic RBF policy options, and alternative implementations like Bitcoin Knots already offer these options. Node operators and mining operators can experiment with full-RBF to test its benefits and drawbacks. 2022-08-24T01:56:14+00:00 + The conversation discussed the vulnerability of open, p2p coinjoin services to DoS attacks. It was noted that attackers can disrupt rounds by failing to complete them or launching double-spend attacks. Mitigating these types of attacks is crucial to prevent malicious coinjoin service providers from outlawing competition. Punishing attackers in the case of failed relay transactions during coinjoin rounds is also challenging. The implementation of full-rbf as a policy in Bitcoin Core was proposed as a potential solution to improve the security and reliability of multi-party funded transactions. However, there are ongoing discussions and disagreements regarding the approach and its impact.Another proposal shared on GitHub aims to enable trustless DLCs on Bitcoin using dual-funded channels with Lightning Network-style HTLCs. This would provide a more secure and scalable solution for off-chain contracts. Antoine Riard suggests that users should be able to manage their LN usage by using better ISPs or adopting different mempool policies. Documentation was highlighted as important in helping users understand and navigate the complexities of RBF policies and mempool DoS vectors. Community engagement and collaboration are emphasized as necessary to advance the state of policy options in Bitcoin Core.The Lightning dual-funded channel proposal aims to increase the efficiency and usability of the Lightning network by allowing users to easily create secure and decentralized channels. The fund allocation and transaction signing process is outlined in the proposal. It has been shared on the bitcoin-dev mailing list where developers discuss technical aspects of Bitcoin.There have been discussions about the lack of basic options in Bitcoin Core for enabling/disabling different RBF policies. The implementation of full-RBF in Bitcoin Core is questioned, and the author suggests providing basic RBF policy options instead of removing the ability to disable certain policies. Antoine Riard proposes fixing the security vulnerabilities in multi-party funded transactions by enabling full-RBF as a policy in Bitcoin Core. He has submitted a patch for review and invites node operators to test full-RBF. Concerns about the impact of full-RBF on vulnerable projects and the lack of consensus among nodes and miners are raised. Some suggest using alternative implementations like Bitcoin Knots, which already has an option to disable all RBF policies. However, proponents argue that full-RBF is a simple and incentive-compatible step towards more robust layer two systems. Peter Todd suggests a similar approach to full-RBF but notes that he hasn't worked on the Bitcoin Core codebase in years.In summary, ongoing discussions revolve around the implementation of full-RBF in Bitcoin Core and its impact on multi-party funded transactions. The Lightning dual-funded channel proposal aims to improve the efficiency and usability of the Lightning network. Developers are encouraged to provide basic RBF policy options, and alternative implementations like Bitcoin Knots already offer these options. Node operators and mining operators can experiment with full-RBF to test its benefits and drawbacks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_RBF-rules-setting-policy-defaults-in-Bitcoin-Core-and-the-role-of-BIPs.xml b/static/bitcoin-dev/Aug_2022/combined_RBF-rules-setting-policy-defaults-in-Bitcoin-Core-and-the-role-of-BIPs.xml index bd1963c975..e3c8a500a8 100644 --- a/static/bitcoin-dev/Aug_2022/combined_RBF-rules-setting-policy-defaults-in-Bitcoin-Core-and-the-role-of-BIPs.xml +++ b/static/bitcoin-dev/Aug_2022/combined_RBF-rules-setting-policy-defaults-in-Bitcoin-Core-and-the-role-of-BIPs.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs - 2023-08-02T07:15:04.672456+00:00 - - Michael Folkson 2022-08-04 21:47:08+00:00 - - - Luke Dashjr 2022-08-04 19:35:13+00:00 - - - Peter Todd 2022-08-04 18:06:34+00:00 - - - Michael Folkson 2022-08-04 14:54:54+00:00 - + 2025-09-26T14:26:38.146805+00:00 + python-feedgen + + + [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs Michael Folkson + 2022-08-04T14:54:00.000Z + + + Peter Todd + 2022-08-04T18:06:00.000Z + + + Luke Dashjr + 2022-08-04T19:35:00.000Z + + + Michael Folkson + 2022-08-04T21:47:00.000Z + + - python-feedgen + 2 Combined summary - RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs - 2023-08-02T07:15:04.672456+00:00 + 2025-09-26T14:26:38.147413+00:00 - In a post on the Bitcoin development mailing list, Michael Folkson discusses the history of BIP125 and the implementation of Replace-by-Fee (RBF) rules in Bitcoin Core. BIP125 serves as a means for wallets and nodes to communicate and aims to standardize communication within the ecosystem. While BIP125 has been widely implemented, any changes should only be made to correct errors that deviate from the original intent. It is crucial not to rely on assumptions of node policies for security purposes.The introduction of RBF rules into Bitcoin Core occurred in November 2015, followed by the drafting of BIP125 by David Harding and Peter Todd. However, a discrepancy was discovered in May 2021, revealing that the RBF rules implemented in Bitcoin Core did not align with those outlined in BIP125. This revelation has sparked two perspectives on how to address the issue. One viewpoint suggests abandoning the idea of a specification for RBF rules and solely documenting them in the Core repository. The other perspective advocates for creating a new specification that accurately outlines the RBF rules implemented in Bitcoin Core and provides detailed rationales for these rules.Folkson emphasizes that while policy is generally less risky than consensus, L2 protocol security heavily relies on policy. Therefore, striving for similar standards in policy as in consensus changes is crucial. Documentation is typically done post-merge, but for consensus PRs, having simultaneous release of two points of reference is considered a high standard. As time passes and the ecosystem evolves, it is essential to continually improve and maintain higher standards than those established in 2015.The new RBF rules implemented in Bitcoin Core are currently documented in the Core repository. The developers responsible for policy decisions will have better insight into whether these rules will continue to be iterated upon based on new research on L2 security or if a finalized static set of RBF rules is imminent. In conclusion, maintaining the highest possible standards for step change default policy changes in Bitcoin Core is crucial for the security of L2 protocols. 2022-08-04T21:47:08+00:00 + In a post on the Bitcoin development mailing list, Michael Folkson discusses the history of BIP125 and the implementation of Replace-by-Fee (RBF) rules in Bitcoin Core. BIP125 serves as a means for wallets and nodes to communicate and aims to standardize communication within the ecosystem. While BIP125 has been widely implemented, any changes should only be made to correct errors that deviate from the original intent. It is crucial not to rely on assumptions of node policies for security purposes.The introduction of RBF rules into Bitcoin Core occurred in November 2015, followed by the drafting of BIP125 by David Harding and Peter Todd. However, a discrepancy was discovered in May 2021, revealing that the RBF rules implemented in Bitcoin Core did not align with those outlined in BIP125. This revelation has sparked two perspectives on how to address the issue. One viewpoint suggests abandoning the idea of a specification for RBF rules and solely documenting them in the Core repository. The other perspective advocates for creating a new specification that accurately outlines the RBF rules implemented in Bitcoin Core and provides detailed rationales for these rules.Folkson emphasizes that while policy is generally less risky than consensus, L2 protocol security heavily relies on policy. Therefore, striving for similar standards in policy as in consensus changes is crucial. Documentation is typically done post-merge, but for consensus PRs, having simultaneous release of two points of reference is considered a high standard. As time passes and the ecosystem evolves, it is essential to continually improve and maintain higher standards than those established in 2015.The new RBF rules implemented in Bitcoin Core are currently documented in the Core repository. The developers responsible for policy decisions will have better insight into whether these rules will continue to be iterated upon based on new research on L2 security or if a finalized static set of RBF rules is imminent. In conclusion, maintaining the highest possible standards for step change default policy changes in Bitcoin Core is crucial for the security of L2 protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_RIDDLE-Lightweight-anti-Sybil-with-anonymity-in-Bitcoin.xml b/static/bitcoin-dev/Aug_2022/combined_RIDDLE-Lightweight-anti-Sybil-with-anonymity-in-Bitcoin.xml index a563dac288..baf4992e49 100644 --- a/static/bitcoin-dev/Aug_2022/combined_RIDDLE-Lightweight-anti-Sybil-with-anonymity-in-Bitcoin.xml +++ b/static/bitcoin-dev/Aug_2022/combined_RIDDLE-Lightweight-anti-Sybil-with-anonymity-in-Bitcoin.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - RIDDLE: Lightweight anti-Sybil with anonymity in Bitcoin - 2023-08-02T06:47:46.725260+00:00 - - AdamISZ 2022-08-11 15:31:48+00:00 - - - AdamISZ 2022-06-30 21:50:20+00:00 - - - AdamISZ 2022-06-12 23:04:47+00:00 - + 2025-09-26T14:26:06.058885+00:00 + python-feedgen + + + [bitcoin-dev] RIDDLE: Lightweight anti-Sybil with anonymity in Bitcoin AdamISZ + 2022-06-12T23:04:00.000Z + + + AdamISZ + 2022-06-30T21:50:00.000Z + + + AdamISZ + 2022-08-11T15:31:00.000Z + + - python-feedgen + 2 Combined summary - RIDDLE: Lightweight anti-Sybil with anonymity in Bitcoin - 2023-08-02T06:47:46.725260+00:00 + 2025-09-26T14:26:06.059530+00:00 - Recently, there has been a lot of study on sublinear ring signatures. Groth/Kohlweiss 2014 introduced logarithmic scaled ring signatures, which can be achieved using taproot keys. AdamISZ wrote a blog post discussing the creation of logarithmic sized ring signatures on taproot keys [1]. However, a question remained regarding how to achieve one/N time usage of these ring signatures with key images.Noether & Goodall's Triptych [3] offers a solution to this issue. It builds on the core idea presented in the GK paper [2], which involves bit decomposition of index. In 2015, Bootle et al. published "Short Accountable Ring Signatures Based on DDH" [4], where they further generalized the concept by introducing n-ary decomposition and delta-functions to identify the index with the correct digits in n-ary.In 2020, Triptych was introduced as a combination of the above concepts along with the inclusion of a key image, similar to the basic cryptonote, LWW, LSAG design. According to Bootle et al., their construction is "2.8 times smaller" than the GK design [2]. Although adding the key image requires more space in the proof, it is still significantly compact compared to other designs. Thus, Triptych [3] offers both a key image and a compact size for high anonymity sets.The research indicates that Triptych [3] appears to be practical for genuinely big anonymity sets. Although it may be possible to achieve even more efficient constructions through bilinear pairings crypto, this method would not work on 'bare' secp256k1. However, there might be a way to transfer over to other curves via bilinear pairings crypto.AdamISZ also shared a suggested protocol for anti-Sybil measures that aims to maintain privacy without being too demanding for users. While the protocol primarily focuses on users or customers of websites or services, it could also be applicable in anti-Sybil measures for things like Lightning.The post includes various sections that can be explored through the provided link. It is worth noting that the original gist was migrated due to issues with GitHub's equation formatting feature, but comments are still available on the gist or on a linked post.The post was signed by waxwing/AdamISZ and sent using Proton Mail secure email. 2022-08-11T15:31:48+00:00 + Recently, there has been a lot of study on sublinear ring signatures. Groth/Kohlweiss 2014 introduced logarithmic scaled ring signatures, which can be achieved using taproot keys. AdamISZ wrote a blog post discussing the creation of logarithmic sized ring signatures on taproot keys [1]. However, a question remained regarding how to achieve one/N time usage of these ring signatures with key images.Noether & Goodall's Triptych [3] offers a solution to this issue. It builds on the core idea presented in the GK paper [2], which involves bit decomposition of index. In 2015, Bootle et al. published "Short Accountable Ring Signatures Based on DDH" [4], where they further generalized the concept by introducing n-ary decomposition and delta-functions to identify the index with the correct digits in n-ary.In 2020, Triptych was introduced as a combination of the above concepts along with the inclusion of a key image, similar to the basic cryptonote, LWW, LSAG design. According to Bootle et al., their construction is "2.8 times smaller" than the GK design [2]. Although adding the key image requires more space in the proof, it is still significantly compact compared to other designs. Thus, Triptych [3] offers both a key image and a compact size for high anonymity sets.The research indicates that Triptych [3] appears to be practical for genuinely big anonymity sets. Although it may be possible to achieve even more efficient constructions through bilinear pairings crypto, this method would not work on 'bare' secp256k1. However, there might be a way to transfer over to other curves via bilinear pairings crypto.AdamISZ also shared a suggested protocol for anti-Sybil measures that aims to maintain privacy without being too demanding for users. While the protocol primarily focuses on users or customers of websites or services, it could also be applicable in anti-Sybil measures for things like Lightning.The post includes various sections that can be explored through the provided link. It is worth noting that the original gist was migrated due to issues with GitHub's equation formatting feature, but comments are still available on the gist or on a linked post.The post was signed by waxwing/AdamISZ and sent using Proton Mail secure email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml b/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml index 0cc35ecd13..b5ea93871d 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Regarding BIP322 edge cases - 2023-08-02T07:16:13.437912+00:00 + 2025-09-26T14:26:25.361822+00:00 + python-feedgen Ali Sherief 2022-08-11 16:56:29+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Regarding BIP322 edge cases - 2023-08-02T07:16:13.438893+00:00 + 2025-09-26T14:26:25.361955+00:00 - The Bitcoin community is currently exploring a way for the initial signer to delegate to another scriptPubKey in order to improve privacy and compatibility with CoinJoin/Lightning. One suggestion that has been proposed is to use MAST (two Merkle branches) to achieve this. The first branch would contain the original signer's scriptPubKey, while the second branch would contain the delegated signer's scriptPubKey. It appears that all parties involved can make signatures on both the delegating and delegated keys. However, more documentation is needed to fully understand the motivation behind this requirement.In relation to OP_CHECKDATASIG, it has been discovered that this opcode already exists in Bitcoin Cash. However, proponents of BIP322 do not prioritize BCH script compatibility. In order to create an opcode called OP_CHECKDATASIG for the internal purposes of BIP322, a lengthy soft-fork would be required to modify the consensus rules. This raises the question of how Script should verify a single signature on the stack without affecting any inputs or outputs. Several suggestions have been made, including performing key recovery for legacy ECDSA and using specific output scripts to require valid signatures and public keys. Additionally, backward compatibility with Bitcoin Message and the use of opcodes like OP_RESERVED have been discussed, although introducing new opcodes may add unnecessary complexity to the Script.To address these issues, it has been proposed to introduce a hypothetical OP_CHECKDATASIG opcode that can perform ECDSA public key recovery for legacy P2PKH signing. This could be done safely within the BIP. However, in order to ensure compatibility with existing schemes, the opcode would need to be assigned a specific byte, such as OP_CHECKDATASIG. Backward compatibility is crucial, and one possible approach is to use OP_RESERVED to maintain compatibility with "Bitcoin Message". The draft of BIP322 also includes TODO items such as Silent Transactions, limiting eligible opcodes in scriptPubKeys for signing, and delegation to another scriptPubKey. Suggestions have been made, such as placing a NOP at the beginning of the script to activate proof parsing mode and using MAST for delegation.During the discussion on the bitcoin-dev mailing list, user Ali Sherief brought up several TODO items from an older version of the BIP322 draft. These items included addressing the interaction with Silent Transactions, considering whether to introduce an invalid opcode for specific proof types, and finding a solution for delegating to another scriptPubKey. Suggestions were made to limit which opcodes scriptPubKeys can use for signing by placing a NOP at the beginning of the script to activate proof parsing mode. Additionally, a subsection for Silent Transactions could be created to operate using its scriptPubKey. It was also proposed to use MAST with two Merkle branches to specify the original signer's scriptPubKey and delegated signer's scriptPubKey for delegation.BIP322 is still a work in progress, with several TODO items that need to be addressed. The Github issue/PR at https://github.com/bitcoin/bips/pull/1347 has been created to address these items. Ali shared the TODO items from an older version of the draft and suggested limiting the opcodes that scriptPubKeys can sign from, potentially by using a NOP at the beginning of the script. However, it is important to note that an opcode may not be necessary if the program can infer the source of the proof from context. For silent transactions, a suggestion has been made to create a subsection that operates using its scriptPubKey. As for the delegation to another scriptPubKey, the proposal suggests using MAST with two Merkle branches to contain both scriptPubKeys.Overall, the Bitcoin community is actively discussing various solutions to ensure backward compatibility in Bitcoin Scripting language. The lack of certain opcodes, such as OP_CHECKDATASIG, and the need for delegation to another scriptPubKey are being addressed through proposals like MAST and limited opcode usage. However, more documentation and clarification are required to fully understand the motivations behind these requirements and how they will be implemented. 2022-08-11T16:56:29+00:00 + The Bitcoin community is currently exploring a way for the initial signer to delegate to another scriptPubKey in order to improve privacy and compatibility with CoinJoin/Lightning. One suggestion that has been proposed is to use MAST (two Merkle branches) to achieve this. The first branch would contain the original signer's scriptPubKey, while the second branch would contain the delegated signer's scriptPubKey. It appears that all parties involved can make signatures on both the delegating and delegated keys. However, more documentation is needed to fully understand the motivation behind this requirement.In relation to OP_CHECKDATASIG, it has been discovered that this opcode already exists in Bitcoin Cash. However, proponents of BIP322 do not prioritize BCH script compatibility. In order to create an opcode called OP_CHECKDATASIG for the internal purposes of BIP322, a lengthy soft-fork would be required to modify the consensus rules. This raises the question of how Script should verify a single signature on the stack without affecting any inputs or outputs. Several suggestions have been made, including performing key recovery for legacy ECDSA and using specific output scripts to require valid signatures and public keys. Additionally, backward compatibility with Bitcoin Message and the use of opcodes like OP_RESERVED have been discussed, although introducing new opcodes may add unnecessary complexity to the Script.To address these issues, it has been proposed to introduce a hypothetical OP_CHECKDATASIG opcode that can perform ECDSA public key recovery for legacy P2PKH signing. This could be done safely within the BIP. However, in order to ensure compatibility with existing schemes, the opcode would need to be assigned a specific byte, such as OP_CHECKDATASIG. Backward compatibility is crucial, and one possible approach is to use OP_RESERVED to maintain compatibility with "Bitcoin Message". The draft of BIP322 also includes TODO items such as Silent Transactions, limiting eligible opcodes in scriptPubKeys for signing, and delegation to another scriptPubKey. Suggestions have been made, such as placing a NOP at the beginning of the script to activate proof parsing mode and using MAST for delegation.During the discussion on the bitcoin-dev mailing list, user Ali Sherief brought up several TODO items from an older version of the BIP322 draft. These items included addressing the interaction with Silent Transactions, considering whether to introduce an invalid opcode for specific proof types, and finding a solution for delegating to another scriptPubKey. Suggestions were made to limit which opcodes scriptPubKeys can use for signing by placing a NOP at the beginning of the script to activate proof parsing mode. Additionally, a subsection for Silent Transactions could be created to operate using its scriptPubKey. It was also proposed to use MAST with two Merkle branches to specify the original signer's scriptPubKey and delegated signer's scriptPubKey for delegation.BIP322 is still a work in progress, with several TODO items that need to be addressed. The Github issue/PR at https://github.com/bitcoin/bips/pull/1347 has been created to address these items. Ali shared the TODO items from an older version of the draft and suggested limiting the opcodes that scriptPubKeys can sign from, potentially by using a NOP at the beginning of the script. However, it is important to note that an opcode may not be necessary if the program can infer the source of the proof from context. For silent transactions, a suggestion has been made to create a subsection that operates using its scriptPubKey. As for the delegation to another scriptPubKey, the proposal suggests using MAST with two Merkle branches to contain both scriptPubKeys.Overall, the Bitcoin community is actively discussing various solutions to ensure backward compatibility in Bitcoin Scripting language. The lack of certain opcodes, such as OP_CHECKDATASIG, and the need for delegation to another scriptPubKey are being addressed through proposals like MAST and limited opcode usage. However, more documentation and clarification are required to fully understand the motivations behind these requirements and how they will be implemented. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_Regarding-setting-a-lower-minrelaytxfee.xml b/static/bitcoin-dev/Aug_2022/combined_Regarding-setting-a-lower-minrelaytxfee.xml index 07cfa85844..a15784e78f 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Regarding-setting-a-lower-minrelaytxfee.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Regarding-setting-a-lower-minrelaytxfee.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - Regarding setting a lower minrelaytxfee - 2023-08-02T07:11:13.160298+00:00 - - Billy Tetrud 2022-08-04 01:21:51+00:00 - - - Aaradhya Chauhan 2022-08-03 18:22:32+00:00 - - - vjudeu at gazeta.pl 2022-08-03 17:07:08+00:00 - - - Aaradhya Chauhan 2022-08-03 15:40:34+00:00 - - - Peter Todd 2022-08-01 13:37:47+00:00 - - - aliashraf.btc At protonmail 2022-08-01 13:19:05+00:00 - - - Peter Todd 2022-08-01 10:30:07+00:00 - - - alicexbt 2022-07-30 17:24:35+00:00 - - - Peter Todd 2022-07-30 10:20:49+00:00 - - - Aaradhya Chauhan 2022-07-30 07:55:55+00:00 - - - Aaradhya Chauhan 2022-07-29 18:59:31+00:00 - - - David A. Harding 2022-07-29 03:38:19+00:00 - - - vjudeu at gazeta.pl 2022-07-27 12:18:56+00:00 - - - Peter Todd 2022-07-27 11:50:23+00:00 - - - vjudeu at gazeta.pl 2022-07-27 04:10:00+00:00 - - - alicexbt 2022-07-26 19:14:58+00:00 - - - Peter Todd 2022-07-26 14:27:56+00:00 - - - Peter Todd 2022-07-26 12:45:12+00:00 - - - alicexbt 2022-07-26 12:19:32+00:00 - - - Aaradhya Chauhan 2022-07-26 08:26:05+00:00 - + 2025-09-26T14:26:36.028203+00:00 + python-feedgen + + + [bitcoin-dev] Regarding setting a lower minrelaytxfee Aaradhya Chauhan + 2022-07-26T08:26:00.000Z + + + alicexbt + 2022-07-26T12:19:00.000Z + + + Peter Todd + 2022-07-26T12:45:00.000Z + + + Peter Todd + 2022-07-26T14:27:00.000Z + + + alicexbt + 2022-07-26T19:14:00.000Z + + + vjudeu + 2022-07-27T04:10:00.000Z + + + Peter Todd + 2022-07-27T11:50:00.000Z + + + vjudeu + 2022-07-27T12:18:00.000Z + + + David A. Harding + 2022-07-29T03:38:00.000Z + + + Aaradhya Chauhan + 2022-07-29T18:59:00.000Z + + + Aaradhya Chauhan + 2022-07-30T07:55:00.000Z + + + Peter Todd + 2022-07-30T10:20:00.000Z + + + alicexbt + 2022-07-30T17:24:00.000Z + + + Peter Todd + 2022-08-01T10:30:00.000Z + + + aliashraf.btc At protonmail + 2022-08-01T13:19:00.000Z + + + Peter Todd + 2022-08-01T13:37:00.000Z + + + Aaradhya Chauhan + 2022-08-03T15:40:00.000Z + + + vjudeu + 2022-08-03T17:07:00.000Z + + + Aaradhya Chauhan + 2022-08-03T18:22:00.000Z + + + Billy Tetrud + 2022-08-04T01:21:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - Regarding setting a lower minrelaytxfee - 2023-08-02T07:11:13.160298+00:00 + 2025-09-26T14:26:36.030380+00:00 - The discussion on the bitcoin-dev mailing list revolves around the possibility of changing the dust limit and the minimum transaction relay feerate. A member suggested removing the fixed dust limit and relying solely on the mempool size limit to determine what is considered dust. However, others pointed out that individual nodes adjusting their settings would not be effective without a network-wide change. While the current settings may be useful for certain situations, changing the defaults would achieve nothing for the majority of users.Peter Todd, a Bitcoin developer, proposed removing the fixed dust limit entirely and relying on the mempool size limit. He argued that this change could be made by nodes without requesting permission or modifying the source code. He also stated that lowering the dust limit would prepare the ecosystem for future conditions where fee revenue would be significant. However, some members raised concerns about potential adverse effects and the complexity involved in implementing this change.In another discussion on the bitcoin-dev mailing list, a user asked about the possibility of reducing the minimum relay transaction fee for Bitcoin transactions. It was noted that while this is not a consensus rule, it could be done with support from full node operators. However, some miners may be hesitant to lower profits by using a lower minrelaytxfee. The option of allowing near-zero transactions into a miner's mempool through the Child-Pays-For-Parent mechanism was also mentioned as a way to potentially mine more fees.Aaradhya Chauhan, a member of the Bitcoin-dev group, expressed the opinion that the current dust protection measure is too high and should be lowered slightly. She suggested halving the measure when prices double and keeping it constant at that point. Aaradhya believes that this change can be easily implemented with the support of full node operators. However, she acknowledged that a few miners may be reluctant to lower their profits by using a lower minrelaytxfee. She supports the Lightning Network but also emphasizes the importance of maintaining transaction affordability in the future. Aaradhya argues that those willing to wait in a queue should have the option for the same affordability for minimum fees as exists today.Overall, the discussions on the bitcoin-dev mailing list revolve around the potential changes to the dust limit and the minimum transaction relay feerate. While some argue for lowering these limits, others raise concerns about potential challenges and adverse effects. The economic benefits of reducing feerates for the bottom of the mempool are considered relatively small compared to the complexity involved. 2022-08-04T01:21:51+00:00 + The discussion on the bitcoin-dev mailing list revolves around the possibility of changing the dust limit and the minimum transaction relay feerate. A member suggested removing the fixed dust limit and relying solely on the mempool size limit to determine what is considered dust. However, others pointed out that individual nodes adjusting their settings would not be effective without a network-wide change. While the current settings may be useful for certain situations, changing the defaults would achieve nothing for the majority of users.Peter Todd, a Bitcoin developer, proposed removing the fixed dust limit entirely and relying on the mempool size limit. He argued that this change could be made by nodes without requesting permission or modifying the source code. He also stated that lowering the dust limit would prepare the ecosystem for future conditions where fee revenue would be significant. However, some members raised concerns about potential adverse effects and the complexity involved in implementing this change.In another discussion on the bitcoin-dev mailing list, a user asked about the possibility of reducing the minimum relay transaction fee for Bitcoin transactions. It was noted that while this is not a consensus rule, it could be done with support from full node operators. However, some miners may be hesitant to lower profits by using a lower minrelaytxfee. The option of allowing near-zero transactions into a miner's mempool through the Child-Pays-For-Parent mechanism was also mentioned as a way to potentially mine more fees.Aaradhya Chauhan, a member of the Bitcoin-dev group, expressed the opinion that the current dust protection measure is too high and should be lowered slightly. She suggested halving the measure when prices double and keeping it constant at that point. Aaradhya believes that this change can be easily implemented with the support of full node operators. However, she acknowledged that a few miners may be reluctant to lower their profits by using a lower minrelaytxfee. She supports the Lightning Network but also emphasizes the importance of maintaining transaction affordability in the future. Aaradhya argues that those willing to wait in a queue should have the option for the same affordability for minimum fees as exists today.Overall, the discussions on the bitcoin-dev mailing list revolve around the potential changes to the dust limit and the minimum transaction relay feerate. While some argue for lowering these limits, others raise concerns about potential challenges and adverse effects. The economic benefits of reducing feerates for the bottom of the mempool are considered relatively small compared to the complexity involved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml b/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml index 166af6ceeb..1bfaf7241d 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2023-08-02T06:56:36.748113+00:00 + 2025-09-26T14:26:31.766987+00:00 + python-feedgen Billy Tetrud 2022-08-20 15:30:26+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2023-08-02T06:56:36.750118+00:00 + 2025-09-26T14:26:31.767233+00:00 - The context discusses various discussions and debates related to the functioning and security of the Bitcoin network. One aspect discussed is the concept of "free lunches" in the network, where some users benefit without contributing, while others bear the costs. It is argued that this is an unhealthy state for the financial system and may not be sustainable in the long term.One suggestion to address this issue is to remove halvings, which are events that reduce the block reward for miners, if they become destructive to the network's security. It is also mentioned that a balanced system with a low annual inflation rate is preferable to any fiat system. While widespread consensus would be ideal, it is acknowledged that a hard fork may be necessary to implement necessary changes.The feasibility of large Bitcoin holders running ASICs to secure their holdings is also discussed. The assumption is made that fees alone may not compensate for low block rewards, and therefore, large holders may mine at a loss to preserve the value of their holdings. However, it is acknowledged that this approach may not work in practice due to trust issues and the potential for betrayal.The concept of the Prisoner's Dilemma is mentioned in relation to cooperation between Bitcoin users. It is highlighted that even though cooperation may be in the best interest of both parties, mistrust and self-interest can lead to suboptimal outcomes.The importance of transaction fees in providing censorship resistance and incentivizing miners to keep the network secure is emphasized. The discussion explores different approaches, such as tying miner revenue to the total value of Bitcoin or relying solely on transaction fees.There are debates about the business model of miners who intend to censor transactions when there is no block reward. It is argued that transaction fees provide censorship resistance, and miners may prioritize high fee transactions to maximize their earnings.The role of the block reward in the functioning of the Bitcoin network is highlighted. The question is raised about whether a perpetual block subsidy should be tied to the total value of Bitcoin or if other methods should be considered to incentivize miners.The assumption of a constant rate for losses in Bitcoin is challenged, and it is argued that losses can occur at a predictable rate. The potential impact of lost coins on the overall value of Bitcoin is discussed.There are also discussions about the subjective nature of defining Bitcoin and the role of leading bodies versus individual autonomy. The importance of the capped supply and predictable issuance curve is mentioned, and tinkering with the protocol is seen as potentially inviting further subversion.The discussion revolves around the predictability of losses in tail emission. While Peter assumes that there is a rate, it is possible for losses to be at a different predictable rate. However, if there exists any fixed central tendency for the rate, tail emission will eventually become non-inflationary. There are two other factors to consider: firstly, if people improve custody faster than 1/(N(t)*P), tail emission can still be inflationary, although this seems unlikely. Secondly, the rate is somewhat stochastic, with "black swan events" like popular wallet losing keys in coding error being possible but not relevant to tail-emission being non-inflationary. However, even such events can be factored into a fixed central tendency over a long enough time period.In the discussion on whether or not to extend block rewards after the current deadline, it is noted that this is only relevant if the community agrees that it is necessary to maintain network security. It is worth noting that a mild inflation can sometimes be compensated by coin loss, which is like a bonus. The assumption of a constant coin loss rate seems unreasonable as people improve their key storage habits over time, leading to a decrease in the rate of coin loss. Additionally, there may be common causes for coin losses that result in heavily correlated losses rather than independent ones.The conversation further explores the potential implications of tail emission on the ability of individuals to access their coins. Todd clarifies that his proposal does not involve re-assigning ownership of coins and therefore does not take away anyone's ability to access their coins. The concern raised by naman naman about the ability to move coins after a long period of inactivity is addressed, with Todd stating that his article on tail emission is focused on maintaining blockchain security without causing inflation.The latest blog post by Peter Todd titled "Surprisingly, Tail Emission Is Not Inflationary" explores the concept of tail emission and its impact on the supply of Bitcoin. Todd argues that tail emission, which is a fixed reward per block that continues indefinitely, can result in a stable monetary supply rather than a monetarily inflationary one. He explains that lost coins contribute to this stability, as they are constantly being lost due to various factors such as deaths, forgotten passphrases, and accidents.The article also discusses the feasibility of implementing tail emission in Bitcoin. While other currencies like Monero have successfully implemented it, adding tail emission to Bitcoin would require convincing a substantial fraction of the Bitcoin community to support the idea. Todd suggests that 2022-08-20T15:30:26+00:00 + The context discusses various discussions and debates related to the functioning and security of the Bitcoin network. One aspect discussed is the concept of "free lunches" in the network, where some users benefit without contributing, while others bear the costs. It is argued that this is an unhealthy state for the financial system and may not be sustainable in the long term.One suggestion to address this issue is to remove halvings, which are events that reduce the block reward for miners, if they become destructive to the network's security. It is also mentioned that a balanced system with a low annual inflation rate is preferable to any fiat system. While widespread consensus would be ideal, it is acknowledged that a hard fork may be necessary to implement necessary changes.The feasibility of large Bitcoin holders running ASICs to secure their holdings is also discussed. The assumption is made that fees alone may not compensate for low block rewards, and therefore, large holders may mine at a loss to preserve the value of their holdings. However, it is acknowledged that this approach may not work in practice due to trust issues and the potential for betrayal.The concept of the Prisoner's Dilemma is mentioned in relation to cooperation between Bitcoin users. It is highlighted that even though cooperation may be in the best interest of both parties, mistrust and self-interest can lead to suboptimal outcomes.The importance of transaction fees in providing censorship resistance and incentivizing miners to keep the network secure is emphasized. The discussion explores different approaches, such as tying miner revenue to the total value of Bitcoin or relying solely on transaction fees.There are debates about the business model of miners who intend to censor transactions when there is no block reward. It is argued that transaction fees provide censorship resistance, and miners may prioritize high fee transactions to maximize their earnings.The role of the block reward in the functioning of the Bitcoin network is highlighted. The question is raised about whether a perpetual block subsidy should be tied to the total value of Bitcoin or if other methods should be considered to incentivize miners.The assumption of a constant rate for losses in Bitcoin is challenged, and it is argued that losses can occur at a predictable rate. The potential impact of lost coins on the overall value of Bitcoin is discussed.There are also discussions about the subjective nature of defining Bitcoin and the role of leading bodies versus individual autonomy. The importance of the capped supply and predictable issuance curve is mentioned, and tinkering with the protocol is seen as potentially inviting further subversion.The discussion revolves around the predictability of losses in tail emission. While Peter assumes that there is a rate, it is possible for losses to be at a different predictable rate. However, if there exists any fixed central tendency for the rate, tail emission will eventually become non-inflationary. There are two other factors to consider: firstly, if people improve custody faster than 1/(N(t)*P), tail emission can still be inflationary, although this seems unlikely. Secondly, the rate is somewhat stochastic, with "black swan events" like popular wallet losing keys in coding error being possible but not relevant to tail-emission being non-inflationary. However, even such events can be factored into a fixed central tendency over a long enough time period.In the discussion on whether or not to extend block rewards after the current deadline, it is noted that this is only relevant if the community agrees that it is necessary to maintain network security. It is worth noting that a mild inflation can sometimes be compensated by coin loss, which is like a bonus. The assumption of a constant coin loss rate seems unreasonable as people improve their key storage habits over time, leading to a decrease in the rate of coin loss. Additionally, there may be common causes for coin losses that result in heavily correlated losses rather than independent ones.The conversation further explores the potential implications of tail emission on the ability of individuals to access their coins. Todd clarifies that his proposal does not involve re-assigning ownership of coins and therefore does not take away anyone's ability to access their coins. The concern raised by naman naman about the ability to move coins after a long period of inactivity is addressed, with Todd stating that his article on tail emission is focused on maintaining blockchain security without causing inflation.The latest blog post by Peter Todd titled "Surprisingly, Tail Emission Is Not Inflationary" explores the concept of tail emission and its impact on the supply of Bitcoin. Todd argues that tail emission, which is a fixed reward per block that continues indefinitely, can result in a stable monetary supply rather than a monetarily inflationary one. He explains that lost coins contribute to this stability, as they are constantly being lost due to various factors such as deaths, forgotten passphrases, and accidents.The article also discusses the feasibility of implementing tail emission in Bitcoin. While other currencies like Monero have successfully implemented it, adding tail emission to Bitcoin would require convincing a substantial fraction of the Bitcoin community to support the idea. Todd suggests that - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml b/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml index ddb98c03c0..7d5b07b285 100644 --- a/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml +++ b/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - joinstr: coinjoin implementation using nostr - 2023-08-02T07:18:10.724897+00:00 + 2025-09-26T14:26:18.959116+00:00 + python-feedgen alicexbt 2022-09-10 10:17:37+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - joinstr: coinjoin implementation using nostr - 2023-08-02T07:18:10.724897+00:00 + 2025-09-26T14:26:18.959275+00:00 - A developer named alicexbt has created a proof-of-concept python script to implement coinjoin using nostr, a decentralized network based on cryptographic keypairs. This implementation utilizes several Bitcoin Core wallet and RPC commands and requires the python-nostr library for coordination between peers. The process involves 5 peers coordinating to create, sign, and broadcast a coinjoin transaction. Each step of the process is published as an event using a nostr relay, and users can use multiple relays simultaneously to avoid trusting a single relay. However, there is a vulnerability of denial of service in the implementation, where a malicious user can register multiple outputs with the same secret, causing an ongoing free denial of service attack without attribution or defense.To address this issue, PR #24058 (basic support BIP-322) can be implemented to add proof of ownership. Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, they can send `txid:out` with a message signed with the address, verify using `verifymessage`, and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO. The cryptographic scheme mentioned as an alternative to blind signatures isn't implemented yet, as it requires a NIP and at least one relay using it.The author plans to continue developing coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. Custom relays are supported by Nostr, examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. The author will run a free and open nostr relay for this project and try to fix the DoS issues before a mainnet version is released for the python script (for nerds) and android app (for all users).The email is sent using Proton Mail secure email, and the author invites opinions on the experiment. The email thread is part of the bitcoin-dev mailing list hosted by lists.linuxfoundation.org. The author credits Fiatjaf, Andrew Chow, Jeff Thibault, and existing coinjoin implementations for their contributions. The author also mentions the creation of an Android app for joinstr in the coming week.Overall, the developer's message provides insights into a coinjoin implementation using Nostr, the challenges and limitations of the current system, and potential improvements to make it more secure. The email includes relevant links to GitHub repositories and provides event IDs and a Coinjoin transaction ID for reference. 2022-09-10T10:17:37+00:00 + A developer named alicexbt has created a proof-of-concept python script to implement coinjoin using nostr, a decentralized network based on cryptographic keypairs. This implementation utilizes several Bitcoin Core wallet and RPC commands and requires the python-nostr library for coordination between peers. The process involves 5 peers coordinating to create, sign, and broadcast a coinjoin transaction. Each step of the process is published as an event using a nostr relay, and users can use multiple relays simultaneously to avoid trusting a single relay. However, there is a vulnerability of denial of service in the implementation, where a malicious user can register multiple outputs with the same secret, causing an ongoing free denial of service attack without attribution or defense.To address this issue, PR #24058 (basic support BIP-322) can be implemented to add proof of ownership. Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, they can send `txid:out` with a message signed with the address, verify using `verifymessage`, and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO. The cryptographic scheme mentioned as an alternative to blind signatures isn't implemented yet, as it requires a NIP and at least one relay using it.The author plans to continue developing coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. Custom relays are supported by Nostr, examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. The author will run a free and open nostr relay for this project and try to fix the DoS issues before a mainnet version is released for the python script (for nerds) and android app (for all users).The email is sent using Proton Mail secure email, and the author invites opinions on the experiment. The email thread is part of the bitcoin-dev mailing list hosted by lists.linuxfoundation.org. The author credits Fiatjaf, Andrew Chow, Jeff Thibault, and existing coinjoin implementations for their contributions. The author also mentions the creation of an Android app for joinstr in the coming week.Overall, the developer's message provides insights into a coinjoin implementation using Nostr, the challenges and limitations of the current system, and potential improvements to make it more secure. The email includes relevant links to GitHub repositories and provides event IDs and a Coinjoin transaction ID for reference. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Announcing-Libforesta.xml b/static/bitcoin-dev/Aug_2023/combined_Announcing-Libforesta.xml index 8e802651e3..0ea7110b40 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Announcing-Libforesta.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Announcing-Libforesta.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Announcing Libforesta - 2023-08-11T15:44:04.631800+00:00 - - Davidson Souza 2023-08-03 20:34:04+00:00 - - - leohaf at orangepill.ovh 2023-08-03 14:03:19+00:00 - - - Davidson Souza 2023-08-02 21:32:15+00:00 - - - Bastiaan van den Berg 2023-08-01 08:02:55+00:00 - - - Davidson Souza 2023-07-31 17:47:26+00:00 - + 2025-09-26T14:27:14.546342+00:00 + python-feedgen + + + [bitcoin-dev] Announcing Libforesta Davidson Souza + 2023-07-31T17:47:00.000Z + + + Bastiaan van den Berg + 2023-08-01T08:02:00.000Z + + + Davidson Souza + 2023-08-02T21:32:00.000Z + + + leohaf + 2023-08-03T14:03:00.000Z + + + Davidson Souza + 2023-08-03T20:34:00.000Z + + - python-feedgen + 2 Combined summary - Announcing Libforesta - 2023-08-11T15:44:04.631800+00:00 + 2025-09-26T14:27:14.547033+00:00 - Davidson Souza, the developer of Floresta, has introduced a project called libfloresta to the Bitcoin developers mailing list. Libfloresta is a fully-validating Bitcoin full node with an integrated watch-only wallet and Electrum Server. The main aim of the project is to create a compact and user-friendly full node for low-power devices like single-board computers (SBCs) and smartphones. Davidson is writing the main logic of libfloresta in Rust and generating bindings to the original code, allowing it to run virtually anywhere by compiling it to WebAssembly (WASM). The project is still in its early stages but has been successfully used on signet without any issues. Mainnet support is almost ready, but performance issues with bridge nodes need to be resolved first. The code is available on Davidson's GitHub repository, along with a blog post explaining how to use it in Rust. Davidson plans to write more documentation as the project matures and is deployed on other platforms. Feedback from the community is welcomed. In terms of consensus, libfloresta does not reimplement the Bitcoin Consensus machine from scratch. Instead, it uses libbitcoinconsensus and plans to incorporate the full libbitcoinkernel in the future. This approach minimizes the risk of misimplementations leading to splits. Davidson is also conducting cross-tests against Bitcoin Core to identify any inconsistencies before they become problematic. Davidson expresses gratitude to Vinteum for their support in his work with Utreexo and Floresta. Overall, libfloresta aims to provide a lightweight and user-friendly solution for running a Bitcoin full node, particularly on low-power devices. It offers compatibility with existing Bitcoin infrastructure and can be used alongside Bitcoin Core. 2023-08-03T20:34:04+00:00 + Davidson Souza, the developer of Floresta, has introduced a project called libfloresta to the Bitcoin developers mailing list. Libfloresta is a fully-validating Bitcoin full node with an integrated watch-only wallet and Electrum Server. The main aim of the project is to create a compact and user-friendly full node for low-power devices like single-board computers (SBCs) and smartphones. Davidson is writing the main logic of libfloresta in Rust and generating bindings to the original code, allowing it to run virtually anywhere by compiling it to WebAssembly (WASM). The project is still in its early stages but has been successfully used on signet without any issues. Mainnet support is almost ready, but performance issues with bridge nodes need to be resolved first. The code is available on Davidson's GitHub repository, along with a blog post explaining how to use it in Rust. Davidson plans to write more documentation as the project matures and is deployed on other platforms. Feedback from the community is welcomed. In terms of consensus, libfloresta does not reimplement the Bitcoin Consensus machine from scratch. Instead, it uses libbitcoinconsensus and plans to incorporate the full libbitcoinkernel in the future. This approach minimizes the risk of misimplementations leading to splits. Davidson is also conducting cross-tests against Bitcoin Core to identify any inconsistencies before they become problematic. Davidson expresses gratitude to Vinteum for their support in his work with Utreexo and Floresta. Overall, libfloresta aims to provide a lightweight and user-friendly solution for running a Bitcoin full node, particularly on low-power devices. It offers compatibility with existing Bitcoin infrastructure and can be used alongside Bitcoin Core. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml b/static/bitcoin-dev/Aug_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml index 03cd9d9193..abc29f6d13 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - Ark: An Alternative Privacy-preserving Second Layer Solution - 2023-08-07T22:25:40.967928+00:00 - - Antoine Riard 2023-08-06 22:43:55+00:00 - - - moonsettler 2023-06-11 09:19:18+00:00 - - - David A. Harding 2023-06-07 18:20:33+00:00 - - - Burak Keceli 2023-06-07 13:30:07+00:00 - - - Ali Sherief 2023-05-28 06:02:58+00:00 - - - David A. Harding 2023-05-27 20:36:47+00:00 - - - Burak Keceli 2023-05-26 11:56:00+00:00 - - - jk_ at op.pl 2023-05-26 07:33:42+00:00 - - - Ali Sherief 2023-05-25 12:12:43+00:00 - - - David A. Harding 2023-05-24 23:02:40+00:00 - - - adiabat 2023-05-24 20:20:35+00:00 - - - Burak Keceli 2023-05-24 07:53:50+00:00 - - - Burak Keceli 2023-05-24 06:28:08+00:00 - - - ZmnSCPxj 2023-05-24 00:45:49+00:00 - - - ZmnSCPxj 2023-05-24 00:40:42+00:00 - - - G. Andrew Stone 2023-05-23 22:06:02+00:00 - - - Burak Keceli 2023-05-23 04:31:24+00:00 - - - ZmnSCPxj 2023-05-22 13:03:00+00:00 - - - Burak Keceli 2023-05-22 07:54:03+00:00 - + 2025-09-26T14:27:35.984018+00:00 + python-feedgen + + + Burak Keceli + 2023-05-22T07:54:00.000Z + + + ZmnSCPxj + 2023-05-22T13:03:00.000Z + + + Burak Keceli + 2023-05-23T04:31:00.000Z + + + G. Andrew Stone + 2023-05-23T22:06:00.000Z + + + ZmnSCPxj + 2023-05-24T00:40:00.000Z + + + ZmnSCPxj + 2023-05-24T00:45:00.000Z + + + Burak Keceli + 2023-05-24T06:28:00.000Z + + + Burak Keceli + 2023-05-24T07:53:00.000Z + + + adiabat + 2023-05-24T20:20:00.000Z + + + David A. Harding + 2023-05-24T23:02:00.000Z + + + Ali Sherief + 2023-05-25T12:12:00.000Z + + + jk_14 + 2023-05-26T07:33:00.000Z + + + Burak Keceli + 2023-05-26T11:56:00.000Z + + + David A. Harding + 2023-05-27T20:36:00.000Z + + + Ali Sherief + 2023-05-28T06:02:00.000Z + + + Burak Keceli + 2023-06-07T13:30:00.000Z + + + David A. Harding + 2023-06-07T18:20:00.000Z + + + [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution moonsettler + 2023-06-11T09:19:00.000Z + + + Antoine Riard + 2023-08-06T22:43:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - Ark: An Alternative Privacy-preserving Second Layer Solution - 2023-08-07T22:25:40.967928+00:00 + 2025-09-26T14:27:35.985950+00:00 - ZmnSCPxj raised concerns about the risks involved in designing a non-custodial Layer 2 payment system, emphasizing the need for thorough code testing before deployment. One risk highlighted is the use of 0-conf transactions, which are considered unsafe due to the potential for double-spending. This applies to both Lightning payments and swap-ins.In the case of Lightning, there is a specific concern when opening a zero-conf channel to receive payments. If the channel is not confirmed before revealing the payment's preimage, the Lightning Service Provider (LSP) can take the sender's money and double-spend on the channel. However, Ark provides an alternative solution using Atomic-Time Locked Contracts (ATLCs). With ATLCs, users can receive and forward payments without waiting for on-chain confirmations. Any attempt at double-spending breaks the entire atomicity, preventing the ASP from redeeming senders' vTXOs if they double-spend recipients' vTXOs.Burak and ZmnSCPxj further discuss risks associated with Lightning payments. They note that ASPs who fail to forward HTLCs after double-spending their pool transaction pose a potential issue known as a footgun. In contrast, Ark allows users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. This distinguishes Ark from swap-ins, where users must wait for on-chain confirmations before revealing their preimage of the HODL invoice to avoid double-spending risks.The email thread also includes a request for a detailed architecture write-up encompassing bitcoin scripts, transactions, and L2 protocols. Burak explains how ASPs may fail to forward Lightning payments on the broader network after being replaced in-mempool transactions. However, forwarding HTLCs before double-spending the pool transaction can prevent this issue. Ark's collaborative nature enables users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. In contrast, swap-ins require users to wait for on-chain confirmations before revealing their preimage of the HODL invoice to prevent funds from being stolen through double-spending by the swap service provider.Ark is introduced as a new second-layer protocol that offers an alternative approach to the Lightning network. It allows users to send and receive funds without liquidity constraints and has a smaller on-chain footprint compared to Lightning. The protocol utilizes virtual UTXOs (vTXOs) that exist off-chain and must be spent within four weeks of receipt. Existing vTXOs are redeemed and new ones created during payment transactions. To enhance anonymity, vTXO values are limited to a specific range. Users can acquire vTXOs from others or lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO through a process called lifting. Ark relies on Ark Service Providers (ASPs) as untrusted intermediaries who provide liquidity and charge fees. ASPs create rapid, blinded coinjoin sessions called pools, allowing users to make payments by registering their vTXOs for spending and recipients' vTXOs. Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction. Payments are credited every five seconds and settled every ten minutes, providing immediate availability without waiting for on-chain confirmations to spend zero-conf vTXOs.For more detailed information about Ark, refer to the website https://arkpill.me/deep-dive. 2023-08-06T22:43:55+00:00 + ZmnSCPxj raised concerns about the risks involved in designing a non-custodial Layer 2 payment system, emphasizing the need for thorough code testing before deployment. One risk highlighted is the use of 0-conf transactions, which are considered unsafe due to the potential for double-spending. This applies to both Lightning payments and swap-ins.In the case of Lightning, there is a specific concern when opening a zero-conf channel to receive payments. If the channel is not confirmed before revealing the payment's preimage, the Lightning Service Provider (LSP) can take the sender's money and double-spend on the channel. However, Ark provides an alternative solution using Atomic-Time Locked Contracts (ATLCs). With ATLCs, users can receive and forward payments without waiting for on-chain confirmations. Any attempt at double-spending breaks the entire atomicity, preventing the ASP from redeeming senders' vTXOs if they double-spend recipients' vTXOs.Burak and ZmnSCPxj further discuss risks associated with Lightning payments. They note that ASPs who fail to forward HTLCs after double-spending their pool transaction pose a potential issue known as a footgun. In contrast, Ark allows users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. This distinguishes Ark from swap-ins, where users must wait for on-chain confirmations before revealing their preimage of the HODL invoice to avoid double-spending risks.The email thread also includes a request for a detailed architecture write-up encompassing bitcoin scripts, transactions, and L2 protocols. Burak explains how ASPs may fail to forward Lightning payments on the broader network after being replaced in-mempool transactions. However, forwarding HTLCs before double-spending the pool transaction can prevent this issue. Ark's collaborative nature enables users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. In contrast, swap-ins require users to wait for on-chain confirmations before revealing their preimage of the HODL invoice to prevent funds from being stolen through double-spending by the swap service provider.Ark is introduced as a new second-layer protocol that offers an alternative approach to the Lightning network. It allows users to send and receive funds without liquidity constraints and has a smaller on-chain footprint compared to Lightning. The protocol utilizes virtual UTXOs (vTXOs) that exist off-chain and must be spent within four weeks of receipt. Existing vTXOs are redeemed and new ones created during payment transactions. To enhance anonymity, vTXO values are limited to a specific range. Users can acquire vTXOs from others or lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO through a process called lifting. Ark relies on Ark Service Providers (ASPs) as untrusted intermediaries who provide liquidity and charge fees. ASPs create rapid, blinded coinjoin sessions called pools, allowing users to make payments by registering their vTXOs for spending and recipients' vTXOs. Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction. Payments are credited every five seconds and settled every ten minutes, providing immediate availability without waiting for on-chain confirmations to spend zero-conf vTXOs.For more detailed information about Ark, refer to the website https://arkpill.me/deep-dive. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_BIP-352-Silent-Payments-addresses-should-have-an-expiration-time.xml b/static/bitcoin-dev/Aug_2023/combined_BIP-352-Silent-Payments-addresses-should-have-an-expiration-time.xml index 30f1a27f81..e55a8130c5 100644 --- a/static/bitcoin-dev/Aug_2023/combined_BIP-352-Silent-Payments-addresses-should-have-an-expiration-time.xml +++ b/static/bitcoin-dev/Aug_2023/combined_BIP-352-Silent-Payments-addresses-should-have-an-expiration-time.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP-352 Silent Payments addresses should have an expiration time - 2023-08-11T15:45:27.663149+00:00 - - Peter Todd 2023-08-10 20:58:00+00:00 - - - Dan Gould 2023-08-08 21:05:43+00:00 - - - josibake 2023-08-06 14:20:06+00:00 - - - Brandon Black 2023-08-05 14:46:52+00:00 - - - Peter Todd 2023-08-05 14:15:35+00:00 - - - Peter Todd 2023-08-05 14:06:10+00:00 - - - Brandon Black 2023-08-04 22:27:17+00:00 - - - Samson Mow 2023-08-04 18:41:39+00:00 - - - Peter Todd 2023-08-04 17:39:03+00:00 - + 2025-09-26T14:27:40.211908+00:00 + python-feedgen + + + [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time Peter Todd + 2023-08-04T17:39:00.000Z + + + Samson Mow + 2023-08-04T18:41:00.000Z + + + Brandon Black + 2023-08-04T22:27:00.000Z + + + Peter Todd + 2023-08-05T14:06:00.000Z + + + Peter Todd + 2023-08-05T14:15:00.000Z + + + Brandon Black + 2023-08-05T14:46:00.000Z + + + josibake + 2023-08-06T14:20:00.000Z + + + Dan Gould + 2023-08-08T21:05:00.000Z + + + Peter Todd + 2023-08-10T20:58:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - BIP-352 Silent Payments addresses should have an expiration time - 2023-08-11T15:45:27.663149+00:00 + 2025-09-26T14:27:40.213028+00:00 - The proposal suggests implementing an expiration field for silent payment addresses in Bitcoin wallets. This would prevent potential loss of funds by giving addresses a predetermined lifespan. The expiration field follows a custom compact encoding scheme that allows for different levels of granularity and maximum expiration periods. The byte length ranges from 1 to 8, with the number of usable bits increasing as the byte length increases. This flexibility ensures that various expiration periods, such as years and weeks, can be accommodated. One advantage of this encoding scheme is its ability to degrade cleanly over time, so it will continue to function properly even after many years of use. Block-based expiration is also included to enable compatibility with operations like OP_CLTV OP_VAULT_RECOVER or OP_CLTV OP_CHECKSIG.The context does not specify the reason behind the chosen 180-year limit, but it can be assumed that this timeframe is practical and avoids excessive speculation. However, there are arguments for extending the planning horizon beyond 180 years, especially for addressing long-term challenges like climate change and resource depletion. It is important to find a balance between short-term practicality and long-term vision when determining the planning horizon. The choice involves trade-offs and should consider the specific context and goals of decision-making processes.The email discusses the need for an expiration mechanism for silent payment addresses in Bitcoin wallets. It proposes using a period of 2^24 days, equivalent to 45,000 years or 2 bytes, allowing for an expiration period of 180 years. The email recommends setting a default expiration period of 1 year for newly created addresses and suggests that transactions to expired addresses should fail with a message stating "address expired". The concept of expiration can also be applied to Lightning invoices. Overall, implementing an expiration mechanism is crucial to prevent fund loss and maintain the integrity of the Bitcoin system. By doing so, wallets can offer users a safer and more reliable experience. 2023-08-10T20:58:00+00:00 + The proposal suggests implementing an expiration field for silent payment addresses in Bitcoin wallets. This would prevent potential loss of funds by giving addresses a predetermined lifespan. The expiration field follows a custom compact encoding scheme that allows for different levels of granularity and maximum expiration periods. The byte length ranges from 1 to 8, with the number of usable bits increasing as the byte length increases. This flexibility ensures that various expiration periods, such as years and weeks, can be accommodated. One advantage of this encoding scheme is its ability to degrade cleanly over time, so it will continue to function properly even after many years of use. Block-based expiration is also included to enable compatibility with operations like OP_CLTV OP_VAULT_RECOVER or OP_CLTV OP_CHECKSIG.The context does not specify the reason behind the chosen 180-year limit, but it can be assumed that this timeframe is practical and avoids excessive speculation. However, there are arguments for extending the planning horizon beyond 180 years, especially for addressing long-term challenges like climate change and resource depletion. It is important to find a balance between short-term practicality and long-term vision when determining the planning horizon. The choice involves trade-offs and should consider the specific context and goals of decision-making processes.The email discusses the need for an expiration mechanism for silent payment addresses in Bitcoin wallets. It proposes using a period of 2^24 days, equivalent to 45,000 years or 2 bytes, allowing for an expiration period of 180 years. The email recommends setting a default expiration period of 1 year for newly created addresses and suggests that transactions to expired addresses should fail with a message stating "address expired". The concept of expiration can also be applied to Lightning invoices. Overall, implementing an expiration mechanism is crucial to prevent fund loss and maintain the integrity of the Bitcoin system. By doing so, wallets can offer users a safer and more reliable experience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin-AdamISZ-.xml b/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin-AdamISZ-.xml index 8f39561896..0077b20e48 100644 --- a/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin-AdamISZ-.xml +++ b/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin-AdamISZ-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP for Serverless Payjoin (AdamISZ) - 2023-08-13T01:53:08.723520+00:00 + 2025-09-26T14:27:42.358474+00:00 + python-feedgen Christopher Allen 2023-08-12 01:05:06+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP for Serverless Payjoin (AdamISZ) - 2023-08-13T01:53:08.723628+00:00 + 2025-09-26T14:27:42.358638+00:00 - The email discusses the interest in standardizing a protocol. The sender suggests using base64url encoding instead of base64 encoding for the psk in the URI to improve readability and avoid complexity. They express appreciation for feedback from "waxwing" and mention that they have resolved the mentioned flaws. The sender explains their decision to use a symmetric key over DH for receiver authentication to avoid additional communication rounds. They propose a solution to mitigate attacks by having the receiver share a public key of a per-request keypair. They mention the use of BIP 47 codes and ephemeral keys for enrolling multiple buffers at a relay simultaneously. The sender acknowledges the concern of relays having metadata that could be used for timing attacks and suggests a random delay based on a Poisson distribution as a mitigation. They refer to a research study by S. Ghesmati in 2020 which supports the idea of payjoin transactions. The sender expresses reluctance to require Tor for deployment and suggests considering Oblivious HTTP instead. They address the concern of timing correlation attacks and suggest a specified delay. The sender agrees that padding should be a requirement and discusses the buffer size, noting the overhead of PSBTs compared to consensus transactions. They thank the recipient, Dan, for the feedback. 2023-08-12T01:05:06+00:00 + The email discusses the interest in standardizing a protocol. The sender suggests using base64url encoding instead of base64 encoding for the psk in the URI to improve readability and avoid complexity. They express appreciation for feedback from "waxwing" and mention that they have resolved the mentioned flaws. The sender explains their decision to use a symmetric key over DH for receiver authentication to avoid additional communication rounds. They propose a solution to mitigate attacks by having the receiver share a public key of a per-request keypair. They mention the use of BIP 47 codes and ephemeral keys for enrolling multiple buffers at a relay simultaneously. The sender acknowledges the concern of relays having metadata that could be used for timing attacks and suggests a random delay based on a Poisson distribution as a mitigation. They refer to a research study by S. Ghesmati in 2020 which supports the idea of payjoin transactions. The sender expresses reluctance to require Tor for deployment and suggests considering Oblivious HTTP instead. They address the concern of timing correlation attacks and suggest a specified delay. The sender agrees that padding should be a requirement and discusses the buffer size, noting the overhead of PSBTs compared to consensus transactions. They thank the recipient, Dan, for the feedback. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin.xml b/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin.xml index 3c5630071f..6da50de69e 100644 --- a/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin.xml +++ b/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin.xml @@ -1,29 +1,35 @@ - + 2 Combined summary - BIP for Serverless Payjoin - 2023-08-14T01:52:59.170301+00:00 - - Dan Gould 2023-08-13 12:50:32+00:00 - - - Christopher Allen 2023-08-13 09:22:47+00:00 - - - David A. Harding 2023-08-13 06:58:29+00:00 - - - Dan Gould 2023-08-12 21:20:37+00:00 - - - AdamISZ 2023-08-10 15:46:18+00:00 - - - AdamISZ 2023-08-10 15:37:54+00:00 - - - Dan Gould 2023-08-09 17:32:54+00:00 - + 2025-09-26T14:27:33.823774+00:00 + python-feedgen + + + [bitcoin-dev] BIP for Serverless Payjoin Dan Gould + 2023-08-09T17:32:00.000Z + + + [bitcoin-dev] Fw: " AdamISZ + 2023-08-10T14:57:00.000Z + + + [bitcoin-dev] " AdamISZ + 2023-08-10T15:37:00.000Z + + + AdamISZ + 2023-08-10T15:46:00.000Z + + + David A. Harding + 2023-08-13T06:58:00.000Z + + + Dan Gould + 2023-08-13T12:50:00.000Z + + @@ -31,13 +37,13 @@ - python-feedgen + 2 Combined summary - BIP for Serverless Payjoin - 2023-08-14T01:52:59.170402+00:00 + 2025-09-26T14:27:33.824601+00:00 - The email discusses the adoption of a DH cryptosystem in the BIP 21 for Serverless Payjoin. It mentions the progress made in developing reference libraries and the use of URs in JavaScript wallets. Dave raises concerns about the security of posting payment URIs publicly, which could lead to session hijacking and modification of transactions. The suggestion is made to use Blockchain Commons UR as an elegant solution. The draft BIP is updated with suggestions for DH over symmetric crypto and encoding public keys directly in the `pj=` endpoint. The draft is posted on the BIPs repository. Concerns about timing correlation and metadata intersection in transactions are mentioned, and random padding is suggested to mitigate this issue. The email also suggests considering Diffie-Hellman key exchange and using anonymized network connections like Tor to address potential attack vectors. An update is provided on the progress of the Serverless Payjoin idea, including the specification of Payjoin version 2. Two proof of concept payjoin implementations using symmetric cryptography and asynchronous messaging are mentioned. The proposal aims to improve privacy in bitcoin transactions and increase transaction throughput. Details are provided on the protocol, messaging protocols, interactions with the Payjoin Relay, receiver enrollment, sender interactions, and fallback PSBT requests. The proposal discusses the implementation of BIP 78 and introduces PSBT Version 2. References to existing implementations and acknowledgments are included. 2023-08-13T12:50:32+00:00 + The email discusses the adoption of a DH cryptosystem in the BIP 21 for Serverless Payjoin. It mentions the progress made in developing reference libraries and the use of URs in JavaScript wallets. Dave raises concerns about the security of posting payment URIs publicly, which could lead to session hijacking and modification of transactions. The suggestion is made to use Blockchain Commons UR as an elegant solution. The draft BIP is updated with suggestions for DH over symmetric crypto and encoding public keys directly in the `pj=` endpoint. The draft is posted on the BIPs repository. Concerns about timing correlation and metadata intersection in transactions are mentioned, and random padding is suggested to mitigate this issue. The email also suggests considering Diffie-Hellman key exchange and using anonymized network connections like Tor to address potential attack vectors. An update is provided on the progress of the Serverless Payjoin idea, including the specification of Payjoin version 2. Two proof of concept payjoin implementations using symmetric cryptography and asynchronous messaging are mentioned. The proposal aims to improve privacy in bitcoin transactions and increase transaction throughput. Details are provided on the protocol, messaging protocols, interactions with the Payjoin Relay, receiver enrollment, sender interactions, and fallback PSBT requests. The proposal discusses the implementation of BIP 78 and introduces PSBT Version 2. References to existing implementations and acknowledgments are included. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Blinded-2-party-Musig2.xml b/static/bitcoin-dev/Aug_2023/combined_Blinded-2-party-Musig2.xml index f8b1848414..684c0d89b2 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Blinded-2-party-Musig2.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Blinded-2-party-Musig2.xml @@ -1,107 +1,147 @@ - + 2 Combined summary - Blinded 2-party Musig2 - 2023-08-31T01:55:43.561462+00:00 - - Tom Trevethan 2023-08-30 10:52:05+00:00 - - - Lloyd Fournier 2023-08-14 06:31:42+00:00 - - - Tom Trevethan 2023-08-10 11:59:52+00:00 - - - Lloyd Fournier 2023-08-10 03:30:02+00:00 - - - Tom Trevethan 2023-08-09 15:14:36+00:00 - - - moonsettler 2023-08-08 17:44:06+00:00 - - - Tom Trevethan 2023-08-07 00:55:38+00:00 - - - Jonas Nick 2023-07-27 08:07:58+00:00 - - - AdamISZ 2023-07-27 05:51:14+00:00 - - - Lloyd Fournier 2023-07-27 02:54:17+00:00 - - - Erik Aronesty 2023-07-26 22:06:44+00:00 - - - Tom Trevethan 2023-07-26 20:35:00+00:00 - - - Jonas Nick 2023-07-26 19:59:26+00:00 - - - moonsettler 2023-07-26 19:28:50+00:00 - - - AdamISZ 2023-07-26 19:19:44+00:00 - - - Andrew Poelstra 2023-07-26 17:40:26+00:00 - - - Tom Trevethan 2023-07-26 16:32:06+00:00 - - - Jonas Nick 2023-07-26 14:59:42+00:00 - - - moonsettler 2023-07-26 09:44:50+00:00 - - - Erik Aronesty 2023-07-26 04:09:41+00:00 - - - Tom Trevethan 2023-07-25 16:05:48+00:00 - - - Erik Aronesty 2023-07-25 14:12:31+00:00 - - - AdamISZ 2023-07-24 16:51:44+00:00 - - - Tom Trevethan 2023-07-24 16:22:15+00:00 - - - Tom Trevethan 2023-07-24 16:08:28+00:00 - - - Tom Trevethan 2023-07-24 15:57:41+00:00 - - - Jonas Nick 2023-07-24 15:40:16+00:00 - - - Jonas Nick 2023-07-24 15:39:09+00:00 - - - Erik Aronesty 2023-07-24 14:40:10+00:00 - - - Erik Aronesty 2023-07-24 14:25:00+00:00 - - - Jonas Nick 2023-07-24 14:12:47+00:00 - - - ZmnSCPxj 2023-07-24 10:50:13+00:00 - - - Tom Trevethan 2023-07-24 07:46:11+00:00 - + 2025-09-26T14:27:23.119877+00:00 + python-feedgen + + + [bitcoin-dev] Blinded 2-party Musig2 Tom Trevethan + 2023-07-24T07:46:00.000Z + + + ZmnSCPxj + 2023-07-24T10:50:00.000Z + + + Jonas Nick + 2023-07-24T14:12:00.000Z + + + Erik Aronesty + 2023-07-24T14:25:00.000Z + + + Erik Aronesty + 2023-07-24T14:40:00.000Z + + + Jonas Nick + 2023-07-24T15:39:00.000Z + + + Jonas Nick + 2023-07-24T15:40:00.000Z + + + Tom Trevethan + 2023-07-24T15:57:00.000Z + + + Tom Trevethan + 2023-07-24T16:08:00.000Z + + + Tom Trevethan + 2023-07-24T16:22:00.000Z + + + AdamISZ + 2023-07-24T16:51:00.000Z + + + Erik Aronesty + 2023-07-25T14:12:00.000Z + + + Tom Trevethan + 2023-07-25T16:05:00.000Z + + + Erik Aronesty + 2023-07-26T04:09:00.000Z + + + moonsettler + 2023-07-26T09:44:00.000Z + + + Jonas Nick + 2023-07-26T14:59:00.000Z + + + Tom Trevethan + 2023-07-26T16:32:00.000Z + + + Andrew Poelstra + 2023-07-26T17:40:00.000Z + + + AdamISZ + 2023-07-26T19:19:00.000Z + + + moonsettler + 2023-07-26T19:28:00.000Z + + + Jonas Nick + 2023-07-26T19:59:00.000Z + + + Tom Trevethan + 2023-07-26T20:35:00.000Z + + + Erik Aronesty + 2023-07-26T22:06:00.000Z + + + Lloyd Fournier + 2023-07-27T02:54:00.000Z + + + AdamISZ + 2023-07-27T05:51:00.000Z + + + Jonas Nick + 2023-07-27T08:07:00.000Z + + + [bitcoin-dev] Fwd: " Tom Trevethan + 2023-07-27T13:25:00.000Z + + + [bitcoin-dev] " Tom Trevethan + 2023-08-07T00:55:00.000Z + + + moonsettler + 2023-08-08T17:44:00.000Z + + + Tom Trevethan + 2023-08-09T15:14:00.000Z + + + Lloyd Fournier + 2023-08-10T03:30:00.000Z + + + Tom Trevethan + 2023-08-10T11:59:00.000Z + + + Lloyd Fournier + 2023-08-14T06:31:00.000Z + + + Tom Trevethan + 2023-08-30T10:52:00.000Z + + @@ -135,13 +175,13 @@ - python-feedgen + 2 Combined summary - Blinded 2-party Musig2 - 2023-08-31T01:55:43.561756+00:00 + 2025-09-26T14:27:23.123366+00:00 - The email discusses the limitations and challenges associated with using Proof of Secret Key (POSK) in the MuSig protocol. It highlights the difficulty of producing POSKs in various contexts and the lack of an established key serialization format for them. The email also mentions the difficulties in publishing POSKs. The email discusses the use of MuSig1 and MuSig2 for avoiding signature forgery and blinding challenges in the signing process. It suggests integrating a "proof of secret key" (posk) into low-level protocols to prevent vulnerabilities. The email raises concerns about the proposed solution not addressing the issue of client-controlled challenge e' and proposes exploring alternative approaches such as commitments and Zero-Knowledge Proofs (ZKPs). The email further discusses the v=2 nonces signing protocol of musig2 and emphasizes the need to blind the challenge value c for confidentiality. It outlines the steps involved in the Keygen and Signing processes and suggests a verification process for statecoin transfers. Additionally, the email addresses concerns about party 1 not learning the final values of (R, s1+s2) or m and proposes an additional step for the server to obtain necessary information without compromising security. The email suggests that all parties involved in a transaction should provide a proof of secret key along with their public key to ensure security. It highlights potential vulnerabilities in a proposed scheme for blind music and the effectiveness of MuSig2 in preventing certain attacks. In conclusion, the email provides a detailed summary of the discussions around blinding challenges and signature forgery in the context of MuSig1 and MuSig2 protocols. It emphasizes the importance of integrating posk, blinding values, and implementing secure verification processes to enhance security in statecoin transfers. 2023-08-30T10:52:05+00:00 + The email discusses the limitations and challenges associated with using Proof of Secret Key (POSK) in the MuSig protocol. It highlights the difficulty of producing POSKs in various contexts and the lack of an established key serialization format for them. The email also mentions the difficulties in publishing POSKs. The email discusses the use of MuSig1 and MuSig2 for avoiding signature forgery and blinding challenges in the signing process. It suggests integrating a "proof of secret key" (posk) into low-level protocols to prevent vulnerabilities. The email raises concerns about the proposed solution not addressing the issue of client-controlled challenge e' and proposes exploring alternative approaches such as commitments and Zero-Knowledge Proofs (ZKPs). The email further discusses the v=2 nonces signing protocol of musig2 and emphasizes the need to blind the challenge value c for confidentiality. It outlines the steps involved in the Keygen and Signing processes and suggests a verification process for statecoin transfers. Additionally, the email addresses concerns about party 1 not learning the final values of (R, s1+s2) or m and proposes an additional step for the server to obtain necessary information without compromising security. The email suggests that all parties involved in a transaction should provide a proof of secret key along with their public key to ensure security. It highlights potential vulnerabilities in a proposed scheme for blind music and the effectiveness of MuSig2 in preventing certain attacks. In conclusion, the email provides a detailed summary of the discussions around blinding challenges and signature forgery in the context of MuSig1 and MuSig2 protocols. It emphasizes the importance of integrating posk, blinding values, and implementing secure verification processes to enhance security in statecoin transfers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Combined-CTV-APO-to-minimal-TXHASH-CSFS.xml b/static/bitcoin-dev/Aug_2023/combined_Combined-CTV-APO-to-minimal-TXHASH-CSFS.xml index 1bd025c261..7979f19c1b 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Combined-CTV-APO-to-minimal-TXHASH-CSFS.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Combined-CTV-APO-to-minimal-TXHASH-CSFS.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Combined CTV+APO to minimal TXHASH+CSFS - 2023-08-24T01:52:55.046913+00:00 - - Brandon Black 2023-08-22 20:23:09+00:00 - - - Greg Sanders 2023-08-22 19:22:18+00:00 - - - Brandon Black 2023-08-22 19:08:36+00:00 - - - Brandon Black 2023-08-22 17:04:38+00:00 - + 2025-09-26T14:27:38.098737+00:00 + python-feedgen + + + [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS Brandon Black + 2023-08-22T17:04:00.000Z + + + Brandon Black + 2023-08-22T19:08:00.000Z + + + Greg Sanders + 2023-08-22T19:22:00.000Z + + + Brandon Black + 2023-08-22T20:23:00.000Z + + - python-feedgen + 2 Combined summary - Combined CTV+APO to minimal TXHASH+CSFS - 2023-08-24T01:52:55.046980+00:00 + 2025-09-26T14:27:38.099416+00:00 - In this email exchange, Greg provides additional information related to a previous conversation with Brandon. He suggests replacing the term "OP_2" with "OP_4" and mentions that BIP118 allows for the use of the pubkey "1" as a substitute for the taproot inner pubkey. Greg proposes adding an opcode called "OP_INNER_PUBKEY" to achieve the same effect. He also highlights that BIP118 addresses taproot malleability bugs by allowing non-APO signatures to have a sighash digest that commits to additional data.Greg includes a link to a discussion on GitHub for further exploration of this topic. He acknowledges that these details are not crucial but suggests addressing them if possible.In another email, Brandon provides a quick update to his proposal based on feedback from James O'Beirne. He states that CTV is less expensive than previously thought when used alone. He clarifies that script success requires exactly "OP_TRUE" instead of just a CastToBool()=true value on the stack. This means that his proposal is slightly larger than CTV when both are used in Tapscript.Brandon then presents a proposal that combines the functionality of bip118 and bip119 while addressing objections and providing clear upgrade paths. The aim of this proposal is to clarify the similarities and differences between the two proposals and promote consensus through discussion.The proposal introduces three new Tapscript-only opcodes: OP_TXHASH, OP_CHECKSIGFROMSTACK, and OP_CHECKSIGFROMSTACKVERIFY. These opcodes replace existing opcodes and provide different hashing and signature checking behaviors depending on the arguments popped from the stack.The motivation behind this proposal is to address objections to bip118 and bip119 and provide a more general solution. Objections to bip119 include it not being general enough, inefficiency when validating the hash, and using extension semantics instead of available OP_SUCCESSx. Objections to bip118 include it not being general enough, enabling inefficient and hard-to-use covenants accidentally, and requiring a new Tapscript key version for safety.The proposal aims to provide the behavior of both bip118 and bip119, offer explicit upgrade hooks for further generality, split the hashing from the validation in bip119, enable some sighash-based covenants accidentally enabled by bip118, and use new signature checking opcodes without requiring a new Tapscript key version.The specification of the proposal defines the behavior of OP_TXHASH and OP_CHECKSIGFROMSTACK(VERIFY) in Tapscript validation. OP_TXHASH hashes the transaction based on a minimally encoded numeric argument popped from the stack, while OP_CHECKSIGFROMSTACK(VERIFY) verifies a signature against a message and public key according to bip340.The email also discusses the efficiency of this proposal compared to bip118 and bip119 in terms of witness bytes. Examples and calculations are provided for different scenarios, and it is concluded that this proposal may be slightly more costly than bare CTV but offers compatibility with ln-symmetry, PTLCs, and OP_VAULT.The email concludes with a discussion on the fields that are hashed in different modes of the proposal and mentions some notes related to validation and signature lengths. Brandon seeks feedback on this proposal and aims to contribute to the discussion on bitcoin script development, specifically regarding bip118 and bip119. 2023-08-22T20:23:09+00:00 + In this email exchange, Greg provides additional information related to a previous conversation with Brandon. He suggests replacing the term "OP_2" with "OP_4" and mentions that BIP118 allows for the use of the pubkey "1" as a substitute for the taproot inner pubkey. Greg proposes adding an opcode called "OP_INNER_PUBKEY" to achieve the same effect. He also highlights that BIP118 addresses taproot malleability bugs by allowing non-APO signatures to have a sighash digest that commits to additional data.Greg includes a link to a discussion on GitHub for further exploration of this topic. He acknowledges that these details are not crucial but suggests addressing them if possible.In another email, Brandon provides a quick update to his proposal based on feedback from James O'Beirne. He states that CTV is less expensive than previously thought when used alone. He clarifies that script success requires exactly "OP_TRUE" instead of just a CastToBool()=true value on the stack. This means that his proposal is slightly larger than CTV when both are used in Tapscript.Brandon then presents a proposal that combines the functionality of bip118 and bip119 while addressing objections and providing clear upgrade paths. The aim of this proposal is to clarify the similarities and differences between the two proposals and promote consensus through discussion.The proposal introduces three new Tapscript-only opcodes: OP_TXHASH, OP_CHECKSIGFROMSTACK, and OP_CHECKSIGFROMSTACKVERIFY. These opcodes replace existing opcodes and provide different hashing and signature checking behaviors depending on the arguments popped from the stack.The motivation behind this proposal is to address objections to bip118 and bip119 and provide a more general solution. Objections to bip119 include it not being general enough, inefficiency when validating the hash, and using extension semantics instead of available OP_SUCCESSx. Objections to bip118 include it not being general enough, enabling inefficient and hard-to-use covenants accidentally, and requiring a new Tapscript key version for safety.The proposal aims to provide the behavior of both bip118 and bip119, offer explicit upgrade hooks for further generality, split the hashing from the validation in bip119, enable some sighash-based covenants accidentally enabled by bip118, and use new signature checking opcodes without requiring a new Tapscript key version.The specification of the proposal defines the behavior of OP_TXHASH and OP_CHECKSIGFROMSTACK(VERIFY) in Tapscript validation. OP_TXHASH hashes the transaction based on a minimally encoded numeric argument popped from the stack, while OP_CHECKSIGFROMSTACK(VERIFY) verifies a signature against a message and public key according to bip340.The email also discusses the efficiency of this proposal compared to bip118 and bip119 in terms of witness bytes. Examples and calculations are provided for different scenarios, and it is concluded that this proposal may be slightly more costly than bare CTV but offers compatibility with ln-symmetry, PTLCs, and OP_VAULT.The email concludes with a discussion on the fields that are hashed in different modes of the proposal and mentions some notes related to validation and signature lengths. Brandon seeks feedback on this proposal and aims to contribute to the discussion on bitcoin script development, specifically regarding bip118 and bip119. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Compressed-Bitcoin-Transactions.xml b/static/bitcoin-dev/Aug_2023/combined_Compressed-Bitcoin-Transactions.xml index 4750f6e120..977be7c334 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Compressed-Bitcoin-Transactions.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Compressed-Bitcoin-Transactions.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Compressed Bitcoin Transactions - 2024-01-24T02:03:56.249090+00:00 - - Tom Briar 2024-01-19 21:09:35+00:00 - - - Jonas Schnelli 2024-01-18 09:24:02+00:00 - - - Tom Briar 2024-01-16 17:08:54+00:00 - - - Tom Briar 2024-01-09 15:31:37+00:00 - - - Andrew Poelstra 2024-01-05 15:19:31+00:00 - - - Tom Briar 2024-01-05 15:06:01+00:00 - - - Tom Briar 2023-09-05 18:30:42+00:00 - - - Peter Todd 2023-09-05 18:00:33+00:00 - - - Tom Briar 2023-09-01 17:05:17+00:00 - - - Jonas Schnelli 2023-09-01 16:56:22+00:00 - - - Tom Briar 2023-09-01 14:12:09+00:00 - - - Andrew Poelstra 2023-09-01 13:56:18+00:00 - - - Fabian 2023-09-01 10:43:26+00:00 - - - Fabian 2023-09-01 10:24:54+00:00 - - - Andrew Poelstra 2023-09-01 00:49:36+00:00 - - - Tom Briar 2023-08-31 21:30:16+00:00 - + 2025-09-26T14:27:18.854751+00:00 + python-feedgen + + + [bitcoin-dev] Compressed Bitcoin Transactions Tom Briar + 2023-08-31T21:30:00.000Z + + + Andrew Poelstra + 2023-09-01T00:49:00.000Z + + + Fabian + 2023-09-01T10:24:00.000Z + + + Fabian + 2023-09-01T10:43:00.000Z + + + Andrew Poelstra + 2023-09-01T13:56:00.000Z + + + Tom Briar + 2023-09-01T14:12:00.000Z + + + Jonas Schnelli + 2023-09-01T16:56:00.000Z + + + Tom Briar + 2023-09-01T17:05:00.000Z + + + Peter Todd + 2023-09-05T18:00:00.000Z + + + Tom Briar + 2023-09-05T18:30:00.000Z + + + Tom Briar + 2024-01-05T15:06:00.000Z + + + Andrew Poelstra + 2024-01-05T15:19:00.000Z + + + Tom Briar + 2024-01-09T15:31:00.000Z + + + Tom Briar + 2024-01-16T17:08:00.000Z + + + Jonas Schnelli + 2024-01-18T09:24:00.000Z + + + Tom Briar + 2024-01-19T21:09:00.000Z + + @@ -67,21 +86,17 @@ - python-feedgen + 2 Combined summary - Compressed Bitcoin Transactions - 2024-01-24T02:03:56.249206+00:00 + 2025-09-26T14:27:18.856495+00:00 + 2024-01-19T21:09:35+00:00 Tom's communication focuses on the development of data compression strategies for Bitcoin transactions, specifically targeting peer-to-peer encrypted traffic. He highlights that traditional compression tools like gzip are not efficient for compressing Bitcoin transactions due to their inability to handle pseudorandom data effectively. Instead, Tom suggests removing redundant elements such as hashes and public keys, which can be regenerated after decompression, to achieve significant size reductions. - He also emphasizes the necessity for application-layer solutions for version 2 encrypted P2P traffic, contrasting it with the OSI model layer adjustments suitable for non-encrypted version 1 traffic. A specific compression proposal at the application layer is scrutinized for its potential to enhance space savings without requiring substantial CPU resources, facilitating quicker block propagation throughout the network. These technical discussions continue on GitHub for a deeper evaluation of this approach. - The Compressed Transaction Schema, conceived by Tom Briar and Andrew Poelstra, is introduced as a technique to decrease transaction sizes within the Bitcoin network by up to 30%, particularly useful under BIP-324. The schema innovates by excluding optional components and introducing new formats such as relative block height and compressed inputs. It is especially beneficial in scenarios with limited bandwidth but sufficient processing power for decompression. Four methods are proposed to optimize compression, though one may complicate decompression in the event of block reorganizations. Details on this schema, including test vectors and performance examples, can be found in the documentation accessible via [this link](https://github.com/TomBriar/bitcoin/blob/2023-05--tx-compression/doc/compressed_transactions.md). - In practice, integrating this schema into Bitcoin Core requires balancing transaction size optimization with decompression time. Alternatives for handling lock time are discussed to conserve bytes, and a method involving encoding transaction outputs with a delta relative to a reference height is considered. Tom responds to feedback from Jonas and Fabian, noting efforts to gather empirical data and introducing a new RPC endpoint to monitor transaction age for compression eligibility. Clear guidelines in BIP documentation are emphasized to mitigate risks during blockchain reorganizations. - Fabian proposes future exploration of a sorted UTXO set index to save space and suggests alternatives for UTXO indexing, while Andrew requests a chart to illustrate the compression strength of specific transaction types. Tom has taken an active role in developing a compression schema for Bitcoin transactions, maintaining transaction integrity while optimizing for efficiency and security. He has made strides in implementing his schema, indicative of ongoing innovation in transaction processing. - 2024-01-19T21:09:35+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-.xml b/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-.xml index ac3c020c9d..c74a2acb1c 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Concern about "Inscriptions" - 2023-09-07T01:54:05.383093+00:00 + Combined summary - Concern about "Inscriptions" + 2025-09-26T14:27:27.419078+00:00 + python-feedgen vjudeu at gazeta.pl 2023-09-06 08:00:53+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 - Combined summary - Concern about "Inscriptions" - 2023-09-07T01:54:05.383222+00:00 + Combined summary - Concern about "Inscriptions" + 2025-09-26T14:27:27.419263+00:00 - The email thread discusses the concept of cut-through transactions in the Bitcoin blockchain. Cut-through involves removing inscriptions from transaction chains while preserving the payment information. It is argued that cut-through is useful for scaling when there are only a few transactions, but it becomes less efficient when all transactions need to be included. The idea of implementing cut-through is seen as a natural consequence of enabling full Replace-By-Fee (RBF) transactions, which would lead to mempool-level batching.The discussion also revolves around the impact of cut-through on inscriptions. While cut-through can prove transaction chains using cryptography, it does not eliminate the presence of transactions in the blockchain. Full archival nodes still contain all the inscription data and can provide it to those who need it. It is compared to running pruned nodes in Bitcoin, where some nodes do not store all the data but can still access it from full archival nodes.Another topic brought up in the email thread is the suggestion of reducing the blocksize limit to address concerns about blockchain size increases and promote activity on the lightning network. It is proposed that the blocksize limit may have been increased unnecessarily in the past, and now it is worth considering a smaller blocksize to encourage more usage of the lightning network. The lightning network is seen as a potential solution to handle increased transaction volume while minimizing the growth of the blockchain.Inefficiencies and costs related to proof-of-secret-key schemes are also discussed. It is mentioned that reusing k values in ECDSA allows for data encoding in both k and the entire secret key, which can be exploited for encoding data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging and expensive.The email thread includes discussions on various topics related to the Bitcoin protocol. One of these topics involves adding a proof-of-work requirement to a public key on an open relay server protocol to deter spammers or scammers. The difficulty of embedding information in a public key is mentioned, particularly when considering the need for mobile devices to generate keys quickly.The email also touches on the issue of Bitcoin script exploits and vulnerabilities caused by the insertion of arbitrary data. Two strategies, Ordisrespector and Ordislow, are proposed as potential solutions to address these vulnerabilities. Ordisrespector allows node operators to opt-in to a self-defense mechanism against aggression via inserted arbitrary data, while Ordislow increases the coercion cost of mining entities relative to cooperation cost by delaying block propagation and requiring inserted arbitrary data in blocks.The inefficiency and costliness of proof-of-secret-key schemes are highlighted, with examples of how ECDSA can be exploited to encode data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging.The email thread also delves into the topic of inscription attacks and spam prevention in the Mimblewimble protocol. It is noted that range proofs in the protocol already prove knowledge of blinding factors in Pedersen commitments, eliminating the need for additional padding to prevent the encoding of spam. Pure Mimblewimble blockchains are seen as highly resistant to inscription and spam attacks.There is a mention of a project called STAMPS that embeds image data in multisig outputs, which increases the size of the UTXO set compared to other methods. Pay-to-Contact protocols are suggested as a way to tweak a pubkey with a small blob of data, allowing for the production of a signature proving knowledge of the private key.The email raises concerns about banning arbitrary data in programming and its consequences. It is argued that if arbitrary data is banned, actors will find ways to encode their data within sets of public keys. Public key data is indistinguishable from random data, making it difficult to determine if a given public key is used for encoding data or serving its intended purpose. Examples of how governments attempt to censor internet protocols and users adapt by tunneling their data through innocent-looking channels are mentioned.The email also mentions the ongoing struggle between decentralization and centralization in the Bitcoin system. It is suggested that incrementing the cost of operating a regular Bitcoin node could lead to reduced network decentralization and vulnerability to central entity control. The central entity does not necessarily have to be a government.Overall, the email thread covers various discussions related to block sizes, blockchain size increases, lightning network usage, proof-of-secret-key schemes, inscription attacks, spam prevention, and the struggle between decentralization and centralization in the Bitcoin system. 2023-09-06T08:00:53+00:00 + The email thread discusses the concept of cut-through transactions in the Bitcoin blockchain. Cut-through involves removing inscriptions from transaction chains while preserving the payment information. It is argued that cut-through is useful for scaling when there are only a few transactions, but it becomes less efficient when all transactions need to be included. The idea of implementing cut-through is seen as a natural consequence of enabling full Replace-By-Fee (RBF) transactions, which would lead to mempool-level batching.The discussion also revolves around the impact of cut-through on inscriptions. While cut-through can prove transaction chains using cryptography, it does not eliminate the presence of transactions in the blockchain. Full archival nodes still contain all the inscription data and can provide it to those who need it. It is compared to running pruned nodes in Bitcoin, where some nodes do not store all the data but can still access it from full archival nodes.Another topic brought up in the email thread is the suggestion of reducing the blocksize limit to address concerns about blockchain size increases and promote activity on the lightning network. It is proposed that the blocksize limit may have been increased unnecessarily in the past, and now it is worth considering a smaller blocksize to encourage more usage of the lightning network. The lightning network is seen as a potential solution to handle increased transaction volume while minimizing the growth of the blockchain.Inefficiencies and costs related to proof-of-secret-key schemes are also discussed. It is mentioned that reusing k values in ECDSA allows for data encoding in both k and the entire secret key, which can be exploited for encoding data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging and expensive.The email thread includes discussions on various topics related to the Bitcoin protocol. One of these topics involves adding a proof-of-work requirement to a public key on an open relay server protocol to deter spammers or scammers. The difficulty of embedding information in a public key is mentioned, particularly when considering the need for mobile devices to generate keys quickly.The email also touches on the issue of Bitcoin script exploits and vulnerabilities caused by the insertion of arbitrary data. Two strategies, Ordisrespector and Ordislow, are proposed as potential solutions to address these vulnerabilities. Ordisrespector allows node operators to opt-in to a self-defense mechanism against aggression via inserted arbitrary data, while Ordislow increases the coercion cost of mining entities relative to cooperation cost by delaying block propagation and requiring inserted arbitrary data in blocks.The inefficiency and costliness of proof-of-secret-key schemes are highlighted, with examples of how ECDSA can be exploited to encode data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging.The email thread also delves into the topic of inscription attacks and spam prevention in the Mimblewimble protocol. It is noted that range proofs in the protocol already prove knowledge of blinding factors in Pedersen commitments, eliminating the need for additional padding to prevent the encoding of spam. Pure Mimblewimble blockchains are seen as highly resistant to inscription and spam attacks.There is a mention of a project called STAMPS that embeds image data in multisig outputs, which increases the size of the UTXO set compared to other methods. Pay-to-Contact protocols are suggested as a way to tweak a pubkey with a small blob of data, allowing for the production of a signature proving knowledge of the private key.The email raises concerns about banning arbitrary data in programming and its consequences. It is argued that if arbitrary data is banned, actors will find ways to encode their data within sets of public keys. Public key data is indistinguishable from random data, making it difficult to determine if a given public key is used for encoding data or serving its intended purpose. Examples of how governments attempt to censor internet protocols and users adapt by tunneling their data through innocent-looking channels are mentioned.The email also mentions the ongoing struggle between decentralization and centralization in the Bitcoin system. It is suggested that incrementing the cost of operating a regular Bitcoin node could lead to reduced network decentralization and vulnerability to central entity control. The central entity does not necessarily have to be a government.Overall, the email thread covers various discussions related to block sizes, blockchain size increases, lightning network usage, proof-of-secret-key schemes, inscription attacks, spam prevention, and the struggle between decentralization and centralization in the Bitcoin system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml b/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml index 2fd86c47e5..f73ea10f85 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Concern about "Inscriptions". (ashneverdawn) - 2023-08-11T15:43:37.028667+00:00 + Combined summary - Concern about "Inscriptions". (ashneverdawn) + 2025-09-26T14:27:12.431601+00:00 + python-feedgen Keagan McClelland 2023-08-02 05:58:53+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 - Combined summary - Concern about "Inscriptions". (ashneverdawn) - 2023-08-11T15:43:37.028667+00:00 + Combined summary - Concern about "Inscriptions". (ashneverdawn) + 2025-09-26T14:27:12.431778+00:00 - The debate revolves around introducing a pricing mechanism for space in the Unspent Transaction Output (UTXO) set. Currently, the UTXO set space is not priced, which causes uncertainty in classifying transactions as spam or legitimate. The UTXO set must be maintained by all nodes, including pruned nodes, making it more valuable than chain space. Introducing a pricing mechanism may lead to inscriptions disappearing as users would have to pay for their usage. However, this proposition may be controversial and offensive to some Bitcoin users. Pricing space in the UTXO set remains an open discussion. It is argued that differentiating transaction types on the network should not be done for privacy and censorship resistance. Limited blockchain resources should go to the highest bidder, based on the value they provide to the marketplace against the cost to the network. The growth rate of the blockchain is not caused by Ordinals, but rather by the limit on storage that can be added per block. 2023-08-02T05:58:53+00:00 + The debate revolves around introducing a pricing mechanism for space in the Unspent Transaction Output (UTXO) set. Currently, the UTXO set space is not priced, which causes uncertainty in classifying transactions as spam or legitimate. The UTXO set must be maintained by all nodes, including pruned nodes, making it more valuable than chain space. Introducing a pricing mechanism may lead to inscriptions disappearing as users would have to pay for their usage. However, this proposition may be controversial and offensive to some Bitcoin users. Pricing space in the UTXO set remains an open discussion. It is argued that differentiating transaction types on the network should not be done for privacy and censorship resistance. Limited blockchain resources should go to the highest bidder, based on the value they provide to the marketplace against the cost to the network. The growth rate of the blockchain is not caused by Ordinals, but rather by the limit on storage that can be added per block. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Concrete-MATT-opcodes.xml b/static/bitcoin-dev/Aug_2023/combined_Concrete-MATT-opcodes.xml index b3fd1b2ce6..d77111f1e2 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Concrete-MATT-opcodes.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Concrete-MATT-opcodes.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Concrete MATT opcodes - 2023-09-16T01:51:28.673509+00:00 - - Antoine Riard 2023-09-15 00:23:31+00:00 - - - Antoine Riard 2023-09-13 20:25:07+00:00 - - - symphonicbtc 2023-08-19 23:11:22+00:00 - - - Antoine Riard 2023-08-18 20:12:09+00:00 - - - Salvatore Ingala 2023-08-18 15:08:39+00:00 - - - symphonicbtc 2023-08-14 14:07:19+00:00 - - - Antoine Riard 2023-08-14 03:00:57+00:00 - - - Salvatore Ingala 2023-08-09 08:38:48+00:00 - - - Johan Torås Halseth 2023-08-07 11:37:07+00:00 - - - Salvatore Ingala 2023-08-07 08:31:40+00:00 - - - David A. Harding 2023-08-06 20:13:25+00:00 - - - Salvatore Ingala 2023-07-30 21:37:49+00:00 - + 2025-09-26T14:27:16.695969+00:00 + python-feedgen + + + [bitcoin-dev] Concrete MATT opcodes Salvatore Ingala + 2023-07-30T21:37:00.000Z + + + David A. Harding + 2023-08-06T20:13:00.000Z + + + Salvatore Ingala + 2023-08-07T08:31:00.000Z + + + Johan Torås Halseth + 2023-08-07T11:37:00.000Z + + + Salvatore Ingala + 2023-08-09T08:38:00.000Z + + + Antoine Riard + 2023-08-14T03:00:00.000Z + + + symphonicbtc + 2023-08-14T14:07:00.000Z + + + Salvatore Ingala + 2023-08-18T15:08:00.000Z + + + Antoine Riard + 2023-08-18T20:12:00.000Z + + + symphonicbtc + 2023-08-19T23:11:00.000Z + + + Antoine Riard + 2023-09-13T20:25:00.000Z + + + Antoine Riard + 2023-09-15T00:23:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Concrete MATT opcodes - 2023-09-16T01:51:28.673620+00:00 + 2025-09-26T14:27:16.697388+00:00 - Salvatore Ingala has presented a proposal for the core opcodes of MATT, including revisions and improvements to the implementation. The code is implemented in the bitcoin-inquisition repository fork, along with OP_CHECKTEMPLATEVERIFY. The changes made include replacing OP_CHECK{IN, OUT}CONTRACTVERIFY with a single opcode called OP_CHECKCONTRACTVERIFY (CCV) and introducing an additional `flags` parameter. The order of parameters has also been modified for better script writing. Various flags are defined, such as CCV_FLAG_CHECK_INPUT and CCV_FLAG_IGNORE_OUTPUT_AMOUNT. Special values are defined for certain parameters. The email emphasizes the flexibility and generality achieved with the new opcode, but acknowledges the potential benefits of additional opcodes and introspection. The email includes several references, including a website mentioning OP_CHECKCONTRACTVERIFY, a mailing list post discussing the MATT proposal, and a GitHub repository with the code implementation. 2023-09-15T00:23:31+00:00 + Salvatore Ingala has presented a proposal for the core opcodes of MATT, including revisions and improvements to the implementation. The code is implemented in the bitcoin-inquisition repository fork, along with OP_CHECKTEMPLATEVERIFY. The changes made include replacing OP_CHECK{IN, OUT}CONTRACTVERIFY with a single opcode called OP_CHECKCONTRACTVERIFY (CCV) and introducing an additional `flags` parameter. The order of parameters has also been modified for better script writing. Various flags are defined, such as CCV_FLAG_CHECK_INPUT and CCV_FLAG_IGNORE_OUTPUT_AMOUNT. Special values are defined for certain parameters. The email emphasizes the flexibility and generality achieved with the new opcode, but acknowledges the potential benefits of additional opcodes and introspection. The email includes several references, including a website mentioning OP_CHECKCONTRACTVERIFY, a mailing list post discussing the MATT proposal, and a GitHub repository with the code implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Full-RBF-testing-at-least-31-of-hash-power-over-at-least-4-pools-is-mining-full-RBF-right-now.xml b/static/bitcoin-dev/Aug_2023/combined_Full-RBF-testing-at-least-31-of-hash-power-over-at-least-4-pools-is-mining-full-RBF-right-now.xml index a31e79db75..0837f5005a 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Full-RBF-testing-at-least-31-of-hash-power-over-at-least-4-pools-is-mining-full-RBF-right-now.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Full-RBF-testing-at-least-31-of-hash-power-over-at-least-4-pools-is-mining-full-RBF-right-now.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now - 2023-08-17T01:50:08.091099+00:00 + 2025-09-26T14:27:29.564791+00:00 + python-feedgen Peter Todd 2023-08-16 14:02:41+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now - 2023-08-17T01:50:08.091155+00:00 + 2025-09-26T14:27:29.564938+00:00 - The email provides an update on the testing of high-fee full-RBF (Replace-by-Fee) adoption. The sender has been conducting tests by sending a high fee transaction (tx1) followed by a double spend (tx2) with an even higher fee, removing one of tx1's outputs. The propagation of each full-RBF double-spend was verified by checking the debug.log on another well-connected node.The results show that over 31% of hash power, from at least 4 different pools, is currently mining full-RBF. This finding confirms the sender's previous research based on the OTS (One-Time-Signature) calendar. The sender successfully performed full-RBF double-spends on multiple pools, including Antpool, Poolin, EMCDPool, and Binance Pool.To verify these double-spends, anyone running a full-RBF node with debug=mempool can examine their debug.log files. It is likely that Antpool, Poolin, and EMCDPool are mining full-RBF with close to 100% of their hash power, as they mined every double-spend available to them. Binance Pool, however, did not mine a full-RBF replacement on two occasions, suggesting they may be mining full-RBF with less than 100% of their hash power.In addition to the mentioned pools, KuCoinPool and ULTIMUSPOOL were found to be mining full-RBF double-spends in the sender's earlier OTS research. No data was obtained on them during this specific testing. Luxor and MARA Pool also mined blocks without mining the double-spends, indicating that they may have full-RBF fully or partially disabled.The sender provides a link to the tool used for these tests, cautioning that it was written years ago and may have bugs. The tool can be found at: https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.pyThe email concludes by mentioning the probability of success in a naive high-fee/higher-fee double-spend and highlights that research like this is time-consuming and expensive. Donations are appreciated, and the sender provides options for donating via Lightning or on-chain transactions.References:1) https://github.com/bitcoin/bitcoin/pull/281322) https://petertodd.orgDonation addresses: Lightning - https://stacker.news/petertodd, On-chain - 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv 2023-08-16T14:02:41+00:00 + The email provides an update on the testing of high-fee full-RBF (Replace-by-Fee) adoption. The sender has been conducting tests by sending a high fee transaction (tx1) followed by a double spend (tx2) with an even higher fee, removing one of tx1's outputs. The propagation of each full-RBF double-spend was verified by checking the debug.log on another well-connected node.The results show that over 31% of hash power, from at least 4 different pools, is currently mining full-RBF. This finding confirms the sender's previous research based on the OTS (One-Time-Signature) calendar. The sender successfully performed full-RBF double-spends on multiple pools, including Antpool, Poolin, EMCDPool, and Binance Pool.To verify these double-spends, anyone running a full-RBF node with debug=mempool can examine their debug.log files. It is likely that Antpool, Poolin, and EMCDPool are mining full-RBF with close to 100% of their hash power, as they mined every double-spend available to them. Binance Pool, however, did not mine a full-RBF replacement on two occasions, suggesting they may be mining full-RBF with less than 100% of their hash power.In addition to the mentioned pools, KuCoinPool and ULTIMUSPOOL were found to be mining full-RBF double-spends in the sender's earlier OTS research. No data was obtained on them during this specific testing. Luxor and MARA Pool also mined blocks without mining the double-spends, indicating that they may have full-RBF fully or partially disabled.The sender provides a link to the tool used for these tests, cautioning that it was written years ago and may have bugs. The tool can be found at: https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.pyThe email concludes by mentioning the probability of success in a naive high-fee/higher-fee double-spend and highlights that research like this is time-consuming and expensive. Donations are appreciated, and the sender provides options for donating via Lightning or on-chain transactions.References:1) https://github.com/bitcoin/bitcoin/pull/281322) https://petertodd.orgDonation addresses: Lightning - https://stacker.news/petertodd, On-chain - 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Private-Collaborative-Custody-with-FROST.xml b/static/bitcoin-dev/Aug_2023/combined_Private-Collaborative-Custody-with-FROST.xml index 30186cd703..b4146aea71 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Private-Collaborative-Custody-with-FROST.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Private-Collaborative-Custody-with-FROST.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Private Collaborative Custody with FROST - 2023-08-31T01:57:49.992613+00:00 - - Nick Farrow 2023-08-30 12:16:28+00:00 - - - rotmaxi 2023-08-29 11:51:49+00:00 - - - Nick Farrow 2023-08-28 19:35:22+00:00 - + 2025-09-26T14:27:50.850084+00:00 + python-feedgen + + + [bitcoin-dev] Private Collaborative Custody with FROST Nick Farrow + 2023-08-28T19:35:00.000Z + + + rot13maxi + 2023-08-29T11:51:00.000Z + + + Nick Farrow + 2023-08-30T12:16:00.000Z + + - python-feedgen + 2 Combined summary - Private Collaborative Custody with FROST - 2023-08-31T01:57:49.992754+00:00 + 2025-09-26T14:27:50.850695+00:00 - The email discusses the concept of private collaborative custody services for Bitcoin. It mentions that with multiparty computation multisignatures like FROST, it is possible to create a collaborative custodian service that ensures privacy for users. Currently, collaborative custodians can access a user's entire wallet history and have the power to censor signature requests. However, with FROST, a private collaborative custodian can hold a key to a multisig without being aware of the public key or wallet that they help control.In the scenario where a private collaborative custodian is required to sign a transaction, it can be done blindly. By remaining blind to the transaction request and unaware of past onchain behavior, these custodians have no practical information to enact censorship requests or non-cooperation. This is in contrast to non-private custodians who can easily be coerced into not collaborating with users.The email also discusses the process of enrolling a private collaborative custodian. Each signer in a FROST multisig controls a point belonging to a joint polynomial. Existing participants can collaborate to securely generate a new point on this shared polynomial and communicate it to the new custodian. The custodian should then share their own public point so that other parties can verify its authenticity.Furthermore, the email explains the concept of blind collaborative signing. Once the custodian controls a point belonging to the FROST key, they can help sign messages. The server follows a scheme similar to blind Schnorr signatures, producing a signature compatible with partial signatures from other FROST participants. The server signs under a single nonce and the nonce contributions from other signers blind the signature. The challenge is also blinded with a factor that includes the necessary Lagrange coefficient, allowing the partial signature to combine correctly with other FROST signatures.It is noted that the collaborative custodian does not need to know they are participating in FROST. The email addresses concerns about the server signing arbitrary challenges by stating that each secret share is unique to a specific FROST key, and the custodian should protect the service with user authentication and potential cooperation from other parties.Overall, the email discusses the benefits of private collaborative custody services for Bitcoin and explains the process of enrolling custodians and performing blind collaborative signing. 2023-08-30T12:16:28+00:00 + The email discusses the concept of private collaborative custody services for Bitcoin. It mentions that with multiparty computation multisignatures like FROST, it is possible to create a collaborative custodian service that ensures privacy for users. Currently, collaborative custodians can access a user's entire wallet history and have the power to censor signature requests. However, with FROST, a private collaborative custodian can hold a key to a multisig without being aware of the public key or wallet that they help control.In the scenario where a private collaborative custodian is required to sign a transaction, it can be done blindly. By remaining blind to the transaction request and unaware of past onchain behavior, these custodians have no practical information to enact censorship requests or non-cooperation. This is in contrast to non-private custodians who can easily be coerced into not collaborating with users.The email also discusses the process of enrolling a private collaborative custodian. Each signer in a FROST multisig controls a point belonging to a joint polynomial. Existing participants can collaborate to securely generate a new point on this shared polynomial and communicate it to the new custodian. The custodian should then share their own public point so that other parties can verify its authenticity.Furthermore, the email explains the concept of blind collaborative signing. Once the custodian controls a point belonging to the FROST key, they can help sign messages. The server follows a scheme similar to blind Schnorr signatures, producing a signature compatible with partial signatures from other FROST participants. The server signs under a single nonce and the nonce contributions from other signers blind the signature. The challenge is also blinded with a factor that includes the necessary Lagrange coefficient, allowing the partial signature to combine correctly with other FROST signatures.It is noted that the collaborative custodian does not need to know they are participating in FROST. The email addresses concerns about the server signing arbitrary challenges by stating that each secret share is unique to a specific FROST key, and the custodian should protect the service with user authentication and potential cooperation from other parties.Overall, the email discusses the benefits of private collaborative custody services for Bitcoin and explains the process of enrolling custodians and performing blind collaborative signing. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml b/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml index 84b824d82b..3820364729 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pull-req to enable Full-RBF by default - 2023-08-11T15:41:45.105161+00:00 + 2025-09-26T14:27:25.273602+00:00 + python-feedgen Peter Todd 2023-08-03 12:46:40+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Pull-req to enable Full-RBF by default - 2023-08-11T15:41:45.105161+00:00 + 2025-09-26T14:27:25.273740+00:00 - The claim that "trxs activity" is meaningless without demonstrating reliance on unconfirmed transaction acceptance is being challenged. The commenter questions the credibility of GAP600's offering of a "real-time risk engine" and "instant deposits & payments" without testing full-replace-by-fee (full-rbf) adoption themselves. They provide examples of transactions that were part of chains of replacements and question how these transactions are getting mined. The commenter requests the names of merchants using GAP600's claimed service to verify their reliance on unconfirmed transactions. They also mention reaching out to changelly.com for confirmation of their use of GAP600 but have yet to receive a response.GAP600 responds by stating they do not conduct specific assessments or research on hashing pools and that client confidentiality prevents them from disclosing their clients' names. They suggest contacting Max from Coinpaid for confirmation of their use of GAP600. They also mention that Changelly may not have fully implemented their service across all offerings. They provide contact details for further inquiries.In response to the commenter's assessment, GAP600 defends their honesty and offers evidence of their position. They state that they have provided clear access to clients to verify their statistics and offer a solution for validating full RBF adoption. They argue that the commenter's conclusions are unfounded.The author challenges the credibility of the claim that merchants relying on unconfirmed transactions exist and asks for concrete examples to support this assertion. They have reached out to Coinspaid and Changelly for confirmation but are awaiting a reply. They also query the specific services offered by Changelly that depend on unconfirmed transactions and inquire about the risk criteria set by GAP600. They suggest conducting test transactions if provided with the necessary information but refuse to provide transaction hashes to protect account owners. They question the lack of specific examples of affected businesses and dismiss payment processors as irrelevant. They mention instances of mining pools being harassed and decline to share private contact information. They suggest that if the service in question truly offered an unconfirmed transaction guarantee, they would have ample data on pools practicing full-rbf.The author provides evidence that there are no genuine examples of actual merchants accepting unconfirmed transactions. They mention that Changelly explicitly states that they do not accept unconfirmed payments. They request an example of an actual merchant accepting unconfirmed transactions.GAP600 provides statistics and feedback from Coinspaid to support their claims. They argue that the lack of impact on double spend rates suggests that the adoption of full RBF by miners is questionable. They mention that they reimburse clients for incorrect predictions of double spends. They clarify that they are not a payment processor but provide services to payment processors, merchants, and non-custodial liquidity providers.The author discusses the implementation of full Replace-By-Fee (RBF) in Bitcoin transactions and its potential negative impact on merchants and users who accept 0-conf transactions. They mention mitigation tools like GAP600 that require replacement transactions to include the original outputs. They provide statistics on the usage of GAP600 and mention their clients. They argue that the addition of a "first seen safe" rule is crucial to avoid negative consequences.The author of the context has submitted a pull request to enable full-rbf by default in Bitcoin Core. They mention several block explorers, nodes, and wallets that have enabled full-rbf. They argue that enabling full-rbf by default will address the issue of a minority of nodes relaying full-rbf replacements. They mention opposition from Bitrefill but found no evidence that they still accept unconfirmed transactions. They propose enabling full-rbf by default in Bitcoin Core and deprecating and removing BIP125 code in future releases. The context includes references to support the points made. 2023-08-03T12:46:40+00:00 + The claim that "trxs activity" is meaningless without demonstrating reliance on unconfirmed transaction acceptance is being challenged. The commenter questions the credibility of GAP600's offering of a "real-time risk engine" and "instant deposits & payments" without testing full-replace-by-fee (full-rbf) adoption themselves. They provide examples of transactions that were part of chains of replacements and question how these transactions are getting mined. The commenter requests the names of merchants using GAP600's claimed service to verify their reliance on unconfirmed transactions. They also mention reaching out to changelly.com for confirmation of their use of GAP600 but have yet to receive a response.GAP600 responds by stating they do not conduct specific assessments or research on hashing pools and that client confidentiality prevents them from disclosing their clients' names. They suggest contacting Max from Coinpaid for confirmation of their use of GAP600. They also mention that Changelly may not have fully implemented their service across all offerings. They provide contact details for further inquiries.In response to the commenter's assessment, GAP600 defends their honesty and offers evidence of their position. They state that they have provided clear access to clients to verify their statistics and offer a solution for validating full RBF adoption. They argue that the commenter's conclusions are unfounded.The author challenges the credibility of the claim that merchants relying on unconfirmed transactions exist and asks for concrete examples to support this assertion. They have reached out to Coinspaid and Changelly for confirmation but are awaiting a reply. They also query the specific services offered by Changelly that depend on unconfirmed transactions and inquire about the risk criteria set by GAP600. They suggest conducting test transactions if provided with the necessary information but refuse to provide transaction hashes to protect account owners. They question the lack of specific examples of affected businesses and dismiss payment processors as irrelevant. They mention instances of mining pools being harassed and decline to share private contact information. They suggest that if the service in question truly offered an unconfirmed transaction guarantee, they would have ample data on pools practicing full-rbf.The author provides evidence that there are no genuine examples of actual merchants accepting unconfirmed transactions. They mention that Changelly explicitly states that they do not accept unconfirmed payments. They request an example of an actual merchant accepting unconfirmed transactions.GAP600 provides statistics and feedback from Coinspaid to support their claims. They argue that the lack of impact on double spend rates suggests that the adoption of full RBF by miners is questionable. They mention that they reimburse clients for incorrect predictions of double spends. They clarify that they are not a payment processor but provide services to payment processors, merchants, and non-custodial liquidity providers.The author discusses the implementation of full Replace-By-Fee (RBF) in Bitcoin transactions and its potential negative impact on merchants and users who accept 0-conf transactions. They mention mitigation tools like GAP600 that require replacement transactions to include the original outputs. They provide statistics on the usage of GAP600 and mention their clients. They argue that the addition of a "first seen safe" rule is crucial to avoid negative consequences.The author of the context has submitted a pull request to enable full-rbf by default in Bitcoin Core. They mention several block explorers, nodes, and wallets that have enabled full-rbf. They argue that enabling full-rbf by default will address the issue of a minority of nodes relaying full-rbf replacements. They mention opposition from Bitrefill but found no evidence that they still accept unconfirmed transactions. They propose enabling full-rbf by default in Bitcoin Core and deprecating and removing BIP125 code in future releases. The context includes references to support the points made. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-remove-the-arbitrary-limits-on-OP-Return-outputs.xml b/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-remove-the-arbitrary-limits-on-OP-Return-outputs.xml index 1107bdeb09..ad2a58245a 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-remove-the-arbitrary-limits-on-OP-Return-outputs.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-remove-the-arbitrary-limits-on-OP-Return-outputs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pull-req to remove the arbitrary limits on OP_Return outputs - 2023-08-11T15:44:41.295327+00:00 + 2025-09-26T14:27:46.618212+00:00 + python-feedgen Murch 2023-08-09 13:06:49+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Pull-req to remove the arbitrary limits on OP_Return outputs - 2023-08-11T15:44:41.295327+00:00 + 2025-09-26T14:27:46.618344+00:00 - The email discusses the use of OP_RETURN in the blockchain and its impact on full node operators. It seeks clarification on whether using OP_RETURN or segwit/taproot witness space would result in fewer bytes on the blockchain, specifically for small inscriptions. The writer also asks about the prunability of OP_RETURN outputs and if there are tools available for full node operators to prune this data. They mention PR 2791 by Pieter Wuille, which implements pruning of provably-unspendable outputs, including OP_RETURN outputs.The email further asks about the default setting and enabling/disabling options for unspendable output pruning. It inquires about the potential impact of pruning OP_RETURN outputs on new nodes during initial block download (IBD) and whether it would differ for pruning Taproot witness space. The author seeks clarification on the policy change's impact on full node operators, the prunability of OP_RETURN outputs, and the consequences of pruning on assisting new nodes during IBD.Sjors Provoost suggested sending an email to notify their intention of merging a pull-request that removes restrictions on OP_RETURN outputs. The rationale behind this proposal is to potentially eliminate transaction pinning vectors. The author acknowledges the concern but argues that it is a potential issue with any relaxation of standardness rules. The email provides links to further information on transaction pinning from the Bitcoin Operations Guide and Peter Todd's website. 2023-08-09T13:06:49+00:00 + The email discusses the use of OP_RETURN in the blockchain and its impact on full node operators. It seeks clarification on whether using OP_RETURN or segwit/taproot witness space would result in fewer bytes on the blockchain, specifically for small inscriptions. The writer also asks about the prunability of OP_RETURN outputs and if there are tools available for full node operators to prune this data. They mention PR 2791 by Pieter Wuille, which implements pruning of provably-unspendable outputs, including OP_RETURN outputs.The email further asks about the default setting and enabling/disabling options for unspendable output pruning. It inquires about the potential impact of pruning OP_RETURN outputs on new nodes during initial block download (IBD) and whether it would differ for pruning Taproot witness space. The author seeks clarification on the policy change's impact on full node operators, the prunability of OP_RETURN outputs, and the consequences of pruning on assisting new nodes during IBD.Sjors Provoost suggested sending an email to notify their intention of merging a pull-request that removes restrictions on OP_RETURN outputs. The rationale behind this proposal is to potentially eliminate transaction pinning vectors. The author acknowledges the concern but argues that it is a potential issue with any relaxation of standardness rules. The email provides links to further information on transaction pinning from the Bitcoin Operations Guide and Peter Todd's website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Sentinel-Chains-A-Novel-Two-Way-Peg.xml b/static/bitcoin-dev/Aug_2023/combined_Sentinel-Chains-A-Novel-Two-Way-Peg.xml index 9fde5bfe7b..a606fea71b 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Sentinel-Chains-A-Novel-Two-Way-Peg.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Sentinel-Chains-A-Novel-Two-Way-Peg.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Sentinel Chains: A Novel Two-Way Peg - 2023-08-31T01:57:21.452114+00:00 - - ZmnSCPxj 2023-08-31 00:16:25+00:00 - - - ZmnSCPxj 2023-08-30 11:05:03+00:00 - - - ryan at breen.xyz 2023-08-28 14:35:30+00:00 - - - ZmnSCPxj 2023-08-28 13:48:39+00:00 - - - Ruben Somsen 2023-08-21 22:32:18+00:00 - - - ryan at breen.xyz 2023-08-19 18:58:15+00:00 - - - Ruben Somsen 2023-08-19 14:35:10+00:00 - - - ryan at breen.xyz 2023-08-16 02:02:38+00:00 - + 2025-09-26T14:27:44.472623+00:00 + python-feedgen + + + [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg ryan + 2023-08-16T02:02:00.000Z + + + Ruben Somsen + 2023-08-19T14:35:00.000Z + + + ryan + 2023-08-19T18:58:00.000Z + + + Ruben Somsen + 2023-08-21T22:32:00.000Z + + + ZmnSCPxj + 2023-08-28T13:48:00.000Z + + + ryan + 2023-08-28T14:35:00.000Z + + + ZmnSCPxj + 2023-08-30T11:05:00.000Z + + + ZmnSCPxj + 2023-08-31T00:16:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Sentinel Chains: A Novel Two-Way Peg - 2023-08-31T01:57:21.452206+00:00 + 2025-09-26T14:27:44.473594+00:00 - The email discusses the concept of "drivechains" and proposes an alternative solution called "Sentinel chains." Drivechains are a type of sidechain that involves conducting sidechain withdrawals directly through miners. The proposal, known as BIP-300, mandates a three-month period for peg-outs, during which miners vote on the validity of the peg-outs. This allows the community to respond in case of incorrect peg-outs or theft.The sender acknowledges criticisms of drivechains but believes that they can be a viable solution, given Bitcoin's reliance on social consensus. However, they argue that there are tools available now that can improve the process, leading to the concept of Sentinel chains.Sentinel chains involve sidechain nodes functioning as Sentinels, actively monitoring Bitcoin blocks and mempool transactions for invalid peg-outs that go against sidechain consensus rules. These invalid transactions or blocks are transmitted to public Nostr servers. Bitcoin full nodes interested in participating in sidechain consensus can run a small daemon alongside Bitcoin Core to monitor Nostr nodes for messages about invalid transactions. They can choose any group of individuals or organizations to receive updates from Nostr, forming their own decentralized web of trust.This approach reverses the conventional model of two-way pegged sidechains by having sidechains monitor nodes instead of requiring nodes to monitor sidechains. Sentinel chains require an initial consensus soft fork and allow for instantaneous and individual withdrawals without the need for a three-month gradual social consensus. Additionally, a single daemon can monitor notifications from multiple Sentinel chains, making the solution highly scalable for numerous sidechains.In summary, the email presents drivechains as an existing solution with certain limitations, and proposes Sentinel chains as an alternative approach that addresses some of these limitations. Sentinel chains involve sidechain nodes functioning as Sentinels, actively monitoring Bitcoin blocks and mempool transactions for invalid peg-outs and transmitting them to public Nostr servers. Bitcoin full nodes can participate in sidechain consensus by running a small daemon alongside Bitcoin Core to monitor Nostr nodes and form their own decentralized web of trust. 2023-08-31T00:16:25+00:00 + The email discusses the concept of "drivechains" and proposes an alternative solution called "Sentinel chains." Drivechains are a type of sidechain that involves conducting sidechain withdrawals directly through miners. The proposal, known as BIP-300, mandates a three-month period for peg-outs, during which miners vote on the validity of the peg-outs. This allows the community to respond in case of incorrect peg-outs or theft.The sender acknowledges criticisms of drivechains but believes that they can be a viable solution, given Bitcoin's reliance on social consensus. However, they argue that there are tools available now that can improve the process, leading to the concept of Sentinel chains.Sentinel chains involve sidechain nodes functioning as Sentinels, actively monitoring Bitcoin blocks and mempool transactions for invalid peg-outs that go against sidechain consensus rules. These invalid transactions or blocks are transmitted to public Nostr servers. Bitcoin full nodes interested in participating in sidechain consensus can run a small daemon alongside Bitcoin Core to monitor Nostr nodes for messages about invalid transactions. They can choose any group of individuals or organizations to receive updates from Nostr, forming their own decentralized web of trust.This approach reverses the conventional model of two-way pegged sidechains by having sidechains monitor nodes instead of requiring nodes to monitor sidechains. Sentinel chains require an initial consensus soft fork and allow for instantaneous and individual withdrawals without the need for a three-month gradual social consensus. Additionally, a single daemon can monitor notifications from multiple Sentinel chains, making the solution highly scalable for numerous sidechains.In summary, the email presents drivechains as an existing solution with certain limitations, and proposes Sentinel chains as an alternative approach that addresses some of these limitations. Sentinel chains involve sidechain nodes functioning as Sentinels, actively monitoring Bitcoin blocks and mempool transactions for invalid peg-outs and transmitting them to public Nostr servers. Bitcoin full nodes can participate in sidechain consensus by running a small daemon alongside Bitcoin Core to monitor Nostr nodes and form their own decentralized web of trust. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_Serverless-Payjoin.xml b/static/bitcoin-dev/Aug_2023/combined_Serverless-Payjoin.xml index 1ab0d99080..5e410e2159 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Serverless-Payjoin.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Serverless-Payjoin.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Serverless Payjoin - 2023-08-21T01:52:45.170913+00:00 - - alicexbt 2023-08-20 17:13:33+00:00 - - - Dan Gould 2023-01-22 20:50:44+00:00 - + 2025-09-26T14:27:20.968983+00:00 + python-feedgen + + + [bitcoin-dev] Serverless Payjoin Dan Gould + 2023-01-22T20:50:00.000Z + + + alicexbt + 2023-08-20T17:13:00.000Z + + - python-feedgen + 2 Combined summary - Serverless Payjoin - 2023-08-21T01:52:45.170979+00:00 + 2025-09-26T14:27:20.969400+00:00 - In a recent communication, Dan shared some points after reading an article titled "Serverless Payjoin Gets Its Wings" by Kukks. Firstly, there is a mention of NIP 4, which seems to have no security issues but potential privacy concerns due to metadata leakage. However, using a new npub each time users engage in payjoin can address this issue, as the message itself remains encrypted. Secondly, there is a discussion about backwards compatibility related to npub and relay information shared in payjoin URIs. The email mentions that fixing this issue is uncertain. Regarding relays, it is stated that if multiple relays are used, there is no incentive for them to engage in malicious activities. However, the exact nature of potential malicious activities with encrypted messages is not clearly understood. Additionally, IP addresses are identified as an issue in many projects, but this can be managed by users or wallet implementations through the use of RiseupVPN, Tor, i2p, etc. Finally, the suggestion of adding random padding, proposed by some senior developers, is considered sensible.Dan Gould has published an upgrade for payjoin that allows the receiver to receive bitcoin transfers without running a public server. This new scheme utilizes a TURN relay for connectivity and symmetric cryptography for security. The recipient requests the relay to allocate them an endpoint for UDP communication. They then share a BIP 21 payjoin URI containing the allocated endpoint and a generated 256-bit key called psk. The sender constructs their request using the original PSBT format from BIP 78, and they utilize the NNpsk0 pattern for noise framework instead of TLS or Tor. The resulting ciphertext ensures message secrecy and integrity when relayed to the recipient through the endpoint.However, this work highlights a larger issue with payjoin, which assumes synchronous communication in an asynchronous world. It is mentioned that a relay could hold a request for an offline payjoin peer until that peer comes online. Yet, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty, which exposes a naive and surveillance-vulnerable transaction that payjoin aims to avoid. Further research is needed before recommending such a protocol.Since TURN relays can handle various internet traffic, they are susceptible to the tragedy of the commons. Relay operators might impose authentication requirements for endpoint allocation provisions. While peers only see the IP address of the TURN relay, not their peer's, it is suggested that TURN relays could also be made available via Tor hidden service to allow either peer to protect their IP with Tor without forcing the other to use it too.Dan Gould has provided proof-of-concept sender, receiver clients, and relay code in Rust, which can be found on GitHub for more details and improved formatting. 2023-08-20T17:13:33+00:00 + In a recent communication, Dan shared some points after reading an article titled "Serverless Payjoin Gets Its Wings" by Kukks. Firstly, there is a mention of NIP 4, which seems to have no security issues but potential privacy concerns due to metadata leakage. However, using a new npub each time users engage in payjoin can address this issue, as the message itself remains encrypted. Secondly, there is a discussion about backwards compatibility related to npub and relay information shared in payjoin URIs. The email mentions that fixing this issue is uncertain. Regarding relays, it is stated that if multiple relays are used, there is no incentive for them to engage in malicious activities. However, the exact nature of potential malicious activities with encrypted messages is not clearly understood. Additionally, IP addresses are identified as an issue in many projects, but this can be managed by users or wallet implementations through the use of RiseupVPN, Tor, i2p, etc. Finally, the suggestion of adding random padding, proposed by some senior developers, is considered sensible.Dan Gould has published an upgrade for payjoin that allows the receiver to receive bitcoin transfers without running a public server. This new scheme utilizes a TURN relay for connectivity and symmetric cryptography for security. The recipient requests the relay to allocate them an endpoint for UDP communication. They then share a BIP 21 payjoin URI containing the allocated endpoint and a generated 256-bit key called psk. The sender constructs their request using the original PSBT format from BIP 78, and they utilize the NNpsk0 pattern for noise framework instead of TLS or Tor. The resulting ciphertext ensures message secrecy and integrity when relayed to the recipient through the endpoint.However, this work highlights a larger issue with payjoin, which assumes synchronous communication in an asynchronous world. It is mentioned that a relay could hold a request for an offline payjoin peer until that peer comes online. Yet, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty, which exposes a naive and surveillance-vulnerable transaction that payjoin aims to avoid. Further research is needed before recommending such a protocol.Since TURN relays can handle various internet traffic, they are susceptible to the tragedy of the commons. Relay operators might impose authentication requirements for endpoint allocation provisions. While peers only see the IP address of the TURN relay, not their peer's, it is suggested that TURN relays could also be made available via Tor hidden service to allow either peer to protect their IP with Tor without forcing the other to use it too.Dan Gould has provided proof-of-concept sender, receiver clients, and relay code in Rust, which can be found on GitHub for more details and improved formatting. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml b/static/bitcoin-dev/Aug_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml index fd9a983d5e..35fa0cd9d0 100644 --- a/static/bitcoin-dev/Aug_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml +++ b/static/bitcoin-dev/Aug_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - ZeroSync: Introducing Validity Proofs to Bitcoin - 2023-08-29T02:15:23.286604+00:00 - - blk0 2023-08-28 07:49:02+00:00 - - - Erik Aronesty 2023-06-05 18:59:58+00:00 - - - Peter Todd 2023-06-05 18:47:03+00:00 - - - Robin Linus 2023-05-12 16:03:06+00:00 - - - Weiji Guo 2023-05-12 15:32:55+00:00 - - - Robin Linus 2023-05-12 12:12:03+00:00 - + 2025-09-26T14:27:31.676419+00:00 + python-feedgen + + + [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin Robin Linus + 2023-05-12T12:12:00.000Z + + + Weiji Guo + 2023-05-12T15:32:00.000Z + + + Robin Linus + 2023-05-12T16:03:00.000Z + + + Peter Todd + 2023-06-05T18:47:00.000Z + + + Erik Aronesty + 2023-06-05T18:59:00.000Z + + + blk0 + 2023-08-28T07:49:00.000Z + + - python-feedgen + 2 Combined summary - ZeroSync: Introducing Validity Proofs to Bitcoin - 2023-08-29T02:15:23.286689+00:00 + 2025-09-26T14:27:31.677246+00:00 - Peter Todd shared information about a general purpose zkVM implementation for the RISC-V instruction set called RiscZero. He mentioned that since Bitcoin Core can be compiled for RISC-V, and RiscZero can prove execution traces of a RISC-V VM, the argument against using RISC-V for Bitcoin no longer applies.A research paper titled "ZeroSync: Introducing Validity Proofs to Bitcoin" has been published, introducing ZeroSync as a proof system that addresses scalability challenges with SNARKs. The system compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync enables diverse applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, is introduced, significantly improving privacy and throughput of token transactions. However, there are concerns about creating an alternative implementation of the Bitcoin protocol, which may lead to potential forks. Furthermore, if the technology advances to real-time proof-generation, widespread adoption by Bitcoin miners could jeopardize Bitcoin's decentralization.In a conversation between Weiji and Robin, they discussed plans to implement a SNARK verifier on Bitcoin's base layer. Robin explained his long-term plan and mentioned experimenting with Simplicity on the Liquid sidechain. Weiji shared his proposal for a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs through a soft fork. Although Robin acknowledged the proposal, he highlighted the challenge of establishing consensus over specific op_snark_verify opcodes due to the variety of competing proof systems with different trade-offs. While STARKs are scalable and suitable for chain state proofs, Robin prefers other proof systems like Plonky2 for on-chain verification due to smaller proof sizes. Robin also mentioned the possibility of using any verifier to wrap other proofs. He invited Weiji to join their Telegram group to discuss SNARKs on Bitcoin.Weiji emailed Robin to inquire about his plans for implementing a SNARK verifier on Bitcoin's base layer. Weiji had previously proposed the opcode OP_ZKP for verifying zkp proofs through a soft fork. In response, Robin shared his research on ZeroSync, a pioneering proof system that addresses Bitcoin's scalability challenges with SNARKs. ZeroSync compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various applications. The implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync also introduces zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, improving privacy and transaction throughput. The groundbreaking compression capabilities of SNARKs have revolutionized cryptocurrency design, and ZeroSync leads their application to Bitcoin. The full paper can be found at https://zerosync.org/zerosync.pdf. Robin welcomes comments and questions from the bitcoin dev community regarding the paper.ZeroSync, the first-ever proof system for Bitcoin, has been introduced to address scalability challenges using SNARKs. It compresses the entire Bitcoin blockchain into a compact proof of validity, allowing instant verification and unlocking innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. These proofs require no consensus changes, which is crucial for implementing forks in Bitcoin. ZeroSync enables various applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, significantly improves privacy and transaction throughput. With the combination of future Bitcoin features like Simplicity, zkCoins enables private and more scalable BTC transactions. The paper on ZeroSync can be found at https://zerosync.org/zerosync.pdf. Robin invites the bitcoin dev community to provide comments and ask questions about the paper. 2023-08-28T07:49:02+00:00 + Peter Todd shared information about a general purpose zkVM implementation for the RISC-V instruction set called RiscZero. He mentioned that since Bitcoin Core can be compiled for RISC-V, and RiscZero can prove execution traces of a RISC-V VM, the argument against using RISC-V for Bitcoin no longer applies.A research paper titled "ZeroSync: Introducing Validity Proofs to Bitcoin" has been published, introducing ZeroSync as a proof system that addresses scalability challenges with SNARKs. The system compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync enables diverse applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, is introduced, significantly improving privacy and throughput of token transactions. However, there are concerns about creating an alternative implementation of the Bitcoin protocol, which may lead to potential forks. Furthermore, if the technology advances to real-time proof-generation, widespread adoption by Bitcoin miners could jeopardize Bitcoin's decentralization.In a conversation between Weiji and Robin, they discussed plans to implement a SNARK verifier on Bitcoin's base layer. Robin explained his long-term plan and mentioned experimenting with Simplicity on the Liquid sidechain. Weiji shared his proposal for a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs through a soft fork. Although Robin acknowledged the proposal, he highlighted the challenge of establishing consensus over specific op_snark_verify opcodes due to the variety of competing proof systems with different trade-offs. While STARKs are scalable and suitable for chain state proofs, Robin prefers other proof systems like Plonky2 for on-chain verification due to smaller proof sizes. Robin also mentioned the possibility of using any verifier to wrap other proofs. He invited Weiji to join their Telegram group to discuss SNARKs on Bitcoin.Weiji emailed Robin to inquire about his plans for implementing a SNARK verifier on Bitcoin's base layer. Weiji had previously proposed the opcode OP_ZKP for verifying zkp proofs through a soft fork. In response, Robin shared his research on ZeroSync, a pioneering proof system that addresses Bitcoin's scalability challenges with SNARKs. ZeroSync compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various applications. The implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync also introduces zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, improving privacy and transaction throughput. The groundbreaking compression capabilities of SNARKs have revolutionized cryptocurrency design, and ZeroSync leads their application to Bitcoin. The full paper can be found at https://zerosync.org/zerosync.pdf. Robin welcomes comments and questions from the bitcoin dev community regarding the paper.ZeroSync, the first-ever proof system for Bitcoin, has been introduced to address scalability challenges using SNARKs. It compresses the entire Bitcoin blockchain into a compact proof of validity, allowing instant verification and unlocking innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. These proofs require no consensus changes, which is crucial for implementing forks in Bitcoin. ZeroSync enables various applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, significantly improves privacy and transaction throughput. With the combination of future Bitcoin features like Simplicity, zkCoins enables private and more scalable BTC transactions. The paper on ZeroSync can be found at https://zerosync.org/zerosync.pdf. Robin invites the bitcoin dev community to provide comments and ask questions about the paper. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2023/combined_segwit-naming-ambiguity.xml b/static/bitcoin-dev/Aug_2023/combined_segwit-naming-ambiguity.xml index 7392ec65f6..a0bcd8817c 100644 --- a/static/bitcoin-dev/Aug_2023/combined_segwit-naming-ambiguity.xml +++ b/static/bitcoin-dev/Aug_2023/combined_segwit-naming-ambiguity.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - segwit naming ambiguity - 2023-08-12T01:48:03.298921+00:00 - - Andrew Poelstra 2023-08-11 13:45:35+00:00 - - - Pavol Rusnak 2023-08-11 10:06:22+00:00 - - - Antoine Poinsot 2023-08-11 07:49:15+00:00 - - - symphonicbtc 2023-08-11 07:38:13+00:00 - - - Tobin Harding 2023-08-11 04:45:57+00:00 - + 2025-09-26T14:27:48.730445+00:00 + python-feedgen + + + [bitcoin-dev] segwit naming ambiguity Tobin Harding + 2023-08-11T04:45:00.000Z + + + symphonicbtc + 2023-08-11T07:38:00.000Z + + + Antoine Poinsot + 2023-08-11T07:49:00.000Z + + + Pavol Rusnak + 2023-08-11T10:06:00.000Z + + + Andrew Poelstra + 2023-08-11T13:45:00.000Z + + - python-feedgen + 2 Combined summary - segwit naming ambiguity - 2023-08-12T01:48:03.298988+00:00 + 2025-09-26T14:27:48.731240+00:00 - The email discusses the naming and functionality of the `is_segwit()` function in relation to different types of Bitcoin transactions. The sender suggests that `is_segwit()` should apply to all segwit versions, including p2tr outputs. They propose a clean API design that includes functions like `segwit_version()`, `is_p2wpkh()`, `is_p2tr()`, and `is_p2wsh()` to differentiate between script types. Another suggestion is to refer to version 0 segwit as "v0". The sender also mentions Murch's BIP as a potential source for better naming conventions. The context emphasizes the need to consider witness programs nested inside P2SH and clarifies that these should be considered segwit as they have segregated witness data. It is suggested that documentation explicitly explains how these functions behave for different program types. Finally, the sender asks for input from OG bitcoin API designers on whether `is_segwit()` should return true or false for p2tr transactions and if there is an official or widely used name for segwit v0. 2023-08-11T13:45:35+00:00 + The email discusses the naming and functionality of the `is_segwit()` function in relation to different types of Bitcoin transactions. The sender suggests that `is_segwit()` should apply to all segwit versions, including p2tr outputs. They propose a clean API design that includes functions like `segwit_version()`, `is_p2wpkh()`, `is_p2tr()`, and `is_p2wsh()` to differentiate between script types. Another suggestion is to refer to version 0 segwit as "v0". The sender also mentions Murch's BIP as a potential source for better naming conventions. The context emphasizes the need to consider witness programs nested inside P2SH and clarifies that these should be considered segwit as they have segregated witness data. It is suggested that documentation explicitly explains how these functions behave for different program types. Finally, the sender asks for input from OG bitcoin API designers on whether `is_segwit()` should return true or false for p2tr transactions and if there is an official or widely used name for segwit v0. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_A-Free-Relay-Attack-Taking-Advantage-of-The-Lack-of-Full-RBF-In-Core.xml b/static/bitcoin-dev/Aug_2024/combined_A-Free-Relay-Attack-Taking-Advantage-of-The-Lack-of-Full-RBF-In-Core.xml index d844193ae1..0686847d69 100644 --- a/static/bitcoin-dev/Aug_2024/combined_A-Free-Relay-Attack-Taking-Advantage-of-The-Lack-of-Full-RBF-In-Core.xml +++ b/static/bitcoin-dev/Aug_2024/combined_A-Free-Relay-Attack-Taking-Advantage-of-The-Lack-of-Full-RBF-In-Core.xml @@ -1,134 +1,179 @@ - + 2 - Combined summary - A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core - 2024-08-17T02:06:44.997884+00:00 - - Antoine Riard 2024-08-16 04:45:00+00:00 - - - Antoine Riard 2024-08-16 04:20:00+00:00 - - - Garlo Nicon 2024-08-01 05:57:00+00:00 - - - Peter Todd 2024-07-30 19:38:00+00:00 - - - David Harding 2024-07-30 04:57:00+00:00 - - - Antoine Riard 2024-07-24 00:44:00+00:00 - - - Antoine Riard 2024-07-24 00:42:00+00:00 - - - Antoine Riard 2024-07-24 00:41:00+00:00 - - - Antoine Riard 2024-07-24 00:38:00+00:00 - - - Antoine Riard 2024-07-24 00:35:00+00:00 - - - Peter Todd 2024-07-23 11:29:00+00:00 - - - David A. Harding 2024-07-22 22:08:00+00:00 - - - Peter Todd 2024-07-22 20:06:00+00:00 - - - Peter Todd 2024-07-22 17:13:00+00:00 - - - David A. Harding 2024-07-22 16:43:00+00:00 - - - Peter Todd 2024-07-22 15:10:00+00:00 - - - Peter Todd 2024-07-22 11:45:00+00:00 - - - Anonymous User 2024-07-22 01:59:00+00:00 - - - Peter Todd 2024-07-21 20:25:00+00:00 - - - Ava Chow 2024-07-21 20:17:00+00:00 - - - David A. Harding 2024-07-21 15:35:00+00:00 - - - /dev /fd 2024-07-21 06:16:00+00:00 - - - Antoine Riard 2024-07-21 02:13:00+00:00 - - - Antoine Riard 2024-07-21 02:12:00+00:00 - - - Antoine Riard 2024-07-21 02:10:00+00:00 - - - Antoine Riard 2024-07-21 02:06:00+00:00 - - - Peter Todd 2024-07-20 15:30:00+00:00 - - - Peter Todd 2024-07-20 15:08:00+00:00 - - - Peter Todd 2024-07-20 15:03:00+00:00 - - - Peter Todd 2024-07-20 14:10:00+00:00 - - - David A. Harding 2024-07-20 06:41:00+00:00 - - - /dev /fd 2024-07-20 05:57:00+00:00 - - - Ava Chow 2024-07-20 00:46:00+00:00 - - - Antoine Riard 2024-07-19 23:58:00+00:00 - - - Antoine Riard 2024-07-19 23:56:00+00:00 - - - Murch 2024-07-19 18:26:00+00:00 - - - Peter Todd 2024-07-19 14:38:00+00:00 - - - Antoine Riard 2024-07-19 13:52:00+00:00 - - - /dev /fd 2024-07-19 12:41:00+00:00 - - - Peter Todd 2024-07-19 01:05:00+00:00 - - - Antoine Riard 2024-07-18 23:04:00+00:00 - - - Peter Todd 2024-07-18 15:56:00+00:00 - + Combined summary - A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core + 2025-09-26T14:25:08.390856+00:00 + python-feedgen + + + A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd + 2024-07-18T15:56:00.000Z + + + Antoine Riard + 2024-07-18T23:04:00.000Z + + + Peter Todd + 2024-07-19T01:05:00.000Z + + + /dev /fd0 + 2024-07-19T12:41:00.000Z + + + Antoine Riard + 2024-07-19T13:52:00.000Z + + + Peter Todd + 2024-07-19T14:38:00.000Z + + + Murch + 2024-07-19T18:26:00.000Z + + + Antoine Riard + 2024-07-19T23:56:00.000Z + + + Antoine Riard + 2024-07-19T23:58:00.000Z + + + Ava Chow' + 2024-07-20T00:46:00.000Z + + + /dev /fd0 + 2024-07-20T05:57:00.000Z + + + David A. Harding + 2024-07-20T06:41:00.000Z + + + Peter Todd + 2024-07-20T14:10:00.000Z + + + Peter Todd + 2024-07-20T15:03:00.000Z + + + Peter Todd + 2024-07-20T15:08:00.000Z + + + Peter Todd + 2024-07-20T15:30:00.000Z + + + Antoine Riard + 2024-07-21T02:06:00.000Z + + + Antoine Riard + 2024-07-21T02:10:00.000Z + + + Antoine Riard + 2024-07-21T02:12:00.000Z + + + Antoine Riard + 2024-07-21T02:13:00.000Z + + + /dev /fd0 + 2024-07-21T06:16:00.000Z + + + David A. Harding + 2024-07-21T15:35:00.000Z + + + Ava Chow' + 2024-07-21T20:17:00.000Z + + + Peter Todd + 2024-07-21T20:25:00.000Z + + + Anonymous User' + 2024-07-22T01:59:00.000Z + + + RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd + 2024-07-22T11:45:00.000Z + + + Peter Todd + 2024-07-22T15:10:00.000Z + + + David A. Harding + 2024-07-22T16:43:00.000Z + + + A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd + 2024-07-22T17:13:00.000Z + + + Peter Todd + 2024-07-22T20:06:00.000Z + + + David A. Harding + 2024-07-22T22:08:00.000Z + + + Peter Todd + 2024-07-23T11:29:00.000Z + + + Antoine Riard + 2024-07-24T00:35:00.000Z + + + Antoine Riard + 2024-07-24T00:38:00.000Z + + + Antoine Riard + 2024-07-24T00:41:00.000Z + + + Antoine Riard + 2024-07-24T00:42:00.000Z + + + Antoine Riard + 2024-07-24T00:44:00.000Z + + + David A. Harding + 2024-07-30T04:57:00.000Z + + + Peter Todd + 2024-07-30T19:38:00.000Z + + + Garlo Nicon + 2024-08-01T05:57:00.000Z + + + Antoine Riard + 2024-08-16T04:20:00.000Z + + + Antoine Riard + 2024-08-16T04:45:00.000Z + + @@ -171,21 +216,17 @@ - python-feedgen + 2 - Combined summary - A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core - 2024-08-17T02:06:44.998218+00:00 + Combined summary - A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core + 2025-09-26T14:25:08.395692+00:00 + 2024-08-16T04:45:00+00:00 The discourse among Bitcoin developers, notably between Antoine Riard and Peter Todd, sheds light on a critical security vulnerability within the Bitcoin network related to transaction relays and double-spending. The vulnerability hinges on exploiting nodes with full Replace-By-Fee (RBF) disabled, allowing for an attack where low fee-rate transactions are initially broadcast across the majority of the network and subsequently double-spent with higher fees to a single miner. This scenario underlines a fundamental issue in the network's design, where the relay and acceptance policies of nodes can be manipulated to waste bandwidth and potentially disrupt transaction integrity. - Antoine's critique extends to the broader Bitcoin Core team's response—or lack thereof—to such vulnerabilities. Despite proposing solutions like enabling full RBF by default, which could mitigate multiple known issues including this specific vulnerability, such suggestions have been ignored or dismissed due to what appears to be political reasons within the development community. This reluctance to adopt straightforward fixes raises concerns about the prioritization of political over technical considerations in addressing security vulnerabilities. - -Furthermore, the discussion delves into the ineffectiveness of TRUC/V3 transactions as proposed in BIP-431. Despite being positioned as a solution to certain types of "free" relay attacks, the rationale behind TRUC/V3 is criticized for failing to address the underlying issues effectively. This situation highlights a misallocation of resources towards solutions that do not fully mitigate the identified risks, thereby perpetuating vulnerabilities within the network. - +Furthermore, the discussion delves into the ineffectiveness of TRUC/V3 transactions as proposed in BIP-431. Despite being positioned as a solution to certain types of "free" relay attacks, the rationale behind TRUC/V3 is criticized for failing to address the underlying issues effectively. This situation highlights a misallocation of resources towards solutions that do not fully mitigate the identified risks, thereby perpetuating vulnerabilities within the network. The communication also emphasizes the economic feasibility of executing such attacks, pointing out that attackers can exploit these vulnerabilities at minimal cost. This underscores a significant inefficiency within the Bitcoin protocol that could be exploited for nefarious purposes, including low-cost transaction consolidation by attackers. - This dialogue underscores the complexity of managing security vulnerabilities within open-source cryptocurrency projects like Bitcoin. It reveals a tension between the need for technical solutions to secure the network and the political dynamics that influence decision-making processes within the developer community. The highlighted correspondence and proposals call for a reassessment of priorities, advocating for a more responsive and technically grounded approach to safeguarding the integrity and efficiency of the Bitcoin network. - 2024-08-16T04:45:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_BIP-8-5-Flag-day-activation-based-on-nlocktime-signaling.xml b/static/bitcoin-dev/Aug_2024/combined_BIP-8-5-Flag-day-activation-based-on-nlocktime-signaling.xml index 4605be1295..a5db7213d5 100644 --- a/static/bitcoin-dev/Aug_2024/combined_BIP-8-5-Flag-day-activation-based-on-nlocktime-signaling.xml +++ b/static/bitcoin-dev/Aug_2024/combined_BIP-8-5-Flag-day-activation-based-on-nlocktime-signaling.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - BIP 8.5: Flag day activation based on nlocktime signaling - 2024-08-23T02:13:16.507545+00:00 - - /dev /fd0 2024-08-22 11:43:00+00:00 - - - Mark Erhardt 2024-08-20 18:05:00+00:00 - - - /dev /fd 2024-08-19 17:50:00+00:00 - - - /dev /fd 2024-08-19 17:50:00+00:00 - - - David Harding 2024-08-19 13:22:00+00:00 - - - Fabian 2024-08-19 13:16:00+00:00 - - - /dev /fd 2024-08-19 05:08:00+00:00 - + 2025-09-26T14:25:12.690203+00:00 + python-feedgen + + + BIP 8.5: Flag day activation based on nlocktime signaling /dev /fd0 + 2024-08-19T05:08:00.000Z + + + Fabian' + 2024-08-19T13:16:00.000Z + + + David A. Harding + 2024-08-19T13:22:00.000Z + + + /dev /fd0 + 2024-08-19T17:50:00.000Z + + + /dev /fd0 + 2024-08-19T17:50:00.000Z + + + Murch + 2024-08-20T18:05:00.000Z + + + /dev /fd0 + 2024-08-22T11:43:00.000Z + + @@ -31,19 +41,16 @@ - python-feedgen + 2 Combined summary - BIP 8.5: Flag day activation based on nlocktime signaling - 2024-08-23T02:13:16.507643+00:00 + 2025-09-26T14:25:12.691211+00:00 + 2024-08-22T11:43:00+00:00 The recent discussions around a new method for activating soft forks in the Bitcoin network have brought several concerns and ideas to the forefront. The mechanism proposed introduces a cost for signaling, aiming to ensure that only users with genuine economic activity participate in the decision-making process. However, this approach raises questions about its fairness and practicality, as it could potentially exclude participants who cannot afford the associated costs or those whose funds are not readily accessible. Furthermore, the reliance on the `nLockTime` field for signaling has been criticized due to its existing uses in the protocol and the potential privacy implications for users capable of adjusting this parameter manually. - Critics argue that the proposed signaling mechanism might incentivize undesirable behaviors, such as splitting transactions to reduce signaling costs, which could lead to increased demand for block space. Additionally, the limitation of signaling to one proposal per transaction, unless `nLockTime` is used creatively, poses challenges for expressing support for multiple proposals simultaneously. The interpretation of signaling data also appears problematic, with concerns about distinguishing between lack of support and mere apathy towards proposals. - The dialogue extends to the technical and economic considerations involved in the proposal. There's an acknowledgment of the challenges posed by spam and the manipulation of transaction fees, which could distort the signaling process. The conversation also touches upon the need for a detailed proposal that addresses potential loopholes and provides clarity through a FAQ section, aiming for a balance between simplicity and functionality. The reference to previous discussions and proposals underscores the importance of innovation and the differentiation of new suggestions from existing ones. This includes leveraging the OP_RETURN operation, setting specific thresholds for tagged input addresses, and exploring alternative mechanisms like Proof-of-Stake (PoS) voting through UTXOs, highlighting the evolving nature of blockchain technology discussions. - An alternative activation method is suggested, focusing on using `nLockTime` for signaling and setting a flag day for soft fork activation. This method proposes a way to circumvent the complexities and controversies associated with previous activation methods, such as BIP 8 and BIP 9, by allowing users to signal their support directly through transactions. The discussion includes practical implementations and modifications to ensure the flexibility and integrity of the signaling process, with references provided for further technical examination. This approach aims to foster community consensus and prepare miners for the adoption of new consensus rules, reflecting a collaborative effort towards decentralized protocol improvement. - 2024-08-22T11:43:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_BIP-Draft-FROST-Signing-.xml b/static/bitcoin-dev/Aug_2024/combined_BIP-Draft-FROST-Signing-.xml index edba94f16f..5b373acb1c 100644 --- a/static/bitcoin-dev/Aug_2024/combined_BIP-Draft-FROST-Signing-.xml +++ b/static/bitcoin-dev/Aug_2024/combined_BIP-Draft-FROST-Signing-.xml @@ -1,23 +1,28 @@ - + 2 - Combined summary - BIP Draft: "FROST Signing" - 2024-08-01T02:15:23.813732+00:00 - - Sivaram D 2024-08-01 00:45:00+00:00 - - - Sivaram Dhakshinamoorthy 2024-07-31 11:23:00+00:00 - + Combined summary - BIP Draft: "FROST Signing" + 2025-09-26T14:25:19.043264+00:00 + python-feedgen + + + BIP Draft: "FROST Signing" Sivaram Dhakshinamoorthy + 2024-07-31T11:23:00.000Z + + + Sivaram D + 2024-08-01T00:45:00.000Z + + - python-feedgen + 2 - Combined summary - BIP Draft: "FROST Signing" - 2024-08-01T02:15:23.813773+00:00 + Combined summary - BIP Draft: "FROST Signing" + 2025-09-26T14:25:19.043739+00:00 - Sivaram has introduced a draft for a Bitcoin Improvement Proposal (BIP) focused on the FROST threshold signing protocol. The proposal is comprehensive, detailing design aspects, guidelines for usage, considerations regarding security, and includes a Python implementation along with test vectors for practical reference. To facilitate review and feedback, the draft has been made accessible at [https://github.com/siv2r/bip-frost-signing](https://github.com/siv2r/bip-frost-signing). However, it's important to note that the draft does not address key generation for FROST. Instead, it points towards existing resources for this purpose, namely the ChillDKG BIP available at [https://github.com/BlockstreamResearch/bip-frost-dkg](https://github.com/BlockstreamResearch/bip-frost-dkg) and RFC 9792's Appendix C, which can be found at [https://datatracker.ietf.org/doc/rfc9591/](https://datatracker.ietf.org/doc/rfc9591/). Sivaram emphasizes the importance of community feedback on this initiative. 2024-08-01T00:45:00+00:00 + Sivaram has introduced a draft for a Bitcoin Improvement Proposal (BIP) focused on the FROST threshold signing protocol. The proposal is comprehensive, detailing design aspects, guidelines for usage, considerations regarding security, and includes a Python implementation along with test vectors for practical reference. To facilitate review and feedback, the draft has been made accessible at [https://github.com/siv2r/bip-frost-signing](https://github.com/siv2r/bip-frost-signing). However, it's important to note that the draft does not address key generation for FROST. Instead, it points towards existing resources for this purpose, namely the ChillDKG BIP available at [https://github.com/BlockstreamResearch/bip-frost-dkg](https://github.com/BlockstreamResearch/bip-frost-dkg) and RFC 9792's Appendix C, which can be found at [https://datatracker.ietf.org/doc/rfc9591/](https://datatracker.ietf.org/doc/rfc9591/). Sivaram emphasizes the importance of community feedback on this initiative. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml b/static/bitcoin-dev/Aug_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml index 4a9927f576..39615f7a75 100644 --- a/static/bitcoin-dev/Aug_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml +++ b/static/bitcoin-dev/Aug_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml @@ -1,47 +1,52 @@ - + 2 Combined summary - Demonstrating Pinning Attacks under Real-World Conditions - 2024-10-13T02:26:41.059288+00:00 - - Antoine Riard 2024-10-12 04:46:00+00:00 - - - waxwing/ AdamISZ 2024-10-11 15:01:00+00:00 - - - Antoine Riard 2024-10-11 00:21:00+00:00 - - - Antoine Riard 2024-09-03 20:12:00+00:00 - - - Peter Todd 2024-09-03 12:58:00+00:00 - - - Antoine Riard 2024-08-27 21:10:00+00:00 - + 2025-09-26T14:25:04.016912+00:00 + python-feedgen + + + Demonstrating Pinning Attacks under Real-World Conditions Antoine Riard + 2024-08-27T21:10:00.000Z + + + Peter Todd + 2024-09-03T12:58:00.000Z + + + Antoine Riard + 2024-09-03T20:12:00.000Z + + + Antoine Riard + 2024-10-11T00:21:00.000Z + + + waxwing/ AdamISZ + 2024-10-11T15:01:00.000Z + + + Antoine Riard + 2024-10-12T04:46:00.000Z + + - python-feedgen + 2 Combined summary - Demonstrating Pinning Attacks under Real-World Conditions - 2024-10-13T02:26:41.059346+00:00 + 2025-09-26T14:25:04.017721+00:00 + 2024-10-12T04:46:00+00:00 The conversation starts with the recognition of a need for clear, step-by-step instructions for volunteers interested in setting up new nodes, focusing on the use of current and default installations of Core/btcd along with lnd/cln/ldk. It delves into specifics such as the amount required in channels, the necessary number of channels, the relevance of channel types, volunteer interconnectivity, desired network topology, and the significance of network connectivity and Tor usage. This discussion illuminates the technical intricacies involved in setting up these nodes and underscores the importance of detailed guidance for volunteers with varying expertise levels. - The topic shifts to the exploration of real-world pinning attacks against production lightning nodes and the broader context of security vulnerabilities within the bitcoin network. The reluctance of developers to engage in real-world demonstrations of these exploits is highlighted, alongside the optimism for improved evaluations and reproductions of bitcoin security exploits. Drawing parallels with major information security conferences, there's an anticipation that increased scrutiny of security flaws will bolster the bitcoin ecosystem's resilience. This part of the discussion emphasizes the critical focus on security vulnerabilities and the proactive measures needed to safeguard blockchain technologies. - Antoine Riard discusses his personal commitment to testing without affecting CPU or RAM functionalities, focusing instead on transaction-relay and mempool logic. He proposes running a node on the mainnet to exploit channels for liquidity rebalancing, committing his own liquidity for this purpose. Additionally, Riard mentions a $100 donation to the OTS project, highlighting his support for its notarization services. His approach to handling transactions cautiously to avoid penalties reflects a nuanced understanding of the risks involved. - Furthermore, Riard has authorized attack tests on his Lightning node, part of the Alice OpenTimestamps calendar, until October 1st, emphasizing operational constraints due to the server's role in a production environment. Despite potential disruptions, the impact is considered minimal thanks to the redundancy of the OpenTimestamps protocol. This section outlines the conditions under which the testing should proceed, including reimbursement for any incurred expenses and encouragement for testers to make donations to the OTS community. - -Lastly, the email touches on Dave Harding's suggestion to establish "free-to-pwn" lightning nodes on the mainnet for conducting sophisticated cross-layer attacks like pinning. This initiative aims to bridge the gap between private testing and public verifiability, highlighting the differences in conducting attacks in testnets versus the mainnet. Antoine addresses the potential criticisms regarding the complexity of full-node software and lightning implementations, advocating for transparency and public demonstrations to uncover vulnerabilities, thereby fostering a more secure and trustworthy bitcoin ecosystem. - 2024-10-12T04:46:00+00:00 +Lastly, the email touches on Dave Harding's suggestion to establish "free-to-pwn" lightning nodes on the mainnet for conducting sophisticated cross-layer attacks like pinning. This initiative aims to bridge the gap between private testing and public verifiability, highlighting the differences in conducting attacks in testnets versus the mainnet. Antoine addresses the potential criticisms regarding the complexity of full-node software and lightning implementations, advocating for transparency and public demonstrations to uncover vulnerabilities, thereby fostering a more secure and trustworthy bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_Keyless-Anchors-Are-Vulnerable-To-Replacement-Cycling-Attacks.xml b/static/bitcoin-dev/Aug_2024/combined_Keyless-Anchors-Are-Vulnerable-To-Replacement-Cycling-Attacks.xml index c5c42af931..7f4dcc7f9c 100644 --- a/static/bitcoin-dev/Aug_2024/combined_Keyless-Anchors-Are-Vulnerable-To-Replacement-Cycling-Attacks.xml +++ b/static/bitcoin-dev/Aug_2024/combined_Keyless-Anchors-Are-Vulnerable-To-Replacement-Cycling-Attacks.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Keyless Anchors Are Vulnerable To Replacement Cycling Attacks - 2024-08-28T02:16:00.575592+00:00 - - Antoine Riard 2024-08-27 19:39:00+00:00 - - - Keagan McClelland 2024-08-02 21:58:00+00:00 - - - Peter Todd 2024-08-02 07:54:00+00:00 - + 2025-09-26T14:25:16.931528+00:00 + python-feedgen + + + Keyless Anchors Are Vulnerable To Replacement Cycling Attacks Peter Todd + 2024-08-02T07:54:00.000Z + + + Keagan McClelland + 2024-08-02T21:58:00.000Z + + + Antoine Riard + 2024-08-27T19:39:00.000Z + + - python-feedgen + 2 Combined summary - Keyless Anchors Are Vulnerable To Replacement Cycling Attacks - 2024-08-28T02:16:00.575655+00:00 + 2025-09-26T14:25:16.932111+00:00 + 2024-08-27T19:39:00+00:00 The discovery of a novel vulnerability within the Bitcoin transaction process, notably affecting transactions where fees are paid using a method known as Child Pays for Parent (CPFP) through the use of keyless ephemeral anchors, has raised concerns about the security and reliability of cryptocurrency transactions. This vulnerability facilitates what is termed a replacement cycling attack, which enables attackers to disrupt the standard processing of transactions at minimal cost, assuming they intend to transact with a higher total fee and fee-rate than their target. Central to this attack is the creation of two transactions, where the second transaction is designated to pay the fees for both. An attacker then uses a third-party transaction to replace these in the mempool by offering higher fees, rendering the original transactions uneconomical to mine due to their lower fee rate. Specifically, this attack targets transactions arranged such that transaction A is made with low or zero fees, depending on transaction B to cover its fees via CPFP. An attacker can broadcast a competing transaction B2 that spends from their own funds along with the keyless ephemeral anchor from A but at a higher fee rate than B, followed by double-spending B2 with another transaction, B3, thereby cycling out transaction B and leaving transaction A unminable. - In response to this issue, the proposal of adding an optional rebroadcasting module to Bitcoin Core has been put forward as a potential solution. The purpose of this module would be to monitor transactions that have fallen out of the mempool and ensure their reinsertion once they become valid again, hence mitigating the impact of replacement cycling attacks. However, this approach is not without its challenges. It could inadvertently act as a vector for Denial of Service (DoS) attacks, putting undue strain on node resources like memory and disk space. Additionally, the implementation of such a module introduces complexities in managing the mempool, particularly in deciding which transactions should be prioritized for eviction when conflicts arise. - Moreover, while preventing the replacement of transactions such as B2 with B3 might seem straightforward, it does not fully address the potential for new forms of exploitation by attackers. Concerns also extend to privacy, as each rebroadcast could inadvertently reveal information about the transaction's origin. To mitigate these privacy issues, it has been suggested that having third parties altruistically rebroadcast transactions could help preserve users' anonymity. For those interested in further details on this topic, Peter Todd offers additional discussion and analysis on his [personal website](https://petertodd.org). - 2024-08-27T19:39:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_Mining-pools-stratumv2-and-oblivious-shares.xml b/static/bitcoin-dev/Aug_2024/combined_Mining-pools-stratumv2-and-oblivious-shares.xml index bb798dde13..5d3f3b7414 100644 --- a/static/bitcoin-dev/Aug_2024/combined_Mining-pools-stratumv2-and-oblivious-shares.xml +++ b/static/bitcoin-dev/Aug_2024/combined_Mining-pools-stratumv2-and-oblivious-shares.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Mining pools, stratumv2 and oblivious shares - 2024-08-28T02:15:11.352385+00:00 - - Matt Corallo 2024-08-27 13:52:00+00:00 - - - Anthony Towns 2024-08-27 09:07:00+00:00 - - - Matt Corallo 2024-08-21 14:28:00+00:00 - - - Anthony Towns 2024-08-16 02:10:00+00:00 - - - Matt Corallo 2024-08-13 13:57:00+00:00 - - - Anthony Towns 2024-07-31 18:00:00+00:00 - - - Luke Dashjr 2024-07-23 18:44:00+00:00 - - - Anthony Towns 2024-07-23 15:02:00+00:00 - + 2025-09-26T14:25:06.165170+00:00 + python-feedgen + + + Mining pools, stratumv2 and oblivious shares Anthony Towns + 2024-07-23T15:02:00.000Z + + + Luke Dashjr + 2024-07-23T18:44:00.000Z + + + Anthony Towns + 2024-07-31T18:00:00.000Z + + + Matt Corallo + 2024-08-13T13:57:00.000Z + + + Anthony Towns + 2024-08-16T02:10:00.000Z + + + Matt Corallo + 2024-08-21T14:28:00.000Z + + + Anthony Towns + 2024-08-27T09:07:00.000Z + + + Matt Corallo + 2024-08-27T13:52:00.000Z + + @@ -35,19 +46,16 @@ - python-feedgen + 2 Combined summary - Mining pools, stratumv2 and oblivious shares - 2024-08-28T02:15:11.352454+00:00 + 2025-09-26T14:25:06.166162+00:00 + 2024-08-27T13:52:00+00:00 The conversation delves into the nuanced challenges and potential strategies within cryptocurrency mining, particularly focusing on block withholding attacks and the implications for mining pools. It highlights the dilemma faced by pools in distinguishing between honest miners and attackers, especially given the feasibility of such attacks even with a minor portion of the pool’s total hash rate being maliciously used. The dialogue underscores the precarious position of mining pools that do not enforce rigorous entry criteria or share validation processes, making them vulnerable to these attacks. This vulnerability is exacerbated when attackers disguise their malicious intent by distributing their hash rate across multiple low-profile accounts, complicating the detection process through statistical analysis. - A significant concern raised is the practicality of validating every submitted share to ensure its legitimacy, which could centralize the mining process, undermining the decentralized ethos of blockchain technology. Furthermore, the email debates the effectiveness of solutions like Know Your Customer (KYC) measures or limiting membership based on hash rate, suggesting these might protect pools but at the cost of decentralization. The discussion also explores hypothetical attack scenarios, illustrating how an attacker could undermine a pool’s profitability and the rewards of honest miners, thereby questioning the sustainability of pools without stringent defensive measures. - Regarding Stratum V2's design and its impact on template distribution and block withholding risks, the conversation suggests that while decentralization in work selection empowers miners, it also opens up vulnerabilities to attacks that exploit the autonomy in block submission. The critique extends to the challenges of managing a decentralized pool, emphasizing the importance of a trusted coordinator in validating work and ensuring fair reward distribution. However, this necessity poses questions about maintaining true decentralization and the effectiveness of potential solutions like oblivious shares or changes to the Proof of Work algorithm that could mitigate block withholding but require significant alterations to the mining protocol. - The discourse further examines the broader implications for Bitcoin's network design, particularly the tension between fostering decentralization and addressing pooling and centralization concerns. The mention of zero-knowledge proofs as a future solution indicates ongoing exploration for more secure and private validation methods, though acknowledging current technological and practical barriers. Lastly, the conversation acknowledges the complex dynamics of pooled mining and the continual search for a balance between innovation, security, and adherence to blockchain's foundational principles, highlighting the role of community collaboration in navigating these challenges. - 2024-08-27T13:52:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_OP-CAT-Research-Fund-sponsored-by-StarkWare.xml b/static/bitcoin-dev/Aug_2024/combined_OP-CAT-Research-Fund-sponsored-by-StarkWare.xml index 076e1133f0..f2519f2bfc 100644 --- a/static/bitcoin-dev/Aug_2024/combined_OP-CAT-Research-Fund-sponsored-by-StarkWare.xml +++ b/static/bitcoin-dev/Aug_2024/combined_OP-CAT-Research-Fund-sponsored-by-StarkWare.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - OP_CAT Research Fund sponsored by StarkWare - 2024-09-03T02:14:48.897337+00:00 - - Antoine Riard 2024-09-03 00:35:00+00:00 - - - /dev /fd 2024-08-29 16:08:00+00:00 - - - Matt Corallo 2024-08-29 14:08:00+00:00 - - - Victor Kolobov 2024-08-29 13:43:00+00:00 - - - Victor Kolobov 2024-08-29 13:18:00+00:00 - + 2025-09-26T14:25:01.901076+00:00 + python-feedgen + + + OP_CAT Research Fund sponsored by StarkWare 'Victor Kolobov' + 2024-08-29T13:18:00.000Z + + + Greg Tonoski + 2024-08-29T13:43:00.000Z + + + Matt Corallo + 2024-08-29T14:08:00.000Z + + + /dev /fd0 + 2024-08-29T16:08:00.000Z + + + Antoine Riard + 2024-09-03T00:35:00.000Z + + - python-feedgen + 2 Combined summary - OP_CAT Research Fund sponsored by StarkWare - 2024-09-03T02:14:48.897425+00:00 + 2025-09-26T14:25:01.901811+00:00 + 2024-09-03T00:35:00+00:00 The discussion encompasses a variety of topics related to Bitcoin development, particularly focusing on the post-Taproot activation landscape and the exploration of covenants or contracting primitives extending Bitcoin script. It reflects on the historical stalemate in consensus discussions since Taproot's activation in 2021, suggesting that a lack of trial-and-error design and development processes akin to those used for Schnorr/Taproot changes has hindered progress. The narrative recalls the Taproot design and development process, including debates over technical ideas, the proposal and review process, and the implementation and discussion phases leading up to its activation. - The discourse also touches upon subsequent initiatives aimed at improving Bitcoin's scripting capabilities, highlighting Jeremy's CTV proposal as a notable attempt despite its failure to gather enough support for activation. The author mentions organizing IRC meetings to facilitate open discussions among covenant developers, aiming to identify areas of agreement and divergence within the community. However, challenges such as the discontinuation of certain working groups and the lack of active participation in proposed forks like the bitcoin-inquisition are noted, pointing to a broader issue of engaging skilled contributors beyond financial incentives. - Moreover, the conversation extends to the broader Bitcoin ecosystem's communication dynamics, criticizing the dominance of FOSS veterans and the limitations of invitation-only developer meetings. It advocates for leveraging bounties to foster more open and public processes, including IRC meetings and conferences, to nurture a high-quality dialogue about Bitcoin's technical development. The author warns against repeating past mistakes, such as the blocksize war, by failing to maintain an open and public space for intellectual discussion, especially given the increasing attention from nation-states and political actors. - Additionally, there's mention of StarkWare's initiative offering a $1 million bounty for arguments regarding the activation of OP_CAT, aiming to stimulate a comprehensive community debate on its implications for Bitcoin. This includes concerns over security, potential applications, and the overall impact on the Bitcoin ecosystem. The committee overseeing this initiative is composed of prominent figures from various organizations, emphasizing the importance of community contributions to the ongoing discourse around OP_CAT's role in Bitcoin's future development. - In parallel, advancements in blockchain technology are highlighted, including projects aimed at enhancing interoperability, streamlining cryptographic procedures within Bitcoin, and exploring decentralized finance (DeFi) mechanisms like Automated Market Makers (AMM). The discussion points to specific efforts in developing on-chain decentralized exchanges (DEX) and reducing transaction confirmation times, illustrating the wide-ranging research and development activities underway within the blockchain space. - 2024-09-03T00:35:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_OP-ZKP-updates.xml b/static/bitcoin-dev/Aug_2024/combined_OP-ZKP-updates.xml index a5efee2a34..a2004d12cc 100644 --- a/static/bitcoin-dev/Aug_2024/combined_OP-ZKP-updates.xml +++ b/static/bitcoin-dev/Aug_2024/combined_OP-ZKP-updates.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - OP_ZKP updates - 2024-10-15T02:24:46.644195+00:00 - - Weiji Guo 2024-10-14 09:00:00+00:00 - - - Weiji Guo 2024-08-28 15:33:00+00:00 - - - Weiji Guo 2024-07-22 22:38:00+00:00 - - - Weikeng Chen 2024-07-22 18:45:00+00:00 - - - Weiji Guo 2024-07-22 14:05:00+00:00 - + 2025-09-26T14:25:10.513498+00:00 + python-feedgen + + + OP_ZKP updates Weiji Guo + 2024-07-22T14:05:00.000Z + + + Weikeng Chen + 2024-07-22T18:45:00.000Z + + + Weiji Guo + 2024-07-22T22:38:00.000Z + + + Weiji Guo + 2024-08-28T15:33:00.000Z + + + Weiji Guo + 2024-10-14T09:00:00.000Z + + - python-feedgen + 2 Combined summary - OP_ZKP updates - 2024-10-15T02:24:46.644247+00:00 + 2025-09-26T14:25:10.514335+00:00 - The recent updates in cryptographic solutions within the domain of open application circuits emphasize a shift towards recursive verification to streamline the process. This approach negates the requirement to publish each application circuit's verification key on-chain, opting instead for a singular circuit verified through recursion. A dedicated GitHub organization and repository, named "tea-horse," have been established to facilitate the sharing of ideas and developments related to this innovative strategy. While the repository is currently in the early stages of development, it is expected to become a valuable resource for those interested in contributing to or understanding the project further. The links to both the GitHub organization and the specific repository are made available for easy access. - + 2024-10-14T09:00:00+00:00 + The recent updates in cryptographic solutions within the domain of open application circuits emphasize a shift towards recursive verification to streamline the process. This approach negates the requirement to publish each application circuit's verification key on-chain, opting instead for a singular circuit verified through recursion. A dedicated GitHub organization and repository, named "tea-horse," have been established to facilitate the sharing of ideas and developments related to this innovative strategy. While the repository is currently in the early stages of development, it is expected to become a valuable resource for those interested in contributing to or understanding the project further. The links to both the GitHub organization and the specific repository are made available for easy access. The discussion also delves into the technical requisites for implementing Dory, a cryptographic solution that necessitates pairing-friendly curves, contrasting with secp256k1's lack of support for pairing operations. This distinction underscores the importance of selecting cryptographic curves that align with the operational requirements of Dory, highlighting its need for pairing to function properly. Despite Dory's promise in terms of transparency and efficiency, its larger proof size compared to other solutions presents a challenge, illustrating the complexities involved in choosing a cryptographic framework that balances technical specifications with desired outcomes such as transparency and scalability. - Weiji Guo highlighted a technical limitation regarding the compatibility of Dory with secp256k1, pointing out that Dory's reliance on pairing operations, which secp256k1 does not support, poses a significant hurdle. This highlights the need for further exploration or alternative solutions to overcome this compatibility issue, reflecting a nuanced understanding of cryptographic principles necessary to address these challenges. - The OP_ZKP proposal aims to integrate Zero-Knowledge Proofs within Bitcoin transactions by identifying an appropriate ZKP scheme that meets several high-level requirements. These include minimal security assumptions, small block size consumption, and the capability for batched verification and aggregated proving without necessitating a trusted setup. The Inner Product Argument (IPA) emerges as a potential candidate due to its transparent setup, compatibility with secp256k1, and relatively small proof size. However, challenges such as linear verification time and scalability of verification keys remain. Aggregated proving techniques are suggested to mitigate these issues, although concerns about the deployment of large verification keys and the overall system complexity persist. Future considerations involve evaluating the performance impact on lower-powered devices and potentially exploring alternative schemes like Dory, should unresolved issues with IPA persist. For those interested in further reading on SNARKs misconceptions and Torus-based optimization, additional resources are provided, including detailed articles from [a16zcrypto](https://a16zcrypto.com/posts/article/17-misconceptions-about-snarks/section--11) and links to a video and paper discussing Torus optimization. - 2024-10-14T09:00:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml b/static/bitcoin-dev/Aug_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml index 74bdc74a4c..a34b9d2b77 100644 --- a/static/bitcoin-dev/Aug_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml +++ b/static/bitcoin-dev/Aug_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Proposing a P2QRH BIP towards a quantum resistant soft fork - 2024-09-26T03:18:36.202311+00:00 - - Hunter Beast 2024-09-25 12:04:00+00:00 - - - Antoine Riard 2024-08-22 06:20:00+00:00 - - - Hunter Beast 2024-08-15 05:05:00+00:00 - - - Hunter Beast 2024-08-06 17:37:00+00:00 - - - Antoine Riard 2024-07-13 01:34:00+00:00 - - - hunter 2024-06-17 20:27:00+00:00 - - - Antoine Riard 2024-06-17 01:07:00+00:00 - - - Hunter Beast 2024-06-14 14:28:00+00:00 - - - PierreLuc DallaireDemers 2024-06-14 13:51:00+00:00 - - - Hunter Beast 2024-06-08 21:04:00+00:00 - + 2025-09-26T14:25:21.224337+00:00 + python-feedgen + + + Proposing a P2QRH BIP towards a quantum resistant soft fork Hunter Beast + 2024-06-08T21:04:00.000Z + + + Pierre-Luc Dallaire-Demers + 2024-06-14T13:51:00.000Z + + + Hunter Beast + 2024-06-14T14:28:00.000Z + + + Antoine Riard + 2024-06-17T01:07:00.000Z + + + hunter + 2024-06-17T20:27:00.000Z + + + Antoine Riard + 2024-07-13T01:34:00.000Z + + + Hunter Beast + 2024-08-06T17:37:00.000Z + + + Hunter Beast + 2024-08-15T05:05:00.000Z + + + Antoine Riard + 2024-08-22T06:20:00.000Z + + + Hunter Beast + 2024-09-25T12:04:00.000Z + + @@ -43,21 +56,17 @@ - python-feedgen + 2 Combined summary - Proposing a P2QRH BIP towards a quantum resistant soft fork - 2024-09-26T03:18:36.202392+00:00 + 2025-09-26T14:25:21.225518+00:00 + 2024-09-25T12:04:00+00:00 The recent discussions and updates surrounding the development of a Bitcoin Improvement Proposal (BIP) to introduce quantum resistance into Bitcoin's cryptographic framework underscore the community's proactive approach towards safeguarding the cryptocurrency against potential quantum computing threats. Central to these discussions is the acknowledgment of IBM's advancements in quantum computing, particularly with its Quantum System Two, which potentially supports up to 16,000 qubits. This advancement hints at a future where quantum computing could significantly impact cryptographic security, necessitating the exploration of post-quantum cryptographic algorithms. - The discourse extends beyond merely recognizing the threat, delving into specific cryptographic considerations and solutions. For example, the integration of FALCON, a post-quantum signature algorithm, into the proposed BIP reflects a thoughtful response to the nuanced challenges posed by quantum computing. This choice is indicative of the community's effort to balance security needs with practical implementation concerns such as signature size and transaction costs. The dialogue also touches on broader strategic issues, including the potential for increased witness discounts to accommodate larger transactions, underscoring the ongoing effort to maintain Bitcoin's scalability and security in tandem. - Moreover, the discussions reveal an awareness of the limitations and uncertainties inherent in predicting quantum computing's progression. References to IBM's roadmap and the need for cautious optimism highlight the complex interplay between technological advancement and cryptographic security. The conversation acknowledges the diversity of quantum computing architectures and their implications for cryptographic attacks, emphasizing the importance of a robust, adaptable approach to security. - Significantly, the proposal outlines defensive measures that Bitcoin users can implement today, such as configuring spending scripts to require artificially inflated witness stacks. This strategy exemplifies the multifaceted approach needed to address quantum threats, combining immediate practical measures with long-term cryptographic evolution. The suggestion to use trusted mining pools for transaction submission further illustrates the community's willingness to explore diverse strategies to mitigate risk. - In summary, the ongoing dialogue around introducing quantum resistance to Bitcoin through a dedicated BIP reflects a comprehensive and forward-looking approach to cryptocurrency security. It underscores the community's commitment to addressing emerging threats through research, collaboration, and innovation. The inclusion of FALCON signatures and the consideration of various post-quantum cryptographic schemes highlight the technical complexity of this endeavor, while discussions about implementation strategies and the potential impact on transaction throughput reveal the broader strategic considerations at play. As the landscape of quantum computing continues to evolve, the Bitcoin community's proactive engagement with these challenges will be crucial in ensuring the cryptocurrency's resilience and longevity. - 2024-09-25T12:04:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_Public-disclosure-of-2-vulnerabilities-affecting-Bitcoin-Core-v22-0.xml b/static/bitcoin-dev/Aug_2024/combined_Public-disclosure-of-2-vulnerabilities-affecting-Bitcoin-Core-v22-0.xml index 1e30630d54..1983082ca8 100644 --- a/static/bitcoin-dev/Aug_2024/combined_Public-disclosure-of-2-vulnerabilities-affecting-Bitcoin-Core-v22-0.xml +++ b/static/bitcoin-dev/Aug_2024/combined_Public-disclosure-of-2-vulnerabilities-affecting-Bitcoin-Core-v22-0.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Public disclosure of 2 vulnerabilities affecting Bitcoin Core < v22.0 - 2024-08-05T02:11:09.512200+00:00 - - hashnoncemessage 2024-08-04 06:41:00+00:00 - - - Peter Todd 2024-07-31 19:01:00+00:00 - - - Niklas Goegge 2024-07-31 17:01:00+00:00 - + 2025-09-26T14:25:14.814487+00:00 + python-feedgen + + + Public disclosure of 2 vulnerabilities affecting Bitcoin Core < v22.0 Niklas Goegge + 2024-07-31T17:01:00.000Z + + + Peter Todd + 2024-07-31T19:01:00.000Z + + + hashnoncemessage' + 2024-08-04T06:41:00.000Z + + - python-feedgen + 2 Combined summary - Public disclosure of 2 vulnerabilities affecting Bitcoin Core < v22.0 - 2024-08-05T02:11:09.512245+00:00 + 2025-09-26T14:25:14.815054+00:00 + 2024-08-04T06:41:00+00:00 Recent discussions have brought to light two critical security vulnerabilities that have raised concerns within the digital security community. These vulnerabilities, revealed in reverse chronological order on the advisories page, highlight the ongoing challenges faced in cybersecurity regarding the dissemination and management of sensitive information. The first vulnerability involves the potential for OP Nodes to be spammed with addr messages, leading to possible crashes. This issue was addressed with a fix released on September 14th, 2021, in Bitcoin Core v22.0. Similarly, a fix for nodes potentially being crashed by malicious UPnP devices on the local network was also released on the same date in Bitcoin Core v22.0. - The communication underscores the importance of clear, detailed information about these vulnerabilities to understand their implications fully and implement necessary mitigation measures. A link to [https://petertodd.org](https://petertodd.org) is provided for those seeking more comprehensive details, indicating a resource for further exploration of these issues. - Additionally, Bitcoin Core has been proactive in enhancing its security framework through the adoption of a new vulnerability disclosure policy. This initiative aims to systematically reveal resolved vulnerabilities, starting with those fixed in version v23.0 to be disclosed later in August, followed by version v24.0 disclosures in September. This schedule continues with announcements for older, unmaintained versions, ensuring all known vulnerabilities are eventually made public. This approach reflects Bitcoin Core's commitment to transparency and security, marking a significant advancement in how vulnerability disclosures are managed. Detailed information regarding this policy and the specific advisories can be accessed via the [security advisories page](https://bitcoincore.org/en/security-advisories) on the Bitcoin Core website, reinforcing the project's dedication to safeguarding its infrastructure against potential threats. - 2024-08-04T06:41:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2024/combined_Re-HODL-Tax-Proposal.xml b/static/bitcoin-dev/Aug_2024/combined_Re-HODL-Tax-Proposal.xml index d00cd46386..b454e5a31f 100644 --- a/static/bitcoin-dev/Aug_2024/combined_Re-HODL-Tax-Proposal.xml +++ b/static/bitcoin-dev/Aug_2024/combined_Re-HODL-Tax-Proposal.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Re: HODL Tax Proposal - 2024-08-03T02:07:09.049176+00:00 - - hashnoncemessage 2024-08-02 05:08:00+00:00 - - - George Burke 2024-08-02 02:03:00+00:00 - - - Jimmy Song 2024-08-02 01:19:00+00:00 - - - Keagan McClelland 2024-08-02 00:28:00+00:00 - - - Keagan McClelland 2024-08-02 00:12:00+00:00 - - - George Burke 2024-08-01 23:38:00+00:00 - - - José Edil Guimarães de Medeiros 2024-08-01 21:59:00+00:00 - - - Christian Riley 2024-08-01 21:55:00+00:00 - - - Richard Greaser 2024-08-01 21:03:00+00:00 - + 2025-09-26T14:25:23.338099+00:00 + python-feedgen + + + Richard Greaser + 2024-08-01T21:03:00.000Z + + + HODL Tax Proposal Christian Riley + 2024-08-01T21:55:00.000Z + + + José Edil Guimarães de Medeiros + 2024-08-01T21:59:00.000Z + + + George Burke + 2024-08-01T23:38:00.000Z + + + Keagan McClelland + 2024-08-02T00:12:00.000Z + + + Keagan McClelland + 2024-08-02T00:28:00.000Z + + + Jimmy Song + 2024-08-02T01:19:00.000Z + + + George Burke + 2024-08-02T02:03:00.000Z + + + hashnoncemessage' + 2024-08-02T05:08:00.000Z + + @@ -39,19 +51,16 @@ - python-feedgen + 2 Combined summary - Re: HODL Tax Proposal - 2024-08-03T02:07:09.049254+00:00 + 2025-09-26T14:25:23.339217+00:00 - The discourse within the Bitcoin development community has recently delved into the feasibility and implications of introducing a demurrage fee system within the Bitcoin network. This concept, aimed at incentivizing the movement of coins to support miners post-halving events by imposing fees on inactive coins, has sparked spirited debate. At the core of the discussion is the challenge this proposal presents to Bitcoin's foundational principles and technical framework. For instance, Bitcoin's design does not inherently recognize time-based metrics like "days" beyond difficulty adjustments, nor does it facilitate direct deductions from balances in a manner akin to traditional financial systems. This underscores a fundamental misunderstanding of Bitcoin's operational mechanics, where miners compete rather than collaborate on block discovery, focusing on cryptographic proof over legal norms. - + 2024-08-02T05:08:00+00:00 + The discourse within the Bitcoin development community has recently delved into the feasibility and implications of introducing a demurrage fee system within the Bitcoin network. This concept, aimed at incentivizing the movement of coins to support miners post-halving events by imposing fees on inactive coins, has sparked spirited debate. At the core of the discussion is the challenge this proposal presents to Bitcoin's foundational principles and technical framework. For instance, Bitcoin's design does not inherently recognize time-based metrics like "days" beyond difficulty adjustments, nor does it facilitate direct deductions from balances in a manner akin to traditional financial systems. This underscores a fundamental misunderstanding of Bitcoin's operational mechanics, where miners compete rather than collaborate on block discovery, focusing on cryptographic proof over legal norms. Moreover, the dialogue touches on the philosophical misalignments of such a proposal with Bitcoin’s ethos. The critique extends to the practicality and ethical considerations of central planning aspects inherent in a demurrage system, such as determining inactivity periods and setting fees. This notion diverges significantly from Bitcoin's decentralized, market-driven approach, emphasizing the value of holders who, by maintaining their assets, contribute to the scarcity and, by extension, the value of the network. This highlights a critical perspective that active usage should not be the sole metric for contributing to the ecosystem's health. - George Burke, a notable figure in the Bitcoin community, has articulated opposition to the idea of a network tax on owned property. He argues that this concept essentially penalizes asset holders, undermining traditional notions of ownership by imposing additional costs for non-utilization. Burke emphasizes that transaction fees paid at acquisition and upon every transfer already serve as a form of network contribution. Holders, or HODLers as they are commonly referred to within the cryptocurrency space, play a vital role in reinforcing the network's value through scarcity. This stance advocates for a broader recognition of the varying ways individuals can contribute to the network's growth and stability without necessitating active transactional behavior. - In conclusion, the discussions surrounding the implementation of a demurrage fee within Bitcoin raise significant concerns regarding its compatibility with the network’s foundational principles and operational design. These conversations underscore the need for a deeper understanding of Bitcoin's technical and philosophical underpinnings before proposing substantial changes. George Burke’s insights further illuminate the importance of acknowledging the intrinsic value holders bring to the ecosystem, challenging the premise that only active participants contribute to the network’s worth. - 2024-08-02T05:08:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Add-BIP-0093-Codex32-as-application-to-BIP-0085.xml b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Add-BIP-0093-Codex32-as-application-to-BIP-0085.xml index 8ebc6ddb0b..059eb5b3a7 100644 --- a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Add-BIP-0093-Codex32-as-application-to-BIP-0085.xml +++ b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Add-BIP-0093-Codex32-as-application-to-BIP-0085.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - [BIP Proposal] Add BIP-0093 (Codex32) as application to BIP-0085 - 2025-09-09T02:31:28.716754+00:00 - - Aneesh Karve 2025-09-07 23:13:00+00:00 - - - Aneesh Karve 2025-09-07 20:42:00+00:00 - - - Ben Westgate 2025-09-03 00:44:00+00:00 - - - Javier Mateos 2025-09-02 02:30:00+00:00 - - - Ben Westgate 2025-09-01 18:37:00+00:00 - - - Javier Mateos 2025-09-01 08:41:00+00:00 - - - Ben Westgate 2025-08-31 22:25:00+00:00 - + 2025-09-26T14:34:37.585060+00:00 + python-feedgen + + + [BIP Proposal] Add BIP-0093 (Codex32) as application to BIP-0085 'Ben Westgate' + 2025-08-31T22:25:00.000Z + + + Javier Mateos + 2025-09-01T08:41:00.000Z + + + Ben Westgate' + 2025-09-01T18:37:00.000Z + + + Javier Mateos + 2025-09-02T02:30:00.000Z + + + Ben Westgate' + 2025-09-03T00:44:00.000Z + + + Aneesh Karve + 2025-09-07T20:42:00.000Z + + + Aneesh Karve + 2025-09-07T23:13:00.000Z + + @@ -31,21 +41,17 @@ - python-feedgen + 2 Combined summary - [BIP Proposal] Add BIP-0093 (Codex32) as application to BIP-0085 - 2025-09-09T02:31:28.716821+00:00 + 2025-09-26T14:34:37.585986+00:00 + 2025-09-07T23:13:00+00:00 The recent discussions and developments around the integration of BIP-0093, also known as codex32, within the framework of BIP-0085 have garnered significant attention in the cryptocurrency community. This proposed integration aims to leverage BIP-0085's capabilities for generating deterministic entropy from BIP32 keychains to create codex32 strings directly from BIP-0032 master keys. Codex32 is designed to enhance the security and reliability of cryptographic seed storage and recovery by introducing features such as error correction, hand verification, identifiers, and secret sharing capabilities, surpassing those available through the existing BIP-39 application. The feedback received has been largely positive, with specific commendations for its potential to facilitate recoverable child codex32 strings for scenarios involving forgetful relatives, thereby improving the overall user experience in managing wallet backups. - In response to the feedback, substantial updates have been made to address concerns and clarify implementation details. Notably, modifications include the incorporation of pseudocode to elucidate the character value selection process and adjustments to the documentation to more clearly define conditions under which certain parameters are set. These changes aim to ensure a uniform application across different tools that utilize BIP-85 derivation, fostering consistency and technical robustness in the implementation of codex32. Furthermore, a recent commit has documented these updates in the project repository, indicating a proactive approach to incorporating community input into the proposal’s development process. - One area of focus in the ongoing discussion has been the need for greater clarity in the specification, particularly regarding the derivation paths and the usage of human-readable prefixes (hrp) and identifiers. Suggestions have been made to simplify or clarify the derivation paths and provide more detailed explanations of each path segment to aid future implementers. Additionally, there is an emphasis on refining the reference implementation to align with the latest version to avoid confusion and compatibility issues. - Ben Westgate's proposal for integrating BIP-0093 (codex32) with BIP-0085 is outlined in detail, highlighting the methodological approach towards utilizing BIP-85 for generating codex32 backups directly from BIP-0032 master keys. This proposition not only aims to standardize the generation of codex32 backups but also underscores the advantages of codex32 over BIP-39, including its error correction capabilities and secret sharing attributes. The initiative has seen supportive momentum, with draft PRs and potential applications being explored to enhance interoperability and ease of use across systems. - Feedback from the community is crucial to the ongoing development and refinement of this proposal. Interested parties are encouraged to review the detailed insights and participate in further discussions, which can be found in the proposal documentation linked here: [BIP-0093 Proposal](https://github.com/bitcoin/bips/compare/master.BenWestgate:bips:codex32). This collaborative effort reflects the commitment of the Bitcoin Development community to enhance and rigorously assess the technical soundness of proposals, aiming to streamline wallet backup processes and improve interoperability across the cryptocurrency ecosystem. - 2025-09-07T23:13:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Elliptic-Curve-Operations-for-Bitcoin-Script.xml b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Elliptic-Curve-Operations-for-Bitcoin-Script.xml index 8e75e263e4..5d88df17a3 100644 --- a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Elliptic-Curve-Operations-for-Bitcoin-Script.xml +++ b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Elliptic-Curve-Operations-for-Bitcoin-Script.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - [BIP Proposal] Elliptic Curve Operations for Bitcoin Script - 2025-09-02T02:42:16.810149+00:00 - - jeremy 2025-09-01 22:43:00+00:00 - - - jeremy 2025-08-25 16:45:00+00:00 - - - Olaoluwa Osuntokun 2025-08-25 00:50:00+00:00 - + 2025-09-26T14:34:29.065310+00:00 + python-feedgen + + + [BIP Proposal] Elliptic Curve Operations for Bitcoin Script Olaoluwa Osuntokun + 2025-08-25T00:50:00.000Z + + + jeremy + 2025-08-25T16:45:00.000Z + + + jeremy + 2025-09-01T22:43:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Elliptic Curve Operations for Bitcoin Script - 2025-09-02T02:42:16.810194+00:00 + 2025-09-26T14:34:29.065811+00:00 + 2025-09-01T22:43:00+00:00 The proposal to enhance Bitcoin's scripting language by introducing new Elliptic Curve (EC) operation op codes is aimed at leveraging the Taproot infrastructure to expand the blockchain's capabilities in facilitating complex operations directly within its script. This initiative paves the way for the computation of the top-level Taproot output public key using Bitcoin Script, enabling a more dynamic approach to creating smart contracts on the Bitcoin blockchain. The integration of these op codes, including `OP_EC_POINT_ADD`, `OP_EC_POINT_MUL`, `OP_EC_POINT_NEGATE`, and `OP_EC_POINT_X_COORD`, is designed to broaden the range of functional operations available to developers, thereby fostering the development of versatile smart contracts and innovative applications such as optimized Discreet Log Contracts (DLCs), partial musig2 signature verifications, and EC-based sigma protocols. - A specific aspect of the proposal highlights the introduction of an operation named *OP_EC_LIFT_X_EVEN*, which seeks to counteract the effects of *OP_EC_POINT_X_COORD* with some limitations due to parity considerations, useful in conjunction with *OP_IKEY*. Moreover, the proposal suggests the addition of *OP_EC_GENERATOR* to simplify script composability by pushing the generator point G onto the stack directly, which addresses the ambiguity associated with representing G as 0 and facilitates a more intuitive execution of operations involving the point at infinity. This modification is expected to streamline processes like *OP_TWEAKADD* by enabling a more coherent sequence of generating a point, multiplication, lifting, and adding points together. - These proposed changes aim to rectify and clarify the procedures for elliptic curve operations within Bitcoin's scripting language, addressing current shortcomings and inaccuracies. By doing so, they set the stage for more accurate and efficient implementations of elliptic curve operations in Bitcoin scripts. For those interested in the technical specifics or contributing to the ongoing discussion, comprehensive details can be accessed through the Bitcoin Improvement Proposal (BIP) [here](https://github.com/bitcoin/bips/pull/1945), alongside a reference implementation for `btcd` available [here](https://github.com/btcsuite/btcd/pull/2413). Through these enhancements, Bitcoin's scripting language is poised for significant advancements in its ability to support complex and secure on-chain logic implementations, marking a substantial step forward in the evolution of Bitcoin's scripting functionalities. - 2025-09-01T22:43:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-No-burn-Quantum-Migration-Proposal-Quantum-Secure-Asset-Verification-Escrow-QSAVE-.xml b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-No-burn-Quantum-Migration-Proposal-Quantum-Secure-Asset-Verification-Escrow-QSAVE-.xml index a2534b9f1f..7bb4dfd669 100644 --- a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-No-burn-Quantum-Migration-Proposal-Quantum-Secure-Asset-Verification-Escrow-QSAVE-.xml +++ b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-No-burn-Quantum-Migration-Proposal-Quantum-Secure-Asset-Verification-Escrow-QSAVE-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) - 2025-09-16T02:27:19.692898+00:00 - - conduition 2025-09-15 16:52:00+00:00 - - - James T 2025-08-24 22:24:00+00:00 - - - Erik Aronesty 2025-08-19 20:59:00+00:00 - - - conduition 2025-08-19 15:01:00+00:00 - - - James T 2025-08-19 10:43:00+00:00 - - - James T 2025-08-14 21:26:00+00:00 - - - conduition 2025-08-09 01:33:00+00:00 - - - James T 2025-08-04 21:18:00+00:00 - + 2025-09-26T14:34:14.136810+00:00 + python-feedgen + + + [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) 'James T' + 2025-08-04T21:18:00.000Z + + + conduition' + 2025-08-09T01:33:00.000Z + + + James T' + 2025-08-14T21:26:00.000Z + + + Javier Mateos + 2025-08-19T10:43:00.000Z + + + conduition' + 2025-08-19T15:01:00.000Z + + + Erik Aronesty + 2025-08-19T20:59:00.000Z + + + James T' + 2025-08-24T22:24:00.000Z + + + conduition' + 2025-09-15T16:52:00.000Z + + @@ -35,23 +46,18 @@ - python-feedgen + 2 Combined summary - [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) - 2025-09-16T02:27:19.692982+00:00 + 2025-09-26T14:34:14.137856+00:00 + 2025-09-15T16:52:00+00:00 The discussion surrounding the future of Bitcoin's cryptographic security, particularly in light of potential vulnerabilities exposed by advancements in quantum computing, reveals a complex landscape of technical challenges and proposed solutions. At the heart of these deliberations is the notion that the decentralized and algorithm-driven ethos of Bitcoin may, paradoxically, necessitate human intervention to navigate unforeseen technological threats such as the advent of quantum computing capable of breaking current cryptographic safeguards. - One of the primary concerns discussed is the vulnerability of Bitcoin’s Elliptic Curve Digital Signature Algorithm (ECDSA) to quantum decryption, posing a significant risk to the integrity and ownership verification mechanisms of the blockchain. The suggested responses to this threat range from consensus-based updates to the cryptographic algorithms underpinning Bitcoin to more radical proposals advocating for a managed transition to quantum-resistant signatures. Such measures underscore the community's willingness to adaptively manage the blockchain's security in response to evolving technological landscapes, emphasizing a collective approach to decision-making and protocol evolution. - Within this context, various proposals have been put forward, including soft-fork upgrades to introduce quantum-resistant algorithms and innovative methods to secure existing wallets against quantum attacks. These approaches highlight a proactive stance towards securing Bitcoin against future threats while maintaining continuity and stability within the network. The discourse also explores the utilization of zero-knowledge proofs and commit/reveal protocols as potential mechanisms for enhancing security without compromising decentralization principles, indicating a nuanced exploration of technical solutions that align with Bitcoin's foundational tenets. - However, the conversation also acknowledges the limitations and challenges associated with these technical solutions, such as the difficulty in protecting certain types of wallets and the broader implications of significant protocol changes on the Bitcoin ecosystem. This includes concerns over centralization, the ethical and practical ramifications of integrating Know Your Customer (KYC) measures, and the potential for contentious forks that could fracture the community. These discussions reflect an ongoing negotiation between innovation and pragmatism, underscoring the importance of community consensus and legal considerations in shaping the future trajectory of Bitcoin's development. - Moreover, proposals like the Quantum Secure Asset Verification & Escrow (QSAVE) initiative represent a blend of technical foresight and social responsibility, proposing a mechanism not only to protect vulnerable Bitcoins from quantum threats but also to leverage these assets for public good. This reflects a broader recognition within the community of the need to balance technological advancement with ethical stewardship and a commitment to public welfare. - In conclusion, the dialogue around securing Bitcoin against quantum computing threats illustrates a multifaceted approach encompassing technical innovation, community consensus-building, and ethical consideration. It highlights the cryptocurrency community's readiness to confront emerging challenges through adaptive problem-solving and collaborative decision-making, rooted in a desire to preserve the integrity, decentralization, and visionary promise of Bitcoin in the face of evolving technological landscapes. - 2025-09-15T16:52:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-OP-TWEAKADD.xml b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-OP-TWEAKADD.xml index 536caf7cd9..efb2b64286 100644 --- a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-OP-TWEAKADD.xml +++ b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-OP-TWEAKADD.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - [BIP Proposal] OP_TWEAKADD - 2025-09-08T02:44:06.618906+00:00 - - jeremy 2025-09-06 21:27:00+00:00 - - - Olaoluwa Osuntokun 2025-09-04 22:46:00+00:00 - - - Olaoluwa Osuntokun 2025-09-04 02:38:00+00:00 - - - jeremy 2025-08-23 18:24:00+00:00 - - - jeremy 2025-08-23 17:35:00+00:00 - + 2025-09-26T14:34:22.604974+00:00 + python-feedgen + + + [BIP Proposal] OP_TWEAKADD jeremy + 2025-08-23T17:35:00.000Z + + + jeremy + 2025-08-23T18:24:00.000Z + + + Olaoluwa Osuntokun + 2025-09-04T02:38:00.000Z + + + Olaoluwa Osuntokun + 2025-09-04T22:46:00.000Z + + + jeremy + 2025-09-06T21:27:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] OP_TWEAKADD - 2025-09-08T02:44:06.618962+00:00 + 2025-09-26T14:34:22.605650+00:00 + 2025-09-06T21:27:00+00:00 The ongoing discussions among Bitcoin developers have brought to light several key considerations and proposals aimed at refining the protocol's security and functionality. A significant point of discussion has been the potential adjustment of the operational cost associated with a new opcode, specifically considering its computational demands relative to existing operations such as `OP_CHECKSIG`. The debate underscores the importance of aligning opcode costs with their computational requirements to ensure the efficiency and security of script operations within the Bitcoin network. This conversation is part of a broader effort to continually optimize Bitcoin's scripting capabilities, reflecting the community's commitment to advancing the protocol. - In addition to opcode cost considerations, there has been detailed deliberation on the use of cryptographic techniques within the Bitcoin Improvement Proposal framework. Specifically, the introduction of tweak reveal scripts in BIP-348 and BIP-349 proposes utilizing combinations of operations like OP_TWEAKADD to enable complex cryptographic functions. These include signature composition and message verification through tailored witness and program structures, emphasizing the enhancement of security and flexibility in transaction verification processes. Techniques such as Proof-of-Signing-Order and delegation mechanisms further illustrate the sophistication of these proposed advancements, aiming to bolster the sequential integrity of signatures and provide versatile frameworks for signing authority management. - Jeremy's recent draft BIP proposing the OP_TWEAKADD opcode highlights another facet of the ongoing technical discourse within the Bitcoin development community. The proposal, which aims to enhance scripting capabilities by allowing for more efficient execution of on-chain operations, reflects careful consideration of design choices such as push versus verify semantics and the arrangement of arguments. The decision to advocate for a plain tweak, as opposed to a hashed version, indicates a preference for simplicity and flexibility, leaving room for future enhancements that could further refine the protocol's cryptographic operations. - These discussions and proposals collectively represent the Bitcoin development community's proactive approach to addressing the complexities and challenges of cryptocurrency protocol enhancement. By focusing on optimizing operational costs, advancing cryptographic techniques, and refining scripting capabilities, the community demonstrates an enduring commitment to securing and improving the Bitcoin network. For further exploration of these topics, including the detailed conversation surrounding the acceptance of compressed public keys over x-only keys in the musig2 BIP, interested readers can refer to the documented discussion [here](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/020756.html). - 2025-09-06T21:27:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Utreexo-Nodes.xml b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Utreexo-Nodes.xml index 347ce54a0f..7e7da85aff 100644 --- a/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Utreexo-Nodes.xml +++ b/static/bitcoin-dev/Aug_2025/combined_-BIP-Proposal-Utreexo-Nodes.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - [BIP Proposal] Utreexo Nodes - 2025-08-13T03:00:00.244983+00:00 - - Calvin Kim 2025-08-10 06:58:00+00:00 - - - Murch 2025-08-06 22:36:00+00:00 - - - K Calvin 2025-07-30 14:20:00+00:00 - - - Javier Mateos 2025-07-30 02:33:00+00:00 - - - Calvin Kim 2025-07-29 23:20:00+00:00 - + 2025-09-26T14:34:33.360069+00:00 + python-feedgen + + + [BIP Proposal] Utreexo Nodes Calvin Kim + 2025-07-29T23:20:00.000Z + + + Javier Mateos + 2025-07-30T02:33:00.000Z + + + K Calvin + 2025-07-30T14:20:00.000Z + + + Murch + 2025-08-06T22:36:00.000Z + + + Calvin Kim + 2025-08-10T06:58:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Utreexo Nodes - 2025-08-13T03:00:00.245038+00:00 + 2025-09-26T14:34:33.360853+00:00 + 2025-08-10T06:58:00+00:00 Calvin Kim has successfully submitted a pull request for review, as indicated by the communication from Murch, which is part of the ongoing discussions within the Bitcoin Development Mailing List. This particular effort is highlighted in the process of developing and refining Bitcoin Improvement Proposals (BIPs), specifically around the concept of Utreexo. Utreexo's main aim is to enhance the efficiency and scalability of Bitcoin transactions by introducing a method that allows for transaction verification without the full Unspent Transaction Output (UTXO) set. The contributions of Tadge Dryja, Davidson Souza, and Calvin are pivotal in this regard, proposing three distinct BIPs focusing on different aspects of Utreexo: the accumulator specifications, the validation process of Bitcoin blocks and transactions through the accumulator, and the necessary adjustments within peer-to-peer networking to support Utreexo nodes. - The collaborative nature of these developments emphasizes the iterative feedback and review process inherent to the Bitcoin open-source community. Javier Mateos' review of the draft proposals acknowledges their progress and alignment with editorial standards, encouraging further refinement and submission when ready. This reflects the constructive engagement and support within the community, aiming at continuous improvement and innovation. - A specific point of discussion concerns the segregation of functionalities across the proposed BIPs, particularly the deliberate choice to exclude Bitcoin-related operations from the accumulator BIP to maintain focus and clarity. However, an identified gap in the current specifications pertains to the lack of a defined deterministic order for processing UTXO deletions and additions, a detail crucial for the accumulator's consistency and reliability. This highlights both the depth of analysis already undertaken and the areas requiring further attention to ensure the robustness of the proposed changes. - Moreover, the division of Utreexo into three layers—accumulator, validation, and peer-to-peer (P2P)—is designed to facilitate the review process and integration into the Bitcoin ecosystem. This structured approach demonstrates a clear vision for Utreexo's role in enhancing blockchain infrastructure, addressing both theoretical and practical considerations in its development. The community's engagement through platforms like GitHub, as seen in the provision of links to access the BIP documents ([https://github.com/utreexo/biptreexo](https://github.com/utreexo/biptreexo)), exemplifies the open and collaborative effort towards refining these proposals. Through such endeavors, Utreexo aims to contribute significantly to the scalability and decentralization of Bitcoin's network, marking an important step forward in blockchain technology. - 2025-08-10T06:58:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_-Draft-BIP-Quantum-Resistant-Transition-Framework-for-Bitcoin.xml b/static/bitcoin-dev/Aug_2025/combined_-Draft-BIP-Quantum-Resistant-Transition-Framework-for-Bitcoin.xml index dede085475..98a1616adc 100644 --- a/static/bitcoin-dev/Aug_2025/combined_-Draft-BIP-Quantum-Resistant-Transition-Framework-for-Bitcoin.xml +++ b/static/bitcoin-dev/Aug_2025/combined_-Draft-BIP-Quantum-Resistant-Transition-Framework-for-Bitcoin.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin - 2025-08-27T02:46:29.086688+00:00 - - Bitcoin Foundation 2025-08-21 20:21:00+00:00 - - - ArmchairCryptologist 2025-08-20 20:15:00+00:00 - - - Alex Pruden 2025-08-20 20:07:00+00:00 - - - Murch 2025-08-20 17:14:00+00:00 - - - Bitcoin Foundation 2025-08-12 22:47:00+00:00 - - - ArmchairCryptologist 2025-08-09 19:38:00+00:00 - - - Bitcoin Foundation 2025-08-09 05:26:00+00:00 - - - conduition 2025-08-09 01:04:00+00:00 - - - Bitcoin Foundation 2025-08-07 18:18:00+00:00 - + 2025-09-26T14:34:39.735170+00:00 + python-feedgen + + + [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin 'Bitcoin Foundation' + 2025-08-07T18:18:00.000Z + + + conduition' + 2025-08-09T01:04:00.000Z + + + Bitcoin Foundation' + 2025-08-09T05:26:00.000Z + + + ArmchairCryptologist' + 2025-08-09T19:38:00.000Z + + + Bitcoin Foundation' + 2025-08-12T22:47:00.000Z + + + Murch + 2025-08-20T17:14:00.000Z + + + Alex Pruden + 2025-08-20T20:07:00.000Z + + + ArmchairCryptologist' + 2025-08-20T20:15:00.000Z + + + Bitcoin Foundation' + 2025-08-21T20:21:00.000Z + + @@ -39,23 +51,18 @@ - python-feedgen + 2 Combined summary - [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin - 2025-08-27T02:46:29.086765+00:00 + 2025-09-26T14:34:39.736226+00:00 + 2025-08-21T20:21:00+00:00 The discourse on making Bitcoin quantum-resistant has been a focal point of debate within the cryptographic and blockchain communities. A recent proposal aimed at enhancing Bitcoin's resilience against potential quantum computing threats has sparked discussions, addressing both the urgency and methodology of such a transition. This conversation is underpinned by concerns that quantum computing advancements could eventually compromise the cryptographic foundations of Bitcoin, particularly ECDSA and Schnorr signatures, which are vulnerable to decryption by algorithms like Shor's algorithm. - The proposal outlines a comprehensive, phased approach to transition Bitcoin to quantum-resistant cryptography. This strategy is designed with an emphasis on minimizing disruption and ensuring backward compatibility. It suggests the initial soft-fork activation of quantum-resistant witness programs, leading to a gradual deprecation of classical ECDSA outputs. The ultimate goal is to freeze classical UTXOs to secure them against quantum-assisted theft. This multifaceted plan aims to provide market certainty, encourage adoption through progressive pressure, and adhere to the principle that users who neglect repeated warnings face consequences. Such an approach acknowledges the significant portion of Bitcoin's value that is at risk due to exposed public keys from address reuse, emphasizing the need for caution and proactive measures. - Central to this proposal is the adoption of SPHINCS+-SHAKE256f (SLH-DSA-SHAKE-256f) as the quantum-resistant cryptographic scheme of choice. This selection is justified by its robust properties against quantum attacks, offering a secure alternative to existing encryption methods. The proposal details technical specifications, including signature sizes and resistance levels to quantum computing attacks, providing a solid foundation for the proposed migration. - Moreover, the transition requires concerted efforts across the Bitcoin ecosystem, necessitating upgrades and adaptations from hardware wallets, exchanges, miners, and light clients. This collective move towards quantum-resistant protocols is crucial for maintaining the network's security integrity in the face of advancing quantum technology. Stakeholders are encouraged to engage with the proposal, offering feedback to refine and enhance the plan before its final implementation. - In parallel discussions, critiques have been raised regarding certain aspects of the quantum resistance proposal, highlighting areas of misunderstanding and improvement. These include underestimations of the computational power needed to break current encryption standards with quantum computers, misconceptions about the security limitations of Bitcoin addresses, and the necessity of considering alternative cryptographic signing algorithms. Furthermore, concerns about the feasibility and implications of freezing UTXOs without a clear unlocking mechanism suggest the potential need for a hard fork, underscoring the complexity of transitioning to a quantum-resistant framework. - This ongoing dialogue underscores the importance of collaborative effort and thorough vetting in developing a secure, future-proofed Bitcoin protocol. It reflects the community's commitment to safeguarding Bitcoin against emerging technological threats, ensuring its long-term viability and trustworthiness as a digital currency. - 2025-08-21T20:21:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_A-Post-Quantum-Migration-Proposal.xml b/static/bitcoin-dev/Aug_2025/combined_A-Post-Quantum-Migration-Proposal.xml index 26784ef9fd..31b875c2b5 100644 --- a/static/bitcoin-dev/Aug_2025/combined_A-Post-Quantum-Migration-Proposal.xml +++ b/static/bitcoin-dev/Aug_2025/combined_A-Post-Quantum-Migration-Proposal.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - A Post Quantum Migration Proposal - 2025-09-16T02:26:25.679229+00:00 - - conduition 2025-09-15 16:24:00+00:00 - - - Saint Wenhao 2025-08-23 10:22:00+00:00 - - - conduition 2025-08-22 19:59:00+00:00 - - - Saint Wenhao 2025-08-19 08:55:00+00:00 - - - Marc Johnson 2025-08-16 18:40:00+00:00 - - - Jameson Lopp 2025-08-12 14:56:00+00:00 - - - Marc Johnson 2025-07-25 10:58:00+00:00 - - - Boris Nagaev 2025-07-20 22:54:00+00:00 - - - Marin Ivezic 2025-07-20 17:39:00+00:00 - - - conduition 2025-07-20 15:56:00+00:00 - - - conduition 2025-07-20 15:37:00+00:00 - - - Peter Todd 2025-07-19 12:05:00+00:00 - - - Antoine Riard 2025-07-18 19:13:00+00:00 - - - Boris Nagaev 2025-07-16 17:34:00+00:00 - - - conduition 2025-07-16 16:43:00+00:00 - - - Ethan Heilman 2025-07-15 17:57:00+00:00 - - - Boris Nagaev 2025-07-15 14:13:00+00:00 - - - Boris Nagaev 2025-07-15 02:50:00+00:00 - - - conduition 2025-07-15 02:32:00+00:00 - - - Jameson Lopp 2025-07-14 18:52:00+00:00 - - - Ethan Heilman 2025-07-14 16:08:00+00:00 - - - Jameson Lopp 2025-07-14 13:50:00+00:00 - - - Antoine Riard 2025-07-14 02:07:00+00:00 - - - Tadge Dryja 2025-07-13 23:19:00+00:00 - - - Jameson Lopp 2025-07-12 21:36:00+00:00 - + 2025-09-26T14:34:26.943800+00:00 + python-feedgen + + + A Post Quantum Migration Proposal Jameson Lopp + 2025-07-12T21:36:00.000Z + + + Tadge Dryja + 2025-07-13T23:19:00.000Z + + + Antoine Riard + 2025-07-14T02:07:00.000Z + + + Jameson Lopp + 2025-07-14T13:50:00.000Z + + + Ethan Heilman + 2025-07-14T16:08:00.000Z + + + Jameson Lopp + 2025-07-14T18:52:00.000Z + + + conduition' + 2025-07-15T02:32:00.000Z + + + Boris Nagaev + 2025-07-15T02:50:00.000Z + + + Boris Nagaev + 2025-07-15T14:13:00.000Z + + + Ethan Heilman + 2025-07-15T17:57:00.000Z + + + conduition' + 2025-07-16T16:43:00.000Z + + + Boris Nagaev + 2025-07-16T17:34:00.000Z + + + Antoine Riard + 2025-07-18T19:13:00.000Z + + + Peter Todd + 2025-07-19T12:05:00.000Z + + + conduition' + 2025-07-20T15:37:00.000Z + + + conduition' + 2025-07-20T15:56:00.000Z + + + Marin Ivezic + 2025-07-20T17:39:00.000Z + + + Boris Nagaev + 2025-07-20T22:54:00.000Z + + + Marc Johnson + 2025-07-25T10:58:00.000Z + + + Jameson Lopp + 2025-08-12T14:56:00.000Z + + + Marc Johnson + 2025-08-16T18:40:00.000Z + + + Saint Wenhao + 2025-08-19T08:55:00.000Z + + + conduition' + 2025-08-22T19:59:00.000Z + + + Saint Wenhao + 2025-08-23T10:22:00.000Z + + + conduition' + 2025-09-15T16:24:00.000Z + + @@ -103,17 +131,15 @@ - python-feedgen + 2 Combined summary - A Post Quantum Migration Proposal - 2025-09-16T02:26:25.679400+00:00 + 2025-09-26T14:34:26.946428+00:00 + 2025-09-15T16:24:00+00:00 The discourse on enhancing Bitcoin's defense against quantum computing threats posits a phased proposal to transition the network towards post-quantum cryptographic standards. This approach is rooted in the urgency to protect the network against potential quantum attacks that could compromise its cryptographic underpinnings. By introducing a new post-quantum output type (P2QRH) and setting a timeline for phasing out legacy ECDSA/Schnorr signatures, the proposal aims to preemptively secure Bitcoin's future. The initial phase mandates stopping transactions to quantum-vulnerable addresses, advocating for a swift migration to P2QRH address types. Subsequently, spending from quantum-vulnerable UTXOs would be deemed invalid, halting transactions reliant on traditional cryptographic methods. An optional third phase explores the possibility of recovering frozen assets through zero-knowledge proofs, pending further research and consensus within the community. - This strategic initiative underscores the critical need for a proactive stance against the quantum threat, motivated by recent advancements in quantum algorithms and NIST's endorsement of post-quantum signature schemes. A successful quantum breach could drastically erode confidence in Bitcoin, inflicting substantial economic repercussions. Hence, the proposal articulates a defensive maneuver, prescribing deadlines for adopting quantum-resistant cryptographic practices to galvanize stakeholders across the Bitcoin ecosystem towards a unified response. - The proposal delineates specific expectations from various ecosystem participants, including miners, institutional holders, exchanges, custodians, and regular users, highlighting the tailored incentives for each group to upgrade. This collective effort aims to diminish the attack surface and mitigate potential losses, portraying the shift to quantum-resistant cryptography as a communal benefit. Moreover, it addresses the technical feasibility of implementing these changes via soft forks, ensuring backward compatibility and offering a gradual, inclusive path towards enhancing Bitcoin's resilience in the quantum era. - 2025-09-15T16:24:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml b/static/bitcoin-dev/Aug_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml index b787d0798f..9b34ba0b9d 100644 --- a/static/bitcoin-dev/Aug_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml +++ b/static/bitcoin-dev/Aug_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml @@ -1,95 +1,23 @@ - + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747215+00:00 - - conduition 2025-08-09 19:53:00+00:00 - - - conduition 2025-07-15 13:53:00+00:00 - - - Jameson Lopp 2025-07-13 21:26:00+00:00 - - - Pieter Wuille 2025-07-13 19:28:00+00:00 - - - Boris Nagaev 2025-07-13 17:51:00+00:00 - - - Ethan Heilman 2025-07-13 16:01:00+00:00 - - - Or Sattath 2025-07-13 15:38:00+00:00 - - - Boris Nagaev 2025-07-13 14:20:00+00:00 - - - Jameson Lopp 2025-07-13 12:34:00+00:00 - - - Boris Nagaev 2025-07-13 01:39:00+00:00 - - - Jameson Lopp 2025-06-08 14:04:00+00:00 - - - waxwing/ AdamISZ 2025-06-07 13:28:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 21:15:00+00:00 - - - Sjors Provoost 2025-05-28 07:46:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 01:07:00+00:00 - - - ArmchairCryptologist 2025-05-26 15:40:00+00:00 - - - Agustin Cruz 2025-05-26 00:32:00+00:00 - - - Dustin Ray 2025-05-25 23:03:00+00:00 - - - conduition 2025-05-25 19:03:00+00:00 - - - Agustin Cruz 2025-03-24 11:19:00+00:00 - - - AstroTown 2025-03-22 19:02:00+00:00 - - - Sjors Provoost 2025-03-18 12:48:00+00:00 - - - Jameson Lopp 2025-03-17 13:28:00+00:00 - - - Matt Corallo 2025-03-17 12:00:00+00:00 - - - IdeA 2025-03-16 22:56:00+00:00 - - - Jameson Lopp 2025-03-16 21:25:00+00:00 - - - Jameson Lopp 2025-03-16 19:44:00+00:00 - - - Jameson Lopp 2025-03-16 18:03:00+00:00 - - - Jameson Lopp 2025-03-16 14:15:00+00:00 - + 2025-09-26T14:34:31.246841+00:00 + python-feedgen + + + Or Sattath + 2025-07-13T15:38:00.000Z + + + conduition' + 2025-07-15T13:53:00.000Z + + + conduition' + 2025-08-09T19:53:00.000Z + + @@ -119,21 +47,17 @@ - python-feedgen + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747403+00:00 + 2025-09-26T14:34:31.247462+00:00 + 2025-08-09T19:53:00+00:00 The discourse delves into the intricate challenges and potential approaches for integrating post-quantum cryptography within Bitcoin's framework, highlighting a proactive stance towards enhancing security against quantum computing threats. A notable proposal involves incorporating a form of post-quantum cryptography, specifically through an OP_HASHBASEDSIG mechanism, potentially utilizing SPHINCS+, to embed quantum-resistant public keys into wallet outputs. This suggestion underscores the urgency of preparing for quantum advancements well in advance, advocating for the embedding of these public keys at least a decade prior to any enforcement action to ensure ample safety margins. - The dialogue further explores the ethical and practical considerations surrounding the handling of Bitcoin funds that may become vulnerable to quantum decryption. The debate oscillates between two primary courses of action: leaving such funds accessible, thereby susceptible to potential quantum theft, or proactively rendering them unspendable to preemptively secure them against quantum capabilities. This discussion touches upon core Bitcoin principles including censorship resistance, forward compatibility, and conservatism. The ethical implications are profound, weighing the prevention of economic disruption against the fairness and property rights implications of either allowing or preventing quantum-enabled theft. - Historical precedents within the Bitcoin protocol's evolution serve as reference points for this debate, suggesting a tendency towards remedying vulnerabilities rather than exploiting them. The conversation acknowledges the complexity of incentivizing the ecosystem-wide adoption of quantum-resistant technologies through measures possibly as radical as burning vulnerable coins. - Furthermore, the exchange considers the broader implications of quantum recovery and the potential redistribution of wealth from those without access to quantum technology to those who might achieve quantum supremacy. This raises significant questions about the balance between ensuring long-term security and adhering to Bitcoin's foundational principles of decentralization and user sovereignty. - In addressing the potential quantum threat, the dialogue encapsulates a meticulous examination of both the technical feasibility of implementing quantum-resistant cryptographic methods and the philosophical underpinnings guiding these decisions. It reflects an ongoing effort among developers and stakeholders to navigate the evolving landscape of digital currency security thoughtfully, emphasizing the need for community consensus and careful consideration of Bitcoin's core values in the face of emerging technological challenges. - 2025-08-09T19:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_BIP-Booby-Trapped-Wallets-Covenant-Only-Taproot-Outputs.xml b/static/bitcoin-dev/Aug_2025/combined_BIP-Booby-Trapped-Wallets-Covenant-Only-Taproot-Outputs.xml index 9ef1b04a64..611f5e7cc1 100644 --- a/static/bitcoin-dev/Aug_2025/combined_BIP-Booby-Trapped-Wallets-Covenant-Only-Taproot-Outputs.xml +++ b/static/bitcoin-dev/Aug_2025/combined_BIP-Booby-Trapped-Wallets-Covenant-Only-Taproot-Outputs.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - BIP Booby Trapped Wallets - Covenant-Only Taproot Outputs - 2025-09-12T02:25:15.315423+00:00 - - Matias Monteagudo 2025-09-11 09:47:00+00:00 - - - Matias Monteagudo 2025-08-21 17:46:00+00:00 - + 2025-09-26T14:34:24.724683+00:00 + python-feedgen + + + BIP Booby Trapped Wallets - Covenant-Only Taproot Outputs Matias Monteagudo + 2025-08-21T17:46:00.000Z + + + Matias Monteagudo + 2025-09-11T09:47:00.000Z + + - python-feedgen + 2 Combined summary - BIP Booby Trapped Wallets - Covenant-Only Taproot Outputs - 2025-09-12T02:25:15.315484+00:00 + 2025-09-26T14:34:24.725104+00:00 + 2025-09-11T09:47:00+00:00 The proposal in question introduces a cutting-edge approach designed to bolster the security of Bitcoin wallets, particularly catering to the needs of institutional holders with significant Bitcoin assets. Authored by Matias Monteagudo, this Bitcoin Improvement Proposal (BIP) advocates for an additional, voluntary security layer that could fundamentally alter how high-value Bitcoin wallets defend against unauthorized access. Central to this proposal is the concept of covenant-only Taproot outputs, which essentially prohibit key-path spending—a conventional method allowing transactions to be signed off directly with a private key—thereby enforcing transactions to exclusively proceed via script-path spending. This mechanism not only restricts transactions to pre-approved destinations but also cleverly conceals these restrictions until an actual attempt at unauthorized access is made, thus adding a robust layer of security while maintaining transaction privacy until it's necessary to reveal such details. - The underlying motivation for this BIP stems from the escalating security risks faced by large-scale Bitcoin operators, such as exchanges, where the visible nature of current security protocols does little to deter advanced cyber threats. By enabling wallet owners to limit transaction flows to specified destinations and automatically diverting any unauthorized transactions to so-called arbitration wallets, the proposed system aims to maintain operational normalcy, thereby deterring potential attackers who rely on preemptive knowledge of security measures. The technical groundwork for implementing these covenant-only Taproot outputs involves invalidating the internal key to make key-path spending nonviable, ensuring all transactions comply with the set covenant conditions. A detailed activation plan adheres to the BIP 9 framework, calling for widespread miner consensus before this new protocol can take effect, assuring backward compatibility to preserve the existing ecosystem's integrity. - From a security standpoint, the proposal meticulously outlines cryptographic safeguards to render the internal key unusable, thus blocking direct path spending avenues. It further suggests concealing the covenant logic to prevent attackers from identifying and exploiting potential vulnerabilities ahead of their malicious attempts. On the economic front, the proposal posits that creating a high-risk environment for theft, promoting fair arbitration practices, and highlighting the network-wide benefits of improved security protocols could collectively enhance the Bitcoin network's resilience against attacks without sacrificing privacy or efficiency. Final sections of the proposal include reference implementations for essential validation logic, wallet integration guidelines, and test vectors to assess the proposal's practical viability. The document closes with acknowledgments to the broader Bitcoin development community and credits to the creators of the Taproot script commitment scheme, indicating a phased review, testing, and eventual deployment strategy aimed at significantly enhancing institutional Bitcoin security without compromising the user experience or network performance. - 2025-09-11T09:47:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_Introducing-Hourglass.xml b/static/bitcoin-dev/Aug_2025/combined_Introducing-Hourglass.xml index d3ee97c592..ee0faae439 100644 --- a/static/bitcoin-dev/Aug_2025/combined_Introducing-Hourglass.xml +++ b/static/bitcoin-dev/Aug_2025/combined_Introducing-Hourglass.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Introducing Hourglass - 2025-08-27T02:40:55.584812+00:00 - - Saint Wenhao 2025-08-23 17:49:00+00:00 - - - Hunter Beast 2025-05-04 06:00:00+00:00 - - - Francis Pouliot 2025-05-02 15:45:00+00:00 - - - Saint Wenhao 2025-05-02 13:58:00+00:00 - - - Agustin Cruz 2025-05-01 18:23:00+00:00 - - - Nagaev Boris 2025-05-01 17:38:00+00:00 - - - Jameson Lopp 2025-05-01 11:38:00+00:00 - - - Michael Tidwell 2025-04-30 03:01:00+00:00 - - - Hunter Beast 2025-04-29 22:38:00+00:00 - + 2025-09-26T14:34:20.482163+00:00 + python-feedgen + + + Introducing Hourglass Hunter Beast + 2025-04-29T22:38:00.000Z + + + Michael Tidwell + 2025-04-30T03:01:00.000Z + + + Jameson Lopp + 2025-05-01T11:38:00.000Z + + + Nagaev Boris + 2025-05-01T17:38:00.000Z + + + Agustin Cruz + 2025-05-01T18:23:00.000Z + + + Saint Wenhao + 2025-05-02T13:58:00.000Z + + + Francis Pouliot + 2025-05-02T15:45:00.000Z + + + Hunter Beast + 2025-05-04T06:00:00.000Z + + + Saint Wenhao + 2025-08-23T17:49:00.000Z + + @@ -39,25 +51,19 @@ - python-feedgen + 2 Combined summary - Introducing Hourglass - 2025-08-27T02:40:55.584889+00:00 + 2025-09-26T14:34:20.483250+00:00 + 2025-08-23T17:49:00+00:00 The discussion regarding the handling and security of Bitcoin in the face of potential quantum computing threats reveals a multifaceted approach to preserving the currency's stability and integrity. The conversation begins with an examination of the implications that quantum computing may have on Bitcoin, particularly focusing on Pay-to-PubKey (P2PK) coins. The proposal to limit P2PK spends to one per block is highlighted as a strategy to incite bidding wars among miners, potentially benefiting them through increased transaction fees derived from quantum-retrieved coins. This method is noted for its feasibility without necessitating any soft forks, leveraging existing operations like OP_SIZE combined with either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY to restrict coin spendability based on Proof of Work. This approach, detailed on [BitcoinTalk](https://bitcointalk.org/index.php?topic=5551080.msg65724436msg65724436), could enforce a time lock on transactions, varying the unlock period depending on the signature size. - The discourse also covers broader implications of trading volumes and price volatility on Bitcoin's security. Michael Tidwell's email criticizes a proposal to manage Bitcoin’s price through spending restrictions, arguing against viewing price volatility as a security issue due to the market's capacity to absorb significant Bitcoin quantities without destabilizing prices. This argument underscores the inherent price fluctuations within the cryptocurrency market and challenges the notion that artificial controls on spending could enforce price stability. - -Further, the conversation delves into strategies for transitioning Bitcoin to a quantum-resistant framework, suggesting that instead of permanently rendering coins inaccessible ("burning"), they could be temporarily "trapped" using a reversible mechanism. This would allow for a potential return to ECDSA if necessary, ensuring the continuity of historical blockchain transaction verifications. Such strategic foresight emphasizes preserving access to assets under new cryptographic standards, reflecting a cautious approach to future-proofing against quantum vulnerabilities. - +Further, the conversation delves into strategies for transitioning Bitcoin to a quantum-resistant framework, suggesting that instead of permanently rendering coins inaccessible ("burning"), they could be temporarily "trapped" using a reversible mechanism. This would allow for a potential return to ECDSA if necessary, ensuring the continuity of historical blockchain transaction verifications. Such strategic foresight emphasizes preserving access to assets under new cryptographic standards, reflecting a cautious approach to future-proofing against quantum vulnerabilities. The Quantum Resistant Address Migration Proposal (QRAMP) introduces a proactive measure against quantum-capable attackers by mandating the migration of unspent P2PK outputs to quantum-resistant addresses before a specified deadline. This initiative aims to invalidate unmoved coins post-deadline, safeguarding them from quantum exploitation by removing their spendability through consensus, illustrating an aggressive yet decisive strategy to protect the currency from quantum threats. - A nuanced perspective on the tactics a quantum computing capable entity might employ to maximize gains in the cryptocurrency space discusses the benefits of publicly broadcasting transactions to ensure their inclusion by other miners. This contrasts with a private broadcast, which limits UTXO claims to blocks mined by the entity itself. The discussion highlights strategic considerations for such entities, including diversifying UTXOs for broadcasting and self-mining to maintain mining momentum and streamline operations. - Boris Nagaev critiques a proposal aimed at dampening quantum attacks' economic impact, pointing out its inadequacy given the rapid capabilities of quantum computers to exploit cryptographic keys. Nagaev's skepticism extends to the strategy's inability to preemptively address high-value targets likely to be attacked first, indicating a need for a more comprehensive approach to mitigating potential quantum-induced economic shocks. - -Lastly, the dialogue explores the concept of allowing early P2PK coins to be "naturally recycled" without modifying their scripts, advocating for a method that respects Bitcoin's technical, cultural, and moral ethos over more drastic measures. This contemplation reflects on the possible scenarios involving mining pools and quantum computing entities, emphasizing the complex dynamics at play in securing Bitcoin against advanced technological threats without undermining its foundational principles. The significant attention to detail and consideration of various strategies and their implications underscore the community's commitment to navigating the evolving landscape of cryptocurrency security. - 2025-08-23T17:49:00+00:00 +Lastly, the dialogue explores the concept of allowing early P2PK coins to be "naturally recycled" without modifying their scripts, advocating for a method that respects Bitcoin's technical, cultural, and moral ethos over more drastic measures. This contemplation reflects on the possible scenarios involving mining pools and quantum computing entities, emphasizing the complex dynamics at play in securing Bitcoin against advanced technological threats without undermining its foundational principles. The significant attention to detail and consideration of various strategies and their implications underscore the community's commitment to navigating the evolving landscape of cryptocurrency security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_New-BIP-Editors-1-Year-Later.xml b/static/bitcoin-dev/Aug_2025/combined_New-BIP-Editors-1-Year-Later.xml index 6e66f4aea1..8557b0c6f3 100644 --- a/static/bitcoin-dev/Aug_2025/combined_New-BIP-Editors-1-Year-Later.xml +++ b/static/bitcoin-dev/Aug_2025/combined_New-BIP-Editors-1-Year-Later.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - New BIP Editors: 1 Year Later - 2025-08-13T02:59:28.232471+00:00 - - Anthony Towns 2025-08-12 05:33:00+00:00 - - - Jon Atack 2025-07-21 21:52:00+00:00 - - - Ava Chow 2025-07-15 01:01:00+00:00 - + 2025-09-26T14:34:35.471411+00:00 + python-feedgen + + + New BIP Editors: 1 Year Later 'Ava Chow' + 2025-07-15T01:01:00.000Z + + + Jon Atack + 2025-07-21T21:52:00.000Z + + + Anthony Towns + 2025-08-12T05:33:00.000Z + + - python-feedgen + 2 Combined summary - New BIP Editors: 1 Year Later - 2025-08-13T02:59:28.232516+00:00 + 2025-09-26T14:34:35.472091+00:00 + 2025-08-12T05:33:00+00:00 The recent period has seen a significant shift in the dynamics and efficiency of the Bitcoin Improvement Proposal (BIP) process, primarily attributed to the introduction of new BIP Editors. These changes have been a catalyst for enhanced productivity and collaboration within the community, as evidenced by the uptick in various metrics such as comments left, Pull Requests (PRs) merged, PRs closed, and BIP numbers assigned. The statistics starkly illustrate the impact of these new editors on the BIP process, showcasing an impressive increase in activity and engagement compared to the period before their integration. This surge not only underscores the rejuvenation of the BIP process but also the critical role that active and committed editors play in sustaining and advancing this initiative. - Despite these positive developments, the distribution of workload among the editors appears uneven, with a few individuals shouldering the majority of the tasks. This situation highlights a potential imbalance in commitment levels among the current BIP Editors, raising questions about the overall effectiveness and sustainability of the team's composition. Such observations suggest that there may be merit in reevaluating the roles and contributions of the editors, considering adjustments that could promote a more equitable distribution of responsibilities. This reevaluation could involve exploring mechanisms for rotating editors or introducing term limits to ensure that the editorial team remains dynamic, engaged, and effectively serves the community's needs. - Jon Atack and Murch have emerged as notably active contributors, significantly influencing daily operations and collaborative efforts within the BIP process. Their involvement has led to improved coordination and prevented the complexities that can arise from having an excessive number of individuals directly involved. Additionally, the support and expertise of other editors, albeit less visible, have been instrumental in facilitating discussions on BIP issues and ensuring responsiveness. This balance between active day-to-day involvement by some editors and the as-needed consultation with others has created an effective and streamlined approach to managing the BIP repository. It represents a model of collaboration that is both efficient and scalable, catering to the evolving needs of the Bitcoin development community. - 2025-08-12T05:33:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_Revisiting-secp256r1-signatures-i-e-P256-mobile-HSM-support-.xml b/static/bitcoin-dev/Aug_2025/combined_Revisiting-secp256r1-signatures-i-e-P256-mobile-HSM-support-.xml index 510c7b5dc6..a2ba4645bd 100644 --- a/static/bitcoin-dev/Aug_2025/combined_Revisiting-secp256r1-signatures-i-e-P256-mobile-HSM-support-.xml +++ b/static/bitcoin-dev/Aug_2025/combined_Revisiting-secp256r1-signatures-i-e-P256-mobile-HSM-support-.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - Revisiting secp256r1 signatures (i.e. P256, mobile HSM support) - 2025-08-27T02:43:37.558941+00:00 - - Javier Mateos 2025-08-19 11:15:00+00:00 - - - Josh Doman 2025-08-08 20:48:00+00:00 - - - conduition 2025-07-23 15:40:00+00:00 - - - Greg Tonoski 2025-07-23 08:49:00+00:00 - - - Josh Doman 2025-07-22 21:44:00+00:00 - + 2025-09-26T14:34:16.254406+00:00 + python-feedgen + + + Revisiting secp256r1 signatures (i.e. P256, mobile HSM support) Josh Doman + 2025-07-22T21:44:00.000Z + + + Greg Tonoski + 2025-07-23T08:49:00.000Z + + + conduition' + 2025-07-23T15:40:00.000Z + + + Josh Doman + 2025-08-08T20:48:00.000Z + + + Javier Mateos + 2025-08-19T11:15:00.000Z + + - python-feedgen + 2 Combined summary - Revisiting secp256r1 signatures (i.e. P256, mobile HSM support) - 2025-08-27T02:43:37.559011+00:00 + 2025-09-26T14:34:16.255088+00:00 + 2025-08-19T11:15:00+00:00 The recent discussions on the Bitcoin Development Mailing List have shed light on various aspects of integrating new cryptographic standards into the Bitcoin protocol, specifically focusing on the P256 curve's compatibility with modern internet and mobile devices. The conversation begins by acknowledging the challenges associated with this integration, including achieving community consensus and the technical hurdles of implementing a high-quality solution comparable to the current libsecp256k1 library. Despite these challenges, the dialogue underscores the potential benefits of P256 integration, such as improving the onboarding experience for new users, enhancing the security of hot wallets, and reducing costs associated with collaborative multisigs. However, concerns about the timing of such an integration are raised, considering the ongoing development of post-quantum cryptographic solutions that may shift the community's focus away from P256. - Further discussion delves into the WebAuthn standard's compatibility with Bitcoin's security needs, particularly in the context of hardware security modules (HSM) and post-quantum cryptography. The discourse suggests that researching how to adapt WebAuthn's signature formats for Bitcoin might offer a productive path toward ensuring long-term security and utility. Nonetheless, there are significant concerns regarding WebAuthn's suitability for Bitcoin, given its design for centralized web authentication and the lack of support for key features like deterministic backup seeds for user recovery and compatibility with hierarchical deterministic wallets. - In addition to exploring the technical and practical aspects of integrating P256 and WebAuthn standards into Bitcoin, the conversation also revisits historical apprehensions within the Bitcoin community regarding P256. These include fears over potential backdoors introduced by NIST, although such concerns have diminished over time. The argument for adopting P256 centers on its promise to enhance user experience and security, despite its slower validation times compared to secp256k1. The potential for P256 to enable secure access to platform APIs for HSMs on mobile devices is highlighted as a significant advantage, suggesting a compelling case for reevaluating P256 support within the Bitcoin ecosystem. - Concurrently, the discussion touches upon the apprehensions around reintroducing the OP_CAT vulnerability through the guise of secp256r1 support. This concern points to broader issues of security and the relevance of certain technical arguments to the core functionality and safety of the Bitcoin protocol. The mention of existing technologies like Samsung's Blockchain Keystore indicates that solutions for secure cryptocurrency management on mobile devices already exist, challenging the necessity and relevance of some proposed changes. - Overall, the exchange on the mailing list reflects a deep and multifaceted debate over the future of Bitcoin's cryptographic standards, balancing the need for advancement and compatibility with modern technologies against the imperatives of security, user autonomy, and the preservation of fundamental features that define the cryptocurrency. The discussion encapsulates a broad spectrum of viewpoints and considerations, from the technical specifics of cryptographic curves to the philosophical underpinnings of Bitcoin's design and use. - 2025-08-19T11:15:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_Taproot-is-post-quantum-secure-when-restricted-to-script-path-spends.xml b/static/bitcoin-dev/Aug_2025/combined_Taproot-is-post-quantum-secure-when-restricted-to-script-path-spends.xml index 049c068493..cc0a6ffdaa 100644 --- a/static/bitcoin-dev/Aug_2025/combined_Taproot-is-post-quantum-secure-when-restricted-to-script-path-spends.xml +++ b/static/bitcoin-dev/Aug_2025/combined_Taproot-is-post-quantum-secure-when-restricted-to-script-path-spends.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Taproot is post-quantum secure when restricted to script-path spends - 2025-08-04T03:22:49.056880+00:00 - - Ethan Heilman 2025-08-03 17:42:00+00:00 - - - Maxim Orlovsky 2025-07-31 09:22:00+00:00 - - - Tim Ruffing 2025-07-23 11:03:00+00:00 - + 2025-09-26T14:34:11.950849+00:00 + python-feedgen + + + Taproot is post-quantum secure when restricted to script-path spends Tim Ruffing + 2025-07-23T11:03:00.000Z + + + Maxim Orlovsky + 2025-07-31T09:22:00.000Z + + + Ethan Heilman + 2025-08-03T17:42:00.000Z + + - python-feedgen + 2 Combined summary - Taproot is post-quantum secure when restricted to script-path spends - 2025-08-04T03:22:49.056955+00:00 + 2025-09-26T14:34:11.951390+00:00 + 2025-08-03T17:42:00+00:00 The discussion around the quantum security of taproot wallets, as brought up by Maxim in his communication, highlights a nuanced understanding of the vulnerabilities associated with quantum computing. It is pointed out that wallet descriptors with public keys, once exposed, could leave taproot wallets susceptible to quantum attacks despite script-spending paths that are generally considered secure. This assertion challenges the prevailing assumption of taproot's invulnerability to such futuristic threats. Furthermore, the concern extends to the potential for quantum-powered miners or nodes to alter transactions maliciously, substituting them with different ones, thus undermining the transactional integrity within the Bitcoin network. - -In contrast, a research paper from the Cryptology ePrint Archive, titled "The Post-Quantum Security of Bitcoin's Taproot as a Commitment Scheme," offers a more optimistic view on the matter. According to [the paper](https://eprint.iacr.org/2025/1307), under the quantum random oracle model (QROM) which assumes SHA256's robustness against quantum attacks, Taproot outputs cannot be manipulated by an attacker to reveal an unexpected Merkle root. This finding significantly bolsters the argument for Bitcoin's resilience against quantum threats, particularly in its scripting capabilities. The paper advocates for a two-phase softfork upgrade to incorporate post-quantum signatures into Bitcoin's scripting language, a suggestion aligned with Matt Corallo and others' proposals. The initial phase would introduce these signatures, and the second phase, anticipatory of the emergence of large-scale quantum computing, would discontinue Schnorr and ECDSA signatures for transaction verification. - +In contrast, a research paper from the Cryptology ePrint Archive, titled "The Post-Quantum Security of Bitcoin's Taproot as a Commitment Scheme," offers a more optimistic view on the matter. According to [the paper](https://eprint.iacr.org/2025/1307), under the quantum random oracle model (QROM) which assumes SHA256's robustness against quantum attacks, Taproot outputs cannot be manipulated by an attacker to reveal an unexpected Merkle root. This finding significantly bolsters the argument for Bitcoin's resilience against quantum threats, particularly in its scripting capabilities. The paper advocates for a two-phase softfork upgrade to incorporate post-quantum signatures into Bitcoin's scripting language, a suggestion aligned with Matt Corallo and others' proposals. The initial phase would introduce these signatures, and the second phase, anticipatory of the emergence of large-scale quantum computing, would discontinue Schnorr and ECDSA signatures for transaction verification. The study meticulously quantifies the challenge posed to quantum attackers, noting that a minimum of 2^81 SHA256 evaluations would be required to compromise a Taproot output with a 50% success rate. It delineates the improbability of assembling the requisite quantum computational power under current technological constraints, effectively setting a security threshold below the aspirational 2^128 level but still within a range deemed adequate against existing quantum capabilities. With this stance, the research shifts the spotlight back onto classical computing advancements as the more immediate threat to Taproot's security rather than quantum computing. The paper concludes that without significant breakthroughs in quantum algorithms, the latter does not currently pose a substantial risk to the integrity of script-path spends within the Bitcoin ecosystem. This perspective underscores the importance of ongoing vigilance against classical computational threats that could potentially undermine the secure framework established by Bitcoin's taproot mechanism before quantum computing becomes a viable concern. - 2025-08-03T17:42:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2025/combined_Workshops-and-Activation-for-CHECKTEMPLATEVERIFY-and-CHECKSIGFROMSTACK.xml b/static/bitcoin-dev/Aug_2025/combined_Workshops-and-Activation-for-CHECKTEMPLATEVERIFY-and-CHECKSIGFROMSTACK.xml index e4bcb1a801..a3e5cd669d 100644 --- a/static/bitcoin-dev/Aug_2025/combined_Workshops-and-Activation-for-CHECKTEMPLATEVERIFY-and-CHECKSIGFROMSTACK.xml +++ b/static/bitcoin-dev/Aug_2025/combined_Workshops-and-Activation-for-CHECKTEMPLATEVERIFY-and-CHECKSIGFROMSTACK.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - Workshops and Activation for CHECKTEMPLATEVERIFY and CHECKSIGFROMSTACK - 2025-09-06T02:27:21.902689+00:00 - - Antoine Riard 2025-08-27 17:13:00+00:00 - - - Antoine Riard 2025-08-24 23:23:00+00:00 - - - /dev /fd 2025-08-22 03:28:00+00:00 - - - Antoine Riard 2025-08-20 18:23:00+00:00 - - - /dev /fd 2025-08-17 20:07:00+00:00 - + 2025-09-26T14:34:18.367277+00:00 + python-feedgen + + + Workshops and Activation for CHECKTEMPLATEVERIFY and CHECKSIGFROMSTACK /dev /fd0 + 2025-08-17T20:07:00.000Z + + + Antoine Riard + 2025-08-20T18:23:00.000Z + + + /dev /fd0 + 2025-08-22T03:28:00.000Z + + + Antoine Riard + 2025-08-24T23:23:00.000Z + + + Antoine Riard + 2025-08-27T17:13:00.000Z + + - python-feedgen + 2 Combined summary - Workshops and Activation for CHECKTEMPLATEVERIFY and CHECKSIGFROMSTACK - 2025-09-06T02:27:21.902745+00:00 + 2025-09-26T14:34:18.367998+00:00 + 2025-08-27T17:13:00+00:00 The recent discussions among the Bitcoin development community highlight a nuanced approach to consensus changes and proposal evaluations, specifically around the CheckTemplateVerify (CTV) feature. The dialogue emphasizes the complexity of making decisions within the Bitcoin network, pointing out that these are not merely binary choices but involve detailed technical considerations and trade-offs. The importance of a more inclusive process is underscored, suggesting that signatories of proposals should provide thorough technical explanations on platforms like personal blogs. This would enable a broader segment of the community to engage with and understand the implications of such changes. - Antoine Riard, in his communication, reflects on the need for a deeper collective understanding of consensus changes, recalling prior suggestions for a gathering of technical opinions. His stance on CTV is neutral yet open, expressing conceptual approval without strong enthusiasm, and highlighting his willingness to support changes backed by sufficient developer and stakeholder consensus. Riard’s perspective is not singularly focused on whether CTV should be implemented but rather on its technical validity and the broader ecosystem's readiness to adopt it. He notes his inability to attend upcoming IRC meetings but expresses an intention to stay informed through transcripts, indicating ongoing engagement with the community’s deliberations. - Further communications shed light on the efforts to review and improve the CTV codebase, including the establishment of repositories and workshops aimed at fostering a deeper understanding and practical skills among participants. These workshops, such as one scheduled for 28 August 2025, aim to review BIP 119 and facilitate hands-on exercises with CTV transactions. This proactive approach suggests a commitment to educational initiatives within the community, providing resources and forums for discussion and learning. - A concerning observation arises from the low engagement in code review processes, especially following a public call to review the CTV feature. Despite the initial indication of significant interest, actual participation has been minimal, raising questions about the challenges in mobilizing community support for technical reviews. In response, there’s a movement towards creating more open and accessible platforms for discussion and decision-making, exemplified by the formation of the Bitcoin Contracting Primitives Working Group. This initiative aims to democratize the consensus development process, encouraging broader participation and transparent dialogue. - Lastly, the communications touch upon the evolving landscape of Bitcoin node usage and the technical debates surrounding soft fork proposals. The engagement of economic nodes and the consideration of different technical solutions reflect an ongoing effort to enhance Bitcoin's protocol in alignment with community feedback and technological advancements. These discussions, along with provided resources, indicate a structured and collaborative approach to future developments within the Bitcoin ecosystem, emphasizing the importance of inclusivity, transparency, and informed decision-making. - 2025-08-27T17:13:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml b/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml index 8cf7b5b5d6..a0b06eff9e 100644 --- a/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml +++ b/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) - 2023-08-02T08:35:26.336429+00:00 + 2025-09-26T14:23:12.919262+00:00 + python-feedgen Anthony Towns 2022-12-13 12:55:08+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) - 2023-08-02T08:35:26.336429+00:00 + 2025-09-26T14:23:12.919396+00:00 - The bitcoin-dev mailing list is currently engaged in a discussion about Full RBF (Replace-by-Fee) and its potential impact on mempool policy. Advocates for Full RBF argue that relying on predictable mempool policy is not advisable, as miners will always prioritize optimizing fees in the short term. This could lead to a scenario where miners advertise how to connect to their nodes, allowing those who prefer higher fee transactions to send them directly. However, this assumption is not an economic fact of life, as there are alternative options such as stablecoins or ETH that users could switch to, resulting in a substantial drop in bitcoin traffic, transaction fees, and price.The outcome of implementing Full RBF is uncertain in terms of its effect on the desirability of bitcoin and its price. The use of BTC for payments may shift towards lightning network, causing a reduction in on-chain traffic and fee income. The author emphasizes the importance of prioritizing long-term income over immediate revenue to prevent 51% attacks from becoming a dominant strategy. Consistent and predictable relay policy across nodes remains possible regardless of whether the policy follows the "first seen is final, highest fee rate wins" principle or something else. The author sees Full RBF as a way to eliminate a use-case that carries risk, ultimately strengthening Bitcoin. However, they disagree with preventing others from voluntarily taking on small risks that can be easily managed or avoided. The author clarifies that "money for enemies" refers to empowering the majority rather than an elite minority within the Bitcoin community.Regarding the claim that RBF is a fee-minimization feature, the author responds by highlighting the economics of the situation. Fees serve as a price on confirmation, and there exists an optimum price where total earnings vs price reaches a peak. RBF optimizes the discovery of this optimum price, which is desirable. However, many merchants and consumers reject opt-in-RBF, necessitating the need for full-RBF to improve price discovery of blockspace when such acceptors are prevalent. The author also disputes the implication that demand follows supply, asserting that if Bitcoin offers less utility, it will experience reduced demand regardless of its optimization for capacity saturation. The optimal state is achieved by providing the most value per blockspace per time period. Zero-conf transactions currently generate added demand for blockspace from merchants and consumers due to their qualification for zero-conf acceptance based on fee rates.A discussion on full RBF highlights its alignment with miner and user economic incentives. However, this argument can be refuted as RBF primarily serves as a fee-minimization feature, resulting in lower earnings for miners. Additionally, nodes providing replacement service and propagation incur expenses. The author emphasizes that fees are the price of confirmation and applies the concept of "price theory" where an optimum price may be lower than the prevailing market price. Therefore, RBF optimizes the discovery of this optimum price, but many zero-conf acceptors reject opt-in-RBF despite its improved price discovery. Thus, full-RBF becomes necessary in such cases.There exists a fundamental disagreement regarding Full RBF. Supporters perceive it as a means to eliminate the risk associated with zero-conf transactions, while opponents believe that relying on predictable mempool policy has worked well thus far. Those in favor argue that node policy is not a consensus rule, and changing mempool policy is essential to actively discourage zero-conf. Opponents contend that zero-conf acceptance is already widely used and valuable, and full-RBF can be discarded if the majority of node operators do not care about it. The economic incentive argument currently holds little significance, and there remains an obvious incentive for someone to attempt a double-spend attack on a zero-conf merchant. Angus suggests that accepting zero-conf changes from being tolerated with occasional issues to being strongly discouraged due to potential financial losses. For now, Angus supports running a full-RBF node, considering it a measure that strengthens Bitcoin. However, he is open to reversing his stance if a strong economic argument convinces him and other miners or users to oppose full-RBF.While many proponents of zero-conf focus on supporting Lightning as an alternative, the author argues that Lightning is not without risks and should not be solely relied upon for commercial payments. Lightning is suitable for low-value payments due to the current low-fee environment's lack of scalability. However, for high-value payments, zero-conf has never been valuable or useful and likely never will be. The author highlights instances where double-spends of zero-conf transactions without RBF have been repeatedly demonstrated, emphasizing the absence of a long-term scenario where zero-conf holds value. Although low fees may seem appealing, they incentivize network-wide surveillance, increase the burden on nodes, and promote unsustainable practices resembling a "mev" (miner-extractable value) bounty for merchants. Nevertheless, the author identifies the risk involved in waiting 20 minutes before shipping items as insignificant, with the only potential issue being a user replacing a transaction with a different destination. Even if such an event were to 2022-12-13T12:55:08+00:00 + The bitcoin-dev mailing list is currently engaged in a discussion about Full RBF (Replace-by-Fee) and its potential impact on mempool policy. Advocates for Full RBF argue that relying on predictable mempool policy is not advisable, as miners will always prioritize optimizing fees in the short term. This could lead to a scenario where miners advertise how to connect to their nodes, allowing those who prefer higher fee transactions to send them directly. However, this assumption is not an economic fact of life, as there are alternative options such as stablecoins or ETH that users could switch to, resulting in a substantial drop in bitcoin traffic, transaction fees, and price.The outcome of implementing Full RBF is uncertain in terms of its effect on the desirability of bitcoin and its price. The use of BTC for payments may shift towards lightning network, causing a reduction in on-chain traffic and fee income. The author emphasizes the importance of prioritizing long-term income over immediate revenue to prevent 51% attacks from becoming a dominant strategy. Consistent and predictable relay policy across nodes remains possible regardless of whether the policy follows the "first seen is final, highest fee rate wins" principle or something else. The author sees Full RBF as a way to eliminate a use-case that carries risk, ultimately strengthening Bitcoin. However, they disagree with preventing others from voluntarily taking on small risks that can be easily managed or avoided. The author clarifies that "money for enemies" refers to empowering the majority rather than an elite minority within the Bitcoin community.Regarding the claim that RBF is a fee-minimization feature, the author responds by highlighting the economics of the situation. Fees serve as a price on confirmation, and there exists an optimum price where total earnings vs price reaches a peak. RBF optimizes the discovery of this optimum price, which is desirable. However, many merchants and consumers reject opt-in-RBF, necessitating the need for full-RBF to improve price discovery of blockspace when such acceptors are prevalent. The author also disputes the implication that demand follows supply, asserting that if Bitcoin offers less utility, it will experience reduced demand regardless of its optimization for capacity saturation. The optimal state is achieved by providing the most value per blockspace per time period. Zero-conf transactions currently generate added demand for blockspace from merchants and consumers due to their qualification for zero-conf acceptance based on fee rates.A discussion on full RBF highlights its alignment with miner and user economic incentives. However, this argument can be refuted as RBF primarily serves as a fee-minimization feature, resulting in lower earnings for miners. Additionally, nodes providing replacement service and propagation incur expenses. The author emphasizes that fees are the price of confirmation and applies the concept of "price theory" where an optimum price may be lower than the prevailing market price. Therefore, RBF optimizes the discovery of this optimum price, but many zero-conf acceptors reject opt-in-RBF despite its improved price discovery. Thus, full-RBF becomes necessary in such cases.There exists a fundamental disagreement regarding Full RBF. Supporters perceive it as a means to eliminate the risk associated with zero-conf transactions, while opponents believe that relying on predictable mempool policy has worked well thus far. Those in favor argue that node policy is not a consensus rule, and changing mempool policy is essential to actively discourage zero-conf. Opponents contend that zero-conf acceptance is already widely used and valuable, and full-RBF can be discarded if the majority of node operators do not care about it. The economic incentive argument currently holds little significance, and there remains an obvious incentive for someone to attempt a double-spend attack on a zero-conf merchant. Angus suggests that accepting zero-conf changes from being tolerated with occasional issues to being strongly discouraged due to potential financial losses. For now, Angus supports running a full-RBF node, considering it a measure that strengthens Bitcoin. However, he is open to reversing his stance if a strong economic argument convinces him and other miners or users to oppose full-RBF.While many proponents of zero-conf focus on supporting Lightning as an alternative, the author argues that Lightning is not without risks and should not be solely relied upon for commercial payments. Lightning is suitable for low-value payments due to the current low-fee environment's lack of scalability. However, for high-value payments, zero-conf has never been valuable or useful and likely never will be. The author highlights instances where double-spends of zero-conf transactions without RBF have been repeatedly demonstrated, emphasizing the absence of a long-term scenario where zero-conf holds value. Although low fees may seem appealing, they incentivize network-wide surveillance, increase the burden on nodes, and promote unsustainable practices resembling a "mev" (miner-extractable value) bounty for merchants. Nevertheless, the author identifies the risk involved in waiting 20 minutes before shipping items as insignificant, with the only potential issue being a user replacing a transaction with a different destination. Even if such an event were to - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml b/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml index 3e5e66fcdc..e1e86555ae 100644 --- a/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml +++ b/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml @@ -1,242 +1,19 @@ - + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger - 2023-08-02T07:48:23.736188+00:00 - - angus 2022-12-05 12:21:44+00:00 - - - Daniel Lipshitz 2022-12-03 14:06:11+00:00 - - - Daniel Lipshitz 2022-12-03 14:03:58+00:00 - - - Daniel Lipshitz 2022-12-03 13:17:16+00:00 - - - Peter Todd 2022-12-03 12:12:02+00:00 - - - Daniel Lipshitz 2022-12-03 11:51:19+00:00 - - - Daniel Lipshitz 2022-12-03 11:01:16+00:00 - - - Peter Todd 2022-12-03 08:50:13+00:00 - - - Daniel Lipshitz 2022-12-02 07:06:26+00:00 - - - Daniel Lipshitz 2022-12-02 06:59:01+00:00 - - - Daniel Lipshitz 2022-12-02 06:34:07+00:00 - - - Peter Todd 2022-12-02 04:30:28+00:00 - - - Antoine Riard 2022-12-02 01:52:46+00:00 - - - Erik Aronesty 2022-12-01 22:03:55+00:00 - - - Daniel Lipshitz 2022-12-01 12:27:16+00:00 - - - ZmnSCPxj 2022-11-10 09:35:18+00:00 - - - ArmchairCryptologist 2022-11-09 13:19:28+00:00 - - - AdamISZ 2022-11-02 15:04:58+00:00 - - - Sergej Kotliar 2022-10-24 07:55:59+00:00 - - - Sergej Kotliar 2022-10-24 07:45:13+00:00 - - - alicexbt 2022-10-23 20:51:16+00:00 - - - David A. Harding 2022-10-23 19:20:41+00:00 - - - Peter Todd 2022-10-21 19:43:33+00:00 - - - Peter Todd 2022-10-21 19:35:24+00:00 - - - Peter Todd 2022-10-21 19:33:46+00:00 - - - Greg Sanders 2022-10-21 14:47:50+00:00 - - - Sergej Kotliar 2022-10-21 14:19:32+00:00 - - - Greg Sanders 2022-10-21 14:01:01+00:00 - - - Sergej Kotliar 2022-10-21 12:02:24+00:00 - - - Sergej Kotliar 2022-10-21 11:56:51+00:00 - - - Sergej Kotliar 2022-10-21 09:34:17+00:00 - - - Antoine Riard 2022-10-21 01:04:24+00:00 - - - Peter Todd 2022-10-20 23:18:16+00:00 - - - Peter Todd 2022-10-20 22:13:15+00:00 - - - Peter Todd 2022-10-20 22:08:17+00:00 - - - Greg Sanders 2022-10-20 21:07:07+00:00 - - - David A. Harding 2022-10-20 21:05:36+00:00 - - - Anthony Towns 2022-10-20 19:58:41+00:00 - - - Sergej Kotliar 2022-10-20 14:17:23+00:00 - - - Ruben Somsen 2022-10-20 14:14:14+00:00 - - - Sergej Kotliar 2022-10-20 14:11:48+00:00 - - - Sergej Kotliar 2022-10-20 12:37:53+00:00 - - - Anthony Towns 2022-10-20 07:22:34+00:00 - - - Peter Todd 2022-10-20 04:05:33+00:00 - - - Antoine Riard 2022-10-20 01:37:25+00:00 - - - Greg Sanders 2022-10-19 16:08:19+00:00 - - - Sergej Kotliar 2022-10-19 16:04:30+00:00 - - - Greg Sanders 2022-10-19 15:51:41+00:00 - - - Jeremy Rubin 2022-10-19 15:43:28+00:00 - - - Erik Aronesty 2022-10-19 14:45:44+00:00 - - - Sergej Kotliar 2022-10-19 14:29:57+00:00 - - - alicexbt 2022-10-19 03:17:51+00:00 - - - Antoine Riard 2022-10-19 03:01:12+00:00 - - - Anthony Towns 2022-10-18 07:00:45+00:00 - - - Antoine Riard 2022-10-17 22:14:52+00:00 - - - Antoine Riard 2022-10-17 21:41:48+00:00 - - - Antoine Riard 2022-10-17 20:31:50+00:00 - - - Greg Sanders 2022-10-17 14:25:33+00:00 - - - Anthony Towns 2022-10-16 08:08:49+00:00 - - - John Carvalho 2022-10-15 04:20:55+00:00 - - - John Carvalho 2022-10-15 04:08:15+00:00 - - - Erik Aronesty 2022-10-14 16:28:49+00:00 - - - Peter Todd 2022-10-14 15:04:56+00:00 - - - Peter Todd 2022-10-14 15:02:25+00:00 - - - John Carvalho 2022-10-14 10:03:21+00:00 - - - alicexbt 2022-10-14 02:44:04+00:00 - - - linuxfoundation.cndm1 at dralias.com 2022-10-13 16:07:19+00:00 - - - Anthony Towns 2022-10-13 04:35:22+00:00 - - - Dario Sneidermanis 2022-10-12 21:44:13+00:00 - - - Pieter Wuille 2022-10-12 16:11:05+00:00 - - - Anthony Towns 2022-10-12 05:42:14+00:00 - - - Pieter Wuille 2022-10-11 16:18:10+00:00 - - - alicexbt 2022-10-08 20:47:52+00:00 - - - Dario Sneidermanis 2022-10-07 21:37:38+00:00 - - - Luke Dashjr 2022-10-07 20:56:21+00:00 - - - Greg Sanders 2022-10-07 17:28:28+00:00 - - - David A. Harding 2022-10-07 17:21:29+00:00 - - - Dario Sneidermanis 2022-10-07 16:20:49+00:00 - + 2025-09-26T14:23:27.824382+00:00 + python-feedgen + + + [bitcoin-dev] Fwd: " Antoine Riard + 2022-12-02T22:35:00.000Z + + + Peter Todd + 2022-12-06T05:03:00.000Z + + @@ -315,13 +92,13 @@ - python-feedgen + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger - 2023-08-02T07:48:23.737154+00:00 + 2025-09-26T14:23:27.824897+00:00 - GAP600, a company specializing in processing cryptocurrency transactions, has processed approximately 15 million transactions with a total value of $2.3 billion USD from January to November 2022. The majority of their clients are payment processors and liquidity providers. However, the CEO of GAP600, Daniel Lipshitz, expressed concern over the potential adoption of full Replace-by-Fee (RBF) as default, as it would make zero-conf acceptance difficult. This could significantly impact GAP600's market share, as they currently process around 1.5 million transactions per month.GAP600 guarantees zero confirmed Bitcoin and other crypto transactions, allowing their customers to recognize zero-conf deposits. They reimburse clients if a transaction they confirmed gets double-spent. However, if full RBF were to become dominant, zero-conf acceptance would be affected. It is unclear how many of GAP600's processed transactions relied on their unconfirmed transaction tools.The email exchange also discussed the services provided by GAP600 to Shapeshift, one of their former clients. Shapeshift no longer uses GAP600's services but occasionally asks for fee recommendations. The conversation highlights the significance of zero-conf transactions in the cryptocurrency industry and raises questions about the implementation and reliance on unconfirmed transaction tools.The discussion on the bitcoin-dev mailing list explores the issue of full RBF and its impact on Bitcoin transactions. There are concerns about the degradation of user experience for 0-conf deposits and the risk of exchange rate changes between fiat and BTC. Various solutions, such as using Child-Pays-for-Parent (CPFP) to lock in FX risk or making the double-spender over-pay, are proposed but have limitations.The conversation emphasizes the need for collaboration between wallet developers, merchant developers, and protocol developers to address these issues and improve the Bitcoin payment experience. Specific implementations of RBF features in various wallets are also discussed, highlighting the need for collaboration to enhance the RBF experience.The risks associated with accepting Bitcoin payments are highlighted, including the zeroconf risk and the FX risk. The conversation mentions the "American call option," where users can make low-fee transactions and wait to see if the BTCUSD rate changes before canceling and making a cheaper transaction. This could potentially abuse the system and harm merchants.Sergej Kotliar, CEO of Bitrefill, raises concerns about the default use of RBF in Bitcoin transactions. He suggests a risk-based approach to determine which payments are non-trivial to reverse, considering user experience. There is also discussion about Lightning Network adoption and the challenges of RBF as a default policy.The bitcoin-dev mailing list recently discussed the relay of full-RBF (replace-by-fee) transactions. One member stated that it is already working well, except for a few percent of hashrate that doesn't accept fullrbf replacement transactions. However, another member disagreed, emphasizing the importance of all full node users trying fullrbf. The first member explained that the relay of full-rbf transactions currently works well due to preferential rbf peering implementations. They personally run four nodes with this feature enabled and haven't seen many non-opt-in doublespends get mined. However, they have observed a few through their Alice OTS calendar, which could increase as miners adopt full-rbf.There are concerns about the gaslighting happening with the advancement of RBF, while merchants wanting to manage their own 0conf risk better is not deemed acceptable. Some argue that miners can facilitate doublespends anyway if the fees are higher. However, proponents of RBF seem to threaten the use case of on-chain Bitcoin being useful at the point-of-sale for merchants and consumers. This may lead to the creation of alternative fee mechanisms and trusted/exclusive mempools where first-seen transactions are respected.According to a tweet by Sergej Kotliar in January 2022, lightning payments account for only 4% compared to on-chain payments, which make up 32%. Bitrefill and similar providers could promote the use of lightning payments by displaying them by default and presenting on-chain payments as a fallback. It would be interesting to know if these services face any obstacles or if they disagree that lightning is an improvement over accepting unconfirmed on-chain transactions from untrusted parties.Pieter Wuille via bitcoin-dev proposed a step towards getting full RBF on the network by allowing experimentation and socializing the notion that developers believe it is time. However, there seems to be confusion about what exactly they believe it is time for. There are two possibilities: (a) deprecating the acceptance of zeroconf transactions on mainnet over the next 6, 12, or 18 months, or (b) switching mainnet mining and relay nodes to full RBF.Pieter Wuille commented on the opt-in flag for full-RBF, stating that adding the flag is a likely step towards wider adoption on the network. However, he believes that the opt-in flag 2022-12-05T12:21:44+00:00 + GAP600, a company specializing in processing cryptocurrency transactions, has processed approximately 15 million transactions with a total value of $2.3 billion USD from January to November 2022. The majority of their clients are payment processors and liquidity providers. However, the CEO of GAP600, Daniel Lipshitz, expressed concern over the potential adoption of full Replace-by-Fee (RBF) as default, as it would make zero-conf acceptance difficult. This could significantly impact GAP600's market share, as they currently process around 1.5 million transactions per month.GAP600 guarantees zero confirmed Bitcoin and other crypto transactions, allowing their customers to recognize zero-conf deposits. They reimburse clients if a transaction they confirmed gets double-spent. However, if full RBF were to become dominant, zero-conf acceptance would be affected. It is unclear how many of GAP600's processed transactions relied on their unconfirmed transaction tools.The email exchange also discussed the services provided by GAP600 to Shapeshift, one of their former clients. Shapeshift no longer uses GAP600's services but occasionally asks for fee recommendations. The conversation highlights the significance of zero-conf transactions in the cryptocurrency industry and raises questions about the implementation and reliance on unconfirmed transaction tools.The discussion on the bitcoin-dev mailing list explores the issue of full RBF and its impact on Bitcoin transactions. There are concerns about the degradation of user experience for 0-conf deposits and the risk of exchange rate changes between fiat and BTC. Various solutions, such as using Child-Pays-for-Parent (CPFP) to lock in FX risk or making the double-spender over-pay, are proposed but have limitations.The conversation emphasizes the need for collaboration between wallet developers, merchant developers, and protocol developers to address these issues and improve the Bitcoin payment experience. Specific implementations of RBF features in various wallets are also discussed, highlighting the need for collaboration to enhance the RBF experience.The risks associated with accepting Bitcoin payments are highlighted, including the zeroconf risk and the FX risk. The conversation mentions the "American call option," where users can make low-fee transactions and wait to see if the BTCUSD rate changes before canceling and making a cheaper transaction. This could potentially abuse the system and harm merchants.Sergej Kotliar, CEO of Bitrefill, raises concerns about the default use of RBF in Bitcoin transactions. He suggests a risk-based approach to determine which payments are non-trivial to reverse, considering user experience. There is also discussion about Lightning Network adoption and the challenges of RBF as a default policy.The bitcoin-dev mailing list recently discussed the relay of full-RBF (replace-by-fee) transactions. One member stated that it is already working well, except for a few percent of hashrate that doesn't accept fullrbf replacement transactions. However, another member disagreed, emphasizing the importance of all full node users trying fullrbf. The first member explained that the relay of full-rbf transactions currently works well due to preferential rbf peering implementations. They personally run four nodes with this feature enabled and haven't seen many non-opt-in doublespends get mined. However, they have observed a few through their Alice OTS calendar, which could increase as miners adopt full-rbf.There are concerns about the gaslighting happening with the advancement of RBF, while merchants wanting to manage their own 0conf risk better is not deemed acceptable. Some argue that miners can facilitate doublespends anyway if the fees are higher. However, proponents of RBF seem to threaten the use case of on-chain Bitcoin being useful at the point-of-sale for merchants and consumers. This may lead to the creation of alternative fee mechanisms and trusted/exclusive mempools where first-seen transactions are respected.According to a tweet by Sergej Kotliar in January 2022, lightning payments account for only 4% compared to on-chain payments, which make up 32%. Bitrefill and similar providers could promote the use of lightning payments by displaying them by default and presenting on-chain payments as a fallback. It would be interesting to know if these services face any obstacles or if they disagree that lightning is an improvement over accepting unconfirmed on-chain transactions from untrusted parties.Pieter Wuille via bitcoin-dev proposed a step towards getting full RBF on the network by allowing experimentation and socializing the notion that developers believe it is time. However, there seems to be confusion about what exactly they believe it is time for. There are two possibilities: (a) deprecating the acceptance of zeroconf transactions on mainnet over the next 6, 12, or 18 months, or (b) switching mainnet mining and relay nodes to full RBF.Pieter Wuille commented on the opt-in flag for full-RBF, stating that adding the flag is a likely step towards wider adoption on the network. However, he believes that the opt-in flag - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_A-Bitcoin-NFT-System.xml b/static/bitcoin-dev/Dec_2022/combined_A-Bitcoin-NFT-System.xml index 3b761a2e0f..a92f0304fd 100644 --- a/static/bitcoin-dev/Dec_2022/combined_A-Bitcoin-NFT-System.xml +++ b/static/bitcoin-dev/Dec_2022/combined_A-Bitcoin-NFT-System.xml @@ -1,27 +1,29 @@ - + 2 Combined summary - A Bitcoin NFT System - 2023-08-02T08:44:42.612561+00:00 - - Aymeric Vitte 2023-01-05 10:46:59+00:00 - - - Vincenzo 2023-01-04 20:59:49+00:00 - - - Aymeric Vitte 2022-12-29 16:49:46+00:00 - + 2025-09-26T14:23:21.450066+00:00 + python-feedgen + + + Vincenzo + 2023-01-04T20:59:00.000Z + + + Aymeric Vitte + 2023-01-05T10:46:00.000Z + + - python-feedgen + 2 Combined summary - A Bitcoin NFT System - 2023-08-02T08:44:42.612561+00:00 + 2025-09-26T14:23:21.450514+00:00 - Aymeric Vitte and Vincenzo engaged in an email exchange discussing their views on the current state of NFTs. Aymeric expressed dissatisfaction with the centralized, insecure, duplicable, virtual, stealable, unsigned, and expensive nature of NFTs. However, he acknowledged that if NFTs were expanded to include anything that can be bought or stored in the real world, web, or metaverse, they would become more interesting.Aymeric pointed out that Ethereum is the primary platform for NFTs, but described the situation as a "mess." He shared a link to his proposal for a decentralized, secure, and cost-effective Bitcoin NFT system. Unfortunately, the provided link to the proposal appears to be inaccessible.The proposed Bitcoin NFT system aims to avoid the shortcomings of the current NFT ecosystem. It suggests using SHA-256 for a simple reference to the NFT hash. Aymeric explains various aspects of the system, including minting NFTs on Bitcoin, minting multiple NFTs in a single transaction, preventing double minting, transferring NFTs for free, buying and selling NFTs, and using Chainpoint for purchasing NFTs.To ensure security and combat counterfeits, the proposed system involves using a double hash in transactions. This approach allows the buyer and seller to verify the authenticity of the NFT by comparing the original hash. Aymeric suggests printing the double hash on the product and providing the original hash to the buyer.Unlike Ethereum-based NFT tokens, the proposed system does not rely on third-party platforms or oracles, making it less costly. Transactions would depend on the number of inputs, but an estimated cost is below $1 USD per transaction.While the system requires buyers and sellers to know each other, anonymous means such as Signal, Protonmail, Telegram, or Tor can be utilized. Aymeric recommends creating a new email address and using PGP keys for added anonymity.The proposal argues against the creation of a super sidechain and instead suggests implementing a local Bitcoin system with limited scope. This localized system could be used in specific areas, such as cruise boats or planes, and could be seen as a form of barter money with a stable value.It is worth noting that the proposed system is not open-source, but the author offers its availability upon contacting them directly. The funding source for this proposal remains undisclosed.In conclusion, Aymeric Vitte expresses dissatisfaction with the current design and use of NFTs, particularly on Ethereum. He proposes a decentralized, secure, and cost-effective Bitcoin NFT system as an alternative. While the provided link to the proposal is inaccessible, the email exchange provides insights into how the system would work and its potential benefits. Aymeric includes links to their LinkedIn, GitHub account, and various cryptocurrency-related projects, showcasing their expertise in the field. 2023-01-05T10:46:59+00:00 + Aymeric Vitte and Vincenzo engaged in an email exchange discussing their views on the current state of NFTs. Aymeric expressed dissatisfaction with the centralized, insecure, duplicable, virtual, stealable, unsigned, and expensive nature of NFTs. However, he acknowledged that if NFTs were expanded to include anything that can be bought or stored in the real world, web, or metaverse, they would become more interesting.Aymeric pointed out that Ethereum is the primary platform for NFTs, but described the situation as a "mess." He shared a link to his proposal for a decentralized, secure, and cost-effective Bitcoin NFT system. Unfortunately, the provided link to the proposal appears to be inaccessible.The proposed Bitcoin NFT system aims to avoid the shortcomings of the current NFT ecosystem. It suggests using SHA-256 for a simple reference to the NFT hash. Aymeric explains various aspects of the system, including minting NFTs on Bitcoin, minting multiple NFTs in a single transaction, preventing double minting, transferring NFTs for free, buying and selling NFTs, and using Chainpoint for purchasing NFTs.To ensure security and combat counterfeits, the proposed system involves using a double hash in transactions. This approach allows the buyer and seller to verify the authenticity of the NFT by comparing the original hash. Aymeric suggests printing the double hash on the product and providing the original hash to the buyer.Unlike Ethereum-based NFT tokens, the proposed system does not rely on third-party platforms or oracles, making it less costly. Transactions would depend on the number of inputs, but an estimated cost is below $1 USD per transaction.While the system requires buyers and sellers to know each other, anonymous means such as Signal, Protonmail, Telegram, or Tor can be utilized. Aymeric recommends creating a new email address and using PGP keys for added anonymity.The proposal argues against the creation of a super sidechain and instead suggests implementing a local Bitcoin system with limited scope. This localized system could be used in specific areas, such as cruise boats or planes, and could be seen as a form of barter money with a stable value.It is worth noting that the proposed system is not open-source, but the author offers its availability upon contacting them directly. The funding source for this proposal remains undisclosed.In conclusion, Aymeric Vitte expresses dissatisfaction with the current design and use of NFTs, particularly on Ethereum. He proposes a decentralized, secure, and cost-effective Bitcoin NFT system as an alternative. While the provided link to the proposal is inaccessible, the email exchange provides insights into how the system would work and its potential benefits. Aymeric includes links to their LinkedIn, GitHub account, and various cryptocurrency-related projects, showcasing their expertise in the field. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml b/static/bitcoin-dev/Dec_2022/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml index a78a4c7cf7..e104cd323e 100644 --- a/static/bitcoin-dev/Dec_2022/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml +++ b/static/bitcoin-dev/Dec_2022/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - A proposal for Full RBF to not exclude Zero Conf use case - 2023-08-02T08:37:12.928040+00:00 - - Daniel Lipshitz 2023-02-06 12:08:40+00:00 - - - Peter Todd 2023-02-04 16:27:47+00:00 - - - Daniel Lipshitz 2023-01-17 17:27:13+00:00 - - - Erik Aronesty 2023-01-17 17:07:54+00:00 - - - Daniel Lipshitz 2023-01-16 10:19:35+00:00 - - - Daniel Lipshitz 2023-01-14 20:15:30+00:00 - - - Peter Todd 2023-01-13 23:53:45+00:00 - - - Daniel Lipshitz 2022-12-18 08:06:15+00:00 - - - Peter Todd 2022-12-16 21:14:33+00:00 - - - Erik Aronesty 2022-12-14 17:41:17+00:00 - - - Daniel Lipshitz 2022-12-14 08:12:30+00:00 - - - Daniel Lipshitz 2022-12-13 21:58:31+00:00 - - - Peter Todd 2022-12-13 21:41:44+00:00 - - - Daniel Lipshitz 2022-12-13 14:08:10+00:00 - - - Lucas Ontivero 2022-12-13 14:00:26+00:00 - - - Daniel Lipshitz 2022-12-13 11:33:00+00:00 - - - John Carvalho 2022-12-13 09:59:36+00:00 - - - Daniel Lipshitz 2022-12-13 08:08:59+00:00 - - - Yuval Kogman 2022-12-13 04:20:22+00:00 - - - Daniel Lipshitz 2022-12-11 20:24:00+00:00 - + 2025-09-26T14:23:36.381158+00:00 + python-feedgen + + + [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case Daniel Lipshitz + 2022-12-11T20:24:00.000Z + + + Yuval Kogman + 2022-12-13T04:20:00.000Z + + + Daniel Lipshitz + 2022-12-13T08:08:00.000Z + + + John Carvalho + 2022-12-13T09:59:00.000Z + + + Daniel Lipshitz + 2022-12-13T11:33:00.000Z + + + Lucas Ontivero + 2022-12-13T14:00:00.000Z + + + Daniel Lipshitz + 2022-12-13T14:08:00.000Z + + + Peter Todd + 2022-12-13T21:41:00.000Z + + + Daniel Lipshitz + 2022-12-13T21:58:00.000Z + + + Daniel Lipshitz + 2022-12-14T08:12:00.000Z + + + Erik Aronesty + 2022-12-14T17:41:00.000Z + + + Peter Todd + 2022-12-16T21:14:00.000Z + + + Daniel Lipshitz + 2022-12-18T08:06:00.000Z + + + Peter Todd + 2023-01-13T23:53:00.000Z + + + Daniel Lipshitz + 2023-01-14T20:15:00.000Z + + + Daniel Lipshitz + 2023-01-16T10:19:00.000Z + + + Erik Aronesty + 2023-01-17T17:07:00.000Z + + + Daniel Lipshitz + 2023-01-17T17:27:00.000Z + + + Peter Todd + 2023-02-04T16:27:00.000Z + + + Daniel Lipshitz + 2023-02-06T12:08:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - A proposal for Full RBF to not exclude Zero Conf use case - 2023-08-02T08:37:12.928040+00:00 + 2025-09-26T14:23:36.383372+00:00 - In an email exchange between Peter Todd and Daniel Lipshitz, it was revealed that GAP600, a service provider, does not have access to KYC/AML information or telephone numbers of its clients who use bitcoin for deposit. They only receive public bitcoin information such as transaction hash and output address shared via API.Lipshitz explained that their company services merchants, payment processors, and non-custodial liquidity providers by enabling them to accept 0-conf transactions. He also provided figures on the queried unique Bitcoin addresses and USD value for November and December 2022.There is ongoing debate about the need for full RBF (replace-by-fee), with Todd arguing that implementing full RBF would stop the collection of data on real-world entities paying for GAP600's service. However, Lipshitz maintained that their service is purely an analysis of the Bitcoin network and does not involve AML/KYC.Todd suggested adding a swap limitation to mitigate risks, but this was challenged as it would negate the use case of multi-party transactions. Lipshitz emphasized that 0-conf on Bitcoin is a significant use case that should not be ignored.GAP600 did not provide specific names of companies using their service but referred to Max CEO from Coinspaid, who may share further information on the merchants they support. The email exchange also discussed the centralization of transaction processing and the privacy concerns associated with collecting client data.In a discussion on the bitcoin-dev mailing list, Daniel Lipshitz suggested the use of first-seen-safe replace-by-fee (FSS-RBF) as an alternative to full replace-by-fee (FullRBF). This would retain the significant 0-conf use case while balancing the associated risks. John Carvalho expressed concerns about the side-effects of FullRBF and supported the discussion of the FSS-RBF feature.Peter Todd explained in an email exchange with Daniel Lipshitz the issues with his first-seen-safe proposal. He noted that it was only proposed as a political compromise and that full-RBF behavior is necessary for multi-party transactions such as coinjoins and multi-party lightning channels. Todd suggested Antoine Riard's spent-nVersion signaling proposal as a possible compromise option, but it has negative privacy implications. He advised service providers to either adopt scalable instant payment tech like Lightning or expand their business with other chains like BSV.Some wallets, including Electrum, may be affected by FullRBF as they use RBF to batch transactions. Daniel Lipshitz suggested that FSS-RBF could be a suitable option to balance FullRBF and retain the 0-conf use case. John Carvalho also supported the discussion of FSS-RBF.In a separate email exchange, Lipshitz responded to Carvalho's query about why FSS-RBF wasn't implemented earlier and whether there were design problems. Lipshitz acknowledged the suitability of FSS-RBF and found no technical issues with its implementation. He pointed out that the reasons against adopting Full-RBF listed on the Bitcoin Core website do not apply in this case since OptinRBF already exists as an option and FSS-RBF offers additional benefits.The speaker expressed their approval of Peter Todd's suggestion to use the "first-seen-safe replace-by-fee" method, which would balance FullRBF while retaining the use cases for zero-conf transactions. They believe this could be a good way forward.It is understood that the current use case of 0-Conf acceptance of transactions is significant, and merchants are aware of the associated risks. However, full RBF adoption would likely make 0-conf not possible and limit this use case. To address this, the primary use case of full RBF (increasing fees) can be enabled while keeping the outputs of TRX1 to be included within TRX2. This would require the addition of at least one input to increase the fee. OptinRBF and FullRBF (with this limitation) would give actors the option to increase fees while still allowing the 0-conf use case. The risks associated with 0-conf are well understood, and it can continue to exist with the ongoing choices available to actors. 2023-02-06T12:08:40+00:00 + In an email exchange between Peter Todd and Daniel Lipshitz, it was revealed that GAP600, a service provider, does not have access to KYC/AML information or telephone numbers of its clients who use bitcoin for deposit. They only receive public bitcoin information such as transaction hash and output address shared via API.Lipshitz explained that their company services merchants, payment processors, and non-custodial liquidity providers by enabling them to accept 0-conf transactions. He also provided figures on the queried unique Bitcoin addresses and USD value for November and December 2022.There is ongoing debate about the need for full RBF (replace-by-fee), with Todd arguing that implementing full RBF would stop the collection of data on real-world entities paying for GAP600's service. However, Lipshitz maintained that their service is purely an analysis of the Bitcoin network and does not involve AML/KYC.Todd suggested adding a swap limitation to mitigate risks, but this was challenged as it would negate the use case of multi-party transactions. Lipshitz emphasized that 0-conf on Bitcoin is a significant use case that should not be ignored.GAP600 did not provide specific names of companies using their service but referred to Max CEO from Coinspaid, who may share further information on the merchants they support. The email exchange also discussed the centralization of transaction processing and the privacy concerns associated with collecting client data.In a discussion on the bitcoin-dev mailing list, Daniel Lipshitz suggested the use of first-seen-safe replace-by-fee (FSS-RBF) as an alternative to full replace-by-fee (FullRBF). This would retain the significant 0-conf use case while balancing the associated risks. John Carvalho expressed concerns about the side-effects of FullRBF and supported the discussion of the FSS-RBF feature.Peter Todd explained in an email exchange with Daniel Lipshitz the issues with his first-seen-safe proposal. He noted that it was only proposed as a political compromise and that full-RBF behavior is necessary for multi-party transactions such as coinjoins and multi-party lightning channels. Todd suggested Antoine Riard's spent-nVersion signaling proposal as a possible compromise option, but it has negative privacy implications. He advised service providers to either adopt scalable instant payment tech like Lightning or expand their business with other chains like BSV.Some wallets, including Electrum, may be affected by FullRBF as they use RBF to batch transactions. Daniel Lipshitz suggested that FSS-RBF could be a suitable option to balance FullRBF and retain the 0-conf use case. John Carvalho also supported the discussion of FSS-RBF.In a separate email exchange, Lipshitz responded to Carvalho's query about why FSS-RBF wasn't implemented earlier and whether there were design problems. Lipshitz acknowledged the suitability of FSS-RBF and found no technical issues with its implementation. He pointed out that the reasons against adopting Full-RBF listed on the Bitcoin Core website do not apply in this case since OptinRBF already exists as an option and FSS-RBF offers additional benefits.The speaker expressed their approval of Peter Todd's suggestion to use the "first-seen-safe replace-by-fee" method, which would balance FullRBF while retaining the use cases for zero-conf transactions. They believe this could be a good way forward.It is understood that the current use case of 0-Conf acceptance of transactions is significant, and merchants are aware of the associated risks. However, full RBF adoption would likely make 0-conf not possible and limit this use case. To address this, the primary use case of full RBF (increasing fees) can be enabled while keeping the outputs of TRX1 to be included within TRX2. This would require the addition of at least one input to increase the fee. OptinRBF and FullRBF (with this limitation) would give actors the option to increase fees while still allowing the 0-conf use case. The risks associated with 0-conf are well understood, and it can continue to exist with the ongoing choices available to actors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_Announcement-Full-RBF-Miner-Bounty.xml b/static/bitcoin-dev/Dec_2022/combined_Announcement-Full-RBF-Miner-Bounty.xml index 2cb808896c..4b9bc4f266 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Announcement-Full-RBF-Miner-Bounty.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Announcement-Full-RBF-Miner-Bounty.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Announcement: Full-RBF Miner Bounty - 2023-08-02T08:24:00.883108+00:00 - - Anthony Towns 2022-12-13 04:01:50+00:00 - - - Peter Todd 2022-12-10 18:07:18+00:00 - - - 0xB10C 2022-12-10 11:59:05+00:00 - - - Peter Todd 2022-12-09 21:16:20+00:00 - - - 0xB10C 2022-12-09 16:04:05+00:00 - - - Peter Todd 2022-12-06 07:37:27+00:00 - - - Peter Todd 2022-12-06 05:39:40+00:00 - - - El_Hoy 2022-12-06 04:48:07+00:00 - - - El_Hoy 2022-12-05 17:25:29+00:00 - - - Erik Aronesty 2022-12-05 17:00:56+00:00 - - - Michael Folkson 2022-12-05 15:33:37+00:00 - - - Rijndael 2022-12-05 14:12:33+00:00 - - - Greg Sanders 2022-12-05 13:38:58+00:00 - - - El_Hoy 2022-12-05 12:20:58+00:00 - - - Peter Todd 2022-11-15 14:43:25+00:00 - - - Anthony Towns 2022-11-15 05:36:08+00:00 - - - email at yancy.lol 2022-11-09 12:14:52+00:00 - - - Peter Todd 2022-11-08 18:16:13+00:00 - - - Erik Aronesty 2022-11-03 13:32:20+00:00 - - - alicexbt 2022-11-02 19:02:33+00:00 - - - Peter Todd 2022-11-02 09:26:27+00:00 - + 2025-09-26T14:23:40.677911+00:00 + python-feedgen + + + [bitcoin-dev] Announcement: Full-RBF Miner Bounty Peter Todd + 2022-11-02T09:26:00.000Z + + + alicexbt + 2022-11-02T19:02:00.000Z + + + Erik Aronesty + 2022-11-03T13:32:00.000Z + + + Peter Todd + 2022-11-08T18:16:00.000Z + + + email + 2022-11-09T12:14:00.000Z + + + Anthony Towns + 2022-11-15T05:36:00.000Z + + + Peter Todd + 2022-11-15T14:43:00.000Z + + + El_Hoy + 2022-12-05T12:20:00.000Z + + + Greg Sanders + 2022-12-05T13:38:00.000Z + + + Rijndael + 2022-12-05T14:12:00.000Z + + + Michael Folkson + 2022-12-05T15:33:00.000Z + + + Erik Aronesty + 2022-12-05T17:00:00.000Z + + + El_Hoy + 2022-12-05T17:25:00.000Z + + + El_Hoy + 2022-12-06T04:48:00.000Z + + + Peter Todd + 2022-12-06T05:39:00.000Z + + + Peter Todd + 2022-12-06T07:37:00.000Z + + + 0xB10C + 2022-12-09T16:04:00.000Z + + + Peter Todd + 2022-12-09T21:16:00.000Z + + + 0xB10C + 2022-12-10T11:59:00.000Z + + + Peter Todd + 2022-12-10T18:07:00.000Z + + + Anthony Towns + 2022-12-13T04:01:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Announcement: Full-RBF Miner Bounty - 2023-08-02T08:24:00.883108+00:00 + 2025-09-26T14:23:40.680374+00:00 - A member of the bitcoin-dev community has set up a mempoolfullrbf=1 node to monitor full-RBF transactions and is logging replacement events. They are filtering full-RBF replacements and listing the replaced and replacement transactions on their website. Another member suggests grouping related replacements together and providing information on how long ago the replaced transaction was seen compared to the full RBF event timestamp. The member also suggests including this information for bip-125 opt-in rbf txs to show the frequency of the "offer a low fee, and raise it over time" approach.Bitcoin developer Peter Todd and 0xB10C discuss monitoring full-RBF transactions in an email exchange. 0xB10C's logs suggest that Luxor may have mempoolfullrbf=1 enabled as they have mined five full-RBF replacements in two blocks. AntPool's status is uncertain based on one transaction they mined. Block explorer Blockstream.info recently enabled full-RBF, but the propagation to their nodes can be sporadic. Todd has ported Antoine's preferential peering patch to v24.0 and suggests running it to focus on replacements rather than propagation. Foundry USA mined a doublespend, potentially due to accidental propagation.Peter Todd sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and logs them. The node accepts incoming connections and has not taken any special steps for peering with other full-rbf nodes. Over the last few days, the node has mostly seen OP_RETURN transactions, particularly OpenTimestamps transactions. Luxor may have mempoolfullrbf=1 enabled based on recent observations. So far, no full-RBF replacement transactions have been mined.0xB10C sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and lists the replaced and replacement transactions. The node does not take any special steps for peering with other full-rbf nodes and relies on good peering to receive all the replacements. The node has mostly seen OP_RETURN transactions, including OpenTimestamps transactions. Replacement transactions have not been mined yet. The OpenTimestamps transactions primarily make full-RBF replacements on two calendars.Peter Todd explains in an email exchange that censoring transactions on the Bitcoin blockchain is highly unlikely due to the decentralized nature of the network. He notes that there are thousands of listening nodes connected to the network, making it difficult for censorship to be successful. Todd also mentions the percentage of the network needed to run full-RBF for a node to connect to at least one full-RBF peer. He suggests running a full-RBF node that connects to every single listening node simultaneously. Todd provides a link to a percolation simulator for full-RBF.In an email exchange, Peter Todd discusses the risks of enforcing mempool consistency on the Bitcoin network. He notes that implementing such a rule could lead to unintended chain splits and may not be feasible as he does not have commit access to the main repository. Todd also explains the probability of censoring nodes successfully blocking transactions, highlighting the difficulty of achieving such censorship. He mentions the possibility of running multiple nodes with functionality to stop the propagation of full-RBF replaced blocks but acknowledges the challenges associated with this approach.The bitcoin-dev mailing list discussion focuses on the importance of proof of work for building consensus-accepted blocks and the risks associated with enforcing mempool consistency through a consensus rule. Some contributors argue against enforcing mempool consistency, citing potential unintended chain splits. Others suggest working on a Bitcoin Core implementation that stops the propagation of full-RBF replaced blocks, but political difficulties arise due to commit access limitations. The conversation also touches on attacks on opt-in RBF and 0Conf bitcoin usage, as well as ad hominem attacks towards Daniel Lipshitz.A discussion on the bitcoin-dev mailing list addresses concerns about a proposed change to the Bitcoin network, which some believe would lead to centralization and fail to achieve its intended goal. The possibility of sending transactions directly to miners is discussed, with one participant noting the difficulty of different miners having conflicting opt-out-rbb transactions. Enforcing mempool consistency through a consensus rule is debated, with warnings about unintended chain splits. The discussion also touches on Peter Todd's attack on opt-in RBF and 0Conf bitcoin usage, suggesting a solution to stop the propagation of full-RBF replaced blocks. However, implementing this solution may be politically challenging.The bitcoin-dev mailing list conversation discusses the risks associated with enforcing mempool consistency on the Bitcoin network and the challenges of implementing such a rule. Concerns are raised about unintended chain splits and the difficulty of making a consensus rule that enforces mempool consistency. The risk of double-spending transactions is also highlighted when conflicting transactions are broadcasted with minimal fees. Peter Todd's efforts to attack opt-in RBF are mentioned, including the donations he received for his work. Evidence suggests that there is no significant hashrate mining with full-RBF policies.On Nov 8, 2022-12-13T04:01:50+00:00 + A member of the bitcoin-dev community has set up a mempoolfullrbf=1 node to monitor full-RBF transactions and is logging replacement events. They are filtering full-RBF replacements and listing the replaced and replacement transactions on their website. Another member suggests grouping related replacements together and providing information on how long ago the replaced transaction was seen compared to the full RBF event timestamp. The member also suggests including this information for bip-125 opt-in rbf txs to show the frequency of the "offer a low fee, and raise it over time" approach.Bitcoin developer Peter Todd and 0xB10C discuss monitoring full-RBF transactions in an email exchange. 0xB10C's logs suggest that Luxor may have mempoolfullrbf=1 enabled as they have mined five full-RBF replacements in two blocks. AntPool's status is uncertain based on one transaction they mined. Block explorer Blockstream.info recently enabled full-RBF, but the propagation to their nodes can be sporadic. Todd has ported Antoine's preferential peering patch to v24.0 and suggests running it to focus on replacements rather than propagation. Foundry USA mined a doublespend, potentially due to accidental propagation.Peter Todd sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and logs them. The node accepts incoming connections and has not taken any special steps for peering with other full-rbf nodes. Over the last few days, the node has mostly seen OP_RETURN transactions, particularly OpenTimestamps transactions. Luxor may have mempoolfullrbf=1 enabled based on recent observations. So far, no full-RBF replacement transactions have been mined.0xB10C sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and lists the replaced and replacement transactions. The node does not take any special steps for peering with other full-rbf nodes and relies on good peering to receive all the replacements. The node has mostly seen OP_RETURN transactions, including OpenTimestamps transactions. Replacement transactions have not been mined yet. The OpenTimestamps transactions primarily make full-RBF replacements on two calendars.Peter Todd explains in an email exchange that censoring transactions on the Bitcoin blockchain is highly unlikely due to the decentralized nature of the network. He notes that there are thousands of listening nodes connected to the network, making it difficult for censorship to be successful. Todd also mentions the percentage of the network needed to run full-RBF for a node to connect to at least one full-RBF peer. He suggests running a full-RBF node that connects to every single listening node simultaneously. Todd provides a link to a percolation simulator for full-RBF.In an email exchange, Peter Todd discusses the risks of enforcing mempool consistency on the Bitcoin network. He notes that implementing such a rule could lead to unintended chain splits and may not be feasible as he does not have commit access to the main repository. Todd also explains the probability of censoring nodes successfully blocking transactions, highlighting the difficulty of achieving such censorship. He mentions the possibility of running multiple nodes with functionality to stop the propagation of full-RBF replaced blocks but acknowledges the challenges associated with this approach.The bitcoin-dev mailing list discussion focuses on the importance of proof of work for building consensus-accepted blocks and the risks associated with enforcing mempool consistency through a consensus rule. Some contributors argue against enforcing mempool consistency, citing potential unintended chain splits. Others suggest working on a Bitcoin Core implementation that stops the propagation of full-RBF replaced blocks, but political difficulties arise due to commit access limitations. The conversation also touches on attacks on opt-in RBF and 0Conf bitcoin usage, as well as ad hominem attacks towards Daniel Lipshitz.A discussion on the bitcoin-dev mailing list addresses concerns about a proposed change to the Bitcoin network, which some believe would lead to centralization and fail to achieve its intended goal. The possibility of sending transactions directly to miners is discussed, with one participant noting the difficulty of different miners having conflicting opt-out-rbb transactions. Enforcing mempool consistency through a consensus rule is debated, with warnings about unintended chain splits. The discussion also touches on Peter Todd's attack on opt-in RBF and 0Conf bitcoin usage, suggesting a solution to stop the propagation of full-RBF replaced blocks. However, implementing this solution may be politically challenging.The bitcoin-dev mailing list conversation discusses the risks associated with enforcing mempool consistency on the Bitcoin network and the challenges of implementing such a rule. Concerns are raised about unintended chain splits and the difficulty of making a consensus rule that enforces mempool consistency. The risk of double-spending transactions is also highlighted when conflicting transactions are broadcasted with minimal fees. Peter Todd's efforts to attack opt-in RBF are mentioned, including the donations he received for his work. Evidence suggests that there is no significant hashrate mining with full-RBF policies.On Nov 8, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_Bitcoin-Contracting-Primitives-WG-2nd-Meeting-Tuesday-20-Dec-18-00-UTC.xml b/static/bitcoin-dev/Dec_2022/combined_Bitcoin-Contracting-Primitives-WG-2nd-Meeting-Tuesday-20-Dec-18-00-UTC.xml index b0e877fe22..26d10bace2 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Bitcoin-Contracting-Primitives-WG-2nd-Meeting-Tuesday-20-Dec-18-00-UTC.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Bitcoin-Contracting-Primitives-WG-2nd-Meeting-Tuesday-20-Dec-18-00-UTC.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Bitcoin Contracting Primitives WG 2nd Meeting, Tuesday 20 Dec. 18:00 UTC - 2023-08-02T08:39:09.677181+00:00 - - Antoine Riard 2022-12-20 02:35:04+00:00 - - - Antoine Riard 2022-12-12 16:13:07+00:00 - + 2025-09-26T14:23:32.087835+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Contracting Primitives WG 2nd Meeting, Tuesday 20 Dec. 18:00 UTC Antoine Riard + 2022-12-12T16:13:00.000Z + + + Antoine Riard + 2022-12-20T02:35:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Contracting Primitives WG 2nd Meeting, Tuesday 20 Dec. 18:00 UTC - 2023-08-02T08:39:09.677181+00:00 + 2025-09-26T14:23:32.088295+00:00 - The Bitcoin Contracting Primitives Working Group has scheduled their second meeting on Tuesday, December 20th at 18:00 UTC. The purpose of the meeting is to discuss contracting protocol use-cases and corresponding primitives, ensuring that all known ideas from the community are considered. Antoine Riard, a member of the group, encourages anyone who has been working on a primitive or use-case that is missing from the current listing to open a PR or contact him directly. The second part of the meeting will focus on addressing any blockers participants may have in their contracting primitives/covenant research and providing additional review on proposals if necessary. Communication for the group will take place on #bitcoin-contracting-primitives-wg on Libera Chat, and logs from the previous session can be found on GitHub. Antoine's personal goal for this meeting is to continue developing a taproot annex implementation, which could serve as a fee-bumping primitive and constrained amount malleability extension for multi-party channels and other applications. 2022-12-20T02:35:04+00:00 + The Bitcoin Contracting Primitives Working Group has scheduled their second meeting on Tuesday, December 20th at 18:00 UTC. The purpose of the meeting is to discuss contracting protocol use-cases and corresponding primitives, ensuring that all known ideas from the community are considered. Antoine Riard, a member of the group, encourages anyone who has been working on a primitive or use-case that is missing from the current listing to open a PR or contact him directly. The second part of the meeting will focus on addressing any blockers participants may have in their contracting primitives/covenant research and providing additional review on proposals if necessary. Communication for the group will take place on #bitcoin-contracting-primitives-wg on Libera Chat, and logs from the previous session can be found on GitHub. Antoine's personal goal for this meeting is to continue developing a taproot annex implementation, which could serve as a fee-bumping primitive and constrained amount malleability extension for multi-party channels and other applications. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_Bitcoin-Core-24-0-1-Released.xml b/static/bitcoin-dev/Dec_2022/combined_Bitcoin-Core-24-0-1-Released.xml index 6a8e4851ae..05d237c691 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Bitcoin-Core-24-0-1-Released.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Bitcoin-Core-24-0-1-Released.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Bitcoin Core 24.0.1 Released - 2023-08-02T08:39:30.837946+00:00 - - Matt Corallo 2022-12-13 21:28:13+00:00 - - - Peter Todd 2022-12-13 21:17:21+00:00 - - - Michael Ford 2022-12-13 12:06:47+00:00 - + 2025-09-26T14:23:19.337624+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Core 24.0.1 Released Michael Ford + 2022-12-13T12:06:00.000Z + + + Peter Todd + 2022-12-13T21:17:00.000Z + + + Matt Corallo + 2022-12-13T21:28:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Core 24.0.1 Released - 2023-08-02T08:39:30.837946+00:00 + 2025-09-26T14:23:19.338227+00:00 - Bitcoin Core has released version 24.0.1 of its software, which brings new features, bug fixes, performance improvements, and updated translations. Users are advised to shut down older versions before upgrading. The compatibility of Bitcoin Core is supported on Linux kernel-based operating systems, macOS 10.15+, and Windows 7 and newer.One notable addition in version 24.0.1 is the `mempoolfullrbf` configuration, allowing users to replace older unconfirmed transactions with newer ones using a feature called full-RBF. However, contributors strongly recommend that merchants and services not treat unconfirmed transactions as final unless they have appropriate recourse or plans when assumptions fail.The update also includes reworked logic for downloading headers from peers, which may increase the initial sync time for new nodes starting up for the first time. Version 23.1 addresses this by improving the presync phase to avoid redundant header downloads. Some RPC configuration options have been removed, while new RPCs like `sendall`, `gettxspendingprevout`, and `simulaterawtransaction` have been added.Version 24.0.1 introduces several low-level changes, including updates to RPC commands and Miniscript descriptor options for certain commands. GUI changes include a new menu item for restoring a wallet from a backup file and saving configuration changes to a `/settings.json` file instead of the Qt settings backend. The interaction between GUI settings and `bitcoin.conf` settings has been simplified.Additionally, the release credits acknowledge the contributions of those who directly impacted this version of Bitcoin Core, as well as those who helped with translations on Transifex.On December 13, 2022, Michael Ford announced the availability of Bitcoin Core version 24.0.1 for download from the official website. It was mentioned that version 24.0 had been tagged but not fully released due to last-minute issues. However, the PGP signature on the email was found to be invalid. The announcement on the bitcoin-core-dev mailing list also had an invalid signature, likely due to a formatting error caused by sending the message as both text and HTML. Peter Todd reminded users not to send HTML emails to the mailing list.In conclusion, Bitcoin Core version 24.0.1 brings various improvements and additions, including the full-RBF feature, enhanced headers sync logic, updated RPCs, GUI changes, and low-level modifications. Users are recommended to upgrade their older versions, and credits are given to contributors and translators. 2022-12-13T21:28:13+00:00 + Bitcoin Core has released version 24.0.1 of its software, which brings new features, bug fixes, performance improvements, and updated translations. Users are advised to shut down older versions before upgrading. The compatibility of Bitcoin Core is supported on Linux kernel-based operating systems, macOS 10.15+, and Windows 7 and newer.One notable addition in version 24.0.1 is the `mempoolfullrbf` configuration, allowing users to replace older unconfirmed transactions with newer ones using a feature called full-RBF. However, contributors strongly recommend that merchants and services not treat unconfirmed transactions as final unless they have appropriate recourse or plans when assumptions fail.The update also includes reworked logic for downloading headers from peers, which may increase the initial sync time for new nodes starting up for the first time. Version 23.1 addresses this by improving the presync phase to avoid redundant header downloads. Some RPC configuration options have been removed, while new RPCs like `sendall`, `gettxspendingprevout`, and `simulaterawtransaction` have been added.Version 24.0.1 introduces several low-level changes, including updates to RPC commands and Miniscript descriptor options for certain commands. GUI changes include a new menu item for restoring a wallet from a backup file and saving configuration changes to a `/settings.json` file instead of the Qt settings backend. The interaction between GUI settings and `bitcoin.conf` settings has been simplified.Additionally, the release credits acknowledge the contributions of those who directly impacted this version of Bitcoin Core, as well as those who helped with translations on Transifex.On December 13, 2022, Michael Ford announced the availability of Bitcoin Core version 24.0.1 for download from the official website. It was mentioned that version 24.0 had been tagged but not fully released due to last-minute issues. However, the PGP signature on the email was found to be invalid. The announcement on the bitcoin-core-dev mailing list also had an invalid signature, likely due to a formatting error caused by sending the message as both text and HTML. Peter Todd reminded users not to send HTML emails to the mailing list.In conclusion, Bitcoin Core version 24.0.1 brings various improvements and additions, including the full-RBF feature, enhanced headers sync logic, updated RPCs, GUI changes, and low-level modifications. Users are recommended to upgrade their older versions, and credits are given to contributors and translators. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml b/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml index a5e60a743c..4614355caf 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger - 2023-08-02T08:34:50.355400+00:00 + 2025-09-26T14:23:29.978227+00:00 + python-feedgen Peter Todd 2022-12-06 05:03:56+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger - 2023-08-02T08:34:50.355400+00:00 + 2025-09-26T14:23:29.978358+00:00 - The bitcoin-dev community is currently discussing the use of a different nVersion to signal full-rbf in multi-party transactions such as coinjoin and contracting protocols like Lightning. Originally, this option was proposed to address a DoS vector affecting these use-cases. However, alternative solutions have been developed that also solve this issue but have their own trade-offs and privacy concerns.One of the proposals suggests that multi-party protocols use a different nVersion to signal full-rbf in their transactions. However, this approach negatively impacts privacy by making it easier for bad actors to deanonymize transactions. Single-party wallets are discouraged from using this option due to complaints from services like Bitrefill about RBF transactions. Designing a protocol without harming privacy seems impossible, as it would require zeroconf services to determine whether a txout has opted into full-rbf while preventing Chainalysis services from doing the same.The decision on how to balance the interests of centralized services and other users regarding privacy tradeoffs needs to be made by the community. Another v3 proposal also presents similar privacy issues, but there may be potential ways to avoid this impact through mempool design.Antoine's message addresses Daniel, who operates a zero-conf risk analysis business. Antoine expresses concerns about the deployment of fullrbf, which could lower the cost of double-spend attacks and increase risk exposure for users. He questions the statistics on the 1.5M transactions per month received by Daniel's business, specifically asking how many are Bitcoin-only transactions excluded from zeroconf due to factors like RBF, long-chain of unconfirmed ancestors, or high value. Antoine also asks about the average feerate.Antoine shares his personal position on fullrbf deployment, as expressed in #26525, stating that there is still no consensus on deploying or removing it. He believes that before considering removing the current option from Bitcoin Core, the community needs to determine the qualification of enough economic flows at risk and the presence of a significant loss in miners' income. He also raises the question of whether the Bitcoin protocol development community should limit user choice in policy settings to preserve mining income and established use-case stability.The original technical motivation for the fullrbf option was to address a DoS vector affecting multi-party transactions like coinjoin and contracting protocols like Lightning. However, alternative solutions have been proposed since then, each with their own trade-offs and conceptual issues. Antoine provides links to previous discussions on these matters, emphasizing the potential risks associated with fullrbf deployment and the importance of balancing user choice with preserving mining income and established use-case stability. 2022-12-06T05:03:56+00:00 + The bitcoin-dev community is currently discussing the use of a different nVersion to signal full-rbf in multi-party transactions such as coinjoin and contracting protocols like Lightning. Originally, this option was proposed to address a DoS vector affecting these use-cases. However, alternative solutions have been developed that also solve this issue but have their own trade-offs and privacy concerns.One of the proposals suggests that multi-party protocols use a different nVersion to signal full-rbf in their transactions. However, this approach negatively impacts privacy by making it easier for bad actors to deanonymize transactions. Single-party wallets are discouraged from using this option due to complaints from services like Bitrefill about RBF transactions. Designing a protocol without harming privacy seems impossible, as it would require zeroconf services to determine whether a txout has opted into full-rbf while preventing Chainalysis services from doing the same.The decision on how to balance the interests of centralized services and other users regarding privacy tradeoffs needs to be made by the community. Another v3 proposal also presents similar privacy issues, but there may be potential ways to avoid this impact through mempool design.Antoine's message addresses Daniel, who operates a zero-conf risk analysis business. Antoine expresses concerns about the deployment of fullrbf, which could lower the cost of double-spend attacks and increase risk exposure for users. He questions the statistics on the 1.5M transactions per month received by Daniel's business, specifically asking how many are Bitcoin-only transactions excluded from zeroconf due to factors like RBF, long-chain of unconfirmed ancestors, or high value. Antoine also asks about the average feerate.Antoine shares his personal position on fullrbf deployment, as expressed in #26525, stating that there is still no consensus on deploying or removing it. He believes that before considering removing the current option from Bitcoin Core, the community needs to determine the qualification of enough economic flows at risk and the presence of a significant loss in miners' income. He also raises the question of whether the Bitcoin protocol development community should limit user choice in policy settings to preserve mining income and established use-case stability.The original technical motivation for the fullrbf option was to address a DoS vector affecting multi-party transactions like coinjoin and contracting protocols like Lightning. However, alternative solutions have been proposed since then, each with their own trade-offs and conceptual issues. Antoine provides links to previous discussions on these matters, emphasizing the potential risks associated with fullrbf deployment and the importance of balancing user choice with preserving mining income and established use-case stability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_Merkleize-All-The-Things.xml b/static/bitcoin-dev/Dec_2022/combined_Merkleize-All-The-Things.xml index 347923303d..8b342950f6 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Merkleize-All-The-Things.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Merkleize-All-The-Things.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - Merkleize All The Things - 2023-08-02T08:28:28.195475+00:00 - - Johan Torås Halseth 2023-05-30 07:34:09+00:00 - - - Salvatore Ingala 2023-05-28 10:24:14+00:00 - - - Johan Torås Halseth 2023-05-26 11:45:17+00:00 - - - Salvatore Ingala 2023-05-05 21:18:16+00:00 - - - Johan Torås Halseth 2023-05-04 08:34:07+00:00 - - - Salvatore Ingala 2023-05-01 21:15:20+00:00 - - - Salvatore Ingala 2023-05-01 13:11:08+00:00 - - - Johan Torås Halseth 2023-04-28 08:48:07+00:00 - - - Billy Tetrud 2022-12-13 06:59:27+00:00 - - - Salvatore Ingala 2022-12-01 08:47:22+00:00 - - - Rijndael 2022-11-30 22:09:33+00:00 - - - Rijndael 2022-11-30 19:42:08+00:00 - - - Salvatore Ingala 2022-11-12 15:04:20+00:00 - - - Antoine Riard 2022-11-11 21:49:58+00:00 - - - Salvatore Ingala 2022-11-10 09:42:30+00:00 - - - David A. Harding 2022-11-10 07:39:10+00:00 - - - Peter Todd 2022-11-09 12:07:33+00:00 - - - Bram Cohen 2022-11-08 23:34:32+00:00 - - - ZmnSCPxj 2022-11-08 12:01:11+00:00 - - - Salvatore Ingala 2022-11-08 09:17:42+00:00 - + 2025-09-26T14:23:15.102539+00:00 + python-feedgen + + + [bitcoin-dev] Merkleize All The Things Salvatore Ingala + 2022-11-08T09:17:00.000Z + + + ZmnSCPxj + 2022-11-08T12:01:00.000Z + + + Bram Cohen + 2022-11-08T23:34:00.000Z + + + Peter Todd + 2022-11-09T12:07:00.000Z + + + David A. Harding + 2022-11-10T07:39:00.000Z + + + Salvatore Ingala + 2022-11-10T09:42:00.000Z + + + Antoine Riard + 2022-11-11T21:49:00.000Z + + + Salvatore Ingala + 2022-11-12T15:04:00.000Z + + + Rijndael + 2022-11-30T19:42:00.000Z + + + Rijndael + 2022-11-30T22:09:00.000Z + + + Salvatore Ingala + 2022-12-01T08:47:00.000Z + + + Billy Tetrud + 2022-12-13T06:59:00.000Z + + + Johan Torås Halseth + 2023-04-28T08:48:00.000Z + + + Salvatore Ingala + 2023-05-01T13:11:00.000Z + + + Salvatore Ingala + 2023-05-01T21:15:00.000Z + + + Johan Torås Halseth + 2023-05-04T08:34:00.000Z + + + Salvatore Ingala + 2023-05-05T21:18:00.000Z + + + Johan Torås Halseth + 2023-05-26T11:45:00.000Z + + + Salvatore Ingala + 2023-05-28T10:24:00.000Z + + + Johan Torås Halseth + 2023-05-30T07:34:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - Merkleize All The Things - 2023-08-02T08:28:28.196514+00:00 + 2025-09-26T14:23:15.104670+00:00 - In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain. He provided a simpler game example to clarify the relationship between the covenant and the bisection protocol.Salvatore Ingala proposed MATT (Merkleize All The Things) as a method for enabling general 2023-05-30T07:34:09+00:00 + In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain. He provided a simpler game example to clarify the relationship between the covenant and the bisection protocol.Salvatore Ingala proposed MATT (Merkleize All The Things) as a method for enabling general - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml b/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml index 1f2bab2322..100aa434b6 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pseudocode for robust tail emission - 2023-08-02T08:42:11.383342+00:00 + 2025-09-26T14:23:34.234399+00:00 + python-feedgen jk_14 at op.pl 2023-02-01 22:04:11+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Pseudocode for robust tail emission - 2023-08-02T08:42:11.384340+00:00 + 2025-09-26T14:23:34.234602+00:00 - In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the 2023-02-01T22:04:11+00:00 + In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_Rethinking-Incentive-Compatibility-Within-the-Bitcoin-Protocol.xml b/static/bitcoin-dev/Dec_2022/combined_Rethinking-Incentive-Compatibility-Within-the-Bitcoin-Protocol.xml index 74124e3138..e6964ae188 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Rethinking-Incentive-Compatibility-Within-the-Bitcoin-Protocol.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Rethinking-Incentive-Compatibility-Within-the-Bitcoin-Protocol.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Rethinking “Incentive Compatibility” Within the Bitcoin Protocol - 2023-08-02T08:35:57.388095+00:00 - - Michael Folkson 2022-12-11 15:44:08+00:00 - - - Daniel Edgecumbe 2022-12-11 15:30:14+00:00 - - - John Carvalho 2022-12-11 14:56:24+00:00 - - - Michael Folkson 2022-12-11 13:58:29+00:00 - - - John Carvalho 2022-12-10 12:10:24+00:00 - + 2025-09-26T14:23:17.221387+00:00 + python-feedgen + + + [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol John Carvalho + 2022-12-10T12:10:00.000Z + + + Michael Folkson + 2022-12-11T13:58:00.000Z + + + John Carvalho + 2022-12-11T14:56:00.000Z + + + Daniel Edgecumbe + 2022-12-11T15:30:00.000Z + + + Michael Folkson + 2022-12-11T15:44:00.000Z + + - python-feedgen + 2 Combined summary - Rethinking “Incentive Compatibility” Within the Bitcoin Protocol - 2023-08-02T08:35:57.388095+00:00 + 2025-09-26T14:23:17.222154+00:00 - In an email exchange on the Bitcoin Core mailing list, John Carvalho questions the quality of current theory surrounding Bitcoin transactions and their incentive compatibility. He criticizes the idea that higher fees alone can make a transaction incentive-compatible, arguing that it is too narrow and subjective. Carvalho also raises concerns about the use of RBF as a fee-minimization tool, which conflicts with behaviors that increase the number of transactions per block and per lifetime.Carvalho suggests alternative designs that fill blocks without requiring strict protocol enforcement. He argues that bidding, which is already accepted as incentive-compatible, should be allowed to determine transaction incentives, and there should be no need for special code for replacement. Michael Folkson responds by explaining the role of P2P/mempool/policy protocol developers in setting defaults. Their goal is to ensure that consensus valid transactions can be effectively propagated across the network without harming network health. Folkson recommends further reading, including a discussion on the purpose of maintaining a mempool and a presentation on transaction relay policy.Carvalho counters by stating his extensive experience in Bitcoin, including managing a Bitcoin company with engineers. He questions the mempoolfullrbf debate and its potential conflict with the goal of mempool harmony, mining income, and the overall value and usefulness of Bitcoin. He raises concerns about biased decisions based on speculation about the future, even when they conflict with the present and past.In conclusion, Carvalho and Folkson have differing perspectives on the topic. Carvalho questions the quality of current theory and proposes alternative designs, while Folkson defends the job of P2P/mempool/policy protocol developers and suggests further reading for Carvalho. The email thread highlights the complexity of the topic and the importance of considering various factors when making decisions related to Bitcoin transactions and incentives. 2022-12-11T15:44:08+00:00 + In an email exchange on the Bitcoin Core mailing list, John Carvalho questions the quality of current theory surrounding Bitcoin transactions and their incentive compatibility. He criticizes the idea that higher fees alone can make a transaction incentive-compatible, arguing that it is too narrow and subjective. Carvalho also raises concerns about the use of RBF as a fee-minimization tool, which conflicts with behaviors that increase the number of transactions per block and per lifetime.Carvalho suggests alternative designs that fill blocks without requiring strict protocol enforcement. He argues that bidding, which is already accepted as incentive-compatible, should be allowed to determine transaction incentives, and there should be no need for special code for replacement. Michael Folkson responds by explaining the role of P2P/mempool/policy protocol developers in setting defaults. Their goal is to ensure that consensus valid transactions can be effectively propagated across the network without harming network health. Folkson recommends further reading, including a discussion on the purpose of maintaining a mempool and a presentation on transaction relay policy.Carvalho counters by stating his extensive experience in Bitcoin, including managing a Bitcoin company with engineers. He questions the mempoolfullrbf debate and its potential conflict with the goal of mempool harmony, mining income, and the overall value and usefulness of Bitcoin. He raises concerns about biased decisions based on speculation about the future, even when they conflict with the present and past.In conclusion, Carvalho and Folkson have differing perspectives on the topic. Carvalho questions the quality of current theory and proposes alternative designs, while Folkson defends the job of P2P/mempool/policy protocol developers and suggests further reading for Carvalho. The email thread highlights the complexity of the topic and the importance of considering various factors when making decisions related to Bitcoin transactions and incentives. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_Roles-and-procedures-around-adding-a-bitcoin-core-maintainer.xml b/static/bitcoin-dev/Dec_2022/combined_Roles-and-procedures-around-adding-a-bitcoin-core-maintainer.xml index c6f788e716..862198b38d 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Roles-and-procedures-around-adding-a-bitcoin-core-maintainer.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Roles-and-procedures-around-adding-a-bitcoin-core-maintainer.xml @@ -1,27 +1,25 @@ - + 2 Combined summary - Roles and procedures around adding a bitcoin core maintainer - 2023-08-02T08:39:59.643682+00:00 - - alicexbt 2023-01-07 05:11:00+00:00 - - - Michael Folkson 2022-12-20 18:44:05+00:00 - - - alicexbt 2022-12-19 21:58:13+00:00 - + 2025-09-26T14:23:25.711290+00:00 + python-feedgen + + + alicexbt + 2023-01-07T05:11:00.000Z + + - python-feedgen + 2 Combined summary - Roles and procedures around adding a bitcoin core maintainer - 2023-08-02T08:39:59.643682+00:00 + 2025-09-26T14:23:25.711677+00:00 - Alicexbt, a user on the Bitcoin-dev mailing list, has provided a detailed summary of the process for adding new maintainers to the Bitcoin Core team. The post outlines the recent addition of glowzow as a maintainer, as well as current efforts to add vasild as a new maintainer. Alicexbt proposes several changes to the current process, including opening a "Call for maintainers" issue when a new maintainer is needed, discussing nominated contributors in an IRC meeting where everyone can share their opinion, and avoiding self-merging pull requests.In response to Alicexbt's post, Michael Folkson suggests that there is some confusion around the process for adding new maintainers and pledges to look into the matter offline. He advises against "ranting and raving or throwing toys out the pram" on the mailing list and wishes everyone happy holidays.The post includes links to various pull requests, IRC meetings, and issues related to the process for adding maintainers. These links provide additional context and support for Alicexbt's proposals.Bitcoin Core has a list of present Bitcoin Core maintainers, which includes MarcoFalke, fanquake, hebasto, achow101, and glozow. Two developers that recently stepped down as Bitcoin Core maintainers are sipa and laanwj.The process followed in adding the recent maintainer, glowzow, involved nomination by fanquake, discussions in an IRC meeting, and a pull request opened by glowzow to add keys. The pull request received several ACKs, 2 NACKs, and 1 meta concept NACK, but eventually, everyone agreed to add glowzow as a maintainer, and the pull request was merged by MarcoFalke.Initiatives have been taken to improve the process and documentation for adding new maintainers. Jeremy opened a pull request that faced disagreements with the documentation and was later closed. Another related pull request was also closed with a comment from Jeremy that the desire to improve documentation seems to be missing based on reviews.Jeremy also nominated jonatack and vasild for a new maintainer in an issue which later got closed since nobody appreciated this effort to nominate self or others for a new maintainer. Similarly, an issue opened by the writer with the title 'Call for Maintainer: Privacy' received some comments that made no sense, and the issue was eventually closed.The process being followed for adding vasild as a maintainer involves volunteering by vasild, discussion in IRC meetings, and a pull request opened by vasild to add keys. The pull request received some ACKs and some disagreements from fanquake, dergoegge, and JeremyRubin. There was even a comment that disrespected vasild's contributions in Bitcoin Core.To improve the process of adding new maintainers, some suggestions include opening a 'Call for maintainers' issue if contributors or maintainers need a new maintainer, having discussions about nominated contributors in an IRC meeting, allowing everyone to share their opinion, defining scope for present and new maintainers, avoiding self-merging pull requests, and encouraging long-term contributors who are not living in a first-world country.In conclusion, Bitcoin Core needs to improve the process of adding new maintainers to ensure unbiased merging of pull requests. The organization should encourage contributions from long-term contributors globally and avoid politics while nominating new maintainers. 2023-01-07T05:11:00+00:00 + Alicexbt, a user on the Bitcoin-dev mailing list, has provided a detailed summary of the process for adding new maintainers to the Bitcoin Core team. The post outlines the recent addition of glowzow as a maintainer, as well as current efforts to add vasild as a new maintainer. Alicexbt proposes several changes to the current process, including opening a "Call for maintainers" issue when a new maintainer is needed, discussing nominated contributors in an IRC meeting where everyone can share their opinion, and avoiding self-merging pull requests.In response to Alicexbt's post, Michael Folkson suggests that there is some confusion around the process for adding new maintainers and pledges to look into the matter offline. He advises against "ranting and raving or throwing toys out the pram" on the mailing list and wishes everyone happy holidays.The post includes links to various pull requests, IRC meetings, and issues related to the process for adding maintainers. These links provide additional context and support for Alicexbt's proposals.Bitcoin Core has a list of present Bitcoin Core maintainers, which includes MarcoFalke, fanquake, hebasto, achow101, and glozow. Two developers that recently stepped down as Bitcoin Core maintainers are sipa and laanwj.The process followed in adding the recent maintainer, glowzow, involved nomination by fanquake, discussions in an IRC meeting, and a pull request opened by glowzow to add keys. The pull request received several ACKs, 2 NACKs, and 1 meta concept NACK, but eventually, everyone agreed to add glowzow as a maintainer, and the pull request was merged by MarcoFalke.Initiatives have been taken to improve the process and documentation for adding new maintainers. Jeremy opened a pull request that faced disagreements with the documentation and was later closed. Another related pull request was also closed with a comment from Jeremy that the desire to improve documentation seems to be missing based on reviews.Jeremy also nominated jonatack and vasild for a new maintainer in an issue which later got closed since nobody appreciated this effort to nominate self or others for a new maintainer. Similarly, an issue opened by the writer with the title 'Call for Maintainer: Privacy' received some comments that made no sense, and the issue was eventually closed.The process being followed for adding vasild as a maintainer involves volunteering by vasild, discussion in IRC meetings, and a pull request opened by vasild to add keys. The pull request received some ACKs and some disagreements from fanquake, dergoegge, and JeremyRubin. There was even a comment that disrespected vasild's contributions in Bitcoin Core.To improve the process of adding new maintainers, some suggestions include opening a 'Call for maintainers' issue if contributors or maintainers need a new maintainer, having discussions about nominated contributors in an IRC meeting, allowing everyone to share their opinion, defining scope for present and new maintainers, avoiding self-merging pull requests, and encouraging long-term contributors who are not living in a first-world country.In conclusion, Bitcoin Core needs to improve the process of adding new maintainers to ensure unbiased merging of pull requests. The organization should encourage contributions from long-term contributors globally and avoid politics while nominating new maintainers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml b/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml index d0ed76cd43..8e42382c7c 100644 --- a/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml +++ b/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-dev Digest, Vol 91, Issue 5 - 2023-08-02T08:35:42.989085+00:00 + 2025-09-26T14:23:38.529860+00:00 + python-feedgen Antoine Riard 2022-12-06 04:06:34+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - bitcoin-dev Digest, Vol 91, Issue 5 - 2023-08-02T08:35:42.989085+00:00 + 2025-09-26T14:23:38.530025+00:00 - Antoine Riard has proposed the removal of the "mempoolfullrbf" feature from Bitcoin Core, citing potential impacts on various use-cases such as on-chain payments, Lightning, and coinjoins. He acknowledges that this decision should follow the same process as any code change, considering factors such as ecosystem impact and utility. While he recognizes the potential benefits for wallets and multi-party applications/contracting protocols, Antoine also sees a lowering of the technical bar for double-spends.A mempool policy design philosophy was suggested to accommodate all Bitcoin use-cases without harming network interests, but concerns remain about miner incentives and potential asymmetries in mining incomes. Antoine believes that removing the "risk-induction" feature is better for the ecosystem, as it alters security expectations for 0conf operators. He suggests that more effective usage data from merchants/service operators would be valuable.The deployment of fullrbf could increase the risk exposure for users of GAP600, a zero-conf risk analysis business integrated with payment processors/liquidity providers and merchants. This increased risk exposure may affect the acceptance of incoming zero-conf transactions. Antoine requests clarification on transaction statistics, such as the number of Bitcoin-only transactions, those excluded from zeroconf, and the average feerate.Antoine maintains his personal position on fullrbf and notes that there is no conceptual consensus within the community on deploying or removing it. He emphasizes the need to address economic flows at risk and potential loss in miners' income before removing the option from Bitcoin Core. Additionally, he questions whether user choice in policy settings should be restrained to preserve mining income and established use-case stability.The original technical motivation for the mempoolfullrbf option was to address a denial-of-service (DoS) vector affecting multi-party transactions like coinjoin and contracting protocols such as Lightning. However, alternative solutions with their own trade-offs and conceptual issues have since been devised. John Carvalho, CEO of Synonym.to, supports zero-conf support for Lightning Network adoption, as it reduces friction and allows for instant, seamless user experiences within wallets. 2022-12-06T04:06:34+00:00 + Antoine Riard has proposed the removal of the "mempoolfullrbf" feature from Bitcoin Core, citing potential impacts on various use-cases such as on-chain payments, Lightning, and coinjoins. He acknowledges that this decision should follow the same process as any code change, considering factors such as ecosystem impact and utility. While he recognizes the potential benefits for wallets and multi-party applications/contracting protocols, Antoine also sees a lowering of the technical bar for double-spends.A mempool policy design philosophy was suggested to accommodate all Bitcoin use-cases without harming network interests, but concerns remain about miner incentives and potential asymmetries in mining incomes. Antoine believes that removing the "risk-induction" feature is better for the ecosystem, as it alters security expectations for 0conf operators. He suggests that more effective usage data from merchants/service operators would be valuable.The deployment of fullrbf could increase the risk exposure for users of GAP600, a zero-conf risk analysis business integrated with payment processors/liquidity providers and merchants. This increased risk exposure may affect the acceptance of incoming zero-conf transactions. Antoine requests clarification on transaction statistics, such as the number of Bitcoin-only transactions, those excluded from zeroconf, and the average feerate.Antoine maintains his personal position on fullrbf and notes that there is no conceptual consensus within the community on deploying or removing it. He emphasizes the need to address economic flows at risk and potential loss in miners' income before removing the option from Bitcoin Core. Additionally, he questions whether user choice in policy settings should be restrained to preserve mining income and established use-case stability.The original technical motivation for the mempoolfullrbf option was to address a denial-of-service (DoS) vector affecting multi-party transactions like coinjoin and contracting protocols such as Lightning. However, alternative solutions with their own trade-offs and conceptual issues have since been devised. John Carvalho, CEO of Synonym.to, supports zero-conf support for Lightning Network adoption, as it reduces friction and allows for instant, seamless user experiences within wallets. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml b/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml index 3d870330e9..3a49a93491 100644 --- a/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml +++ b/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - onion addresses to try [At least 17% of Bitcoin Core 24.x listening nodes are running full-rbf] - 2023-08-02T08:40:39.871016+00:00 + 2025-09-26T14:23:23.600414+00:00 + python-feedgen Peter Todd 2022-12-23 09:46:19+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - onion addresses to try [At least 17% of Bitcoin Core 24.x listening nodes are running full-rbf] - 2023-08-02T08:40:39.871981+00:00 + 2025-09-26T14:23:23.600548+00:00 - In a recent Bitcoin-dev thread, Peter Todd expressed his concern about the lack of easily accessible sources for onion addresses to try. However, Vasil Dimov pointed out that the issue is more complex than it seems at first glance. Dimov highlighted the fact that obtaining onion addresses is inexpensive and trying them without considering their longer-term track record can lead to problems. There is a risk of inadvertently obtaining the addresses associated with a one-time Sybil attack.To address this challenge, Dimov proposed an alternative solution – using DNS seed records instead. These addresses have been tested over extended periods, offering a higher probability of representing genuine nodes. However, Dimov mentioned that his DNS seed is not currently configured to track nodes using Tor, which limits its effectiveness in this context.On December 22, 2022, Peter Todd shared his concerns on the bitcoin-dev forum regarding the limited availability of convenient sources for onion addresses. In response to Todd's post, Vasil Dimov offered a potential solution in the form of a command that can be executed in the terminal. The command, "bitcoin-cli getnodeaddresses 0 |jq -r 'map(select(.network == "onion")) | .[].address'", could help obtain onion addresses for testing purposes.Dimov concluded his email by including a quote emphasizing the importance of living life to the fullest. 2022-12-23T09:46:19+00:00 + In a recent Bitcoin-dev thread, Peter Todd expressed his concern about the lack of easily accessible sources for onion addresses to try. However, Vasil Dimov pointed out that the issue is more complex than it seems at first glance. Dimov highlighted the fact that obtaining onion addresses is inexpensive and trying them without considering their longer-term track record can lead to problems. There is a risk of inadvertently obtaining the addresses associated with a one-time Sybil attack.To address this challenge, Dimov proposed an alternative solution – using DNS seed records instead. These addresses have been tested over extended periods, offering a higher probability of representing genuine nodes. However, Dimov mentioned that his DNS seed is not currently configured to track nodes using Tor, which limits its effectiveness in this context.On December 22, 2022, Peter Todd shared his concerns on the bitcoin-dev forum regarding the limited availability of convenient sources for onion addresses. In response to Todd's post, Vasil Dimov offered a potential solution in the form of a command that can be executed in the terminal. The command, "bitcoin-cli getnodeaddresses 0 |jq -r 'map(select(.network == "onion")) | .[].address'", could help obtain onion addresses for testing purposes.Dimov concluded his email by including a quote emphasizing the importance of living life to the fullest. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_-BUG-Bitcoin-blockspace-price-discrimination-put-simple-transactions-at-disadvantage.xml b/static/bitcoin-dev/Dec_2023/combined_-BUG-Bitcoin-blockspace-price-discrimination-put-simple-transactions-at-disadvantage.xml index ed61c4eeb3..e3fd2fcf32 100644 --- a/static/bitcoin-dev/Dec_2023/combined_-BUG-Bitcoin-blockspace-price-discrimination-put-simple-transactions-at-disadvantage.xml +++ b/static/bitcoin-dev/Dec_2023/combined_-BUG-Bitcoin-blockspace-price-discrimination-put-simple-transactions-at-disadvantage.xml @@ -1,38 +1,35 @@ - + 2 Combined summary - [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage - 2024-01-24T02:09:27.130205+00:00 - - Greg Tonoski 2024-01-21 17:14:14+00:00 - - - Nagaev Boris 2024-01-16 23:40:12+00:00 - - - Nagaev Boris 2024-01-16 23:29:58+00:00 - - - Greg Tonoski 2024-01-16 10:40:48+00:00 - - - Greg Tonoski 2024-01-14 13:10:30+00:00 - - - Greg Tonoski 2024-01-13 15:04:12+00:00 - - - Keagan McClelland 2023-12-27 22:39:38+00:00 - - - vjudeu at gazeta.pl 2023-12-27 21:43:34+00:00 - - - Nagaev Boris 2023-12-27 19:06:13+00:00 - - - Greg Tonoski 2023-12-27 16:44:51+00:00 - + 2025-09-26T14:22:59.914739+00:00 + python-feedgen + + + Greg Tonoski + 2024-01-13T15:04:00.000Z + + + Greg Tonoski + 2024-01-14T13:10:00.000Z + + + Greg Tonoski + 2024-01-16T10:40:00.000Z + + + Nagaev Boris + 2024-01-16T23:29:00.000Z + + + Nagaev Boris + 2024-01-16T23:40:00.000Z + + + Greg Tonoski + 2024-01-21T17:14:00.000Z + + @@ -43,31 +40,22 @@ - python-feedgen + 2 Combined summary - [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage - 2024-01-24T02:09:27.130332+00:00 + 2025-09-26T14:22:59.915678+00:00 + 2024-01-21T17:14:14+00:00 The ongoing debate regarding the use of blockchain for data storage highlights several key issues. Firstly, transactions that incorporate large amounts of non-essential witness data, such as an image in a single transaction, could change the nature of the blockchain by inflating it with this 'bloated' data. The UTXO set naturally expands as the number of participants grows, and price discrimination for block space has not halted this inflation. - The cost-effectiveness of storing data on the blockchain is scrutinized, particularly given the financial implications which do not seem to be offset by discounts. There's also concern about centralization within the Bitcoin network; centralized batch transactions by exchanges have already led to significant centralization, independent of any benefits from witness discounting. - Node operators typically situate UTXO sets on SSDs due to their speed, while blocks are stored on HDDs, which are less costly. If miners were to charge the same for storing one byte of transaction output as they do for witness data, it could lead to an increase in UTXO set size, forcing node operators to invest in more expensive SSD storage. The current pricing structure, which differentiates between the two types of data, helps maintain economic balance for node operators. - While transaction type—P2WPKH or P2TR—is important, prioritization in blockchain networks is more complex, often depending more on transaction size and fees. 'Bloated' transactions may be prioritized over simpler ones, despite the cumulative size and fees being comparable. - Discussion around the allocation of block space to witness data reveals that the preferential pricing model can lead to artificial inflation of witness data. This misallocation can negatively impact network efficiency, impose bandwidth costs on nodes, and risk centralizing control of the Bitcoin network. For visual reference on the disparities in block allocation, see [Bitcoin Segwit Mispricing Comparison](https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf). - -Moreover, the "witness discount" affects how transactions are prioritized but does not translate into storage costs for nodes. The connection between the UTXO set size and the witness discount doesn't influence operational node expenses, and linking the two could introduce system inefficiencies. - +Moreover, the "witness discount" affects how transactions are prioritized but does not translate into storage costs for nodes. The connection between the UTXO set size and the witness discount doesn't influence operational node expenses, and linking the two could introduce system inefficiencies. There are concerns about the blockchain's operational mechanisms, specifically whether inefficiencies occur inside or outside the witness, and how these affect simple transactions versus complex ones. This calls for a deeper understanding of how these issues manifest in the system. - Comparatively, sending coins to a P2WPKH address is currently cheaper than to a P2TR address, though spending Taproot transactions is more block space-efficient since no public key hash needs to be stored. The discrepancy between the costs of sending versus spending suggests the need for a revised fee structure that accounts for the long-term benefits of Taproot transactions. - -Finally, the current incentivization structure favors storing data in the witness section, as evidenced by the substantial size difference between the "blocks" directory and the "chainstate" directory—the former being much larger due to the lower latency requirements and thus, less expensive storage solutions. A balanced incentive for keeping the "chainstate" streamlined is crucial for efficient transaction validation. - +Finally, the current incentivization structure favors storing data in the witness section, as evidenced by the substantial size difference between the "blocks" directory and the "chainstate" directory—the former being much larger due to the lower latency requirements and thus, less expensive storage solutions. A balanced incentive for keeping the "chainstate" streamlined is crucial for efficient transaction validation. In conclusion, there is a call for a uniform pricing strategy across all bytes within the blockchain, irrespective of their position in the transaction data. A 1:1 weight-to-byte ratio would ensure equity in block space pricing and could be considered for future Segwit updates. The community's reception to this proposal will likely shape the direction of blockchain development. - 2024-01-21T17:14:14+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_Addressing-the-possibility-of-profitable-fee-manipulation-attacks.xml b/static/bitcoin-dev/Dec_2023/combined_Addressing-the-possibility-of-profitable-fee-manipulation-attacks.xml index bf09da981f..fa0a709e75 100644 --- a/static/bitcoin-dev/Dec_2023/combined_Addressing-the-possibility-of-profitable-fee-manipulation-attacks.xml +++ b/static/bitcoin-dev/Dec_2023/combined_Addressing-the-possibility-of-profitable-fee-manipulation-attacks.xml @@ -1,37 +1,41 @@ - + 2 Combined summary - Addressing the possibility of profitable fee manipulation attacks - 2023-12-19T01:58:59.565955+00:00 - - alicexbt 2023-12-18 06:26:28+00:00 - - - Nagaev Boris 2023-12-18 00:30:19+00:00 - - - Peter Todd 2023-12-17 17:56:16+00:00 - - - ArmchairCryptologist 2023-12-17 11:11:10+00:00 - + 2025-09-26T14:22:53.570620+00:00 + python-feedgen + + + [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks ArmchairCryptologist + 2023-12-17T11:11:00.000Z + + + Peter Todd + 2023-12-17T17:56:00.000Z + + + Nagaev Boris + 2023-12-18T00:30:00.000Z + + + alicexbt + 2023-12-18T06:26:00.000Z + + - python-feedgen + 2 Combined summary - Addressing the possibility of profitable fee manipulation attacks - 2023-12-19T01:58:59.566005+00:00 + 2025-09-26T14:22:53.571300+00:00 + 2023-12-18T06:26:28+00:00 The recent analysis of Bitcoin's network activity indicates that the blockchain is functioning without any apparent manipulation in block space bidding. The high demand for block space is noted, and it is explained that identifying transactions from a single individual based on fee rates and timing is unreliable due to the use of services like unisat for deploying and minting BRC20 tokens. These services can make multiple transactions appear as if they come from one source. In terms of technical performance, Initial Block Download (IBD) seems to go smoothly on machines equipped with sufficient RAM, although no specific benchmarking data is provided to compare current IBD times with previous ones when less dbcache was used. It is also mentioned that the number of full nodes has increased over the past year. - A separate point of discussion raises concerns about the potential for collusion among blockchain miners and the associated stability of such arrangements. Miners are incentivized to defect from collusive agreements to maximize their profits by underreporting their actual hashrate and secretly mining through another pool. This leads to expectations that more miners will resort to such strategies over time, thus undermining the collective effort and reducing the number of miners involved in collusion. - The conversation turns to critique the effectiveness of fee-burning solutions and suggests that Replace-by-Fee (RBF) could be a better alternative than Child-Pays-For-Parent (CPFP). BitPay is criticized for its payment processing service, with speculation about its possible motives relating to block size debates in blockchain networks. Furthermore, the practice of certain mining pools filtering out low-fee transactions could unintentionally support network flooding strategies that increase transaction fees. For those interested in delving deeper into these topics, a link to [Peter Todd's website](https://petertodd.org) is shared, along with his email address for further communication after removing the last character. - Finally, there's a detailed observation of patterns in Bitcoin's transaction fees and mempool size that suggest potential strategic manipulations, specifically related to ordinal and BRC-20 token transactions. An alarming increase in UTXOs over seven months has expanded the chainstate database significantly, which could be attributed to small, high-fee transaction bursts during low-volume periods. Evidence from mempool.space hints at the possibility that these are deliberate to keep blocks full and prevent the mempool from clearing. While this might be part of token minting activities, it raises suspicions about whether it is an attack on Bitcoin's fee structure. The profitability of such an attack would largely depend on miner participation, transaction volume, and costs. The higher the miner involvement, the cheaper the attack, as they would reclaim the transaction fees. This kind of manipulation could affect wallets' fee estimation algorithms, causing users to overpay based on inflated historical fee data. Despite these speculative patterns, concrete evidence of malicious intent remains unconfirmed. - 2023-12-18T06:26:28+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_Altruistic-Rebroadcasting-A-Partial-Replacement-Cycling-Mitigation.xml b/static/bitcoin-dev/Dec_2023/combined_Altruistic-Rebroadcasting-A-Partial-Replacement-Cycling-Mitigation.xml index 2760d7a2be..0b6e28e1db 100644 --- a/static/bitcoin-dev/Dec_2023/combined_Altruistic-Rebroadcasting-A-Partial-Replacement-Cycling-Mitigation.xml +++ b/static/bitcoin-dev/Dec_2023/combined_Altruistic-Rebroadcasting-A-Partial-Replacement-Cycling-Mitigation.xml @@ -1,47 +1,49 @@ - + 2 Combined summary - Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation - 2023-12-23T01:53:54.167196+00:00 - - Peter Todd 2023-12-22 14:01:28+00:00 - - - Antoine Riard 2023-12-21 21:59:04+00:00 - - - Peter Todd 2023-12-17 10:57:32+00:00 - - - Antoine Riard 2023-12-15 22:29:22+00:00 - - - Peter Todd 2023-12-09 10:08:56+00:00 - + 2025-09-26T14:22:57.801689+00:00 + python-feedgen + + + [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation Peter Todd + 2023-12-09T10:08:00.000Z + + + Antoine Riard + 2023-12-15T22:29:00.000Z + + + Peter Todd + 2023-12-17T10:57:00.000Z + + + Antoine Riard + 2023-12-21T21:59:00.000Z + + + Peter Todd + 2023-12-22T14:01:00.000Z + + - python-feedgen + 2 Combined summary - Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation - 2023-12-23T01:53:54.167251+00:00 + 2025-09-26T14:22:57.802503+00:00 + 2023-12-22T14:01:28+00:00 The discourse on Bitcoin Improvement Proposal (BIP) 157 and its effectiveness highlights that the protocol operates well based on practical experiences. Rebroadcasting transactions is considered an additional security layer where even a single node's participation suffices for functionality. Consistency in mempool minimum fees across nodes has been observed, with deviations within 1%, despite differences in their mempool sizes. This reflects a steady supply/demand curve for transaction fees. - Replacement attacks, where attackers use the same unspent transaction outputs (UTXOs) to displace multiple victim transactions, are addressed by BIP125 rules. These rules require incremental fees for each transaction replacement, thus financially burdening the attacker. The effectiveness of such attacks is further diminished when targeting multiple victims simultaneously, as it reduces the attack's impact due to the distribution of information across nodes. For instance, if an attacker targets two different victim transactions, the likelihood of both being cycled out by half of the altruistic rebroadcasting nodes is low, rendering the attack ineffective. - Concerns have been raised about the security model for time-sensitive second-layer networks, particularly regarding the determination of global mempool minimum fees and adversaries exploiting this system. The conversation also discussed the potential for adversaries to broadcast the same UTXO amount under various transaction IDs, consuming all altruistic bandwidth. Although rate-limitation per UTXO was considered, it brings the risk of impacting legitimate transactions. A long-term solution involves fixing replacement cycling through techniques such as eliminating package malleability and adopting self-contained fee-bumping reserve UTXOs, as detailed in a Linux Foundation mailing list post. - The discussion around local replacement caches suggests that such mechanisms might not be necessary since altruistic entities could provide caching services, managing transaction broadcasts based on minimum fee thresholds. BIP-133 feefilter is highlighted as a tool enabling nodes to set fee rate thresholds to avoid receiving low-fee transactions. Even with significant financial resources, an attacker's impact may be limited due to P2P bandwidth constraints and the cost-effectiveness of storing a replacement database in RAM. - A proposal from a GitHub issue suggests implementing a local replacement cache to maintain transactions meeting current fee requirements, highlighting concerns for full-nodes with limited storage facing moderate liquidity attacks. Periodic altruistic rebroadcasting could become vulnerable to sybil attacks or malicious squatting. Furthermore, discrepancies in rebroadcast traffic and minimum fee rates could result in bandwidth wastage. In cases involving medium- to high-liquidity attackers, existing mitigation efforts might fall short, leading to concurrent spending issues and compromising the integrity of multi-party time-sensitive protocols. - Finally, to counter replacement cycling attacks, a method for third parties to monitor and rebroadcast original transactions replaced in the attack cycle is suggested. While this approach requires development work and coordination among interested parties, it remains feasible and potentially cost-effective. Miners could be incentivized to participate in rebroadcasting to capture profitable transactions. However, limitations exist in Bitcoin Core's transaction propagation which can be improved by the Transaction Announcements Reconciliation BIP, enhancing synchronization of mempools across the network. - For further exploration of these topics, readers are directed to Peter Todd's domain and the provided references, including the BIP-133 feefilter mechanism on GitHub and the GitHub issue discussing local replacement caches. - 2023-12-22T14:01:28+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_BIP-number-request-for-wallet-policies.xml b/static/bitcoin-dev/Dec_2023/combined_BIP-number-request-for-wallet-policies.xml index 3879d545c5..6c8a51b6c0 100644 --- a/static/bitcoin-dev/Dec_2023/combined_BIP-number-request-for-wallet-policies.xml +++ b/static/bitcoin-dev/Dec_2023/combined_BIP-number-request-for-wallet-policies.xml @@ -1,29 +1,31 @@ - + 2 Combined summary - BIP number request for wallet policies - 2024-01-26T01:54:53.808032+00:00 - - Michael Folkson 2024-01-25 16:49:49+00:00 - - - Antoine Poinsot 2023-12-16 14:10:08+00:00 - + 2025-09-26T14:22:45.037471+00:00 + python-feedgen + + + [bitcoin-dev] BIP number request for wallet policies Antoine Poinsot + 2023-12-16T14:10:00.000Z + + + Michael Folkson + 2024-01-25T16:49:00.000Z + + - python-feedgen + 2 Combined summary - BIP number request for wallet policies - 2024-01-26T01:54:53.808085+00:00 + 2025-09-26T14:22:45.037924+00:00 + 2024-01-25T16:49:49+00:00 The Bitcoin community is currently observing the progression of a proposed standard for hardware signing devices, which has been in practical use by major providers including Ledger, BitBox02, and Jade. Initiated by Salvatore Ingala around eighteen months ago, this wallet policy standard is yet to receive formal recognition in the form of a Bitcoin Improvement Proposal (BIP) number. Despite being widely adopted in production, the proposal's official status remains pending in the BIPs repository. - Antoine Poinsot, the author of the proposal, has been awaiting a response from the BIP editors for over a year since the initial pull request for a BIP number was submitted. The lack of assignment or feedback after multiple follow-ups has raised concerns among those involved in the development. This delay hinders the formalization of a standard that is already deemed essential by the industry. Poinsot and other contributors are eager for guidance from the BIP editors to understand their expectations better and to align with the requirements for formal acceptance. - This situation underscores a larger issue regarding the process of managing and implementing improvements within the Bitcoin ecosystem. The current impasse calls attention to the necessity for a more efficient, responsive, and transparent system for handling such proposals. A system that offers clearer communication and support could significantly benefit the community, especially those dedicated to enhancing the Bitcoin infrastructure. Moreover, the recent assignment of a BIP number, BIP 388, as mentioned by Michael Folkson, may represent a step towards resolving these procedural bottlenecks and ensuring that contributors like Poinsot receive the recognition and direction needed to uphold the ongoing development and standardization efforts in the Bitcoin space. - For those interested in further details about Bitcoin and its ongoing developments, educational resources are available at [Port of Bitcoin](https://www.youtube.com/@portofbitcoin). - 2024-01-25T16:49:49+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml b/static/bitcoin-dev/Dec_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml index 44ed433b99..14bf22511f 100644 --- a/static/bitcoin-dev/Dec_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml +++ b/static/bitcoin-dev/Dec_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) - 2023-12-22T14:19:32.416217+00:00 - - Johan Torås Halseth 2023-12-21 13:34:36+00:00 - - - Antoine Riard 2023-12-17 22:56:38+00:00 - - - Johan Torås Halseth 2023-12-11 09:17:23+00:00 - - - Antoine Riard 2023-11-21 02:39:45+00:00 - - - Johan Torås Halseth 2023-10-26 16:52:03+00:00 - + 2025-09-26T14:23:02.062339+00:00 + python-feedgen + + + [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) Johan Torås Halseth + 2023-10-26T16:52:00.000Z + + + Antoine Riard + 2023-11-21T02:39:00.000Z + + + Johan Torås Halseth + 2023-12-11T09:17:00.000Z + + + Antoine Riard + 2023-12-17T22:56:00.000Z + + + Johan Torås Halseth + 2023-12-21T13:34:00.000Z + + - python-feedgen + 2 Combined summary - HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) - 2023-12-22T14:19:32.416275+00:00 + 2025-09-26T14:23:02.063188+00:00 + 2023-12-21T13:34:36+00:00 In a detailed examination of the security and functionality of the Lightning Network (LN) within Bitcoin's financial ecosystem, programmers Antoine and Johan engage in a technical discourse exploring potential vulnerabilities and solutions. The focus lies on the new covenant mechanism proposed as part of Bitcoin's Eltoo update, which simplifies LN transactions by collapsing multiple Hash Time-Locked Contracts (HTLCs) into a single output. This mechanism requires a user to provide a preimage and signature to spend an aggregated HTLC output, which can represent numerous individual HTLC payouts within standard transaction relay limits. A revelation made during this conversation is that counterparty attacks could occur through partial preimage revelation during transactions, enabling the replacement of legitimate network transactions with high-fee, low-value spends that lead to double-spending. - Antoine elaborates on an attack scenario involving Alice and Bob, where Bob could steal a larger HTLC payout by repeatedly replacing Alice's transactions with his own that carry higher fees. Such attacks exploit network mempool congestion, delaying the confirmation of malicious transactions. Antoine suggests that simply implementing self-adjusting fees will not suffice; instead, he proposes adding a sliding delay to HTLC timelocks based on block feerate to thwart attackers. The discussion also ventures into how witness size growth in a taproot-world scenario could be managed and considers efficient Script-level testing of partial set membership as a solution. - Further discussions involve the security implications of not broadcasting a revoked state in the Eltoo protocol, as raised by Antoine, and Johan's concern about managing an exponential growth in state combinations resulting from this vulnerability. They delve into the practical aspects of addressing these complexities, emphasizing the need for strategies to maintain system integrity. - The blog post transitions to discussing transaction recycling and slot jamming attacks, which are enabled by changes in HTLC second-level transactions for anchor channel types. It now allows additional fees to be added without invalidating previous signatures. The aggregation of HTLC outputs, while beneficial for reducing fee-bumping reserve requirements, introduces concerns about malleability and the depletion of value through excessive miners' fees. Segregating HTLC claims into separate outputs and introducing covenants might be a viable mitigation strategy. Other considerations include the current protocol limit affecting long-term payment throughput on the LN and the use of taproot branches to maintain near-constant size for claimed offered HTLCs. An exploration is made regarding the use of advanced cryptosystems to enhance scalability and security, despite trimmed HTLCs due to dust limits. - For further insights, the email refers readers to additional resources including GitHub repositories, commits demonstrating test attacks, and scholarly discussions. This comprehensive analysis underscores the importance of understanding not only the technical aspects but also the game-theoretical implications of cryptocurrency protocols to safeguard against potential threats to transaction processes on the Lightning Network. - 2023-12-21T13:34:36+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_Lamport-scheme-not-signature-to-economize-on-L1.xml b/static/bitcoin-dev/Dec_2023/combined_Lamport-scheme-not-signature-to-economize-on-L1.xml index b41e7815e6..e5532dbe0c 100644 --- a/static/bitcoin-dev/Dec_2023/combined_Lamport-scheme-not-signature-to-economize-on-L1.xml +++ b/static/bitcoin-dev/Dec_2023/combined_Lamport-scheme-not-signature-to-economize-on-L1.xml @@ -1,68 +1,27 @@ - + 2 Combined summary - Lamport scheme (not signature) to economize on L1 - 2024-01-06T02:09:52.329538+00:00 - - yurisvb at pm.me 2024-01-05 18:22:44+00:00 - - - yurisvb at pm.me 2024-01-05 18:02:39+00:00 - - - David A. Harding 2024-01-01 18:57:13+00:00 - - - yurisvb at pm.me 2024-01-01 10:17:07+00:00 - - - David A. Harding 2023-12-31 19:33:24+00:00 - - - yurisvb at pm.me 2023-12-31 17:42:19+00:00 - - - yurisvb at pm.me 2023-12-29 00:30:30+00:00 - - - yurisvb at pm.me 2023-12-23 00:26:07+00:00 - - - yurisvb at pm.me 2023-12-22 15:32:38+00:00 - - - G. Andrew Stone 2023-12-22 04:52:08+00:00 - - - yurisvb at pm.me 2023-12-21 16:07:27+00:00 - - - Nagaev Boris 2023-12-20 21:33:56+00:00 - - - yurisvb at pm.me 2023-12-19 21:22:20+00:00 - - - Nagaev Boris 2023-12-19 17:08:40+00:00 - - - yurisvb at pm.me 2023-12-19 14:07:23+00:00 - - - Nagaev Boris 2023-12-19 00:45:45+00:00 - - - yurisvb at pm.me 2023-12-18 22:43:48+00:00 - - - Nagaev Boris 2023-12-18 16:45:15+00:00 - - - Sergio Demian Lerner 2023-12-18 12:29:48+00:00 - - - yurisvb at pm.me 2023-12-18 01:37:23+00:00 - + 2025-09-26T14:22:47.150758+00:00 + python-feedgen + + + yurisvb + 2024-01-01T10:17:00.000Z + + + David A. Harding + 2024-01-01T18:57:00.000Z + + + yurisvb + 2024-01-05T18:02:00.000Z + + + yurisvb + 2024-01-05T18:22:00.000Z + + @@ -83,41 +42,27 @@ - python-feedgen + 2 Combined summary - Lamport scheme (not signature) to economize on L1 - 2024-01-06T02:09:52.329686+00:00 + 2025-09-26T14:22:47.151401+00:00 + 2024-01-05T18:22:44+00:00 Recent updates to Bitcoin protocols have resulted in transaction authentication requiring only 36 bytes and dropping to 16 bytes for address reuse due to the Lamport scheme. A discussion on Twitter Spaces is scheduled to deliberate these changes. - Dave expresses skepticism about the benefits of reducing transaction sizes through new cryptographic elements, questioning whether such incremental savings warrant the potential risks and challenges in gaining community acceptance. - Another email suggests that while integrating a new scheme could fit within Bitcoin's existing framework, convincing miners and balancing the slowed validation process present significant hurdles, invoking the No-Free-Lunch Principle. - Research indicates signature serialization makes up 14-16% of a Bitcoin transaction size; thus, new signature schemes could reduce block space usage by a similar margin. However, practicality and costs of implementation via soft or hard fork are concerns. - A cryptographic protocol offering up to a 66% reduction in blockchain footprint has been developed, based on the difficulty of factorizing polynomials. This is documented on GitHub and is being prepared as a Bitcoin Improvement Proposal. - A correction was issued concerning the description of a function related to pre-image problems, now correctly mapping 'a valid LAMPPRI' to an address and signature format. Further details on entropy calculations are forthcoming. - The vulnerabilities of cryptographic schemes are under examination, with a focus on cryptanalysis and minimizing collision rates in hash functions. The possibility of a multi-use version of the scheme is considered to further decrease blockchain bloat. - Security concerns for a proposed change include implications for chain reorganizations and double-spending attacks, with fears it may increase the attack surface. Measures against rainbow-table attacks and nonces as salts are recommended, and reassessment of the adversarial model is promised. - Consensus emerges that hash functions should have digest sizes double their symmetric key size to prevent collision attacks. A 26% reduction in block space utilization is possible, but security may be compromised. - Further discussions involve optimizing 12-byte hashes instead of 14-byte ones for efficiency, broadcasting ECCPUB to mitigate LSIG miner risks, standardizing fingerprint to 128 bits, and considering Schnorr keys for maintaining security standards. - Comparing cryptographic schemes, Lamport leads to an 80-byte footprint versus Taproot's 96 bytes, with possible equal space requirements after additional Lamport space needs. Transaction timing simplification proposes fixing T2 at 48 hours after T0. - Lamport hashes use a lengthy hash of key fingerprints, with KDFs generating ECCPRI and ECCPUB derived from them, leading to Bitcoin addresses resistant to brute force. Transaction signing processes and mining fee structures are explained, focusing on the single-use economic model for Lamport transactions. - Security concerns include attackers broadcasting first bundles after cracking hashes and the need to break a second hashing layer. The weakest link principle illustrates system robustness, emphasizing the difficulty of breaking Lamport chains compared to double-spending attacks. - Schnorr signatures' compactness raises questions about their security effectiveness. Cryptographic protocol developments like MAVE signature scheme, MAVEPAY cryptocurrency, and FawkesCoin based on the Guy Fawkes Protocol are mentioned by R. M. Needham. - An enhancement for Layer 1 blockchain byte-efficiency combines the Lamport Scheme with a dual-key system, including a penalty payment system for unfulfilled commitments and suggesting Argon2 for potential 12-byte hashes, significantly reducing space from ECC signatures. - 2024-01-05T18:22:44+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_Ordinal-Inscription-Size-Limits.xml b/static/bitcoin-dev/Dec_2023/combined_Ordinal-Inscription-Size-Limits.xml index b2e4dc1910..3a52cc01d6 100644 --- a/static/bitcoin-dev/Dec_2023/combined_Ordinal-Inscription-Size-Limits.xml +++ b/static/bitcoin-dev/Dec_2023/combined_Ordinal-Inscription-Size-Limits.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Ordinal Inscription Size Limits - 2024-01-04T02:00:07.522616+00:00 - - Erik Aronesty 2024-01-03 13:05:42+00:00 - - - Brad Morrison 2024-01-03 09:11:58+00:00 - - - Erik Aronesty 2024-01-01 16:08:29+00:00 - - - Brad Morrison 2024-01-01 13:33:02+00:00 - - - Erik Aronesty 2023-12-30 09:58:41+00:00 - - - Nagaev Boris 2023-12-29 19:01:52+00:00 - - - Greg Tonoski 2023-12-29 12:27:42+00:00 - - - Aymeric Vitte 2023-02-07 12:17:24+00:00 - - - Erik Aronesty 2023-02-06 18:05:05+00:00 - - - Claus Ehrenberg 2023-02-06 17:31:45+00:00 - - - Erik Aronesty 2023-02-06 16:39:14+00:00 - - - Kostas Karasavvas 2023-02-04 14:25:58+00:00 - - - Melvin Carvalho 2023-02-03 19:56:16+00:00 - - - Erik Aronesty 2023-01-31 08:58:46+00:00 - - - Robert Dickinson 2023-01-29 10:34:54+00:00 - - - Aymeric Vitte 2023-01-28 16:47:46+00:00 - - - alicexbt 2023-01-28 10:58:12+00:00 - - - Robert Dickinson 2023-01-28 04:26:15+00:00 - - - Aymeric Vitte 2023-01-27 15:43:46+00:00 - - - Andrew Poelstra 2023-01-27 13:21:00+00:00 - - - rotmaxi 2023-01-27 12:58:49+00:00 - - - Robert Dickinson 2023-01-27 12:44:10+00:00 - + 2025-09-26T14:22:49.301993+00:00 + python-feedgen + + + [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson + 2023-01-27T12:44:00.000Z + + + rot13maxi + 2023-01-27T12:58:00.000Z + + + Andrew Poelstra + 2023-01-27T13:21:00.000Z + + + Aymeric Vitte + 2023-01-27T15:43:00.000Z + + + Robert Dickinson + 2023-01-28T04:26:00.000Z + + + alicexbt + 2023-01-28T10:58:00.000Z + + + Aymeric Vitte + 2023-01-28T16:47:00.000Z + + + Robert Dickinson + 2023-01-29T10:34:00.000Z + + + Erik Aronesty + 2023-01-31T08:58:00.000Z + + + Melvin Carvalho + 2023-02-03T19:56:00.000Z + + + Kostas Karasavvas + 2023-02-04T14:25:00.000Z + + + Erik Aronesty + 2023-02-06T16:39:00.000Z + + + Claus Ehrenberg + 2023-02-06T17:31:00.000Z + + + Erik Aronesty + 2023-02-06T18:05:00.000Z + + + Aymeric Vitte + 2023-02-07T12:17:00.000Z + + + Greg Tonoski + 2023-12-29T12:27:00.000Z + + + Nagaev Boris + 2023-12-29T19:01:00.000Z + + + Erik Aronesty + 2023-12-30T09:58:00.000Z + + + Brad Morrison + 2024-01-01T13:33:00.000Z + + + Erik Aronesty + 2024-01-01T16:08:00.000Z + + + Brad Morrison + 2024-01-03T09:11:00.000Z + + + Erik Aronesty + 2024-01-03T13:05:00.000Z + + @@ -91,29 +116,21 @@ - python-feedgen + 2 Combined summary - Ordinal Inscription Size Limits - 2024-01-04T02:00:07.522763+00:00 + 2025-09-26T14:22:49.304306+00:00 + 2024-01-03T13:05:42+00:00 The Bitcoin programming community is engaged in discussions focusing on blockchain scalability, transaction efficiency, and data storage. Scalability challenges stem not from block size but from the broadcasting and storing of transactions across network nodes. Alternatives like the Lightning Network and covenant technology are being explored to address these issues. - Comparisons with credit card payment systems highlight Bitcoin's higher transaction costs due to fees that control spam but also limit its use for payments. Proposals include increasing block size to lower fees and make Bitcoin more competitive. - Spam prevention via transaction fees is effective yet inconsistent; advanced methods like payment pools and tree payments have been suggested to improve this and can be found at [UTXOs Scaling](https://utxos.org/uses/scaling/). Innovative data storage within transactions using multisig and Taproot’s Merkle proofs is being debated, with suggestions for natural economic deterrents to discourage misuse. - Discussions on witness data storage involve concerns about storing 'toxic data' and proposals to limit data size or alter incentive structures. GitHub references such as [PR 28408](https://github.com/bitcoin/bitcoin/pull/28408) and [Issue 29146](https://github.com/bitcoin/bitcoin/issues/29146) indicate a broader dialogue on control mechanisms against unwanted data, including deprecating certain opcodes. - Storing NFT content as witness data poses risks regarding node storage capacity and disk usage. Suggestions include imposing size limits and alternative methods like extension blocks. Linking sats to real-world deeds is considered, however, storing actual property on the blockchain is seen as impractical. - -Robert Dickinson and Alicexbt contribute their perspectives on storage capacity and blockchain space management. Dickinson recommends premium charges for image storage, whereas Alicexbt advises capacity planning and proposes a "local bitcoin" system to avoid main chain storage congestion. - +Robert Dickinson and Alicexbt contribute their perspectives on storage capacity and blockchain space management. Dickinson recommends premium charges for image storage, whereas Alicexbt advises capacity planning and proposes a "local bitcoin" system to avoid main chain storage congestion. Amidst this technical debate, there is also discussion about the cultural and innovative uses of data storage, such as embedding images during festivals. However, there are calls for responsible usage and education to prevent negative consequences from arbitrary data storage. - Aymeric Vitte presents a vision for integrating Bitcoin into the NFT and 'web3' sphere. He suggests a centralized bitcoin-based NFT system for efficient referencing of low-value NFTs in transactions, contrasting with decentralized approaches. - The debate considers balancing innovation with the practicalities of Bitcoin’s infrastructure. Core developers face the challenge of addressing diverse opinions and the long-term effects of permitting unlimited data storage through witness data and ordinals, aiming to ensure Bitcoin's evolution remains robust and sustainable. - 2024-01-03T13:05:42+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_Scaling-Lightning-Safely-With-Feerate-Dependent-Timelocks.xml b/static/bitcoin-dev/Dec_2023/combined_Scaling-Lightning-Safely-With-Feerate-Dependent-Timelocks.xml index 2c83a1f4b2..834f20e380 100644 --- a/static/bitcoin-dev/Dec_2023/combined_Scaling-Lightning-Safely-With-Feerate-Dependent-Timelocks.xml +++ b/static/bitcoin-dev/Dec_2023/combined_Scaling-Lightning-Safely-With-Feerate-Dependent-Timelocks.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Scaling Lightning Safely With Feerate-Dependent Timelocks - 2023-12-31T02:07:50.710158+00:00 - - Nagaev Boris 2023-12-30 03:20:37+00:00 - - - David A. Harding 2023-12-30 03:11:48+00:00 - - - Nagaev Boris 2023-12-30 01:17:01+00:00 - - - David A. Harding 2023-12-30 00:37:14+00:00 - - - David A. Harding 2023-12-29 18:11:43+00:00 - - - Eric Voskuil 2023-12-28 18:42:39+00:00 - - - jlspc 2023-12-28 18:19:06+00:00 - - - jlspc 2023-12-28 18:06:00+00:00 - - - Eric Voskuil 2023-12-23 04:09:15+00:00 - - - Nagaev Boris 2023-12-22 16:36:56+00:00 - - - jlspc 2023-12-22 01:25:33+00:00 - - - Antoine Riard 2023-12-17 23:01:22+00:00 - - - jlspc 2023-12-14 17:07:40+00:00 - + 2025-09-26T14:22:42.922582+00:00 + python-feedgen + + + [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks jlspc + 2023-12-14T17:07:00.000Z + + + Antoine Riard + 2023-12-17T23:01:00.000Z + + + jlspc + 2023-12-22T01:25:00.000Z + + + Nagaev Boris + 2023-12-22T16:36:00.000Z + + + Eric Voskuil + 2023-12-23T04:09:00.000Z + + + jlspc + 2023-12-28T18:06:00.000Z + + + jlspc + 2023-12-28T18:19:00.000Z + + + Eric Voskuil + 2023-12-28T18:42:00.000Z + + + David A. Harding + 2023-12-29T18:11:00.000Z + + + David A. Harding + 2023-12-30T00:37:00.000Z + + + Nagaev Boris + 2023-12-30T01:17:00.000Z + + + David A. Harding + 2023-12-30T03:11:00.000Z + + + Nagaev Boris + 2023-12-30T03:20:00.000Z + + @@ -55,23 +71,18 @@ - python-feedgen + 2 Combined summary - Scaling Lightning Safely With Feerate-Dependent Timelocks - 2023-12-31T02:07:50.710256+00:00 + 2025-09-26T14:22:42.924018+00:00 + 2023-12-30T03:20:37+00:00 The discourse among Bitcoin developers is focused on the implementation of Feerate-Dependent Timelocks (FDTs) and their potential impact on the network. Boris Nagaev's initial proposition that miners offer a fee discount for out-of-band payments to increase earnings through faster transactions has been met with skepticism due to the 'free rider' problem, where non-discounting miners could ultimately benefit more. This could lead to adjustments in contract protocols using FDTs or miners exiting the market. - Eric Voskuil raises concerns about the threat to Bitcoin's decentralization and censorship resistance from out-of-band fee payments, stressing the importance of maintaining in-band fees for transaction security. A technical challenge associated with FDTs involves pruned nodes not having median feerate information post-upgrade, potentially affecting new consensus rule enforcement. A proposed workaround is to have upgraded nodes gather new median feerates and enforce FDT rules only when data is available, advocating cautious user strategies during transition. - John highlights that Forward-Dated Transactions rely on the alignment of timelock satisfaction windows to reduce dishonest mining and suggests that consecutive aligned windows can balance security against latency. The discussion includes the idea of a standardized global window size for simplifying verification processes and improving efficiency. - Antoine and John provide insight into the specifics of FDTs, explaining that transactions must wait for a qualifying aligned window before being included in the blockchain, assuming miners behave honestly. They also discuss the assumption that transactions with lower fee rates will be mined successfully during these windows. - -Separately, the debate covers the proposal of FDTs to address issues such as congestion by adjusting transaction inclusion based on block fee rates, aiming to prevent "forced expiration spam" attacks. The FDT mechanism incorporates parameters like 'feerate_value_bound,' 'window_size,' and 'block_count' to delay confirmations if median fee rates exceed certain bounds. While rooted in bip68 and bip113, enhancements are suggested for better control during high-fee periods. In the context of the Lightning Network, pre-signed transactions could be deferred if fee conditions aren't met, and modifications to the bip341 annex could allow individual HTLC outputs within a single transaction to have varying FDT settings. - +Separately, the debate covers the proposal of FDTs to address issues such as congestion by adjusting transaction inclusion based on block fee rates, aiming to prevent "forced expiration spam" attacks. The FDT mechanism incorporates parameters like 'feerate_value_bound,' 'window_size,' and 'block_count' to delay confirmations if median fee rates exceed certain bounds. While rooted in bip68 and bip113, enhancements are suggested for better control during high-fee periods. In the context of the Lightning Network, pre-signed transactions could be deferred if fee conditions aren't met, and modifications to the bip341 annex could allow individual HTLC outputs within a single transaction to have varying FDT settings. Further considerations include a 'claim_grace_period' to counteract fee-rate races and a 'number_of_windows' parameter that would increase storage requirements but is deemed feasible. The dialogue encapsulates optimism about FDTs mitigating vulnerabilities from congestion, enhancing security while maintaining capital efficiency, and offering protection against fee manipulation by dishonest miners. Despite some attack vectors persisting, FDTs are seen as raising the difficulty for attackers without guaranteeing absolute security. Continuous innovation is emphasized for addressing network congestion and improving the safety and protocols of the Bitcoin and Lightning Networks. - 2023-12-30T03:20:37+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_Swift-Activation-CTV.xml b/static/bitcoin-dev/Dec_2023/combined_Swift-Activation-CTV.xml index 0992d9cf99..f3a8a4cf29 100644 --- a/static/bitcoin-dev/Dec_2023/combined_Swift-Activation-CTV.xml +++ b/static/bitcoin-dev/Dec_2023/combined_Swift-Activation-CTV.xml @@ -1,50 +1,39 @@ - + 2 Combined summary - Swift Activation - CTV - 2024-01-04T02:10:09.560333+00:00 - - Anthony Towns 2024-01-03 08:36:02+00:00 - - - alicexbt 2024-01-02 16:43:22+00:00 - - - Ryan Breen 2024-01-02 16:24:06+00:00 - - - Erik Aronesty 2024-01-02 14:32:29+00:00 - - - Michael Folkson 2024-01-02 13:52:20+00:00 - - - Erik Aronesty 2024-01-01 17:11:24+00:00 - - - Michael Folkson 2024-01-01 16:37:35+00:00 - - - Michael Folkson 2023-12-30 13:54:04+00:00 - - - Erik Aronesty 2023-12-30 08:59:45+00:00 - - - Anthony Towns 2023-12-30 08:05:54+00:00 - - - alicexbt 2023-12-22 22:34:52+00:00 - - - alicexbt 2023-12-22 01:56:09+00:00 - - - Luke Dashjr 2023-12-22 01:05:12+00:00 - - - alicexbt 2023-12-20 01:44:58+00:00 - + 2025-09-26T14:22:55.686203+00:00 + python-feedgen + + + Michael Folkson + 2024-01-01T16:37:00.000Z + + + Erik Aronesty + 2024-01-01T17:11:00.000Z + + + Michael Folkson + 2024-01-02T13:52:00.000Z + + + Erik Aronesty + 2024-01-02T14:32:00.000Z + + + Ryan Breen + 2024-01-02T16:24:00.000Z + + + alicexbt + 2024-01-02T16:43:00.000Z + + + Anthony Towns + 2024-01-03T08:36:00.000Z + + @@ -59,25 +48,19 @@ - python-feedgen + 2 Combined summary - Swift Activation - CTV - 2024-01-04T02:10:09.560439+00:00 + 2025-09-26T14:22:55.687203+00:00 + 2024-01-03T08:36:02+00:00 The advancement of Bitcoin's protocol through CheckTemplateVerify (CTV) has sparked a debate among developers, highlighting both the feature's potential benefits and the challenges it presents. CTV is designed to provide functionalities similar to ANYONECANPAY, allowing for additional inputs to be attached. It has shown promise in projects such as James O'Beirne's vault prototype and Jeremy Rubin's Sapio smart contracting language, suggesting its use can enhance security through predefined spending conditions and improve layer-two solution efficiency. - However, safety concerns specifically related to CTV have not been adequately addressed in public discussions. The industry consensus leans towards broader agreement before implementing changes like CTV, considering Bitcoin's current scale and avoiding divisive outcomes. Educational resources are available on Michael Folkson's YouTube channel to aid in understanding these concepts. - Central to the debate is the technology's evaluation for Bitcoin integration, with covenants being emphasized for creating secure vaults. Despite practical applications on test networks, apprehensions remain about centralization risks and increased complexity compared to multi-signature protocols. The rush to activate covenants without wide consensus and the potential for a chain split are major concerns. APO is acknowledged for its design quality, but thoughts of its activation are deemed premature. - The process for consensus changes in Bitcoin demands careful scrutiny to ensure changes are widely understood and agreed upon. Critiques of CTV's initial goals suggest alternative methods might be preferable for achieving objectives like censorship resistance and financial autonomy. This suggests a cautious approach to evolving Bitcoin's transaction mechanisms and revisiting foundational principles. - Furthermore, while CTV could potentially elevate Bitcoin's scaling and privacy capabilities, its readiness for deployment is questioned. To promote further development and mainnet proof-of-concept implementations, bounties ranging from 0.01 BTC to 1 BTC have been offered on BIP Bounty, yet participation remains low. Misconceptions regarding TXHASH capabilities in relation to CTV need clarification, and the activation method and timeline are disputed, with some preferring a delayed activation. - There are calls for contributions to _reardencode_'s ongoing work to refine CTV, with discussions open on GitHub. The construction of a BIP 8 client with 'LOCKINONTIMEOUT' set to true, offering users an option, underpins the importance of community engagement. Luke, a community member, opposes what he sees as a deceptive proposal and suggests preparing countermeasures against miner-activated updates. - Updates to CTV activation parameters have been proposed, focusing on simplicity and practicality. With more PoCs available than during the Taproot upgrade, support for CTV seems to be growing. There is encouragement to build and run the specified client before January 1, 2024, to prevent delays that could push activation to 2028. These discussions highlight the importance of secure communication, as evidenced by the use of Proton Mail. - 2024-01-03T08:36:02+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2023/combined_V3-Transactions-are-still-vulnerable-to-significant-tx-pinning-griefing-attacks.xml b/static/bitcoin-dev/Dec_2023/combined_V3-Transactions-are-still-vulnerable-to-significant-tx-pinning-griefing-attacks.xml index 966a7dbf9a..db88b63925 100644 --- a/static/bitcoin-dev/Dec_2023/combined_V3-Transactions-are-still-vulnerable-to-significant-tx-pinning-griefing-attacks.xml +++ b/static/bitcoin-dev/Dec_2023/combined_V3-Transactions-are-still-vulnerable-to-significant-tx-pinning-griefing-attacks.xml @@ -1,32 +1,23 @@ - + 2 Combined summary - V3 Transactions are still vulnerable to significant tx pinning griefing attacks - 2024-01-03T02:14:28.371167+00:00 - - Peter Todd 2024-01-02 23:43:01+00:00 - - - Peter Todd 2024-01-02 23:18:11+00:00 - - - Gloria Zhao 2024-01-02 11:12:05+00:00 - - - Peter Todd 2023-12-20 21:11:28+00:00 - - - Greg Sanders 2023-12-20 20:16:25+00:00 - - - Peter Todd 2023-12-20 19:48:59+00:00 - - - Gloria Zhao 2023-12-20 19:13:22+00:00 - - - Peter Todd 2023-12-20 17:14:56+00:00 - + 2025-09-26T14:22:51.420907+00:00 + python-feedgen + + + Gloria Zhao + 2024-01-02T11:12:00.000Z + + + Peter Todd + 2024-01-02T23:18:00.000Z + + + Peter Todd + 2024-01-02T23:43:00.000Z + + @@ -35,27 +26,20 @@ - python-feedgen + 2 Combined summary - V3 Transactions are still vulnerable to significant tx pinning griefing attacks - 2024-01-03T02:14:28.371239+00:00 + 2025-09-26T14:22:51.421487+00:00 + 2024-01-02T23:43:01+00:00 The recent discourse among programmers has centered on the intricacies of Lightning Network transactions and their optimization. A key point of debate has been whether V3 transactions significantly improve upon the Lightning Network's existing security measures against transaction pinning. Analysis suggests that while V3 transactions aim to enhance the network by limiting transaction size to prevent pinning attacks, they may only offer marginal improvements over current protocols. - In regards to the frequency of force closes within the Lightning Network, recent data indicates that most channels are closed without any HTLCs outstanding. This finding suggests that the majority of force closures are of a more routine nature and not typically associated with contentious scenarios. Such information could inform future protocol developments, particularly those aimed at managing channel economics more efficiently. - Further discussions have shed light on the expected weights of commitment transactions, revealing that the size is smaller than previously calculated. For commitment transactions with no HTLC outputs, the size is approximately 162 virtual bytes (vB), expanding to 206vB with the inclusion of HTLCs. These figures contrast with the larger sizes often assumed in theoretical models and highlight the need for accurate data when considering protocol changes or optimizations. - An analysis of transaction pinning highlighted through a hypothetical scenario between two parties, Alice and Mallory, illustrates the cost implications of V3 versus non-V3 transactions. In this example, the additional fees an attacker can force upon a user are constrained by the rules of V3 transactions. The comparison shows that V3 transactions limit the potential damage significantly more than non-V3 transactions, thus reinforcing the intended security benefits of the newer protocol version. - Critiques have also been raised regarding the current implementation of anchor outputs in Lightning channels. Specifically, it has been suggested that the use of two anchor outputs is unnecessary and that a single output would suffice. This critique draws upon insights from prominent contributors in the cryptocurrency development community, who argue for more efficient use of anchors. - The limitations of Child Pays for Parent (CPFP) transactions within Bitcoin's protocol were also discussed, focusing on the static approach currently employed. The requirement for users to choose the CPFP layer size beforehand, which is arbitrarily set at 1 kilovirtualbyte, allows for a reasonable number of taproot inputs but lacks adaptability. Recognizing the need for a more dynamic solution, it is acknowledged that significant systemic changes would be necessary for such advancements. - -Lastly, the conversation touched upon the concept of "pinning potential" and the various factors influencing it, including the management of UTXOs and the value of commitment transactions. While the constraints under the current protocol are far from ideal, it is noted that the situation has improved considerably, offering better protection against pinning compared to previous iterations of the network. - +Lastly, the conversation touched upon the concept of "pinning potential" and the various factors influencing it, including the management of UTXOs and the value of commitment transactions. While the constraints under the current protocol are far from ideal, it is noted that the situation has improved considerably, offering better protection against pinning compared to previous iterations of the network. Overall, the discourse emphasizes the importance of continuous evaluation and refinement of transaction protocols within the Lightning Network and the Bitcoin ecosystem. Despite the advancements brought forth by V3 transactions, the consensus among developers is that there remains room for improvement in safeguarding against transaction pinning and optimizing network operations. - 2024-01-02T23:43:01+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.xml b/static/bitcoin-dev/Dec_2024/combined_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.xml index 23aefff13a..b1ea9ee0fe 100644 --- a/static/bitcoin-dev/Dec_2024/combined_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.xml +++ b/static/bitcoin-dev/Dec_2024/combined_-BIP-Proposal-Redefinition-of-the-Bitcoin-Unit-to-the-Base-Denomination.xml @@ -1,33 +1,36 @@ - + 2 Combined summary - [BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination - 2024-12-16T02:44:28.929637+00:00 - - Michael Cassano 2024-12-13 17:16:00+00:00 - - - George Burke 2024-12-13 15:09:00+00:00 - - - Bitcoin Error Log 2024-12-12 19:52:00+00:00 - + 2025-09-26T14:34:56.824222+00:00 + python-feedgen + + + [BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination Bitcoin Error Log + 2024-12-12T19:52:00.000Z + + + George Burke + 2024-12-13T15:09:00.000Z + + + Michael Cassano + 2024-12-13T17:16:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Redefinition of the Bitcoin Unit to the Base Denomination - 2024-12-16T02:44:28.929687+00:00 + 2025-09-26T14:34:56.824750+00:00 - In a recent discourse within the Bitcoin development community, a novel proposal has been tabled that seeks to alter the conventional unit representation of Bitcoin. This proposition advocates for a radical departure from the current system, where one bitcoin is subdivided into 100 million base units (sats), each represented down to eight decimal places. The essence of the proposal is to recalibrate the unit definition so that the smallest indivisible unit in the Bitcoin protocol, currently known as "satoshi" or "sat," would henceforth be recognized as "one bitcoin." This change aims to simplify the currency's accounting system by eliminating decimals, thereby facilitating easier transaction processes and enhancing the overall comprehension of Bitcoin's value system. - + 2024-12-13T17:16:00+00:00 + In a recent discourse within the Bitcoin development community, a novel proposal has been tabled that seeks to alter the conventional unit representation of Bitcoin. This proposition advocates for a radical departure from the current system, where one bitcoin is subdivided into 100 million base units (sats), each represented down to eight decimal places. The essence of the proposal is to recalibrate the unit definition so that the smallest indivisible unit in the Bitcoin protocol, currently known as "satoshi" or "sat," would henceforth be recognized as "one bitcoin." This change aims to simplify the currency's accounting system by eliminating decimals, thereby facilitating easier transaction processes and enhancing the overall comprehension of Bitcoin's value system. The proponents of this change underscore several benefits designed to enhance user interaction with Bitcoin. One of the primary advantages includes simplifying mental calculations and reducing confusion associated with the decimal representation of Bitcoin values. By shifting to an integer-based display format, the proposal also seeks to preempt the necessity for introducing new fractional denominations as the currency gains wider adoption and its value increases. Furthermore, it addresses concerns related to unit bias and misinformation about Bitcoin’s divisibility which can affect new users' understanding and adoption. - -Critically, the proposal contrasts itself with previous attempts to introduce new denominational units, such as BIP 176's "bits," arguing that these efforts fall short of resolving the fundamental issues of complexity and confusion due to their reliance on decimal points and multiple denominations. The push towards an integer-only display framework is presented as a more straightforward, intuitive, and enduring solution for denoting Bitcoin's value. - +Critically, the proposal contrasts itself with previous attempts to introduce new denominational units, such as BIP 176's "bits," arguing that these efforts fall short of resolving the fundamental issues of complexity and confusion due to their reliance on decimal points and multiple denominations. The push towards an integer-only display framework is presented as a more straightforward, intuitive, and enduring solution for denoting Bitcoin's value. John Carvalho, the author behind this initiative, has made the draft proposal available on GitHub for community review at [this link](https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/BIP%2021Q.md). Carvalho emphasizes the importance of gathering feedback from the Bitcoin community to refine and possibly adopt this significant change in how Bitcoin's value is expressed, highlighting the critical role of consensus within the community in effecting such foundational adjustments. - 2024-12-13T17:16:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Adding-New-BIP-Editors.xml b/static/bitcoin-dev/Dec_2024/combined_Adding-New-BIP-Editors.xml index 1a37caf149..a4daebcf0f 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Adding-New-BIP-Editors.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Adding-New-BIP-Editors.xml @@ -1,308 +1,411 @@ - + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.152793+00:00 - - Murch 2024-12-10 22:37:00+00:00 - - - Mark Erhardt 2024-09-19 18:48:00+00:00 - - - Antoine Riard 2024-09-19 07:47:00+00:00 - - - Mark Erhardt 2024-09-18 18:25:00+00:00 - - - Murch 2024-05-13 18:33:00+00:00 - - - Antoine Riard 2024-04-25 06:42:00+00:00 - - - Anthony Towns 2024-04-23 22:15:00+00:00 - - - Ali Sherief 2024-04-22 04:28:00+00:00 - - - Steve Lee 2024-04-22 02:44:00+00:00 - - - Ava Chow 2024-04-22 00:06:00+00:00 - - - Matt Corallo 2024-04-21 23:01:00+00:00 - - - Antoine Riard 2024-04-21 20:48:00+00:00 - - - Michael Folkson 2024-04-21 19:18:00+00:00 - - - Ava Chow 2024-04-21 18:47:00+00:00 - - - Michael Folkson 2024-04-21 17:57:00+00:00 - - - Ava Chow 2024-04-21 16:39:00+00:00 - - - Michael Folkson 2024-04-21 11:43:00+00:00 - - - Ava Chow 2024-04-20 23:05:00+00:00 - - - Ava Chow 2024-04-20 22:47:00+00:00 - - - Michael Folkson 2024-04-20 22:21:00+00:00 - - - Steve Lee 2024-04-20 22:03:00+00:00 - - - Ava Chow 2024-04-20 21:37:00+00:00 - - - Steve Lee 2024-04-20 21:11:00+00:00 - - - Ava Chow 2024-04-20 21:08:00+00:00 - - - Ava Chow 2024-04-20 20:59:00+00:00 - - - Steve Lee 2024-04-20 20:46:00+00:00 - - - Michael Folkson 2024-04-20 19:59:00+00:00 - - - Ava Chow 2024-04-20 19:48:00+00:00 - - - Ava Chow 2024-04-20 19:14:00+00:00 - - - Olaoluwa Osuntokun 2024-04-19 22:32:00+00:00 - - - nsvrn 2024-04-17 23:58:00+00:00 - - - Ava Chow 2024-04-16 17:08:00+00:00 - - - NVK 2024-04-16 13:32:00+00:00 - - - Tim Ruffing 2024-04-16 12:34:00+00:00 - - - Matt Corallo 2024-04-15 17:50:00+00:00 - - - Sergi Delgado Segura 2024-04-11 14:22:00+00:00 - - - Ali Sherief 2024-04-07 10:11:00+00:00 - - - Larry Ruane 2024-04-05 19:18:00+00:00 - - - xBC 2024-04-04 12:58:00+00:00 - - - Niklas Goegge 2024-04-04 09:09:00+00:00 - - - Anthony Towns 2024-04-04 05:00:00+00:00 - - - Pieter Wuille 2024-04-03 19:44:00+00:00 - - - Fabian 2024-04-03 18:34:00+00:00 - - - Vasil Dimov 2024-04-03 17:24:00+00:00 - - - Juan Galt 2024-04-03 16:58:00+00:00 - - - Murch 2024-04-03 15:03:00+00:00 - - - Luke Dashjr 2024-04-02 15:39:00+00:00 - - - Gloria Zhao 2024-04-02 15:13:00+00:00 - - - Luke Dashjr 2024-04-02 14:28:00+00:00 - - - nvk 2024-04-02 14:24:00+00:00 - - - /dev /fd 2024-04-02 13:49:00+00:00 - - - Tim Ruffing 2024-04-02 13:17:00+00:00 - - - Michael Folkson 2024-04-02 08:18:00+00:00 - - - Ava Chow 2024-04-02 00:37:00+00:00 - - - /dev /fd 2024-04-01 23:55:00+00:00 - - - David A. Harding 2024-04-01 21:13:00+00:00 - - - Antoine Riard 2024-04-01 20:14:00+00:00 - - - Jonas Nick 2024-04-01 18:42:00+00:00 - - - Murch 2024-04-01 18:41:00+00:00 - - - Michael Folkson 2024-04-01 11:58:00+00:00 - - - /dev /fd 2024-04-01 06:21:00+00:00 - - - Ava Chow 2024-03-31 17:01:00+00:00 - - - Michael Folkson 2024-03-31 16:01:00+00:00 - - - Antoine Riard 2024-03-30 20:01:00+00:00 - - - Michael Folkson 2024-03-30 11:51:00+00:00 - - - Peter Todd 2024-03-30 04:04:00+00:00 - - - Keagan McClelland 2024-03-29 22:17:00+00:00 - - - Antoine Riard 2024-03-29 21:08:00+00:00 - - - /dev /fd 2024-03-29 05:24:00+00:00 - - - Michael Folkson 2024-03-29 02:34:00+00:00 - - - Matt Corallo 2024-03-28 21:19:00+00:00 - - - John C. Vernaleo 2024-03-28 20:59:00+00:00 - - - Matt Corallo 2024-03-28 20:31:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Antoine Riard 2024-03-28 19:42:00+00:00 - - - /dev /fd 2024-03-28 16:09:00+00:00 - - - Brandon Black 2024-03-28 15:50:00+00:00 - - - Murch 2024-03-28 13:02:00+00:00 - - - Matt Corallo 2024-03-27 23:54:00+00:00 - - - John C. Vernaleo 2024-03-27 23:39:00+00:00 - - - Murch 2024-03-27 23:36:00+00:00 - - - Murch 2024-03-27 21:25:00+00:00 - - - Chris Stewart 2024-03-14 11:56:00+00:00 - - - Jon A 2024-03-11 16:48:00+00:00 - - - Bitcoin Error Log 2024-03-10 17:27:00+00:00 - - - Michael Folkson 2024-03-09 10:46:00+00:00 - - - Keagan McClelland 2024-03-07 22:39:00+00:00 - - - Antoine Riard 2024-03-07 20:56:00+00:00 - - - Tim Ruffing 2024-02-28 16:31:00+00:00 - - - bitcoindevml.void 2024-02-28 11:12:00+00:00 - - - /dev /fd 2024-02-28 04:22:00+00:00 - - - Ava Chow 2024-02-27 23:26:00+00:00 - - - /dev /fd 2024-02-27 23:10:00+00:00 - - - Luke Dashjr 2024-02-27 22:57:00+00:00 - - - Luke Dashjr 2024-02-27 22:40:00+00:00 - - - Greg Tonoski 2024-02-27 21:48:00+00:00 - - - Léo Haf 2024-02-27 21:33:00+00:00 - - - Ava Chow 2024-02-27 20:11:00+00:00 - - - Ava Chow 2024-02-27 18:53:00+00:00 - + 2025-09-26T14:35:07.604753+00:00 + python-feedgen + + + Adding New BIP Editors 'Ava Chow' + 2024-02-27T18:53:00.000Z + + + Léo Haf' + 2024-02-27T20:11:00.000Z + + + Antoine Poinsot' + 2024-02-27T21:33:00.000Z + + + Greg Tonoski + 2024-02-27T21:48:00.000Z + + + Luke Dashjr + 2024-02-27T22:40:00.000Z + + + Ava Chow' + 2024-02-27T22:57:00.000Z + + + /dev /fd0 + 2024-02-27T23:10:00.000Z + + + Steve Lee + 2024-02-27T23:26:00.000Z + + + /dev /fd0 + 2024-02-28T04:22:00.000Z + + + bitcoin-dev-ml.void867 + 2024-02-28T11:12:00.000Z + + + Tim Ruffing + 2024-02-28T16:31:00.000Z + + + Antoine Riard + 2024-03-07T20:56:00.000Z + + + Keagan McClelland + 2024-03-07T22:39:00.000Z + + + Michael Folkson + 2024-03-09T10:46:00.000Z + + + Bitcoin Error Log + 2024-03-10T17:27:00.000Z + + + Jon A + 2024-03-11T16:48:00.000Z + + + Chris Stewart + 2024-03-14T11:56:00.000Z + + + Murch + 2024-03-27T21:25:00.000Z + + + Keagan McClelland + 2024-03-27T23:36:00.000Z + + + John C. Vernaleo + 2024-03-27T23:39:00.000Z + + + Matt Corallo + 2024-03-27T23:54:00.000Z + + + Murch + 2024-03-28T13:02:00.000Z + + + Brandon Black + 2024-03-28T15:50:00.000Z + + + /dev /fd0 + 2024-03-28T16:09:00.000Z + + + Antoine Riard + 2024-03-28T19:42:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Antoine Riard + 2024-03-28T20:31:00.000Z + + + John C. Vernaleo + 2024-03-28T20:59:00.000Z + + + Matt Corallo + 2024-03-28T21:19:00.000Z + + + Michael Folkson + 2024-03-29T02:34:00.000Z + + + /dev /fd0 + 2024-03-29T05:24:00.000Z + + + Antoine Riard + 2024-03-29T21:08:00.000Z + + + Keagan McClelland + 2024-03-29T22:17:00.000Z + + + Peter Todd + 2024-03-30T04:04:00.000Z + + + Michael Folkson + 2024-03-30T11:51:00.000Z + + + Antoine Riard + 2024-03-30T20:01:00.000Z + + + Michael Folkson + 2024-03-31T16:01:00.000Z + + + Ava Chow' + 2024-03-31T17:01:00.000Z + + + /dev /fd0 + 2024-04-01T06:21:00.000Z + + + Michael Folkson + 2024-04-01T11:58:00.000Z + + + Re: Adding New BIP Editors Murch + 2024-04-01T18:41:00.000Z + + + Jonas Nick + 2024-04-01T18:42:00.000Z + + + Antoine Riard + 2024-04-01T20:14:00.000Z + + + David A. Harding + 2024-04-01T21:13:00.000Z + + + /dev /fd0 + 2024-04-01T23:55:00.000Z + + + Ava Chow' + 2024-04-02T00:37:00.000Z + + + Michael Folkson + 2024-04-02T08:18:00.000Z + + + Time for an update to BIP2? Tim Ruffing + 2024-04-02T13:17:00.000Z + + + /dev /fd0 + 2024-04-02T13:49:00.000Z + + + nvk + 2024-04-02T14:24:00.000Z + + + Luke Dashjr + 2024-04-02T14:28:00.000Z + + + Gloria Zhao + 2024-04-02T15:13:00.000Z + + + Luke Dashjr + 2024-04-02T15:39:00.000Z + + + Murch + 2024-04-03T15:03:00.000Z + + + Juan Galt + 2024-04-03T16:58:00.000Z + + + Vasil Dimov + 2024-04-03T17:24:00.000Z + + + Fabian' + 2024-04-03T18:34:00.000Z + + + Pieter Wuille + 2024-04-03T19:44:00.000Z + + + Anthony Towns + 2024-04-04T05:00:00.000Z + + + Niklas Goegge + 2024-04-04T09:09:00.000Z + + + Adding New BIP Editors 0xB10C + 2024-04-04T12:58:00.000Z + + + Larry Ruane + 2024-04-05T19:18:00.000Z + + + Ali Sherief + 2024-04-07T10:11:00.000Z + + + Sergi Delgado Segura + 2024-04-11T14:22:00.000Z + + + Matt Corallo + 2024-04-15T17:50:00.000Z + + + Tim Ruffing + 2024-04-16T12:34:00.000Z + + + NVK + 2024-04-16T13:32:00.000Z + + + Ava Chow' + 2024-04-16T17:08:00.000Z + + + nsvrn' + 2024-04-17T23:58:00.000Z + + + Olaoluwa Osuntokun + 2024-04-19T22:32:00.000Z + + + Ava Chow' + 2024-04-20T19:14:00.000Z + + + NVK + 2024-04-20T19:48:00.000Z + + + Michael Folkson + 2024-04-20T19:59:00.000Z + + + Steve Lee + 2024-04-20T20:46:00.000Z + + + Ava Chow' + 2024-04-20T20:59:00.000Z + + + Ava Chow' + 2024-04-20T21:08:00.000Z + + + Steve Lee + 2024-04-20T21:11:00.000Z + + + Ava Chow' + 2024-04-20T21:37:00.000Z + + + Steve Lee + 2024-04-20T22:03:00.000Z + + + Michael Folkson + 2024-04-20T22:21:00.000Z + + + Ava Chow' + 2024-04-20T22:47:00.000Z + + + Ava Chow' + 2024-04-20T23:05:00.000Z + + + Michael Folkson + 2024-04-21T11:43:00.000Z + + + Ava Chow' + 2024-04-21T16:39:00.000Z + + + Michael Folkson + 2024-04-21T17:57:00.000Z + + + Ava Chow' + 2024-04-21T18:47:00.000Z + + + Michael Folkson + 2024-04-21T19:18:00.000Z + + + Antoine Riard + 2024-04-21T20:48:00.000Z + + + Matt Corallo + 2024-04-21T23:01:00.000Z + + + Ava Chow' + 2024-04-22T00:06:00.000Z + + + Steve Lee + 2024-04-22T02:44:00.000Z + + + Ali Sherief + 2024-04-22T04:28:00.000Z + + + Anthony Towns + 2024-04-23T22:15:00.000Z + + + Antoine Riard + 2024-04-25T06:42:00.000Z + + + Time for an update to BIP2? Murch + 2024-05-13T18:33:00.000Z + + + Murch + 2024-09-18T18:25:00.000Z + + + Antoine Riard + 2024-09-19T07:47:00.000Z + + + Murch + 2024-09-19T18:48:00.000Z + + + Murch + 2024-12-10T22:37:00.000Z + + @@ -403,21 +506,17 @@ - python-feedgen + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.153617+00:00 + 2025-09-26T14:35:07.614673+00:00 + 2024-12-10T22:37:00+00:00 In the realm of Bitcoin development, discussions pertaining to the enhancement of the Bitcoin Improvement Proposal (BIP) process have been prominent. A key focus has been on addressing the current bottleneck in managing BIPs, emphasized by Luke Dashjr's acknowledgment of his limited capacity to actively maintain the BIPs repository. This acknowledgment underscores the critical need for additional BIP editors to ensure an efficient and effective review and integration process for new proposals and amendments to existing ones. - The role of a BIP editor is significant, encompassing responsibilities such as assigning BIP numbers, merging pull requests for new proposals, making fixes to existing BIPs, and more, as outlined in BIP 2. The addition of new editors is envisaged as a pivotal measure to alleviate the backlog of submissions and augment the process's overall productivity. For the continuity and coherence of the BIP numbering system, it is imperative that any incoming editors concur on the established numbering scheme. - The selection criteria for new BIP editors highlight the necessity for candidates with a comprehensive background in Bitcoin development, showcasing a history of active participation and contributions. These individuals must possess the ability to impartially assess proposals, a quality that underscores the importance of objectivity in the role. - Within this context, Kanzure and RubenSomsen have been identified as exemplary candidates for the position of BIP editors. Their extensive involvement in Bitcoin development positions them as valuable additions to the editorial team. Their potential inclusion is anticipated to significantly ameliorate the management and advancement of the BIPs repository, offering substantial benefits to the Bitcoin development community. - This dialogue illustrates the collective effort within the Bitcoin developer ecosystem to refine the governance mechanisms surrounding BIPs. It emphasizes the commitment to ensuring that the process remains robust, transparent, and inclusive, facilitating the continuous evolution and improvement of Bitcoin. - 2024-12-10T22:37:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml b/static/bitcoin-dev/Dec_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml index 90e2185a26..284d5f9805 100644 --- a/static/bitcoin-dev/Dec_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml +++ b/static/bitcoin-dev/Dec_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml @@ -1,37 +1,41 @@ - + 2 - Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST" - 2024-12-20T02:24:21.673384+00:00 - - Tim Ruffing 2024-12-19 10:56:00+00:00 - - - Jonas Nick 2024-07-16 17:31:00+00:00 - - - David A. Harding 2024-07-16 16:43:00+00:00 - - - Tim Ruffing 2024-07-08 20:05:00+00:00 - + Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST" + 2025-09-26T14:34:50.411892+00:00 + python-feedgen + + + BIP Draft: "ChillDKG: Distributed Key Generation for FROST" Tim Ruffing + 2024-07-08T20:05:00.000Z + + + David A. Harding + 2024-07-16T16:43:00.000Z + + + Jonas Nick + 2024-07-16T17:31:00.000Z + + + Tim Ruffing + 2024-12-19T10:56:00.000Z + + - python-feedgen + 2 - Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST" - 2024-12-20T02:24:21.673433+00:00 + Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST" + 2025-09-26T14:34:50.412519+00:00 - Recent updates to a draft Bitcoin Improvement Proposal (BIP) have been shared, detailing numerous changes, improvements, and cleanups since its initial announcement. Significant amendments include fixing a security vulnerability concerning the CertEq signature not covering the entire message, adding blame functionality for identifying faulty parties with an investigation phase, making the threshold public key Taproot-safe by default, and allowing participants to encrypt the secret share intended for themselves. This encryption uses a symmetric approach to avoid the computational overhead of ECDH computations. The full draft of the BIP is accessible for review and feedback, with a particular interest in hearing from potential users and applications, such as wallets, regarding the design decisions, the API's fit, and possible improvements. The document is hosted on GitHub, available at [this link](https://github.com/BlockstreamResearch/bip-frost-dkg). Feedback is actively sought, especially on specifying the wire format and adding test vectors. Collaboration is ongoing with siv2r, author of another BIP draft for FROST signing, to ensure compatibility between proposals. Discussions are also open regarding how to best include the "secp256k1proto" package necessary for running the reference implementation, with current preference leaning towards keeping a "git-subtree" in the BIPs repo for completeness and archival purposes. - -Privacy concerns associated with recovery data in distributed key generation (DKG) processes are highlighted, pointing out the risks of sensitive information being stored in plaintext, such as long-term "host" public keys and the final threshold public key. The threat model considers adversaries accessing this data, potentially linking on-chain transactions to individuals and compromising privacy. Currently, the protocol does not require encryption of recovery data before backup, based on the premise that encryption is a local operation and does not affect communication protocols within the DKG framework. However, feedback suggests revisiting this stance for better clarity and guidance in the BIP, proposing the use of the DKG protocol seed to derive an encryption key, thereby enhancing security and privacy without adding complexity for participants. - + 2024-12-19T10:56:00+00:00 + Recent updates to a draft Bitcoin Improvement Proposal (BIP) have been shared, detailing numerous changes, improvements, and cleanups since its initial announcement. Significant amendments include fixing a security vulnerability concerning the CertEq signature not covering the entire message, adding blame functionality for identifying faulty parties with an investigation phase, making the threshold public key Taproot-safe by default, and allowing participants to encrypt the secret share intended for themselves. This encryption uses a symmetric approach to avoid the computational overhead of ECDH computations. The full draft of the BIP is accessible for review and feedback, with a particular interest in hearing from potential users and applications, such as wallets, regarding the design decisions, the API's fit, and possible improvements. The document is hosted on GitHub, available at [this link](https://github.com/BlockstreamResearch/bip-frost-dkg). Feedback is actively sought, especially on specifying the wire format and adding test vectors. Collaboration is ongoing with siv2r, author of another BIP draft for FROST signing, to ensure compatibility between proposals. Discussions are also open regarding how to best include the "secp256k1proto" package necessary for running the reference implementation, with current preference leaning towards keeping a "git-subtree" in the BIPs repo for completeness and archival purposes. +Privacy concerns associated with recovery data in distributed key generation (DKG) processes are highlighted, pointing out the risks of sensitive information being stored in plaintext, such as long-term "host" public keys and the final threshold public key. The threat model considers adversaries accessing this data, potentially linking on-chain transactions to individuals and compromising privacy. Currently, the protocol does not require encryption of recovery data before backup, based on the premise that encryption is a local operation and does not affect communication protocols within the DKG framework. However, feedback suggests revisiting this stance for better clarity and guidance in the BIP, proposing the use of the DKG protocol seed to derive an encryption key, thereby enhancing security and privacy without adding complexity for participants. Dave raises a question regarding the privacy implications of making public recovery data accessible in the ChillDKK protocol. He draws parallels with cryptocurrency security practices, particularly comparing the exposure levels of BIP32 HD paths and xpub data in terms of privacy impact. Dave's inquiry seeks to understand whether ChillDKG's approach to publishing recovery data more closely resembles the relatively benign disclosure of an HD path or the more concerning privacy issues associated with revealing an xpub. - Jonas, Nick, and Tim are working on a draft BIP focused on Distributed Key Generation for FROST Threshold Signatures, aiming to introduce it to the community for feedback and discussion. This draft includes design considerations, usage instructions, and a Python-based reference implementation, aiming to serve as the definitive specification for the proposal. The team invites the community to review their work hosted on GitHub, emphasizing the need for feedback on several underdeveloped aspects such as the wire format, test vectors, and formalizing secp256k1proto as an official Python package. This effort reflects the ongoing initiatives to enhance cryptographic practices within the Bitcoin ecosystem, highlighting the collaborative nature of developing secure and efficient distributed key generation mechanisms. - 2024-12-19T10:56:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml b/static/bitcoin-dev/Dec_2024/combined_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml index aadb679c5a..4ff6cbefb7 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Censorship-and-Privacy-in-Chaumian-ecash-implementations.xml @@ -1,33 +1,36 @@ - + 2 Combined summary - Censorship and Privacy in Chaumian ecash implementations - 2024-12-22T02:30:21.265720+00:00 - - /dev /fd0 2024-12-21 23:03:00+00:00 - - - conduition 2024-12-21 21:52:00+00:00 - - - /dev /fd0 2024-12-21 16:58:00+00:00 - + 2025-09-26T14:35:01.058904+00:00 + python-feedgen + + + Censorship and Privacy in Chaumian ecash implementations /dev /fd0 + 2024-12-21T16:58:00.000Z + + + conduition' + 2024-12-21T21:52:00.000Z + + + /dev /fd0 + 2024-12-21T23:03:00.000Z + + - python-feedgen + 2 Combined summary - Censorship and Privacy in Chaumian ecash implementations - 2024-12-22T02:30:21.265783+00:00 + 2025-09-26T14:35:01.059504+00:00 + 2024-12-21T23:03:00+00:00 The discussion revolves around concerns and misconceptions regarding censorship resistance in ecash implementations, particularly with the Cashu protocol. The original assertion challenged the claim that all ecash implementations are inherently resistant to censorship, highlighting that specific mechanisms, such as P2PK (Pay to Public Key) and authentication processes, could potentially enable censorship of individual users. In the case of P2PK, ecash tokens can be linked to public keys, making it possible to restrict transactions based on the identity of users. This is exacerbated by the use of Nostr keys, which, due to their unobfuscated nature, could allow for direct censorship based on the linked identity or even the content shared by the user. - Furthermore, the discussion touches upon how mints might enforce authentication and Know Your Customer (KYC) protocols, effectively barring users who refuse to comply from transacting with their ecash tokens. Such measures not only raise concerns about privacy but also contradict claims of censorship resistance. Despite these potential issues being acknowledged within the community, there seems to be a push towards marketing these systems as resistant to censorship. - The debate over these concerns has been ongoing, with notable discussions taking place on GitHub, illustrating differing perspectives on how to balance regulatory compliance with the foundational principles of privacy and freedom inherent to cryptocurrencies. A particular pull request detailed an authentication mechanism that directly links actions to users through a linking key, raising alarms about privacy compromises. Although this proposal was eventually closed in favor of a new mechanism aiming for clearer and possibly more privacy-conscious authentication, the core issue of potential censorship through KYC remains unresolved. - The controversy underscores a broader dilemma within the development of ecash systems: the need to navigate between creating a censorship-resistant platform and adhering to regulatory demands that might necessitate some form of user identification. While some argue for the necessity of standardized authentication to prevent fragmentation and ensure compliance, others fear that such moves could erode the very freedoms that cryptocurrencies seek to protect. This highlights a critical juncture at which the future direction of ecash development hangs in balance, between upholding privacy and freedom and accommodating regulatory pressures. - 2024-12-21T23:03:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Covenants-Support-Bitcoin-Wiki.xml b/static/bitcoin-dev/Dec_2024/combined_Covenants-Support-Bitcoin-Wiki.xml index a761f300a4..b33f24a9f8 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Covenants-Support-Bitcoin-Wiki.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Covenants-Support-Bitcoin-Wiki.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Covenants Support - Bitcoin Wiki - 2024-12-12T02:41:37.131461+00:00 - - Brandon Black 2024-12-11 15:11:00+00:00 - - - Anthony Towns 2024-12-11 13:28:00+00:00 - - - Brandon Black 2024-12-09 20:45:00+00:00 - - - Anthony Towns 2024-12-09 20:13:00+00:00 - - - Yuval Kogman 2024-12-07 01:42:00+00:00 - - - /dev /fd 2024-12-07 00:29:00+00:00 - - - Jonas Nick 2024-12-06 21:45:00+00:00 - - - /dev /fd 2024-11-29 14:08:00+00:00 - + 2025-09-26T14:35:05.314948+00:00 + python-feedgen + + + Covenants Support - Bitcoin Wiki /dev /fd0 + 2024-11-29T14:08:00.000Z + + + Jonas Nick + 2024-12-06T21:45:00.000Z + + + /dev /fd0 + 2024-12-07T00:29:00.000Z + + + Yuval Kogman + 2024-12-07T01:42:00.000Z + + + Anthony Towns + 2024-12-09T20:13:00.000Z + + + Brandon Black + 2024-12-09T20:45:00.000Z + + + Anthony Towns + 2024-12-11T13:28:00.000Z + + + Brandon Black + 2024-12-11T15:11:00.000Z + + @@ -35,21 +46,17 @@ - python-feedgen + 2 Combined summary - Covenants Support - Bitcoin Wiki - 2024-12-12T02:41:37.131531+00:00 + 2025-09-26T14:35:05.316029+00:00 + 2024-12-11T15:11:00+00:00 The email exchange primarily revolves around the clarification and critique of a misunderstood proposal regarding example scripts for Lightning Symmetry involving hypothetical opcodes not yet implemented, specifically OP_VAULT. Brandon, in his correspondence, emphasizes that his intention was to explore theoretical possibilities rather than present production-ready solutions. He points out the importance of understanding the context and the exploratory nature of such proposals before critiquing them. This highlights an ongoing dialogue within the Bitcoin Development Mailing List about the processes and standards for proposing, testing, and discussing new features or changes to the Bitcoin protocol. - -Brandon’s response to AJ underscores a broader issue within the Bitcoin developer community concerning the methodology of achieving consensus for proposals and the seriousness with which proposals are treated. He suggests that for a more effective consensus, it would be beneficial to ensure all objections or concerns have been addressed, aiming for unanimous agreement or at least a rough consensus when perfect agreement isn't possible. Furthermore, Brandon criticizes the careless publicizing of projects like "lnhance" without thorough testing, pointing out the necessity for proposals to undergo rigorous validation to avoid misleading the community. - +Brandon’s response to AJ underscores a broader issue within the Bitcoin developer community concerning the methodology of achieving consensus for proposals and the seriousness with which proposals are treated. He suggests that for a more effective consensus, it would be beneficial to ensure all objections or concerns have been addressed, aiming for unanimous agreement or at least a rough consensus when perfect agreement isn't possible. Furthermore, Brandon criticizes the careless publicizing of projects like "lnhance" without thorough testing, pointing out the necessity for proposals to undergo rigorous validation to avoid misleading the community. The discussion extends to the mechanisms for expressing opinions on opcode proposals within the Bitcoin developer community. Yuval Kogman outlines a nuanced system allowing developers to express their stance on proposals through seven options, emphasizing the need for a clear distinction between technical evaluation and perceived community support. This system aims to accommodate a wide range of opinions and encourages transparency by enabling contributors to link their rationale behind their opinions. The approach reflects an acknowledgment of the diverse perspectives within the community and the complexity of accurately gauging both technical merit and community backing. - An initiative to gather Bitcoin developers' opinions on various covenant proposals through a draft Bitcoin wiki page is introduced, aiming to facilitate consensus building. The wiki page serves as a platform for developers to list relevant opcodes, share insights, and contribute to the discussion on proposals like OP_CTV, which is noted for its potential benefits for implementations such as coinjoin. This initiative demonstrates a collective effort toward refining and agreeing upon proposals that could enhance the Bitcoin protocol. - Overall, these communications underscore the challenges and complexities of developing and achieving consensus on new features or changes within the Bitcoin protocol. They highlight the importance of clear communication, thorough testing, and inclusive discussions in fostering a constructive and forward-moving dialogue within the Bitcoin development community. - 2024-12-11T15:11:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml b/static/bitcoin-dev/Dec_2024/combined_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml index 2daaef2556..195bdf36ff 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml @@ -1,39 +1,45 @@ - + 2 - Combined summary - Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode - 2024-12-13T02:43:22.781715+00:00 - - Brandon Black 2024-12-12 05:49:00+00:00 - - - Weikeng Chen 2024-12-12 03:17:00+00:00 - - - Brandon Black 2024-12-09 22:06:00+00:00 - - - Andrew Poelstra 2024-12-09 19:08:00+00:00 - - - Weikeng Chen 2024-12-09 13:27:00+00:00 - + Combined summary - Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode + 2025-09-26T14:34:58.936669+00:00 + python-feedgen + + + Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode Weikeng Chen + 2024-12-09T13:27:00.000Z + + + Andrew Poelstra + 2024-12-09T19:08:00.000Z + + + Brandon Black + 2024-12-09T22:06:00.000Z + + + Weikeng Chen + 2024-12-12T03:17:00.000Z + + + Brandon Black + 2024-12-12T05:49:00.000Z + + - python-feedgen + 2 - Combined summary - Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode - 2024-12-13T02:43:22.781772+00:00 + Combined summary - Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode + 2025-09-26T14:34:58.937532+00:00 - In recent discussions on the Bitcoin Development Mailing List, a new approach to script execution in Bitcoin's scripting system has been broached. The conversation was sparked by suggestions around modifying the behavior of scripts with respect to conditional success validation. Specifically, the dialogue revolved around the potential use of "OP_SEGMENT" as suggested by Rusty Russell, aiming to redefine the "OP_SUCCESS" functionality to facilitate more granular control over script validation. This proposed mechanism, leveraging "OP_CODESEPARATOR", seeks to make only specific segments of a script unconditionally valid, rather than the entire script. Such an adjustment would allow for a nuanced approach to script execution, where each segment before an "OP_CODESEPARATOR" is treated distinctly regarding its success validation. This proposal also introduces the concept of a "SUCCESS" flag, which plays a critical role in this nuanced execution method. - -Further discussion highlighted the flexibility and strategic advantages offered by existing SUCCESSx codes in facilitating soft forks within the Bitcoin network. These codes are recognized for their foundational role in enabling upgrades without compromising the network’s stability. Andrew Poelstra's suggestion of transitioning one of these opcodes to an "OP_WEAK_SUCCESS" indicates a move towards utilizing these codes not just for network updates but for enhancing operational functionalities. This shift represents a broader perspective on developing the opcode infrastructure to cater to specialized applications while maintaining the integrity of the existing codebase. - -The utility of an "OP_SUCCESS" opcode was also elaborated upon, especially in the context of implementing fraud proofs in Bitcoin script. This opcode's functionality, allowing for immediate marking of script execution as successful, presents a significant advantage in scenarios requiring efficient identification of mismatches. Despite the potential for emulating this functionality through script rewriting, the complexity and inefficiency of such an alternative underscore the value of directly implementing "OP_SUCCESS". Tools exist for script rewriting, as indicated by a [GitHub resource](https://github.com/Bitcoin-Wildlife-Sanctuary/fraud-proof-compiler), yet they highlight the convoluted nature of achieving the same outcomes without a dedicated opcode. The conversation thus advocates for simplifying script development processes by incorporating opcodes like "OP_SUCCESS", aiming to enhance both efficiency and developer accessibility within the Bitcoin scripting environment. 2024-12-12T05:49:00+00:00 + In recent discussions on the Bitcoin Development Mailing List, a new approach to script execution in Bitcoin's scripting system has been broached. The conversation was sparked by suggestions around modifying the behavior of scripts with respect to conditional success validation. Specifically, the dialogue revolved around the potential use of "OP_SEGMENT" as suggested by Rusty Russell, aiming to redefine the "OP_SUCCESS" functionality to facilitate more granular control over script validation. This proposed mechanism, leveraging "OP_CODESEPARATOR", seeks to make only specific segments of a script unconditionally valid, rather than the entire script. Such an adjustment would allow for a nuanced approach to script execution, where each segment before an "OP_CODESEPARATOR" is treated distinctly regarding its success validation. This proposal also introduces the concept of a "SUCCESS" flag, which plays a critical role in this nuanced execution method. +Further discussion highlighted the flexibility and strategic advantages offered by existing SUCCESSx codes in facilitating soft forks within the Bitcoin network. These codes are recognized for their foundational role in enabling upgrades without compromising the network’s stability. Andrew Poelstra's suggestion of transitioning one of these opcodes to an "OP_WEAK_SUCCESS" indicates a move towards utilizing these codes not just for network updates but for enhancing operational functionalities. This shift represents a broader perspective on developing the opcode infrastructure to cater to specialized applications while maintaining the integrity of the existing codebase. +The utility of an "OP_SUCCESS" opcode was also elaborated upon, especially in the context of implementing fraud proofs in Bitcoin script. This opcode's functionality, allowing for immediate marking of script execution as successful, presents a significant advantage in scenarios requiring efficient identification of mismatches. Despite the potential for emulating this functionality through script rewriting, the complexity and inefficiency of such an alternative underscore the value of directly implementing "OP_SUCCESS". Tools exist for script rewriting, as indicated by a [GitHub resource](https://github.com/Bitcoin-Wildlife-Sanctuary/fraud-proof-compiler), yet they highlight the convoluted nature of achieving the same outcomes without a dedicated opcode. The conversation thus advocates for simplifying script development processes by incorporating opcodes like "OP_SUCCESS", aiming to enhance both efficiency and developer accessibility within the Bitcoin scripting environment. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Double-Exponential-Hash-Rate-Growth-and-Difficulty-Adjustment.xml b/static/bitcoin-dev/Dec_2024/combined_Double-Exponential-Hash-Rate-Growth-and-Difficulty-Adjustment.xml index ad6b44863f..aed9d7f3ad 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Double-Exponential-Hash-Rate-Growth-and-Difficulty-Adjustment.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Double-Exponential-Hash-Rate-Growth-and-Difficulty-Adjustment.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Double Exponential Hash Rate Growth and Difficulty Adjustment - 2024-12-20T02:25:19.184770+00:00 - - Anders 2024-12-19 20:00:00+00:00 - - - Michael Cassano 2024-12-19 17:25:00+00:00 - - - Anders 2024-12-19 01:19:00+00:00 - + 2025-09-26T14:34:41.851943+00:00 + python-feedgen + + + Double Exponential Hash Rate Growth and Difficulty Adjustment Anders + 2024-12-19T01:19:00.000Z + + + Michael Cassano + 2024-12-19T17:25:00.000Z + + + Anders + 2024-12-19T20:00:00.000Z + + - python-feedgen + 2 Combined summary - Double Exponential Hash Rate Growth and Difficulty Adjustment - 2024-12-20T02:25:19.184815+00:00 + 2025-09-26T14:34:41.852516+00:00 + 2024-12-19T20:00:00+00:00 In an insightful exchange on the Bitcoin Development Mailing List, a significant concern was raised regarding the long-term sustainability of Bitcoin's difficulty adjustment mechanism amid observations of potential double exponential growth in the hash rate. This growth, if it continues, threatens to outpace the current mechanism designed to maintain a steady block time of approximately 10 minutes. The crux of the issue lies in the finite limit of leading zeros that can be accommodated in the target value for a valid block hash, a constraint dictated by the 256-bit (64 hexadecimal digits) structure of the target value. Currently, with around 19-20 leading zeros already in place, the system is left with a margin of roughly 44-45 zeros before reaching its upper limit. The concern is that double exponential growth in hash rate could expedite the arrival at this threshold far sooner than linear projections might suggest, potentially destabilizing block times and by extension, network stability within the next decade. - Several questions were posed to the mailing list community, seeking insights into whether formal analyses exist that corroborate the likelihood of such accelerated growth patterns in Bitcoin's hash rate, alongside inquiries into viable long-term solutions and the trade-offs they present. Among the suggested approaches to mitigate these challenges are the possibilities of adjusting the difficulty more frequently, altering the difficulty adjustment algorithm itself, or even changing the proof-of-work algorithm entirely. - In response to these concerns, a novel solution was proposed to avoid necessitating a hard fork while addressing the impending limitations of the current difficulty adjustment mechanism. The suggestion involves maintaining miners on the SHA256 algorithm but introducing a requirement for a secondary hashing to achieve a new difficulty target. This would entail miners publishing blocks when two conditions are met: first, when the SHA256 hash of the block header equals 1, and second, when the double SHA256 hash of the same header is less than a newly introduced secondary target. This secondary target would dynamically adjust based on the primary target, ensuring blocks are verified through both the initial and secondary difficulty assessments. This approach aims to sustain network stability by adapting the verification process to accommodate growing computational power without the need for significant structural changes to the existing framework. - 2024-12-19T20:00:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml b/static/bitcoin-dev/Dec_2024/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml index 68075756be..20b51336c6 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Mandatory Inclusion of Old Transactions in Blocks - 2025-01-10T02:25:45.035585+00:00 - - Jameson Lopp 2025-01-09 12:24:00+00:00 - - - developer 2024-12-29 16:35:00+00:00 - - - Ethan Heilman 2024-12-28 18:48:00+00:00 - - - Owen Kemeys 2024-12-28 16:23:00+00:00 - - - Luke Dashjr 2024-12-28 16:22:00+00:00 - - - developer 2024-12-28 16:15:00+00:00 - - - developer 2024-12-28 15:54:00+00:00 - + 2025-09-26T14:34:54.710335+00:00 + python-feedgen + + + developer + 2024-12-28T15:54:00.000Z + + + developer + 2024-12-28T16:15:00.000Z + + + Luke Dashjr + 2024-12-28T16:22:00.000Z + + + Owen Kemeys + 2024-12-28T16:23:00.000Z + + + Ethan Heilman + 2024-12-28T18:48:00.000Z + + + developer + 2024-12-29T16:35:00.000Z + + + Jameson Lopp + 2025-01-09T12:24:00.000Z + + @@ -31,19 +41,16 @@ - python-feedgen + 2 Combined summary - Mandatory Inclusion of Old Transactions in Blocks - 2025-01-10T02:25:45.035651+00:00 + 2025-09-26T14:34:54.711256+00:00 - The recent discussions on the Bitcoin Development Mailing List have sparked significant interest in the potential for adjusting the way transactions are processed and confirmed within the Bitcoin network. A major focus of these conversations has been on the utilization of the "nLockTime" feature, which traditionally is set to zero, suggesting its innovative application could enhance the protocol's resilience against control and censorship by indicating a transaction's readiness for immediate block inclusion. This proposal leverages legal and existing functionalities of the Bitcoin protocol, aiming to refine the transaction selection process currently based on fee rates. By introducing a dual sorting mechanism that considers both the transaction fee rate and "nLockTime," the proposal suggests older transactions with lower fees may have a better opportunity to get included in a block, potentially reducing mempool stagnation. - + 2025-01-09T12:24:00+00:00 + The recent discussions on the Bitcoin Development Mailing List have sparked significant interest in the potential for adjusting the way transactions are processed and confirmed within the Bitcoin network. A major focus of these conversations has been on the utilization of the "nLockTime" feature, which traditionally is set to zero, suggesting its innovative application could enhance the protocol's resilience against control and censorship by indicating a transaction's readiness for immediate block inclusion. This proposal leverages legal and existing functionalities of the Bitcoin protocol, aiming to refine the transaction selection process currently based on fee rates. By introducing a dual sorting mechanism that considers both the transaction fee rate and "nLockTime," the proposal suggests older transactions with lower fees may have a better opportunity to get included in a block, potentially reducing mempool stagnation. Further exploration into the technical challenges reveals concerns about achieving consensus on the oldest transactions, a key factor in advancing the proposal's practicality. The conversation acknowledges the complexity of this issue, mirroring the consensus process already inherent in Bitcoin but also highlights the necessity of further innovation before considering it mature enough for a formal Bitcoin Improvement Proposal (BIP). Critics of the proposed system argue it could lead to regular chainsplits due to discrepancies in transaction visibility across nodes, emphasizing the blockchain's reliance on mining to achieve consensus on transaction history. This critique underscores the fundamental challenges in altering the transaction confirmation process and the essential role of mining in maintaining the integrity of the blockchain. - A specific proposal discussed mandates Bitcoin miners to include a minimum percentage of the oldest transactions in their blocks, irrespective of the fee levels, aiming to combat mining centralization and censorship. The specification requires each miner to ensure their blocks contain at least 0.1% of transactions from the oldest in the mempool, promoting a democratic processing approach. This initiative addresses concerns over mining centralization and regulatory pressures that might influence transaction selection. By enforcing the inclusion of older, possibly lower-fee transactions, the proposal seeks to prevent exclusion based on fee size alone, enhancing the fairness and inclusivity of the transaction confirmation process. - The proposal outlines several anticipated benefits, including increased censorship resistance, promotion of decentralization by reducing centralized control over the network, and improvement in the mempool's dynamics by facilitating the confirmation of old and low-fee transactions. However, it also necessitates miners adjusting their resource management practices to identify and include these specified transactions automatically. Ultimately, the proposal advocates for a more equitable Bitcoin network, ensuring all transactions have a fair chance of being confirmed without bias towards higher fees, thereby maintaining the network's integrity and decentralization. - 2025-01-09T12:24:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Proposal-for-Quantum-Resistant-Cryptography-in-Bitcoin-BIP-Submission.xml b/static/bitcoin-dev/Dec_2024/combined_Proposal-for-Quantum-Resistant-Cryptography-in-Bitcoin-BIP-Submission.xml index ee8998e24c..74c983c0d5 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Proposal-for-Quantum-Resistant-Cryptography-in-Bitcoin-BIP-Submission.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Proposal-for-Quantum-Resistant-Cryptography-in-Bitcoin-BIP-Submission.xml @@ -1,33 +1,36 @@ - + 2 Combined summary - Proposal for Quantum-Resistant Cryptography in Bitcoin - BIP Submission - 2024-12-14T02:30:30.367281+00:00 - - Ian Quantum 2024-12-13 02:07:00+00:00 - - - Jon Atack 2024-10-21 15:35:00+00:00 - - - Agustin Cruz 2024-10-17 22:54:00+00:00 - + 2025-09-26T14:34:48.300374+00:00 + python-feedgen + + + Proposal for Quantum-Resistant Cryptography in Bitcoin - BIP Submission Agustin Cruz + 2024-10-17T22:54:00.000Z + + + Jon Atack + 2024-10-21T15:35:00.000Z + + + Ian Quantum + 2024-12-13T02:07:00.000Z + + - python-feedgen + 2 Combined summary - Proposal for Quantum-Resistant Cryptography in Bitcoin - BIP Submission - 2024-12-14T02:30:30.367323+00:00 + 2025-09-26T14:34:48.300866+00:00 + 2024-12-13T02:07:00+00:00 The discourse on enhancing Bitcoin's security framework to counter the threats posed by advancements in quantum computing has been vibrant across various platforms, with significant contributions being made towards developing a Bitcoin Improvement Proposal (BIP) specifically designed to introduce quantum-resistant cryptographic measures into the Bitcoin protocol. This initiative is driven by the recognition of the potential vulnerabilities that quantum computing could exploit within the existing cryptographic foundations of Bitcoin. Central to this proposal is the adoption of post-quantum cryptographic algorithms, notably SPHINCS+ and Dilithium. These algorithms are identified for their capability to fortify Bitcoin against the anticipated quantum computing capabilities, thereby ensuring the digital currency's resilience in the face of such technological progress. - To facilitate the integration of these quantum-resistant algorithms, the BIP draft outlines a series of critical modifications to the Bitcoin protocol. Among these are the introduction of a new Bech32-based address format tailored for quantum-resistant addresses, alongside adjustments to the transaction structures and script opcodes. These modifications are necessitated by the larger signature sizes associated with quantum-resistant cryptographic algorithms. Moreover, the draft proposes a transition mechanism through a soft fork, aiming to preserve backward compatibility with the existing ecosystem of Bitcoin addresses and transactions. This approach underscores a commitment to minimizing disruption while bolstering the security of the network against quantum computing threats. - The open invitation for community review and feedback on the draft hosted at [this GitHub link](https://github.com/chucrut/bips/blob/master/bip-xxxx.md) reflects a collaborative ethos in the development process of this BIP. Agustín Cruz, the proponent of the BIP, emphasizes the value of community input in refining the proposal, signaling an inclusive strategy to enhance Bitcoin's security mechanisms. The provision for community engagement is seen as a critical step in ensuring that the proposed measures are robust, feasible, and reflective of the collective wisdom of the Bitcoin development community. - Parallel discussions highlight concerns regarding current encryption standards like FALCON and the suitability of alternative cryptographic solutions such as NTRU Prime for secure lattice operations in heterogeneous environments. These conversations underscore the ongoing evaluation of cryptographic resilience against potential quantum computing exploits. Moreover, developments in quantum networking and mass production of quantum computing resources, exemplified by initiatives from entities like PSI Quantum, Oxford Ionics, Riverlane, and Intel, further contextualize the urgency and complexity of preparing Bitcoin for a post-quantum computing era. The expected advancements in quantum computing capabilities necessitate a proactive and informed approach to securing the Bitcoin network, as evidenced by the comprehensive efforts to develop and refine the proposed BIP for quantum resistance. - 2024-12-13T02:07:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml b/static/bitcoin-dev/Dec_2024/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml index 1773738942..f336d5d92a 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks - 2025-04-10T02:34:59.225767+00:00 - - Yuval Kogman 2025-04-09 02:16:00+00:00 - - - Javier Mateos 2025-04-07 10:01:00+00:00 - - - Yuval Kogman 2025-04-04 19:59:00+00:00 - - - Yuval Kogman 2025-04-04 17:58:00+00:00 - - - Peter Todd 2025-04-04 16:42:00+00:00 - - - Yuval Kogman 2025-02-13 15:42:00+00:00 - - - /dev /fd 2025-02-12 10:17:00+00:00 - - - Yuval Kogman 2025-02-07 20:07:00+00:00 - - - Peter Todd 2025-02-04 22:22:00+00:00 - - - Yuval Kogman 2025-02-04 14:02:00+00:00 - - - waxwing/ AdamISZ 2025-01-24 16:38:00+00:00 - - - Peter Todd 2025-01-24 16:00:00+00:00 - - - Peter Todd 2025-01-23 16:25:00+00:00 - - - Yuval Kogman 2025-01-07 21:33:00+00:00 - - - waxwing/ AdamISZ 2025-01-07 15:56:00+00:00 - - - Yuval Kogman 2025-01-06 14:30:00+00:00 - - - Sjors Provoost 2025-01-06 13:07:00+00:00 - - - Yuval Kogman 2024-12-21 14:16:00+00:00 - + 2025-09-26T14:34:46.185326+00:00 + python-feedgen + + + Yuval Kogman + 2024-12-21T14:16:00.000Z + + + Sjors Provoost + 2025-01-06T13:07:00.000Z + + + Yuval Kogman + 2025-01-06T14:30:00.000Z + + + waxwing/ AdamISZ + 2025-01-07T15:56:00.000Z + + + Yuval Kogman + 2025-01-07T21:33:00.000Z + + + Peter Todd + 2025-01-23T16:25:00.000Z + + + Peter Todd + 2025-01-24T16:00:00.000Z + + + waxwing/ AdamISZ + 2025-01-24T16:38:00.000Z + + + Yuval Kogman + 2025-02-04T14:02:00.000Z + + + Peter Todd + 2025-02-04T22:22:00.000Z + + + Yuval Kogman + 2025-02-07T20:07:00.000Z + + + /dev /fd0 + 2025-02-12T10:17:00.000Z + + + Yuval Kogman + 2025-02-13T15:42:00.000Z + + + Peter Todd + 2025-04-04T16:42:00.000Z + + + Yuval Kogman + 2025-04-04T17:58:00.000Z + + + Yuval Kogman + 2025-04-04T19:59:00.000Z + + + Javier Mateos + 2025-04-07T10:01:00.000Z + + + Yuval Kogman + 2025-04-09T02:16:00.000Z + + @@ -75,23 +96,18 @@ - python-feedgen + 2 Combined summary - Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks - 2025-04-10T02:34:59.225885+00:00 + 2025-09-26T14:34:46.187636+00:00 + 2025-04-09T02:16:00+00:00 The discourse within the Bitcoin development community highlights several critical insights and concerns surrounding privacy, trust, and transparency in the operation of coinjoin implementations such as Wasabi Wallet and Samourai Wallet. At the core of these discussions is the acknowledgment of inherent vulnerabilities and the complexity of ensuring user anonymity against sophisticated deanonymization techniques. The dialogue surfaces a pivotal tension between the theoretical promise of privacy-enhancing technologies and their practical implementation challenges. - A central theme in the conversation revolves around the limitations and potential weaknesses of coinjoin protocols. Specifically, criticisms target the coordinators' ability to undermine the privacy guarantees through manipulating transaction processes, a risk exacerbated by a lack of transparency and possible rent-seeking behaviors. These concerns are not merely theoretical but are grounded in detailed technical analyses that reveal how malicious actors could exploit protocol design flaws for deanonymization purposes. - For instance, the critique of Whirlpool's vulnerability centers on the process of blind signing keys, which could enable a coordinator to clandestinely link outputs to inputs, thereby breaching the protocol's privacy assurances. Similarly, WabiSabi faces scrutiny over its handling of key consistency, with the protocol's reliance on clients registering Bitcoin UTXOs independently underpinning a methodological flaw. This flaw could allow inconsistent round IDs to be issued to clients, facilitating partitioning attacks that compromise user anonymity. Despite efforts to address these and other issues, such as poor coin selection practices and the misuse of Tor circuits, the fundamental challenge of verifying and controlling the public keys used for proof verification persists. - Moreover, the discussions delve into the economic models embedded within these systems, particularly focusing on coordination fees and anonymous credential mechanisms. While intended to fairly compensate for transaction coordination, these structures have inadvertently fallen short of preventing the misappropriation of user funds, highlighting a significant gap in balancing privacy enhancement with financial security. - The critiques extend beyond specific protocols to encompass broader themes of ethical responsibility, transparency in development practices, and the imperative for rigorous auditing. The need for a comprehensive approach to security, one that includes both cryptographic and non-cryptographic elements of privacy-sensitive code, is emphasized as essential for maintaining user trust and integrity within the Bitcoin ecosystem. - In summary, the discussions reflect a multifaceted debate on the evolution of cryptocurrency protocols, underscoring the ongoing challenge of innovating privacy-enhancing technologies while safeguarding against exploitation. This dynamic interplay between innovation, security, and ethical considerations encapsulates the current state of discourse in the Bitcoin development community, pointing towards a future where these tensions must be continually navigated to advance the field responsibly. - 2025-04-09T02:16:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Summary-Covenants-Support-Bitcoin-Wiki.xml b/static/bitcoin-dev/Dec_2024/combined_Summary-Covenants-Support-Bitcoin-Wiki.xml index 16481016c5..00cbfc83da 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Summary-Covenants-Support-Bitcoin-Wiki.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Summary-Covenants-Support-Bitcoin-Wiki.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - Summary: Covenants Support - Bitcoin Wiki - 2025-01-17T02:15:51.411061+00:00 - - moonsettler 2025-01-16 12:32:00+00:00 - - - /dev /fd 2025-01-14 14:14:00+00:00 - - - /dev /fd 2025-01-03 13:58:00+00:00 - - - moonsettler 2025-01-03 11:59:00+00:00 - - - /dev /fd 2025-01-02 15:16:00+00:00 - - - moonsettler 2025-01-02 13:40:00+00:00 - - - /dev /fd 2025-01-02 01:22:00+00:00 - - - Ethan Heilman 2025-01-01 18:11:00+00:00 - - - /dev /fd 2025-01-01 01:46:00+00:00 - - - moonsettler 2024-12-31 13:17:00+00:00 - - - /dev /fd 2024-12-31 08:23:00+00:00 - + 2025-09-26T14:34:52.561950+00:00 + python-feedgen + + + /dev /fd0 + 2024-12-31T08:23:00.000Z + + + moonsettler + 2024-12-31T13:17:00.000Z + + + /dev /fd0 + 2025-01-01T01:46:00.000Z + + + Ethan Heilman + 2025-01-01T18:11:00.000Z + + + /dev /fd0 + 2025-01-02T01:22:00.000Z + + + moonsettler' + 2025-01-02T13:40:00.000Z + + + /dev /fd0 + 2025-01-02T15:16:00.000Z + + + moonsettler' + 2025-01-03T11:59:00.000Z + + + /dev /fd0 + 2025-01-03T13:58:00.000Z + + + /dev /fd0 + 2025-01-14T14:14:00.000Z + + + moonsettler' + 2025-01-16T12:32:00.000Z + + @@ -47,23 +61,18 @@ - python-feedgen + 2 Combined summary - Summary: Covenants Support - Bitcoin Wiki - 2025-01-17T02:15:51.411143+00:00 + 2025-09-26T14:34:52.563209+00:00 + 2025-01-16T12:32:00+00:00 In the realm of Bitcoin development, a series of discussions and exchanges have unfolded on the Bitcoin Development Mailing List, revealing a vibrant collaborative effort aimed at refining and enhancing the functionality and efficiency of Bitcoin. A focal point of these discussions has been the evaluation and potential implementation of various proposals and opcodes designed to optimize Bitcoin contracts, including Resumeable LN channels, Multi-party LN channels, Vaults, and more. The discourse has highlighted significant improvements these enhancements could bring, emphasizing the importance of thoughtful evaluation and technical merit over popularity. - One notable debate centers around the introduction and comparison of specific opcodes, namely OP_CAT and OP_PAIRCOMMIT, with contributors examining their implications for the Lightning Network (LN) and broader Bitcoin script capabilities. Despite the technical support for OP_PAIRCOMMIT due to its simplicity and added functionality, there's an ongoing conversation about its necessity and the possible complexity it introduces compared to existing solutions. This dialogue underscores a collective pursuit of balancing expressiveness, functionality, and simplicity within the Bitcoin protocol, without compromising its principles or adding unnecessary complexity. - Contributors have also delved into the functionalities of INTERNALKEY and PAIRCOMMIT, clarifying their roles in enabling LN-Symmetry and contributing to efficiency improvements across various contract types. The reduction of signature operations (SigOps) required on-chain stands out as a key benefit, potentially offering economic advantages by streamlining validation processes. Such optimizations are met with both enthusiasm and critique, as participants weigh the trade-offs between innovation and the introduction of new complexities. - The communications reveal a dynamic and nuanced debate among developers regarding the best paths forward for Bitcoin's evolution. Suggestions for achieving consensus include the addition of more detailed rationales, participation in mailing list discussions, and organizing workshops, reflecting a commitment to a collaborative and inclusive decision-making process. This process is not only about advancing technical solutions but also about fostering a community-driven approach where diverse perspectives can contribute to the ecosystem's growth. - Moreover, the discourse extends beyond technical considerations to address the procedural aspects of proposal evaluation and activation client development. The notion that advancements should be guided by technical merit rather than popularity is reiterated, highlighting the importance of thorough analysis and community engagement in shaping Bitcoin's future. - In summary, the conversations captured in the Bitcoin Development Mailing List illustrate a dedicated effort to explore, critique, and refine proposals aimed at enhancing Bitcoin’s functionality. Through a combination of technical discussions, evaluations of new opcodes, and considerations of efficiency and complexity, the Bitcoin developer community continues to navigate the challenges and opportunities presented by the evolving landscape of cryptocurrency technology. - 2025-01-16T12:32:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_TRUC-and-P2A-for-CTV-fee-management.xml b/static/bitcoin-dev/Dec_2024/combined_TRUC-and-P2A-for-CTV-fee-management.xml index fdc1129b69..db81be2fb4 100644 --- a/static/bitcoin-dev/Dec_2024/combined_TRUC-and-P2A-for-CTV-fee-management.xml +++ b/static/bitcoin-dev/Dec_2024/combined_TRUC-and-P2A-for-CTV-fee-management.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - TRUC and P2A for CTV fee management - 2025-01-01T02:30:24.227986+00:00 - - stutxo 2024-12-31 00:57:00+00:00 - - - /dev /fd 2024-12-21 03:07:00+00:00 - - - stutxo 2024-12-18 00:25:00+00:00 - + 2025-09-26T14:35:03.170934+00:00 + python-feedgen + + + TRUC and P2A for CTV fee management 'stutxo' + 2024-12-18T00:25:00.000Z + + + /dev /fd0 + 2024-12-21T03:07:00.000Z + + + stutxo' + 2024-12-31T00:57:00.000Z + + - python-feedgen + 2 Combined summary - TRUC and P2A for CTV fee management - 2025-01-01T02:30:24.228046+00:00 + 2025-09-26T14:35:03.171582+00:00 + 2024-12-31T00:57:00+00:00 The email delves into specific technical aspects of Bitcoin development, particularly focusing on the testing of packages and Pay-to-Address (P2A) functionality with the use of CHECKTEMPLATEVERIFY (CTV) on Signet. It highlights an issue identified in the README documentation concerning an incorrect example that involves an output value discrepancy. This error is exemplified through a transaction, with its details accessible via a provided [Mempool Space](https://mempool.space/signet/tx/86896275fb71d4e3b84d1edeeacb90f7c4ccf77ee3a29e66d7effff4bb0682fb) link for direct review and verification. The communication originates from a member of the Bitcoin Development Google Groups thread, indicating it's part of a broader discourse among professionals engaged in the evolution of cryptocurrency technologies. - -The message further explores the intricacies of OP_CTV ("securethebag"), especially addressing the limitations arising from transaction fees and the inability to dynamically adjust these fees due to the precommitment to a specific tree of outputs and inputs mandated by OP_CTV. This challenge is significant in the context of long-term coin vaulting where the fee market's unpredictability could lead to complications. Discussions around this topic include references to Jamesob's research on a simple CTV vault and Rustyrussell's comments on nostr, which suggest looking into optimized sponsors as a viable solution for adding fees without promoting miner centralization. - +The message further explores the intricacies of OP_CTV ("securethebag"), especially addressing the limitations arising from transaction fees and the inability to dynamically adjust these fees due to the precommitment to a specific tree of outputs and inputs mandated by OP_CTV. This challenge is significant in the context of long-term coin vaulting where the fee market's unpredictability could lead to complications. Discussions around this topic include references to Jamesob's research on a simple CTV vault and Rustyrussell's comments on nostr, which suggest looking into optimized sponsors as a viable solution for adding fees without promoting miner centralization. Moreover, the introduction of v3 transactions in Bitcoin 28.0 heralds new mechanisms for tackling the fee adjustment issue inherent to OP_CTV transactions. The capability to employ Child Pays For Parent (CPFP) on an anchor output, given there is an output for 240 sats paying to a P2A address, represents a strategic response to the constraints posed by OP_CTV. The email outlines practical demonstrations of this technique using Signet for a CTV spend transaction with zero fees followed by a P2A CPFP transaction to facilitate fee adjustments. These examples showcase potential strategies for reducing the sensitivity of OP_CTV transactions to the fee market's fluctuations. However, the discussion also opens up queries about the general utility and possible drawbacks of this approach across various CTV script spends, inviting further investigation and dialogue within the developer community. - 2024-12-31T00:57:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2024/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml b/static/bitcoin-dev/Dec_2024/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml index e123d9d136..3009f06ddb 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Trivial QC signatures with clean upgrade path - 2025-01-02T02:23:08.757612+00:00 - - Ian Quantum 2025-01-02 00:43:00+00:00 - - - David A. Harding 2025-01-01 08:38:00+00:00 - - - David A. Harding 2025-01-01 08:37:00+00:00 - - - Antoine Riard 2024-12-18 03:29:00+00:00 - - - conduition 2024-12-17 05:31:00+00:00 - - - Tadge Dryja 2024-12-16 22:20:00+00:00 - - - Matt Corallo 2024-12-16 15:57:00+00:00 - - - Anthony Towns 2024-12-16 11:14:00+00:00 - - - Matt Corallo 2024-12-16 01:40:00+00:00 - - - Weikeng Chen 2024-12-16 01:30:00+00:00 - - - Luke Dashjr 2024-12-15 23:54:00+00:00 - - - Matt Corallo 2024-12-15 21:42:00+00:00 - + 2025-09-26T14:34:44.000498+00:00 + python-feedgen + + + Trivial QC signatures with clean upgrade path Matt Corallo + 2024-12-15T21:42:00.000Z + + + Luke Dashjr + 2024-12-15T23:54:00.000Z + + + Weikeng Chen + 2024-12-16T01:30:00.000Z + + + Matt Corallo + 2024-12-16T01:40:00.000Z + + + Anthony Towns + 2024-12-16T11:14:00.000Z + + + Matt Corallo + 2024-12-16T15:57:00.000Z + + + Tadge Dryja + 2024-12-16T22:20:00.000Z + + + conduition' + 2024-12-17T05:31:00.000Z + + + Antoine Riard + 2024-12-18T03:29:00.000Z + + + David A. Harding + 2025-01-01T08:37:00.000Z + + + David A. Harding + 2025-01-01T08:38:00.000Z + + + Ian Quantum + 2025-01-02T00:43:00.000Z + + @@ -51,21 +66,17 @@ - python-feedgen + 2 Combined summary - Trivial QC signatures with clean upgrade path - 2025-01-02T02:23:08.757701+00:00 + 2025-09-26T14:34:44.002218+00:00 + 2025-01-02T00:43:00+00:00 The ongoing discussions among Bitcoin developers about enhancing the network's security against potential quantum computing threats have shed light on various innovative proposals and considerations. One focal point is the challenge posed by post-quantum cryptography (PQC) and its integration into the Bitcoin protocol to safeguard against quantum attacks that could compromise cryptographic standards currently in place. The discourse has evolved around several key ideas aimed at preempting these threats, highlighting the community's proactive stance towards ensuring the long-term resilience of Bitcoin. - A significant portion of the conversation revolves around the adoption of quantum-resistant cryptographic algorithms before the actualization of quantum computing capabilities that could threaten Bitcoin's security. Proposals such as integrating Winternitz one-time signature algorithms (WOTS) into wallets for a more flexible transition to PQC have been discussed. This approach allows for certification of public keys from future signature algorithms, providing a buffer period for research and development in the field. Moreover, there's an acknowledgment of the speculative nature of current quantum computing projections, emphasizing the need for adaptable solutions that can evolve with our understanding of quantum technology. - Another critical aspect discussed is the implementation of fallback mechanisms within Bitcoin's infrastructure to mitigate risks associated with quantum computing advancements. These include creating consensus-level proofs of quantum computer existence to trigger protective forks and developing output types immune to quantum decryption efforts. Such measures aim to provide a secure transition pathway that doesn't disrupt the underlying principles of blockchain technology while maintaining the integrity and continuity of the network amidst evolving threats. - Moreover, the dialogue touches upon the complexities involved in adjusting Bitcoin's foundational structures to accommodate post-quantum secure protocols. Suggestions for modifying public keys to incorporate post-quantum elements and the potential for new script opcodes offer insights into the technical hurdles and strategic decisions facing developers. Despite these challenges, the emphasis remains on finding balanced solutions that preemptively safeguard the network without necessitating immediate, drastic changes. - Throughout these exchanges, the importance of continuing innovation and adaptation in cryptocurrency security is evident. By exploring various cryptographic and strategic solutions, the Bitcoin development community demonstrates a commitment to securing the network against emerging technologies. The discussions underscore a collective effort to anticipate future threats and ensure the longevity of Bitcoin through careful planning, research, and consensus-building. - 2025-01-02T00:43:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_-OP-EVICT-An-Alternative-to-OP-TAPLEAFUPDATEVERIFY-.xml b/static/bitcoin-dev/Feb_2022/combined_-OP-EVICT-An-Alternative-to-OP-TAPLEAFUPDATEVERIFY-.xml index aa4f87de1e..408e46dd3b 100644 --- a/static/bitcoin-dev/Feb_2022/combined_-OP-EVICT-An-Alternative-to-OP-TAPLEAFUPDATEVERIFY-.xml +++ b/static/bitcoin-dev/Feb_2022/combined_-OP-EVICT-An-Alternative-to-OP-TAPLEAFUPDATEVERIFY-.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY` - 2023-08-02T05:42:21.822854+00:00 - - ZmnSCPxj 2022-02-23 11:42:54+00:00 - - - Antoine Riard 2022-02-22 00:17:52+00:00 - - - Billy Tetrud 2022-02-19 21:59:41+00:00 - - - ZmnSCPxj 2022-02-19 11:41:42+00:00 - - - Billy Tetrud 2022-02-19 07:21:56+00:00 - - - Greg Sanders 2022-02-19 01:46:07+00:00 - - - ZmnSCPxj 2022-02-19 01:17:20+00:00 - - - Jeremy Rubin 2022-02-19 00:56:05+00:00 - - - ZmnSCPxj 2022-02-18 23:39:49+00:00 - - - Antoine Riard 2022-02-18 18:09:07+00:00 - - - ZmnSCPxj 2022-02-18 16:06:39+00:00 - - - Erik Aronesty 2022-02-18 15:50:02+00:00 - - - ZmnSCPxj 2022-02-18 14:48:38+00:00 - - - Jonas Nick 2022-02-18 13:55:31+00:00 - - - Erik Aronesty 2022-02-18 13:53:09+00:00 - - - ZmnSCPxj 2022-02-18 02:45:23+00:00 - + 2025-09-26T14:41:20.069900+00:00 + python-feedgen + + + OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY` ZmnSCPxj + 2022-02-18T02:45:00.000Z + + + Erik Aronesty + 2022-02-18T13:53:00.000Z + + + Jonas Nick + 2022-02-18T13:55:00.000Z + + + ZmnSCPxj + 2022-02-18T14:48:00.000Z + + + Erik Aronesty + 2022-02-18T15:50:00.000Z + + + ZmnSCPxj + 2022-02-18T16:06:00.000Z + + + Antoine Riard + 2022-02-18T18:09:00.000Z + + + ZmnSCPxj + 2022-02-18T23:39:00.000Z + + + Jeremy Rubin + 2022-02-19T00:56:00.000Z + + + ZmnSCPxj + 2022-02-19T01:17:00.000Z + + + Greg Sanders + 2022-02-19T01:46:00.000Z + + + Billy Tetrud + 2022-02-19T07:21:00.000Z + + + ZmnSCPxj + 2022-02-19T11:41:00.000Z + + + Billy Tetrud + 2022-02-19T21:59:00.000Z + + + Antoine Riard + 2022-02-22T00:17:00.000Z + + + ZmnSCPxj + 2022-02-23T11:42:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY` - 2023-08-02T05:42:21.822854+00:00 + 2025-09-26T14:41:20.071650+00:00 - In a recent email conversation between Antoine and ZmnSCPxj, they discuss the differences between `OP_TLUV` and `OP_EVICT` in terms of their assumptions about cooperation among construction participants once the Taproot tree is set up. While `OP_TLUV` leaves the transaction output with the remaining Tapleaves intact, `OP_EVICT` assumes cooperation among the remaining construction participants to satisfy the final CHECKSIG. In order to revive the construct with `OP_TLUV`, a separate transaction that spends the change output is required, whereas `OP_EVICT` does another CHECKSIG without requiring a separate transaction.The discussion then moves onto the topic of withdrawing funds unilaterally without affecting the stability of the off-chain pool and without cooperation with other users, which is currently a restriction of channel factories fault-tolerance. The blockchain is the only entity that can reliably enforce timeouts, hence, if a channel has an HTLC/PTLC time out, it may be necessary to evict the participant who is not behaving properly, and that is what `OP_EVICT` does. ZmnSCPxj came up with the idea of `OP_EVICT` after musing on this topic.The conversation between Antoine Riard and ZmnSCPxj discusses the implementation of a CoinPool hosted inside a Decker-Wattenhofer or Decker-Russell-Osuntokun construction, with a focus on the eviction mechanism. TLUV is discussed as a possible way to create an "N-of-N With Eviction" construction, which enables the remaining participants to evict offline participants and continue operating in their absence. However, TLUV enforces a constraint in the spends path ordering. In contrast, OP_EVICT removes the constraint in the spends paths ordering and also allows for multiple evictions and the revival of the CoinPool in a single transaction. The disadvantage of OP_EVICT is that it requires point operations.The conversation also explores the possibility of preventing eviction abuse where one counterparty threatens to evict everyone as all the output signatures are known among participants and free to sum. The conclusion is that on-chain fees are currently the only mechanism to avoid such abuse. Finally, the advantage of TLUV over CTV is discussed in terms of revivable constructs with eviction of participants.ZmnSCPxj clarified that the Decker-Russell-Osunstokun paper does not prevent imposing a penalty for cheating attempts in fully punitive channels. He suggested that participants could still retain per-participant versions of update+state transactions and deduct the fee from their main owned funds, similar to the per-participant commitment transactions of Poon-Dryja. The paper just focuses on the mechanism without regard to fees, assuming that the reader already knows they exist and need to be paid.Bitcoin developers are discussing the tradeoffs of punitive channels and their impact on large value channels. While fully punitive channels can encourage correct behavior, they can also make such channels more dangerous from the perspective of bugs causing old states to be published. Non-punitive channels like Eltoo may not be suitable for high-value channels as they do not provide enough punishment to deter cheating attempts.The discussion also covers evictions, revivals, CTV, TLUV, and OP_EVICT, a redesigned version of OP_TLUV that allows participants to evict an offline participant and continue operating with a smaller N-of-N group.In a Bitcoin-dev email thread, the topic of statechains and commitment schemes for multi-party constructions was discussed. The use of LN-Penalty in the context of a multi-party construction remains an unsolved issue. However, safe constructions for N>2 include Decker-Wattenhofer and Decker-Russell-Osuntokun (eltoo). The conversation also delved into the use of Taproot Leaf Versioning (TLV) and its ability to create an "N-of-N With Eviction" construction. However, TLUV imposes an arbitrary ordering due to tapleaf revelation. In contrast, OP_EVICT does not require any ordering during commitment. It allows participants to evict an offline participant, creating a smaller N-of-N where all participants are online, and continue operating. OP_EVICT requires participant cooperation after the state update to allow a single participant to withdraw their funds unilaterally.To prevent signature replay, each update of an updateable scheme like CoinPool should use a different pubkey for each participant for each state. Additionally, non-punitive channels may not be suitable for high-value channels in a congested blockspace world, as punishments incentivize correct behavior. Thus, both fully punitive and non-punitive channels will likely exist for N==2.In a discussion between Erik and ZmnSCPxj, counterproposals for evicting participants in a channel were explored. One counterproposal suggested publishing one transaction per evicted participant, but concerns were raised about the potential combinatorial explosion and 2022-02-23T11:42:54+00:00 + In a recent email conversation between Antoine and ZmnSCPxj, they discuss the differences between `OP_TLUV` and `OP_EVICT` in terms of their assumptions about cooperation among construction participants once the Taproot tree is set up. While `OP_TLUV` leaves the transaction output with the remaining Tapleaves intact, `OP_EVICT` assumes cooperation among the remaining construction participants to satisfy the final CHECKSIG. In order to revive the construct with `OP_TLUV`, a separate transaction that spends the change output is required, whereas `OP_EVICT` does another CHECKSIG without requiring a separate transaction.The discussion then moves onto the topic of withdrawing funds unilaterally without affecting the stability of the off-chain pool and without cooperation with other users, which is currently a restriction of channel factories fault-tolerance. The blockchain is the only entity that can reliably enforce timeouts, hence, if a channel has an HTLC/PTLC time out, it may be necessary to evict the participant who is not behaving properly, and that is what `OP_EVICT` does. ZmnSCPxj came up with the idea of `OP_EVICT` after musing on this topic.The conversation between Antoine Riard and ZmnSCPxj discusses the implementation of a CoinPool hosted inside a Decker-Wattenhofer or Decker-Russell-Osuntokun construction, with a focus on the eviction mechanism. TLUV is discussed as a possible way to create an "N-of-N With Eviction" construction, which enables the remaining participants to evict offline participants and continue operating in their absence. However, TLUV enforces a constraint in the spends path ordering. In contrast, OP_EVICT removes the constraint in the spends paths ordering and also allows for multiple evictions and the revival of the CoinPool in a single transaction. The disadvantage of OP_EVICT is that it requires point operations.The conversation also explores the possibility of preventing eviction abuse where one counterparty threatens to evict everyone as all the output signatures are known among participants and free to sum. The conclusion is that on-chain fees are currently the only mechanism to avoid such abuse. Finally, the advantage of TLUV over CTV is discussed in terms of revivable constructs with eviction of participants.ZmnSCPxj clarified that the Decker-Russell-Osunstokun paper does not prevent imposing a penalty for cheating attempts in fully punitive channels. He suggested that participants could still retain per-participant versions of update+state transactions and deduct the fee from their main owned funds, similar to the per-participant commitment transactions of Poon-Dryja. The paper just focuses on the mechanism without regard to fees, assuming that the reader already knows they exist and need to be paid.Bitcoin developers are discussing the tradeoffs of punitive channels and their impact on large value channels. While fully punitive channels can encourage correct behavior, they can also make such channels more dangerous from the perspective of bugs causing old states to be published. Non-punitive channels like Eltoo may not be suitable for high-value channels as they do not provide enough punishment to deter cheating attempts.The discussion also covers evictions, revivals, CTV, TLUV, and OP_EVICT, a redesigned version of OP_TLUV that allows participants to evict an offline participant and continue operating with a smaller N-of-N group.In a Bitcoin-dev email thread, the topic of statechains and commitment schemes for multi-party constructions was discussed. The use of LN-Penalty in the context of a multi-party construction remains an unsolved issue. However, safe constructions for N>2 include Decker-Wattenhofer and Decker-Russell-Osuntokun (eltoo). The conversation also delved into the use of Taproot Leaf Versioning (TLV) and its ability to create an "N-of-N With Eviction" construction. However, TLUV imposes an arbitrary ordering due to tapleaf revelation. In contrast, OP_EVICT does not require any ordering during commitment. It allows participants to evict an offline participant, creating a smaller N-of-N where all participants are online, and continue operating. OP_EVICT requires participant cooperation after the state update to allow a single participant to withdraw their funds unilaterally.To prevent signature replay, each update of an updateable scheme like CoinPool should use a different pubkey for each participant for each state. Additionally, non-punitive channels may not be suitable for high-value channels in a congested blockspace world, as punishments incentivize correct behavior. Thus, both fully punitive and non-punitive channels will likely exist for N==2.In a discussion between Erik and ZmnSCPxj, counterproposals for evicting participants in a channel were explored. One counterproposal suggested publishing one transaction per evicted participant, but concerns were raised about the potential combinatorial explosion and - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT.xml b/static/bitcoin-dev/Feb_2022/combined_-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT.xml index f23a8c6271..3c8a385b10 100644 --- a/static/bitcoin-dev/Feb_2022/combined_-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT.xml +++ b/static/bitcoin-dev/Feb_2022/combined_-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT - 2023-08-02T05:45:08.383421+00:00 - - Billy Tetrud 2022-03-07 17:26:13+00:00 - - - ZmnSCPxj 2022-03-06 20:38:17+00:00 - - - Billy Tetrud 2022-03-06 15:49:56+00:00 - - - ZmnSCPxj 2022-03-05 23:02:41+00:00 - - - Billy Tetrud 2022-03-05 19:12:03+00:00 - - - ZmnSCPxj 2022-02-27 16:34:31+00:00 - + 2025-09-26T14:40:58.809410+00:00 + python-feedgen + + + OP_FOLD`: A Looping Construct For Bitcoin SCRIPT ZmnSCPxj + 2022-02-27T16:34:00.000Z + + + Billy Tetrud + 2022-03-05T19:12:00.000Z + + + ZmnSCPxj + 2022-03-05T23:02:00.000Z + + + Billy Tetrud + 2022-03-06T15:49:00.000Z + + + ZmnSCPxj + 2022-03-06T20:38:00.000Z + + + Billy Tetrud + 2022-03-07T17:26:00.000Z + + - python-feedgen + 2 Combined summary - `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT - 2023-08-02T05:45:08.383421+00:00 + 2025-09-26T14:40:58.810290+00:00 - In the context of implementing a jet-like system in Bitcoin, the author presents three possibilities: implementing jets without requiring all nodes to upgrade, implementing lighter weighting by using a soft fork to hide jets from unupgraded nodes, and implementing jet registration in a soft fork. Upgraded nodes would query connections for support of jets and send transactions verbatim with the jet included in the script to upgraded nodes that support it. For non-upgraded nodes, the jet opcode call would be replaced with some data that contains the original jet opcode to be swapped back in when the transaction data reaches an upgraded node.The discussion highlights the need for security when releasing a new jet, as users of a new jet have no security if nobody else has upgraded. To incentivize end-users to use a jet, scripts must weigh less when using a jet. Full nodes could recognize jettable code and insert them automatically on transport, but this may result in a large lookup table once there are many jets. The proposal is to allow anyone to add a new jet, requiring a consensus change to implement a mechanism that allows any jet to be registered in userspace.While implementing jets in Bitcoin can optimize scripts, save bytes in transmission, and reduce processing power, changes in costs may occur. Adding jets would require debate and review to be added to Bitcoin core or other Bitcoin software. Implementing more general opcodes is useful, but their boundaries should be well understood before being added. The most general opcodes that can be fully reasoned about and come to a consensus on should be implemented. However, the implementation of `OP_FOLD` is possible without increasing the attack surface.The article discusses the usefulness of op_fold in Bitcoin and how it can provide bandwidth savings by programming as compression. Jets cover the majority of use cases that op_fold would otherwise have. The suggestion is to provide more general operations and identify the most important needs to be implemented on the blockchain layer. The more general an opcode is, the harder it is to understand the boundaries, so implementing the most general opcodes that can be fully reasoned about and come to a consensus on is recommended. Op_fold can still be useful with the proposed restrictions without increasing the attack surface.The Bitcoin Taproot update proposes the implementation of an `OP_FOLD` opcode, providing a looping mechanism for processing elements in an input structure and accumulating results. Restrictions are in place to prevent potential Denial of Service attacks through SCRIPT. Alternative suggestions include adding a field to limit the number of opcodes processed, allowing for multiple loops and loops-in-loops. While `OP_FOLD` improves bandwidth consumption without significantly increasing CPU consumption, trade-offs must be made in the Bitcoin SCRIPT design between general opcodes and complex opcodes.Bitcoin SCRIPT is a programming language used to implement OP_EVICT and general operations. The addition of an `OP_FOLD` operation should be safe as long as further operations admitting partiality are not added. Restricting the use of `OP_FOLD` ensures that its processing does not exceed that of a script without it. The article also discusses the possibility of adding an annex field to Taproot to indicate the maximum number of opcodes to be processed, allowing for lifting restrictions on `OP_FOLD` and multiple loops. The choice between providing more general operations or operations that do more depends on optimizing for specific uses in Bitcoin SCRIPT design. 2022-03-07T17:26:13+00:00 + In the context of implementing a jet-like system in Bitcoin, the author presents three possibilities: implementing jets without requiring all nodes to upgrade, implementing lighter weighting by using a soft fork to hide jets from unupgraded nodes, and implementing jet registration in a soft fork. Upgraded nodes would query connections for support of jets and send transactions verbatim with the jet included in the script to upgraded nodes that support it. For non-upgraded nodes, the jet opcode call would be replaced with some data that contains the original jet opcode to be swapped back in when the transaction data reaches an upgraded node.The discussion highlights the need for security when releasing a new jet, as users of a new jet have no security if nobody else has upgraded. To incentivize end-users to use a jet, scripts must weigh less when using a jet. Full nodes could recognize jettable code and insert them automatically on transport, but this may result in a large lookup table once there are many jets. The proposal is to allow anyone to add a new jet, requiring a consensus change to implement a mechanism that allows any jet to be registered in userspace.While implementing jets in Bitcoin can optimize scripts, save bytes in transmission, and reduce processing power, changes in costs may occur. Adding jets would require debate and review to be added to Bitcoin core or other Bitcoin software. Implementing more general opcodes is useful, but their boundaries should be well understood before being added. The most general opcodes that can be fully reasoned about and come to a consensus on should be implemented. However, the implementation of `OP_FOLD` is possible without increasing the attack surface.The article discusses the usefulness of op_fold in Bitcoin and how it can provide bandwidth savings by programming as compression. Jets cover the majority of use cases that op_fold would otherwise have. The suggestion is to provide more general operations and identify the most important needs to be implemented on the blockchain layer. The more general an opcode is, the harder it is to understand the boundaries, so implementing the most general opcodes that can be fully reasoned about and come to a consensus on is recommended. Op_fold can still be useful with the proposed restrictions without increasing the attack surface.The Bitcoin Taproot update proposes the implementation of an `OP_FOLD` opcode, providing a looping mechanism for processing elements in an input structure and accumulating results. Restrictions are in place to prevent potential Denial of Service attacks through SCRIPT. Alternative suggestions include adding a field to limit the number of opcodes processed, allowing for multiple loops and loops-in-loops. While `OP_FOLD` improves bandwidth consumption without significantly increasing CPU consumption, trade-offs must be made in the Bitcoin SCRIPT design between general opcodes and complex opcodes.Bitcoin SCRIPT is a programming language used to implement OP_EVICT and general operations. The addition of an `OP_FOLD` operation should be safe as long as further operations admitting partiality are not added. Restricting the use of `OP_FOLD` ensures that its processing does not exceed that of a script without it. The article also discusses the possibility of adding an annex field to Taproot to indicate the maximum number of opcodes to be processed, allowing for lifting restrictions on `OP_FOLD` and multiple loops. The choice between providing more general operations or operations that do more depends on optimizing for specific uses in Bitcoin SCRIPT design. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_-Pre-BIP-Fee-Accounts.xml b/static/bitcoin-dev/Feb_2022/combined_-Pre-BIP-Fee-Accounts.xml index 32397a76b2..b411dd0538 100644 --- a/static/bitcoin-dev/Feb_2022/combined_-Pre-BIP-Fee-Accounts.xml +++ b/static/bitcoin-dev/Feb_2022/combined_-Pre-BIP-Fee-Accounts.xml @@ -1,98 +1,187 @@ - + 2 Combined summary - [Pre-BIP] Fee Accounts - 2023-08-02T05:17:55.394761+00:00 - - Jeremy Rubin 2022-05-02 15:59:49+00:00 - - - Peter Todd 2022-04-28 12:15:02+00:00 - - - Jeremy Rubin 2022-04-17 20:57:28+00:00 - - - Peter Todd 2022-04-15 14:52:47+00:00 - - - Jeremy Rubin 2022-04-11 13:18:10+00:00 - - - Peter Todd 2022-04-10 19:32:52+00:00 - - - Jeremy Rubin 2022-02-20 16:45:35+00:00 - - - ZmnSCPxj 2022-02-20 16:34:35+00:00 - - - Jeremy Rubin 2022-02-20 16:29:35+00:00 - - - Jeremy Rubin 2022-02-20 16:29:00+00:00 - - - ZmnSCPxj 2022-02-20 14:24:22+00:00 - - - ZmnSCPxj 2022-02-20 02:39:50+00:00 - - - ZmnSCPxj 2022-02-20 02:24:37+00:00 - - - Peter Todd 2022-02-19 20:35:20+00:00 - - - darosior 2022-02-19 17:20:19+00:00 - - - Peter Todd 2022-02-19 09:39:22+00:00 - - - Jeremy Rubin 2022-02-19 00:38:27+00:00 - - - Peter Todd 2022-02-18 23:50:07+00:00 - - - Jeremy Rubin 2022-02-10 08:08:59+00:00 - - - Peter Todd 2022-02-10 06:58:56+00:00 - - - Billy Tetrud 2022-01-20 05:23:12+00:00 - - - Jeremy 2022-01-19 20:08:23+00:00 - - - Billy Tetrud 2022-01-19 16:51:48+00:00 - - - Jeremy 2022-01-19 07:32:36+00:00 - - - Billy Tetrud 2022-01-19 04:53:21+00:00 - - - Jeremy 2022-01-19 02:51:42+00:00 - - - Billy Tetrud 2022-01-19 02:37:39+00:00 - - - Jeremy 2022-01-18 17:43:07+00:00 - - - Billy Tetrud 2022-01-18 16:12:36+00:00 - - - Jeremy 2022-01-01 20:04:00+00:00 - + 2025-09-26T14:41:28.789315+00:00 + python-feedgen + + + [bitcoin-dev] [Pre-BIP] Fee Accounts Jeremy + 2022-01-01T20:04:00.000Z + + + Billy Tetrud + 2022-01-18T16:12:00.000Z + + + Jeremy + 2022-01-18T17:43:00.000Z + + + Billy Tetrud + 2022-01-19T02:37:00.000Z + + + Jeremy + 2022-01-19T02:51:00.000Z + + + Billy Tetrud + 2022-01-19T04:53:00.000Z + + + Jeremy + 2022-01-19T07:32:00.000Z + + + Billy Tetrud + 2022-01-19T16:51:00.000Z + + + Jeremy + 2022-01-19T20:08:00.000Z + + + Billy Tetrud + 2022-01-20T05:23:00.000Z + + + Peter Todd + 2022-02-10T06:58:00.000Z + + + Jeremy Rubin + 2022-02-10T08:08:00.000Z + + + Peter Todd + 2022-02-18T23:50:00.000Z + + + Jeremy Rubin + 2022-02-19T00:38:00.000Z + + + Peter Todd + 2022-02-19T09:39:00.000Z + + + [bitcoin-dev] [Lightning-dev] " darosior + 2022-02-19T17:20:00.000Z + + + Peter Todd + 2022-02-19T20:35:00.000Z + + + ZmnSCPxj + 2022-02-20T02:24:00.000Z + + + ZmnSCPxj + 2022-02-20T02:39:00.000Z + + + ZmnSCPxj + 2022-02-20T14:24:00.000Z + + + Jeremy Rubin + 2022-02-20T16:29:00.000Z + + + [bitcoin-dev] " Jeremy Rubin + 2022-02-20T16:29:00.000Z + + + ZmnSCPxj + 2022-02-20T16:34:00.000Z + + + Jeremy Rubin + 2022-02-20T16:45:00.000Z + + + Peter Todd + 2022-04-10T19:32:00.000Z + + + Jeremy Rubin + 2022-04-11T13:18:00.000Z + + + Peter Todd + 2022-04-15T14:52:00.000Z + + + Jeremy Rubin + 2022-04-17T20:57:00.000Z + + + Peter Todd + 2022-04-28T12:15:00.000Z + + + Jeremy Rubin + 2022-05-02T15:59:00.000Z + + + [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions Peter Todd + 2022-06-14T11:12:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T11:39:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T11:53:00.000Z + + + rot13maxi + 2022-06-14T12:28:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T12:45:00.000Z + + + Bryan Bishop + 2022-06-14T13:55:00.000Z + + + digital vagabond + 2022-06-14T15:06:00.000Z + + + Peter Todd + 2022-06-14T15:22:00.000Z + + + Peter Todd + 2022-06-14T15:34:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T17:15:00.000Z + + + Andrew Poelstra + 2022-06-14T20:33:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-15T01:16:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-15T01:21:00.000Z + + + Peter Todd + 2022-06-19T11:04:00.000Z + + @@ -123,13 +212,13 @@ - python-feedgen + 2 Combined summary - [Pre-BIP] Fee Accounts - 2023-08-02T05:17:55.395761+00:00 + 2025-09-26T14:41:28.793594+00:00 - In a detailed email conversation, the participants discuss various aspects of blockchain technology, specifically focusing on Open Time Stamps (OTS). The discussion begins with a proposal for a correct timestamping service model, stating that any such service must adhere to the model to be reliable. The writer highlights the potential issues and unreliability that can arise if the model is not followed.Jeremy Rubin questions the appeal to authority in the Bitcoin-dev group and raises concerns about the formal correctness of OTS. He suggests the need for an actual specification for OTS to resolve these issues. The conversation then delves into the technical details of OTS, including its proof format and how it relates to transactions and Bitcoin blocks. The participants also discuss the concept of linearization and its relevance in a use-case scenario. They debate the advantages and disadvantages of different transaction models and fee accounts implementation, emphasizing the importance of flexibility and avoiding unnecessary costs.Additionally, the conversation touches upon the topic of necromancy attacks, where an earlier version of a transaction is resurrected by a third party for OTS. The potential benefits and drawbacks of such attacks are discussed, along with suggestions for mitigating their impact. The discussion expands to include the design of fee accounts and the need for explicit tagging or opt-in features. Different viewpoints are presented, highlighting the potential limitations and advantages of each approach.Another topic addressed is the use of Child Pays for Parent (CPFP) to solve issues related to relative locktimes in Bitcoin Vaults. The participants discuss the recommended design for Vaults and the need for additional features like RBF-able addable input/output or sponsors.The conversation concludes with discussions on the definition of pinning attacks, progress in committing data, and the potential risks associated with certain approaches in blockchain schemes. Overall, the email conversation covers a wide range of topics related to blockchain technology, providing insights into the challenges and considerations involved in implementing and improving timestamping services.Bitcoin developer Jeremy Rubin has proposed a new design to improve the fee-paying semantics in Bitcoin. The current system of paying fees in-band presents challenges for smart contracts and features such as fee bumping and DoS-resistant payment channels. Rubin's proposal suggests two approaches: using a special transaction called a "sponsor" to allow arbitrary fee appending, or implementing an account system as an extension block.The account system proposal involves defining a "fee account" output type that would have separate UTXO databases for deposits and withdrawals. Fee accounts would only be able to sign two types of transactions: one specifying a fee amount and a TXID, and another specifying a withdrawal amount, a fee, and an address. These transactions would be committed in an extension block merkle tree.Rubin argues that the proposed account system would make it easier to write smart contracts by separating the logic from the fees. The mempool logic would be updated to allow attaching fee account spends to transactions, with restrictions on accounts not being allowed to spend more than their balance. The design is considered scalable because adding fees to a transaction does not require adding inputs or outputs or tracking substantial amounts of new state.The proposal could also be modified to enhance privacy by implementing techniques like Tornado.cash or a trustless mixing protocol. Rubin suggests that a federated network could be used to bribe miners until a consensus upgrade is deployed, but acknowledges that this approach may introduce centralization.Overall, Rubin's proposal aims to address the limitations of the current fee-paying system in Bitcoin and provide more flexibility and scalability while considering privacy concerns. 2022-05-02T15:59:49+00:00 + In a detailed email conversation, the participants discuss various aspects of blockchain technology, specifically focusing on Open Time Stamps (OTS). The discussion begins with a proposal for a correct timestamping service model, stating that any such service must adhere to the model to be reliable. The writer highlights the potential issues and unreliability that can arise if the model is not followed.Jeremy Rubin questions the appeal to authority in the Bitcoin-dev group and raises concerns about the formal correctness of OTS. He suggests the need for an actual specification for OTS to resolve these issues. The conversation then delves into the technical details of OTS, including its proof format and how it relates to transactions and Bitcoin blocks. The participants also discuss the concept of linearization and its relevance in a use-case scenario. They debate the advantages and disadvantages of different transaction models and fee accounts implementation, emphasizing the importance of flexibility and avoiding unnecessary costs.Additionally, the conversation touches upon the topic of necromancy attacks, where an earlier version of a transaction is resurrected by a third party for OTS. The potential benefits and drawbacks of such attacks are discussed, along with suggestions for mitigating their impact. The discussion expands to include the design of fee accounts and the need for explicit tagging or opt-in features. Different viewpoints are presented, highlighting the potential limitations and advantages of each approach.Another topic addressed is the use of Child Pays for Parent (CPFP) to solve issues related to relative locktimes in Bitcoin Vaults. The participants discuss the recommended design for Vaults and the need for additional features like RBF-able addable input/output or sponsors.The conversation concludes with discussions on the definition of pinning attacks, progress in committing data, and the potential risks associated with certain approaches in blockchain schemes. Overall, the email conversation covers a wide range of topics related to blockchain technology, providing insights into the challenges and considerations involved in implementing and improving timestamping services.Bitcoin developer Jeremy Rubin has proposed a new design to improve the fee-paying semantics in Bitcoin. The current system of paying fees in-band presents challenges for smart contracts and features such as fee bumping and DoS-resistant payment channels. Rubin's proposal suggests two approaches: using a special transaction called a "sponsor" to allow arbitrary fee appending, or implementing an account system as an extension block.The account system proposal involves defining a "fee account" output type that would have separate UTXO databases for deposits and withdrawals. Fee accounts would only be able to sign two types of transactions: one specifying a fee amount and a TXID, and another specifying a withdrawal amount, a fee, and an address. These transactions would be committed in an extension block merkle tree.Rubin argues that the proposed account system would make it easier to write smart contracts by separating the logic from the fees. The mempool logic would be updated to allow attaching fee account spends to transactions, with restrictions on accounts not being allowed to spend more than their balance. The design is considered scalable because adding fees to a transaction does not require adding inputs or outputs or tracking substantial amounts of new state.The proposal could also be modified to enhance privacy by implementing techniques like Tornado.cash or a trustless mixing protocol. Rubin suggests that a federated network could be used to bribe miners until a consensus upgrade is deployed, but acknowledges that this approach may introduce centralization.Overall, Rubin's proposal aims to address the limitations of the current fee-paying system in Bitcoin and provide more flexibility and scalability while considering privacy concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_A-Comparison-Of-LN-and-Drivechain-Security-In-The-Presence-Of-51-Attackers.xml b/static/bitcoin-dev/Feb_2022/combined_A-Comparison-Of-LN-and-Drivechain-Security-In-The-Presence-Of-51-Attackers.xml index 0e8e96c6c9..f809167a33 100644 --- a/static/bitcoin-dev/Feb_2022/combined_A-Comparison-Of-LN-and-Drivechain-Security-In-The-Presence-Of-51-Attackers.xml +++ b/static/bitcoin-dev/Feb_2022/combined_A-Comparison-Of-LN-and-Drivechain-Security-In-The-Presence-Of-51-Attackers.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers - 2023-08-02T05:44:45.898087+00:00 - - Paul Sztorc 2022-02-27 00:42:22+00:00 - - - Billy Tetrud 2022-02-26 14:58:12+00:00 - - - ZmnSCPxj 2022-02-26 07:39:36+00:00 - - - Paul Sztorc 2022-02-24 21:39:40+00:00 - - - ZmnSCPxj 2022-02-24 12:49:00+00:00 - + 2025-09-26T14:40:54.518585+00:00 + python-feedgen + + + [bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers ZmnSCPxj + 2022-02-24T12:49:00.000Z + + + Paul Sztorc + 2022-02-24T21:39:00.000Z + + + ZmnSCPxj + 2022-02-26T07:39:00.000Z + + + Billy Tetrud + 2022-02-26T14:58:00.000Z + + + Paul Sztorc + 2022-02-27T00:42:00.000Z + + - python-feedgen + 2 Combined summary - A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers - 2023-08-02T05:44:45.898087+00:00 + 2025-09-26T14:40:54.519377+00:00 - In a recent email conversation between Paul and ZmnSCPxj, a quiz was presented to test one's understanding of Drivechain. The quiz included questions about the security model, withdrawal system, and potential drawbacks of Drivechain. It aimed to identify those who have a good knowledge of Drivechain. Some questions had alternative answers, while others were deemed incorrect or not fully answered.The quiz discussed various aspects of Drivechain, including the parameters "m" and "b" which represent how much people want to kill a sidechain and how much profit a mainchain miner expects from supporting a sidechain. It also touched on topics such as how m can be above one, how Drivechain is designed to deter sc-theft, and how the BTC network might become uncompetitive.ZmnSCPxj confirmed in a bitcoin-dev post that both Lightning Network (LN) and Drivechain are vulnerable to miner-theft, but they use their designs to deter theft. However, in LN, a 51% miner can only attack channels in which it is a participant, while in Drivechain, a 51% miner can simultaneously attack all sidechains and steal all funds. The main obstacle in LN is that the miner-coalition must join the channel, whereas in Drivechain, the main obstacle is constructing a transaction obeying the Bip300 rules, which are designed to thwart miner-theft.Paul Sztorc made a statement about a 51% hashrate being able to double-spend in LN by censoring "justice transactions," and ZmnSCPxj confirmed the truth in this statement. However, ZmnSCPxj pointed out that a 51% miner can only attack LN channels it is a participant in, whereas in Drivechain, a 51% miner can steal all funds from any sidechain simultaneously. ZmnSCPxj also discussed the possibility of a non-participant convincing a 51% miner to help with an attack, but concluded that the honest participant always has the upper hand due to time preference and the ability to offer fees immediately.ZmnSCPxj noted that in the presence of channel factories, the entire factory is at risk if at least one participant is a 51% miner or a sockpuppet. This trade-off in channel factories further scales but reduces protection against 51% miners.Overall, the quiz and discussion highlighted the intricacies of Drivechain's security model, withdrawal system, and potential vulnerabilities. It emphasized the importance of understanding these aspects to ensure the safety of funds in Drivechain. 2022-02-27T00:42:22+00:00 + In a recent email conversation between Paul and ZmnSCPxj, a quiz was presented to test one's understanding of Drivechain. The quiz included questions about the security model, withdrawal system, and potential drawbacks of Drivechain. It aimed to identify those who have a good knowledge of Drivechain. Some questions had alternative answers, while others were deemed incorrect or not fully answered.The quiz discussed various aspects of Drivechain, including the parameters "m" and "b" which represent how much people want to kill a sidechain and how much profit a mainchain miner expects from supporting a sidechain. It also touched on topics such as how m can be above one, how Drivechain is designed to deter sc-theft, and how the BTC network might become uncompetitive.ZmnSCPxj confirmed in a bitcoin-dev post that both Lightning Network (LN) and Drivechain are vulnerable to miner-theft, but they use their designs to deter theft. However, in LN, a 51% miner can only attack channels in which it is a participant, while in Drivechain, a 51% miner can simultaneously attack all sidechains and steal all funds. The main obstacle in LN is that the miner-coalition must join the channel, whereas in Drivechain, the main obstacle is constructing a transaction obeying the Bip300 rules, which are designed to thwart miner-theft.Paul Sztorc made a statement about a 51% hashrate being able to double-spend in LN by censoring "justice transactions," and ZmnSCPxj confirmed the truth in this statement. However, ZmnSCPxj pointed out that a 51% miner can only attack LN channels it is a participant in, whereas in Drivechain, a 51% miner can steal all funds from any sidechain simultaneously. ZmnSCPxj also discussed the possibility of a non-participant convincing a 51% miner to help with an attack, but concluded that the honest participant always has the upper hand due to time preference and the ability to offer fees immediately.ZmnSCPxj noted that in the presence of channel factories, the entire factory is at risk if at least one participant is a 51% miner or a sockpuppet. This trade-off in channel factories further scales but reduces protection against 51% miners.Overall, the quiz and discussion highlighted the intricacies of Drivechain's security model, withdrawal system, and potential vulnerabilities. It emphasized the importance of understanding these aspects to ensure the safety of funds in Drivechain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_A-suggestion-to-periodically-destroy-or-remove-to-secondary-storage-for-Archiving-reasons-dust-Non-standard-UTXOs-and-also-detected-burn.xml b/static/bitcoin-dev/Feb_2022/combined_A-suggestion-to-periodically-destroy-or-remove-to-secondary-storage-for-Archiving-reasons-dust-Non-standard-UTXOs-and-also-detected-burn.xml index 4182d652f7..7b7ccf0c8b 100644 --- a/static/bitcoin-dev/Feb_2022/combined_A-suggestion-to-periodically-destroy-or-remove-to-secondary-storage-for-Archiving-reasons-dust-Non-standard-UTXOs-and-also-detected-burn.xml +++ b/static/bitcoin-dev/Feb_2022/combined_A-suggestion-to-periodically-destroy-or-remove-to-secondary-storage-for-Archiving-reasons-dust-Non-standard-UTXOs-and-also-detected-burn.xml @@ -1,39 +1,60 @@ - + 2 Combined summary - A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn - 2023-08-02T05:34:08.334106+00:00 - - shymaa arafat 2022-02-13 13:11:18+00:00 - - - yanmaani at cock.li 2022-02-13 09:56:21+00:00 - - - shymaa arafat 2022-02-13 05:19:04+00:00 - - - shymaa arafat 2022-02-07 16:51:54+00:00 - - - Billy Tetrud 2022-02-07 14:34:42+00:00 - - - shymaa arafat 2022-02-06 12:41:33+00:00 - + 2025-09-26T14:41:03.036458+00:00 + python-feedgen + + + [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn shymaa arafat + 2022-02-06T12:41:00.000Z + + + Pieter Wuille + 2022-02-06T17:39:00.000Z + + + Eric Voskuil + 2022-02-06T19:14:00.000Z + + + Billy Tetrud + 2022-02-07T14:34:00.000Z + + + shymaa arafat + 2022-02-07T16:51:00.000Z + + + shymaa arafat + 2022-02-13T05:19:00.000Z + + + yanmaani + 2022-02-13T09:56:00.000Z + + + shymaa arafat + 2022-02-13T13:11:00.000Z + + + ZmnSCPxj + 2022-02-18T03:36:00.000Z + + - python-feedgen + 2 Combined summary - A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn - 2023-08-02T05:34:08.334106+00:00 + 2025-09-26T14:41:03.037747+00:00 - The issue of handling the extensive amount of dust created by Alt coins and new protocols is being discussed on the Bitcointalk thread. One suggestion is to divide 1 Satoshi into fractions or accept a UTXO with 0 value, which could be considered non-standard transactions. This idea is referenced in an email from 2016 regarding non-standard transactions.On the Bitcoin-dev mailing list, there is a discussion about addressing the issue of UTXO set size. One proposed solution is to use economic incentives to discourage the creation of new UTXOs. This would involve charging a fee based on bytes and byte weight plus net_utxos and utxo weight. Implementing this through a soft fork could result in a lower block size cap. There is also mention of limiting the block size cap at 0 to avoid guaranteed returns.During this discussion, Billy Tetrud brings up the issue of UTXO set size and suggests using utreexo or another accumulator as a solution. Another member suggests using economic incentives to disincentivize the creation of new UTXOs by charging a fee based on transaction size and number of UTXOs created. This proposal would require lowering the block size cap and may be contentious. It is also important to limit the block size cap at 0 to ensure users are not guaranteed to get back whatever they put into it.There are millions of UTXOs with small amounts of Bitcoin. BitInfoCharts has added a link for dust analysis on their site, allowing users to view the top 100 dustiest Bitcoin addresses. There are also similar cases with smaller numbers of UTXOs. Shymaa suggests that people with holdings below a certain threshold should collect those UTXOs into larger amounts during low fee times. The number of UTXOs below certain thresholds is increasing daily.While it has been suggested to delete or trim low-value UTXOs, this could be considered theft and could destroy useful funds. It may be worth investigating using the amount as a heuristic for deciding what to keep and for how long. Currently, there are no rules mandating minimal fees for transactions, and it is unclear what those rules should be given the uncertainty of fee levels in the future.In another thread on the bitcoin-dev mailing list, there is discussion about lightning network transactions creating dust UTXOs. This adds to the issue of UTXO set size that will need to be addressed. One potential solution is the use of utreexo or another accumulator. Some suggest storing outputs unlikely to be spent off RAM, but others argue against deleting them entirely from the UTXO set as it may be considered theft and could destroy useful funds. Instead, it may be useful to investigate using the amount as a heuristic for deciding what to keep and how long. There is debate over whether archiving non-standard and burned UTXOs should be a standardness or consensus rule.The author of a proposal suggests deleting UTXOs holding small amounts of Bitcoin, along with non-standard and burned UTXOs. This would relieve the system state of a large number of UTXOs and add to the scarcity of Bitcoin. The proposal could be beneficial in the long run as the number of dust UTXOs is expected to increase over time. Further study is needed to determine optimal values for deleting UTXOs at different intervals and thresholds. 2022-02-13T13:11:18+00:00 + The issue of handling the extensive amount of dust created by Alt coins and new protocols is being discussed on the Bitcointalk thread. One suggestion is to divide 1 Satoshi into fractions or accept a UTXO with 0 value, which could be considered non-standard transactions. This idea is referenced in an email from 2016 regarding non-standard transactions.On the Bitcoin-dev mailing list, there is a discussion about addressing the issue of UTXO set size. One proposed solution is to use economic incentives to discourage the creation of new UTXOs. This would involve charging a fee based on bytes and byte weight plus net_utxos and utxo weight. Implementing this through a soft fork could result in a lower block size cap. There is also mention of limiting the block size cap at 0 to avoid guaranteed returns.During this discussion, Billy Tetrud brings up the issue of UTXO set size and suggests using utreexo or another accumulator as a solution. Another member suggests using economic incentives to disincentivize the creation of new UTXOs by charging a fee based on transaction size and number of UTXOs created. This proposal would require lowering the block size cap and may be contentious. It is also important to limit the block size cap at 0 to ensure users are not guaranteed to get back whatever they put into it.There are millions of UTXOs with small amounts of Bitcoin. BitInfoCharts has added a link for dust analysis on their site, allowing users to view the top 100 dustiest Bitcoin addresses. There are also similar cases with smaller numbers of UTXOs. Shymaa suggests that people with holdings below a certain threshold should collect those UTXOs into larger amounts during low fee times. The number of UTXOs below certain thresholds is increasing daily.While it has been suggested to delete or trim low-value UTXOs, this could be considered theft and could destroy useful funds. It may be worth investigating using the amount as a heuristic for deciding what to keep and for how long. Currently, there are no rules mandating minimal fees for transactions, and it is unclear what those rules should be given the uncertainty of fee levels in the future.In another thread on the bitcoin-dev mailing list, there is discussion about lightning network transactions creating dust UTXOs. This adds to the issue of UTXO set size that will need to be addressed. One potential solution is the use of utreexo or another accumulator. Some suggest storing outputs unlikely to be spent off RAM, but others argue against deleting them entirely from the UTXO set as it may be considered theft and could destroy useful funds. Instead, it may be useful to investigate using the amount as a heuristic for deciding what to keep and how long. There is debate over whether archiving non-standard and burned UTXOs should be a standardness or consensus rule.The author of a proposal suggests deleting UTXOs holding small amounts of Bitcoin, along with non-standard and burned UTXOs. This would relieve the system state of a large number of UTXOs and add to the scarcity of Bitcoin. The proposal could be beneficial in the long run as the number of dust UTXOs is expected to increase over time. Further study is needed to determine optimal values for deleting UTXOs at different intervals and thresholds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Advancing-the-security-of-Neutrino-using-minimally-trusted-oracles.xml b/static/bitcoin-dev/Feb_2022/combined_Advancing-the-security-of-Neutrino-using-minimally-trusted-oracles.xml index 201164e96d..930fa0d257 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Advancing-the-security-of-Neutrino-using-minimally-trusted-oracles.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Advancing-the-security-of-Neutrino-using-minimally-trusted-oracles.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Advancing the security of Neutrino using minimally trusted oracles - 2023-08-02T05:34:25.680202+00:00 - - enclade 2022-02-11 02:39:15+00:00 - - - Devrandom 2022-02-10 21:07:14+00:00 - - - enclade 2022-02-10 10:02:08+00:00 - + 2025-09-26T14:41:17.921955+00:00 + python-feedgen + + + [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles enclade + 2022-02-10T10:02:00.000Z + + + Devrandom + 2022-02-10T21:07:00.000Z + + + enclade + 2022-02-11T02:39:00.000Z + + - python-feedgen + 2 Combined summary - Advancing the security of Neutrino using minimally trusted oracles - 2023-08-02T05:34:25.680202+00:00 + 2025-09-26T14:41:17.922479+00:00 - A proposal has been made to make the protocol design completely interactive for the Validating Lightning Signer project. In this proposal, the client sends a nonce over DNS and the oracle responds by signing the nonce. However, it was pointed out that using quantized timestamps could mitigate many issues regarding denial of service and make fault proofs stronger.The oracles' messages can be delivered over a write-only channel like Kryptoradio or Blockstream Satellite, which would scale well. When the oracles produce agreeing messages, the additional data is only 64 bytes per additional signer, so it makes sense to broadcast any a client may want to trust.To reduce their attack surface, it is suggested that the oracles be non-interactive. Instead of signing over a client-provided timestamp, they could pre-quantize the timestamp and emit attestations for each quantum time step.This proposal is related to the design doc available at https://gitlab.com/lightning-signer/docs/-/blob/master/oracle.md.The use of oracles to provide a moderate level of confidence to lightweight clients in the filters they have received from an untrusted source has been outlined in a design document which inspired Neutrino. The determinism of the filter headers allows for them to be simply and compactly attested by a potentially large number of authoritative sources with minimal loss in privacy. These sources could be exchanges, hardware wallet manufacturers, block explorers, or other well-known parties.DNS is the most obvious transport for these oracles, and several implementations of tools exist which provide either headers or raw filter data to clients by encoding it in record responses. This allows oracles to operate with low resource requirements and attack surface while providing a privacy-maximizing service to their clients. Other tools can also aggregate the signatures into other formats as required.Clients can consider their view of the current network state to be strong when several of their oracle sources present agreeing signatures, or display an error to their user if no suitable number of attestations could be found. Fault or fraud proofs can be generated by any party by simply collecting differing signatures, making errors readily apparent and provable.Host names and their associated keys would be baked into the binaries of client software supporting the system, but their location and credentials could be attested in a text file of their primary domain. Oracles would return the current block hash, hash of the tip of the neutrino header chain, and an ECDSA signature over the data including the requesting quantized timestamp. This provides the client with sufficient and portable evidence that their view of the state of the network has not been tampered with, while maintaining as much privacy as possible.This proposal would be very useful for the Validating Lightning Signer project as it allows the signer to ensure that the channel is still active. The related design doc can be found at https://gitlab.com/lightning-signer/docs/-/blob/master/oracle.md. 2022-02-11T02:39:15+00:00 + A proposal has been made to make the protocol design completely interactive for the Validating Lightning Signer project. In this proposal, the client sends a nonce over DNS and the oracle responds by signing the nonce. However, it was pointed out that using quantized timestamps could mitigate many issues regarding denial of service and make fault proofs stronger.The oracles' messages can be delivered over a write-only channel like Kryptoradio or Blockstream Satellite, which would scale well. When the oracles produce agreeing messages, the additional data is only 64 bytes per additional signer, so it makes sense to broadcast any a client may want to trust.To reduce their attack surface, it is suggested that the oracles be non-interactive. Instead of signing over a client-provided timestamp, they could pre-quantize the timestamp and emit attestations for each quantum time step.This proposal is related to the design doc available at https://gitlab.com/lightning-signer/docs/-/blob/master/oracle.md.The use of oracles to provide a moderate level of confidence to lightweight clients in the filters they have received from an untrusted source has been outlined in a design document which inspired Neutrino. The determinism of the filter headers allows for them to be simply and compactly attested by a potentially large number of authoritative sources with minimal loss in privacy. These sources could be exchanges, hardware wallet manufacturers, block explorers, or other well-known parties.DNS is the most obvious transport for these oracles, and several implementations of tools exist which provide either headers or raw filter data to clients by encoding it in record responses. This allows oracles to operate with low resource requirements and attack surface while providing a privacy-maximizing service to their clients. Other tools can also aggregate the signatures into other formats as required.Clients can consider their view of the current network state to be strong when several of their oracle sources present agreeing signatures, or display an error to their user if no suitable number of attestations could be found. Fault or fraud proofs can be generated by any party by simply collecting differing signatures, making errors readily apparent and provable.Host names and their associated keys would be baked into the binaries of client software supporting the system, but their location and credentials could be attested in a text file of their primary domain. Oracles would return the current block hash, hash of the tip of the neutrino header chain, and an ECDSA signature over the data including the requesting quantized timestamp. This provides the client with sufficient and portable evidence that their view of the state of the network has not been tampered with, while maintaining as much privacy as possible.This proposal would be very useful for the Validating Lightning Signer project as it allows the signer to ensure that the channel is still active. The related design doc can be found at https://gitlab.com/lightning-signer/docs/-/blob/master/oracle.md. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_BIP-119-CTV-Meeting-3-Draft-Agenda-for-Tuesday-February-8th-at-12-00-PT.xml b/static/bitcoin-dev/Feb_2022/combined_BIP-119-CTV-Meeting-3-Draft-Agenda-for-Tuesday-February-8th-at-12-00-PT.xml index a89479fc72..8579c0cf68 100644 --- a/static/bitcoin-dev/Feb_2022/combined_BIP-119-CTV-Meeting-3-Draft-Agenda-for-Tuesday-February-8th-at-12-00-PT.xml +++ b/static/bitcoin-dev/Feb_2022/combined_BIP-119-CTV-Meeting-3-Draft-Agenda-for-Tuesday-February-8th-at-12-00-PT.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP-119 CTV Meeting #3 Draft Agenda for Tuesday February 8th at 12:00 PT - 2023-08-02T05:33:46.653715+00:00 - - Jeremy Rubin 2022-02-07 19:10:41+00:00 - - - Jeremy Rubin 2022-02-02 20:29:19+00:00 - + 2025-09-26T14:41:15.812192+00:00 + python-feedgen + + + [bitcoin-dev] BIP-119 CTV Meeting #3 Draft Agenda for Tuesday February 8th at 12:00 PT Jeremy Rubin + 2022-02-02T20:29:00.000Z + + + Jeremy Rubin + 2022-02-07T19:10:00.000Z + + - python-feedgen + 2 Combined summary - BIP-119 CTV Meeting #3 Draft Agenda for Tuesday February 8th at 12:00 PT - 2023-08-02T05:33:46.653715+00:00 + 2025-09-26T14:41:15.812653+00:00 - The Non-Interactive Lightning Channels topic will include discussions on two links provided: https://rubin.io/bitcoin/2021/12/11/advent-14/ and https://utxos.org/uses/non-interactive-channels/. The CTV's "Dramatic" Improvement of DLCs section will cover three links: https://zensored.substack.com/p/supercharging-dlcs-with-ctv, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html, and https://rubin.io/bitcoin/2021/12/20/advent-23/. The PathCoin section discusses a proposal for transferring coins offline by pre-compiling chains of transfers cleverly. The details can be found at two links: https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019809.html. The OP_TXHASH section talks about an alternative approach to OP_CTV + APO's functionality using programmable tx hash opcode, with discussions available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html. Lastly, the Emulating CTV for Liquid topic is covered in this link: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019851.html.The meeting will conclude with 15 minutes of General Discussion. 2022-02-07T19:10:41+00:00 + The Non-Interactive Lightning Channels topic will include discussions on two links provided: https://rubin.io/bitcoin/2021/12/11/advent-14/ and https://utxos.org/uses/non-interactive-channels/. The CTV's "Dramatic" Improvement of DLCs section will cover three links: https://zensored.substack.com/p/supercharging-dlcs-with-ctv, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html, and https://rubin.io/bitcoin/2021/12/20/advent-23/. The PathCoin section discusses a proposal for transferring coins offline by pre-compiling chains of transfers cleverly. The details can be found at two links: https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019809.html. The OP_TXHASH section talks about an alternative approach to OP_CTV + APO's functionality using programmable tx hash opcode, with discussions available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html. Lastly, the Emulating CTV for Liquid topic is covered in this link: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019851.html.The meeting will conclude with 15 minutes of General Discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_BIP-119-CTV-Meeting-4-Draft-Agenda-for-Tuesday-February-22nd-at-12-00-PT.xml b/static/bitcoin-dev/Feb_2022/combined_BIP-119-CTV-Meeting-4-Draft-Agenda-for-Tuesday-February-22nd-at-12-00-PT.xml index 668fc20854..ff17950c56 100644 --- a/static/bitcoin-dev/Feb_2022/combined_BIP-119-CTV-Meeting-4-Draft-Agenda-for-Tuesday-February-22nd-at-12-00-PT.xml +++ b/static/bitcoin-dev/Feb_2022/combined_BIP-119-CTV-Meeting-4-Draft-Agenda-for-Tuesday-February-22nd-at-12-00-PT.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP-119 CTV Meeting #4 Draft Agenda for Tuesday February 22nd at 12:00 PT - 2023-08-02T05:42:42.827380+00:00 - - Jeremy Rubin 2022-02-22 18:05:21+00:00 - - - Jeremy Rubin 2022-02-22 03:36:05+00:00 - + 2025-09-26T14:40:45.884317+00:00 + python-feedgen + + + [bitcoin-dev] BIP-119 CTV Meeting #4 Draft Agenda for Tuesday February 22nd at 12:00 PT Jeremy Rubin + 2022-02-22T03:36:00.000Z + + + Jeremy Rubin + 2022-02-22T18:05:00.000Z + + - python-feedgen + 2 Combined summary - BIP-119 CTV Meeting #4 Draft Agenda for Tuesday February 22nd at 12:00 PT - 2023-08-02T05:42:42.827380+00:00 + 2025-09-26T14:40:45.884812+00:00 - In this tutorial by Jeremy Rubin, he explains how to use the Sapio CLI to generate contracts and interact with them on the network. The tutorial focuses on using a congestion control tree as an example. To begin, you will need to install JQ (a json manipulating tool) and other necessary tools for running a bitcoin node. Next, set up a node following the instructions provided. You can find the installation instructions on the Sapio website at https://learn.sapio-lang.org/ch01-01-installation.html. It is recommended to skip the sapio-studio part and pod part and proceed with the Local Quickstart until "Instantiate a contract from the plugin".Once your node is set up, open the site https://rjsf-team.github.io/react-jsonschema-form/ and run the command *sapio-cli contract api --fileplugin-example/target/wasm32-unknown-unknown/debug/sapio_wasm_plugin_example.wasm*. Copy the resulting JSON into the RJSF site and fill out the form as desired. After filling out the form, you should see a JSON output. You may need to delete some extra fields due to minor bugs on the site. Alternatively, you can modify the JSON directly and save it in a file named ARGS.json.The next step is to modify your sapio-cli config file. Create a contract template and obtain a proposed funding amount and binding of the template to the UTXO (unspent transaction output). Once the funding transaction is finalized, review the hex transaction and ensure that you want to proceed with the contract. Finally, send the contract and any other related transactions to the network.There are several additional things you can explore, such as using the Sapio Studio GUI, modifying the congestion control tree code, recompiling it, and trying out other contracts.In the upcoming fourth CTV meeting, tutorials will be the main focus. Participants are encouraged to prepare beforehand. The meeting will cover several topics. The first topic of discussion will be the objective of Signet and the decision function of observations from a test network. The team will also consider which applications should be prototyped and developed further, taking into account the necessary level of detail. They will also discuss the possibility of adding other experiments like APO/Sponsors and incorporating lightning for the signet.The second topic will be connecting to the CTV Signet Tutorial. Participants will ensure that everyone who wants to join can do so and address any issues that arise. Attendees are requested to build a branch from https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-signet-23.0-alpha and connect to [signet] signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae and addnode=50.18.75.225.The third topic will focus on receiving and sending coins. There is a faucet available for the signet at https://faucet.ctvsignet.com and an explorer at https://explorer.ctvsignet.com.The fourth topic will be a Sapio tutorial. Participants are advised to go through the documentation at https://learn.sapio-lang.org and download/build the sapio cli & plugin examples before the meeting. The team will guide everyone in building and sending a basic application, such as a congestion control tree or vault, on the signet.The fifth topic will be a Sapio Q&A session, where attendees can share their experiences with Sapio and have a more general discussion about the project and its potential accomplishments.The meeting will conclude with a 30-minute general discussion. 2022-02-22T18:05:21+00:00 + In this tutorial by Jeremy Rubin, he explains how to use the Sapio CLI to generate contracts and interact with them on the network. The tutorial focuses on using a congestion control tree as an example. To begin, you will need to install JQ (a json manipulating tool) and other necessary tools for running a bitcoin node. Next, set up a node following the instructions provided. You can find the installation instructions on the Sapio website at https://learn.sapio-lang.org/ch01-01-installation.html. It is recommended to skip the sapio-studio part and pod part and proceed with the Local Quickstart until "Instantiate a contract from the plugin".Once your node is set up, open the site https://rjsf-team.github.io/react-jsonschema-form/ and run the command *sapio-cli contract api --fileplugin-example/target/wasm32-unknown-unknown/debug/sapio_wasm_plugin_example.wasm*. Copy the resulting JSON into the RJSF site and fill out the form as desired. After filling out the form, you should see a JSON output. You may need to delete some extra fields due to minor bugs on the site. Alternatively, you can modify the JSON directly and save it in a file named ARGS.json.The next step is to modify your sapio-cli config file. Create a contract template and obtain a proposed funding amount and binding of the template to the UTXO (unspent transaction output). Once the funding transaction is finalized, review the hex transaction and ensure that you want to proceed with the contract. Finally, send the contract and any other related transactions to the network.There are several additional things you can explore, such as using the Sapio Studio GUI, modifying the congestion control tree code, recompiling it, and trying out other contracts.In the upcoming fourth CTV meeting, tutorials will be the main focus. Participants are encouraged to prepare beforehand. The meeting will cover several topics. The first topic of discussion will be the objective of Signet and the decision function of observations from a test network. The team will also consider which applications should be prototyped and developed further, taking into account the necessary level of detail. They will also discuss the possibility of adding other experiments like APO/Sponsors and incorporating lightning for the signet.The second topic will be connecting to the CTV Signet Tutorial. Participants will ensure that everyone who wants to join can do so and address any issues that arise. Attendees are requested to build a branch from https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-signet-23.0-alpha and connect to [signet] signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae and addnode=50.18.75.225.The third topic will focus on receiving and sending coins. There is a faucet available for the signet at https://faucet.ctvsignet.com and an explorer at https://explorer.ctvsignet.com.The fourth topic will be a Sapio tutorial. Participants are advised to go through the documentation at https://learn.sapio-lang.org and download/build the sapio cli & plugin examples before the meeting. The team will guide everyone in building and sending a basic application, such as a congestion control tree or vault, on the signet.The fifth topic will be a Sapio Q&A session, where attendees can share their experiences with Sapio and have a more general discussion about the project and its potential accomplishments.The meeting will conclude with a 30-minute general discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_CTV-Signet-Parameters.xml b/static/bitcoin-dev/Feb_2022/combined_CTV-Signet-Parameters.xml index 73074f47b1..cd9988f74e 100644 --- a/static/bitcoin-dev/Feb_2022/combined_CTV-Signet-Parameters.xml +++ b/static/bitcoin-dev/Feb_2022/combined_CTV-Signet-Parameters.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - CTV Signet Parameters - 2023-08-02T05:39:40.983139+00:00 - - Jeremy Rubin 2022-04-28 12:23:32+00:00 - - - Jeremy Rubin 2022-04-22 05:30:08+00:00 - - - Nadav Ivgi 2022-04-22 01:10:25+00:00 - - - Anthony Towns 2022-04-22 00:58:04+00:00 - - - Jeremy Rubin 2022-04-21 15:05:20+00:00 - - - Russell O'Connor 2022-04-21 13:22:21+00:00 - - - Jeremy Rubin 2022-04-21 06:25:05+00:00 - - - Jeremy Rubin 2022-04-21 06:16:09+00:00 - - - Anthony Towns 2022-04-21 05:03:51+00:00 - - - Anthony Towns 2022-04-21 02:36:00+00:00 - - - Buck O Perley 2022-04-20 17:13:19+00:00 - - - Nadav Ivgi 2022-04-20 17:05:36+00:00 - - - Anthony Towns 2022-04-20 02:31:07+00:00 - - - Jeremy Rubin 2022-02-22 03:19:23+00:00 - - - 0x0ff 2022-02-18 11:13:31+00:00 - - - Jeremy Rubin 2022-02-17 21:58:38+00:00 - + 2025-09-26T14:41:13.698445+00:00 + python-feedgen + + + [bitcoin-dev] CTV Signet Parameters Jeremy Rubin + 2022-02-17T21:58:00.000Z + + + 0x0ff + 2022-02-18T11:13:00.000Z + + + Jeremy Rubin + 2022-02-22T03:19:00.000Z + + + Anthony Towns + 2022-04-20T02:31:00.000Z + + + Nadav Ivgi + 2022-04-20T17:05:00.000Z + + + Buck O Perley + 2022-04-20T17:13:00.000Z + + + Anthony Towns + 2022-04-21T02:36:00.000Z + + + Anthony Towns + 2022-04-21T05:03:00.000Z + + + Jeremy Rubin + 2022-04-21T06:16:00.000Z + + + Jeremy Rubin + 2022-04-21T06:25:00.000Z + + + Russell O'Connor + 2022-04-21T13:22:00.000Z + + + Jeremy Rubin + 2022-04-21T15:05:00.000Z + + + Anthony Towns + 2022-04-22T00:58:00.000Z + + + Nadav Ivgi + 2022-04-22T01:10:00.000Z + + + Jeremy Rubin + 2022-04-22T05:30:00.000Z + + + Jeremy Rubin + 2022-04-28T12:23:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - CTV Signet Parameters - 2023-08-02T05:39:40.984135+00:00 + 2025-09-26T14:41:13.700161+00:00 - In a discussion on the Bitcoin scripting language, a member raised a question about the necessity of using DROP/1 when leaving a 32-byte hash on the stack. Another member clarified that it may not necessarily mean everyone is using Sapio to construct transactions, but they may be using sapio-miniscript or a different miniscript implementation compatible with sapio-miniscript's CTV fragment. The use of miniscript seems different than using Sapio, but the underlying point of the discussion remains unchanged.The conversation then shifted to the potential benefits of using bare CTV over segwit v0/v1. It was noted that bare CTV can save 34 or 67 bytes per histogram bucket, allowing for more buckets and greater feerate savings. Binning into 5 groups yields a higher feerate discount compared to binning into 4 groups. However, the knock-on effects of these changes are difficult to predict accurately. The cheapness of nodes in the graph can change the optimal graph and make simple comparisons inadequate. Bugs like nonstandard broadcasting would be fixed through testing, and the proposed changes are still in the "interesting thought experiment" stage.Regarding the use of bare CTV, it was mentioned that it only saves bytes when spending, and an extra 34 or 67 bytes of witness data is fairly immaterial. Real user data suggests that nobody will benefit from using bare CTV. Upgrading old hardware may be necessary to support new features. The potential benefits of using segwit v0 CTV for users with hardware modules or MPC Threshold Crypto that only support ECDSA signatures were also discussed.In the discussion on the bitcoin-dev mailing list, various participants shared their thoughts on the use of bare CTV in different contexts. Testing was emphasized as a crucial step in identifying bugs and ensuring consistency with proposed consensus and policy rules. The benefits of bare CTV were explored, including its potential to save space when batching transactions for customers with different fee priority levels. However, it was noted that real user data suggests that nobody will benefit from using bare CTV. The possibility of using OP_SUCCESSx in segwitv0 CTV was discussed, but it was concluded that upgrading old hardware may be necessary to support new features.The discussion on Consensus-enforced Transaction Verification (CTV) in Bitcoin highlighted the importance of testing and demonstrating major use cases before implementing new features. While there are working prototypes of CTV's use cases, they are not yet production-ready. The potential benefits of CTV were explored, such as combining batches into a root and N batch outputs, eliminating the need for inputs, signatures, and change outputs per batch. However, the limitations and additional blockspace usage of bare-CTV were questioned. The use of an OP_SUCCESS code from tapscript instead of bare-CTV was suggested as a better alternative. The justification for bare-CTV and its limitations were further discussed.A recent email thread focused on the testing and implementation of new feature proposals. The criteria for soft-forking a proposal into consensus code were discussed, emphasizing the need for real-life use cases and sufficient testing. CheckTemplateVerify (CTV), a feature enabling more complex smart contracts, was examined. While there are prototypes of CTV's major use cases, they are not yet production-ready. Sapio was highlighted as an example of CTV's versatility. The discussion also touched on other proposed features such as eltoo and TLUV, noting their current status and design considerations. It was suggested that consensus should not be rushed until use cases are fully fleshed out and demonstrated.In a bitcoin-dev post, the importance of decision making and testing before implementing changes was emphasized. The significance of hard numbers and clear metrics for evaluating proposals was questioned. The readiness and eagerness to use CheckTemplateVerify (CTV) and Taproot were compared. The usefulness of bare-CTV and its limitations were discussed, along with alternative options like using an OP_SUCCESS code from tapscript. The writer suggested defining clear metrics for evaluating proposals to facilitate decision making.In a discussion on the bitcoin-dev mailing list, a member questioned the necessity of DROP/1 in a specific context. Another participant explained that with Taproot's CLEANSTACK rule, leaving the 32-byte hash on the stack would not evaluate as true. The conversation also touched on the use of CastToBool() function in tapscript and the relevance of the MINIMALIF rule to CTV.Overall, the discussions revolve around the potential benefits, limitations, and testing of Consensus-enforced Transaction Verification (CTV) in Bitcoin. Various perspectives on the use of bare CTV, alternative implementations, and the need for clear metrics are presented.In a recent email thread on the bitcoin-dev mailing list, the lack of practical experimentation with CheckTemplateVerify (CTV) was discussed. Anthony Towns highlighted that there had been over 2,200 transactions on the CTV signet, but 2022-04-28T12:23:32+00:00 + In a discussion on the Bitcoin scripting language, a member raised a question about the necessity of using DROP/1 when leaving a 32-byte hash on the stack. Another member clarified that it may not necessarily mean everyone is using Sapio to construct transactions, but they may be using sapio-miniscript or a different miniscript implementation compatible with sapio-miniscript's CTV fragment. The use of miniscript seems different than using Sapio, but the underlying point of the discussion remains unchanged.The conversation then shifted to the potential benefits of using bare CTV over segwit v0/v1. It was noted that bare CTV can save 34 or 67 bytes per histogram bucket, allowing for more buckets and greater feerate savings. Binning into 5 groups yields a higher feerate discount compared to binning into 4 groups. However, the knock-on effects of these changes are difficult to predict accurately. The cheapness of nodes in the graph can change the optimal graph and make simple comparisons inadequate. Bugs like nonstandard broadcasting would be fixed through testing, and the proposed changes are still in the "interesting thought experiment" stage.Regarding the use of bare CTV, it was mentioned that it only saves bytes when spending, and an extra 34 or 67 bytes of witness data is fairly immaterial. Real user data suggests that nobody will benefit from using bare CTV. Upgrading old hardware may be necessary to support new features. The potential benefits of using segwit v0 CTV for users with hardware modules or MPC Threshold Crypto that only support ECDSA signatures were also discussed.In the discussion on the bitcoin-dev mailing list, various participants shared their thoughts on the use of bare CTV in different contexts. Testing was emphasized as a crucial step in identifying bugs and ensuring consistency with proposed consensus and policy rules. The benefits of bare CTV were explored, including its potential to save space when batching transactions for customers with different fee priority levels. However, it was noted that real user data suggests that nobody will benefit from using bare CTV. The possibility of using OP_SUCCESSx in segwitv0 CTV was discussed, but it was concluded that upgrading old hardware may be necessary to support new features.The discussion on Consensus-enforced Transaction Verification (CTV) in Bitcoin highlighted the importance of testing and demonstrating major use cases before implementing new features. While there are working prototypes of CTV's use cases, they are not yet production-ready. The potential benefits of CTV were explored, such as combining batches into a root and N batch outputs, eliminating the need for inputs, signatures, and change outputs per batch. However, the limitations and additional blockspace usage of bare-CTV were questioned. The use of an OP_SUCCESS code from tapscript instead of bare-CTV was suggested as a better alternative. The justification for bare-CTV and its limitations were further discussed.A recent email thread focused on the testing and implementation of new feature proposals. The criteria for soft-forking a proposal into consensus code were discussed, emphasizing the need for real-life use cases and sufficient testing. CheckTemplateVerify (CTV), a feature enabling more complex smart contracts, was examined. While there are prototypes of CTV's major use cases, they are not yet production-ready. Sapio was highlighted as an example of CTV's versatility. The discussion also touched on other proposed features such as eltoo and TLUV, noting their current status and design considerations. It was suggested that consensus should not be rushed until use cases are fully fleshed out and demonstrated.In a bitcoin-dev post, the importance of decision making and testing before implementing changes was emphasized. The significance of hard numbers and clear metrics for evaluating proposals was questioned. The readiness and eagerness to use CheckTemplateVerify (CTV) and Taproot were compared. The usefulness of bare-CTV and its limitations were discussed, along with alternative options like using an OP_SUCCESS code from tapscript. The writer suggested defining clear metrics for evaluating proposals to facilitate decision making.In a discussion on the bitcoin-dev mailing list, a member questioned the necessity of DROP/1 in a specific context. Another participant explained that with Taproot's CLEANSTACK rule, leaving the 32-byte hash on the stack would not evaluate as true. The conversation also touched on the use of CastToBool() function in tapscript and the relevance of the MINIMALIF rule to CTV.Overall, the discussions revolve around the potential benefits, limitations, and testing of Consensus-enforced Transaction Verification (CTV) in Bitcoin. Various perspectives on the use of bare CTV, alternative implementations, and the need for clear metrics are presented.In a recent email thread on the bitcoin-dev mailing list, the lack of practical experimentation with CheckTemplateVerify (CTV) was discussed. Anthony Towns highlighted that there had been over 2,200 transactions on the CTV signet, but - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_CTV-dramatically-improves-DLCs.xml b/static/bitcoin-dev/Feb_2022/combined_CTV-dramatically-improves-DLCs.xml index fa91ca8b98..a25c61cef4 100644 --- a/static/bitcoin-dev/Feb_2022/combined_CTV-dramatically-improves-DLCs.xml +++ b/static/bitcoin-dev/Feb_2022/combined_CTV-dramatically-improves-DLCs.xml @@ -1,32 +1,55 @@ - + 2 Combined summary - CTV dramatically improves DLCs - 2023-08-02T05:25:02.224690+00:00 - - Jeremy Rubin 2022-03-15 17:28:05+00:00 - - - Thibaut Le Guilly 2022-02-07 02:30:32+00:00 - - - Jeremy Rubin 2022-02-06 17:56:12+00:00 - - - Lloyd Fournier 2022-02-06 07:18:11+00:00 - - - Alex Schoof 2022-01-28 21:14:12+00:00 - - - Jeremy Rubin 2022-01-28 19:38:29+00:00 - - - Jeremy 2022-01-28 17:21:09+00:00 - - - Lloyd Fournier 2022-01-24 08:01:17+00:00 - + 2025-09-26T14:40:43.765841+00:00 + python-feedgen + + + [bitcoin-dev] CTV dramatically improves DLCs Lloyd Fournier + 2022-01-24T08:01:00.000Z + + + [bitcoin-dev] [dlc-dev] " Jonas Nick + 2022-01-25T16:24:00.000Z + + + Thibaut Le Guilly + 2022-01-27T00:45:00.000Z + + + Jeremy + 2022-01-28T16:53:00.000Z + + + [bitcoin-dev] " Jeremy + 2022-01-28T17:21:00.000Z + + + Jeremy Rubin + 2022-01-28T19:38:00.000Z + + + Alex Schoof + 2022-01-28T21:14:00.000Z + + + Lloyd Fournier + 2022-02-06T07:18:00.000Z + + + Jeremy Rubin + 2022-02-06T17:56:00.000Z + + + Thibaut Le Guilly + 2022-02-07T02:30:00.000Z + + + Jeremy Rubin + 2022-03-15T17:28:00.000Z + + @@ -35,13 +58,13 @@ - python-feedgen + 2 Combined summary - CTV dramatically improves DLCs - 2023-08-02T05:25:02.224690+00:00 + 2025-09-26T14:40:43.767126+00:00 - Jeremy has developed a prototype of a protocol in Sapio and shared the link to it on GitHub. He invites others to test and tweak the protocol using the provided benchmark. Jeremy tested one oracle with 100,000 different payouts and observed it taking around 13 seconds on a release build. He intends to experiment more with the protocol, but acknowledges that Sapio Studio may not be able to handle a GUI for 100,000 nodes.In a discussion thread, several points were raised regarding the use of CSFS and its effectiveness in providing privacy benefits. It was noted that while CSFS could be used in both the oracle and transaction restriction parts of the DLC, it does not provide the same model as DLC. Additionally, there was discussion about the performance benefits of the CTV approach, which allows for computation of oracle anticipation points without signing or verification. A benchmark comparison was made between the current approach with signing and verification and only computing the anticipation points, resulting in a performance improvement of roughly 24x for the serial case and 10x for the parallel case. The benchmarks are available on GitHub. One potential concern raised was the impact of having a large taproot tree on the size of witness data when spending script paths that are low in the tree and how it would affect transaction fees. Finally, there was a discussion about the Y axis being the dependent variable represented by the CTV hashes in a contract, and how this affects the cheaper part of the DLC in lightning channels that might be updated between parties frequently.The email exchange discusses the benefits and features of Discreet Log Contracts (DLCs) with CheckTemplateVerify (CTV). The author explains that CTV enables a trustless timeout branch, which can have a failover claim that returns funds to both sides. Additionally, CTV DLCs are non-interactive asynchronously third-party unilaterally creatable, which means it is possible for a single party to create a DLC on behalf of another user. This enables use cases like pay-to-DLC addresses, which can also be constructed and sent to a third party service to create DLCs without requiring the third party service to do anything other than make the payment as requested.The email also discusses how CTV DLCs can be composed in interesting ways. Options over DLCs open up many exciting types of instrument where Alice can create an option expiring in 1 week where Bob can add funds to pay a premium and "Open" a DLC on an outcome closing in 1 year. There are also opportunities for perpetual-like contracts where you could combine into one logical DLC 12 DLCs closing 1 per month that can either be paid out all at once at the end of the year or profit pulled out partially at any time earlier.Lastly, the email mentions an additional performance improvement that can be had for iterative DLCs in Lightning where you might trade over a fixed set of attestation points with variable payout curves. However, the author is not entirely clear on what is meant concretely by this. Overall, the discussion highlights the potential benefits and uses of CTV DLCs.The email thread discusses the benefits of using OP_CTV with Discreet Log Contracts (DLCs) on the Bitcoin network. OP_CTV simplifies and improves the performance of DLCs by enabling non-interactive asynchronously third-party unilaterally creatable contracts. With this, each party can compute all outcomes on their own in parallel, making multi-party DLCs easier to execute. Additionally, OP_CTV enables a "trustless timeout" branch where failover claims return funds to both sides, and DLCs can be composed in interesting ways. For example, Options over DLCs can be created, perpetual-like contracts can be combined, and iterative DLCs can be traded over a fixed set of attestation points with variable payout curves. Lastly, OP_CTV allows for pay-to-DLC addresses to be constructed and sent to third-party services, enabling the creation of DLCs without requiring the service to do anything other than make the payment as requested.Jeremy Rubin proposes a way to make the close portion of a DLC be an "optimistic" execution with a choice of justice scheme, enabling closing a DLC somewhat securely without exposing the oracles on-chain at all. Assuming honest oracles, the only cost of this mechanism over previous is that you have to do a script path spend (but it can be a top-level branch, since it's the "most likely" one). For every DLC branch add two branches allowing Alice or Bob to "lock in" a redemption of the contract that becomes spendable by them after CET-hash-* should include a nLockTime/nSequence such that it is at the same time as the attestation points should be known. Justice with punishment seems to be the better option since T is actively choosing this resolution (the CTV transition is signed), but justice with no punishment might be better if one thinks the oracles might collude to steal. 2022-03-15T17:28:05+00:00 + Jeremy has developed a prototype of a protocol in Sapio and shared the link to it on GitHub. He invites others to test and tweak the protocol using the provided benchmark. Jeremy tested one oracle with 100,000 different payouts and observed it taking around 13 seconds on a release build. He intends to experiment more with the protocol, but acknowledges that Sapio Studio may not be able to handle a GUI for 100,000 nodes.In a discussion thread, several points were raised regarding the use of CSFS and its effectiveness in providing privacy benefits. It was noted that while CSFS could be used in both the oracle and transaction restriction parts of the DLC, it does not provide the same model as DLC. Additionally, there was discussion about the performance benefits of the CTV approach, which allows for computation of oracle anticipation points without signing or verification. A benchmark comparison was made between the current approach with signing and verification and only computing the anticipation points, resulting in a performance improvement of roughly 24x for the serial case and 10x for the parallel case. The benchmarks are available on GitHub. One potential concern raised was the impact of having a large taproot tree on the size of witness data when spending script paths that are low in the tree and how it would affect transaction fees. Finally, there was a discussion about the Y axis being the dependent variable represented by the CTV hashes in a contract, and how this affects the cheaper part of the DLC in lightning channels that might be updated between parties frequently.The email exchange discusses the benefits and features of Discreet Log Contracts (DLCs) with CheckTemplateVerify (CTV). The author explains that CTV enables a trustless timeout branch, which can have a failover claim that returns funds to both sides. Additionally, CTV DLCs are non-interactive asynchronously third-party unilaterally creatable, which means it is possible for a single party to create a DLC on behalf of another user. This enables use cases like pay-to-DLC addresses, which can also be constructed and sent to a third party service to create DLCs without requiring the third party service to do anything other than make the payment as requested.The email also discusses how CTV DLCs can be composed in interesting ways. Options over DLCs open up many exciting types of instrument where Alice can create an option expiring in 1 week where Bob can add funds to pay a premium and "Open" a DLC on an outcome closing in 1 year. There are also opportunities for perpetual-like contracts where you could combine into one logical DLC 12 DLCs closing 1 per month that can either be paid out all at once at the end of the year or profit pulled out partially at any time earlier.Lastly, the email mentions an additional performance improvement that can be had for iterative DLCs in Lightning where you might trade over a fixed set of attestation points with variable payout curves. However, the author is not entirely clear on what is meant concretely by this. Overall, the discussion highlights the potential benefits and uses of CTV DLCs.The email thread discusses the benefits of using OP_CTV with Discreet Log Contracts (DLCs) on the Bitcoin network. OP_CTV simplifies and improves the performance of DLCs by enabling non-interactive asynchronously third-party unilaterally creatable contracts. With this, each party can compute all outcomes on their own in parallel, making multi-party DLCs easier to execute. Additionally, OP_CTV enables a "trustless timeout" branch where failover claims return funds to both sides, and DLCs can be composed in interesting ways. For example, Options over DLCs can be created, perpetual-like contracts can be combined, and iterative DLCs can be traded over a fixed set of attestation points with variable payout curves. Lastly, OP_CTV allows for pay-to-DLC addresses to be constructed and sent to third-party services, enabling the creation of DLCs without requiring the service to do anything other than make the payment as requested.Jeremy Rubin proposes a way to make the close portion of a DLC be an "optimistic" execution with a choice of justice scheme, enabling closing a DLC somewhat securely without exposing the oracles on-chain at all. Assuming honest oracles, the only cost of this mechanism over previous is that you have to do a script path spend (but it can be a top-level branch, since it's the "most likely" one). For every DLC branch add two branches allowing Alice or Bob to "lock in" a redemption of the contract that becomes spendable by them after CET-hash-* should include a nLockTime/nSequence such that it is at the same time as the attestation points should be known. Justice with punishment seems to be the better option since T is actively choosing this resolution (the CTV transition is signed), but justice with no punishment might be better if one thinks the oracles might collude to steal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml b/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml index bc8cb0e99b..fb66bb5e13 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Decentralized BIP 47 payment code directory - 2023-08-02T05:45:48.056713+00:00 + 2025-09-26T14:40:41.649915+00:00 + python-feedgen Prayank 2022-03-02 04:45:58+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Decentralized BIP 47 payment code directory - 2023-08-02T05:45:48.056713+00:00 + 2025-09-26T14:40:41.650037+00:00 - In a conversation between Peter and Prayank, Prayank introduces a newer version (v3 and v4) of BIP47, which has been proposed on GitHub. This version aims to solve the toxic change issue and seems like an improvement. Prayank explains that using an xpub does not provide anonymity because anyone who has access to the xpub, including platforms or hackers, can identify one's payments. However, using a payment code allows for public association without revealing the payment identifier on the blockchain, making it difficult for others to determine if funds have been received. Prayank also suggests a rust library that can assist application developers in implementing BIP47 into different bitcoin projects.The OpenBitcoinPrivacyProject has proposed a newer version of BIP47, v3 and v4, which addresses certain issues present in the previous version. The new version eliminates the toxic change issue by modifying the notification from Alice to Bob as a transaction from Alice to herself, functioning as a bare 1 of 3 multisig. Two pubkeys represent Alice's payment code and Bob's payment identifier. This change incurs a one-time overhead of 64 bytes for the two pubkeys, which is spread out over the lifespan of the relationship between Alice and Bob. Additionally, the first economic payment from Alice to Bob can be included with the notification transaction. Payment codes can be recovered from the bip32 seed without requiring extra backups. The new version is already being used in production with Samourai wallet. BIP47 v3 enables Alice to receive Bob's address without exposing her IP/identity to Charlie. Charlie can observe Alice receiving the payment code material from Bob but cannot determine if Alice proceeded to make a payment to Bob. Unlike an xpub, this method ensures privacy even if the xpub is shared with a crowdfunding platform, as the platform or any potential hackers cannot identify the payments made by Alice. By using the payment code, individuals can publicly associate themselves with their payment code without revealing if they have received funds, as the payment code is not visible on the blockchain.Twitter has seen discussions about BIP47 and its potential to enhance privacy. However, some developers argue that it merely adds spam to the Bitcoin network without providing any actual improvements. Additionally, the only existing implementation of BIP47 is Paynym, a centralized payment code directory managed by Samourai wallet, raising concerns regarding privacy and security. To address these concerns, the author suggests utilizing TXT records and domains. They present a proof of concept using GNS (GNU Name Service) to create a payment code for Alice, adding it as a TXT record with an expiry date, and verifying it. The author also proposes using `gnunet-publish` as a replacement for notification transactions. These solutions could potentially help users avoid sharing their bitcoin addresses on social media platforms when receiving donations. In addition to these suggestions, the author provides links to related resources, including a Q&A on accepting donations correctly and a new proposal addressing privacy concerns. 2022-03-02T04:45:58+00:00 + In a conversation between Peter and Prayank, Prayank introduces a newer version (v3 and v4) of BIP47, which has been proposed on GitHub. This version aims to solve the toxic change issue and seems like an improvement. Prayank explains that using an xpub does not provide anonymity because anyone who has access to the xpub, including platforms or hackers, can identify one's payments. However, using a payment code allows for public association without revealing the payment identifier on the blockchain, making it difficult for others to determine if funds have been received. Prayank also suggests a rust library that can assist application developers in implementing BIP47 into different bitcoin projects.The OpenBitcoinPrivacyProject has proposed a newer version of BIP47, v3 and v4, which addresses certain issues present in the previous version. The new version eliminates the toxic change issue by modifying the notification from Alice to Bob as a transaction from Alice to herself, functioning as a bare 1 of 3 multisig. Two pubkeys represent Alice's payment code and Bob's payment identifier. This change incurs a one-time overhead of 64 bytes for the two pubkeys, which is spread out over the lifespan of the relationship between Alice and Bob. Additionally, the first economic payment from Alice to Bob can be included with the notification transaction. Payment codes can be recovered from the bip32 seed without requiring extra backups. The new version is already being used in production with Samourai wallet. BIP47 v3 enables Alice to receive Bob's address without exposing her IP/identity to Charlie. Charlie can observe Alice receiving the payment code material from Bob but cannot determine if Alice proceeded to make a payment to Bob. Unlike an xpub, this method ensures privacy even if the xpub is shared with a crowdfunding platform, as the platform or any potential hackers cannot identify the payments made by Alice. By using the payment code, individuals can publicly associate themselves with their payment code without revealing if they have received funds, as the payment code is not visible on the blockchain.Twitter has seen discussions about BIP47 and its potential to enhance privacy. However, some developers argue that it merely adds spam to the Bitcoin network without providing any actual improvements. Additionally, the only existing implementation of BIP47 is Paynym, a centralized payment code directory managed by Samourai wallet, raising concerns regarding privacy and security. To address these concerns, the author suggests utilizing TXT records and domains. They present a proof of concept using GNS (GNU Name Service) to create a payment code for Alice, adding it as a TXT record with an expiry date, and verifying it. The author also proposes using `gnunet-publish` as a replacement for notification transactions. These solutions could potentially help users avoid sharing their bitcoin addresses on social media platforms when receiving donations. In addition to these suggestions, the author provides links to related resources, including a Q&A on accepting donations correctly and a new proposal addressing privacy concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Documenting-the-lifetime-of-a-transaction-during-mempool-congestion-from-the-perspective-of-a-rational-user.xml b/static/bitcoin-dev/Feb_2022/combined_Documenting-the-lifetime-of-a-transaction-during-mempool-congestion-from-the-perspective-of-a-rational-user.xml index 2be0dbda30..6b72f09cee 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Documenting-the-lifetime-of-a-transaction-during-mempool-congestion-from-the-perspective-of-a-rational-user.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Documenting-the-lifetime-of-a-transaction-during-mempool-congestion-from-the-perspective-of-a-rational-user.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user - 2023-08-02T05:23:10.793023+00:00 - - Billy Tetrud 2022-02-26 05:35:51+00:00 - - - Jeremy 2022-01-13 21:06:37+00:00 - + 2025-09-26T14:41:05.149019+00:00 + python-feedgen + + + [bitcoin-dev] Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user Jeremy + 2022-01-13T21:06:00.000Z + + + Billy Tetrud + 2022-02-26T05:35:00.000Z + + - python-feedgen + 2 Combined summary - Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user - 2023-08-02T05:23:10.793023+00:00 + 2025-09-26T14:41:05.149497+00:00 - In this email, Jeremy Rubin discusses existing wallet behaviors and user preferences in Bitcoin, focusing on rational wallet behavior. The author argues that rational wallets should prioritize spending untrusted outputs to guarantee payment, free of cost, by using Child Pays For Parent (CPFP) mechanism to push transactions to the top of the mempool. Wallets should also track replaced payments and prevent double-spending.The author emphasizes the importance of clear messaging around transaction finalization to solve problems more easily. They also mention the significance of saving all ancestors and descendants of transactions to maximize balance and receive "free" CPFP subsidies. Wallet agents are advised to retransmit transactions if they believe other nodes are not aware of them and they are likely to go into a block.Certain wallets, like Lightning Channels, already have some of this functionality built-in. However, congestion control using Check Transaction Verify (CTV) does not complicate wallet behavior but rather helps solve existing problems by reducing the need for rational behavior like CPFP bumping. In a full mempool scenario, exchanges that batch transactions can confirm a constant-sized root transaction, and sub-trees of transactions locked in by CTV can be treated as fully trusted. This reduces the need for CPFP bumping and exerts back pressure on transaction urgency.The email primarily focuses on existing wallet behaviors and user preferences, rather than on CTV. The author defines rational wallet behavior as maximizing fully trusted balance, processing payments within the urgency budget, and maximizing privacy. It is suggested that rational wallet behavior may require additional metadata, such as trust scores or recent hashrate data.Overall, the email highlights the rational behaviors for wallets in various payment scenarios and discusses the reasons why some of these behaviors are not currently implemented. The author suggests that with the development of a more robust fee market, rational behaviors will likely become emergent among all Bitcoin wallets. Finally, the author addresses the relevance of CTV congestion control in solving existing wallet architecture problems, arguing that it can help reduce the need for rational behaviors like CPFP bumping and improve time-preference in on-chain resolution. 2022-02-26T05:35:51+00:00 + In this email, Jeremy Rubin discusses existing wallet behaviors and user preferences in Bitcoin, focusing on rational wallet behavior. The author argues that rational wallets should prioritize spending untrusted outputs to guarantee payment, free of cost, by using Child Pays For Parent (CPFP) mechanism to push transactions to the top of the mempool. Wallets should also track replaced payments and prevent double-spending.The author emphasizes the importance of clear messaging around transaction finalization to solve problems more easily. They also mention the significance of saving all ancestors and descendants of transactions to maximize balance and receive "free" CPFP subsidies. Wallet agents are advised to retransmit transactions if they believe other nodes are not aware of them and they are likely to go into a block.Certain wallets, like Lightning Channels, already have some of this functionality built-in. However, congestion control using Check Transaction Verify (CTV) does not complicate wallet behavior but rather helps solve existing problems by reducing the need for rational behavior like CPFP bumping. In a full mempool scenario, exchanges that batch transactions can confirm a constant-sized root transaction, and sub-trees of transactions locked in by CTV can be treated as fully trusted. This reduces the need for CPFP bumping and exerts back pressure on transaction urgency.The email primarily focuses on existing wallet behaviors and user preferences, rather than on CTV. The author defines rational wallet behavior as maximizing fully trusted balance, processing payments within the urgency budget, and maximizing privacy. It is suggested that rational wallet behavior may require additional metadata, such as trust scores or recent hashrate data.Overall, the email highlights the rational behaviors for wallets in various payment scenarios and discusses the reasons why some of these behaviors are not currently implemented. The author suggests that with the development of a more robust fee market, rational behaviors will likely become emergent among all Bitcoin wallets. Finally, the author addresses the relevance of CTV congestion control in solving existing wallet architecture problems, arguing that it can help reduce the need for rational behaviors like CPFP bumping and improve time-preference in on-chain resolution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Draft-BIP-Ordinal-Numbers.xml b/static/bitcoin-dev/Feb_2022/combined_Draft-BIP-Ordinal-Numbers.xml index 7a418d4429..a2fef913ef 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Draft-BIP-Ordinal-Numbers.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Draft-BIP-Ordinal-Numbers.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Draft-BIP: Ordinal Numbers - 2023-08-02T05:43:09.503765+00:00 - - Billy Tetrud 2022-02-25 15:56:24+00:00 - - - AdamISZ 2022-02-25 11:17:29+00:00 - - - Billy Tetrud 2022-02-25 04:59:56+00:00 - - - Casey Rodarmor 2022-02-24 21:03:54+00:00 - - - Casey Rodarmor 2022-02-24 21:02:05+00:00 - - - vjudeu at gazeta.pl 2022-02-24 17:52:39+00:00 - - - Billy Tetrud 2022-02-24 15:55:57+00:00 - - - Casey Rodarmor 2022-02-24 07:17:02+00:00 - - - vjudeu at gazeta.pl 2022-02-24 07:02:06+00:00 - - - damian at willtech.com.au 2022-02-24 02:34:39+00:00 - - - Casey Rodarmor 2022-02-23 07:31:49+00:00 - - - damian at willtech.com.au 2022-02-23 07:24:52+00:00 - - - Casey Rodarmor 2022-02-23 07:10:58+00:00 - - - damian at willtech.com.au 2022-02-23 07:02:03+00:00 - - - Casey Rodarmor 2022-02-23 00:43:52+00:00 - + 2025-09-26T14:41:07.291853+00:00 + python-feedgen + + + [bitcoin-dev] Draft-BIP: Ordinal Numbers Casey Rodarmor + 2022-02-23T00:43:00.000Z + + + damian + 2022-02-23T07:02:00.000Z + + + Casey Rodarmor + 2022-02-23T07:10:00.000Z + + + damian + 2022-02-23T07:24:00.000Z + + + Casey Rodarmor + 2022-02-23T07:31:00.000Z + + + damian + 2022-02-24T02:34:00.000Z + + + vjudeu + 2022-02-24T07:02:00.000Z + + + Casey Rodarmor + 2022-02-24T07:17:00.000Z + + + Billy Tetrud + 2022-02-24T15:55:00.000Z + + + vjudeu + 2022-02-24T17:52:00.000Z + + + Casey Rodarmor + 2022-02-24T21:02:00.000Z + + + Casey Rodarmor + 2022-02-24T21:03:00.000Z + + + Billy Tetrud + 2022-02-25T04:59:00.000Z + + + AdamISZ + 2022-02-25T11:17:00.000Z + + + Billy Tetrud + 2022-02-25T15:56:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Draft-BIP: Ordinal Numbers - 2023-08-02T05:43:09.503765+00:00 + 2025-09-26T14:41:07.293688+00:00 - In a recent discussion, the possibility of hiding coin amounts in Bitcoin was brought up. However, it was pointed out that such a move would make it impossible to audit the blockchain and verify inflation levels. The speaker believes that Bitcoin is unlikely to adopt this feature, as it would remove unconditional soundness from the system and replace it with computational soundness. Even if Bitcoin were to adopt amount hiding, it would still maintain backward compatibility with old style addresses.There is also discussion about increasing payment precision by going sub-satoshi on chain. This could be extended to ordinals through the use of fraction ordinals like 1.1 or 4.85. While a concrete proposal is not yet possible, the idea is being explored. Additionally, there is discussion around the use of duplicate transaction IDs, which was once possible but is now prevented by the BIP 34 soft fork. The need for this rule is explained in more detail in the BIP.In the context mentioned, there is a concern regarding the use of ordinal numbers in future improvements. The issue arises if and when a Monero-like system is introduced where coin amounts are hidden. To make such a system backward-compatible, zero satoshi may be used as a substitute for hidden values. Zero satoshi has the advantage of bypassing the amount checking for old clients, which can be useful for introducing new protocols and adding fractional satoshis on-chain. However, if these amounts are simply ignored, it would be difficult to connect any future protocol based on that with ordinal numbers.The proposal aims to use dust for valuable purposes, instead of reducing its creation. The idea is to split dust into its unit satoshis and use them for NFTs or colored coins. The proposal has received positive feedback, with one person suggesting that having a standard would be better than everyone doing their own thing. However, there are concerns about what happens when payment precision increases by going sub-satoshi on chain. The proposal also mentions the issue of stolen bitcoins and blacklisted coins, which the proposal does not address. Finally, the question is raised about using zero satoshis for NFTs but not colored coins.In a recent discussion on the bitcoin-dev mailing list, the practicality of numbering each satoshi created was questioned. The potential cost of implementing a system to handle the large number of ordinal numbers that would result from numbering each satoshi was a concern. The process of assigning ordinals was explained, where newly mined satoshis are sequentially numbered and assigned as ordinal numbers. When satoshis are spent in a transaction, the input satoshi ordinal numbers are assigned to output satoshis using a first-in-first-out algorithm. Despite the simplicity of the process, the potential expense of the system was noted.The writer of the context believes that not all people who have been stolen from lose their right and title to what was stolen. They believe that it is not the responsibility of an ordinal to determine if a satoshi is fungible or not. The BIP states that transferred ordinals should be considered fungible with other satoshis with no public history. It is unlikely that a previous owner of an ordinal would have any particular reason to expect ownership after they transfer it.The conversation discusses how Bitcoin assigns ordinal numbers to each Satoshi created and how these numbers are determined when BTC is transferred to another UTXO. The system uses a first-in-first-out algorithm, with the first ordinal number of the first input becoming the first ordinal number of the first output. While a full index can be expensive, it only needs to track contiguous ordinal ranges, which scales with the number of outputs. The potential challenges associated with numbering each satoshi and determining which ordinal numbers are being transferred were raised.A scheme called Ordinal Numbers has been proposed for numbering and tracking satoshis across Bitcoin transactions. This scheme assigns ordinal numbers to each satoshi in the order it is mined and can be used for various applications such as NFTs, reputation systems, and Lightning Network-compatible stablecoins. The process of assigning ordinal numbers was explained, where newly mined satoshis are sequentially numbered and assigned as ordinal numbers. The use of ordinal numbers allows for the transfer of digital assets and has potential applications in account and authentication schemes, colored coin schemes, reputation systems, and voting rights for DAOs.In conclusion, the discussions revolve around potential changes to the Bitcoin system, including the possibility of hiding coin amounts and increasing payment precision. There are concerns about the impact on auditing the blockchain and verifying inflation levels. The use of ordinal numbers for tracking satoshis and its potential applications are also explored. While there are challenges and considerations to be addressed, the proposal shows promise in enhancing the functionality and versatility of Bitcoin. 2022-02-25T15:56:24+00:00 + In a recent discussion, the possibility of hiding coin amounts in Bitcoin was brought up. However, it was pointed out that such a move would make it impossible to audit the blockchain and verify inflation levels. The speaker believes that Bitcoin is unlikely to adopt this feature, as it would remove unconditional soundness from the system and replace it with computational soundness. Even if Bitcoin were to adopt amount hiding, it would still maintain backward compatibility with old style addresses.There is also discussion about increasing payment precision by going sub-satoshi on chain. This could be extended to ordinals through the use of fraction ordinals like 1.1 or 4.85. While a concrete proposal is not yet possible, the idea is being explored. Additionally, there is discussion around the use of duplicate transaction IDs, which was once possible but is now prevented by the BIP 34 soft fork. The need for this rule is explained in more detail in the BIP.In the context mentioned, there is a concern regarding the use of ordinal numbers in future improvements. The issue arises if and when a Monero-like system is introduced where coin amounts are hidden. To make such a system backward-compatible, zero satoshi may be used as a substitute for hidden values. Zero satoshi has the advantage of bypassing the amount checking for old clients, which can be useful for introducing new protocols and adding fractional satoshis on-chain. However, if these amounts are simply ignored, it would be difficult to connect any future protocol based on that with ordinal numbers.The proposal aims to use dust for valuable purposes, instead of reducing its creation. The idea is to split dust into its unit satoshis and use them for NFTs or colored coins. The proposal has received positive feedback, with one person suggesting that having a standard would be better than everyone doing their own thing. However, there are concerns about what happens when payment precision increases by going sub-satoshi on chain. The proposal also mentions the issue of stolen bitcoins and blacklisted coins, which the proposal does not address. Finally, the question is raised about using zero satoshis for NFTs but not colored coins.In a recent discussion on the bitcoin-dev mailing list, the practicality of numbering each satoshi created was questioned. The potential cost of implementing a system to handle the large number of ordinal numbers that would result from numbering each satoshi was a concern. The process of assigning ordinals was explained, where newly mined satoshis are sequentially numbered and assigned as ordinal numbers. When satoshis are spent in a transaction, the input satoshi ordinal numbers are assigned to output satoshis using a first-in-first-out algorithm. Despite the simplicity of the process, the potential expense of the system was noted.The writer of the context believes that not all people who have been stolen from lose their right and title to what was stolen. They believe that it is not the responsibility of an ordinal to determine if a satoshi is fungible or not. The BIP states that transferred ordinals should be considered fungible with other satoshis with no public history. It is unlikely that a previous owner of an ordinal would have any particular reason to expect ownership after they transfer it.The conversation discusses how Bitcoin assigns ordinal numbers to each Satoshi created and how these numbers are determined when BTC is transferred to another UTXO. The system uses a first-in-first-out algorithm, with the first ordinal number of the first input becoming the first ordinal number of the first output. While a full index can be expensive, it only needs to track contiguous ordinal ranges, which scales with the number of outputs. The potential challenges associated with numbering each satoshi and determining which ordinal numbers are being transferred were raised.A scheme called Ordinal Numbers has been proposed for numbering and tracking satoshis across Bitcoin transactions. This scheme assigns ordinal numbers to each satoshi in the order it is mined and can be used for various applications such as NFTs, reputation systems, and Lightning Network-compatible stablecoins. The process of assigning ordinal numbers was explained, where newly mined satoshis are sequentially numbered and assigned as ordinal numbers. The use of ordinal numbers allows for the transfer of digital assets and has potential applications in account and authentication schemes, colored coin schemes, reputation systems, and voting rights for DAOs.In conclusion, the discussions revolve around potential changes to the Bitcoin system, including the possibility of hiding coin amounts and increasing payment precision. There are concerns about the impact on auditing the blockchain and verifying inflation levels. The use of ordinal numbers for tracking satoshis and its potential applications are also explored. While there are challenges and considerations to be addressed, the proposal shows promise in enhancing the functionality and versatility of Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Improving-RBF-Policy.xml b/static/bitcoin-dev/Feb_2022/combined_Improving-RBF-Policy.xml index f8c7d924e4..5a04c55407 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Improving-RBF-Policy.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Improving-RBF-Policy.xml @@ -1,68 +1,111 @@ - + 2 Combined summary - Improving RBF Policy - 2023-08-02T05:30:18.072198+00:00 - - Billy Tetrud 2022-03-17 15:59:11+00:00 - - - Antoine Riard 2022-03-17 02:02:30+00:00 - - - Billy Tetrud 2022-03-15 01:43:31+00:00 - - - Gloria Zhao 2022-03-14 10:29:16+00:00 - - - Billy Tetrud 2022-03-12 08:18:39+00:00 - - - Billy Tetrud 2022-03-11 16:22:07+00:00 - - - Gloria Zhao 2022-03-09 15:09:55+00:00 - - - lisa neigut 2022-02-09 17:57:59+00:00 - - - Anthony Towns 2022-02-08 04:58:50+00:00 - - - Gloria Zhao 2022-02-07 11:16:26+00:00 - - - Bastien TEINTURIER 2022-02-07 10:22:01+00:00 - - - Michael Folkson 2022-02-05 13:21:57+00:00 - - - Anthony Towns 2022-02-02 10:21:16+00:00 - - - Bastien TEINTURIER 2022-02-01 09:30:12+00:00 - - - Prayank 2022-02-01 02:47:18+00:00 - - - Anthony Towns 2022-02-01 01:56:37+00:00 - - - Bastien TEINTURIER 2022-01-31 15:57:52+00:00 - - - Antoine Riard 2022-01-30 22:53:32+00:00 - - - Jeremy 2022-01-28 01:35:11+00:00 - - - Gloria Zhao 2022-01-27 13:42:09+00:00 - + 2025-09-26T14:40:52.396851+00:00 + python-feedgen + + + [bitcoin-dev] Improving RBF Policy Gloria Zhao + 2022-01-27T13:42:00.000Z + + + Jeremy + 2022-01-28T01:35:00.000Z + + + Antoine Riard + 2022-01-30T22:53:00.000Z + + + Bastien TEINTURIER + 2022-01-31T15:57:00.000Z + + + [bitcoin-dev] Improving RBF policy Bram Cohen + 2022-01-31T22:54:00.000Z + + + Eric Voskuil + 2022-02-01T00:08:00.000Z + + + Antoine Riard + 2022-02-01T00:42:00.000Z + + + Anthony Towns + 2022-02-01T01:56:00.000Z + + + [bitcoin-dev] Improving RBF Policy Prayank + 2022-02-01T02:47:00.000Z + + + Bram Cohen + 2022-02-01T08:32:00.000Z + + + Bastien TEINTURIER + 2022-02-01T09:30:00.000Z + + + Eric Voskuil + 2022-02-01T19:44:00.000Z + + + Anthony Towns + 2022-02-02T10:21:00.000Z + + + Michael Folkson + 2022-02-05T13:21:00.000Z + + + Bastien TEINTURIER + 2022-02-07T10:22:00.000Z + + + Gloria Zhao + 2022-02-07T11:16:00.000Z + + + Anthony Towns + 2022-02-08T04:58:00.000Z + + + lisa neigut + 2022-02-09T17:57:00.000Z + + + Gloria Zhao + 2022-03-09T15:09:00.000Z + + + Billy Tetrud + 2022-03-11T16:22:00.000Z + + + Billy Tetrud + 2022-03-12T08:18:00.000Z + + + Gloria Zhao + 2022-03-14T10:29:00.000Z + + + Billy Tetrud + 2022-03-15T01:43:00.000Z + + + Antoine Riard + 2022-03-17T02:02:00.000Z + + + Billy Tetrud + 2022-03-17T15:59:00.000Z + + @@ -83,13 +126,13 @@ - python-feedgen + 2 Combined summary - Improving RBF Policy - 2023-08-02T05:30:18.072198+00:00 + 2025-09-26T14:40:52.399406+00:00 - In recent discussions among Bitcoin developers, proposals have been made to improve the Replace-by-Fee (RBF) policies in the mempool. The goal is to address limitations and potential vulnerabilities of the current rules. One suggestion is to implement transaction relay rate limiting with a feerate-based priority queue and staggered broadcast of replacement transactions. This would prioritize transactions based on their likelihood of being included in a block.Another proposal is to allow users to specify descendant limits on their transactions, which would help solve the pinning problem associated with package RBF attacks.There has also been discussion around the concept of "mining score" as a way to prioritize transactions. The mining score would be calculated based on the ancestor feerate at which a transaction is included in a block. It is suggested that this mining score could be used as the priority value for transaction relay if a rate-limited priority queue is implemented.Some concerns have been raised about the potential downsides of these proposals, but they have generally been well-received and open for feedback. The overall objective is to prevent Denial-of-Service (DoS) attacks while maintaining the fee-rate relay rule that already mitigates spam.The conversation also touches on the idea of excluding low fee transactions from being relayed and included in blocks. While there are concerns about missing out on good fees, it is noted that this approach is a special case and other factors need to be considered, such as trusting that a lower fee transaction won't replace a higher fee transaction and the number of transactions bidding for a spot in the next block.Rate limiting is already done via INVENTORY_BROADCAST_MAX and *_INVENTORY_BROADCAST_INTERVAL, but an alternative approach suggested is to track the "effective fee rate" to better manage the ancestor fee rate. This could be achieved through candidate set blockbuilding ideas.Furthermore, there has been discussion about keeping high-feerate evicted transactions in the mempool in case they get mined by someone else, which could improve compact block relay. However, concerns have been raised about the sufficiency of the 100 transaction LRU cache and the possibility of applying rate limits only to replacement transactions.Lastly, there is a suggestion to have a split between mempool acceptance rules and spam prevention rules. This would allow transactions to be sent to miners through an alternate route if they are blocked by anti-spam rules.Overall, the discussions focus on improving the RBF policies in Bitcoin's transaction relay system to address limitations, prevent DoS attacks, and ensure a fair and efficient fee-based transaction prioritization.In another discussion, participants considered whether or not descendants matter for miner incentives. The group also discussed policies to address miner incentives and DoS issues, such as requiring certain percentage increases in ancestor absolute fees and feerates. The conversation highlights the need for improved security and more efficient use of resources in multi-party contracts built on top of Bitcoin.Bastien Teinturier proposes new rules for replacing transactions that prioritize DoS protection and incentive compatibility. He suggests separating policies that address miner incentives from policies that address DoS issues and adding a third policy to specifically address DoS concerns. He also discusses the timeline for implementing updated policies and potential vulnerabilities in multi-party contracts due to reliance on policies that cannot be enforced.Another member of the mailing list suggests relay rate limiting and prioritizing by ancestor fee rate as a way to discourage people from wasting network bandwidth. This proposal aims to address the issue of publishing transactions that will never get confirmed while still ensuring incentive compatibility. They also discuss the importance of having a path that follows the new relay rules and gets support from a significant portion of hashpower.The post delves into the discussion of improving Bitcoin's Replace-by-Fee (RBF) feature in transactions. Developer Jeremy Rubin proposes several changes to address issues and potential attacks. These changes involve removing rules that require higher fees, preventing pinning attacks, and creating a more user-friendly interface for fee bumping transactions. Rubin also discusses models for transaction validation rate-limiting and enhancing the mining score of mempool transactions.The author introduces a new rule called the "feerate-based" rule, which aims to replace transactions in the mempool. This approach entails calculating conflicting transactions and their descendants, identifying original transactions for inclusion in the next block, and ensuring replacements pay at least the same amount plus a certain percentage in absolute fees. Replacements must also have a higher feerate than the maximum mining score of remaining transactions in the mempool after the next block. The proposal suggests utilizing TBD constants to limit the number of replacements allowed with specific fees.Various implementation options for the feerate-based replacement rule are discussed, including dynamic block templates, cached block templates, or dividing the mempool into different feerate layers. Throughout the document, links to relevant pull requests, issues, and discussions are provided for further context. However, the author emphasizes that more discussion is needed to improve the RBF policy.The post also addresses topics like DoS protection, iterative 2022-03-17T15:59:11+00:00 + In recent discussions among Bitcoin developers, proposals have been made to improve the Replace-by-Fee (RBF) policies in the mempool. The goal is to address limitations and potential vulnerabilities of the current rules. One suggestion is to implement transaction relay rate limiting with a feerate-based priority queue and staggered broadcast of replacement transactions. This would prioritize transactions based on their likelihood of being included in a block.Another proposal is to allow users to specify descendant limits on their transactions, which would help solve the pinning problem associated with package RBF attacks.There has also been discussion around the concept of "mining score" as a way to prioritize transactions. The mining score would be calculated based on the ancestor feerate at which a transaction is included in a block. It is suggested that this mining score could be used as the priority value for transaction relay if a rate-limited priority queue is implemented.Some concerns have been raised about the potential downsides of these proposals, but they have generally been well-received and open for feedback. The overall objective is to prevent Denial-of-Service (DoS) attacks while maintaining the fee-rate relay rule that already mitigates spam.The conversation also touches on the idea of excluding low fee transactions from being relayed and included in blocks. While there are concerns about missing out on good fees, it is noted that this approach is a special case and other factors need to be considered, such as trusting that a lower fee transaction won't replace a higher fee transaction and the number of transactions bidding for a spot in the next block.Rate limiting is already done via INVENTORY_BROADCAST_MAX and *_INVENTORY_BROADCAST_INTERVAL, but an alternative approach suggested is to track the "effective fee rate" to better manage the ancestor fee rate. This could be achieved through candidate set blockbuilding ideas.Furthermore, there has been discussion about keeping high-feerate evicted transactions in the mempool in case they get mined by someone else, which could improve compact block relay. However, concerns have been raised about the sufficiency of the 100 transaction LRU cache and the possibility of applying rate limits only to replacement transactions.Lastly, there is a suggestion to have a split between mempool acceptance rules and spam prevention rules. This would allow transactions to be sent to miners through an alternate route if they are blocked by anti-spam rules.Overall, the discussions focus on improving the RBF policies in Bitcoin's transaction relay system to address limitations, prevent DoS attacks, and ensure a fair and efficient fee-based transaction prioritization.In another discussion, participants considered whether or not descendants matter for miner incentives. The group also discussed policies to address miner incentives and DoS issues, such as requiring certain percentage increases in ancestor absolute fees and feerates. The conversation highlights the need for improved security and more efficient use of resources in multi-party contracts built on top of Bitcoin.Bastien Teinturier proposes new rules for replacing transactions that prioritize DoS protection and incentive compatibility. He suggests separating policies that address miner incentives from policies that address DoS issues and adding a third policy to specifically address DoS concerns. He also discusses the timeline for implementing updated policies and potential vulnerabilities in multi-party contracts due to reliance on policies that cannot be enforced.Another member of the mailing list suggests relay rate limiting and prioritizing by ancestor fee rate as a way to discourage people from wasting network bandwidth. This proposal aims to address the issue of publishing transactions that will never get confirmed while still ensuring incentive compatibility. They also discuss the importance of having a path that follows the new relay rules and gets support from a significant portion of hashpower.The post delves into the discussion of improving Bitcoin's Replace-by-Fee (RBF) feature in transactions. Developer Jeremy Rubin proposes several changes to address issues and potential attacks. These changes involve removing rules that require higher fees, preventing pinning attacks, and creating a more user-friendly interface for fee bumping transactions. Rubin also discusses models for transaction validation rate-limiting and enhancing the mining score of mempool transactions.The author introduces a new rule called the "feerate-based" rule, which aims to replace transactions in the mempool. This approach entails calculating conflicting transactions and their descendants, identifying original transactions for inclusion in the next block, and ensuring replacements pay at least the same amount plus a certain percentage in absolute fees. Replacements must also have a higher feerate than the maximum mining score of remaining transactions in the mempool after the next block. The proposal suggests utilizing TBD constants to limit the number of replacements allowed with specific fees.Various implementation options for the feerate-based replacement rule are discussed, including dynamic block templates, cached block templates, or dividing the mempool into different feerate layers. Throughout the document, links to relevant pull requests, issues, and discussions are provided for further context. However, the author emphasizes that more discussion is needed to improve the RBF policy.The post also addresses topics like DoS protection, iterative - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Lightning-and-other-layer-2-projects-with-multiple-RBF-policies.xml b/static/bitcoin-dev/Feb_2022/combined_Lightning-and-other-layer-2-projects-with-multiple-RBF-policies.xml index 8fcd30a885..8ed2f05447 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Lightning-and-other-layer-2-projects-with-multiple-RBF-policies.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Lightning-and-other-layer-2-projects-with-multiple-RBF-policies.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Lightning and other layer 2 projects with multiple RBF policies - 2023-08-02T05:38:08.533361+00:00 - - Prayank 2022-02-14 17:59:37+00:00 - - - Michael Folkson 2022-02-14 17:02:06+00:00 - - - Prayank 2022-02-14 05:18:30+00:00 - - - Michael Folkson 2022-02-13 15:46:43+00:00 - - - Prayank 2022-02-13 06:09:05+00:00 - + 2025-09-26T14:41:00.922121+00:00 + python-feedgen + + + [bitcoin-dev] Lightning and other layer 2 projects with multiple RBF policies Prayank + 2022-02-13T06:09:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Michael Folkson + 2022-02-13T15:46:00.000Z + + + Prayank + 2022-02-14T05:18:00.000Z + + + Michael Folkson + 2022-02-14T17:02:00.000Z + + + Prayank + 2022-02-14T17:59:00.000Z + + - python-feedgen + 2 Combined summary - Lightning and other layer 2 projects with multiple RBF policies - 2023-08-02T05:38:08.533361+00:00 + 2025-09-26T14:41:00.922879+00:00 - The security of Layer 2 projects, such as the Lightning Network, relies on policy rules. While it is possible for users to run different policy rules, research in this area is still in its early stages, and the incentives for running the same or differing policies are not yet clear. However, given that the majority of full nodes currently run Bitcoin Core, it is important to discuss setting defaults that enhance the security of Layer 2 projects without impacting users who have no interest in these protocols.Multiple Replace-by-Fee (RBF) policies being used by nodes can potentially compromise the security of different projects that rely on the default RBF policy in the latest version of Bitcoin Core. An attacker could exploit this by using a different RBF policy with a portion of the network's hash power. To address this concern, recent improvements suggested for RBF policy have primarily focused on enhancing the security of the Lightning Network. It is worth noting that Bitcoin Knots, an alternative implementation of Bitcoin Core, allows users to fully configure their own policy rules, even through a graphical user interface (GUI).In a recent email exchange, the implications of multiple RBF policies being used in Bitcoin Core were discussed. While most users will likely stick to the default policy rules, changing the default RBF policy could potentially improve the security of Layer 2 projects like the Lightning Network over the long term. However, it would take time for a significant majority of the network to upgrade to the new policy rules and realize these benefits. The use of different versions of Bitcoin Core is currently prevalent, but there is a trend towards more full nodes upgrading to newer versions.To gain a better understanding of the issues associated with multiple RBF policies, experiments on custom signet networks are encouraged. These experiments could shed more light on the vulnerabilities of Layer 2 projects and provide valuable insights for further research. It is important to note that while the Lightning Network is the most widely adopted Layer 2 project, contributors to other projects are also free to discuss and address non-Lightning-specific security considerations.In conclusion, the security of Layer 2 projects like the Lightning Network is influenced by policy rules. While there is a need for further research in this area, setting defaults that enhance security without impacting users who have no interest in these protocols should be considered. The use of multiple RBF policies in Bitcoin Core can pose security risks to Layer 2 projects, but recent improvements have focused on enhancing the security of the Lightning Network. Bitcoin Knots offers fully configurable policy rules, allowing users to choose their desired policies. Further experimentation and discussions are encouraged to better understand the implications of multiple RBF policies and ensure the security of Layer 2 projects. 2022-02-14T17:59:37+00:00 + The security of Layer 2 projects, such as the Lightning Network, relies on policy rules. While it is possible for users to run different policy rules, research in this area is still in its early stages, and the incentives for running the same or differing policies are not yet clear. However, given that the majority of full nodes currently run Bitcoin Core, it is important to discuss setting defaults that enhance the security of Layer 2 projects without impacting users who have no interest in these protocols.Multiple Replace-by-Fee (RBF) policies being used by nodes can potentially compromise the security of different projects that rely on the default RBF policy in the latest version of Bitcoin Core. An attacker could exploit this by using a different RBF policy with a portion of the network's hash power. To address this concern, recent improvements suggested for RBF policy have primarily focused on enhancing the security of the Lightning Network. It is worth noting that Bitcoin Knots, an alternative implementation of Bitcoin Core, allows users to fully configure their own policy rules, even through a graphical user interface (GUI).In a recent email exchange, the implications of multiple RBF policies being used in Bitcoin Core were discussed. While most users will likely stick to the default policy rules, changing the default RBF policy could potentially improve the security of Layer 2 projects like the Lightning Network over the long term. However, it would take time for a significant majority of the network to upgrade to the new policy rules and realize these benefits. The use of different versions of Bitcoin Core is currently prevalent, but there is a trend towards more full nodes upgrading to newer versions.To gain a better understanding of the issues associated with multiple RBF policies, experiments on custom signet networks are encouraged. These experiments could shed more light on the vulnerabilities of Layer 2 projects and provide valuable insights for further research. It is important to note that while the Lightning Network is the most widely adopted Layer 2 project, contributors to other projects are also free to discuss and address non-Lightning-specific security considerations.In conclusion, the security of Layer 2 projects like the Lightning Network is influenced by policy rules. While there is a need for further research in this area, setting defaults that enhance security without impacting users who have no interest in these protocols should be considered. The use of multiple RBF policies in Bitcoin Core can pose security risks to Layer 2 projects, but recent improvements have focused on enhancing the security of the Lightning Network. Bitcoin Knots offers fully configurable policy rules, allowing users to choose their desired policies. Further experimentation and discussions are encouraged to better understand the implications of multiple RBF policies and ensure the security of Layer 2 projects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_OP-RETURN-inside-TapScript.xml b/static/bitcoin-dev/Feb_2022/combined_OP-RETURN-inside-TapScript.xml index c4652e0eef..c7c3dd5cdd 100644 --- a/static/bitcoin-dev/Feb_2022/combined_OP-RETURN-inside-TapScript.xml +++ b/static/bitcoin-dev/Feb_2022/combined_OP-RETURN-inside-TapScript.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - OP_RETURN inside TapScript - 2023-08-02T05:43:57.141649+00:00 - - Kostas Karasavvas 2022-03-21 11:00:38+00:00 - - - vjudeu at gazeta.pl 2022-03-19 18:32:00+00:00 - - - Peter Todd 2022-03-16 18:21:30+00:00 - - - Zac Greenwood 2022-02-25 13:53:57+00:00 - - - ZmnSCPxj 2022-02-25 12:48:11+00:00 - - - Zac Greenwood 2022-02-25 07:15:06+00:00 - - - ZmnSCPxj 2022-02-25 03:19:34+00:00 - - - Zac Greenwood 2022-02-25 01:12:34+00:00 - - - ZmnSCPxj 2022-02-25 00:04:54+00:00 - - - Zac Greenwood 2022-02-24 21:40:57+00:00 - - - Ruben Somsen 2022-02-24 14:01:58+00:00 - - - vjudeu at gazeta.pl 2022-02-24 13:27:16+00:00 - - - Ruben Somsen 2022-02-24 10:08:22+00:00 - - - vjudeu at gazeta.pl 2022-02-24 09:02:08+00:00 - + 2025-09-26T14:40:39.502499+00:00 + python-feedgen + + + [bitcoin-dev] OP_RETURN inside TapScript vjudeu + 2022-02-24T09:02:00.000Z + + + Ruben Somsen + 2022-02-24T10:08:00.000Z + + + vjudeu + 2022-02-24T13:27:00.000Z + + + Ruben Somsen + 2022-02-24T14:01:00.000Z + + + Zac Greenwood + 2022-02-24T21:40:00.000Z + + + ZmnSCPxj + 2022-02-25T00:04:00.000Z + + + Zac Greenwood + 2022-02-25T01:12:00.000Z + + + ZmnSCPxj + 2022-02-25T03:19:00.000Z + + + Zac Greenwood + 2022-02-25T07:15:00.000Z + + + ZmnSCPxj + 2022-02-25T12:48:00.000Z + + + Zac Greenwood + 2022-02-25T13:53:00.000Z + + + Peter Todd + 2022-03-16T18:21:00.000Z + + + vjudeu + 2022-03-19T18:32:00.000Z + + + Kostas Karasavvas + 2022-03-21T11:00:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - OP_RETURN inside TapScript - 2023-08-02T05:43:57.141649+00:00 + 2025-09-26T14:40:39.504062+00:00 - With the activation of Taproot, it is now possible to attach data to a transaction by creating an "OP_RETURN" branch in the TapScript. This eliminates the need for separate OP_RETURN outputs and allows for more than 80 bytes of data to be stored for free. The data can be stored off-chain but will always be connected to a taproot address that was pushed on-chain. It's important to note that this capability has always existed and is not specific to tapscript.Committing to an ECC point enables data to be stored inside it, including P2PK and P2PKH. It is also possible to commit to large amounts of data, such as 1.5GB, using OP_RETURN or even an entire merkle tree of hashes. However, altering an ECC point, including tapscript, in non-deterministic ways can make it more difficult to recover from backup because the key cannot be recovered without knowing the full commitment.While "OP_RETURN" in TapScript allows for data attachment, it differs from OP_RETURN as the user must communicate out-of-band to reveal the commitment. In contrast, with OP_RETURN, the data is immediately visible. The immediate visibility of data is utilized by various colored coin protocols and BIP47.The question arises whether the implementation should be changed to place the "data" field in "createrawtransaction" into a TapScript instead of creating a separate OP_RETURN output. Currently, Bitcoin Core has a "data" field in "createrawtransaction". By placing this data in a TapScript, it would be possible to eliminate the need for a separate OP_RETURN output and simplify the process of attaching data to a transaction.In summary, Taproot allows for the attachment of data to a transaction by creating an "OP_RETURN" branch in the TapScript. This eliminates the need for separate OP_RETURN outputs and enables more than 80 bytes of data to be stored for free. The implementation may need to be changed to place the "data" field in "createrawtransaction" into a TapScript, streamlining the process of attaching data to a transaction. 2022-03-21T11:00:38+00:00 + With the activation of Taproot, it is now possible to attach data to a transaction by creating an "OP_RETURN" branch in the TapScript. This eliminates the need for separate OP_RETURN outputs and allows for more than 80 bytes of data to be stored for free. The data can be stored off-chain but will always be connected to a taproot address that was pushed on-chain. It's important to note that this capability has always existed and is not specific to tapscript.Committing to an ECC point enables data to be stored inside it, including P2PK and P2PKH. It is also possible to commit to large amounts of data, such as 1.5GB, using OP_RETURN or even an entire merkle tree of hashes. However, altering an ECC point, including tapscript, in non-deterministic ways can make it more difficult to recover from backup because the key cannot be recovered without knowing the full commitment.While "OP_RETURN" in TapScript allows for data attachment, it differs from OP_RETURN as the user must communicate out-of-band to reveal the commitment. In contrast, with OP_RETURN, the data is immediately visible. The immediate visibility of data is utilized by various colored coin protocols and BIP47.The question arises whether the implementation should be changed to place the "data" field in "createrawtransaction" into a TapScript instead of creating a separate OP_RETURN output. Currently, Bitcoin Core has a "data" field in "createrawtransaction". By placing this data in a TapScript, it would be possible to eliminate the need for a separate OP_RETURN output and simplify the process of attaching data to a transaction.In summary, Taproot allows for the attachment of data to a transaction by creating an "OP_RETURN" branch in the TapScript. This eliminates the need for separate OP_RETURN outputs and enables more than 80 bytes of data to be stored for free. The implementation may need to be changed to place the "data" field in "createrawtransaction" into a TapScript, streamlining the process of attaching data to a transaction. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_PathCoin.xml b/static/bitcoin-dev/Feb_2022/combined_PathCoin.xml index 090040ee8d..cf5486ef15 100644 --- a/static/bitcoin-dev/Feb_2022/combined_PathCoin.xml +++ b/static/bitcoin-dev/Feb_2022/combined_PathCoin.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - PathCoin - 2023-08-02T05:25:56.794555+00:00 - - AdamISZ 2022-02-20 18:26:30+00:00 - - - Billy Tetrud 2022-01-30 15:39:04+00:00 - - - AdamISZ 2022-01-29 17:16:29+00:00 - - - Billy Tetrud 2022-01-28 15:27:30+00:00 - - - AdamISZ 2022-01-25 12:50:32+00:00 - - - Billy Tetrud 2022-01-25 11:53:36+00:00 - - - AdamISZ 2022-01-24 14:43:53+00:00 - + 2025-09-26T14:41:11.552476+00:00 + python-feedgen + + + [bitcoin-dev] PathCoin AdamISZ + 2022-01-24T14:43:00.000Z + + + Billy Tetrud + 2022-01-25T11:53:00.000Z + + + AdamISZ + 2022-01-25T12:50:00.000Z + + + Billy Tetrud + 2022-01-28T15:27:00.000Z + + + AdamISZ + 2022-01-29T17:16:00.000Z + + + Billy Tetrud + 2022-01-30T15:39:00.000Z + + + AdamISZ + 2022-02-20T18:26:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - PathCoin - 2023-08-02T05:25:56.794555+00:00 + 2025-09-26T14:41:11.553370+00:00 - The Bitcoin-dev mailing list is currently discussing a new idea called 'path coin', which aims to enable a fully trustless transfer of coins between parties. The first suggestion involves the use of an eltoo/D-R-O type mechanism, assuming APOAS, to eliminate the need for a fidelity bond requirement. This would remove the need for upfront collateral, making it more practical at scale. However, the timelock aspect would still remain, limiting its operation within a pre-agreed time window.Another suggestion revolves around jumping over hops in a fixed path of 100 users. It is believed that longer paths and the ability to jump over can provide more utility, potentially achieved through cleverly arranged lists of other paths. Signature adaptors and CTV or a similar covenant are proposed as a way to create a fully trustless transfer of control of a UTXO from one party to another with no interaction with the rest of the group at the time of transfer.The discussion also focuses on creating a trustless contract enforcement mechanism. One approach suggested is the use of burn mechanisms to enforce contracts, but concerns are raised about instability due to possible bribery and collusion. Instead, penalties consisting of a payment directly from the attacker to the attacked, which exceeds the amount stolen, are proposed as a stable alternative. This model is similar to the one used in Lightning.The conversation touches on the limitations of PathCoin and the need for further development. Sabu, a protocol with similar goals, is also mentioned but noted to have a vulnerability exploitable by miners. Overall, the objective is to explore potential solutions for creating a trustless contract enforcement mechanism.In the email exchange, AdamISZ introduces the concept of a toy version of sending coins like email, utilizing signature adaptors and CTV or similar covenants for a fully trustless transfer of control of a UTXO. While acknowledging the extreme limitations, AdamISZ shares the idea in hopes of further development by imaginative minds. Billy Tetrud responds by highlighting the instability of penalty via burn approaches, citing game theory challenges and the lack of incentives for honest parties to punish. He suggests that a trustless system can still be achieved through penalties as disincentives, as long as the penalty involves a payment from the attacker to the attacked that exceeds the amount stolen.The discussion also includes references to statechains, payment pools, and the Sabu protocol, all with different tradeoffs in achieving trustless systems. The focus remains on finding innovative solutions for trustless contract enforcement mechanisms.In summary, the Bitcoin-dev mailing list is exploring the concept of 'path coin' for a fully trustless transfer of coins between parties. Various ideas involving eltoo/D-R-O mechanisms, jumping over hops, and penalties as disincentives are being discussed. There is a recognition of limitations and the need for further development, but the aim is to find solutions for creating a trustless contract enforcement mechanism. 2022-02-20T18:26:30+00:00 + The Bitcoin-dev mailing list is currently discussing a new idea called 'path coin', which aims to enable a fully trustless transfer of coins between parties. The first suggestion involves the use of an eltoo/D-R-O type mechanism, assuming APOAS, to eliminate the need for a fidelity bond requirement. This would remove the need for upfront collateral, making it more practical at scale. However, the timelock aspect would still remain, limiting its operation within a pre-agreed time window.Another suggestion revolves around jumping over hops in a fixed path of 100 users. It is believed that longer paths and the ability to jump over can provide more utility, potentially achieved through cleverly arranged lists of other paths. Signature adaptors and CTV or a similar covenant are proposed as a way to create a fully trustless transfer of control of a UTXO from one party to another with no interaction with the rest of the group at the time of transfer.The discussion also focuses on creating a trustless contract enforcement mechanism. One approach suggested is the use of burn mechanisms to enforce contracts, but concerns are raised about instability due to possible bribery and collusion. Instead, penalties consisting of a payment directly from the attacker to the attacked, which exceeds the amount stolen, are proposed as a stable alternative. This model is similar to the one used in Lightning.The conversation touches on the limitations of PathCoin and the need for further development. Sabu, a protocol with similar goals, is also mentioned but noted to have a vulnerability exploitable by miners. Overall, the objective is to explore potential solutions for creating a trustless contract enforcement mechanism.In the email exchange, AdamISZ introduces the concept of a toy version of sending coins like email, utilizing signature adaptors and CTV or similar covenants for a fully trustless transfer of control of a UTXO. While acknowledging the extreme limitations, AdamISZ shares the idea in hopes of further development by imaginative minds. Billy Tetrud responds by highlighting the instability of penalty via burn approaches, citing game theory challenges and the lack of incentives for honest parties to punish. He suggests that a trustless system can still be achieved through penalties as disincentives, as long as the penalty involves a payment from the attacker to the attacked that exceeds the amount stolen.The discussion also includes references to statechains, payment pools, and the Sabu protocol, all with different tradeoffs in achieving trustless systems. The focus remains on finding innovative solutions for trustless contract enforcement mechanisms.In summary, the Bitcoin-dev mailing list is exploring the concept of 'path coin' for a fully trustless transfer of coins between parties. Various ideas involving eltoo/D-R-O mechanisms, jumping over hops, and penalties as disincentives are being discussed. There is a recognition of limitations and the need for further development, but the aim is to find solutions for creating a trustless contract enforcement mechanism. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml b/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml index b27d38eab2..0e01bde80c 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2023-08-02T05:36:35.237176+00:00 + 2025-09-26T14:41:09.439178+00:00 + python-feedgen Paul Sztorc 2022-03-04 20:06:50+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2023-08-02T05:36:35.237176+00:00 + 2025-09-26T14:41:09.439335+00:00 - In an email exchange on the bitcoin-dev mailing list, Billy Tetrud discusses sidechains and their potential to address the issue of a less-secure altcoin dominating Bitcoin. While he acknowledges some merits of sidechains in this scenario, Tetrud points out that they do not completely solve the problem. He raises concerns about a sidechain cutting off the main chain and whether it would be in the best interest of enough people. Tetrud also explores the benefits and drawbacks of largeblock sidechains compared to other payment systems like Visa and Lightning. Various tradeoffs, such as onboarding, payment speed, micropayments, fees, and contribution to layer 1 security budget, are considered. Tetrud concludes that if a layer 2 is harmless, its existence can be justified by one net benefit for some users.Another discussion revolves around the size of commitments needed for sidechains and channel factories. User ZmnSCPxj suggests a solution to reduce on-chain bytes by utilizing tweaks in the miner's key and unused TapScript. This eliminates the need for separate commitments and reduces data requirements. Additionally, sidechains can push zero bytes on-chain by using OP_RETURN inside TapScript for checking purposes.The conversation centers around the potential dominance of a sidechain over Bitcoin and how it could prevent an altcoin from dominating. The consensus is that having all chains, centralized and decentralized, in the same monetary unit ensures the decentralized chain always exists without interference from monetary network effects. However, it is argued that a sidechain cannot exist without its main chain, and if it becomes too popular, people may stop using the main chain altogether. The discussion also compares the benefits of a largeblock sidechain to Visa and Lightning and considers the burden on Bitcoin-only nodes. The potential advantages to users of a largeblock sidechain are discussed, including lower fees and more decentralization. The idea of sweeping fiat transactions into a largeblock sidechain is also explored.Another conversation between Billy Tetrud and Paul focuses on the use of sidechains in Bitcoin. Billy proposes that all chains, decentralized and centralized, being in the same monetary unit ensures the existence of the decentralized chain without interference from network effects. Paul disagrees, stating that sidechains cannot exist without their main chain and gives an example using a zcash sidechain. They also discuss the merits of largeblock sidechains and how they can allow users to easily sweep fiat transactions into the BTC universe. Paul believes that largeblock sidechains would not burden Bitcoin Core full nodes.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin scalability, sidechains, network effects, and the security of Lightning Network and Drivechains. Participants argue that sidechains are necessary to prevent people from switching entirely to altcoins, which could be heavily exploited by attackers. Another participant suggests that having all chains in the same monetary unit guarantees the existence of the decentralized chain. The discussion delves into the security risks of LN channel factories and compares the security of LN and Drivechains. The participants emphasize the importance of separating the onboarding rate from the payment rate for designing different structures.The email exchange on the bitcoin-dev mailing list centers around the use of recursive covenants and their potential impact on Bitcoin. The discussion explores implementing techniques like Drivechains using recursive covenants. While concerns about negative effects on Bitcoin or the user base are raised, it is suggested that separate soft forks can be used to add recursive covenants if consensus is reached. The rejection of Drivechains in Bitcoin is also discussed, with arguments made against their implementation due to their distinct security model and potential block size increase. However, proponents argue that Drivechains could have a positive impact and should be given a chance. The debate includes discussions on miner censorship, block size increase, and the need for consensus changes. Paul Sztorc responds to the rejection of Drivechains, stating that there is no strong incentive for mainchain miners and sidechain validators to merge their businesses. He refutes claims that Drivechains would degrade security and believes that Drivechain was ahead of its time and will eventually be adopted. Other discussions revolve around encumbrances and restrictions on spend from covenants, the potential harm to the fungibility of UTXOs, and the shift in risk models. Some argue that introducing different risk models can be damaging to fungibility, while others believe that being able to reject certain coins is at the heart of Bitcoin's security. The email exchanges highlight the ongoing debates and considerations surrounding recursive covenants, Drivechains, and their potential impact on Bitcoin.In a recent email to the Bitcoin-dev mailing list, Jeremy Rubin raises concerns about proposals enabling more "featureful" covenants by adding additional computation into bitcoin script. They emphasize the importance of limiting operations in bitcoin script to "verification" rather than "computation" whenever possible. The author expresses uncertainty about these proposals and fears that opcodes like OP_CAT and OP_TX introduce unnecessary complexity into the script. However, 2022-03-04T20:06:50+00:00 + In an email exchange on the bitcoin-dev mailing list, Billy Tetrud discusses sidechains and their potential to address the issue of a less-secure altcoin dominating Bitcoin. While he acknowledges some merits of sidechains in this scenario, Tetrud points out that they do not completely solve the problem. He raises concerns about a sidechain cutting off the main chain and whether it would be in the best interest of enough people. Tetrud also explores the benefits and drawbacks of largeblock sidechains compared to other payment systems like Visa and Lightning. Various tradeoffs, such as onboarding, payment speed, micropayments, fees, and contribution to layer 1 security budget, are considered. Tetrud concludes that if a layer 2 is harmless, its existence can be justified by one net benefit for some users.Another discussion revolves around the size of commitments needed for sidechains and channel factories. User ZmnSCPxj suggests a solution to reduce on-chain bytes by utilizing tweaks in the miner's key and unused TapScript. This eliminates the need for separate commitments and reduces data requirements. Additionally, sidechains can push zero bytes on-chain by using OP_RETURN inside TapScript for checking purposes.The conversation centers around the potential dominance of a sidechain over Bitcoin and how it could prevent an altcoin from dominating. The consensus is that having all chains, centralized and decentralized, in the same monetary unit ensures the decentralized chain always exists without interference from monetary network effects. However, it is argued that a sidechain cannot exist without its main chain, and if it becomes too popular, people may stop using the main chain altogether. The discussion also compares the benefits of a largeblock sidechain to Visa and Lightning and considers the burden on Bitcoin-only nodes. The potential advantages to users of a largeblock sidechain are discussed, including lower fees and more decentralization. The idea of sweeping fiat transactions into a largeblock sidechain is also explored.Another conversation between Billy Tetrud and Paul focuses on the use of sidechains in Bitcoin. Billy proposes that all chains, decentralized and centralized, being in the same monetary unit ensures the existence of the decentralized chain without interference from network effects. Paul disagrees, stating that sidechains cannot exist without their main chain and gives an example using a zcash sidechain. They also discuss the merits of largeblock sidechains and how they can allow users to easily sweep fiat transactions into the BTC universe. Paul believes that largeblock sidechains would not burden Bitcoin Core full nodes.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin scalability, sidechains, network effects, and the security of Lightning Network and Drivechains. Participants argue that sidechains are necessary to prevent people from switching entirely to altcoins, which could be heavily exploited by attackers. Another participant suggests that having all chains in the same monetary unit guarantees the existence of the decentralized chain. The discussion delves into the security risks of LN channel factories and compares the security of LN and Drivechains. The participants emphasize the importance of separating the onboarding rate from the payment rate for designing different structures.The email exchange on the bitcoin-dev mailing list centers around the use of recursive covenants and their potential impact on Bitcoin. The discussion explores implementing techniques like Drivechains using recursive covenants. While concerns about negative effects on Bitcoin or the user base are raised, it is suggested that separate soft forks can be used to add recursive covenants if consensus is reached. The rejection of Drivechains in Bitcoin is also discussed, with arguments made against their implementation due to their distinct security model and potential block size increase. However, proponents argue that Drivechains could have a positive impact and should be given a chance. The debate includes discussions on miner censorship, block size increase, and the need for consensus changes. Paul Sztorc responds to the rejection of Drivechains, stating that there is no strong incentive for mainchain miners and sidechain validators to merge their businesses. He refutes claims that Drivechains would degrade security and believes that Drivechain was ahead of its time and will eventually be adopted. Other discussions revolve around encumbrances and restrictions on spend from covenants, the potential harm to the fungibility of UTXOs, and the shift in risk models. Some argue that introducing different risk models can be damaging to fungibility, while others believe that being able to reject certain coins is at the heart of Bitcoin's security. The email exchanges highlight the ongoing debates and considerations surrounding recursive covenants, Drivechains, and their potential impact on Bitcoin.In a recent email to the Bitcoin-dev mailing list, Jeremy Rubin raises concerns about proposals enabling more "featureful" covenants by adding additional computation into bitcoin script. They emphasize the importance of limiting operations in bitcoin script to "verification" rather than "computation" whenever possible. The author expresses uncertainty about these proposals and fears that opcodes like OP_CAT and OP_TX introduce unnecessary complexity into the script. However, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml b/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml index 0871bd93ae..4eabd4a263 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2023-08-02T05:21:36.067269+00:00 + 2025-09-26T14:40:56.663112+00:00 + python-feedgen Billy Tetrud 2022-02-22 12:57:15+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2023-08-02T05:21:36.067269+00:00 + 2025-09-26T14:40:56.663278+00:00 - In a recent discussion about Bitcoin scaling, there was disagreement over whether it should be done rapidly or not. Some argue that scaling should not be delayed to keep fees high, suggesting that if higher fees are needed, the block size can be lowered or the default minimum relay fee rate increased. They also question the belief that the Lightning Network is the main cause of low fees and argue that delaying scaling would harm Bitcoin's growth.On the other hand, others argue that new use cases for on-chain transactions may compete with existing users for limited blockchain space. This situation has been compared to the saying "nobody goes there anymore, it's too crowded." The discussion also touched upon the issue of invoking Satoshi's opinions in present-day discussions. One participant objected to assumptions about the founder of Bitcoin, arguing that Satoshi is more than just a pseudonym and will live on forever. However, another participant objected to the invocation of Satoshi in general, suggesting that if he wants to participate in Bitcoin development today, he can speak for himself. They added that if Satoshi refuses to participate, his opinion is irrelevant. In an email exchange posted on a Bitcoin forum, Prayank objects to ZmnSCPxj's invocation of Satoshi, stating that he cares about Satoshi's opinions, especially regarding subsidies. ZmnSCPxj counters by arguing that if Satoshi refuses to participate in Bitcoin development today, it doesn't matter what his opinion is. He asserts that Satoshi is dead and Bitcoin lives on without him. Prayank objects to this assumption, insisting that Satoshi is more than just a pseudonym and will live on forever. Both parties acknowledge that they are considering the various arguments being presented.In another post, ZmnSCPxj mentions that improvements like the Taproot upgrade can reduce activity on the blockchain and increase functionality without requiring an increase in block size. The Taproot upgrade offers features such as Schnorr multisignatures, MAST, `SIGHASH_ANYPREVOUT`, and `OP_CTV`, which reduce block size usage for complex contracts, enable offchain updateable multiparty cryptocurrency systems, and allow transactional cut-through without immediate output publication. ZmnSCPxj believes that these upgrades enhance Bitcoin's functionality and provide opportunities to use the blockchain in a different way.There is also a discussion about the expansion of use-cases in Ethereum potentially harming Bitcoin by fueling future contentious blocksize debates due to high on-chain fees. However, the counterargument is that fees will be the incentives for miners as subsidy decreases, and it will depend on the demand for block space. Additionally, if this is the reason to stop or delay improvements in Bitcoin, it may apply to Taproot as well. A proposal for a lightning-compatible mimblewimble+dandelion on-chain soft fork is mentioned as a way to reduce transaction size, improve privacy, and move more small transactions off-chain. However, it is suggested that this should not be released for another two years as timing is crucial for Bitcoin innovation.Furthermore, there is a discussion about the lack of compelling use-cases beneficial to all users, with some shared use cases being considered too narrow. The Drivechains use-case is deemed harmful to the security of Bitcoin as a whole. It is argued that the new uses for on-chain transactions mentioned as a use-case could harm existing users by competing for limited blockchain space. As a result, it is concluded that any core consensus changes to the Bitcoin system must be carefully evaluated against the risks.In the Bitcoin developer community, there is a debate about the readiness and potential risks of implementing the proposed consensus change known as OP_CTV. Some developers argue for its activation in a few months, while others express skepticism and call for more testing and research. Other soft fork proposals, such as BIP 118 focusing on eltoo payment channels, are also discussed. Concerns are raised about rushing through consensus changes without thorough examination and community support. Skeptics emphasize the need for technical discussions and engagement to address potential issues. Despite differing opinions, there is a general agreement that implementing a soft fork within the next few months is feasible with proper precautions. The discussion highlights the importance of responsible decision-making and avoiding contentious activation attempts. IRC workshops on BIP 119 are mentioned as a resource for engaging with skeptics on technical concerns. 2022-02-22T12:57:15+00:00 + In a recent discussion about Bitcoin scaling, there was disagreement over whether it should be done rapidly or not. Some argue that scaling should not be delayed to keep fees high, suggesting that if higher fees are needed, the block size can be lowered or the default minimum relay fee rate increased. They also question the belief that the Lightning Network is the main cause of low fees and argue that delaying scaling would harm Bitcoin's growth.On the other hand, others argue that new use cases for on-chain transactions may compete with existing users for limited blockchain space. This situation has been compared to the saying "nobody goes there anymore, it's too crowded." The discussion also touched upon the issue of invoking Satoshi's opinions in present-day discussions. One participant objected to assumptions about the founder of Bitcoin, arguing that Satoshi is more than just a pseudonym and will live on forever. However, another participant objected to the invocation of Satoshi in general, suggesting that if he wants to participate in Bitcoin development today, he can speak for himself. They added that if Satoshi refuses to participate, his opinion is irrelevant. In an email exchange posted on a Bitcoin forum, Prayank objects to ZmnSCPxj's invocation of Satoshi, stating that he cares about Satoshi's opinions, especially regarding subsidies. ZmnSCPxj counters by arguing that if Satoshi refuses to participate in Bitcoin development today, it doesn't matter what his opinion is. He asserts that Satoshi is dead and Bitcoin lives on without him. Prayank objects to this assumption, insisting that Satoshi is more than just a pseudonym and will live on forever. Both parties acknowledge that they are considering the various arguments being presented.In another post, ZmnSCPxj mentions that improvements like the Taproot upgrade can reduce activity on the blockchain and increase functionality without requiring an increase in block size. The Taproot upgrade offers features such as Schnorr multisignatures, MAST, `SIGHASH_ANYPREVOUT`, and `OP_CTV`, which reduce block size usage for complex contracts, enable offchain updateable multiparty cryptocurrency systems, and allow transactional cut-through without immediate output publication. ZmnSCPxj believes that these upgrades enhance Bitcoin's functionality and provide opportunities to use the blockchain in a different way.There is also a discussion about the expansion of use-cases in Ethereum potentially harming Bitcoin by fueling future contentious blocksize debates due to high on-chain fees. However, the counterargument is that fees will be the incentives for miners as subsidy decreases, and it will depend on the demand for block space. Additionally, if this is the reason to stop or delay improvements in Bitcoin, it may apply to Taproot as well. A proposal for a lightning-compatible mimblewimble+dandelion on-chain soft fork is mentioned as a way to reduce transaction size, improve privacy, and move more small transactions off-chain. However, it is suggested that this should not be released for another two years as timing is crucial for Bitcoin innovation.Furthermore, there is a discussion about the lack of compelling use-cases beneficial to all users, with some shared use cases being considered too narrow. The Drivechains use-case is deemed harmful to the security of Bitcoin as a whole. It is argued that the new uses for on-chain transactions mentioned as a use-case could harm existing users by competing for limited blockchain space. As a result, it is concluded that any core consensus changes to the Bitcoin system must be carefully evaluated against the risks.In the Bitcoin developer community, there is a debate about the readiness and potential risks of implementing the proposed consensus change known as OP_CTV. Some developers argue for its activation in a few months, while others express skepticism and call for more testing and research. Other soft fork proposals, such as BIP 118 focusing on eltoo payment channels, are also discussed. Concerns are raised about rushing through consensus changes without thorough examination and community support. Skeptics emphasize the need for technical discussions and engagement to address potential issues. Despite differing opinions, there is a general agreement that implementing a soft fork within the next few months is feasible with proper precautions. The discussion highlights the importance of responsible decision-making and avoiding contentious activation attempts. IRC workshops on BIP 119 are mentioned as a resource for engaging with skeptics on technical concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml b/static/bitcoin-dev/Feb_2022/combined_TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml index 093a44e691..ec9b1c233c 100644 --- a/static/bitcoin-dev/Feb_2022/combined_TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml +++ b/static/bitcoin-dev/Feb_2022/combined_TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml @@ -1,89 +1,243 @@ - + 2 Combined summary - TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2023-08-02T05:27:45.946150+00:00 - - Russell O'Connor 2022-02-17 14:50:53+00:00 - - - Anthony Towns 2022-02-17 14:27:27+00:00 - - - Russell O'Connor 2022-02-16 04:10:19+00:00 - - - Rusty Russell 2022-02-16 02:26:14+00:00 - - - Russell O'Connor 2022-02-15 19:12:30+00:00 - - - Jeremy Rubin 2022-02-15 18:57:35+00:00 - - - Rusty Russell 2022-02-15 08:45:10+00:00 - - - Jeremy Rubin 2022-02-08 04:34:30+00:00 - - - Rusty Russell 2022-02-08 03:40:15+00:00 - - - Russell O'Connor 2022-02-08 02:16:10+00:00 - - - Anthony Towns 2022-02-01 01:16:39+00:00 - - - Anthony Towns 2022-01-31 02:18:52+00:00 - - - Russell O'Connor 2022-01-29 17:14:43+00:00 - - - Jeremy Rubin 2022-01-29 17:02:37+00:00 - - - Russell O'Connor 2022-01-29 15:43:13+00:00 - - - Jeremy 2022-01-28 16:38:58+00:00 - - - James O'Beirne 2022-01-28 15:14:12+00:00 - - - Anthony Towns 2022-01-28 14:17:40+00:00 - - - Russell O'Connor 2022-01-28 14:13:11+00:00 - - - Russell O'Connor 2022-01-28 13:56:25+00:00 - - - Michael Folkson 2022-01-28 13:14:07+00:00 - - - Anthony Towns 2022-01-28 01:34:36+00:00 - - - James O'Beirne 2022-01-28 00:18:54+00:00 - - - Russell O'Connor 2022-01-27 19:16:33+00:00 - - - James Lu 2022-01-27 04:20:40+00:00 - - - Jeremy 2022-01-26 22:16:06+00:00 - - - Russell O'Connor 2022-01-26 17:20:10+00:00 - + 2025-09-26T14:41:26.589908+00:00 + python-feedgen + + + [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT Russell O'Connor + 2022-01-26T17:20:00.000Z + + + Jeremy + 2022-01-26T22:16:00.000Z + + + James Lu + 2022-01-27T04:20:00.000Z + + + Russell O'Connor + 2022-01-27T19:16:00.000Z + + + James O'Beirne + 2022-01-28T00:18:00.000Z + + + Anthony Towns + 2022-01-28T01:34:00.000Z + + + Michael Folkson + 2022-01-28T13:14:00.000Z + + + Russell O'Connor + 2022-01-28T13:56:00.000Z + + + Russell O'Connor + 2022-01-28T14:13:00.000Z + + + Anthony Towns + 2022-01-28T14:17:00.000Z + + + James O'Beirne + 2022-01-28T15:14:00.000Z + + + Jeremy + 2022-01-28T16:38:00.000Z + + + Russell O'Connor + 2022-01-29T15:43:00.000Z + + + Jeremy Rubin + 2022-01-29T17:02:00.000Z + + + Russell O'Connor + 2022-01-29T17:14:00.000Z + + + Anthony Towns + 2022-01-31T02:18:00.000Z + + + Anthony Towns + 2022-02-01T01:16:00.000Z + + + Russell O'Connor + 2022-02-08T02:16:00.000Z + + + Rusty Russell + 2022-02-08T03:40:00.000Z + + + Jeremy Rubin + 2022-02-08T04:34:00.000Z + + + [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding + 2022-02-11T00:55:00.000Z + + + Jeremy Rubin + 2022-02-11T03:42:00.000Z + + + James O'Beirne + 2022-02-11T17:42:00.000Z + + + digital vagabond + 2022-02-11T18:12:00.000Z + + + darosior + 2022-02-12T10:54:00.000Z + + + Billy Tetrud + 2022-02-12T15:59:00.000Z + + + [bitcoin-dev] " Rusty Russell + 2022-02-15T08:45:00.000Z + + + Jeremy Rubin + 2022-02-15T18:57:00.000Z + + + Russell O'Connor + 2022-02-15T19:12:00.000Z + + + Rusty Russell + 2022-02-16T02:26:00.000Z + + + Russell O'Connor + 2022-02-16T04:10:00.000Z + + + Anthony Towns + 2022-02-17T14:27:00.000Z + + + Russell O'Connor + 2022-02-17T14:50:00.000Z + + + Anthony Towns + 2022-02-17T15:15:00.000Z + + + ZmnSCPxj + 2022-02-18T07:34:00.000Z + + + ZmnSCPxj + 2022-02-23T11:28:00.000Z + + + Paul Sztorc + 2022-02-23T18:14:00.000Z + + + ZmnSCPxj + 2022-02-24T02:20:00.000Z + + + Anthony Towns + 2022-02-24T06:53:00.000Z + + + ZmnSCPxj + 2022-02-24T12:03:00.000Z + + + Billy Tetrud + 2022-02-26T05:38:00.000Z + + + Anthony Towns + 2022-02-26T06:00:00.000Z + + + ZmnSCPxj + 2022-02-26T06:43:00.000Z + + + Paul Sztorc + 2022-02-27T00:58:00.000Z + + + ZmnSCPxj + 2022-02-27T02:00:00.000Z + + + ZmnSCPxj + 2022-02-27T07:25:00.000Z + + + Billy Tetrud + 2022-02-27T16:59:00.000Z + + + Paul Sztorc + 2022-02-27T23:50:00.000Z + + + Paul Sztorc + 2022-02-28T00:20:00.000Z + + + ZmnSCPxj + 2022-02-28T06:49:00.000Z + + + vjudeu + 2022-02-28T07:55:00.000Z + + + Paul Sztorc + 2022-02-28T22:54:00.000Z + + + Billy Tetrud + 2022-03-01T05:39:00.000Z + + + Paul Sztorc + 2022-03-02T00:00:00.000Z + + + ZmnSCPxj + 2022-03-04T08:42:00.000Z + + + Billy Tetrud + 2022-03-04T12:35:00.000Z + + + vjudeu + 2022-03-04T13:43:00.000Z + + + Paul Sztorc + 2022-03-04T20:06:00.000Z + + @@ -111,13 +265,13 @@ - python-feedgen + 2 Combined summary - TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2023-08-02T05:27:45.947186+00:00 + 2025-09-26T14:41:26.595490+00:00 - In a technical discussion on the bitcoin-dev mailing list, various topics related to transaction introspection, Discreet Log Contracts (DLCs), and programmable systems were debated. It was noted that Discreet Log Contracts provide interesting oracle behavior without transaction introspection, but CSFSV allows for pubkey delegation, which was not previously mentioned. The potential combination of the TXHASH proposal with CAT and rolling SHA256 opcodes to create a programmable system at redemption time was discussed. The usefulness of "CAT" and "CHECKSIGFROMSTACK" in practical applications and the need for a more ideal programming language were also debated.There were concerns raised about whether the proposal covers all future needs, particularly regarding SIGHASH_GROUP. The advantages and disadvantages of using CTV versus TXHASH for transaction validation were discussed. It was noted that while CTV appears to be more flexible, there is a lack of third-party experimentation, making it potentially unsuitable for deployment on mainnet. The pros and cons of bundling CTV with APO and SIGHASH_GROUP were considered, with the conclusion that they should only be bundled if fully specced, implemented, and tested.Jeremy Rubin highlighted the differences between CTV and TXHASH, noting that CTV requires the contract to be fully enumerated and is non-recursive, limiting its applicability. Rusty Russell agreed with this assessment, emphasizing the importance of making tools as clean and clear as possible. There was a discussion about the possibility of using CTV in recursive covenants, with concerns raised about the limitations of fully enumerating contracts and the need to know the set of pairs in advance. It was suggested that iterative covenants are possible with CTV and just as powerful, though technically finite.Russell O'Connor proposed decomposing CTV and ANYPREVOUT into their constituent pieces and programmatically reassembling their behavior. Further decomposition of OP_TXHASH and defining bits for controlling various aspects of a transaction was suggested. The use of SHA256() of scripts instead of the scripts themselves was also proposed. There were discussions about the potential enhancements of Bitcoin Script's functionality, including the combination of TXHASH with CAT and/or rolling SHA256 opcodes. The need for a flexible and expressive scripting system was emphasized, with the possibility of adding specific features as new ideas emerge.The efficiency and usefulness of CTV in comparison to a more general covenant system were debated, with the argument that if CTV is efficient for expressing useful patterns like vaults, it should not be considered technical debt. The importance of considering the long-term implications of design choices was highlighted. Concerns were raised about the complexity and potential challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. However, it was noted that CTV is currently the most practical approach for vaulting and has a low maintenance burden.There were discussions about the potential risks and challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. The possibility of creating complex or recursive covenants using TXHASH and CSFSV was debated, with differing opinions on whether CAT is needed for such constructions. The availability of custom signets with CTV was questioned, with the absence of readily available faucets noted as a possible limitation. The efficiency and usefulness of CTV in comparison to a more general covenant system were discussed, along with the potential benefits and limitations of CTV's hash structure. The proposal of an alternative way to extend the set of txflags for TXHASH was considered, highlighting the benefits and potential challenges of this approach.The discussion on covenant opcodes involved debates about technical debt, soft fork processes, and the risks associated with them. Some stakeholders advocated for implementing CTV, while others suggested that TXHASH+CSFSV would provide more value and enable oracle signature verification. The complexity of these proposals and the potential for quadratic hashing bugs were raised as concerns. It was agreed that while TXHASH is a theoretical approach worth exploring, CTV is preferred for its practicality and availability timeline. The proposal suggested decomposing the operations of CTV and ANYPREVOUT and reassembling their behavior programmatically. Alternative proposals like OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY were also considered.Overall, the discussions on implementing a CTV opcode in Bitcoin Script involved considerations of efficiency, usefulness, technical debt, and long-term implications. There were debates about the viability of creating complex or recursive covenants using existing opcodes and the need for additional ones. The availability of custom signets with CTV and the challenges associated with testing and upgrading were also discussed. Stakeholders emphasized the importance of thoroughly developing and testing these solutions before implementation on the mainnet.The proposal suggested the introduction of new opcodes to verify signatures on messages signed by oracles for oracle applications. These opcodes could be combined with multiple calls to TXHASH to create signatures that commit to specific subsets of transaction data. The potential 2022-02-17T14:50:53+00:00 + In a technical discussion on the bitcoin-dev mailing list, various topics related to transaction introspection, Discreet Log Contracts (DLCs), and programmable systems were debated. It was noted that Discreet Log Contracts provide interesting oracle behavior without transaction introspection, but CSFSV allows for pubkey delegation, which was not previously mentioned. The potential combination of the TXHASH proposal with CAT and rolling SHA256 opcodes to create a programmable system at redemption time was discussed. The usefulness of "CAT" and "CHECKSIGFROMSTACK" in practical applications and the need for a more ideal programming language were also debated.There were concerns raised about whether the proposal covers all future needs, particularly regarding SIGHASH_GROUP. The advantages and disadvantages of using CTV versus TXHASH for transaction validation were discussed. It was noted that while CTV appears to be more flexible, there is a lack of third-party experimentation, making it potentially unsuitable for deployment on mainnet. The pros and cons of bundling CTV with APO and SIGHASH_GROUP were considered, with the conclusion that they should only be bundled if fully specced, implemented, and tested.Jeremy Rubin highlighted the differences between CTV and TXHASH, noting that CTV requires the contract to be fully enumerated and is non-recursive, limiting its applicability. Rusty Russell agreed with this assessment, emphasizing the importance of making tools as clean and clear as possible. There was a discussion about the possibility of using CTV in recursive covenants, with concerns raised about the limitations of fully enumerating contracts and the need to know the set of pairs in advance. It was suggested that iterative covenants are possible with CTV and just as powerful, though technically finite.Russell O'Connor proposed decomposing CTV and ANYPREVOUT into their constituent pieces and programmatically reassembling their behavior. Further decomposition of OP_TXHASH and defining bits for controlling various aspects of a transaction was suggested. The use of SHA256() of scripts instead of the scripts themselves was also proposed. There were discussions about the potential enhancements of Bitcoin Script's functionality, including the combination of TXHASH with CAT and/or rolling SHA256 opcodes. The need for a flexible and expressive scripting system was emphasized, with the possibility of adding specific features as new ideas emerge.The efficiency and usefulness of CTV in comparison to a more general covenant system were debated, with the argument that if CTV is efficient for expressing useful patterns like vaults, it should not be considered technical debt. The importance of considering the long-term implications of design choices was highlighted. Concerns were raised about the complexity and potential challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. However, it was noted that CTV is currently the most practical approach for vaulting and has a low maintenance burden.There were discussions about the potential risks and challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. The possibility of creating complex or recursive covenants using TXHASH and CSFSV was debated, with differing opinions on whether CAT is needed for such constructions. The availability of custom signets with CTV was questioned, with the absence of readily available faucets noted as a possible limitation. The efficiency and usefulness of CTV in comparison to a more general covenant system were discussed, along with the potential benefits and limitations of CTV's hash structure. The proposal of an alternative way to extend the set of txflags for TXHASH was considered, highlighting the benefits and potential challenges of this approach.The discussion on covenant opcodes involved debates about technical debt, soft fork processes, and the risks associated with them. Some stakeholders advocated for implementing CTV, while others suggested that TXHASH+CSFSV would provide more value and enable oracle signature verification. The complexity of these proposals and the potential for quadratic hashing bugs were raised as concerns. It was agreed that while TXHASH is a theoretical approach worth exploring, CTV is preferred for its practicality and availability timeline. The proposal suggested decomposing the operations of CTV and ANYPREVOUT and reassembling their behavior programmatically. Alternative proposals like OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY were also considered.Overall, the discussions on implementing a CTV opcode in Bitcoin Script involved considerations of efficiency, usefulness, technical debt, and long-term implications. There were debates about the viability of creating complex or recursive covenants using existing opcodes and the need for additional ones. The availability of custom signets with CTV and the challenges associated with testing and upgrading were also discussed. Stakeholders emphasized the importance of thoroughly developing and testing these solutions before implementation on the mainnet.The proposal suggested the introduction of new opcodes to verify signatures on messages signed by oracles for oracle applications. These opcodes could be combined with multiple calls to TXHASH to create signatures that commit to specific subsets of transaction data. The potential - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Thoughts-on-fee-bumping.xml b/static/bitcoin-dev/Feb_2022/combined_Thoughts-on-fee-bumping.xml index 206bb0d610..898c83f6ef 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Thoughts-on-fee-bumping.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Thoughts-on-fee-bumping.xml @@ -1,83 +1,115 @@ - + 2 Combined summary - Thoughts on fee bumping - 2023-08-02T05:35:26.714069+00:00 - - darosior 2022-02-18 09:01:07+00:00 - - - Prayank 2022-02-18 02:08:02+00:00 - - - Prayank 2022-02-18 00:54:47+00:00 - - - Antoine Riard 2022-02-18 00:35:01+00:00 - - - James O'Beirne 2022-02-17 18:18:11+00:00 - - - Anthony Towns 2022-02-17 14:32:25+00:00 - - - Billy Tetrud 2022-02-16 20:36:04+00:00 - - - James O'Beirne 2022-02-16 19:18:47+00:00 - - - Billy Tetrud 2022-02-16 02:54:28+00:00 - - - Jeremy Rubin 2022-02-15 21:38:11+00:00 - - - Jeremy Rubin 2022-02-15 21:37:43+00:00 - - - James O'Beirne 2022-02-15 20:53:13+00:00 - - - Russell O'Connor 2022-02-15 20:24:29+00:00 - - - Billy Tetrud 2022-02-15 17:09:56+00:00 - - - Antoine Riard 2022-02-15 00:43:26+00:00 - - - James O'Beirne 2022-02-14 20:28:51+00:00 - - - James O'Beirne 2022-02-14 19:51:26+00:00 - - - Billy Tetrud 2022-02-12 19:44:41+00:00 - - - darosior 2022-02-11 06:51:34+00:00 - - - Antoine Riard 2022-02-11 05:26:53+00:00 - - - Matt Corallo 2022-02-11 00:12:16+00:00 - - - James O'Beirne 2022-02-10 23:51:47+00:00 - - - darosior 2022-02-10 23:44:38+00:00 - - - Greg Sanders 2022-02-10 23:09:06+00:00 - - - James O'Beirne 2022-02-10 19:40:22+00:00 - + 2025-09-26T14:41:24.362258+00:00 + python-feedgen + + + [bitcoin-dev] Thoughts on fee bumping James O'Beirne + 2022-02-10T19:40:00.000Z + + + Greg Sanders + 2022-02-10T23:09:00.000Z + + + darosior + 2022-02-10T23:44:00.000Z + + + James O'Beirne + 2022-02-10T23:51:00.000Z + + + Matt Corallo + 2022-02-11T00:12:00.000Z + + + Antoine Riard + 2022-02-11T05:26:00.000Z + + + darosior + 2022-02-11T06:51:00.000Z + + + Billy Tetrud + 2022-02-12T19:44:00.000Z + + + James O'Beirne + 2022-02-14T19:51:00.000Z + + + James O'Beirne + 2022-02-14T20:28:00.000Z + + + Antoine Riard + 2022-02-15T00:43:00.000Z + + + Billy Tetrud + 2022-02-15T17:09:00.000Z + + + Russell O'Connor + 2022-02-15T20:24:00.000Z + + + James O'Beirne + 2022-02-15T20:53:00.000Z + + + Jeremy Rubin + 2022-02-15T21:37:00.000Z + + + [bitcoin-dev] " Jeremy Rubin + 2022-02-15T21:38:00.000Z + + + Billy Tetrud + 2022-02-16T02:54:00.000Z + + + James O'Beirne + 2022-02-16T19:18:00.000Z + + + Billy Tetrud + 2022-02-16T20:36:00.000Z + + + Anthony Towns + 2022-02-17T14:32:00.000Z + + + James O'Beirne + 2022-02-17T18:18:00.000Z + + + Antoine Riard + 2022-02-18T00:35:00.000Z + + + Prayank + 2022-02-18T00:54:00.000Z + + + Prayank + 2022-02-18T02:08:00.000Z + + + darosior + 2022-02-18T09:01:00.000Z + + + [bitcoin-dev] Sponsor transaction engineering, was " David A. Harding + 2022-02-18T21:09:00.000Z + + @@ -103,13 +135,13 @@ - python-feedgen + 2 Combined summary - Thoughts on fee bumping - 2023-08-02T05:35:26.715066+00:00 + 2025-09-26T14:41:24.364827+00:00 - The discussion on the bitcoin-dev mailing list revolves around the validity of transactions in Bitcoin and the use of transaction sponsors as a fee-bumping primitive. Currently, there is a consensus threshold for transactions to become invalid after a 100 block reorg. However, concerns have been raised about the risks involved for those not waiting for standard finalization.One concern is the difficulty of knowing if a target transaction has been dropped from the majority of network nodes since the last broadcast. However, it is possible to specify a sponsorship transaction that points to a specific transaction ID without rebroadcasting the original transaction data. Pre-committing to a fee-bumping key in CPFP outputs could also become problematic if the key is compromised later on.Transaction sponsors and fee-bumping primitives have benefits for fee management in certain use cases, but there are potential risks to consider, such as data availability and redundancy issues. Further analysis is necessary before deploying new fee-bumping primitives.The use of transaction sponsors in fee bumping has limitations, including transaction topology fluctuations and pre-specifying fee-bumping keys in CPFP outputs. Broadcasting sponsor and target transactions together is suggested as a measure of caution. While transaction sponsors have advantages like targeted replacement policy and ease of migration, they are not a solution to L2-related mempool issues due to replace-by-fee bottleneck and dust limit issues. The proposal of SIGHASH_{NONE,SINGLE}|ANYONECANPAY for the fee-management use case is made.There is a disagreement about the impact of decreasing the miner's reward on fee-bumping. Some argue that increasing feerate may not always be economically rational, as miners with a limited number of transactions may prioritize maximizing absolute fees over feerate. However, this argument may not align with the current reality where a large backlog of transactions is not necessary. The complexity of prioritizing transactions in the mempool is discussed, considering both fee rates and transaction sizes.A simplified approach to fee-bumping is needed to minimize network costs and blockspace waste. Special consideration is given to design principles that ensure feerate bumps are not impossible and minimize bandwidth and chain space consumption. Broadcasting the "diff" instead of rebroadcasting the original transaction is suggested as a more efficient approach. Transaction sponsors are proposed as a way to simplify fee management, although concerns about pinning attacks and wasted block space are raised.The complexity of fee-bumping and dynamic fee management in Bitcoin has sparked significant discussion. Design principles that prioritize the end-user experience while ensuring incentive compatibility are introduced. Additive feerate bumps should always be possible without extensive bandwidth or chain space. Special transaction structures should not be necessary, and feerate increases should be feasible from any source. The transaction sponsors design is supported as a means to achieve these goals, allowing for feerate bumps after a transaction has been broadcasted.Critics have raised objections, citing potential pinning-like attacks and compromise of the classic invariant. However, ways to address these concerns are suggested. Implementing this approach would require a soft-fork, but it is considered worth considering to streamline the fee management process.Given the increasing importance of fees within the Bitcoin system, the current complexity of fee management is deemed unsustainable. Exploring alternative approaches that enhance user experience and simplify fee management is crucial. While further considerations and discussions are needed, an approach that allows for fee-bumping after transaction broadcast is advocated for its flexibility and promised benefits. 2022-02-18T09:01:07+00:00 + The discussion on the bitcoin-dev mailing list revolves around the validity of transactions in Bitcoin and the use of transaction sponsors as a fee-bumping primitive. Currently, there is a consensus threshold for transactions to become invalid after a 100 block reorg. However, concerns have been raised about the risks involved for those not waiting for standard finalization.One concern is the difficulty of knowing if a target transaction has been dropped from the majority of network nodes since the last broadcast. However, it is possible to specify a sponsorship transaction that points to a specific transaction ID without rebroadcasting the original transaction data. Pre-committing to a fee-bumping key in CPFP outputs could also become problematic if the key is compromised later on.Transaction sponsors and fee-bumping primitives have benefits for fee management in certain use cases, but there are potential risks to consider, such as data availability and redundancy issues. Further analysis is necessary before deploying new fee-bumping primitives.The use of transaction sponsors in fee bumping has limitations, including transaction topology fluctuations and pre-specifying fee-bumping keys in CPFP outputs. Broadcasting sponsor and target transactions together is suggested as a measure of caution. While transaction sponsors have advantages like targeted replacement policy and ease of migration, they are not a solution to L2-related mempool issues due to replace-by-fee bottleneck and dust limit issues. The proposal of SIGHASH_{NONE,SINGLE}|ANYONECANPAY for the fee-management use case is made.There is a disagreement about the impact of decreasing the miner's reward on fee-bumping. Some argue that increasing feerate may not always be economically rational, as miners with a limited number of transactions may prioritize maximizing absolute fees over feerate. However, this argument may not align with the current reality where a large backlog of transactions is not necessary. The complexity of prioritizing transactions in the mempool is discussed, considering both fee rates and transaction sizes.A simplified approach to fee-bumping is needed to minimize network costs and blockspace waste. Special consideration is given to design principles that ensure feerate bumps are not impossible and minimize bandwidth and chain space consumption. Broadcasting the "diff" instead of rebroadcasting the original transaction is suggested as a more efficient approach. Transaction sponsors are proposed as a way to simplify fee management, although concerns about pinning attacks and wasted block space are raised.The complexity of fee-bumping and dynamic fee management in Bitcoin has sparked significant discussion. Design principles that prioritize the end-user experience while ensuring incentive compatibility are introduced. Additive feerate bumps should always be possible without extensive bandwidth or chain space. Special transaction structures should not be necessary, and feerate increases should be feasible from any source. The transaction sponsors design is supported as a means to achieve these goals, allowing for feerate bumps after a transaction has been broadcasted.Critics have raised objections, citing potential pinning-like attacks and compromise of the classic invariant. However, ways to address these concerns are suggested. Implementing this approach would require a soft-fork, but it is considered worth considering to streamline the fee management process.Given the increasing importance of fees within the Bitcoin system, the current complexity of fee management is deemed unsustainable. Exploring alternative approaches that enhance user experience and simplify fee management is crucial. While further considerations and discussions are needed, an approach that allows for fee-bumping after transaction broadcast is advocated for its flexibility and promised benefits. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml b/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml index f50a996176..c912702571 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2023-08-02T04:21:03.192868+00:00 + 2025-09-26T14:40:50.176643+00:00 + python-feedgen Anthony Towns 2022-02-03 06:17:14+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2023-08-02T04:21:03.192868+00:00 + 2025-09-26T14:40:50.176818+00:00 - In a recent discussion on the bitcoin-dev mailing list, the topic of enabling covenants in Bitcoin Script was explored. One suggestion involved using the "2 2 CHECKMULTISIG" multisig approach to enforce KYC by requiring funds to be deposited and signed with a government key. The idea of using recursive covenants to create non-terminating computations was also discussed. This concept was originally mentioned in a tweet by Ethan Heilman and later elaborated on in a post by Andrew Poelstra.The discussion also delved into the question of whether Turing completeness should be banned in Bitcoin Script. ZmnSCPxj argued for allowing total Turing-completeness but banning partial Turing-completeness. However, it was acknowledged that banning non-terminating computation for cross-transaction computations would be infeasible. Recursive covenants were identified as a way to write universal computations, and banning source code manipulation would essentially mean banning the manipulation of strings of bytes, which is fundamental to Bitcoin Script.ZmnSCPxj further explained the concept of substructural recursion rules and copattern matching in total functional languages, which ensure termination of recursion. They compared recursive covenants in Bitcoin to codata types in total functional languages, emphasizing the need for Bitcoin SCRIPT to be provably terminating.Jeremy Rubin raised concerns about the potential dangers of evil multisig covenants and the possibility of mining centralization leading to censorship. The discussion also touched on the usefulness of the CSFS opcode and the relationship between OP_CAT and covenants. It was suggested that more direct approaches like OP_TWEAK or UPDATETAPLEAF could be better for implementing covenants.The conversation also addressed the need for separate programs to operate ants and the encoding of state in other parts of the transaction. The idea of adding OP_TWEAK and convenience opcodes for building Taproot Merkle trees was proposed.The discussion on enabling covenants highlighted concerns about transaction and block validation for nodes, ensuring bounded resource requirements and clear evaluation costs. It was noted that while enabling covenants could allow for complex machines that manipulate funds on the blockchain, simple Script programs can be validated and scrutinized to mitigate potential risks. The addition of OP_CHECKSIGFROMSTACK opcode and upper bounds on recursions were suggested as possible solutions.Overall, the discussion emphasized the need for careful consideration of enabling covenants, balancing functionality with validation costs and ensuring the safety and integrity of the Bitcoin network.The ongoing discussion on enabling covenants in Bitcoin has seen arguments against them losing weight as more research is conducted. Multisig wallets alone can enable recursive covenants, such as when a government requires funds to be deposited into a multisig that can only be spent if certain conditions are met. This approach is already being used in permissioned systems like Liquid. While there are ways to escape from recursive covenants, they are not fundamentally different from consensus-enforced covenants. Therefore, multisig-based covenants should be considered in the ongoing discussions about enabling covenants in Bitcoin.Recent research has reduced the weight of arguments against covenants, as AJ's point has further weakened anti-covenant arguments. Multisig alone can enable recursive covenants, as a government can deposit funds into a multisig wallet that requires certain conditions to be met for spending. This process is more efficient than explicit covenants and is already being used in systems like Liquid. The difference between escaping from recursive covenants and consensus-enforced covenants seems to be in procedure and difficulty rather than a fundamental difference.The discussion around enabling covenants is centered on whether OP_CAT should be allowed or not. Multisig wallets can enable recursive covenants, as a government can require funds to be deposited into a multisig that follows certain rules. This approach is already used by Liquid and BTC-on-Ethereum tokens. Escaping from this type of recursive covenant would require a change in signing policy. However, escaping any consensus-enforced covenant would require a hard fork. This difference seems to be more procedural and difficulty-based.Russell O'Connor raised concerns about recursive covenants and the implications of enabling OP_CAT. He initially suggested that such worries should be left for OP_TWEAK, but later acknowledged that recursive covenants could still be created by sneaking state into UTXO amounts or sibling outputs accessed via txid. This highlights the importance of avoiding giving too much power. However, altcoins already exist and some are worse, making full EVM support possible.In an email thread, Russell O'Connor discussed the topic of enabling covenants, specifically recursive covenants that require OP_TWEAK. He expressed concern about simulating this operation with CHECKSIG(FROMSTACK), but later noted that recursive covenants could still be created using a fixed scriptpubkey by sneaking state into UTXO amounts or sibling outputs accessed via txid 2022-02-03T06:17:14+00:00 + In a recent discussion on the bitcoin-dev mailing list, the topic of enabling covenants in Bitcoin Script was explored. One suggestion involved using the "2 2 CHECKMULTISIG" multisig approach to enforce KYC by requiring funds to be deposited and signed with a government key. The idea of using recursive covenants to create non-terminating computations was also discussed. This concept was originally mentioned in a tweet by Ethan Heilman and later elaborated on in a post by Andrew Poelstra.The discussion also delved into the question of whether Turing completeness should be banned in Bitcoin Script. ZmnSCPxj argued for allowing total Turing-completeness but banning partial Turing-completeness. However, it was acknowledged that banning non-terminating computation for cross-transaction computations would be infeasible. Recursive covenants were identified as a way to write universal computations, and banning source code manipulation would essentially mean banning the manipulation of strings of bytes, which is fundamental to Bitcoin Script.ZmnSCPxj further explained the concept of substructural recursion rules and copattern matching in total functional languages, which ensure termination of recursion. They compared recursive covenants in Bitcoin to codata types in total functional languages, emphasizing the need for Bitcoin SCRIPT to be provably terminating.Jeremy Rubin raised concerns about the potential dangers of evil multisig covenants and the possibility of mining centralization leading to censorship. The discussion also touched on the usefulness of the CSFS opcode and the relationship between OP_CAT and covenants. It was suggested that more direct approaches like OP_TWEAK or UPDATETAPLEAF could be better for implementing covenants.The conversation also addressed the need for separate programs to operate ants and the encoding of state in other parts of the transaction. The idea of adding OP_TWEAK and convenience opcodes for building Taproot Merkle trees was proposed.The discussion on enabling covenants highlighted concerns about transaction and block validation for nodes, ensuring bounded resource requirements and clear evaluation costs. It was noted that while enabling covenants could allow for complex machines that manipulate funds on the blockchain, simple Script programs can be validated and scrutinized to mitigate potential risks. The addition of OP_CHECKSIGFROMSTACK opcode and upper bounds on recursions were suggested as possible solutions.Overall, the discussion emphasized the need for careful consideration of enabling covenants, balancing functionality with validation costs and ensuring the safety and integrity of the Bitcoin network.The ongoing discussion on enabling covenants in Bitcoin has seen arguments against them losing weight as more research is conducted. Multisig wallets alone can enable recursive covenants, such as when a government requires funds to be deposited into a multisig that can only be spent if certain conditions are met. This approach is already being used in permissioned systems like Liquid. While there are ways to escape from recursive covenants, they are not fundamentally different from consensus-enforced covenants. Therefore, multisig-based covenants should be considered in the ongoing discussions about enabling covenants in Bitcoin.Recent research has reduced the weight of arguments against covenants, as AJ's point has further weakened anti-covenant arguments. Multisig alone can enable recursive covenants, as a government can deposit funds into a multisig wallet that requires certain conditions to be met for spending. This process is more efficient than explicit covenants and is already being used in systems like Liquid. The difference between escaping from recursive covenants and consensus-enforced covenants seems to be in procedure and difficulty rather than a fundamental difference.The discussion around enabling covenants is centered on whether OP_CAT should be allowed or not. Multisig wallets can enable recursive covenants, as a government can require funds to be deposited into a multisig that follows certain rules. This approach is already used by Liquid and BTC-on-Ethereum tokens. Escaping from this type of recursive covenant would require a change in signing policy. However, escaping any consensus-enforced covenant would require a hard fork. This difference seems to be more procedural and difficulty-based.Russell O'Connor raised concerns about recursive covenants and the implications of enabling OP_CAT. He initially suggested that such worries should be left for OP_TWEAK, but later acknowledged that recursive covenants could still be created by sneaking state into UTXO amounts or sibling outputs accessed via txid. This highlights the importance of avoiding giving too much power. However, altcoins already exist and some are worse, making full EVM support possible.In an email thread, Russell O'Connor discussed the topic of enabling covenants, specifically recursive covenants that require OP_TWEAK. He expressed concern about simulating this operation with CHECKSIG(FROMSTACK), but later noted that recursive covenants could still be created using a fixed scriptpubkey by sneaking state into UTXO amounts or sibling outputs accessed via txid - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml b/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml index 6ab05b9308..54e0b7dfc2 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why CTV, why now? - 2023-08-02T05:33:36.243747+00:00 + 2025-09-26T14:40:48.032467+00:00 + python-feedgen Jeremy Rubin 2022-02-02 01:43:38+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Why CTV, why now? - 2023-08-02T05:33:36.243747+00:00 + 2025-09-26T14:40:48.032612+00:00 - Anthony Towns shared a script template on the Bitcoin-dev mailing list that can be used to simulate CTV (Covenants) on the Liquid blockchain using new element opcodes. Although this approach is less efficient than having a dedicated opcode, it can be effective for many useful applications. The script template involves several INSPECT and SHA256 opcodes, which are used to determine the spending transaction's txid.If the NUMINPUTS is greater than one, there is a need to limit the usage of other inputs, which would be specific to the application being developed. Anthony believes that this emulation might be compatible with confidential assets/values but is uncertain. He also suggests that a similar approach using CHECKSIGFROMSTACK instead of "EQUAL" could be used to construct APO-style signatures on elements/liquid. However, he advises wrapping the output inspection blocks with "INSPECTNUMOUTPUTS GREATERTHAN IF .. ENDIF" and starting with "PUSH[FakeAPOSig] SHA256 DUP SHA256INITIALIZE SHA256UPDATE" to avoid potential misuse in a different context.Anthony notes that the Liquid network, which currently has approximately $120M worth of BTC and $36M worth of USDT, is not congested and does not have many lightning channels built on top of it. As a result, the vaulting application appears to be the most interesting one to build on top of Liquid at present. This suggests that there may be a justification for exploring vault-related work on the Liquid blockchain. Real experience with CTV-like constructs is expected to provide valuable insights.On January 5th, Jeremy via bitcoin-dev proposed CTV as a simple covenant type with minimal validation burdens. It is designed to offer simplicity, flexibility, and power for building various useful applications. The new element opcodes make it possible to simulate CTV on the Liquid blockchain or liquid-testnet if fake money is preferred. While the script template provided in the context is not as efficient as a dedicated opcode, it can still be used when NUMINPUTS is one. In this case, the txid of the spending transaction is fixed due to taproot-only opcodes and the absence of scriptSig malleability. 2022-02-02T01:43:38+00:00 + Anthony Towns shared a script template on the Bitcoin-dev mailing list that can be used to simulate CTV (Covenants) on the Liquid blockchain using new element opcodes. Although this approach is less efficient than having a dedicated opcode, it can be effective for many useful applications. The script template involves several INSPECT and SHA256 opcodes, which are used to determine the spending transaction's txid.If the NUMINPUTS is greater than one, there is a need to limit the usage of other inputs, which would be specific to the application being developed. Anthony believes that this emulation might be compatible with confidential assets/values but is uncertain. He also suggests that a similar approach using CHECKSIGFROMSTACK instead of "EQUAL" could be used to construct APO-style signatures on elements/liquid. However, he advises wrapping the output inspection blocks with "INSPECTNUMOUTPUTS GREATERTHAN IF .. ENDIF" and starting with "PUSH[FakeAPOSig] SHA256 DUP SHA256INITIALIZE SHA256UPDATE" to avoid potential misuse in a different context.Anthony notes that the Liquid network, which currently has approximately $120M worth of BTC and $36M worth of USDT, is not congested and does not have many lightning channels built on top of it. As a result, the vaulting application appears to be the most interesting one to build on top of Liquid at present. This suggests that there may be a justification for exploring vault-related work on the Liquid blockchain. Real experience with CTV-like constructs is expected to provide valuable insights.On January 5th, Jeremy via bitcoin-dev proposed CTV as a simple covenant type with minimal validation burdens. It is designed to offer simplicity, flexibility, and power for building various useful applications. The new element opcodes make it possible to simulate CTV on the Liquid blockchain or liquid-testnet if fake money is preferred. While the script template provided in the context is not as efficient as a dedicated opcode, it can still be used when NUMINPUTS is one. In this case, the txid of the spending transaction is fixed due to taproot-only opcodes and the absence of scriptSig malleability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_non-default-ports-for-automatic-connections-in-Bitcoin-P2P-network.xml b/static/bitcoin-dev/Feb_2022/combined_non-default-ports-for-automatic-connections-in-Bitcoin-P2P-network.xml index 903b861234..b6c6f49190 100644 --- a/static/bitcoin-dev/Feb_2022/combined_non-default-ports-for-automatic-connections-in-Bitcoin-P2P-network.xml +++ b/static/bitcoin-dev/Feb_2022/combined_non-default-ports-for-automatic-connections-in-Bitcoin-P2P-network.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - non-default ports for automatic connections in Bitcoin P2P network - 2023-08-02T05:33:11.258363+00:00 - - Vasil Dimov 2022-02-02 13:30:47+00:00 - - - Prayank 2022-01-29 22:02:24+00:00 - + 2025-09-26T14:41:22.184280+00:00 + python-feedgen + + + [bitcoin-dev] non-default ports for automatic connections in Bitcoin P2P network Prayank + 2022-01-29T22:02:00.000Z + + + Vasil Dimov + 2022-02-02T13:30:00.000Z + + - python-feedgen + 2 Combined summary - non-default ports for automatic connections in Bitcoin P2P network - 2023-08-02T05:33:11.258363+00:00 + 2025-09-26T14:41:22.184782+00:00 - The Bitcoin Core has a preference for peers that listen on port 8333, and currently, it does not allow incoming connections from those who do not use this port. To address the issue of ISPs blocking the default port 8333, a pull request was merged in October 2021 that allows for non-default ports to be used for automatic connections. Another pull request in November 2021 made further changes to support non-default ports. Although no major issues were found during the review process, there was some discussion and minor suggestions from a reviewer.The option to change the default port was added in May 2011 by Gavin Andresen after a user raised concerns about the default port 8333 on bitcointalk in July 2010. Additionally, a PowerShell script was written and tested on version 22.0 to ban all peers every 100 seconds using the default port, which worked as expected. The default ports used in Bitcoin Core are 8333 for mainnet, 18333 for testnet, 18444 for regtest, and 38333 for signet.It is unclear whether Satoshi considered the fact that 8333 in leet becomes 'beee' in plaintext when choosing the default port for Bitcoin. However, the inclusion of the bad ports list in PR #23542 remains unclear. For more details and justifications regarding these matters, the relevant pull requests and discussions can be found on GitHub.To conclude, Prayank shared information about automatic outgoing connections to peers at non-default ports, emphasizing that the discussion focuses solely on this matter to avoid confusion. Vasil Dimov signed off with his email ID and included a quote by Winston Churchill on diplomacy. 2022-02-02T13:30:47+00:00 + The Bitcoin Core has a preference for peers that listen on port 8333, and currently, it does not allow incoming connections from those who do not use this port. To address the issue of ISPs blocking the default port 8333, a pull request was merged in October 2021 that allows for non-default ports to be used for automatic connections. Another pull request in November 2021 made further changes to support non-default ports. Although no major issues were found during the review process, there was some discussion and minor suggestions from a reviewer.The option to change the default port was added in May 2011 by Gavin Andresen after a user raised concerns about the default port 8333 on bitcointalk in July 2010. Additionally, a PowerShell script was written and tested on version 22.0 to ban all peers every 100 seconds using the default port, which worked as expected. The default ports used in Bitcoin Core are 8333 for mainnet, 18333 for testnet, 18444 for regtest, and 38333 for signet.It is unclear whether Satoshi considered the fact that 8333 in leet becomes 'beee' in plaintext when choosing the default port for Bitcoin. However, the inclusion of the bad ports list in PR #23542 remains unclear. For more details and justifications regarding these matters, the relevant pull requests and discussions can be found on GitHub.To conclude, Prayank shared information about automatic outgoing connections to peers at non-default ports, emphasizing that the discussion focuses solely on this matter to avoid confusion. Vasil Dimov signed off with his email ID and included a quote by Winston Churchill on diplomacy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml b/static/bitcoin-dev/Feb_2023/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml index a78a4c7cf7..2fc3a50f1b 100644 --- a/static/bitcoin-dev/Feb_2023/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml +++ b/static/bitcoin-dev/Feb_2023/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - A proposal for Full RBF to not exclude Zero Conf use case - 2023-08-02T08:37:12.928040+00:00 - - Daniel Lipshitz 2023-02-06 12:08:40+00:00 - - - Peter Todd 2023-02-04 16:27:47+00:00 - - - Daniel Lipshitz 2023-01-17 17:27:13+00:00 - - - Erik Aronesty 2023-01-17 17:07:54+00:00 - - - Daniel Lipshitz 2023-01-16 10:19:35+00:00 - - - Daniel Lipshitz 2023-01-14 20:15:30+00:00 - - - Peter Todd 2023-01-13 23:53:45+00:00 - - - Daniel Lipshitz 2022-12-18 08:06:15+00:00 - - - Peter Todd 2022-12-16 21:14:33+00:00 - - - Erik Aronesty 2022-12-14 17:41:17+00:00 - - - Daniel Lipshitz 2022-12-14 08:12:30+00:00 - - - Daniel Lipshitz 2022-12-13 21:58:31+00:00 - - - Peter Todd 2022-12-13 21:41:44+00:00 - - - Daniel Lipshitz 2022-12-13 14:08:10+00:00 - - - Lucas Ontivero 2022-12-13 14:00:26+00:00 - - - Daniel Lipshitz 2022-12-13 11:33:00+00:00 - - - John Carvalho 2022-12-13 09:59:36+00:00 - - - Daniel Lipshitz 2022-12-13 08:08:59+00:00 - - - Yuval Kogman 2022-12-13 04:20:22+00:00 - - - Daniel Lipshitz 2022-12-11 20:24:00+00:00 - + 2025-09-26T14:36:20.306919+00:00 + python-feedgen + + + [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case Daniel Lipshitz + 2022-12-11T20:24:00.000Z + + + Yuval Kogman + 2022-12-13T04:20:00.000Z + + + Daniel Lipshitz + 2022-12-13T08:08:00.000Z + + + John Carvalho + 2022-12-13T09:59:00.000Z + + + Daniel Lipshitz + 2022-12-13T11:33:00.000Z + + + Lucas Ontivero + 2022-12-13T14:00:00.000Z + + + Daniel Lipshitz + 2022-12-13T14:08:00.000Z + + + Peter Todd + 2022-12-13T21:41:00.000Z + + + Daniel Lipshitz + 2022-12-13T21:58:00.000Z + + + Daniel Lipshitz + 2022-12-14T08:12:00.000Z + + + Erik Aronesty + 2022-12-14T17:41:00.000Z + + + Peter Todd + 2022-12-16T21:14:00.000Z + + + Daniel Lipshitz + 2022-12-18T08:06:00.000Z + + + Peter Todd + 2023-01-13T23:53:00.000Z + + + Daniel Lipshitz + 2023-01-14T20:15:00.000Z + + + Daniel Lipshitz + 2023-01-16T10:19:00.000Z + + + Erik Aronesty + 2023-01-17T17:07:00.000Z + + + Daniel Lipshitz + 2023-01-17T17:27:00.000Z + + + Peter Todd + 2023-02-04T16:27:00.000Z + + + Daniel Lipshitz + 2023-02-06T12:08:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - A proposal for Full RBF to not exclude Zero Conf use case - 2023-08-02T08:37:12.928040+00:00 + 2025-09-26T14:36:20.309180+00:00 - In an email exchange between Peter Todd and Daniel Lipshitz, it was revealed that GAP600, a service provider, does not have access to KYC/AML information or telephone numbers of its clients who use bitcoin for deposit. They only receive public bitcoin information such as transaction hash and output address shared via API.Lipshitz explained that their company services merchants, payment processors, and non-custodial liquidity providers by enabling them to accept 0-conf transactions. He also provided figures on the queried unique Bitcoin addresses and USD value for November and December 2022.There is ongoing debate about the need for full RBF (replace-by-fee), with Todd arguing that implementing full RBF would stop the collection of data on real-world entities paying for GAP600's service. However, Lipshitz maintained that their service is purely an analysis of the Bitcoin network and does not involve AML/KYC.Todd suggested adding a swap limitation to mitigate risks, but this was challenged as it would negate the use case of multi-party transactions. Lipshitz emphasized that 0-conf on Bitcoin is a significant use case that should not be ignored.GAP600 did not provide specific names of companies using their service but referred to Max CEO from Coinspaid, who may share further information on the merchants they support. The email exchange also discussed the centralization of transaction processing and the privacy concerns associated with collecting client data.In a discussion on the bitcoin-dev mailing list, Daniel Lipshitz suggested the use of first-seen-safe replace-by-fee (FSS-RBF) as an alternative to full replace-by-fee (FullRBF). This would retain the significant 0-conf use case while balancing the associated risks. John Carvalho expressed concerns about the side-effects of FullRBF and supported the discussion of the FSS-RBF feature.Peter Todd explained in an email exchange with Daniel Lipshitz the issues with his first-seen-safe proposal. He noted that it was only proposed as a political compromise and that full-RBF behavior is necessary for multi-party transactions such as coinjoins and multi-party lightning channels. Todd suggested Antoine Riard's spent-nVersion signaling proposal as a possible compromise option, but it has negative privacy implications. He advised service providers to either adopt scalable instant payment tech like Lightning or expand their business with other chains like BSV.Some wallets, including Electrum, may be affected by FullRBF as they use RBF to batch transactions. Daniel Lipshitz suggested that FSS-RBF could be a suitable option to balance FullRBF and retain the 0-conf use case. John Carvalho also supported the discussion of FSS-RBF.In a separate email exchange, Lipshitz responded to Carvalho's query about why FSS-RBF wasn't implemented earlier and whether there were design problems. Lipshitz acknowledged the suitability of FSS-RBF and found no technical issues with its implementation. He pointed out that the reasons against adopting Full-RBF listed on the Bitcoin Core website do not apply in this case since OptinRBF already exists as an option and FSS-RBF offers additional benefits.The speaker expressed their approval of Peter Todd's suggestion to use the "first-seen-safe replace-by-fee" method, which would balance FullRBF while retaining the use cases for zero-conf transactions. They believe this could be a good way forward.It is understood that the current use case of 0-Conf acceptance of transactions is significant, and merchants are aware of the associated risks. However, full RBF adoption would likely make 0-conf not possible and limit this use case. To address this, the primary use case of full RBF (increasing fees) can be enabled while keeping the outputs of TRX1 to be included within TRX2. This would require the addition of at least one input to increase the fee. OptinRBF and FullRBF (with this limitation) would give actors the option to increase fees while still allowing the 0-conf use case. The risks associated with 0-conf are well understood, and it can continue to exist with the ongoing choices available to actors. 2023-02-06T12:08:40+00:00 + In an email exchange between Peter Todd and Daniel Lipshitz, it was revealed that GAP600, a service provider, does not have access to KYC/AML information or telephone numbers of its clients who use bitcoin for deposit. They only receive public bitcoin information such as transaction hash and output address shared via API.Lipshitz explained that their company services merchants, payment processors, and non-custodial liquidity providers by enabling them to accept 0-conf transactions. He also provided figures on the queried unique Bitcoin addresses and USD value for November and December 2022.There is ongoing debate about the need for full RBF (replace-by-fee), with Todd arguing that implementing full RBF would stop the collection of data on real-world entities paying for GAP600's service. However, Lipshitz maintained that their service is purely an analysis of the Bitcoin network and does not involve AML/KYC.Todd suggested adding a swap limitation to mitigate risks, but this was challenged as it would negate the use case of multi-party transactions. Lipshitz emphasized that 0-conf on Bitcoin is a significant use case that should not be ignored.GAP600 did not provide specific names of companies using their service but referred to Max CEO from Coinspaid, who may share further information on the merchants they support. The email exchange also discussed the centralization of transaction processing and the privacy concerns associated with collecting client data.In a discussion on the bitcoin-dev mailing list, Daniel Lipshitz suggested the use of first-seen-safe replace-by-fee (FSS-RBF) as an alternative to full replace-by-fee (FullRBF). This would retain the significant 0-conf use case while balancing the associated risks. John Carvalho expressed concerns about the side-effects of FullRBF and supported the discussion of the FSS-RBF feature.Peter Todd explained in an email exchange with Daniel Lipshitz the issues with his first-seen-safe proposal. He noted that it was only proposed as a political compromise and that full-RBF behavior is necessary for multi-party transactions such as coinjoins and multi-party lightning channels. Todd suggested Antoine Riard's spent-nVersion signaling proposal as a possible compromise option, but it has negative privacy implications. He advised service providers to either adopt scalable instant payment tech like Lightning or expand their business with other chains like BSV.Some wallets, including Electrum, may be affected by FullRBF as they use RBF to batch transactions. Daniel Lipshitz suggested that FSS-RBF could be a suitable option to balance FullRBF and retain the 0-conf use case. John Carvalho also supported the discussion of FSS-RBF.In a separate email exchange, Lipshitz responded to Carvalho's query about why FSS-RBF wasn't implemented earlier and whether there were design problems. Lipshitz acknowledged the suitability of FSS-RBF and found no technical issues with its implementation. He pointed out that the reasons against adopting Full-RBF listed on the Bitcoin Core website do not apply in this case since OptinRBF already exists as an option and FSS-RBF offers additional benefits.The speaker expressed their approval of Peter Todd's suggestion to use the "first-seen-safe replace-by-fee" method, which would balance FullRBF while retaining the use cases for zero-conf transactions. They believe this could be a good way forward.It is understood that the current use case of 0-Conf acceptance of transactions is significant, and merchants are aware of the associated risks. However, full RBF adoption would likely make 0-conf not possible and limit this use case. To address this, the primary use case of full RBF (increasing fees) can be enabled while keeping the outputs of TRX1 to be included within TRX2. This would require the addition of at least one input to increase the fee. OptinRBF and FullRBF (with this limitation) would give actors the option to increase fees while still allowing the 0-conf use case. The risks associated with 0-conf are well understood, and it can continue to exist with the ongoing choices available to actors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_BIP-for-OP-VAULT.xml b/static/bitcoin-dev/Feb_2023/combined_BIP-for-OP-VAULT.xml index adfa145df7..615c3c6450 100644 --- a/static/bitcoin-dev/Feb_2023/combined_BIP-for-OP-VAULT.xml +++ b/static/bitcoin-dev/Feb_2023/combined_BIP-for-OP-VAULT.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - BIP for OP_VAULT - 2023-08-02T08:58:20.823000+00:00 - - alicexbt 2023-03-30 18:12:46+00:00 - - - Zac Greenwood 2023-03-30 10:39:40+00:00 - - - Steve Lee 2023-03-30 00:16:43+00:00 - - - alicexbt 2023-03-29 19:57:08+00:00 - - - Zac Greenwood 2023-03-29 07:10:19+00:00 - - - Anthony Towns 2023-03-24 12:10:05+00:00 - - - Greg Sanders 2023-03-16 14:44:33+00:00 - - - Greg Sanders 2023-03-14 14:40:53+00:00 - - - Luke Dashjr 2023-03-13 20:55:00+00:00 - - - Brandon Black 2023-03-13 19:03:30+00:00 - - - Greg Sanders 2023-03-13 14:56:15+00:00 - - - Greg Sanders 2023-03-13 14:55:05+00:00 - - - Luke Dashjr 2023-03-11 20:53:21+00:00 - - - Anthony Towns 2023-03-10 01:08:55+00:00 - - - Greg Sanders 2023-03-09 18:45:15+00:00 - - - Anthony Towns 2023-03-07 12:45:34+00:00 - - - Greg Sanders 2023-03-06 16:07:38+00:00 - - - James O'Beirne 2023-03-06 15:25:38+00:00 - - - Andrew Melnychuk Oseen 2023-03-02 19:51:17+00:00 - - - Greg Sanders 2023-03-02 14:54:31+00:00 - - - Anthony Towns 2023-03-02 04:46:25+00:00 - - - Greg Sanders 2023-03-01 15:05:47+00:00 - - - James O'Beirne 2023-02-13 21:09:29+00:00 - + 2025-09-26T14:36:15.992875+00:00 + python-feedgen + + + [bitcoin-dev] BIP for OP_VAULT James O'Beirne + 2023-02-13T21:09:00.000Z + + + Greg Sanders + 2023-03-01T15:05:00.000Z + + + Anthony Towns + 2023-03-02T04:46:00.000Z + + + Greg Sanders + 2023-03-02T14:54:00.000Z + + + Andrew Melnychuk Oseen + 2023-03-02T19:51:00.000Z + + + James O'Beirne + 2023-03-06T15:25:00.000Z + + + Greg Sanders + 2023-03-06T16:07:00.000Z + + + Anthony Towns + 2023-03-07T12:45:00.000Z + + + Greg Sanders + 2023-03-09T18:45:00.000Z + + + Anthony Towns + 2023-03-10T01:08:00.000Z + + + Luke Dashjr + 2023-03-11T20:53:00.000Z + + + Greg Sanders + 2023-03-13T14:55:00.000Z + + + Greg Sanders + 2023-03-13T14:56:00.000Z + + + Brandon Black + 2023-03-13T19:03:00.000Z + + + Luke Dashjr + 2023-03-13T20:55:00.000Z + + + Greg Sanders + 2023-03-14T14:40:00.000Z + + + Greg Sanders + 2023-03-16T14:44:00.000Z + + + Anthony Towns + 2023-03-24T12:10:00.000Z + + + Zac Greenwood + 2023-03-29T07:10:00.000Z + + + alicexbt + 2023-03-29T19:57:00.000Z + + + Steve Lee + 2023-03-30T00:16:00.000Z + + + Zac Greenwood + 2023-03-30T10:39:00.000Z + + + alicexbt + 2023-03-30T18:12:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - BIP for OP_VAULT - 2023-08-02T08:58:20.824001+00:00 + 2025-09-26T14:36:15.995542+00:00 - The email exchange between Zac Greenwood and alicexbt revolves around whether Bitcoin should support private businesses that rely on on-chain storage. Zac argues against such businesses, stating that they contribute little fees while spamming the blockchain. Alicexbt disagrees, highlighting the value these businesses bring, including paying significant fees and attracting new users.In the discussion, Anthony Towns proposes four opcodes that could enable a fair, non-custodial, on-chain auction of ordinals. The proposed mechanism involves creating a utxo on-chain that can be spent in two ways: updating to a new bidder or awarding it to the current high bidder. This approach is resistant to MEV and scalable to larger auctions.The email also mentions the exploration of taproot, multisig, and other technologies within the Bitcoin community. It emphasizes the need to accommodate different visions of money to avoid becoming a niche technology.The discussion on the bitcoin-dev mailing list explores the potential use of opcodes to facilitate parasitical use cases of the blockchain. Some developers are exploring covenants and multisig, while others advocate for Bitcoin to accommodate different visions of money. Proposed opcodes could enable a fair, non-custodial, on-chain auction of ordinals. The script for this auction involves creating a utxo that commits to the address of the leading bidder. The approach is resistant to MEV and could be extended for other asset types.James O'Beirne discusses the concept of "forwarding" input amounts in the OP_VAULT proposal. He provides an example scenario where a user can spend a portion of their vaulted funds by supplying witness data. The proposed approach allows for multiple hot wallets or watchtowers to validate spends and recover funds on violations.The TLUV-ified OP_VAULT implementation is also discussed, aiming to simplify the spec and avoid nested and recursive script execution. The new implementation uses opcodes such as OP_VAULT, OP_VAULT_RECOVER, and OP_CHECKTEMPLATEVERIFY.In another email exchange, the proposed changes to TLUV-ify the OP_VAULT process are discussed. These changes would eliminate hashed commitments and recursive script execution, making the spec easier to understand and reducing indirection. The required opcodes for this implementation include OP_VAULT, OP_VAULT_RECOVER, and OP_CHECKTEMPLATEVERIFY.Finally, a user named Andrew expresses their desire for multiple tapleaves to be restricted in the amounts they can spend. They provide an example of how participants Alice, Bob, and Carol can have restrictions on their outputs based on the locking script.Overall, these discussions highlight various proposals and improvements to the OP_VAULT draft, aiming to enhance security, privacy, and efficiency in Bitcoin transactions. 2023-03-30T18:12:46+00:00 + The email exchange between Zac Greenwood and alicexbt revolves around whether Bitcoin should support private businesses that rely on on-chain storage. Zac argues against such businesses, stating that they contribute little fees while spamming the blockchain. Alicexbt disagrees, highlighting the value these businesses bring, including paying significant fees and attracting new users.In the discussion, Anthony Towns proposes four opcodes that could enable a fair, non-custodial, on-chain auction of ordinals. The proposed mechanism involves creating a utxo on-chain that can be spent in two ways: updating to a new bidder or awarding it to the current high bidder. This approach is resistant to MEV and scalable to larger auctions.The email also mentions the exploration of taproot, multisig, and other technologies within the Bitcoin community. It emphasizes the need to accommodate different visions of money to avoid becoming a niche technology.The discussion on the bitcoin-dev mailing list explores the potential use of opcodes to facilitate parasitical use cases of the blockchain. Some developers are exploring covenants and multisig, while others advocate for Bitcoin to accommodate different visions of money. Proposed opcodes could enable a fair, non-custodial, on-chain auction of ordinals. The script for this auction involves creating a utxo that commits to the address of the leading bidder. The approach is resistant to MEV and could be extended for other asset types.James O'Beirne discusses the concept of "forwarding" input amounts in the OP_VAULT proposal. He provides an example scenario where a user can spend a portion of their vaulted funds by supplying witness data. The proposed approach allows for multiple hot wallets or watchtowers to validate spends and recover funds on violations.The TLUV-ified OP_VAULT implementation is also discussed, aiming to simplify the spec and avoid nested and recursive script execution. The new implementation uses opcodes such as OP_VAULT, OP_VAULT_RECOVER, and OP_CHECKTEMPLATEVERIFY.In another email exchange, the proposed changes to TLUV-ify the OP_VAULT process are discussed. These changes would eliminate hashed commitments and recursive script execution, making the spec easier to understand and reducing indirection. The required opcodes for this implementation include OP_VAULT, OP_VAULT_RECOVER, and OP_CHECKTEMPLATEVERIFY.Finally, a user named Andrew expresses their desire for multiple tapleaves to be restricted in the amounts they can spend. They provide an example of how participants Alice, Bob, and Carol can have restrictions on their outputs based on the locking script.Overall, these discussions highlight various proposals and improvements to the OP_VAULT draft, aiming to enhance security, privacy, and efficiency in Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_BIP-proposal-Fee-redistribution-contracts.xml b/static/bitcoin-dev/Feb_2023/combined_BIP-proposal-Fee-redistribution-contracts.xml index 30777917c8..25160bda85 100644 --- a/static/bitcoin-dev/Feb_2023/combined_BIP-proposal-Fee-redistribution-contracts.xml +++ b/static/bitcoin-dev/Feb_2023/combined_BIP-proposal-Fee-redistribution-contracts.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - BIP proposal: Fee-redistribution contracts - 2023-08-02T09:01:47.251880+00:00 - - David A. Harding 2023-03-01 17:17:58+00:00 - - - shymaa arafat 2023-02-28 10:02:47+00:00 - - - HcaFc_jbe 2023-02-27 21:41:35+00:00 - - - Rastislav Budinsky 2023-02-27 13:32:01+00:00 - + 2025-09-26T14:36:22.434305+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Fee-redistribution contracts Rastislav Budinsky + 2023-02-27T13:32:00.000Z + + + HcaFc_jbe + 2023-02-27T21:41:00.000Z + + + shymaa arafat + 2023-02-28T10:02:00.000Z + + + David A. Harding + 2023-03-01T17:17:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal: Fee-redistribution contracts - 2023-08-02T09:01:47.251880+00:00 + 2025-09-26T14:36:22.434924+00:00 - In a bitcoin-dev mailing list, Rastislav Budinsky proposed a solution where miners would only take a fraction M of the transaction fees, while the remaining fraction C would be sent to contracts for redistribution. However, Dave pointed out that miners can profit from confirming transactions through alternative means, such as "out-of-band fees". He explained that if consensus rules were changed to require each miner to pay a percentage of its in-band fees to future miners, it would incentivize miners to prefer out-of-band fees that wouldn't be subject to this redistribution scheme. This could potentially prevent the effective redistribution of fees as proposed by Rastislav's solution. Additionally, discussions on the mailing list have revealed that larger miners have an advantage over smaller miners in collecting miner-specific fee payments, which undermines the decentralization of Bitcoin's transaction confirmation mechanism.A Bachelor's thesis introduces a proposal to change the way transaction fees are collected and distributed in Bitcoin mining. The proposal suggests taking only a fraction of the fees while sending the rest to contracts for redistribution back to the miner in a "smarter" way. This approach aims to increase security and predictability against fluctuations in fees. However, the proposal has some flaws, including the possibility of undercutting attacks and challenges in achieving miner consensus. The lack of references to op_codes or implementations in the paper makes it unclear how the smart contract would be constructed. Nevertheless, the proposal offers a potential solution to address long-term miner incentives when block subsidies run out.The writer of the Bachelor's thesis proposes a new method of distributing transaction fees, where miners would take a fraction M of the fees, and the remaining fraction C would be sent to contracts for redistribution back to the miner. This approach aims to make mining more secure and predictable against significant fee fluctuations. The benefits of this proposal are discussed, highlighting a better mining environment. However, there are several challenges with the proposal, including the difficulty in constructing the smart contract and convincing the ecosystem to shift from a competitive to a cooperative mining incentive structure. The paper also notes an error in describing the distribution in block creation, which should be poisson instead of exponential. Further discussion is needed to achieve miner consensus and implement the fee-redistribution scheme effectively.The writer is working on their Bachelor's thesis, presenting a new approach to collecting transaction fees. Under this proposal, miners would only take a fraction M of the fees, while the remaining fraction C would be sent to contracts for redistribution back to the miner. This solution aims to enhance mining security and predictability regarding fee fluctuations. The benefits of the proposal are discussed, arguing that most miners should not oppose it as it creates a better mining environment. However, there are challenges highlighted in the paper, such as the difficulty in constructing the smart contract and persuading the ecosystem to transition from a competitive to a cooperative mining incentive structure. Furthermore, the paper acknowledges the need for further discussion on achieving miner consensus and implementing/updating the fee-redistribution scheme effectively. The writer also suggests considering a generally spendable script and embedding the correct logic into consensus nodes as a less disruptive alternative to a hard fork. The full paper can be accessed at [1]. 2023-03-01T17:17:58+00:00 + In a bitcoin-dev mailing list, Rastislav Budinsky proposed a solution where miners would only take a fraction M of the transaction fees, while the remaining fraction C would be sent to contracts for redistribution. However, Dave pointed out that miners can profit from confirming transactions through alternative means, such as "out-of-band fees". He explained that if consensus rules were changed to require each miner to pay a percentage of its in-band fees to future miners, it would incentivize miners to prefer out-of-band fees that wouldn't be subject to this redistribution scheme. This could potentially prevent the effective redistribution of fees as proposed by Rastislav's solution. Additionally, discussions on the mailing list have revealed that larger miners have an advantage over smaller miners in collecting miner-specific fee payments, which undermines the decentralization of Bitcoin's transaction confirmation mechanism.A Bachelor's thesis introduces a proposal to change the way transaction fees are collected and distributed in Bitcoin mining. The proposal suggests taking only a fraction of the fees while sending the rest to contracts for redistribution back to the miner in a "smarter" way. This approach aims to increase security and predictability against fluctuations in fees. However, the proposal has some flaws, including the possibility of undercutting attacks and challenges in achieving miner consensus. The lack of references to op_codes or implementations in the paper makes it unclear how the smart contract would be constructed. Nevertheless, the proposal offers a potential solution to address long-term miner incentives when block subsidies run out.The writer of the Bachelor's thesis proposes a new method of distributing transaction fees, where miners would take a fraction M of the fees, and the remaining fraction C would be sent to contracts for redistribution back to the miner. This approach aims to make mining more secure and predictable against significant fee fluctuations. The benefits of this proposal are discussed, highlighting a better mining environment. However, there are several challenges with the proposal, including the difficulty in constructing the smart contract and convincing the ecosystem to shift from a competitive to a cooperative mining incentive structure. The paper also notes an error in describing the distribution in block creation, which should be poisson instead of exponential. Further discussion is needed to achieve miner consensus and implement the fee-redistribution scheme effectively.The writer is working on their Bachelor's thesis, presenting a new approach to collecting transaction fees. Under this proposal, miners would only take a fraction M of the fees, while the remaining fraction C would be sent to contracts for redistribution back to the miner. This solution aims to enhance mining security and predictability regarding fee fluctuations. The benefits of the proposal are discussed, arguing that most miners should not oppose it as it creates a better mining environment. However, there are challenges highlighted in the paper, such as the difficulty in constructing the smart contract and persuading the ecosystem to transition from a competitive to a cooperative mining incentive structure. Furthermore, the paper acknowledges the need for further discussion on achieving miner consensus and implementing/updating the fee-redistribution scheme effectively. The writer also suggests considering a generally spendable script and embedding the correct logic into consensus nodes as a less disruptive alternative to a hard fork. The full paper can be accessed at [1]. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Bitcoin-Contracting-Primitives-WG-4rd-Meeting-Tuesday-21-Feb-18-00-UTC.xml b/static/bitcoin-dev/Feb_2023/combined_Bitcoin-Contracting-Primitives-WG-4rd-Meeting-Tuesday-21-Feb-18-00-UTC.xml index a248befbb1..7529059968 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Bitcoin-Contracting-Primitives-WG-4rd-Meeting-Tuesday-21-Feb-18-00-UTC.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Bitcoin-Contracting-Primitives-WG-4rd-Meeting-Tuesday-21-Feb-18-00-UTC.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Bitcoin Contracting Primitives WG 4rd Meeting, Tuesday 21 Feb. 18:00 UTC - 2023-08-02T08:56:13.176997+00:00 - - Antoine Riard 2023-02-21 00:40:48+00:00 - - - Antoine Riard 2023-02-08 01:59:59+00:00 - + 2025-09-26T14:36:11.699851+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Contracting Primitives WG 4rd Meeting, Tuesday 21 Feb. 18:00 UTC Antoine Riard + 2023-02-08T01:59:00.000Z + + + Antoine Riard + 2023-02-21T00:40:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Contracting Primitives WG 4rd Meeting, Tuesday 21 Feb. 18:00 UTC - 2023-08-02T08:56:13.176997+00:00 + 2025-09-26T14:36:11.700338+00:00 - Antoine Riard has announced the fourth Bitcoin contracting primitives working group meeting, scheduled to take place on Tuesday, February 21st at 18:00. The purpose of this meeting is to discuss various topics such as ANYPREVOUT / "Eltoo" and the possibility of organizing an open meatspace event during S2 2023 or S1 2024 to enhance the development pace of contracting protocols. Participants have the opportunity to propose additional agenda topics in advance through the GitHub issue tracker.The meeting, which will be held two weeks from now, aims to address important matters related to Bitcoin contracting primitives. Two specific topics have already been proposed for discussion in the upcoming meeting. The first topic is ANYPREVOUT / "Eltoo," a work in progress that has been ongoing over the past year for Eltoo lightning channels. The second topic revolves around the potential organization of an open meatspace event during S2 2023 or S1 2024. These events are considered beneficial for accelerating the development of contracting protocols.If time allows, participants will also have the opportunity to discuss any blockers they may have encountered in their contracting primitives/covenant research. For those interested, the communication venue for the meeting is #bitcoin-contracting-primitives-wg on Libera Chat IRC. Furthermore, logs of previous sessions can be accessed for reference purposes.In summary, Antoine Riard has announced the fourth Bitcoin contracting primitives working group meeting, which will take place on Tuesday, February 21st at 18:00. The meeting will cover topics such as ANYPREVOUT / "Eltoo" and the potential organization of an open meatspace event. Participants can propose additional agenda topics in advance, and the communication venue for the meeting is #bitcoin-contracting-primitives-wg on Libera Chat IRC. Logs of previous sessions are available for reference. 2023-02-21T00:40:48+00:00 + Antoine Riard has announced the fourth Bitcoin contracting primitives working group meeting, scheduled to take place on Tuesday, February 21st at 18:00. The purpose of this meeting is to discuss various topics such as ANYPREVOUT / "Eltoo" and the possibility of organizing an open meatspace event during S2 2023 or S1 2024 to enhance the development pace of contracting protocols. Participants have the opportunity to propose additional agenda topics in advance through the GitHub issue tracker.The meeting, which will be held two weeks from now, aims to address important matters related to Bitcoin contracting primitives. Two specific topics have already been proposed for discussion in the upcoming meeting. The first topic is ANYPREVOUT / "Eltoo," a work in progress that has been ongoing over the past year for Eltoo lightning channels. The second topic revolves around the potential organization of an open meatspace event during S2 2023 or S1 2024. These events are considered beneficial for accelerating the development of contracting protocols.If time allows, participants will also have the opportunity to discuss any blockers they may have encountered in their contracting primitives/covenant research. For those interested, the communication venue for the meeting is #bitcoin-contracting-primitives-wg on Libera Chat IRC. Furthermore, logs of previous sessions can be accessed for reference purposes.In summary, Antoine Riard has announced the fourth Bitcoin contracting primitives working group meeting, which will take place on Tuesday, February 21st at 18:00. The meeting will cover topics such as ANYPREVOUT / "Eltoo" and the potential organization of an open meatspace event. Participants can propose additional agenda topics in advance, and the communication venue for the meeting is #bitcoin-contracting-primitives-wg on Libera Chat IRC. Logs of previous sessions are available for reference. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Codex32.xml b/static/bitcoin-dev/Feb_2023/combined_Codex32.xml index 6c76d4a7e2..b8b9117b55 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Codex32.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Codex32.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Codex32 - 2023-08-02T09:01:23.468356+00:00 - - Russell O'Connor 2023-02-23 18:26:17+00:00 - - - Russell O'Connor 2023-02-23 16:36:59+00:00 - - - Russell O'Connor 2023-02-23 03:30:10+00:00 - - - Russell O'Connor 2023-02-22 19:01:10+00:00 - - - Russell O'Connor 2023-02-22 17:24:19+00:00 - - - Peter Todd 2023-02-22 16:29:03+00:00 - - - Pavol Rusnak 2023-02-20 18:48:32+00:00 - - - Andrew Poelstra 2023-02-20 18:44:36+00:00 - - - Russell O'Connor 2023-02-20 00:52:36+00:00 - - - Christopher Allen 2023-02-19 23:05:12+00:00 - - - Andrew Poelstra 2023-02-19 22:12:51+00:00 - - - David A. Harding 2023-02-19 20:13:33+00:00 - - - Andrew Poelstra 2023-02-16 13:49:53+00:00 - - - Pavol Rusnak 2023-02-16 11:50:12+00:00 - - - Russell O'Connor 2023-02-16 02:16:02+00:00 - + 2025-09-26T14:36:03.113607+00:00 + python-feedgen + + + [bitcoin-dev] Codex32 Russell O'Connor + 2023-02-16T02:16:00.000Z + + + Pavol Rusnak + 2023-02-16T11:50:00.000Z + + + Andrew Poelstra + 2023-02-16T13:49:00.000Z + + + David A. Harding + 2023-02-19T20:13:00.000Z + + + Andrew Poelstra + 2023-02-19T22:12:00.000Z + + + Christopher Allen + 2023-02-19T23:05:00.000Z + + + Russell O'Connor + 2023-02-20T00:52:00.000Z + + + Andrew Poelstra + 2023-02-20T18:44:00.000Z + + + Pavol Rusnak + 2023-02-20T18:48:00.000Z + + + Peter Todd + 2023-02-22T16:29:00.000Z + + + Russell O'Connor + 2023-02-22T17:24:00.000Z + + + Russell O'Connor + 2023-02-22T19:01:00.000Z + + + Russell O'Connor + 2023-02-23T03:30:00.000Z + + + Russell O'Connor + 2023-02-23T16:36:00.000Z + + + Russell O'Connor + 2023-02-23T18:26:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Codex32 - 2023-08-02T09:01:23.468356+00:00 + 2025-09-26T14:36:03.115400+00:00 - The Codex32 project introduces innovative methods for verifying the integrity of shares and seeds while maintaining security. One approach is through 2 character quick checks, which accumulate BCH guarantees as they are performed. Following the prescribed order of these checks allows for quicker error detection. Additionally, a mod N = 0 checksum can be computed by hand to verify shares, and it is suggested that Shamir's secret sharing shards can share the same checksum. Worksheets are provided to evaluate checksums of different sizes.An email conversation discusses the possibility of using a "quick check" to independently verify shares without a computer, with a minimum size of 2 characters recommended. The difference between using an addition table/volvelle and a specific table/volvelle for 1 character quick checks is minimal. There is also consideration of creating a mod N = 0 checksum as a simpler approach. The project enables the verification of shares without a computer, and a specialized worksheet could facilitate the process. While small checksums are not foolproof, a relatively easy procedure with a low chance of error is preferred over a complex one.Codex32 is a protocol designed for paper recollection without electronics, ensuring the privacy and safety of shares. It does not support nested SSSS but allows for using one share as the secret for the next level. Storing version information for wallets using implicit BIP32 paths in metadata is recommended. It is also advised to store descriptor data alongside shares. Hardware wallets provide practical protection by isolating secrets. Codex32 addresses potential compromise vectors, reducing risk.A new proposal suggests a method for verifying individual shares without a computer. This involves using a mod N = 0 checksum or generating shares with small checksums, which can be verified manually. Updates to the draft text have been discussed in an email conversation, and individuals have been thanked for their feedback. A pull request for the new scheme was opened on February 15, 2023. Andrew Poelstra suggests the need for a MAC to prevent attacks on Bitcoin seed phrases.Overall, Codex32 offers innovative methods for verifying shares and seeds while maintaining security. The project provides options for quick checks, mod N = 0 checksums, and the use of Shamir's secret sharing shards. These verification methods can be performed manually, making them accessible to users without relying on computers. The protocol also addresses potential compromise vectors and provides practical protection through hardware wallets. Ongoing discussions and updates demonstrate the project's commitment to improving and refining its methods.Codex32 is a new seed-sharing scheme that allows for the backup and restoration of a hierarchical deterministic wallet's master seed using Shamir's secret sharing. It offers advantages over SLIP-0039, such as a longer checksum, more compact encoding, and readable metadata. The scheme uses the bech32 alphabet and is designed for hand computation. It supports splitting secret data into up to 31 shares, resembling Bech32 strings.One of the main benefits of Codex32 is the ability to independently verify the integrity of each share without a computer. This allows users to perform their recollection privately using pen and paper, ensuring the accuracy of their backup. Codex32 does not natively support nested SSSS or dummy wallets but does allow for version information storage.In a discussion about the new BIP proposal, concerns were raised about the potential for deliberate modification of a recovery code, leading to fraudulent activities. However, there is no way to prevent such an attack without compromising the properties of the code.The Codex32 format uses uppercase alphabets and numbers to reduce the size of QR codes. Lowercase letters are converted into a two-byte value, increasing QR code size. By using only uppercase alphabets and numbers, QR codes can be compressed and their efficiency improved. Superior QR codecs provided by Blockchain Commons or Nayuki.io can achieve even better results.The context mentions the discovery of a secret society called the Cult of the Bound Variable, which used sandstone "computers" with 32 glyphs for cryptographic computations. Their system, known as Codex32, may be of interest to the Bitcoin community.Overall, Codex32 offers an alternative method for backing up and restoring master seeds in hierarchical deterministic wallets. Its simplicity, error-correcting abilities, and support for independent share verification make it a compelling option for users seeking a secure and efficient seed-sharing scheme. 2023-02-23T18:26:17+00:00 + The Codex32 project introduces innovative methods for verifying the integrity of shares and seeds while maintaining security. One approach is through 2 character quick checks, which accumulate BCH guarantees as they are performed. Following the prescribed order of these checks allows for quicker error detection. Additionally, a mod N = 0 checksum can be computed by hand to verify shares, and it is suggested that Shamir's secret sharing shards can share the same checksum. Worksheets are provided to evaluate checksums of different sizes.An email conversation discusses the possibility of using a "quick check" to independently verify shares without a computer, with a minimum size of 2 characters recommended. The difference between using an addition table/volvelle and a specific table/volvelle for 1 character quick checks is minimal. There is also consideration of creating a mod N = 0 checksum as a simpler approach. The project enables the verification of shares without a computer, and a specialized worksheet could facilitate the process. While small checksums are not foolproof, a relatively easy procedure with a low chance of error is preferred over a complex one.Codex32 is a protocol designed for paper recollection without electronics, ensuring the privacy and safety of shares. It does not support nested SSSS but allows for using one share as the secret for the next level. Storing version information for wallets using implicit BIP32 paths in metadata is recommended. It is also advised to store descriptor data alongside shares. Hardware wallets provide practical protection by isolating secrets. Codex32 addresses potential compromise vectors, reducing risk.A new proposal suggests a method for verifying individual shares without a computer. This involves using a mod N = 0 checksum or generating shares with small checksums, which can be verified manually. Updates to the draft text have been discussed in an email conversation, and individuals have been thanked for their feedback. A pull request for the new scheme was opened on February 15, 2023. Andrew Poelstra suggests the need for a MAC to prevent attacks on Bitcoin seed phrases.Overall, Codex32 offers innovative methods for verifying shares and seeds while maintaining security. The project provides options for quick checks, mod N = 0 checksums, and the use of Shamir's secret sharing shards. These verification methods can be performed manually, making them accessible to users without relying on computers. The protocol also addresses potential compromise vectors and provides practical protection through hardware wallets. Ongoing discussions and updates demonstrate the project's commitment to improving and refining its methods.Codex32 is a new seed-sharing scheme that allows for the backup and restoration of a hierarchical deterministic wallet's master seed using Shamir's secret sharing. It offers advantages over SLIP-0039, such as a longer checksum, more compact encoding, and readable metadata. The scheme uses the bech32 alphabet and is designed for hand computation. It supports splitting secret data into up to 31 shares, resembling Bech32 strings.One of the main benefits of Codex32 is the ability to independently verify the integrity of each share without a computer. This allows users to perform their recollection privately using pen and paper, ensuring the accuracy of their backup. Codex32 does not natively support nested SSSS or dummy wallets but does allow for version information storage.In a discussion about the new BIP proposal, concerns were raised about the potential for deliberate modification of a recovery code, leading to fraudulent activities. However, there is no way to prevent such an attack without compromising the properties of the code.The Codex32 format uses uppercase alphabets and numbers to reduce the size of QR codes. Lowercase letters are converted into a two-byte value, increasing QR code size. By using only uppercase alphabets and numbers, QR codes can be compressed and their efficiency improved. Superior QR codecs provided by Blockchain Commons or Nayuki.io can achieve even better results.The context mentions the discovery of a secret society called the Cult of the Bound Variable, which used sandstone "computers" with 32 glyphs for cryptographic computations. Their system, known as Codex32, may be of interest to the Bitcoin community.Overall, Codex32 offers an alternative method for backing up and restoring master seeds in hierarchical deterministic wallets. Its simplicity, error-correcting abilities, and support for independent share verification make it a compelling option for users seeking a secure and efficient seed-sharing scheme. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Debate-64-bytes-in-OP-RETURN-VS-taproot-OP-FALSE-OP-IF-OP-PUSH.xml b/static/bitcoin-dev/Feb_2023/combined_Debate-64-bytes-in-OP-RETURN-VS-taproot-OP-FALSE-OP-IF-OP-PUSH.xml index 34ea1683f3..3af74a5839 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Debate-64-bytes-in-OP-RETURN-VS-taproot-OP-FALSE-OP-IF-OP-PUSH.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Debate-64-bytes-in-OP-RETURN-VS-taproot-OP-FALSE-OP-IF-OP-PUSH.xml @@ -1,107 +1,147 @@ - + 2 Combined summary - Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH - 2023-08-02T08:54:11.232682+00:00 - - Aymeric Vitte 2023-02-18 18:38:00+00:00 - - - Anthony Towns 2023-02-17 12:49:41+00:00 - - - Aymeric Vitte 2023-02-17 10:56:19+00:00 - - - Claus Ehrenberg 2023-02-16 19:59:06+00:00 - - - Aymeric Vitte 2023-02-16 18:23:55+00:00 - - - Aymeric Vitte 2023-02-12 16:23:59+00:00 - - - Russell O'Connor 2023-02-05 18:12:52+00:00 - - - Andrew Poelstra 2023-02-05 18:06:18+00:00 - - - Aymeric Vitte 2023-02-05 12:47:38+00:00 - - - Peter Todd 2023-02-05 12:06:33+00:00 - - - Aymeric Vitte 2023-02-05 11:40:38+00:00 - - - Peter Todd 2023-02-05 02:01:08+00:00 - - - Russell O'Connor 2023-02-05 00:11:35+00:00 - - - Peter Todd 2023-02-05 00:04:04+00:00 - - - Aymeric Vitte 2023-02-04 23:09:02+00:00 - - - Christopher Allen 2023-02-04 22:18:06+00:00 - - - Aymeric Vitte 2023-02-04 20:55:47+00:00 - - - Christopher Allen 2023-02-04 18:54:41+00:00 - - - Aymeric Vitte 2023-02-04 17:01:20+00:00 - - - Kostas Karasavvas 2023-02-04 14:11:33+00:00 - - - Christopher Allen 2023-02-03 18:47:17+00:00 - - - Aymeric Vitte 2023-02-03 11:15:14+00:00 - - - Rijndael 2023-02-02 13:25:41+00:00 - - - Aymeric Vitte 2023-02-02 12:24:12+00:00 - - - Peter Todd 2023-02-02 11:49:32+00:00 - - - Aymeric Vitte 2023-02-02 11:45:42+00:00 - - - Peter Todd 2023-02-02 11:22:23+00:00 - - - Andrew Poelstra 2023-02-01 14:02:41+00:00 - - - Aymeric Vitte 2023-02-01 12:59:40+00:00 - - - Peter Todd 2023-02-01 12:51:38+00:00 - - - Kostas Karasavvas 2023-02-01 08:36:52+00:00 - - - Christopher Allen 2023-02-01 02:22:29+00:00 - - - Christopher Allen 2023-02-01 00:46:32+00:00 - + 2025-09-26T14:36:18.150773+00:00 + python-feedgen + + + [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH Christopher Allen + 2023-02-01T00:46:00.000Z + + + Peter Todd + 2023-02-01T02:07:00.000Z + + + Christopher Allen + 2023-02-01T02:22:00.000Z + + + Kostas Karasavvas + 2023-02-01T08:36:00.000Z + + + Peter Todd + 2023-02-01T12:51:00.000Z + + + Aymeric Vitte + 2023-02-01T12:59:00.000Z + + + Andrew Poelstra + 2023-02-01T14:02:00.000Z + + + Peter Todd + 2023-02-02T11:22:00.000Z + + + Aymeric Vitte + 2023-02-02T11:45:00.000Z + + + Peter Todd + 2023-02-02T11:49:00.000Z + + + Aymeric Vitte + 2023-02-02T12:24:00.000Z + + + Rijndael + 2023-02-02T13:25:00.000Z + + + Aymeric Vitte + 2023-02-03T11:15:00.000Z + + + Christopher Allen + 2023-02-03T18:47:00.000Z + + + Kostas Karasavvas + 2023-02-04T14:11:00.000Z + + + Aymeric Vitte + 2023-02-04T17:01:00.000Z + + + Christopher Allen + 2023-02-04T18:54:00.000Z + + + Aymeric Vitte + 2023-02-04T20:55:00.000Z + + + Christopher Allen + 2023-02-04T22:18:00.000Z + + + Aymeric Vitte + 2023-02-04T23:09:00.000Z + + + Peter Todd + 2023-02-05T00:04:00.000Z + + + Russell O'Connor + 2023-02-05T00:11:00.000Z + + + Peter Todd + 2023-02-05T02:01:00.000Z + + + Aymeric Vitte + 2023-02-05T11:40:00.000Z + + + Peter Todd + 2023-02-05T12:06:00.000Z + + + Aymeric Vitte + 2023-02-05T12:47:00.000Z + + + Andrew Poelstra + 2023-02-05T18:06:00.000Z + + + Russell O'Connor + 2023-02-05T18:12:00.000Z + + + Aymeric Vitte + 2023-02-12T16:23:00.000Z + + + Aymeric Vitte + 2023-02-16T18:23:00.000Z + + + Claus Ehrenberg + 2023-02-16T19:59:00.000Z + + + Aymeric Vitte + 2023-02-17T10:56:00.000Z + + + Anthony Towns + 2023-02-17T12:49:00.000Z + + + Aymeric Vitte + 2023-02-18T18:38:00.000Z + + @@ -135,13 +175,13 @@ - python-feedgen + 2 Combined summary - Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH - 2023-08-02T08:54:11.232682+00:00 + 2025-09-26T14:36:18.154418+00:00 - The discussions on the bitcoin-dev mailing list revolve around finding efficient and cost-effective ways to store data in the Bitcoin network. One proposal suggests increasing the size of the OP_RETURN to support a hash, signature, and metadata, while another proposal argues for allowing any number of OP_RETURN outputs without a size limit. The community also discusses the best practices for storing data in Bitcoin, including the use of witness envelopes and OP_RETURN.To request a change to the OP_RETURN size, individuals must issue a pull request on bitcoin-core and address any concerns or objections that arise. The process involves discussions within the community, obtaining acknowledgments (ACKs), and addressing negative acknowledgments (NACKs). The maintainers decide when to merge the change based on community interest and consensus. Once released, the change can only take effect after a significant number of miners and nodes have updated to the new release.The conversation explores different approaches and considerations, such as the efficiency gains of using FALSE IF ... ENDIF over repeated drops. There are also discussions on storing data in Bitcoin's UTXO set and the potential impact on deviant behavior. The use of Taproot is considered for making a script visible, with considerations for data privacy and user control.The discussions highlight the importance of community engagement, consensus-building, and addressing concerns when proposing changes to the Bitcoin protocol. Christopher Allen actively seeks to understand the tradeoffs in post-taproot Bitcoin, exploring options for publishing data while minimizing harm. The focus shifts to whether a traditional OP_RETURN or a spent taproot transaction is more suitable for placing a 64-byte message in the Bitcoin blockchain. However, alternative options and perspectives are welcomed in this ongoing discussion. 2023-02-18T18:38:00+00:00 + The discussions on the bitcoin-dev mailing list revolve around finding efficient and cost-effective ways to store data in the Bitcoin network. One proposal suggests increasing the size of the OP_RETURN to support a hash, signature, and metadata, while another proposal argues for allowing any number of OP_RETURN outputs without a size limit. The community also discusses the best practices for storing data in Bitcoin, including the use of witness envelopes and OP_RETURN.To request a change to the OP_RETURN size, individuals must issue a pull request on bitcoin-core and address any concerns or objections that arise. The process involves discussions within the community, obtaining acknowledgments (ACKs), and addressing negative acknowledgments (NACKs). The maintainers decide when to merge the change based on community interest and consensus. Once released, the change can only take effect after a significant number of miners and nodes have updated to the new release.The conversation explores different approaches and considerations, such as the efficiency gains of using FALSE IF ... ENDIF over repeated drops. There are also discussions on storing data in Bitcoin's UTXO set and the potential impact on deviant behavior. The use of Taproot is considered for making a script visible, with considerations for data privacy and user control.The discussions highlight the importance of community engagement, consensus-building, and addressing concerns when proposing changes to the Bitcoin protocol. Christopher Allen actively seeks to understand the tradeoffs in post-taproot Bitcoin, exploring options for publishing data while minimizing harm. The focus shifts to whether a traditional OP_RETURN or a spent taproot transaction is more suitable for placing a 64-byte message in the Bitcoin blockchain. However, alternative options and perspectives are welcomed in this ongoing discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Feb_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 6c25093aa9..82c0ca0a4a 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:36:07.411732+00:00 + python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:36:07.411900+00:00 - On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to 2023-03-13T16:38:25+00:00 + On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Ordinal-Inscription-Size-Limits.xml b/static/bitcoin-dev/Feb_2023/combined_Ordinal-Inscription-Size-Limits.xml index b2e4dc1910..4a7eba2395 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Ordinal-Inscription-Size-Limits.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Ordinal-Inscription-Size-Limits.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Ordinal Inscription Size Limits - 2024-01-04T02:00:07.522616+00:00 - - Erik Aronesty 2024-01-03 13:05:42+00:00 - - - Brad Morrison 2024-01-03 09:11:58+00:00 - - - Erik Aronesty 2024-01-01 16:08:29+00:00 - - - Brad Morrison 2024-01-01 13:33:02+00:00 - - - Erik Aronesty 2023-12-30 09:58:41+00:00 - - - Nagaev Boris 2023-12-29 19:01:52+00:00 - - - Greg Tonoski 2023-12-29 12:27:42+00:00 - - - Aymeric Vitte 2023-02-07 12:17:24+00:00 - - - Erik Aronesty 2023-02-06 18:05:05+00:00 - - - Claus Ehrenberg 2023-02-06 17:31:45+00:00 - - - Erik Aronesty 2023-02-06 16:39:14+00:00 - - - Kostas Karasavvas 2023-02-04 14:25:58+00:00 - - - Melvin Carvalho 2023-02-03 19:56:16+00:00 - - - Erik Aronesty 2023-01-31 08:58:46+00:00 - - - Robert Dickinson 2023-01-29 10:34:54+00:00 - - - Aymeric Vitte 2023-01-28 16:47:46+00:00 - - - alicexbt 2023-01-28 10:58:12+00:00 - - - Robert Dickinson 2023-01-28 04:26:15+00:00 - - - Aymeric Vitte 2023-01-27 15:43:46+00:00 - - - Andrew Poelstra 2023-01-27 13:21:00+00:00 - - - rotmaxi 2023-01-27 12:58:49+00:00 - - - Robert Dickinson 2023-01-27 12:44:10+00:00 - + 2025-09-26T14:36:09.585775+00:00 + python-feedgen + + + [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson + 2023-01-27T12:44:00.000Z + + + rot13maxi + 2023-01-27T12:58:00.000Z + + + Andrew Poelstra + 2023-01-27T13:21:00.000Z + + + Aymeric Vitte + 2023-01-27T15:43:00.000Z + + + Robert Dickinson + 2023-01-28T04:26:00.000Z + + + alicexbt + 2023-01-28T10:58:00.000Z + + + Aymeric Vitte + 2023-01-28T16:47:00.000Z + + + Robert Dickinson + 2023-01-29T10:34:00.000Z + + + Erik Aronesty + 2023-01-31T08:58:00.000Z + + + Melvin Carvalho + 2023-02-03T19:56:00.000Z + + + Kostas Karasavvas + 2023-02-04T14:25:00.000Z + + + Erik Aronesty + 2023-02-06T16:39:00.000Z + + + Claus Ehrenberg + 2023-02-06T17:31:00.000Z + + + Erik Aronesty + 2023-02-06T18:05:00.000Z + + + Aymeric Vitte + 2023-02-07T12:17:00.000Z + + + Greg Tonoski + 2023-12-29T12:27:00.000Z + + + Nagaev Boris + 2023-12-29T19:01:00.000Z + + + Erik Aronesty + 2023-12-30T09:58:00.000Z + + + Brad Morrison + 2024-01-01T13:33:00.000Z + + + Erik Aronesty + 2024-01-01T16:08:00.000Z + + + Brad Morrison + 2024-01-03T09:11:00.000Z + + + Erik Aronesty + 2024-01-03T13:05:00.000Z + + @@ -91,29 +116,21 @@ - python-feedgen + 2 Combined summary - Ordinal Inscription Size Limits - 2024-01-04T02:00:07.522763+00:00 + 2025-09-26T14:36:09.588318+00:00 + 2024-01-03T13:05:42+00:00 The Bitcoin programming community is engaged in discussions focusing on blockchain scalability, transaction efficiency, and data storage. Scalability challenges stem not from block size but from the broadcasting and storing of transactions across network nodes. Alternatives like the Lightning Network and covenant technology are being explored to address these issues. - Comparisons with credit card payment systems highlight Bitcoin's higher transaction costs due to fees that control spam but also limit its use for payments. Proposals include increasing block size to lower fees and make Bitcoin more competitive. - Spam prevention via transaction fees is effective yet inconsistent; advanced methods like payment pools and tree payments have been suggested to improve this and can be found at [UTXOs Scaling](https://utxos.org/uses/scaling/). Innovative data storage within transactions using multisig and Taproot’s Merkle proofs is being debated, with suggestions for natural economic deterrents to discourage misuse. - Discussions on witness data storage involve concerns about storing 'toxic data' and proposals to limit data size or alter incentive structures. GitHub references such as [PR 28408](https://github.com/bitcoin/bitcoin/pull/28408) and [Issue 29146](https://github.com/bitcoin/bitcoin/issues/29146) indicate a broader dialogue on control mechanisms against unwanted data, including deprecating certain opcodes. - Storing NFT content as witness data poses risks regarding node storage capacity and disk usage. Suggestions include imposing size limits and alternative methods like extension blocks. Linking sats to real-world deeds is considered, however, storing actual property on the blockchain is seen as impractical. - -Robert Dickinson and Alicexbt contribute their perspectives on storage capacity and blockchain space management. Dickinson recommends premium charges for image storage, whereas Alicexbt advises capacity planning and proposes a "local bitcoin" system to avoid main chain storage congestion. - +Robert Dickinson and Alicexbt contribute their perspectives on storage capacity and blockchain space management. Dickinson recommends premium charges for image storage, whereas Alicexbt advises capacity planning and proposes a "local bitcoin" system to avoid main chain storage congestion. Amidst this technical debate, there is also discussion about the cultural and innovative uses of data storage, such as embedding images during festivals. However, there are calls for responsible usage and education to prevent negative consequences from arbitrary data storage. - Aymeric Vitte presents a vision for integrating Bitcoin into the NFT and 'web3' sphere. He suggests a centralized bitcoin-based NFT system for efficient referencing of low-value NFTs in transactions, contrasting with decentralized approaches. - The debate considers balancing innovation with the practicalities of Bitcoin’s infrastructure. Core developers face the challenge of addressing diverse opinions and the long-term effects of permitting unlimited data storage through witness data and ordinals, aiming to ensure Bitcoin's evolution remains robust and sustainable. - 2024-01-03T13:05:42+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Pseudocode-for-robust-tail-emission.xml b/static/bitcoin-dev/Feb_2023/combined_Pseudocode-for-robust-tail-emission.xml index 1f2bab2322..891406feae 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Pseudocode-for-robust-tail-emission.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Pseudocode-for-robust-tail-emission.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pseudocode for robust tail emission - 2023-08-02T08:42:11.383342+00:00 + 2025-09-26T14:36:13.844578+00:00 + python-feedgen jk_14 at op.pl 2023-02-01 22:04:11+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Pseudocode for robust tail emission - 2023-08-02T08:42:11.384340+00:00 + 2025-09-26T14:36:13.844786+00:00 - In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the 2023-02-01T22:04:11+00:00 + In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Purely-off-chain-coin-colouring.xml b/static/bitcoin-dev/Feb_2023/combined_Purely-off-chain-coin-colouring.xml index 1a1e6a0220..c843769b1d 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Purely-off-chain-coin-colouring.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Purely-off-chain-coin-colouring.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Purely off-chain coin colouring - 2023-11-21T02:05:43.408293+00:00 + 2025-09-26T14:35:58.851847+00:00 + python-feedgen vjudeu at gazeta.pl 2023-11-20 19:47:13+00:00 @@ -55,27 +56,20 @@ - python-feedgen + 2 Combined summary - Purely off-chain coin colouring - 2023-11-21T02:05:43.408390+00:00 + 2025-09-26T14:35:58.851995+00:00 + 2023-11-20T19:47:13+00:00 Blockchain standardization is a key topic, with suggestions to treat signature R-values as Taproot-based public keys for consistent protocol interpretation. Another approach proposes using commitments that can push any data and nest future commitments within previous ones, ensuring they remain off-chain by starting with OP_RETURN and expressing r-values as 256-bit numbers. - Minimal on-chain presence for inscriptions involves hashing the actual data and committing it via sign-to-contract to reduce the blockchain footprint. This technique enhances privacy and prevents issues like blocking or front-running. Sign-to-contract extends to timestamping by including a merkle root but raises concerns about ownership representation. The method requires generating a nonce and its public version, deriving a nonce, creating and verifying a signature, and is compatible with ecdsa and schnorr signatures. - Discussions on the bitcoin-dev mailing list highlight the trade-off between small block sizes for decentralization and the need for valuable block space to ensure Bitcoin's security through transaction fees. Solutions like ordinals or publications may drive demand for block space, while adjusting the inflation subsidy phase-out remains controversial. - -The debate on moving inscriptions off-chain considers the scarcity and value of blockspace versus network efficiency. Proposals suggest off-chain protocols for NFTs with proof of work or Lightning fees, allowing tracking without affecting how ordinals are spent. A patron system over Lightning is proposed, and the term "inscription" is debated in this context. - +The debate on moving inscriptions off-chain considers the scarcity and value of blockspace versus network efficiency. Proposals suggest off-chain protocols for NFTs with proof of work or Lightning fees, allowing tracking without affecting how ordinals are spent. A patron system over Lightning is proposed, and the term "inscription" is debated in this context. To combat NFT-related scams, theft, and duplication, solutions include requiring proof of work or Lightning payments for hosting NFTs. Nostr relay and proof of work are mentioned as tools for maintaining a clean digital artifact feed. Despite some resistance, the ordinals protocol is preferred for art projects, with an invitation for further input on its development. - Storing off-chain NFT data faces challenges due to third-party limitations. A proposal recommends using reliable parties to store proofs and artwork copies, with full versions released after transactions. Adjusting OP_RETURN size could address current constraints. On-chain data publishing is defended for its indefinite storage capabilities by archival nodes, questioning models like nostr for their data persistence. - -The integration of NFTs within Bitcoin involves using ordinals to track satoshis with unique "inscriptions," though linking specific data or rights to an ordinal remains unsolved. Moving inscriptions off-chain could lower costs and overhead, focusing on ownership transfer. RGB protocol and Taro support off-chain custody proofs for NFTs, raising concerns about the longevity of off-chain data compared to on-chain publication's guaranteed persistence. - +The integration of NFTs within Bitcoin involves using ordinals to track satoshis with unique "inscriptions," though linking specific data or rights to an ordinal remains unsolved. Moving inscriptions off-chain could lower costs and overhead, focusing on ownership transfer. RGB protocol and Taro support off-chain custody proofs for NFTs, raising concerns about the longevity of off-chain data compared to on-chain publication's guaranteed persistence. Further discussions explore semi-fungible tokens on the Liquid network and privacy through zero-knowledge proofs or unobservable transfers via nostr events. In conclusion, developers are considering various approaches to incorporate NFTs into Bitcoin, aiming to balance cost, scalability, and data permanence as they move towards integrating colored bitcoins. - 2023-11-20T19:47:13+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Reference-example-bech32m-address-for-future-segwit-versions.xml b/static/bitcoin-dev/Feb_2023/combined_Reference-example-bech32m-address-for-future-segwit-versions.xml index f405560c6d..a11bafd62e 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Reference-example-bech32m-address-for-future-segwit-versions.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Reference-example-bech32m-address-for-future-segwit-versions.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Reference example bech32m address for future segwit versions - 2023-08-02T08:52:43.448743+00:00 - - Anthony Towns 2023-02-01 01:13:49+00:00 - - - Greg Sanders 2023-02-01 00:37:06+00:00 - - - David A. Harding 2023-01-31 23:33:13+00:00 - - - Greg Sanders 2023-01-31 14:30:34+00:00 - - - David A. Harding 2023-01-31 00:02:51+00:00 - + 2025-09-26T14:35:56.705832+00:00 + python-feedgen + + + [bitcoin-dev] Reference example bech32m address for future segwit versions David A. Harding + 2023-01-31T00:02:00.000Z + + + Greg Sanders + 2023-01-31T14:30:00.000Z + + + David A. Harding + 2023-01-31T23:33:00.000Z + + + Greg Sanders + 2023-02-01T00:37:00.000Z + + + Anthony Towns + 2023-02-01T01:13:00.000Z + + - python-feedgen + 2 Combined summary - Reference example bech32m address for future segwit versions - 2023-08-02T08:52:43.448743+00:00 + 2025-09-26T14:35:56.706645+00:00 - In a recent email exchange on the bitcoin-dev mailing list, David A. Harding raised a question about the best practice for wallets when it comes to spending to the output indicated by any valid bech32m address. The response from aj was that it depends on whether the wallet is custodial or non-custodial. If it's a non-custodial wallet that may not be upgraded by the time witness v2 addresses are in use, then sending to such addresses now makes sense and is worth testing. However, if it's a custodial wallet, then there's a strong argument against allowing sending to such addresses until they're actually in use.The reason for this is two-fold: firstly, nobody will be running old software since the custodian can just force everyone to upgrade. Secondly, signing a transaction to send bitcoins held on behalf of someone else to an address that will get them stolen could be considered negligence, forcing the custodian to make the user whole again. Therefore, there's no point in testing a scenario that's likely years away for custodial wallets.On the other hand, for non-custodial wallets, it's worth testing as they might not be able to find compatible software in the future to move their private keys and have to resort to using the current software. However, in that case, they should be able to capture the transaction it generates before broadcasting it, and don't need to publish it on-chain. It's a different matter for libraries and non-wallet software like block explorers or alternate node implementations.In an email exchange, Greg Sanders predicts that most custodians may be hesitant to whitelist a witness version that they know is insecure. David A. Harding questions whether wallets should only send to outputs they know can be secured or if they should spend to the output indicated by any valid bech32m address. He finds the more restrictive approach to be sad and believes that there is a benefit to testing it when proprietary software is involved. However, he wants the testing to use the address least likely to cause problems for protocol developers in the future.David asks Greg and others on the list if they have any reason to believe that OP_16 OP_PUSH2 0000 would be a problematic script or if they can think of a better one. The email also references BIP350, which recommends ensuring that wallet implementations support sending to v1 and higher versions.In an email conversation between Greg Sanders and David, the topic of sending funds to future segwit versions was discussed. Greg suggested that most exchanges would not enable sends to future segwit versions due to the risk involved in doing so. However, David argued that wallets should spend to any valid bech32m address and that the more restrictive approach of only sending to secured outputs seemed unnecessary. He explained that withdrawing to a witness program for which there is no solution could result in bigger problems. David also suggested that testing the best practice of sending to secured outputs could benefit protocol developers in the future if they need to test other best practices that cannot be easily tested for. However, he wanted to use the address least likely to cause problems for protocol developers in the future. He sought suggestions from others on the list regarding what script to use. The email conversation references BIP350, which recommends supporting sending to v1 and higher versions.In a discussion on the Bitcoin-dev mailing list, David A. Harding proposed having a reserved address space for future segwit versions that are unlikely to interfere with future soft forks but can still exercise wallets supporting bech32m. He suggested using the following addresses: HRP (Human-readable part) "bc" for mainnet and "tb" for testnet, witness version 16 (the last segwit version), and witness program 0x0000. This would help developers of future soft forks deal with existing outputs paid to templates used in the proposed soft fork.Greg, in response, noted that most exchanges will not enable sends to future segwit versions due to the risk perspective of sending funds there. However, updating to new versions should be straightforward as long as the checksum is not changed again and popular open-source libraries support it. Testing this behavior in production can create an annoyance for developers of future soft forks. Therefore, having a canonical example of future segwit addresses that are unlikely to interfere with future soft forks could be useful.A proposal has been made for a canonical example of future segwit addresses that are designed to be very unlikely to interfere with future soft forks but which would still reasonably exercise wallets supporting bech32m. This is equivalent to the RFC2606 domain "example.com" which has been reserved for examples in documentation. The proposed addresses include one each for mainnet and testnet. The Witness version is 16, which is the last segwit version, while the Witness program is 0x0000; two bytes is the minimum allowed by BIP141, but it's far too small to make any sort of 2023-02-01T01:13:49+00:00 + In a recent email exchange on the bitcoin-dev mailing list, David A. Harding raised a question about the best practice for wallets when it comes to spending to the output indicated by any valid bech32m address. The response from aj was that it depends on whether the wallet is custodial or non-custodial. If it's a non-custodial wallet that may not be upgraded by the time witness v2 addresses are in use, then sending to such addresses now makes sense and is worth testing. However, if it's a custodial wallet, then there's a strong argument against allowing sending to such addresses until they're actually in use.The reason for this is two-fold: firstly, nobody will be running old software since the custodian can just force everyone to upgrade. Secondly, signing a transaction to send bitcoins held on behalf of someone else to an address that will get them stolen could be considered negligence, forcing the custodian to make the user whole again. Therefore, there's no point in testing a scenario that's likely years away for custodial wallets.On the other hand, for non-custodial wallets, it's worth testing as they might not be able to find compatible software in the future to move their private keys and have to resort to using the current software. However, in that case, they should be able to capture the transaction it generates before broadcasting it, and don't need to publish it on-chain. It's a different matter for libraries and non-wallet software like block explorers or alternate node implementations.In an email exchange, Greg Sanders predicts that most custodians may be hesitant to whitelist a witness version that they know is insecure. David A. Harding questions whether wallets should only send to outputs they know can be secured or if they should spend to the output indicated by any valid bech32m address. He finds the more restrictive approach to be sad and believes that there is a benefit to testing it when proprietary software is involved. However, he wants the testing to use the address least likely to cause problems for protocol developers in the future.David asks Greg and others on the list if they have any reason to believe that OP_16 OP_PUSH2 0000 would be a problematic script or if they can think of a better one. The email also references BIP350, which recommends ensuring that wallet implementations support sending to v1 and higher versions.In an email conversation between Greg Sanders and David, the topic of sending funds to future segwit versions was discussed. Greg suggested that most exchanges would not enable sends to future segwit versions due to the risk involved in doing so. However, David argued that wallets should spend to any valid bech32m address and that the more restrictive approach of only sending to secured outputs seemed unnecessary. He explained that withdrawing to a witness program for which there is no solution could result in bigger problems. David also suggested that testing the best practice of sending to secured outputs could benefit protocol developers in the future if they need to test other best practices that cannot be easily tested for. However, he wanted to use the address least likely to cause problems for protocol developers in the future. He sought suggestions from others on the list regarding what script to use. The email conversation references BIP350, which recommends supporting sending to v1 and higher versions.In a discussion on the Bitcoin-dev mailing list, David A. Harding proposed having a reserved address space for future segwit versions that are unlikely to interfere with future soft forks but can still exercise wallets supporting bech32m. He suggested using the following addresses: HRP (Human-readable part) "bc" for mainnet and "tb" for testnet, witness version 16 (the last segwit version), and witness program 0x0000. This would help developers of future soft forks deal with existing outputs paid to templates used in the proposed soft fork.Greg, in response, noted that most exchanges will not enable sends to future segwit versions due to the risk perspective of sending funds there. However, updating to new versions should be straightforward as long as the checksum is not changed again and popular open-source libraries support it. Testing this behavior in production can create an annoyance for developers of future soft forks. Therefore, having a canonical example of future segwit addresses that are unlikely to interfere with future soft forks could be useful.A proposal has been made for a canonical example of future segwit addresses that are designed to be very unlikely to interfere with future soft forks but which would still reasonably exercise wallets supporting bech32m. This is equivalent to the RFC2606 domain "example.com" which has been reserved for examples in documentation. The proposed addresses include one each for mainnet and testnet. The Witness version is 16, which is the last segwit version, while the Witness program is 0x0000; two bytes is the minimum allowed by BIP141, but it's far too small to make any sort of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Refreshed-BIP324.xml b/static/bitcoin-dev/Feb_2023/combined_Refreshed-BIP324.xml index cd4118e47b..2ff77cb844 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Refreshed-BIP324.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Refreshed-BIP324.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100274+00:00 - - Tim Ruffing 2023-10-11 20:52:52+00:00 - - - Erik Aronesty 2023-02-28 21:02:41+00:00 - - - Dhruv M 2023-02-28 18:07:06+00:00 - - - Anthony Towns 2023-02-21 16:03:37+00:00 - - - Pieter Wuille 2023-02-20 15:22:30+00:00 - - - Anthony Towns 2023-02-19 23:56:02+00:00 - - - Pieter Wuille 2023-02-17 22:13:05+00:00 - - - Anthony Towns 2023-02-17 15:51:19+00:00 - - - Dhruv M 2023-02-16 17:43:22+00:00 - - - Anthony Towns 2023-01-09 08:11:05+00:00 - - - Anthony Towns 2023-01-05 23:12:50+00:00 - - - Pieter Wuille 2023-01-05 22:06:29+00:00 - - - Anthony Towns 2022-11-18 08:24:49+00:00 - - - Yuval Kogman 2022-11-12 18:52:31+00:00 - - - Pieter Wuille 2022-11-12 03:23:16+00:00 - - - Pieter Wuille 2022-11-10 21:23:44+00:00 - - - Anthony Towns 2022-11-08 03:20:23+00:00 - - - Jonas Schnelli 2022-11-03 22:26:54+00:00 - - - Murch 2022-11-03 17:53:26+00:00 - - - Vasil Dimov 2022-10-27 07:28:38+00:00 - - - Pieter Wuille 2022-10-26 16:39:02+00:00 - - - Dhruv M 2022-10-08 12:59:58+00:00 - + 2025-09-26T14:36:24.580628+00:00 + python-feedgen + + + [bitcoin-dev] Refreshed BIP324 Dhruv M + 2022-10-08T12:59:00.000Z + + + Pieter Wuille + 2022-10-26T16:39:00.000Z + + + Vasil Dimov + 2022-10-27T07:28:00.000Z + + + Murch + 2022-11-03T17:53:00.000Z + + + Jonas Schnelli + 2022-11-03T22:26:00.000Z + + + Anthony Towns + 2022-11-08T03:20:00.000Z + + + Pieter Wuille + 2022-11-10T21:23:00.000Z + + + Pieter Wuille + 2022-11-12T03:23:00.000Z + + + Yuval Kogman + 2022-11-12T18:52:00.000Z + + + Anthony Towns + 2022-11-18T08:24:00.000Z + + + Pieter Wuille + 2023-01-05T22:06:00.000Z + + + Anthony Towns + 2023-01-05T23:12:00.000Z + + + Anthony Towns + 2023-01-09T08:11:00.000Z + + + Dhruv M + 2023-02-16T17:43:00.000Z + + + Anthony Towns + 2023-02-17T15:51:00.000Z + + + Pieter Wuille + 2023-02-17T22:13:00.000Z + + + Anthony Towns + 2023-02-19T23:56:00.000Z + + + Pieter Wuille + 2023-02-20T15:22:00.000Z + + + Anthony Towns + 2023-02-21T16:03:00.000Z + + + Dhruv M + 2023-02-28T18:07:00.000Z + + + Erik Aronesty + 2023-02-28T21:02:00.000Z + + + Tim Ruffing + 2023-10-11T20:52:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100469+00:00 + 2025-09-26T14:36:24.582911+00:00 - The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. 2023-10-11T20:52:52+00:00 + The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Testing-censorship-resistance-of-bitcoin-p2p-network.xml b/static/bitcoin-dev/Feb_2023/combined_Testing-censorship-resistance-of-bitcoin-p2p-network.xml index 73e65558c6..e1db5fa19d 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Testing-censorship-resistance-of-bitcoin-p2p-network.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Testing-censorship-resistance-of-bitcoin-p2p-network.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Testing censorship resistance of bitcoin p2p network - 2023-08-02T08:56:50.488864+00:00 - - Peter Todd 2023-02-22 16:39:04+00:00 - - - alicexbt 2023-02-19 00:33:11+00:00 - - - Russell O'Connor 2023-02-18 18:03:45+00:00 - - - vjudeu at gazeta.pl 2023-02-18 09:48:02+00:00 - - - Andrew Poelstra 2023-02-18 01:28:38+00:00 - - - Peter Todd 2023-02-18 00:03:15+00:00 - - - Andrew Poelstra 2023-02-17 23:39:11+00:00 - - - Andrew Poelstra 2023-02-17 23:35:34+00:00 - - - vjudeu at gazeta.pl 2023-02-17 14:56:31+00:00 - - - alicexbt 2023-02-13 12:34:30+00:00 - + 2025-09-26T14:36:00.963960+00:00 + python-feedgen + + + [bitcoin-dev] Testing censorship resistance of bitcoin p2p network alicexbt + 2023-02-13T12:34:00.000Z + + + vjudeu + 2023-02-17T14:56:00.000Z + + + Andrew Poelstra + 2023-02-17T23:35:00.000Z + + + Andrew Poelstra + 2023-02-17T23:39:00.000Z + + + Peter Todd + 2023-02-18T00:03:00.000Z + + + Andrew Poelstra + 2023-02-18T01:28:00.000Z + + + vjudeu + 2023-02-18T09:48:00.000Z + + + Russell O'Connor + 2023-02-18T18:03:00.000Z + + + alicexbt + 2023-02-19T00:33:00.000Z + + + Peter Todd + 2023-02-22T16:39:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Testing censorship resistance of bitcoin p2p network - 2023-08-02T08:56:50.488864+00:00 + 2025-09-26T14:36:00.965285+00:00 - In a recent discussion on the bitcoin-dev mailing list, the topic of using static analysis to determine the likelihood of an IF branch being taken in inscription scripts was brought up. Andrew Poelstra suggested that if this filtering could be done reliably and efficiently, it would make inscription scripts more "plausible" but would also increase their space cost by requiring multiple instances of OP_DROP. Peter Todd questioned the actual percentage increase in space cost, with Poelstra estimating a little over 1% according to standardness rules and less than 0.2% according to consensus.The conversation then shifted to the issue of censorship resistance in Bitcoin transactions. There are concerns about certain projects censoring transactions and the potential exploitation of such practices by government agencies. To test if transactions are being relayed by connected peers, two tools were mentioned: counting INV messages and broadcasting transactions to specific nodes using libbtc. A Python script was shared that allows listing peers, broadcasting transactions, and banning peers that do not relay transactions. While the script is primarily for testing purposes, it can be used by anyone who wants to avoid connecting to unhelpful peers. It was noted that there may be some false positives in the results, and the script relies on libbtc.The discussion also touched upon the storage of arbitrary data on-chain and the use of OP_RETURN. The writer argues that commitments should only be stored by nodes that explicitly enable them, as they are additional information that can be skipped if needed. They believe that using OP_RETURN would result in all nodes storing such data, whereas using witness nodes would limit storage to those specifically designed for it. The benefits of inscriptions were also highlighted, including increased interest in running full nodes, trying out bitcoin wallets and lightning, greater adoption of Taproot, and more developers seeking bitcoin development resources.Another email thread focused on spam in Bitcoin transactions. The current standardness rules allow for up to 80-byte pushes, resulting in a little over 1% of spam. By consensus, which allows for 520-byte pushes, the percentage is less than 0.2%. To reduce the number of dropping opcodes, the suggestion is to use "OP_2DROP" instead of "OP_DROP OP_DROP." However, this alone is not enough to reject official alternatives like commitments. The inclusion of spam transactions in the chain is still possible. Pruning unused data blobs in the chain is seen as a solution, but switching from witness to non-witness nodes would require additional validation and invalidate signatures. One proposed solution involves storing the first and last chunk of data and keeping the internal state of SHA-256 before entering the last chunk, allowing for pruning without invalidating signatures. The discussion also mentions the possibility of spammers providing "FALSE" as a separate witness element rather than part of the witnessScript, leading to the use of legitimate "IF ENDIF" cases.In February 2023, Andrew Poelstra suggested using static analysis to determine the likelihood of an IF branch being taken in inscription scripts. This proposal aims to make inscription scripts more "plausible" by requiring the addition of OP_DROP multiple times. The actual percentage increase in space cost was estimated to be a little over 1% according to standardness rules and less than 0.2% according to consensus. The issue of banning specific script fragments was discussed, with concerns raised about spammers using alternative methods to bypass bans. Andrew Poelstra mentioned that spammers could use "IF ENDIF" and provide "FALSE" as a separate witness element, which would also impact legitimate use cases.The topic of spam in Bitcoin transactions was also addressed. The current standardness rules allow for up to 80-byte pushes, resulting in a little over 1% of spam. By consensus, which allows for 520-byte pushes, the percentage is less than 0.2%. To address this issue, suggestions were made to use "OP_2DROP" instead of "OP_DROP OP_DROP" and to prune unused data blobs in the chain. However, switching from witness to non-witness nodes was considered unfeasible due to additional validation requirements and signature invalidation. The idea of storing the first and last chunk of data and preserving the internal state of SHA-256 before entering the last chunk was proposed as a solution for pruning without invalidating signatures.The discussion also touched upon the sentiment expressed in the quote "I disapprove of what you say, but I will defend to the death your right to say it." The author wondered how many Bitcoin developers share this sentiment and raised concerns about censorship and government agencies taking advantage of transaction censorship practices. Testing censorship resistance was deemed important, and an ideal tool for this purpose was suggested. This tool would allow users to construct different types of transactions, broadcast them to specific nodes, verify successful relay or rejection, and ban peers if necessary. The concept of an external mempool was mentioned as a potential solution to avoid censorship in certain cases.Overall, the discussions 2023-02-22T16:39:04+00:00 + In a recent discussion on the bitcoin-dev mailing list, the topic of using static analysis to determine the likelihood of an IF branch being taken in inscription scripts was brought up. Andrew Poelstra suggested that if this filtering could be done reliably and efficiently, it would make inscription scripts more "plausible" but would also increase their space cost by requiring multiple instances of OP_DROP. Peter Todd questioned the actual percentage increase in space cost, with Poelstra estimating a little over 1% according to standardness rules and less than 0.2% according to consensus.The conversation then shifted to the issue of censorship resistance in Bitcoin transactions. There are concerns about certain projects censoring transactions and the potential exploitation of such practices by government agencies. To test if transactions are being relayed by connected peers, two tools were mentioned: counting INV messages and broadcasting transactions to specific nodes using libbtc. A Python script was shared that allows listing peers, broadcasting transactions, and banning peers that do not relay transactions. While the script is primarily for testing purposes, it can be used by anyone who wants to avoid connecting to unhelpful peers. It was noted that there may be some false positives in the results, and the script relies on libbtc.The discussion also touched upon the storage of arbitrary data on-chain and the use of OP_RETURN. The writer argues that commitments should only be stored by nodes that explicitly enable them, as they are additional information that can be skipped if needed. They believe that using OP_RETURN would result in all nodes storing such data, whereas using witness nodes would limit storage to those specifically designed for it. The benefits of inscriptions were also highlighted, including increased interest in running full nodes, trying out bitcoin wallets and lightning, greater adoption of Taproot, and more developers seeking bitcoin development resources.Another email thread focused on spam in Bitcoin transactions. The current standardness rules allow for up to 80-byte pushes, resulting in a little over 1% of spam. By consensus, which allows for 520-byte pushes, the percentage is less than 0.2%. To reduce the number of dropping opcodes, the suggestion is to use "OP_2DROP" instead of "OP_DROP OP_DROP." However, this alone is not enough to reject official alternatives like commitments. The inclusion of spam transactions in the chain is still possible. Pruning unused data blobs in the chain is seen as a solution, but switching from witness to non-witness nodes would require additional validation and invalidate signatures. One proposed solution involves storing the first and last chunk of data and keeping the internal state of SHA-256 before entering the last chunk, allowing for pruning without invalidating signatures. The discussion also mentions the possibility of spammers providing "FALSE" as a separate witness element rather than part of the witnessScript, leading to the use of legitimate "IF ENDIF" cases.In February 2023, Andrew Poelstra suggested using static analysis to determine the likelihood of an IF branch being taken in inscription scripts. This proposal aims to make inscription scripts more "plausible" by requiring the addition of OP_DROP multiple times. The actual percentage increase in space cost was estimated to be a little over 1% according to standardness rules and less than 0.2% according to consensus. The issue of banning specific script fragments was discussed, with concerns raised about spammers using alternative methods to bypass bans. Andrew Poelstra mentioned that spammers could use "IF ENDIF" and provide "FALSE" as a separate witness element, which would also impact legitimate use cases.The topic of spam in Bitcoin transactions was also addressed. The current standardness rules allow for up to 80-byte pushes, resulting in a little over 1% of spam. By consensus, which allows for 520-byte pushes, the percentage is less than 0.2%. To address this issue, suggestions were made to use "OP_2DROP" instead of "OP_DROP OP_DROP" and to prune unused data blobs in the chain. However, switching from witness to non-witness nodes was considered unfeasible due to additional validation requirements and signature invalidation. The idea of storing the first and last chunk of data and preserving the internal state of SHA-256 before entering the last chunk was proposed as a solution for pruning without invalidating signatures.The discussion also touched upon the sentiment expressed in the quote "I disapprove of what you say, but I will defend to the death your right to say it." The author wondered how many Bitcoin developers share this sentiment and raised concerns about censorship and government agencies taking advantage of transaction censorship practices. Testing censorship resistance was deemed important, and an ideal tool for this purpose was suggested. This tool would allow users to construct different types of transactions, broadcast them to specific nodes, verify successful relay or rejection, and ban peers if necessary. The concept of an external mempool was mentioned as a potential solution to avoid censorship in certain cases.Overall, the discussions - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2023/combined_Unenforceable-fee-obligations-in-multiparty-protocols-with-Taproot-inputs.xml b/static/bitcoin-dev/Feb_2023/combined_Unenforceable-fee-obligations-in-multiparty-protocols-with-Taproot-inputs.xml index 96c29b8265..c218adc669 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Unenforceable-fee-obligations-in-multiparty-protocols-with-Taproot-inputs.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Unenforceable-fee-obligations-in-multiparty-protocols-with-Taproot-inputs.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Unenforceable fee obligations in multiparty protocols with Taproot inputs - 2023-08-02T08:55:58.334868+00:00 - - Antoine Riard 2023-02-15 03:33:24+00:00 - - - Anthony Towns 2023-02-12 06:47:31+00:00 - - - Russell O'Connor 2023-02-11 14:40:38+00:00 - - - Anthony Towns 2023-02-11 05:14:55+00:00 - - - Yuval Kogman 2023-02-10 19:35:06+00:00 - - - Russell O'Connor 2023-02-08 14:04:16+00:00 - - - Andrew Poelstra 2023-02-08 14:00:48+00:00 - - - Michael Folkson 2023-02-08 09:34:57+00:00 - - - Antoine Riard 2023-02-08 00:56:30+00:00 - - - Peter Todd 2023-02-07 19:04:00+00:00 - - - Russell O'Connor 2023-02-07 18:35:12+00:00 - - - Peter Todd 2023-02-07 18:12:36+00:00 - - - Andrew Poelstra 2023-02-07 18:10:10+00:00 - - - Andrew Poelstra 2023-02-07 13:46:22+00:00 - - - Peter Todd 2023-02-07 12:50:13+00:00 - - - Nadav Ivgi 2023-02-07 09:36:58+00:00 - - - Lloyd Fournier 2023-02-07 04:38:30+00:00 - - - Yuval Kogman 2023-02-07 02:49:28+00:00 - + 2025-09-26T14:36:05.265717+00:00 + python-feedgen + + + [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs Yuval Kogman + 2023-02-07T02:49:00.000Z + + + Lloyd Fournier + 2023-02-07T04:38:00.000Z + + + Nadav Ivgi + 2023-02-07T09:36:00.000Z + + + Peter Todd + 2023-02-07T12:50:00.000Z + + + Andrew Poelstra + 2023-02-07T13:46:00.000Z + + + Andrew Poelstra + 2023-02-07T18:10:00.000Z + + + Peter Todd + 2023-02-07T18:12:00.000Z + + + Russell O'Connor + 2023-02-07T18:35:00.000Z + + + Peter Todd + 2023-02-07T19:04:00.000Z + + + Antoine Riard + 2023-02-08T00:56:00.000Z + + + Michael Folkson + 2023-02-08T09:34:00.000Z + + + Andrew Poelstra + 2023-02-08T14:00:00.000Z + + + Russell O'Connor + 2023-02-08T14:04:00.000Z + + + Yuval Kogman + 2023-02-10T19:35:00.000Z + + + Anthony Towns + 2023-02-11T05:14:00.000Z + + + Russell O'Connor + 2023-02-11T14:40:00.000Z + + + Anthony Towns + 2023-02-12T06:47:00.000Z + + + Antoine Riard + 2023-02-15T03:33:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Unenforceable fee obligations in multiparty protocols with Taproot inputs - 2023-08-02T08:55:58.334868+00:00 + 2025-09-26T14:36:05.267842+00:00 - Several topics were discussed in a recent conversation regarding the security of multiparty transactions using Taproot. One concern raised was the potential for witness inflation and fee extraction in coinjoin transactions. It was noted that the last signer could manipulate the transaction's feerate by using an inflated witness, causing complications and wasting time value. To address this issue, several strategies were proposed, such as negotiating transactions at a lower feerate, enforcing minimal weights for non-witness data, requiring ownership proofs, and imposing minimum feerates or confirmation ages for inputs. It was also emphasized that full Replace-by-Fee (RBF) is necessary to ensure incentive compatibility in multiparty transactions.Another topic of discussion was a bug identified in Taproot where the same Tapleaf could be repeated multiple times within the same Taproot, potentially with different Taplevels and Tapfee rates. To mitigate this bug, it was recommended to always have knowledge of the entire Taptree when interacting with someone's Tapspend. Additionally, the CODESEPARATOR opcode could be used to prevent signature migration within or between branches.An email conversation between Yuval and LL highlighted a potential attack scenario in multiparty transactions, involving one participant unfairly extracting fee contributions from others. This exploit takes advantage of the variable size of Taproot spends by using a larger signature for the last input signed, reducing the feerate without affecting absolute fees. To prevent this attack, several mitigations were proposed. Negotiating a lower feerate ahead of time and establishing a minimum feerate that the attacker cannot go below was one solution. Another mitigation was enforcing a minimum weight for non-witness data in the transaction before considering it fully constructed. In a centralized setting with BIP-322 ownership proofs, the server could reject signatures that do not match the spend path specified in the ownership proof. Publicly verifiable protocol transcripts and requirements for minimum feerates or confirmation ages for inputs were also suggested as deterrents.Each mitigation proposed has its limitations and trade-offs. Pinning attacks can prevent RBF, but minimum confirmation age may not be applicable to lightning channels. Therefore, it is recommended to implement multiple mitigations simultaneously to effectively prevent this type of attack. 2023-02-15T03:33:24+00:00 + Several topics were discussed in a recent conversation regarding the security of multiparty transactions using Taproot. One concern raised was the potential for witness inflation and fee extraction in coinjoin transactions. It was noted that the last signer could manipulate the transaction's feerate by using an inflated witness, causing complications and wasting time value. To address this issue, several strategies were proposed, such as negotiating transactions at a lower feerate, enforcing minimal weights for non-witness data, requiring ownership proofs, and imposing minimum feerates or confirmation ages for inputs. It was also emphasized that full Replace-by-Fee (RBF) is necessary to ensure incentive compatibility in multiparty transactions.Another topic of discussion was a bug identified in Taproot where the same Tapleaf could be repeated multiple times within the same Taproot, potentially with different Taplevels and Tapfee rates. To mitigate this bug, it was recommended to always have knowledge of the entire Taptree when interacting with someone's Tapspend. Additionally, the CODESEPARATOR opcode could be used to prevent signature migration within or between branches.An email conversation between Yuval and LL highlighted a potential attack scenario in multiparty transactions, involving one participant unfairly extracting fee contributions from others. This exploit takes advantage of the variable size of Taproot spends by using a larger signature for the last input signed, reducing the feerate without affecting absolute fees. To prevent this attack, several mitigations were proposed. Negotiating a lower feerate ahead of time and establishing a minimum feerate that the attacker cannot go below was one solution. Another mitigation was enforcing a minimum weight for non-witness data in the transaction before considering it fully constructed. In a centralized setting with BIP-322 ownership proofs, the server could reject signatures that do not match the spend path specified in the ownership proof. Publicly verifiable protocol transcripts and requirements for minimum feerates or confirmation ages for inputs were also suggested as deterrents.Each mitigation proposed has its limitations and trade-offs. Pinning attacks can prevent RBF, but minimum confirmation age may not be applicable to lightning channels. Therefore, it is recommended to implement multiple mitigations simultaneously to effectively prevent this type of attack. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2024/combined_Adding-New-BIP-Editors.xml b/static/bitcoin-dev/Feb_2024/combined_Adding-New-BIP-Editors.xml index 1a37caf149..d61fb016d6 100644 --- a/static/bitcoin-dev/Feb_2024/combined_Adding-New-BIP-Editors.xml +++ b/static/bitcoin-dev/Feb_2024/combined_Adding-New-BIP-Editors.xml @@ -1,308 +1,411 @@ - + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.152793+00:00 - - Murch 2024-12-10 22:37:00+00:00 - - - Mark Erhardt 2024-09-19 18:48:00+00:00 - - - Antoine Riard 2024-09-19 07:47:00+00:00 - - - Mark Erhardt 2024-09-18 18:25:00+00:00 - - - Murch 2024-05-13 18:33:00+00:00 - - - Antoine Riard 2024-04-25 06:42:00+00:00 - - - Anthony Towns 2024-04-23 22:15:00+00:00 - - - Ali Sherief 2024-04-22 04:28:00+00:00 - - - Steve Lee 2024-04-22 02:44:00+00:00 - - - Ava Chow 2024-04-22 00:06:00+00:00 - - - Matt Corallo 2024-04-21 23:01:00+00:00 - - - Antoine Riard 2024-04-21 20:48:00+00:00 - - - Michael Folkson 2024-04-21 19:18:00+00:00 - - - Ava Chow 2024-04-21 18:47:00+00:00 - - - Michael Folkson 2024-04-21 17:57:00+00:00 - - - Ava Chow 2024-04-21 16:39:00+00:00 - - - Michael Folkson 2024-04-21 11:43:00+00:00 - - - Ava Chow 2024-04-20 23:05:00+00:00 - - - Ava Chow 2024-04-20 22:47:00+00:00 - - - Michael Folkson 2024-04-20 22:21:00+00:00 - - - Steve Lee 2024-04-20 22:03:00+00:00 - - - Ava Chow 2024-04-20 21:37:00+00:00 - - - Steve Lee 2024-04-20 21:11:00+00:00 - - - Ava Chow 2024-04-20 21:08:00+00:00 - - - Ava Chow 2024-04-20 20:59:00+00:00 - - - Steve Lee 2024-04-20 20:46:00+00:00 - - - Michael Folkson 2024-04-20 19:59:00+00:00 - - - Ava Chow 2024-04-20 19:48:00+00:00 - - - Ava Chow 2024-04-20 19:14:00+00:00 - - - Olaoluwa Osuntokun 2024-04-19 22:32:00+00:00 - - - nsvrn 2024-04-17 23:58:00+00:00 - - - Ava Chow 2024-04-16 17:08:00+00:00 - - - NVK 2024-04-16 13:32:00+00:00 - - - Tim Ruffing 2024-04-16 12:34:00+00:00 - - - Matt Corallo 2024-04-15 17:50:00+00:00 - - - Sergi Delgado Segura 2024-04-11 14:22:00+00:00 - - - Ali Sherief 2024-04-07 10:11:00+00:00 - - - Larry Ruane 2024-04-05 19:18:00+00:00 - - - xBC 2024-04-04 12:58:00+00:00 - - - Niklas Goegge 2024-04-04 09:09:00+00:00 - - - Anthony Towns 2024-04-04 05:00:00+00:00 - - - Pieter Wuille 2024-04-03 19:44:00+00:00 - - - Fabian 2024-04-03 18:34:00+00:00 - - - Vasil Dimov 2024-04-03 17:24:00+00:00 - - - Juan Galt 2024-04-03 16:58:00+00:00 - - - Murch 2024-04-03 15:03:00+00:00 - - - Luke Dashjr 2024-04-02 15:39:00+00:00 - - - Gloria Zhao 2024-04-02 15:13:00+00:00 - - - Luke Dashjr 2024-04-02 14:28:00+00:00 - - - nvk 2024-04-02 14:24:00+00:00 - - - /dev /fd 2024-04-02 13:49:00+00:00 - - - Tim Ruffing 2024-04-02 13:17:00+00:00 - - - Michael Folkson 2024-04-02 08:18:00+00:00 - - - Ava Chow 2024-04-02 00:37:00+00:00 - - - /dev /fd 2024-04-01 23:55:00+00:00 - - - David A. Harding 2024-04-01 21:13:00+00:00 - - - Antoine Riard 2024-04-01 20:14:00+00:00 - - - Jonas Nick 2024-04-01 18:42:00+00:00 - - - Murch 2024-04-01 18:41:00+00:00 - - - Michael Folkson 2024-04-01 11:58:00+00:00 - - - /dev /fd 2024-04-01 06:21:00+00:00 - - - Ava Chow 2024-03-31 17:01:00+00:00 - - - Michael Folkson 2024-03-31 16:01:00+00:00 - - - Antoine Riard 2024-03-30 20:01:00+00:00 - - - Michael Folkson 2024-03-30 11:51:00+00:00 - - - Peter Todd 2024-03-30 04:04:00+00:00 - - - Keagan McClelland 2024-03-29 22:17:00+00:00 - - - Antoine Riard 2024-03-29 21:08:00+00:00 - - - /dev /fd 2024-03-29 05:24:00+00:00 - - - Michael Folkson 2024-03-29 02:34:00+00:00 - - - Matt Corallo 2024-03-28 21:19:00+00:00 - - - John C. Vernaleo 2024-03-28 20:59:00+00:00 - - - Matt Corallo 2024-03-28 20:31:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Antoine Riard 2024-03-28 19:42:00+00:00 - - - /dev /fd 2024-03-28 16:09:00+00:00 - - - Brandon Black 2024-03-28 15:50:00+00:00 - - - Murch 2024-03-28 13:02:00+00:00 - - - Matt Corallo 2024-03-27 23:54:00+00:00 - - - John C. Vernaleo 2024-03-27 23:39:00+00:00 - - - Murch 2024-03-27 23:36:00+00:00 - - - Murch 2024-03-27 21:25:00+00:00 - - - Chris Stewart 2024-03-14 11:56:00+00:00 - - - Jon A 2024-03-11 16:48:00+00:00 - - - Bitcoin Error Log 2024-03-10 17:27:00+00:00 - - - Michael Folkson 2024-03-09 10:46:00+00:00 - - - Keagan McClelland 2024-03-07 22:39:00+00:00 - - - Antoine Riard 2024-03-07 20:56:00+00:00 - - - Tim Ruffing 2024-02-28 16:31:00+00:00 - - - bitcoindevml.void 2024-02-28 11:12:00+00:00 - - - /dev /fd 2024-02-28 04:22:00+00:00 - - - Ava Chow 2024-02-27 23:26:00+00:00 - - - /dev /fd 2024-02-27 23:10:00+00:00 - - - Luke Dashjr 2024-02-27 22:57:00+00:00 - - - Luke Dashjr 2024-02-27 22:40:00+00:00 - - - Greg Tonoski 2024-02-27 21:48:00+00:00 - - - Léo Haf 2024-02-27 21:33:00+00:00 - - - Ava Chow 2024-02-27 20:11:00+00:00 - - - Ava Chow 2024-02-27 18:53:00+00:00 - + 2025-09-26T14:23:10.754305+00:00 + python-feedgen + + + Adding New BIP Editors 'Ava Chow' + 2024-02-27T18:53:00.000Z + + + Léo Haf' + 2024-02-27T20:11:00.000Z + + + Antoine Poinsot' + 2024-02-27T21:33:00.000Z + + + Greg Tonoski + 2024-02-27T21:48:00.000Z + + + Luke Dashjr + 2024-02-27T22:40:00.000Z + + + Ava Chow' + 2024-02-27T22:57:00.000Z + + + /dev /fd0 + 2024-02-27T23:10:00.000Z + + + Steve Lee + 2024-02-27T23:26:00.000Z + + + /dev /fd0 + 2024-02-28T04:22:00.000Z + + + bitcoin-dev-ml.void867 + 2024-02-28T11:12:00.000Z + + + Tim Ruffing + 2024-02-28T16:31:00.000Z + + + Antoine Riard + 2024-03-07T20:56:00.000Z + + + Keagan McClelland + 2024-03-07T22:39:00.000Z + + + Michael Folkson + 2024-03-09T10:46:00.000Z + + + Bitcoin Error Log + 2024-03-10T17:27:00.000Z + + + Jon A + 2024-03-11T16:48:00.000Z + + + Chris Stewart + 2024-03-14T11:56:00.000Z + + + Murch + 2024-03-27T21:25:00.000Z + + + Keagan McClelland + 2024-03-27T23:36:00.000Z + + + John C. Vernaleo + 2024-03-27T23:39:00.000Z + + + Matt Corallo + 2024-03-27T23:54:00.000Z + + + Murch + 2024-03-28T13:02:00.000Z + + + Brandon Black + 2024-03-28T15:50:00.000Z + + + /dev /fd0 + 2024-03-28T16:09:00.000Z + + + Antoine Riard + 2024-03-28T19:42:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Antoine Riard + 2024-03-28T20:31:00.000Z + + + John C. Vernaleo + 2024-03-28T20:59:00.000Z + + + Matt Corallo + 2024-03-28T21:19:00.000Z + + + Michael Folkson + 2024-03-29T02:34:00.000Z + + + /dev /fd0 + 2024-03-29T05:24:00.000Z + + + Antoine Riard + 2024-03-29T21:08:00.000Z + + + Keagan McClelland + 2024-03-29T22:17:00.000Z + + + Peter Todd + 2024-03-30T04:04:00.000Z + + + Michael Folkson + 2024-03-30T11:51:00.000Z + + + Antoine Riard + 2024-03-30T20:01:00.000Z + + + Michael Folkson + 2024-03-31T16:01:00.000Z + + + Ava Chow' + 2024-03-31T17:01:00.000Z + + + /dev /fd0 + 2024-04-01T06:21:00.000Z + + + Michael Folkson + 2024-04-01T11:58:00.000Z + + + Re: Adding New BIP Editors Murch + 2024-04-01T18:41:00.000Z + + + Jonas Nick + 2024-04-01T18:42:00.000Z + + + Antoine Riard + 2024-04-01T20:14:00.000Z + + + David A. Harding + 2024-04-01T21:13:00.000Z + + + /dev /fd0 + 2024-04-01T23:55:00.000Z + + + Ava Chow' + 2024-04-02T00:37:00.000Z + + + Michael Folkson + 2024-04-02T08:18:00.000Z + + + Time for an update to BIP2? Tim Ruffing + 2024-04-02T13:17:00.000Z + + + /dev /fd0 + 2024-04-02T13:49:00.000Z + + + nvk + 2024-04-02T14:24:00.000Z + + + Luke Dashjr + 2024-04-02T14:28:00.000Z + + + Gloria Zhao + 2024-04-02T15:13:00.000Z + + + Luke Dashjr + 2024-04-02T15:39:00.000Z + + + Murch + 2024-04-03T15:03:00.000Z + + + Juan Galt + 2024-04-03T16:58:00.000Z + + + Vasil Dimov + 2024-04-03T17:24:00.000Z + + + Fabian' + 2024-04-03T18:34:00.000Z + + + Pieter Wuille + 2024-04-03T19:44:00.000Z + + + Anthony Towns + 2024-04-04T05:00:00.000Z + + + Niklas Goegge + 2024-04-04T09:09:00.000Z + + + Adding New BIP Editors 0xB10C + 2024-04-04T12:58:00.000Z + + + Larry Ruane + 2024-04-05T19:18:00.000Z + + + Ali Sherief + 2024-04-07T10:11:00.000Z + + + Sergi Delgado Segura + 2024-04-11T14:22:00.000Z + + + Matt Corallo + 2024-04-15T17:50:00.000Z + + + Tim Ruffing + 2024-04-16T12:34:00.000Z + + + NVK + 2024-04-16T13:32:00.000Z + + + Ava Chow' + 2024-04-16T17:08:00.000Z + + + nsvrn' + 2024-04-17T23:58:00.000Z + + + Olaoluwa Osuntokun + 2024-04-19T22:32:00.000Z + + + Ava Chow' + 2024-04-20T19:14:00.000Z + + + NVK + 2024-04-20T19:48:00.000Z + + + Michael Folkson + 2024-04-20T19:59:00.000Z + + + Steve Lee + 2024-04-20T20:46:00.000Z + + + Ava Chow' + 2024-04-20T20:59:00.000Z + + + Ava Chow' + 2024-04-20T21:08:00.000Z + + + Steve Lee + 2024-04-20T21:11:00.000Z + + + Ava Chow' + 2024-04-20T21:37:00.000Z + + + Steve Lee + 2024-04-20T22:03:00.000Z + + + Michael Folkson + 2024-04-20T22:21:00.000Z + + + Ava Chow' + 2024-04-20T22:47:00.000Z + + + Ava Chow' + 2024-04-20T23:05:00.000Z + + + Michael Folkson + 2024-04-21T11:43:00.000Z + + + Ava Chow' + 2024-04-21T16:39:00.000Z + + + Michael Folkson + 2024-04-21T17:57:00.000Z + + + Ava Chow' + 2024-04-21T18:47:00.000Z + + + Michael Folkson + 2024-04-21T19:18:00.000Z + + + Antoine Riard + 2024-04-21T20:48:00.000Z + + + Matt Corallo + 2024-04-21T23:01:00.000Z + + + Ava Chow' + 2024-04-22T00:06:00.000Z + + + Steve Lee + 2024-04-22T02:44:00.000Z + + + Ali Sherief + 2024-04-22T04:28:00.000Z + + + Anthony Towns + 2024-04-23T22:15:00.000Z + + + Antoine Riard + 2024-04-25T06:42:00.000Z + + + Time for an update to BIP2? Murch + 2024-05-13T18:33:00.000Z + + + Murch + 2024-09-18T18:25:00.000Z + + + Antoine Riard + 2024-09-19T07:47:00.000Z + + + Murch + 2024-09-19T18:48:00.000Z + + + Murch + 2024-12-10T22:37:00.000Z + + @@ -403,21 +506,17 @@ - python-feedgen + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.153617+00:00 + 2025-09-26T14:23:10.766294+00:00 + 2024-12-10T22:37:00+00:00 In the realm of Bitcoin development, discussions pertaining to the enhancement of the Bitcoin Improvement Proposal (BIP) process have been prominent. A key focus has been on addressing the current bottleneck in managing BIPs, emphasized by Luke Dashjr's acknowledgment of his limited capacity to actively maintain the BIPs repository. This acknowledgment underscores the critical need for additional BIP editors to ensure an efficient and effective review and integration process for new proposals and amendments to existing ones. - The role of a BIP editor is significant, encompassing responsibilities such as assigning BIP numbers, merging pull requests for new proposals, making fixes to existing BIPs, and more, as outlined in BIP 2. The addition of new editors is envisaged as a pivotal measure to alleviate the backlog of submissions and augment the process's overall productivity. For the continuity and coherence of the BIP numbering system, it is imperative that any incoming editors concur on the established numbering scheme. - The selection criteria for new BIP editors highlight the necessity for candidates with a comprehensive background in Bitcoin development, showcasing a history of active participation and contributions. These individuals must possess the ability to impartially assess proposals, a quality that underscores the importance of objectivity in the role. - Within this context, Kanzure and RubenSomsen have been identified as exemplary candidates for the position of BIP editors. Their extensive involvement in Bitcoin development positions them as valuable additions to the editorial team. Their potential inclusion is anticipated to significantly ameliorate the management and advancement of the BIPs repository, offering substantial benefits to the Bitcoin development community. - This dialogue illustrates the collective effort within the Bitcoin developer ecosystem to refine the governance mechanisms surrounding BIPs. It emphasizes the commitment to ensuring that the process remains robust, transparent, and inclusive, facilitating the continuous evolution and improvement of Bitcoin. - 2024-12-10T22:37:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2024/combined_CheckTemplateVerify-Does-Not-Scale-Due-to-UTXO-s-Required-For-Fee-Payment.xml b/static/bitcoin-dev/Feb_2024/combined_CheckTemplateVerify-Does-Not-Scale-Due-to-UTXO-s-Required-For-Fee-Payment.xml index acc574bcf9..4f898d81cc 100644 --- a/static/bitcoin-dev/Feb_2024/combined_CheckTemplateVerify-Does-Not-Scale-Due-to-UTXO-s-Required-For-Fee-Payment.xml +++ b/static/bitcoin-dev/Feb_2024/combined_CheckTemplateVerify-Does-Not-Scale-Due-to-UTXO-s-Required-For-Fee-Payment.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment - 2024-03-05T18:23:59.543786+00:00 - - jlspc 2024-02-20 23:13:00+00:00 - - - Peter Todd 2024-01-30 08:40:41+00:00 - - - Anthony Towns 2024-01-30 05:55:09+00:00 - - - ZmnSCPxj 2024-01-30 05:17:04+00:00 - - - ZmnSCPxj 2024-01-30 05:07:16+00:00 - - - Peter Todd 2024-01-30 04:49:57+00:00 - - - Peter Todd 2024-01-30 04:46:27+00:00 - - - Peter Todd 2024-01-30 04:41:30+00:00 - - - Peter Todd 2024-01-30 04:38:26+00:00 - - - ZmnSCPxj 2024-01-30 04:12:07+00:00 - - - Brandon Black 2024-01-27 06:28:54+00:00 - - - jlspc 2024-01-25 17:49:26+00:00 - - - Michael Folkson 2024-01-25 12:57:52+00:00 - - - Peter Todd 2024-01-24 19:31:07+00:00 - + 2025-09-26T14:23:04.211740+00:00 + python-feedgen + + + [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment Peter Todd + 2024-01-24T19:31:00.000Z + + + Michael Folkson + 2024-01-25T12:57:00.000Z + + + [bitcoin-dev] " jlspc + 2024-01-25T17:49:00.000Z + + + Brandon Black + 2024-01-27T06:28:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2024-01-30T04:12:00.000Z + + + Peter Todd + 2024-01-30T04:38:00.000Z + + + Peter Todd + 2024-01-30T04:41:00.000Z + + + Peter Todd + 2024-01-30T04:46:00.000Z + + + Peter Todd + 2024-01-30T04:49:00.000Z + + + ZmnSCPxj + 2024-01-30T05:07:00.000Z + + + ZmnSCPxj + 2024-01-30T05:17:00.000Z + + + Anthony Towns + 2024-01-30T05:55:00.000Z + + + Peter Todd + 2024-01-30T08:40:00.000Z + + + jlspc' + 2024-02-20T23:13:00.000Z + + @@ -59,23 +76,18 @@ - python-feedgen + 2 Combined summary - CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment - 2024-03-05T18:23:59.546783+00:00 + 2025-09-26T14:23:04.213469+00:00 + 2024-02-20T23:13:00+00:00 The email discussion initiates with a focus on Bitcoin's security model, emphasizing the importance of aligning miners' economic incentives with on-chain activities to safeguard the network. It highlights the risks posed by offchain payments to miners, such as those from anchor outputs, which could potentially undermine the designed economic incentives crucial for Bitcoin's security. The conversation also addresses vulnerabilities associated with feerate-dependent timelocks (FDTs) in securing Layer 2 protocols, suggesting that while FDTs could be manipulated by miners, protections similar to those against double-spend attacks might also defend against such manipulation. The underlying argument stresses the necessity for the majority of hash power to refrain from collusion in malpractices. - Further examination reveals shifts in fee payment responsibilities within the Lightning Network due to V3 transactions and commitment transactions with zero fees, relying on anchor outputs and CPFP mechanisms for fee adjustments. This leads to scenarios where recipients may bear disproportionate transaction costs. The dialogue suggests improvements in negotiating minimum commitment transaction fee rates to address challenges and inefficiencies within the Lightning Network's current fee adjustment mechanisms. - Technical aspects of Bitcoin Improvement Proposals (BIPs), particularly BIP 118 and its implications on transaction digest algorithms, are discussed. BIP 118 introduces changes like the SIGHASH_NOINPUT signature type, affecting transaction malleability and flexibility, contrasting with BIP 143, which established a new algorithm for version 0 witness programs. These discussions highlight the evolving nature of Bitcoin's transaction verification processes. - -The Decker-Russell-Osuntokun (DRS) protocol is examined for its complexities in managing transaction fees and maintaining channel integrity within layer-2 solutions like the Lightning Network. The "initiator pays" principle for onchain fees is defended to deter potential abuses, emphasizing strategic considerations in safeguarding network operations. - +The Decker-Russell-Osuntokun (DRS) protocol is examined for its complexities in managing transaction fees and maintaining channel integrity within layer-2 solutions like the Lightning Network. The "initiator pays" principle for onchain fees is defended to deter potential abuses, emphasizing strategic considerations in safeguarding network operations. The email further explores concerns around fee-rate-dependent timelocks, CPFP versus RBF mechanisms, and broader discussions on optimizing Bitcoin's scalability and miner incentivization models. These insights delve into ongoing debates over transaction fee policies, their impact on mining decentralization, and the search for efficient standards like CTV that accommodate dynamic fee structures without compromising network integrity. - Lastly, CheckTemplateVerify (CTV) and Taproot are scrutinized for their roles in addressing fee variant complexities within cryptocurrency transaction scripting. This underlines Bitcoin's continuous evolution in scripting capabilities to enhance efficiency and security. For further exploration of these topics, references are made to the [Lightning Development Mailing List](https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004254.html), Michael Folkson's [YouTube channel](https://www.youtube.com/@portofbitcoin), and the [Bitcoin Improvement Proposals on GitHub](https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0119.mediawiki), including [Peter Todd's review on v3 transactions](https://petertodd.org/2023/v3-transactions-reviewanchor-outputs-are-a-danger-to-mining-decentralization). - 2024-02-20T23:13:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2024/combined_Over-Half-of-Replace-by-Fee-Rate-Replacements-Are-Mined.xml b/static/bitcoin-dev/Feb_2024/combined_Over-Half-of-Replace-by-Fee-Rate-Replacements-Are-Mined.xml index 7b83b63b9b..7b5cb85296 100644 --- a/static/bitcoin-dev/Feb_2024/combined_Over-Half-of-Replace-by-Fee-Rate-Replacements-Are-Mined.xml +++ b/static/bitcoin-dev/Feb_2024/combined_Over-Half-of-Replace-by-Fee-Rate-Replacements-Are-Mined.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - Over Half of Replace-by-Fee-Rate Replacements Are Mined - 2024-03-05T18:29:04.252888+00:00 - - Peter Todd 2024-02-24 22:25:00+00:00 - - - Nagaev Boris 2024-02-24 20:54:00+00:00 - - - Peter Todd 2024-02-24 18:45:00+00:00 - - - Nagaev Boris 2024-02-24 17:55:00+00:00 - - - Peter Todd 2024-02-24 15:58:00+00:00 - + 2025-09-26T14:23:08.474170+00:00 + python-feedgen + + + Over Half of Replace-by-Fee-Rate Replacements Are Mined Peter Todd + 2024-02-24T15:58:00.000Z + + + Nagaev Boris + 2024-02-24T17:55:00.000Z + + + Peter Todd + 2024-02-24T18:45:00.000Z + + + Nagaev Boris + 2024-02-24T20:54:00.000Z + + + Peter Todd + 2024-02-24T22:25:00.000Z + + - python-feedgen + 2 Combined summary - Over Half of Replace-by-Fee-Rate Replacements Are Mined - 2024-03-05T18:29:04.252888+00:00 + 2025-09-26T14:23:08.474976+00:00 + 2024-02-24T22:25:00+00:00 In recent discussions regarding the implementation of Replace-By-Fee-Rate (RBFR) in Bitcoin's transaction processing, various aspects of RBFR's mechanics, implications, and potential applications have been explored. One critical aspect is the selection of an appropriate coefficient for fee rate increase to prevent both overpayment by users and potential Denial-of-Service (DoS) attacks through minimal fee increments. The debate revolves around finding a balance that would not overly burden users with high fees while maintaining network security against DoS attacks. A proposed 2x coefficient aims to make DoS attacks costly while still effectively preventing pinning attacks, which could hinder the progress of smart contract protocols like Lightning. However, concerns about overpaying and the potential for a lower coefficient, such as 1.1x, to fulfill the dual purpose of affordability and security have been raised. - The Libre Relay implementation, a prototype fork of Bitcoin Core v26.0, introduces Pure RBFR with a 2x ratio, allowing transactions to be replaced if their fee rate is at least double that of the previous transactions. This policy significantly benefits Lightning and similar systems by ensuring transactions can always progress by offering sufficiently high fees. Despite initial data showing that a substantial portion of RBFR replacements are mined, indicating that miners may miss out on profitable transactions by not adopting RBFR, the approach's overall feasibility remains under discussion. Notably, the Libre Relay's RBFR mechanism operates independently of the general mempool conditions, providing a memoryless transaction replacement strategy that does not strictly adhere to expected next block feerate limits. - Furthermore, the dialogue includes technical insights into calculating the number of possible replacements an attacker could perform before reaching the next block's fee rate, emphasizing the importance of obtaining historical data on purging and next block feerates. Such analyses could inform the development of more refined RBFR strategies that balance between minimizing DoS attack viability and ensuring fair cost for legitimate users. - Lastly, the exploration of RBFR's implementation details, including simple code snippets demonstrating how fee rate increases could be assessed, underscores the ongoing efforts to refine Bitcoin's transaction policies for enhanced efficiency and security. These discussions, enriched by contributions from various stakeholders in the Bitcoin community, highlight the evolving nature of blockchain technology management and the continuous search for optimal solutions to complex problems. - 2024-02-24T22:25:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2024/combined_bitcoin-dev-Mailing-List-Migration-Action-Required-.xml b/static/bitcoin-dev/Feb_2024/combined_bitcoin-dev-Mailing-List-Migration-Action-Required-.xml index 369c0c1119..6dfc0fd413 100644 --- a/static/bitcoin-dev/Feb_2024/combined_bitcoin-dev-Mailing-List-Migration-Action-Required-.xml +++ b/static/bitcoin-dev/Feb_2024/combined_bitcoin-dev-Mailing-List-Migration-Action-Required-.xml @@ -1,27 +1,26 @@ - + 2 Combined summary - bitcoin-dev Mailing List Migration (Action Required) - 2024-03-05T18:26:49.954818+00:00 - - Bryan Bishop 2024-02-09 20:34:00+00:00 - - - Bryan Bishop 2024-02-09 20:32:04+00:00 - + 2025-09-26T14:23:06.327645+00:00 + python-feedgen + + + UTC | newest] + 2024-02-09T20:34:00.000Z + + - python-feedgen + 2 Combined summary - bitcoin-dev Mailing List Migration (Action Required) - 2024-03-05T18:26:49.955813+00:00 + 2025-09-26T14:23:06.327990+00:00 + 2024-02-09T20:34:00+00:00 The bitcoindev mailing list has successfully transitioned to Google Groups, marking the end of accepting subscriptions through the old system as of February 2024. To ensure continued participation and receipt of emails, it's crucial for members and interested parties to subscribe to the new platform without delay. The transition will include a brief pause before allowing new emails to ensure everyone has ample time to join. Subscription can be achieved in two ways: sending an email to a specified address and replying to an automated response—checking the spam folder if necessary—or by subscribing via the online interface at [Google Groups](https://groups.google.com/g/bitcoindev) using any email associated with a Google account. Active involvement in the community discussions is encouraged by opting to receive all messages, which facilitates easy replies and interaction within threads. To avoid cluttering one's main inbox, setting up a filter for the specific mailing list address is advised. - Further enhancing accessibility, the mailing list archive is available online and backed externally, ensuring that both new and historical content remains accessible without requiring a Google account at [gnusha.org](https://gnusha.org/pi/bitcoindev). While Google's platform is utilized for distribution, the emphasis on not relying solely on Google underscores a commitment to maintaining public access to information. The initiative to create additional public archives of the mailing list is encouraged, with straightforward instructions provided for anyone interested in hosting. Details of such archives should be shared with the moderators once set up. A comprehensive archive of the bitcoin-dev mailing list, including detailed instructions for verification, is available at [diyhpl.us](https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/bitcoin-dev-ml-archive.2024-02-09-004.tar.gz), ensuring the preservation of the mailing list’s integrity and history. - Mailing lists serve as a broad communication medium with limited moderation, emphasizing the importance of considering the broader audience when posting, especially for new topics, to maintain a productive signal-to-noise ratio. The rules governing the list have remained unchanged, accessible for review to ensure compliance and understanding of community standards. Appreciation was expressed towards Joe Rayhawk for his assistance with the migration, highlighting the collaborative effort involved in the process. For additional support or inquiries, moderator contact information is provided, facilitating open communication and assistance for members of the mailing list community. - 2024-02-09T20:34:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_Announcing-Bitcoin-BOSD-Standardized-Withdrawal-Output-Specification-for-L2s.xml b/static/bitcoin-dev/Feb_2025/combined_Announcing-Bitcoin-BOSD-Standardized-Withdrawal-Output-Specification-for-L2s.xml index 4974d7886b..7d0cc9dced 100644 --- a/static/bitcoin-dev/Feb_2025/combined_Announcing-Bitcoin-BOSD-Standardized-Withdrawal-Output-Specification-for-L2s.xml +++ b/static/bitcoin-dev/Feb_2025/combined_Announcing-Bitcoin-BOSD-Standardized-Withdrawal-Output-Specification-for-L2s.xml @@ -1,35 +1,37 @@ - + 2 Combined summary - Announcing Bitcoin BOSD: Standardized Withdrawal Output Specification for L2s - 2025-02-24T02:25:16.252568+00:00 - - David A. Harding 2025-02-19 02:29:00+00:00 - - - Martin Habovštiak 2025-02-16 08:50:00+00:00 - - - Jose Storopoli 2025-02-15 11:37:00+00:00 - + 2025-09-26T14:33:11.880834+00:00 + python-feedgen + + + Announcing Bitcoin BOSD: Standardized Withdrawal Output Specification for L2s Jose Storopoli + 2025-02-15T11:37:00.000Z + + + Martin Habovštiak + 2025-02-16T08:50:00.000Z + + + David A. Harding + 2025-02-19T02:29:00.000Z + + - python-feedgen + 2 Combined summary - Announcing Bitcoin BOSD: Standardized Withdrawal Output Specification for L2s - 2025-02-24T02:25:16.252614+00:00 + 2025-09-26T14:33:11.881368+00:00 + 2025-02-19T02:29:00+00:00 The communication delves into the development and application of the Bitcoin Output Script Descriptor (BOSD), a new specification designed to enhance the on-chain withdrawal process for Bitcoin Layer 2 (L2) solutions. BOSD aims to ensure that withdrawal outputs are standard by construction, removing the need for L2 solutions to implement separate rules for transaction compliance with the Bitcoin network's standardness requirements. This is particularly beneficial in mitigating risks associated with non-standard transactions, such as those involving oversized OP_RETURN outputs, which could potentially compromise the integrity and reliability of Bitcoin’s L2 infrastructure. - The introduction of BOSD represents a significant step towards simplifying the validation logic required for processing transactions, thereby streamlining the operations of Bitcoin L2 solutions. By providing a compact representation of withdrawal outputs that adheres to Bitcoin's standardness rules, BOSD facilitates a more efficient and reliable framework for transaction validation. The open-source Rust implementation of BOSD is available on [crates.io](https://crates.io/crates/bitcoin-bosd), encouraging developers and stakeholders to explore its features and contribute to its development. Detailed information about BOSD, including its motivation, technical specifications, and creation rationale, can be found in the [SPECIFICATION.md document](https://github.com/alpenlabs/bitcoin-bosd/blob/main/SPECIFICATION.md) hosted on GitHub, where community feedback through issues and discussions is welcomed. - The problem of handling transactions that exceed the byte limitations set by Bitcoin Core's standard transaction rules is addressed through an insightful discussion on the challenges posed by OP_RETURN outputs larger than 83 bytes. This highlights the plight of users whose transactions might not be relayed to compatible miners due to exceeding the 80 push bytes limit, necessitating alternative solutions. The discourse critiques impractical solutions such as creating type 5 transactions or extending numeric ranges to bypass byte limits, advocating instead for a more pragmatic approach that allows for local verification on raw() descriptors. This would enable the modification of a single line of code to accept larger data carrier outputs, offering a flexible solution for accommodating non-standard transaction sizes without requiring central coordination or risking rejection based on non-standard sizes. - -Furthermore, there's a consideration of terminological clarity within the developmental community, emphasizing the importance of distinct naming conventions to prevent confusion. This comes in light of the term BOSD potentially conflating with "output script descriptors," a concept introduced by Bitcoin Core developers in 2018. The discussion also includes a proposal to adopt clearer terminology for better understanding and collaboration among developers. - +Furthermore, there's a consideration of terminological clarity within the developmental community, emphasizing the importance of distinct naming conventions to prevent confusion. This comes in light of the term BOSD potentially conflating with "output script descriptors," a concept introduced by Bitcoin Core developers in 2018. The discussion also includes a proposal to adopt clearer terminology for better understanding and collaboration among developers. In conclusion, the Bitcoin Output Script Descriptor (BOSD) presents a streamlined and standardized approach to handling on-chain withdrawals in Bitcoin's Layer 2 ecosystem, aiming to reduce fragmentation and enhance interoperability across different L2 solutions. Through its compact representation and emphasis on efficiency, BOSD addresses critical challenges within the Bitcoin network, fostering a more robust and cohesive framework for transaction validation and compliance. - 2025-02-19T02:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_Call-for-reconfiguration-of-nodes-to-relay-transactions-with-fee-rates-below-1-sat-vbyte.xml b/static/bitcoin-dev/Feb_2025/combined_Call-for-reconfiguration-of-nodes-to-relay-transactions-with-fee-rates-below-1-sat-vbyte.xml index 0fb5289de3..4cbf672ea4 100644 --- a/static/bitcoin-dev/Feb_2025/combined_Call-for-reconfiguration-of-nodes-to-relay-transactions-with-fee-rates-below-1-sat-vbyte.xml +++ b/static/bitcoin-dev/Feb_2025/combined_Call-for-reconfiguration-of-nodes-to-relay-transactions-with-fee-rates-below-1-sat-vbyte.xml @@ -1,47 +1,52 @@ - + 2 Combined summary - Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte - 2025-02-04T02:21:50.837876+00:00 - - Murch 2025-02-03 19:42:00+00:00 - - - Sjors Provoost 2025-01-31 15:13:00+00:00 - - - Sjors Provoost 2025-01-31 14:40:00+00:00 - - - Greg Tonoski 2025-01-31 13:43:00+00:00 - - - Sjors Provoost 2025-01-31 12:54:00+00:00 - - - Greg Tonoski 2025-01-31 08:49:00+00:00 - + 2025-09-26T14:33:13.993189+00:00 + python-feedgen + + + Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte Greg Tonoski + 2025-01-31T08:49:00.000Z + + + Sjors Provoost + 2025-01-31T12:54:00.000Z + + + Greg Tonoski + 2025-01-31T13:43:00.000Z + + + Sjors Provoost + 2025-01-31T14:40:00.000Z + + + Sjors Provoost + 2025-01-31T15:13:00.000Z + + + Murch + 2025-02-03T19:42:00.000Z + + - python-feedgen + 2 Combined summary - Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte - 2025-02-04T02:21:50.837940+00:00 + 2025-09-26T14:33:13.994096+00:00 + 2025-02-03T19:42:00+00:00 The recent discussions on the Bitcoin Development Mailing List have brought several key topics to light, particularly focusing on the optimization and management of system resources like bandwidth and CPU in the context of Bitcoin's operational efficiency. The conversation underscored the importance of these resources in maintaining the scalability, speed, and reliability of Bitcoin transactions and operations. It was elucidated that understanding the balance and consumption of bandwidth and CPU usage stands critical for developers striving to enhance Bitcoin's infrastructure. This dialogue signifies the ongoing efforts within the community to address and mitigate evolving challenges, ensuring the network's robustness. - Sjors Provoost introduced an insightful perspective on managing transaction fees on the network. He suggested the utilization of the `prioritisetransaction` RPC for selectively including low or zero-fee transactions in blocks, compensating through other means such as alternative payment networks. This approach underscores a nuanced understanding of transaction prioritization, extending beyond mere fee structures. Provoost also highlighted the significance of considering technical resources like bandwidth, memory, and CPU usage in transaction processing, which are vital for the network’s efficiency and cost-effectiveness. This discussion brings forth a broader view of blockchain economics, emphasizing the importance of optimizing various system resources alongside transaction fee structures to sustain network health and performance. - A consensus emerged around configuring `-incrementalrelayfee=0` to complement `minrelaytxfee=0.00000001`, challenging previous concerns over DoS attack risks due to low transaction fees. This is based on observations that miners might already operate with a `-blockmintxfee` set to `0` or lower, evidenced by zero-fee transactions in blocks. Furthermore, it was argued that Bitcoin's current operational parameters, including a default mempool size limit of 300MB and a timeout of 336 hours for unconfirmed transactions, effectively mitigate potential DoS attacks facilitated by low fee-rate transactions. These safeguards support the argument for potentially lowering transaction fees without compromising security. - In terms of transaction fee adjustments, a cautious approach was advised when setting `-incrementalrelayfee`, suggesting a minor increase from 0.001 satoshis per virtual byte to 0.002, requiring miner cooperation to avoid transactions stagnating in the mempool. This strategy acknowledges the risk of lowering the cost barrier for DoS attacks but also considers the changing landscape with the Lightning Network's introduction. The discussion acknowledged that maintaining somewhat elevated fee levels could deter new forms of economically viable attacks, highlighting the evolving considerations in the ecosystem regarding fee adjustments. - Lastly, there's an ongoing debate about adjusting the default minimum relay transaction fee, which has remained at 1 sat/vbyte since 2013. Given the significant increase in Bitcoin's value, there's a proposition to lower the `minrelaytxfee` to 0.00000001 or 0.001 sat/vbyte to facilitate transactions with lower fee rates, such as consolidation and multisig operations. This adjustment aims at improving the efficiency and accessibility of the Bitcoin network for a variety of operations, reflecting directly on node operation and configuration practices within the community. - 2025-02-03T19:42:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_Finished-planned-work-on-BIP-3-Updated-BIP-Process.xml b/static/bitcoin-dev/Feb_2025/combined_Finished-planned-work-on-BIP-3-Updated-BIP-Process.xml index 4d3179f21b..16ae486f9f 100644 --- a/static/bitcoin-dev/Feb_2025/combined_Finished-planned-work-on-BIP-3-Updated-BIP-Process.xml +++ b/static/bitcoin-dev/Feb_2025/combined_Finished-planned-work-on-BIP-3-Updated-BIP-Process.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Finished planned work on BIP 3: Updated BIP Process - 2025-03-29T02:31:25.297115+00:00 - - Antoine Poinsot 2025-03-28 17:21:00+00:00 - - - Murch 2025-03-19 02:38:00+00:00 - - - Murch 2025-02-03 19:11:00+00:00 - + 2025-09-26T14:33:22.555420+00:00 + python-feedgen + + + Finished planned work on BIP 3: Updated BIP Process Murch + 2025-02-03T19:11:00.000Z + + + Murch + 2025-03-19T02:38:00.000Z + + + Antoine Poinsot' + 2025-03-28T17:21:00.000Z + + - python-feedgen + 2 Combined summary - Finished planned work on BIP 3: Updated BIP Process - 2025-03-29T02:31:25.297175+00:00 + 2025-09-26T14:33:22.555932+00:00 + 2025-03-28T17:21:00+00:00 The recent communications and developments regarding the Bitcoin Improvement Proposals (BIPs) underscore a significant advancement in the evolution of the Bitcoin protocol. A particular focus has been placed on BIP3, which has undergone various stages of review and refinement, signaling its readiness for broader adoption within the Bitcoin community. Following its merge as a Draft on February 20th and subsequent minor updates, a period of over three weeks passed without any further feedback, suggesting a consensus among stakeholders on its readiness. The current proposal to advance BIP3 to the status of Proposed marks a crucial step towards its implementation. Stakeholders are encouraged to share their comments, suggestions, or concerns through the provided [GitHub link](https://github.com/bitcoin/bips/pull/1794), via email, or other communication channels associated with the Bitcoin Development Mailing List group. - In detailing the process of updating the BIP procedure, it's noted that significant efforts have been made by developers to refine the proposal. Initially conducted in a private repository, the work was later moved to the public domain through a pull request in the official BIPs Repository in early December. This move facilitated two additional rounds of review, leading to its designation as BIP 3 at the beginning of January. The developer behind these updates has completed their contributions and is now seeking feedback from the wider Bitcoin development community. This initiative aims not only to gather reviews from those who have been following the proposal closely but also to invite new contributors to offer suggestions, voice concerns, or express support for the proposal. Interested parties can find more details and participate in the discussion through the provided [GitHub link](https://github.com/bitcoin/bips/pull/1712). This effort reflects an ongoing commitment to maintaining a robust, transparent, and inclusive framework for proposing and implementing improvements to Bitcoin, with the engagement and feedback from the community being vital for shaping its future direction. - 2025-03-28T17:21:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_P2QRH-BIP-360-Update.xml b/static/bitcoin-dev/Feb_2025/combined_P2QRH-BIP-360-Update.xml index 6886e9dcfd..c3f7fa5d07 100644 --- a/static/bitcoin-dev/Feb_2025/combined_P2QRH-BIP-360-Update.xml +++ b/static/bitcoin-dev/Feb_2025/combined_P2QRH-BIP-360-Update.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - P2QRH / BIP-360 Update - 2025-03-15T02:27:13.172496+00:00 - - Hunter Beast 2025-03-12 21:05:00+00:00 - - - Jose Storopoli 2025-03-12 11:14:00+00:00 - - - Hunter Beast 2025-03-03 21:00:00+00:00 - - - Hunter Beast 2025-03-03 20:57:00+00:00 - - - Dustin Ray 2025-02-28 04:19:00+00:00 - - - Matt Corallo 2025-02-26 19:02:00+00:00 - - - Jonas Nick 2025-02-26 08:08:00+00:00 - - - Tim Bratton 2025-02-26 00:03:00+00:00 - - - Hunter Beast 2025-02-25 18:03:00+00:00 - - - Hunter Beast 2025-02-25 16:54:00+00:00 - - - Ian Quantum 2025-02-24 16:12:00+00:00 - - - Jonas Nick 2025-02-24 13:17:00+00:00 - - - Hunter Beast 2025-02-23 20:58:00+00:00 - - - Hunter Beast 2025-02-23 20:33:00+00:00 - - - Jonas Nick 2025-02-21 08:54:00+00:00 - - - Matt Corallo 2025-02-20 22:11:00+00:00 - - - Hunter Beast 2025-02-19 22:57:00+00:00 - - - Dustin Ray 2025-02-19 17:23:00+00:00 - - - Hunter Beast 2025-02-19 15:40:00+00:00 - + 2025-09-26T14:33:26.866230+00:00 + python-feedgen + + + P2QRH / BIP-360 Update Hunter Beast + 2025-02-19T15:40:00.000Z + + + Dustin Ray + 2025-02-19T17:23:00.000Z + + + Hunter Beast + 2025-02-19T22:57:00.000Z + + + Matt Corallo + 2025-02-20T22:11:00.000Z + + + Jonas Nick + 2025-02-21T08:54:00.000Z + + + Hunter Beast + 2025-02-23T20:33:00.000Z + + + Hunter Beast + 2025-02-23T20:58:00.000Z + + + Jonas Nick + 2025-02-24T13:17:00.000Z + + + Ian Quantum + 2025-02-24T16:12:00.000Z + + + Hunter Beast + 2025-02-25T16:54:00.000Z + + + Hunter Beast + 2025-02-25T18:03:00.000Z + + + Tim Bratton + 2025-02-26T00:03:00.000Z + + + Jonas Nick + 2025-02-26T08:08:00.000Z + + + Matt Corallo + 2025-02-26T19:02:00.000Z + + + Dustin Ray + 2025-02-28T04:19:00.000Z + + + Hunter Beast + 2025-03-03T20:57:00.000Z + + + Hunter Beast + 2025-03-03T21:00:00.000Z + + + Jose Storopoli + 2025-03-12T11:14:00.000Z + + + Hunter Beast + 2025-03-12T21:05:00.000Z + + @@ -79,21 +101,17 @@ - python-feedgen + 2 Combined summary - P2QRH / BIP-360 Update - 2025-03-15T02:27:13.172638+00:00 + 2025-09-26T14:33:26.868452+00:00 + 2025-03-12T21:05:00+00:00 The ongoing discussions and developments within the Bitcoin development community focus on enhancing the blockchain's security in the face of potential quantum computing threats. A significant portion of this discourse revolves around the implementation and integration of post-quantum cryptography (PQC) strategies to safeguard Bitcoin against emerging computational capabilities that could compromise existing cryptographic defenses. Among the notable concerns is the practicality of incorporating quantum-resistant algorithms without excessively burdening the blockchain's efficiency and user experience. The critique extends to specific Bitcoin Improvement Proposals (BIPs) that aim to introduce new cryptographic measures, with particular attention given to their potential vulnerabilities and the implications for multisig transactions and attestation mechanisms. - A key aspect of the debate centers on finding a balance between adopting robust PQC methods and maintaining the operational integrity of the Bitcoin network. There is an acknowledgment of the challenges posed by transitioning to quantum-resistant architectures, such as increased computational costs, larger key sizes, and the complexity of integrating these new systems into the existing framework. Discussions emphasize the importance of pragmatic and forward-thinking approaches that can offer interim protection against quantum threats while paving the way for more comprehensive solutions as the field of quantum computing and PQC evolves. - In addition to technical considerations, there is a strong emphasis on community engagement and feedback in shaping the direction of Bitcoin's quantum resistance efforts. Proposed changes and updates to BIPs are subject to meticulous scrutiny, with contributions from various stakeholders aimed at refining these proposals to ensure they provide effective security enhancements without compromising the core functionalities of the Bitcoin protocol. This collaborative effort underscores the dynamic nature of cryptocurrency development, where adaptability and collective expertise play critical roles in navigating the complexities of digital security in an ever-evolving technological landscape. - Moreover, the discourse reflects a nuanced understanding of the trade-offs involved in implementing PQC measures. While the urgency of preparing for quantum computing advancements is recognized, there is also a cautious approach to avoid premature commitments to specific cryptographic schemes that may not fully address the unique challenges faced by cryptocurrencies like Bitcoin. The exploration of various algorithms, including hash-based signatures and lattice-based cryptography, indicates a comprehensive search for solutions that align with Bitcoin's security needs and operational constraints. - Overall, the conversations among Bitcoin developers highlight a concerted effort to anticipate and counteract quantum computing threats through strategic planning and community-driven decision-making. By prioritizing both immediate and long-term security objectives, the development community aims to fortify Bitcoin against emerging challenges while ensuring that the blockchain remains accessible, efficient, and secure for users worldwide. - 2025-03-12T21:05:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_Proposal-for-Quantum-Resistant-Address-Migration-Protocol-QRAMP-BIP.xml b/static/bitcoin-dev/Feb_2025/combined_Proposal-for-Quantum-Resistant-Address-Migration-Protocol-QRAMP-BIP.xml index 28f5cf9021..b155a03547 100644 --- a/static/bitcoin-dev/Feb_2025/combined_Proposal-for-Quantum-Resistant-Address-Migration-Protocol-QRAMP-BIP.xml +++ b/static/bitcoin-dev/Feb_2025/combined_Proposal-for-Quantum-Resistant-Address-Migration-Protocol-QRAMP-BIP.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP - 2025-03-10T02:07:51.349334+00:00 - - ArmchairCryptologist 2025-03-09 09:19:00+00:00 - - - Agustin Cruz 2025-03-09 00:53:00+00:00 - - - Agustin Cruz 2025-03-07 18:42:00+00:00 - - - Michal Kolesár 2025-03-05 13:40:00+00:00 - - - Dustin Ray 2025-02-19 22:05:00+00:00 - - - Agustin Cruz 2025-02-19 21:49:00+00:00 - - - Dustin Ray 2025-02-19 21:35:00+00:00 - - - Agustin Cruz 2025-02-19 21:07:00+00:00 - - - Dustin Ray 2025-02-19 20:10:00+00:00 - - - Pieter Wuille 2025-02-19 17:56:00+00:00 - - - Agustin Cruz 2025-02-19 16:42:00+00:00 - - - Hunter Beast 2025-02-19 16:06:00+00:00 - - - Agustin Cruz 2025-02-12 00:54:00+00:00 - - - Dustin Ray 2025-02-12 00:47:00+00:00 - - - Agustin Cruz 2025-02-12 00:37:00+00:00 - - - Dustin Ray 2025-02-12 00:15:00+00:00 - - - Agustin Cruz 2025-02-11 22:36:00+00:00 - + 2025-09-26T14:33:18.326582+00:00 + python-feedgen + + + Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP Agustin Cruz + 2025-02-11T22:36:00.000Z + + + Dustin Ray + 2025-02-12T00:15:00.000Z + + + Agustin Cruz + 2025-02-12T00:37:00.000Z + + + Dustin Ray + 2025-02-12T00:47:00.000Z + + + Agustin Cruz + 2025-02-12T00:54:00.000Z + + + Hunter Beast + 2025-02-19T16:06:00.000Z + + + Agustin Cruz + 2025-02-19T16:42:00.000Z + + + Pieter Wuille + 2025-02-19T17:56:00.000Z + + + Dustin Ray + 2025-02-19T20:10:00.000Z + + + Agustin Cruz + 2025-02-19T21:07:00.000Z + + + Dustin Ray + 2025-02-19T21:35:00.000Z + + + Agustin Cruz + 2025-02-19T21:49:00.000Z + + + Dustin Ray + 2025-02-19T22:05:00.000Z + + + Michal Kolesár + 2025-03-05T13:40:00.000Z + + + Agustin Cruz + 2025-03-07T18:42:00.000Z + + + Agustin Cruz + 2025-03-09T00:53:00.000Z + + + ArmchairCryptologist' + 2025-03-09T09:19:00.000Z + + @@ -71,21 +91,17 @@ - python-feedgen + 2 Combined summary - Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP - 2025-03-10T02:07:51.349452+00:00 + 2025-09-26T14:33:18.328644+00:00 + 2025-03-09T09:19:00+00:00 The quantum computing era presents a formidable challenge to the current cryptographic underpinnings of Bitcoin, necessitating a proactive approach to ensure the long-term security and stability of the network. A mandatory migration to quantum-resistant addresses, as discussed in various segments of the community, emerges as a pivotal strategy to preempt potential threats. This transition, while crucial, is fraught with complexities, including the risk of high transaction fees due to limited block size and the potential for network flooding by parties benefiting from increased fees. Such dynamics underscore the importance of a carefully planned, possibly extended migration period to mitigate risks without imposing undue burdens on users. - The Quantum-Resistant Address Migration Protocol (QRAMP), coupled with the technical specifications outlined in BIP-360, represents a concerted effort to address these challenges. QRAMP proposes a structured migration framework, emphasizing the necessity of moving away from legacy ECDSA-based addresses before quantum capabilities render them vulnerable. This initiative underscores a broader commitment to preserving Bitcoin's foundational security without resorting to drastic measures that could erode trust or accessibility within the network. - Discussions highlight the nuanced debate surrounding the best path forward, balancing between enforced migrations with clear deadlines and more voluntary, incentivized approaches. The proposed hard deadline for transitioning funds to quantum-resistant addresses aims to circumvent the gradual erosion of security posed by quantum advancements. However, this approach raises concerns about the potential loss of funds, particularly those in dormant wallets or belonging to less active users. Alternatives, such as turnstile mechanisms for voluntary migration, offer a less coercive path, emphasizing user choice and gradual adaptation. - The technical and philosophical deliberations extend to considerations of how best to manage the transition without undermining Bitcoin’s core principles, such as autonomy, security, and fixed supply. The prospect of reactivating dormant coins through quantum exploitation introduces complex economic and ethical questions, particularly regarding the distribution and value of Bitcoin. These discussions encapsulate the broader tensions within the development community between innovation and preservation, highlighting the delicate balance required to navigate future threats. - Moreover, the discourse reflects an acute awareness of the timing and nature of quantum advancements, arguing for a preparedness strategy that evolves alongside technological progress. This includes developing and integrating quantum-resistant cryptographic mechanisms, ensuring the continuity of Bitcoin's operations, and safeguarding against both current and future vulnerabilities. The collaborative spirit evident in the proposals and discussions signifies a collective endeavor to fortify Bitcoin against the specter of quantum computing, ensuring its resilience in an uncertain digital age. - 2025-03-09T09:19:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml b/static/bitcoin-dev/Feb_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml index 1773738942..f07ff21df3 100644 --- a/static/bitcoin-dev/Feb_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml +++ b/static/bitcoin-dev/Feb_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks - 2025-04-10T02:34:59.225767+00:00 - - Yuval Kogman 2025-04-09 02:16:00+00:00 - - - Javier Mateos 2025-04-07 10:01:00+00:00 - - - Yuval Kogman 2025-04-04 19:59:00+00:00 - - - Yuval Kogman 2025-04-04 17:58:00+00:00 - - - Peter Todd 2025-04-04 16:42:00+00:00 - - - Yuval Kogman 2025-02-13 15:42:00+00:00 - - - /dev /fd 2025-02-12 10:17:00+00:00 - - - Yuval Kogman 2025-02-07 20:07:00+00:00 - - - Peter Todd 2025-02-04 22:22:00+00:00 - - - Yuval Kogman 2025-02-04 14:02:00+00:00 - - - waxwing/ AdamISZ 2025-01-24 16:38:00+00:00 - - - Peter Todd 2025-01-24 16:00:00+00:00 - - - Peter Todd 2025-01-23 16:25:00+00:00 - - - Yuval Kogman 2025-01-07 21:33:00+00:00 - - - waxwing/ AdamISZ 2025-01-07 15:56:00+00:00 - - - Yuval Kogman 2025-01-06 14:30:00+00:00 - - - Sjors Provoost 2025-01-06 13:07:00+00:00 - - - Yuval Kogman 2024-12-21 14:16:00+00:00 - + 2025-09-26T14:33:16.175996+00:00 + python-feedgen + + + Yuval Kogman + 2024-12-21T14:16:00.000Z + + + Sjors Provoost + 2025-01-06T13:07:00.000Z + + + Yuval Kogman + 2025-01-06T14:30:00.000Z + + + waxwing/ AdamISZ + 2025-01-07T15:56:00.000Z + + + Yuval Kogman + 2025-01-07T21:33:00.000Z + + + Peter Todd + 2025-01-23T16:25:00.000Z + + + Peter Todd + 2025-01-24T16:00:00.000Z + + + waxwing/ AdamISZ + 2025-01-24T16:38:00.000Z + + + Yuval Kogman + 2025-02-04T14:02:00.000Z + + + Peter Todd + 2025-02-04T22:22:00.000Z + + + Yuval Kogman + 2025-02-07T20:07:00.000Z + + + /dev /fd0 + 2025-02-12T10:17:00.000Z + + + Yuval Kogman + 2025-02-13T15:42:00.000Z + + + Peter Todd + 2025-04-04T16:42:00.000Z + + + Yuval Kogman + 2025-04-04T17:58:00.000Z + + + Yuval Kogman + 2025-04-04T19:59:00.000Z + + + Javier Mateos + 2025-04-07T10:01:00.000Z + + + Yuval Kogman + 2025-04-09T02:16:00.000Z + + @@ -75,23 +96,18 @@ - python-feedgen + 2 Combined summary - Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks - 2025-04-10T02:34:59.225885+00:00 + 2025-09-26T14:33:16.178160+00:00 + 2025-04-09T02:16:00+00:00 The discourse within the Bitcoin development community highlights several critical insights and concerns surrounding privacy, trust, and transparency in the operation of coinjoin implementations such as Wasabi Wallet and Samourai Wallet. At the core of these discussions is the acknowledgment of inherent vulnerabilities and the complexity of ensuring user anonymity against sophisticated deanonymization techniques. The dialogue surfaces a pivotal tension between the theoretical promise of privacy-enhancing technologies and their practical implementation challenges. - A central theme in the conversation revolves around the limitations and potential weaknesses of coinjoin protocols. Specifically, criticisms target the coordinators' ability to undermine the privacy guarantees through manipulating transaction processes, a risk exacerbated by a lack of transparency and possible rent-seeking behaviors. These concerns are not merely theoretical but are grounded in detailed technical analyses that reveal how malicious actors could exploit protocol design flaws for deanonymization purposes. - For instance, the critique of Whirlpool's vulnerability centers on the process of blind signing keys, which could enable a coordinator to clandestinely link outputs to inputs, thereby breaching the protocol's privacy assurances. Similarly, WabiSabi faces scrutiny over its handling of key consistency, with the protocol's reliance on clients registering Bitcoin UTXOs independently underpinning a methodological flaw. This flaw could allow inconsistent round IDs to be issued to clients, facilitating partitioning attacks that compromise user anonymity. Despite efforts to address these and other issues, such as poor coin selection practices and the misuse of Tor circuits, the fundamental challenge of verifying and controlling the public keys used for proof verification persists. - Moreover, the discussions delve into the economic models embedded within these systems, particularly focusing on coordination fees and anonymous credential mechanisms. While intended to fairly compensate for transaction coordination, these structures have inadvertently fallen short of preventing the misappropriation of user funds, highlighting a significant gap in balancing privacy enhancement with financial security. - The critiques extend beyond specific protocols to encompass broader themes of ethical responsibility, transparency in development practices, and the imperative for rigorous auditing. The need for a comprehensive approach to security, one that includes both cryptographic and non-cryptographic elements of privacy-sensitive code, is emphasized as essential for maintaining user trust and integrity within the Bitcoin ecosystem. - In summary, the discussions reflect a multifaceted debate on the evolution of cryptocurrency protocols, underscoring the ongoing challenge of innovating privacy-enhancing technologies while safeguarding against exploitation. This dynamic interplay between innovation, security, and ethical considerations encapsulates the current state of discourse in the Bitcoin development community, pointing towards a future where these tensions must be continually navigated to advance the field responsibly. - 2025-04-09T02:16:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_Transaction-Validation-Optimization.xml b/static/bitcoin-dev/Feb_2025/combined_Transaction-Validation-Optimization.xml index 8fc8b11605..ddc1a8802c 100644 --- a/static/bitcoin-dev/Feb_2025/combined_Transaction-Validation-Optimization.xml +++ b/static/bitcoin-dev/Feb_2025/combined_Transaction-Validation-Optimization.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Transaction Validation Optimization - 2025-02-20T02:25:15.938734+00:00 - - Pieter Wuille 2025-02-19 18:20:00+00:00 - - - Eric Voskuil 2025-02-19 05:47:00+00:00 - - - John 2025-02-18 15:22:00+00:00 - + 2025-09-26T14:33:20.442625+00:00 + python-feedgen + + + Transaction Validation Optimization John + 2025-02-18T15:22:00.000Z + + + Eric Voskuil + 2025-02-19T05:47:00.000Z + + + Pieter Wuille + 2025-02-19T18:20:00.000Z + + - python-feedgen + 2 Combined summary - Transaction Validation Optimization - 2025-02-20T02:25:15.938794+00:00 + 2025-09-26T14:33:20.443200+00:00 + 2025-02-19T18:20:00+00:00 Bitcoin Core's approach to transaction validation emphasizes efficiency and security, employing a signature validation cache and a script validation cache as outlined by Eric Voskuil. These caches facilitate the process by which transactions that have already been verified in the mempool do not require full re-validation when they are subsequently included in a block. The script validation cache is particularly nuanced, containing validation flags that account for the status of consensus rules, which ensures its inapplicability post-softfork activations due to the change in rules. - Pieter Wuille raises an intriguing point regarding the potential redundancy within this system. His analysis suggests that transactions once validated in the mempool and later found in new blocks undergo what appears to be duplicate validation steps. This observation prompts him to question whether optimizing this process, especially for SegWit-verified transactions through the use of wtxid hashes, could eliminate unnecessary re-validations while maintaining network integrity. Wuille is seeking insights into the necessity of this apparent redundancy, pondering if the current mechanism indeed requires transactions to be fully re-validated upon block processing and what potential risks could arise from streamlining this process. His inquiry extends to the implications such optimizations might hold for transaction propagation timing and node synchronization, indicating a cautious approach towards modifying established protocols without overlooking possible complications. - This discussion encapsulates a deeper exploration into Bitcoin's core functionalities, highlighting areas where efficiency improvements may be possible without compromising the network's security or reliability. It reflects a thoughtful consideration of the balance between optimization and caution, inviting further examination of historical design choices and potential implications of proposed changes. - 2025-02-19T18:20:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_Transaction-expiration-should-be-based-on-the-most-recent-transaction-in-a-group-not-the-first.xml b/static/bitcoin-dev/Feb_2025/combined_Transaction-expiration-should-be-based-on-the-most-recent-transaction-in-a-group-not-the-first.xml index 69f2d17a51..a8ca31527a 100644 --- a/static/bitcoin-dev/Feb_2025/combined_Transaction-expiration-should-be-based-on-the-most-recent-transaction-in-a-group-not-the-first.xml +++ b/static/bitcoin-dev/Feb_2025/combined_Transaction-expiration-should-be-based-on-the-most-recent-transaction-in-a-group-not-the-first.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Transaction expiration should be based on the most recent transaction in a group, not the first - 2025-02-05T02:28:36.222707+00:00 - - Peter Todd 2025-02-04 21:39:00+00:00 - - - ArmchairCryptologist 2025-01-31 12:02:00+00:00 - - - Peter Todd 2025-01-28 22:25:00+00:00 - + 2025-09-26T14:33:24.715138+00:00 + python-feedgen + + + Transaction expiration should be based on the most recent transaction in a group, not the first Peter Todd + 2025-01-28T22:25:00.000Z + + + ArmchairCryptologist' + 2025-01-31T12:02:00.000Z + + + Peter Todd + 2025-02-04T21:39:00.000Z + + - python-feedgen + 2 Combined summary - Transaction expiration should be based on the most recent transaction in a group, not the first - 2025-02-05T02:28:36.222751+00:00 + 2025-09-26T14:33:24.715708+00:00 + 2025-02-04T21:39:00+00:00 The debate centers on the question of whether expiration-based mempool eviction is still relevant or beneficial within the Bitcoin network, highlighting a series of technical and philosophical concerns. Observations indicate that despite transactions lingering unconfirmed for extended periods, they are eventually processed without being exploited, prompting a reevaluation of the need for a mechanism that adds to computational and bandwidth overhead by repeatedly evicting and then re-accepting these transactions. The discussion points out the flawed reliance on unconfirmed transaction disappearance, exacerbated by the full implementation of Replace-By-Fee (RBF) policies, which contradicts any expectation of unconfirmed transactions vanishing permanently. The argument suggests that the practice might be redundant or counterproductive due to the mempool's limited capacity and proposes enhancing the `abandontransaction` function to allow targeted eviction from a node's local mempool. - Further critique is directed at Bitcoin Core's current approach to transaction expiration within the mempool, which involves removing transactions after a specified duration without considering their descendant transactions. This method is criticized for its inefficiency, particularly in scenarios involving Child Pays For Parent (CPFP), where users are willing to pay extra to prioritize an old transaction. Additionally, this approach poses potential vulnerabilities, such as facilitating free-relay Denial of Service (DoS) attacks and enabling transaction cycling attacks, which exploit the transaction expiration mechanism for network abuse. Despite these issues, the rationale behind transaction expiration focuses on mitigating risks associated with accepting non-mineable transactions due to soft-fork complications or other anomalies. However, the effectiveness of this rationale is questioned, considering that even months-old transactions are eventually mined, challenging the necessity of expiring them from the mempool. - The discussion extends to the broader implications of mempool management strategies on network efficiency, security vulnerabilities, and transaction longevity, emphasizing a need for a nuanced approach to managing mempool dynamics in light of evolving network behaviors and capabilities. Contributors like Peter Todd offer valuable insights into the complexities of blockchain technology and network management, providing a deeper understanding of the ongoing debates within the Bitcoin development community ([Peter Todd](https://petertodd.org)). - 2025-02-04T21:39:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2025/combined_Update-on-the-Great-Consensus-Cleanup-Revival.xml b/static/bitcoin-dev/Feb_2025/combined_Update-on-the-Great-Consensus-Cleanup-Revival.xml index 0ce660df7f..716bb28bf5 100644 --- a/static/bitcoin-dev/Feb_2025/combined_Update-on-the-Great-Consensus-Cleanup-Revival.xml +++ b/static/bitcoin-dev/Feb_2025/combined_Update-on-the-Great-Consensus-Cleanup-Revival.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Update on the Great Consensus Cleanup Revival - 2025-03-09T02:07:41.925909+00:00 - - Greg Sanders 2025-03-07 21:45:00+00:00 - - - Antoine Poinsot 2025-02-27 17:23:00+00:00 - - - Matt Corallo 2025-02-26 19:11:00+00:00 - - - Peter Todd 2025-02-26 11:02:00+00:00 - - - Antoine Poinsot 2025-02-23 22:35:00+00:00 - - - Matt Corallo 2025-02-21 01:22:00+00:00 - - - Antoine Riard 2025-02-15 21:13:00+00:00 - - - Peter Todd 2025-02-14 17:40:00+00:00 - - - Antoine Riard 2025-02-11 21:20:00+00:00 - - - Chris Stewart 2025-02-10 21:21:00+00:00 - - - Antoine Poinsot 2025-02-10 16:28:00+00:00 - - - Antoine Riard 2025-02-07 13:02:00+00:00 - - - Antoine Poinsot 2025-02-06 22:03:00+00:00 - - - Murch 2025-02-06 21:34:00+00:00 - - - Antoine Poinsot 2025-02-05 18:09:00+00:00 - + 2025-09-26T14:33:29.019339+00:00 + python-feedgen + + + Update on the Great Consensus Cleanup Revival 'Antoine Poinsot' + 2025-02-05T18:09:00.000Z + + + Murch + 2025-02-06T21:34:00.000Z + + + Antoine Poinsot' + 2025-02-06T22:03:00.000Z + + + Antoine Riard + 2025-02-07T13:02:00.000Z + + + Antoine Poinsot' + 2025-02-10T16:28:00.000Z + + + Chris Stewart + 2025-02-10T21:21:00.000Z + + + Antoine Riard + 2025-02-11T21:20:00.000Z + + + Peter Todd + 2025-02-14T17:40:00.000Z + + + Antoine Riard + 2025-02-15T21:13:00.000Z + + + Matt Corallo + 2025-02-21T01:22:00.000Z + + + Antoine Poinsot' + 2025-02-23T22:35:00.000Z + + + Peter Todd + 2025-02-26T11:02:00.000Z + + + Matt Corallo + 2025-02-26T19:11:00.000Z + + + Antoine Poinsot' + 2025-02-27T17:23:00.000Z + + + Greg Sanders + 2025-03-07T21:45:00.000Z + + @@ -63,29 +81,21 @@ - python-feedgen + 2 Combined summary - Update on the Great Consensus Cleanup Revival - 2025-03-09T02:07:41.926034+00:00 + 2025-09-26T14:33:29.020997+00:00 + 2025-03-07T21:45:00+00:00 The discussions on the Bitcoin Development Mailing List and various GitHub issues have delved into multiple facets of Bitcoin's development, focusing on optimizing transaction validation processes, assessing hardware performance for mining, contemplating codebase refinements, analyzing security measures against potential attacks, and proposing significant updates to the Bitcoin protocol through Improvement Proposals (BIPs). - One area of discussion emphasized the relationship between the number of preparation blocks used in transaction validations and the resulting computational costs. Through comparative analysis, it was determined that employing a mitigation strategy could equate the validation cost of using Taproot technology to that of legacy systems under certain conditions. This insight is pivotal for developers aiming to enhance Bitcoin transaction validations efficiently. - Another point of interest revolved around the affordability and performance of mining hardware, notably inexpensive devices like Raspberry Pi. The conversation shed light on how parallelization across multiple cores could potentially exceed expected outcomes in mining operations, highlighting an eagerness to understand the performance of such hardware under varying operational scenarios. - Further deliberations touched upon the importance of meticulously reviewing unused code segments within the Bitcoin codebase. The specific mention of three lines of code and a single line defining SCRIPT_VERIFY_SIGPUSHONLY underscored the complexity in deciding whether removing ostensibly unused code is beneficial, given its indirect relevance to testing other code functionalities. - Security concerns also took center stage, with discussions exploring worst-case scenarios in blockchain validation times. A nuanced perspective was offered on managing these scenarios, not just from end-users' viewpoint but also considering miners' roles in maintaining network integrity. Real-world tests, including one conducted on a Dell XPS 15 9520 laptop, revealed that current worst-case validation times could be significantly reduced through proposed mitigations, underscoring the balance between theoretical challenges and practical solutions. - Enhancements in block validation times were celebrated, marking a substantial step forward in Bitcoin’s efficiency. A notable 40x decrease in the worst-case scenario for validation times was achieved, sparking inquiries into the quantification of this improvement and the potential for further reductions. - In-depth technical explorations were conducted around the VerifyScript functionality and the SCRIPT_VERIFY_SIGPUSHONLY flag, revealing a nuanced understanding of Bitcoin's codebase where elements may persist for purposes outside immediate network operations, such as testing and verification. - Antoine Poinsot's contributions highlighted a preference for addressing vulnerabilities in the Bitcoin protocol through bundled fixes in soft forks, emphasizing a comprehensive approach to securing the network. His advocacy for deploying multiple soft forks simultaneously under a future BIP-9-based deployment scenario illustrated the technical and consensus considerations involved in evolving Bitcoin's protocol. - Finally, efforts to fortify Bitcoin against known threats culminated in a revised consensus cleanup proposal, encapsulating critical updates to enhance the security and functionality of Bitcoin. This initiative underscores the ongoing commitment within the development community to refine and secure the Bitcoin protocol, reflecting a collaborative effort towards ensuring its robustness and longevity. - 2025-03-07T21:45:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_-Bitcoin-Advent-Calendar-Decentralized-Coordination-Free-Mining-Pools.xml b/static/bitcoin-dev/Jan_2022/combined_-Bitcoin-Advent-Calendar-Decentralized-Coordination-Free-Mining-Pools.xml index 8e6734ec80..4375d58bd2 100644 --- a/static/bitcoin-dev/Jan_2022/combined_-Bitcoin-Advent-Calendar-Decentralized-Coordination-Free-Mining-Pools.xml +++ b/static/bitcoin-dev/Jan_2022/combined_-Bitcoin-Advent-Calendar-Decentralized-Coordination-Free-Mining-Pools.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools - 2023-08-02T05:14:21.409949+00:00 - - Billy Tetrud 2022-01-18 18:15:15+00:00 - - - Jeremy 2021-12-23 19:05:22+00:00 - - - vjudeu at gazeta.pl 2021-12-23 11:56:18+00:00 - - - Billy Tetrud 2021-12-20 17:18:44+00:00 - - - vjudeu at gazeta.pl 2021-12-17 06:37:17+00:00 - - - Jeremy 2021-12-17 00:37:09+00:00 - - - Billy Tetrud 2021-12-16 16:57:03+00:00 - - - vjudeu at gazeta.pl 2021-12-16 09:35:04+00:00 - - - Jeremy 2021-12-15 21:53:50+00:00 - - - yanmaani at cock.li 2021-12-15 21:10:51+00:00 - - - Bob McElrath 2021-12-15 18:51:41+00:00 - - - Jeremy 2021-12-15 18:39:28+00:00 - - - Billy Tetrud 2021-12-15 17:25:15+00:00 - - - Bob McElrath 2021-12-15 00:12:00+00:00 - - - Bob McElrath 2021-12-14 23:33:05+00:00 - - - Jeremy 2021-12-14 19:50:33+00:00 - - - Jeremy 2021-12-14 19:39:06+00:00 - - - vjudeu at gazeta.pl 2021-12-13 14:10:49+00:00 - - - Jeremy 2021-12-13 01:31:42+00:00 - - - vjudeu at gazeta.pl 2021-12-12 23:14:45+00:00 - - - Jeremy 2021-12-12 16:43:12+00:00 - + 2025-09-26T14:40:30.847274+00:00 + python-feedgen + + + [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools Jeremy + 2021-12-12T16:43:00.000Z + + + vjudeu + 2021-12-12T23:14:00.000Z + + + Jeremy + 2021-12-13T01:31:00.000Z + + + vjudeu + 2021-12-13T14:10:00.000Z + + + Jeremy + 2021-12-14T19:39:00.000Z + + + Jeremy + 2021-12-14T19:50:00.000Z + + + Bob McElrath + 2021-12-14T23:33:00.000Z + + + Bob McElrath + 2021-12-15T00:12:00.000Z + + + Billy Tetrud + 2021-12-15T17:25:00.000Z + + + Jeremy + 2021-12-15T18:39:00.000Z + + + Bob McElrath + 2021-12-15T18:51:00.000Z + + + yanmaani + 2021-12-15T21:10:00.000Z + + + Jeremy + 2021-12-15T21:53:00.000Z + + + vjudeu + 2021-12-16T09:35:00.000Z + + + Billy Tetrud + 2021-12-16T16:57:00.000Z + + + Jeremy + 2021-12-17T00:37:00.000Z + + + vjudeu + 2021-12-17T06:37:00.000Z + + + Billy Tetrud + 2021-12-20T17:18:00.000Z + + + vjudeu + 2021-12-23T11:56:00.000Z + + + Jeremy + 2021-12-23T19:05:00.000Z + + + Billy Tetrud + 2022-01-18T18:15:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools - 2023-08-02T05:14:21.409949+00:00 + 2025-09-26T14:40:30.849726+00:00 - The discussion revolves around proposals for improving Bitcoin mining pools. One proposal suggests creating a separate blockchain called "superblocks" that would progress linearly and keep block headers instead of transactions. The idea is to collect uncollected blocks into the next superblock and reward the block creator based on the number of blocks included. Various approaches to defining windows and reward functions are discussed, including paying less for blocks found in rapid succession. Concerns have been raised about the feasibility and security of this design, as well as the issue of unspendable block rewards.Other suggestions include using weak blocks and an ephemeral blockchain or utilizing multisig and leaf nodes to enable smaller miners to participate without centralized control. These proposals aim to increase payout regularity and reduce on-chain footprint through combined payouts or non-custodial mining pools. However, questions remain about the distribution of block rewards and data availability.The role of Proof of Stake and the value of signing in mining are also discussed. Some participants suggest focusing on specific problems where CheckTemplateVerify (CTV) is the best solution, rather than trying to cover all aspects. Safety concerns are raised about throwing block rewards into a channel for immediate spending, and there is a need to reduce on-chain wait time for spending block rewards.The Braidpool project is mentioned, which proposes a separate blockchain with superblocks storing only block headers. There are public forums and mailing lists available for people to join, and the creators welcome additional contributors. However, concerns have been expressed about the design, suggesting a focus on one specific problem that CTV can effectively solve.The debate also includes discussions on the definition of a pool, reducing profit variance, resource management, and the goals of payout functions for solo miners and mining pools. There are suggestions for simplifying verification of coinbase rewards, assigning difficulty levels to shares, and using longer windows of difficulty periods to hedge against changes in hashrate.Overall, the discussion showcases ongoing debates among Bitcoin developers regarding the efficiency and security of mining pools. While there are differing opinions and concerns about the proposed solutions, there is a recognition of the potential benefits in exploring different designs and techniques to address issues related to payout regularity, on-chain footprint, and unspendable block rewards. 2022-01-18T18:15:15+00:00 + The discussion revolves around proposals for improving Bitcoin mining pools. One proposal suggests creating a separate blockchain called "superblocks" that would progress linearly and keep block headers instead of transactions. The idea is to collect uncollected blocks into the next superblock and reward the block creator based on the number of blocks included. Various approaches to defining windows and reward functions are discussed, including paying less for blocks found in rapid succession. Concerns have been raised about the feasibility and security of this design, as well as the issue of unspendable block rewards.Other suggestions include using weak blocks and an ephemeral blockchain or utilizing multisig and leaf nodes to enable smaller miners to participate without centralized control. These proposals aim to increase payout regularity and reduce on-chain footprint through combined payouts or non-custodial mining pools. However, questions remain about the distribution of block rewards and data availability.The role of Proof of Stake and the value of signing in mining are also discussed. Some participants suggest focusing on specific problems where CheckTemplateVerify (CTV) is the best solution, rather than trying to cover all aspects. Safety concerns are raised about throwing block rewards into a channel for immediate spending, and there is a need to reduce on-chain wait time for spending block rewards.The Braidpool project is mentioned, which proposes a separate blockchain with superblocks storing only block headers. There are public forums and mailing lists available for people to join, and the creators welcome additional contributors. However, concerns have been expressed about the design, suggesting a focus on one specific problem that CTV can effectively solve.The debate also includes discussions on the definition of a pool, reducing profit variance, resource management, and the goals of payout functions for solo miners and mining pools. There are suggestions for simplifying verification of coinbase rewards, assigning difficulty levels to shares, and using longer windows of difficulty periods to hedge against changes in hashrate.Overall, the discussion showcases ongoing debates among Bitcoin developers regarding the efficiency and security of mining pools. While there are differing opinions and concerns about the proposed solutions, there is a recognition of the potential benefits in exploring different designs and techniques to address issues related to payout regularity, on-chain footprint, and unspendable block rewards. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_-Pre-BIP-Fee-Accounts.xml b/static/bitcoin-dev/Jan_2022/combined_-Pre-BIP-Fee-Accounts.xml index 32397a76b2..d5a3b7ef41 100644 --- a/static/bitcoin-dev/Jan_2022/combined_-Pre-BIP-Fee-Accounts.xml +++ b/static/bitcoin-dev/Jan_2022/combined_-Pre-BIP-Fee-Accounts.xml @@ -1,98 +1,187 @@ - + 2 Combined summary - [Pre-BIP] Fee Accounts - 2023-08-02T05:17:55.394761+00:00 - - Jeremy Rubin 2022-05-02 15:59:49+00:00 - - - Peter Todd 2022-04-28 12:15:02+00:00 - - - Jeremy Rubin 2022-04-17 20:57:28+00:00 - - - Peter Todd 2022-04-15 14:52:47+00:00 - - - Jeremy Rubin 2022-04-11 13:18:10+00:00 - - - Peter Todd 2022-04-10 19:32:52+00:00 - - - Jeremy Rubin 2022-02-20 16:45:35+00:00 - - - ZmnSCPxj 2022-02-20 16:34:35+00:00 - - - Jeremy Rubin 2022-02-20 16:29:35+00:00 - - - Jeremy Rubin 2022-02-20 16:29:00+00:00 - - - ZmnSCPxj 2022-02-20 14:24:22+00:00 - - - ZmnSCPxj 2022-02-20 02:39:50+00:00 - - - ZmnSCPxj 2022-02-20 02:24:37+00:00 - - - Peter Todd 2022-02-19 20:35:20+00:00 - - - darosior 2022-02-19 17:20:19+00:00 - - - Peter Todd 2022-02-19 09:39:22+00:00 - - - Jeremy Rubin 2022-02-19 00:38:27+00:00 - - - Peter Todd 2022-02-18 23:50:07+00:00 - - - Jeremy Rubin 2022-02-10 08:08:59+00:00 - - - Peter Todd 2022-02-10 06:58:56+00:00 - - - Billy Tetrud 2022-01-20 05:23:12+00:00 - - - Jeremy 2022-01-19 20:08:23+00:00 - - - Billy Tetrud 2022-01-19 16:51:48+00:00 - - - Jeremy 2022-01-19 07:32:36+00:00 - - - Billy Tetrud 2022-01-19 04:53:21+00:00 - - - Jeremy 2022-01-19 02:51:42+00:00 - - - Billy Tetrud 2022-01-19 02:37:39+00:00 - - - Jeremy 2022-01-18 17:43:07+00:00 - - - Billy Tetrud 2022-01-18 16:12:36+00:00 - - - Jeremy 2022-01-01 20:04:00+00:00 - + 2025-09-26T14:40:37.377246+00:00 + python-feedgen + + + [bitcoin-dev] [Pre-BIP] Fee Accounts Jeremy + 2022-01-01T20:04:00.000Z + + + Billy Tetrud + 2022-01-18T16:12:00.000Z + + + Jeremy + 2022-01-18T17:43:00.000Z + + + Billy Tetrud + 2022-01-19T02:37:00.000Z + + + Jeremy + 2022-01-19T02:51:00.000Z + + + Billy Tetrud + 2022-01-19T04:53:00.000Z + + + Jeremy + 2022-01-19T07:32:00.000Z + + + Billy Tetrud + 2022-01-19T16:51:00.000Z + + + Jeremy + 2022-01-19T20:08:00.000Z + + + Billy Tetrud + 2022-01-20T05:23:00.000Z + + + Peter Todd + 2022-02-10T06:58:00.000Z + + + Jeremy Rubin + 2022-02-10T08:08:00.000Z + + + Peter Todd + 2022-02-18T23:50:00.000Z + + + Jeremy Rubin + 2022-02-19T00:38:00.000Z + + + Peter Todd + 2022-02-19T09:39:00.000Z + + + [bitcoin-dev] [Lightning-dev] " darosior + 2022-02-19T17:20:00.000Z + + + Peter Todd + 2022-02-19T20:35:00.000Z + + + ZmnSCPxj + 2022-02-20T02:24:00.000Z + + + ZmnSCPxj + 2022-02-20T02:39:00.000Z + + + ZmnSCPxj + 2022-02-20T14:24:00.000Z + + + Jeremy Rubin + 2022-02-20T16:29:00.000Z + + + [bitcoin-dev] " Jeremy Rubin + 2022-02-20T16:29:00.000Z + + + ZmnSCPxj + 2022-02-20T16:34:00.000Z + + + Jeremy Rubin + 2022-02-20T16:45:00.000Z + + + Peter Todd + 2022-04-10T19:32:00.000Z + + + Jeremy Rubin + 2022-04-11T13:18:00.000Z + + + Peter Todd + 2022-04-15T14:52:00.000Z + + + Jeremy Rubin + 2022-04-17T20:57:00.000Z + + + Peter Todd + 2022-04-28T12:15:00.000Z + + + Jeremy Rubin + 2022-05-02T15:59:00.000Z + + + [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions Peter Todd + 2022-06-14T11:12:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T11:39:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T11:53:00.000Z + + + rot13maxi + 2022-06-14T12:28:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T12:45:00.000Z + + + Bryan Bishop + 2022-06-14T13:55:00.000Z + + + digital vagabond + 2022-06-14T15:06:00.000Z + + + Peter Todd + 2022-06-14T15:22:00.000Z + + + Peter Todd + 2022-06-14T15:34:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T17:15:00.000Z + + + Andrew Poelstra + 2022-06-14T20:33:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-15T01:16:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-15T01:21:00.000Z + + + Peter Todd + 2022-06-19T11:04:00.000Z + + @@ -123,13 +212,13 @@ - python-feedgen + 2 Combined summary - [Pre-BIP] Fee Accounts - 2023-08-02T05:17:55.395761+00:00 + 2025-09-26T14:40:37.381602+00:00 - In a detailed email conversation, the participants discuss various aspects of blockchain technology, specifically focusing on Open Time Stamps (OTS). The discussion begins with a proposal for a correct timestamping service model, stating that any such service must adhere to the model to be reliable. The writer highlights the potential issues and unreliability that can arise if the model is not followed.Jeremy Rubin questions the appeal to authority in the Bitcoin-dev group and raises concerns about the formal correctness of OTS. He suggests the need for an actual specification for OTS to resolve these issues. The conversation then delves into the technical details of OTS, including its proof format and how it relates to transactions and Bitcoin blocks. The participants also discuss the concept of linearization and its relevance in a use-case scenario. They debate the advantages and disadvantages of different transaction models and fee accounts implementation, emphasizing the importance of flexibility and avoiding unnecessary costs.Additionally, the conversation touches upon the topic of necromancy attacks, where an earlier version of a transaction is resurrected by a third party for OTS. The potential benefits and drawbacks of such attacks are discussed, along with suggestions for mitigating their impact. The discussion expands to include the design of fee accounts and the need for explicit tagging or opt-in features. Different viewpoints are presented, highlighting the potential limitations and advantages of each approach.Another topic addressed is the use of Child Pays for Parent (CPFP) to solve issues related to relative locktimes in Bitcoin Vaults. The participants discuss the recommended design for Vaults and the need for additional features like RBF-able addable input/output or sponsors.The conversation concludes with discussions on the definition of pinning attacks, progress in committing data, and the potential risks associated with certain approaches in blockchain schemes. Overall, the email conversation covers a wide range of topics related to blockchain technology, providing insights into the challenges and considerations involved in implementing and improving timestamping services.Bitcoin developer Jeremy Rubin has proposed a new design to improve the fee-paying semantics in Bitcoin. The current system of paying fees in-band presents challenges for smart contracts and features such as fee bumping and DoS-resistant payment channels. Rubin's proposal suggests two approaches: using a special transaction called a "sponsor" to allow arbitrary fee appending, or implementing an account system as an extension block.The account system proposal involves defining a "fee account" output type that would have separate UTXO databases for deposits and withdrawals. Fee accounts would only be able to sign two types of transactions: one specifying a fee amount and a TXID, and another specifying a withdrawal amount, a fee, and an address. These transactions would be committed in an extension block merkle tree.Rubin argues that the proposed account system would make it easier to write smart contracts by separating the logic from the fees. The mempool logic would be updated to allow attaching fee account spends to transactions, with restrictions on accounts not being allowed to spend more than their balance. The design is considered scalable because adding fees to a transaction does not require adding inputs or outputs or tracking substantial amounts of new state.The proposal could also be modified to enhance privacy by implementing techniques like Tornado.cash or a trustless mixing protocol. Rubin suggests that a federated network could be used to bribe miners until a consensus upgrade is deployed, but acknowledges that this approach may introduce centralization.Overall, Rubin's proposal aims to address the limitations of the current fee-paying system in Bitcoin and provide more flexibility and scalability while considering privacy concerns. 2022-05-02T15:59:49+00:00 + In a detailed email conversation, the participants discuss various aspects of blockchain technology, specifically focusing on Open Time Stamps (OTS). The discussion begins with a proposal for a correct timestamping service model, stating that any such service must adhere to the model to be reliable. The writer highlights the potential issues and unreliability that can arise if the model is not followed.Jeremy Rubin questions the appeal to authority in the Bitcoin-dev group and raises concerns about the formal correctness of OTS. He suggests the need for an actual specification for OTS to resolve these issues. The conversation then delves into the technical details of OTS, including its proof format and how it relates to transactions and Bitcoin blocks. The participants also discuss the concept of linearization and its relevance in a use-case scenario. They debate the advantages and disadvantages of different transaction models and fee accounts implementation, emphasizing the importance of flexibility and avoiding unnecessary costs.Additionally, the conversation touches upon the topic of necromancy attacks, where an earlier version of a transaction is resurrected by a third party for OTS. The potential benefits and drawbacks of such attacks are discussed, along with suggestions for mitigating their impact. The discussion expands to include the design of fee accounts and the need for explicit tagging or opt-in features. Different viewpoints are presented, highlighting the potential limitations and advantages of each approach.Another topic addressed is the use of Child Pays for Parent (CPFP) to solve issues related to relative locktimes in Bitcoin Vaults. The participants discuss the recommended design for Vaults and the need for additional features like RBF-able addable input/output or sponsors.The conversation concludes with discussions on the definition of pinning attacks, progress in committing data, and the potential risks associated with certain approaches in blockchain schemes. Overall, the email conversation covers a wide range of topics related to blockchain technology, providing insights into the challenges and considerations involved in implementing and improving timestamping services.Bitcoin developer Jeremy Rubin has proposed a new design to improve the fee-paying semantics in Bitcoin. The current system of paying fees in-band presents challenges for smart contracts and features such as fee bumping and DoS-resistant payment channels. Rubin's proposal suggests two approaches: using a special transaction called a "sponsor" to allow arbitrary fee appending, or implementing an account system as an extension block.The account system proposal involves defining a "fee account" output type that would have separate UTXO databases for deposits and withdrawals. Fee accounts would only be able to sign two types of transactions: one specifying a fee amount and a TXID, and another specifying a withdrawal amount, a fee, and an address. These transactions would be committed in an extension block merkle tree.Rubin argues that the proposed account system would make it easier to write smart contracts by separating the logic from the fees. The mempool logic would be updated to allow attaching fee account spends to transactions, with restrictions on accounts not being allowed to spend more than their balance. The design is considered scalable because adding fees to a transaction does not require adding inputs or outputs or tracking substantial amounts of new state.The proposal could also be modified to enhance privacy by implementing techniques like Tornado.cash or a trustless mixing protocol. Rubin suggests that a federated network could be used to bribe miners until a consensus upgrade is deployed, but acknowledges that this approach may introduce centralization.Overall, Rubin's proposal aims to address the limitations of the current fee-paying system in Bitcoin and provide more flexibility and scalability while considering privacy concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml b/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml index 2b21225011..658199a95c 100644 --- a/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml +++ b/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [dlc-dev] CTV dramatically improves DLCs - 2023-08-02T05:26:20.231936+00:00 + 2025-09-26T14:40:00.997082+00:00 + python-feedgen Jeremy 2022-01-28 16:53:40+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [dlc-dev] CTV dramatically improves DLCs - 2023-08-02T05:26:20.231936+00:00 + 2025-09-26T14:40:00.997278+00:00 - In an email thread on the Bitcoin-dev mailing list, Thibaut Le Guilly responds to Lloyd Fournier regarding the use of CTV in the Discreet Log Contract (DLC) protocol. Thibaut agrees that CTV could simplify the protocol but raises the possibility of using the CHECKSIGFROMSTACK opcode instead. He suggests that this opcode would allow for requiring an oracle signature over the outcome without any special tricks or the need for the oracle to release a nonce in advance. However, he admits that he hasn't thoroughly studied covenant opcodes yet.Jeremy, another participant in the discussion, replies to Thibaut's message. He acknowledges that CSFS might have independent benefits in general but points out that in this specific case, CTV is only being used in the user-generated mapping of Oracle result to Transaction Outcome. Jeremy adds that if Thibaut comes up with something CSFS-based for the Oracles, it would be complimentary to the current usage of CTV.Jonas Nick chimes in by thanking Thibaut for proposing the interesting application of OP_CTV. However, Jonas mentions that this particular use case doesn't necessarily require OP_CTV and can also be achieved through other covenant constructions such as ANYPREVOUT-based covenants. These alternative constructions offer similar benefits. Specifically, the script of the Taproot leaves can be set to CHECKSIGVERIFY CHECKSIGVERIFY, where the creation of signatures has minimal computational cost. The downside of this approach is the additional overhead of 64 witness bytes compared to CTV.Overall, the email thread discusses the potential use of OP_CTV and alternative covenant constructions for DLCs. It explores the advantages and considerations of each approach, highlighting the potential benefits and trade-offs associated with different opcode choices. 2022-01-28T16:53:40+00:00 + In an email thread on the Bitcoin-dev mailing list, Thibaut Le Guilly responds to Lloyd Fournier regarding the use of CTV in the Discreet Log Contract (DLC) protocol. Thibaut agrees that CTV could simplify the protocol but raises the possibility of using the CHECKSIGFROMSTACK opcode instead. He suggests that this opcode would allow for requiring an oracle signature over the outcome without any special tricks or the need for the oracle to release a nonce in advance. However, he admits that he hasn't thoroughly studied covenant opcodes yet.Jeremy, another participant in the discussion, replies to Thibaut's message. He acknowledges that CSFS might have independent benefits in general but points out that in this specific case, CTV is only being used in the user-generated mapping of Oracle result to Transaction Outcome. Jeremy adds that if Thibaut comes up with something CSFS-based for the Oracles, it would be complimentary to the current usage of CTV.Jonas Nick chimes in by thanking Thibaut for proposing the interesting application of OP_CTV. However, Jonas mentions that this particular use case doesn't necessarily require OP_CTV and can also be achieved through other covenant constructions such as ANYPREVOUT-based covenants. These alternative constructions offer similar benefits. Specifically, the script of the Taproot leaves can be set to CHECKSIGVERIFY CHECKSIGVERIFY, where the creation of signatures has minimal computational cost. The downside of this approach is the additional overhead of 64 witness bytes compared to CTV.Overall, the email thread discusses the potential use of OP_CTV and alternative covenant constructions for DLCs. It explores the advantages and considerations of each approach, highlighting the potential benefits and trade-offs associated with different opcode choices. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_BIP-proposal-Pay-to-contract-tweak-fields-for-PSBT-bip-psbt-p2c-.xml b/static/bitcoin-dev/Jan_2022/combined_BIP-proposal-Pay-to-contract-tweak-fields-for-PSBT-bip-psbt-p2c-.xml index 41c62b1b3a..1169c0ef0b 100644 --- a/static/bitcoin-dev/Jan_2022/combined_BIP-proposal-Pay-to-contract-tweak-fields-for-PSBT-bip-psbt-p2c-.xml +++ b/static/bitcoin-dev/Jan_2022/combined_BIP-proposal-Pay-to-contract-tweak-fields-for-PSBT-bip-psbt-p2c-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c) - 2023-08-02T05:23:35.482429+00:00 - - Dr Maxim Orlovsky 2022-04-01 08:32:36+00:00 - - - Jeremy 2022-01-17 05:55:00+00:00 - - - Dr Maxim Orlovsky 2022-01-16 17:41:22+00:00 - + 2025-09-26T14:40:35.195330+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c) Dr Maxim Orlovsky + 2022-01-16T17:41:00.000Z + + + Jeremy + 2022-01-17T05:55:00.000Z + + + Dr Maxim Orlovsky + 2022-04-01T08:32:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c) - 2023-08-02T05:23:35.482429+00:00 + 2025-09-26T14:40:35.195935+00:00 - Dr. Maxim Orlovsky has proposed a new standard called BIP (Bitcoin Improvement Proposal) that aims to add pay-to-contract key tweaking data fields to PSBTs (Partially Signed Bitcoin Transactions). This proposal is an extension of the existing PSBT standard suggested by Andrew Poelstra in March 2019. The BIP proposal introduces a commitment called P2C, which creates a cryptographic commitment to some message using elliptic curve properties.The main objective of this proposal is to provide a universal method for spending previous outputs containing P2C tweaks. These tweaks are used to create a cryptographic commitment to a specific message. In order to spend an output containing a P2C commitment, the same commitment must be added to the corresponding private key. The proposal includes a new per-input type, PSBT_IN_P2C_TWEAK, which contains the compact public key serialization and a value that is added to the private key to produce valid signatures.This new field provides sufficient information for creating valid signatures for spending outputs containing tweaked public keys such as bare scripts, P2PK, P2PKH, P2SH, witness v0 P2WPKH and P2WSH, nested witness v0 P2WPKH-P2SH and P2WSH-P2SH, and witness v1 P2TR outputs. The proposal is compatible with existing consensus rules and does not require any modifications.It is important to note that this proposal only focuses on spending transaction outputs containing P2C tweaks and does not address the construction of new P2C commitments or transactions containing them in their outputs. The scope of the proposal is limited to the question of spending an output that previously contained a P2C commitment, without creating a new commitment or risking extra-blockchain value loss.External signers who may not have any information about the P2C commitment can use this proposal to produce valid signatures. However, it is worth mentioning that possible future witness versions, including witness v1 non-taproot outputs, may not be supported by this BIP and may require the addition of new fields to the PSBT inputs.In summary, Dr. Maxim Orlovsky's proposal aims to extend the PSBT standard by adding new fields for pay-to-contract key tweaking data. The proposal provides a universal method for spending previous outputs containing P2C tweaks and is compatible with existing consensus rules. It introduces a new per-input type, PSBT_IN_P2C_TWEAK, which contains the necessary information for creating valid signatures. However, it does not address the construction of new P2C commitments or transactions containing them in their outputs. 2022-04-01T08:32:36+00:00 + Dr. Maxim Orlovsky has proposed a new standard called BIP (Bitcoin Improvement Proposal) that aims to add pay-to-contract key tweaking data fields to PSBTs (Partially Signed Bitcoin Transactions). This proposal is an extension of the existing PSBT standard suggested by Andrew Poelstra in March 2019. The BIP proposal introduces a commitment called P2C, which creates a cryptographic commitment to some message using elliptic curve properties.The main objective of this proposal is to provide a universal method for spending previous outputs containing P2C tweaks. These tweaks are used to create a cryptographic commitment to a specific message. In order to spend an output containing a P2C commitment, the same commitment must be added to the corresponding private key. The proposal includes a new per-input type, PSBT_IN_P2C_TWEAK, which contains the compact public key serialization and a value that is added to the private key to produce valid signatures.This new field provides sufficient information for creating valid signatures for spending outputs containing tweaked public keys such as bare scripts, P2PK, P2PKH, P2SH, witness v0 P2WPKH and P2WSH, nested witness v0 P2WPKH-P2SH and P2WSH-P2SH, and witness v1 P2TR outputs. The proposal is compatible with existing consensus rules and does not require any modifications.It is important to note that this proposal only focuses on spending transaction outputs containing P2C tweaks and does not address the construction of new P2C commitments or transactions containing them in their outputs. The scope of the proposal is limited to the question of spending an output that previously contained a P2C commitment, without creating a new commitment or risking extra-blockchain value loss.External signers who may not have any information about the P2C commitment can use this proposal to produce valid signatures. However, it is worth mentioning that possible future witness versions, including witness v1 non-taproot outputs, may not be supported by this BIP and may require the addition of new fields to the PSBT inputs.In summary, Dr. Maxim Orlovsky's proposal aims to extend the PSBT standard by adding new fields for pay-to-contract key tweaking data. The proposal provides a universal method for spending previous outputs containing P2C tweaks and is compatible with existing consensus rules. It introduces a new per-input type, PSBT_IN_P2C_TWEAK, which contains the necessary information for creating valid signatures. However, it does not address the construction of new P2C commitments or transactions containing them in their outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_Bitcoin-Legal-Defense-Fund.xml b/static/bitcoin-dev/Jan_2022/combined_Bitcoin-Legal-Defense-Fund.xml index 71034b32d4..58c7925406 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Bitcoin-Legal-Defense-Fund.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Bitcoin-Legal-Defense-Fund.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Bitcoin Legal Defense Fund - 2023-08-02T05:22:46.087113+00:00 - - Zac Greenwood 2022-01-21 14:36:10+00:00 - - - Jeremy 2022-01-14 18:34:45+00:00 - - - qmccormick13 2022-01-14 18:18:40+00:00 - - - Aymeric Vitte 2022-01-14 13:21:42+00:00 - - - Antoine Riard 2022-01-13 20:50:08+00:00 - - - Steve Lee 2022-01-13 19:28:32+00:00 - - - Alex Morcos 2022-01-13 19:25:48+00:00 - - - Jeremy 2022-01-13 19:05:42+00:00 - - - Alex Schoof 2022-01-13 18:54:35+00:00 - - - Steve Lee 2022-01-13 18:28:18+00:00 - - - jack 2022-01-13 18:20:40+00:00 - - - Prayank 2022-01-13 10:13:11+00:00 - - - SatoshiSingh 2022-01-12 09:59:07+00:00 - - - Christopher Allen 2022-01-12 01:42:57+00:00 - - - René Pickhardt 2022-01-12 00:47:41+00:00 - - - jack 2022-01-12 00:13:45+00:00 - + 2025-09-26T14:40:28.697148+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Legal Defense Fund jack + 2022-01-12T00:13:00.000Z + + + René Pickhardt + 2022-01-12T00:47:00.000Z + + + Christopher Allen + 2022-01-12T01:42:00.000Z + + + SatoshiSingh + 2022-01-12T09:59:00.000Z + + + Prayank + 2022-01-13T10:13:00.000Z + + + jack + 2022-01-13T18:20:00.000Z + + + Steve Lee + 2022-01-13T18:28:00.000Z + + + Alex Schoof + 2022-01-13T18:54:00.000Z + + + Jeremy + 2022-01-13T19:05:00.000Z + + + Alex Morcos + 2022-01-13T19:25:00.000Z + + + Steve Lee + 2022-01-13T19:28:00.000Z + + + Antoine Riard + 2022-01-13T20:50:00.000Z + + + Aymeric Vitte + 2022-01-14T13:21:00.000Z + + + qmccormick13 + 2022-01-14T18:18:00.000Z + + + Jeremy + 2022-01-14T18:34:00.000Z + + + Zac Greenwood + 2022-01-21T14:36:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Legal Defense Fund - 2023-08-02T05:22:46.087113+00:00 + 2025-09-26T14:40:28.699030+00:00 - In the Bitcoin-dev mailing list, a member named Prayank suggested changing the name of the Bitcoin Legal Defense Fund (BLDF) to avoid confusion for newcomers. Jack agreed with this suggestion and said he would come up with a better name for the fund. The discussion also touched on the scope and focus of the BLDF, with some members suggesting more neutral names that cover other cryptocurrencies besides Bitcoin. There was a concern about the fund financing lawsuits irrelevant to Bitcoin.The email thread also addressed the issue of people involved in important funds commenting or influencing soft fork-related discussions. It was suggested that the board operating principles should include criteria for how cases are chosen to prevent the fund from influencing direction. The importance of transparency and responsible governance was emphasized.The discussion revolved around the creation of a fund to finance defense lawsuits related to Bitcoin. Some participants suggested a more neutral name for the fund, while others raised concerns about people involved in the fund commenting or influencing discussions. The goal was to ensure that the fund operates transparently and responsibly.The bitcoin-dev mailing list discussed suggestions for the name of a fund that would provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. There were concerns about the name of the fund being confusing for newbies and the potential influence of people involved in the fund on soft fork-related discussions. The discussion aimed to ensure the fund operates in a transparent and responsible manner.The conversation on the bitcoin-dev mailing list focused on the Bitcoin Legal Defense Fund (BLDF), which aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. Suggestions were made to change the name of the fund to avoid confusion for new users. There was also discussion about the involvement of people in the fund in soft fork-related discussions and the need for transparency and responsible governance.The Bitcoin Legal Defense Fund (BLDF) was discussed on the bitcoin-dev mailing list. The fund aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. Suggestions were made to clarify the name of the fund and ensure its transparency and responsible governance. There was also discussion about the involvement of people in important funds in soft fork-related discussions.The bitcoin-dev mailing list discussed the creation of the Bitcoin Legal Defense Fund (BLDF). The fund aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. Suggestions were made to change the name of the fund to avoid confusion and ensure transparency and responsible governance. The discussion also touched on the involvement of people in the fund in soft fork-related discussions.The bitcoin-dev mailing list discussed the creation of the Bitcoin Legal Defense Fund (BLDF), which aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. The discussion revolved around suggestions for the name of the fund, concerns about its potential influence on soft fork-related discussions, and the importance of transparency and responsible governance.The bitcoin-dev mailing list discussed the Bitcoin Legal Defense Fund (BLDF), which provides legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. The discussion focused on suggestions for the name of the fund, concerns about its potential influence on soft fork-related discussions, and the need for transparency and responsible governance.The bitcoin-dev mailing list discussed the creation of the Bitcoin Legal Defense Fund (BLDF), which aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. The discussion covered suggestions for the name of the fund, concerns about its potential influence on soft fork-related discussions, and the importance of transparency and responsible governance.The bitcoin-dev mailing list discussed the Bitcoin Legal Defense Fund (BLDF), which aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. The members suggested a more neutral name for the fund, expressed concerns about its potential influence on soft fork-related discussions, and emphasized the need for transparency and responsible governance. 2022-01-21T14:36:10+00:00 + In the Bitcoin-dev mailing list, a member named Prayank suggested changing the name of the Bitcoin Legal Defense Fund (BLDF) to avoid confusion for newcomers. Jack agreed with this suggestion and said he would come up with a better name for the fund. The discussion also touched on the scope and focus of the BLDF, with some members suggesting more neutral names that cover other cryptocurrencies besides Bitcoin. There was a concern about the fund financing lawsuits irrelevant to Bitcoin.The email thread also addressed the issue of people involved in important funds commenting or influencing soft fork-related discussions. It was suggested that the board operating principles should include criteria for how cases are chosen to prevent the fund from influencing direction. The importance of transparency and responsible governance was emphasized.The discussion revolved around the creation of a fund to finance defense lawsuits related to Bitcoin. Some participants suggested a more neutral name for the fund, while others raised concerns about people involved in the fund commenting or influencing discussions. The goal was to ensure that the fund operates transparently and responsibly.The bitcoin-dev mailing list discussed suggestions for the name of a fund that would provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. There were concerns about the name of the fund being confusing for newbies and the potential influence of people involved in the fund on soft fork-related discussions. The discussion aimed to ensure the fund operates in a transparent and responsible manner.The conversation on the bitcoin-dev mailing list focused on the Bitcoin Legal Defense Fund (BLDF), which aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. Suggestions were made to change the name of the fund to avoid confusion for new users. There was also discussion about the involvement of people in the fund in soft fork-related discussions and the need for transparency and responsible governance.The Bitcoin Legal Defense Fund (BLDF) was discussed on the bitcoin-dev mailing list. The fund aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. Suggestions were made to clarify the name of the fund and ensure its transparency and responsible governance. There was also discussion about the involvement of people in important funds in soft fork-related discussions.The bitcoin-dev mailing list discussed the creation of the Bitcoin Legal Defense Fund (BLDF). The fund aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. Suggestions were made to change the name of the fund to avoid confusion and ensure transparency and responsible governance. The discussion also touched on the involvement of people in the fund in soft fork-related discussions.The bitcoin-dev mailing list discussed the creation of the Bitcoin Legal Defense Fund (BLDF), which aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. The discussion revolved around suggestions for the name of the fund, concerns about its potential influence on soft fork-related discussions, and the importance of transparency and responsible governance.The bitcoin-dev mailing list discussed the Bitcoin Legal Defense Fund (BLDF), which provides legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. The discussion focused on suggestions for the name of the fund, concerns about its potential influence on soft fork-related discussions, and the need for transparency and responsible governance.The bitcoin-dev mailing list discussed the creation of the Bitcoin Legal Defense Fund (BLDF), which aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. The discussion covered suggestions for the name of the fund, concerns about its potential influence on soft fork-related discussions, and the importance of transparency and responsible governance.The bitcoin-dev mailing list discussed the Bitcoin Legal Defense Fund (BLDF), which aims to provide legal support for developers facing lawsuits related to their activities in the Bitcoin ecosystem. The members suggested a more neutral name for the fund, expressed concerns about its potential influence on soft fork-related discussions, and emphasized the need for transparency and responsible governance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml b/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml index 2a4364309b..b594256efc 100644 --- a/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml +++ b/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CTV BIP review - 2023-08-02T05:24:26.222299+00:00 + 2025-09-26T14:40:13.877590+00:00 + python-feedgen Billy Tetrud 2022-01-21 17:36:13+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - CTV BIP review - 2023-08-02T05:24:26.222299+00:00 + 2025-09-26T14:40:13.877760+00:00 - In a recent discussion about the activation method for Bitcoin Improvement Proposal (BIP) 8 and BIP 9/ST, there was disagreement over how these proposals should be characterized. The main point of contention was whether activation required majority hash power support or not. BIP9/ST requires this support, while BIP8 does not. Billy Tetrud pointed out factual errors in LukeJr's statements about BIP8 and agreed with Michael that the discussion should be kept separate from the BIPs themselves. Tetrud suggested that BIPs should only mention what types of activation methods are possible, without advocating for any specific method.Billy Tetrud thanked Eric Lombrozo for correcting the factual errors regarding BIP8 and ST activation methods in an email exchange. While characterizing BIP8 and ST as BIP9-based or not is subjective, the central issue remains whether activation requires majority hash power support or not. The conversation on activation methods should be separate from advocating for specific methods in BIPs to reduce noise in conversations.The Bitcoin-dev mailing list had a discussion about the legal definition of covenant, which led to Jeremy expressing annoyance. In response, aj proposed a more useful definition of covenant within the context of Bitcoin. According to aj, a covenant is when the scriptPubKey of an unspent transaction output (utxo) restricts the scriptPubKey in the outputs of a transaction that spends that utxo. aj clarified that CTV and TLUV have this type of restriction, while CSV and CLTV do not. They also mentioned that "checksig" could potentially be considered a covenant if the signature used in checksig is in the scriptPubKey. The discussion also covered several topics related to BIPs and their implementation, including the burden placed on full BIP implementation, the use of Eltoo-like protocols, implementing OP_CAT or OP_SHA256STREAM in Bitcoin, language cleanups, and the review of CTV BIP.In an email thread regarding the review of CTV BIP, Michael Folkson requested Eric and Luke to refrain from discussing activation methods for future soft forks on a thread for CTV BIP review. He explained that the discussion for Taproot activation was kept separate until there was overwhelming community consensus. Eric and Luke disagreed with Michael's statements about backward compatibility of unenforced soft forks and chain splits. They argued that soft forks do not produce a chain split themselves but can disrupt if miners cause a split. However, Michael maintained that without majority hash power enforcement, soft forks are not backward compatible. There was also a disagreement between Eric and Luke about the definition of backward compatibility and the use of BIP8 for Taproot activation.In another discussion on the Bitcoin-dev mailing list, Jeremy Rubin expressed skepticism about using BIPs for specific use cases for CTV. Alex suggested having explicit application notes to provide details on how CTV can be used in specific applications while making it clear that they are not part of CTV itself. Luke Dashjr provided a detailed review of the CTV BIP, expressing concerns about its readiness and suggesting alternative approaches for certain use cases.Jeremy Rubin thanked Luke Dashjr for his review of CTV and mentioned plans for language cleanups. While he agreed with the need for BIPs for specific use cases, he was skeptical about the overall approach and suggested reviewing application-focused posts and creating a BIP describing how to build something similar to Sapio to help users think through compiling to CTV contracts. Luke Dashjr disagreed with Rubin's viewpoint, stating that CTV is not yet ready and that BIP 9 has known flaws. He questioned why congestion-controlled transactions had not been considered and suggested using Speedy Trial instead of BIP 9 for future deployments. He also discussed limitations of CHECKTEMPLATEVERIFY and proposed alternatives.Luke Dashjr and Eric Voskuil had a discussion about the compatibility of soft forks with the Bitcoin consensus protocol. Dashjr argued that soft forks are not backward compatible without hash power enforcement, while Voskuil disagreed, stating that enforcement is by users, not miners. There was a disagreement about BIP8 achieving consensus for Taproot activation, with Michael Folkson calling it a misleading statement and accusing Eric of deception.The email thread discussed the review of CTV, focusing on technical aspects. The author emphasized that personal or legal attacks on developers would not sway their opinion. They agreed with some nitpicks mentioned in the email and expressed a desire to see fully implemented BIPs before activation. They strongly opposed using BIP9, believing it to be flawed and representing an attempt to impose developer will over community consensus. The author suggested directing other technical comments to Jeremy or someone else as their research was ongoing. The email ended with the author's contact information.Eric at voskuil.org stated that the only significant difference between BIP9 and BIP8 is whether activation requires majority hash power support or not. Soft forks are 2022-01-21T17:36:13+00:00 + In a recent discussion about the activation method for Bitcoin Improvement Proposal (BIP) 8 and BIP 9/ST, there was disagreement over how these proposals should be characterized. The main point of contention was whether activation required majority hash power support or not. BIP9/ST requires this support, while BIP8 does not. Billy Tetrud pointed out factual errors in LukeJr's statements about BIP8 and agreed with Michael that the discussion should be kept separate from the BIPs themselves. Tetrud suggested that BIPs should only mention what types of activation methods are possible, without advocating for any specific method.Billy Tetrud thanked Eric Lombrozo for correcting the factual errors regarding BIP8 and ST activation methods in an email exchange. While characterizing BIP8 and ST as BIP9-based or not is subjective, the central issue remains whether activation requires majority hash power support or not. The conversation on activation methods should be separate from advocating for specific methods in BIPs to reduce noise in conversations.The Bitcoin-dev mailing list had a discussion about the legal definition of covenant, which led to Jeremy expressing annoyance. In response, aj proposed a more useful definition of covenant within the context of Bitcoin. According to aj, a covenant is when the scriptPubKey of an unspent transaction output (utxo) restricts the scriptPubKey in the outputs of a transaction that spends that utxo. aj clarified that CTV and TLUV have this type of restriction, while CSV and CLTV do not. They also mentioned that "checksig" could potentially be considered a covenant if the signature used in checksig is in the scriptPubKey. The discussion also covered several topics related to BIPs and their implementation, including the burden placed on full BIP implementation, the use of Eltoo-like protocols, implementing OP_CAT or OP_SHA256STREAM in Bitcoin, language cleanups, and the review of CTV BIP.In an email thread regarding the review of CTV BIP, Michael Folkson requested Eric and Luke to refrain from discussing activation methods for future soft forks on a thread for CTV BIP review. He explained that the discussion for Taproot activation was kept separate until there was overwhelming community consensus. Eric and Luke disagreed with Michael's statements about backward compatibility of unenforced soft forks and chain splits. They argued that soft forks do not produce a chain split themselves but can disrupt if miners cause a split. However, Michael maintained that without majority hash power enforcement, soft forks are not backward compatible. There was also a disagreement between Eric and Luke about the definition of backward compatibility and the use of BIP8 for Taproot activation.In another discussion on the Bitcoin-dev mailing list, Jeremy Rubin expressed skepticism about using BIPs for specific use cases for CTV. Alex suggested having explicit application notes to provide details on how CTV can be used in specific applications while making it clear that they are not part of CTV itself. Luke Dashjr provided a detailed review of the CTV BIP, expressing concerns about its readiness and suggesting alternative approaches for certain use cases.Jeremy Rubin thanked Luke Dashjr for his review of CTV and mentioned plans for language cleanups. While he agreed with the need for BIPs for specific use cases, he was skeptical about the overall approach and suggested reviewing application-focused posts and creating a BIP describing how to build something similar to Sapio to help users think through compiling to CTV contracts. Luke Dashjr disagreed with Rubin's viewpoint, stating that CTV is not yet ready and that BIP 9 has known flaws. He questioned why congestion-controlled transactions had not been considered and suggested using Speedy Trial instead of BIP 9 for future deployments. He also discussed limitations of CHECKTEMPLATEVERIFY and proposed alternatives.Luke Dashjr and Eric Voskuil had a discussion about the compatibility of soft forks with the Bitcoin consensus protocol. Dashjr argued that soft forks are not backward compatible without hash power enforcement, while Voskuil disagreed, stating that enforcement is by users, not miners. There was a disagreement about BIP8 achieving consensus for Taproot activation, with Michael Folkson calling it a misleading statement and accusing Eric of deception.The email thread discussed the review of CTV, focusing on technical aspects. The author emphasized that personal or legal attacks on developers would not sway their opinion. They agreed with some nitpicks mentioned in the email and expressed a desire to see fully implemented BIPs before activation. They strongly opposed using BIP9, believing it to be flawed and representing an attempt to impose developer will over community consensus. The author suggested directing other technical comments to Jeremy or someone else as their research was ongoing. The email ended with the author's contact information.Eric at voskuil.org stated that the only significant difference between BIP9 and BIP8 is whether activation requires majority hash power support or not. Soft forks are - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_CTV-dramatically-improves-DLCs.xml b/static/bitcoin-dev/Jan_2022/combined_CTV-dramatically-improves-DLCs.xml index fa91ca8b98..a35d34fd1b 100644 --- a/static/bitcoin-dev/Jan_2022/combined_CTV-dramatically-improves-DLCs.xml +++ b/static/bitcoin-dev/Jan_2022/combined_CTV-dramatically-improves-DLCs.xml @@ -1,32 +1,55 @@ - + 2 Combined summary - CTV dramatically improves DLCs - 2023-08-02T05:25:02.224690+00:00 - - Jeremy Rubin 2022-03-15 17:28:05+00:00 - - - Thibaut Le Guilly 2022-02-07 02:30:32+00:00 - - - Jeremy Rubin 2022-02-06 17:56:12+00:00 - - - Lloyd Fournier 2022-02-06 07:18:11+00:00 - - - Alex Schoof 2022-01-28 21:14:12+00:00 - - - Jeremy Rubin 2022-01-28 19:38:29+00:00 - - - Jeremy 2022-01-28 17:21:09+00:00 - - - Lloyd Fournier 2022-01-24 08:01:17+00:00 - + 2025-09-26T14:40:05.253403+00:00 + python-feedgen + + + [bitcoin-dev] CTV dramatically improves DLCs Lloyd Fournier + 2022-01-24T08:01:00.000Z + + + [bitcoin-dev] [dlc-dev] " Jonas Nick + 2022-01-25T16:24:00.000Z + + + Thibaut Le Guilly + 2022-01-27T00:45:00.000Z + + + Jeremy + 2022-01-28T16:53:00.000Z + + + [bitcoin-dev] " Jeremy + 2022-01-28T17:21:00.000Z + + + Jeremy Rubin + 2022-01-28T19:38:00.000Z + + + Alex Schoof + 2022-01-28T21:14:00.000Z + + + Lloyd Fournier + 2022-02-06T07:18:00.000Z + + + Jeremy Rubin + 2022-02-06T17:56:00.000Z + + + Thibaut Le Guilly + 2022-02-07T02:30:00.000Z + + + Jeremy Rubin + 2022-03-15T17:28:00.000Z + + @@ -35,13 +58,13 @@ - python-feedgen + 2 Combined summary - CTV dramatically improves DLCs - 2023-08-02T05:25:02.224690+00:00 + 2025-09-26T14:40:05.254792+00:00 - Jeremy has developed a prototype of a protocol in Sapio and shared the link to it on GitHub. He invites others to test and tweak the protocol using the provided benchmark. Jeremy tested one oracle with 100,000 different payouts and observed it taking around 13 seconds on a release build. He intends to experiment more with the protocol, but acknowledges that Sapio Studio may not be able to handle a GUI for 100,000 nodes.In a discussion thread, several points were raised regarding the use of CSFS and its effectiveness in providing privacy benefits. It was noted that while CSFS could be used in both the oracle and transaction restriction parts of the DLC, it does not provide the same model as DLC. Additionally, there was discussion about the performance benefits of the CTV approach, which allows for computation of oracle anticipation points without signing or verification. A benchmark comparison was made between the current approach with signing and verification and only computing the anticipation points, resulting in a performance improvement of roughly 24x for the serial case and 10x for the parallel case. The benchmarks are available on GitHub. One potential concern raised was the impact of having a large taproot tree on the size of witness data when spending script paths that are low in the tree and how it would affect transaction fees. Finally, there was a discussion about the Y axis being the dependent variable represented by the CTV hashes in a contract, and how this affects the cheaper part of the DLC in lightning channels that might be updated between parties frequently.The email exchange discusses the benefits and features of Discreet Log Contracts (DLCs) with CheckTemplateVerify (CTV). The author explains that CTV enables a trustless timeout branch, which can have a failover claim that returns funds to both sides. Additionally, CTV DLCs are non-interactive asynchronously third-party unilaterally creatable, which means it is possible for a single party to create a DLC on behalf of another user. This enables use cases like pay-to-DLC addresses, which can also be constructed and sent to a third party service to create DLCs without requiring the third party service to do anything other than make the payment as requested.The email also discusses how CTV DLCs can be composed in interesting ways. Options over DLCs open up many exciting types of instrument where Alice can create an option expiring in 1 week where Bob can add funds to pay a premium and "Open" a DLC on an outcome closing in 1 year. There are also opportunities for perpetual-like contracts where you could combine into one logical DLC 12 DLCs closing 1 per month that can either be paid out all at once at the end of the year or profit pulled out partially at any time earlier.Lastly, the email mentions an additional performance improvement that can be had for iterative DLCs in Lightning where you might trade over a fixed set of attestation points with variable payout curves. However, the author is not entirely clear on what is meant concretely by this. Overall, the discussion highlights the potential benefits and uses of CTV DLCs.The email thread discusses the benefits of using OP_CTV with Discreet Log Contracts (DLCs) on the Bitcoin network. OP_CTV simplifies and improves the performance of DLCs by enabling non-interactive asynchronously third-party unilaterally creatable contracts. With this, each party can compute all outcomes on their own in parallel, making multi-party DLCs easier to execute. Additionally, OP_CTV enables a "trustless timeout" branch where failover claims return funds to both sides, and DLCs can be composed in interesting ways. For example, Options over DLCs can be created, perpetual-like contracts can be combined, and iterative DLCs can be traded over a fixed set of attestation points with variable payout curves. Lastly, OP_CTV allows for pay-to-DLC addresses to be constructed and sent to third-party services, enabling the creation of DLCs without requiring the service to do anything other than make the payment as requested.Jeremy Rubin proposes a way to make the close portion of a DLC be an "optimistic" execution with a choice of justice scheme, enabling closing a DLC somewhat securely without exposing the oracles on-chain at all. Assuming honest oracles, the only cost of this mechanism over previous is that you have to do a script path spend (but it can be a top-level branch, since it's the "most likely" one). For every DLC branch add two branches allowing Alice or Bob to "lock in" a redemption of the contract that becomes spendable by them after CET-hash-* should include a nLockTime/nSequence such that it is at the same time as the attestation points should be known. Justice with punishment seems to be the better option since T is actively choosing this resolution (the CTV transition is signed), but justice with no punishment might be better if one thinks the oracles might collude to steal. 2022-03-15T17:28:05+00:00 + Jeremy has developed a prototype of a protocol in Sapio and shared the link to it on GitHub. He invites others to test and tweak the protocol using the provided benchmark. Jeremy tested one oracle with 100,000 different payouts and observed it taking around 13 seconds on a release build. He intends to experiment more with the protocol, but acknowledges that Sapio Studio may not be able to handle a GUI for 100,000 nodes.In a discussion thread, several points were raised regarding the use of CSFS and its effectiveness in providing privacy benefits. It was noted that while CSFS could be used in both the oracle and transaction restriction parts of the DLC, it does not provide the same model as DLC. Additionally, there was discussion about the performance benefits of the CTV approach, which allows for computation of oracle anticipation points without signing or verification. A benchmark comparison was made between the current approach with signing and verification and only computing the anticipation points, resulting in a performance improvement of roughly 24x for the serial case and 10x for the parallel case. The benchmarks are available on GitHub. One potential concern raised was the impact of having a large taproot tree on the size of witness data when spending script paths that are low in the tree and how it would affect transaction fees. Finally, there was a discussion about the Y axis being the dependent variable represented by the CTV hashes in a contract, and how this affects the cheaper part of the DLC in lightning channels that might be updated between parties frequently.The email exchange discusses the benefits and features of Discreet Log Contracts (DLCs) with CheckTemplateVerify (CTV). The author explains that CTV enables a trustless timeout branch, which can have a failover claim that returns funds to both sides. Additionally, CTV DLCs are non-interactive asynchronously third-party unilaterally creatable, which means it is possible for a single party to create a DLC on behalf of another user. This enables use cases like pay-to-DLC addresses, which can also be constructed and sent to a third party service to create DLCs without requiring the third party service to do anything other than make the payment as requested.The email also discusses how CTV DLCs can be composed in interesting ways. Options over DLCs open up many exciting types of instrument where Alice can create an option expiring in 1 week where Bob can add funds to pay a premium and "Open" a DLC on an outcome closing in 1 year. There are also opportunities for perpetual-like contracts where you could combine into one logical DLC 12 DLCs closing 1 per month that can either be paid out all at once at the end of the year or profit pulled out partially at any time earlier.Lastly, the email mentions an additional performance improvement that can be had for iterative DLCs in Lightning where you might trade over a fixed set of attestation points with variable payout curves. However, the author is not entirely clear on what is meant concretely by this. Overall, the discussion highlights the potential benefits and uses of CTV DLCs.The email thread discusses the benefits of using OP_CTV with Discreet Log Contracts (DLCs) on the Bitcoin network. OP_CTV simplifies and improves the performance of DLCs by enabling non-interactive asynchronously third-party unilaterally creatable contracts. With this, each party can compute all outcomes on their own in parallel, making multi-party DLCs easier to execute. Additionally, OP_CTV enables a "trustless timeout" branch where failover claims return funds to both sides, and DLCs can be composed in interesting ways. For example, Options over DLCs can be created, perpetual-like contracts can be combined, and iterative DLCs can be traded over a fixed set of attestation points with variable payout curves. Lastly, OP_CTV allows for pay-to-DLC addresses to be constructed and sent to third-party services, enabling the creation of DLCs without requiring the service to do anything other than make the payment as requested.Jeremy Rubin proposes a way to make the close portion of a DLC be an "optimistic" execution with a choice of justice scheme, enabling closing a DLC somewhat securely without exposing the oracles on-chain at all. Assuming honest oracles, the only cost of this mechanism over previous is that you have to do a script path spend (but it can be a top-level branch, since it's the "most likely" one). For every DLC branch add two branches allowing Alice or Bob to "lock in" a redemption of the contract that becomes spendable by them after CET-hash-* should include a nLockTime/nSequence such that it is at the same time as the attestation points should be known. Justice with punishment seems to be the better option since T is actively choosing this resolution (the CTV transition is signed), but justice with no punishment might be better if one thinks the oracles might collude to steal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_Covenants-and-capabilities-in-the-UTXO-model.xml b/static/bitcoin-dev/Jan_2022/combined_Covenants-and-capabilities-in-the-UTXO-model.xml index 6b9187d638..e1a0955b61 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Covenants-and-capabilities-in-the-UTXO-model.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Covenants-and-capabilities-in-the-UTXO-model.xml @@ -1,32 +1,39 @@ - + 2 Combined summary - Covenants and capabilities in the UTXO model - 2023-08-02T05:16:41.582819+00:00 - - Bram Cohen 2022-01-22 00:19:07+00:00 - - - Billy Tetrud 2022-01-21 17:32:27+00:00 - - - Peter Todd 2022-01-21 02:22:15+00:00 - - - Bram Cohen 2022-01-20 19:23:30+00:00 - - - Billy Tetrud 2022-01-19 02:24:47+00:00 - - - Bram Cohen 2022-01-18 17:16:25+00:00 - - - Billy Tetrud 2022-01-18 15:10:33+00:00 - - - Bram Cohen 2021-12-31 23:22:08+00:00 - + 2025-09-26T14:40:11.734136+00:00 + python-feedgen + + + Billy Tetrud + 2022-01-18T15:10:00.000Z + + + Bram Cohen + 2022-01-18T17:16:00.000Z + + + Billy Tetrud + 2022-01-19T02:24:00.000Z + + + Bram Cohen + 2022-01-20T19:23:00.000Z + + + Peter Todd + 2022-01-21T02:22:00.000Z + + + Billy Tetrud + 2022-01-21T17:32:00.000Z + + + Bram Cohen + 2022-01-22T00:19:00.000Z + + @@ -35,13 +42,13 @@ - python-feedgen + 2 Combined summary - Covenants and capabilities in the UTXO model - 2023-08-02T05:16:41.582819+00:00 + 2025-09-26T14:40:11.734994+00:00 - The conversation between Billy Tetrud and an unknown recipient revolves around the concept of a 'parent' in Bitcoin transactions and the optimization of the UXTO model. The recipient expresses concern about transactions becoming invalid due to limitations on how far they can point back, which could cause problems during reorgs. The discussion also touches on the use of capabilities validation tricks and optional mappings of inputs to outputs.The author questions the need to verify the secure hash chain from parent to child in Bitcoin transactions, suggesting that transactions should be defined as invalid unless they match the covenant in the parent. However, this can lead to transactions becoming invalid and create issues during reorgs. There is limited information available on why valid transactions becoming invalid is seen as a problem. Peter Todd points out that allowing references to old blocks could bring in old block data into the UTXO set and cause issues.In another discussion, Bram Cohen raises concerns about a proposal that would require nodes to keep the entire blockchain, potentially causing scalability issues. He mentions that Monero's UTXO set is already the whole blockchain, resulting in problems for pruned nodes. Allowing references to old blocks could lead to similar issues for Bitcoin. It is important to carefully consider proposals before implementation to avoid unintended consequences.Billy Tetrud and an anonymous party discuss the concept of covenants in Bitcoin and the ability to specify spending rules for UTXOs. They mention the lack of a strong single concept for a 'parent' in Bitcoin transactions and the ability for a coin to check its own ID and verify the secure hash chain from parent to child. They also discuss the potential for scalability issues if references to old blocks are allowed.Bram Cohen and Billy Tetrud discuss the implementation of covenants in Bitcoin and suggest adding programmatic capabilities to the language. They mention the complexity of Bitcoin transactions and the need for special-purpose opcodes to make coherent statements. They discuss the potential for deduplicating common script snippets to save bandwidth. They highlight the importance of ensuring recipients fully understand the covenant attached to a payment and the potential scalability issues with allowing references to old blocks.In a recent post on the bitcoin-dev mailing list, Bram Cohen discusses adding covenants and capabilities to the UTXO model. He suggests adding programmatic capabilities to the language and special-purpose opcodes for coherent statements about transactions. He emphasizes the need for recipients to fully understand payment covenants and discusses potential issues with implementing complex functionality. He proposes ways to compress or deduplicate code snippets for better scalability. Cohen's suggestions aim to add covenants and capabilities while making minimal compromises to Bitcoin's current practices.The UTXO model can be modified to include covenants and capabilities by adding programmatic capabilities to the language and using programmatic tricks. However, a clear concept of a single parent in Bitcoin transactions is missing. Implementing complex functionality can be expensive, and deduplicating code snippets is necessary for optimization. The controversy lies in whether covenants and capabilities should be opt-in or opt-out. Recipients must fully understand the implications of covenants, and retroactive veto or clawback actions are unacceptable. Concerns have been raised about potential attacks on the underlying chain if colored coins' value exceeds the tokenized chain. Backwards pointing covenants can be used for more complex functionality. The chialisp.com website offers a detailed implementation of these ideas in a slightly different model. 2022-01-22T00:19:07+00:00 + The conversation between Billy Tetrud and an unknown recipient revolves around the concept of a 'parent' in Bitcoin transactions and the optimization of the UXTO model. The recipient expresses concern about transactions becoming invalid due to limitations on how far they can point back, which could cause problems during reorgs. The discussion also touches on the use of capabilities validation tricks and optional mappings of inputs to outputs.The author questions the need to verify the secure hash chain from parent to child in Bitcoin transactions, suggesting that transactions should be defined as invalid unless they match the covenant in the parent. However, this can lead to transactions becoming invalid and create issues during reorgs. There is limited information available on why valid transactions becoming invalid is seen as a problem. Peter Todd points out that allowing references to old blocks could bring in old block data into the UTXO set and cause issues.In another discussion, Bram Cohen raises concerns about a proposal that would require nodes to keep the entire blockchain, potentially causing scalability issues. He mentions that Monero's UTXO set is already the whole blockchain, resulting in problems for pruned nodes. Allowing references to old blocks could lead to similar issues for Bitcoin. It is important to carefully consider proposals before implementation to avoid unintended consequences.Billy Tetrud and an anonymous party discuss the concept of covenants in Bitcoin and the ability to specify spending rules for UTXOs. They mention the lack of a strong single concept for a 'parent' in Bitcoin transactions and the ability for a coin to check its own ID and verify the secure hash chain from parent to child. They also discuss the potential for scalability issues if references to old blocks are allowed.Bram Cohen and Billy Tetrud discuss the implementation of covenants in Bitcoin and suggest adding programmatic capabilities to the language. They mention the complexity of Bitcoin transactions and the need for special-purpose opcodes to make coherent statements. They discuss the potential for deduplicating common script snippets to save bandwidth. They highlight the importance of ensuring recipients fully understand the covenant attached to a payment and the potential scalability issues with allowing references to old blocks.In a recent post on the bitcoin-dev mailing list, Bram Cohen discusses adding covenants and capabilities to the UTXO model. He suggests adding programmatic capabilities to the language and special-purpose opcodes for coherent statements about transactions. He emphasizes the need for recipients to fully understand payment covenants and discusses potential issues with implementing complex functionality. He proposes ways to compress or deduplicate code snippets for better scalability. Cohen's suggestions aim to add covenants and capabilities while making minimal compromises to Bitcoin's current practices.The UTXO model can be modified to include covenants and capabilities by adding programmatic capabilities to the language and using programmatic tricks. However, a clear concept of a single parent in Bitcoin transactions is missing. Implementing complex functionality can be expensive, and deduplicating code snippets is necessary for optimization. The controversy lies in whether covenants and capabilities should be opt-in or opt-out. Recipients must fully understand the implications of covenants, and retroactive veto or clawback actions are unacceptable. Concerns have been raised about potential attacks on the underlying chain if colored coins' value exceeds the tokenized chain. Backwards pointing covenants can be used for more complex functionality. The chialisp.com website offers a detailed implementation of these ideas in a slightly different model. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_Documenting-the-lifetime-of-a-transaction-during-mempool-congestion-from-the-perspective-of-a-rational-user.xml b/static/bitcoin-dev/Jan_2022/combined_Documenting-the-lifetime-of-a-transaction-during-mempool-congestion-from-the-perspective-of-a-rational-user.xml index 3649c89149..efaed9b342 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Documenting-the-lifetime-of-a-transaction-during-mempool-congestion-from-the-perspective-of-a-rational-user.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Documenting-the-lifetime-of-a-transaction-during-mempool-congestion-from-the-perspective-of-a-rational-user.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user - 2023-08-02T05:23:10.793023+00:00 - - Billy Tetrud 2022-02-26 05:35:51+00:00 - - - Jeremy 2022-01-13 21:06:37+00:00 - + 2025-09-26T14:40:22.356141+00:00 + python-feedgen + + + [bitcoin-dev] Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user Jeremy + 2022-01-13T21:06:00.000Z + + + Billy Tetrud + 2022-02-26T05:35:00.000Z + + - python-feedgen + 2 Combined summary - Documenting the lifetime of a transaction during mempool congestion from the perspective of a rational user - 2023-08-02T05:23:10.793023+00:00 + 2025-09-26T14:40:22.356673+00:00 - In this email, Jeremy Rubin discusses existing wallet behaviors and user preferences in Bitcoin, focusing on rational wallet behavior. The author argues that rational wallets should prioritize spending untrusted outputs to guarantee payment, free of cost, by using Child Pays For Parent (CPFP) mechanism to push transactions to the top of the mempool. Wallets should also track replaced payments and prevent double-spending.The author emphasizes the importance of clear messaging around transaction finalization to solve problems more easily. They also mention the significance of saving all ancestors and descendants of transactions to maximize balance and receive "free" CPFP subsidies. Wallet agents are advised to retransmit transactions if they believe other nodes are not aware of them and they are likely to go into a block.Certain wallets, like Lightning Channels, already have some of this functionality built-in. However, congestion control using Check Transaction Verify (CTV) does not complicate wallet behavior but rather helps solve existing problems by reducing the need for rational behavior like CPFP bumping. In a full mempool scenario, exchanges that batch transactions can confirm a constant-sized root transaction, and sub-trees of transactions locked in by CTV can be treated as fully trusted. This reduces the need for CPFP bumping and exerts back pressure on transaction urgency.The email primarily focuses on existing wallet behaviors and user preferences, rather than on CTV. The author defines rational wallet behavior as maximizing fully trusted balance, processing payments within the urgency budget, and maximizing privacy. It is suggested that rational wallet behavior may require additional metadata, such as trust scores or recent hashrate data.Overall, the email highlights the rational behaviors for wallets in various payment scenarios and discusses the reasons why some of these behaviors are not currently implemented. The author suggests that with the development of a more robust fee market, rational behaviors will likely become emergent among all Bitcoin wallets. Finally, the author addresses the relevance of CTV congestion control in solving existing wallet architecture problems, arguing that it can help reduce the need for rational behaviors like CPFP bumping and improve time-preference in on-chain resolution. 2022-02-26T05:35:51+00:00 + In this email, Jeremy Rubin discusses existing wallet behaviors and user preferences in Bitcoin, focusing on rational wallet behavior. The author argues that rational wallets should prioritize spending untrusted outputs to guarantee payment, free of cost, by using Child Pays For Parent (CPFP) mechanism to push transactions to the top of the mempool. Wallets should also track replaced payments and prevent double-spending.The author emphasizes the importance of clear messaging around transaction finalization to solve problems more easily. They also mention the significance of saving all ancestors and descendants of transactions to maximize balance and receive "free" CPFP subsidies. Wallet agents are advised to retransmit transactions if they believe other nodes are not aware of them and they are likely to go into a block.Certain wallets, like Lightning Channels, already have some of this functionality built-in. However, congestion control using Check Transaction Verify (CTV) does not complicate wallet behavior but rather helps solve existing problems by reducing the need for rational behavior like CPFP bumping. In a full mempool scenario, exchanges that batch transactions can confirm a constant-sized root transaction, and sub-trees of transactions locked in by CTV can be treated as fully trusted. This reduces the need for CPFP bumping and exerts back pressure on transaction urgency.The email primarily focuses on existing wallet behaviors and user preferences, rather than on CTV. The author defines rational wallet behavior as maximizing fully trusted balance, processing payments within the urgency budget, and maximizing privacy. It is suggested that rational wallet behavior may require additional metadata, such as trust scores or recent hashrate data.Overall, the email highlights the rational behaviors for wallets in various payment scenarios and discusses the reasons why some of these behaviors are not currently implemented. The author suggests that with the development of a more robust fee market, rational behaviors will likely become emergent among all Bitcoin wallets. Finally, the author addresses the relevance of CTV congestion control in solving existing wallet architecture problems, arguing that it can help reduce the need for rational behaviors like CPFP bumping and improve time-preference in on-chain resolution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_Improving-RBF-Policy.xml b/static/bitcoin-dev/Jan_2022/combined_Improving-RBF-Policy.xml index f8c7d924e4..d32da6089c 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Improving-RBF-Policy.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Improving-RBF-Policy.xml @@ -1,68 +1,111 @@ - + 2 Combined summary - Improving RBF Policy - 2023-08-02T05:30:18.072198+00:00 - - Billy Tetrud 2022-03-17 15:59:11+00:00 - - - Antoine Riard 2022-03-17 02:02:30+00:00 - - - Billy Tetrud 2022-03-15 01:43:31+00:00 - - - Gloria Zhao 2022-03-14 10:29:16+00:00 - - - Billy Tetrud 2022-03-12 08:18:39+00:00 - - - Billy Tetrud 2022-03-11 16:22:07+00:00 - - - Gloria Zhao 2022-03-09 15:09:55+00:00 - - - lisa neigut 2022-02-09 17:57:59+00:00 - - - Anthony Towns 2022-02-08 04:58:50+00:00 - - - Gloria Zhao 2022-02-07 11:16:26+00:00 - - - Bastien TEINTURIER 2022-02-07 10:22:01+00:00 - - - Michael Folkson 2022-02-05 13:21:57+00:00 - - - Anthony Towns 2022-02-02 10:21:16+00:00 - - - Bastien TEINTURIER 2022-02-01 09:30:12+00:00 - - - Prayank 2022-02-01 02:47:18+00:00 - - - Anthony Towns 2022-02-01 01:56:37+00:00 - - - Bastien TEINTURIER 2022-01-31 15:57:52+00:00 - - - Antoine Riard 2022-01-30 22:53:32+00:00 - - - Jeremy 2022-01-28 01:35:11+00:00 - - - Gloria Zhao 2022-01-27 13:42:09+00:00 - + 2025-09-26T14:40:09.586879+00:00 + python-feedgen + + + [bitcoin-dev] Improving RBF Policy Gloria Zhao + 2022-01-27T13:42:00.000Z + + + Jeremy + 2022-01-28T01:35:00.000Z + + + Antoine Riard + 2022-01-30T22:53:00.000Z + + + Bastien TEINTURIER + 2022-01-31T15:57:00.000Z + + + [bitcoin-dev] Improving RBF policy Bram Cohen + 2022-01-31T22:54:00.000Z + + + Eric Voskuil + 2022-02-01T00:08:00.000Z + + + Antoine Riard + 2022-02-01T00:42:00.000Z + + + Anthony Towns + 2022-02-01T01:56:00.000Z + + + [bitcoin-dev] Improving RBF Policy Prayank + 2022-02-01T02:47:00.000Z + + + Bram Cohen + 2022-02-01T08:32:00.000Z + + + Bastien TEINTURIER + 2022-02-01T09:30:00.000Z + + + Eric Voskuil + 2022-02-01T19:44:00.000Z + + + Anthony Towns + 2022-02-02T10:21:00.000Z + + + Michael Folkson + 2022-02-05T13:21:00.000Z + + + Bastien TEINTURIER + 2022-02-07T10:22:00.000Z + + + Gloria Zhao + 2022-02-07T11:16:00.000Z + + + Anthony Towns + 2022-02-08T04:58:00.000Z + + + lisa neigut + 2022-02-09T17:57:00.000Z + + + Gloria Zhao + 2022-03-09T15:09:00.000Z + + + Billy Tetrud + 2022-03-11T16:22:00.000Z + + + Billy Tetrud + 2022-03-12T08:18:00.000Z + + + Gloria Zhao + 2022-03-14T10:29:00.000Z + + + Billy Tetrud + 2022-03-15T01:43:00.000Z + + + Antoine Riard + 2022-03-17T02:02:00.000Z + + + Billy Tetrud + 2022-03-17T15:59:00.000Z + + @@ -83,13 +126,13 @@ - python-feedgen + 2 Combined summary - Improving RBF Policy - 2023-08-02T05:30:18.072198+00:00 + 2025-09-26T14:40:09.589512+00:00 - In recent discussions among Bitcoin developers, proposals have been made to improve the Replace-by-Fee (RBF) policies in the mempool. The goal is to address limitations and potential vulnerabilities of the current rules. One suggestion is to implement transaction relay rate limiting with a feerate-based priority queue and staggered broadcast of replacement transactions. This would prioritize transactions based on their likelihood of being included in a block.Another proposal is to allow users to specify descendant limits on their transactions, which would help solve the pinning problem associated with package RBF attacks.There has also been discussion around the concept of "mining score" as a way to prioritize transactions. The mining score would be calculated based on the ancestor feerate at which a transaction is included in a block. It is suggested that this mining score could be used as the priority value for transaction relay if a rate-limited priority queue is implemented.Some concerns have been raised about the potential downsides of these proposals, but they have generally been well-received and open for feedback. The overall objective is to prevent Denial-of-Service (DoS) attacks while maintaining the fee-rate relay rule that already mitigates spam.The conversation also touches on the idea of excluding low fee transactions from being relayed and included in blocks. While there are concerns about missing out on good fees, it is noted that this approach is a special case and other factors need to be considered, such as trusting that a lower fee transaction won't replace a higher fee transaction and the number of transactions bidding for a spot in the next block.Rate limiting is already done via INVENTORY_BROADCAST_MAX and *_INVENTORY_BROADCAST_INTERVAL, but an alternative approach suggested is to track the "effective fee rate" to better manage the ancestor fee rate. This could be achieved through candidate set blockbuilding ideas.Furthermore, there has been discussion about keeping high-feerate evicted transactions in the mempool in case they get mined by someone else, which could improve compact block relay. However, concerns have been raised about the sufficiency of the 100 transaction LRU cache and the possibility of applying rate limits only to replacement transactions.Lastly, there is a suggestion to have a split between mempool acceptance rules and spam prevention rules. This would allow transactions to be sent to miners through an alternate route if they are blocked by anti-spam rules.Overall, the discussions focus on improving the RBF policies in Bitcoin's transaction relay system to address limitations, prevent DoS attacks, and ensure a fair and efficient fee-based transaction prioritization.In another discussion, participants considered whether or not descendants matter for miner incentives. The group also discussed policies to address miner incentives and DoS issues, such as requiring certain percentage increases in ancestor absolute fees and feerates. The conversation highlights the need for improved security and more efficient use of resources in multi-party contracts built on top of Bitcoin.Bastien Teinturier proposes new rules for replacing transactions that prioritize DoS protection and incentive compatibility. He suggests separating policies that address miner incentives from policies that address DoS issues and adding a third policy to specifically address DoS concerns. He also discusses the timeline for implementing updated policies and potential vulnerabilities in multi-party contracts due to reliance on policies that cannot be enforced.Another member of the mailing list suggests relay rate limiting and prioritizing by ancestor fee rate as a way to discourage people from wasting network bandwidth. This proposal aims to address the issue of publishing transactions that will never get confirmed while still ensuring incentive compatibility. They also discuss the importance of having a path that follows the new relay rules and gets support from a significant portion of hashpower.The post delves into the discussion of improving Bitcoin's Replace-by-Fee (RBF) feature in transactions. Developer Jeremy Rubin proposes several changes to address issues and potential attacks. These changes involve removing rules that require higher fees, preventing pinning attacks, and creating a more user-friendly interface for fee bumping transactions. Rubin also discusses models for transaction validation rate-limiting and enhancing the mining score of mempool transactions.The author introduces a new rule called the "feerate-based" rule, which aims to replace transactions in the mempool. This approach entails calculating conflicting transactions and their descendants, identifying original transactions for inclusion in the next block, and ensuring replacements pay at least the same amount plus a certain percentage in absolute fees. Replacements must also have a higher feerate than the maximum mining score of remaining transactions in the mempool after the next block. The proposal suggests utilizing TBD constants to limit the number of replacements allowed with specific fees.Various implementation options for the feerate-based replacement rule are discussed, including dynamic block templates, cached block templates, or dividing the mempool into different feerate layers. Throughout the document, links to relevant pull requests, issues, and discussions are provided for further context. However, the author emphasizes that more discussion is needed to improve the RBF policy.The post also addresses topics like DoS protection, iterative 2022-03-17T15:59:11+00:00 + In recent discussions among Bitcoin developers, proposals have been made to improve the Replace-by-Fee (RBF) policies in the mempool. The goal is to address limitations and potential vulnerabilities of the current rules. One suggestion is to implement transaction relay rate limiting with a feerate-based priority queue and staggered broadcast of replacement transactions. This would prioritize transactions based on their likelihood of being included in a block.Another proposal is to allow users to specify descendant limits on their transactions, which would help solve the pinning problem associated with package RBF attacks.There has also been discussion around the concept of "mining score" as a way to prioritize transactions. The mining score would be calculated based on the ancestor feerate at which a transaction is included in a block. It is suggested that this mining score could be used as the priority value for transaction relay if a rate-limited priority queue is implemented.Some concerns have been raised about the potential downsides of these proposals, but they have generally been well-received and open for feedback. The overall objective is to prevent Denial-of-Service (DoS) attacks while maintaining the fee-rate relay rule that already mitigates spam.The conversation also touches on the idea of excluding low fee transactions from being relayed and included in blocks. While there are concerns about missing out on good fees, it is noted that this approach is a special case and other factors need to be considered, such as trusting that a lower fee transaction won't replace a higher fee transaction and the number of transactions bidding for a spot in the next block.Rate limiting is already done via INVENTORY_BROADCAST_MAX and *_INVENTORY_BROADCAST_INTERVAL, but an alternative approach suggested is to track the "effective fee rate" to better manage the ancestor fee rate. This could be achieved through candidate set blockbuilding ideas.Furthermore, there has been discussion about keeping high-feerate evicted transactions in the mempool in case they get mined by someone else, which could improve compact block relay. However, concerns have been raised about the sufficiency of the 100 transaction LRU cache and the possibility of applying rate limits only to replacement transactions.Lastly, there is a suggestion to have a split between mempool acceptance rules and spam prevention rules. This would allow transactions to be sent to miners through an alternate route if they are blocked by anti-spam rules.Overall, the discussions focus on improving the RBF policies in Bitcoin's transaction relay system to address limitations, prevent DoS attacks, and ensure a fair and efficient fee-based transaction prioritization.In another discussion, participants considered whether or not descendants matter for miner incentives. The group also discussed policies to address miner incentives and DoS issues, such as requiring certain percentage increases in ancestor absolute fees and feerates. The conversation highlights the need for improved security and more efficient use of resources in multi-party contracts built on top of Bitcoin.Bastien Teinturier proposes new rules for replacing transactions that prioritize DoS protection and incentive compatibility. He suggests separating policies that address miner incentives from policies that address DoS issues and adding a third policy to specifically address DoS concerns. He also discusses the timeline for implementing updated policies and potential vulnerabilities in multi-party contracts due to reliance on policies that cannot be enforced.Another member of the mailing list suggests relay rate limiting and prioritizing by ancestor fee rate as a way to discourage people from wasting network bandwidth. This proposal aims to address the issue of publishing transactions that will never get confirmed while still ensuring incentive compatibility. They also discuss the importance of having a path that follows the new relay rules and gets support from a significant portion of hashpower.The post delves into the discussion of improving Bitcoin's Replace-by-Fee (RBF) feature in transactions. Developer Jeremy Rubin proposes several changes to address issues and potential attacks. These changes involve removing rules that require higher fees, preventing pinning attacks, and creating a more user-friendly interface for fee bumping transactions. Rubin also discusses models for transaction validation rate-limiting and enhancing the mining score of mempool transactions.The author introduces a new rule called the "feerate-based" rule, which aims to replace transactions in the mempool. This approach entails calculating conflicting transactions and their descendants, identifying original transactions for inclusion in the next block, and ensuring replacements pay at least the same amount plus a certain percentage in absolute fees. Replacements must also have a higher feerate than the maximum mining score of remaining transactions in the mempool after the next block. The proposal suggests utilizing TBD constants to limit the number of replacements allowed with specific fees.Various implementation options for the feerate-based replacement rule are discussed, including dynamic block templates, cached block templates, or dividing the mempool into different feerate layers. Throughout the document, links to relevant pull requests, issues, and discussions are provided for further context. However, the author emphasizes that more discussion is needed to improve the RBF policy.The post also addresses topics like DoS protection, iterative - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_Nuke-notify-options-from-Bitcoin-Core.xml b/static/bitcoin-dev/Jan_2022/combined_Nuke-notify-options-from-Bitcoin-Core.xml index 255a78c6df..faddb0218c 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Nuke-notify-options-from-Bitcoin-Core.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Nuke-notify-options-from-Bitcoin-Core.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Nuke *notify options from Bitcoin Core - 2023-08-02T05:20:36.978071+00:00 - - Prayank 2022-01-01 23:29:15+00:00 - - - Daniel Edgecumbe 2022-01-01 22:57:57+00:00 - - - Prayank 2022-01-01 21:03:11+00:00 - + 2025-09-26T14:40:20.244595+00:00 + python-feedgen + + + [bitcoin-dev] Nuke *notify options from Bitcoin Core Prayank + 2022-01-01T21:03:00.000Z + + + Daniel Edgecumbe + 2022-01-01T22:57:00.000Z + + + Prayank + 2022-01-01T23:29:00.000Z + + - python-feedgen + 2 Combined summary - Nuke *notify options from Bitcoin Core - 2023-08-02T05:20:36.978071+00:00 + 2025-09-26T14:40:20.245180+00:00 - In the email conversation, Prayank responds to Daniel regarding certain points that may have been overlooked. Prayank expresses that many fancy features won't function in Windows shortcut target and it is even more suspicious if someone attempts to wrap it in notify options provided by Bitcoin Core. He emphasizes that this approach does not offer the option to run a command based on events like received transactions in the wallet. On the contrary, these notify options provide opportunities for malware to exploit. Prayank suggests that there is ample time to conduct further research on the issue and provide a fresh and helpful response for documentation purposes.The email thread revolves around a proposal to eliminate specific options from Bitcoin Core, specifically the notify options. The writer of the email argues that these options can be utilized by attackers through social engineering tactics to gain control over machines running Bitcoin Core. They further explain their attempts to bring attention to this matter with project maintainers and reviewers, but have encountered resistance. To facilitate deeper understanding, the author provides links to various pull requests (PRs) and issues related to this topic. They also mention being instructed not to review or comment on one particular PR, a directive they disagree with. The email concludes with the author sharing their public key.The author of the email advocates for the complete removal of all notify options from Bitcoin Core due to their potential to aid attackers in compromising machines running the software. To address this concern, the author proposes three potential solutions: removing notifications.dat, refraining from using system() in runCommand(), and introducing a new setting called notifypolicy in the settings.json file. This new setting would be restricted by default but could be adjusted to unrestricted when necessary. The author asserts that these issues have been thoroughly explained in multiple PRs and discussions with various individuals, including reviewers who rejected proposals due to a lack of comprehension regarding the underlying problems. The author provides specific links to two PRs where these issues were debated. Expressing frustration with the lack of interest in addressing these concerns, the author hopes that this email will help raise awareness about the issue. The author also mentions being asked to refrain from reviewing and commenting on a specific PR. Lastly, the author notes that this email will contribute to their security project and extends New Year wishes to everyone. 2022-01-01T23:29:15+00:00 + In the email conversation, Prayank responds to Daniel regarding certain points that may have been overlooked. Prayank expresses that many fancy features won't function in Windows shortcut target and it is even more suspicious if someone attempts to wrap it in notify options provided by Bitcoin Core. He emphasizes that this approach does not offer the option to run a command based on events like received transactions in the wallet. On the contrary, these notify options provide opportunities for malware to exploit. Prayank suggests that there is ample time to conduct further research on the issue and provide a fresh and helpful response for documentation purposes.The email thread revolves around a proposal to eliminate specific options from Bitcoin Core, specifically the notify options. The writer of the email argues that these options can be utilized by attackers through social engineering tactics to gain control over machines running Bitcoin Core. They further explain their attempts to bring attention to this matter with project maintainers and reviewers, but have encountered resistance. To facilitate deeper understanding, the author provides links to various pull requests (PRs) and issues related to this topic. They also mention being instructed not to review or comment on one particular PR, a directive they disagree with. The email concludes with the author sharing their public key.The author of the email advocates for the complete removal of all notify options from Bitcoin Core due to their potential to aid attackers in compromising machines running the software. To address this concern, the author proposes three potential solutions: removing notifications.dat, refraining from using system() in runCommand(), and introducing a new setting called notifypolicy in the settings.json file. This new setting would be restricted by default but could be adjusted to unrestricted when necessary. The author asserts that these issues have been thoroughly explained in multiple PRs and discussions with various individuals, including reviewers who rejected proposals due to a lack of comprehension regarding the underlying problems. The author provides specific links to two PRs where these issues were debated. Expressing frustration with the lack of interest in addressing these concerns, the author hopes that this email will help raise awareness about the issue. The author also mentions being asked to refrain from reviewing and commenting on a specific PR. Lastly, the author notes that this email will contribute to their security project and extends New Year wishes to everyone. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_OP-PUSH-KEY-BIP-118-0x01-Pun.xml b/static/bitcoin-dev/Jan_2022/combined_OP-PUSH-KEY-BIP-118-0x01-Pun.xml index dada16bf06..c1ecc05264 100644 --- a/static/bitcoin-dev/Jan_2022/combined_OP-PUSH-KEY-BIP-118-0x01-Pun.xml +++ b/static/bitcoin-dev/Jan_2022/combined_OP-PUSH-KEY-BIP-118-0x01-Pun.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - OP_PUSH_KEY_* & BIP-118 0x01 Pun - 2023-08-02T05:22:56.401137+00:00 - - Jeremy 2022-01-13 01:45:30+00:00 - - - Jeremy 2022-01-13 00:35:19+00:00 - + 2025-09-26T14:40:07.366506+00:00 + python-feedgen + + + [bitcoin-dev] OP_PUSH_KEY_* & BIP-118 0x01 Pun Jeremy + 2022-01-13T00:35:00.000Z + + + Jeremy + 2022-01-13T01:45:00.000Z + + - python-feedgen + 2 Combined summary - OP_PUSH_KEY_* & BIP-118 0x01 Pun - 2023-08-02T05:22:56.401137+00:00 + 2025-09-26T14:40:07.366968+00:00 - Bitcoin developer Jeremy Rubin has proposed the addition of two new transaction introspection opcodes in order to simplify future plans for more generalized covenant. The opcodes, named OP_PUSH_KEY_INTERNAL and OP_PUSH_KEY_EXTERNAL, would allow the retrieval of the taproot key for the current input. The internal key can already be included in the tree, but the external key creates a hash cycle and cannot be directly included. Rubin suggests that these opcodes could be beneficial for APO (Assuming Positive Outcome) and TLUV (Taproot Leaf Uses Version), as they would enable the retrieval of the current key from the stack. This would not only be useful for signing in a path for APO, but also for transactions contingent on HTLC (Hash Time Locked Contract) scriptcode satisfaction. However, there is a small incompatibility with BIP-118 (Bitcoin Improvement Proposal 118) regarding APO-enablement. Keys are not currently tagged for APO, so there should either be a version of the opcode specifically tagged for APO or APO should define a CheckSig2 opcode if tagging is desired. The proposal aims to create a more general approach by using the OP_PUSH_KEY opcodes, which could simplify APO and benefit future plans for more generalized covenant. While the use of the internal key is straightforward, the use of the external key may be less obvious. Nevertheless, it could prove helpful for recursive covenants in the future. It is important to note that both opcodes are very design specific, meaning there is only one choice of data that they can push. 2022-01-13T01:45:30+00:00 + Bitcoin developer Jeremy Rubin has proposed the addition of two new transaction introspection opcodes in order to simplify future plans for more generalized covenant. The opcodes, named OP_PUSH_KEY_INTERNAL and OP_PUSH_KEY_EXTERNAL, would allow the retrieval of the taproot key for the current input. The internal key can already be included in the tree, but the external key creates a hash cycle and cannot be directly included. Rubin suggests that these opcodes could be beneficial for APO (Assuming Positive Outcome) and TLUV (Taproot Leaf Uses Version), as they would enable the retrieval of the current key from the stack. This would not only be useful for signing in a path for APO, but also for transactions contingent on HTLC (Hash Time Locked Contract) scriptcode satisfaction. However, there is a small incompatibility with BIP-118 (Bitcoin Improvement Proposal 118) regarding APO-enablement. Keys are not currently tagged for APO, so there should either be a version of the opcode specifically tagged for APO or APO should define a CheckSig2 opcode if tagging is desired. The proposal aims to create a more general approach by using the OP_PUSH_KEY opcodes, which could simplify APO and benefit future plans for more generalized covenant. While the use of the internal key is straightforward, the use of the external key may be less obvious. Nevertheless, it could prove helpful for recursive covenants in the future. It is important to note that both opcodes are very design specific, meaning there is only one choice of data that they can push. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_On-the-regularity-of-soft-forks.xml b/static/bitcoin-dev/Jan_2022/combined_On-the-regularity-of-soft-forks.xml index 5f16bb52e7..c1fe65946c 100644 --- a/static/bitcoin-dev/Jan_2022/combined_On-the-regularity-of-soft-forks.xml +++ b/static/bitcoin-dev/Jan_2022/combined_On-the-regularity-of-soft-forks.xml @@ -1,47 +1,47 @@ - + 2 Combined summary - On the regularity of soft forks - 2023-08-02T04:54:30.049777+00:00 - - Billy Tetrud 2022-01-19 02:26:12+00:00 - - - Prayank 2022-01-18 17:22:05+00:00 - - - Billy Tetrud 2022-01-18 16:00:06+00:00 - - - vjudeu at gazeta.pl 2022-01-01 15:45:11+00:00 - - - Keagan McClelland 2021-12-31 03:10:48+00:00 - - - Michael Folkson 2021-10-16 11:02:08+00:00 - - - micaroni at gmail.com 2021-10-15 00:43:40+00:00 - - - Anthony Towns 2021-10-14 23:52:07+00:00 - - - Jorge Timón 2021-10-12 19:04:02+00:00 - - - ZmnSCPxj 2021-10-11 19:53:39+00:00 - - - Jeremy 2021-10-11 19:12:58+00:00 - - - Prayank 2021-10-11 16:03:16+00:00 - - - Michael Folkson 2021-10-11 12:24:10+00:00 - + 2025-09-26T14:40:03.140063+00:00 + python-feedgen + + + [bitcoin-dev] On the regularity of soft forks Michael Folkson + 2021-10-11T12:24:00.000Z + + + Prayank + 2021-10-11T16:03:00.000Z + + + Jeremy + 2021-10-11T19:12:00.000Z + + + ZmnSCPxj + 2021-10-11T19:53:00.000Z + + + Jorge Timón + 2021-10-12T19:04:00.000Z + + + Anthony Towns + 2021-10-14T23:52:00.000Z + + + micaroni + 2021-10-15T00:43:00.000Z + + + Michael Folkson + 2021-10-16T11:02:00.000Z + + + Keagan McClelland + 2021-12-31T03:10:00.000Z + + @@ -55,13 +55,13 @@ - python-feedgen + 2 Combined summary - On the regularity of soft forks - 2023-08-02T04:54:30.049777+00:00 + 2025-09-26T14:40:03.141182+00:00 - Miner signaling is a tool used to indicate readiness for a soft fork, but it should not be seen as a form of voting or expressing support for the fork. This distinction is crucial in order to avoid confusion and misinterpretation by users. The signaling process for taproot, for example, caused confusion among different communities as many believed that miners were actually voting for taproot. To address this issue, there needs to be sufficient community consensus before enabling miner signaling.Prayank, the author of the article, acknowledges that despite sharing a link to clarify the matter, there are still people who hold the misconception that miners vote during signaling. This confusion is further fueled by the differing opinions of developers on MASF (Miner Activated Soft Fork) versus UASF (User Activated Soft Fork). Finding a solution to this problem is a concern for Prayank.The author argues against frequent soft forks with only a single or minimal set of features, advocating instead for infrequent soft forks that include batches of features. The primary focus should be on ensuring the robustness, security, and resistance to harmful or suboptimal changes within the system. Soft fork code should not be merged into a Bitcoin implementation until there is sufficient community consensus on the entirety of that soft fork.In situations where there is no overwhelming community consensus on the activation method, activation parameters, and what to do if the initial attempt fails, the activation of soft forks carries additional risks. These risks include the potential for bugs, consensus divergences, and flawed implementations of soft fork features. Therefore, infrequent soft forks with batches of features are favored over frequent soft forks with only a single feature.Overall, the article emphasizes the need for clear communication and understanding regarding miner signaling, as well as the importance of community consensus in the implementation of soft forks. It also highlights the benefits of infrequent soft forks with multiple features in order to prioritize the security and stability of the Bitcoin system. 2022-01-19T02:26:12+00:00 + Miner signaling is a tool used to indicate readiness for a soft fork, but it should not be seen as a form of voting or expressing support for the fork. This distinction is crucial in order to avoid confusion and misinterpretation by users. The signaling process for taproot, for example, caused confusion among different communities as many believed that miners were actually voting for taproot. To address this issue, there needs to be sufficient community consensus before enabling miner signaling.Prayank, the author of the article, acknowledges that despite sharing a link to clarify the matter, there are still people who hold the misconception that miners vote during signaling. This confusion is further fueled by the differing opinions of developers on MASF (Miner Activated Soft Fork) versus UASF (User Activated Soft Fork). Finding a solution to this problem is a concern for Prayank.The author argues against frequent soft forks with only a single or minimal set of features, advocating instead for infrequent soft forks that include batches of features. The primary focus should be on ensuring the robustness, security, and resistance to harmful or suboptimal changes within the system. Soft fork code should not be merged into a Bitcoin implementation until there is sufficient community consensus on the entirety of that soft fork.In situations where there is no overwhelming community consensus on the activation method, activation parameters, and what to do if the initial attempt fails, the activation of soft forks carries additional risks. These risks include the potential for bugs, consensus divergences, and flawed implementations of soft fork features. Therefore, infrequent soft forks with batches of features are favored over frequent soft forks with only a single feature.Overall, the article emphasizes the need for clear communication and understanding regarding miner signaling, as well as the importance of community consensus in the implementation of soft forks. It also highlights the benefits of infrequent soft forks with multiple features in order to prioritize the security and stability of the Bitcoin system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_PathCoin.xml b/static/bitcoin-dev/Jan_2022/combined_PathCoin.xml index 1f0cb16370..a4adce49fc 100644 --- a/static/bitcoin-dev/Jan_2022/combined_PathCoin.xml +++ b/static/bitcoin-dev/Jan_2022/combined_PathCoin.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - PathCoin - 2023-08-02T05:25:56.794555+00:00 - - AdamISZ 2022-02-20 18:26:30+00:00 - - - Billy Tetrud 2022-01-30 15:39:04+00:00 - - - AdamISZ 2022-01-29 17:16:29+00:00 - - - Billy Tetrud 2022-01-28 15:27:30+00:00 - - - AdamISZ 2022-01-25 12:50:32+00:00 - - - Billy Tetrud 2022-01-25 11:53:36+00:00 - - - AdamISZ 2022-01-24 14:43:53+00:00 - + 2025-09-26T14:40:24.473389+00:00 + python-feedgen + + + [bitcoin-dev] PathCoin AdamISZ + 2022-01-24T14:43:00.000Z + + + Billy Tetrud + 2022-01-25T11:53:00.000Z + + + AdamISZ + 2022-01-25T12:50:00.000Z + + + Billy Tetrud + 2022-01-28T15:27:00.000Z + + + AdamISZ + 2022-01-29T17:16:00.000Z + + + Billy Tetrud + 2022-01-30T15:39:00.000Z + + + AdamISZ + 2022-02-20T18:26:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - PathCoin - 2023-08-02T05:25:56.794555+00:00 + 2025-09-26T14:40:24.474365+00:00 - The Bitcoin-dev mailing list is currently discussing a new idea called 'path coin', which aims to enable a fully trustless transfer of coins between parties. The first suggestion involves the use of an eltoo/D-R-O type mechanism, assuming APOAS, to eliminate the need for a fidelity bond requirement. This would remove the need for upfront collateral, making it more practical at scale. However, the timelock aspect would still remain, limiting its operation within a pre-agreed time window.Another suggestion revolves around jumping over hops in a fixed path of 100 users. It is believed that longer paths and the ability to jump over can provide more utility, potentially achieved through cleverly arranged lists of other paths. Signature adaptors and CTV or a similar covenant are proposed as a way to create a fully trustless transfer of control of a UTXO from one party to another with no interaction with the rest of the group at the time of transfer.The discussion also focuses on creating a trustless contract enforcement mechanism. One approach suggested is the use of burn mechanisms to enforce contracts, but concerns are raised about instability due to possible bribery and collusion. Instead, penalties consisting of a payment directly from the attacker to the attacked, which exceeds the amount stolen, are proposed as a stable alternative. This model is similar to the one used in Lightning.The conversation touches on the limitations of PathCoin and the need for further development. Sabu, a protocol with similar goals, is also mentioned but noted to have a vulnerability exploitable by miners. Overall, the objective is to explore potential solutions for creating a trustless contract enforcement mechanism.In the email exchange, AdamISZ introduces the concept of a toy version of sending coins like email, utilizing signature adaptors and CTV or similar covenants for a fully trustless transfer of control of a UTXO. While acknowledging the extreme limitations, AdamISZ shares the idea in hopes of further development by imaginative minds. Billy Tetrud responds by highlighting the instability of penalty via burn approaches, citing game theory challenges and the lack of incentives for honest parties to punish. He suggests that a trustless system can still be achieved through penalties as disincentives, as long as the penalty involves a payment from the attacker to the attacked that exceeds the amount stolen.The discussion also includes references to statechains, payment pools, and the Sabu protocol, all with different tradeoffs in achieving trustless systems. The focus remains on finding innovative solutions for trustless contract enforcement mechanisms.In summary, the Bitcoin-dev mailing list is exploring the concept of 'path coin' for a fully trustless transfer of coins between parties. Various ideas involving eltoo/D-R-O mechanisms, jumping over hops, and penalties as disincentives are being discussed. There is a recognition of limitations and the need for further development, but the aim is to find solutions for creating a trustless contract enforcement mechanism. 2022-02-20T18:26:30+00:00 + The Bitcoin-dev mailing list is currently discussing a new idea called 'path coin', which aims to enable a fully trustless transfer of coins between parties. The first suggestion involves the use of an eltoo/D-R-O type mechanism, assuming APOAS, to eliminate the need for a fidelity bond requirement. This would remove the need for upfront collateral, making it more practical at scale. However, the timelock aspect would still remain, limiting its operation within a pre-agreed time window.Another suggestion revolves around jumping over hops in a fixed path of 100 users. It is believed that longer paths and the ability to jump over can provide more utility, potentially achieved through cleverly arranged lists of other paths. Signature adaptors and CTV or a similar covenant are proposed as a way to create a fully trustless transfer of control of a UTXO from one party to another with no interaction with the rest of the group at the time of transfer.The discussion also focuses on creating a trustless contract enforcement mechanism. One approach suggested is the use of burn mechanisms to enforce contracts, but concerns are raised about instability due to possible bribery and collusion. Instead, penalties consisting of a payment directly from the attacker to the attacked, which exceeds the amount stolen, are proposed as a stable alternative. This model is similar to the one used in Lightning.The conversation touches on the limitations of PathCoin and the need for further development. Sabu, a protocol with similar goals, is also mentioned but noted to have a vulnerability exploitable by miners. Overall, the objective is to explore potential solutions for creating a trustless contract enforcement mechanism.In the email exchange, AdamISZ introduces the concept of a toy version of sending coins like email, utilizing signature adaptors and CTV or similar covenants for a fully trustless transfer of control of a UTXO. While acknowledging the extreme limitations, AdamISZ shares the idea in hopes of further development by imaginative minds. Billy Tetrud responds by highlighting the instability of penalty via burn approaches, citing game theory challenges and the lack of incentives for honest parties to punish. He suggests that a trustless system can still be achieved through penalties as disincentives, as long as the penalty involves a payment from the attacker to the attacked that exceeds the amount stolen.The discussion also includes references to statechains, payment pools, and the Sabu protocol, all with different tradeoffs in achieving trustless systems. The focus remains on finding innovative solutions for trustless contract enforcement mechanisms.In summary, the Bitcoin-dev mailing list is exploring the concept of 'path coin' for a fully trustless transfer of coins between parties. Various ideas involving eltoo/D-R-O mechanisms, jumping over hops, and penalties as disincentives are being discussed. There is a recognition of limitations and the need for further development, but the aim is to find solutions for creating a trustless contract enforcement mechanism. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_Renaming-full-nodes.xml b/static/bitcoin-dev/Jan_2022/combined_Renaming-full-nodes.xml index 7f625e7d82..52363b558c 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Renaming-full-nodes.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Renaming-full-nodes.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Renaming full nodes - 2023-08-02T05:24:34.321497+00:00 - - mm-studios 2022-01-23 13:06:36+00:00 - - - James Lu 2022-01-23 02:44:14+00:00 - + 2025-09-26T14:40:15.989709+00:00 + python-feedgen + + + [bitcoin-dev] Renaming full nodes James Lu + 2022-01-23T02:44:00.000Z + + + mm-studios + 2022-01-23T13:06:00.000Z + + - python-feedgen + 2 Combined summary - Renaming full nodes - 2023-08-02T05:24:34.321497+00:00 + 2025-09-26T14:40:15.990162+00:00 - The writer of this message is concerned about the limited accessibility of becoming a Bitcoin miner, as it is largely dominated by wealthy individuals. They question whether there is a correlation between wealth and running an honest node, and reject the notion that having "skin in the game" automatically equates to honesty. Despite this concern, the writer acknowledges that the validation of blocks on the Bitcoin network is decentralized.James Lu suggests renaming full nodes to "validator nodes" in order to highlight their role in verifying the validity of blocks. This proposed name change aims to alleviate confusion surrounding the control of the Bitcoin network by mining nodes. By emphasizing the importance of validator nodes, it becomes evident that Bitcoin operates on a decentralized network where anyone can run a validator node, even with a low-end laptop.The suggested renaming of full nodes as "validator nodes" would serve to clarify that Bitcoin is not controlled solely by a select group of wealthy individuals. Instead, the network relies on the collective effort of participants who run validator nodes to ensure the integrity of the system. This change in terminology would make it easier for people to grasp the significance of full nodes in maintaining the overall security and stability of the Bitcoin network. 2022-01-23T13:06:36+00:00 + The writer of this message is concerned about the limited accessibility of becoming a Bitcoin miner, as it is largely dominated by wealthy individuals. They question whether there is a correlation between wealth and running an honest node, and reject the notion that having "skin in the game" automatically equates to honesty. Despite this concern, the writer acknowledges that the validation of blocks on the Bitcoin network is decentralized.James Lu suggests renaming full nodes to "validator nodes" in order to highlight their role in verifying the validity of blocks. This proposed name change aims to alleviate confusion surrounding the control of the Bitcoin network by mining nodes. By emphasizing the importance of validator nodes, it becomes evident that Bitcoin operates on a decentralized network where anyone can run a validator node, even with a low-end laptop.The suggested renaming of full nodes as "validator nodes" would serve to clarify that Bitcoin is not controlled solely by a select group of wealthy individuals. Instead, the network relies on the collective effort of participants who run validator nodes to ensure the integrity of the system. This change in terminology would make it easier for people to grasp the significance of full nodes in maintaining the overall security and stability of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml b/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml index af66d23b31..01ae2ec796 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2023-08-02T05:21:36.067269+00:00 + 2025-09-26T14:40:18.133622+00:00 + python-feedgen Billy Tetrud 2022-02-22 12:57:15+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2023-08-02T05:21:36.067269+00:00 + 2025-09-26T14:40:18.133807+00:00 - In a recent discussion about Bitcoin scaling, there was disagreement over whether it should be done rapidly or not. Some argue that scaling should not be delayed to keep fees high, suggesting that if higher fees are needed, the block size can be lowered or the default minimum relay fee rate increased. They also question the belief that the Lightning Network is the main cause of low fees and argue that delaying scaling would harm Bitcoin's growth.On the other hand, others argue that new use cases for on-chain transactions may compete with existing users for limited blockchain space. This situation has been compared to the saying "nobody goes there anymore, it's too crowded." The discussion also touched upon the issue of invoking Satoshi's opinions in present-day discussions. One participant objected to assumptions about the founder of Bitcoin, arguing that Satoshi is more than just a pseudonym and will live on forever. However, another participant objected to the invocation of Satoshi in general, suggesting that if he wants to participate in Bitcoin development today, he can speak for himself. They added that if Satoshi refuses to participate, his opinion is irrelevant. In an email exchange posted on a Bitcoin forum, Prayank objects to ZmnSCPxj's invocation of Satoshi, stating that he cares about Satoshi's opinions, especially regarding subsidies. ZmnSCPxj counters by arguing that if Satoshi refuses to participate in Bitcoin development today, it doesn't matter what his opinion is. He asserts that Satoshi is dead and Bitcoin lives on without him. Prayank objects to this assumption, insisting that Satoshi is more than just a pseudonym and will live on forever. Both parties acknowledge that they are considering the various arguments being presented.In another post, ZmnSCPxj mentions that improvements like the Taproot upgrade can reduce activity on the blockchain and increase functionality without requiring an increase in block size. The Taproot upgrade offers features such as Schnorr multisignatures, MAST, `SIGHASH_ANYPREVOUT`, and `OP_CTV`, which reduce block size usage for complex contracts, enable offchain updateable multiparty cryptocurrency systems, and allow transactional cut-through without immediate output publication. ZmnSCPxj believes that these upgrades enhance Bitcoin's functionality and provide opportunities to use the blockchain in a different way.There is also a discussion about the expansion of use-cases in Ethereum potentially harming Bitcoin by fueling future contentious blocksize debates due to high on-chain fees. However, the counterargument is that fees will be the incentives for miners as subsidy decreases, and it will depend on the demand for block space. Additionally, if this is the reason to stop or delay improvements in Bitcoin, it may apply to Taproot as well. A proposal for a lightning-compatible mimblewimble+dandelion on-chain soft fork is mentioned as a way to reduce transaction size, improve privacy, and move more small transactions off-chain. However, it is suggested that this should not be released for another two years as timing is crucial for Bitcoin innovation.Furthermore, there is a discussion about the lack of compelling use-cases beneficial to all users, with some shared use cases being considered too narrow. The Drivechains use-case is deemed harmful to the security of Bitcoin as a whole. It is argued that the new uses for on-chain transactions mentioned as a use-case could harm existing users by competing for limited blockchain space. As a result, it is concluded that any core consensus changes to the Bitcoin system must be carefully evaluated against the risks.In the Bitcoin developer community, there is a debate about the readiness and potential risks of implementing the proposed consensus change known as OP_CTV. Some developers argue for its activation in a few months, while others express skepticism and call for more testing and research. Other soft fork proposals, such as BIP 118 focusing on eltoo payment channels, are also discussed. Concerns are raised about rushing through consensus changes without thorough examination and community support. Skeptics emphasize the need for technical discussions and engagement to address potential issues. Despite differing opinions, there is a general agreement that implementing a soft fork within the next few months is feasible with proper precautions. The discussion highlights the importance of responsible decision-making and avoiding contentious activation attempts. IRC workshops on BIP 119 are mentioned as a resource for engaging with skeptics on technical concerns. 2022-02-22T12:57:15+00:00 + In a recent discussion about Bitcoin scaling, there was disagreement over whether it should be done rapidly or not. Some argue that scaling should not be delayed to keep fees high, suggesting that if higher fees are needed, the block size can be lowered or the default minimum relay fee rate increased. They also question the belief that the Lightning Network is the main cause of low fees and argue that delaying scaling would harm Bitcoin's growth.On the other hand, others argue that new use cases for on-chain transactions may compete with existing users for limited blockchain space. This situation has been compared to the saying "nobody goes there anymore, it's too crowded." The discussion also touched upon the issue of invoking Satoshi's opinions in present-day discussions. One participant objected to assumptions about the founder of Bitcoin, arguing that Satoshi is more than just a pseudonym and will live on forever. However, another participant objected to the invocation of Satoshi in general, suggesting that if he wants to participate in Bitcoin development today, he can speak for himself. They added that if Satoshi refuses to participate, his opinion is irrelevant. In an email exchange posted on a Bitcoin forum, Prayank objects to ZmnSCPxj's invocation of Satoshi, stating that he cares about Satoshi's opinions, especially regarding subsidies. ZmnSCPxj counters by arguing that if Satoshi refuses to participate in Bitcoin development today, it doesn't matter what his opinion is. He asserts that Satoshi is dead and Bitcoin lives on without him. Prayank objects to this assumption, insisting that Satoshi is more than just a pseudonym and will live on forever. Both parties acknowledge that they are considering the various arguments being presented.In another post, ZmnSCPxj mentions that improvements like the Taproot upgrade can reduce activity on the blockchain and increase functionality without requiring an increase in block size. The Taproot upgrade offers features such as Schnorr multisignatures, MAST, `SIGHASH_ANYPREVOUT`, and `OP_CTV`, which reduce block size usage for complex contracts, enable offchain updateable multiparty cryptocurrency systems, and allow transactional cut-through without immediate output publication. ZmnSCPxj believes that these upgrades enhance Bitcoin's functionality and provide opportunities to use the blockchain in a different way.There is also a discussion about the expansion of use-cases in Ethereum potentially harming Bitcoin by fueling future contentious blocksize debates due to high on-chain fees. However, the counterargument is that fees will be the incentives for miners as subsidy decreases, and it will depend on the demand for block space. Additionally, if this is the reason to stop or delay improvements in Bitcoin, it may apply to Taproot as well. A proposal for a lightning-compatible mimblewimble+dandelion on-chain soft fork is mentioned as a way to reduce transaction size, improve privacy, and move more small transactions off-chain. However, it is suggested that this should not be released for another two years as timing is crucial for Bitcoin innovation.Furthermore, there is a discussion about the lack of compelling use-cases beneficial to all users, with some shared use cases being considered too narrow. The Drivechains use-case is deemed harmful to the security of Bitcoin as a whole. It is argued that the new uses for on-chain transactions mentioned as a use-case could harm existing users by competing for limited blockchain space. As a result, it is concluded that any core consensus changes to the Bitcoin system must be carefully evaluated against the risks.In the Bitcoin developer community, there is a debate about the readiness and potential risks of implementing the proposed consensus change known as OP_CTV. Some developers argue for its activation in a few months, while others express skepticism and call for more testing and research. Other soft fork proposals, such as BIP 118 focusing on eltoo payment channels, are also discussed. Concerns are raised about rushing through consensus changes without thorough examination and community support. Skeptics emphasize the need for technical discussions and engagement to address potential issues. Despite differing opinions, there is a general agreement that implementing a soft fork within the next few months is feasible with proper precautions. The discussion highlights the importance of responsible decision-making and avoiding contentious activation attempts. IRC workshops on BIP 119 are mentioned as a resource for engaging with skeptics on technical concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml b/static/bitcoin-dev/Jan_2022/combined_TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml index 96ae193d28..4a595dfc76 100644 --- a/static/bitcoin-dev/Jan_2022/combined_TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml +++ b/static/bitcoin-dev/Jan_2022/combined_TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml @@ -1,89 +1,243 @@ - + 2 Combined summary - TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2023-08-02T05:27:45.946150+00:00 - - Russell O'Connor 2022-02-17 14:50:53+00:00 - - - Anthony Towns 2022-02-17 14:27:27+00:00 - - - Russell O'Connor 2022-02-16 04:10:19+00:00 - - - Rusty Russell 2022-02-16 02:26:14+00:00 - - - Russell O'Connor 2022-02-15 19:12:30+00:00 - - - Jeremy Rubin 2022-02-15 18:57:35+00:00 - - - Rusty Russell 2022-02-15 08:45:10+00:00 - - - Jeremy Rubin 2022-02-08 04:34:30+00:00 - - - Rusty Russell 2022-02-08 03:40:15+00:00 - - - Russell O'Connor 2022-02-08 02:16:10+00:00 - - - Anthony Towns 2022-02-01 01:16:39+00:00 - - - Anthony Towns 2022-01-31 02:18:52+00:00 - - - Russell O'Connor 2022-01-29 17:14:43+00:00 - - - Jeremy Rubin 2022-01-29 17:02:37+00:00 - - - Russell O'Connor 2022-01-29 15:43:13+00:00 - - - Jeremy 2022-01-28 16:38:58+00:00 - - - James O'Beirne 2022-01-28 15:14:12+00:00 - - - Anthony Towns 2022-01-28 14:17:40+00:00 - - - Russell O'Connor 2022-01-28 14:13:11+00:00 - - - Russell O'Connor 2022-01-28 13:56:25+00:00 - - - Michael Folkson 2022-01-28 13:14:07+00:00 - - - Anthony Towns 2022-01-28 01:34:36+00:00 - - - James O'Beirne 2022-01-28 00:18:54+00:00 - - - Russell O'Connor 2022-01-27 19:16:33+00:00 - - - James Lu 2022-01-27 04:20:40+00:00 - - - Jeremy 2022-01-26 22:16:06+00:00 - - - Russell O'Connor 2022-01-26 17:20:10+00:00 - + 2025-09-26T14:40:33.073144+00:00 + python-feedgen + + + [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT Russell O'Connor + 2022-01-26T17:20:00.000Z + + + Jeremy + 2022-01-26T22:16:00.000Z + + + James Lu + 2022-01-27T04:20:00.000Z + + + Russell O'Connor + 2022-01-27T19:16:00.000Z + + + James O'Beirne + 2022-01-28T00:18:00.000Z + + + Anthony Towns + 2022-01-28T01:34:00.000Z + + + Michael Folkson + 2022-01-28T13:14:00.000Z + + + Russell O'Connor + 2022-01-28T13:56:00.000Z + + + Russell O'Connor + 2022-01-28T14:13:00.000Z + + + Anthony Towns + 2022-01-28T14:17:00.000Z + + + James O'Beirne + 2022-01-28T15:14:00.000Z + + + Jeremy + 2022-01-28T16:38:00.000Z + + + Russell O'Connor + 2022-01-29T15:43:00.000Z + + + Jeremy Rubin + 2022-01-29T17:02:00.000Z + + + Russell O'Connor + 2022-01-29T17:14:00.000Z + + + Anthony Towns + 2022-01-31T02:18:00.000Z + + + Anthony Towns + 2022-02-01T01:16:00.000Z + + + Russell O'Connor + 2022-02-08T02:16:00.000Z + + + Rusty Russell + 2022-02-08T03:40:00.000Z + + + Jeremy Rubin + 2022-02-08T04:34:00.000Z + + + [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding + 2022-02-11T00:55:00.000Z + + + Jeremy Rubin + 2022-02-11T03:42:00.000Z + + + James O'Beirne + 2022-02-11T17:42:00.000Z + + + digital vagabond + 2022-02-11T18:12:00.000Z + + + darosior + 2022-02-12T10:54:00.000Z + + + Billy Tetrud + 2022-02-12T15:59:00.000Z + + + [bitcoin-dev] " Rusty Russell + 2022-02-15T08:45:00.000Z + + + Jeremy Rubin + 2022-02-15T18:57:00.000Z + + + Russell O'Connor + 2022-02-15T19:12:00.000Z + + + Rusty Russell + 2022-02-16T02:26:00.000Z + + + Russell O'Connor + 2022-02-16T04:10:00.000Z + + + Anthony Towns + 2022-02-17T14:27:00.000Z + + + Russell O'Connor + 2022-02-17T14:50:00.000Z + + + Anthony Towns + 2022-02-17T15:15:00.000Z + + + ZmnSCPxj + 2022-02-18T07:34:00.000Z + + + ZmnSCPxj + 2022-02-23T11:28:00.000Z + + + Paul Sztorc + 2022-02-23T18:14:00.000Z + + + ZmnSCPxj + 2022-02-24T02:20:00.000Z + + + Anthony Towns + 2022-02-24T06:53:00.000Z + + + ZmnSCPxj + 2022-02-24T12:03:00.000Z + + + Billy Tetrud + 2022-02-26T05:38:00.000Z + + + Anthony Towns + 2022-02-26T06:00:00.000Z + + + ZmnSCPxj + 2022-02-26T06:43:00.000Z + + + Paul Sztorc + 2022-02-27T00:58:00.000Z + + + ZmnSCPxj + 2022-02-27T02:00:00.000Z + + + ZmnSCPxj + 2022-02-27T07:25:00.000Z + + + Billy Tetrud + 2022-02-27T16:59:00.000Z + + + Paul Sztorc + 2022-02-27T23:50:00.000Z + + + Paul Sztorc + 2022-02-28T00:20:00.000Z + + + ZmnSCPxj + 2022-02-28T06:49:00.000Z + + + vjudeu + 2022-02-28T07:55:00.000Z + + + Paul Sztorc + 2022-02-28T22:54:00.000Z + + + Billy Tetrud + 2022-03-01T05:39:00.000Z + + + Paul Sztorc + 2022-03-02T00:00:00.000Z + + + ZmnSCPxj + 2022-03-04T08:42:00.000Z + + + Billy Tetrud + 2022-03-04T12:35:00.000Z + + + vjudeu + 2022-03-04T13:43:00.000Z + + + Paul Sztorc + 2022-03-04T20:06:00.000Z + + @@ -111,13 +265,13 @@ - python-feedgen + 2 Combined summary - TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2023-08-02T05:27:45.947186+00:00 + 2025-09-26T14:40:33.079267+00:00 - In a technical discussion on the bitcoin-dev mailing list, various topics related to transaction introspection, Discreet Log Contracts (DLCs), and programmable systems were debated. It was noted that Discreet Log Contracts provide interesting oracle behavior without transaction introspection, but CSFSV allows for pubkey delegation, which was not previously mentioned. The potential combination of the TXHASH proposal with CAT and rolling SHA256 opcodes to create a programmable system at redemption time was discussed. The usefulness of "CAT" and "CHECKSIGFROMSTACK" in practical applications and the need for a more ideal programming language were also debated.There were concerns raised about whether the proposal covers all future needs, particularly regarding SIGHASH_GROUP. The advantages and disadvantages of using CTV versus TXHASH for transaction validation were discussed. It was noted that while CTV appears to be more flexible, there is a lack of third-party experimentation, making it potentially unsuitable for deployment on mainnet. The pros and cons of bundling CTV with APO and SIGHASH_GROUP were considered, with the conclusion that they should only be bundled if fully specced, implemented, and tested.Jeremy Rubin highlighted the differences between CTV and TXHASH, noting that CTV requires the contract to be fully enumerated and is non-recursive, limiting its applicability. Rusty Russell agreed with this assessment, emphasizing the importance of making tools as clean and clear as possible. There was a discussion about the possibility of using CTV in recursive covenants, with concerns raised about the limitations of fully enumerating contracts and the need to know the set of pairs in advance. It was suggested that iterative covenants are possible with CTV and just as powerful, though technically finite.Russell O'Connor proposed decomposing CTV and ANYPREVOUT into their constituent pieces and programmatically reassembling their behavior. Further decomposition of OP_TXHASH and defining bits for controlling various aspects of a transaction was suggested. The use of SHA256() of scripts instead of the scripts themselves was also proposed. There were discussions about the potential enhancements of Bitcoin Script's functionality, including the combination of TXHASH with CAT and/or rolling SHA256 opcodes. The need for a flexible and expressive scripting system was emphasized, with the possibility of adding specific features as new ideas emerge.The efficiency and usefulness of CTV in comparison to a more general covenant system were debated, with the argument that if CTV is efficient for expressing useful patterns like vaults, it should not be considered technical debt. The importance of considering the long-term implications of design choices was highlighted. Concerns were raised about the complexity and potential challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. However, it was noted that CTV is currently the most practical approach for vaulting and has a low maintenance burden.There were discussions about the potential risks and challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. The possibility of creating complex or recursive covenants using TXHASH and CSFSV was debated, with differing opinions on whether CAT is needed for such constructions. The availability of custom signets with CTV was questioned, with the absence of readily available faucets noted as a possible limitation. The efficiency and usefulness of CTV in comparison to a more general covenant system were discussed, along with the potential benefits and limitations of CTV's hash structure. The proposal of an alternative way to extend the set of txflags for TXHASH was considered, highlighting the benefits and potential challenges of this approach.The discussion on covenant opcodes involved debates about technical debt, soft fork processes, and the risks associated with them. Some stakeholders advocated for implementing CTV, while others suggested that TXHASH+CSFSV would provide more value and enable oracle signature verification. The complexity of these proposals and the potential for quadratic hashing bugs were raised as concerns. It was agreed that while TXHASH is a theoretical approach worth exploring, CTV is preferred for its practicality and availability timeline. The proposal suggested decomposing the operations of CTV and ANYPREVOUT and reassembling their behavior programmatically. Alternative proposals like OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY were also considered.Overall, the discussions on implementing a CTV opcode in Bitcoin Script involved considerations of efficiency, usefulness, technical debt, and long-term implications. There were debates about the viability of creating complex or recursive covenants using existing opcodes and the need for additional ones. The availability of custom signets with CTV and the challenges associated with testing and upgrading were also discussed. Stakeholders emphasized the importance of thoroughly developing and testing these solutions before implementation on the mainnet.The proposal suggested the introduction of new opcodes to verify signatures on messages signed by oracles for oracle applications. These opcodes could be combined with multiple calls to TXHASH to create signatures that commit to specific subsets of transaction data. The potential 2022-02-17T14:50:53+00:00 + In a technical discussion on the bitcoin-dev mailing list, various topics related to transaction introspection, Discreet Log Contracts (DLCs), and programmable systems were debated. It was noted that Discreet Log Contracts provide interesting oracle behavior without transaction introspection, but CSFSV allows for pubkey delegation, which was not previously mentioned. The potential combination of the TXHASH proposal with CAT and rolling SHA256 opcodes to create a programmable system at redemption time was discussed. The usefulness of "CAT" and "CHECKSIGFROMSTACK" in practical applications and the need for a more ideal programming language were also debated.There were concerns raised about whether the proposal covers all future needs, particularly regarding SIGHASH_GROUP. The advantages and disadvantages of using CTV versus TXHASH for transaction validation were discussed. It was noted that while CTV appears to be more flexible, there is a lack of third-party experimentation, making it potentially unsuitable for deployment on mainnet. The pros and cons of bundling CTV with APO and SIGHASH_GROUP were considered, with the conclusion that they should only be bundled if fully specced, implemented, and tested.Jeremy Rubin highlighted the differences between CTV and TXHASH, noting that CTV requires the contract to be fully enumerated and is non-recursive, limiting its applicability. Rusty Russell agreed with this assessment, emphasizing the importance of making tools as clean and clear as possible. There was a discussion about the possibility of using CTV in recursive covenants, with concerns raised about the limitations of fully enumerating contracts and the need to know the set of pairs in advance. It was suggested that iterative covenants are possible with CTV and just as powerful, though technically finite.Russell O'Connor proposed decomposing CTV and ANYPREVOUT into their constituent pieces and programmatically reassembling their behavior. Further decomposition of OP_TXHASH and defining bits for controlling various aspects of a transaction was suggested. The use of SHA256() of scripts instead of the scripts themselves was also proposed. There were discussions about the potential enhancements of Bitcoin Script's functionality, including the combination of TXHASH with CAT and/or rolling SHA256 opcodes. The need for a flexible and expressive scripting system was emphasized, with the possibility of adding specific features as new ideas emerge.The efficiency and usefulness of CTV in comparison to a more general covenant system were debated, with the argument that if CTV is efficient for expressing useful patterns like vaults, it should not be considered technical debt. The importance of considering the long-term implications of design choices was highlighted. Concerns were raised about the complexity and potential challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. However, it was noted that CTV is currently the most practical approach for vaulting and has a low maintenance burden.There were discussions about the potential risks and challenges associated with implementing CTV, such as technical debt and the need for additional hash formats. The possibility of creating complex or recursive covenants using TXHASH and CSFSV was debated, with differing opinions on whether CAT is needed for such constructions. The availability of custom signets with CTV was questioned, with the absence of readily available faucets noted as a possible limitation. The efficiency and usefulness of CTV in comparison to a more general covenant system were discussed, along with the potential benefits and limitations of CTV's hash structure. The proposal of an alternative way to extend the set of txflags for TXHASH was considered, highlighting the benefits and potential challenges of this approach.The discussion on covenant opcodes involved debates about technical debt, soft fork processes, and the risks associated with them. Some stakeholders advocated for implementing CTV, while others suggested that TXHASH+CSFSV would provide more value and enable oracle signature verification. The complexity of these proposals and the potential for quadratic hashing bugs were raised as concerns. It was agreed that while TXHASH is a theoretical approach worth exploring, CTV is preferred for its practicality and availability timeline. The proposal suggested decomposing the operations of CTV and ANYPREVOUT and reassembling their behavior programmatically. Alternative proposals like OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY were also considered.Overall, the discussions on implementing a CTV opcode in Bitcoin Script involved considerations of efficiency, usefulness, technical debt, and long-term implications. There were debates about the viability of creating complex or recursive covenants using existing opcodes and the need for additional ones. The availability of custom signets with CTV and the challenges associated with testing and upgrading were also discussed. Stakeholders emphasized the importance of thoroughly developing and testing these solutions before implementation on the mainnet.The proposal suggested the introduction of new opcodes to verify signatures on messages signed by oracles for oracle applications. These opcodes could be combined with multiple calls to TXHASH to create signatures that commit to specific subsets of transaction data. The potential - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_Take-2-Removing-the-Dust-Limit.xml b/static/bitcoin-dev/Jan_2022/combined_Take-2-Removing-the-Dust-Limit.xml index 28b30b723a..def4cbbb23 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Take-2-Removing-the-Dust-Limit.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Take-2-Removing-the-Dust-Limit.xml @@ -1,32 +1,39 @@ - + 2 Combined summary - Take 2: Removing the Dust Limit - 2023-08-02T05:12:48.753724+00:00 - - shymaa arafat 2022-01-21 12:16:35+00:00 - - - damian at willtech.com.au 2021-12-09 06:27:04+00:00 - - - Ruben Somsen 2021-12-08 22:51:50+00:00 - - - Jeremy 2021-12-08 17:41:34+00:00 - - - Jeremy 2021-12-08 17:18:49+00:00 - - - Ruben Somsen 2021-12-08 10:46:22+00:00 - - - Bastien TEINTURIER 2021-12-08 08:34:32+00:00 - - - Jeremy 2021-12-08 01:28:42+00:00 - + 2025-09-26T14:39:56.734415+00:00 + python-feedgen + + + [bitcoin-dev] Take 2: Removing the Dust Limit Jeremy + 2021-12-08T01:28:00.000Z + + + Bastien TEINTURIER + 2021-12-08T08:34:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Ruben Somsen + 2021-12-08T10:46:00.000Z + + + [bitcoin-dev] " Jeremy + 2021-12-08T17:18:00.000Z + + + Jeremy + 2021-12-08T17:41:00.000Z + + + Ruben Somsen + 2021-12-08T22:51:00.000Z + + + damian + 2021-12-09T06:27:00.000Z + + @@ -35,13 +42,13 @@ - python-feedgen + 2 Combined summary - Take 2: Removing the Dust Limit - 2023-08-02T05:12:48.753724+00:00 + 2025-09-26T14:39:56.735244+00:00 - In an email exchange between Bitcoin developers, the issue of 0 value outputs in transactions is discussed. Jeremy Rubin proposes a carve-out that would allow 0 value outputs to be used as Intermediate Outputs, but with certain conditions. The parent transaction must have a higher feerate after Child Pays For Parent (CPFP) than the parent alone. This proposal aims to prevent the proliferation of 0 value utxos while still allowing them to be spent by the fee-paying transaction later. It is suggested that this rule could be beneficial for Anchor Outputs and CTV-based contracts, as well as spacechains. Rubin believes that introducing this rule as a mempool policy would not require new validation rules. However, it is noted that this proposal relies on a fully functional package relay system. Overall, Rubin's proposal addresses the issues surrounding the creation of 0 value outputs for immediately spendable outputs. 2022-01-21T12:16:35+00:00 + In an email exchange between Bitcoin developers, the issue of 0 value outputs in transactions is discussed. Jeremy Rubin proposes a carve-out that would allow 0 value outputs to be used as Intermediate Outputs, but with certain conditions. The parent transaction must have a higher feerate after Child Pays For Parent (CPFP) than the parent alone. This proposal aims to prevent the proliferation of 0 value utxos while still allowing them to be spent by the fee-paying transaction later. It is suggested that this rule could be beneficial for Anchor Outputs and CTV-based contracts, as well as spacechains. Rubin believes that introducing this rule as a mempool policy would not require new validation rules. However, it is noted that this proposal relies on a fully functional package relay system. Overall, Rubin's proposal addresses the issues surrounding the creation of 0 value outputs for immediately spendable outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_bip39.xml b/static/bitcoin-dev/Jan_2022/combined_bip39.xml index 941eb3176d..304ded9337 100644 --- a/static/bitcoin-dev/Jan_2022/combined_bip39.xml +++ b/static/bitcoin-dev/Jan_2022/combined_bip39.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - bip39 - 2023-08-02T05:23:58.009016+00:00 - - Billy Tetrud 2022-01-18 16:33:04+00:00 - - - Pavol Rusnak 2022-01-17 22:45:20+00:00 - - - Jeremy 2022-01-17 22:38:12+00:00 - - - Erik Aronesty 2022-01-17 21:51:55+00:00 - + 2025-09-26T14:39:58.844831+00:00 + python-feedgen + + + [bitcoin-dev] bip39 Erik Aronesty + 2022-01-17T21:51:00.000Z + + + Jeremy + 2022-01-17T22:38:00.000Z + + + Pavol Rusnak + 2022-01-17T22:45:00.000Z + + + Billy Tetrud + 2022-01-18T16:33:00.000Z + + - python-feedgen + 2 Combined summary - bip39 - 2023-08-02T05:23:58.010016+00:00 + 2025-09-26T14:39:58.845505+00:00 - The Bitcoin-dev mailing list recently discussed the potential confusion caused by similar-sounding words in the BIP39 wordlist used for seed recovery cards. Erik Aronesty brought up the issue of adjacent ambiguity, citing examples like "art", "work", and "artwork" being three different words. Duplicates were also mentioned, such as "canal" and "arm" versus "can" and "alarm". Jeremy Rubin suggested adding non-void whitespace characters to address this problem, while acknowledging the difficulty of changing the BIP39 standard list that software expects. The idea of rejecting seeds with similar-sounding word pairs was also considered, but the extent of entropy loss remained uncertain.The discussion further delved into Trezor recovery cards, which feature each word in a separate box and require users to write them one under the other instead of side by side. Pavol Rusnak, co-founder of SatoshiLabs, provided an example of a Trezor recovery card and proposed removing words that are strict subsets of others, like "add" being a subset of "addict" and "address". It was noted that even with a 1000-word list and a 12-word seed, the chances of randomly generating a duplicate seed would be exceedingly rare, far surpassing the age of the universe, even if every person on Earth generated 1000 seeds per second. Therefore, the concern over entropy loss was deemed insignificant.In summary, the bitcoin-dev mailing list discussed the potential confusion caused by similar-sounding words in seed recovery cards. Various solutions were proposed, including the use of non-void whitespace characters and the rejection of seeds with similar-sounding word pairs. However, changing the BIP39 standard list proved challenging due to software expectations. The discussion also touched on Trezor recovery cards and the importance of clear communication to avoid confusion. 2022-01-18T16:33:04+00:00 + The Bitcoin-dev mailing list recently discussed the potential confusion caused by similar-sounding words in the BIP39 wordlist used for seed recovery cards. Erik Aronesty brought up the issue of adjacent ambiguity, citing examples like "art", "work", and "artwork" being three different words. Duplicates were also mentioned, such as "canal" and "arm" versus "can" and "alarm". Jeremy Rubin suggested adding non-void whitespace characters to address this problem, while acknowledging the difficulty of changing the BIP39 standard list that software expects. The idea of rejecting seeds with similar-sounding word pairs was also considered, but the extent of entropy loss remained uncertain.The discussion further delved into Trezor recovery cards, which feature each word in a separate box and require users to write them one under the other instead of side by side. Pavol Rusnak, co-founder of SatoshiLabs, provided an example of a Trezor recovery card and proposed removing words that are strict subsets of others, like "add" being a subset of "addict" and "address". It was noted that even with a 1000-word list and a 12-word seed, the chances of randomly generating a duplicate seed would be exceedingly rare, far surpassing the age of the universe, even if every person on Earth generated 1000 seeds per second. Therefore, the concern over entropy loss was deemed insignificant.In summary, the bitcoin-dev mailing list discussed the potential confusion caused by similar-sounding words in seed recovery cards. Various solutions were proposed, including the use of non-void whitespace characters and the rejection of seeds with similar-sounding word pairs. However, changing the BIP39 standard list proved challenging due to software expectations. The discussion also touched on Trezor recovery cards and the importance of clear communication to avoid confusion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_non-default-ports-for-automatic-connections-in-Bitcoin-P2P-network.xml b/static/bitcoin-dev/Jan_2022/combined_non-default-ports-for-automatic-connections-in-Bitcoin-P2P-network.xml index 2f705fb235..ce3d39d58b 100644 --- a/static/bitcoin-dev/Jan_2022/combined_non-default-ports-for-automatic-connections-in-Bitcoin-P2P-network.xml +++ b/static/bitcoin-dev/Jan_2022/combined_non-default-ports-for-automatic-connections-in-Bitcoin-P2P-network.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - non-default ports for automatic connections in Bitcoin P2P network - 2023-08-02T05:33:11.258363+00:00 - - Vasil Dimov 2022-02-02 13:30:47+00:00 - - - Prayank 2022-01-29 22:02:24+00:00 - + 2025-09-26T14:40:26.585464+00:00 + python-feedgen + + + [bitcoin-dev] non-default ports for automatic connections in Bitcoin P2P network Prayank + 2022-01-29T22:02:00.000Z + + + Vasil Dimov + 2022-02-02T13:30:00.000Z + + - python-feedgen + 2 Combined summary - non-default ports for automatic connections in Bitcoin P2P network - 2023-08-02T05:33:11.258363+00:00 + 2025-09-26T14:40:26.585921+00:00 - The Bitcoin Core has a preference for peers that listen on port 8333, and currently, it does not allow incoming connections from those who do not use this port. To address the issue of ISPs blocking the default port 8333, a pull request was merged in October 2021 that allows for non-default ports to be used for automatic connections. Another pull request in November 2021 made further changes to support non-default ports. Although no major issues were found during the review process, there was some discussion and minor suggestions from a reviewer.The option to change the default port was added in May 2011 by Gavin Andresen after a user raised concerns about the default port 8333 on bitcointalk in July 2010. Additionally, a PowerShell script was written and tested on version 22.0 to ban all peers every 100 seconds using the default port, which worked as expected. The default ports used in Bitcoin Core are 8333 for mainnet, 18333 for testnet, 18444 for regtest, and 38333 for signet.It is unclear whether Satoshi considered the fact that 8333 in leet becomes 'beee' in plaintext when choosing the default port for Bitcoin. However, the inclusion of the bad ports list in PR #23542 remains unclear. For more details and justifications regarding these matters, the relevant pull requests and discussions can be found on GitHub.To conclude, Prayank shared information about automatic outgoing connections to peers at non-default ports, emphasizing that the discussion focuses solely on this matter to avoid confusion. Vasil Dimov signed off with his email ID and included a quote by Winston Churchill on diplomacy. 2022-02-02T13:30:47+00:00 + The Bitcoin Core has a preference for peers that listen on port 8333, and currently, it does not allow incoming connections from those who do not use this port. To address the issue of ISPs blocking the default port 8333, a pull request was merged in October 2021 that allows for non-default ports to be used for automatic connections. Another pull request in November 2021 made further changes to support non-default ports. Although no major issues were found during the review process, there was some discussion and minor suggestions from a reviewer.The option to change the default port was added in May 2011 by Gavin Andresen after a user raised concerns about the default port 8333 on bitcointalk in July 2010. Additionally, a PowerShell script was written and tested on version 22.0 to ban all peers every 100 seconds using the default port, which worked as expected. The default ports used in Bitcoin Core are 8333 for mainnet, 18333 for testnet, 18444 for regtest, and 38333 for signet.It is unclear whether Satoshi considered the fact that 8333 in leet becomes 'beee' in plaintext when choosing the default port for Bitcoin. However, the inclusion of the bad ports list in PR #23542 remains unclear. For more details and justifications regarding these matters, the relevant pull requests and discussions can be found on GitHub.To conclude, Prayank shared information about automatic outgoing connections to peers at non-default ports, emphasizing that the discussion focuses solely on this matter to avoid confusion. Vasil Dimov signed off with his email ID and included a quote by Winston Churchill on diplomacy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_A-Bitcoin-NFT-System.xml b/static/bitcoin-dev/Jan_2023/combined_A-Bitcoin-NFT-System.xml index 6a1e70e385..3e7e0dfae5 100644 --- a/static/bitcoin-dev/Jan_2023/combined_A-Bitcoin-NFT-System.xml +++ b/static/bitcoin-dev/Jan_2023/combined_A-Bitcoin-NFT-System.xml @@ -1,27 +1,29 @@ - + 2 Combined summary - A Bitcoin NFT System - 2023-08-02T08:44:42.612561+00:00 - - Aymeric Vitte 2023-01-05 10:46:59+00:00 - - - Vincenzo 2023-01-04 20:59:49+00:00 - - - Aymeric Vitte 2022-12-29 16:49:46+00:00 - + 2025-09-26T14:31:57.137524+00:00 + python-feedgen + + + Vincenzo + 2023-01-04T20:59:00.000Z + + + Aymeric Vitte + 2023-01-05T10:46:00.000Z + + - python-feedgen + 2 Combined summary - A Bitcoin NFT System - 2023-08-02T08:44:42.612561+00:00 + 2025-09-26T14:31:57.137987+00:00 - Aymeric Vitte and Vincenzo engaged in an email exchange discussing their views on the current state of NFTs. Aymeric expressed dissatisfaction with the centralized, insecure, duplicable, virtual, stealable, unsigned, and expensive nature of NFTs. However, he acknowledged that if NFTs were expanded to include anything that can be bought or stored in the real world, web, or metaverse, they would become more interesting.Aymeric pointed out that Ethereum is the primary platform for NFTs, but described the situation as a "mess." He shared a link to his proposal for a decentralized, secure, and cost-effective Bitcoin NFT system. Unfortunately, the provided link to the proposal appears to be inaccessible.The proposed Bitcoin NFT system aims to avoid the shortcomings of the current NFT ecosystem. It suggests using SHA-256 for a simple reference to the NFT hash. Aymeric explains various aspects of the system, including minting NFTs on Bitcoin, minting multiple NFTs in a single transaction, preventing double minting, transferring NFTs for free, buying and selling NFTs, and using Chainpoint for purchasing NFTs.To ensure security and combat counterfeits, the proposed system involves using a double hash in transactions. This approach allows the buyer and seller to verify the authenticity of the NFT by comparing the original hash. Aymeric suggests printing the double hash on the product and providing the original hash to the buyer.Unlike Ethereum-based NFT tokens, the proposed system does not rely on third-party platforms or oracles, making it less costly. Transactions would depend on the number of inputs, but an estimated cost is below $1 USD per transaction.While the system requires buyers and sellers to know each other, anonymous means such as Signal, Protonmail, Telegram, or Tor can be utilized. Aymeric recommends creating a new email address and using PGP keys for added anonymity.The proposal argues against the creation of a super sidechain and instead suggests implementing a local Bitcoin system with limited scope. This localized system could be used in specific areas, such as cruise boats or planes, and could be seen as a form of barter money with a stable value.It is worth noting that the proposed system is not open-source, but the author offers its availability upon contacting them directly. The funding source for this proposal remains undisclosed.In conclusion, Aymeric Vitte expresses dissatisfaction with the current design and use of NFTs, particularly on Ethereum. He proposes a decentralized, secure, and cost-effective Bitcoin NFT system as an alternative. While the provided link to the proposal is inaccessible, the email exchange provides insights into how the system would work and its potential benefits. Aymeric includes links to their LinkedIn, GitHub account, and various cryptocurrency-related projects, showcasing their expertise in the field. 2023-01-05T10:46:59+00:00 + Aymeric Vitte and Vincenzo engaged in an email exchange discussing their views on the current state of NFTs. Aymeric expressed dissatisfaction with the centralized, insecure, duplicable, virtual, stealable, unsigned, and expensive nature of NFTs. However, he acknowledged that if NFTs were expanded to include anything that can be bought or stored in the real world, web, or metaverse, they would become more interesting.Aymeric pointed out that Ethereum is the primary platform for NFTs, but described the situation as a "mess." He shared a link to his proposal for a decentralized, secure, and cost-effective Bitcoin NFT system. Unfortunately, the provided link to the proposal appears to be inaccessible.The proposed Bitcoin NFT system aims to avoid the shortcomings of the current NFT ecosystem. It suggests using SHA-256 for a simple reference to the NFT hash. Aymeric explains various aspects of the system, including minting NFTs on Bitcoin, minting multiple NFTs in a single transaction, preventing double minting, transferring NFTs for free, buying and selling NFTs, and using Chainpoint for purchasing NFTs.To ensure security and combat counterfeits, the proposed system involves using a double hash in transactions. This approach allows the buyer and seller to verify the authenticity of the NFT by comparing the original hash. Aymeric suggests printing the double hash on the product and providing the original hash to the buyer.Unlike Ethereum-based NFT tokens, the proposed system does not rely on third-party platforms or oracles, making it less costly. Transactions would depend on the number of inputs, but an estimated cost is below $1 USD per transaction.While the system requires buyers and sellers to know each other, anonymous means such as Signal, Protonmail, Telegram, or Tor can be utilized. Aymeric recommends creating a new email address and using PGP keys for added anonymity.The proposal argues against the creation of a super sidechain and instead suggests implementing a local Bitcoin system with limited scope. This localized system could be used in specific areas, such as cruise boats or planes, and could be seen as a form of barter money with a stable value.It is worth noting that the proposed system is not open-source, but the author offers its availability upon contacting them directly. The funding source for this proposal remains undisclosed.In conclusion, Aymeric Vitte expresses dissatisfaction with the current design and use of NFTs, particularly on Ethereum. He proposes a decentralized, secure, and cost-effective Bitcoin NFT system as an alternative. While the provided link to the proposal is inaccessible, the email exchange provides insights into how the system would work and its potential benefits. Aymeric includes links to their LinkedIn, GitHub account, and various cryptocurrency-related projects, showcasing their expertise in the field. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_A-Universal-Coin-Swap-system-based-on-bitcoin-and-a-Bitcoin-NFT-system.xml b/static/bitcoin-dev/Jan_2023/combined_A-Universal-Coin-Swap-system-based-on-bitcoin-and-a-Bitcoin-NFT-system.xml index f24dbd52c3..394821797e 100644 --- a/static/bitcoin-dev/Jan_2023/combined_A-Universal-Coin-Swap-system-based-on-bitcoin-and-a-Bitcoin-NFT-system.xml +++ b/static/bitcoin-dev/Jan_2023/combined_A-Universal-Coin-Swap-system-based-on-bitcoin-and-a-Bitcoin-NFT-system.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - A Universal Coin Swap system based on bitcoin and a Bitcoin NFT system - 2023-08-02T08:50:26.366123+00:00 - - Aymeric Vitte 2023-01-31 18:36:28+00:00 - - - Aymeric Vitte 2023-01-26 20:15:38+00:00 - + 2025-09-26T14:32:12.053699+00:00 + python-feedgen + + + [bitcoin-dev] A Universal Coin Swap system based on bitcoin and a Bitcoin NFT system Aymeric Vitte + 2023-01-26T20:15:00.000Z + + + Aymeric Vitte + 2023-01-31T18:36:00.000Z + + - python-feedgen + 2 Combined summary - A Universal Coin Swap system based on bitcoin and a Bitcoin NFT system - 2023-08-02T08:50:26.366123+00:00 + 2025-09-26T14:32:12.054195+00:00 - Aymeric Vitte, a French programmer, has put forward two innovative systems based on the Bitcoin blockchain. The first proposal is a Bitcoin NFT system that aims to provide a straightforward and efficient method for buying and selling NFTs while establishing ownership through blockchain verification. This system emphasizes the simplicity of Bitcoin compared to Ethereum, highlighting its ability to handle NFT transactions without unnecessary complexity.Unlike other solutions, Aymeric's NFT system stores proof of deals in OP_RETURN, allowing for the creation of bitcoin contracts. This approach ensures decentralization and prevents the network from becoming overwhelmed with excessive data. By utilizing a reputation model, trust in this system is established through one-time deals rather than relying on long-term relationships between parties.The second proposal introduced by Aymeric is the Universal Coin Swap system. This system aims to create a secure, decentralized, and cost-effective solution that can be applied to all blockchains and tokens based on Bitcoin. Unlike the Lightning network, which enforces strict rules, this system suggests relying on reputation models. Trust is built through one-time transactions, ensuring simplicity and ease of use.Aymeric believes that his proposals contain unique ideas such as the double hash and third-party involvement. These ideas enhance the potential of the systems and facilitate the sale of secret NFTs. Importantly, these proposals maintain decentralization, setting them apart from existing tools and wallets in the market.Aymeric welcomes feedback and reviews on his proposals, providing links to his CV, LinkedIn profile, GitHub, wallet, and other projects he has worked on. He argues that Bitcoin surpasses other systems in various aspects, positioning it as the superior choice for implementing these innovative solutions. 2023-01-31T18:36:28+00:00 + Aymeric Vitte, a French programmer, has put forward two innovative systems based on the Bitcoin blockchain. The first proposal is a Bitcoin NFT system that aims to provide a straightforward and efficient method for buying and selling NFTs while establishing ownership through blockchain verification. This system emphasizes the simplicity of Bitcoin compared to Ethereum, highlighting its ability to handle NFT transactions without unnecessary complexity.Unlike other solutions, Aymeric's NFT system stores proof of deals in OP_RETURN, allowing for the creation of bitcoin contracts. This approach ensures decentralization and prevents the network from becoming overwhelmed with excessive data. By utilizing a reputation model, trust in this system is established through one-time deals rather than relying on long-term relationships between parties.The second proposal introduced by Aymeric is the Universal Coin Swap system. This system aims to create a secure, decentralized, and cost-effective solution that can be applied to all blockchains and tokens based on Bitcoin. Unlike the Lightning network, which enforces strict rules, this system suggests relying on reputation models. Trust is built through one-time transactions, ensuring simplicity and ease of use.Aymeric believes that his proposals contain unique ideas such as the double hash and third-party involvement. These ideas enhance the potential of the systems and facilitate the sale of secret NFTs. Importantly, these proposals maintain decentralization, setting them apart from existing tools and wallets in the market.Aymeric welcomes feedback and reviews on his proposals, providing links to his CV, LinkedIn profile, GitHub, wallet, and other projects he has worked on. He argues that Bitcoin surpasses other systems in various aspects, positioning it as the superior choice for implementing these innovative solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml b/static/bitcoin-dev/Jan_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml index ff89402056..09664f50e2 100644 --- a/static/bitcoin-dev/Jan_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml +++ b/static/bitcoin-dev/Jan_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - A new Bitcoin implementation integrated with Core Lightning - 2023-08-02T08:48:39.136155+00:00 - - Matt Corallo 2023-05-06 05:58:55+00:00 - - - Vincenzo Palazzo 2023-04-30 15:22:01+00:00 - - - niftynei 2023-04-24 16:06:59+00:00 - - - Michael Folkson 2023-04-19 10:54:10+00:00 - - - Kostas Karasavvas 2023-04-19 09:05:10+00:00 - - - Michael Folkson 2023-04-18 17:06:14+00:00 - - - Michael Folkson 2023-01-16 15:45:36+00:00 - - - alicexbt 2023-01-15 13:04:05+00:00 - - - Michael Folkson 2023-01-14 20:45:38+00:00 - - - Fabian 2023-01-14 20:34:38+00:00 - - - Michael Folkson 2023-01-14 20:26:07+00:00 - + 2025-09-26T14:32:09.940416+00:00 + python-feedgen + + + [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning Michael Folkson + 2023-01-14T20:26:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Fabian + 2023-01-14T20:34:00.000Z + + + Michael Folkson + 2023-01-14T20:45:00.000Z + + + [bitcoin-dev] " alicexbt + 2023-01-15T13:04:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Michael Folkson + 2023-01-16T15:45:00.000Z + + + [bitcoin-dev] " Michael Folkson + 2023-04-18T17:06:00.000Z + + + Kostas Karasavvas + 2023-04-19T09:05:00.000Z + + + Michael Folkson + 2023-04-19T10:54:00.000Z + + + [bitcoin-dev] [Lightning-dev] " niftynei + 2023-04-24T16:06:00.000Z + + + Vincenzo Palazzo + 2023-04-30T15:22:00.000Z + + + Matt Corallo + 2023-05-06T05:58:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - A new Bitcoin implementation integrated with Core Lightning - 2023-08-02T08:48:39.136155+00:00 + 2025-09-26T14:32:09.941616+00:00 - Decisions within the Bitcoin community have been criticized for happening in a closed-off manner, with discussions taking place behind closed doors or in private IRC channels. Michael, however, believes that a more open and collaborative approach is needed. He suggests integrating a bare bones Knots style Bitcoin implementation with Core Lightning to create a simpler and more efficient solution. This would avoid the need to re-implement consensus code in a different language, which many developers see as a better option. However, there are concerns about the potential complexity and effort required for such integration.The email thread also addresses the decoupling of CLN from the block source, allowing for a separation of concerns and flexibility in choosing a block backend. The idea of "comingle"ing the peering of LN gossip and block data networks is raised, but it has not been seriously pursued in the LN side. Additionally, there is a discussion about fee calculation and the need for a unified approach to ensure proper functioning of Lightning nodes.Overall, the email thread sheds light on ongoing discussions and ideas for improving the scalability and functionality of the Bitcoin network. It highlights the challenges and opportunities in integrating full nodes and Lightning nodes, managing the Bitcoin Core project, and enhancing the overall ecosystem.The libbitcoinkernel project aimed to extract the consensus engine from Core, but it has proven difficult due to the elusive nature of consensus itself. As a result, the model of Knots style consensus compatible codebase forks of Bitcoin Core seems to be gaining traction. However, merging Bitcoin Core and Core Lightning into one codebase would be a monumental task, according to Michael. He is seeking input from individuals well-versed in both codebases to explore ambitious long-term projects that could potentially combine these two entities.Despite the perceived lull in the chaos surrounding soft fork activation, the Bitcoin community sees this as an opportune time to delve into ambitious endeavors, even if they are purely conceptual at this stage. By focusing on such projects, the community hopes to foster innovation and progress within the ecosystem. 2023-05-06T05:58:55+00:00 + Decisions within the Bitcoin community have been criticized for happening in a closed-off manner, with discussions taking place behind closed doors or in private IRC channels. Michael, however, believes that a more open and collaborative approach is needed. He suggests integrating a bare bones Knots style Bitcoin implementation with Core Lightning to create a simpler and more efficient solution. This would avoid the need to re-implement consensus code in a different language, which many developers see as a better option. However, there are concerns about the potential complexity and effort required for such integration.The email thread also addresses the decoupling of CLN from the block source, allowing for a separation of concerns and flexibility in choosing a block backend. The idea of "comingle"ing the peering of LN gossip and block data networks is raised, but it has not been seriously pursued in the LN side. Additionally, there is a discussion about fee calculation and the need for a unified approach to ensure proper functioning of Lightning nodes.Overall, the email thread sheds light on ongoing discussions and ideas for improving the scalability and functionality of the Bitcoin network. It highlights the challenges and opportunities in integrating full nodes and Lightning nodes, managing the Bitcoin Core project, and enhancing the overall ecosystem.The libbitcoinkernel project aimed to extract the consensus engine from Core, but it has proven difficult due to the elusive nature of consensus itself. As a result, the model of Knots style consensus compatible codebase forks of Bitcoin Core seems to be gaining traction. However, merging Bitcoin Core and Core Lightning into one codebase would be a monumental task, according to Michael. He is seeking input from individuals well-versed in both codebases to explore ambitious long-term projects that could potentially combine these two entities.Despite the perceived lull in the chaos surrounding soft fork activation, the Bitcoin community sees this as an opportune time to delve into ambitious endeavors, even if they are purely conceptual at this stage. By focusing on such projects, the community hopes to foster innovation and progress within the ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml b/static/bitcoin-dev/Jan_2023/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml index e409c799a8..e6935fcd2b 100644 --- a/static/bitcoin-dev/Jan_2023/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml +++ b/static/bitcoin-dev/Jan_2023/combined_A-proposal-for-Full-RBF-to-not-exclude-Zero-Conf-use-case.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - A proposal for Full RBF to not exclude Zero Conf use case - 2023-08-02T08:37:12.928040+00:00 - - Daniel Lipshitz 2023-02-06 12:08:40+00:00 - - - Peter Todd 2023-02-04 16:27:47+00:00 - - - Daniel Lipshitz 2023-01-17 17:27:13+00:00 - - - Erik Aronesty 2023-01-17 17:07:54+00:00 - - - Daniel Lipshitz 2023-01-16 10:19:35+00:00 - - - Daniel Lipshitz 2023-01-14 20:15:30+00:00 - - - Peter Todd 2023-01-13 23:53:45+00:00 - - - Daniel Lipshitz 2022-12-18 08:06:15+00:00 - - - Peter Todd 2022-12-16 21:14:33+00:00 - - - Erik Aronesty 2022-12-14 17:41:17+00:00 - - - Daniel Lipshitz 2022-12-14 08:12:30+00:00 - - - Daniel Lipshitz 2022-12-13 21:58:31+00:00 - - - Peter Todd 2022-12-13 21:41:44+00:00 - - - Daniel Lipshitz 2022-12-13 14:08:10+00:00 - - - Lucas Ontivero 2022-12-13 14:00:26+00:00 - - - Daniel Lipshitz 2022-12-13 11:33:00+00:00 - - - John Carvalho 2022-12-13 09:59:36+00:00 - - - Daniel Lipshitz 2022-12-13 08:08:59+00:00 - - - Yuval Kogman 2022-12-13 04:20:22+00:00 - - - Daniel Lipshitz 2022-12-11 20:24:00+00:00 - + 2025-09-26T14:32:18.466959+00:00 + python-feedgen + + + [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case Daniel Lipshitz + 2022-12-11T20:24:00.000Z + + + Yuval Kogman + 2022-12-13T04:20:00.000Z + + + Daniel Lipshitz + 2022-12-13T08:08:00.000Z + + + John Carvalho + 2022-12-13T09:59:00.000Z + + + Daniel Lipshitz + 2022-12-13T11:33:00.000Z + + + Lucas Ontivero + 2022-12-13T14:00:00.000Z + + + Daniel Lipshitz + 2022-12-13T14:08:00.000Z + + + Peter Todd + 2022-12-13T21:41:00.000Z + + + Daniel Lipshitz + 2022-12-13T21:58:00.000Z + + + Daniel Lipshitz + 2022-12-14T08:12:00.000Z + + + Erik Aronesty + 2022-12-14T17:41:00.000Z + + + Peter Todd + 2022-12-16T21:14:00.000Z + + + Daniel Lipshitz + 2022-12-18T08:06:00.000Z + + + Peter Todd + 2023-01-13T23:53:00.000Z + + + Daniel Lipshitz + 2023-01-14T20:15:00.000Z + + + Daniel Lipshitz + 2023-01-16T10:19:00.000Z + + + Erik Aronesty + 2023-01-17T17:07:00.000Z + + + Daniel Lipshitz + 2023-01-17T17:27:00.000Z + + + Peter Todd + 2023-02-04T16:27:00.000Z + + + Daniel Lipshitz + 2023-02-06T12:08:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - A proposal for Full RBF to not exclude Zero Conf use case - 2023-08-02T08:37:12.928040+00:00 + 2025-09-26T14:32:18.469025+00:00 - In an email exchange between Peter Todd and Daniel Lipshitz, it was revealed that GAP600, a service provider, does not have access to KYC/AML information or telephone numbers of its clients who use bitcoin for deposit. They only receive public bitcoin information such as transaction hash and output address shared via API.Lipshitz explained that their company services merchants, payment processors, and non-custodial liquidity providers by enabling them to accept 0-conf transactions. He also provided figures on the queried unique Bitcoin addresses and USD value for November and December 2022.There is ongoing debate about the need for full RBF (replace-by-fee), with Todd arguing that implementing full RBF would stop the collection of data on real-world entities paying for GAP600's service. However, Lipshitz maintained that their service is purely an analysis of the Bitcoin network and does not involve AML/KYC.Todd suggested adding a swap limitation to mitigate risks, but this was challenged as it would negate the use case of multi-party transactions. Lipshitz emphasized that 0-conf on Bitcoin is a significant use case that should not be ignored.GAP600 did not provide specific names of companies using their service but referred to Max CEO from Coinspaid, who may share further information on the merchants they support. The email exchange also discussed the centralization of transaction processing and the privacy concerns associated with collecting client data.In a discussion on the bitcoin-dev mailing list, Daniel Lipshitz suggested the use of first-seen-safe replace-by-fee (FSS-RBF) as an alternative to full replace-by-fee (FullRBF). This would retain the significant 0-conf use case while balancing the associated risks. John Carvalho expressed concerns about the side-effects of FullRBF and supported the discussion of the FSS-RBF feature.Peter Todd explained in an email exchange with Daniel Lipshitz the issues with his first-seen-safe proposal. He noted that it was only proposed as a political compromise and that full-RBF behavior is necessary for multi-party transactions such as coinjoins and multi-party lightning channels. Todd suggested Antoine Riard's spent-nVersion signaling proposal as a possible compromise option, but it has negative privacy implications. He advised service providers to either adopt scalable instant payment tech like Lightning or expand their business with other chains like BSV.Some wallets, including Electrum, may be affected by FullRBF as they use RBF to batch transactions. Daniel Lipshitz suggested that FSS-RBF could be a suitable option to balance FullRBF and retain the 0-conf use case. John Carvalho also supported the discussion of FSS-RBF.In a separate email exchange, Lipshitz responded to Carvalho's query about why FSS-RBF wasn't implemented earlier and whether there were design problems. Lipshitz acknowledged the suitability of FSS-RBF and found no technical issues with its implementation. He pointed out that the reasons against adopting Full-RBF listed on the Bitcoin Core website do not apply in this case since OptinRBF already exists as an option and FSS-RBF offers additional benefits.The speaker expressed their approval of Peter Todd's suggestion to use the "first-seen-safe replace-by-fee" method, which would balance FullRBF while retaining the use cases for zero-conf transactions. They believe this could be a good way forward.It is understood that the current use case of 0-Conf acceptance of transactions is significant, and merchants are aware of the associated risks. However, full RBF adoption would likely make 0-conf not possible and limit this use case. To address this, the primary use case of full RBF (increasing fees) can be enabled while keeping the outputs of TRX1 to be included within TRX2. This would require the addition of at least one input to increase the fee. OptinRBF and FullRBF (with this limitation) would give actors the option to increase fees while still allowing the 0-conf use case. The risks associated with 0-conf are well understood, and it can continue to exist with the ongoing choices available to actors. 2023-02-06T12:08:40+00:00 + In an email exchange between Peter Todd and Daniel Lipshitz, it was revealed that GAP600, a service provider, does not have access to KYC/AML information or telephone numbers of its clients who use bitcoin for deposit. They only receive public bitcoin information such as transaction hash and output address shared via API.Lipshitz explained that their company services merchants, payment processors, and non-custodial liquidity providers by enabling them to accept 0-conf transactions. He also provided figures on the queried unique Bitcoin addresses and USD value for November and December 2022.There is ongoing debate about the need for full RBF (replace-by-fee), with Todd arguing that implementing full RBF would stop the collection of data on real-world entities paying for GAP600's service. However, Lipshitz maintained that their service is purely an analysis of the Bitcoin network and does not involve AML/KYC.Todd suggested adding a swap limitation to mitigate risks, but this was challenged as it would negate the use case of multi-party transactions. Lipshitz emphasized that 0-conf on Bitcoin is a significant use case that should not be ignored.GAP600 did not provide specific names of companies using their service but referred to Max CEO from Coinspaid, who may share further information on the merchants they support. The email exchange also discussed the centralization of transaction processing and the privacy concerns associated with collecting client data.In a discussion on the bitcoin-dev mailing list, Daniel Lipshitz suggested the use of first-seen-safe replace-by-fee (FSS-RBF) as an alternative to full replace-by-fee (FullRBF). This would retain the significant 0-conf use case while balancing the associated risks. John Carvalho expressed concerns about the side-effects of FullRBF and supported the discussion of the FSS-RBF feature.Peter Todd explained in an email exchange with Daniel Lipshitz the issues with his first-seen-safe proposal. He noted that it was only proposed as a political compromise and that full-RBF behavior is necessary for multi-party transactions such as coinjoins and multi-party lightning channels. Todd suggested Antoine Riard's spent-nVersion signaling proposal as a possible compromise option, but it has negative privacy implications. He advised service providers to either adopt scalable instant payment tech like Lightning or expand their business with other chains like BSV.Some wallets, including Electrum, may be affected by FullRBF as they use RBF to batch transactions. Daniel Lipshitz suggested that FSS-RBF could be a suitable option to balance FullRBF and retain the 0-conf use case. John Carvalho also supported the discussion of FSS-RBF.In a separate email exchange, Lipshitz responded to Carvalho's query about why FSS-RBF wasn't implemented earlier and whether there were design problems. Lipshitz acknowledged the suitability of FSS-RBF and found no technical issues with its implementation. He pointed out that the reasons against adopting Full-RBF listed on the Bitcoin Core website do not apply in this case since OptinRBF already exists as an option and FSS-RBF offers additional benefits.The speaker expressed their approval of Peter Todd's suggestion to use the "first-seen-safe replace-by-fee" method, which would balance FullRBF while retaining the use cases for zero-conf transactions. They believe this could be a good way forward.It is understood that the current use case of 0-Conf acceptance of transactions is significant, and merchants are aware of the associated risks. However, full RBF adoption would likely make 0-conf not possible and limit this use case. To address this, the primary use case of full RBF (increasing fees) can be enabled while keeping the outputs of TRX1 to be included within TRX2. This would require the addition of at least one input to increase the fee. OptinRBF and FullRBF (with this limitation) would give actors the option to increase fees while still allowing the 0-conf use case. The risks associated with 0-conf are well understood, and it can continue to exist with the ongoing choices available to actors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Bitcoin-Contracting-Primitives-WG-3rd-Meeting-Tuesday-17-Jan-18-00-UTC.xml b/static/bitcoin-dev/Jan_2023/combined_Bitcoin-Contracting-Primitives-WG-3rd-Meeting-Tuesday-17-Jan-18-00-UTC.xml index 0c3983980a..55a01fe693 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Bitcoin-Contracting-Primitives-WG-3rd-Meeting-Tuesday-17-Jan-18-00-UTC.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Bitcoin-Contracting-Primitives-WG-3rd-Meeting-Tuesday-17-Jan-18-00-UTC.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Bitcoin Contracting Primitives WG 3rd Meeting, Tuesday 17 Jan. 18:00 UTC - 2023-08-02T08:45:11.151326+00:00 - - Antoine Riard 2023-01-17 01:50:05+00:00 - - - Antoine Riard 2023-01-06 00:26:03+00:00 - + 2025-09-26T14:31:50.756832+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Contracting Primitives WG 3rd Meeting, Tuesday 17 Jan. 18:00 UTC Antoine Riard + 2023-01-06T00:26:00.000Z + + + Antoine Riard + 2023-01-17T01:50:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Contracting Primitives WG 3rd Meeting, Tuesday 17 Jan. 18:00 UTC - 2023-08-02T08:45:11.151326+00:00 + 2025-09-26T14:31:50.757319+00:00 - The 3rd Bitcoin Contracting Primitives Working Group (WG) meeting has been scheduled for Tuesday, January 17th at 18:00 UTC. Antoine Riard, the group leader, has proposed this date and time. The agenda for the meeting includes a thorough discussion of all contracting protocol use-cases and a review of the research in the contracting primitives/covenant spaces. Participants are encouraged to open a PR or contact Antoine if they have been working on a use-case that is missing from the current listing.The second part of the meeting will be dedicated to addressing any blockers that participants have encountered in their contracting primitives/covenant research. This will provide an opportunity for individuals to discuss any challenges or obstacles they have faced during their research.Antoine also shared his personal goal for the year, which is to nurture websites with archive material gathered in the repository. These websites would present the contracting protocol research according to the best engineering/scientific standards and ensure idea neutrality. Additionally, Antoine intends to collect feedback, particularly on dimensions like privacy or economic scaling, from the Bitcoin community of stakeholders at large, using Pretty Graphics (tm).In an effort to promote decentralization within the group, there are plans to start rotating the host of the monthly meetings during the year, similar to how it is done with BOLTs among Lightning implementations contributors. Anyone interested in hosting one of the monthly meetings is encouraged to open an issue against the repository or contact Antoine.For communication, the group uses the #bitcoin-contracting-primitives-wg channel on Libera Chat. Logs of previous sessions can be found at [0]. If anyone has questions or feedback, they are welcome to reach out to Antoine, the group leader. 2023-01-17T01:50:05+00:00 + The 3rd Bitcoin Contracting Primitives Working Group (WG) meeting has been scheduled for Tuesday, January 17th at 18:00 UTC. Antoine Riard, the group leader, has proposed this date and time. The agenda for the meeting includes a thorough discussion of all contracting protocol use-cases and a review of the research in the contracting primitives/covenant spaces. Participants are encouraged to open a PR or contact Antoine if they have been working on a use-case that is missing from the current listing.The second part of the meeting will be dedicated to addressing any blockers that participants have encountered in their contracting primitives/covenant research. This will provide an opportunity for individuals to discuss any challenges or obstacles they have faced during their research.Antoine also shared his personal goal for the year, which is to nurture websites with archive material gathered in the repository. These websites would present the contracting protocol research according to the best engineering/scientific standards and ensure idea neutrality. Additionally, Antoine intends to collect feedback, particularly on dimensions like privacy or economic scaling, from the Bitcoin community of stakeholders at large, using Pretty Graphics (tm).In an effort to promote decentralization within the group, there are plans to start rotating the host of the monthly meetings during the year, similar to how it is done with BOLTs among Lightning implementations contributors. Anyone interested in hosting one of the monthly meetings is encouraged to open an issue against the repository or contact Antoine.For communication, the group uses the #bitcoin-contracting-primitives-wg channel on Libera Chat. Logs of previous sessions can be found at [0]. If anyone has questions or feedback, they are welcome to reach out to Antoine, the group leader. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Jan_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 6c25093aa9..8cb796f4d1 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:32:01.400338+00:00 + python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:32:01.400541+00:00 - On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to 2023-03-13T16:38:25+00:00 + On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_OP-VAULT-a-new-vault-proposal.xml b/static/bitcoin-dev/Jan_2023/combined_OP-VAULT-a-new-vault-proposal.xml index b71008cb12..ca3a2a318f 100644 --- a/static/bitcoin-dev/Jan_2023/combined_OP-VAULT-a-new-vault-proposal.xml +++ b/static/bitcoin-dev/Jan_2023/combined_OP-VAULT-a-new-vault-proposal.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - OP_VAULT: a new vault proposal - 2023-08-02T08:46:51.905810+00:00 - - James O'Beirne 2023-01-20 17:43:14+00:00 - - - Billy Tetrud 2023-01-19 22:49:30+00:00 - - - James O'Beirne 2023-01-18 23:37:51+00:00 - - - James O'Beirne 2023-01-18 22:45:01+00:00 - - - Billy Tetrud 2023-01-18 19:00:29+00:00 - - - Anthony Towns 2023-01-17 07:46:38+00:00 - - - Andrew Chow 2023-01-16 23:47:09+00:00 - - - Anthony Towns 2023-01-11 06:52:28+00:00 - - - James O'Beirne 2023-01-10 20:22:54+00:00 - - - James O'Beirne 2023-01-10 14:17:49+00:00 - - - James O'Beirne 2023-01-10 13:35:04+00:00 - - - Anthony Towns 2023-01-10 12:29:52+00:00 - - - James O'Beirne 2023-01-09 20:32:34+00:00 - - - Greg Sanders 2023-01-09 19:31:51+00:00 - - - rot13maxi 2023-01-09 19:02:26+00:00 - - - James O'Beirne 2023-01-09 16:07:54+00:00 - + 2025-09-26T14:32:07.824981+00:00 + python-feedgen + + + [bitcoin-dev] OP_VAULT: a new vault proposal James O'Beirne + 2023-01-09T16:07:00.000Z + + + rot13maxi + 2023-01-09T19:02:00.000Z + + + Greg Sanders + 2023-01-09T19:31:00.000Z + + + James O'Beirne + 2023-01-09T20:32:00.000Z + + + Anthony Towns + 2023-01-10T12:29:00.000Z + + + James O'Beirne + 2023-01-10T13:35:00.000Z + + + James O'Beirne + 2023-01-10T14:17:00.000Z + + + James O'Beirne + 2023-01-10T20:22:00.000Z + + + Anthony Towns + 2023-01-11T06:52:00.000Z + + + Andrew Chow + 2023-01-16T23:47:00.000Z + + + Anthony Towns + 2023-01-17T07:46:00.000Z + + + Billy Tetrud + 2023-01-18T19:00:00.000Z + + + James O'Beirne + 2023-01-18T22:45:00.000Z + + + James O'Beirne + 2023-01-18T23:37:00.000Z + + + Billy Tetrud + 2023-01-19T22:49:00.000Z + + + James O'Beirne + 2023-01-20T17:43:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - OP_VAULT: a new vault proposal - 2023-08-02T08:46:51.905810+00:00 + 2025-09-26T14:32:07.826976+00:00 - The proposal being discussed is centered around the implementation of efficient wallet vaults. It suggests encouraging address reuse for vaults and ensuring unique addresses through key derivation. The proposal allows privacy-conscious users to trade batched operations for no privacy loss, while commercial users may reveal the related nature of coins being unvaulted or recovered. To maintain the privacy of still-vaulted coins, users can vary the internal key used for OP_VAULT taptrees or utilize the optional "authorized recovery" feature by varying the sPK with a ranged descriptor. Recovery sweeps only occur in catastrophic cases, and most users are willing to sacrifice some privacy for the ownership of their coins. However, it is uncertain whether this change is more fundamental, but it is relatively easy to implement.The proposal suggests limiting the usage of OP_VAULT and OP_UNVAULT to tapscripts instead of bare and P2WSH outputs in order to simplify implementation. It also discusses the possibility of storing a recovery address with every key to the vault and gating the recovery path with an arbitrary scriptPubKey. However, adding this feature may introduce complexity to downstream code that needs to handle special cases.There is an ongoing discussion about the verification process of a node for the destination of a spend using an OP_VAULT output and its corresponding OP_UNVAULT script. The proposal provides the option to store a recovery address with each key, but the recovery path can be gated by an arbitrary scriptPubKey. The proposal aims to meet all criteria for efficient wallet vaults and allows batching as well.There have been suggestions from Greg Sanders and AJ Towns to improve the proposal. These suggestions include allowing OP_UNVAULT outputs to live behind scripthashes, introducing an extra "revault" output in unvault trigger transactions, and implementing a replacement parameter for the recovery script. These changes aim to enhance efficiency, flexibility, and security in the proposed vault design.Another topic of discussion is the verification process of a node to ensure that the destination of an OP_VAULT output uses the appropriate OP_UNVAULT script. There are concerns about compatibility with SIGHASH_GROUP and the use of the OP_BEFOREBLOCKVERIFY opcode, which may affect the reorgability of transactions. The proposal includes a static intermediate address that does not have any unique values for a particular vault, allowing for dynamic unvaulting using OP_PUSHOUTPUTSTACK.The author has implemented three changes based on suggestions from Greg Sanders and AJ Towns. These changes include allowing OP_UNVAULT outputs to live behind scripthashes, introducing an extra "revault" output, and implementing a replacement parameter for the recovery script. The author believes these suggestions have improved the proposal and plans to make minor updates to the paper and write a BIP draft soon.A proposal for a targeted wallet vault opcode has been suggested to limit objections and complexity. It aims to provide efficient vault storage and allow batching in a single transaction. However, there are concerns about the verification of the destination of an OP_VAULT output and the security of the recovery path. The proposal suggests storing a recovery address with every key to minimize the risk of lost or stolen funds. The idea of making the recovery-path authorization behavior variable has also been proposed for flexibility.In a discussion on the bitcoin-dev mailing list, Andrew Chow raises concerns about a proposal that encourages address reuse for vaults. He suggests ensuring unique addresses through key derivation and limiting the usage of OP_VAULT and OP_UNVAULT to tapscripts to simplify implementation. James O'Beirne has implemented a vault design called OP_VAULT and seeks feedback on its viability. The discussion covers various aspects of the design, including privacy, batched operations, and the verification process. Suggestions for improvements have been made, and a BIP draft may be written.The conversation between James O'Beirne and Andrew Poelstra focuses on the design of OP_VAULT, a new opcode for Bitcoin script. They discuss the size and complexity of the witness script, the use of recovery-path construction, and the potential for batching inputs and outputs. The benefits of using taproot to hide the vault operations are highlighted, and suggestions for improvements are made.In a discussion about Bitcoin vaults, questions arise about the recovery path and its security measures. Various proposals, including the use of signatures and OP_NOP repurposing, are discussed. The possibility of using CTV and template malleability is considered but deemed inappropriate for vaults. The benefits of batching withdrawals and the inability to batch unvaults in Revault are also debated.The author has received a suggestion from Greg about improving the "output flow" of a vault use. The current draft implementation allows all outputs except the OP_UNVAULT trigger to hide their true script until spend. However, there is ongoing discussion about potentially rearranging the commit structure. The author believes that tangible code artifacts are crucial in testing these proposals.A proposal for a new Bitcoin vault 2023-01-20T17:43:14+00:00 + The proposal being discussed is centered around the implementation of efficient wallet vaults. It suggests encouraging address reuse for vaults and ensuring unique addresses through key derivation. The proposal allows privacy-conscious users to trade batched operations for no privacy loss, while commercial users may reveal the related nature of coins being unvaulted or recovered. To maintain the privacy of still-vaulted coins, users can vary the internal key used for OP_VAULT taptrees or utilize the optional "authorized recovery" feature by varying the sPK with a ranged descriptor. Recovery sweeps only occur in catastrophic cases, and most users are willing to sacrifice some privacy for the ownership of their coins. However, it is uncertain whether this change is more fundamental, but it is relatively easy to implement.The proposal suggests limiting the usage of OP_VAULT and OP_UNVAULT to tapscripts instead of bare and P2WSH outputs in order to simplify implementation. It also discusses the possibility of storing a recovery address with every key to the vault and gating the recovery path with an arbitrary scriptPubKey. However, adding this feature may introduce complexity to downstream code that needs to handle special cases.There is an ongoing discussion about the verification process of a node for the destination of a spend using an OP_VAULT output and its corresponding OP_UNVAULT script. The proposal provides the option to store a recovery address with each key, but the recovery path can be gated by an arbitrary scriptPubKey. The proposal aims to meet all criteria for efficient wallet vaults and allows batching as well.There have been suggestions from Greg Sanders and AJ Towns to improve the proposal. These suggestions include allowing OP_UNVAULT outputs to live behind scripthashes, introducing an extra "revault" output in unvault trigger transactions, and implementing a replacement parameter for the recovery script. These changes aim to enhance efficiency, flexibility, and security in the proposed vault design.Another topic of discussion is the verification process of a node to ensure that the destination of an OP_VAULT output uses the appropriate OP_UNVAULT script. There are concerns about compatibility with SIGHASH_GROUP and the use of the OP_BEFOREBLOCKVERIFY opcode, which may affect the reorgability of transactions. The proposal includes a static intermediate address that does not have any unique values for a particular vault, allowing for dynamic unvaulting using OP_PUSHOUTPUTSTACK.The author has implemented three changes based on suggestions from Greg Sanders and AJ Towns. These changes include allowing OP_UNVAULT outputs to live behind scripthashes, introducing an extra "revault" output, and implementing a replacement parameter for the recovery script. The author believes these suggestions have improved the proposal and plans to make minor updates to the paper and write a BIP draft soon.A proposal for a targeted wallet vault opcode has been suggested to limit objections and complexity. It aims to provide efficient vault storage and allow batching in a single transaction. However, there are concerns about the verification of the destination of an OP_VAULT output and the security of the recovery path. The proposal suggests storing a recovery address with every key to minimize the risk of lost or stolen funds. The idea of making the recovery-path authorization behavior variable has also been proposed for flexibility.In a discussion on the bitcoin-dev mailing list, Andrew Chow raises concerns about a proposal that encourages address reuse for vaults. He suggests ensuring unique addresses through key derivation and limiting the usage of OP_VAULT and OP_UNVAULT to tapscripts to simplify implementation. James O'Beirne has implemented a vault design called OP_VAULT and seeks feedback on its viability. The discussion covers various aspects of the design, including privacy, batched operations, and the verification process. Suggestions for improvements have been made, and a BIP draft may be written.The conversation between James O'Beirne and Andrew Poelstra focuses on the design of OP_VAULT, a new opcode for Bitcoin script. They discuss the size and complexity of the witness script, the use of recovery-path construction, and the potential for batching inputs and outputs. The benefits of using taproot to hide the vault operations are highlighted, and suggestions for improvements are made.In a discussion about Bitcoin vaults, questions arise about the recovery path and its security measures. Various proposals, including the use of signatures and OP_NOP repurposing, are discussed. The possibility of using CTV and template malleability is considered but deemed inappropriate for vaults. The benefits of batching withdrawals and the inability to batch unvaults in Revault are also debated.The author has received a suggestion from Greg about improving the "output flow" of a vault use. The current draft implementation allows all outputs except the OP_UNVAULT trigger to hide their true script until spend. However, there is ongoing discussion about potentially rearranging the commit structure. The author believes that tangible code artifacts are crucial in testing these proposals.A proposal for a new Bitcoin vault - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Ordinal-Inscription-Size-Limits.xml b/static/bitcoin-dev/Jan_2023/combined_Ordinal-Inscription-Size-Limits.xml index b2e4dc1910..fb85cca700 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Ordinal-Inscription-Size-Limits.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Ordinal-Inscription-Size-Limits.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Ordinal Inscription Size Limits - 2024-01-04T02:00:07.522616+00:00 - - Erik Aronesty 2024-01-03 13:05:42+00:00 - - - Brad Morrison 2024-01-03 09:11:58+00:00 - - - Erik Aronesty 2024-01-01 16:08:29+00:00 - - - Brad Morrison 2024-01-01 13:33:02+00:00 - - - Erik Aronesty 2023-12-30 09:58:41+00:00 - - - Nagaev Boris 2023-12-29 19:01:52+00:00 - - - Greg Tonoski 2023-12-29 12:27:42+00:00 - - - Aymeric Vitte 2023-02-07 12:17:24+00:00 - - - Erik Aronesty 2023-02-06 18:05:05+00:00 - - - Claus Ehrenberg 2023-02-06 17:31:45+00:00 - - - Erik Aronesty 2023-02-06 16:39:14+00:00 - - - Kostas Karasavvas 2023-02-04 14:25:58+00:00 - - - Melvin Carvalho 2023-02-03 19:56:16+00:00 - - - Erik Aronesty 2023-01-31 08:58:46+00:00 - - - Robert Dickinson 2023-01-29 10:34:54+00:00 - - - Aymeric Vitte 2023-01-28 16:47:46+00:00 - - - alicexbt 2023-01-28 10:58:12+00:00 - - - Robert Dickinson 2023-01-28 04:26:15+00:00 - - - Aymeric Vitte 2023-01-27 15:43:46+00:00 - - - Andrew Poelstra 2023-01-27 13:21:00+00:00 - - - rotmaxi 2023-01-27 12:58:49+00:00 - - - Robert Dickinson 2023-01-27 12:44:10+00:00 - + 2025-09-26T14:32:05.662018+00:00 + python-feedgen + + + [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson + 2023-01-27T12:44:00.000Z + + + rot13maxi + 2023-01-27T12:58:00.000Z + + + Andrew Poelstra + 2023-01-27T13:21:00.000Z + + + Aymeric Vitte + 2023-01-27T15:43:00.000Z + + + Robert Dickinson + 2023-01-28T04:26:00.000Z + + + alicexbt + 2023-01-28T10:58:00.000Z + + + Aymeric Vitte + 2023-01-28T16:47:00.000Z + + + Robert Dickinson + 2023-01-29T10:34:00.000Z + + + Erik Aronesty + 2023-01-31T08:58:00.000Z + + + Melvin Carvalho + 2023-02-03T19:56:00.000Z + + + Kostas Karasavvas + 2023-02-04T14:25:00.000Z + + + Erik Aronesty + 2023-02-06T16:39:00.000Z + + + Claus Ehrenberg + 2023-02-06T17:31:00.000Z + + + Erik Aronesty + 2023-02-06T18:05:00.000Z + + + Aymeric Vitte + 2023-02-07T12:17:00.000Z + + + Greg Tonoski + 2023-12-29T12:27:00.000Z + + + Nagaev Boris + 2023-12-29T19:01:00.000Z + + + Erik Aronesty + 2023-12-30T09:58:00.000Z + + + Brad Morrison + 2024-01-01T13:33:00.000Z + + + Erik Aronesty + 2024-01-01T16:08:00.000Z + + + Brad Morrison + 2024-01-03T09:11:00.000Z + + + Erik Aronesty + 2024-01-03T13:05:00.000Z + + @@ -91,29 +116,21 @@ - python-feedgen + 2 Combined summary - Ordinal Inscription Size Limits - 2024-01-04T02:00:07.522763+00:00 + 2025-09-26T14:32:05.664657+00:00 + 2024-01-03T13:05:42+00:00 The Bitcoin programming community is engaged in discussions focusing on blockchain scalability, transaction efficiency, and data storage. Scalability challenges stem not from block size but from the broadcasting and storing of transactions across network nodes. Alternatives like the Lightning Network and covenant technology are being explored to address these issues. - Comparisons with credit card payment systems highlight Bitcoin's higher transaction costs due to fees that control spam but also limit its use for payments. Proposals include increasing block size to lower fees and make Bitcoin more competitive. - Spam prevention via transaction fees is effective yet inconsistent; advanced methods like payment pools and tree payments have been suggested to improve this and can be found at [UTXOs Scaling](https://utxos.org/uses/scaling/). Innovative data storage within transactions using multisig and Taproot’s Merkle proofs is being debated, with suggestions for natural economic deterrents to discourage misuse. - Discussions on witness data storage involve concerns about storing 'toxic data' and proposals to limit data size or alter incentive structures. GitHub references such as [PR 28408](https://github.com/bitcoin/bitcoin/pull/28408) and [Issue 29146](https://github.com/bitcoin/bitcoin/issues/29146) indicate a broader dialogue on control mechanisms against unwanted data, including deprecating certain opcodes. - Storing NFT content as witness data poses risks regarding node storage capacity and disk usage. Suggestions include imposing size limits and alternative methods like extension blocks. Linking sats to real-world deeds is considered, however, storing actual property on the blockchain is seen as impractical. - -Robert Dickinson and Alicexbt contribute their perspectives on storage capacity and blockchain space management. Dickinson recommends premium charges for image storage, whereas Alicexbt advises capacity planning and proposes a "local bitcoin" system to avoid main chain storage congestion. - +Robert Dickinson and Alicexbt contribute their perspectives on storage capacity and blockchain space management. Dickinson recommends premium charges for image storage, whereas Alicexbt advises capacity planning and proposes a "local bitcoin" system to avoid main chain storage congestion. Amidst this technical debate, there is also discussion about the cultural and innovative uses of data storage, such as embedding images during festivals. However, there are calls for responsible usage and education to prevent negative consequences from arbitrary data storage. - Aymeric Vitte presents a vision for integrating Bitcoin into the NFT and 'web3' sphere. He suggests a centralized bitcoin-based NFT system for efficient referencing of low-value NFTs in transactions, contrasting with decentralized approaches. - The debate considers balancing innovation with the practicalities of Bitcoin’s infrastructure. Core developers face the challenge of addressing diverse opinions and the long-term effects of permitting unlimited data storage through witness data and ordinals, aiming to ensure Bitcoin's evolution remains robust and sustainable. - 2024-01-03T13:05:42+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Pseudocode-for-robust-tail-emission.xml b/static/bitcoin-dev/Jan_2023/combined_Pseudocode-for-robust-tail-emission.xml index 920d3c1f83..be4651c1fe 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Pseudocode-for-robust-tail-emission.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Pseudocode-for-robust-tail-emission.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pseudocode for robust tail emission - 2023-08-02T08:42:11.383342+00:00 + 2025-09-26T14:32:16.319577+00:00 + python-feedgen jk_14 at op.pl 2023-02-01 22:04:11+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Pseudocode for robust tail emission - 2023-08-02T08:42:11.384340+00:00 + 2025-09-26T14:32:16.319747+00:00 - In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the 2023-02-01T22:04:11+00:00 + In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Reference-example-bech32m-address-for-future-segwit-versions.xml b/static/bitcoin-dev/Jan_2023/combined_Reference-example-bech32m-address-for-future-segwit-versions.xml index 6eaceedb4a..33419e267a 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Reference-example-bech32m-address-for-future-segwit-versions.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Reference-example-bech32m-address-for-future-segwit-versions.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Reference example bech32m address for future segwit versions - 2023-08-02T08:52:43.448743+00:00 - - Anthony Towns 2023-02-01 01:13:49+00:00 - - - Greg Sanders 2023-02-01 00:37:06+00:00 - - - David A. Harding 2023-01-31 23:33:13+00:00 - - - Greg Sanders 2023-01-31 14:30:34+00:00 - - - David A. Harding 2023-01-31 00:02:51+00:00 - + 2025-09-26T14:31:48.644484+00:00 + python-feedgen + + + [bitcoin-dev] Reference example bech32m address for future segwit versions David A. Harding + 2023-01-31T00:02:00.000Z + + + Greg Sanders + 2023-01-31T14:30:00.000Z + + + David A. Harding + 2023-01-31T23:33:00.000Z + + + Greg Sanders + 2023-02-01T00:37:00.000Z + + + Anthony Towns + 2023-02-01T01:13:00.000Z + + - python-feedgen + 2 Combined summary - Reference example bech32m address for future segwit versions - 2023-08-02T08:52:43.448743+00:00 + 2025-09-26T14:31:48.645156+00:00 - In a recent email exchange on the bitcoin-dev mailing list, David A. Harding raised a question about the best practice for wallets when it comes to spending to the output indicated by any valid bech32m address. The response from aj was that it depends on whether the wallet is custodial or non-custodial. If it's a non-custodial wallet that may not be upgraded by the time witness v2 addresses are in use, then sending to such addresses now makes sense and is worth testing. However, if it's a custodial wallet, then there's a strong argument against allowing sending to such addresses until they're actually in use.The reason for this is two-fold: firstly, nobody will be running old software since the custodian can just force everyone to upgrade. Secondly, signing a transaction to send bitcoins held on behalf of someone else to an address that will get them stolen could be considered negligence, forcing the custodian to make the user whole again. Therefore, there's no point in testing a scenario that's likely years away for custodial wallets.On the other hand, for non-custodial wallets, it's worth testing as they might not be able to find compatible software in the future to move their private keys and have to resort to using the current software. However, in that case, they should be able to capture the transaction it generates before broadcasting it, and don't need to publish it on-chain. It's a different matter for libraries and non-wallet software like block explorers or alternate node implementations.In an email exchange, Greg Sanders predicts that most custodians may be hesitant to whitelist a witness version that they know is insecure. David A. Harding questions whether wallets should only send to outputs they know can be secured or if they should spend to the output indicated by any valid bech32m address. He finds the more restrictive approach to be sad and believes that there is a benefit to testing it when proprietary software is involved. However, he wants the testing to use the address least likely to cause problems for protocol developers in the future.David asks Greg and others on the list if they have any reason to believe that OP_16 OP_PUSH2 0000 would be a problematic script or if they can think of a better one. The email also references BIP350, which recommends ensuring that wallet implementations support sending to v1 and higher versions.In an email conversation between Greg Sanders and David, the topic of sending funds to future segwit versions was discussed. Greg suggested that most exchanges would not enable sends to future segwit versions due to the risk involved in doing so. However, David argued that wallets should spend to any valid bech32m address and that the more restrictive approach of only sending to secured outputs seemed unnecessary. He explained that withdrawing to a witness program for which there is no solution could result in bigger problems. David also suggested that testing the best practice of sending to secured outputs could benefit protocol developers in the future if they need to test other best practices that cannot be easily tested for. However, he wanted to use the address least likely to cause problems for protocol developers in the future. He sought suggestions from others on the list regarding what script to use. The email conversation references BIP350, which recommends supporting sending to v1 and higher versions.In a discussion on the Bitcoin-dev mailing list, David A. Harding proposed having a reserved address space for future segwit versions that are unlikely to interfere with future soft forks but can still exercise wallets supporting bech32m. He suggested using the following addresses: HRP (Human-readable part) "bc" for mainnet and "tb" for testnet, witness version 16 (the last segwit version), and witness program 0x0000. This would help developers of future soft forks deal with existing outputs paid to templates used in the proposed soft fork.Greg, in response, noted that most exchanges will not enable sends to future segwit versions due to the risk perspective of sending funds there. However, updating to new versions should be straightforward as long as the checksum is not changed again and popular open-source libraries support it. Testing this behavior in production can create an annoyance for developers of future soft forks. Therefore, having a canonical example of future segwit addresses that are unlikely to interfere with future soft forks could be useful.A proposal has been made for a canonical example of future segwit addresses that are designed to be very unlikely to interfere with future soft forks but which would still reasonably exercise wallets supporting bech32m. This is equivalent to the RFC2606 domain "example.com" which has been reserved for examples in documentation. The proposed addresses include one each for mainnet and testnet. The Witness version is 16, which is the last segwit version, while the Witness program is 0x0000; two bytes is the minimum allowed by BIP141, but it's far too small to make any sort of 2023-02-01T01:13:49+00:00 + In a recent email exchange on the bitcoin-dev mailing list, David A. Harding raised a question about the best practice for wallets when it comes to spending to the output indicated by any valid bech32m address. The response from aj was that it depends on whether the wallet is custodial or non-custodial. If it's a non-custodial wallet that may not be upgraded by the time witness v2 addresses are in use, then sending to such addresses now makes sense and is worth testing. However, if it's a custodial wallet, then there's a strong argument against allowing sending to such addresses until they're actually in use.The reason for this is two-fold: firstly, nobody will be running old software since the custodian can just force everyone to upgrade. Secondly, signing a transaction to send bitcoins held on behalf of someone else to an address that will get them stolen could be considered negligence, forcing the custodian to make the user whole again. Therefore, there's no point in testing a scenario that's likely years away for custodial wallets.On the other hand, for non-custodial wallets, it's worth testing as they might not be able to find compatible software in the future to move their private keys and have to resort to using the current software. However, in that case, they should be able to capture the transaction it generates before broadcasting it, and don't need to publish it on-chain. It's a different matter for libraries and non-wallet software like block explorers or alternate node implementations.In an email exchange, Greg Sanders predicts that most custodians may be hesitant to whitelist a witness version that they know is insecure. David A. Harding questions whether wallets should only send to outputs they know can be secured or if they should spend to the output indicated by any valid bech32m address. He finds the more restrictive approach to be sad and believes that there is a benefit to testing it when proprietary software is involved. However, he wants the testing to use the address least likely to cause problems for protocol developers in the future.David asks Greg and others on the list if they have any reason to believe that OP_16 OP_PUSH2 0000 would be a problematic script or if they can think of a better one. The email also references BIP350, which recommends ensuring that wallet implementations support sending to v1 and higher versions.In an email conversation between Greg Sanders and David, the topic of sending funds to future segwit versions was discussed. Greg suggested that most exchanges would not enable sends to future segwit versions due to the risk involved in doing so. However, David argued that wallets should spend to any valid bech32m address and that the more restrictive approach of only sending to secured outputs seemed unnecessary. He explained that withdrawing to a witness program for which there is no solution could result in bigger problems. David also suggested that testing the best practice of sending to secured outputs could benefit protocol developers in the future if they need to test other best practices that cannot be easily tested for. However, he wanted to use the address least likely to cause problems for protocol developers in the future. He sought suggestions from others on the list regarding what script to use. The email conversation references BIP350, which recommends supporting sending to v1 and higher versions.In a discussion on the Bitcoin-dev mailing list, David A. Harding proposed having a reserved address space for future segwit versions that are unlikely to interfere with future soft forks but can still exercise wallets supporting bech32m. He suggested using the following addresses: HRP (Human-readable part) "bc" for mainnet and "tb" for testnet, witness version 16 (the last segwit version), and witness program 0x0000. This would help developers of future soft forks deal with existing outputs paid to templates used in the proposed soft fork.Greg, in response, noted that most exchanges will not enable sends to future segwit versions due to the risk perspective of sending funds there. However, updating to new versions should be straightforward as long as the checksum is not changed again and popular open-source libraries support it. Testing this behavior in production can create an annoyance for developers of future soft forks. Therefore, having a canonical example of future segwit addresses that are unlikely to interfere with future soft forks could be useful.A proposal has been made for a canonical example of future segwit addresses that are designed to be very unlikely to interfere with future soft forks but which would still reasonably exercise wallets supporting bech32m. This is equivalent to the RFC2606 domain "example.com" which has been reserved for examples in documentation. The proposed addresses include one each for mainnet and testnet. The Witness version is 16, which is the last segwit version, while the Witness program is 0x0000; two bytes is the minimum allowed by BIP141, but it's far too small to make any sort of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Refreshed-BIP324.xml b/static/bitcoin-dev/Jan_2023/combined_Refreshed-BIP324.xml index cd4118e47b..e06b7710e5 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Refreshed-BIP324.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Refreshed-BIP324.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100274+00:00 - - Tim Ruffing 2023-10-11 20:52:52+00:00 - - - Erik Aronesty 2023-02-28 21:02:41+00:00 - - - Dhruv M 2023-02-28 18:07:06+00:00 - - - Anthony Towns 2023-02-21 16:03:37+00:00 - - - Pieter Wuille 2023-02-20 15:22:30+00:00 - - - Anthony Towns 2023-02-19 23:56:02+00:00 - - - Pieter Wuille 2023-02-17 22:13:05+00:00 - - - Anthony Towns 2023-02-17 15:51:19+00:00 - - - Dhruv M 2023-02-16 17:43:22+00:00 - - - Anthony Towns 2023-01-09 08:11:05+00:00 - - - Anthony Towns 2023-01-05 23:12:50+00:00 - - - Pieter Wuille 2023-01-05 22:06:29+00:00 - - - Anthony Towns 2022-11-18 08:24:49+00:00 - - - Yuval Kogman 2022-11-12 18:52:31+00:00 - - - Pieter Wuille 2022-11-12 03:23:16+00:00 - - - Pieter Wuille 2022-11-10 21:23:44+00:00 - - - Anthony Towns 2022-11-08 03:20:23+00:00 - - - Jonas Schnelli 2022-11-03 22:26:54+00:00 - - - Murch 2022-11-03 17:53:26+00:00 - - - Vasil Dimov 2022-10-27 07:28:38+00:00 - - - Pieter Wuille 2022-10-26 16:39:02+00:00 - - - Dhruv M 2022-10-08 12:59:58+00:00 - + 2025-09-26T14:32:22.748858+00:00 + python-feedgen + + + [bitcoin-dev] Refreshed BIP324 Dhruv M + 2022-10-08T12:59:00.000Z + + + Pieter Wuille + 2022-10-26T16:39:00.000Z + + + Vasil Dimov + 2022-10-27T07:28:00.000Z + + + Murch + 2022-11-03T17:53:00.000Z + + + Jonas Schnelli + 2022-11-03T22:26:00.000Z + + + Anthony Towns + 2022-11-08T03:20:00.000Z + + + Pieter Wuille + 2022-11-10T21:23:00.000Z + + + Pieter Wuille + 2022-11-12T03:23:00.000Z + + + Yuval Kogman + 2022-11-12T18:52:00.000Z + + + Anthony Towns + 2022-11-18T08:24:00.000Z + + + Pieter Wuille + 2023-01-05T22:06:00.000Z + + + Anthony Towns + 2023-01-05T23:12:00.000Z + + + Anthony Towns + 2023-01-09T08:11:00.000Z + + + Dhruv M + 2023-02-16T17:43:00.000Z + + + Anthony Towns + 2023-02-17T15:51:00.000Z + + + Pieter Wuille + 2023-02-17T22:13:00.000Z + + + Anthony Towns + 2023-02-19T23:56:00.000Z + + + Pieter Wuille + 2023-02-20T15:22:00.000Z + + + Anthony Towns + 2023-02-21T16:03:00.000Z + + + Dhruv M + 2023-02-28T18:07:00.000Z + + + Erik Aronesty + 2023-02-28T21:02:00.000Z + + + Tim Ruffing + 2023-10-11T20:52:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100469+00:00 + 2025-09-26T14:32:22.751192+00:00 - The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. 2023-10-11T20:52:52+00:00 + The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Roles-and-procedures-around-adding-a-bitcoin-core-maintainer.xml b/static/bitcoin-dev/Jan_2023/combined_Roles-and-procedures-around-adding-a-bitcoin-core-maintainer.xml index 30320e41a8..c14287954b 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Roles-and-procedures-around-adding-a-bitcoin-core-maintainer.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Roles-and-procedures-around-adding-a-bitcoin-core-maintainer.xml @@ -1,27 +1,25 @@ - + 2 Combined summary - Roles and procedures around adding a bitcoin core maintainer - 2023-08-02T08:39:59.643682+00:00 - - alicexbt 2023-01-07 05:11:00+00:00 - - - Michael Folkson 2022-12-20 18:44:05+00:00 - - - alicexbt 2022-12-19 21:58:13+00:00 - + 2025-09-26T14:32:03.511785+00:00 + python-feedgen + + + alicexbt + 2023-01-07T05:11:00.000Z + + - python-feedgen + 2 Combined summary - Roles and procedures around adding a bitcoin core maintainer - 2023-08-02T08:39:59.643682+00:00 + 2025-09-26T14:32:03.512121+00:00 - Alicexbt, a user on the Bitcoin-dev mailing list, has provided a detailed summary of the process for adding new maintainers to the Bitcoin Core team. The post outlines the recent addition of glowzow as a maintainer, as well as current efforts to add vasild as a new maintainer. Alicexbt proposes several changes to the current process, including opening a "Call for maintainers" issue when a new maintainer is needed, discussing nominated contributors in an IRC meeting where everyone can share their opinion, and avoiding self-merging pull requests.In response to Alicexbt's post, Michael Folkson suggests that there is some confusion around the process for adding new maintainers and pledges to look into the matter offline. He advises against "ranting and raving or throwing toys out the pram" on the mailing list and wishes everyone happy holidays.The post includes links to various pull requests, IRC meetings, and issues related to the process for adding maintainers. These links provide additional context and support for Alicexbt's proposals.Bitcoin Core has a list of present Bitcoin Core maintainers, which includes MarcoFalke, fanquake, hebasto, achow101, and glozow. Two developers that recently stepped down as Bitcoin Core maintainers are sipa and laanwj.The process followed in adding the recent maintainer, glowzow, involved nomination by fanquake, discussions in an IRC meeting, and a pull request opened by glowzow to add keys. The pull request received several ACKs, 2 NACKs, and 1 meta concept NACK, but eventually, everyone agreed to add glowzow as a maintainer, and the pull request was merged by MarcoFalke.Initiatives have been taken to improve the process and documentation for adding new maintainers. Jeremy opened a pull request that faced disagreements with the documentation and was later closed. Another related pull request was also closed with a comment from Jeremy that the desire to improve documentation seems to be missing based on reviews.Jeremy also nominated jonatack and vasild for a new maintainer in an issue which later got closed since nobody appreciated this effort to nominate self or others for a new maintainer. Similarly, an issue opened by the writer with the title 'Call for Maintainer: Privacy' received some comments that made no sense, and the issue was eventually closed.The process being followed for adding vasild as a maintainer involves volunteering by vasild, discussion in IRC meetings, and a pull request opened by vasild to add keys. The pull request received some ACKs and some disagreements from fanquake, dergoegge, and JeremyRubin. There was even a comment that disrespected vasild's contributions in Bitcoin Core.To improve the process of adding new maintainers, some suggestions include opening a 'Call for maintainers' issue if contributors or maintainers need a new maintainer, having discussions about nominated contributors in an IRC meeting, allowing everyone to share their opinion, defining scope for present and new maintainers, avoiding self-merging pull requests, and encouraging long-term contributors who are not living in a first-world country.In conclusion, Bitcoin Core needs to improve the process of adding new maintainers to ensure unbiased merging of pull requests. The organization should encourage contributions from long-term contributors globally and avoid politics while nominating new maintainers. 2023-01-07T05:11:00+00:00 + Alicexbt, a user on the Bitcoin-dev mailing list, has provided a detailed summary of the process for adding new maintainers to the Bitcoin Core team. The post outlines the recent addition of glowzow as a maintainer, as well as current efforts to add vasild as a new maintainer. Alicexbt proposes several changes to the current process, including opening a "Call for maintainers" issue when a new maintainer is needed, discussing nominated contributors in an IRC meeting where everyone can share their opinion, and avoiding self-merging pull requests.In response to Alicexbt's post, Michael Folkson suggests that there is some confusion around the process for adding new maintainers and pledges to look into the matter offline. He advises against "ranting and raving or throwing toys out the pram" on the mailing list and wishes everyone happy holidays.The post includes links to various pull requests, IRC meetings, and issues related to the process for adding maintainers. These links provide additional context and support for Alicexbt's proposals.Bitcoin Core has a list of present Bitcoin Core maintainers, which includes MarcoFalke, fanquake, hebasto, achow101, and glozow. Two developers that recently stepped down as Bitcoin Core maintainers are sipa and laanwj.The process followed in adding the recent maintainer, glowzow, involved nomination by fanquake, discussions in an IRC meeting, and a pull request opened by glowzow to add keys. The pull request received several ACKs, 2 NACKs, and 1 meta concept NACK, but eventually, everyone agreed to add glowzow as a maintainer, and the pull request was merged by MarcoFalke.Initiatives have been taken to improve the process and documentation for adding new maintainers. Jeremy opened a pull request that faced disagreements with the documentation and was later closed. Another related pull request was also closed with a comment from Jeremy that the desire to improve documentation seems to be missing based on reviews.Jeremy also nominated jonatack and vasild for a new maintainer in an issue which later got closed since nobody appreciated this effort to nominate self or others for a new maintainer. Similarly, an issue opened by the writer with the title 'Call for Maintainer: Privacy' received some comments that made no sense, and the issue was eventually closed.The process being followed for adding vasild as a maintainer involves volunteering by vasild, discussion in IRC meetings, and a pull request opened by vasild to add keys. The pull request received some ACKs and some disagreements from fanquake, dergoegge, and JeremyRubin. There was even a comment that disrespected vasild's contributions in Bitcoin Core.To improve the process of adding new maintainers, some suggestions include opening a 'Call for maintainers' issue if contributors or maintainers need a new maintainer, having discussions about nominated contributors in an IRC meeting, allowing everyone to share their opinion, defining scope for present and new maintainers, avoiding self-merging pull requests, and encouraging long-term contributors who are not living in a first-world country.In conclusion, Bitcoin Core needs to improve the process of adding new maintainers to ensure unbiased merging of pull requests. The organization should encourage contributions from long-term contributors globally and avoid politics while nominating new maintainers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_SIGHASH-GROUP-vs-Ephemeral-anchors.xml b/static/bitcoin-dev/Jan_2023/combined_SIGHASH-GROUP-vs-Ephemeral-anchors.xml index 2e1ac0b593..1f54b09be5 100644 --- a/static/bitcoin-dev/Jan_2023/combined_SIGHASH-GROUP-vs-Ephemeral-anchors.xml +++ b/static/bitcoin-dev/Jan_2023/combined_SIGHASH-GROUP-vs-Ephemeral-anchors.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - SIGHASH_GROUP vs Ephemeral anchors - 2023-08-02T08:47:43.542428+00:00 - - Antoine Riard 2023-01-12 02:06:21+00:00 - - - Anthony Towns 2023-01-11 08:00:14+00:00 - + 2025-09-26T14:32:20.585975+00:00 + python-feedgen + + + [bitcoin-dev] SIGHASH_GROUP vs Ephemeral anchors Anthony Towns + 2023-01-11T08:00:00.000Z + + + Antoine Riard + 2023-01-12T02:06:00.000Z + + - python-feedgen + 2 Combined summary - SIGHASH_GROUP vs Ephemeral anchors - 2023-08-02T08:47:43.542428+00:00 + 2025-09-26T14:32:20.586453+00:00 - The comparison between SIGHASH_GROUP and Ephemeral anchors is a topic of discussion in the bitcoin-dev mailing list. SIGHASH_GROUP allows inputs of a transaction to divide the outputs into non-overlapping groups, while Ephemeral anchors are a relay policy level rule that creates a 0-value output with sPK of OP_TRUE, which is not considered dust if paid 0 fees and relayed with another tx.SIGHASH_ALL can be used instead of SIGHASH_GROUP by creating three transactions and signing them accordingly. However, ephemeral anchors have some limitations compared to SIGHASH_GROUP, such as being unable to duplicate the behavior of two signatures, one using SIGHASH_GROUP and the other SIGHASH_ALL. There are proposed rules for ephemeral anchors, including that a V3 transaction cannot have more than one ancestor, and it must be 0-fee, spent in the same mempool relay package, and nversion==3. Removing or loosening the v3.4b rule could allow ephemeral anchors to provide fees for multiple input/output groups, but it may introduce replacement issues. Overall, ephemeral anchors appear to offer most of the benefits of SIGHASH_GROUP, particularly with the potential to save on costs and consensus changes.The context provided includes a link to a mailing list for Bitcoin developers hosted on the website lists.linuxfoundation.org. The mailing list allows developers to communicate and collaborate on the development of Bitcoin. The email also includes an attachment that appears to be an HTML file, but no information about its contents is given. 2023-01-12T02:06:21+00:00 + The comparison between SIGHASH_GROUP and Ephemeral anchors is a topic of discussion in the bitcoin-dev mailing list. SIGHASH_GROUP allows inputs of a transaction to divide the outputs into non-overlapping groups, while Ephemeral anchors are a relay policy level rule that creates a 0-value output with sPK of OP_TRUE, which is not considered dust if paid 0 fees and relayed with another tx.SIGHASH_ALL can be used instead of SIGHASH_GROUP by creating three transactions and signing them accordingly. However, ephemeral anchors have some limitations compared to SIGHASH_GROUP, such as being unable to duplicate the behavior of two signatures, one using SIGHASH_GROUP and the other SIGHASH_ALL. There are proposed rules for ephemeral anchors, including that a V3 transaction cannot have more than one ancestor, and it must be 0-fee, spent in the same mempool relay package, and nversion==3. Removing or loosening the v3.4b rule could allow ephemeral anchors to provide fees for multiple input/output groups, but it may introduce replacement issues. Overall, ephemeral anchors appear to offer most of the benefits of SIGHASH_GROUP, particularly with the potential to save on costs and consensus changes.The context provided includes a link to a mailing list for Bitcoin developers hosted on the website lists.linuxfoundation.org. The mailing list allows developers to communicate and collaborate on the development of Bitcoin. The email also includes an attachment that appears to be an HTML file, but no information about its contents is given. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Serverless-Payjoin.xml b/static/bitcoin-dev/Jan_2023/combined_Serverless-Payjoin.xml index 80705698a5..1848e7737e 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Serverless-Payjoin.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Serverless-Payjoin.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Serverless Payjoin - 2023-08-21T01:52:45.170913+00:00 - - alicexbt 2023-08-20 17:13:33+00:00 - - - Dan Gould 2023-01-22 20:50:44+00:00 - + 2025-09-26T14:31:59.247898+00:00 + python-feedgen + + + [bitcoin-dev] Serverless Payjoin Dan Gould + 2023-01-22T20:50:00.000Z + + + alicexbt + 2023-08-20T17:13:00.000Z + + - python-feedgen + 2 Combined summary - Serverless Payjoin - 2023-08-21T01:52:45.170979+00:00 + 2025-09-26T14:31:59.248338+00:00 - In a recent communication, Dan shared some points after reading an article titled "Serverless Payjoin Gets Its Wings" by Kukks. Firstly, there is a mention of NIP 4, which seems to have no security issues but potential privacy concerns due to metadata leakage. However, using a new npub each time users engage in payjoin can address this issue, as the message itself remains encrypted. Secondly, there is a discussion about backwards compatibility related to npub and relay information shared in payjoin URIs. The email mentions that fixing this issue is uncertain. Regarding relays, it is stated that if multiple relays are used, there is no incentive for them to engage in malicious activities. However, the exact nature of potential malicious activities with encrypted messages is not clearly understood. Additionally, IP addresses are identified as an issue in many projects, but this can be managed by users or wallet implementations through the use of RiseupVPN, Tor, i2p, etc. Finally, the suggestion of adding random padding, proposed by some senior developers, is considered sensible.Dan Gould has published an upgrade for payjoin that allows the receiver to receive bitcoin transfers without running a public server. This new scheme utilizes a TURN relay for connectivity and symmetric cryptography for security. The recipient requests the relay to allocate them an endpoint for UDP communication. They then share a BIP 21 payjoin URI containing the allocated endpoint and a generated 256-bit key called psk. The sender constructs their request using the original PSBT format from BIP 78, and they utilize the NNpsk0 pattern for noise framework instead of TLS or Tor. The resulting ciphertext ensures message secrecy and integrity when relayed to the recipient through the endpoint.However, this work highlights a larger issue with payjoin, which assumes synchronous communication in an asynchronous world. It is mentioned that a relay could hold a request for an offline payjoin peer until that peer comes online. Yet, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty, which exposes a naive and surveillance-vulnerable transaction that payjoin aims to avoid. Further research is needed before recommending such a protocol.Since TURN relays can handle various internet traffic, they are susceptible to the tragedy of the commons. Relay operators might impose authentication requirements for endpoint allocation provisions. While peers only see the IP address of the TURN relay, not their peer's, it is suggested that TURN relays could also be made available via Tor hidden service to allow either peer to protect their IP with Tor without forcing the other to use it too.Dan Gould has provided proof-of-concept sender, receiver clients, and relay code in Rust, which can be found on GitHub for more details and improved formatting. 2023-08-20T17:13:33+00:00 + In a recent communication, Dan shared some points after reading an article titled "Serverless Payjoin Gets Its Wings" by Kukks. Firstly, there is a mention of NIP 4, which seems to have no security issues but potential privacy concerns due to metadata leakage. However, using a new npub each time users engage in payjoin can address this issue, as the message itself remains encrypted. Secondly, there is a discussion about backwards compatibility related to npub and relay information shared in payjoin URIs. The email mentions that fixing this issue is uncertain. Regarding relays, it is stated that if multiple relays are used, there is no incentive for them to engage in malicious activities. However, the exact nature of potential malicious activities with encrypted messages is not clearly understood. Additionally, IP addresses are identified as an issue in many projects, but this can be managed by users or wallet implementations through the use of RiseupVPN, Tor, i2p, etc. Finally, the suggestion of adding random padding, proposed by some senior developers, is considered sensible.Dan Gould has published an upgrade for payjoin that allows the receiver to receive bitcoin transfers without running a public server. This new scheme utilizes a TURN relay for connectivity and symmetric cryptography for security. The recipient requests the relay to allocate them an endpoint for UDP communication. They then share a BIP 21 payjoin URI containing the allocated endpoint and a generated 256-bit key called psk. The sender constructs their request using the original PSBT format from BIP 78, and they utilize the NNpsk0 pattern for noise framework instead of TLS or Tor. The resulting ciphertext ensures message secrecy and integrity when relayed to the recipient through the endpoint.However, this work highlights a larger issue with payjoin, which assumes synchronous communication in an asynchronous world. It is mentioned that a relay could hold a request for an offline payjoin peer until that peer comes online. Yet, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty, which exposes a naive and surveillance-vulnerable transaction that payjoin aims to avoid. Further research is needed before recommending such a protocol.Since TURN relays can handle various internet traffic, they are susceptible to the tragedy of the commons. Relay operators might impose authentication requirements for endpoint allocation provisions. While peers only see the IP address of the TURN relay, not their peer's, it is suggested that TURN relays could also be made available via Tor hidden service to allow either peer to protect their IP with Tor without forcing the other to use it too.Dan Gould has provided proof-of-concept sender, receiver clients, and relay code in Rust, which can be found on GitHub for more details and improved formatting. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Using-OP-VAULT-to-improve-DLCs.xml b/static/bitcoin-dev/Jan_2023/combined_Using-OP-VAULT-to-improve-DLCs.xml index 24628c50d0..e6535f0467 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Using-OP-VAULT-to-improve-DLCs.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Using-OP-VAULT-to-improve-DLCs.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Using OP_VAULT to improve DLCs - 2023-08-02T08:47:59.670284+00:00 - - Billy Tetrud 2023-01-19 22:42:43+00:00 - - - Ben Carman 2023-01-12 12:32:06+00:00 - + 2025-09-26T14:32:14.165980+00:00 + python-feedgen + + + [bitcoin-dev] Using OP_VAULT to improve DLCs Ben Carman + 2023-01-12T12:32:00.000Z + + + Billy Tetrud + 2023-01-19T22:42:00.000Z + + - python-feedgen + 2 Combined summary - Using OP_VAULT to improve DLCs - 2023-08-02T08:47:59.670284+00:00 + 2025-09-26T14:32:14.166422+00:00 - A proposal has been put forward to use the OP_UNVAULT opcode as a means of creating more complex covenants. The idea is to restrict the script to only contain the OP_UNVAULT call, allowing it to be used for Jeremy Rubin's congestion control transactions. However, by adding a scriptPubKey for authorization recovery, it becomes possible to create more general covenants by setting the unvault-target-hash to an unsatisfiable number and placing arbitrary conditions on spending the UTXO to the recovery address. This concept, proposed by Ben Carman after reading James O'Beirne's OP_VAULT proposal, can be seen as a general CTV-like covenant.While this approach would require more blockchain space, it should offer the same computational savings as the original CTV proposal. The main drawback is that the final spending script will be slightly larger. Another proposal suggests using the OP_UNVAULT output to create a not-so-simple covenant by setting the unvault-target-hash to desired output restrictions. This construction can recreate many aspects of CTV, including Lloyd's improvement to DLCs. A taproot tree similar to Lloyd's construction could also be created, with each leaf appearing as `0 OP_UNVAULT CHECKSIG`. This variation should provide the same computational benefits as the original CTV proposal but would consume more blockchain space. The downside is that the final spending script would be slightly larger, with `OP_CTV` being replaced by `0 OP_UNVAULT` (adding 34 bytes, excluding the witness discount). However, in the case of a DLC with multiple outcomes, the impact may be negligible as the input size will primarily come from the control block.This idea was inspired by James O'Beirne's OP_VAULT proposal, and credit is given to Lloyd Fournier for the original proposal. 2023-01-19T22:42:43+00:00 + A proposal has been put forward to use the OP_UNVAULT opcode as a means of creating more complex covenants. The idea is to restrict the script to only contain the OP_UNVAULT call, allowing it to be used for Jeremy Rubin's congestion control transactions. However, by adding a scriptPubKey for authorization recovery, it becomes possible to create more general covenants by setting the unvault-target-hash to an unsatisfiable number and placing arbitrary conditions on spending the UTXO to the recovery address. This concept, proposed by Ben Carman after reading James O'Beirne's OP_VAULT proposal, can be seen as a general CTV-like covenant.While this approach would require more blockchain space, it should offer the same computational savings as the original CTV proposal. The main drawback is that the final spending script will be slightly larger. Another proposal suggests using the OP_UNVAULT output to create a not-so-simple covenant by setting the unvault-target-hash to desired output restrictions. This construction can recreate many aspects of CTV, including Lloyd's improvement to DLCs. A taproot tree similar to Lloyd's construction could also be created, with each leaf appearing as `0 OP_UNVAULT CHECKSIG`. This variation should provide the same computational benefits as the original CTV proposal but would consume more blockchain space. The downside is that the final spending script would be slightly larger, with `OP_CTV` being replaced by `0 OP_UNVAULT` (adding 34 bytes, excluding the witness discount). However, in the case of a DLC with multiple outcomes, the impact may be negligible as the input size will primarily come from the control block.This idea was inspired by James O'Beirne's OP_VAULT proposal, and credit is given to Lloyd Fournier for the original proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Wallet-policies-for-descriptor-wallets.xml b/static/bitcoin-dev/Jan_2023/combined_Wallet-policies-for-descriptor-wallets.xml index 31ad2a1399..30cae30479 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Wallet-policies-for-descriptor-wallets.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Wallet-policies-for-descriptor-wallets.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Wallet policies for descriptor wallets - 2023-08-02T06:23:33.636002+00:00 - - Salvatore Ingala 2023-01-24 08:38:29+00:00 - - - darosior 2023-01-23 19:53:18+00:00 - - - Salvatore Ingala 2022-11-21 11:27:25+00:00 - - - Andrew Poelstra 2022-09-29 23:56:51+00:00 - - - Salvatore Ingala 2022-05-17 08:44:53+00:00 - - - Salvatore Ingala 2022-05-10 09:37:26+00:00 - - - darosior 2022-05-09 11:36:47+00:00 - - - Billy Tetrud 2022-05-08 17:41:07+00:00 - - - Salvatore Ingala 2022-05-05 14:32:34+00:00 - + 2025-09-26T14:31:52.903972+00:00 + python-feedgen + + + [bitcoin-dev] Wallet policies for descriptor wallets Salvatore Ingala + 2022-05-05T14:32:00.000Z + + + Billy Tetrud + 2022-05-08T17:41:00.000Z + + + darosior + 2022-05-09T11:36:00.000Z + + + Salvatore Ingala + 2022-05-10T09:37:00.000Z + + + Salvatore Ingala + 2022-05-17T08:44:00.000Z + + + Andrew Poelstra + 2022-09-29T23:56:00.000Z + + + Salvatore Ingala + 2022-11-21T11:27:00.000Z + + + darosior + 2023-01-23T19:53:00.000Z + + + Salvatore Ingala + 2023-01-24T08:38:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Wallet policies for descriptor wallets - 2023-08-02T06:23:33.637054+00:00 + 2025-09-26T14:31:52.905019+00:00 - Salvatore Ingala, a Bitcoin developer, has proposed a new language called "wallet policies" to address challenges in implementing descriptors and miniscript support in hardware wallets. These challenges arise due to limited RAM, computational power, and storage capacity of hardware wallets.The proposed language aims to provide a native, compact representation of the wallet receive/change and improve the user experience of software wallets. The registration flow for wallet policies involves the software wallet initiating a registration process on the hardware wallet. The information includes the wallet policy and a unique name that identifies the policy. The hardware wallet displays the policy on its secure screen, allowing the user to review and compare it with a trusted source before approving it. The goal is to ensure that the user knows the policy being used to spend their funds, preventing any malicious modifications.To simplify implementation and improve user experience, the document proposes minimizing the amount of information shown on-screen and reducing the number of times the user needs to validate such information. It also suggests reusing the same xpub in multiple places to avoid blowup in descriptor size. The proof of registration is executed securely using message authentication codes.The document provides examples of wallet descriptor templates for different use cases, such as native segwit accounts, taproot BIP86 accounts, native segwit 2-of-3, and templates with miniscript for "1 of 2 equally likely keys." It also includes additional rules, implementation guidelines, and references to relevant Bitcoin Improvement Proposals (BIPs) for further information.The email exchange discusses the challenges of implementing output descriptors on signing devices, proposing optimizations to overcome difficulties for implementers. It suggests optimizations for common use cases, such as using two descriptors at different derivation indices for receive and change addresses. The conversation also touches on the feasibility of incorporating Musig2 descriptors into hardware wallets and the potential for improving key aliasing using wallet policies.Overall, the proposed wallet policies language aims to provide a secure and user-friendly solution for integrating descriptors and miniscript support in hardware wallets, addressing the limitations of embedded devices and ensuring good user experience.Salvatore Ingala addresses the challenges of implementing descriptors and miniscript support in hardware wallets due to technical constraints such as limited RAM and computational power. To overcome these limitations, Ingala proposes a "wallet policies" language that can be used by all hardware wallets to securely support complex scripts.The proposed solution involves a registration flow for the wallet policy in the hardware wallet. This registration process includes generating all relevant addresses/scripts and identifying keys controlled by the hardware wallet. The user registers a wallet policy into the hardware wallet, and the software wallet initiates the registration on the hardware wallet. The registered policy is stored in the hardware wallet's permanent memory, and a master key encrypts all necessary information required to spend funds sent to those addresses.The policy language suggested targets a stricter subset of the output descriptors language, making it easier to implement and allowing for human inspection during the registration flow. Wallet descriptor templates consist of key placeholders and key origin information, including various types such as P2SH, P2WSH, P2PKH, P2WPKH, multisig, sorted multi, P2TR, and miniscript templates.The document outlines a standard for output script descriptors used to derive addresses and scripts from wallet descriptor templates. It specifies that wallet policies are considered invalid if any placeholder has derivation steps while the corresponding element of the keys vector is not an xpub. The document provides examples of wallet descriptor templates for native segwit accounts, taproot BIP86 accounts, and multisig setups.Overall, the proposed wallet policies language aims to address the security and user experience challenges faced by hardware wallets when supporting complex scripts. By registering wallet policies, hardware wallets can securely perform operations like generating addresses and signing transactions. 2023-01-24T08:38:29+00:00 + Salvatore Ingala, a Bitcoin developer, has proposed a new language called "wallet policies" to address challenges in implementing descriptors and miniscript support in hardware wallets. These challenges arise due to limited RAM, computational power, and storage capacity of hardware wallets.The proposed language aims to provide a native, compact representation of the wallet receive/change and improve the user experience of software wallets. The registration flow for wallet policies involves the software wallet initiating a registration process on the hardware wallet. The information includes the wallet policy and a unique name that identifies the policy. The hardware wallet displays the policy on its secure screen, allowing the user to review and compare it with a trusted source before approving it. The goal is to ensure that the user knows the policy being used to spend their funds, preventing any malicious modifications.To simplify implementation and improve user experience, the document proposes minimizing the amount of information shown on-screen and reducing the number of times the user needs to validate such information. It also suggests reusing the same xpub in multiple places to avoid blowup in descriptor size. The proof of registration is executed securely using message authentication codes.The document provides examples of wallet descriptor templates for different use cases, such as native segwit accounts, taproot BIP86 accounts, native segwit 2-of-3, and templates with miniscript for "1 of 2 equally likely keys." It also includes additional rules, implementation guidelines, and references to relevant Bitcoin Improvement Proposals (BIPs) for further information.The email exchange discusses the challenges of implementing output descriptors on signing devices, proposing optimizations to overcome difficulties for implementers. It suggests optimizations for common use cases, such as using two descriptors at different derivation indices for receive and change addresses. The conversation also touches on the feasibility of incorporating Musig2 descriptors into hardware wallets and the potential for improving key aliasing using wallet policies.Overall, the proposed wallet policies language aims to provide a secure and user-friendly solution for integrating descriptors and miniscript support in hardware wallets, addressing the limitations of embedded devices and ensuring good user experience.Salvatore Ingala addresses the challenges of implementing descriptors and miniscript support in hardware wallets due to technical constraints such as limited RAM and computational power. To overcome these limitations, Ingala proposes a "wallet policies" language that can be used by all hardware wallets to securely support complex scripts.The proposed solution involves a registration flow for the wallet policy in the hardware wallet. This registration process includes generating all relevant addresses/scripts and identifying keys controlled by the hardware wallet. The user registers a wallet policy into the hardware wallet, and the software wallet initiates the registration on the hardware wallet. The registered policy is stored in the hardware wallet's permanent memory, and a master key encrypts all necessary information required to spend funds sent to those addresses.The policy language suggested targets a stricter subset of the output descriptors language, making it easier to implement and allowing for human inspection during the registration flow. Wallet descriptor templates consist of key placeholders and key origin information, including various types such as P2SH, P2WSH, P2PKH, P2WPKH, multisig, sorted multi, P2TR, and miniscript templates.The document outlines a standard for output script descriptors used to derive addresses and scripts from wallet descriptor templates. It specifies that wallet policies are considered invalid if any placeholder has derivation steps while the corresponding element of the keys vector is not an xpub. The document provides examples of wallet descriptor templates for native segwit accounts, taproot BIP86 accounts, and multisig setups.Overall, the proposed wallet policies language aims to address the security and user experience challenges faced by hardware wallets when supporting complex scripts. By registering wallet policies, hardware wallets can securely perform operations like generating addresses and signing transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Wallet-vaults-with-pre-signed-transactions-but-no-ephemeral-keys.xml b/static/bitcoin-dev/Jan_2023/combined_Wallet-vaults-with-pre-signed-transactions-but-no-ephemeral-keys.xml index 3ec05376c3..4aa4115441 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Wallet-vaults-with-pre-signed-transactions-but-no-ephemeral-keys.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Wallet-vaults-with-pre-signed-transactions-but-no-ephemeral-keys.xml @@ -1,33 +1,36 @@ - + 2 Combined summary - Wallet vaults with pre-signed transactions but no ephemeral keys - 2024-03-06T10:39:03.345296+00:00 - - Billy Tetrud 2023-01-31 15:02:51+00:00 - - - darosior 2023-01-26 14:30:56+00:00 - - - Billy Tetrud 2023-01-23 17:39:41+00:00 - + 2025-09-26T14:31:55.022827+00:00 + python-feedgen + + + [bitcoin-dev] Wallet vaults with pre-signed transactions but no ephemeral keys Billy Tetrud + 2023-01-23T17:39:00.000Z + + + darosior + 2023-01-26T14:30:00.000Z + + + Billy Tetrud + 2023-01-31T15:02:00.000Z + + - python-feedgen + 2 Combined summary - Wallet vaults with pre-signed transactions but no ephemeral keys - 2024-03-06T10:39:03.345296+00:00 + 2025-09-26T14:31:55.023375+00:00 + 2023-01-31T15:02:51+00:00 The discourse on James' OP_VAULT proposal introduces an innovative approach to wallet vaults that circumvents the need for ephemeral keys, which must be deleted after use as suggested in Bryan Bishop's earlier proposal. This method employs the creation of an N-of-N multisig address alongside pre-signing transactions with N-1 keys to another address that features various timelocked spend paths. This mechanism ensures that funds can be immediately accessed if all keys are available, similar to a standard N-of-N multisig setup. However, utilizing any of the pre-signed transactions transitions the funds to an address that allows for a clawback within a specified time frame, thus adding a layer of security. - The proposed system intricately outlines the process of setting up such a vault, involving the establishment of a 3 of 3 Vault Address and an Interim Address. The latter enables transactions with varying key combinations subject to specific timelocks. This setup requires meticulous storage of seeds, wallet configuration, and pre-signed transactions separately to facilitate recovery and unvaulting processes. Despite its innovative approach, this methodology introduces challenges such as the necessity for backing up transactions for each vaulting instance, inflexibility regarding transaction fees, and limitations on the amount that can be unvaulted, mandating the entire utxo to be used without providing for change. - The Revault project offers a more sophisticated instantiation of this concept, allowing for additional security measures through cosigning servers acting as anti-replay oracles, thereby enabling policy enforcement on spending transactions. This is particularly relevant as it addresses two significant issues identified: ensuring all watchtowers have received the Cancel signature before executing the Unvault transaction and the lack of policy application on Spend transactions. Although covenants could potentially resolve these concerns, the use of cosigning servers presents a suboptimal solution. For further details on Revault, interested parties can visit [Revault on GitHub](https://github.com/revault/). - This exploration into alternative vaulting methodologies demonstrates a clear evolution from traditional mechanisms requiring the deletion of ephemeral keys, moving towards more secure and flexible solutions. Despite the inherent challenges and potential for improvement, particularly in fee handling and unvaulting flexibility, these proposals mark significant advancements in cryptocurrency wallet security. - 2023-01-31T15:02:51+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2023/combined_Why-Full-RBF-Makes-DoS-Attacks-on-Multiparty-Protocols-Significantly-More-Expensive.xml b/static/bitcoin-dev/Jan_2023/combined_Why-Full-RBF-Makes-DoS-Attacks-on-Multiparty-Protocols-Significantly-More-Expensive.xml index 2133d86e22..cc164a9b0d 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Why-Full-RBF-Makes-DoS-Attacks-on-Multiparty-Protocols-Significantly-More-Expensive.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Why-Full-RBF-Makes-DoS-Attacks-on-Multiparty-Protocols-Significantly-More-Expensive.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive - 2023-08-02T08:47:30.328458+00:00 - - Peter Todd 2023-01-13 23:46:58+00:00 - - - Peter Todd 2023-01-13 23:37:04+00:00 - - - David A. Harding 2023-01-10 20:14:47+00:00 - - - alicexbt 2023-01-10 17:10:37+00:00 - - - Peter Todd 2023-01-10 10:06:22+00:00 - - - Peter Todd 2023-01-10 10:03:16+00:00 - - - David A. Harding 2023-01-10 10:02:35+00:00 - - - alicexbt 2023-01-10 09:19:39+00:00 - - - Peter Todd 2023-01-10 08:47:48+00:00 - - - David A. Harding 2023-01-10 07:11:46+00:00 - - - Peter Todd 2023-01-09 22:18:52+00:00 - + 2025-09-26T14:32:24.866415+00:00 + python-feedgen + + + [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive Peter Todd + 2023-01-09T22:18:00.000Z + + + David A. Harding + 2023-01-10T07:11:00.000Z + + + Peter Todd + 2023-01-10T08:47:00.000Z + + + alicexbt + 2023-01-10T09:19:00.000Z + + + David A. Harding + 2023-01-10T10:02:00.000Z + + + Peter Todd + 2023-01-10T10:03:00.000Z + + + Peter Todd + 2023-01-10T10:06:00.000Z + + + alicexbt + 2023-01-10T17:10:00.000Z + + + David A. Harding + 2023-01-10T20:14:00.000Z + + + Peter Todd + 2023-01-13T23:37:00.000Z + + + Peter Todd + 2023-01-13T23:46:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive - 2023-08-02T08:47:30.328458+00:00 + 2025-09-26T14:32:24.867702+00:00 - In an email thread on the Bitcoin-dev mailing list, a user named alicexbt raised concerns about full Replace-by-Fee (RBF) and its impact on coinjoin implementations. Peter Todd criticized Samourai Wallet's technical decisions and questioned Wasabi's privacy issues. The discussion also touched on Samourai's reputation regarding alleged collaboration with chain analysis firms for censorship purposes. However, this claim was considered symbolic and not a significant issue. The overall conversation highlighted privacy and censorship concerns within the Bitcoin community.In another email exchange, David A. Harding and Peter Todd discussed implementing "conflict monitoring" in decentralized coinjoin protocols. Two methods were proposed: running a relay node with a conflict-detection patch or assuming a conflict exists when there are unexplainable failures in new blocks. Both methods can evade attacks without the need for full-RBF. Todd questioned why centralized unconfirmed transaction acceptance services are prioritized over decentralized protocols that provide privacy and security for more users.In a discussion about decentralized coinjoin implementations like Joinmarket, Peter Todd raised the question of how to implement "conflict monitoring". Two methods were suggested: running a relay node with a conflict-detection patch and using Bitcoin Core to identify conflicting transactions in the mempool, or assuming a conflict exists based on low feerates in new blocks. Both methods have their advantages and limitations but can help prevent attacks on coinjoins without relying on full-RBF.The email thread also explained how Full-RBF helps mitigate double-spend DoS attacks by ensuring coinjoin transactions have fees set at a level that allows them to be mined in a reasonable amount of time. The discussion dismissed the opinion of Wasabi due to privacy issues and clarified that Full-RBF does not provide advantages to well-connected mining pools. It was also concluded that attackers can already perform DoS attacks by double-spending inputs in coinjoins, making Full-RBF unnecessary for this particular attack.In another email exchange between Peter Todd and Dave, the necessity of full-RBF was questioned. The discussion revolved around how participants would learn about double-spend attacks and the importance of implementing conflict monitoring systems in protocol software. It was emphasized that such systems can defeat pinning attacks and individual conflicting input attacks without requiring full-RBF.On Twitter, a user asked about getting extra sats to increase fees for coinjoin transactions. Peter Todd clarified that there is no need for extra sats as coinjoin transactions already have fees set at an appropriate level. He dismissed the mention of Whirlpool and criticized Samourai Wallet's technical decisions. The discussion concluded with Todd stating that attackers can already perform DoS attacks on coinjoins by double-spending inputs, rendering Full-RBF unnecessary.In an email exchange, Peter Todd and an unknown recipient discussed the benefits of full-RBF in multi-party protocols like coinjoins. Todd explained that full-RBF allows higher fee transactions to replace lower fee ones, ensuring forward progress and mitigating DoS attacks caused by intentional or unintentional double-spending of low-fee transactions. However, concerns were raised about transaction pinning and the cost difference between using full-RBF and not using it. Despite these concerns, full-RBF was deemed beneficial for multi-party protocols.In a Bitcoin-dev email, David A. Harding expressed confusion about the necessity of full-RBF. Peter Todd explained that without it, people can cause DoS attacks by double-spending inputs with low-fee transactions. Harding proposed creating new transactions without conflicting inputs, but Todd pointed out that participants may not always be aware of the double-spend. Todd also discussed the issue of transaction pinning and highlighted the cost difference between using full-RBF and not using it. He emphasized that full-RBF improves the success rate of automated coinjoin processes and similar protocols.The benefits of full-RBF were questioned in an email from Peter Todd. He argued that without it, intentional and unintentional double-spending attacks can occur, causing DoS attacks on multi-party protocols. However, another participant suggested alternative solutions to these attacks. The cost difference between using full-RBF and not using it was highlighted, with conflicting inputs costing $0.05 and transaction pinning costing $17.00.The absence of full-RBF in Bitcoin raised concerns about tx-pinning attacks. Peter Todd explained that without full-RBF, low-fee transactions can hold up multi-party protocols by double-spending inputs. Full-RBF mitigates this issue by allowing higher fee transactions to replace lower fee ones, ensuring forward progress. Despite concerns about the cost of attacks, full-RBF is considered a valuable improvement for multi-party protocols. 2023-01-13T23:46:58+00:00 + In an email thread on the Bitcoin-dev mailing list, a user named alicexbt raised concerns about full Replace-by-Fee (RBF) and its impact on coinjoin implementations. Peter Todd criticized Samourai Wallet's technical decisions and questioned Wasabi's privacy issues. The discussion also touched on Samourai's reputation regarding alleged collaboration with chain analysis firms for censorship purposes. However, this claim was considered symbolic and not a significant issue. The overall conversation highlighted privacy and censorship concerns within the Bitcoin community.In another email exchange, David A. Harding and Peter Todd discussed implementing "conflict monitoring" in decentralized coinjoin protocols. Two methods were proposed: running a relay node with a conflict-detection patch or assuming a conflict exists when there are unexplainable failures in new blocks. Both methods can evade attacks without the need for full-RBF. Todd questioned why centralized unconfirmed transaction acceptance services are prioritized over decentralized protocols that provide privacy and security for more users.In a discussion about decentralized coinjoin implementations like Joinmarket, Peter Todd raised the question of how to implement "conflict monitoring". Two methods were suggested: running a relay node with a conflict-detection patch and using Bitcoin Core to identify conflicting transactions in the mempool, or assuming a conflict exists based on low feerates in new blocks. Both methods have their advantages and limitations but can help prevent attacks on coinjoins without relying on full-RBF.The email thread also explained how Full-RBF helps mitigate double-spend DoS attacks by ensuring coinjoin transactions have fees set at a level that allows them to be mined in a reasonable amount of time. The discussion dismissed the opinion of Wasabi due to privacy issues and clarified that Full-RBF does not provide advantages to well-connected mining pools. It was also concluded that attackers can already perform DoS attacks by double-spending inputs in coinjoins, making Full-RBF unnecessary for this particular attack.In another email exchange between Peter Todd and Dave, the necessity of full-RBF was questioned. The discussion revolved around how participants would learn about double-spend attacks and the importance of implementing conflict monitoring systems in protocol software. It was emphasized that such systems can defeat pinning attacks and individual conflicting input attacks without requiring full-RBF.On Twitter, a user asked about getting extra sats to increase fees for coinjoin transactions. Peter Todd clarified that there is no need for extra sats as coinjoin transactions already have fees set at an appropriate level. He dismissed the mention of Whirlpool and criticized Samourai Wallet's technical decisions. The discussion concluded with Todd stating that attackers can already perform DoS attacks on coinjoins by double-spending inputs, rendering Full-RBF unnecessary.In an email exchange, Peter Todd and an unknown recipient discussed the benefits of full-RBF in multi-party protocols like coinjoins. Todd explained that full-RBF allows higher fee transactions to replace lower fee ones, ensuring forward progress and mitigating DoS attacks caused by intentional or unintentional double-spending of low-fee transactions. However, concerns were raised about transaction pinning and the cost difference between using full-RBF and not using it. Despite these concerns, full-RBF was deemed beneficial for multi-party protocols.In a Bitcoin-dev email, David A. Harding expressed confusion about the necessity of full-RBF. Peter Todd explained that without it, people can cause DoS attacks by double-spending inputs with low-fee transactions. Harding proposed creating new transactions without conflicting inputs, but Todd pointed out that participants may not always be aware of the double-spend. Todd also discussed the issue of transaction pinning and highlighted the cost difference between using full-RBF and not using it. He emphasized that full-RBF improves the success rate of automated coinjoin processes and similar protocols.The benefits of full-RBF were questioned in an email from Peter Todd. He argued that without it, intentional and unintentional double-spending attacks can occur, causing DoS attacks on multi-party protocols. However, another participant suggested alternative solutions to these attacks. The cost difference between using full-RBF and not using it was highlighted, with conflicting inputs costing $0.05 and transaction pinning costing $17.00.The absence of full-RBF in Bitcoin raised concerns about tx-pinning attacks. Peter Todd explained that without full-RBF, low-fee transactions can hold up multi-party protocols by double-spending inputs. Full-RBF mitigates this issue by allowing higher fee transactions to replace lower fee ones, ensuring forward progress. Despite concerns about the cost of attacks, full-RBF is considered a valuable improvement for multi-party protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_-BUG-Bitcoin-blockspace-price-discrimination-put-simple-transactions-at-disadvantage.xml b/static/bitcoin-dev/Jan_2024/combined_-BUG-Bitcoin-blockspace-price-discrimination-put-simple-transactions-at-disadvantage.xml index 1ba61158d2..dc2707f876 100644 --- a/static/bitcoin-dev/Jan_2024/combined_-BUG-Bitcoin-blockspace-price-discrimination-put-simple-transactions-at-disadvantage.xml +++ b/static/bitcoin-dev/Jan_2024/combined_-BUG-Bitcoin-blockspace-price-discrimination-put-simple-transactions-at-disadvantage.xml @@ -1,38 +1,35 @@ - + 2 Combined summary - [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage - 2024-01-24T02:09:27.130205+00:00 - - Greg Tonoski 2024-01-21 17:14:14+00:00 - - - Nagaev Boris 2024-01-16 23:40:12+00:00 - - - Nagaev Boris 2024-01-16 23:29:58+00:00 - - - Greg Tonoski 2024-01-16 10:40:48+00:00 - - - Greg Tonoski 2024-01-14 13:10:30+00:00 - - - Greg Tonoski 2024-01-13 15:04:12+00:00 - - - Keagan McClelland 2023-12-27 22:39:38+00:00 - - - vjudeu at gazeta.pl 2023-12-27 21:43:34+00:00 - - - Nagaev Boris 2023-12-27 19:06:13+00:00 - - - Greg Tonoski 2023-12-27 16:44:51+00:00 - + 2025-09-26T14:19:51.781313+00:00 + python-feedgen + + + Greg Tonoski + 2024-01-13T15:04:00.000Z + + + Greg Tonoski + 2024-01-14T13:10:00.000Z + + + Greg Tonoski + 2024-01-16T10:40:00.000Z + + + Nagaev Boris + 2024-01-16T23:29:00.000Z + + + Nagaev Boris + 2024-01-16T23:40:00.000Z + + + Greg Tonoski + 2024-01-21T17:14:00.000Z + + @@ -43,31 +40,22 @@ - python-feedgen + 2 Combined summary - [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage - 2024-01-24T02:09:27.130332+00:00 + 2025-09-26T14:19:51.782005+00:00 + 2024-01-21T17:14:14+00:00 The ongoing debate regarding the use of blockchain for data storage highlights several key issues. Firstly, transactions that incorporate large amounts of non-essential witness data, such as an image in a single transaction, could change the nature of the blockchain by inflating it with this 'bloated' data. The UTXO set naturally expands as the number of participants grows, and price discrimination for block space has not halted this inflation. - The cost-effectiveness of storing data on the blockchain is scrutinized, particularly given the financial implications which do not seem to be offset by discounts. There's also concern about centralization within the Bitcoin network; centralized batch transactions by exchanges have already led to significant centralization, independent of any benefits from witness discounting. - Node operators typically situate UTXO sets on SSDs due to their speed, while blocks are stored on HDDs, which are less costly. If miners were to charge the same for storing one byte of transaction output as they do for witness data, it could lead to an increase in UTXO set size, forcing node operators to invest in more expensive SSD storage. The current pricing structure, which differentiates between the two types of data, helps maintain economic balance for node operators. - While transaction type—P2WPKH or P2TR—is important, prioritization in blockchain networks is more complex, often depending more on transaction size and fees. 'Bloated' transactions may be prioritized over simpler ones, despite the cumulative size and fees being comparable. - Discussion around the allocation of block space to witness data reveals that the preferential pricing model can lead to artificial inflation of witness data. This misallocation can negatively impact network efficiency, impose bandwidth costs on nodes, and risk centralizing control of the Bitcoin network. For visual reference on the disparities in block allocation, see [Bitcoin Segwit Mispricing Comparison](https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf). - -Moreover, the "witness discount" affects how transactions are prioritized but does not translate into storage costs for nodes. The connection between the UTXO set size and the witness discount doesn't influence operational node expenses, and linking the two could introduce system inefficiencies. - +Moreover, the "witness discount" affects how transactions are prioritized but does not translate into storage costs for nodes. The connection between the UTXO set size and the witness discount doesn't influence operational node expenses, and linking the two could introduce system inefficiencies. There are concerns about the blockchain's operational mechanisms, specifically whether inefficiencies occur inside or outside the witness, and how these affect simple transactions versus complex ones. This calls for a deeper understanding of how these issues manifest in the system. - Comparatively, sending coins to a P2WPKH address is currently cheaper than to a P2TR address, though spending Taproot transactions is more block space-efficient since no public key hash needs to be stored. The discrepancy between the costs of sending versus spending suggests the need for a revised fee structure that accounts for the long-term benefits of Taproot transactions. - -Finally, the current incentivization structure favors storing data in the witness section, as evidenced by the substantial size difference between the "blocks" directory and the "chainstate" directory—the former being much larger due to the lower latency requirements and thus, less expensive storage solutions. A balanced incentive for keeping the "chainstate" streamlined is crucial for efficient transaction validation. - +Finally, the current incentivization structure favors storing data in the witness section, as evidenced by the substantial size difference between the "blocks" directory and the "chainstate" directory—the former being much larger due to the lower latency requirements and thus, less expensive storage solutions. A balanced incentive for keeping the "chainstate" streamlined is crucial for efficient transaction validation. In conclusion, there is a call for a uniform pricing strategy across all bytes within the blockchain, irrespective of their position in the transaction data. A 1:1 weight-to-byte ratio would ensure equity in block space pricing and could be considered for future Segwit updates. The community's reception to this proposal will likely shape the direction of blockchain development. - 2024-01-21T17:14:14+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_BIP-number-request-for-wallet-policies.xml b/static/bitcoin-dev/Jan_2024/combined_BIP-number-request-for-wallet-policies.xml index 3322ca157b..157127fd17 100644 --- a/static/bitcoin-dev/Jan_2024/combined_BIP-number-request-for-wallet-policies.xml +++ b/static/bitcoin-dev/Jan_2024/combined_BIP-number-request-for-wallet-policies.xml @@ -1,29 +1,31 @@ - + 2 Combined summary - BIP number request for wallet policies - 2024-01-26T01:54:53.808032+00:00 - - Michael Folkson 2024-01-25 16:49:49+00:00 - - - Antoine Poinsot 2023-12-16 14:10:08+00:00 - + 2025-09-26T14:19:30.457768+00:00 + python-feedgen + + + [bitcoin-dev] BIP number request for wallet policies Antoine Poinsot + 2023-12-16T14:10:00.000Z + + + Michael Folkson + 2024-01-25T16:49:00.000Z + + - python-feedgen + 2 Combined summary - BIP number request for wallet policies - 2024-01-26T01:54:53.808085+00:00 + 2025-09-26T14:19:30.458253+00:00 + 2024-01-25T16:49:49+00:00 The Bitcoin community is currently observing the progression of a proposed standard for hardware signing devices, which has been in practical use by major providers including Ledger, BitBox02, and Jade. Initiated by Salvatore Ingala around eighteen months ago, this wallet policy standard is yet to receive formal recognition in the form of a Bitcoin Improvement Proposal (BIP) number. Despite being widely adopted in production, the proposal's official status remains pending in the BIPs repository. - Antoine Poinsot, the author of the proposal, has been awaiting a response from the BIP editors for over a year since the initial pull request for a BIP number was submitted. The lack of assignment or feedback after multiple follow-ups has raised concerns among those involved in the development. This delay hinders the formalization of a standard that is already deemed essential by the industry. Poinsot and other contributors are eager for guidance from the BIP editors to understand their expectations better and to align with the requirements for formal acceptance. - This situation underscores a larger issue regarding the process of managing and implementing improvements within the Bitcoin ecosystem. The current impasse calls attention to the necessity for a more efficient, responsive, and transparent system for handling such proposals. A system that offers clearer communication and support could significantly benefit the community, especially those dedicated to enhancing the Bitcoin infrastructure. Moreover, the recent assignment of a BIP number, BIP 388, as mentioned by Michael Folkson, may represent a step towards resolving these procedural bottlenecks and ensuring that contributors like Poinsot receive the recognition and direction needed to uphold the ongoing development and standardization efforts in the Bitcoin space. - For those interested in further details about Bitcoin and its ongoing developments, educational resources are available at [Port of Bitcoin](https://www.youtube.com/@portofbitcoin). - 2024-01-25T16:49:49+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_BIP-process-friction.xml b/static/bitcoin-dev/Jan_2024/combined_BIP-process-friction.xml index fc97458f60..4ea9cd3d2f 100644 --- a/static/bitcoin-dev/Jan_2024/combined_BIP-process-friction.xml +++ b/static/bitcoin-dev/Jan_2024/combined_BIP-process-friction.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - BIP process friction - 2024-01-24T02:14:15.070907+00:00 - - Michael Folkson 2024-01-19 19:27:30+00:00 - - - KarlJohan Alm 2024-01-19 02:33:25+00:00 - - - Anthony Towns 2024-01-19 00:46:10+00:00 - - - Peter Todd 2024-01-18 18:00:34+00:00 - - - Peter Todd 2024-01-18 17:42:03+00:00 - - - alicexbt 2024-01-18 16:47:33+00:00 - - - David A. Harding 2024-01-18 15:41:14+00:00 - - - Michael Folkson 2024-01-17 17:29:48+00:00 - - - Luke Dashjr 2024-01-17 16:45:59+00:00 - - - Christopher Allen 2024-01-17 06:55:03+00:00 - - - Anthony Towns 2024-01-17 02:42:52+00:00 - + 2025-09-26T14:19:34.722451+00:00 + python-feedgen + + + [bitcoin-dev] BIP process friction Anthony Towns + 2024-01-17T02:42:00.000Z + + + Christopher Allen + 2024-01-17T06:55:00.000Z + + + Luke Dashjr + 2024-01-17T16:45:00.000Z + + + Michael Folkson + 2024-01-17T17:29:00.000Z + + + David A. Harding + 2024-01-18T15:41:00.000Z + + + alicexbt + 2024-01-18T16:47:00.000Z + + + Peter Todd + 2024-01-18T17:42:00.000Z + + + Peter Todd + 2024-01-18T18:00:00.000Z + + + Anthony Towns + 2024-01-19T00:46:00.000Z + + + Karl-Johan Alm + 2024-01-19T02:33:00.000Z + + + Michael Folkson + 2024-01-19T19:27:00.000Z + + @@ -47,21 +61,17 @@ - python-feedgen + 2 Combined summary - BIP process friction - 2024-01-24T02:14:15.070995+00:00 + 2025-09-26T14:19:34.723774+00:00 - Kalle's resignation as a Bitcoin Improvement Proposal (BIP) editor has prompted the Bitcoin community to reconsider how responsibilities are distributed among the team to maintain the BIP editing process effectively. The debate around BIP-125, which deals with transaction fee variability and affects all wallet users, contrasts with more specialized cases like Ordinals or Taproot Assets, suggesting these niche topics may not be suitable for official BIPs. There's a call for "living documentation" to better reflect current practices and trade-offs in mempool policies, with suggestions to introduce versioning in BIPs to allow for updates without new proposal numbers. - + 2024-01-19T19:27:30+00:00 + Kalle's resignation as a Bitcoin Improvement Proposal (BIP) editor has prompted the Bitcoin community to reconsider how responsibilities are distributed among the team to maintain the BIP editing process effectively. The debate around BIP-125, which deals with transaction fee variability and affects all wallet users, contrasts with more specialized cases like Ordinals or Taproot Assets, suggesting these niche topics may not be suitable for official BIPs. There's a call for "living documentation" to better reflect current practices and trade-offs in mempool policies, with suggestions to introduce versioning in BIPs to allow for updates without new proposal numbers. The use of signet for testing, although advantageous for controlled experimentation, has sparked discussions regarding its centralized nature and the terminology used to describe its consensus mechanism. A proposition for a new identifier system for proposals, such as BIN24-1, aims to reduce visual clutter and enhance readability, seeking community feedback on its implementation. - The BIP process itself faces scrutiny, especially on whether policy changes should be documented as BIPs to facilitate tracking and review by developers, particularly those working on protocols like Lightning. Separating policy sections from consensus change BIPs could provide clearer guidance. A revision of BIP 3 is suggested to reflect the decentralized and voluntary aspects of Bitcoin's development. - Blockchain Commons Research (BCR) offers an alternative management approach for research proposals and standards, resetting numbering annually for simplicity and employing a status symbol system to track progression based on actual implementations. Their GitHub repository outlines a system that categorizes proposals into various statuses, providing clarity on the developmental stage of each specification. This method could influence the BIP framework by offering a transparent way to monitor proposal development and acceptance. - The BIP process has faced difficulties, highlighted by the backlog of unmerged pull requests and administrative challenges, such as assigning new numbers and mandating backward compatibility sections. In response, aj has created BINANA, an independent system hosted on GitHub for assigning numbers to bitcoin-related specifications more liberally. While BINANA serves as an alternative to the formal BIP process, aj does not intend to lead reforms within the existing BIP repository system, though it playfully suggests that BINANA could become a comprehensive glossary for the Bitcoin community. - 2024-01-19T19:27:30+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_CheckTemplateVerify-Does-Not-Scale-Due-to-UTXO-s-Required-For-Fee-Payment.xml b/static/bitcoin-dev/Jan_2024/combined_CheckTemplateVerify-Does-Not-Scale-Due-to-UTXO-s-Required-For-Fee-Payment.xml index d74c4f9378..125c3acfea 100644 --- a/static/bitcoin-dev/Jan_2024/combined_CheckTemplateVerify-Does-Not-Scale-Due-to-UTXO-s-Required-For-Fee-Payment.xml +++ b/static/bitcoin-dev/Jan_2024/combined_CheckTemplateVerify-Does-Not-Scale-Due-to-UTXO-s-Required-For-Fee-Payment.xml @@ -1,47 +1,67 @@ - + 2 Combined summary - CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment - 2024-01-31T01:58:03.672241+00:00 - - Peter Todd 2024-01-30 08:40:41+00:00 - - - Anthony Towns 2024-01-30 05:55:09+00:00 - - - ZmnSCPxj 2024-01-30 05:17:04+00:00 - - - ZmnSCPxj 2024-01-30 05:07:16+00:00 - - - Peter Todd 2024-01-30 04:49:57+00:00 - - - Peter Todd 2024-01-30 04:46:27+00:00 - - - Peter Todd 2024-01-30 04:41:30+00:00 - - - Peter Todd 2024-01-30 04:38:26+00:00 - - - ZmnSCPxj 2024-01-30 04:12:07+00:00 - - - Brandon Black 2024-01-27 06:28:54+00:00 - - - jlspc 2024-01-25 17:49:26+00:00 - - - Michael Folkson 2024-01-25 12:57:52+00:00 - - - Peter Todd 2024-01-24 19:31:07+00:00 - + 2025-09-26T14:19:26.228559+00:00 + python-feedgen + + + [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment Peter Todd + 2024-01-24T19:31:00.000Z + + + Michael Folkson + 2024-01-25T12:57:00.000Z + + + [bitcoin-dev] " jlspc + 2024-01-25T17:49:00.000Z + + + Brandon Black + 2024-01-27T06:28:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2024-01-30T04:12:00.000Z + + + Peter Todd + 2024-01-30T04:38:00.000Z + + + Peter Todd + 2024-01-30T04:41:00.000Z + + + Peter Todd + 2024-01-30T04:46:00.000Z + + + Peter Todd + 2024-01-30T04:49:00.000Z + + + ZmnSCPxj + 2024-01-30T05:07:00.000Z + + + ZmnSCPxj + 2024-01-30T05:17:00.000Z + + + Anthony Towns + 2024-01-30T05:55:00.000Z + + + Peter Todd + 2024-01-30T08:40:00.000Z + + + jlspc' + 2024-02-20T23:13:00.000Z + + @@ -55,23 +75,18 @@ - python-feedgen + 2 Combined summary - CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment - 2024-01-31T01:58:03.672338+00:00 + 2025-09-26T14:19:26.230171+00:00 + 2024-01-30T08:40:41+00:00 The current discussions among developers are addressing the fee payment structure within the Lightning Network (LN), focusing on commitment transactions, fairness in fee distribution, and incentives. It is observed that the channel initiator might not necessarily pay most of the fees, challenging the expectation of 'initiator pays.' Real-world examples have shown that cooperative close failures can occur due to low initial fee rates, necessitating the recipient to use Child Pays for Parent (CPFP) to expedite their transaction. - Proposals such as BIP 118 and BIP 143 seek to modify digital signature hashing, influencing how fees get distributed in LN transactions. The concept of 'initiator pays' is under scrutiny, especially with regard to potential fee-related attacks where an attacker could drain a channel at a low fee-rate time, leaving the victim with high transaction fees. Debates also touch upon the security implications of fee-rate-dependent timelocks (FDTs) which rely on miner honesty, and whether anchor outputs and CPFP are less efficient than Replace-by-Fee (RBF) due to additional block space required for CPFP transactions. - Peter Todd has proposed signing multiple offchain transaction versions with different fee rates to address these issues, although concerns about incentives and party responsibilities for fee payments persist. There is consideration for shared burden in fee payments, potentially requiring contributions from all parties during channel openings, diverging from single-sided funding models. - Moreover, there is an ongoing debate regarding the fair allocation of on-chain fees within channels and the practicality of multiple fee-rate-version transactions in protocols like Poon-Dryja or Decker-Russell-Osuntokun. Discussions cover the management of Hash Time-Locked Contracts (HTLCs), user balance protocols, and CTV-based solutions for exit fees. Proposed ideas include using in-protocol balances to cover fees, ephemeral anchors for exiting users, dual UTXO commitments for incoming users, and fee insurance to facilitate multiple exits through one UTXO. These concepts aim to decrease trust requirements and scale the network effectively. - Michael Folkson discusses the comparison between CTV and RBF, particularly in high fee scenarios, highlighting the limitations of CPFP compared to the efficiency of RBF. He also addresses the implications for LN symmetry and suggests that APO-based LN-Symmetry could enable fee adjustments with channel updates. For further in-depth discussions, individuals can visit the [Lightning Development Mailing List](https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004254.html) and Michael Folkson's [YouTube channel](https://www.youtube.com/@portofbitcoin). - Critiques of CTV highlight the contradiction of its goal to simplify UTXO management with the possible requirement of additional UTXOs for fee payments. Suggestions include pausing CTV development in favor of new covenant schemes that integrate RBF features to avoid extra UTXOs and enhance on-chain efficiency. Resources related to these topics are available in the [Bitcoin Improvement Proposals on GitHub](https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0119.mediawiki) and [Peter Todd's review on v3 transactions](https://petertodd.org/2023/v3-transactions-reviewanchor-outputs-are-a-danger-to-mining-decentralization). Peter Todd's contact information is provided, excluding the last character for security purposes. - 2024-01-30T08:40:41+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_Compressed-Bitcoin-Transactions.xml b/static/bitcoin-dev/Jan_2024/combined_Compressed-Bitcoin-Transactions.xml index 4750f6e120..b66e879b28 100644 --- a/static/bitcoin-dev/Jan_2024/combined_Compressed-Bitcoin-Transactions.xml +++ b/static/bitcoin-dev/Jan_2024/combined_Compressed-Bitcoin-Transactions.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Compressed Bitcoin Transactions - 2024-01-24T02:03:56.249090+00:00 - - Tom Briar 2024-01-19 21:09:35+00:00 - - - Jonas Schnelli 2024-01-18 09:24:02+00:00 - - - Tom Briar 2024-01-16 17:08:54+00:00 - - - Tom Briar 2024-01-09 15:31:37+00:00 - - - Andrew Poelstra 2024-01-05 15:19:31+00:00 - - - Tom Briar 2024-01-05 15:06:01+00:00 - - - Tom Briar 2023-09-05 18:30:42+00:00 - - - Peter Todd 2023-09-05 18:00:33+00:00 - - - Tom Briar 2023-09-01 17:05:17+00:00 - - - Jonas Schnelli 2023-09-01 16:56:22+00:00 - - - Tom Briar 2023-09-01 14:12:09+00:00 - - - Andrew Poelstra 2023-09-01 13:56:18+00:00 - - - Fabian 2023-09-01 10:43:26+00:00 - - - Fabian 2023-09-01 10:24:54+00:00 - - - Andrew Poelstra 2023-09-01 00:49:36+00:00 - - - Tom Briar 2023-08-31 21:30:16+00:00 - + 2025-09-26T14:19:36.872099+00:00 + python-feedgen + + + [bitcoin-dev] Compressed Bitcoin Transactions Tom Briar + 2023-08-31T21:30:00.000Z + + + Andrew Poelstra + 2023-09-01T00:49:00.000Z + + + Fabian + 2023-09-01T10:24:00.000Z + + + Fabian + 2023-09-01T10:43:00.000Z + + + Andrew Poelstra + 2023-09-01T13:56:00.000Z + + + Tom Briar + 2023-09-01T14:12:00.000Z + + + Jonas Schnelli + 2023-09-01T16:56:00.000Z + + + Tom Briar + 2023-09-01T17:05:00.000Z + + + Peter Todd + 2023-09-05T18:00:00.000Z + + + Tom Briar + 2023-09-05T18:30:00.000Z + + + Tom Briar + 2024-01-05T15:06:00.000Z + + + Andrew Poelstra + 2024-01-05T15:19:00.000Z + + + Tom Briar + 2024-01-09T15:31:00.000Z + + + Tom Briar + 2024-01-16T17:08:00.000Z + + + Jonas Schnelli + 2024-01-18T09:24:00.000Z + + + Tom Briar + 2024-01-19T21:09:00.000Z + + @@ -67,21 +86,17 @@ - python-feedgen + 2 Combined summary - Compressed Bitcoin Transactions - 2024-01-24T02:03:56.249206+00:00 + 2025-09-26T14:19:36.874237+00:00 + 2024-01-19T21:09:35+00:00 Tom's communication focuses on the development of data compression strategies for Bitcoin transactions, specifically targeting peer-to-peer encrypted traffic. He highlights that traditional compression tools like gzip are not efficient for compressing Bitcoin transactions due to their inability to handle pseudorandom data effectively. Instead, Tom suggests removing redundant elements such as hashes and public keys, which can be regenerated after decompression, to achieve significant size reductions. - He also emphasizes the necessity for application-layer solutions for version 2 encrypted P2P traffic, contrasting it with the OSI model layer adjustments suitable for non-encrypted version 1 traffic. A specific compression proposal at the application layer is scrutinized for its potential to enhance space savings without requiring substantial CPU resources, facilitating quicker block propagation throughout the network. These technical discussions continue on GitHub for a deeper evaluation of this approach. - The Compressed Transaction Schema, conceived by Tom Briar and Andrew Poelstra, is introduced as a technique to decrease transaction sizes within the Bitcoin network by up to 30%, particularly useful under BIP-324. The schema innovates by excluding optional components and introducing new formats such as relative block height and compressed inputs. It is especially beneficial in scenarios with limited bandwidth but sufficient processing power for decompression. Four methods are proposed to optimize compression, though one may complicate decompression in the event of block reorganizations. Details on this schema, including test vectors and performance examples, can be found in the documentation accessible via [this link](https://github.com/TomBriar/bitcoin/blob/2023-05--tx-compression/doc/compressed_transactions.md). - In practice, integrating this schema into Bitcoin Core requires balancing transaction size optimization with decompression time. Alternatives for handling lock time are discussed to conserve bytes, and a method involving encoding transaction outputs with a delta relative to a reference height is considered. Tom responds to feedback from Jonas and Fabian, noting efforts to gather empirical data and introducing a new RPC endpoint to monitor transaction age for compression eligibility. Clear guidelines in BIP documentation are emphasized to mitigate risks during blockchain reorganizations. - Fabian proposes future exploration of a sorted UTXO set index to save space and suggests alternatives for UTXO indexing, while Andrew requests a chart to illustrate the compression strength of specific transaction types. Tom has taken an active role in developing a compression schema for Bitcoin transactions, maintaining transaction integrity while optimizing for efficiency and security. He has made strides in implementing his schema, indicative of ongoing innovation in transaction processing. - 2024-01-19T21:09:35+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_Future-of-the-bitcoin-dev-mailing-list.xml b/static/bitcoin-dev/Jan_2024/combined_Future-of-the-bitcoin-dev-mailing-list.xml index 8652663d63..66f6569840 100644 --- a/static/bitcoin-dev/Jan_2024/combined_Future-of-the-bitcoin-dev-mailing-list.xml +++ b/static/bitcoin-dev/Jan_2024/combined_Future-of-the-bitcoin-dev-mailing-list.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Future of the bitcoin-dev mailing list - 2024-01-06T02:06:27.901281+00:00 + 2025-09-26T14:19:32.607455+00:00 + python-feedgen Brad Morrison 2024-01-04 13:50:51+00:00 @@ -107,43 +108,28 @@ - python-feedgen + 2 Combined summary - Future of the bitcoin-dev mailing list - 2024-01-06T02:06:27.901450+00:00 + 2025-09-26T14:19:32.607648+00:00 + 2024-01-04T13:50:51+00:00 The Linux Foundation's mailing lists, primarily running on an outdated Mailman version, necessitate migration or upgrade. Nostr is proposed as a replacement due to its decentralized nature, potentially through a custom Nostr Improvement Proposal (NIP) for relay functions. - Google Groups' interface is criticized for inefficiency and spam issues, prompting consideration of maintaining traditional mail servers. Nostr is endorsed for creating a versatile system with varied moderation policies across different frontends, as described in NIP 11. - Debate over email's role in public discourse has increased, particularly among Gmail users concerned about privacy and centralization. Email's decentralized attributes are valued, and a lightning anti-spam fee is suggested to encourage Lightning network adoption for Bitcoin developer communications. - Antoine praises the bitcoin-dev moderation team and recognizes Nostr's potential, endorsing temporary use of the Delving Bitcoin forum and suggesting other open-source platforms for reference. - Discussions include integrating P2P methods into email systems, broadcasting moderated content in blocks, and leveraging cryptographic signatures. Hashcash-based proof-of-work and Silent Payments are considered for anti-spam and security enhancements. - Nostr's limitations are acknowledged, yet enthusiasm persists for developing a relay system on it for mailing lists. Challenges in managing email servers versus nostr relays are compared, highlighting the ease of nostr maintenance and cryptographic advantages. - Running a personal mail server is suggested as a viable option for managing mailing lists, exemplified by https://lists.freebsd.org. Community members are open to setting up similar infrastructure for community projects. - The Bitcoin developer community leans towards adopting an alternative email service. Diverse communication channels, such as IRC, are valued, and the use of Discourse at Delvingbitcoin.org is noted for its technical discussion capabilities. - An innovative anti-spam measure proposes a fee for sending messages on a technical mailing list, possibly via the lightning network. Custom software development and integration with third-party hosting services are deemed possible with API access. - Issues with the nostr protocol, like single-key cryptography and mirroring relay problems, are highlighted. Peter Todd's insights are recommended for further exploration of these concerns. - It's stressed that GitHub should not replace mailing lists due to the importance of cryptographic signatures for message authenticity. GitHub Discussions offers robust tools but lacks clear support for email interactions. - Two solutions for the bitcoin-dev mailing list are proposed: finding a new host or replacing it altogether. The importance of a comprehensive archiving system is emphasized, considering accessibility and non-proprietary data formats. - Simple Machines Forum (SMF) is recommended for its strong anti-spam features and adaptability. Bryan Bishop acknowledges the usefulness of James O'Beirne's Git repository for archiving Delving Bitcoin discussions, and Blockchain Commons' use of GitHub discussions illustrates their practical application. - Concerns are raised about nostr's complexity and barriers to entry, favoring email for its universal accessibility. Matrix is introduced as a potential communication platform, with Synapse offering maintenance advantages. - Dan suggests Nostr for its resistance to mail server blocking and cost efficiency but notes missing features necessary for a smooth transition. Google Groups and groups.io are considered stable options for prioritizing email interfaces. - The bitcoin-dev mailing list is transitioning hosts after the Linux Foundation's decision to discontinue mailing list hosting. Public-inbox instances for decentralized archiving and enhanced moderator tools are recommended. The final decision on hosting will influence Bitcoin development coordination. - 2024-01-04T13:50:51+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_Introducing-a-version-field-to-BIP39-mnemonic-phrases.xml b/static/bitcoin-dev/Jan_2024/combined_Introducing-a-version-field-to-BIP39-mnemonic-phrases.xml index 279a6abed5..041682f6f8 100644 --- a/static/bitcoin-dev/Jan_2024/combined_Introducing-a-version-field-to-BIP39-mnemonic-phrases.xml +++ b/static/bitcoin-dev/Jan_2024/combined_Introducing-a-version-field-to-BIP39-mnemonic-phrases.xml @@ -1,45 +1,48 @@ - + 2 Combined summary - Introducing a version field to BIP39 mnemonic phrases - 2024-01-14T02:07:17.997315+00:00 - - Leslie 2024-01-13 17:06:31+00:00 - - - Pavol Rusnak 2024-01-13 16:31:35+00:00 - - - Leslie 2024-01-13 15:55:07+00:00 - - - Pavol Rusnak 2024-01-13 14:12:10+00:00 - - - Leslie 2024-01-10 14:28:29+00:00 - + 2025-09-26T14:19:28.344614+00:00 + python-feedgen + + + [bitcoin-dev] Introducing a version field to BIP39 mnemonic phrases Leslie + 2024-01-10T14:28:00.000Z + + + Pavol Rusnak + 2024-01-13T14:12:00.000Z + + + Leslie + 2024-01-13T15:55:00.000Z + + + Pavol Rusnak + 2024-01-13T16:31:00.000Z + + + Leslie + 2024-01-13T17:06:00.000Z + + - python-feedgen + 2 Combined summary - Introducing a version field to BIP39 mnemonic phrases - 2024-01-14T02:07:17.997395+00:00 + 2025-09-26T14:19:28.345434+00:00 + 2024-01-13T17:06:31+00:00 The discourse within the cryptocurrency community regarding the BIP39 mnemonic phrase standard reveals efforts to evolve its capabilities while maintaining backward compatibility. A new proposal suggests adding a version field to the mnemonic phrases, aiming to address the absence of such a feature in the current BIP39 implementation. This addition could enhance the robustness and flexibility of mnemonics, allowing for future improvements and ensuring compatibility with legacy systems. - The proposed version field includes a 24-bit general-purpose area and an 8-bit segment earmarked for the BIP39 standard version. This design seeks to preserve interoperability with existing applications and wallets that utilize BIP39, preventing potential conflicts. The versioned mnemonics would start with initial entropy akin to BIP39's methodology, followed by appending a 32-bit version field and a checksum calculated per the original protocol. These mnemonics would then be converted into word sequences using the established BIP39 wordlist. - Compatibility is at the forefront of this proposal, as systems unaware of the version extension should continue to recognize these phrases as 'Legacy' BIP39, thus retaining backwards functionality. Conversely, forward-thinking design aspects are embedded to accommodate prospective updates to the BIP39 standard. The discussion also touches on the possibility of integrating alternative methods for deriving entropy in the future, potentially moving away from the PBKDF2 key stretching algorithm currently in use. - Despite the push for evolution, there are cautions against fragmenting the ecosystem. Alternative standards like aezeed and Electrum V2 illustrate that the standard BIP39 entropy may not suffice for all applications, leading to the creation of distinct standards. However, the argument for versioned mnemonics is not intended to disrupt the core utility of BIP39 but to initiate a dialogue on how to advance without undermining its fundamental strengths. - Critics of the modification stress the importance of the original BIP39's design intent for maximum interoperability. Counterarguments highlight the risk of reduced cross-compatibility due to different implementations embracing disparate subsets of key stretching methods. Moreover, the introduction of versions encoding derivation paths is seen as potentially constraining, requiring users to manage multiple seeds for various applications, which could lead to poor backup practices. - To explore the details of the BIP39 standard and the versioned BIP39 proposal, interested parties can refer to the official Bitcoin Improvement Proposals documentation and the associated GitHub repository. - 2024-01-13T17:06:31+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_Lamport-scheme-not-signature-to-economize-on-L1.xml b/static/bitcoin-dev/Jan_2024/combined_Lamport-scheme-not-signature-to-economize-on-L1.xml index 08945fedad..9a14fa43de 100644 --- a/static/bitcoin-dev/Jan_2024/combined_Lamport-scheme-not-signature-to-economize-on-L1.xml +++ b/static/bitcoin-dev/Jan_2024/combined_Lamport-scheme-not-signature-to-economize-on-L1.xml @@ -1,68 +1,27 @@ - + 2 Combined summary - Lamport scheme (not signature) to economize on L1 - 2024-01-06T02:09:52.329538+00:00 - - yurisvb at pm.me 2024-01-05 18:22:44+00:00 - - - yurisvb at pm.me 2024-01-05 18:02:39+00:00 - - - David A. Harding 2024-01-01 18:57:13+00:00 - - - yurisvb at pm.me 2024-01-01 10:17:07+00:00 - - - David A. Harding 2023-12-31 19:33:24+00:00 - - - yurisvb at pm.me 2023-12-31 17:42:19+00:00 - - - yurisvb at pm.me 2023-12-29 00:30:30+00:00 - - - yurisvb at pm.me 2023-12-23 00:26:07+00:00 - - - yurisvb at pm.me 2023-12-22 15:32:38+00:00 - - - G. Andrew Stone 2023-12-22 04:52:08+00:00 - - - yurisvb at pm.me 2023-12-21 16:07:27+00:00 - - - Nagaev Boris 2023-12-20 21:33:56+00:00 - - - yurisvb at pm.me 2023-12-19 21:22:20+00:00 - - - Nagaev Boris 2023-12-19 17:08:40+00:00 - - - yurisvb at pm.me 2023-12-19 14:07:23+00:00 - - - Nagaev Boris 2023-12-19 00:45:45+00:00 - - - yurisvb at pm.me 2023-12-18 22:43:48+00:00 - - - Nagaev Boris 2023-12-18 16:45:15+00:00 - - - Sergio Demian Lerner 2023-12-18 12:29:48+00:00 - - - yurisvb at pm.me 2023-12-18 01:37:23+00:00 - + 2025-09-26T14:19:38.987527+00:00 + python-feedgen + + + yurisvb + 2024-01-01T10:17:00.000Z + + + David A. Harding + 2024-01-01T18:57:00.000Z + + + yurisvb + 2024-01-05T18:02:00.000Z + + + yurisvb + 2024-01-05T18:22:00.000Z + + @@ -83,41 +42,27 @@ - python-feedgen + 2 Combined summary - Lamport scheme (not signature) to economize on L1 - 2024-01-06T02:09:52.329686+00:00 + 2025-09-26T14:19:38.988206+00:00 + 2024-01-05T18:22:44+00:00 Recent updates to Bitcoin protocols have resulted in transaction authentication requiring only 36 bytes and dropping to 16 bytes for address reuse due to the Lamport scheme. A discussion on Twitter Spaces is scheduled to deliberate these changes. - Dave expresses skepticism about the benefits of reducing transaction sizes through new cryptographic elements, questioning whether such incremental savings warrant the potential risks and challenges in gaining community acceptance. - Another email suggests that while integrating a new scheme could fit within Bitcoin's existing framework, convincing miners and balancing the slowed validation process present significant hurdles, invoking the No-Free-Lunch Principle. - Research indicates signature serialization makes up 14-16% of a Bitcoin transaction size; thus, new signature schemes could reduce block space usage by a similar margin. However, practicality and costs of implementation via soft or hard fork are concerns. - A cryptographic protocol offering up to a 66% reduction in blockchain footprint has been developed, based on the difficulty of factorizing polynomials. This is documented on GitHub and is being prepared as a Bitcoin Improvement Proposal. - A correction was issued concerning the description of a function related to pre-image problems, now correctly mapping 'a valid LAMPPRI' to an address and signature format. Further details on entropy calculations are forthcoming. - The vulnerabilities of cryptographic schemes are under examination, with a focus on cryptanalysis and minimizing collision rates in hash functions. The possibility of a multi-use version of the scheme is considered to further decrease blockchain bloat. - Security concerns for a proposed change include implications for chain reorganizations and double-spending attacks, with fears it may increase the attack surface. Measures against rainbow-table attacks and nonces as salts are recommended, and reassessment of the adversarial model is promised. - Consensus emerges that hash functions should have digest sizes double their symmetric key size to prevent collision attacks. A 26% reduction in block space utilization is possible, but security may be compromised. - Further discussions involve optimizing 12-byte hashes instead of 14-byte ones for efficiency, broadcasting ECCPUB to mitigate LSIG miner risks, standardizing fingerprint to 128 bits, and considering Schnorr keys for maintaining security standards. - Comparing cryptographic schemes, Lamport leads to an 80-byte footprint versus Taproot's 96 bytes, with possible equal space requirements after additional Lamport space needs. Transaction timing simplification proposes fixing T2 at 48 hours after T0. - Lamport hashes use a lengthy hash of key fingerprints, with KDFs generating ECCPRI and ECCPUB derived from them, leading to Bitcoin addresses resistant to brute force. Transaction signing processes and mining fee structures are explained, focusing on the single-use economic model for Lamport transactions. - Security concerns include attackers broadcasting first bundles after cracking hashes and the need to break a second hashing layer. The weakest link principle illustrates system robustness, emphasizing the difficulty of breaking Lamport chains compared to double-spending attacks. - Schnorr signatures' compactness raises questions about their security effectiveness. Cryptographic protocol developments like MAVE signature scheme, MAVEPAY cryptocurrency, and FawkesCoin based on the Guy Fawkes Protocol are mentioned by R. M. Needham. - An enhancement for Layer 1 blockchain byte-efficiency combines the Lamport Scheme with a dual-key system, including a penalty payment system for unfulfilled commitments and suggesting Argon2 for potential 12-byte hashes, significantly reducing space from ECC signatures. - 2024-01-05T18:22:44+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_MuSig2-derivation-descriptor-and-PSBT-field-BIPs.xml b/static/bitcoin-dev/Jan_2024/combined_MuSig2-derivation-descriptor-and-PSBT-field-BIPs.xml index cbfbb50666..08c6fa2214 100644 --- a/static/bitcoin-dev/Jan_2024/combined_MuSig2-derivation-descriptor-and-PSBT-field-BIPs.xml +++ b/static/bitcoin-dev/Jan_2024/combined_MuSig2-derivation-descriptor-and-PSBT-field-BIPs.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - MuSig2 derivation, descriptor, and PSBT field BIPs - 2024-01-24T02:10:57.359215+00:00 - - Michael Folkson 2024-01-23 12:12:35+00:00 - - - Christopher Allen 2024-01-16 08:18:26+00:00 - - - Ava Chow 2024-01-15 23:29:46+00:00 - + 2025-09-26T14:19:47.505983+00:00 + python-feedgen + + + [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs Ava Chow + 2024-01-15T23:29:00.000Z + + + Christopher Allen + 2024-01-16T08:18:00.000Z + + + Michael Folkson + 2024-01-23T12:12:00.000Z + + - python-feedgen + 2 Combined summary - MuSig2 derivation, descriptor, and PSBT field BIPs - 2024-01-24T02:10:57.359261+00:00 + 2025-09-26T14:19:47.506520+00:00 + 2024-01-23T12:12:35+00:00 Tim Ruffing, a notable figure in the Bitcoin development community, has shed light on the complications associated with using x-only public keys in advanced cryptographic operations like MuSig2 and other multisignature schemes. During an online meetup of the London Bitcoin Devs in 2022, he addressed the engineering challenges posed by these keys. X-only pubkeys are efficient in that they save space by including only the x-coordinate of a public key, but this efficiency comes at a cost. When it comes to tweaking keys—a common practice in various cryptographic protocols including Taproot and MuSig2—the absence of the y-coordinate necessitates additional considerations during the engineering phase. These complexities can make specifications cumbersome and although not explicitly a security concern, they add a level of annoyance for developers. This leads to a retrospective debate over whether the trade-off between space savings and increased engineering complexity is justified. - Additionally, the Bitcoin Improvement Proposals (BIPs) related to MuSig2 have seen significant updates since their initial release in October. A new BIP dedicated to synthetic extended public keys was introduced due to its relevance beyond descriptors to PSBT fields. The Descriptors BIP itself has been relatively stable, with ongoing discussions about the potential removal of ranged derivation within expressions while keeping it for the overall aggregate public key. A major revision in the PSBT fields BIP is the representation of the aggregate public key as a plain public key rather than an 'xonly' key. This change facilitates the identification of derived keys in a PSBT by embedding the evenness bit into the serialized fingerprint. - The changes and their detailed explanations are available through GitHub links, inviting those with relevant expertise to review and contribute to the evolving landscape of Bitcoin's multisignature protocol specifications. Interested parties can find the Derivation BIP [here](https://github.com/achow101/bips/blob/musig2/bip-musig2-derivation.mediawiki), the Descriptors BIP [here](https://github.com/achow101/bips/blob/musig2/bip-musig2-descriptors.mediawiki), and the PSBT fields BIP [here](https://github.com/achow101/bips/blob/musig2/bip-musig2-psbt.mediawiki). These developments underscore the importance of collaborative effort and peer review in the continuous improvement of cryptographic standards within the Bitcoin ecosystem. - 2024-01-23T12:12:35+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_One-Shot-Replace-By-Fee-Rate.xml b/static/bitcoin-dev/Jan_2024/combined_One-Shot-Replace-By-Fee-Rate.xml index 6ec9ee82b7..3f0831a72e 100644 --- a/static/bitcoin-dev/Jan_2024/combined_One-Shot-Replace-By-Fee-Rate.xml +++ b/static/bitcoin-dev/Jan_2024/combined_One-Shot-Replace-By-Fee-Rate.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - One-Shot Replace-By-Fee-Rate - 2024-02-01T01:59:10.977057+00:00 - - Peter Todd 2024-01-31 08:40:12+00:00 - - - Murch 2024-01-28 17:27:06+00:00 - - - Peter Todd 2024-01-27 07:19:22+00:00 - - - Murch 2024-01-25 21:25:28+00:00 - - - Peter Todd 2024-01-24 04:44:14+00:00 - - - Peter Todd 2024-01-22 22:52:01+00:00 - - - Murch 2024-01-22 18:12:45+00:00 - - - Peter Todd 2024-01-18 18:23:39+00:00 - + 2025-09-26T14:19:49.653380+00:00 + python-feedgen + + + [bitcoin-dev] One-Shot Replace-By-Fee-Rate Peter Todd + 2024-01-18T18:23:00.000Z + + + Murch + 2024-01-22T18:12:00.000Z + + + Peter Todd + 2024-01-22T22:52:00.000Z + + + Peter Todd + 2024-01-24T04:44:00.000Z + + + Murch + 2024-01-25T21:25:00.000Z + + + Peter Todd + 2024-01-27T07:19:00.000Z + + + Murch + 2024-01-28T17:27:00.000Z + + + Peter Todd + 2024-01-31T08:40:00.000Z + + @@ -35,25 +46,19 @@ - python-feedgen + 2 Combined summary - One-Shot Replace-By-Fee-Rate - 2024-02-01T01:59:10.977128+00:00 + 2025-09-26T14:19:49.654392+00:00 + 2024-01-31T08:40:12+00:00 Developers have identified a potential flaw in the Bitcoin network's replace-by-fee (RBF) policy that might prioritize less profitable transactions for miners over more profitable ones due to a loophole. A new commit is proposed to enhance network integrity by rejecting replacements with unconfirmed inputs conflicting with multiple transactions, thereby preventing cycles of unconfirmed transactions. - A scenario was presented showing how four unique conflicts can be constructed with transaction series and confirmed inputs, possibly leading to infinite replacement cycles. The interaction between proposed and existing RBF rules could inadvertently enable these outcomes. An attack attempt revealed a discrepancy in expected versus actual mempool behavior, where replacing transactions must exceed the raw fee-rate of their direct conflicts. A script is available for replication of these findings. - Peter Todd has introduced a feature in his Libre Relay fork on [GitHub](https://github.com/petertodd/bitcoin/tree/libre-relay-v26.0) to refine the RBF mechanism. This includes doubling the required fee rate for replacements and a new service bit for node peering. The code is open for review and testing, with nodes already running it on mainnet and testnet. - Concerns about BIP-125 Rule 2 were raised, which does not prevent combining unconfirmed inputs from different replaced transactions. A draft fix on [GitHub](https://github.com/bitcoin/bitcoin/pull/26451) addresses this, requiring all unconfirmed inputs in a replacement transaction to come from the same replaced transaction. For educational materials on the topic, further communication should be directed to [petertodd.org](https://petertodd.org). - The One Shot Replace By Fee Rate (RBFr) proposal's effectiveness and drawbacks are being scrutinized. The proposal, found on Peter Todd's blog ([One Shot Replace By Fee Rate](https://petertodd.org/2024/one-shot-replace-by-fee-rate)), suggests prioritizing fee-rate over total fee to avoid transaction pinning attacks, but its integration may risk the network’s stability. - The One-Shot Replace-By-Fee-Rate policy is an alternative that focuses on fee-rate rather than absolute fee, aiming to resolve BIP-125 Rule 3 related issues and encouraging fair competition for block space. It requires new transactions to offer a substantially higher fee rate, ensuring top placement in the mempool and avoiding replacement if the existing transaction already has a mineable fee rate. - Research supported by Fulgur Ventures indicates that one-shot and pure replace-by-fee-rate policies are resilient against bandwidth exhaustion attacks, suggesting improvements in efficiency and security for the network and second-layer protocols. The research promotes transitioning to fee-rate-based transaction replacement methods, contributing insights into optimizing transaction management on the Bitcoin network. - 2024-01-31T08:40:12+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_Ordinal-Inscription-Size-Limits.xml b/static/bitcoin-dev/Jan_2024/combined_Ordinal-Inscription-Size-Limits.xml index 00dfcf94b7..8375b025a3 100644 --- a/static/bitcoin-dev/Jan_2024/combined_Ordinal-Inscription-Size-Limits.xml +++ b/static/bitcoin-dev/Jan_2024/combined_Ordinal-Inscription-Size-Limits.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Ordinal Inscription Size Limits - 2024-01-04T02:00:07.522616+00:00 - - Erik Aronesty 2024-01-03 13:05:42+00:00 - - - Brad Morrison 2024-01-03 09:11:58+00:00 - - - Erik Aronesty 2024-01-01 16:08:29+00:00 - - - Brad Morrison 2024-01-01 13:33:02+00:00 - - - Erik Aronesty 2023-12-30 09:58:41+00:00 - - - Nagaev Boris 2023-12-29 19:01:52+00:00 - - - Greg Tonoski 2023-12-29 12:27:42+00:00 - - - Aymeric Vitte 2023-02-07 12:17:24+00:00 - - - Erik Aronesty 2023-02-06 18:05:05+00:00 - - - Claus Ehrenberg 2023-02-06 17:31:45+00:00 - - - Erik Aronesty 2023-02-06 16:39:14+00:00 - - - Kostas Karasavvas 2023-02-04 14:25:58+00:00 - - - Melvin Carvalho 2023-02-03 19:56:16+00:00 - - - Erik Aronesty 2023-01-31 08:58:46+00:00 - - - Robert Dickinson 2023-01-29 10:34:54+00:00 - - - Aymeric Vitte 2023-01-28 16:47:46+00:00 - - - alicexbt 2023-01-28 10:58:12+00:00 - - - Robert Dickinson 2023-01-28 04:26:15+00:00 - - - Aymeric Vitte 2023-01-27 15:43:46+00:00 - - - Andrew Poelstra 2023-01-27 13:21:00+00:00 - - - rotmaxi 2023-01-27 12:58:49+00:00 - - - Robert Dickinson 2023-01-27 12:44:10+00:00 - + 2025-09-26T14:19:41.137231+00:00 + python-feedgen + + + [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson + 2023-01-27T12:44:00.000Z + + + rot13maxi + 2023-01-27T12:58:00.000Z + + + Andrew Poelstra + 2023-01-27T13:21:00.000Z + + + Aymeric Vitte + 2023-01-27T15:43:00.000Z + + + Robert Dickinson + 2023-01-28T04:26:00.000Z + + + alicexbt + 2023-01-28T10:58:00.000Z + + + Aymeric Vitte + 2023-01-28T16:47:00.000Z + + + Robert Dickinson + 2023-01-29T10:34:00.000Z + + + Erik Aronesty + 2023-01-31T08:58:00.000Z + + + Melvin Carvalho + 2023-02-03T19:56:00.000Z + + + Kostas Karasavvas + 2023-02-04T14:25:00.000Z + + + Erik Aronesty + 2023-02-06T16:39:00.000Z + + + Claus Ehrenberg + 2023-02-06T17:31:00.000Z + + + Erik Aronesty + 2023-02-06T18:05:00.000Z + + + Aymeric Vitte + 2023-02-07T12:17:00.000Z + + + Greg Tonoski + 2023-12-29T12:27:00.000Z + + + Nagaev Boris + 2023-12-29T19:01:00.000Z + + + Erik Aronesty + 2023-12-30T09:58:00.000Z + + + Brad Morrison + 2024-01-01T13:33:00.000Z + + + Erik Aronesty + 2024-01-01T16:08:00.000Z + + + Brad Morrison + 2024-01-03T09:11:00.000Z + + + Erik Aronesty + 2024-01-03T13:05:00.000Z + + @@ -91,29 +116,21 @@ - python-feedgen + 2 Combined summary - Ordinal Inscription Size Limits - 2024-01-04T02:00:07.522763+00:00 + 2025-09-26T14:19:41.139524+00:00 + 2024-01-03T13:05:42+00:00 The Bitcoin programming community is engaged in discussions focusing on blockchain scalability, transaction efficiency, and data storage. Scalability challenges stem not from block size but from the broadcasting and storing of transactions across network nodes. Alternatives like the Lightning Network and covenant technology are being explored to address these issues. - Comparisons with credit card payment systems highlight Bitcoin's higher transaction costs due to fees that control spam but also limit its use for payments. Proposals include increasing block size to lower fees and make Bitcoin more competitive. - Spam prevention via transaction fees is effective yet inconsistent; advanced methods like payment pools and tree payments have been suggested to improve this and can be found at [UTXOs Scaling](https://utxos.org/uses/scaling/). Innovative data storage within transactions using multisig and Taproot’s Merkle proofs is being debated, with suggestions for natural economic deterrents to discourage misuse. - Discussions on witness data storage involve concerns about storing 'toxic data' and proposals to limit data size or alter incentive structures. GitHub references such as [PR 28408](https://github.com/bitcoin/bitcoin/pull/28408) and [Issue 29146](https://github.com/bitcoin/bitcoin/issues/29146) indicate a broader dialogue on control mechanisms against unwanted data, including deprecating certain opcodes. - Storing NFT content as witness data poses risks regarding node storage capacity and disk usage. Suggestions include imposing size limits and alternative methods like extension blocks. Linking sats to real-world deeds is considered, however, storing actual property on the blockchain is seen as impractical. - -Robert Dickinson and Alicexbt contribute their perspectives on storage capacity and blockchain space management. Dickinson recommends premium charges for image storage, whereas Alicexbt advises capacity planning and proposes a "local bitcoin" system to avoid main chain storage congestion. - +Robert Dickinson and Alicexbt contribute their perspectives on storage capacity and blockchain space management. Dickinson recommends premium charges for image storage, whereas Alicexbt advises capacity planning and proposes a "local bitcoin" system to avoid main chain storage congestion. Amidst this technical debate, there is also discussion about the cultural and innovative uses of data storage, such as embedding images during festivals. However, there are calls for responsible usage and education to prevent negative consequences from arbitrary data storage. - Aymeric Vitte presents a vision for integrating Bitcoin into the NFT and 'web3' sphere. He suggests a centralized bitcoin-based NFT system for efficient referencing of low-value NFTs in transactions, contrasting with decentralized approaches. - The debate considers balancing innovation with the practicalities of Bitcoin’s infrastructure. Core developers face the challenge of addressing diverse opinions and the long-term effects of permitting unlimited data storage through witness data and ordinals, aiming to ensure Bitcoin's evolution remains robust and sustainable. - 2024-01-03T13:05:42+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_Swift-Activation-CTV.xml b/static/bitcoin-dev/Jan_2024/combined_Swift-Activation-CTV.xml index 7ac221cbec..fef477bf6e 100644 --- a/static/bitcoin-dev/Jan_2024/combined_Swift-Activation-CTV.xml +++ b/static/bitcoin-dev/Jan_2024/combined_Swift-Activation-CTV.xml @@ -1,50 +1,39 @@ - + 2 Combined summary - Swift Activation - CTV - 2024-01-04T02:10:09.560333+00:00 - - Anthony Towns 2024-01-03 08:36:02+00:00 - - - alicexbt 2024-01-02 16:43:22+00:00 - - - Ryan Breen 2024-01-02 16:24:06+00:00 - - - Erik Aronesty 2024-01-02 14:32:29+00:00 - - - Michael Folkson 2024-01-02 13:52:20+00:00 - - - Erik Aronesty 2024-01-01 17:11:24+00:00 - - - Michael Folkson 2024-01-01 16:37:35+00:00 - - - Michael Folkson 2023-12-30 13:54:04+00:00 - - - Erik Aronesty 2023-12-30 08:59:45+00:00 - - - Anthony Towns 2023-12-30 08:05:54+00:00 - - - alicexbt 2023-12-22 22:34:52+00:00 - - - alicexbt 2023-12-22 01:56:09+00:00 - - - Luke Dashjr 2023-12-22 01:05:12+00:00 - - - alicexbt 2023-12-20 01:44:58+00:00 - + 2025-09-26T14:19:45.367992+00:00 + python-feedgen + + + Michael Folkson + 2024-01-01T16:37:00.000Z + + + Erik Aronesty + 2024-01-01T17:11:00.000Z + + + Michael Folkson + 2024-01-02T13:52:00.000Z + + + Erik Aronesty + 2024-01-02T14:32:00.000Z + + + Ryan Breen + 2024-01-02T16:24:00.000Z + + + alicexbt + 2024-01-02T16:43:00.000Z + + + Anthony Towns + 2024-01-03T08:36:00.000Z + + @@ -59,25 +48,19 @@ - python-feedgen + 2 Combined summary - Swift Activation - CTV - 2024-01-04T02:10:09.560439+00:00 + 2025-09-26T14:19:45.368906+00:00 + 2024-01-03T08:36:02+00:00 The advancement of Bitcoin's protocol through CheckTemplateVerify (CTV) has sparked a debate among developers, highlighting both the feature's potential benefits and the challenges it presents. CTV is designed to provide functionalities similar to ANYONECANPAY, allowing for additional inputs to be attached. It has shown promise in projects such as James O'Beirne's vault prototype and Jeremy Rubin's Sapio smart contracting language, suggesting its use can enhance security through predefined spending conditions and improve layer-two solution efficiency. - However, safety concerns specifically related to CTV have not been adequately addressed in public discussions. The industry consensus leans towards broader agreement before implementing changes like CTV, considering Bitcoin's current scale and avoiding divisive outcomes. Educational resources are available on Michael Folkson's YouTube channel to aid in understanding these concepts. - Central to the debate is the technology's evaluation for Bitcoin integration, with covenants being emphasized for creating secure vaults. Despite practical applications on test networks, apprehensions remain about centralization risks and increased complexity compared to multi-signature protocols. The rush to activate covenants without wide consensus and the potential for a chain split are major concerns. APO is acknowledged for its design quality, but thoughts of its activation are deemed premature. - The process for consensus changes in Bitcoin demands careful scrutiny to ensure changes are widely understood and agreed upon. Critiques of CTV's initial goals suggest alternative methods might be preferable for achieving objectives like censorship resistance and financial autonomy. This suggests a cautious approach to evolving Bitcoin's transaction mechanisms and revisiting foundational principles. - Furthermore, while CTV could potentially elevate Bitcoin's scaling and privacy capabilities, its readiness for deployment is questioned. To promote further development and mainnet proof-of-concept implementations, bounties ranging from 0.01 BTC to 1 BTC have been offered on BIP Bounty, yet participation remains low. Misconceptions regarding TXHASH capabilities in relation to CTV need clarification, and the activation method and timeline are disputed, with some preferring a delayed activation. - There are calls for contributions to _reardencode_'s ongoing work to refine CTV, with discussions open on GitHub. The construction of a BIP 8 client with 'LOCKINONTIMEOUT' set to true, offering users an option, underpins the importance of community engagement. Luke, a community member, opposes what he sees as a deceptive proposal and suggests preparing countermeasures against miner-activated updates. - Updates to CTV activation parameters have been proposed, focusing on simplicity and practicality. With more PoCs available than during the Taproot upgrade, support for CTV seems to be growing. There is encouragement to build and run the specified client before January 1, 2024, to prevent delays that could push activation to 2028. These discussions highlight the importance of secure communication, as evidenced by the use of Proton Mail. - 2024-01-03T08:36:02+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2024/combined_V3-Transactions-are-still-vulnerable-to-significant-tx-pinning-griefing-attacks.xml b/static/bitcoin-dev/Jan_2024/combined_V3-Transactions-are-still-vulnerable-to-significant-tx-pinning-griefing-attacks.xml index a9b4162541..c4653073c8 100644 --- a/static/bitcoin-dev/Jan_2024/combined_V3-Transactions-are-still-vulnerable-to-significant-tx-pinning-griefing-attacks.xml +++ b/static/bitcoin-dev/Jan_2024/combined_V3-Transactions-are-still-vulnerable-to-significant-tx-pinning-griefing-attacks.xml @@ -1,32 +1,23 @@ - + 2 Combined summary - V3 Transactions are still vulnerable to significant tx pinning griefing attacks - 2024-01-03T02:14:28.371167+00:00 - - Peter Todd 2024-01-02 23:43:01+00:00 - - - Peter Todd 2024-01-02 23:18:11+00:00 - - - Gloria Zhao 2024-01-02 11:12:05+00:00 - - - Peter Todd 2023-12-20 21:11:28+00:00 - - - Greg Sanders 2023-12-20 20:16:25+00:00 - - - Peter Todd 2023-12-20 19:48:59+00:00 - - - Gloria Zhao 2023-12-20 19:13:22+00:00 - - - Peter Todd 2023-12-20 17:14:56+00:00 - + 2025-09-26T14:19:43.254038+00:00 + python-feedgen + + + Gloria Zhao + 2024-01-02T11:12:00.000Z + + + Peter Todd + 2024-01-02T23:18:00.000Z + + + Peter Todd + 2024-01-02T23:43:00.000Z + + @@ -35,27 +26,20 @@ - python-feedgen + 2 Combined summary - V3 Transactions are still vulnerable to significant tx pinning griefing attacks - 2024-01-03T02:14:28.371239+00:00 + 2025-09-26T14:19:43.254609+00:00 + 2024-01-02T23:43:01+00:00 The recent discourse among programmers has centered on the intricacies of Lightning Network transactions and their optimization. A key point of debate has been whether V3 transactions significantly improve upon the Lightning Network's existing security measures against transaction pinning. Analysis suggests that while V3 transactions aim to enhance the network by limiting transaction size to prevent pinning attacks, they may only offer marginal improvements over current protocols. - In regards to the frequency of force closes within the Lightning Network, recent data indicates that most channels are closed without any HTLCs outstanding. This finding suggests that the majority of force closures are of a more routine nature and not typically associated with contentious scenarios. Such information could inform future protocol developments, particularly those aimed at managing channel economics more efficiently. - Further discussions have shed light on the expected weights of commitment transactions, revealing that the size is smaller than previously calculated. For commitment transactions with no HTLC outputs, the size is approximately 162 virtual bytes (vB), expanding to 206vB with the inclusion of HTLCs. These figures contrast with the larger sizes often assumed in theoretical models and highlight the need for accurate data when considering protocol changes or optimizations. - An analysis of transaction pinning highlighted through a hypothetical scenario between two parties, Alice and Mallory, illustrates the cost implications of V3 versus non-V3 transactions. In this example, the additional fees an attacker can force upon a user are constrained by the rules of V3 transactions. The comparison shows that V3 transactions limit the potential damage significantly more than non-V3 transactions, thus reinforcing the intended security benefits of the newer protocol version. - Critiques have also been raised regarding the current implementation of anchor outputs in Lightning channels. Specifically, it has been suggested that the use of two anchor outputs is unnecessary and that a single output would suffice. This critique draws upon insights from prominent contributors in the cryptocurrency development community, who argue for more efficient use of anchors. - The limitations of Child Pays for Parent (CPFP) transactions within Bitcoin's protocol were also discussed, focusing on the static approach currently employed. The requirement for users to choose the CPFP layer size beforehand, which is arbitrarily set at 1 kilovirtualbyte, allows for a reasonable number of taproot inputs but lacks adaptability. Recognizing the need for a more dynamic solution, it is acknowledged that significant systemic changes would be necessary for such advancements. - -Lastly, the conversation touched upon the concept of "pinning potential" and the various factors influencing it, including the management of UTXOs and the value of commitment transactions. While the constraints under the current protocol are far from ideal, it is noted that the situation has improved considerably, offering better protection against pinning compared to previous iterations of the network. - +Lastly, the conversation touched upon the concept of "pinning potential" and the various factors influencing it, including the management of UTXOs and the value of commitment transactions. While the constraints under the current protocol are far from ideal, it is noted that the situation has improved considerably, offering better protection against pinning compared to previous iterations of the network. Overall, the discourse emphasizes the importance of continuous evaluation and refinement of transaction protocols within the Lightning Network and the Bitcoin ecosystem. Despite the advancements brought forth by V3 transactions, the consensus among developers is that there remains room for improvement in safeguarding against transaction pinning and optimizing network operations. - 2024-01-02T23:43:01+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_-FULL-DISCLOSURE-Replacement-Cycling-Attacks-on-Attacks-on-Bitcoin-Miners-Block-Templates.xml b/static/bitcoin-dev/Jan_2025/combined_-FULL-DISCLOSURE-Replacement-Cycling-Attacks-on-Attacks-on-Bitcoin-Miners-Block-Templates.xml index 91a25780e1..3f192a6b4c 100644 --- a/static/bitcoin-dev/Jan_2025/combined_-FULL-DISCLOSURE-Replacement-Cycling-Attacks-on-Attacks-on-Bitcoin-Miners-Block-Templates.xml +++ b/static/bitcoin-dev/Jan_2025/combined_-FULL-DISCLOSURE-Replacement-Cycling-Attacks-on-Attacks-on-Bitcoin-Miners-Block-Templates.xml @@ -1,35 +1,37 @@ - + 2 Combined summary - [FULL DISCLOSURE]: Replacement Cycling Attacks on Attacks on Bitcoin Miners Block Templates - 2025-01-28T02:17:21.900480+00:00 - - Antoine Riard 2025-01-27 23:01:00+00:00 - - - David A. Harding 2025-01-27 22:17:00+00:00 - - - Antoine Riard 2025-01-27 15:22:00+00:00 - + 2025-09-26T14:22:23.640249+00:00 + python-feedgen + + + [FULL DISCLOSURE]: Replacement Cycling Attacks on Attacks on Bitcoin Miners Block Templates Antoine Riard + 2025-01-27T15:22:00.000Z + + + David A. Harding + 2025-01-27T22:17:00.000Z + + + Antoine Riard + 2025-01-27T23:01:00.000Z + + - python-feedgen + 2 Combined summary - [FULL DISCLOSURE]: Replacement Cycling Attacks on Attacks on Bitcoin Miners Block Templates - 2025-01-28T02:17:21.900526+00:00 + 2025-09-26T14:22:23.640761+00:00 - The discussion revolves around a specific type of cyber attack targeting the Bitcoin network, known as "Transaction Traffic Hijack" or more technically, a variant of replacement cycling attacks. These attacks aim to manipulate Bitcoin's transaction flows, particularly exploiting the fee bump mechanism to hijack transaction traffic. While the paper attached to the email does not provide a quantitative analysis of the transactions affected, it highlights concerns regarding both the fee bump mechanism and potential vulnerabilities in UTXO-sharing flows. - + 2025-01-27T23:01:00+00:00 + The discussion revolves around a specific type of cyber attack targeting the Bitcoin network, known as "Transaction Traffic Hijack" or more technically, a variant of replacement cycling attacks. These attacks aim to manipulate Bitcoin's transaction flows, particularly exploiting the fee bump mechanism to hijack transaction traffic. While the paper attached to the email does not provide a quantitative analysis of the transactions affected, it highlights concerns regarding both the fee bump mechanism and potential vulnerabilities in UTXO-sharing flows. Dave further elucidates the mechanics of the attack in his query, outlining a scenario where an attacker, named Mallet, exploits the replace-by-fee (RBF) policy to financially benefit at the expense of other miners. This is done by preventing a bumped fee transaction from propagating through the network while ensuring it is mined by the attacker, thereby increasing their profits. - In a comprehensive disclosure, the author reveals the severity of replacement cycling attacks on the Bitcoin ecosystem, especially in a post-subsidy world. The attack exploits non-UTXO owned transaction traffic to manipulate miner's block templates, leading to an unfair distribution of Bitcoin fee rewards among miners. A series of tests conducted on both classic and cluster-based mempools demonstrate the practicality of these attacks. Further, the initial discovery relating to the vulnerability of Lightning channels to such attacks and subsequent mitigation efforts are detailed. - The author proposes several solutions to address these vulnerabilities, including the development of a cluster mempool to improve eviction and replacement algorithms, the implementation of a replace-by-feerate policy to increase attack costs, restrictions on transaction chain topologies to simplify mempool algorithm computations, and the enhancement of UTXO-based transaction announcements to safeguard against downgraded feerate branches. - Significantly, this discourse underpins the urgency for continuous scrutiny and adaptation of Bitcoin's protocol to thwart potential exploitations by adversarial entities. The highlighted tests and proposed solutions offer a starting point for further research and development towards enhancing Bitcoin’s security framework. The documentation and discussions surrounding these findings are made accessible through various GitHub repositories and papers, enriching the community's understanding of the evolving landscape of blockchain security challenges. - 2025-01-27T23:01:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_Call-for-reconfiguration-of-nodes-to-relay-transactions-with-fee-rates-below-1-sat-vbyte.xml b/static/bitcoin-dev/Jan_2025/combined_Call-for-reconfiguration-of-nodes-to-relay-transactions-with-fee-rates-below-1-sat-vbyte.xml index 0fb5289de3..3b99c14aac 100644 --- a/static/bitcoin-dev/Jan_2025/combined_Call-for-reconfiguration-of-nodes-to-relay-transactions-with-fee-rates-below-1-sat-vbyte.xml +++ b/static/bitcoin-dev/Jan_2025/combined_Call-for-reconfiguration-of-nodes-to-relay-transactions-with-fee-rates-below-1-sat-vbyte.xml @@ -1,47 +1,52 @@ - + 2 Combined summary - Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte - 2025-02-04T02:21:50.837876+00:00 - - Murch 2025-02-03 19:42:00+00:00 - - - Sjors Provoost 2025-01-31 15:13:00+00:00 - - - Sjors Provoost 2025-01-31 14:40:00+00:00 - - - Greg Tonoski 2025-01-31 13:43:00+00:00 - - - Sjors Provoost 2025-01-31 12:54:00+00:00 - - - Greg Tonoski 2025-01-31 08:49:00+00:00 - + 2025-09-26T14:22:25.751128+00:00 + python-feedgen + + + Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte Greg Tonoski + 2025-01-31T08:49:00.000Z + + + Sjors Provoost + 2025-01-31T12:54:00.000Z + + + Greg Tonoski + 2025-01-31T13:43:00.000Z + + + Sjors Provoost + 2025-01-31T14:40:00.000Z + + + Sjors Provoost + 2025-01-31T15:13:00.000Z + + + Murch + 2025-02-03T19:42:00.000Z + + - python-feedgen + 2 Combined summary - Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte - 2025-02-04T02:21:50.837940+00:00 + 2025-09-26T14:22:25.752005+00:00 + 2025-02-03T19:42:00+00:00 The recent discussions on the Bitcoin Development Mailing List have brought several key topics to light, particularly focusing on the optimization and management of system resources like bandwidth and CPU in the context of Bitcoin's operational efficiency. The conversation underscored the importance of these resources in maintaining the scalability, speed, and reliability of Bitcoin transactions and operations. It was elucidated that understanding the balance and consumption of bandwidth and CPU usage stands critical for developers striving to enhance Bitcoin's infrastructure. This dialogue signifies the ongoing efforts within the community to address and mitigate evolving challenges, ensuring the network's robustness. - Sjors Provoost introduced an insightful perspective on managing transaction fees on the network. He suggested the utilization of the `prioritisetransaction` RPC for selectively including low or zero-fee transactions in blocks, compensating through other means such as alternative payment networks. This approach underscores a nuanced understanding of transaction prioritization, extending beyond mere fee structures. Provoost also highlighted the significance of considering technical resources like bandwidth, memory, and CPU usage in transaction processing, which are vital for the network’s efficiency and cost-effectiveness. This discussion brings forth a broader view of blockchain economics, emphasizing the importance of optimizing various system resources alongside transaction fee structures to sustain network health and performance. - A consensus emerged around configuring `-incrementalrelayfee=0` to complement `minrelaytxfee=0.00000001`, challenging previous concerns over DoS attack risks due to low transaction fees. This is based on observations that miners might already operate with a `-blockmintxfee` set to `0` or lower, evidenced by zero-fee transactions in blocks. Furthermore, it was argued that Bitcoin's current operational parameters, including a default mempool size limit of 300MB and a timeout of 336 hours for unconfirmed transactions, effectively mitigate potential DoS attacks facilitated by low fee-rate transactions. These safeguards support the argument for potentially lowering transaction fees without compromising security. - In terms of transaction fee adjustments, a cautious approach was advised when setting `-incrementalrelayfee`, suggesting a minor increase from 0.001 satoshis per virtual byte to 0.002, requiring miner cooperation to avoid transactions stagnating in the mempool. This strategy acknowledges the risk of lowering the cost barrier for DoS attacks but also considers the changing landscape with the Lightning Network's introduction. The discussion acknowledged that maintaining somewhat elevated fee levels could deter new forms of economically viable attacks, highlighting the evolving considerations in the ecosystem regarding fee adjustments. - Lastly, there's an ongoing debate about adjusting the default minimum relay transaction fee, which has remained at 1 sat/vbyte since 2013. Given the significant increase in Bitcoin's value, there's a proposition to lower the `minrelaytxfee` to 0.00000001 or 0.001 sat/vbyte to facilitate transactions with lower fee rates, such as consolidation and multisig operations. This adjustment aims at improving the efficiency and accessibility of the Bitcoin network for a variety of operations, reflecting directly on node operation and configuration practices within the community. - 2025-02-03T19:42:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml b/static/bitcoin-dev/Jan_2025/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml index 68075756be..a434dd8b2d 100644 --- a/static/bitcoin-dev/Jan_2025/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml +++ b/static/bitcoin-dev/Jan_2025/combined_Mandatory-Inclusion-of-Old-Transactions-in-Blocks.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Mandatory Inclusion of Old Transactions in Blocks - 2025-01-10T02:25:45.035585+00:00 - - Jameson Lopp 2025-01-09 12:24:00+00:00 - - - developer 2024-12-29 16:35:00+00:00 - - - Ethan Heilman 2024-12-28 18:48:00+00:00 - - - Owen Kemeys 2024-12-28 16:23:00+00:00 - - - Luke Dashjr 2024-12-28 16:22:00+00:00 - - - developer 2024-12-28 16:15:00+00:00 - - - developer 2024-12-28 15:54:00+00:00 - + 2025-09-26T14:22:36.509021+00:00 + python-feedgen + + + developer + 2024-12-28T15:54:00.000Z + + + developer + 2024-12-28T16:15:00.000Z + + + Luke Dashjr + 2024-12-28T16:22:00.000Z + + + Owen Kemeys + 2024-12-28T16:23:00.000Z + + + Ethan Heilman + 2024-12-28T18:48:00.000Z + + + developer + 2024-12-29T16:35:00.000Z + + + Jameson Lopp + 2025-01-09T12:24:00.000Z + + @@ -31,19 +41,16 @@ - python-feedgen + 2 Combined summary - Mandatory Inclusion of Old Transactions in Blocks - 2025-01-10T02:25:45.035651+00:00 + 2025-09-26T14:22:36.509897+00:00 - The recent discussions on the Bitcoin Development Mailing List have sparked significant interest in the potential for adjusting the way transactions are processed and confirmed within the Bitcoin network. A major focus of these conversations has been on the utilization of the "nLockTime" feature, which traditionally is set to zero, suggesting its innovative application could enhance the protocol's resilience against control and censorship by indicating a transaction's readiness for immediate block inclusion. This proposal leverages legal and existing functionalities of the Bitcoin protocol, aiming to refine the transaction selection process currently based on fee rates. By introducing a dual sorting mechanism that considers both the transaction fee rate and "nLockTime," the proposal suggests older transactions with lower fees may have a better opportunity to get included in a block, potentially reducing mempool stagnation. - + 2025-01-09T12:24:00+00:00 + The recent discussions on the Bitcoin Development Mailing List have sparked significant interest in the potential for adjusting the way transactions are processed and confirmed within the Bitcoin network. A major focus of these conversations has been on the utilization of the "nLockTime" feature, which traditionally is set to zero, suggesting its innovative application could enhance the protocol's resilience against control and censorship by indicating a transaction's readiness for immediate block inclusion. This proposal leverages legal and existing functionalities of the Bitcoin protocol, aiming to refine the transaction selection process currently based on fee rates. By introducing a dual sorting mechanism that considers both the transaction fee rate and "nLockTime," the proposal suggests older transactions with lower fees may have a better opportunity to get included in a block, potentially reducing mempool stagnation. Further exploration into the technical challenges reveals concerns about achieving consensus on the oldest transactions, a key factor in advancing the proposal's practicality. The conversation acknowledges the complexity of this issue, mirroring the consensus process already inherent in Bitcoin but also highlights the necessity of further innovation before considering it mature enough for a formal Bitcoin Improvement Proposal (BIP). Critics of the proposed system argue it could lead to regular chainsplits due to discrepancies in transaction visibility across nodes, emphasizing the blockchain's reliance on mining to achieve consensus on transaction history. This critique underscores the fundamental challenges in altering the transaction confirmation process and the essential role of mining in maintaining the integrity of the blockchain. - A specific proposal discussed mandates Bitcoin miners to include a minimum percentage of the oldest transactions in their blocks, irrespective of the fee levels, aiming to combat mining centralization and censorship. The specification requires each miner to ensure their blocks contain at least 0.1% of transactions from the oldest in the mempool, promoting a democratic processing approach. This initiative addresses concerns over mining centralization and regulatory pressures that might influence transaction selection. By enforcing the inclusion of older, possibly lower-fee transactions, the proposal seeks to prevent exclusion based on fee size alone, enhancing the fairness and inclusivity of the transaction confirmation process. - The proposal outlines several anticipated benefits, including increased censorship resistance, promotion of decentralization by reducing centralized control over the network, and improvement in the mempool's dynamics by facilitating the confirmation of old and low-fee transactions. However, it also necessitates miners adjusting their resource management practices to identify and include these specified transactions automatically. Ultimately, the proposal advocates for a more equitable Bitcoin network, ensuring all transactions have a fair chance of being confirmed without bias towards higher fees, thereby maintaining the network's integrity and decentralization. - 2025-01-09T12:24:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml b/static/bitcoin-dev/Jan_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml index 1773738942..bc629f05f0 100644 --- a/static/bitcoin-dev/Jan_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml +++ b/static/bitcoin-dev/Jan_2025/combined_Reiterating-centralized-coinjoin-Wasabi-Samourai-deanonymization-attacks.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks - 2025-04-10T02:34:59.225767+00:00 - - Yuval Kogman 2025-04-09 02:16:00+00:00 - - - Javier Mateos 2025-04-07 10:01:00+00:00 - - - Yuval Kogman 2025-04-04 19:59:00+00:00 - - - Yuval Kogman 2025-04-04 17:58:00+00:00 - - - Peter Todd 2025-04-04 16:42:00+00:00 - - - Yuval Kogman 2025-02-13 15:42:00+00:00 - - - /dev /fd 2025-02-12 10:17:00+00:00 - - - Yuval Kogman 2025-02-07 20:07:00+00:00 - - - Peter Todd 2025-02-04 22:22:00+00:00 - - - Yuval Kogman 2025-02-04 14:02:00+00:00 - - - waxwing/ AdamISZ 2025-01-24 16:38:00+00:00 - - - Peter Todd 2025-01-24 16:00:00+00:00 - - - Peter Todd 2025-01-23 16:25:00+00:00 - - - Yuval Kogman 2025-01-07 21:33:00+00:00 - - - waxwing/ AdamISZ 2025-01-07 15:56:00+00:00 - - - Yuval Kogman 2025-01-06 14:30:00+00:00 - - - Sjors Provoost 2025-01-06 13:07:00+00:00 - - - Yuval Kogman 2024-12-21 14:16:00+00:00 - + 2025-09-26T14:22:30.091948+00:00 + python-feedgen + + + Yuval Kogman + 2024-12-21T14:16:00.000Z + + + Sjors Provoost + 2025-01-06T13:07:00.000Z + + + Yuval Kogman + 2025-01-06T14:30:00.000Z + + + waxwing/ AdamISZ + 2025-01-07T15:56:00.000Z + + + Yuval Kogman + 2025-01-07T21:33:00.000Z + + + Peter Todd + 2025-01-23T16:25:00.000Z + + + Peter Todd + 2025-01-24T16:00:00.000Z + + + waxwing/ AdamISZ + 2025-01-24T16:38:00.000Z + + + Yuval Kogman + 2025-02-04T14:02:00.000Z + + + Peter Todd + 2025-02-04T22:22:00.000Z + + + Yuval Kogman + 2025-02-07T20:07:00.000Z + + + /dev /fd0 + 2025-02-12T10:17:00.000Z + + + Yuval Kogman + 2025-02-13T15:42:00.000Z + + + Peter Todd + 2025-04-04T16:42:00.000Z + + + Yuval Kogman + 2025-04-04T17:58:00.000Z + + + Yuval Kogman + 2025-04-04T19:59:00.000Z + + + Javier Mateos + 2025-04-07T10:01:00.000Z + + + Yuval Kogman + 2025-04-09T02:16:00.000Z + + @@ -75,23 +96,18 @@ - python-feedgen + 2 Combined summary - Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks - 2025-04-10T02:34:59.225885+00:00 + 2025-09-26T14:22:30.094132+00:00 + 2025-04-09T02:16:00+00:00 The discourse within the Bitcoin development community highlights several critical insights and concerns surrounding privacy, trust, and transparency in the operation of coinjoin implementations such as Wasabi Wallet and Samourai Wallet. At the core of these discussions is the acknowledgment of inherent vulnerabilities and the complexity of ensuring user anonymity against sophisticated deanonymization techniques. The dialogue surfaces a pivotal tension between the theoretical promise of privacy-enhancing technologies and their practical implementation challenges. - A central theme in the conversation revolves around the limitations and potential weaknesses of coinjoin protocols. Specifically, criticisms target the coordinators' ability to undermine the privacy guarantees through manipulating transaction processes, a risk exacerbated by a lack of transparency and possible rent-seeking behaviors. These concerns are not merely theoretical but are grounded in detailed technical analyses that reveal how malicious actors could exploit protocol design flaws for deanonymization purposes. - For instance, the critique of Whirlpool's vulnerability centers on the process of blind signing keys, which could enable a coordinator to clandestinely link outputs to inputs, thereby breaching the protocol's privacy assurances. Similarly, WabiSabi faces scrutiny over its handling of key consistency, with the protocol's reliance on clients registering Bitcoin UTXOs independently underpinning a methodological flaw. This flaw could allow inconsistent round IDs to be issued to clients, facilitating partitioning attacks that compromise user anonymity. Despite efforts to address these and other issues, such as poor coin selection practices and the misuse of Tor circuits, the fundamental challenge of verifying and controlling the public keys used for proof verification persists. - Moreover, the discussions delve into the economic models embedded within these systems, particularly focusing on coordination fees and anonymous credential mechanisms. While intended to fairly compensate for transaction coordination, these structures have inadvertently fallen short of preventing the misappropriation of user funds, highlighting a significant gap in balancing privacy enhancement with financial security. - The critiques extend beyond specific protocols to encompass broader themes of ethical responsibility, transparency in development practices, and the imperative for rigorous auditing. The need for a comprehensive approach to security, one that includes both cryptographic and non-cryptographic elements of privacy-sensitive code, is emphasized as essential for maintaining user trust and integrity within the Bitcoin ecosystem. - In summary, the discussions reflect a multifaceted debate on the evolution of cryptocurrency protocols, underscoring the ongoing challenge of innovating privacy-enhancing technologies while safeguarding against exploitation. This dynamic interplay between innovation, security, and ethical considerations encapsulates the current state of discourse in the Bitcoin development community, pointing towards a future where these tensions must be continually navigated to advance the field responsibly. - 2025-04-09T02:16:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_Summary-Covenants-Support-Bitcoin-Wiki.xml b/static/bitcoin-dev/Jan_2025/combined_Summary-Covenants-Support-Bitcoin-Wiki.xml index 16481016c5..c6a98289ba 100644 --- a/static/bitcoin-dev/Jan_2025/combined_Summary-Covenants-Support-Bitcoin-Wiki.xml +++ b/static/bitcoin-dev/Jan_2025/combined_Summary-Covenants-Support-Bitcoin-Wiki.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - Summary: Covenants Support - Bitcoin Wiki - 2025-01-17T02:15:51.411061+00:00 - - moonsettler 2025-01-16 12:32:00+00:00 - - - /dev /fd 2025-01-14 14:14:00+00:00 - - - /dev /fd 2025-01-03 13:58:00+00:00 - - - moonsettler 2025-01-03 11:59:00+00:00 - - - /dev /fd 2025-01-02 15:16:00+00:00 - - - moonsettler 2025-01-02 13:40:00+00:00 - - - /dev /fd 2025-01-02 01:22:00+00:00 - - - Ethan Heilman 2025-01-01 18:11:00+00:00 - - - /dev /fd 2025-01-01 01:46:00+00:00 - - - moonsettler 2024-12-31 13:17:00+00:00 - - - /dev /fd 2024-12-31 08:23:00+00:00 - + 2025-09-26T14:22:34.360531+00:00 + python-feedgen + + + /dev /fd0 + 2024-12-31T08:23:00.000Z + + + moonsettler + 2024-12-31T13:17:00.000Z + + + /dev /fd0 + 2025-01-01T01:46:00.000Z + + + Ethan Heilman + 2025-01-01T18:11:00.000Z + + + /dev /fd0 + 2025-01-02T01:22:00.000Z + + + moonsettler' + 2025-01-02T13:40:00.000Z + + + /dev /fd0 + 2025-01-02T15:16:00.000Z + + + moonsettler' + 2025-01-03T11:59:00.000Z + + + /dev /fd0 + 2025-01-03T13:58:00.000Z + + + /dev /fd0 + 2025-01-14T14:14:00.000Z + + + moonsettler' + 2025-01-16T12:32:00.000Z + + @@ -47,23 +61,18 @@ - python-feedgen + 2 Combined summary - Summary: Covenants Support - Bitcoin Wiki - 2025-01-17T02:15:51.411143+00:00 + 2025-09-26T14:22:34.361410+00:00 + 2025-01-16T12:32:00+00:00 In the realm of Bitcoin development, a series of discussions and exchanges have unfolded on the Bitcoin Development Mailing List, revealing a vibrant collaborative effort aimed at refining and enhancing the functionality and efficiency of Bitcoin. A focal point of these discussions has been the evaluation and potential implementation of various proposals and opcodes designed to optimize Bitcoin contracts, including Resumeable LN channels, Multi-party LN channels, Vaults, and more. The discourse has highlighted significant improvements these enhancements could bring, emphasizing the importance of thoughtful evaluation and technical merit over popularity. - One notable debate centers around the introduction and comparison of specific opcodes, namely OP_CAT and OP_PAIRCOMMIT, with contributors examining their implications for the Lightning Network (LN) and broader Bitcoin script capabilities. Despite the technical support for OP_PAIRCOMMIT due to its simplicity and added functionality, there's an ongoing conversation about its necessity and the possible complexity it introduces compared to existing solutions. This dialogue underscores a collective pursuit of balancing expressiveness, functionality, and simplicity within the Bitcoin protocol, without compromising its principles or adding unnecessary complexity. - Contributors have also delved into the functionalities of INTERNALKEY and PAIRCOMMIT, clarifying their roles in enabling LN-Symmetry and contributing to efficiency improvements across various contract types. The reduction of signature operations (SigOps) required on-chain stands out as a key benefit, potentially offering economic advantages by streamlining validation processes. Such optimizations are met with both enthusiasm and critique, as participants weigh the trade-offs between innovation and the introduction of new complexities. - The communications reveal a dynamic and nuanced debate among developers regarding the best paths forward for Bitcoin's evolution. Suggestions for achieving consensus include the addition of more detailed rationales, participation in mailing list discussions, and organizing workshops, reflecting a commitment to a collaborative and inclusive decision-making process. This process is not only about advancing technical solutions but also about fostering a community-driven approach where diverse perspectives can contribute to the ecosystem's growth. - Moreover, the discourse extends beyond technical considerations to address the procedural aspects of proposal evaluation and activation client development. The notion that advancements should be guided by technical merit rather than popularity is reiterated, highlighting the importance of thorough analysis and community engagement in shaping Bitcoin's future. - In summary, the conversations captured in the Bitcoin Development Mailing List illustrate a dedicated effort to explore, critique, and refine proposals aimed at enhancing Bitcoin’s functionality. Through a combination of technical discussions, evaluations of new opcodes, and considerations of efficiency and complexity, the Bitcoin developer community continues to navigate the challenges and opportunities presented by the evolving landscape of cryptocurrency technology. - 2025-01-16T12:32:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_Transaction-expiration-should-be-based-on-the-most-recent-transaction-in-a-group-not-the-first.xml b/static/bitcoin-dev/Jan_2025/combined_Transaction-expiration-should-be-based-on-the-most-recent-transaction-in-a-group-not-the-first.xml index 69f2d17a51..8876b2c27d 100644 --- a/static/bitcoin-dev/Jan_2025/combined_Transaction-expiration-should-be-based-on-the-most-recent-transaction-in-a-group-not-the-first.xml +++ b/static/bitcoin-dev/Jan_2025/combined_Transaction-expiration-should-be-based-on-the-most-recent-transaction-in-a-group-not-the-first.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Transaction expiration should be based on the most recent transaction in a group, not the first - 2025-02-05T02:28:36.222707+00:00 - - Peter Todd 2025-02-04 21:39:00+00:00 - - - ArmchairCryptologist 2025-01-31 12:02:00+00:00 - - - Peter Todd 2025-01-28 22:25:00+00:00 - + 2025-09-26T14:22:40.771934+00:00 + python-feedgen + + + Transaction expiration should be based on the most recent transaction in a group, not the first Peter Todd + 2025-01-28T22:25:00.000Z + + + ArmchairCryptologist' + 2025-01-31T12:02:00.000Z + + + Peter Todd + 2025-02-04T21:39:00.000Z + + - python-feedgen + 2 Combined summary - Transaction expiration should be based on the most recent transaction in a group, not the first - 2025-02-05T02:28:36.222751+00:00 + 2025-09-26T14:22:40.772508+00:00 + 2025-02-04T21:39:00+00:00 The debate centers on the question of whether expiration-based mempool eviction is still relevant or beneficial within the Bitcoin network, highlighting a series of technical and philosophical concerns. Observations indicate that despite transactions lingering unconfirmed for extended periods, they are eventually processed without being exploited, prompting a reevaluation of the need for a mechanism that adds to computational and bandwidth overhead by repeatedly evicting and then re-accepting these transactions. The discussion points out the flawed reliance on unconfirmed transaction disappearance, exacerbated by the full implementation of Replace-By-Fee (RBF) policies, which contradicts any expectation of unconfirmed transactions vanishing permanently. The argument suggests that the practice might be redundant or counterproductive due to the mempool's limited capacity and proposes enhancing the `abandontransaction` function to allow targeted eviction from a node's local mempool. - Further critique is directed at Bitcoin Core's current approach to transaction expiration within the mempool, which involves removing transactions after a specified duration without considering their descendant transactions. This method is criticized for its inefficiency, particularly in scenarios involving Child Pays For Parent (CPFP), where users are willing to pay extra to prioritize an old transaction. Additionally, this approach poses potential vulnerabilities, such as facilitating free-relay Denial of Service (DoS) attacks and enabling transaction cycling attacks, which exploit the transaction expiration mechanism for network abuse. Despite these issues, the rationale behind transaction expiration focuses on mitigating risks associated with accepting non-mineable transactions due to soft-fork complications or other anomalies. However, the effectiveness of this rationale is questioned, considering that even months-old transactions are eventually mined, challenging the necessity of expiring them from the mempool. - The discussion extends to the broader implications of mempool management strategies on network efficiency, security vulnerabilities, and transaction longevity, emphasizing a need for a nuanced approach to managing mempool dynamics in light of evolving network behaviors and capabilities. Contributors like Peter Todd offer valuable insights into the complexities of blockchain technology and network management, providing a deeper understanding of the ongoing debates within the Bitcoin development community ([Peter Todd](https://petertodd.org)). - 2025-02-04T21:39:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml b/static/bitcoin-dev/Jan_2025/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml index e123d9d136..ac03c740e3 100644 --- a/static/bitcoin-dev/Jan_2025/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml +++ b/static/bitcoin-dev/Jan_2025/combined_Trivial-QC-signatures-with-clean-upgrade-path.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Trivial QC signatures with clean upgrade path - 2025-01-02T02:23:08.757612+00:00 - - Ian Quantum 2025-01-02 00:43:00+00:00 - - - David A. Harding 2025-01-01 08:38:00+00:00 - - - David A. Harding 2025-01-01 08:37:00+00:00 - - - Antoine Riard 2024-12-18 03:29:00+00:00 - - - conduition 2024-12-17 05:31:00+00:00 - - - Tadge Dryja 2024-12-16 22:20:00+00:00 - - - Matt Corallo 2024-12-16 15:57:00+00:00 - - - Anthony Towns 2024-12-16 11:14:00+00:00 - - - Matt Corallo 2024-12-16 01:40:00+00:00 - - - Weikeng Chen 2024-12-16 01:30:00+00:00 - - - Luke Dashjr 2024-12-15 23:54:00+00:00 - - - Matt Corallo 2024-12-15 21:42:00+00:00 - + 2025-09-26T14:22:27.904308+00:00 + python-feedgen + + + Trivial QC signatures with clean upgrade path Matt Corallo + 2024-12-15T21:42:00.000Z + + + Luke Dashjr + 2024-12-15T23:54:00.000Z + + + Weikeng Chen + 2024-12-16T01:30:00.000Z + + + Matt Corallo + 2024-12-16T01:40:00.000Z + + + Anthony Towns + 2024-12-16T11:14:00.000Z + + + Matt Corallo + 2024-12-16T15:57:00.000Z + + + Tadge Dryja + 2024-12-16T22:20:00.000Z + + + conduition' + 2024-12-17T05:31:00.000Z + + + Antoine Riard + 2024-12-18T03:29:00.000Z + + + David A. Harding + 2025-01-01T08:37:00.000Z + + + David A. Harding + 2025-01-01T08:38:00.000Z + + + Ian Quantum + 2025-01-02T00:43:00.000Z + + @@ -51,21 +66,17 @@ - python-feedgen + 2 Combined summary - Trivial QC signatures with clean upgrade path - 2025-01-02T02:23:08.757701+00:00 + 2025-09-26T14:22:27.905621+00:00 + 2025-01-02T00:43:00+00:00 The ongoing discussions among Bitcoin developers about enhancing the network's security against potential quantum computing threats have shed light on various innovative proposals and considerations. One focal point is the challenge posed by post-quantum cryptography (PQC) and its integration into the Bitcoin protocol to safeguard against quantum attacks that could compromise cryptographic standards currently in place. The discourse has evolved around several key ideas aimed at preempting these threats, highlighting the community's proactive stance towards ensuring the long-term resilience of Bitcoin. - A significant portion of the conversation revolves around the adoption of quantum-resistant cryptographic algorithms before the actualization of quantum computing capabilities that could threaten Bitcoin's security. Proposals such as integrating Winternitz one-time signature algorithms (WOTS) into wallets for a more flexible transition to PQC have been discussed. This approach allows for certification of public keys from future signature algorithms, providing a buffer period for research and development in the field. Moreover, there's an acknowledgment of the speculative nature of current quantum computing projections, emphasizing the need for adaptable solutions that can evolve with our understanding of quantum technology. - Another critical aspect discussed is the implementation of fallback mechanisms within Bitcoin's infrastructure to mitigate risks associated with quantum computing advancements. These include creating consensus-level proofs of quantum computer existence to trigger protective forks and developing output types immune to quantum decryption efforts. Such measures aim to provide a secure transition pathway that doesn't disrupt the underlying principles of blockchain technology while maintaining the integrity and continuity of the network amidst evolving threats. - Moreover, the dialogue touches upon the complexities involved in adjusting Bitcoin's foundational structures to accommodate post-quantum secure protocols. Suggestions for modifying public keys to incorporate post-quantum elements and the potential for new script opcodes offer insights into the technical hurdles and strategic decisions facing developers. Despite these challenges, the emphasis remains on finding balanced solutions that preemptively safeguard the network without necessitating immediate, drastic changes. - Throughout these exchanges, the importance of continuing innovation and adaptation in cryptocurrency security is evident. By exploring various cryptographic and strategic solutions, the Bitcoin development community demonstrates a commitment to securing the network against emerging technologies. The discussions underscore a collective effort to anticipate future threats and ensure the longevity of Bitcoin through careful planning, research, and consensus-building. - 2025-01-02T00:43:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_UTXO-checkpoint-transactions.xml b/static/bitcoin-dev/Jan_2025/combined_UTXO-checkpoint-transactions.xml index 1cb6bb6285..df7be47652 100644 --- a/static/bitcoin-dev/Jan_2025/combined_UTXO-checkpoint-transactions.xml +++ b/static/bitcoin-dev/Jan_2025/combined_UTXO-checkpoint-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - UTXO checkpoint transactions - 2025-01-29T02:17:32.604022+00:00 + 2025-09-26T14:22:38.659387+00:00 + python-feedgen Erik Aronesty 2025-01-28 17:34:00+00:00 @@ -15,17 +16,15 @@ - python-feedgen + 2 Combined summary - UTXO checkpoint transactions - 2025-01-29T02:17:32.604067+00:00 + 2025-09-26T14:22:38.659514+00:00 + 2025-01-28T17:34:00+00:00 In a recent discussion on the Bitcoin Development Mailing List, a novel proposal was introduced by Eric Voskuil regarding the potential implementation of UTXO checkpoint transactions within the Bitcoin network. The primary aim of this suggestion is to enhance the synchronization process for extremely lightweight nodes, which could significantly benefit from an expedited syncing mechanism without the need to rely heavily on traditional methods that demand considerable resources and time. - The proposed mechanism involves the submission of a unique transaction type that incorporates a substantial fee alongside a hash of the current UTXO (Unspent Transaction Output) set, paired with the block height as an opcode parameter. This design ensures that miners would only include such transactions in a block if the provided UTXO set hash accurately matches the current state, a process intended to safeguard against invalid submissions. However, due to the computational intensity required to generate these hashes, the proposition suggests assigning a high cost factor to these transactions, equating them to the processing weight of a 100KB transaction. - A critical aspect of this proposal is the introduction of a temporal threshold for the acceptance of checkpoints, advocating that only those checkpoints which are several months old should be considered valid for use. This stipulation aims to mitigate risks associated with more recent transactions and ensures that only sufficiently aged data is utilized for node synchronization purposes. The concept underlying this proposal seeks to furnish a solution tailored towards enhancing the efficiency and accessibility of blockchain technology for devices with limited processing capabilities, thereby broadening the scope of Bitcoin's usability and adoption. - 2025-01-28T17:34:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2025/combined_Who-uses-or-wants-to-use-PSBTv2-BIP370-.xml b/static/bitcoin-dev/Jan_2025/combined_Who-uses-or-wants-to-use-PSBTv2-BIP370-.xml index ac571ed14f..fac01a6eb5 100644 --- a/static/bitcoin-dev/Jan_2025/combined_Who-uses-or-wants-to-use-PSBTv2-BIP370-.xml +++ b/static/bitcoin-dev/Jan_2025/combined_Who-uses-or-wants-to-use-PSBTv2-BIP370-.xml @@ -1,47 +1,52 @@ - + 2 Combined summary - Who uses or wants to use PSBTv2 (BIP370) - 2025-01-18T02:15:42.874539+00:00 - - Andrew Toth 2025-01-17 14:53:00+00:00 - - - Salvatore Ingala 2025-01-17 13:02:00+00:00 - - - Kalle Rosenbaum 2025-01-17 10:38:00+00:00 - - - Kalle Rosenbaum 2025-01-17 10:01:00+00:00 - - - Sjors Provoost 2025-01-17 09:45:00+00:00 - - - Sjors Provoost 2025-01-17 09:16:00+00:00 - + 2025-09-26T14:22:32.209763+00:00 + python-feedgen + + + Who uses or wants to use PSBTv2 (BIP370) Sjors Provoost + 2025-01-17T09:16:00.000Z + + + Salvatore Ingala + 2025-01-17T09:45:00.000Z + + + Kalle Rosenbaum + 2025-01-17T10:01:00.000Z + + + Kalle Rosenbaum + 2025-01-17T10:38:00.000Z + + + Salvatore Ingala + 2025-01-17T13:02:00.000Z + + + Andrew Toth + 2025-01-17T14:53:00.000Z + + - python-feedgen + 2 Combined summary - Who uses or wants to use PSBTv2 (BIP370) - 2025-01-18T02:15:42.874602+00:00 + 2025-09-26T14:22:32.210593+00:00 + 2025-01-17T14:53:00+00:00 The recent exchanges on the Bitcoin Development Mailing List bring to light several key discussions and updates regarding the Partially Signed Bitcoin Transaction (PSBT) protocol, specifically its version 2 (PSBTv2). Notably, PSBTv2 is essential for implementing silent payments through BIP375 by employing the PSBT_OUT_SCRIPT field. Silent payments are a method where the output script of a transaction isn't known at the time of its creation, making PSBTv2 crucial since its predecessor, version 0, doesn't support creating an unsigned transaction without an output script. - Salvatore Ingala points out that the PSBT implementations within various Ledger client libraries are minimalistic, designed primarily for necessary communication protocols rather than as comprehensive solutions. This limitation indicates there's no plan to expand their functionality to be more general-purpose. Nonetheless, there might have been some confusion or outdated information regarding Ledger's implementation of PSBTv2, as Salvatore later suggests looking at a potentially more relevant version of the Ledger's PSBTv2 [here](https://github.com/LedgerHQ/app-bitcoin-new/blob/53dfd1727ab55182f9e365747b26b862e48b7b8b/bitcoin_client_js/src/lib/psbtv2.ts). - Another significant point raised in the discussions is the mention of BIP370, a proposal aimed at being a backward-compatible change to the original PSBT standard defined by BIP174. The primary advantage of BIP370 is its ability to add new inputs and outputs to a transaction, which is currently under review with Bitcoin Core pull request 21283. However, this pull request has received limited attention so far. Testing against other implementations could facilitate this review process. It's noted that Core Lightning has adopted PSBTv2, albeit with some inefficiencies as it needs to revert to v0 when interacting with Bitcoin Core, highlighting a gap between current utilization and potential optimization. - In addition, Andrew Toth’s contribution mentions Ledger's longstanding implementation of PSBTv2, used for facilitating communication between the Ledger Live software and hardware wallets, indicating an industry move towards broader adoption. This information is corroborated with a link to the specific implementation details found [here](https://github.com/LedgerHQ/ledger-live/blob/03b94dae50b1177801c57d9cee14cb5b4752b075/libs/ledgerjs/packages/hw-app-btc/src/newops/psbtv2.ts). - The ongoing discussion emphasizes the critical nature of PSBTv2 in advancing Bitcoin transaction capabilities, particularly in enhancing privacy through silent payments and improving transaction flexibility with BIP370. Despite these advancements, the dialogue also reveals areas requiring further development, such as the need for more comprehensive PSBT implementations and greater engagement with proposed enhancements like BIP370. - 2025-01-17T14:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_-BIP-proposal-Private-Payments.xml b/static/bitcoin-dev/July_2022/combined_-BIP-proposal-Private-Payments.xml index d7a530827b..f8b18ec517 100644 --- a/static/bitcoin-dev/July_2022/combined_-BIP-proposal-Private-Payments.xml +++ b/static/bitcoin-dev/July_2022/combined_-BIP-proposal-Private-Payments.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - [BIP proposal] Private Payments - 2023-08-02T06:52:59.917948+00:00 - - Alfred Hodler 2022-07-11 10:28:40+00:00 - - - Alfred Hodler 2022-07-05 09:38:44+00:00 - - - Christopher Allen 2022-07-01 17:37:57+00:00 - - - Alfred Hodler 2022-07-01 12:41:45+00:00 - - - Clark Moody 2022-06-29 22:33:26+00:00 - - - Peter Todd 2022-06-28 23:33:45+00:00 - - - Alfred Hodler 2022-06-28 12:40:10+00:00 - - - Alfred Hodler 2022-06-28 12:35:31+00:00 - - - Ruben Somsen 2022-06-27 20:35:34+00:00 - - - Ruben Somsen 2022-06-27 20:30:39+00:00 - - - Bryan Bishop 2022-06-27 20:20:45+00:00 - - - Alfred Hodler 2022-06-27 18:17:16+00:00 - + 2025-09-26T14:24:27.705588+00:00 + python-feedgen + + + [bitcoin-dev] [BIP proposal] Private Payments Alfred Hodler + 2022-06-27T18:17:00.000Z + + + Bryan Bishop + 2022-06-27T20:20:00.000Z + + + Ruben Somsen + 2022-06-27T20:30:00.000Z + + + Ruben Somsen + 2022-06-27T20:35:00.000Z + + + Alfred Hodler + 2022-06-28T12:35:00.000Z + + + Alfred Hodler + 2022-06-28T12:40:00.000Z + + + Peter Todd + 2022-06-28T23:33:00.000Z + + + Clark Moody + 2022-06-29T22:33:00.000Z + + + Alfred Hodler + 2022-07-01T12:41:00.000Z + + + Christopher Allen + 2022-07-01T17:37:00.000Z + + + Alfred Hodler + 2022-07-05T09:38:00.000Z + + + Alfred Hodler + 2022-07-11T10:28:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - [BIP proposal] Private Payments - 2023-08-02T06:52:59.917948+00:00 + 2025-09-26T14:24:27.706919+00:00 - In an update to a previous specification, it has been decided that Bob does not need to watch all address types he's advertising. Instead, when notifying him, Alice will pick one address type out of the ones Bob is advertising and include it in the notification. The new payload has been extended to 73 bytes and defined as `BIPXXXX + notification + N_Alice + address_type`. Previously, the spec had stated that Alice should construct a 72-byte OP_RETURN output whose value would be set to `BIPXXXX + notification + N_Alice`. Damian James Williamson questioned the legibility of the blockchain and the fungibility of UTXOs in a proposal. KING JAMES HRMH replied, stating that the blockchain must be legible for it to be an indelible record, and that Bitcoin is only fungible because it uses the blockchain. The email also included contact information for Damian's company, Willtech, as well as links to their website, duigco.org, and other projects.A proposal to use bech32 instead of base58 for more compact QR codes has been agreed upon. Base64 is a big offender as it not only does not auto-compress, but also triggers binary mode that almost doubles the size of the QR. The Blockchain Commons offers other Airgap QR and TorGap UR efforts, including NFC encrypted Airgap & crypto-request/response flows.The conversation between Clark and Alfred discussed the proposal to use bech32 instead of base58 for more compact QR codes. They both agreed that it is a good proposal. They also discussed the possibility of a third-party service offering to publish OP_RETURN notification payloads in the blockchain for a fee without linking the notifier's identity to their wallet. Another alternative discussed was publishing the block height along with the notification data contained within that block.A new payment code standard proposal is being put forward that builds on the idea of payment codes under a new BIP with some principal differences. The proposed standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist, but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process.In a recent bitcoin-dev thread, there was a discussion around the mechanism to demand that a notification transaction meets some minimum miner fee. However, it was pointed out that this mechanism is not safe against miners as they can pay themselves arbitrarily high fees with no downside. One suggestion made was that the spammer has to publish at all. Another suggestion put forward was to do a timelocked sacrifice with OP_CSV.Bryan suggested using Tor hidden service to publish instead of using OP_RETURN while keeping the details of the transaction off-chain. Alfred pointed out that this method is an off-chain solution and it won't work in an offline regime. He also mentioned that Tor keys can be derived from master keys, but this approach isn't much different from Bitmessage notifications in BIP47.The participants discussed the potential issues that may arise if the number of standard scripts increases significantly. One concern is that wallets will have to watch all of them, which could create a performance hit. Additionally, some wallets may not support certain scripts, leading to confusion when sending funds. One proposed solution is to use Taproot-only, but there are concerns about locking down the BIP to a single script type for future proofing. Instead, participants suggest using address type flags to solve these issues at the expense of having a couple of extra bytes.In a discussion on the bitcoin-dev mailing list, Bryan Bishop suggested an alternative to using OP_RETURN in notification transactions for private payments. He proposed publishing the data on a Tor hidden service that other wallets can check. Ruben Santamarta pointed out that the data on-chain is critical to accessing funds and guaranteeing their availability when restoring from backup.Alfred Hodler proposed a way to make notification transactions more private. He suggests that notification transactions will no longer leave a footprint on the blockchain and instead, will just be a single OP_RETURN containing a value that only Alice and Bob can calculate. Bryan suggested an alternative way to maintain privacy while making notification transactions. He suggested that instead of using OP_RETURN, Alice could publish on a Tor hidden service that other wallets check.The BIP47 standard for creating static payment codes suffered from several issues. The new proposed standard that builds on the idea of payment codes under a new BIP has several principal differences. The new standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process. 2022-07-11T10:28:40+00:00 + In an update to a previous specification, it has been decided that Bob does not need to watch all address types he's advertising. Instead, when notifying him, Alice will pick one address type out of the ones Bob is advertising and include it in the notification. The new payload has been extended to 73 bytes and defined as `BIPXXXX + notification + N_Alice + address_type`. Previously, the spec had stated that Alice should construct a 72-byte OP_RETURN output whose value would be set to `BIPXXXX + notification + N_Alice`. Damian James Williamson questioned the legibility of the blockchain and the fungibility of UTXOs in a proposal. KING JAMES HRMH replied, stating that the blockchain must be legible for it to be an indelible record, and that Bitcoin is only fungible because it uses the blockchain. The email also included contact information for Damian's company, Willtech, as well as links to their website, duigco.org, and other projects.A proposal to use bech32 instead of base58 for more compact QR codes has been agreed upon. Base64 is a big offender as it not only does not auto-compress, but also triggers binary mode that almost doubles the size of the QR. The Blockchain Commons offers other Airgap QR and TorGap UR efforts, including NFC encrypted Airgap & crypto-request/response flows.The conversation between Clark and Alfred discussed the proposal to use bech32 instead of base58 for more compact QR codes. They both agreed that it is a good proposal. They also discussed the possibility of a third-party service offering to publish OP_RETURN notification payloads in the blockchain for a fee without linking the notifier's identity to their wallet. Another alternative discussed was publishing the block height along with the notification data contained within that block.A new payment code standard proposal is being put forward that builds on the idea of payment codes under a new BIP with some principal differences. The proposed standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist, but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process.In a recent bitcoin-dev thread, there was a discussion around the mechanism to demand that a notification transaction meets some minimum miner fee. However, it was pointed out that this mechanism is not safe against miners as they can pay themselves arbitrarily high fees with no downside. One suggestion made was that the spammer has to publish at all. Another suggestion put forward was to do a timelocked sacrifice with OP_CSV.Bryan suggested using Tor hidden service to publish instead of using OP_RETURN while keeping the details of the transaction off-chain. Alfred pointed out that this method is an off-chain solution and it won't work in an offline regime. He also mentioned that Tor keys can be derived from master keys, but this approach isn't much different from Bitmessage notifications in BIP47.The participants discussed the potential issues that may arise if the number of standard scripts increases significantly. One concern is that wallets will have to watch all of them, which could create a performance hit. Additionally, some wallets may not support certain scripts, leading to confusion when sending funds. One proposed solution is to use Taproot-only, but there are concerns about locking down the BIP to a single script type for future proofing. Instead, participants suggest using address type flags to solve these issues at the expense of having a couple of extra bytes.In a discussion on the bitcoin-dev mailing list, Bryan Bishop suggested an alternative to using OP_RETURN in notification transactions for private payments. He proposed publishing the data on a Tor hidden service that other wallets can check. Ruben Santamarta pointed out that the data on-chain is critical to accessing funds and guaranteeing their availability when restoring from backup.Alfred Hodler proposed a way to make notification transactions more private. He suggests that notification transactions will no longer leave a footprint on the blockchain and instead, will just be a single OP_RETURN containing a value that only Alice and Bob can calculate. Bryan suggested an alternative way to maintain privacy while making notification transactions. He suggested that instead of using OP_RETURN, Alice could publish on a Tor hidden service that other wallets check.The BIP47 standard for creating static payment codes suffered from several issues. The new proposed standard that builds on the idea of payment codes under a new BIP has several principal differences. The new standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Adding-SIGHASH-to-TXID.xml b/static/bitcoin-dev/July_2022/combined_Adding-SIGHASH-to-TXID.xml index 69282b8ef5..1437d1c361 100644 --- a/static/bitcoin-dev/July_2022/combined_Adding-SIGHASH-to-TXID.xml +++ b/static/bitcoin-dev/July_2022/combined_Adding-SIGHASH-to-TXID.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Adding SIGHASH to TXID - 2023-08-02T06:28:20.828027+00:00 - - vjudeu at gazeta.pl 2022-07-03 05:45:48+00:00 - - - Jeremy Rubin 2022-05-07 11:55:35+00:00 - - - vjudeu at gazeta.pl 2022-05-07 04:50:12+00:00 - + 2025-09-26T14:24:23.358130+00:00 + python-feedgen + + + [bitcoin-dev] Adding SIGHASH to TXID vjudeu + 2022-05-07T04:50:00.000Z + + + Jeremy Rubin + 2022-05-07T11:55:00.000Z + + + vjudeu + 2022-07-03T05:45:00.000Z + + - python-feedgen + 2 Combined summary - Adding SIGHASH to TXID - 2023-08-02T06:28:20.828027+00:00 + 2025-09-26T14:24:23.358686+00:00 - In a Bitcoin-dev mailing list, there is a proposal being discussed to control transaction flow by introducing new SIGHASH flags. The proposal suggests using these flags to apply sighashes to the previous transaction and create a stable txid, even if new inputs and outputs are added. This would allow for better control over transaction flow when using different sighashes like SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Currently, the Core client signs everything with SIGHASH_ALL by default, but the proposal suggests changing this behavior and proposing different sighashes based on the created transaction.The proposal also suggests displaying the transaction in a way that is visible in block explorers. Inputs and outputs would be highlighted or grayed out based on the selected sighashes, making it easier for users to control them. This would provide users with more control over the flow of transactions and ensure the stability of the txid.Another proposal made by John Law on the bitcoin-dev mailing list suggests using new sighash flags to calculate a transaction ID (txid) and have more control over the input and output of transactions. Currently, txid:vout is used as a previous transaction output to prevent modifications. However, with the introduction of SIGHASH_PREVOUT_XYZ flags, it would be possible to use different types of sighashes to commit to specific fields of the previous transaction output.For example, using SIGHASH_PREVOUT_SINGLE would allow the addition of new outputs to the previous transaction without affecting the replaced txid. On the other hand, using SIGHASH_PREVOUT_NONE would not check any outputs of the previous transaction but would still check the inputs. By applying sighashes to the previous transaction, instead of allowing for any transaction, there would be more control over the txid, ensuring that signatures sign what is intended and are not invalidated by changes unrelated to the currently-checked signature.The proposal suggests defaulting to SIGHASH_PREVOUT_ALL, but the three SIGHASH_PREVOUT_XYZ flags could also be combined with SIGHASH_PREVOUT_ANYONECANPAY to discard all inputs except for the input number matching "vout". Overall, the proposal aims to provide better control over the flow of transactions and ensure the stability of the txid.In summary, the use of SIGHASH_PREVOUT_XYZ flags would allow for greater control over transaction flow and create a stable txid. By applying sighashes to the previous transaction, users can ensure that signatures sign what is intended and prevent invalidation due to changes in unrelated inputs and outputs. The proposal suggests defaulting to SIGHASH_PREVOUT_ALL but also provides options for different combinations of flags to achieve specific control over transactions. 2022-07-03T05:45:48+00:00 + In a Bitcoin-dev mailing list, there is a proposal being discussed to control transaction flow by introducing new SIGHASH flags. The proposal suggests using these flags to apply sighashes to the previous transaction and create a stable txid, even if new inputs and outputs are added. This would allow for better control over transaction flow when using different sighashes like SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Currently, the Core client signs everything with SIGHASH_ALL by default, but the proposal suggests changing this behavior and proposing different sighashes based on the created transaction.The proposal also suggests displaying the transaction in a way that is visible in block explorers. Inputs and outputs would be highlighted or grayed out based on the selected sighashes, making it easier for users to control them. This would provide users with more control over the flow of transactions and ensure the stability of the txid.Another proposal made by John Law on the bitcoin-dev mailing list suggests using new sighash flags to calculate a transaction ID (txid) and have more control over the input and output of transactions. Currently, txid:vout is used as a previous transaction output to prevent modifications. However, with the introduction of SIGHASH_PREVOUT_XYZ flags, it would be possible to use different types of sighashes to commit to specific fields of the previous transaction output.For example, using SIGHASH_PREVOUT_SINGLE would allow the addition of new outputs to the previous transaction without affecting the replaced txid. On the other hand, using SIGHASH_PREVOUT_NONE would not check any outputs of the previous transaction but would still check the inputs. By applying sighashes to the previous transaction, instead of allowing for any transaction, there would be more control over the txid, ensuring that signatures sign what is intended and are not invalidated by changes unrelated to the currently-checked signature.The proposal suggests defaulting to SIGHASH_PREVOUT_ALL, but the three SIGHASH_PREVOUT_XYZ flags could also be combined with SIGHASH_PREVOUT_ANYONECANPAY to discard all inputs except for the input number matching "vout". Overall, the proposal aims to provide better control over the flow of transactions and ensure the stability of the txid.In summary, the use of SIGHASH_PREVOUT_XYZ flags would allow for greater control over transaction flow and create a stable txid. By applying sighashes to the previous transaction, users can ensure that signatures sign what is intended and prevent invalidation due to changes in unrelated inputs and outputs. The proposal suggests defaulting to SIGHASH_PREVOUT_ALL but also provides options for different combinations of flags to achieve specific control over transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_BGP-hijacking-on-Bitcoin-p2p-network.xml b/static/bitcoin-dev/July_2022/combined_BGP-hijacking-on-Bitcoin-p2p-network.xml index 2b8fedd289..3cf6b05f94 100644 --- a/static/bitcoin-dev/July_2022/combined_BGP-hijacking-on-Bitcoin-p2p-network.xml +++ b/static/bitcoin-dev/July_2022/combined_BGP-hijacking-on-Bitcoin-p2p-network.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BGP hijacking on Bitcoin p2p network - 2023-08-02T06:46:57.112983+00:00 - - alicexbt 2022-07-05 20:30:24+00:00 - - - Elias Rohrer 2022-06-10 06:44:05+00:00 - - - alicexbt 2022-06-09 18:24:03+00:00 - + 2025-09-26T14:24:21.246956+00:00 + python-feedgen + + + [bitcoin-dev] BGP hijacking on Bitcoin p2p network alicexbt + 2022-06-09T18:24:00.000Z + + + Elias Rohrer + 2022-06-10T06:44:00.000Z + + + alicexbt + 2022-07-05T20:30:00.000Z + + - python-feedgen + 2 Combined summary - BGP hijacking on Bitcoin p2p network - 2023-08-02T06:46:57.112983+00:00 + 2025-09-26T14:24:21.247616+00:00 - Alicexbt, a member of the Bitcoin Development mailing list, has raised concerns about BGP hijacking attacks on bitcoin nodes. This vulnerability was noted in a 2014 answer on Stack Exchange. To learn more about the topic, Alicexbt searched for research articles and found works by Maria Apostolaki et al., Muoi Tran et al., and related works. They also shared links to blog posts about the March 2022 Twitter prefix hijacking incident and the Tor network's vulnerability to BGP hijacking.After conducting further research, Alicexbt discovered that RPKI ROA and BGP prefix length could help prevent BGP hijacking attacks. In an effort to address these vulnerabilities, Alicexbt is working on a Chrome extension that connects to local bitcoin core and checks the IP address of all peers for prefix length and other attributes. The extension will highlight peers with different colors based on certain criteria.However, when running tests on the first 10 IP addresses returned in `getnodeaddresses` for Bitcoin Core, vulnerable results were obtained. In response to this, Elias recommended research articles by Maria Apostolaki et al., Muoi Tran et al., and related works that delve into routing attacks.Desiring to contribute to the community's understanding and defense against BGP hijacking attacks, Alicexbt expressed interest in writing a detailed blog post or research article on the subject. They are seeking technical feedback and links to past discussions with potential solutions.In addition to bitcoin nodes, other networks such as Twitter and the Tor network have also experienced BGP hijacking incidents. The Twitter prefix hijacking incident in March 2022 was detailed in blog posts by ISC Sans and MANRS. The vulnerability of the Tor network to BGP hijacking was discussed in an article by 'nusenu'.To mitigate these attacks, it is suggested that implementing RPKI ROA and considering BGP prefix length can be effective. However, further research and discussions are needed to fully address the vulnerabilities. Alicexbt's goal is to contribute to this effort by writing a comprehensive article or blog post in the near future. 2022-07-05T20:30:24+00:00 + Alicexbt, a member of the Bitcoin Development mailing list, has raised concerns about BGP hijacking attacks on bitcoin nodes. This vulnerability was noted in a 2014 answer on Stack Exchange. To learn more about the topic, Alicexbt searched for research articles and found works by Maria Apostolaki et al., Muoi Tran et al., and related works. They also shared links to blog posts about the March 2022 Twitter prefix hijacking incident and the Tor network's vulnerability to BGP hijacking.After conducting further research, Alicexbt discovered that RPKI ROA and BGP prefix length could help prevent BGP hijacking attacks. In an effort to address these vulnerabilities, Alicexbt is working on a Chrome extension that connects to local bitcoin core and checks the IP address of all peers for prefix length and other attributes. The extension will highlight peers with different colors based on certain criteria.However, when running tests on the first 10 IP addresses returned in `getnodeaddresses` for Bitcoin Core, vulnerable results were obtained. In response to this, Elias recommended research articles by Maria Apostolaki et al., Muoi Tran et al., and related works that delve into routing attacks.Desiring to contribute to the community's understanding and defense against BGP hijacking attacks, Alicexbt expressed interest in writing a detailed blog post or research article on the subject. They are seeking technical feedback and links to past discussions with potential solutions.In addition to bitcoin nodes, other networks such as Twitter and the Tor network have also experienced BGP hijacking incidents. The Twitter prefix hijacking incident in March 2022 was detailed in blog posts by ISC Sans and MANRS. The vulnerability of the Tor network to BGP hijacking was discussed in an article by 'nusenu'.To mitigate these attacks, it is suggested that implementing RPKI ROA and considering BGP prefix length can be effective. However, further research and discussions are needed to fully address the vulnerabilities. Alicexbt's goal is to contribute to this effort by writing a comprehensive article or blog post in the near future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml b/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml index b99a7e90b6..5757df4165 100644 --- a/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml +++ b/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2023-08-02T07:12:45.744421+00:00 + 2025-09-26T14:24:36.235325+00:00 + python-feedgen Dmitry Petukhov 2022-08-04 07:09:33+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2023-08-02T07:12:45.744421+00:00 + 2025-09-26T14:24:36.235467+00:00 - A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. The proposal uses tuples of 2022-08-04T07:09:33+00:00 + A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. The proposal uses tuples of - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_BIP-draft-Half-Aggregation-of-BIP-340-Signatures.xml b/static/bitcoin-dev/July_2022/combined_BIP-draft-Half-Aggregation-of-BIP-340-Signatures.xml index 2dd9474909..0b8b3cd731 100644 --- a/static/bitcoin-dev/July_2022/combined_BIP-draft-Half-Aggregation-of-BIP-340-Signatures.xml +++ b/static/bitcoin-dev/July_2022/combined_BIP-draft-Half-Aggregation-of-BIP-340-Signatures.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - BIP draft: Half-Aggregation of BIP-340 Signatures - 2023-08-02T06:54:19.989189+00:00 - - Michael Folkson 2022-07-20 11:16:40+00:00 - - - Jonas Nick 2022-07-17 20:48:11+00:00 - - - Michael Folkson 2022-07-17 13:26:26+00:00 - - - Jonas Nick 2022-07-08 15:53:06+00:00 - + 2025-09-26T14:24:19.136287+00:00 + python-feedgen + + + [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures Jonas Nick + 2022-07-08T15:53:00.000Z + + + Michael Folkson + 2022-07-17T13:26:00.000Z + + + Jonas Nick + 2022-07-17T20:48:00.000Z + + + Michael Folkson + 2022-07-20T11:16:00.000Z + + - python-feedgen + 2 Combined summary - BIP draft: Half-Aggregation of BIP-340 Signatures - 2023-08-02T06:54:19.989189+00:00 + 2025-09-26T14:24:19.136955+00:00 - In a recent email thread, Michael Folkson discusses the potential role of a half aggregation BIP draft and the challenges of implementing CISA/CISHA as a consensus change. Folkson mentions that it is too early to formalize the equivalent of BIP341/342 for this draft BIP. However, there are use cases for the half aggregation BIP that can be worked on today, such as Lightning gossip. Folkson also notes that if CISA/CISHA was attempted in the long term, there would need to be two tiers of verification: one for single signature key path spends where CISA/CISHA could be applied, and another for Taproot script paths where it couldn't be applied. It might even be necessary to define a new output type specifically for the CISA/CISHA use case where there is no access to a script path.The draft BIP does not specify whether "half aggregation needs a new output type or not" as it is out of scope. However, half-aggregation has multiple possible applications. The StackExchange post linked in the context argues that CISA requires a new output type. This argument also applies to half aggregating signatures across transaction inputs, known as CISHA. The Bitcoin development community has been discussing the concept of half-aggregation in various contexts. Jonas Nick has proposed a concrete specification of the scheme and a place for collecting supplemental information like references to cryptographic security proofs. The BIP draft, available on GitHub, only specifies the cryptographic scheme and does not prescribe specific applications. It includes "incremental aggregation" which allows aggregating additional BIP-340 signatures into an existing half-aggregate signature. The formal specification provides a mathematically precise description of the scheme, paving the way for computer-aided formal proofs. Hacspec's syntax being a subset of Rust's syntax allows using the standard Rust toolchain to compile, execute, and test the specification. Although this work is still in its early stages and won't be proposed for a soft fork anytime soon, it opens up possibilities for further exploration.To facilitate further discussions on half-aggregation, a concrete specification of the scheme and a platform for supplementary information have been provided. The BIP draft, similar to BIP-340, only specifies the cryptographic scheme and does not prescribe specific applications. However, it introduces "incremental aggregation" which allows additional BIP-340 signatures to be aggregated into an existing half-aggregate signature. The formal specification written in hacspec provides a mathematically precise description of the scheme, enabling computer-aided formal proofs. The specification can be compiled, executed, and tested using the standard Rust toolchain since hacspec's syntax is a subset of Rust's syntax. It's important to note that the specified scheme has not yet undergone an extensive security review, although it has been reviewed by Elliott Jin and Tim Ruffing. A blog post providing a broader context for half-aggregation and BIP-340 can be found at the given link. 2022-07-20T11:16:40+00:00 + In a recent email thread, Michael Folkson discusses the potential role of a half aggregation BIP draft and the challenges of implementing CISA/CISHA as a consensus change. Folkson mentions that it is too early to formalize the equivalent of BIP341/342 for this draft BIP. However, there are use cases for the half aggregation BIP that can be worked on today, such as Lightning gossip. Folkson also notes that if CISA/CISHA was attempted in the long term, there would need to be two tiers of verification: one for single signature key path spends where CISA/CISHA could be applied, and another for Taproot script paths where it couldn't be applied. It might even be necessary to define a new output type specifically for the CISA/CISHA use case where there is no access to a script path.The draft BIP does not specify whether "half aggregation needs a new output type or not" as it is out of scope. However, half-aggregation has multiple possible applications. The StackExchange post linked in the context argues that CISA requires a new output type. This argument also applies to half aggregating signatures across transaction inputs, known as CISHA. The Bitcoin development community has been discussing the concept of half-aggregation in various contexts. Jonas Nick has proposed a concrete specification of the scheme and a place for collecting supplemental information like references to cryptographic security proofs. The BIP draft, available on GitHub, only specifies the cryptographic scheme and does not prescribe specific applications. It includes "incremental aggregation" which allows aggregating additional BIP-340 signatures into an existing half-aggregate signature. The formal specification provides a mathematically precise description of the scheme, paving the way for computer-aided formal proofs. Hacspec's syntax being a subset of Rust's syntax allows using the standard Rust toolchain to compile, execute, and test the specification. Although this work is still in its early stages and won't be proposed for a soft fork anytime soon, it opens up possibilities for further exploration.To facilitate further discussions on half-aggregation, a concrete specification of the scheme and a platform for supplementary information have been provided. The BIP draft, similar to BIP-340, only specifies the cryptographic scheme and does not prescribe specific applications. However, it introduces "incremental aggregation" which allows additional BIP-340 signatures to be aggregated into an existing half-aggregate signature. The formal specification written in hacspec provides a mathematically precise description of the scheme, enabling computer-aided formal proofs. The specification can be compiled, executed, and tested using the standard Rust toolchain since hacspec's syntax is a subset of Rust's syntax. It's important to note that the specified scheme has not yet undergone an extensive security review, although it has been reviewed by Elliott Jin and Tim Ruffing. A blog post providing a broader context for half-aggregation and BIP-340 can be found at the given link. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Bitcoin-covenants-are-inevitable.xml b/static/bitcoin-dev/July_2022/combined_Bitcoin-covenants-are-inevitable.xml index 7124cb3cf2..00d2adb642 100644 --- a/static/bitcoin-dev/July_2022/combined_Bitcoin-covenants-are-inevitable.xml +++ b/static/bitcoin-dev/July_2022/combined_Bitcoin-covenants-are-inevitable.xml @@ -1,173 +1,231 @@ - + 2 Combined summary - Bitcoin covenants are inevitable - 2023-08-02T06:40:26.385436+00:00 - - alicexbt 2022-07-19 14:46:46+00:00 - - - Anthony Towns 2022-07-19 04:44:58+00:00 - - - Billy Tetrud 2022-07-14 04:55:35+00:00 - - - Erik Aronesty 2022-07-08 15:14:39+00:00 - - - John Carvalho 2022-07-08 07:26:06+00:00 - - - Billy Tetrud 2022-07-08 05:03:40+00:00 - - - vjudeu at gazeta.pl 2022-07-08 04:59:30+00:00 - - - Eric Voskuil 2022-07-08 00:28:36+00:00 - - - Anthony Towns 2022-07-07 22:06:14+00:00 - - - Corey Haddad 2022-07-07 22:02:08+00:00 - - - Erik Aronesty 2022-07-07 21:11:47+00:00 - - - Eric Voskuil 2022-07-07 19:57:56+00:00 - - - Erik Aronesty 2022-07-07 17:37:39+00:00 - - - Eric Voskuil 2022-07-07 16:24:26+00:00 - - - Peter Todd 2022-07-07 14:12:41+00:00 - - - Giuseppe B 2022-07-07 14:10:31+00:00 - - - Erik Aronesty 2022-07-07 14:05:25+00:00 - - - John Carvalho 2022-07-07 13:24:39+00:00 - - - vjudeu at gazeta.pl 2022-07-07 12:15:34+00:00 - - - Billy Tetrud 2022-07-07 00:46:15+00:00 - - - vjudeu at gazeta.pl 2022-07-06 11:10:27+00:00 - - - Corey Haddad 2022-07-06 04:28:50+00:00 - - - Giuseppe B 2022-07-03 10:30:52+00:00 - - - Peter Todd 2022-07-03 09:43:53+00:00 - - - Erik Aronesty 2022-06-30 17:04:50+00:00 - - - Billy Tetrud 2022-06-30 15:25:47+00:00 - - - Kate Salazar 2022-06-29 10:44:11+00:00 - - - Alex Lee 2022-06-29 05:02:30+00:00 - - - Peter Todd 2022-06-28 23:22:40+00:00 - - - Peter Todd 2022-06-28 23:20:27+00:00 - - - Alex Lee 2022-06-28 16:23:40+00:00 - - - Billy Tetrud 2022-06-28 03:55:56+00:00 - - - Peter Todd 2022-06-23 19:17:37+00:00 - - - Eric Voskuil 2022-06-21 20:10:43+00:00 - - - Keagan McClelland 2022-06-21 19:00:07+00:00 - - - Erik Aronesty 2022-06-19 22:35:55+00:00 - - - Kate Salazar 2022-06-19 18:26:21+00:00 - - - Manuel Costa 2022-06-19 15:54:03+00:00 - - - Peter Todd 2022-06-19 10:31:38+00:00 - - - alicexbt 2022-06-12 19:16:49+00:00 - - - Corey Haddad 2022-06-12 16:35:06+00:00 - - - Erik Aronesty 2022-06-12 13:02:38+00:00 - - - Peter Todd 2022-06-12 03:36:45+00:00 - - - Billy Tetrud 2022-06-09 04:30:45+00:00 - - - Ryan Grant 2022-06-09 00:03:07+00:00 - - - Jorge Timón 2022-06-08 09:22:41+00:00 - - - Billy Tetrud 2022-06-08 03:51:40+00:00 - - - Erik Aronesty 2022-06-06 13:02:18+00:00 - - - alicexbt 2022-06-05 04:18:04+00:00 - - - Jorge Timón 2022-06-04 18:43:35+00:00 - - - alicexbt 2022-06-04 16:12:54+00:00 - - - Keagan McClelland 2022-06-04 13:48:40+00:00 - - - John Carvalho 2022-06-04 12:27:53+00:00 - - - micaroni at gmail.com 2022-06-04 00:29:44+00:00 - - - alicexbt 2022-06-03 18:39:34+00:00 - + 2025-09-26T14:24:25.549303+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin covenants are inevitable alicexbt + 2022-06-03T18:39:00.000Z + + + micaroni + 2022-06-04T00:29:00.000Z + + + John Carvalho + 2022-06-04T12:27:00.000Z + + + Keagan McClelland + 2022-06-04T13:48:00.000Z + + + alicexbt + 2022-06-04T16:12:00.000Z + + + Jorge Timón + 2022-06-04T18:43:00.000Z + + + alicexbt + 2022-06-05T04:18:00.000Z + + + Erik Aronesty + 2022-06-06T13:02:00.000Z + + + Billy Tetrud + 2022-06-08T03:51:00.000Z + + + Jorge Timón + 2022-06-08T09:22:00.000Z + + + Ryan Grant + 2022-06-09T00:03:00.000Z + + + Billy Tetrud + 2022-06-09T04:30:00.000Z + + + Peter Todd + 2022-06-12T03:36:00.000Z + + + Erik Aronesty + 2022-06-12T13:02:00.000Z + + + Corey Haddad + 2022-06-12T16:35:00.000Z + + + alicexbt + 2022-06-12T19:16:00.000Z + + + Peter Todd + 2022-06-19T10:31:00.000Z + + + Manuel Costa + 2022-06-19T15:54:00.000Z + + + Kate Salazar + 2022-06-19T18:26:00.000Z + + + Erik Aronesty + 2022-06-19T22:35:00.000Z + + + Keagan McClelland + 2022-06-21T19:00:00.000Z + + + Eric Voskuil + 2022-06-21T20:10:00.000Z + + + Peter Todd + 2022-06-23T19:17:00.000Z + + + Billy Tetrud + 2022-06-28T03:55:00.000Z + + + Alex Lee + 2022-06-28T16:23:00.000Z + + + Peter Todd + 2022-06-28T23:20:00.000Z + + + Peter Todd + 2022-06-28T23:22:00.000Z + + + Alex Lee + 2022-06-29T05:02:00.000Z + + + Kate Salazar + 2022-06-29T10:44:00.000Z + + + Billy Tetrud + 2022-06-30T15:25:00.000Z + + + Erik Aronesty + 2022-06-30T17:04:00.000Z + + + Peter Todd + 2022-07-03T09:43:00.000Z + + + Giuseppe B + 2022-07-03T10:30:00.000Z + + + Corey Haddad + 2022-07-06T04:28:00.000Z + + + vjudeu + 2022-07-06T11:10:00.000Z + + + Billy Tetrud + 2022-07-07T00:46:00.000Z + + + vjudeu + 2022-07-07T12:15:00.000Z + + + John Carvalho + 2022-07-07T13:24:00.000Z + + + Erik Aronesty + 2022-07-07T14:05:00.000Z + + + Giuseppe B + 2022-07-07T14:10:00.000Z + + + Peter Todd + 2022-07-07T14:12:00.000Z + + + Eric Voskuil + 2022-07-07T16:24:00.000Z + + + Erik Aronesty + 2022-07-07T17:37:00.000Z + + + Eric Voskuil + 2022-07-07T19:57:00.000Z + + + Erik Aronesty + 2022-07-07T21:11:00.000Z + + + Corey Haddad + 2022-07-07T22:02:00.000Z + + + Anthony Towns + 2022-07-07T22:06:00.000Z + + + Eric Voskuil + 2022-07-08T00:28:00.000Z + + + vjudeu + 2022-07-08T04:59:00.000Z + + + Billy Tetrud + 2022-07-08T05:03:00.000Z + + + John Carvalho + 2022-07-08T07:26:00.000Z + + + Erik Aronesty + 2022-07-08T15:14:00.000Z + + + Billy Tetrud + 2022-07-14T04:55:00.000Z + + + Anthony Towns + 2022-07-19T04:44:00.000Z + + + alicexbt + 2022-07-19T14:46:00.000Z + + @@ -223,13 +281,13 @@ - python-feedgen + 2 Combined summary - Bitcoin covenants are inevitable - 2023-08-02T06:40:26.386442+00:00 + 2025-09-26T14:24:25.555392+00:00 - The recent discussions among Bitcoin developers have focused on several key topics, including the implementation of covenants, the optimal amount of security needed for Bitcoin, the relationship between block size and fees, and the overall security of the network.There is a debate surrounding the use of covenants in Bitcoin, with concerns about potential risks to fungibility and transaction freedom. Covenants would involve adding temporary conditions to coins while they remain in the owner's possession. The term 'transaction introspection' has been suggested as an alternative to 'covenants'. Opinions differ on whether soft forks should be allowed for covenants, as the risk of losing coins and compromising fungibility and transaction freedom may outweigh any benefits.Discussions also revolve around the optimal amount of security needed for Bitcoin. The present level of security is approximately 1.7% of the total coin supply per year. There are differing opinions on whether lower confirmation rates lead to higher fees or better security. Reducing the block size could potentially increase total fees collected by miners. Market forces and economic shifts play a significant role in determining security. The impact of zero-size blocks on fees and security is also explored.The relationship between confirmation rates, fees, and security in Bitcoin transactions is another topic of debate. Lower confirmation rates are argued to result in higher fees, while others believe that the present level of security is sufficient. Block size reduction can enhance security in terms of validation and fees. Increasing demand is crucial for increasing double spend security and censorship resistance.The discussions also address the relationship between block size and fees, as well as the security of the network. Lowering the block size can prevent double-spending attacks and reduce the burden on node operators. Economic forces are considered to provide security, and the current amount of security appears to be sufficient. Finding the optimal level of security is challenging, and various options are discussed to address this issue.The distribution of costs associated with Bitcoin's security is another point of discussion. There are proposals to reduce block size, violate the 21 million coin limit, or rely on merged mining to pay for security. The importance of finding a balance between security and cost-effectiveness is emphasized.The discussions also touch on various options for paying for Bitcoin's security, including the possibility of burning Bitcoin. The finite supply of Bitcoin is acknowledged as a significant factor, but it is recognized that other forms of cryptographic security must work together to make Bitcoin useful.Overall, the discussions highlight the ongoing debate within the Bitcoin community about how to ensure the security and sustainability of the network. There is a need for ongoing dialogue and consensus building to address these issues effectively.In the context of Bitcoin and its potential for consensus, there is a preference among some individuals for BIP 8 or an improved version of it as a means of implementing soft forks. However, they are also open to any solutions that can enhance the functionality and performance of Bitcoin. One proposal that has been put forward is the implementation of covenants before the next cycle. This approach would create opportunities for developers to build innovative applications and features during bear markets, thereby diversifying the capabilities of Bitcoin.It is important to note that the introduction of CTV (Check Template Verify) is not being rushed as a soft fork. Unlike other soft forks, which often garnered significant attention on social media from respected developers, CTV's research did not receive the same level of publicity. This suggests that the development and adoption of CTV have proceeded with less fanfare and potentially fewer followers.The author believes that we should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits. They prefer BIP 8 or improved BIP 8 for soft fork but won't mind anything else being used if that improves Bitcoin.Apart from the technical merits, covenants will improve various aspects such as developers building interesting projects with real demand in the market, students learning Sapio, and better tooling being available for application developers. There may also be an increase in demand for block space and funding of Bitcoin developers and projects.Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics, etc. on social media, but there are zero technical NACKs for CTV. All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general.Overall, the desire for consensus and improvements in Bitcoin drives the consideration of BIP 8 or an enhanced version thereof. Implementing covenants could foster innovation during bear markets, while the measured approach to CTV's adoption highlights the importance of thorough research and evaluation. 2022-07-19T14:46:46+00:00 + The recent discussions among Bitcoin developers have focused on several key topics, including the implementation of covenants, the optimal amount of security needed for Bitcoin, the relationship between block size and fees, and the overall security of the network.There is a debate surrounding the use of covenants in Bitcoin, with concerns about potential risks to fungibility and transaction freedom. Covenants would involve adding temporary conditions to coins while they remain in the owner's possession. The term 'transaction introspection' has been suggested as an alternative to 'covenants'. Opinions differ on whether soft forks should be allowed for covenants, as the risk of losing coins and compromising fungibility and transaction freedom may outweigh any benefits.Discussions also revolve around the optimal amount of security needed for Bitcoin. The present level of security is approximately 1.7% of the total coin supply per year. There are differing opinions on whether lower confirmation rates lead to higher fees or better security. Reducing the block size could potentially increase total fees collected by miners. Market forces and economic shifts play a significant role in determining security. The impact of zero-size blocks on fees and security is also explored.The relationship between confirmation rates, fees, and security in Bitcoin transactions is another topic of debate. Lower confirmation rates are argued to result in higher fees, while others believe that the present level of security is sufficient. Block size reduction can enhance security in terms of validation and fees. Increasing demand is crucial for increasing double spend security and censorship resistance.The discussions also address the relationship between block size and fees, as well as the security of the network. Lowering the block size can prevent double-spending attacks and reduce the burden on node operators. Economic forces are considered to provide security, and the current amount of security appears to be sufficient. Finding the optimal level of security is challenging, and various options are discussed to address this issue.The distribution of costs associated with Bitcoin's security is another point of discussion. There are proposals to reduce block size, violate the 21 million coin limit, or rely on merged mining to pay for security. The importance of finding a balance between security and cost-effectiveness is emphasized.The discussions also touch on various options for paying for Bitcoin's security, including the possibility of burning Bitcoin. The finite supply of Bitcoin is acknowledged as a significant factor, but it is recognized that other forms of cryptographic security must work together to make Bitcoin useful.Overall, the discussions highlight the ongoing debate within the Bitcoin community about how to ensure the security and sustainability of the network. There is a need for ongoing dialogue and consensus building to address these issues effectively.In the context of Bitcoin and its potential for consensus, there is a preference among some individuals for BIP 8 or an improved version of it as a means of implementing soft forks. However, they are also open to any solutions that can enhance the functionality and performance of Bitcoin. One proposal that has been put forward is the implementation of covenants before the next cycle. This approach would create opportunities for developers to build innovative applications and features during bear markets, thereby diversifying the capabilities of Bitcoin.It is important to note that the introduction of CTV (Check Template Verify) is not being rushed as a soft fork. Unlike other soft forks, which often garnered significant attention on social media from respected developers, CTV's research did not receive the same level of publicity. This suggests that the development and adoption of CTV have proceeded with less fanfare and potentially fewer followers.The author believes that we should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits. They prefer BIP 8 or improved BIP 8 for soft fork but won't mind anything else being used if that improves Bitcoin.Apart from the technical merits, covenants will improve various aspects such as developers building interesting projects with real demand in the market, students learning Sapio, and better tooling being available for application developers. There may also be an increase in demand for block space and funding of Bitcoin developers and projects.Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics, etc. on social media, but there are zero technical NACKs for CTV. All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general.Overall, the desire for consensus and improvements in Bitcoin drives the consideration of BIP 8 or an enhanced version thereof. Implementing covenants could foster innovation during bear markets, while the measured approach to CTV's adoption highlights the importance of thorough research and evaluation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Full-Disclosure-Denial-of-Service-in-STONEWALLx2-p2p-coinjoin-.xml b/static/bitcoin-dev/July_2022/combined_Full-Disclosure-Denial-of-Service-in-STONEWALLx2-p2p-coinjoin-.xml index 59c3f1bfac..5b457b80b5 100644 --- a/static/bitcoin-dev/July_2022/combined_Full-Disclosure-Denial-of-Service-in-STONEWALLx2-p2p-coinjoin-.xml +++ b/static/bitcoin-dev/July_2022/combined_Full-Disclosure-Denial-of-Service-in-STONEWALLx2-p2p-coinjoin-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Full Disclosure: Denial of Service in STONEWALLx2 (p2p coinjoin) - 2023-08-02T07:01:14.301183+00:00 - - alicexbt 2022-09-10 10:20:48+00:00 - - - alicexbt 2022-07-14 09:25:56+00:00 - + 2025-09-26T14:24:12.763026+00:00 + python-feedgen + + + [bitcoin-dev] Full Disclosure: Denial of Service in STONEWALLx2 (p2p coinjoin) alicexbt + 2022-07-14T09:25:00.000Z + + + alicexbt + 2022-09-10T10:20:00.000Z + + - python-feedgen + 2 Combined summary - Full Disclosure: Denial of Service in STONEWALLx2 (p2p coinjoin) - 2023-08-02T07:01:14.301183+00:00 + 2025-09-26T14:24:12.763548+00:00 - A vulnerability has been identified in the Samourai wallet's p2p coinjoin transaction STONEWALLx2, which has been assigned CVE-2022-35913. The issue was reported on July 14th, 2022, to the bitcoin-dev mailing list. The vulnerability involves a denial-of-service (DoS) attack where one participant spends the UTXO used in STONEWALLx2 before the transaction is completed, resulting in an error message for the other participant.Antoine Riard discovered and shared the details of this DoS attack in an email on June 21, 2022. To demonstrate the attack, he created a testnet wallet and used two Android devices to simulate Bob and Carol, who were following each other's paynyms. Carol initiated several paynyms, and when Bob initiated a STONEWALLx2 transaction that required collaboration with Carol, she spent the UTXO from her wallet before Bob could complete the final step. This action caused an error message to appear on Bob's app when trying to broadcast the transaction.In response to this vulnerability, the Samourai Wallet team proposed two suggestions to mitigate the issue. First, they recommended displaying an error message that informs the user that the collaborator has spent their UTXO used in STONEWALLx2, ending the p2p coinjoin process. The message would also suggest unfollowing the collaborator's paynym and recommend doing such transactions only with trusted users for the time being. Secondly, they suggested that once full Replace-by-Fee (RBF) is used by some nodes and miners, the attacker's transaction could be replaced with a higher fee rate. However, implementing this solution won't be straightforward as fees for STONEWALLx2 are shared equally between the participants.The timeline of events shows that Samourai acknowledged the issue on July 7, 2022, and shared their conclusions on July 14, 2022. Antoine Riard played a significant role in the discovery of the DoS vector in p2p coinjoin transactions and assisted during the testing phase by responding to emails. 2022-09-10T10:20:48+00:00 + A vulnerability has been identified in the Samourai wallet's p2p coinjoin transaction STONEWALLx2, which has been assigned CVE-2022-35913. The issue was reported on July 14th, 2022, to the bitcoin-dev mailing list. The vulnerability involves a denial-of-service (DoS) attack where one participant spends the UTXO used in STONEWALLx2 before the transaction is completed, resulting in an error message for the other participant.Antoine Riard discovered and shared the details of this DoS attack in an email on June 21, 2022. To demonstrate the attack, he created a testnet wallet and used two Android devices to simulate Bob and Carol, who were following each other's paynyms. Carol initiated several paynyms, and when Bob initiated a STONEWALLx2 transaction that required collaboration with Carol, she spent the UTXO from her wallet before Bob could complete the final step. This action caused an error message to appear on Bob's app when trying to broadcast the transaction.In response to this vulnerability, the Samourai Wallet team proposed two suggestions to mitigate the issue. First, they recommended displaying an error message that informs the user that the collaborator has spent their UTXO used in STONEWALLx2, ending the p2p coinjoin process. The message would also suggest unfollowing the collaborator's paynym and recommend doing such transactions only with trusted users for the time being. Secondly, they suggested that once full Replace-by-Fee (RBF) is used by some nodes and miners, the attacker's transaction could be replaced with a higher fee rate. However, implementing this solution won't be straightforward as fees for STONEWALLx2 are shared equally between the participants.The timeline of events shows that Samourai acknowledged the issue on July 7, 2022, and shared their conclusions on July 14, 2022. Antoine Riard played a significant role in the discovery of the DoS vector in p2p coinjoin transactions and assisted during the testing phase by responding to emails. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_How-to-do-Proof-of-Micro-Burn-.xml b/static/bitcoin-dev/July_2022/combined_How-to-do-Proof-of-Micro-Burn-.xml index 0527af638e..1ebc2879ca 100644 --- a/static/bitcoin-dev/July_2022/combined_How-to-do-Proof-of-Micro-Burn-.xml +++ b/static/bitcoin-dev/July_2022/combined_How-to-do-Proof-of-Micro-Burn-.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - How to do Proof of Micro-Burn? - 2023-08-02T07:01:57.518257+00:00 - - Peter Todd 2022-07-19 23:13:41+00:00 - - - Ruben Somsen 2022-07-19 22:23:40+00:00 - - - ZmnSCPxj 2022-07-19 14:48:27+00:00 - - - Ruben Somsen 2022-07-18 22:32:37+00:00 - - - ZmnSCPxj 2022-07-17 22:34:24+00:00 - - - Ruben Somsen 2022-07-17 20:40:33+00:00 - - - Велеслав 2022-07-17 13:28:23+00:00 - + 2025-09-26T14:24:31.971376+00:00 + python-feedgen + + + [bitcoin-dev] How to do Proof of Micro-Burn? Велеслав + 2022-07-17T13:28:00.000Z + + + Ruben Somsen + 2022-07-17T20:40:00.000Z + + + ZmnSCPxj + 2022-07-17T22:34:00.000Z + + + Ruben Somsen + 2022-07-18T22:32:00.000Z + + + ZmnSCPxj + 2022-07-19T14:48:00.000Z + + + Ruben Somsen + 2022-07-19T22:23:00.000Z + + + Peter Todd + 2022-07-19T23:13:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - How to do Proof of Micro-Burn? - 2023-08-02T07:01:57.518257+00:00 + 2025-09-26T14:24:31.972197+00:00 - In a recent email exchange on the Bitcoin-dev mailing list, Ruben Somsen proposed a new method for burning multiple amounts in a single OP_RETURN. He suggested using a merkle sum tree with two levels, where the top level represents the total amount burned and the bottom level represents the specific use cases for the funds. However, this method is only practical when burning significantly less than a transaction fee. ZmnSCPxj raised concerns about the atomicity issue and the risk being moved to the seller side. Ruben argued that the lack of an opening of the commitment means the buyer cannot prove the commitment, giving them an incentive to actually pay.The conversation between Ruben and ZmnSCPxj delved into the concept of commitment in cryptography. ZmnSCPxj pointed out that Ruben's proposal did not qualify as a true commitment since it could easily be opened to an uncommitted value. He suggested using Pedersen commitments instead, where only someone who knows 'k' can open the commitment. ZmnSCPxj also explained the merkle sum tree property missing from Ruben's proposal, which allows for the possibility of "double spending" a burn. They also discussed the atomicity issue, where the risk is shifted to the seller if the buyer refuses to finalize the purchase after the on-chain commitment is made. ZmnSCPxj noted that without an opening of the commitment, the buyer cannot prove the commitment and therefore has an incentive to pay.On the bitcoin-dev mailing list, ZmnSCPxj proposed a method for committing to multiple burns in a single transaction using a basic merkle sum tree. To prevent double spending, the leaf hash would need to commit to the intent or recipient of the burn. ZmnSCPxj also suggested outsourcing the burn to an aggregating third party and paying them over Lightning Network (LN), but acknowledged that this would not be atomic. To address this, he proposed an alternative method using private keys and sum commitments. However, ZmnSCPxj cautioned that this approach could have cryptographic failures.Veleslav posted on the mailing list seeking a solution to the proof of burn problem. He suggested using OP_RETURN with application-specific data as the current working solution, but noted the scalability constraint due to finite block space. Veleslav proposed a second layer protocol similar to Lightning Network for public evidence of burns. However, he has not found a solution to the double-spend problem yet. Ruben responded by suggesting a basic merkle sum tree that commits to the intent or recipient of the burn. He also mentioned the possibility of outsourcing the burn to an aggregating third party, but warned about the atomicity issue. Ruben further suggested placing the root hash in a double taproot commitment in the change output, and performing the burn on a spacechain to avoid using mainchain block space and improve scalability. He believes this approach could revitalize the original hashcash use case and combat spam.In conclusion, Veleslav is looking for a solution to the scalability constraint in proof-of-burn use cases. The current solution of using OP_RETURN has limitations, and Veleslav is considering a second layer protocol similar to Lightning Network. However, a reliable solution has not been found yet, and pre-committing burns in the blockchain with additional outputs presents challenges with double spending. Veleslav also explores the possibility of using a liquid type sidechain to fix burns back into the main chain within a Merkel tree proof structure. The goal is to enable micro-burns through the Lightning network and quickly obtain valid burn proofs that are cost-effective to verify. 2022-07-19T23:13:41+00:00 + In a recent email exchange on the Bitcoin-dev mailing list, Ruben Somsen proposed a new method for burning multiple amounts in a single OP_RETURN. He suggested using a merkle sum tree with two levels, where the top level represents the total amount burned and the bottom level represents the specific use cases for the funds. However, this method is only practical when burning significantly less than a transaction fee. ZmnSCPxj raised concerns about the atomicity issue and the risk being moved to the seller side. Ruben argued that the lack of an opening of the commitment means the buyer cannot prove the commitment, giving them an incentive to actually pay.The conversation between Ruben and ZmnSCPxj delved into the concept of commitment in cryptography. ZmnSCPxj pointed out that Ruben's proposal did not qualify as a true commitment since it could easily be opened to an uncommitted value. He suggested using Pedersen commitments instead, where only someone who knows 'k' can open the commitment. ZmnSCPxj also explained the merkle sum tree property missing from Ruben's proposal, which allows for the possibility of "double spending" a burn. They also discussed the atomicity issue, where the risk is shifted to the seller if the buyer refuses to finalize the purchase after the on-chain commitment is made. ZmnSCPxj noted that without an opening of the commitment, the buyer cannot prove the commitment and therefore has an incentive to pay.On the bitcoin-dev mailing list, ZmnSCPxj proposed a method for committing to multiple burns in a single transaction using a basic merkle sum tree. To prevent double spending, the leaf hash would need to commit to the intent or recipient of the burn. ZmnSCPxj also suggested outsourcing the burn to an aggregating third party and paying them over Lightning Network (LN), but acknowledged that this would not be atomic. To address this, he proposed an alternative method using private keys and sum commitments. However, ZmnSCPxj cautioned that this approach could have cryptographic failures.Veleslav posted on the mailing list seeking a solution to the proof of burn problem. He suggested using OP_RETURN with application-specific data as the current working solution, but noted the scalability constraint due to finite block space. Veleslav proposed a second layer protocol similar to Lightning Network for public evidence of burns. However, he has not found a solution to the double-spend problem yet. Ruben responded by suggesting a basic merkle sum tree that commits to the intent or recipient of the burn. He also mentioned the possibility of outsourcing the burn to an aggregating third party, but warned about the atomicity issue. Ruben further suggested placing the root hash in a double taproot commitment in the change output, and performing the burn on a spacechain to avoid using mainchain block space and improve scalability. He believes this approach could revitalize the original hashcash use case and combat spam.In conclusion, Veleslav is looking for a solution to the scalability constraint in proof-of-burn use cases. The current solution of using OP_RETURN has limitations, and Veleslav is considering a second layer protocol similar to Lightning Network. However, a reliable solution has not been found yet, and pre-committing burns in the blockchain with additional outputs presents challenges with double spending. Veleslav also explores the possibility of using a liquid type sidechain to fix burns back into the main chain within a Merkel tree proof structure. The goal is to enable micro-burns through the Lightning network and quickly obtain valid burn proofs that are cost-effective to verify. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_New-BIP-Private-Payments.xml b/static/bitcoin-dev/July_2022/combined_New-BIP-Private-Payments.xml index 6ea7e84528..a255a1c7d4 100644 --- a/static/bitcoin-dev/July_2022/combined_New-BIP-Private-Payments.xml +++ b/static/bitcoin-dev/July_2022/combined_New-BIP-Private-Payments.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - New BIP: Private Payments - 2023-08-02T07:14:07.713900+00:00 - - Alfred Hodler 2022-08-01 11:38:29+00:00 - - - Ruben Somsen 2022-07-30 13:41:36+00:00 - - - Alfred Hodler 2022-07-30 09:24:47+00:00 - + 2025-09-26T14:24:04.176533+00:00 + python-feedgen + + + [bitcoin-dev] New BIP: Private Payments Alfred Hodler + 2022-07-30T09:24:00.000Z + + + Ruben Somsen + 2022-07-30T13:41:00.000Z + + + Alfred Hodler + 2022-08-01T11:38:00.000Z + + - python-feedgen + 2 Combined summary - New BIP: Private Payments - 2023-08-02T07:14:07.713900+00:00 + 2025-09-26T14:24:04.177112+00:00 - In response to feedback from Ruben Somsen, Alfred Hodler has made several updates to his proposal for a new BIP that aims to enhance the privacy and future-proofing of two-party transactions. Ruben pointed out that the proposal introduces a scanning requirement to detect incoming notifications, which complicates light client implementation. He recommended that Alfred include this information in the BIP to ensure readers are aware of this downside.Ruben also noted that Alfred's proposal is similar to the BIP47 protocol improvement suggestions made in Prague, with the only difference being the addition of an extra ECDH calculation to hide the recipient payment code. This additional step leads to the scanning requirement, but allows users to broadcast notifications themselves instead of outsourcing them. Ruben suggested acknowledging this similarity and giving credit to the participants of the Prague discussion.Furthermore, Ruben advised Alfred to revisit the "Allowing collisions" paragraph from the Prague discussion, as it has the potential to reduce the size by up to 28 bytes. Despite these concerns, Ruben expressed support for Alfred's proposal and appreciated the effort put into working out details such as address formats.Alfred has taken Ruben's feedback into consideration and implemented some changes. He has incorporated Ruben's suggestion of using only the first four bytes of the notification code, as well as added Ruben as a co-author. Alfred explained that hiding the recipient in the notification not only allows Alice to send a notification herself, but also breaks the link between the notifier and Bob. This avoids social graph building issues and unique per-recipient notification addresses found in BIP47.However, light clients will need to rely on an OP_RETURN indexing service, which Alfred considers an acceptable inconvenience. This reliance reduces social metadata on the blockchain, prevents censorship of certain recipients by notification services, allows wallets to choose their level of outsourcing, and protects against attacks from adversaries monitoring notifications.Overall, Alfred's proposed BIP aims to enhance the privacy and future-proofing of two-party transactions. It builds upon the BIP47 protocol and offers increased privacy features. The proposal can be found on GitHub, and Alfred is seeking feedback to further refine it before it can be assigned a BIP number. Once the BIP is deemed viable, a reference implementation will be published. 2022-08-01T11:38:29+00:00 + In response to feedback from Ruben Somsen, Alfred Hodler has made several updates to his proposal for a new BIP that aims to enhance the privacy and future-proofing of two-party transactions. Ruben pointed out that the proposal introduces a scanning requirement to detect incoming notifications, which complicates light client implementation. He recommended that Alfred include this information in the BIP to ensure readers are aware of this downside.Ruben also noted that Alfred's proposal is similar to the BIP47 protocol improvement suggestions made in Prague, with the only difference being the addition of an extra ECDH calculation to hide the recipient payment code. This additional step leads to the scanning requirement, but allows users to broadcast notifications themselves instead of outsourcing them. Ruben suggested acknowledging this similarity and giving credit to the participants of the Prague discussion.Furthermore, Ruben advised Alfred to revisit the "Allowing collisions" paragraph from the Prague discussion, as it has the potential to reduce the size by up to 28 bytes. Despite these concerns, Ruben expressed support for Alfred's proposal and appreciated the effort put into working out details such as address formats.Alfred has taken Ruben's feedback into consideration and implemented some changes. He has incorporated Ruben's suggestion of using only the first four bytes of the notification code, as well as added Ruben as a co-author. Alfred explained that hiding the recipient in the notification not only allows Alice to send a notification herself, but also breaks the link between the notifier and Bob. This avoids social graph building issues and unique per-recipient notification addresses found in BIP47.However, light clients will need to rely on an OP_RETURN indexing service, which Alfred considers an acceptable inconvenience. This reliance reduces social metadata on the blockchain, prevents censorship of certain recipients by notification services, allows wallets to choose their level of outsourcing, and protects against attacks from adversaries monitoring notifications.Overall, Alfred's proposed BIP aims to enhance the privacy and future-proofing of two-party transactions. It builds upon the BIP47 protocol and offers increased privacy features. The proposal can be found on GitHub, and Alfred is seeking feedback to further refine it before it can be assigned a BIP number. Once the BIP is deemed viable, a reference implementation will be published. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_No-Order-Mnemonic.xml b/static/bitcoin-dev/July_2022/combined_No-Order-Mnemonic.xml index c46275ce96..9327c3b42d 100644 --- a/static/bitcoin-dev/July_2022/combined_No-Order-Mnemonic.xml +++ b/static/bitcoin-dev/July_2022/combined_No-Order-Mnemonic.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - No Order Mnemonic - 2023-08-02T06:53:56.589196+00:00 - - Erik Aronesty 2022-07-11 13:18:14+00:00 - - - Erik Aronesty 2022-07-11 13:11:53+00:00 - - - Anton Shevchenko 2022-07-09 23:46:19+00:00 - - - James MacWhyte 2022-07-09 22:21:16+00:00 - - - Zac Greenwood 2022-07-09 20:31:22+00:00 - - - James MacWhyte 2022-07-08 14:08:54+00:00 - - - Paul Sztorc 2022-07-08 09:12:06+00:00 - - - vjudeu at gazeta.pl 2022-07-08 04:35:16+00:00 - - - Eric Voskuil 2022-07-08 02:19:43+00:00 - - - Bram Cohen 2022-07-08 01:47:33+00:00 - - - Anton Shevchenko 2022-07-07 17:58:40+00:00 - - - Pavol Rusnak 2022-07-07 17:52:18+00:00 - - - Bram Cohen 2022-07-07 17:36:26+00:00 - - - Anton Shevchenko 2022-07-07 14:33:09+00:00 - + 2025-09-26T14:24:34.085681+00:00 + python-feedgen + + + [bitcoin-dev] No Order Mnemonic Anton Shevchenko + 2022-07-07T14:33:00.000Z + + + Bram Cohen + 2022-07-07T17:36:00.000Z + + + Pavol Rusnak + 2022-07-07T17:52:00.000Z + + + Anton Shevchenko + 2022-07-07T17:58:00.000Z + + + Bram Cohen + 2022-07-08T01:47:00.000Z + + + Eric Voskuil + 2022-07-08T02:19:00.000Z + + + vjudeu + 2022-07-08T04:35:00.000Z + + + Paul Sztorc + 2022-07-08T09:12:00.000Z + + + James MacWhyte + 2022-07-08T14:08:00.000Z + + + Zac Greenwood + 2022-07-09T20:31:00.000Z + + + James MacWhyte + 2022-07-09T22:21:00.000Z + + + Anton Shevchenko + 2022-07-09T23:46:00.000Z + + + Erik Aronesty + 2022-07-11T13:11:00.000Z + + + Erik Aronesty + 2022-07-11T13:18:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - No Order Mnemonic - 2023-08-02T06:53:56.589196+00:00 + 2025-09-26T14:24:34.087293+00:00 - In a discussion on the bitcoin-dev mailing list, there is a debate about the security of a 12-word seed used for Bitcoin wallets. Sorting the seed alphabetically reduces its entropy by approximately 29 bits, which raises concerns about its security. One suggestion is to use an unordered encoding instead, but others argue that 12 unordered words may be sufficient for memory purposes unless there are gaps or errors in the remembered story.James MacWhyte proposes randomly choosing 11 words and sorting them alphabetically before assigning a checksum. This would significantly reduce entropy, leaving around 10 trillion combinations to brute force. With hardware capable of one million guesses per second, this could be exhausted within a couple of months.It is noted that sorting a seed alphabetically removes approximately 29 bits of entropy, reducing the seed entropy from 128 to 99 bits. However, choosing 11 random words and then sorting them alphabetically would still reduce entropy considerably. Despite some initial miscalculations, it is determined that there are actually around 10^30 total possible phrases, making it impossible to brute force in an acceptable timeframe.Zac Greenwood explains that sorting a seed alphabetically reduces its entropy by approximately 29 bits, reducing the seed entropy from 128 to 99 bits. However, James MacWhyte points out that if one word is the very last from the wordlist, it would end up at the end of the mnemonic once you rearrange your 12 words alphabetically. Despite this, choosing 11 random words and then sorting them alphabetically before assigning a checksum would still reduce entropy considerably. Napkin math estimates this would leave around 10 trillion combinations, which would only take a couple of months to exhaust with hardware capable of doing one million guesses per second.The discussion also explores different mnemonic encodings. Anton Shevchenko shares his python implementation for a different mnemonic encoding that requires users to remember words but not their order. Bram Cohen raises the question of whether it is possible to create a code that always uses BIP-39 words for the same key as part of its encoding, adding error correction words in case the order is lost or confused. Pavol Rusnak suggests encoding the index of permutation used to scramble the otherwise sorted list, but notes that repetitions make this more difficult. It is also emphasized that any ordering is acceptable as long as the new words are in the same pool as the old words.In conclusion, the discussion revolves around the security of a 12-word seed for Bitcoin wallets. Sorting the seed alphabetically reduces entropy, but there are concerns about its security. Different proposals are made, such as using an unordered encoding or sorting random words alphabetically before assigning a checksum. The feasibility of brute forcing the combinations is discussed, and different mnemonic encodings are explored. Anton Shevchenko shares his python implementation for a mnemonic encoding that requires users to remember words but not their order. Bram Cohen raises the question of creating a code that always uses BIP-39 words for the same key as part of its encoding, with added error correction words. 2022-07-11T13:18:14+00:00 + In a discussion on the bitcoin-dev mailing list, there is a debate about the security of a 12-word seed used for Bitcoin wallets. Sorting the seed alphabetically reduces its entropy by approximately 29 bits, which raises concerns about its security. One suggestion is to use an unordered encoding instead, but others argue that 12 unordered words may be sufficient for memory purposes unless there are gaps or errors in the remembered story.James MacWhyte proposes randomly choosing 11 words and sorting them alphabetically before assigning a checksum. This would significantly reduce entropy, leaving around 10 trillion combinations to brute force. With hardware capable of one million guesses per second, this could be exhausted within a couple of months.It is noted that sorting a seed alphabetically removes approximately 29 bits of entropy, reducing the seed entropy from 128 to 99 bits. However, choosing 11 random words and then sorting them alphabetically would still reduce entropy considerably. Despite some initial miscalculations, it is determined that there are actually around 10^30 total possible phrases, making it impossible to brute force in an acceptable timeframe.Zac Greenwood explains that sorting a seed alphabetically reduces its entropy by approximately 29 bits, reducing the seed entropy from 128 to 99 bits. However, James MacWhyte points out that if one word is the very last from the wordlist, it would end up at the end of the mnemonic once you rearrange your 12 words alphabetically. Despite this, choosing 11 random words and then sorting them alphabetically before assigning a checksum would still reduce entropy considerably. Napkin math estimates this would leave around 10 trillion combinations, which would only take a couple of months to exhaust with hardware capable of doing one million guesses per second.The discussion also explores different mnemonic encodings. Anton Shevchenko shares his python implementation for a different mnemonic encoding that requires users to remember words but not their order. Bram Cohen raises the question of whether it is possible to create a code that always uses BIP-39 words for the same key as part of its encoding, adding error correction words in case the order is lost or confused. Pavol Rusnak suggests encoding the index of permutation used to scramble the otherwise sorted list, but notes that repetitions make this more difficult. It is also emphasized that any ordering is acceptable as long as the new words are in the same pool as the old words.In conclusion, the discussion revolves around the security of a 12-word seed for Bitcoin wallets. Sorting the seed alphabetically reduces entropy, but there are concerns about its security. Different proposals are made, such as using an unordered encoding or sorting random words alphabetically before assigning a checksum. The feasibility of brute forcing the combinations is discussed, and different mnemonic encodings are explored. Anton Shevchenko shares his python implementation for a mnemonic encoding that requires users to remember words but not their order. Bram Cohen raises the question of creating a code that always uses BIP-39 words for the same key as part of its encoding, with added error correction words. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 140fe3148d..8d0ee1785c 100644 --- a/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On a new community process to specify covenants - 2023-08-02T07:05:21.717413+00:00 + 2025-09-26T14:24:14.910744+00:00 + python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - On a new community process to specify covenants - 2023-08-02T07:05:21.718414+00:00 + 2025-09-26T14:24:14.910955+00:00 - The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest 2022-10-07T15:33:12+00:00 + The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml b/static/bitcoin-dev/July_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml index 3d26322659..5150de805e 100644 --- a/static/bitcoin-dev/July_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml +++ b/static/bitcoin-dev/July_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml @@ -1,89 +1,119 @@ - + 2 Combined summary - Playing with full-rbf peers for fun and L2s security - 2023-08-02T06:48:58.631630+00:00 - - Antoine Riard 2022-08-24 01:56:14+00:00 - - - Antoine Riard 2022-07-09 15:06:43+00:00 - - - alicexbt 2022-07-08 19:44:24+00:00 - - - Greg Sanders 2022-07-08 15:09:33+00:00 - - - Peter Todd 2022-07-08 14:53:13+00:00 - - - alicexbt 2022-07-05 20:46:51+00:00 - - - Peter Todd 2022-06-27 13:46:46+00:00 - - - Greg Sanders 2022-06-27 12:03:38+00:00 - - - Peter Todd 2022-06-27 00:43:35+00:00 - - - alicexbt 2022-06-26 16:40:24+00:00 - - - Peter Todd 2022-06-23 19:13:47+00:00 - - - Antoine Riard 2022-06-21 23:45:48+00:00 - - - Antoine Riard 2022-06-21 23:43:23+00:00 - - - Peter Todd 2022-06-20 23:49:55+00:00 - - - Peter Todd 2022-06-19 10:42:15+00:00 - - - alicexbt 2022-06-17 04:54:11+00:00 - - - Antoine Riard 2022-06-17 01:34:17+00:00 - - - Greg Sanders 2022-06-16 13:24:03+00:00 - - - alicexbt 2022-06-16 12:47:15+00:00 - - - linuxfoundation.cndm1 at dralias.com 2022-06-16 05:43:33+00:00 - - - alicexbt 2022-06-16 01:45:42+00:00 - - - Greg Sanders 2022-06-16 01:02:39+00:00 - - - alicexbt 2022-06-16 00:16:52+00:00 - - - Peter Todd 2022-06-15 03:18:33+00:00 - - - Luke Dashjr 2022-06-15 02:53:58+00:00 - - - Peter Todd 2022-06-15 02:27:20+00:00 - - - Antoine Riard 2022-06-14 00:25:11+00:00 - + 2025-09-26T14:24:10.638649+00:00 + python-feedgen + + + [bitcoin-dev] Playing with full-rbf peers for fun and L2s security Antoine Riard + 2022-06-14T00:25:00.000Z + + + Peter Todd + 2022-06-15T02:27:00.000Z + + + Luke Dashjr + 2022-06-15T02:53:00.000Z + + + Peter Todd + 2022-06-15T03:18:00.000Z + + + alicexbt + 2022-06-16T00:16:00.000Z + + + Greg Sanders + 2022-06-16T01:02:00.000Z + + + alicexbt + 2022-06-16T01:45:00.000Z + + + linuxfoundation.cndm1 + 2022-06-16T05:43:00.000Z + + + alicexbt + 2022-06-16T12:47:00.000Z + + + Greg Sanders + 2022-06-16T13:24:00.000Z + + + Antoine Riard + 2022-06-17T01:34:00.000Z + + + alicexbt + 2022-06-17T04:54:00.000Z + + + Peter Todd + 2022-06-19T10:42:00.000Z + + + Peter Todd + 2022-06-20T23:49:00.000Z + + + Antoine Riard + 2022-06-21T23:43:00.000Z + + + Antoine Riard + 2022-06-21T23:45:00.000Z + + + Peter Todd + 2022-06-23T19:13:00.000Z + + + alicexbt + 2022-06-26T16:40:00.000Z + + + Peter Todd + 2022-06-27T00:43:00.000Z + + + Greg Sanders + 2022-06-27T12:03:00.000Z + + + Peter Todd + 2022-06-27T13:46:00.000Z + + + alicexbt + 2022-07-05T20:46:00.000Z + + + Peter Todd + 2022-07-08T14:53:00.000Z + + + Greg Sanders + 2022-07-08T15:09:00.000Z + + + alicexbt + 2022-07-08T19:44:00.000Z + + + Antoine Riard + 2022-07-09T15:06:00.000Z + + + Antoine Riard + 2022-08-24T01:56:00.000Z + + @@ -111,13 +141,13 @@ - python-feedgen + 2 Combined summary - Playing with full-rbf peers for fun and L2s security - 2023-08-02T06:48:58.631630+00:00 + 2025-09-26T14:24:10.641482+00:00 - The conversation discussed the vulnerability of open, p2p coinjoin services to DoS attacks. It was noted that attackers can disrupt rounds by failing to complete them or launching double-spend attacks. Mitigating these types of attacks is crucial to prevent malicious coinjoin service providers from outlawing competition. Punishing attackers in the case of failed relay transactions during coinjoin rounds is also challenging. The implementation of full-rbf as a policy in Bitcoin Core was proposed as a potential solution to improve the security and reliability of multi-party funded transactions. However, there are ongoing discussions and disagreements regarding the approach and its impact.Another proposal shared on GitHub aims to enable trustless DLCs on Bitcoin using dual-funded channels with Lightning Network-style HTLCs. This would provide a more secure and scalable solution for off-chain contracts. Antoine Riard suggests that users should be able to manage their LN usage by using better ISPs or adopting different mempool policies. Documentation was highlighted as important in helping users understand and navigate the complexities of RBF policies and mempool DoS vectors. Community engagement and collaboration are emphasized as necessary to advance the state of policy options in Bitcoin Core.The Lightning dual-funded channel proposal aims to increase the efficiency and usability of the Lightning network by allowing users to easily create secure and decentralized channels. The fund allocation and transaction signing process is outlined in the proposal. It has been shared on the bitcoin-dev mailing list where developers discuss technical aspects of Bitcoin.There have been discussions about the lack of basic options in Bitcoin Core for enabling/disabling different RBF policies. The implementation of full-RBF in Bitcoin Core is questioned, and the author suggests providing basic RBF policy options instead of removing the ability to disable certain policies. Antoine Riard proposes fixing the security vulnerabilities in multi-party funded transactions by enabling full-RBF as a policy in Bitcoin Core. He has submitted a patch for review and invites node operators to test full-RBF. Concerns about the impact of full-RBF on vulnerable projects and the lack of consensus among nodes and miners are raised. Some suggest using alternative implementations like Bitcoin Knots, which already has an option to disable all RBF policies. However, proponents argue that full-RBF is a simple and incentive-compatible step towards more robust layer two systems. Peter Todd suggests a similar approach to full-RBF but notes that he hasn't worked on the Bitcoin Core codebase in years.In summary, ongoing discussions revolve around the implementation of full-RBF in Bitcoin Core and its impact on multi-party funded transactions. The Lightning dual-funded channel proposal aims to improve the efficiency and usability of the Lightning network. Developers are encouraged to provide basic RBF policy options, and alternative implementations like Bitcoin Knots already offer these options. Node operators and mining operators can experiment with full-RBF to test its benefits and drawbacks. 2022-08-24T01:56:14+00:00 + The conversation discussed the vulnerability of open, p2p coinjoin services to DoS attacks. It was noted that attackers can disrupt rounds by failing to complete them or launching double-spend attacks. Mitigating these types of attacks is crucial to prevent malicious coinjoin service providers from outlawing competition. Punishing attackers in the case of failed relay transactions during coinjoin rounds is also challenging. The implementation of full-rbf as a policy in Bitcoin Core was proposed as a potential solution to improve the security and reliability of multi-party funded transactions. However, there are ongoing discussions and disagreements regarding the approach and its impact.Another proposal shared on GitHub aims to enable trustless DLCs on Bitcoin using dual-funded channels with Lightning Network-style HTLCs. This would provide a more secure and scalable solution for off-chain contracts. Antoine Riard suggests that users should be able to manage their LN usage by using better ISPs or adopting different mempool policies. Documentation was highlighted as important in helping users understand and navigate the complexities of RBF policies and mempool DoS vectors. Community engagement and collaboration are emphasized as necessary to advance the state of policy options in Bitcoin Core.The Lightning dual-funded channel proposal aims to increase the efficiency and usability of the Lightning network by allowing users to easily create secure and decentralized channels. The fund allocation and transaction signing process is outlined in the proposal. It has been shared on the bitcoin-dev mailing list where developers discuss technical aspects of Bitcoin.There have been discussions about the lack of basic options in Bitcoin Core for enabling/disabling different RBF policies. The implementation of full-RBF in Bitcoin Core is questioned, and the author suggests providing basic RBF policy options instead of removing the ability to disable certain policies. Antoine Riard proposes fixing the security vulnerabilities in multi-party funded transactions by enabling full-RBF as a policy in Bitcoin Core. He has submitted a patch for review and invites node operators to test full-RBF. Concerns about the impact of full-RBF on vulnerable projects and the lack of consensus among nodes and miners are raised. Some suggest using alternative implementations like Bitcoin Knots, which already has an option to disable all RBF policies. However, proponents argue that full-RBF is a simple and incentive-compatible step towards more robust layer two systems. Peter Todd suggests a similar approach to full-RBF but notes that he hasn't worked on the Bitcoin Core codebase in years.In summary, ongoing discussions revolve around the implementation of full-RBF in Bitcoin Core and its impact on multi-party funded transactions. The Lightning dual-funded channel proposal aims to improve the efficiency and usability of the Lightning network. Developers are encouraged to provide basic RBF policy options, and alternative implementations like Bitcoin Knots already offer these options. Node operators and mining operators can experiment with full-RBF to test its benefits and drawbacks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Regarding-setting-a-lower-minrelaytxfee.xml b/static/bitcoin-dev/July_2022/combined_Regarding-setting-a-lower-minrelaytxfee.xml index c65b3370ea..36707a616c 100644 --- a/static/bitcoin-dev/July_2022/combined_Regarding-setting-a-lower-minrelaytxfee.xml +++ b/static/bitcoin-dev/July_2022/combined_Regarding-setting-a-lower-minrelaytxfee.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - Regarding setting a lower minrelaytxfee - 2023-08-02T07:11:13.160298+00:00 - - Billy Tetrud 2022-08-04 01:21:51+00:00 - - - Aaradhya Chauhan 2022-08-03 18:22:32+00:00 - - - vjudeu at gazeta.pl 2022-08-03 17:07:08+00:00 - - - Aaradhya Chauhan 2022-08-03 15:40:34+00:00 - - - Peter Todd 2022-08-01 13:37:47+00:00 - - - aliashraf.btc At protonmail 2022-08-01 13:19:05+00:00 - - - Peter Todd 2022-08-01 10:30:07+00:00 - - - alicexbt 2022-07-30 17:24:35+00:00 - - - Peter Todd 2022-07-30 10:20:49+00:00 - - - Aaradhya Chauhan 2022-07-30 07:55:55+00:00 - - - Aaradhya Chauhan 2022-07-29 18:59:31+00:00 - - - David A. Harding 2022-07-29 03:38:19+00:00 - - - vjudeu at gazeta.pl 2022-07-27 12:18:56+00:00 - - - Peter Todd 2022-07-27 11:50:23+00:00 - - - vjudeu at gazeta.pl 2022-07-27 04:10:00+00:00 - - - alicexbt 2022-07-26 19:14:58+00:00 - - - Peter Todd 2022-07-26 14:27:56+00:00 - - - Peter Todd 2022-07-26 12:45:12+00:00 - - - alicexbt 2022-07-26 12:19:32+00:00 - - - Aaradhya Chauhan 2022-07-26 08:26:05+00:00 - + 2025-09-26T14:24:38.351779+00:00 + python-feedgen + + + [bitcoin-dev] Regarding setting a lower minrelaytxfee Aaradhya Chauhan + 2022-07-26T08:26:00.000Z + + + alicexbt + 2022-07-26T12:19:00.000Z + + + Peter Todd + 2022-07-26T12:45:00.000Z + + + Peter Todd + 2022-07-26T14:27:00.000Z + + + alicexbt + 2022-07-26T19:14:00.000Z + + + vjudeu + 2022-07-27T04:10:00.000Z + + + Peter Todd + 2022-07-27T11:50:00.000Z + + + vjudeu + 2022-07-27T12:18:00.000Z + + + David A. Harding + 2022-07-29T03:38:00.000Z + + + Aaradhya Chauhan + 2022-07-29T18:59:00.000Z + + + Aaradhya Chauhan + 2022-07-30T07:55:00.000Z + + + Peter Todd + 2022-07-30T10:20:00.000Z + + + alicexbt + 2022-07-30T17:24:00.000Z + + + Peter Todd + 2022-08-01T10:30:00.000Z + + + aliashraf.btc At protonmail + 2022-08-01T13:19:00.000Z + + + Peter Todd + 2022-08-01T13:37:00.000Z + + + Aaradhya Chauhan + 2022-08-03T15:40:00.000Z + + + vjudeu + 2022-08-03T17:07:00.000Z + + + Aaradhya Chauhan + 2022-08-03T18:22:00.000Z + + + Billy Tetrud + 2022-08-04T01:21:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - Regarding setting a lower minrelaytxfee - 2023-08-02T07:11:13.160298+00:00 + 2025-09-26T14:24:38.354206+00:00 - The discussion on the bitcoin-dev mailing list revolves around the possibility of changing the dust limit and the minimum transaction relay feerate. A member suggested removing the fixed dust limit and relying solely on the mempool size limit to determine what is considered dust. However, others pointed out that individual nodes adjusting their settings would not be effective without a network-wide change. While the current settings may be useful for certain situations, changing the defaults would achieve nothing for the majority of users.Peter Todd, a Bitcoin developer, proposed removing the fixed dust limit entirely and relying on the mempool size limit. He argued that this change could be made by nodes without requesting permission or modifying the source code. He also stated that lowering the dust limit would prepare the ecosystem for future conditions where fee revenue would be significant. However, some members raised concerns about potential adverse effects and the complexity involved in implementing this change.In another discussion on the bitcoin-dev mailing list, a user asked about the possibility of reducing the minimum relay transaction fee for Bitcoin transactions. It was noted that while this is not a consensus rule, it could be done with support from full node operators. However, some miners may be hesitant to lower profits by using a lower minrelaytxfee. The option of allowing near-zero transactions into a miner's mempool through the Child-Pays-For-Parent mechanism was also mentioned as a way to potentially mine more fees.Aaradhya Chauhan, a member of the Bitcoin-dev group, expressed the opinion that the current dust protection measure is too high and should be lowered slightly. She suggested halving the measure when prices double and keeping it constant at that point. Aaradhya believes that this change can be easily implemented with the support of full node operators. However, she acknowledged that a few miners may be reluctant to lower their profits by using a lower minrelaytxfee. She supports the Lightning Network but also emphasizes the importance of maintaining transaction affordability in the future. Aaradhya argues that those willing to wait in a queue should have the option for the same affordability for minimum fees as exists today.Overall, the discussions on the bitcoin-dev mailing list revolve around the potential changes to the dust limit and the minimum transaction relay feerate. While some argue for lowering these limits, others raise concerns about potential challenges and adverse effects. The economic benefits of reducing feerates for the bottom of the mempool are considered relatively small compared to the complexity involved. 2022-08-04T01:21:51+00:00 + The discussion on the bitcoin-dev mailing list revolves around the possibility of changing the dust limit and the minimum transaction relay feerate. A member suggested removing the fixed dust limit and relying solely on the mempool size limit to determine what is considered dust. However, others pointed out that individual nodes adjusting their settings would not be effective without a network-wide change. While the current settings may be useful for certain situations, changing the defaults would achieve nothing for the majority of users.Peter Todd, a Bitcoin developer, proposed removing the fixed dust limit entirely and relying on the mempool size limit. He argued that this change could be made by nodes without requesting permission or modifying the source code. He also stated that lowering the dust limit would prepare the ecosystem for future conditions where fee revenue would be significant. However, some members raised concerns about potential adverse effects and the complexity involved in implementing this change.In another discussion on the bitcoin-dev mailing list, a user asked about the possibility of reducing the minimum relay transaction fee for Bitcoin transactions. It was noted that while this is not a consensus rule, it could be done with support from full node operators. However, some miners may be hesitant to lower profits by using a lower minrelaytxfee. The option of allowing near-zero transactions into a miner's mempool through the Child-Pays-For-Parent mechanism was also mentioned as a way to potentially mine more fees.Aaradhya Chauhan, a member of the Bitcoin-dev group, expressed the opinion that the current dust protection measure is too high and should be lowered slightly. She suggested halving the measure when prices double and keeping it constant at that point. Aaradhya believes that this change can be easily implemented with the support of full node operators. However, she acknowledged that a few miners may be reluctant to lower their profits by using a lower minrelaytxfee. She supports the Lightning Network but also emphasizes the importance of maintaining transaction affordability in the future. Aaradhya argues that those willing to wait in a queue should have the option for the same affordability for minimum fees as exists today.Overall, the discussions on the bitcoin-dev mailing list revolve around the potential changes to the dust limit and the minimum transaction relay feerate. While some argue for lowering these limits, others raise concerns about potential challenges and adverse effects. The economic benefits of reducing feerates for the bottom of the mempool are considered relatively small compared to the complexity involved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Security-problems-with-relying-on-transaction-fees-for-security.xml b/static/bitcoin-dev/July_2022/combined_Security-problems-with-relying-on-transaction-fees-for-security.xml index 84e7f64cf2..b75d1e0356 100644 --- a/static/bitcoin-dev/July_2022/combined_Security-problems-with-relying-on-transaction-fees-for-security.xml +++ b/static/bitcoin-dev/July_2022/combined_Security-problems-with-relying-on-transaction-fees-for-security.xml @@ -1,113 +1,151 @@ - + 2 Combined summary - Security problems with relying on transaction fees for security - 2023-08-02T07:00:56.931840+00:00 - - vjudeu at gazeta.pl 2022-07-15 06:03:57+00:00 - - - Manuel Costa 2022-07-14 16:27:55+00:00 - - - Erik Aronesty 2022-07-14 16:01:39+00:00 - - - Gino Pinuto 2022-07-14 11:42:56+00:00 - - - Erik Aronesty 2022-07-14 09:57:41+00:00 - - - vjudeu at gazeta.pl 2022-07-14 09:33:13+00:00 - - - Anthony Towns 2022-07-14 00:54:48+00:00 - - - Manuel Costa 2022-07-13 13:29:43+00:00 - - - Erik Aronesty 2022-07-13 12:18:43+00:00 - - - Gino Pinuto 2022-07-13 12:11:59+00:00 - - - John Tromp 2022-07-13 11:56:33+00:00 - - - John Tromp 2022-07-13 09:43:57+00:00 - - - Tom Harding 2022-07-13 00:38:32+00:00 - - - Ryan Grant 2022-07-12 17:46:43+00:00 - - - Peter 2022-07-12 15:08:41+00:00 - - - Erik Aronesty 2022-07-12 11:57:40+00:00 - - - Peter 2022-07-12 03:56:03+00:00 - - - Bram Cohen 2022-07-12 02:47:43+00:00 - - - Peter Todd 2022-07-12 00:37:11+00:00 - - - Peter Todd 2022-07-12 00:31:19+00:00 - - - Russell O'Connor 2022-07-12 00:21:40+00:00 - - - James MacWhyte 2022-07-12 00:01:09+00:00 - - - Anthony Towns 2022-07-11 23:29:47+00:00 - - - Peter Todd 2022-07-11 22:26:31+00:00 - - - James MacWhyte 2022-07-11 22:19:06+00:00 - - - Peter Todd 2022-07-11 21:56:53+00:00 - - - Peter Todd 2022-07-11 21:53:37+00:00 - - - Peter Todd 2022-07-11 21:36:52+00:00 - - - Pox 2022-07-11 21:18:10+00:00 - - - Erik Aronesty 2022-07-11 20:52:39+00:00 - - - Russell O'Connor 2022-07-11 20:35:02+00:00 - - - vjudeu at gazeta.pl 2022-07-11 19:45:39+00:00 - - - Erik Aronesty 2022-07-11 18:43:27+00:00 - - - micaroni at gmail.com 2022-07-11 18:38:34+00:00 - - - Bram Cohen 2022-07-11 18:12:52+00:00 - + 2025-09-26T14:24:06.337658+00:00 + python-feedgen + + + [bitcoin-dev] Security problems with relying on transaction fees for security Bram Cohen + 2022-07-11T18:12:00.000Z + + + micaroni + 2022-07-11T18:38:00.000Z + + + Erik Aronesty + 2022-07-11T18:43:00.000Z + + + vjudeu + 2022-07-11T19:45:00.000Z + + + Russell O'Connor + 2022-07-11T20:35:00.000Z + + + Erik Aronesty + 2022-07-11T20:52:00.000Z + + + Pox + 2022-07-11T21:18:00.000Z + + + Peter Todd + 2022-07-11T21:36:00.000Z + + + Peter Todd + 2022-07-11T21:53:00.000Z + + + Peter Todd + 2022-07-11T21:56:00.000Z + + + James MacWhyte + 2022-07-11T22:19:00.000Z + + + Peter Todd + 2022-07-11T22:26:00.000Z + + + Anthony Towns + 2022-07-11T23:29:00.000Z + + + James MacWhyte + 2022-07-12T00:01:00.000Z + + + Russell O'Connor + 2022-07-12T00:21:00.000Z + + + Peter Todd + 2022-07-12T00:31:00.000Z + + + Peter Todd + 2022-07-12T00:37:00.000Z + + + Bram Cohen + 2022-07-12T02:47:00.000Z + + + Peter + 2022-07-12T03:56:00.000Z + + + Erik Aronesty + 2022-07-12T11:57:00.000Z + + + Peter + 2022-07-12T15:08:00.000Z + + + Ryan Grant + 2022-07-12T17:46:00.000Z + + + Tom Harding + 2022-07-13T00:38:00.000Z + + + John Tromp + 2022-07-13T09:43:00.000Z + + + John Tromp + 2022-07-13T11:56:00.000Z + + + Gino Pinuto + 2022-07-13T12:11:00.000Z + + + Erik Aronesty + 2022-07-13T12:18:00.000Z + + + Manuel Costa + 2022-07-13T13:29:00.000Z + + + Anthony Towns + 2022-07-14T00:54:00.000Z + + + vjudeu + 2022-07-14T09:33:00.000Z + + + Erik Aronesty + 2022-07-14T09:57:00.000Z + + + Gino Pinuto + 2022-07-14T11:42:00.000Z + + + Erik Aronesty + 2022-07-14T16:01:00.000Z + + + Manuel Costa + 2022-07-14T16:27:00.000Z + + + vjudeu + 2022-07-15T06:03:00.000Z + + @@ -143,13 +181,13 @@ - python-feedgen + 2 Combined summary - Security problems with relying on transaction fees for security - 2023-08-02T07:00:56.931840+00:00 + 2025-09-26T14:24:06.340896+00:00 - According to a recent discussion on the bitcoin-dev mailing list, there are several important considerations regarding the emission curve and distribution of coins in Bitcoin. The shape of the emission curve is crucial for ensuring a fair distribution, as poorly shaped curves can lead to uneven distribution. Bitcoin's emission curve lasts over 100 years, with a small amount of bitcoin being emitted during the last 100 years from 2040-2140. In terms of expected time of emission, Bitcoin's curve equals about six years.The discussion also compares the emission curves of various cryptocurrencies. PoS coins like Algorand have an expected emission time of 0, indicating a rapid emission rate. However, there is one coin whose expected emission time is larger than Bitcoin's, at approximately 50 years. Another coin, Dogecoin (DOGE), has recently joined the ranks with an expected emission time of 33 years. This limited supply characteristic of Bitcoin and DOGE is seen as a positive attribute for investors, which may attract more attention to these coins.The debate on designing protocols for "price go up forever" is discussed, with differing perspectives within the Bitcoin community. Some argue that protocols should be designed based on the belief that Bitcoin will grow in utility compared to fiat currencies. They believe that if Bitcoin fails to do so, then there would be no point in using it anyway. Others, however, express concern over designing protocols with assumptions of perpetual price growth, considering it a bad idea. This highlights the importance of careful protocol design to ensure the long-term success and sustainability of the network.BIP119, also known as OP_CTV, is mentioned as a design that enables value to be assigned in a predetermined tree of payments. This allows for batched transactions and smoothing out mining fees. OP_CTV can also be used to shift transaction fees to later blocks, providing an effective solution whenever smoothing transaction fees would be beneficial. It is noted that OP_CTV allows for slightly different payment channels compared to the existing Lightning Network, enabling onboarding of a large number of individuals to payment channels.The future of mining is discussed, with the suggestion that it could become a public service rather than a for-profit business model. Game theory suggests that large holders will likely be the major players in mining, and they have the means, ability, and incentive to secure their funds. The importance of advertising this fact is emphasized. It is also mentioned that mining will need to transition to a public service when there is a backlog and every nation is on board for game theoretic reasons.Peter Todd suggests emergency measures to smooth out fees, such as having a separate mandatory category of fees or using a fixed minimum fee that is repaid by the miner into a pool. These suggestions aim to address the issue of fee smoothing effectively. The conversation also touches on the topic of using bribes to incentivize miners to build on a particular block, with considerations of centralization pressure and the viability of leaving transactions in the mempool as incentives.In a recent discussion on the bitcoin-dev mailing list, the potential consequences of relying solely on transaction fees for Bitcoin's security were explored. One concern raised was the established day/night cycle with fees dropping to zero overnight and longer gaps on weekends and holidays. This could result in fewer blocks being mined overnight and miners adopting strategies such as waiting for enough fees in the mempool before attempting to make a block. However, this strategy may lead to miners with lower costs of operation reorging the last hour of the day overnight, causing miners with more expensive operations to stop mining preemptively. This slippery slope could ultimately result in a mining cabal that attacks the whole system.To address this issue, several potential solutions were suggested. One proposal involved having transaction fees be about 10% of rewards on average, striking a balance between incentivizing fee collection and avoiding skewed incentives. Another suggestion was to smooth out fees over time by having wallets collect dust during periods of low transaction fees. Additionally, creating a user experience that clarifies when transactions may take longer but are reliable could help alleviate user aversion to longer transaction times.However, some unrealistic solutions were also proposed, such as dragging most of East Asia eastward to a later time zone or hard forking in fixed rewards in perpetuity. These solutions were deemed problematic and impractical.Overall, the discussion highlighted the importance of considering the potential impact of transaction fees on Bitcoin's security and the need to find feasible measures to address any potential issues that may arise. 2022-07-15T06:03:57+00:00 + According to a recent discussion on the bitcoin-dev mailing list, there are several important considerations regarding the emission curve and distribution of coins in Bitcoin. The shape of the emission curve is crucial for ensuring a fair distribution, as poorly shaped curves can lead to uneven distribution. Bitcoin's emission curve lasts over 100 years, with a small amount of bitcoin being emitted during the last 100 years from 2040-2140. In terms of expected time of emission, Bitcoin's curve equals about six years.The discussion also compares the emission curves of various cryptocurrencies. PoS coins like Algorand have an expected emission time of 0, indicating a rapid emission rate. However, there is one coin whose expected emission time is larger than Bitcoin's, at approximately 50 years. Another coin, Dogecoin (DOGE), has recently joined the ranks with an expected emission time of 33 years. This limited supply characteristic of Bitcoin and DOGE is seen as a positive attribute for investors, which may attract more attention to these coins.The debate on designing protocols for "price go up forever" is discussed, with differing perspectives within the Bitcoin community. Some argue that protocols should be designed based on the belief that Bitcoin will grow in utility compared to fiat currencies. They believe that if Bitcoin fails to do so, then there would be no point in using it anyway. Others, however, express concern over designing protocols with assumptions of perpetual price growth, considering it a bad idea. This highlights the importance of careful protocol design to ensure the long-term success and sustainability of the network.BIP119, also known as OP_CTV, is mentioned as a design that enables value to be assigned in a predetermined tree of payments. This allows for batched transactions and smoothing out mining fees. OP_CTV can also be used to shift transaction fees to later blocks, providing an effective solution whenever smoothing transaction fees would be beneficial. It is noted that OP_CTV allows for slightly different payment channels compared to the existing Lightning Network, enabling onboarding of a large number of individuals to payment channels.The future of mining is discussed, with the suggestion that it could become a public service rather than a for-profit business model. Game theory suggests that large holders will likely be the major players in mining, and they have the means, ability, and incentive to secure their funds. The importance of advertising this fact is emphasized. It is also mentioned that mining will need to transition to a public service when there is a backlog and every nation is on board for game theoretic reasons.Peter Todd suggests emergency measures to smooth out fees, such as having a separate mandatory category of fees or using a fixed minimum fee that is repaid by the miner into a pool. These suggestions aim to address the issue of fee smoothing effectively. The conversation also touches on the topic of using bribes to incentivize miners to build on a particular block, with considerations of centralization pressure and the viability of leaving transactions in the mempool as incentives.In a recent discussion on the bitcoin-dev mailing list, the potential consequences of relying solely on transaction fees for Bitcoin's security were explored. One concern raised was the established day/night cycle with fees dropping to zero overnight and longer gaps on weekends and holidays. This could result in fewer blocks being mined overnight and miners adopting strategies such as waiting for enough fees in the mempool before attempting to make a block. However, this strategy may lead to miners with lower costs of operation reorging the last hour of the day overnight, causing miners with more expensive operations to stop mining preemptively. This slippery slope could ultimately result in a mining cabal that attacks the whole system.To address this issue, several potential solutions were suggested. One proposal involved having transaction fees be about 10% of rewards on average, striking a balance between incentivizing fee collection and avoiding skewed incentives. Another suggestion was to smooth out fees over time by having wallets collect dust during periods of low transaction fees. Additionally, creating a user experience that clarifies when transactions may take longer but are reliable could help alleviate user aversion to longer transaction times.However, some unrealistic solutions were also proposed, such as dragging most of East Asia eastward to a later time zone or hard forking in fixed rewards in perpetuity. These solutions were deemed problematic and impractical.Overall, the discussion highlighted the importance of considering the potential impact of transaction fees on Bitcoin's security and the need to find feasible measures to address any potential issues that may arise. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml b/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml index e1cfec147d..cb933636f9 100644 --- a/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml +++ b/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2023-08-02T06:56:36.748113+00:00 + 2025-09-26T14:24:29.854293+00:00 + python-feedgen Billy Tetrud 2022-08-20 15:30:26+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2023-08-02T06:56:36.750118+00:00 + 2025-09-26T14:24:29.854525+00:00 - The context discusses various discussions and debates related to the functioning and security of the Bitcoin network. One aspect discussed is the concept of "free lunches" in the network, where some users benefit without contributing, while others bear the costs. It is argued that this is an unhealthy state for the financial system and may not be sustainable in the long term.One suggestion to address this issue is to remove halvings, which are events that reduce the block reward for miners, if they become destructive to the network's security. It is also mentioned that a balanced system with a low annual inflation rate is preferable to any fiat system. While widespread consensus would be ideal, it is acknowledged that a hard fork may be necessary to implement necessary changes.The feasibility of large Bitcoin holders running ASICs to secure their holdings is also discussed. The assumption is made that fees alone may not compensate for low block rewards, and therefore, large holders may mine at a loss to preserve the value of their holdings. However, it is acknowledged that this approach may not work in practice due to trust issues and the potential for betrayal.The concept of the Prisoner's Dilemma is mentioned in relation to cooperation between Bitcoin users. It is highlighted that even though cooperation may be in the best interest of both parties, mistrust and self-interest can lead to suboptimal outcomes.The importance of transaction fees in providing censorship resistance and incentivizing miners to keep the network secure is emphasized. The discussion explores different approaches, such as tying miner revenue to the total value of Bitcoin or relying solely on transaction fees.There are debates about the business model of miners who intend to censor transactions when there is no block reward. It is argued that transaction fees provide censorship resistance, and miners may prioritize high fee transactions to maximize their earnings.The role of the block reward in the functioning of the Bitcoin network is highlighted. The question is raised about whether a perpetual block subsidy should be tied to the total value of Bitcoin or if other methods should be considered to incentivize miners.The assumption of a constant rate for losses in Bitcoin is challenged, and it is argued that losses can occur at a predictable rate. The potential impact of lost coins on the overall value of Bitcoin is discussed.There are also discussions about the subjective nature of defining Bitcoin and the role of leading bodies versus individual autonomy. The importance of the capped supply and predictable issuance curve is mentioned, and tinkering with the protocol is seen as potentially inviting further subversion.The discussion revolves around the predictability of losses in tail emission. While Peter assumes that there is a rate, it is possible for losses to be at a different predictable rate. However, if there exists any fixed central tendency for the rate, tail emission will eventually become non-inflationary. There are two other factors to consider: firstly, if people improve custody faster than 1/(N(t)*P), tail emission can still be inflationary, although this seems unlikely. Secondly, the rate is somewhat stochastic, with "black swan events" like popular wallet losing keys in coding error being possible but not relevant to tail-emission being non-inflationary. However, even such events can be factored into a fixed central tendency over a long enough time period.In the discussion on whether or not to extend block rewards after the current deadline, it is noted that this is only relevant if the community agrees that it is necessary to maintain network security. It is worth noting that a mild inflation can sometimes be compensated by coin loss, which is like a bonus. The assumption of a constant coin loss rate seems unreasonable as people improve their key storage habits over time, leading to a decrease in the rate of coin loss. Additionally, there may be common causes for coin losses that result in heavily correlated losses rather than independent ones.The conversation further explores the potential implications of tail emission on the ability of individuals to access their coins. Todd clarifies that his proposal does not involve re-assigning ownership of coins and therefore does not take away anyone's ability to access their coins. The concern raised by naman naman about the ability to move coins after a long period of inactivity is addressed, with Todd stating that his article on tail emission is focused on maintaining blockchain security without causing inflation.The latest blog post by Peter Todd titled "Surprisingly, Tail Emission Is Not Inflationary" explores the concept of tail emission and its impact on the supply of Bitcoin. Todd argues that tail emission, which is a fixed reward per block that continues indefinitely, can result in a stable monetary supply rather than a monetarily inflationary one. He explains that lost coins contribute to this stability, as they are constantly being lost due to various factors such as deaths, forgotten passphrases, and accidents.The article also discusses the feasibility of implementing tail emission in Bitcoin. While other currencies like Monero have successfully implemented it, adding tail emission to Bitcoin would require convincing a substantial fraction of the Bitcoin community to support the idea. Todd suggests that 2022-08-20T15:30:26+00:00 + The context discusses various discussions and debates related to the functioning and security of the Bitcoin network. One aspect discussed is the concept of "free lunches" in the network, where some users benefit without contributing, while others bear the costs. It is argued that this is an unhealthy state for the financial system and may not be sustainable in the long term.One suggestion to address this issue is to remove halvings, which are events that reduce the block reward for miners, if they become destructive to the network's security. It is also mentioned that a balanced system with a low annual inflation rate is preferable to any fiat system. While widespread consensus would be ideal, it is acknowledged that a hard fork may be necessary to implement necessary changes.The feasibility of large Bitcoin holders running ASICs to secure their holdings is also discussed. The assumption is made that fees alone may not compensate for low block rewards, and therefore, large holders may mine at a loss to preserve the value of their holdings. However, it is acknowledged that this approach may not work in practice due to trust issues and the potential for betrayal.The concept of the Prisoner's Dilemma is mentioned in relation to cooperation between Bitcoin users. It is highlighted that even though cooperation may be in the best interest of both parties, mistrust and self-interest can lead to suboptimal outcomes.The importance of transaction fees in providing censorship resistance and incentivizing miners to keep the network secure is emphasized. The discussion explores different approaches, such as tying miner revenue to the total value of Bitcoin or relying solely on transaction fees.There are debates about the business model of miners who intend to censor transactions when there is no block reward. It is argued that transaction fees provide censorship resistance, and miners may prioritize high fee transactions to maximize their earnings.The role of the block reward in the functioning of the Bitcoin network is highlighted. The question is raised about whether a perpetual block subsidy should be tied to the total value of Bitcoin or if other methods should be considered to incentivize miners.The assumption of a constant rate for losses in Bitcoin is challenged, and it is argued that losses can occur at a predictable rate. The potential impact of lost coins on the overall value of Bitcoin is discussed.There are also discussions about the subjective nature of defining Bitcoin and the role of leading bodies versus individual autonomy. The importance of the capped supply and predictable issuance curve is mentioned, and tinkering with the protocol is seen as potentially inviting further subversion.The discussion revolves around the predictability of losses in tail emission. While Peter assumes that there is a rate, it is possible for losses to be at a different predictable rate. However, if there exists any fixed central tendency for the rate, tail emission will eventually become non-inflationary. There are two other factors to consider: firstly, if people improve custody faster than 1/(N(t)*P), tail emission can still be inflationary, although this seems unlikely. Secondly, the rate is somewhat stochastic, with "black swan events" like popular wallet losing keys in coding error being possible but not relevant to tail-emission being non-inflationary. However, even such events can be factored into a fixed central tendency over a long enough time period.In the discussion on whether or not to extend block rewards after the current deadline, it is noted that this is only relevant if the community agrees that it is necessary to maintain network security. It is worth noting that a mild inflation can sometimes be compensated by coin loss, which is like a bonus. The assumption of a constant coin loss rate seems unreasonable as people improve their key storage habits over time, leading to a decrease in the rate of coin loss. Additionally, there may be common causes for coin losses that result in heavily correlated losses rather than independent ones.The conversation further explores the potential implications of tail emission on the ability of individuals to access their coins. Todd clarifies that his proposal does not involve re-assigning ownership of coins and therefore does not take away anyone's ability to access their coins. The concern raised by naman naman about the ability to move coins after a long period of inactivity is addressed, with Todd stating that his article on tail emission is focused on maintaining blockchain security without causing inflation.The latest blog post by Peter Todd titled "Surprisingly, Tail Emission Is Not Inflationary" explores the concept of tail emission and its impact on the supply of Bitcoin. Todd argues that tail emission, which is a fixed reward per block that continues indefinitely, can result in a stable monetary supply rather than a monetarily inflationary one. He explains that lost coins contribute to this stability, as they are constantly being lost due to various factors such as deaths, forgotten passphrases, and accidents.The article also discusses the feasibility of implementing tail emission in Bitcoin. While other currencies like Monero have successfully implemented it, adding tail emission to Bitcoin would require convincing a substantial fraction of the Bitcoin community to support the idea. Todd suggests that - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml b/static/bitcoin-dev/July_2022/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml index 1c6cc48fb4..fd55cf1578 100644 --- a/static/bitcoin-dev/July_2022/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml +++ b/static/bitcoin-dev/July_2022/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - TAPLEAF_UPDATE_VERIFY covenant opcode - 2023-08-02T04:43:31.285155+00:00 - - Tim Ruffing 2022-07-08 19:52:12+00:00 - - - Billy Tetrud 2021-10-29 15:47:12+00:00 - - - Olaoluwa Osuntokun 2021-09-23 00:29:18+00:00 - - - Antoine Riard 2021-09-22 01:40:16+00:00 - - - Anthony Towns 2021-09-20 14:52:46+00:00 - - - Antoine Riard 2021-09-18 14:11:10+00:00 - - - Anthony Towns 2021-09-15 06:50:51+00:00 - - - Antoine Riard 2021-09-12 23:37:56+00:00 - - - Anthony Towns 2021-09-11 03:26:44+00:00 - - - Anthony Towns 2021-09-10 07:42:19+00:00 - - - Antoine Riard 2021-09-10 04:12:24+00:00 - - - Jeremy 2021-09-09 19:26:37+00:00 - - - Jeremy 2021-09-09 15:54:25+00:00 - - - darosior 2021-09-09 12:56:10+00:00 - - - Matt Corallo 2021-09-09 09:16:12+00:00 - - - Anthony Towns 2021-09-09 06:53:30+00:00 - - - Anthony Towns 2021-09-09 06:41:38+00:00 - + 2025-09-26T14:24:40.541236+00:00 + python-feedgen + + + [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode Anthony Towns + 2021-09-09T06:41:00.000Z + + + Anthony Towns + 2021-09-09T06:53:00.000Z + + + Matt Corallo + 2021-09-09T09:16:00.000Z + + + darosior + 2021-09-09T12:56:00.000Z + + + Jeremy + 2021-09-09T15:54:00.000Z + + + Jeremy + 2021-09-09T19:26:00.000Z + + + Antoine Riard + 2021-09-10T04:12:00.000Z + + + Anthony Towns + 2021-09-10T07:42:00.000Z + + + Anthony Towns + 2021-09-11T03:26:00.000Z + + + Antoine Riard + 2021-09-12T23:37:00.000Z + + + Anthony Towns + 2021-09-15T06:50:00.000Z + + + Antoine Riard + 2021-09-18T14:11:00.000Z + + + Anthony Towns + 2021-09-20T14:52:00.000Z + + + Antoine Riard + 2021-09-22T01:40:00.000Z + + + Olaoluwa Osuntokun + 2021-09-23T00:29:00.000Z + + + Billy Tetrud + 2021-10-29T15:47:00.000Z + + + Tim Ruffing + 2022-07-08T19:52:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - TAPLEAF_UPDATE_VERIFY covenant opcode - 2023-08-02T04:43:31.285155+00:00 + 2025-09-26T14:24:40.543153+00:00 - In the context of Taproot and off-chain contract transactions, the conversation revolves around proposing new opcodes and discussing various optimizations and security concerns. One proposal is for a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV), which would allow for updating the internal public key, specifying a new step for the merkle path, and removing scripts or merkle path steps. The author suggests modifying the proposal to obtain the script from the annex, making it more powerful and allowing for dynamic script updates. This modification would require the addition of an OP_PUSH_ANNEX opcode.The discussion also touches on the issue of utxos interacting with each other and proposes the use of a fixed ID to identify contracts. This would allow transactions to spend/interact with a contract without needing to know the set of active utxos where that contract lives. Nodes would need to maintain an extra index into the UTXO set, but this can be alleviated with a utreexo-like solution.Another topic of discussion is the design and implementation of specific capabilities for off-chain contract transactions. Suggestions include splitting funds between multiple parties, selective withdrawals based on time or conditions, and using opcodes like IN_OUT_AMOUNT to specify authorized withdrawal ranges for hot wallets. Security concerns, such as replay attacks and trust in counterparty cooperation, are also addressed.The conversation explores different ways to optimize Taproot's smart contract capabilities while maintaining security and reliability. The MERKLESUB opcode is discussed, highlighting its ability to refer to non-corresponding outputs but lacking certain abilities like adding branches or preserving current scripts. Trade-offs and potential solutions are proposed, including extending the signature digest algorithm and introducing a new opcode.Overall, the participants show a deep understanding of the technical complexities involved in designing and implementing off-chain contract transactions. They discuss various proposals, optimizations, and security considerations to enhance the functionality and usability of Taproot and off-chain contracts on the Bitcoin network.Anthony Towns discusses Taproot and proposes splitting the discussion into two parts. The first part focuses on improving the functionality and efficiency of transactions using Taproot scripts. This involves updating a UTXO by changing the taproot tree using a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV). This enables the creation of more complex covenants that limit hot wallet withdrawals, protect funds with both hot and cold wallet keys, and verify that funds are being appropriately retained in the updated scriptPubKey.The second part of the discussion addresses more efficient and private one-in, one-out transactions within a pooled fund represented by a UTXO. However, this method requires everyone in the pool to be online to sign via the key path, which can limit the number of people who can reasonably be included in a pool before there's a breakdown. This enables joint funding of ventures, where participants put BTC into a pooled UTXO, ready to finalize the purchase of land while having the ability to reclaim their funds if the deal falls through.Despite these advantages, both proposals have limitations. The first proposal cannot tweak scripts in areas of the merkle tree that it cannot see, while the second proposal requires all members of the pool to be online to sign via the key path. Bitcoin developer AJ Towns believes that these limitations could be simulated with CAT and CHECKSIGFROMSTACK but introducing dedicated opcodes for this functionality would make the feature easier to use correctly and cheap and efficient for both wallets and nodes to validate.In addition to the discussion on Taproot, Anthony Towns also addresses other aspects related to Taproot implementation. He suggests upgrading ADD, SUB, and the comparison operators to support 64-bit values to resolve issues with complicated calculations. He also discusses TLUV, which controls how spending scripts can change between input sPK and output sPK, and proposes a script for implementing the release/locked/available vault construct. Furthermore, he explores the issue of TLUV's parity in taproot addresses and suggests various approaches to solve it.The context also mentions constructing hashes programmatically using "OP_CAT" or similar functionality, allowing for interesting behavior such as adding oneself to a pool if they contribute at least 10 BTC. However, using templates is necessary when constructing a new script programmatically to ensure efficiency. There is a caveat that people could bypass covenant constraints if allowed to add arbitrary opcodes.Towns further discusses the pooled scheme and updating the internal pubkey, which becomes complicated due to the use of 32-byte x-only pubkeys for the scriptPubKey and the internal public key. He provides an example scenario where removing a participant from the pool might result in switching the scriptPubKey, causing potential issues with key path spends.Overall, the context provides a detailed discussion of various aspects of Taproot and potential issues that may arise when constructing a new script programmatically. While Towns proposes solutions to these issues, there are still caveats to consider. The article concludes by suggesting that dedicated opcodes for this functionality would make 2022-07-08T19:52:12+00:00 + In the context of Taproot and off-chain contract transactions, the conversation revolves around proposing new opcodes and discussing various optimizations and security concerns. One proposal is for a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV), which would allow for updating the internal public key, specifying a new step for the merkle path, and removing scripts or merkle path steps. The author suggests modifying the proposal to obtain the script from the annex, making it more powerful and allowing for dynamic script updates. This modification would require the addition of an OP_PUSH_ANNEX opcode.The discussion also touches on the issue of utxos interacting with each other and proposes the use of a fixed ID to identify contracts. This would allow transactions to spend/interact with a contract without needing to know the set of active utxos where that contract lives. Nodes would need to maintain an extra index into the UTXO set, but this can be alleviated with a utreexo-like solution.Another topic of discussion is the design and implementation of specific capabilities for off-chain contract transactions. Suggestions include splitting funds between multiple parties, selective withdrawals based on time or conditions, and using opcodes like IN_OUT_AMOUNT to specify authorized withdrawal ranges for hot wallets. Security concerns, such as replay attacks and trust in counterparty cooperation, are also addressed.The conversation explores different ways to optimize Taproot's smart contract capabilities while maintaining security and reliability. The MERKLESUB opcode is discussed, highlighting its ability to refer to non-corresponding outputs but lacking certain abilities like adding branches or preserving current scripts. Trade-offs and potential solutions are proposed, including extending the signature digest algorithm and introducing a new opcode.Overall, the participants show a deep understanding of the technical complexities involved in designing and implementing off-chain contract transactions. They discuss various proposals, optimizations, and security considerations to enhance the functionality and usability of Taproot and off-chain contracts on the Bitcoin network.Anthony Towns discusses Taproot and proposes splitting the discussion into two parts. The first part focuses on improving the functionality and efficiency of transactions using Taproot scripts. This involves updating a UTXO by changing the taproot tree using a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV). This enables the creation of more complex covenants that limit hot wallet withdrawals, protect funds with both hot and cold wallet keys, and verify that funds are being appropriately retained in the updated scriptPubKey.The second part of the discussion addresses more efficient and private one-in, one-out transactions within a pooled fund represented by a UTXO. However, this method requires everyone in the pool to be online to sign via the key path, which can limit the number of people who can reasonably be included in a pool before there's a breakdown. This enables joint funding of ventures, where participants put BTC into a pooled UTXO, ready to finalize the purchase of land while having the ability to reclaim their funds if the deal falls through.Despite these advantages, both proposals have limitations. The first proposal cannot tweak scripts in areas of the merkle tree that it cannot see, while the second proposal requires all members of the pool to be online to sign via the key path. Bitcoin developer AJ Towns believes that these limitations could be simulated with CAT and CHECKSIGFROMSTACK but introducing dedicated opcodes for this functionality would make the feature easier to use correctly and cheap and efficient for both wallets and nodes to validate.In addition to the discussion on Taproot, Anthony Towns also addresses other aspects related to Taproot implementation. He suggests upgrading ADD, SUB, and the comparison operators to support 64-bit values to resolve issues with complicated calculations. He also discusses TLUV, which controls how spending scripts can change between input sPK and output sPK, and proposes a script for implementing the release/locked/available vault construct. Furthermore, he explores the issue of TLUV's parity in taproot addresses and suggests various approaches to solve it.The context also mentions constructing hashes programmatically using "OP_CAT" or similar functionality, allowing for interesting behavior such as adding oneself to a pool if they contribute at least 10 BTC. However, using templates is necessary when constructing a new script programmatically to ensure efficiency. There is a caveat that people could bypass covenant constraints if allowed to add arbitrary opcodes.Towns further discusses the pooled scheme and updating the internal pubkey, which becomes complicated due to the use of 32-byte x-only pubkeys for the scriptPubKey and the internal public key. He provides an example scenario where removing a participant from the pool might result in switching the scriptPubKey, causing potential issues with key path spends.Overall, the context provides a detailed discussion of various aspects of Taproot and potential issues that may arise when constructing a new script programmatically. While Towns proposes solutions to these issues, there are still caveats to consider. The article concludes by suggesting that dedicated opcodes for this functionality would make - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Trying-all-address-types-in-message-signing-verification-BIP-.xml b/static/bitcoin-dev/July_2022/combined_Trying-all-address-types-in-message-signing-verification-BIP-.xml index 91187f904c..6775b3407a 100644 --- a/static/bitcoin-dev/July_2022/combined_Trying-all-address-types-in-message-signing-verification-BIP-.xml +++ b/static/bitcoin-dev/July_2022/combined_Trying-all-address-types-in-message-signing-verification-BIP-.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Trying all address types in message signing verification (BIP) - 2023-08-02T07:03:29.248557+00:00 - - Ryan Grant 2022-07-23 04:28:08+00:00 - - - Ali Sherief 2022-07-22 15:20:24+00:00 - - - Craig Raw 2022-07-21 07:06:08+00:00 - - - Ali Sherief 2022-07-21 05:36:11+00:00 - - - Greg Sanders 2022-07-20 21:50:53+00:00 - - - Peter (Coinkite Inc) 2022-07-20 13:31:21+00:00 - - - Ali Sherief 2022-07-20 04:10:09+00:00 - + 2025-09-26T14:24:17.024391+00:00 + python-feedgen + + + [bitcoin-dev] Trying all address types in message signing verification (BIP) Ali Sherief + 2022-07-20T04:10:00.000Z + + + Peter (Coinkite Inc) + 2022-07-20T13:31:00.000Z + + + Greg Sanders + 2022-07-20T21:50:00.000Z + + + Ali Sherief + 2022-07-21T05:36:00.000Z + + + Craig Raw + 2022-07-21T07:06:00.000Z + + + Ali Sherief + 2022-07-22T15:20:00.000Z + + + Ryan Grant + 2022-07-23T04:28:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Trying all address types in message signing verification (BIP) - 2023-08-02T07:03:29.248557+00:00 + 2025-09-26T14:24:17.025245+00:00 - In a recent email, Peter from Coinkite Inc mentioned that the BIP-322 proposals did not gain wide acceptance in the past. However, there is renewed interest in using BIP322 to validate signatures related to upgrading the Bitcoin-native Decentralized Identifier Method (did:btcr) beyond its current specification, to version 2.0. This has been discussed in detail in the advance-readings of the RWOT11 conference in The Hague and in the DID Core specification document by W3C. The proposed use of BIP322 would allow for improved security and privacy in the handling of decentralized identifiers on the Bitcoin blockchain.Ali Sherief proposed a BIP to address the lack of standardization for Segwit message signatures. Currently, wallets that support signing and verifying a Bitcoin message can only sign legacy addresses. Although it is technically possible to sign and verify segwit addresses, the absence of an accepted standard for signing segwit messages means that wallets that do support this feature simply insert the segwit address into the address field. Verification also only works using the procedure on that specific wallet software. This BIP does not enforce anything but sets guidelines for writing a message signing and verification procedure. The proposal standardizes the practice of placing the segwit address into the address field and does not require alterations to the message signing format like those in BIPs 173 or 322.In the verification part, the following address hashing algorithms will be tried in sequence in an attempt to reconstruct the address in the signed message: P2PKH (legacy address), P2WPKH-P2SH (nested segwit), and P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with version 0 as well as future native segwit address types such as Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness version by the bech32 encoding. The verification procedure stops if any of these hashes yield the correct address, and fails if all of the above methods fail to reproduce the address in the signed message.In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message. The proposal does not require any changes to existing signed messages, and the original sign/verify algorithms will continue to interoperate with this improved sign/verify algorithm, without any action necessary from the developers.Craig Raw verifies the signature by converting the message and signature to a public key, trying first BIP137 and then the approach used by Electrum. The script type is extracted from the provided address and compared against the address constructed with the public key using the same script type. BIP322 is suggested as a reference, which was not widely accepted.The original approach for signing segwit messages was directly from Satoshi himself and has never been codified in a BIP. The proposal does not replace, supersede, or obsolete BIPs 173 or 322 and only aims to standardize the practice of placing the segwit address into the address field. However, any universal BIP that encompasses all signatures would have to check for BIP137 signatures. Fortunately, only the verification algorithm needs to be adjusted to identify BIP137 signatures.Ali Sherief, a developer, is proposing to create a Bitcoin Improvement Proposal (BIP) to address the lack of standardization for Segwit message signatures. Currently, wallets that support signing and verifying a bitcoin message can only sign legacy addresses. There is no generally-accepted standard for signing segwit messages. Ali's proposal will standardize the practice of placing the segwit address into the address field and set guidelines for writing a message signing and verification procedure.The BIP does not replace, supersede, or obsolete BIPs 173 or 322. In the verification part of the proposal, P2PKH (legacy address), P2WPKH-P2SH (nested segwit), and P2WPKH with version from 0 to MAX_WITNESS_VERSION will be tried in sequence in an attempt to reconstruct the address in the signed message. If any of these hashes yield the correct address, the verification procedure stops, and it fails if all of the above methods fail to reproduce the address in the signed message.In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message. Ali plans to add a Python example for the signing and verification process, which can be translated to C++ without even minor interface/implementation difficulties. However, Bitcoin Core does not currently support verifying the message as its UX makes it look possible, but in effect, segwit features never got implemented to that depth in Core. Peter (Coinkite Inc) suggests that a "defacto" BIP is needed, and Core should be updated to support it. The author seeks advice from the mailing list on how to draft such a BIP 2022-07-23T04:28:08+00:00 + In a recent email, Peter from Coinkite Inc mentioned that the BIP-322 proposals did not gain wide acceptance in the past. However, there is renewed interest in using BIP322 to validate signatures related to upgrading the Bitcoin-native Decentralized Identifier Method (did:btcr) beyond its current specification, to version 2.0. This has been discussed in detail in the advance-readings of the RWOT11 conference in The Hague and in the DID Core specification document by W3C. The proposed use of BIP322 would allow for improved security and privacy in the handling of decentralized identifiers on the Bitcoin blockchain.Ali Sherief proposed a BIP to address the lack of standardization for Segwit message signatures. Currently, wallets that support signing and verifying a Bitcoin message can only sign legacy addresses. Although it is technically possible to sign and verify segwit addresses, the absence of an accepted standard for signing segwit messages means that wallets that do support this feature simply insert the segwit address into the address field. Verification also only works using the procedure on that specific wallet software. This BIP does not enforce anything but sets guidelines for writing a message signing and verification procedure. The proposal standardizes the practice of placing the segwit address into the address field and does not require alterations to the message signing format like those in BIPs 173 or 322.In the verification part, the following address hashing algorithms will be tried in sequence in an attempt to reconstruct the address in the signed message: P2PKH (legacy address), P2WPKH-P2SH (nested segwit), and P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with version 0 as well as future native segwit address types such as Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness version by the bech32 encoding. The verification procedure stops if any of these hashes yield the correct address, and fails if all of the above methods fail to reproduce the address in the signed message.In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message. The proposal does not require any changes to existing signed messages, and the original sign/verify algorithms will continue to interoperate with this improved sign/verify algorithm, without any action necessary from the developers.Craig Raw verifies the signature by converting the message and signature to a public key, trying first BIP137 and then the approach used by Electrum. The script type is extracted from the provided address and compared against the address constructed with the public key using the same script type. BIP322 is suggested as a reference, which was not widely accepted.The original approach for signing segwit messages was directly from Satoshi himself and has never been codified in a BIP. The proposal does not replace, supersede, or obsolete BIPs 173 or 322 and only aims to standardize the practice of placing the segwit address into the address field. However, any universal BIP that encompasses all signatures would have to check for BIP137 signatures. Fortunately, only the verification algorithm needs to be adjusted to identify BIP137 signatures.Ali Sherief, a developer, is proposing to create a Bitcoin Improvement Proposal (BIP) to address the lack of standardization for Segwit message signatures. Currently, wallets that support signing and verifying a bitcoin message can only sign legacy addresses. There is no generally-accepted standard for signing segwit messages. Ali's proposal will standardize the practice of placing the segwit address into the address field and set guidelines for writing a message signing and verification procedure.The BIP does not replace, supersede, or obsolete BIPs 173 or 322. In the verification part of the proposal, P2PKH (legacy address), P2WPKH-P2SH (nested segwit), and P2WPKH with version from 0 to MAX_WITNESS_VERSION will be tried in sequence in an attempt to reconstruct the address in the signed message. If any of these hashes yield the correct address, the verification procedure stops, and it fails if all of the above methods fail to reproduce the address in the signed message.In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message. Ali plans to add a Python example for the signing and verification process, which can be translated to C++ without even minor interface/implementation difficulties. However, Bitcoin Core does not currently support verifying the message as its UX makes it look possible, but in effect, segwit features never got implemented to that depth in Core. Peter (Coinkite Inc) suggests that a "defacto" BIP is needed, and Core should be updated to support it. The author seeks advice from the mailing list on how to draft such a BIP - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_Zero-knowledge-proofs-e-g-Schnorr-are-incompatible-with-address-signing-without-compromise.xml b/static/bitcoin-dev/July_2022/combined_Zero-knowledge-proofs-e-g-Schnorr-are-incompatible-with-address-signing-without-compromise.xml index a7bf536b5b..d97611a9bc 100644 --- a/static/bitcoin-dev/July_2022/combined_Zero-knowledge-proofs-e-g-Schnorr-are-incompatible-with-address-signing-without-compromise.xml +++ b/static/bitcoin-dev/July_2022/combined_Zero-knowledge-proofs-e-g-Schnorr-are-incompatible-with-address-signing-without-compromise.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Zero-knowledge proofs e.g. Schnorr are incompatible with address signing without compromise - 2023-08-02T07:13:50.255363+00:00 - - Pieter Wuille 2022-07-28 15:58:03+00:00 - - - Ali Sherief 2022-07-28 15:51:18+00:00 - - - Pieter Wuille 2022-07-28 15:27:05+00:00 - - - Ali Sherief 2022-07-28 07:27:02+00:00 - + 2025-09-26T14:24:08.456387+00:00 + python-feedgen + + + [bitcoin-dev] Zero-knowledge proofs e.g. Schnorr are incompatible with address signing without compromise Ali Sherief + 2022-07-28T07:27:00.000Z + + + Pieter Wuille + 2022-07-28T15:27:00.000Z + + + Ali Sherief + 2022-07-28T15:51:00.000Z + + + Pieter Wuille + 2022-07-28T15:58:00.000Z + + - python-feedgen + 2 Combined summary - Zero-knowledge proofs e.g. Schnorr are incompatible with address signing without compromise - 2023-08-02T07:13:50.255363+00:00 + 2025-09-26T14:24:08.456992+00:00 - In a discussion about Bitcoin Improvement Proposal (BIP) 340, Ali Sherief sought clarification on the recovery of public keys from single-key signatures. The response clarified that BIP340 does not support key recovery and that a choice had to be made between supporting batch validation or public key recovery. Ultimately, it was decided to prioritize batch validation. The conversation then shifted to the implementation of BIP340 in taproot compatible wallets. It was stated that while some wallets lack a sign message feature, every taproot compatible wallet has a BIP340 implementation for transaction signing. If a wallet supports taproot signing, it already has the necessary code for producing BIP340 signatures, making message signing irrelevant if taproot signing is not supported.During the BIP340 discussion, it was emphasized that the intentional design choice in BIP340 is either batch verifiability or public key recovery. The topic of recovering a public key from a single-key signature was also addressed. Ali Sherief planned to concatenate the public key after the signature, rather than appending it after the Taproot address due to its unruly nature. The suggestion was made to work on BIP322, which is compatible with all script types, not limited to single-key policies, and easily adaptable to future schemes. Pieter Wuille added that every Taproot compatible wallet already incorporates a BIP340 implementation.A recent message on the bitcoin-dev mailing list discussed the compatibility of zero-knowledge proofs, such as Schnorr, with address message signing. It was noted that retrieving the public key from the address or signature is not possible, posing a challenge in proving the authenticity of a Schnorr signature. This limitation was an intentional design choice in BIP340, prioritizing batch verifiability over public key recovery. The author of the message expressed regret regarding the use of public key recovery when introducing the legacy message signing scheme, suggesting that script signatures like those proposed in BIP322 would have been a better choice. It was also mentioned that including the public key + BIP340 signature in the encoded signature could avoid reliance on public key recovery. To address compatibility concerns with address signing mechanisms, the author proposed sacrificing the zero-knowledge aspect of their BIP or creating a separate message signing format exclusively for Taproot. However, they believed that this redundancy could be avoided by advancing BIP322, which can verify all script types and accommodate any requirements.In a post on Bitcointalk, the author discussed the implementation of address/message signing support for Taproot, specifically focusing on Schnorr signatures. The author noted that BIP340 has already standardized this, eliminating the need for re-implementation. However, there are certain considerations to keep in mind before implementing this signing format, such as encoding and public key requirements. The article further explained the default signing and verification algorithms for Schnorr signatures, highlighting the incompatibility of zero-knowledge proofs (like Schnorr) with address message signing due to the inability to retrieve the public key from the address or signature. To achieve compatibility with the address signing mechanism, either the zero-knowledge aspect would have to be sacrificed or a separate message signing format would be necessary. The article concluded by questioning whether the community truly desires message signatures considering the increasing discrepancy between legacy addresses and other address types. 2022-07-28T15:58:03+00:00 + In a discussion about Bitcoin Improvement Proposal (BIP) 340, Ali Sherief sought clarification on the recovery of public keys from single-key signatures. The response clarified that BIP340 does not support key recovery and that a choice had to be made between supporting batch validation or public key recovery. Ultimately, it was decided to prioritize batch validation. The conversation then shifted to the implementation of BIP340 in taproot compatible wallets. It was stated that while some wallets lack a sign message feature, every taproot compatible wallet has a BIP340 implementation for transaction signing. If a wallet supports taproot signing, it already has the necessary code for producing BIP340 signatures, making message signing irrelevant if taproot signing is not supported.During the BIP340 discussion, it was emphasized that the intentional design choice in BIP340 is either batch verifiability or public key recovery. The topic of recovering a public key from a single-key signature was also addressed. Ali Sherief planned to concatenate the public key after the signature, rather than appending it after the Taproot address due to its unruly nature. The suggestion was made to work on BIP322, which is compatible with all script types, not limited to single-key policies, and easily adaptable to future schemes. Pieter Wuille added that every Taproot compatible wallet already incorporates a BIP340 implementation.A recent message on the bitcoin-dev mailing list discussed the compatibility of zero-knowledge proofs, such as Schnorr, with address message signing. It was noted that retrieving the public key from the address or signature is not possible, posing a challenge in proving the authenticity of a Schnorr signature. This limitation was an intentional design choice in BIP340, prioritizing batch verifiability over public key recovery. The author of the message expressed regret regarding the use of public key recovery when introducing the legacy message signing scheme, suggesting that script signatures like those proposed in BIP322 would have been a better choice. It was also mentioned that including the public key + BIP340 signature in the encoded signature could avoid reliance on public key recovery. To address compatibility concerns with address signing mechanisms, the author proposed sacrificing the zero-knowledge aspect of their BIP or creating a separate message signing format exclusively for Taproot. However, they believed that this redundancy could be avoided by advancing BIP322, which can verify all script types and accommodate any requirements.In a post on Bitcointalk, the author discussed the implementation of address/message signing support for Taproot, specifically focusing on Schnorr signatures. The author noted that BIP340 has already standardized this, eliminating the need for re-implementation. However, there are certain considerations to keep in mind before implementing this signing format, such as encoding and public key requirements. The article further explained the default signing and verification algorithms for Schnorr signatures, highlighting the incompatibility of zero-knowledge proofs (like Schnorr) with address message signing due to the inability to retrieve the public key from the address or signature. To achieve compatibility with the address signing mechanism, either the zero-knowledge aspect would have to be sacrificed or a separate message signing format would be necessary. The article concluded by questioning whether the community truly desires message signatures considering the increasing discrepancy between legacy addresses and other address types. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_Announcing-Libforesta.xml b/static/bitcoin-dev/July_2023/combined_Announcing-Libforesta.xml index 39a33542d1..8ad8b44383 100644 --- a/static/bitcoin-dev/July_2023/combined_Announcing-Libforesta.xml +++ b/static/bitcoin-dev/July_2023/combined_Announcing-Libforesta.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Announcing Libforesta - 2023-08-11T15:44:04.631800+00:00 - - Davidson Souza 2023-08-03 20:34:04+00:00 - - - leohaf at orangepill.ovh 2023-08-03 14:03:19+00:00 - - - Davidson Souza 2023-08-02 21:32:15+00:00 - - - Bastiaan van den Berg 2023-08-01 08:02:55+00:00 - - - Davidson Souza 2023-07-31 17:47:26+00:00 - + 2025-09-26T14:24:46.949521+00:00 + python-feedgen + + + [bitcoin-dev] Announcing Libforesta Davidson Souza + 2023-07-31T17:47:00.000Z + + + Bastiaan van den Berg + 2023-08-01T08:02:00.000Z + + + Davidson Souza + 2023-08-02T21:32:00.000Z + + + leohaf + 2023-08-03T14:03:00.000Z + + + Davidson Souza + 2023-08-03T20:34:00.000Z + + - python-feedgen + 2 Combined summary - Announcing Libforesta - 2023-08-11T15:44:04.631800+00:00 + 2025-09-26T14:24:46.950308+00:00 - Davidson Souza, the developer of Floresta, has introduced a project called libfloresta to the Bitcoin developers mailing list. Libfloresta is a fully-validating Bitcoin full node with an integrated watch-only wallet and Electrum Server. The main aim of the project is to create a compact and user-friendly full node for low-power devices like single-board computers (SBCs) and smartphones. Davidson is writing the main logic of libfloresta in Rust and generating bindings to the original code, allowing it to run virtually anywhere by compiling it to WebAssembly (WASM). The project is still in its early stages but has been successfully used on signet without any issues. Mainnet support is almost ready, but performance issues with bridge nodes need to be resolved first. The code is available on Davidson's GitHub repository, along with a blog post explaining how to use it in Rust. Davidson plans to write more documentation as the project matures and is deployed on other platforms. Feedback from the community is welcomed. In terms of consensus, libfloresta does not reimplement the Bitcoin Consensus machine from scratch. Instead, it uses libbitcoinconsensus and plans to incorporate the full libbitcoinkernel in the future. This approach minimizes the risk of misimplementations leading to splits. Davidson is also conducting cross-tests against Bitcoin Core to identify any inconsistencies before they become problematic. Davidson expresses gratitude to Vinteum for their support in his work with Utreexo and Floresta. Overall, libfloresta aims to provide a lightweight and user-friendly solution for running a Bitcoin full node, particularly on low-power devices. It offers compatibility with existing Bitcoin infrastructure and can be used alongside Bitcoin Core. 2023-08-03T20:34:04+00:00 + Davidson Souza, the developer of Floresta, has introduced a project called libfloresta to the Bitcoin developers mailing list. Libfloresta is a fully-validating Bitcoin full node with an integrated watch-only wallet and Electrum Server. The main aim of the project is to create a compact and user-friendly full node for low-power devices like single-board computers (SBCs) and smartphones. Davidson is writing the main logic of libfloresta in Rust and generating bindings to the original code, allowing it to run virtually anywhere by compiling it to WebAssembly (WASM). The project is still in its early stages but has been successfully used on signet without any issues. Mainnet support is almost ready, but performance issues with bridge nodes need to be resolved first. The code is available on Davidson's GitHub repository, along with a blog post explaining how to use it in Rust. Davidson plans to write more documentation as the project matures and is deployed on other platforms. Feedback from the community is welcomed. In terms of consensus, libfloresta does not reimplement the Bitcoin Consensus machine from scratch. Instead, it uses libbitcoinconsensus and plans to incorporate the full libbitcoinkernel in the future. This approach minimizes the risk of misimplementations leading to splits. Davidson is also conducting cross-tests against Bitcoin Core to identify any inconsistencies before they become problematic. Davidson expresses gratitude to Vinteum for their support in his work with Utreexo and Floresta. Overall, libfloresta aims to provide a lightweight and user-friendly solution for running a Bitcoin full node, particularly on low-power devices. It offers compatibility with existing Bitcoin infrastructure and can be used alongside Bitcoin Core. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_Blinded-2-party-Musig2.xml b/static/bitcoin-dev/July_2023/combined_Blinded-2-party-Musig2.xml index 6e4514fc37..175b29c9b2 100644 --- a/static/bitcoin-dev/July_2023/combined_Blinded-2-party-Musig2.xml +++ b/static/bitcoin-dev/July_2023/combined_Blinded-2-party-Musig2.xml @@ -1,107 +1,147 @@ - + 2 Combined summary - Blinded 2-party Musig2 - 2023-08-31T01:55:43.561462+00:00 - - Tom Trevethan 2023-08-30 10:52:05+00:00 - - - Lloyd Fournier 2023-08-14 06:31:42+00:00 - - - Tom Trevethan 2023-08-10 11:59:52+00:00 - - - Lloyd Fournier 2023-08-10 03:30:02+00:00 - - - Tom Trevethan 2023-08-09 15:14:36+00:00 - - - moonsettler 2023-08-08 17:44:06+00:00 - - - Tom Trevethan 2023-08-07 00:55:38+00:00 - - - Jonas Nick 2023-07-27 08:07:58+00:00 - - - AdamISZ 2023-07-27 05:51:14+00:00 - - - Lloyd Fournier 2023-07-27 02:54:17+00:00 - - - Erik Aronesty 2023-07-26 22:06:44+00:00 - - - Tom Trevethan 2023-07-26 20:35:00+00:00 - - - Jonas Nick 2023-07-26 19:59:26+00:00 - - - moonsettler 2023-07-26 19:28:50+00:00 - - - AdamISZ 2023-07-26 19:19:44+00:00 - - - Andrew Poelstra 2023-07-26 17:40:26+00:00 - - - Tom Trevethan 2023-07-26 16:32:06+00:00 - - - Jonas Nick 2023-07-26 14:59:42+00:00 - - - moonsettler 2023-07-26 09:44:50+00:00 - - - Erik Aronesty 2023-07-26 04:09:41+00:00 - - - Tom Trevethan 2023-07-25 16:05:48+00:00 - - - Erik Aronesty 2023-07-25 14:12:31+00:00 - - - AdamISZ 2023-07-24 16:51:44+00:00 - - - Tom Trevethan 2023-07-24 16:22:15+00:00 - - - Tom Trevethan 2023-07-24 16:08:28+00:00 - - - Tom Trevethan 2023-07-24 15:57:41+00:00 - - - Jonas Nick 2023-07-24 15:40:16+00:00 - - - Jonas Nick 2023-07-24 15:39:09+00:00 - - - Erik Aronesty 2023-07-24 14:40:10+00:00 - - - Erik Aronesty 2023-07-24 14:25:00+00:00 - - - Jonas Nick 2023-07-24 14:12:47+00:00 - - - ZmnSCPxj 2023-07-24 10:50:13+00:00 - - - Tom Trevethan 2023-07-24 07:46:11+00:00 - + 2025-09-26T14:24:51.246947+00:00 + python-feedgen + + + [bitcoin-dev] Blinded 2-party Musig2 Tom Trevethan + 2023-07-24T07:46:00.000Z + + + ZmnSCPxj + 2023-07-24T10:50:00.000Z + + + Jonas Nick + 2023-07-24T14:12:00.000Z + + + Erik Aronesty + 2023-07-24T14:25:00.000Z + + + Erik Aronesty + 2023-07-24T14:40:00.000Z + + + Jonas Nick + 2023-07-24T15:39:00.000Z + + + Jonas Nick + 2023-07-24T15:40:00.000Z + + + Tom Trevethan + 2023-07-24T15:57:00.000Z + + + Tom Trevethan + 2023-07-24T16:08:00.000Z + + + Tom Trevethan + 2023-07-24T16:22:00.000Z + + + AdamISZ + 2023-07-24T16:51:00.000Z + + + Erik Aronesty + 2023-07-25T14:12:00.000Z + + + Tom Trevethan + 2023-07-25T16:05:00.000Z + + + Erik Aronesty + 2023-07-26T04:09:00.000Z + + + moonsettler + 2023-07-26T09:44:00.000Z + + + Jonas Nick + 2023-07-26T14:59:00.000Z + + + Tom Trevethan + 2023-07-26T16:32:00.000Z + + + Andrew Poelstra + 2023-07-26T17:40:00.000Z + + + AdamISZ + 2023-07-26T19:19:00.000Z + + + moonsettler + 2023-07-26T19:28:00.000Z + + + Jonas Nick + 2023-07-26T19:59:00.000Z + + + Tom Trevethan + 2023-07-26T20:35:00.000Z + + + Erik Aronesty + 2023-07-26T22:06:00.000Z + + + Lloyd Fournier + 2023-07-27T02:54:00.000Z + + + AdamISZ + 2023-07-27T05:51:00.000Z + + + Jonas Nick + 2023-07-27T08:07:00.000Z + + + [bitcoin-dev] Fwd: " Tom Trevethan + 2023-07-27T13:25:00.000Z + + + [bitcoin-dev] " Tom Trevethan + 2023-08-07T00:55:00.000Z + + + moonsettler + 2023-08-08T17:44:00.000Z + + + Tom Trevethan + 2023-08-09T15:14:00.000Z + + + Lloyd Fournier + 2023-08-10T03:30:00.000Z + + + Tom Trevethan + 2023-08-10T11:59:00.000Z + + + Lloyd Fournier + 2023-08-14T06:31:00.000Z + + + Tom Trevethan + 2023-08-30T10:52:00.000Z + + @@ -135,13 +175,13 @@ - python-feedgen + 2 Combined summary - Blinded 2-party Musig2 - 2023-08-31T01:55:43.561756+00:00 + 2025-09-26T14:24:51.250780+00:00 - The email discusses the limitations and challenges associated with using Proof of Secret Key (POSK) in the MuSig protocol. It highlights the difficulty of producing POSKs in various contexts and the lack of an established key serialization format for them. The email also mentions the difficulties in publishing POSKs. The email discusses the use of MuSig1 and MuSig2 for avoiding signature forgery and blinding challenges in the signing process. It suggests integrating a "proof of secret key" (posk) into low-level protocols to prevent vulnerabilities. The email raises concerns about the proposed solution not addressing the issue of client-controlled challenge e' and proposes exploring alternative approaches such as commitments and Zero-Knowledge Proofs (ZKPs). The email further discusses the v=2 nonces signing protocol of musig2 and emphasizes the need to blind the challenge value c for confidentiality. It outlines the steps involved in the Keygen and Signing processes and suggests a verification process for statecoin transfers. Additionally, the email addresses concerns about party 1 not learning the final values of (R, s1+s2) or m and proposes an additional step for the server to obtain necessary information without compromising security. The email suggests that all parties involved in a transaction should provide a proof of secret key along with their public key to ensure security. It highlights potential vulnerabilities in a proposed scheme for blind music and the effectiveness of MuSig2 in preventing certain attacks. In conclusion, the email provides a detailed summary of the discussions around blinding challenges and signature forgery in the context of MuSig1 and MuSig2 protocols. It emphasizes the importance of integrating posk, blinding values, and implementing secure verification processes to enhance security in statecoin transfers. 2023-08-30T10:52:05+00:00 + The email discusses the limitations and challenges associated with using Proof of Secret Key (POSK) in the MuSig protocol. It highlights the difficulty of producing POSKs in various contexts and the lack of an established key serialization format for them. The email also mentions the difficulties in publishing POSKs. The email discusses the use of MuSig1 and MuSig2 for avoiding signature forgery and blinding challenges in the signing process. It suggests integrating a "proof of secret key" (posk) into low-level protocols to prevent vulnerabilities. The email raises concerns about the proposed solution not addressing the issue of client-controlled challenge e' and proposes exploring alternative approaches such as commitments and Zero-Knowledge Proofs (ZKPs). The email further discusses the v=2 nonces signing protocol of musig2 and emphasizes the need to blind the challenge value c for confidentiality. It outlines the steps involved in the Keygen and Signing processes and suggests a verification process for statecoin transfers. Additionally, the email addresses concerns about party 1 not learning the final values of (R, s1+s2) or m and proposes an additional step for the server to obtain necessary information without compromising security. The email suggests that all parties involved in a transaction should provide a proof of secret key along with their public key to ensure security. It highlights potential vulnerabilities in a proposed scheme for blind music and the effectiveness of MuSig2 in preventing certain attacks. In conclusion, the email provides a detailed summary of the discussions around blinding challenges and signature forgery in the context of MuSig1 and MuSig2 protocols. It emphasizes the importance of integrating posk, blinding values, and implementing secure verification processes to enhance security in statecoin transfers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-.xml b/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-.xml index eccec96c85..50c8ba1d2c 100644 --- a/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-.xml +++ b/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-.xml @@ -1,32 +1,15 @@ - + 2 - Combined summary - Concern about "Inscriptions". - 2023-08-11T15:40:44.968060+00:00 - - leohaf at orangepill.ovh 2023-08-03 16:03:27+00:00 - - - GamedevAlice 2023-08-03 13:33:32+00:00 - - - rot13maxi 2023-07-30 18:34:12+00:00 - - - Léo Haf 2023-07-27 19:03:58+00:00 - - - vjudeu at gazeta.pl 2023-07-27 05:10:32+00:00 - - - leohaf at orangepill.ovh 2023-07-26 09:46:51+00:00 - - - vjudeu at gazeta.pl 2023-07-26 05:30:32+00:00 - - - leohaf at orangepill.ovh 2023-07-25 14:11:49+00:00 - + Combined summary - Concern about "Inscriptions". + 2025-09-26T14:24:57.665094+00:00 + python-feedgen + + + [bitcoin-dev] [SPAM] " aymeric + 2023-07-27T10:41:00.000Z + + @@ -35,13 +18,13 @@ - python-feedgen + 2 - Combined summary - Concern about "Inscriptions". - 2023-08-11T15:40:44.968060+00:00 + Combined summary - Concern about "Inscriptions". + 2025-09-26T14:24:57.665492+00:00 - The email addresses the problem of inscriptions in the mempool and requests Bitcoin developers to find a solution. It mentions that currently there are limited options to reject inscriptions, with a patch created by Luke Dashjr being the only practical option, but it requires compiling Bitcoin Core. The writer suggests having more options to reject inscriptions in the mempool to allow users to customize their approach and mitigate the negative impact on the network. Ethical concerns are raised as inscriptions are primarily used for selling NFTs or Tokens, which are rejected by the Bitcoin community. The email concludes with a request to seriously consider implementing a feature that would enable users to reject inscriptions in the mempool to protect the network's integrity. 2023-08-03T16:03:27+00:00 + The email addresses the problem of inscriptions in the mempool and requests Bitcoin developers to find a solution. It mentions that currently there are limited options to reject inscriptions, with a patch created by Luke Dashjr being the only practical option, but it requires compiling Bitcoin Core. The writer suggests having more options to reject inscriptions in the mempool to allow users to customize their approach and mitigate the negative impact on the network. Ethical concerns are raised as inscriptions are primarily used for selling NFTs or Tokens, which are rejected by the Bitcoin community. The email concludes with a request to seriously consider implementing a feature that would enable users to reject inscriptions in the mempool to protect the network's integrity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml b/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml index 3d71ed29bd..73d80f9233 100644 --- a/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml +++ b/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Concern about "Inscriptions". (ashneverdawn) - 2023-08-11T15:43:37.028667+00:00 + Combined summary - Concern about "Inscriptions". (ashneverdawn) + 2025-09-26T14:24:42.689306+00:00 + python-feedgen Keagan McClelland 2023-08-02 05:58:53+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 - Combined summary - Concern about "Inscriptions". (ashneverdawn) - 2023-08-11T15:43:37.028667+00:00 + Combined summary - Concern about "Inscriptions". (ashneverdawn) + 2025-09-26T14:24:42.689449+00:00 - The debate revolves around introducing a pricing mechanism for space in the Unspent Transaction Output (UTXO) set. Currently, the UTXO set space is not priced, which causes uncertainty in classifying transactions as spam or legitimate. The UTXO set must be maintained by all nodes, including pruned nodes, making it more valuable than chain space. Introducing a pricing mechanism may lead to inscriptions disappearing as users would have to pay for their usage. However, this proposition may be controversial and offensive to some Bitcoin users. Pricing space in the UTXO set remains an open discussion. It is argued that differentiating transaction types on the network should not be done for privacy and censorship resistance. Limited blockchain resources should go to the highest bidder, based on the value they provide to the marketplace against the cost to the network. The growth rate of the blockchain is not caused by Ordinals, but rather by the limit on storage that can be added per block. 2023-08-02T05:58:53+00:00 + The debate revolves around introducing a pricing mechanism for space in the Unspent Transaction Output (UTXO) set. Currently, the UTXO set space is not priced, which causes uncertainty in classifying transactions as spam or legitimate. The UTXO set must be maintained by all nodes, including pruned nodes, making it more valuable than chain space. Introducing a pricing mechanism may lead to inscriptions disappearing as users would have to pay for their usage. However, this proposition may be controversial and offensive to some Bitcoin users. Pricing space in the UTXO set remains an open discussion. It is argued that differentiating transaction types on the network should not be done for privacy and censorship resistance. Limited blockchain resources should go to the highest bidder, based on the value they provide to the marketplace against the cost to the network. The growth rate of the blockchain is not caused by Ordinals, but rather by the limit on storage that can be added per block. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_Concrete-MATT-opcodes.xml b/static/bitcoin-dev/July_2023/combined_Concrete-MATT-opcodes.xml index b3fd1b2ce6..6f50fc8799 100644 --- a/static/bitcoin-dev/July_2023/combined_Concrete-MATT-opcodes.xml +++ b/static/bitcoin-dev/July_2023/combined_Concrete-MATT-opcodes.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Concrete MATT opcodes - 2023-09-16T01:51:28.673509+00:00 - - Antoine Riard 2023-09-15 00:23:31+00:00 - - - Antoine Riard 2023-09-13 20:25:07+00:00 - - - symphonicbtc 2023-08-19 23:11:22+00:00 - - - Antoine Riard 2023-08-18 20:12:09+00:00 - - - Salvatore Ingala 2023-08-18 15:08:39+00:00 - - - symphonicbtc 2023-08-14 14:07:19+00:00 - - - Antoine Riard 2023-08-14 03:00:57+00:00 - - - Salvatore Ingala 2023-08-09 08:38:48+00:00 - - - Johan Torås Halseth 2023-08-07 11:37:07+00:00 - - - Salvatore Ingala 2023-08-07 08:31:40+00:00 - - - David A. Harding 2023-08-06 20:13:25+00:00 - - - Salvatore Ingala 2023-07-30 21:37:49+00:00 - + 2025-09-26T14:24:49.097455+00:00 + python-feedgen + + + [bitcoin-dev] Concrete MATT opcodes Salvatore Ingala + 2023-07-30T21:37:00.000Z + + + David A. Harding + 2023-08-06T20:13:00.000Z + + + Salvatore Ingala + 2023-08-07T08:31:00.000Z + + + Johan Torås Halseth + 2023-08-07T11:37:00.000Z + + + Salvatore Ingala + 2023-08-09T08:38:00.000Z + + + Antoine Riard + 2023-08-14T03:00:00.000Z + + + symphonicbtc + 2023-08-14T14:07:00.000Z + + + Salvatore Ingala + 2023-08-18T15:08:00.000Z + + + Antoine Riard + 2023-08-18T20:12:00.000Z + + + symphonicbtc + 2023-08-19T23:11:00.000Z + + + Antoine Riard + 2023-09-13T20:25:00.000Z + + + Antoine Riard + 2023-09-15T00:23:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Concrete MATT opcodes - 2023-09-16T01:51:28.673620+00:00 + 2025-09-26T14:24:49.098973+00:00 - Salvatore Ingala has presented a proposal for the core opcodes of MATT, including revisions and improvements to the implementation. The code is implemented in the bitcoin-inquisition repository fork, along with OP_CHECKTEMPLATEVERIFY. The changes made include replacing OP_CHECK{IN, OUT}CONTRACTVERIFY with a single opcode called OP_CHECKCONTRACTVERIFY (CCV) and introducing an additional `flags` parameter. The order of parameters has also been modified for better script writing. Various flags are defined, such as CCV_FLAG_CHECK_INPUT and CCV_FLAG_IGNORE_OUTPUT_AMOUNT. Special values are defined for certain parameters. The email emphasizes the flexibility and generality achieved with the new opcode, but acknowledges the potential benefits of additional opcodes and introspection. The email includes several references, including a website mentioning OP_CHECKCONTRACTVERIFY, a mailing list post discussing the MATT proposal, and a GitHub repository with the code implementation. 2023-09-15T00:23:31+00:00 + Salvatore Ingala has presented a proposal for the core opcodes of MATT, including revisions and improvements to the implementation. The code is implemented in the bitcoin-inquisition repository fork, along with OP_CHECKTEMPLATEVERIFY. The changes made include replacing OP_CHECK{IN, OUT}CONTRACTVERIFY with a single opcode called OP_CHECKCONTRACTVERIFY (CCV) and introducing an additional `flags` parameter. The order of parameters has also been modified for better script writing. Various flags are defined, such as CCV_FLAG_CHECK_INPUT and CCV_FLAG_IGNORE_OUTPUT_AMOUNT. Special values are defined for certain parameters. The email emphasizes the flexibility and generality achieved with the new opcode, but acknowledges the potential benefits of additional opcodes and introspection. The email includes several references, including a website mentioning OP_CHECKCONTRACTVERIFY, a mailing list post discussing the MATT proposal, and a GitHub repository with the code implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_Denial-of-Service-using-Package-Relay.xml b/static/bitcoin-dev/July_2023/combined_Denial-of-Service-using-Package-Relay.xml index 8f945acc2e..0ff4792a43 100644 --- a/static/bitcoin-dev/July_2023/combined_Denial-of-Service-using-Package-Relay.xml +++ b/static/bitcoin-dev/July_2023/combined_Denial-of-Service-using-Package-Relay.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Denial of Service using Package Relay - 2023-08-11T15:34:40.119121+00:00 - - Andrew Chow 2023-07-06 17:24:47+00:00 - - - alicexbt 2023-07-06 16:22:44+00:00 - + 2025-09-26T14:24:59.784150+00:00 + python-feedgen + + + [bitcoin-dev] Denial of Service using Package Relay alicexbt + 2023-07-06T16:22:00.000Z + + + Andrew Chow + 2023-07-06T17:24:00.000Z + + - python-feedgen + 2 Combined summary - Denial of Service using Package Relay - 2023-08-11T15:34:40.119121+00:00 + 2025-09-26T14:24:59.784600+00:00 - User alicexbt raised concerns about the acceptance of unconfirmed inputs in a coinjoin transaction, as it could potentially invalidate the coinjoin. The user also mentioned that the coordinator B should not accept the unconfirmed UTXO from step 2 because it is unaware of that transaction and has zero fee. They noted that a similar attack could be carried out by registering the same UTXO with multiple coordinators without package relay. However, they acknowledged the benefits of package relay, such as the ability for any participant to rebroadcast the coinjoin with a further Child Pays for Parent (CPFP) if it falls below the minimum relay fee. The user also mentioned upcoming proposals for Replace-By-Fee (RBF) in package transactions, which could eliminate the need for all participants to re-sign the coinjoin for RBF. Overall, the user highlighted concerns about the acceptance of unconfirmed inputs in coinjoins and discussed the potential benefits of package relay and upcoming RBF proposals for improving security and efficiency.The user informed Bitcoin Developers about a potential vulnerability in coinjoin related to the use of the package relay feature. They explained that this vulnerability could be exploited for a Denial of Service (DoS) attack and emphasized its significance, comparing it to a soft fork. The user provided an example of the attack involving two coinjoin implementations, A and B, where the attacker registers an input in implementation A, double-spends the same input with zero fees to their own address, and registers the unconfirmed UTXO from step 2 in implementation B. This results in implementation B relaying a package containing a coinjoin transaction that pays for the double-spent input. Both users and implementation B have incentives to engage in this type of attack. The user also mentioned an alternative approach where the attacker registers the same input in both implementations A and B, but highlighted the tradeoffs associated with this approach. They stressed the importance of addressing this vulnerability promptly and provided a link to the package relay proposal for further details.The email was signed by /dev/fd0floppy disk guy using Proton Mail secure email. 2023-07-06T17:24:47+00:00 + User alicexbt raised concerns about the acceptance of unconfirmed inputs in a coinjoin transaction, as it could potentially invalidate the coinjoin. The user also mentioned that the coordinator B should not accept the unconfirmed UTXO from step 2 because it is unaware of that transaction and has zero fee. They noted that a similar attack could be carried out by registering the same UTXO with multiple coordinators without package relay. However, they acknowledged the benefits of package relay, such as the ability for any participant to rebroadcast the coinjoin with a further Child Pays for Parent (CPFP) if it falls below the minimum relay fee. The user also mentioned upcoming proposals for Replace-By-Fee (RBF) in package transactions, which could eliminate the need for all participants to re-sign the coinjoin for RBF. Overall, the user highlighted concerns about the acceptance of unconfirmed inputs in coinjoins and discussed the potential benefits of package relay and upcoming RBF proposals for improving security and efficiency.The user informed Bitcoin Developers about a potential vulnerability in coinjoin related to the use of the package relay feature. They explained that this vulnerability could be exploited for a Denial of Service (DoS) attack and emphasized its significance, comparing it to a soft fork. The user provided an example of the attack involving two coinjoin implementations, A and B, where the attacker registers an input in implementation A, double-spends the same input with zero fees to their own address, and registers the unconfirmed UTXO from step 2 in implementation B. This results in implementation B relaying a package containing a coinjoin transaction that pays for the double-spent input. Both users and implementation B have incentives to engage in this type of attack. The user also mentioned an alternative approach where the attacker registers the same input in both implementations A and B, but highlighted the tradeoffs associated with this approach. They stressed the importance of addressing this vulnerability promptly and provided a link to the package relay proposal for further details.The email was signed by /dev/fd0floppy disk guy using Proton Mail secure email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_On-the-experiment-of-the-Bitcoin-Contracting-Primitives-WG-and-marking-this-community-process-up-for-grabs-.xml b/static/bitcoin-dev/July_2023/combined_On-the-experiment-of-the-Bitcoin-Contracting-Primitives-WG-and-marking-this-community-process-up-for-grabs-.xml index 19af88791f..12b364955b 100644 --- a/static/bitcoin-dev/July_2023/combined_On-the-experiment-of-the-Bitcoin-Contracting-Primitives-WG-and-marking-this-community-process-up-for-grabs-.xml +++ b/static/bitcoin-dev/July_2023/combined_On-the-experiment-of-the-Bitcoin-Contracting-Primitives-WG-and-marking-this-community-process-up-for-grabs-.xml @@ -1,39 +1,48 @@ - + 2 - Combined summary - On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs" - 2023-08-11T15:35:30.251397+00:00 - - Greg Sanders 2023-07-20 06:11:57+00:00 - - - Antoine Riard 2023-07-20 05:46:25+00:00 - - - Antoine Riard 2023-07-20 05:33:58+00:00 - - - Greg Sanders 2023-07-19 20:45:15+00:00 - - - Keagan McClelland 2023-07-19 18:29:24+00:00 - - - Antoine Riard 2023-07-18 20:18:49+00:00 - + Combined summary - On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs" + 2025-09-26T14:24:44.836530+00:00 + python-feedgen + + + [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs" Antoine Riard + 2023-07-18T20:18:00.000Z + + + Keagan McClelland + 2023-07-19T18:29:00.000Z + + + Greg Sanders + 2023-07-19T20:45:00.000Z + + + Antoine Riard + 2023-07-20T05:33:00.000Z + + + Antoine Riard + 2023-07-20T05:46:00.000Z + + + Greg Sanders + 2023-07-20T06:11:00.000Z + + - python-feedgen + 2 - Combined summary - On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs" - 2023-08-11T15:35:30.251397+00:00 + Combined summary - On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs" + 2025-09-26T14:24:44.837476+00:00 - In an email exchange on the Bitcoin-dev mailing list, Keags expressed his agreement with Antoine that a smoothly functioning Lightning Network (LN) is more important than advanced contracting capabilities. However, he also mentioned that as he delves deeper into LN development, he realizes that some of the complexity in current LN proposals can be simplified with CTV (Covenant Transaction Verification). Keags suspects that other covenant schemes may also be capable of reducing complexity. He encourages others to confirm this claim.Keags goes on to state that he has long supported the addition of a covenant scheme into Bitcoin, believing it is necessary for the long-term survival of the cryptocurrency. Working directly with the Lightning protocol has made these arguments more concrete and beneficial. He challenges the idea that covenants are a distraction from LN development, emphasizing that they can significantly contribute to LN's maturity.Although Keags does not comment on when or how covenants should be prioritized, he emphasizes that Lightning would benefit from having a covenant primitive. He acknowledges that Antoine's focus on LN may prevent him from splitting his attention, but he wants observers to understand that covenants and LN are not independent efforts.Antoine's email, which prompted Keags' response, announces the conclusion of his experiment regarding covenant specifications. He explains that the goals of the experiment were to build a consistent framework for evaluating covenant proposals, identify common grounds between proposals, open up the consensus changes development process beyond Bitcoin Core, and maintain a high-quality technical archive. Antoine highlights related initiatives undertaken by others, such as the bitcoin-inquisition fork and the archiving of covenant proposals under the Optech umbrella.Antoine provides an update on the Bitcoin Contracting Primitives WG, stating that a Github repository was created to document and archive various primitives and protocols related to Bitcoin contracts. Monthly meetings were held with attendees from different parts of the community, and in-depth discussions took place on topics like "merkelized all the things" and "payment pools for miners payoffs". However, Antoine admits that he has not run an online meeting since April due to his focus on Lightning robustness.Antoine expresses his belief that the smooth functioning of LN with 50-100M UTXO-sharing users is more critical for Bitcoin's survival than extended covenant capabilities. He acknowledges that small incremental changes to Bitcoin Script can have a significant impact, citing Taproot and Schnorr as examples. Antoine plans to continue working on CoinPool, addressing issues like interactivity and withdrawal compression, as well as exploring advanced Bitcoin contracts based on the taproot annex. He also mentions the possibility of submitting security reviews of consensus changes under pseudonyms.In conclusion, Antoine reflects on the state of Bitcoin's technological momentum and suggests that what it lacks is a small group of technical historians and archivists to assess and preserve consensus change proposals. He invites anyone interested in maintaining and nurturing the Bitcoin Contracting Primitives WG to reach out. Antoine believes there are compelling technical proposals to advance Bitcoin's capabilities but emphasizes the need for rigorous testing and adherence to decentralization and FOSS neutrality standards. 2023-07-20T06:11:57+00:00 + In an email exchange on the Bitcoin-dev mailing list, Keags expressed his agreement with Antoine that a smoothly functioning Lightning Network (LN) is more important than advanced contracting capabilities. However, he also mentioned that as he delves deeper into LN development, he realizes that some of the complexity in current LN proposals can be simplified with CTV (Covenant Transaction Verification). Keags suspects that other covenant schemes may also be capable of reducing complexity. He encourages others to confirm this claim.Keags goes on to state that he has long supported the addition of a covenant scheme into Bitcoin, believing it is necessary for the long-term survival of the cryptocurrency. Working directly with the Lightning protocol has made these arguments more concrete and beneficial. He challenges the idea that covenants are a distraction from LN development, emphasizing that they can significantly contribute to LN's maturity.Although Keags does not comment on when or how covenants should be prioritized, he emphasizes that Lightning would benefit from having a covenant primitive. He acknowledges that Antoine's focus on LN may prevent him from splitting his attention, but he wants observers to understand that covenants and LN are not independent efforts.Antoine's email, which prompted Keags' response, announces the conclusion of his experiment regarding covenant specifications. He explains that the goals of the experiment were to build a consistent framework for evaluating covenant proposals, identify common grounds between proposals, open up the consensus changes development process beyond Bitcoin Core, and maintain a high-quality technical archive. Antoine highlights related initiatives undertaken by others, such as the bitcoin-inquisition fork and the archiving of covenant proposals under the Optech umbrella.Antoine provides an update on the Bitcoin Contracting Primitives WG, stating that a Github repository was created to document and archive various primitives and protocols related to Bitcoin contracts. Monthly meetings were held with attendees from different parts of the community, and in-depth discussions took place on topics like "merkelized all the things" and "payment pools for miners payoffs". However, Antoine admits that he has not run an online meeting since April due to his focus on Lightning robustness.Antoine expresses his belief that the smooth functioning of LN with 50-100M UTXO-sharing users is more critical for Bitcoin's survival than extended covenant capabilities. He acknowledges that small incremental changes to Bitcoin Script can have a significant impact, citing Taproot and Schnorr as examples. Antoine plans to continue working on CoinPool, addressing issues like interactivity and withdrawal compression, as well as exploring advanced Bitcoin contracts based on the taproot annex. He also mentions the possibility of submitting security reviews of consensus changes under pseudonyms.In conclusion, Antoine reflects on the state of Bitcoin's technological momentum and suggests that what it lacks is a small group of technical historians and archivists to assess and preserve consensus change proposals. He invites anyone interested in maintaining and nurturing the Bitcoin Contracting Primitives WG to reach out. Antoine believes there are compelling technical proposals to advance Bitcoin's capabilities but emphasizes the need for rigorous testing and adherence to decentralization and FOSS neutrality standards. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml b/static/bitcoin-dev/July_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml index 3fdd5adaa1..fca8311ebe 100644 --- a/static/bitcoin-dev/July_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml +++ b/static/bitcoin-dev/July_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pull-req to enable Full-RBF by default - 2023-08-11T15:41:45.105161+00:00 + 2025-09-26T14:24:53.399206+00:00 + python-feedgen Peter Todd 2023-08-03 12:46:40+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Pull-req to enable Full-RBF by default - 2023-08-11T15:41:45.105161+00:00 + 2025-09-26T14:24:53.399379+00:00 - The claim that "trxs activity" is meaningless without demonstrating reliance on unconfirmed transaction acceptance is being challenged. The commenter questions the credibility of GAP600's offering of a "real-time risk engine" and "instant deposits & payments" without testing full-replace-by-fee (full-rbf) adoption themselves. They provide examples of transactions that were part of chains of replacements and question how these transactions are getting mined. The commenter requests the names of merchants using GAP600's claimed service to verify their reliance on unconfirmed transactions. They also mention reaching out to changelly.com for confirmation of their use of GAP600 but have yet to receive a response.GAP600 responds by stating they do not conduct specific assessments or research on hashing pools and that client confidentiality prevents them from disclosing their clients' names. They suggest contacting Max from Coinpaid for confirmation of their use of GAP600. They also mention that Changelly may not have fully implemented their service across all offerings. They provide contact details for further inquiries.In response to the commenter's assessment, GAP600 defends their honesty and offers evidence of their position. They state that they have provided clear access to clients to verify their statistics and offer a solution for validating full RBF adoption. They argue that the commenter's conclusions are unfounded.The author challenges the credibility of the claim that merchants relying on unconfirmed transactions exist and asks for concrete examples to support this assertion. They have reached out to Coinspaid and Changelly for confirmation but are awaiting a reply. They also query the specific services offered by Changelly that depend on unconfirmed transactions and inquire about the risk criteria set by GAP600. They suggest conducting test transactions if provided with the necessary information but refuse to provide transaction hashes to protect account owners. They question the lack of specific examples of affected businesses and dismiss payment processors as irrelevant. They mention instances of mining pools being harassed and decline to share private contact information. They suggest that if the service in question truly offered an unconfirmed transaction guarantee, they would have ample data on pools practicing full-rbf.The author provides evidence that there are no genuine examples of actual merchants accepting unconfirmed transactions. They mention that Changelly explicitly states that they do not accept unconfirmed payments. They request an example of an actual merchant accepting unconfirmed transactions.GAP600 provides statistics and feedback from Coinspaid to support their claims. They argue that the lack of impact on double spend rates suggests that the adoption of full RBF by miners is questionable. They mention that they reimburse clients for incorrect predictions of double spends. They clarify that they are not a payment processor but provide services to payment processors, merchants, and non-custodial liquidity providers.The author discusses the implementation of full Replace-By-Fee (RBF) in Bitcoin transactions and its potential negative impact on merchants and users who accept 0-conf transactions. They mention mitigation tools like GAP600 that require replacement transactions to include the original outputs. They provide statistics on the usage of GAP600 and mention their clients. They argue that the addition of a "first seen safe" rule is crucial to avoid negative consequences.The author of the context has submitted a pull request to enable full-rbf by default in Bitcoin Core. They mention several block explorers, nodes, and wallets that have enabled full-rbf. They argue that enabling full-rbf by default will address the issue of a minority of nodes relaying full-rbf replacements. They mention opposition from Bitrefill but found no evidence that they still accept unconfirmed transactions. They propose enabling full-rbf by default in Bitcoin Core and deprecating and removing BIP125 code in future releases. The context includes references to support the points made. 2023-08-03T12:46:40+00:00 + The claim that "trxs activity" is meaningless without demonstrating reliance on unconfirmed transaction acceptance is being challenged. The commenter questions the credibility of GAP600's offering of a "real-time risk engine" and "instant deposits & payments" without testing full-replace-by-fee (full-rbf) adoption themselves. They provide examples of transactions that were part of chains of replacements and question how these transactions are getting mined. The commenter requests the names of merchants using GAP600's claimed service to verify their reliance on unconfirmed transactions. They also mention reaching out to changelly.com for confirmation of their use of GAP600 but have yet to receive a response.GAP600 responds by stating they do not conduct specific assessments or research on hashing pools and that client confidentiality prevents them from disclosing their clients' names. They suggest contacting Max from Coinpaid for confirmation of their use of GAP600. They also mention that Changelly may not have fully implemented their service across all offerings. They provide contact details for further inquiries.In response to the commenter's assessment, GAP600 defends their honesty and offers evidence of their position. They state that they have provided clear access to clients to verify their statistics and offer a solution for validating full RBF adoption. They argue that the commenter's conclusions are unfounded.The author challenges the credibility of the claim that merchants relying on unconfirmed transactions exist and asks for concrete examples to support this assertion. They have reached out to Coinspaid and Changelly for confirmation but are awaiting a reply. They also query the specific services offered by Changelly that depend on unconfirmed transactions and inquire about the risk criteria set by GAP600. They suggest conducting test transactions if provided with the necessary information but refuse to provide transaction hashes to protect account owners. They question the lack of specific examples of affected businesses and dismiss payment processors as irrelevant. They mention instances of mining pools being harassed and decline to share private contact information. They suggest that if the service in question truly offered an unconfirmed transaction guarantee, they would have ample data on pools practicing full-rbf.The author provides evidence that there are no genuine examples of actual merchants accepting unconfirmed transactions. They mention that Changelly explicitly states that they do not accept unconfirmed payments. They request an example of an actual merchant accepting unconfirmed transactions.GAP600 provides statistics and feedback from Coinspaid to support their claims. They argue that the lack of impact on double spend rates suggests that the adoption of full RBF by miners is questionable. They mention that they reimburse clients for incorrect predictions of double spends. They clarify that they are not a payment processor but provide services to payment processors, merchants, and non-custodial liquidity providers.The author discusses the implementation of full Replace-By-Fee (RBF) in Bitcoin transactions and its potential negative impact on merchants and users who accept 0-conf transactions. They mention mitigation tools like GAP600 that require replacement transactions to include the original outputs. They provide statistics on the usage of GAP600 and mention their clients. They argue that the addition of a "first seen safe" rule is crucial to avoid negative consequences.The author of the context has submitted a pull request to enable full-rbf by default in Bitcoin Core. They mention several block explorers, nodes, and wallets that have enabled full-rbf. They argue that enabling full-rbf by default will address the issue of a minority of nodes relaying full-rbf replacements. They mention opposition from Bitrefill but found no evidence that they still accept unconfirmed transactions. They propose enabling full-rbf by default in Bitcoin Core and deprecating and removing BIP125 code in future releases. The context includes references to support the points made. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2023/combined_Standardisation-of-an-unstructured-taproot-annex.xml b/static/bitcoin-dev/July_2023/combined_Standardisation-of-an-unstructured-taproot-annex.xml index 01337a52dd..4543ef4aef 100644 --- a/static/bitcoin-dev/July_2023/combined_Standardisation-of-an-unstructured-taproot-annex.xml +++ b/static/bitcoin-dev/July_2023/combined_Standardisation-of-an-unstructured-taproot-annex.xml @@ -1,98 +1,131 @@ - + 2 Combined summary - Standardisation of an unstructured taproot annex - 2023-08-02T09:34:03.267700+00:00 - - Antoine Riard 2023-07-04 20:18:23+00:00 - - - Joost Jager 2023-06-20 12:50:47+00:00 - - - Joost Jager 2023-06-20 12:30:19+00:00 - - - Antoine Riard 2023-06-19 01:14:10+00:00 - - - Greg Sanders 2023-06-18 20:40:53+00:00 - - - Antoine Riard 2023-06-18 20:32:12+00:00 - - - Greg Sanders 2023-06-16 13:30:46+00:00 - - - Joost Jager 2023-06-16 11:26:34+00:00 - - - Greg Sanders 2023-06-15 10:39:36+00:00 - - - Joost Jager 2023-06-15 09:36:19+00:00 - - - Joost Jager 2023-06-13 10:38:05+00:00 - - - David A. Harding 2023-06-13 08:51:39+00:00 - - - Greg Sanders 2023-06-12 13:03:47+00:00 - - - Antoine Riard 2023-06-12 03:16:44+00:00 - - - Joost Jager 2023-06-11 19:25:42+00:00 - - - David A. Harding 2023-06-10 22:09:57+00:00 - - - Joost Jager 2023-06-10 07:43:52+00:00 - - - Antoine Riard 2023-06-10 00:23:36+00:00 - - - Joost Jager 2023-06-08 09:16:26+00:00 - - - Peter Todd 2023-06-03 15:50:27+00:00 - - - Joost Jager 2023-06-03 12:55:27+00:00 - - - Greg Sanders 2023-06-03 12:43:38+00:00 - - - Joost Jager 2023-06-03 12:35:51+00:00 - - - Greg Sanders 2023-06-03 12:05:59+00:00 - - - Joost Jager 2023-06-03 09:14:27+00:00 - - - Joost Jager 2023-06-03 08:06:37+00:00 - - - Joost Jager 2023-06-03 07:49:36+00:00 - - - Greg Sanders 2023-06-03 01:14:40+00:00 - - - David A. Harding 2023-06-03 01:08:01+00:00 - - - Joost Jager 2023-06-02 15:00:37+00:00 - + 2025-09-26T14:24:55.547314+00:00 + python-feedgen + + + [bitcoin-dev] Standardisation of an unstructured taproot annex Joost Jager + 2023-06-02T15:00:00.000Z + + + David A. Harding + 2023-06-03T01:08:00.000Z + + + Greg Sanders + 2023-06-03T01:14:00.000Z + + + Joost Jager + 2023-06-03T07:49:00.000Z + + + Joost Jager + 2023-06-03T08:06:00.000Z + + + Joost Jager + 2023-06-03T09:14:00.000Z + + + Greg Sanders + 2023-06-03T12:05:00.000Z + + + Joost Jager + 2023-06-03T12:35:00.000Z + + + Greg Sanders + 2023-06-03T12:43:00.000Z + + + Joost Jager + 2023-06-03T12:55:00.000Z + + + Peter Todd + 2023-06-03T15:50:00.000Z + + + Joost Jager + 2023-06-08T09:16:00.000Z + + + Antoine Riard + 2023-06-10T00:23:00.000Z + + + Joost Jager + 2023-06-10T07:43:00.000Z + + + David A. Harding + 2023-06-10T22:09:00.000Z + + + Joost Jager + 2023-06-11T19:25:00.000Z + + + Antoine Riard + 2023-06-12T03:16:00.000Z + + + Greg Sanders + 2023-06-12T13:03:00.000Z + + + David A. Harding + 2023-06-13T08:51:00.000Z + + + Joost Jager + 2023-06-13T10:38:00.000Z + + + Joost Jager + 2023-06-15T09:36:00.000Z + + + Greg Sanders + 2023-06-15T10:39:00.000Z + + + Joost Jager + 2023-06-16T11:26:00.000Z + + + Greg Sanders + 2023-06-16T13:30:00.000Z + + + Antoine Riard + 2023-06-18T20:32:00.000Z + + + Greg Sanders + 2023-06-18T20:40:00.000Z + + + Antoine Riard + 2023-06-19T01:14:00.000Z + + + Joost Jager + 2023-06-20T12:30:00.000Z + + + Joost Jager + 2023-06-20T12:50:00.000Z + + + Antoine Riard + 2023-07-04T20:18:00.000Z + + @@ -123,13 +156,13 @@ - python-feedgen + 2 Combined summary - Standardisation of an unstructured taproot annex - 2023-08-02T09:34:03.268734+00:00 + 2025-09-26T14:24:55.550213+00:00 - In a recent email exchange, Antoine and Joost discussed the potential benefits of using the annex feature for Bitcoin's time-locked vault applications. Joost emphasized that the annex data is not included in the calculation of transaction IDs, making it a powerful tool for applications that could benefit from covenants. He specifically mentioned time-locked vaults as a critical application that could greatly benefit from the annex.Joost explained that backing up the ephemeral signatures of pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be accessed. However, without the annex, this process is not as safe as it could be. Due to a circular reference problem, the vault creation and signature backup cannot be executed in one atomic operation. This means that if the backup does not confirm, the funds can be lost even if the vault is confirmed.Despite being labeled as speculative, Joost argued that the use case for the annex in time-locked vaults is relevant, especially considering the difficulty of implementing soft forks like OP_VAULT. To support this use case, Joost created a simple demo application that demonstrates how coins can be spent to a special address and later moved to a predefined final destination. The demo uses the annex to store the ephemeral signature of the pre-signed transaction, ensuring that the coin cannot be lost.Joost also highlighted the importance of raising awareness about the on-chain ephemeral signature backup functionality enabled by the annex. He provided a link to his demo application on GitHub, which showcases the potential of the annex for implementing more advanced covenants, such as time-locked vaults.Overall, Joost and Antoine's discussion sheds light on the potential benefits of using the annex for time-locked vault applications and emphasizes the need for further exploration and adoption of the annex feature.In another email exchange between Antoine Riard and Joost, they discuss the concept of an opt-in annex in multi-party transactions. The purpose of this approach is to prevent surprises within multi-party transactions. If someone doesn't commit to an annex, they can be confident that no version of the transaction will appear where another signer includes a potentially large annex. This ensures that existing multi-party protocols remain unaffected.For future protocols that rely on the annex, everyone involved would need to opt-in by committing to an annex. The annex can be empty, serving only as a signal of opting in. The goal is to maintain transparency and avoid unexpected variations in transaction versions.In a separate email thread, Antoine Riard seeks clarification on the topic of opt-in annexes in relation to non-deployed and deployed protocols. Greg Sanders requests a citation for the claim that people should not build protocols meant for production on undeveloped upgrade hooks. Antoine acknowledges that ideally, premature choices should not encumber future development, but mentions that if certain use cases gain economic weight, the coordination cost of deploying a new policy may be prohibitive. In such cases, he suggests implementing sound and "firewalled" signaling and upgrading mechanisms to deploy new policy rules smoothly. Greg seeks further clarification on Antoine's mention of modifying current Taproot support on the Lightning side, specifically regarding the requirement of all P2TR spends to add an annex and commit to it in the BIP341 signature digest. Antoine explains that this would be a mandatory upgrade for Lightning nodes, as failure to do so would disrupt the propagation of `option_taproot` channel transactions. Antoine also discusses the possibility of introducing a TLV record to limit the maximum size/weight of the witness/transaction.The email conversation continues with Joost Jager proposing a restrictive policy for enabling annex-vaults while still aligning with existing work. This policy includes opt-in annexes for every input, the use of TLV format for future extensibility, only allowing unstructured data in tlv record 0 for future extensibility, and limiting the maximum size of the value to 256 bytes to protect opt-in users. Joost highlights the need for a larger limit than the current 126 bytes proposed in a previous pull request, as it would not be sufficient for certain vault configurations. He asks if there are any remaining objections to making the annex standard under these conditions.The discussion revolves around two key points. First, there is a proposal to require every input to commit to an annex, even if it is empty. This could potentially affect the existing multi-party protocols. The concern raised is whether a transaction without the minimal annex, indicated by the 0x50 tag, should be rejected. Implementing this would require modifying current Taproot support on the Lightning side, where all P2TR spends must add an annex and commit to it in the BIP341 signature digest. Failure to upgrade Lightning nodes accordingly would disrupt the propagation of their `option_taproot` channel transactions.Secondly, there is another approach suggested to limit the maximum size or weight of the witness/transaction as a TLV (Type-Length-Value 2023-07-04T20:18:23+00:00 + In a recent email exchange, Antoine and Joost discussed the potential benefits of using the annex feature for Bitcoin's time-locked vault applications. Joost emphasized that the annex data is not included in the calculation of transaction IDs, making it a powerful tool for applications that could benefit from covenants. He specifically mentioned time-locked vaults as a critical application that could greatly benefit from the annex.Joost explained that backing up the ephemeral signatures of pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be accessed. However, without the annex, this process is not as safe as it could be. Due to a circular reference problem, the vault creation and signature backup cannot be executed in one atomic operation. This means that if the backup does not confirm, the funds can be lost even if the vault is confirmed.Despite being labeled as speculative, Joost argued that the use case for the annex in time-locked vaults is relevant, especially considering the difficulty of implementing soft forks like OP_VAULT. To support this use case, Joost created a simple demo application that demonstrates how coins can be spent to a special address and later moved to a predefined final destination. The demo uses the annex to store the ephemeral signature of the pre-signed transaction, ensuring that the coin cannot be lost.Joost also highlighted the importance of raising awareness about the on-chain ephemeral signature backup functionality enabled by the annex. He provided a link to his demo application on GitHub, which showcases the potential of the annex for implementing more advanced covenants, such as time-locked vaults.Overall, Joost and Antoine's discussion sheds light on the potential benefits of using the annex for time-locked vault applications and emphasizes the need for further exploration and adoption of the annex feature.In another email exchange between Antoine Riard and Joost, they discuss the concept of an opt-in annex in multi-party transactions. The purpose of this approach is to prevent surprises within multi-party transactions. If someone doesn't commit to an annex, they can be confident that no version of the transaction will appear where another signer includes a potentially large annex. This ensures that existing multi-party protocols remain unaffected.For future protocols that rely on the annex, everyone involved would need to opt-in by committing to an annex. The annex can be empty, serving only as a signal of opting in. The goal is to maintain transparency and avoid unexpected variations in transaction versions.In a separate email thread, Antoine Riard seeks clarification on the topic of opt-in annexes in relation to non-deployed and deployed protocols. Greg Sanders requests a citation for the claim that people should not build protocols meant for production on undeveloped upgrade hooks. Antoine acknowledges that ideally, premature choices should not encumber future development, but mentions that if certain use cases gain economic weight, the coordination cost of deploying a new policy may be prohibitive. In such cases, he suggests implementing sound and "firewalled" signaling and upgrading mechanisms to deploy new policy rules smoothly. Greg seeks further clarification on Antoine's mention of modifying current Taproot support on the Lightning side, specifically regarding the requirement of all P2TR spends to add an annex and commit to it in the BIP341 signature digest. Antoine explains that this would be a mandatory upgrade for Lightning nodes, as failure to do so would disrupt the propagation of `option_taproot` channel transactions. Antoine also discusses the possibility of introducing a TLV record to limit the maximum size/weight of the witness/transaction.The email conversation continues with Joost Jager proposing a restrictive policy for enabling annex-vaults while still aligning with existing work. This policy includes opt-in annexes for every input, the use of TLV format for future extensibility, only allowing unstructured data in tlv record 0 for future extensibility, and limiting the maximum size of the value to 256 bytes to protect opt-in users. Joost highlights the need for a larger limit than the current 126 bytes proposed in a previous pull request, as it would not be sufficient for certain vault configurations. He asks if there are any remaining objections to making the annex standard under these conditions.The discussion revolves around two key points. First, there is a proposal to require every input to commit to an annex, even if it is empty. This could potentially affect the existing multi-party protocols. The concern raised is whether a transaction without the minimal annex, indicated by the 0x50 tag, should be rejected. Implementing this would require modifying current Taproot support on the Lightning side, where all P2TR spends must add an annex and commit to it in the BIP341 signature digest. Failure to upgrade Lightning nodes accordingly would disrupt the propagation of their `option_taproot` channel transactions.Secondly, there is another approach suggested to limit the maximum size or weight of the witness/transaction as a TLV (Type-Length-Value - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_A-Free-Relay-Attack-Taking-Advantage-of-The-Lack-of-Full-RBF-In-Core.xml b/static/bitcoin-dev/July_2024/combined_A-Free-Relay-Attack-Taking-Advantage-of-The-Lack-of-Full-RBF-In-Core.xml index 8d930d6a21..d924ff887e 100644 --- a/static/bitcoin-dev/July_2024/combined_A-Free-Relay-Attack-Taking-Advantage-of-The-Lack-of-Full-RBF-In-Core.xml +++ b/static/bitcoin-dev/July_2024/combined_A-Free-Relay-Attack-Taking-Advantage-of-The-Lack-of-Full-RBF-In-Core.xml @@ -1,134 +1,179 @@ - + 2 - Combined summary - A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core - 2024-08-17T02:06:44.997884+00:00 - - Antoine Riard 2024-08-16 04:45:00+00:00 - - - Antoine Riard 2024-08-16 04:20:00+00:00 - - - Garlo Nicon 2024-08-01 05:57:00+00:00 - - - Peter Todd 2024-07-30 19:38:00+00:00 - - - David Harding 2024-07-30 04:57:00+00:00 - - - Antoine Riard 2024-07-24 00:44:00+00:00 - - - Antoine Riard 2024-07-24 00:42:00+00:00 - - - Antoine Riard 2024-07-24 00:41:00+00:00 - - - Antoine Riard 2024-07-24 00:38:00+00:00 - - - Antoine Riard 2024-07-24 00:35:00+00:00 - - - Peter Todd 2024-07-23 11:29:00+00:00 - - - David A. Harding 2024-07-22 22:08:00+00:00 - - - Peter Todd 2024-07-22 20:06:00+00:00 - - - Peter Todd 2024-07-22 17:13:00+00:00 - - - David A. Harding 2024-07-22 16:43:00+00:00 - - - Peter Todd 2024-07-22 15:10:00+00:00 - - - Peter Todd 2024-07-22 11:45:00+00:00 - - - Anonymous User 2024-07-22 01:59:00+00:00 - - - Peter Todd 2024-07-21 20:25:00+00:00 - - - Ava Chow 2024-07-21 20:17:00+00:00 - - - David A. Harding 2024-07-21 15:35:00+00:00 - - - /dev /fd 2024-07-21 06:16:00+00:00 - - - Antoine Riard 2024-07-21 02:13:00+00:00 - - - Antoine Riard 2024-07-21 02:12:00+00:00 - - - Antoine Riard 2024-07-21 02:10:00+00:00 - - - Antoine Riard 2024-07-21 02:06:00+00:00 - - - Peter Todd 2024-07-20 15:30:00+00:00 - - - Peter Todd 2024-07-20 15:08:00+00:00 - - - Peter Todd 2024-07-20 15:03:00+00:00 - - - Peter Todd 2024-07-20 14:10:00+00:00 - - - David A. Harding 2024-07-20 06:41:00+00:00 - - - /dev /fd 2024-07-20 05:57:00+00:00 - - - Ava Chow 2024-07-20 00:46:00+00:00 - - - Antoine Riard 2024-07-19 23:58:00+00:00 - - - Antoine Riard 2024-07-19 23:56:00+00:00 - - - Murch 2024-07-19 18:26:00+00:00 - - - Peter Todd 2024-07-19 14:38:00+00:00 - - - Antoine Riard 2024-07-19 13:52:00+00:00 - - - /dev /fd 2024-07-19 12:41:00+00:00 - - - Peter Todd 2024-07-19 01:05:00+00:00 - - - Antoine Riard 2024-07-18 23:04:00+00:00 - - - Peter Todd 2024-07-18 15:56:00+00:00 - + Combined summary - A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core + 2025-09-26T14:21:21.678415+00:00 + python-feedgen + + + A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd + 2024-07-18T15:56:00.000Z + + + Antoine Riard + 2024-07-18T23:04:00.000Z + + + Peter Todd + 2024-07-19T01:05:00.000Z + + + /dev /fd0 + 2024-07-19T12:41:00.000Z + + + Antoine Riard + 2024-07-19T13:52:00.000Z + + + Peter Todd + 2024-07-19T14:38:00.000Z + + + Murch + 2024-07-19T18:26:00.000Z + + + Antoine Riard + 2024-07-19T23:56:00.000Z + + + Antoine Riard + 2024-07-19T23:58:00.000Z + + + Ava Chow' + 2024-07-20T00:46:00.000Z + + + /dev /fd0 + 2024-07-20T05:57:00.000Z + + + David A. Harding + 2024-07-20T06:41:00.000Z + + + Peter Todd + 2024-07-20T14:10:00.000Z + + + Peter Todd + 2024-07-20T15:03:00.000Z + + + Peter Todd + 2024-07-20T15:08:00.000Z + + + Peter Todd + 2024-07-20T15:30:00.000Z + + + Antoine Riard + 2024-07-21T02:06:00.000Z + + + Antoine Riard + 2024-07-21T02:10:00.000Z + + + Antoine Riard + 2024-07-21T02:12:00.000Z + + + Antoine Riard + 2024-07-21T02:13:00.000Z + + + /dev /fd0 + 2024-07-21T06:16:00.000Z + + + David A. Harding + 2024-07-21T15:35:00.000Z + + + Ava Chow' + 2024-07-21T20:17:00.000Z + + + Peter Todd + 2024-07-21T20:25:00.000Z + + + Anonymous User' + 2024-07-22T01:59:00.000Z + + + RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd + 2024-07-22T11:45:00.000Z + + + Peter Todd + 2024-07-22T15:10:00.000Z + + + David A. Harding + 2024-07-22T16:43:00.000Z + + + A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd + 2024-07-22T17:13:00.000Z + + + Peter Todd + 2024-07-22T20:06:00.000Z + + + David A. Harding + 2024-07-22T22:08:00.000Z + + + Peter Todd + 2024-07-23T11:29:00.000Z + + + Antoine Riard + 2024-07-24T00:35:00.000Z + + + Antoine Riard + 2024-07-24T00:38:00.000Z + + + Antoine Riard + 2024-07-24T00:41:00.000Z + + + Antoine Riard + 2024-07-24T00:42:00.000Z + + + Antoine Riard + 2024-07-24T00:44:00.000Z + + + David A. Harding + 2024-07-30T04:57:00.000Z + + + Peter Todd + 2024-07-30T19:38:00.000Z + + + Garlo Nicon + 2024-08-01T05:57:00.000Z + + + Antoine Riard + 2024-08-16T04:20:00.000Z + + + Antoine Riard + 2024-08-16T04:45:00.000Z + + @@ -171,21 +216,17 @@ - python-feedgen + 2 - Combined summary - A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core - 2024-08-17T02:06:44.998218+00:00 + Combined summary - A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core + 2025-09-26T14:21:21.682643+00:00 + 2024-08-16T04:45:00+00:00 The discourse among Bitcoin developers, notably between Antoine Riard and Peter Todd, sheds light on a critical security vulnerability within the Bitcoin network related to transaction relays and double-spending. The vulnerability hinges on exploiting nodes with full Replace-By-Fee (RBF) disabled, allowing for an attack where low fee-rate transactions are initially broadcast across the majority of the network and subsequently double-spent with higher fees to a single miner. This scenario underlines a fundamental issue in the network's design, where the relay and acceptance policies of nodes can be manipulated to waste bandwidth and potentially disrupt transaction integrity. - Antoine's critique extends to the broader Bitcoin Core team's response—or lack thereof—to such vulnerabilities. Despite proposing solutions like enabling full RBF by default, which could mitigate multiple known issues including this specific vulnerability, such suggestions have been ignored or dismissed due to what appears to be political reasons within the development community. This reluctance to adopt straightforward fixes raises concerns about the prioritization of political over technical considerations in addressing security vulnerabilities. - -Furthermore, the discussion delves into the ineffectiveness of TRUC/V3 transactions as proposed in BIP-431. Despite being positioned as a solution to certain types of "free" relay attacks, the rationale behind TRUC/V3 is criticized for failing to address the underlying issues effectively. This situation highlights a misallocation of resources towards solutions that do not fully mitigate the identified risks, thereby perpetuating vulnerabilities within the network. - +Furthermore, the discussion delves into the ineffectiveness of TRUC/V3 transactions as proposed in BIP-431. Despite being positioned as a solution to certain types of "free" relay attacks, the rationale behind TRUC/V3 is criticized for failing to address the underlying issues effectively. This situation highlights a misallocation of resources towards solutions that do not fully mitigate the identified risks, thereby perpetuating vulnerabilities within the network. The communication also emphasizes the economic feasibility of executing such attacks, pointing out that attackers can exploit these vulnerabilities at minimal cost. This underscores a significant inefficiency within the Bitcoin protocol that could be exploited for nefarious purposes, including low-cost transaction consolidation by attackers. - This dialogue underscores the complexity of managing security vulnerabilities within open-source cryptocurrency projects like Bitcoin. It reveals a tension between the need for technical solutions to secure the network and the political dynamics that influence decision-making processes within the developer community. The highlighted correspondence and proposals call for a reassessment of priorities, advocating for a more responsive and technically grounded approach to safeguarding the integrity and efficiency of the Bitcoin network. - 2024-08-16T04:45:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml b/static/bitcoin-dev/July_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml index 90e2185a26..2942c397a7 100644 --- a/static/bitcoin-dev/July_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml +++ b/static/bitcoin-dev/July_2024/combined_BIP-Draft-ChillDKG-Distributed-Key-Generation-for-FROST-.xml @@ -1,37 +1,41 @@ - + 2 - Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST" - 2024-12-20T02:24:21.673384+00:00 - - Tim Ruffing 2024-12-19 10:56:00+00:00 - - - Jonas Nick 2024-07-16 17:31:00+00:00 - - - David A. Harding 2024-07-16 16:43:00+00:00 - - - Tim Ruffing 2024-07-08 20:05:00+00:00 - + Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST" + 2025-09-26T14:21:30.223958+00:00 + python-feedgen + + + BIP Draft: "ChillDKG: Distributed Key Generation for FROST" Tim Ruffing + 2024-07-08T20:05:00.000Z + + + David A. Harding + 2024-07-16T16:43:00.000Z + + + Jonas Nick + 2024-07-16T17:31:00.000Z + + + Tim Ruffing + 2024-12-19T10:56:00.000Z + + - python-feedgen + 2 - Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST" - 2024-12-20T02:24:21.673433+00:00 + Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST" + 2025-09-26T14:21:30.224663+00:00 - Recent updates to a draft Bitcoin Improvement Proposal (BIP) have been shared, detailing numerous changes, improvements, and cleanups since its initial announcement. Significant amendments include fixing a security vulnerability concerning the CertEq signature not covering the entire message, adding blame functionality for identifying faulty parties with an investigation phase, making the threshold public key Taproot-safe by default, and allowing participants to encrypt the secret share intended for themselves. This encryption uses a symmetric approach to avoid the computational overhead of ECDH computations. The full draft of the BIP is accessible for review and feedback, with a particular interest in hearing from potential users and applications, such as wallets, regarding the design decisions, the API's fit, and possible improvements. The document is hosted on GitHub, available at [this link](https://github.com/BlockstreamResearch/bip-frost-dkg). Feedback is actively sought, especially on specifying the wire format and adding test vectors. Collaboration is ongoing with siv2r, author of another BIP draft for FROST signing, to ensure compatibility between proposals. Discussions are also open regarding how to best include the "secp256k1proto" package necessary for running the reference implementation, with current preference leaning towards keeping a "git-subtree" in the BIPs repo for completeness and archival purposes. - -Privacy concerns associated with recovery data in distributed key generation (DKG) processes are highlighted, pointing out the risks of sensitive information being stored in plaintext, such as long-term "host" public keys and the final threshold public key. The threat model considers adversaries accessing this data, potentially linking on-chain transactions to individuals and compromising privacy. Currently, the protocol does not require encryption of recovery data before backup, based on the premise that encryption is a local operation and does not affect communication protocols within the DKG framework. However, feedback suggests revisiting this stance for better clarity and guidance in the BIP, proposing the use of the DKG protocol seed to derive an encryption key, thereby enhancing security and privacy without adding complexity for participants. - + 2024-12-19T10:56:00+00:00 + Recent updates to a draft Bitcoin Improvement Proposal (BIP) have been shared, detailing numerous changes, improvements, and cleanups since its initial announcement. Significant amendments include fixing a security vulnerability concerning the CertEq signature not covering the entire message, adding blame functionality for identifying faulty parties with an investigation phase, making the threshold public key Taproot-safe by default, and allowing participants to encrypt the secret share intended for themselves. This encryption uses a symmetric approach to avoid the computational overhead of ECDH computations. The full draft of the BIP is accessible for review and feedback, with a particular interest in hearing from potential users and applications, such as wallets, regarding the design decisions, the API's fit, and possible improvements. The document is hosted on GitHub, available at [this link](https://github.com/BlockstreamResearch/bip-frost-dkg). Feedback is actively sought, especially on specifying the wire format and adding test vectors. Collaboration is ongoing with siv2r, author of another BIP draft for FROST signing, to ensure compatibility between proposals. Discussions are also open regarding how to best include the "secp256k1proto" package necessary for running the reference implementation, with current preference leaning towards keeping a "git-subtree" in the BIPs repo for completeness and archival purposes. +Privacy concerns associated with recovery data in distributed key generation (DKG) processes are highlighted, pointing out the risks of sensitive information being stored in plaintext, such as long-term "host" public keys and the final threshold public key. The threat model considers adversaries accessing this data, potentially linking on-chain transactions to individuals and compromising privacy. Currently, the protocol does not require encryption of recovery data before backup, based on the premise that encryption is a local operation and does not affect communication protocols within the DKG framework. However, feedback suggests revisiting this stance for better clarity and guidance in the BIP, proposing the use of the DKG protocol seed to derive an encryption key, thereby enhancing security and privacy without adding complexity for participants. Dave raises a question regarding the privacy implications of making public recovery data accessible in the ChillDKK protocol. He draws parallels with cryptocurrency security practices, particularly comparing the exposure levels of BIP32 HD paths and xpub data in terms of privacy impact. Dave's inquiry seeks to understand whether ChillDKG's approach to publishing recovery data more closely resembles the relatively benign disclosure of an HD path or the more concerning privacy issues associated with revealing an xpub. - Jonas, Nick, and Tim are working on a draft BIP focused on Distributed Key Generation for FROST Threshold Signatures, aiming to introduce it to the community for feedback and discussion. This draft includes design considerations, usage instructions, and a Python-based reference implementation, aiming to serve as the definitive specification for the proposal. The team invites the community to review their work hosted on GitHub, emphasizing the need for feedback on several underdeveloped aspects such as the wire format, test vectors, and formalizing secp256k1proto as an official Python package. This effort reflects the ongoing initiatives to enhance cryptographic practices within the Bitcoin ecosystem, highlighting the collaborative nature of developing secure and efficient distributed key generation mechanisms. - 2024-12-19T10:56:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_BIP-Draft-FROST-Signing-.xml b/static/bitcoin-dev/July_2024/combined_BIP-Draft-FROST-Signing-.xml index f66d869837..f3cca8417b 100644 --- a/static/bitcoin-dev/July_2024/combined_BIP-Draft-FROST-Signing-.xml +++ b/static/bitcoin-dev/July_2024/combined_BIP-Draft-FROST-Signing-.xml @@ -1,23 +1,28 @@ - + 2 - Combined summary - BIP Draft: "FROST Signing" - 2024-08-01T02:15:23.813732+00:00 - - Sivaram D 2024-08-01 00:45:00+00:00 - - - Sivaram Dhakshinamoorthy 2024-07-31 11:23:00+00:00 - + Combined summary - BIP Draft: "FROST Signing" + 2025-09-26T14:21:36.563748+00:00 + python-feedgen + + + BIP Draft: "FROST Signing" Sivaram Dhakshinamoorthy + 2024-07-31T11:23:00.000Z + + + Sivaram D + 2024-08-01T00:45:00.000Z + + - python-feedgen + 2 - Combined summary - BIP Draft: "FROST Signing" - 2024-08-01T02:15:23.813773+00:00 + Combined summary - BIP Draft: "FROST Signing" + 2025-09-26T14:21:36.564248+00:00 - Sivaram has introduced a draft for a Bitcoin Improvement Proposal (BIP) focused on the FROST threshold signing protocol. The proposal is comprehensive, detailing design aspects, guidelines for usage, considerations regarding security, and includes a Python implementation along with test vectors for practical reference. To facilitate review and feedback, the draft has been made accessible at [https://github.com/siv2r/bip-frost-signing](https://github.com/siv2r/bip-frost-signing). However, it's important to note that the draft does not address key generation for FROST. Instead, it points towards existing resources for this purpose, namely the ChillDKG BIP available at [https://github.com/BlockstreamResearch/bip-frost-dkg](https://github.com/BlockstreamResearch/bip-frost-dkg) and RFC 9792's Appendix C, which can be found at [https://datatracker.ietf.org/doc/rfc9591/](https://datatracker.ietf.org/doc/rfc9591/). Sivaram emphasizes the importance of community feedback on this initiative. 2024-08-01T00:45:00+00:00 + Sivaram has introduced a draft for a Bitcoin Improvement Proposal (BIP) focused on the FROST threshold signing protocol. The proposal is comprehensive, detailing design aspects, guidelines for usage, considerations regarding security, and includes a Python implementation along with test vectors for practical reference. To facilitate review and feedback, the draft has been made accessible at [https://github.com/siv2r/bip-frost-signing](https://github.com/siv2r/bip-frost-signing). However, it's important to note that the draft does not address key generation for FROST. Instead, it points towards existing resources for this purpose, namely the ChillDKG BIP available at [https://github.com/BlockstreamResearch/bip-frost-dkg](https://github.com/BlockstreamResearch/bip-frost-dkg) and RFC 9792's Appendix C, which can be found at [https://datatracker.ietf.org/doc/rfc9591/](https://datatracker.ietf.org/doc/rfc9591/). Sivaram emphasizes the importance of community feedback on this initiative. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_Bitcoin-Core-Security-Disclosure-Policy.xml b/static/bitcoin-dev/July_2024/combined_Bitcoin-Core-Security-Disclosure-Policy.xml index cda60f7b01..25f7a194ed 100644 --- a/static/bitcoin-dev/July_2024/combined_Bitcoin-Core-Security-Disclosure-Policy.xml +++ b/static/bitcoin-dev/July_2024/combined_Bitcoin-Core-Security-Disclosure-Policy.xml @@ -1,37 +1,41 @@ - + 2 Combined summary - Bitcoin Core Security Disclosure Policy - 2024-07-12T12:03:51.047529+00:00 - - Antoine Riard 2024-07-04 14:34:00+00:00 - - - Eric Voskuil 2024-07-04 00:44:00+00:00 - - - Antoine Riard 2024-07-03 17:20:00+00:00 - - - Antoine Poinsot 2024-07-03 12:57:00+00:00 - + 2025-09-26T14:21:34.451497+00:00 + python-feedgen + + + Bitcoin Core Security Disclosure Policy 'Antoine Poinsot' + 2024-07-03T12:57:00.000Z + + + Antoine Riard + 2024-07-03T17:20:00.000Z + + + Eric Voskuil + 2024-07-04T00:44:00.000Z + + + Antoine Riard + 2024-07-04T14:34:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Core Security Disclosure Policy - 2024-07-12T12:03:51.048531+00:00 + 2025-09-26T14:21:34.452299+00:00 + 2024-07-04T14:34:00+00:00 The discourse surrounding the management and disclosure of security vulnerabilities within the Bitcoin Core community has seen a significant evolution. Historically, there has been a pervasive misperception among many users that Bitcoin Core is devoid of bugs. This notion is not only inaccurate but also detrimental to the community's wellbeing. The acknowledgment of this issue marks a critical step forward by the Bitcoin Core team in addressing the false sense of infallibility that has lingered for over a decade. Such misconceptions have previously led to material harm within the community, underscoring the importance of transparency and active engagement in security discussions. - In an effort to enhance the security posture of Bitcoin Core, a structured approach to the disclosure of security vulnerabilities has been introduced. This new policy aims to refine how vulnerabilities are communicated to the public, ensuring that both the risks of running outdated versions are clearly understood and that there is a consistent methodology for tracking and disclosing security issues. By setting clear expectations for security researchers and incentivizing the responsible reporting of vulnerabilities, the initiative seeks to foster an environment where contributors can more effectively mitigate potential threats. The differentiation between low, medium, high, and critical severity levels for vulnerabilities allows for a tailored response strategy that aligns with the impact and exploitability of identified bugs. - Furthermore, the updated lifecycle information for each Bitcoin Core release, now available at [Bitcoin Core's official site](https://bitcoincore.org/en/lifecycle/), provides essential guidance for those planning to deploy Bitcoin Core or its components in secure hardware environments. This update facilitates better management of software lifecycles, crucial for maintaining the integrity and security of implementations. - The gradual implementation of this disclosure policy represents a proactive measure by the Bitcoin Core team to address long-standing challenges in the project's security management practices. By openly disclosing vulnerabilities fixed in versions up to 0.21.0, and outlining a schedule for subsequent disclosures, the team demonstrates a commitment to transparency and the continuous improvement of Bitcoin Core's security framework. This development reflects a broader recognition within the Bitcoin community of the need to collectively address security vulnerabilities, shifting away from previous tendencies towards opacity and towards a more inclusive and informed approach to safeguarding the network. - 2024-07-04T14:34:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_Great-Consensus-Cleanup-Revival.xml b/static/bitcoin-dev/July_2024/combined_Great-Consensus-Cleanup-Revival.xml index 4509c7cd94..638fe42b72 100644 --- a/static/bitcoin-dev/July_2024/combined_Great-Consensus-Cleanup-Revival.xml +++ b/static/bitcoin-dev/July_2024/combined_Great-Consensus-Cleanup-Revival.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.043876+00:00 - - Antoine Riard 2024-11-28 05:18:00+00:00 - - - Murad Ali 2024-07-20 21:39:00+00:00 - - - Eric Voskuil 2024-07-20 20:29:00+00:00 - - - Antoine Riard 2024-07-18 17:39:00+00:00 - - - Eric Voskuil 2024-07-04 14:45:00+00:00 - - - Antoine Riard 2024-07-04 13:20:00+00:00 - - - Eric Voskuil 2024-07-03 23:29:00+00:00 - - - Eric Voskuil 2024-07-03 01:13:00+00:00 - - - Larry Ruane 2024-07-03 01:07:00+00:00 - - - Eric Voskuil 2024-07-02 15:57:00+00:00 - - - Antoine Poinsot 2024-07-02 10:23:00+00:00 - - - Antoine Riard 2024-07-02 02:36:00+00:00 - - - Eric Voskuil 2024-06-29 20:40:00+00:00 - - - Eric Voskuil 2024-06-29 20:29:00+00:00 - - - Antoine Riard 2024-06-29 01:53:00+00:00 - - - Eric Voskuil 2024-06-29 01:31:00+00:00 - - - Antoine Riard 2024-06-29 01:06:00+00:00 - - - Eric Voskuil 2024-06-28 17:14:00+00:00 - - - Antoine Poinsot 2024-06-27 09:35:00+00:00 - - - Eric Voskuil 2024-06-24 00:35:00+00:00 - - - Antoine Poinsot 2024-06-21 13:09:00+00:00 - - - Eric Voskuil 2024-06-18 13:02:00+00:00 - - - Antoine Poinsot 2024-06-18 08:13:00+00:00 - - - Eric Voskuil 2024-06-17 22:15:00+00:00 - - - Antoine Riard 2024-05-06 01:10:00+00:00 - - - Mark F 2024-04-30 22:20:00+00:00 - - - Antoine Riard 2024-04-25 06:08:00+00:00 - - - Antoine Poinsot 2024-04-18 10:04:00+00:00 - - - Mark F 2024-04-18 00:46:00+00:00 - - - Antoine Riard 2024-03-27 18:57:00+00:00 - - - Antoine Poinsot 2024-03-27 10:35:00+00:00 - - - Antoine Riard 2024-03-26 19:11:00+00:00 - - - Antoine Poinsot 2024-03-24 18:10:00+00:00 - + 2025-09-26T14:21:25.992370+00:00 + python-feedgen + + + Great Consensus Cleanup Revival 'Antoine Poinsot' + 2024-03-24T18:10:00.000Z + + + Antoine Riard + 2024-03-26T19:11:00.000Z + + + Antoine Poinsot' + 2024-03-27T10:35:00.000Z + + + Antoine Riard + 2024-03-27T18:57:00.000Z + + + Mark F + 2024-04-18T00:46:00.000Z + + + Antoine Poinsot' + 2024-04-18T10:04:00.000Z + + + Antoine Riard + 2024-04-25T06:08:00.000Z + + + Mark F + 2024-04-30T22:20:00.000Z + + + Antoine Riard + 2024-05-06T01:10:00.000Z + + + Eric Voskuil + 2024-06-17T22:15:00.000Z + + + Antoine Poinsot' + 2024-06-18T08:13:00.000Z + + + Eric Voskuil + 2024-06-18T13:02:00.000Z + + + Antoine Poinsot' + 2024-06-21T13:09:00.000Z + + + Eric Voskuil + 2024-06-24T00:35:00.000Z + + + Antoine Poinsot' + 2024-06-27T09:35:00.000Z + + + Eric Voskuil + 2024-06-28T17:14:00.000Z + + + Antoine Riard + 2024-06-29T01:06:00.000Z + + + Eric Voskuil + 2024-06-29T01:31:00.000Z + + + Antoine Riard + 2024-06-29T01:53:00.000Z + + + Eric Voskuil + 2024-06-29T20:29:00.000Z + + + Eric Voskuil + 2024-06-29T20:40:00.000Z + + + Antoine Riard + 2024-07-02T02:36:00.000Z + + + Antoine Poinsot' + 2024-07-02T10:23:00.000Z + + + Eric Voskuil + 2024-07-02T15:57:00.000Z + + + Larry Ruane + 2024-07-03T01:07:00.000Z + + + Eric Voskuil + 2024-07-03T01:13:00.000Z + + + Eric Voskuil + 2024-07-03T23:29:00.000Z + + + Antoine Riard + 2024-07-04T13:20:00.000Z + + + Eric Voskuil + 2024-07-04T14:45:00.000Z + + + Antoine Riard + 2024-07-18T17:39:00.000Z + + + Eric Voskuil + 2024-07-20T20:29:00.000Z + + + Murad Ali + 2024-07-20T21:39:00.000Z + + + Antoine Riard + 2024-11-28T05:18:00.000Z + + @@ -135,19 +171,16 @@ - python-feedgen + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.044085+00:00 + 2025-09-26T14:21:25.995675+00:00 + 2024-11-28T05:18:00+00:00 The conversation initiated by Antoine Poinsot sheds light on various aspects of the Bitcoin network's consensus mechanism, probing into areas that could benefit from improvement and adjustment. Poinsot zeroes in on concerns like the prolonged block validation times, which pose a threat to the network's overall efficacy and security framework. In response to this, he acknowledges existing solutions but proposes a supplementary strategy that caps the size of legacy transactions, aiming to bolster safety measures and ensure quicker validation processes. - Another significant point of discussion is the timewarp bug, which Poinsot indicates has not received the level of concern it rightfully demands. He emphasizes the critical need for addressing this flaw to safeguard the network’s stability. Moreover, the debate ventures into ensuring coinbase transaction uniqueness as a measure to circumvent the requirement for BIP30 validations beyond a specific block height, suggesting a potential pathway to streamline transaction verification while enhancing the network's security posture. - A nuanced proposal is introduced regarding the handling of transactions based on their sizes. Poinsot suggests maintaining the validity of transactions under 64 bytes while advocating for the invalidation of those exactly at this size threshold. This approach hints at a precise methodology aimed at refining transaction processing without imposing broad restrictions on transaction sizes. - The dialogue further extends an invitation to the community for additional insights, challenging others to identify possible disagreements, overlooked facets, or enhancements to the presented proposals. This initiative underscores a commitment to collaborative progress, aiming to cultivate a constructive forum for discussion that could lead to substantial improvements within the Bitcoin consensus mechanism. Through this exchange, Poinsot not only highlights key areas of concern but also catalyzes a broader dialogue aimed at fortifying the network against potential vulnerabilities and inefficiencies. - 2024-11-28T05:18:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_Idea-for-BIP-Deterministic-Wallets-with-Token-support.xml b/static/bitcoin-dev/July_2024/combined_Idea-for-BIP-Deterministic-Wallets-with-Token-support.xml index eef84203a8..2660f1cfad 100644 --- a/static/bitcoin-dev/July_2024/combined_Idea-for-BIP-Deterministic-Wallets-with-Token-support.xml +++ b/static/bitcoin-dev/July_2024/combined_Idea-for-BIP-Deterministic-Wallets-with-Token-support.xml @@ -1,35 +1,37 @@ - + 2 Combined summary - Idea for BIP : Deterministic Wallets with Token support - 2024-07-12T12:05:42.317085+00:00 - - Forrest96er 2024-07-09 00:55:00+00:00 - - - Aneesh Karve 2024-07-07 02:10:00+00:00 - - - Forrest96er 2024-07-06 20:41:00+00:00 - + 2025-09-26T14:21:17.296463+00:00 + python-feedgen + + + Idea for BIP : Deterministic Wallets with Token support Forrest96er + 2024-07-06T20:41:00.000Z + + + Aneesh Karve + 2024-07-07T02:10:00.000Z + + + Forrest96er + 2024-07-09T00:55:00.000Z + + - python-feedgen + 2 Combined summary - Idea for BIP : Deterministic Wallets with Token support - 2024-07-12T12:05:42.317085+00:00 + 2025-09-26T14:21:17.296969+00:00 + 2024-07-09T00:55:00+00:00 The exploration of enhancing privacy and security in cryptocurrency transactions, especially within the context of Bitcoin and Ethereum-like coins, uncovers several technical challenges and proposed solutions. One critical issue is the impracticality of adding an additional node to the derivation path in hierarchical deterministic (HD) wallets to manage the burgeoning number of tokens. This approach is deemed nearly impossible due to the constantly evolving landscape of tokens across various blockchains, which would render any list of available tokens quickly outdated. - -A more viable solution involves using the token's address or a hash of it as an additional input in the HMAC function, which generates child private and public keys. This method, recommended to be applied at the "Change" node level, allows for the creation of unique addresses for each token, thereby significantly enhancing user privacy by preventing the linking of transactions to the same identity through address reuse. It also ensures backward compatibility with BIP 44 and maintains that hardware wallets, which only export extended public keys to front-end applications, do not compromise private keys. Consequently, this system supports the dynamic generation of public keys for new tokens without requiring further exports. - +A more viable solution involves using the token's address or a hash of it as an additional input in the HMAC function, which generates child private and public keys. This method, recommended to be applied at the "Change" node level, allows for the creation of unique addresses for each token, thereby significantly enhancing user privacy by preventing the linking of transactions to the same identity through address reuse. It also ensures backward compatibility with BIP 44 and maintains that hardware wallets, which only export extended public keys to front-end applications, do not compromise private keys. Consequently, this system supports the dynamic generation of public keys for new tokens without requiring further exports. Another aspect discussed is the handling of extended public keys with caution due to their sensitive nature. Extended public keys must be treated more carefully than regular public keys because obtaining an extended public key plus any non-hardened private key descending from it could compromise the entire account. The adoption of hardened keys at the account level is suggested as a measure to mitigate this risk. - In addition, there's a mention of BIP-85, which proposes a solution for using a single secret to populate multiple wallets for various purposes through different application codes for each token. This idea aligns with the broader goal of maintaining privacy and security while accommodating the increasing complexity brought about by the multitude of new tokens. - Overall, the discussion encapsulates the ongoing efforts to refine cryptographic practices to secure digital assets better. It highlights the necessity for innovative solutions to adapt to the rapid development of cryptocurrency technologies while ensuring users' privacy and assets are protected. - 2024-07-09T00:55:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_Mining-pools-stratumv2-and-oblivious-shares.xml b/static/bitcoin-dev/July_2024/combined_Mining-pools-stratumv2-and-oblivious-shares.xml index ecd9aca9f2..fd834cd9a1 100644 --- a/static/bitcoin-dev/July_2024/combined_Mining-pools-stratumv2-and-oblivious-shares.xml +++ b/static/bitcoin-dev/July_2024/combined_Mining-pools-stratumv2-and-oblivious-shares.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Mining pools, stratumv2 and oblivious shares - 2024-08-28T02:15:11.352385+00:00 - - Matt Corallo 2024-08-27 13:52:00+00:00 - - - Anthony Towns 2024-08-27 09:07:00+00:00 - - - Matt Corallo 2024-08-21 14:28:00+00:00 - - - Anthony Towns 2024-08-16 02:10:00+00:00 - - - Matt Corallo 2024-08-13 13:57:00+00:00 - - - Anthony Towns 2024-07-31 18:00:00+00:00 - - - Luke Dashjr 2024-07-23 18:44:00+00:00 - - - Anthony Towns 2024-07-23 15:02:00+00:00 - + 2025-09-26T14:21:19.450364+00:00 + python-feedgen + + + Mining pools, stratumv2 and oblivious shares Anthony Towns + 2024-07-23T15:02:00.000Z + + + Luke Dashjr + 2024-07-23T18:44:00.000Z + + + Anthony Towns + 2024-07-31T18:00:00.000Z + + + Matt Corallo + 2024-08-13T13:57:00.000Z + + + Anthony Towns + 2024-08-16T02:10:00.000Z + + + Matt Corallo + 2024-08-21T14:28:00.000Z + + + Anthony Towns + 2024-08-27T09:07:00.000Z + + + Matt Corallo + 2024-08-27T13:52:00.000Z + + @@ -35,19 +46,16 @@ - python-feedgen + 2 Combined summary - Mining pools, stratumv2 and oblivious shares - 2024-08-28T02:15:11.352454+00:00 + 2025-09-26T14:21:19.451404+00:00 + 2024-08-27T13:52:00+00:00 The conversation delves into the nuanced challenges and potential strategies within cryptocurrency mining, particularly focusing on block withholding attacks and the implications for mining pools. It highlights the dilemma faced by pools in distinguishing between honest miners and attackers, especially given the feasibility of such attacks even with a minor portion of the pool’s total hash rate being maliciously used. The dialogue underscores the precarious position of mining pools that do not enforce rigorous entry criteria or share validation processes, making them vulnerable to these attacks. This vulnerability is exacerbated when attackers disguise their malicious intent by distributing their hash rate across multiple low-profile accounts, complicating the detection process through statistical analysis. - A significant concern raised is the practicality of validating every submitted share to ensure its legitimacy, which could centralize the mining process, undermining the decentralized ethos of blockchain technology. Furthermore, the email debates the effectiveness of solutions like Know Your Customer (KYC) measures or limiting membership based on hash rate, suggesting these might protect pools but at the cost of decentralization. The discussion also explores hypothetical attack scenarios, illustrating how an attacker could undermine a pool’s profitability and the rewards of honest miners, thereby questioning the sustainability of pools without stringent defensive measures. - Regarding Stratum V2's design and its impact on template distribution and block withholding risks, the conversation suggests that while decentralization in work selection empowers miners, it also opens up vulnerabilities to attacks that exploit the autonomy in block submission. The critique extends to the challenges of managing a decentralized pool, emphasizing the importance of a trusted coordinator in validating work and ensuring fair reward distribution. However, this necessity poses questions about maintaining true decentralization and the effectiveness of potential solutions like oblivious shares or changes to the Proof of Work algorithm that could mitigate block withholding but require significant alterations to the mining protocol. - The discourse further examines the broader implications for Bitcoin's network design, particularly the tension between fostering decentralization and addressing pooling and centralization concerns. The mention of zero-knowledge proofs as a future solution indicates ongoing exploration for more secure and private validation methods, though acknowledging current technological and practical barriers. Lastly, the conversation acknowledges the complex dynamics of pooled mining and the continual search for a balance between innovation, security, and adherence to blockchain's foundational principles, highlighting the role of community collaboration in navigating these challenges. - 2024-08-27T13:52:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_OP-ZKP-updates.xml b/static/bitcoin-dev/July_2024/combined_OP-ZKP-updates.xml index a5efee2a34..d2afecd0db 100644 --- a/static/bitcoin-dev/July_2024/combined_OP-ZKP-updates.xml +++ b/static/bitcoin-dev/July_2024/combined_OP-ZKP-updates.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - OP_ZKP updates - 2024-10-15T02:24:46.644195+00:00 - - Weiji Guo 2024-10-14 09:00:00+00:00 - - - Weiji Guo 2024-08-28 15:33:00+00:00 - - - Weiji Guo 2024-07-22 22:38:00+00:00 - - - Weikeng Chen 2024-07-22 18:45:00+00:00 - - - Weiji Guo 2024-07-22 14:05:00+00:00 - + 2025-09-26T14:21:23.801474+00:00 + python-feedgen + + + OP_ZKP updates Weiji Guo + 2024-07-22T14:05:00.000Z + + + Weikeng Chen + 2024-07-22T18:45:00.000Z + + + Weiji Guo + 2024-07-22T22:38:00.000Z + + + Weiji Guo + 2024-08-28T15:33:00.000Z + + + Weiji Guo + 2024-10-14T09:00:00.000Z + + - python-feedgen + 2 Combined summary - OP_ZKP updates - 2024-10-15T02:24:46.644247+00:00 + 2025-09-26T14:21:23.802212+00:00 - The recent updates in cryptographic solutions within the domain of open application circuits emphasize a shift towards recursive verification to streamline the process. This approach negates the requirement to publish each application circuit's verification key on-chain, opting instead for a singular circuit verified through recursion. A dedicated GitHub organization and repository, named "tea-horse," have been established to facilitate the sharing of ideas and developments related to this innovative strategy. While the repository is currently in the early stages of development, it is expected to become a valuable resource for those interested in contributing to or understanding the project further. The links to both the GitHub organization and the specific repository are made available for easy access. - + 2024-10-14T09:00:00+00:00 + The recent updates in cryptographic solutions within the domain of open application circuits emphasize a shift towards recursive verification to streamline the process. This approach negates the requirement to publish each application circuit's verification key on-chain, opting instead for a singular circuit verified through recursion. A dedicated GitHub organization and repository, named "tea-horse," have been established to facilitate the sharing of ideas and developments related to this innovative strategy. While the repository is currently in the early stages of development, it is expected to become a valuable resource for those interested in contributing to or understanding the project further. The links to both the GitHub organization and the specific repository are made available for easy access. The discussion also delves into the technical requisites for implementing Dory, a cryptographic solution that necessitates pairing-friendly curves, contrasting with secp256k1's lack of support for pairing operations. This distinction underscores the importance of selecting cryptographic curves that align with the operational requirements of Dory, highlighting its need for pairing to function properly. Despite Dory's promise in terms of transparency and efficiency, its larger proof size compared to other solutions presents a challenge, illustrating the complexities involved in choosing a cryptographic framework that balances technical specifications with desired outcomes such as transparency and scalability. - Weiji Guo highlighted a technical limitation regarding the compatibility of Dory with secp256k1, pointing out that Dory's reliance on pairing operations, which secp256k1 does not support, poses a significant hurdle. This highlights the need for further exploration or alternative solutions to overcome this compatibility issue, reflecting a nuanced understanding of cryptographic principles necessary to address these challenges. - The OP_ZKP proposal aims to integrate Zero-Knowledge Proofs within Bitcoin transactions by identifying an appropriate ZKP scheme that meets several high-level requirements. These include minimal security assumptions, small block size consumption, and the capability for batched verification and aggregated proving without necessitating a trusted setup. The Inner Product Argument (IPA) emerges as a potential candidate due to its transparent setup, compatibility with secp256k1, and relatively small proof size. However, challenges such as linear verification time and scalability of verification keys remain. Aggregated proving techniques are suggested to mitigate these issues, although concerns about the deployment of large verification keys and the overall system complexity persist. Future considerations involve evaluating the performance impact on lower-powered devices and potentially exploring alternative schemes like Dory, should unresolved issues with IPA persist. For those interested in further reading on SNARKs misconceptions and Torus-based optimization, additional resources are provided, including detailed articles from [a16zcrypto](https://a16zcrypto.com/posts/article/17-misconceptions-about-snarks/section--11) and links to a video and paper discussing Torus optimization. - 2024-10-14T09:00:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml b/static/bitcoin-dev/July_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml index 74bdc74a4c..22dde1f650 100644 --- a/static/bitcoin-dev/July_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml +++ b/static/bitcoin-dev/July_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Proposing a P2QRH BIP towards a quantum resistant soft fork - 2024-09-26T03:18:36.202311+00:00 - - Hunter Beast 2024-09-25 12:04:00+00:00 - - - Antoine Riard 2024-08-22 06:20:00+00:00 - - - Hunter Beast 2024-08-15 05:05:00+00:00 - - - Hunter Beast 2024-08-06 17:37:00+00:00 - - - Antoine Riard 2024-07-13 01:34:00+00:00 - - - hunter 2024-06-17 20:27:00+00:00 - - - Antoine Riard 2024-06-17 01:07:00+00:00 - - - Hunter Beast 2024-06-14 14:28:00+00:00 - - - PierreLuc DallaireDemers 2024-06-14 13:51:00+00:00 - - - Hunter Beast 2024-06-08 21:04:00+00:00 - + 2025-09-26T14:21:38.756688+00:00 + python-feedgen + + + Proposing a P2QRH BIP towards a quantum resistant soft fork Hunter Beast + 2024-06-08T21:04:00.000Z + + + Pierre-Luc Dallaire-Demers + 2024-06-14T13:51:00.000Z + + + Hunter Beast + 2024-06-14T14:28:00.000Z + + + Antoine Riard + 2024-06-17T01:07:00.000Z + + + hunter + 2024-06-17T20:27:00.000Z + + + Antoine Riard + 2024-07-13T01:34:00.000Z + + + Hunter Beast + 2024-08-06T17:37:00.000Z + + + Hunter Beast + 2024-08-15T05:05:00.000Z + + + Antoine Riard + 2024-08-22T06:20:00.000Z + + + Hunter Beast + 2024-09-25T12:04:00.000Z + + @@ -43,21 +56,17 @@ - python-feedgen + 2 Combined summary - Proposing a P2QRH BIP towards a quantum resistant soft fork - 2024-09-26T03:18:36.202392+00:00 + 2025-09-26T14:21:38.757983+00:00 + 2024-09-25T12:04:00+00:00 The recent discussions and updates surrounding the development of a Bitcoin Improvement Proposal (BIP) to introduce quantum resistance into Bitcoin's cryptographic framework underscore the community's proactive approach towards safeguarding the cryptocurrency against potential quantum computing threats. Central to these discussions is the acknowledgment of IBM's advancements in quantum computing, particularly with its Quantum System Two, which potentially supports up to 16,000 qubits. This advancement hints at a future where quantum computing could significantly impact cryptographic security, necessitating the exploration of post-quantum cryptographic algorithms. - The discourse extends beyond merely recognizing the threat, delving into specific cryptographic considerations and solutions. For example, the integration of FALCON, a post-quantum signature algorithm, into the proposed BIP reflects a thoughtful response to the nuanced challenges posed by quantum computing. This choice is indicative of the community's effort to balance security needs with practical implementation concerns such as signature size and transaction costs. The dialogue also touches on broader strategic issues, including the potential for increased witness discounts to accommodate larger transactions, underscoring the ongoing effort to maintain Bitcoin's scalability and security in tandem. - Moreover, the discussions reveal an awareness of the limitations and uncertainties inherent in predicting quantum computing's progression. References to IBM's roadmap and the need for cautious optimism highlight the complex interplay between technological advancement and cryptographic security. The conversation acknowledges the diversity of quantum computing architectures and their implications for cryptographic attacks, emphasizing the importance of a robust, adaptable approach to security. - Significantly, the proposal outlines defensive measures that Bitcoin users can implement today, such as configuring spending scripts to require artificially inflated witness stacks. This strategy exemplifies the multifaceted approach needed to address quantum threats, combining immediate practical measures with long-term cryptographic evolution. The suggestion to use trusted mining pools for transaction submission further illustrates the community's willingness to explore diverse strategies to mitigate risk. - In summary, the ongoing dialogue around introducing quantum resistance to Bitcoin through a dedicated BIP reflects a comprehensive and forward-looking approach to cryptocurrency security. It underscores the community's commitment to addressing emerging threats through research, collaboration, and innovation. The inclusion of FALCON signatures and the consideration of various post-quantum cryptographic schemes highlight the technical complexity of this endeavor, while discussions about implementation strategies and the potential impact on transaction throughput reveal the broader strategic considerations at play. As the landscape of quantum computing continues to evolve, the Bitcoin community's proactive engagement with these challenges will be crucial in ensuring the cryptocurrency's resilience and longevity. - 2024-09-25T12:04:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_Public-disclosure-of-10-vulnerabilities-affecting-Bitcoin-Core-0-21-0.xml b/static/bitcoin-dev/July_2024/combined_Public-disclosure-of-10-vulnerabilities-affecting-Bitcoin-Core-0-21-0.xml index 5d4d6aa67a..f0c2c61b28 100644 --- a/static/bitcoin-dev/July_2024/combined_Public-disclosure-of-10-vulnerabilities-affecting-Bitcoin-Core-0-21-0.xml +++ b/static/bitcoin-dev/July_2024/combined_Public-disclosure-of-10-vulnerabilities-affecting-Bitcoin-Core-0-21-0.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Public disclosure of 10 vulnerabilities affecting Bitcoin Core < 0.21.0 - 2024-07-12T12:04:30.113617+00:00 - - Antoine Poinsot 2024-07-10 07:40:00+00:00 - - - Antoine Riard 2024-07-03 17:12:00+00:00 - - - Antoine Poinsot 2024-07-03 16:34:00+00:00 - + 2025-09-26T14:21:28.109933+00:00 + python-feedgen + + + Public disclosure of 10 vulnerabilities affecting Bitcoin Core < 0.21.0 'Antoine Poinsot' + 2024-07-03T16:34:00.000Z + + + Antoine Riard + 2024-07-03T17:12:00.000Z + + + Antoine Poinsot' + 2024-07-10T07:40:00.000Z + + - python-feedgen + 2 Combined summary - Public disclosure of 10 vulnerabilities affecting Bitcoin Core < 0.21.0 - 2024-07-12T12:04:30.114617+00:00 + 2025-09-26T14:21:28.110503+00:00 + 2024-07-10T07:40:00+00:00 The correspondence among the individuals named Antoine revolves around enhancing the security advisory practices for a software project. The initiative to retroactively request CVE (Common Vulnerabilities and Exposures) numbers for historical issues from Mitre is mentioned as an underway effort. This approach aims at systematically cataloging past vulnerabilities to better manage and mitigate risks associated with software regressions. The suggestion to assign unique numeric identifiers to each security advisory, as demonstrated by OpenSSH's recent actions, is highlighted as a beneficial strategy. Such identifiers not only facilitate a methodical review of old vulnerabilities when evaluating new changes but also simplify the coordination among security researchers and handlers in developing and deploying mitigation patches. - Additionally, the gradual adoption of a new vulnerability disclosure policy by the project is discussed. The policy, along with the ten security advisories, is accessible on the project's website ([Bitcoin Core Security Advisories](https://bitcoincore.org/en/security-advisories)). Plans are outlined to follow up with public disclosures of vulnerabilities addressed in successive versions of the software, starting with version 22.0 in July, followed by version 23.0 in August, and continuing with subsequent versions until all vulnerabilities in old unmaintained versions have been disclosed. This structured approach to vulnerability disclosure is posited as a measure that will be consistently applied to new software versions moving forward, marking a significant step in the project's commitment to security transparency and improvement. - 2024-07-10T07:40:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2024/combined_Public-disclosure-of-2-vulnerabilities-affecting-Bitcoin-Core-v22-0.xml b/static/bitcoin-dev/July_2024/combined_Public-disclosure-of-2-vulnerabilities-affecting-Bitcoin-Core-v22-0.xml index af1659510e..822cec0986 100644 --- a/static/bitcoin-dev/July_2024/combined_Public-disclosure-of-2-vulnerabilities-affecting-Bitcoin-Core-v22-0.xml +++ b/static/bitcoin-dev/July_2024/combined_Public-disclosure-of-2-vulnerabilities-affecting-Bitcoin-Core-v22-0.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Public disclosure of 2 vulnerabilities affecting Bitcoin Core < v22.0 - 2024-08-05T02:11:09.512200+00:00 - - hashnoncemessage 2024-08-04 06:41:00+00:00 - - - Peter Todd 2024-07-31 19:01:00+00:00 - - - Niklas Goegge 2024-07-31 17:01:00+00:00 - + 2025-09-26T14:21:32.338427+00:00 + python-feedgen + + + Public disclosure of 2 vulnerabilities affecting Bitcoin Core < v22.0 Niklas Goegge + 2024-07-31T17:01:00.000Z + + + Peter Todd + 2024-07-31T19:01:00.000Z + + + hashnoncemessage' + 2024-08-04T06:41:00.000Z + + - python-feedgen + 2 Combined summary - Public disclosure of 2 vulnerabilities affecting Bitcoin Core < v22.0 - 2024-08-05T02:11:09.512245+00:00 + 2025-09-26T14:21:32.339004+00:00 + 2024-08-04T06:41:00+00:00 Recent discussions have brought to light two critical security vulnerabilities that have raised concerns within the digital security community. These vulnerabilities, revealed in reverse chronological order on the advisories page, highlight the ongoing challenges faced in cybersecurity regarding the dissemination and management of sensitive information. The first vulnerability involves the potential for OP Nodes to be spammed with addr messages, leading to possible crashes. This issue was addressed with a fix released on September 14th, 2021, in Bitcoin Core v22.0. Similarly, a fix for nodes potentially being crashed by malicious UPnP devices on the local network was also released on the same date in Bitcoin Core v22.0. - The communication underscores the importance of clear, detailed information about these vulnerabilities to understand their implications fully and implement necessary mitigation measures. A link to [https://petertodd.org](https://petertodd.org) is provided for those seeking more comprehensive details, indicating a resource for further exploration of these issues. - Additionally, Bitcoin Core has been proactive in enhancing its security framework through the adoption of a new vulnerability disclosure policy. This initiative aims to systematically reveal resolved vulnerabilities, starting with those fixed in version v23.0 to be disclosed later in August, followed by version v24.0 disclosures in September. This schedule continues with announcements for older, unmaintained versions, ensuring all known vulnerabilities are eventually made public. This approach reflects Bitcoin Core's commitment to transparency and security, marking a significant advancement in how vulnerability disclosures are managed. Detailed information regarding this policy and the specific advisories can be accessed via the [security advisories page](https://bitcoincore.org/en/security-advisories) on the Bitcoin Core website, reinforcing the project's dedication to safeguarding its infrastructure against potential threats. - 2024-08-04T06:41:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Compressed-Base58-Encoding-for-BIP-39-Mnemonics-with-Multisig-Extensions.xml b/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Compressed-Base58-Encoding-for-BIP-39-Mnemonics-with-Multisig-Extensions.xml index 2fb700f741..01c7081167 100644 --- a/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Compressed-Base58-Encoding-for-BIP-39-Mnemonics-with-Multisig-Extensions.xml +++ b/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Compressed-Base58-Encoding-for-BIP-39-Mnemonics-with-Multisig-Extensions.xml @@ -1,29 +1,31 @@ - + 2 Combined summary - [BIP Proposal] Compressed Base58 Encoding for BIP-39 Mnemonics with Multisig Extensions - 2025-07-16T03:17:58.262544+00:00 - - Russell OConnor 2025-07-14 20:48:00+00:00 - - - Zach 2025-07-14 16:12:00+00:00 - + 2025-09-26T14:25:46.928067+00:00 + python-feedgen + + + [BIP Proposal] Compressed Base58 Encoding for BIP-39 Mnemonics with Multisig Extensions Zach + 2025-07-14T16:12:00.000Z + + + Russell O'Connor' + 2025-07-14T20:48:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Compressed Base58 Encoding for BIP-39 Mnemonics with Multisig Extensions - 2025-07-16T03:17:58.262591+00:00 + 2025-09-26T14:25:46.928510+00:00 + 2025-07-14T20:48:00+00:00 The discussion begins with an evaluation of a proposed Bitcoin Improvement Proposal (BIP) that seeks to enhance the security and usability of wallets by offering an innovative approach to compressing mnemonic phrases. The method introduced suggests condensing BIP-39 mnemonic phrases into a 24-character string using Base58 encoding. This proposed system marks a departure from the traditional 12-word mnemonics, aiming for a more compact and simplified representation without sacrificing the deterministic, reversible qualities inherent in current seed generation methodologies. - A notable feature of this proposal is its optional extension for multi-signature (multisig) setups, which is particularly advantageous for scenarios such as 2-of-3 schemes. In these arrangements, each participant would store a compressed local mnemonic alongside the extended public keys (xpubs) from other participants, concatenated into a single Base58 string equipped with a checksum to ensure integrity. This format, envisioned to be around 252 characters long, is designed to facilitate secure, distributed storage and improve the management of mnemonic and multisig data within limited space situations, like physical backups or QR codes. - Further detailed in the proposal is the encoding process, which involves specific division and remainder operations to map each word from the BIP-39 English wordlist to a unique two-character code. The choice of Base58 is justified by its efficiency and compatibility, offering the capacity to uniquely represent all 2048 words. Additionally, the structure and verification processes for the multisig storage format are elucidated, showing how this condensed format could streamline operations involving multiple parties and locations. - Finally, Zach, the proponent of this initiative, actively solicits feedback from the Bitcoin-Dev community on his draft, signaling a willingness to incorporate suggestions to refine the proposal further. He acknowledges the foundational contributions of the BIP-39 authors and the Bitcoin community's role in establishing Base58 standards, situating his proposal as a continuation of these efforts while striving for advancements in wallet security and usability. His work represents a thoughtful attempt to reconcile the needs for compactness and security in cryptocurrency storage and management, as evidenced in the ongoing work towards Bitcoin Core enhancement through [GitHub](https://github.com/bitcoin/bitcoin/pull/32652), albeit noted as a work in progress. - 2025-07-14T20:48:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Proof-of-Activity-Reclamation-PoAR-.xml b/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Proof-of-Activity-Reclamation-PoAR-.xml index 84c054bb86..8cab47fbcf 100644 --- a/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Proof-of-Activity-Reclamation-PoAR-.xml +++ b/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Proof-of-Activity-Reclamation-PoAR-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - [BIP Proposal] Proof-of-Activity Reclamation (PoAR) - 2025-07-21T03:13:57.265689+00:00 - - Javier Mateos 2025-07-20 23:13:00+00:00 - - - Peter Todd 2025-07-16 20:49:00+00:00 - - - Murch 2025-07-15 22:02:00+00:00 - - - Donald Dienst 2025-07-15 21:58:00+00:00 - - - Boris Nagaev 2025-07-15 19:28:00+00:00 - - - Christian Riley 2025-07-15 19:07:00+00:00 - - - Donald Dienst 2025-07-15 18:48:00+00:00 - - - Donald Dienst 2025-07-10 22:55:00+00:00 - + 2025-09-26T14:25:38.243240+00:00 + python-feedgen + + + [BIP Proposal] Proof-of-Activity Reclamation (PoAR) 'Donald Dienst' + 2025-07-10T22:55:00.000Z + + + Christian Riley + 2025-07-15T18:48:00.000Z + + + Lucas Barbosa + 2025-07-15T19:07:00.000Z + + + Boris Nagaev + 2025-07-15T19:28:00.000Z + + + Donald Dienst' + 2025-07-15T21:58:00.000Z + + + Murch + 2025-07-15T22:02:00.000Z + + + Peter Todd + 2025-07-16T20:49:00.000Z + + + Javier Mateos + 2025-07-20T23:13:00.000Z + + @@ -35,23 +46,18 @@ - python-feedgen + 2 Combined summary - [BIP Proposal] Proof-of-Activity Reclamation (PoAR) - 2025-07-21T03:13:57.265758+00:00 + 2025-09-26T14:25:38.244084+00:00 - The discussion initiated by Donald Dienst about the "Bitcoin Dormant Recovery Proposal" and the subsequent exchanges among developers and stakeholders in the Bitcoin community have highlighted several critical considerations regarding the long-term economic sustainability of Bitcoin, particularly in relation to lost or abandoned coins. The debate centers around the proposal to reintroduce lost bitcoins into circulation through a mechanism termed "Proof-of-Activity Reclamation (PoAR)," which aims to address issues such as miner incentives, artificial scarcity, confiscation risks, and the need for Bitcoin to sustain its economy without resorting to altering its foundational principles. - + 2025-07-20T23:13:00+00:00 + The discussion initiated by Donald Dienst about the "Bitcoin Dormant Recovery Proposal" and the subsequent exchanges among developers and stakeholders in the Bitcoin community have highlighted several critical considerations regarding the long-term economic sustainability of Bitcoin, particularly in relation to lost or abandoned coins. The debate centers around the proposal to reintroduce lost bitcoins into circulation through a mechanism termed "Proof-of-Activity Reclamation (PoAR)," which aims to address issues such as miner incentives, artificial scarcity, confiscation risks, and the need for Bitcoin to sustain its economy without resorting to altering its foundational principles. Critics of the proposal argue that the concern over miner incentives due to the eventual mining cap being reached is exaggerated. They assert that transaction fees can naturally compensate for the decrease in block rewards, negating the need for drastic changes based on distant future speculation. Furthermore, the divisibility of Bitcoin into satoshis is highlighted as a design feature that counters concerns over artificial scarcity. Any potential adjustments to extend decimal places in the future would not fundamentally alter Bitcoin's core rules, according to proponents who see the system's deflationary aspect as beneficial rather than problematic. - The issue of confiscation, disguised as reauthentication of dormant coins, has raised significant ethical and practical concerns. Critics argue that the inability to distinguish between truly lost coins and those intentionally held as part of long-term savings or inheritance plans poses a risk of unjustly penalizing certain users under the guise of reactivating dormant value within the network. This argument extends to the broader philosophical foundation of Bitcoin, emphasizing individual sovereignty over one's funds without the obligation to engage in active transactions. - Donald Dienst's proposal suggests a nuanced approach to reintroducing lost bitcoins back into circulation, advocating for a rules-based mechanism that respects multi-generational ownership while addressing the economic implications of permanently lost coins. He suggests extending the inactivity window to mitigate concerns over long-term planning, such as inheritance, and proposes enhancements for post-quantum security as part of a broader hard fork. This approach aims to balance preserving Bitcoin's utility as both a store of value and a medium of exchange against the backdrop of inevitable wallet access losses. - The Proof-of-Activity Reclamation (PoAR) proposal specifically targets the recycling of coins inactive for more than 20 years, reintroducing them into circulation to extend miner incentives within the fixed supply framework. However, this proposition has sparked debate over its necessity and potential impact on Bitcoin's economic model, raising questions about backward compatibility, the ethics of reallocating inactive coins, and the overall feasibility of implementing such a change through a hard fork. Critics highlight the risks associated with disrupting long-term financial planning and the shift in funding sources for network security from active transactions to a form of value reallocation from inactive holders. - In essence, the discourse surrounding the PoAR proposal underscores the complexity of managing digital currency economies, the ethical considerations in distinguishing between lost and purposefully dormant assets, and the importance of maintaining Bitcoin's foundational principles amidst evolving economic dynamics. The community's response to these proposals reflects a cautious approach to altering Bitcoin's economic model, emphasizing thorough analysis, consensus-building, and respect for individual autonomy in digital asset management. - 2025-07-20T23:13:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Utreexo-Nodes.xml b/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Utreexo-Nodes.xml index 347ce54a0f..b5e98cd4f8 100644 --- a/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Utreexo-Nodes.xml +++ b/static/bitcoin-dev/July_2025/combined_-BIP-Proposal-Utreexo-Nodes.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - [BIP Proposal] Utreexo Nodes - 2025-08-13T03:00:00.244983+00:00 - - Calvin Kim 2025-08-10 06:58:00+00:00 - - - Murch 2025-08-06 22:36:00+00:00 - - - K Calvin 2025-07-30 14:20:00+00:00 - - - Javier Mateos 2025-07-30 02:33:00+00:00 - - - Calvin Kim 2025-07-29 23:20:00+00:00 - + 2025-09-26T14:25:51.198899+00:00 + python-feedgen + + + [BIP Proposal] Utreexo Nodes Calvin Kim + 2025-07-29T23:20:00.000Z + + + Javier Mateos + 2025-07-30T02:33:00.000Z + + + K Calvin + 2025-07-30T14:20:00.000Z + + + Murch + 2025-08-06T22:36:00.000Z + + + Calvin Kim + 2025-08-10T06:58:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Utreexo Nodes - 2025-08-13T03:00:00.245038+00:00 + 2025-09-26T14:25:51.199656+00:00 + 2025-08-10T06:58:00+00:00 Calvin Kim has successfully submitted a pull request for review, as indicated by the communication from Murch, which is part of the ongoing discussions within the Bitcoin Development Mailing List. This particular effort is highlighted in the process of developing and refining Bitcoin Improvement Proposals (BIPs), specifically around the concept of Utreexo. Utreexo's main aim is to enhance the efficiency and scalability of Bitcoin transactions by introducing a method that allows for transaction verification without the full Unspent Transaction Output (UTXO) set. The contributions of Tadge Dryja, Davidson Souza, and Calvin are pivotal in this regard, proposing three distinct BIPs focusing on different aspects of Utreexo: the accumulator specifications, the validation process of Bitcoin blocks and transactions through the accumulator, and the necessary adjustments within peer-to-peer networking to support Utreexo nodes. - The collaborative nature of these developments emphasizes the iterative feedback and review process inherent to the Bitcoin open-source community. Javier Mateos' review of the draft proposals acknowledges their progress and alignment with editorial standards, encouraging further refinement and submission when ready. This reflects the constructive engagement and support within the community, aiming at continuous improvement and innovation. - A specific point of discussion concerns the segregation of functionalities across the proposed BIPs, particularly the deliberate choice to exclude Bitcoin-related operations from the accumulator BIP to maintain focus and clarity. However, an identified gap in the current specifications pertains to the lack of a defined deterministic order for processing UTXO deletions and additions, a detail crucial for the accumulator's consistency and reliability. This highlights both the depth of analysis already undertaken and the areas requiring further attention to ensure the robustness of the proposed changes. - Moreover, the division of Utreexo into three layers—accumulator, validation, and peer-to-peer (P2P)—is designed to facilitate the review process and integration into the Bitcoin ecosystem. This structured approach demonstrates a clear vision for Utreexo's role in enhancing blockchain infrastructure, addressing both theoretical and practical considerations in its development. The community's engagement through platforms like GitHub, as seen in the provision of links to access the BIP documents ([https://github.com/utreexo/biptreexo](https://github.com/utreexo/biptreexo)), exemplifies the open and collaborative effort towards refining these proposals. Through such endeavors, Utreexo aims to contribute significantly to the scalability and decentralization of Bitcoin's network, marking an important step forward in blockchain technology. - 2025-08-10T06:58:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_A-Post-Quantum-Migration-Proposal.xml b/static/bitcoin-dev/July_2025/combined_A-Post-Quantum-Migration-Proposal.xml index 26784ef9fd..d456637a97 100644 --- a/static/bitcoin-dev/July_2025/combined_A-Post-Quantum-Migration-Proposal.xml +++ b/static/bitcoin-dev/July_2025/combined_A-Post-Quantum-Migration-Proposal.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - A Post Quantum Migration Proposal - 2025-09-16T02:26:25.679229+00:00 - - conduition 2025-09-15 16:24:00+00:00 - - - Saint Wenhao 2025-08-23 10:22:00+00:00 - - - conduition 2025-08-22 19:59:00+00:00 - - - Saint Wenhao 2025-08-19 08:55:00+00:00 - - - Marc Johnson 2025-08-16 18:40:00+00:00 - - - Jameson Lopp 2025-08-12 14:56:00+00:00 - - - Marc Johnson 2025-07-25 10:58:00+00:00 - - - Boris Nagaev 2025-07-20 22:54:00+00:00 - - - Marin Ivezic 2025-07-20 17:39:00+00:00 - - - conduition 2025-07-20 15:56:00+00:00 - - - conduition 2025-07-20 15:37:00+00:00 - - - Peter Todd 2025-07-19 12:05:00+00:00 - - - Antoine Riard 2025-07-18 19:13:00+00:00 - - - Boris Nagaev 2025-07-16 17:34:00+00:00 - - - conduition 2025-07-16 16:43:00+00:00 - - - Ethan Heilman 2025-07-15 17:57:00+00:00 - - - Boris Nagaev 2025-07-15 14:13:00+00:00 - - - Boris Nagaev 2025-07-15 02:50:00+00:00 - - - conduition 2025-07-15 02:32:00+00:00 - - - Jameson Lopp 2025-07-14 18:52:00+00:00 - - - Ethan Heilman 2025-07-14 16:08:00+00:00 - - - Jameson Lopp 2025-07-14 13:50:00+00:00 - - - Antoine Riard 2025-07-14 02:07:00+00:00 - - - Tadge Dryja 2025-07-13 23:19:00+00:00 - - - Jameson Lopp 2025-07-12 21:36:00+00:00 - + 2025-09-26T14:25:40.476283+00:00 + python-feedgen + + + A Post Quantum Migration Proposal Jameson Lopp + 2025-07-12T21:36:00.000Z + + + Tadge Dryja + 2025-07-13T23:19:00.000Z + + + Antoine Riard + 2025-07-14T02:07:00.000Z + + + Jameson Lopp + 2025-07-14T13:50:00.000Z + + + Ethan Heilman + 2025-07-14T16:08:00.000Z + + + Jameson Lopp + 2025-07-14T18:52:00.000Z + + + conduition' + 2025-07-15T02:32:00.000Z + + + Boris Nagaev + 2025-07-15T02:50:00.000Z + + + Boris Nagaev + 2025-07-15T14:13:00.000Z + + + Ethan Heilman + 2025-07-15T17:57:00.000Z + + + conduition' + 2025-07-16T16:43:00.000Z + + + Boris Nagaev + 2025-07-16T17:34:00.000Z + + + Antoine Riard + 2025-07-18T19:13:00.000Z + + + Peter Todd + 2025-07-19T12:05:00.000Z + + + conduition' + 2025-07-20T15:37:00.000Z + + + conduition' + 2025-07-20T15:56:00.000Z + + + Marin Ivezic + 2025-07-20T17:39:00.000Z + + + Boris Nagaev + 2025-07-20T22:54:00.000Z + + + Marc Johnson + 2025-07-25T10:58:00.000Z + + + Jameson Lopp + 2025-08-12T14:56:00.000Z + + + Marc Johnson + 2025-08-16T18:40:00.000Z + + + Saint Wenhao + 2025-08-19T08:55:00.000Z + + + conduition' + 2025-08-22T19:59:00.000Z + + + Saint Wenhao + 2025-08-23T10:22:00.000Z + + + conduition' + 2025-09-15T16:24:00.000Z + + @@ -103,17 +131,15 @@ - python-feedgen + 2 Combined summary - A Post Quantum Migration Proposal - 2025-09-16T02:26:25.679400+00:00 + 2025-09-26T14:25:40.478884+00:00 + 2025-09-15T16:24:00+00:00 The discourse on enhancing Bitcoin's defense against quantum computing threats posits a phased proposal to transition the network towards post-quantum cryptographic standards. This approach is rooted in the urgency to protect the network against potential quantum attacks that could compromise its cryptographic underpinnings. By introducing a new post-quantum output type (P2QRH) and setting a timeline for phasing out legacy ECDSA/Schnorr signatures, the proposal aims to preemptively secure Bitcoin's future. The initial phase mandates stopping transactions to quantum-vulnerable addresses, advocating for a swift migration to P2QRH address types. Subsequently, spending from quantum-vulnerable UTXOs would be deemed invalid, halting transactions reliant on traditional cryptographic methods. An optional third phase explores the possibility of recovering frozen assets through zero-knowledge proofs, pending further research and consensus within the community. - This strategic initiative underscores the critical need for a proactive stance against the quantum threat, motivated by recent advancements in quantum algorithms and NIST's endorsement of post-quantum signature schemes. A successful quantum breach could drastically erode confidence in Bitcoin, inflicting substantial economic repercussions. Hence, the proposal articulates a defensive maneuver, prescribing deadlines for adopting quantum-resistant cryptographic practices to galvanize stakeholders across the Bitcoin ecosystem towards a unified response. - The proposal delineates specific expectations from various ecosystem participants, including miners, institutional holders, exchanges, custodians, and regular users, highlighting the tailored incentives for each group to upgrade. This collective effort aims to diminish the attack surface and mitigate potential losses, portraying the shift to quantum-resistant cryptography as a communal benefit. Moreover, it addresses the technical feasibility of implementing these changes via soft forks, ensuring backward compatibility and offering a gradual, inclusive path towards enhancing Bitcoin's resilience in the quantum era. - 2025-09-15T16:24:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_A-Taproot-native-re-bindable-transaction-bundle-proposal.xml b/static/bitcoin-dev/July_2025/combined_A-Taproot-native-re-bindable-transaction-bundle-proposal.xml index eeb1a14c01..307a89e9cf 100644 --- a/static/bitcoin-dev/July_2025/combined_A-Taproot-native-re-bindable-transaction-bundle-proposal.xml +++ b/static/bitcoin-dev/July_2025/combined_A-Taproot-native-re-bindable-transaction-bundle-proposal.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - A Taproot-native (re-)bindable transaction bundle proposal - 2025-08-01T03:24:41.955587+00:00 - - Garlo Nicon 2025-07-31 07:35:00+00:00 - - - Greg Maxwell 2025-07-30 19:44:00+00:00 - - - Antoine Poinsot 2025-07-30 17:35:00+00:00 - - - Sjors Provoost 2025-07-30 15:40:00+00:00 - - - Peter Todd 2025-07-17 09:05:00+00:00 - - - Peter Todd 2025-07-17 09:00:00+00:00 - - - Antoine Poinsot 2025-07-14 14:23:00+00:00 - - - Antoine Poinsot 2025-07-14 13:58:00+00:00 - - - /dev /fd 2025-07-12 03:44:00+00:00 - - - Murch 2025-07-12 00:27:00+00:00 - - - James OBeirne 2025-07-11 22:59:00+00:00 - - - Antoine Poinsot 2025-07-11 18:37:00+00:00 - - - James OBeirne 2025-07-10 12:24:00+00:00 - - - Brandon Black 2025-07-10 04:44:00+00:00 - - - Ademan 2025-07-09 20:14:00+00:00 - - - Rijndael 2025-07-09 20:05:00+00:00 - - - Rijndael 2025-07-09 19:59:00+00:00 - - - Greg Sanders 2025-07-09 18:19:00+00:00 - + 2025-09-26T14:25:29.716112+00:00 + python-feedgen + + + A Taproot-native (re-)bindable transaction bundle proposal Greg Sanders + 2025-07-09T18:19:00.000Z + + + Rijndael + 2025-07-09T19:59:00.000Z + + + Rijndael + 2025-07-09T20:05:00.000Z + + + Ademan + 2025-07-09T20:14:00.000Z + + + Brandon Black + 2025-07-10T04:44:00.000Z + + + James O'Beirne + 2025-07-10T12:24:00.000Z + + + Antoine Poinsot' + 2025-07-11T18:37:00.000Z + + + James O'Beirne + 2025-07-11T22:59:00.000Z + + + Murch + 2025-07-12T00:27:00.000Z + + + /dev /fd0 + 2025-07-12T03:44:00.000Z + + + Antoine Poinsot' + 2025-07-14T13:58:00.000Z + + + Antoine Poinsot' + 2025-07-14T14:23:00.000Z + + + Peter Todd + 2025-07-17T09:00:00.000Z + + + Peter Todd + 2025-07-17T09:05:00.000Z + + + Sjors Provoost + 2025-07-30T15:40:00.000Z + + + Antoine Poinsot' + 2025-07-30T17:35:00.000Z + + + Greg Maxwell + 2025-07-30T19:44:00.000Z + + + Garlo Nicon + 2025-07-31T07:35:00.000Z + + @@ -75,21 +96,17 @@ - python-feedgen + 2 Combined summary - A Taproot-native (re-)bindable transaction bundle proposal - 2025-08-01T03:24:41.955709+00:00 + 2025-09-26T14:25:29.718013+00:00 + 2025-07-31T07:35:00+00:00 The conversation within the Bitcoin development community, as captured through various email exchanges, delves into the technicalities and implications of adopting new scripting features, with a particular focus on Taproot integration and the potential introduction of new opcodes like `OP_TEMPLATEHASH`. Antoine Poinsot's contributions highlight a cautious approach towards integrating new features into older versions of the Bitcoin scripting system, emphasizing consistency and security enhancements introduced by recent upgrades such as Taproot. This perspective is rooted in maintaining the evolutionary trajectory of the Bitcoin protocol towards greater privacy and security, despite the trade-offs in cost associated with newer script spends. - James O'Beirne addresses hardware manufacturers' reluctance to adopt Schnorr signatures, underscoring the significance of ensuring support for advanced cryptographic standards across the ecosystem. This hesitance hinders the broader adoption of privacy and security-enhancing features like MuSig2 and script path spending. The discourse also touches upon the challenges and delays in transitioning existing systems to newer standards like Taproot, elucidating the practical barriers to swift technological adoption within the Bitcoin network. - Further discussions bring to light the intricate balance between introducing new functionalities and maintaining compatibility with existing protocols. The debate around `OP_TEMPLATEHASH` versus `OP_CHECKTEMPLATEVERIFY` (CTV) encapsulates this dilemma, exploring the benefits and limitations of each approach in enhancing Bitcoin's scripting capabilities. The dialogue underscores the importance of forward-looking development strategies that prioritize security, efficiency, and privacy while accommodating the evolving needs of the Bitcoin community. - The technical exchanges among developers reveal a deep engagement with the nuances of Bitcoin's protocol enhancements, from the specifics of annex commitments in transactions to the broader implications of new opcode introductions. These conversations reflect a commitment to collaborative problem-solving and innovation, with an emphasis on rigorous review and consideration of the long-term impact on the Bitcoin ecosystem. The inclusion of links to GitHub repositories and Bitcoin Improvement Proposals (BIPs) offers a window into the ongoing efforts to refine and evolve the cryptocurrency's underlying technology, highlighting the dynamic interplay between theoretical proposals and practical implementation challenges. - In sum, these discussions encapsulate a multifaceted examination of the pathways for advancing Bitcoin's scripting system, grappling with the tensions between innovation and legacy support, and the overarching goal of enhancing the cryptocurrency's security, privacy, and utility for users. Through technical rigor and collaborative discourse, the community seeks to navigate the complexities of protocol development, balancing the pursuit of new capabilities with the imperative of maintaining a secure and resilient network. - 2025-07-31T07:35:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml b/static/bitcoin-dev/July_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml index b787d0798f..8a82281d85 100644 --- a/static/bitcoin-dev/July_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml +++ b/static/bitcoin-dev/July_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml @@ -1,95 +1,23 @@ - + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747215+00:00 - - conduition 2025-08-09 19:53:00+00:00 - - - conduition 2025-07-15 13:53:00+00:00 - - - Jameson Lopp 2025-07-13 21:26:00+00:00 - - - Pieter Wuille 2025-07-13 19:28:00+00:00 - - - Boris Nagaev 2025-07-13 17:51:00+00:00 - - - Ethan Heilman 2025-07-13 16:01:00+00:00 - - - Or Sattath 2025-07-13 15:38:00+00:00 - - - Boris Nagaev 2025-07-13 14:20:00+00:00 - - - Jameson Lopp 2025-07-13 12:34:00+00:00 - - - Boris Nagaev 2025-07-13 01:39:00+00:00 - - - Jameson Lopp 2025-06-08 14:04:00+00:00 - - - waxwing/ AdamISZ 2025-06-07 13:28:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 21:15:00+00:00 - - - Sjors Provoost 2025-05-28 07:46:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 01:07:00+00:00 - - - ArmchairCryptologist 2025-05-26 15:40:00+00:00 - - - Agustin Cruz 2025-05-26 00:32:00+00:00 - - - Dustin Ray 2025-05-25 23:03:00+00:00 - - - conduition 2025-05-25 19:03:00+00:00 - - - Agustin Cruz 2025-03-24 11:19:00+00:00 - - - AstroTown 2025-03-22 19:02:00+00:00 - - - Sjors Provoost 2025-03-18 12:48:00+00:00 - - - Jameson Lopp 2025-03-17 13:28:00+00:00 - - - Matt Corallo 2025-03-17 12:00:00+00:00 - - - IdeA 2025-03-16 22:56:00+00:00 - - - Jameson Lopp 2025-03-16 21:25:00+00:00 - - - Jameson Lopp 2025-03-16 19:44:00+00:00 - - - Jameson Lopp 2025-03-16 18:03:00+00:00 - - - Jameson Lopp 2025-03-16 14:15:00+00:00 - + 2025-09-26T14:25:44.815299+00:00 + python-feedgen + + + Or Sattath + 2025-07-13T15:38:00.000Z + + + conduition' + 2025-07-15T13:53:00.000Z + + + conduition' + 2025-08-09T19:53:00.000Z + + @@ -119,21 +47,17 @@ - python-feedgen + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747403+00:00 + 2025-09-26T14:25:44.815840+00:00 + 2025-08-09T19:53:00+00:00 The discourse delves into the intricate challenges and potential approaches for integrating post-quantum cryptography within Bitcoin's framework, highlighting a proactive stance towards enhancing security against quantum computing threats. A notable proposal involves incorporating a form of post-quantum cryptography, specifically through an OP_HASHBASEDSIG mechanism, potentially utilizing SPHINCS+, to embed quantum-resistant public keys into wallet outputs. This suggestion underscores the urgency of preparing for quantum advancements well in advance, advocating for the embedding of these public keys at least a decade prior to any enforcement action to ensure ample safety margins. - The dialogue further explores the ethical and practical considerations surrounding the handling of Bitcoin funds that may become vulnerable to quantum decryption. The debate oscillates between two primary courses of action: leaving such funds accessible, thereby susceptible to potential quantum theft, or proactively rendering them unspendable to preemptively secure them against quantum capabilities. This discussion touches upon core Bitcoin principles including censorship resistance, forward compatibility, and conservatism. The ethical implications are profound, weighing the prevention of economic disruption against the fairness and property rights implications of either allowing or preventing quantum-enabled theft. - Historical precedents within the Bitcoin protocol's evolution serve as reference points for this debate, suggesting a tendency towards remedying vulnerabilities rather than exploiting them. The conversation acknowledges the complexity of incentivizing the ecosystem-wide adoption of quantum-resistant technologies through measures possibly as radical as burning vulnerable coins. - Furthermore, the exchange considers the broader implications of quantum recovery and the potential redistribution of wealth from those without access to quantum technology to those who might achieve quantum supremacy. This raises significant questions about the balance between ensuring long-term security and adhering to Bitcoin's foundational principles of decentralization and user sovereignty. - In addressing the potential quantum threat, the dialogue encapsulates a meticulous examination of both the technical feasibility of implementing quantum-resistant cryptographic methods and the philosophical underpinnings guiding these decisions. It reflects an ongoing effort among developers and stakeholders to navigate the evolving landscape of digital currency security thoughtfully, emphasizing the need for community consensus and careful consideration of Bitcoin's core values in the face of emerging technological challenges. - 2025-08-09T19:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml b/static/bitcoin-dev/July_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml index 9592354c5c..574d5b4311 100644 --- a/static/bitcoin-dev/July_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml +++ b/static/bitcoin-dev/July_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures - 2025-07-18T03:07:52.835406+00:00 - - Jonas Nick 2025-07-17 13:15:00+00:00 - - - waxwing/ AdamISZ 2025-07-03 14:07:00+00:00 - - - Tim Ruffing 2025-07-02 11:36:00+00:00 - - - waxwing/ AdamISZ 2025-06-16 19:35:00+00:00 - - - waxwing/ AdamISZ 2025-04-30 15:54:00+00:00 - - - Jonas Nick 2025-04-30 07:59:00+00:00 - - - waxwing/ AdamISZ 2025-04-26 17:05:00+00:00 - - - waxwing/ AdamISZ 2025-04-26 15:30:00+00:00 - - - Jonas Nick 2025-04-25 16:41:00+00:00 - - - waxwing/ AdamISZ 2025-04-25 16:08:00+00:00 - - - Jonas Nick 2025-04-22 15:29:00+00:00 - - - waxwing/ AdamISZ 2025-04-19 16:28:00+00:00 - - - Jonas Nick 2025-04-17 16:27:00+00:00 - + 2025-09-26T14:25:42.630612+00:00 + python-feedgen + + + DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures Jonas Nick + 2025-04-17T16:27:00.000Z + + + waxwing/ AdamISZ + 2025-04-19T16:28:00.000Z + + + Jonas Nick + 2025-04-22T15:29:00.000Z + + + waxwing/ AdamISZ + 2025-04-25T16:08:00.000Z + + + Jonas Nick + 2025-04-25T16:41:00.000Z + + + waxwing/ AdamISZ + 2025-04-26T15:30:00.000Z + + + waxwing/ AdamISZ + 2025-04-26T17:05:00.000Z + + + Jonas Nick + 2025-04-30T07:59:00.000Z + + + waxwing/ AdamISZ + 2025-04-30T15:54:00.000Z + + + waxwing/ AdamISZ + 2025-06-16T19:35:00.000Z + + + Tim Ruffing + 2025-07-02T11:36:00.000Z + + + waxwing/ AdamISZ + 2025-07-03T14:07:00.000Z + + + Jonas Nick + 2025-07-17T13:15:00.000Z + + @@ -55,21 +71,17 @@ - python-feedgen + 2 Combined summary - DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures - 2025-07-18T03:07:52.835505+00:00 + 2025-09-26T14:25:42.632080+00:00 + 2025-07-17T13:15:00+00:00 The conversation between AdamISZ/waxwing and Tim delves into the intricacies of cryptographic signing protocols, focusing on their application in Bitcoin but acknowledging broader uses beyond blockchain technology. They discuss the efficiency of a signing protocol that reduces the computational demand by changing from constant time operations to ones that scale with the number of participants, considering trade-offs between signing and verification performance. The dialogue touches on the importance of designing systems that manage scaling effectively, especially for devices with limited computational resources. The exchange also explores the potential benefits of algebraic algorithms in cryptographic processes, highlighting their ease of integration into circuits for zero-knowledge proofs and their operational efficiencies due to fewer conditional branches or loops. - Further analysis on cryptographic protocols examines the security implications and operational efficiencies of using distinct ephemeral identifiers across participants. The discussion contrasts the computational inefficiencies introduced by this approach against the streamlined process achieved by employing a singular identifier, emphasizing the latter's advantages in reducing computation time without sacrificing security. This choice is framed within the context of enhancing transaction efficiency on the blockchain without introducing significant increases in signature size or verification costs. Additionally, the discourse addresses concerns related to ensuring the integrity of the signing process, particularly in identifying and mitigating disruptive behavior among participants, underscoring the necessity of honest coordinators and secure communication channels. - -A detailed exploration into cryptographic verification mechanisms reveals an innovative perspective on nonce reuse and its security ramifications, particularly comparing MuSig2 and DahLIAS protocols. The discussions shed light on DahLIAS's flexibility in verification processes, allowing for multiple public keys and messages as inputs, which diverges from MuSig2's rigid structure. This adaptability not only expands DahLIAS’s applicability but also introduces a nuanced layer of security by preventing attackers from exploiting nonce reuse through variable "b" values for each participant. This aspect underscores the ongoing efforts to refine cryptographic protocols, ensuring robust security against sophisticated attack vectors. - +A detailed exploration into cryptographic verification mechanisms reveals an innovative perspective on nonce reuse and its security ramifications, particularly comparing MuSig2 and DahLIAS protocols. The discussions shed light on DahLIAS's flexibility in verification processes, allowing for multiple public keys and messages as inputs, which diverges from MuSig2's rigid structure. This adaptability not only expands DahLIAS’s applicability but also introduces a nuanced layer of security by preventing attackers from exploiting nonce reuse through variable "b" values for each participant. This aspect underscores the ongoing efforts to refine cryptographic protocols, ensuring robust security against sophisticated attack vectors. The email exchanges delve into the theoretical underpinnings and practical considerations of cryptographic optimizations, emphasizing the significance of not compromising on security while seeking operational efficiencies. The discourse covers the security theorem for DahLIAS, highlighting its robustness against attacks unless specific cryptographic assumptions are violated. Additionally, the conversations pivot towards practical optimizations for single-party signers and the inclusion of such methodologies in academic papers versus Bitcoin Improvement Proposals (BIPs), arguing for a broader applicational relevance that warrants academic scrutiny. - Lastly, the discussions encapsulate a comprehensive overview of the CISA algorithm and its potential to streamline blockchain transactions by optimizing signature processes. This includes a nuanced analysis of nonce handling and the security considerations associated with aggregate signatures, particularly focusing on the compatibility with key tweaking and the implications for operational efficiency and security. The dialogue also extends to client-side validation concepts, proposing strategies to mitigate risks and enhance the security framework for digital signatures within the blockchain domain. - 2025-07-17T13:15:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_Human-meaningful-witness-versioning.xml b/static/bitcoin-dev/July_2025/combined_Human-meaningful-witness-versioning.xml index 80dac0cdcf..f31597c8b6 100644 --- a/static/bitcoin-dev/July_2025/combined_Human-meaningful-witness-versioning.xml +++ b/static/bitcoin-dev/July_2025/combined_Human-meaningful-witness-versioning.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Human meaningful witness versioning - 2025-07-22T03:08:37.240203+00:00 - - Ethan Heilman 2025-07-21 17:01:00+00:00 - - - Ava Chow 2025-07-21 02:24:00+00:00 - - - Ethan Heilman 2025-07-21 01:44:00+00:00 - - - Greg Maxwell 2025-07-20 22:38:00+00:00 - - - Ethan Heilman 2025-07-20 21:29:00+00:00 - - - conduition 2025-07-20 15:19:00+00:00 - - - Ava Chow 2025-07-18 22:46:00+00:00 - - - Greg Maxwell 2025-07-18 22:18:00+00:00 - - - Ethan Heilman 2025-07-18 21:58:00+00:00 - + 2025-09-26T14:25:25.453195+00:00 + python-feedgen + + + Human meaningful witness versioning Ethan Heilman + 2025-07-18T21:58:00.000Z + + + Greg Maxwell + 2025-07-18T22:18:00.000Z + + + Ava Chow' + 2025-07-18T22:46:00.000Z + + + conduition' + 2025-07-20T15:19:00.000Z + + + Ethan Heilman + 2025-07-20T21:29:00.000Z + + + Greg Maxwell + 2025-07-20T22:38:00.000Z + + + Ethan Heilman + 2025-07-21T01:44:00.000Z + + + Ava Chow' + 2025-07-21T02:24:00.000Z + + + Ethan Heilman + 2025-07-21T17:01:00.000Z + + @@ -39,21 +51,17 @@ - python-feedgen + 2 Combined summary - Human meaningful witness versioning - 2025-07-22T03:08:37.240294+00:00 + 2025-09-26T14:25:25.454442+00:00 + 2025-07-21T17:01:00+00:00 The recent discussions on the Bitcoin Development Mailing List have brought forward several critical considerations regarding the design and evolution of Bitcoin's addressing system, particularly focusing on witness versions and the encoding methods used in cryptocurrency addresses. The conversation initiated by Ava Chow highlighted an oversight in the reading of BIP 173, specifically concerning the bech32 encoding scheme and its impact on the decision-making process for BIP-360. It was clarified that bech32 encoding does not include the OP_PUSH32 operation, leading to a revision in the approach towards witness versioning for BIP-360, now favoring Witness Version 2 over the initially considered Witness Version 3. This adjustment underscores the dynamic nature of development within the Bitcoin community, where open discussions lead to informed decision-making processes. - -An underlying theme in these discussions is the emphasis on enhancing user safety and comprehension through thoughtful address format design. The dialogue revisits past decisions, such as the adoption of a 5-bit encoding system to minimize address length inflation while accommodating future versioning needs. The "bc" prefix in Bitcoin addresses serves as a preventive measure against confusion with fork coins or altcoins, illustrating a proactive stance towards minimizing user errors and fund loss due to misdirected transactions. Such design considerations reflect a commitment to balancing technical innovation with practical usability, ensuring that both senders and recipients navigate the intricacies of Bitcoin transactions with clarity and confidence. - +An underlying theme in these discussions is the emphasis on enhancing user safety and comprehension through thoughtful address format design. The dialogue revisits past decisions, such as the adoption of a 5-bit encoding system to minimize address length inflation while accommodating future versioning needs. The "bc" prefix in Bitcoin addresses serves as a preventive measure against confusion with fork coins or altcoins, illustrating a proactive stance towards minimizing user errors and fund loss due to misdirected transactions. Such design considerations reflect a commitment to balancing technical innovation with practical usability, ensuring that both senders and recipients navigate the intricacies of Bitcoin transactions with clarity and confidence. Further discourse among contributors explores the implications of quantum computing on address types and the necessity for forward-thinking strategies in naming conventions and cryptographic practices. The introduction of potential new output types like P2QRH, P2TSH, and P2TTH, alongside the development of post-quantum signature verification opcodes, exemplifies the community's proactive approach to addressing future technological challenges. This discussion extends into the realms of soft fork deployment flexibility, witness program functionality, and the overarching goal of maintaining a secure, resilient, and user-friendly cryptocurrency system. - -Moreover, the conversations critique the current visibility and understanding of Bitcoin addresses among users, challenging misconceptions about transaction types and witness versions. There's a call for a reevaluation of how addresses convey information, advocating for a system that promotes maximum compression and versatility without sacrificing user comprehension. The proposal for a mnemonic-based allocation of Witness Versions, aiming to make output types more identifiable and understandable, represents a novel approach to enhancing user safety and knowledge in the cryptocurrency landscape. This initiative seeks to build upon existing measures like the "bc" and "tc" prefixes for mainnet and testnet addresses, furthering efforts to create a more accessible and secure Bitcoin ecosystem. - +Moreover, the conversations critique the current visibility and understanding of Bitcoin addresses among users, challenging misconceptions about transaction types and witness versions. There's a call for a reevaluation of how addresses convey information, advocating for a system that promotes maximum compression and versatility without sacrificing user comprehension. The proposal for a mnemonic-based allocation of Witness Versions, aiming to make output types more identifiable and understandable, represents a novel approach to enhancing user safety and knowledge in the cryptocurrency landscape. This initiative seeks to build upon existing measures like the "bc" and "tc" prefixes for mainnet and testnet addresses, furthering efforts to create a more accessible and secure Bitcoin ecosystem. In summary, these exchanges on the Bitcoin Development Mailing List encapsulate a collective endeavor to refine Bitcoin's addressing scheme through rigorous debate, innovative proposals, and a shared commitment to user-centric development. The discussions highlight the importance of historical context, the anticipation of future technological shifts, and the prioritization of security and clarity in the ongoing evolution of Bitcoin's technical framework. - 2025-07-21T17:01:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_Make-pathological-transactions-with-more-than-2500-legacy-signature-operations-non-standard.xml b/static/bitcoin-dev/July_2025/combined_Make-pathological-transactions-with-more-than-2500-legacy-signature-operations-non-standard.xml index 427a7cebdd..e5613c4cd3 100644 --- a/static/bitcoin-dev/July_2025/combined_Make-pathological-transactions-with-more-than-2500-legacy-signature-operations-non-standard.xml +++ b/static/bitcoin-dev/July_2025/combined_Make-pathological-transactions-with-more-than-2500-legacy-signature-operations-non-standard.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Make pathological transactions with more than 2500 legacy signature operations non-standard - 2025-07-30T03:14:32.252289+00:00 - - Antoine Riard 2025-07-27 21:40:00+00:00 - - - Antoine Poinsot 2025-07-23 21:12:00+00:00 - - - Antoine Riard 2025-07-23 17:56:00+00:00 - - - Antoine Poinsot 2025-07-14 14:44:00+00:00 - - - Antoine Riard 2025-07-12 04:12:00+00:00 - - - Antoine Poinsot 2025-07-07 21:46:00+00:00 - - - Antoine Riard 2025-07-03 18:18:00+00:00 - - - Antoine Poinsot 2025-07-02 08:47:00+00:00 - + 2025-09-26T14:25:55.460269+00:00 + python-feedgen + + + Make pathological transactions with more than 2500 legacy signature operations non-standard 'Antoine Poinsot' + 2025-07-02T08:47:00.000Z + + + Antoine Riard + 2025-07-03T18:18:00.000Z + + + Antoine Poinsot' + 2025-07-07T21:46:00.000Z + + + Antoine Riard + 2025-07-12T04:12:00.000Z + + + Antoine Poinsot' + 2025-07-14T14:44:00.000Z + + + Antoine Riard + 2025-07-23T17:56:00.000Z + + + Antoine Poinsot' + 2025-07-23T21:12:00.000Z + + + Antoine Riard + 2025-07-27T21:40:00.000Z + + @@ -35,21 +46,17 @@ - python-feedgen + 2 Combined summary - Make pathological transactions with more than 2500 legacy signature operations non-standard - 2025-07-30T03:14:32.252380+00:00 + 2025-09-26T14:25:55.461307+00:00 + 2025-07-27T21:40:00+00:00 The discourse elucidates several pivotal aspects and concerns within the Bitcoin development community regarding multiparty transaction protocols, specifically highlighting the delicate balance between security measures and the inherent trust challenges among participants. Antoine's explanations shed light on the nuanced considerations that underpin the design and implementation of cryptocurrency systems, emphasizing the distinction between contributing non-standard inputs in a multi-party flow and outright attacks like DoS. This distinction is crucial for understanding the collaborative dynamics and the technical constraints faced by developers in ensuring network robustness against potential abuses. - Further examination delves into the intricacies of transaction validation processes and the implications of Bitcoin Improvement Proposals (BIPs) on these procedures. The discussion ventures into the challenges posed by transactions that might inadvertently violate policy rules, particularly in the context of Coinjoin transactions among multiple participants. Such scenarios underscore the complexities of enforcing compliance with evolving network policies while also contending with the potential for DoS attacks leveraging policy constraints. The emphasis on the need for downstream software developers to adapt to policy changes highlights a broader challenge in maintaining network security and functionality amidst continuous protocol evolution. - Antoine's communication also encompasses a detailed analysis regarding the implementation concerns of BIP54, focusing on its approach to signature operations (sigops) within transactions. By elucidating the distinctions between legacy and Segwit transactions in relation to sigop limits, Antoine clarifies the practical impact of BIP54 on transaction creation and validation. The inclusion of references, such as the BIP54 documentation on GitHub, serves to encourage a deeper engagement with the proposal's technicalities, indicating the importance of understanding the specifics of such proposals for effective implementation. - Discussions extend to the technical strategies employed in transaction scripting, particularly highlighting methods to circumvent transaction ID malleability risks through the use of Segwit inputs. This aspect of the conversation underscores the critical importance of Segwit in enhancing off-chain transaction security, illustrating the ongoing efforts within the community to address vulnerabilities and improve the Bitcoin protocol's resilience. - Finally, the dialogue touches upon broader implications of consensus rule changes, such as those proposed under BIP54, on the scalability and flexibility of off-chain solutions. The consideration of new limits on signature operations and their potential impact on large-scale off-chain payment pools exemplifies the intricate balance between security enhancements and the preservation of network capacity for innovation. The possibility of future innovations bypassing current limitations through new opcodes or script versions indicates an awareness of the need for adaptable solutions that do not compromise the network's integrity or scalability. Through this comprehensive discussion, the community's commitment to careful consideration of consensus rule changes, balancing immediate technical needs with the long-term vision for Bitcoin's evolution, is evident. - 2025-07-27T21:40:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_New-BIP-Editors-1-Year-Later.xml b/static/bitcoin-dev/July_2025/combined_New-BIP-Editors-1-Year-Later.xml index 6e66f4aea1..a29d037bd0 100644 --- a/static/bitcoin-dev/July_2025/combined_New-BIP-Editors-1-Year-Later.xml +++ b/static/bitcoin-dev/July_2025/combined_New-BIP-Editors-1-Year-Later.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - New BIP Editors: 1 Year Later - 2025-08-13T02:59:28.232471+00:00 - - Anthony Towns 2025-08-12 05:33:00+00:00 - - - Jon Atack 2025-07-21 21:52:00+00:00 - - - Ava Chow 2025-07-15 01:01:00+00:00 - + 2025-09-26T14:25:53.312117+00:00 + python-feedgen + + + New BIP Editors: 1 Year Later 'Ava Chow' + 2025-07-15T01:01:00.000Z + + + Jon Atack + 2025-07-21T21:52:00.000Z + + + Anthony Towns + 2025-08-12T05:33:00.000Z + + - python-feedgen + 2 Combined summary - New BIP Editors: 1 Year Later - 2025-08-13T02:59:28.232516+00:00 + 2025-09-26T14:25:53.312652+00:00 + 2025-08-12T05:33:00+00:00 The recent period has seen a significant shift in the dynamics and efficiency of the Bitcoin Improvement Proposal (BIP) process, primarily attributed to the introduction of new BIP Editors. These changes have been a catalyst for enhanced productivity and collaboration within the community, as evidenced by the uptick in various metrics such as comments left, Pull Requests (PRs) merged, PRs closed, and BIP numbers assigned. The statistics starkly illustrate the impact of these new editors on the BIP process, showcasing an impressive increase in activity and engagement compared to the period before their integration. This surge not only underscores the rejuvenation of the BIP process but also the critical role that active and committed editors play in sustaining and advancing this initiative. - Despite these positive developments, the distribution of workload among the editors appears uneven, with a few individuals shouldering the majority of the tasks. This situation highlights a potential imbalance in commitment levels among the current BIP Editors, raising questions about the overall effectiveness and sustainability of the team's composition. Such observations suggest that there may be merit in reevaluating the roles and contributions of the editors, considering adjustments that could promote a more equitable distribution of responsibilities. This reevaluation could involve exploring mechanisms for rotating editors or introducing term limits to ensure that the editorial team remains dynamic, engaged, and effectively serves the community's needs. - Jon Atack and Murch have emerged as notably active contributors, significantly influencing daily operations and collaborative efforts within the BIP process. Their involvement has led to improved coordination and prevented the complexities that can arise from having an excessive number of individuals directly involved. Additionally, the support and expertise of other editors, albeit less visible, have been instrumental in facilitating discussions on BIP issues and ensuring responsiveness. This balance between active day-to-day involvement by some editors and the as-needed consultation with others has created an effective and streamlined approach to managing the BIP repository. It represents a model of collaboration that is both efficient and scalable, catering to the evolving needs of the Bitcoin development community. - 2025-08-12T05:33:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_OP-CAT-Enables-Winternitz-Signatures.xml b/static/bitcoin-dev/July_2025/combined_OP-CAT-Enables-Winternitz-Signatures.xml index 5a19fe291d..8eb0118b4c 100644 --- a/static/bitcoin-dev/July_2025/combined_OP-CAT-Enables-Winternitz-Signatures.xml +++ b/static/bitcoin-dev/July_2025/combined_OP-CAT-Enables-Winternitz-Signatures.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - OP_CAT Enables Winternitz Signatures - 2025-07-10T02:59:31.290814+00:00 - - Jonas Nick 2025-07-08 08:07:00+00:00 - - - conduition 2025-07-08 07:03:00+00:00 - - - conduition 2025-07-08 00:49:00+00:00 - - - conduition 2025-07-08 00:16:00+00:00 - - - Jonas Nick 2025-07-07 10:40:00+00:00 - - - Anthony Towns 2025-07-05 12:18:00+00:00 - - - conduition 2025-06-09 15:31:00+00:00 - - - conduition 2025-06-08 03:20:00+00:00 - + 2025-09-26T14:25:33.978463+00:00 + python-feedgen + + + OP_CAT Enables Winternitz Signatures 'conduition' + 2025-06-08T03:20:00.000Z + + + conduition' + 2025-06-09T15:31:00.000Z + + + Anthony Towns + 2025-07-05T12:18:00.000Z + + + Jonas Nick + 2025-07-07T10:40:00.000Z + + + conduition' + 2025-07-08T00:16:00.000Z + + + conduition' + 2025-07-08T00:49:00.000Z + + + conduition' + 2025-07-08T07:03:00.000Z + + + Jonas Nick + 2025-07-08T08:07:00.000Z + + @@ -35,21 +46,17 @@ - python-feedgen + 2 Combined summary - OP_CAT Enables Winternitz Signatures - 2025-07-10T02:59:31.290881+00:00 + 2025-09-26T14:25:33.979456+00:00 + 2025-07-08T08:07:00+00:00 The discussion within the Bitcoin Development Mailing List focuses on enhancing the efficiency and security of digital transaction signatures, particularly through the implementation and optimization of cryptographic signature schemes. The conversation begins with an analysis of the fixed-sum Winternitz one-time signature scheme (WOTS), emphasizing the selection of specific parameters to ensure the integrity of digital transactions. The optimal checksum calculation for efficient signing, avoiding the use of random salt counters, and considerations for employing less collision-resistant hashing algorithms for efficiency gains are central themes. The dialogue also explores the feasibility of using a combination of RMD160 and SHA256 hashing functions to reduce witness size in transactions while maintaining adequate collision resistance. - Further technical exchanges propose improvements in Bitcoin script efficiency through strategic use of OP codes, leading to significant reductions in script sizes. A transformative suggestion involves substituting certain operations with OP_LSHIFT, achieving a reduction in byte usage and overall script and witness size. This optimization, detailed in a shared [gist](https://gist.github.com/conduition/c6fd78e90c21f669fad7e3b5fe113182file-winternitz-ts-L100-L137), highlights the collaborative and innovative efforts within the community to refine Bitcoin scripting capabilities. - The conversation extends to methods for reducing signature sizes and improving verification costs, juxtaposing different constructions and their implications for blockchain applications. A focus on preimage resistance over collision resistance, informed by quantum computing considerations, underpins discussions about the potential of various Winternitz variants. The standardization of W-OTS+ as part of XMSS and its secure variants is mentioned as a critical point of reference. - Technical suggestions for optimizing conversion processes from four-bit pair to eight-bit format are introduced, alongside a brief mention of operational issues affecting transaction processing due to server downtime. This encapsulates a broader discussion on the necessity for smaller, quantum-resistant signature schemes to maintain network efficiency without increasing block size. Lattice-based cryptography emerges as a promising avenue for quantum resistance, with current hash-based alternatives considered temporary solutions pending the discovery of more efficient signature schemes. - Jeremy Rubin's work on enabling Lamport signatures through OP_CAT, leading to discussions around Winternitz One Time Signatures (WOTS) as a more compact alternative, signifies an ongoing exploration of post-quantum cryptographic solutions. The development and testing of prototype implementations, along with suggestions for further optimization, reflect the community's proactive approach to addressing the challenges posed by quantum computing. The sharing of resources and collaborative problem-solving efforts underscore the commitment to advancing cryptographic techniques within the Bitcoin development ecosystem. - 2025-07-08T08:07:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_Proposal-Self-Verifiable-Transaction-Broadcast-Log-for-Enhanced-User-Transparency.xml b/static/bitcoin-dev/July_2025/combined_Proposal-Self-Verifiable-Transaction-Broadcast-Log-for-Enhanced-User-Transparency.xml index bb995ef9bd..be4b4ad97c 100644 --- a/static/bitcoin-dev/July_2025/combined_Proposal-Self-Verifiable-Transaction-Broadcast-Log-for-Enhanced-User-Transparency.xml +++ b/static/bitcoin-dev/July_2025/combined_Proposal-Self-Verifiable-Transaction-Broadcast-Log-for-Enhanced-User-Transparency.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency - 2025-07-30T03:13:45.493672+00:00 - - Murch 2025-07-29 22:55:00+00:00 - - - wang wang 2025-06-16 09:57:00+00:00 - + 2025-09-26T14:25:57.574946+00:00 + python-feedgen + + + Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency wang wang + 2025-06-16T09:57:00.000Z + + + Murch + 2025-07-29T22:55:00.000Z + + - python-feedgen + 2 Combined summary - Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency - 2025-07-30T03:13:45.493719+00:00 + 2025-09-26T14:25:57.575400+00:00 + 2025-07-29T22:55:00+00:00 The email from Liang to the Bitcoin developers outlines a detailed proposal for enhancing user experience and auditability within Bitcoin node software, specifically addressing concerns related to transactions that have been orphaned or dropped. Liang proposes the introduction of a *Self-Verifiable Transaction Broadcast Log*, which aims to serve as an opt-in feature allowing nodes to record all accepted transactions for broadcast, inclusive of timestamps and source details. This proposed feature is designed to assist users and wallets in verifying transactions that may have been dropped, reorganized, or failed to confirm, without impacting consensus behavior. The log, according to Liang, would be equipped with filtering capabilities and accessible through a new RPC call (`getbroadcastedtxs`), enabling users to manage it according to their needs. - Liang's motivation for this proposal is rooted in personal experience, highlighting a situation where a valid transaction could not be located within the mempool, blockchain, or via block explorers, despite having access to the private key involved. This incident raises concerns over potential censorship or selective orphaning by influential entities, which could occur without leaving any verifiable traces for users. By introducing this logging feature, the proposal seeks to bolster transparency and auditability, particularly benefiting users concerned with privacy or those utilizing air-gapped setups who lack comprehensive mempool logs. - In soliciting feedback from the Bitcoin development community, Liang presents several considerations associated with the proposal. These include evaluating the feature's value in enhancing user transparency, addressing potential wallet behavior and privacy issues, determining whether the logs should be stored in-memory or on disk by default, and assessing the benefit of integrating this feature into wallet software for easier user access. Initially drafted as a Bitcoin Improvement Proposal (BIP), Liang invites preliminary feedback before proceeding with a formal PR or implementation patch, indicating readiness to contribute a reference implementation compatible with Bitcoin Core version 25 and above. For further discussion, Liang suggests engaging on platforms like [Bitcoin StackExchange](https://bitcoin.stackexchange.com), recognizing that the topic may extend beyond the scope of the initial mailing list discussion. - 2025-07-29T22:55:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_Proposal-for-Decentralized-Satellite-Based-Bitcoin-Nodes.xml b/static/bitcoin-dev/July_2025/combined_Proposal-for-Decentralized-Satellite-Based-Bitcoin-Nodes.xml index 5e5633ed46..74d5eaea99 100644 --- a/static/bitcoin-dev/July_2025/combined_Proposal-for-Decentralized-Satellite-Based-Bitcoin-Nodes.xml +++ b/static/bitcoin-dev/July_2025/combined_Proposal-for-Decentralized-Satellite-Based-Bitcoin-Nodes.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - Proposal for Decentralized Satellite-Based Bitcoin Nodes - 2025-07-08T02:59:05.915908+00:00 - - Antoine Riard 2025-07-07 01:26:00+00:00 - - - BitMan 2025-07-06 15:01:00+00:00 - + 2025-09-26T14:25:59.684881+00:00 + python-feedgen + + + Proposal for Decentralized Satellite-Based Bitcoin Nodes 'BitMan' + 2025-07-06T15:01:00.000Z + + + Antoine Riard + 2025-07-07T01:26:00.000Z + + - python-feedgen + 2 Combined summary - Proposal for Decentralized Satellite-Based Bitcoin Nodes - 2025-07-08T02:59:05.915947+00:00 + 2025-09-26T14:25:59.685327+00:00 + 2025-07-07T01:26:00+00:00 The email highlights a discussion initiated by jgarzik on the Bitcoin Development Mailing List, which can be explored further at [https://bitcointalk.org/index.php?topic=334701.0](https://bitcointalk.org/index.php?topic=334701.0). It delves into the intricacies of disseminating the Bitcoin blockchain via the Blockstream Satellite system. While this technology facilitates the global broadcast of the Bitcoin blockchain, it restricts users from broadcasting transactions or updating the blockchain themselves. This limitation has raised concerns about potential centralization and the dependency on a singular company's infrastructure for the blockchain's dissemination. - A 16-year-old Bitcoin enthusiast contributes an innovative proposal to the conversation, drawing inspiration from Elon Musk's Starlink project. The proposed idea is to develop a fully open-source, community-driven satellite communication system. This ambitious system would not only allow the reception of data but also enable the broadcasting of transactions and the synchronization of blocks directly with space-based full nodes. Such a development aims to make Bitcoin more independent from centralized internet service providers (ISPs) and infrastructures, thus enhancing its decentralization. - The young sender acknowledges the financial and technical hurdles associated with creating a satellite communication system that is both open-source and community-driven. Yet, they remain optimistic, suggesting that crowdfunding or support from decentralization enthusiasts could turn this vision into reality. The ultimate goal of this proposal is to enable Bitcoin's operation in an almost entirely off-grid manner, utilizing minimal energy—possibly sourced from small solar panels—and a satellite dish. This setup would empower users to send and receive data or execute transactions independently of centralized networks, thereby reinforcing Bitcoin's core principles of resilience, censorship resistance, and global accessibility. The email encapsulates a fervent desire within the Bitcoin community for innovations that further promote freedom and decentralization. - 2025-07-07T01:26:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_Revisiting-secp256r1-signatures-i-e-P256-mobile-HSM-support-.xml b/static/bitcoin-dev/July_2025/combined_Revisiting-secp256r1-signatures-i-e-P256-mobile-HSM-support-.xml index 510c7b5dc6..c6787acc0d 100644 --- a/static/bitcoin-dev/July_2025/combined_Revisiting-secp256r1-signatures-i-e-P256-mobile-HSM-support-.xml +++ b/static/bitcoin-dev/July_2025/combined_Revisiting-secp256r1-signatures-i-e-P256-mobile-HSM-support-.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - Revisiting secp256r1 signatures (i.e. P256, mobile HSM support) - 2025-08-27T02:43:37.558941+00:00 - - Javier Mateos 2025-08-19 11:15:00+00:00 - - - Josh Doman 2025-08-08 20:48:00+00:00 - - - conduition 2025-07-23 15:40:00+00:00 - - - Greg Tonoski 2025-07-23 08:49:00+00:00 - - - Josh Doman 2025-07-22 21:44:00+00:00 - + 2025-09-26T14:25:31.831620+00:00 + python-feedgen + + + Revisiting secp256r1 signatures (i.e. P256, mobile HSM support) Josh Doman + 2025-07-22T21:44:00.000Z + + + Greg Tonoski + 2025-07-23T08:49:00.000Z + + + conduition' + 2025-07-23T15:40:00.000Z + + + Josh Doman + 2025-08-08T20:48:00.000Z + + + Javier Mateos + 2025-08-19T11:15:00.000Z + + - python-feedgen + 2 Combined summary - Revisiting secp256r1 signatures (i.e. P256, mobile HSM support) - 2025-08-27T02:43:37.559011+00:00 + 2025-09-26T14:25:31.832376+00:00 + 2025-08-19T11:15:00+00:00 The recent discussions on the Bitcoin Development Mailing List have shed light on various aspects of integrating new cryptographic standards into the Bitcoin protocol, specifically focusing on the P256 curve's compatibility with modern internet and mobile devices. The conversation begins by acknowledging the challenges associated with this integration, including achieving community consensus and the technical hurdles of implementing a high-quality solution comparable to the current libsecp256k1 library. Despite these challenges, the dialogue underscores the potential benefits of P256 integration, such as improving the onboarding experience for new users, enhancing the security of hot wallets, and reducing costs associated with collaborative multisigs. However, concerns about the timing of such an integration are raised, considering the ongoing development of post-quantum cryptographic solutions that may shift the community's focus away from P256. - Further discussion delves into the WebAuthn standard's compatibility with Bitcoin's security needs, particularly in the context of hardware security modules (HSM) and post-quantum cryptography. The discourse suggests that researching how to adapt WebAuthn's signature formats for Bitcoin might offer a productive path toward ensuring long-term security and utility. Nonetheless, there are significant concerns regarding WebAuthn's suitability for Bitcoin, given its design for centralized web authentication and the lack of support for key features like deterministic backup seeds for user recovery and compatibility with hierarchical deterministic wallets. - In addition to exploring the technical and practical aspects of integrating P256 and WebAuthn standards into Bitcoin, the conversation also revisits historical apprehensions within the Bitcoin community regarding P256. These include fears over potential backdoors introduced by NIST, although such concerns have diminished over time. The argument for adopting P256 centers on its promise to enhance user experience and security, despite its slower validation times compared to secp256k1. The potential for P256 to enable secure access to platform APIs for HSMs on mobile devices is highlighted as a significant advantage, suggesting a compelling case for reevaluating P256 support within the Bitcoin ecosystem. - Concurrently, the discussion touches upon the apprehensions around reintroducing the OP_CAT vulnerability through the guise of secp256r1 support. This concern points to broader issues of security and the relevance of certain technical arguments to the core functionality and safety of the Bitcoin protocol. The mention of existing technologies like Samsung's Blockchain Keystore indicates that solutions for secure cryptocurrency management on mobile devices already exist, challenging the necessity and relevance of some proposed changes. - Overall, the exchange on the mailing list reflects a deep and multifaceted debate over the future of Bitcoin's cryptographic standards, balancing the need for advancement and compatibility with modern technologies against the imperatives of security, user autonomy, and the preservation of fundamental features that define the cryptocurrency. The discussion encapsulates a broad spectrum of viewpoints and considerations, from the technical specifics of cryptographic curves to the philosophical underpinnings of Bitcoin's design and use. - 2025-08-19T11:15:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_Taproot-is-post-quantum-secure-when-restricted-to-script-path-spends.xml b/static/bitcoin-dev/July_2025/combined_Taproot-is-post-quantum-secure-when-restricted-to-script-path-spends.xml index 049c068493..7bd9911e44 100644 --- a/static/bitcoin-dev/July_2025/combined_Taproot-is-post-quantum-secure-when-restricted-to-script-path-spends.xml +++ b/static/bitcoin-dev/July_2025/combined_Taproot-is-post-quantum-secure-when-restricted-to-script-path-spends.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Taproot is post-quantum secure when restricted to script-path spends - 2025-08-04T03:22:49.056880+00:00 - - Ethan Heilman 2025-08-03 17:42:00+00:00 - - - Maxim Orlovsky 2025-07-31 09:22:00+00:00 - - - Tim Ruffing 2025-07-23 11:03:00+00:00 - + 2025-09-26T14:25:27.568191+00:00 + python-feedgen + + + Taproot is post-quantum secure when restricted to script-path spends Tim Ruffing + 2025-07-23T11:03:00.000Z + + + Maxim Orlovsky + 2025-07-31T09:22:00.000Z + + + Ethan Heilman + 2025-08-03T17:42:00.000Z + + - python-feedgen + 2 Combined summary - Taproot is post-quantum secure when restricted to script-path spends - 2025-08-04T03:22:49.056955+00:00 + 2025-09-26T14:25:27.568751+00:00 + 2025-08-03T17:42:00+00:00 The discussion around the quantum security of taproot wallets, as brought up by Maxim in his communication, highlights a nuanced understanding of the vulnerabilities associated with quantum computing. It is pointed out that wallet descriptors with public keys, once exposed, could leave taproot wallets susceptible to quantum attacks despite script-spending paths that are generally considered secure. This assertion challenges the prevailing assumption of taproot's invulnerability to such futuristic threats. Furthermore, the concern extends to the potential for quantum-powered miners or nodes to alter transactions maliciously, substituting them with different ones, thus undermining the transactional integrity within the Bitcoin network. - -In contrast, a research paper from the Cryptology ePrint Archive, titled "The Post-Quantum Security of Bitcoin's Taproot as a Commitment Scheme," offers a more optimistic view on the matter. According to [the paper](https://eprint.iacr.org/2025/1307), under the quantum random oracle model (QROM) which assumes SHA256's robustness against quantum attacks, Taproot outputs cannot be manipulated by an attacker to reveal an unexpected Merkle root. This finding significantly bolsters the argument for Bitcoin's resilience against quantum threats, particularly in its scripting capabilities. The paper advocates for a two-phase softfork upgrade to incorporate post-quantum signatures into Bitcoin's scripting language, a suggestion aligned with Matt Corallo and others' proposals. The initial phase would introduce these signatures, and the second phase, anticipatory of the emergence of large-scale quantum computing, would discontinue Schnorr and ECDSA signatures for transaction verification. - +In contrast, a research paper from the Cryptology ePrint Archive, titled "The Post-Quantum Security of Bitcoin's Taproot as a Commitment Scheme," offers a more optimistic view on the matter. According to [the paper](https://eprint.iacr.org/2025/1307), under the quantum random oracle model (QROM) which assumes SHA256's robustness against quantum attacks, Taproot outputs cannot be manipulated by an attacker to reveal an unexpected Merkle root. This finding significantly bolsters the argument for Bitcoin's resilience against quantum threats, particularly in its scripting capabilities. The paper advocates for a two-phase softfork upgrade to incorporate post-quantum signatures into Bitcoin's scripting language, a suggestion aligned with Matt Corallo and others' proposals. The initial phase would introduce these signatures, and the second phase, anticipatory of the emergence of large-scale quantum computing, would discontinue Schnorr and ECDSA signatures for transaction verification. The study meticulously quantifies the challenge posed to quantum attackers, noting that a minimum of 2^81 SHA256 evaluations would be required to compromise a Taproot output with a 50% success rate. It delineates the improbability of assembling the requisite quantum computational power under current technological constraints, effectively setting a security threshold below the aspirational 2^128 level but still within a range deemed adequate against existing quantum capabilities. With this stance, the research shifts the spotlight back onto classical computing advancements as the more immediate threat to Taproot's security rather than quantum computing. The paper concludes that without significant breakthroughs in quantum algorithms, the latter does not currently pose a substantial risk to the integrity of script-path spends within the Bitcoin ecosystem. This perspective underscores the importance of ongoing vigilance against classical computational threats that could potentially undermine the secure framework established by Bitcoin's taproot mechanism before quantum computing becomes a viable concern. - 2025-08-03T17:42:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_Unbreaking-testnet4.xml b/static/bitcoin-dev/July_2025/combined_Unbreaking-testnet4.xml index 126bc0ac4c..194fb4a198 100644 --- a/static/bitcoin-dev/July_2025/combined_Unbreaking-testnet4.xml +++ b/static/bitcoin-dev/July_2025/combined_Unbreaking-testnet4.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Unbreaking testnet4 - 2025-07-06T03:04:39.614598+00:00 - - Garlo Nicon 2025-07-05 04:31:00+00:00 - - - Saint Wenhao 2025-05-17 05:11:00+00:00 - - - pithosian 2025-05-12 20:19:00+00:00 - - - Saint Wenhao 2025-05-12 18:17:00+00:00 - - - pithosian 2025-05-12 12:05:00+00:00 - - - Anthony Towns 2025-05-12 05:21:00+00:00 - - - Garlo Nicon 2025-05-09 13:07:00+00:00 - - - Saint Wenhao 2025-05-06 11:48:00+00:00 - - - Greg Maxwell 2025-05-05 22:25:00+00:00 - - - Sjors Provoost 2025-04-28 18:50:00+00:00 - - - Saint Wenhao 2025-04-28 18:15:00+00:00 - - - Saint Wenhao 2025-04-28 13:33:00+00:00 - - - Sjors Provoost 2025-04-28 12:47:00+00:00 - - - emsit 2025-04-28 11:59:00+00:00 - - - pithosian 2025-04-28 11:48:00+00:00 - - - Jameson Lopp 2025-04-28 10:45:00+00:00 - - - Saint Wenhao 2025-04-28 06:11:00+00:00 - - - Jameson Lopp 2025-04-27 22:49:00+00:00 - - - Saint Wenhao 2025-04-27 11:44:00+00:00 - - - Saint Wenhao 2025-03-31 07:32:00+00:00 - - - Antoine Poinsot 2025-03-24 13:57:00+00:00 - - - Murch 2025-03-24 12:25:00+00:00 - - - Garlo Nicon 2025-03-24 07:00:00+00:00 - - - Murch 2025-03-21 21:20:00+00:00 - - - Melvin Carvalho 2025-03-20 18:58:00+00:00 - - - bitcoindevml.void 2025-03-19 17:03:00+00:00 - - - Melvin Carvalho 2025-03-19 09:11:00+00:00 - - - Garlo Nicon 2025-03-19 08:43:00+00:00 - - - Sjors Provoost 2025-03-19 08:32:00+00:00 - - - Sjors Provoost 2025-03-19 07:56:00+00:00 - - - Melvin Carvalho 2025-03-19 07:01:00+00:00 - - - Antoine Poinsot 2025-03-18 21:34:00+00:00 - - - Antoine Poinsot 2025-03-18 14:29:00+00:00 - + 2025-09-26T14:25:49.079265+00:00 + python-feedgen + + + Unbreaking testnet4 'Antoine Poinsot' + 2025-03-18T14:29:00.000Z + + + Melvin Carvalho + 2025-03-18T21:34:00.000Z + + + Garlo Nicon + 2025-03-19T07:01:00.000Z + + + Sjors Provoost + 2025-03-19T07:56:00.000Z + + + Sjors Provoost + 2025-03-19T08:32:00.000Z + + + Garlo Nicon + 2025-03-19T08:43:00.000Z + + + Melvin Carvalho + 2025-03-19T09:11:00.000Z + + + bitcoin-dev-ml.void867 + 2025-03-19T17:03:00.000Z + + + Melvin Carvalho + 2025-03-20T18:58:00.000Z + + + Murch + 2025-03-21T21:20:00.000Z + + + Garlo Nicon + 2025-03-24T07:00:00.000Z + + + Murch + 2025-03-24T12:25:00.000Z + + + Antoine Poinsot' + 2025-03-24T13:57:00.000Z + + + Saint Wenhao + 2025-03-31T07:32:00.000Z + + + Saint Wenhao + 2025-04-27T11:44:00.000Z + + + Jameson Lopp + 2025-04-27T22:49:00.000Z + + + Saint Wenhao + 2025-04-28T06:11:00.000Z + + + Jameson Lopp + 2025-04-28T10:45:00.000Z + + + pithosian + 2025-04-28T11:48:00.000Z + + + emsit' + 2025-04-28T11:59:00.000Z + + + Sjors Provoost + 2025-04-28T12:47:00.000Z + + + Saint Wenhao + 2025-04-28T13:33:00.000Z + + + Saint Wenhao + 2025-04-28T18:15:00.000Z + + + Sjors Provoost + 2025-04-28T18:50:00.000Z + + + Greg Maxwell + 2025-05-05T22:25:00.000Z + + + Saint Wenhao + 2025-05-06T11:48:00.000Z + + + Garlo Nicon + 2025-05-09T13:07:00.000Z + + + Anthony Towns + 2025-05-12T05:21:00.000Z + + + pithosian + 2025-05-12T12:05:00.000Z + + + Saint Wenhao + 2025-05-12T18:17:00.000Z + + + pithosian + 2025-05-12T20:19:00.000Z + + + Saint Wenhao + 2025-05-17T05:11:00.000Z + + + Garlo Nicon + 2025-07-05T04:31:00.000Z + + @@ -135,21 +171,17 @@ - python-feedgen + 2 Combined summary - Unbreaking testnet4 - 2025-07-06T03:04:39.614808+00:00 + 2025-09-26T14:25:49.082423+00:00 + 2025-07-05T04:31:00+00:00 The ongoing discourse within the Bitcoin development community underscores a collective drive towards refining the blockchain's testnet environment, aiming to bridge the gap between an ideal testing ground and the inherent challenges posed by current operational frameworks. Testnet4, introduced with aspirations to surmount the difficulties encountered in Testnet3—particularly those related to the difficulty reset mechanism—has paradoxically replicated similar challenges. The initiative to enable developers to mine blocks on less powerful devices like laptops, although well-intentioned, inadvertently led to exploitative practices that undermined the testnet's utility. This contradiction highlights a fundamental tension between maintaining a permissionless network, as is characteristic of Proof of Work (PoW) systems, and the necessity for a controlled environment conducive to development, such as that offered by Signet. - The debate extends to the question of how best to evolve the testnet framework without compromising its core objectives. A pivotal suggestion within this dialogue is the elimination of the difficulty reset rule from Testnet4 through a flag day hard fork slated for January 1, 2026. This proposed timeline provides ample opportunity for comprehensive review, integration into upcoming Bitcoin Core releases, and widespread adoption across existing infrastructure. This approach reflects a broader consideration of how to balance the need for an authentic replication of the Bitcoin mainnet against facilitating a practical and accessible platform for developers. - Further discussions have ventured into innovative solutions aimed at enhancing the testnet's functionality, including the development of a decentralized faucet by Antoine Poinsot. This tool represents a significant step towards lowering entry barriers for new developers and streamlining the testing process. Such initiatives underscore a concerted effort within the community to address the testnet's limitations, ensuring it remains a vital resource for fostering innovation and improving the robustness of Bitcoin's testing environments. - In parallel, conversations have also delved into technical aspects concerning the blockchain's code, particularly the `fPowAllowMinDifficultyBlocks` rule and its implications for block addition under specific circumstances. These discussions highlight the intricate nature of blockchain protocol management and the continuous efforts to strike a balance between flexibility, security, and fairness within the network's operation. - Overall, the dialogue within the Bitcoin Development Mailing List encapsulates a dynamic and ongoing process of reflection, critique, and collaborative problem-solving. It signifies a commitment among developers to not only navigate the complexities of blockchain technology but also to envision and implement changes that enhance its sustainability, efficacy, and inclusivity. - 2025-07-05T04:31:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2025/combined_What-s-a-good-stopping-point-Making-the-case-for-the-capabilities-enabled-by-CTV-CSFS.xml b/static/bitcoin-dev/July_2025/combined_What-s-a-good-stopping-point-Making-the-case-for-the-capabilities-enabled-by-CTV-CSFS.xml index 263eb4fa4f..8e560aa27a 100644 --- a/static/bitcoin-dev/July_2025/combined_What-s-a-good-stopping-point-Making-the-case-for-the-capabilities-enabled-by-CTV-CSFS.xml +++ b/static/bitcoin-dev/July_2025/combined_What-s-a-good-stopping-point-Making-the-case-for-the-capabilities-enabled-by-CTV-CSFS.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS - 2025-07-11T03:05:22.820924+00:00 - - Josh Doman 2025-07-10 14:33:00+00:00 - - - Greg Sanders 2025-07-10 12:05:00+00:00 - - - Josh Doman 2025-07-09 21:30:00+00:00 - - - Antoine Poinsot 2025-07-04 13:02:00+00:00 - - - Anthony Towns 2025-07-03 03:55:00+00:00 - - - Antoine Riard 2025-06-29 22:50:00+00:00 - - - Greg Sanders 2025-06-26 17:03:00+00:00 - - - Josh Doman 2025-06-26 16:02:00+00:00 - - - Ethan Heilman 2025-06-25 20:34:00+00:00 - - - Chris Stewart 2025-06-25 19:22:00+00:00 - - - Antoine Poinsot 2025-06-25 16:50:00+00:00 - - - Matt Corallo 2025-06-24 15:54:00+00:00 - - - Harsha Goli 2025-06-24 14:29:00+00:00 - - - Antoine Poinsot 2025-06-23 13:14:00+00:00 - + 2025-09-26T14:25:36.128171+00:00 + python-feedgen + + + What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS 'Antoine Poinsot' + 2025-06-23T13:14:00.000Z + + + Harsha Goli + 2025-06-24T14:29:00.000Z + + + Matt Corallo + 2025-06-24T15:54:00.000Z + + + Antoine Poinsot' + 2025-06-25T16:50:00.000Z + + + Chris Stewart + 2025-06-25T19:22:00.000Z + + + Ethan Heilman + 2025-06-25T20:34:00.000Z + + + Josh Doman + 2025-06-26T16:02:00.000Z + + + Greg Sanders + 2025-06-26T17:03:00.000Z + + + Antoine Riard + 2025-06-29T22:50:00.000Z + + + Anthony Towns + 2025-07-03T03:55:00.000Z + + + Antoine Poinsot' + 2025-07-04T13:02:00.000Z + + + Josh Doman + 2025-07-09T21:30:00.000Z + + + Greg Sanders + 2025-07-10T12:05:00.000Z + + + Josh Doman + 2025-07-10T14:33:00.000Z + + @@ -59,23 +76,18 @@ - python-feedgen + 2 Combined summary - What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS - 2025-07-11T03:05:22.821031+00:00 + 2025-09-26T14:25:36.129771+00:00 + 2025-07-10T14:33:00+00:00 The dialogue among Bitcoin developers centers on the necessity and methodology of enhancing Bitcoin's expressivity particularly in relation to committing to sibling prevouts. The conversation suggests a departure from more complex proposals like OP_TX / OP_TXHASH in favor of a streamlined approach utilizing MuHash. MuHash is proposed for its efficiency in committing to sibling prevouts within transactions, offering an alternative that reduces complexity by enabling commitments in constant time. This method involves precomputing a MuHash accumulator with the SHA256(index || prevout) for each transaction input, thereby facilitating efficient commitment verification. The discussion posits this technique as a low-cost, predictable method that could seamlessly integrate into the existing commitment scheme without substantial modifications, leveraging the already-included MuHash in Bitcoin's codebase. - There are concerns regarding the BitVM/CTV proposal, highlighting a lack of detailed demonstration or practical application that makes it difficult to assess its benefits or improvements to Bitcoin users. The skepticism extends to the justification for increasing Bitcoin's expressivity through such proposals, suggesting a need for more concrete evidence or deployment success before considering significant changes. - Further discussions explore the potential risks of expanding Bitcoin's script capabilities, emphasizing the importance of cautious development to avoid unintended vulnerabilities. The conversation reflects a preference for a gradual, well-evaluated extension of scripting functions rather than a comprehensive overhaul, focusing on consensus-level mechanisms to address issues like Miner Extractable Value (MEV) attacks. There's also a call for prioritizing fixes in Bitcoin Improvement Proposal 54 (BIP54) before integrating new features like CheckTemplateVerify (CTV) and CSFS, underlining the limited resources for review and the potential for unfavorable interactions between different changes. - A detailed discourse delves into the exploration of commitment hashes and their applications beyond current usage, urging the Bitcoin development community to investigate a broader range of enhancements. The discussions underscore a collective interest in refining Bitcoin's functionality, particularly for second-layer protocols, through sophisticated mechanisms like explicit commitments to neighbor prevouts. - The narrative shifts towards considerations for replacing or augmenting Bitcoin Script, advocating for the introduction of simple opcodes to gather insights for future development. It highlights the ongoing efforts to enhance Script’s capabilities through advanced introspection and arithmetic operations while addressing security concerns with innovative solutions like Taproot annexes. - The exchange on the Bitcoin Development Mailing List showcases a robust debate on introducing new opcodes aimed at reducing interactivity within second-layer protocols. There's a conscious effort to balance innovation with stability, emphasizing practical use cases over speculative advantages. The dialogue encapsulates a strategic approach to Bitcoin's evolution, prioritizing enhancements that offer tangible benefits and align with the network's foundational principles. - 2025-07-10T14:33:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_-BIP-proposal-Private-Payments.xml b/static/bitcoin-dev/June_2022/combined_-BIP-proposal-Private-Payments.xml index 9551cc937f..ab49dc089a 100644 --- a/static/bitcoin-dev/June_2022/combined_-BIP-proposal-Private-Payments.xml +++ b/static/bitcoin-dev/June_2022/combined_-BIP-proposal-Private-Payments.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - [BIP proposal] Private Payments - 2023-08-02T06:52:59.917948+00:00 - - Alfred Hodler 2022-07-11 10:28:40+00:00 - - - Alfred Hodler 2022-07-05 09:38:44+00:00 - - - Christopher Allen 2022-07-01 17:37:57+00:00 - - - Alfred Hodler 2022-07-01 12:41:45+00:00 - - - Clark Moody 2022-06-29 22:33:26+00:00 - - - Peter Todd 2022-06-28 23:33:45+00:00 - - - Alfred Hodler 2022-06-28 12:40:10+00:00 - - - Alfred Hodler 2022-06-28 12:35:31+00:00 - - - Ruben Somsen 2022-06-27 20:35:34+00:00 - - - Ruben Somsen 2022-06-27 20:30:39+00:00 - - - Bryan Bishop 2022-06-27 20:20:45+00:00 - - - Alfred Hodler 2022-06-27 18:17:16+00:00 - + 2025-09-26T14:31:42.194191+00:00 + python-feedgen + + + [bitcoin-dev] [BIP proposal] Private Payments Alfred Hodler + 2022-06-27T18:17:00.000Z + + + Bryan Bishop + 2022-06-27T20:20:00.000Z + + + Ruben Somsen + 2022-06-27T20:30:00.000Z + + + Ruben Somsen + 2022-06-27T20:35:00.000Z + + + Alfred Hodler + 2022-06-28T12:35:00.000Z + + + Alfred Hodler + 2022-06-28T12:40:00.000Z + + + Peter Todd + 2022-06-28T23:33:00.000Z + + + Clark Moody + 2022-06-29T22:33:00.000Z + + + Alfred Hodler + 2022-07-01T12:41:00.000Z + + + Christopher Allen + 2022-07-01T17:37:00.000Z + + + Alfred Hodler + 2022-07-05T09:38:00.000Z + + + Alfred Hodler + 2022-07-11T10:28:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - [BIP proposal] Private Payments - 2023-08-02T06:52:59.917948+00:00 + 2025-09-26T14:31:42.195612+00:00 - In an update to a previous specification, it has been decided that Bob does not need to watch all address types he's advertising. Instead, when notifying him, Alice will pick one address type out of the ones Bob is advertising and include it in the notification. The new payload has been extended to 73 bytes and defined as `BIPXXXX + notification + N_Alice + address_type`. Previously, the spec had stated that Alice should construct a 72-byte OP_RETURN output whose value would be set to `BIPXXXX + notification + N_Alice`. Damian James Williamson questioned the legibility of the blockchain and the fungibility of UTXOs in a proposal. KING JAMES HRMH replied, stating that the blockchain must be legible for it to be an indelible record, and that Bitcoin is only fungible because it uses the blockchain. The email also included contact information for Damian's company, Willtech, as well as links to their website, duigco.org, and other projects.A proposal to use bech32 instead of base58 for more compact QR codes has been agreed upon. Base64 is a big offender as it not only does not auto-compress, but also triggers binary mode that almost doubles the size of the QR. The Blockchain Commons offers other Airgap QR and TorGap UR efforts, including NFC encrypted Airgap & crypto-request/response flows.The conversation between Clark and Alfred discussed the proposal to use bech32 instead of base58 for more compact QR codes. They both agreed that it is a good proposal. They also discussed the possibility of a third-party service offering to publish OP_RETURN notification payloads in the blockchain for a fee without linking the notifier's identity to their wallet. Another alternative discussed was publishing the block height along with the notification data contained within that block.A new payment code standard proposal is being put forward that builds on the idea of payment codes under a new BIP with some principal differences. The proposed standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist, but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process.In a recent bitcoin-dev thread, there was a discussion around the mechanism to demand that a notification transaction meets some minimum miner fee. However, it was pointed out that this mechanism is not safe against miners as they can pay themselves arbitrarily high fees with no downside. One suggestion made was that the spammer has to publish at all. Another suggestion put forward was to do a timelocked sacrifice with OP_CSV.Bryan suggested using Tor hidden service to publish instead of using OP_RETURN while keeping the details of the transaction off-chain. Alfred pointed out that this method is an off-chain solution and it won't work in an offline regime. He also mentioned that Tor keys can be derived from master keys, but this approach isn't much different from Bitmessage notifications in BIP47.The participants discussed the potential issues that may arise if the number of standard scripts increases significantly. One concern is that wallets will have to watch all of them, which could create a performance hit. Additionally, some wallets may not support certain scripts, leading to confusion when sending funds. One proposed solution is to use Taproot-only, but there are concerns about locking down the BIP to a single script type for future proofing. Instead, participants suggest using address type flags to solve these issues at the expense of having a couple of extra bytes.In a discussion on the bitcoin-dev mailing list, Bryan Bishop suggested an alternative to using OP_RETURN in notification transactions for private payments. He proposed publishing the data on a Tor hidden service that other wallets can check. Ruben Santamarta pointed out that the data on-chain is critical to accessing funds and guaranteeing their availability when restoring from backup.Alfred Hodler proposed a way to make notification transactions more private. He suggests that notification transactions will no longer leave a footprint on the blockchain and instead, will just be a single OP_RETURN containing a value that only Alice and Bob can calculate. Bryan suggested an alternative way to maintain privacy while making notification transactions. He suggested that instead of using OP_RETURN, Alice could publish on a Tor hidden service that other wallets check.The BIP47 standard for creating static payment codes suffered from several issues. The new proposed standard that builds on the idea of payment codes under a new BIP has several principal differences. The new standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process. 2022-07-11T10:28:40+00:00 + In an update to a previous specification, it has been decided that Bob does not need to watch all address types he's advertising. Instead, when notifying him, Alice will pick one address type out of the ones Bob is advertising and include it in the notification. The new payload has been extended to 73 bytes and defined as `BIPXXXX + notification + N_Alice + address_type`. Previously, the spec had stated that Alice should construct a 72-byte OP_RETURN output whose value would be set to `BIPXXXX + notification + N_Alice`. Damian James Williamson questioned the legibility of the blockchain and the fungibility of UTXOs in a proposal. KING JAMES HRMH replied, stating that the blockchain must be legible for it to be an indelible record, and that Bitcoin is only fungible because it uses the blockchain. The email also included contact information for Damian's company, Willtech, as well as links to their website, duigco.org, and other projects.A proposal to use bech32 instead of base58 for more compact QR codes has been agreed upon. Base64 is a big offender as it not only does not auto-compress, but also triggers binary mode that almost doubles the size of the QR. The Blockchain Commons offers other Airgap QR and TorGap UR efforts, including NFC encrypted Airgap & crypto-request/response flows.The conversation between Clark and Alfred discussed the proposal to use bech32 instead of base58 for more compact QR codes. They both agreed that it is a good proposal. They also discussed the possibility of a third-party service offering to publish OP_RETURN notification payloads in the blockchain for a fee without linking the notifier's identity to their wallet. Another alternative discussed was publishing the block height along with the notification data contained within that block.A new payment code standard proposal is being put forward that builds on the idea of payment codes under a new BIP with some principal differences. The proposed standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist, but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process.In a recent bitcoin-dev thread, there was a discussion around the mechanism to demand that a notification transaction meets some minimum miner fee. However, it was pointed out that this mechanism is not safe against miners as they can pay themselves arbitrarily high fees with no downside. One suggestion made was that the spammer has to publish at all. Another suggestion put forward was to do a timelocked sacrifice with OP_CSV.Bryan suggested using Tor hidden service to publish instead of using OP_RETURN while keeping the details of the transaction off-chain. Alfred pointed out that this method is an off-chain solution and it won't work in an offline regime. He also mentioned that Tor keys can be derived from master keys, but this approach isn't much different from Bitmessage notifications in BIP47.The participants discussed the potential issues that may arise if the number of standard scripts increases significantly. One concern is that wallets will have to watch all of them, which could create a performance hit. Additionally, some wallets may not support certain scripts, leading to confusion when sending funds. One proposed solution is to use Taproot-only, but there are concerns about locking down the BIP to a single script type for future proofing. Instead, participants suggest using address type flags to solve these issues at the expense of having a couple of extra bytes.In a discussion on the bitcoin-dev mailing list, Bryan Bishop suggested an alternative to using OP_RETURN in notification transactions for private payments. He proposed publishing the data on a Tor hidden service that other wallets can check. Ruben Santamarta pointed out that the data on-chain is critical to accessing funds and guaranteeing their availability when restoring from backup.Alfred Hodler proposed a way to make notification transactions more private. He suggests that notification transactions will no longer leave a footprint on the blockchain and instead, will just be a single OP_RETURN containing a value that only Alice and Bob can calculate. Bryan suggested an alternative way to maintain privacy while making notification transactions. He suggested that instead of using OP_RETURN, Alice could publish on a Tor hidden service that other wallets check.The BIP47 standard for creating static payment codes suffered from several issues. The new proposed standard that builds on the idea of payment codes under a new BIP has several principal differences. The new standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_-PROPOSAL-OP-TX-generalized-covenants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml b/static/bitcoin-dev/June_2022/combined_-PROPOSAL-OP-TX-generalized-covenants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml index 738d9c81e0..7aaa9fdb53 100644 --- a/static/bitcoin-dev/June_2022/combined_-PROPOSAL-OP-TX-generalized-covenants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml +++ b/static/bitcoin-dev/June_2022/combined_-PROPOSAL-OP-TX-generalized-covenants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY - 2023-08-02T06:29:11.754640+00:00 - - Jeremy Rubin 2022-06-24 18:05:50+00:00 - - - Anthony Towns 2022-06-24 06:06:05+00:00 - - - Alex Schoof 2022-05-11 23:32:34+00:00 - - - Brandon Black 2022-05-10 15:16:10+00:00 - - - Rusty Russell 2022-05-10 10:35:54+00:00 - + 2025-09-26T14:31:24.993859+00:00 + python-feedgen + + + [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY Rusty Russell + 2022-05-10T10:35:00.000Z + + + Brandon Black + 2022-05-10T15:16:00.000Z + + + Alex Schoof + 2022-05-11T23:32:00.000Z + + + Anthony Towns + 2022-06-24T06:06:00.000Z + + + Jeremy Rubin + 2022-06-24T18:05:00.000Z + + - python-feedgen + 2 Combined summary - [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY - 2023-08-02T06:29:11.754640+00:00 + 2025-09-26T14:31:24.994634+00:00 - In a recent discussion on the bitcoin-dev mailing list, the use of merkle trees for Commitment Transaction Verification (CTV) was debated. While there was recognition that merkle trees could offer advantages in terms of API perspective, the main concern raised was related to validation performance. It was argued that using a merkle tree would add unnecessary work for CTV, with its value only evident in scenarios involving multiple outputs and random-index insertions. For cases where editing the last output is common, SHA-STREAM was proposed as an alternative option, enabling efficient editing of the tail. The conversation also touched upon the OPTX_SEPARATELY and OPTX_UNHASHED fields, as well as the OPTX_SELECT_OUTPUT_AMOUNT32x2* and OPTX_SELECT_OUTPUT_SCRIPTPUBKEY* fields. The issue of upgradability was highlighted, particularly in relation to committing to specific outputs, which currently poses challenges for both OP_TX and CTV. One potential solution suggested was the use of a merkle path to prove the consumption of an entire output. Overall, the discussion centered around weighing the tradeoffs between employing a merkle tree versus other methods for CTV.On May 10, 2022, Rusty Russell shared some ideas on the bitcoin-dev mailing list regarding the OPTX_SEPARATELY and OPTX_UNHASHED fields. He proposed treating these fields separately instead of concatenating them and pushing them on the stack without hashing. The discussion revolved around updating the CTV hash by committing to specific outputs, but it was acknowledged that both approaches were less efficient compared to using a merkle path. The challenge of proving the consumption of an output in its entirety was linked to concerns about upgradability, especially if additional features like CAT or TLUV were to be added. Both OP_TX and CTV aimed to account for upgradability in advance. These concepts have the potential to enhance the efficiency and security of the Bitcoin network.A proposal has been introduced for a v1 tapscript opcode that enables generic covenants. The proposal suggests utilizing an OP_SUCCESS opcode, unless it is used similarly to OP_CHECKTEMPLATEVERIFY, which offers a clear use case and allows for future expansion. If experience demonstrates that repurposing OP_NOP4 as a shortcut is a useful optimization, it may be considered in the future. The proposal builds upon Russell O'Connor's TXHASH, incorporating Anthony Towns' modification through opcode extension. Certain bits are defined specifically for this soft fork, while others can have their semantics determined later. To ensure clarity, the proposal outlines potential future uses. Notably, BIP-342 resource limits impose restrictions, such as failing when more than 1000 elements are pushed on the stack or when an element exceeds 512 bytes. By precisely enumerating what can be committed to, it becomes unequivocally clear what is and isn't committed. The bits separating concatenation and hashing provide a straightforward mechanism for template-style commitments (like CTV) or programmatic treatment of individual elements, such as amounts. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. It is important to note that the OP_SUCCESS semantic is only applicable in tapscript v1, making it incompatible with covenants for v0 segwit or pre-segwit inputs. If covenants prove beneficial, dedicated opcodes can be provided for those cases.Brandon responded to Rusty Russell's previous email regarding the proposal for a v1 tapscript opcode for generic covenants. Brandon emphasized one major limitation of CTV, which is the script's specificity to the amount of the input being spent. He suggested adding OPTX_SELECT_IN_OUT_AMOUNT32x2 to the initial set of flags, enabling the reuse of a single script and facilitating the construction of a small script for relocatable, batchable operations. The proposed soft fork involves OP_TX followed by 4 bytes of flags. Only the flags marked with an asterisk need to be defined for this soft fork, while others can have their semantics determined later. The proposed flag combinations aim to approximate OP_CHECKTEMPLATEVERIFY, with other combinations resulting in OP_SUCCESS. By enumerating what can be committed to, it becomes explicitly clear what is and isn't committed. The bits separating concatenation and hashing provide a simple mechanism for template-style commitments or programmatic treatment of individual elements. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. The OP_SUCCESS semantic is only valid in tapscript v1, meaning it does not allow for covenants in v0 segwit or pre-segwit inputs. If covenants prove useful, dedicated opcodes can be provided for those cases, similar to OP_CHECKTEMPLATEVERIFY.A proposal has been made to introduce a v1 tapscript opcode for generic covenants, with only an OP_SUCCESS opcode if used similarly 2022-06-24T18:05:50+00:00 + In a recent discussion on the bitcoin-dev mailing list, the use of merkle trees for Commitment Transaction Verification (CTV) was debated. While there was recognition that merkle trees could offer advantages in terms of API perspective, the main concern raised was related to validation performance. It was argued that using a merkle tree would add unnecessary work for CTV, with its value only evident in scenarios involving multiple outputs and random-index insertions. For cases where editing the last output is common, SHA-STREAM was proposed as an alternative option, enabling efficient editing of the tail. The conversation also touched upon the OPTX_SEPARATELY and OPTX_UNHASHED fields, as well as the OPTX_SELECT_OUTPUT_AMOUNT32x2* and OPTX_SELECT_OUTPUT_SCRIPTPUBKEY* fields. The issue of upgradability was highlighted, particularly in relation to committing to specific outputs, which currently poses challenges for both OP_TX and CTV. One potential solution suggested was the use of a merkle path to prove the consumption of an entire output. Overall, the discussion centered around weighing the tradeoffs between employing a merkle tree versus other methods for CTV.On May 10, 2022, Rusty Russell shared some ideas on the bitcoin-dev mailing list regarding the OPTX_SEPARATELY and OPTX_UNHASHED fields. He proposed treating these fields separately instead of concatenating them and pushing them on the stack without hashing. The discussion revolved around updating the CTV hash by committing to specific outputs, but it was acknowledged that both approaches were less efficient compared to using a merkle path. The challenge of proving the consumption of an output in its entirety was linked to concerns about upgradability, especially if additional features like CAT or TLUV were to be added. Both OP_TX and CTV aimed to account for upgradability in advance. These concepts have the potential to enhance the efficiency and security of the Bitcoin network.A proposal has been introduced for a v1 tapscript opcode that enables generic covenants. The proposal suggests utilizing an OP_SUCCESS opcode, unless it is used similarly to OP_CHECKTEMPLATEVERIFY, which offers a clear use case and allows for future expansion. If experience demonstrates that repurposing OP_NOP4 as a shortcut is a useful optimization, it may be considered in the future. The proposal builds upon Russell O'Connor's TXHASH, incorporating Anthony Towns' modification through opcode extension. Certain bits are defined specifically for this soft fork, while others can have their semantics determined later. To ensure clarity, the proposal outlines potential future uses. Notably, BIP-342 resource limits impose restrictions, such as failing when more than 1000 elements are pushed on the stack or when an element exceeds 512 bytes. By precisely enumerating what can be committed to, it becomes unequivocally clear what is and isn't committed. The bits separating concatenation and hashing provide a straightforward mechanism for template-style commitments (like CTV) or programmatic treatment of individual elements, such as amounts. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. It is important to note that the OP_SUCCESS semantic is only applicable in tapscript v1, making it incompatible with covenants for v0 segwit or pre-segwit inputs. If covenants prove beneficial, dedicated opcodes can be provided for those cases.Brandon responded to Rusty Russell's previous email regarding the proposal for a v1 tapscript opcode for generic covenants. Brandon emphasized one major limitation of CTV, which is the script's specificity to the amount of the input being spent. He suggested adding OPTX_SELECT_IN_OUT_AMOUNT32x2 to the initial set of flags, enabling the reuse of a single script and facilitating the construction of a small script for relocatable, batchable operations. The proposed soft fork involves OP_TX followed by 4 bytes of flags. Only the flags marked with an asterisk need to be defined for this soft fork, while others can have their semantics determined later. The proposed flag combinations aim to approximate OP_CHECKTEMPLATEVERIFY, with other combinations resulting in OP_SUCCESS. By enumerating what can be committed to, it becomes explicitly clear what is and isn't committed. The bits separating concatenation and hashing provide a simple mechanism for template-style commitments or programmatic treatment of individual elements. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. The OP_SUCCESS semantic is only valid in tapscript v1, meaning it does not allow for covenants in v0 segwit or pre-segwit inputs. If covenants prove useful, dedicated opcodes can be provided for those cases, similar to OP_CHECKTEMPLATEVERIFY.A proposal has been made to introduce a v1 tapscript opcode for generic covenants, with only an OP_SUCCESS opcode if used similarly - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_BGP-hijacking-on-Bitcoin-p2p-network.xml b/static/bitcoin-dev/June_2022/combined_BGP-hijacking-on-Bitcoin-p2p-network.xml index 33e9c48193..58330c2a17 100644 --- a/static/bitcoin-dev/June_2022/combined_BGP-hijacking-on-Bitcoin-p2p-network.xml +++ b/static/bitcoin-dev/June_2022/combined_BGP-hijacking-on-Bitcoin-p2p-network.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BGP hijacking on Bitcoin p2p network - 2023-08-02T06:46:57.112983+00:00 - - alicexbt 2022-07-05 20:30:24+00:00 - - - Elias Rohrer 2022-06-10 06:44:05+00:00 - - - alicexbt 2022-06-09 18:24:03+00:00 - + 2025-09-26T14:31:35.705605+00:00 + python-feedgen + + + [bitcoin-dev] BGP hijacking on Bitcoin p2p network alicexbt + 2022-06-09T18:24:00.000Z + + + Elias Rohrer + 2022-06-10T06:44:00.000Z + + + alicexbt + 2022-07-05T20:30:00.000Z + + - python-feedgen + 2 Combined summary - BGP hijacking on Bitcoin p2p network - 2023-08-02T06:46:57.112983+00:00 + 2025-09-26T14:31:35.706184+00:00 - Alicexbt, a member of the Bitcoin Development mailing list, has raised concerns about BGP hijacking attacks on bitcoin nodes. This vulnerability was noted in a 2014 answer on Stack Exchange. To learn more about the topic, Alicexbt searched for research articles and found works by Maria Apostolaki et al., Muoi Tran et al., and related works. They also shared links to blog posts about the March 2022 Twitter prefix hijacking incident and the Tor network's vulnerability to BGP hijacking.After conducting further research, Alicexbt discovered that RPKI ROA and BGP prefix length could help prevent BGP hijacking attacks. In an effort to address these vulnerabilities, Alicexbt is working on a Chrome extension that connects to local bitcoin core and checks the IP address of all peers for prefix length and other attributes. The extension will highlight peers with different colors based on certain criteria.However, when running tests on the first 10 IP addresses returned in `getnodeaddresses` for Bitcoin Core, vulnerable results were obtained. In response to this, Elias recommended research articles by Maria Apostolaki et al., Muoi Tran et al., and related works that delve into routing attacks.Desiring to contribute to the community's understanding and defense against BGP hijacking attacks, Alicexbt expressed interest in writing a detailed blog post or research article on the subject. They are seeking technical feedback and links to past discussions with potential solutions.In addition to bitcoin nodes, other networks such as Twitter and the Tor network have also experienced BGP hijacking incidents. The Twitter prefix hijacking incident in March 2022 was detailed in blog posts by ISC Sans and MANRS. The vulnerability of the Tor network to BGP hijacking was discussed in an article by 'nusenu'.To mitigate these attacks, it is suggested that implementing RPKI ROA and considering BGP prefix length can be effective. However, further research and discussions are needed to fully address the vulnerabilities. Alicexbt's goal is to contribute to this effort by writing a comprehensive article or blog post in the near future. 2022-07-05T20:30:24+00:00 + Alicexbt, a member of the Bitcoin Development mailing list, has raised concerns about BGP hijacking attacks on bitcoin nodes. This vulnerability was noted in a 2014 answer on Stack Exchange. To learn more about the topic, Alicexbt searched for research articles and found works by Maria Apostolaki et al., Muoi Tran et al., and related works. They also shared links to blog posts about the March 2022 Twitter prefix hijacking incident and the Tor network's vulnerability to BGP hijacking.After conducting further research, Alicexbt discovered that RPKI ROA and BGP prefix length could help prevent BGP hijacking attacks. In an effort to address these vulnerabilities, Alicexbt is working on a Chrome extension that connects to local bitcoin core and checks the IP address of all peers for prefix length and other attributes. The extension will highlight peers with different colors based on certain criteria.However, when running tests on the first 10 IP addresses returned in `getnodeaddresses` for Bitcoin Core, vulnerable results were obtained. In response to this, Elias recommended research articles by Maria Apostolaki et al., Muoi Tran et al., and related works that delve into routing attacks.Desiring to contribute to the community's understanding and defense against BGP hijacking attacks, Alicexbt expressed interest in writing a detailed blog post or research article on the subject. They are seeking technical feedback and links to past discussions with potential solutions.In addition to bitcoin nodes, other networks such as Twitter and the Tor network have also experienced BGP hijacking incidents. The Twitter prefix hijacking incident in March 2022 was detailed in blog posts by ISC Sans and MANRS. The vulnerability of the Tor network to BGP hijacking was discussed in an article by 'nusenu'.To mitigate these attacks, it is suggested that implementing RPKI ROA and considering BGP prefix length can be effective. However, further research and discussions are needed to fully address the vulnerabilities. Alicexbt's goal is to contribute to this effort by writing a comprehensive article or blog post in the near future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_BIP47-Prague-Discussion.xml b/static/bitcoin-dev/June_2022/combined_BIP47-Prague-Discussion.xml index 02548fc1d6..dcfda2cb8b 100644 --- a/static/bitcoin-dev/June_2022/combined_BIP47-Prague-Discussion.xml +++ b/static/bitcoin-dev/June_2022/combined_BIP47-Prague-Discussion.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP47 Prague Discussion - 2023-08-02T06:47:26.626141+00:00 - - Paul Sztorc 2022-06-11 14:30:13+00:00 - - - Ruben Somsen 2022-06-11 10:01:58+00:00 - + 2025-09-26T14:31:33.595212+00:00 + python-feedgen + + + [bitcoin-dev] BIP47 Prague Discussion Ruben Somsen + 2022-06-11T10:01:00.000Z + + + Paul Sztorc + 2022-06-11T14:30:00.000Z + + - python-feedgen + 2 Combined summary - BIP47 Prague Discussion - 2023-08-02T06:47:26.626141+00:00 + 2025-09-26T14:31:33.595663+00:00 - At Pizza Day Prague 2022, a discussion was held regarding the improvement of BIP47, which focused on minimizing the on-chain space required and outsourcing the notification transaction to break the sender/recipient link. The current implementation of BIP47 requires an input key for blinding, the blinded sender payment code in an op_return, and the recipient key in an output. However, it was suggested that the requirement for the recipient to learn the payment code of the sender could be foregone, as it is not necessary and could potentially save space. The minimum notification payload required is a fresh sender key and a static recipient key.Another idea discussed was to put multiple notifications in a single transaction, which can then be outsourced to a third party. This third party could be paid over the Lightning Network for their services in breaking the sender/recipient link. One possible solution proposed was to use the taproot annex to insert the notification payload as discounted witness data. However, this approach would require custom software for the recipient to notice the notification, as it is not tied to an easily noticeable output. Alternatively, the sender keys could be included in the transaction while still creating an output for each recipient key.During the discussion, an interesting point was raised regarding the representation of the recipient key. It was suggested that it could be represented using only 4 bytes, leaving a window of 1 in ~4.3 billion for a collision. This would significantly reduce the payload from 64 bytes to 36 bytes of witness data. However, it should be noted that using the annex makes the transaction non-standard. Therefore, it was proposed that either the annex should be standardized as the first use case or an alternative method should be considered.The participants in the discussion included Alekos Filini, Martin Habovštiak, Daniela Brozzoni, Eric Sirion, Pavol Rusnak, Salvatore Ingala, and others. Relevant materials such as Silent Payments and BIP47 were provided for reference.Overall, the discussion revolved around minimizing the on-chain space required for BIP47 and outsourcing the notification transaction to a third party in order to break the sender/recipient link. Additionally, the idea of representing the recipient key with only 4 bytes was discussed, which would significantly reduce the payload size. 2022-06-11T14:30:13+00:00 + At Pizza Day Prague 2022, a discussion was held regarding the improvement of BIP47, which focused on minimizing the on-chain space required and outsourcing the notification transaction to break the sender/recipient link. The current implementation of BIP47 requires an input key for blinding, the blinded sender payment code in an op_return, and the recipient key in an output. However, it was suggested that the requirement for the recipient to learn the payment code of the sender could be foregone, as it is not necessary and could potentially save space. The minimum notification payload required is a fresh sender key and a static recipient key.Another idea discussed was to put multiple notifications in a single transaction, which can then be outsourced to a third party. This third party could be paid over the Lightning Network for their services in breaking the sender/recipient link. One possible solution proposed was to use the taproot annex to insert the notification payload as discounted witness data. However, this approach would require custom software for the recipient to notice the notification, as it is not tied to an easily noticeable output. Alternatively, the sender keys could be included in the transaction while still creating an output for each recipient key.During the discussion, an interesting point was raised regarding the representation of the recipient key. It was suggested that it could be represented using only 4 bytes, leaving a window of 1 in ~4.3 billion for a collision. This would significantly reduce the payload from 64 bytes to 36 bytes of witness data. However, it should be noted that using the annex makes the transaction non-standard. Therefore, it was proposed that either the annex should be standardized as the first use case or an alternative method should be considered.The participants in the discussion included Alekos Filini, Martin Habovštiak, Daniela Brozzoni, Eric Sirion, Pavol Rusnak, Salvatore Ingala, and others. Relevant materials such as Silent Payments and BIP47 were provided for reference.Overall, the discussion revolved around minimizing the on-chain space required for BIP47 and outsourcing the notification transaction to a third party in order to break the sender/recipient link. Additionally, the idea of representing the recipient key with only 4 bytes was discussed, which would significantly reduce the payload size. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_Bitcoin-covenants-are-inevitable.xml b/static/bitcoin-dev/June_2022/combined_Bitcoin-covenants-are-inevitable.xml index 5ee9d9ab04..c34246683e 100644 --- a/static/bitcoin-dev/June_2022/combined_Bitcoin-covenants-are-inevitable.xml +++ b/static/bitcoin-dev/June_2022/combined_Bitcoin-covenants-are-inevitable.xml @@ -1,173 +1,231 @@ - + 2 Combined summary - Bitcoin covenants are inevitable - 2023-08-02T06:40:26.385436+00:00 - - alicexbt 2022-07-19 14:46:46+00:00 - - - Anthony Towns 2022-07-19 04:44:58+00:00 - - - Billy Tetrud 2022-07-14 04:55:35+00:00 - - - Erik Aronesty 2022-07-08 15:14:39+00:00 - - - John Carvalho 2022-07-08 07:26:06+00:00 - - - Billy Tetrud 2022-07-08 05:03:40+00:00 - - - vjudeu at gazeta.pl 2022-07-08 04:59:30+00:00 - - - Eric Voskuil 2022-07-08 00:28:36+00:00 - - - Anthony Towns 2022-07-07 22:06:14+00:00 - - - Corey Haddad 2022-07-07 22:02:08+00:00 - - - Erik Aronesty 2022-07-07 21:11:47+00:00 - - - Eric Voskuil 2022-07-07 19:57:56+00:00 - - - Erik Aronesty 2022-07-07 17:37:39+00:00 - - - Eric Voskuil 2022-07-07 16:24:26+00:00 - - - Peter Todd 2022-07-07 14:12:41+00:00 - - - Giuseppe B 2022-07-07 14:10:31+00:00 - - - Erik Aronesty 2022-07-07 14:05:25+00:00 - - - John Carvalho 2022-07-07 13:24:39+00:00 - - - vjudeu at gazeta.pl 2022-07-07 12:15:34+00:00 - - - Billy Tetrud 2022-07-07 00:46:15+00:00 - - - vjudeu at gazeta.pl 2022-07-06 11:10:27+00:00 - - - Corey Haddad 2022-07-06 04:28:50+00:00 - - - Giuseppe B 2022-07-03 10:30:52+00:00 - - - Peter Todd 2022-07-03 09:43:53+00:00 - - - Erik Aronesty 2022-06-30 17:04:50+00:00 - - - Billy Tetrud 2022-06-30 15:25:47+00:00 - - - Kate Salazar 2022-06-29 10:44:11+00:00 - - - Alex Lee 2022-06-29 05:02:30+00:00 - - - Peter Todd 2022-06-28 23:22:40+00:00 - - - Peter Todd 2022-06-28 23:20:27+00:00 - - - Alex Lee 2022-06-28 16:23:40+00:00 - - - Billy Tetrud 2022-06-28 03:55:56+00:00 - - - Peter Todd 2022-06-23 19:17:37+00:00 - - - Eric Voskuil 2022-06-21 20:10:43+00:00 - - - Keagan McClelland 2022-06-21 19:00:07+00:00 - - - Erik Aronesty 2022-06-19 22:35:55+00:00 - - - Kate Salazar 2022-06-19 18:26:21+00:00 - - - Manuel Costa 2022-06-19 15:54:03+00:00 - - - Peter Todd 2022-06-19 10:31:38+00:00 - - - alicexbt 2022-06-12 19:16:49+00:00 - - - Corey Haddad 2022-06-12 16:35:06+00:00 - - - Erik Aronesty 2022-06-12 13:02:38+00:00 - - - Peter Todd 2022-06-12 03:36:45+00:00 - - - Billy Tetrud 2022-06-09 04:30:45+00:00 - - - Ryan Grant 2022-06-09 00:03:07+00:00 - - - Jorge Timón 2022-06-08 09:22:41+00:00 - - - Billy Tetrud 2022-06-08 03:51:40+00:00 - - - Erik Aronesty 2022-06-06 13:02:18+00:00 - - - alicexbt 2022-06-05 04:18:04+00:00 - - - Jorge Timón 2022-06-04 18:43:35+00:00 - - - alicexbt 2022-06-04 16:12:54+00:00 - - - Keagan McClelland 2022-06-04 13:48:40+00:00 - - - John Carvalho 2022-06-04 12:27:53+00:00 - - - micaroni at gmail.com 2022-06-04 00:29:44+00:00 - - - alicexbt 2022-06-03 18:39:34+00:00 - + 2025-09-26T14:31:40.037055+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin covenants are inevitable alicexbt + 2022-06-03T18:39:00.000Z + + + micaroni + 2022-06-04T00:29:00.000Z + + + John Carvalho + 2022-06-04T12:27:00.000Z + + + Keagan McClelland + 2022-06-04T13:48:00.000Z + + + alicexbt + 2022-06-04T16:12:00.000Z + + + Jorge Timón + 2022-06-04T18:43:00.000Z + + + alicexbt + 2022-06-05T04:18:00.000Z + + + Erik Aronesty + 2022-06-06T13:02:00.000Z + + + Billy Tetrud + 2022-06-08T03:51:00.000Z + + + Jorge Timón + 2022-06-08T09:22:00.000Z + + + Ryan Grant + 2022-06-09T00:03:00.000Z + + + Billy Tetrud + 2022-06-09T04:30:00.000Z + + + Peter Todd + 2022-06-12T03:36:00.000Z + + + Erik Aronesty + 2022-06-12T13:02:00.000Z + + + Corey Haddad + 2022-06-12T16:35:00.000Z + + + alicexbt + 2022-06-12T19:16:00.000Z + + + Peter Todd + 2022-06-19T10:31:00.000Z + + + Manuel Costa + 2022-06-19T15:54:00.000Z + + + Kate Salazar + 2022-06-19T18:26:00.000Z + + + Erik Aronesty + 2022-06-19T22:35:00.000Z + + + Keagan McClelland + 2022-06-21T19:00:00.000Z + + + Eric Voskuil + 2022-06-21T20:10:00.000Z + + + Peter Todd + 2022-06-23T19:17:00.000Z + + + Billy Tetrud + 2022-06-28T03:55:00.000Z + + + Alex Lee + 2022-06-28T16:23:00.000Z + + + Peter Todd + 2022-06-28T23:20:00.000Z + + + Peter Todd + 2022-06-28T23:22:00.000Z + + + Alex Lee + 2022-06-29T05:02:00.000Z + + + Kate Salazar + 2022-06-29T10:44:00.000Z + + + Billy Tetrud + 2022-06-30T15:25:00.000Z + + + Erik Aronesty + 2022-06-30T17:04:00.000Z + + + Peter Todd + 2022-07-03T09:43:00.000Z + + + Giuseppe B + 2022-07-03T10:30:00.000Z + + + Corey Haddad + 2022-07-06T04:28:00.000Z + + + vjudeu + 2022-07-06T11:10:00.000Z + + + Billy Tetrud + 2022-07-07T00:46:00.000Z + + + vjudeu + 2022-07-07T12:15:00.000Z + + + John Carvalho + 2022-07-07T13:24:00.000Z + + + Erik Aronesty + 2022-07-07T14:05:00.000Z + + + Giuseppe B + 2022-07-07T14:10:00.000Z + + + Peter Todd + 2022-07-07T14:12:00.000Z + + + Eric Voskuil + 2022-07-07T16:24:00.000Z + + + Erik Aronesty + 2022-07-07T17:37:00.000Z + + + Eric Voskuil + 2022-07-07T19:57:00.000Z + + + Erik Aronesty + 2022-07-07T21:11:00.000Z + + + Corey Haddad + 2022-07-07T22:02:00.000Z + + + Anthony Towns + 2022-07-07T22:06:00.000Z + + + Eric Voskuil + 2022-07-08T00:28:00.000Z + + + vjudeu + 2022-07-08T04:59:00.000Z + + + Billy Tetrud + 2022-07-08T05:03:00.000Z + + + John Carvalho + 2022-07-08T07:26:00.000Z + + + Erik Aronesty + 2022-07-08T15:14:00.000Z + + + Billy Tetrud + 2022-07-14T04:55:00.000Z + + + Anthony Towns + 2022-07-19T04:44:00.000Z + + + alicexbt + 2022-07-19T14:46:00.000Z + + @@ -223,13 +281,13 @@ - python-feedgen + 2 Combined summary - Bitcoin covenants are inevitable - 2023-08-02T06:40:26.386442+00:00 + 2025-09-26T14:31:40.042072+00:00 - The recent discussions among Bitcoin developers have focused on several key topics, including the implementation of covenants, the optimal amount of security needed for Bitcoin, the relationship between block size and fees, and the overall security of the network.There is a debate surrounding the use of covenants in Bitcoin, with concerns about potential risks to fungibility and transaction freedom. Covenants would involve adding temporary conditions to coins while they remain in the owner's possession. The term 'transaction introspection' has been suggested as an alternative to 'covenants'. Opinions differ on whether soft forks should be allowed for covenants, as the risk of losing coins and compromising fungibility and transaction freedom may outweigh any benefits.Discussions also revolve around the optimal amount of security needed for Bitcoin. The present level of security is approximately 1.7% of the total coin supply per year. There are differing opinions on whether lower confirmation rates lead to higher fees or better security. Reducing the block size could potentially increase total fees collected by miners. Market forces and economic shifts play a significant role in determining security. The impact of zero-size blocks on fees and security is also explored.The relationship between confirmation rates, fees, and security in Bitcoin transactions is another topic of debate. Lower confirmation rates are argued to result in higher fees, while others believe that the present level of security is sufficient. Block size reduction can enhance security in terms of validation and fees. Increasing demand is crucial for increasing double spend security and censorship resistance.The discussions also address the relationship between block size and fees, as well as the security of the network. Lowering the block size can prevent double-spending attacks and reduce the burden on node operators. Economic forces are considered to provide security, and the current amount of security appears to be sufficient. Finding the optimal level of security is challenging, and various options are discussed to address this issue.The distribution of costs associated with Bitcoin's security is another point of discussion. There are proposals to reduce block size, violate the 21 million coin limit, or rely on merged mining to pay for security. The importance of finding a balance between security and cost-effectiveness is emphasized.The discussions also touch on various options for paying for Bitcoin's security, including the possibility of burning Bitcoin. The finite supply of Bitcoin is acknowledged as a significant factor, but it is recognized that other forms of cryptographic security must work together to make Bitcoin useful.Overall, the discussions highlight the ongoing debate within the Bitcoin community about how to ensure the security and sustainability of the network. There is a need for ongoing dialogue and consensus building to address these issues effectively.In the context of Bitcoin and its potential for consensus, there is a preference among some individuals for BIP 8 or an improved version of it as a means of implementing soft forks. However, they are also open to any solutions that can enhance the functionality and performance of Bitcoin. One proposal that has been put forward is the implementation of covenants before the next cycle. This approach would create opportunities for developers to build innovative applications and features during bear markets, thereby diversifying the capabilities of Bitcoin.It is important to note that the introduction of CTV (Check Template Verify) is not being rushed as a soft fork. Unlike other soft forks, which often garnered significant attention on social media from respected developers, CTV's research did not receive the same level of publicity. This suggests that the development and adoption of CTV have proceeded with less fanfare and potentially fewer followers.The author believes that we should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits. They prefer BIP 8 or improved BIP 8 for soft fork but won't mind anything else being used if that improves Bitcoin.Apart from the technical merits, covenants will improve various aspects such as developers building interesting projects with real demand in the market, students learning Sapio, and better tooling being available for application developers. There may also be an increase in demand for block space and funding of Bitcoin developers and projects.Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics, etc. on social media, but there are zero technical NACKs for CTV. All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general.Overall, the desire for consensus and improvements in Bitcoin drives the consideration of BIP 8 or an enhanced version thereof. Implementing covenants could foster innovation during bear markets, while the measured approach to CTV's adoption highlights the importance of thorough research and evaluation. 2022-07-19T14:46:46+00:00 + The recent discussions among Bitcoin developers have focused on several key topics, including the implementation of covenants, the optimal amount of security needed for Bitcoin, the relationship between block size and fees, and the overall security of the network.There is a debate surrounding the use of covenants in Bitcoin, with concerns about potential risks to fungibility and transaction freedom. Covenants would involve adding temporary conditions to coins while they remain in the owner's possession. The term 'transaction introspection' has been suggested as an alternative to 'covenants'. Opinions differ on whether soft forks should be allowed for covenants, as the risk of losing coins and compromising fungibility and transaction freedom may outweigh any benefits.Discussions also revolve around the optimal amount of security needed for Bitcoin. The present level of security is approximately 1.7% of the total coin supply per year. There are differing opinions on whether lower confirmation rates lead to higher fees or better security. Reducing the block size could potentially increase total fees collected by miners. Market forces and economic shifts play a significant role in determining security. The impact of zero-size blocks on fees and security is also explored.The relationship between confirmation rates, fees, and security in Bitcoin transactions is another topic of debate. Lower confirmation rates are argued to result in higher fees, while others believe that the present level of security is sufficient. Block size reduction can enhance security in terms of validation and fees. Increasing demand is crucial for increasing double spend security and censorship resistance.The discussions also address the relationship between block size and fees, as well as the security of the network. Lowering the block size can prevent double-spending attacks and reduce the burden on node operators. Economic forces are considered to provide security, and the current amount of security appears to be sufficient. Finding the optimal level of security is challenging, and various options are discussed to address this issue.The distribution of costs associated with Bitcoin's security is another point of discussion. There are proposals to reduce block size, violate the 21 million coin limit, or rely on merged mining to pay for security. The importance of finding a balance between security and cost-effectiveness is emphasized.The discussions also touch on various options for paying for Bitcoin's security, including the possibility of burning Bitcoin. The finite supply of Bitcoin is acknowledged as a significant factor, but it is recognized that other forms of cryptographic security must work together to make Bitcoin useful.Overall, the discussions highlight the ongoing debate within the Bitcoin community about how to ensure the security and sustainability of the network. There is a need for ongoing dialogue and consensus building to address these issues effectively.In the context of Bitcoin and its potential for consensus, there is a preference among some individuals for BIP 8 or an improved version of it as a means of implementing soft forks. However, they are also open to any solutions that can enhance the functionality and performance of Bitcoin. One proposal that has been put forward is the implementation of covenants before the next cycle. This approach would create opportunities for developers to build innovative applications and features during bear markets, thereby diversifying the capabilities of Bitcoin.It is important to note that the introduction of CTV (Check Template Verify) is not being rushed as a soft fork. Unlike other soft forks, which often garnered significant attention on social media from respected developers, CTV's research did not receive the same level of publicity. This suggests that the development and adoption of CTV have proceeded with less fanfare and potentially fewer followers.The author believes that we should improve the review process for soft fork BIPs and share honest opinions with agreement, disagreement on technical merits. They prefer BIP 8 or improved BIP 8 for soft fork but won't mind anything else being used if that improves Bitcoin.Apart from the technical merits, covenants will improve various aspects such as developers building interesting projects with real demand in the market, students learning Sapio, and better tooling being available for application developers. There may also be an increase in demand for block space and funding of Bitcoin developers and projects.Some people may write paragraphs about CTV being contentious, spread misinformation and do all types of drama, politics, etc. on social media, but there are zero technical NACKs for CTV. All the developers that participated in the discussion are either okay with CTV or OP_TX or covenants in general.Overall, the desire for consensus and improvements in Bitcoin drives the consideration of BIP 8 or an enhanced version thereof. Implementing covenants could foster innovation during bear markets, while the measured approach to CTV's adoption highlights the importance of thorough research and evaluation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_MuSig2-BIP.xml b/static/bitcoin-dev/June_2022/combined_MuSig2-BIP.xml index 74cf7342a4..34d3fc922d 100644 --- a/static/bitcoin-dev/June_2022/combined_MuSig2-BIP.xml +++ b/static/bitcoin-dev/June_2022/combined_MuSig2-BIP.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 - - Jonas Nick 2022-11-03 14:43:22+00:00 - - - Jonas Nick 2022-10-11 15:34:23+00:00 - - - Jonas Nick 2022-10-03 20:41:08+00:00 - - - AdamISZ 2022-06-12 23:07:08+00:00 - - - AdamISZ 2022-05-26 17:34:47+00:00 - - - Jonas Nick 2022-05-26 15:32:33+00:00 - - - AdamISZ 2022-05-24 19:06:41+00:00 - - - AdamISZ 2022-05-23 22:09:52+00:00 - - - Jonas Nick 2022-05-23 15:56:54+00:00 - - - AdamISZ 2022-05-22 22:26:08+00:00 - - - Jonas Nick 2022-04-28 19:18:34+00:00 - - - Brandon Black 2022-04-28 15:33:42+00:00 - - - Olaoluwa Osuntokun 2022-04-28 03:53:59+00:00 - - - Olaoluwa Osuntokun 2022-04-28 01:47:33+00:00 - - - Jonas Nick 2022-04-05 22:57:13+00:00 - + 2025-09-26T14:31:31.439703+00:00 + python-feedgen + + + [bitcoin-dev] MuSig2 BIP Jonas Nick + 2022-04-05T22:57:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T01:47:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T03:53:00.000Z + + + Brandon Black + 2022-04-28T15:33:00.000Z + + + Jonas Nick + 2022-04-28T19:18:00.000Z + + + AdamISZ + 2022-05-22T22:26:00.000Z + + + Jonas Nick + 2022-05-23T15:56:00.000Z + + + AdamISZ + 2022-05-23T22:09:00.000Z + + + AdamISZ + 2022-05-24T19:06:00.000Z + + + Jonas Nick + 2022-05-26T15:32:00.000Z + + + AdamISZ + 2022-05-26T17:34:00.000Z + + + AdamISZ + 2022-06-12T23:07:00.000Z + + + Jonas Nick + 2022-10-03T20:41:00.000Z + + + Jonas Nick + 2022-10-11T15:34:00.000Z + + + Jonas Nick + 2022-11-03T14:43:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 + 2025-09-26T14:31:31.441561+00:00 - The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary 2022-11-03T14:43:22+00:00 + The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_Package-Relay-Proposal.xml b/static/bitcoin-dev/June_2022/combined_Package-Relay-Proposal.xml index e4d767fcb0..5c88f6a69e 100644 --- a/static/bitcoin-dev/June_2022/combined_Package-Relay-Proposal.xml +++ b/static/bitcoin-dev/June_2022/combined_Package-Relay-Proposal.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Package Relay Proposal - 2023-08-02T06:32:07.153762+00:00 - - Greg Sanders 2023-05-10 15:42:34+00:00 - - - Tom Trevethan 2023-05-10 15:12:04+00:00 - - - Gloria Zhao 2022-11-01 18:03:22+00:00 - - - Antoine Riard 2022-06-17 20:08:36+00:00 - - - Gloria Zhao 2022-06-14 09:59:23+00:00 - - - Suhas Daftuar 2022-06-08 15:59:03+00:00 - - - Gloria Zhao 2022-06-07 17:44:45+00:00 - - - Gloria Zhao 2022-05-28 01:54:13+00:00 - - - eric at voskuil.org 2022-05-26 02:59:01+00:00 - - - eric at voskuil.org 2022-05-25 20:52:07+00:00 - - - Anthony Towns 2022-05-25 18:55:35+00:00 - - - Eric Voskuil 2022-05-24 23:43:57+00:00 - - - Gloria Zhao 2022-05-24 21:05:35+00:00 - - - Anthony Towns 2022-05-24 19:48:02+00:00 - - - Gloria Zhao 2022-05-24 01:13:43+00:00 - - - Anthony Towns 2022-05-23 21:34:16+00:00 - - - Gloria Zhao 2022-05-18 18:40:58+00:00 - - - Anthony Towns 2022-05-18 00:35:31+00:00 - - - Gloria Zhao 2022-05-17 20:45:42+00:00 - - - Greg Sanders 2022-05-17 17:56:40+00:00 - - - Gloria Zhao 2022-05-17 16:01:04+00:00 - + 2025-09-26T14:31:46.527635+00:00 + python-feedgen + + + [bitcoin-dev] Package Relay Proposal Gloria Zhao + 2022-05-17T16:01:00.000Z + + + Greg Sanders + 2022-05-17T17:56:00.000Z + + + Gloria Zhao + 2022-05-17T20:45:00.000Z + + + Anthony Towns + 2022-05-18T00:35:00.000Z + + + Gloria Zhao + 2022-05-18T18:40:00.000Z + + + Anthony Towns + 2022-05-23T21:34:00.000Z + + + Gloria Zhao + 2022-05-24T01:13:00.000Z + + + Anthony Towns + 2022-05-24T19:48:00.000Z + + + Gloria Zhao + 2022-05-24T21:05:00.000Z + + + Eric Voskuil + 2022-05-24T23:43:00.000Z + + + Anthony Towns + 2022-05-25T18:55:00.000Z + + + eric + 2022-05-25T20:52:00.000Z + + + eric + 2022-05-26T02:59:00.000Z + + + Gloria Zhao + 2022-05-28T01:54:00.000Z + + + Gloria Zhao + 2022-06-07T17:44:00.000Z + + + Suhas Daftuar + 2022-06-08T15:59:00.000Z + + + Gloria Zhao + 2022-06-14T09:59:00.000Z + + + Antoine Riard + 2022-06-17T20:08:00.000Z + + + Gloria Zhao + 2022-11-01T18:03:00.000Z + + + [bitcoin-dev] Package Relay Proposal Tom Trevethan + 2023-05-10T15:12:00.000Z + + + Greg Sanders + 2023-05-10T15:42:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Package Relay Proposal - 2023-08-02T06:32:07.153762+00:00 + 2025-09-26T14:31:46.529927+00:00 - The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids. Different perspectives are presented, highlighting the tradeoffs and considerations involved in implementing package relay in the Bitcoin protocol.A proposal has been made by Bitcoin Core developer Gloria Zhao to implement a 2023-05-10T15:42:34+00:00 + The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids. Different perspectives are presented, highlighting the tradeoffs and considerations involved in implementing package relay in the Bitcoin protocol.A proposal has been made by Bitcoin Core developer Gloria Zhao to implement a - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml index b85393ef37..a7256419d8 100644 --- a/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Packaged Transaction Relay - 2023-08-02T06:45:04.464151+00:00 + 2025-09-26T14:31:37.851598+00:00 + python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Packaged Transaction Relay - 2023-08-02T06:45:04.465148+00:00 + 2025-09-26T14:31:37.851752+00:00 - The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. 2022-10-10T22:05:38+00:00 + The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml b/static/bitcoin-dev/June_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml index afcc19e10e..e47524bdcb 100644 --- a/static/bitcoin-dev/June_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml +++ b/static/bitcoin-dev/June_2022/combined_Playing-with-full-rbf-peers-for-fun-and-L2s-security.xml @@ -1,89 +1,119 @@ - + 2 Combined summary - Playing with full-rbf peers for fun and L2s security - 2023-08-02T06:48:58.631630+00:00 - - Antoine Riard 2022-08-24 01:56:14+00:00 - - - Antoine Riard 2022-07-09 15:06:43+00:00 - - - alicexbt 2022-07-08 19:44:24+00:00 - - - Greg Sanders 2022-07-08 15:09:33+00:00 - - - Peter Todd 2022-07-08 14:53:13+00:00 - - - alicexbt 2022-07-05 20:46:51+00:00 - - - Peter Todd 2022-06-27 13:46:46+00:00 - - - Greg Sanders 2022-06-27 12:03:38+00:00 - - - Peter Todd 2022-06-27 00:43:35+00:00 - - - alicexbt 2022-06-26 16:40:24+00:00 - - - Peter Todd 2022-06-23 19:13:47+00:00 - - - Antoine Riard 2022-06-21 23:45:48+00:00 - - - Antoine Riard 2022-06-21 23:43:23+00:00 - - - Peter Todd 2022-06-20 23:49:55+00:00 - - - Peter Todd 2022-06-19 10:42:15+00:00 - - - alicexbt 2022-06-17 04:54:11+00:00 - - - Antoine Riard 2022-06-17 01:34:17+00:00 - - - Greg Sanders 2022-06-16 13:24:03+00:00 - - - alicexbt 2022-06-16 12:47:15+00:00 - - - linuxfoundation.cndm1 at dralias.com 2022-06-16 05:43:33+00:00 - - - alicexbt 2022-06-16 01:45:42+00:00 - - - Greg Sanders 2022-06-16 01:02:39+00:00 - - - alicexbt 2022-06-16 00:16:52+00:00 - - - Peter Todd 2022-06-15 03:18:33+00:00 - - - Luke Dashjr 2022-06-15 02:53:58+00:00 - - - Peter Todd 2022-06-15 02:27:20+00:00 - - - Antoine Riard 2022-06-14 00:25:11+00:00 - + 2025-09-26T14:31:29.287382+00:00 + python-feedgen + + + [bitcoin-dev] Playing with full-rbf peers for fun and L2s security Antoine Riard + 2022-06-14T00:25:00.000Z + + + Peter Todd + 2022-06-15T02:27:00.000Z + + + Luke Dashjr + 2022-06-15T02:53:00.000Z + + + Peter Todd + 2022-06-15T03:18:00.000Z + + + alicexbt + 2022-06-16T00:16:00.000Z + + + Greg Sanders + 2022-06-16T01:02:00.000Z + + + alicexbt + 2022-06-16T01:45:00.000Z + + + linuxfoundation.cndm1 + 2022-06-16T05:43:00.000Z + + + alicexbt + 2022-06-16T12:47:00.000Z + + + Greg Sanders + 2022-06-16T13:24:00.000Z + + + Antoine Riard + 2022-06-17T01:34:00.000Z + + + alicexbt + 2022-06-17T04:54:00.000Z + + + Peter Todd + 2022-06-19T10:42:00.000Z + + + Peter Todd + 2022-06-20T23:49:00.000Z + + + Antoine Riard + 2022-06-21T23:43:00.000Z + + + Antoine Riard + 2022-06-21T23:45:00.000Z + + + Peter Todd + 2022-06-23T19:13:00.000Z + + + alicexbt + 2022-06-26T16:40:00.000Z + + + Peter Todd + 2022-06-27T00:43:00.000Z + + + Greg Sanders + 2022-06-27T12:03:00.000Z + + + Peter Todd + 2022-06-27T13:46:00.000Z + + + alicexbt + 2022-07-05T20:46:00.000Z + + + Peter Todd + 2022-07-08T14:53:00.000Z + + + Greg Sanders + 2022-07-08T15:09:00.000Z + + + alicexbt + 2022-07-08T19:44:00.000Z + + + Antoine Riard + 2022-07-09T15:06:00.000Z + + + Antoine Riard + 2022-08-24T01:56:00.000Z + + @@ -111,13 +141,13 @@ - python-feedgen + 2 Combined summary - Playing with full-rbf peers for fun and L2s security - 2023-08-02T06:48:58.631630+00:00 + 2025-09-26T14:31:29.290441+00:00 - The conversation discussed the vulnerability of open, p2p coinjoin services to DoS attacks. It was noted that attackers can disrupt rounds by failing to complete them or launching double-spend attacks. Mitigating these types of attacks is crucial to prevent malicious coinjoin service providers from outlawing competition. Punishing attackers in the case of failed relay transactions during coinjoin rounds is also challenging. The implementation of full-rbf as a policy in Bitcoin Core was proposed as a potential solution to improve the security and reliability of multi-party funded transactions. However, there are ongoing discussions and disagreements regarding the approach and its impact.Another proposal shared on GitHub aims to enable trustless DLCs on Bitcoin using dual-funded channels with Lightning Network-style HTLCs. This would provide a more secure and scalable solution for off-chain contracts. Antoine Riard suggests that users should be able to manage their LN usage by using better ISPs or adopting different mempool policies. Documentation was highlighted as important in helping users understand and navigate the complexities of RBF policies and mempool DoS vectors. Community engagement and collaboration are emphasized as necessary to advance the state of policy options in Bitcoin Core.The Lightning dual-funded channel proposal aims to increase the efficiency and usability of the Lightning network by allowing users to easily create secure and decentralized channels. The fund allocation and transaction signing process is outlined in the proposal. It has been shared on the bitcoin-dev mailing list where developers discuss technical aspects of Bitcoin.There have been discussions about the lack of basic options in Bitcoin Core for enabling/disabling different RBF policies. The implementation of full-RBF in Bitcoin Core is questioned, and the author suggests providing basic RBF policy options instead of removing the ability to disable certain policies. Antoine Riard proposes fixing the security vulnerabilities in multi-party funded transactions by enabling full-RBF as a policy in Bitcoin Core. He has submitted a patch for review and invites node operators to test full-RBF. Concerns about the impact of full-RBF on vulnerable projects and the lack of consensus among nodes and miners are raised. Some suggest using alternative implementations like Bitcoin Knots, which already has an option to disable all RBF policies. However, proponents argue that full-RBF is a simple and incentive-compatible step towards more robust layer two systems. Peter Todd suggests a similar approach to full-RBF but notes that he hasn't worked on the Bitcoin Core codebase in years.In summary, ongoing discussions revolve around the implementation of full-RBF in Bitcoin Core and its impact on multi-party funded transactions. The Lightning dual-funded channel proposal aims to improve the efficiency and usability of the Lightning network. Developers are encouraged to provide basic RBF policy options, and alternative implementations like Bitcoin Knots already offer these options. Node operators and mining operators can experiment with full-RBF to test its benefits and drawbacks. 2022-08-24T01:56:14+00:00 + The conversation discussed the vulnerability of open, p2p coinjoin services to DoS attacks. It was noted that attackers can disrupt rounds by failing to complete them or launching double-spend attacks. Mitigating these types of attacks is crucial to prevent malicious coinjoin service providers from outlawing competition. Punishing attackers in the case of failed relay transactions during coinjoin rounds is also challenging. The implementation of full-rbf as a policy in Bitcoin Core was proposed as a potential solution to improve the security and reliability of multi-party funded transactions. However, there are ongoing discussions and disagreements regarding the approach and its impact.Another proposal shared on GitHub aims to enable trustless DLCs on Bitcoin using dual-funded channels with Lightning Network-style HTLCs. This would provide a more secure and scalable solution for off-chain contracts. Antoine Riard suggests that users should be able to manage their LN usage by using better ISPs or adopting different mempool policies. Documentation was highlighted as important in helping users understand and navigate the complexities of RBF policies and mempool DoS vectors. Community engagement and collaboration are emphasized as necessary to advance the state of policy options in Bitcoin Core.The Lightning dual-funded channel proposal aims to increase the efficiency and usability of the Lightning network by allowing users to easily create secure and decentralized channels. The fund allocation and transaction signing process is outlined in the proposal. It has been shared on the bitcoin-dev mailing list where developers discuss technical aspects of Bitcoin.There have been discussions about the lack of basic options in Bitcoin Core for enabling/disabling different RBF policies. The implementation of full-RBF in Bitcoin Core is questioned, and the author suggests providing basic RBF policy options instead of removing the ability to disable certain policies. Antoine Riard proposes fixing the security vulnerabilities in multi-party funded transactions by enabling full-RBF as a policy in Bitcoin Core. He has submitted a patch for review and invites node operators to test full-RBF. Concerns about the impact of full-RBF on vulnerable projects and the lack of consensus among nodes and miners are raised. Some suggest using alternative implementations like Bitcoin Knots, which already has an option to disable all RBF policies. However, proponents argue that full-RBF is a simple and incentive-compatible step towards more robust layer two systems. Peter Todd suggests a similar approach to full-RBF but notes that he hasn't worked on the Bitcoin Core codebase in years.In summary, ongoing discussions revolve around the implementation of full-RBF in Bitcoin Core and its impact on multi-party funded transactions. The Lightning dual-funded channel proposal aims to improve the efficiency and usability of the Lightning network. Developers are encouraged to provide basic RBF policy options, and alternative implementations like Bitcoin Knots already offer these options. Node operators and mining operators can experiment with full-RBF to test its benefits and drawbacks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_RIDDLE-Lightweight-anti-Sybil-with-anonymity-in-Bitcoin.xml b/static/bitcoin-dev/June_2022/combined_RIDDLE-Lightweight-anti-Sybil-with-anonymity-in-Bitcoin.xml index 53cc5f57dc..44023b0000 100644 --- a/static/bitcoin-dev/June_2022/combined_RIDDLE-Lightweight-anti-Sybil-with-anonymity-in-Bitcoin.xml +++ b/static/bitcoin-dev/June_2022/combined_RIDDLE-Lightweight-anti-Sybil-with-anonymity-in-Bitcoin.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - RIDDLE: Lightweight anti-Sybil with anonymity in Bitcoin - 2023-08-02T06:47:46.725260+00:00 - - AdamISZ 2022-08-11 15:31:48+00:00 - - - AdamISZ 2022-06-30 21:50:20+00:00 - - - AdamISZ 2022-06-12 23:04:47+00:00 - + 2025-09-26T14:31:20.721892+00:00 + python-feedgen + + + [bitcoin-dev] RIDDLE: Lightweight anti-Sybil with anonymity in Bitcoin AdamISZ + 2022-06-12T23:04:00.000Z + + + AdamISZ + 2022-06-30T21:50:00.000Z + + + AdamISZ + 2022-08-11T15:31:00.000Z + + - python-feedgen + 2 Combined summary - RIDDLE: Lightweight anti-Sybil with anonymity in Bitcoin - 2023-08-02T06:47:46.725260+00:00 + 2025-09-26T14:31:20.722513+00:00 - Recently, there has been a lot of study on sublinear ring signatures. Groth/Kohlweiss 2014 introduced logarithmic scaled ring signatures, which can be achieved using taproot keys. AdamISZ wrote a blog post discussing the creation of logarithmic sized ring signatures on taproot keys [1]. However, a question remained regarding how to achieve one/N time usage of these ring signatures with key images.Noether & Goodall's Triptych [3] offers a solution to this issue. It builds on the core idea presented in the GK paper [2], which involves bit decomposition of index. In 2015, Bootle et al. published "Short Accountable Ring Signatures Based on DDH" [4], where they further generalized the concept by introducing n-ary decomposition and delta-functions to identify the index with the correct digits in n-ary.In 2020, Triptych was introduced as a combination of the above concepts along with the inclusion of a key image, similar to the basic cryptonote, LWW, LSAG design. According to Bootle et al., their construction is "2.8 times smaller" than the GK design [2]. Although adding the key image requires more space in the proof, it is still significantly compact compared to other designs. Thus, Triptych [3] offers both a key image and a compact size for high anonymity sets.The research indicates that Triptych [3] appears to be practical for genuinely big anonymity sets. Although it may be possible to achieve even more efficient constructions through bilinear pairings crypto, this method would not work on 'bare' secp256k1. However, there might be a way to transfer over to other curves via bilinear pairings crypto.AdamISZ also shared a suggested protocol for anti-Sybil measures that aims to maintain privacy without being too demanding for users. While the protocol primarily focuses on users or customers of websites or services, it could also be applicable in anti-Sybil measures for things like Lightning.The post includes various sections that can be explored through the provided link. It is worth noting that the original gist was migrated due to issues with GitHub's equation formatting feature, but comments are still available on the gist or on a linked post.The post was signed by waxwing/AdamISZ and sent using Proton Mail secure email. 2022-08-11T15:31:48+00:00 + Recently, there has been a lot of study on sublinear ring signatures. Groth/Kohlweiss 2014 introduced logarithmic scaled ring signatures, which can be achieved using taproot keys. AdamISZ wrote a blog post discussing the creation of logarithmic sized ring signatures on taproot keys [1]. However, a question remained regarding how to achieve one/N time usage of these ring signatures with key images.Noether & Goodall's Triptych [3] offers a solution to this issue. It builds on the core idea presented in the GK paper [2], which involves bit decomposition of index. In 2015, Bootle et al. published "Short Accountable Ring Signatures Based on DDH" [4], where they further generalized the concept by introducing n-ary decomposition and delta-functions to identify the index with the correct digits in n-ary.In 2020, Triptych was introduced as a combination of the above concepts along with the inclusion of a key image, similar to the basic cryptonote, LWW, LSAG design. According to Bootle et al., their construction is "2.8 times smaller" than the GK design [2]. Although adding the key image requires more space in the proof, it is still significantly compact compared to other designs. Thus, Triptych [3] offers both a key image and a compact size for high anonymity sets.The research indicates that Triptych [3] appears to be practical for genuinely big anonymity sets. Although it may be possible to achieve even more efficient constructions through bilinear pairings crypto, this method would not work on 'bare' secp256k1. However, there might be a way to transfer over to other curves via bilinear pairings crypto.AdamISZ also shared a suggested protocol for anti-Sybil measures that aims to maintain privacy without being too demanding for users. While the protocol primarily focuses on users or customers of websites or services, it could also be applicable in anti-Sybil measures for things like Lightning.The post includes various sections that can be explored through the provided link. It is worth noting that the original gist was migrated due to issues with GitHub's equation formatting feature, but comments are still available on the gist or on a linked post.The post was signed by waxwing/AdamISZ and sent using Proton Mail secure email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_Using-Merged-Mining-on-a-separate-zero-supply-chain-instead-of-sidechains.xml b/static/bitcoin-dev/June_2022/combined_Using-Merged-Mining-on-a-separate-zero-supply-chain-instead-of-sidechains.xml index d5d1b64f8f..18ba43a36c 100644 --- a/static/bitcoin-dev/June_2022/combined_Using-Merged-Mining-on-a-separate-zero-supply-chain-instead-of-sidechains.xml +++ b/static/bitcoin-dev/June_2022/combined_Using-Merged-Mining-on-a-separate-zero-supply-chain-instead-of-sidechains.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Using Merged Mining on a separate zero supply chain, instead of sidechains - 2023-08-02T06:44:06.875698+00:00 - - ZmnSCPxj 2022-06-05 16:37:24+00:00 - - - vjudeu at gazeta.pl 2022-06-04 15:33:43+00:00 - + 2025-09-26T14:31:27.106573+00:00 + python-feedgen + + + [bitcoin-dev] Using Merged Mining on a separate zero supply chain, instead of sidechains vjudeu + 2022-06-04T15:33:00.000Z + + + ZmnSCPxj + 2022-06-05T16:37:00.000Z + + - python-feedgen + 2 Combined summary - Using Merged Mining on a separate zero supply chain, instead of sidechains - 2023-08-02T06:44:06.875698+00:00 + 2025-09-26T14:31:27.107025+00:00 - The article explores the possibility of implementing sidechains in a no-fork manner using transaction joining and homomorphic encryption. The concept involves creating a new chain with zero coins and introducing coins from other chains by signing a transaction. This method allows for the creation of a test network, but to establish independence, the movement of coins within the chain is necessary.To facilitate sidechains, transaction joining can be employed to transform a series of transactions into a single transaction. Additionally, homomorphic encryption, such as Pedersen commitments or ElGamal commitments, can be utilized to encrypt the amount. This encryption technique is similar to how MimbleWimble coins like Grin operate.To prevent the alteration of history, the hash of the chain can be incorporated into the signature within a Bitcoin transaction. This safeguard ensures that the chain's history cannot be overwritten. Furthermore, merged mining offers a potential solution for rewarding sidechain miners.In summary, by combining transaction joining, homomorphic encryption, and the use of the Bitcoin blockchain, it is feasible to introduce sidechains without requiring forks. This approach allows for the integration of new features while preserving consensus and preventing the manipulation of historical data. 2022-06-05T16:37:24+00:00 + The article explores the possibility of implementing sidechains in a no-fork manner using transaction joining and homomorphic encryption. The concept involves creating a new chain with zero coins and introducing coins from other chains by signing a transaction. This method allows for the creation of a test network, but to establish independence, the movement of coins within the chain is necessary.To facilitate sidechains, transaction joining can be employed to transform a series of transactions into a single transaction. Additionally, homomorphic encryption, such as Pedersen commitments or ElGamal commitments, can be utilized to encrypt the amount. This encryption technique is similar to how MimbleWimble coins like Grin operate.To prevent the alteration of history, the hash of the chain can be incorporated into the signature within a Bitcoin transaction. This safeguard ensures that the chain's history cannot be overwritten. Furthermore, merged mining offers a potential solution for rewarding sidechain miners.In summary, by combining transaction joining, homomorphic encryption, and the use of the Bitcoin blockchain, it is feasible to introduce sidechains without requiring forks. This approach allows for the integration of new features while preserving consensus and preventing the manipulation of historical data. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml b/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml index 08278cd261..d666068332 100644 --- a/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml +++ b/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Why OpenTimestamps does not "linearize" its transactions - 2023-08-02T06:52:21.283384+00:00 + Combined summary - Why OpenTimestamps does not "linearize" its transactions + 2025-09-26T14:31:22.878355+00:00 + python-feedgen Peter Todd 2022-06-19 11:04:50+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 - Combined summary - Why OpenTimestamps does not "linearize" its transactions - 2023-08-02T06:52:21.283384+00:00 + Combined summary - Why OpenTimestamps does not "linearize" its transactions + 2025-09-26T14:31:22.878521+00:00 - In a recent email exchange on the bitcoin-dev mailing list, concerns were raised regarding the use of OpenTimestamps (OTS) for timestamping. One user expressed worry about the requirement to publicize .ots files and suggested including more cryptographic information in the original OP_RETURN to eliminate the need for this. However, it was clarified that publication is not actually a part of the OTS system.The discussion also touched upon the issue of security with .ots files when shared with other parties. Without cryptographic pinning, there is a possibility that a fourth party could replace the .ots file, changing the timestamp to a later date and compromising the validity of the data. Additionally, there were concerns about the potential loss of transaction history containing OTS hashes in chain forks.Another user highlighted the limitations of OTS in proving the timing and uniqueness of documents. While OTS can prove the duration of a document, it cannot demonstrate its shortness or whether an earlier version was already published. The user referred to this as the system being "designed to be broken" as it allows individuals to rewrite history by republishing others' documents under different contexts.The conversation also delved into the scalability and efficiency of OTS. It was noted that through the use of merkle trees, OTS can timestamp tens of thousands of messages with a single transaction, making it a more efficient option. However, there were suggestions for additional measures to ensure the security and uniqueness of timestamps, such as publicizing nonces and document hashes with user consent.Overall, the discussions highlighted the complexities and considerations involved in using timestamp services like OpenTimestamps. While they provide valuable information about the existence of content at a given time, there are limitations and security concerns that need to be addressed to ensure the validity and reliability of the timestamps.In the context of proving the existence of a message prior to a certain point in time, linearization is not considered as a viable solution. The focus is on verifying statements about messages rather than timestamp proofs. To address this issue, random beacons provide a solution by offering dual-sided bounds on the creation time of messages. By creating messages that are known to have been created after a specific point in time and with an unpredictable prior, the accuracy of timestamp proofs can be ensured.For use-cases that require day to hour level precision, Bitcoin block hashes serve as an effective random beacon. However, for higher precision absolute time, there are several trusted alternatives available. These include the NIST random beacon and Roughtime, among others.Overall, random beacons offer a way to establish the creation time of messages, allowing for the verification of statements without relying solely on timestamp proofs. Whether using Bitcoin block hashes or other trusted alternatives, random beacons provide a valuable tool for various precision requirements. 2022-06-19T11:04:50+00:00 + In a recent email exchange on the bitcoin-dev mailing list, concerns were raised regarding the use of OpenTimestamps (OTS) for timestamping. One user expressed worry about the requirement to publicize .ots files and suggested including more cryptographic information in the original OP_RETURN to eliminate the need for this. However, it was clarified that publication is not actually a part of the OTS system.The discussion also touched upon the issue of security with .ots files when shared with other parties. Without cryptographic pinning, there is a possibility that a fourth party could replace the .ots file, changing the timestamp to a later date and compromising the validity of the data. Additionally, there were concerns about the potential loss of transaction history containing OTS hashes in chain forks.Another user highlighted the limitations of OTS in proving the timing and uniqueness of documents. While OTS can prove the duration of a document, it cannot demonstrate its shortness or whether an earlier version was already published. The user referred to this as the system being "designed to be broken" as it allows individuals to rewrite history by republishing others' documents under different contexts.The conversation also delved into the scalability and efficiency of OTS. It was noted that through the use of merkle trees, OTS can timestamp tens of thousands of messages with a single transaction, making it a more efficient option. However, there were suggestions for additional measures to ensure the security and uniqueness of timestamps, such as publicizing nonces and document hashes with user consent.Overall, the discussions highlighted the complexities and considerations involved in using timestamp services like OpenTimestamps. While they provide valuable information about the existence of content at a given time, there are limitations and security concerns that need to be addressed to ensure the validity and reliability of the timestamps.In the context of proving the existence of a message prior to a certain point in time, linearization is not considered as a viable solution. The focus is on verifying statements about messages rather than timestamp proofs. To address this issue, random beacons provide a solution by offering dual-sided bounds on the creation time of messages. By creating messages that are known to have been created after a specific point in time and with an unpredictable prior, the accuracy of timestamp proofs can be ensured.For use-cases that require day to hour level precision, Bitcoin block hashes serve as an effective random beacon. However, for higher precision absolute time, there are several trusted alternatives available. These include the NIST random beacon and Roughtime, among others.Overall, random beacons offer a way to establish the creation time of messages, allowing for the verification of statements without relying solely on timestamp proofs. Whether using Bitcoin block hashes or other trusted alternatives, random beacons provide a valuable tool for various precision requirements. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml b/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml index 4449a35156..64401efb90 100644 --- a/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml +++ b/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-dev Digest, Vol 85, Issue 4 - 2023-08-02T06:44:20.506979+00:00 + 2025-09-26T14:31:44.341548+00:00 + python-feedgen Billy Tetrud 2022-06-15 04:02:38+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - bitcoin-dev Digest, Vol 85, Issue 4 - 2023-08-02T06:44:20.506979+00:00 + 2025-09-26T14:31:44.341711+00:00 - The concept of consensus in Bitcoin involves trust, which is measured using a mechanism called Trust Metric. The Ford Fulkerson Max Flow Algorithm is used to convert an unordered graph of "Trust Declarations" into a Directed Acyclic Graph with weighting to prevent faults. Sybil resistance is achieved by linking pseudo-identities to trusted individuals and requiring a minimum number of Trust Declarations. However, attackers can still pose as trustworthy individuals. Negative Certs were considered but not implemented due to potential harm.Maintaining the system requires discipline and does not incentivize people without risking bribery. Getting people to pay BTC to make declarations of trust is difficult. There was a discussion about whether developers are paid enough in BTC to afford making declarations, and the idea of separating the Declaration from the payment threshold was proposed. This would allow anyone to enter a zero-value transaction with a Declaration of Trust, but independent post-processing would determine inclusion in the Graph Processing.Luke Kenneth Casson Leighton suggests that trust metrics could address misinformation undermining Bitcoin. Trust metrics are similar to the Bitcoin protocol and could benefit the ecosystem. Trust metrics quantify who's trusted among a set of people and can be used to answer questions about Bitcoin. Public declarations of trust and Maximum-Flow Graph analysis help filter out spam. Colluding users farming aliases can game trust metrics, but Sybil resistance can be bolstered by charging fees or requiring proof of funds. Adding trust metrics evaluation to the Bitcoin protocol would help developers evaluate whom to trust for protocol development.AliceXBT discusses misinformation being used to undermine Bitcoin and suggests Trust Metrics as a solution. She mentions advogato.org as a successful experiment in this regard. Public declarations of trust and Maximum-Flow Graph analysis help filter out false information. AliceXBT finds it ironic that trust metric evaluation was not added to the Bitcoin protocol from the start, hindering developers' ability to evaluate whom to trust for protocol development. 2022-06-15T04:02:38+00:00 + The concept of consensus in Bitcoin involves trust, which is measured using a mechanism called Trust Metric. The Ford Fulkerson Max Flow Algorithm is used to convert an unordered graph of "Trust Declarations" into a Directed Acyclic Graph with weighting to prevent faults. Sybil resistance is achieved by linking pseudo-identities to trusted individuals and requiring a minimum number of Trust Declarations. However, attackers can still pose as trustworthy individuals. Negative Certs were considered but not implemented due to potential harm.Maintaining the system requires discipline and does not incentivize people without risking bribery. Getting people to pay BTC to make declarations of trust is difficult. There was a discussion about whether developers are paid enough in BTC to afford making declarations, and the idea of separating the Declaration from the payment threshold was proposed. This would allow anyone to enter a zero-value transaction with a Declaration of Trust, but independent post-processing would determine inclusion in the Graph Processing.Luke Kenneth Casson Leighton suggests that trust metrics could address misinformation undermining Bitcoin. Trust metrics are similar to the Bitcoin protocol and could benefit the ecosystem. Trust metrics quantify who's trusted among a set of people and can be used to answer questions about Bitcoin. Public declarations of trust and Maximum-Flow Graph analysis help filter out spam. Colluding users farming aliases can game trust metrics, but Sybil resistance can be bolstered by charging fees or requiring proof of funds. Adding trust metrics evaluation to the Bitcoin protocol would help developers evaluate whom to trust for protocol development.AliceXBT discusses misinformation being used to undermine Bitcoin and suggests Trust Metrics as a solution. She mentions advogato.org as a successful experiment in this regard. Public declarations of trust and Maximum-Flow Graph analysis help filter out false information. AliceXBT finds it ironic that trust metric evaluation was not added to the Bitcoin protocol from the start, hindering developers' ability to evaluate whom to trust for protocol development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml b/static/bitcoin-dev/June_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml index 03cd9d9193..8f82da466b 100644 --- a/static/bitcoin-dev/June_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml +++ b/static/bitcoin-dev/June_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - Ark: An Alternative Privacy-preserving Second Layer Solution - 2023-08-07T22:25:40.967928+00:00 - - Antoine Riard 2023-08-06 22:43:55+00:00 - - - moonsettler 2023-06-11 09:19:18+00:00 - - - David A. Harding 2023-06-07 18:20:33+00:00 - - - Burak Keceli 2023-06-07 13:30:07+00:00 - - - Ali Sherief 2023-05-28 06:02:58+00:00 - - - David A. Harding 2023-05-27 20:36:47+00:00 - - - Burak Keceli 2023-05-26 11:56:00+00:00 - - - jk_ at op.pl 2023-05-26 07:33:42+00:00 - - - Ali Sherief 2023-05-25 12:12:43+00:00 - - - David A. Harding 2023-05-24 23:02:40+00:00 - - - adiabat 2023-05-24 20:20:35+00:00 - - - Burak Keceli 2023-05-24 07:53:50+00:00 - - - Burak Keceli 2023-05-24 06:28:08+00:00 - - - ZmnSCPxj 2023-05-24 00:45:49+00:00 - - - ZmnSCPxj 2023-05-24 00:40:42+00:00 - - - G. Andrew Stone 2023-05-23 22:06:02+00:00 - - - Burak Keceli 2023-05-23 04:31:24+00:00 - - - ZmnSCPxj 2023-05-22 13:03:00+00:00 - - - Burak Keceli 2023-05-22 07:54:03+00:00 - + 2025-09-26T14:24:02.060900+00:00 + python-feedgen + + + Burak Keceli + 2023-05-22T07:54:00.000Z + + + ZmnSCPxj + 2023-05-22T13:03:00.000Z + + + Burak Keceli + 2023-05-23T04:31:00.000Z + + + G. Andrew Stone + 2023-05-23T22:06:00.000Z + + + ZmnSCPxj + 2023-05-24T00:40:00.000Z + + + ZmnSCPxj + 2023-05-24T00:45:00.000Z + + + Burak Keceli + 2023-05-24T06:28:00.000Z + + + Burak Keceli + 2023-05-24T07:53:00.000Z + + + adiabat + 2023-05-24T20:20:00.000Z + + + David A. Harding + 2023-05-24T23:02:00.000Z + + + Ali Sherief + 2023-05-25T12:12:00.000Z + + + jk_14 + 2023-05-26T07:33:00.000Z + + + Burak Keceli + 2023-05-26T11:56:00.000Z + + + David A. Harding + 2023-05-27T20:36:00.000Z + + + Ali Sherief + 2023-05-28T06:02:00.000Z + + + Burak Keceli + 2023-06-07T13:30:00.000Z + + + David A. Harding + 2023-06-07T18:20:00.000Z + + + [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution moonsettler + 2023-06-11T09:19:00.000Z + + + Antoine Riard + 2023-08-06T22:43:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - Ark: An Alternative Privacy-preserving Second Layer Solution - 2023-08-07T22:25:40.967928+00:00 + 2025-09-26T14:24:02.063215+00:00 - ZmnSCPxj raised concerns about the risks involved in designing a non-custodial Layer 2 payment system, emphasizing the need for thorough code testing before deployment. One risk highlighted is the use of 0-conf transactions, which are considered unsafe due to the potential for double-spending. This applies to both Lightning payments and swap-ins.In the case of Lightning, there is a specific concern when opening a zero-conf channel to receive payments. If the channel is not confirmed before revealing the payment's preimage, the Lightning Service Provider (LSP) can take the sender's money and double-spend on the channel. However, Ark provides an alternative solution using Atomic-Time Locked Contracts (ATLCs). With ATLCs, users can receive and forward payments without waiting for on-chain confirmations. Any attempt at double-spending breaks the entire atomicity, preventing the ASP from redeeming senders' vTXOs if they double-spend recipients' vTXOs.Burak and ZmnSCPxj further discuss risks associated with Lightning payments. They note that ASPs who fail to forward HTLCs after double-spending their pool transaction pose a potential issue known as a footgun. In contrast, Ark allows users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. This distinguishes Ark from swap-ins, where users must wait for on-chain confirmations before revealing their preimage of the HODL invoice to avoid double-spending risks.The email thread also includes a request for a detailed architecture write-up encompassing bitcoin scripts, transactions, and L2 protocols. Burak explains how ASPs may fail to forward Lightning payments on the broader network after being replaced in-mempool transactions. However, forwarding HTLCs before double-spending the pool transaction can prevent this issue. Ark's collaborative nature enables users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. In contrast, swap-ins require users to wait for on-chain confirmations before revealing their preimage of the HODL invoice to prevent funds from being stolen through double-spending by the swap service provider.Ark is introduced as a new second-layer protocol that offers an alternative approach to the Lightning network. It allows users to send and receive funds without liquidity constraints and has a smaller on-chain footprint compared to Lightning. The protocol utilizes virtual UTXOs (vTXOs) that exist off-chain and must be spent within four weeks of receipt. Existing vTXOs are redeemed and new ones created during payment transactions. To enhance anonymity, vTXO values are limited to a specific range. Users can acquire vTXOs from others or lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO through a process called lifting. Ark relies on Ark Service Providers (ASPs) as untrusted intermediaries who provide liquidity and charge fees. ASPs create rapid, blinded coinjoin sessions called pools, allowing users to make payments by registering their vTXOs for spending and recipients' vTXOs. Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction. Payments are credited every five seconds and settled every ten minutes, providing immediate availability without waiting for on-chain confirmations to spend zero-conf vTXOs.For more detailed information about Ark, refer to the website https://arkpill.me/deep-dive. 2023-08-06T22:43:55+00:00 + ZmnSCPxj raised concerns about the risks involved in designing a non-custodial Layer 2 payment system, emphasizing the need for thorough code testing before deployment. One risk highlighted is the use of 0-conf transactions, which are considered unsafe due to the potential for double-spending. This applies to both Lightning payments and swap-ins.In the case of Lightning, there is a specific concern when opening a zero-conf channel to receive payments. If the channel is not confirmed before revealing the payment's preimage, the Lightning Service Provider (LSP) can take the sender's money and double-spend on the channel. However, Ark provides an alternative solution using Atomic-Time Locked Contracts (ATLCs). With ATLCs, users can receive and forward payments without waiting for on-chain confirmations. Any attempt at double-spending breaks the entire atomicity, preventing the ASP from redeeming senders' vTXOs if they double-spend recipients' vTXOs.Burak and ZmnSCPxj further discuss risks associated with Lightning payments. They note that ASPs who fail to forward HTLCs after double-spending their pool transaction pose a potential issue known as a footgun. In contrast, Ark allows users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. This distinguishes Ark from swap-ins, where users must wait for on-chain confirmations before revealing their preimage of the HODL invoice to avoid double-spending risks.The email thread also includes a request for a detailed architecture write-up encompassing bitcoin scripts, transactions, and L2 protocols. Burak explains how ASPs may fail to forward Lightning payments on the broader network after being replaced in-mempool transactions. However, forwarding HTLCs before double-spending the pool transaction can prevent this issue. Ark's collaborative nature enables users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. In contrast, swap-ins require users to wait for on-chain confirmations before revealing their preimage of the HODL invoice to prevent funds from being stolen through double-spending by the swap service provider.Ark is introduced as a new second-layer protocol that offers an alternative approach to the Lightning network. It allows users to send and receive funds without liquidity constraints and has a smaller on-chain footprint compared to Lightning. The protocol utilizes virtual UTXOs (vTXOs) that exist off-chain and must be spent within four weeks of receipt. Existing vTXOs are redeemed and new ones created during payment transactions. To enhance anonymity, vTXO values are limited to a specific range. Users can acquire vTXOs from others or lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO through a process called lifting. Ark relies on Ark Service Providers (ASPs) as untrusted intermediaries who provide liquidity and charge fees. ASPs create rapid, blinded coinjoin sessions called pools, allowing users to make payments by registering their vTXOs for spending and recipients' vTXOs. Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction. Payments are credited every five seconds and settled every ten minutes, providing immediate availability without waiting for on-chain confirmations to spend zero-conf vTXOs.For more detailed information about Ark, refer to the website https://arkpill.me/deep-dive. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_Bitcoin-mail-list-needs-an-explicit-moderation-policy.xml b/static/bitcoin-dev/June_2023/combined_Bitcoin-mail-list-needs-an-explicit-moderation-policy.xml index 51de572467..88033e5504 100644 --- a/static/bitcoin-dev/June_2023/combined_Bitcoin-mail-list-needs-an-explicit-moderation-policy.xml +++ b/static/bitcoin-dev/June_2023/combined_Bitcoin-mail-list-needs-an-explicit-moderation-policy.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Bitcoin mail list needs an explicit moderation policy - 2023-08-02T09:36:37.086319+00:00 - - vjudeu at gazeta.pl 2023-06-12 05:26:32+00:00 - - - alicexbt 2023-06-03 17:21:27+00:00 - - - Bryan Bishop 2023-06-03 00:06:53+00:00 - - - Dr Maxim Orlovsky 2023-06-02 23:43:45+00:00 - + 2025-09-26T14:23:55.689417+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin mail list needs an explicit moderation policy Dr Maxim Orlovsky + 2023-06-02T23:43:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Bryan Bishop + 2023-06-03T00:06:00.000Z + + + [bitcoin-dev] " alicexbt + 2023-06-03T17:21:00.000Z + + + vjudeu + 2023-06-12T05:26:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin mail list needs an explicit moderation policy - 2023-08-02T09:36:37.086319+00:00 + 2025-09-26T14:23:55.690061+00:00 - Dr. Maxim Orlovsky, a long-time contributor to the bitcoin community, has raised concerns about the lack of clear moderation policies on the bitcoin-dev mail list. In an email to the list, Dr. Orlovsky proposed several changes to address these concerns. Firstly, he suggested that a clear peer-review policy should be established and made public after discussion within the mail list. This would ensure transparency and fairness in the moderation process. Secondly, Dr. Orlovsky recommended replacing the current moderator, Bryan Bishop, with someone selected from a list of potential candidates using the criteria of "least votes against." The new moderator's role would be purely executive, without any personal preferences or biases.Furthermore, Dr. Orlovsky proposed the creation of a dedicated mail list called "bitcoin-dev-unmoderated" where all submissions would be published without moderation. This list would be read only by individuals interested in auditing the bitcoin-dev main mail list for non-censorship. To incentivize moderators, Dr. Orlovsky suggested that their reputation should play a key role. This would ensure that moderators are motivated to enforce the policies effectively and fairly.In his email, Dr. Orlovsky provided evidence of the lack of explicit moderation policies and the abuse of power by the current moderator. He referred to the rejection of one of his own posts as an example of censorship, implying that it was based on personal preferences rather than the quality of the content.The email included links to Dr. Orlovsky's previous contributions to the bitcoin community and Twitter conversations that highlighted the need for explicit moderation policies. These tweets also demonstrated the frustration caused by the lack of transparency in the moderation process.In response to Dr. Orlovsky's concerns, Bryan Bishop questioned the allegations of abuse and suggested that the issue may be related to moderation queue latency rather than personal bias. He mentioned asking Dr. Orlovsky to stop tagging him on a particular topic, which may have caused some tension between them.Overall, the email exchange between Dr. Maxim Orlovsky and Bryan Bishop underscores the need for clear moderation policies and unbiased enforcement on the bitcoin-dev mail list. The proposed changes aim to ensure transparency, fairness, and effective discussion among developers in the bitcoin community. 2023-06-12T05:26:32+00:00 + Dr. Maxim Orlovsky, a long-time contributor to the bitcoin community, has raised concerns about the lack of clear moderation policies on the bitcoin-dev mail list. In an email to the list, Dr. Orlovsky proposed several changes to address these concerns. Firstly, he suggested that a clear peer-review policy should be established and made public after discussion within the mail list. This would ensure transparency and fairness in the moderation process. Secondly, Dr. Orlovsky recommended replacing the current moderator, Bryan Bishop, with someone selected from a list of potential candidates using the criteria of "least votes against." The new moderator's role would be purely executive, without any personal preferences or biases.Furthermore, Dr. Orlovsky proposed the creation of a dedicated mail list called "bitcoin-dev-unmoderated" where all submissions would be published without moderation. This list would be read only by individuals interested in auditing the bitcoin-dev main mail list for non-censorship. To incentivize moderators, Dr. Orlovsky suggested that their reputation should play a key role. This would ensure that moderators are motivated to enforce the policies effectively and fairly.In his email, Dr. Orlovsky provided evidence of the lack of explicit moderation policies and the abuse of power by the current moderator. He referred to the rejection of one of his own posts as an example of censorship, implying that it was based on personal preferences rather than the quality of the content.The email included links to Dr. Orlovsky's previous contributions to the bitcoin community and Twitter conversations that highlighted the need for explicit moderation policies. These tweets also demonstrated the frustration caused by the lack of transparency in the moderation process.In response to Dr. Orlovsky's concerns, Bryan Bishop questioned the allegations of abuse and suggested that the issue may be related to moderation queue latency rather than personal bias. He mentioned asking Dr. Orlovsky to stop tagging him on a particular topic, which may have caused some tension between them.Overall, the email exchange between Dr. Maxim Orlovsky and Bryan Bishop underscores the need for clear moderation policies and unbiased enforcement on the bitcoin-dev mail list. The proposed changes aim to ensure transparency, fairness, and effective discussion among developers in the bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml b/static/bitcoin-dev/June_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml index 1eee121526..47a066bd2d 100644 --- a/static/bitcoin-dev/June_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml +++ b/static/bitcoin-dev/June_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Civ Kit: A Peer-to-Peer Electronic Market System - 2023-08-02T09:14:15.352548+00:00 - - Antoine Riard 2023-06-30 03:46:32+00:00 - - - Chris Stewart 2023-05-09 15:09:16+00:00 - - - Antoine Riard 2023-05-01 17:47:46+00:00 - - - Antoine Riard 2023-04-13 14:10:01+00:00 - + 2025-09-26T14:23:44.986206+00:00 + python-feedgen + + + [bitcoin-dev] Civ Kit: A Peer-to-Peer Electronic Market System Antoine Riard + 2023-04-13T14:10:00.000Z + + + Antoine Riard + 2023-05-01T17:47:00.000Z + + + Chris Stewart + 2023-05-09T15:09:00.000Z + + + Antoine Riard + 2023-06-30T03:46:00.000Z + + - python-feedgen + 2 Combined summary - Civ Kit: A Peer-to-Peer Electronic Market System - 2023-08-02T09:14:15.352548+00:00 + 2025-09-26T14:23:44.986876+00:00 - The email thread discusses the concept of front-running in peer-to-peer marketplaces and the concern that bulletin board operators may front-run trades. However, there are security paradigms proposed to mitigate this risk, such as duplicating offers to multiple boards and monitoring latency anomalies. Running bulletin boards as federations with consensus rules is also suggested.The CivKit architecture aims to provide a flexible framework for peer-to-peer marketplaces, adapting to the needs of market participants. It aims to create a censorship-resistant and permissionless global trading system while addressing concerns like front-running. The paper delves into the architecture in detail, combining the Nostr architecture with Lightning onion routing infrastructure. The market boards are Nostr relays with a Lightning gateway, operating autonomously and in competition.The trades are escrowed under Bitcoin Script contracts, relying on moderations and know your peer oracles for adjudication. A consistent incentive framework for service operators is proposed through privacy-preserving credentials backed by Bitcoin payments. The authors plan to release code and modules gradually, leveraging the Lightning Dev Kit and Nostr libraries. They express their enthusiasm for collaborating with the community to standardize libraries and ensure interoperability between clients.The email provides links to various resources including the paper itself, external references like the Lightning Dev Kit and W3C DID Core specification, and the Privacy Pass project. The authors welcome feedback from readers and encourage an interactive dialogue. They provide a mailing list for further discussion and engagement with the Bitcoin development community. 2023-06-30T03:46:32+00:00 + The email thread discusses the concept of front-running in peer-to-peer marketplaces and the concern that bulletin board operators may front-run trades. However, there are security paradigms proposed to mitigate this risk, such as duplicating offers to multiple boards and monitoring latency anomalies. Running bulletin boards as federations with consensus rules is also suggested.The CivKit architecture aims to provide a flexible framework for peer-to-peer marketplaces, adapting to the needs of market participants. It aims to create a censorship-resistant and permissionless global trading system while addressing concerns like front-running. The paper delves into the architecture in detail, combining the Nostr architecture with Lightning onion routing infrastructure. The market boards are Nostr relays with a Lightning gateway, operating autonomously and in competition.The trades are escrowed under Bitcoin Script contracts, relying on moderations and know your peer oracles for adjudication. A consistent incentive framework for service operators is proposed through privacy-preserving credentials backed by Bitcoin payments. The authors plan to release code and modules gradually, leveraging the Lightning Dev Kit and Nostr libraries. They express their enthusiasm for collaborating with the community to standardize libraries and ensure interoperability between clients.The email provides links to various resources including the paper itself, external references like the Lightning Dev Kit and W3C DID Core specification, and the Privacy Pass project. The authors welcome feedback from readers and encourage an interactive dialogue. They provide a mailing list for further discussion and engagement with the Bitcoin development community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_Formosa-proposed-improvement-upon-BIP39.xml b/static/bitcoin-dev/June_2023/combined_Formosa-proposed-improvement-upon-BIP39.xml index 9506f7e185..72a8a15fb4 100644 --- a/static/bitcoin-dev/June_2023/combined_Formosa-proposed-improvement-upon-BIP39.xml +++ b/static/bitcoin-dev/June_2023/combined_Formosa-proposed-improvement-upon-BIP39.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Formosa --- proposed improvement upon BIP39 - 2023-08-02T09:23:27.878283+00:00 - - yurisvb at pm.me 2023-06-05 14:22:04+00:00 - - - yurisvb at pm.me 2023-05-19 23:08:36+00:00 - - - Keagan McClelland 2023-05-19 21:24:45+00:00 - - - yurisvb at pm.me 2023-05-02 08:31:19+00:00 - + 2025-09-26T14:23:57.802018+00:00 + python-feedgen + + + [bitcoin-dev] Formosa --- proposed improvement upon BIP39 yurisvb + 2023-05-02T08:31:00.000Z + + + Keagan McClelland + 2023-05-19T21:24:00.000Z + + + yurisvb + 2023-05-19T23:08:00.000Z + + + yurisvb + 2023-06-05T14:22:00.000Z + + - python-feedgen + 2 Combined summary - Formosa --- proposed improvement upon BIP39 - 2023-08-02T09:23:27.878283+00:00 + 2025-09-26T14:23:57.802776+00:00 - Yuri S Villas Boas has published an article on Toptal's Technology Blog introducing Formosa, a password format that aims to improve upon BIP39. Unlike BIP39, which uses semantically disconnected words for seed phrases, Formosa allows for meaningful, themed sentences with a regular grammatical structure. This system is simple and can be understood by any IT professional in less than 10 minutes. Formosa uses a fixed grammatical structure for sentences, making it easy to implement and customize themes. It also retains important properties of BIP39, such as checksum bits and uniformly high entropy density. This leads to efficient auto-complete and resistance to side-channel attacks. The article also touches on the issue of loss of Bitcoin at a higher rate than it is mined, and how non-technical individuals who adopt Bitcoin can feel emotional pain when they lose their patrimony. Yuri argues that a solution for coercion-resistance should not rely on obscurity. He mentions that we currently lack defenses to coercion that don't violate Kerckhoff's principle by critically relying on obscurity. Yuri plans to make a thread about this critical issue soon.In response to feedback from Keagan McClelland, Yuri explains that Formosa extends BIP39 rather than replacing it. This allows for forwards and backwards compatibility, facilitating adoption. Themes used in Formosa are convertible into one another, and legacy addresses can be kept even if a user chooses a theme. While increased memorability could make $5 wrench attacks more viable, Yuri argues that knowledge-based authentication still has properties that possession-based authentication doesn't. He suggests that mitigating the shortcomings of knowledge-based authentication can be done better with two-factor authentication instead of possession-based authentication.Yuri S VB has proposed a password format as a Bitcoin Improvement Proposal that enhances BIP39. The proposed format allows for meaningful, themed sentences with a regular grammatical structure while maintaining the same entropy/checksum and total bits/non-repeating leading digits ratios. This process aims to extend BIP39 rather than replace it, in order to avoid the need for everyone in the ecosystem to adopt a new standard. The main value proposition of this scheme is significant wallet interoperability. Anecdotal experiments suggest that long-term memorization of 128 + 4 bits (equivalent to the 12 words standard of BIP39) can be achieved in less than one hour with the use of a theme. Users who want to avoid the vulnerability to coercion that an effective brain wallet would entail can take advantage of the easier transcription and checking without memorizing the seed for the long term.Yuri, a developer, has proposed a password format that improves upon BIP39 by allowing meaningful, themed sentences with a regular grammatical structure. This proposal aims to make it easier for users to memorize their seed phrases. The intention is to extend BIP39 rather than replace it, as BIP39 is widely used in the ecosystem. The main benefit of this proposal is significant wallet interoperability. However, there may be concerns about whether the increased memorability of the seed phrases is a good thing, as it could make $5 wrench attacks more viable. There is also a possibility that widespread adoption of this technology could change the ratio of loss versus theft in the Bitcoin ecosystem. The proposal is available on GitHub for further exploration and scrutiny by colleagues. 2023-06-05T14:22:04+00:00 + Yuri S Villas Boas has published an article on Toptal's Technology Blog introducing Formosa, a password format that aims to improve upon BIP39. Unlike BIP39, which uses semantically disconnected words for seed phrases, Formosa allows for meaningful, themed sentences with a regular grammatical structure. This system is simple and can be understood by any IT professional in less than 10 minutes. Formosa uses a fixed grammatical structure for sentences, making it easy to implement and customize themes. It also retains important properties of BIP39, such as checksum bits and uniformly high entropy density. This leads to efficient auto-complete and resistance to side-channel attacks. The article also touches on the issue of loss of Bitcoin at a higher rate than it is mined, and how non-technical individuals who adopt Bitcoin can feel emotional pain when they lose their patrimony. Yuri argues that a solution for coercion-resistance should not rely on obscurity. He mentions that we currently lack defenses to coercion that don't violate Kerckhoff's principle by critically relying on obscurity. Yuri plans to make a thread about this critical issue soon.In response to feedback from Keagan McClelland, Yuri explains that Formosa extends BIP39 rather than replacing it. This allows for forwards and backwards compatibility, facilitating adoption. Themes used in Formosa are convertible into one another, and legacy addresses can be kept even if a user chooses a theme. While increased memorability could make $5 wrench attacks more viable, Yuri argues that knowledge-based authentication still has properties that possession-based authentication doesn't. He suggests that mitigating the shortcomings of knowledge-based authentication can be done better with two-factor authentication instead of possession-based authentication.Yuri S VB has proposed a password format as a Bitcoin Improvement Proposal that enhances BIP39. The proposed format allows for meaningful, themed sentences with a regular grammatical structure while maintaining the same entropy/checksum and total bits/non-repeating leading digits ratios. This process aims to extend BIP39 rather than replace it, in order to avoid the need for everyone in the ecosystem to adopt a new standard. The main value proposition of this scheme is significant wallet interoperability. Anecdotal experiments suggest that long-term memorization of 128 + 4 bits (equivalent to the 12 words standard of BIP39) can be achieved in less than one hour with the use of a theme. Users who want to avoid the vulnerability to coercion that an effective brain wallet would entail can take advantage of the easier transcription and checking without memorizing the seed for the long term.Yuri, a developer, has proposed a password format that improves upon BIP39 by allowing meaningful, themed sentences with a regular grammatical structure. This proposal aims to make it easier for users to memorize their seed phrases. The intention is to extend BIP39 rather than replace it, as BIP39 is widely used in the ecosystem. The main benefit of this proposal is significant wallet interoperability. However, there may be concerns about whether the increased memorability of the seed phrases is a good thing, as it could make $5 wrench attacks more viable. There is also a possibility that widespread adoption of this technology could change the ratio of loss versus theft in the Bitcoin ecosystem. The proposal is available on GitHub for further exploration and scrutiny by colleagues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml b/static/bitcoin-dev/June_2023/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml index 17da6013f8..09363814b9 100644 --- a/static/bitcoin-dev/June_2023/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml +++ b/static/bitcoin-dev/June_2023/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - New transaction policies (nVersion=3) for contracting protocols - 2023-08-02T07:37:32.592526+00:00 - - Greg Sanders 2023-06-21 20:57:45+00:00 - - - Ruben Somsen 2022-10-01 09:59:55+00:00 - - - Greg Sanders 2022-09-30 12:17:38+00:00 - - - Bastien TEINTURIER 2022-09-30 12:08:41+00:00 - - - Ruben Somsen 2022-09-30 00:13:53+00:00 - - - Greg Sanders 2022-09-29 14:41:28+00:00 - - - Bastien TEINTURIER 2022-09-29 09:15:02+00:00 - - - Gloria Zhao 2022-09-26 16:47:49+00:00 - - - Greg Sanders 2022-09-26 16:01:54+00:00 - - - Bastien TEINTURIER 2022-09-26 15:27:40+00:00 - - - Antoine Riard 2022-09-25 23:59:22+00:00 - - - Greg Sanders 2022-09-23 18:48:39+00:00 - - - Gloria Zhao 2022-09-23 15:18:21+00:00 - + 2025-09-26T14:23:42.866485+00:00 + python-feedgen + + + [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols Gloria Zhao + 2022-09-23T15:18:00.000Z + + + Greg Sanders + 2022-09-23T18:48:00.000Z + + + Antoine Riard + 2022-09-25T23:59:00.000Z + + + Bastien TEINTURIER + 2022-09-26T15:27:00.000Z + + + Greg Sanders + 2022-09-26T16:01:00.000Z + + + Gloria Zhao + 2022-09-26T16:47:00.000Z + + + Bastien TEINTURIER + 2022-09-29T09:15:00.000Z + + + Greg Sanders + 2022-09-29T14:41:00.000Z + + + Ruben Somsen + 2022-09-30T00:13:00.000Z + + + Bastien TEINTURIER + 2022-09-30T12:08:00.000Z + + + Greg Sanders + 2022-09-30T12:17:00.000Z + + + Ruben Somsen + 2022-10-01T09:59:00.000Z + + + Greg Sanders + 2023-06-21T20:57:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - New transaction policies (nVersion=3) for contracting protocols - 2023-08-02T07:37:32.592526+00:00 + 2025-09-26T14:23:42.867964+00:00 - Bitcoin developer Gloria Zhao has proposed a new transaction format called V3, which aims to improve replace-by-fee (RBF) and child-pays-for-parent (CPFP) protocols. The proposal includes rules that limit the size and number of descendant transactions, allowing for easier fee-bumping and reducing the need for managing a large UTXO pool. These rules provide flexibility for Layer 2 (L2) protocols while maintaining security and efficiency.Under the proposed rules, a V3 transaction can be replaced even without signaling BIP125 replaceability, as long as it meets other RBF rules. Any descendant of an unconfirmed V3 transaction must also be V3, and an unconfirmed V3 transaction cannot have more than one descendant. Additionally, a V3 transaction with an unconfirmed V3 ancestor cannot exceed 1000 virtual bytes in size.The proposal also discusses the intended usage for Lightning Network (LN) commitment transactions, which should be V3 and have one anchor output. If the commitment transaction needs to be broadcasted, the desired feerate at broadcast time should be determined, and the anchor output should be spent in a high feerate transaction. Multiple commitment transactions can be funded by one child, and to add more fees, the child should be replaced with a higher-feerate transaction.In addition to the V3 transaction format, the Bitcoin development team has proposed a new package relay policy to replace BIP125, the current Replace-by-Fee (RBF) policy. The new policy includes changes to the feerate requirements and ensures that replacement transactions are not less incentive-compatible to mine. It also addresses questions related to Rule 3 Pinning, counterparty's commitment transaction in the mempool, privacy concerns, backward compatibility, and replacing transactions between V2 and V3.The proposed policies aim to improve RBF and CPFP protocols, with specific rules for V3 transactions and modifications to package RBF rules. The changes aim to provide inherited replaceability signaling and prevent pinning attacks. Gloria Zhao has implemented these policies in Bitcoin Core and welcomes feedback from the community. The proposal offers potential benefits for L2/contract protocols and addresses some limitations of previous proposals. Feedback and review of the proposal are encouraged by the development team. 2023-06-21T20:57:45+00:00 + Bitcoin developer Gloria Zhao has proposed a new transaction format called V3, which aims to improve replace-by-fee (RBF) and child-pays-for-parent (CPFP) protocols. The proposal includes rules that limit the size and number of descendant transactions, allowing for easier fee-bumping and reducing the need for managing a large UTXO pool. These rules provide flexibility for Layer 2 (L2) protocols while maintaining security and efficiency.Under the proposed rules, a V3 transaction can be replaced even without signaling BIP125 replaceability, as long as it meets other RBF rules. Any descendant of an unconfirmed V3 transaction must also be V3, and an unconfirmed V3 transaction cannot have more than one descendant. Additionally, a V3 transaction with an unconfirmed V3 ancestor cannot exceed 1000 virtual bytes in size.The proposal also discusses the intended usage for Lightning Network (LN) commitment transactions, which should be V3 and have one anchor output. If the commitment transaction needs to be broadcasted, the desired feerate at broadcast time should be determined, and the anchor output should be spent in a high feerate transaction. Multiple commitment transactions can be funded by one child, and to add more fees, the child should be replaced with a higher-feerate transaction.In addition to the V3 transaction format, the Bitcoin development team has proposed a new package relay policy to replace BIP125, the current Replace-by-Fee (RBF) policy. The new policy includes changes to the feerate requirements and ensures that replacement transactions are not less incentive-compatible to mine. It also addresses questions related to Rule 3 Pinning, counterparty's commitment transaction in the mempool, privacy concerns, backward compatibility, and replacing transactions between V2 and V3.The proposed policies aim to improve RBF and CPFP protocols, with specific rules for V3 transactions and modifications to package RBF rules. The changes aim to provide inherited replaceability signaling and prevent pinning attacks. Gloria Zhao has implemented these policies in Bitcoin Core and welcomes feedback from the community. The proposal offers potential benefits for L2/contract protocols and addresses some limitations of previous proposals. Feedback and review of the proposal are encouraged by the development team. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_Scaling-and-anonymizing-Bitcoin-at-layer-1-with-client-side-validation.xml b/static/bitcoin-dev/June_2023/combined_Scaling-and-anonymizing-Bitcoin-at-layer-1-with-client-side-validation.xml index 4a3f234f26..372887e76e 100644 --- a/static/bitcoin-dev/June_2023/combined_Scaling-and-anonymizing-Bitcoin-at-layer-1-with-client-side-validation.xml +++ b/static/bitcoin-dev/June_2023/combined_Scaling-and-anonymizing-Bitcoin-at-layer-1-with-client-side-validation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Scaling and anonymizing Bitcoin at layer 1 with client-side validation - 2023-08-02T09:31:48.911443+00:00 + 2025-09-26T14:23:47.132446+00:00 + python-feedgen Dr Maxim Orlovsky 2023-06-14 20:14:26+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Scaling and anonymizing Bitcoin at layer 1 with client-side validation - 2023-08-02T09:31:48.911443+00:00 + 2025-09-26T14:23:47.132602+00:00 - Dr. Maxim Orlovsky, in response to comments from Peter, agrees that the section describing the timestamping service should be extended. He clarifies that the term "timestamping" refers to the knowledge of certain facts prior to a specific moment in time. He also explains that the term "timechain" is used as a historical reference. In regards to Peter's claim about scalability, Maxim disagrees and states that the consensus layer only includes headers of fixed size, eliminating the need for sharding. Other data are client-side and shared by network users. Each user tracks and keeps data relevant to their part of the state history. The miners producing headers and PMTs act independently.Maxim acknowledges the data availability problem as the main issue but proposes several solutions. The most promising one involves allowing anyone to witness if a miner hasn't released data from a previous PMT. Miners would then include the missing data in subsequent headers to demonstrate its existence. He suggests adding fees cryptoeconomics, where miners would lose fees if they fail to provide the required data. Maxim confirms that he is proposing a proof-of-publication-based single-use-seal and admits that the smart contract protocol and P2P network structure were not discussed in detail in the paper. However, he agrees with Peter that the exact details of the P2P network are not crucial at this point.On June 1, 2023, Dr. Maxim Orlovsky announced the release of the RGB smart contract system by LNP/BP Standards Association. This system aims to upgrade the Bitcoin layer 1 - blockchain by introducing client-side validation. The proposal, called Prime, offers a scalable and completely anonymous layer 1 that can handle billions of transactions per minute. It doesn't require a softfork or miners upgrade and won't affect users who choose not to upgrade. Lightning Network and other layer 2 systems will become redundant. The white paper for the proposal can be found on GitHub. However, criticisms have been raised regarding the design of the timestamping service and scalability claims.To address these concerns, Maxim suggests reading two papers that provide more details on scalable single-use-seal asset transfer and tree chains. In response to John Tromp's question about Bitcoin Proof of Work (PoW) anchoring, Maxim refers to their paper, which explains the consequences if a miner spends the current miner single-use-seal without proper commitment or sufficient PoW. The issue of PMT availability and consensus among miners is still unclear and requires further discussion.The LNP/BP Standards Association plans to establish a working group for the formal specification and reference implementation of the new layer. They also aim to organize educational and workshop activities. Funding will be raised through non-profit donations, as the infrastructural effort should not be managed by a for-profit company. Interested parties can contact them via email, and for-profit organizations can become members of the Association to contribute to the future development of Bitcoin technologies. 2023-06-14T20:14:26+00:00 + Dr. Maxim Orlovsky, in response to comments from Peter, agrees that the section describing the timestamping service should be extended. He clarifies that the term "timestamping" refers to the knowledge of certain facts prior to a specific moment in time. He also explains that the term "timechain" is used as a historical reference. In regards to Peter's claim about scalability, Maxim disagrees and states that the consensus layer only includes headers of fixed size, eliminating the need for sharding. Other data are client-side and shared by network users. Each user tracks and keeps data relevant to their part of the state history. The miners producing headers and PMTs act independently.Maxim acknowledges the data availability problem as the main issue but proposes several solutions. The most promising one involves allowing anyone to witness if a miner hasn't released data from a previous PMT. Miners would then include the missing data in subsequent headers to demonstrate its existence. He suggests adding fees cryptoeconomics, where miners would lose fees if they fail to provide the required data. Maxim confirms that he is proposing a proof-of-publication-based single-use-seal and admits that the smart contract protocol and P2P network structure were not discussed in detail in the paper. However, he agrees with Peter that the exact details of the P2P network are not crucial at this point.On June 1, 2023, Dr. Maxim Orlovsky announced the release of the RGB smart contract system by LNP/BP Standards Association. This system aims to upgrade the Bitcoin layer 1 - blockchain by introducing client-side validation. The proposal, called Prime, offers a scalable and completely anonymous layer 1 that can handle billions of transactions per minute. It doesn't require a softfork or miners upgrade and won't affect users who choose not to upgrade. Lightning Network and other layer 2 systems will become redundant. The white paper for the proposal can be found on GitHub. However, criticisms have been raised regarding the design of the timestamping service and scalability claims.To address these concerns, Maxim suggests reading two papers that provide more details on scalable single-use-seal asset transfer and tree chains. In response to John Tromp's question about Bitcoin Proof of Work (PoW) anchoring, Maxim refers to their paper, which explains the consequences if a miner spends the current miner single-use-seal without proper commitment or sufficient PoW. The issue of PMT availability and consensus among miners is still unclear and requires further discussion.The LNP/BP Standards Association plans to establish a working group for the formal specification and reference implementation of the new layer. They also aim to organize educational and workshop activities. Funding will be raised through non-profit donations, as the infrastructural effort should not be managed by a for-profit company. Interested parties can contact them via email, and for-profit organizations can become members of the Association to contribute to the future development of Bitcoin technologies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_Standardisation-of-an-unstructured-taproot-annex.xml b/static/bitcoin-dev/June_2023/combined_Standardisation-of-an-unstructured-taproot-annex.xml index 6311769062..a505788445 100644 --- a/static/bitcoin-dev/June_2023/combined_Standardisation-of-an-unstructured-taproot-annex.xml +++ b/static/bitcoin-dev/June_2023/combined_Standardisation-of-an-unstructured-taproot-annex.xml @@ -1,98 +1,131 @@ - + 2 Combined summary - Standardisation of an unstructured taproot annex - 2023-08-02T09:34:03.267700+00:00 - - Antoine Riard 2023-07-04 20:18:23+00:00 - - - Joost Jager 2023-06-20 12:50:47+00:00 - - - Joost Jager 2023-06-20 12:30:19+00:00 - - - Antoine Riard 2023-06-19 01:14:10+00:00 - - - Greg Sanders 2023-06-18 20:40:53+00:00 - - - Antoine Riard 2023-06-18 20:32:12+00:00 - - - Greg Sanders 2023-06-16 13:30:46+00:00 - - - Joost Jager 2023-06-16 11:26:34+00:00 - - - Greg Sanders 2023-06-15 10:39:36+00:00 - - - Joost Jager 2023-06-15 09:36:19+00:00 - - - Joost Jager 2023-06-13 10:38:05+00:00 - - - David A. Harding 2023-06-13 08:51:39+00:00 - - - Greg Sanders 2023-06-12 13:03:47+00:00 - - - Antoine Riard 2023-06-12 03:16:44+00:00 - - - Joost Jager 2023-06-11 19:25:42+00:00 - - - David A. Harding 2023-06-10 22:09:57+00:00 - - - Joost Jager 2023-06-10 07:43:52+00:00 - - - Antoine Riard 2023-06-10 00:23:36+00:00 - - - Joost Jager 2023-06-08 09:16:26+00:00 - - - Peter Todd 2023-06-03 15:50:27+00:00 - - - Joost Jager 2023-06-03 12:55:27+00:00 - - - Greg Sanders 2023-06-03 12:43:38+00:00 - - - Joost Jager 2023-06-03 12:35:51+00:00 - - - Greg Sanders 2023-06-03 12:05:59+00:00 - - - Joost Jager 2023-06-03 09:14:27+00:00 - - - Joost Jager 2023-06-03 08:06:37+00:00 - - - Joost Jager 2023-06-03 07:49:36+00:00 - - - Greg Sanders 2023-06-03 01:14:40+00:00 - - - David A. Harding 2023-06-03 01:08:01+00:00 - - - Joost Jager 2023-06-02 15:00:37+00:00 - + 2025-09-26T14:23:53.571873+00:00 + python-feedgen + + + [bitcoin-dev] Standardisation of an unstructured taproot annex Joost Jager + 2023-06-02T15:00:00.000Z + + + David A. Harding + 2023-06-03T01:08:00.000Z + + + Greg Sanders + 2023-06-03T01:14:00.000Z + + + Joost Jager + 2023-06-03T07:49:00.000Z + + + Joost Jager + 2023-06-03T08:06:00.000Z + + + Joost Jager + 2023-06-03T09:14:00.000Z + + + Greg Sanders + 2023-06-03T12:05:00.000Z + + + Joost Jager + 2023-06-03T12:35:00.000Z + + + Greg Sanders + 2023-06-03T12:43:00.000Z + + + Joost Jager + 2023-06-03T12:55:00.000Z + + + Peter Todd + 2023-06-03T15:50:00.000Z + + + Joost Jager + 2023-06-08T09:16:00.000Z + + + Antoine Riard + 2023-06-10T00:23:00.000Z + + + Joost Jager + 2023-06-10T07:43:00.000Z + + + David A. Harding + 2023-06-10T22:09:00.000Z + + + Joost Jager + 2023-06-11T19:25:00.000Z + + + Antoine Riard + 2023-06-12T03:16:00.000Z + + + Greg Sanders + 2023-06-12T13:03:00.000Z + + + David A. Harding + 2023-06-13T08:51:00.000Z + + + Joost Jager + 2023-06-13T10:38:00.000Z + + + Joost Jager + 2023-06-15T09:36:00.000Z + + + Greg Sanders + 2023-06-15T10:39:00.000Z + + + Joost Jager + 2023-06-16T11:26:00.000Z + + + Greg Sanders + 2023-06-16T13:30:00.000Z + + + Antoine Riard + 2023-06-18T20:32:00.000Z + + + Greg Sanders + 2023-06-18T20:40:00.000Z + + + Antoine Riard + 2023-06-19T01:14:00.000Z + + + Joost Jager + 2023-06-20T12:30:00.000Z + + + Joost Jager + 2023-06-20T12:50:00.000Z + + + Antoine Riard + 2023-07-04T20:18:00.000Z + + @@ -123,13 +156,13 @@ - python-feedgen + 2 Combined summary - Standardisation of an unstructured taproot annex - 2023-08-02T09:34:03.268734+00:00 + 2025-09-26T14:23:53.575203+00:00 - In a recent email exchange, Antoine and Joost discussed the potential benefits of using the annex feature for Bitcoin's time-locked vault applications. Joost emphasized that the annex data is not included in the calculation of transaction IDs, making it a powerful tool for applications that could benefit from covenants. He specifically mentioned time-locked vaults as a critical application that could greatly benefit from the annex.Joost explained that backing up the ephemeral signatures of pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be accessed. However, without the annex, this process is not as safe as it could be. Due to a circular reference problem, the vault creation and signature backup cannot be executed in one atomic operation. This means that if the backup does not confirm, the funds can be lost even if the vault is confirmed.Despite being labeled as speculative, Joost argued that the use case for the annex in time-locked vaults is relevant, especially considering the difficulty of implementing soft forks like OP_VAULT. To support this use case, Joost created a simple demo application that demonstrates how coins can be spent to a special address and later moved to a predefined final destination. The demo uses the annex to store the ephemeral signature of the pre-signed transaction, ensuring that the coin cannot be lost.Joost also highlighted the importance of raising awareness about the on-chain ephemeral signature backup functionality enabled by the annex. He provided a link to his demo application on GitHub, which showcases the potential of the annex for implementing more advanced covenants, such as time-locked vaults.Overall, Joost and Antoine's discussion sheds light on the potential benefits of using the annex for time-locked vault applications and emphasizes the need for further exploration and adoption of the annex feature.In another email exchange between Antoine Riard and Joost, they discuss the concept of an opt-in annex in multi-party transactions. The purpose of this approach is to prevent surprises within multi-party transactions. If someone doesn't commit to an annex, they can be confident that no version of the transaction will appear where another signer includes a potentially large annex. This ensures that existing multi-party protocols remain unaffected.For future protocols that rely on the annex, everyone involved would need to opt-in by committing to an annex. The annex can be empty, serving only as a signal of opting in. The goal is to maintain transparency and avoid unexpected variations in transaction versions.In a separate email thread, Antoine Riard seeks clarification on the topic of opt-in annexes in relation to non-deployed and deployed protocols. Greg Sanders requests a citation for the claim that people should not build protocols meant for production on undeveloped upgrade hooks. Antoine acknowledges that ideally, premature choices should not encumber future development, but mentions that if certain use cases gain economic weight, the coordination cost of deploying a new policy may be prohibitive. In such cases, he suggests implementing sound and "firewalled" signaling and upgrading mechanisms to deploy new policy rules smoothly. Greg seeks further clarification on Antoine's mention of modifying current Taproot support on the Lightning side, specifically regarding the requirement of all P2TR spends to add an annex and commit to it in the BIP341 signature digest. Antoine explains that this would be a mandatory upgrade for Lightning nodes, as failure to do so would disrupt the propagation of `option_taproot` channel transactions. Antoine also discusses the possibility of introducing a TLV record to limit the maximum size/weight of the witness/transaction.The email conversation continues with Joost Jager proposing a restrictive policy for enabling annex-vaults while still aligning with existing work. This policy includes opt-in annexes for every input, the use of TLV format for future extensibility, only allowing unstructured data in tlv record 0 for future extensibility, and limiting the maximum size of the value to 256 bytes to protect opt-in users. Joost highlights the need for a larger limit than the current 126 bytes proposed in a previous pull request, as it would not be sufficient for certain vault configurations. He asks if there are any remaining objections to making the annex standard under these conditions.The discussion revolves around two key points. First, there is a proposal to require every input to commit to an annex, even if it is empty. This could potentially affect the existing multi-party protocols. The concern raised is whether a transaction without the minimal annex, indicated by the 0x50 tag, should be rejected. Implementing this would require modifying current Taproot support on the Lightning side, where all P2TR spends must add an annex and commit to it in the BIP341 signature digest. Failure to upgrade Lightning nodes accordingly would disrupt the propagation of their `option_taproot` channel transactions.Secondly, there is another approach suggested to limit the maximum size or weight of the witness/transaction as a TLV (Type-Length-Value 2023-07-04T20:18:23+00:00 + In a recent email exchange, Antoine and Joost discussed the potential benefits of using the annex feature for Bitcoin's time-locked vault applications. Joost emphasized that the annex data is not included in the calculation of transaction IDs, making it a powerful tool for applications that could benefit from covenants. He specifically mentioned time-locked vaults as a critical application that could greatly benefit from the annex.Joost explained that backing up the ephemeral signatures of pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be accessed. However, without the annex, this process is not as safe as it could be. Due to a circular reference problem, the vault creation and signature backup cannot be executed in one atomic operation. This means that if the backup does not confirm, the funds can be lost even if the vault is confirmed.Despite being labeled as speculative, Joost argued that the use case for the annex in time-locked vaults is relevant, especially considering the difficulty of implementing soft forks like OP_VAULT. To support this use case, Joost created a simple demo application that demonstrates how coins can be spent to a special address and later moved to a predefined final destination. The demo uses the annex to store the ephemeral signature of the pre-signed transaction, ensuring that the coin cannot be lost.Joost also highlighted the importance of raising awareness about the on-chain ephemeral signature backup functionality enabled by the annex. He provided a link to his demo application on GitHub, which showcases the potential of the annex for implementing more advanced covenants, such as time-locked vaults.Overall, Joost and Antoine's discussion sheds light on the potential benefits of using the annex for time-locked vault applications and emphasizes the need for further exploration and adoption of the annex feature.In another email exchange between Antoine Riard and Joost, they discuss the concept of an opt-in annex in multi-party transactions. The purpose of this approach is to prevent surprises within multi-party transactions. If someone doesn't commit to an annex, they can be confident that no version of the transaction will appear where another signer includes a potentially large annex. This ensures that existing multi-party protocols remain unaffected.For future protocols that rely on the annex, everyone involved would need to opt-in by committing to an annex. The annex can be empty, serving only as a signal of opting in. The goal is to maintain transparency and avoid unexpected variations in transaction versions.In a separate email thread, Antoine Riard seeks clarification on the topic of opt-in annexes in relation to non-deployed and deployed protocols. Greg Sanders requests a citation for the claim that people should not build protocols meant for production on undeveloped upgrade hooks. Antoine acknowledges that ideally, premature choices should not encumber future development, but mentions that if certain use cases gain economic weight, the coordination cost of deploying a new policy may be prohibitive. In such cases, he suggests implementing sound and "firewalled" signaling and upgrading mechanisms to deploy new policy rules smoothly. Greg seeks further clarification on Antoine's mention of modifying current Taproot support on the Lightning side, specifically regarding the requirement of all P2TR spends to add an annex and commit to it in the BIP341 signature digest. Antoine explains that this would be a mandatory upgrade for Lightning nodes, as failure to do so would disrupt the propagation of `option_taproot` channel transactions. Antoine also discusses the possibility of introducing a TLV record to limit the maximum size/weight of the witness/transaction.The email conversation continues with Joost Jager proposing a restrictive policy for enabling annex-vaults while still aligning with existing work. This policy includes opt-in annexes for every input, the use of TLV format for future extensibility, only allowing unstructured data in tlv record 0 for future extensibility, and limiting the maximum size of the value to 256 bytes to protect opt-in users. Joost highlights the need for a larger limit than the current 126 bytes proposed in a previous pull request, as it would not be sufficient for certain vault configurations. He asks if there are any remaining objections to making the annex standard under these conditions.The discussion revolves around two key points. First, there is a proposal to require every input to commit to an annex, even if it is empty. This could potentially affect the existing multi-party protocols. The concern raised is whether a transaction without the minimal annex, indicated by the 0x50 tag, should be rejected. Implementing this would require modifying current Taproot support on the Lightning side, where all P2TR spends must add an annex and commit to it in the BIP341 signature digest. Failure to upgrade Lightning nodes accordingly would disrupt the propagation of their `option_taproot` channel transactions.Secondly, there is another approach suggested to limit the maximum size or weight of the witness/transaction as a TLV (Type-Length-Value - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_Vaults-in-the-MATT-framework.xml b/static/bitcoin-dev/June_2023/combined_Vaults-in-the-MATT-framework.xml index 4537d898ff..4ee47ccd10 100644 --- a/static/bitcoin-dev/June_2023/combined_Vaults-in-the-MATT-framework.xml +++ b/static/bitcoin-dev/June_2023/combined_Vaults-in-the-MATT-framework.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Vaults in the MATT framework - 2023-08-02T09:20:10.117249+00:00 - - Johan Torås Halseth 2023-06-02 13:25:39+00:00 - - - Salvatore Ingala 2023-05-02 08:21:01+00:00 - - - Michael Folkson 2023-05-01 14:18:29+00:00 - - - Salvatore Ingala 2023-04-24 19:37:20+00:00 - + 2025-09-26T14:23:51.422470+00:00 + python-feedgen + + + [bitcoin-dev] Vaults in the MATT framework Salvatore Ingala + 2023-04-24T19:37:00.000Z + + + Michael Folkson + 2023-05-01T14:18:00.000Z + + + Salvatore Ingala + 2023-05-02T08:21:00.000Z + + + Johan Torås Halseth + 2023-06-02T13:25:00.000Z + + - python-feedgen + 2 Combined summary - Vaults in the MATT framework - 2023-08-02T09:20:10.117249+00:00 + 2025-09-26T14:23:51.423134+00:00 - Bitcoin developer Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes two new opcodes (OP_CHECKINPUTCONTRACTVERIFY and OP_CHECKOUTPUTCONTRACTVERIFY) that enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data within it. These opcodes enable general smart contracts and fraud proofs. The proposal also discusses Simplicity, a proposal to replace Script with a better language, but notes that it is separate from the discussion on what features should be included in the language.Ingala's proposal for new opcodes allows for the creation and verification of covenant-style contracts. The opcodes can be used to embed data into P2TR output scripts and verify that the correct data is present in subsequent transactions. However, the author suggests adding an opcode like OP_SHA256CAT to allow the data embedding to commit to multiple pieces of data. There is also consideration for extending OP_CHECKOUTPUTCONTRACTVERIFY to apply for arbitrary inputs, allowing for more complex cross-input semantics.The post describes a specific example of a vault using the proposed opcodes. A vault is modeled as a simple state machine with two states: the initial vault UTXOs and the utxo produced by the trigger transaction during unvaulting. The post explains how these opcodes could be used in the context of a vault, which controls the behavior of coins. It also discusses preserving amount in covenant-style contracts, including approaches such as direct introspection on output amounts and deferred checks.The structure of the P2TR output scripts for both the vault and unvaulting state are described. The proposed vault implementation differs from OP_VAULT in that it does not support adding an additional output sent back to the same vault. The author argues that separating the ctv-hash from the scripts in the taptree makes it easier to program state machines that control the behavior of coins.Overall, the proposal presents new opcodes that could enable more complex covenant-style contracts on Bitcoin. The required engineering for a soft-fork is relatively straightforward if the desired features are implemented. However, the decision to implement these features should consider potential risks to Bitcoin caused by their effect on miners' incentives. Comments and feedback on the proposal are welcome from the Bitcoin community.Another aspect of Ingala's proposal involves P2TR-based vaults, which provide an added layer of protection for storing Bitcoin securely. These vaults allow users to specify spending conditions that must be met before funds can be withdrawn. The proposal includes parameters for the vault contract and describes the structure of the vault state [V] and unvaulting state [U]. It also discusses how the proposed opcodes can be used to create vaults comparable to those built with OP_VAULT.Ingala's proposal for smart contracts in Bitcoin has two core opcodes that can be used to create vaults comparable to those built with OP_VAULT. These opcodes enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data in the output. However, further implementation is required since the opcodes only operate on scriptPubkey and not on the amounts.In summary, Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes new opcodes to enhance Script and enable more complex covenant-style contracts. The proposal discusses the use of these opcodes in creating vaults and preserving amounts in covenant-style contracts. The structure of the P2TR output scripts for the vault and unvaulting state is described, highlighting the differences from OP_VAULT. The proposal aims to make it easier to program state machines that control the behavior of coins. Feedback from the Bitcoin community is welcomed on the proposal. 2023-06-02T13:25:39+00:00 + Bitcoin developer Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes two new opcodes (OP_CHECKINPUTCONTRACTVERIFY and OP_CHECKOUTPUTCONTRACTVERIFY) that enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data within it. These opcodes enable general smart contracts and fraud proofs. The proposal also discusses Simplicity, a proposal to replace Script with a better language, but notes that it is separate from the discussion on what features should be included in the language.Ingala's proposal for new opcodes allows for the creation and verification of covenant-style contracts. The opcodes can be used to embed data into P2TR output scripts and verify that the correct data is present in subsequent transactions. However, the author suggests adding an opcode like OP_SHA256CAT to allow the data embedding to commit to multiple pieces of data. There is also consideration for extending OP_CHECKOUTPUTCONTRACTVERIFY to apply for arbitrary inputs, allowing for more complex cross-input semantics.The post describes a specific example of a vault using the proposed opcodes. A vault is modeled as a simple state machine with two states: the initial vault UTXOs and the utxo produced by the trigger transaction during unvaulting. The post explains how these opcodes could be used in the context of a vault, which controls the behavior of coins. It also discusses preserving amount in covenant-style contracts, including approaches such as direct introspection on output amounts and deferred checks.The structure of the P2TR output scripts for both the vault and unvaulting state are described. The proposed vault implementation differs from OP_VAULT in that it does not support adding an additional output sent back to the same vault. The author argues that separating the ctv-hash from the scripts in the taptree makes it easier to program state machines that control the behavior of coins.Overall, the proposal presents new opcodes that could enable more complex covenant-style contracts on Bitcoin. The required engineering for a soft-fork is relatively straightforward if the desired features are implemented. However, the decision to implement these features should consider potential risks to Bitcoin caused by their effect on miners' incentives. Comments and feedback on the proposal are welcome from the Bitcoin community.Another aspect of Ingala's proposal involves P2TR-based vaults, which provide an added layer of protection for storing Bitcoin securely. These vaults allow users to specify spending conditions that must be met before funds can be withdrawn. The proposal includes parameters for the vault contract and describes the structure of the vault state [V] and unvaulting state [U]. It also discusses how the proposed opcodes can be used to create vaults comparable to those built with OP_VAULT.Ingala's proposal for smart contracts in Bitcoin has two core opcodes that can be used to create vaults comparable to those built with OP_VAULT. These opcodes enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data in the output. However, further implementation is required since the opcodes only operate on scriptPubkey and not on the amounts.In summary, Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes new opcodes to enhance Script and enable more complex covenant-style contracts. The proposal discusses the use of these opcodes in creating vaults and preserving amounts in covenant-style contracts. The structure of the P2TR output scripts for the vault and unvaulting state is described, highlighting the differences from OP_VAULT. The proposal aims to make it easier to program state machines that control the behavior of coins. Feedback from the Bitcoin community is welcomed on the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml b/static/bitcoin-dev/June_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml index fd9a983d5e..1116081ea7 100644 --- a/static/bitcoin-dev/June_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml +++ b/static/bitcoin-dev/June_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - ZeroSync: Introducing Validity Proofs to Bitcoin - 2023-08-29T02:15:23.286604+00:00 - - blk0 2023-08-28 07:49:02+00:00 - - - Erik Aronesty 2023-06-05 18:59:58+00:00 - - - Peter Todd 2023-06-05 18:47:03+00:00 - - - Robin Linus 2023-05-12 16:03:06+00:00 - - - Weiji Guo 2023-05-12 15:32:55+00:00 - - - Robin Linus 2023-05-12 12:12:03+00:00 - + 2025-09-26T14:23:59.913310+00:00 + python-feedgen + + + [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin Robin Linus + 2023-05-12T12:12:00.000Z + + + Weiji Guo + 2023-05-12T15:32:00.000Z + + + Robin Linus + 2023-05-12T16:03:00.000Z + + + Peter Todd + 2023-06-05T18:47:00.000Z + + + Erik Aronesty + 2023-06-05T18:59:00.000Z + + + blk0 + 2023-08-28T07:49:00.000Z + + - python-feedgen + 2 Combined summary - ZeroSync: Introducing Validity Proofs to Bitcoin - 2023-08-29T02:15:23.286689+00:00 + 2025-09-26T14:23:59.914206+00:00 - Peter Todd shared information about a general purpose zkVM implementation for the RISC-V instruction set called RiscZero. He mentioned that since Bitcoin Core can be compiled for RISC-V, and RiscZero can prove execution traces of a RISC-V VM, the argument against using RISC-V for Bitcoin no longer applies.A research paper titled "ZeroSync: Introducing Validity Proofs to Bitcoin" has been published, introducing ZeroSync as a proof system that addresses scalability challenges with SNARKs. The system compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync enables diverse applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, is introduced, significantly improving privacy and throughput of token transactions. However, there are concerns about creating an alternative implementation of the Bitcoin protocol, which may lead to potential forks. Furthermore, if the technology advances to real-time proof-generation, widespread adoption by Bitcoin miners could jeopardize Bitcoin's decentralization.In a conversation between Weiji and Robin, they discussed plans to implement a SNARK verifier on Bitcoin's base layer. Robin explained his long-term plan and mentioned experimenting with Simplicity on the Liquid sidechain. Weiji shared his proposal for a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs through a soft fork. Although Robin acknowledged the proposal, he highlighted the challenge of establishing consensus over specific op_snark_verify opcodes due to the variety of competing proof systems with different trade-offs. While STARKs are scalable and suitable for chain state proofs, Robin prefers other proof systems like Plonky2 for on-chain verification due to smaller proof sizes. Robin also mentioned the possibility of using any verifier to wrap other proofs. He invited Weiji to join their Telegram group to discuss SNARKs on Bitcoin.Weiji emailed Robin to inquire about his plans for implementing a SNARK verifier on Bitcoin's base layer. Weiji had previously proposed the opcode OP_ZKP for verifying zkp proofs through a soft fork. In response, Robin shared his research on ZeroSync, a pioneering proof system that addresses Bitcoin's scalability challenges with SNARKs. ZeroSync compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various applications. The implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync also introduces zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, improving privacy and transaction throughput. The groundbreaking compression capabilities of SNARKs have revolutionized cryptocurrency design, and ZeroSync leads their application to Bitcoin. The full paper can be found at https://zerosync.org/zerosync.pdf. Robin welcomes comments and questions from the bitcoin dev community regarding the paper.ZeroSync, the first-ever proof system for Bitcoin, has been introduced to address scalability challenges using SNARKs. It compresses the entire Bitcoin blockchain into a compact proof of validity, allowing instant verification and unlocking innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. These proofs require no consensus changes, which is crucial for implementing forks in Bitcoin. ZeroSync enables various applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, significantly improves privacy and transaction throughput. With the combination of future Bitcoin features like Simplicity, zkCoins enables private and more scalable BTC transactions. The paper on ZeroSync can be found at https://zerosync.org/zerosync.pdf. Robin invites the bitcoin dev community to provide comments and ask questions about the paper. 2023-08-28T07:49:02+00:00 + Peter Todd shared information about a general purpose zkVM implementation for the RISC-V instruction set called RiscZero. He mentioned that since Bitcoin Core can be compiled for RISC-V, and RiscZero can prove execution traces of a RISC-V VM, the argument against using RISC-V for Bitcoin no longer applies.A research paper titled "ZeroSync: Introducing Validity Proofs to Bitcoin" has been published, introducing ZeroSync as a proof system that addresses scalability challenges with SNARKs. The system compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync enables diverse applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, is introduced, significantly improving privacy and throughput of token transactions. However, there are concerns about creating an alternative implementation of the Bitcoin protocol, which may lead to potential forks. Furthermore, if the technology advances to real-time proof-generation, widespread adoption by Bitcoin miners could jeopardize Bitcoin's decentralization.In a conversation between Weiji and Robin, they discussed plans to implement a SNARK verifier on Bitcoin's base layer. Robin explained his long-term plan and mentioned experimenting with Simplicity on the Liquid sidechain. Weiji shared his proposal for a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs through a soft fork. Although Robin acknowledged the proposal, he highlighted the challenge of establishing consensus over specific op_snark_verify opcodes due to the variety of competing proof systems with different trade-offs. While STARKs are scalable and suitable for chain state proofs, Robin prefers other proof systems like Plonky2 for on-chain verification due to smaller proof sizes. Robin also mentioned the possibility of using any verifier to wrap other proofs. He invited Weiji to join their Telegram group to discuss SNARKs on Bitcoin.Weiji emailed Robin to inquire about his plans for implementing a SNARK verifier on Bitcoin's base layer. Weiji had previously proposed the opcode OP_ZKP for verifying zkp proofs through a soft fork. In response, Robin shared his research on ZeroSync, a pioneering proof system that addresses Bitcoin's scalability challenges with SNARKs. ZeroSync compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various applications. The implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync also introduces zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, improving privacy and transaction throughput. The groundbreaking compression capabilities of SNARKs have revolutionized cryptocurrency design, and ZeroSync leads their application to Bitcoin. The full paper can be found at https://zerosync.org/zerosync.pdf. Robin welcomes comments and questions from the bitcoin dev community regarding the paper.ZeroSync, the first-ever proof system for Bitcoin, has been introduced to address scalability challenges using SNARKs. It compresses the entire Bitcoin blockchain into a compact proof of validity, allowing instant verification and unlocking innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. These proofs require no consensus changes, which is crucial for implementing forks in Bitcoin. ZeroSync enables various applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, significantly improves privacy and transaction throughput. With the combination of future Bitcoin features like Simplicity, zkCoins enables private and more scalable BTC transactions. The paper on ZeroSync can be found at https://zerosync.org/zerosync.pdf. Robin invites the bitcoin dev community to provide comments and ask questions about the paper. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2023/combined_postr-p2n-payjoin-using-nostr.xml b/static/bitcoin-dev/June_2023/combined_postr-p2n-payjoin-using-nostr.xml index cc9614d35e..bfe44cfef4 100644 --- a/static/bitcoin-dev/June_2023/combined_postr-p2n-payjoin-using-nostr.xml +++ b/static/bitcoin-dev/June_2023/combined_postr-p2n-payjoin-using-nostr.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - postr: p2n payjoin using nostr - 2023-08-02T09:36:53.020411+00:00 + 2025-09-26T14:23:49.277713+00:00 + python-feedgen alicexbt 2023-06-12 19:28:47+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - postr: p2n payjoin using nostr - 2023-08-02T09:36:53.020411+00:00 + 2025-09-26T14:23:49.277895+00:00 - In an email thread, a discussion is taking place regarding a proof of concept for using nostr npub and relays for payjoin. The method of using SIGHASH_NONE is explained, where there is no change in the transaction and the sender wants to spend the entire UTXO for the payment. However, this allows the receiver to have control over the funds and anyone who sees the final broadcasted transaction can extract the sender's input for any purpose.The use of specific SIGHASH flags can be ignored by developers, as they can use other flags or the default option. It is mentioned that there are no incentives for the sender or recipient to use RBF (Replace-by-Fee) and double spend in a payjoin transaction. To secure all outputs, it is suggested to use SIGHASH_ALL by the recipient, based on the understanding of SIGHASH flags and a blog post by Raghav Sood. However, it is pointed out that this method is still vulnerable, as mentioned in a tweet thread by Symphonicbtc.Furthermore, the email suggests disabling the ability to use mainnet coins directly in the code, emphasizing that it is highly irresponsible to post in this state. It is also warned that this proof of concept is not a proper implementation of a payjoin, even in a theoretical scenario, as it is easy to discern which inputs belong to the sender and receiver respectively in the final transaction.In another development, a Bitcoin developer has shared a proof of concept for payjoin (p2ep) that eliminates the need for a personal server, addressing concerns about its adoption. Unlike the stowaway method used by samourai, the developer's proposal only requires common nostr relays between the sender and recipient. The repository for this proof of concept can be found on GitLab, and a demo video showcasing the concept is available on YouTube. 2023-06-12T19:28:47+00:00 + In an email thread, a discussion is taking place regarding a proof of concept for using nostr npub and relays for payjoin. The method of using SIGHASH_NONE is explained, where there is no change in the transaction and the sender wants to spend the entire UTXO for the payment. However, this allows the receiver to have control over the funds and anyone who sees the final broadcasted transaction can extract the sender's input for any purpose.The use of specific SIGHASH flags can be ignored by developers, as they can use other flags or the default option. It is mentioned that there are no incentives for the sender or recipient to use RBF (Replace-by-Fee) and double spend in a payjoin transaction. To secure all outputs, it is suggested to use SIGHASH_ALL by the recipient, based on the understanding of SIGHASH flags and a blog post by Raghav Sood. However, it is pointed out that this method is still vulnerable, as mentioned in a tweet thread by Symphonicbtc.Furthermore, the email suggests disabling the ability to use mainnet coins directly in the code, emphasizing that it is highly irresponsible to post in this state. It is also warned that this proof of concept is not a proper implementation of a payjoin, even in a theoretical scenario, as it is easy to discern which inputs belong to the sender and receiver respectively in the final transaction.In another development, a Bitcoin developer has shared a proof of concept for payjoin (p2ep) that eliminates the need for a personal server, addressing concerns about its adoption. Unlike the stowaway method used by samourai, the developer's proposal only requires common nostr relays between the sender and recipient. The repository for this proof of concept can be found on GitLab, and a demo video showcasing the concept is available on YouTube. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2024/combined_AOPP-2-0-using-OP-CAT-and-OP-CSFS.xml b/static/bitcoin-dev/June_2024/combined_AOPP-2-0-using-OP-CAT-and-OP-CSFS.xml index 0eecd5e2a2..0caa2f7cf1 100644 --- a/static/bitcoin-dev/June_2024/combined_AOPP-2-0-using-OP-CAT-and-OP-CSFS.xml +++ b/static/bitcoin-dev/June_2024/combined_AOPP-2-0-using-OP-CAT-and-OP-CSFS.xml @@ -1,29 +1,31 @@ - + 2 Combined summary - AOPP 2.0 using OP_CAT and OP_CSFS - 2024-06-02T02:05:23.972365+00:00 - - Ethan Heilman 2024-06-01 12:34:00+00:00 - - - /dev /fd0 2024-06-01 02:27:00+00:00 - + 2025-09-26T14:37:05.368911+00:00 + python-feedgen + + + AOPP 2.0 using OP_CAT and OP_CSFS /dev /fd0 + 2024-06-01T02:27:00.000Z + + + Ethan Heilman + 2024-06-01T12:34:00.000Z + + - python-feedgen + 2 Combined summary - AOPP 2.0 using OP_CAT and OP_CSFS - 2024-06-02T02:05:23.972417+00:00 + 2025-09-26T14:37:05.369428+00:00 + 2024-06-01T12:34:00+00:00 In the ongoing discussions within the Bitcoin Improvement Proposal (BIP) 322 thread, a significant point of interest has been the exploration of potential applications and risks associated with proposed opcodes for the Bitcoin protocol. A recent contribution to this dialogue highlights a theoretical framework wherein the authentication of public keys could be managed interactively, rather than relying solely on on-chain mechanisms. This approach suggests an innovative method for addressing key management issues, such as key revocation and expiration, by facilitating off-chain interactions. - The proposed system envisions a scenario where withdrawals are executed to a string that uniquely identifies the user. This process necessitates the generation of a public key by the user, which must then be certified by an identity verifier to authorize the transaction. The technical specifics of this concept involve a series of cryptographic checks and verifications embedded within the transaction script itself. These include the utilization of certification signatures, blockchain public keys, transaction signatures, and a mechanism for time-locking transactions, alongside conditional execution paths based on the presence or absence of certain criteria. - A notable aspect of this proposal is the suggestion to replace the `CHECKDATASIG` opcode with `CHECKSIGFROMSTACK` for experimental purposes on test networks like signet. This adjustment aims to explore alternative methods for verifying data signatures against dynamically provided public keys and data, potentially offering enhanced flexibility and security for blockchain transactions. - -For further exploration of this concept, including detailed code snippets and technical explanations, interested parties can review the original proposal documented by the contributor known as "floppy disk guy" on [GitHub](https://gist.github.com/markblundeberg/bd28871548108fc66d958018b1bde085). This document provides a comprehensive overview of the envisioned protocol modifications, underscoring the innovative approaches being considered within the Bitcoin development community to enhance identity verification and key management practices within the blockchain ecosystem. - 2024-06-01T12:34:00+00:00 +For further exploration of this concept, including detailed code snippets and technical explanations, interested parties can review the original proposal documented by the contributor known as "floppy disk guy" on [GitHub](https://gist.github.com/markblundeberg/bd28871548108fc66d958018b1bde085). This document provides a comprehensive overview of the envisioned protocol modifications, underscoring the innovative approaches being considered within the Bitcoin development community to enhance identity verification and key management practices within the blockchain ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2024/combined_BIP-85-Champion-Unreachable-Please-weigh-in-.xml b/static/bitcoin-dev/June_2024/combined_BIP-85-Champion-Unreachable-Please-weigh-in-.xml index 1ca285f322..88502f112f 100644 --- a/static/bitcoin-dev/June_2024/combined_BIP-85-Champion-Unreachable-Please-weigh-in-.xml +++ b/static/bitcoin-dev/June_2024/combined_BIP-85-Champion-Unreachable-Please-weigh-in-.xml @@ -1,25 +1,29 @@ - + 2 Combined summary - BIP-85 Champion Unreachable? Please weigh in. - 2024-07-12T12:02:44.316672+00:00 - - Jon A 2024-06-27 17:37:00+00:00 - - - Aneesh Karve 2024-06-26 17:55:00+00:00 - + 2025-09-26T14:37:13.897951+00:00 + python-feedgen + + + BIP-85 Champion Unreachable? Please weigh in Aneesh Karve + 2024-06-26T17:55:00.000Z + + + Jon A + 2024-06-27T17:37:00.000Z + + - python-feedgen + 2 Combined summary - BIP-85 Champion Unreachable? Please weigh in. - 2024-07-12T12:02:44.316672+00:00 + 2025-09-26T14:37:13.898537+00:00 + 2024-06-27T17:37:00+00:00 Ethan Kosakovsky, the original author of BIP-85, has not shown any GitHub activity since 2021, raising concerns about his availability and willingness to maintain and update BIP-85. A recent pull request was submitted by a computer scientist to address inaccuracies and inconsistencies found within BIP-85, highlighting the need for potential ownership transfer due to Ethan's unreachability. This action was guided by advice from Mark Erhardt and supported by established protocols under BIP-2, which allows for the transfer of BIP ownership when the original author is no longer available or interested in its maintenance. - The computer scientist volunteering to take over has a strong background with implementations of BIP-85, BIP-32, and BIP-39, showcasing their commitment and expertise in this area. Their work can be found on GitHub at [https://github.com/akarve/bipsea](https://github.com/akarve/bipsea). They have also shared insights into the potential of BIP-85 through various posts, indicating a deep understanding and active engagement with the protocol. The situation underscores the importance of having active and responsive contributors in maintaining the integrity and relevance of Bitcoin Improvement Proposals (BIPs). - 2024-06-27T17:37:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2024/combined_Great-Consensus-Cleanup-Revival.xml b/static/bitcoin-dev/June_2024/combined_Great-Consensus-Cleanup-Revival.xml index 4509c7cd94..a16a2f5bb4 100644 --- a/static/bitcoin-dev/June_2024/combined_Great-Consensus-Cleanup-Revival.xml +++ b/static/bitcoin-dev/June_2024/combined_Great-Consensus-Cleanup-Revival.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.043876+00:00 - - Antoine Riard 2024-11-28 05:18:00+00:00 - - - Murad Ali 2024-07-20 21:39:00+00:00 - - - Eric Voskuil 2024-07-20 20:29:00+00:00 - - - Antoine Riard 2024-07-18 17:39:00+00:00 - - - Eric Voskuil 2024-07-04 14:45:00+00:00 - - - Antoine Riard 2024-07-04 13:20:00+00:00 - - - Eric Voskuil 2024-07-03 23:29:00+00:00 - - - Eric Voskuil 2024-07-03 01:13:00+00:00 - - - Larry Ruane 2024-07-03 01:07:00+00:00 - - - Eric Voskuil 2024-07-02 15:57:00+00:00 - - - Antoine Poinsot 2024-07-02 10:23:00+00:00 - - - Antoine Riard 2024-07-02 02:36:00+00:00 - - - Eric Voskuil 2024-06-29 20:40:00+00:00 - - - Eric Voskuil 2024-06-29 20:29:00+00:00 - - - Antoine Riard 2024-06-29 01:53:00+00:00 - - - Eric Voskuil 2024-06-29 01:31:00+00:00 - - - Antoine Riard 2024-06-29 01:06:00+00:00 - - - Eric Voskuil 2024-06-28 17:14:00+00:00 - - - Antoine Poinsot 2024-06-27 09:35:00+00:00 - - - Eric Voskuil 2024-06-24 00:35:00+00:00 - - - Antoine Poinsot 2024-06-21 13:09:00+00:00 - - - Eric Voskuil 2024-06-18 13:02:00+00:00 - - - Antoine Poinsot 2024-06-18 08:13:00+00:00 - - - Eric Voskuil 2024-06-17 22:15:00+00:00 - - - Antoine Riard 2024-05-06 01:10:00+00:00 - - - Mark F 2024-04-30 22:20:00+00:00 - - - Antoine Riard 2024-04-25 06:08:00+00:00 - - - Antoine Poinsot 2024-04-18 10:04:00+00:00 - - - Mark F 2024-04-18 00:46:00+00:00 - - - Antoine Riard 2024-03-27 18:57:00+00:00 - - - Antoine Poinsot 2024-03-27 10:35:00+00:00 - - - Antoine Riard 2024-03-26 19:11:00+00:00 - - - Antoine Poinsot 2024-03-24 18:10:00+00:00 - + 2025-09-26T14:37:09.671245+00:00 + python-feedgen + + + Great Consensus Cleanup Revival 'Antoine Poinsot' + 2024-03-24T18:10:00.000Z + + + Antoine Riard + 2024-03-26T19:11:00.000Z + + + Antoine Poinsot' + 2024-03-27T10:35:00.000Z + + + Antoine Riard + 2024-03-27T18:57:00.000Z + + + Mark F + 2024-04-18T00:46:00.000Z + + + Antoine Poinsot' + 2024-04-18T10:04:00.000Z + + + Antoine Riard + 2024-04-25T06:08:00.000Z + + + Mark F + 2024-04-30T22:20:00.000Z + + + Antoine Riard + 2024-05-06T01:10:00.000Z + + + Eric Voskuil + 2024-06-17T22:15:00.000Z + + + Antoine Poinsot' + 2024-06-18T08:13:00.000Z + + + Eric Voskuil + 2024-06-18T13:02:00.000Z + + + Antoine Poinsot' + 2024-06-21T13:09:00.000Z + + + Eric Voskuil + 2024-06-24T00:35:00.000Z + + + Antoine Poinsot' + 2024-06-27T09:35:00.000Z + + + Eric Voskuil + 2024-06-28T17:14:00.000Z + + + Antoine Riard + 2024-06-29T01:06:00.000Z + + + Eric Voskuil + 2024-06-29T01:31:00.000Z + + + Antoine Riard + 2024-06-29T01:53:00.000Z + + + Eric Voskuil + 2024-06-29T20:29:00.000Z + + + Eric Voskuil + 2024-06-29T20:40:00.000Z + + + Antoine Riard + 2024-07-02T02:36:00.000Z + + + Antoine Poinsot' + 2024-07-02T10:23:00.000Z + + + Eric Voskuil + 2024-07-02T15:57:00.000Z + + + Larry Ruane + 2024-07-03T01:07:00.000Z + + + Eric Voskuil + 2024-07-03T01:13:00.000Z + + + Eric Voskuil + 2024-07-03T23:29:00.000Z + + + Antoine Riard + 2024-07-04T13:20:00.000Z + + + Eric Voskuil + 2024-07-04T14:45:00.000Z + + + Antoine Riard + 2024-07-18T17:39:00.000Z + + + Eric Voskuil + 2024-07-20T20:29:00.000Z + + + Murad Ali + 2024-07-20T21:39:00.000Z + + + Antoine Riard + 2024-11-28T05:18:00.000Z + + @@ -135,19 +171,16 @@ - python-feedgen + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.044085+00:00 + 2025-09-26T14:37:09.674898+00:00 + 2024-11-28T05:18:00+00:00 The conversation initiated by Antoine Poinsot sheds light on various aspects of the Bitcoin network's consensus mechanism, probing into areas that could benefit from improvement and adjustment. Poinsot zeroes in on concerns like the prolonged block validation times, which pose a threat to the network's overall efficacy and security framework. In response to this, he acknowledges existing solutions but proposes a supplementary strategy that caps the size of legacy transactions, aiming to bolster safety measures and ensure quicker validation processes. - Another significant point of discussion is the timewarp bug, which Poinsot indicates has not received the level of concern it rightfully demands. He emphasizes the critical need for addressing this flaw to safeguard the network’s stability. Moreover, the debate ventures into ensuring coinbase transaction uniqueness as a measure to circumvent the requirement for BIP30 validations beyond a specific block height, suggesting a potential pathway to streamline transaction verification while enhancing the network's security posture. - A nuanced proposal is introduced regarding the handling of transactions based on their sizes. Poinsot suggests maintaining the validity of transactions under 64 bytes while advocating for the invalidation of those exactly at this size threshold. This approach hints at a precise methodology aimed at refining transaction processing without imposing broad restrictions on transaction sizes. - The dialogue further extends an invitation to the community for additional insights, challenging others to identify possible disagreements, overlooked facets, or enhancements to the presented proposals. This initiative underscores a commitment to collaborative progress, aiming to cultivate a constructive forum for discussion that could lead to substantial improvements within the Bitcoin consensus mechanism. Through this exchange, Poinsot not only highlights key areas of concern but also catalyzes a broader dialogue aimed at fortifying the network against potential vulnerabilities and inefficiencies. - 2024-11-28T05:18:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2024/combined_Libre-Relay-v27-1-released-with-lower-1-25x-replacement-threshold.xml b/static/bitcoin-dev/June_2024/combined_Libre-Relay-v27-1-released-with-lower-1-25x-replacement-threshold.xml index 05e1039375..d64050e863 100644 --- a/static/bitcoin-dev/June_2024/combined_Libre-Relay-v27-1-released-with-lower-1-25x-replacement-threshold.xml +++ b/static/bitcoin-dev/June_2024/combined_Libre-Relay-v27-1-released-with-lower-1-25x-replacement-threshold.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Libre Relay v27.1 released with lower 1.25x replacement threshold - 2024-07-12T12:01:49.173208+00:00 - - Peter Todd 2024-06-22 14:29:00+00:00 - - - Peter Todd 2024-06-20 22:33:00+00:00 - - - Peter Todd 2024-06-20 16:33:00+00:00 - + 2025-09-26T14:37:18.194199+00:00 + python-feedgen + + + Libre Relay v27.1 released with lower 1.25x replacement threshold Peter Todd + 2024-06-20T16:33:00.000Z + + + Peter Todd + 2024-06-20T22:33:00.000Z + + + Peter Todd + 2024-06-22T14:29:00.000Z + + - python-feedgen + 2 Combined summary - Libre Relay v27.1 released with lower 1.25x replacement threshold - 2024-07-12T12:01:49.173208+00:00 + 2025-09-26T14:37:18.194694+00:00 + 2024-06-22T14:29:00+00:00 In a recent incident involving a Lightning Network (LN) node, a transaction was successfully resolved through the use of Replace-By-Fee-Rate (RBFR), showcasing its effectiveness in real-world applications. A transaction was created that spent three anchor outputs at a fee rate of 13.1sat/vB, which had been previously pinned by another transaction with a lower fee rate of 5.37sat/vB. Despite the lower total fee, F2Pool prioritized and mined the RBFR replacement due to its higher fee rate, demonstrating the inefficiency of low fee rates in the current mining environment. This occurrence also highlighted the limited propagation of the original transaction across non-RBFR nodes, underscoring the utility of RBFR nodes in facilitating transaction confirmation despite lower overall fees. - The developer behind these observations has introduced significant updates to the Libre Relay project, specifically adjusting the replace-by-fee-rate threshold to 1.25x from the previous 2x. This adjustment aims to reduce the cost associated with overcoming transaction pinning while increasing the cost for those attempting it, essentially making it more likely for a pinned transaction to itself get mined if it attempts to exploit the system. This development encourages further scrutiny and testing against potential denial-of-service (DoS) attacks, which could underscore or refute the perceived vulnerabilities within the RBFR proposal. Critics are invited to demonstrate any substantial flaws, especially those that could outperform existing relay attacks without RBFR. - Moreover, this enhancement in the RBFR mechanism has shown its practical benefits, particularly for LN node operations. Instances were cited where transactions that would typically fail due to higher absolute fees were eventually confirmed through propagation by Libre Relay nodes, with F2Pool playing a pivotal role in mining these transactions. This outcome suggests that running Libre Relay could be advantageous for Lightning node operators to mitigate pinning vulnerabilities inherent in the Lightning protocol. The adjustments and real-world implications reflect ongoing efforts to enhance transaction efficiency and security within the Bitcoin network, highlighting the potential of RBFR in addressing complex transactional challenges. - 2024-06-22T14:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2024/combined_Network-partition-recovery.xml b/static/bitcoin-dev/June_2024/combined_Network-partition-recovery.xml index 2bb6024183..e5cb87c5eb 100644 --- a/static/bitcoin-dev/June_2024/combined_Network-partition-recovery.xml +++ b/static/bitcoin-dev/June_2024/combined_Network-partition-recovery.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Network partition recovery - 2024-07-12T11:59:51.683633+00:00 - - Peter Todd 2024-06-21 01:30:00+00:00 - - - Ethan Heilman 2024-06-16 20:30:00+00:00 - - - Tao Effect 2024-06-14 21:31:00+00:00 - + 2025-09-26T14:37:11.788235+00:00 + python-feedgen + + + Network partition recovery Tao Effect + 2024-06-14T21:31:00.000Z + + + Ethan Heilman + 2024-06-16T20:30:00.000Z + + + Peter Todd + 2024-06-21T01:30:00.000Z + + - python-feedgen + 2 Combined summary - Network partition recovery - 2024-07-12T11:59:51.683633+00:00 + 2025-09-26T14:37:11.788842+00:00 + 2024-06-21T01:30:00+00:00 In the discussion about the resilience of Bitcoin in the face of potential internet splits, a key point raised is the minimal impact such events might have on the network due to the small bandwidth requirements for synchronizing blocks and the strong financial incentives to overcome these challenges. Various technologies, including satellite internet, amateur radio, and Blockstream satellite, offer solutions to quickly remedy any network partitions, suggesting that significant disruptions would require catastrophic scenarios far beyond the issues of blockchain connectivity. Furthermore, the automatic re-mining of transactions from reorganized blocks ensures continuity despite temporary partitions. - The conversation also touches on the dynamics of short-term vs. long-term internet partitions and their implications for Bitcoin mining and transaction confirmation reliability. Short-term disruptions are unlikely to affect most users, while longer partitions could lead to miners halting operations upon realizing the futility of mining on an isolated chain, anticipating the eventual loss of rewards when normalcy resumes. This scenario underlines a critical trust issue within partitioned segments, as confirmations by miners within such segments would be deemed unreliable due to the expectation of reversal once the partition heals. Efforts to communicate outside of the partition for transaction verification highlight the community's likely response to maintaining integrity amidst such challenges. - -Moreover, the possibility of a perfectly balanced split in mining power due to an internet partition raises complex questions about the "longest chain wins" principle and the feasibility of merging divergent chains. While some Directed Acyclic Graph (DAG) chains possess the capability to automatically merge forks and resolve double-spending issues, incorporating similar functionality into Bitcoin would represent an unprecedented change to its consensus mechanism. These insights underscore the proactive considerations being explored within the Bitcoin community to safeguard the network against potential future disruptions caused by internet fragmentation. - 2024-06-21T01:30:00+00:00 +Moreover, the possibility of a perfectly balanced split in mining power due to an internet partition raises complex questions about the "longest chain wins" principle and the feasibility of merging divergent chains. While some Directed Acyclic Graph (DAG) chains possess the capability to automatically merge forks and resolve double-spending issues, incorporating similar functionality into Bitcoin would represent an unprecedented change to its consensus mechanism. These insights underscore the proactive considerations being explored within the Bitcoin community to safeguard the network against potential future disruptions caused by internet fragmentation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2024/combined_OP-Expire-mempool-behavior.xml b/static/bitcoin-dev/June_2024/combined_OP-Expire-mempool-behavior.xml index 1976130ad3..5c18e40fd0 100644 --- a/static/bitcoin-dev/June_2024/combined_OP-Expire-mempool-behavior.xml +++ b/static/bitcoin-dev/June_2024/combined_OP-Expire-mempool-behavior.xml @@ -1,37 +1,41 @@ - + 2 Combined summary - OP_Expire mempool behavior - 2024-07-12T11:50:49.756256+00:00 - - Antoine Riard 2024-06-20 23:09:00+00:00 - - - Peter Todd 2024-03-19 15:04:00+00:00 - - - Antoine Riard 2024-03-16 18:21:00+00:00 - - - Peter Todd 2024-03-13 03:32:00+00:00 - + 2025-09-26T14:37:07.479665+00:00 + python-feedgen + + + OP_Expire mempool behavior Peter Todd + 2024-03-13T03:32:00.000Z + + + Antoine Riard + 2024-03-16T18:21:00.000Z + + + Peter Todd + 2024-03-19T15:04:00.000Z + + + Antoine Riard + 2024-06-20T23:09:00.000Z + + - python-feedgen + 2 Combined summary - OP_Expire mempool behavior - 2024-07-12T11:50:49.756256+00:00 + 2025-09-26T14:37:07.480342+00:00 + 2024-06-20T23:09:00+00:00 Antoine Riard delves into the technical intricacies of Bitcoin Improvement Proposals (BIP) and their implications on transaction replacement and denial-of-service (DoS) attacks. A key focus is on the replace-by-fee-rate (RBFR) strategy under BIP125 rules, where HTLC-timeout transactions can supersede HTLC-preimage transactions in a mempool if they offer a higher fee. This mechanism ensures network integrity by guaranteeing that transactions are confirmed, thus preventing potential bandwidth waste. Riard also discusses the OP_Expire functionality, which deems transactions invalid after a certain period. He emphasizes the vulnerability this creates, allowing attackers to consume network resources with minimal cost. However, he reassures that existing rules around transaction fees are designed to mitigate such attacks effectively. - The conversation extends to the Lightning Network (LN), highlighting concerns about the efficient broadcast of second-stage transactions like HTLC-preimage and HTLC-timeout close to their expiry. The introduction of altruistic rebroadcasting is discussed as a measure to prioritize transactions with higher mining probabilities, though its effectiveness against sophisticated DoS strategies remains debatable. Additionally, Riard notes an observed uniformity in minimum fees across different nodes, suggesting a level of predictability in network fee structures despite variations in mempool sizes. - A critical issue raised pertains to version 3 (V3) transactions and the loophole that allows attackers to exploit the system through replacement cycling attacks without adequately compensating for the bandwidth used. This flaw undermines the principle that users must pay for the network resources they consume. Furthermore, the discussion points out the practical challenges LN nodes face in mitigating these attacks due to their limited tx-relay network interface designs. - -Further insights are offered from discussions on the [delvingbitcoin forum](https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8), where the topic of OP_Expire's potential as a "bandwidth-wasting vector" is explored. It is argued that while OP_Expire introduces a new layer to transaction handling, it does not significantly alter the economic incentives or costs associated with transaction replacement compared to the established Replace-By-Fee (RBF) practices. This perspective underscores the ongoing need for scrutiny and adaptation of cryptographic protocols to address emerging challenges in the cryptocurrency domain. - 2024-06-20T23:09:00+00:00 +Further insights are offered from discussions on the [delvingbitcoin forum](https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8), where the topic of OP_Expire's potential as a "bandwidth-wasting vector" is explored. It is argued that while OP_Expire introduces a new layer to transaction handling, it does not significantly alter the economic incentives or costs associated with transaction replacement compared to the established Replace-By-Fee (RBF) practices. This perspective underscores the ongoing need for scrutiny and adaptation of cryptographic protocols to address emerging challenges in the cryptocurrency domain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml b/static/bitcoin-dev/June_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml index 74bdc74a4c..8b94824989 100644 --- a/static/bitcoin-dev/June_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml +++ b/static/bitcoin-dev/June_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Proposing a P2QRH BIP towards a quantum resistant soft fork - 2024-09-26T03:18:36.202311+00:00 - - Hunter Beast 2024-09-25 12:04:00+00:00 - - - Antoine Riard 2024-08-22 06:20:00+00:00 - - - Hunter Beast 2024-08-15 05:05:00+00:00 - - - Hunter Beast 2024-08-06 17:37:00+00:00 - - - Antoine Riard 2024-07-13 01:34:00+00:00 - - - hunter 2024-06-17 20:27:00+00:00 - - - Antoine Riard 2024-06-17 01:07:00+00:00 - - - Hunter Beast 2024-06-14 14:28:00+00:00 - - - PierreLuc DallaireDemers 2024-06-14 13:51:00+00:00 - - - Hunter Beast 2024-06-08 21:04:00+00:00 - + 2025-09-26T14:37:16.081641+00:00 + python-feedgen + + + Proposing a P2QRH BIP towards a quantum resistant soft fork Hunter Beast + 2024-06-08T21:04:00.000Z + + + Pierre-Luc Dallaire-Demers + 2024-06-14T13:51:00.000Z + + + Hunter Beast + 2024-06-14T14:28:00.000Z + + + Antoine Riard + 2024-06-17T01:07:00.000Z + + + hunter + 2024-06-17T20:27:00.000Z + + + Antoine Riard + 2024-07-13T01:34:00.000Z + + + Hunter Beast + 2024-08-06T17:37:00.000Z + + + Hunter Beast + 2024-08-15T05:05:00.000Z + + + Antoine Riard + 2024-08-22T06:20:00.000Z + + + Hunter Beast + 2024-09-25T12:04:00.000Z + + @@ -43,21 +56,17 @@ - python-feedgen + 2 Combined summary - Proposing a P2QRH BIP towards a quantum resistant soft fork - 2024-09-26T03:18:36.202392+00:00 + 2025-09-26T14:37:16.082909+00:00 + 2024-09-25T12:04:00+00:00 The recent discussions and updates surrounding the development of a Bitcoin Improvement Proposal (BIP) to introduce quantum resistance into Bitcoin's cryptographic framework underscore the community's proactive approach towards safeguarding the cryptocurrency against potential quantum computing threats. Central to these discussions is the acknowledgment of IBM's advancements in quantum computing, particularly with its Quantum System Two, which potentially supports up to 16,000 qubits. This advancement hints at a future where quantum computing could significantly impact cryptographic security, necessitating the exploration of post-quantum cryptographic algorithms. - The discourse extends beyond merely recognizing the threat, delving into specific cryptographic considerations and solutions. For example, the integration of FALCON, a post-quantum signature algorithm, into the proposed BIP reflects a thoughtful response to the nuanced challenges posed by quantum computing. This choice is indicative of the community's effort to balance security needs with practical implementation concerns such as signature size and transaction costs. The dialogue also touches on broader strategic issues, including the potential for increased witness discounts to accommodate larger transactions, underscoring the ongoing effort to maintain Bitcoin's scalability and security in tandem. - Moreover, the discussions reveal an awareness of the limitations and uncertainties inherent in predicting quantum computing's progression. References to IBM's roadmap and the need for cautious optimism highlight the complex interplay between technological advancement and cryptographic security. The conversation acknowledges the diversity of quantum computing architectures and their implications for cryptographic attacks, emphasizing the importance of a robust, adaptable approach to security. - Significantly, the proposal outlines defensive measures that Bitcoin users can implement today, such as configuring spending scripts to require artificially inflated witness stacks. This strategy exemplifies the multifaceted approach needed to address quantum threats, combining immediate practical measures with long-term cryptographic evolution. The suggestion to use trusted mining pools for transaction submission further illustrates the community's willingness to explore diverse strategies to mitigate risk. - In summary, the ongoing dialogue around introducing quantum resistance to Bitcoin through a dedicated BIP reflects a comprehensive and forward-looking approach to cryptocurrency security. It underscores the community's commitment to addressing emerging threats through research, collaboration, and innovation. The inclusion of FALCON signatures and the consideration of various post-quantum cryptographic schemes highlight the technical complexity of this endeavor, while discussions about implementation strategies and the potential impact on transaction throughput reveal the broader strategic considerations at play. As the landscape of quantum computing continues to evolve, the Bitcoin community's proactive engagement with these challenges will be crucial in ensuring the cryptocurrency's resilience and longevity. - 2024-09-25T12:04:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml b/static/bitcoin-dev/June_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml index b787d0798f..78163b27bb 100644 --- a/static/bitcoin-dev/June_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml +++ b/static/bitcoin-dev/June_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml @@ -1,95 +1,23 @@ - + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747215+00:00 - - conduition 2025-08-09 19:53:00+00:00 - - - conduition 2025-07-15 13:53:00+00:00 - - - Jameson Lopp 2025-07-13 21:26:00+00:00 - - - Pieter Wuille 2025-07-13 19:28:00+00:00 - - - Boris Nagaev 2025-07-13 17:51:00+00:00 - - - Ethan Heilman 2025-07-13 16:01:00+00:00 - - - Or Sattath 2025-07-13 15:38:00+00:00 - - - Boris Nagaev 2025-07-13 14:20:00+00:00 - - - Jameson Lopp 2025-07-13 12:34:00+00:00 - - - Boris Nagaev 2025-07-13 01:39:00+00:00 - - - Jameson Lopp 2025-06-08 14:04:00+00:00 - - - waxwing/ AdamISZ 2025-06-07 13:28:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 21:15:00+00:00 - - - Sjors Provoost 2025-05-28 07:46:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 01:07:00+00:00 - - - ArmchairCryptologist 2025-05-26 15:40:00+00:00 - - - Agustin Cruz 2025-05-26 00:32:00+00:00 - - - Dustin Ray 2025-05-25 23:03:00+00:00 - - - conduition 2025-05-25 19:03:00+00:00 - - - Agustin Cruz 2025-03-24 11:19:00+00:00 - - - AstroTown 2025-03-22 19:02:00+00:00 - - - Sjors Provoost 2025-03-18 12:48:00+00:00 - - - Jameson Lopp 2025-03-17 13:28:00+00:00 - - - Matt Corallo 2025-03-17 12:00:00+00:00 - - - IdeA 2025-03-16 22:56:00+00:00 - - - Jameson Lopp 2025-03-16 21:25:00+00:00 - - - Jameson Lopp 2025-03-16 19:44:00+00:00 - - - Jameson Lopp 2025-03-16 18:03:00+00:00 - - - Jameson Lopp 2025-03-16 14:15:00+00:00 - + 2025-09-26T14:31:12.190805+00:00 + python-feedgen + + + Or Sattath + 2025-07-13T15:38:00.000Z + + + conduition' + 2025-07-15T13:53:00.000Z + + + conduition' + 2025-08-09T19:53:00.000Z + + @@ -119,21 +47,17 @@ - python-feedgen + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747403+00:00 + 2025-09-26T14:31:12.191389+00:00 + 2025-08-09T19:53:00+00:00 The discourse delves into the intricate challenges and potential approaches for integrating post-quantum cryptography within Bitcoin's framework, highlighting a proactive stance towards enhancing security against quantum computing threats. A notable proposal involves incorporating a form of post-quantum cryptography, specifically through an OP_HASHBASEDSIG mechanism, potentially utilizing SPHINCS+, to embed quantum-resistant public keys into wallet outputs. This suggestion underscores the urgency of preparing for quantum advancements well in advance, advocating for the embedding of these public keys at least a decade prior to any enforcement action to ensure ample safety margins. - The dialogue further explores the ethical and practical considerations surrounding the handling of Bitcoin funds that may become vulnerable to quantum decryption. The debate oscillates between two primary courses of action: leaving such funds accessible, thereby susceptible to potential quantum theft, or proactively rendering them unspendable to preemptively secure them against quantum capabilities. This discussion touches upon core Bitcoin principles including censorship resistance, forward compatibility, and conservatism. The ethical implications are profound, weighing the prevention of economic disruption against the fairness and property rights implications of either allowing or preventing quantum-enabled theft. - Historical precedents within the Bitcoin protocol's evolution serve as reference points for this debate, suggesting a tendency towards remedying vulnerabilities rather than exploiting them. The conversation acknowledges the complexity of incentivizing the ecosystem-wide adoption of quantum-resistant technologies through measures possibly as radical as burning vulnerable coins. - Furthermore, the exchange considers the broader implications of quantum recovery and the potential redistribution of wealth from those without access to quantum technology to those who might achieve quantum supremacy. This raises significant questions about the balance between ensuring long-term security and adhering to Bitcoin's foundational principles of decentralization and user sovereignty. - In addressing the potential quantum threat, the dialogue encapsulates a meticulous examination of both the technical feasibility of implementing quantum-resistant cryptographic methods and the philosophical underpinnings guiding these decisions. It reflects an ongoing effort among developers and stakeholders to navigate the evolving landscape of digital currency security thoughtfully, emphasizing the need for community consensus and careful consideration of Bitcoin's core values in the face of emerging technological challenges. - 2025-08-09T19:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Allowing-Duplicate-Keys-in-BIP-390-musig-Expressions.xml b/static/bitcoin-dev/June_2025/combined_Allowing-Duplicate-Keys-in-BIP-390-musig-Expressions.xml index dc212b72f5..79535c6195 100644 --- a/static/bitcoin-dev/June_2025/combined_Allowing-Duplicate-Keys-in-BIP-390-musig-Expressions.xml +++ b/static/bitcoin-dev/June_2025/combined_Allowing-Duplicate-Keys-in-BIP-390-musig-Expressions.xml @@ -1,33 +1,36 @@ - + 2 Combined summary - Allowing Duplicate Keys in BIP 390 musig() Expressions - 2025-07-01T05:54:58.643884+00:00 - - Ava Chow 2025-06-03 21:38:00+00:00 - - - Nagaev Boris 2025-06-03 21:26:00+00:00 - - - Ava Chow 2025-06-03 21:07:00+00:00 - + 2025-09-26T14:30:42.076498+00:00 + python-feedgen + + + Allowing Duplicate Keys in BIP 390 musig() Expressions 'Ava Chow' + 2025-06-03T21:07:00.000Z + + + Nagaev Boris + 2025-06-03T21:26:00.000Z + + + Ava Chow' + 2025-06-03T21:38:00.000Z + + - python-feedgen + 2 Combined summary - Allowing Duplicate Keys in BIP 390 musig() Expressions - 2025-07-01T05:54:58.643930+00:00 + 2025-09-26T14:30:42.077073+00:00 + 2025-06-03T21:38:00+00:00 In discussing the technical nuances of Bitcoin Improvement Proposal (BIP) 327, several key points emerge regarding the handling of public keys within the cryptographic processes of Bitcoin transactions. The allowance of duplicate participant public keys under BIP 327 is highlighted as a noteworthy feature, despite the potential complexities it introduces into the signing procedures. The rationale behind this decision appears to stem from a desire to maintain flexibility and simplicity in transaction processing, although it raises concerns about the security implications of such an approach. - Ava Chow's correspondence sheds light on the specific issue of deterministic nonce generation when duplicate public keys are present. The standard practice of deriving nonces from a combination of the message, the set of public keys, and each participant's private key could lead to the creation of identical nonces if public keys are duplicated. This situation, while not immediately threatening in terms of private key exposure, introduces risks associated with unexpected outcomes during the signing process. The discussion reflects an awareness of these risks and a cautious approach to managing them, emphasizing the need for careful consideration of security assumptions in scenarios involving duplicate keys. - Furthermore, the dialogue touches upon the challenges associated with implementing `musig()` descriptor expressions, particularly the restriction against repeated participant public keys. The practical difficulties of enforcing this restriction are brought into question, especially in light of the fact that MuSig2, a protocol enhancement, permits such duplications to facilitate easier implementation. Ava proposes amending the BIP to eliminate this restriction, seeking feedback from the developer community on the potential impact of this change. The conversation underscores the dynamic nature of Bitcoin protocol development, where proposals for modifications are subject to community scrutiny and debate in pursuit of optimal security and functionality. - This discourse among Bitcoin developers illustrates the intricate balance between innovation and security in the evolution of cryptocurrency protocols. The willingness to reconsider established norms, such as the unique public key requirement, in response to practical implementation challenges reflects a broader theme of adaptability within the field. As the discussion continues, the outcome will likely influence future practices related to public key management and nonce generation within the Bitcoin network. - 2025-06-03T21:38:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml b/static/bitcoin-dev/June_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml index 448deb381d..85ec8fafe9 100644 --- a/static/bitcoin-dev/June_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml +++ b/static/bitcoin-dev/June_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP39 Extension for Manual Seed Phrase Creation - 2025-07-01T05:38:58.785596+00:00 + 2025-09-26T14:30:46.413688+00:00 + python-feedgen Russell OConnor 2025-06-04 17:45:00+00:00 @@ -31,19 +32,16 @@ - python-feedgen + 2 Combined summary - BIP39 Extension for Manual Seed Phrase Creation - 2025-07-01T05:38:58.785663+00:00 + 2025-09-26T14:30:46.413846+00:00 + 2025-06-04T17:45:00+00:00 The discussion explores the nuances and potential improvements to the BIP39 checksum mechanism, focusing on alternative methods for generating and verifying mnemonic phrases. The conversation begins with an acknowledgment of the possible advantages in manually generating randomness over relying on computer chips' hidden processes. It introduces BIP-93, also known as codex32, as a protocol that supports both human and computer-generated randomness, facilitating secret sharing and emphasizing transparency in the generation process. This approach addresses concerns about the opacity of current systems and suggests a method that could enhance user trust and security. - The dialogue further delves into the practical aspects of mnemonic phrase creation, proposing a 16-word seed phrase method that bypasses the traditional checksum requirement. This method involves selecting words from a predefined list, aiming to simplify the process for users while maintaining security through initial xpub confirmation. The proposed solution underscores the importance of simplicity in onboarding new users to cryptocurrency, suggesting that reducing friction in this process could significantly impact adoption rates. - Moreover, the correspondence highlights a broader discourse on the utility and implementation of checksums in mnemonic phrases, questioning their necessity, especially in contexts where entropy is manually generated. It presents an innovative approach that utilizes a subset of words to encode both entropy and derivation paths within a 16-word phrase, offering a potential revision or supplement to the existing BIP39 standard. This methodology not only simplifies the user experience by minimizing technical barriers but also retains the security benefits of checksums through strategic word selection and encoding of metadata. - In essence, the emails collectively advocate for more transparent, user-friendly approaches to cryptographic security, specifically in the realm of mnemonic phrase generation and verification. They propose concrete methods and protocols, such as codex32 and a revised application of the BIP39 wordlist, to achieve these objectives, highlighting the ongoing evolution of cryptocurrency technologies towards greater accessibility and reliability. - 2025-06-04T17:45:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_CTV-CSFS-a-letter.xml b/static/bitcoin-dev/June_2025/combined_CTV-CSFS-a-letter.xml index 2291337cb4..b86b7531b7 100644 --- a/static/bitcoin-dev/June_2025/combined_CTV-CSFS-a-letter.xml +++ b/static/bitcoin-dev/June_2025/combined_CTV-CSFS-a-letter.xml @@ -1,200 +1,267 @@ - + 2 Combined summary - CTV + CSFS: a letter - 2025-07-01T04:15:52.183248+00:00 - - Saint Wenhao 2025-06-28 16:13:00+00:00 - - - fiatjaf 2025-06-21 12:06:00+00:00 - - - Peter Todd 2025-06-20 14:28:00+00:00 - - - /dev /fd0 2025-06-17 18:19:00+00:00 - - - Harsha Goli 2025-06-17 16:40:00+00:00 - - - Antoine Poinsot 2025-06-17 14:34:00+00:00 - - - Steven Roose 2025-06-17 11:22:00+00:00 - - - Owen Kemeys 2025-06-15 19:43:00+00:00 - - - Greg Maxwell 2025-06-15 17:43:00+00:00 - - - Jameson Lopp 2025-06-15 14:40:00+00:00 - - - Sanket Kanjalkar 2025-06-15 00:20:00+00:00 - - - Greg Maxwell 2025-06-15 00:01:00+00:00 - - - Sanket Kanjalkar 2025-06-14 23:50:00+00:00 - - - Greg Maxwell 2025-06-14 21:31:00+00:00 - - - Jameson Lopp 2025-06-14 20:17:00+00:00 - - - Jameson Lopp 2025-06-14 20:05:00+00:00 - - - gmaxwell 2025-06-14 16:06:00+00:00 - - - Sjors Provoost 2025-06-14 15:58:00+00:00 - - - Jameson Lopp 2025-06-13 15:41:00+00:00 - - - Harsha Goli 2025-06-13 14:50:00+00:00 - - - Antoine Poinsot 2025-06-13 13:07:00+00:00 - - - Matt Corallo 2025-06-13 12:36:00+00:00 - - - Jameson Lopp 2025-06-13 11:08:00+00:00 - - - Anthony Towns 2025-06-13 06:19:00+00:00 - - - Anthony Towns 2025-06-13 05:50:00+00:00 - - - Antoine Riard 2025-06-13 01:18:00+00:00 - - - Matt Corallo 2025-06-12 22:44:00+00:00 - - - Andrew Poelstra 2025-06-12 19:51:00+00:00 - - - Matt Corallo 2025-06-12 18:43:00+00:00 - - - James OBeirne 2025-06-12 18:38:00+00:00 - - - Matt Corallo 2025-06-12 18:04:00+00:00 - - - James OBeirne 2025-06-12 03:34:00+00:00 - - - James OBeirne 2025-06-12 03:23:00+00:00 - - - Greg Maxwell 2025-06-12 02:06:00+00:00 - - - Harsha Goli 2025-06-12 00:59:00+00:00 - - - Matt Corallo 2025-06-11 20:30:00+00:00 - - - James OBeirne 2025-06-11 18:34:00+00:00 - - - Brandon Black 2025-06-11 18:09:00+00:00 - - - James OBeirne 2025-06-11 16:50:00+00:00 - - - James OBeirne 2025-06-11 14:12:00+00:00 - - - Peter Todd 2025-06-11 13:52:00+00:00 - - - Antoine Riard 2025-06-10 23:42:00+00:00 - - - Matt Corallo 2025-06-10 23:42:00+00:00 - - - Paul Sztorc 2025-06-10 19:04:00+00:00 - - - Matt Corallo 2025-06-10 17:17:00+00:00 - - - Sjors Provoost 2025-06-10 17:15:00+00:00 - - - Sjors Provoost 2025-06-10 16:56:00+00:00 - - - James OBeirne 2025-06-10 14:03:00+00:00 - - - Andrew Poelstra 2025-06-10 13:23:00+00:00 - - - Greg Sanders 2025-06-10 13:19:00+00:00 - - - Melvin Carvalho 2025-06-10 02:28:00+00:00 - - - David A. Harding 2025-06-10 02:08:00+00:00 - - - Paul Sztorc 2025-06-10 02:02:00+00:00 - - - Antoine Poinsot 2025-06-09 23:02:00+00:00 - - - Matt Corallo 2025-06-09 21:12:00+00:00 - - - /dev /fd0 2025-06-09 19:27:00+00:00 - - - Matt Corallo 2025-06-09 18:55:00+00:00 - - - Matt Corallo 2025-06-09 17:51:00+00:00 - - - Michael Folkson 2025-06-09 15:56:00+00:00 - - - James OBeirne 2025-06-09 14:43:00+00:00 - - - James OBeirne 2025-06-09 14:41:00+00:00 - - - Michael Folkson 2025-06-09 13:51:00+00:00 - - - James OBeirne 2025-06-09 12:51:00+00:00 - - - James OBeirne 2025-06-09 11:40:00+00:00 - + 2025-09-26T14:31:05.732271+00:00 + python-feedgen + + + CTV + CSFS: a letter James O'Beirne + 2025-06-09T11:40:00.000Z + + + Michael Folkson + 2025-06-09T12:51:00.000Z + + + Matt Corallo + 2025-06-09T13:51:00.000Z + + + James O'Beirne + 2025-06-09T14:41:00.000Z + + + James O'Beirne + 2025-06-09T14:43:00.000Z + + + Michael Folkson + 2025-06-09T15:56:00.000Z + + + Matt Corallo + 2025-06-09T17:51:00.000Z + + + Antoine Poinsot' + 2025-06-09T18:55:00.000Z + + + /dev /fd0 + 2025-06-09T19:27:00.000Z + + + Matt Corallo + 2025-06-09T21:12:00.000Z + + + Andrew Poelstra + 2025-06-09T23:02:00.000Z + + + Paul Sztorc + 2025-06-10T02:02:00.000Z + + + David A. Harding + 2025-06-10T02:08:00.000Z + + + Melvin Carvalho + 2025-06-10T02:28:00.000Z + + + Greg Sanders + 2025-06-10T13:19:00.000Z + + + Andrew Poelstra + 2025-06-10T13:23:00.000Z + + + James O'Beirne + 2025-06-10T14:03:00.000Z + + + Sjors Provoost + 2025-06-10T16:56:00.000Z + + + Antoine Poinsot' + 2025-06-10T17:15:00.000Z + + + Matt Corallo + 2025-06-10T17:17:00.000Z + + + Paul Sztorc + 2025-06-10T19:04:00.000Z + + + Antoine Riard + 2025-06-10T23:42:00.000Z + + + Antoine Riard + 2025-06-10T23:42:00.000Z + + + Peter Todd + 2025-06-11T13:52:00.000Z + + + James O'Beirne + 2025-06-11T14:12:00.000Z + + + James O'Beirne + 2025-06-11T16:50:00.000Z + + + Brandon Black + 2025-06-11T18:09:00.000Z + + + James O'Beirne + 2025-06-11T18:34:00.000Z + + + Matt Corallo + 2025-06-11T20:30:00.000Z + + + Harsha Goli + 2025-06-12T00:59:00.000Z + + + Greg Maxwell + 2025-06-12T02:06:00.000Z + + + James O'Beirne + 2025-06-12T03:23:00.000Z + + + James O'Beirne + 2025-06-12T03:34:00.000Z + + + Matt Corallo + 2025-06-12T18:04:00.000Z + + + James O'Beirne + 2025-06-12T18:38:00.000Z + + + Matt Corallo + 2025-06-12T18:43:00.000Z + + + Andrew Poelstra + 2025-06-12T19:51:00.000Z + + + Matt Corallo + 2025-06-12T22:44:00.000Z + + + Antoine Riard + 2025-06-13T01:18:00.000Z + + + Anthony Towns + 2025-06-13T05:50:00.000Z + + + Anthony Towns + 2025-06-13T06:19:00.000Z + + + Jameson Lopp + 2025-06-13T11:08:00.000Z + + + Matt Corallo + 2025-06-13T12:36:00.000Z + + + Antoine Poinsot' + 2025-06-13T13:07:00.000Z + + + Harsha Goli + 2025-06-13T14:50:00.000Z + + + Jameson Lopp + 2025-06-13T15:41:00.000Z + + + Sjors Provoost + 2025-06-14T15:58:00.000Z + + + gmaxwell + 2025-06-14T16:06:00.000Z + + + Jameson Lopp + 2025-06-14T20:05:00.000Z + + + Jameson Lopp + 2025-06-14T20:17:00.000Z + + + Greg Maxwell + 2025-06-14T21:31:00.000Z + + + Sanket Kanjalkar + 2025-06-14T23:50:00.000Z + + + Greg Maxwell + 2025-06-15T00:01:00.000Z + + + Sanket Kanjalkar + 2025-06-15T00:20:00.000Z + + + Jameson Lopp + 2025-06-15T14:40:00.000Z + + + Greg Maxwell + 2025-06-15T17:43:00.000Z + + + Owen Kemeys + 2025-06-15T19:43:00.000Z + + + Steven Roose + 2025-06-17T11:22:00.000Z + + + Antoine Poinsot' + 2025-06-17T14:34:00.000Z + + + Harsha Goli + 2025-06-17T16:40:00.000Z + + + /dev /fd0 + 2025-06-17T18:19:00.000Z + + + Peter Todd + 2025-06-20T14:28:00.000Z + + + fiatjaf + 2025-06-21T12:06:00.000Z + + + Saint Wenhao + 2025-06-28T16:13:00.000Z + + @@ -259,15 +326,14 @@ - python-feedgen + 2 Combined summary - CTV + CSFS: a letter - 2025-07-01T04:15:52.183691+00:00 + 2025-09-26T14:31:05.738931+00:00 + 2025-06-28T16:13:00+00:00 The letter published advocates for the activation of OP_CHECKTEMPLATEVERIFY (BIP-119) and OP_CHECKSIGFROMSTACK (BIP-348), highlighting their potential to enhance Bitcoin's value as a scarce, censorship-resistant asset. These opcodes, which have been extensively reviewed and are considered safe and in demand, could unlock a wide array of functionalities including scaling solutions, vaults, congestion control, non-custodial mining, discreet log contracts, and more. CTV, introduced over five years ago, remains the preferred method for enforcing pregenerated transaction sequences through consensus. CSFS, utilized in Blockstream’s Elements for about eight years, complements CTV by enabling implementations like ln-symmetry for Lightning Network improvements among other use cases. - The letter requests Bitcoin Core contributors to prioritize reviewing and integrating these opcodes within six months, emphasizing that this timeline would allow for thorough review and planning for activation. It clarifies that the request is not to dictate the consensus process but acknowledges the necessity of implementing these changes in the most widely used Bitcoin client before activation. The signatories, representing a broad spectrum of application and protocol developers, express optimism about the benefits these changes could bring to Bitcoin users, especially regarding security and scaling. They believe that the minimal size and scope of these changes make them a realistic step forward in preserving Bitcoin’s promise. - 2025-06-28T16:13:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Censorship-Resistant-Transaction-Relay-Taking-out-the-garbage-man-.xml b/static/bitcoin-dev/June_2025/combined_Censorship-Resistant-Transaction-Relay-Taking-out-the-garbage-man-.xml index 567b45d919..3011ba2379 100644 --- a/static/bitcoin-dev/June_2025/combined_Censorship-Resistant-Transaction-Relay-Taking-out-the-garbage-man-.xml +++ b/static/bitcoin-dev/June_2025/combined_Censorship-Resistant-Transaction-Relay-Taking-out-the-garbage-man-.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Censorship Resistant Transaction Relay - Taking out the garbage(man) - 2025-07-01T05:46:36.202349+00:00 - - Rijndael 2025-06-06 17:38:00+00:00 - - - Sjors Provoost 2025-06-05 13:29:00+00:00 - - - Peter Todd 2025-06-05 12:16:00+00:00 - - - Peter Todd 2025-06-05 11:59:00+00:00 - - - Chris Guida 2025-06-04 20:16:00+00:00 - - - Chris Guida 2025-06-04 20:00:00+00:00 - - - Chris Guida 2025-06-04 18:44:00+00:00 - - - Sjors Provoost 2025-06-03 20:32:00+00:00 - - - Peter Todd 2025-06-03 17:58:00+00:00 - - - Sjors Provoost 2025-06-03 17:51:00+00:00 - - - Peter Todd 2025-06-03 17:41:00+00:00 - - - Sjors Provoost 2025-06-03 17:00:00+00:00 - - - Sjors Provoost 2025-06-03 06:50:00+00:00 - - - Chris Guida 2025-06-03 02:52:00+00:00 - - - John Carvalho 2025-05-27 11:37:00+00:00 - - - Peter Todd 2025-05-27 11:16:00+00:00 - + 2025-09-26T14:31:03.539128+00:00 + python-feedgen + + + Censorship Resistant Transaction Relay - Taking out the garbage(man) Peter Todd + 2025-05-27T11:16:00.000Z + + + John Carvalho + 2025-05-27T11:37:00.000Z + + + Chris Guida + 2025-06-03T02:52:00.000Z + + + Sjors Provoost + 2025-06-03T06:50:00.000Z + + + Greg Maxwell + 2025-06-03T17:00:00.000Z + + + Peter Todd + 2025-06-03T17:41:00.000Z + + + Sjors Provoost + 2025-06-03T17:51:00.000Z + + + Peter Todd + 2025-06-03T17:58:00.000Z + + + Sjors Provoost + 2025-06-03T20:32:00.000Z + + + Chris Guida + 2025-06-04T18:44:00.000Z + + + Chris Guida + 2025-06-04T20:00:00.000Z + + + Chris Guida + 2025-06-04T20:16:00.000Z + + + Peter Todd + 2025-06-05T11:59:00.000Z + + + Peter Todd + 2025-06-05T12:16:00.000Z + + + Sjors Provoost + 2025-06-05T13:29:00.000Z + + + Rijndael + 2025-06-06T17:38:00.000Z + + @@ -67,17 +86,15 @@ - python-feedgen + 2 Combined summary - Censorship Resistant Transaction Relay - Taking out the garbage(man) - 2025-07-01T05:46:36.202464+00:00 + 2025-09-26T14:31:03.541078+00:00 + 2025-06-06T17:38:00+00:00 In the realm of digital communication, censorship resistance and security are paramount. The introduction of PKDNS leverages the Mainline DHT to provide a robust framework for public-key domains, ensuring that control remains with the keyholder. This system negates the need for blockchain technology while offering functionalities such as dynamic endpoint updates, key associations, and revocable sessions. Two informative Medium articles delve into the intricacies of PKDNS, explaining its role in promoting a censorship-resistant digital landscape and elucidating the Mainline DHT's pivotal function in combating censorship. These publications aim to clarify misconceptions about public-key domains and the technological mechanisms underlying their resistance to censorship. - -Conversely, the bitcoin network faces challenges from sybil attacks aimed at disrupting transaction relaying through "garbageman" nodes. These nodes simulate offering NODE_LIBRE_RELAY service but discard transactions instead, raising operational costs for genuine Libre Relay nodes. The complexity of these attacks highlights the sophisticated strategies employed to manipulate transaction flows within the network. Bitcoin Core's existing defenses, such as the feeler node system, offer a foundation for mitigating these threats by ensuring nodes maintain connections to the most-work chain. Further proposals suggest enhancing this defense mechanism by evaluating peers based on the new transaction fees they advertise, employing cluster mempool functionality, and utilizing set-reconciliation techniques for efficient data sharing among nodes. These strategies aim to improve the network's resilience against such attacks by identifying and avoiding sybil attackers. - +Conversely, the bitcoin network faces challenges from sybil attacks aimed at disrupting transaction relaying through "garbageman" nodes. These nodes simulate offering NODE_LIBRE_RELAY service but discard transactions instead, raising operational costs for genuine Libre Relay nodes. The complexity of these attacks highlights the sophisticated strategies employed to manipulate transaction flows within the network. Bitcoin Core's existing defenses, such as the feeler node system, offer a foundation for mitigating these threats by ensuring nodes maintain connections to the most-work chain. Further proposals suggest enhancing this defense mechanism by evaluating peers based on the new transaction fees they advertise, employing cluster mempool functionality, and utilizing set-reconciliation techniques for efficient data sharing among nodes. These strategies aim to improve the network's resilience against such attacks by identifying and avoiding sybil attackers. Moreover, privacy concerns and the practice of manual peering emerge as significant considerations in strengthening the network's defenses. Direct connections among trusted nodes present a social solution to the technical challenge posed by sybil attacks, underscoring the importance of community trust and cooperation in maintaining the integrity of transaction relaying channels. This multi-faceted approach reflects the bitcoin community's dedication to preserving the network's open and reliable transaction propagation system against sophisticated external threats. - 2025-06-06T17:38:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml b/static/bitcoin-dev/June_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml index 9592354c5c..4c3dbb5ad3 100644 --- a/static/bitcoin-dev/June_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml +++ b/static/bitcoin-dev/June_2025/combined_DahLIAS-Discrete-Logarithm-Based-Interactive-Aggregate-Signatures.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures - 2025-07-18T03:07:52.835406+00:00 - - Jonas Nick 2025-07-17 13:15:00+00:00 - - - waxwing/ AdamISZ 2025-07-03 14:07:00+00:00 - - - Tim Ruffing 2025-07-02 11:36:00+00:00 - - - waxwing/ AdamISZ 2025-06-16 19:35:00+00:00 - - - waxwing/ AdamISZ 2025-04-30 15:54:00+00:00 - - - Jonas Nick 2025-04-30 07:59:00+00:00 - - - waxwing/ AdamISZ 2025-04-26 17:05:00+00:00 - - - waxwing/ AdamISZ 2025-04-26 15:30:00+00:00 - - - Jonas Nick 2025-04-25 16:41:00+00:00 - - - waxwing/ AdamISZ 2025-04-25 16:08:00+00:00 - - - Jonas Nick 2025-04-22 15:29:00+00:00 - - - waxwing/ AdamISZ 2025-04-19 16:28:00+00:00 - - - Jonas Nick 2025-04-17 16:27:00+00:00 - + 2025-09-26T14:31:10.008083+00:00 + python-feedgen + + + DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures Jonas Nick + 2025-04-17T16:27:00.000Z + + + waxwing/ AdamISZ + 2025-04-19T16:28:00.000Z + + + Jonas Nick + 2025-04-22T15:29:00.000Z + + + waxwing/ AdamISZ + 2025-04-25T16:08:00.000Z + + + Jonas Nick + 2025-04-25T16:41:00.000Z + + + waxwing/ AdamISZ + 2025-04-26T15:30:00.000Z + + + waxwing/ AdamISZ + 2025-04-26T17:05:00.000Z + + + Jonas Nick + 2025-04-30T07:59:00.000Z + + + waxwing/ AdamISZ + 2025-04-30T15:54:00.000Z + + + waxwing/ AdamISZ + 2025-06-16T19:35:00.000Z + + + Tim Ruffing + 2025-07-02T11:36:00.000Z + + + waxwing/ AdamISZ + 2025-07-03T14:07:00.000Z + + + Jonas Nick + 2025-07-17T13:15:00.000Z + + @@ -55,21 +71,17 @@ - python-feedgen + 2 Combined summary - DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures - 2025-07-18T03:07:52.835505+00:00 + 2025-09-26T14:31:10.009581+00:00 + 2025-07-17T13:15:00+00:00 The conversation between AdamISZ/waxwing and Tim delves into the intricacies of cryptographic signing protocols, focusing on their application in Bitcoin but acknowledging broader uses beyond blockchain technology. They discuss the efficiency of a signing protocol that reduces the computational demand by changing from constant time operations to ones that scale with the number of participants, considering trade-offs between signing and verification performance. The dialogue touches on the importance of designing systems that manage scaling effectively, especially for devices with limited computational resources. The exchange also explores the potential benefits of algebraic algorithms in cryptographic processes, highlighting their ease of integration into circuits for zero-knowledge proofs and their operational efficiencies due to fewer conditional branches or loops. - Further analysis on cryptographic protocols examines the security implications and operational efficiencies of using distinct ephemeral identifiers across participants. The discussion contrasts the computational inefficiencies introduced by this approach against the streamlined process achieved by employing a singular identifier, emphasizing the latter's advantages in reducing computation time without sacrificing security. This choice is framed within the context of enhancing transaction efficiency on the blockchain without introducing significant increases in signature size or verification costs. Additionally, the discourse addresses concerns related to ensuring the integrity of the signing process, particularly in identifying and mitigating disruptive behavior among participants, underscoring the necessity of honest coordinators and secure communication channels. - -A detailed exploration into cryptographic verification mechanisms reveals an innovative perspective on nonce reuse and its security ramifications, particularly comparing MuSig2 and DahLIAS protocols. The discussions shed light on DahLIAS's flexibility in verification processes, allowing for multiple public keys and messages as inputs, which diverges from MuSig2's rigid structure. This adaptability not only expands DahLIAS’s applicability but also introduces a nuanced layer of security by preventing attackers from exploiting nonce reuse through variable "b" values for each participant. This aspect underscores the ongoing efforts to refine cryptographic protocols, ensuring robust security against sophisticated attack vectors. - +A detailed exploration into cryptographic verification mechanisms reveals an innovative perspective on nonce reuse and its security ramifications, particularly comparing MuSig2 and DahLIAS protocols. The discussions shed light on DahLIAS's flexibility in verification processes, allowing for multiple public keys and messages as inputs, which diverges from MuSig2's rigid structure. This adaptability not only expands DahLIAS’s applicability but also introduces a nuanced layer of security by preventing attackers from exploiting nonce reuse through variable "b" values for each participant. This aspect underscores the ongoing efforts to refine cryptographic protocols, ensuring robust security against sophisticated attack vectors. The email exchanges delve into the theoretical underpinnings and practical considerations of cryptographic optimizations, emphasizing the significance of not compromising on security while seeking operational efficiencies. The discourse covers the security theorem for DahLIAS, highlighting its robustness against attacks unless specific cryptographic assumptions are violated. Additionally, the conversations pivot towards practical optimizations for single-party signers and the inclusion of such methodologies in academic papers versus Bitcoin Improvement Proposals (BIPs), arguing for a broader applicational relevance that warrants academic scrutiny. - Lastly, the discussions encapsulate a comprehensive overview of the CISA algorithm and its potential to streamline blockchain transactions by optimizing signature processes. This includes a nuanced analysis of nonce handling and the security considerations associated with aggregate signatures, particularly focusing on the compatibility with key tweaking and the implications for operational efficiency and security. The dialogue also extends to client-side validation concepts, proposing strategies to mitigate risks and enhance the security framework for digital signatures within the blockchain domain. - 2025-07-17T13:15:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Draft-BIP-Well-Known-Bitcoin-Identity-Endpoint.xml b/static/bitcoin-dev/June_2025/combined_Draft-BIP-Well-Known-Bitcoin-Identity-Endpoint.xml index a0b4770b66..38c133a00e 100644 --- a/static/bitcoin-dev/June_2025/combined_Draft-BIP-Well-Known-Bitcoin-Identity-Endpoint.xml +++ b/static/bitcoin-dev/June_2025/combined_Draft-BIP-Well-Known-Bitcoin-Identity-Endpoint.xml @@ -1,35 +1,40 @@ - + 2 Combined summary - Draft BIP: Well-Known Bitcoin Identity Endpoint - 2025-07-01T05:41:13.631024+00:00 - - Murch 2025-06-02 19:32:00+00:00 - - - hodlinator 2025-06-02 18:20:00+00:00 - - - hodlinator 2025-06-02 12:40:00+00:00 - - - Aviv Barel 2025-05-26 12:50:00+00:00 - + 2025-09-26T14:30:57.128512+00:00 + python-feedgen + + + Draft BIP: Well-Known Bitcoin Identity Endpoint Aviv Bar-el + 2025-05-26T12:50:00.000Z + + + hodlinator' + 2025-06-02T12:40:00.000Z + + + hodlinator' + 2025-06-02T18:20:00.000Z + + + Murch + 2025-06-02T19:32:00.000Z + + - python-feedgen + 2 Combined summary - Draft BIP: Well-Known Bitcoin Identity Endpoint - 2025-07-01T05:41:13.631076+00:00 + 2025-09-26T14:30:57.129164+00:00 - The recent discussions within the Bitcoin Development Mailing List have brought to light AvivB's draft for a Bitcoin Improvement Proposal (BIP) aimed at refining the transaction processes within the Bitcoin ecosystem. The proposal, known as the "Well-Known Bitcoin Identity Endpoint," proposes an innovative approach to enhance on-chain payment transactions by adopting a simple, HTTPS-based protocol. This protocol is designed to facilitate the discovery and retrieval of payment and contact information related to Lightning Addresses. By implementing such a mechanism, the proposal seeks to streamline transaction experiences, making them smoother and more efficient for users. Additionally, it extends the functionality beyond mere payment processing to include various types of payments and identity metadata, thereby broadening its application and utility in the digital currency sphere. - + 2025-06-02T19:32:00+00:00 + The recent discussions within the Bitcoin Development Mailing List have brought to light AvivB's draft for a Bitcoin Improvement Proposal (BIP) aimed at refining the transaction processes within the Bitcoin ecosystem. The proposal, known as the "Well-Known Bitcoin Identity Endpoint," proposes an innovative approach to enhance on-chain payment transactions by adopting a simple, HTTPS-based protocol. This protocol is designed to facilitate the discovery and retrieval of payment and contact information related to Lightning Addresses. By implementing such a mechanism, the proposal seeks to streamline transaction experiences, making them smoother and more efficient for users. Additionally, it extends the functionality beyond mere payment processing to include various types of payments and identity metadata, thereby broadening its application and utility in the digital currency sphere. AvivB's initiative to generalize the method used by Lightning Address emphasizes the potential benefits of simplifying user interactions with blockchain technology. This includes making transaction executions and access to essential information more straightforward. The proposed BIP highlights an ongoing effort to innovate and improve the cryptocurrency community's infrastructure, focusing on user-friendliness and efficiency in Bitcoin payments. Interested parties are encouraged to review and contribute to the refinement of this proposal. The draft BIP, which outlines the specifics of this innovative approach and serves as a basis for further development, is available for public viewing and feedback [here](https://github.com/aviv57/paysats/blob/main/bip/BIPXXX.MD). - Feedback from other programmers, like Murch, points out the importance of clearly differentiating this proposal from existing schemes, such as the Lightning Address and LNURL, to avoid confusion due to similarities in formatting. Moreover, there's an acknowledgment of the need to clarify how the proposed system would communicate paysats distinctly from these existing formats. Such constructive feedback suggests that while the proposal is a solid starting point, further clarification and differentiation could enhance its clarity and effectiveness. - 2025-06-02T19:32:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Full-Disclosure-CVE-2025-27586-No-Santa-Claus-under-the-Lightning-Sun-.xml b/static/bitcoin-dev/June_2025/combined_Full-Disclosure-CVE-2025-27586-No-Santa-Claus-under-the-Lightning-Sun-.xml index e189f9234c..bdd0cd3d9c 100644 --- a/static/bitcoin-dev/June_2025/combined_Full-Disclosure-CVE-2025-27586-No-Santa-Claus-under-the-Lightning-Sun-.xml +++ b/static/bitcoin-dev/June_2025/combined_Full-Disclosure-CVE-2025-27586-No-Santa-Claus-under-the-Lightning-Sun-.xml @@ -1,35 +1,37 @@ - + 2 - Combined summary - Full-Disclosure: CVE-2025-27586 "No Santa Claus under the Lightning Sun" - 2025-07-01T06:00:51.060172+00:00 - - Antoine Riard 2025-06-19 04:56:00+00:00 - - - David A. Harding 2025-06-18 02:16:00+00:00 - - - Antoine Riard 2025-06-12 19:03:00+00:00 - + Combined summary - Full-Disclosure: CVE-2025-27586 "No Santa Claus under the Lightning Sun" + 2025-09-26T14:31:14.303671+00:00 + python-feedgen + + + Full-Disclosure: CVE-2025-27586 "No Santa Claus under the Lightning Sun" Antoine Riard + 2025-06-12T19:03:00.000Z + + + David A. Harding + 2025-06-18T02:16:00.000Z + + + Antoine Riard + 2025-06-19T04:56:00.000Z + + - python-feedgen + 2 - Combined summary - Full-Disclosure: CVE-2025-27586 "No Santa Claus under the Lightning Sun" - 2025-07-01T06:00:51.060233+00:00 + Combined summary - Full-Disclosure: CVE-2025-27586 "No Santa Claus under the Lightning Sun" + 2025-09-26T14:31:14.304251+00:00 + 2025-06-19T04:56:00+00:00 The discourse presents a comprehensive overview of a newly disclosed vulnerability affecting Bitcoin's time-sensitive contract protocols, specifically targeting the Lightning Network (LN) through what is referred to as fee-bumping reserves exhaustion attacks. This vector of attack leverages the absence of a well-defined mechanism for provisioning fee reserves necessary for the timely inclusion of transactions, particularly under the `option_anchor` channels upgrade. The issue roots back to early deployments of anchor outputs across the network around the end of 2020, with discussions among LN maintainers surfacing by mid-2022. Despite some mitigations being developed and implemented across various LN implementations, the consensus suggests that a more robust, protocol-level solution is required yet appears unlikely due to the complexity of implementing such changes within an embargoed process. - Anchor outputs were introduced to allow non-interactive fee bumping via CPFP (Child Pays For Parent) transactions, enabling nodes to increase transaction fees unilaterally to ensure timeliness in block inclusion—critical for operations like claiming HTLCs (Hash Time-Locked Contracts). However, the initial specifications did not address how nodes should manage or provision external fee-bumping reserves, leading to potential vulnerabilities where an attacker could deliberately exhaust a node's fee reserves through channel inflation tactics. Such actions could jeopardize the ability of a node to perform necessary transactions before HTLC expiry, thus posing a risk of financial loss. - Key to exploiting this vulnerability is the adversary's ability to estimate a target node's fee-bumping reserve levels, a task that can be approached through heuristic methods such as monitoring unilateral force-closures or analyzing on-chain behavior related to UTXO management. Mitigation strategies involve over-provisioning fee reserves based on worst-case scenarios, halting the growth of a node's overall channel weight surface, and cooperative efforts among LN nodes to reduce commitment transaction sizes. - This disclosure emphasizes the ongoing challenges within the LN ecosystem regarding dynamic fee management and highlights the need for collective action towards developing and adopting more comprehensive solutions to safeguard against such vulnerabilities. The report, including its background, problem statement, potential impact, and proposed mitigations, is made publicly available [here](https://ariard.github.io/feebumping.html), alongside a call for further research and collaboration within the community to address these critical issues. - In conclusion, the revelation of CVE-2025-27586 signifies a pivotal moment for the Lightning Network and Bitcoin's underlying security framework, underscoring the delicate balance between innovation and the requisite safeguards needed to protect the network and its participants from sophisticated threats. - 2025-06-19T04:56:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml b/static/bitcoin-dev/June_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml index a6b106d244..9a7a0b8638 100644 --- a/static/bitcoin-dev/June_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml +++ b/static/bitcoin-dev/June_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Hashed keys are actually fully quantum secure - 2025-07-01T05:35:10.635886+00:00 - - conduition 2025-06-02 18:29:00+00:00 - - - Nagaev Boris 2025-05-26 10:03:00+00:00 - - - conduition 2025-05-25 18:22:00+00:00 - - - Martin Habovštiak 2025-03-30 20:16:00+00:00 - - - Martin Habovštiak 2025-03-30 20:11:00+00:00 - - - David A. Harding 2025-03-30 15:41:00+00:00 - - - Lloyd Fournier 2025-03-24 00:24:00+00:00 - - - Erik Aronesty 2025-03-18 16:48:00+00:00 - - - Martin Habovštiak 2025-03-17 11:07:00+00:00 - - - Lloyd Fournier 2025-03-17 10:44:00+00:00 - - - Martin Habovštiak 2025-03-16 20:52:00+00:00 - - - Agustin Cruz 2025-03-16 19:03:00+00:00 - - - Martin Habovštiak 2025-03-16 18:50:00+00:00 - - - Martin Habovštiak 2025-03-16 18:25:00+00:00 - + 2025-09-26T14:30:48.561692+00:00 + python-feedgen + + + Hashed keys are actually fully quantum secure Martin Habovštiak + 2025-03-16T18:25:00.000Z + + + Antoine Poinsot' + 2025-03-16T18:50:00.000Z + + + Agustin Cruz + 2025-03-16T19:03:00.000Z + + + Martin Habovštiak + 2025-03-16T20:52:00.000Z + + + Lloyd Fournier + 2025-03-17T10:44:00.000Z + + + Martin Habovštiak + 2025-03-17T11:07:00.000Z + + + Erik Aronesty + 2025-03-18T16:48:00.000Z + + + Lloyd Fournier + 2025-03-24T00:24:00.000Z + + + David A. Harding + 2025-03-30T15:41:00.000Z + + + Martin Habovštiak + 2025-03-30T20:11:00.000Z + + + Martin Habovštiak + 2025-03-30T20:16:00.000Z + + + conduition' + 2025-05-25T18:22:00.000Z + + + Nagaev Boris + 2025-05-26T10:03:00.000Z + + + conduition' + 2025-06-02T18:29:00.000Z + + @@ -59,23 +76,18 @@ - python-feedgen + 2 Combined summary - Hashed keys are actually fully quantum secure - 2025-07-01T05:35:10.635989+00:00 + 2025-09-26T14:30:48.563298+00:00 + 2025-06-02T18:29:00+00:00 The series of discussions within the Bitcoin Development Mailing List covers a wide range of technical proposals and security concerns aimed at enhancing the resilience of Bitcoin in the face of evolving threats, particularly those posed by quantum computing. One focal point is the exploration of innovative mechanisms to safeguard transactions through cryptographic adjustments, such as employing Quantum Resistant (QR) signatures and committing to these within the blockchain infrastructure. This approach underscores a proactive strategy to prevent potential attackers from exploiting vulnerabilities inherent in current cryptographic practices, especially considering the advent of quantum computing capabilities. - A significant portion of the dialogue delves into the intricacies of implementing these security measures, including the technical feasibility of embedding QR signature commitments in transaction processes. The discussions reveal a consensus on the necessity for a soft fork to introduce such enhancements, highlighting the community's readiness to adapt the Bitcoin protocol to mitigate these advanced threats. The conversation also touches upon the procedural and technical requirements for deploying QR signing algorithms, reflecting a broader commitment to securing the cryptocurrency against irrevocable loss due to quantum attacks. - -Moreover, the dialogue extends into the tactical aspects of ensuring transactional integrity and security. For instance, the concept of providing a "head start" for transactions to preempt quantum computational attacks illustrates a nuanced approach to maintaining the competitiveness and security of legitimate transactions within the network. This idea, coupled with the integration of a robust Replace-By-Fee (RBF) mechanism, represents an adaptive response to the dynamic challenges facing Bitcoin's security framework. - +Moreover, the dialogue extends into the tactical aspects of ensuring transactional integrity and security. For instance, the concept of providing a "head start" for transactions to preempt quantum computational attacks illustrates a nuanced approach to maintaining the competitiveness and security of legitimate transactions within the network. This idea, coupled with the integration of a robust Replace-By-Fee (RBF) mechanism, represents an adaptive response to the dynamic challenges facing Bitcoin's security framework. Additionally, the discussions underscore the importance of collaborative efforts and the exchange of ideas among developers to refine and evolve Bitcoin's defensive strategies. The examination of Taproot's hashing functionalities and its implications for address reuse and system flexibility indicates a deep engagement with both the technical and social dimensions of cryptocurrency security. These conversations illuminate the complexities of balancing technical innovation with practical implementation and user adoption. - Furthermore, the discourse around the potential need for a soft fork to disallow the spending of bare public keys, leveraging the security benefits of Taproot keys against quantum threats, reflects a strategic foresight. This discussion emphasizes the critical role of community consensus in timing and executing such a significant protocol change, underscoring the challenges of navigating the uncertain terrain of quantum computing advancements. - In conclusion, the exchanges within the Bitcoin Development Mailing List highlight a multifaceted approach to enhancing Bitcoin's security. From addressing quantum computing threats with QR signatures to refining transaction mechanisms for improved resilience, the community's engagement with these issues showcases a proactive and collaborative effort to fortify Bitcoin against future vulnerabilities. The ongoing dialogue signifies an acknowledgment of the nuanced challenges at the intersection of technology, security, and consensus-building, laying the groundwork for continued innovation and adaptation in the cryptocurrency's protocol and practices. - 2025-06-02T18:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_OP-CAT-Enables-Winternitz-Signatures.xml b/static/bitcoin-dev/June_2025/combined_OP-CAT-Enables-Winternitz-Signatures.xml index 5a19fe291d..945297338d 100644 --- a/static/bitcoin-dev/June_2025/combined_OP-CAT-Enables-Winternitz-Signatures.xml +++ b/static/bitcoin-dev/June_2025/combined_OP-CAT-Enables-Winternitz-Signatures.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - OP_CAT Enables Winternitz Signatures - 2025-07-10T02:59:31.290814+00:00 - - Jonas Nick 2025-07-08 08:07:00+00:00 - - - conduition 2025-07-08 07:03:00+00:00 - - - conduition 2025-07-08 00:49:00+00:00 - - - conduition 2025-07-08 00:16:00+00:00 - - - Jonas Nick 2025-07-07 10:40:00+00:00 - - - Anthony Towns 2025-07-05 12:18:00+00:00 - - - conduition 2025-06-09 15:31:00+00:00 - - - conduition 2025-06-08 03:20:00+00:00 - + 2025-09-26T14:30:52.860424+00:00 + python-feedgen + + + OP_CAT Enables Winternitz Signatures 'conduition' + 2025-06-08T03:20:00.000Z + + + conduition' + 2025-06-09T15:31:00.000Z + + + Anthony Towns + 2025-07-05T12:18:00.000Z + + + Jonas Nick + 2025-07-07T10:40:00.000Z + + + conduition' + 2025-07-08T00:16:00.000Z + + + conduition' + 2025-07-08T00:49:00.000Z + + + conduition' + 2025-07-08T07:03:00.000Z + + + Jonas Nick + 2025-07-08T08:07:00.000Z + + @@ -35,21 +46,17 @@ - python-feedgen + 2 Combined summary - OP_CAT Enables Winternitz Signatures - 2025-07-10T02:59:31.290881+00:00 + 2025-09-26T14:30:52.861380+00:00 + 2025-07-08T08:07:00+00:00 The discussion within the Bitcoin Development Mailing List focuses on enhancing the efficiency and security of digital transaction signatures, particularly through the implementation and optimization of cryptographic signature schemes. The conversation begins with an analysis of the fixed-sum Winternitz one-time signature scheme (WOTS), emphasizing the selection of specific parameters to ensure the integrity of digital transactions. The optimal checksum calculation for efficient signing, avoiding the use of random salt counters, and considerations for employing less collision-resistant hashing algorithms for efficiency gains are central themes. The dialogue also explores the feasibility of using a combination of RMD160 and SHA256 hashing functions to reduce witness size in transactions while maintaining adequate collision resistance. - Further technical exchanges propose improvements in Bitcoin script efficiency through strategic use of OP codes, leading to significant reductions in script sizes. A transformative suggestion involves substituting certain operations with OP_LSHIFT, achieving a reduction in byte usage and overall script and witness size. This optimization, detailed in a shared [gist](https://gist.github.com/conduition/c6fd78e90c21f669fad7e3b5fe113182file-winternitz-ts-L100-L137), highlights the collaborative and innovative efforts within the community to refine Bitcoin scripting capabilities. - The conversation extends to methods for reducing signature sizes and improving verification costs, juxtaposing different constructions and their implications for blockchain applications. A focus on preimage resistance over collision resistance, informed by quantum computing considerations, underpins discussions about the potential of various Winternitz variants. The standardization of W-OTS+ as part of XMSS and its secure variants is mentioned as a critical point of reference. - Technical suggestions for optimizing conversion processes from four-bit pair to eight-bit format are introduced, alongside a brief mention of operational issues affecting transaction processing due to server downtime. This encapsulates a broader discussion on the necessity for smaller, quantum-resistant signature schemes to maintain network efficiency without increasing block size. Lattice-based cryptography emerges as a promising avenue for quantum resistance, with current hash-based alternatives considered temporary solutions pending the discovery of more efficient signature schemes. - Jeremy Rubin's work on enabling Lamport signatures through OP_CAT, leading to discussions around Winternitz One Time Signatures (WOTS) as a more compact alternative, signifies an ongoing exploration of post-quantum cryptographic solutions. The development and testing of prototype implementations, along with suggestions for further optimization, reflect the community's proactive approach to addressing the challenges posed by quantum computing. The sharing of resources and collaborative problem-solving efforts underscore the commitment to advancing cryptographic techniques within the Bitcoin development ecosystem. - 2025-07-08T08:07:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork.xml b/static/bitcoin-dev/June_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork.xml index 95faa02616..72d71d165c 100644 --- a/static/bitcoin-dev/June_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork.xml +++ b/static/bitcoin-dev/June_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Post-Quantum commit / reveal Fawkescoin variant as a soft fork - 2025-07-01T05:49:14.290234+00:00 - - conduition 2025-06-05 14:33:00+00:00 - - - Nagaev Boris 2025-06-02 22:50:00+00:00 - - - conduition 2025-06-02 19:34:00+00:00 - - - Jonathan Voss 2025-06-02 18:54:00+00:00 - - - waxwing/ AdamISZ 2025-06-02 17:38:00+00:00 - - - Q C 2025-06-02 15:50:00+00:00 - - - Peter Todd 2025-06-02 11:24:00+00:00 - - - waxwing/ AdamISZ 2025-05-31 16:07:00+00:00 - - - Jonathan Voss 2025-05-30 22:00:00+00:00 - - - Nagaev Boris 2025-05-28 20:24:00+00:00 - - - Sergio Demian Lerner 2025-05-28 18:20:00+00:00 - - - Tadge Dryja 2025-05-28 17:14:00+00:00 - + 2025-09-26T14:31:18.607274+00:00 + python-feedgen + + + Post-Quantum commit / reveal Fawkescoin variant as a soft fork Tadge Dryja + 2025-05-28T17:14:00.000Z + + + Sergio Demian Lerner + 2025-05-28T18:20:00.000Z + + + Nagaev Boris + 2025-05-28T20:24:00.000Z + + + Jonathan Voss + 2025-05-30T22:00:00.000Z + + + waxwing/ AdamISZ + 2025-05-31T16:07:00.000Z + + + Peter Todd + 2025-06-02T11:24:00.000Z + + + Q C + 2025-06-02T15:50:00.000Z + + + waxwing/ AdamISZ + 2025-06-02T17:38:00.000Z + + + Jonathan Voss + 2025-06-02T18:54:00.000Z + + + conduition' + 2025-06-02T19:34:00.000Z + + + Nagaev Boris + 2025-06-02T22:50:00.000Z + + + conduition' + 2025-06-05T14:33:00.000Z + + @@ -51,21 +66,17 @@ - python-feedgen + 2 Combined summary - Post-Quantum commit / reveal Fawkescoin variant as a soft fork - 2025-07-01T05:49:14.290329+00:00 + 2025-09-26T14:31:18.608658+00:00 - In recent discussions among Bitcoin developers, there's been a significant focus on enhancing the cryptocurrency's security in anticipation of advances in quantum computing. A proposed method to address this concern involves a commit/reveal scheme designed to secure Bitcoin transactions against potential quantum computer attacks. This approach is aimed at protecting users' funds by introducing a system where a wallet, potentially compromised by quantum capabilities, would execute a "commitment transaction" followed by a "reveal transaction," thereby moving the funds to a new, quantum-resistant script. This process is intended for wallets finding themselves suddenly vulnerable to quantum threats, ensuring that Bitcoin transactions remain secure and mostly unchanged for everyday use. - + 2025-06-05T14:33:00+00:00 + In recent discussions among Bitcoin developers, there's been a significant focus on enhancing the cryptocurrency's security in anticipation of advances in quantum computing. A proposed method to address this concern involves a commit/reveal scheme designed to secure Bitcoin transactions against potential quantum computer attacks. This approach is aimed at protecting users' funds by introducing a system where a wallet, potentially compromised by quantum capabilities, would execute a "commitment transaction" followed by a "reveal transaction," thereby moving the funds to a new, quantum-resistant script. This process is intended for wallets finding themselves suddenly vulnerable to quantum threats, ensuring that Bitcoin transactions remain secure and mostly unchanged for everyday use. The conversation also touched upon the possibility of incorporating future quantum-resistant (QR) signing algorithms into Bitcoin's existing architecture, like adding a new opcode to tapscript to facilitate QR signing. This would necessitate the creation of a new address type capable of handling both current EC opcodes and future QR algorithms, suggesting a complex yet forward-looking amendment to Bitcoin's security framework. However, concerns were raised regarding the practicality of such solutions, including the necessity of commitments being visible on-chain to prevent duplication and ensure the integrity of the commitment process. This visibility requirement could hinder the aggregation of commitments, thus raising scalability issues. - Another perspective highlighted the potential limitations of Bitcoin as a monetary network if it requires out-of-band payments to validate transactions. The critique suggests that relying on external mechanisms could compromise Bitcoin's self-sufficiency and undermine its foundational principles as a peer-to-peer electronic cash system. This sentiment underscores the importance of developing solutions that maintain Bitcoin's autonomy and inherent value as a decentralized financial system. - Furthermore, the discussion ventured into technical specifics concerning the structure and security of commit/reveal schemes. It addressed potential vulnerabilities to quantum attacks, especially during the reveal phase, and suggested alternatives like Pedersen commitments for their hiding properties, despite their susceptibility to quantum decryption. The discourse reflects a proactive approach to ensuring Bitcoin's resilience against evolving technological threats, emphasizing the need for a secure, quantum-resistant framework that adheres to the cryptocurrency's core objectives and design principles. - In summary, the ongoing dialogue among Bitcoin developers illustrates a concerted effort to preemptively address the challenges posed by quantum computing. By exploring various strategies, from commit/reveal protocols to the integration of quantum-resistant algorithms, the community aims to fortify Bitcoin's security infrastructure for the future. These discussions highlight the critical balance between innovation and pragmatism, striving to protect the cryptocurrency against potential threats while preserving its fundamental characteristics and utility. - 2025-06-05T14:33:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Pre-emptive-commit-reveal-for-quantum-safe-migration-poison-pill-.xml b/static/bitcoin-dev/June_2025/combined_Pre-emptive-commit-reveal-for-quantum-safe-migration-poison-pill-.xml index 3c379f70bf..5fa24b33e4 100644 --- a/static/bitcoin-dev/June_2025/combined_Pre-emptive-commit-reveal-for-quantum-safe-migration-poison-pill-.xml +++ b/static/bitcoin-dev/June_2025/combined_Pre-emptive-commit-reveal-for-quantum-safe-migration-poison-pill-.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - Pre-emptive commit/reveal for quantum-safe migration (poison-pill) - 2025-07-01T05:54:13.942780+00:00 - - conduition 2025-06-09 16:29:00+00:00 - - - Leo Wandersleb 2025-06-05 15:22:00+00:00 - - - Leo Wandersleb 2025-06-05 15:12:00+00:00 - - - conduition 2025-06-05 15:01:00+00:00 - - - Boris Nagaev 2025-06-05 14:54:00+00:00 - - - Leo Wandersleb 2025-06-05 08:18:00+00:00 - - - Boris Nagaev 2025-06-04 18:38:00+00:00 - - - Leo Wandersleb 2025-06-04 17:39:00+00:00 - - - Leo Wandersleb 2025-06-04 17:14:00+00:00 - - - Nagaev Boris 2025-06-03 21:49:00+00:00 - - - Tim Ruffing 2025-06-03 19:49:00+00:00 - - - Leo Wandersleb 2025-06-03 17:26:00+00:00 - - - conduition 2025-06-03 15:15:00+00:00 - - - Leo Wandersleb 2025-06-03 11:51:00+00:00 - - - Leo Wandersleb 2025-06-03 04:19:00+00:00 - - - Nagaev Boris 2025-06-02 23:11:00+00:00 - - - Leo Wandersleb 2025-06-02 21:06:00+00:00 - + 2025-09-26T14:30:50.711855+00:00 + python-feedgen + + + Pre-emptive commit/reveal for quantum-safe migration (poison-pill) Leo Wandersleb + 2025-06-02T21:06:00.000Z + + + Nagaev Boris + 2025-06-02T23:11:00.000Z + + + Leo Wandersleb + 2025-06-03T04:19:00.000Z + + + Leo Wandersleb + 2025-06-03T11:51:00.000Z + + + conduition' + 2025-06-03T15:15:00.000Z + + + Leo Wandersleb + 2025-06-03T17:26:00.000Z + + + Tim Ruffing + 2025-06-03T19:49:00.000Z + + + Nagaev Boris + 2025-06-03T21:49:00.000Z + + + Leo Wandersleb + 2025-06-04T17:14:00.000Z + + + Leo Wandersleb + 2025-06-04T17:39:00.000Z + + + Boris Nagaev + 2025-06-04T18:38:00.000Z + + + Leo Wandersleb + 2025-06-05T08:18:00.000Z + + + Boris Nagaev + 2025-06-05T14:54:00.000Z + + + conduition' + 2025-06-05T15:01:00.000Z + + + Leo Wandersleb + 2025-06-05T15:12:00.000Z + + + Leo Wandersleb + 2025-06-05T15:22:00.000Z + + + conduition' + 2025-06-09T16:29:00.000Z + + @@ -71,23 +91,18 @@ - python-feedgen + 2 Combined summary - Pre-emptive commit/reveal for quantum-safe migration (poison-pill) - 2025-07-01T05:54:13.942896+00:00 + 2025-09-26T14:30:50.713905+00:00 + 2025-06-09T16:29:00+00:00 The discussion across various emails among Bitcoin developers focuses on the development and refinement of quantum-resistant strategies for Bitcoin transactions. The conversation delves into several key proposals and technical clarifications aimed at ensuring the security of Bitcoin in a post-quantum computing era. One significant proposal is the commit/reveal scheme, which has been analyzed and critiqued for its potential effectiveness against quantum attacks. - One aspect of the debate centers around the idea of making pre-emptive commitments to future transactions that would migrate funds to quantum-safe addresses without revealing which UTXOs (Unspent Transaction Outputs) are controlled by the user. This method involves creating and signing transactions ahead of time, then publishing only the root hash of a Merkle tree of these transactions in an OP_RETURN transaction. Such an approach could be implemented immediately, without requiring consensus changes, preserving privacy, and offering flexibility depending on whether quantum threats materialize as anticipated. - Critics of the initial commit/reveal proposal raised concerns regarding the duplication of transaction data on-chain and the complexity of implementing such a system without substantial modifications to existing node operations. There's a preference for a solution that doesn't necessitate nodes to independently track commitments, reveals, and counter-reveals, advocating instead for a more space-efficient method that avoids convoluted stages in transaction verification. - -Another proposal elaborated during the discussions introduces a variant to the commit/reveal approach, aiming to protect both unrevealed and bare pubkeys. It suggests using announcements containing necessary information like the UTXO, wTXID, and a proof, stored in an OP_RETURN output. The rule for this hypothetical soft fork would mandate the presence of an announcement with the corresponding wTXID and valid proof published a certain number of blocks earlier to spend an EC output. This design aims to prevent malicious blocking of coins by attackers and does not institute an "earliest announcement wins" rule but rather allows any valid announcement that meets the time requirement to win once sufficiently buried. - +Another proposal elaborated during the discussions introduces a variant to the commit/reveal approach, aiming to protect both unrevealed and bare pubkeys. It suggests using announcements containing necessary information like the UTXO, wTXID, and a proof, stored in an OP_RETURN output. The rule for this hypothetical soft fork would mandate the presence of an announcement with the corresponding wTXID and valid proof published a certain number of blocks earlier to spend an EC output. This design aims to prevent malicious blocking of coins by attackers and does not institute an "earliest announcement wins" rule but rather allows any valid announcement that meets the time requirement to win once sufficiently buried. Further dialogue touches on the importance of ensuring any commitment mechanism includes complete transaction data, including witness data, to prevent attackers from preemptively committing to unsigned transactions. There's also a discussion about how frequently users would need to update their commitments as their UTXO sets change and the implications for scalability and privacy. - Overall, the conversation highlights the community's ongoing efforts to proactively address the potential threat posed by quantum computing to the Bitcoin network's security. Developers are exploring innovative solutions that balance security, efficiency, and backward compatibility, acknowledging the challenges of implementing such measures without disrupting the existing blockchain ecosystem. - 2025-06-09T16:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Proposal-Self-Verifiable-Transaction-Broadcast-Log-for-Enhanced-User-Transparency.xml b/static/bitcoin-dev/June_2025/combined_Proposal-Self-Verifiable-Transaction-Broadcast-Log-for-Enhanced-User-Transparency.xml index bb995ef9bd..3b34fc60ca 100644 --- a/static/bitcoin-dev/June_2025/combined_Proposal-Self-Verifiable-Transaction-Broadcast-Log-for-Enhanced-User-Transparency.xml +++ b/static/bitcoin-dev/June_2025/combined_Proposal-Self-Verifiable-Transaction-Broadcast-Log-for-Enhanced-User-Transparency.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency - 2025-07-30T03:13:45.493672+00:00 - - Murch 2025-07-29 22:55:00+00:00 - - - wang wang 2025-06-16 09:57:00+00:00 - + 2025-09-26T14:31:16.417019+00:00 + python-feedgen + + + Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency wang wang + 2025-06-16T09:57:00.000Z + + + Murch + 2025-07-29T22:55:00.000Z + + - python-feedgen + 2 Combined summary - Proposal: Self-Verifiable Transaction Broadcast Log for Enhanced User Transparency - 2025-07-30T03:13:45.493719+00:00 + 2025-09-26T14:31:16.417505+00:00 + 2025-07-29T22:55:00+00:00 The email from Liang to the Bitcoin developers outlines a detailed proposal for enhancing user experience and auditability within Bitcoin node software, specifically addressing concerns related to transactions that have been orphaned or dropped. Liang proposes the introduction of a *Self-Verifiable Transaction Broadcast Log*, which aims to serve as an opt-in feature allowing nodes to record all accepted transactions for broadcast, inclusive of timestamps and source details. This proposed feature is designed to assist users and wallets in verifying transactions that may have been dropped, reorganized, or failed to confirm, without impacting consensus behavior. The log, according to Liang, would be equipped with filtering capabilities and accessible through a new RPC call (`getbroadcastedtxs`), enabling users to manage it according to their needs. - Liang's motivation for this proposal is rooted in personal experience, highlighting a situation where a valid transaction could not be located within the mempool, blockchain, or via block explorers, despite having access to the private key involved. This incident raises concerns over potential censorship or selective orphaning by influential entities, which could occur without leaving any verifiable traces for users. By introducing this logging feature, the proposal seeks to bolster transparency and auditability, particularly benefiting users concerned with privacy or those utilizing air-gapped setups who lack comprehensive mempool logs. - In soliciting feedback from the Bitcoin development community, Liang presents several considerations associated with the proposal. These include evaluating the feature's value in enhancing user transparency, addressing potential wallet behavior and privacy issues, determining whether the logs should be stored in-memory or on disk by default, and assessing the benefit of integrating this feature into wallet software for easier user access. Initially drafted as a Bitcoin Improvement Proposal (BIP), Liang invites preliminary feedback before proceeding with a formal PR or implementation patch, indicating readiness to contribute a reference implementation compatible with Bitcoin Core version 25 and above. For further discussion, Liang suggests engaging on platforms like [Bitcoin StackExchange](https://bitcoin.stackexchange.com), recognizing that the topic may extend beyond the scope of the initial mailing list discussion. - 2025-07-29T22:55:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Proposal-to-solve-the-spam-war-configurable-data-blob-relay-policy.xml b/static/bitcoin-dev/June_2025/combined_Proposal-to-solve-the-spam-war-configurable-data-blob-relay-policy.xml index 22c314fb08..2b5bbb02b3 100644 --- a/static/bitcoin-dev/June_2025/combined_Proposal-to-solve-the-spam-war-configurable-data-blob-relay-policy.xml +++ b/static/bitcoin-dev/June_2025/combined_Proposal-to-solve-the-spam-war-configurable-data-blob-relay-policy.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Proposal to solve the spam war: configurable data blob relay policy - 2025-07-01T05:40:00.780008+00:00 - - Peter Todd 2025-06-02 10:25:00+00:00 - - - Greg Sanders 2025-05-28 13:16:00+00:00 - - - Dave Scotese 2025-05-27 23:10:00+00:00 - - - Jonathan Voss 2025-05-27 16:51:00+00:00 - - - Jonathan Voss 2025-05-27 16:40:00+00:00 - - - Russell OConnor 2025-05-27 16:02:00+00:00 - - - Pieter Wuille 2025-05-27 14:16:00+00:00 - - - Jonathan Voss 2025-05-24 21:07:00+00:00 - + 2025-09-26T14:30:59.242723+00:00 + python-feedgen + + + Proposal to solve the spam war: configurable data blob relay policy Jonathan Voss + 2025-05-24T21:07:00.000Z + + + Pieter Wuille + 2025-05-27T14:16:00.000Z + + + Russell O'Connor' + 2025-05-27T16:02:00.000Z + + + Jonathan Voss + 2025-05-27T16:40:00.000Z + + + Jonathan Voss + 2025-05-27T16:51:00.000Z + + + Dave Scotese + 2025-05-27T23:10:00.000Z + + + Greg Sanders + 2025-05-28T13:16:00.000Z + + + Peter Todd + 2025-06-02T10:25:00.000Z + + @@ -35,21 +46,17 @@ - python-feedgen + 2 Combined summary - Proposal to solve the spam war: configurable data blob relay policy - 2025-07-01T05:40:00.780097+00:00 + 2025-09-26T14:30:59.243713+00:00 + 2025-06-02T10:25:00+00:00 The discourse on the integration of non-monetary data within the Bitcoin blockchain has elicited varied perspectives, particularly focusing on proof-of-publication mechanisms and their implications for the technology's future. The utilization of Bitcoin as a publication layer for high-value use cases like Citrea, alongside its traditional financial utility, underscores the network's robustness in ensuring data permanence. This is contrasted with platforms like Bitmessage, which have struggled to maintain data integrity over time. The emphasis on leveraging Bitcoin's infrastructure for proof-of-publication highlights the criticality of cryptography in validating widespread data dissemination. - Discussions within the Bitcoin Development Mailing List reveal concerns about altering Layer 2 security models through data relocation, potentially impacting the scalability and utility enhancements designed for Bitcoin. There's an acknowledgment of the unremunerated contributions of network maintainers, suggesting a future where miners might indirectly compensate these efforts, thereby fostering a participatory market for data propagation within the Bitcoin ecosystem. This scenario posits a division within the network to balance Bitcoin's dual roles in financial transactions and innovative technological applications without compromising on either function. - Further elaboration on technical proposals reveals an inclination towards integrating Zero-Knowledge Proofs (ZKPs) with Citrea to enhance security and efficiency in validating decentralized data. A proposed additional relay service aims to streamline data distribution without burdening the Layer 2 protocol, suggesting a minimal adoption threshold for effective operation. This approach delineates between ephemeral and monetary data storage, addressing node operators' incentives to maintain network integrity. - The proposal for a new relay service to manage non-financial transactions on the Bitcoin network addresses pragmatic challenges associated with current relay policies. Highlighting inefficiencies in restrictive policies, the discussion advocates for a system aligned with the standardness filters majority of the network adheres to. This model seeks to mitigate potential negative impacts on block propagation speeds, fee estimation, and DoS protection mechanisms, proposing a structured method to incorporate arbitrary data without imposing significant burdens. - The debate extends to philosophical considerations of Bitcoin's design principles, emphasizing the importance of censorship resistance and the accommodation of diverse transaction types. Pieter Todd and others in the community argue for maintaining openness and neutrality, resisting narrowly defined transaction relay criteria. This perspective reflects a broader consensus on embracing Bitcoin's multifaceted utility while addressing the practicalities of incorporating non-monetary data through technical adjustments and policy upgrades. Such developments aim to reconcile differing views within the community, ensuring Bitcoin's continued evolution as both a financial instrument and a platform for technological innovation. - 2025-06-02T10:25:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_Sybil-resistance-in-different-coinjoin-implementations.xml b/static/bitcoin-dev/June_2025/combined_Sybil-resistance-in-different-coinjoin-implementations.xml index 11b5b08883..4d2da83852 100644 --- a/static/bitcoin-dev/June_2025/combined_Sybil-resistance-in-different-coinjoin-implementations.xml +++ b/static/bitcoin-dev/June_2025/combined_Sybil-resistance-in-different-coinjoin-implementations.xml @@ -1,35 +1,40 @@ - + 2 Combined summary - Sybil resistance in different coinjoin implementations - 2025-07-01T04:19:29.368456+00:00 - - waxwing/ AdamISZ 2025-06-25 12:53:00+00:00 - - - /dev /fd0 2025-06-25 01:55:00+00:00 - - - waxwing/ AdamISZ 2025-06-07 14:39:00+00:00 - - - /dev /fd 2025-05-27 14:29:00+00:00 - + 2025-09-26T14:31:07.861809+00:00 + python-feedgen + + + Sybil resistance in different coinjoin implementations /dev /fd0 + 2025-05-27T14:29:00.000Z + + + waxwing/ AdamISZ + 2025-06-07T14:39:00.000Z + + + /dev /fd0 + 2025-06-25T01:55:00.000Z + + + waxwing/ AdamISZ + 2025-06-25T12:53:00.000Z + + - python-feedgen + 2 Combined summary - Sybil resistance in different coinjoin implementations - 2025-07-01T04:19:29.368525+00:00 + 2025-09-26T14:31:07.862482+00:00 + 2025-06-25T12:53:00+00:00 The discussion revolves around the intricacies of hedging strategies as a means to mitigate the costs associated with timelocking bitcoins, a method employed to enhance security measures within cryptocurrency systems. It is argued that while hedging can offset some volatility-related costs by leveraging futures with minimal leverage, it does not eliminate the opportunity cost incurred during the lock period. This opportunity cost represents the foregone potential gains from alternative investments or uses of the funds. The conversation further explores the complexity of calculating these costs, suggesting that age and value restrictions on transactions could increase the cost of attacks on the system, thereby enhancing security. However, the exact formula for such calculations remains a topic of exploration. - The discourse extends into the realm of Unspent Transaction Outputs (UTXOs) and their role in sybil resistance mechanisms within Bitcoin's ecosystem. A proposed formula for estimating the cost of holding a UTXO is shared, which considers basic properties of a UTXO but acknowledges room for refinement. The dialogue underscores the challenge of imposing significant costs on attackers without disproportionately affecting honest users, especially through mechanisms like fidelity bonds. These bonds are critiqued for potentially complicating privacy and incurring high costs, driving the search for more nuanced solutions. - Further analysis touches upon the dual threats posed by sybil attacks: undermining non-collusion assumptions critical to protocol integrity and overwhelming resources through unrestricted access. The utility of UTXO ownership proofs in mitigating these threats is debated, with a particular focus on the limitations of simple ownership proofs and the potential of combining fidelity bonds with anonymity-enhancing technologies like aut-ct for more effective defense strategies. The conversation concludes with reflections on the practical challenges of coordinating such solutions within the decentralized and privacy-conscious framework of Bitcoin, highlighting the ongoing quest for balance between accessibility, privacy, and security in the digital currency space. - 2025-06-25T12:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_The-case-for-privatizing-Bitcoin-Core.xml b/static/bitcoin-dev/June_2025/combined_The-case-for-privatizing-Bitcoin-Core.xml index f9e0d1acba..eda044f295 100644 --- a/static/bitcoin-dev/June_2025/combined_The-case-for-privatizing-Bitcoin-Core.xml +++ b/static/bitcoin-dev/June_2025/combined_The-case-for-privatizing-Bitcoin-Core.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - The case for privatizing Bitcoin Core - 2025-07-01T05:59:49.001148+00:00 - - TheCharlatan 2025-06-17 08:30:00+00:00 - - - Bryan Bishop 2025-06-16 17:36:00+00:00 - - - waxwing/ AdamISZ 2025-06-16 16:53:00+00:00 - - - Bryan Bishop 2025-06-16 16:09:00+00:00 - - - waxwing/ AdamISZ 2025-06-16 15:14:00+00:00 - - - Andrew Poelstra 2025-06-15 16:14:00+00:00 - - - Antoine Riard 2025-06-15 05:41:00+00:00 - - - Antoine Poinsot 2025-06-14 18:29:00+00:00 - - - Michael Folkson 2025-06-12 16:45:00+00:00 - - - Dave Scotese 2025-06-11 08:38:00+00:00 - - - Bryan Bishop 2025-06-10 23:13:00+00:00 - - - Bryan Bishop 2025-06-10 20:31:00+00:00 - + 2025-09-26T14:30:44.267255+00:00 + python-feedgen + + + The case for privatizing Bitcoin Core Bryan Bishop + 2025-06-10T20:31:00.000Z + + + Dave Scotese + 2025-06-10T23:13:00.000Z + + + Michael Folkson + 2025-06-11T08:38:00.000Z + + + The Case for Decentralizing Bitcoin Core Development [was Re: [bitcoindev] The case for privatizing Bitcoin Core] Christopher Allen + 2025-06-12T16:45:00.000Z + + + The case for privatizing Bitcoin Core 'Antoine Poinsot' + 2025-06-14T18:29:00.000Z + + + Antoine Riard + 2025-06-15T05:41:00.000Z + + + Andrew Poelstra + 2025-06-15T16:14:00.000Z + + + waxwing/ AdamISZ + 2025-06-16T15:14:00.000Z + + + Bryan Bishop + 2025-06-16T16:09:00.000Z + + + waxwing/ AdamISZ + 2025-06-16T16:53:00.000Z + + + Bryan Bishop + 2025-06-16T17:36:00.000Z + + + TheCharlatan + 2025-06-17T08:30:00.000Z + + @@ -51,19 +66,16 @@ - python-feedgen + 2 Combined summary - The case for privatizing Bitcoin Core - 2025-07-01T05:59:49.001239+00:00 + 2025-09-26T14:30:44.268699+00:00 + 2025-06-17T08:30:00+00:00 Recent discussions within the Bitcoin Core development community have highlighted a recurring issue: non-contributors, sometimes even non-developers, intruding into forums intended for collaboration on Bitcoin Core, leading to wasted time, controversy, and misinformation. The essence of open-source development is voluntary collaboration among developers who choose to work together on projects they are passionate about, without any obligations beyond those specified by the license. Many developers hold personal moral values that guide their collaboration choices, but it's important to acknowledge that these cannot be coercively applied. - The situation on GitHub, where Bitcoin Core development primarily takes place, has been problematic due to inadequate moderation controls suited only for a narrow concept of open-source development. This has led to a call for re-evaluating how collaboration occurs, suggesting the possibility of moving towards a privatized, members-only collaboration platform. Such a platform would offer privacy for issues and pull requests, restrict public hyperlinking, and allow for controlled access through registration or application, while still continuing development under the same open-source license. - This proposed shift comes in response to the limitations of current public forums and office-based development practices, which can exclude many from the development process. By creating a private space for developers, the proposal aims to reduce unwanted interference and brigading, making the development environment more conducive to productivity and focus. Despite the privatization, the ethos of open-source development—such as public code review and releases—would remain unchanged, ensuring continued openness and accessibility. - The proposed changes aim to balance the need for open-source collaboration with the challenges posed by non-technical interventions and the demands of maintaining a productive development environment. By introducing mechanisms such as registration delays, probationary periods, and possibly proof-of-work entry requirements, the goal is to create a space that minimizes disruption while fostering a healthy, productive developer community. - 2025-06-17T08:30:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_What-s-a-good-stopping-point-Making-the-case-for-the-capabilities-enabled-by-CTV-CSFS.xml b/static/bitcoin-dev/June_2025/combined_What-s-a-good-stopping-point-Making-the-case-for-the-capabilities-enabled-by-CTV-CSFS.xml index 263eb4fa4f..33106b7d8a 100644 --- a/static/bitcoin-dev/June_2025/combined_What-s-a-good-stopping-point-Making-the-case-for-the-capabilities-enabled-by-CTV-CSFS.xml +++ b/static/bitcoin-dev/June_2025/combined_What-s-a-good-stopping-point-Making-the-case-for-the-capabilities-enabled-by-CTV-CSFS.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS - 2025-07-11T03:05:22.820924+00:00 - - Josh Doman 2025-07-10 14:33:00+00:00 - - - Greg Sanders 2025-07-10 12:05:00+00:00 - - - Josh Doman 2025-07-09 21:30:00+00:00 - - - Antoine Poinsot 2025-07-04 13:02:00+00:00 - - - Anthony Towns 2025-07-03 03:55:00+00:00 - - - Antoine Riard 2025-06-29 22:50:00+00:00 - - - Greg Sanders 2025-06-26 17:03:00+00:00 - - - Josh Doman 2025-06-26 16:02:00+00:00 - - - Ethan Heilman 2025-06-25 20:34:00+00:00 - - - Chris Stewart 2025-06-25 19:22:00+00:00 - - - Antoine Poinsot 2025-06-25 16:50:00+00:00 - - - Matt Corallo 2025-06-24 15:54:00+00:00 - - - Harsha Goli 2025-06-24 14:29:00+00:00 - - - Antoine Poinsot 2025-06-23 13:14:00+00:00 - + 2025-09-26T14:30:55.012674+00:00 + python-feedgen + + + What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS 'Antoine Poinsot' + 2025-06-23T13:14:00.000Z + + + Harsha Goli + 2025-06-24T14:29:00.000Z + + + Matt Corallo + 2025-06-24T15:54:00.000Z + + + Antoine Poinsot' + 2025-06-25T16:50:00.000Z + + + Chris Stewart + 2025-06-25T19:22:00.000Z + + + Ethan Heilman + 2025-06-25T20:34:00.000Z + + + Josh Doman + 2025-06-26T16:02:00.000Z + + + Greg Sanders + 2025-06-26T17:03:00.000Z + + + Antoine Riard + 2025-06-29T22:50:00.000Z + + + Anthony Towns + 2025-07-03T03:55:00.000Z + + + Antoine Poinsot' + 2025-07-04T13:02:00.000Z + + + Josh Doman + 2025-07-09T21:30:00.000Z + + + Greg Sanders + 2025-07-10T12:05:00.000Z + + + Josh Doman + 2025-07-10T14:33:00.000Z + + @@ -59,23 +76,18 @@ - python-feedgen + 2 Combined summary - What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS - 2025-07-11T03:05:22.821031+00:00 + 2025-09-26T14:30:55.014264+00:00 + 2025-07-10T14:33:00+00:00 The dialogue among Bitcoin developers centers on the necessity and methodology of enhancing Bitcoin's expressivity particularly in relation to committing to sibling prevouts. The conversation suggests a departure from more complex proposals like OP_TX / OP_TXHASH in favor of a streamlined approach utilizing MuHash. MuHash is proposed for its efficiency in committing to sibling prevouts within transactions, offering an alternative that reduces complexity by enabling commitments in constant time. This method involves precomputing a MuHash accumulator with the SHA256(index || prevout) for each transaction input, thereby facilitating efficient commitment verification. The discussion posits this technique as a low-cost, predictable method that could seamlessly integrate into the existing commitment scheme without substantial modifications, leveraging the already-included MuHash in Bitcoin's codebase. - There are concerns regarding the BitVM/CTV proposal, highlighting a lack of detailed demonstration or practical application that makes it difficult to assess its benefits or improvements to Bitcoin users. The skepticism extends to the justification for increasing Bitcoin's expressivity through such proposals, suggesting a need for more concrete evidence or deployment success before considering significant changes. - Further discussions explore the potential risks of expanding Bitcoin's script capabilities, emphasizing the importance of cautious development to avoid unintended vulnerabilities. The conversation reflects a preference for a gradual, well-evaluated extension of scripting functions rather than a comprehensive overhaul, focusing on consensus-level mechanisms to address issues like Miner Extractable Value (MEV) attacks. There's also a call for prioritizing fixes in Bitcoin Improvement Proposal 54 (BIP54) before integrating new features like CheckTemplateVerify (CTV) and CSFS, underlining the limited resources for review and the potential for unfavorable interactions between different changes. - A detailed discourse delves into the exploration of commitment hashes and their applications beyond current usage, urging the Bitcoin development community to investigate a broader range of enhancements. The discussions underscore a collective interest in refining Bitcoin's functionality, particularly for second-layer protocols, through sophisticated mechanisms like explicit commitments to neighbor prevouts. - The narrative shifts towards considerations for replacing or augmenting Bitcoin Script, advocating for the introduction of simple opcodes to gather insights for future development. It highlights the ongoing efforts to enhance Script’s capabilities through advanced introspection and arithmetic operations while addressing security concerns with innovative solutions like Taproot annexes. - The exchange on the Bitcoin Development Mailing List showcases a robust debate on introducing new opcodes aimed at reducing interactivity within second-layer protocols. There's a conscious effort to balance innovation with stability, emphasizing practical use cases over speculative advantages. The dialogue encapsulates a strategic approach to Bitcoin's evolution, prioritizing enhancements that offer tangible benefits and align with the network's foundational principles. - 2025-07-10T14:33:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2025/combined_jpeg-resistance-of-various-post-quantum-signature-schemes.xml b/static/bitcoin-dev/June_2025/combined_jpeg-resistance-of-various-post-quantum-signature-schemes.xml index 0b964cff2a..a78245849a 100644 --- a/static/bitcoin-dev/June_2025/combined_jpeg-resistance-of-various-post-quantum-signature-schemes.xml +++ b/static/bitcoin-dev/June_2025/combined_jpeg-resistance-of-various-post-quantum-signature-schemes.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - jpeg resistance of various post-quantum signature schemes - 2025-07-01T05:37:43.584764+00:00 - - Q C 2025-06-17 17:42:00+00:00 - - - Q C 2025-05-29 23:20:00+00:00 - - - Bas Westerbaan 2025-05-22 12:57:00+00:00 - - - Hunter Beast 2025-05-21 20:38:00+00:00 - - - Bas Westerbaan 2025-05-21 10:32:00+00:00 - + 2025-09-26T14:31:01.358506+00:00 + python-feedgen + + + jpeg resistance of various post-quantum signature schemes 'Bas Westerbaan' + 2025-05-21T10:32:00.000Z + + + Hunter Beast + 2025-05-21T20:38:00.000Z + + + Bas Westerbaan' + 2025-05-22T12:57:00.000Z + + + Q C + 2025-05-29T23:20:00.000Z + + + Q C + 2025-06-17T17:42:00.000Z + + - python-feedgen + 2 Combined summary - jpeg resistance of various post-quantum signature schemes - 2025-07-01T05:37:43.584821+00:00 + 2025-09-26T14:31:01.359328+00:00 + 2025-06-17T17:42:00+00:00 The discussions and analyses provided in the emails revolve around the intricate aspects of post-quantum cryptography (PQC), focusing on the evaluation of various cryptographic schemes in light of their security, efficiency, and practicality for implementation. A notable topic is the consideration of SLH-DSA within the development of BIP-360, which brings to the forefront the challenges associated with lattice-based cryptography. Despite the potential vulnerabilities, such as those related to novel security assumptions, lattice-based approaches are still valued for their applicability in key agreement protocols, especially in preparing for the advent of quantum computing. - One significant point of discussion is the resistance of different cryptographic schemes to quantum attacks, with a particular emphasis on XMSS. This hash-based signature mechanism is recognized for its robustness against quantum threats, offering a reliable verification process that supports a high volume of messages. However, concerns about XMSS include the risk of signature forgery due to the possible reuse of OTS leaves, underlining the importance of vigilant management of keys and signatures to uphold security integrity. Comparisons among various algorithms, including FALCON, secp256k1 Schnorr signatures, and SLH-DSA, shed light on the trade-offs between performance, signature size, and verification speed, which are crucial for ensuring the feasibility of cryptographic solutions. - The conversations further delve into the ongoing efforts to standardize new variants of SLH-DSA, reflecting a dynamic field that seeks to balance operational demands with security requirements. The dialogue also touches upon the potential deprecation of ML-DSA in favor of FALCON, highlighting the continuous evolution of cryptographic standards. Moreover, the implementation complexities and security considerations of FALCON's signing routine are discussed, along with the broader implications of improved lattice cryptanalysis. - -An intriguing aspect of the discourse is the concept of "jpeg resistance," a term coined to describe a signature scheme's ability to withstand attempts by attackers to create a valid signature and public key pair for a given message. This section explores the resilience of various schemes, including XMSS, XMSSMT, and SLH-DSA, against such manipulation tactics. The analysis reveals how the structure and validation processes of these schemes impact their vulnerability to attacks, emphasizing the nuanced balance required to prevent unauthorized signature fabrication. - +An intriguing aspect of the discourse is the concept of "jpeg resistance," a term coined to describe a signature scheme's ability to withstand attempts by attackers to create a valid signature and public key pair for a given message. This section explores the resilience of various schemes, including XMSS, XMSSMT, and SLH-DSA, against such manipulation tactics. The analysis reveals how the structure and validation processes of these schemes impact their vulnerability to attacks, emphasizing the nuanced balance required to prevent unauthorized signature fabrication. In summary, the detailed examination of different cryptographic schemes within these emails offers valuable insights into the challenges and considerations involved in developing secure, efficient, and scalable solutions for digital transactions in the quantum computing era. The collective wisdom and collaborative efforts of the cryptographic community are underscored as pivotal elements in navigating the complex landscape of cryptographic security and privacy amidst advancing technological capabilities. - 2025-06-17T17:42:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT.xml b/static/bitcoin-dev/March_2022/combined_-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT.xml index 82c816a78e..82c9c5d548 100644 --- a/static/bitcoin-dev/March_2022/combined_-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT.xml +++ b/static/bitcoin-dev/March_2022/combined_-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT - 2023-08-02T05:45:08.383421+00:00 - - Billy Tetrud 2022-03-07 17:26:13+00:00 - - - ZmnSCPxj 2022-03-06 20:38:17+00:00 - - - Billy Tetrud 2022-03-06 15:49:56+00:00 - - - ZmnSCPxj 2022-03-05 23:02:41+00:00 - - - Billy Tetrud 2022-03-05 19:12:03+00:00 - - - ZmnSCPxj 2022-02-27 16:34:31+00:00 - + 2025-09-26T14:35:37.575397+00:00 + python-feedgen + + + OP_FOLD`: A Looping Construct For Bitcoin SCRIPT ZmnSCPxj + 2022-02-27T16:34:00.000Z + + + Billy Tetrud + 2022-03-05T19:12:00.000Z + + + ZmnSCPxj + 2022-03-05T23:02:00.000Z + + + Billy Tetrud + 2022-03-06T15:49:00.000Z + + + ZmnSCPxj + 2022-03-06T20:38:00.000Z + + + Billy Tetrud + 2022-03-07T17:26:00.000Z + + - python-feedgen + 2 Combined summary - `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT - 2023-08-02T05:45:08.383421+00:00 + 2025-09-26T14:35:37.576292+00:00 - In the context of implementing a jet-like system in Bitcoin, the author presents three possibilities: implementing jets without requiring all nodes to upgrade, implementing lighter weighting by using a soft fork to hide jets from unupgraded nodes, and implementing jet registration in a soft fork. Upgraded nodes would query connections for support of jets and send transactions verbatim with the jet included in the script to upgraded nodes that support it. For non-upgraded nodes, the jet opcode call would be replaced with some data that contains the original jet opcode to be swapped back in when the transaction data reaches an upgraded node.The discussion highlights the need for security when releasing a new jet, as users of a new jet have no security if nobody else has upgraded. To incentivize end-users to use a jet, scripts must weigh less when using a jet. Full nodes could recognize jettable code and insert them automatically on transport, but this may result in a large lookup table once there are many jets. The proposal is to allow anyone to add a new jet, requiring a consensus change to implement a mechanism that allows any jet to be registered in userspace.While implementing jets in Bitcoin can optimize scripts, save bytes in transmission, and reduce processing power, changes in costs may occur. Adding jets would require debate and review to be added to Bitcoin core or other Bitcoin software. Implementing more general opcodes is useful, but their boundaries should be well understood before being added. The most general opcodes that can be fully reasoned about and come to a consensus on should be implemented. However, the implementation of `OP_FOLD` is possible without increasing the attack surface.The article discusses the usefulness of op_fold in Bitcoin and how it can provide bandwidth savings by programming as compression. Jets cover the majority of use cases that op_fold would otherwise have. The suggestion is to provide more general operations and identify the most important needs to be implemented on the blockchain layer. The more general an opcode is, the harder it is to understand the boundaries, so implementing the most general opcodes that can be fully reasoned about and come to a consensus on is recommended. Op_fold can still be useful with the proposed restrictions without increasing the attack surface.The Bitcoin Taproot update proposes the implementation of an `OP_FOLD` opcode, providing a looping mechanism for processing elements in an input structure and accumulating results. Restrictions are in place to prevent potential Denial of Service attacks through SCRIPT. Alternative suggestions include adding a field to limit the number of opcodes processed, allowing for multiple loops and loops-in-loops. While `OP_FOLD` improves bandwidth consumption without significantly increasing CPU consumption, trade-offs must be made in the Bitcoin SCRIPT design between general opcodes and complex opcodes.Bitcoin SCRIPT is a programming language used to implement OP_EVICT and general operations. The addition of an `OP_FOLD` operation should be safe as long as further operations admitting partiality are not added. Restricting the use of `OP_FOLD` ensures that its processing does not exceed that of a script without it. The article also discusses the possibility of adding an annex field to Taproot to indicate the maximum number of opcodes to be processed, allowing for lifting restrictions on `OP_FOLD` and multiple loops. The choice between providing more general operations or operations that do more depends on optimizing for specific uses in Bitcoin SCRIPT design. 2022-03-07T17:26:13+00:00 + In the context of implementing a jet-like system in Bitcoin, the author presents three possibilities: implementing jets without requiring all nodes to upgrade, implementing lighter weighting by using a soft fork to hide jets from unupgraded nodes, and implementing jet registration in a soft fork. Upgraded nodes would query connections for support of jets and send transactions verbatim with the jet included in the script to upgraded nodes that support it. For non-upgraded nodes, the jet opcode call would be replaced with some data that contains the original jet opcode to be swapped back in when the transaction data reaches an upgraded node.The discussion highlights the need for security when releasing a new jet, as users of a new jet have no security if nobody else has upgraded. To incentivize end-users to use a jet, scripts must weigh less when using a jet. Full nodes could recognize jettable code and insert them automatically on transport, but this may result in a large lookup table once there are many jets. The proposal is to allow anyone to add a new jet, requiring a consensus change to implement a mechanism that allows any jet to be registered in userspace.While implementing jets in Bitcoin can optimize scripts, save bytes in transmission, and reduce processing power, changes in costs may occur. Adding jets would require debate and review to be added to Bitcoin core or other Bitcoin software. Implementing more general opcodes is useful, but their boundaries should be well understood before being added. The most general opcodes that can be fully reasoned about and come to a consensus on should be implemented. However, the implementation of `OP_FOLD` is possible without increasing the attack surface.The article discusses the usefulness of op_fold in Bitcoin and how it can provide bandwidth savings by programming as compression. Jets cover the majority of use cases that op_fold would otherwise have. The suggestion is to provide more general operations and identify the most important needs to be implemented on the blockchain layer. The more general an opcode is, the harder it is to understand the boundaries, so implementing the most general opcodes that can be fully reasoned about and come to a consensus on is recommended. Op_fold can still be useful with the proposed restrictions without increasing the attack surface.The Bitcoin Taproot update proposes the implementation of an `OP_FOLD` opcode, providing a looping mechanism for processing elements in an input structure and accumulating results. Restrictions are in place to prevent potential Denial of Service attacks through SCRIPT. Alternative suggestions include adding a field to limit the number of opcodes processed, allowing for multiple loops and loops-in-loops. While `OP_FOLD` improves bandwidth consumption without significantly increasing CPU consumption, trade-offs must be made in the Bitcoin SCRIPT design between general opcodes and complex opcodes.Bitcoin SCRIPT is a programming language used to implement OP_EVICT and general operations. The addition of an `OP_FOLD` operation should be safe as long as further operations admitting partiality are not added. Restricting the use of `OP_FOLD` ensures that its processing does not exceed that of a script without it. The article also discusses the possibility of adding an annex field to Taproot to indicate the maximum number of opcodes to be processed, allowing for lifting restrictions on `OP_FOLD` and multiple loops. The choice between providing more general operations or operations that do more depends on optimizing for specific uses in Bitcoin SCRIPT design. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Annex-Purpose-Discussion-OP-ANNEX-Turing-Completeness-and-other-considerations.xml b/static/bitcoin-dev/March_2022/combined_Annex-Purpose-Discussion-OP-ANNEX-Turing-Completeness-and-other-considerations.xml index 15ca056436..3ba6cb5002 100644 --- a/static/bitcoin-dev/March_2022/combined_Annex-Purpose-Discussion-OP-ANNEX-Turing-Completeness-and-other-considerations.xml +++ b/static/bitcoin-dev/March_2022/combined_Annex-Purpose-Discussion-OP-ANNEX-Turing-Completeness-and-other-considerations.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations - 2023-08-02T05:49:14.711009+00:00 - - Anthony Towns 2022-03-07 08:08:03+00:00 - - - Antoine Riard 2022-03-07 00:59:33+00:00 - - - Jeremy Rubin 2022-03-06 13:21:57+00:00 - - - Christian Decker 2022-03-06 13:12:52+00:00 - - - Christian Decker 2022-03-06 12:55:53+00:00 - - - Jeremy Rubin 2022-03-05 12:20:02+00:00 - - - Anthony Towns 2022-03-05 05:59:24+00:00 - - - ZmnSCPxj 2022-03-04 23:33:10+00:00 - - - Jeremy Rubin 2022-03-04 23:21:41+00:00 - + 2025-09-26T14:35:39.725969+00:00 + python-feedgen + + + [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations Jeremy Rubin + 2022-03-04T23:21:00.000Z + + + ZmnSCPxj + 2022-03-04T23:33:00.000Z + + + Anthony Towns + 2022-03-05T05:59:00.000Z + + + Jeremy Rubin + 2022-03-05T12:20:00.000Z + + + Christian Decker + 2022-03-06T12:55:00.000Z + + + Christian Decker + 2022-03-06T13:12:00.000Z + + + Jeremy Rubin + 2022-03-06T13:21:00.000Z + + + Antoine Riard + 2022-03-07T00:59:00.000Z + + + Anthony Towns + 2022-03-07T08:08:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations - 2023-08-02T05:49:14.711009+00:00 + 2025-09-26T14:35:39.727188+00:00 - A discussion has been taking place on the Bitcoin development mailing list regarding the use of annexes in transactions and their potential benefits. Annexes are reserved spaces for future extensions that can be analyzed immediately without knowing anything about the utxo being spent. One potential benefit is optimizing SIGHASH_GROUP to allow a group of inputs to claim a group of outputs for signing. However, there are concerns about using annexes, such as the potential for script fragments to require incompatible interpretations of the annex. Some suggest banning the OP_ANNEX opcode altogether.The discussion also touches on other topics, such as CLTV, CSV, and nLockTime. It is suggested that a way to access individual entries from the annex would be useful, but creating scripts with difficult solutions can be impractical. The annex could contain a short byte string indicating additional weight units, which would only increase the witness size by a few bytes.There is also debate about the purpose of the annex and its implications for the Bitcoin network. Some propose using it for transaction field extension or specifying per-input absolute locktimes. Others suggest soft-forking the annex out of the current Checksig and redesigning its usage later. The reservation of the annex ensures that new consensus rules can be immediately applied to utxos predating those rules without needing to update them on-chain first.Concerns are raised about third-party malleability in Bitcoin transactions when using the annex opcode. Suggestions are made to banish the OP_ANNEX opcode or find a way to make it third-party malleable-resistant. The use of OP_ANNEX is debated, with some arguing for its utility in increasing limits on SCRIPT execution and others pointing out its potential issues.Overall, the discussion revolves around the potential benefits and drawbacks of using annexes in transactions and their implications for the Bitcoin network. There are various suggestions and concerns regarding the usage and implementation of annexes, including optimizing SIGHASH_GROUP, addressing script compatibility issues, and ensuring security against third-party malleability.The Annex is a linearizable resource that can be used to reserve something like memory efficiently. One suggestion is to introduce OP_ANNEX, an opcode that would push the annex on the stack along with a 0 or 1 to differentiate it from no annex. This would allow for the Annex to be used as a register/tape for a computational model, making witness construction Turing complete. However, this conflicts with using the Annex to guess computation costs and raises issues with Miniscript, where multiple annex values may need to be pre-signed.To address these issues, one solution proposed is to soft-fork the Annex out and always set it equal to 0 until a specific use case is found. Another option is to make the Annex unobservable from the script but still serve as a hint for validation rules. However, before deciding on the use of the Annex, further discussion is needed to determine its purpose and constraints. 2022-03-07T08:08:03+00:00 + A discussion has been taking place on the Bitcoin development mailing list regarding the use of annexes in transactions and their potential benefits. Annexes are reserved spaces for future extensions that can be analyzed immediately without knowing anything about the utxo being spent. One potential benefit is optimizing SIGHASH_GROUP to allow a group of inputs to claim a group of outputs for signing. However, there are concerns about using annexes, such as the potential for script fragments to require incompatible interpretations of the annex. Some suggest banning the OP_ANNEX opcode altogether.The discussion also touches on other topics, such as CLTV, CSV, and nLockTime. It is suggested that a way to access individual entries from the annex would be useful, but creating scripts with difficult solutions can be impractical. The annex could contain a short byte string indicating additional weight units, which would only increase the witness size by a few bytes.There is also debate about the purpose of the annex and its implications for the Bitcoin network. Some propose using it for transaction field extension or specifying per-input absolute locktimes. Others suggest soft-forking the annex out of the current Checksig and redesigning its usage later. The reservation of the annex ensures that new consensus rules can be immediately applied to utxos predating those rules without needing to update them on-chain first.Concerns are raised about third-party malleability in Bitcoin transactions when using the annex opcode. Suggestions are made to banish the OP_ANNEX opcode or find a way to make it third-party malleable-resistant. The use of OP_ANNEX is debated, with some arguing for its utility in increasing limits on SCRIPT execution and others pointing out its potential issues.Overall, the discussion revolves around the potential benefits and drawbacks of using annexes in transactions and their implications for the Bitcoin network. There are various suggestions and concerns regarding the usage and implementation of annexes, including optimizing SIGHASH_GROUP, addressing script compatibility issues, and ensuring security against third-party malleability.The Annex is a linearizable resource that can be used to reserve something like memory efficiently. One suggestion is to introduce OP_ANNEX, an opcode that would push the annex on the stack along with a 0 or 1 to differentiate it from no annex. This would allow for the Annex to be used as a register/tape for a computational model, making witness construction Turing complete. However, this conflicts with using the Annex to guess computation costs and raises issues with Miniscript, where multiple annex values may need to be pre-signed.To address these issues, one solution proposed is to soft-fork the Annex out and always set it equal to 0 until a specific use case is found. Another option is to make the Annex unobservable from the script but still serve as a hint for validation rules. However, before deciding on the use of the Annex, further discussion is needed to determine its purpose and constraints. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_BIP-Draft-Submission.xml b/static/bitcoin-dev/March_2022/combined_BIP-Draft-Submission.xml index a40baf59d3..08c7c19fe8 100644 --- a/static/bitcoin-dev/March_2022/combined_BIP-Draft-Submission.xml +++ b/static/bitcoin-dev/March_2022/combined_BIP-Draft-Submission.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP Draft Submission - 2023-08-02T05:48:15.629878+00:00 - - Billy Tetrud 2022-03-05 19:13:27+00:00 - - - Asher Hopp 2022-03-04 02:07:59+00:00 - + 2025-09-26T14:35:09.732820+00:00 + python-feedgen + + + [bitcoin-dev] BIP Draft Submission Asher Hopp + 2022-03-04T02:07:00.000Z + + + Billy Tetrud + 2022-03-05T19:13:00.000Z + + - python-feedgen + 2 Combined summary - BIP Draft Submission - 2023-08-02T05:48:15.629878+00:00 + 2025-09-26T14:35:09.733261+00:00 - Asher Hopp, a new contributor to the bitcoin-dev mailing list, has proposed a Bitcoin Improvement Proposal (BIP) that suggests changing the maximum supply of bitcoin from 21 million to 21 trillion. This would be achieved by moving the decimal place six places to the right while still allowing for two degrees of accuracy after the decimal point.Hopp's proposal is based on a suggestion made by Satoshi Nakamoto in 2010 regarding how the display shows the decimal point and commas when interpreting a bitcoin wallet's balance. The aim of this change is to address the negative perception of bitcoin's unit size, promote community cohesion, and simplify standardization across different regions.While Hopp acknowledges that there may be a psychological drawback to this proposal, as Bitcoin detractors could spread misinformation about the monetary value of anyone's bitcoin, he believes that the benefits outweigh this concern. Implementing this BIP would require updating the configuration of wallets' CLI/GUI displays. However, it is important to note that the proposal is backward compatible with previous versions of Bitcoin, meaning there would be no interruption in services for Bitcoin wallets that do not implement this BIP.The proposed change offers several advantages, including addressing unit bias, promoting community unity, simplifying standardization, and potentially facilitating wider adoption of Bitcoin. Moving the decimal place six places to the right in the display of a wallet's balance can easily be accomplished through software updates.In conclusion, Asher Hopp's BIP draft recommends changing the maximum supply of bitcoin from 21 million to 21 trillion by moving the decimal place six places to the right. The proposal is based on Satoshi Nakamoto's suggestion in 2010 and aims to improve Bitcoin's adoption and address concerns related to unit size. While there may be some psychological challenges, the proposal is backward compatible and does not disrupt existing Bitcoin services. 2022-03-05T19:13:27+00:00 + Asher Hopp, a new contributor to the bitcoin-dev mailing list, has proposed a Bitcoin Improvement Proposal (BIP) that suggests changing the maximum supply of bitcoin from 21 million to 21 trillion. This would be achieved by moving the decimal place six places to the right while still allowing for two degrees of accuracy after the decimal point.Hopp's proposal is based on a suggestion made by Satoshi Nakamoto in 2010 regarding how the display shows the decimal point and commas when interpreting a bitcoin wallet's balance. The aim of this change is to address the negative perception of bitcoin's unit size, promote community cohesion, and simplify standardization across different regions.While Hopp acknowledges that there may be a psychological drawback to this proposal, as Bitcoin detractors could spread misinformation about the monetary value of anyone's bitcoin, he believes that the benefits outweigh this concern. Implementing this BIP would require updating the configuration of wallets' CLI/GUI displays. However, it is important to note that the proposal is backward compatible with previous versions of Bitcoin, meaning there would be no interruption in services for Bitcoin wallets that do not implement this BIP.The proposed change offers several advantages, including addressing unit bias, promoting community unity, simplifying standardization, and potentially facilitating wider adoption of Bitcoin. Moving the decimal place six places to the right in the display of a wallet's balance can easily be accomplished through software updates.In conclusion, Asher Hopp's BIP draft recommends changing the maximum supply of bitcoin from 21 million to 21 trillion by moving the decimal place six places to the right. The proposal is based on Satoshi Nakamoto's suggestion in 2010 and aims to improve Bitcoin's adoption and address concerns related to unit size. While there may be some psychological challenges, the proposal is backward compatible and does not disrupt existing Bitcoin services. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Beyond-Jets-Microcode-Consensus-Critical-Jets-Without-Softforks.xml b/static/bitcoin-dev/March_2022/combined_Beyond-Jets-Microcode-Consensus-Critical-Jets-Without-Softforks.xml index e491d82b61..071d9da2b8 100644 --- a/static/bitcoin-dev/March_2022/combined_Beyond-Jets-Microcode-Consensus-Critical-Jets-Without-Softforks.xml +++ b/static/bitcoin-dev/March_2022/combined_Beyond-Jets-Microcode-Consensus-Critical-Jets-Without-Softforks.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks - 2023-08-02T05:56:00.974335+00:00 - - ZmnSCPxj 2022-03-23 00:20:16+00:00 - - - Anthony Towns 2022-03-22 23:11:05+00:00 - - - ZmnSCPxj 2022-03-22 16:47:33+00:00 - - - ZmnSCPxj 2022-03-22 16:39:10+00:00 - - - Russell O'Connor 2022-03-22 16:28:21+00:00 - - - ZmnSCPxj 2022-03-22 16:22:55+00:00 - - - Russell O'Connor 2022-03-22 15:08:33+00:00 - - - ZmnSCPxj 2022-03-22 05:37:03+00:00 - + 2025-09-26T14:35:13.994927+00:00 + python-feedgen + + + [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks ZmnSCPxj + 2022-03-22T05:37:00.000Z + + + Russell O'Connor + 2022-03-22T15:08:00.000Z + + + ZmnSCPxj + 2022-03-22T16:22:00.000Z + + + Russell O'Connor + 2022-03-22T16:28:00.000Z + + + ZmnSCPxj + 2022-03-22T16:39:00.000Z + + + ZmnSCPxj + 2022-03-22T16:47:00.000Z + + + Anthony Towns + 2022-03-22T23:11:00.000Z + + + ZmnSCPxj + 2022-03-23T00:20:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks - 2023-08-02T05:56:00.974335+00:00 + 2025-09-26T14:35:13.995963+00:00 - A proposal has been made to introduce microcodes for Bitcoin SCRIPT. The idea is to define a generic low-level language, called RISC, and map specific high-level languages to it. Users can sacrifice Bitcoins to define new microcodes that extend the functionality of Bitcoin SCRIPT. The proposed RISC language includes general instructions like arithmetic, SECP256K1 scalar and point math, bytevector concatenation, sha256 midstates, bytevector bit manipulation, transaction introspection, and more.The microcodes are compiled using LLVM and stored in a 256-long array of functions, where the array index corresponds to the `OP_` code. This allows for faster execution compared to expanding an OP-code SCRIPT to a UOP-code SCRIPT and interpreting it in a loop. However, there are concerns about introducing a significant new dependency to the consensus definition.To fix bugs in existing microcodes, a new microcode can be based on the existing one and the buggy implementation can be redefined. However, this requires existing Tapscripts to be re-spent to point to the new bug-fixed microcode, which incurs an on-chain spend.There is also a discussion about referencing microcodes in a simpler way. It is suggested that each microcode represents a language based on the current OG Bitcoin SCRIPT language. Tapscript versions can be replaced with microcodes, where each version is a slot for a microcode. The current OG Bitcoin SCRIPT would be just one of those slots. This approach reduces the cost of indicating a microcode to just one byte, as required currently.Efficiency in referencing microcodes is also considered. It is proposed to use a hash to refer to an entire language of redefined `OP_` codes, rather than individual opcodes. The use of a 50-bit hash or a 160-bit RIPEMD . SHA256 hash is sufficient to specify the microcodes with a low probability of collision. However, there is a concern about potential deliberate attacks if users of different SCRIPTs collaborate to define a single microcode.Specific microcodes can be used in Tapscript by opting for a specific `0xce` version and referring to the microcode through its hash. Race conditions can occur when reorganizing a newly-defined microcode, but this can be avoided by waiting for deep confirmation. Fullnodes may need to maintain multiple microcodes, which makes creating new ones expensive due to JIT compilation and the requirement to keep an index that cannot have items deleted. The advantage of using microcodes is that the size of the SCRIPT can be used as a proxy for CPU load, allowing for bounded CPU load without requiring a softfork.Namespace management is another issue discussed. Simplicity is suggested as a better platform than Bitcoin Script due to its narrow interface. However, specific microcodes are proposed as a solution to namespace management issues. They require opt-in usage and specific Tapscript versions, along with a hash to refer to the microcode. The only race condition occurs during reorganization, which can be avoided by waiting for deep confirmation. CPU load is bounded as long as there are no looping constructs and the number of `UOP_` micro-opcodes is limited.Another discussion focuses on the use of microcodes as a means of enabling new functionality in the Bitcoin consensus layer. The proposal suggests defining a generic low-level language and mapping specific high-level languages to it. This allows existing Bitcoin SCRIPT `OP_` codes to be mapped to `UOP_` micro-opcodes. Bugs in implementations can be fixed by uploading new microcodes based on the existing ones. To avoid trivial triggering of JIT-compilation, users petitioning for the jettification of operations must sacrifice Bitcoins.Overall, the use of microcodes in Bitcoin SCRIPT offers a way to extend functionality, fix bugs, and manage namespaces. It provides faster execution through LLVM compilation and allows for bounded CPU load. However, there are concerns about introducing dependencies, the cost of new functionality, and potential centralization pressure. 2022-03-23T00:20:16+00:00 + A proposal has been made to introduce microcodes for Bitcoin SCRIPT. The idea is to define a generic low-level language, called RISC, and map specific high-level languages to it. Users can sacrifice Bitcoins to define new microcodes that extend the functionality of Bitcoin SCRIPT. The proposed RISC language includes general instructions like arithmetic, SECP256K1 scalar and point math, bytevector concatenation, sha256 midstates, bytevector bit manipulation, transaction introspection, and more.The microcodes are compiled using LLVM and stored in a 256-long array of functions, where the array index corresponds to the `OP_` code. This allows for faster execution compared to expanding an OP-code SCRIPT to a UOP-code SCRIPT and interpreting it in a loop. However, there are concerns about introducing a significant new dependency to the consensus definition.To fix bugs in existing microcodes, a new microcode can be based on the existing one and the buggy implementation can be redefined. However, this requires existing Tapscripts to be re-spent to point to the new bug-fixed microcode, which incurs an on-chain spend.There is also a discussion about referencing microcodes in a simpler way. It is suggested that each microcode represents a language based on the current OG Bitcoin SCRIPT language. Tapscript versions can be replaced with microcodes, where each version is a slot for a microcode. The current OG Bitcoin SCRIPT would be just one of those slots. This approach reduces the cost of indicating a microcode to just one byte, as required currently.Efficiency in referencing microcodes is also considered. It is proposed to use a hash to refer to an entire language of redefined `OP_` codes, rather than individual opcodes. The use of a 50-bit hash or a 160-bit RIPEMD . SHA256 hash is sufficient to specify the microcodes with a low probability of collision. However, there is a concern about potential deliberate attacks if users of different SCRIPTs collaborate to define a single microcode.Specific microcodes can be used in Tapscript by opting for a specific `0xce` version and referring to the microcode through its hash. Race conditions can occur when reorganizing a newly-defined microcode, but this can be avoided by waiting for deep confirmation. Fullnodes may need to maintain multiple microcodes, which makes creating new ones expensive due to JIT compilation and the requirement to keep an index that cannot have items deleted. The advantage of using microcodes is that the size of the SCRIPT can be used as a proxy for CPU load, allowing for bounded CPU load without requiring a softfork.Namespace management is another issue discussed. Simplicity is suggested as a better platform than Bitcoin Script due to its narrow interface. However, specific microcodes are proposed as a solution to namespace management issues. They require opt-in usage and specific Tapscript versions, along with a hash to refer to the microcode. The only race condition occurs during reorganization, which can be avoided by waiting for deep confirmation. CPU load is bounded as long as there are no looping constructs and the number of `UOP_` micro-opcodes is limited.Another discussion focuses on the use of microcodes as a means of enabling new functionality in the Bitcoin consensus layer. The proposal suggests defining a generic low-level language and mapping specific high-level languages to it. This allows existing Bitcoin SCRIPT `OP_` codes to be mapped to `UOP_` micro-opcodes. Bugs in implementations can be fixed by uploading new microcodes based on the existing ones. To avoid trivial triggering of JIT-compilation, users petitioning for the jettification of operations must sacrifice Bitcoins.Overall, the use of microcodes in Bitcoin SCRIPT offers a way to extend functionality, fix bugs, and manage namespaces. It provides faster execution through LLVM compilation and allows for bounded CPU load. However, there are concerns about introducing dependencies, the cost of new functionality, and potential centralization pressure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_CTV-Meeting-5-Agenda-Tuesday-March-7th-12-00-PT-.xml b/static/bitcoin-dev/March_2022/combined_CTV-Meeting-5-Agenda-Tuesday-March-7th-12-00-PT-.xml index a839eb6f07..a62e258452 100644 --- a/static/bitcoin-dev/March_2022/combined_CTV-Meeting-5-Agenda-Tuesday-March-7th-12-00-PT-.xml +++ b/static/bitcoin-dev/March_2022/combined_CTV-Meeting-5-Agenda-Tuesday-March-7th-12-00-PT-.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT) - 2023-08-02T05:50:06.365688+00:00 - - Jorge Timón 2022-03-10 11:41:52+00:00 - - - Michael Folkson 2022-03-09 14:14:40+00:00 - - - Jorge Timón 2022-03-09 11:02:35+00:00 - - - Jeremy Rubin 2022-03-08 03:32:13+00:00 - - - Jeremy Rubin 2022-03-08 02:50:39+00:00 - + 2025-09-26T14:35:43.951480+00:00 + python-feedgen + + + [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT) Jeremy Rubin + 2022-03-08T02:50:00.000Z + + + Jeremy Rubin + 2022-03-08T03:32:00.000Z + + + Jorge Timón + 2022-03-09T11:02:00.000Z + + + Michael Folkson + 2022-03-09T14:14:00.000Z + + + Jorge Timón + 2022-03-10T11:41:00.000Z + + - python-feedgen + 2 Combined summary - CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT) - 2023-08-02T05:50:06.365688+00:00 + 2025-09-26T14:35:43.952282+00:00 - The email thread on the bitcoin-dev mailing list revolves around the potential addition of a soft fork proposal to Bitcoin core without community consensus. The author expresses concerns about the dismissal of criticism by some developers and emphasizes the need for accountability without resorting to personal attacks. Additionally, the email includes an agenda for an upcoming CTV meeting addressing various topics such as experimental support for Taproot, transaction sponsoring versus CPFP/RBF, non-recursive vaults, and more. This discussion underscores the significance of community outreach and consensus-building in the development of Bitcoin consensus changes.The conversation begins with Jorge Timón inquiring about the feasibility of incorporating CTV into Bitcoin Core. In response, Michael Folkson advises against assuming community consensus and proposes keeping discussions on activation mechanisms and soft fork proposals separate. He emphasizes the importance of patience in achieving community consensus and highlights the activation mechanism known as ST (Speedy Trial) used for Taproot. Michael stresses the significance of welcoming criticism and avoiding blind trust in any individual. Furthermore, he asserts that thorough technical review and community consensus should precede the implementation of any soft fork proposal.The message also includes information regarding an upcoming CTV meeting. The agenda encompasses several items, including a Sapio Taproot support update, a comparison between transaction sponsoring and CPFP/RBF, Jamesob's Non-Recursive Vaults Post, and a Q&A session. The speaker also mentions the confusion surrounding different terminologies used within the mailing list. Furthermore, there are links provided in the email related to some agenda items, offering additional resources for deeper understanding.On March 8th, a CTV meeting was scheduled at noon PT. The agenda featured updates and discussions on various Bitcoin development topics. The first item focused on a Sapio Taproot support update and requested review, highlighting the experimental support merged on master. The second topic explored Transaction Sponsoring versus CPFP/RBF, delving into two distinct methods of confirming transactions on the blockchain. The third item centered around Jamesob's Non-Recursive Vaults Post, which proposed potential security enhancements for Bitcoin wallets. The fourth agenda item entailed a broad discussion of recent advancements in the Bitcoin community, featuring acronyms like EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, and Jets. Lastly, the meeting concluded with a Q&A session to facilitate questions and discussions.To summarize, a CTV meeting is scheduled for tomorrow at noon PT, encompassing various agenda items. These include a Sapio Taproot support update, Transaction Sponsoring versus CPFP/RBF comparison, Jamesob's Non-Recursive Vaults Post, understanding recent jargon used on the mailing list, and a Q&A session. The meeting aims to provide updates, foster discussions, and promote engagement among interested parties. 2022-03-10T11:41:52+00:00 + The email thread on the bitcoin-dev mailing list revolves around the potential addition of a soft fork proposal to Bitcoin core without community consensus. The author expresses concerns about the dismissal of criticism by some developers and emphasizes the need for accountability without resorting to personal attacks. Additionally, the email includes an agenda for an upcoming CTV meeting addressing various topics such as experimental support for Taproot, transaction sponsoring versus CPFP/RBF, non-recursive vaults, and more. This discussion underscores the significance of community outreach and consensus-building in the development of Bitcoin consensus changes.The conversation begins with Jorge Timón inquiring about the feasibility of incorporating CTV into Bitcoin Core. In response, Michael Folkson advises against assuming community consensus and proposes keeping discussions on activation mechanisms and soft fork proposals separate. He emphasizes the importance of patience in achieving community consensus and highlights the activation mechanism known as ST (Speedy Trial) used for Taproot. Michael stresses the significance of welcoming criticism and avoiding blind trust in any individual. Furthermore, he asserts that thorough technical review and community consensus should precede the implementation of any soft fork proposal.The message also includes information regarding an upcoming CTV meeting. The agenda encompasses several items, including a Sapio Taproot support update, a comparison between transaction sponsoring and CPFP/RBF, Jamesob's Non-Recursive Vaults Post, and a Q&A session. The speaker also mentions the confusion surrounding different terminologies used within the mailing list. Furthermore, there are links provided in the email related to some agenda items, offering additional resources for deeper understanding.On March 8th, a CTV meeting was scheduled at noon PT. The agenda featured updates and discussions on various Bitcoin development topics. The first item focused on a Sapio Taproot support update and requested review, highlighting the experimental support merged on master. The second topic explored Transaction Sponsoring versus CPFP/RBF, delving into two distinct methods of confirming transactions on the blockchain. The third item centered around Jamesob's Non-Recursive Vaults Post, which proposed potential security enhancements for Bitcoin wallets. The fourth agenda item entailed a broad discussion of recent advancements in the Bitcoin community, featuring acronyms like EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, and Jets. Lastly, the meeting concluded with a Q&A session to facilitate questions and discussions.To summarize, a CTV meeting is scheduled for tomorrow at noon PT, encompassing various agenda items. These include a Sapio Taproot support update, Transaction Sponsoring versus CPFP/RBF comparison, Jamesob's Non-Recursive Vaults Post, understanding recent jargon used on the mailing list, and a Q&A session. The meeting aims to provide updates, foster discussions, and promote engagement among interested parties. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_CTV-dramatically-improves-DLCs.xml b/static/bitcoin-dev/March_2022/combined_CTV-dramatically-improves-DLCs.xml index edbc1c8501..cbb058081e 100644 --- a/static/bitcoin-dev/March_2022/combined_CTV-dramatically-improves-DLCs.xml +++ b/static/bitcoin-dev/March_2022/combined_CTV-dramatically-improves-DLCs.xml @@ -1,32 +1,55 @@ - + 2 Combined summary - CTV dramatically improves DLCs - 2023-08-02T05:25:02.224690+00:00 - - Jeremy Rubin 2022-03-15 17:28:05+00:00 - - - Thibaut Le Guilly 2022-02-07 02:30:32+00:00 - - - Jeremy Rubin 2022-02-06 17:56:12+00:00 - - - Lloyd Fournier 2022-02-06 07:18:11+00:00 - - - Alex Schoof 2022-01-28 21:14:12+00:00 - - - Jeremy Rubin 2022-01-28 19:38:29+00:00 - - - Jeremy 2022-01-28 17:21:09+00:00 - - - Lloyd Fournier 2022-01-24 08:01:17+00:00 - + 2025-09-26T14:35:24.622861+00:00 + python-feedgen + + + [bitcoin-dev] CTV dramatically improves DLCs Lloyd Fournier + 2022-01-24T08:01:00.000Z + + + [bitcoin-dev] [dlc-dev] " Jonas Nick + 2022-01-25T16:24:00.000Z + + + Thibaut Le Guilly + 2022-01-27T00:45:00.000Z + + + Jeremy + 2022-01-28T16:53:00.000Z + + + [bitcoin-dev] " Jeremy + 2022-01-28T17:21:00.000Z + + + Jeremy Rubin + 2022-01-28T19:38:00.000Z + + + Alex Schoof + 2022-01-28T21:14:00.000Z + + + Lloyd Fournier + 2022-02-06T07:18:00.000Z + + + Jeremy Rubin + 2022-02-06T17:56:00.000Z + + + Thibaut Le Guilly + 2022-02-07T02:30:00.000Z + + + Jeremy Rubin + 2022-03-15T17:28:00.000Z + + @@ -35,13 +58,13 @@ - python-feedgen + 2 Combined summary - CTV dramatically improves DLCs - 2023-08-02T05:25:02.224690+00:00 + 2025-09-26T14:35:24.624257+00:00 - Jeremy has developed a prototype of a protocol in Sapio and shared the link to it on GitHub. He invites others to test and tweak the protocol using the provided benchmark. Jeremy tested one oracle with 100,000 different payouts and observed it taking around 13 seconds on a release build. He intends to experiment more with the protocol, but acknowledges that Sapio Studio may not be able to handle a GUI for 100,000 nodes.In a discussion thread, several points were raised regarding the use of CSFS and its effectiveness in providing privacy benefits. It was noted that while CSFS could be used in both the oracle and transaction restriction parts of the DLC, it does not provide the same model as DLC. Additionally, there was discussion about the performance benefits of the CTV approach, which allows for computation of oracle anticipation points without signing or verification. A benchmark comparison was made between the current approach with signing and verification and only computing the anticipation points, resulting in a performance improvement of roughly 24x for the serial case and 10x for the parallel case. The benchmarks are available on GitHub. One potential concern raised was the impact of having a large taproot tree on the size of witness data when spending script paths that are low in the tree and how it would affect transaction fees. Finally, there was a discussion about the Y axis being the dependent variable represented by the CTV hashes in a contract, and how this affects the cheaper part of the DLC in lightning channels that might be updated between parties frequently.The email exchange discusses the benefits and features of Discreet Log Contracts (DLCs) with CheckTemplateVerify (CTV). The author explains that CTV enables a trustless timeout branch, which can have a failover claim that returns funds to both sides. Additionally, CTV DLCs are non-interactive asynchronously third-party unilaterally creatable, which means it is possible for a single party to create a DLC on behalf of another user. This enables use cases like pay-to-DLC addresses, which can also be constructed and sent to a third party service to create DLCs without requiring the third party service to do anything other than make the payment as requested.The email also discusses how CTV DLCs can be composed in interesting ways. Options over DLCs open up many exciting types of instrument where Alice can create an option expiring in 1 week where Bob can add funds to pay a premium and "Open" a DLC on an outcome closing in 1 year. There are also opportunities for perpetual-like contracts where you could combine into one logical DLC 12 DLCs closing 1 per month that can either be paid out all at once at the end of the year or profit pulled out partially at any time earlier.Lastly, the email mentions an additional performance improvement that can be had for iterative DLCs in Lightning where you might trade over a fixed set of attestation points with variable payout curves. However, the author is not entirely clear on what is meant concretely by this. Overall, the discussion highlights the potential benefits and uses of CTV DLCs.The email thread discusses the benefits of using OP_CTV with Discreet Log Contracts (DLCs) on the Bitcoin network. OP_CTV simplifies and improves the performance of DLCs by enabling non-interactive asynchronously third-party unilaterally creatable contracts. With this, each party can compute all outcomes on their own in parallel, making multi-party DLCs easier to execute. Additionally, OP_CTV enables a "trustless timeout" branch where failover claims return funds to both sides, and DLCs can be composed in interesting ways. For example, Options over DLCs can be created, perpetual-like contracts can be combined, and iterative DLCs can be traded over a fixed set of attestation points with variable payout curves. Lastly, OP_CTV allows for pay-to-DLC addresses to be constructed and sent to third-party services, enabling the creation of DLCs without requiring the service to do anything other than make the payment as requested.Jeremy Rubin proposes a way to make the close portion of a DLC be an "optimistic" execution with a choice of justice scheme, enabling closing a DLC somewhat securely without exposing the oracles on-chain at all. Assuming honest oracles, the only cost of this mechanism over previous is that you have to do a script path spend (but it can be a top-level branch, since it's the "most likely" one). For every DLC branch add two branches allowing Alice or Bob to "lock in" a redemption of the contract that becomes spendable by them after CET-hash-* should include a nLockTime/nSequence such that it is at the same time as the attestation points should be known. Justice with punishment seems to be the better option since T is actively choosing this resolution (the CTV transition is signed), but justice with no punishment might be better if one thinks the oracles might collude to steal. 2022-03-15T17:28:05+00:00 + Jeremy has developed a prototype of a protocol in Sapio and shared the link to it on GitHub. He invites others to test and tweak the protocol using the provided benchmark. Jeremy tested one oracle with 100,000 different payouts and observed it taking around 13 seconds on a release build. He intends to experiment more with the protocol, but acknowledges that Sapio Studio may not be able to handle a GUI for 100,000 nodes.In a discussion thread, several points were raised regarding the use of CSFS and its effectiveness in providing privacy benefits. It was noted that while CSFS could be used in both the oracle and transaction restriction parts of the DLC, it does not provide the same model as DLC. Additionally, there was discussion about the performance benefits of the CTV approach, which allows for computation of oracle anticipation points without signing or verification. A benchmark comparison was made between the current approach with signing and verification and only computing the anticipation points, resulting in a performance improvement of roughly 24x for the serial case and 10x for the parallel case. The benchmarks are available on GitHub. One potential concern raised was the impact of having a large taproot tree on the size of witness data when spending script paths that are low in the tree and how it would affect transaction fees. Finally, there was a discussion about the Y axis being the dependent variable represented by the CTV hashes in a contract, and how this affects the cheaper part of the DLC in lightning channels that might be updated between parties frequently.The email exchange discusses the benefits and features of Discreet Log Contracts (DLCs) with CheckTemplateVerify (CTV). The author explains that CTV enables a trustless timeout branch, which can have a failover claim that returns funds to both sides. Additionally, CTV DLCs are non-interactive asynchronously third-party unilaterally creatable, which means it is possible for a single party to create a DLC on behalf of another user. This enables use cases like pay-to-DLC addresses, which can also be constructed and sent to a third party service to create DLCs without requiring the third party service to do anything other than make the payment as requested.The email also discusses how CTV DLCs can be composed in interesting ways. Options over DLCs open up many exciting types of instrument where Alice can create an option expiring in 1 week where Bob can add funds to pay a premium and "Open" a DLC on an outcome closing in 1 year. There are also opportunities for perpetual-like contracts where you could combine into one logical DLC 12 DLCs closing 1 per month that can either be paid out all at once at the end of the year or profit pulled out partially at any time earlier.Lastly, the email mentions an additional performance improvement that can be had for iterative DLCs in Lightning where you might trade over a fixed set of attestation points with variable payout curves. However, the author is not entirely clear on what is meant concretely by this. Overall, the discussion highlights the potential benefits and uses of CTV DLCs.The email thread discusses the benefits of using OP_CTV with Discreet Log Contracts (DLCs) on the Bitcoin network. OP_CTV simplifies and improves the performance of DLCs by enabling non-interactive asynchronously third-party unilaterally creatable contracts. With this, each party can compute all outcomes on their own in parallel, making multi-party DLCs easier to execute. Additionally, OP_CTV enables a "trustless timeout" branch where failover claims return funds to both sides, and DLCs can be composed in interesting ways. For example, Options over DLCs can be created, perpetual-like contracts can be combined, and iterative DLCs can be traded over a fixed set of attestation points with variable payout curves. Lastly, OP_CTV allows for pay-to-DLC addresses to be constructed and sent to third-party services, enabling the creation of DLCs without requiring the service to do anything other than make the payment as requested.Jeremy Rubin proposes a way to make the close portion of a DLC be an "optimistic" execution with a choice of justice scheme, enabling closing a DLC somewhat securely without exposing the oracles on-chain at all. Assuming honest oracles, the only cost of this mechanism over previous is that you have to do a script path spend (but it can be a top-level branch, since it's the "most likely" one). For every DLC branch add two branches allowing Alice or Bob to "lock in" a redemption of the contract that becomes spendable by them after CET-hash-* should include a nLockTime/nSequence such that it is at the same time as the attestation points should be known. Justice with punishment seems to be the better option since T is actively choosing this resolution (the CTV transition is signed), but justice with no punishment might be better if one thinks the oracles might collude to steal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_CTV-vaults-in-the-wild.xml b/static/bitcoin-dev/March_2022/combined_CTV-vaults-in-the-wild.xml index c5a579c012..d459df4232 100644 --- a/static/bitcoin-dev/March_2022/combined_CTV-vaults-in-the-wild.xml +++ b/static/bitcoin-dev/March_2022/combined_CTV-vaults-in-the-wild.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - CTV vaults in the wild - 2023-08-02T05:49:32.008973+00:00 - - Antoine Riard 2022-03-10 22:31:32+00:00 - - - Antoine Riard 2022-03-10 21:12:44+00:00 - - - James O'Beirne 2022-03-08 19:46:03+00:00 - - - ZmnSCPxj 2022-03-08 00:57:21+00:00 - - - Antoine Riard 2022-03-06 23:15:41+00:00 - - - James O'Beirne 2022-03-06 17:35:17+00:00 - + 2025-09-26T14:35:52.440424+00:00 + python-feedgen + + + [bitcoin-dev] CTV vaults in the wild James O'Beirne + 2022-03-06T17:35:00.000Z + + + Antoine Riard + 2022-03-06T23:15:00.000Z + + + ZmnSCPxj + 2022-03-08T00:57:00.000Z + + + James O'Beirne + 2022-03-08T19:46:00.000Z + + + Antoine Riard + 2022-03-10T21:12:00.000Z + + + Antoine Riard + 2022-03-10T22:31:00.000Z + + - python-feedgen + 2 Combined summary - CTV vaults in the wild - 2023-08-02T05:49:32.008973+00:00 + 2025-09-26T14:35:52.441307+00:00 - Antoine and James O'Beirne had a discussion about the implementation of hashchain-based vault designs. Antoine expressed concern about bugs slipping in and affecting the output amount or relative-timelock setting correctness. They also discussed the immutability of flow paths in hashchain-based vaults, the security advantage of trusted hardware, and the need for better fee-bumping needs.They also talked about the idea of a vault scheme for custodians and individual users to function as a single trusted entity. The concern arises when someone unexpectedly hacks the fee keys that encumber all of the anchor outputs. They also discussed the need for space efficiency and the usage of watchtowers for lightning channels and vault schemes.The conversation between Antoine and ZmnSCPxj focused on the design of Taproot-based vaults and their vulnerabilities. They discussed the limitations of hashchain-based vault designs and the advantages of Taproot in terms of flexibility and recoverability. They also addressed the issues of trusted hardware and watchtowers used by both Lightning Network and vault users.The conversation between Antoine and James revolved around the discussion of pre-signed transactions as a security measure for Bitcoin wallets. James argued that bugs can affect the output amount or relative-timelock setting correctness in any sufficiently involved uses of bitcoin script. They also discussed the security advantage of vaults compared to classic multisig setup and the need for an intermediary protocol step for formal authorization of unvault broadcasts.In a Bitcoin-dev email thread, Antoine Riard responded to James O'Beirne's sketch of a CTV-based vault design. He expressed his concern regarding the immutability of flow paths in hashchain-based vault designs and suggested leveraging a presigned transaction data design. Riard also discussed other minor points on vault design, such as introducing an intermediary, out-of-chain protocol step for formal authorization of unvault broadcasts and the safety of using anchor outputs.James O'Beirne created an implementation and write-up of a simple vault design using CTV in response to AJ's skepticism about the readiness of CTV for deployment on mainnet. James believes that this design has several attractive qualities for custody operations of any size. 2022-03-10T22:31:32+00:00 + Antoine and James O'Beirne had a discussion about the implementation of hashchain-based vault designs. Antoine expressed concern about bugs slipping in and affecting the output amount or relative-timelock setting correctness. They also discussed the immutability of flow paths in hashchain-based vaults, the security advantage of trusted hardware, and the need for better fee-bumping needs.They also talked about the idea of a vault scheme for custodians and individual users to function as a single trusted entity. The concern arises when someone unexpectedly hacks the fee keys that encumber all of the anchor outputs. They also discussed the need for space efficiency and the usage of watchtowers for lightning channels and vault schemes.The conversation between Antoine and ZmnSCPxj focused on the design of Taproot-based vaults and their vulnerabilities. They discussed the limitations of hashchain-based vault designs and the advantages of Taproot in terms of flexibility and recoverability. They also addressed the issues of trusted hardware and watchtowers used by both Lightning Network and vault users.The conversation between Antoine and James revolved around the discussion of pre-signed transactions as a security measure for Bitcoin wallets. James argued that bugs can affect the output amount or relative-timelock setting correctness in any sufficiently involved uses of bitcoin script. They also discussed the security advantage of vaults compared to classic multisig setup and the need for an intermediary protocol step for formal authorization of unvault broadcasts.In a Bitcoin-dev email thread, Antoine Riard responded to James O'Beirne's sketch of a CTV-based vault design. He expressed his concern regarding the immutability of flow paths in hashchain-based vault designs and suggested leveraging a presigned transaction data design. Riard also discussed other minor points on vault design, such as introducing an intermediary, out-of-chain protocol step for formal authorization of unvault broadcasts and the safety of using anchor outputs.James O'Beirne created an implementation and write-up of a simple vault design using CTV in response to AJ's skepticism about the readiness of CTV for deployment on mainnet. James believes that this design has several attractive qualities for custody operations of any size. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Covenants-and-feebumping.xml b/static/bitcoin-dev/March_2022/combined_Covenants-and-feebumping.xml index b710563ee2..68e44f6c08 100644 --- a/static/bitcoin-dev/March_2022/combined_Covenants-and-feebumping.xml +++ b/static/bitcoin-dev/March_2022/combined_Covenants-and-feebumping.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Covenants and feebumping - 2023-08-02T05:55:38.338309+00:00 - - darosior 2022-03-21 12:06:54+00:00 - - - ZmnSCPxj 2022-03-16 23:29:42+00:00 - - - darosior 2022-03-14 14:49:30+00:00 - - - Jeremy Rubin 2022-03-13 02:33:48+00:00 - - - darosior 2022-03-12 18:08:39+00:00 - + 2025-09-26T14:35:26.735504+00:00 + python-feedgen + + + [bitcoin-dev] Covenants and feebumping darosior + 2022-03-12T18:08:00.000Z + + + Jeremy Rubin + 2022-03-13T02:33:00.000Z + + + darosior + 2022-03-14T14:49:00.000Z + + + ZmnSCPxj + 2022-03-16T23:29:00.000Z + + + darosior + 2022-03-21T12:06:00.000Z + + - python-feedgen + 2 Combined summary - Covenants and feebumping - 2023-08-02T05:55:38.338309+00:00 + 2025-09-26T14:35:26.736347+00:00 - The email conversation between Antoine and ZmnSCPxj revolves around the use of a signature challenge for ensuring the uptime of hot contracts. However, they acknowledge that this method has drawbacks, such as the need to presign multiple versions of a transaction with varying feerates and the issue of third-party trust. To address these concerns, ZmnSCPxj suggests using a DLC (Discreet Log Contract) oracle, which would provide a set of points corresponding to different feerate ranges. The oracle would commit to publishing the scalar of one of those points at a future block height. Adaptor signatures would be created for each feerate version, and multiple watchtowers would be sent these signatures to prevent any single watchtower from publishing the highest-feerate version. Despite the advantages of this approach, there are still limitations, including third-party trust, time-bound DLCs, and the inability to invoke the oracle at any time for hot dynamic protocols.In another part of the conversation, Antoine proposes using covenants for fee bumping in Bitcoin contracts, although this would require a soft fork. He explains that covenant-based fee bumping has appealing properties, but finding a similar solution for other protocols has proven challenging. Antoine suggests attaching an increasing relative timelock to each leaf as the committed revocation feerate increases, allowing the feerate to adapt to the block space market. This approach also provides anti-fee sniping protection if the revocation transaction pays a significant amount of fees. However, paying fees from internal funds introduces the possibility of blackmail for multi-party contracts. Precommitted levels of fee bumping may work, but they come with substantial costs. Another option is using sponsors, which are similar to CPFP (Child Pays For Parent) and simplify the management of transaction chains in the mempool. Sponsors allow the allocation of funds later on but require pre-committing to all possible fee-bumped levels, preventing the dynamic addition of more fees.The conversation also highlights the differences between "cold contracts" (vaults) and "hot contracts" in terms of fee bumping. Timelocks are used for cold contracts to prevent the denial-of-service (DOS) attacks that can occur with high feerates. On the other hand, hot contracts utilize a signature challenge for the same purpose. However, this method has its flaws, as the lower the uptime risk, the higher the DOS risk. The use of sponsor-type solutions allows for the design of protocols without native fee payment methods, relying on external systems to achieve the desired effect. A recent post on the Bitcoin-dev mailing list proposes a timelocked-covenant approach to fee bumping for multi-party contracts like vaults, using shared funds to pay for fees and avoiding perverse incentives.Jeremy Rubin contributes to the discussion by suggesting transaction sponsors as a form of covenant for fee bumping. He emphasizes their efficiency, particularly pre-committed levels and fancier covenants, as well as their capital efficiency. Sponsors can also address protocol design concerns and RBF (Replace-By-Fee) pinning issues. In response to darosior's soft fork proposal for dynamic fee bumping, Jeremy suggests using a covenant-based approach instead. He provides an example of designing a covenant for a vault wallet software with five participants, committing to the revocation transaction with increasing feerate and relative timelock. This enables fee adaptation and anti-fee sniping protection.Antoine Riard introduces a new fee bumping method for Bitcoin transactions. It involves adding a single input and output to a Taproot transaction, costing 520 weight units or 105 virtual bytes. This method offers more granularity in fee bumps at a relatively low cost. However, it is not applicable for bumping the first transaction of a chain, such as HTLC transactions in Lightning. A workaround is to use a different covenant per participant behind a signature check, requiring funds to already be in the contract for unilateral close. While not as optimal and usable as other methods like CPFP or adding input/output pairs, it remains more efficient for many use cases.The conversation also touches on the idea of using a soft fork to fix dynamic fee bumping, given the complexity of designing with current primitives. One proposed solution is using covenants for fee bumping, which have attractive properties. An Unvaulting transaction triggers a timelock, after which a revocation transaction may be confirmed. With a covenant, one can commit to the revocation transaction instead of presigning it. Using a Taproot tree, different versions of the revocation transaction with increasing feerates can be committed to. However, careful consideration is needed to avoid wrecking miner incentives. Paying fees from shared funds eliminates the need for refilling and managing a fee-bumping wallet. Antoine Riard's covenant-based approach to fee bumping in multi-party vault setups is seen as a promising solution. It involves creating a Taproot tree with a depth of 7 2022-03-21T12:06:54+00:00 + The email conversation between Antoine and ZmnSCPxj revolves around the use of a signature challenge for ensuring the uptime of hot contracts. However, they acknowledge that this method has drawbacks, such as the need to presign multiple versions of a transaction with varying feerates and the issue of third-party trust. To address these concerns, ZmnSCPxj suggests using a DLC (Discreet Log Contract) oracle, which would provide a set of points corresponding to different feerate ranges. The oracle would commit to publishing the scalar of one of those points at a future block height. Adaptor signatures would be created for each feerate version, and multiple watchtowers would be sent these signatures to prevent any single watchtower from publishing the highest-feerate version. Despite the advantages of this approach, there are still limitations, including third-party trust, time-bound DLCs, and the inability to invoke the oracle at any time for hot dynamic protocols.In another part of the conversation, Antoine proposes using covenants for fee bumping in Bitcoin contracts, although this would require a soft fork. He explains that covenant-based fee bumping has appealing properties, but finding a similar solution for other protocols has proven challenging. Antoine suggests attaching an increasing relative timelock to each leaf as the committed revocation feerate increases, allowing the feerate to adapt to the block space market. This approach also provides anti-fee sniping protection if the revocation transaction pays a significant amount of fees. However, paying fees from internal funds introduces the possibility of blackmail for multi-party contracts. Precommitted levels of fee bumping may work, but they come with substantial costs. Another option is using sponsors, which are similar to CPFP (Child Pays For Parent) and simplify the management of transaction chains in the mempool. Sponsors allow the allocation of funds later on but require pre-committing to all possible fee-bumped levels, preventing the dynamic addition of more fees.The conversation also highlights the differences between "cold contracts" (vaults) and "hot contracts" in terms of fee bumping. Timelocks are used for cold contracts to prevent the denial-of-service (DOS) attacks that can occur with high feerates. On the other hand, hot contracts utilize a signature challenge for the same purpose. However, this method has its flaws, as the lower the uptime risk, the higher the DOS risk. The use of sponsor-type solutions allows for the design of protocols without native fee payment methods, relying on external systems to achieve the desired effect. A recent post on the Bitcoin-dev mailing list proposes a timelocked-covenant approach to fee bumping for multi-party contracts like vaults, using shared funds to pay for fees and avoiding perverse incentives.Jeremy Rubin contributes to the discussion by suggesting transaction sponsors as a form of covenant for fee bumping. He emphasizes their efficiency, particularly pre-committed levels and fancier covenants, as well as their capital efficiency. Sponsors can also address protocol design concerns and RBF (Replace-By-Fee) pinning issues. In response to darosior's soft fork proposal for dynamic fee bumping, Jeremy suggests using a covenant-based approach instead. He provides an example of designing a covenant for a vault wallet software with five participants, committing to the revocation transaction with increasing feerate and relative timelock. This enables fee adaptation and anti-fee sniping protection.Antoine Riard introduces a new fee bumping method for Bitcoin transactions. It involves adding a single input and output to a Taproot transaction, costing 520 weight units or 105 virtual bytes. This method offers more granularity in fee bumps at a relatively low cost. However, it is not applicable for bumping the first transaction of a chain, such as HTLC transactions in Lightning. A workaround is to use a different covenant per participant behind a signature check, requiring funds to already be in the contract for unilateral close. While not as optimal and usable as other methods like CPFP or adding input/output pairs, it remains more efficient for many use cases.The conversation also touches on the idea of using a soft fork to fix dynamic fee bumping, given the complexity of designing with current primitives. One proposed solution is using covenants for fee bumping, which have attractive properties. An Unvaulting transaction triggers a timelock, after which a revocation transaction may be confirmed. With a covenant, one can commit to the revocation transaction instead of presigning it. Using a Taproot tree, different versions of the revocation transaction with increasing feerates can be committed to. However, careful consideration is needed to avoid wrecking miner incentives. Paying fees from shared funds eliminates the need for refilling and managing a fee-bumping wallet. Antoine Riard's covenant-based approach to fee bumping in multi-party vault setups is seen as a promising solution. It involves creating a Taproot tree with a depth of 7 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml b/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml index b374d98899..8c4f9ea63a 100644 --- a/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml +++ b/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Decentralized BIP 47 payment code directory - 2023-08-02T05:45:48.056713+00:00 + 2025-09-26T14:35:18.252934+00:00 + python-feedgen Prayank 2022-03-02 04:45:58+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Decentralized BIP 47 payment code directory - 2023-08-02T05:45:48.056713+00:00 + 2025-09-26T14:35:18.253118+00:00 - In a conversation between Peter and Prayank, Prayank introduces a newer version (v3 and v4) of BIP47, which has been proposed on GitHub. This version aims to solve the toxic change issue and seems like an improvement. Prayank explains that using an xpub does not provide anonymity because anyone who has access to the xpub, including platforms or hackers, can identify one's payments. However, using a payment code allows for public association without revealing the payment identifier on the blockchain, making it difficult for others to determine if funds have been received. Prayank also suggests a rust library that can assist application developers in implementing BIP47 into different bitcoin projects.The OpenBitcoinPrivacyProject has proposed a newer version of BIP47, v3 and v4, which addresses certain issues present in the previous version. The new version eliminates the toxic change issue by modifying the notification from Alice to Bob as a transaction from Alice to herself, functioning as a bare 1 of 3 multisig. Two pubkeys represent Alice's payment code and Bob's payment identifier. This change incurs a one-time overhead of 64 bytes for the two pubkeys, which is spread out over the lifespan of the relationship between Alice and Bob. Additionally, the first economic payment from Alice to Bob can be included with the notification transaction. Payment codes can be recovered from the bip32 seed without requiring extra backups. The new version is already being used in production with Samourai wallet. BIP47 v3 enables Alice to receive Bob's address without exposing her IP/identity to Charlie. Charlie can observe Alice receiving the payment code material from Bob but cannot determine if Alice proceeded to make a payment to Bob. Unlike an xpub, this method ensures privacy even if the xpub is shared with a crowdfunding platform, as the platform or any potential hackers cannot identify the payments made by Alice. By using the payment code, individuals can publicly associate themselves with their payment code without revealing if they have received funds, as the payment code is not visible on the blockchain.Twitter has seen discussions about BIP47 and its potential to enhance privacy. However, some developers argue that it merely adds spam to the Bitcoin network without providing any actual improvements. Additionally, the only existing implementation of BIP47 is Paynym, a centralized payment code directory managed by Samourai wallet, raising concerns regarding privacy and security. To address these concerns, the author suggests utilizing TXT records and domains. They present a proof of concept using GNS (GNU Name Service) to create a payment code for Alice, adding it as a TXT record with an expiry date, and verifying it. The author also proposes using `gnunet-publish` as a replacement for notification transactions. These solutions could potentially help users avoid sharing their bitcoin addresses on social media platforms when receiving donations. In addition to these suggestions, the author provides links to related resources, including a Q&A on accepting donations correctly and a new proposal addressing privacy concerns. 2022-03-02T04:45:58+00:00 + In a conversation between Peter and Prayank, Prayank introduces a newer version (v3 and v4) of BIP47, which has been proposed on GitHub. This version aims to solve the toxic change issue and seems like an improvement. Prayank explains that using an xpub does not provide anonymity because anyone who has access to the xpub, including platforms or hackers, can identify one's payments. However, using a payment code allows for public association without revealing the payment identifier on the blockchain, making it difficult for others to determine if funds have been received. Prayank also suggests a rust library that can assist application developers in implementing BIP47 into different bitcoin projects.The OpenBitcoinPrivacyProject has proposed a newer version of BIP47, v3 and v4, which addresses certain issues present in the previous version. The new version eliminates the toxic change issue by modifying the notification from Alice to Bob as a transaction from Alice to herself, functioning as a bare 1 of 3 multisig. Two pubkeys represent Alice's payment code and Bob's payment identifier. This change incurs a one-time overhead of 64 bytes for the two pubkeys, which is spread out over the lifespan of the relationship between Alice and Bob. Additionally, the first economic payment from Alice to Bob can be included with the notification transaction. Payment codes can be recovered from the bip32 seed without requiring extra backups. The new version is already being used in production with Samourai wallet. BIP47 v3 enables Alice to receive Bob's address without exposing her IP/identity to Charlie. Charlie can observe Alice receiving the payment code material from Bob but cannot determine if Alice proceeded to make a payment to Bob. Unlike an xpub, this method ensures privacy even if the xpub is shared with a crowdfunding platform, as the platform or any potential hackers cannot identify the payments made by Alice. By using the payment code, individuals can publicly associate themselves with their payment code without revealing if they have received funds, as the payment code is not visible on the blockchain.Twitter has seen discussions about BIP47 and its potential to enhance privacy. However, some developers argue that it merely adds spam to the Bitcoin network without providing any actual improvements. Additionally, the only existing implementation of BIP47 is Paynym, a centralized payment code directory managed by Samourai wallet, raising concerns regarding privacy and security. To address these concerns, the author suggests utilizing TXT records and domains. They present a proof of concept using GNS (GNU Name Service) to create a payment code for Alice, adding it as a TXT record with an expiry date, and verifying it. The author also proposes using `gnunet-publish` as a replacement for notification transactions. These solutions could potentially help users avoid sharing their bitcoin addresses on social media platforms when receiving donations. In addition to these suggestions, the author provides links to related resources, including a Q&A on accepting donations correctly and a new proposal addressing privacy concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Improving-RBF-Policy.xml b/static/bitcoin-dev/March_2022/combined_Improving-RBF-Policy.xml index 129841068c..3d80bdfa00 100644 --- a/static/bitcoin-dev/March_2022/combined_Improving-RBF-Policy.xml +++ b/static/bitcoin-dev/March_2022/combined_Improving-RBF-Policy.xml @@ -1,68 +1,111 @@ - + 2 Combined summary - Improving RBF Policy - 2023-08-02T05:30:18.072198+00:00 - - Billy Tetrud 2022-03-17 15:59:11+00:00 - - - Antoine Riard 2022-03-17 02:02:30+00:00 - - - Billy Tetrud 2022-03-15 01:43:31+00:00 - - - Gloria Zhao 2022-03-14 10:29:16+00:00 - - - Billy Tetrud 2022-03-12 08:18:39+00:00 - - - Billy Tetrud 2022-03-11 16:22:07+00:00 - - - Gloria Zhao 2022-03-09 15:09:55+00:00 - - - lisa neigut 2022-02-09 17:57:59+00:00 - - - Anthony Towns 2022-02-08 04:58:50+00:00 - - - Gloria Zhao 2022-02-07 11:16:26+00:00 - - - Bastien TEINTURIER 2022-02-07 10:22:01+00:00 - - - Michael Folkson 2022-02-05 13:21:57+00:00 - - - Anthony Towns 2022-02-02 10:21:16+00:00 - - - Bastien TEINTURIER 2022-02-01 09:30:12+00:00 - - - Prayank 2022-02-01 02:47:18+00:00 - - - Anthony Towns 2022-02-01 01:56:37+00:00 - - - Bastien TEINTURIER 2022-01-31 15:57:52+00:00 - - - Antoine Riard 2022-01-30 22:53:32+00:00 - - - Jeremy 2022-01-28 01:35:11+00:00 - - - Gloria Zhao 2022-01-27 13:42:09+00:00 - + 2025-09-26T14:35:31.070227+00:00 + python-feedgen + + + [bitcoin-dev] Improving RBF Policy Gloria Zhao + 2022-01-27T13:42:00.000Z + + + Jeremy + 2022-01-28T01:35:00.000Z + + + Antoine Riard + 2022-01-30T22:53:00.000Z + + + Bastien TEINTURIER + 2022-01-31T15:57:00.000Z + + + [bitcoin-dev] Improving RBF policy Bram Cohen + 2022-01-31T22:54:00.000Z + + + Eric Voskuil + 2022-02-01T00:08:00.000Z + + + Antoine Riard + 2022-02-01T00:42:00.000Z + + + Anthony Towns + 2022-02-01T01:56:00.000Z + + + [bitcoin-dev] Improving RBF Policy Prayank + 2022-02-01T02:47:00.000Z + + + Bram Cohen + 2022-02-01T08:32:00.000Z + + + Bastien TEINTURIER + 2022-02-01T09:30:00.000Z + + + Eric Voskuil + 2022-02-01T19:44:00.000Z + + + Anthony Towns + 2022-02-02T10:21:00.000Z + + + Michael Folkson + 2022-02-05T13:21:00.000Z + + + Bastien TEINTURIER + 2022-02-07T10:22:00.000Z + + + Gloria Zhao + 2022-02-07T11:16:00.000Z + + + Anthony Towns + 2022-02-08T04:58:00.000Z + + + lisa neigut + 2022-02-09T17:57:00.000Z + + + Gloria Zhao + 2022-03-09T15:09:00.000Z + + + Billy Tetrud + 2022-03-11T16:22:00.000Z + + + Billy Tetrud + 2022-03-12T08:18:00.000Z + + + Gloria Zhao + 2022-03-14T10:29:00.000Z + + + Billy Tetrud + 2022-03-15T01:43:00.000Z + + + Antoine Riard + 2022-03-17T02:02:00.000Z + + + Billy Tetrud + 2022-03-17T15:59:00.000Z + + @@ -83,13 +126,13 @@ - python-feedgen + 2 Combined summary - Improving RBF Policy - 2023-08-02T05:30:18.072198+00:00 + 2025-09-26T14:35:31.072836+00:00 - In recent discussions among Bitcoin developers, proposals have been made to improve the Replace-by-Fee (RBF) policies in the mempool. The goal is to address limitations and potential vulnerabilities of the current rules. One suggestion is to implement transaction relay rate limiting with a feerate-based priority queue and staggered broadcast of replacement transactions. This would prioritize transactions based on their likelihood of being included in a block.Another proposal is to allow users to specify descendant limits on their transactions, which would help solve the pinning problem associated with package RBF attacks.There has also been discussion around the concept of "mining score" as a way to prioritize transactions. The mining score would be calculated based on the ancestor feerate at which a transaction is included in a block. It is suggested that this mining score could be used as the priority value for transaction relay if a rate-limited priority queue is implemented.Some concerns have been raised about the potential downsides of these proposals, but they have generally been well-received and open for feedback. The overall objective is to prevent Denial-of-Service (DoS) attacks while maintaining the fee-rate relay rule that already mitigates spam.The conversation also touches on the idea of excluding low fee transactions from being relayed and included in blocks. While there are concerns about missing out on good fees, it is noted that this approach is a special case and other factors need to be considered, such as trusting that a lower fee transaction won't replace a higher fee transaction and the number of transactions bidding for a spot in the next block.Rate limiting is already done via INVENTORY_BROADCAST_MAX and *_INVENTORY_BROADCAST_INTERVAL, but an alternative approach suggested is to track the "effective fee rate" to better manage the ancestor fee rate. This could be achieved through candidate set blockbuilding ideas.Furthermore, there has been discussion about keeping high-feerate evicted transactions in the mempool in case they get mined by someone else, which could improve compact block relay. However, concerns have been raised about the sufficiency of the 100 transaction LRU cache and the possibility of applying rate limits only to replacement transactions.Lastly, there is a suggestion to have a split between mempool acceptance rules and spam prevention rules. This would allow transactions to be sent to miners through an alternate route if they are blocked by anti-spam rules.Overall, the discussions focus on improving the RBF policies in Bitcoin's transaction relay system to address limitations, prevent DoS attacks, and ensure a fair and efficient fee-based transaction prioritization.In another discussion, participants considered whether or not descendants matter for miner incentives. The group also discussed policies to address miner incentives and DoS issues, such as requiring certain percentage increases in ancestor absolute fees and feerates. The conversation highlights the need for improved security and more efficient use of resources in multi-party contracts built on top of Bitcoin.Bastien Teinturier proposes new rules for replacing transactions that prioritize DoS protection and incentive compatibility. He suggests separating policies that address miner incentives from policies that address DoS issues and adding a third policy to specifically address DoS concerns. He also discusses the timeline for implementing updated policies and potential vulnerabilities in multi-party contracts due to reliance on policies that cannot be enforced.Another member of the mailing list suggests relay rate limiting and prioritizing by ancestor fee rate as a way to discourage people from wasting network bandwidth. This proposal aims to address the issue of publishing transactions that will never get confirmed while still ensuring incentive compatibility. They also discuss the importance of having a path that follows the new relay rules and gets support from a significant portion of hashpower.The post delves into the discussion of improving Bitcoin's Replace-by-Fee (RBF) feature in transactions. Developer Jeremy Rubin proposes several changes to address issues and potential attacks. These changes involve removing rules that require higher fees, preventing pinning attacks, and creating a more user-friendly interface for fee bumping transactions. Rubin also discusses models for transaction validation rate-limiting and enhancing the mining score of mempool transactions.The author introduces a new rule called the "feerate-based" rule, which aims to replace transactions in the mempool. This approach entails calculating conflicting transactions and their descendants, identifying original transactions for inclusion in the next block, and ensuring replacements pay at least the same amount plus a certain percentage in absolute fees. Replacements must also have a higher feerate than the maximum mining score of remaining transactions in the mempool after the next block. The proposal suggests utilizing TBD constants to limit the number of replacements allowed with specific fees.Various implementation options for the feerate-based replacement rule are discussed, including dynamic block templates, cached block templates, or dividing the mempool into different feerate layers. Throughout the document, links to relevant pull requests, issues, and discussions are provided for further context. However, the author emphasizes that more discussion is needed to improve the RBF policy.The post also addresses topics like DoS protection, iterative 2022-03-17T15:59:11+00:00 + In recent discussions among Bitcoin developers, proposals have been made to improve the Replace-by-Fee (RBF) policies in the mempool. The goal is to address limitations and potential vulnerabilities of the current rules. One suggestion is to implement transaction relay rate limiting with a feerate-based priority queue and staggered broadcast of replacement transactions. This would prioritize transactions based on their likelihood of being included in a block.Another proposal is to allow users to specify descendant limits on their transactions, which would help solve the pinning problem associated with package RBF attacks.There has also been discussion around the concept of "mining score" as a way to prioritize transactions. The mining score would be calculated based on the ancestor feerate at which a transaction is included in a block. It is suggested that this mining score could be used as the priority value for transaction relay if a rate-limited priority queue is implemented.Some concerns have been raised about the potential downsides of these proposals, but they have generally been well-received and open for feedback. The overall objective is to prevent Denial-of-Service (DoS) attacks while maintaining the fee-rate relay rule that already mitigates spam.The conversation also touches on the idea of excluding low fee transactions from being relayed and included in blocks. While there are concerns about missing out on good fees, it is noted that this approach is a special case and other factors need to be considered, such as trusting that a lower fee transaction won't replace a higher fee transaction and the number of transactions bidding for a spot in the next block.Rate limiting is already done via INVENTORY_BROADCAST_MAX and *_INVENTORY_BROADCAST_INTERVAL, but an alternative approach suggested is to track the "effective fee rate" to better manage the ancestor fee rate. This could be achieved through candidate set blockbuilding ideas.Furthermore, there has been discussion about keeping high-feerate evicted transactions in the mempool in case they get mined by someone else, which could improve compact block relay. However, concerns have been raised about the sufficiency of the 100 transaction LRU cache and the possibility of applying rate limits only to replacement transactions.Lastly, there is a suggestion to have a split between mempool acceptance rules and spam prevention rules. This would allow transactions to be sent to miners through an alternate route if they are blocked by anti-spam rules.Overall, the discussions focus on improving the RBF policies in Bitcoin's transaction relay system to address limitations, prevent DoS attacks, and ensure a fair and efficient fee-based transaction prioritization.In another discussion, participants considered whether or not descendants matter for miner incentives. The group also discussed policies to address miner incentives and DoS issues, such as requiring certain percentage increases in ancestor absolute fees and feerates. The conversation highlights the need for improved security and more efficient use of resources in multi-party contracts built on top of Bitcoin.Bastien Teinturier proposes new rules for replacing transactions that prioritize DoS protection and incentive compatibility. He suggests separating policies that address miner incentives from policies that address DoS issues and adding a third policy to specifically address DoS concerns. He also discusses the timeline for implementing updated policies and potential vulnerabilities in multi-party contracts due to reliance on policies that cannot be enforced.Another member of the mailing list suggests relay rate limiting and prioritizing by ancestor fee rate as a way to discourage people from wasting network bandwidth. This proposal aims to address the issue of publishing transactions that will never get confirmed while still ensuring incentive compatibility. They also discuss the importance of having a path that follows the new relay rules and gets support from a significant portion of hashpower.The post delves into the discussion of improving Bitcoin's Replace-by-Fee (RBF) feature in transactions. Developer Jeremy Rubin proposes several changes to address issues and potential attacks. These changes involve removing rules that require higher fees, preventing pinning attacks, and creating a more user-friendly interface for fee bumping transactions. Rubin also discusses models for transaction validation rate-limiting and enhancing the mining score of mempool transactions.The author introduces a new rule called the "feerate-based" rule, which aims to replace transactions in the mempool. This approach entails calculating conflicting transactions and their descendants, identifying original transactions for inclusion in the next block, and ensuring replacements pay at least the same amount plus a certain percentage in absolute fees. Replacements must also have a higher feerate than the maximum mining score of remaining transactions in the mempool after the next block. The proposal suggests utilizing TBD constants to limit the number of replacements allowed with specific fees.Various implementation options for the feerate-based replacement rule are discussed, including dynamic block templates, cached block templates, or dividing the mempool into different feerate layers. Throughout the document, links to relevant pull requests, issues, and discussions are provided for further context. However, the author emphasizes that more discussion is needed to improve the RBF policy.The post also addresses topics like DoS protection, iterative - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Jets-Was-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT-.xml b/static/bitcoin-dev/March_2022/combined_Jets-Was-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT-.xml index f7b9d07661..13c3802348 100644 --- a/static/bitcoin-dev/March_2022/combined_Jets-Was-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT-.xml +++ b/static/bitcoin-dev/March_2022/combined_Jets-Was-OP-FOLD-A-Looping-Construct-For-Bitcoin-SCRIPT-.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Jets (Was: `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT) - 2023-08-02T05:49:45.907529+00:00 - - Billy Tetrud 2022-03-16 15:59:00+00:00 - - - ZmnSCPxj 2022-03-16 15:38:57+00:00 - - - Billy Tetrud 2022-03-11 14:11:33+00:00 - - - ZmnSCPxj 2022-03-10 06:43:56+00:00 - - - Billy Tetrud 2022-03-10 05:05:35+00:00 - - - ZmnSCPxj 2022-03-07 23:35:04+00:00 - + 2025-09-26T14:35:28.851492+00:00 + python-feedgen + + + OP_FOLD`: A Looping Construct For Bitcoin SCRIPT) ZmnSCPxj + 2022-03-07T23:35:00.000Z + + + Billy Tetrud + 2022-03-10T05:05:00.000Z + + + ZmnSCPxj + 2022-03-10T06:43:00.000Z + + + Billy Tetrud + 2022-03-11T14:11:00.000Z + + + ZmnSCPxj + 2022-03-16T15:38:00.000Z + + + Billy Tetrud + 2022-03-16T15:59:00.000Z + + - python-feedgen + 2 Combined summary - Jets (Was: `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT) - 2023-08-02T05:49:45.908525+00:00 + 2025-09-26T14:35:28.852367+00:00 - The conversation between Billy and ZmnSCPxj revolves around the implementation of a cleanstack rule and the introduction of jets in the Bitcoin network. The cleanstack rule would prevent scripts from validating if more than just a true value is left on the stack, and there is also a stronger cleanstack rule where both the stack and alt stack are completely empty. The minimum critical mass for a jet to be beneficial is when two nodes supporting it are connected, which depends on the size of the script.There are discussions about the implementation of jets without a soft fork and the potential disincentives they may create. It is suggested that individual sections of the network could decide which jets they want to support without requiring a soft fork for each one. Higher-order function ability could also be added to jets without additional soft forks.The conversation also considers the use of a constants table in the SCRIPT puzzle instead of the witness solution. It is proposed that the language could be redesigned so that OP_PUSH is not in the opcode stream, but instead, a separate table of constants is attached to the actual SCRIPT. This would enhance the usefulness of jets.Challenges faced in implementing jets include increasing costs and the risk of hacks. To address these issues, the author suggests replacing most of the "OP_PUSH" opcodes with variants that look up a static table at the start of the executable script body. This would make it easier to incorporate existing jets into new scripts without manipulating the stack in a way that the jet expects. Although this proposal adds complexity, it could potentially reduce overhead costs and make jets more user-friendly.Overall, the conversation explores various aspects of implementing jets in Bitcoin, including their benefits, critical mass, disincentives, higher-order function ability, constant table implementation, and challenges. The goal is to optimize network efficiency, reduce transaction fees, and improve the Bitcoin scripting language. 2022-03-16T15:59:00+00:00 + The conversation between Billy and ZmnSCPxj revolves around the implementation of a cleanstack rule and the introduction of jets in the Bitcoin network. The cleanstack rule would prevent scripts from validating if more than just a true value is left on the stack, and there is also a stronger cleanstack rule where both the stack and alt stack are completely empty. The minimum critical mass for a jet to be beneficial is when two nodes supporting it are connected, which depends on the size of the script.There are discussions about the implementation of jets without a soft fork and the potential disincentives they may create. It is suggested that individual sections of the network could decide which jets they want to support without requiring a soft fork for each one. Higher-order function ability could also be added to jets without additional soft forks.The conversation also considers the use of a constants table in the SCRIPT puzzle instead of the witness solution. It is proposed that the language could be redesigned so that OP_PUSH is not in the opcode stream, but instead, a separate table of constants is attached to the actual SCRIPT. This would enhance the usefulness of jets.Challenges faced in implementing jets include increasing costs and the risk of hacks. To address these issues, the author suggests replacing most of the "OP_PUSH" opcodes with variants that look up a static table at the start of the executable script body. This would make it easier to incorporate existing jets into new scripts without manipulating the stack in a way that the jet expects. Although this proposal adds complexity, it could potentially reduce overhead costs and make jets more user-friendly.Overall, the conversation explores various aspects of implementing jets in Bitcoin, including their benefits, critical mass, disincentives, higher-order function ability, constant table implementation, and challenges. The goal is to optimize network efficiency, reduce transaction fees, and improve the Bitcoin scripting language. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Meeting-Summary-Logs-for-CTV-Meeting-5.xml b/static/bitcoin-dev/March_2022/combined_Meeting-Summary-Logs-for-CTV-Meeting-5.xml index bf08737634..b26bce9bc0 100644 --- a/static/bitcoin-dev/March_2022/combined_Meeting-Summary-Logs-for-CTV-Meeting-5.xml +++ b/static/bitcoin-dev/March_2022/combined_Meeting-Summary-Logs-for-CTV-Meeting-5.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Meeting Summary & Logs for CTV Meeting #5 - 2023-08-02T05:50:24.597524+00:00 - - Jorge Timón 2022-03-10 11:28:55+00:00 - - - ZmnSCPxj 2022-03-09 14:42:36+00:00 - - - Jorge Timón 2022-03-09 11:08:06+00:00 - - - Jeremy Rubin 2022-03-09 00:36:46+00:00 - + 2025-09-26T14:35:41.839986+00:00 + python-feedgen + + + [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5 Jeremy Rubin + 2022-03-09T00:36:00.000Z + + + Jorge Timón + 2022-03-09T11:08:00.000Z + + + ZmnSCPxj + 2022-03-09T14:42:00.000Z + + + Jorge Timón + 2022-03-10T11:28:00.000Z + + - python-feedgen + 2 Combined summary - Meeting Summary & Logs for CTV Meeting #5 - 2023-08-02T05:50:24.598524+00:00 + 2025-09-26T14:35:41.840662+00:00 - The conversation in the communication thread revolves around the concept of Speedy Trial (ST) and its implementation in relation to CTV. ST is a short softfork attempt with `lockinontimeout=false`, and if it fails, developers decide whether to offer a UASF `lockinontimeout=true` version or not. Jeremy Rubin demonstrated the complexity of ST through a state diagram, leading to a joke about using `OP_RING` instead of implementing `OP_CTV`. Criticism of ST is discussed, highlighting concerns about miners and users having less opportunity to oppose a malevolent change imposed by miners. The trust factor of developers is also brought up, with one participant expressing distrust towards Jeremy Rubin, although acknowledging that this is subjective and off-topic.The conversation further explains that users with mining hashpower can block the initial Speedy Trial, which should prompt developers to listen to their concerns. If developers fail to do so, a counter-UASF can be written, rejecting blocks signaling for the upgrade. Clients using the initial Speedy Trial code will follow the chain with better hashpower. Therefore, users who want to resist or support a particular softfork have the ability to resist Speedy Trial and even run a counter-UASF if developers release a UASF `lockinontimeout=true` later. The conversation emphasizes the importance of understanding activation mechanisms and how users can actively resist them. In another discussion on the bitcoin-dev mailing list, Jeremy Rubin shares updates on various topics. Firstly, Sapio now has experimental Taproot support, and assistance is needed for reviewing Rust-bitcoin. Secondly, he explains the concept of Transaction Sponsors and why it doesn't have a BIP number assigned. Thirdly, James' Vaults Post is mentioned, which explores recursive CTV vaults. Fourthly, there is a conversation about adding more power to protocols and proposed solutions for infrastructure issues related to flexible covenants. Finally, there is a general discussion on naming conventions and forking, with some participants expressing concern about Speedy Trial and proposing unique names like "Hot Tub Coin Machine" and "OP_DOTHETHING".The Bitcoin Core Tech meeting on March 8th, 2022, covered several topics. Firstly, Sapio now has experimental Taproot support, and assistance is needed for reviewing Rust-bitcoin's pull request for MuSig support. Secondly, the meeting discussed transaction sponsors and their differences from RBF/CPFP, as well as the absence of a BIP number assigned to them. The third topic was James' Vaults post, which explores the customization of vaults. Fourthly, the meeting discussed the potential dangers of adding too much power to scripts and the difficulty of generating a transition function for more flexible covenants. Finally, there was a general discussion on naming protocols and forking, with participants expressing concerns about Speedy Trial and suggesting unique names for projects. 2022-03-10T11:28:55+00:00 + The conversation in the communication thread revolves around the concept of Speedy Trial (ST) and its implementation in relation to CTV. ST is a short softfork attempt with `lockinontimeout=false`, and if it fails, developers decide whether to offer a UASF `lockinontimeout=true` version or not. Jeremy Rubin demonstrated the complexity of ST through a state diagram, leading to a joke about using `OP_RING` instead of implementing `OP_CTV`. Criticism of ST is discussed, highlighting concerns about miners and users having less opportunity to oppose a malevolent change imposed by miners. The trust factor of developers is also brought up, with one participant expressing distrust towards Jeremy Rubin, although acknowledging that this is subjective and off-topic.The conversation further explains that users with mining hashpower can block the initial Speedy Trial, which should prompt developers to listen to their concerns. If developers fail to do so, a counter-UASF can be written, rejecting blocks signaling for the upgrade. Clients using the initial Speedy Trial code will follow the chain with better hashpower. Therefore, users who want to resist or support a particular softfork have the ability to resist Speedy Trial and even run a counter-UASF if developers release a UASF `lockinontimeout=true` later. The conversation emphasizes the importance of understanding activation mechanisms and how users can actively resist them. In another discussion on the bitcoin-dev mailing list, Jeremy Rubin shares updates on various topics. Firstly, Sapio now has experimental Taproot support, and assistance is needed for reviewing Rust-bitcoin. Secondly, he explains the concept of Transaction Sponsors and why it doesn't have a BIP number assigned. Thirdly, James' Vaults Post is mentioned, which explores recursive CTV vaults. Fourthly, there is a conversation about adding more power to protocols and proposed solutions for infrastructure issues related to flexible covenants. Finally, there is a general discussion on naming conventions and forking, with some participants expressing concern about Speedy Trial and proposing unique names like "Hot Tub Coin Machine" and "OP_DOTHETHING".The Bitcoin Core Tech meeting on March 8th, 2022, covered several topics. Firstly, Sapio now has experimental Taproot support, and assistance is needed for reviewing Rust-bitcoin's pull request for MuSig support. Secondly, the meeting discussed transaction sponsors and their differences from RBF/CPFP, as well as the absence of a BIP number assigned to them. The third topic was James' Vaults post, which explores the customization of vaults. Fourthly, the meeting discussed the potential dangers of adding too much power to scripts and the difficulty of generating a transition function for more flexible covenants. Finally, there was a general discussion on naming protocols and forking, with participants expressing concerns about Speedy Trial and suggesting unique names for projects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_OP-RETURN-inside-TapScript.xml b/static/bitcoin-dev/March_2022/combined_OP-RETURN-inside-TapScript.xml index 36d9fa81db..6c1b92f7e8 100644 --- a/static/bitcoin-dev/March_2022/combined_OP-RETURN-inside-TapScript.xml +++ b/static/bitcoin-dev/March_2022/combined_OP-RETURN-inside-TapScript.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - OP_RETURN inside TapScript - 2023-08-02T05:43:57.141649+00:00 - - Kostas Karasavvas 2022-03-21 11:00:38+00:00 - - - vjudeu at gazeta.pl 2022-03-19 18:32:00+00:00 - - - Peter Todd 2022-03-16 18:21:30+00:00 - - - Zac Greenwood 2022-02-25 13:53:57+00:00 - - - ZmnSCPxj 2022-02-25 12:48:11+00:00 - - - Zac Greenwood 2022-02-25 07:15:06+00:00 - - - ZmnSCPxj 2022-02-25 03:19:34+00:00 - - - Zac Greenwood 2022-02-25 01:12:34+00:00 - - - ZmnSCPxj 2022-02-25 00:04:54+00:00 - - - Zac Greenwood 2022-02-24 21:40:57+00:00 - - - Ruben Somsen 2022-02-24 14:01:58+00:00 - - - vjudeu at gazeta.pl 2022-02-24 13:27:16+00:00 - - - Ruben Somsen 2022-02-24 10:08:22+00:00 - - - vjudeu at gazeta.pl 2022-02-24 09:02:08+00:00 - + 2025-09-26T14:35:11.846793+00:00 + python-feedgen + + + [bitcoin-dev] OP_RETURN inside TapScript vjudeu + 2022-02-24T09:02:00.000Z + + + Ruben Somsen + 2022-02-24T10:08:00.000Z + + + vjudeu + 2022-02-24T13:27:00.000Z + + + Ruben Somsen + 2022-02-24T14:01:00.000Z + + + Zac Greenwood + 2022-02-24T21:40:00.000Z + + + ZmnSCPxj + 2022-02-25T00:04:00.000Z + + + Zac Greenwood + 2022-02-25T01:12:00.000Z + + + ZmnSCPxj + 2022-02-25T03:19:00.000Z + + + Zac Greenwood + 2022-02-25T07:15:00.000Z + + + ZmnSCPxj + 2022-02-25T12:48:00.000Z + + + Zac Greenwood + 2022-02-25T13:53:00.000Z + + + Peter Todd + 2022-03-16T18:21:00.000Z + + + vjudeu + 2022-03-19T18:32:00.000Z + + + Kostas Karasavvas + 2022-03-21T11:00:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - OP_RETURN inside TapScript - 2023-08-02T05:43:57.141649+00:00 + 2025-09-26T14:35:11.848360+00:00 - With the activation of Taproot, it is now possible to attach data to a transaction by creating an "OP_RETURN" branch in the TapScript. This eliminates the need for separate OP_RETURN outputs and allows for more than 80 bytes of data to be stored for free. The data can be stored off-chain but will always be connected to a taproot address that was pushed on-chain. It's important to note that this capability has always existed and is not specific to tapscript.Committing to an ECC point enables data to be stored inside it, including P2PK and P2PKH. It is also possible to commit to large amounts of data, such as 1.5GB, using OP_RETURN or even an entire merkle tree of hashes. However, altering an ECC point, including tapscript, in non-deterministic ways can make it more difficult to recover from backup because the key cannot be recovered without knowing the full commitment.While "OP_RETURN" in TapScript allows for data attachment, it differs from OP_RETURN as the user must communicate out-of-band to reveal the commitment. In contrast, with OP_RETURN, the data is immediately visible. The immediate visibility of data is utilized by various colored coin protocols and BIP47.The question arises whether the implementation should be changed to place the "data" field in "createrawtransaction" into a TapScript instead of creating a separate OP_RETURN output. Currently, Bitcoin Core has a "data" field in "createrawtransaction". By placing this data in a TapScript, it would be possible to eliminate the need for a separate OP_RETURN output and simplify the process of attaching data to a transaction.In summary, Taproot allows for the attachment of data to a transaction by creating an "OP_RETURN" branch in the TapScript. This eliminates the need for separate OP_RETURN outputs and enables more than 80 bytes of data to be stored for free. The implementation may need to be changed to place the "data" field in "createrawtransaction" into a TapScript, streamlining the process of attaching data to a transaction. 2022-03-21T11:00:38+00:00 + With the activation of Taproot, it is now possible to attach data to a transaction by creating an "OP_RETURN" branch in the TapScript. This eliminates the need for separate OP_RETURN outputs and allows for more than 80 bytes of data to be stored for free. The data can be stored off-chain but will always be connected to a taproot address that was pushed on-chain. It's important to note that this capability has always existed and is not specific to tapscript.Committing to an ECC point enables data to be stored inside it, including P2PK and P2PKH. It is also possible to commit to large amounts of data, such as 1.5GB, using OP_RETURN or even an entire merkle tree of hashes. However, altering an ECC point, including tapscript, in non-deterministic ways can make it more difficult to recover from backup because the key cannot be recovered without knowing the full commitment.While "OP_RETURN" in TapScript allows for data attachment, it differs from OP_RETURN as the user must communicate out-of-band to reveal the commitment. In contrast, with OP_RETURN, the data is immediately visible. The immediate visibility of data is utilized by various colored coin protocols and BIP47.The question arises whether the implementation should be changed to place the "data" field in "createrawtransaction" into a TapScript instead of creating a separate OP_RETURN output. Currently, Bitcoin Core has a "data" field in "createrawtransaction". By placing this data in a TapScript, it would be possible to eliminate the need for a separate OP_RETURN output and simplify the process of attaching data to a transaction.In summary, Taproot allows for the attachment of data to a transaction by creating an "OP_RETURN" branch in the TapScript. This eliminates the need for separate OP_RETURN outputs and enables more than 80 bytes of data to be stored for free. The implementation may need to be changed to place the "data" field in "createrawtransaction" into a TapScript, streamlining the process of attaching data to a transaction. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_One-testnet-to-rule-them-all.xml b/static/bitcoin-dev/March_2022/combined_One-testnet-to-rule-them-all.xml index a62b85208b..28a87eddf0 100644 --- a/static/bitcoin-dev/March_2022/combined_One-testnet-to-rule-them-all.xml +++ b/static/bitcoin-dev/March_2022/combined_One-testnet-to-rule-them-all.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - One testnet to rule them all - 2023-08-02T05:48:33.453096+00:00 - - Jeremy Rubin 2022-03-05 23:40:11+00:00 - - - vjudeu at gazeta.pl 2022-03-05 18:17:07+00:00 - - - Jeremy Rubin 2022-03-05 16:19:26+00:00 - - - vjudeu at gazeta.pl 2022-03-04 20:46:04+00:00 - + 2025-09-26T14:35:20.363196+00:00 + python-feedgen + + + [bitcoin-dev] One testnet to rule them all vjudeu + 2022-03-04T20:46:00.000Z + + + Jeremy Rubin + 2022-03-05T16:19:00.000Z + + + vjudeu + 2022-03-05T18:17:00.000Z + + + Jeremy Rubin + 2022-03-05T23:40:00.000Z + + - python-feedgen + 2 Combined summary - One testnet to rule them all - 2023-08-02T05:48:33.453096+00:00 + 2025-09-26T14:35:20.363977+00:00 - The discussion on the Bitcoin-dev mailing list revolves around the use of testnet3 and signet for testing purposes in relation to sidechains. Some users argue that pegging worthless coins into a system of also worthless coins is pointless unless it is to test pegging mechanisms. However, others believe that testing pegging is necessary for introducing sidechains. The question arises as to why more than 21 million coins are required for testing if they are not needed for real transactions.Testnet3 is considered good enough to represent the main chain during sidechain testing because it is permissionless and open, allowing anyone to start mining sidechain blocks. The scarcity of coins in testnet3 is seen as a feature rather than a bug, as it allows users to see what can happen with a chain after many halvings. Miners in testnet3 can create, move, and destroy zero satoshis, extending the precision of the coins. This makes mining less cumbersome and eliminates the need to find testnet coins and peg them.A proposal discussed in the conversation involves creating one Taproot address per signet in testnet3, enabling coins to travel between many signets. New signets can be pegged in with a 1:1 ratio, and existing signets can be transformed into signet sidechains. Signet would replace testnet3 as the official signet, and other signets could be pegged into it as well. However, it is noted that signet degrades to a testnet if the key is set to OP_TRUE.The conversation also addresses the difficulty of obtaining testnet coins for testing purposes. It is suggested that moving coins to and from testnet3 via one testnet transaction every three months could allow the same coins to travel between multiple signets. Overall, the focus is on finding the best way to test sidechains using the available resources.In summary, the discussion on the Bitcoin-dev mailing list revolves around the use of testnet3 and signet for testing sidechains. There are differing opinions on the usefulness of pegging worthless coins and the need for more than 21 million coins for testing. Testnet3 is considered suitable for representing the main chain during sidechain testing due to its permissionless and open nature. The scarcity of coins in testnet3 is seen as a feature, allowing for the creation, movement, and destruction of zero satoshis. A proposal suggests creating one Taproot address per signet in testnet3 and enabling coins to travel between signets. There are also discussions about the difficulty of obtaining testnet coins for testing purposes. The focus is on finding the best approach to test sidechains using the available resources. 2022-03-05T23:40:11+00:00 + The discussion on the Bitcoin-dev mailing list revolves around the use of testnet3 and signet for testing purposes in relation to sidechains. Some users argue that pegging worthless coins into a system of also worthless coins is pointless unless it is to test pegging mechanisms. However, others believe that testing pegging is necessary for introducing sidechains. The question arises as to why more than 21 million coins are required for testing if they are not needed for real transactions.Testnet3 is considered good enough to represent the main chain during sidechain testing because it is permissionless and open, allowing anyone to start mining sidechain blocks. The scarcity of coins in testnet3 is seen as a feature rather than a bug, as it allows users to see what can happen with a chain after many halvings. Miners in testnet3 can create, move, and destroy zero satoshis, extending the precision of the coins. This makes mining less cumbersome and eliminates the need to find testnet coins and peg them.A proposal discussed in the conversation involves creating one Taproot address per signet in testnet3, enabling coins to travel between many signets. New signets can be pegged in with a 1:1 ratio, and existing signets can be transformed into signet sidechains. Signet would replace testnet3 as the official signet, and other signets could be pegged into it as well. However, it is noted that signet degrades to a testnet if the key is set to OP_TRUE.The conversation also addresses the difficulty of obtaining testnet coins for testing purposes. It is suggested that moving coins to and from testnet3 via one testnet transaction every three months could allow the same coins to travel between multiple signets. Overall, the focus is on finding the best way to test sidechains using the available resources.In summary, the discussion on the Bitcoin-dev mailing list revolves around the use of testnet3 and signet for testing sidechains. There are differing opinions on the usefulness of pegging worthless coins and the need for more than 21 million coins for testing. Testnet3 is considered suitable for representing the main chain during sidechain testing due to its permissionless and open nature. The scarcity of coins in testnet3 is seen as a feature, allowing for the creation, movement, and destruction of zero satoshis. A proposal suggests creating one Taproot address per signet in testnet3 and enabling coins to travel between signets. There are also discussions about the difficulty of obtaining testnet coins for testing purposes. The focus is on finding the best approach to test sidechains using the available resources. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Recurring-bitcoin-LN-payments-using-DLCs.xml b/static/bitcoin-dev/March_2022/combined_Recurring-bitcoin-LN-payments-using-DLCs.xml index 6b00da8c38..a6673daa07 100644 --- a/static/bitcoin-dev/March_2022/combined_Recurring-bitcoin-LN-payments-using-DLCs.xml +++ b/static/bitcoin-dev/March_2022/combined_Recurring-bitcoin-LN-payments-using-DLCs.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Recurring bitcoin/LN payments using DLCs - 2023-08-02T05:46:48.958437+00:00 - - Chris Stewart 2022-03-06 20:53:55+00:00 - - - ZmnSCPxj 2022-03-06 20:11:12+00:00 - - - Chris Stewart 2022-03-06 14:05:25+00:00 - - - Jeremy Rubin 2022-03-06 00:14:51+00:00 - - - ZmnSCPxj 2022-03-05 22:57:39+00:00 - - - Chris Stewart 2022-03-05 14:45:56+00:00 - - - ZmnSCPxj 2022-03-04 08:22:12+00:00 - - - Chris Stewart 2022-03-03 12:58:55+00:00 - + 2025-09-26T14:35:48.209455+00:00 + python-feedgen + + + [bitcoin-dev] Recurring bitcoin/LN payments using DLCs Chris Stewart + 2022-03-03T12:58:00.000Z + + + ZmnSCPxj + 2022-03-04T08:22:00.000Z + + + Chris Stewart + 2022-03-05T14:45:00.000Z + + + ZmnSCPxj + 2022-03-05T22:57:00.000Z + + + Jeremy Rubin + 2022-03-06T00:14:00.000Z + + + Chris Stewart + 2022-03-06T14:05:00.000Z + + + ZmnSCPxj + 2022-03-06T20:11:00.000Z + + + Chris Stewart + 2022-03-06T20:53:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Recurring bitcoin/LN payments using DLCs - 2023-08-02T05:46:48.959474+00:00 + 2025-09-26T14:35:48.210531+00:00 - In the context provided, the discussion revolves around the use of escrow providers and the challenges they face due to interactiveness at settlement time. PTLCs (Payment-Point Timelock Contracts) are proposed as a solution that offers non-interactive settlement, benefiting users Alice and Bob. The oracle issues attestations, which are used by Alice or Bob to complete the adaptor signature. This reduces the need for bi-directional communication during settlement, making DLC style applications more user-friendly.It is noted that the interactiveness requirements for LN (Lightning Network) are high, posing difficulties in developing applications, particularly for mobile platforms. However, PTLCs are transportable over LN, making them a viable replacement for 2-of-3 escrows.In a conversation between Chris and ZmnSCPxj, the advantages of PTLCs are emphasized. They eliminate the need for interactiveness at settlement time, improving the user experience. The oracle issues attestations, and Alice or Bob complete the adaptor signature using these attestations. Non-interactive settlement is highlighted as a significant advantage of DLC style applications.ZmnSCPxj proposes an example application where an oracle determines when a fund can be spent. A workperson completes some work, and the oracle judges if the work has been completed before compensation is made. It is suggested that this scheme can also be implemented using a simple 2-of-3 escrow, as the oracle attestation can be a partial signature. The possibility of multiple PTLCs triggered by a single oracle is also discussed.The conversation includes a link to a GitHub repository containing an old Python sapio contract that enables cancellable subscriptions functioning as a time-based autopay scheme. The email thread explores the idea of pre-approved lines of credit from a Bitcoin wallet, which can be drawn down with oracle attestations and may include locktimes for rate limiting. This scheme finds potential application in commissioning work from unbranded workpeople, where the oracle judges if the work has been completed before compensation.The discussion raises the question of whether multiple PTLCs triggered by a single oracle are the most suitable application for the proposed scheme. The context provides an overview of the scheme and its potential applications, highlighting its contextual nature.After further consideration, Chris agrees with ZmnSCPxj that the proposal for recurring payments is similar to nLocktime. To prevent malicious parties from withdrawing multiple subscriptions using oracle attestations, subsequent UTXOs can be rate-limited with nlocktimes. The use of pre-approved lines of credit from a bitcoin wallet, drawn down with oracle attestations and optional locktimes for rate limiting, is suggested as a method for implementing recurring payments.In response to ZmnSCPxj's question regarding the improvement of a certain process over 'nLockTime'd transactions, it is stated that more information about the specific process is needed for a comprehensive answer. 'nLockTime' is explained as a feature in Bitcoin transactions that allows the sender to specify a future time or block height for adding the transaction to the blockchain. Without additional details, it is challenging to compare the process being discussed with 'nLockTime' transactions.The benefits of Discreet Log Contracts (DLCs) are highlighted in the context. DLCs enable recurring subscriptions without on-chain transactions, similar to ACH in traditional finance. Users can set up DLCs with providers, allowing access to a predetermined amount of Bitcoin to be withdrawn at a specified future time. Netflix is given as an example, where an oracle represents a monthly subscription, and users have DLCs executed at the end of each month. DLCs are unilaterally funded, cancellable, and do not require Bitcoin transactions for creation. Providers can specify withdrawal limits, ensuring authorized amounts are not exceeded. The cryptographic enforcement of withdrawal limits adds an additional layer of security. Concerns about providers acting as both oracle and recipient are mitigated by the predetermined subscription amount, preventing excess fund withdrawal. Users can cancel subscriptions at any time, and providers can only steal up to one month's service fees across all customers. 2022-03-06T20:53:55+00:00 + In the context provided, the discussion revolves around the use of escrow providers and the challenges they face due to interactiveness at settlement time. PTLCs (Payment-Point Timelock Contracts) are proposed as a solution that offers non-interactive settlement, benefiting users Alice and Bob. The oracle issues attestations, which are used by Alice or Bob to complete the adaptor signature. This reduces the need for bi-directional communication during settlement, making DLC style applications more user-friendly.It is noted that the interactiveness requirements for LN (Lightning Network) are high, posing difficulties in developing applications, particularly for mobile platforms. However, PTLCs are transportable over LN, making them a viable replacement for 2-of-3 escrows.In a conversation between Chris and ZmnSCPxj, the advantages of PTLCs are emphasized. They eliminate the need for interactiveness at settlement time, improving the user experience. The oracle issues attestations, and Alice or Bob complete the adaptor signature using these attestations. Non-interactive settlement is highlighted as a significant advantage of DLC style applications.ZmnSCPxj proposes an example application where an oracle determines when a fund can be spent. A workperson completes some work, and the oracle judges if the work has been completed before compensation is made. It is suggested that this scheme can also be implemented using a simple 2-of-3 escrow, as the oracle attestation can be a partial signature. The possibility of multiple PTLCs triggered by a single oracle is also discussed.The conversation includes a link to a GitHub repository containing an old Python sapio contract that enables cancellable subscriptions functioning as a time-based autopay scheme. The email thread explores the idea of pre-approved lines of credit from a Bitcoin wallet, which can be drawn down with oracle attestations and may include locktimes for rate limiting. This scheme finds potential application in commissioning work from unbranded workpeople, where the oracle judges if the work has been completed before compensation.The discussion raises the question of whether multiple PTLCs triggered by a single oracle are the most suitable application for the proposed scheme. The context provides an overview of the scheme and its potential applications, highlighting its contextual nature.After further consideration, Chris agrees with ZmnSCPxj that the proposal for recurring payments is similar to nLocktime. To prevent malicious parties from withdrawing multiple subscriptions using oracle attestations, subsequent UTXOs can be rate-limited with nlocktimes. The use of pre-approved lines of credit from a bitcoin wallet, drawn down with oracle attestations and optional locktimes for rate limiting, is suggested as a method for implementing recurring payments.In response to ZmnSCPxj's question regarding the improvement of a certain process over 'nLockTime'd transactions, it is stated that more information about the specific process is needed for a comprehensive answer. 'nLockTime' is explained as a feature in Bitcoin transactions that allows the sender to specify a future time or block height for adding the transaction to the blockchain. Without additional details, it is challenging to compare the process being discussed with 'nLockTime' transactions.The benefits of Discreet Log Contracts (DLCs) are highlighted in the context. DLCs enable recurring subscriptions without on-chain transactions, similar to ACH in traditional finance. Users can set up DLCs with providers, allowing access to a predetermined amount of Bitcoin to be withdrawn at a specified future time. Netflix is given as an example, where an oracle represents a monthly subscription, and users have DLCs executed at the end of each month. DLCs are unilaterally funded, cancellable, and do not require Bitcoin transactions for creation. Providers can specify withdrawal limits, ensuring authorized amounts are not exceeded. The cryptographic enforcement of withdrawal limits adds an additional layer of security. Concerns about providers acting as both oracle and recipient are mitigated by the predetermined subscription amount, preventing excess fund withdrawal. Users can cancel subscriptions at any time, and providers can only steal up to one month's service fees across all customers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml b/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml index dbcb67d2bd..2871844a8e 100644 --- a/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml +++ b/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2023-08-02T05:36:35.237176+00:00 + 2025-09-26T14:35:46.097865+00:00 + python-feedgen Paul Sztorc 2022-03-04 20:06:50+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2023-08-02T05:36:35.237176+00:00 + 2025-09-26T14:35:46.098032+00:00 - In an email exchange on the bitcoin-dev mailing list, Billy Tetrud discusses sidechains and their potential to address the issue of a less-secure altcoin dominating Bitcoin. While he acknowledges some merits of sidechains in this scenario, Tetrud points out that they do not completely solve the problem. He raises concerns about a sidechain cutting off the main chain and whether it would be in the best interest of enough people. Tetrud also explores the benefits and drawbacks of largeblock sidechains compared to other payment systems like Visa and Lightning. Various tradeoffs, such as onboarding, payment speed, micropayments, fees, and contribution to layer 1 security budget, are considered. Tetrud concludes that if a layer 2 is harmless, its existence can be justified by one net benefit for some users.Another discussion revolves around the size of commitments needed for sidechains and channel factories. User ZmnSCPxj suggests a solution to reduce on-chain bytes by utilizing tweaks in the miner's key and unused TapScript. This eliminates the need for separate commitments and reduces data requirements. Additionally, sidechains can push zero bytes on-chain by using OP_RETURN inside TapScript for checking purposes.The conversation centers around the potential dominance of a sidechain over Bitcoin and how it could prevent an altcoin from dominating. The consensus is that having all chains, centralized and decentralized, in the same monetary unit ensures the decentralized chain always exists without interference from monetary network effects. However, it is argued that a sidechain cannot exist without its main chain, and if it becomes too popular, people may stop using the main chain altogether. The discussion also compares the benefits of a largeblock sidechain to Visa and Lightning and considers the burden on Bitcoin-only nodes. The potential advantages to users of a largeblock sidechain are discussed, including lower fees and more decentralization. The idea of sweeping fiat transactions into a largeblock sidechain is also explored.Another conversation between Billy Tetrud and Paul focuses on the use of sidechains in Bitcoin. Billy proposes that all chains, decentralized and centralized, being in the same monetary unit ensures the existence of the decentralized chain without interference from network effects. Paul disagrees, stating that sidechains cannot exist without their main chain and gives an example using a zcash sidechain. They also discuss the merits of largeblock sidechains and how they can allow users to easily sweep fiat transactions into the BTC universe. Paul believes that largeblock sidechains would not burden Bitcoin Core full nodes.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin scalability, sidechains, network effects, and the security of Lightning Network and Drivechains. Participants argue that sidechains are necessary to prevent people from switching entirely to altcoins, which could be heavily exploited by attackers. Another participant suggests that having all chains in the same monetary unit guarantees the existence of the decentralized chain. The discussion delves into the security risks of LN channel factories and compares the security of LN and Drivechains. The participants emphasize the importance of separating the onboarding rate from the payment rate for designing different structures.The email exchange on the bitcoin-dev mailing list centers around the use of recursive covenants and their potential impact on Bitcoin. The discussion explores implementing techniques like Drivechains using recursive covenants. While concerns about negative effects on Bitcoin or the user base are raised, it is suggested that separate soft forks can be used to add recursive covenants if consensus is reached. The rejection of Drivechains in Bitcoin is also discussed, with arguments made against their implementation due to their distinct security model and potential block size increase. However, proponents argue that Drivechains could have a positive impact and should be given a chance. The debate includes discussions on miner censorship, block size increase, and the need for consensus changes. Paul Sztorc responds to the rejection of Drivechains, stating that there is no strong incentive for mainchain miners and sidechain validators to merge their businesses. He refutes claims that Drivechains would degrade security and believes that Drivechain was ahead of its time and will eventually be adopted. Other discussions revolve around encumbrances and restrictions on spend from covenants, the potential harm to the fungibility of UTXOs, and the shift in risk models. Some argue that introducing different risk models can be damaging to fungibility, while others believe that being able to reject certain coins is at the heart of Bitcoin's security. The email exchanges highlight the ongoing debates and considerations surrounding recursive covenants, Drivechains, and their potential impact on Bitcoin.In a recent email to the Bitcoin-dev mailing list, Jeremy Rubin raises concerns about proposals enabling more "featureful" covenants by adding additional computation into bitcoin script. They emphasize the importance of limiting operations in bitcoin script to "verification" rather than "computation" whenever possible. The author expresses uncertainty about these proposals and fears that opcodes like OP_CAT and OP_TX introduce unnecessary complexity into the script. However, 2022-03-04T20:06:50+00:00 + In an email exchange on the bitcoin-dev mailing list, Billy Tetrud discusses sidechains and their potential to address the issue of a less-secure altcoin dominating Bitcoin. While he acknowledges some merits of sidechains in this scenario, Tetrud points out that they do not completely solve the problem. He raises concerns about a sidechain cutting off the main chain and whether it would be in the best interest of enough people. Tetrud also explores the benefits and drawbacks of largeblock sidechains compared to other payment systems like Visa and Lightning. Various tradeoffs, such as onboarding, payment speed, micropayments, fees, and contribution to layer 1 security budget, are considered. Tetrud concludes that if a layer 2 is harmless, its existence can be justified by one net benefit for some users.Another discussion revolves around the size of commitments needed for sidechains and channel factories. User ZmnSCPxj suggests a solution to reduce on-chain bytes by utilizing tweaks in the miner's key and unused TapScript. This eliminates the need for separate commitments and reduces data requirements. Additionally, sidechains can push zero bytes on-chain by using OP_RETURN inside TapScript for checking purposes.The conversation centers around the potential dominance of a sidechain over Bitcoin and how it could prevent an altcoin from dominating. The consensus is that having all chains, centralized and decentralized, in the same monetary unit ensures the decentralized chain always exists without interference from monetary network effects. However, it is argued that a sidechain cannot exist without its main chain, and if it becomes too popular, people may stop using the main chain altogether. The discussion also compares the benefits of a largeblock sidechain to Visa and Lightning and considers the burden on Bitcoin-only nodes. The potential advantages to users of a largeblock sidechain are discussed, including lower fees and more decentralization. The idea of sweeping fiat transactions into a largeblock sidechain is also explored.Another conversation between Billy Tetrud and Paul focuses on the use of sidechains in Bitcoin. Billy proposes that all chains, decentralized and centralized, being in the same monetary unit ensures the existence of the decentralized chain without interference from network effects. Paul disagrees, stating that sidechains cannot exist without their main chain and gives an example using a zcash sidechain. They also discuss the merits of largeblock sidechains and how they can allow users to easily sweep fiat transactions into the BTC universe. Paul believes that largeblock sidechains would not burden Bitcoin Core full nodes.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin scalability, sidechains, network effects, and the security of Lightning Network and Drivechains. Participants argue that sidechains are necessary to prevent people from switching entirely to altcoins, which could be heavily exploited by attackers. Another participant suggests that having all chains in the same monetary unit guarantees the existence of the decentralized chain. The discussion delves into the security risks of LN channel factories and compares the security of LN and Drivechains. The participants emphasize the importance of separating the onboarding rate from the payment rate for designing different structures.The email exchange on the bitcoin-dev mailing list centers around the use of recursive covenants and their potential impact on Bitcoin. The discussion explores implementing techniques like Drivechains using recursive covenants. While concerns about negative effects on Bitcoin or the user base are raised, it is suggested that separate soft forks can be used to add recursive covenants if consensus is reached. The rejection of Drivechains in Bitcoin is also discussed, with arguments made against their implementation due to their distinct security model and potential block size increase. However, proponents argue that Drivechains could have a positive impact and should be given a chance. The debate includes discussions on miner censorship, block size increase, and the need for consensus changes. Paul Sztorc responds to the rejection of Drivechains, stating that there is no strong incentive for mainchain miners and sidechain validators to merge their businesses. He refutes claims that Drivechains would degrade security and believes that Drivechain was ahead of its time and will eventually be adopted. Other discussions revolve around encumbrances and restrictions on spend from covenants, the potential harm to the fungibility of UTXOs, and the shift in risk models. Some argue that introducing different risk models can be damaging to fungibility, while others believe that being able to reject certain coins is at the heart of Bitcoin's security. The email exchanges highlight the ongoing debates and considerations surrounding recursive covenants, Drivechains, and their potential impact on Bitcoin.In a recent email to the Bitcoin-dev mailing list, Jeremy Rubin raises concerns about proposals enabling more "featureful" covenants by adding additional computation into bitcoin script. They emphasize the importance of limiting operations in bitcoin script to "verification" rather than "computation" whenever possible. The author expresses uncertainty about these proposals and fears that opcodes like OP_CAT and OP_TX introduce unnecessary complexity into the script. However, - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Removing-the-Dust-Limit.xml b/static/bitcoin-dev/March_2022/combined_Removing-the-Dust-Limit.xml index 4cbc05258f..fc0ffddee2 100644 --- a/static/bitcoin-dev/March_2022/combined_Removing-the-Dust-Limit.xml +++ b/static/bitcoin-dev/March_2022/combined_Removing-the-Dust-Limit.xml @@ -1,119 +1,151 @@ - + 2 Combined summary - Removing the Dust Limit - 2023-08-02T04:31:39.825006+00:00 - - vjudeu at gazeta.pl 2022-03-12 13:02:24+00:00 - - - ZmnSCPxj 2021-10-08 22:47:11+00:00 - - - ZmnSCPxj 2021-10-08 10:38:50+00:00 - - - shymaa arafat 2021-10-08 07:44:59+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 10:35:16+00:00 - - - ZmnSCPxj 2021-10-07 10:01:53+00:00 - - - shymaa arafat 2021-10-07 09:13:33+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 08:34:17+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 08:17:40+00:00 - - - ZmnSCPxj 2021-10-07 04:52:01+00:00 - - - Erik Aronesty 2021-10-01 13:40:06+00:00 - - - Pieter Wuille 2021-09-30 22:07:08+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-08-30 03:31:56+00:00 - - - shymaa arafat 2021-08-27 09:07:35+00:00 - - - Billy Tetrud 2021-08-26 21:21:25+00:00 - - - ZmnSCPxj 2021-08-21 03:10:46+00:00 - - - shymaa arafat 2021-08-20 05:45:31+00:00 - - - Jeremy 2021-08-20 04:51:31+00:00 - - - shymaa arafat 2021-08-18 19:06:30+00:00 - - - Anthony Towns 2021-08-12 22:03:39+00:00 - - - ZmnSCPxj 2021-08-11 00:46:36+00:00 - - - Antoine Riard 2021-08-10 22:37:48+00:00 - - - Charlie Lee 2021-08-10 18:39:39+00:00 - - - ZmnSCPxj 2021-08-10 11:37:37+00:00 - - - David A. Harding 2021-08-10 06:14:41+00:00 - - - Billy Tetrud 2021-08-10 05:44:04+00:00 - - - Jeremy 2021-08-10 05:04:07+00:00 - - - Billy Tetrud 2021-08-10 00:30:02+00:00 - - - Antoine Riard 2021-08-09 13:22:28+00:00 - - - Karl 2021-08-09 11:58:03+00:00 - - - Prayank 2021-08-09 10:25:50+00:00 - - - Jeremy 2021-08-08 23:07:27+00:00 - - - Jeremy 2021-08-08 22:46:26+00:00 - - - David A. Harding 2021-08-08 21:51:01+00:00 - - - Oleg Andreev 2021-08-08 21:41:32+00:00 - - - Matt Corallo 2021-08-08 21:14:23+00:00 - - - Jeremy 2021-08-08 18:52:55+00:00 - + 2025-09-26T14:35:35.423366+00:00 + python-feedgen + + + [bitcoin-dev] Removing the Dust Limit Jeremy + 2021-08-08T18:52:00.000Z + + + Matt Corallo + 2021-08-08T21:14:00.000Z + + + Oleg Andreev + 2021-08-08T21:41:00.000Z + + + [bitcoin-dev] [Lightning-dev] " David A. Harding + 2021-08-08T21:51:00.000Z + + + Jeremy + 2021-08-08T22:46:00.000Z + + + Jeremy + 2021-08-08T23:07:00.000Z + + + [bitcoin-dev] " Prayank + 2021-08-09T10:25:00.000Z + + + Karl + 2021-08-09T11:58:00.000Z + + + Antoine Riard + 2021-08-09T13:22:00.000Z + + + Billy Tetrud + 2021-08-10T00:30:00.000Z + + + Jeremy + 2021-08-10T05:04:00.000Z + + + Billy Tetrud + 2021-08-10T05:44:00.000Z + + + David A. Harding + 2021-08-10T06:14:00.000Z + + + ZmnSCPxj + 2021-08-10T11:37:00.000Z + + + Charlie Lee + 2021-08-10T18:39:00.000Z + + + Antoine Riard + 2021-08-10T22:37:00.000Z + + + ZmnSCPxj + 2021-08-11T00:46:00.000Z + + + Anthony Towns + 2021-08-12T22:03:00.000Z + + + Jeremy + 2021-08-20T04:51:00.000Z + + + shymaa arafat + 2021-08-20T05:45:00.000Z + + + ZmnSCPxj + 2021-08-21T03:10:00.000Z + + + Billy Tetrud + 2021-08-26T21:21:00.000Z + + + shymaa arafat + 2021-08-27T09:07:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-08-30T03:31:00.000Z + + + Pieter Wuille + 2021-09-30T22:07:00.000Z + + + Erik Aronesty + 2021-10-01T13:40:00.000Z + + + ZmnSCPxj + 2021-10-07T04:52:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T08:17:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T08:34:00.000Z + + + shymaa arafat + 2021-10-07T09:13:00.000Z + + + ZmnSCPxj + 2021-10-07T10:01:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T10:35:00.000Z + + + shymaa arafat + 2021-10-08T07:44:00.000Z + + + ZmnSCPxj + 2021-10-08T10:38:00.000Z + + + ZmnSCPxj + 2021-10-08T22:47:00.000Z + + @@ -151,13 +183,13 @@ - python-feedgen + 2 Combined summary - Removing the Dust Limit - 2023-08-02T04:31:39.825967+00:00 + 2025-09-26T14:35:35.426842+00:00 - Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees. However, this short-term incentive is countered by concerns about spam and dust fingerprinting attacks.In conclusion, 2022-03-12T13:02:24+00:00 + Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees. However, this short-term incentive is countered by concerns about spam and dust fingerprinting attacks.In conclusion, - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Silent-Payments-Non-interactive-private-payments-with-no-on-chain-overhead.xml b/static/bitcoin-dev/March_2022/combined_Silent-Payments-Non-interactive-private-payments-with-no-on-chain-overhead.xml index 366b5ba0f8..81765c3288 100644 --- a/static/bitcoin-dev/March_2022/combined_Silent-Payments-Non-interactive-private-payments-with-no-on-chain-overhead.xml +++ b/static/bitcoin-dev/March_2022/combined_Silent-Payments-Non-interactive-private-payments-with-no-on-chain-overhead.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Silent Payments – Non-interactive private payments with no on-chain overhead - 2023-08-02T05:56:55.480642+00:00 - - Erik Aronesty 2022-05-25 13:13:05+00:00 - - - alicexbt 2022-05-24 13:49:34+00:00 - - - woltx 2022-05-24 01:31:23+00:00 - - - Ruben Somsen 2022-03-31 10:48:41+00:00 - - - Billy 2022-03-30 16:09:22+00:00 - - - Billy 2022-03-30 05:58:18+00:00 - - - Ruben Somsen 2022-03-29 15:36:13+00:00 - - - Billy 2022-03-29 14:57:33+00:00 - - - Ruben Somsen 2022-03-28 15:27:56+00:00 - + 2025-09-26T14:35:22.509838+00:00 + python-feedgen + + + [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead Ruben Somsen + 2022-03-28T15:27:00.000Z + + + Billy + 2022-03-29T14:57:00.000Z + + + Ruben Somsen + 2022-03-29T15:36:00.000Z + + + Billy + 2022-03-30T05:58:00.000Z + + + Billy + 2022-03-30T16:09:00.000Z + + + Ruben Somsen + 2022-03-31T10:48:00.000Z + + + woltx + 2022-05-24T01:31:00.000Z + + + alicexbt + 2022-05-24T13:49:00.000Z + + + Erik Aronesty + 2022-05-25T13:13:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Silent Payments – Non-interactive private payments with no on-chain overhead - 2023-08-02T05:56:55.480642+00:00 + 2025-09-26T14:35:22.511025+00:00 - Ruben Somsen has proposed a new scheme called Silent Payments for private non-interactive address generation without on-chain overhead. In this scheme, the recipient generates a silent payment address and makes it publicly known, while the sender uses a public key from one of their chosen inputs to derive a shared secret that is used to tweak the silent payment address. This approach avoids using the Bitcoin blockchain as a messaging layer and requires no interaction between the sender and recipient, other than knowing the silent payment address.However, there are some downsides to this scheme. One limitation is the scanning requirement, which may not be suitable for light clients. Additionally, the scheme requires the sender to have control over their own input(s). Silent payments aim to prevent input linkage in Bitcoin transactions, which is important for privacy preservation, but it can introduce weaknesses such as revealing the intended recipient to other coinjoin users. To address this weakness, the proposal includes a blinding scheme to hide the silent payment address from other participants.The article compares Silent Payments with other protocols that offer similar functionality. Payment Code Sharing involves sending an OP_RETURN message on-chain to establish a shared secret prior to making payments. Xpub Sharing involves handing out an xpub instead of an address upon first payment to enable repeat payments. Regular Address Sharing requires interaction for every single payment, whereas Silent Payments do not.The proposed scheme of Silent Payments aims to provide a solution for private transactions by allowing fresh address generation, compatibility with one-time seed backups, and improved privacy. However, it still faces challenges such as the scanning requirement and lack of light client support. There are open questions regarding the implementation of Silent Payments, including the speed of required database lookups, support for light clients, preferred input tweaking, potential security issues in the proposed cryptography, and whether the added complexity of the scheme is worth it.One side-benefit of Silent Payments is that BIP32 HD keys won't be needed for address generation since every address will automatically be unique. Overall, Silent Payments have not been seriously considered before and may be reasonably viable, especially if the focus is on detecting only unspent payments by scanning the UTXO set. The article recommends reading the gist for improved formatting and potential future edits.In a separate discussion on the Bitcoin-dev mailing list, David Wagner's Blind Diffie-Hellman Key Exchange is mentioned in relation to the review of the Taproot BIP. The discussion provides a link to Wagner's explanation of the key exchange through a Gist on GitHub.The bitcoin-dev mailing list serves as a platform for further discussion and collaboration on Bitcoin development. The article acknowledges the help of others in the development of these protocols and provides references to related articles and schemes for further reading. 2022-05-25T13:13:05+00:00 + Ruben Somsen has proposed a new scheme called Silent Payments for private non-interactive address generation without on-chain overhead. In this scheme, the recipient generates a silent payment address and makes it publicly known, while the sender uses a public key from one of their chosen inputs to derive a shared secret that is used to tweak the silent payment address. This approach avoids using the Bitcoin blockchain as a messaging layer and requires no interaction between the sender and recipient, other than knowing the silent payment address.However, there are some downsides to this scheme. One limitation is the scanning requirement, which may not be suitable for light clients. Additionally, the scheme requires the sender to have control over their own input(s). Silent payments aim to prevent input linkage in Bitcoin transactions, which is important for privacy preservation, but it can introduce weaknesses such as revealing the intended recipient to other coinjoin users. To address this weakness, the proposal includes a blinding scheme to hide the silent payment address from other participants.The article compares Silent Payments with other protocols that offer similar functionality. Payment Code Sharing involves sending an OP_RETURN message on-chain to establish a shared secret prior to making payments. Xpub Sharing involves handing out an xpub instead of an address upon first payment to enable repeat payments. Regular Address Sharing requires interaction for every single payment, whereas Silent Payments do not.The proposed scheme of Silent Payments aims to provide a solution for private transactions by allowing fresh address generation, compatibility with one-time seed backups, and improved privacy. However, it still faces challenges such as the scanning requirement and lack of light client support. There are open questions regarding the implementation of Silent Payments, including the speed of required database lookups, support for light clients, preferred input tweaking, potential security issues in the proposed cryptography, and whether the added complexity of the scheme is worth it.One side-benefit of Silent Payments is that BIP32 HD keys won't be needed for address generation since every address will automatically be unique. Overall, Silent Payments have not been seriously considered before and may be reasonably viable, especially if the focus is on detecting only unspent payments by scanning the UTXO set. The article recommends reading the gist for improved formatting and potential future edits.In a separate discussion on the Bitcoin-dev mailing list, David Wagner's Blind Diffie-Hellman Key Exchange is mentioned in relation to the review of the Taproot BIP. The discussion provides a link to Wagner's explanation of the key exchange through a Gist on GitHub.The bitcoin-dev mailing list serves as a platform for further discussion and collaboration on Bitcoin development. The article acknowledges the help of others in the development of these protocols and provides references to related articles and schemes for further reading. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Speedy-Trial.xml b/static/bitcoin-dev/March_2022/combined_Speedy-Trial.xml index ca05dc1c40..57513e7743 100644 --- a/static/bitcoin-dev/March_2022/combined_Speedy-Trial.xml +++ b/static/bitcoin-dev/March_2022/combined_Speedy-Trial.xml @@ -1,167 +1,223 @@ - + 2 Combined summary - Speedy Trial - 2023-08-02T05:53:16.831910+00:00 - - Billy Tetrud 2022-04-27 02:35:49+00:00 - - - Erik Aronesty 2022-04-26 13:05:56+00:00 - - - Anthony Towns 2022-04-26 05:42:14+00:00 - - - Keagan McClelland 2022-04-25 17:26:09+00:00 - - - Anthony Towns 2022-04-25 17:00:12+00:00 - - - Keagan McClelland 2022-04-25 16:11:45+00:00 - - - Jorge Timón 2022-04-24 12:44:16+00:00 - - - Anthony Towns 2022-04-24 12:14:29+00:00 - - - Jorge Timón 2022-04-24 11:13:08+00:00 - - - Anthony Towns 2022-04-11 13:05:22+00:00 - - - Jorge Timón 2022-04-08 09:58:48+00:00 - - - pushd 2022-03-31 15:55:49+00:00 - - - Billy Tetrud 2022-03-31 15:34:26+00:00 - - - pushd 2022-03-31 14:19:36+00:00 - - - Billy Tetrud 2022-03-31 04:31:09+00:00 - - - pushd 2022-03-30 21:14:16+00:00 - - - Billy Tetrud 2022-03-30 20:10:49+00:00 - - - pushd 2022-03-30 10:34:45+00:00 - - - Anthony Towns 2022-03-30 04:21:06+00:00 - - - Jorge Timón 2022-03-28 08:31:18+00:00 - - - pushd 2022-03-26 12:59:12+00:00 - - - Anthony Towns 2022-03-26 01:45:46+00:00 - - - Jorge Timón 2022-03-24 18:30:09+00:00 - - - Kate Salazar 2022-03-23 22:34:21+00:00 - - - Anthony Towns 2022-03-22 23:49:51+00:00 - - - vjudeu at gazeta.pl 2022-03-22 16:37:01+00:00 - - - Eric Voskuil 2022-03-22 15:45:55+00:00 - - - Billy Tetrud 2022-03-22 15:19:30+00:00 - - - vjudeu at gazeta.pl 2022-03-21 15:56:03+00:00 - - - Billy Tetrud 2022-03-21 03:41:42+00:00 - - - vjudeu at gazeta.pl 2022-03-19 16:43:42+00:00 - - - ZmnSCPxj 2022-03-18 23:01:43+00:00 - - - Jorge Timón 2022-03-18 18:36:03+00:00 - - - Billy Tetrud 2022-03-17 15:38:53+00:00 - - - pushd 2022-03-17 14:34:49+00:00 - - - Jorge Timón 2022-03-17 14:04:32+00:00 - - - Jorge Timón 2022-03-17 12:18:11+00:00 - - - Jorge Timón 2022-03-17 12:08:25+00:00 - - - Jorge Timón 2022-03-17 11:32:24+00:00 - - - Billy Tetrud 2022-03-17 04:17:20+00:00 - - - Jeremy Rubin 2022-03-15 17:21:29+00:00 - - - Anthony Towns 2022-03-15 15:45:49+00:00 - - - Billy Tetrud 2022-03-12 17:52:59+00:00 - - - pushd 2022-03-12 17:11:29+00:00 - - - Russell O'Connor 2022-03-12 13:34:59+00:00 - - - Billy Tetrud 2022-03-11 16:26:21+00:00 - - - Jorge Timón 2022-03-11 14:04:29+00:00 - - - Russell O'Connor 2022-03-11 13:47:14+00:00 - - - Jorge Timón 2022-03-11 12:19:36+00:00 - - - pushd 2022-03-11 11:14:33+00:00 - - - Billy Tetrud 2022-03-11 05:41:58+00:00 - - - Luke Dashjr 2022-03-11 00:28:08+00:00 - - - Russell O'Connor 2022-03-11 00:12:19+00:00 - + 2025-09-26T14:35:33.266571+00:00 + python-feedgen + + + [bitcoin-dev] Speedy Trial Russell O'Connor + 2022-03-11T00:12:00.000Z + + + Luke Dashjr + 2022-03-11T00:28:00.000Z + + + Billy Tetrud + 2022-03-11T05:41:00.000Z + + + pushd + 2022-03-11T11:14:00.000Z + + + Jorge Timón + 2022-03-11T12:19:00.000Z + + + Russell O'Connor + 2022-03-11T13:47:00.000Z + + + Jorge Timón + 2022-03-11T14:04:00.000Z + + + Billy Tetrud + 2022-03-11T16:26:00.000Z + + + Russell O'Connor + 2022-03-12T13:34:00.000Z + + + pushd + 2022-03-12T17:11:00.000Z + + + Billy Tetrud + 2022-03-12T17:52:00.000Z + + + Anthony Towns + 2022-03-15T15:45:00.000Z + + + Jeremy Rubin + 2022-03-15T17:21:00.000Z + + + Billy Tetrud + 2022-03-17T04:17:00.000Z + + + Jorge Timón + 2022-03-17T11:32:00.000Z + + + Jorge Timón + 2022-03-17T12:08:00.000Z + + + Jorge Timón + 2022-03-17T12:18:00.000Z + + + Jorge Timón + 2022-03-17T14:04:00.000Z + + + pushd + 2022-03-17T14:34:00.000Z + + + Billy Tetrud + 2022-03-17T15:38:00.000Z + + + Jorge Timón + 2022-03-18T18:36:00.000Z + + + ZmnSCPxj + 2022-03-18T23:01:00.000Z + + + vjudeu + 2022-03-19T16:43:00.000Z + + + Billy Tetrud + 2022-03-21T03:41:00.000Z + + + vjudeu + 2022-03-21T15:56:00.000Z + + + Billy Tetrud + 2022-03-22T15:19:00.000Z + + + Eric Voskuil + 2022-03-22T15:45:00.000Z + + + vjudeu + 2022-03-22T16:37:00.000Z + + + Anthony Towns + 2022-03-22T23:49:00.000Z + + + Kate Salazar + 2022-03-23T22:34:00.000Z + + + Jorge Timón + 2022-03-24T18:30:00.000Z + + + Anthony Towns + 2022-03-26T01:45:00.000Z + + + pushd + 2022-03-26T12:59:00.000Z + + + Jorge Timón + 2022-03-28T08:31:00.000Z + + + Anthony Towns + 2022-03-30T04:21:00.000Z + + + pushd + 2022-03-30T10:34:00.000Z + + + Billy Tetrud + 2022-03-30T20:10:00.000Z + + + pushd + 2022-03-30T21:14:00.000Z + + + Billy Tetrud + 2022-03-31T04:31:00.000Z + + + pushd + 2022-03-31T14:19:00.000Z + + + Billy Tetrud + 2022-03-31T15:34:00.000Z + + + pushd + 2022-03-31T15:55:00.000Z + + + Jorge Timón + 2022-04-08T09:58:00.000Z + + + Anthony Towns + 2022-04-11T13:05:00.000Z + + + Jorge Timón + 2022-04-24T11:13:00.000Z + + + Anthony Towns + 2022-04-24T12:14:00.000Z + + + Jorge Timón + 2022-04-24T12:44:00.000Z + + + Keagan McClelland + 2022-04-25T16:11:00.000Z + + + Anthony Towns + 2022-04-25T17:00:00.000Z + + + Keagan McClelland + 2022-04-25T17:26:00.000Z + + + Anthony Towns + 2022-04-26T05:42:00.000Z + + + Erik Aronesty + 2022-04-26T13:05:00.000Z + + + Billy Tetrud + 2022-04-27T02:35:00.000Z + + @@ -215,13 +271,13 @@ - python-feedgen + 2 Combined summary - Speedy Trial - 2023-08-02T05:53:16.832917+00:00 + 2025-09-26T14:35:33.271854+00:00 - In the ongoing discussion within the Bitcoin community, consensus-building methods are being evaluated. Some propose setting specific criteria for determining consensus and involving non-developer stakeholders in the decision-making process. Ideas such as wallet votes and coin-weighted polling are being considered, but concerns about centralization pressures have been raised.On the technical side, there are questions regarding how nodes decide which blocks to orphan when only some of them need to signal. It has been clarified that in a semi-mandatory signaling system like BIP8, only "threshold" blocks are required to signal. If only a small percentage of miners fail to signal and the threshold is set high enough, no blocks will be orphaned. However, if any block would cause the entire threshold period to fail, it will be orphaned.The debate on whether miners or users should lead in decision-making continues, with the agreement that users ultimately lead and miners need to be prepared to upgrade their software. The concept of "evil" forks and the defense of Bitcoin against them is questioned, as defending against a fallacy of reification is not necessary. Systematically measuring user consensus without resorting to gaming the system or centralization is deemed challenging.Discussions between Anthony Towns and Jorge Timón delve into the advantages and disadvantages of bip8 and speedy trial. Towns argues that bip8 is not superior to speedy trial for activating bad soft forks, while Timón emphasizes the importance of considering user resistance. Keagan also points out that bip8 lacks mandatory signaling during the lock-in period, which makes it more difficult to counter a soft fork.Email exchanges between Towns and Timón further explore the topic of bip8 activation for bad soft forks. Towns maintains that bip8 is never superior to speedy trial, except when miners correctly identify a bad fork. Timón expresses frustration at feeling ignored, leading to the abrupt end of the conversation.The conversation expands to include other participants, discussing scenarios where bip8 fails compared to speedy trial. Timón presents hypothetical situations where bip8 with lot=true would activate an evil fork while speedy trial would block it. Towns argues that bip8 is designed for activating good proposals and that flawed ones should be stopped during the review process. The discussion becomes confrontational, with Timón accusing Towns of not understanding his points. Despite attempts at resolution, the conversation ends with Timón deciding to cease communication on the matter.Pushd raises concerns about the misconception that Bitcoin soft fork upgrades are decided by a majority vote of miners. They argue that this misunderstanding has been misused by mining pools in the past and creates a contentious environment. Billy Tetrud disagrees, suggesting that the solution lies in better explaining speedy trial to those who misunderstand it. Pushd counters by listing the downsides of this misunderstanding, including wasted time during the signaling period and giving miners an advantage over economic nodes. The need to address misconceptions and improve the understanding of soft fork activation mechanisms is emphasized.The discussion continues with a debate over whether changing the design or improving explanations is the solution to address the misconceptions. Different viewpoints are presented, with some advocating for a better activation method like BIP8/LOT=TRUE, while others argue for persistent explanation. The downsides of the current system, such as wasted time during signaling and the perception of voting, are highlighted. The conclusion emphasizes the importance of understanding the nuances of soft fork activation and finding ways to address any misconceptions.In a recent discussion on the bitcoin-dev mailing list, there is a debate about whether bitcoin upgrades are made based on miners' votes. While some argue that miners should have the power to approve changes, others believe that the confusion surrounding miner signaling and voting needs to be addressed through better explanations.The conversation explores different activation methods, including BIP 8/LOT=TRUE, which is seen as a simpler alternative. However, there are concerns about changing how Bitcoin is engineered for the sake of optics. Instead, it is suggested that explaining the speedy trial process more clearly can help prevent misunderstandings.The flaws in the speedy trial narrative are discussed, with concerns that it can mislead users into thinking that miner signaling is how Bitcoin upgrades are voted in. It is noted that flawed proposals making it through activation is a failure of the review process. The percentage of supermajority hashpower is decided by Bitcoin core developers, who can choose not to follow old or new consensus rules at any time.The conversation also touches on hypothetical scenarios, where someone being able to block a change is undesirable and could harm bitcoin. There is disagreement on whether solutions should allow blocking an evil fork, as it could also be used to block a good fork. The importance of rejecting bad premises and focusing on reasonable discussions is emphasized.In another thread, participants express their preferences for BIP 8's LOT parameter, citing its benefits of giving more power to users and reducing politics and controversies. The determination of an enemy or opposition in certain steps is questioned, and there is mention of parallel lines 2022-04-27T02:35:49+00:00 + In the ongoing discussion within the Bitcoin community, consensus-building methods are being evaluated. Some propose setting specific criteria for determining consensus and involving non-developer stakeholders in the decision-making process. Ideas such as wallet votes and coin-weighted polling are being considered, but concerns about centralization pressures have been raised.On the technical side, there are questions regarding how nodes decide which blocks to orphan when only some of them need to signal. It has been clarified that in a semi-mandatory signaling system like BIP8, only "threshold" blocks are required to signal. If only a small percentage of miners fail to signal and the threshold is set high enough, no blocks will be orphaned. However, if any block would cause the entire threshold period to fail, it will be orphaned.The debate on whether miners or users should lead in decision-making continues, with the agreement that users ultimately lead and miners need to be prepared to upgrade their software. The concept of "evil" forks and the defense of Bitcoin against them is questioned, as defending against a fallacy of reification is not necessary. Systematically measuring user consensus without resorting to gaming the system or centralization is deemed challenging.Discussions between Anthony Towns and Jorge Timón delve into the advantages and disadvantages of bip8 and speedy trial. Towns argues that bip8 is not superior to speedy trial for activating bad soft forks, while Timón emphasizes the importance of considering user resistance. Keagan also points out that bip8 lacks mandatory signaling during the lock-in period, which makes it more difficult to counter a soft fork.Email exchanges between Towns and Timón further explore the topic of bip8 activation for bad soft forks. Towns maintains that bip8 is never superior to speedy trial, except when miners correctly identify a bad fork. Timón expresses frustration at feeling ignored, leading to the abrupt end of the conversation.The conversation expands to include other participants, discussing scenarios where bip8 fails compared to speedy trial. Timón presents hypothetical situations where bip8 with lot=true would activate an evil fork while speedy trial would block it. Towns argues that bip8 is designed for activating good proposals and that flawed ones should be stopped during the review process. The discussion becomes confrontational, with Timón accusing Towns of not understanding his points. Despite attempts at resolution, the conversation ends with Timón deciding to cease communication on the matter.Pushd raises concerns about the misconception that Bitcoin soft fork upgrades are decided by a majority vote of miners. They argue that this misunderstanding has been misused by mining pools in the past and creates a contentious environment. Billy Tetrud disagrees, suggesting that the solution lies in better explaining speedy trial to those who misunderstand it. Pushd counters by listing the downsides of this misunderstanding, including wasted time during the signaling period and giving miners an advantage over economic nodes. The need to address misconceptions and improve the understanding of soft fork activation mechanisms is emphasized.The discussion continues with a debate over whether changing the design or improving explanations is the solution to address the misconceptions. Different viewpoints are presented, with some advocating for a better activation method like BIP8/LOT=TRUE, while others argue for persistent explanation. The downsides of the current system, such as wasted time during signaling and the perception of voting, are highlighted. The conclusion emphasizes the importance of understanding the nuances of soft fork activation and finding ways to address any misconceptions.In a recent discussion on the bitcoin-dev mailing list, there is a debate about whether bitcoin upgrades are made based on miners' votes. While some argue that miners should have the power to approve changes, others believe that the confusion surrounding miner signaling and voting needs to be addressed through better explanations.The conversation explores different activation methods, including BIP 8/LOT=TRUE, which is seen as a simpler alternative. However, there are concerns about changing how Bitcoin is engineered for the sake of optics. Instead, it is suggested that explaining the speedy trial process more clearly can help prevent misunderstandings.The flaws in the speedy trial narrative are discussed, with concerns that it can mislead users into thinking that miner signaling is how Bitcoin upgrades are voted in. It is noted that flawed proposals making it through activation is a failure of the review process. The percentage of supermajority hashpower is decided by Bitcoin core developers, who can choose not to follow old or new consensus rules at any time.The conversation also touches on hypothetical scenarios, where someone being able to block a change is undesirable and could harm bitcoin. There is disagreement on whether solutions should allow blocking an evil fork, as it could also be used to block a good fork. The importance of rejecting bad premises and focusing on reasonable discussions is emphasized.In another thread, participants express their preferences for BIP 8's LOT parameter, citing its benefits of giving more power to users and reducing politics and controversies. The determination of an enemy or opposition in certain steps is questioned, and there is mention of parallel lines - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Wasabi-Wallet-2-0-Testnet-Release.xml b/static/bitcoin-dev/March_2022/combined_Wasabi-Wallet-2-0-Testnet-Release.xml index 4651b4ccaf..7e4c530fd8 100644 --- a/static/bitcoin-dev/March_2022/combined_Wasabi-Wallet-2-0-Testnet-Release.xml +++ b/static/bitcoin-dev/March_2022/combined_Wasabi-Wallet-2-0-Testnet-Release.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Wasabi Wallet 2.0 Testnet Release - 2023-08-02T05:46:22.084545+00:00 - - nopara73 2022-03-10 12:33:21+00:00 - - - Prayank 2022-03-02 04:24:00+00:00 - - - nopara73 2022-03-01 22:50:24+00:00 - - - Max Hillebrand 2022-03-01 20:48:20+00:00 - + 2025-09-26T14:35:16.108153+00:00 + python-feedgen + + + [bitcoin-dev] Wasabi Wallet 2.0 Testnet Release Max Hillebrand + 2022-03-01T20:48:00.000Z + + + nopara73 + 2022-03-01T22:50:00.000Z + + + Prayank + 2022-03-02T04:24:00.000Z + + + nopara73 + 2022-03-10T12:33:00.000Z + + - python-feedgen + 2 Combined summary - Wasabi Wallet 2.0 Testnet Release - 2023-08-02T05:46:22.084545+00:00 + 2025-09-26T14:35:16.108826+00:00 - The recently released Wasabi Wallet 2.0 offers enhanced privacy features for users. While the wallet does not have coin control, it utilizes coinjoined coins that are indistinguishable to ensure transaction privacy. In cases where coinjoined coins cannot be used, the wallet employs an improved version of coin control that selects clusters of coins assumed to belong to the same wallet. The owner has control over who can see the ownership of equalized coinjoin UTXOs.The wallet operates based on the user's assumption of its threat model and does not mislead the user. However, using a change address in transactions can impact privacy. To make it difficult to analyze possible recipients, the wallet suggests using a change address that is the same as other outputs. It should be noted that Wasabi Wallet does not offer different types of addresses specifically for change. Nonetheless, recent improvements made by Bitcoin Core may enhance privacy in this regard.Some issues related to privacy, security, and other aspects remain unresolved and are discussed on GitHub or in various discussions. While the bitcoin-dev mailing list may not be the primary platform for target users of Wasabi 2.0, developers could benefit from being aware of its innovations.The new version of Wasabi Wallet introduces deep Tor integration and BIP158 block filters or the packaged Bitcoin full node to provide effortless privacy. The blockchain layer incorporates the Wabisabi coinjoin implementation, which replaces the ZeroLink coinjoin coordination protocol. This implementation enables anonymous DoS protection for centrally coordinated coinjoins without relying on equal amount outputs.The coordination allows for a more sophisticated amount decomposition, resulting in "changeless" coinjoins that reduce mining fees and the time until the user's utxo set is private. The user experience is designed to be simple: receive, wait, spend privately. When spending Bitcoin to an address, the wallet automatically selects private coins with sufficient sats and displays coin control to the user. Adjusting the payment amount slightly is recommended to avoid creating a change utxo, thereby decreasing fees and enhancing future privacy.In Wasabi Wallet, labeling is mandatory, abstracting away the concept of utxos and displaying only contact labels for users to choose from. The 2.0 version can be downloaded from GitHub, and users are encouraged to test the new UI/UX, review the cryptography and coordination protocol, and analyze resulting transaction graphs in the wild. A testnet coordinator is provided with the release.Overall, Wasabi Wallet 2.0 aims to provide users with improved privacy features through its integration of Tor, implementation of the Wabisabi coinjoin protocol, and simplified user experience. Users are invited to test and provide feedback on the new version to further enhance its functionality. 2022-03-10T12:33:21+00:00 + The recently released Wasabi Wallet 2.0 offers enhanced privacy features for users. While the wallet does not have coin control, it utilizes coinjoined coins that are indistinguishable to ensure transaction privacy. In cases where coinjoined coins cannot be used, the wallet employs an improved version of coin control that selects clusters of coins assumed to belong to the same wallet. The owner has control over who can see the ownership of equalized coinjoin UTXOs.The wallet operates based on the user's assumption of its threat model and does not mislead the user. However, using a change address in transactions can impact privacy. To make it difficult to analyze possible recipients, the wallet suggests using a change address that is the same as other outputs. It should be noted that Wasabi Wallet does not offer different types of addresses specifically for change. Nonetheless, recent improvements made by Bitcoin Core may enhance privacy in this regard.Some issues related to privacy, security, and other aspects remain unresolved and are discussed on GitHub or in various discussions. While the bitcoin-dev mailing list may not be the primary platform for target users of Wasabi 2.0, developers could benefit from being aware of its innovations.The new version of Wasabi Wallet introduces deep Tor integration and BIP158 block filters or the packaged Bitcoin full node to provide effortless privacy. The blockchain layer incorporates the Wabisabi coinjoin implementation, which replaces the ZeroLink coinjoin coordination protocol. This implementation enables anonymous DoS protection for centrally coordinated coinjoins without relying on equal amount outputs.The coordination allows for a more sophisticated amount decomposition, resulting in "changeless" coinjoins that reduce mining fees and the time until the user's utxo set is private. The user experience is designed to be simple: receive, wait, spend privately. When spending Bitcoin to an address, the wallet automatically selects private coins with sufficient sats and displays coin control to the user. Adjusting the payment amount slightly is recommended to avoid creating a change utxo, thereby decreasing fees and enhancing future privacy.In Wasabi Wallet, labeling is mandatory, abstracting away the concept of utxos and displaying only contact labels for users to choose from. The 2.0 version can be downloaded from GitHub, and users are encouraged to test the new UI/UX, review the cryptography and coordination protocol, and analyze resulting transaction graphs in the wild. A testnet coordinator is provided with the release.Overall, Wasabi Wallet 2.0 aims to provide users with improved privacy features through its integration of Tor, implementation of the Wabisabi coinjoin protocol, and simplified user experience. Users are invited to test and provide feedback on the new version to further enhance its functionality. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_bitcoin-scripting-and-lisp.xml b/static/bitcoin-dev/March_2022/combined_bitcoin-scripting-and-lisp.xml index 4414a4037d..432c119167 100644 --- a/static/bitcoin-dev/March_2022/combined_bitcoin-scripting-and-lisp.xml +++ b/static/bitcoin-dev/March_2022/combined_bitcoin-scripting-and-lisp.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - bitcoin scripting and lisp - 2023-08-02T05:48:04.512962+00:00 - - Anthony Towns 2022-03-22 23:37:23+00:00 - - - Bram Cohen 2022-03-19 17:34:34+00:00 - - - ZmnSCPxj 2022-03-16 15:09:15+00:00 - - - ZmnSCPxj 2022-03-16 14:54:05+00:00 - - - Bram Cohen 2022-03-16 06:52:09+00:00 - - - Bram Cohen 2022-03-16 06:45:48+00:00 - - - Bram Cohen 2022-03-16 06:40:51+00:00 - - - Anthony Towns 2022-03-11 04:46:45+00:00 - - - Anthony Towns 2022-03-10 06:47:17+00:00 - - - ZmnSCPxj 2022-03-09 14:30:34+00:00 - - - Bram Cohen 2022-03-09 03:07:51+00:00 - - - Bram Cohen 2022-03-09 02:54:56+00:00 - - - Bram Cohen 2022-03-09 02:24:15+00:00 - - - ZmnSCPxj 2022-03-08 03:06:43+00:00 - - - Anthony Towns 2022-03-08 01:27:19+00:00 - - - ZmnSCPxj 2022-03-07 22:56:38+00:00 - - - Bram Cohen 2022-03-07 06:26:47+00:00 - - - Russell O'Connor 2022-03-06 02:09:45+00:00 - - - ZmnSCPxj 2022-03-05 23:20:20+00:00 - - - Russell O'Connor 2022-03-05 20:10:11+00:00 - - - Jeremy Rubin 2022-03-05 13:41:24+00:00 - - - ZmnSCPxj 2022-03-04 23:10:48+00:00 - - - Anthony Towns 2022-03-04 01:04:42+00:00 - + 2025-09-26T14:35:54.589259+00:00 + python-feedgen + + + Anthony Towns + 2022-03-04T01:04:00.000Z + + + ZmnSCPxj + 2022-03-04T23:10:00.000Z + + + Jeremy Rubin + 2022-03-05T13:41:00.000Z + + + Russell O'Connor + 2022-03-05T20:10:00.000Z + + + ZmnSCPxj + 2022-03-05T23:20:00.000Z + + + Russell O'Connor + 2022-03-06T02:09:00.000Z + + + [bitcoin-dev] bitcoin scripting and lisp Bram Cohen + 2022-03-07T06:26:00.000Z + + + ZmnSCPxj + 2022-03-07T22:56:00.000Z + + + Anthony Towns + 2022-03-08T01:27:00.000Z + + + ZmnSCPxj + 2022-03-08T03:06:00.000Z + + + Bram Cohen + 2022-03-09T02:24:00.000Z + + + Bram Cohen + 2022-03-09T02:54:00.000Z + + + Bram Cohen + 2022-03-09T03:07:00.000Z + + + ZmnSCPxj + 2022-03-09T14:30:00.000Z + + + Anthony Towns + 2022-03-10T06:47:00.000Z + + + Anthony Towns + 2022-03-11T04:46:00.000Z + + + Bram Cohen + 2022-03-16T06:40:00.000Z + + + Bram Cohen + 2022-03-16T06:45:00.000Z + + + Bram Cohen + 2022-03-16T06:52:00.000Z + + + ZmnSCPxj + 2022-03-16T14:54:00.000Z + + + ZmnSCPxj + 2022-03-16T15:09:00.000Z + + + Bram Cohen + 2022-03-19T17:34:00.000Z + + + Anthony Towns + 2022-03-22T23:37:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - bitcoin scripting and lisp - 2023-08-02T05:48:04.512962+00:00 + 2025-09-26T14:35:54.591885+00:00 - The bitcoin-dev mailing list discussion covered various topics related to improving efficiency in Bitcoin transactions. One suggestion was to discuss cross-input compression of puzzles/solutions, similar to the Chia network, which could save bytes and require less heavy crypto math. The conversation also explored the block packing problem and optimizing block templates to fit more transactions. BLS signatures and PTLC signatures were discussed, along with their benefits and drawbacks. The potential use of a domain-specific language (DSL) and concerns about code comments impacting the blockchain's size were briefly mentioned.In the discussion on cross-input compression, ZmnSCPxj noted that it could save bytes and require less heavy crypto math. BLS signatures were mentioned as a simpler alternative with efficient verification and aggregation. The costs involved in Chia transactions were compared, while in Bitcoin, the costs are implicitly tied together. The use of lisp-generating-lisp compression was discussed, along with its potential impact on CPU load.PTLC signatures were found to be incompatible with Chia due to the absence of secp256k1 operations and the loss of information when aggregated via BLS. However, the CLVM supports BLS12-381 operations, potentially enabling PTLCs in the future. The risks associated with implementing complex covenants directly in C++ were mentioned, and the advantages of using a DSL for covenants were highlighted.Another email thread focused on saving bytes in Bitcoin transactions by reusing single signatures or scriptPubKey templates. Key reuse was seen as undesirable, and instead, encouraging reuse of how pubkeys are used while rotating them was suggested. The potential savings in witness data for HTLCs were discussed, but PTLCs were considered more space-efficient. The implementation of covenant features using CLVM was noted as an advantage over soft fork deployment.The bitcoin-dev mailing list discussion covered various topics. Cross-input signature aggregation was compared to cross-input puzzle/solution compression, with the latter deemed less complicated. The idea of lisp-generating-lisp compression was discussed, along with potential CPU load implications. The compatibility of PTLCs with Chia was questioned due to the absence of secp256k1 operations and the loss of information when using BLS aggregation. The security implications of BLS signatures and concerns about implementing complex covenants directly in C++ were raised. The possibility of using a DSL for covenants was mentioned, though concerns about complexity and auditing were noted.In an exchange between Anthony Towns and an unknown party, the challenges of saving bytes in Bitcoin transactions through single signature reuse or scriptPubKey template reuse were discussed. Key reuse incentivization was identified as an issue, and the benefits and limitations of HTLCs and PTLCs were explored. The complexities and risks associated with implementing covenant features directly in C++ were highlighted.ZmnSCPxj explained the differences between Lisp and Chia in handling puzzles/solutions and cross-input signature aggregation. The importance of cross-transaction relationships in Bitcoin's context was emphasized. The discussion also touched on cost differences in jets and the lack of special treatment for generating Lisp code with Lisp code. Concerns about bugs in covenant complexity and the advantages of implementing covenant capabilities with a language implementation were mentioned.Bram Cohen and Anthony Towns discussed the possibility of redoing the singleton pattern in Bitcoin's context. They proposed passing both the full transaction being spent and the full transaction of its parent to retrieve the parent's scriptPubKey. The need for soft fork opcodes to allow spender flexibility and the use of lisp-like code fragments were suggested. The complications of implementing soft forks and the desirability of rejecting fakeopcodes were discussed.The benefits of cross-input signature aggregation were discussed, noting that BLS signatures could simplify the process. The suggestion of reusing single signatures or scriptPubKey templates for multiple inputs was made. The potential savings in witness data for HTLCs and PTLCs were explored, with PTLCs considered more space-efficient. Concerns about the complexity and risks of implementing covenant features were raised.The email thread delved into the details of cross-input signature aggregation and its complexities. The use of BLS signatures was highlighted as a way to simplify the process. The potential savings in bytes by reusing single signatures or scriptPubKey templates were mentioned. The discussion also touched on the complexities of covenant implementation and the risks associated with it.Overall, the discussions revolved around improving efficiency, reducing transaction size, and exploring different signature types and techniques in Bitcoin transactions.In a discussion about Bitcoin's scripting language, it is explained that in the coin set model, each puzzle (scriptpubkey) either fails an assert or returns a list of extra conditions. The language allows for recursive covenants through specifying output scriptpubkeys/puzzles. However, Bitcoin's script's ability to generate and parse transactions falls short. There is a hook for compression at the consensus layer, but it isn't aggressively used yet. The email also explores 2022-03-22T23:37:23+00:00 + The bitcoin-dev mailing list discussion covered various topics related to improving efficiency in Bitcoin transactions. One suggestion was to discuss cross-input compression of puzzles/solutions, similar to the Chia network, which could save bytes and require less heavy crypto math. The conversation also explored the block packing problem and optimizing block templates to fit more transactions. BLS signatures and PTLC signatures were discussed, along with their benefits and drawbacks. The potential use of a domain-specific language (DSL) and concerns about code comments impacting the blockchain's size were briefly mentioned.In the discussion on cross-input compression, ZmnSCPxj noted that it could save bytes and require less heavy crypto math. BLS signatures were mentioned as a simpler alternative with efficient verification and aggregation. The costs involved in Chia transactions were compared, while in Bitcoin, the costs are implicitly tied together. The use of lisp-generating-lisp compression was discussed, along with its potential impact on CPU load.PTLC signatures were found to be incompatible with Chia due to the absence of secp256k1 operations and the loss of information when aggregated via BLS. However, the CLVM supports BLS12-381 operations, potentially enabling PTLCs in the future. The risks associated with implementing complex covenants directly in C++ were mentioned, and the advantages of using a DSL for covenants were highlighted.Another email thread focused on saving bytes in Bitcoin transactions by reusing single signatures or scriptPubKey templates. Key reuse was seen as undesirable, and instead, encouraging reuse of how pubkeys are used while rotating them was suggested. The potential savings in witness data for HTLCs were discussed, but PTLCs were considered more space-efficient. The implementation of covenant features using CLVM was noted as an advantage over soft fork deployment.The bitcoin-dev mailing list discussion covered various topics. Cross-input signature aggregation was compared to cross-input puzzle/solution compression, with the latter deemed less complicated. The idea of lisp-generating-lisp compression was discussed, along with potential CPU load implications. The compatibility of PTLCs with Chia was questioned due to the absence of secp256k1 operations and the loss of information when using BLS aggregation. The security implications of BLS signatures and concerns about implementing complex covenants directly in C++ were raised. The possibility of using a DSL for covenants was mentioned, though concerns about complexity and auditing were noted.In an exchange between Anthony Towns and an unknown party, the challenges of saving bytes in Bitcoin transactions through single signature reuse or scriptPubKey template reuse were discussed. Key reuse incentivization was identified as an issue, and the benefits and limitations of HTLCs and PTLCs were explored. The complexities and risks associated with implementing covenant features directly in C++ were highlighted.ZmnSCPxj explained the differences between Lisp and Chia in handling puzzles/solutions and cross-input signature aggregation. The importance of cross-transaction relationships in Bitcoin's context was emphasized. The discussion also touched on cost differences in jets and the lack of special treatment for generating Lisp code with Lisp code. Concerns about bugs in covenant complexity and the advantages of implementing covenant capabilities with a language implementation were mentioned.Bram Cohen and Anthony Towns discussed the possibility of redoing the singleton pattern in Bitcoin's context. They proposed passing both the full transaction being spent and the full transaction of its parent to retrieve the parent's scriptPubKey. The need for soft fork opcodes to allow spender flexibility and the use of lisp-like code fragments were suggested. The complications of implementing soft forks and the desirability of rejecting fakeopcodes were discussed.The benefits of cross-input signature aggregation were discussed, noting that BLS signatures could simplify the process. The suggestion of reusing single signatures or scriptPubKey templates for multiple inputs was made. The potential savings in witness data for HTLCs and PTLCs were explored, with PTLCs considered more space-efficient. Concerns about the complexity and risks of implementing covenant features were raised.The email thread delved into the details of cross-input signature aggregation and its complexities. The use of BLS signatures was highlighted as a way to simplify the process. The potential savings in bytes by reusing single signatures or scriptPubKey templates were mentioned. The discussion also touched on the complexities of covenant implementation and the risks associated with it.Overall, the discussions revolved around improving efficiency, reducing transaction size, and exploring different signature types and techniques in Bitcoin transactions.In a discussion about Bitcoin's scripting language, it is explained that in the coin set model, each puzzle (scriptpubkey) either fails an assert or returns a list of extra conditions. The language allows for recursive covenants through specifying output scriptpubkeys/puzzles. However, Bitcoin's script's ability to generate and parse transactions falls short. There is a hook for compression at the consensus layer, but it isn't aggressively used yet. The email also explores - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_mempool-transaction-witness-replacement.xml b/static/bitcoin-dev/March_2022/combined_mempool-transaction-witness-replacement.xml index b5577a8a7e..5b5936f13a 100644 --- a/static/bitcoin-dev/March_2022/combined_mempool-transaction-witness-replacement.xml +++ b/static/bitcoin-dev/March_2022/combined_mempool-transaction-witness-replacement.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - mempool transaction witness-replacement - 2023-08-02T05:56:15.070778+00:00 - - darosior 2022-03-22 19:57:23+00:00 - - - Larry Ruane 2022-03-22 19:04:26+00:00 - + 2025-09-26T14:35:50.320798+00:00 + python-feedgen + + + [bitcoin-dev] mempool transaction witness-replacement Larry Ruane + 2022-03-22T19:04:00.000Z + + + darosior + 2022-03-22T19:57:00.000Z + + - python-feedgen + 2 Combined summary - mempool transaction witness-replacement - 2023-08-02T05:56:15.070778+00:00 + 2025-09-26T14:35:50.321274+00:00 - A proposal has been made by Larry Ruane to modify the Bitcoin Core mempool by allowing the replacement of existing transactions with ones that have the same transaction ID (txid), but a smaller witness and higher feerate. This change is miner-incentive compatible, meaning that miners would be more motivated to mine transactions with higher feerates. However, there are complications with Replace-By-Fee (RBF) that need to be considered before merging the proposed change. One concern is the code complexity cost, as well as the potential for transaction-relay Denial-of-Service (DoS) attacks. To address these concerns, a per-node setting could be implemented.One advantage of this change is that it may provide a defense against a mempool pinning attack. In scenarios where applications use same-txid-different-witness transactions shared between counterparties, this change would make those applications safer. Additionally, the proposal addresses the issue of DoS tradeoff. If the new transaction only has a slightly smaller witness, an attacker could repeatedly rebroadcast it, consuming significant amounts of relay bandwidth and CPU resources. On the other hand, if the new transaction must have a significantly smaller witness, it may not be possible to replace a transaction with a beneficially-smaller one.The proposed change, known as witness-replacement, is similar to RBF but differs in several ways. One key difference is that witness-replacement does not require evicting mempool descendant transactions because the inputs' txid references to their parent, who is being replaced, remain valid. Another distinction is that signaling is not required for witness-replacement since the outputs cannot be changed.While this proposal could be implemented as a per-node setting, it is desirable for the node network to reach a consensus on relay policies. Ultimately, the proposal aims to improve the efficiency and incentives for miners while addressing potential vulnerabilities and concerns associated with replacing transactions in the Bitcoin Core mempool. 2022-03-22T19:57:23+00:00 + A proposal has been made by Larry Ruane to modify the Bitcoin Core mempool by allowing the replacement of existing transactions with ones that have the same transaction ID (txid), but a smaller witness and higher feerate. This change is miner-incentive compatible, meaning that miners would be more motivated to mine transactions with higher feerates. However, there are complications with Replace-By-Fee (RBF) that need to be considered before merging the proposed change. One concern is the code complexity cost, as well as the potential for transaction-relay Denial-of-Service (DoS) attacks. To address these concerns, a per-node setting could be implemented.One advantage of this change is that it may provide a defense against a mempool pinning attack. In scenarios where applications use same-txid-different-witness transactions shared between counterparties, this change would make those applications safer. Additionally, the proposal addresses the issue of DoS tradeoff. If the new transaction only has a slightly smaller witness, an attacker could repeatedly rebroadcast it, consuming significant amounts of relay bandwidth and CPU resources. On the other hand, if the new transaction must have a significantly smaller witness, it may not be possible to replace a transaction with a beneficially-smaller one.The proposed change, known as witness-replacement, is similar to RBF but differs in several ways. One key difference is that witness-replacement does not require evicting mempool descendant transactions because the inputs' txid references to their parent, who is being replaced, remain valid. Another distinction is that signaling is not required for witness-replacement since the outputs cannot be changed.While this proposal could be implemented as a per-node setting, it is desirable for the node network to reach a consensus on relay policies. Ultimately, the proposal aims to improve the efficiency and incentives for miners while addressing potential vulnerabilities and concerns associated with replacing transactions in the Bitcoin Core mempool. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2023/combined_BIP-for-OP-VAULT.xml b/static/bitcoin-dev/March_2023/combined_BIP-for-OP-VAULT.xml index e91ec6d746..9eacb0d65b 100644 --- a/static/bitcoin-dev/March_2023/combined_BIP-for-OP-VAULT.xml +++ b/static/bitcoin-dev/March_2023/combined_BIP-for-OP-VAULT.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - BIP for OP_VAULT - 2023-08-02T08:58:20.823000+00:00 - - alicexbt 2023-03-30 18:12:46+00:00 - - - Zac Greenwood 2023-03-30 10:39:40+00:00 - - - Steve Lee 2023-03-30 00:16:43+00:00 - - - alicexbt 2023-03-29 19:57:08+00:00 - - - Zac Greenwood 2023-03-29 07:10:19+00:00 - - - Anthony Towns 2023-03-24 12:10:05+00:00 - - - Greg Sanders 2023-03-16 14:44:33+00:00 - - - Greg Sanders 2023-03-14 14:40:53+00:00 - - - Luke Dashjr 2023-03-13 20:55:00+00:00 - - - Brandon Black 2023-03-13 19:03:30+00:00 - - - Greg Sanders 2023-03-13 14:56:15+00:00 - - - Greg Sanders 2023-03-13 14:55:05+00:00 - - - Luke Dashjr 2023-03-11 20:53:21+00:00 - - - Anthony Towns 2023-03-10 01:08:55+00:00 - - - Greg Sanders 2023-03-09 18:45:15+00:00 - - - Anthony Towns 2023-03-07 12:45:34+00:00 - - - Greg Sanders 2023-03-06 16:07:38+00:00 - - - James O'Beirne 2023-03-06 15:25:38+00:00 - - - Andrew Melnychuk Oseen 2023-03-02 19:51:17+00:00 - - - Greg Sanders 2023-03-02 14:54:31+00:00 - - - Anthony Towns 2023-03-02 04:46:25+00:00 - - - Greg Sanders 2023-03-01 15:05:47+00:00 - - - James O'Beirne 2023-02-13 21:09:29+00:00 - + 2025-09-26T14:29:14.291685+00:00 + python-feedgen + + + [bitcoin-dev] BIP for OP_VAULT James O'Beirne + 2023-02-13T21:09:00.000Z + + + Greg Sanders + 2023-03-01T15:05:00.000Z + + + Anthony Towns + 2023-03-02T04:46:00.000Z + + + Greg Sanders + 2023-03-02T14:54:00.000Z + + + Andrew Melnychuk Oseen + 2023-03-02T19:51:00.000Z + + + James O'Beirne + 2023-03-06T15:25:00.000Z + + + Greg Sanders + 2023-03-06T16:07:00.000Z + + + Anthony Towns + 2023-03-07T12:45:00.000Z + + + Greg Sanders + 2023-03-09T18:45:00.000Z + + + Anthony Towns + 2023-03-10T01:08:00.000Z + + + Luke Dashjr + 2023-03-11T20:53:00.000Z + + + Greg Sanders + 2023-03-13T14:55:00.000Z + + + Greg Sanders + 2023-03-13T14:56:00.000Z + + + Brandon Black + 2023-03-13T19:03:00.000Z + + + Luke Dashjr + 2023-03-13T20:55:00.000Z + + + Greg Sanders + 2023-03-14T14:40:00.000Z + + + Greg Sanders + 2023-03-16T14:44:00.000Z + + + Anthony Towns + 2023-03-24T12:10:00.000Z + + + Zac Greenwood + 2023-03-29T07:10:00.000Z + + + alicexbt + 2023-03-29T19:57:00.000Z + + + Steve Lee + 2023-03-30T00:16:00.000Z + + + Zac Greenwood + 2023-03-30T10:39:00.000Z + + + alicexbt + 2023-03-30T18:12:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - BIP for OP_VAULT - 2023-08-02T08:58:20.824001+00:00 + 2025-09-26T14:29:14.294173+00:00 - The email exchange between Zac Greenwood and alicexbt revolves around whether Bitcoin should support private businesses that rely on on-chain storage. Zac argues against such businesses, stating that they contribute little fees while spamming the blockchain. Alicexbt disagrees, highlighting the value these businesses bring, including paying significant fees and attracting new users.In the discussion, Anthony Towns proposes four opcodes that could enable a fair, non-custodial, on-chain auction of ordinals. The proposed mechanism involves creating a utxo on-chain that can be spent in two ways: updating to a new bidder or awarding it to the current high bidder. This approach is resistant to MEV and scalable to larger auctions.The email also mentions the exploration of taproot, multisig, and other technologies within the Bitcoin community. It emphasizes the need to accommodate different visions of money to avoid becoming a niche technology.The discussion on the bitcoin-dev mailing list explores the potential use of opcodes to facilitate parasitical use cases of the blockchain. Some developers are exploring covenants and multisig, while others advocate for Bitcoin to accommodate different visions of money. Proposed opcodes could enable a fair, non-custodial, on-chain auction of ordinals. The script for this auction involves creating a utxo that commits to the address of the leading bidder. The approach is resistant to MEV and could be extended for other asset types.James O'Beirne discusses the concept of "forwarding" input amounts in the OP_VAULT proposal. He provides an example scenario where a user can spend a portion of their vaulted funds by supplying witness data. The proposed approach allows for multiple hot wallets or watchtowers to validate spends and recover funds on violations.The TLUV-ified OP_VAULT implementation is also discussed, aiming to simplify the spec and avoid nested and recursive script execution. The new implementation uses opcodes such as OP_VAULT, OP_VAULT_RECOVER, and OP_CHECKTEMPLATEVERIFY.In another email exchange, the proposed changes to TLUV-ify the OP_VAULT process are discussed. These changes would eliminate hashed commitments and recursive script execution, making the spec easier to understand and reducing indirection. The required opcodes for this implementation include OP_VAULT, OP_VAULT_RECOVER, and OP_CHECKTEMPLATEVERIFY.Finally, a user named Andrew expresses their desire for multiple tapleaves to be restricted in the amounts they can spend. They provide an example of how participants Alice, Bob, and Carol can have restrictions on their outputs based on the locking script.Overall, these discussions highlight various proposals and improvements to the OP_VAULT draft, aiming to enhance security, privacy, and efficiency in Bitcoin transactions. 2023-03-30T18:12:46+00:00 + The email exchange between Zac Greenwood and alicexbt revolves around whether Bitcoin should support private businesses that rely on on-chain storage. Zac argues against such businesses, stating that they contribute little fees while spamming the blockchain. Alicexbt disagrees, highlighting the value these businesses bring, including paying significant fees and attracting new users.In the discussion, Anthony Towns proposes four opcodes that could enable a fair, non-custodial, on-chain auction of ordinals. The proposed mechanism involves creating a utxo on-chain that can be spent in two ways: updating to a new bidder or awarding it to the current high bidder. This approach is resistant to MEV and scalable to larger auctions.The email also mentions the exploration of taproot, multisig, and other technologies within the Bitcoin community. It emphasizes the need to accommodate different visions of money to avoid becoming a niche technology.The discussion on the bitcoin-dev mailing list explores the potential use of opcodes to facilitate parasitical use cases of the blockchain. Some developers are exploring covenants and multisig, while others advocate for Bitcoin to accommodate different visions of money. Proposed opcodes could enable a fair, non-custodial, on-chain auction of ordinals. The script for this auction involves creating a utxo that commits to the address of the leading bidder. The approach is resistant to MEV and could be extended for other asset types.James O'Beirne discusses the concept of "forwarding" input amounts in the OP_VAULT proposal. He provides an example scenario where a user can spend a portion of their vaulted funds by supplying witness data. The proposed approach allows for multiple hot wallets or watchtowers to validate spends and recover funds on violations.The TLUV-ified OP_VAULT implementation is also discussed, aiming to simplify the spec and avoid nested and recursive script execution. The new implementation uses opcodes such as OP_VAULT, OP_VAULT_RECOVER, and OP_CHECKTEMPLATEVERIFY.In another email exchange, the proposed changes to TLUV-ify the OP_VAULT process are discussed. These changes would eliminate hashed commitments and recursive script execution, making the spec easier to understand and reducing indirection. The required opcodes for this implementation include OP_VAULT, OP_VAULT_RECOVER, and OP_CHECKTEMPLATEVERIFY.Finally, a user named Andrew expresses their desire for multiple tapleaves to be restricted in the amounts they can spend. They provide an example of how participants Alice, Bob, and Carol can have restrictions on their outputs based on the locking script.Overall, these discussions highlight various proposals and improvements to the OP_VAULT draft, aiming to enhance security, privacy, and efficiency in Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2023/combined_BIP-proposal-Fee-redistribution-contracts.xml b/static/bitcoin-dev/March_2023/combined_BIP-proposal-Fee-redistribution-contracts.xml index d53ad8bb53..f74b9617d4 100644 --- a/static/bitcoin-dev/March_2023/combined_BIP-proposal-Fee-redistribution-contracts.xml +++ b/static/bitcoin-dev/March_2023/combined_BIP-proposal-Fee-redistribution-contracts.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - BIP proposal: Fee-redistribution contracts - 2023-08-02T09:01:47.251880+00:00 - - David A. Harding 2023-03-01 17:17:58+00:00 - - - shymaa arafat 2023-02-28 10:02:47+00:00 - - - HcaFc_jbe 2023-02-27 21:41:35+00:00 - - - Rastislav Budinsky 2023-02-27 13:32:01+00:00 - + 2025-09-26T14:29:16.407928+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Fee-redistribution contracts Rastislav Budinsky + 2023-02-27T13:32:00.000Z + + + HcaFc_jbe + 2023-02-27T21:41:00.000Z + + + shymaa arafat + 2023-02-28T10:02:00.000Z + + + David A. Harding + 2023-03-01T17:17:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal: Fee-redistribution contracts - 2023-08-02T09:01:47.251880+00:00 + 2025-09-26T14:29:16.408659+00:00 - In a bitcoin-dev mailing list, Rastislav Budinsky proposed a solution where miners would only take a fraction M of the transaction fees, while the remaining fraction C would be sent to contracts for redistribution. However, Dave pointed out that miners can profit from confirming transactions through alternative means, such as "out-of-band fees". He explained that if consensus rules were changed to require each miner to pay a percentage of its in-band fees to future miners, it would incentivize miners to prefer out-of-band fees that wouldn't be subject to this redistribution scheme. This could potentially prevent the effective redistribution of fees as proposed by Rastislav's solution. Additionally, discussions on the mailing list have revealed that larger miners have an advantage over smaller miners in collecting miner-specific fee payments, which undermines the decentralization of Bitcoin's transaction confirmation mechanism.A Bachelor's thesis introduces a proposal to change the way transaction fees are collected and distributed in Bitcoin mining. The proposal suggests taking only a fraction of the fees while sending the rest to contracts for redistribution back to the miner in a "smarter" way. This approach aims to increase security and predictability against fluctuations in fees. However, the proposal has some flaws, including the possibility of undercutting attacks and challenges in achieving miner consensus. The lack of references to op_codes or implementations in the paper makes it unclear how the smart contract would be constructed. Nevertheless, the proposal offers a potential solution to address long-term miner incentives when block subsidies run out.The writer of the Bachelor's thesis proposes a new method of distributing transaction fees, where miners would take a fraction M of the fees, and the remaining fraction C would be sent to contracts for redistribution back to the miner. This approach aims to make mining more secure and predictable against significant fee fluctuations. The benefits of this proposal are discussed, highlighting a better mining environment. However, there are several challenges with the proposal, including the difficulty in constructing the smart contract and convincing the ecosystem to shift from a competitive to a cooperative mining incentive structure. The paper also notes an error in describing the distribution in block creation, which should be poisson instead of exponential. Further discussion is needed to achieve miner consensus and implement the fee-redistribution scheme effectively.The writer is working on their Bachelor's thesis, presenting a new approach to collecting transaction fees. Under this proposal, miners would only take a fraction M of the fees, while the remaining fraction C would be sent to contracts for redistribution back to the miner. This solution aims to enhance mining security and predictability regarding fee fluctuations. The benefits of the proposal are discussed, arguing that most miners should not oppose it as it creates a better mining environment. However, there are challenges highlighted in the paper, such as the difficulty in constructing the smart contract and persuading the ecosystem to transition from a competitive to a cooperative mining incentive structure. Furthermore, the paper acknowledges the need for further discussion on achieving miner consensus and implementing/updating the fee-redistribution scheme effectively. The writer also suggests considering a generally spendable script and embedding the correct logic into consensus nodes as a less disruptive alternative to a hard fork. The full paper can be accessed at [1]. 2023-03-01T17:17:58+00:00 + In a bitcoin-dev mailing list, Rastislav Budinsky proposed a solution where miners would only take a fraction M of the transaction fees, while the remaining fraction C would be sent to contracts for redistribution. However, Dave pointed out that miners can profit from confirming transactions through alternative means, such as "out-of-band fees". He explained that if consensus rules were changed to require each miner to pay a percentage of its in-band fees to future miners, it would incentivize miners to prefer out-of-band fees that wouldn't be subject to this redistribution scheme. This could potentially prevent the effective redistribution of fees as proposed by Rastislav's solution. Additionally, discussions on the mailing list have revealed that larger miners have an advantage over smaller miners in collecting miner-specific fee payments, which undermines the decentralization of Bitcoin's transaction confirmation mechanism.A Bachelor's thesis introduces a proposal to change the way transaction fees are collected and distributed in Bitcoin mining. The proposal suggests taking only a fraction of the fees while sending the rest to contracts for redistribution back to the miner in a "smarter" way. This approach aims to increase security and predictability against fluctuations in fees. However, the proposal has some flaws, including the possibility of undercutting attacks and challenges in achieving miner consensus. The lack of references to op_codes or implementations in the paper makes it unclear how the smart contract would be constructed. Nevertheless, the proposal offers a potential solution to address long-term miner incentives when block subsidies run out.The writer of the Bachelor's thesis proposes a new method of distributing transaction fees, where miners would take a fraction M of the fees, and the remaining fraction C would be sent to contracts for redistribution back to the miner. This approach aims to make mining more secure and predictable against significant fee fluctuations. The benefits of this proposal are discussed, highlighting a better mining environment. However, there are several challenges with the proposal, including the difficulty in constructing the smart contract and convincing the ecosystem to shift from a competitive to a cooperative mining incentive structure. The paper also notes an error in describing the distribution in block creation, which should be poisson instead of exponential. Further discussion is needed to achieve miner consensus and implement the fee-redistribution scheme effectively.The writer is working on their Bachelor's thesis, presenting a new approach to collecting transaction fees. Under this proposal, miners would only take a fraction M of the fees, while the remaining fraction C would be sent to contracts for redistribution back to the miner. This solution aims to enhance mining security and predictability regarding fee fluctuations. The benefits of the proposal are discussed, arguing that most miners should not oppose it as it creates a better mining environment. However, there are challenges highlighted in the paper, such as the difficulty in constructing the smart contract and persuading the ecosystem to transition from a competitive to a cooperative mining incentive structure. Furthermore, the paper acknowledges the need for further discussion on achieving miner consensus and implementing/updating the fee-redistribution scheme effectively. The writer also suggests considering a generally spendable script and embedding the correct logic into consensus nodes as a less disruptive alternative to a hard fork. The full paper can be accessed at [1]. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml b/static/bitcoin-dev/March_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml index d9eb5818ae..357794603a 100644 --- a/static/bitcoin-dev/March_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml +++ b/static/bitcoin-dev/March_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin fungibility and inscribed sats - 2023-08-02T09:02:43.756693+00:00 + 2025-09-26T14:29:07.842561+00:00 + python-feedgen Kree Love 2023-04-20 23:06:17+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin fungibility and inscribed sats - 2023-08-02T09:02:43.756693+00:00 + 2025-09-26T14:29:07.842698+00:00 - In a detailed message, the author shares their personal journey with Bitcoin, starting from late 2010 when they saw it as an electronic cash system. However, they express concern about the current state of Bitcoin, noting that it has become more of an electronic asset rather than a peer-to-peer cash system due to regulation and artificially limited block sizes causing network congestion and high fees.The author also highlights the challenges faced in improving fungibility, citing regulatory hostility towards protocols like CoinJoin. They emphasize the importance of practical applications and global usability for Bitcoin to maintain its status as a global currency, despite pressure from governments, industrial lobbies, and cartels.Furthermore, the author believes that Non-Fungible Tokens (NFTs) distract from the ongoing efforts to ensure the safety and stability of Bitcoin as a reserve currency. However, they clarify that NFTs do not affect the fungibility of Bitcoin itself, as there is no token standard being used. These sats or UTXOs can be sold as regular Bitcoin on exchanges and consolidated for use like any other Bitcoin.The issue of Bitcoin fungibility is acknowledged as debatable by the author, who is actively working on implementing a coinjoin feature to prevent censorship of post-mix UTXOs on certain exchanges. They also mention the existence of the Ordinals theory, where some users believe in it and strive to understand how Bitcoin works.Developers are mentioned as being interested in building various things around Bitcoin, including BIP, DEX, libraries, and projects implementing PSBT. The author acknowledges not living in a first-world country and not attending bitdevs but expresses their desire for Bitcoin to be accessible to all.In conclusion, the author urges people to freely use Bitcoin without changing consensus rules, as this approach will ultimately benefit Bitcoin. The message was sent using Proton Mail secure email. 2023-04-20T23:06:17+00:00 + In a detailed message, the author shares their personal journey with Bitcoin, starting from late 2010 when they saw it as an electronic cash system. However, they express concern about the current state of Bitcoin, noting that it has become more of an electronic asset rather than a peer-to-peer cash system due to regulation and artificially limited block sizes causing network congestion and high fees.The author also highlights the challenges faced in improving fungibility, citing regulatory hostility towards protocols like CoinJoin. They emphasize the importance of practical applications and global usability for Bitcoin to maintain its status as a global currency, despite pressure from governments, industrial lobbies, and cartels.Furthermore, the author believes that Non-Fungible Tokens (NFTs) distract from the ongoing efforts to ensure the safety and stability of Bitcoin as a reserve currency. However, they clarify that NFTs do not affect the fungibility of Bitcoin itself, as there is no token standard being used. These sats or UTXOs can be sold as regular Bitcoin on exchanges and consolidated for use like any other Bitcoin.The issue of Bitcoin fungibility is acknowledged as debatable by the author, who is actively working on implementing a coinjoin feature to prevent censorship of post-mix UTXOs on certain exchanges. They also mention the existence of the Ordinals theory, where some users believe in it and strive to understand how Bitcoin works.Developers are mentioned as being interested in building various things around Bitcoin, including BIP, DEX, libraries, and projects implementing PSBT. The author acknowledges not living in a first-world country and not attending bitdevs but expresses their desire for Bitcoin to be accessible to all.In conclusion, the author urges people to freely use Bitcoin without changing consensus rules, as this approach will ultimately benefit Bitcoin. The message was sent using Proton Mail secure email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2023/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml b/static/bitcoin-dev/March_2023/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml index 9af850445d..20c9b36b41 100644 --- a/static/bitcoin-dev/March_2023/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml +++ b/static/bitcoin-dev/March_2023/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Conjectures on solving the high interactivity issue in payment pools and channel factories - 2023-08-02T06:18:48.419381+00:00 - - Antoine Riard 2023-04-18 03:38:57+00:00 - - - jlspc 2023-03-17 20:54:51+00:00 - - - Billy Tetrud 2022-05-12 17:36:25+00:00 - - - ZmnSCPxj 2022-05-10 16:45:19+00:00 - - - Antoine Riard 2022-05-10 00:38:36+00:00 - - - Billy Tetrud 2022-05-01 22:53:13+00:00 - - - Antoine Riard 2022-04-28 13:18:05+00:00 - + 2025-09-26T14:29:05.696314+00:00 + python-feedgen + + + [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories Antoine Riard + 2022-04-28T13:18:00.000Z + + + Billy Tetrud + 2022-05-01T22:53:00.000Z + + + Antoine Riard + 2022-05-10T00:38:00.000Z + + + ZmnSCPxj + 2022-05-10T16:45:00.000Z + + + Billy Tetrud + 2022-05-12T17:36:00.000Z + + + jlspc + 2023-03-17T20:54:00.000Z + + + Antoine Riard + 2023-04-18T03:38:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Conjectures on solving the high interactivity issue in payment pools and channel factories - 2023-08-02T06:18:48.420890+00:00 + 2025-09-26T14:29:05.697282+00:00 - The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels. 2023-04-18T03:38:57+00:00 + The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/March_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 6c25093aa9..0f281ce89a 100644 --- a/static/bitcoin-dev/March_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/March_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:29:12.139212+00:00 + python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:29:12.139401+00:00 - On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to 2023-03-13T16:38:25+00:00 + On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2023/combined_Minimum-fees.xml b/static/bitcoin-dev/March_2023/combined_Minimum-fees.xml index 9ee8c1a936..6377713c00 100644 --- a/static/bitcoin-dev/March_2023/combined_Minimum-fees.xml +++ b/static/bitcoin-dev/March_2023/combined_Minimum-fees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Minimum fees - 2023-08-02T09:02:11.454433+00:00 + 2025-09-26T14:29:09.987583+00:00 + python-feedgen vjudeu at gazeta.pl 2023-03-05 21:58:51+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Minimum fees - 2023-08-02T09:02:11.454433+00:00 + 2025-09-26T14:29:09.987737+00:00 - The bitcoin community is considering a new protocol rule called min_fees, proposed by Giuseppe B. This rule would require miners to specify a minimum fee for the following block to be valid. The aim is to address the issue of low transaction fees and increase network security. Currently, transaction fees can be very small due to ample space in blocks. Users are willing to pay higher fees, but only if others do too. Miners also want higher fees. By implementing min_fees, the equilibrium could be brought closer to a socially optimal state. However, there are concerns about potential reorgs/orphan rates and chain instability. Further analysis and discussion are needed before implementing the rule. 2023-03-05T21:58:51+00:00 + The bitcoin community is considering a new protocol rule called min_fees, proposed by Giuseppe B. This rule would require miners to specify a minimum fee for the following block to be valid. The aim is to address the issue of low transaction fees and increase network security. Currently, transaction fees can be very small due to ample space in blocks. Users are willing to pay higher fees, but only if others do too. Miners also want higher fees. By implementing min_fees, the equilibrium could be brought closer to a socially optimal state. However, there are concerns about potential reorgs/orphan rates and chain instability. Further analysis and discussion are needed before implementing the rule. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2023/combined_Using-service-bit-24-for-utreexo-signaling-in-testnet-and-signet.xml b/static/bitcoin-dev/March_2023/combined_Using-service-bit-24-for-utreexo-signaling-in-testnet-and-signet.xml index f944466f0c..87f693e8b2 100644 --- a/static/bitcoin-dev/March_2023/combined_Using-service-bit-24-for-utreexo-signaling-in-testnet-and-signet.xml +++ b/static/bitcoin-dev/March_2023/combined_Using-service-bit-24-for-utreexo-signaling-in-testnet-and-signet.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Using service bit 24 for utreexo signaling in testnet and signet - 2023-08-02T09:02:27.387650+00:00 - - Peter Todd 2023-03-02 21:05:26+00:00 - - - Luke Dashjr 2023-03-02 18:20:35+00:00 - - - kcalvinalvin 2023-03-02 06:55:19+00:00 - + 2025-09-26T14:29:03.549430+00:00 + python-feedgen + + + [bitcoin-dev] Using service bit 24 for utreexo signaling in testnet and signet kcalvinalvin + 2023-03-02T06:55:00.000Z + + + Luke Dashjr + 2023-03-02T18:20:00.000Z + + + Peter Todd + 2023-03-02T21:05:00.000Z + + - python-feedgen + 2 Combined summary - Using service bit 24 for utreexo signaling in testnet and signet - 2023-08-02T09:02:27.387650+00:00 + 2025-09-26T14:29:03.549964+00:00 - On March 2, 2023, Luke Dashjr proposed the use of experimental service bits for experiments in a post on the bitcoin-dev mailing list. He suggested using an unused bit, bit 24, for signaling purposes related to the utreexo project. This suggestion came as the details of utreexo were not yet finalized and subject to change. Bit 26 is currently being used for full-rbf.In response to Luke's proposal, kcalvinalvin announced his intention to use service bit 24 (1 signet) for utreexo node binaries in a message to the bitcoin-dev mailing list. This decision was based on a comment in protocol.h in bitcoind, and plans were made to release the binaries for the utreexo node in the near future. However, there were no immediate plans to release binaries for mainnet. Calvin requested coordination with anyone else using the same bit for signaling other purposes.The use of service bit 24 for utreexo node binaries was seen as a significant development, prompting Luke to suggest documenting this information as a Bitcoin Improvement Proposal (BIP) and assigning a normal service bit for it.Overall, Bit 24 is a cloud-based service that offers developers a range of tools for creating, deploying, and managing applications in the cloud. It provides features such as automatic scaling, load balancing, data storage, and security. The platform supports multiple programming languages and frameworks, giving developers the flexibility to choose the technology stack that best suits their needs.In addition to its features, Bit 24 also offers a user-friendly interface, detailed documentation, and support to assist developers in setting up and managing their applications. With its comprehensive set of capabilities, Bit 24 is recommended as a reliable and flexible cloud-based service for building and deploying applications quickly and efficiently. 2023-03-02T21:05:26+00:00 + On March 2, 2023, Luke Dashjr proposed the use of experimental service bits for experiments in a post on the bitcoin-dev mailing list. He suggested using an unused bit, bit 24, for signaling purposes related to the utreexo project. This suggestion came as the details of utreexo were not yet finalized and subject to change. Bit 26 is currently being used for full-rbf.In response to Luke's proposal, kcalvinalvin announced his intention to use service bit 24 (1 signet) for utreexo node binaries in a message to the bitcoin-dev mailing list. This decision was based on a comment in protocol.h in bitcoind, and plans were made to release the binaries for the utreexo node in the near future. However, there were no immediate plans to release binaries for mainnet. Calvin requested coordination with anyone else using the same bit for signaling other purposes.The use of service bit 24 for utreexo node binaries was seen as a significant development, prompting Luke to suggest documenting this information as a Bitcoin Improvement Proposal (BIP) and assigning a normal service bit for it.Overall, Bit 24 is a cloud-based service that offers developers a range of tools for creating, deploying, and managing applications in the cloud. It provides features such as automatic scaling, load balancing, data storage, and security. The platform supports multiple programming languages and frameworks, giving developers the flexibility to choose the technology stack that best suits their needs.In addition to its features, Bit 24 also offers a user-friendly interface, detailed documentation, and support to assist developers in setting up and managing their applications. With its comprehensive set of capabilities, Bit 24 is recommended as a reliable and flexible cloud-based service for building and deploying applications quickly and efficiently. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2024/combined_51-Attack-via-Difficulty-Increase-with-a-Small-Quantum-Miner.xml b/static/bitcoin-dev/March_2024/combined_51-Attack-via-Difficulty-Increase-with-a-Small-Quantum-Miner.xml index 5a1aaabfda..2585543e37 100644 --- a/static/bitcoin-dev/March_2024/combined_51-Attack-via-Difficulty-Increase-with-a-Small-Quantum-Miner.xml +++ b/static/bitcoin-dev/March_2024/combined_51-Attack-via-Difficulty-Increase-with-a-Small-Quantum-Miner.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - 51% Attack via Difficulty Increase with a Small Quantum Miner - 2024-03-21T02:03:52.012652+00:00 - - Antoine Riard 2024-03-20 20:42:00+00:00 - - - Or Sattath 2024-03-18 13:19:00+00:00 - + 2025-09-26T14:42:05.301833+00:00 + python-feedgen + + + 51% Attack via Difficulty Increase with a Small Quantum Miner Or Sattath + 2024-03-18T13:19:00.000Z + + + Antoine Riard + 2024-03-20T20:42:00.000Z + + - python-feedgen + 2 Combined summary - 51% Attack via Difficulty Increase with a Small Quantum Miner - 2024-03-21T02:03:52.012694+00:00 + 2025-09-26T14:42:05.302260+00:00 + 2024-03-20T20:42:00+00:00 The collaborative research highlighted in a paper on [arXiv](https://arxiv.org/abs/2403.08023) brings to light the potential threat quantum computing poses to blockchain security through the lens of a 51% attack scenario. The paper, contributed by authors including Bolton Bailey, examines the feasibility of a quantum miner leveraging significantly less computational power than traditional miners to undermine a blockchain network. This theoretical attack relies on advanced, yet currently non-existent, quantum computers that are both fast and noise-tolerant. The essence of the attack involves using Grover's algorithm, known for its quadratic speedup in search problems, enabling a quantum miner to mine blocks at an artificially increased difficulty with much less effort compared to classical methods. - The proposed attack strategy not only suggests a new way to execute 51% attacks but also raises concerns about the security and integrity of blockchain networks in the face of quantum advancements. By increasing the mining difficulty and utilizing Grover's algorithm, a quantum miner could disproportionately influence the proof-of-work (PoW) consensus mechanism with fewer mined blocks. This would allow them to potentially dominate the network’s PoW, leading to severe consequences similar to those of traditional 51% attacks, including double spending and usurping all block rewards. - The research underscores the importance of preemptively addressing these quantum-enabled threats to ensure the future security of blockchain technologies. As quantum computing continues to evolve, the paper calls for blockchain protocols to consider and adapt to mitigate against such sophisticated attacks, emphasizing the need for ongoing vigilance and innovation within the field. - 2024-03-20T20:42:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2024/combined_A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml b/static/bitcoin-dev/March_2024/combined_A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml index ffa6c10675..8b39b97296 100644 --- a/static/bitcoin-dev/March_2024/combined_A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml +++ b/static/bitcoin-dev/March_2024/combined_A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml @@ -1,68 +1,99 @@ - + 2 Combined summary - A Free-Relay Attack Exploiting RBF Rule #6 - 2024-03-30T02:06:32.211673+00:00 - - Antoine Riard 2024-03-29 20:48:00+00:00 - - - Peter Todd 2024-03-28 19:47:00+00:00 - - - Antoine Riard 2024-03-28 19:13:00+00:00 - - - Peter Todd 2024-03-28 15:20:00+00:00 - - - Peter Todd 2024-03-28 14:27:00+00:00 - - - Steve Lee 2024-03-27 22:05:00+00:00 - - - Peter Todd 2024-03-27 20:30:00+00:00 - - - David A. Harding 2024-03-27 19:50:00+00:00 - - - Antoine Riard 2024-03-27 19:17:00+00:00 - - - Peter Todd 2024-03-27 18:04:00+00:00 - - - David A. Harding 2024-03-27 17:18:00+00:00 - - - Peter Todd 2024-03-27 13:04:00+00:00 - - - Peter Todd 2024-03-27 12:54:00+00:00 - - - Antoine Riard 2024-03-27 06:27:00+00:00 - - - David A. Harding 2024-03-26 18:36:00+00:00 - - - Nagaev Boris 2024-03-23 00:29:00+00:00 - - - Antoine Riard 2024-03-22 23:18:00+00:00 - - - Peter Todd 2024-03-19 13:46:00+00:00 - - - Nagaev Boris 2024-03-19 12:37:00+00:00 - - - Peter Todd 2024-03-18 13:21:00+00:00 - + 2025-09-26T14:42:03.188151+00:00 + python-feedgen + + + A Free-Relay Attack Exploiting RBF Rule #6 Peter Todd + 2024-03-18T13:21:00.000Z + + + Nagaev Boris + 2024-03-19T12:37:00.000Z + + + Peter Todd + 2024-03-19T13:46:00.000Z + + + Antoine Riard + 2024-03-22T23:18:00.000Z + + + Nagaev Boris + 2024-03-23T00:29:00.000Z + + + David A. Harding + 2024-03-26T18:36:00.000Z + + + Antoine Riard + 2024-03-27T06:27:00.000Z + + + Peter Todd + 2024-03-27T12:54:00.000Z + + + Peter Todd + 2024-03-27T13:04:00.000Z + + + David A. Harding + 2024-03-27T17:18:00.000Z + + + Peter Todd + 2024-03-27T18:04:00.000Z + + + Antoine Riard + 2024-03-27T19:17:00.000Z + + + David A. Harding + 2024-03-27T19:50:00.000Z + + + Peter Todd + 2024-03-27T20:30:00.000Z + + + Steve Lee + 2024-03-27T22:05:00.000Z + + + Peter Todd + 2024-03-28T14:27:00.000Z + + + Peter Todd + 2024-03-28T15:20:00.000Z + + + Antoine Riard + 2024-03-28T18:34:00.000Z + + + Antoine Riard + 2024-03-28T19:13:00.000Z + + + Peter Todd + 2024-03-28T19:16:00.000Z + + + Peter Todd + 2024-03-28T19:47:00.000Z + + + Antoine Riard + 2024-03-29T20:48:00.000Z + + @@ -83,33 +114,23 @@ - python-feedgen + 2 Combined summary - A Free-Relay Attack Exploiting RBF Rule #6 - 2024-03-30T02:06:32.211807+00:00 + 2025-09-26T14:42:03.190701+00:00 + 2024-03-29T20:48:00+00:00 The discussion initially focuses on the challenges of scaling Bitcoin payments, specifically for users with low-cost Android devices facing limitations in validation resources. It underscores the complexity of assessing potential attack costs on the system, stressing the need for a comprehensive threat model to compare various design alternatives. The importance of improving communication between security researchers and maintainers is highlighted, with suggestions for modifications to Bitcoin Core's `SECURITY.md` to ensure technical reports are acknowledged within approximately 72 hours. - Antoine Riard raises concerns about how software maintainers respond to security reports, advocating for the option to report vulnerabilities anonymously or under a pseudonym to protect professional reputation. He reflects on past instances where significant security issues were disclosed without a formal process, suggesting a standardized two-week period for vendors to engage in mitigation before public disclosure. - The conversation delves into bandwidth utilization in transaction relay networks and the economic aspects of securing incoming liquidity on the Lightning Network (LN). It discusses the limitations imposed by current protocol specifications, such as the inability to change the `dust_limit_satoshis` value for existing channels. Additionally, the potential consequences of large mempools on network operations are examined. - An innovative technique for managing transaction fees within the LN framework is explored, involving the implementation of feerate ascending LN states by adjusting `dust_limit_satoshis`. This approach aligns with BOLT2's specifications and represents ongoing efforts to optimize LN implementations. - Mempool management strategies are analyzed, focusing on objectives like increasing block template efficiency and ensuring adequate validation times for BIP152 compact blocks. The dialogue suggests that incorporating a proof-of-UTXO mechanism could strengthen the network against attacks, while also acknowledging the economic challenges in making such mechanisms unfeasible for attackers. - David A. Harding shares his experiences with the bitcoin-security mailing list, highlighting the need for better acknowledgment of reported security issues. His narrative emphasizes the complexities and emotional toll involved in the vulnerability disclosure process. - The correspondence touches on the necessity of balancing public vulnerability disclosure with responsible reporting to prevent exploitation. It advocates for open discourse as a strategy for dealing with vulnerabilities and emphasizes the delicate balance required to ensure network security. - Antoine Riard discusses modifying Bitcoin Core, stressing the importance of structured disclosure timelines and ethical standards in technology practices. He encourages active participation in vulnerability reporting and patch coordination. - Boris Nagaev critiques a proposed solution to replacement attacks, advocating for distributing all transactions to every node to avoid selective targeting during an attack. He highlights the practical challenges of this approach, such as the risk of DoS attacks through bandwidth overload or memory exhaustion. - The discussion extends to transaction identifier (txid) variations, considering strategies to either exacerbate or mitigate bandwidth challenges within Bitcoin’s network. Peter Todd offers further insights on this subject at his website, available [here](https://petertodd.org). - Finally, the Replace-By-Fee Rate (RBFR) rule discussion examines challenges blockchain nodes face in managing transactions within mempools. A proposal involves using dual priority queues in nodes for incoming and broadcasting transactions to reduce the spread of spam and maintain mempool efficiency. Public discussions and resources on these topics, including analyses of one-shot replace-by-fee-rate mechanisms and their success rates, are accessible online, highlighting ongoing efforts to improve the Bitcoin network’s transaction handling processes. Relevant links include [Original Full-RBF opt-in pull request](https://github.com/bitcoin/bitcoin/pull/6871), [One-shot replace-by-fee-rate - the status quo](https://petertodd.org/2024/one-shot-replace-by-fee-rate-the-status-quo), and [Replace-by-fee-rate success rate](https://petertodd.org/2024/replace-by-fee-rate-success-rate). - 2024-03-29T20:48:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2024/combined_Adding-New-BIP-Editors.xml b/static/bitcoin-dev/March_2024/combined_Adding-New-BIP-Editors.xml index 1a37caf149..aea1a25d4d 100644 --- a/static/bitcoin-dev/March_2024/combined_Adding-New-BIP-Editors.xml +++ b/static/bitcoin-dev/March_2024/combined_Adding-New-BIP-Editors.xml @@ -1,308 +1,411 @@ - + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.152793+00:00 - - Murch 2024-12-10 22:37:00+00:00 - - - Mark Erhardt 2024-09-19 18:48:00+00:00 - - - Antoine Riard 2024-09-19 07:47:00+00:00 - - - Mark Erhardt 2024-09-18 18:25:00+00:00 - - - Murch 2024-05-13 18:33:00+00:00 - - - Antoine Riard 2024-04-25 06:42:00+00:00 - - - Anthony Towns 2024-04-23 22:15:00+00:00 - - - Ali Sherief 2024-04-22 04:28:00+00:00 - - - Steve Lee 2024-04-22 02:44:00+00:00 - - - Ava Chow 2024-04-22 00:06:00+00:00 - - - Matt Corallo 2024-04-21 23:01:00+00:00 - - - Antoine Riard 2024-04-21 20:48:00+00:00 - - - Michael Folkson 2024-04-21 19:18:00+00:00 - - - Ava Chow 2024-04-21 18:47:00+00:00 - - - Michael Folkson 2024-04-21 17:57:00+00:00 - - - Ava Chow 2024-04-21 16:39:00+00:00 - - - Michael Folkson 2024-04-21 11:43:00+00:00 - - - Ava Chow 2024-04-20 23:05:00+00:00 - - - Ava Chow 2024-04-20 22:47:00+00:00 - - - Michael Folkson 2024-04-20 22:21:00+00:00 - - - Steve Lee 2024-04-20 22:03:00+00:00 - - - Ava Chow 2024-04-20 21:37:00+00:00 - - - Steve Lee 2024-04-20 21:11:00+00:00 - - - Ava Chow 2024-04-20 21:08:00+00:00 - - - Ava Chow 2024-04-20 20:59:00+00:00 - - - Steve Lee 2024-04-20 20:46:00+00:00 - - - Michael Folkson 2024-04-20 19:59:00+00:00 - - - Ava Chow 2024-04-20 19:48:00+00:00 - - - Ava Chow 2024-04-20 19:14:00+00:00 - - - Olaoluwa Osuntokun 2024-04-19 22:32:00+00:00 - - - nsvrn 2024-04-17 23:58:00+00:00 - - - Ava Chow 2024-04-16 17:08:00+00:00 - - - NVK 2024-04-16 13:32:00+00:00 - - - Tim Ruffing 2024-04-16 12:34:00+00:00 - - - Matt Corallo 2024-04-15 17:50:00+00:00 - - - Sergi Delgado Segura 2024-04-11 14:22:00+00:00 - - - Ali Sherief 2024-04-07 10:11:00+00:00 - - - Larry Ruane 2024-04-05 19:18:00+00:00 - - - xBC 2024-04-04 12:58:00+00:00 - - - Niklas Goegge 2024-04-04 09:09:00+00:00 - - - Anthony Towns 2024-04-04 05:00:00+00:00 - - - Pieter Wuille 2024-04-03 19:44:00+00:00 - - - Fabian 2024-04-03 18:34:00+00:00 - - - Vasil Dimov 2024-04-03 17:24:00+00:00 - - - Juan Galt 2024-04-03 16:58:00+00:00 - - - Murch 2024-04-03 15:03:00+00:00 - - - Luke Dashjr 2024-04-02 15:39:00+00:00 - - - Gloria Zhao 2024-04-02 15:13:00+00:00 - - - Luke Dashjr 2024-04-02 14:28:00+00:00 - - - nvk 2024-04-02 14:24:00+00:00 - - - /dev /fd 2024-04-02 13:49:00+00:00 - - - Tim Ruffing 2024-04-02 13:17:00+00:00 - - - Michael Folkson 2024-04-02 08:18:00+00:00 - - - Ava Chow 2024-04-02 00:37:00+00:00 - - - /dev /fd 2024-04-01 23:55:00+00:00 - - - David A. Harding 2024-04-01 21:13:00+00:00 - - - Antoine Riard 2024-04-01 20:14:00+00:00 - - - Jonas Nick 2024-04-01 18:42:00+00:00 - - - Murch 2024-04-01 18:41:00+00:00 - - - Michael Folkson 2024-04-01 11:58:00+00:00 - - - /dev /fd 2024-04-01 06:21:00+00:00 - - - Ava Chow 2024-03-31 17:01:00+00:00 - - - Michael Folkson 2024-03-31 16:01:00+00:00 - - - Antoine Riard 2024-03-30 20:01:00+00:00 - - - Michael Folkson 2024-03-30 11:51:00+00:00 - - - Peter Todd 2024-03-30 04:04:00+00:00 - - - Keagan McClelland 2024-03-29 22:17:00+00:00 - - - Antoine Riard 2024-03-29 21:08:00+00:00 - - - /dev /fd 2024-03-29 05:24:00+00:00 - - - Michael Folkson 2024-03-29 02:34:00+00:00 - - - Matt Corallo 2024-03-28 21:19:00+00:00 - - - John C. Vernaleo 2024-03-28 20:59:00+00:00 - - - Matt Corallo 2024-03-28 20:31:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Antoine Riard 2024-03-28 19:42:00+00:00 - - - /dev /fd 2024-03-28 16:09:00+00:00 - - - Brandon Black 2024-03-28 15:50:00+00:00 - - - Murch 2024-03-28 13:02:00+00:00 - - - Matt Corallo 2024-03-27 23:54:00+00:00 - - - John C. Vernaleo 2024-03-27 23:39:00+00:00 - - - Murch 2024-03-27 23:36:00+00:00 - - - Murch 2024-03-27 21:25:00+00:00 - - - Chris Stewart 2024-03-14 11:56:00+00:00 - - - Jon A 2024-03-11 16:48:00+00:00 - - - Bitcoin Error Log 2024-03-10 17:27:00+00:00 - - - Michael Folkson 2024-03-09 10:46:00+00:00 - - - Keagan McClelland 2024-03-07 22:39:00+00:00 - - - Antoine Riard 2024-03-07 20:56:00+00:00 - - - Tim Ruffing 2024-02-28 16:31:00+00:00 - - - bitcoindevml.void 2024-02-28 11:12:00+00:00 - - - /dev /fd 2024-02-28 04:22:00+00:00 - - - Ava Chow 2024-02-27 23:26:00+00:00 - - - /dev /fd 2024-02-27 23:10:00+00:00 - - - Luke Dashjr 2024-02-27 22:57:00+00:00 - - - Luke Dashjr 2024-02-27 22:40:00+00:00 - - - Greg Tonoski 2024-02-27 21:48:00+00:00 - - - Léo Haf 2024-02-27 21:33:00+00:00 - - - Ava Chow 2024-02-27 20:11:00+00:00 - - - Ava Chow 2024-02-27 18:53:00+00:00 - + 2025-09-26T14:42:07.573651+00:00 + python-feedgen + + + Adding New BIP Editors 'Ava Chow' + 2024-02-27T18:53:00.000Z + + + Léo Haf' + 2024-02-27T20:11:00.000Z + + + Antoine Poinsot' + 2024-02-27T21:33:00.000Z + + + Greg Tonoski + 2024-02-27T21:48:00.000Z + + + Luke Dashjr + 2024-02-27T22:40:00.000Z + + + Ava Chow' + 2024-02-27T22:57:00.000Z + + + /dev /fd0 + 2024-02-27T23:10:00.000Z + + + Steve Lee + 2024-02-27T23:26:00.000Z + + + /dev /fd0 + 2024-02-28T04:22:00.000Z + + + bitcoin-dev-ml.void867 + 2024-02-28T11:12:00.000Z + + + Tim Ruffing + 2024-02-28T16:31:00.000Z + + + Antoine Riard + 2024-03-07T20:56:00.000Z + + + Keagan McClelland + 2024-03-07T22:39:00.000Z + + + Michael Folkson + 2024-03-09T10:46:00.000Z + + + Bitcoin Error Log + 2024-03-10T17:27:00.000Z + + + Jon A + 2024-03-11T16:48:00.000Z + + + Chris Stewart + 2024-03-14T11:56:00.000Z + + + Murch + 2024-03-27T21:25:00.000Z + + + Keagan McClelland + 2024-03-27T23:36:00.000Z + + + John C. Vernaleo + 2024-03-27T23:39:00.000Z + + + Matt Corallo + 2024-03-27T23:54:00.000Z + + + Murch + 2024-03-28T13:02:00.000Z + + + Brandon Black + 2024-03-28T15:50:00.000Z + + + /dev /fd0 + 2024-03-28T16:09:00.000Z + + + Antoine Riard + 2024-03-28T19:42:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Antoine Riard + 2024-03-28T20:31:00.000Z + + + John C. Vernaleo + 2024-03-28T20:59:00.000Z + + + Matt Corallo + 2024-03-28T21:19:00.000Z + + + Michael Folkson + 2024-03-29T02:34:00.000Z + + + /dev /fd0 + 2024-03-29T05:24:00.000Z + + + Antoine Riard + 2024-03-29T21:08:00.000Z + + + Keagan McClelland + 2024-03-29T22:17:00.000Z + + + Peter Todd + 2024-03-30T04:04:00.000Z + + + Michael Folkson + 2024-03-30T11:51:00.000Z + + + Antoine Riard + 2024-03-30T20:01:00.000Z + + + Michael Folkson + 2024-03-31T16:01:00.000Z + + + Ava Chow' + 2024-03-31T17:01:00.000Z + + + /dev /fd0 + 2024-04-01T06:21:00.000Z + + + Michael Folkson + 2024-04-01T11:58:00.000Z + + + Re: Adding New BIP Editors Murch + 2024-04-01T18:41:00.000Z + + + Jonas Nick + 2024-04-01T18:42:00.000Z + + + Antoine Riard + 2024-04-01T20:14:00.000Z + + + David A. Harding + 2024-04-01T21:13:00.000Z + + + /dev /fd0 + 2024-04-01T23:55:00.000Z + + + Ava Chow' + 2024-04-02T00:37:00.000Z + + + Michael Folkson + 2024-04-02T08:18:00.000Z + + + Time for an update to BIP2? Tim Ruffing + 2024-04-02T13:17:00.000Z + + + /dev /fd0 + 2024-04-02T13:49:00.000Z + + + nvk + 2024-04-02T14:24:00.000Z + + + Luke Dashjr + 2024-04-02T14:28:00.000Z + + + Gloria Zhao + 2024-04-02T15:13:00.000Z + + + Luke Dashjr + 2024-04-02T15:39:00.000Z + + + Murch + 2024-04-03T15:03:00.000Z + + + Juan Galt + 2024-04-03T16:58:00.000Z + + + Vasil Dimov + 2024-04-03T17:24:00.000Z + + + Fabian' + 2024-04-03T18:34:00.000Z + + + Pieter Wuille + 2024-04-03T19:44:00.000Z + + + Anthony Towns + 2024-04-04T05:00:00.000Z + + + Niklas Goegge + 2024-04-04T09:09:00.000Z + + + Adding New BIP Editors 0xB10C + 2024-04-04T12:58:00.000Z + + + Larry Ruane + 2024-04-05T19:18:00.000Z + + + Ali Sherief + 2024-04-07T10:11:00.000Z + + + Sergi Delgado Segura + 2024-04-11T14:22:00.000Z + + + Matt Corallo + 2024-04-15T17:50:00.000Z + + + Tim Ruffing + 2024-04-16T12:34:00.000Z + + + NVK + 2024-04-16T13:32:00.000Z + + + Ava Chow' + 2024-04-16T17:08:00.000Z + + + nsvrn' + 2024-04-17T23:58:00.000Z + + + Olaoluwa Osuntokun + 2024-04-19T22:32:00.000Z + + + Ava Chow' + 2024-04-20T19:14:00.000Z + + + NVK + 2024-04-20T19:48:00.000Z + + + Michael Folkson + 2024-04-20T19:59:00.000Z + + + Steve Lee + 2024-04-20T20:46:00.000Z + + + Ava Chow' + 2024-04-20T20:59:00.000Z + + + Ava Chow' + 2024-04-20T21:08:00.000Z + + + Steve Lee + 2024-04-20T21:11:00.000Z + + + Ava Chow' + 2024-04-20T21:37:00.000Z + + + Steve Lee + 2024-04-20T22:03:00.000Z + + + Michael Folkson + 2024-04-20T22:21:00.000Z + + + Ava Chow' + 2024-04-20T22:47:00.000Z + + + Ava Chow' + 2024-04-20T23:05:00.000Z + + + Michael Folkson + 2024-04-21T11:43:00.000Z + + + Ava Chow' + 2024-04-21T16:39:00.000Z + + + Michael Folkson + 2024-04-21T17:57:00.000Z + + + Ava Chow' + 2024-04-21T18:47:00.000Z + + + Michael Folkson + 2024-04-21T19:18:00.000Z + + + Antoine Riard + 2024-04-21T20:48:00.000Z + + + Matt Corallo + 2024-04-21T23:01:00.000Z + + + Ava Chow' + 2024-04-22T00:06:00.000Z + + + Steve Lee + 2024-04-22T02:44:00.000Z + + + Ali Sherief + 2024-04-22T04:28:00.000Z + + + Anthony Towns + 2024-04-23T22:15:00.000Z + + + Antoine Riard + 2024-04-25T06:42:00.000Z + + + Time for an update to BIP2? Murch + 2024-05-13T18:33:00.000Z + + + Murch + 2024-09-18T18:25:00.000Z + + + Antoine Riard + 2024-09-19T07:47:00.000Z + + + Murch + 2024-09-19T18:48:00.000Z + + + Murch + 2024-12-10T22:37:00.000Z + + @@ -403,21 +506,17 @@ - python-feedgen + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.153617+00:00 + 2025-09-26T14:42:07.583728+00:00 + 2024-12-10T22:37:00+00:00 In the realm of Bitcoin development, discussions pertaining to the enhancement of the Bitcoin Improvement Proposal (BIP) process have been prominent. A key focus has been on addressing the current bottleneck in managing BIPs, emphasized by Luke Dashjr's acknowledgment of his limited capacity to actively maintain the BIPs repository. This acknowledgment underscores the critical need for additional BIP editors to ensure an efficient and effective review and integration process for new proposals and amendments to existing ones. - The role of a BIP editor is significant, encompassing responsibilities such as assigning BIP numbers, merging pull requests for new proposals, making fixes to existing BIPs, and more, as outlined in BIP 2. The addition of new editors is envisaged as a pivotal measure to alleviate the backlog of submissions and augment the process's overall productivity. For the continuity and coherence of the BIP numbering system, it is imperative that any incoming editors concur on the established numbering scheme. - The selection criteria for new BIP editors highlight the necessity for candidates with a comprehensive background in Bitcoin development, showcasing a history of active participation and contributions. These individuals must possess the ability to impartially assess proposals, a quality that underscores the importance of objectivity in the role. - Within this context, Kanzure and RubenSomsen have been identified as exemplary candidates for the position of BIP editors. Their extensive involvement in Bitcoin development positions them as valuable additions to the editorial team. Their potential inclusion is anticipated to significantly ameliorate the management and advancement of the BIPs repository, offering substantial benefits to the Bitcoin development community. - This dialogue illustrates the collective effort within the Bitcoin developer ecosystem to refine the governance mechanisms surrounding BIPs. It emphasizes the commitment to ensuring that the process remains robust, transparent, and inclusive, facilitating the continuous evolution and improvement of Bitcoin. - 2024-12-10T22:37:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2024/combined_Anyone-can-boost-a-more-efficient-alternative-to-anchor-outputs.xml b/static/bitcoin-dev/March_2024/combined_Anyone-can-boost-a-more-efficient-alternative-to-anchor-outputs.xml index ffe8557e5b..e847e74009 100644 --- a/static/bitcoin-dev/March_2024/combined_Anyone-can-boost-a-more-efficient-alternative-to-anchor-outputs.xml +++ b/static/bitcoin-dev/March_2024/combined_Anyone-can-boost-a-more-efficient-alternative-to-anchor-outputs.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - Anyone can boost - a more efficient alternative to anchor outputs - 2024-03-28T02:09:11.698377+00:00 - - Peter Todd 2024-03-27 12:20:00+00:00 - - - David A. Harding 2024-03-25 01:36:00+00:00 - - - Peter Todd 2024-03-19 14:24:00+00:00 - - - Fabian 2024-03-19 14:10:00+00:00 - - - Martin Habovštiak 2024-03-19 09:47:00+00:00 - + 2025-09-26T14:42:01.039659+00:00 + python-feedgen + + + Anyone can boost - a more efficient alternative to anchor outputs Martin Habovštiak + 2024-03-19T09:47:00.000Z + + + Fabian' + 2024-03-19T14:10:00.000Z + + + Peter Todd + 2024-03-19T14:24:00.000Z + + + David A. Harding + 2024-03-25T01:36:00.000Z + + + Peter Todd + 2024-03-27T12:20:00.000Z + + - python-feedgen + 2 Combined summary - Anyone can boost - a more efficient alternative to anchor outputs - 2024-03-28T02:09:11.698433+00:00 + 2025-09-26T14:42:01.040510+00:00 + 2024-03-27T12:20:00+00:00 Peter Todd highlights the vulnerabilities in transaction sponsorship services, focusing on the potential for services to exploit users by replacing their transactions without proper sponsorship once payment is concluded. This practice risks the reliability of such services, as users may not receive the support they expect for their transactions. Furthermore, Todd discusses a scenario where a service might sell the same transaction space to multiple customers, leading to conflicts and one party not receiving the promised transaction support. To address these issues and improve transaction sponsor block space efficiency, Todd references a thread at [https://delvingbitcoin.org/t/improving-transaction-sponsor-blockspace-efficiency/696](https://delvingbitcoin.org/t/improving-transaction-sponsor-blockspace-efficiency/696) which could provide insights into optimizing sponsored transactions while mitigating trust issues. - In another discussion from the Bitcoin Development Mailing List, the concept of Transaction Sponsorship, initially proposed by Jeremy Rubin, is revisited. This concept involves replace-by-fee-rate (RBFR) with a set minimum fee-rate ratio to counteract significant transaction pinning attacks. Despite concerns about denial-of-service (DoS) attacks, RBFR's implementation on Libre Relay nodes within the mainnet showcases its resilience against such threats. The mechanism promises new smart contracting capabilities beyond its initial purposes, demonstrated through Ark's use case that refines their connector output scheme. However, the effectiveness of this mechanism in broader applications remains debated, especially concerning third-party interventions in transaction mining and its impact on systems like OpenTimestamps. - Fabian draws a comparison between Martin's recent proposal and Jeremy Rubin's 2020 concept of transaction sponsoring, noting similarities but also potential structural differences. He stresses the importance of Martin delineating his idea's unique aspects to clarify how it improves upon or diverges from existing proposals. This could enhance understanding and foster further innovation within the community. Fabian emphasizes the value of building on prior knowledge and discussions, referring to an extensive mailing list thread from 2022 as a crucial resource for anyone exploring transaction sponsoring concepts. - -Peter Todd introduces an alternative method to enhance Bitcoin protocols, addressing the limitations seen in anchor outputs and Child Pays for Parent (CPFP) methods with "anyone can boost." This approach allows for efficient fee boosting by including a transaction ID in a new transaction's annex, with the condition that both transactions must be confirmed in the same block to avoid network spam and DoS attacks. This proposal promises a more cost-effective and simplified user experience for boosting transactions, albeit requiring a soft fork for implementation. It considers the potential impacts on fee betting practices and the necessity for entities engaged in presigned transactions to prepare for the new boosting method. Todd's proposal represents a significant step forward in addressing inefficiencies in Bitcoin transaction processing, emphasizing the need for ongoing dialogue and development within the ecosystem. - 2024-03-27T12:20:00+00:00 +Peter Todd introduces an alternative method to enhance Bitcoin protocols, addressing the limitations seen in anchor outputs and Child Pays for Parent (CPFP) methods with "anyone can boost." This approach allows for efficient fee boosting by including a transaction ID in a new transaction's annex, with the condition that both transactions must be confirmed in the same block to avoid network spam and DoS attacks. This proposal promises a more cost-effective and simplified user experience for boosting transactions, albeit requiring a soft fork for implementation. It considers the potential impacts on fee betting practices and the necessity for entities engaged in presigned transactions to prepare for the new boosting method. Todd's proposal represents a significant step forward in addressing inefficiencies in Bitcoin transaction processing, emphasizing the need for ongoing dialogue and development within the ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2024/combined_Great-Consensus-Cleanup-Revival.xml b/static/bitcoin-dev/March_2024/combined_Great-Consensus-Cleanup-Revival.xml index 4509c7cd94..73d48b8749 100644 --- a/static/bitcoin-dev/March_2024/combined_Great-Consensus-Cleanup-Revival.xml +++ b/static/bitcoin-dev/March_2024/combined_Great-Consensus-Cleanup-Revival.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.043876+00:00 - - Antoine Riard 2024-11-28 05:18:00+00:00 - - - Murad Ali 2024-07-20 21:39:00+00:00 - - - Eric Voskuil 2024-07-20 20:29:00+00:00 - - - Antoine Riard 2024-07-18 17:39:00+00:00 - - - Eric Voskuil 2024-07-04 14:45:00+00:00 - - - Antoine Riard 2024-07-04 13:20:00+00:00 - - - Eric Voskuil 2024-07-03 23:29:00+00:00 - - - Eric Voskuil 2024-07-03 01:13:00+00:00 - - - Larry Ruane 2024-07-03 01:07:00+00:00 - - - Eric Voskuil 2024-07-02 15:57:00+00:00 - - - Antoine Poinsot 2024-07-02 10:23:00+00:00 - - - Antoine Riard 2024-07-02 02:36:00+00:00 - - - Eric Voskuil 2024-06-29 20:40:00+00:00 - - - Eric Voskuil 2024-06-29 20:29:00+00:00 - - - Antoine Riard 2024-06-29 01:53:00+00:00 - - - Eric Voskuil 2024-06-29 01:31:00+00:00 - - - Antoine Riard 2024-06-29 01:06:00+00:00 - - - Eric Voskuil 2024-06-28 17:14:00+00:00 - - - Antoine Poinsot 2024-06-27 09:35:00+00:00 - - - Eric Voskuil 2024-06-24 00:35:00+00:00 - - - Antoine Poinsot 2024-06-21 13:09:00+00:00 - - - Eric Voskuil 2024-06-18 13:02:00+00:00 - - - Antoine Poinsot 2024-06-18 08:13:00+00:00 - - - Eric Voskuil 2024-06-17 22:15:00+00:00 - - - Antoine Riard 2024-05-06 01:10:00+00:00 - - - Mark F 2024-04-30 22:20:00+00:00 - - - Antoine Riard 2024-04-25 06:08:00+00:00 - - - Antoine Poinsot 2024-04-18 10:04:00+00:00 - - - Mark F 2024-04-18 00:46:00+00:00 - - - Antoine Riard 2024-03-27 18:57:00+00:00 - - - Antoine Poinsot 2024-03-27 10:35:00+00:00 - - - Antoine Riard 2024-03-26 19:11:00+00:00 - - - Antoine Poinsot 2024-03-24 18:10:00+00:00 - + 2025-09-26T14:41:58.921767+00:00 + python-feedgen + + + Great Consensus Cleanup Revival 'Antoine Poinsot' + 2024-03-24T18:10:00.000Z + + + Antoine Riard + 2024-03-26T19:11:00.000Z + + + Antoine Poinsot' + 2024-03-27T10:35:00.000Z + + + Antoine Riard + 2024-03-27T18:57:00.000Z + + + Mark F + 2024-04-18T00:46:00.000Z + + + Antoine Poinsot' + 2024-04-18T10:04:00.000Z + + + Antoine Riard + 2024-04-25T06:08:00.000Z + + + Mark F + 2024-04-30T22:20:00.000Z + + + Antoine Riard + 2024-05-06T01:10:00.000Z + + + Eric Voskuil + 2024-06-17T22:15:00.000Z + + + Antoine Poinsot' + 2024-06-18T08:13:00.000Z + + + Eric Voskuil + 2024-06-18T13:02:00.000Z + + + Antoine Poinsot' + 2024-06-21T13:09:00.000Z + + + Eric Voskuil + 2024-06-24T00:35:00.000Z + + + Antoine Poinsot' + 2024-06-27T09:35:00.000Z + + + Eric Voskuil + 2024-06-28T17:14:00.000Z + + + Antoine Riard + 2024-06-29T01:06:00.000Z + + + Eric Voskuil + 2024-06-29T01:31:00.000Z + + + Antoine Riard + 2024-06-29T01:53:00.000Z + + + Eric Voskuil + 2024-06-29T20:29:00.000Z + + + Eric Voskuil + 2024-06-29T20:40:00.000Z + + + Antoine Riard + 2024-07-02T02:36:00.000Z + + + Antoine Poinsot' + 2024-07-02T10:23:00.000Z + + + Eric Voskuil + 2024-07-02T15:57:00.000Z + + + Larry Ruane + 2024-07-03T01:07:00.000Z + + + Eric Voskuil + 2024-07-03T01:13:00.000Z + + + Eric Voskuil + 2024-07-03T23:29:00.000Z + + + Antoine Riard + 2024-07-04T13:20:00.000Z + + + Eric Voskuil + 2024-07-04T14:45:00.000Z + + + Antoine Riard + 2024-07-18T17:39:00.000Z + + + Eric Voskuil + 2024-07-20T20:29:00.000Z + + + Murad Ali + 2024-07-20T21:39:00.000Z + + + Antoine Riard + 2024-11-28T05:18:00.000Z + + @@ -135,19 +171,16 @@ - python-feedgen + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.044085+00:00 + 2025-09-26T14:41:58.925478+00:00 + 2024-11-28T05:18:00+00:00 The conversation initiated by Antoine Poinsot sheds light on various aspects of the Bitcoin network's consensus mechanism, probing into areas that could benefit from improvement and adjustment. Poinsot zeroes in on concerns like the prolonged block validation times, which pose a threat to the network's overall efficacy and security framework. In response to this, he acknowledges existing solutions but proposes a supplementary strategy that caps the size of legacy transactions, aiming to bolster safety measures and ensure quicker validation processes. - Another significant point of discussion is the timewarp bug, which Poinsot indicates has not received the level of concern it rightfully demands. He emphasizes the critical need for addressing this flaw to safeguard the network’s stability. Moreover, the debate ventures into ensuring coinbase transaction uniqueness as a measure to circumvent the requirement for BIP30 validations beyond a specific block height, suggesting a potential pathway to streamline transaction verification while enhancing the network's security posture. - A nuanced proposal is introduced regarding the handling of transactions based on their sizes. Poinsot suggests maintaining the validity of transactions under 64 bytes while advocating for the invalidation of those exactly at this size threshold. This approach hints at a precise methodology aimed at refining transaction processing without imposing broad restrictions on transaction sizes. - The dialogue further extends an invitation to the community for additional insights, challenging others to identify possible disagreements, overlooked facets, or enhancements to the presented proposals. This initiative underscores a commitment to collaborative progress, aiming to cultivate a constructive forum for discussion that could lead to substantial improvements within the Bitcoin consensus mechanism. Through this exchange, Poinsot not only highlights key areas of concern but also catalyzes a broader dialogue aimed at fortifying the network against potential vulnerabilities and inefficiencies. - 2024-11-28T05:18:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2024/combined_OP-Expire-mempool-behavior.xml b/static/bitcoin-dev/March_2024/combined_OP-Expire-mempool-behavior.xml index d7571f2974..7dc4c84399 100644 --- a/static/bitcoin-dev/March_2024/combined_OP-Expire-mempool-behavior.xml +++ b/static/bitcoin-dev/March_2024/combined_OP-Expire-mempool-behavior.xml @@ -1,37 +1,41 @@ - + 2 Combined summary - OP_Expire mempool behavior - 2024-07-12T11:50:49.756256+00:00 - - Antoine Riard 2024-06-20 23:09:00+00:00 - - - Peter Todd 2024-03-19 15:04:00+00:00 - - - Antoine Riard 2024-03-16 18:21:00+00:00 - - - Peter Todd 2024-03-13 03:32:00+00:00 - + 2025-09-26T14:41:56.735400+00:00 + python-feedgen + + + OP_Expire mempool behavior Peter Todd + 2024-03-13T03:32:00.000Z + + + Antoine Riard + 2024-03-16T18:21:00.000Z + + + Peter Todd + 2024-03-19T15:04:00.000Z + + + Antoine Riard + 2024-06-20T23:09:00.000Z + + - python-feedgen + 2 Combined summary - OP_Expire mempool behavior - 2024-07-12T11:50:49.756256+00:00 + 2025-09-26T14:41:56.735984+00:00 + 2024-06-20T23:09:00+00:00 Antoine Riard delves into the technical intricacies of Bitcoin Improvement Proposals (BIP) and their implications on transaction replacement and denial-of-service (DoS) attacks. A key focus is on the replace-by-fee-rate (RBFR) strategy under BIP125 rules, where HTLC-timeout transactions can supersede HTLC-preimage transactions in a mempool if they offer a higher fee. This mechanism ensures network integrity by guaranteeing that transactions are confirmed, thus preventing potential bandwidth waste. Riard also discusses the OP_Expire functionality, which deems transactions invalid after a certain period. He emphasizes the vulnerability this creates, allowing attackers to consume network resources with minimal cost. However, he reassures that existing rules around transaction fees are designed to mitigate such attacks effectively. - The conversation extends to the Lightning Network (LN), highlighting concerns about the efficient broadcast of second-stage transactions like HTLC-preimage and HTLC-timeout close to their expiry. The introduction of altruistic rebroadcasting is discussed as a measure to prioritize transactions with higher mining probabilities, though its effectiveness against sophisticated DoS strategies remains debatable. Additionally, Riard notes an observed uniformity in minimum fees across different nodes, suggesting a level of predictability in network fee structures despite variations in mempool sizes. - A critical issue raised pertains to version 3 (V3) transactions and the loophole that allows attackers to exploit the system through replacement cycling attacks without adequately compensating for the bandwidth used. This flaw undermines the principle that users must pay for the network resources they consume. Furthermore, the discussion points out the practical challenges LN nodes face in mitigating these attacks due to their limited tx-relay network interface designs. - -Further insights are offered from discussions on the [delvingbitcoin forum](https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8), where the topic of OP_Expire's potential as a "bandwidth-wasting vector" is explored. It is argued that while OP_Expire introduces a new layer to transaction handling, it does not significantly alter the economic incentives or costs associated with transaction replacement compared to the established Replace-By-Fee (RBF) practices. This perspective underscores the ongoing need for scrutiny and adaptation of cryptographic protocols to address emerging challenges in the cryptocurrency domain. - 2024-06-20T23:09:00+00:00 +Further insights are offered from discussions on the [delvingbitcoin forum](https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8), where the topic of OP_Expire's potential as a "bandwidth-wasting vector" is explored. It is argued that while OP_Expire introduces a new layer to transaction handling, it does not significantly alter the economic incentives or costs associated with transaction replacement compared to the established Replace-By-Fee (RBF) practices. This perspective underscores the ongoing need for scrutiny and adaptation of cryptographic protocols to address emerging challenges in the cryptocurrency domain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2024/combined_Re-A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml b/static/bitcoin-dev/March_2024/combined_Re-A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml index 35cedb5366..612f2800aa 100644 --- a/static/bitcoin-dev/March_2024/combined_Re-A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml +++ b/static/bitcoin-dev/March_2024/combined_Re-A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Re: A Free-Relay Attack Exploiting RBF Rule #6 - 2024-03-30T02:07:03.202252+00:00 + 2025-09-26T14:41:54.624579+00:00 + python-feedgen Peter Todd 2024-03-28 19:16:00+00:00 @@ -11,21 +12,17 @@ - python-feedgen + 2 Combined summary - Re: A Free-Relay Attack Exploiting RBF Rule #6 - 2024-03-30T02:07:03.202291+00:00 + 2025-09-26T14:41:54.624710+00:00 + 2024-03-28T19:16:00+00:00 The discussion initiated by Peter Todd concerns CVE-2017-12842 and the broader issues surrounding vulnerability disclosure and patching within the Bitcoin Core community. Todd highlights a critical perspective on the severity of CVE-2017-12842, questioning its practical significance compared to the effort and resources required for exploitation. He raises concerns about certain design choices in projects like Sergio's RSK Bridge contract that could be prone to this vulnerability, implying a deeper issue with how security is approached in some blockchain projects. - The process of disclosing vulnerabilities is a focal point of Todd's message. Despite informing key individuals directly involved with Bitcoin Core, there was a notable lack of action or engagement from these parties. This experience underscores a broader frustration with the traditional vulnerability disclosure process, especially when it involves significant findings related to high-profile projects. Todd suggests that the lack of response and the dismissal of his findings reflect a challenging dynamic within the community, one where political and social factors may influence the handling of technical vulnerabilities. - Furthermore, Todd's recounting touches upon the complex professional relationships and reputations within the Bitcoin Core community, particularly among those working on mempool code. This context sheds light on the potential motivations behind the observed inaction and dismissiveness towards reported vulnerabilities. It appears that navigating these relationships and the associated political landscape is a considerable challenge for those attempting to contribute to the project's security. - Antoine LDK's contribution to the discussion provides additional insights into the nuances of vulnerability disclosure. He contrasts the handling of CVE-2017-12842 with another vulnerability, CVE-2021-31876, highlighting differences in disclosure timelines and approaches to patching. The comparison reveals a preference for more extended disclosure delays to ensure comprehensive feedback and patch development, suggesting a more cautious approach may benefit the community. However, Antoine also acknowledges instances where the response to security findings falls short of ethical information security standards, indicating a recurring challenge in achieving timely and effective vulnerability management. - Overall, the dialogue between Todd and Antoine LDK illustrates the complexities of vulnerability disclosure in the context of Bitcoin Core and similar high-stakes software projects. The experiences shared by both individuals point to systemic issues in how vulnerabilities are addressed, suggesting a need for greater transparency, responsiveness, and collaboration within the community. For further information and updates from Peter Todd, he can be reached through [Peter Todd's Website](https://petertodd.org). - 2024-03-28T19:16:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2024/combined_The-Future-of-Bitcoin-Testnet.xml b/static/bitcoin-dev/March_2024/combined_The-Future-of-Bitcoin-Testnet.xml index 45054a7a94..28ff7fcadc 100644 --- a/static/bitcoin-dev/March_2024/combined_The-Future-of-Bitcoin-Testnet.xml +++ b/static/bitcoin-dev/March_2024/combined_The-Future-of-Bitcoin-Testnet.xml @@ -1,134 +1,179 @@ - + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303256+00:00 - - Saint Wenhao 2025-04-25 17:19:00+00:00 - - - Garlo Nicon 2025-03-31 10:48:00+00:00 - - - Peter Todd 2024-05-04 17:13:00+00:00 - - - Peter Todd 2024-05-04 17:08:00+00:00 - - - Ali Sherief 2024-05-02 07:10:00+00:00 - - - Garlo Nicon 2024-05-01 15:30:00+00:00 - - - Matthew Bagazinski 2024-04-30 18:46:00+00:00 - - - Matt Corallo 2024-04-28 13:45:00+00:00 - - - Ali Sherief 2024-04-22 04:33:00+00:00 - - - Sjors Provoost 2024-04-16 17:30:00+00:00 - - - Garlo Nicon 2024-04-10 06:57:00+00:00 - - - Garlo Nicon 2024-04-09 18:28:00+00:00 - - - Peter Todd 2024-04-09 16:48:00+00:00 - - - coinableS 2024-04-09 04:29:00+00:00 - - - Garlo Nicon 2024-04-08 19:11:00+00:00 - - - K Calvin 2024-04-07 08:09:00+00:00 - - - Christian Decker 2024-04-07 07:20:00+00:00 - - - David A. Harding 2024-04-06 23:04:00+00:00 - - - Calvin Kim 2024-04-05 04:30:00+00:00 - - - Jameson Lopp 2024-04-04 12:47:00+00:00 - - - Calvin Kim 2024-04-04 08:14:00+00:00 - - - Andrew Poelstra 2024-04-03 19:35:00+00:00 - - - emsit 2024-04-03 18:18:00+00:00 - - - Anthony Towns 2024-04-03 04:19:00+00:00 - - - Jameson Lopp 2024-04-02 19:46:00+00:00 - - - Lukáš Kráľ 2024-04-02 18:36:00+00:00 - - - Jameson Lopp 2024-04-02 11:53:00+00:00 - - - Fabian 2024-04-01 22:01:00+00:00 - - - emsit 2024-04-01 19:22:00+00:00 - - - Warren Togami 2024-04-01 14:28:00+00:00 - - - Andrew Poelstra 2024-04-01 14:20:00+00:00 - - - Pieter Wuille 2024-04-01 13:37:00+00:00 - - - Fabian 2024-04-01 13:32:00+00:00 - - - Peter Todd 2024-04-01 13:25:00+00:00 - - - Jameson Lopp 2024-04-01 12:54:00+00:00 - - - Peter Todd 2024-03-31 21:29:00+00:00 - - - Nagaev Boris 2024-03-31 21:01:00+00:00 - - - Eric Voskuil 2024-03-31 17:21:00+00:00 - - - Peter Todd 2024-03-31 16:02:00+00:00 - - - Jameson Lopp 2024-03-31 14:57:00+00:00 - - - Luke Dashjr 2024-03-31 14:33:00+00:00 - - - Jameson Lopp 2024-03-31 13:19:00+00:00 - + 2025-09-26T14:42:09.773413+00:00 + python-feedgen + + + The Future of Bitcoin Testnet Jameson Lopp + 2024-03-31T13:19:00.000Z + + + Luke Dashjr + 2024-03-31T14:33:00.000Z + + + Jameson Lopp + 2024-03-31T14:57:00.000Z + + + Peter Todd + 2024-03-31T16:02:00.000Z + + + Eric Voskuil + 2024-03-31T17:21:00.000Z + + + Nagaev Boris + 2024-03-31T21:01:00.000Z + + + Peter Todd + 2024-03-31T21:29:00.000Z + + + Jameson Lopp + 2024-04-01T12:54:00.000Z + + + Andrew Poelstra + 2024-04-01T13:25:00.000Z + + + Fabian' + 2024-04-01T13:32:00.000Z + + + Pieter Wuille + 2024-04-01T13:37:00.000Z + + + Andrew Poelstra + 2024-04-01T14:20:00.000Z + + + Warren Togami + 2024-04-01T14:28:00.000Z + + + emsit + 2024-04-01T19:22:00.000Z + + + Fabian' + 2024-04-01T22:01:00.000Z + + + Jameson Lopp + 2024-04-02T11:53:00.000Z + + + Lukáš Kráľ + 2024-04-02T18:36:00.000Z + + + Jameson Lopp + 2024-04-02T19:46:00.000Z + + + Anthony Towns + 2024-04-03T04:19:00.000Z + + + emsit + 2024-04-03T18:18:00.000Z + + + Andrew Poelstra + 2024-04-03T19:35:00.000Z + + + Calvin Kim + 2024-04-04T08:14:00.000Z + + + Jameson Lopp + 2024-04-04T12:47:00.000Z + + + Calvin Kim + 2024-04-05T04:30:00.000Z + + + David A. Harding + 2024-04-06T23:04:00.000Z + + + Christian Decker + 2024-04-07T07:20:00.000Z + + + K Calvin + 2024-04-07T08:09:00.000Z + + + Garlo Nicon + 2024-04-08T19:11:00.000Z + + + coinableS + 2024-04-09T04:29:00.000Z + + + Peter Todd + 2024-04-09T16:48:00.000Z + + + Garlo Nicon + 2024-04-09T18:28:00.000Z + + + Garlo Nicon + 2024-04-10T06:57:00.000Z + + + Sjors Provoost' + 2024-04-16T17:30:00.000Z + + + Ali Sherief + 2024-04-22T04:33:00.000Z + + + Matt Corallo + 2024-04-28T13:45:00.000Z + + + Matthew Bagazinski + 2024-04-30T18:46:00.000Z + + + Garlo Nicon + 2024-05-01T15:30:00.000Z + + + Ali Sherief + 2024-05-02T07:10:00.000Z + + + Peter Todd + 2024-05-04T17:08:00.000Z + + + Peter Todd + 2024-05-04T17:13:00.000Z + + + Garlo Nicon + 2025-03-31T10:48:00.000Z + + + Saint Wenhao + 2025-04-25T17:19:00.000Z + + @@ -171,17 +216,15 @@ - python-feedgen + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303535+00:00 + 2025-09-26T14:42:09.777351+00:00 + 2025-04-25T17:19:00+00:00 The discourse surrounding the future and functionality of Bitcoin's testnet3 brings to light several pressing issues and proposals for its evolution. Testnet3, after 13 years of operation and reaching a block height of approximately 2.5 million, finds itself at a crossroads due to a significantly reduced block reward and operational challenges arising from an edge case bug that resets the mining difficulty to one. This anomaly has led to operational inconsistencies and raised concerns about the effective distribution of testnet coins, as detailed in Jameson Lopp’s comprehensive analysis available [here](https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/). Furthermore, the network faces exploitation through scammy airdrops and an unintended marketplace where TBTC is actively traded, deviating from its foundational principle that testnet coins should hold no real-world value. - In response to these challenges, several key questions and proposals are presented to the community. The potential for a testnet reset is considered, recognizing the need for substantial notice due to the extensive updates required for production systems. Additionally, addressing the difficulty reset bug emerges as a priority, with suggestions for a straightforward code fix that might necessitate a hard fork. This approach, while potentially disruptive, could naturally integrate into the network's dynamics if executed thoughtfully. The necessity of formalizing this process through a Bitcoin Improvement Proposal (BIP) or adopting a more informal implementation strategy remains a point of debate. - Moreover, the discussion extends to the possibility of deprecating testnet3 in favor of signet, highlighting an ongoing exploration of alternative testing environments that might better serve the needs of the Bitcoin development community. This conversation reflects a broader debate on balancing innovation and stability within Bitcoin's development platforms, emphasizing the importance of community feedback and collaborative decision-making in navigating the future of testnet3. The dialogue ultimately underscores the complexities of managing blockchain networks like Bitcoin, where technical adjustments must consider both their immediate impact and broader implications for developers, miners, and the ecosystem at large. - 2025-04-25T17:19:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_-Recursive-covenant-with-CTV-and-CSFS.xml b/static/bitcoin-dev/March_2025/combined_-Recursive-covenant-with-CTV-and-CSFS.xml index 813963138d..2a8ffe5344 100644 --- a/static/bitcoin-dev/March_2025/combined_-Recursive-covenant-with-CTV-and-CSFS.xml +++ b/static/bitcoin-dev/March_2025/combined_-Recursive-covenant-with-CTV-and-CSFS.xml @@ -1,68 +1,91 @@ - + 2 - Combined summary - "Recursive covenant" with CTV and CSFS - 2025-03-19T02:30:32.925392+00:00 - - moonsettler 2025-03-18 20:29:00+00:00 - - - Anthony Towns 2025-03-14 03:20:00+00:00 - - - Nadav Ivgi 2025-03-12 16:15:00+00:00 - - - Nadav Ivgi 2025-03-12 10:02:00+00:00 - - - Anthony Towns 2025-03-12 03:48:00+00:00 - - - Antoine Riard 2025-03-11 01:06:00+00:00 - - - Antoine Riard 2025-03-10 22:36:00+00:00 - - - Nadav Ivgi 2025-03-10 05:14:00+00:00 - - - James OBeirne 2025-03-08 15:55:00+00:00 - - - Anthony Towns 2025-03-07 21:36:00+00:00 - - - Anthony Towns 2025-03-07 21:16:00+00:00 - - - Anthony Towns 2025-03-07 21:01:00+00:00 - - - Antoine Riard 2025-03-06 21:26:00+00:00 - - - moonsettler 2025-03-06 18:36:00+00:00 - - - Greg Sanders 2025-03-06 17:17:00+00:00 - - - Antoine Riard 2025-03-05 22:46:00+00:00 - - - moonsettler 2025-03-05 17:53:00+00:00 - - - Antoine Poinsot 2025-03-05 16:14:00+00:00 - - - Olaoluwa Osuntokun 2025-03-05 06:14:00+00:00 - - - Anthony Towns 2025-03-05 00:01:00+00:00 - + Combined summary - "Recursive covenant" with CTV and CSFS + 2025-09-26T14:37:39.636720+00:00 + python-feedgen + + + Recursive covenant" with CTV and CSFS Anthony Towns + 2025-03-05T00:01:00.000Z + + + Olaoluwa Osuntokun + 2025-03-05T06:14:00.000Z + + + Antoine Poinsot' + 2025-03-05T16:14:00.000Z + + + moonsettler' + 2025-03-05T17:53:00.000Z + + + Antoine Riard + 2025-03-05T22:46:00.000Z + + + Greg Sanders + 2025-03-06T17:17:00.000Z + + + moonsettler' + 2025-03-06T18:36:00.000Z + + + Antoine Riard + 2025-03-06T21:26:00.000Z + + + Anthony Towns + 2025-03-07T21:01:00.000Z + + + Anthony Towns + 2025-03-07T21:16:00.000Z + + + Anthony Towns + 2025-03-07T21:36:00.000Z + + + James O'Beirne + 2025-03-08T15:55:00.000Z + + + Nadav Ivgi + 2025-03-10T05:14:00.000Z + + + Antoine Riard + 2025-03-10T22:36:00.000Z + + + Antoine Riard + 2025-03-11T01:06:00.000Z + + + Anthony Towns + 2025-03-12T03:48:00.000Z + + + Nadav Ivgi + 2025-03-12T10:02:00.000Z + + + Nadav Ivgi + 2025-03-12T16:15:00.000Z + + + Anthony Towns + 2025-03-14T03:20:00.000Z + + + moonsettler' + 2025-03-18T20:29:00.000Z + + @@ -83,23 +106,18 @@ - python-feedgen + 2 - Combined summary - "Recursive covenant" with CTV and CSFS - 2025-03-19T02:30:32.925531+00:00 + Combined summary - "Recursive covenant" with CTV and CSFS + 2025-09-26T14:37:39.638893+00:00 + 2025-03-18T20:29:00+00:00 In a series of insightful discussions among programmers and Bitcoin developers, the conversation traversed various technical landscapes, focusing on enhancing Bitcoin's transaction mechanics and scripting capabilities. The dialogue opened with an examination of new applications enabled by specific transaction strategies such as griefing deterrents through immortal statechains and yield collection from blind merged mining via surfchains. This exploration underscored the evolving nature of Bitcoin transactions, emphasizing the balance between security enhancements and the potential for enabling novel applications. - The discourse progressed into a detailed analysis of Bitcoin transaction mechanisms, spotlighting advanced concepts like Anyprevout (APO) and CheckTemplateVerify (CTV) in crafting specialized transaction chains. These techniques offer pathways to creating secure and efficient transaction processes, albeit with challenges in achieving trustless infinite chains without comprehensive introspection capabilities akin to those provided by Elements. Furthermore, the discussion highlighted the strategic considerations in managing transaction fees, particularly in high-feerate scenarios where the dynamics of Child Pays for Parent (CPFP) and Replace-By-Fee (RBF) mechanisms play crucial roles. Alternative transaction confirmation methods, such as direct compensation to miners, were also contemplated as potential solutions to existing challenges in transaction fee management. - Nadav Ivgi's contribution focused on the intricacies of Bitcoin's proposed enhancements, referencing COSHV (CheckOutputSHVerify) and its integration within Bitcoin scripting. This segment illuminated the technical and political nuances involved in adopting new script functionalities, stressing the continuous efforts within the Bitcoin Development community to refine and optimize blockchain protocols. The dialogue further delved into concerns related to transaction-withholding risks and the impact of extending script expressivity on these risks. The development and analysis of cryptographic functions within Bitcoin's ecosystem were discussed, highlighting ongoing efforts to fortify the network's security framework. - The conversation then explored the concept of transaction withholding (TxWithhold) smart contracts, presenting a unique mechanism for increasing miner income through anonymous participation in TxWithhold operations. This discussion not only showcased innovative blockchain functionalities but also emphasized the importance of understanding the technical foundations and limitations of existing technologies. - Further, the dialogue addressed the development and modification of Bitcoin Script, touching upon the complexities of implementing changes and the potential for more significant overhauls versus narrowly scoped adjustments. Antoine Poinsot advocated for a new, cleaner interpreter that could offer a more reliable solution than adjusting the current unpredictable framework, reflecting on the broader challenges in Bitcoin development where code clarity and predictability are paramount. - Lastly, the discourse examined proposals for the near-term activation of CTV and CSFS, as outlined in BIP 119 and BIP 348. The debate surrounding these proposals highlighted differing views on the readiness of the ecosystem for such changes and the practical applications of these features beyond theoretical concerns. This included discussions on the use of CTV and CSFS in facilitating spacechains and other innovative possibilities, demonstrating the dynamic debate within the Bitcoin development community regarding protocol enhancements and the future direction of Bitcoin's evolution. - 2025-03-18T20:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml b/static/bitcoin-dev/March_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml index b787d0798f..1f7c6d88a4 100644 --- a/static/bitcoin-dev/March_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml +++ b/static/bitcoin-dev/March_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml @@ -1,95 +1,23 @@ - + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747215+00:00 - - conduition 2025-08-09 19:53:00+00:00 - - - conduition 2025-07-15 13:53:00+00:00 - - - Jameson Lopp 2025-07-13 21:26:00+00:00 - - - Pieter Wuille 2025-07-13 19:28:00+00:00 - - - Boris Nagaev 2025-07-13 17:51:00+00:00 - - - Ethan Heilman 2025-07-13 16:01:00+00:00 - - - Or Sattath 2025-07-13 15:38:00+00:00 - - - Boris Nagaev 2025-07-13 14:20:00+00:00 - - - Jameson Lopp 2025-07-13 12:34:00+00:00 - - - Boris Nagaev 2025-07-13 01:39:00+00:00 - - - Jameson Lopp 2025-06-08 14:04:00+00:00 - - - waxwing/ AdamISZ 2025-06-07 13:28:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 21:15:00+00:00 - - - Sjors Provoost 2025-05-28 07:46:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 01:07:00+00:00 - - - ArmchairCryptologist 2025-05-26 15:40:00+00:00 - - - Agustin Cruz 2025-05-26 00:32:00+00:00 - - - Dustin Ray 2025-05-25 23:03:00+00:00 - - - conduition 2025-05-25 19:03:00+00:00 - - - Agustin Cruz 2025-03-24 11:19:00+00:00 - - - AstroTown 2025-03-22 19:02:00+00:00 - - - Sjors Provoost 2025-03-18 12:48:00+00:00 - - - Jameson Lopp 2025-03-17 13:28:00+00:00 - - - Matt Corallo 2025-03-17 12:00:00+00:00 - - - IdeA 2025-03-16 22:56:00+00:00 - - - Jameson Lopp 2025-03-16 21:25:00+00:00 - - - Jameson Lopp 2025-03-16 19:44:00+00:00 - - - Jameson Lopp 2025-03-16 18:03:00+00:00 - - - Jameson Lopp 2025-03-16 14:15:00+00:00 - + 2025-09-26T14:37:41.824630+00:00 + python-feedgen + + + Or Sattath + 2025-07-13T15:38:00.000Z + + + conduition' + 2025-07-15T13:53:00.000Z + + + conduition' + 2025-08-09T19:53:00.000Z + + @@ -119,21 +47,17 @@ - python-feedgen + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747403+00:00 + 2025-09-26T14:37:41.825190+00:00 + 2025-08-09T19:53:00+00:00 The discourse delves into the intricate challenges and potential approaches for integrating post-quantum cryptography within Bitcoin's framework, highlighting a proactive stance towards enhancing security against quantum computing threats. A notable proposal involves incorporating a form of post-quantum cryptography, specifically through an OP_HASHBASEDSIG mechanism, potentially utilizing SPHINCS+, to embed quantum-resistant public keys into wallet outputs. This suggestion underscores the urgency of preparing for quantum advancements well in advance, advocating for the embedding of these public keys at least a decade prior to any enforcement action to ensure ample safety margins. - The dialogue further explores the ethical and practical considerations surrounding the handling of Bitcoin funds that may become vulnerable to quantum decryption. The debate oscillates between two primary courses of action: leaving such funds accessible, thereby susceptible to potential quantum theft, or proactively rendering them unspendable to preemptively secure them against quantum capabilities. This discussion touches upon core Bitcoin principles including censorship resistance, forward compatibility, and conservatism. The ethical implications are profound, weighing the prevention of economic disruption against the fairness and property rights implications of either allowing or preventing quantum-enabled theft. - Historical precedents within the Bitcoin protocol's evolution serve as reference points for this debate, suggesting a tendency towards remedying vulnerabilities rather than exploiting them. The conversation acknowledges the complexity of incentivizing the ecosystem-wide adoption of quantum-resistant technologies through measures possibly as radical as burning vulnerable coins. - Furthermore, the exchange considers the broader implications of quantum recovery and the potential redistribution of wealth from those without access to quantum technology to those who might achieve quantum supremacy. This raises significant questions about the balance between ensuring long-term security and adhering to Bitcoin's foundational principles of decentralization and user sovereignty. - In addressing the potential quantum threat, the dialogue encapsulates a meticulous examination of both the technical feasibility of implementing quantum-resistant cryptographic methods and the philosophical underpinnings guiding these decisions. It reflects an ongoing effort among developers and stakeholders to navigate the evolving landscape of digital currency security thoughtfully, emphasizing the need for community consensus and careful consideration of Bitcoin's core values in the face of emerging technological challenges. - 2025-08-09T19:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Consensus-Cleanup-BIP-draft.xml b/static/bitcoin-dev/March_2025/combined_Consensus-Cleanup-BIP-draft.xml index 3a21160116..584ae43e5c 100644 --- a/static/bitcoin-dev/March_2025/combined_Consensus-Cleanup-BIP-draft.xml +++ b/static/bitcoin-dev/March_2025/combined_Consensus-Cleanup-BIP-draft.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Consensus Cleanup BIP draft - 2025-04-01T03:03:13.747555+00:00 - - eric 2025-03-31 20:09:00+00:00 - - - Antoine Poinsot 2025-03-31 15:29:00+00:00 - - - Anthony Towns 2025-03-31 11:00:00+00:00 - - - Sjors Provoost 2025-03-29 11:02:00+00:00 - - - eric 2025-03-28 19:53:00+00:00 - - - Sjors Provoost 2025-03-28 14:07:00+00:00 - - - Chris Stewart 2025-03-28 13:54:00+00:00 - - - Sjors Provoost 2025-03-28 12:48:00+00:00 - - - Chris Stewart 2025-03-28 11:02:00+00:00 - - - Sjors Provoost 2025-03-28 09:23:00+00:00 - - - jeremy 2025-03-27 21:38:00+00:00 - - - jeremy 2025-03-27 20:45:00+00:00 - - - Antoine Poinsot 2025-03-27 19:05:00+00:00 - - - /dev /fd0 2025-03-27 17:54:00+00:00 - - - Chris Stewart 2025-03-27 10:46:00+00:00 - - - Antoine Poinsot 2025-03-26 17:14:00+00:00 - + 2025-09-26T14:37:54.628480+00:00 + python-feedgen + + + Consensus Cleanup BIP draft 'Antoine Poinsot' + 2025-03-26T17:14:00.000Z + + + Chris Stewart + 2025-03-27T10:46:00.000Z + + + /dev /fd0 + 2025-03-27T17:54:00.000Z + + + Antoine Poinsot' + 2025-03-27T19:05:00.000Z + + + jeremy + 2025-03-27T20:45:00.000Z + + + Antoine Poinsot' + 2025-03-27T21:38:00.000Z + + + Sjors Provoost + 2025-03-28T09:23:00.000Z + + + Chris Stewart + 2025-03-28T11:02:00.000Z + + + Sjors Provoost + 2025-03-28T12:48:00.000Z + + + Chris Stewart + 2025-03-28T13:54:00.000Z + + + Sjors Provoost + 2025-03-28T14:07:00.000Z + + + eric + 2025-03-28T19:53:00.000Z + + + Sjors Provoost + 2025-03-29T11:02:00.000Z + + + Anthony Towns + 2025-03-31T11:00:00.000Z + + + Antoine Poinsot' + 2025-03-31T15:29:00.000Z + + + eric + 2025-03-31T20:09:00.000Z + + @@ -67,23 +86,18 @@ - python-feedgen + 2 Combined summary - Consensus Cleanup BIP draft - 2025-04-01T03:03:13.747662+00:00 + 2025-09-26T14:37:54.630367+00:00 + 2025-03-31T20:09:00+00:00 The dialogue within the Bitcoin Development Mailing List brings to light a comprehensive discussion on the nuances of implementing changes within the Bitcoin protocol, specifically addressing the need for a new consensus rule aimed at enhancing Simplified Payment Verification (SPV) wallets. The rule proposes to eliminate the necessity for these wallets to obtain the coinbase transaction, theoretically simplifying their implementation. However, this proposal has been met with skepticism, as critics argue that, apart from marginally benefiting SPV wallet implementation, it fails to address initial problems related to security, performance, or code simplification for nodes. This situation has led to a consensus among some experts that the rule's sole justification lies in its slight convenience for SPV wallets, which hardly warrants the introduction of a discontinuity in the system. Moreover, there's an ongoing debate regarding the appropriateness of basing consensus changes on implementation details, especially when these do not contribute to solving broader issues within the system. - Further discussions delve into the technicalities of Bitcoin transactions, particularly focusing on Segregated Witness (SegWit) and its impact on transaction malleability and backward compatibility. SegWit, by altering how transaction data is stored and transmitted, introduces a separation where the witness data, including signatures, is detached from the main transaction block. This modification addresses the critical vulnerability of malleability in pre-SegWit transactions caused by the lack of signature space within the scriptSig field. The conversation also highlights the need for distinguishing between pre-SegWit and SegWit transactions due to their differing effects on transaction malleability and the potential implications for future compatibility concerns. - An intriguing aspect discussed is the unique characteristic of segwit transactions with a single input and output directing funds to a 2-byte witness program, exempt from the 64-byte size limitation. This peculiarity allows for potentially unlimited witness sizes, offering a broad avenue for transaction structure manipulation. Despite the theoretical possibilities, the practical applications of employing anchor outputs in transactions characterized by a singular input and output configuration remain subjects of ongoing debate. - In a series of exchanges, concerns were raised about the advisability of removing 64-byte transactions from the Bitcoin protocol, citing it as an undesirable alteration that could negatively impact future upgrades, particularly those enhancing transaction programmability. This debate reflects the intricate balance between innovation and the need for cautious, consensus-driven evolution within the Bitcoin ecosystem. - The communication further underscores the importance of procedural nuances in documenting proposed security enhancements for Bitcoin, advocating for separating these changes into distinct Bitcoin Improvement Proposals (BIPs). This approach would allow for more precise discussion, implementation, and future amendment processes within the technical community, maintaining flexibility in implementation and enabling individual proposals to be modified or removed without affecting the broader set of enhancements. - Finally, a draft Bitcoin Improvement Proposal (BIP) by Antoine Poinsot marks significant progress in blockchain technology, aiming to introduce amendments for enhancing the security and efficiency of Bitcoin consensus. The proposal addresses several longstanding issues affecting network stability and reliability, such as vulnerabilities to the Timewarp and Murch Zawy attacks, and introduces measures to streamline the validation process and bolster the network's resistance to specific types of manipulation or attacks. This collaborative effort highlights the community-driven nature of Bitcoin's evolution, emphasizing collective input and expertise in shaping the future of blockchain technology. - 2025-03-31T20:09:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Does-anyone-still-need-testnet3-.xml b/static/bitcoin-dev/March_2025/combined_Does-anyone-still-need-testnet3-.xml index c383cfb7b4..187dc4413e 100644 --- a/static/bitcoin-dev/March_2025/combined_Does-anyone-still-need-testnet3-.xml +++ b/static/bitcoin-dev/March_2025/combined_Does-anyone-still-need-testnet3-.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Does anyone still need testnet3? - 2025-04-02T02:43:49.589965+00:00 - - Sjors Provoost 2025-04-01 09:06:00+00:00 - - - Garlo Nicon 2025-04-01 05:56:00+00:00 - - - Melvin Carvalho 2025-03-31 21:23:00+00:00 - - - Melvin Carvalho 2025-03-21 05:44:00+00:00 - - - Sjors Provoost 2025-03-14 09:31:00+00:00 - - - Andreas Schildbach 2025-03-14 09:12:00+00:00 - - - Sjors Provoost 2025-03-14 08:52:00+00:00 - + 2025-09-26T14:37:46.099190+00:00 + python-feedgen + + + Does anyone still need testnet3? Sjors Provoost + 2025-03-14T08:52:00.000Z + + + Andreas Schildbach' + 2025-03-14T09:12:00.000Z + + + Sjors Provoost + 2025-03-14T09:31:00.000Z + + + Melvin Carvalho + 2025-03-21T05:44:00.000Z + + + Sanket Kanjalkar + 2025-03-31T21:23:00.000Z + + + Garlo Nicon + 2025-04-01T05:56:00.000Z + + + Sjors Provoost + 2025-04-01T09:06:00.000Z + + @@ -31,19 +41,16 @@ - python-feedgen + 2 Combined summary - Does anyone still need testnet3? - 2025-04-02T02:43:49.590031+00:00 + 2025-09-26T14:37:46.100106+00:00 + 2025-04-01T09:06:00+00:00 The Bitcoin development community is actively exploring solutions to enhance the functionality and accessibility of test networks, addressing challenges such as the difficulty in obtaining coins for development purposes due to high transaction fees on testnet3. A novel proposal suggests creating an application to enable coin swapping between testnet3 and testnet4, potentially incorporating an Automated Market Maker (AMM) system to facilitate this process. This initiative aims to simplify resource acquisition for developers, fostering a more efficient testing environment within the Bitcoin ecosystem. - Testnet4 is currently experiencing frequent short reorganizations (reorgs), primarily due to the exploitation of a rule that allows mining difficulty to drop significantly after a period without new blocks. This scenario leads to a situation where the Median Time Past (MTP) on testnet4 is often set in the future, an anomaly diverging from the expected behavior. In response, a countermeasure involving strategic re-organization of blocks mined at artificially low difficulty has been proposed. Though this solution is still conceptual and not intended for direct incorporation into Bitcoin Core, it offers a potential pathway to increase the frequency of reorgs, serving as a valuable testbed for debugging and further exploration. - The integration of testnet4 within the Bitcoinj framework is underway, though not yet complete, with the next release (version 0.18) anticipated to take longer than 12 months. Despite these timelines, the current version of testnet3 remains a satisfactory testing ground, even with its challenges, which are deemed beneficial for stress-testing code. The commitment to support both testnets moving forward was confirmed, alongside a mention of btc-rpc-explorer, a self-hostable block explorer tool, which currently does not support testnet4. These developments highlight ongoing efforts to improve testing frameworks and tools, reflecting the community's dedication to enhancing the robustness of Bitcoin-related technologies. - Testnet4, proposed in BIP94 and supported by Bitcoin Core from version 28, addresses the limitations of using testnet3, including block storms that have made it increasingly impractical. This transition allows users to either adopt testnet4 or continue utilizing testnet3 by maintaining their node software independently, underscoring the blockchain community's commitment to backward compatibility and adaptability. The discussion also opens the possibility of creating a permissionless signet based purely on proof-of-work, indicating an innovative approach to improving network functionality. Feedback from developers reliant on testnet3 is encouraged to ensure that future versions of Bitcoin Core, such as v29, remain inclusive and accommodating, highlighting the importance of community input in guiding Bitcoin's technological evolution. Interested parties are invited to contribute to the dialogue through the provided [Github issue link](https://github.com/bitcoin/bitcoin/issues/), facilitating a comprehensive discourse on these advancements. - 2025-04-01T09:06:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Finished-planned-work-on-BIP-3-Updated-BIP-Process.xml b/static/bitcoin-dev/March_2025/combined_Finished-planned-work-on-BIP-3-Updated-BIP-Process.xml index 4d3179f21b..6536a2d960 100644 --- a/static/bitcoin-dev/March_2025/combined_Finished-planned-work-on-BIP-3-Updated-BIP-Process.xml +++ b/static/bitcoin-dev/March_2025/combined_Finished-planned-work-on-BIP-3-Updated-BIP-Process.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Finished planned work on BIP 3: Updated BIP Process - 2025-03-29T02:31:25.297115+00:00 - - Antoine Poinsot 2025-03-28 17:21:00+00:00 - - - Murch 2025-03-19 02:38:00+00:00 - - - Murch 2025-02-03 19:11:00+00:00 - + 2025-09-26T14:37:35.182914+00:00 + python-feedgen + + + Finished planned work on BIP 3: Updated BIP Process Murch + 2025-02-03T19:11:00.000Z + + + Murch + 2025-03-19T02:38:00.000Z + + + Antoine Poinsot' + 2025-03-28T17:21:00.000Z + + - python-feedgen + 2 Combined summary - Finished planned work on BIP 3: Updated BIP Process - 2025-03-29T02:31:25.297175+00:00 + 2025-09-26T14:37:35.183549+00:00 + 2025-03-28T17:21:00+00:00 The recent communications and developments regarding the Bitcoin Improvement Proposals (BIPs) underscore a significant advancement in the evolution of the Bitcoin protocol. A particular focus has been placed on BIP3, which has undergone various stages of review and refinement, signaling its readiness for broader adoption within the Bitcoin community. Following its merge as a Draft on February 20th and subsequent minor updates, a period of over three weeks passed without any further feedback, suggesting a consensus among stakeholders on its readiness. The current proposal to advance BIP3 to the status of Proposed marks a crucial step towards its implementation. Stakeholders are encouraged to share their comments, suggestions, or concerns through the provided [GitHub link](https://github.com/bitcoin/bips/pull/1794), via email, or other communication channels associated with the Bitcoin Development Mailing List group. - In detailing the process of updating the BIP procedure, it's noted that significant efforts have been made by developers to refine the proposal. Initially conducted in a private repository, the work was later moved to the public domain through a pull request in the official BIPs Repository in early December. This move facilitated two additional rounds of review, leading to its designation as BIP 3 at the beginning of January. The developer behind these updates has completed their contributions and is now seeking feedback from the wider Bitcoin development community. This initiative aims not only to gather reviews from those who have been following the proposal closely but also to invite new contributors to offer suggestions, voice concerns, or express support for the proposal. Interested parties can find more details and participate in the discussion through the provided [GitHub link](https://github.com/bitcoin/bips/pull/1712). This effort reflects an ongoing commitment to maintaining a robust, transparent, and inclusive framework for proposing and implementing improvements to Bitcoin, with the engagement and feedback from the community being vital for shaping its future direction. - 2025-03-28T17:21:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml b/static/bitcoin-dev/March_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml index a6b106d244..1c8239363d 100644 --- a/static/bitcoin-dev/March_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml +++ b/static/bitcoin-dev/March_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Hashed keys are actually fully quantum secure - 2025-07-01T05:35:10.635886+00:00 - - conduition 2025-06-02 18:29:00+00:00 - - - Nagaev Boris 2025-05-26 10:03:00+00:00 - - - conduition 2025-05-25 18:22:00+00:00 - - - Martin Habovštiak 2025-03-30 20:16:00+00:00 - - - Martin Habovštiak 2025-03-30 20:11:00+00:00 - - - David A. Harding 2025-03-30 15:41:00+00:00 - - - Lloyd Fournier 2025-03-24 00:24:00+00:00 - - - Erik Aronesty 2025-03-18 16:48:00+00:00 - - - Martin Habovštiak 2025-03-17 11:07:00+00:00 - - - Lloyd Fournier 2025-03-17 10:44:00+00:00 - - - Martin Habovštiak 2025-03-16 20:52:00+00:00 - - - Agustin Cruz 2025-03-16 19:03:00+00:00 - - - Martin Habovštiak 2025-03-16 18:50:00+00:00 - - - Martin Habovštiak 2025-03-16 18:25:00+00:00 - + 2025-09-26T14:37:20.339625+00:00 + python-feedgen + + + Hashed keys are actually fully quantum secure Martin Habovštiak + 2025-03-16T18:25:00.000Z + + + Antoine Poinsot' + 2025-03-16T18:50:00.000Z + + + Agustin Cruz + 2025-03-16T19:03:00.000Z + + + Martin Habovštiak + 2025-03-16T20:52:00.000Z + + + Lloyd Fournier + 2025-03-17T10:44:00.000Z + + + Martin Habovštiak + 2025-03-17T11:07:00.000Z + + + Erik Aronesty + 2025-03-18T16:48:00.000Z + + + Lloyd Fournier + 2025-03-24T00:24:00.000Z + + + David A. Harding + 2025-03-30T15:41:00.000Z + + + Martin Habovštiak + 2025-03-30T20:11:00.000Z + + + Martin Habovštiak + 2025-03-30T20:16:00.000Z + + + conduition' + 2025-05-25T18:22:00.000Z + + + Nagaev Boris + 2025-05-26T10:03:00.000Z + + + conduition' + 2025-06-02T18:29:00.000Z + + @@ -59,23 +76,18 @@ - python-feedgen + 2 Combined summary - Hashed keys are actually fully quantum secure - 2025-07-01T05:35:10.635989+00:00 + 2025-09-26T14:37:20.341524+00:00 + 2025-06-02T18:29:00+00:00 The series of discussions within the Bitcoin Development Mailing List covers a wide range of technical proposals and security concerns aimed at enhancing the resilience of Bitcoin in the face of evolving threats, particularly those posed by quantum computing. One focal point is the exploration of innovative mechanisms to safeguard transactions through cryptographic adjustments, such as employing Quantum Resistant (QR) signatures and committing to these within the blockchain infrastructure. This approach underscores a proactive strategy to prevent potential attackers from exploiting vulnerabilities inherent in current cryptographic practices, especially considering the advent of quantum computing capabilities. - A significant portion of the dialogue delves into the intricacies of implementing these security measures, including the technical feasibility of embedding QR signature commitments in transaction processes. The discussions reveal a consensus on the necessity for a soft fork to introduce such enhancements, highlighting the community's readiness to adapt the Bitcoin protocol to mitigate these advanced threats. The conversation also touches upon the procedural and technical requirements for deploying QR signing algorithms, reflecting a broader commitment to securing the cryptocurrency against irrevocable loss due to quantum attacks. - -Moreover, the dialogue extends into the tactical aspects of ensuring transactional integrity and security. For instance, the concept of providing a "head start" for transactions to preempt quantum computational attacks illustrates a nuanced approach to maintaining the competitiveness and security of legitimate transactions within the network. This idea, coupled with the integration of a robust Replace-By-Fee (RBF) mechanism, represents an adaptive response to the dynamic challenges facing Bitcoin's security framework. - +Moreover, the dialogue extends into the tactical aspects of ensuring transactional integrity and security. For instance, the concept of providing a "head start" for transactions to preempt quantum computational attacks illustrates a nuanced approach to maintaining the competitiveness and security of legitimate transactions within the network. This idea, coupled with the integration of a robust Replace-By-Fee (RBF) mechanism, represents an adaptive response to the dynamic challenges facing Bitcoin's security framework. Additionally, the discussions underscore the importance of collaborative efforts and the exchange of ideas among developers to refine and evolve Bitcoin's defensive strategies. The examination of Taproot's hashing functionalities and its implications for address reuse and system flexibility indicates a deep engagement with both the technical and social dimensions of cryptocurrency security. These conversations illuminate the complexities of balancing technical innovation with practical implementation and user adoption. - Furthermore, the discourse around the potential need for a soft fork to disallow the spending of bare public keys, leveraging the security benefits of Taproot keys against quantum threats, reflects a strategic foresight. This discussion emphasizes the critical role of community consensus in timing and executing such a significant protocol change, underscoring the challenges of navigating the uncertain terrain of quantum computing advancements. - In conclusion, the exchanges within the Bitcoin Development Mailing List highlight a multifaceted approach to enhancing Bitcoin's security. From addressing quantum computing threats with QR signatures to refining transaction mechanisms for improved resilience, the community's engagement with these issues showcases a proactive and collaborative effort to fortify Bitcoin against future vulnerabilities. The ongoing dialogue signifies an acknowledgment of the nuanced challenges at the intersection of technology, security, and consensus-building, laying the groundwork for continued innovation and adaptation in the cryptocurrency's protocol and practices. - 2025-06-02T18:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_New-Proposal-String-Substring-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml b/static/bitcoin-dev/March_2025/combined_New-Proposal-String-Substring-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml index 2dc67fb5a4..d87f713de0 100644 --- a/static/bitcoin-dev/March_2025/combined_New-Proposal-String-Substring-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml +++ b/static/bitcoin-dev/March_2025/combined_New-Proposal-String-Substring-Search-in-Bitcoin-Script-OP-ISSUBSTR.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - New Proposal：String Substring Search in Bitcoin Script - OP_ISSUBSTR - 2025-04-10T02:36:16.758506+00:00 - - Anthony Towns 2025-04-08 18:04:00+00:00 - - - Martin Habovštiak 2025-04-01 15:35:00+00:00 - - - Pieter Wuille 2025-04-01 12:25:00+00:00 - - - Javier Mateos 2025-03-28 22:40:00+00:00 - - - Vojtěch Strnad 2025-03-20 00:23:00+00:00 - - - weichu deng 2025-03-19 09:07:00+00:00 - - - Rijndael 2025-03-18 21:33:00+00:00 - - - Erik Aronesty 2025-03-18 16:41:00+00:00 - - - weichu deng 2025-03-18 15:32:00+00:00 - - - Peter Todd 2025-03-17 16:54:00+00:00 - - - weichu deng 2025-03-17 16:14:00+00:00 - + 2025-09-26T14:37:52.479160+00:00 + python-feedgen + + + New Proposal：String Substring Search in Bitcoin Script - OP_ISSUBSTR weichu deng + 2025-03-17T16:14:00.000Z + + + Peter Todd + 2025-03-17T16:54:00.000Z + + + weichu deng + 2025-03-18T15:32:00.000Z + + + Erik Aronesty + 2025-03-18T16:41:00.000Z + + + Rijndael + 2025-03-18T21:33:00.000Z + + + weichu deng + 2025-03-19T09:07:00.000Z + + + Vojtěch Strnad + 2025-03-20T00:23:00.000Z + + + Javier Mateos + 2025-03-28T22:40:00.000Z + + + Pieter Wuille + 2025-04-01T12:25:00.000Z + + + Martin Habovštiak + 2025-04-01T15:35:00.000Z + + + Anthony Towns + 2025-04-08T18:04:00.000Z + + @@ -47,25 +61,19 @@ - python-feedgen + 2 Combined summary - New Proposal：String Substring Search in Bitcoin Script - OP_ISSUBSTR - 2025-04-10T02:36:16.758592+00:00 + 2025-09-26T14:37:52.480551+00:00 + 2025-04-08T18:04:00+00:00 In a recent discussion among programmers, the efficiency and potential limitations of using different opcodes in programming were examined, with a particular focus on Bitcoin script development. The conversation revolved around the OP_CAT operation and its alternatives for string manipulation, highlighting how certain operations could be more efficiently executed with opcodes designed for specific tasks like substring extraction. This dialogue sheds light on the nuanced considerations developers must make when choosing opcodes to express their logic, balancing efficiency with the natural language of coding. - The debate touched upon the structural adjustments within data management practices, inspired by the Rust programming community's approach to managing data arrays. By storing stack elements on the heap with a detailed structure that includes reference count, length, and data array, substring operations can be made more efficient and secure. This method effectively prevents stack overflow risks without compromising on operational functionality, offering insights into memory management strategies that enhance programming security and efficiency. - Furthermore, the conversation delved into the scripting nuances within cryptocurrency transactions, particularly in Bitcoin. It was argued that scripts should aim to verify information rather than compute it, advocating for a simplification in script design. By requiring specific inputs like coin position, scripts can streamline verification processes, making a case for minimizing computational functions within scripts to optimize performance and security. - Technical challenges of dynamic string handling in Bitcoin script development were also discussed. The limitations of OP_CAT in scenarios where the substring's position is not predetermined highlight a need for more flexible string manipulation tools. This points towards an ongoing dialogue within the Bitcoin developer community to explore robust solutions or alternative approaches that accommodate dynamic string operations, underlining the importance of evolving script functionalities to address practical development challenges. - An innovative approach to enhancing user interaction and security in a Bitcoin-based game was proposed, leveraging public key manipulation in a split format. This technique emphasizes the versatility and creative potential of Bitcoin's scripting language, illustrating how technical ingenuity can introduce novel mechanisms for user engagement within the cryptocurrency space. - The intricacies of implementing substring search functionalities in Bitcoin scripts were further explored, with discussions around the technical and security implications of reintroducing the OP_CAT operation. These exchanges underscore the careful consideration required to balance functional enhancements with security imperatives, reflecting a broader commitment within the Bitcoin development community to refine and advance the scripting capabilities of the cryptocurrency. - Finally, a new Bitcoin Improvement Proposal (BIP) introduces OP_ISSUBSTR and OP_ISSUBSTRVERIFY, aiming to reintroduce string operations in Bitcoin scripts. This proposal addresses the developmental challenges posed by the current lack of on-chain string logic processing capabilities, proposing a secure and efficient mechanism for substring verification. This initiative marks a significant step towards expanding the functionality and developer-friendliness of Bitcoin scripts, underscoring the community's proactive approach to addressing emerging challenges and enhancing the cryptocurrency's underlying technology. - 2025-04-08T18:04:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_P2QRH-BIP-360-Update.xml b/static/bitcoin-dev/March_2025/combined_P2QRH-BIP-360-Update.xml index 6886e9dcfd..750eb7da85 100644 --- a/static/bitcoin-dev/March_2025/combined_P2QRH-BIP-360-Update.xml +++ b/static/bitcoin-dev/March_2025/combined_P2QRH-BIP-360-Update.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - P2QRH / BIP-360 Update - 2025-03-15T02:27:13.172496+00:00 - - Hunter Beast 2025-03-12 21:05:00+00:00 - - - Jose Storopoli 2025-03-12 11:14:00+00:00 - - - Hunter Beast 2025-03-03 21:00:00+00:00 - - - Hunter Beast 2025-03-03 20:57:00+00:00 - - - Dustin Ray 2025-02-28 04:19:00+00:00 - - - Matt Corallo 2025-02-26 19:02:00+00:00 - - - Jonas Nick 2025-02-26 08:08:00+00:00 - - - Tim Bratton 2025-02-26 00:03:00+00:00 - - - Hunter Beast 2025-02-25 18:03:00+00:00 - - - Hunter Beast 2025-02-25 16:54:00+00:00 - - - Ian Quantum 2025-02-24 16:12:00+00:00 - - - Jonas Nick 2025-02-24 13:17:00+00:00 - - - Hunter Beast 2025-02-23 20:58:00+00:00 - - - Hunter Beast 2025-02-23 20:33:00+00:00 - - - Jonas Nick 2025-02-21 08:54:00+00:00 - - - Matt Corallo 2025-02-20 22:11:00+00:00 - - - Hunter Beast 2025-02-19 22:57:00+00:00 - - - Dustin Ray 2025-02-19 17:23:00+00:00 - - - Hunter Beast 2025-02-19 15:40:00+00:00 - + 2025-09-26T14:37:50.361995+00:00 + python-feedgen + + + P2QRH / BIP-360 Update Hunter Beast + 2025-02-19T15:40:00.000Z + + + Dustin Ray + 2025-02-19T17:23:00.000Z + + + Hunter Beast + 2025-02-19T22:57:00.000Z + + + Matt Corallo + 2025-02-20T22:11:00.000Z + + + Jonas Nick + 2025-02-21T08:54:00.000Z + + + Hunter Beast + 2025-02-23T20:33:00.000Z + + + Hunter Beast + 2025-02-23T20:58:00.000Z + + + Jonas Nick + 2025-02-24T13:17:00.000Z + + + Ian Quantum + 2025-02-24T16:12:00.000Z + + + Hunter Beast + 2025-02-25T16:54:00.000Z + + + Hunter Beast + 2025-02-25T18:03:00.000Z + + + Tim Bratton + 2025-02-26T00:03:00.000Z + + + Jonas Nick + 2025-02-26T08:08:00.000Z + + + Matt Corallo + 2025-02-26T19:02:00.000Z + + + Dustin Ray + 2025-02-28T04:19:00.000Z + + + Hunter Beast + 2025-03-03T20:57:00.000Z + + + Hunter Beast + 2025-03-03T21:00:00.000Z + + + Jose Storopoli + 2025-03-12T11:14:00.000Z + + + Hunter Beast + 2025-03-12T21:05:00.000Z + + @@ -79,21 +101,17 @@ - python-feedgen + 2 Combined summary - P2QRH / BIP-360 Update - 2025-03-15T02:27:13.172638+00:00 + 2025-09-26T14:37:50.364194+00:00 + 2025-03-12T21:05:00+00:00 The ongoing discussions and developments within the Bitcoin development community focus on enhancing the blockchain's security in the face of potential quantum computing threats. A significant portion of this discourse revolves around the implementation and integration of post-quantum cryptography (PQC) strategies to safeguard Bitcoin against emerging computational capabilities that could compromise existing cryptographic defenses. Among the notable concerns is the practicality of incorporating quantum-resistant algorithms without excessively burdening the blockchain's efficiency and user experience. The critique extends to specific Bitcoin Improvement Proposals (BIPs) that aim to introduce new cryptographic measures, with particular attention given to their potential vulnerabilities and the implications for multisig transactions and attestation mechanisms. - A key aspect of the debate centers on finding a balance between adopting robust PQC methods and maintaining the operational integrity of the Bitcoin network. There is an acknowledgment of the challenges posed by transitioning to quantum-resistant architectures, such as increased computational costs, larger key sizes, and the complexity of integrating these new systems into the existing framework. Discussions emphasize the importance of pragmatic and forward-thinking approaches that can offer interim protection against quantum threats while paving the way for more comprehensive solutions as the field of quantum computing and PQC evolves. - In addition to technical considerations, there is a strong emphasis on community engagement and feedback in shaping the direction of Bitcoin's quantum resistance efforts. Proposed changes and updates to BIPs are subject to meticulous scrutiny, with contributions from various stakeholders aimed at refining these proposals to ensure they provide effective security enhancements without compromising the core functionalities of the Bitcoin protocol. This collaborative effort underscores the dynamic nature of cryptocurrency development, where adaptability and collective expertise play critical roles in navigating the complexities of digital security in an ever-evolving technological landscape. - Moreover, the discourse reflects a nuanced understanding of the trade-offs involved in implementing PQC measures. While the urgency of preparing for quantum computing advancements is recognized, there is also a cautious approach to avoid premature commitments to specific cryptographic schemes that may not fully address the unique challenges faced by cryptocurrencies like Bitcoin. The exploration of various algorithms, including hash-based signatures and lattice-based cryptography, indicates a comprehensive search for solutions that align with Bitcoin's security needs and operational constraints. - Overall, the conversations among Bitcoin developers highlight a concerted effort to anticipate and counteract quantum computing threats through strategic planning and community-driven decision-making. By prioritizing both immediate and long-term security objectives, the development community aims to fortify Bitcoin against emerging challenges while ensuring that the blockchain remains accessible, efficient, and secure for users worldwide. - 2025-03-12T21:05:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Proposal-Unlocking-Dust-UTXOs-as-Miner-Transaction-Fees.xml b/static/bitcoin-dev/March_2025/combined_Proposal-Unlocking-Dust-UTXOs-as-Miner-Transaction-Fees.xml index 5ba175e0a5..d29d499f51 100644 --- a/static/bitcoin-dev/March_2025/combined_Proposal-Unlocking-Dust-UTXOs-as-Miner-Transaction-Fees.xml +++ b/static/bitcoin-dev/March_2025/combined_Proposal-Unlocking-Dust-UTXOs-as-Miner-Transaction-Fees.xml @@ -1,49 +1,53 @@ - + 2 Combined summary - Proposal: Unlocking Dust UTXOs as Miner Transaction Fees - 2025-03-15T02:28:26.630536+00:00 - - Garlo Nicon 2025-03-13 12:55:00+00:00 - - - Nighttime Satoshi 2025-03-09 01:35:00+00:00 - - - Pieter Wuille 2025-03-08 23:48:00+00:00 - - - Nighttime Satoshi 2025-03-08 23:15:00+00:00 - - - Light 2025-03-08 22:13:00+00:00 - - - Nighttime Satoshi 2025-03-08 18:23:00+00:00 - + 2025-09-26T14:37:48.213843+00:00 + python-feedgen + + + Proposal: Unlocking Dust UTXOs as Miner Transaction Fees Nighttime Satoshi + 2025-03-08T18:23:00.000Z + + + Light + 2025-03-08T22:13:00.000Z + + + Nighttime Satoshi + 2025-03-08T23:15:00.000Z + + + Pieter Wuille + 2025-03-08T23:48:00.000Z + + + Nighttime Satoshi + 2025-03-09T01:35:00.000Z + + + Garlo Nicon + 2025-03-13T12:55:00.000Z + + - python-feedgen + 2 Combined summary - Proposal: Unlocking Dust UTXOs as Miner Transaction Fees - 2025-03-15T02:28:26.630597+00:00 + 2025-09-26T14:37:48.214725+00:00 + 2025-03-13T12:55:00+00:00 The recent discussions within the Bitcoin Development Mailing List have unveiled a series of proposals and critiques regarding the handling of dust UTXOs—tiny amounts of Bitcoin that are not economically viable to spend due to their value being less than the transaction fees required. These discussions delve into technical and economic considerations of proposed changes aimed at enhancing the fungibility of Bitcoin and reducing the bloat of the Unspent Transaction Output (UTXO) set, which represents all bitcoins not yet spent. - -One segment of the conversation focuses on a revised proposal addressing the reintegration of dust satoshis back into the Bitcoin network at the Layer 1 level. The necessity of finding a solution for dust UTXOs is emphasized, with the proposal suggesting that allowing miners to claim authorized dust UTXOs through standard-format transactions could distribute the transaction overhead across many claims without changing the existing rule for coinbase transactions to only have one input. Moreover, it introduces a mechanism for spending dust outputs without meeting their original conditions by creating a "Dust Fee Authorization" transaction. This would enable the use of dust UTXOs below a specific threshold in a manner that adheres to new, strict rules, potentially as part of a soft fork. - +One segment of the conversation focuses on a revised proposal addressing the reintegration of dust satoshis back into the Bitcoin network at the Layer 1 level. The necessity of finding a solution for dust UTXOs is emphasized, with the proposal suggesting that allowing miners to claim authorized dust UTXOs through standard-format transactions could distribute the transaction overhead across many claims without changing the existing rule for coinbase transactions to only have one input. Moreover, it introduces a mechanism for spending dust outputs without meeting their original conditions by creating a "Dust Fee Authorization" transaction. This would enable the use of dust UTXOs below a specific threshold in a manner that adheres to new, strict rules, potentially as part of a soft fork. Pieter Wuille's critique sheds light on the practical and economic challenges of implementing such changes as a soft fork, emphasizing that any alteration allowing coinbase transactions to spend outputs or change the rules surrounding dust outputs would necessitate a hardfork. Wuille argues that the economic viability of the proposed methods, including the costs associated with OP_RETURN outputs and additional coinbase transaction inputs, might outweigh the benefits of reclaiming dust output values. - Further discussion explores the dynamic nature of the dust threshold, suggesting flexibility in wallet software to adapt based on mempool conditions, and the focus on simple key-controlled UTXOs to keep initial implementations manageable. There's an openness to future expansions that could address more complex script types. Concerns about exceeding metadata requirements and the economic viability of the proposal during high-fee periods are also raised, alongside possibilities for reducing transaction weight through innovations like Schnorr signatures. - Critiques extend to the practicality of the proposal, questioning the improvement it offers over existing methods, especially given potential high transaction fees that could negate the economic advantage of reclaiming dust UTXOs. The dialogue reflects on the balance between technical feasibility, economic incentives, and the overall goal of enhancing Bitcoin's efficiency and utility. - Pieter Wuille's proposal introduces a novel approach to this challenge, proposing a system where users can allow their dust UTXOs to be claimed by miners as transaction fees through cryptographic authorization. This voluntary method aims to benefit users by recovering lost value, provide additional fee income for miners, and reduce the UTXO set size. Key features include its implementation via a soft fork for backward compatibility, minimal impact on consensus logic, and its focus on user consent, security, and economic rationale. The proposal, detailed on GitHub, represents a thoughtful strategy to improve Bitcoin's handling of dust UTXOs while seeking further community feedback to refine its approach. - 2025-03-13T12:55:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Proposal-for-Quantum-Resistant-Address-Migration-Protocol-QRAMP-BIP.xml b/static/bitcoin-dev/March_2025/combined_Proposal-for-Quantum-Resistant-Address-Migration-Protocol-QRAMP-BIP.xml index 28f5cf9021..a5d5739e08 100644 --- a/static/bitcoin-dev/March_2025/combined_Proposal-for-Quantum-Resistant-Address-Migration-Protocol-QRAMP-BIP.xml +++ b/static/bitcoin-dev/March_2025/combined_Proposal-for-Quantum-Resistant-Address-Migration-Protocol-QRAMP-BIP.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP - 2025-03-10T02:07:51.349334+00:00 - - ArmchairCryptologist 2025-03-09 09:19:00+00:00 - - - Agustin Cruz 2025-03-09 00:53:00+00:00 - - - Agustin Cruz 2025-03-07 18:42:00+00:00 - - - Michal Kolesár 2025-03-05 13:40:00+00:00 - - - Dustin Ray 2025-02-19 22:05:00+00:00 - - - Agustin Cruz 2025-02-19 21:49:00+00:00 - - - Dustin Ray 2025-02-19 21:35:00+00:00 - - - Agustin Cruz 2025-02-19 21:07:00+00:00 - - - Dustin Ray 2025-02-19 20:10:00+00:00 - - - Pieter Wuille 2025-02-19 17:56:00+00:00 - - - Agustin Cruz 2025-02-19 16:42:00+00:00 - - - Hunter Beast 2025-02-19 16:06:00+00:00 - - - Agustin Cruz 2025-02-12 00:54:00+00:00 - - - Dustin Ray 2025-02-12 00:47:00+00:00 - - - Agustin Cruz 2025-02-12 00:37:00+00:00 - - - Dustin Ray 2025-02-12 00:15:00+00:00 - - - Agustin Cruz 2025-02-11 22:36:00+00:00 - + 2025-09-26T14:37:28.840883+00:00 + python-feedgen + + + Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP Agustin Cruz + 2025-02-11T22:36:00.000Z + + + Dustin Ray + 2025-02-12T00:15:00.000Z + + + Agustin Cruz + 2025-02-12T00:37:00.000Z + + + Dustin Ray + 2025-02-12T00:47:00.000Z + + + Agustin Cruz + 2025-02-12T00:54:00.000Z + + + Hunter Beast + 2025-02-19T16:06:00.000Z + + + Agustin Cruz + 2025-02-19T16:42:00.000Z + + + Pieter Wuille + 2025-02-19T17:56:00.000Z + + + Dustin Ray + 2025-02-19T20:10:00.000Z + + + Agustin Cruz + 2025-02-19T21:07:00.000Z + + + Dustin Ray + 2025-02-19T21:35:00.000Z + + + Agustin Cruz + 2025-02-19T21:49:00.000Z + + + Dustin Ray + 2025-02-19T22:05:00.000Z + + + Michal Kolesár + 2025-03-05T13:40:00.000Z + + + Agustin Cruz + 2025-03-07T18:42:00.000Z + + + Agustin Cruz + 2025-03-09T00:53:00.000Z + + + ArmchairCryptologist' + 2025-03-09T09:19:00.000Z + + @@ -71,21 +91,17 @@ - python-feedgen + 2 Combined summary - Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP - 2025-03-10T02:07:51.349452+00:00 + 2025-09-26T14:37:28.842777+00:00 + 2025-03-09T09:19:00+00:00 The quantum computing era presents a formidable challenge to the current cryptographic underpinnings of Bitcoin, necessitating a proactive approach to ensure the long-term security and stability of the network. A mandatory migration to quantum-resistant addresses, as discussed in various segments of the community, emerges as a pivotal strategy to preempt potential threats. This transition, while crucial, is fraught with complexities, including the risk of high transaction fees due to limited block size and the potential for network flooding by parties benefiting from increased fees. Such dynamics underscore the importance of a carefully planned, possibly extended migration period to mitigate risks without imposing undue burdens on users. - The Quantum-Resistant Address Migration Protocol (QRAMP), coupled with the technical specifications outlined in BIP-360, represents a concerted effort to address these challenges. QRAMP proposes a structured migration framework, emphasizing the necessity of moving away from legacy ECDSA-based addresses before quantum capabilities render them vulnerable. This initiative underscores a broader commitment to preserving Bitcoin's foundational security without resorting to drastic measures that could erode trust or accessibility within the network. - Discussions highlight the nuanced debate surrounding the best path forward, balancing between enforced migrations with clear deadlines and more voluntary, incentivized approaches. The proposed hard deadline for transitioning funds to quantum-resistant addresses aims to circumvent the gradual erosion of security posed by quantum advancements. However, this approach raises concerns about the potential loss of funds, particularly those in dormant wallets or belonging to less active users. Alternatives, such as turnstile mechanisms for voluntary migration, offer a less coercive path, emphasizing user choice and gradual adaptation. - The technical and philosophical deliberations extend to considerations of how best to manage the transition without undermining Bitcoin’s core principles, such as autonomy, security, and fixed supply. The prospect of reactivating dormant coins through quantum exploitation introduces complex economic and ethical questions, particularly regarding the distribution and value of Bitcoin. These discussions encapsulate the broader tensions within the development community between innovation and preservation, highlighting the delicate balance required to navigate future threats. - Moreover, the discourse reflects an acute awareness of the timing and nature of quantum advancements, arguing for a preparedness strategy that evolves alongside technological progress. This includes developing and integrating quantum-resistant cryptographic mechanisms, ensuring the continuity of Bitcoin's operations, and safeguarding against both current and future vulnerabilities. The collaborative spirit evident in the proposals and discussions signifies a collective endeavor to fortify Bitcoin against the specter of quantum computing, ensuring its resilience in an uncertain digital age. - 2025-03-09T09:19:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Re-Against-Allowing-Quantum-Recovery-of-Bitcoin.xml b/static/bitcoin-dev/March_2025/combined_Re-Against-Allowing-Quantum-Recovery-of-Bitcoin.xml index 63bffa019e..0c6eb73f65 100644 --- a/static/bitcoin-dev/March_2025/combined_Re-Against-Allowing-Quantum-Recovery-of-Bitcoin.xml +++ b/static/bitcoin-dev/March_2025/combined_Re-Against-Allowing-Quantum-Recovery-of-Bitcoin.xml @@ -1,29 +1,143 @@ - + 2 Combined summary - Re: Against Allowing Quantum Recovery of Bitcoin - 2025-05-02T02:48:52.887179+00:00 - - Michael Tidwell 2025-04-30 15:40:00+00:00 - - - Nadav Ivgi 2025-04-06 14:07:00+00:00 - - - Ben Sigman 2025-04-04 04:49:00+00:00 - - - Javier Mateos 2025-03-30 22:23:00+00:00 - - - Matt Corallo 2025-03-28 20:00:00+00:00 - - - Sjors Provoost 2025-03-25 08:16:00+00:00 - - - Matt Corallo 2025-03-25 01:06:00+00:00 - + 2025-09-26T14:37:37.481624+00:00 + python-feedgen + + + Jameson Lopp + 2025-03-16T14:15:00.000Z + + + Chris Riley + 2025-03-16T18:03:00.000Z + + + Nagaev Boris + 2025-03-16T19:44:00.000Z + + + Jameson Lopp + 2025-03-16T21:25:00.000Z + + + IdeA + 2025-03-16T22:56:00.000Z + + + Matt Corallo + 2025-03-17T12:00:00.000Z + + + Jameson Lopp + 2025-03-17T13:28:00.000Z + + + Sjors Provoost + 2025-03-18T12:48:00.000Z + + + Against Allowing Quantum Recovery of Bitcoin AstroTown + 2025-03-22T19:02:00.000Z + + + Agustin Cruz + 2025-03-24T11:19:00.000Z + + + Matt Corallo + 2025-03-25T01:06:00.000Z + + + Sjors Provoost + 2025-03-25T08:16:00.000Z + + + Matt Corallo + 2025-03-28T20:00:00.000Z + + + Javier Mateos + 2025-03-30T22:23:00.000Z + + + Ben Sigman' + 2025-04-04T04:49:00.000Z + + + Nadav Ivgi + 2025-04-06T14:07:00.000Z + + + Michael Tidwell + 2025-04-30T15:40:00.000Z + + + conduition' + 2025-05-25T19:03:00.000Z + + + Dustin Ray + 2025-05-25T23:03:00.000Z + + + Agustin Cruz + 2025-05-26T00:32:00.000Z + + + ArmchairCryptologist' + 2025-05-26T15:40:00.000Z + + + waxwing/ AdamISZ + 2025-05-28T01:07:00.000Z + + + Sjors Provoost + 2025-05-28T07:46:00.000Z + + + waxwing/ AdamISZ + 2025-05-28T21:15:00.000Z + + + waxwing/ AdamISZ + 2025-06-07T13:28:00.000Z + + + Jameson Lopp + 2025-06-08T14:04:00.000Z + + + Boris Nagaev + 2025-07-13T01:39:00.000Z + + + Jameson Lopp + 2025-07-13T12:34:00.000Z + + + Boris Nagaev + 2025-07-13T14:20:00.000Z + + + Ethan Heilman + 2025-07-13T16:01:00.000Z + + + Boris Nagaev + 2025-07-13T17:51:00.000Z + + + Pieter Wuille + 2025-07-13T19:28:00.000Z + + + Jameson Lopp + 2025-07-13T21:26:00.000Z + + @@ -31,23 +145,18 @@ - python-feedgen + 2 Combined summary - Re: Against Allowing Quantum Recovery of Bitcoin - 2025-05-02T02:48:52.887242+00:00 + 2025-09-26T14:37:37.485621+00:00 + 2025-04-30T15:40:00+00:00 The ongoing discussions within the Bitcoin development community highlight a proactive approach towards securing the cryptocurrency against potential quantum computing threats. A significant emphasis is placed on the introduction of post-quantum cryptographic (PQC) mechanisms to safeguard Bitcoin from vulnerabilities posed by quantum attackers. The innovative strategies proposed range from implementing soft forks that mandate certain transaction conditions to integrating new cryptographic standards. These proposals aim not only to enhance security but also to ensure the stability and functionality of the blockchain in the face of evolving technological threats. - One notable proposal involves adjusting the Bitcoin protocol to make it resilient against quantum attacks by introducing a system where transactions involving quantum-vulnerable coins allocate a major portion of the funds to timelocked outputs. This method proposes locking 99% of such funds for periods between 10 to 100 years, with the intention of delaying their usage and preventing market flooding. The remaining 1% would be freely spendable but also subject to a timelock, aiming to regulate its entry into the market and mitigate impacts on Bitcoin's value. This approach seeks to balance the need for security with the desire to avoid rewarding malicious actors excessively, thereby preserving market integrity. - The conversation extends to various methods for transitioning Bitcoin into a quantum-resistant state, including the introduction of rolling timeouts and quantum doomsday clocks. Amid these technical discussions, there's a consensus on the urgency of adopting PQC standards to protect against quantum vulnerabilities. Proposals like BIP 360 and adaptations of Taproot PQC are being considered, indicating a community-driven effort to evolve Bitcoin's cryptographic foundation. This phase marks a critical juncture in Bitcoin's development, underscoring the necessity of adaptation to maintain its resilience against future technological advances. - A strategic, phased approach to transitioning to quantum-resistant signatures has been suggested to mitigate risks without causing upheaval within the Bitcoin community. This includes allowing users to attach optional PQC keys to Taproot addresses as an immediate measure, followed by a soft fork to disable vulnerable signatures, incorporating a migration period for a smooth transition. The final stage involves phasing out old signatures gradually, accompanied by incentives to encourage adoption of secure transactions. This method emphasizes communication and inclusivity, aiming to facilitate a seamless transition without inducing panic or coercion among users. - Furthermore, Matt Corallo's proposition for a Probabilistic Check Quantum (PCQ) scheme introduces a nuanced approach to address concerns over asset freezes due to policy changes in key path spending. By offering a solution that minimizes disruption while maintaining user trust, this proposal reflects a deep understanding of the balance required between innovation and ensuring asset stability. It highlights the broader concern within the cryptocurrency community regarding how technological advancements might influence asset perception and value. - Lastly, the discourse acknowledges the challenges of adopting post-quantum schemes, emphasizing the importance of a freeze fork to preemptively secure Bitcoin against quantum computing threats. This discussion points to a growing recognition within the community of the need for PQC capabilities, driven by both current interest and the anticipation of future demands. Skepticism towards arguments against the adoption of PQC solutions underscores the ongoing debates and concerns about future-proofing Bitcoin in an era of rapidly advancing quantum computing technologies. - 2025-04-30T15:40:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Slashing-covenants.xml b/static/bitcoin-dev/March_2025/combined_Slashing-covenants.xml index cefe4b9a42..7981186235 100644 --- a/static/bitcoin-dev/March_2025/combined_Slashing-covenants.xml +++ b/static/bitcoin-dev/March_2025/combined_Slashing-covenants.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Slashing covenants - 2025-03-25T02:33:51.915511+00:00 - - Ethan Heilman 2025-03-24 21:51:00+00:00 - - - Hunter Beast 2025-03-24 13:41:00+00:00 - - - Ethan Heilman 2024-11-24 21:13:00+00:00 - + 2025-09-26T14:37:33.072977+00:00 + python-feedgen + + + Slashing covenants Ethan Heilman + 2024-11-24T21:13:00.000Z + + + Hunter Beast + 2025-03-24T13:41:00.000Z + + + Ethan Heilman + 2025-03-24T21:51:00.000Z + + - python-feedgen + 2 Combined summary - Slashing covenants - 2025-03-25T02:33:51.915555+00:00 + 2025-09-26T14:37:33.073616+00:00 + 2025-03-24T21:51:00+00:00 Slashing covenants offer an innovative enforcement mechanism for Bitcoin transactions, diverging from traditional methods that prevent the spending of outputs against covenant conditions. Instead, this protocol allows transactions to proceed but imposes financial penalties on violators who breach established rules, marking a less secure but more efficient alternative than employing specific opcodes for direct prevention. This approach leverages existing Bitcoin script capabilities and Lamport signatures to verify authenticity without necessitating complex cryptographic operations within the script. It operates on a two-part script system: the first part ensures covenant adherence if the spending signature matches its encoded counterpart, and the second part punishes discrepancies by enabling anyone to slash the violator's funds through costly transactions. - The discussion highlights the potential benefits of slashing covenants over traditional enforcement methods like BitVM, emphasizing their efficiency, compatibility with current infrastructure, and absence of new cryptographic assumptions. While initially compared to BitVM, it was clarified that BitVM does not utilize this precise strategy. The mechanism behind slashing covenants focuses on proving the identity of two signatures—one verified by Bitcoin’s CHECKSIGVERIFY and another through a simplified script—without direct comparison. This is seen as a significant innovation that maintains security through cryptoeconomic incentives, reminiscent of how bitcoin mining operates. Despite its reliance on financial disincentives rather than outright prevention, the method is deemed sufficient for maintaining transaction integrity within the Bitcoin network. - Furthermore, while the concept is tailored for Bitcoin, it is noted that implementation might be simpler on platforms like Ethereum due to their flexible nature. The conversation also opens up possibilities for expanding this model to support dynamic cosigner groups with advanced cryptographic proofs, potentially enhancing the resilience and applicability of covenants in blockchain systems. This exploration into slashing covenants exemplifies the ongoing search for balance between security and practicality in cryptocurrency protocols, highlighting both the challenges and innovations arising from the unique constraints of decentralized networks. - 2025-03-24T21:51:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Standard-Unstructured-Annex.xml b/static/bitcoin-dev/March_2025/combined_Standard-Unstructured-Annex.xml index 635969fb01..e7c2e09371 100644 --- a/static/bitcoin-dev/March_2025/combined_Standard-Unstructured-Annex.xml +++ b/static/bitcoin-dev/March_2025/combined_Standard-Unstructured-Annex.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Standard Unstructured Annex - 2025-04-30T02:51:38.262133+00:00 - - Peter Todd 2025-04-29 02:59:00+00:00 - - - Russell OConnor 2025-04-28 16:25:00+00:00 - - - Russell OConnor 2025-04-28 16:13:00+00:00 - - - Antoine Riard 2025-04-09 22:55:00+00:00 - - - Peter Todd 2025-03-24 16:17:00+00:00 - - - Antoine Riard 2025-03-20 22:47:00+00:00 - - - Peter Todd 2025-03-20 00:27:00+00:00 - + 2025-09-26T14:37:24.566981+00:00 + python-feedgen + + + Standard Unstructured Annex Peter Todd + 2025-03-20T00:27:00.000Z + + + Antoine Riard + 2025-03-20T22:47:00.000Z + + + Peter Todd + 2025-03-24T16:17:00.000Z + + + Antoine Riard + 2025-04-09T22:55:00.000Z + + + Russell O'Connor' + 2025-04-28T16:13:00.000Z + + + Russell O'Connor' + 2025-04-28T16:25:00.000Z + + + Peter Todd + 2025-04-29T02:59:00.000Z + + @@ -31,21 +41,17 @@ - python-feedgen + 2 Combined summary - Standard Unstructured Annex - 2025-04-30T02:51:38.262195+00:00 + 2025-09-26T14:37:24.567904+00:00 + 2025-04-29T02:59:00+00:00 The discussion primarily focuses on a new rule proposal regarding the use of annexes within Bitcoin transactions. It introduces a stipulation that if any input within a transaction includes an annex, then all inputs must feature an annex, albeit they can be empty. This standardization aims to streamline transaction validation processes by enforcing a consistent approach to handling annexes, potentially simplifying the protocol's operation and enhancing its efficiency. The rule is designed to facilitate a uniform method for indicating approval of annex usage across transactions, distinguishing between having no annex and a zero-byte annex in an attempt to standardize participation in such transactions. - Further elaboration within the discussion addresses concerns around the potential for transaction pinning attacks in multi-party protocols due to the manipulation of annex sizes. The inclusion of an annex in each input does not inherently prevent a party from broadcasting a version of the transaction that is heavier and has a lower fee rate, which could complicate the transaction process. There's a dialogue about the need for strategies, like full Replace-By-Fee (RBF), to mitigate these risks, indicating ongoing explorations into more effective measures against such vulnerabilities. - An additional point of interest is the proposition of encoding schemes and versioning within Bitcoin's evolving framework, particularly in light of the Taproot upgrade. The suggested inclusion of a one-byte version number in payload data offers applications greater flexibility and domain separation, encouraging innovation while maintaining compatibility with future protocol enhancements. This approach reflects a broader movement towards refining Bitcoin's infrastructure to support complex functionalities and improve user experience through standardization and upgradability. - The conversation also touches on the emerging consensus favoring a tag-length-value (TLV) encoding scheme for annex data, highlighting the ongoing efforts to standardize and enhance functionality within the blockchain domain. This shift underscores the technological progress being made towards achieving a consensus on encoding practices, aiming to facilitate application upgrades and improve system interoperability. The proactive stance on integrating mechanisms to defend against potential annex-related exploits, such as witness-RBF combined with replace-by-fee-rate tactics, exemplifies the commitment to securing and advancing the network's capabilities. - Lastly, the discussion delves into the integration of taproot annex support, emphasizing the requirement for initiating all non-empty annexes with byte 0x00 to distinguish them from future consensus-relevant annexes. This measure seeks to ensure compatibility with potential soft-forks and maintain the integrity of the network's operations. The specification that all inputs must have an annex, serving as an opt-in feature, is highlighted as a crucial step towards mitigating the risk of transaction pinning attacks, reflecting the ongoing evolution of policies to enhance network security and efficiency. - 2025-04-29T02:59:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Table-for-economic-nodes-Covenants-Support-Bitcoin-Wiki.xml b/static/bitcoin-dev/March_2025/combined_Table-for-economic-nodes-Covenants-Support-Bitcoin-Wiki.xml index 3df95af849..034329c5e9 100644 --- a/static/bitcoin-dev/March_2025/combined_Table-for-economic-nodes-Covenants-Support-Bitcoin-Wiki.xml +++ b/static/bitcoin-dev/March_2025/combined_Table-for-economic-nodes-Covenants-Support-Bitcoin-Wiki.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - Table for economic nodes: Covenants Support - Bitcoin Wiki - 2025-03-06T02:27:45.328547+00:00 - - /dev /fd0 2025-03-05 13:32:00+00:00 - - - /dev /fd0 2025-03-05 09:39:00+00:00 - + 2025-09-26T14:37:22.456622+00:00 + python-feedgen + + + Table for economic nodes: Covenants Support - Bitcoin Wiki /dev /fd0 + 2025-03-05T09:39:00.000Z + + + /dev /fd0 + 2025-03-05T13:32:00.000Z + + - python-feedgen + 2 Combined summary - Table for economic nodes: Covenants Support - Bitcoin Wiki - 2025-03-06T02:27:45.328588+00:00 + 2025-09-26T14:37:22.457082+00:00 + 2025-03-05T13:32:00+00:00 The recent communication highlights the ongoing development and discussion surrounding the implementation of covenants in Bitcoin's infrastructure. Covenants, a concept gaining traction within the cryptocurrency community, are tools designed to provide enhanced control over transactions. A comprehensive list of potential use cases for covenants, still a work in progress, has been made available through a dedicated wiki page. This initiative underscores the collaborative effort among developers to explore and evaluate the practical applications of covenants, positing them as potentially transformative elements within Bitcoin’s ecosystem. - Significant contributions from developers Matt Black, Jeremy Rubin, and stutxo have enriched the covenants' use cases wiki page, demonstrating a collective endeavor to scrutinize and refine the utility of covenants. The documentation and evaluation of these use cases are critical steps toward understanding the implications and operational feasibility of covenants in real-world scenarios. The call for input from economic nodes represents an essential phase in this developmental journey, aiming to incorporate a wider spectrum of insights and perspectives. Engaging economic nodes in the discourse is pivotal for assessing the broader implications and acceptance of covenants across different stakeholders within the Bitcoin network. - The progression of this dialogue into more structured forms of discussion, such as IRC meetings and workshops, indicates a move towards consensus and actionable insights. This structured approach to gathering feedback and fostering open discussions is instrumental in ensuring that the exploration of covenants is grounded in practicality and informed by diverse viewpoints. The effort to centralize and disseminate information through resources like the [covenants support wiki](https://en.bitcoin.it/wiki/Covenants_support) and the [list of use cases for covenants](https://en.bitcoin.it/wiki/Covenants_Uses) reflects a commitment to transparency and inclusivity in the development process. Such resources not only facilitate information sharing but also encourage active participation from the community, underscoring the importance of collective expertise and collaboration in shaping the future of Bitcoin. - 2025-03-05T13:32:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_The-Future-of-Bitcoin-Testnet.xml b/static/bitcoin-dev/March_2025/combined_The-Future-of-Bitcoin-Testnet.xml index 45054a7a94..439cacb080 100644 --- a/static/bitcoin-dev/March_2025/combined_The-Future-of-Bitcoin-Testnet.xml +++ b/static/bitcoin-dev/March_2025/combined_The-Future-of-Bitcoin-Testnet.xml @@ -1,134 +1,179 @@ - + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303256+00:00 - - Saint Wenhao 2025-04-25 17:19:00+00:00 - - - Garlo Nicon 2025-03-31 10:48:00+00:00 - - - Peter Todd 2024-05-04 17:13:00+00:00 - - - Peter Todd 2024-05-04 17:08:00+00:00 - - - Ali Sherief 2024-05-02 07:10:00+00:00 - - - Garlo Nicon 2024-05-01 15:30:00+00:00 - - - Matthew Bagazinski 2024-04-30 18:46:00+00:00 - - - Matt Corallo 2024-04-28 13:45:00+00:00 - - - Ali Sherief 2024-04-22 04:33:00+00:00 - - - Sjors Provoost 2024-04-16 17:30:00+00:00 - - - Garlo Nicon 2024-04-10 06:57:00+00:00 - - - Garlo Nicon 2024-04-09 18:28:00+00:00 - - - Peter Todd 2024-04-09 16:48:00+00:00 - - - coinableS 2024-04-09 04:29:00+00:00 - - - Garlo Nicon 2024-04-08 19:11:00+00:00 - - - K Calvin 2024-04-07 08:09:00+00:00 - - - Christian Decker 2024-04-07 07:20:00+00:00 - - - David A. Harding 2024-04-06 23:04:00+00:00 - - - Calvin Kim 2024-04-05 04:30:00+00:00 - - - Jameson Lopp 2024-04-04 12:47:00+00:00 - - - Calvin Kim 2024-04-04 08:14:00+00:00 - - - Andrew Poelstra 2024-04-03 19:35:00+00:00 - - - emsit 2024-04-03 18:18:00+00:00 - - - Anthony Towns 2024-04-03 04:19:00+00:00 - - - Jameson Lopp 2024-04-02 19:46:00+00:00 - - - Lukáš Kráľ 2024-04-02 18:36:00+00:00 - - - Jameson Lopp 2024-04-02 11:53:00+00:00 - - - Fabian 2024-04-01 22:01:00+00:00 - - - emsit 2024-04-01 19:22:00+00:00 - - - Warren Togami 2024-04-01 14:28:00+00:00 - - - Andrew Poelstra 2024-04-01 14:20:00+00:00 - - - Pieter Wuille 2024-04-01 13:37:00+00:00 - - - Fabian 2024-04-01 13:32:00+00:00 - - - Peter Todd 2024-04-01 13:25:00+00:00 - - - Jameson Lopp 2024-04-01 12:54:00+00:00 - - - Peter Todd 2024-03-31 21:29:00+00:00 - - - Nagaev Boris 2024-03-31 21:01:00+00:00 - - - Eric Voskuil 2024-03-31 17:21:00+00:00 - - - Peter Todd 2024-03-31 16:02:00+00:00 - - - Jameson Lopp 2024-03-31 14:57:00+00:00 - - - Luke Dashjr 2024-03-31 14:33:00+00:00 - - - Jameson Lopp 2024-03-31 13:19:00+00:00 - + 2025-09-26T14:37:58.964965+00:00 + python-feedgen + + + The Future of Bitcoin Testnet Jameson Lopp + 2024-03-31T13:19:00.000Z + + + Luke Dashjr + 2024-03-31T14:33:00.000Z + + + Jameson Lopp + 2024-03-31T14:57:00.000Z + + + Peter Todd + 2024-03-31T16:02:00.000Z + + + Eric Voskuil + 2024-03-31T17:21:00.000Z + + + Nagaev Boris + 2024-03-31T21:01:00.000Z + + + Peter Todd + 2024-03-31T21:29:00.000Z + + + Jameson Lopp + 2024-04-01T12:54:00.000Z + + + Andrew Poelstra + 2024-04-01T13:25:00.000Z + + + Fabian' + 2024-04-01T13:32:00.000Z + + + Pieter Wuille + 2024-04-01T13:37:00.000Z + + + Andrew Poelstra + 2024-04-01T14:20:00.000Z + + + Warren Togami + 2024-04-01T14:28:00.000Z + + + emsit + 2024-04-01T19:22:00.000Z + + + Fabian' + 2024-04-01T22:01:00.000Z + + + Jameson Lopp + 2024-04-02T11:53:00.000Z + + + Lukáš Kráľ + 2024-04-02T18:36:00.000Z + + + Jameson Lopp + 2024-04-02T19:46:00.000Z + + + Anthony Towns + 2024-04-03T04:19:00.000Z + + + emsit + 2024-04-03T18:18:00.000Z + + + Andrew Poelstra + 2024-04-03T19:35:00.000Z + + + Calvin Kim + 2024-04-04T08:14:00.000Z + + + Jameson Lopp + 2024-04-04T12:47:00.000Z + + + Calvin Kim + 2024-04-05T04:30:00.000Z + + + David A. Harding + 2024-04-06T23:04:00.000Z + + + Christian Decker + 2024-04-07T07:20:00.000Z + + + K Calvin + 2024-04-07T08:09:00.000Z + + + Garlo Nicon + 2024-04-08T19:11:00.000Z + + + coinableS + 2024-04-09T04:29:00.000Z + + + Peter Todd + 2024-04-09T16:48:00.000Z + + + Garlo Nicon + 2024-04-09T18:28:00.000Z + + + Garlo Nicon + 2024-04-10T06:57:00.000Z + + + Sjors Provoost' + 2024-04-16T17:30:00.000Z + + + Ali Sherief + 2024-04-22T04:33:00.000Z + + + Matt Corallo + 2024-04-28T13:45:00.000Z + + + Matthew Bagazinski + 2024-04-30T18:46:00.000Z + + + Garlo Nicon + 2024-05-01T15:30:00.000Z + + + Ali Sherief + 2024-05-02T07:10:00.000Z + + + Peter Todd + 2024-05-04T17:08:00.000Z + + + Peter Todd + 2024-05-04T17:13:00.000Z + + + Garlo Nicon + 2025-03-31T10:48:00.000Z + + + Saint Wenhao + 2025-04-25T17:19:00.000Z + + @@ -171,17 +216,15 @@ - python-feedgen + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303535+00:00 + 2025-09-26T14:37:58.969140+00:00 + 2025-04-25T17:19:00+00:00 The discourse surrounding the future and functionality of Bitcoin's testnet3 brings to light several pressing issues and proposals for its evolution. Testnet3, after 13 years of operation and reaching a block height of approximately 2.5 million, finds itself at a crossroads due to a significantly reduced block reward and operational challenges arising from an edge case bug that resets the mining difficulty to one. This anomaly has led to operational inconsistencies and raised concerns about the effective distribution of testnet coins, as detailed in Jameson Lopp’s comprehensive analysis available [here](https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/). Furthermore, the network faces exploitation through scammy airdrops and an unintended marketplace where TBTC is actively traded, deviating from its foundational principle that testnet coins should hold no real-world value. - In response to these challenges, several key questions and proposals are presented to the community. The potential for a testnet reset is considered, recognizing the need for substantial notice due to the extensive updates required for production systems. Additionally, addressing the difficulty reset bug emerges as a priority, with suggestions for a straightforward code fix that might necessitate a hard fork. This approach, while potentially disruptive, could naturally integrate into the network's dynamics if executed thoughtfully. The necessity of formalizing this process through a Bitcoin Improvement Proposal (BIP) or adopting a more informal implementation strategy remains a point of debate. - Moreover, the discussion extends to the possibility of deprecating testnet3 in favor of signet, highlighting an ongoing exploration of alternative testing environments that might better serve the needs of the Bitcoin development community. This conversation reflects a broader debate on balancing innovation and stability within Bitcoin's development platforms, emphasizing the importance of community feedback and collaborative decision-making in navigating the future of testnet3. The dialogue ultimately underscores the complexities of managing blockchain networks like Bitcoin, where technical adjustments must consider both their immediate impact and broader implications for developers, miners, and the ecosystem at large. - 2025-04-25T17:19:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Time-to-add-CSFS-to-Signet-.xml b/static/bitcoin-dev/March_2025/combined_Time-to-add-CSFS-to-Signet-.xml index 19abe70228..5dc75975f4 100644 --- a/static/bitcoin-dev/March_2025/combined_Time-to-add-CSFS-to-Signet-.xml +++ b/static/bitcoin-dev/March_2025/combined_Time-to-add-CSFS-to-Signet-.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Time to add CSFS to Signet? - 2025-03-27T02:36:07.369596+00:00 - - Greg Sanders 2025-03-26 13:36:00+00:00 - - - moonsettler 2025-03-26 11:54:00+00:00 - - - Greg Sanders 2025-03-20 13:10:00+00:00 - - - moonsettler 2025-03-18 16:40:00+00:00 - - - Weikeng Chen 2025-03-18 06:55:00+00:00 - - - moonsettler 2025-03-17 22:52:00+00:00 - - - /dev /fd 2025-03-17 14:43:00+00:00 - - - Weikeng Chen 2025-03-17 14:11:00+00:00 - - - Weikeng Chen 2025-03-17 03:38:00+00:00 - + 2025-09-26T14:37:30.960320+00:00 + python-feedgen + + + Time to add CSFS to Signet? Weikeng Chen + 2025-03-17T03:38:00.000Z + + + Antoine Poinsot' + 2025-03-17T14:11:00.000Z + + + /dev /fd0 + 2025-03-17T14:43:00.000Z + + + moonsettler' + 2025-03-17T22:52:00.000Z + + + Weikeng Chen + 2025-03-18T06:55:00.000Z + + + moonsettler' + 2025-03-18T16:40:00.000Z + + + Greg Sanders + 2025-03-20T13:10:00.000Z + + + moonsettler' + 2025-03-26T11:54:00.000Z + + + Greg Sanders + 2025-03-26T13:36:00.000Z + + @@ -39,23 +51,18 @@ - python-feedgen + 2 Combined summary - Time to add CSFS to Signet? - 2025-03-27T02:36:07.369669+00:00 + 2025-09-26T14:37:30.961403+00:00 + 2025-03-26T13:36:00+00:00 The email exchange on the Bitcoin Development Mailing List reveals discussions and developments regarding the compliance of the Commitment Signed Fixed Sequence (CSFS) implemented in mutinynet with BIP348 standards. The sender points out that while the non-compliance may not affect all users, adhering to established standards is crucial. To address this, a proactive step has been taken through a Pull Request on inquisition to align mutinynet's features with Bitcoin Improvement Proposals, indicating an effort to maintain community and technical standards within the Bitcoin development ecosystem. - Further, the conversation delves into the utility of signets for protocol developers and users, highlighting the ongoing efforts to enhance testing frameworks. There is particular interest in activating LNhance on a testnet, suggesting benefits to the testing environment through this feature. This discussion emphasizes the Bitcoin development community's commitment to improving testing frameworks, showcasing an endeavor to implement innovative features like LNhance for a more effective testing process. - -An inquiry from Weikeng explores the strategic addition of "mutinynet" into the existing "signet" for further testing, indicating its readiness for broader developmental use. This highlights the community's approach toward enhancing network functionality and security, reflecting careful consideration of timing and integration strategies to improve the Bitcoin protocol effectively. The mention of "mutinynet" and "signet" illustrates a multifaceted approach to development and testing, aiming to fine-tune updates before wider rollouts. - +An inquiry from Weikeng explores the strategic addition of "mutinynet" into the existing "signet" for further testing, indicating its readiness for broader developmental use. This highlights the community's approach toward enhancing network functionality and security, reflecting careful consideration of timing and integration strategies to improve the Bitcoin protocol effectively. The mention of "mutinynet" and "signet" illustrates a multifaceted approach to development and testing, aiming to fine-tune updates before wider rollouts. Significant advancements are discussed concerning the Cryptographic Secure Feature Set (CSFS) and new LNhance opcodes on Signet and Mutinynet platforms. These platforms serve as testing environments for these features, with details provided for developers interested in exploring these innovations. A GitHub link ([this GitHub link](https://github.com/lnhance/mutinynet-bitcoin/tree/mutinynet-cat-ln-hance)) and resources like the Mutinynet faucet ([this link](https://faucet.mutinynet.com/)) are made available, illustrating a proactive approach towards enhancing Bitcoin through innovative features and comprehensive testing. - The support for CSFS among Bitcoin developers is highlighted, with no objections noted from over 50 developers. Christian Decker's endorsement adds weight to the proposal, emphasizing the positive reception and potential significance of CSFS within the Bitcoin ecosystem. This consensus-building underscores the collaborative process aimed at enhancing Bitcoin's functionality and efficiency. - Lastly, the potential integration of CSFS with CTV on Signet, facilitating experiments related to LNHANCE, is explored. This integration could advance BitVM operations by replacing Winternitz signatures, reducing on-chain data availability overhead. This discussion reflects the Bitcoin Development community's forward-looking approach to blockchain development and experimentation, emphasizing collaborative input in the development process. - 2025-03-26T13:36:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_UTXO-probing-attack-using-payjoin.xml b/static/bitcoin-dev/March_2025/combined_UTXO-probing-attack-using-payjoin.xml index d3f5be41b3..20136623f8 100644 --- a/static/bitcoin-dev/March_2025/combined_UTXO-probing-attack-using-payjoin.xml +++ b/static/bitcoin-dev/March_2025/combined_UTXO-probing-attack-using-payjoin.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - UTXO probing attack using payjoin - 2025-04-01T03:01:33.543778+00:00 - - /dev /fd0 2025-03-29 13:00:00+00:00 - - - /dev /fd0 2025-03-29 12:34:00+00:00 - - - Yuval Kogman 2025-03-28 23:41:00+00:00 - - - waxwing/ AdamISZ 2025-03-28 19:28:00+00:00 - - - /dev /fd 2025-03-26 19:38:00+00:00 - - - /dev /fd 2025-03-26 19:26:00+00:00 - - - Yuval Kogman 2025-03-25 13:39:00+00:00 - - - jbesraa 2025-03-25 12:52:00+00:00 - - - /dev /fd 2025-03-25 11:46:00+00:00 - + 2025-09-26T14:37:26.679545+00:00 + python-feedgen + + + UTXO probing attack using payjoin /dev /fd0 + 2025-03-25T11:46:00.000Z + + + jbesraa + 2025-03-25T12:52:00.000Z + + + Yuval Kogman + 2025-03-25T13:39:00.000Z + + + /dev /fd0 + 2025-03-26T19:26:00.000Z + + + /dev /fd0 + 2025-03-26T19:38:00.000Z + + + waxwing/ AdamISZ + 2025-03-28T19:28:00.000Z + + + Yuval Kogman + 2025-03-28T23:41:00.000Z + + + /dev /fd0 + 2025-03-29T12:34:00.000Z + + + /dev /fd0 + 2025-03-29T13:00:00.000Z + + @@ -39,19 +51,16 @@ - python-feedgen + 2 Combined summary - UTXO probing attack using payjoin - 2025-04-01T03:01:33.543868+00:00 + 2025-09-26T14:37:26.680606+00:00 + 2025-03-29T13:00:00+00:00 The discourse surrounding the Payjoin protocol underlines significant privacy considerations and technical challenges in the realm of Bitcoin transactions. Payjoin, designed to enhance transaction privacy by allowing the receiver to participate actively in the transaction process, has been scrutinized for its potential vulnerabilities, particularly UTXO probing attacks. These attacks exploit Payjoin's privacy mechanisms to discreetly gather information about a recipient's wallet contents, posing notable privacy risks. Countermeasures against such probing attempts include the recipient's ability to validate and potentially broadcast the initial transaction, introducing costs and complexities for attackers. Despite these measures, the dialogue recommends limiting Payjoin transactions to trusted parties, acknowledging the inherent trade-offs in privacy when engaging in such transactions. - Further discussion reveals implementation nuances and broader implications for Bitcoin's privacy and scalability. The conversation diverges into the technicalities of various BIPs (Bitcoin Improvement Proposals) related to Payjoin, highlighting strategies to mitigate risks associated with UTXO enumeration and deanonymization attacks. Notably, there's an emphasis on educating users about the complexity of privacy tools, suggesting that privacy should not be perceived as a binary attribute but rather as a spectrum that requires nuanced understanding and careful navigation. - The dialogue also touches upon historical perspectives on Bitcoin privacy, correcting misconceptions about pioneering research and its contributions to the field. This reflection on academic works underscores the ongoing evolution in approaches to enhancing transaction privacy within the Bitcoin ecosystem. Moreover, practical insights from testing Payjoin transactions using specific wallets like BullBitcoin illustrate the operational realities and potential implications of engaging in Payjoin transactions, reinforcing the notion that such activities should be approached with caution and preferably limited to interactions within trusted networks. - In summary, the discussions captured in the mailing list provide a comprehensive examination of Payjoin's potential, limitations, and the continuous effort to balance privacy enhancements with the practical challenges they introduce. Through detailed technical analyses, implementation feedback, and reflections on the broader context of Bitcoin transaction privacy, the dialogue contributes valuable insights into the evolving landscape of cryptocurrency privacy measures. - 2025-03-29T13:00:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Unbreaking-testnet4.xml b/static/bitcoin-dev/March_2025/combined_Unbreaking-testnet4.xml index 126bc0ac4c..d1e112f45f 100644 --- a/static/bitcoin-dev/March_2025/combined_Unbreaking-testnet4.xml +++ b/static/bitcoin-dev/March_2025/combined_Unbreaking-testnet4.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Unbreaking testnet4 - 2025-07-06T03:04:39.614598+00:00 - - Garlo Nicon 2025-07-05 04:31:00+00:00 - - - Saint Wenhao 2025-05-17 05:11:00+00:00 - - - pithosian 2025-05-12 20:19:00+00:00 - - - Saint Wenhao 2025-05-12 18:17:00+00:00 - - - pithosian 2025-05-12 12:05:00+00:00 - - - Anthony Towns 2025-05-12 05:21:00+00:00 - - - Garlo Nicon 2025-05-09 13:07:00+00:00 - - - Saint Wenhao 2025-05-06 11:48:00+00:00 - - - Greg Maxwell 2025-05-05 22:25:00+00:00 - - - Sjors Provoost 2025-04-28 18:50:00+00:00 - - - Saint Wenhao 2025-04-28 18:15:00+00:00 - - - Saint Wenhao 2025-04-28 13:33:00+00:00 - - - Sjors Provoost 2025-04-28 12:47:00+00:00 - - - emsit 2025-04-28 11:59:00+00:00 - - - pithosian 2025-04-28 11:48:00+00:00 - - - Jameson Lopp 2025-04-28 10:45:00+00:00 - - - Saint Wenhao 2025-04-28 06:11:00+00:00 - - - Jameson Lopp 2025-04-27 22:49:00+00:00 - - - Saint Wenhao 2025-04-27 11:44:00+00:00 - - - Saint Wenhao 2025-03-31 07:32:00+00:00 - - - Antoine Poinsot 2025-03-24 13:57:00+00:00 - - - Murch 2025-03-24 12:25:00+00:00 - - - Garlo Nicon 2025-03-24 07:00:00+00:00 - - - Murch 2025-03-21 21:20:00+00:00 - - - Melvin Carvalho 2025-03-20 18:58:00+00:00 - - - bitcoindevml.void 2025-03-19 17:03:00+00:00 - - - Melvin Carvalho 2025-03-19 09:11:00+00:00 - - - Garlo Nicon 2025-03-19 08:43:00+00:00 - - - Sjors Provoost 2025-03-19 08:32:00+00:00 - - - Sjors Provoost 2025-03-19 07:56:00+00:00 - - - Melvin Carvalho 2025-03-19 07:01:00+00:00 - - - Antoine Poinsot 2025-03-18 21:34:00+00:00 - - - Antoine Poinsot 2025-03-18 14:29:00+00:00 - + 2025-09-26T14:37:43.974662+00:00 + python-feedgen + + + Unbreaking testnet4 'Antoine Poinsot' + 2025-03-18T14:29:00.000Z + + + Melvin Carvalho + 2025-03-18T21:34:00.000Z + + + Garlo Nicon + 2025-03-19T07:01:00.000Z + + + Sjors Provoost + 2025-03-19T07:56:00.000Z + + + Sjors Provoost + 2025-03-19T08:32:00.000Z + + + Garlo Nicon + 2025-03-19T08:43:00.000Z + + + Melvin Carvalho + 2025-03-19T09:11:00.000Z + + + bitcoin-dev-ml.void867 + 2025-03-19T17:03:00.000Z + + + Melvin Carvalho + 2025-03-20T18:58:00.000Z + + + Murch + 2025-03-21T21:20:00.000Z + + + Garlo Nicon + 2025-03-24T07:00:00.000Z + + + Murch + 2025-03-24T12:25:00.000Z + + + Antoine Poinsot' + 2025-03-24T13:57:00.000Z + + + Saint Wenhao + 2025-03-31T07:32:00.000Z + + + Saint Wenhao + 2025-04-27T11:44:00.000Z + + + Jameson Lopp + 2025-04-27T22:49:00.000Z + + + Saint Wenhao + 2025-04-28T06:11:00.000Z + + + Jameson Lopp + 2025-04-28T10:45:00.000Z + + + pithosian + 2025-04-28T11:48:00.000Z + + + emsit' + 2025-04-28T11:59:00.000Z + + + Sjors Provoost + 2025-04-28T12:47:00.000Z + + + Saint Wenhao + 2025-04-28T13:33:00.000Z + + + Saint Wenhao + 2025-04-28T18:15:00.000Z + + + Sjors Provoost + 2025-04-28T18:50:00.000Z + + + Greg Maxwell + 2025-05-05T22:25:00.000Z + + + Saint Wenhao + 2025-05-06T11:48:00.000Z + + + Garlo Nicon + 2025-05-09T13:07:00.000Z + + + Anthony Towns + 2025-05-12T05:21:00.000Z + + + pithosian + 2025-05-12T12:05:00.000Z + + + Saint Wenhao + 2025-05-12T18:17:00.000Z + + + pithosian + 2025-05-12T20:19:00.000Z + + + Saint Wenhao + 2025-05-17T05:11:00.000Z + + + Garlo Nicon + 2025-07-05T04:31:00.000Z + + @@ -135,21 +171,17 @@ - python-feedgen + 2 Combined summary - Unbreaking testnet4 - 2025-07-06T03:04:39.614808+00:00 + 2025-09-26T14:37:43.978249+00:00 + 2025-07-05T04:31:00+00:00 The ongoing discourse within the Bitcoin development community underscores a collective drive towards refining the blockchain's testnet environment, aiming to bridge the gap between an ideal testing ground and the inherent challenges posed by current operational frameworks. Testnet4, introduced with aspirations to surmount the difficulties encountered in Testnet3—particularly those related to the difficulty reset mechanism—has paradoxically replicated similar challenges. The initiative to enable developers to mine blocks on less powerful devices like laptops, although well-intentioned, inadvertently led to exploitative practices that undermined the testnet's utility. This contradiction highlights a fundamental tension between maintaining a permissionless network, as is characteristic of Proof of Work (PoW) systems, and the necessity for a controlled environment conducive to development, such as that offered by Signet. - The debate extends to the question of how best to evolve the testnet framework without compromising its core objectives. A pivotal suggestion within this dialogue is the elimination of the difficulty reset rule from Testnet4 through a flag day hard fork slated for January 1, 2026. This proposed timeline provides ample opportunity for comprehensive review, integration into upcoming Bitcoin Core releases, and widespread adoption across existing infrastructure. This approach reflects a broader consideration of how to balance the need for an authentic replication of the Bitcoin mainnet against facilitating a practical and accessible platform for developers. - Further discussions have ventured into innovative solutions aimed at enhancing the testnet's functionality, including the development of a decentralized faucet by Antoine Poinsot. This tool represents a significant step towards lowering entry barriers for new developers and streamlining the testing process. Such initiatives underscore a concerted effort within the community to address the testnet's limitations, ensuring it remains a vital resource for fostering innovation and improving the robustness of Bitcoin's testing environments. - In parallel, conversations have also delved into technical aspects concerning the blockchain's code, particularly the `fPowAllowMinDifficultyBlocks` rule and its implications for block addition under specific circumstances. These discussions highlight the intricate nature of blockchain protocol management and the continuous efforts to strike a balance between flexibility, security, and fairness within the network's operation. - Overall, the dialogue within the Bitcoin Development Mailing List encapsulates a dynamic and ongoing process of reflection, critique, and collaborative problem-solving. It signifies a commitment among developers to not only navigate the complexities of blockchain technology but also to envision and implement changes that enhance its sustainability, efficacy, and inclusivity. - 2025-07-05T04:31:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2025/combined_Update-on-the-Great-Consensus-Cleanup-Revival.xml b/static/bitcoin-dev/March_2025/combined_Update-on-the-Great-Consensus-Cleanup-Revival.xml index 0ce660df7f..878508aa7e 100644 --- a/static/bitcoin-dev/March_2025/combined_Update-on-the-Great-Consensus-Cleanup-Revival.xml +++ b/static/bitcoin-dev/March_2025/combined_Update-on-the-Great-Consensus-Cleanup-Revival.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Update on the Great Consensus Cleanup Revival - 2025-03-09T02:07:41.925909+00:00 - - Greg Sanders 2025-03-07 21:45:00+00:00 - - - Antoine Poinsot 2025-02-27 17:23:00+00:00 - - - Matt Corallo 2025-02-26 19:11:00+00:00 - - - Peter Todd 2025-02-26 11:02:00+00:00 - - - Antoine Poinsot 2025-02-23 22:35:00+00:00 - - - Matt Corallo 2025-02-21 01:22:00+00:00 - - - Antoine Riard 2025-02-15 21:13:00+00:00 - - - Peter Todd 2025-02-14 17:40:00+00:00 - - - Antoine Riard 2025-02-11 21:20:00+00:00 - - - Chris Stewart 2025-02-10 21:21:00+00:00 - - - Antoine Poinsot 2025-02-10 16:28:00+00:00 - - - Antoine Riard 2025-02-07 13:02:00+00:00 - - - Antoine Poinsot 2025-02-06 22:03:00+00:00 - - - Murch 2025-02-06 21:34:00+00:00 - - - Antoine Poinsot 2025-02-05 18:09:00+00:00 - + 2025-09-26T14:37:56.775975+00:00 + python-feedgen + + + Update on the Great Consensus Cleanup Revival 'Antoine Poinsot' + 2025-02-05T18:09:00.000Z + + + Murch + 2025-02-06T21:34:00.000Z + + + Antoine Poinsot' + 2025-02-06T22:03:00.000Z + + + Antoine Riard + 2025-02-07T13:02:00.000Z + + + Antoine Poinsot' + 2025-02-10T16:28:00.000Z + + + Chris Stewart + 2025-02-10T21:21:00.000Z + + + Antoine Riard + 2025-02-11T21:20:00.000Z + + + Peter Todd + 2025-02-14T17:40:00.000Z + + + Antoine Riard + 2025-02-15T21:13:00.000Z + + + Matt Corallo + 2025-02-21T01:22:00.000Z + + + Antoine Poinsot' + 2025-02-23T22:35:00.000Z + + + Peter Todd + 2025-02-26T11:02:00.000Z + + + Matt Corallo + 2025-02-26T19:11:00.000Z + + + Antoine Poinsot' + 2025-02-27T17:23:00.000Z + + + Greg Sanders + 2025-03-07T21:45:00.000Z + + @@ -63,29 +81,21 @@ - python-feedgen + 2 Combined summary - Update on the Great Consensus Cleanup Revival - 2025-03-09T02:07:41.926034+00:00 + 2025-09-26T14:37:56.777804+00:00 + 2025-03-07T21:45:00+00:00 The discussions on the Bitcoin Development Mailing List and various GitHub issues have delved into multiple facets of Bitcoin's development, focusing on optimizing transaction validation processes, assessing hardware performance for mining, contemplating codebase refinements, analyzing security measures against potential attacks, and proposing significant updates to the Bitcoin protocol through Improvement Proposals (BIPs). - One area of discussion emphasized the relationship between the number of preparation blocks used in transaction validations and the resulting computational costs. Through comparative analysis, it was determined that employing a mitigation strategy could equate the validation cost of using Taproot technology to that of legacy systems under certain conditions. This insight is pivotal for developers aiming to enhance Bitcoin transaction validations efficiently. - Another point of interest revolved around the affordability and performance of mining hardware, notably inexpensive devices like Raspberry Pi. The conversation shed light on how parallelization across multiple cores could potentially exceed expected outcomes in mining operations, highlighting an eagerness to understand the performance of such hardware under varying operational scenarios. - Further deliberations touched upon the importance of meticulously reviewing unused code segments within the Bitcoin codebase. The specific mention of three lines of code and a single line defining SCRIPT_VERIFY_SIGPUSHONLY underscored the complexity in deciding whether removing ostensibly unused code is beneficial, given its indirect relevance to testing other code functionalities. - Security concerns also took center stage, with discussions exploring worst-case scenarios in blockchain validation times. A nuanced perspective was offered on managing these scenarios, not just from end-users' viewpoint but also considering miners' roles in maintaining network integrity. Real-world tests, including one conducted on a Dell XPS 15 9520 laptop, revealed that current worst-case validation times could be significantly reduced through proposed mitigations, underscoring the balance between theoretical challenges and practical solutions. - Enhancements in block validation times were celebrated, marking a substantial step forward in Bitcoin’s efficiency. A notable 40x decrease in the worst-case scenario for validation times was achieved, sparking inquiries into the quantification of this improvement and the potential for further reductions. - In-depth technical explorations were conducted around the VerifyScript functionality and the SCRIPT_VERIFY_SIGPUSHONLY flag, revealing a nuanced understanding of Bitcoin's codebase where elements may persist for purposes outside immediate network operations, such as testing and verification. - Antoine Poinsot's contributions highlighted a preference for addressing vulnerabilities in the Bitcoin protocol through bundled fixes in soft forks, emphasizing a comprehensive approach to securing the network. His advocacy for deploying multiple soft forks simultaneously under a future BIP-9-based deployment scenario illustrated the technical and consensus considerations involved in evolving Bitcoin's protocol. - Finally, efforts to fortify Bitcoin against known threats culminated in a revised consensus cleanup proposal, encapsulating critical updates to enhance the security and functionality of Bitcoin. This initiative underscores the ongoing commitment within the development community to refine and secure the Bitcoin protocol, reflecting a collaborative effort towards ensuring its robustness and longevity. - 2025-03-07T21:45:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_-PROPOSAL-OP-TX-generalized-covenants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml b/static/bitcoin-dev/May_2022/combined_-PROPOSAL-OP-TX-generalized-covenants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml index 83c384b085..ae2fbf6a40 100644 --- a/static/bitcoin-dev/May_2022/combined_-PROPOSAL-OP-TX-generalized-covenants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml +++ b/static/bitcoin-dev/May_2022/combined_-PROPOSAL-OP-TX-generalized-covenants-reduced-to-OP-CHECKTEMPLATEVERIFY.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY - 2023-08-02T06:29:11.754640+00:00 - - Jeremy Rubin 2022-06-24 18:05:50+00:00 - - - Anthony Towns 2022-06-24 06:06:05+00:00 - - - Alex Schoof 2022-05-11 23:32:34+00:00 - - - Brandon Black 2022-05-10 15:16:10+00:00 - - - Rusty Russell 2022-05-10 10:35:54+00:00 - + 2025-09-26T14:38:16.017224+00:00 + python-feedgen + + + [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY Rusty Russell + 2022-05-10T10:35:00.000Z + + + Brandon Black + 2022-05-10T15:16:00.000Z + + + Alex Schoof + 2022-05-11T23:32:00.000Z + + + Anthony Towns + 2022-06-24T06:06:00.000Z + + + Jeremy Rubin + 2022-06-24T18:05:00.000Z + + - python-feedgen + 2 Combined summary - [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY - 2023-08-02T06:29:11.754640+00:00 + 2025-09-26T14:38:16.017940+00:00 - In a recent discussion on the bitcoin-dev mailing list, the use of merkle trees for Commitment Transaction Verification (CTV) was debated. While there was recognition that merkle trees could offer advantages in terms of API perspective, the main concern raised was related to validation performance. It was argued that using a merkle tree would add unnecessary work for CTV, with its value only evident in scenarios involving multiple outputs and random-index insertions. For cases where editing the last output is common, SHA-STREAM was proposed as an alternative option, enabling efficient editing of the tail. The conversation also touched upon the OPTX_SEPARATELY and OPTX_UNHASHED fields, as well as the OPTX_SELECT_OUTPUT_AMOUNT32x2* and OPTX_SELECT_OUTPUT_SCRIPTPUBKEY* fields. The issue of upgradability was highlighted, particularly in relation to committing to specific outputs, which currently poses challenges for both OP_TX and CTV. One potential solution suggested was the use of a merkle path to prove the consumption of an entire output. Overall, the discussion centered around weighing the tradeoffs between employing a merkle tree versus other methods for CTV.On May 10, 2022, Rusty Russell shared some ideas on the bitcoin-dev mailing list regarding the OPTX_SEPARATELY and OPTX_UNHASHED fields. He proposed treating these fields separately instead of concatenating them and pushing them on the stack without hashing. The discussion revolved around updating the CTV hash by committing to specific outputs, but it was acknowledged that both approaches were less efficient compared to using a merkle path. The challenge of proving the consumption of an output in its entirety was linked to concerns about upgradability, especially if additional features like CAT or TLUV were to be added. Both OP_TX and CTV aimed to account for upgradability in advance. These concepts have the potential to enhance the efficiency and security of the Bitcoin network.A proposal has been introduced for a v1 tapscript opcode that enables generic covenants. The proposal suggests utilizing an OP_SUCCESS opcode, unless it is used similarly to OP_CHECKTEMPLATEVERIFY, which offers a clear use case and allows for future expansion. If experience demonstrates that repurposing OP_NOP4 as a shortcut is a useful optimization, it may be considered in the future. The proposal builds upon Russell O'Connor's TXHASH, incorporating Anthony Towns' modification through opcode extension. Certain bits are defined specifically for this soft fork, while others can have their semantics determined later. To ensure clarity, the proposal outlines potential future uses. Notably, BIP-342 resource limits impose restrictions, such as failing when more than 1000 elements are pushed on the stack or when an element exceeds 512 bytes. By precisely enumerating what can be committed to, it becomes unequivocally clear what is and isn't committed. The bits separating concatenation and hashing provide a straightforward mechanism for template-style commitments (like CTV) or programmatic treatment of individual elements, such as amounts. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. It is important to note that the OP_SUCCESS semantic is only applicable in tapscript v1, making it incompatible with covenants for v0 segwit or pre-segwit inputs. If covenants prove beneficial, dedicated opcodes can be provided for those cases.Brandon responded to Rusty Russell's previous email regarding the proposal for a v1 tapscript opcode for generic covenants. Brandon emphasized one major limitation of CTV, which is the script's specificity to the amount of the input being spent. He suggested adding OPTX_SELECT_IN_OUT_AMOUNT32x2 to the initial set of flags, enabling the reuse of a single script and facilitating the construction of a small script for relocatable, batchable operations. The proposed soft fork involves OP_TX followed by 4 bytes of flags. Only the flags marked with an asterisk need to be defined for this soft fork, while others can have their semantics determined later. The proposed flag combinations aim to approximate OP_CHECKTEMPLATEVERIFY, with other combinations resulting in OP_SUCCESS. By enumerating what can be committed to, it becomes explicitly clear what is and isn't committed. The bits separating concatenation and hashing provide a simple mechanism for template-style commitments or programmatic treatment of individual elements. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. The OP_SUCCESS semantic is only valid in tapscript v1, meaning it does not allow for covenants in v0 segwit or pre-segwit inputs. If covenants prove useful, dedicated opcodes can be provided for those cases, similar to OP_CHECKTEMPLATEVERIFY.A proposal has been made to introduce a v1 tapscript opcode for generic covenants, with only an OP_SUCCESS opcode if used similarly 2022-06-24T18:05:50+00:00 + In a recent discussion on the bitcoin-dev mailing list, the use of merkle trees for Commitment Transaction Verification (CTV) was debated. While there was recognition that merkle trees could offer advantages in terms of API perspective, the main concern raised was related to validation performance. It was argued that using a merkle tree would add unnecessary work for CTV, with its value only evident in scenarios involving multiple outputs and random-index insertions. For cases where editing the last output is common, SHA-STREAM was proposed as an alternative option, enabling efficient editing of the tail. The conversation also touched upon the OPTX_SEPARATELY and OPTX_UNHASHED fields, as well as the OPTX_SELECT_OUTPUT_AMOUNT32x2* and OPTX_SELECT_OUTPUT_SCRIPTPUBKEY* fields. The issue of upgradability was highlighted, particularly in relation to committing to specific outputs, which currently poses challenges for both OP_TX and CTV. One potential solution suggested was the use of a merkle path to prove the consumption of an entire output. Overall, the discussion centered around weighing the tradeoffs between employing a merkle tree versus other methods for CTV.On May 10, 2022, Rusty Russell shared some ideas on the bitcoin-dev mailing list regarding the OPTX_SEPARATELY and OPTX_UNHASHED fields. He proposed treating these fields separately instead of concatenating them and pushing them on the stack without hashing. The discussion revolved around updating the CTV hash by committing to specific outputs, but it was acknowledged that both approaches were less efficient compared to using a merkle path. The challenge of proving the consumption of an output in its entirety was linked to concerns about upgradability, especially if additional features like CAT or TLUV were to be added. Both OP_TX and CTV aimed to account for upgradability in advance. These concepts have the potential to enhance the efficiency and security of the Bitcoin network.A proposal has been introduced for a v1 tapscript opcode that enables generic covenants. The proposal suggests utilizing an OP_SUCCESS opcode, unless it is used similarly to OP_CHECKTEMPLATEVERIFY, which offers a clear use case and allows for future expansion. If experience demonstrates that repurposing OP_NOP4 as a shortcut is a useful optimization, it may be considered in the future. The proposal builds upon Russell O'Connor's TXHASH, incorporating Anthony Towns' modification through opcode extension. Certain bits are defined specifically for this soft fork, while others can have their semantics determined later. To ensure clarity, the proposal outlines potential future uses. Notably, BIP-342 resource limits impose restrictions, such as failing when more than 1000 elements are pushed on the stack or when an element exceeds 512 bytes. By precisely enumerating what can be committed to, it becomes unequivocally clear what is and isn't committed. The bits separating concatenation and hashing provide a straightforward mechanism for template-style commitments (like CTV) or programmatic treatment of individual elements, such as amounts. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. It is important to note that the OP_SUCCESS semantic is only applicable in tapscript v1, making it incompatible with covenants for v0 segwit or pre-segwit inputs. If covenants prove beneficial, dedicated opcodes can be provided for those cases.Brandon responded to Rusty Russell's previous email regarding the proposal for a v1 tapscript opcode for generic covenants. Brandon emphasized one major limitation of CTV, which is the script's specificity to the amount of the input being spent. He suggested adding OPTX_SELECT_IN_OUT_AMOUNT32x2 to the initial set of flags, enabling the reuse of a single script and facilitating the construction of a small script for relocatable, batchable operations. The proposed soft fork involves OP_TX followed by 4 bytes of flags. Only the flags marked with an asterisk need to be defined for this soft fork, while others can have their semantics determined later. The proposed flag combinations aim to approximate OP_CHECKTEMPLATEVERIFY, with other combinations resulting in OP_SUCCESS. By enumerating what can be committed to, it becomes explicitly clear what is and isn't committed. The bits separating concatenation and hashing provide a simple mechanism for template-style commitments or programmatic treatment of individual elements. The absence of double-hashing for scriptsigs and other fields means that the hashing done for SIGHASH_ALL cannot be reused. The OP_SUCCESS semantic is only valid in tapscript v1, meaning it does not allow for covenants in v0 segwit or pre-segwit inputs. If covenants prove useful, dedicated opcodes can be provided for those cases, similar to OP_CHECKTEMPLATEVERIFY.A proposal has been made to introduce a v1 tapscript opcode for generic covenants, with only an OP_SUCCESS opcode if used similarly - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_-Pre-BIP-Fee-Accounts.xml b/static/bitcoin-dev/May_2022/combined_-Pre-BIP-Fee-Accounts.xml index 32397a76b2..22491aa78f 100644 --- a/static/bitcoin-dev/May_2022/combined_-Pre-BIP-Fee-Accounts.xml +++ b/static/bitcoin-dev/May_2022/combined_-Pre-BIP-Fee-Accounts.xml @@ -1,98 +1,187 @@ - + 2 Combined summary - [Pre-BIP] Fee Accounts - 2023-08-02T05:17:55.394761+00:00 - - Jeremy Rubin 2022-05-02 15:59:49+00:00 - - - Peter Todd 2022-04-28 12:15:02+00:00 - - - Jeremy Rubin 2022-04-17 20:57:28+00:00 - - - Peter Todd 2022-04-15 14:52:47+00:00 - - - Jeremy Rubin 2022-04-11 13:18:10+00:00 - - - Peter Todd 2022-04-10 19:32:52+00:00 - - - Jeremy Rubin 2022-02-20 16:45:35+00:00 - - - ZmnSCPxj 2022-02-20 16:34:35+00:00 - - - Jeremy Rubin 2022-02-20 16:29:35+00:00 - - - Jeremy Rubin 2022-02-20 16:29:00+00:00 - - - ZmnSCPxj 2022-02-20 14:24:22+00:00 - - - ZmnSCPxj 2022-02-20 02:39:50+00:00 - - - ZmnSCPxj 2022-02-20 02:24:37+00:00 - - - Peter Todd 2022-02-19 20:35:20+00:00 - - - darosior 2022-02-19 17:20:19+00:00 - - - Peter Todd 2022-02-19 09:39:22+00:00 - - - Jeremy Rubin 2022-02-19 00:38:27+00:00 - - - Peter Todd 2022-02-18 23:50:07+00:00 - - - Jeremy Rubin 2022-02-10 08:08:59+00:00 - - - Peter Todd 2022-02-10 06:58:56+00:00 - - - Billy Tetrud 2022-01-20 05:23:12+00:00 - - - Jeremy 2022-01-19 20:08:23+00:00 - - - Billy Tetrud 2022-01-19 16:51:48+00:00 - - - Jeremy 2022-01-19 07:32:36+00:00 - - - Billy Tetrud 2022-01-19 04:53:21+00:00 - - - Jeremy 2022-01-19 02:51:42+00:00 - - - Billy Tetrud 2022-01-19 02:37:39+00:00 - - - Jeremy 2022-01-18 17:43:07+00:00 - - - Billy Tetrud 2022-01-18 16:12:36+00:00 - - - Jeremy 2022-01-01 20:04:00+00:00 - + 2025-09-26T14:38:48.139889+00:00 + python-feedgen + + + [bitcoin-dev] [Pre-BIP] Fee Accounts Jeremy + 2022-01-01T20:04:00.000Z + + + Billy Tetrud + 2022-01-18T16:12:00.000Z + + + Jeremy + 2022-01-18T17:43:00.000Z + + + Billy Tetrud + 2022-01-19T02:37:00.000Z + + + Jeremy + 2022-01-19T02:51:00.000Z + + + Billy Tetrud + 2022-01-19T04:53:00.000Z + + + Jeremy + 2022-01-19T07:32:00.000Z + + + Billy Tetrud + 2022-01-19T16:51:00.000Z + + + Jeremy + 2022-01-19T20:08:00.000Z + + + Billy Tetrud + 2022-01-20T05:23:00.000Z + + + Peter Todd + 2022-02-10T06:58:00.000Z + + + Jeremy Rubin + 2022-02-10T08:08:00.000Z + + + Peter Todd + 2022-02-18T23:50:00.000Z + + + Jeremy Rubin + 2022-02-19T00:38:00.000Z + + + Peter Todd + 2022-02-19T09:39:00.000Z + + + [bitcoin-dev] [Lightning-dev] " darosior + 2022-02-19T17:20:00.000Z + + + Peter Todd + 2022-02-19T20:35:00.000Z + + + ZmnSCPxj + 2022-02-20T02:24:00.000Z + + + ZmnSCPxj + 2022-02-20T02:39:00.000Z + + + ZmnSCPxj + 2022-02-20T14:24:00.000Z + + + Jeremy Rubin + 2022-02-20T16:29:00.000Z + + + [bitcoin-dev] " Jeremy Rubin + 2022-02-20T16:29:00.000Z + + + ZmnSCPxj + 2022-02-20T16:34:00.000Z + + + Jeremy Rubin + 2022-02-20T16:45:00.000Z + + + Peter Todd + 2022-04-10T19:32:00.000Z + + + Jeremy Rubin + 2022-04-11T13:18:00.000Z + + + Peter Todd + 2022-04-15T14:52:00.000Z + + + Jeremy Rubin + 2022-04-17T20:57:00.000Z + + + Peter Todd + 2022-04-28T12:15:00.000Z + + + Jeremy Rubin + 2022-05-02T15:59:00.000Z + + + [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions Peter Todd + 2022-06-14T11:12:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T11:39:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T11:53:00.000Z + + + rot13maxi + 2022-06-14T12:28:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T12:45:00.000Z + + + Bryan Bishop + 2022-06-14T13:55:00.000Z + + + digital vagabond + 2022-06-14T15:06:00.000Z + + + Peter Todd + 2022-06-14T15:22:00.000Z + + + Peter Todd + 2022-06-14T15:34:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-14T17:15:00.000Z + + + Andrew Poelstra + 2022-06-14T20:33:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-15T01:16:00.000Z + + + Undiscussed Horrific Abuse, One Victim of Many + 2022-06-15T01:21:00.000Z + + + Peter Todd + 2022-06-19T11:04:00.000Z + + @@ -123,13 +212,13 @@ - python-feedgen + 2 Combined summary - [Pre-BIP] Fee Accounts - 2023-08-02T05:17:55.395761+00:00 + 2025-09-26T14:38:48.144578+00:00 - In a detailed email conversation, the participants discuss various aspects of blockchain technology, specifically focusing on Open Time Stamps (OTS). The discussion begins with a proposal for a correct timestamping service model, stating that any such service must adhere to the model to be reliable. The writer highlights the potential issues and unreliability that can arise if the model is not followed.Jeremy Rubin questions the appeal to authority in the Bitcoin-dev group and raises concerns about the formal correctness of OTS. He suggests the need for an actual specification for OTS to resolve these issues. The conversation then delves into the technical details of OTS, including its proof format and how it relates to transactions and Bitcoin blocks. The participants also discuss the concept of linearization and its relevance in a use-case scenario. They debate the advantages and disadvantages of different transaction models and fee accounts implementation, emphasizing the importance of flexibility and avoiding unnecessary costs.Additionally, the conversation touches upon the topic of necromancy attacks, where an earlier version of a transaction is resurrected by a third party for OTS. The potential benefits and drawbacks of such attacks are discussed, along with suggestions for mitigating their impact. The discussion expands to include the design of fee accounts and the need for explicit tagging or opt-in features. Different viewpoints are presented, highlighting the potential limitations and advantages of each approach.Another topic addressed is the use of Child Pays for Parent (CPFP) to solve issues related to relative locktimes in Bitcoin Vaults. The participants discuss the recommended design for Vaults and the need for additional features like RBF-able addable input/output or sponsors.The conversation concludes with discussions on the definition of pinning attacks, progress in committing data, and the potential risks associated with certain approaches in blockchain schemes. Overall, the email conversation covers a wide range of topics related to blockchain technology, providing insights into the challenges and considerations involved in implementing and improving timestamping services.Bitcoin developer Jeremy Rubin has proposed a new design to improve the fee-paying semantics in Bitcoin. The current system of paying fees in-band presents challenges for smart contracts and features such as fee bumping and DoS-resistant payment channels. Rubin's proposal suggests two approaches: using a special transaction called a "sponsor" to allow arbitrary fee appending, or implementing an account system as an extension block.The account system proposal involves defining a "fee account" output type that would have separate UTXO databases for deposits and withdrawals. Fee accounts would only be able to sign two types of transactions: one specifying a fee amount and a TXID, and another specifying a withdrawal amount, a fee, and an address. These transactions would be committed in an extension block merkle tree.Rubin argues that the proposed account system would make it easier to write smart contracts by separating the logic from the fees. The mempool logic would be updated to allow attaching fee account spends to transactions, with restrictions on accounts not being allowed to spend more than their balance. The design is considered scalable because adding fees to a transaction does not require adding inputs or outputs or tracking substantial amounts of new state.The proposal could also be modified to enhance privacy by implementing techniques like Tornado.cash or a trustless mixing protocol. Rubin suggests that a federated network could be used to bribe miners until a consensus upgrade is deployed, but acknowledges that this approach may introduce centralization.Overall, Rubin's proposal aims to address the limitations of the current fee-paying system in Bitcoin and provide more flexibility and scalability while considering privacy concerns. 2022-05-02T15:59:49+00:00 + In a detailed email conversation, the participants discuss various aspects of blockchain technology, specifically focusing on Open Time Stamps (OTS). The discussion begins with a proposal for a correct timestamping service model, stating that any such service must adhere to the model to be reliable. The writer highlights the potential issues and unreliability that can arise if the model is not followed.Jeremy Rubin questions the appeal to authority in the Bitcoin-dev group and raises concerns about the formal correctness of OTS. He suggests the need for an actual specification for OTS to resolve these issues. The conversation then delves into the technical details of OTS, including its proof format and how it relates to transactions and Bitcoin blocks. The participants also discuss the concept of linearization and its relevance in a use-case scenario. They debate the advantages and disadvantages of different transaction models and fee accounts implementation, emphasizing the importance of flexibility and avoiding unnecessary costs.Additionally, the conversation touches upon the topic of necromancy attacks, where an earlier version of a transaction is resurrected by a third party for OTS. The potential benefits and drawbacks of such attacks are discussed, along with suggestions for mitigating their impact. The discussion expands to include the design of fee accounts and the need for explicit tagging or opt-in features. Different viewpoints are presented, highlighting the potential limitations and advantages of each approach.Another topic addressed is the use of Child Pays for Parent (CPFP) to solve issues related to relative locktimes in Bitcoin Vaults. The participants discuss the recommended design for Vaults and the need for additional features like RBF-able addable input/output or sponsors.The conversation concludes with discussions on the definition of pinning attacks, progress in committing data, and the potential risks associated with certain approaches in blockchain schemes. Overall, the email conversation covers a wide range of topics related to blockchain technology, providing insights into the challenges and considerations involved in implementing and improving timestamping services.Bitcoin developer Jeremy Rubin has proposed a new design to improve the fee-paying semantics in Bitcoin. The current system of paying fees in-band presents challenges for smart contracts and features such as fee bumping and DoS-resistant payment channels. Rubin's proposal suggests two approaches: using a special transaction called a "sponsor" to allow arbitrary fee appending, or implementing an account system as an extension block.The account system proposal involves defining a "fee account" output type that would have separate UTXO databases for deposits and withdrawals. Fee accounts would only be able to sign two types of transactions: one specifying a fee amount and a TXID, and another specifying a withdrawal amount, a fee, and an address. These transactions would be committed in an extension block merkle tree.Rubin argues that the proposed account system would make it easier to write smart contracts by separating the logic from the fees. The mempool logic would be updated to allow attaching fee account spends to transactions, with restrictions on accounts not being allowed to spend more than their balance. The design is considered scalable because adding fees to a transaction does not require adding inputs or outputs or tracking substantial amounts of new state.The proposal could also be modified to enhance privacy by implementing techniques like Tornado.cash or a trustless mixing protocol. Rubin suggests that a federated network could be used to bribe miners until a consensus upgrade is deployed, but acknowledges that this approach may introduce centralization.Overall, Rubin's proposal aims to address the limitations of the current fee-paying system in Bitcoin and provide more flexibility and scalability while considering privacy concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_A-Calculus-of-Covenants.xml b/static/bitcoin-dev/May_2022/combined_A-Calculus-of-Covenants.xml index 131a0ec6c2..be454b845a 100644 --- a/static/bitcoin-dev/May_2022/combined_A-Calculus-of-Covenants.xml +++ b/static/bitcoin-dev/May_2022/combined_A-Calculus-of-Covenants.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - A Calculus of Covenants - 2023-08-02T06:07:59.342861+00:00 - - Keagan McClelland 2022-05-18 17:08:43+00:00 - - - Jeremy Rubin 2022-04-12 15:03:57+00:00 - - - Jeremy Rubin 2022-04-12 14:33:14+00:00 - + 2025-09-26T14:38:11.792877+00:00 + python-feedgen + + + [bitcoin-dev] A Calculus of Covenants Jeremy Rubin + 2022-04-12T14:33:00.000Z + + + Jeremy Rubin + 2022-04-12T15:03:00.000Z + + + Keagan McClelland + 2022-05-18T17:08:00.000Z + + - python-feedgen + 2 Combined summary - A Calculus of Covenants - 2023-08-02T06:07:59.342861+00:00 + 2025-09-26T14:38:11.793434+00:00 - The author presents a framework for understanding covenants in the context of building infrastructure for them. The focus is on local covenants, where only one coin is examined. The framework defines a covenant primitive as having a set of transaction intents, a verifier generator function, a prover generator function, impedance-matched proofs, and assumptions under which the covenant is verified.To instantiate a covenant, the user selects a specific element from the set of sets of transaction intents and generates a verifier and a prover function. This framework is then applied to analyze three covenants: plain CTV, 2-3 online multisig, and 3-3 presigned + deleted.The author also raises questions about the cardinality of an intent set, the composition of different covenants within an intent, and the unrollability of intents. While the framework assumes statelessness, it acknowledges that provers may need to maintain external state to prove.The author notes that the efficiency of a prover or verifier is not addressed in this framework. However, the framework is valuable for generating tooling that can integrate covenants into Sapio, a platform.Overall, this framework provides a comprehensive approach to analyzing covenants and offers insights into their practical use cases. 2022-05-18T17:08:43+00:00 + The author presents a framework for understanding covenants in the context of building infrastructure for them. The focus is on local covenants, where only one coin is examined. The framework defines a covenant primitive as having a set of transaction intents, a verifier generator function, a prover generator function, impedance-matched proofs, and assumptions under which the covenant is verified.To instantiate a covenant, the user selects a specific element from the set of sets of transaction intents and generates a verifier and a prover function. This framework is then applied to analyze three covenants: plain CTV, 2-3 online multisig, and 3-3 presigned + deleted.The author also raises questions about the cardinality of an intent set, the composition of different covenants within an intent, and the unrollability of intents. While the framework assumes statelessness, it acknowledges that provers may need to maintain external state to prove.The author notes that the efficiency of a prover or verifier is not addressed in this framework. However, the framework is valuable for generating tooling that can integrate covenants into Sapio, a platform.Overall, this framework provides a comprehensive approach to analyzing covenants and offers insights into their practical use cases. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_ANYPREVOUT-in-place-of-CTV.xml b/static/bitcoin-dev/May_2022/combined_ANYPREVOUT-in-place-of-CTV.xml index ded11e0b23..468d073b22 100644 --- a/static/bitcoin-dev/May_2022/combined_ANYPREVOUT-in-place-of-CTV.xml +++ b/static/bitcoin-dev/May_2022/combined_ANYPREVOUT-in-place-of-CTV.xml @@ -1,86 +1,115 @@ - + 2 Combined summary - ANYPREVOUT in place of CTV - 2023-08-02T06:12:38.421815+00:00 - - Swambo, Jacob 2022-05-03 16:40:22+00:00 - - - Jeremy Rubin 2022-05-03 15:51:18+00:00 - - - darosior 2022-05-03 10:38:52+00:00 - - - Billy Tetrud 2022-05-01 23:35:08+00:00 - - - Nadav Ivgi 2022-05-01 14:25:42+00:00 - - - Greg Sanders 2022-04-30 11:15:25+00:00 - - - Nadav Ivgi 2022-04-30 08:09:26+00:00 - - - Swambo, Jacob 2022-04-29 13:22:14+00:00 - - - Nadav Ivgi 2022-04-29 11:40:05+00:00 - - - Nadav Ivgi 2022-04-29 10:21:33+00:00 - - - darosior 2022-04-29 08:30:55+00:00 - - - Nadav Ivgi 2022-04-29 05:08:32+00:00 - - - Jeremy Rubin 2022-04-26 20:13:26+00:00 - - - Nadav Ivgi 2022-04-25 16:57:48+00:00 - - - Nadav Ivgi 2022-04-25 16:35:17+00:00 - - - darosior 2022-04-25 16:35:14+00:00 - - - darosior 2022-04-25 13:35:48+00:00 - - - Hampus Sjöberg 2022-04-25 13:34:25+00:00 - - - Erik Aronesty 2022-04-25 01:46:25+00:00 - - - Richard Myers 2022-04-24 20:41:54+00:00 - - - pushd 2022-04-22 17:14:50+00:00 - - - Luke Dashjr 2022-04-22 17:01:14+00:00 - - - pushd 2022-04-22 13:35:11+00:00 - - - darosior 2022-04-22 11:54:30+00:00 - - - rot13maxi 2022-04-22 11:44:24+00:00 - - - darosior 2022-04-22 11:11:41+00:00 - + 2025-09-26T14:38:30.985824+00:00 + python-feedgen + + + [bitcoin-dev] ANYPREVOUT in place of CTV darosior + 2022-04-22T11:11:00.000Z + + + rot13maxi + 2022-04-22T11:44:00.000Z + + + darosior + 2022-04-22T11:54:00.000Z + + + pushd + 2022-04-22T13:35:00.000Z + + + Luke Dashjr + 2022-04-22T17:01:00.000Z + + + pushd + 2022-04-22T17:14:00.000Z + + + Richard Myers + 2022-04-24T20:41:00.000Z + + + Erik Aronesty + 2022-04-25T01:46:00.000Z + + + Hampus Sjöberg + 2022-04-25T13:34:00.000Z + + + darosior + 2022-04-25T13:35:00.000Z + + + darosior + 2022-04-25T16:35:00.000Z + + + Nadav Ivgi + 2022-04-25T16:35:00.000Z + + + Nadav Ivgi + 2022-04-25T16:57:00.000Z + + + Jeremy Rubin + 2022-04-26T20:13:00.000Z + + + Nadav Ivgi + 2022-04-29T05:08:00.000Z + + + darosior + 2022-04-29T08:30:00.000Z + + + Nadav Ivgi + 2022-04-29T10:21:00.000Z + + + Nadav Ivgi + 2022-04-29T11:40:00.000Z + + + Swambo, Jacob + 2022-04-29T13:22:00.000Z + + + Nadav Ivgi + 2022-04-30T08:09:00.000Z + + + Greg Sanders + 2022-04-30T11:15:00.000Z + + + Nadav Ivgi + 2022-05-01T14:25:00.000Z + + + Billy Tetrud + 2022-05-01T23:35:00.000Z + + + darosior + 2022-05-03T10:38:00.000Z + + + Jeremy Rubin + 2022-05-03T15:51:00.000Z + + + Swambo, Jacob + 2022-05-03T16:40:00.000Z + + @@ -107,13 +136,13 @@ - python-feedgen + 2 Combined summary - ANYPREVOUT in place of CTV - 2023-08-02T06:12:38.421815+00:00 + 2025-09-26T14:38:30.988542+00:00 - The email thread discusses the debate within the Bitcoin developer community regarding the use of SIGHASH_ANYPREVOUT (APO) as an alternative to CTV's proposed covenant design. The author retracts their previous statement in favor of OP_CTV, realizing that both APOAS and CTV face a trade-off between flexibility and safety. They question the need for less restrictive templates and provide reasons why such templates may be necessary. They argue that disallowing RBF can make it difficult for attackers to create malicious alternatives, certain covenant-based applications may not be critical enough to require strict restrictions, and flexible signature messages can be used safely in trusted multi-party contexts.The author suggests that APOAS covenants, when combined with other SIGHASH modes and the ability to re-bind transactions, offer more flexibility than CTV covenants. They express their uncertainty about the safety of BIP-118 but believe that the recent debate is part of the maturation process and are glad for it.The discussion also focuses on the potential use of APO instead of CTV. Some argue that APO gets dangerously close to fully recursive covenants and suggest using smaller independent steps, like adding CTV and gradually introducing more flags and ergonomic Opcodes for covenants. Others believe that BIP118 could be a soft fork candidate that benefits more Bitcoin users, considering the interest in simple covenants and better off-chain protocols. There is also concern about the long-term storage of bitcoins in non-quantum-computer vulnerable-bare-CTV-covenants and the potential impact of a large-scale theft of bitcoins on the overall value of the cryptocurrency.In a conversation between Antoine and Jacob, they discuss the comparison between CTV and APO covenants. Antoine clarifies that both commit to the same template and that more powerful covenants could enable more interesting applications where CTV would be an optimization. However, in the short term, some request activating CTV to start playing with covenants before settling on a more useful covenant. Jacob argues that APOAS-based covenants tie the signature message algorithm to both the covenant commitment and transaction validation, introducing a trade-off between safety and flexibility. Antoine suggests separating the covenant commitment from the signatures to validate transactions, bypassing this trade-off.The email thread also discusses the use of BIP118 and its potential as a soft fork candidate. It is suggested that committing to the number of inputs instead of sha_sequences ensures txid stability for single input transactions. There is also discussion about whether APO-AS part of BIP118 may face opposition similar to BIP119.In another discussion on the Bitcoin-dev mailing list, the use cases of APOAS|SINGLE are explored. It is noted that APOAS|SINGLE is useful for vaults or spacechains but not for batch channels or congestion control. The debate revolves around the commitment to amount and its implications. The suggestions put forward include doing a tweaked version of BIP118 in place of or before BIP119 and making the commitment to amount optional behind a flag.The author acknowledges the benefits of using APOAS instead of CTV in the short-term, as it enables Eltoo. However, they argue that there is a point in favor of CTV in the long-term. They suggest separating the covenant commitment from the signatures to validate transactions, providing additional flexibility for new templates and enabling more utility for covenant-based applications.The author of a post on the Bitcoin-dev mailing list proposes using a tweaked version of BIP118 as an alternative to CTV. They argue that SIGHASH_ANYPREVOUTANYSCRIPT can emulate CTV if its "ANYONECANPAY" behavior is made optional. The author suggests that APO-AS covenants could cover the flagship use case of vaults and that potential use cases for APO should be explored. They propose that BIP118 could benefit more Bitcoin users and ask if people would oppose the APO-AS part of BIP118 for the same reasons they might oppose BIP119.Another member of the mailing list expresses doubts about the necessity and sufficiency of CTV, suggesting that pre-signed transactions could be used instead. They argue that APO-AS covenants can cover the same use cases as CTV and propose that CTV could be considered an optimization of APO. The member suggests that if onchain usage proves them wrong, CTV could still be rolled out as an optimization.In addition, there is discussion about the activation of CTV and SIGHASH_ANYPREVOUT, with concerns about scarce reviewer time. The fields covered by the CTV hash are similar to what the ANYPREVOUT_ANYSCRIPT's signature hash covers, but APO_AS does not commit to the number of inputs and the hash of the inputs' sequences. It is suggested that tweaking BIP118 could address these issues and make it more compatible with C 2022-05-03T16:40:22+00:00 + The email thread discusses the debate within the Bitcoin developer community regarding the use of SIGHASH_ANYPREVOUT (APO) as an alternative to CTV's proposed covenant design. The author retracts their previous statement in favor of OP_CTV, realizing that both APOAS and CTV face a trade-off between flexibility and safety. They question the need for less restrictive templates and provide reasons why such templates may be necessary. They argue that disallowing RBF can make it difficult for attackers to create malicious alternatives, certain covenant-based applications may not be critical enough to require strict restrictions, and flexible signature messages can be used safely in trusted multi-party contexts.The author suggests that APOAS covenants, when combined with other SIGHASH modes and the ability to re-bind transactions, offer more flexibility than CTV covenants. They express their uncertainty about the safety of BIP-118 but believe that the recent debate is part of the maturation process and are glad for it.The discussion also focuses on the potential use of APO instead of CTV. Some argue that APO gets dangerously close to fully recursive covenants and suggest using smaller independent steps, like adding CTV and gradually introducing more flags and ergonomic Opcodes for covenants. Others believe that BIP118 could be a soft fork candidate that benefits more Bitcoin users, considering the interest in simple covenants and better off-chain protocols. There is also concern about the long-term storage of bitcoins in non-quantum-computer vulnerable-bare-CTV-covenants and the potential impact of a large-scale theft of bitcoins on the overall value of the cryptocurrency.In a conversation between Antoine and Jacob, they discuss the comparison between CTV and APO covenants. Antoine clarifies that both commit to the same template and that more powerful covenants could enable more interesting applications where CTV would be an optimization. However, in the short term, some request activating CTV to start playing with covenants before settling on a more useful covenant. Jacob argues that APOAS-based covenants tie the signature message algorithm to both the covenant commitment and transaction validation, introducing a trade-off between safety and flexibility. Antoine suggests separating the covenant commitment from the signatures to validate transactions, bypassing this trade-off.The email thread also discusses the use of BIP118 and its potential as a soft fork candidate. It is suggested that committing to the number of inputs instead of sha_sequences ensures txid stability for single input transactions. There is also discussion about whether APO-AS part of BIP118 may face opposition similar to BIP119.In another discussion on the Bitcoin-dev mailing list, the use cases of APOAS|SINGLE are explored. It is noted that APOAS|SINGLE is useful for vaults or spacechains but not for batch channels or congestion control. The debate revolves around the commitment to amount and its implications. The suggestions put forward include doing a tweaked version of BIP118 in place of or before BIP119 and making the commitment to amount optional behind a flag.The author acknowledges the benefits of using APOAS instead of CTV in the short-term, as it enables Eltoo. However, they argue that there is a point in favor of CTV in the long-term. They suggest separating the covenant commitment from the signatures to validate transactions, providing additional flexibility for new templates and enabling more utility for covenant-based applications.The author of a post on the Bitcoin-dev mailing list proposes using a tweaked version of BIP118 as an alternative to CTV. They argue that SIGHASH_ANYPREVOUTANYSCRIPT can emulate CTV if its "ANYONECANPAY" behavior is made optional. The author suggests that APO-AS covenants could cover the flagship use case of vaults and that potential use cases for APO should be explored. They propose that BIP118 could benefit more Bitcoin users and ask if people would oppose the APO-AS part of BIP118 for the same reasons they might oppose BIP119.Another member of the mailing list expresses doubts about the necessity and sufficiency of CTV, suggesting that pre-signed transactions could be used instead. They argue that APO-AS covenants can cover the same use cases as CTV and propose that CTV could be considered an optimization of APO. The member suggests that if onchain usage proves them wrong, CTV could still be rolled out as an optimization.In addition, there is discussion about the activation of CTV and SIGHASH_ANYPREVOUT, with concerns about scarce reviewer time. The fields covered by the CTV hash are similar to what the ANYPREVOUT_ANYSCRIPT's signature hash covers, but APO_AS does not commit to the number of inputs and the hash of the inputs' sequences. It is suggested that tweaking BIP118 could address these issues and make it more compatible with C - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Adding-SIGHASH-to-TXID.xml b/static/bitcoin-dev/May_2022/combined_Adding-SIGHASH-to-TXID.xml index bd5ccf7e92..34e145f5a8 100644 --- a/static/bitcoin-dev/May_2022/combined_Adding-SIGHASH-to-TXID.xml +++ b/static/bitcoin-dev/May_2022/combined_Adding-SIGHASH-to-TXID.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Adding SIGHASH to TXID - 2023-08-02T06:28:20.828027+00:00 - - vjudeu at gazeta.pl 2022-07-03 05:45:48+00:00 - - - Jeremy Rubin 2022-05-07 11:55:35+00:00 - - - vjudeu at gazeta.pl 2022-05-07 04:50:12+00:00 - + 2025-09-26T14:38:35.211868+00:00 + python-feedgen + + + [bitcoin-dev] Adding SIGHASH to TXID vjudeu + 2022-05-07T04:50:00.000Z + + + Jeremy Rubin + 2022-05-07T11:55:00.000Z + + + vjudeu + 2022-07-03T05:45:00.000Z + + - python-feedgen + 2 Combined summary - Adding SIGHASH to TXID - 2023-08-02T06:28:20.828027+00:00 + 2025-09-26T14:38:35.212435+00:00 - In a Bitcoin-dev mailing list, there is a proposal being discussed to control transaction flow by introducing new SIGHASH flags. The proposal suggests using these flags to apply sighashes to the previous transaction and create a stable txid, even if new inputs and outputs are added. This would allow for better control over transaction flow when using different sighashes like SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Currently, the Core client signs everything with SIGHASH_ALL by default, but the proposal suggests changing this behavior and proposing different sighashes based on the created transaction.The proposal also suggests displaying the transaction in a way that is visible in block explorers. Inputs and outputs would be highlighted or grayed out based on the selected sighashes, making it easier for users to control them. This would provide users with more control over the flow of transactions and ensure the stability of the txid.Another proposal made by John Law on the bitcoin-dev mailing list suggests using new sighash flags to calculate a transaction ID (txid) and have more control over the input and output of transactions. Currently, txid:vout is used as a previous transaction output to prevent modifications. However, with the introduction of SIGHASH_PREVOUT_XYZ flags, it would be possible to use different types of sighashes to commit to specific fields of the previous transaction output.For example, using SIGHASH_PREVOUT_SINGLE would allow the addition of new outputs to the previous transaction without affecting the replaced txid. On the other hand, using SIGHASH_PREVOUT_NONE would not check any outputs of the previous transaction but would still check the inputs. By applying sighashes to the previous transaction, instead of allowing for any transaction, there would be more control over the txid, ensuring that signatures sign what is intended and are not invalidated by changes unrelated to the currently-checked signature.The proposal suggests defaulting to SIGHASH_PREVOUT_ALL, but the three SIGHASH_PREVOUT_XYZ flags could also be combined with SIGHASH_PREVOUT_ANYONECANPAY to discard all inputs except for the input number matching "vout". Overall, the proposal aims to provide better control over the flow of transactions and ensure the stability of the txid.In summary, the use of SIGHASH_PREVOUT_XYZ flags would allow for greater control over transaction flow and create a stable txid. By applying sighashes to the previous transaction, users can ensure that signatures sign what is intended and prevent invalidation due to changes in unrelated inputs and outputs. The proposal suggests defaulting to SIGHASH_PREVOUT_ALL but also provides options for different combinations of flags to achieve specific control over transactions. 2022-07-03T05:45:48+00:00 + In a Bitcoin-dev mailing list, there is a proposal being discussed to control transaction flow by introducing new SIGHASH flags. The proposal suggests using these flags to apply sighashes to the previous transaction and create a stable txid, even if new inputs and outputs are added. This would allow for better control over transaction flow when using different sighashes like SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Currently, the Core client signs everything with SIGHASH_ALL by default, but the proposal suggests changing this behavior and proposing different sighashes based on the created transaction.The proposal also suggests displaying the transaction in a way that is visible in block explorers. Inputs and outputs would be highlighted or grayed out based on the selected sighashes, making it easier for users to control them. This would provide users with more control over the flow of transactions and ensure the stability of the txid.Another proposal made by John Law on the bitcoin-dev mailing list suggests using new sighash flags to calculate a transaction ID (txid) and have more control over the input and output of transactions. Currently, txid:vout is used as a previous transaction output to prevent modifications. However, with the introduction of SIGHASH_PREVOUT_XYZ flags, it would be possible to use different types of sighashes to commit to specific fields of the previous transaction output.For example, using SIGHASH_PREVOUT_SINGLE would allow the addition of new outputs to the previous transaction without affecting the replaced txid. On the other hand, using SIGHASH_PREVOUT_NONE would not check any outputs of the previous transaction but would still check the inputs. By applying sighashes to the previous transaction, instead of allowing for any transaction, there would be more control over the txid, ensuring that signatures sign what is intended and are not invalidated by changes unrelated to the currently-checked signature.The proposal suggests defaulting to SIGHASH_PREVOUT_ALL, but the three SIGHASH_PREVOUT_XYZ flags could also be combined with SIGHASH_PREVOUT_ANYONECANPAY to discard all inputs except for the input number matching "vout". Overall, the proposal aims to provide better control over the flow of transactions and ensure the stability of the txid.In summary, the use of SIGHASH_PREVOUT_XYZ flags would allow for greater control over transaction flow and create a stable txid. By applying sighashes to the previous transaction, users can ensure that signatures sign what is intended and prevent invalidation due to changes in unrelated inputs and outputs. The proposal suggests defaulting to SIGHASH_PREVOUT_ALL but also provides options for different combinations of flags to achieve specific control over transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_BIP-proposal-Timelocked-address-fidelity-bond-for-BIP39-seeds.xml b/static/bitcoin-dev/May_2022/combined_BIP-proposal-Timelocked-address-fidelity-bond-for-BIP39-seeds.xml index f7c5bf26a0..8d81bf25fe 100644 --- a/static/bitcoin-dev/May_2022/combined_BIP-proposal-Timelocked-address-fidelity-bond-for-BIP39-seeds.xml +++ b/static/bitcoin-dev/May_2022/combined_BIP-proposal-Timelocked-address-fidelity-bond-for-BIP39-seeds.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - BIP proposal: Timelocked address fidelity bond for BIP39 seeds - 2023-08-02T06:21:58.705963+00:00 - - AdamISZ 2022-05-21 21:36:06+00:00 - - - ZmnSCPxj 2022-05-18 06:29:23+00:00 - - - eric at voskuil.org 2022-05-18 03:06:29+00:00 - - - ZmnSCPxj 2022-05-16 00:00:16+00:00 - - - Chris Belcher 2022-05-15 09:13:39+00:00 - - - ZmnSCPxj 2022-05-13 12:44:14+00:00 - - - Chris Belcher 2022-05-13 10:02:20+00:00 - - - AdamISZ 2022-05-10 19:28:05+00:00 - - - AdamISZ 2022-05-10 19:03:16+00:00 - - - ZmnSCPxj 2022-05-10 16:54:31+00:00 - - - AdamISZ 2022-05-10 12:31:00+00:00 - - - ZmnSCPxj 2022-05-04 04:19:25+00:00 - - - eric at voskuil.org 2022-05-04 04:04:10+00:00 - - - ZmnSCPxj 2022-05-04 02:37:10+00:00 - - - Eric Voskuil 2022-05-03 18:26:52+00:00 - - - Chris Belcher 2022-05-03 18:03:12+00:00 - - - ZmnSCPxj 2022-05-03 05:26:46+00:00 - - - Chris Belcher 2022-05-02 09:23:50+00:00 - - - ZmnSCPxj 2022-05-01 11:41:50+00:00 - - - Chris Belcher 2022-05-01 10:01:49+00:00 - - - ZmnSCPxj 2022-05-01 09:43:39+00:00 - - - Chris Belcher 2022-05-01 08:57:25+00:00 - + 2025-09-26T14:38:18.172067+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds Chris Belcher + 2022-05-01T08:57:00.000Z + + + ZmnSCPxj + 2022-05-01T09:43:00.000Z + + + Chris Belcher + 2022-05-01T10:01:00.000Z + + + ZmnSCPxj + 2022-05-01T11:41:00.000Z + + + Chris Belcher + 2022-05-02T09:23:00.000Z + + + ZmnSCPxj + 2022-05-03T05:26:00.000Z + + + Chris Belcher + 2022-05-03T18:03:00.000Z + + + Eric Voskuil + 2022-05-03T18:26:00.000Z + + + ZmnSCPxj + 2022-05-04T02:37:00.000Z + + + eric + 2022-05-04T04:04:00.000Z + + + ZmnSCPxj + 2022-05-04T04:19:00.000Z + + + AdamISZ + 2022-05-10T12:31:00.000Z + + + ZmnSCPxj + 2022-05-10T16:54:00.000Z + + + AdamISZ + 2022-05-10T19:03:00.000Z + + + AdamISZ + 2022-05-10T19:28:00.000Z + + + Chris Belcher + 2022-05-13T10:02:00.000Z + + + ZmnSCPxj + 2022-05-13T12:44:00.000Z + + + Chris Belcher + 2022-05-15T09:13:00.000Z + + + ZmnSCPxj + 2022-05-16T00:00:00.000Z + + + eric + 2022-05-18T03:06:00.000Z + + + ZmnSCPxj + 2022-05-18T06:29:00.000Z + + + AdamISZ + 2022-05-21T21:36:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: Timelocked address fidelity bond for BIP39 seeds - 2023-08-02T06:21:58.705963+00:00 + 2025-09-26T14:38:18.174396+00:00 - Paragraph 1:The discussion revolves around the concept of fidelity bonds and their use in proving non-dilutability. It is pointed out that the analogy of borrowing gold to make an advertisement and then returning it with interest is not entirely accurate because the same gold atoms cannot be reused in two different advertisements. The suggestion is made to use domain separation tags to ensure fidelity bonds are only used in specific applications, but this relies on social consensus and a clear definition of each application.Paragraph 2:The conversation also explores the idea of using someone else's proof of burn (PoB) to prove an expense. This involves renting someone else's PoB to demonstrate necessary expenses. The defiads scheme utilizes this concept by selling an advertisement created by the covenant and its presumed exclusivity. Paragraph 3:The concept of lending and borrowing scenarios is discussed, where the lender provides the principal amount and is paid interest in exchange, while the borrower uses the principal to generate income. However, if the principal is used as a billboard for an advertisement, it is not being used as money. Instead, a fidelity bond is used to back an assertion of trustworthiness. The term "fidelity bond" is accepted, but it is acknowledged that it is a misleading analogy since proof of burn/work is merely a demonstration of a prior expense.Paragraph 4:In an email exchange, ZmnSCPxj raises privacy concerns regarding linking two identities: JoinMarket maker and Teleport maker. While acknowledging that linking the identities can slightly degrade privacy, it is argued that this must be balanced against the risk of sybil attacks on both systems. Without fidelity bonds, both systems are vulnerable to such attacks, which could result in lost coins.Paragraph 5:The discussion between Chris Belcher and ZmnSCPxj focuses on the use of fidelity bonds in JoinMarket and Teleport. Chris explains that fidelity bond owners can use them in multiple applications, increasing their left-hand-side value while the right-hand-side value remains constant. However, he acknowledges that if two makers in the same application use the same fidelity bond, it could be problematic. Privacy concerns are also addressed, with Chris mentioning the implementation of podle commitments in JoinMarket to combat malicious takers aborting at the last step.Paragraph 6:The conversation between two individuals delves into the concept of renting out fidelity bonds to generate yield. The net present value of a loan is questioned, and an alternative scenario where a landlord pays a lessor rent in exchange for use of the fidelity bond coin is proposed. Risks associated with rental services, such as surveillance and privacy concerns, are discussed. Potential solutions, including removing the intermediate certificate keypair and using pay-for-signature protocols, are suggested.Paragraph 7:The conversation explores the potential market of lessors and the risks associated with rental services. The defiads project is mentioned as an example of a system prioritizing advertisements with larger bonded values. The use of pay-for-signature protocols is proposed to address privacy concerns. The discussion also touches on checking fidelity bonds not being used across multiple makers and whether this deserves a section in the BIP.Paragraph 8:The email exchange between Chris Belcher and ZmnSCPxj addresses the use of the same fidelity bond in both JoinMarket and Teleport. Chris believes it is an intended feature and can be used across different applications without being abusable. However, he acknowledges the potential problem if two makers in the same application use the same fidelity bond. The question of potential abuse is raised.Paragraph 9:The BIP proposes a method for storing timelocked address fidelity bonds in BIP39 phrases and signing fidelity bond certificates. It defines a common derivation scheme for users of wallet software to have a backup of their fidelity bonds. The BIP mainly documents an existing system and provides test vectors and examples of timelocked addresses.Overall, the conversation explores various aspects of fidelity bonds, including their use in proving non-dilutability, lending and borrowing scenarios, privacy concerns, rental services, and the proposed BIP for storing and signing fidelity bond certificates. 2022-05-21T21:36:06+00:00 + Paragraph 1:The discussion revolves around the concept of fidelity bonds and their use in proving non-dilutability. It is pointed out that the analogy of borrowing gold to make an advertisement and then returning it with interest is not entirely accurate because the same gold atoms cannot be reused in two different advertisements. The suggestion is made to use domain separation tags to ensure fidelity bonds are only used in specific applications, but this relies on social consensus and a clear definition of each application.Paragraph 2:The conversation also explores the idea of using someone else's proof of burn (PoB) to prove an expense. This involves renting someone else's PoB to demonstrate necessary expenses. The defiads scheme utilizes this concept by selling an advertisement created by the covenant and its presumed exclusivity. Paragraph 3:The concept of lending and borrowing scenarios is discussed, where the lender provides the principal amount and is paid interest in exchange, while the borrower uses the principal to generate income. However, if the principal is used as a billboard for an advertisement, it is not being used as money. Instead, a fidelity bond is used to back an assertion of trustworthiness. The term "fidelity bond" is accepted, but it is acknowledged that it is a misleading analogy since proof of burn/work is merely a demonstration of a prior expense.Paragraph 4:In an email exchange, ZmnSCPxj raises privacy concerns regarding linking two identities: JoinMarket maker and Teleport maker. While acknowledging that linking the identities can slightly degrade privacy, it is argued that this must be balanced against the risk of sybil attacks on both systems. Without fidelity bonds, both systems are vulnerable to such attacks, which could result in lost coins.Paragraph 5:The discussion between Chris Belcher and ZmnSCPxj focuses on the use of fidelity bonds in JoinMarket and Teleport. Chris explains that fidelity bond owners can use them in multiple applications, increasing their left-hand-side value while the right-hand-side value remains constant. However, he acknowledges that if two makers in the same application use the same fidelity bond, it could be problematic. Privacy concerns are also addressed, with Chris mentioning the implementation of podle commitments in JoinMarket to combat malicious takers aborting at the last step.Paragraph 6:The conversation between two individuals delves into the concept of renting out fidelity bonds to generate yield. The net present value of a loan is questioned, and an alternative scenario where a landlord pays a lessor rent in exchange for use of the fidelity bond coin is proposed. Risks associated with rental services, such as surveillance and privacy concerns, are discussed. Potential solutions, including removing the intermediate certificate keypair and using pay-for-signature protocols, are suggested.Paragraph 7:The conversation explores the potential market of lessors and the risks associated with rental services. The defiads project is mentioned as an example of a system prioritizing advertisements with larger bonded values. The use of pay-for-signature protocols is proposed to address privacy concerns. The discussion also touches on checking fidelity bonds not being used across multiple makers and whether this deserves a section in the BIP.Paragraph 8:The email exchange between Chris Belcher and ZmnSCPxj addresses the use of the same fidelity bond in both JoinMarket and Teleport. Chris believes it is an intended feature and can be used across different applications without being abusable. However, he acknowledges the potential problem if two makers in the same application use the same fidelity bond. The question of potential abuse is raised.Paragraph 9:The BIP proposes a method for storing timelocked address fidelity bonds in BIP39 phrases and signing fidelity bond certificates. It defines a common derivation scheme for users of wallet software to have a backup of their fidelity bonds. The BIP mainly documents an existing system and provides test vectors and examples of timelocked addresses.Overall, the conversation explores various aspects of fidelity bonds, including their use in proving non-dilutability, lending and borrowing scenarios, privacy concerns, rental services, and the proposed BIP for storing and signing fidelity bond certificates. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Bringing-a-nuke-to-a-knife-fight-Transaction-introspection-to-stop-RBF-pinning.xml b/static/bitcoin-dev/May_2022/combined_Bringing-a-nuke-to-a-knife-fight-Transaction-introspection-to-stop-RBF-pinning.xml index 1084689233..cbd13d46e3 100644 --- a/static/bitcoin-dev/May_2022/combined_Bringing-a-nuke-to-a-knife-fight-Transaction-introspection-to-stop-RBF-pinning.xml +++ b/static/bitcoin-dev/May_2022/combined_Bringing-a-nuke-to-a-knife-fight-Transaction-introspection-to-stop-RBF-pinning.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning - 2023-08-02T06:30:27.349277+00:00 - - Greg Sanders 2022-05-12 13:31:02+00:00 - - - David A. Harding 2022-05-12 07:17:05+00:00 - - - Greg Sanders 2022-05-10 18:53:14+00:00 - + 2025-09-26T14:38:33.101022+00:00 + python-feedgen + + + [bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning Greg Sanders + 2022-05-10T18:53:00.000Z + + + David A. Harding + 2022-05-12T07:17:00.000Z + + + Greg Sanders + 2022-05-12T13:31:00.000Z + + - python-feedgen + 2 Combined summary - Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning - 2023-08-02T06:30:27.349277+00:00 + 2025-09-26T14:38:33.101604+00:00 - A proposed update transaction aims to set an upper bound on the final transaction weight. This proposal includes OPTX_SELECT_WEIGHT to push tx weight to stack and conditionally commit to the change output's scriptpubkey for each contract participant. However, concerns arise about pinning an unsubmitted update[-1] under 25,000 vbytes of junk. One suggestion is to raise mempool ancestor/descendant limits in the future. Another idea is to relative-time lock update transactions' state input by one block to close off the vector, allowing for one "update transaction package" at a time in the mempool. The use of ANYONECANPAY-like behavior, such as vault structures, may avoid these issues.The author notes that making the 1,000 vbytes limit smaller would limit the amount of pinning possible but could also discourage people from holding bitcoins in deep taproot trees or sophisticated tapscripts.Another proposal involves adding OPTX_SELECT_WEIGHT to the "state" input's script in an update transaction to set an upper bound on the final transaction weight. Additionally, there would be a conditional commitment to the change output's scriptpubkey via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2 for each contract participant. However, this proposal is met with skepticism due to concerns about mempool spending reintroducing pinning. It is possible for malicious actors to submit unencumbered UTXOs to the mempool, preventing update[-1] from being committed on-chain before its (H|P)TLC timeout.If the proposal of `OPTX_SELECT_WEIGHT OP_TX` is implemented and each update's weight is limited to 1,000 vbytes, Mallory can still pin the unsubmitted update[-1] under 25,000 vbytes of junk. While this proposal makes escaping the pinning cheaper, it does not eliminate the underlying concern. Furthermore, relying on mempool ancestor/descendant limits makes it harder to raise those limits in the future, increasing the risk of node memory/CPU DoS. Therefore, any increase in these limits must be carefully ensured not to increase the risk.A developer shares their thoughts on eltoo designs for Elements and eventual inclusion into Bitcoin, specifically addressing the issue of BIP125 rule#3. This rule requires replacement transactions to pay an absolute fee of at least the sum paid by the original transactions. However, this poses a problem in scenarios like eltoo where fees are required to be brought by the counterparty. This can lead to illicit HTLC timeouts due to low feerate update transactions or bloated inputs/outputs, causing users to pay more sats.To mitigate this pinning, the developer suggests using policy or transaction introspection opcodes. They provide an example using Rusty's OP_TX proposal and continuously spent off-chain state outputs sent to a committed set of outputs. By adding OPTX_SELECT_WEIGHT to the state input's script and conditionally committing to the change output's scriptpubkey via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2, the size of the transaction package submitted to mempools is restricted. The developer also proposes encumbering change outputs to either 1 block CSV encumbered outputs or another OPTX_SELECT_WEIGHT recursively, allowing each counterparty to CPFP N times with each transaction having a maximum weight. The 1 block CSV acts as an "escape hatch" to retrieve the fee output from the covenant structure.In conclusion, the developer acknowledges that dealing with the mempool is challenging, but they suggest that transaction weight, output count, output scriptpubkey, and introspection can be utilized to address these challenges effectively. 2022-05-12T13:31:02+00:00 + A proposed update transaction aims to set an upper bound on the final transaction weight. This proposal includes OPTX_SELECT_WEIGHT to push tx weight to stack and conditionally commit to the change output's scriptpubkey for each contract participant. However, concerns arise about pinning an unsubmitted update[-1] under 25,000 vbytes of junk. One suggestion is to raise mempool ancestor/descendant limits in the future. Another idea is to relative-time lock update transactions' state input by one block to close off the vector, allowing for one "update transaction package" at a time in the mempool. The use of ANYONECANPAY-like behavior, such as vault structures, may avoid these issues.The author notes that making the 1,000 vbytes limit smaller would limit the amount of pinning possible but could also discourage people from holding bitcoins in deep taproot trees or sophisticated tapscripts.Another proposal involves adding OPTX_SELECT_WEIGHT to the "state" input's script in an update transaction to set an upper bound on the final transaction weight. Additionally, there would be a conditional commitment to the change output's scriptpubkey via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2 for each contract participant. However, this proposal is met with skepticism due to concerns about mempool spending reintroducing pinning. It is possible for malicious actors to submit unencumbered UTXOs to the mempool, preventing update[-1] from being committed on-chain before its (H|P)TLC timeout.If the proposal of `OPTX_SELECT_WEIGHT OP_TX` is implemented and each update's weight is limited to 1,000 vbytes, Mallory can still pin the unsubmitted update[-1] under 25,000 vbytes of junk. While this proposal makes escaping the pinning cheaper, it does not eliminate the underlying concern. Furthermore, relying on mempool ancestor/descendant limits makes it harder to raise those limits in the future, increasing the risk of node memory/CPU DoS. Therefore, any increase in these limits must be carefully ensured not to increase the risk.A developer shares their thoughts on eltoo designs for Elements and eventual inclusion into Bitcoin, specifically addressing the issue of BIP125 rule#3. This rule requires replacement transactions to pay an absolute fee of at least the sum paid by the original transactions. However, this poses a problem in scenarios like eltoo where fees are required to be brought by the counterparty. This can lead to illicit HTLC timeouts due to low feerate update transactions or bloated inputs/outputs, causing users to pay more sats.To mitigate this pinning, the developer suggests using policy or transaction introspection opcodes. They provide an example using Rusty's OP_TX proposal and continuously spent off-chain state outputs sent to a committed set of outputs. By adding OPTX_SELECT_WEIGHT to the state input's script and conditionally committing to the change output's scriptpubkey via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2, the size of the transaction package submitted to mempools is restricted. The developer also proposes encumbering change outputs to either 1 block CSV encumbered outputs or another OPTX_SELECT_WEIGHT recursively, allowing each counterparty to CPFP N times with each transaction having a maximum weight. The 1 block CSV acts as an "escape hatch" to retrieve the fee output from the covenant structure.In conclusion, the developer acknowledges that dealing with the mempool is challenging, but they suggest that transaction weight, output count, output scriptpubkey, and introspection can be utilized to address these challenges effectively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_CTV-BIP-Meeting-8-Notes.xml b/static/bitcoin-dev/May_2022/combined_CTV-BIP-Meeting-8-Notes.xml index fc1698808f..eb1f91fed8 100644 --- a/static/bitcoin-dev/May_2022/combined_CTV-BIP-Meeting-8-Notes.xml +++ b/static/bitcoin-dev/May_2022/combined_CTV-BIP-Meeting-8-Notes.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - CTV BIP Meeting #8 Notes - 2023-08-02T06:28:02.023317+00:00 - - Billy Tetrud 2022-05-12 17:28:39+00:00 - - - ZmnSCPxj 2022-05-12 12:20:01+00:00 - - - Jorge Timón 2022-05-12 11:46:45+00:00 - - - Billy Tetrud 2022-05-10 15:09:45+00:00 - - - Keagan McClelland 2022-05-09 15:23:39+00:00 - - - Billy Tetrud 2022-05-08 16:32:45+00:00 - - - ZmnSCPxj 2022-05-07 22:40:10+00:00 - - - Jorge Timón 2022-05-07 13:22:49+00:00 - - - alicexbt 2022-05-07 02:40:36+00:00 - + 2025-09-26T14:38:07.527254+00:00 + python-feedgen + + + [bitcoin-dev] CTV BIP Meeting #8 Notes alicexbt + 2022-05-07T02:40:00.000Z + + + Jorge Timón + 2022-05-07T13:22:00.000Z + + + ZmnSCPxj + 2022-05-07T22:40:00.000Z + + + Billy Tetrud + 2022-05-08T16:32:00.000Z + + + Keagan McClelland + 2022-05-09T15:23:00.000Z + + + Billy Tetrud + 2022-05-10T15:09:00.000Z + + + Jorge Timón + 2022-05-12T11:46:00.000Z + + + ZmnSCPxj + 2022-05-12T12:20:00.000Z + + + Billy Tetrud + 2022-05-12T17:28:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - CTV BIP Meeting #8 Notes - 2023-08-02T06:28:02.023317+00:00 + 2025-09-26T14:38:07.528444+00:00 - In a recent discussion on the Bitcoin development mailing list, it was clarified that recursive covenants do not guarantee any specific outcome in the future. Both recursive and non-recursive covenant opcodes can be used to ensure something will happen, but there is always the possibility of alternative spend paths. A covenant is not just a promise, but also a restriction. Recursive covenants allow for loops in the progression through covenant addresses, enabling infinite recursion and the creation of permanent walled gardens. However, it is important to note that the way covenants are discussed does not always reflect what a particular covenant opcode does, but rather the boundaries of what can be done with it.The distinction between recursive and non-recursive covenants is further elaborated by ZmnSCPxj in response to Jorge's confusion. A covenant is essentially a promise of something happening in the future, while a recursive covenant guarantees that the same thing will happen again in the future. Non-recursive covenants, on the other hand, can also be useful, as they serve their purpose efficiently without relying on recursion. For example, the `OP_EVICT` opcode is designed for a specific use-case and avoids recursion. In different situations, both types of covenants have their importance.The discussion on the bitcoin-dev mailing list revolves around the feasibility and potential use cases of covenants. While the concept of creating walled gardens, such as Visacoin, raises concerns about censorship, it is noted that multisig wallets can achieve similar results without the need for recursive covenants. The conversation also highlights the ability of well-implemented covenant contracts to allow receivers to specify spend conditions, avoiding the receipt of restricted coins. It is argued that dynamic covenants enable more secure wallet vaults and that practical use cases of walled gardens require this dynamicness rather than recursion. The OP_CTV opcode is mentioned as a means of providing non-recursive covenants, and it is emphasized that no combination of future opcodes can enable recursion or dynamicness to an OP_CTV call. The discussion concludes by acknowledging the different possibilities and limitations of covenants in the Bitcoin ecosystem.In relation to potential attacks based on covenants, the discussion explores the idea of governments mandating certain spend conditions for Bitcoin. It is argued that this would require a law to force the acceptance of these conditions for services. To defend against receiving "tainted" coins, it is suggested that compliant scripts be generated to receive funds, allowing the receiver to avoid restricted coins. This places the risk solely on the receiver. Additionally, organizations with incompatible interests would want to choose their own spend conditions when transferring funds, rather than inheriting the conditions of the spender. Therefore, the implementation and trustworthiness of parties involved play a significant role in mitigating risks associated with covenants.The conversation delves into the implementation of walled gardens using covenants and highlights the need for dynamic rather than recursive covenants for practicality. A static walled garden created through infinite recursion would not be able to accommodate new addresses. Dynamicness is achieved by dynamically specifying destination addresses, enabling users to send funds to arbitrary public keys while still allowing the government to spend the funds. The OP_CHECKOUTPUTVERIFY opcode is mentioned as a means of providing this dynamicness and enhancing wallet vault security. Concerns about potential attacks, such as visacoin, which requires recursive covenants, are deemed unwarranted given that OP_CTV cannot be used for such purposes.In a BitcoinTalk thread, concerns are raised about potential attacks enabled by covenants, with visacoin being considered particularly alarming. However, it is clarified that `OP_CTV` has enabled non-recursive covenant opcodes, making it possible to have covenants without recursion. It is emphasized that `OP_CTV` cannot be used to implement visacoin, as it requires a recursive covenant.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin development. Concerns about attacks based on covenants are raised, with visacoin mentioned as a potential threat. The conversation also touches on the APO version of the simple vault, comparing CTV with other covenant proposals, and addressing concerns about recursive covenants. The meeting summary includes information on the vulnerabilities of the APO version of the simple vault and the unusability of APO as a CTV alternative. It also mentions Fiatjaf's CTV spacechain demo and the discussions surrounding recursive covenants and responding to FUD (fear, uncertainty, and doubt). The overall discussion highlights the different aspects and considerations involved in Bitcoin development.During the last CTV meeting, several topics were discussed, including the vulnerabilities of the APO version of the simple vault and its usability as a CTV alternative. The meeting also covered Fiatjaf's CTV spacechain demo and comparisons between CTV and other covenant proposals. There was a discussion on recursive c 2022-05-12T17:28:39+00:00 + In a recent discussion on the Bitcoin development mailing list, it was clarified that recursive covenants do not guarantee any specific outcome in the future. Both recursive and non-recursive covenant opcodes can be used to ensure something will happen, but there is always the possibility of alternative spend paths. A covenant is not just a promise, but also a restriction. Recursive covenants allow for loops in the progression through covenant addresses, enabling infinite recursion and the creation of permanent walled gardens. However, it is important to note that the way covenants are discussed does not always reflect what a particular covenant opcode does, but rather the boundaries of what can be done with it.The distinction between recursive and non-recursive covenants is further elaborated by ZmnSCPxj in response to Jorge's confusion. A covenant is essentially a promise of something happening in the future, while a recursive covenant guarantees that the same thing will happen again in the future. Non-recursive covenants, on the other hand, can also be useful, as they serve their purpose efficiently without relying on recursion. For example, the `OP_EVICT` opcode is designed for a specific use-case and avoids recursion. In different situations, both types of covenants have their importance.The discussion on the bitcoin-dev mailing list revolves around the feasibility and potential use cases of covenants. While the concept of creating walled gardens, such as Visacoin, raises concerns about censorship, it is noted that multisig wallets can achieve similar results without the need for recursive covenants. The conversation also highlights the ability of well-implemented covenant contracts to allow receivers to specify spend conditions, avoiding the receipt of restricted coins. It is argued that dynamic covenants enable more secure wallet vaults and that practical use cases of walled gardens require this dynamicness rather than recursion. The OP_CTV opcode is mentioned as a means of providing non-recursive covenants, and it is emphasized that no combination of future opcodes can enable recursion or dynamicness to an OP_CTV call. The discussion concludes by acknowledging the different possibilities and limitations of covenants in the Bitcoin ecosystem.In relation to potential attacks based on covenants, the discussion explores the idea of governments mandating certain spend conditions for Bitcoin. It is argued that this would require a law to force the acceptance of these conditions for services. To defend against receiving "tainted" coins, it is suggested that compliant scripts be generated to receive funds, allowing the receiver to avoid restricted coins. This places the risk solely on the receiver. Additionally, organizations with incompatible interests would want to choose their own spend conditions when transferring funds, rather than inheriting the conditions of the spender. Therefore, the implementation and trustworthiness of parties involved play a significant role in mitigating risks associated with covenants.The conversation delves into the implementation of walled gardens using covenants and highlights the need for dynamic rather than recursive covenants for practicality. A static walled garden created through infinite recursion would not be able to accommodate new addresses. Dynamicness is achieved by dynamically specifying destination addresses, enabling users to send funds to arbitrary public keys while still allowing the government to spend the funds. The OP_CHECKOUTPUTVERIFY opcode is mentioned as a means of providing this dynamicness and enhancing wallet vault security. Concerns about potential attacks, such as visacoin, which requires recursive covenants, are deemed unwarranted given that OP_CTV cannot be used for such purposes.In a BitcoinTalk thread, concerns are raised about potential attacks enabled by covenants, with visacoin being considered particularly alarming. However, it is clarified that `OP_CTV` has enabled non-recursive covenant opcodes, making it possible to have covenants without recursion. It is emphasized that `OP_CTV` cannot be used to implement visacoin, as it requires a recursive covenant.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin development. Concerns about attacks based on covenants are raised, with visacoin mentioned as a potential threat. The conversation also touches on the APO version of the simple vault, comparing CTV with other covenant proposals, and addressing concerns about recursive covenants. The meeting summary includes information on the vulnerabilities of the APO version of the simple vault and the unusability of APO as a CTV alternative. It also mentions Fiatjaf's CTV spacechain demo and the discussions surrounding recursive covenants and responding to FUD (fear, uncertainty, and doubt). The overall discussion highlights the different aspects and considerations involved in Bitcoin development.During the last CTV meeting, several topics were discussed, including the vulnerabilities of the APO version of the simple vault and its usability as a CTV alternative. The meeting also covered Fiatjaf's CTV spacechain demo and comparisons between CTV and other covenant proposals. There was a discussion on recursive c - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_CTV-BIP-Meeting-9-Notes.xml b/static/bitcoin-dev/May_2022/combined_CTV-BIP-Meeting-9-Notes.xml index 2a4a0566c7..72e57f97af 100644 --- a/static/bitcoin-dev/May_2022/combined_CTV-BIP-Meeting-9-Notes.xml +++ b/static/bitcoin-dev/May_2022/combined_CTV-BIP-Meeting-9-Notes.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - CTV BIP Meeting #9 Notes - 2023-08-02T06:37:12.834569+00:00 - - Bram Cohen 2022-05-21 15:37:51+00:00 - - - ZmnSCPxj 2022-05-20 23:47:54+00:00 - - - alicexbt 2022-05-20 23:23:58+00:00 - - - ZmnSCPxj 2022-05-20 01:03:11+00:00 - - - alicexbt 2022-05-19 15:57:55+00:00 - + 2025-09-26T14:38:39.431691+00:00 + python-feedgen + + + [bitcoin-dev] CTV BIP Meeting #9 Notes alicexbt + 2022-05-19T15:57:00.000Z + + + ZmnSCPxj + 2022-05-20T01:03:00.000Z + + + alicexbt + 2022-05-20T23:23:00.000Z + + + ZmnSCPxj + 2022-05-20T23:47:00.000Z + + + Bram Cohen + 2022-05-21T15:37:00.000Z + + - python-feedgen + 2 Combined summary - CTV BIP Meeting #9 Notes - 2023-08-02T06:37:12.834569+00:00 + 2025-09-26T14:38:39.432474+00:00 - In a recent discussion on the Bitcoin-dev mailing list, concerns were raised about MEV (Maximal Extractable Value) and its association with general covenants. MEV refers to miners analyzing contract execution to order transactions in a way that maximizes their profit. One proposed solution to address MEV is to ensure all transactions in a block occur simultaneously by limiting price oracles to report only one price per block. However, this would require a new signature opcode.ZmnSCPxj discusses the vulnerability of covenant mechanisms to MEV, specifically mentioning the `OP_CSFS` and `OP_CAT` mechanisms. These mechanisms require copying parts of the transaction into the witness data for covenants, with `OP_CSFS` needing large scripts if used for covenants. ZmnSCPxj suggests creating an opcode explicitly supporting recursion to better support recursive covenants and reduce the amount of data pushed on the witness stack.MEV poses a problem for complex smart contracts, as miners can manipulate transaction order for their own profit. Privacy mechanisms like Taproot, which reveal only one branch at a time, are proposed as a solution. Covenant mechanisms requiring large witness data are more vulnerable to MEV, as miners may prefer branches with smaller witnesses. To prevent this, burdening the disputant considered "wrong" with the larger witness is suggested.The recent CTV meeting addressed topics such as OP_TX, OP_CAT/CSFS/General Covenants, and Script Interpreter Flags. The discussion included evaluating CTV/NOP upgradability versus multibyte op-success and considering the use of OP_TX for CTV. Concerns about general covenants were discussed, with some users expressing fears of censorship and imposition of covenants without consent. MEV was also mentioned as an issue associated with general covenants, similar to Ethereum's MEV.The meeting concluded with thoughts on documenting the rules enforced by flags, re-evaluating the test flags infrastructure, and considering script enforcement in light of taproot implementation. Overall, the discussion highlighted the need to address MEV and vulnerabilities in covenant mechanisms while ensuring privacy and consensus stability. 2022-05-21T15:37:51+00:00 + In a recent discussion on the Bitcoin-dev mailing list, concerns were raised about MEV (Maximal Extractable Value) and its association with general covenants. MEV refers to miners analyzing contract execution to order transactions in a way that maximizes their profit. One proposed solution to address MEV is to ensure all transactions in a block occur simultaneously by limiting price oracles to report only one price per block. However, this would require a new signature opcode.ZmnSCPxj discusses the vulnerability of covenant mechanisms to MEV, specifically mentioning the `OP_CSFS` and `OP_CAT` mechanisms. These mechanisms require copying parts of the transaction into the witness data for covenants, with `OP_CSFS` needing large scripts if used for covenants. ZmnSCPxj suggests creating an opcode explicitly supporting recursion to better support recursive covenants and reduce the amount of data pushed on the witness stack.MEV poses a problem for complex smart contracts, as miners can manipulate transaction order for their own profit. Privacy mechanisms like Taproot, which reveal only one branch at a time, are proposed as a solution. Covenant mechanisms requiring large witness data are more vulnerable to MEV, as miners may prefer branches with smaller witnesses. To prevent this, burdening the disputant considered "wrong" with the larger witness is suggested.The recent CTV meeting addressed topics such as OP_TX, OP_CAT/CSFS/General Covenants, and Script Interpreter Flags. The discussion included evaluating CTV/NOP upgradability versus multibyte op-success and considering the use of OP_TX for CTV. Concerns about general covenants were discussed, with some users expressing fears of censorship and imposition of covenants without consent. MEV was also mentioned as an issue associated with general covenants, similar to Ethereum's MEV.The meeting concluded with thoughts on documenting the rules enforced by flags, re-evaluating the test flags infrastructure, and considering script enforcement in light of taproot implementation. Overall, the discussion highlighted the need to address MEV and vulnerabilities in covenant mechanisms while ensuring privacy and consensus stability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml b/static/bitcoin-dev/May_2022/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml index c0e69005e4..6452d4fb60 100644 --- a/static/bitcoin-dev/May_2022/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml +++ b/static/bitcoin-dev/May_2022/combined_Conjectures-on-solving-the-high-interactivity-issue-in-payment-pools-and-channel-factories.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Conjectures on solving the high interactivity issue in payment pools and channel factories - 2023-08-02T06:18:48.419381+00:00 - - Antoine Riard 2023-04-18 03:38:57+00:00 - - - jlspc 2023-03-17 20:54:51+00:00 - - - Billy Tetrud 2022-05-12 17:36:25+00:00 - - - ZmnSCPxj 2022-05-10 16:45:19+00:00 - - - Antoine Riard 2022-05-10 00:38:36+00:00 - - - Billy Tetrud 2022-05-01 22:53:13+00:00 - - - Antoine Riard 2022-04-28 13:18:05+00:00 - + 2025-09-26T14:38:01.120481+00:00 + python-feedgen + + + [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories Antoine Riard + 2022-04-28T13:18:00.000Z + + + Billy Tetrud + 2022-05-01T22:53:00.000Z + + + Antoine Riard + 2022-05-10T00:38:00.000Z + + + ZmnSCPxj + 2022-05-10T16:45:00.000Z + + + Billy Tetrud + 2022-05-12T17:36:00.000Z + + + jlspc + 2023-03-17T20:54:00.000Z + + + Antoine Riard + 2023-04-18T03:38:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Conjectures on solving the high interactivity issue in payment pools and channel factories - 2023-08-02T06:18:48.420890+00:00 + 2025-09-26T14:38:01.121356+00:00 - The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels. 2023-04-18T03:38:57+00:00 + The email thread discusses the issue of interactivity and liveliness requirements in Bitcoin's Lightning Network. The author suggests that constructions requiring all users to be online and exchange round of signatures for balance distribution would get stalled with just one lazy, buggy, or offline user. The early deployment of LN showed the resort to delegated channel hosting solutions to relieve users from the liveliness requirement. The author further suggests a trust-minimized solution enabling non-interactive, off-chain updates of the pool/factory, with no or minimal consumption of blockspace.The discussion also highlights different security models for addressing the double-spend issue of off-chain Bitcoin transactions. It mentions two main models: prophylactic and corrective. The article proposes a third solution that uses separate control transactions and value transactions. Examples of such solutions are the Tunable-Penalty Factory protocol and the LN-Penalty. However, the penalty mechanism that allows a "wronged" user to take some or all of a dishonest user's funds could be exploited by a malicious coalition.The conversation between Antoine and Billy revolves around predicting liquidity needs in sub-pools. There are concerns about fan-out transactions interfering with confirmation of simple withdrawal transactions and whether sub-pool states could be used honestly and structured trustlessly. The possibility of an always-online service using the receiving key in spending mode if the balance stacked there becomes relevant is discussed. The gitlab.com/lightning-signer/docs is mentioned as a work in progress in this direction. The issue of a malicious participant committing off-chain balance in two partitions and sending spends to the hosting "receiving-keys" entities without their knowledge is also addressed.The email exchange between Billy and ZmnSCPxj focuses on partitioning and solving the issues related to it. Two techniques are suggested: creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, and having each sub-pool have only two participants to reduce disruption if any one pool participant is down. The discussion concludes that large multi-participant pools with sub-pools are essentially just channel factories with good tradeoffs.The conversation between Antoine and Billy discusses the challenges of partitioning multi-party constructions and preventing double-spending. Possible solutions suggested include creating sub-pools that can be used by sub-pool participants later without the whole group's involvement, or having an always-online system capable of signing only for group updates that do not change the owner's balance in the group. However, equivocation is still a hard issue with partitioning multi-party constructions.The post also explores the issue of interactivity with payment pools and channel factories when there are many participants involved. Several solutions have been proposed, such as timelocked kick-out abilities or assuming the widespread usage of node towers among the pool participants. It suggests non-interactive off-chain pool partitions as a trust-minimized solution, where if a pool update fails due to lack of online unanimity, a partition request could be exchanged among the online subset of users ("the actives"). Various trust-minimization trade-offs can be made in the publication of partition statements.Lastly, the post addresses the process of partitioning in a Bitcoin mining pool and proposes a new consensus data structure to register and order the partition statements. It discusses the cost and economic attractiveness of pool partitioning and suggests leveraging covenants and revocation mechanisms to solve security issues. The double-spend issue is already addressed on the Bitcoin base-layer and in payment channels. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Improving-BIP-8-soft-fork-activation.xml b/static/bitcoin-dev/May_2022/combined_Improving-BIP-8-soft-fork-activation.xml index 99e5e82281..1751ef503a 100644 --- a/static/bitcoin-dev/May_2022/combined_Improving-BIP-8-soft-fork-activation.xml +++ b/static/bitcoin-dev/May_2022/combined_Improving-BIP-8-soft-fork-activation.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Improving BIP 8 soft fork activation - 2023-08-02T06:30:03.022610+00:00 - - Billy Tetrud 2022-05-13 12:23:39+00:00 - - - Greg Sanders 2022-05-12 22:56:22+00:00 - - - alicexbt 2022-05-12 19:59:38+00:00 - - - Russell O'Connor 2022-05-11 19:22:40+00:00 - - - alicexbt 2022-05-11 15:15:15+00:00 - - - Billy Tetrud 2022-05-10 15:31:17+00:00 - - - alicexbt 2022-05-10 13:40:37+00:00 - + 2025-09-26T14:38:03.233667+00:00 + python-feedgen + + + [bitcoin-dev] Improving BIP 8 soft fork activation alicexbt + 2022-05-10T13:40:00.000Z + + + Billy Tetrud + 2022-05-10T15:31:00.000Z + + + alicexbt + 2022-05-11T15:15:00.000Z + + + Russell O'Connor + 2022-05-11T19:22:00.000Z + + + alicexbt + 2022-05-12T19:59:00.000Z + + + Greg Sanders + 2022-05-12T22:56:00.000Z + + + Billy Tetrud + 2022-05-13T12:23:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Improving BIP 8 soft fork activation - 2023-08-02T06:30:03.022610+00:00 + 2025-09-26T14:38:03.234503+00:00 - A proposal has been made to change the activation mechanism for soft forks in Bitcoin. The proposal suggests removing the lockinontimeout (LOT) flag and instead calculating the MUST_SIGNAL state based on the threshold reached. This proposal also introduces tri-state version signaling that can encode both active support and active opposition to a soft fork. However, some concerns were raised about the potential risk of taking a large fraction of mining hardware offline for an extended period of time with this new mechanism.Russell O'Connor responded to the proposal, stating that the MUST_SIGNAL state is no longer necessary as there are currently no other clients to activate alongside a BIP8 deployment. He proposed using an anti-fork signal that only needs to be on a single block and can be almost anything to prepare for an "anti-fork." Russell also mentioned the risk of losing mining power if miners do not conform or are unable to conform to the version bits signal over multiple blocks. He suggested various solutions, including developers planning and shipping binaries with activation code in time, mining pools participating in discussions and hiring competent developers, and reaching out to the community for help if needed.Another user named Billy Tetrud provided feedback on the proposal, acknowledging its usefulness and agreeing that there are issues with the current activation methods. Billy suggested a minor improvement to specify "minimum_activation_blocks" instead of "minimum_activation_height" for easier reasoning and flexibility. He gave a concept ACK and expressed the preference for future soft forks to use a previously specified activation mechanism rather than rolling out rushed implementations.In conclusion, the concept of a MUST_SIGNAL state for BIP8 activation has been deemed unnecessary by some developers. The purpose of mandatory signaling was to ensure all existing clients waiting for SegWit signaling would be activated together with any BIP8 clients, but it is no longer necessary. There are alternative design choices available that do not pose the risk of taking a significant amount of mining hardware offline. The proposal suggests using version bit signaling and a soft-fork signal on a single block. Additionally, solutions were proposed to address the risk of losing mining power, such as better planning, active participation from mining pools, and collaboration within the developer community.Overall, the discussion revolves around the optimization of soft fork activation methods in Bitcoin and finding alternatives to the MUST_SIGNAL state in BIP8. The proposals and feedback provided offer insights into potential improvements and considerations for future soft forks. 2022-05-13T12:23:39+00:00 + A proposal has been made to change the activation mechanism for soft forks in Bitcoin. The proposal suggests removing the lockinontimeout (LOT) flag and instead calculating the MUST_SIGNAL state based on the threshold reached. This proposal also introduces tri-state version signaling that can encode both active support and active opposition to a soft fork. However, some concerns were raised about the potential risk of taking a large fraction of mining hardware offline for an extended period of time with this new mechanism.Russell O'Connor responded to the proposal, stating that the MUST_SIGNAL state is no longer necessary as there are currently no other clients to activate alongside a BIP8 deployment. He proposed using an anti-fork signal that only needs to be on a single block and can be almost anything to prepare for an "anti-fork." Russell also mentioned the risk of losing mining power if miners do not conform or are unable to conform to the version bits signal over multiple blocks. He suggested various solutions, including developers planning and shipping binaries with activation code in time, mining pools participating in discussions and hiring competent developers, and reaching out to the community for help if needed.Another user named Billy Tetrud provided feedback on the proposal, acknowledging its usefulness and agreeing that there are issues with the current activation methods. Billy suggested a minor improvement to specify "minimum_activation_blocks" instead of "minimum_activation_height" for easier reasoning and flexibility. He gave a concept ACK and expressed the preference for future soft forks to use a previously specified activation mechanism rather than rolling out rushed implementations.In conclusion, the concept of a MUST_SIGNAL state for BIP8 activation has been deemed unnecessary by some developers. The purpose of mandatory signaling was to ensure all existing clients waiting for SegWit signaling would be activated together with any BIP8 clients, but it is no longer necessary. There are alternative design choices available that do not pose the risk of taking a significant amount of mining hardware offline. The proposal suggests using version bit signaling and a soft-fork signal on a single block. Additionally, solutions were proposed to address the risk of losing mining power, such as better planning, active participation from mining pools, and collaboration within the developer community.Overall, the discussion revolves around the optimization of soft fork activation methods in Bitcoin and finding alternatives to the MUST_SIGNAL state in BIP8. The proposals and feedback provided offer insights into potential improvements and considerations for future soft forks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Improving-chaumian-ecash-and-sidechains-with-fidelity-bond-federations.xml b/static/bitcoin-dev/May_2022/combined_Improving-chaumian-ecash-and-sidechains-with-fidelity-bond-federations.xml index fb2f5fab81..44c7f18642 100644 --- a/static/bitcoin-dev/May_2022/combined_Improving-chaumian-ecash-and-sidechains-with-fidelity-bond-federations.xml +++ b/static/bitcoin-dev/May_2022/combined_Improving-chaumian-ecash-and-sidechains-with-fidelity-bond-federations.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Improving chaumian ecash and sidechains with fidelity bond federations - 2023-08-02T06:30:43.484304+00:00 - - ZmnSCPxj 2022-05-16 11:26:38+00:00 - - - Chris Belcher 2022-05-16 10:26:45+00:00 - + 2025-09-26T14:38:20.288187+00:00 + python-feedgen + + + [bitcoin-dev] Improving chaumian ecash and sidechains with fidelity bond federations Chris Belcher + 2022-05-16T10:26:00.000Z + + + ZmnSCPxj + 2022-05-16T11:26:00.000Z + + - python-feedgen + 2 Combined summary - Improving chaumian ecash and sidechains with fidelity bond federations - 2023-08-02T06:30:43.484304+00:00 + 2025-09-26T14:38:20.288581+00:00 - ZmnSCPxj, a blockchain developer, has put forward a new proposal that involves dividing transaction fees from sidechains or ecash servers among fidelity bonds based on their respective values. This concept is reminiscent of ZmnSCPxj's previous idea of "mainstake," which entails locking up funds on the mainchain to construct new sidechain blocks. Under this scheme, the allocation of sideblocks would be proportional to the value of the mainstake that was locked up. Importantly, this approach can also be applied to other scenarios requiring federations. For instance, statechains, which function as federation-guarded CoinPools, could adopt a similar mechanism for selecting federation members. Additionally, fidelity bonds can guide users in choosing federation members for unchained smart contracts.The utilization of fidelity bonds aims to establish trust-minimized federations for chaumian ecash servers or sidechains. Fidelity bonds serve as a means of deliberately sacrificing bitcoin value in a manner that can be verified by a third party. This system has already been implemented in JoinMarket since August 2021, with approximately 600 BTC being locked up, some for extended periods. The value of a fidelity bond is calculated using a greater-than-linear power of the bitcoin sacrifice, thereby creating a strong incentive for distinct fidelity bonds to be controlled by different individuals. Rational behavior dictates that all bitcoins should be consolidated into one fidelity bond rather than distributed across multiple bonds, which mathematically penalizes sybil attackers seeking to distribute their bitcoins over numerous bonds. It is worth noting that fidelity bonds do not resolve the trust issue entirely, as an individual with a significant fidelity bond could still potentially steal funds from the ecash server or sidechain using their control over multisig keys. However, fidelity bonds greatly incentivize the ownership of distinct fidelity bonds by different individuals. Another advantage of fidelity bonds is that they align with the cypherpunk ethos, allowing anyone to create and advertise a fidelity bond on the market.To implement this scheme, each fidelity bond owner would generate a key within the multisig framework. Transaction fees from the sidechain or ecash server would then be distributed among fidelity bonds in proportion to their respective fidelity bond values. This approach effectively ensures that the benefits are shared based on the level of commitment represented by the fidelity bonds. 2022-05-16T11:26:38+00:00 + ZmnSCPxj, a blockchain developer, has put forward a new proposal that involves dividing transaction fees from sidechains or ecash servers among fidelity bonds based on their respective values. This concept is reminiscent of ZmnSCPxj's previous idea of "mainstake," which entails locking up funds on the mainchain to construct new sidechain blocks. Under this scheme, the allocation of sideblocks would be proportional to the value of the mainstake that was locked up. Importantly, this approach can also be applied to other scenarios requiring federations. For instance, statechains, which function as federation-guarded CoinPools, could adopt a similar mechanism for selecting federation members. Additionally, fidelity bonds can guide users in choosing federation members for unchained smart contracts.The utilization of fidelity bonds aims to establish trust-minimized federations for chaumian ecash servers or sidechains. Fidelity bonds serve as a means of deliberately sacrificing bitcoin value in a manner that can be verified by a third party. This system has already been implemented in JoinMarket since August 2021, with approximately 600 BTC being locked up, some for extended periods. The value of a fidelity bond is calculated using a greater-than-linear power of the bitcoin sacrifice, thereby creating a strong incentive for distinct fidelity bonds to be controlled by different individuals. Rational behavior dictates that all bitcoins should be consolidated into one fidelity bond rather than distributed across multiple bonds, which mathematically penalizes sybil attackers seeking to distribute their bitcoins over numerous bonds. It is worth noting that fidelity bonds do not resolve the trust issue entirely, as an individual with a significant fidelity bond could still potentially steal funds from the ecash server or sidechain using their control over multisig keys. However, fidelity bonds greatly incentivize the ownership of distinct fidelity bonds by different individuals. Another advantage of fidelity bonds is that they align with the cypherpunk ethos, allowing anyone to create and advertise a fidelity bond on the market.To implement this scheme, each fidelity bond owner would generate a key within the multisig framework. Transaction fees from the sidechain or ecash server would then be distributed among fidelity bonds in proportion to their respective fidelity bond values. This approach effectively ensures that the benefits are shared based on the level of commitment represented by the fidelity bonds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_MuSig2-BIP.xml b/static/bitcoin-dev/May_2022/combined_MuSig2-BIP.xml index 74cf7342a4..78f298dedf 100644 --- a/static/bitcoin-dev/May_2022/combined_MuSig2-BIP.xml +++ b/static/bitcoin-dev/May_2022/combined_MuSig2-BIP.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 - - Jonas Nick 2022-11-03 14:43:22+00:00 - - - Jonas Nick 2022-10-11 15:34:23+00:00 - - - Jonas Nick 2022-10-03 20:41:08+00:00 - - - AdamISZ 2022-06-12 23:07:08+00:00 - - - AdamISZ 2022-05-26 17:34:47+00:00 - - - Jonas Nick 2022-05-26 15:32:33+00:00 - - - AdamISZ 2022-05-24 19:06:41+00:00 - - - AdamISZ 2022-05-23 22:09:52+00:00 - - - Jonas Nick 2022-05-23 15:56:54+00:00 - - - AdamISZ 2022-05-22 22:26:08+00:00 - - - Jonas Nick 2022-04-28 19:18:34+00:00 - - - Brandon Black 2022-04-28 15:33:42+00:00 - - - Olaoluwa Osuntokun 2022-04-28 03:53:59+00:00 - - - Olaoluwa Osuntokun 2022-04-28 01:47:33+00:00 - - - Jonas Nick 2022-04-05 22:57:13+00:00 - + 2025-09-26T14:38:28.836465+00:00 + python-feedgen + + + [bitcoin-dev] MuSig2 BIP Jonas Nick + 2022-04-05T22:57:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T01:47:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T03:53:00.000Z + + + Brandon Black + 2022-04-28T15:33:00.000Z + + + Jonas Nick + 2022-04-28T19:18:00.000Z + + + AdamISZ + 2022-05-22T22:26:00.000Z + + + Jonas Nick + 2022-05-23T15:56:00.000Z + + + AdamISZ + 2022-05-23T22:09:00.000Z + + + AdamISZ + 2022-05-24T19:06:00.000Z + + + Jonas Nick + 2022-05-26T15:32:00.000Z + + + AdamISZ + 2022-05-26T17:34:00.000Z + + + AdamISZ + 2022-06-12T23:07:00.000Z + + + Jonas Nick + 2022-10-03T20:41:00.000Z + + + Jonas Nick + 2022-10-11T15:34:00.000Z + + + Jonas Nick + 2022-11-03T14:43:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 + 2025-09-26T14:38:28.838005+00:00 - The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary 2022-11-03T14:43:22+00:00 + The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Multiple-ways-to-do-bitcoin-covenants.xml b/static/bitcoin-dev/May_2022/combined_Multiple-ways-to-do-bitcoin-covenants.xml index d2ea34bcec..701d98840b 100644 --- a/static/bitcoin-dev/May_2022/combined_Multiple-ways-to-do-bitcoin-covenants.xml +++ b/static/bitcoin-dev/May_2022/combined_Multiple-ways-to-do-bitcoin-covenants.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Multiple ways to do bitcoin covenants - 2023-08-02T06:18:07.113596+00:00 - - Billy Tetrud 2022-05-01 23:02:55+00:00 - - - alicexbt 2022-04-28 08:11:28+00:00 - + 2025-09-26T14:38:13.902897+00:00 + python-feedgen + + + [bitcoin-dev] Multiple ways to do bitcoin covenants alicexbt + 2022-04-28T08:11:00.000Z + + + Billy Tetrud + 2022-05-01T23:02:00.000Z + + - python-feedgen + 2 Combined summary - Multiple ways to do bitcoin covenants - 2023-08-02T06:18:07.113596+00:00 + 2025-09-26T14:38:13.903342+00:00 - The author of the context has been analyzing various covenant proposals with a focus on wallet vaults. Among the options discussed, CTV (Covenant Transaction Verification) is considered as the minimal covenant opcode that addresses malleability issues. Other proposed opcodes have potential undesirable effects when interacting with existing systems. Another option, TXHASH+CSFS, offers similar capabilities to CTV but is more complex due to additional features. APO wallet vaults are deemed hacky, inefficient, and limited in their functionality. TLUV + IN_OUT_AMOUNT allows for infinitely recursive covenants, but it has limitations with multi-input transactions. OP_CHECKOUTPUTVERIFY is an interesting opcode that enables recursive covenants but shares similar limitations as TLUV + IN_OUT_AMOUNT with multi-input transactions, and it also incurs high costs beyond simple covenants. While some of these covenant opcodes have been specified and analyzed to some extent, none except CTV (potentially TXHASH+CSFS) seem to be of sufficient quality to be implemented in Bitcoin in their current state. The author favors CTV due to its simplicity, efficiency in block space usage, and the ability to be utilized even without taproot.However, it is acknowledged that different developers may have preferences for alternative methods of implementing Bitcoin covenants for various reasons. Recent discussions and explorations have centered around CTV and other covenant proposals. One question raised was whether Bitcoin already has opcodes with overlapping features, and the answer is affirmative. It is indeed possible to have multiple ways to achieve Bitcoin covenants with some tradeoffs.The author also questions the tradeoffs between CTV, APO, TLUV, and TXHASH+CSFS. While the first question received answers from Jeremy and sheshek in the CTV chat, there is no clear consensus regarding the second question.When comparing the different options, the author reiterates their preference for CTV due to its simplicity, block space efficiency, and ability to be used independently of taproot. It is important to consider bare script to expose a public key in the case of an EC (Elliptic Curve) break, as relying solely on vaults can lead to potential vulnerabilities. Additionally, with the growing prevalence of quantum computing, it is unsustainable to force everyone into a quantum-unsafe position.However, it is acknowledged that other developers may have different preferences for implementing Bitcoin covenants. For example, Russel O'Connor favors the general OP_TXHASH design. 2022-05-01T23:02:55+00:00 + The author of the context has been analyzing various covenant proposals with a focus on wallet vaults. Among the options discussed, CTV (Covenant Transaction Verification) is considered as the minimal covenant opcode that addresses malleability issues. Other proposed opcodes have potential undesirable effects when interacting with existing systems. Another option, TXHASH+CSFS, offers similar capabilities to CTV but is more complex due to additional features. APO wallet vaults are deemed hacky, inefficient, and limited in their functionality. TLUV + IN_OUT_AMOUNT allows for infinitely recursive covenants, but it has limitations with multi-input transactions. OP_CHECKOUTPUTVERIFY is an interesting opcode that enables recursive covenants but shares similar limitations as TLUV + IN_OUT_AMOUNT with multi-input transactions, and it also incurs high costs beyond simple covenants. While some of these covenant opcodes have been specified and analyzed to some extent, none except CTV (potentially TXHASH+CSFS) seem to be of sufficient quality to be implemented in Bitcoin in their current state. The author favors CTV due to its simplicity, efficiency in block space usage, and the ability to be utilized even without taproot.However, it is acknowledged that different developers may have preferences for alternative methods of implementing Bitcoin covenants for various reasons. Recent discussions and explorations have centered around CTV and other covenant proposals. One question raised was whether Bitcoin already has opcodes with overlapping features, and the answer is affirmative. It is indeed possible to have multiple ways to achieve Bitcoin covenants with some tradeoffs.The author also questions the tradeoffs between CTV, APO, TLUV, and TXHASH+CSFS. While the first question received answers from Jeremy and sheshek in the CTV chat, there is no clear consensus regarding the second question.When comparing the different options, the author reiterates their preference for CTV due to its simplicity, block space efficiency, and ability to be used independently of taproot. It is important to consider bare script to expose a public key in the case of an EC (Elliptic Curve) break, as relying solely on vaults can lead to potential vulnerabilities. Additionally, with the growing prevalence of quantum computing, it is unsustainable to force everyone into a quantum-unsafe position.However, it is acknowledged that other developers may have different preferences for implementing Bitcoin covenants. For example, Russel O'Connor favors the general OP_TXHASH design. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Package-Relay-Proposal.xml b/static/bitcoin-dev/May_2022/combined_Package-Relay-Proposal.xml index e4d767fcb0..5de7b50825 100644 --- a/static/bitcoin-dev/May_2022/combined_Package-Relay-Proposal.xml +++ b/static/bitcoin-dev/May_2022/combined_Package-Relay-Proposal.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Package Relay Proposal - 2023-08-02T06:32:07.153762+00:00 - - Greg Sanders 2023-05-10 15:42:34+00:00 - - - Tom Trevethan 2023-05-10 15:12:04+00:00 - - - Gloria Zhao 2022-11-01 18:03:22+00:00 - - - Antoine Riard 2022-06-17 20:08:36+00:00 - - - Gloria Zhao 2022-06-14 09:59:23+00:00 - - - Suhas Daftuar 2022-06-08 15:59:03+00:00 - - - Gloria Zhao 2022-06-07 17:44:45+00:00 - - - Gloria Zhao 2022-05-28 01:54:13+00:00 - - - eric at voskuil.org 2022-05-26 02:59:01+00:00 - - - eric at voskuil.org 2022-05-25 20:52:07+00:00 - - - Anthony Towns 2022-05-25 18:55:35+00:00 - - - Eric Voskuil 2022-05-24 23:43:57+00:00 - - - Gloria Zhao 2022-05-24 21:05:35+00:00 - - - Anthony Towns 2022-05-24 19:48:02+00:00 - - - Gloria Zhao 2022-05-24 01:13:43+00:00 - - - Anthony Towns 2022-05-23 21:34:16+00:00 - - - Gloria Zhao 2022-05-18 18:40:58+00:00 - - - Anthony Towns 2022-05-18 00:35:31+00:00 - - - Gloria Zhao 2022-05-17 20:45:42+00:00 - - - Greg Sanders 2022-05-17 17:56:40+00:00 - - - Gloria Zhao 2022-05-17 16:01:04+00:00 - + 2025-09-26T14:38:45.952396+00:00 + python-feedgen + + + [bitcoin-dev] Package Relay Proposal Gloria Zhao + 2022-05-17T16:01:00.000Z + + + Greg Sanders + 2022-05-17T17:56:00.000Z + + + Gloria Zhao + 2022-05-17T20:45:00.000Z + + + Anthony Towns + 2022-05-18T00:35:00.000Z + + + Gloria Zhao + 2022-05-18T18:40:00.000Z + + + Anthony Towns + 2022-05-23T21:34:00.000Z + + + Gloria Zhao + 2022-05-24T01:13:00.000Z + + + Anthony Towns + 2022-05-24T19:48:00.000Z + + + Gloria Zhao + 2022-05-24T21:05:00.000Z + + + Eric Voskuil + 2022-05-24T23:43:00.000Z + + + Anthony Towns + 2022-05-25T18:55:00.000Z + + + eric + 2022-05-25T20:52:00.000Z + + + eric + 2022-05-26T02:59:00.000Z + + + Gloria Zhao + 2022-05-28T01:54:00.000Z + + + Gloria Zhao + 2022-06-07T17:44:00.000Z + + + Suhas Daftuar + 2022-06-08T15:59:00.000Z + + + Gloria Zhao + 2022-06-14T09:59:00.000Z + + + Antoine Riard + 2022-06-17T20:08:00.000Z + + + Gloria Zhao + 2022-11-01T18:03:00.000Z + + + [bitcoin-dev] Package Relay Proposal Tom Trevethan + 2023-05-10T15:12:00.000Z + + + Greg Sanders + 2023-05-10T15:42:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Package Relay Proposal - 2023-08-02T06:32:07.153762+00:00 + 2025-09-26T14:38:45.954752+00:00 - The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids. Different perspectives are presented, highlighting the tradeoffs and considerations involved in implementing package relay in the Bitcoin protocol.A proposal has been made by Bitcoin Core developer Gloria Zhao to implement a 2023-05-10T15:42:34+00:00 + The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids. Different perspectives are presented, highlighting the tradeoffs and considerations involved in implementing package relay in the Bitcoin protocol.A proposal has been made by Bitcoin Core developer Gloria Zhao to implement a - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Password-protected-wallet-on-Taproot.xml b/static/bitcoin-dev/May_2022/combined_Password-protected-wallet-on-Taproot.xml index e753c49db4..253a9c529a 100644 --- a/static/bitcoin-dev/May_2022/combined_Password-protected-wallet-on-Taproot.xml +++ b/static/bitcoin-dev/May_2022/combined_Password-protected-wallet-on-Taproot.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Password-protected wallet on Taproot - 2023-08-02T06:22:11.547041+00:00 - - Lloyd Fournier 2022-05-04 00:26:46+00:00 - - - vjudeu at gazeta.pl 2022-05-01 16:18:40+00:00 - + 2025-09-26T14:38:37.321354+00:00 + python-feedgen + + + [bitcoin-dev] Password-protected wallet on Taproot vjudeu + 2022-05-01T16:18:00.000Z + + + Lloyd Fournier + 2022-05-04T00:26:00.000Z + + - python-feedgen + 2 Combined summary - Password-protected wallet on Taproot - 2023-08-02T06:22:11.547041+00:00 + 2025-09-26T14:38:37.321868+00:00 - In an email exchange between LL and vjudeu, the possibility of using Taproot to protect individual public keys with passwords is discussed. The proposed method involves creating a normal, Taproot-based public key in a secure and random manner. Another public key is then created by taking a user's password and executing a proper password hash on it to use as a private key. These two keys are combined in a Schnorr signature to form a 2-of-2 multisig. The first key is completely random, while the second key is a brainwallet derived from the user's chosen password. By default, all keys within a wallet can be protected with the same password, but it is also possible to choose different passwords for different addresses if needed.LL suggests that instead of using a hardware device with a pin to protect a secret key, a pinless device could be used in conjunction with a strong password and proper password hash. It is emphasized that sha256 should not be used to hash the password, as there are better options available for password hashing. While bip39 passwords offer similar functionality, they require entering the passwords into potentially malicious hardware devices. Descriptors can handle the protection of public keys with passwords in the same way as any other 2-of-2 multisig.Taproot, an upcoming upgrade for Bitcoin, will enable users to protect their public keys with passwords. This is achieved by combining a randomly generated normal Taproot-based public key with a second public key derived from a user-chosen password. The resulting 2-of-2 multisig incorporates both the randomly generated key and the password-derived key, providing an additional layer of security for Bitcoin users. 2022-05-04T00:26:46+00:00 + In an email exchange between LL and vjudeu, the possibility of using Taproot to protect individual public keys with passwords is discussed. The proposed method involves creating a normal, Taproot-based public key in a secure and random manner. Another public key is then created by taking a user's password and executing a proper password hash on it to use as a private key. These two keys are combined in a Schnorr signature to form a 2-of-2 multisig. The first key is completely random, while the second key is a brainwallet derived from the user's chosen password. By default, all keys within a wallet can be protected with the same password, but it is also possible to choose different passwords for different addresses if needed.LL suggests that instead of using a hardware device with a pin to protect a secret key, a pinless device could be used in conjunction with a strong password and proper password hash. It is emphasized that sha256 should not be used to hash the password, as there are better options available for password hashing. While bip39 passwords offer similar functionality, they require entering the passwords into potentially malicious hardware devices. Descriptors can handle the protection of public keys with passwords in the same way as any other 2-of-2 multisig.Taproot, an upcoming upgrade for Bitcoin, will enable users to protect their public keys with passwords. This is achieved by combining a randomly generated normal Taproot-based public key with a second public key derived from a user-chosen password. The resulting 2-of-2 multisig incorporates both the randomly generated key and the password-derived key, providing an additional layer of security for Bitcoin users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Pay-to-signature-hash-as-a-covenant.xml b/static/bitcoin-dev/May_2022/combined_Pay-to-signature-hash-as-a-covenant.xml index eeb8051ed6..94994002a9 100644 --- a/static/bitcoin-dev/May_2022/combined_Pay-to-signature-hash-as-a-covenant.xml +++ b/static/bitcoin-dev/May_2022/combined_Pay-to-signature-hash-as-a-covenant.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Pay to signature hash as a covenant - 2023-08-02T06:22:39.721436+00:00 - - AdamISZ 2022-05-21 21:24:39+00:00 - - - ZmnSCPxj 2022-05-03 09:35:31+00:00 - - - vjudeu at gazeta.pl 2022-05-03 07:37:20+00:00 - + 2025-09-26T14:38:22.397717+00:00 + python-feedgen + + + [bitcoin-dev] Pay to signature hash as a covenant vjudeu + 2022-05-03T07:37:00.000Z + + + ZmnSCPxj + 2022-05-03T09:35:00.000Z + + + AdamISZ + 2022-05-21T21:24:00.000Z + + - python-feedgen + 2 Combined summary - Pay to signature hash as a covenant - 2023-08-02T06:22:39.721436+00:00 + 2025-09-26T14:38:22.398296+00:00 - The sender of the email is discussing the use of covenants in P2PK scripts and whether it is possible to implement them without making any consensus changes. They suggest experimenting with P2PK and legacy signatures, but highlight that Schnorr signatures may offer more flexibility and enable a wider range of use cases. In terms of implementation, the writer proposes using P2WSH (Pay-to-Witness-Script-Hash) with a redeemScript that includes OP_CHECKSIG. This would allow for pre-commitment to a specific transaction based on the SIGHASH flags of the fixedSignature. They also mention the potential application of post-COVID congestion control using OP_CTV (CheckTemplateVerify), even in its absence.To improve efficiency, the author suggests the introduction of an OP_CHECKSIGHASHVERIFY operation that accepts a SIGHASH flag and a hash, checking if the sighash of the transaction matches the provided hash. They argue that this technique would be similar to OP_CTV but more efficient. The proposed approach is expected to work with Tapscripts within Taproot, although it should be noted that the fixedPubKey cannot be the same as the internal Taproot key.In conclusion, the author is exploring the possibility of utilizing covenants in a P2PK scenario without requiring consensus changes. They propose various techniques involving signature hashes and discuss the potential enhancements offered by Schnorr signatures. They are open to suggestions on how to effectively implement these ideas, including the incorporation of OP_CHECKSIGADD or multisig. 2022-05-21T21:24:39+00:00 + The sender of the email is discussing the use of covenants in P2PK scripts and whether it is possible to implement them without making any consensus changes. They suggest experimenting with P2PK and legacy signatures, but highlight that Schnorr signatures may offer more flexibility and enable a wider range of use cases. In terms of implementation, the writer proposes using P2WSH (Pay-to-Witness-Script-Hash) with a redeemScript that includes OP_CHECKSIG. This would allow for pre-commitment to a specific transaction based on the SIGHASH flags of the fixedSignature. They also mention the potential application of post-COVID congestion control using OP_CTV (CheckTemplateVerify), even in its absence.To improve efficiency, the author suggests the introduction of an OP_CHECKSIGHASHVERIFY operation that accepts a SIGHASH flag and a hash, checking if the sighash of the transaction matches the provided hash. They argue that this technique would be similar to OP_CTV but more efficient. The proposed approach is expected to work with Tapscripts within Taproot, although it should be noted that the fixedPubKey cannot be the same as the internal Taproot key.In conclusion, the author is exploring the possibility of utilizing covenants in a P2PK scenario without requiring consensus changes. They propose various techniques involving signature hashes and discuss the potential enhancements offered by Schnorr signatures. They are open to suggestions on how to effectively implement these ideas, including the incorporation of OP_CHECKSIGADD or multisig. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Silent-Payments-Non-interactive-private-payments-with-no-on-chain-overhead.xml b/static/bitcoin-dev/May_2022/combined_Silent-Payments-Non-interactive-private-payments-with-no-on-chain-overhead.xml index 7ab9434a57..762866851a 100644 --- a/static/bitcoin-dev/May_2022/combined_Silent-Payments-Non-interactive-private-payments-with-no-on-chain-overhead.xml +++ b/static/bitcoin-dev/May_2022/combined_Silent-Payments-Non-interactive-private-payments-with-no-on-chain-overhead.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Silent Payments – Non-interactive private payments with no on-chain overhead - 2023-08-02T05:56:55.480642+00:00 - - Erik Aronesty 2022-05-25 13:13:05+00:00 - - - alicexbt 2022-05-24 13:49:34+00:00 - - - woltx 2022-05-24 01:31:23+00:00 - - - Ruben Somsen 2022-03-31 10:48:41+00:00 - - - Billy 2022-03-30 16:09:22+00:00 - - - Billy 2022-03-30 05:58:18+00:00 - - - Ruben Somsen 2022-03-29 15:36:13+00:00 - - - Billy 2022-03-29 14:57:33+00:00 - - - Ruben Somsen 2022-03-28 15:27:56+00:00 - + 2025-09-26T14:38:09.679805+00:00 + python-feedgen + + + [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead Ruben Somsen + 2022-03-28T15:27:00.000Z + + + Billy + 2022-03-29T14:57:00.000Z + + + Ruben Somsen + 2022-03-29T15:36:00.000Z + + + Billy + 2022-03-30T05:58:00.000Z + + + Billy + 2022-03-30T16:09:00.000Z + + + Ruben Somsen + 2022-03-31T10:48:00.000Z + + + woltx + 2022-05-24T01:31:00.000Z + + + alicexbt + 2022-05-24T13:49:00.000Z + + + Erik Aronesty + 2022-05-25T13:13:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Silent Payments – Non-interactive private payments with no on-chain overhead - 2023-08-02T05:56:55.480642+00:00 + 2025-09-26T14:38:09.681021+00:00 - Ruben Somsen has proposed a new scheme called Silent Payments for private non-interactive address generation without on-chain overhead. In this scheme, the recipient generates a silent payment address and makes it publicly known, while the sender uses a public key from one of their chosen inputs to derive a shared secret that is used to tweak the silent payment address. This approach avoids using the Bitcoin blockchain as a messaging layer and requires no interaction between the sender and recipient, other than knowing the silent payment address.However, there are some downsides to this scheme. One limitation is the scanning requirement, which may not be suitable for light clients. Additionally, the scheme requires the sender to have control over their own input(s). Silent payments aim to prevent input linkage in Bitcoin transactions, which is important for privacy preservation, but it can introduce weaknesses such as revealing the intended recipient to other coinjoin users. To address this weakness, the proposal includes a blinding scheme to hide the silent payment address from other participants.The article compares Silent Payments with other protocols that offer similar functionality. Payment Code Sharing involves sending an OP_RETURN message on-chain to establish a shared secret prior to making payments. Xpub Sharing involves handing out an xpub instead of an address upon first payment to enable repeat payments. Regular Address Sharing requires interaction for every single payment, whereas Silent Payments do not.The proposed scheme of Silent Payments aims to provide a solution for private transactions by allowing fresh address generation, compatibility with one-time seed backups, and improved privacy. However, it still faces challenges such as the scanning requirement and lack of light client support. There are open questions regarding the implementation of Silent Payments, including the speed of required database lookups, support for light clients, preferred input tweaking, potential security issues in the proposed cryptography, and whether the added complexity of the scheme is worth it.One side-benefit of Silent Payments is that BIP32 HD keys won't be needed for address generation since every address will automatically be unique. Overall, Silent Payments have not been seriously considered before and may be reasonably viable, especially if the focus is on detecting only unspent payments by scanning the UTXO set. The article recommends reading the gist for improved formatting and potential future edits.In a separate discussion on the Bitcoin-dev mailing list, David Wagner's Blind Diffie-Hellman Key Exchange is mentioned in relation to the review of the Taproot BIP. The discussion provides a link to Wagner's explanation of the key exchange through a Gist on GitHub.The bitcoin-dev mailing list serves as a platform for further discussion and collaboration on Bitcoin development. The article acknowledges the help of others in the development of these protocols and provides references to related articles and schemes for further reading. 2022-05-25T13:13:05+00:00 + Ruben Somsen has proposed a new scheme called Silent Payments for private non-interactive address generation without on-chain overhead. In this scheme, the recipient generates a silent payment address and makes it publicly known, while the sender uses a public key from one of their chosen inputs to derive a shared secret that is used to tweak the silent payment address. This approach avoids using the Bitcoin blockchain as a messaging layer and requires no interaction between the sender and recipient, other than knowing the silent payment address.However, there are some downsides to this scheme. One limitation is the scanning requirement, which may not be suitable for light clients. Additionally, the scheme requires the sender to have control over their own input(s). Silent payments aim to prevent input linkage in Bitcoin transactions, which is important for privacy preservation, but it can introduce weaknesses such as revealing the intended recipient to other coinjoin users. To address this weakness, the proposal includes a blinding scheme to hide the silent payment address from other participants.The article compares Silent Payments with other protocols that offer similar functionality. Payment Code Sharing involves sending an OP_RETURN message on-chain to establish a shared secret prior to making payments. Xpub Sharing involves handing out an xpub instead of an address upon first payment to enable repeat payments. Regular Address Sharing requires interaction for every single payment, whereas Silent Payments do not.The proposed scheme of Silent Payments aims to provide a solution for private transactions by allowing fresh address generation, compatibility with one-time seed backups, and improved privacy. However, it still faces challenges such as the scanning requirement and lack of light client support. There are open questions regarding the implementation of Silent Payments, including the speed of required database lookups, support for light clients, preferred input tweaking, potential security issues in the proposed cryptography, and whether the added complexity of the scheme is worth it.One side-benefit of Silent Payments is that BIP32 HD keys won't be needed for address generation since every address will automatically be unique. Overall, Silent Payments have not been seriously considered before and may be reasonably viable, especially if the focus is on detecting only unspent payments by scanning the UTXO set. The article recommends reading the gist for improved formatting and potential future edits.In a separate discussion on the Bitcoin-dev mailing list, David Wagner's Blind Diffie-Hellman Key Exchange is mentioned in relation to the review of the Taproot BIP. The discussion provides a link to Wagner's explanation of the key exchange through a Gist on GitHub.The bitcoin-dev mailing list serves as a platform for further discussion and collaboration on Bitcoin development. The article acknowledges the help of others in the development of these protocols and provides references to related articles and schemes for further reading. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Speedy-covenants-OP-CAT2-.xml b/static/bitcoin-dev/May_2022/combined_Speedy-covenants-OP-CAT2-.xml index eca6ffbd67..70e4444614 100644 --- a/static/bitcoin-dev/May_2022/combined_Speedy-covenants-OP-CAT2-.xml +++ b/static/bitcoin-dev/May_2022/combined_Speedy-covenants-OP-CAT2-.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - Speedy covenants (OP_CAT2) - 2023-08-02T06:27:28.079397+00:00 - - Erik Aronesty 2022-05-14 13:32:18+00:00 - - - Russell O'Connor 2022-05-13 23:33:36+00:00 - - - Anthony Towns 2022-05-13 21:43:47+00:00 - - - Russell O'Connor 2022-05-12 10:48:44+00:00 - - - ZmnSCPxj 2022-05-12 03:07:45+00:00 - - - Russell O'Connor 2022-05-11 19:41:16+00:00 - - - vjudeu at gazeta.pl 2022-05-11 16:03:25+00:00 - - - alicexbt 2022-05-11 15:25:31+00:00 - - - ZmnSCPxj 2022-05-11 11:42:10+00:00 - - - vjudeu at gazeta.pl 2022-05-11 10:57:01+00:00 - - - ZmnSCPxj 2022-05-08 02:19:57+00:00 - - - Nadav Ivgi 2022-05-08 02:03:25+00:00 - - - ZmnSCPxj 2022-05-07 22:28:58+00:00 - - - ZmnSCPxj 2022-05-07 14:08:27+00:00 - - - Jorge Timón 2022-05-07 13:31:27+00:00 - - - Jorge Timón 2022-05-07 13:27:16+00:00 - - - vjudeu at gazeta.pl 2022-05-07 03:52:48+00:00 - - - ZmnSCPxj 2022-05-07 03:06:23+00:00 - - - Jorge Timón 2022-05-06 22:30:01+00:00 - + 2025-09-26T14:38:26.689357+00:00 + python-feedgen + + + [bitcoin-dev] Speedy covenants (OP_CAT2) Jorge Timón + 2022-05-06T22:30:00.000Z + + + ZmnSCPxj + 2022-05-07T03:06:00.000Z + + + vjudeu + 2022-05-07T03:52:00.000Z + + + Jorge Timón + 2022-05-07T13:27:00.000Z + + + Jorge Timón + 2022-05-07T13:31:00.000Z + + + ZmnSCPxj + 2022-05-07T14:08:00.000Z + + + ZmnSCPxj + 2022-05-07T22:28:00.000Z + + + Nadav Ivgi + 2022-05-08T02:03:00.000Z + + + ZmnSCPxj + 2022-05-08T02:19:00.000Z + + + vjudeu + 2022-05-11T10:57:00.000Z + + + ZmnSCPxj + 2022-05-11T11:42:00.000Z + + + alicexbt + 2022-05-11T15:25:00.000Z + + + vjudeu + 2022-05-11T16:03:00.000Z + + + Russell O'Connor + 2022-05-11T19:41:00.000Z + + + ZmnSCPxj + 2022-05-12T03:07:00.000Z + + + Russell O'Connor + 2022-05-12T10:48:00.000Z + + + Anthony Towns + 2022-05-13T21:43:00.000Z + + + Russell O'Connor + 2022-05-13T23:33:00.000Z + + + Erik Aronesty + 2022-05-14T13:32:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - Speedy covenants (OP_CAT2) - 2023-08-02T06:27:28.079397+00:00 + 2025-09-26T14:38:26.691175+00:00 - In a recent discussion on the bitcoin-dev mailing list, the implementation of CAT+CSFS for validating oracle messages and pubkey delegation was discussed. The primary purpose of this proposal would be to validate these messages, with covenants serving as a secondary function to gather user data. It was emphasized that the development of new opcodes should not happen without validating the current ones.Various opinions were shared regarding different opcode proposals. Anthony Towns stated that CTV and APO are weaker in terms of what can be done with them, while CAT/CSFS lacks ease of use and bug prevention. OP_TX was also considered to have less clean and maintainable validation code. Russell O'Connor expressed his belief that recursive covenants are necessary for programmable money, but they should be used properly and understood by users to avoid misuse.The use of OP_CAT in tapscript was also discussed. While OP_CAT alone does not enable covenants, non-recursive covenants can be enabled with it. However, it is still uncertain whether recursive covenants can be achieved. ZmnSCPxj suggested that hijacking the ECDSA checksig operation from a parallel, legacy input could potentially enable the calculations needed for recursive covenants, but this has not been accomplished yet.The email thread also touched upon the removal of OP_CAT from Bitcoin and its potential re-enabling in a soft fork. Concerns were raised about excessive memory usage and security risks associated with recursive scripts. The concept of negative fee transactions, where the receiver pays all transaction costs, was also mentioned.There were discussions about using OP_SUBSTR or OP_SPLIT instead of OP_CAT for script covenant operations. These alternatives were considered better as they ensure smaller script sizes and only one byte as the smallest unit in the script. It was clarified that OP_CAT does not by itself make all covenant opcodes recursive, but it enables any opcode to be recursive.Overall, the discussions highlighted the importance of carefully considering factors such as functionality, efficiency, bug prevention, and clean validation code when proposing and implementing opcodes. The potential risks and benefits of recursive covenants were also explored, with the need for thorough review and testing before their implementation.In a conversation between Jorge and ZmnSCPxj, the possibility of enabling covenants using OP_CAT in Bitcoin was discussed. Recursive covenants were highlighted as being close to true Turing-completeness, which poses a risk of denial-of-service attacks on the network. Non-recursive covenants can be enabled with OP_CTV and SIGHASH_ANYPREVOUT. However, limiting opcode processing would reduce the system from Turing-complete to total programming without codata. The safety of total-with-codata needs to be proven before enabling such opcodes.The removal of OP_CAT was due to its potential to cause an O(2^N) memory usage problem. It was suggested that re-enabling it could be achieved through TapScript by adding restrictions. Creating a new opcode, OP_CAT2, is unnecessary unless it is significantly different. Alternatively, other string-based functions like OP_SUBSTR or OP_SPLIT can be utilized. Modifying sighashes can also address the issue of transaction costs being paid by the sender instead of the receiver. For example, a "negative fee transaction" can be created using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY.The discussion originated from the context of P2SH, where the sender was paying for the receiver's security with k-of-n multisignature. This led to the creation of OP_EVAL and the P2SH concept. However, concerns about recursive covenants prompted changes to modern P2SH, making it "just a template" without any actual OP_EVAL. Re-enabling OP_CAT would require a hardfork, but a soft-fork approach using TapScript could enable the same opcode. Quantum-computing-break concerns can be addressed by utilizing a new SegWit version.It was noted that OP_CAT does not implement covenants itself but creates recursive covenants when combined with other covenant opcodes. The simplicity proposal was considered the best among all covenant proposals but requires a new scripting language that is more challenging to review and test. Speedy covenants, on the other hand, have been implemented for a longer time and should be easier to deploy. Deploying other covenant proposals later is not incompatible with this proposal.While the removal of OP_CAT was not directly related to enabling covenants, discussions around P2SH highlighted the need for improved security for receivers without burdening the sender. The solution became OP_EVAL and P2SH, but concerns about recursive covenants arose. Re-enabling OP_CAT would require a hardfork, but a new OP_CAT2 could be introduced as a soft fork. Taproot could also enable the same opcode in a soft-fork manner. However, the use of OP_EVAL for creating recursive scripts is problematic due to concerns about unbounded SCRIPT 2022-05-14T13:32:18+00:00 + In a recent discussion on the bitcoin-dev mailing list, the implementation of CAT+CSFS for validating oracle messages and pubkey delegation was discussed. The primary purpose of this proposal would be to validate these messages, with covenants serving as a secondary function to gather user data. It was emphasized that the development of new opcodes should not happen without validating the current ones.Various opinions were shared regarding different opcode proposals. Anthony Towns stated that CTV and APO are weaker in terms of what can be done with them, while CAT/CSFS lacks ease of use and bug prevention. OP_TX was also considered to have less clean and maintainable validation code. Russell O'Connor expressed his belief that recursive covenants are necessary for programmable money, but they should be used properly and understood by users to avoid misuse.The use of OP_CAT in tapscript was also discussed. While OP_CAT alone does not enable covenants, non-recursive covenants can be enabled with it. However, it is still uncertain whether recursive covenants can be achieved. ZmnSCPxj suggested that hijacking the ECDSA checksig operation from a parallel, legacy input could potentially enable the calculations needed for recursive covenants, but this has not been accomplished yet.The email thread also touched upon the removal of OP_CAT from Bitcoin and its potential re-enabling in a soft fork. Concerns were raised about excessive memory usage and security risks associated with recursive scripts. The concept of negative fee transactions, where the receiver pays all transaction costs, was also mentioned.There were discussions about using OP_SUBSTR or OP_SPLIT instead of OP_CAT for script covenant operations. These alternatives were considered better as they ensure smaller script sizes and only one byte as the smallest unit in the script. It was clarified that OP_CAT does not by itself make all covenant opcodes recursive, but it enables any opcode to be recursive.Overall, the discussions highlighted the importance of carefully considering factors such as functionality, efficiency, bug prevention, and clean validation code when proposing and implementing opcodes. The potential risks and benefits of recursive covenants were also explored, with the need for thorough review and testing before their implementation.In a conversation between Jorge and ZmnSCPxj, the possibility of enabling covenants using OP_CAT in Bitcoin was discussed. Recursive covenants were highlighted as being close to true Turing-completeness, which poses a risk of denial-of-service attacks on the network. Non-recursive covenants can be enabled with OP_CTV and SIGHASH_ANYPREVOUT. However, limiting opcode processing would reduce the system from Turing-complete to total programming without codata. The safety of total-with-codata needs to be proven before enabling such opcodes.The removal of OP_CAT was due to its potential to cause an O(2^N) memory usage problem. It was suggested that re-enabling it could be achieved through TapScript by adding restrictions. Creating a new opcode, OP_CAT2, is unnecessary unless it is significantly different. Alternatively, other string-based functions like OP_SUBSTR or OP_SPLIT can be utilized. Modifying sighashes can also address the issue of transaction costs being paid by the sender instead of the receiver. For example, a "negative fee transaction" can be created using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY.The discussion originated from the context of P2SH, where the sender was paying for the receiver's security with k-of-n multisignature. This led to the creation of OP_EVAL and the P2SH concept. However, concerns about recursive covenants prompted changes to modern P2SH, making it "just a template" without any actual OP_EVAL. Re-enabling OP_CAT would require a hardfork, but a soft-fork approach using TapScript could enable the same opcode. Quantum-computing-break concerns can be addressed by utilizing a new SegWit version.It was noted that OP_CAT does not implement covenants itself but creates recursive covenants when combined with other covenant opcodes. The simplicity proposal was considered the best among all covenant proposals but requires a new scripting language that is more challenging to review and test. Speedy covenants, on the other hand, have been implemented for a longer time and should be easier to deploy. Deploying other covenant proposals later is not incompatible with this proposal.While the removal of OP_CAT was not directly related to enabling covenants, discussions around P2SH highlighted the need for improved security for receivers without burdening the sender. The solution became OP_EVAL and P2SH, but concerns about recursive covenants arose. Re-enabling OP_CAT would require a hardfork, but a new OP_CAT2 could be introduced as a soft fork. Taproot could also enable the same opcode in a soft-fork manner. However, the use of OP_EVAL for creating recursive scripts is problematic due to concerns about unbounded SCRIPT - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Towards-a-means-of-measuring-user-support-for-Soft-Forks.xml b/static/bitcoin-dev/May_2022/combined_Towards-a-means-of-measuring-user-support-for-Soft-Forks.xml index e48033cc29..22e3840048 100644 --- a/static/bitcoin-dev/May_2022/combined_Towards-a-means-of-measuring-user-support-for-Soft-Forks.xml +++ b/static/bitcoin-dev/May_2022/combined_Towards-a-means-of-measuring-user-support-for-Soft-Forks.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - Towards a means of measuring user support for Soft Forks - 2023-08-02T06:16:29.811662+00:00 - - Billy Tetrud 2022-05-01 22:41:44+00:00 - - - ZmnSCPxj 2022-04-30 06:14:45+00:00 - - - Billy Tetrud 2022-04-28 16:35:32+00:00 - - - Billy Tetrud 2022-04-28 16:09:36+00:00 - - - micaroni at gmail.com 2022-04-28 08:03:53+00:00 - - - ZmnSCPxj 2022-04-28 05:26:48+00:00 - - - Billy Tetrud 2022-04-28 05:18:06+00:00 - - - Nadav Ivgi 2022-04-28 00:16:57+00:00 - - - Erik Aronesty 2022-04-27 20:13:35+00:00 - - - Keagan McClelland 2022-04-27 18:32:33+00:00 - - - Jeremy Rubin 2022-04-27 17:54:16+00:00 - - - micaroni at gmail.com 2022-04-27 17:22:07+00:00 - - - Billy Tetrud 2022-04-27 16:17:51+00:00 - - - Ryan Grant 2022-04-27 15:27:23+00:00 - - - Erik Aronesty 2022-04-27 14:28:31+00:00 - - - Chris Riley 2022-04-27 14:01:57+00:00 - - - Billy Tetrud 2022-04-27 03:04:04+00:00 - - - Bryan Bishop 2022-04-26 20:39:44+00:00 - - - Keagan McClelland 2022-04-26 19:37:07+00:00 - + 2025-09-26T14:38:43.764480+00:00 + python-feedgen + + + [bitcoin-dev] Towards a means of measuring user support for Soft Forks Keagan McClelland + 2022-04-26T19:37:00.000Z + + + Bryan Bishop + 2022-04-26T20:39:00.000Z + + + Billy Tetrud + 2022-04-27T03:04:00.000Z + + + Chris Riley + 2022-04-27T14:01:00.000Z + + + Erik Aronesty + 2022-04-27T14:28:00.000Z + + + Ryan Grant + 2022-04-27T15:27:00.000Z + + + Billy Tetrud + 2022-04-27T16:17:00.000Z + + + micaroni + 2022-04-27T17:22:00.000Z + + + Jeremy Rubin + 2022-04-27T17:54:00.000Z + + + Keagan McClelland + 2022-04-27T18:32:00.000Z + + + Erik Aronesty + 2022-04-27T20:13:00.000Z + + + Nadav Ivgi + 2022-04-28T00:16:00.000Z + + + Billy Tetrud + 2022-04-28T05:18:00.000Z + + + ZmnSCPxj + 2022-04-28T05:26:00.000Z + + + micaroni + 2022-04-28T08:03:00.000Z + + + Billy Tetrud + 2022-04-28T16:09:00.000Z + + + Billy Tetrud + 2022-04-28T16:35:00.000Z + + + ZmnSCPxj + 2022-04-30T06:14:00.000Z + + + Billy Tetrud + 2022-05-01T22:41:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - Towards a means of measuring user support for Soft Forks - 2023-08-02T06:16:29.811662+00:00 + 2025-09-26T14:38:43.766551+00:00 - The discussion revolves around the concept of rationality and how it relates to different goals. The author argues that rationality is subjective and depends on individual goals. They suggest that consensus should be established around goals to streamline conversations and share ideas. A futures market for predictions is proposed as a means to better understand people's goals without revealing them directly. However, it is noted that persistent irrationalities embedded in the design of the human mind will still be difficult to break.In the context of Bitcoin governance, the conversation focuses on achieving consensus among stakeholders. There is a proposal to determine representation based on the economic influence of different constituencies, including holders, transactors, miners, and developers. Various mechanisms such as coin-weighted polling, transaction signaling, miner signaling, and developer consensus reviews are suggested to measure support. However, there are concerns about the limitations and potential gaming of these methods.The issue of soft fork activation in Bitcoin is discussed, including the threshold for activating consensus changes and the representation of different constituencies in this process. The mailing list members agree that technical consensus alone is not enough to assess user consensus, and more rigorous methods are needed. There is a proposal for transaction signaling to allow users to have sybil-resistant influence over miner decisions. Concerns are raised about potential manipulation and false consensus.The conversation also addresses the flaws of the Aumann Agreement Theorem in the context of democracy and consensus building. It is suggested that improving human thinking, gathering relevant information, and accurately laying out goals can address these flaws. The importance of understanding the preferences of non-experts and non-technical people is emphasized, and clear explanations of proposed changes are seen as crucial.Different proposals and ideas are presented throughout the discussion, including polling that is not programmatically connected to activation, time-locked weighted voting, and combining rejection of blocks and transaction fees for signaling upgrades. Anticipated objections and questions are raised regarding these proposals, highlighting the need for further discussion and analysis.Overall, the conversation revolves around finding a logical solution to achieve consensus in Bitcoin governance, considering individual goals, economic influence, and user preferences. The limitations of existing methods and the importance of clarity, inclusivity, and understanding are emphasized in the quest for effective decision-making processes.Keagan suggests using transactions themselves to signal for upgrades by utilizing the free bits in the version field of a transaction. This would provide users with sybil-resistant influence over miner decisions and allow them to pressure miners to act on their behalf. The proposal aims to address the breakdown in civility around the debate on soft-fork activation and create a mechanism for measuring social consensus. However, there are concerns raised about the potential manipulation and false consensus that could result from such a system. Some argue that this proposal could be seen as "pay to play," giving wealthier individuals more decision-making power. The author agrees that wealth should not be able to dominate consensus decisions and sees the proposed mechanism as an improvement over the current situation where influential people decide consensus.Implementing this proposal would require its own soft fork, but the author acknowledges that there are concerns about certain parties, such as CoinJoin pool operators and L2 protocol implementations, having power over deciding consensus. Despite these concerns, it is seen as an improvement over the current status quo.The forum discusses various questions related to the proposal, including whether it affords a better view into consensus than the current system of miner signaling, whether it can be gamed to give a worse view into consensus, and whether it measures the right thing. The author also queries whether a BIP specification should be written to detail out the proposal.In addition to this proposal, the Bitcoin community is also discussing other methods of measuring user support for soft-fork changes. One suggestion involves weighted polling of holders to gauge consensus. However, this would not be directly connected to the activation mechanism and would only provide a means of gauging some portion of consensus.Overall, the Bitcoin community is actively debating how to measure user support for proposed soft-fork changes, aiming to ensure that technical consensus aligns with user consensus. Various proposals and concerns have been raised, highlighting the challenges and considerations involved in accurately measuring consensus in the cryptocurrency space.McClelland has proposed a mechanism that allows users to pressure miners into taking action on their behalf by using transactions themselves as a signal for an upgrade. He suggests utilizing the "free" bits in the version field of a transaction, which are currently ignored, to create rules where a transaction signaling in favor of an upgrade must not be included in a block that does not signal in favor of it. This would give users sybil-resistant influence over miner decisions. The proposal aims to provide miners with a better understanding of what users want and could be incorporated as an auxiliary feature of the soft fork deployment scheme. However, there are anticipated objections to this idea, such as the argument that signaling is not equivalent to voting, the need for consensus before any deployment, and concerns that it would allow the wealthy to make consensus 2022-05-01T22:41:44+00:00 + The discussion revolves around the concept of rationality and how it relates to different goals. The author argues that rationality is subjective and depends on individual goals. They suggest that consensus should be established around goals to streamline conversations and share ideas. A futures market for predictions is proposed as a means to better understand people's goals without revealing them directly. However, it is noted that persistent irrationalities embedded in the design of the human mind will still be difficult to break.In the context of Bitcoin governance, the conversation focuses on achieving consensus among stakeholders. There is a proposal to determine representation based on the economic influence of different constituencies, including holders, transactors, miners, and developers. Various mechanisms such as coin-weighted polling, transaction signaling, miner signaling, and developer consensus reviews are suggested to measure support. However, there are concerns about the limitations and potential gaming of these methods.The issue of soft fork activation in Bitcoin is discussed, including the threshold for activating consensus changes and the representation of different constituencies in this process. The mailing list members agree that technical consensus alone is not enough to assess user consensus, and more rigorous methods are needed. There is a proposal for transaction signaling to allow users to have sybil-resistant influence over miner decisions. Concerns are raised about potential manipulation and false consensus.The conversation also addresses the flaws of the Aumann Agreement Theorem in the context of democracy and consensus building. It is suggested that improving human thinking, gathering relevant information, and accurately laying out goals can address these flaws. The importance of understanding the preferences of non-experts and non-technical people is emphasized, and clear explanations of proposed changes are seen as crucial.Different proposals and ideas are presented throughout the discussion, including polling that is not programmatically connected to activation, time-locked weighted voting, and combining rejection of blocks and transaction fees for signaling upgrades. Anticipated objections and questions are raised regarding these proposals, highlighting the need for further discussion and analysis.Overall, the conversation revolves around finding a logical solution to achieve consensus in Bitcoin governance, considering individual goals, economic influence, and user preferences. The limitations of existing methods and the importance of clarity, inclusivity, and understanding are emphasized in the quest for effective decision-making processes.Keagan suggests using transactions themselves to signal for upgrades by utilizing the free bits in the version field of a transaction. This would provide users with sybil-resistant influence over miner decisions and allow them to pressure miners to act on their behalf. The proposal aims to address the breakdown in civility around the debate on soft-fork activation and create a mechanism for measuring social consensus. However, there are concerns raised about the potential manipulation and false consensus that could result from such a system. Some argue that this proposal could be seen as "pay to play," giving wealthier individuals more decision-making power. The author agrees that wealth should not be able to dominate consensus decisions and sees the proposed mechanism as an improvement over the current situation where influential people decide consensus.Implementing this proposal would require its own soft fork, but the author acknowledges that there are concerns about certain parties, such as CoinJoin pool operators and L2 protocol implementations, having power over deciding consensus. Despite these concerns, it is seen as an improvement over the current status quo.The forum discusses various questions related to the proposal, including whether it affords a better view into consensus than the current system of miner signaling, whether it can be gamed to give a worse view into consensus, and whether it measures the right thing. The author also queries whether a BIP specification should be written to detail out the proposal.In addition to this proposal, the Bitcoin community is also discussing other methods of measuring user support for soft-fork changes. One suggestion involves weighted polling of holders to gauge consensus. However, this would not be directly connected to the activation mechanism and would only provide a means of gauging some portion of consensus.Overall, the Bitcoin community is actively debating how to measure user support for proposed soft-fork changes, aiming to ensure that technical consensus aligns with user consensus. Various proposals and concerns have been raised, highlighting the challenges and considerations involved in accurately measuring consensus in the cryptocurrency space.McClelland has proposed a mechanism that allows users to pressure miners into taking action on their behalf by using transactions themselves as a signal for an upgrade. He suggests utilizing the "free" bits in the version field of a transaction, which are currently ignored, to create rules where a transaction signaling in favor of an upgrade must not be included in a block that does not signal in favor of it. This would give users sybil-resistant influence over miner decisions. The proposal aims to provide miners with a better understanding of what users want and could be incorporated as an auxiliary feature of the soft fork deployment scheme. However, there are anticipated objections to this idea, such as the argument that signaling is not equivalent to voting, the need for consensus before any deployment, and concerns that it would allow the wealthy to make consensus - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Wallet-policies-for-descriptor-wallets.xml b/static/bitcoin-dev/May_2022/combined_Wallet-policies-for-descriptor-wallets.xml index 31ad2a1399..25726479b9 100644 --- a/static/bitcoin-dev/May_2022/combined_Wallet-policies-for-descriptor-wallets.xml +++ b/static/bitcoin-dev/May_2022/combined_Wallet-policies-for-descriptor-wallets.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Wallet policies for descriptor wallets - 2023-08-02T06:23:33.636002+00:00 - - Salvatore Ingala 2023-01-24 08:38:29+00:00 - - - darosior 2023-01-23 19:53:18+00:00 - - - Salvatore Ingala 2022-11-21 11:27:25+00:00 - - - Andrew Poelstra 2022-09-29 23:56:51+00:00 - - - Salvatore Ingala 2022-05-17 08:44:53+00:00 - - - Salvatore Ingala 2022-05-10 09:37:26+00:00 - - - darosior 2022-05-09 11:36:47+00:00 - - - Billy Tetrud 2022-05-08 17:41:07+00:00 - - - Salvatore Ingala 2022-05-05 14:32:34+00:00 - + 2025-09-26T14:38:05.382215+00:00 + python-feedgen + + + [bitcoin-dev] Wallet policies for descriptor wallets Salvatore Ingala + 2022-05-05T14:32:00.000Z + + + Billy Tetrud + 2022-05-08T17:41:00.000Z + + + darosior + 2022-05-09T11:36:00.000Z + + + Salvatore Ingala + 2022-05-10T09:37:00.000Z + + + Salvatore Ingala + 2022-05-17T08:44:00.000Z + + + Andrew Poelstra + 2022-09-29T23:56:00.000Z + + + Salvatore Ingala + 2022-11-21T11:27:00.000Z + + + darosior + 2023-01-23T19:53:00.000Z + + + Salvatore Ingala + 2023-01-24T08:38:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Wallet policies for descriptor wallets - 2023-08-02T06:23:33.637054+00:00 + 2025-09-26T14:38:05.383398+00:00 - Salvatore Ingala, a Bitcoin developer, has proposed a new language called "wallet policies" to address challenges in implementing descriptors and miniscript support in hardware wallets. These challenges arise due to limited RAM, computational power, and storage capacity of hardware wallets.The proposed language aims to provide a native, compact representation of the wallet receive/change and improve the user experience of software wallets. The registration flow for wallet policies involves the software wallet initiating a registration process on the hardware wallet. The information includes the wallet policy and a unique name that identifies the policy. The hardware wallet displays the policy on its secure screen, allowing the user to review and compare it with a trusted source before approving it. The goal is to ensure that the user knows the policy being used to spend their funds, preventing any malicious modifications.To simplify implementation and improve user experience, the document proposes minimizing the amount of information shown on-screen and reducing the number of times the user needs to validate such information. It also suggests reusing the same xpub in multiple places to avoid blowup in descriptor size. The proof of registration is executed securely using message authentication codes.The document provides examples of wallet descriptor templates for different use cases, such as native segwit accounts, taproot BIP86 accounts, native segwit 2-of-3, and templates with miniscript for "1 of 2 equally likely keys." It also includes additional rules, implementation guidelines, and references to relevant Bitcoin Improvement Proposals (BIPs) for further information.The email exchange discusses the challenges of implementing output descriptors on signing devices, proposing optimizations to overcome difficulties for implementers. It suggests optimizations for common use cases, such as using two descriptors at different derivation indices for receive and change addresses. The conversation also touches on the feasibility of incorporating Musig2 descriptors into hardware wallets and the potential for improving key aliasing using wallet policies.Overall, the proposed wallet policies language aims to provide a secure and user-friendly solution for integrating descriptors and miniscript support in hardware wallets, addressing the limitations of embedded devices and ensuring good user experience.Salvatore Ingala addresses the challenges of implementing descriptors and miniscript support in hardware wallets due to technical constraints such as limited RAM and computational power. To overcome these limitations, Ingala proposes a "wallet policies" language that can be used by all hardware wallets to securely support complex scripts.The proposed solution involves a registration flow for the wallet policy in the hardware wallet. This registration process includes generating all relevant addresses/scripts and identifying keys controlled by the hardware wallet. The user registers a wallet policy into the hardware wallet, and the software wallet initiates the registration on the hardware wallet. The registered policy is stored in the hardware wallet's permanent memory, and a master key encrypts all necessary information required to spend funds sent to those addresses.The policy language suggested targets a stricter subset of the output descriptors language, making it easier to implement and allowing for human inspection during the registration flow. Wallet descriptor templates consist of key placeholders and key origin information, including various types such as P2SH, P2WSH, P2PKH, P2WPKH, multisig, sorted multi, P2TR, and miniscript templates.The document outlines a standard for output script descriptors used to derive addresses and scripts from wallet descriptor templates. It specifies that wallet policies are considered invalid if any placeholder has derivation steps while the corresponding element of the keys vector is not an xpub. The document provides examples of wallet descriptor templates for native segwit accounts, taproot BIP86 accounts, and multisig setups.Overall, the proposed wallet policies language aims to address the security and user experience challenges faced by hardware wallets when supporting complex scripts. By registering wallet policies, hardware wallets can securely perform operations like generating addresses and signing transactions. 2023-01-24T08:38:29+00:00 + Salvatore Ingala, a Bitcoin developer, has proposed a new language called "wallet policies" to address challenges in implementing descriptors and miniscript support in hardware wallets. These challenges arise due to limited RAM, computational power, and storage capacity of hardware wallets.The proposed language aims to provide a native, compact representation of the wallet receive/change and improve the user experience of software wallets. The registration flow for wallet policies involves the software wallet initiating a registration process on the hardware wallet. The information includes the wallet policy and a unique name that identifies the policy. The hardware wallet displays the policy on its secure screen, allowing the user to review and compare it with a trusted source before approving it. The goal is to ensure that the user knows the policy being used to spend their funds, preventing any malicious modifications.To simplify implementation and improve user experience, the document proposes minimizing the amount of information shown on-screen and reducing the number of times the user needs to validate such information. It also suggests reusing the same xpub in multiple places to avoid blowup in descriptor size. The proof of registration is executed securely using message authentication codes.The document provides examples of wallet descriptor templates for different use cases, such as native segwit accounts, taproot BIP86 accounts, native segwit 2-of-3, and templates with miniscript for "1 of 2 equally likely keys." It also includes additional rules, implementation guidelines, and references to relevant Bitcoin Improvement Proposals (BIPs) for further information.The email exchange discusses the challenges of implementing output descriptors on signing devices, proposing optimizations to overcome difficulties for implementers. It suggests optimizations for common use cases, such as using two descriptors at different derivation indices for receive and change addresses. The conversation also touches on the feasibility of incorporating Musig2 descriptors into hardware wallets and the potential for improving key aliasing using wallet policies.Overall, the proposed wallet policies language aims to provide a secure and user-friendly solution for integrating descriptors and miniscript support in hardware wallets, addressing the limitations of embedded devices and ensuring good user experience.Salvatore Ingala addresses the challenges of implementing descriptors and miniscript support in hardware wallets due to technical constraints such as limited RAM and computational power. To overcome these limitations, Ingala proposes a "wallet policies" language that can be used by all hardware wallets to securely support complex scripts.The proposed solution involves a registration flow for the wallet policy in the hardware wallet. This registration process includes generating all relevant addresses/scripts and identifying keys controlled by the hardware wallet. The user registers a wallet policy into the hardware wallet, and the software wallet initiates the registration on the hardware wallet. The registered policy is stored in the hardware wallet's permanent memory, and a master key encrypts all necessary information required to spend funds sent to those addresses.The policy language suggested targets a stricter subset of the output descriptors language, making it easier to implement and allowing for human inspection during the registration flow. Wallet descriptor templates consist of key placeholders and key origin information, including various types such as P2SH, P2WSH, P2PKH, P2WPKH, multisig, sorted multi, P2TR, and miniscript templates.The document outlines a standard for output script descriptors used to derive addresses and scripts from wallet descriptor templates. It specifies that wallet policies are considered invalid if any placeholder has derivation steps while the corresponding element of the keys vector is not an xpub. The document provides examples of wallet descriptor templates for native segwit accounts, taproot BIP86 accounts, and multisig setups.Overall, the proposed wallet policies language aims to address the security and user experience challenges faced by hardware wallets when supporting complex scripts. By registering wallet policies, hardware wallets can securely perform operations like generating addresses and signing transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml b/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml index 16f6c56a5b..b8e52e4a47 100644 --- a/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml +++ b/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - What to do when contentious soft fork activations are attempted - 2023-08-02T06:20:11.973401+00:00 + 2025-09-26T14:38:24.542058+00:00 + python-feedgen Jorge Timón 2022-05-07 01:57:39+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - What to do when contentious soft fork activations are attempted - 2023-08-02T06:20:11.973401+00:00 + 2025-09-26T14:38:24.542201+00:00 - The email conversation between Jorge Timón and John Tromp on the Bitcoin-dev mailing list has sparked a discussion on irony. Timón accused Tromp of making personal attacks against Andreas Antonopoulos for his opinions on bip8. However, Tromp pointed out that Timón himself had made a personal attack by calling Jeremy ignorant about bip8. This led to a discussion on how ironic it is that people who base their arguments on personal attacks are also the ones who complain the most about personal attacks.In a separate discussion on the bitcoin-dev mailing list, Jorge Timón questioned a claim made by Russell O'Connor about the design of Speedy Trial (ST). Timón found the claim strange and stated that the grace period for slower activation after lock-in was added to address concerns raised by people who disliked the proposal. However, he still believed that speedy trial was a bad proposal due to incorrect analysis. O'Connor responded by quoting his own blog post where he clarified that the design of speedy trial was not based on any activation philosophy about failing fast.In another email exchange, Jorge Timón suggested that it is unnecessary to personally attack Andreas for his opinions. He argued that the only reason Jeremy Rubin does not like BIP8 is because he is ignorant about it and has not reviewed it enough. However, John Tromp pointed out the irony in equating 'clueless about BIP119' with a personal attack and then calling Jeremy ignorant about BIP8. The conversation seems to revolve around differences of opinion regarding different Bitcoin Improvement Proposals (BIPs).In a separate email thread, Ryan Grant defends the OP_CTV covenant proposal after Jorge Timón questioned Andreas' criticism. Ryan argues that OP_CTV covenants cannot restrict any address that the sender does not control and criticizes Andreas for not code-reviewing BIP119 or the pull request. Ryan believes that Andreas did not look into the reason why the proposed client was safe and would not cause a chain split. The conversation also references Russell O'Connor's explanation for how Speedy Trials arose in the consensus process and how it was designed.The email threads also touch upon the concept of covenants in Bitcoin and the contributions made by individuals towards it. There is a mention of Bip8 and the importance of being open-minded to understand its analysis. The discussions revolve around the need for education, avoiding personal attacks, addressing misinformation, and looking at technical details when discussing contentious soft forks and covenant proposals.Michael Folkson expresses his thoughts on the recent attempt to activate a contentious soft fork and questions what should be done differently if such attempts happen again. He believes that it is unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split and suggests there should be a personal cost to dissuade them from trying it again. Folkson acknowledges that Bitcoin is a permissionless network and no authority can stop such attempts, but hopes that people will actively resist and prevent the network from being fundamentally broken.Overall, the email exchanges and threads highlight discussions on irony, differences of opinion regarding Bitcoin Improvement Proposals, the design of Speedy Trial, criticism of covenant proposals, addressing misinformation, and the recent attempt to activate a contentious soft fork. The conversations emphasize the importance of education, avoiding personal attacks, and considering technical details when discussing contentious topics in the Bitcoin community. 2022-05-07T01:57:39+00:00 + The email conversation between Jorge Timón and John Tromp on the Bitcoin-dev mailing list has sparked a discussion on irony. Timón accused Tromp of making personal attacks against Andreas Antonopoulos for his opinions on bip8. However, Tromp pointed out that Timón himself had made a personal attack by calling Jeremy ignorant about bip8. This led to a discussion on how ironic it is that people who base their arguments on personal attacks are also the ones who complain the most about personal attacks.In a separate discussion on the bitcoin-dev mailing list, Jorge Timón questioned a claim made by Russell O'Connor about the design of Speedy Trial (ST). Timón found the claim strange and stated that the grace period for slower activation after lock-in was added to address concerns raised by people who disliked the proposal. However, he still believed that speedy trial was a bad proposal due to incorrect analysis. O'Connor responded by quoting his own blog post where he clarified that the design of speedy trial was not based on any activation philosophy about failing fast.In another email exchange, Jorge Timón suggested that it is unnecessary to personally attack Andreas for his opinions. He argued that the only reason Jeremy Rubin does not like BIP8 is because he is ignorant about it and has not reviewed it enough. However, John Tromp pointed out the irony in equating 'clueless about BIP119' with a personal attack and then calling Jeremy ignorant about BIP8. The conversation seems to revolve around differences of opinion regarding different Bitcoin Improvement Proposals (BIPs).In a separate email thread, Ryan Grant defends the OP_CTV covenant proposal after Jorge Timón questioned Andreas' criticism. Ryan argues that OP_CTV covenants cannot restrict any address that the sender does not control and criticizes Andreas for not code-reviewing BIP119 or the pull request. Ryan believes that Andreas did not look into the reason why the proposed client was safe and would not cause a chain split. The conversation also references Russell O'Connor's explanation for how Speedy Trials arose in the consensus process and how it was designed.The email threads also touch upon the concept of covenants in Bitcoin and the contributions made by individuals towards it. There is a mention of Bip8 and the importance of being open-minded to understand its analysis. The discussions revolve around the need for education, avoiding personal attacks, addressing misinformation, and looking at technical details when discussing contentious soft forks and covenant proposals.Michael Folkson expresses his thoughts on the recent attempt to activate a contentious soft fork and questions what should be done differently if such attempts happen again. He believes that it is unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split and suggests there should be a personal cost to dissuade them from trying it again. Folkson acknowledges that Bitcoin is a permissionless network and no authority can stop such attempts, but hopes that people will actively resist and prevent the network from being fundamentally broken.Overall, the email exchanges and threads highlight discussions on irony, differences of opinion regarding Bitcoin Improvement Proposals, the design of Speedy Trial, criticism of covenant proposals, addressing misinformation, and the recent attempt to activate a contentious soft fork. The conversations emphasize the importance of education, avoiding personal attacks, and considering technical details when discussing contentious topics in the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_Working-Towards-Consensus.xml b/static/bitcoin-dev/May_2022/combined_Working-Towards-Consensus.xml index 72fc67691f..15a5168625 100644 --- a/static/bitcoin-dev/May_2022/combined_Working-Towards-Consensus.xml +++ b/static/bitcoin-dev/May_2022/combined_Working-Towards-Consensus.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Working Towards Consensus - 2023-08-02T06:22:28.004149+00:00 - - Billy Tetrud 2022-05-08 17:36:01+00:00 - - - John Carvalho 2022-05-03 05:24:23+00:00 - - - Billy Tetrud 2022-05-03 00:04:45+00:00 - - - John Carvalho 2022-05-02 08:37:29+00:00 - - - Jeremy Rubin 2022-05-02 02:43:29+00:00 - + 2025-09-26T14:38:41.576145+00:00 + python-feedgen + + + [bitcoin-dev] Working Towards Consensus Jeremy Rubin + 2022-05-02T02:43:00.000Z + + + John Carvalho + 2022-05-02T08:37:00.000Z + + + Billy Tetrud + 2022-05-03T00:04:00.000Z + + + John Carvalho + 2022-05-03T05:24:00.000Z + + + Billy Tetrud + 2022-05-08T17:36:00.000Z + + - python-feedgen + 2 Combined summary - Working Towards Consensus - 2023-08-02T06:22:28.004149+00:00 + 2025-09-26T14:38:41.576851+00:00 - In recent discussions on the bitcoin-dev mailing list, members have engaged in a debate about the process of proposing new features for Bitcoin. The argument revolves around whether designers and developers should take the lead or if demand from the market should drive the development of new features. Concerns were raised about the potential centralization and harm to fungibility that could result from adding complex features to Bitcoin's base layer.One proposed feature called CTV (CheckTemplateVerify) was also discussed, with members examining its simplicity and effectiveness. The importance of defending consensus and focusing on features that everyone wants, rather than speculative additions, was emphasized during the conversation.However, personal attacks were made during the discussion, leading to criticism from others. This has caused confusion and fear within the Bitcoin community, particularly in light of a recent attempt to activate a contentious soft fork. To prevent such incidents in the future, it is suggested that personal attacks be avoided, technical details be carefully considered, and all posts read thoroughly to understand various opinions. Additionally, there is a need to better document Bitcoin's technical consensus process.The Bitcoin technical community needs to evaluate and propose upgrades to enhance Bitcoin's capabilities for self-sovereignty, privacy, scalability, and decentralization. Concerns regarding negative potential of covenants should be addressed, and the trade-offs between levels of functionality should be explained. Discussions on activation and release mechanisms also need to be renewed.John Carvalho argues that consensus can be reached by proposing features that everyone needs, but this statement is met with disagreement as not all features are necessary for all users. He emphasizes the importance of designers solving problems with designs rather than speculative additions. On the other hand, Billy Tetrud stresses the significance of consensus and education in decision-making, urging people to avoid personal attacks and focus on technical details when discussing proposals.Jeremy Rubin, in response to recent controversy surrounding his post on BIP-119, apologizes for any confusion caused and proposes efforts to better document Bitcoin's technical consensus process. He believes it is crucial to address concerns about covenants, renew conversations about activation and release mechanisms, and systematize knowledge around covenant technologies. Despite expecting messy discourse, Rubin invites feedback from the community.Overall, consensus and collaboration within the Bitcoin community are highlighted as vital for the network's success. 2022-05-08T17:36:01+00:00 + In recent discussions on the bitcoin-dev mailing list, members have engaged in a debate about the process of proposing new features for Bitcoin. The argument revolves around whether designers and developers should take the lead or if demand from the market should drive the development of new features. Concerns were raised about the potential centralization and harm to fungibility that could result from adding complex features to Bitcoin's base layer.One proposed feature called CTV (CheckTemplateVerify) was also discussed, with members examining its simplicity and effectiveness. The importance of defending consensus and focusing on features that everyone wants, rather than speculative additions, was emphasized during the conversation.However, personal attacks were made during the discussion, leading to criticism from others. This has caused confusion and fear within the Bitcoin community, particularly in light of a recent attempt to activate a contentious soft fork. To prevent such incidents in the future, it is suggested that personal attacks be avoided, technical details be carefully considered, and all posts read thoroughly to understand various opinions. Additionally, there is a need to better document Bitcoin's technical consensus process.The Bitcoin technical community needs to evaluate and propose upgrades to enhance Bitcoin's capabilities for self-sovereignty, privacy, scalability, and decentralization. Concerns regarding negative potential of covenants should be addressed, and the trade-offs between levels of functionality should be explained. Discussions on activation and release mechanisms also need to be renewed.John Carvalho argues that consensus can be reached by proposing features that everyone needs, but this statement is met with disagreement as not all features are necessary for all users. He emphasizes the importance of designers solving problems with designs rather than speculative additions. On the other hand, Billy Tetrud stresses the significance of consensus and education in decision-making, urging people to avoid personal attacks and focus on technical details when discussing proposals.Jeremy Rubin, in response to recent controversy surrounding his post on BIP-119, apologizes for any confusion caused and proposes efforts to better document Bitcoin's technical consensus process. He believes it is crucial to address concerns about covenants, renew conversations about activation and release mechanisms, and systematize knowledge around covenant technologies. Despite expecting messy discourse, Rubin invites feedback from the community.Overall, consensus and collaboration within the Bitcoin community are highlighted as vital for the network's success. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml b/static/bitcoin-dev/May_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml index 8483e94693..59d51a3551 100644 --- a/static/bitcoin-dev/May_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml +++ b/static/bitcoin-dev/May_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? - 2023-11-05T02:03:01.848102+00:00 + 2025-09-26T14:32:52.599750+00:00 + python-feedgen ArmchairCryptologist 2023-11-04 09:58:48+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? - 2023-11-05T02:03:01.848349+00:00 + 2025-09-26T14:32:52.599917+00:00 - Bitcoin developers are engaged in discussions to find solutions for the current high fee environment, prevent spam transactions, and ensure the long-term sustainability and decentralization of the network. Proposed solutions include fixing layered protocols, introducing new opcodes like OP_ZKP, reallocating block space, and penalizing non-economic transactions. The goal is to strike a balance between reducing fees, preventing spam, and maintaining the economic viability and security of the network. Ali Sherief expresses concern over congestion caused by side projects like BRC-20 and suggests implementing BIPs or commits in the Bitcoin Core codebase to address the issue. Michael Folkson argues that consensus-compatible transactions paying market-rate fees are functioning as intended. However, the debate continues on finding effective solutions while preserving maximum freedom and valid use cases. The email exchange also discusses the purpose of paying higher transaction fees than the received amount, the lack of Lightning wallets for desktop, and the need for GUI wallets to interact with the Lightning Network. Overall, the focus is on addressing congestion, preventing spam, and ensuring smooth operation of the Bitcoin network as a peer-to-peer digital currency. 2023-11-04T09:58:48+00:00 + Bitcoin developers are engaged in discussions to find solutions for the current high fee environment, prevent spam transactions, and ensure the long-term sustainability and decentralization of the network. Proposed solutions include fixing layered protocols, introducing new opcodes like OP_ZKP, reallocating block space, and penalizing non-economic transactions. The goal is to strike a balance between reducing fees, preventing spam, and maintaining the economic viability and security of the network. Ali Sherief expresses concern over congestion caused by side projects like BRC-20 and suggests implementing BIPs or commits in the Bitcoin Core codebase to address the issue. Michael Folkson argues that consensus-compatible transactions paying market-rate fees are functioning as intended. However, the debate continues on finding effective solutions while preserving maximum freedom and valid use cases. The email exchange also discusses the purpose of paying higher transaction fees than the received amount, the lack of Lightning wallets for desktop, and the need for GUI wallets to interact with the Lightning Network. Overall, the focus is on addressing congestion, preventing spam, and ensuring smooth operation of the Bitcoin network as a peer-to-peer digital currency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml b/static/bitcoin-dev/May_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml index ff89402056..9d8fc8002b 100644 --- a/static/bitcoin-dev/May_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml +++ b/static/bitcoin-dev/May_2023/combined_A-new-Bitcoin-implementation-integrated-with-Core-Lightning.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - A new Bitcoin implementation integrated with Core Lightning - 2023-08-02T08:48:39.136155+00:00 - - Matt Corallo 2023-05-06 05:58:55+00:00 - - - Vincenzo Palazzo 2023-04-30 15:22:01+00:00 - - - niftynei 2023-04-24 16:06:59+00:00 - - - Michael Folkson 2023-04-19 10:54:10+00:00 - - - Kostas Karasavvas 2023-04-19 09:05:10+00:00 - - - Michael Folkson 2023-04-18 17:06:14+00:00 - - - Michael Folkson 2023-01-16 15:45:36+00:00 - - - alicexbt 2023-01-15 13:04:05+00:00 - - - Michael Folkson 2023-01-14 20:45:38+00:00 - - - Fabian 2023-01-14 20:34:38+00:00 - - - Michael Folkson 2023-01-14 20:26:07+00:00 - + 2025-09-26T14:32:54.719184+00:00 + python-feedgen + + + [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning Michael Folkson + 2023-01-14T20:26:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Fabian + 2023-01-14T20:34:00.000Z + + + Michael Folkson + 2023-01-14T20:45:00.000Z + + + [bitcoin-dev] " alicexbt + 2023-01-15T13:04:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Michael Folkson + 2023-01-16T15:45:00.000Z + + + [bitcoin-dev] " Michael Folkson + 2023-04-18T17:06:00.000Z + + + Kostas Karasavvas + 2023-04-19T09:05:00.000Z + + + Michael Folkson + 2023-04-19T10:54:00.000Z + + + [bitcoin-dev] [Lightning-dev] " niftynei + 2023-04-24T16:06:00.000Z + + + Vincenzo Palazzo + 2023-04-30T15:22:00.000Z + + + Matt Corallo + 2023-05-06T05:58:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - A new Bitcoin implementation integrated with Core Lightning - 2023-08-02T08:48:39.136155+00:00 + 2025-09-26T14:32:54.720626+00:00 - Decisions within the Bitcoin community have been criticized for happening in a closed-off manner, with discussions taking place behind closed doors or in private IRC channels. Michael, however, believes that a more open and collaborative approach is needed. He suggests integrating a bare bones Knots style Bitcoin implementation with Core Lightning to create a simpler and more efficient solution. This would avoid the need to re-implement consensus code in a different language, which many developers see as a better option. However, there are concerns about the potential complexity and effort required for such integration.The email thread also addresses the decoupling of CLN from the block source, allowing for a separation of concerns and flexibility in choosing a block backend. The idea of "comingle"ing the peering of LN gossip and block data networks is raised, but it has not been seriously pursued in the LN side. Additionally, there is a discussion about fee calculation and the need for a unified approach to ensure proper functioning of Lightning nodes.Overall, the email thread sheds light on ongoing discussions and ideas for improving the scalability and functionality of the Bitcoin network. It highlights the challenges and opportunities in integrating full nodes and Lightning nodes, managing the Bitcoin Core project, and enhancing the overall ecosystem.The libbitcoinkernel project aimed to extract the consensus engine from Core, but it has proven difficult due to the elusive nature of consensus itself. As a result, the model of Knots style consensus compatible codebase forks of Bitcoin Core seems to be gaining traction. However, merging Bitcoin Core and Core Lightning into one codebase would be a monumental task, according to Michael. He is seeking input from individuals well-versed in both codebases to explore ambitious long-term projects that could potentially combine these two entities.Despite the perceived lull in the chaos surrounding soft fork activation, the Bitcoin community sees this as an opportune time to delve into ambitious endeavors, even if they are purely conceptual at this stage. By focusing on such projects, the community hopes to foster innovation and progress within the ecosystem. 2023-05-06T05:58:55+00:00 + Decisions within the Bitcoin community have been criticized for happening in a closed-off manner, with discussions taking place behind closed doors or in private IRC channels. Michael, however, believes that a more open and collaborative approach is needed. He suggests integrating a bare bones Knots style Bitcoin implementation with Core Lightning to create a simpler and more efficient solution. This would avoid the need to re-implement consensus code in a different language, which many developers see as a better option. However, there are concerns about the potential complexity and effort required for such integration.The email thread also addresses the decoupling of CLN from the block source, allowing for a separation of concerns and flexibility in choosing a block backend. The idea of "comingle"ing the peering of LN gossip and block data networks is raised, but it has not been seriously pursued in the LN side. Additionally, there is a discussion about fee calculation and the need for a unified approach to ensure proper functioning of Lightning nodes.Overall, the email thread sheds light on ongoing discussions and ideas for improving the scalability and functionality of the Bitcoin network. It highlights the challenges and opportunities in integrating full nodes and Lightning nodes, managing the Bitcoin Core project, and enhancing the overall ecosystem.The libbitcoinkernel project aimed to extract the consensus engine from Core, but it has proven difficult due to the elusive nature of consensus itself. As a result, the model of Knots style consensus compatible codebase forks of Bitcoin Core seems to be gaining traction. However, merging Bitcoin Core and Core Lightning into one codebase would be a monumental task, according to Michael. He is seeking input from individuals well-versed in both codebases to explore ambitious long-term projects that could potentially combine these two entities.Despite the perceived lull in the chaos surrounding soft fork activation, the Bitcoin community sees this as an opportune time to delve into ambitious endeavors, even if they are purely conceptual at this stage. By focusing on such projects, the community hopes to foster innovation and progress within the ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_A-payout-scheme-for-a-non-custodial-mining-pool.xml b/static/bitcoin-dev/May_2023/combined_A-payout-scheme-for-a-non-custodial-mining-pool.xml index daaced241b..6f21b2c849 100644 --- a/static/bitcoin-dev/May_2023/combined_A-payout-scheme-for-a-non-custodial-mining-pool.xml +++ b/static/bitcoin-dev/May_2023/combined_A-payout-scheme-for-a-non-custodial-mining-pool.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - A payout scheme for a non custodial mining pool - 2023-08-02T09:24:09.357949+00:00 - - Antoine Riard 2023-05-22 01:27:41+00:00 - - - F M 2023-05-03 15:48:46+00:00 - + 2025-09-26T14:33:03.307275+00:00 + python-feedgen + + + [bitcoin-dev] A payout scheme for a non custodial mining pool F M + 2023-05-03T15:48:00.000Z + + + Antoine Riard + 2023-05-22T01:27:00.000Z + + - python-feedgen + 2 Combined summary - A payout scheme for a non custodial mining pool - 2023-08-02T09:24:09.357949+00:00 + 2025-09-26T14:33:03.307714+00:00 - In recent discussions within the Bitcoin community, there has been a lack of consensus regarding the definitions of covenants and payment pools. To address this issue, a proposal has been made for a non-custodial payment pool scheme that would enable miners in a mining pool to share ownership of the coinbase reward. This scheme is based on payment trees, which are essentially trees of transactions redistributing funds to payment pool participants using their addresses as leaves. The root of the tree contains the payment pool's funds with an n-of-n multisig.The proposed payment tree allows for a compact withdrawal from the pool, with varying levels of pooling conservation after a withdrawal. In order to achieve off-chain novation of the pool tree, replay security is crucial to prevent participants from replaying their withdrawals, either partially or in full, after withdrawing all their balances. While many payment pool structures rely on precompiled transactions for safe withdrawal, this approach becomes impractical if every extranonce attempted by every miner requires a set of precompiled transactions.Instead, the proposed scheme utilizes ANYPREVOUT signatures, which enables miners to collectively construct a payment tree that "waits" for rewards when a block is found. The authors compare the average space occupied on the blockchain with that of P2Pool and find promising results. However, a significant challenge lies in the lack of cooperation among pool participants to facilitate cooperative withdrawal. This issue can be mitigated through the implementation of fees to enter the pool. Additionally, the balance can be timelocked in case of non-cooperative closure, serving as a deterrent.Furthermore, the authors suggest that past force-closures of pools can be seen as evidence of good conduct by future co-participants in a payment pool. Overall, the proposed scheme offers a potential solution for non-custodial payment pools and presents interesting avenues for further exploration. The authors have released their work as an RFC (Request for Comments) and encourage feedback and input from the Bitcoin community. 2023-05-22T01:27:41+00:00 + In recent discussions within the Bitcoin community, there has been a lack of consensus regarding the definitions of covenants and payment pools. To address this issue, a proposal has been made for a non-custodial payment pool scheme that would enable miners in a mining pool to share ownership of the coinbase reward. This scheme is based on payment trees, which are essentially trees of transactions redistributing funds to payment pool participants using their addresses as leaves. The root of the tree contains the payment pool's funds with an n-of-n multisig.The proposed payment tree allows for a compact withdrawal from the pool, with varying levels of pooling conservation after a withdrawal. In order to achieve off-chain novation of the pool tree, replay security is crucial to prevent participants from replaying their withdrawals, either partially or in full, after withdrawing all their balances. While many payment pool structures rely on precompiled transactions for safe withdrawal, this approach becomes impractical if every extranonce attempted by every miner requires a set of precompiled transactions.Instead, the proposed scheme utilizes ANYPREVOUT signatures, which enables miners to collectively construct a payment tree that "waits" for rewards when a block is found. The authors compare the average space occupied on the blockchain with that of P2Pool and find promising results. However, a significant challenge lies in the lack of cooperation among pool participants to facilitate cooperative withdrawal. This issue can be mitigated through the implementation of fees to enter the pool. Additionally, the balance can be timelocked in case of non-cooperative closure, serving as a deterrent.Furthermore, the authors suggest that past force-closures of pools can be seen as evidence of good conduct by future co-participants in a payment pool. Overall, the proposed scheme offers a potential solution for non-custodial payment pools and presents interesting avenues for further exploration. The authors have released their work as an RFC (Request for Comments) and encourage feedback and input from the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml b/static/bitcoin-dev/May_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml index b79174f1f2..1cce025083 100644 --- a/static/bitcoin-dev/May_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml +++ b/static/bitcoin-dev/May_2023/combined_Ark-An-Alternative-Privacy-preserving-Second-Layer-Solution.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - Ark: An Alternative Privacy-preserving Second Layer Solution - 2023-08-07T22:25:40.967928+00:00 - - Antoine Riard 2023-08-06 22:43:55+00:00 - - - moonsettler 2023-06-11 09:19:18+00:00 - - - David A. Harding 2023-06-07 18:20:33+00:00 - - - Burak Keceli 2023-06-07 13:30:07+00:00 - - - Ali Sherief 2023-05-28 06:02:58+00:00 - - - David A. Harding 2023-05-27 20:36:47+00:00 - - - Burak Keceli 2023-05-26 11:56:00+00:00 - - - jk_ at op.pl 2023-05-26 07:33:42+00:00 - - - Ali Sherief 2023-05-25 12:12:43+00:00 - - - David A. Harding 2023-05-24 23:02:40+00:00 - - - adiabat 2023-05-24 20:20:35+00:00 - - - Burak Keceli 2023-05-24 07:53:50+00:00 - - - Burak Keceli 2023-05-24 06:28:08+00:00 - - - ZmnSCPxj 2023-05-24 00:45:49+00:00 - - - ZmnSCPxj 2023-05-24 00:40:42+00:00 - - - G. Andrew Stone 2023-05-23 22:06:02+00:00 - - - Burak Keceli 2023-05-23 04:31:24+00:00 - - - ZmnSCPxj 2023-05-22 13:03:00+00:00 - - - Burak Keceli 2023-05-22 07:54:03+00:00 - + 2025-09-26T14:33:01.192410+00:00 + python-feedgen + + + Burak Keceli + 2023-05-22T07:54:00.000Z + + + ZmnSCPxj + 2023-05-22T13:03:00.000Z + + + Burak Keceli + 2023-05-23T04:31:00.000Z + + + G. Andrew Stone + 2023-05-23T22:06:00.000Z + + + ZmnSCPxj + 2023-05-24T00:40:00.000Z + + + ZmnSCPxj + 2023-05-24T00:45:00.000Z + + + Burak Keceli + 2023-05-24T06:28:00.000Z + + + Burak Keceli + 2023-05-24T07:53:00.000Z + + + adiabat + 2023-05-24T20:20:00.000Z + + + David A. Harding + 2023-05-24T23:02:00.000Z + + + Ali Sherief + 2023-05-25T12:12:00.000Z + + + jk_14 + 2023-05-26T07:33:00.000Z + + + Burak Keceli + 2023-05-26T11:56:00.000Z + + + David A. Harding + 2023-05-27T20:36:00.000Z + + + Ali Sherief + 2023-05-28T06:02:00.000Z + + + Burak Keceli + 2023-06-07T13:30:00.000Z + + + David A. Harding + 2023-06-07T18:20:00.000Z + + + [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution moonsettler + 2023-06-11T09:19:00.000Z + + + Antoine Riard + 2023-08-06T22:43:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - Ark: An Alternative Privacy-preserving Second Layer Solution - 2023-08-07T22:25:40.967928+00:00 + 2025-09-26T14:33:01.194681+00:00 - ZmnSCPxj raised concerns about the risks involved in designing a non-custodial Layer 2 payment system, emphasizing the need for thorough code testing before deployment. One risk highlighted is the use of 0-conf transactions, which are considered unsafe due to the potential for double-spending. This applies to both Lightning payments and swap-ins.In the case of Lightning, there is a specific concern when opening a zero-conf channel to receive payments. If the channel is not confirmed before revealing the payment's preimage, the Lightning Service Provider (LSP) can take the sender's money and double-spend on the channel. However, Ark provides an alternative solution using Atomic-Time Locked Contracts (ATLCs). With ATLCs, users can receive and forward payments without waiting for on-chain confirmations. Any attempt at double-spending breaks the entire atomicity, preventing the ASP from redeeming senders' vTXOs if they double-spend recipients' vTXOs.Burak and ZmnSCPxj further discuss risks associated with Lightning payments. They note that ASPs who fail to forward HTLCs after double-spending their pool transaction pose a potential issue known as a footgun. In contrast, Ark allows users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. This distinguishes Ark from swap-ins, where users must wait for on-chain confirmations before revealing their preimage of the HODL invoice to avoid double-spending risks.The email thread also includes a request for a detailed architecture write-up encompassing bitcoin scripts, transactions, and L2 protocols. Burak explains how ASPs may fail to forward Lightning payments on the broader network after being replaced in-mempool transactions. However, forwarding HTLCs before double-spending the pool transaction can prevent this issue. Ark's collaborative nature enables users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. In contrast, swap-ins require users to wait for on-chain confirmations before revealing their preimage of the HODL invoice to prevent funds from being stolen through double-spending by the swap service provider.Ark is introduced as a new second-layer protocol that offers an alternative approach to the Lightning network. It allows users to send and receive funds without liquidity constraints and has a smaller on-chain footprint compared to Lightning. The protocol utilizes virtual UTXOs (vTXOs) that exist off-chain and must be spent within four weeks of receipt. Existing vTXOs are redeemed and new ones created during payment transactions. To enhance anonymity, vTXO values are limited to a specific range. Users can acquire vTXOs from others or lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO through a process called lifting. Ark relies on Ark Service Providers (ASPs) as untrusted intermediaries who provide liquidity and charge fees. ASPs create rapid, blinded coinjoin sessions called pools, allowing users to make payments by registering their vTXOs for spending and recipients' vTXOs. Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction. Payments are credited every five seconds and settled every ten minutes, providing immediate availability without waiting for on-chain confirmations to spend zero-conf vTXOs.For more detailed information about Ark, refer to the website https://arkpill.me/deep-dive. 2023-08-06T22:43:55+00:00 + ZmnSCPxj raised concerns about the risks involved in designing a non-custodial Layer 2 payment system, emphasizing the need for thorough code testing before deployment. One risk highlighted is the use of 0-conf transactions, which are considered unsafe due to the potential for double-spending. This applies to both Lightning payments and swap-ins.In the case of Lightning, there is a specific concern when opening a zero-conf channel to receive payments. If the channel is not confirmed before revealing the payment's preimage, the Lightning Service Provider (LSP) can take the sender's money and double-spend on the channel. However, Ark provides an alternative solution using Atomic-Time Locked Contracts (ATLCs). With ATLCs, users can receive and forward payments without waiting for on-chain confirmations. Any attempt at double-spending breaks the entire atomicity, preventing the ASP from redeeming senders' vTXOs if they double-spend recipients' vTXOs.Burak and ZmnSCPxj further discuss risks associated with Lightning payments. They note that ASPs who fail to forward HTLCs after double-spending their pool transaction pose a potential issue known as a footgun. In contrast, Ark allows users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. This distinguishes Ark from swap-ins, where users must wait for on-chain confirmations before revealing their preimage of the HODL invoice to avoid double-spending risks.The email thread also includes a request for a detailed architecture write-up encompassing bitcoin scripts, transactions, and L2 protocols. Burak explains how ASPs may fail to forward Lightning payments on the broader network after being replaced in-mempool transactions. However, forwarding HTLCs before double-spending the pool transaction can prevent this issue. Ark's collaborative nature enables users to pay Lightning invoices with zero-conf vTXOs without waiting for on-chain confirmations. In contrast, swap-ins require users to wait for on-chain confirmations before revealing their preimage of the HODL invoice to prevent funds from being stolen through double-spending by the swap service provider.Ark is introduced as a new second-layer protocol that offers an alternative approach to the Lightning network. It allows users to send and receive funds without liquidity constraints and has a smaller on-chain footprint compared to Lightning. The protocol utilizes virtual UTXOs (vTXOs) that exist off-chain and must be spent within four weeks of receipt. Existing vTXOs are redeemed and new ones created during payment transactions. To enhance anonymity, vTXO values are limited to a specific range. Users can acquire vTXOs from others or lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO through a process called lifting. Ark relies on Ark Service Providers (ASPs) as untrusted intermediaries who provide liquidity and charge fees. ASPs create rapid, blinded coinjoin sessions called pools, allowing users to make payments by registering their vTXOs for spending and recipients' vTXOs. Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction. Payments are credited every five seconds and settled every ten minutes, providing immediate availability without waiting for on-chain confirmations to spend zero-conf vTXOs.For more detailed information about Ark, refer to the website https://arkpill.me/deep-dive. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Bitcoin-Core-24-1-released.xml b/static/bitcoin-dev/May_2023/combined_Bitcoin-Core-24-1-released.xml index 0192e2cbca..c154200c17 100644 --- a/static/bitcoin-dev/May_2023/combined_Bitcoin-Core-24-1-released.xml +++ b/static/bitcoin-dev/May_2023/combined_Bitcoin-Core-24-1-released.xml @@ -1,23 +1,32 @@ - + 2 Combined summary - Bitcoin Core 24.1 released - 2023-08-02T09:28:10.705920+00:00 - - Sjors Provoost 2023-05-19 11:20:26+00:00 - - - Michael Ford 2023-05-19 10:56:14+00:00 - + 2025-09-26T14:32:50.454271+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Core 24.1 released Michael Ford + 2023-05-19T10:56:00.000Z + + + Sjors Provoost + 2023-05-19T11:20:00.000Z + + + [bitcoin-dev] Full-RBF Peering Bitcoin Core v24.1 Released Peter Todd + 2023-05-21T21:21:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Core 24.1 released - 2023-08-02T09:28:10.705920+00:00 + 2025-09-26T14:32:50.454813+00:00 - On May 19, 2023, Michael Ford announced the release of Bitcoin Core version 24.1 via the bitcoin-dev mailing list. This new version can be downloaded from the official website or through BitTorrent, which includes a link with several trackers. However, one of the trackers has a typo in its subdomain: trakcer.bitcoin.sprovoost.nl instead of tracker.bitcoin.sprovoost.nl. Sjors noticed this error and mentioned it in a reply, promising to add the correct subdomain.Bitcoin Core version 24.1 comes with various bug fixes, performance improvements, and updated translations. To download this version, users can visit the official website or use BitTorrent. The release notes advise users to report any bugs using the GitHub issue tracker and subscribe to receive security and update notifications. Upgrading to the new version requires shutting down the older version and then running the installer on Windows or copying over `/Applications/Bitcoin-Qt` on macOS or `bitcoind`/`bitcoin-qt` on Linux. Compatibility-wise, Bitcoin Core is supported and tested on operating systems that use the Linux kernel, macOS 10.15+, and Windows 7 and newer. While it may work on other Unix-like systems, it is not recommended to use Bitcoin Core on unsupported systems.The release includes several improvements across different areas such as P2P, RPC and other APIs, Build System, Wallet, and GUI changes. For example, wallet users can now migrate their wallet by specifying a wallet name and passphrase, reuse change destinations when re-creating transactions with avoidpartialspends, and handle "unknown" Address Type properly. GUI changes involve loading PSBTs using istreambuf_iterator instead of istream_iterator and correctly limiting the overview transaction list.Lastly, the release acknowledges the contributions of individuals who directly or indirectly helped with the release. This includes Andrew Chow, Anthony Towns, Hennadii Stepanov, John Moffett, Jon Atack, Marco Falke, Martin Zumsande, Matthew Zipkin, Michael Ford, pablomartin4btc, Sebastian Falbesoner, Suhas Daftuar, Thomas Nguyen, Vasil Dimov, and those who assisted with translations on Transifex. These individuals have played a significant role in the development of Bitcoin Core version 24.1. 2023-05-19T11:20:26+00:00 + On May 19, 2023, Michael Ford announced the release of Bitcoin Core version 24.1 via the bitcoin-dev mailing list. This new version can be downloaded from the official website or through BitTorrent, which includes a link with several trackers. However, one of the trackers has a typo in its subdomain: trakcer.bitcoin.sprovoost.nl instead of tracker.bitcoin.sprovoost.nl. Sjors noticed this error and mentioned it in a reply, promising to add the correct subdomain.Bitcoin Core version 24.1 comes with various bug fixes, performance improvements, and updated translations. To download this version, users can visit the official website or use BitTorrent. The release notes advise users to report any bugs using the GitHub issue tracker and subscribe to receive security and update notifications. Upgrading to the new version requires shutting down the older version and then running the installer on Windows or copying over `/Applications/Bitcoin-Qt` on macOS or `bitcoind`/`bitcoin-qt` on Linux. Compatibility-wise, Bitcoin Core is supported and tested on operating systems that use the Linux kernel, macOS 10.15+, and Windows 7 and newer. While it may work on other Unix-like systems, it is not recommended to use Bitcoin Core on unsupported systems.The release includes several improvements across different areas such as P2P, RPC and other APIs, Build System, Wallet, and GUI changes. For example, wallet users can now migrate their wallet by specifying a wallet name and passphrase, reuse change destinations when re-creating transactions with avoidpartialspends, and handle "unknown" Address Type properly. GUI changes involve loading PSBTs using istreambuf_iterator instead of istream_iterator and correctly limiting the overview transaction list.Lastly, the release acknowledges the contributions of individuals who directly or indirectly helped with the release. This includes Andrew Chow, Anthony Towns, Hennadii Stepanov, John Moffett, Jon Atack, Marco Falke, Martin Zumsande, Matthew Zipkin, Michael Ford, pablomartin4btc, Sebastian Falbesoner, Suhas Daftuar, Thomas Nguyen, Vasil Dimov, and those who assisted with translations on Transifex. These individuals have played a significant role in the development of Bitcoin Core version 24.1. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Bitcoin-Core-maintainers-and-communication-on-merge-decisions.xml b/static/bitcoin-dev/May_2023/combined_Bitcoin-Core-maintainers-and-communication-on-merge-decisions.xml index 6f42312d84..0e50c74147 100644 --- a/static/bitcoin-dev/May_2023/combined_Bitcoin-Core-maintainers-and-communication-on-merge-decisions.xml +++ b/static/bitcoin-dev/May_2023/combined_Bitcoin-Core-maintainers-and-communication-on-merge-decisions.xml @@ -1,92 +1,123 @@ - + 2 Combined summary - Bitcoin Core maintainers and communication on merge decisions - 2023-08-02T09:18:07.628839+00:00 - - Erik Aronesty 2023-05-11 18:48:39+00:00 - - - Steve Lee 2023-05-11 18:04:08+00:00 - - - alicexbt 2023-05-11 16:49:36+00:00 - - - Michael Folkson 2023-05-11 12:34:57+00:00 - - - Andrew Chow 2023-05-10 21:24:52+00:00 - - - Steve Lee 2023-05-10 18:29:56+00:00 - - - Michael Folkson 2023-05-10 17:22:37+00:00 - - - Steve Lee 2023-05-10 16:36:54+00:00 - - - Michael Folkson 2023-05-10 15:55:25+00:00 - - - Steve Lee 2023-05-10 02:44:59+00:00 - - - Bryan Bishop 2023-05-08 12:03:10+00:00 - - - Michael Folkson 2023-05-08 09:36:27+00:00 - - - David A. Harding 2023-05-07 17:35:52+00:00 - - - Michael Folkson 2023-05-07 07:03:02+00:00 - - - Aymeric Vitte 2023-04-20 14:25:30+00:00 - - - Erik Aronesty 2023-04-20 13:59:07+00:00 - - - Aymeric Vitte 2023-04-20 10:54:53+00:00 - - - Michael Folkson 2023-04-20 09:24:19+00:00 - - - Michael Folkson 2023-04-20 08:45:58+00:00 - - - Anthony Towns 2023-04-20 02:27:13+00:00 - - - Andrew Chow 2023-04-19 21:33:33+00:00 - - - alicexbt 2023-04-19 21:13:23+00:00 - - - Aymeric Vitte 2023-04-19 15:17:02+00:00 - - - Michael Folkson 2023-04-19 13:33:35+00:00 - - - alicexbt 2023-04-19 12:24:15+00:00 - - - Michael Folkson 2023-04-19 10:09:00+00:00 - - - Erik Aronesty 2023-04-19 00:56:48+00:00 - - - Michael Folkson 2023-04-18 12:40:44+00:00 - + 2025-09-26T14:32:39.847174+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson + 2023-04-18T12:40:00.000Z + + + Erik Aronesty + 2023-04-19T00:56:00.000Z + + + Michael Folkson + 2023-04-19T10:09:00.000Z + + + alicexbt + 2023-04-19T12:24:00.000Z + + + Michael Folkson + 2023-04-19T13:33:00.000Z + + + Aymeric Vitte + 2023-04-19T15:17:00.000Z + + + alicexbt + 2023-04-19T21:13:00.000Z + + + Andrew Chow + 2023-04-19T21:33:00.000Z + + + Anthony Towns + 2023-04-20T02:27:00.000Z + + + Michael Folkson + 2023-04-20T08:45:00.000Z + + + Michael Folkson + 2023-04-20T09:24:00.000Z + + + Aymeric Vitte + 2023-04-20T10:54:00.000Z + + + Erik Aronesty + 2023-04-20T13:59:00.000Z + + + Aymeric Vitte + 2023-04-20T14:25:00.000Z + + + Michael Folkson + 2023-05-07T07:03:00.000Z + + + David A. Harding + 2023-05-07T17:35:00.000Z + + + Michael Folkson + 2023-05-08T09:36:00.000Z + + + Bryan Bishop + 2023-05-08T12:03:00.000Z + + + Steve Lee + 2023-05-10T02:44:00.000Z + + + Michael Folkson + 2023-05-10T15:55:00.000Z + + + Steve Lee + 2023-05-10T16:36:00.000Z + + + Michael Folkson + 2023-05-10T17:22:00.000Z + + + Steve Lee + 2023-05-10T18:29:00.000Z + + + Andrew Chow + 2023-05-10T21:24:00.000Z + + + Michael Folkson + 2023-05-11T12:34:00.000Z + + + alicexbt + 2023-05-11T16:49:00.000Z + + + Steve Lee + 2023-05-11T18:04:00.000Z + + + Erik Aronesty + 2023-05-11T18:48:00.000Z + + @@ -115,13 +146,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core maintainers and communication on merge decisions - 2023-08-02T09:18:07.629835+00:00 + 2025-09-26T14:32:39.852589+00:00 - Bitcoin Core is currently facing challenges with its decision-making process for adding or blocking new maintainers. There are concerns that the current maintainers have too much power in deciding who can join the project. Some contributors argue that Bitcoin Core should function as a volunteer project where independent contributors merge different pull requests or patches. They believe that the controls on GitHub are simply because of the platform's structure. Additionally, there is confusion between Bitcoin Core and the bitcoin protocol itself. Several articles are provided to help understand the decentralized nature of Bitcoin governance.Michael Folkson raised his concerns about the decision-making process for new maintainers in an email to David A. Harding. He worried that long-term contributors might be excluded from important discussions and decision-making processes. He also questioned the transparency and justification behind blocking certain individuals. David responded by explaining that many organizations have their current members choose new members, highlighting the need to evaluate whether the current maintainers are capable of moving Bitcoin Core in the desired direction.The discussion also touched on the need for clear governance structures in open-source projects like Bitcoin Core. It was suggested that criteria should be established for selecting new maintainers in order to maintain the decentralized nature of the project and prevent power consolidation. The lack of transparent and consistent criteria could lead to contentious consensus changes without justification or rationale.Another issue raised in the context is the communication challenges within the Bitcoin Core project. Maintainers often merge pull requests without providing commentary, leading to frustration and confusion among contributors. The high number of open pull requests and issues makes it difficult to keep up with all the activity in the repository. Some contributors argue that maintainers do not need to provide commentary on every merge, as it becomes self-evident when the code is ready to be merged based on the number of acknowledgments (ACKs) from contributors.There are concerns about the transparency and accountability of the maintainers in Bitcoin Core, as they sometimes refuse to discuss merge decisions. This lack of communication can create problems and lead to confusion among casual observers. However, it is acknowledged that there is also a need to prevent malicious interference with the project.The Bitcoin Core project has also faced challenges with its communication process and maintainers stepping down. The lack of commentary on merges by maintainers has been attributed to their belief that it is self-evident when the code is ready for merging based on the number of ACKs from contributors. With several long-time maintainers stepping away, there may be delays in merging pull requests as the remaining maintainers may be less familiar with certain parts of the codebase.The concerns about communication and maintainers' decision-making process have prompted discussions on the need for more transparency, accountability, and clear governance structures within the Bitcoin Core project. It is suggested that dedicated communication channels be used for internal project decisions, and criteria be established for selecting new maintainers. Maintainers are encouraged to provide more commentary on merges to improve transparency and understanding among contributors.Overall, the Bitcoin Core project is grappling with issues related to the decision-making process for new maintainers, communication challenges, and the need for transparent and consistent criteria. The discussions highlight the importance of maintaining the decentralized nature of the project and ensuring clear governance structures in open-source projects.Merge decisions within Bitcoin Core have also come under scrutiny, with concerns about transparency and accountability. The author argues that if the transparency and accountability of merge decisions are not improved, it is unlikely to be better on the default signet. They suggest that the lack of transparency and justification in merge/non-merge decisions could lead to investing more heavily in consensus-compatible forks of Core or treating Core as a proprietary "open-source" project where merge decisions are not explained or justified openly.Michael Folkson emphasizes the importance of communication and transparency in the development process. He mentions that maintaining a pull request for an extended period without any commentary can be frustrating for the author. He emphasizes the need for openness and discussion around merge decisions, while acknowledging that not every pull request requires commentary for merging if it has received enough reviews, ACKs, and lacks controversy.The perception that the bitcoin-inquisition/default signet is seen as the only staging ground for consensus changes is also raised as a concern. The author warns that this perception could be dangerous if the maintainer(s) of that project have the same inclinations as a subset of the Core maintainers. To counter this, they suggest the possibility of creating a custom signet with more reviews, testing, and regular updates to challenge this perception.In summary, the email thread discusses the communication challenges within Bitcoin Core, particularly regarding pull requests and maintainer decisions. Michael Folkson expresses frustration with the lack of commentary provided by maintainers when merging pull requests and the prolonged periods without resolution. He argues for more transparency, accountability, and open discussion around merge decisions to avoid misunderstandings and contentious activations. Folkson also raises concerns about the perception of the default signet as the sole staging ground for consensus changes, suggesting alternatives to challenge this perception. The importance of competition and 2023-05-11T18:48:39+00:00 + Bitcoin Core is currently facing challenges with its decision-making process for adding or blocking new maintainers. There are concerns that the current maintainers have too much power in deciding who can join the project. Some contributors argue that Bitcoin Core should function as a volunteer project where independent contributors merge different pull requests or patches. They believe that the controls on GitHub are simply because of the platform's structure. Additionally, there is confusion between Bitcoin Core and the bitcoin protocol itself. Several articles are provided to help understand the decentralized nature of Bitcoin governance.Michael Folkson raised his concerns about the decision-making process for new maintainers in an email to David A. Harding. He worried that long-term contributors might be excluded from important discussions and decision-making processes. He also questioned the transparency and justification behind blocking certain individuals. David responded by explaining that many organizations have their current members choose new members, highlighting the need to evaluate whether the current maintainers are capable of moving Bitcoin Core in the desired direction.The discussion also touched on the need for clear governance structures in open-source projects like Bitcoin Core. It was suggested that criteria should be established for selecting new maintainers in order to maintain the decentralized nature of the project and prevent power consolidation. The lack of transparent and consistent criteria could lead to contentious consensus changes without justification or rationale.Another issue raised in the context is the communication challenges within the Bitcoin Core project. Maintainers often merge pull requests without providing commentary, leading to frustration and confusion among contributors. The high number of open pull requests and issues makes it difficult to keep up with all the activity in the repository. Some contributors argue that maintainers do not need to provide commentary on every merge, as it becomes self-evident when the code is ready to be merged based on the number of acknowledgments (ACKs) from contributors.There are concerns about the transparency and accountability of the maintainers in Bitcoin Core, as they sometimes refuse to discuss merge decisions. This lack of communication can create problems and lead to confusion among casual observers. However, it is acknowledged that there is also a need to prevent malicious interference with the project.The Bitcoin Core project has also faced challenges with its communication process and maintainers stepping down. The lack of commentary on merges by maintainers has been attributed to their belief that it is self-evident when the code is ready for merging based on the number of ACKs from contributors. With several long-time maintainers stepping away, there may be delays in merging pull requests as the remaining maintainers may be less familiar with certain parts of the codebase.The concerns about communication and maintainers' decision-making process have prompted discussions on the need for more transparency, accountability, and clear governance structures within the Bitcoin Core project. It is suggested that dedicated communication channels be used for internal project decisions, and criteria be established for selecting new maintainers. Maintainers are encouraged to provide more commentary on merges to improve transparency and understanding among contributors.Overall, the Bitcoin Core project is grappling with issues related to the decision-making process for new maintainers, communication challenges, and the need for transparent and consistent criteria. The discussions highlight the importance of maintaining the decentralized nature of the project and ensuring clear governance structures in open-source projects.Merge decisions within Bitcoin Core have also come under scrutiny, with concerns about transparency and accountability. The author argues that if the transparency and accountability of merge decisions are not improved, it is unlikely to be better on the default signet. They suggest that the lack of transparency and justification in merge/non-merge decisions could lead to investing more heavily in consensus-compatible forks of Core or treating Core as a proprietary "open-source" project where merge decisions are not explained or justified openly.Michael Folkson emphasizes the importance of communication and transparency in the development process. He mentions that maintaining a pull request for an extended period without any commentary can be frustrating for the author. He emphasizes the need for openness and discussion around merge decisions, while acknowledging that not every pull request requires commentary for merging if it has received enough reviews, ACKs, and lacks controversy.The perception that the bitcoin-inquisition/default signet is seen as the only staging ground for consensus changes is also raised as a concern. The author warns that this perception could be dangerous if the maintainer(s) of that project have the same inclinations as a subset of the Core maintainers. To counter this, they suggest the possibility of creating a custom signet with more reviews, testing, and regular updates to challenge this perception.In summary, the email thread discusses the communication challenges within Bitcoin Core, particularly regarding pull requests and maintainer decisions. Michael Folkson expresses frustration with the lack of commentary provided by maintainers when merging pull requests and the prolonged periods without resolution. He argues for more transparency, accountability, and open discussion around merge decisions to avoid misunderstandings and contentious activations. Folkson also raises concerns about the perception of the default signet as the sole staging ground for consensus changes, suggesting alternatives to challenge this perception. The importance of competition and - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Bitcoin-Transaction-Relay-over-Nostr.xml b/static/bitcoin-dev/May_2023/combined_Bitcoin-Transaction-Relay-over-Nostr.xml index da186fcce4..4dab9d2025 100644 --- a/static/bitcoin-dev/May_2023/combined_Bitcoin-Transaction-Relay-over-Nostr.xml +++ b/static/bitcoin-dev/May_2023/combined_Bitcoin-Transaction-Relay-over-Nostr.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Bitcoin Transaction Relay over Nostr - 2023-08-02T09:31:22.511099+00:00 - - Greg Sanders 2023-05-30 13:30:32+00:00 - - - Joost Jager 2023-05-30 12:30:51+00:00 - - - David A. Harding 2023-05-28 02:37:12+00:00 - - - Joost Jager 2023-05-23 15:26:18+00:00 - - - alicexbt 2023-05-23 13:25:31+00:00 - - - Joost Jager 2023-05-23 07:19:17+00:00 - + 2025-09-26T14:32:29.202013+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Transaction Relay over Nostr Joost Jager + 2023-05-23T07:19:00.000Z + + + alicexbt + 2023-05-23T13:25:00.000Z + + + Joost Jager + 2023-05-23T15:26:00.000Z + + + David A. Harding + 2023-05-28T02:37:00.000Z + + + Joost Jager + 2023-05-30T12:30:00.000Z + + + Greg Sanders + 2023-05-30T13:30:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Transaction Relay over Nostr - 2023-08-02T09:31:22.511099+00:00 + 2025-09-26T14:32:29.202844+00:00 - In a Bitcoin development email thread, there is a discussion about the concept of weak blocks and block templates, and how they can improve the efficiency and profitability of miners. Weak blocks are blocks whose headers don't hash to a low enough value to be included on the chain, while block templates are ordered lists of raw transactions that a full node can validate and calculate fees for. The suggestion is to use a Nostr relay to relay block templates and weak blocks, which would make it easier for external services to build the best possible block using advanced algorithms. Additionally, relaying weak blocks through Nostr could compensate for the reduced effectiveness of BIP152 compact block relay caused by custom transactions not seen by typical relay nodes. This would also help with fee estimation and provide insights for those trying to get their transactions included in the next block.The conversation also touches on the idea of encrypting transactions while publishing them as Nostr events, which would allow different clients to display transactions as an external mempool sorted by fee rate without compromising user privacy. However, there are concerns about the authenticity of encrypted transactions and the potential distortion of the mempool view. Incentives for mining pools to include these transactions in their blocks are discussed, particularly if they offer higher fee rates compared to transactions in the normal mempool. NIP4 is proposed as a means to privately coordinate everything between users and pools, with users locking some sats in a 2-of-2 multisig and releasing them to the mining pool upon confirmation. Out-of-band payment is suggested as an option if the fee included in the transaction itself is insufficient, but the question remains whether miners would trust users to actually release the payment after confirmation.Joost Jager introduces an alternative approach for Bitcoin transaction relay called Nostr, which is an open and decentralized network of relays for public and ephemeral messages between pseudonymous entities. With the standards defined in NIP-89, it becomes possible to broadcast arbitrary Bitcoin transaction packages, overcoming limitations in the current P2P relay system. Miners can listen for these broadcasted transaction packages and insert them into their local mempool using the `submitpackage` RPC. This feature serves as an interim solution for package relay until it becomes available through traditional P2P methods. Implementing Nostr as a relay mechanism can help democratize access to miner mempools and introduce more flexibility in the system, potentially boosting its resilience. A prototype of this concept has been created, and a demonstration video is available.Overall, the discussions revolve around improving block relay efficiency, addressing DoS threats, exploring alternative relay mechanisms, and enhancing user privacy and incentives for miners. The proposed ideas like weak blocks, block templates, and Nostr relay show potential in enhancing the Bitcoin network's performance and security while promoting a more inclusive and efficient system for all participants. 2023-05-30T13:30:32+00:00 + In a Bitcoin development email thread, there is a discussion about the concept of weak blocks and block templates, and how they can improve the efficiency and profitability of miners. Weak blocks are blocks whose headers don't hash to a low enough value to be included on the chain, while block templates are ordered lists of raw transactions that a full node can validate and calculate fees for. The suggestion is to use a Nostr relay to relay block templates and weak blocks, which would make it easier for external services to build the best possible block using advanced algorithms. Additionally, relaying weak blocks through Nostr could compensate for the reduced effectiveness of BIP152 compact block relay caused by custom transactions not seen by typical relay nodes. This would also help with fee estimation and provide insights for those trying to get their transactions included in the next block.The conversation also touches on the idea of encrypting transactions while publishing them as Nostr events, which would allow different clients to display transactions as an external mempool sorted by fee rate without compromising user privacy. However, there are concerns about the authenticity of encrypted transactions and the potential distortion of the mempool view. Incentives for mining pools to include these transactions in their blocks are discussed, particularly if they offer higher fee rates compared to transactions in the normal mempool. NIP4 is proposed as a means to privately coordinate everything between users and pools, with users locking some sats in a 2-of-2 multisig and releasing them to the mining pool upon confirmation. Out-of-band payment is suggested as an option if the fee included in the transaction itself is insufficient, but the question remains whether miners would trust users to actually release the payment after confirmation.Joost Jager introduces an alternative approach for Bitcoin transaction relay called Nostr, which is an open and decentralized network of relays for public and ephemeral messages between pseudonymous entities. With the standards defined in NIP-89, it becomes possible to broadcast arbitrary Bitcoin transaction packages, overcoming limitations in the current P2P relay system. Miners can listen for these broadcasted transaction packages and insert them into their local mempool using the `submitpackage` RPC. This feature serves as an interim solution for package relay until it becomes available through traditional P2P methods. Implementing Nostr as a relay mechanism can help democratize access to miner mempools and introduce more flexibility in the system, potentially boosting its resilience. A prototype of this concept has been created, and a demonstration video is available.Overall, the discussions revolve around improving block relay efficiency, addressing DoS threats, exploring alternative relay mechanisms, and enhancing user privacy and incentives for miners. The proposed ideas like weak blocks, block templates, and Nostr relay show potential in enhancing the Bitcoin network's performance and security while promoting a more inclusive and efficient system for all participants. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml b/static/bitcoin-dev/May_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml index 793d740c93..c81e5e8606 100644 --- a/static/bitcoin-dev/May_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml +++ b/static/bitcoin-dev/May_2023/combined_Civ-Kit-A-Peer-to-Peer-Electronic-Market-System.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Civ Kit: A Peer-to-Peer Electronic Market System - 2023-08-02T09:14:15.352548+00:00 - - Antoine Riard 2023-06-30 03:46:32+00:00 - - - Chris Stewart 2023-05-09 15:09:16+00:00 - - - Antoine Riard 2023-05-01 17:47:46+00:00 - - - Antoine Riard 2023-04-13 14:10:01+00:00 - + 2025-09-26T14:32:31.321777+00:00 + python-feedgen + + + [bitcoin-dev] Civ Kit: A Peer-to-Peer Electronic Market System Antoine Riard + 2023-04-13T14:10:00.000Z + + + Antoine Riard + 2023-05-01T17:47:00.000Z + + + Chris Stewart + 2023-05-09T15:09:00.000Z + + + Antoine Riard + 2023-06-30T03:46:00.000Z + + - python-feedgen + 2 Combined summary - Civ Kit: A Peer-to-Peer Electronic Market System - 2023-08-02T09:14:15.352548+00:00 + 2025-09-26T14:32:31.322533+00:00 - The email thread discusses the concept of front-running in peer-to-peer marketplaces and the concern that bulletin board operators may front-run trades. However, there are security paradigms proposed to mitigate this risk, such as duplicating offers to multiple boards and monitoring latency anomalies. Running bulletin boards as federations with consensus rules is also suggested.The CivKit architecture aims to provide a flexible framework for peer-to-peer marketplaces, adapting to the needs of market participants. It aims to create a censorship-resistant and permissionless global trading system while addressing concerns like front-running. The paper delves into the architecture in detail, combining the Nostr architecture with Lightning onion routing infrastructure. The market boards are Nostr relays with a Lightning gateway, operating autonomously and in competition.The trades are escrowed under Bitcoin Script contracts, relying on moderations and know your peer oracles for adjudication. A consistent incentive framework for service operators is proposed through privacy-preserving credentials backed by Bitcoin payments. The authors plan to release code and modules gradually, leveraging the Lightning Dev Kit and Nostr libraries. They express their enthusiasm for collaborating with the community to standardize libraries and ensure interoperability between clients.The email provides links to various resources including the paper itself, external references like the Lightning Dev Kit and W3C DID Core specification, and the Privacy Pass project. The authors welcome feedback from readers and encourage an interactive dialogue. They provide a mailing list for further discussion and engagement with the Bitcoin development community. 2023-06-30T03:46:32+00:00 + The email thread discusses the concept of front-running in peer-to-peer marketplaces and the concern that bulletin board operators may front-run trades. However, there are security paradigms proposed to mitigate this risk, such as duplicating offers to multiple boards and monitoring latency anomalies. Running bulletin boards as federations with consensus rules is also suggested.The CivKit architecture aims to provide a flexible framework for peer-to-peer marketplaces, adapting to the needs of market participants. It aims to create a censorship-resistant and permissionless global trading system while addressing concerns like front-running. The paper delves into the architecture in detail, combining the Nostr architecture with Lightning onion routing infrastructure. The market boards are Nostr relays with a Lightning gateway, operating autonomously and in competition.The trades are escrowed under Bitcoin Script contracts, relying on moderations and know your peer oracles for adjudication. A consistent incentive framework for service operators is proposed through privacy-preserving credentials backed by Bitcoin payments. The authors plan to release code and modules gradually, leveraging the Lightning Dev Kit and Nostr libraries. They express their enthusiasm for collaborating with the community to standardize libraries and ensure interoperability between clients.The email provides links to various resources including the paper itself, external references like the Lightning Dev Kit and W3C DID Core specification, and the Privacy Pass project. The authors welcome feedback from readers and encourage an interactive dialogue. They provide a mailing list for further discussion and engagement with the Bitcoin development community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Coinjoin-with-less-steps-using-ALL-ANYONECANPAY.xml b/static/bitcoin-dev/May_2023/combined_Coinjoin-with-less-steps-using-ALL-ANYONECANPAY.xml index 370e98ee37..bedda43b89 100644 --- a/static/bitcoin-dev/May_2023/combined_Coinjoin-with-less-steps-using-ALL-ANYONECANPAY.xml +++ b/static/bitcoin-dev/May_2023/combined_Coinjoin-with-less-steps-using-ALL-ANYONECANPAY.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Coinjoin with less steps using ALL|ANYONECANPAY - 2023-08-02T09:30:57.541979+00:00 - - alicexbt 2023-05-23 12:48:02+00:00 - - - alicexbt 2023-05-23 12:34:03+00:00 - - - Lucas Ontivero 2023-05-23 12:17:23+00:00 - - - Ben Carman 2023-05-22 22:51:49+00:00 - - - alicexbt 2023-05-22 12:51:22+00:00 - + 2025-09-26T14:32:56.932890+00:00 + python-feedgen + + + [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY alicexbt + 2023-05-22T12:51:00.000Z + + + Ben Carman + 2023-05-22T22:51:00.000Z + + + Lucas Ontivero + 2023-05-23T12:17:00.000Z + + + alicexbt + 2023-05-23T12:34:00.000Z + + + alicexbt + 2023-05-23T12:48:00.000Z + + - python-feedgen + 2 Combined summary - Coinjoin with less steps using ALL|ANYONECANPAY - 2023-08-02T09:30:57.541979+00:00 + 2025-09-26T14:32:56.933628+00:00 - In a recent Bitcoin Protocol Discussion post, a user named AliceXBt suggested using the ALL|ANYONECANPAY sighash flag in CoinJoin to streamline the process. This approach involves registering outputs and creating a signed PSBT with one input, all registered outputs, and the sighash flag. Other participants would then add their inputs to the PSBT before finalizing and broadcasting the transaction. While this method could reduce some steps in CoinJoin, there are concerns about security.The main issues with using the ALL|ANYONECANPAY flag include the possibility of the coordinator adding its own inputs, which could compromise privacy benefits. There is also a risk of inputs from sanctioned addresses being included. However, these issues can be addressed through client-side validation and by disallowing certain types of inputs. Joinstr plans to use NIP38/48 channels for CoinJoin rounds to ensure that only participants are aware of the details.Another proposal in a Bitcoin Developers discussion group focused on the order in which inputs are registered in coinjoin implementations. It was suggested that registering inputs first could make denial of service (DoS) attacks more expensive. However, using the ALL|ANYONECANPAY flag may have drawbacks, such as the inability to verify beforehand if the other inputs are the desired ones or allowing inputs from sanctioned addresses. The ln-vortex code for verifying PSBT on the client side was provided as an example.A proof of concept was presented using ALL|ANYONECANPAY to reduce steps in coinjoin. One user created a signed PSBT with one input and all registered outputs, while other participants added their inputs to the PSBT before finalizing and broadcasting the transaction. The poster plans to implement this method in joinstr if there are no major drawbacks, and encourages others to adopt it for their coinjoin implementations.While the ALL|ANYONECANPAY sighash flag offers potential benefits in reducing steps in CoinJoin, there are risks to consider. The inability to verify beforehand if the desired inputs are included in the transaction can lead to unintended consequences, such as the coordinator adding its own inputs or a lack of uniformity due to different input types or amounts. However, the ln-vortex code provides client-side validation for PSBT, and a proof of concept has been shared to demonstrate the feasibility of using ALL|ANYONECANPAY. The sender plans to implement this approach in joinstr and invites others to do the same. 2023-05-23T12:48:02+00:00 + In a recent Bitcoin Protocol Discussion post, a user named AliceXBt suggested using the ALL|ANYONECANPAY sighash flag in CoinJoin to streamline the process. This approach involves registering outputs and creating a signed PSBT with one input, all registered outputs, and the sighash flag. Other participants would then add their inputs to the PSBT before finalizing and broadcasting the transaction. While this method could reduce some steps in CoinJoin, there are concerns about security.The main issues with using the ALL|ANYONECANPAY flag include the possibility of the coordinator adding its own inputs, which could compromise privacy benefits. There is also a risk of inputs from sanctioned addresses being included. However, these issues can be addressed through client-side validation and by disallowing certain types of inputs. Joinstr plans to use NIP38/48 channels for CoinJoin rounds to ensure that only participants are aware of the details.Another proposal in a Bitcoin Developers discussion group focused on the order in which inputs are registered in coinjoin implementations. It was suggested that registering inputs first could make denial of service (DoS) attacks more expensive. However, using the ALL|ANYONECANPAY flag may have drawbacks, such as the inability to verify beforehand if the other inputs are the desired ones or allowing inputs from sanctioned addresses. The ln-vortex code for verifying PSBT on the client side was provided as an example.A proof of concept was presented using ALL|ANYONECANPAY to reduce steps in coinjoin. One user created a signed PSBT with one input and all registered outputs, while other participants added their inputs to the PSBT before finalizing and broadcasting the transaction. The poster plans to implement this method in joinstr if there are no major drawbacks, and encourages others to adopt it for their coinjoin implementations.While the ALL|ANYONECANPAY sighash flag offers potential benefits in reducing steps in CoinJoin, there are risks to consider. The inability to verify beforehand if the desired inputs are included in the transaction can lead to unintended consequences, such as the coordinator adding its own inputs or a lack of uniformity due to different input types or amounts. However, the ln-vortex code provides client-side validation for PSBT, and a proof of concept has been shared to demonstrate the feasibility of using ALL|ANYONECANPAY. The sender plans to implement this approach in joinstr and invites others to do the same. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Formosa-proposed-improvement-upon-BIP39.xml b/static/bitcoin-dev/May_2023/combined_Formosa-proposed-improvement-upon-BIP39.xml index c6b771e8b8..6463d0fdb2 100644 --- a/static/bitcoin-dev/May_2023/combined_Formosa-proposed-improvement-upon-BIP39.xml +++ b/static/bitcoin-dev/May_2023/combined_Formosa-proposed-improvement-upon-BIP39.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Formosa --- proposed improvement upon BIP39 - 2023-08-02T09:23:27.878283+00:00 - - yurisvb at pm.me 2023-06-05 14:22:04+00:00 - - - yurisvb at pm.me 2023-05-19 23:08:36+00:00 - - - Keagan McClelland 2023-05-19 21:24:45+00:00 - - - yurisvb at pm.me 2023-05-02 08:31:19+00:00 - + 2025-09-26T14:32:48.341938+00:00 + python-feedgen + + + [bitcoin-dev] Formosa --- proposed improvement upon BIP39 yurisvb + 2023-05-02T08:31:00.000Z + + + Keagan McClelland + 2023-05-19T21:24:00.000Z + + + yurisvb + 2023-05-19T23:08:00.000Z + + + yurisvb + 2023-06-05T14:22:00.000Z + + - python-feedgen + 2 Combined summary - Formosa --- proposed improvement upon BIP39 - 2023-08-02T09:23:27.878283+00:00 + 2025-09-26T14:32:48.342617+00:00 - Yuri S Villas Boas has published an article on Toptal's Technology Blog introducing Formosa, a password format that aims to improve upon BIP39. Unlike BIP39, which uses semantically disconnected words for seed phrases, Formosa allows for meaningful, themed sentences with a regular grammatical structure. This system is simple and can be understood by any IT professional in less than 10 minutes. Formosa uses a fixed grammatical structure for sentences, making it easy to implement and customize themes. It also retains important properties of BIP39, such as checksum bits and uniformly high entropy density. This leads to efficient auto-complete and resistance to side-channel attacks. The article also touches on the issue of loss of Bitcoin at a higher rate than it is mined, and how non-technical individuals who adopt Bitcoin can feel emotional pain when they lose their patrimony. Yuri argues that a solution for coercion-resistance should not rely on obscurity. He mentions that we currently lack defenses to coercion that don't violate Kerckhoff's principle by critically relying on obscurity. Yuri plans to make a thread about this critical issue soon.In response to feedback from Keagan McClelland, Yuri explains that Formosa extends BIP39 rather than replacing it. This allows for forwards and backwards compatibility, facilitating adoption. Themes used in Formosa are convertible into one another, and legacy addresses can be kept even if a user chooses a theme. While increased memorability could make $5 wrench attacks more viable, Yuri argues that knowledge-based authentication still has properties that possession-based authentication doesn't. He suggests that mitigating the shortcomings of knowledge-based authentication can be done better with two-factor authentication instead of possession-based authentication.Yuri S VB has proposed a password format as a Bitcoin Improvement Proposal that enhances BIP39. The proposed format allows for meaningful, themed sentences with a regular grammatical structure while maintaining the same entropy/checksum and total bits/non-repeating leading digits ratios. This process aims to extend BIP39 rather than replace it, in order to avoid the need for everyone in the ecosystem to adopt a new standard. The main value proposition of this scheme is significant wallet interoperability. Anecdotal experiments suggest that long-term memorization of 128 + 4 bits (equivalent to the 12 words standard of BIP39) can be achieved in less than one hour with the use of a theme. Users who want to avoid the vulnerability to coercion that an effective brain wallet would entail can take advantage of the easier transcription and checking without memorizing the seed for the long term.Yuri, a developer, has proposed a password format that improves upon BIP39 by allowing meaningful, themed sentences with a regular grammatical structure. This proposal aims to make it easier for users to memorize their seed phrases. The intention is to extend BIP39 rather than replace it, as BIP39 is widely used in the ecosystem. The main benefit of this proposal is significant wallet interoperability. However, there may be concerns about whether the increased memorability of the seed phrases is a good thing, as it could make $5 wrench attacks more viable. There is also a possibility that widespread adoption of this technology could change the ratio of loss versus theft in the Bitcoin ecosystem. The proposal is available on GitHub for further exploration and scrutiny by colleagues. 2023-06-05T14:22:04+00:00 + Yuri S Villas Boas has published an article on Toptal's Technology Blog introducing Formosa, a password format that aims to improve upon BIP39. Unlike BIP39, which uses semantically disconnected words for seed phrases, Formosa allows for meaningful, themed sentences with a regular grammatical structure. This system is simple and can be understood by any IT professional in less than 10 minutes. Formosa uses a fixed grammatical structure for sentences, making it easy to implement and customize themes. It also retains important properties of BIP39, such as checksum bits and uniformly high entropy density. This leads to efficient auto-complete and resistance to side-channel attacks. The article also touches on the issue of loss of Bitcoin at a higher rate than it is mined, and how non-technical individuals who adopt Bitcoin can feel emotional pain when they lose their patrimony. Yuri argues that a solution for coercion-resistance should not rely on obscurity. He mentions that we currently lack defenses to coercion that don't violate Kerckhoff's principle by critically relying on obscurity. Yuri plans to make a thread about this critical issue soon.In response to feedback from Keagan McClelland, Yuri explains that Formosa extends BIP39 rather than replacing it. This allows for forwards and backwards compatibility, facilitating adoption. Themes used in Formosa are convertible into one another, and legacy addresses can be kept even if a user chooses a theme. While increased memorability could make $5 wrench attacks more viable, Yuri argues that knowledge-based authentication still has properties that possession-based authentication doesn't. He suggests that mitigating the shortcomings of knowledge-based authentication can be done better with two-factor authentication instead of possession-based authentication.Yuri S VB has proposed a password format as a Bitcoin Improvement Proposal that enhances BIP39. The proposed format allows for meaningful, themed sentences with a regular grammatical structure while maintaining the same entropy/checksum and total bits/non-repeating leading digits ratios. This process aims to extend BIP39 rather than replace it, in order to avoid the need for everyone in the ecosystem to adopt a new standard. The main value proposition of this scheme is significant wallet interoperability. Anecdotal experiments suggest that long-term memorization of 128 + 4 bits (equivalent to the 12 words standard of BIP39) can be achieved in less than one hour with the use of a theme. Users who want to avoid the vulnerability to coercion that an effective brain wallet would entail can take advantage of the easier transcription and checking without memorizing the seed for the long term.Yuri, a developer, has proposed a password format that improves upon BIP39 by allowing meaningful, themed sentences with a regular grammatical structure. This proposal aims to make it easier for users to memorize their seed phrases. The intention is to extend BIP39 rather than replace it, as BIP39 is widely used in the ecosystem. The main benefit of this proposal is significant wallet interoperability. However, there may be concerns about whether the increased memorability of the seed phrases is a good thing, as it could make $5 wrench attacks more viable. There is also a possibility that widespread adoption of this technology could change the ratio of loss versus theft in the Bitcoin ecosystem. The proposal is available on GitHub for further exploration and scrutiny by colleagues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Merkleize-All-The-Things.xml b/static/bitcoin-dev/May_2023/combined_Merkleize-All-The-Things.xml index 347923303d..08ca1c4d3e 100644 --- a/static/bitcoin-dev/May_2023/combined_Merkleize-All-The-Things.xml +++ b/static/bitcoin-dev/May_2023/combined_Merkleize-All-The-Things.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - Merkleize All The Things - 2023-08-02T08:28:28.195475+00:00 - - Johan Torås Halseth 2023-05-30 07:34:09+00:00 - - - Salvatore Ingala 2023-05-28 10:24:14+00:00 - - - Johan Torås Halseth 2023-05-26 11:45:17+00:00 - - - Salvatore Ingala 2023-05-05 21:18:16+00:00 - - - Johan Torås Halseth 2023-05-04 08:34:07+00:00 - - - Salvatore Ingala 2023-05-01 21:15:20+00:00 - - - Salvatore Ingala 2023-05-01 13:11:08+00:00 - - - Johan Torås Halseth 2023-04-28 08:48:07+00:00 - - - Billy Tetrud 2022-12-13 06:59:27+00:00 - - - Salvatore Ingala 2022-12-01 08:47:22+00:00 - - - Rijndael 2022-11-30 22:09:33+00:00 - - - Rijndael 2022-11-30 19:42:08+00:00 - - - Salvatore Ingala 2022-11-12 15:04:20+00:00 - - - Antoine Riard 2022-11-11 21:49:58+00:00 - - - Salvatore Ingala 2022-11-10 09:42:30+00:00 - - - David A. Harding 2022-11-10 07:39:10+00:00 - - - Peter Todd 2022-11-09 12:07:33+00:00 - - - Bram Cohen 2022-11-08 23:34:32+00:00 - - - ZmnSCPxj 2022-11-08 12:01:11+00:00 - - - Salvatore Ingala 2022-11-08 09:17:42+00:00 - + 2025-09-26T14:32:27.081940+00:00 + python-feedgen + + + [bitcoin-dev] Merkleize All The Things Salvatore Ingala + 2022-11-08T09:17:00.000Z + + + ZmnSCPxj + 2022-11-08T12:01:00.000Z + + + Bram Cohen + 2022-11-08T23:34:00.000Z + + + Peter Todd + 2022-11-09T12:07:00.000Z + + + David A. Harding + 2022-11-10T07:39:00.000Z + + + Salvatore Ingala + 2022-11-10T09:42:00.000Z + + + Antoine Riard + 2022-11-11T21:49:00.000Z + + + Salvatore Ingala + 2022-11-12T15:04:00.000Z + + + Rijndael + 2022-11-30T19:42:00.000Z + + + Rijndael + 2022-11-30T22:09:00.000Z + + + Salvatore Ingala + 2022-12-01T08:47:00.000Z + + + Billy Tetrud + 2022-12-13T06:59:00.000Z + + + Johan Torås Halseth + 2023-04-28T08:48:00.000Z + + + Salvatore Ingala + 2023-05-01T13:11:00.000Z + + + Salvatore Ingala + 2023-05-01T21:15:00.000Z + + + Johan Torås Halseth + 2023-05-04T08:34:00.000Z + + + Salvatore Ingala + 2023-05-05T21:18:00.000Z + + + Johan Torås Halseth + 2023-05-26T11:45:00.000Z + + + Salvatore Ingala + 2023-05-28T10:24:00.000Z + + + Johan Torås Halseth + 2023-05-30T07:34:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - Merkleize All The Things - 2023-08-02T08:28:28.196514+00:00 + 2025-09-26T14:32:27.084120+00:00 - In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain. He provided a simpler game example to clarify the relationship between the covenant and the bisection protocol.Salvatore Ingala proposed MATT (Merkleize All The Things) as a method for enabling general 2023-05-30T07:34:09+00:00 + In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain. He provided a simpler game example to clarify the relationship between the covenant and the bisection protocol.Salvatore Ingala proposed MATT (Merkleize All The Things) as a method for enabling general - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_On-adaptor-security-in-protocols-.xml b/static/bitcoin-dev/May_2023/combined_On-adaptor-security-in-protocols-.xml index 66901adf31..08a88e8351 100644 --- a/static/bitcoin-dev/May_2023/combined_On-adaptor-security-in-protocols-.xml +++ b/static/bitcoin-dev/May_2023/combined_On-adaptor-security-in-protocols-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - On adaptor security (in protocols) - 2023-08-02T09:22:26.483449+00:00 - - AdamISZ 2023-05-14 08:37:50+00:00 - - - Lloyd Fournier 2023-05-11 11:41:14+00:00 - - - AdamISZ 2023-05-11 05:12:39+00:00 - - - Lloyd Fournier 2023-05-08 04:37:48+00:00 - - - AdamISZ 2023-05-03 12:58:21+00:00 - - - AdamISZ 2023-05-01 18:37:27+00:00 - - - Lloyd Fournier 2023-05-01 04:23:30+00:00 - - - AdamISZ 2023-04-28 18:13:03+00:00 - + 2025-09-26T14:32:46.228836+00:00 + python-feedgen + + + [bitcoin-dev] On adaptor security (in protocols) AdamISZ + 2023-04-28T18:13:00.000Z + + + Lloyd Fournier + 2023-05-01T04:23:00.000Z + + + AdamISZ + 2023-05-01T18:37:00.000Z + + + AdamISZ + 2023-05-03T12:58:00.000Z + + + Lloyd Fournier + 2023-05-08T04:37:00.000Z + + + AdamISZ + 2023-05-11T05:12:00.000Z + + + Lloyd Fournier + 2023-05-11T11:41:00.000Z + + + AdamISZ + 2023-05-14T08:37:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - On adaptor security (in protocols) - 2023-08-02T09:22:26.483449+00:00 + 2025-09-26T14:32:46.229844+00:00 - In an email exchange between AdamISZ and Lloyd Fournier, they discuss the usefulness of single signer adaptors in Bitcoin. They conclude that single key signature adaptor in isolation is basically useless in a Bitcoin context but it could be useful in combination with another locking condition on the utxo such as another pubkey lock. They also discuss the canonical adaptor-based swap where Alice can encrypt the single-key signature for her payment to Bob, revealing the partial signature of Bob, on the payout from a multisig, to Alice. However, they mention that Alice can still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. Lloyd states that single signer adaptor signatures have been used as signature encryption in practice for years for the transaction signatures by DLC client implementations and are even used in channel implementations as well as atomic swaps.On May 11th, 2023, AdamISZ sent an email to Lloyd Fournier discussing a potential variant of the canonical adaptor based swap. He suggests that Alice can encrypt the single-key signature for her payment to Bob with the encryption key being T = sG, where s is the partial signature of Bob on the payout from a multisig to Alice. However, Lloyd points out that Alice could still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. He notes that a multisig is always necessary in these situations, but it need not be a key aggregated multisig like MuSig. Lloyd also mentions that there is no useful use of a single signer adaptor signature in Bitcoin without some kind of other spending constraint.On May 8th, 2023, Lloyd and AdamISZ had a conversation discussing the usefulness of single signer adaptors. Lloyd argues that they do provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret. He gives an example of holding a secret key for X and creating a signature adaptor with some encryption key Y with message m. If he does not create any further signatures on m, then any signature on m that is published necessarily reveals the secret on Y to him. This property can be useful in practice and has already been used for years by DLCs in production. However, AdamISZ struggles to understand this point and references Dryja's construct and single key Schnorr, stating that they are missing and therefore making them useless. Lloyd clarifies that he was not referencing the DLC oracle attestation protocol but rather pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for transaction signatures. There are even channel implementations using them as well as atomic swaps doing this.In an email exchange between AdamISZ and Lloyd Fournier via bitcoin-dev, they discuss the usefulness of single signer adaptors. Fournier argues that if a secret key is held for X and a signature adaptor is created with encryption key Y for message m, any signature on m published reveals the secret on Y to the holder of the secret key for X, making it a useful property in theory and practice. AdamISZ initially struggles to understand this concept but eventually acknowledges his error and admits to having a misconception about adaptors for years. They also discuss the framing of s' = k - t +H(R|P|m)x vs s' = k + H(R+T|P|m)x and a potential variant of the canonical adaptor based swap. Fournier clarifies that he was not referencing the DLC oracle attestation protocol, but rather pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for transaction signatures, making them a pretty useful thing. The conversation ends on a cordial note with cheers exchanged.In an email exchange between AdamISZ and Lloyd Fournier, they discussed the usefulness of single signer adaptors. While Fournier had previously claimed that they were useless as they did not provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret, AdamISZ disagreed. He argued that if he held a secret key for X and created a signature adaptor with some encryption key Y with message m and did not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to him. This property is useful in theory and practice. Fournier was confused by AdamISZ's statement and asked for clarification on what he meant by "any signature on m that is published reveals y." AdamISZ elaborated that if only one adaptor signature is generated on m and no other signatures on m are created, then a signature on m that appears under the key would reveal y to him. Fournier thought that the confusion might be about the DLC construct, which is analogous to single key Schnorr. However, AdamISZ clarified that he was not referencing the DLC oracle attestation protocol but was pointing out that 2023-05-14T08:37:50+00:00 + In an email exchange between AdamISZ and Lloyd Fournier, they discuss the usefulness of single signer adaptors in Bitcoin. They conclude that single key signature adaptor in isolation is basically useless in a Bitcoin context but it could be useful in combination with another locking condition on the utxo such as another pubkey lock. They also discuss the canonical adaptor-based swap where Alice can encrypt the single-key signature for her payment to Bob, revealing the partial signature of Bob, on the payout from a multisig, to Alice. However, they mention that Alice can still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. Lloyd states that single signer adaptor signatures have been used as signature encryption in practice for years for the transaction signatures by DLC client implementations and are even used in channel implementations as well as atomic swaps.On May 11th, 2023, AdamISZ sent an email to Lloyd Fournier discussing a potential variant of the canonical adaptor based swap. He suggests that Alice can encrypt the single-key signature for her payment to Bob with the encryption key being T = sG, where s is the partial signature of Bob on the payout from a multisig to Alice. However, Lloyd points out that Alice could still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. He notes that a multisig is always necessary in these situations, but it need not be a key aggregated multisig like MuSig. Lloyd also mentions that there is no useful use of a single signer adaptor signature in Bitcoin without some kind of other spending constraint.On May 8th, 2023, Lloyd and AdamISZ had a conversation discussing the usefulness of single signer adaptors. Lloyd argues that they do provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret. He gives an example of holding a secret key for X and creating a signature adaptor with some encryption key Y with message m. If he does not create any further signatures on m, then any signature on m that is published necessarily reveals the secret on Y to him. This property can be useful in practice and has already been used for years by DLCs in production. However, AdamISZ struggles to understand this point and references Dryja's construct and single key Schnorr, stating that they are missing and therefore making them useless. Lloyd clarifies that he was not referencing the DLC oracle attestation protocol but rather pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for transaction signatures. There are even channel implementations using them as well as atomic swaps doing this.In an email exchange between AdamISZ and Lloyd Fournier via bitcoin-dev, they discuss the usefulness of single signer adaptors. Fournier argues that if a secret key is held for X and a signature adaptor is created with encryption key Y for message m, any signature on m published reveals the secret on Y to the holder of the secret key for X, making it a useful property in theory and practice. AdamISZ initially struggles to understand this concept but eventually acknowledges his error and admits to having a misconception about adaptors for years. They also discuss the framing of s' = k - t +H(R|P|m)x vs s' = k + H(R+T|P|m)x and a potential variant of the canonical adaptor based swap. Fournier clarifies that he was not referencing the DLC oracle attestation protocol, but rather pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for transaction signatures, making them a pretty useful thing. The conversation ends on a cordial note with cheers exchanged.In an email exchange between AdamISZ and Lloyd Fournier, they discussed the usefulness of single signer adaptors. While Fournier had previously claimed that they were useless as they did not provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret, AdamISZ disagreed. He argued that if he held a secret key for X and created a signature adaptor with some encryption key Y with message m and did not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to him. This property is useful in theory and practice. Fournier was confused by AdamISZ's statement and asked for clarification on what he meant by "any signature on m that is published reveals y." AdamISZ elaborated that if only one adaptor signature is generated on m and no other signatures on m are created, then a signature on m that appears under the key would reveal y to him. Fournier thought that the confusion might be about the DLC construct, which is analogous to single key Schnorr. However, AdamISZ clarified that he was not referencing the DLC oracle attestation protocol but was pointing out that - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Package-Relay-Proposal.xml b/static/bitcoin-dev/May_2023/combined_Package-Relay-Proposal.xml index e4d767fcb0..43248d2532 100644 --- a/static/bitcoin-dev/May_2023/combined_Package-Relay-Proposal.xml +++ b/static/bitcoin-dev/May_2023/combined_Package-Relay-Proposal.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Package Relay Proposal - 2023-08-02T06:32:07.153762+00:00 - - Greg Sanders 2023-05-10 15:42:34+00:00 - - - Tom Trevethan 2023-05-10 15:12:04+00:00 - - - Gloria Zhao 2022-11-01 18:03:22+00:00 - - - Antoine Riard 2022-06-17 20:08:36+00:00 - - - Gloria Zhao 2022-06-14 09:59:23+00:00 - - - Suhas Daftuar 2022-06-08 15:59:03+00:00 - - - Gloria Zhao 2022-06-07 17:44:45+00:00 - - - Gloria Zhao 2022-05-28 01:54:13+00:00 - - - eric at voskuil.org 2022-05-26 02:59:01+00:00 - - - eric at voskuil.org 2022-05-25 20:52:07+00:00 - - - Anthony Towns 2022-05-25 18:55:35+00:00 - - - Eric Voskuil 2022-05-24 23:43:57+00:00 - - - Gloria Zhao 2022-05-24 21:05:35+00:00 - - - Anthony Towns 2022-05-24 19:48:02+00:00 - - - Gloria Zhao 2022-05-24 01:13:43+00:00 - - - Anthony Towns 2022-05-23 21:34:16+00:00 - - - Gloria Zhao 2022-05-18 18:40:58+00:00 - - - Anthony Towns 2022-05-18 00:35:31+00:00 - - - Gloria Zhao 2022-05-17 20:45:42+00:00 - - - Greg Sanders 2022-05-17 17:56:40+00:00 - - - Gloria Zhao 2022-05-17 16:01:04+00:00 - + 2025-09-26T14:33:09.750910+00:00 + python-feedgen + + + [bitcoin-dev] Package Relay Proposal Gloria Zhao + 2022-05-17T16:01:00.000Z + + + Greg Sanders + 2022-05-17T17:56:00.000Z + + + Gloria Zhao + 2022-05-17T20:45:00.000Z + + + Anthony Towns + 2022-05-18T00:35:00.000Z + + + Gloria Zhao + 2022-05-18T18:40:00.000Z + + + Anthony Towns + 2022-05-23T21:34:00.000Z + + + Gloria Zhao + 2022-05-24T01:13:00.000Z + + + Anthony Towns + 2022-05-24T19:48:00.000Z + + + Gloria Zhao + 2022-05-24T21:05:00.000Z + + + Eric Voskuil + 2022-05-24T23:43:00.000Z + + + Anthony Towns + 2022-05-25T18:55:00.000Z + + + eric + 2022-05-25T20:52:00.000Z + + + eric + 2022-05-26T02:59:00.000Z + + + Gloria Zhao + 2022-05-28T01:54:00.000Z + + + Gloria Zhao + 2022-06-07T17:44:00.000Z + + + Suhas Daftuar + 2022-06-08T15:59:00.000Z + + + Gloria Zhao + 2022-06-14T09:59:00.000Z + + + Antoine Riard + 2022-06-17T20:08:00.000Z + + + Gloria Zhao + 2022-11-01T18:03:00.000Z + + + [bitcoin-dev] Package Relay Proposal Tom Trevethan + 2023-05-10T15:12:00.000Z + + + Greg Sanders + 2023-05-10T15:42:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Package Relay Proposal - 2023-08-02T06:32:07.153762+00:00 + 2025-09-26T14:33:09.753172+00:00 - The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids. Different perspectives are presented, highlighting the tradeoffs and considerations involved in implementing package relay in the Bitcoin protocol.A proposal has been made by Bitcoin Core developer Gloria Zhao to implement a 2023-05-10T15:42:34+00:00 + The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids. Different perspectives are presented, highlighting the tradeoffs and considerations involved in implementing package relay in the Bitcoin protocol.A proposal has been made by Bitcoin Core developer Gloria Zhao to implement a - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Proposal-to-Remove-BIP35-P2P-mempool-Message.xml b/static/bitcoin-dev/May_2023/combined_Proposal-to-Remove-BIP35-P2P-mempool-Message.xml index 88affa19b2..00552b7301 100644 --- a/static/bitcoin-dev/May_2023/combined_Proposal-to-Remove-BIP35-P2P-mempool-Message.xml +++ b/static/bitcoin-dev/May_2023/combined_Proposal-to-Remove-BIP35-P2P-mempool-Message.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Proposal to Remove BIP35 P2P 'mempool' Message - 2023-08-02T09:16:00.932771+00:00 - - 0xB10C 2023-05-01 13:24:26+00:00 - - - David A. Harding 2023-04-18 16:57:41+00:00 - - - Will Clark 2023-04-18 06:37:45+00:00 - + 2025-09-26T14:33:07.562929+00:00 + python-feedgen + + + [bitcoin-dev] Proposal to Remove BIP35 P2P 'mempool' Message Will Clark + 2023-04-18T06:37:00.000Z + + + David A. Harding + 2023-04-18T16:57:00.000Z + + + 0xB10C + 2023-05-01T13:24:00.000Z + + - python-feedgen + 2 Combined summary - Proposal to Remove BIP35 P2P 'mempool' Message - 2023-08-02T09:16:00.932771+00:00 + 2025-09-26T14:33:07.563516+00:00 - In response to a query about the BIP35 P2P `mempool` message, it has been revealed that Bitcoin Core only gates processing of mempool messages on NetPermissionFlags::Mempool when bloom filters are disabled. Despite being disabled by default, over 20% of nodes on the network have bloom filters enabled and respond to mempool messages with INV messages. An individual has reportedly been receiving around 20 mempool messages per hour to a well-connected NODE_BLOOM Bitcoin Core node from various user agents such as /BitcoinKit:0.1.0/, /bitcoinj:0.*.*/Bitcoin Wallet:*/, /WalletKit:0.1.0/, and /bread:2.1/. Moreover, the node responds to clients with INVs up to the maximum number of 50k entries and with smaller (bloom) filtered INVs.The conversation can be traced on a GitHub pull request comment [0] and the public key and signature of the commenter are also available as attachments. The `savemempool` RPC can be used to load the mempool directly into a client for trusted users. In the past, lightweight clients loaded a BIP37 filter and requested `mempool` using `getdata`. The node would then only send transactions matching the filter and false positives to the client. This approach reduced the amount of data transferred, which is crucial for lite clients with limited bandwidth or metered connections.During a backlog, the mempool contents in the `savemempool` format are about 300 MB, which is too much to transfer to lite clients. Although BIP37 and BIP35 interfaces are problematic, it's essential to build interfaces that enable people to use third-party wallets with their trusted nodes easily. It's possible to use `getheaders`, BIP157/8, and `getdata(block)` with their nodes to learn about all confirmed transactions affecting their wallet. Lite clients using a trusted node should receive a replacement for BIP35/7 support before those protocols are removed. Support for BIP324 and countersign should also be added to allow an authenticated and encrypted connection from a lite client to a trusted node. An authenticated connection is necessary to be secure, and it should ideally be encrypted.The author proposes the removal of BIP35 P2P `mempool` message, which is considered bad for privacy and relatively inefficient for trusted peers. The original intention of the message was to be publicly callable, but it is now gated behind stricter Net Permissions accessible to trusted peers only. An alternative for serving trusted clients could be using the `savemempool` RPC, although it currently has some shortcomings. Dumping and loading a dumped mempool to sync two trusted nodes or bootstrap one node makes more sense via RPC, but there is an argument to be made that syncing via P2P message would be more convenient.The author has a draft PR open for the removal of the mempool message, and before moving forward, they want to ensure that there are no active use cases or technical opposition to its removal. The author requests input on whether there are any parties who still directly rely on the BIP35 P2P `mempool` message and whether there will be any issues or negative consequences resulting from its removal. A quick search of node implementations shows that `btcd`, `libbitcoin`, and `BitcoinJ` all have BIP35 messages specified, but it's difficult to gauge upstream usage by other projects without outreach like this. The removal of the message would provide a small clean-up to the P2P codebase and bring the usual benefits in terms of maintainability. 2023-05-01T13:24:26+00:00 + In response to a query about the BIP35 P2P `mempool` message, it has been revealed that Bitcoin Core only gates processing of mempool messages on NetPermissionFlags::Mempool when bloom filters are disabled. Despite being disabled by default, over 20% of nodes on the network have bloom filters enabled and respond to mempool messages with INV messages. An individual has reportedly been receiving around 20 mempool messages per hour to a well-connected NODE_BLOOM Bitcoin Core node from various user agents such as /BitcoinKit:0.1.0/, /bitcoinj:0.*.*/Bitcoin Wallet:*/, /WalletKit:0.1.0/, and /bread:2.1/. Moreover, the node responds to clients with INVs up to the maximum number of 50k entries and with smaller (bloom) filtered INVs.The conversation can be traced on a GitHub pull request comment [0] and the public key and signature of the commenter are also available as attachments. The `savemempool` RPC can be used to load the mempool directly into a client for trusted users. In the past, lightweight clients loaded a BIP37 filter and requested `mempool` using `getdata`. The node would then only send transactions matching the filter and false positives to the client. This approach reduced the amount of data transferred, which is crucial for lite clients with limited bandwidth or metered connections.During a backlog, the mempool contents in the `savemempool` format are about 300 MB, which is too much to transfer to lite clients. Although BIP37 and BIP35 interfaces are problematic, it's essential to build interfaces that enable people to use third-party wallets with their trusted nodes easily. It's possible to use `getheaders`, BIP157/8, and `getdata(block)` with their nodes to learn about all confirmed transactions affecting their wallet. Lite clients using a trusted node should receive a replacement for BIP35/7 support before those protocols are removed. Support for BIP324 and countersign should also be added to allow an authenticated and encrypted connection from a lite client to a trusted node. An authenticated connection is necessary to be secure, and it should ideally be encrypted.The author proposes the removal of BIP35 P2P `mempool` message, which is considered bad for privacy and relatively inefficient for trusted peers. The original intention of the message was to be publicly callable, but it is now gated behind stricter Net Permissions accessible to trusted peers only. An alternative for serving trusted clients could be using the `savemempool` RPC, although it currently has some shortcomings. Dumping and loading a dumped mempool to sync two trusted nodes or bootstrap one node makes more sense via RPC, but there is an argument to be made that syncing via P2P message would be more convenient.The author has a draft PR open for the removal of the mempool message, and before moving forward, they want to ensure that there are no active use cases or technical opposition to its removal. The author requests input on whether there are any parties who still directly rely on the BIP35 P2P `mempool` message and whether there will be any issues or negative consequences resulting from its removal. A quick search of node implementations shows that `btcd`, `libbitcoin`, and `BitcoinJ` all have BIP35 messages specified, but it's difficult to gauge upstream usage by other projects without outreach like this. The removal of the message would provide a small clean-up to the P2P codebase and bring the usual benefits in terms of maintainability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Responsible-disclosures-and-Bitcoin-development.xml b/static/bitcoin-dev/May_2023/combined_Responsible-disclosures-and-Bitcoin-development.xml index 7312adfb34..082ac96236 100644 --- a/static/bitcoin-dev/May_2023/combined_Responsible-disclosures-and-Bitcoin-development.xml +++ b/static/bitcoin-dev/May_2023/combined_Responsible-disclosures-and-Bitcoin-development.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Responsible disclosures and Bitcoin development - 2023-08-02T09:26:12.973597+00:00 - - alicexbt 2023-05-23 16:45:58+00:00 - - - Michael Folkson 2023-05-23 16:17:55+00:00 - - - alicexbt 2023-05-22 12:56:13+00:00 - - - Michael Folkson 2023-05-17 12:44:41+00:00 - - - alicexbt 2023-05-16 22:39:53+00:00 - - - Michael Folkson 2023-05-11 19:44:18+00:00 - - - alicexbt 2023-05-09 02:47:24+00:00 - + 2025-09-26T14:32:33.435275+00:00 + python-feedgen + + + [bitcoin-dev] Responsible disclosures and Bitcoin development alicexbt + 2023-05-09T02:47:00.000Z + + + Michael Folkson + 2023-05-11T19:44:00.000Z + + + alicexbt + 2023-05-16T22:39:00.000Z + + + Michael Folkson + 2023-05-17T12:44:00.000Z + + + alicexbt + 2023-05-22T12:56:00.000Z + + + Michael Folkson + 2023-05-23T16:17:00.000Z + + + alicexbt + 2023-05-23T16:45:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Responsible disclosures and Bitcoin development - 2023-08-02T09:26:12.973597+00:00 + 2025-09-26T14:32:33.436283+00:00 - A vulnerability in the Bitcoin Core repository has sparked a debate about the reporting process for vulnerabilities. While some argue that issues not resulting in loss of funds or presenting systemic issues should be publicly collaborated on, others believe that reporting privately is necessary for better practices and to avoid exploitation. The current process involves communication and resolution through a small group of individuals rather than open collaboration between contributors. It is acknowledged that this approach is critically needed for certain issues, such as the 2018 inflation bug. However, it is also recognized that not all bug reports can go through this funnel, and that better documentation and guidance on the reporting process would be beneficial.The email exchange on the Bitcoin-dev mailing list discusses these concerns. One user suggests that the reporting process should be less closed and more open, while another acknowledges room for improvement in the documentation and guidance surrounding the process. They also highlight the trade-offs between wider collaboration and keeping knowledge of the issue within a smaller group. Previous examples of vulnerabilities being exploited on mainnet are referenced, emphasizing the importance of considering the impact of any vulnerability. The issue raised by one user has since been assigned a CVE ID.In response, a developer argues against pushing everything into closed, private channels and points out that the reporting process cannot scale for all bug reports. They agree that opening a public issue was appropriate in this case, as it initially only affected nodes running in debug mode. The developer suggests that instead of complaining, users should suggest what class of bug reports should go through the reporting process and what shouldn't. They stress the delicate trade-offs involved, including understanding and resolving issues faster through wider collaboration versus keeping knowledge restricted. The importance of considering the potential impact of vulnerabilities is reiterated.The email thread also includes discussions about the impact of the vulnerability, with concerns raised about denial of service and stale blocks affecting mining pool revenue. Some users have experienced similar issues without using the debug build for bitcoind, but there has been no decline in the number of listening nodes on bitnodes.io. The thread provides links to examples where the reporting process was critically needed and highlights the security practices followed by Bitcoin developers.Overall, the debate centers around the reporting process for vulnerabilities in Bitcoin Core, with arguments for both public collaboration and private reporting. The importance of considering the impact of vulnerabilities is emphasized, along with the need for better documentation and guidance on the reporting process. The trade-offs between wider collaboration and restricted knowledge are acknowledged, and previous examples of exploited vulnerabilities are referenced. 2023-05-23T16:45:58+00:00 + A vulnerability in the Bitcoin Core repository has sparked a debate about the reporting process for vulnerabilities. While some argue that issues not resulting in loss of funds or presenting systemic issues should be publicly collaborated on, others believe that reporting privately is necessary for better practices and to avoid exploitation. The current process involves communication and resolution through a small group of individuals rather than open collaboration between contributors. It is acknowledged that this approach is critically needed for certain issues, such as the 2018 inflation bug. However, it is also recognized that not all bug reports can go through this funnel, and that better documentation and guidance on the reporting process would be beneficial.The email exchange on the Bitcoin-dev mailing list discusses these concerns. One user suggests that the reporting process should be less closed and more open, while another acknowledges room for improvement in the documentation and guidance surrounding the process. They also highlight the trade-offs between wider collaboration and keeping knowledge of the issue within a smaller group. Previous examples of vulnerabilities being exploited on mainnet are referenced, emphasizing the importance of considering the impact of any vulnerability. The issue raised by one user has since been assigned a CVE ID.In response, a developer argues against pushing everything into closed, private channels and points out that the reporting process cannot scale for all bug reports. They agree that opening a public issue was appropriate in this case, as it initially only affected nodes running in debug mode. The developer suggests that instead of complaining, users should suggest what class of bug reports should go through the reporting process and what shouldn't. They stress the delicate trade-offs involved, including understanding and resolving issues faster through wider collaboration versus keeping knowledge restricted. The importance of considering the potential impact of vulnerabilities is reiterated.The email thread also includes discussions about the impact of the vulnerability, with concerns raised about denial of service and stale blocks affecting mining pool revenue. Some users have experienced similar issues without using the debug build for bitcoind, but there has been no decline in the number of listening nodes on bitnodes.io. The thread provides links to examples where the reporting process was critically needed and highlights the security practices followed by Bitcoin developers.Overall, the debate centers around the reporting process for vulnerabilities in Bitcoin Core, with arguments for both public collaboration and private reporting. The importance of considering the impact of vulnerabilities is emphasized, along with the need for better documentation and guidance on the reporting process. The trade-offs between wider collaboration and restricted knowledge are acknowledged, and previous examples of exploited vulnerabilities are referenced. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Seeking-concept-ACKs-for-transaction-terminology-BIP.xml b/static/bitcoin-dev/May_2023/combined_Seeking-concept-ACKs-for-transaction-terminology-BIP.xml index 74ca2c0aee..d5d368b3fb 100644 --- a/static/bitcoin-dev/May_2023/combined_Seeking-concept-ACKs-for-transaction-terminology-BIP.xml +++ b/static/bitcoin-dev/May_2023/combined_Seeking-concept-ACKs-for-transaction-terminology-BIP.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Seeking concept ACKs for transaction terminology BIP - 2023-08-02T09:03:22.335529+00:00 - - Keagan McClelland 2023-05-10 20:20:53+00:00 - - - josibake 2023-04-21 09:36:08+00:00 - - - Vincenzo Palazzo 2023-04-11 12:27:27+00:00 - - - darosior 2023-04-06 09:03:14+00:00 - - - Andrew Poelstra 2023-04-05 22:05:11+00:00 - - - Murch 2023-04-05 18:54:15+00:00 - + 2025-09-26T14:32:44.115412+00:00 + python-feedgen + + + [bitcoin-dev] Seeking concept ACKs for transaction terminology BIP Murch + 2023-04-05T18:54:00.000Z + + + Andrew Poelstra + 2023-04-05T22:05:00.000Z + + + darosior + 2023-04-06T09:03:00.000Z + + + Vincenzo Palazzo + 2023-04-11T12:27:00.000Z + + + josibake + 2023-04-21T09:36:00.000Z + + + Keagan McClelland + 2023-05-10T20:20:00.000Z + + - python-feedgen + 2 Combined summary - Seeking concept ACKs for transaction terminology BIP - 2023-08-02T09:03:22.335529+00:00 + 2025-09-26T14:32:44.116321+00:00 - In an effort to minimize confusion and establish a shared vocabulary for discussions about transactions, Murch has proposed the creation of a shared terminology document. This proposal comes after Murch noticed that conversations often get sidetracked by the use of competing terms for transaction components. To address this issue, Murch has drafted an informational BIP (Bitcoin Improvement Proposal) that outlines terminology for various components and aspects of transactions.The purpose of the proposal is not to achieve perfect consistency but rather to establish a common vocabulary among participants. Murch acknowledges that there are already contradictory established terms, making it challenging to establish a single set of terms. However, the proposed BIP aims to provide a reference document that can help minimize miscommunication and speed up the process of reaching social consensus on transaction-related issues.Josie, a participant in Bitcoin developer education programs, has also recognized the struggle students face when trying to reconcile different terms used in various resources. To address this issue, Josie suggests having a reference document early in the curriculum to reduce cognitive load and establish a shared terminology. Josie emphasizes the importance of the "synonyms" field, which helps map various resources to a common vocabulary.Murch's draft of the BIP can be found on GitHub, where he has asked for feedback from the community on the proposal's creation. Vincent, one of the participants, expressed his agreement with the proposal, noting that he recently discovered he was using a different term to refer to `scriptPubKey`, which caused confusion.On April 5th, 2023, Murch sent an email to the bitcoin-dev mailing list proposing the creation of an informational BIP that would establish a shared vocabulary for various components and aspects of transactions. Murch highlighted the existence of many competing terms, which can lead to confusion during conversations about transactions. The proposed BIP aims to avoid this confusion by establishing a shared terminology. Murch's draft of the BIP is available on GitHub, and he invites the bitcoin-dev community to review it and provide feedback. Murch acknowledges that some established terms are contradictory, and therefore, the proposal does not aim for perfect consistency. Instead, its primary goal is to establish a shared vocabulary that will facilitate conversations about transactions.Antoine responded to Murch's email, expressing agreement with the proposed BIP. This shows that there is support within the community for establishing a shared vocabulary.Andrew Poelstra, Director of Research at Blockstream, also expressed interest in the proposed BIP, leaving the task of refining the terminology to others. The draft of the proposal can be accessed via the link provided on GitHub.Overall, Murch's proposal for a shared terminology document aims to address the issue of confusion caused by competing terms in discussions about transactions. By establishing a common vocabulary, miscommunication can be minimized, and the process of reaching social consensus on transaction-related matters can be expedited. 2023-05-10T20:20:53+00:00 + In an effort to minimize confusion and establish a shared vocabulary for discussions about transactions, Murch has proposed the creation of a shared terminology document. This proposal comes after Murch noticed that conversations often get sidetracked by the use of competing terms for transaction components. To address this issue, Murch has drafted an informational BIP (Bitcoin Improvement Proposal) that outlines terminology for various components and aspects of transactions.The purpose of the proposal is not to achieve perfect consistency but rather to establish a common vocabulary among participants. Murch acknowledges that there are already contradictory established terms, making it challenging to establish a single set of terms. However, the proposed BIP aims to provide a reference document that can help minimize miscommunication and speed up the process of reaching social consensus on transaction-related issues.Josie, a participant in Bitcoin developer education programs, has also recognized the struggle students face when trying to reconcile different terms used in various resources. To address this issue, Josie suggests having a reference document early in the curriculum to reduce cognitive load and establish a shared terminology. Josie emphasizes the importance of the "synonyms" field, which helps map various resources to a common vocabulary.Murch's draft of the BIP can be found on GitHub, where he has asked for feedback from the community on the proposal's creation. Vincent, one of the participants, expressed his agreement with the proposal, noting that he recently discovered he was using a different term to refer to `scriptPubKey`, which caused confusion.On April 5th, 2023, Murch sent an email to the bitcoin-dev mailing list proposing the creation of an informational BIP that would establish a shared vocabulary for various components and aspects of transactions. Murch highlighted the existence of many competing terms, which can lead to confusion during conversations about transactions. The proposed BIP aims to avoid this confusion by establishing a shared terminology. Murch's draft of the BIP is available on GitHub, and he invites the bitcoin-dev community to review it and provide feedback. Murch acknowledges that some established terms are contradictory, and therefore, the proposal does not aim for perfect consistency. Instead, its primary goal is to establish a shared vocabulary that will facilitate conversations about transactions.Antoine responded to Murch's email, expressing agreement with the proposed BIP. This shows that there is support within the community for establishing a shared vocabulary.Andrew Poelstra, Director of Research at Blockstream, also expressed interest in the proposed BIP, leaving the task of refining the terminology to others. The draft of the proposal can be accessed via the link provided on GitHub.Overall, Murch's proposal for a shared terminology document aims to address the issue of confusion caused by competing terms in discussions about transactions. By establishing a common vocabulary, miscommunication can be minimized, and the process of reaching social consensus on transaction-related matters can be expedited. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Vaults-in-the-MATT-framework.xml b/static/bitcoin-dev/May_2023/combined_Vaults-in-the-MATT-framework.xml index adf165db4c..25ac3f3bd5 100644 --- a/static/bitcoin-dev/May_2023/combined_Vaults-in-the-MATT-framework.xml +++ b/static/bitcoin-dev/May_2023/combined_Vaults-in-the-MATT-framework.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Vaults in the MATT framework - 2023-08-02T09:20:10.117249+00:00 - - Johan Torås Halseth 2023-06-02 13:25:39+00:00 - - - Salvatore Ingala 2023-05-02 08:21:01+00:00 - - - Michael Folkson 2023-05-01 14:18:29+00:00 - - - Salvatore Ingala 2023-04-24 19:37:20+00:00 - + 2025-09-26T14:32:42.002223+00:00 + python-feedgen + + + [bitcoin-dev] Vaults in the MATT framework Salvatore Ingala + 2023-04-24T19:37:00.000Z + + + Michael Folkson + 2023-05-01T14:18:00.000Z + + + Salvatore Ingala + 2023-05-02T08:21:00.000Z + + + Johan Torås Halseth + 2023-06-02T13:25:00.000Z + + - python-feedgen + 2 Combined summary - Vaults in the MATT framework - 2023-08-02T09:20:10.117249+00:00 + 2025-09-26T14:32:42.002892+00:00 - Bitcoin developer Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes two new opcodes (OP_CHECKINPUTCONTRACTVERIFY and OP_CHECKOUTPUTCONTRACTVERIFY) that enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data within it. These opcodes enable general smart contracts and fraud proofs. The proposal also discusses Simplicity, a proposal to replace Script with a better language, but notes that it is separate from the discussion on what features should be included in the language.Ingala's proposal for new opcodes allows for the creation and verification of covenant-style contracts. The opcodes can be used to embed data into P2TR output scripts and verify that the correct data is present in subsequent transactions. However, the author suggests adding an opcode like OP_SHA256CAT to allow the data embedding to commit to multiple pieces of data. There is also consideration for extending OP_CHECKOUTPUTCONTRACTVERIFY to apply for arbitrary inputs, allowing for more complex cross-input semantics.The post describes a specific example of a vault using the proposed opcodes. A vault is modeled as a simple state machine with two states: the initial vault UTXOs and the utxo produced by the trigger transaction during unvaulting. The post explains how these opcodes could be used in the context of a vault, which controls the behavior of coins. It also discusses preserving amount in covenant-style contracts, including approaches such as direct introspection on output amounts and deferred checks.The structure of the P2TR output scripts for both the vault and unvaulting state are described. The proposed vault implementation differs from OP_VAULT in that it does not support adding an additional output sent back to the same vault. The author argues that separating the ctv-hash from the scripts in the taptree makes it easier to program state machines that control the behavior of coins.Overall, the proposal presents new opcodes that could enable more complex covenant-style contracts on Bitcoin. The required engineering for a soft-fork is relatively straightforward if the desired features are implemented. However, the decision to implement these features should consider potential risks to Bitcoin caused by their effect on miners' incentives. Comments and feedback on the proposal are welcome from the Bitcoin community.Another aspect of Ingala's proposal involves P2TR-based vaults, which provide an added layer of protection for storing Bitcoin securely. These vaults allow users to specify spending conditions that must be met before funds can be withdrawn. The proposal includes parameters for the vault contract and describes the structure of the vault state [V] and unvaulting state [U]. It also discusses how the proposed opcodes can be used to create vaults comparable to those built with OP_VAULT.Ingala's proposal for smart contracts in Bitcoin has two core opcodes that can be used to create vaults comparable to those built with OP_VAULT. These opcodes enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data in the output. However, further implementation is required since the opcodes only operate on scriptPubkey and not on the amounts.In summary, Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes new opcodes to enhance Script and enable more complex covenant-style contracts. The proposal discusses the use of these opcodes in creating vaults and preserving amounts in covenant-style contracts. The structure of the P2TR output scripts for the vault and unvaulting state is described, highlighting the differences from OP_VAULT. The proposal aims to make it easier to program state machines that control the behavior of coins. Feedback from the Bitcoin community is welcomed on the proposal. 2023-06-02T13:25:39+00:00 + Bitcoin developer Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes two new opcodes (OP_CHECKINPUTCONTRACTVERIFY and OP_CHECKOUTPUTCONTRACTVERIFY) that enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data within it. These opcodes enable general smart contracts and fraud proofs. The proposal also discusses Simplicity, a proposal to replace Script with a better language, but notes that it is separate from the discussion on what features should be included in the language.Ingala's proposal for new opcodes allows for the creation and verification of covenant-style contracts. The opcodes can be used to embed data into P2TR output scripts and verify that the correct data is present in subsequent transactions. However, the author suggests adding an opcode like OP_SHA256CAT to allow the data embedding to commit to multiple pieces of data. There is also consideration for extending OP_CHECKOUTPUTCONTRACTVERIFY to apply for arbitrary inputs, allowing for more complex cross-input semantics.The post describes a specific example of a vault using the proposed opcodes. A vault is modeled as a simple state machine with two states: the initial vault UTXOs and the utxo produced by the trigger transaction during unvaulting. The post explains how these opcodes could be used in the context of a vault, which controls the behavior of coins. It also discusses preserving amount in covenant-style contracts, including approaches such as direct introspection on output amounts and deferred checks.The structure of the P2TR output scripts for both the vault and unvaulting state are described. The proposed vault implementation differs from OP_VAULT in that it does not support adding an additional output sent back to the same vault. The author argues that separating the ctv-hash from the scripts in the taptree makes it easier to program state machines that control the behavior of coins.Overall, the proposal presents new opcodes that could enable more complex covenant-style contracts on Bitcoin. The required engineering for a soft-fork is relatively straightforward if the desired features are implemented. However, the decision to implement these features should consider potential risks to Bitcoin caused by their effect on miners' incentives. Comments and feedback on the proposal are welcome from the Bitcoin community.Another aspect of Ingala's proposal involves P2TR-based vaults, which provide an added layer of protection for storing Bitcoin securely. These vaults allow users to specify spending conditions that must be met before funds can be withdrawn. The proposal includes parameters for the vault contract and describes the structure of the vault state [V] and unvaulting state [U]. It also discusses how the proposed opcodes can be used to create vaults comparable to those built with OP_VAULT.Ingala's proposal for smart contracts in Bitcoin has two core opcodes that can be used to create vaults comparable to those built with OP_VAULT. These opcodes enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data in the output. However, further implementation is required since the opcodes only operate on scriptPubkey and not on the amounts.In summary, Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin, which includes new opcodes to enhance Script and enable more complex covenant-style contracts. The proposal discusses the use of these opcodes in creating vaults and preserving amounts in covenant-style contracts. The structure of the P2TR output scripts for the vault and unvaulting state is described, highlighting the differences from OP_VAULT. The proposal aims to make it easier to program state machines that control the behavior of coins. Feedback from the Bitcoin community is welcomed on the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_Witness-script-validation-to-reject-arbitrary-data.xml b/static/bitcoin-dev/May_2023/combined_Witness-script-validation-to-reject-arbitrary-data.xml index 2f63f5b0bb..52a79799bd 100644 --- a/static/bitcoin-dev/May_2023/combined_Witness-script-validation-to-reject-arbitrary-data.xml +++ b/static/bitcoin-dev/May_2023/combined_Witness-script-validation-to-reject-arbitrary-data.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Witness script validation to reject arbitrary data - 2023-08-02T09:25:50.032298+00:00 - - Aymeric Vitte 2023-05-09 17:45:11+00:00 - - - Moth 2023-05-09 12:20:20+00:00 - - - Peter Todd 2023-05-08 23:55:57+00:00 - - - Christopher Allen 2023-05-08 21:43:06+00:00 - - - angus 2023-05-08 21:33:24+00:00 - - - Moth 2023-05-08 20:16:41+00:00 - + 2025-09-26T14:32:35.550934+00:00 + python-feedgen + + + [bitcoin-dev] Witness script validation to reject arbitrary data Moth + 2023-05-08T20:16:00.000Z + + + angus + 2023-05-08T21:33:00.000Z + + + Christopher Allen + 2023-05-08T21:43:00.000Z + + + Peter Todd + 2023-05-08T23:55:00.000Z + + + Moth + 2023-05-09T12:20:00.000Z + + + Aymeric Vitte + 2023-05-09T17:45:00.000Z + + - python-feedgen + 2 Combined summary - Witness script validation to reject arbitrary data - 2023-08-02T09:25:50.032298+00:00 + 2025-09-26T14:32:35.551816+00:00 - In a recent discussion on the Bitcoin-dev mailing list, the topic of raising the limit on OP_RETURN was brought up. However, it was concluded that imposing limits may not be necessary as people will find ways to work around them and fees will regulate the use of OP_RETURN. The issue of controlling the value of stored data was also raised, with suggestions to store references to data using hashes and/or signatures instead of storing it directly. It was noted that this cannot currently be done with OP_RETURN. The discussion also touched on the issue of freeriders and how to prevent them from impacting the network as a whole and increasing decentralization among miners. Finally, the idea that the market will self-regulate when ordinal meme stuff/BRC20 has zero value was mentioned.Another thread in the Bitcoin-dev email chain focused on concerns about inscriptions being inserted between specific flags. It was explained that this is simply an artificial limitation of the current inscription protocol and there are numerous ways to embed arbitrary data in Bitcoin transactions. The flood of BRC-20 inscriptions happening currently is considered small and could have used other data encoding techniques or OP_RETURN outputs. Blocking these types of transactions is seen as futile. The purpose of this flood of inscriptions is to create a new set of assets via an auction, which does not require any data to be embedded in the chain at all. Blocking such transactions is deemed hopeless by some individuals.The ongoing discussion on the bitcoin-dev mailing list revolves around the limitation of the inscription protocol, which only allows data to be inserted between OP_FALSE and OP_IF flags. One suggestion is to implement a validation check to reject witness scripts that have arbitrary data between these flags, thereby allowing rejection of inscriptions while still benefiting from taproot. However, others argue that blocking such use cases is hopeless as there are countless ways to embed arbitrary data in Bitcoin transactions. They point out that the current flood of inscription transactions is small and could have used alternative data encoding techniques. Additionally, the purpose of this flood, which involves the creation of a new set of assets through an auction, does not require any data to be embedded in the chain. It could have been implemented with normal transactions that are indistinguishable from others.In a message sent on May 8, 2023, a user named Moth proposed the idea of a validation check to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags. The goal is to prevent the network from being overloaded with transactions focused solely on ordinals and BRC-20 tokens while still benefiting from taproot. However, it is noted that there are many other ways to "inscribe" data into the blockchain, making such a validation check ineffective. Some individuals had hoped for a slightly larger OP_RETURN to store a tagged root of a hash-tree for various use cases. These use cases include open timestamps, ION, and Gordian Envelope, which consolidates large sets of proofs into a hash used for L2 proofs-of-inclusion. Concerns have been raised about the inscription technique freeloading on the network mempool, the validation network, and volunteer unpruned full nodes. This has led to increased costs for hosting and maintaining free privacy services. While solutions are sought, it remains uncertain whether raising the limit on OP_RETURN would be a viable solution.There is also a concern that banning the storage of arbitrary/non-functional data could lead to people abusing useful data, causing more harm than good. An example of this is Stamps, which stores Inscription-like data in fake outputs, consuming UTXO set storage. The issue of the UTXO set getting too big is seen as a more significant problem than the chain size increasing. It is unclear whether lifting the size limit for witness scripts as part of Taproot was an oversight. If Taproot is meant to enable large useful scripts, it becomes difficult to define "not useful" in a way that filters out unwanted data. It is suggested that incentivizing people to find workarounds by attempting to censor their current actions may lead to even worse outcomes. The fear is that banning things will only push people to find alternative ways to bypass the ban.One suggestion put forward is to have a validation check to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags. This would prevent the network from being overloaded with transactions focused solely on ordinals and BRC-20 tokens while still benefiting from taproot. However, the author questions whether this validation check is a good idea and whether it was an oversight to allow arbitrary data between these flags when the size limit for witness scripts was lifted as part of taproot. It is important to note that OP_RETURN can currently store arbitrary data up to 80kb. 2023-05-09T17:45:11+00:00 + In a recent discussion on the Bitcoin-dev mailing list, the topic of raising the limit on OP_RETURN was brought up. However, it was concluded that imposing limits may not be necessary as people will find ways to work around them and fees will regulate the use of OP_RETURN. The issue of controlling the value of stored data was also raised, with suggestions to store references to data using hashes and/or signatures instead of storing it directly. It was noted that this cannot currently be done with OP_RETURN. The discussion also touched on the issue of freeriders and how to prevent them from impacting the network as a whole and increasing decentralization among miners. Finally, the idea that the market will self-regulate when ordinal meme stuff/BRC20 has zero value was mentioned.Another thread in the Bitcoin-dev email chain focused on concerns about inscriptions being inserted between specific flags. It was explained that this is simply an artificial limitation of the current inscription protocol and there are numerous ways to embed arbitrary data in Bitcoin transactions. The flood of BRC-20 inscriptions happening currently is considered small and could have used other data encoding techniques or OP_RETURN outputs. Blocking these types of transactions is seen as futile. The purpose of this flood of inscriptions is to create a new set of assets via an auction, which does not require any data to be embedded in the chain at all. Blocking such transactions is deemed hopeless by some individuals.The ongoing discussion on the bitcoin-dev mailing list revolves around the limitation of the inscription protocol, which only allows data to be inserted between OP_FALSE and OP_IF flags. One suggestion is to implement a validation check to reject witness scripts that have arbitrary data between these flags, thereby allowing rejection of inscriptions while still benefiting from taproot. However, others argue that blocking such use cases is hopeless as there are countless ways to embed arbitrary data in Bitcoin transactions. They point out that the current flood of inscription transactions is small and could have used alternative data encoding techniques. Additionally, the purpose of this flood, which involves the creation of a new set of assets through an auction, does not require any data to be embedded in the chain. It could have been implemented with normal transactions that are indistinguishable from others.In a message sent on May 8, 2023, a user named Moth proposed the idea of a validation check to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags. The goal is to prevent the network from being overloaded with transactions focused solely on ordinals and BRC-20 tokens while still benefiting from taproot. However, it is noted that there are many other ways to "inscribe" data into the blockchain, making such a validation check ineffective. Some individuals had hoped for a slightly larger OP_RETURN to store a tagged root of a hash-tree for various use cases. These use cases include open timestamps, ION, and Gordian Envelope, which consolidates large sets of proofs into a hash used for L2 proofs-of-inclusion. Concerns have been raised about the inscription technique freeloading on the network mempool, the validation network, and volunteer unpruned full nodes. This has led to increased costs for hosting and maintaining free privacy services. While solutions are sought, it remains uncertain whether raising the limit on OP_RETURN would be a viable solution.There is also a concern that banning the storage of arbitrary/non-functional data could lead to people abusing useful data, causing more harm than good. An example of this is Stamps, which stores Inscription-like data in fake outputs, consuming UTXO set storage. The issue of the UTXO set getting too big is seen as a more significant problem than the chain size increasing. It is unclear whether lifting the size limit for witness scripts as part of Taproot was an oversight. If Taproot is meant to enable large useful scripts, it becomes difficult to define "not useful" in a way that filters out unwanted data. It is suggested that incentivizing people to find workarounds by attempting to censor their current actions may lead to even worse outcomes. The fear is that banning things will only push people to find alternative ways to bypass the ban.One suggestion put forward is to have a validation check to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags. This would prevent the network from being overloaded with transactions focused solely on ordinals and BRC-20 tokens while still benefiting from taproot. However, the author questions whether this validation check is a good idea and whether it was an oversight to allow arbitrary data between these flags when the size limit for witness scripts was lifted as part of taproot. It is important to note that OP_RETURN can currently store arbitrary data up to 80kb. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml b/static/bitcoin-dev/May_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml index 12830b6170..2f48186b6d 100644 --- a/static/bitcoin-dev/May_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml +++ b/static/bitcoin-dev/May_2023/combined_ZeroSync-Introducing-Validity-Proofs-to-Bitcoin.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - ZeroSync: Introducing Validity Proofs to Bitcoin - 2023-08-29T02:15:23.286604+00:00 - - blk0 2023-08-28 07:49:02+00:00 - - - Erik Aronesty 2023-06-05 18:59:58+00:00 - - - Peter Todd 2023-06-05 18:47:03+00:00 - - - Robin Linus 2023-05-12 16:03:06+00:00 - - - Weiji Guo 2023-05-12 15:32:55+00:00 - - - Robin Linus 2023-05-12 12:12:03+00:00 - + 2025-09-26T14:32:59.044706+00:00 + python-feedgen + + + [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin Robin Linus + 2023-05-12T12:12:00.000Z + + + Weiji Guo + 2023-05-12T15:32:00.000Z + + + Robin Linus + 2023-05-12T16:03:00.000Z + + + Peter Todd + 2023-06-05T18:47:00.000Z + + + Erik Aronesty + 2023-06-05T18:59:00.000Z + + + blk0 + 2023-08-28T07:49:00.000Z + + - python-feedgen + 2 Combined summary - ZeroSync: Introducing Validity Proofs to Bitcoin - 2023-08-29T02:15:23.286689+00:00 + 2025-09-26T14:32:59.045511+00:00 - Peter Todd shared information about a general purpose zkVM implementation for the RISC-V instruction set called RiscZero. He mentioned that since Bitcoin Core can be compiled for RISC-V, and RiscZero can prove execution traces of a RISC-V VM, the argument against using RISC-V for Bitcoin no longer applies.A research paper titled "ZeroSync: Introducing Validity Proofs to Bitcoin" has been published, introducing ZeroSync as a proof system that addresses scalability challenges with SNARKs. The system compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync enables diverse applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, is introduced, significantly improving privacy and throughput of token transactions. However, there are concerns about creating an alternative implementation of the Bitcoin protocol, which may lead to potential forks. Furthermore, if the technology advances to real-time proof-generation, widespread adoption by Bitcoin miners could jeopardize Bitcoin's decentralization.In a conversation between Weiji and Robin, they discussed plans to implement a SNARK verifier on Bitcoin's base layer. Robin explained his long-term plan and mentioned experimenting with Simplicity on the Liquid sidechain. Weiji shared his proposal for a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs through a soft fork. Although Robin acknowledged the proposal, he highlighted the challenge of establishing consensus over specific op_snark_verify opcodes due to the variety of competing proof systems with different trade-offs. While STARKs are scalable and suitable for chain state proofs, Robin prefers other proof systems like Plonky2 for on-chain verification due to smaller proof sizes. Robin also mentioned the possibility of using any verifier to wrap other proofs. He invited Weiji to join their Telegram group to discuss SNARKs on Bitcoin.Weiji emailed Robin to inquire about his plans for implementing a SNARK verifier on Bitcoin's base layer. Weiji had previously proposed the opcode OP_ZKP for verifying zkp proofs through a soft fork. In response, Robin shared his research on ZeroSync, a pioneering proof system that addresses Bitcoin's scalability challenges with SNARKs. ZeroSync compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various applications. The implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync also introduces zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, improving privacy and transaction throughput. The groundbreaking compression capabilities of SNARKs have revolutionized cryptocurrency design, and ZeroSync leads their application to Bitcoin. The full paper can be found at https://zerosync.org/zerosync.pdf. Robin welcomes comments and questions from the bitcoin dev community regarding the paper.ZeroSync, the first-ever proof system for Bitcoin, has been introduced to address scalability challenges using SNARKs. It compresses the entire Bitcoin blockchain into a compact proof of validity, allowing instant verification and unlocking innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. These proofs require no consensus changes, which is crucial for implementing forks in Bitcoin. ZeroSync enables various applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, significantly improves privacy and transaction throughput. With the combination of future Bitcoin features like Simplicity, zkCoins enables private and more scalable BTC transactions. The paper on ZeroSync can be found at https://zerosync.org/zerosync.pdf. Robin invites the bitcoin dev community to provide comments and ask questions about the paper. 2023-08-28T07:49:02+00:00 + Peter Todd shared information about a general purpose zkVM implementation for the RISC-V instruction set called RiscZero. He mentioned that since Bitcoin Core can be compiled for RISC-V, and RiscZero can prove execution traces of a RISC-V VM, the argument against using RISC-V for Bitcoin no longer applies.A research paper titled "ZeroSync: Introducing Validity Proofs to Bitcoin" has been published, introducing ZeroSync as a proof system that addresses scalability challenges with SNARKs. The system compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync enables diverse applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, is introduced, significantly improving privacy and throughput of token transactions. However, there are concerns about creating an alternative implementation of the Bitcoin protocol, which may lead to potential forks. Furthermore, if the technology advances to real-time proof-generation, widespread adoption by Bitcoin miners could jeopardize Bitcoin's decentralization.In a conversation between Weiji and Robin, they discussed plans to implement a SNARK verifier on Bitcoin's base layer. Robin explained his long-term plan and mentioned experimenting with Simplicity on the Liquid sidechain. Weiji shared his proposal for a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs through a soft fork. Although Robin acknowledged the proposal, he highlighted the challenge of establishing consensus over specific op_snark_verify opcodes due to the variety of competing proof systems with different trade-offs. While STARKs are scalable and suitable for chain state proofs, Robin prefers other proof systems like Plonky2 for on-chain verification due to smaller proof sizes. Robin also mentioned the possibility of using any verifier to wrap other proofs. He invited Weiji to join their Telegram group to discuss SNARKs on Bitcoin.Weiji emailed Robin to inquire about his plans for implementing a SNARK verifier on Bitcoin's base layer. Weiji had previously proposed the opcode OP_ZKP for verifying zkp proofs through a soft fork. In response, Robin shared his research on ZeroSync, a pioneering proof system that addresses Bitcoin's scalability challenges with SNARKs. ZeroSync compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various applications. The implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. This approach requires no consensus changes, making it crucial for implementing forks in Bitcoin. ZeroSync also introduces zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, improving privacy and transaction throughput. The groundbreaking compression capabilities of SNARKs have revolutionized cryptocurrency design, and ZeroSync leads their application to Bitcoin. The full paper can be found at https://zerosync.org/zerosync.pdf. Robin welcomes comments and questions from the bitcoin dev community regarding the paper.ZeroSync, the first-ever proof system for Bitcoin, has been introduced to address scalability challenges using SNARKs. It compresses the entire Bitcoin blockchain into a compact proof of validity, allowing instant verification and unlocking innovative applications. The prototype implementation of a chain state proof utilizes the Cairo language, Utreexo, and recursive STARKs. These proofs require no consensus changes, which is crucial for implementing forks in Bitcoin. ZeroSync enables various applications such as quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Additionally, zkCoins, a client-side validation protocol combined with zero-knowledge SNARKs, significantly improves privacy and transaction throughput. With the combination of future Bitcoin features like Simplicity, zkCoins enables private and more scalable BTC transactions. The paper on ZeroSync can be found at https://zerosync.org/zerosync.pdf. Robin invites the bitcoin dev community to provide comments and ask questions about the paper. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_proposal-new-opcode-OP-ZKP-to-enable-ZKP-based-spending-authorization.xml b/static/bitcoin-dev/May_2023/combined_proposal-new-opcode-OP-ZKP-to-enable-ZKP-based-spending-authorization.xml index d90d81824e..7cef478748 100644 --- a/static/bitcoin-dev/May_2023/combined_proposal-new-opcode-OP-ZKP-to-enable-ZKP-based-spending-authorization.xml +++ b/static/bitcoin-dev/May_2023/combined_proposal-new-opcode-OP-ZKP-to-enable-ZKP-based-spending-authorization.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - proposal: new opcode OP_ZKP to enable ZKP-based spending authorization - 2023-08-02T09:21:30.577946+00:00 - - ZmnSCPxj 2023-05-06 02:51:33+00:00 - - - Weiji Guo 2023-05-05 23:06:51+00:00 - - - ZmnSCPxj 2023-05-04 17:13:09+00:00 - - - Weiji Guo 2023-05-04 15:31:22+00:00 - - - ZmnSCPxj 2023-05-02 15:01:01+00:00 - - - Weiji Guo 2023-05-01 12:46:30+00:00 - - - ZmnSCPxj 2023-04-30 02:15:50+00:00 - - - Weiji Guo 2023-04-28 08:29:10+00:00 - + 2025-09-26T14:32:37.664407+00:00 + python-feedgen + + + [bitcoin-dev] proposal: new opcode OP_ZKP to enable ZKP-based spending authorization Weiji Guo + 2023-04-28T08:29:00.000Z + + + ZmnSCPxj + 2023-04-30T02:15:00.000Z + + + Weiji Guo + 2023-05-01T12:46:00.000Z + + + ZmnSCPxj + 2023-05-02T15:01:00.000Z + + + Weiji Guo + 2023-05-04T15:31:00.000Z + + + ZmnSCPxj + 2023-05-04T17:13:00.000Z + + + Weiji Guo + 2023-05-05T23:06:00.000Z + + + ZmnSCPxj + 2023-05-06T02:51:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - proposal: new opcode OP_ZKP to enable ZKP-based spending authorization - 2023-08-02T09:21:30.578945+00:00 + 2025-09-26T14:32:37.665518+00:00 - The discussion between Weiji and ZmnSCPxj revolves around the possibility of an attack on the fullnode mempool network. The attack involves flooding the network with non-aggregated transactions and confirming a single aggregated transaction with a lower feerate in cooperation with a miner. However, ZmnSCPxj argues that this attack is not feasible due to the high cost and the need for a separate, paid aggregator outside the mempool to prevent overload on the free mempool service.To prevent the attack on non-aggregated transactions, it is suggested that transactions should be made non-aggregatable with other transactions in the mempool. Aggregation should be arranged before the blockchain-level transaction hits the mempool. Signature aggregation within a single blockchain-level transaction is allowed, but not across transactions. Similarly, cross-input ZKP aggregation is acceptable, but not cross-transaction ZKP aggregation. It is recommended to disallow ZKP aggregation once a transaction could potentially hit the mempool and require paid services for aggregation outside of the unpaid, free mempool.Weiji proposes the use of ZKPs in Bitcoin transactions and suggests that specialized computing power vendors could optimize ZKP computations. Groth16 verification can be fast enough to handle thousands of OP_ZKP transactions even on a common full node. These transactions can be put into the mempool and open to aggregation by vendors. However, it is cautioned against treating these transactions with special rules as there is no guarantee that certain OP_ZKP transactions will be aggregated or recursively verified. The cost for standalone OP_ZKP transactions might be higher, incentivizing vendors to develop aggregation/recursive verification services.The discussion also addresses the issue of verification keys exceeding the maximum script element size. It is suggested to store verification keys in configurations and only use their hash in the `scriptPubKey`. Weight units for propagation of verification keys should be adjusted similarly to `scriptPubKey`s and amounts in block data. If verification keys are permanent, they should be weighted heavier than `scriptPubKey`s and amounts. If ZKP witnesses consume more resources, their weighting should be higher as well.The proposal of a new opcode, OP_ZKP, aims to enable zero-knowledge based spending authorization in Bitcoin. This would make the Bitcoin script Turing complete and enable various applications. Security concerns, system limitations, scalability, ZKP schemes, curve choices, potential uses, and ecology implications are discussed in the proposal. Proof aggregation and recursive verification are suggested for scalability, and Groth16-BN254 is proposed as an initial choice for ZKP schemes and curve choices.The potential impact of ZKPs on smart contracts, computation power vendors, and wallet applications is also explored. Service providers could work with miners to optimize transaction generation and propose bundles of transactions to be included in blocks. Challenges include maintaining off-network UTXO entries with high security and figuring out ways for smart contracts to call each other. The heavy-duty computation task of generating proof to authorize spending is addressed, suggesting that if no secret is involved, a wallet is not needed, and the ZKP proof could serve as proof of something happening or existing.Further discussion among developers and the community is required before any BIP can be requested. The article provides relevant links to support the ideas presented. 2023-05-06T02:51:33+00:00 + The discussion between Weiji and ZmnSCPxj revolves around the possibility of an attack on the fullnode mempool network. The attack involves flooding the network with non-aggregated transactions and confirming a single aggregated transaction with a lower feerate in cooperation with a miner. However, ZmnSCPxj argues that this attack is not feasible due to the high cost and the need for a separate, paid aggregator outside the mempool to prevent overload on the free mempool service.To prevent the attack on non-aggregated transactions, it is suggested that transactions should be made non-aggregatable with other transactions in the mempool. Aggregation should be arranged before the blockchain-level transaction hits the mempool. Signature aggregation within a single blockchain-level transaction is allowed, but not across transactions. Similarly, cross-input ZKP aggregation is acceptable, but not cross-transaction ZKP aggregation. It is recommended to disallow ZKP aggregation once a transaction could potentially hit the mempool and require paid services for aggregation outside of the unpaid, free mempool.Weiji proposes the use of ZKPs in Bitcoin transactions and suggests that specialized computing power vendors could optimize ZKP computations. Groth16 verification can be fast enough to handle thousands of OP_ZKP transactions even on a common full node. These transactions can be put into the mempool and open to aggregation by vendors. However, it is cautioned against treating these transactions with special rules as there is no guarantee that certain OP_ZKP transactions will be aggregated or recursively verified. The cost for standalone OP_ZKP transactions might be higher, incentivizing vendors to develop aggregation/recursive verification services.The discussion also addresses the issue of verification keys exceeding the maximum script element size. It is suggested to store verification keys in configurations and only use their hash in the `scriptPubKey`. Weight units for propagation of verification keys should be adjusted similarly to `scriptPubKey`s and amounts in block data. If verification keys are permanent, they should be weighted heavier than `scriptPubKey`s and amounts. If ZKP witnesses consume more resources, their weighting should be higher as well.The proposal of a new opcode, OP_ZKP, aims to enable zero-knowledge based spending authorization in Bitcoin. This would make the Bitcoin script Turing complete and enable various applications. Security concerns, system limitations, scalability, ZKP schemes, curve choices, potential uses, and ecology implications are discussed in the proposal. Proof aggregation and recursive verification are suggested for scalability, and Groth16-BN254 is proposed as an initial choice for ZKP schemes and curve choices.The potential impact of ZKPs on smart contracts, computation power vendors, and wallet applications is also explored. Service providers could work with miners to optimize transaction generation and propose bundles of transactions to be included in blocks. Challenges include maintaining off-network UTXO entries with high security and figuring out ways for smart contracts to call each other. The heavy-duty computation task of generating proof to authorize spending is addressed, suggesting that if no secret is involved, a wallet is not needed, and the ZKP proof could serve as proof of something happening or existing.Further discussion among developers and the community is required before any BIP can be requested. The article provides relevant links to support the ideas presented. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2023/combined_tx-max-fee.xml b/static/bitcoin-dev/May_2023/combined_tx-max-fee.xml index d98bf079a3..992a5acb47 100644 --- a/static/bitcoin-dev/May_2023/combined_tx-max-fee.xml +++ b/static/bitcoin-dev/May_2023/combined_tx-max-fee.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - tx max fee - 2023-08-02T09:25:11.308357+00:00 + 2025-09-26T14:33:05.451790+00:00 + python-feedgen Tom Harding 2023-05-12 00:06:51+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - tx max fee - 2023-08-02T09:25:11.308357+00:00 + 2025-09-26T14:33:05.451950+00:00 - On the bitcoin-dev mailing list, a user named vjudeu proposed a new method of replacing transactions with multiple smaller transactions. The proposal suggests that transactions paying "fee > sum" can be replaced by N transactions paying "fee < sum". This would allow users to split up large transactions into smaller ones, potentially saving on fees.The discussion sparked among members of the bitcoin development community, with some expressing concern about the potential impact on the network's mempool and block size. Others pointed out that this approach could improve fee estimation for users and reduce the risk of overpaying for transactions.The conversation also revolves around the use case of paying more fees than outputs to incentivize honest mining during state-level censorship attacks. It is suggested that instead of changing the "max fee" rule, a better solution would be to introduce op_ctv, which allows many users to pool fees and share a single utxo.Furthermore, it is explained that even if the "max fee" rule were changed, it could still be avoided by splitting the transaction into multiple transactions, each paying one satoshi per virtual byte. Maintaining balances and using change addresses would not be a deterrent as the transactions could be prepared upfront as part of the protocol and released all at once. This can be achieved through HD wallets, which only require storing a single key and generating addresses as needed.The proposal raises interesting questions about the tradeoffs between transaction size, fees, and network congestion. It remains to be seen whether this idea will be implemented or how it might affect the broader bitcoin ecosystem. However, it is clear that innovation and experimentation are still alive and well in the world of cryptocurrency development.Overall, the discussion explores the possibility of changing the "max fee" rule to output amounts in Bitcoin transactions. While some argue that it could help prevent spam and denial-of-service attacks, others raise concerns about the potential impact on fees, mempool, and block size. The proposal also touches on alternative solutions such as op_ctv and the use of multiple smaller transactions with lower fees. The conversation showcases the ongoing debate and exploration of new ideas within the bitcoin-dev community. 2023-05-12T00:06:51+00:00 + On the bitcoin-dev mailing list, a user named vjudeu proposed a new method of replacing transactions with multiple smaller transactions. The proposal suggests that transactions paying "fee > sum" can be replaced by N transactions paying "fee < sum". This would allow users to split up large transactions into smaller ones, potentially saving on fees.The discussion sparked among members of the bitcoin development community, with some expressing concern about the potential impact on the network's mempool and block size. Others pointed out that this approach could improve fee estimation for users and reduce the risk of overpaying for transactions.The conversation also revolves around the use case of paying more fees than outputs to incentivize honest mining during state-level censorship attacks. It is suggested that instead of changing the "max fee" rule, a better solution would be to introduce op_ctv, which allows many users to pool fees and share a single utxo.Furthermore, it is explained that even if the "max fee" rule were changed, it could still be avoided by splitting the transaction into multiple transactions, each paying one satoshi per virtual byte. Maintaining balances and using change addresses would not be a deterrent as the transactions could be prepared upfront as part of the protocol and released all at once. This can be achieved through HD wallets, which only require storing a single key and generating addresses as needed.The proposal raises interesting questions about the tradeoffs between transaction size, fees, and network congestion. It remains to be seen whether this idea will be implemented or how it might affect the broader bitcoin ecosystem. However, it is clear that innovation and experimentation are still alive and well in the world of cryptocurrency development.Overall, the discussion explores the possibility of changing the "max fee" rule to output amounts in Bitcoin transactions. While some argue that it could help prevent spam and denial-of-service attacks, others raise concerns about the potential impact on fees, mempool, and block size. The proposal also touches on alternative solutions such as op_ctv and the use of multiple smaller transactions with lower fees. The conversation showcases the ongoing debate and exploration of new ideas within the bitcoin-dev community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_A-Fool-s-Errand-or-should-I-try-.xml b/static/bitcoin-dev/May_2024/combined_A-Fool-s-Errand-or-should-I-try-.xml index 016c596700..c569d0e379 100644 --- a/static/bitcoin-dev/May_2024/combined_A-Fool-s-Errand-or-should-I-try-.xml +++ b/static/bitcoin-dev/May_2024/combined_A-Fool-s-Errand-or-should-I-try-.xml @@ -1,45 +1,51 @@ - + 2 Combined summary - A Fool's Errand or should I try? - 2024-05-08T01:45:33.613614+00:00 - - bitcoin-dev-ml.void867 2024-05-07 05:15:00+00:00 - - - Fractal Encrypt 2024-05-06 23:51:00+00:00 - - - bitcoindevml.void 2024-05-06 08:09:00+00:00 - - - Fractal Encrypt 2024-05-05 15:03:00+00:00 - - - Ali Sherief 2024-05-05 11:55:00+00:00 - - - Fractal Encrypt 2024-05-04 15:00:00+00:00 - + 2025-09-26T14:28:59.242629+00:00 + python-feedgen + + + A Fool's Errand or should I try? Fractal Encrypt + 2024-05-04T15:00:00.000Z + + + Ali Sherief + 2024-05-05T11:55:00.000Z + + + Fractal Encrypt + 2024-05-05T15:03:00.000Z + + + bitcoin-dev-ml.void867 + 2024-05-06T08:09:00.000Z + + + Fractal Encrypt + 2024-05-06T23:51:00.000Z + + + bitcoin-dev-ml.void867 + 2024-05-07T05:15:00.000Z + + - python-feedgen + 2 Combined summary - A Fool's Errand or should I try? - 2024-05-08T01:45:33.613694+00:00 + 2025-09-26T14:28:59.243475+00:00 + 2024-05-07T05:15:00+00:00 The discussion centers around the intricacies and potential enhancements of Bitcoin's RPC commands, specifically focusing on `getrawtransaction` with verbosity level 2 and `decoderawtransaction`. The `getrawtransaction` command is spotlighted for its ability to provide comprehensive details about transactions that are either pending in the mempool or have already been confirmed within a block. This functionality is crucial for developers requiring an extensive understanding of transaction elements and their status within the blockchain ecosystem. However, there appears to be some confusion or lack of clarity regarding the use of this command for transactions that have not yet been broadcasted to the network, highlighting a possible area of misunderstanding or need for further documentation. - Further exploration into Bitcoin Core's RPC interface reveals the utility of the `getrawtransaction` function when set to verbosity 2, offering deep insights into transactions' raw data and their interactions within the blockchain. For those seeking detailed analyses or involved in application development related to Bitcoin, accessing such intricate details proves invaluable. The availability of comprehensive guides and documentation, such as the one found at [Bitcoin Core Documentation](https://bitcoincore.org/en/doc/27.0.0/rpc/rawtransactions/getrawtransaction/), supports developers and researchers in leveraging these features for advanced transaction analysis and verification processes. - A significant challenge identified relates to the `decoderawtransaction` function's limitations, particularly its independence from block storage and the complexity involved in tracing inputs back to their origins manually. The proposal for a new RPC call named `getfulltransaction` aims to address these issues by simplifying the retrieval process for transaction details, especially concerning previous input addresses and amounts, thus eliminating the need for manual workarounds and promoting efficiency. - Additionally, there's a push to augment the `decoderawtransaction` function with capabilities to display transaction fee information and possibly include metrics like satoshis per virtual byte (sats/vB). The motivation behind this enhancement stems from the difficulties experienced in manually calculating fees during transaction creation. The envisioned modification would enable `decoderawtransaction` to automatically fetch UTXO details for each input, facilitating accurate calculation of transaction fees by comparing total input and output values. This proposal also considers displaying fee information conditionally based on whether inputs originate from the user's wallet and ensuring compatibility with nodes that have `txindex` enabled, thereby supporting comprehensive transaction ID lookups across the entire chainstate. Despite acknowledging personal technical limitations, the sender expresses a strong interest and determination to contribute this enhancement to the community, emphasizing the value of guidance, mentorship, and constructive criticism in realizing this project. - 2024-05-07T05:15:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_Adding-New-BIP-Editors.xml b/static/bitcoin-dev/May_2024/combined_Adding-New-BIP-Editors.xml index 1a37caf149..4fb71283b3 100644 --- a/static/bitcoin-dev/May_2024/combined_Adding-New-BIP-Editors.xml +++ b/static/bitcoin-dev/May_2024/combined_Adding-New-BIP-Editors.xml @@ -1,308 +1,411 @@ - + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.152793+00:00 - - Murch 2024-12-10 22:37:00+00:00 - - - Mark Erhardt 2024-09-19 18:48:00+00:00 - - - Antoine Riard 2024-09-19 07:47:00+00:00 - - - Mark Erhardt 2024-09-18 18:25:00+00:00 - - - Murch 2024-05-13 18:33:00+00:00 - - - Antoine Riard 2024-04-25 06:42:00+00:00 - - - Anthony Towns 2024-04-23 22:15:00+00:00 - - - Ali Sherief 2024-04-22 04:28:00+00:00 - - - Steve Lee 2024-04-22 02:44:00+00:00 - - - Ava Chow 2024-04-22 00:06:00+00:00 - - - Matt Corallo 2024-04-21 23:01:00+00:00 - - - Antoine Riard 2024-04-21 20:48:00+00:00 - - - Michael Folkson 2024-04-21 19:18:00+00:00 - - - Ava Chow 2024-04-21 18:47:00+00:00 - - - Michael Folkson 2024-04-21 17:57:00+00:00 - - - Ava Chow 2024-04-21 16:39:00+00:00 - - - Michael Folkson 2024-04-21 11:43:00+00:00 - - - Ava Chow 2024-04-20 23:05:00+00:00 - - - Ava Chow 2024-04-20 22:47:00+00:00 - - - Michael Folkson 2024-04-20 22:21:00+00:00 - - - Steve Lee 2024-04-20 22:03:00+00:00 - - - Ava Chow 2024-04-20 21:37:00+00:00 - - - Steve Lee 2024-04-20 21:11:00+00:00 - - - Ava Chow 2024-04-20 21:08:00+00:00 - - - Ava Chow 2024-04-20 20:59:00+00:00 - - - Steve Lee 2024-04-20 20:46:00+00:00 - - - Michael Folkson 2024-04-20 19:59:00+00:00 - - - Ava Chow 2024-04-20 19:48:00+00:00 - - - Ava Chow 2024-04-20 19:14:00+00:00 - - - Olaoluwa Osuntokun 2024-04-19 22:32:00+00:00 - - - nsvrn 2024-04-17 23:58:00+00:00 - - - Ava Chow 2024-04-16 17:08:00+00:00 - - - NVK 2024-04-16 13:32:00+00:00 - - - Tim Ruffing 2024-04-16 12:34:00+00:00 - - - Matt Corallo 2024-04-15 17:50:00+00:00 - - - Sergi Delgado Segura 2024-04-11 14:22:00+00:00 - - - Ali Sherief 2024-04-07 10:11:00+00:00 - - - Larry Ruane 2024-04-05 19:18:00+00:00 - - - xBC 2024-04-04 12:58:00+00:00 - - - Niklas Goegge 2024-04-04 09:09:00+00:00 - - - Anthony Towns 2024-04-04 05:00:00+00:00 - - - Pieter Wuille 2024-04-03 19:44:00+00:00 - - - Fabian 2024-04-03 18:34:00+00:00 - - - Vasil Dimov 2024-04-03 17:24:00+00:00 - - - Juan Galt 2024-04-03 16:58:00+00:00 - - - Murch 2024-04-03 15:03:00+00:00 - - - Luke Dashjr 2024-04-02 15:39:00+00:00 - - - Gloria Zhao 2024-04-02 15:13:00+00:00 - - - Luke Dashjr 2024-04-02 14:28:00+00:00 - - - nvk 2024-04-02 14:24:00+00:00 - - - /dev /fd 2024-04-02 13:49:00+00:00 - - - Tim Ruffing 2024-04-02 13:17:00+00:00 - - - Michael Folkson 2024-04-02 08:18:00+00:00 - - - Ava Chow 2024-04-02 00:37:00+00:00 - - - /dev /fd 2024-04-01 23:55:00+00:00 - - - David A. Harding 2024-04-01 21:13:00+00:00 - - - Antoine Riard 2024-04-01 20:14:00+00:00 - - - Jonas Nick 2024-04-01 18:42:00+00:00 - - - Murch 2024-04-01 18:41:00+00:00 - - - Michael Folkson 2024-04-01 11:58:00+00:00 - - - /dev /fd 2024-04-01 06:21:00+00:00 - - - Ava Chow 2024-03-31 17:01:00+00:00 - - - Michael Folkson 2024-03-31 16:01:00+00:00 - - - Antoine Riard 2024-03-30 20:01:00+00:00 - - - Michael Folkson 2024-03-30 11:51:00+00:00 - - - Peter Todd 2024-03-30 04:04:00+00:00 - - - Keagan McClelland 2024-03-29 22:17:00+00:00 - - - Antoine Riard 2024-03-29 21:08:00+00:00 - - - /dev /fd 2024-03-29 05:24:00+00:00 - - - Michael Folkson 2024-03-29 02:34:00+00:00 - - - Matt Corallo 2024-03-28 21:19:00+00:00 - - - John C. Vernaleo 2024-03-28 20:59:00+00:00 - - - Matt Corallo 2024-03-28 20:31:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Antoine Riard 2024-03-28 19:42:00+00:00 - - - /dev /fd 2024-03-28 16:09:00+00:00 - - - Brandon Black 2024-03-28 15:50:00+00:00 - - - Murch 2024-03-28 13:02:00+00:00 - - - Matt Corallo 2024-03-27 23:54:00+00:00 - - - John C. Vernaleo 2024-03-27 23:39:00+00:00 - - - Murch 2024-03-27 23:36:00+00:00 - - - Murch 2024-03-27 21:25:00+00:00 - - - Chris Stewart 2024-03-14 11:56:00+00:00 - - - Jon A 2024-03-11 16:48:00+00:00 - - - Bitcoin Error Log 2024-03-10 17:27:00+00:00 - - - Michael Folkson 2024-03-09 10:46:00+00:00 - - - Keagan McClelland 2024-03-07 22:39:00+00:00 - - - Antoine Riard 2024-03-07 20:56:00+00:00 - - - Tim Ruffing 2024-02-28 16:31:00+00:00 - - - bitcoindevml.void 2024-02-28 11:12:00+00:00 - - - /dev /fd 2024-02-28 04:22:00+00:00 - - - Ava Chow 2024-02-27 23:26:00+00:00 - - - /dev /fd 2024-02-27 23:10:00+00:00 - - - Luke Dashjr 2024-02-27 22:57:00+00:00 - - - Luke Dashjr 2024-02-27 22:40:00+00:00 - - - Greg Tonoski 2024-02-27 21:48:00+00:00 - - - Léo Haf 2024-02-27 21:33:00+00:00 - - - Ava Chow 2024-02-27 20:11:00+00:00 - - - Ava Chow 2024-02-27 18:53:00+00:00 - + 2025-09-26T14:28:57.109875+00:00 + python-feedgen + + + Adding New BIP Editors 'Ava Chow' + 2024-02-27T18:53:00.000Z + + + Léo Haf' + 2024-02-27T20:11:00.000Z + + + Antoine Poinsot' + 2024-02-27T21:33:00.000Z + + + Greg Tonoski + 2024-02-27T21:48:00.000Z + + + Luke Dashjr + 2024-02-27T22:40:00.000Z + + + Ava Chow' + 2024-02-27T22:57:00.000Z + + + /dev /fd0 + 2024-02-27T23:10:00.000Z + + + Steve Lee + 2024-02-27T23:26:00.000Z + + + /dev /fd0 + 2024-02-28T04:22:00.000Z + + + bitcoin-dev-ml.void867 + 2024-02-28T11:12:00.000Z + + + Tim Ruffing + 2024-02-28T16:31:00.000Z + + + Antoine Riard + 2024-03-07T20:56:00.000Z + + + Keagan McClelland + 2024-03-07T22:39:00.000Z + + + Michael Folkson + 2024-03-09T10:46:00.000Z + + + Bitcoin Error Log + 2024-03-10T17:27:00.000Z + + + Jon A + 2024-03-11T16:48:00.000Z + + + Chris Stewart + 2024-03-14T11:56:00.000Z + + + Murch + 2024-03-27T21:25:00.000Z + + + Keagan McClelland + 2024-03-27T23:36:00.000Z + + + John C. Vernaleo + 2024-03-27T23:39:00.000Z + + + Matt Corallo + 2024-03-27T23:54:00.000Z + + + Murch + 2024-03-28T13:02:00.000Z + + + Brandon Black + 2024-03-28T15:50:00.000Z + + + /dev /fd0 + 2024-03-28T16:09:00.000Z + + + Antoine Riard + 2024-03-28T19:42:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Antoine Riard + 2024-03-28T20:31:00.000Z + + + John C. Vernaleo + 2024-03-28T20:59:00.000Z + + + Matt Corallo + 2024-03-28T21:19:00.000Z + + + Michael Folkson + 2024-03-29T02:34:00.000Z + + + /dev /fd0 + 2024-03-29T05:24:00.000Z + + + Antoine Riard + 2024-03-29T21:08:00.000Z + + + Keagan McClelland + 2024-03-29T22:17:00.000Z + + + Peter Todd + 2024-03-30T04:04:00.000Z + + + Michael Folkson + 2024-03-30T11:51:00.000Z + + + Antoine Riard + 2024-03-30T20:01:00.000Z + + + Michael Folkson + 2024-03-31T16:01:00.000Z + + + Ava Chow' + 2024-03-31T17:01:00.000Z + + + /dev /fd0 + 2024-04-01T06:21:00.000Z + + + Michael Folkson + 2024-04-01T11:58:00.000Z + + + Re: Adding New BIP Editors Murch + 2024-04-01T18:41:00.000Z + + + Jonas Nick + 2024-04-01T18:42:00.000Z + + + Antoine Riard + 2024-04-01T20:14:00.000Z + + + David A. Harding + 2024-04-01T21:13:00.000Z + + + /dev /fd0 + 2024-04-01T23:55:00.000Z + + + Ava Chow' + 2024-04-02T00:37:00.000Z + + + Michael Folkson + 2024-04-02T08:18:00.000Z + + + Time for an update to BIP2? Tim Ruffing + 2024-04-02T13:17:00.000Z + + + /dev /fd0 + 2024-04-02T13:49:00.000Z + + + nvk + 2024-04-02T14:24:00.000Z + + + Luke Dashjr + 2024-04-02T14:28:00.000Z + + + Gloria Zhao + 2024-04-02T15:13:00.000Z + + + Luke Dashjr + 2024-04-02T15:39:00.000Z + + + Murch + 2024-04-03T15:03:00.000Z + + + Juan Galt + 2024-04-03T16:58:00.000Z + + + Vasil Dimov + 2024-04-03T17:24:00.000Z + + + Fabian' + 2024-04-03T18:34:00.000Z + + + Pieter Wuille + 2024-04-03T19:44:00.000Z + + + Anthony Towns + 2024-04-04T05:00:00.000Z + + + Niklas Goegge + 2024-04-04T09:09:00.000Z + + + Adding New BIP Editors 0xB10C + 2024-04-04T12:58:00.000Z + + + Larry Ruane + 2024-04-05T19:18:00.000Z + + + Ali Sherief + 2024-04-07T10:11:00.000Z + + + Sergi Delgado Segura + 2024-04-11T14:22:00.000Z + + + Matt Corallo + 2024-04-15T17:50:00.000Z + + + Tim Ruffing + 2024-04-16T12:34:00.000Z + + + NVK + 2024-04-16T13:32:00.000Z + + + Ava Chow' + 2024-04-16T17:08:00.000Z + + + nsvrn' + 2024-04-17T23:58:00.000Z + + + Olaoluwa Osuntokun + 2024-04-19T22:32:00.000Z + + + Ava Chow' + 2024-04-20T19:14:00.000Z + + + NVK + 2024-04-20T19:48:00.000Z + + + Michael Folkson + 2024-04-20T19:59:00.000Z + + + Steve Lee + 2024-04-20T20:46:00.000Z + + + Ava Chow' + 2024-04-20T20:59:00.000Z + + + Ava Chow' + 2024-04-20T21:08:00.000Z + + + Steve Lee + 2024-04-20T21:11:00.000Z + + + Ava Chow' + 2024-04-20T21:37:00.000Z + + + Steve Lee + 2024-04-20T22:03:00.000Z + + + Michael Folkson + 2024-04-20T22:21:00.000Z + + + Ava Chow' + 2024-04-20T22:47:00.000Z + + + Ava Chow' + 2024-04-20T23:05:00.000Z + + + Michael Folkson + 2024-04-21T11:43:00.000Z + + + Ava Chow' + 2024-04-21T16:39:00.000Z + + + Michael Folkson + 2024-04-21T17:57:00.000Z + + + Ava Chow' + 2024-04-21T18:47:00.000Z + + + Michael Folkson + 2024-04-21T19:18:00.000Z + + + Antoine Riard + 2024-04-21T20:48:00.000Z + + + Matt Corallo + 2024-04-21T23:01:00.000Z + + + Ava Chow' + 2024-04-22T00:06:00.000Z + + + Steve Lee + 2024-04-22T02:44:00.000Z + + + Ali Sherief + 2024-04-22T04:28:00.000Z + + + Anthony Towns + 2024-04-23T22:15:00.000Z + + + Antoine Riard + 2024-04-25T06:42:00.000Z + + + Time for an update to BIP2? Murch + 2024-05-13T18:33:00.000Z + + + Murch + 2024-09-18T18:25:00.000Z + + + Antoine Riard + 2024-09-19T07:47:00.000Z + + + Murch + 2024-09-19T18:48:00.000Z + + + Murch + 2024-12-10T22:37:00.000Z + + @@ -403,21 +506,17 @@ - python-feedgen + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.153617+00:00 + 2025-09-26T14:28:57.119533+00:00 + 2024-12-10T22:37:00+00:00 In the realm of Bitcoin development, discussions pertaining to the enhancement of the Bitcoin Improvement Proposal (BIP) process have been prominent. A key focus has been on addressing the current bottleneck in managing BIPs, emphasized by Luke Dashjr's acknowledgment of his limited capacity to actively maintain the BIPs repository. This acknowledgment underscores the critical need for additional BIP editors to ensure an efficient and effective review and integration process for new proposals and amendments to existing ones. - The role of a BIP editor is significant, encompassing responsibilities such as assigning BIP numbers, merging pull requests for new proposals, making fixes to existing BIPs, and more, as outlined in BIP 2. The addition of new editors is envisaged as a pivotal measure to alleviate the backlog of submissions and augment the process's overall productivity. For the continuity and coherence of the BIP numbering system, it is imperative that any incoming editors concur on the established numbering scheme. - The selection criteria for new BIP editors highlight the necessity for candidates with a comprehensive background in Bitcoin development, showcasing a history of active participation and contributions. These individuals must possess the ability to impartially assess proposals, a quality that underscores the importance of objectivity in the role. - Within this context, Kanzure and RubenSomsen have been identified as exemplary candidates for the position of BIP editors. Their extensive involvement in Bitcoin development positions them as valuable additions to the editorial team. Their potential inclusion is anticipated to significantly ameliorate the management and advancement of the BIPs repository, offering substantial benefits to the Bitcoin development community. - This dialogue illustrates the collective effort within the Bitcoin developer ecosystem to refine the governance mechanisms surrounding BIPs. It emphasizes the commitment to ensuring that the process remains robust, transparent, and inclusive, facilitating the continuous evolution and improvement of Bitcoin. - 2024-12-10T22:37:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_Analysis-of-Replacement-Cycling-Attacks-Risks-on-L2s-beyond-LN-.xml b/static/bitcoin-dev/May_2024/combined_Analysis-of-Replacement-Cycling-Attacks-Risks-on-L2s-beyond-LN-.xml index 1a73eef840..1aa1730009 100644 --- a/static/bitcoin-dev/May_2024/combined_Analysis-of-Replacement-Cycling-Attacks-Risks-on-L2s-beyond-LN-.xml +++ b/static/bitcoin-dev/May_2024/combined_Analysis-of-Replacement-Cycling-Attacks-Risks-on-L2s-beyond-LN-.xml @@ -1,35 +1,37 @@ - + 2 Combined summary - Analysis of Replacement Cycling Attacks Risks on L2s (beyond LN) - 2024-05-26T02:02:45.378320+00:00 - - Antoine Riard 2024-05-24 23:54:00+00:00 - - - /dev /fd 2024-05-23 10:05:00+00:00 - - - Antoine Riard 2024-05-17 03:30:00+00:00 - + 2025-09-26T14:28:50.498897+00:00 + python-feedgen + + + Analysis of Replacement Cycling Attacks Risks on L2s (beyond LN) Antoine Riard + 2024-05-17T03:30:00.000Z + + + /dev /fd0 + 2024-05-23T10:05:00.000Z + + + Antoine Riard + 2024-05-24T23:54:00.000Z + + - python-feedgen + 2 Combined summary - Analysis of Replacement Cycling Attacks Risks on L2s (beyond LN) - 2024-05-26T02:02:45.378384+00:00 + 2025-09-26T14:28:50.499555+00:00 + 2024-05-24T23:54:00+00:00 The inquiry revolves around the operational and security implications for coinswap, as highlighted in the development documentation available on [GitHub](https://github.com/utxo-teleport/teleport-transactions/blob/master/docs/dev-book.mdhow-coinswap-works). The concerns raised pertain to vulnerabilities within the coinswap mechanism that might expose it to risks similar to those faced by other Bitcoin applications and protocols, particularly focusing on replacement cycling attacks and the potential for denial-of-service (DoS) and loss of funds. - Coinswap's susceptibility to a form of attack known as replacement cycling is at the core of these concerns. This type of attack involves delaying transaction confirmations through a sequence of replacement transactions, which could potentially enable an attacker to double-spend a hash time-locked contract (HTLC) preimage. The discussion extends to a broader examination of Bitcoin use cases vulnerable to such attacks, including coinjoins and lightning networks. These vulnerabilities arise from characteristics inherent to multi-party transactions and contracting protocols, such as shared UTXO spendings and pre-signed transactions executed under absolute or relative timelocks. - Moreover, the dialogue delves into the intricacies of how transaction-relay and mempool mechanisms can be manipulated to launch a time-value DoS attack, targeting specific applications or protocols to disrupt services or waste the on-chain time value of coins. Despite existing anti-DoS measures, such as those implemented in the lightning network, the risk of fund loss due to interrupted transaction confirmations remains a critical concern. - The analysis further explores the ramifications of mempool policy changes on the security models of various second-layer solutions and Bitcoin applications, including Discreet Log Contracts (DLCs), coinjoins, payjoins, and submarine swaps, among others. These applications are identified as being at risk of suffering from either financial losses or time-value DoS under certain conditions. - In summary, the vulnerability of Bitcoin applications and protocols to transaction-relay jamming presents significant challenges to both their security and functionality. The potential for financial losses and the undermining of service reliability underscores the need for a thorough understanding and mitigation of these vulnerabilities within the decentralized Bitcoin ecosystem. The complexities involved in addressing these issues highlight the difficulties in developing and implementing effective mitigation strategies across diverse codebases and user configurations. - 2024-05-24T23:54:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_BIP-21-Updates.xml b/static/bitcoin-dev/May_2024/combined_BIP-21-Updates.xml index 5986fe12e6..7451940238 100644 --- a/static/bitcoin-dev/May_2024/combined_BIP-21-Updates.xml +++ b/static/bitcoin-dev/May_2024/combined_BIP-21-Updates.xml @@ -1,25 +1,29 @@ - + 2 Combined summary - BIP 21 Updates - 2024-11-13T02:19:14.969647+00:00 - - Matt Corallo 2024-11-12 16:07:00+00:00 - - - Matt Corallo 2024-05-30 21:54:00+00:00 - + 2025-09-26T14:28:39.854540+00:00 + python-feedgen + + + BIP 21 Updates Matt Corallo + 2024-05-30T21:54:00.000Z + + + Matt Corallo + 2024-11-12T16:07:00.000Z + + - python-feedgen + 2 Combined summary - BIP 21 Updates - 2024-11-13T02:19:14.969686+00:00 + 2025-09-26T14:28:39.855033+00:00 - The recent discussions within the Bitcoin development community have brought attention to the limitations of the current BIP 21 standard, which primarily focuses on transactions using base58 addresses and lacks official support for more advanced addressing schemes like Segwit and Taproot. Given the significant adoption of wallets that can handle these newer types of addresses and decode lightning payment instructions from URI query parameters, there's a consensus on the need to modernize BIP 21. This update would not only accommodate the inclusion of Segwit and Taproot addresses in URI bodies but also support the evolving Bitcoin payment landscape, including Silent Payments and BOLT 12. The proposal suggests enhancing BIP 21 URIs to enable the embedding of various payment instructions through distinct query parameters, making the body of the URI optional for schemes that do not require a standard on-chain fallback. This approach aims to ensure compatibility with existing wallets by allowing them to ignore unrecognized new query parameters and reject invalid URIs without a body. - -Furthermore, a new Bitcoin Improvement Proposal (BIP) is being drafted to introduce an additional feature aimed at enriching the payment process. This includes the implementation of a "payment info callback" parameter, which does not affect current wallet operations but offers an important functionality for specific use cases, such as nostr zaps. The proposal outlines the mechanics of a Proof of Payment mechanism where the URI may contain a "pop" (or "req-pop") parameter. This parameter enables the construction of a URI that the wallet application can open post-payment to provide proof of payment completion or other relevant information. The parameter must be a percent-encoded URI prefix, following RFC 3986 section 2.1 guidelines. Upon payment completion, supported wallet applications will percent-decode this URI, append it with payment information, and open it with the system's default handler, barring certain schemes like HTTP or JavaScript to ensure security. For on-chain transactions, the payment information should include the full transaction data in hex format, while for BOLT 11 invoice payments, it should be the hex-encoded payment preimage. This innovative approach facilitates a more transparent and verifiable payment process, potentially setting a new standard for payment information sharing across different payment methods within the Bitcoin ecosystem. 2024-11-12T16:07:00+00:00 + The recent discussions within the Bitcoin development community have brought attention to the limitations of the current BIP 21 standard, which primarily focuses on transactions using base58 addresses and lacks official support for more advanced addressing schemes like Segwit and Taproot. Given the significant adoption of wallets that can handle these newer types of addresses and decode lightning payment instructions from URI query parameters, there's a consensus on the need to modernize BIP 21. This update would not only accommodate the inclusion of Segwit and Taproot addresses in URI bodies but also support the evolving Bitcoin payment landscape, including Silent Payments and BOLT 12. The proposal suggests enhancing BIP 21 URIs to enable the embedding of various payment instructions through distinct query parameters, making the body of the URI optional for schemes that do not require a standard on-chain fallback. This approach aims to ensure compatibility with existing wallets by allowing them to ignore unrecognized new query parameters and reject invalid URIs without a body. +Furthermore, a new Bitcoin Improvement Proposal (BIP) is being drafted to introduce an additional feature aimed at enriching the payment process. This includes the implementation of a "payment info callback" parameter, which does not affect current wallet operations but offers an important functionality for specific use cases, such as nostr zaps. The proposal outlines the mechanics of a Proof of Payment mechanism where the URI may contain a "pop" (or "req-pop") parameter. This parameter enables the construction of a URI that the wallet application can open post-payment to provide proof of payment completion or other relevant information. The parameter must be a percent-encoded URI prefix, following RFC 3986 section 2.1 guidelines. Upon payment completion, supported wallet applications will percent-decode this URI, append it with payment information, and open it with the system's default handler, barring certain schemes like HTTP or JavaScript to ensure security. For on-chain transactions, the payment information should include the full transaction data in hex format, while for BOLT 11 invoice payments, it should be the hex-encoded payment preimage. This innovative approach facilitates a more transparent and verifiable payment process, potentially setting a new standard for payment information sharing across different payment methods within the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_BIP-322-use-case.xml b/static/bitcoin-dev/May_2024/combined_BIP-322-use-case.xml index 0287b5b391..7ba75e592a 100644 --- a/static/bitcoin-dev/May_2024/combined_BIP-322-use-case.xml +++ b/static/bitcoin-dev/May_2024/combined_BIP-322-use-case.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - BIP 322 use case - 2024-05-12T02:05:58.328580+00:00 - - Prof EduStream 2024-05-10 17:47:00+00:00 - - - Luke Dashjr 2024-05-05 14:50:00+00:00 - - - Ali Sherief 2024-05-05 12:09:00+00:00 - - - Luke Dashjr 2024-05-04 00:11:00+00:00 - - - ProfEduStream 2024-05-03 23:53:00+00:00 - + 2025-09-26T14:28:46.272901+00:00 + python-feedgen + + + BIP 322 use case ProfEduStream + 2024-05-03T23:53:00.000Z + + + Luke Dashjr + 2024-05-04T00:11:00.000Z + + + Ali Sherief + 2024-05-05T12:09:00.000Z + + + Luke Dashjr + 2024-05-05T14:50:00.000Z + + + Prof EduStream + 2024-05-10T17:47:00.000Z + + - python-feedgen + 2 Combined summary - BIP 322 use case - 2024-05-12T02:05:58.328660+00:00 + 2025-09-26T14:28:46.273691+00:00 + 2024-05-10T17:47:00+00:00 The discourse centers around the significance and challenges of implementing multi-signature (multi-sig) capabilities in Bitcoin, particularly for signing messages. It's argued that the utility of signing a message with a multi-sig address should be akin to that of a single-sig address, enabling users to cryptographically demonstrate ownership of an address. This feature is already available for single-sig addresses, suggesting that extending it to multi-sig users would cater to a niche yet essential user base, including individuals and compliance-abiding companies. Despite privacy concerns deterring the development of such features, the argument posits that since single-sig signing exists, multi-sig signing could similarly benefit a specific set of users without compromising privacy principles. - Further discussion delves into the technical aspects of Bitcoin transaction proofs, such as proof-of-funds and proof-of-sender. The complexity of these mechanisms lies in their need to ensure security and privacy while accommodating the unique requirements of coinjoins and other privacy-enhancing technologies. Suggestions include delegation of signing authority and the introduction of a unique identifier for simplifying signature verification processes. Moreover, the Partially Signed Bitcoin Transactions (PSBTs) format is acknowledged for its potential in improving compatibility with these advanced cryptographic proofs, albeit with noted limitations that necessitate further technical refinements. - The dialogue also touches upon BIP322’s role in facilitating the signing of messages and the collection of UTXO sets for authentication purposes. However, its development has been hindered by its potential misuse for Know Your Customer (KYC) procedures and a lack of interest in its primary utility for pre-transaction contract agreements. Despite these challenges, some wallets have adopted BIP322, indicating a demand for its functionalities. The necessity for BIP322 or similar proposals becomes evident when considering operational challenges faced by entities requiring legal proof of Bitcoin address ownership, especially those preferring multi-sig wallets for enhanced security and governance. - -The conversation further explores the practical implications of BIP322’s limitations, highlighting the Bitcoin association's struggles with signing addresses using multi-sig wallets. Applications like "Swiss Bitcoin Pay" and Peach exemplify the operational impact, where legal requirements necessitate proof of ownership through message signing. The inability to fulfill these requirements with multi-sig wallets underscores a critical infrastructure gap within the Bitcoin ecosystem. This limitation not only affects financial operations but also hampers efforts towards decentralizing treasury functions among companies opting for the added security of multi-sig solutions. The expressed anticipation for ecosystem improvements reflects a broader call to action for the development of technologies that enable secure and decentralized verification methods in Bitcoin transactions and ownership. - 2024-05-10T17:47:00+00:00 +The conversation further explores the practical implications of BIP322’s limitations, highlighting the Bitcoin association's struggles with signing addresses using multi-sig wallets. Applications like "Swiss Bitcoin Pay" and Peach exemplify the operational impact, where legal requirements necessitate proof of ownership through message signing. The inability to fulfill these requirements with multi-sig wallets underscores a critical infrastructure gap within the Bitcoin ecosystem. This limitation not only affects financial operations but also hampers efforts towards decentralizing treasury functions among companies opting for the added security of multi-sig solutions. The expressed anticipation for ecosystem improvements reflects a broader call to action for the development of technologies that enable secure and decentralized verification methods in Bitcoin transactions and ownership. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_BIP-for-OP-CHECKSIGFROMSTACK.xml b/static/bitcoin-dev/May_2024/combined_BIP-for-OP-CHECKSIGFROMSTACK.xml index b5dee33453..523f778c53 100644 --- a/static/bitcoin-dev/May_2024/combined_BIP-for-OP-CHECKSIGFROMSTACK.xml +++ b/static/bitcoin-dev/May_2024/combined_BIP-for-OP-CHECKSIGFROMSTACK.xml @@ -1,35 +1,37 @@ - + 2 Combined summary - BIP for OP_CHECKSIGFROMSTACK - 2024-05-16T02:00:33.101359+00:00 - - Brandon Black 2024-05-14 21:55:00+00:00 - - - Andrew Poelstra 2024-04-25 11:44:00+00:00 - - - Brandon Black 2024-04-25 05:12:00+00:00 - + 2025-09-26T14:28:48.385963+00:00 + python-feedgen + + + BIP for OP_CHECKSIGFROMSTACK Brandon Black + 2024-04-25T05:12:00.000Z + + + Andrew Poelstra + 2024-04-25T11:44:00.000Z + + + Brandon Black + 2024-05-14T21:55:00.000Z + + - python-feedgen + 2 Combined summary - BIP for OP_CHECKSIGFROMSTACK - 2024-05-16T02:00:33.101424+00:00 + 2025-09-26T14:28:48.386497+00:00 + 2024-05-14T21:55:00+00:00 The email from Andrew Poelstra, Director of Research at Blockstream, sheds light on considerations regarding the Bitcoin Improvement Proposal (BIP) focusing on enhancements in bitcoin script capabilities through the introduction of new opcodes related to cryptographic signature verification. These discussions are pivotal for understanding the proposal's implications on batch verification and the CHECKSIG FROM STACK (CSFS) functionalities. Specifically, Poelstra highlights the potential inclusion of a new opcode, CHECKSIGFROMSTACKADD (CSFSA), inspired by advanced miniscript applications presented by Rob Hamilton. The consideration for CSFSA stems from its anticipated common use and feasibility of implementation. Additionally, there's a debate on making CHECKSIGFROMSTACKVERIFY exclusively available to tapscript to align with BIP119 and CTV's objectives within legacy scripts. - Poelstra articulates concerns about maintaining consistency between the sets of public keys recognized by CSFS and those accepted by CHECKSIG operations. He suggests that diverging the types of public keys used by these functions could complicate future soft forks and development trajectories. Emphasizing uniformity, Poelstra argues against the necessity of differentiating public key sets for these operations, given the initial proposal's reliance on a single set for both functionalities. This stance underscores a broader reflection on the proposal's architectural decisions and their long-term implications on bitcoin's scripting language and operational integrity. - The proposal introduces OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY opcodes, aiming to extend bitcoin's script utility by allowing cryptographic checks against arbitrary data. This initiative represents a significant shift towards enhancing script functionalities beyond traditional transaction verification methods. The proposed opcodes, designed to conform with BIP 340 standards for Schnorr signatures, bring nuanced changes to bitcoin's scripting environment. They emphasize compatibility across script types, including legacy and segwitv0, through a soft-fork deployment strategy. The technical details underline strict adherence to public key size limitations and signature validation processes, reflecting a meticulous approach to integrating these opcodes without disrupting the existing ecosystem. - Further discussions in the proposal articulate the rationale behind distinct design choices, such as leveraging NOP5 for OP_CHECKSIGFROMSTACKVERIFY to ensure broad script compatibility and avoiding pre-hash message modifications in line with BIP 340 verification practices. The document also explores potential applications of the new opcodes, like improving Lightning Network symmetry and facilitating script-based delegation, highlighting their contribution to bitcoin's flexibility and functional depth. A reference implementation available on GitHub ([bitcoin/bitcoin29270](https://github.com/bitcoin/bitcoin/pull/29270)) offers a practical foundation for assessing the proposal's technical viability and alignment with bitcoin's developmental ethos. - In essence, the proposal for introducing OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY opcodes encapsulates a forward-looking enhancement to bitcoin's scripting capabilities. It carefully balances innovation with respect for the cryptocurrency's foundational principles, providing a detailed blueprint for augmenting bitcoin's transaction verification mechanisms and overall utility. - 2024-05-14T21:55:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_BIP-for-Testnet-4.xml b/static/bitcoin-dev/May_2024/combined_BIP-for-Testnet-4.xml index 91bc2710cd..ad369f1e8a 100644 --- a/static/bitcoin-dev/May_2024/combined_BIP-for-Testnet-4.xml +++ b/static/bitcoin-dev/May_2024/combined_BIP-for-Testnet-4.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - BIP for Testnet 4 - 2024-05-31T02:10:54.805641+00:00 - - Matt Corallo 2024-05-30 17:46:00+00:00 - - - Fabian 2024-05-28 23:41:00+00:00 - - - Fabian 2024-05-28 22:01:00+00:00 - + 2025-09-26T14:28:37.744029+00:00 + python-feedgen + + + BIP for Testnet 4 'Fabian' + 2024-05-28T22:01:00.000Z + + + Fabian' + 2024-05-28T23:41:00.000Z + + + Matt Corallo + 2024-05-30T17:46:00.000Z + + - python-feedgen + 2 Combined summary - BIP for Testnet 4 - 2024-05-31T02:10:54.805687+00:00 + 2025-09-26T14:28:37.744659+00:00 - The Bitcoin development community has been actively discussing the creation of Testnet 4, a successor to Testnet 3, in response to several significant issues that have emerged after 13 years of operation. These challenges include an edge case bug known as "block storms," which severely hampers network functionality by allowing excessive mining of blocks in short periods, and the misuse of the testnet for scammy airdrops, thus detracting from its intended purpose as highlighted by Jameson Lopp. The primary aim behind introducing Testnet 4 is to refine and improve upon the existing framework by implementing minor but crucial modifications to the consensus rules to prevent CPU-only mining attacks and enhance overall network security and utility. - + 2024-05-30T17:46:00+00:00 + The Bitcoin development community has been actively discussing the creation of Testnet 4, a successor to Testnet 3, in response to several significant issues that have emerged after 13 years of operation. These challenges include an edge case bug known as "block storms," which severely hampers network functionality by allowing excessive mining of blocks in short periods, and the misuse of the testnet for scammy airdrops, thus detracting from its intended purpose as highlighted by Jameson Lopp. The primary aim behind introducing Testnet 4 is to refine and improve upon the existing framework by implementing minor but crucial modifications to the consensus rules to prevent CPU-only mining attacks and enhance overall network security and utility. One notable change in Testnet 4 concerns the calculation method for the required work for the first block in a new difficulty period. This adjustment seeks to address the difficulty resetting issue prevalent in Testnet 3. By maintaining the 20-minute difficulty exception while introducing a more nuanced approach to calculating difficulty adjustments, Testnet 4 aims to strike a balance between minimal changes for user compatibility and significant improvements for network stability. During the discussions for these modifications, various alternatives were considered. However, the community opted for solutions that would not drastically alter the network's fundamental operations or exclude CPU miners, thereby ensuring a degree of continuity and accessibility. - For the implementation of Testnet 4, detailed network parameters and consensus rules have been outlined, with a focus on backward compatibility for software that currently supports Testnet 3. This includes adherence to all mainnet consensus rules from the outset, incorporating updates such as the Taproot softfork from the genesis block of Testnet 4. The deliberate structuring of Testnet 4’s genesis block and the thoughtful consideration of its consensus rules underscore the collective effort of the Bitcoin development community to evolve the testing environment thoughtfully. By addressing vulnerabilities and fostering minimal disruption, Testnet 4 is poised to offer a pragmatic, improved platform for developers, reflecting a harmonious blend of innovation and careful planning within the broader context of Bitcoin’s ongoing development. - 2024-05-30T17:46:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_Great-Consensus-Cleanup-Revival.xml b/static/bitcoin-dev/May_2024/combined_Great-Consensus-Cleanup-Revival.xml index 4509c7cd94..348c920c4d 100644 --- a/static/bitcoin-dev/May_2024/combined_Great-Consensus-Cleanup-Revival.xml +++ b/static/bitcoin-dev/May_2024/combined_Great-Consensus-Cleanup-Revival.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.043876+00:00 - - Antoine Riard 2024-11-28 05:18:00+00:00 - - - Murad Ali 2024-07-20 21:39:00+00:00 - - - Eric Voskuil 2024-07-20 20:29:00+00:00 - - - Antoine Riard 2024-07-18 17:39:00+00:00 - - - Eric Voskuil 2024-07-04 14:45:00+00:00 - - - Antoine Riard 2024-07-04 13:20:00+00:00 - - - Eric Voskuil 2024-07-03 23:29:00+00:00 - - - Eric Voskuil 2024-07-03 01:13:00+00:00 - - - Larry Ruane 2024-07-03 01:07:00+00:00 - - - Eric Voskuil 2024-07-02 15:57:00+00:00 - - - Antoine Poinsot 2024-07-02 10:23:00+00:00 - - - Antoine Riard 2024-07-02 02:36:00+00:00 - - - Eric Voskuil 2024-06-29 20:40:00+00:00 - - - Eric Voskuil 2024-06-29 20:29:00+00:00 - - - Antoine Riard 2024-06-29 01:53:00+00:00 - - - Eric Voskuil 2024-06-29 01:31:00+00:00 - - - Antoine Riard 2024-06-29 01:06:00+00:00 - - - Eric Voskuil 2024-06-28 17:14:00+00:00 - - - Antoine Poinsot 2024-06-27 09:35:00+00:00 - - - Eric Voskuil 2024-06-24 00:35:00+00:00 - - - Antoine Poinsot 2024-06-21 13:09:00+00:00 - - - Eric Voskuil 2024-06-18 13:02:00+00:00 - - - Antoine Poinsot 2024-06-18 08:13:00+00:00 - - - Eric Voskuil 2024-06-17 22:15:00+00:00 - - - Antoine Riard 2024-05-06 01:10:00+00:00 - - - Mark F 2024-04-30 22:20:00+00:00 - - - Antoine Riard 2024-04-25 06:08:00+00:00 - - - Antoine Poinsot 2024-04-18 10:04:00+00:00 - - - Mark F 2024-04-18 00:46:00+00:00 - - - Antoine Riard 2024-03-27 18:57:00+00:00 - - - Antoine Poinsot 2024-03-27 10:35:00+00:00 - - - Antoine Riard 2024-03-26 19:11:00+00:00 - - - Antoine Poinsot 2024-03-24 18:10:00+00:00 - + 2025-09-26T14:28:42.041811+00:00 + python-feedgen + + + Great Consensus Cleanup Revival 'Antoine Poinsot' + 2024-03-24T18:10:00.000Z + + + Antoine Riard + 2024-03-26T19:11:00.000Z + + + Antoine Poinsot' + 2024-03-27T10:35:00.000Z + + + Antoine Riard + 2024-03-27T18:57:00.000Z + + + Mark F + 2024-04-18T00:46:00.000Z + + + Antoine Poinsot' + 2024-04-18T10:04:00.000Z + + + Antoine Riard + 2024-04-25T06:08:00.000Z + + + Mark F + 2024-04-30T22:20:00.000Z + + + Antoine Riard + 2024-05-06T01:10:00.000Z + + + Eric Voskuil + 2024-06-17T22:15:00.000Z + + + Antoine Poinsot' + 2024-06-18T08:13:00.000Z + + + Eric Voskuil + 2024-06-18T13:02:00.000Z + + + Antoine Poinsot' + 2024-06-21T13:09:00.000Z + + + Eric Voskuil + 2024-06-24T00:35:00.000Z + + + Antoine Poinsot' + 2024-06-27T09:35:00.000Z + + + Eric Voskuil + 2024-06-28T17:14:00.000Z + + + Antoine Riard + 2024-06-29T01:06:00.000Z + + + Eric Voskuil + 2024-06-29T01:31:00.000Z + + + Antoine Riard + 2024-06-29T01:53:00.000Z + + + Eric Voskuil + 2024-06-29T20:29:00.000Z + + + Eric Voskuil + 2024-06-29T20:40:00.000Z + + + Antoine Riard + 2024-07-02T02:36:00.000Z + + + Antoine Poinsot' + 2024-07-02T10:23:00.000Z + + + Eric Voskuil + 2024-07-02T15:57:00.000Z + + + Larry Ruane + 2024-07-03T01:07:00.000Z + + + Eric Voskuil + 2024-07-03T01:13:00.000Z + + + Eric Voskuil + 2024-07-03T23:29:00.000Z + + + Antoine Riard + 2024-07-04T13:20:00.000Z + + + Eric Voskuil + 2024-07-04T14:45:00.000Z + + + Antoine Riard + 2024-07-18T17:39:00.000Z + + + Eric Voskuil + 2024-07-20T20:29:00.000Z + + + Murad Ali + 2024-07-20T21:39:00.000Z + + + Antoine Riard + 2024-11-28T05:18:00.000Z + + @@ -135,19 +171,16 @@ - python-feedgen + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.044085+00:00 + 2025-09-26T14:28:42.045526+00:00 + 2024-11-28T05:18:00+00:00 The conversation initiated by Antoine Poinsot sheds light on various aspects of the Bitcoin network's consensus mechanism, probing into areas that could benefit from improvement and adjustment. Poinsot zeroes in on concerns like the prolonged block validation times, which pose a threat to the network's overall efficacy and security framework. In response to this, he acknowledges existing solutions but proposes a supplementary strategy that caps the size of legacy transactions, aiming to bolster safety measures and ensure quicker validation processes. - Another significant point of discussion is the timewarp bug, which Poinsot indicates has not received the level of concern it rightfully demands. He emphasizes the critical need for addressing this flaw to safeguard the network’s stability. Moreover, the debate ventures into ensuring coinbase transaction uniqueness as a measure to circumvent the requirement for BIP30 validations beyond a specific block height, suggesting a potential pathway to streamline transaction verification while enhancing the network's security posture. - A nuanced proposal is introduced regarding the handling of transactions based on their sizes. Poinsot suggests maintaining the validity of transactions under 64 bytes while advocating for the invalidation of those exactly at this size threshold. This approach hints at a precise methodology aimed at refining transaction processing without imposing broad restrictions on transaction sizes. - The dialogue further extends an invitation to the community for additional insights, challenging others to identify possible disagreements, overlooked facets, or enhancements to the presented proposals. This initiative underscores a commitment to collaborative progress, aiming to cultivate a constructive forum for discussion that could lead to substantial improvements within the Bitcoin consensus mechanism. Through this exchange, Poinsot not only highlights key areas of concern but also catalyzes a broader dialogue aimed at fortifying the network against potential vulnerabilities and inefficiencies. - 2024-11-28T05:18:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_How-was-the-average-size-of-blk-data-chosen-.xml b/static/bitcoin-dev/May_2024/combined_How-was-the-average-size-of-blk-data-chosen-.xml index 822533c144..e7106134df 100644 --- a/static/bitcoin-dev/May_2024/combined_How-was-the-average-size-of-blk-data-chosen-.xml +++ b/static/bitcoin-dev/May_2024/combined_How-was-the-average-size-of-blk-data-chosen-.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - How was the average size of blk*.data chosen? - 2024-05-31T02:10:12.608851+00:00 - - Peter Todd 2024-05-30 18:20:00+00:00 - - - Juan David Peña Melo 2024-05-07 01:23:00+00:00 - + 2025-09-26T14:28:35.630816+00:00 + python-feedgen + + + How was the average size of blk*.data chosen? Juan David Peña Melo + 2024-05-07T01:23:00.000Z + + + Peter Todd + 2024-05-30T18:20:00.000Z + + - python-feedgen + 2 Combined summary - How was the average size of blk*.data chosen? - 2024-05-31T02:10:12.608891+00:00 + 2025-09-26T14:28:35.631422+00:00 + 2024-05-30T18:20:00+00:00 The determination of file sizes for storing data on blockchain networks is a critical decision influenced by various technical considerations to ensure optimal performance and compatibility. For instance, the Monero cryptocurrency stores all block data in a single file, which poses challenges when dealing with older file systems that do not support files larger than 4GB. This limitation necessitates selecting a maximum file size below this threshold to avoid issues such as difficulties in copying files between locations. Additionally, storing an excessive number of files within a single directory can lead to operational problems, suggesting a balance must be struck between the number of files and their individual sizes. - The Bitcoin network adopts a structured approach to data storage through its blk*.dat files, which encapsulate raw block data including verified transactions. These files are generated sequentially and maintain a consistent size range between 128MB to 134MB. This size specification results from meticulous testing aimed at optimizing various aspects of system performance such as efficiency in read/write operations and synchronization speeds with the network. The underlying rationale is to achieve a balance that minimizes the number of read/write operations—thereby enhancing performance—while also ensuring files are not so large as to impede download and processing times, which could slow down synchronization with the blockchain. - Developers conduct extensive benchmark tests to ascertain the impact of file size on the blockchain's overall performance, examining factors like synchronization times and system responsiveness during read/write processes. Such experimentation is vital for maintaining the efficiency and scalability of the Bitcoin software, enabling it to handle growing transaction volumes without significant performance loss. The chosen file size has direct implications for users operating full nodes, affecting the required disk space and the speed at which nodes can fully synchronize with the network. As the blockchain continues to expand, ongoing adjustments and monitoring by developers are essential to keep the Bitcoin network resilient and accessible. For further details, visit [Peter Todd's website](https://petertodd.org). - 2024-05-30T18:20:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_Penlock-a-paper-computer-for-secret-splitting-BIP39-seed-phrases.xml b/static/bitcoin-dev/May_2024/combined_Penlock-a-paper-computer-for-secret-splitting-BIP39-seed-phrases.xml index 0216a92dce..7a0ef5cf6a 100644 --- a/static/bitcoin-dev/May_2024/combined_Penlock-a-paper-computer-for-secret-splitting-BIP39-seed-phrases.xml +++ b/static/bitcoin-dev/May_2024/combined_Penlock-a-paper-computer-for-secret-splitting-BIP39-seed-phrases.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - Penlock, a paper-computer for secret-splitting BIP39 seed phrases - 2024-05-25T01:59:49.743108+00:00 - - Rama Gan 2024-05-24 15:02:00+00:00 - - - Andrew Poelstra 2024-05-24 14:14:00+00:00 - - - Rama Gan 2024-05-24 10:39:00+00:00 - - - Andrew Poelstra 2024-05-16 17:24:00+00:00 - - - Andrew Poelstra 2024-05-16 13:27:00+00:00 - - - Rama Gan 2024-05-16 07:43:00+00:00 - - - Andrew Poelstra 2024-05-14 13:42:00+00:00 - - - Rama Gan 2024-05-14 12:43:00+00:00 - - - Rama Gan 2024-05-14 12:03:00+00:00 - - - Andrew Poelstra 2024-05-13 13:40:00+00:00 - - - Rama Gan 2024-05-12 18:04:00+00:00 - + 2025-09-26T14:28:54.832685+00:00 + python-feedgen + + + Penlock, a paper-computer for secret-splitting BIP39 seed phrases 'Rama Gan' + 2024-05-12T18:04:00.000Z + + + Andrew Poelstra + 2024-05-13T13:40:00.000Z + + + Rama Gan' + 2024-05-14T12:03:00.000Z + + + Rama Gan' + 2024-05-14T12:43:00.000Z + + + Andrew Poelstra + 2024-05-14T13:42:00.000Z + + + Rama Gan' + 2024-05-16T07:43:00.000Z + + + Andrew Poelstra + 2024-05-16T13:27:00.000Z + + + Andrew Poelstra + 2024-05-16T17:24:00.000Z + + + Rama Gan' + 2024-05-24T10:39:00.000Z + + + Andrew Poelstra + 2024-05-24T14:14:00.000Z + + + Rama Gan' + 2024-05-24T15:02:00.000Z + + @@ -47,23 +61,18 @@ - python-feedgen + 2 Combined summary - Penlock, a paper-computer for secret-splitting BIP39 seed phrases - 2024-05-25T01:59:49.743198+00:00 + 2025-09-26T14:28:54.834124+00:00 + 2024-05-24T15:02:00+00:00 Andrew Poelstra's discussions offer insights into the intricacies of cryptographic methods and tools, with a focus on enhancing security and efficiency in data handling and recovery processes. The dialogue touches upon various aspects including the design and implementation of cryptographic schemes like 2-of-M, optimizations for secure storage solutions, and considerations for digital document compatibility. - One key theme is the exploration of encoding schemes and their impact on the compactness and processing speed of secure information storage. Poelstra highlights the comparison between different encoding methods, noting how codex32 surpasses others by compressing data into fewer characters without sacrificing data integrity. This efficiency is crucial for practical applications where both speed and security are paramount. Furthermore, Poelstra addresses the potential for confusion arising from attempting to use a composite scheme for secret splitting, acknowledging the need for clear differentiation in method application based on the number of shares involved. - The conversation also delves into the development of tools like slide wheels for aiding in recovery processes, emphasizing the balance between theoretical idealism and practical usability. The idea of employing a second wheel and altering labeling to accommodate recovery windows suggests an ongoing endeavor to refine tools for better user experience. Despite these innovations, Poelstra candidly discusses the limitations and challenges faced, particularly in ensuring that added complexities do not outweigh the benefits. - Andrew Poelstra provides a detailed overview of Penlock, a project aimed at improving the security and accessibility of cryptographic practices. Penlock uses a novel approach to secret splitting, optimizing it for paper-based implementations and making it user-friendly. The method allows for efficient and secure management of secrets, backed by a simple checksum mechanism for error detection. Practical tools, such as a printable wheel, facilitate the arithmetic operations necessary for implementing Penlock's algorithms, showcasing a commitment to making cryptographic methods more accessible to users. - Moreover, Poelstra sheds light on broader issues related to digital document compatibility and the practicalities of utilizing cryptographic tools in real-world scenarios. The discussion covers the challenges of ensuring document display fidelity across browsers and the implications for secure information handling. Additionally, the dialogue encompasses the exploration of new methodologies for seed phrase generation and the potential integration with existing cryptographic systems, highlighting the importance of adaptability and careful consideration of user experience. - In sum, Andrew Poelstra's communications provide valuable insights into ongoing efforts to enhance cryptographic security and efficiency. Through discussions on encoding schemes, tool development, and practical implementation challenges, Poelstra contributes to a deeper understanding of the complexities involved in secure data handling and recovery. His work underscores the importance of innovation, collaboration, and continuous improvement in the field of cryptography. - 2024-05-24T15:02:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml b/static/bitcoin-dev/May_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml index fa98b6b549..889981611f 100644 --- a/static/bitcoin-dev/May_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml +++ b/static/bitcoin-dev/May_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) - 2024-11-18T02:30:36.698421+00:00 - - Ethan Heilman 2024-11-17 21:59:00+00:00 - - - Ethan Heilman 2024-11-16 14:55:00+00:00 - - - Xiaohui Liu 2024-11-15 21:54:00+00:00 - - - Garlo Nicon 2024-10-25 09:58:00+00:00 - - - Vicky 2024-10-25 00:20:00+00:00 - - - Antoine Riard 2024-05-11 02:53:00+00:00 - - - Andrew Poelstra 2024-05-09 12:46:00+00:00 - - - Ben Carman 2024-05-09 00:31:00+00:00 - - - Ethan Heilman 2024-05-07 16:05:00+00:00 - - - Andrew Poelstra 2024-05-07 14:34:00+00:00 - - - David A. Harding 2024-05-07 04:11:00+00:00 - - - Antoine Riard 2024-05-07 00:55:00+00:00 - - - Andrew Poelstra 2024-05-06 19:06:00+00:00 - - - David A. Harding 2024-05-06 18:56:00+00:00 - - - Andrew Poelstra 2024-05-06 16:48:00+00:00 - - - David A. Harding 2024-05-06 07:39:00+00:00 - - - Ethan Heilman 2024-05-01 20:02:00+00:00 - - - Antoine Riard 2024-05-01 03:46:00+00:00 - - - Ethan Heilman 2024-04-30 20:43:00+00:00 - - - Andrew Poelstra 2024-04-30 14:21:00+00:00 - - - Ethan Heilman 2024-04-30 13:25:00+00:00 - - - Matthew Zipkin 2024-04-30 12:32:00+00:00 - - - Ethan Heilman 2024-04-29 00:30:00+00:00 - + 2025-09-26T14:28:52.680530+00:00 + python-feedgen + + + Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) Ethan Heilman + 2024-04-29T00:30:00.000Z + + + Matthew Zipkin + 2024-04-30T12:32:00.000Z + + + Ethan Heilman + 2024-04-30T13:25:00.000Z + + + Andrew Poelstra + 2024-04-30T14:21:00.000Z + + + Ethan Heilman + 2024-04-30T20:43:00.000Z + + + Antoine Riard + 2024-05-01T03:46:00.000Z + + + Ethan Heilman + 2024-05-01T20:02:00.000Z + + + David A. Harding + 2024-05-06T07:39:00.000Z + + + Andrew Poelstra + 2024-05-06T16:48:00.000Z + + + David A. Harding + 2024-05-06T18:56:00.000Z + + + Andrew Poelstra + 2024-05-06T19:06:00.000Z + + + Antoine Riard + 2024-05-07T00:55:00.000Z + + + David A. Harding + 2024-05-07T04:11:00.000Z + + + Andrew Poelstra + 2024-05-07T14:34:00.000Z + + + Ethan Heilman + 2024-05-07T16:05:00.000Z + + + Ben Carman + 2024-05-09T00:31:00.000Z + + + Andrew Poelstra + 2024-05-09T12:46:00.000Z + + + Antoine Riard + 2024-05-11T02:53:00.000Z + + + Vicky + 2024-10-25T00:20:00.000Z + + + Garlo Nicon + 2024-10-25T09:58:00.000Z + + + Xiaohui Liu + 2024-11-15T21:54:00.000Z + + + Ethan Heilman + 2024-11-16T14:55:00.000Z + + + Ethan Heilman + 2024-11-17T21:59:00.000Z + + @@ -95,35 +121,24 @@ - python-feedgen + 2 Combined summary - Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) - 2024-11-18T02:30:36.698570+00:00 + 2025-09-26T14:28:52.682861+00:00 + 2024-11-17T21:59:00+00:00 The conversation explores innovative approaches to blockchain technology, particularly focusing on the implementation of covenants and introspection within Bitcoin's blockchain without necessitating OP_CAT. The dialogue delves into the limitations and potentials of utilizing opcodes like OP_SIZE for creating sophisticated contracts or covenants. It outlines a theoretical framework where an unlimited opcode set could enable small scripts capable of enforcing rules or conditions by introspecting the entire blockchain, potentially incorporating snarks to maintain script size while enhancing privacy and security through cryptographic methods. - The discussion also touches upon the complexities of implementing covenants in Bitcoin's scripting language, highlighting the technical challenges involved in parsing transaction fields without OP_CAT. This inquiry underscores the foundational aspects of Bitcoin's programmability and security features, emphasizing the need for developers to understand these mechanisms thoroughly. - Further, the conversation shifts to examining the security implications of using multiple private keys for generating specific addresses, illustrating the computational difficulty associated with this process through examples of one-byte and two-byte grinds. This illustration serves to highlight the nuanced strategy in multisignature setups within the Bitcoin protocol, showcasing how developers can leverage cryptographic signatures to balance accessibility and security according to the needs of a transaction or wallet. - In another part of the conversation, the focus shifts to the examination of ECDSA signature size distribution within Bitcoin's cryptographic framework, discussing the practicality of enhancing transaction security through signature batching. Additionally, Adam's proposal on Proof-of-Work locked outputs is explored as a more feasible approach than employing full Lamport signature schemes, further probing the security model and practical applications of these cryptographic enhancements in light of Bitcoin's operability constraints. - -Antoine's email to Ethan provides an in-depth analysis of cryptographic techniques related to transaction security and flexibility within blockchain technologies. It discusses vulnerabilities and innovations in Lamport and ECDSA/Schnorr signatures, emphasizing the potential risks and solutions to secure transactions against quantum computing threats. The concept of a "faux-ctv" variant leveraging BIP118 for no-input signatures is introduced, offering insights into the evolving landscape of blockchain security and transaction integrity. - +Antoine's email to Ethan provides an in-depth analysis of cryptographic techniques related to transaction security and flexibility within blockchain technologies. It discusses vulnerabilities and innovations in Lamport and ECDSA/Schnorr signatures, emphasizing the potential risks and solutions to secure transactions against quantum computing threats. The concept of a "faux-ctv" variant leveraging BIP118 for no-input signatures is introduced, offering insights into the evolving landscape of blockchain security and transaction integrity. Andrew Poelstra's insight into transaction signing processes within blockchain highlights the importance of sighash flags in ensuring transaction integrity, providing a deeper understanding of blockchain technology's technical nuances. His affiliation with Blockstream Research and contributions to the field are acknowledged, inviting further exploration of his work for those interested in blockchain advancements. - The dialogue between Ethan Heilman and David A. Harding sheds light on novel techniques to implement covenants in Bitcoin's scripting language, tapscript, despite opcode limitations. This conversation underlines ongoing explorations into expanding Bitcoin's scripting capabilities, reflecting broader interests in enhancing smart contract provisions on the platform. - A nuanced discussion among blockchain enthusiasts addresses several key points regarding fee bumping, signature validation, and quantum computing vulnerabilities in Bitcoin transactions. This exchange encapsulates a deep understanding of managing transaction fees, ensuring signature security, and preparing for technological threats to the cryptocurrency protocol. - Andrew Poelstra's method to bridge gaps between pre-Taproot and post-Taproot transaction outputs using anti-equivocation schemes exemplifies innovative solutions to enhance Bitcoin's security measures without relying on newer Schnorr signatures. This proposal underscores creative approaches to developing blockchain technology within the constraints of Bitcoin's scripting language. - The discussion between Antoine Riard and Andrew Poelstra, involving Matthew Zipkin and Ethan Heilman, revolves around the intricacies of integrating ECDSA and Schnorr signatures within Tapscript. This technical exploration reveals the complexity and potential confusion surrounding cryptographic and scripting innovations, reflecting efforts to evolve Bitcoin's scripting abilities for increased transaction verification and execution flexibility. - The conversation highlights a potential vulnerability in using Lamport public keys for blockchain transactions, pointing out the susceptibility to DoS attacks and issues related to signature algorithms like ECDSA. Concerns about the robustness of such schemes against attackers with considerable computational resources are raised, alongside discussions on improving the overall resilience of the system through technical adjustments. - This comprehensive summary encapsulates the multifaceted discussions on cryptographic techniques, security concerns, and innovative approaches to enhancing Bitcoin's functionality and security. The conversations reflect the collaborative effort and ongoing research within the blockchain community to address technical challenges and expand the capabilities of cryptocurrency platforms. - 2024-11-17T21:59:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_Test-cases-for-signing-legacy-inputs-in-transactions.xml b/static/bitcoin-dev/May_2024/combined_Test-cases-for-signing-legacy-inputs-in-transactions.xml index 9a30d4d55c..009e4c7e20 100644 --- a/static/bitcoin-dev/May_2024/combined_Test-cases-for-signing-legacy-inputs-in-transactions.xml +++ b/static/bitcoin-dev/May_2024/combined_Test-cases-for-signing-legacy-inputs-in-transactions.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Test cases for signing legacy inputs in transactions - 2024-05-04T03:09:42.518325+00:00 - - Ali Sherief 2024-05-02 10:29:00+00:00 - - - Edil Guimarães de Medeiros 2024-04-30 12:48:00+00:00 - - - Ali Sherief 2024-04-30 11:43:00+00:00 - + 2025-09-26T14:28:33.519332+00:00 + python-feedgen + + + Test cases for signing legacy inputs in transactions Ali Sherief + 2024-04-30T11:43:00.000Z + + + Edil Guimarães de Medeiros + 2024-04-30T12:48:00.000Z + + + Ali Sherief + 2024-05-02T10:29:00.000Z + + - python-feedgen + 2 Combined summary - Test cases for signing legacy inputs in transactions - 2024-05-04T03:09:42.518386+00:00 + 2025-09-26T14:28:33.519898+00:00 + 2024-05-02T10:29:00+00:00 The conversation delves into the complexities and considerations involved in using core to generate private keys and legacy transactions within a software framework. It touches upon the trust placed in core as a standard for transaction implementation, while also acknowledging the limitations of relying solely on one's own generated Core transactions due to the inability to cover all edge cases. This discussion reflects a broader acknowledgment within the network of the existing compatibility with core, despite potential flaws, suggesting an industry-wide acceptance of its role. However, it raises concerns over the simplicity of this approach, prompting a call for further scrutiny in relation to software development practices, particularly those concerning security and reliability in transaction processing. - Ali highlights the challenges encountered in testing reproducible legacy transactions, stemming primarily from the lack of crucial debugging information and the non-determinism introduced by using OpenSSL for signature creation. This situation underscores the difficulties developers face in ensuring the reliability of transaction constructors in BIP143 and the need for improved testing methodologies. The absence of raw legacy transactions accompanied by their private keys is identified as a significant obstacle, emphasizing the necessity for resources that offer comprehensive and deterministic data sets for effective software testing. This conversation points towards a pressing demand within the programming community for better testing environments that accommodate legacy transaction formats, thereby facilitating more reliable blockchain technology development and assessment. - 2024-05-02T10:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_The-Future-of-Bitcoin-Testnet.xml b/static/bitcoin-dev/May_2024/combined_The-Future-of-Bitcoin-Testnet.xml index 45054a7a94..4584b80c5e 100644 --- a/static/bitcoin-dev/May_2024/combined_The-Future-of-Bitcoin-Testnet.xml +++ b/static/bitcoin-dev/May_2024/combined_The-Future-of-Bitcoin-Testnet.xml @@ -1,134 +1,179 @@ - + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303256+00:00 - - Saint Wenhao 2025-04-25 17:19:00+00:00 - - - Garlo Nicon 2025-03-31 10:48:00+00:00 - - - Peter Todd 2024-05-04 17:13:00+00:00 - - - Peter Todd 2024-05-04 17:08:00+00:00 - - - Ali Sherief 2024-05-02 07:10:00+00:00 - - - Garlo Nicon 2024-05-01 15:30:00+00:00 - - - Matthew Bagazinski 2024-04-30 18:46:00+00:00 - - - Matt Corallo 2024-04-28 13:45:00+00:00 - - - Ali Sherief 2024-04-22 04:33:00+00:00 - - - Sjors Provoost 2024-04-16 17:30:00+00:00 - - - Garlo Nicon 2024-04-10 06:57:00+00:00 - - - Garlo Nicon 2024-04-09 18:28:00+00:00 - - - Peter Todd 2024-04-09 16:48:00+00:00 - - - coinableS 2024-04-09 04:29:00+00:00 - - - Garlo Nicon 2024-04-08 19:11:00+00:00 - - - K Calvin 2024-04-07 08:09:00+00:00 - - - Christian Decker 2024-04-07 07:20:00+00:00 - - - David A. Harding 2024-04-06 23:04:00+00:00 - - - Calvin Kim 2024-04-05 04:30:00+00:00 - - - Jameson Lopp 2024-04-04 12:47:00+00:00 - - - Calvin Kim 2024-04-04 08:14:00+00:00 - - - Andrew Poelstra 2024-04-03 19:35:00+00:00 - - - emsit 2024-04-03 18:18:00+00:00 - - - Anthony Towns 2024-04-03 04:19:00+00:00 - - - Jameson Lopp 2024-04-02 19:46:00+00:00 - - - Lukáš Kráľ 2024-04-02 18:36:00+00:00 - - - Jameson Lopp 2024-04-02 11:53:00+00:00 - - - Fabian 2024-04-01 22:01:00+00:00 - - - emsit 2024-04-01 19:22:00+00:00 - - - Warren Togami 2024-04-01 14:28:00+00:00 - - - Andrew Poelstra 2024-04-01 14:20:00+00:00 - - - Pieter Wuille 2024-04-01 13:37:00+00:00 - - - Fabian 2024-04-01 13:32:00+00:00 - - - Peter Todd 2024-04-01 13:25:00+00:00 - - - Jameson Lopp 2024-04-01 12:54:00+00:00 - - - Peter Todd 2024-03-31 21:29:00+00:00 - - - Nagaev Boris 2024-03-31 21:01:00+00:00 - - - Eric Voskuil 2024-03-31 17:21:00+00:00 - - - Peter Todd 2024-03-31 16:02:00+00:00 - - - Jameson Lopp 2024-03-31 14:57:00+00:00 - - - Luke Dashjr 2024-03-31 14:33:00+00:00 - - - Jameson Lopp 2024-03-31 13:19:00+00:00 - + 2025-09-26T14:29:01.430806+00:00 + python-feedgen + + + The Future of Bitcoin Testnet Jameson Lopp + 2024-03-31T13:19:00.000Z + + + Luke Dashjr + 2024-03-31T14:33:00.000Z + + + Jameson Lopp + 2024-03-31T14:57:00.000Z + + + Peter Todd + 2024-03-31T16:02:00.000Z + + + Eric Voskuil + 2024-03-31T17:21:00.000Z + + + Nagaev Boris + 2024-03-31T21:01:00.000Z + + + Peter Todd + 2024-03-31T21:29:00.000Z + + + Jameson Lopp + 2024-04-01T12:54:00.000Z + + + Andrew Poelstra + 2024-04-01T13:25:00.000Z + + + Fabian' + 2024-04-01T13:32:00.000Z + + + Pieter Wuille + 2024-04-01T13:37:00.000Z + + + Andrew Poelstra + 2024-04-01T14:20:00.000Z + + + Warren Togami + 2024-04-01T14:28:00.000Z + + + emsit + 2024-04-01T19:22:00.000Z + + + Fabian' + 2024-04-01T22:01:00.000Z + + + Jameson Lopp + 2024-04-02T11:53:00.000Z + + + Lukáš Kráľ + 2024-04-02T18:36:00.000Z + + + Jameson Lopp + 2024-04-02T19:46:00.000Z + + + Anthony Towns + 2024-04-03T04:19:00.000Z + + + emsit + 2024-04-03T18:18:00.000Z + + + Andrew Poelstra + 2024-04-03T19:35:00.000Z + + + Calvin Kim + 2024-04-04T08:14:00.000Z + + + Jameson Lopp + 2024-04-04T12:47:00.000Z + + + Calvin Kim + 2024-04-05T04:30:00.000Z + + + David A. Harding + 2024-04-06T23:04:00.000Z + + + Christian Decker + 2024-04-07T07:20:00.000Z + + + K Calvin + 2024-04-07T08:09:00.000Z + + + Garlo Nicon + 2024-04-08T19:11:00.000Z + + + coinableS + 2024-04-09T04:29:00.000Z + + + Peter Todd + 2024-04-09T16:48:00.000Z + + + Garlo Nicon + 2024-04-09T18:28:00.000Z + + + Garlo Nicon + 2024-04-10T06:57:00.000Z + + + Sjors Provoost' + 2024-04-16T17:30:00.000Z + + + Ali Sherief + 2024-04-22T04:33:00.000Z + + + Matt Corallo + 2024-04-28T13:45:00.000Z + + + Matthew Bagazinski + 2024-04-30T18:46:00.000Z + + + Garlo Nicon + 2024-05-01T15:30:00.000Z + + + Ali Sherief + 2024-05-02T07:10:00.000Z + + + Peter Todd + 2024-05-04T17:08:00.000Z + + + Peter Todd + 2024-05-04T17:13:00.000Z + + + Garlo Nicon + 2025-03-31T10:48:00.000Z + + + Saint Wenhao + 2025-04-25T17:19:00.000Z + + @@ -171,17 +216,15 @@ - python-feedgen + 2 Combined summary - The Future of Bitcoin Testnet - 2025-04-30T02:48:25.303535+00:00 + 2025-09-26T14:29:01.434702+00:00 + 2025-04-25T17:19:00+00:00 The discourse surrounding the future and functionality of Bitcoin's testnet3 brings to light several pressing issues and proposals for its evolution. Testnet3, after 13 years of operation and reaching a block height of approximately 2.5 million, finds itself at a crossroads due to a significantly reduced block reward and operational challenges arising from an edge case bug that resets the mining difficulty to one. This anomaly has led to operational inconsistencies and raised concerns about the effective distribution of testnet coins, as detailed in Jameson Lopp’s comprehensive analysis available [here](https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/). Furthermore, the network faces exploitation through scammy airdrops and an unintended marketplace where TBTC is actively traded, deviating from its foundational principle that testnet coins should hold no real-world value. - In response to these challenges, several key questions and proposals are presented to the community. The potential for a testnet reset is considered, recognizing the need for substantial notice due to the extensive updates required for production systems. Additionally, addressing the difficulty reset bug emerges as a priority, with suggestions for a straightforward code fix that might necessitate a hard fork. This approach, while potentially disruptive, could naturally integrate into the network's dynamics if executed thoughtfully. The necessity of formalizing this process through a Bitcoin Improvement Proposal (BIP) or adopting a more informal implementation strategy remains a point of debate. - Moreover, the discussion extends to the possibility of deprecating testnet3 in favor of signet, highlighting an ongoing exploration of alternative testing environments that might better serve the needs of the Bitcoin development community. This conversation reflects a broader debate on balancing innovation and stability within Bitcoin's development platforms, emphasizing the importance of community feedback and collaborative decision-making in navigating the future of testnet3. The dialogue ultimately underscores the complexities of managing blockchain networks like Bitcoin, where technical adjustments must consider both their immediate impact and broader implications for developers, miners, and the ecosystem at large. - 2025-04-25T17:19:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2024/combined_bitcoin-bounty-program.xml b/static/bitcoin-dev/May_2024/combined_bitcoin-bounty-program.xml index d646c129f6..b6d8706b68 100644 --- a/static/bitcoin-dev/May_2024/combined_bitcoin-bounty-program.xml +++ b/static/bitcoin-dev/May_2024/combined_bitcoin-bounty-program.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - bitcoin bounty program - 2024-05-07T02:10:27.996247+00:00 - - jeremy 2024-05-06 18:39:00+00:00 - - - Erik Aronesty 2024-05-03 19:59:00+00:00 - + 2025-09-26T14:28:44.160211+00:00 + python-feedgen + + + bitcoin bounty program Erik Aronesty + 2024-05-03T19:59:00.000Z + + + jeremy + 2024-05-06T18:39:00.000Z + + - python-feedgen + 2 Combined summary - bitcoin bounty program - 2024-05-07T02:10:27.996298+00:00 + 2025-09-26T14:28:44.160625+00:00 + 2024-05-06T18:39:00+00:00 In the realm of cryptocurrency development, particularly concerning Bitcoin and its extensions like Litecoin, there's a growing interest in enhancing privacy features through dedicated improvement proposals. The focal point of this interest is the establishment of a bounty program aimed at addressing specific needs within this niche. The initiative seeks to introduce a privacy-layer Pull Request (PR) that either mimics or advances the functionalities found in the Litecoin Bitcoin Improvement Proposal (BIP). This endeavor underlines the importance of not only conceptualizing such improvements but also ensuring their practical applicability and security. - To achieve these objectives, the proposal outlines a two-pronged approach. Firstly, it emphasizes the necessity of conducting a professional cryptographic review of the BIP. This step is crucial for assessing the security measures and viability of the proposed enhancements before they are implemented. It reflects a proactive measure to safeguard against potential vulnerabilities, thereby contributing to the overall robustness of the cryptocurrency infrastructure. Secondly, the initiative calls for the actual coding and implementation of the proposal. This phase translates the theoretical constructs into tangible, operational code, enabling the practical application of the proposed privacy layers. - However, despite the clear objectives and the recognized need for such advancements, there appears to be a notable gap in the available resources and platforms that support the posting of bounties specifically tailored to these requirements. This lack of support or guidance for setting up bounties that cater to the unique aspects of cryptocurrency development, such as privacy layer enhancement and cryptographic review, suggests an untapped opportunity. It indicates a space ripe for exploration and development by those involved in or interested in contributing to the security and efficacy of cryptocurrency systems. - 2024-05-06T18:39:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_-Proposal-64-bit-arithmetic-in-Script.xml b/static/bitcoin-dev/May_2025/combined_-Proposal-64-bit-arithmetic-in-Script.xml index 73d0d8f4ea..d2842a9c38 100644 --- a/static/bitcoin-dev/May_2025/combined_-Proposal-64-bit-arithmetic-in-Script.xml +++ b/static/bitcoin-dev/May_2025/combined_-Proposal-64-bit-arithmetic-in-Script.xml @@ -1,45 +1,51 @@ - + 2 Combined summary - [Proposal] 64-bit arithmetic in Script - 2025-05-15T02:53:29.745032+00:00 - - Christian Decker 2025-05-14 08:27:00+00:00 - - - Chris Stewart 2025-05-14 08:23:00+00:00 - - - Christian Decker 2025-05-13 11:44:00+00:00 - - - Chris Stewart 2025-05-13 09:03:00+00:00 - - - Martin Habovštiak 2025-05-12 19:32:00+00:00 - - - Chris Stewart 2025-05-12 16:15:00+00:00 - + 2025-09-26T14:39:15.987107+00:00 + python-feedgen + + + [Proposal] 64-bit arithmetic in Script Chris Stewart + 2025-05-12T16:15:00.000Z + + + Martin Habovštiak + 2025-05-12T19:32:00.000Z + + + Chris Stewart + 2025-05-13T09:03:00.000Z + + + Christian Decker + 2025-05-13T11:44:00.000Z + + + Chris Stewart + 2025-05-14T08:23:00.000Z + + + Christian Decker + 2025-05-14T08:27:00.000Z + + - python-feedgen + 2 Combined summary - [Proposal] 64-bit arithmetic in Script - 2025-05-15T02:53:29.745094+00:00 + 2025-09-26T14:39:15.988012+00:00 + 2025-05-14T08:27:00+00:00 The email exchanges delve into the development and proposed enhancements within Bitcoin's scripting capabilities, emphasizing the integration and potential deployment of new opcodes as part of Tapscript improvements. The discussion broadly covers the initiative to introduce 64-bit arithmetic capabilities through specific proposals, aiming to significantly impact scripting functionalities within the Bitcoin network. This initiative focuses on facilitating broad consensus changes, with particular attention given to deploying these opcodes strategically to ensure backward compatibility and enhance script upgrade efficiency. Among the highlighted proposals are OP_{IN,OUT}_AMOUNT, OP_VAULT, and OP_CHECKCONTRACTVERIFY (OP_CCV), leveraging OP_SUCCESSx semantics for redefining existing opcode behaviors in a manner that supports parallel feature shipping. - The conversation also touches upon cryptographic resilience against emerging quantum computing threats, acknowledging while 64-bit arithmetic suffices for current applications like amount locks, the future might necessitate exploring arbitrary precision. The technical limitations within Script, notably the lack of looping functionalities, pose challenges to iterating over and summing all transaction elements, which invites further exploration of alternative approaches to expand Script's functional scope. External resources such as GitHub links and StackExchange posts are referenced, offering additional insights into the BIP proposal's specifics, deployment strategies, and the broader implications of these technical enhancements. - The discourse extends to concerns about the clarity and direction of the proposal, especially its adherence to traditional hardfork processes due to necessary alterations in the leaf version and the proposition of OP_SUCCESSX as an innovative solution. Questions arise regarding the decision to limit upgrades to 64 bits instead of expanding to 256 bits, which could offer enhanced benefits for cryptographic applications. The focus on pushing sums onto the stack without addressing individual output capabilities raises critical perspectives on the proposal’s scope and its limitations. The soft fork aims to extend the numerical capabilities of Script far beyond its current limits, maintaining Bitcoin's original encoding formats and arithmetic semantics while significantly increasing precision. - Chris's communication highlights this enhancement as foundational groundwork for integrating monetary amounts into Script, with several prototype proposals already explored for incorporating amount locks. This narrative underscores the ongoing efforts within the Bitcoin development community to bolster the scripting language's functionality, reflecting a concerted effort toward technical advancements that promise significant implications for future developments. - 2025-05-14T08:27:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml b/static/bitcoin-dev/May_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml index b787d0798f..15ad34de30 100644 --- a/static/bitcoin-dev/May_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml +++ b/static/bitcoin-dev/May_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin.xml @@ -1,95 +1,23 @@ - + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747215+00:00 - - conduition 2025-08-09 19:53:00+00:00 - - - conduition 2025-07-15 13:53:00+00:00 - - - Jameson Lopp 2025-07-13 21:26:00+00:00 - - - Pieter Wuille 2025-07-13 19:28:00+00:00 - - - Boris Nagaev 2025-07-13 17:51:00+00:00 - - - Ethan Heilman 2025-07-13 16:01:00+00:00 - - - Or Sattath 2025-07-13 15:38:00+00:00 - - - Boris Nagaev 2025-07-13 14:20:00+00:00 - - - Jameson Lopp 2025-07-13 12:34:00+00:00 - - - Boris Nagaev 2025-07-13 01:39:00+00:00 - - - Jameson Lopp 2025-06-08 14:04:00+00:00 - - - waxwing/ AdamISZ 2025-06-07 13:28:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 21:15:00+00:00 - - - Sjors Provoost 2025-05-28 07:46:00+00:00 - - - waxwing/ AdamISZ 2025-05-28 01:07:00+00:00 - - - ArmchairCryptologist 2025-05-26 15:40:00+00:00 - - - Agustin Cruz 2025-05-26 00:32:00+00:00 - - - Dustin Ray 2025-05-25 23:03:00+00:00 - - - conduition 2025-05-25 19:03:00+00:00 - - - Agustin Cruz 2025-03-24 11:19:00+00:00 - - - AstroTown 2025-03-22 19:02:00+00:00 - - - Sjors Provoost 2025-03-18 12:48:00+00:00 - - - Jameson Lopp 2025-03-17 13:28:00+00:00 - - - Matt Corallo 2025-03-17 12:00:00+00:00 - - - IdeA 2025-03-16 22:56:00+00:00 - - - Jameson Lopp 2025-03-16 21:25:00+00:00 - - - Jameson Lopp 2025-03-16 19:44:00+00:00 - - - Jameson Lopp 2025-03-16 18:03:00+00:00 - - - Jameson Lopp 2025-03-16 14:15:00+00:00 - + 2025-09-26T14:39:22.393742+00:00 + python-feedgen + + + Or Sattath + 2025-07-13T15:38:00.000Z + + + conduition' + 2025-07-15T13:53:00.000Z + + + conduition' + 2025-08-09T19:53:00.000Z + + @@ -119,21 +47,17 @@ - python-feedgen + 2 Combined summary - Against Allowing Quantum Recovery of Bitcoin - 2025-08-13T02:57:56.747403+00:00 + 2025-09-26T14:39:22.394331+00:00 + 2025-08-09T19:53:00+00:00 The discourse delves into the intricate challenges and potential approaches for integrating post-quantum cryptography within Bitcoin's framework, highlighting a proactive stance towards enhancing security against quantum computing threats. A notable proposal involves incorporating a form of post-quantum cryptography, specifically through an OP_HASHBASEDSIG mechanism, potentially utilizing SPHINCS+, to embed quantum-resistant public keys into wallet outputs. This suggestion underscores the urgency of preparing for quantum advancements well in advance, advocating for the embedding of these public keys at least a decade prior to any enforcement action to ensure ample safety margins. - The dialogue further explores the ethical and practical considerations surrounding the handling of Bitcoin funds that may become vulnerable to quantum decryption. The debate oscillates between two primary courses of action: leaving such funds accessible, thereby susceptible to potential quantum theft, or proactively rendering them unspendable to preemptively secure them against quantum capabilities. This discussion touches upon core Bitcoin principles including censorship resistance, forward compatibility, and conservatism. The ethical implications are profound, weighing the prevention of economic disruption against the fairness and property rights implications of either allowing or preventing quantum-enabled theft. - Historical precedents within the Bitcoin protocol's evolution serve as reference points for this debate, suggesting a tendency towards remedying vulnerabilities rather than exploiting them. The conversation acknowledges the complexity of incentivizing the ecosystem-wide adoption of quantum-resistant technologies through measures possibly as radical as burning vulnerable coins. - Furthermore, the exchange considers the broader implications of quantum recovery and the potential redistribution of wealth from those without access to quantum technology to those who might achieve quantum supremacy. This raises significant questions about the balance between ensuring long-term security and adhering to Bitcoin's foundational principles of decentralization and user sovereignty. - In addressing the potential quantum threat, the dialogue encapsulates a meticulous examination of both the technical feasibility of implementing quantum-resistant cryptographic methods and the philosophical underpinnings guiding these decisions. It reflects an ongoing effort among developers and stakeholders to navigate the evolving landscape of digital currency security thoughtfully, emphasizing the need for community consensus and careful consideration of Bitcoin's core values in the face of emerging technological challenges. - 2025-08-09T19:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_BIP-Proposal-Define-Bitcoin-Subunits-as-Satoshis-Sats.xml b/static/bitcoin-dev/May_2025/combined_BIP-Proposal-Define-Bitcoin-Subunits-as-Satoshis-Sats.xml index b7d74679be..ab9719b7e4 100644 --- a/static/bitcoin-dev/May_2025/combined_BIP-Proposal-Define-Bitcoin-Subunits-as-Satoshis-Sats.xml +++ b/static/bitcoin-dev/May_2025/combined_BIP-Proposal-Define-Bitcoin-Subunits-as-Satoshis-Sats.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - BIP Proposal: Define Bitcoin Subunits as Satoshis/Sats - 2025-05-04T02:58:58.623663+00:00 - - Jakub Szwedo 2025-05-02 20:54:00+00:00 - - - Lucas André 2025-04-29 22:10:00+00:00 - - - OceanSlim 2025-04-29 12:18:00+00:00 - + 2025-09-26T14:39:09.571317+00:00 + python-feedgen + + + BIP Proposal: Define Bitcoin Subunits as Satoshis/Sats 'OceanSlim' + 2025-04-29T12:18:00.000Z + + + Lucas André + 2025-04-29T22:10:00.000Z + + + Jakub Szwedo + 2025-05-02T20:54:00.000Z + + - python-feedgen + 2 Combined summary - BIP Proposal: Define Bitcoin Subunits as Satoshis/Sats - 2025-05-04T02:58:58.623710+00:00 + 2025-09-26T14:39:09.571837+00:00 - The email highlights a proposal to integrate accessibility and voice/UI guidance into a Bitcoin Improvement Proposal (BIP) aimed at standardizing the terminology around Bitcoin's smallest unit. This suggested addition aims to make digital communication more inclusive, particularly for users of assistive technologies. It outlines a detailed approach towards ensuring that numerical values are accessible in screen readers, voice assistants, and other accessible interfaces. For instance, it recommends converting "1 sat" to "one satoshi" and provides a phonetic transcription to aid in pronunciation by speech-based technologies. To support these guidelines, it references resources on the International Phonetic Alphabet and a phonetics conversion tool, which could be instrumental in developing comprehensive accessibility standards. - -Furthermore, the email addresses the core purpose of the proposed BIP, which is to formally recognize "satoshi" as the standard term for the smallest Bitcoin unit, and "satoshis" for its plural form, with "sats" as an abbreviation. This effort seeks to eliminate inconsistencies in the terminology's usage across different platforms, without altering Bitcoin's unit structure. It distinguishes this BIP from previous proposals, such as BIP-176 and BIP-177, which focused on denomination changes rather than terminology standardization. The proposer encourages feedback and suggestions from the community to refine the proposal, which is available for review. This initiative underscores the importance of standardizing digital currency terminology while ensuring accessibility for all users, reflecting a commitment to inclusivity in technological development. 2025-05-02T20:54:00+00:00 + The email highlights a proposal to integrate accessibility and voice/UI guidance into a Bitcoin Improvement Proposal (BIP) aimed at standardizing the terminology around Bitcoin's smallest unit. This suggested addition aims to make digital communication more inclusive, particularly for users of assistive technologies. It outlines a detailed approach towards ensuring that numerical values are accessible in screen readers, voice assistants, and other accessible interfaces. For instance, it recommends converting "1 sat" to "one satoshi" and provides a phonetic transcription to aid in pronunciation by speech-based technologies. To support these guidelines, it references resources on the International Phonetic Alphabet and a phonetics conversion tool, which could be instrumental in developing comprehensive accessibility standards. +Furthermore, the email addresses the core purpose of the proposed BIP, which is to formally recognize "satoshi" as the standard term for the smallest Bitcoin unit, and "satoshis" for its plural form, with "sats" as an abbreviation. This effort seeks to eliminate inconsistencies in the terminology's usage across different platforms, without altering Bitcoin's unit structure. It distinguishes this BIP from previous proposals, such as BIP-176 and BIP-177, which focused on denomination changes rather than terminology standardization. The proposer encourages feedback and suggestions from the community to refine the proposal, which is available for review. This initiative underscores the importance of standardizing digital currency terminology while ensuring accessibility for all users, reflecting a commitment to inclusivity in technological development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml b/static/bitcoin-dev/May_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml index 448deb381d..dab411d1c4 100644 --- a/static/bitcoin-dev/May_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml +++ b/static/bitcoin-dev/May_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP39 Extension for Manual Seed Phrase Creation - 2025-07-01T05:38:58.785596+00:00 + 2025-09-26T14:38:50.293513+00:00 + python-feedgen Russell OConnor 2025-06-04 17:45:00+00:00 @@ -31,19 +32,16 @@ - python-feedgen + 2 Combined summary - BIP39 Extension for Manual Seed Phrase Creation - 2025-07-01T05:38:58.785663+00:00 + 2025-09-26T14:38:50.293679+00:00 + 2025-06-04T17:45:00+00:00 The discussion explores the nuances and potential improvements to the BIP39 checksum mechanism, focusing on alternative methods for generating and verifying mnemonic phrases. The conversation begins with an acknowledgment of the possible advantages in manually generating randomness over relying on computer chips' hidden processes. It introduces BIP-93, also known as codex32, as a protocol that supports both human and computer-generated randomness, facilitating secret sharing and emphasizing transparency in the generation process. This approach addresses concerns about the opacity of current systems and suggests a method that could enhance user trust and security. - The dialogue further delves into the practical aspects of mnemonic phrase creation, proposing a 16-word seed phrase method that bypasses the traditional checksum requirement. This method involves selecting words from a predefined list, aiming to simplify the process for users while maintaining security through initial xpub confirmation. The proposed solution underscores the importance of simplicity in onboarding new users to cryptocurrency, suggesting that reducing friction in this process could significantly impact adoption rates. - Moreover, the correspondence highlights a broader discourse on the utility and implementation of checksums in mnemonic phrases, questioning their necessity, especially in contexts where entropy is manually generated. It presents an innovative approach that utilizes a subset of words to encode both entropy and derivation paths within a 16-word phrase, offering a potential revision or supplement to the existing BIP39 standard. This methodology not only simplifies the user experience by minimizing technical barriers but also retains the security benefits of checksums through strategic word selection and encoding of metadata. - In essence, the emails collectively advocate for more transparent, user-friendly approaches to cryptographic security, specifically in the realm of mnemonic phrase generation and verification. They propose concrete methods and protocols, such as codex32 and a revised application of the BIP39 wordlist, to achieve these objectives, highlighting the ongoing evolution of cryptocurrency technologies towards greater accessibility and reliability. - 2025-06-04T17:45:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Censorship-Resistant-Transaction-Relay-Taking-out-the-garbage-man-.xml b/static/bitcoin-dev/May_2025/combined_Censorship-Resistant-Transaction-Relay-Taking-out-the-garbage-man-.xml index 567b45d919..79cbc8609c 100644 --- a/static/bitcoin-dev/May_2025/combined_Censorship-Resistant-Transaction-Relay-Taking-out-the-garbage-man-.xml +++ b/static/bitcoin-dev/May_2025/combined_Censorship-Resistant-Transaction-Relay-Taking-out-the-garbage-man-.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Censorship Resistant Transaction Relay - Taking out the garbage(man) - 2025-07-01T05:46:36.202349+00:00 - - Rijndael 2025-06-06 17:38:00+00:00 - - - Sjors Provoost 2025-06-05 13:29:00+00:00 - - - Peter Todd 2025-06-05 12:16:00+00:00 - - - Peter Todd 2025-06-05 11:59:00+00:00 - - - Chris Guida 2025-06-04 20:16:00+00:00 - - - Chris Guida 2025-06-04 20:00:00+00:00 - - - Chris Guida 2025-06-04 18:44:00+00:00 - - - Sjors Provoost 2025-06-03 20:32:00+00:00 - - - Peter Todd 2025-06-03 17:58:00+00:00 - - - Sjors Provoost 2025-06-03 17:51:00+00:00 - - - Peter Todd 2025-06-03 17:41:00+00:00 - - - Sjors Provoost 2025-06-03 17:00:00+00:00 - - - Sjors Provoost 2025-06-03 06:50:00+00:00 - - - Chris Guida 2025-06-03 02:52:00+00:00 - - - John Carvalho 2025-05-27 11:37:00+00:00 - - - Peter Todd 2025-05-27 11:16:00+00:00 - + 2025-09-26T14:39:11.758154+00:00 + python-feedgen + + + Censorship Resistant Transaction Relay - Taking out the garbage(man) Peter Todd + 2025-05-27T11:16:00.000Z + + + John Carvalho + 2025-05-27T11:37:00.000Z + + + Chris Guida + 2025-06-03T02:52:00.000Z + + + Sjors Provoost + 2025-06-03T06:50:00.000Z + + + Greg Maxwell + 2025-06-03T17:00:00.000Z + + + Peter Todd + 2025-06-03T17:41:00.000Z + + + Sjors Provoost + 2025-06-03T17:51:00.000Z + + + Peter Todd + 2025-06-03T17:58:00.000Z + + + Sjors Provoost + 2025-06-03T20:32:00.000Z + + + Chris Guida + 2025-06-04T18:44:00.000Z + + + Chris Guida + 2025-06-04T20:00:00.000Z + + + Chris Guida + 2025-06-04T20:16:00.000Z + + + Peter Todd + 2025-06-05T11:59:00.000Z + + + Peter Todd + 2025-06-05T12:16:00.000Z + + + Sjors Provoost + 2025-06-05T13:29:00.000Z + + + Rijndael + 2025-06-06T17:38:00.000Z + + @@ -67,17 +86,15 @@ - python-feedgen + 2 Combined summary - Censorship Resistant Transaction Relay - Taking out the garbage(man) - 2025-07-01T05:46:36.202464+00:00 + 2025-09-26T14:39:11.760108+00:00 + 2025-06-06T17:38:00+00:00 In the realm of digital communication, censorship resistance and security are paramount. The introduction of PKDNS leverages the Mainline DHT to provide a robust framework for public-key domains, ensuring that control remains with the keyholder. This system negates the need for blockchain technology while offering functionalities such as dynamic endpoint updates, key associations, and revocable sessions. Two informative Medium articles delve into the intricacies of PKDNS, explaining its role in promoting a censorship-resistant digital landscape and elucidating the Mainline DHT's pivotal function in combating censorship. These publications aim to clarify misconceptions about public-key domains and the technological mechanisms underlying their resistance to censorship. - -Conversely, the bitcoin network faces challenges from sybil attacks aimed at disrupting transaction relaying through "garbageman" nodes. These nodes simulate offering NODE_LIBRE_RELAY service but discard transactions instead, raising operational costs for genuine Libre Relay nodes. The complexity of these attacks highlights the sophisticated strategies employed to manipulate transaction flows within the network. Bitcoin Core's existing defenses, such as the feeler node system, offer a foundation for mitigating these threats by ensuring nodes maintain connections to the most-work chain. Further proposals suggest enhancing this defense mechanism by evaluating peers based on the new transaction fees they advertise, employing cluster mempool functionality, and utilizing set-reconciliation techniques for efficient data sharing among nodes. These strategies aim to improve the network's resilience against such attacks by identifying and avoiding sybil attackers. - +Conversely, the bitcoin network faces challenges from sybil attacks aimed at disrupting transaction relaying through "garbageman" nodes. These nodes simulate offering NODE_LIBRE_RELAY service but discard transactions instead, raising operational costs for genuine Libre Relay nodes. The complexity of these attacks highlights the sophisticated strategies employed to manipulate transaction flows within the network. Bitcoin Core's existing defenses, such as the feeler node system, offer a foundation for mitigating these threats by ensuring nodes maintain connections to the most-work chain. Further proposals suggest enhancing this defense mechanism by evaluating peers based on the new transaction fees they advertise, employing cluster mempool functionality, and utilizing set-reconciliation techniques for efficient data sharing among nodes. These strategies aim to improve the network's resilience against such attacks by identifying and avoiding sybil attackers. Moreover, privacy concerns and the practice of manual peering emerge as significant considerations in strengthening the network's defenses. Direct connections among trusted nodes present a social solution to the technical challenge posed by sybil attacks, underscoring the importance of community trust and cooperation in maintaining the integrity of transaction relaying channels. This multi-faceted approach reflects the bitcoin community's dedication to preserving the network's open and reliable transaction propagation system against sophisticated external threats. - 2025-06-06T17:38:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Draft-BIP-Well-Known-Bitcoin-Identity-Endpoint.xml b/static/bitcoin-dev/May_2025/combined_Draft-BIP-Well-Known-Bitcoin-Identity-Endpoint.xml index a0b4770b66..115a693da5 100644 --- a/static/bitcoin-dev/May_2025/combined_Draft-BIP-Well-Known-Bitcoin-Identity-Endpoint.xml +++ b/static/bitcoin-dev/May_2025/combined_Draft-BIP-Well-Known-Bitcoin-Identity-Endpoint.xml @@ -1,35 +1,40 @@ - + 2 Combined summary - Draft BIP: Well-Known Bitcoin Identity Endpoint - 2025-07-01T05:41:13.631024+00:00 - - Murch 2025-06-02 19:32:00+00:00 - - - hodlinator 2025-06-02 18:20:00+00:00 - - - hodlinator 2025-06-02 12:40:00+00:00 - - - Aviv Barel 2025-05-26 12:50:00+00:00 - + 2025-09-26T14:39:03.162910+00:00 + python-feedgen + + + Draft BIP: Well-Known Bitcoin Identity Endpoint Aviv Bar-el + 2025-05-26T12:50:00.000Z + + + hodlinator' + 2025-06-02T12:40:00.000Z + + + hodlinator' + 2025-06-02T18:20:00.000Z + + + Murch + 2025-06-02T19:32:00.000Z + + - python-feedgen + 2 Combined summary - Draft BIP: Well-Known Bitcoin Identity Endpoint - 2025-07-01T05:41:13.631076+00:00 + 2025-09-26T14:39:03.163556+00:00 - The recent discussions within the Bitcoin Development Mailing List have brought to light AvivB's draft for a Bitcoin Improvement Proposal (BIP) aimed at refining the transaction processes within the Bitcoin ecosystem. The proposal, known as the "Well-Known Bitcoin Identity Endpoint," proposes an innovative approach to enhance on-chain payment transactions by adopting a simple, HTTPS-based protocol. This protocol is designed to facilitate the discovery and retrieval of payment and contact information related to Lightning Addresses. By implementing such a mechanism, the proposal seeks to streamline transaction experiences, making them smoother and more efficient for users. Additionally, it extends the functionality beyond mere payment processing to include various types of payments and identity metadata, thereby broadening its application and utility in the digital currency sphere. - + 2025-06-02T19:32:00+00:00 + The recent discussions within the Bitcoin Development Mailing List have brought to light AvivB's draft for a Bitcoin Improvement Proposal (BIP) aimed at refining the transaction processes within the Bitcoin ecosystem. The proposal, known as the "Well-Known Bitcoin Identity Endpoint," proposes an innovative approach to enhance on-chain payment transactions by adopting a simple, HTTPS-based protocol. This protocol is designed to facilitate the discovery and retrieval of payment and contact information related to Lightning Addresses. By implementing such a mechanism, the proposal seeks to streamline transaction experiences, making them smoother and more efficient for users. Additionally, it extends the functionality beyond mere payment processing to include various types of payments and identity metadata, thereby broadening its application and utility in the digital currency sphere. AvivB's initiative to generalize the method used by Lightning Address emphasizes the potential benefits of simplifying user interactions with blockchain technology. This includes making transaction executions and access to essential information more straightforward. The proposed BIP highlights an ongoing effort to innovate and improve the cryptocurrency community's infrastructure, focusing on user-friendliness and efficiency in Bitcoin payments. Interested parties are encouraged to review and contribute to the refinement of this proposal. The draft BIP, which outlines the specifics of this innovative approach and serves as a basis for further development, is available for public viewing and feedback [here](https://github.com/aviv57/paysats/blob/main/bip/BIPXXX.MD). - Feedback from other programmers, like Murch, points out the importance of clearly differentiating this proposal from existing schemes, such as the Lightning Address and LNURL, to avoid confusion due to similarities in formatting. Moreover, there's an acknowledgment of the need to clarify how the proposed system would communicate paysats distinctly from these existing formats. Such constructive feedback suggests that while the proposal is a solid starting point, further clarification and differentiation could enhance its clarity and effectiveness. - 2025-06-02T19:32:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml b/static/bitcoin-dev/May_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml index a6b106d244..6925b6ff1a 100644 --- a/static/bitcoin-dev/May_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml +++ b/static/bitcoin-dev/May_2025/combined_Hashed-keys-are-actually-fully-quantum-secure.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Hashed keys are actually fully quantum secure - 2025-07-01T05:35:10.635886+00:00 - - conduition 2025-06-02 18:29:00+00:00 - - - Nagaev Boris 2025-05-26 10:03:00+00:00 - - - conduition 2025-05-25 18:22:00+00:00 - - - Martin Habovštiak 2025-03-30 20:16:00+00:00 - - - Martin Habovštiak 2025-03-30 20:11:00+00:00 - - - David A. Harding 2025-03-30 15:41:00+00:00 - - - Lloyd Fournier 2025-03-24 00:24:00+00:00 - - - Erik Aronesty 2025-03-18 16:48:00+00:00 - - - Martin Habovštiak 2025-03-17 11:07:00+00:00 - - - Lloyd Fournier 2025-03-17 10:44:00+00:00 - - - Martin Habovštiak 2025-03-16 20:52:00+00:00 - - - Agustin Cruz 2025-03-16 19:03:00+00:00 - - - Martin Habovštiak 2025-03-16 18:50:00+00:00 - - - Martin Habovštiak 2025-03-16 18:25:00+00:00 - + 2025-09-26T14:38:52.438559+00:00 + python-feedgen + + + Hashed keys are actually fully quantum secure Martin Habovštiak + 2025-03-16T18:25:00.000Z + + + Antoine Poinsot' + 2025-03-16T18:50:00.000Z + + + Agustin Cruz + 2025-03-16T19:03:00.000Z + + + Martin Habovštiak + 2025-03-16T20:52:00.000Z + + + Lloyd Fournier + 2025-03-17T10:44:00.000Z + + + Martin Habovštiak + 2025-03-17T11:07:00.000Z + + + Erik Aronesty + 2025-03-18T16:48:00.000Z + + + Lloyd Fournier + 2025-03-24T00:24:00.000Z + + + David A. Harding + 2025-03-30T15:41:00.000Z + + + Martin Habovštiak + 2025-03-30T20:11:00.000Z + + + Martin Habovštiak + 2025-03-30T20:16:00.000Z + + + conduition' + 2025-05-25T18:22:00.000Z + + + Nagaev Boris + 2025-05-26T10:03:00.000Z + + + conduition' + 2025-06-02T18:29:00.000Z + + @@ -59,23 +76,18 @@ - python-feedgen + 2 Combined summary - Hashed keys are actually fully quantum secure - 2025-07-01T05:35:10.635989+00:00 + 2025-09-26T14:38:52.440146+00:00 + 2025-06-02T18:29:00+00:00 The series of discussions within the Bitcoin Development Mailing List covers a wide range of technical proposals and security concerns aimed at enhancing the resilience of Bitcoin in the face of evolving threats, particularly those posed by quantum computing. One focal point is the exploration of innovative mechanisms to safeguard transactions through cryptographic adjustments, such as employing Quantum Resistant (QR) signatures and committing to these within the blockchain infrastructure. This approach underscores a proactive strategy to prevent potential attackers from exploiting vulnerabilities inherent in current cryptographic practices, especially considering the advent of quantum computing capabilities. - A significant portion of the dialogue delves into the intricacies of implementing these security measures, including the technical feasibility of embedding QR signature commitments in transaction processes. The discussions reveal a consensus on the necessity for a soft fork to introduce such enhancements, highlighting the community's readiness to adapt the Bitcoin protocol to mitigate these advanced threats. The conversation also touches upon the procedural and technical requirements for deploying QR signing algorithms, reflecting a broader commitment to securing the cryptocurrency against irrevocable loss due to quantum attacks. - -Moreover, the dialogue extends into the tactical aspects of ensuring transactional integrity and security. For instance, the concept of providing a "head start" for transactions to preempt quantum computational attacks illustrates a nuanced approach to maintaining the competitiveness and security of legitimate transactions within the network. This idea, coupled with the integration of a robust Replace-By-Fee (RBF) mechanism, represents an adaptive response to the dynamic challenges facing Bitcoin's security framework. - +Moreover, the dialogue extends into the tactical aspects of ensuring transactional integrity and security. For instance, the concept of providing a "head start" for transactions to preempt quantum computational attacks illustrates a nuanced approach to maintaining the competitiveness and security of legitimate transactions within the network. This idea, coupled with the integration of a robust Replace-By-Fee (RBF) mechanism, represents an adaptive response to the dynamic challenges facing Bitcoin's security framework. Additionally, the discussions underscore the importance of collaborative efforts and the exchange of ideas among developers to refine and evolve Bitcoin's defensive strategies. The examination of Taproot's hashing functionalities and its implications for address reuse and system flexibility indicates a deep engagement with both the technical and social dimensions of cryptocurrency security. These conversations illuminate the complexities of balancing technical innovation with practical implementation and user adoption. - Furthermore, the discourse around the potential need for a soft fork to disallow the spending of bare public keys, leveraging the security benefits of Taproot keys against quantum threats, reflects a strategic foresight. This discussion emphasizes the critical role of community consensus in timing and executing such a significant protocol change, underscoring the challenges of navigating the uncertain terrain of quantum computing advancements. - In conclusion, the exchanges within the Bitcoin Development Mailing List highlight a multifaceted approach to enhancing Bitcoin's security. From addressing quantum computing threats with QR signatures to refining transaction mechanisms for improved resilience, the community's engagement with these issues showcases a proactive and collaborative effort to fortify Bitcoin against future vulnerabilities. The ongoing dialogue signifies an acknowledgment of the nuanced challenges at the intersection of technology, security, and consensus-building, laying the groundwork for continued innovation and adaptation in the cryptocurrency's protocol and practices. - 2025-06-02T18:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Introducing-Hourglass.xml b/static/bitcoin-dev/May_2025/combined_Introducing-Hourglass.xml index d3ee97c592..0aa4810b36 100644 --- a/static/bitcoin-dev/May_2025/combined_Introducing-Hourglass.xml +++ b/static/bitcoin-dev/May_2025/combined_Introducing-Hourglass.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Introducing Hourglass - 2025-08-27T02:40:55.584812+00:00 - - Saint Wenhao 2025-08-23 17:49:00+00:00 - - - Hunter Beast 2025-05-04 06:00:00+00:00 - - - Francis Pouliot 2025-05-02 15:45:00+00:00 - - - Saint Wenhao 2025-05-02 13:58:00+00:00 - - - Agustin Cruz 2025-05-01 18:23:00+00:00 - - - Nagaev Boris 2025-05-01 17:38:00+00:00 - - - Jameson Lopp 2025-05-01 11:38:00+00:00 - - - Michael Tidwell 2025-04-30 03:01:00+00:00 - - - Hunter Beast 2025-04-29 22:38:00+00:00 - + 2025-09-26T14:38:58.941924+00:00 + python-feedgen + + + Introducing Hourglass Hunter Beast + 2025-04-29T22:38:00.000Z + + + Michael Tidwell + 2025-04-30T03:01:00.000Z + + + Jameson Lopp + 2025-05-01T11:38:00.000Z + + + Nagaev Boris + 2025-05-01T17:38:00.000Z + + + Agustin Cruz + 2025-05-01T18:23:00.000Z + + + Saint Wenhao + 2025-05-02T13:58:00.000Z + + + Francis Pouliot + 2025-05-02T15:45:00.000Z + + + Hunter Beast + 2025-05-04T06:00:00.000Z + + + Saint Wenhao + 2025-08-23T17:49:00.000Z + + @@ -39,25 +51,19 @@ - python-feedgen + 2 Combined summary - Introducing Hourglass - 2025-08-27T02:40:55.584889+00:00 + 2025-09-26T14:38:58.943010+00:00 + 2025-08-23T17:49:00+00:00 The discussion regarding the handling and security of Bitcoin in the face of potential quantum computing threats reveals a multifaceted approach to preserving the currency's stability and integrity. The conversation begins with an examination of the implications that quantum computing may have on Bitcoin, particularly focusing on Pay-to-PubKey (P2PK) coins. The proposal to limit P2PK spends to one per block is highlighted as a strategy to incite bidding wars among miners, potentially benefiting them through increased transaction fees derived from quantum-retrieved coins. This method is noted for its feasibility without necessitating any soft forks, leveraging existing operations like OP_SIZE combined with either OP_CHECKSEQUENCEVERIFY or OP_CHECKLOCKTIMEVERIFY to restrict coin spendability based on Proof of Work. This approach, detailed on [BitcoinTalk](https://bitcointalk.org/index.php?topic=5551080.msg65724436msg65724436), could enforce a time lock on transactions, varying the unlock period depending on the signature size. - The discourse also covers broader implications of trading volumes and price volatility on Bitcoin's security. Michael Tidwell's email criticizes a proposal to manage Bitcoin’s price through spending restrictions, arguing against viewing price volatility as a security issue due to the market's capacity to absorb significant Bitcoin quantities without destabilizing prices. This argument underscores the inherent price fluctuations within the cryptocurrency market and challenges the notion that artificial controls on spending could enforce price stability. - -Further, the conversation delves into strategies for transitioning Bitcoin to a quantum-resistant framework, suggesting that instead of permanently rendering coins inaccessible ("burning"), they could be temporarily "trapped" using a reversible mechanism. This would allow for a potential return to ECDSA if necessary, ensuring the continuity of historical blockchain transaction verifications. Such strategic foresight emphasizes preserving access to assets under new cryptographic standards, reflecting a cautious approach to future-proofing against quantum vulnerabilities. - +Further, the conversation delves into strategies for transitioning Bitcoin to a quantum-resistant framework, suggesting that instead of permanently rendering coins inaccessible ("burning"), they could be temporarily "trapped" using a reversible mechanism. This would allow for a potential return to ECDSA if necessary, ensuring the continuity of historical blockchain transaction verifications. Such strategic foresight emphasizes preserving access to assets under new cryptographic standards, reflecting a cautious approach to future-proofing against quantum vulnerabilities. The Quantum Resistant Address Migration Proposal (QRAMP) introduces a proactive measure against quantum-capable attackers by mandating the migration of unspent P2PK outputs to quantum-resistant addresses before a specified deadline. This initiative aims to invalidate unmoved coins post-deadline, safeguarding them from quantum exploitation by removing their spendability through consensus, illustrating an aggressive yet decisive strategy to protect the currency from quantum threats. - A nuanced perspective on the tactics a quantum computing capable entity might employ to maximize gains in the cryptocurrency space discusses the benefits of publicly broadcasting transactions to ensure their inclusion by other miners. This contrasts with a private broadcast, which limits UTXO claims to blocks mined by the entity itself. The discussion highlights strategic considerations for such entities, including diversifying UTXOs for broadcasting and self-mining to maintain mining momentum and streamline operations. - Boris Nagaev critiques a proposal aimed at dampening quantum attacks' economic impact, pointing out its inadequacy given the rapid capabilities of quantum computers to exploit cryptographic keys. Nagaev's skepticism extends to the strategy's inability to preemptively address high-value targets likely to be attacked first, indicating a need for a more comprehensive approach to mitigating potential quantum-induced economic shocks. - -Lastly, the dialogue explores the concept of allowing early P2PK coins to be "naturally recycled" without modifying their scripts, advocating for a method that respects Bitcoin's technical, cultural, and moral ethos over more drastic measures. This contemplation reflects on the possible scenarios involving mining pools and quantum computing entities, emphasizing the complex dynamics at play in securing Bitcoin against advanced technological threats without undermining its foundational principles. The significant attention to detail and consideration of various strategies and their implications underscore the community's commitment to navigating the evolving landscape of cryptocurrency security. - 2025-08-23T17:49:00+00:00 +Lastly, the dialogue explores the concept of allowing early P2PK coins to be "naturally recycled" without modifying their scripts, advocating for a method that respects Bitcoin's technical, cultural, and moral ethos over more drastic measures. This contemplation reflects on the possible scenarios involving mining pools and quantum computing entities, emphasizing the complex dynamics at play in securing Bitcoin against advanced technological threats without undermining its foundational principles. The significant attention to detail and consideration of various strategies and their implications underscore the community's commitment to navigating the evolving landscape of cryptocurrency security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork.xml b/static/bitcoin-dev/May_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork.xml index 95faa02616..552d1217dc 100644 --- a/static/bitcoin-dev/May_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork.xml +++ b/static/bitcoin-dev/May_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Post-Quantum commit / reveal Fawkescoin variant as a soft fork - 2025-07-01T05:49:14.290234+00:00 - - conduition 2025-06-05 14:33:00+00:00 - - - Nagaev Boris 2025-06-02 22:50:00+00:00 - - - conduition 2025-06-02 19:34:00+00:00 - - - Jonathan Voss 2025-06-02 18:54:00+00:00 - - - waxwing/ AdamISZ 2025-06-02 17:38:00+00:00 - - - Q C 2025-06-02 15:50:00+00:00 - - - Peter Todd 2025-06-02 11:24:00+00:00 - - - waxwing/ AdamISZ 2025-05-31 16:07:00+00:00 - - - Jonathan Voss 2025-05-30 22:00:00+00:00 - - - Nagaev Boris 2025-05-28 20:24:00+00:00 - - - Sergio Demian Lerner 2025-05-28 18:20:00+00:00 - - - Tadge Dryja 2025-05-28 17:14:00+00:00 - + 2025-09-26T14:39:28.854091+00:00 + python-feedgen + + + Post-Quantum commit / reveal Fawkescoin variant as a soft fork Tadge Dryja + 2025-05-28T17:14:00.000Z + + + Sergio Demian Lerner + 2025-05-28T18:20:00.000Z + + + Nagaev Boris + 2025-05-28T20:24:00.000Z + + + Jonathan Voss + 2025-05-30T22:00:00.000Z + + + waxwing/ AdamISZ + 2025-05-31T16:07:00.000Z + + + Peter Todd + 2025-06-02T11:24:00.000Z + + + Q C + 2025-06-02T15:50:00.000Z + + + waxwing/ AdamISZ + 2025-06-02T17:38:00.000Z + + + Jonathan Voss + 2025-06-02T18:54:00.000Z + + + conduition' + 2025-06-02T19:34:00.000Z + + + Nagaev Boris + 2025-06-02T22:50:00.000Z + + + conduition' + 2025-06-05T14:33:00.000Z + + @@ -51,21 +66,17 @@ - python-feedgen + 2 Combined summary - Post-Quantum commit / reveal Fawkescoin variant as a soft fork - 2025-07-01T05:49:14.290329+00:00 + 2025-09-26T14:39:28.855601+00:00 - In recent discussions among Bitcoin developers, there's been a significant focus on enhancing the cryptocurrency's security in anticipation of advances in quantum computing. A proposed method to address this concern involves a commit/reveal scheme designed to secure Bitcoin transactions against potential quantum computer attacks. This approach is aimed at protecting users' funds by introducing a system where a wallet, potentially compromised by quantum capabilities, would execute a "commitment transaction" followed by a "reveal transaction," thereby moving the funds to a new, quantum-resistant script. This process is intended for wallets finding themselves suddenly vulnerable to quantum threats, ensuring that Bitcoin transactions remain secure and mostly unchanged for everyday use. - + 2025-06-05T14:33:00+00:00 + In recent discussions among Bitcoin developers, there's been a significant focus on enhancing the cryptocurrency's security in anticipation of advances in quantum computing. A proposed method to address this concern involves a commit/reveal scheme designed to secure Bitcoin transactions against potential quantum computer attacks. This approach is aimed at protecting users' funds by introducing a system where a wallet, potentially compromised by quantum capabilities, would execute a "commitment transaction" followed by a "reveal transaction," thereby moving the funds to a new, quantum-resistant script. This process is intended for wallets finding themselves suddenly vulnerable to quantum threats, ensuring that Bitcoin transactions remain secure and mostly unchanged for everyday use. The conversation also touched upon the possibility of incorporating future quantum-resistant (QR) signing algorithms into Bitcoin's existing architecture, like adding a new opcode to tapscript to facilitate QR signing. This would necessitate the creation of a new address type capable of handling both current EC opcodes and future QR algorithms, suggesting a complex yet forward-looking amendment to Bitcoin's security framework. However, concerns were raised regarding the practicality of such solutions, including the necessity of commitments being visible on-chain to prevent duplication and ensure the integrity of the commitment process. This visibility requirement could hinder the aggregation of commitments, thus raising scalability issues. - Another perspective highlighted the potential limitations of Bitcoin as a monetary network if it requires out-of-band payments to validate transactions. The critique suggests that relying on external mechanisms could compromise Bitcoin's self-sufficiency and undermine its foundational principles as a peer-to-peer electronic cash system. This sentiment underscores the importance of developing solutions that maintain Bitcoin's autonomy and inherent value as a decentralized financial system. - Furthermore, the discussion ventured into technical specifics concerning the structure and security of commit/reveal schemes. It addressed potential vulnerabilities to quantum attacks, especially during the reveal phase, and suggested alternatives like Pedersen commitments for their hiding properties, despite their susceptibility to quantum decryption. The discourse reflects a proactive approach to ensuring Bitcoin's resilience against evolving technological threats, emphasizing the need for a secure, quantum-resistant framework that adheres to the cryptocurrency's core objectives and design principles. - In summary, the ongoing dialogue among Bitcoin developers illustrates a concerted effort to preemptively address the challenges posed by quantum computing. By exploring various strategies, from commit/reveal protocols to the integration of quantum-resistant algorithms, the community aims to fortify Bitcoin's security infrastructure for the future. These discussions highlight the critical balance between innovation and pragmatism, striving to protect the cryptocurrency against potential threats while preserving its fundamental characteristics and utility. - 2025-06-05T14:33:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Proposal-to-solve-the-spam-war-configurable-data-blob-relay-policy.xml b/static/bitcoin-dev/May_2025/combined_Proposal-to-solve-the-spam-war-configurable-data-blob-relay-policy.xml index 22c314fb08..f8e35dd755 100644 --- a/static/bitcoin-dev/May_2025/combined_Proposal-to-solve-the-spam-war-configurable-data-blob-relay-policy.xml +++ b/static/bitcoin-dev/May_2025/combined_Proposal-to-solve-the-spam-war-configurable-data-blob-relay-policy.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Proposal to solve the spam war: configurable data blob relay policy - 2025-07-01T05:40:00.780008+00:00 - - Peter Todd 2025-06-02 10:25:00+00:00 - - - Greg Sanders 2025-05-28 13:16:00+00:00 - - - Dave Scotese 2025-05-27 23:10:00+00:00 - - - Jonathan Voss 2025-05-27 16:51:00+00:00 - - - Jonathan Voss 2025-05-27 16:40:00+00:00 - - - Russell OConnor 2025-05-27 16:02:00+00:00 - - - Pieter Wuille 2025-05-27 14:16:00+00:00 - - - Jonathan Voss 2025-05-24 21:07:00+00:00 - + 2025-09-26T14:39:05.275143+00:00 + python-feedgen + + + Proposal to solve the spam war: configurable data blob relay policy Jonathan Voss + 2025-05-24T21:07:00.000Z + + + Pieter Wuille + 2025-05-27T14:16:00.000Z + + + Russell O'Connor' + 2025-05-27T16:02:00.000Z + + + Jonathan Voss + 2025-05-27T16:40:00.000Z + + + Jonathan Voss + 2025-05-27T16:51:00.000Z + + + Dave Scotese + 2025-05-27T23:10:00.000Z + + + Greg Sanders + 2025-05-28T13:16:00.000Z + + + Peter Todd + 2025-06-02T10:25:00.000Z + + @@ -35,21 +46,17 @@ - python-feedgen + 2 Combined summary - Proposal to solve the spam war: configurable data blob relay policy - 2025-07-01T05:40:00.780097+00:00 + 2025-09-26T14:39:05.276166+00:00 + 2025-06-02T10:25:00+00:00 The discourse on the integration of non-monetary data within the Bitcoin blockchain has elicited varied perspectives, particularly focusing on proof-of-publication mechanisms and their implications for the technology's future. The utilization of Bitcoin as a publication layer for high-value use cases like Citrea, alongside its traditional financial utility, underscores the network's robustness in ensuring data permanence. This is contrasted with platforms like Bitmessage, which have struggled to maintain data integrity over time. The emphasis on leveraging Bitcoin's infrastructure for proof-of-publication highlights the criticality of cryptography in validating widespread data dissemination. - Discussions within the Bitcoin Development Mailing List reveal concerns about altering Layer 2 security models through data relocation, potentially impacting the scalability and utility enhancements designed for Bitcoin. There's an acknowledgment of the unremunerated contributions of network maintainers, suggesting a future where miners might indirectly compensate these efforts, thereby fostering a participatory market for data propagation within the Bitcoin ecosystem. This scenario posits a division within the network to balance Bitcoin's dual roles in financial transactions and innovative technological applications without compromising on either function. - Further elaboration on technical proposals reveals an inclination towards integrating Zero-Knowledge Proofs (ZKPs) with Citrea to enhance security and efficiency in validating decentralized data. A proposed additional relay service aims to streamline data distribution without burdening the Layer 2 protocol, suggesting a minimal adoption threshold for effective operation. This approach delineates between ephemeral and monetary data storage, addressing node operators' incentives to maintain network integrity. - The proposal for a new relay service to manage non-financial transactions on the Bitcoin network addresses pragmatic challenges associated with current relay policies. Highlighting inefficiencies in restrictive policies, the discussion advocates for a system aligned with the standardness filters majority of the network adheres to. This model seeks to mitigate potential negative impacts on block propagation speeds, fee estimation, and DoS protection mechanisms, proposing a structured method to incorporate arbitrary data without imposing significant burdens. - The debate extends to philosophical considerations of Bitcoin's design principles, emphasizing the importance of censorship resistance and the accommodation of diverse transaction types. Pieter Todd and others in the community argue for maintaining openness and neutrality, resisting narrowly defined transaction relay criteria. This perspective reflects a broader consensus on embracing Bitcoin's multifaceted utility while addressing the practicalities of incorporating non-monetary data through technical adjustments and policy upgrades. Such developments aim to reconcile differing views within the community, ensuring Bitcoin's continued evolution as both a financial instrument and a platform for technological innovation. - 2025-06-02T10:25:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-29-0.xml b/static/bitcoin-dev/May_2025/combined_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-29-0.xml index 117b0f8b9d..7609f3208a 100644 --- a/static/bitcoin-dev/May_2025/combined_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-29-0.xml +++ b/static/bitcoin-dev/May_2025/combined_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-29-0.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - Public disclosure of one vulnerability affecting Bitcoin Core <29.0 - 2025-05-17T02:44:59.318463+00:00 - - Antoine Poinsot 2025-05-16 14:41:00+00:00 - - - Antoine Poinsot 2025-04-28 19:00:00+00:00 - + 2025-09-26T14:39:01.052408+00:00 + python-feedgen + + + Public disclosure of one vulnerability affecting Bitcoin Core <29.0 'Antoine Poinsot' + 2025-04-28T19:00:00.000Z + + + Antoine Poinsot' + 2025-05-16T14:41:00.000Z + + - python-feedgen + 2 Combined summary - Public disclosure of one vulnerability affecting Bitcoin Core <29.0 - 2025-05-17T02:44:59.318502+00:00 + 2025-09-26T14:39:01.052801+00:00 + 2025-05-16T14:41:00+00:00 A recent security advisory has been issued for Bitcoin Core, pinpointing a low-severity issue that impacts versions of the software prior to 29.0. This version was released two weeks ago, marking an important update for users and developers concerned with maintaining the security and integrity of their operations within the Bitcoin ecosystem. The advisory brings attention to the continuous efforts by the Bitcoin Core team to identify and address vulnerabilities in a timely manner, ensuring the community is informed and can take necessary actions to mitigate risks. - The advisory and further details about this specific vulnerability are accessible on the Bitcoin Core project's website, ensuring transparency and easy access to critical information. This approach reflects the project's commitment to open communication and thoroughness in handling security issues, providing a reliable source for updates and advisories. - Moreover, the Bitcoin Core project has made available its full security disclosure policy, which outlines the protocols and procedures in place for managing, communicating, and resolving security vulnerabilities. This policy is a vital resource for developers, stakeholders, and users of Bitcoin Core, offering insights into the project's systematic approach to security. It lays out how advisories are handled from discovery through to resolution, emphasizing the importance of transparency and responsible management in the digital currency space. Access to the policy is intended to foster a deeper understanding of the project's dedication to security and the measures taken to protect users against potential threats. - 2025-05-16T14:41:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Re-BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml b/static/bitcoin-dev/May_2025/combined_Re-BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml index a96f84e1ae..79eb5c8fee 100644 --- a/static/bitcoin-dev/May_2025/combined_Re-BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml +++ b/static/bitcoin-dev/May_2025/combined_Re-BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml @@ -1,31 +1,60 @@ - + 2 Combined summary - Re: BIP39 Extension for Manual Seed Phrase Creation - 2025-05-26T02:58:21.578058+00:00 - - nerdyrugbyguy 2025-05-25 14:26:00+00:00 - - - pithosian 2025-05-24 20:56:00+00:00 - + 2025-09-26T14:39:20.211785+00:00 + python-feedgen + + + Eric Kvam + 2025-05-23T11:25:00.000Z + + + Kyle Honeycutt + 2025-05-23T14:29:00.000Z + + + Russell O'Connor' + 2025-05-23T20:45:00.000Z + + + Eric Kvam + 2025-05-24T12:33:00.000Z + + + BIP39 Extension for Manual Seed Phrase Creation pithosian + 2025-05-24T20:56:00.000Z + + + nerdyrugbyguy + 2025-05-25T14:26:00.000Z + + + pithosian + 2025-05-25T21:41:00.000Z + + + eric + 2025-06-04T15:26:00.000Z + + + Russell O'Connor' + 2025-06-04T17:45:00.000Z + + - python-feedgen + 2 Combined summary - Re: BIP39 Extension for Manual Seed Phrase Creation - 2025-05-26T02:58:21.578103+00:00 + 2025-09-26T14:39:20.212940+00:00 - The dialogue opens with Eric discussing the complexities and challenges associated with Bitcoin self-custody, highlighting the difficulties even technically adept individuals face with concepts like binary math and checksums. He notes that the reliance on what he terms "black box" solutions—tools whose internal workings are opaque to the user—poses a dilemma in ensuring trustless operation. This situation underscores a broader question about Bitcoin's accessibility: is it meant only for those with technical expertise, or can it be made approachable for the average person? - + 2025-05-25T14:26:00+00:00 + The dialogue opens with Eric discussing the complexities and challenges associated with Bitcoin self-custody, highlighting the difficulties even technically adept individuals face with concepts like binary math and checksums. He notes that the reliance on what he terms "black box" solutions—tools whose internal workings are opaque to the user—poses a dilemma in ensuring trustless operation. This situation underscores a broader question about Bitcoin's accessibility: is it meant only for those with technical expertise, or can it be made approachable for the average person? Eric then presents an idea for a UEFI application designed to generate a seed phrase from entropy input, aiming to make the process more accessible without compromising on security. He outlines the current methods of seed generation, which range from using verifiable open-source tools (white box) to relying on unverifiable ones (black box), as well as more complex procedures involving non-standard entropy import and cross-checking between tools. He suggests that standardizing the format for encoding entropy could simplify these processes, making self-custody more attainable for non-experts. - In a further exploration of the technical aspects, Eric touches upon the use of coin flips for entropy generation, advocating for Von Neumann skew correction to enhance randomness. He explains the necessity of subsequent steps like SHA256 hashing to generate a checksum word, followed by SHA512 HMAC, EC point multiplication, and other operations for deriving child keys and addresses. These steps, while crucial, are deemed too complex for manual execution, indicating the need for automated tools. - Eric also mentions his existing work on a bootable UEFI application that incorporates these principles, suggesting its potential reimplementation as part of a larger project. He asserts that modifying the existing specification for mnemonic generation is unnecessary, emphasizing instead the importance of educating users on the process and the available tools. Additionally, he discusses alternatives like Electrum's Seed Version System and wallet descriptors as means to manage non-entropy metadata, advocating for user education over attempts to obscure critical information. - This exchange encapsulates a nuanced debate within the Bitcoin development community regarding the balance between security, transparency, and user-friendliness in cryptographic tools and practices. While recognizing the value of established protocols and specifications, it calls attention to the ongoing need for innovation and clarity in making digital asset self-custody both secure and accessible to a wider audience. - 2025-05-25T14:26:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Re-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml b/static/bitcoin-dev/May_2025/combined_Re-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml index d59cc1b82a..00db0e542a 100644 --- a/static/bitcoin-dev/May_2025/combined_Re-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml +++ b/static/bitcoin-dev/May_2025/combined_Re-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml @@ -1,29 +1,347 @@ - + 2 Combined summary - Re: [Opt-in full-RBF] Zero-conf apps in immediate danger - 2025-05-07T02:53:30.331398+00:00 - - Anthony Towns 2025-05-06 05:39:00+00:00 - - - Anthony Towns 2025-05-02 10:06:00+00:00 - + 2025-09-26T14:38:56.816647+00:00 + python-feedgen + + + Dario Sneidermanis + 2022-10-07T16:20:00.000Z + + + David A. Harding + 2022-10-07T17:21:00.000Z + + + Greg Sanders + 2022-10-07T17:28:00.000Z + + + Luke Dashjr + 2022-10-07T20:56:00.000Z + + + Dario Sneidermanis + 2022-10-07T21:37:00.000Z + + + alicexbt + 2022-10-08T20:47:00.000Z + + + Pieter Wuille + 2022-10-11T16:18:00.000Z + + + Anthony Towns + 2022-10-12T05:42:00.000Z + + + Pieter Wuille + 2022-10-12T16:11:00.000Z + + + Dario Sneidermanis + 2022-10-12T21:44:00.000Z + + + Anthony Towns + 2022-10-13T04:35:00.000Z + + + linuxfoundation.cndm1 + 2022-10-13T16:07:00.000Z + + + alicexbt + 2022-10-14T02:44:00.000Z + + + John Carvalho + 2022-10-14T10:03:00.000Z + + + Peter Todd + 2022-10-14T15:02:00.000Z + + + Peter Todd + 2022-10-14T15:04:00.000Z + + + Erik Aronesty + 2022-10-14T16:28:00.000Z + + + John Carvalho + 2022-10-15T04:08:00.000Z + + + John Carvalho + 2022-10-15T04:20:00.000Z + + + Anthony Towns + 2022-10-16T08:08:00.000Z + + + Greg Sanders + 2022-10-17T14:25:00.000Z + + + Antoine Riard + 2022-10-17T20:31:00.000Z + + + Antoine Riard + 2022-10-17T21:41:00.000Z + + + Antoine Riard + 2022-10-17T22:14:00.000Z + + + Anthony Towns + 2022-10-18T07:00:00.000Z + + + Antoine Riard + 2022-10-19T03:01:00.000Z + + + alicexbt + 2022-10-19T03:17:00.000Z + + + Sergej Kotliar + 2022-10-19T14:29:00.000Z + + + Erik Aronesty + 2022-10-19T14:45:00.000Z + + + Jeremy Rubin + 2022-10-19T15:43:00.000Z + + + Greg Sanders + 2022-10-19T15:51:00.000Z + + + Sergej Kotliar + 2022-10-19T16:04:00.000Z + + + Greg Sanders + 2022-10-19T16:08:00.000Z + + + Antoine Riard + 2022-10-20T01:37:00.000Z + + + Peter Todd + 2022-10-20T04:05:00.000Z + + + Anthony Towns + 2022-10-20T07:22:00.000Z + + + Sergej Kotliar + 2022-10-20T12:37:00.000Z + + + Sergej Kotliar + 2022-10-20T14:11:00.000Z + + + Ruben Somsen + 2022-10-20T14:14:00.000Z + + + Sergej Kotliar + 2022-10-20T14:17:00.000Z + + + Anthony Towns + 2022-10-20T19:58:00.000Z + + + David A. Harding + 2022-10-20T21:05:00.000Z + + + Greg Sanders + 2022-10-20T21:07:00.000Z + + + Eloy + 2022-10-20T22:02:00.000Z + + + Peter Todd + 2022-10-20T22:08:00.000Z + + + Peter Todd + 2022-10-20T22:13:00.000Z + + + Peter Todd + 2022-10-20T23:18:00.000Z + + + Antoine Riard + 2022-10-21T01:04:00.000Z + + + Sergej Kotliar + 2022-10-21T09:34:00.000Z + + + Sergej Kotliar + 2022-10-21T11:56:00.000Z + + + Sergej Kotliar + 2022-10-21T12:02:00.000Z + + + Greg Sanders + 2022-10-21T14:01:00.000Z + + + Sergej Kotliar + 2022-10-21T14:19:00.000Z + + + Greg Sanders + 2022-10-21T14:47:00.000Z + + + Peter Todd + 2022-10-21T19:33:00.000Z + + + Peter Todd + 2022-10-21T19:35:00.000Z + + + Peter Todd + 2022-10-21T19:43:00.000Z + + + David A. Harding + 2022-10-23T19:20:00.000Z + + + alicexbt + 2022-10-23T20:51:00.000Z + + + Sergej Kotliar + 2022-10-24T07:45:00.000Z + + + Sergej Kotliar + 2022-10-24T07:55:00.000Z + + + AdamISZ + 2022-11-02T15:04:00.000Z + + + ArmchairCryptologist + 2022-11-09T13:19:00.000Z + + + ZmnSCPxj + 2022-11-10T09:35:00.000Z + + + Daniel Lipshitz + 2022-12-01T12:27:00.000Z + + + Erik Aronesty + 2022-12-01T22:03:00.000Z + + + Antoine Riard + 2022-12-02T01:52:00.000Z + + + Peter Todd + 2022-12-02T04:30:00.000Z + + + Daniel Lipshitz + 2022-12-02T06:34:00.000Z + + + Daniel Lipshitz + 2022-12-02T06:59:00.000Z + + + Daniel Lipshitz + 2022-12-02T07:06:00.000Z + + + Peter Todd + 2022-12-03T08:50:00.000Z + + + Daniel Lipshitz + 2022-12-03T11:01:00.000Z + + + Daniel Lipshitz + 2022-12-03T11:51:00.000Z + + + Peter Todd + 2022-12-03T12:12:00.000Z + + + Daniel Lipshitz + 2022-12-03T13:17:00.000Z + + + Daniel Lipshitz + 2022-12-03T14:03:00.000Z + + + [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Daniel Lipshitz + 2022-12-03T14:06:00.000Z + + + angus + 2022-12-05T12:21:00.000Z + + + Anthony Towns + 2025-05-02T10:06:00.000Z + + + Anthony Towns + 2025-05-06T05:39:00.000Z + + - python-feedgen + 2 Combined summary - Re: [Opt-in full-RBF] Zero-conf apps in immediate danger - 2025-05-07T02:53:30.331438+00:00 + 2025-09-26T14:38:56.824319+00:00 - The discussion from a thread on X last year provides valuable insights into the dynamics of Bitcoin and Lightning network transactions, particularly in relation to volume changes, user activity, and transaction sizes. A notable shift in the "relative volume" metric was observed, with bitcoin/lightning volume decreasing from 30%-40% in 2022 to 25%-30% by late 2024. The "monthly active users" metric also reflected a decrease in bitcoin/lightning volume from about 50% to roughly 40% during a similar timeframe, alongside a significant migration from on-chain transactions to those conducted via the Lightning network. - -A distinct difference in behavior between on-chain bitcoin users and lightning users was identified in terms of the "average payment size," where individual on-chain payments were found to be approximately four times greater in value than those made through the Lightning network. Additionally, Bitrefill's decision to stop accepting zero-confirmation (zeroconf) transactions around August or September 2023 was highlighted without clear indication whether this move was triggered by an increase in fraudulent attempts or as a precautionary measure. Analysis of various charts revealed a definite correlation between the decrease in on-chain activity and spikes in transaction fees, though no obvious correlation could be identified between on-chain activity and the period after Bitrefill ceased accepting zeroconf transactions. - + 2025-05-06T05:39:00+00:00 + The discussion from a thread on X last year provides valuable insights into the dynamics of Bitcoin and Lightning network transactions, particularly in relation to volume changes, user activity, and transaction sizes. A notable shift in the "relative volume" metric was observed, with bitcoin/lightning volume decreasing from 30%-40% in 2022 to 25%-30% by late 2024. The "monthly active users" metric also reflected a decrease in bitcoin/lightning volume from about 50% to roughly 40% during a similar timeframe, alongside a significant migration from on-chain transactions to those conducted via the Lightning network. +A distinct difference in behavior between on-chain bitcoin users and lightning users was identified in terms of the "average payment size," where individual on-chain payments were found to be approximately four times greater in value than those made through the Lightning network. Additionally, Bitrefill's decision to stop accepting zero-confirmation (zeroconf) transactions around August or September 2023 was highlighted without clear indication whether this move was triggered by an increase in fraudulent attempts or as a precautionary measure. Analysis of various charts revealed a definite correlation between the decrease in on-chain activity and spikes in transaction fees, though no obvious correlation could be identified between on-chain activity and the period after Bitrefill ceased accepting zeroconf transactions. Furthermore, the impact of using Bitrefill accounts for transactions was discussed as providing some degree of insulation from both on-chain fees and confirmation delays, without any detailed examination on how these practices have evolved over time or their correlation with either the cessation of support for zeroconf transactions or fee spikes. The thread also shed light on the composition of Lightning network's monthly active users, attributing more than half of this activity to business partnerships rather than direct user engagement with Lightning. This suggests that only a small fraction of Lightning payments, estimated between 12.5% and 25%, are made by users who control their own keys, indicating a trend towards business-to-business (B2B) transactions rather than peer-to-peer (P2P) engagements. - This analysis underscores concerns regarding the overall positive impact of Lightning growth on the Bitcoin payments system, especially given the apparent shift towards B2B transactions and away from the P2P, self-banking model that Bitcoin advocates. The implications of the `mempoolfullrbf` default setting change, from false to true in version 28.0 of the Bitcoin network, further complicate this landscape. This change, coupled with the reported adoption rate of approximately 30%-40% for this version as of October last year, raises important questions about its effects on transaction volumes, user satisfaction, and the technical or support adjustments required to navigate these changes. - 2025-05-06T05:39:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Relax-OP-RETURN-standardness-restrictions.xml b/static/bitcoin-dev/May_2025/combined_Relax-OP-RETURN-standardness-restrictions.xml index e4eb3d4c40..9b7b56d056 100644 --- a/static/bitcoin-dev/May_2025/combined_Relax-OP-RETURN-standardness-restrictions.xml +++ b/static/bitcoin-dev/May_2025/combined_Relax-OP-RETURN-standardness-restrictions.xml @@ -1,218 +1,291 @@ - + 2 Combined summary - Relax OP_RETURN standardness restrictions - 2025-05-26T02:57:22.317291+00:00 - - waxwing/ AdamISZ 2025-05-25 15:53:00+00:00 - - - Bob Burnett 2025-05-21 18:12:00+00:00 - - - Pieter Wuille 2025-05-21 17:52:00+00:00 - - - Bob Burnett 2025-05-21 17:19:00+00:00 - - - Pieter Wuille 2025-05-21 14:47:00+00:00 - - - Bob Burnett 2025-05-21 13:38:00+00:00 - - - Sjors Provoost 2025-05-21 07:41:00+00:00 - - - Bob Burnett 2025-05-21 02:10:00+00:00 - - - Greg Maxwell 2025-05-20 23:12:00+00:00 - - - Antoine Poinsot 2025-05-20 16:26:00+00:00 - - - Antoine Poinsot 2025-05-14 15:54:00+00:00 - - - Anthony Towns 2025-05-12 13:47:00+00:00 - - - James OBeirne 2025-05-07 20:42:00+00:00 - - - pithosian 2025-05-07 16:55:00+00:00 - - - Greg Maxwell 2025-05-07 11:32:00+00:00 - - - pithosian 2025-05-07 01:20:00+00:00 - - - Sjors Provoost 2025-05-06 08:56:00+00:00 - - - Greg Maxwell 2025-05-05 23:55:00+00:00 - - - Peter Todd 2025-05-05 21:45:00+00:00 - - - Peter Todd 2025-05-05 21:34:00+00:00 - - - Peter Todd 2025-05-05 21:30:00+00:00 - - - Nagaev Boris 2025-05-05 14:32:00+00:00 - - - Greg Maxwell 2025-05-05 14:05:00+00:00 - - - Greg Maxwell 2025-05-05 11:42:00+00:00 - - - Anthony Towns 2025-05-05 09:18:00+00:00 - - - Bitcoin Error Log 2025-05-05 06:04:00+00:00 - - - Nagaev Boris 2025-05-04 20:04:00+00:00 - - - nsvrn 2025-05-03 05:14:00+00:00 - - - Martin Habovštiak 2025-05-03 02:02:00+00:00 - - - Greg Maxwell 2025-05-02 22:58:00+00:00 - - - Peter Todd 2025-05-02 20:43:00+00:00 - - - Peter Todd 2025-05-02 20:10:00+00:00 - - - Peter Todd 2025-05-02 20:03:00+00:00 - - - /dev /fd 2025-05-02 19:04:00+00:00 - - - Greg Tonoski 2025-05-02 18:56:00+00:00 - - - Peter Todd 2025-05-02 18:29:00+00:00 - - - Greg Maxwell 2025-05-02 17:36:00+00:00 - - - Greg Maxwell 2025-05-02 16:43:00+00:00 - - - nsvrn 2025-05-02 14:37:00+00:00 - - - Bob Burnett 2025-05-02 13:58:00+00:00 - - - Sjors Provoost 2025-05-02 11:16:00+00:00 - - - Anthony Towns 2025-05-02 09:51:00+00:00 - - - Anthony Towns 2025-05-02 06:34:00+00:00 - - - Greg Maxwell 2025-05-02 06:29:00+00:00 - - - PandaCute 2025-05-02 00:14:00+00:00 - - - Antoine Poinsot 2025-05-01 22:40:00+00:00 - - - Nagaev Boris 2025-05-01 19:33:00+00:00 - - - Andrew Toth 2025-05-01 17:40:00+00:00 - - - Chris Guida 2025-05-01 04:57:00+00:00 - - - Anthony Towns 2025-05-01 03:01:00+00:00 - - - Anthony Towns 2025-04-30 16:37:00+00:00 - - - Sjors Provoost 2025-04-30 16:30:00+00:00 - - - Nagaev Boris 2025-04-30 15:37:00+00:00 - - - Chris Guida 2025-04-30 05:39:00+00:00 - - - Jason Hughes 2025-04-30 00:10:00+00:00 - - - Martin Habovštiak 2025-04-29 19:20:00+00:00 - - - Sjors Provoost 2025-04-29 14:51:00+00:00 - - - Jason Hughes (wk) 2025-04-28 16:20:00+00:00 - - - Pieter Wuille 2025-04-26 12:48:00+00:00 - - - Sjors Provoost 2025-04-26 11:45:00+00:00 - - - Luke Dashjr 2025-04-26 11:35:00+00:00 - - - Sjors Provoost 2025-04-26 10:53:00+00:00 - - - Luke Dashjr 2025-04-26 09:50:00+00:00 - - - Peter Todd 2025-04-20 08:43:00+00:00 - - - Antoine Riard 2025-04-18 21:34:00+00:00 - - - Antoine Poinsot 2025-04-18 13:29:00+00:00 - - - Vojtěch Strnad 2025-04-18 13:06:00+00:00 - - - Greg Sanders 2025-04-18 12:54:00+00:00 - - - Sjors Provoost 2025-04-18 12:03:00+00:00 - - - Antoine Poinsot 2025-04-17 18:52:00+00:00 - + 2025-09-26T14:39:31.116996+00:00 + python-feedgen + + + Relax OP_RETURN standardness restrictions 'Antoine Poinsot' + 2025-04-17T18:52:00.000Z + + + Sjors Provoost + 2025-04-18T12:03:00.000Z + + + Greg Sanders + 2025-04-18T12:54:00.000Z + + + Vojtěch Strnad + 2025-04-18T13:06:00.000Z + + + Antoine Poinsot' + 2025-04-18T13:29:00.000Z + + + Antoine Riard + 2025-04-18T21:34:00.000Z + + + Peter Todd + 2025-04-20T08:43:00.000Z + + + Luke Dashjr + 2025-04-26T09:50:00.000Z + + + Sjors Provoost + 2025-04-26T10:53:00.000Z + + + Luke Dashjr + 2025-04-26T11:35:00.000Z + + + Sjors Provoost + 2025-04-26T11:45:00.000Z + + + Pieter Wuille + 2025-04-26T12:48:00.000Z + + + Jason Hughes (wk057) + 2025-04-28T16:20:00.000Z + + + Sjors Provoost + 2025-04-29T14:51:00.000Z + + + Martin Habovštiak + 2025-04-29T19:20:00.000Z + + + Jason Hughes + 2025-04-30T00:10:00.000Z + + + Chris Guida + 2025-04-30T05:39:00.000Z + + + Nagaev Boris + 2025-04-30T15:37:00.000Z + + + Sjors Provoost + 2025-04-30T16:30:00.000Z + + + Anthony Towns + 2025-04-30T16:37:00.000Z + + + Anthony Towns + 2025-05-01T03:01:00.000Z + + + Chris Guida + 2025-05-01T04:57:00.000Z + + + Andrew Toth + 2025-05-01T17:40:00.000Z + + + Nagaev Boris + 2025-05-01T19:33:00.000Z + + + Antoine Poinsot' + 2025-05-01T22:40:00.000Z + + + PandaCute + 2025-05-02T00:14:00.000Z + + + Re: Relax OP_RETURN standardness restrictions Greg Maxwell + 2025-05-02T06:29:00.000Z + + + Anthony Towns + 2025-05-02T06:34:00.000Z + + + Anthony Towns + 2025-05-02T09:51:00.000Z + + + Sjors Provoost + 2025-05-02T11:16:00.000Z + + + Bob Burnett + 2025-05-02T13:58:00.000Z + + + nsvrn' + 2025-05-02T14:37:00.000Z + + + Greg Maxwell + 2025-05-02T16:43:00.000Z + + + Greg Maxwell + 2025-05-02T17:36:00.000Z + + + Peter Todd + 2025-05-02T18:29:00.000Z + + + Greg Tonoski + 2025-05-02T18:56:00.000Z + + + /dev /fd0 + 2025-05-02T19:04:00.000Z + + + Removing OP_Return restrictions: Devil's Advocate Position Peter Todd + 2025-05-02T20:03:00.000Z + + + Peter Todd + 2025-05-02T20:10:00.000Z + + + Re: Relax OP_RETURN standardness restrictions Peter Todd + 2025-05-02T20:43:00.000Z + + + Greg Maxwell + 2025-05-02T22:58:00.000Z + + + Martin Habovštiak + 2025-05-03T02:02:00.000Z + + + nsvrn' + 2025-05-03T05:14:00.000Z + + + Nagaev Boris + 2025-05-04T20:04:00.000Z + + + Bitcoin Error Log + 2025-05-05T06:04:00.000Z + + + Anthony Towns + 2025-05-05T09:18:00.000Z + + + Greg Maxwell + 2025-05-05T11:42:00.000Z + + + Greg Maxwell + 2025-05-05T14:05:00.000Z + + + Nagaev Boris + 2025-05-05T14:32:00.000Z + + + Peter Todd + 2025-05-05T21:30:00.000Z + + + Weak blocks give an advantage to large miners Peter Todd + 2025-05-05T21:34:00.000Z + + + Peter Todd + 2025-05-05T21:45:00.000Z + + + Greg Maxwell + 2025-05-05T23:55:00.000Z + + + Sjors Provoost + 2025-05-06T08:56:00.000Z + + + pithosian + 2025-05-07T01:20:00.000Z + + + Greg Maxwell + 2025-05-07T11:32:00.000Z + + + pithosian + 2025-05-07T16:55:00.000Z + + + James O'Beirne + 2025-05-07T20:42:00.000Z + + + Anthony Towns + 2025-05-12T13:47:00.000Z + + + Antoine Poinsot' + 2025-05-14T15:54:00.000Z + + + Antoine Poinsot' + 2025-05-20T16:26:00.000Z + + + Greg Maxwell + 2025-05-20T23:12:00.000Z + + + Bob Burnett + 2025-05-21T02:10:00.000Z + + + Sjors Provoost + 2025-05-21T07:41:00.000Z + + + Bob Burnett + 2025-05-21T13:38:00.000Z + + + Pieter Wuille + 2025-05-21T14:47:00.000Z + + + Bob Burnett + 2025-05-21T17:19:00.000Z + + + Pieter Wuille + 2025-05-21T17:52:00.000Z + + + Bob Burnett + 2025-05-21T18:12:00.000Z + + + waxwing/ AdamISZ + 2025-05-25T15:53:00.000Z + + @@ -283,17 +356,15 @@ - python-feedgen + 2 Combined summary - Relax OP_RETURN standardness restrictions - 2025-05-26T02:57:22.317755+00:00 + 2025-09-26T14:39:31.123860+00:00 + 2025-05-25T15:53:00+00:00 The ongoing discussions within the Bitcoin Development Mailing List have brought to light several key points regarding the use and regulation of OP_RETURN outputs in Bitcoin transactions. Initially, the standardness rules were established with the intention of discouraging the blockchain from being used as a data storage system, aiming to make data embedding slightly inconvenient while still allowing for an alternative that was less harmful than other methods. These rules include limiting transactions to no more than one OP_RETURN output, which must also be under 83 bytes. However, developers have creatively found ways around these limitations, as exemplified by the Citrea bridge named Clementine, which uses Taproot outputs to embed data. - This inventive approach underscores the challenges of enforcing restrictions meant to discourage certain practices within the Bitcoin network. The effectiveness of these measures has been called into question, as they have inadvertently encouraged less desirable behaviors without significantly deterring the storage of arbitrary data on the blockchain. In response to these challenges, there is a proposal to remove restrictions related to OP_RETURN outputs. The proposed changes include eliminating the limit on the size of scriptPubKey for OP_RETURN outputs as an initial step, followed by removing the limitation on the number of OP_RETURN outputs per transaction. This approach is aimed at ceasing the promotion of harmful practices within the network by adjusting the standardness rules to better accommodate the evolving needs of various cryptographic schemes and protocols utilizing the blockchain. - These discussions reflect the dynamic nature of blockchain technology development and highlight the need for continuous adaptation of the network's regulatory framework to support innovation. By reconsidering the limitations placed on OP_RETURN outputs, the Bitcoin development community is exploring ways to optimize the blockchain's functionality while maintaining its integrity and security. The dialogue emphasizes the importance of balancing the encouragement of technological advancements with the prevention of misuse, illustrating the complexities involved in managing a decentralized digital currency like Bitcoin. - 2025-05-25T15:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Removing-checkpoints-in-Bitcoin-Core-v30.xml b/static/bitcoin-dev/May_2025/combined_Removing-checkpoints-in-Bitcoin-Core-v30.xml index 31dff304f0..0d968c52c1 100644 --- a/static/bitcoin-dev/May_2025/combined_Removing-checkpoints-in-Bitcoin-Core-v30.xml +++ b/static/bitcoin-dev/May_2025/combined_Removing-checkpoints-in-Bitcoin-Core-v30.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Removing checkpoints in Bitcoin Core v30 - 2025-05-03T02:57:40.508553+00:00 - - eric 2025-05-02 21:16:00+00:00 - - - Sjors Provoost 2025-04-28 16:25:00+00:00 - - - Sjors Provoost 2025-04-28 11:34:00+00:00 - + 2025-09-26T14:39:26.660645+00:00 + python-feedgen + + + Removing checkpoints in Bitcoin Core v30 Sjors Provoost + 2025-04-28T11:34:00.000Z + + + Sjors Provoost + 2025-04-28T16:25:00.000Z + + + eric + 2025-05-02T21:16:00.000Z + + - python-feedgen + 2 Combined summary - Removing checkpoints in Bitcoin Core v30 - 2025-05-03T02:57:40.508598+00:00 + 2025-09-26T14:39:26.661228+00:00 - In a comprehensive discussion on the Bitcoin Development Mailing List, the subject of checkpoints in the Bitcoin protocol was thoroughly examined. Checkpoints, initially implemented to safeguard against Denial of Service (DoS) attacks, have become a focal point due to their perceived potential to enhance performance. This has raised concerns over the possibility that their misuse for performance improvements could prompt the development of alternative Bitcoin Core or Libbitcoin versions exploiting "honest" checkpoints alongside a UTXO snapshot for accelerated performance. An experiment conducted on an M4 MacBook to evaluate the impact of checkpoints on Initial Block Download (IBD) times revealed that the difference in time with and without checkpoints up to block 295,000 was minimal, suggesting that the early blocks constituting only 3% of all transactions do not significantly benefit from checkpointing in terms of signature verification times. Moreover, it was argued that loading a UTXO snapshot at checkpoint height might offer a modest speedup, but this would only marginally improve efficiency. - -The conversation also delved into the `-assumevalid` feature as an alternative to checkpoints, suggesting its replacement with a combination of AssumeUTXO and SwiftSync to allow more efficient background validation while maintaining full validation capabilities. This proposal aims to boost blockchain performance without overly depending on checkpoints or compromising security against DoS attacks. The upcoming v30 release of Bitcoin Core will see the removal of checkpoints and all related support code, based on the assessment that these measures have become redundant following the introduction of headers pre-sync functionality in v24, which effectively counteracts low proof-of-work header spam attacks. The consensus among developers suggests that new checkpoints are unnecessary for adequate security against such threats. The dialogue also recognized the potential for network splits due to extremely large reorganizations, though such events are considered highly improbable. Despite the humorous attribution of these scenarios to aliens or the NSA, they underline a significant vulnerability in network resilience. The conversation acknowledges the existential risks posed by such catastrophic events to Bitcoin's value and utility, proposing a Bitcoin Improvement Proposal (BIP) to establish protocols for restoring network consistency and recommending the permanent activation of certain soft fork rules from the genesis block in the absence of the last checkpoint header. This proactive approach reflects a commitment to preserving Bitcoin's integrity against theoretical threats to its continuity and stability. Further details and technical rationale behind these decisions can be found through references to [Bitcoin Core Pull Request](https://github.com/bitcoin/bitcoin/pull/0) and [Headers Pre-Sync Functionality](https://github.com/bitcoin/bitcoin/pull/1). 2025-05-02T21:16:00+00:00 + In a comprehensive discussion on the Bitcoin Development Mailing List, the subject of checkpoints in the Bitcoin protocol was thoroughly examined. Checkpoints, initially implemented to safeguard against Denial of Service (DoS) attacks, have become a focal point due to their perceived potential to enhance performance. This has raised concerns over the possibility that their misuse for performance improvements could prompt the development of alternative Bitcoin Core or Libbitcoin versions exploiting "honest" checkpoints alongside a UTXO snapshot for accelerated performance. An experiment conducted on an M4 MacBook to evaluate the impact of checkpoints on Initial Block Download (IBD) times revealed that the difference in time with and without checkpoints up to block 295,000 was minimal, suggesting that the early blocks constituting only 3% of all transactions do not significantly benefit from checkpointing in terms of signature verification times. Moreover, it was argued that loading a UTXO snapshot at checkpoint height might offer a modest speedup, but this would only marginally improve efficiency. +The conversation also delved into the `-assumevalid` feature as an alternative to checkpoints, suggesting its replacement with a combination of AssumeUTXO and SwiftSync to allow more efficient background validation while maintaining full validation capabilities. This proposal aims to boost blockchain performance without overly depending on checkpoints or compromising security against DoS attacks. The upcoming v30 release of Bitcoin Core will see the removal of checkpoints and all related support code, based on the assessment that these measures have become redundant following the introduction of headers pre-sync functionality in v24, which effectively counteracts low proof-of-work header spam attacks. The consensus among developers suggests that new checkpoints are unnecessary for adequate security against such threats. The dialogue also recognized the potential for network splits due to extremely large reorganizations, though such events are considered highly improbable. Despite the humorous attribution of these scenarios to aliens or the NSA, they underline a significant vulnerability in network resilience. The conversation acknowledges the existential risks posed by such catastrophic events to Bitcoin's value and utility, proposing a Bitcoin Improvement Proposal (BIP) to establish protocols for restoring network consistency and recommending the permanent activation of certain soft fork rules from the genesis block in the absence of the last checkpoint header. This proactive approach reflects a commitment to preserving Bitcoin's integrity against theoretical threats to its continuity and stability. Further details and technical rationale behind these decisions can be found through references to [Bitcoin Core Pull Request](https://github.com/bitcoin/bitcoin/pull/0) and [Headers Pre-Sync Functionality](https://github.com/bitcoin/bitcoin/pull/1). - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_SwiftSync-smarter-synchronization-with-hints.xml b/static/bitcoin-dev/May_2025/combined_SwiftSync-smarter-synchronization-with-hints.xml index 1b97857c6e..cc39e4043f 100644 --- a/static/bitcoin-dev/May_2025/combined_SwiftSync-smarter-synchronization-with-hints.xml +++ b/static/bitcoin-dev/May_2025/combined_SwiftSync-smarter-synchronization-with-hints.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - SwiftSync - smarter synchronization with hints - 2025-05-05T02:52:46.682238+00:00 - - Nagaev Boris 2025-05-04 01:06:00+00:00 - - - Ruben Somsen 2025-05-03 16:24:00+00:00 - - - Greg Maxwell 2025-05-03 15:54:00+00:00 - - - Ruben Somsen 2025-05-03 14:55:00+00:00 - - - Greg Maxwell 2025-05-03 14:36:00+00:00 - - - Greg Maxwell 2025-05-03 13:57:00+00:00 - - - Weikeng Chen 2025-05-03 13:53:00+00:00 - - - Ruben Somsen 2025-05-03 13:42:00+00:00 - - - Greg Maxwell 2025-05-03 12:02:00+00:00 - - - Sanket Kanjalkar 2025-05-02 20:23:00+00:00 - - - Saint Wenhao 2025-05-02 19:15:00+00:00 - - - Greg Maxwell 2025-05-02 16:07:00+00:00 - - - Saint Wenhao 2025-05-02 13:38:00+00:00 - - - Ruben Somsen 2025-05-02 10:59:00+00:00 - - - Greg Maxwell 2025-05-02 06:47:00+00:00 - - - Ruben Somsen 2025-04-09 10:10:00+00:00 - + 2025-09-26T14:38:54.587788+00:00 + python-feedgen + + + SwiftSync - smarter synchronization with hints Ruben Somsen + 2025-04-09T10:10:00.000Z + + + Greg Maxwell + 2025-05-02T06:47:00.000Z + + + Ruben Somsen + 2025-05-02T10:59:00.000Z + + + Saint Wenhao + 2025-05-02T13:38:00.000Z + + + Greg Maxwell + 2025-05-02T16:07:00.000Z + + + Saint Wenhao + 2025-05-02T19:15:00.000Z + + + Sanket Kanjalkar + 2025-05-02T20:23:00.000Z + + + Greg Maxwell + 2025-05-03T12:02:00.000Z + + + Ruben Somsen + 2025-05-03T13:42:00.000Z + + + Weikeng Chen + 2025-05-03T13:53:00.000Z + + + Greg Maxwell + 2025-05-03T13:57:00.000Z + + + Greg Maxwell + 2025-05-03T14:36:00.000Z + + + Ruben Somsen + 2025-05-03T14:55:00.000Z + + + Greg Maxwell + 2025-05-03T15:54:00.000Z + + + Ruben Somsen + 2025-05-03T16:24:00.000Z + + + Nagaev Boris + 2025-05-04T01:06:00.000Z + + @@ -67,27 +86,20 @@ - python-feedgen + 2 Combined summary - SwiftSync - smarter synchronization with hints - 2025-05-05T02:52:46.682348+00:00 + 2025-09-26T14:38:54.589442+00:00 + 2025-05-04T01:06:00+00:00 In a series of exchanges on the Bitcoin Development Mailing List, participants delved into various aspects of blockchain technology's security and efficiency. The discussions covered topics from the potential vulnerabilities in transaction ID (TXID) handling to innovative approaches for optimizing synchronization mechanisms among nodes within the network. A key focus was on the cryptographic practices underlying Bitcoin's development, emphasizing the importance of rigorous scrutiny to ensure the robustness and integrity of the cryptocurrency. - One discussion explored the vulnerability associated with truncating transaction identifiers, highlighting a fundamental flaw in limiting TXID lengths. This could potentially enable attackers to negate the impact of accumulators through repeated operations, underscoring the need for careful consideration in cryptographic modifications. Another conversation introduced SwiftSync, an innovative method proposing to streamline the validation process by applying XOR logic to transaction identifiers. This approach aims to enhance network efficiency by reducing the computational load required for transaction verification, marking a significant shift towards optimizing blockchain functionality. - The dialogue further extended into the realm of cryptographic salt's role in securing transactions, suggesting that privacy and uniqueness are paramount for effective application. This detailed examination reflects ongoing debates among developers regarding optimization and security of cryptographic methods, illustrating the community's commitment to refining Bitcoin's underlying mechanisms. - Additionally, concerns were raised about using AES encryption over traditional hashing for proving relationships between unspent transaction outputs (UTXOs), with a focus on collision resistance and the choice of encryption mode. This discussion points to continued efforts in exploring new cryptographic techniques to secure transactions while enhancing privacy. - -Another notable exchange proposed bypassing conventional hashing techniques by directly managing transaction outputs, addressing potential manipulation vulnerabilities and suggesting optimizations like "hashPrevouts" for processing efficiency. This forward-looking perspective advocates for designing protocols that accommodate future enhancements, aiming for more efficient and secure transaction processing. - +Another notable exchange proposed bypassing conventional hashing techniques by directly managing transaction outputs, addressing potential manipulation vulnerabilities and suggesting optimizations like "hashPrevouts" for processing efficiency. This forward-looking perspective advocates for designing protocols that accommodate future enhancements, aiming for more efficient and secure transaction processing. The conversation also touched on optimizing SwiftSync by addressing practical challenges such as ordered block processing and space savings. Participants debated the feasibility of weaker hash functions versus the benefits of proof-of-work mechanisms, balancing efficiency with security requirements. This comprehensive analysis highlights the complex interplay between performance and security in blockchain development. - Greg Maxwell contributed insights on tagged hashes and the implications of hash grinding, emphasizing the need for robust security mechanisms against evolving threats. The discussions underscored the significance of cryptographic principles in maintaining blockchain technology's resilience. - Lastly, SwiftSync's introduction as a near-stateless validation technique marked a pivotal advancement. By utilizing hints about unspent outputs and leveraging hash aggregates, SwiftSync promises substantial speed-ups in blockchain validation without compromising security. The protocol's innovative approach to UTXO set management during Initial Block Download showcases the potential for significant efficiency gains, aligning with the broader goals of optimizing blockchain technology for better performance and reliability. - 2025-05-04T01:06:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Sybil-resistance-in-different-coinjoin-implementations.xml b/static/bitcoin-dev/May_2025/combined_Sybil-resistance-in-different-coinjoin-implementations.xml index 11b5b08883..99d393ea0d 100644 --- a/static/bitcoin-dev/May_2025/combined_Sybil-resistance-in-different-coinjoin-implementations.xml +++ b/static/bitcoin-dev/May_2025/combined_Sybil-resistance-in-different-coinjoin-implementations.xml @@ -1,35 +1,40 @@ - + 2 Combined summary - Sybil resistance in different coinjoin implementations - 2025-07-01T04:19:29.368456+00:00 - - waxwing/ AdamISZ 2025-06-25 12:53:00+00:00 - - - /dev /fd0 2025-06-25 01:55:00+00:00 - - - waxwing/ AdamISZ 2025-06-07 14:39:00+00:00 - - - /dev /fd 2025-05-27 14:29:00+00:00 - + 2025-09-26T14:39:18.099548+00:00 + python-feedgen + + + Sybil resistance in different coinjoin implementations /dev /fd0 + 2025-05-27T14:29:00.000Z + + + waxwing/ AdamISZ + 2025-06-07T14:39:00.000Z + + + /dev /fd0 + 2025-06-25T01:55:00.000Z + + + waxwing/ AdamISZ + 2025-06-25T12:53:00.000Z + + - python-feedgen + 2 Combined summary - Sybil resistance in different coinjoin implementations - 2025-07-01T04:19:29.368525+00:00 + 2025-09-26T14:39:18.100220+00:00 + 2025-06-25T12:53:00+00:00 The discussion revolves around the intricacies of hedging strategies as a means to mitigate the costs associated with timelocking bitcoins, a method employed to enhance security measures within cryptocurrency systems. It is argued that while hedging can offset some volatility-related costs by leveraging futures with minimal leverage, it does not eliminate the opportunity cost incurred during the lock period. This opportunity cost represents the foregone potential gains from alternative investments or uses of the funds. The conversation further explores the complexity of calculating these costs, suggesting that age and value restrictions on transactions could increase the cost of attacks on the system, thereby enhancing security. However, the exact formula for such calculations remains a topic of exploration. - The discourse extends into the realm of Unspent Transaction Outputs (UTXOs) and their role in sybil resistance mechanisms within Bitcoin's ecosystem. A proposed formula for estimating the cost of holding a UTXO is shared, which considers basic properties of a UTXO but acknowledges room for refinement. The dialogue underscores the challenge of imposing significant costs on attackers without disproportionately affecting honest users, especially through mechanisms like fidelity bonds. These bonds are critiqued for potentially complicating privacy and incurring high costs, driving the search for more nuanced solutions. - Further analysis touches upon the dual threats posed by sybil attacks: undermining non-collusion assumptions critical to protocol integrity and overwhelming resources through unrestricted access. The utility of UTXO ownership proofs in mitigating these threats is debated, with a particular focus on the limitations of simple ownership proofs and the potential of combining fidelity bonds with anonymity-enhancing technologies like aut-ct for more effective defense strategies. The conversation concludes with reflections on the practical challenges of coordinating such solutions within the decentralized and privacy-conscious framework of Bitcoin, highlighting the ongoing quest for balance between accessibility, privacy, and security in the digital currency space. - 2025-06-25T12:53:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_The-Tragic-Tale-of-BIP30.xml b/static/bitcoin-dev/May_2025/combined_The-Tragic-Tale-of-BIP30.xml index 89fb7e11f1..df238e40c4 100644 --- a/static/bitcoin-dev/May_2025/combined_The-Tragic-Tale-of-BIP30.xml +++ b/static/bitcoin-dev/May_2025/combined_The-Tragic-Tale-of-BIP30.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - The Tragic Tale of BIP30 - 2025-05-11T02:52:46.926246+00:00 - - Eric Voskuil 2025-05-10 16:55:00+00:00 - - - Sjors Provoost 2025-05-10 16:17:00+00:00 - - - Eric Voskuil 2025-05-10 15:39:00+00:00 - - - eric 2025-05-02 21:09:00+00:00 - - - eric 2025-05-02 21:09:00+00:00 - - - Sjors Provoost 2025-04-29 15:28:00+00:00 - - - Ruben Somsen 2025-04-29 15:11:00+00:00 - - - Eric Voskuil 2025-04-28 12:39:00+00:00 - - - Sjors Provoost 2025-04-28 11:48:00+00:00 - - - eric 2025-04-27 21:01:00+00:00 - - - eric 2025-04-27 18:30:00+00:00 - - - Luke Dashjr 2025-04-27 18:20:00+00:00 - - - Ruben Somsen 2025-04-27 16:45:00+00:00 - + 2025-09-26T14:39:13.872017+00:00 + python-feedgen + + + The Tragic Tale of BIP30 Ruben Somsen + 2025-04-27T16:45:00.000Z + + + Luke Dashjr + 2025-04-27T18:20:00.000Z + + + eric + 2025-04-27T18:30:00.000Z + + + eric + 2025-04-27T21:01:00.000Z + + + Sjors Provoost + 2025-04-28T11:48:00.000Z + + + Eric Voskuil + 2025-04-28T12:39:00.000Z + + + Ruben Somsen + 2025-04-29T15:11:00.000Z + + + Sjors Provoost + 2025-04-29T15:28:00.000Z + + + eric + 2025-05-02T21:09:00.000Z + + + eric + 2025-05-02T21:09:00.000Z + + + Eric Voskuil + 2025-05-10T15:39:00.000Z + + + Sjors Provoost + 2025-05-10T16:17:00.000Z + + + Eric Voskuil + 2025-05-10T16:55:00.000Z + + @@ -55,25 +71,19 @@ - python-feedgen + 2 Combined summary - The Tragic Tale of BIP30 - 2025-05-11T02:52:46.926340+00:00 + 2025-09-26T14:39:13.873633+00:00 + 2025-05-10T16:55:00+00:00 The recent discussions within the Bitcoin Development Mailing List have illuminated several critical aspects and proposed changes to the Bitcoin protocol, focusing on the integrity and future direction of the blockchain. A significant point of contention revolves around the handling of consensus bugs and the role of checkpoints in mitigating potential chain splits. Specifically, the debate touches upon the implications of removing 14 checkpoints, which has been a topic of concern among developers due to the potential for causing chain splits, particularly relating to a consensus bug associated with BIP30. The removal of these checkpoints has led to a broader dialogue about the consistency and stability of the blockchain, urging a reevaluation of how technical decisions impact both the historical consistency and future integrity of the network. - Additionally, an interesting proposal has been introduced regarding the use of BIP54's nLockTime rule as a mechanism for forking the Bitcoin blockchain. This approach, which diverges from existing blocks by not adhering to BIP54 specifications, suggests a novel methodology for initiating forks, thereby highlighting the flexibility of blockchain protocols in accommodating new branches or versions. Such discussions underscore the evolving nature of blockchain technology and the creative avenues through which developers can navigate protocol limitations or design innovative solutions. - The conversation further extends to the technical intricacies of managing the Unspent Transaction Output (UTXO) set and addresses specific challenges such as duplicate transaction IDs (txids) and their impact on blockchain transactions. The dialogue reveals that certain assumptions regarding txid uniqueness have led to reevaluations of protocol effectiveness, specifically BIP30, which was designed to handle exceptions by eliminating duplicate entries. This discussion not only delves into the specifics of blockchain operations but also explores potential fixes and the interplay between different Bitcoin Improvement Proposals (BIPs), such as BIP34 and the Consensus Cleanup amendment, in enhancing protocol efficiency and security. - Moreover, there has been an acknowledgment of the need for a more detailed examination before implementing significant changes like the removal of checkpoints, reflecting a cautious approach to protocol modifications. The discourse emphasizes the balancing act between efficiency, security, and consensus within the cryptocurrency development community, highlighting the complexities involved in protocol development and the continuous effort required to address emerging challenges. - In terms of practical improvements to Bitcoin's transaction handling mechanisms, two specific solutions were proposed to address issues related to transaction overwrites and the creation of redundant UTXOs. These proposals aim to streamline the process by either reversing the effects of overwriting transactions or avoiding the creation of unnecessary UTXOs, although concerns regarding computational efficiency and the increased CPU time required for transaction verification were raised, suggesting that optimization remains a key challenge. - Finally, the discussions touched upon the implications of sunsetting BIP30 in favor of more efficient validation methods like utreexo, SwiftSync, and Zero-Knowledge Proof systems. The inefficiency of BIP30's UTXO set check has prompted suggestions for a system that caches coinbase TXIDs to prevent duplicates, potentially allowing for the complete sunset of BIP30. This reflects the ongoing pursuit of optimizing and securing the Bitcoin protocol against significant threats while maintaining its functionality and resilience. - These conversations within the Bitcoin Development Mailing List illustrate the proactive, forward-thinking approach of the developer community in addressing technical challenges, optimizing blockchain functionality, and ensuring the network's long-term stability and security. - 2025-05-10T16:55:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_Unbreaking-testnet4.xml b/static/bitcoin-dev/May_2025/combined_Unbreaking-testnet4.xml index 126bc0ac4c..26653b86c7 100644 --- a/static/bitcoin-dev/May_2025/combined_Unbreaking-testnet4.xml +++ b/static/bitcoin-dev/May_2025/combined_Unbreaking-testnet4.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Unbreaking testnet4 - 2025-07-06T03:04:39.614598+00:00 - - Garlo Nicon 2025-07-05 04:31:00+00:00 - - - Saint Wenhao 2025-05-17 05:11:00+00:00 - - - pithosian 2025-05-12 20:19:00+00:00 - - - Saint Wenhao 2025-05-12 18:17:00+00:00 - - - pithosian 2025-05-12 12:05:00+00:00 - - - Anthony Towns 2025-05-12 05:21:00+00:00 - - - Garlo Nicon 2025-05-09 13:07:00+00:00 - - - Saint Wenhao 2025-05-06 11:48:00+00:00 - - - Greg Maxwell 2025-05-05 22:25:00+00:00 - - - Sjors Provoost 2025-04-28 18:50:00+00:00 - - - Saint Wenhao 2025-04-28 18:15:00+00:00 - - - Saint Wenhao 2025-04-28 13:33:00+00:00 - - - Sjors Provoost 2025-04-28 12:47:00+00:00 - - - emsit 2025-04-28 11:59:00+00:00 - - - pithosian 2025-04-28 11:48:00+00:00 - - - Jameson Lopp 2025-04-28 10:45:00+00:00 - - - Saint Wenhao 2025-04-28 06:11:00+00:00 - - - Jameson Lopp 2025-04-27 22:49:00+00:00 - - - Saint Wenhao 2025-04-27 11:44:00+00:00 - - - Saint Wenhao 2025-03-31 07:32:00+00:00 - - - Antoine Poinsot 2025-03-24 13:57:00+00:00 - - - Murch 2025-03-24 12:25:00+00:00 - - - Garlo Nicon 2025-03-24 07:00:00+00:00 - - - Murch 2025-03-21 21:20:00+00:00 - - - Melvin Carvalho 2025-03-20 18:58:00+00:00 - - - bitcoindevml.void 2025-03-19 17:03:00+00:00 - - - Melvin Carvalho 2025-03-19 09:11:00+00:00 - - - Garlo Nicon 2025-03-19 08:43:00+00:00 - - - Sjors Provoost 2025-03-19 08:32:00+00:00 - - - Sjors Provoost 2025-03-19 07:56:00+00:00 - - - Melvin Carvalho 2025-03-19 07:01:00+00:00 - - - Antoine Poinsot 2025-03-18 21:34:00+00:00 - - - Antoine Poinsot 2025-03-18 14:29:00+00:00 - + 2025-09-26T14:39:24.543822+00:00 + python-feedgen + + + Unbreaking testnet4 'Antoine Poinsot' + 2025-03-18T14:29:00.000Z + + + Melvin Carvalho + 2025-03-18T21:34:00.000Z + + + Garlo Nicon + 2025-03-19T07:01:00.000Z + + + Sjors Provoost + 2025-03-19T07:56:00.000Z + + + Sjors Provoost + 2025-03-19T08:32:00.000Z + + + Garlo Nicon + 2025-03-19T08:43:00.000Z + + + Melvin Carvalho + 2025-03-19T09:11:00.000Z + + + bitcoin-dev-ml.void867 + 2025-03-19T17:03:00.000Z + + + Melvin Carvalho + 2025-03-20T18:58:00.000Z + + + Murch + 2025-03-21T21:20:00.000Z + + + Garlo Nicon + 2025-03-24T07:00:00.000Z + + + Murch + 2025-03-24T12:25:00.000Z + + + Antoine Poinsot' + 2025-03-24T13:57:00.000Z + + + Saint Wenhao + 2025-03-31T07:32:00.000Z + + + Saint Wenhao + 2025-04-27T11:44:00.000Z + + + Jameson Lopp + 2025-04-27T22:49:00.000Z + + + Saint Wenhao + 2025-04-28T06:11:00.000Z + + + Jameson Lopp + 2025-04-28T10:45:00.000Z + + + pithosian + 2025-04-28T11:48:00.000Z + + + emsit' + 2025-04-28T11:59:00.000Z + + + Sjors Provoost + 2025-04-28T12:47:00.000Z + + + Saint Wenhao + 2025-04-28T13:33:00.000Z + + + Saint Wenhao + 2025-04-28T18:15:00.000Z + + + Sjors Provoost + 2025-04-28T18:50:00.000Z + + + Greg Maxwell + 2025-05-05T22:25:00.000Z + + + Saint Wenhao + 2025-05-06T11:48:00.000Z + + + Garlo Nicon + 2025-05-09T13:07:00.000Z + + + Anthony Towns + 2025-05-12T05:21:00.000Z + + + pithosian + 2025-05-12T12:05:00.000Z + + + Saint Wenhao + 2025-05-12T18:17:00.000Z + + + pithosian + 2025-05-12T20:19:00.000Z + + + Saint Wenhao + 2025-05-17T05:11:00.000Z + + + Garlo Nicon + 2025-07-05T04:31:00.000Z + + @@ -135,21 +171,17 @@ - python-feedgen + 2 Combined summary - Unbreaking testnet4 - 2025-07-06T03:04:39.614808+00:00 + 2025-09-26T14:39:24.547477+00:00 + 2025-07-05T04:31:00+00:00 The ongoing discourse within the Bitcoin development community underscores a collective drive towards refining the blockchain's testnet environment, aiming to bridge the gap between an ideal testing ground and the inherent challenges posed by current operational frameworks. Testnet4, introduced with aspirations to surmount the difficulties encountered in Testnet3—particularly those related to the difficulty reset mechanism—has paradoxically replicated similar challenges. The initiative to enable developers to mine blocks on less powerful devices like laptops, although well-intentioned, inadvertently led to exploitative practices that undermined the testnet's utility. This contradiction highlights a fundamental tension between maintaining a permissionless network, as is characteristic of Proof of Work (PoW) systems, and the necessity for a controlled environment conducive to development, such as that offered by Signet. - The debate extends to the question of how best to evolve the testnet framework without compromising its core objectives. A pivotal suggestion within this dialogue is the elimination of the difficulty reset rule from Testnet4 through a flag day hard fork slated for January 1, 2026. This proposed timeline provides ample opportunity for comprehensive review, integration into upcoming Bitcoin Core releases, and widespread adoption across existing infrastructure. This approach reflects a broader consideration of how to balance the need for an authentic replication of the Bitcoin mainnet against facilitating a practical and accessible platform for developers. - Further discussions have ventured into innovative solutions aimed at enhancing the testnet's functionality, including the development of a decentralized faucet by Antoine Poinsot. This tool represents a significant step towards lowering entry barriers for new developers and streamlining the testing process. Such initiatives underscore a concerted effort within the community to address the testnet's limitations, ensuring it remains a vital resource for fostering innovation and improving the robustness of Bitcoin's testing environments. - In parallel, conversations have also delved into technical aspects concerning the blockchain's code, particularly the `fPowAllowMinDifficultyBlocks` rule and its implications for block addition under specific circumstances. These discussions highlight the intricate nature of blockchain protocol management and the continuous efforts to strike a balance between flexibility, security, and fairness within the network's operation. - Overall, the dialogue within the Bitcoin Development Mailing List encapsulates a dynamic and ongoing process of reflection, critique, and collaborative problem-solving. It signifies a commitment among developers to not only navigate the complexities of blockchain technology but also to envision and implement changes that enhance its sustainability, efficacy, and inclusivity. - 2025-07-05T04:31:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2025/combined_jpeg-resistance-of-various-post-quantum-signature-schemes.xml b/static/bitcoin-dev/May_2025/combined_jpeg-resistance-of-various-post-quantum-signature-schemes.xml index 0b964cff2a..bc9db87d35 100644 --- a/static/bitcoin-dev/May_2025/combined_jpeg-resistance-of-various-post-quantum-signature-schemes.xml +++ b/static/bitcoin-dev/May_2025/combined_jpeg-resistance-of-various-post-quantum-signature-schemes.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - jpeg resistance of various post-quantum signature schemes - 2025-07-01T05:37:43.584764+00:00 - - Q C 2025-06-17 17:42:00+00:00 - - - Q C 2025-05-29 23:20:00+00:00 - - - Bas Westerbaan 2025-05-22 12:57:00+00:00 - - - Hunter Beast 2025-05-21 20:38:00+00:00 - - - Bas Westerbaan 2025-05-21 10:32:00+00:00 - + 2025-09-26T14:39:07.386711+00:00 + python-feedgen + + + jpeg resistance of various post-quantum signature schemes 'Bas Westerbaan' + 2025-05-21T10:32:00.000Z + + + Hunter Beast + 2025-05-21T20:38:00.000Z + + + Bas Westerbaan' + 2025-05-22T12:57:00.000Z + + + Q C + 2025-05-29T23:20:00.000Z + + + Q C + 2025-06-17T17:42:00.000Z + + - python-feedgen + 2 Combined summary - jpeg resistance of various post-quantum signature schemes - 2025-07-01T05:37:43.584821+00:00 + 2025-09-26T14:39:07.387570+00:00 + 2025-06-17T17:42:00+00:00 The discussions and analyses provided in the emails revolve around the intricate aspects of post-quantum cryptography (PQC), focusing on the evaluation of various cryptographic schemes in light of their security, efficiency, and practicality for implementation. A notable topic is the consideration of SLH-DSA within the development of BIP-360, which brings to the forefront the challenges associated with lattice-based cryptography. Despite the potential vulnerabilities, such as those related to novel security assumptions, lattice-based approaches are still valued for their applicability in key agreement protocols, especially in preparing for the advent of quantum computing. - One significant point of discussion is the resistance of different cryptographic schemes to quantum attacks, with a particular emphasis on XMSS. This hash-based signature mechanism is recognized for its robustness against quantum threats, offering a reliable verification process that supports a high volume of messages. However, concerns about XMSS include the risk of signature forgery due to the possible reuse of OTS leaves, underlining the importance of vigilant management of keys and signatures to uphold security integrity. Comparisons among various algorithms, including FALCON, secp256k1 Schnorr signatures, and SLH-DSA, shed light on the trade-offs between performance, signature size, and verification speed, which are crucial for ensuring the feasibility of cryptographic solutions. - The conversations further delve into the ongoing efforts to standardize new variants of SLH-DSA, reflecting a dynamic field that seeks to balance operational demands with security requirements. The dialogue also touches upon the potential deprecation of ML-DSA in favor of FALCON, highlighting the continuous evolution of cryptographic standards. Moreover, the implementation complexities and security considerations of FALCON's signing routine are discussed, along with the broader implications of improved lattice cryptanalysis. - -An intriguing aspect of the discourse is the concept of "jpeg resistance," a term coined to describe a signature scheme's ability to withstand attempts by attackers to create a valid signature and public key pair for a given message. This section explores the resilience of various schemes, including XMSS, XMSSMT, and SLH-DSA, against such manipulation tactics. The analysis reveals how the structure and validation processes of these schemes impact their vulnerability to attacks, emphasizing the nuanced balance required to prevent unauthorized signature fabrication. - +An intriguing aspect of the discourse is the concept of "jpeg resistance," a term coined to describe a signature scheme's ability to withstand attempts by attackers to create a valid signature and public key pair for a given message. This section explores the resilience of various schemes, including XMSS, XMSSMT, and SLH-DSA, against such manipulation tactics. The analysis reveals how the structure and validation processes of these schemes impact their vulnerability to attacks, emphasizing the nuanced balance required to prevent unauthorized signature fabrication. In summary, the detailed examination of different cryptographic schemes within these emails offers valuable insights into the challenges and considerations involved in developing secure, efficient, and scalable solutions for digital transactions in the quantum computing era. The collective wisdom and collaborative efforts of the cryptographic community are underscored as pivotal elements in navigating the complex landscape of cryptographic security and privacy amidst advancing technological capabilities. - 2025-06-17T17:42:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml b/static/bitcoin-dev/Nov_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml index 3e5e66fcdc..2c3084d270 100644 --- a/static/bitcoin-dev/Nov_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml +++ b/static/bitcoin-dev/Nov_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml @@ -1,242 +1,19 @@ - + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger - 2023-08-02T07:48:23.736188+00:00 - - angus 2022-12-05 12:21:44+00:00 - - - Daniel Lipshitz 2022-12-03 14:06:11+00:00 - - - Daniel Lipshitz 2022-12-03 14:03:58+00:00 - - - Daniel Lipshitz 2022-12-03 13:17:16+00:00 - - - Peter Todd 2022-12-03 12:12:02+00:00 - - - Daniel Lipshitz 2022-12-03 11:51:19+00:00 - - - Daniel Lipshitz 2022-12-03 11:01:16+00:00 - - - Peter Todd 2022-12-03 08:50:13+00:00 - - - Daniel Lipshitz 2022-12-02 07:06:26+00:00 - - - Daniel Lipshitz 2022-12-02 06:59:01+00:00 - - - Daniel Lipshitz 2022-12-02 06:34:07+00:00 - - - Peter Todd 2022-12-02 04:30:28+00:00 - - - Antoine Riard 2022-12-02 01:52:46+00:00 - - - Erik Aronesty 2022-12-01 22:03:55+00:00 - - - Daniel Lipshitz 2022-12-01 12:27:16+00:00 - - - ZmnSCPxj 2022-11-10 09:35:18+00:00 - - - ArmchairCryptologist 2022-11-09 13:19:28+00:00 - - - AdamISZ 2022-11-02 15:04:58+00:00 - - - Sergej Kotliar 2022-10-24 07:55:59+00:00 - - - Sergej Kotliar 2022-10-24 07:45:13+00:00 - - - alicexbt 2022-10-23 20:51:16+00:00 - - - David A. Harding 2022-10-23 19:20:41+00:00 - - - Peter Todd 2022-10-21 19:43:33+00:00 - - - Peter Todd 2022-10-21 19:35:24+00:00 - - - Peter Todd 2022-10-21 19:33:46+00:00 - - - Greg Sanders 2022-10-21 14:47:50+00:00 - - - Sergej Kotliar 2022-10-21 14:19:32+00:00 - - - Greg Sanders 2022-10-21 14:01:01+00:00 - - - Sergej Kotliar 2022-10-21 12:02:24+00:00 - - - Sergej Kotliar 2022-10-21 11:56:51+00:00 - - - Sergej Kotliar 2022-10-21 09:34:17+00:00 - - - Antoine Riard 2022-10-21 01:04:24+00:00 - - - Peter Todd 2022-10-20 23:18:16+00:00 - - - Peter Todd 2022-10-20 22:13:15+00:00 - - - Peter Todd 2022-10-20 22:08:17+00:00 - - - Greg Sanders 2022-10-20 21:07:07+00:00 - - - David A. Harding 2022-10-20 21:05:36+00:00 - - - Anthony Towns 2022-10-20 19:58:41+00:00 - - - Sergej Kotliar 2022-10-20 14:17:23+00:00 - - - Ruben Somsen 2022-10-20 14:14:14+00:00 - - - Sergej Kotliar 2022-10-20 14:11:48+00:00 - - - Sergej Kotliar 2022-10-20 12:37:53+00:00 - - - Anthony Towns 2022-10-20 07:22:34+00:00 - - - Peter Todd 2022-10-20 04:05:33+00:00 - - - Antoine Riard 2022-10-20 01:37:25+00:00 - - - Greg Sanders 2022-10-19 16:08:19+00:00 - - - Sergej Kotliar 2022-10-19 16:04:30+00:00 - - - Greg Sanders 2022-10-19 15:51:41+00:00 - - - Jeremy Rubin 2022-10-19 15:43:28+00:00 - - - Erik Aronesty 2022-10-19 14:45:44+00:00 - - - Sergej Kotliar 2022-10-19 14:29:57+00:00 - - - alicexbt 2022-10-19 03:17:51+00:00 - - - Antoine Riard 2022-10-19 03:01:12+00:00 - - - Anthony Towns 2022-10-18 07:00:45+00:00 - - - Antoine Riard 2022-10-17 22:14:52+00:00 - - - Antoine Riard 2022-10-17 21:41:48+00:00 - - - Antoine Riard 2022-10-17 20:31:50+00:00 - - - Greg Sanders 2022-10-17 14:25:33+00:00 - - - Anthony Towns 2022-10-16 08:08:49+00:00 - - - John Carvalho 2022-10-15 04:20:55+00:00 - - - John Carvalho 2022-10-15 04:08:15+00:00 - - - Erik Aronesty 2022-10-14 16:28:49+00:00 - - - Peter Todd 2022-10-14 15:04:56+00:00 - - - Peter Todd 2022-10-14 15:02:25+00:00 - - - John Carvalho 2022-10-14 10:03:21+00:00 - - - alicexbt 2022-10-14 02:44:04+00:00 - - - linuxfoundation.cndm1 at dralias.com 2022-10-13 16:07:19+00:00 - - - Anthony Towns 2022-10-13 04:35:22+00:00 - - - Dario Sneidermanis 2022-10-12 21:44:13+00:00 - - - Pieter Wuille 2022-10-12 16:11:05+00:00 - - - Anthony Towns 2022-10-12 05:42:14+00:00 - - - Pieter Wuille 2022-10-11 16:18:10+00:00 - - - alicexbt 2022-10-08 20:47:52+00:00 - - - Dario Sneidermanis 2022-10-07 21:37:38+00:00 - - - Luke Dashjr 2022-10-07 20:56:21+00:00 - - - Greg Sanders 2022-10-07 17:28:28+00:00 - - - David A. Harding 2022-10-07 17:21:29+00:00 - - - Dario Sneidermanis 2022-10-07 16:20:49+00:00 - + 2025-09-26T14:29:31.515309+00:00 + python-feedgen + + + [bitcoin-dev] Fwd: " Antoine Riard + 2022-12-02T22:35:00.000Z + + + Peter Todd + 2022-12-06T05:03:00.000Z + + @@ -315,13 +92,13 @@ - python-feedgen + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger - 2023-08-02T07:48:23.737154+00:00 + 2025-09-26T14:29:31.515796+00:00 - GAP600, a company specializing in processing cryptocurrency transactions, has processed approximately 15 million transactions with a total value of $2.3 billion USD from January to November 2022. The majority of their clients are payment processors and liquidity providers. However, the CEO of GAP600, Daniel Lipshitz, expressed concern over the potential adoption of full Replace-by-Fee (RBF) as default, as it would make zero-conf acceptance difficult. This could significantly impact GAP600's market share, as they currently process around 1.5 million transactions per month.GAP600 guarantees zero confirmed Bitcoin and other crypto transactions, allowing their customers to recognize zero-conf deposits. They reimburse clients if a transaction they confirmed gets double-spent. However, if full RBF were to become dominant, zero-conf acceptance would be affected. It is unclear how many of GAP600's processed transactions relied on their unconfirmed transaction tools.The email exchange also discussed the services provided by GAP600 to Shapeshift, one of their former clients. Shapeshift no longer uses GAP600's services but occasionally asks for fee recommendations. The conversation highlights the significance of zero-conf transactions in the cryptocurrency industry and raises questions about the implementation and reliance on unconfirmed transaction tools.The discussion on the bitcoin-dev mailing list explores the issue of full RBF and its impact on Bitcoin transactions. There are concerns about the degradation of user experience for 0-conf deposits and the risk of exchange rate changes between fiat and BTC. Various solutions, such as using Child-Pays-for-Parent (CPFP) to lock in FX risk or making the double-spender over-pay, are proposed but have limitations.The conversation emphasizes the need for collaboration between wallet developers, merchant developers, and protocol developers to address these issues and improve the Bitcoin payment experience. Specific implementations of RBF features in various wallets are also discussed, highlighting the need for collaboration to enhance the RBF experience.The risks associated with accepting Bitcoin payments are highlighted, including the zeroconf risk and the FX risk. The conversation mentions the "American call option," where users can make low-fee transactions and wait to see if the BTCUSD rate changes before canceling and making a cheaper transaction. This could potentially abuse the system and harm merchants.Sergej Kotliar, CEO of Bitrefill, raises concerns about the default use of RBF in Bitcoin transactions. He suggests a risk-based approach to determine which payments are non-trivial to reverse, considering user experience. There is also discussion about Lightning Network adoption and the challenges of RBF as a default policy.The bitcoin-dev mailing list recently discussed the relay of full-RBF (replace-by-fee) transactions. One member stated that it is already working well, except for a few percent of hashrate that doesn't accept fullrbf replacement transactions. However, another member disagreed, emphasizing the importance of all full node users trying fullrbf. The first member explained that the relay of full-rbf transactions currently works well due to preferential rbf peering implementations. They personally run four nodes with this feature enabled and haven't seen many non-opt-in doublespends get mined. However, they have observed a few through their Alice OTS calendar, which could increase as miners adopt full-rbf.There are concerns about the gaslighting happening with the advancement of RBF, while merchants wanting to manage their own 0conf risk better is not deemed acceptable. Some argue that miners can facilitate doublespends anyway if the fees are higher. However, proponents of RBF seem to threaten the use case of on-chain Bitcoin being useful at the point-of-sale for merchants and consumers. This may lead to the creation of alternative fee mechanisms and trusted/exclusive mempools where first-seen transactions are respected.According to a tweet by Sergej Kotliar in January 2022, lightning payments account for only 4% compared to on-chain payments, which make up 32%. Bitrefill and similar providers could promote the use of lightning payments by displaying them by default and presenting on-chain payments as a fallback. It would be interesting to know if these services face any obstacles or if they disagree that lightning is an improvement over accepting unconfirmed on-chain transactions from untrusted parties.Pieter Wuille via bitcoin-dev proposed a step towards getting full RBF on the network by allowing experimentation and socializing the notion that developers believe it is time. However, there seems to be confusion about what exactly they believe it is time for. There are two possibilities: (a) deprecating the acceptance of zeroconf transactions on mainnet over the next 6, 12, or 18 months, or (b) switching mainnet mining and relay nodes to full RBF.Pieter Wuille commented on the opt-in flag for full-RBF, stating that adding the flag is a likely step towards wider adoption on the network. However, he believes that the opt-in flag 2022-12-05T12:21:44+00:00 + GAP600, a company specializing in processing cryptocurrency transactions, has processed approximately 15 million transactions with a total value of $2.3 billion USD from January to November 2022. The majority of their clients are payment processors and liquidity providers. However, the CEO of GAP600, Daniel Lipshitz, expressed concern over the potential adoption of full Replace-by-Fee (RBF) as default, as it would make zero-conf acceptance difficult. This could significantly impact GAP600's market share, as they currently process around 1.5 million transactions per month.GAP600 guarantees zero confirmed Bitcoin and other crypto transactions, allowing their customers to recognize zero-conf deposits. They reimburse clients if a transaction they confirmed gets double-spent. However, if full RBF were to become dominant, zero-conf acceptance would be affected. It is unclear how many of GAP600's processed transactions relied on their unconfirmed transaction tools.The email exchange also discussed the services provided by GAP600 to Shapeshift, one of their former clients. Shapeshift no longer uses GAP600's services but occasionally asks for fee recommendations. The conversation highlights the significance of zero-conf transactions in the cryptocurrency industry and raises questions about the implementation and reliance on unconfirmed transaction tools.The discussion on the bitcoin-dev mailing list explores the issue of full RBF and its impact on Bitcoin transactions. There are concerns about the degradation of user experience for 0-conf deposits and the risk of exchange rate changes between fiat and BTC. Various solutions, such as using Child-Pays-for-Parent (CPFP) to lock in FX risk or making the double-spender over-pay, are proposed but have limitations.The conversation emphasizes the need for collaboration between wallet developers, merchant developers, and protocol developers to address these issues and improve the Bitcoin payment experience. Specific implementations of RBF features in various wallets are also discussed, highlighting the need for collaboration to enhance the RBF experience.The risks associated with accepting Bitcoin payments are highlighted, including the zeroconf risk and the FX risk. The conversation mentions the "American call option," where users can make low-fee transactions and wait to see if the BTCUSD rate changes before canceling and making a cheaper transaction. This could potentially abuse the system and harm merchants.Sergej Kotliar, CEO of Bitrefill, raises concerns about the default use of RBF in Bitcoin transactions. He suggests a risk-based approach to determine which payments are non-trivial to reverse, considering user experience. There is also discussion about Lightning Network adoption and the challenges of RBF as a default policy.The bitcoin-dev mailing list recently discussed the relay of full-RBF (replace-by-fee) transactions. One member stated that it is already working well, except for a few percent of hashrate that doesn't accept fullrbf replacement transactions. However, another member disagreed, emphasizing the importance of all full node users trying fullrbf. The first member explained that the relay of full-rbf transactions currently works well due to preferential rbf peering implementations. They personally run four nodes with this feature enabled and haven't seen many non-opt-in doublespends get mined. However, they have observed a few through their Alice OTS calendar, which could increase as miners adopt full-rbf.There are concerns about the gaslighting happening with the advancement of RBF, while merchants wanting to manage their own 0conf risk better is not deemed acceptable. Some argue that miners can facilitate doublespends anyway if the fees are higher. However, proponents of RBF seem to threaten the use case of on-chain Bitcoin being useful at the point-of-sale for merchants and consumers. This may lead to the creation of alternative fee mechanisms and trusted/exclusive mempools where first-seen transactions are respected.According to a tweet by Sergej Kotliar in January 2022, lightning payments account for only 4% compared to on-chain payments, which make up 32%. Bitrefill and similar providers could promote the use of lightning payments by displaying them by default and presenting on-chain payments as a fallback. It would be interesting to know if these services face any obstacles or if they disagree that lightning is an improvement over accepting unconfirmed on-chain transactions from untrusted parties.Pieter Wuille via bitcoin-dev proposed a step towards getting full RBF on the network by allowing experimentation and socializing the notion that developers believe it is time. However, there seems to be confusion about what exactly they believe it is time for. There are two possibilities: (a) deprecating the acceptance of zeroconf transactions on mainnet over the next 6, 12, or 18 months, or (b) switching mainnet mining and relay nodes to full RBF.Pieter Wuille commented on the opt-in flag for full-RBF, stating that adding the flag is a likely step towards wider adoption on the network. However, he believes that the opt-in flag - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Announcement-Full-RBF-Miner-Bounty.xml b/static/bitcoin-dev/Nov_2022/combined_Announcement-Full-RBF-Miner-Bounty.xml index 0365fda69e..ea47e02a04 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Announcement-Full-RBF-Miner-Bounty.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Announcement-Full-RBF-Miner-Bounty.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Announcement: Full-RBF Miner Bounty - 2023-08-02T08:24:00.883108+00:00 - - Anthony Towns 2022-12-13 04:01:50+00:00 - - - Peter Todd 2022-12-10 18:07:18+00:00 - - - 0xB10C 2022-12-10 11:59:05+00:00 - - - Peter Todd 2022-12-09 21:16:20+00:00 - - - 0xB10C 2022-12-09 16:04:05+00:00 - - - Peter Todd 2022-12-06 07:37:27+00:00 - - - Peter Todd 2022-12-06 05:39:40+00:00 - - - El_Hoy 2022-12-06 04:48:07+00:00 - - - El_Hoy 2022-12-05 17:25:29+00:00 - - - Erik Aronesty 2022-12-05 17:00:56+00:00 - - - Michael Folkson 2022-12-05 15:33:37+00:00 - - - Rijndael 2022-12-05 14:12:33+00:00 - - - Greg Sanders 2022-12-05 13:38:58+00:00 - - - El_Hoy 2022-12-05 12:20:58+00:00 - - - Peter Todd 2022-11-15 14:43:25+00:00 - - - Anthony Towns 2022-11-15 05:36:08+00:00 - - - email at yancy.lol 2022-11-09 12:14:52+00:00 - - - Peter Todd 2022-11-08 18:16:13+00:00 - - - Erik Aronesty 2022-11-03 13:32:20+00:00 - - - alicexbt 2022-11-02 19:02:33+00:00 - - - Peter Todd 2022-11-02 09:26:27+00:00 - + 2025-09-26T14:29:52.899085+00:00 + python-feedgen + + + [bitcoin-dev] Announcement: Full-RBF Miner Bounty Peter Todd + 2022-11-02T09:26:00.000Z + + + alicexbt + 2022-11-02T19:02:00.000Z + + + Erik Aronesty + 2022-11-03T13:32:00.000Z + + + Peter Todd + 2022-11-08T18:16:00.000Z + + + email + 2022-11-09T12:14:00.000Z + + + Anthony Towns + 2022-11-15T05:36:00.000Z + + + Peter Todd + 2022-11-15T14:43:00.000Z + + + El_Hoy + 2022-12-05T12:20:00.000Z + + + Greg Sanders + 2022-12-05T13:38:00.000Z + + + Rijndael + 2022-12-05T14:12:00.000Z + + + Michael Folkson + 2022-12-05T15:33:00.000Z + + + Erik Aronesty + 2022-12-05T17:00:00.000Z + + + El_Hoy + 2022-12-05T17:25:00.000Z + + + El_Hoy + 2022-12-06T04:48:00.000Z + + + Peter Todd + 2022-12-06T05:39:00.000Z + + + Peter Todd + 2022-12-06T07:37:00.000Z + + + 0xB10C + 2022-12-09T16:04:00.000Z + + + Peter Todd + 2022-12-09T21:16:00.000Z + + + 0xB10C + 2022-12-10T11:59:00.000Z + + + Peter Todd + 2022-12-10T18:07:00.000Z + + + Anthony Towns + 2022-12-13T04:01:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Announcement: Full-RBF Miner Bounty - 2023-08-02T08:24:00.883108+00:00 + 2025-09-26T14:29:52.901324+00:00 - A member of the bitcoin-dev community has set up a mempoolfullrbf=1 node to monitor full-RBF transactions and is logging replacement events. They are filtering full-RBF replacements and listing the replaced and replacement transactions on their website. Another member suggests grouping related replacements together and providing information on how long ago the replaced transaction was seen compared to the full RBF event timestamp. The member also suggests including this information for bip-125 opt-in rbf txs to show the frequency of the "offer a low fee, and raise it over time" approach.Bitcoin developer Peter Todd and 0xB10C discuss monitoring full-RBF transactions in an email exchange. 0xB10C's logs suggest that Luxor may have mempoolfullrbf=1 enabled as they have mined five full-RBF replacements in two blocks. AntPool's status is uncertain based on one transaction they mined. Block explorer Blockstream.info recently enabled full-RBF, but the propagation to their nodes can be sporadic. Todd has ported Antoine's preferential peering patch to v24.0 and suggests running it to focus on replacements rather than propagation. Foundry USA mined a doublespend, potentially due to accidental propagation.Peter Todd sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and logs them. The node accepts incoming connections and has not taken any special steps for peering with other full-rbf nodes. Over the last few days, the node has mostly seen OP_RETURN transactions, particularly OpenTimestamps transactions. Luxor may have mempoolfullrbf=1 enabled based on recent observations. So far, no full-RBF replacement transactions have been mined.0xB10C sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and lists the replaced and replacement transactions. The node does not take any special steps for peering with other full-rbf nodes and relies on good peering to receive all the replacements. The node has mostly seen OP_RETURN transactions, including OpenTimestamps transactions. Replacement transactions have not been mined yet. The OpenTimestamps transactions primarily make full-RBF replacements on two calendars.Peter Todd explains in an email exchange that censoring transactions on the Bitcoin blockchain is highly unlikely due to the decentralized nature of the network. He notes that there are thousands of listening nodes connected to the network, making it difficult for censorship to be successful. Todd also mentions the percentage of the network needed to run full-RBF for a node to connect to at least one full-RBF peer. He suggests running a full-RBF node that connects to every single listening node simultaneously. Todd provides a link to a percolation simulator for full-RBF.In an email exchange, Peter Todd discusses the risks of enforcing mempool consistency on the Bitcoin network. He notes that implementing such a rule could lead to unintended chain splits and may not be feasible as he does not have commit access to the main repository. Todd also explains the probability of censoring nodes successfully blocking transactions, highlighting the difficulty of achieving such censorship. He mentions the possibility of running multiple nodes with functionality to stop the propagation of full-RBF replaced blocks but acknowledges the challenges associated with this approach.The bitcoin-dev mailing list discussion focuses on the importance of proof of work for building consensus-accepted blocks and the risks associated with enforcing mempool consistency through a consensus rule. Some contributors argue against enforcing mempool consistency, citing potential unintended chain splits. Others suggest working on a Bitcoin Core implementation that stops the propagation of full-RBF replaced blocks, but political difficulties arise due to commit access limitations. The conversation also touches on attacks on opt-in RBF and 0Conf bitcoin usage, as well as ad hominem attacks towards Daniel Lipshitz.A discussion on the bitcoin-dev mailing list addresses concerns about a proposed change to the Bitcoin network, which some believe would lead to centralization and fail to achieve its intended goal. The possibility of sending transactions directly to miners is discussed, with one participant noting the difficulty of different miners having conflicting opt-out-rbb transactions. Enforcing mempool consistency through a consensus rule is debated, with warnings about unintended chain splits. The discussion also touches on Peter Todd's attack on opt-in RBF and 0Conf bitcoin usage, suggesting a solution to stop the propagation of full-RBF replaced blocks. However, implementing this solution may be politically challenging.The bitcoin-dev mailing list conversation discusses the risks associated with enforcing mempool consistency on the Bitcoin network and the challenges of implementing such a rule. Concerns are raised about unintended chain splits and the difficulty of making a consensus rule that enforces mempool consistency. The risk of double-spending transactions is also highlighted when conflicting transactions are broadcasted with minimal fees. Peter Todd's efforts to attack opt-in RBF are mentioned, including the donations he received for his work. Evidence suggests that there is no significant hashrate mining with full-RBF policies.On Nov 8, 2022-12-13T04:01:50+00:00 + A member of the bitcoin-dev community has set up a mempoolfullrbf=1 node to monitor full-RBF transactions and is logging replacement events. They are filtering full-RBF replacements and listing the replaced and replacement transactions on their website. Another member suggests grouping related replacements together and providing information on how long ago the replaced transaction was seen compared to the full RBF event timestamp. The member also suggests including this information for bip-125 opt-in rbf txs to show the frequency of the "offer a low fee, and raise it over time" approach.Bitcoin developer Peter Todd and 0xB10C discuss monitoring full-RBF transactions in an email exchange. 0xB10C's logs suggest that Luxor may have mempoolfullrbf=1 enabled as they have mined five full-RBF replacements in two blocks. AntPool's status is uncertain based on one transaction they mined. Block explorer Blockstream.info recently enabled full-RBF, but the propagation to their nodes can be sporadic. Todd has ported Antoine's preferential peering patch to v24.0 and suggests running it to focus on replacements rather than propagation. Foundry USA mined a doublespend, potentially due to accidental propagation.Peter Todd sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and logs them. The node accepts incoming connections and has not taken any special steps for peering with other full-rbf nodes. Over the last few days, the node has mostly seen OP_RETURN transactions, particularly OpenTimestamps transactions. Luxor may have mempoolfullrbf=1 enabled based on recent observations. So far, no full-RBF replacement transactions have been mined.0xB10C sets up a mempoolfullrbf=1 node to monitor full-RBF replacements and lists the replaced and replacement transactions. The node does not take any special steps for peering with other full-rbf nodes and relies on good peering to receive all the replacements. The node has mostly seen OP_RETURN transactions, including OpenTimestamps transactions. Replacement transactions have not been mined yet. The OpenTimestamps transactions primarily make full-RBF replacements on two calendars.Peter Todd explains in an email exchange that censoring transactions on the Bitcoin blockchain is highly unlikely due to the decentralized nature of the network. He notes that there are thousands of listening nodes connected to the network, making it difficult for censorship to be successful. Todd also mentions the percentage of the network needed to run full-RBF for a node to connect to at least one full-RBF peer. He suggests running a full-RBF node that connects to every single listening node simultaneously. Todd provides a link to a percolation simulator for full-RBF.In an email exchange, Peter Todd discusses the risks of enforcing mempool consistency on the Bitcoin network. He notes that implementing such a rule could lead to unintended chain splits and may not be feasible as he does not have commit access to the main repository. Todd also explains the probability of censoring nodes successfully blocking transactions, highlighting the difficulty of achieving such censorship. He mentions the possibility of running multiple nodes with functionality to stop the propagation of full-RBF replaced blocks but acknowledges the challenges associated with this approach.The bitcoin-dev mailing list discussion focuses on the importance of proof of work for building consensus-accepted blocks and the risks associated with enforcing mempool consistency through a consensus rule. Some contributors argue against enforcing mempool consistency, citing potential unintended chain splits. Others suggest working on a Bitcoin Core implementation that stops the propagation of full-RBF replaced blocks, but political difficulties arise due to commit access limitations. The conversation also touches on attacks on opt-in RBF and 0Conf bitcoin usage, as well as ad hominem attacks towards Daniel Lipshitz.A discussion on the bitcoin-dev mailing list addresses concerns about a proposed change to the Bitcoin network, which some believe would lead to centralization and fail to achieve its intended goal. The possibility of sending transactions directly to miners is discussed, with one participant noting the difficulty of different miners having conflicting opt-out-rbb transactions. Enforcing mempool consistency through a consensus rule is debated, with warnings about unintended chain splits. The discussion also touches on Peter Todd's attack on opt-in RBF and 0Conf bitcoin usage, suggesting a solution to stop the propagation of full-RBF replaced blocks. However, implementing this solution may be politically challenging.The bitcoin-dev mailing list conversation discusses the risks associated with enforcing mempool consistency on the Bitcoin network and the challenges of implementing such a rule. Concerns are raised about unintended chain splits and the difficulty of making a consensus rule that enforces mempool consistency. The risk of double-spending transactions is also highlighted when conflicting transactions are broadcasted with minimal fees. Peter Todd's efforts to attack opt-in RBF are mentioned, including the donations he received for his work. Evidence suggests that there is no significant hashrate mining with full-RBF policies.On Nov 8, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Bitcoin-Contracting-Primitives-WG-1st-Meeting-Tuesday-15-Nov-18-00-UTC.xml b/static/bitcoin-dev/Nov_2022/combined_Bitcoin-Contracting-Primitives-WG-1st-Meeting-Tuesday-15-Nov-18-00-UTC.xml index e4083461f9..4c32fec614 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Bitcoin-Contracting-Primitives-WG-1st-Meeting-Tuesday-15-Nov-18-00-UTC.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Bitcoin-Contracting-Primitives-WG-1st-Meeting-Tuesday-15-Nov-18-00-UTC.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC - 2023-08-02T08:20:59.365111+00:00 - - Antoine Riard 2022-11-15 23:49:17+00:00 - - - Antoine Riard 2022-11-15 23:47:39+00:00 - - - alicexbt 2022-11-15 22:36:48+00:00 - - - Antoine Riard 2022-11-14 02:21:16+00:00 - - - Antoine Riard 2022-11-01 00:47:18+00:00 - + 2025-09-26T14:29:59.321037+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC Antoine Riard + 2022-11-01T00:47:00.000Z + + + Antoine Riard + 2022-11-14T02:21:00.000Z + + + alicexbt + 2022-11-15T22:36:00.000Z + + + Antoine Riard + 2022-11-15T23:47:00.000Z + + + Antoine Riard + 2022-11-15T23:49:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Contracting Primitives WG 1st Meeting, Tuesday 15 Nov. 18:00 UTC - 2023-08-02T08:20:59.365111+00:00 + 2025-09-26T14:29:59.321764+00:00 - On November 15th, the Bitcoin Contracting Primitives working group held their first meeting to discuss various covenant interests, including state channels, universal settlement layer, transaction introspection covenants, vaults/self-custody, MATT covenants, logical label covenant, congestion control, and DLC. The goal of the process is to address misunderstandings, coordinate around goals, highlight consensus building, and help achieve covenant-style upgrades. The next meeting will focus on archiving all known consistent contracting primitives and protocols. Meetings will be held every month on the 3rd Tuesday, and logs are available on GitHub for reference. Antoine Riard proposed the date and time for the first meeting, which took place on November 15th at 18:00 UTC. The communication venue is #bitcoin-contracting-primitives-wg on Libera Chat. Attendees are encouraged to share their expectations, ideas, and subjects of interest related to the R&D process. Those working on contracting protocols or other use-cases can open an issue on GitHub. Efforts will be made to have a schedule inclusive of most time zones, and alternative communication formats such as jitsi/audio-based meetings are being considered. In addition, a message was sent to Bitcoin developers regarding the upcoming session on November 15th. The topics for discussion include anyprevout, recursive covenants, introspection, new malleability flags, ZK rollups, new contracting protocols, and other ideas. The sender suggests adding CTV: BIP-119 OP_CHECKTEMPLATEVERIFY to the discussion. The meeting will take place at 18:00 UTC and will have a monthly frequency. The communication venue is #bitcoin-contracting-primitives-wg on Libera Chat. Attendees are encouraged to share their thoughts on the topics. Those working on contracting protocols or other relevant use-cases can open an issue on GitHub. A schedule that accommodates most time zones may be considered.Antoine Riard is initiating a new community process for Bitcoin developers to discuss various topics related to contracting primitives. The first session took place on November 15th, and the meetings will continue on a monthly basis. The communication venue is #bitcoin-contracting-primitives-wg on Libera Chat. The agenda for the meetings is to listen to attendees' expectations, ideas, and subjects of interest regarding the contracting primitives R&D process. Those working on contracting protocols or other use-cases can open an issue on GitHub. The group aims to have a schedule that is inclusive of most time zones, and alternative communication formats such as jitsi/audio-based meetings are being considered. The topics for discussion include anyprevout, recursive covenants, introspection, new malleability flags, ZK rollups, and new contracting protocols. 2022-11-15T23:49:17+00:00 + On November 15th, the Bitcoin Contracting Primitives working group held their first meeting to discuss various covenant interests, including state channels, universal settlement layer, transaction introspection covenants, vaults/self-custody, MATT covenants, logical label covenant, congestion control, and DLC. The goal of the process is to address misunderstandings, coordinate around goals, highlight consensus building, and help achieve covenant-style upgrades. The next meeting will focus on archiving all known consistent contracting primitives and protocols. Meetings will be held every month on the 3rd Tuesday, and logs are available on GitHub for reference. Antoine Riard proposed the date and time for the first meeting, which took place on November 15th at 18:00 UTC. The communication venue is #bitcoin-contracting-primitives-wg on Libera Chat. Attendees are encouraged to share their expectations, ideas, and subjects of interest related to the R&D process. Those working on contracting protocols or other use-cases can open an issue on GitHub. Efforts will be made to have a schedule inclusive of most time zones, and alternative communication formats such as jitsi/audio-based meetings are being considered. In addition, a message was sent to Bitcoin developers regarding the upcoming session on November 15th. The topics for discussion include anyprevout, recursive covenants, introspection, new malleability flags, ZK rollups, new contracting protocols, and other ideas. The sender suggests adding CTV: BIP-119 OP_CHECKTEMPLATEVERIFY to the discussion. The meeting will take place at 18:00 UTC and will have a monthly frequency. The communication venue is #bitcoin-contracting-primitives-wg on Libera Chat. Attendees are encouraged to share their thoughts on the topics. Those working on contracting protocols or other relevant use-cases can open an issue on GitHub. A schedule that accommodates most time zones may be considered.Antoine Riard is initiating a new community process for Bitcoin developers to discuss various topics related to contracting primitives. The first session took place on November 15th, and the meetings will continue on a monthly basis. The communication venue is #bitcoin-contracting-primitives-wg on Libera Chat. The agenda for the meetings is to listen to attendees' expectations, ideas, and subjects of interest regarding the contracting primitives R&D process. Those working on contracting protocols or other use-cases can open an issue on GitHub. The group aims to have a schedule that is inclusive of most time zones, and alternative communication formats such as jitsi/audio-based meetings are being considered. The topics for discussion include anyprevout, recursive covenants, introspection, new malleability flags, ZK rollups, and new contracting protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml b/static/bitcoin-dev/Nov_2022/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml index 321db70ff3..c84ec3cce7 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml @@ -1,131 +1,175 @@ - + 2 Combined summary - Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy - 2023-08-02T04:05:11.326798+00:00 - - Erik Aronesty 2022-11-02 17:30:13+00:00 - - - raymo at riseup.net 2021-08-09 20:22:57+00:00 - - - raymo at riseup.net 2021-08-09 16:22:29+00:00 - - - s7r 2021-08-09 00:03:31+00:00 - - - raymo at riseup.net 2021-08-08 09:11:42+00:00 - - - Tao Effect 2021-07-17 18:54:22+00:00 - - - raymo at riseup.net 2021-07-17 15:50:30+00:00 - - - Billy Tetrud 2021-07-07 03:20:38+00:00 - - - raymo at riseup.net 2021-07-03 08:02:09+00:00 - - - Billy Tetrud 2021-07-02 17:57:54+00:00 - - - raymo at riseup.net 2021-07-01 22:15:13+00:00 - - - Erik Aronesty 2021-07-01 20:49:16+00:00 - - - raymo at riseup.net 2021-07-01 20:11:10+00:00 - - - raymo at riseup.net 2021-06-30 12:21:27+00:00 - - - ZmnSCPxj 2021-06-29 21:42:26+00:00 - - - raymo at riseup.net 2021-06-28 19:07:40+00:00 - - - Ricardo Filipe 2021-06-28 18:05:46+00:00 - - - Alex Schoof 2021-06-28 17:58:47+00:00 - - - raymo at riseup.net 2021-06-28 17:38:10+00:00 - - - Tao Effect 2021-06-28 17:29:40+00:00 - - - raymo at riseup.net 2021-06-28 16:58:37+00:00 - - - raymo at riseup.net 2021-06-28 16:33:24+00:00 - - - ZmnSCPxj 2021-06-28 15:28:44+00:00 - - - James Hilliard 2021-06-28 11:28:13+00:00 - - - raymo at riseup.net 2021-06-28 09:52:38+00:00 - - - James Hilliard 2021-06-28 08:23:00+00:00 - - - raymo at riseup.net 2021-06-28 06:29:59+00:00 - - - ZmnSCPxj 2021-06-28 05:20:08+00:00 - - - raymo at riseup.net 2021-06-27 11:05:04+00:00 - - - ZmnSCPxj 2021-06-27 04:53:52+00:00 - - - raymo at riseup.net 2021-06-26 21:54:26+00:00 - - - Billy Tetrud 2021-06-22 18:20:51+00:00 - - - James Hilliard 2021-06-20 01:59:54+00:00 - - - ZmnSCPxj 2021-06-20 00:53:58+00:00 - - - Erik Aronesty 2021-06-19 21:14:08+00:00 - - - raymo at riseup.net 2021-06-18 20:22:08+00:00 - - - raymo at riseup.net 2021-06-18 20:00:12+00:00 - - - Alex Schoof 2021-06-18 13:44:17+00:00 - - - Erik Aronesty 2021-06-18 13:37:54+00:00 - - - Erik Aronesty 2021-06-18 01:42:39+00:00 - - - raymo at riseup.net 2021-06-16 13:44:24+00:00 - + 2025-09-26T14:29:20.787938+00:00 + python-feedgen + + + [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo + 2021-06-16T13:44:00.000Z + + + Erik Aronesty + 2021-06-18T01:42:00.000Z + + + Erik Aronesty + 2021-06-18T13:37:00.000Z + + + Alex Schoof + 2021-06-18T13:44:00.000Z + + + raymo + 2021-06-18T20:00:00.000Z + + + raymo + 2021-06-18T20:22:00.000Z + + + Erik Aronesty + 2021-06-19T21:14:00.000Z + + + ZmnSCPxj + 2021-06-20T00:53:00.000Z + + + James Hilliard + 2021-06-20T01:59:00.000Z + + + Billy Tetrud + 2021-06-22T18:20:00.000Z + + + raymo + 2021-06-26T21:54:00.000Z + + + ZmnSCPxj + 2021-06-27T04:53:00.000Z + + + raymo + 2021-06-27T11:05:00.000Z + + + ZmnSCPxj + 2021-06-28T05:20:00.000Z + + + raymo + 2021-06-28T06:29:00.000Z + + + James Hilliard + 2021-06-28T08:23:00.000Z + + + raymo + 2021-06-28T09:52:00.000Z + + + James Hilliard + 2021-06-28T11:28:00.000Z + + + ZmnSCPxj + 2021-06-28T15:28:00.000Z + + + raymo + 2021-06-28T16:33:00.000Z + + + raymo + 2021-06-28T16:58:00.000Z + + + Tao Effect + 2021-06-28T17:29:00.000Z + + + raymo + 2021-06-28T17:38:00.000Z + + + Alex Schoof + 2021-06-28T17:58:00.000Z + + + Ricardo Filipe + 2021-06-28T18:05:00.000Z + + + raymo + 2021-06-28T19:07:00.000Z + + + ZmnSCPxj + 2021-06-29T21:42:00.000Z + + + raymo + 2021-06-30T12:21:00.000Z + + + raymo + 2021-07-01T20:11:00.000Z + + + Erik Aronesty + 2021-07-01T20:49:00.000Z + + + raymo + 2021-07-01T22:15:00.000Z + + + Billy Tetrud + 2021-07-02T17:57:00.000Z + + + raymo + 2021-07-03T08:02:00.000Z + + + Billy Tetrud + 2021-07-07T03:20:00.000Z + + + raymo + 2021-07-17T15:50:00.000Z + + + Tao Effect + 2021-07-17T18:54:00.000Z + + + raymo + 2021-08-08T09:11:00.000Z + + + s7r + 2021-08-09T00:03:00.000Z + + + raymo + 2021-08-09T16:22:00.000Z + + + raymo + 2021-08-09T20:22:00.000Z + + + Erik Aronesty + 2022-11-02T17:30:00.000Z + + @@ -167,13 +211,13 @@ - python-feedgen + 2 Combined summary - Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy - 2023-08-02T04:05:11.326798+00:00 + 2025-09-26T14:29:20.792079+00:00 - Full Replace-By-Fee (RBF) is becoming the norm in the Sabu protocol, and transactions without it can be rejected. Watchtowers can prevent attacks in progress by offering an always-on watchtower service for a small fee. The Sabu state functions as another mempool, so it's important for all parties to maintain it.An email exchange between Raymo and Chris Riley discusses the uncertainty surrounding potential revenue increases under the Sabu protocol. While upgrading the Bitcoin protocol wouldn't be technically difficult, consensus on implementation changes is required. If there are difficulties with implementing changes to the Bitcoin core protocol, the Stratum protocol could be changed instead.Miners have the incentive to accept the highest fee transaction, but there is no guarantee due to the untrusted nature of the network. It is still uncertain whether miners will prefer the highest fee transaction or keep the first transaction received and drop subsequent ones.The Guarantee Transaction is created based on the Main Transaction but has no direct relation to it. Miners choose the Guarantee Transaction over other transactions spending the same UTXO(s) because it offers a notably higher fee. Bob must be online 24/7 to prevent Alice's attack from succeeding completely.The email thread also discusses a hypothetical fraudulent attack on Bitcoin's Lightning Network. This attack involves a malicious actor using already-spent inputs to defraud a creditor. Despite a higher fee in the Guarantee transaction, miners are unlikely to drop the Sabu-Killing-transaction and consider only the Guarantee transaction. The attack has a 99% chance of success, and Bob needs to be online continuously to prevent it.The email raises a question about how Bob can spend the coins he received and become an issuer in relation to another creditor, Dave. If Alice tries to defraud Bob after he spent his Sabu credit to Dave, Dave would need to hold all parent "guarantee transactions" and watch for potential fraudulent transactions.Raymo, the creator of Sabu, suggests penalties for issuers, creditors, and miners instead of a claw-back mechanism. He is actively working on realizing the Sabu protocol and Gazin wallet. The proposal is open for review and feedback on various platforms.The Sabu protocol aims to improve Bitcoin circulation, transaction processing speed (TPS), and privacy. It allows users to send and receive Bitcoin without opening channels or paying transaction fees. Transactions are recorded on the Bitcoin blockchain only in case of fraudulent activity. The protocol involves issuers who own Bitcoin and creditors who receive it in exchange for goods or services.The security model of Sabu relies on guarantee transactions to ensure creditors receive payment even in case of fraud. The protocol offers self-sovereignty and decentralized communication, with PGP encryption ensuring privacy. Wallets can add friends using email addresses or scanned public keys. Each transaction is a small money transfer with specific inputs and outputs, and creditors pay a Sabu-transaction-fee to issuers.Despite concerns about the assumptions made in the proposal and the use of email for user identification and communication, the Sabu protocol offers a promising solution to improve Bitcoin circulation, TPS, and privacy. It provides an alternative to the Lightning Network and traditional custodial solutions.In conclusion, the Sabu protocol proposes a peer-to-peer network architecture that allows for improved Bitcoin trading with enhanced privacy and self-sovereignty. It addresses concerns about cheating through guarantee transactions and offers an alternative approach to transaction processing speed. However, further evaluation and addressing of concerns are necessary for successful implementation.The author of the article suggests using email as the primary communication method for transactions, despite potential privacy concerns. They argue that email is the most neutral, free, and globally accessible option. However, this protocol does not address the issue of preventing fraud proofs. As alternatives, QR codes and device-to-device linking are proposed for adding contacts to the contact list.To improve Bitcoin's transaction per second (TPS) and privacy, a proposal has been made to create a new cryptocurrency called IOUs that would run on top of Bitcoin. However, there are concerns about preventing double-spending, network latency, and spam filters when using email as the remote procedure call mechanism. Consensus among nodes is necessary to avoid conflicts regarding the correct set of "sent notes".Another plan to enhance Bitcoin's TPS and privacy involves implementing an off-chain transaction network, as suggested by Raymo. This system guarantees security through relative fees and the cost-of-theft. It is recommended for small transactions similar to Lightning but without limits or routing protocols. More details can be found in Raymo's Medium post and Bitcointalk forum, where the community is invited to provide feedback and thoughts.In summary, various discussions have taken place regarding mining behavior, high transaction fees, and latency issues in the Bitcoin network. The vulnerability of sybil attacks and proxy attacks has also been addressed, along with suggestions for defense mechanisms. Both the Sabu protocol and Raymo's proposal aim to improve Bitcoin's TPS and 2022-11-02T17:30:13+00:00 + Full Replace-By-Fee (RBF) is becoming the norm in the Sabu protocol, and transactions without it can be rejected. Watchtowers can prevent attacks in progress by offering an always-on watchtower service for a small fee. The Sabu state functions as another mempool, so it's important for all parties to maintain it.An email exchange between Raymo and Chris Riley discusses the uncertainty surrounding potential revenue increases under the Sabu protocol. While upgrading the Bitcoin protocol wouldn't be technically difficult, consensus on implementation changes is required. If there are difficulties with implementing changes to the Bitcoin core protocol, the Stratum protocol could be changed instead.Miners have the incentive to accept the highest fee transaction, but there is no guarantee due to the untrusted nature of the network. It is still uncertain whether miners will prefer the highest fee transaction or keep the first transaction received and drop subsequent ones.The Guarantee Transaction is created based on the Main Transaction but has no direct relation to it. Miners choose the Guarantee Transaction over other transactions spending the same UTXO(s) because it offers a notably higher fee. Bob must be online 24/7 to prevent Alice's attack from succeeding completely.The email thread also discusses a hypothetical fraudulent attack on Bitcoin's Lightning Network. This attack involves a malicious actor using already-spent inputs to defraud a creditor. Despite a higher fee in the Guarantee transaction, miners are unlikely to drop the Sabu-Killing-transaction and consider only the Guarantee transaction. The attack has a 99% chance of success, and Bob needs to be online continuously to prevent it.The email raises a question about how Bob can spend the coins he received and become an issuer in relation to another creditor, Dave. If Alice tries to defraud Bob after he spent his Sabu credit to Dave, Dave would need to hold all parent "guarantee transactions" and watch for potential fraudulent transactions.Raymo, the creator of Sabu, suggests penalties for issuers, creditors, and miners instead of a claw-back mechanism. He is actively working on realizing the Sabu protocol and Gazin wallet. The proposal is open for review and feedback on various platforms.The Sabu protocol aims to improve Bitcoin circulation, transaction processing speed (TPS), and privacy. It allows users to send and receive Bitcoin without opening channels or paying transaction fees. Transactions are recorded on the Bitcoin blockchain only in case of fraudulent activity. The protocol involves issuers who own Bitcoin and creditors who receive it in exchange for goods or services.The security model of Sabu relies on guarantee transactions to ensure creditors receive payment even in case of fraud. The protocol offers self-sovereignty and decentralized communication, with PGP encryption ensuring privacy. Wallets can add friends using email addresses or scanned public keys. Each transaction is a small money transfer with specific inputs and outputs, and creditors pay a Sabu-transaction-fee to issuers.Despite concerns about the assumptions made in the proposal and the use of email for user identification and communication, the Sabu protocol offers a promising solution to improve Bitcoin circulation, TPS, and privacy. It provides an alternative to the Lightning Network and traditional custodial solutions.In conclusion, the Sabu protocol proposes a peer-to-peer network architecture that allows for improved Bitcoin trading with enhanced privacy and self-sovereignty. It addresses concerns about cheating through guarantee transactions and offers an alternative approach to transaction processing speed. However, further evaluation and addressing of concerns are necessary for successful implementation.The author of the article suggests using email as the primary communication method for transactions, despite potential privacy concerns. They argue that email is the most neutral, free, and globally accessible option. However, this protocol does not address the issue of preventing fraud proofs. As alternatives, QR codes and device-to-device linking are proposed for adding contacts to the contact list.To improve Bitcoin's transaction per second (TPS) and privacy, a proposal has been made to create a new cryptocurrency called IOUs that would run on top of Bitcoin. However, there are concerns about preventing double-spending, network latency, and spam filters when using email as the remote procedure call mechanism. Consensus among nodes is necessary to avoid conflicts regarding the correct set of "sent notes".Another plan to enhance Bitcoin's TPS and privacy involves implementing an off-chain transaction network, as suggested by Raymo. This system guarantees security through relative fees and the cost-of-theft. It is recommended for small transactions similar to Lightning but without limits or routing protocols. More details can be found in Raymo's Medium post and Bitcointalk forum, where the community is invited to provide feedback and thoughts.In summary, various discussions have taken place regarding mining behavior, high transaction fees, and latency issues in the Bitcoin network. The vulnerability of sybil attacks and proxy attacks has also been addressed, along with suggestions for defense mechanisms. Both the Sabu protocol and Raymo's proposal aim to improve Bitcoin's TPS and - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Custom-signet-for-testing-full-RBF.xml b/static/bitcoin-dev/Nov_2022/combined_Custom-signet-for-testing-full-RBF.xml index 100ec50760..a5ba8ed020 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Custom-signet-for-testing-full-RBF.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Custom-signet-for-testing-full-RBF.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Custom signet for testing full RBF - 2023-08-02T08:34:33.026191+00:00 - - alicexbt 2022-11-22 17:09:16+00:00 - - - Michael Folkson 2022-11-22 11:20:44+00:00 - - - alicexbt 2022-11-20 06:36:23+00:00 - + 2025-09-26T14:29:57.210035+00:00 + python-feedgen + + + [bitcoin-dev] Custom signet for testing full RBF alicexbt + 2022-11-20T06:36:00.000Z + + + Michael Folkson + 2022-11-22T11:20:00.000Z + + + alicexbt + 2022-11-22T17:09:00.000Z + + - python-feedgen + 2 Combined summary - Custom signet for testing full RBF - 2023-08-02T08:34:33.026191+00:00 + 2025-09-26T14:29:57.210601+00:00 - A user named Alicexbt has successfully set up a custom signet for testing full Replace-By-Fee (RBF) and is inviting Bitcoin Developers to participate. The purpose of using a custom signet, as mentioned by another user named Michael Folkson in an email to the developers, is to test features that may not be available on the default signet with Bitcoin Core 24.0. Michael raised questions about the difficulties in setting up a custom signet and whether it is safe to run it on the same machine as other signets. He also expressed interest in knowing how regularly the sole block signer on the custom signet is mining blocks.Alicexbt had no issues setting up the custom signet using instructions from the Bitcoin wiki. They are the sole block signer and have been mining blocks regularly with default settings. While mainstream miners and dictators did not respond or agree to use full RBF, Alicexbt believes testing is important and encourages others to join the experiment. To connect to the custom signet nodes, users can use the `addnode` command with the provided IP address or connect through i2p or onion nodes. Alicexbt has shared an example configuration and a simple test case where two nodes are connected, and Tx1 is broadcasted using one node and replaced with Tx2 using the `bumpfee` RPC on the other node. Those interested in testing can post their Bitcoin addresses in the "full-rbf room". Alicexbt suggests that if the experiment proves successful, they may proceed towards setting up an explorer. The email sent by Alicexbt to Bitcoin developers was done using Proton Mail secure email service. 2022-11-22T17:09:16+00:00 + A user named Alicexbt has successfully set up a custom signet for testing full Replace-By-Fee (RBF) and is inviting Bitcoin Developers to participate. The purpose of using a custom signet, as mentioned by another user named Michael Folkson in an email to the developers, is to test features that may not be available on the default signet with Bitcoin Core 24.0. Michael raised questions about the difficulties in setting up a custom signet and whether it is safe to run it on the same machine as other signets. He also expressed interest in knowing how regularly the sole block signer on the custom signet is mining blocks.Alicexbt had no issues setting up the custom signet using instructions from the Bitcoin wiki. They are the sole block signer and have been mining blocks regularly with default settings. While mainstream miners and dictators did not respond or agree to use full RBF, Alicexbt believes testing is important and encourages others to join the experiment. To connect to the custom signet nodes, users can use the `addnode` command with the provided IP address or connect through i2p or onion nodes. Alicexbt has shared an example configuration and a simple test case where two nodes are connected, and Tx1 is broadcasted using one node and replaced with Tx2 using the `bumpfee` RPC on the other node. Those interested in testing can post their Bitcoin addresses in the "full-rbf room". Alicexbt suggests that if the experiment proves successful, they may proceed towards setting up an explorer. The email sent by Alicexbt to Bitcoin developers was done using Proton Mail secure email service. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 6c25093aa9..f728bcc7dc 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:29:27.286630+00:00 + python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:29:27.286802+00:00 - On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to 2023-03-13T16:38:25+00:00 + On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Merkleize-All-The-Things.xml b/static/bitcoin-dev/Nov_2022/combined_Merkleize-All-The-Things.xml index 8f18c5153b..4218be1eb0 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Merkleize-All-The-Things.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Merkleize-All-The-Things.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - Merkleize All The Things - 2023-08-02T08:28:28.195475+00:00 - - Johan Torås Halseth 2023-05-30 07:34:09+00:00 - - - Salvatore Ingala 2023-05-28 10:24:14+00:00 - - - Johan Torås Halseth 2023-05-26 11:45:17+00:00 - - - Salvatore Ingala 2023-05-05 21:18:16+00:00 - - - Johan Torås Halseth 2023-05-04 08:34:07+00:00 - - - Salvatore Ingala 2023-05-01 21:15:20+00:00 - - - Salvatore Ingala 2023-05-01 13:11:08+00:00 - - - Johan Torås Halseth 2023-04-28 08:48:07+00:00 - - - Billy Tetrud 2022-12-13 06:59:27+00:00 - - - Salvatore Ingala 2022-12-01 08:47:22+00:00 - - - Rijndael 2022-11-30 22:09:33+00:00 - - - Rijndael 2022-11-30 19:42:08+00:00 - - - Salvatore Ingala 2022-11-12 15:04:20+00:00 - - - Antoine Riard 2022-11-11 21:49:58+00:00 - - - Salvatore Ingala 2022-11-10 09:42:30+00:00 - - - David A. Harding 2022-11-10 07:39:10+00:00 - - - Peter Todd 2022-11-09 12:07:33+00:00 - - - Bram Cohen 2022-11-08 23:34:32+00:00 - - - ZmnSCPxj 2022-11-08 12:01:11+00:00 - - - Salvatore Ingala 2022-11-08 09:17:42+00:00 - + 2025-09-26T14:29:25.138169+00:00 + python-feedgen + + + [bitcoin-dev] Merkleize All The Things Salvatore Ingala + 2022-11-08T09:17:00.000Z + + + ZmnSCPxj + 2022-11-08T12:01:00.000Z + + + Bram Cohen + 2022-11-08T23:34:00.000Z + + + Peter Todd + 2022-11-09T12:07:00.000Z + + + David A. Harding + 2022-11-10T07:39:00.000Z + + + Salvatore Ingala + 2022-11-10T09:42:00.000Z + + + Antoine Riard + 2022-11-11T21:49:00.000Z + + + Salvatore Ingala + 2022-11-12T15:04:00.000Z + + + Rijndael + 2022-11-30T19:42:00.000Z + + + Rijndael + 2022-11-30T22:09:00.000Z + + + Salvatore Ingala + 2022-12-01T08:47:00.000Z + + + Billy Tetrud + 2022-12-13T06:59:00.000Z + + + Johan Torås Halseth + 2023-04-28T08:48:00.000Z + + + Salvatore Ingala + 2023-05-01T13:11:00.000Z + + + Salvatore Ingala + 2023-05-01T21:15:00.000Z + + + Johan Torås Halseth + 2023-05-04T08:34:00.000Z + + + Salvatore Ingala + 2023-05-05T21:18:00.000Z + + + Johan Torås Halseth + 2023-05-26T11:45:00.000Z + + + Salvatore Ingala + 2023-05-28T10:24:00.000Z + + + Johan Torås Halseth + 2023-05-30T07:34:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - Merkleize All The Things - 2023-08-02T08:28:28.196514+00:00 + 2025-09-26T14:29:25.140345+00:00 - In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain. He provided a simpler game example to clarify the relationship between the covenant and the bisection protocol.Salvatore Ingala proposed MATT (Merkleize All The Things) as a method for enabling general 2023-05-30T07:34:09+00:00 + In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain. He provided a simpler game example to clarify the relationship between the covenant and the bisection protocol.Salvatore Ingala proposed MATT (Merkleize All The Things) as a method for enabling general - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_MuSig2-BIP.xml b/static/bitcoin-dev/Nov_2022/combined_MuSig2-BIP.xml index 74cf7342a4..b72d946901 100644 --- a/static/bitcoin-dev/Nov_2022/combined_MuSig2-BIP.xml +++ b/static/bitcoin-dev/Nov_2022/combined_MuSig2-BIP.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 - - Jonas Nick 2022-11-03 14:43:22+00:00 - - - Jonas Nick 2022-10-11 15:34:23+00:00 - - - Jonas Nick 2022-10-03 20:41:08+00:00 - - - AdamISZ 2022-06-12 23:07:08+00:00 - - - AdamISZ 2022-05-26 17:34:47+00:00 - - - Jonas Nick 2022-05-26 15:32:33+00:00 - - - AdamISZ 2022-05-24 19:06:41+00:00 - - - AdamISZ 2022-05-23 22:09:52+00:00 - - - Jonas Nick 2022-05-23 15:56:54+00:00 - - - AdamISZ 2022-05-22 22:26:08+00:00 - - - Jonas Nick 2022-04-28 19:18:34+00:00 - - - Brandon Black 2022-04-28 15:33:42+00:00 - - - Olaoluwa Osuntokun 2022-04-28 03:53:59+00:00 - - - Olaoluwa Osuntokun 2022-04-28 01:47:33+00:00 - - - Jonas Nick 2022-04-05 22:57:13+00:00 - + 2025-09-26T14:29:37.972387+00:00 + python-feedgen + + + [bitcoin-dev] MuSig2 BIP Jonas Nick + 2022-04-05T22:57:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T01:47:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T03:53:00.000Z + + + Brandon Black + 2022-04-28T15:33:00.000Z + + + Jonas Nick + 2022-04-28T19:18:00.000Z + + + AdamISZ + 2022-05-22T22:26:00.000Z + + + Jonas Nick + 2022-05-23T15:56:00.000Z + + + AdamISZ + 2022-05-23T22:09:00.000Z + + + AdamISZ + 2022-05-24T19:06:00.000Z + + + Jonas Nick + 2022-05-26T15:32:00.000Z + + + AdamISZ + 2022-05-26T17:34:00.000Z + + + AdamISZ + 2022-06-12T23:07:00.000Z + + + Jonas Nick + 2022-10-03T20:41:00.000Z + + + Jonas Nick + 2022-10-11T15:34:00.000Z + + + Jonas Nick + 2022-11-03T14:43:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 + 2025-09-26T14:29:37.974070+00:00 - The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary 2022-11-03T14:43:22+00:00 + The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml b/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml index beea467a82..c91762aee4 100644 --- a/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml +++ b/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On mempool policy consistency - 2023-08-02T08:19:04.219216+00:00 + 2025-09-26T14:29:22.950536+00:00 + python-feedgen email at yancy.lol 2022-11-10 14:38:27+00:00 @@ -135,13 +136,13 @@ - python-feedgen + 2 Combined summary - On mempool policy consistency - 2023-08-02T08:19:04.220213+00:00 + 2025-09-26T14:29:22.950737+00:00 - The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases. The discussion also touched upon 2022-11-10T14:38:27+00:00 + The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases. The discussion also touched upon - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Package-Relay-Proposal.xml b/static/bitcoin-dev/Nov_2022/combined_Package-Relay-Proposal.xml index f7d6e2732a..298dba8540 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Package-Relay-Proposal.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Package-Relay-Proposal.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Package Relay Proposal - 2023-08-02T06:32:07.153762+00:00 - - Greg Sanders 2023-05-10 15:42:34+00:00 - - - Tom Trevethan 2023-05-10 15:12:04+00:00 - - - Gloria Zhao 2022-11-01 18:03:22+00:00 - - - Antoine Riard 2022-06-17 20:08:36+00:00 - - - Gloria Zhao 2022-06-14 09:59:23+00:00 - - - Suhas Daftuar 2022-06-08 15:59:03+00:00 - - - Gloria Zhao 2022-06-07 17:44:45+00:00 - - - Gloria Zhao 2022-05-28 01:54:13+00:00 - - - eric at voskuil.org 2022-05-26 02:59:01+00:00 - - - eric at voskuil.org 2022-05-25 20:52:07+00:00 - - - Anthony Towns 2022-05-25 18:55:35+00:00 - - - Eric Voskuil 2022-05-24 23:43:57+00:00 - - - Gloria Zhao 2022-05-24 21:05:35+00:00 - - - Anthony Towns 2022-05-24 19:48:02+00:00 - - - Gloria Zhao 2022-05-24 01:13:43+00:00 - - - Anthony Towns 2022-05-23 21:34:16+00:00 - - - Gloria Zhao 2022-05-18 18:40:58+00:00 - - - Anthony Towns 2022-05-18 00:35:31+00:00 - - - Gloria Zhao 2022-05-17 20:45:42+00:00 - - - Greg Sanders 2022-05-17 17:56:40+00:00 - - - Gloria Zhao 2022-05-17 16:01:04+00:00 - + 2025-09-26T14:29:55.091680+00:00 + python-feedgen + + + [bitcoin-dev] Package Relay Proposal Gloria Zhao + 2022-05-17T16:01:00.000Z + + + Greg Sanders + 2022-05-17T17:56:00.000Z + + + Gloria Zhao + 2022-05-17T20:45:00.000Z + + + Anthony Towns + 2022-05-18T00:35:00.000Z + + + Gloria Zhao + 2022-05-18T18:40:00.000Z + + + Anthony Towns + 2022-05-23T21:34:00.000Z + + + Gloria Zhao + 2022-05-24T01:13:00.000Z + + + Anthony Towns + 2022-05-24T19:48:00.000Z + + + Gloria Zhao + 2022-05-24T21:05:00.000Z + + + Eric Voskuil + 2022-05-24T23:43:00.000Z + + + Anthony Towns + 2022-05-25T18:55:00.000Z + + + eric + 2022-05-25T20:52:00.000Z + + + eric + 2022-05-26T02:59:00.000Z + + + Gloria Zhao + 2022-05-28T01:54:00.000Z + + + Gloria Zhao + 2022-06-07T17:44:00.000Z + + + Suhas Daftuar + 2022-06-08T15:59:00.000Z + + + Gloria Zhao + 2022-06-14T09:59:00.000Z + + + Antoine Riard + 2022-06-17T20:08:00.000Z + + + Gloria Zhao + 2022-11-01T18:03:00.000Z + + + [bitcoin-dev] Package Relay Proposal Tom Trevethan + 2023-05-10T15:12:00.000Z + + + Greg Sanders + 2023-05-10T15:42:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Package Relay Proposal - 2023-08-02T06:32:07.153762+00:00 + 2025-09-26T14:29:55.093774+00:00 - The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids. Different perspectives are presented, highlighting the tradeoffs and considerations involved in implementing package relay in the Bitcoin protocol.A proposal has been made by Bitcoin Core developer Gloria Zhao to implement a 2023-05-10T15:42:34+00:00 + The email thread on the bitcoin-dev mailing list discusses the availability of the submitpackage RPC on the mainnet in the current core release. Tom Trevethan inquired about its availability and any plans for deployment in the next release. Greg replied that a PR was opened to address this concern and shared a link for higher-level tracking of the project.Currently, the submitpackage RPC is available on regtest in the current core release. However, there has been no recent discussion or timeline for deploying it on the mainnet in the next release. The submitpackage RPC is crucial for addressing mempool purge issues.Gloria Zhao proposed changes to her package relay proposal called Ancestor Package Relay, BIP331. The changes involve reducing the scope to receiver-initiated and ancestor packages only, removing sender-initiated package relay. The proposal also removes child-with-unconfirmed-parents package as it is a subset of ancestor packages. The major change in package information is the removal of the block hash, which should be handled internally at the mempool validation level. The proposal discusses the purpose of 'max_count' and 'max_weight', trade-offs in bandwidth consumption, and concerns of package-feerate downgrades attacks.The proposal suggests a set of p2p protocol changes to enable package relay, introducing version 1 packages consisting of one transaction and its unconfirmed parents. It explains the rules and requirements for package relay in Bitcoin Core, specifying the structure and purpose of messages like "sendpackages," "getpckgtxns," and "pckgtxns." The proposal aims to improve the fairness of the fee-based market for block space and increase users' ability to fee-bump their transactions.The proposal also addresses pinning attacks by considering transactions as a unit instead of individually. It mentions the use of ancestor packages in evaluating transactions in the mempool and developing a safe and incentive-compatible package mempool acceptance policy. The proposed protocol flow involves the sender announcing the package and providing package information upon request from the receiver. It suggests adding new inv types and protocol messages to support this.The proposal for package relay aims to improve communication efficiency, reduce bandwidth usage, and optimize storage for unconfirmed transactions. It introduces versioning to support different types of packages based on future use cases. The proposal acknowledges the contributions of various developers and includes a list of related links and resources.The conversation between Gloria Zhao and Suhas Daftuar discusses potential issues with package relay, including concerns about bandwidth waste and potential denial-of-service attacks. Suggestions are made to mitigate these issues, such as including a hash of the package wtxids in the initial announcement and limiting the use of version 1 packages. The discussion also covers the validation rules for packages and the use of BIP152 shortids.The conversation further explores the implementation of package relay using BIP152 and proposes changes to improve its efficiency and security. The suggestion of using a Merkle root for package identity instead of blockhash is discussed. Various aspects of the proposal, including incorporating ancestors into package announcements and versioning, are considered.The conversation concludes that while there are potential issues with package relay, further consideration and improvements could make it a valuable addition to Bitcoin's protocol. Relevant resources and links, such as BIP152, are shared throughout the discussion.The conversation on the Bitcoin-dev mailing list discusses various aspects of package relay in the Bitcoin protocol. One of the main concerns raised is the possibility of peers providing false information, leading to censorship of transactions. To address this, it is suggested to store all announcements and request from every peer to prevent censorship. The idea of including more upfront information, such as fee and weight, when announcing packages is also discussed, although its effectiveness in resolving censorship issues is debated.Another proposed solution is to encode parent transactions as short hashes of the wtxid and include them in the inv announcement to avoid round trips while deduplicating parents. However, it is noted that this method may create a denial-of-service vector as nodes would need to calculate shortids for every transaction in their mempools every time they receive a package.The discussion also highlights the use of BIP152 shortids for package relay and the need to simplify the protocol. It is mentioned that adding versioning to individual protocols is a reflection of the insufficiency of the initial protocol versioning design. The size and count constraints for package broadcasts are addressed, and it is mentioned that packaging across blocks is not economically rational under the assumption that one miner cannot expect to mine multiple blocks in a row.Overall, the email thread focuses on potential issues with peer-to-peer package announcements and proposes solutions using existing protocols. The conversation delves into the technical details of package relay, including the inclusion of fee and weight information, encoding parent transactions, and the use of shortids. Different perspectives are presented, highlighting the tradeoffs and considerations involved in implementing package relay in the Bitcoin protocol.A proposal has been made by Bitcoin Core developer Gloria Zhao to implement a - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Preventing-detecting-pinning-of-jointly-funded-txs.xml b/static/bitcoin-dev/Nov_2022/combined_Preventing-detecting-pinning-of-jointly-funded-txs.xml index 3e1826c3b9..2ddf76ee65 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Preventing-detecting-pinning-of-jointly-funded-txs.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Preventing-detecting-pinning-of-jointly-funded-txs.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Preventing/detecting pinning of jointly funded txs - 2023-08-02T08:22:02.569157+00:00 - - Anthony Towns 2022-11-07 11:46:28+00:00 - - - Antoine Riard 2022-11-06 23:22:08+00:00 - - - Greg Sanders 2022-11-02 13:46:24+00:00 - - - Anthony Towns 2022-11-02 03:52:09+00:00 - + 2025-09-26T14:29:46.460829+00:00 + python-feedgen + + + [bitcoin-dev] Preventing/detecting pinning of jointly funded txs Anthony Towns + 2022-11-02T03:52:00.000Z + + + Greg Sanders + 2022-11-02T13:46:00.000Z + + + Antoine Riard + 2022-11-06T23:22:00.000Z + + + Anthony Towns + 2022-11-07T11:46:00.000Z + + - python-feedgen + 2 Combined summary - Preventing/detecting pinning of jointly funded txs - 2023-08-02T08:22:02.569157+00:00 + 2025-09-26T14:29:46.461542+00:00 - Antoine Riard has proposed a solution to the denial-of-service (DoS) issue in an opt-in replace-by-fee (RBF) world for coinjoins, splicing, and dual-funded transactions. His proposal involves deploying a distributed monitoring system called "mempools watchdog" to track network mempools. However, this infrastructure is vulnerable to mempool partitioning attacks by adversaries. To address this problem, victims could outsource the monitoring to dedicated entities, but there is a lack of compensation mechanism, resulting in few public options.Another challenge discussed is assigning blame reliably among trust-minimized joint funding protocol participants. This issue arises when multiple double-spends occur from sybilling participants, aiming to halt the assignment process. One suggestion to avoid this situation is for participants to not sign conflicting transactions, indicating their desire to remain part of the group. If someone does sign it, it signifies their intention to leave the group. Additionally, if participants want to abort the coinjoin but stay in the group, at least 51% of the remaining group members must agree.In a full RBF world, any participant should be able to fee-bump the joint transaction. However, it is advised to avoid coinjoins with an excessively large number of untrusted counterparties. In such cases, it is better to exclude cheating participants and split the remainder into smaller groups until a more reasonable size is achieved. Broadcasting a double-spend with an equivalent fee rate as the honest transaction does not tighten the attack scenario because the attacker can still employ low fee rate pinning that cannot be recovered by fee bumping the alternative.Anthony Towns discusses solutions for a DoS attack in the opt-in RBF world. The attack targets joint funding protocol participants and requires distributed monitoring of network mempools. However, this mempools watchdog infrastructure is susceptible to partitioning attacks, where adversaries manipulate local node mempool views. Outsourcing mempool monitoring encounters the issue of limited public resources and single-point-of-censorship vulnerability. The economic scalability of defensive infrastructure is also a concern due to the ongoing cat-and-mouse game between victims and attackers. Assigning blame reliably among joint funding protocol participants is another challenge, and introducing a UTXO-satoshi-weight vote is suggested for efficient assignment convergence.The discussion on the bitcoin-dev mailing list delves into handling conflicts when revalidating transactions without access to the transaction itself. One approach proposed using BIP 37 mempool filters, but this compromises privacy by revealing information to attackers. Investing in hashpower was suggested as an alternative solution, particularly when working with untrusted peers. Privacy-conscious individuals can run anonymous bitcoind nodes to check their mempool content. To facilitate this, transaction broadcasts can be made more private using methods like Tor/i2p or Dandelion. Querying an explorer or centralized service is also an option if privacy is not a concern. Overall, the aim of the discussion was to find better solutions for handling transaction conflicts in Bitcoin.The bitcoin-dev discussion revolves around assigning blame in coinjoin-like protocols and proposes using Tor hidden services (HS) to ping explorers. However, privacy methods like coinswap cannot utilize Tor HS. As the size of the coinjoin increases, the risk of gossiping a duplicitous double-spend among peers also rises. DoS concerns are less pronounced in dual funding Lightning Network channels due to the relatively small number of participants. Joint funding protocols can address the problem of opt-in RBF availability for coinjoins, but participants must maintain dedicated hashpower. Alternatively, anonymous Bitcoin nodes can be set up to query their mempools and mining pools for transaction confirmation. However, outsourcing this process is challenging unless privacy is not a concern. In that case, utilizing public explorers or centralized services to identify conflicting transactions is an option. Making transaction broadcasts more private using Tor/i2p or Dandelion can facilitate running anonymous bitcoind nodes. Investing in hashpower or running anonymous nodes are viable options to ensure transaction confirmation for untrusted peers.The email thread on bitcoin-dev focuses on joint funding protocols and detecting conflicts to ensure transaction confirmation. The main goal is to confirm transactions, but identifying conflicting transactions can also expose dishonest participants. One approach discussed involves setting up anonymous bitcoin nodes with realistic mempools and broadcasting the jointly funded transaction, then querying their mempools to check if the new transaction made it there. If not, it is highly likely that the blocking transaction is present. This method requires fewer capital expenses compared to maintaining dedicated hashpower but relies on the public peer-to-peer network to relay the transaction. For those unconcerned about privacy, querying an explorer or centralized service for conflicting transactions is an option. Running "anonymous" bitcoind nodes that don't announce transactions can provide a more private solution. It was suggested that making transaction broadcasts more private could facilitate running anonymous bitcoind nodes. 2022-11-07T11:46:28+00:00 + Antoine Riard has proposed a solution to the denial-of-service (DoS) issue in an opt-in replace-by-fee (RBF) world for coinjoins, splicing, and dual-funded transactions. His proposal involves deploying a distributed monitoring system called "mempools watchdog" to track network mempools. However, this infrastructure is vulnerable to mempool partitioning attacks by adversaries. To address this problem, victims could outsource the monitoring to dedicated entities, but there is a lack of compensation mechanism, resulting in few public options.Another challenge discussed is assigning blame reliably among trust-minimized joint funding protocol participants. This issue arises when multiple double-spends occur from sybilling participants, aiming to halt the assignment process. One suggestion to avoid this situation is for participants to not sign conflicting transactions, indicating their desire to remain part of the group. If someone does sign it, it signifies their intention to leave the group. Additionally, if participants want to abort the coinjoin but stay in the group, at least 51% of the remaining group members must agree.In a full RBF world, any participant should be able to fee-bump the joint transaction. However, it is advised to avoid coinjoins with an excessively large number of untrusted counterparties. In such cases, it is better to exclude cheating participants and split the remainder into smaller groups until a more reasonable size is achieved. Broadcasting a double-spend with an equivalent fee rate as the honest transaction does not tighten the attack scenario because the attacker can still employ low fee rate pinning that cannot be recovered by fee bumping the alternative.Anthony Towns discusses solutions for a DoS attack in the opt-in RBF world. The attack targets joint funding protocol participants and requires distributed monitoring of network mempools. However, this mempools watchdog infrastructure is susceptible to partitioning attacks, where adversaries manipulate local node mempool views. Outsourcing mempool monitoring encounters the issue of limited public resources and single-point-of-censorship vulnerability. The economic scalability of defensive infrastructure is also a concern due to the ongoing cat-and-mouse game between victims and attackers. Assigning blame reliably among joint funding protocol participants is another challenge, and introducing a UTXO-satoshi-weight vote is suggested for efficient assignment convergence.The discussion on the bitcoin-dev mailing list delves into handling conflicts when revalidating transactions without access to the transaction itself. One approach proposed using BIP 37 mempool filters, but this compromises privacy by revealing information to attackers. Investing in hashpower was suggested as an alternative solution, particularly when working with untrusted peers. Privacy-conscious individuals can run anonymous bitcoind nodes to check their mempool content. To facilitate this, transaction broadcasts can be made more private using methods like Tor/i2p or Dandelion. Querying an explorer or centralized service is also an option if privacy is not a concern. Overall, the aim of the discussion was to find better solutions for handling transaction conflicts in Bitcoin.The bitcoin-dev discussion revolves around assigning blame in coinjoin-like protocols and proposes using Tor hidden services (HS) to ping explorers. However, privacy methods like coinswap cannot utilize Tor HS. As the size of the coinjoin increases, the risk of gossiping a duplicitous double-spend among peers also rises. DoS concerns are less pronounced in dual funding Lightning Network channels due to the relatively small number of participants. Joint funding protocols can address the problem of opt-in RBF availability for coinjoins, but participants must maintain dedicated hashpower. Alternatively, anonymous Bitcoin nodes can be set up to query their mempools and mining pools for transaction confirmation. However, outsourcing this process is challenging unless privacy is not a concern. In that case, utilizing public explorers or centralized services to identify conflicting transactions is an option. Making transaction broadcasts more private using Tor/i2p or Dandelion can facilitate running anonymous bitcoind nodes. Investing in hashpower or running anonymous nodes are viable options to ensure transaction confirmation for untrusted peers.The email thread on bitcoin-dev focuses on joint funding protocols and detecting conflicts to ensure transaction confirmation. The main goal is to confirm transactions, but identifying conflicting transactions can also expose dishonest participants. One approach discussed involves setting up anonymous bitcoin nodes with realistic mempools and broadcasting the jointly funded transaction, then querying their mempools to check if the new transaction made it there. If not, it is highly likely that the blocking transaction is present. This method requires fewer capital expenses compared to maintaining dedicated hashpower but relies on the public peer-to-peer network to relay the transaction. For those unconcerned about privacy, querying an explorer or centralized service for conflicting transactions is an option. Running "anonymous" bitcoind nodes that don't announce transactions can provide a more private solution. It was suggested that making transaction broadcasts more private could facilitate running anonymous bitcoind nodes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Refreshed-BIP324.xml b/static/bitcoin-dev/Nov_2022/combined_Refreshed-BIP324.xml index cd4118e47b..6a500bea8e 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Refreshed-BIP324.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Refreshed-BIP324.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100274+00:00 - - Tim Ruffing 2023-10-11 20:52:52+00:00 - - - Erik Aronesty 2023-02-28 21:02:41+00:00 - - - Dhruv M 2023-02-28 18:07:06+00:00 - - - Anthony Towns 2023-02-21 16:03:37+00:00 - - - Pieter Wuille 2023-02-20 15:22:30+00:00 - - - Anthony Towns 2023-02-19 23:56:02+00:00 - - - Pieter Wuille 2023-02-17 22:13:05+00:00 - - - Anthony Towns 2023-02-17 15:51:19+00:00 - - - Dhruv M 2023-02-16 17:43:22+00:00 - - - Anthony Towns 2023-01-09 08:11:05+00:00 - - - Anthony Towns 2023-01-05 23:12:50+00:00 - - - Pieter Wuille 2023-01-05 22:06:29+00:00 - - - Anthony Towns 2022-11-18 08:24:49+00:00 - - - Yuval Kogman 2022-11-12 18:52:31+00:00 - - - Pieter Wuille 2022-11-12 03:23:16+00:00 - - - Pieter Wuille 2022-11-10 21:23:44+00:00 - - - Anthony Towns 2022-11-08 03:20:23+00:00 - - - Jonas Schnelli 2022-11-03 22:26:54+00:00 - - - Murch 2022-11-03 17:53:26+00:00 - - - Vasil Dimov 2022-10-27 07:28:38+00:00 - - - Pieter Wuille 2022-10-26 16:39:02+00:00 - - - Dhruv M 2022-10-08 12:59:58+00:00 - + 2025-09-26T14:29:50.746227+00:00 + python-feedgen + + + [bitcoin-dev] Refreshed BIP324 Dhruv M + 2022-10-08T12:59:00.000Z + + + Pieter Wuille + 2022-10-26T16:39:00.000Z + + + Vasil Dimov + 2022-10-27T07:28:00.000Z + + + Murch + 2022-11-03T17:53:00.000Z + + + Jonas Schnelli + 2022-11-03T22:26:00.000Z + + + Anthony Towns + 2022-11-08T03:20:00.000Z + + + Pieter Wuille + 2022-11-10T21:23:00.000Z + + + Pieter Wuille + 2022-11-12T03:23:00.000Z + + + Yuval Kogman + 2022-11-12T18:52:00.000Z + + + Anthony Towns + 2022-11-18T08:24:00.000Z + + + Pieter Wuille + 2023-01-05T22:06:00.000Z + + + Anthony Towns + 2023-01-05T23:12:00.000Z + + + Anthony Towns + 2023-01-09T08:11:00.000Z + + + Dhruv M + 2023-02-16T17:43:00.000Z + + + Anthony Towns + 2023-02-17T15:51:00.000Z + + + Pieter Wuille + 2023-02-17T22:13:00.000Z + + + Anthony Towns + 2023-02-19T23:56:00.000Z + + + Pieter Wuille + 2023-02-20T15:22:00.000Z + + + Anthony Towns + 2023-02-21T16:03:00.000Z + + + Dhruv M + 2023-02-28T18:07:00.000Z + + + Erik Aronesty + 2023-02-28T21:02:00.000Z + + + Tim Ruffing + 2023-10-11T20:52:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100469+00:00 + 2025-09-26T14:29:50.748365+00:00 - The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. 2023-10-11T20:52:52+00:00 + The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Relative-txout-amounts-with-a-Merkleized-Sum-Tree-and-explicit-miner-fee-.xml b/static/bitcoin-dev/Nov_2022/combined_Relative-txout-amounts-with-a-Merkleized-Sum-Tree-and-explicit-miner-fee-.xml index 046d7ba907..e08fb2d9b0 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Relative-txout-amounts-with-a-Merkleized-Sum-Tree-and-explicit-miner-fee-.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Relative-txout-amounts-with-a-Merkleized-Sum-Tree-and-explicit-miner-fee-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Relative txout amounts with a Merkleized Sum Tree and explicit miner fee. - 2023-08-02T08:34:18.369441+00:00 - - Rijndael 2022-11-26 00:12:10+00:00 - - - ZmnSCPxj 2022-11-21 23:52:00+00:00 - - - Andrew Melnychuk Oseen 2022-11-18 21:11:54+00:00 - + 2025-09-26T14:29:29.400776+00:00 + python-feedgen + + + [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree and explicit miner fee Andrew Melnychuk Oseen + 2022-11-18T21:11:00.000Z + + + ZmnSCPxj + 2022-11-21T23:52:00.000Z + + + Rijndael + 2022-11-26T00:12:00.000Z + + - python-feedgen + 2 Combined summary - Relative txout amounts with a Merkleized Sum Tree and explicit miner fee. - 2023-08-02T08:34:18.369441+00:00 + 2025-09-26T14:29:29.401343+00:00 - In response to Andrew's query about mapping output amounts to a tap branch for secure partial spends of a single UTXO, ZmnSCPxj suggests exploring covenant schemes, specifically the tree structures for `OP_CHECKTEMPLATEVERIFY`. While Taproot has multiple leaves, only one leaf will consume the entire input amount. To address this issue, ZmnSCPxj recommends using multiple tree leaves that will eventually be published, which can be achieved through `OP_CHECKTEMPLATEVERIFY`. Without this opcode, presigned transactions in a tree structure can be used, but they are known to be larger than `OP_CHECKTEMPLATEVERIFY`.Rijndael also suggests that Andrew looks into `TAPLEAF_UPDATE_VERIFY`, which is similar to his proposed solution. By examining both `TAPLEAF_UPDATE_VERIFY` and `OP_CHECKTEMPLATEVERIFY`, Andrew can gain a better understanding of covenant schemes and how they can be utilized in his project.The email conversation revolves around mapping output amounts to a tap branch for secure partial spends of a single UTXO. The challenge lies in the fact that only one tap branch will consume the entire input amount. The solution proposed is to have multiple tree leaves that will eventually be published. The writer recommends exploring the tree structures for `OP_CHECKTEMPLATEVERIFY`, as they align with the desired outcome and can help make `OP_CTV` a reality. If `OP_CHECKTEMPLATEVERIFY` is not used, presigned transactions in a tree structure can be employed, although they are known to be larger.The author seeks feedback on an idea regarding mapping output amounts to a tap branch for secure partial spends of a single UTXO. This involves defining the Merkel tree root tweak and tree branch and leaf using tagged hash, left and right hash, and relative output amount. Transaction validation includes a negative output amount that flags the transaction as a relative amount spend, with the miner fee being the absolute of the output amount. The author poses several questions, such as whether this idea would require a hard fork, if the sum is required in the asset tree, how big a taproot tree can become before it becomes cumbersome, and whether multiple taproot trees can be placed inside a tweak.Potential benefits of this approach include slightly increased privacy of output amounts and reduced growth rate of UTXOs. However, drawbacks may include disabling the ability for output change addresses to be the same as inputs, as the spending amounts are absolute. An example transaction is provided, demonstrating inputs and outputs. Additionally, the author suggests that this idea could facilitate the onboarding of numerous lightning channels with a single UTXO output. An exchange, for instance, could schedule open lightning channels at specific time intervals, with individuals providing pubkeys and payment to be placed in a tap leaf, similar to selling seats for an aircraft flight. 2022-11-26T00:12:10+00:00 + In response to Andrew's query about mapping output amounts to a tap branch for secure partial spends of a single UTXO, ZmnSCPxj suggests exploring covenant schemes, specifically the tree structures for `OP_CHECKTEMPLATEVERIFY`. While Taproot has multiple leaves, only one leaf will consume the entire input amount. To address this issue, ZmnSCPxj recommends using multiple tree leaves that will eventually be published, which can be achieved through `OP_CHECKTEMPLATEVERIFY`. Without this opcode, presigned transactions in a tree structure can be used, but they are known to be larger than `OP_CHECKTEMPLATEVERIFY`.Rijndael also suggests that Andrew looks into `TAPLEAF_UPDATE_VERIFY`, which is similar to his proposed solution. By examining both `TAPLEAF_UPDATE_VERIFY` and `OP_CHECKTEMPLATEVERIFY`, Andrew can gain a better understanding of covenant schemes and how they can be utilized in his project.The email conversation revolves around mapping output amounts to a tap branch for secure partial spends of a single UTXO. The challenge lies in the fact that only one tap branch will consume the entire input amount. The solution proposed is to have multiple tree leaves that will eventually be published. The writer recommends exploring the tree structures for `OP_CHECKTEMPLATEVERIFY`, as they align with the desired outcome and can help make `OP_CTV` a reality. If `OP_CHECKTEMPLATEVERIFY` is not used, presigned transactions in a tree structure can be employed, although they are known to be larger.The author seeks feedback on an idea regarding mapping output amounts to a tap branch for secure partial spends of a single UTXO. This involves defining the Merkel tree root tweak and tree branch and leaf using tagged hash, left and right hash, and relative output amount. Transaction validation includes a negative output amount that flags the transaction as a relative amount spend, with the miner fee being the absolute of the output amount. The author poses several questions, such as whether this idea would require a hard fork, if the sum is required in the asset tree, how big a taproot tree can become before it becomes cumbersome, and whether multiple taproot trees can be placed inside a tweak.Potential benefits of this approach include slightly increased privacy of output amounts and reduced growth rate of UTXOs. However, drawbacks may include disabling the ability for output change addresses to be the same as inputs, as the spending amounts are absolute. An example transaction is provided, demonstrating inputs and outputs. Additionally, the author suggests that this idea could facilitate the onboarding of numerous lightning channels with a single UTXO output. An exchange, for instance, could schedule open lightning channels at specific time intervals, with individuals providing pubkeys and payment to be placed in a tap leaf, similar to selling seats for an aircraft flight. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Removing-BIP-125-Rule-5-Pinning-with-the-Always-Replaceable-Invariant.xml b/static/bitcoin-dev/Nov_2022/combined_Removing-BIP-125-Rule-5-Pinning-with-the-Always-Replaceable-Invariant.xml index a2cce43875..dd85c1c2ba 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Removing-BIP-125-Rule-5-Pinning-with-the-Always-Replaceable-Invariant.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Removing-BIP-125-Rule-5-Pinning-with-the-Always-Replaceable-Invariant.xml @@ -1,27 +1,49 @@ - + 2 Combined summary - Removing BIP-125 Rule #5 Pinning with the Always-Replaceable Invariant - 2023-08-02T08:26:05.083482+00:00 - - Peter Todd 2022-11-07 21:27:16+00:00 - - - Suhas Daftuar 2022-11-07 21:21:11+00:00 - - - Peter Todd 2022-11-07 20:17:29+00:00 - + 2025-09-26T14:29:48.593457+00:00 + python-feedgen + + + [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replaceable Invariant Peter Todd + 2022-11-07T20:17:00.000Z + + + [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime Peter Todd + 2022-11-07T21:17:00.000Z + + + [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replaceable Invariant Suhas Daftuar + 2022-11-07T21:21:00.000Z + + + Peter Todd + 2022-11-07T21:27:00.000Z + + + Antoine Riard + 2022-11-07T22:55:00.000Z + + + Peter Todd + 2022-11-09T12:41:00.000Z + + + David A. Harding + 2022-11-11T03:00:00.000Z + + - python-feedgen + 2 Combined summary - Removing BIP-125 Rule #5 Pinning with the Always-Replaceable Invariant - 2023-08-02T08:26:05.083482+00:00 + 2025-09-26T14:29:48.594249+00:00 - In a message posted on the Bitcoin-dev mailing list, Suhas Daftuar pointed out a flaw in the proposal to limit the number of descendants of each in-mempool transaction. The issue arises from the fact that a single transaction can conflict with multiple in-mempool transactions, as Bitcoin transactions can have multiple inputs. This could lead to more evictions than intended. Peter Todd suggested a solution by summing up the number of nReplacementCandidates for each input in the multiple input case. The objective is to ensure that a transaction can always be replaced by double-spending an output to defeat pinning, rather than making every possible way of double-spending multiple outputs work.To address the pinning problem caused by Rule #5 of BIP-125, which limits the number of original transactions and their descendant transactions that can be replaced and evicted from the mempool, the Replaceability Invariant has been proposed. The goal of this proposal is to ensure that all transactions in the mempool are always replaceable, thereby eliminating the need for Rule #5. The Replaceability Invariant involves assigning an integer, nReplacementCandidates, to each transaction. When a non-conflicting transaction is accepted into the mempool, the nReplacementCandidates value is incremented by 1 for each unconfirmed parent. Conflicting transactions do not require verification as the invariant guarantees their replaceability. When a block is mined, the nReplacementCandidates of all unconfirmed transactions remains unchanged since a confirmed transaction cannot spend an unconfirmed txout. A special case is needed to handle reorgs that change a transaction from confirmed to unconfirmed, where setting nReplacementCandidates to MAX_REPLACEMENT_CANDIDATES would suffice. The proposal also acknowledges that accommodating diamond tx graphs is unnecessary as they are even more unusual than unconfirmed children.Currently, Bitcoin Core implements rule #5 of BIP-125, which limits the number of original transactions and their descendant transactions that can be replaced in the mempool to a total of 100. However, this rule lacks justification beyond avoiding excessive computational work and may not be necessary considering the natural limits imposed by the overall mempool size. To avoid pinning caused by rule #5, the Replaceability Invariant can be implemented. This invariant ensures that no transaction is accepted into the mempool if it would prevent another transaction from being replaced due to Rule #5. Implementing the Replaceability Invariant is straightforward: for each transaction, maintain an integer called nReplacementCandidates. When evaluating a non-conflicting transaction for acceptance into the mempool, verify that nReplacementCandidates + 1 does not exceed the MAX_REPLACEMENT_CANDIDATES limit. If the limit is exceeded, reject the new transaction. By guaranteeing the replaceability of all transactions in the mempool, the problem of Rule #5 pinning can be resolved. 2022-11-07T21:27:16+00:00 + In a message posted on the Bitcoin-dev mailing list, Suhas Daftuar pointed out a flaw in the proposal to limit the number of descendants of each in-mempool transaction. The issue arises from the fact that a single transaction can conflict with multiple in-mempool transactions, as Bitcoin transactions can have multiple inputs. This could lead to more evictions than intended. Peter Todd suggested a solution by summing up the number of nReplacementCandidates for each input in the multiple input case. The objective is to ensure that a transaction can always be replaced by double-spending an output to defeat pinning, rather than making every possible way of double-spending multiple outputs work.To address the pinning problem caused by Rule #5 of BIP-125, which limits the number of original transactions and their descendant transactions that can be replaced and evicted from the mempool, the Replaceability Invariant has been proposed. The goal of this proposal is to ensure that all transactions in the mempool are always replaceable, thereby eliminating the need for Rule #5. The Replaceability Invariant involves assigning an integer, nReplacementCandidates, to each transaction. When a non-conflicting transaction is accepted into the mempool, the nReplacementCandidates value is incremented by 1 for each unconfirmed parent. Conflicting transactions do not require verification as the invariant guarantees their replaceability. When a block is mined, the nReplacementCandidates of all unconfirmed transactions remains unchanged since a confirmed transaction cannot spend an unconfirmed txout. A special case is needed to handle reorgs that change a transaction from confirmed to unconfirmed, where setting nReplacementCandidates to MAX_REPLACEMENT_CANDIDATES would suffice. The proposal also acknowledges that accommodating diamond tx graphs is unnecessary as they are even more unusual than unconfirmed children.Currently, Bitcoin Core implements rule #5 of BIP-125, which limits the number of original transactions and their descendant transactions that can be replaced in the mempool to a total of 100. However, this rule lacks justification beyond avoiding excessive computational work and may not be necessary considering the natural limits imposed by the overall mempool size. To avoid pinning caused by rule #5, the Replaceability Invariant can be implemented. This invariant ensures that no transaction is accepted into the mempool if it would prevent another transaction from being replaced due to Rule #5. Implementing the Replaceability Invariant is straightforward: for each transaction, maintain an integer called nReplacementCandidates. When evaluating a non-conflicting transaction for acceptance into the mempool, verify that nReplacementCandidates + 1 does not exceed the MAX_REPLACEMENT_CANDIDATES limit. If the limit is exceeded, reject the new transaction. By guaranteeing the replaceability of all transactions in the mempool, the problem of Rule #5 pinning can be resolved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Solving-Multi-Party-Flows-Pinning-with-Opt-in-Full-RBF-Spent-nVersion-Signaling.xml b/static/bitcoin-dev/Nov_2022/combined_Solving-Multi-Party-Flows-Pinning-with-Opt-in-Full-RBF-Spent-nVersion-Signaling.xml index 69cfc8643f..303a46670b 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Solving-Multi-Party-Flows-Pinning-with-Opt-in-Full-RBF-Spent-nVersion-Signaling.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Solving-Multi-Party-Flows-Pinning-with-Opt-in-Full-RBF-Spent-nVersion-Signaling.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling - 2023-08-02T08:21:36.331219+00:00 - - Greg Sanders 2022-11-02 15:00:47+00:00 - - - Peter Todd 2022-11-02 14:33:51+00:00 - - - Greg Sanders 2022-11-02 14:19:00+00:00 - - - Peter Todd 2022-11-02 14:04:03+00:00 - - - Greg Sanders 2022-11-02 13:58:59+00:00 - - - Antoine Riard 2022-11-02 02:21:59+00:00 - + 2025-09-26T14:29:44.346545+00:00 + python-feedgen + + + [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling Antoine Riard + 2022-11-02T02:21:00.000Z + + + Greg Sanders + 2022-11-02T13:58:00.000Z + + + Peter Todd + 2022-11-02T14:04:00.000Z + + + Greg Sanders + 2022-11-02T14:19:00.000Z + + + Peter Todd + 2022-11-02T14:33:00.000Z + + + Greg Sanders + 2022-11-02T15:00:00.000Z + + - python-feedgen + 2 Combined summary - Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling - 2023-08-02T08:21:36.331219+00:00 + 2025-09-26T14:29:44.347471+00:00 - The impact of rule #3 and rule #5 on coinjoin scenarios is discussed in the conversation. Despite the implementation of fullrbf-everywhere and V3, pinning can still be an issue. Rule #5 violations are contained to coinjoins with around 50 peers, but there is no technical reason for this rule to exist other than being a conservative DoS limit. Exploiting these rules requires money, and while their existence may not be guaranteed, they do currently affect operations. Attackers have more at stake and can be booted from the protocol if they pay the price and get mined.In an email exchange, Greg Sanders highlights that pinning remains an issue in coinjoin scenarios despite fullrbf-everywhere and V3. Adversaries can double-spend their coins either to full package weight or give 24 descendants, resulting in paying more or being excluded from RBFing if there are four or more adversaries violating rule #5. Narrowing the policy to mark transaction outputs as opt-in to V3 can restrict rule #5 violations to coinjoins with approximately 50 peers. However, the existence of rule #5 has no concrete technical justification and simply serves as a conservative DoS limit. It is uncertain whether these rules will continue to exist, but their exploitation incurs costs.On the bitcoin-dev mailing list, Antoine Riard proposes using zeroconf as a solution to address multi-party funding pinning. However, Peter Todd opposes this idea, arguing that zeroconf is a marginal use case with potential privacy trade-offs and engineering costs. He suggests adopting full-RBF instead to eliminate the privacy harm caused by opt-in-RBF. Greg Maxwell adds in a subsequent email that even with fullrbf-everywhere and V3, pinning via rule #3 and rule #5 remains an issue in coinjoin scenarios. Each adversary in a coinjoin can double-spend their coin, leading to paying more or being excluded from RBFing if there are four or more adversaries violating rule #5. While narrowing the policy to opt-in V3 marking is interesting, double-spending counterparties can still cause pain per peer through rule #3. Rule #5 violations, however, are contained within coinjoins with approximately 50 peers. The exploration of this approach is speculative but worth considering.Antoine Riard proposes an alternative solution to address pinning in multi-party collaborative flows by adopting a zeroconf-like mechanism. However, Peter Todd strongly disagrees, stating that incurring engineering costs and compromising privacy for a marginal use case like zeroconf is unreasonable. He suggests moving towards full-RBF to undo the privacy cost of opt-in-RBF. He also notes that achieving zeroconf will become even harder due to diminishing mempool consistency in the future. The only supporters of zeroconf are Bitrefill and Muun, with the latter working to eliminate its vulnerability to it. Attempts to secure zeroconf have involved sybil attacks against the network to measure transaction propagation.Antoine Riard proposes a new policy to address the issue of low-cost and high-success DoS vector in multi-party funding flows. The problem arises when participants combining inputs lack control or visibility over potential double-spends by other participants. Antoine suggests marking all coins' nVersion fields as opting for fullrbf to work around this issue for contracting protocols wallets. However, this policy marking becomes a protocol fingerprint leak for observers of transaction logs. In the long term, assuming all wallets will be Lightning wallets, this privacy issue could lead to most wallets signaling RBF for their spends, making them incompatible with zeroconf services and gradually outlawing them. Antoine sees this as an alternative way forward, allowing users to decide with their coins instead of miners enforcing the policy.The challenge of pinning contracting protocols funding flows with opt-out double-spends can be addressed by implementing an opt-in Full-Replace-by-Fee Spent-nVersion Signaling policy. This addresses the low-cost and high-success DoS vector in multi-party collaborative flows, where a single input can harm the remaining inputs or engage in MEV attacks. The proposed solution involves considering a confirmed transaction as opting-in for replacement if the last bit of the nVersion field is set. This protects participants in multi-party flows from pinning due to opt-out double-spends. However, there are engineering challenges related to accessing the spent nVersion fields in mempool logic. For contracting protocols wallets, marking all coins' nVersion fields as opting for fullrbf is a better approach if they don't know which coins will be used in a collaborative flow. However, this policy marking becomes a protocol fingerprint leak. Zeroconf operators can inspect the ancestors' nVersion fields of receiving transactions to identify replaceable transactions. In the long term, the efficiency of this new policy enforcement relies on relay paths and support at the miner mempools. Incentive alignment with hashrate is crucial for transaction-relay rules. Greg Maxwell is 2022-11-02T15:00:47+00:00 + The impact of rule #3 and rule #5 on coinjoin scenarios is discussed in the conversation. Despite the implementation of fullrbf-everywhere and V3, pinning can still be an issue. Rule #5 violations are contained to coinjoins with around 50 peers, but there is no technical reason for this rule to exist other than being a conservative DoS limit. Exploiting these rules requires money, and while their existence may not be guaranteed, they do currently affect operations. Attackers have more at stake and can be booted from the protocol if they pay the price and get mined.In an email exchange, Greg Sanders highlights that pinning remains an issue in coinjoin scenarios despite fullrbf-everywhere and V3. Adversaries can double-spend their coins either to full package weight or give 24 descendants, resulting in paying more or being excluded from RBFing if there are four or more adversaries violating rule #5. Narrowing the policy to mark transaction outputs as opt-in to V3 can restrict rule #5 violations to coinjoins with approximately 50 peers. However, the existence of rule #5 has no concrete technical justification and simply serves as a conservative DoS limit. It is uncertain whether these rules will continue to exist, but their exploitation incurs costs.On the bitcoin-dev mailing list, Antoine Riard proposes using zeroconf as a solution to address multi-party funding pinning. However, Peter Todd opposes this idea, arguing that zeroconf is a marginal use case with potential privacy trade-offs and engineering costs. He suggests adopting full-RBF instead to eliminate the privacy harm caused by opt-in-RBF. Greg Maxwell adds in a subsequent email that even with fullrbf-everywhere and V3, pinning via rule #3 and rule #5 remains an issue in coinjoin scenarios. Each adversary in a coinjoin can double-spend their coin, leading to paying more or being excluded from RBFing if there are four or more adversaries violating rule #5. While narrowing the policy to opt-in V3 marking is interesting, double-spending counterparties can still cause pain per peer through rule #3. Rule #5 violations, however, are contained within coinjoins with approximately 50 peers. The exploration of this approach is speculative but worth considering.Antoine Riard proposes an alternative solution to address pinning in multi-party collaborative flows by adopting a zeroconf-like mechanism. However, Peter Todd strongly disagrees, stating that incurring engineering costs and compromising privacy for a marginal use case like zeroconf is unreasonable. He suggests moving towards full-RBF to undo the privacy cost of opt-in-RBF. He also notes that achieving zeroconf will become even harder due to diminishing mempool consistency in the future. The only supporters of zeroconf are Bitrefill and Muun, with the latter working to eliminate its vulnerability to it. Attempts to secure zeroconf have involved sybil attacks against the network to measure transaction propagation.Antoine Riard proposes a new policy to address the issue of low-cost and high-success DoS vector in multi-party funding flows. The problem arises when participants combining inputs lack control or visibility over potential double-spends by other participants. Antoine suggests marking all coins' nVersion fields as opting for fullrbf to work around this issue for contracting protocols wallets. However, this policy marking becomes a protocol fingerprint leak for observers of transaction logs. In the long term, assuming all wallets will be Lightning wallets, this privacy issue could lead to most wallets signaling RBF for their spends, making them incompatible with zeroconf services and gradually outlawing them. Antoine sees this as an alternative way forward, allowing users to decide with their coins instead of miners enforcing the policy.The challenge of pinning contracting protocols funding flows with opt-out double-spends can be addressed by implementing an opt-in Full-Replace-by-Fee Spent-nVersion Signaling policy. This addresses the low-cost and high-success DoS vector in multi-party collaborative flows, where a single input can harm the remaining inputs or engage in MEV attacks. The proposed solution involves considering a confirmed transaction as opting-in for replacement if the last bit of the nVersion field is set. This protects participants in multi-party flows from pinning due to opt-out double-spends. However, there are engineering challenges related to accessing the spent nVersion fields in mempool logic. For contracting protocols wallets, marking all coins' nVersion fields as opting for fullrbf is a better approach if they don't know which coins will be used in a collaborative flow. However, this policy marking becomes a protocol fingerprint leak. Zeroconf operators can inspect the ancestors' nVersion fields of receiving transactions to identify replaceable transactions. In the long term, the efficiency of this new policy enforcement relies on relay paths and support at the miner mempools. Incentive alignment with hashrate is crucial for transaction-relay rules. Greg Maxwell is - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml b/static/bitcoin-dev/Nov_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml index 04c7b66823..0d262e5d4c 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Taro: A Taproot Asset Representation Overlay - 2023-08-02T05:59:12.664244+00:00 - - Johan Torås Halseth 2022-11-07 13:51:12+00:00 - - - Olaoluwa Osuntokun 2022-11-05 00:35:53+00:00 - - - Johan Torås Halseth 2022-11-03 09:26:05+00:00 - - - Olaoluwa Osuntokun 2022-10-19 02:40:13+00:00 - - - Olaoluwa Osuntokun 2022-04-16 02:43:08+00:00 - - - Ruben Somsen 2022-04-15 13:14:40+00:00 - - - Bram Cohen 2022-04-11 21:29:31+00:00 - - - Olaoluwa Osuntokun 2022-04-11 19:51:55+00:00 - - - Olaoluwa Osuntokun 2022-04-11 18:21:14+00:00 - - - Bram Cohen 2022-04-11 00:30:29+00:00 - - - Ruben Somsen 2022-04-10 16:51:52+00:00 - - - Olaoluwa Osuntokun 2022-04-08 17:49:28+00:00 - - - Olaoluwa Osuntokun 2022-04-08 17:48:02+00:00 - - - Alex Schoof 2022-04-07 19:11:39+00:00 - - - Ruben Somsen 2022-04-07 17:14:03+00:00 - - - ZmnSCPxj 2022-04-06 00:43:23+00:00 - - - vjudeu at gazeta.pl 2022-04-05 20:23:05+00:00 - - - Olaoluwa Osuntokun 2022-04-05 15:06:03+00:00 - + 2025-09-26T14:29:35.813324+00:00 + python-feedgen + + + [bitcoin-dev] Taro: A Taproot Asset Representation Overlay Olaoluwa Osuntokun + 2022-04-05T15:06:00.000Z + + + [bitcoin-dev] " vjudeu + 2022-04-05T20:23:00.000Z + + + ZmnSCPxj + 2022-04-06T00:43:00.000Z + + + Ruben Somsen + 2022-04-07T17:14:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Alex Schoof + 2022-04-07T19:11:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2022-04-08T17:48:00.000Z + + + Olaoluwa Osuntokun + 2022-04-08T17:49:00.000Z + + + Ruben Somsen + 2022-04-10T16:51:00.000Z + + + Bram Cohen + 2022-04-11T00:30:00.000Z + + + Olaoluwa Osuntokun + 2022-04-11T18:21:00.000Z + + + Olaoluwa Osuntokun + 2022-04-11T19:51:00.000Z + + + Bram Cohen + 2022-04-11T21:29:00.000Z + + + Ruben Somsen + 2022-04-15T13:14:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2022-04-16T02:43:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Olaoluwa Osuntokun + 2022-10-19T02:40:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Johan Torås Halseth + 2022-11-03T09:26:00.000Z + + + Olaoluwa Osuntokun + 2022-11-05T00:35:00.000Z + + + Johan Torås Halseth + 2022-11-07T13:51:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Taro: A Taproot Asset Representation Overlay - 2023-08-02T05:59:12.664244+00:00 + 2025-09-26T14:29:35.815304+00:00 - During a discussion about the "utxo teleport" scheme, Johan and Olaoluwa express their opinions on its soundness and compatibility with LN channels. Johan believes that as long as tokens are not sent to a spent UTXO, the scheme is sound. However, he agrees with Olaoluwa's concern about losing the blockchain as the main synchronization point. Olaoluwa argues that the scheme may not be sound because the UTXO may no longer exist when the transaction hits the chain, and there is no total ordering for safety.In contrast, Taro's state transition model ensures everything is bound to a single synchronization point and has re-org safety traits like regular Bitcoin transactions. Olaoluwa also points out that the "utxo teleport" scheme is not ideal for anchoring assets in channels. With Taro, assets are committed to the funding output when the channel is created, providing better visibility. Additionally, the "utxo teleport" scheme requires additional synchronization, while Taro creates an on-chain taproot output that directly creates the new asset anchor/output. The sender and receiver can use the blockchain itself as a synchronization point.Johan suggests adding a "teleport" feature to Taro, which would allow token transfer to already spent TXOs, burning the tokens. This feature could be beneficial for LN channels, enabling the addition or topping up of tokens in open channels with proof of token transfer.Ruben raises concerns about the RGB protocol, which he believes apply to Taro as well. He notes that the Taro script is not enforced by Bitcoin, so those controlling the Bitcoin script can choose to ignore the Taro script and destroy Taro assets. However, Ruben acknowledges that Taro's design predates RGB and seems to have inspired it.The email exchange discusses issues with verifying asset provenance in Taro's specifications. Hiroki Gondo points out the possibility of asset inflation if an illicit copy of a UTXO is created in the asset tree. Laolu acknowledges the issue and mentions that they aim to address it by assuming a "no-op" state transition in the current spec. Gondo suggests setting a constraint that only explicitly changed UTXOs should change, rather than generating proofs for every unchanging UTXO.Olaoluwa announces the Taro protocol, which uses the Taproot script tree and MS-SMT hybrid merkle tree for tokenization and asset issuance on the Bitcoin chain. They mention that Taro supports Lightning Network integration and efficient proofs of non-existence.The email exchange explores the feasibility of adding a scripting language to Taro. Ruben argues that using Bitcoin script without an additional scripting language inside Taro is sufficient. Olaoluwa proposes an "issuance covenant" design sketch for certain collateralization requirements, which Ruben acknowledges could be useful. They also discuss the deterministic location of the Taro tree in the taproot tree and propose solutions.In another email exchange, Bram Cohen and Olaoluwa discuss witnesses in transactions and the potential usage of the annex field in taproot transactions. They talk about implementing partial reveal of data in the annex field and the philosophical question of its reserved use. They also discuss Taro's single event issuance and the provision for future issuance associated with discrete IDs under a single identifier. They address the terminology used for Taro assets, preferring to use widely used asset issuance/minting terminology instead of "colored coins."The email exchange further discusses the potential scripting layer in Taro, including a design sketch for an "issuance covenant" and the usage of Bitcoin covenants to enforce spending conditions on Taro assets. The email acknowledges that there are still questions to answer regarding the feasibility of these ideas.The email exchange between Olaoluwa Osuntokun and Bram Cohen discusses the limitations and tradeoffs of the Taro system. Witnesses for transactions need to be put into Bitcoin transactions despite the Bitcoin layer not understanding them. There needs to be a constraint on Taro transactions that is understood by the Bitcoin layer. Taro issuance is limited to a single event rather than potentially multiple events subject to special per-asset rules. Multiple Taro coins cannot consolidate their value into a single output because they only support a single linear history. Despite these limitations, there is nothing wrong with a system having well-documented limitations.Ruben and Olaoluwa discuss the Taro documentation and its relationship with RGB. Ruben had a bad experience with RGB's documentation and suggests rebuilding Taro from scratch. However, he believes Taro should still credit RGB in its documentation. The limitations of Taro in building scripting support were also discussed, where only certain types of smart contracts could be built due to Bitcoin's limitations in enforcing them. The conversation moved on to ways in which both RGB and Taro can prevent double spending or duplicate assets. Ruben explains potential issues with Taro's system, such as asset issuers choosing to issue assets in denomin 2022-11-07T13:51:12+00:00 + During a discussion about the "utxo teleport" scheme, Johan and Olaoluwa express their opinions on its soundness and compatibility with LN channels. Johan believes that as long as tokens are not sent to a spent UTXO, the scheme is sound. However, he agrees with Olaoluwa's concern about losing the blockchain as the main synchronization point. Olaoluwa argues that the scheme may not be sound because the UTXO may no longer exist when the transaction hits the chain, and there is no total ordering for safety.In contrast, Taro's state transition model ensures everything is bound to a single synchronization point and has re-org safety traits like regular Bitcoin transactions. Olaoluwa also points out that the "utxo teleport" scheme is not ideal for anchoring assets in channels. With Taro, assets are committed to the funding output when the channel is created, providing better visibility. Additionally, the "utxo teleport" scheme requires additional synchronization, while Taro creates an on-chain taproot output that directly creates the new asset anchor/output. The sender and receiver can use the blockchain itself as a synchronization point.Johan suggests adding a "teleport" feature to Taro, which would allow token transfer to already spent TXOs, burning the tokens. This feature could be beneficial for LN channels, enabling the addition or topping up of tokens in open channels with proof of token transfer.Ruben raises concerns about the RGB protocol, which he believes apply to Taro as well. He notes that the Taro script is not enforced by Bitcoin, so those controlling the Bitcoin script can choose to ignore the Taro script and destroy Taro assets. However, Ruben acknowledges that Taro's design predates RGB and seems to have inspired it.The email exchange discusses issues with verifying asset provenance in Taro's specifications. Hiroki Gondo points out the possibility of asset inflation if an illicit copy of a UTXO is created in the asset tree. Laolu acknowledges the issue and mentions that they aim to address it by assuming a "no-op" state transition in the current spec. Gondo suggests setting a constraint that only explicitly changed UTXOs should change, rather than generating proofs for every unchanging UTXO.Olaoluwa announces the Taro protocol, which uses the Taproot script tree and MS-SMT hybrid merkle tree for tokenization and asset issuance on the Bitcoin chain. They mention that Taro supports Lightning Network integration and efficient proofs of non-existence.The email exchange explores the feasibility of adding a scripting language to Taro. Ruben argues that using Bitcoin script without an additional scripting language inside Taro is sufficient. Olaoluwa proposes an "issuance covenant" design sketch for certain collateralization requirements, which Ruben acknowledges could be useful. They also discuss the deterministic location of the Taro tree in the taproot tree and propose solutions.In another email exchange, Bram Cohen and Olaoluwa discuss witnesses in transactions and the potential usage of the annex field in taproot transactions. They talk about implementing partial reveal of data in the annex field and the philosophical question of its reserved use. They also discuss Taro's single event issuance and the provision for future issuance associated with discrete IDs under a single identifier. They address the terminology used for Taro assets, preferring to use widely used asset issuance/minting terminology instead of "colored coins."The email exchange further discusses the potential scripting layer in Taro, including a design sketch for an "issuance covenant" and the usage of Bitcoin covenants to enforce spending conditions on Taro assets. The email acknowledges that there are still questions to answer regarding the feasibility of these ideas.The email exchange between Olaoluwa Osuntokun and Bram Cohen discusses the limitations and tradeoffs of the Taro system. Witnesses for transactions need to be put into Bitcoin transactions despite the Bitcoin layer not understanding them. There needs to be a constraint on Taro transactions that is understood by the Bitcoin layer. Taro issuance is limited to a single event rather than potentially multiple events subject to special per-asset rules. Multiple Taro coins cannot consolidate their value into a single output because they only support a single linear history. Despite these limitations, there is nothing wrong with a system having well-documented limitations.Ruben and Olaoluwa discuss the Taro documentation and its relationship with RGB. Ruben had a bad experience with RGB's documentation and suggests rebuilding Taro from scratch. However, he believes Taro should still credit RGB in its documentation. The limitations of Taro in building scripting support were also discussed, where only certain types of smart contracts could be built due to Bitcoin's limitations in enforcing them. The conversation moved on to ways in which both RGB and Taro can prevent double spending or duplicate assets. Ruben explains potential issues with Taro's system, such as asset issuers choosing to issue assets in denomin - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml b/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml index d0a655fd44..928b95fbb4 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime - 2023-08-02T08:26:22.532496+00:00 + 2025-09-26T14:29:40.120226+00:00 + python-feedgen David A. Harding 2022-11-11 03:00:58+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime - 2023-08-02T08:26:22.532496+00:00 + 2025-09-26T14:29:40.120366+00:00 - In a recent email thread on the bitcoin-dev mailing list, Peter Todd proposed a solution to address Rule #3 pinning in multi-party transactions. The attack involves one party broadcasting a low fee transaction that ties up funds from other parties, making it difficult for them to spend their inputs unless they pay for the malicious party's transaction. Todd's solution involves pre-signing transactions with nLockTime set far into the future and spending one or more inputs of the transaction with a high enough fee to replace any attempts to exploit the rule.However, there are several open questions and challenges associated with this solution. One issue is determining the high fee needed to guarantee replacements with high odds. Since the sat/vb (satoshi per virtual byte) is unknown at the time of signature exchange among participants, overshooting and adopting a historical worst-case mempool feerate may be necessary. This introduces economic lower bounds on the funds involved in a contract, creating a griefing vector where a participant could deliberately pin to inflict asymmetric damage without entering into any fee competition.To address these challenges, participants may consider unilaterally spending after a protocol/implementation timepoint to save the time value of their contributed UTXOs over operation success. Additionally, a proposed more workable solution is to rely on package-relay, an ephemeral anchor output, and a special replacement regime (e.g., nVersion=3). This would allow the multi-party funded transaction coordinator to unilateral fee-bump, step-by-step, without relying on assumptions about the knowledge of network mempools and burning excessive fees.The email exchange between Antoine and Peter Todd also highlights the issue of incentive compatibility when considering miner harvesting attacks as part of the threat model. It remains unclear if the v3 rules that depend on miners arbitrarily rejecting transactions from their mempools are sufficiently incentive compatible to work effectively.Overall, the Bitcoin community is actively discussing ways to prevent pinning attacks on multi-party transactions. Implementing pre-signed transactions with nLockTime set in the future and utilizing a combination of package-relay, an ephemeral anchor output, and a special replacement regime could potentially address this issue. However, there are still challenges to be addressed, such as determining the appropriate fee and ensuring incentive compatibility in the face of potential miner harvesting attacks. 2022-11-11T03:00:58+00:00 + In a recent email thread on the bitcoin-dev mailing list, Peter Todd proposed a solution to address Rule #3 pinning in multi-party transactions. The attack involves one party broadcasting a low fee transaction that ties up funds from other parties, making it difficult for them to spend their inputs unless they pay for the malicious party's transaction. Todd's solution involves pre-signing transactions with nLockTime set far into the future and spending one or more inputs of the transaction with a high enough fee to replace any attempts to exploit the rule.However, there are several open questions and challenges associated with this solution. One issue is determining the high fee needed to guarantee replacements with high odds. Since the sat/vb (satoshi per virtual byte) is unknown at the time of signature exchange among participants, overshooting and adopting a historical worst-case mempool feerate may be necessary. This introduces economic lower bounds on the funds involved in a contract, creating a griefing vector where a participant could deliberately pin to inflict asymmetric damage without entering into any fee competition.To address these challenges, participants may consider unilaterally spending after a protocol/implementation timepoint to save the time value of their contributed UTXOs over operation success. Additionally, a proposed more workable solution is to rely on package-relay, an ephemeral anchor output, and a special replacement regime (e.g., nVersion=3). This would allow the multi-party funded transaction coordinator to unilateral fee-bump, step-by-step, without relying on assumptions about the knowledge of network mempools and burning excessive fees.The email exchange between Antoine and Peter Todd also highlights the issue of incentive compatibility when considering miner harvesting attacks as part of the threat model. It remains unclear if the v3 rules that depend on miners arbitrarily rejecting transactions from their mempools are sufficiently incentive compatible to work effectively.Overall, the Bitcoin community is actively discussing ways to prevent pinning attacks on multi-party transactions. Implementing pre-signed transactions with nLockTime set in the future and utilizing a combination of package-relay, an ephemeral anchor output, and a special replacement regime could potentially address this issue. However, there are still challenges to be addressed, such as determining the appropriate fee and ensuring incentive compatibility in the face of potential miner harvesting attacks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Validity-Rollups-on-Bitcoin.xml b/static/bitcoin-dev/Nov_2022/combined_Validity-Rollups-on-Bitcoin.xml index ef9ba7a0cb..dd0e8dc4d8 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Validity-Rollups-on-Bitcoin.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Validity-Rollups-on-Bitcoin.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Validity Rollups on Bitcoin - 2023-08-02T08:05:02.174011+00:00 - - ZmnSCPxj 2022-11-04 23:07:56+00:00 - - - Russell O'Connor 2022-11-04 20:29:26+00:00 - - - Trey Del Bonis 2022-11-04 19:53:31+00:00 - - - AdamISZ 2022-11-02 17:19:23+00:00 - - - John Light 2022-10-12 15:40:10+00:00 - - - Greg Sanders 2022-10-12 13:28:22+00:00 - - - John Light 2022-10-11 15:40:52+00:00 - + 2025-09-26T14:29:42.233240+00:00 + python-feedgen + + + [bitcoin-dev] Validity Rollups on Bitcoin John Light + 2022-10-11T15:40:00.000Z + + + Greg Sanders + 2022-10-12T13:28:00.000Z + + + John Light + 2022-10-12T15:40:00.000Z + + + AdamISZ + 2022-11-02T17:19:00.000Z + + + Trey Del Bonis + 2022-11-04T19:53:00.000Z + + + Russell O'Connor + 2022-11-04T20:29:00.000Z + + + ZmnSCPxj + 2022-11-04T23:07:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Validity Rollups on Bitcoin - 2023-08-02T08:05:02.174011+00:00 + 2025-09-26T14:29:42.234329+00:00 - ZmnSCPxj has proposed the implementation of new opcodes in Taproot to improve efficiency and avoid duplicating data in the witness. One potential opcode is a form of OP_MERKLEUPDATEVERIFY that checks a merkle proof against a root and verifies if replacing the leaf with some hash using the proof yields a specified updated root. Another proposal is a limited version of OP_EVAL for cases where different spend paths cannot be split into different tapleafs.ZmnSCPxj suggests reusing pay-to-contract to store a commitment to the state in Taproot. This involves using the Taproot outpoint script as the public key corresponding to the pay-to-contract of the Taproot MAST root and an internal public key. The internal public key can also be a pay-to-contract, allowing for the commitment of a covenant state. This proposed opcode would determine if the internal public key is a pay-to-contract of the current state on the internal-internal pubkey. If an expected new state exists, it would compute a new Taproot internal pubkey and recomputes the pay-to-contract on the new state. This approach eliminates the need for quining and OP_PUSHSCRIPT, only requiring a way to compute the new state from the old state.Trey Del Bonis discusses the idea of using granular transaction introspection opcodes from Elements for rollups. He acknowledges that the actual proof verification process is complex and suggests implementing a specific opcode for more efficient proof verification. This opcode would take the serialized proof, a verification key, and the public input as separate stack items. The public input includes various commitments and data from the transaction outputs, and the rollup batch data itself. Trey also expresses interest in Simplicity Jets that facilitate rollups, particularly pairing-friendly curve operations.The conversation between AdamISZ/waxwing and John Light explores the minimal functionality required for general-purpose off-chain contracting that is provable. They discuss the verification of bilinear pairings on-chain and the use of a covenant opcode for implementing rollups/sidechains with client-side computation and compact state update. They also touch on the security models of Optimism and Arbitrum, as well as the use of trusted setups in different security models.Greg Sanders inquired about a concise cheat sheet for transaction introspection/OP_ZKP and their uses in different rollup architectures. While such a cheat sheet does not exist yet, Trey Del Bonis has written a detailed technical post on how these components can be used in a validity rollup. However, more research and design work are needed to provide the requested details.John Light's report titled "Validity Rollups on Bitcoin" explores the benefits of validity rollups for Bitcoin and existing layer two protocols like the Lightning Network. The report examines the history, technical workings, and potential risks and benefits of implementing validity rollups on Bitcoin, highlighting their potential to improve scalability, privacy, and programmability without compromising Bitcoin's core values. The full report can be found at bitcoinrollups.org, and feedback from the Bitcoin dev community is welcomed.In summary, there are ongoing discussions and proposals regarding the implementation of new opcodes in Taproot to enhance efficiency and avoid data duplication. Transaction introspection opcodes from Elements are being considered for rollups, along with the need for efficient proof verification. The conversation also touches on security models, trusted setups, and the potential benefits of validity rollups for Bitcoin. John Light's report provides a comprehensive examination of validity rollups and their potential impact on Bitcoin's scalability, privacy, and programmability. 2022-11-04T23:07:56+00:00 + ZmnSCPxj has proposed the implementation of new opcodes in Taproot to improve efficiency and avoid duplicating data in the witness. One potential opcode is a form of OP_MERKLEUPDATEVERIFY that checks a merkle proof against a root and verifies if replacing the leaf with some hash using the proof yields a specified updated root. Another proposal is a limited version of OP_EVAL for cases where different spend paths cannot be split into different tapleafs.ZmnSCPxj suggests reusing pay-to-contract to store a commitment to the state in Taproot. This involves using the Taproot outpoint script as the public key corresponding to the pay-to-contract of the Taproot MAST root and an internal public key. The internal public key can also be a pay-to-contract, allowing for the commitment of a covenant state. This proposed opcode would determine if the internal public key is a pay-to-contract of the current state on the internal-internal pubkey. If an expected new state exists, it would compute a new Taproot internal pubkey and recomputes the pay-to-contract on the new state. This approach eliminates the need for quining and OP_PUSHSCRIPT, only requiring a way to compute the new state from the old state.Trey Del Bonis discusses the idea of using granular transaction introspection opcodes from Elements for rollups. He acknowledges that the actual proof verification process is complex and suggests implementing a specific opcode for more efficient proof verification. This opcode would take the serialized proof, a verification key, and the public input as separate stack items. The public input includes various commitments and data from the transaction outputs, and the rollup batch data itself. Trey also expresses interest in Simplicity Jets that facilitate rollups, particularly pairing-friendly curve operations.The conversation between AdamISZ/waxwing and John Light explores the minimal functionality required for general-purpose off-chain contracting that is provable. They discuss the verification of bilinear pairings on-chain and the use of a covenant opcode for implementing rollups/sidechains with client-side computation and compact state update. They also touch on the security models of Optimism and Arbitrum, as well as the use of trusted setups in different security models.Greg Sanders inquired about a concise cheat sheet for transaction introspection/OP_ZKP and their uses in different rollup architectures. While such a cheat sheet does not exist yet, Trey Del Bonis has written a detailed technical post on how these components can be used in a validity rollup. However, more research and design work are needed to provide the requested details.John Light's report titled "Validity Rollups on Bitcoin" explores the benefits of validity rollups for Bitcoin and existing layer two protocols like the Lightning Network. The report examines the history, technical workings, and potential risks and benefits of implementing validity rollups on Bitcoin, highlighting their potential to improve scalability, privacy, and programmability without compromising Bitcoin's core values. The full report can be found at bitcoinrollups.org, and feedback from the Bitcoin dev community is welcomed.In summary, there are ongoing discussions and proposals regarding the implementation of new opcodes in Taproot to enhance efficiency and avoid data duplication. Transaction introspection opcodes from Elements are being considered for rollups, along with the need for efficient proof verification. The conversation also touches on security models, trusted setups, and the potential benefits of validity rollups for Bitcoin. John Light's report provides a comprehensive examination of validity rollups and their potential impact on Bitcoin's scalability, privacy, and programmability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Wallet-policies-for-descriptor-wallets.xml b/static/bitcoin-dev/Nov_2022/combined_Wallet-policies-for-descriptor-wallets.xml index 31ad2a1399..4cbe1b8dd9 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Wallet-policies-for-descriptor-wallets.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Wallet-policies-for-descriptor-wallets.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Wallet policies for descriptor wallets - 2023-08-02T06:23:33.636002+00:00 - - Salvatore Ingala 2023-01-24 08:38:29+00:00 - - - darosior 2023-01-23 19:53:18+00:00 - - - Salvatore Ingala 2022-11-21 11:27:25+00:00 - - - Andrew Poelstra 2022-09-29 23:56:51+00:00 - - - Salvatore Ingala 2022-05-17 08:44:53+00:00 - - - Salvatore Ingala 2022-05-10 09:37:26+00:00 - - - darosior 2022-05-09 11:36:47+00:00 - - - Billy Tetrud 2022-05-08 17:41:07+00:00 - - - Salvatore Ingala 2022-05-05 14:32:34+00:00 - + 2025-09-26T14:29:18.564289+00:00 + python-feedgen + + + [bitcoin-dev] Wallet policies for descriptor wallets Salvatore Ingala + 2022-05-05T14:32:00.000Z + + + Billy Tetrud + 2022-05-08T17:41:00.000Z + + + darosior + 2022-05-09T11:36:00.000Z + + + Salvatore Ingala + 2022-05-10T09:37:00.000Z + + + Salvatore Ingala + 2022-05-17T08:44:00.000Z + + + Andrew Poelstra + 2022-09-29T23:56:00.000Z + + + Salvatore Ingala + 2022-11-21T11:27:00.000Z + + + darosior + 2023-01-23T19:53:00.000Z + + + Salvatore Ingala + 2023-01-24T08:38:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Wallet policies for descriptor wallets - 2023-08-02T06:23:33.637054+00:00 + 2025-09-26T14:29:18.565372+00:00 - Salvatore Ingala, a Bitcoin developer, has proposed a new language called "wallet policies" to address challenges in implementing descriptors and miniscript support in hardware wallets. These challenges arise due to limited RAM, computational power, and storage capacity of hardware wallets.The proposed language aims to provide a native, compact representation of the wallet receive/change and improve the user experience of software wallets. The registration flow for wallet policies involves the software wallet initiating a registration process on the hardware wallet. The information includes the wallet policy and a unique name that identifies the policy. The hardware wallet displays the policy on its secure screen, allowing the user to review and compare it with a trusted source before approving it. The goal is to ensure that the user knows the policy being used to spend their funds, preventing any malicious modifications.To simplify implementation and improve user experience, the document proposes minimizing the amount of information shown on-screen and reducing the number of times the user needs to validate such information. It also suggests reusing the same xpub in multiple places to avoid blowup in descriptor size. The proof of registration is executed securely using message authentication codes.The document provides examples of wallet descriptor templates for different use cases, such as native segwit accounts, taproot BIP86 accounts, native segwit 2-of-3, and templates with miniscript for "1 of 2 equally likely keys." It also includes additional rules, implementation guidelines, and references to relevant Bitcoin Improvement Proposals (BIPs) for further information.The email exchange discusses the challenges of implementing output descriptors on signing devices, proposing optimizations to overcome difficulties for implementers. It suggests optimizations for common use cases, such as using two descriptors at different derivation indices for receive and change addresses. The conversation also touches on the feasibility of incorporating Musig2 descriptors into hardware wallets and the potential for improving key aliasing using wallet policies.Overall, the proposed wallet policies language aims to provide a secure and user-friendly solution for integrating descriptors and miniscript support in hardware wallets, addressing the limitations of embedded devices and ensuring good user experience.Salvatore Ingala addresses the challenges of implementing descriptors and miniscript support in hardware wallets due to technical constraints such as limited RAM and computational power. To overcome these limitations, Ingala proposes a "wallet policies" language that can be used by all hardware wallets to securely support complex scripts.The proposed solution involves a registration flow for the wallet policy in the hardware wallet. This registration process includes generating all relevant addresses/scripts and identifying keys controlled by the hardware wallet. The user registers a wallet policy into the hardware wallet, and the software wallet initiates the registration on the hardware wallet. The registered policy is stored in the hardware wallet's permanent memory, and a master key encrypts all necessary information required to spend funds sent to those addresses.The policy language suggested targets a stricter subset of the output descriptors language, making it easier to implement and allowing for human inspection during the registration flow. Wallet descriptor templates consist of key placeholders and key origin information, including various types such as P2SH, P2WSH, P2PKH, P2WPKH, multisig, sorted multi, P2TR, and miniscript templates.The document outlines a standard for output script descriptors used to derive addresses and scripts from wallet descriptor templates. It specifies that wallet policies are considered invalid if any placeholder has derivation steps while the corresponding element of the keys vector is not an xpub. The document provides examples of wallet descriptor templates for native segwit accounts, taproot BIP86 accounts, and multisig setups.Overall, the proposed wallet policies language aims to address the security and user experience challenges faced by hardware wallets when supporting complex scripts. By registering wallet policies, hardware wallets can securely perform operations like generating addresses and signing transactions. 2023-01-24T08:38:29+00:00 + Salvatore Ingala, a Bitcoin developer, has proposed a new language called "wallet policies" to address challenges in implementing descriptors and miniscript support in hardware wallets. These challenges arise due to limited RAM, computational power, and storage capacity of hardware wallets.The proposed language aims to provide a native, compact representation of the wallet receive/change and improve the user experience of software wallets. The registration flow for wallet policies involves the software wallet initiating a registration process on the hardware wallet. The information includes the wallet policy and a unique name that identifies the policy. The hardware wallet displays the policy on its secure screen, allowing the user to review and compare it with a trusted source before approving it. The goal is to ensure that the user knows the policy being used to spend their funds, preventing any malicious modifications.To simplify implementation and improve user experience, the document proposes minimizing the amount of information shown on-screen and reducing the number of times the user needs to validate such information. It also suggests reusing the same xpub in multiple places to avoid blowup in descriptor size. The proof of registration is executed securely using message authentication codes.The document provides examples of wallet descriptor templates for different use cases, such as native segwit accounts, taproot BIP86 accounts, native segwit 2-of-3, and templates with miniscript for "1 of 2 equally likely keys." It also includes additional rules, implementation guidelines, and references to relevant Bitcoin Improvement Proposals (BIPs) for further information.The email exchange discusses the challenges of implementing output descriptors on signing devices, proposing optimizations to overcome difficulties for implementers. It suggests optimizations for common use cases, such as using two descriptors at different derivation indices for receive and change addresses. The conversation also touches on the feasibility of incorporating Musig2 descriptors into hardware wallets and the potential for improving key aliasing using wallet policies.Overall, the proposed wallet policies language aims to provide a secure and user-friendly solution for integrating descriptors and miniscript support in hardware wallets, addressing the limitations of embedded devices and ensuring good user experience.Salvatore Ingala addresses the challenges of implementing descriptors and miniscript support in hardware wallets due to technical constraints such as limited RAM and computational power. To overcome these limitations, Ingala proposes a "wallet policies" language that can be used by all hardware wallets to securely support complex scripts.The proposed solution involves a registration flow for the wallet policy in the hardware wallet. This registration process includes generating all relevant addresses/scripts and identifying keys controlled by the hardware wallet. The user registers a wallet policy into the hardware wallet, and the software wallet initiates the registration on the hardware wallet. The registered policy is stored in the hardware wallet's permanent memory, and a master key encrypts all necessary information required to spend funds sent to those addresses.The policy language suggested targets a stricter subset of the output descriptors language, making it easier to implement and allowing for human inspection during the registration flow. Wallet descriptor templates consist of key placeholders and key origin information, including various types such as P2SH, P2WSH, P2PKH, P2WPKH, multisig, sorted multi, P2TR, and miniscript templates.The document outlines a standard for output script descriptors used to derive addresses and scripts from wallet descriptor templates. It specifies that wallet policies are considered invalid if any placeholder has derivation steps while the corresponding element of the keys vector is not an xpub. The document provides examples of wallet descriptor templates for native segwit accounts, taproot BIP86 accounts, and multisig setups.Overall, the proposed wallet policies language aims to address the security and user experience challenges faced by hardware wallets when supporting complex scripts. By registering wallet policies, hardware wallets can securely perform operations like generating addresses and signing transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_brickchain.xml b/static/bitcoin-dev/Nov_2022/combined_brickchain.xml index 25167a3a30..c8ae69bc7d 100644 --- a/static/bitcoin-dev/Nov_2022/combined_brickchain.xml +++ b/static/bitcoin-dev/Nov_2022/combined_brickchain.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - brickchain - 2023-08-02T08:15:48.234195+00:00 - - mm-studios 2022-11-08 16:31:15+00:00 - - - Erik Aronesty 2022-11-08 15:49:10+00:00 - - - mm-studios 2022-11-08 14:25:04+00:00 - - - Erik Aronesty 2022-11-08 14:16:41+00:00 - - - mm-studios 2022-10-19 22:53:54+00:00 - - - mm-studios 2022-10-19 22:47:43+00:00 - - - G. Andrew Stone 2022-10-19 21:34:43+00:00 - - - mm-studios 2022-10-19 16:03:45+00:00 - - - Erik Aronesty 2022-10-19 14:24:48+00:00 - - - Bryan Bishop 2022-10-19 13:54:11+00:00 - - - angus 2022-10-19 13:40:35+00:00 - - - mm-studios 2022-10-19 09:04:50+00:00 - + 2025-09-26T14:29:33.662229+00:00 + python-feedgen + + + [bitcoin-dev] brickchain mm-studios + 2022-10-19T09:04:00.000Z + + + angus + 2022-10-19T13:40:00.000Z + + + Bryan Bishop + 2022-10-19T13:54:00.000Z + + + Erik Aronesty + 2022-10-19T14:24:00.000Z + + + mm-studios + 2022-10-19T16:03:00.000Z + + + G. Andrew Stone + 2022-10-19T21:34:00.000Z + + + mm-studios + 2022-10-19T22:47:00.000Z + + + mm-studios + 2022-10-19T22:53:00.000Z + + + Erik Aronesty + 2022-11-08T14:16:00.000Z + + + mm-studios + 2022-11-08T14:25:00.000Z + + + Erik Aronesty + 2022-11-08T15:49:00.000Z + + + mm-studios + 2022-11-08T16:31:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - brickchain - 2023-08-02T08:15:48.235232+00:00 + 2025-09-26T14:29:33.663602+00:00 - The author proposes a novel approach to enhance the speed of transactions in the Bitcoin network by modifying the Proof of Work (PoW) algorithm. Currently, the network's capacity is limited by the size of blocks produced by miners. Although some suggested removing these limits, it was widely rejected due to unfavorable consequences.To address this issue, the author introduces the concept of a 'brick', which aims to maintain small blocks while accommodating all transactions. A brick is essentially a block that does not meet the difficulty rule but is filled with transactions up to its maximum capacity. Once a brick is completely filled, it would be broadcasted, and the miner would proceed to work on a new brick connected to the previous one.Nodes within the network would accept incoming regular blocks as well as bricks with hashes that fail to satisfy the difficulty rule, under the condition that the brick is fully filled. If a series of minimum hashes is computationally equivalent to the network difficulty, then the entire 'brickchain' is considered valid as a block.Implementing this approach could effectively reduce the backlog of unconfirmed transactions (mempools), maintain low transaction fees, and ultimately enhance the network's throughput without the need for increasing the block size. However, there are potential concerns surrounding the determination of brick validity, the allocation of block rewards, distribution of fees, and integration of the brick sidechain into the main blockchain.In an email discussing the proposal, the author also mentions the importance of layer 2 protocols like MWEB, which allow holding and transferring uncommitted transactions as pools or joins. The email emphasizes the need to avoid increasing the workload of full-nodes and undermining layer 2 systems like the Lightning Network (LN). Layered financial systems, such as L3 projects like TARO and RGB, are considered superior in terms of layered financial systems.The email concludes by acknowledging that more work needs to be done to refine the proposal and determine its feasibility. The author recognizes the need for changes in the PoW algorithm and a better calculus to define the proposal. It is clear that increasing the throughput without increasing the block size is a primary goal, and the proposal aims to achieve this by introducing the concept of bricks and validating them as blocks within a brickchain. 2022-11-08T16:31:15+00:00 + The author proposes a novel approach to enhance the speed of transactions in the Bitcoin network by modifying the Proof of Work (PoW) algorithm. Currently, the network's capacity is limited by the size of blocks produced by miners. Although some suggested removing these limits, it was widely rejected due to unfavorable consequences.To address this issue, the author introduces the concept of a 'brick', which aims to maintain small blocks while accommodating all transactions. A brick is essentially a block that does not meet the difficulty rule but is filled with transactions up to its maximum capacity. Once a brick is completely filled, it would be broadcasted, and the miner would proceed to work on a new brick connected to the previous one.Nodes within the network would accept incoming regular blocks as well as bricks with hashes that fail to satisfy the difficulty rule, under the condition that the brick is fully filled. If a series of minimum hashes is computationally equivalent to the network difficulty, then the entire 'brickchain' is considered valid as a block.Implementing this approach could effectively reduce the backlog of unconfirmed transactions (mempools), maintain low transaction fees, and ultimately enhance the network's throughput without the need for increasing the block size. However, there are potential concerns surrounding the determination of brick validity, the allocation of block rewards, distribution of fees, and integration of the brick sidechain into the main blockchain.In an email discussing the proposal, the author also mentions the importance of layer 2 protocols like MWEB, which allow holding and transferring uncommitted transactions as pools or joins. The email emphasizes the need to avoid increasing the workload of full-nodes and undermining layer 2 systems like the Lightning Network (LN). Layered financial systems, such as L3 projects like TARO and RGB, are considered superior in terms of layered financial systems.The email concludes by acknowledging that more work needs to be done to refine the proposal and determine its feasibility. The author recognizes the need for changes in the PoW algorithm and a better calculus to define the proposal. It is clear that increasing the throughput without increasing the block size is a primary goal, and the proposal aims to achieve this by introducing the concept of bricks and validating them as blocks within a brickchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml b/static/bitcoin-dev/Nov_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml index 4161e59b38..7bfdf45272 100644 --- a/static/bitcoin-dev/Nov_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml +++ b/static/bitcoin-dev/Nov_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? - 2023-11-05T02:03:01.848102+00:00 + 2025-09-26T14:27:03.841326+00:00 + python-feedgen ArmchairCryptologist 2023-11-04 09:58:48+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? - 2023-11-05T02:03:01.848349+00:00 + 2025-09-26T14:27:03.841485+00:00 - Bitcoin developers are engaged in discussions to find solutions for the current high fee environment, prevent spam transactions, and ensure the long-term sustainability and decentralization of the network. Proposed solutions include fixing layered protocols, introducing new opcodes like OP_ZKP, reallocating block space, and penalizing non-economic transactions. The goal is to strike a balance between reducing fees, preventing spam, and maintaining the economic viability and security of the network. Ali Sherief expresses concern over congestion caused by side projects like BRC-20 and suggests implementing BIPs or commits in the Bitcoin Core codebase to address the issue. Michael Folkson argues that consensus-compatible transactions paying market-rate fees are functioning as intended. However, the debate continues on finding effective solutions while preserving maximum freedom and valid use cases. The email exchange also discusses the purpose of paying higher transaction fees than the received amount, the lack of Lightning wallets for desktop, and the need for GUI wallets to interact with the Lightning Network. Overall, the focus is on addressing congestion, preventing spam, and ensuring smooth operation of the Bitcoin network as a peer-to-peer digital currency. 2023-11-04T09:58:48+00:00 + Bitcoin developers are engaged in discussions to find solutions for the current high fee environment, prevent spam transactions, and ensure the long-term sustainability and decentralization of the network. Proposed solutions include fixing layered protocols, introducing new opcodes like OP_ZKP, reallocating block space, and penalizing non-economic transactions. The goal is to strike a balance between reducing fees, preventing spam, and maintaining the economic viability and security of the network. Ali Sherief expresses concern over congestion caused by side projects like BRC-20 and suggests implementing BIPs or commits in the Bitcoin Core codebase to address the issue. Michael Folkson argues that consensus-compatible transactions paying market-rate fees are functioning as intended. However, the debate continues on finding effective solutions while preserving maximum freedom and valid use cases. The email exchange also discusses the purpose of paying higher transaction fees than the received amount, the lack of Lightning wallets for desktop, and the need for GUI wallets to interact with the Lightning Network. Overall, the focus is on addressing congestion, preventing spam, and ensuring smooth operation of the Bitcoin network as a peer-to-peer digital currency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_A-proposal-for-a-PSBT-for-descriptors-format.xml b/static/bitcoin-dev/Nov_2023/combined_A-proposal-for-a-PSBT-for-descriptors-format.xml index afa550c5bf..6f21052833 100644 --- a/static/bitcoin-dev/Nov_2023/combined_A-proposal-for-a-PSBT-for-descriptors-format.xml +++ b/static/bitcoin-dev/Nov_2023/combined_A-proposal-for-a-PSBT-for-descriptors-format.xml @@ -1,27 +1,30 @@ - + 2 - Combined summary - A proposal for a "PSBT for descriptors" format - 2023-12-01T02:06:02.929110+00:00 - - Brandon Black 2023-11-30 23:12:05+00:00 - - - SeedHammer Team 2023-11-23 22:25:43+00:00 - + Combined summary - A proposal for a "PSBT for descriptors" format + 2025-09-26T14:27:01.695083+00:00 + python-feedgen + + + [bitcoin-dev] A proposal for a "PSBT for descriptors" format SeedHammer Team + 2023-11-23T22:25:00.000Z + + + Brandon Black + 2023-11-30T23:12:00.000Z + + - python-feedgen + 2 - Combined summary - A proposal for a "PSBT for descriptors" format - 2023-12-01T02:06:02.929150+00:00 + Combined summary - A proposal for a "PSBT for descriptors" format + 2025-09-26T14:27:01.695534+00:00 + 2023-11-30T23:12:05+00:00 SeedHammer is in the process of creating a standardized output descriptor to facilitate self-contained metal engraved backups, which could be crucial for the preservation and recovery of cryptocurrency assets. Their proposed format incorporates the binary encoding from BIP174 PSBT, aiming to make it compatible with PSBTv1 and PSBTv2 by allowing a coordinating device to add inputs or an unsigned transaction without additional modifications. This initiative includes introducing two new global map entries: PSBT_GLOBAL_DESCRIPTOR and PSBT_GLOBAL_KEY_NAME, with specific keys and values to hold the descriptor information. - The preliminary design of SeedHammer's descriptor format adheres to the standards set forth in BIPs 380-386 and BIP 389, utilizing Miniscript while discouraging inline keys and requiring substitutions of pk(NAME) expressions with indexed key references. It also integrates extra metadata like labels and birthdate blocks via PSBT map entries. The debate within the community partly revolves around the choice of encoding method—CBOR versus PSBT—with Blockchain Commons suggesting CBOR due to its status as an established standard. However, SeedHammer maintains that PSBT's simplicity and current support in wallet software make it a more practical choice despite CBOR's complexity. - Another aspect under discussion is whether to create a unique header and magic number for the new format or to extend the existing PSBT format. As part of the development process, SeedHammer seeks feedback on their proposal to refine it before submitting it for formal consideration through the BIP process. For those interested in reviewing the details of this proposal, examples and further information are accessible via the links provided for the proposal, its implementation, and a playground for experimentation. - 2023-11-30T23:12:05+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml b/static/bitcoin-dev/Nov_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml index 4ee8ab95d8..873d414fa2 100644 --- a/static/bitcoin-dev/Nov_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml +++ b/static/bitcoin-dev/Nov_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml @@ -1,218 +1,247 @@ - + 2 - Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" - 2023-11-19T02:08:14.468907+00:00 - - Antoine Riard 2023-11-17 22:36:35+00:00 - - - Antoine Riard 2023-11-02 04:46:29+00:00 - - - Peter Todd 2023-10-27 00:43:30+00:00 - - - Peter Todd 2023-10-27 00:43:30+00:00 - - - Matt Corallo 2023-10-23 16:09:50+00:00 - - - Matt Corallo 2023-10-23 16:09:50+00:00 - - - David A. Harding 2023-10-23 08:49:55+00:00 - - - David A. Harding 2023-10-23 08:49:55+00:00 - - - Nadav Ivgi 2023-10-22 04:49:19+00:00 - - - Nadav Ivgi 2023-10-22 04:49:19+00:00 - - - Antoine Riard 2023-10-21 20:05:35+00:00 - - - Antoine Riard 2023-10-21 20:05:35+00:00 - - - Nagaev Boris 2023-10-21 14:21:48+00:00 - - - Peter Todd 2023-10-21 02:43:31+00:00 - - - Peter Todd 2023-10-21 02:43:31+00:00 - - - Matt Corallo 2023-10-21 01:55:12+00:00 - - - Matt Corallo 2023-10-21 01:55:12+00:00 - - - Peter Todd 2023-10-21 01:25:10+00:00 - - - Peter Todd 2023-10-21 01:25:10+00:00 - - - Matt Corallo 2023-10-21 01:03:49+00:00 - - - Matt Corallo 2023-10-21 01:03:49+00:00 - - - Olaoluwa Osuntokun 2023-10-21 00:18:58+00:00 - - - Olaoluwa Osuntokun 2023-10-21 00:18:58+00:00 - - - Peter Todd 2023-10-21 00:15:21+00:00 - - - Peter Todd 2023-10-21 00:15:21+00:00 - - - Matt Corallo 2023-10-20 21:05:48+00:00 - - - Matt Corallo 2023-10-20 21:05:48+00:00 - - - Matt Morehouse 2023-10-20 18:35:26+00:00 - - - Matt Morehouse 2023-10-20 18:35:26+00:00 - - - Jochen Hoenicke 2023-10-20 11:18:46+00:00 - - - Peter Todd 2023-10-20 11:03:43+00:00 - - - Peter Todd 2023-10-20 11:03:43+00:00 - - - Peter Todd 2023-10-20 10:47:38+00:00 - - - Peter Todd 2023-10-20 10:31:03+00:00 - - - Peter Todd 2023-10-20 10:31:03+00:00 - - - Antoine Riard 2023-10-20 06:56:34+00:00 - - - Antoine Riard 2023-10-20 06:56:34+00:00 - - - Antoine Riard 2023-10-19 19:33:22+00:00 - - - Antoine Riard 2023-10-19 19:33:22+00:00 - - - Matt Corallo 2023-10-19 18:02:38+00:00 - - - Matt Corallo 2023-10-19 18:02:38+00:00 - - - Matt Morehouse 2023-10-19 17:53:53+00:00 - - - Matt Morehouse 2023-10-19 17:53:53+00:00 - - - Antoine Riard 2023-10-19 17:22:01+00:00 - - - Antoine Riard 2023-10-19 17:22:01+00:00 - - - Matt Morehouse 2023-10-19 16:23:13+00:00 - - - Matt Morehouse 2023-10-19 16:23:13+00:00 - - - Bastien TEINTURIER 2023-10-19 08:12:08+00:00 - - - Bastien TEINTURIER 2023-10-19 08:12:08+00:00 - - - Antoine Riard 2023-10-18 02:57:34+00:00 - - - Antoine Riard 2023-10-18 02:57:34+00:00 - - - Matt Corallo 2023-10-18 00:17:44+00:00 - - - Matt Corallo 2023-10-18 00:17:44+00:00 - - - Antoine Riard 2023-10-17 18:47:59+00:00 - - - Antoine Riard 2023-10-17 18:47:59+00:00 - - - Antoine Riard 2023-10-17 18:34:52+00:00 - - - Antoine Riard 2023-10-17 18:34:52+00:00 - - - Antoine Riard 2023-10-17 17:47:14+00:00 - - - Antoine Riard 2023-10-17 17:47:14+00:00 - - - ZmnSCPxj 2023-10-17 10:34:04+00:00 - - - ZmnSCPxj 2023-10-17 10:34:04+00:00 - - - ziggie 2023-10-17 07:21:35+00:00 - - - ziggie 2023-10-17 07:21:35+00:00 - - - Antoine Riard 2023-10-17 01:11:20+00:00 - - - Olaoluwa Osuntokun 2023-10-16 22:51:19+00:00 - - - Olaoluwa Osuntokun 2023-10-16 22:51:19+00:00 - - - Matt Morehouse 2023-10-16 22:10:06+00:00 - - - Peter Todd 2023-10-16 19:13:52+00:00 - - - Antoine Riard 2023-10-16 16:57:36+00:00 - - - Antoine Riard 2023-10-16 16:57:36+00:00 - + Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2025-09-26T14:26:53.196360+00:00 + python-feedgen + + + [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Antoine Riard + 2023-10-16T16:57:00.000Z + + + Peter Todd + 2023-10-16T19:13:00.000Z + + + Matt Morehouse + 2023-10-16T22:10:00.000Z + + + Olaoluwa Osuntokun + 2023-10-16T22:51:00.000Z + + + Antoine Riard + 2023-10-17T01:11:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ziggie1984 + 2023-10-17T07:21:00.000Z + + + ZmnSCPxj + 2023-10-17T10:34:00.000Z + + + Antoine Riard + 2023-10-17T17:47:00.000Z + + + Antoine Riard + 2023-10-17T18:34:00.000Z + + + Antoine Riard + 2023-10-17T18:47:00.000Z + + + Matt Corallo + 2023-10-18T00:17:00.000Z + + + Antoine Riard + 2023-10-18T02:57:00.000Z + + + Bastien TEINTURIER + 2023-10-19T08:12:00.000Z + + + Matt Morehouse + 2023-10-19T16:23:00.000Z + + + Antoine Riard + 2023-10-19T17:22:00.000Z + + + Matt Morehouse + 2023-10-19T17:53:00.000Z + + + Matt Corallo + 2023-10-19T18:02:00.000Z + + + Antoine Riard + 2023-10-19T19:33:00.000Z + + + [bitcoin-dev] " Antoine Riard + 2023-10-20T06:56:00.000Z + + + Peter Todd + 2023-10-20T10:31:00.000Z + + + Peter Todd + 2023-10-20T10:47:00.000Z + + + Peter Todd + 2023-10-20T11:03:00.000Z + + + Jochen Hoenicke + 2023-10-20T11:18:00.000Z + + + Matt Morehouse + 2023-10-20T18:35:00.000Z + + + Matt Corallo + 2023-10-20T21:05:00.000Z + + + [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely Peter Todd + 2023-10-21T00:09:00.000Z + + + Peter Todd + 2023-10-21T00:15:00.000Z + + + Olaoluwa Osuntokun + 2023-10-21T00:18:00.000Z + + + Matt Corallo + 2023-10-21T01:03:00.000Z + + + Peter Todd + 2023-10-21T01:25:00.000Z + + + Matt Corallo + 2023-10-21T01:55:00.000Z + + + Peter Todd + 2023-10-21T02:43:00.000Z + + + David A. Harding + 2023-10-21T08:58:00.000Z + + + Peter Todd + 2023-10-21T10:31:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Nagaev Boris + 2023-10-21T14:21:00.000Z + + + Antoine Riard + 2023-10-21T20:05:00.000Z + + + [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Nadav Ivgi + 2023-10-22T04:49:00.000Z + + + vjudeu + 2023-10-22T08:30:00.000Z + + + David A. Harding + 2023-10-23T08:49:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2023-10-23T11:10:00.000Z + + + Peter Todd + 2023-10-23T15:45:00.000Z + + + Matt Corallo + 2023-10-23T16:09:00.000Z + + + Peter Todd + 2023-10-27T00:43:00.000Z + + + Antoine Riard + 2023-11-02T04:46:00.000Z + + + [bitcoin-dev] " Antoine Riard + 2023-11-02T05:24:00.000Z + + + Peter Todd + 2023-11-02T06:26:00.000Z + + + Matt Morehouse + 2023-11-02T17:07:00.000Z + + + Antoine Riard + 2023-11-03T05:25:00.000Z + + + Antoine Riard + 2023-11-03T05:27:00.000Z + + + Peter Todd + 2023-11-04T07:26:00.000Z + + + Antoine Riard + 2023-11-06T18:45:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2023-11-07T11:11:00.000Z + + + Antoine Riard + 2023-11-07T15:44:00.000Z + + + [bitcoin-dev] " Peter Todd + 2023-11-08T00:51:00.000Z + + + Peter Todd + 2023-11-08T02:06:00.000Z + + + Antoine Riard + 2023-11-13T02:18:00.000Z + + + Peter Todd + 2023-11-14T19:50:00.000Z + + + [bitcoin-dev] Fwd: " Antoine Riard + 2023-11-15T17:53:00.000Z + + + Antoine Riard + 2023-11-17T22:36:00.000Z + + @@ -283,39 +312,26 @@ - python-feedgen + 2 - Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" - 2023-11-19T02:08:14.469376+00:00 + Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2025-09-26T14:26:53.201832+00:00 - The recent discussions among programmers have focused on addressing security threats to the Lightning Network (LN), particularly vulnerabilities in Hashed Time-Locked Contracts (HTLCs). The "flood & loot" attack, where attackers exploit network mempools by closing channels and hindering defensive transactions, has been highlighted as a significant threat. It was noted that policy differences across Bitcoin Core implementations allow such attacks due to transaction prioritization based on fees. - + 2023-11-17T22:36:35+00:00 + The recent discussions among programmers have focused on addressing security threats to the Lightning Network (LN), particularly vulnerabilities in Hashed Time-Locked Contracts (HTLCs). The "flood & loot" attack, where attackers exploit network mempools by closing channels and hindering defensive transactions, has been highlighted as a significant threat. It was noted that policy differences across Bitcoin Core implementations allow such attacks due to transaction prioritization based on fees. Mitigation strategies are being implemented in various lightning node implementations to address these vulnerabilities. One suggestion is for nodes to monitor their mempool duplicates to reduce exploitation risk, although this does not eliminate the threat entirely. Additionally, there's a push for ecosystem-level solutions rather than quick fixes that could disrupt LN or lower miners' earnings. - To enhance security against replacement cycling attacks, a technical proposal suggests implementing a new opcode, OP_CSV_ALLINPUTS, which would require all inputs in an HTLC preimage branch to have a consistent nSequence, ensuring only confirmed inputs are used. - The email exchanges also reflect on one author's decision to step away from lightning development due to the severity of replacement cycling issues and the lack of standardized mechanisms to combat them. An expert assessment and dedicated time to improve lightning's robustness are called for. - Plans to demonstrate a real-world replacement cycling attack no earlier than the second semester of 2024 were disclosed, with encouragement for public discussion and correspondence on these topics. Debates continue over alternative methods for handling vulnerabilities within the technical community. - New opcodes like OP_CSV_ALLINPUTS and restructuring of presigned transactions are suggested to manage fees and prevent attacks more effectively. Insights into optimizing transaction handling and storage include proposals by Peter Todd, who advocates for combining multiple HTLC claims into one transaction for larger nodes using specific signatures. Discussions also mention the potential efficiency of Replace-by-Fee (RBF) over Child-Pays-for-Parent (CPFP) under most conditions. - For those seeking detailed information, Peter Todd's website at https://petertodd.org is recommended, with an invitation for further dialogue via direct email. - Security discussions extend to anchor outputs in LN for managing fees and transaction replacement strategies, recognizing the benefits of small transactions and deterministic forms. Concerns regarding default settings for RBF, fee overheads, and different feerate variants are raised, including identifying a possible policy bug that requires attention at the policy or Bitcoin Core layer. - An explained attack scenario clarifies that successful attacks depend on precise timing and execution by directly connected peers. Increased security parameters, like the CLTV delta, and the use of anchor channels for fee bumping through second-level HTLCs are considered to hinder such attacks. A proposal to limit spending to presigned second-stage transactions signed with SIGHASH_ALL is suggested to prevent replacement cycling attacks. - -Innovative approaches to mitigating aggressive fee bumping near the CLTV deadline are explored, recommending a "scorched earth" strategy to make it costly for attackers. Research on defensive fee rebroadcasting suggests foundational improvements at the bitcoin protocol level to reinforce Layer 2 protocols. - -Discussants suggest increasing the CLTV delta to give node operators more time for intervention and consider various mitigation strategies, including mempool scanning and transaction re-signing. Establishing a "black box" Lightning infrastructure on the mainnet to experiment with LN vulnerabilities and defenses is of interest, but limited by the scarcity of LN experts and undisclosed risks. - +Innovative approaches to mitigating aggressive fee bumping near the CLTV deadline are explored, recommending a "scorched earth" strategy to make it costly for attackers. Research on defensive fee rebroadcasting suggests foundational improvements at the bitcoin protocol level to reinforce Layer 2 protocols. +Discussants suggest increasing the CLTV delta to give node operators more time for intervention and consider various mitigation strategies, including mempool scanning and transaction re-signing. Establishing a "black box" Lightning infrastructure on the mainnet to experiment with LN vulnerabilities and defenses is of interest, but limited by the scarcity of LN experts and undisclosed risks. A complex payment channel scenario reveals strategic advantages and limitations of CPFP and presigned transactions, while an unobserved attack type exploiting neighboring nodes highlights the need for surveillance and countermeasures like aggressive fee-bumping. - Eclair and LND have partially implemented mitigation strategies against vulnerabilities, while Core-Lightning and LDK have yet to adopt similar mechanisms. Node operators are advised to limit HTLCs for large channels to unknown peers and monitor for suspicious behavior. - Lastly, the Lightning Network Daemon (lnd) version 0.16.1-beta includes safeguards against HTLC-related exploits, with performance improvements planned for the upcoming version 0.17.1. The collaborative nature of the community in enhancing lnd's security is acknowledged, and the importance of critical analysis and skepticism in technical discussions is emphasized ahead of the public disclosure of related CVEs on October 16, 2023. - 2023-11-17T22:36:35+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_Future-of-the-bitcoin-dev-mailing-list.xml b/static/bitcoin-dev/Nov_2023/combined_Future-of-the-bitcoin-dev-mailing-list.xml index 59bcb4bfea..cc301add00 100644 --- a/static/bitcoin-dev/Nov_2023/combined_Future-of-the-bitcoin-dev-mailing-list.xml +++ b/static/bitcoin-dev/Nov_2023/combined_Future-of-the-bitcoin-dev-mailing-list.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Future of the bitcoin-dev mailing list - 2024-01-06T02:06:27.901281+00:00 + 2025-09-26T14:26:46.703886+00:00 + python-feedgen Brad Morrison 2024-01-04 13:50:51+00:00 @@ -107,43 +108,28 @@ - python-feedgen + 2 Combined summary - Future of the bitcoin-dev mailing list - 2024-01-06T02:06:27.901450+00:00 + 2025-09-26T14:26:46.704038+00:00 + 2024-01-04T13:50:51+00:00 The Linux Foundation's mailing lists, primarily running on an outdated Mailman version, necessitate migration or upgrade. Nostr is proposed as a replacement due to its decentralized nature, potentially through a custom Nostr Improvement Proposal (NIP) for relay functions. - Google Groups' interface is criticized for inefficiency and spam issues, prompting consideration of maintaining traditional mail servers. Nostr is endorsed for creating a versatile system with varied moderation policies across different frontends, as described in NIP 11. - Debate over email's role in public discourse has increased, particularly among Gmail users concerned about privacy and centralization. Email's decentralized attributes are valued, and a lightning anti-spam fee is suggested to encourage Lightning network adoption for Bitcoin developer communications. - Antoine praises the bitcoin-dev moderation team and recognizes Nostr's potential, endorsing temporary use of the Delving Bitcoin forum and suggesting other open-source platforms for reference. - Discussions include integrating P2P methods into email systems, broadcasting moderated content in blocks, and leveraging cryptographic signatures. Hashcash-based proof-of-work and Silent Payments are considered for anti-spam and security enhancements. - Nostr's limitations are acknowledged, yet enthusiasm persists for developing a relay system on it for mailing lists. Challenges in managing email servers versus nostr relays are compared, highlighting the ease of nostr maintenance and cryptographic advantages. - Running a personal mail server is suggested as a viable option for managing mailing lists, exemplified by https://lists.freebsd.org. Community members are open to setting up similar infrastructure for community projects. - The Bitcoin developer community leans towards adopting an alternative email service. Diverse communication channels, such as IRC, are valued, and the use of Discourse at Delvingbitcoin.org is noted for its technical discussion capabilities. - An innovative anti-spam measure proposes a fee for sending messages on a technical mailing list, possibly via the lightning network. Custom software development and integration with third-party hosting services are deemed possible with API access. - Issues with the nostr protocol, like single-key cryptography and mirroring relay problems, are highlighted. Peter Todd's insights are recommended for further exploration of these concerns. - It's stressed that GitHub should not replace mailing lists due to the importance of cryptographic signatures for message authenticity. GitHub Discussions offers robust tools but lacks clear support for email interactions. - Two solutions for the bitcoin-dev mailing list are proposed: finding a new host or replacing it altogether. The importance of a comprehensive archiving system is emphasized, considering accessibility and non-proprietary data formats. - Simple Machines Forum (SMF) is recommended for its strong anti-spam features and adaptability. Bryan Bishop acknowledges the usefulness of James O'Beirne's Git repository for archiving Delving Bitcoin discussions, and Blockchain Commons' use of GitHub discussions illustrates their practical application. - Concerns are raised about nostr's complexity and barriers to entry, favoring email for its universal accessibility. Matrix is introduced as a potential communication platform, with Synapse offering maintenance advantages. - Dan suggests Nostr for its resistance to mail server blocking and cost efficiency but notes missing features necessary for a smooth transition. Google Groups and groups.io are considered stable options for prioritizing email interfaces. - The bitcoin-dev mailing list is transitioning hosts after the Linux Foundation's decision to discontinue mailing list hosting. Public-inbox instances for decentralized archiving and enhanced moderator tools are recommended. The final decision on hosting will influence Bitcoin development coordination. - 2024-01-04T13:50:51+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml b/static/bitcoin-dev/Nov_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml index 44ed433b99..3667870399 100644 --- a/static/bitcoin-dev/Nov_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml +++ b/static/bitcoin-dev/Nov_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) - 2023-12-22T14:19:32.416217+00:00 - - Johan Torås Halseth 2023-12-21 13:34:36+00:00 - - - Antoine Riard 2023-12-17 22:56:38+00:00 - - - Johan Torås Halseth 2023-12-11 09:17:23+00:00 - - - Antoine Riard 2023-11-21 02:39:45+00:00 - - - Johan Torås Halseth 2023-10-26 16:52:03+00:00 - + 2025-09-26T14:27:08.135182+00:00 + python-feedgen + + + [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) Johan Torås Halseth + 2023-10-26T16:52:00.000Z + + + Antoine Riard + 2023-11-21T02:39:00.000Z + + + Johan Torås Halseth + 2023-12-11T09:17:00.000Z + + + Antoine Riard + 2023-12-17T22:56:00.000Z + + + Johan Torås Halseth + 2023-12-21T13:34:00.000Z + + - python-feedgen + 2 Combined summary - HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) - 2023-12-22T14:19:32.416275+00:00 + 2025-09-26T14:27:08.135897+00:00 + 2023-12-21T13:34:36+00:00 In a detailed examination of the security and functionality of the Lightning Network (LN) within Bitcoin's financial ecosystem, programmers Antoine and Johan engage in a technical discourse exploring potential vulnerabilities and solutions. The focus lies on the new covenant mechanism proposed as part of Bitcoin's Eltoo update, which simplifies LN transactions by collapsing multiple Hash Time-Locked Contracts (HTLCs) into a single output. This mechanism requires a user to provide a preimage and signature to spend an aggregated HTLC output, which can represent numerous individual HTLC payouts within standard transaction relay limits. A revelation made during this conversation is that counterparty attacks could occur through partial preimage revelation during transactions, enabling the replacement of legitimate network transactions with high-fee, low-value spends that lead to double-spending. - Antoine elaborates on an attack scenario involving Alice and Bob, where Bob could steal a larger HTLC payout by repeatedly replacing Alice's transactions with his own that carry higher fees. Such attacks exploit network mempool congestion, delaying the confirmation of malicious transactions. Antoine suggests that simply implementing self-adjusting fees will not suffice; instead, he proposes adding a sliding delay to HTLC timelocks based on block feerate to thwart attackers. The discussion also ventures into how witness size growth in a taproot-world scenario could be managed and considers efficient Script-level testing of partial set membership as a solution. - Further discussions involve the security implications of not broadcasting a revoked state in the Eltoo protocol, as raised by Antoine, and Johan's concern about managing an exponential growth in state combinations resulting from this vulnerability. They delve into the practical aspects of addressing these complexities, emphasizing the need for strategies to maintain system integrity. - The blog post transitions to discussing transaction recycling and slot jamming attacks, which are enabled by changes in HTLC second-level transactions for anchor channel types. It now allows additional fees to be added without invalidating previous signatures. The aggregation of HTLC outputs, while beneficial for reducing fee-bumping reserve requirements, introduces concerns about malleability and the depletion of value through excessive miners' fees. Segregating HTLC claims into separate outputs and introducing covenants might be a viable mitigation strategy. Other considerations include the current protocol limit affecting long-term payment throughput on the LN and the use of taproot branches to maintain near-constant size for claimed offered HTLCs. An exploration is made regarding the use of advanced cryptosystems to enhance scalability and security, despite trimmed HTLCs due to dust limits. - For further insights, the email refers readers to additional resources including GitHub repositories, commits demonstrating test attacks, and scholarly discussions. This comprehensive analysis underscores the importance of understanding not only the technical aspects but also the game-theoretical implications of cryptocurrency protocols to safeguard against potential threats to transaction processes on the Lightning Network. - 2023-12-21T13:34:36+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml b/static/bitcoin-dev/Nov_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml index 8098ec034f..ec64a6c6ee 100644 --- a/static/bitcoin-dev/Nov_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml +++ b/static/bitcoin-dev/Nov_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely - 2023-11-15T02:05:08.292575+00:00 + 2025-09-26T14:27:10.282178+00:00 + python-feedgen Peter Todd 2023-11-14 19:50:04+00:00 @@ -103,29 +104,21 @@ - python-feedgen + 2 Combined summary - OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely - 2023-11-15T02:05:08.292807+00:00 + 2025-09-26T14:27:10.282342+00:00 + 2023-11-14T19:50:04+00:00 The discussion addresses technical challenges within the Lightning Network, such as managing outdated states and transaction fees. It is recognized that while security could be improved, keeping transaction fees to a minimum relative to the channel's total value is essential for economic viability. - Miners benefit from the increase in feerate over discarded transactions when mining HTLC commitment transactions. Consequently, the need to minimize the proportion of channel value allocated to fees is highlighted, with suggestions to amend implementations that currently do not follow this principle. - The conversation also touches on Replace-by-Fee (RBF) mechanics, suggesting that increased channel fees could be extracted from the party broadcasting the commitment transaction to alleviate substantial fees upon closing channels. - SIGHASH_NOINPUT is proposed as a solution to sign HTLC refund transactions, which could simplify handling multiple fee rates. However, LN-Symmetry is considered insecure without a degree of trust between parties. - Package relay version 3 is introduced, changing how zero-value outputs are managed to prevent UTXO set growth. Anchor outputs must now be spent within the same package, impacting defensive strategies against double-spend attacks. - OP_Expire is presented, ensuring timely revelation of preimages in blockchain transactions and making them useless if not revealed promptly. This mechanism is critiqued for potentially enabling RBF without anchor outputs, leading to more efficient use of block space compared to CPFP with package relay. - Antoine's email highlights vulnerabilities in single-input commitment transactions and suggests pre-signing these with zero fees and using CPFP for necessary fee adjustments. However, there's a risk that replacement by CPFP could lead to eviction from the mempool. - An HTLC scenario explains how OP_EXPIRE can secure funds against potential attacks by enforcing timelocks. The ability of OP_Expire to prevent adversarial tactics like replacement cycling is questioned, indicating the need for further evaluation. - Overall, these discussions explore enhancements to the Lightning Network and smart contract scripting to improve security and efficiency. They address HTLCs and propose significant changes, such as introducing the OP_Expire opcode and considering soft fork upgrades for better transaction management and protection against attacks. - 2023-11-14T19:50:04+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_On-solving-pinning-replacement-cycling-and-mempool-issues-for-bitcoin-second-layers.xml b/static/bitcoin-dev/Nov_2023/combined_On-solving-pinning-replacement-cycling-and-mempool-issues-for-bitcoin-second-layers.xml index f6eeca4864..13996a3970 100644 --- a/static/bitcoin-dev/Nov_2023/combined_On-solving-pinning-replacement-cycling-and-mempool-issues-for-bitcoin-second-layers.xml +++ b/static/bitcoin-dev/Nov_2023/combined_On-solving-pinning-replacement-cycling-and-mempool-issues-for-bitcoin-second-layers.xml @@ -1,31 +1,31 @@ - + 2 Combined summary - On solving pinning, replacement cycling and mempool issues for bitcoin second-layers - 2023-11-16T02:02:45.685770+00:00 - - Antoine Riard 2023-11-15 18:14:28+00:00 - - - Antoine Riard 2023-10-22 02:27:37+00:00 - - - Antoine Riard 2023-10-22 02:27:37+00:00 - + 2025-09-26T14:26:40.265420+00:00 + python-feedgen + + + [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers Antoine Riard + 2023-10-22T02:27:00.000Z + + + Antoine Riard + 2023-11-15T18:14:00.000Z + + - python-feedgen + 2 Combined summary - On solving pinning, replacement cycling and mempool issues for bitcoin second-layers - 2023-11-16T02:02:45.685814+00:00 + 2025-09-26T14:26:40.265942+00:00 + 2023-11-15T18:14:28+00:00 The email outlines the considerations for creating a valid consensus-change based solution for Bitcoin L2, specifically regarding issues such as pinning and replacement cycling. The proposed solution should maintain non-interactive properties with off-chain counterparties, minimize fee-bumping reserves and UTXO locks, prevent malicious activities while allowing competition with ongoing fee rates, and ensure security for low-value lightning payments without relying on local knowledge of historical mempool states. It should also cater to multi-party off-chain constructions, reduce witness size through efficient scripting, guard against fee manipulation by low-hashrate miners, and be compatible with solutions to forced closure of time-sensitive off-chain states. Furthermore, it should not exacerbate problems like partial or global mempool partitioning. - A potential approach involves removing package malleability with annex and sighash_anyamount semantics, inspired by Peter Todd's op_expire proposal. However, there is no concrete design yet, and due to the complexity, any solution would require end-to-end implementation for validation, particularly for the Lightning Network. There's an acknowledgment that more mainnet experimentation is needed to address pinning, replacement cycling, and miner incentives alignment with second layers, urging further research within the Bitcoin community, especially given the importance of a reliable fee market in a post-subsidy world and sustaining a decentralized mining ecosystem. - Gleb Naumenko and the author intend to devote their research efforts to resolving these issues by examining cross-layer challenges they've previously explored together, referencing their expertise with bitcoin core and rust-lightning codebases. They plan to collaborate with Elichai Turkel on mathematical verification and risk assessments of potential fixes, aiming to reduce the fee-bumping reserve and locked UTXOs for lightning users. An issue on coordinated security handling has been reopened to bolster Lightning Network security. The sender stresses the need for game theory consideration and node network resource changes, following an open and responsible Bitcoin process, anticipating that this work will take significant time, much like the package relay design discussions that have recently advanced to review phases. Input from the Bitcoin and Lightning development community is welcomed as the solutions are developed. - 2023-11-15T18:14:28+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_Ordinals-BIP-PR.xml b/static/bitcoin-dev/Nov_2023/combined_Ordinals-BIP-PR.xml index 006d68d834..18bc5dbc4c 100644 --- a/static/bitcoin-dev/Nov_2023/combined_Ordinals-BIP-PR.xml +++ b/static/bitcoin-dev/Nov_2023/combined_Ordinals-BIP-PR.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Ordinals BIP PR - 2023-11-23T02:00:52.403974+00:00 - - Kostas Karasavvas 2023-11-22 11:27:03+00:00 - - - vjudeu at gazeta.pl 2023-11-21 23:10:55+00:00 - - - Kostas Karasavvas 2023-11-21 12:13:55+00:00 - - - vjudeu at gazeta.pl 2023-11-20 22:20:46+00:00 - - - Claus Ehrenberg 2023-11-09 22:32:10+00:00 - - - Casey Rodarmor 2023-11-09 02:15:05+00:00 - - - alicexbt 2023-10-27 17:05:46+00:00 - - - Alexander F. Moser 2023-10-27 09:39:44+00:00 - - - Peter Todd 2023-10-26 22:11:50+00:00 - - - Peter Todd 2023-10-26 22:05:30+00:00 - - - Luke Dashjr 2023-10-25 00:15:04+00:00 - - - Christopher Allen 2023-10-24 23:08:37+00:00 - - - Olaoluwa Osuntokun 2023-10-24 22:56:55+00:00 - - - alicexbt 2023-10-24 01:28:17+00:00 - - - Luke Dashjr 2023-10-23 18:29:50+00:00 - - - Andrew Poelstra 2023-10-23 17:43:29+00:00 - - - Ryan Breen 2023-10-23 17:26:06+00:00 - - - Tim Ruffing 2023-10-23 16:32:47+00:00 - - - Peter Todd 2023-10-23 15:35:30+00:00 - - - Léo Haf 2023-10-23 14:57:32+00:00 - - - Andrew Poelstra 2023-10-23 13:45:44+00:00 - - - Casey Rodarmor 2023-10-21 05:38:01+00:00 - + 2025-09-26T14:26:50.963057+00:00 + python-feedgen + + + [bitcoin-dev] Ordinals BIP PR Casey Rodarmor + 2023-10-21T05:38:00.000Z + + + Andrew Poelstra + 2023-10-23T13:45:00.000Z + + + Léo Haf + 2023-10-23T14:57:00.000Z + + + Peter Todd + 2023-10-23T15:35:00.000Z + + + Tim Ruffing + 2023-10-23T16:32:00.000Z + + + Ryan Breen + 2023-10-23T17:26:00.000Z + + + Andrew Poelstra + 2023-10-23T17:43:00.000Z + + + Luke Dashjr + 2023-10-23T18:29:00.000Z + + + alicexbt + 2023-10-24T01:28:00.000Z + + + Olaoluwa Osuntokun + 2023-10-24T22:56:00.000Z + + + Christopher Allen + 2023-10-24T23:08:00.000Z + + + Luke Dashjr + 2023-10-25T00:15:00.000Z + + + Peter Todd + 2023-10-26T22:05:00.000Z + + + Peter Todd + 2023-10-26T22:11:00.000Z + + + Alexander F. Moser + 2023-10-27T09:39:00.000Z + + + alicexbt + 2023-10-27T17:05:00.000Z + + + Casey Rodarmor + 2023-11-09T02:15:00.000Z + + + Claus Ehrenberg + 2023-11-09T22:32:00.000Z + + + vjudeu + 2023-11-20T22:20:00.000Z + + + Kostas Karasavvas + 2023-11-21T12:13:00.000Z + + + vjudeu + 2023-11-21T23:10:00.000Z + + + Kostas Karasavvas + 2023-11-22T11:27:00.000Z + + @@ -91,21 +116,17 @@ - python-feedgen + 2 Combined summary - Ordinals BIP PR - 2023-11-23T02:00:52.404120+00:00 + 2025-09-26T14:26:50.965425+00:00 + 2023-11-22T11:27:03+00:00 The discussion on Bitcoin ordinals highlights their design to ensure on-chain data persistence, which leads to fuller blocks and raises concerns about space competition between regular transactions and data embedding. A proposed technical solution suggests hiding ordinals behind an R-value in the witness part of a transaction input, which would reduce their size and cost while maintaining cryptographic proof and allowing for uncensorable inclusion in different types of addresses. - The role of Bitcoin Improvement Proposals (BIPs) is examined with the suggestion that they should focus on crucial protocol elements to preserve the integrity and functionality of Bitcoin. A minimalist approach is recommended to avoid overloading developers with non-essential features. Concerns are raised regarding the impartiality of BIP editors and the application of BIP 2 requirements, suggesting potential bias against proposals like ordinals. The conversation also explores the idea of listing BIPs not maintained in the official repository to challenge centralized management. - Debate surrounds the assignment and management of BIP numbers, with a proposal to automate this process using pull request numbers to address concerns about gatekeeping. This could lead to non-contiguous BIP numbers, but an offset starting at the highest manually assigned number could maintain order. Discussions also consider the subjective nature of terms in BIP 2, the workload of BIP editors, and calls for additional editorial assistance while addressing decentralization issues. - A restrained approach to BIPs is advocated, reserving them for widely-adopted standards and suggesting alternative repositories for non-BIP protocols. Transparency in the evaluation process of improvements is emphasized, as is the need to consider diverse community stakeholders in decision-making. Handling controversial proposals and recognizing the difference between technical documentation and implementation are also noted. - In a specific email, urgency is expressed concerning the progress of a PR for the Ordinals BIP. The sender seeks feedback from BIP editors to understand necessary actions for acceptance, emphasizing the importance of guidance in advancing the proposal's development process. The communication reflects professional persistence and a desire for pivotal editor interaction to facilitate the BIP's progression. - 2023-11-22T11:27:03+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_Proposed-BIP-for-MuSig2-Descriptors.xml b/static/bitcoin-dev/Nov_2023/combined_Proposed-BIP-for-MuSig2-Descriptors.xml index 07e0dbfeb8..389fcaf906 100644 --- a/static/bitcoin-dev/Nov_2023/combined_Proposed-BIP-for-MuSig2-Descriptors.xml +++ b/static/bitcoin-dev/Nov_2023/combined_Proposed-BIP-for-MuSig2-Descriptors.xml @@ -1,29 +1,31 @@ - + 2 Combined summary - Proposed BIP for MuSig2 Descriptors - 2023-11-08T17:08:56.337818+00:00 - - Salvatore Ingala 2023-11-07 11:34:46+00:00 - - - Andrew Chow 2023-10-10 22:30:21+00:00 - + 2025-09-26T14:26:48.815500+00:00 + python-feedgen + + + [bitcoin-dev] Proposed BIP for MuSig2 Descriptors Andrew Chow + 2023-10-10T22:30:00.000Z + + + Salvatore Ingala + 2023-11-07T11:34:00.000Z + + - python-feedgen + 2 Combined summary - Proposed BIP for MuSig2 Descriptors - 2023-11-08T17:08:56.337867+00:00 + 2025-09-26T14:26:48.815971+00:00 + 2023-11-07T11:34:46+00:00 The correspondence from Salvatore underscores a critical evaluation of the proposed Bitcoin Improvement Proposal (BIP) draft for MuSig2 descriptors, a new addition to Bitcoin Core intended to streamline the process for multiple signers to jointly create a single signature. The BIP draft, found on GitHub, introduces descriptors that offer an abstraction layer for defining sets of addresses and scripts within Bitcoin software. The proposal details syntax, semantics, and usage examples of MuSig2 descriptors to ensure standardization and ease of implementation for developers. - Salvatore's main point of contention lies in the utility of supporting KEY expressions with ranged derivations in the musig descriptor. He emphasizes the inefficiency of requiring each signer to derive the child xpub for each key and execute the KeyAgg algorithm multiple times when spending inputs. He proposes a more streamlined approach where KeyAgg is executed once for all inputs by appending the derivation path after the musig policy. This suggestion aims to reduce performance impact for signing devices and simplifies the creation of descriptor parsers. - The draft itself, along with the rationale behind the proposed structure and function of MuSig2 descriptors, is accessible through the provided GitHub link. Additionally, there is an active pull request to include this BIP draft in the official list of BIPs, which can be examined via the second link shared in the email. - In conclusion, while the overall goal of the BIP draft is to facilitate the use of MuSig2 descriptors, Salvatore advocates for a minimalistic approach that eschews unnecessary complexity and computational overhead unless justified by specific use cases. He suggests that a discussion on potential use cases and associated trade-offs may be beneficial if included in the BIP proposal, ensuring that the standard remains both practical and efficient. - 2023-11-07T11:34:46+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_Purely-off-chain-coin-colouring.xml b/static/bitcoin-dev/Nov_2023/combined_Purely-off-chain-coin-colouring.xml index cd9e0a3280..4380b4d4bf 100644 --- a/static/bitcoin-dev/Nov_2023/combined_Purely-off-chain-coin-colouring.xml +++ b/static/bitcoin-dev/Nov_2023/combined_Purely-off-chain-coin-colouring.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Purely off-chain coin colouring - 2023-11-21T02:05:43.408293+00:00 + 2025-09-26T14:26:44.560699+00:00 + python-feedgen vjudeu at gazeta.pl 2023-11-20 19:47:13+00:00 @@ -55,27 +56,20 @@ - python-feedgen + 2 Combined summary - Purely off-chain coin colouring - 2023-11-21T02:05:43.408390+00:00 + 2025-09-26T14:26:44.560856+00:00 + 2023-11-20T19:47:13+00:00 Blockchain standardization is a key topic, with suggestions to treat signature R-values as Taproot-based public keys for consistent protocol interpretation. Another approach proposes using commitments that can push any data and nest future commitments within previous ones, ensuring they remain off-chain by starting with OP_RETURN and expressing r-values as 256-bit numbers. - Minimal on-chain presence for inscriptions involves hashing the actual data and committing it via sign-to-contract to reduce the blockchain footprint. This technique enhances privacy and prevents issues like blocking or front-running. Sign-to-contract extends to timestamping by including a merkle root but raises concerns about ownership representation. The method requires generating a nonce and its public version, deriving a nonce, creating and verifying a signature, and is compatible with ecdsa and schnorr signatures. - Discussions on the bitcoin-dev mailing list highlight the trade-off between small block sizes for decentralization and the need for valuable block space to ensure Bitcoin's security through transaction fees. Solutions like ordinals or publications may drive demand for block space, while adjusting the inflation subsidy phase-out remains controversial. - -The debate on moving inscriptions off-chain considers the scarcity and value of blockspace versus network efficiency. Proposals suggest off-chain protocols for NFTs with proof of work or Lightning fees, allowing tracking without affecting how ordinals are spent. A patron system over Lightning is proposed, and the term "inscription" is debated in this context. - +The debate on moving inscriptions off-chain considers the scarcity and value of blockspace versus network efficiency. Proposals suggest off-chain protocols for NFTs with proof of work or Lightning fees, allowing tracking without affecting how ordinals are spent. A patron system over Lightning is proposed, and the term "inscription" is debated in this context. To combat NFT-related scams, theft, and duplication, solutions include requiring proof of work or Lightning payments for hosting NFTs. Nostr relay and proof of work are mentioned as tools for maintaining a clean digital artifact feed. Despite some resistance, the ordinals protocol is preferred for art projects, with an invitation for further input on its development. - Storing off-chain NFT data faces challenges due to third-party limitations. A proposal recommends using reliable parties to store proofs and artwork copies, with full versions released after transactions. Adjusting OP_RETURN size could address current constraints. On-chain data publishing is defended for its indefinite storage capabilities by archival nodes, questioning models like nostr for their data persistence. - -The integration of NFTs within Bitcoin involves using ordinals to track satoshis with unique "inscriptions," though linking specific data or rights to an ordinal remains unsolved. Moving inscriptions off-chain could lower costs and overhead, focusing on ownership transfer. RGB protocol and Taro support off-chain custody proofs for NFTs, raising concerns about the longevity of off-chain data compared to on-chain publication's guaranteed persistence. - +The integration of NFTs within Bitcoin involves using ordinals to track satoshis with unique "inscriptions," though linking specific data or rights to an ordinal remains unsolved. Moving inscriptions off-chain could lower costs and overhead, focusing on ownership transfer. RGB protocol and Taro support off-chain custody proofs for NFTs, raising concerns about the longevity of off-chain data compared to on-chain publication's guaranteed persistence. Further discussions explore semi-fungible tokens on the Liquid network and privacy through zero-knowledge proofs or unobservable transfers via nostr events. In conclusion, developers are considering various approaches to incorporate NFTs into Bitcoin, aiming to balance cost, scalability, and data permanence as they move towards integrating colored bitcoins. - 2023-11-20T19:47:13+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml b/static/bitcoin-dev/Nov_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml index c521c5b761..46903daccc 100644 --- a/static/bitcoin-dev/Nov_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml +++ b/static/bitcoin-dev/Nov_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml @@ -1,53 +1,67 @@ - + 2 Combined summary - Scaling Lightning With Simple Covenants - 2023-11-17T02:04:15.764762+00:00 - - jlspc 2023-11-15 19:59:37+00:00 - - - jlspc 2023-10-06 16:26:33+00:00 - - - jlspc 2023-10-06 16:26:33+00:00 - - - jlspc 2023-09-28 15:56:11+00:00 - - - Antoine Riard 2023-09-26 16:42:34+00:00 - - - ZmnSCPxj 2023-09-19 07:44:48+00:00 - - - ZmnSCPxj 2023-09-18 04:14:55+00:00 - - - Erik Aronesty 2023-09-17 11:32:52+00:00 - - - jlspc 2023-09-17 00:59:39+00:00 - - - jlspc 2023-09-17 00:56:04+00:00 - - - jlspc 2023-09-17 00:52:13+00:00 - - - Antoine Riard 2023-09-11 05:27:25+00:00 - - - Rusty Russell 2023-09-11 02:13:52+00:00 - - - Anthony Towns 2023-09-11 00:56:40+00:00 - - - jlspc 2023-09-08 18:54:46+00:00 - + 2025-09-26T14:26:42.413627+00:00 + python-feedgen + + + [bitcoin-dev] Scaling Lightning With Simple Covenants jlspc + 2023-09-08T18:54:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2023-09-11T00:56:00.000Z + + + [bitcoin-dev] " Rusty Russell + 2023-09-11T02:13:00.000Z + + + Antoine Riard + 2023-09-11T05:27:00.000Z + + + jlspc + 2023-09-17T00:52:00.000Z + + + jlspc + 2023-09-17T00:56:00.000Z + + + jlspc + 2023-09-17T00:59:00.000Z + + + Erik Aronesty + 2023-09-17T11:32:00.000Z + + + ZmnSCPxj + 2023-09-18T04:14:00.000Z + + + ZmnSCPxj + 2023-09-19T07:44:00.000Z + + + Antoine Riard + 2023-09-26T16:42:00.000Z + + + jlspc + 2023-09-28T15:56:00.000Z + + + jlspc + 2023-10-06T16:26:00.000Z + + + jlspc + 2023-11-15T19:59:00.000Z + + @@ -63,23 +77,18 @@ - python-feedgen + 2 Combined summary - Scaling Lightning With Simple Covenants - 2023-11-17T02:04:15.764876+00:00 + 2025-09-26T14:26:42.415113+00:00 + 2023-11-15T19:59:37+00:00 The recent discussions among programmers have centered on enhancing the Lightning Network's operation and scalability. John has analyzed trade-offs between trust/safety and capital efficiency, suggesting a prepayment system to balance channel lifetime risks and fund adjustments. He has calculated the scalability of timeout-tree leaves on-chain using a Python program and contributed to a paper on passive rollovers, detailing the functioning of commitment transactions in hierarchical channels. - Antoine has highlighted scaling issues for off-chain constructions, like liquidity imbalances, proposing improvements such as on-chain splicing. He also expressed concerns about coordinating a large number of users and mentioned cryptographic tools for better scalability. - -John agreed with Antoine on addressing the needs of casual users, proposing hierarchical channels and timeout-trees for their convenience. He acknowledged practical challenges in coordination for required signatures and emphasized solutions that limit interactivity. John recommended a consensus rule change to deal with the "thundering herd" problem by basing timeout-tree expirations on low-fee block occurrences. - -The email defines user categories as "casual" or "dedicated," discussing trust assumptions and different scaling aspects: onboarding, transactional, and user resource scaling. It questions the feasibility of casual users engaging in future time-bound actions and highlights concerns about fund access, mempool congestion, and fee risk mitigation. - -The correspondence outlines critical issues in off-chain scaling, such as enforcement costs in channel factories and the trade-off between trust and capital efficiency. The paper suggests tolerating an increase in transactions for rule enforcement in mature systems. It contemplates the role of "dedicated users" within the fee structure and the balancing act between capital commitment and efficiency. - +John agreed with Antoine on addressing the needs of casual users, proposing hierarchical channels and timeout-trees for their convenience. He acknowledged practical challenges in coordination for required signatures and emphasized solutions that limit interactivity. John recommended a consensus rule change to deal with the "thundering herd" problem by basing timeout-tree expirations on low-fee block occurrences. +The email defines user categories as "casual" or "dedicated," discussing trust assumptions and different scaling aspects: onboarding, transactional, and user resource scaling. It questions the feasibility of casual users engaging in future time-bound actions and highlights concerns about fund access, mempool congestion, and fee risk mitigation. +The correspondence outlines critical issues in off-chain scaling, such as enforcement costs in channel factories and the trade-off between trust and capital efficiency. The paper suggests tolerating an increase in transactions for rule enforcement in mature systems. It contemplates the role of "dedicated users" within the fee structure and the balancing act between capital commitment and efficiency. The email proposes covenant-based solutions like CheckTemplateVerify (CTV) or AnyPrevOut (APO) for creating scalable channels without all participants' signatures. This approach reduces the need for co-owning on-chain UTXOs, enhancing scalability. It recommends integrating simple covenants and off-chain transaction methods into Bitcoin's consensus rules to reduce the on-chain footprint and facilitate off-chain operations, making the Lightning Network more accessible for payments. - 2023-11-15T19:59:37+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_The-Pinning-Replacement-Problem-Set.xml b/static/bitcoin-dev/Nov_2023/combined_The-Pinning-Replacement-Problem-Set.xml index 1171919ba4..0558bd27e5 100644 --- a/static/bitcoin-dev/Nov_2023/combined_The-Pinning-Replacement-Problem-Set.xml +++ b/static/bitcoin-dev/Nov_2023/combined_The-Pinning-Replacement-Problem-Set.xml @@ -1,47 +1,43 @@ - + 2 Combined summary - The Pinning & Replacement Problem Set - 2023-11-05T02:08:47.744592+00:00 - - Antoine Riard 2023-11-03 19:57:35+00:00 - - - Peter Todd 2023-11-02 15:42:29+00:00 - - - John Carvalho 2023-11-02 08:58:36+00:00 - + 2025-09-26T14:26:59.579339+00:00 + python-feedgen + + + [bitcoin-dev] The Pinning & Replacement Problem Set John Carvalho + 2023-11-02T08:58:00.000Z + + + Peter Todd + 2023-11-02T15:42:00.000Z + + + Antoine Riard + 2023-11-03T19:57:00.000Z + + - python-feedgen + 2 Combined summary - The Pinning & Replacement Problem Set - 2023-11-05T02:08:47.744652+00:00 + 2025-09-26T14:26:59.579916+00:00 - In the email exchange between Antoine and John, the discussion revolves around the safety issues related to lightning and other time-sensitive layers being affected when blocks are full. Antoine mentions that this issue has been described in a paper under the "forced expiration spam" problems arising within a high block space demand environment. He also acknowledges that there are variants of these issues with scenarios like "flood & loot." The new problem that arises is that the counterparty channel might defer the confirmation of an honest on-chain spend, which aligns with miners' incentives. - + 2023-11-03T19:57:35+00:00 + In the email exchange between Antoine and John, the discussion revolves around the safety issues related to lightning and other time-sensitive layers being affected when blocks are full. Antoine mentions that this issue has been described in a paper under the "forced expiration spam" problems arising within a high block space demand environment. He also acknowledges that there are variants of these issues with scenarios like "flood & loot." The new problem that arises is that the counterparty channel might defer the confirmation of an honest on-chain spend, which aligns with miners' incentives. Antoine suggests several options to address this issue. The first option is to revert to a static world with no replacement-by-fee mechanism as a widely deployed network policy. Antoine believes that in a competitive mining environment, parties can always reach out to miners with higher fee packages than available in the local mempool. - The second option proposed by Antoine is to design, implement, and deploy policies that better capture transaction-issuer intent regarding the replacement of current in-mempool transactions. However, Antoine points out that with lightning and other time-sensitive layers, there isn't a single transaction-issuer intent due to the competing interests of counterparties within off-chain states. - -The third option suggested by Antoine is to remove all policies and let the network of nodes and the economic ecosystem evolve on its own. Antoine notes that some mempool policies are anti-Denial-of-Service measures protecting low-performance full-nodes, and these measures contribute to pinning issues. He believes that "pure" replacement-by-fee (RBF) only worsens adversarial replacement issues. - +The third option suggested by Antoine is to remove all policies and let the network of nodes and the economic ecosystem evolve on its own. Antoine notes that some mempool policies are anti-Denial-of-Service measures protecting low-performance full-nodes, and these measures contribute to pinning issues. He believes that "pure" replacement-by-fee (RBF) only worsens adversarial replacement issues. The fourth option proposed by Antoine is to do nothing and allow a fragmented mempool environment, where large lightning and Bitcoin businesses have out-of-band relationships with miners and pools to support their packages, along with some service-level safety agreements. This option was previously considered by the lightning community to solve pinning issues but was dismissed due to concerns about centralization. - -The final option suggested by Antoine is to design and implement some consensus change or alter the processing requirements of full-nodes to align incentives between miners and time-sensitive second-layers. He mentions the "reverse locktime" new Bitcoin script opcode idea or a replacement cache at the mempool level as examples. - +The final option suggested by Antoine is to design and implement some consensus change or alter the processing requirements of full-nodes to align incentives between miners and time-sensitive second-layers. He mentions the "reverse locktime" new Bitcoin script opcode idea or a replacement cache at the mempool level as examples. In response, John disagrees with Antoine's statement linking replacement cycling to full-RBF (replace-by-fee). He argues that in the case of anchor channels, it is not even possible to turn off RBF due to the 1 block CSV delay. John also mentions that the largest pool, AntPool, currently has full-RBF enabled. He suggests designing protocols that are made secure by clear incentives instead of relying on specific mempool behaviors. - John further expresses his concern that all layers and technologies built on Bitcoin will fail when miners misbehave or when blocks and the mempool remain consistently full. He criticizes the decision to mess with mempool policies like RBF and mempoolfullrbf, stating that they have disrupted the fragile harmony and utility of Bitcoin. He emphasizes that both pinning and replacement problems now exist in Lightning due to these changes. - -John presents several options for Core to address the issue. The first option is to try to revert mempoolfullrbf and reinstate the first-seen policy, although it is uncertain if this would be effective. The second option is to create additional policies that allow users to flag how they want their transactions handled, such as distinguishing between "pin this" and "replace this." John considers this the best option as it provides utility and aligns with incentives. - +John presents several options for Core to address the issue. The first option is to try to revert mempoolfullrbf and reinstate the first-seen policy, although it is uncertain if this would be effective. The second option is to create additional policies that allow users to flag how they want their transactions handled, such as distinguishing between "pin this" and "replace this." John considers this the best option as it provides utility and aligns with incentives. The third option is to remove all policy and let the market evolve to deal with the chaos, similar to doing nothing. The fourth option is to allow a fractured mempool environment to develop where large businesses form private contracts with miners and pools to support their own policies, providing better experiences to customers and users. The fifth option is to invent a new cryptographic solution that John cannot currently imagine. - In conclusion, the email exchange highlights the safety issues related to lightning and time-sensitive layers in the context of full blocks and explores various options for addressing these problems. Both Antoine and John present different perspectives on how to navigate these challenges and find solutions that align with incentives and preserve the utility of Bitcoin. - 2023-11-03T19:57:35+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_a-simple-and-easy-to-remember-personalized-mnemonic-generation-scheme.xml b/static/bitcoin-dev/Nov_2023/combined_a-simple-and-easy-to-remember-personalized-mnemonic-generation-scheme.xml index 5adb5d5e56..b122714ce2 100644 --- a/static/bitcoin-dev/Nov_2023/combined_a-simple-and-easy-to-remember-personalized-mnemonic-generation-scheme.xml +++ b/static/bitcoin-dev/Nov_2023/combined_a-simple-and-easy-to-remember-personalized-mnemonic-generation-scheme.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - a simple and easy-to-remember personalized mnemonic generation scheme - 2023-11-08T17:12:58.280417+00:00 - - symphonicbtc 2023-11-07 17:31:01+00:00 - - - Joe 2023-11-06 08:57:04+00:00 - + 2025-09-26T14:26:55.322568+00:00 + python-feedgen + + + [bitcoin-dev] a simple and easy-to-remember personalized mnemonic generation scheme =?gb18030?B?Sm9l?= + 2023-11-06T08:57:00.000Z + + + symphonicbtc + 2023-11-07T17:31:00.000Z + + - python-feedgen + 2 Combined summary - a simple and easy-to-remember personalized mnemonic generation scheme - 2023-11-08T17:12:58.280473+00:00 + 2025-09-26T14:26:55.323126+00:00 + 2023-11-07T17:31:01+00:00 The discourse centers around a novel mnemonic generation method proposed by Joe, which aims to simplify and personalize the process of obtaining mnemonic phrases for cryptocurrency wallets. Joe's approach allows users to create their own easy-to-remember sentences in any language and then uses the SHA256 algorithm to transform these sentences into entropy. From there, the system generates a mnemonic that is compatible with the BIP-39 standard, making it more user-friendly and reducing the need for mnemonic memorization or writing down. - However, this methodology has been met with some skepticism due to concerns regarding security. It is pointed out that the creation of mnemonics should not rely on human-generated phrases because people are poor at providing random and secure inputs, a requirement that is essential for safeguarding digital assets. The original intent behind BIP-39 was to prevent such practices by ensuring that mnemonics are generated randomly, thereby providing the necessary entropy for security. - Despite these reservations, there is acknowledgment of the potential for innovation in wallet systems and a suggestion for further exploration into generating readable sentences as mnemonics, particularly for English speakers. The feasibility of such an approach in other languages like Chinese remains uncertain. Joe's reference implementation can be found on GitHub, offering a practical example of his idea in action, potentially serving as a starting point for future development and discussion within the field. - 2023-11-07T17:31:01+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_bitcoin-dev-Digest-Vol-102-Issue-15.xml b/static/bitcoin-dev/Nov_2023/combined_bitcoin-dev-Digest-Vol-102-Issue-15.xml index 5a351e5832..bb97b3faf9 100644 --- a/static/bitcoin-dev/Nov_2023/combined_bitcoin-dev-Digest-Vol-102-Issue-15.xml +++ b/static/bitcoin-dev/Nov_2023/combined_bitcoin-dev-Digest-Vol-102-Issue-15.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-dev Digest, Vol 102, Issue 15 - 2023-11-09T08:34:31.206521+00:00 + 2025-09-26T14:27:05.988280+00:00 + python-feedgen Luke Kenneth Casson Leighton 2023-11-08 02:00:00+00:00 @@ -15,19 +16,16 @@ - python-feedgen + 2 Combined summary - bitcoin-dev Digest, Vol 102, Issue 15 - 2023-11-09T08:34:31.206593+00:00 + 2025-09-26T14:27:05.988408+00:00 + 2023-11-08T02:00:00+00:00 The discussion opens with a recognition of the importance of email lists as a means to stay abreast of technical dialogues within a particular community. It's suggested that email lists are a preferred method for knowledge sharing, and there is an active search for alternatives to the current system, indicating some limitations or the need for better features. Alain Williams, who previously chaired UKUUG 25 years ago, is mentioned as a competent individual capable of managing such lists through his platform at lists.phcomp.co.uk. This reference points towards the quest for reliable list management. - Furthermore, the communication touches upon the use of NNTP newsgroups as an alternative, highlighting their long-standing presence in the tech world and their functionality when properly managed. Eternal-september.org is presented as a credible provider of spam-free NNTP newsgroup services, demonstrating the writer’s preference for proven, traditional methods of online communication. The author also introduces public-inbox, a sophisticated tool that allows the archiving of emails within a git repository, which can be found at https://github.com/nojb/public-inbox. Public-inbox offers flexible reading options, including NNTP, IMAP, Atom feeds, and HTML archives, and has the capability to import historical data from mailman archives, illustrating its versatility and advanced capabilities for handling email-based discussions. - Additionally, the message addresses concerns regarding the desire for anonymity and the avoidance of high-resource systems by suggesting solutions like ProtonMail, mail-forwarders, and TOR networks. Such alternatives accommodate those who prefer or require privacy without necessitating significant hosting resources. - Lastly, the email includes a link to a crowd-funded, eco-conscious hardware project on Crowd Supply, accessible via https://www.crowdsupply.com/eoma68. This serves as an indication of the writer's interest in open-source hardware initiatives that align with the broader theme of open and accessible communication tools, further reinforcing the ethos of community engagement and collaboration. - 2023-11-08T02:00:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2023/combined_ossification-and-misaligned-incentive-concerns.xml b/static/bitcoin-dev/Nov_2023/combined_ossification-and-misaligned-incentive-concerns.xml index 07858fdf2f..01afa022c6 100644 --- a/static/bitcoin-dev/Nov_2023/combined_ossification-and-misaligned-incentive-concerns.xml +++ b/static/bitcoin-dev/Nov_2023/combined_ossification-and-misaligned-incentive-concerns.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ossification and misaligned incentive concerns - 2023-11-08T17:12:36.688671+00:00 + 2025-09-26T14:26:57.467849+00:00 + python-feedgen JK 2023-11-07 12:24:39+00:00 @@ -35,23 +36,18 @@ - python-feedgen + 2 Combined summary - ossification and misaligned incentive concerns - 2023-11-08T17:12:36.688762+00:00 + 2025-09-26T14:26:57.468065+00:00 + 2023-11-07T12:24:39+00:00 The email discussion opens with a critical examination of Bitcoin's economic model, particularly the challenges stemming from its programmed halvings and inflation rate. It points out that the system's initial expansion, which helped stakeholders weather high inflation phases, is nearing saturation, and the lack of control over the transition from high to low inflation rates is causing favoritism and conflicts of interest among different user groups. This imbalance has been evident for years, with transaction fees being a contentious issue, as demonstrated by the recent uproar caused by Ordinals. The concern is that users who actively transact will not indefinitely bear the cost of network security, benefiting passive stakeholders who do not contribute. The writer suggests that a possible solution might involve a conditional delay in halvings during prolonged network regression periods, thus preventing free rider problems and ensuring compatibility between new and old code until a critical event necessitates change. - Further exploration into Bitcoin's economic principles is presented through an analysis of mining and its influence on the network's value. By drawing parallels to the Rai stones of the Yapese people, the email illustrates how ease of production can devalue a currency, inferring that miners play a crucial role in preserving Bitcoin's purchasing power. It asserts that while private keys are secure and the blockchain fully validating, miners are essential in protecting the value of Bitcoin, rather than merely processing transactions. - The narrative surrounding the miners' role in network security is questioned in another part of the email. The author argues that miners provide only double-spend insurance, which influences the size and clearance of transactions but does not equate to comprehensive network security. They stress that individual ownership of private keys and full validation of their notes means that miners have no power over them, challenging the prevailing view of miners as guarantors of overall network security. - A discussion about the perception of direct versus hidden taxes reveals the preference for less noticeable taxes, drawing a parallel with transaction fees and block rewards in Bitcoin. The writer presents a hypothetical system with constant difficulty and adjustable block rewards, limiting network security due to Earth's finite resources. They highlight a natural balance between network security and inflation levels, comparing this relationship to central banking practices while noting its novelty within a monetary system like Bitcoin. - Finally, the email broaches the topic of centralized service providers' growing sway over Bitcoin's development, emphasizing the tension between user demands for privacy and scaling and the service providers' business models. As these providers solidify their positions, a small but influential technical minority appears to be supporting an off-chain, federated ecosystem, potentially at odds with the broader user base's interests. This observation underscores the complexities within the Bitcoin ecosystem where individual and collective incentives may diverge. - Throughout the summary, the information is structured into cohesive paragraphs with each paragraph addressing a distinct aspect or concern raised in the original text, maintaining formal tone and grammatical correctness without resorting to bullet points. Links and references provided in the original email have been omitted in the summary as per the instructions given. - 2023-11-07T12:24:39+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_BIP-21-Updates.xml b/static/bitcoin-dev/Nov_2024/combined_BIP-21-Updates.xml index 1ffc28b16d..1af05109de 100644 --- a/static/bitcoin-dev/Nov_2024/combined_BIP-21-Updates.xml +++ b/static/bitcoin-dev/Nov_2024/combined_BIP-21-Updates.xml @@ -1,25 +1,29 @@ - + 2 Combined summary - BIP 21 Updates - 2024-11-13T02:19:14.969647+00:00 - - Matt Corallo 2024-11-12 16:07:00+00:00 - - - Matt Corallo 2024-05-30 21:54:00+00:00 - + 2025-09-26T14:39:33.238638+00:00 + python-feedgen + + + BIP 21 Updates Matt Corallo + 2024-05-30T21:54:00.000Z + + + Matt Corallo + 2024-11-12T16:07:00.000Z + + - python-feedgen + 2 Combined summary - BIP 21 Updates - 2024-11-13T02:19:14.969686+00:00 + 2025-09-26T14:39:33.239080+00:00 - The recent discussions within the Bitcoin development community have brought attention to the limitations of the current BIP 21 standard, which primarily focuses on transactions using base58 addresses and lacks official support for more advanced addressing schemes like Segwit and Taproot. Given the significant adoption of wallets that can handle these newer types of addresses and decode lightning payment instructions from URI query parameters, there's a consensus on the need to modernize BIP 21. This update would not only accommodate the inclusion of Segwit and Taproot addresses in URI bodies but also support the evolving Bitcoin payment landscape, including Silent Payments and BOLT 12. The proposal suggests enhancing BIP 21 URIs to enable the embedding of various payment instructions through distinct query parameters, making the body of the URI optional for schemes that do not require a standard on-chain fallback. This approach aims to ensure compatibility with existing wallets by allowing them to ignore unrecognized new query parameters and reject invalid URIs without a body. - -Furthermore, a new Bitcoin Improvement Proposal (BIP) is being drafted to introduce an additional feature aimed at enriching the payment process. This includes the implementation of a "payment info callback" parameter, which does not affect current wallet operations but offers an important functionality for specific use cases, such as nostr zaps. The proposal outlines the mechanics of a Proof of Payment mechanism where the URI may contain a "pop" (or "req-pop") parameter. This parameter enables the construction of a URI that the wallet application can open post-payment to provide proof of payment completion or other relevant information. The parameter must be a percent-encoded URI prefix, following RFC 3986 section 2.1 guidelines. Upon payment completion, supported wallet applications will percent-decode this URI, append it with payment information, and open it with the system's default handler, barring certain schemes like HTTP or JavaScript to ensure security. For on-chain transactions, the payment information should include the full transaction data in hex format, while for BOLT 11 invoice payments, it should be the hex-encoded payment preimage. This innovative approach facilitates a more transparent and verifiable payment process, potentially setting a new standard for payment information sharing across different payment methods within the Bitcoin ecosystem. 2024-11-12T16:07:00+00:00 + The recent discussions within the Bitcoin development community have brought attention to the limitations of the current BIP 21 standard, which primarily focuses on transactions using base58 addresses and lacks official support for more advanced addressing schemes like Segwit and Taproot. Given the significant adoption of wallets that can handle these newer types of addresses and decode lightning payment instructions from URI query parameters, there's a consensus on the need to modernize BIP 21. This update would not only accommodate the inclusion of Segwit and Taproot addresses in URI bodies but also support the evolving Bitcoin payment landscape, including Silent Payments and BOLT 12. The proposal suggests enhancing BIP 21 URIs to enable the embedding of various payment instructions through distinct query parameters, making the body of the URI optional for schemes that do not require a standard on-chain fallback. This approach aims to ensure compatibility with existing wallets by allowing them to ignore unrecognized new query parameters and reject invalid URIs without a body. +Furthermore, a new Bitcoin Improvement Proposal (BIP) is being drafted to introduce an additional feature aimed at enriching the payment process. This includes the implementation of a "payment info callback" parameter, which does not affect current wallet operations but offers an important functionality for specific use cases, such as nostr zaps. The proposal outlines the mechanics of a Proof of Payment mechanism where the URI may contain a "pop" (or "req-pop") parameter. This parameter enables the construction of a URI that the wallet application can open post-payment to provide proof of payment completion or other relevant information. The parameter must be a percent-encoded URI prefix, following RFC 3986 section 2.1 guidelines. Upon payment completion, supported wallet applications will percent-decode this URI, append it with payment information, and open it with the system's default handler, barring certain schemes like HTTP or JavaScript to ensure security. For on-chain transactions, the payment information should include the full transaction data in hex format, while for BOLT 11 invoice payments, it should be the hex-encoded payment preimage. This innovative approach facilitates a more transparent and verifiable payment process, potentially setting a new standard for payment information sharing across different payment methods within the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_Bitcoin-Core-on-ARM-Windows-.xml b/static/bitcoin-dev/Nov_2024/combined_Bitcoin-Core-on-ARM-Windows-.xml index 36c3409f84..1fc1bb19e3 100644 --- a/static/bitcoin-dev/Nov_2024/combined_Bitcoin-Core-on-ARM-Windows-.xml +++ b/static/bitcoin-dev/Nov_2024/combined_Bitcoin-Core-on-ARM-Windows-.xml @@ -1,25 +1,29 @@ - + 2 Combined summary - Bitcoin Core on ARM (Windows) - 2024-11-22T02:28:06.726361+00:00 - - Antoine Riard 2024-11-21 23:57:00+00:00 - - - Ali Sherief 2024-11-21 09:03:00+00:00 - + 2025-09-26T14:39:41.840601+00:00 + python-feedgen + + + Bitcoin Core on ARM (Windows) Ali Sherief + 2024-11-21T09:03:00.000Z + + + Antoine Riard + 2024-11-21T23:57:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Core on ARM (Windows) - 2024-11-22T02:28:06.726401+00:00 + 2025-09-26T14:39:41.841099+00:00 + 2024-11-21T23:57:00+00:00 Compiling Windows for the ARM instruction set architecture involves configuring your compiler, such as gcc or clang, to build your kernel code specifically for ARM hardware platforms. This process does not require a unique ARM toolchain since modern compilers are capable of cross-platform compilation, including building on x86-64 and targeting ARM. The task also involves some linker configurations to manage the assembly functions properly. In the context of the Bitcoin core codebase, there are mentions of x86-specific assembly functions within the secp256k1 library, which are mainly about scalar optimizations. Such details might be particularly interesting, as highlighted in a discussion on the Bitcoin Development Mailing List ([Bitcoindev](https://groups.google.com/g/bitcoindev/c/fOIByS6COMk)). The focus is not necessarily on compiling the entirety of the Bitcoin core but rather on fine-tuning the libbitcoinkernel engine. The inclusion of RISC-V support for the consensus engine's compilation could mark a significant advancement. - On another note, there's an observation that ARM binaries are available for all major operating systems except Windows, despite Apple Silicon being essentially ARM-based. This raises questions about the feasibility of creating ARM binaries for Windows and whether existing methods support Arm64. The Windows build guide suggests Visual Studio as a potential tool that might facilitate ARM support, but the presence of x86-specific assembly functions in the codebase could pose challenges for the build process. - 2024-11-21T23:57:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_Broken-links-to-the-previous-mailing-list-archive.xml b/static/bitcoin-dev/Nov_2024/combined_Broken-links-to-the-previous-mailing-list-archive.xml index 79bcf302d3..88b086d256 100644 --- a/static/bitcoin-dev/Nov_2024/combined_Broken-links-to-the-previous-mailing-list-archive.xml +++ b/static/bitcoin-dev/Nov_2024/combined_Broken-links-to-the-previous-mailing-list-archive.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Broken links to the previous mailing list archive - 2024-11-15T02:27:56.179566+00:00 - - Andrew Poelstra 2024-11-14 14:30:00+00:00 - - - Weikeng Chen 2024-11-13 02:35:00+00:00 - - - Bryan Bishop 2024-11-12 19:54:00+00:00 - + 2025-09-26T14:39:50.326728+00:00 + python-feedgen + + + Broken links to the previous mailing list archive Bryan Bishop + 2024-11-12T19:54:00.000Z + + + Weikeng Chen + 2024-11-13T02:35:00.000Z + + + Andrew Poelstra + 2024-11-14T14:30:00.000Z + + - python-feedgen + 2 Combined summary - Broken links to the previous mailing list archive - 2024-11-15T02:27:56.179610+00:00 + 2025-09-26T14:39:50.327295+00:00 + 2024-11-14T14:30:00+00:00 The ongoing discussion raises concerns about the sustainability and reliability of hosting Bitcoin mailing lists, emphasizing the need for the community to secure its domain to ensure the longevity of critical communication channels. This arises from challenges experienced with external organizations like the Linux Foundation, which may not always provide indefinite support for Bitcoin-related projects. The conversation highlights an instance where the Linux Foundation agreed to host archives for the Bitcoin development community but later decided to discontinue this service. Such a move has significant implications, as it disrupts access to valuable resources and leaves numerous internet links leading to these resources broken. Despite this setback, the Linux Foundation's willingness to keep read-only archives accessible presents an opportunity for collaboration and eases the transition to a new domain. - The discontinuation of hosting by the Linux Foundation has prompted the Bitcoin community to explore alternatives for preserving access to vital content. Among the proposed solutions is a redirect service offered by gnusha.org, which facilitates the redirection of old URLs to new locations within the mailing list archives. This service operates on a straightforward mechanism requiring a previous URL input to map to a current archive location, offering a simple yet effective method for link updating. Additionally, a Python script available on GitHub provides another means to manually resolve URLs from their old Linux Foundation format to new destinations. This approach, although slightly more technical, ensures the continued accessibility of previously archived content, catering to those willing to undertake a more hands-on resolution process. - The importance of maintaining access to these archives cannot be overstated, as they hold canonical information essential to the development and historical understanding of Bitcoin. As the community grapples with these changes, the collective endeavor to update and preserve these links underscores the critical nature of this content. Both the gnusha.org redirect service and the manual resolution script offer viable pathways to mitigate the impact of the Linux Foundation's decision, highlighting the community's resilience and commitment to safeguarding the accessibility of indispensable resources. The choice between utilizing the redirect service or engaging in manual resolution reflects broader considerations around ease of use and the assurance of content integrity, with each method presenting its advantages. - 2024-11-14T14:30:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_CHECKSIGFROMSTACK-VERIFY-ADD-.xml b/static/bitcoin-dev/Nov_2024/combined_CHECKSIGFROMSTACK-VERIFY-ADD-.xml index 3e67e26ff0..ab9e73a33a 100644 --- a/static/bitcoin-dev/Nov_2024/combined_CHECKSIGFROMSTACK-VERIFY-ADD-.xml +++ b/static/bitcoin-dev/Nov_2024/combined_CHECKSIGFROMSTACK-VERIFY-ADD-.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - CHECKSIGFROMSTACK(VERIFY/ADD) - 2024-11-24T02:37:35.358873+00:00 - - moonsettler 2024-11-23 19:45:00+00:00 - - - Antoine Poinsot 2024-11-15 15:33:00+00:00 - - - Murch 2024-11-15 14:57:00+00:00 - - - moonsettler 2024-11-15 10:14:00+00:00 - - - Brandon Black 2024-11-14 22:02:00+00:00 - + 2025-09-26T14:39:46.064520+00:00 + python-feedgen + + + CHECKSIGFROMSTACK(VERIFY/ADD) Brandon Black + 2024-11-14T22:02:00.000Z + + + moonsettler' + 2024-11-15T10:14:00.000Z + + + Murch + 2024-11-15T14:57:00.000Z + + + Antoine Poinsot' + 2024-11-15T15:33:00.000Z + + + moonsettler' + 2024-11-23T19:45:00.000Z + + - python-feedgen + 2 Combined summary - CHECKSIGFROMSTACK(VERIFY/ADD) - 2024-11-24T02:37:35.358928+00:00 + 2025-09-26T14:39:46.065292+00:00 + 2024-11-23T19:45:00+00:00 The recent discussions among Bitcoin developers have highlighted several key considerations regarding the future of the Bitcoin protocol, particularly in relation to legacy script functionalities and the introduction of new opcodes. One focal point of these deliberations is the potential removal of the CHECKSIGFROMSTACKVERIFY (CSFSV) opcode from the legacy script in favor of using a combination of OP_CSFS and OP_VERIFY for similar functionality. This consideration stems from an assessment that current uses and the potential for future applications do not necessitate CSFSV's inclusion, especially given the limited availability of upgradeable NOPs and the capacity to backport tapscript, which would inherently provide all desired functionalities to legacy systems. - The discourse extends to the broader implications of altering legacy Script, highlighting the importance of cautious evaluation before making any changes. The rationale behind this conservative approach is to maintain the stability and predictability of the system, acknowledging that modifications could complicate the analysis of worst-case scenarios and the overall understanding of the script's behavior under extreme conditions. This perspective underscores the necessity of a compelling use case or significant advantage before implementing changes that might affect the foundational aspects of Bitcoin’s protocol. - Further discussions have revolved around the implementation and prospective use of signature aggregation and how it intersects with the development of CHECKSIGFROMSTACK (CSFS) and related functionalities like CHECKTEMPLATEVERIFY (CTV). There's an anticipation that signature aggregation will play a crucial role in the utilization of CSFS, suggesting a need for these features to be accessible ahead of broader script updates like tapscript. However, concerns have been raised about the practicality of integrating advanced signature methods, such as Schnorr signatures, within the existing framework, especially considering the challenges associated with backporting these technologies. - The ongoing debate also touches upon the possible inclusion of CHECKSIGFROMSTACKADD (CSFSA), driven by the notion that it could facilitate more efficient script multisig operations by reducing the weight units required per key. Despite the advancements in signature verification methodologies like MuSig2 and FROST, the argument for CSFSA rests on its potential to simplify the creation of script multisigs, thereby enhancing their accessibility and reducing error rates. - Throughout these discussions, the Bitcoin developer community exhibits a preference for minimalism and rigorous scrutiny in protocol changes. There's a clear emphasis on evaluating each proposed modification for its tangible benefits against the backdrop of security, stability, and complexity considerations. This collective approach reflects an overarching principle in cryptocurrency development: the pursuit of innovation must be balanced with the imperative to safeguard the network's integrity and reliability. - 2024-11-23T19:45:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_ColliderScript-Covenants-in-Bitcoin-via-160-bit-hash-collisions.xml b/static/bitcoin-dev/Nov_2024/combined_ColliderScript-Covenants-in-Bitcoin-via-160-bit-hash-collisions.xml index eba50d6483..46dd618ce6 100644 --- a/static/bitcoin-dev/Nov_2024/combined_ColliderScript-Covenants-in-Bitcoin-via-160-bit-hash-collisions.xml +++ b/static/bitcoin-dev/Nov_2024/combined_ColliderScript-Covenants-in-Bitcoin-via-160-bit-hash-collisions.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - ColliderScript: Covenants in Bitcoin via 160-bit hash collisions - 2024-11-28T02:33:39.286931+00:00 - - Ethan Heilman 2024-11-27 22:37:00+00:00 - - - Antoine Riard 2024-11-25 03:42:00+00:00 - - - Ethan Heilman 2024-11-13 22:06:00+00:00 - - - Antoine Riard 2024-11-12 17:38:00+00:00 - - - Ethan Heilman 2024-11-07 17:44:00+00:00 - + 2025-09-26T14:39:37.613701+00:00 + python-feedgen + + + ColliderScript: Covenants in Bitcoin via 160-bit hash collisions Ethan Heilman + 2024-11-07T17:44:00.000Z + + + Antoine Riard + 2024-11-12T17:38:00.000Z + + + Ethan Heilman + 2024-11-13T22:06:00.000Z + + + Antoine Riard + 2024-11-25T03:42:00.000Z + + + Ethan Heilman + 2024-11-27T22:37:00.000Z + + - python-feedgen + 2 Combined summary - ColliderScript: Covenants in Bitcoin via 160-bit hash collisions - 2024-11-28T02:33:39.287011+00:00 + 2025-09-26T14:39:37.614453+00:00 + 2024-11-27T22:37:00+00:00 The recent discussions within the Bitcoin Development Mailing List have shed light on several advanced cryptographic methods aimed at enhancing the security and functionality of Bitcoin transactions. A key focus has been on the method for proving the equivalence of y1 and y2 values in transaction scripts, a technique that underscores the importance of cryptographic soundness without relying on assumptions. This method relies on the consistency of witness stack elements (w,t) across both small and large script interpretations, highlighting a deterministic approach to transaction verification that is central to maintaining the blockchain's integrity. - Further scrutiny reveals the application of this method in the context of multi-party colliderscript-based vault protocols, emphasizing the need for all participants to verify transaction equivalence prior to engagement. This pre-verification process serves as a critical safeguard against potential security breaches. The discussion also delves into the operational specifics, questioning the necessity of duplicating certain variables in the scripting process and scrutinizing the role and definition of parameters within Bitcoin equivalence tester sets. - Another aspect of the conversation addresses the concept of transaction grinding and its implications for transaction security. Through a detailed explanation, it becomes evident that grinding plays a crucial role in ensuring the equality of s1 and s2 values within a transaction, thereby guaranteeing that the outputs from both large and small scripts remain identical despite different encodings. This deterministic property of the dGen functions is highlighted as pivotal for achieving the desired modifications through grinding, with an emphasis on the significance of randomness in thwarting potential attacks by ensuring transaction security. - -In addition to these technical discussions, the mailing list also introduces a novel approach towards cryptographic verification in Bitcoin transactions, employing an equivalence check mechanism between two algorithm sets. This innovative method utilizes traditional signature validation processes alongside a "signature defragmentation" technique, aiming to maintain the integrity of signature compositions. The methodology seeks to balance complexity and practicality within the scripting limitations of Bitcoin, sparking further dialogue on security models and potential improvements to enhance protocol robustness. - +In addition to these technical discussions, the mailing list also introduces a novel approach towards cryptographic verification in Bitcoin transactions, employing an equivalence check mechanism between two algorithm sets. This innovative method utilizes traditional signature validation processes alongside a "signature defragmentation" technique, aiming to maintain the integrity of signature compositions. The methodology seeks to balance complexity and practicality within the scripting limitations of Bitcoin, sparking further dialogue on security models and potential improvements to enhance protocol robustness. Lastly, the discourse covers a groundbreaking technique for creating and spending covenants in Bitcoin using Tapscript, without the need for soft forks. Despite the high computational demand associated with covenant spending, this method presents a significant advancement in enabling arbitrary computation within Bitcoin transaction data constraints. An intriguing application of Tapscript for Lamport signatures is discussed, showcasing the potential of this technique to prepare Bitcoin transactions for quantum-resistant security measures. This recent publication represents a substantial contribution to the field, exploring the limits of Bitcoin's scripting capabilities and offering a glimpse into future developments in blockchain technology. For those interested in a deeper dive into the methodologies and their implications for Bitcoin, the full paper is available at [colliderscript.co/colliderscript.pdf](https://colliderscript.co/colliderscript.pdf). - 2024-11-27T22:37:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_Covenants-Support-Bitcoin-Wiki.xml b/static/bitcoin-dev/Nov_2024/combined_Covenants-Support-Bitcoin-Wiki.xml index a761f300a4..e28436a031 100644 --- a/static/bitcoin-dev/Nov_2024/combined_Covenants-Support-Bitcoin-Wiki.xml +++ b/static/bitcoin-dev/Nov_2024/combined_Covenants-Support-Bitcoin-Wiki.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Covenants Support - Bitcoin Wiki - 2024-12-12T02:41:37.131461+00:00 - - Brandon Black 2024-12-11 15:11:00+00:00 - - - Anthony Towns 2024-12-11 13:28:00+00:00 - - - Brandon Black 2024-12-09 20:45:00+00:00 - - - Anthony Towns 2024-12-09 20:13:00+00:00 - - - Yuval Kogman 2024-12-07 01:42:00+00:00 - - - /dev /fd 2024-12-07 00:29:00+00:00 - - - Jonas Nick 2024-12-06 21:45:00+00:00 - - - /dev /fd 2024-11-29 14:08:00+00:00 - + 2025-09-26T14:39:48.214978+00:00 + python-feedgen + + + Covenants Support - Bitcoin Wiki /dev /fd0 + 2024-11-29T14:08:00.000Z + + + Jonas Nick + 2024-12-06T21:45:00.000Z + + + /dev /fd0 + 2024-12-07T00:29:00.000Z + + + Yuval Kogman + 2024-12-07T01:42:00.000Z + + + Anthony Towns + 2024-12-09T20:13:00.000Z + + + Brandon Black + 2024-12-09T20:45:00.000Z + + + Anthony Towns + 2024-12-11T13:28:00.000Z + + + Brandon Black + 2024-12-11T15:11:00.000Z + + @@ -35,21 +46,17 @@ - python-feedgen + 2 Combined summary - Covenants Support - Bitcoin Wiki - 2024-12-12T02:41:37.131531+00:00 + 2025-09-26T14:39:48.216058+00:00 + 2024-12-11T15:11:00+00:00 The email exchange primarily revolves around the clarification and critique of a misunderstood proposal regarding example scripts for Lightning Symmetry involving hypothetical opcodes not yet implemented, specifically OP_VAULT. Brandon, in his correspondence, emphasizes that his intention was to explore theoretical possibilities rather than present production-ready solutions. He points out the importance of understanding the context and the exploratory nature of such proposals before critiquing them. This highlights an ongoing dialogue within the Bitcoin Development Mailing List about the processes and standards for proposing, testing, and discussing new features or changes to the Bitcoin protocol. - -Brandon’s response to AJ underscores a broader issue within the Bitcoin developer community concerning the methodology of achieving consensus for proposals and the seriousness with which proposals are treated. He suggests that for a more effective consensus, it would be beneficial to ensure all objections or concerns have been addressed, aiming for unanimous agreement or at least a rough consensus when perfect agreement isn't possible. Furthermore, Brandon criticizes the careless publicizing of projects like "lnhance" without thorough testing, pointing out the necessity for proposals to undergo rigorous validation to avoid misleading the community. - +Brandon’s response to AJ underscores a broader issue within the Bitcoin developer community concerning the methodology of achieving consensus for proposals and the seriousness with which proposals are treated. He suggests that for a more effective consensus, it would be beneficial to ensure all objections or concerns have been addressed, aiming for unanimous agreement or at least a rough consensus when perfect agreement isn't possible. Furthermore, Brandon criticizes the careless publicizing of projects like "lnhance" without thorough testing, pointing out the necessity for proposals to undergo rigorous validation to avoid misleading the community. The discussion extends to the mechanisms for expressing opinions on opcode proposals within the Bitcoin developer community. Yuval Kogman outlines a nuanced system allowing developers to express their stance on proposals through seven options, emphasizing the need for a clear distinction between technical evaluation and perceived community support. This system aims to accommodate a wide range of opinions and encourages transparency by enabling contributors to link their rationale behind their opinions. The approach reflects an acknowledgment of the diverse perspectives within the community and the complexity of accurately gauging both technical merit and community backing. - An initiative to gather Bitcoin developers' opinions on various covenant proposals through a draft Bitcoin wiki page is introduced, aiming to facilitate consensus building. The wiki page serves as a platform for developers to list relevant opcodes, share insights, and contribute to the discussion on proposals like OP_CTV, which is noted for its potential benefits for implementations such as coinjoin. This initiative demonstrates a collective effort toward refining and agreeing upon proposals that could enhance the Bitcoin protocol. - Overall, these communications underscore the challenges and complexities of developing and achieving consensus on new features or changes within the Bitcoin protocol. They highlight the importance of clear communication, thorough testing, and inclusive discussions in fostering a constructive and forward-moving dialogue within the Bitcoin development community. - 2024-12-11T15:11:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_Great-Consensus-Cleanup-Revival.xml b/static/bitcoin-dev/Nov_2024/combined_Great-Consensus-Cleanup-Revival.xml index 4509c7cd94..de7cf20511 100644 --- a/static/bitcoin-dev/Nov_2024/combined_Great-Consensus-Cleanup-Revival.xml +++ b/static/bitcoin-dev/Nov_2024/combined_Great-Consensus-Cleanup-Revival.xml @@ -1,107 +1,143 @@ - + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.043876+00:00 - - Antoine Riard 2024-11-28 05:18:00+00:00 - - - Murad Ali 2024-07-20 21:39:00+00:00 - - - Eric Voskuil 2024-07-20 20:29:00+00:00 - - - Antoine Riard 2024-07-18 17:39:00+00:00 - - - Eric Voskuil 2024-07-04 14:45:00+00:00 - - - Antoine Riard 2024-07-04 13:20:00+00:00 - - - Eric Voskuil 2024-07-03 23:29:00+00:00 - - - Eric Voskuil 2024-07-03 01:13:00+00:00 - - - Larry Ruane 2024-07-03 01:07:00+00:00 - - - Eric Voskuil 2024-07-02 15:57:00+00:00 - - - Antoine Poinsot 2024-07-02 10:23:00+00:00 - - - Antoine Riard 2024-07-02 02:36:00+00:00 - - - Eric Voskuil 2024-06-29 20:40:00+00:00 - - - Eric Voskuil 2024-06-29 20:29:00+00:00 - - - Antoine Riard 2024-06-29 01:53:00+00:00 - - - Eric Voskuil 2024-06-29 01:31:00+00:00 - - - Antoine Riard 2024-06-29 01:06:00+00:00 - - - Eric Voskuil 2024-06-28 17:14:00+00:00 - - - Antoine Poinsot 2024-06-27 09:35:00+00:00 - - - Eric Voskuil 2024-06-24 00:35:00+00:00 - - - Antoine Poinsot 2024-06-21 13:09:00+00:00 - - - Eric Voskuil 2024-06-18 13:02:00+00:00 - - - Antoine Poinsot 2024-06-18 08:13:00+00:00 - - - Eric Voskuil 2024-06-17 22:15:00+00:00 - - - Antoine Riard 2024-05-06 01:10:00+00:00 - - - Mark F 2024-04-30 22:20:00+00:00 - - - Antoine Riard 2024-04-25 06:08:00+00:00 - - - Antoine Poinsot 2024-04-18 10:04:00+00:00 - - - Mark F 2024-04-18 00:46:00+00:00 - - - Antoine Riard 2024-03-27 18:57:00+00:00 - - - Antoine Poinsot 2024-03-27 10:35:00+00:00 - - - Antoine Riard 2024-03-26 19:11:00+00:00 - - - Antoine Poinsot 2024-03-24 18:10:00+00:00 - + 2025-09-26T14:39:35.427485+00:00 + python-feedgen + + + Great Consensus Cleanup Revival 'Antoine Poinsot' + 2024-03-24T18:10:00.000Z + + + Antoine Riard + 2024-03-26T19:11:00.000Z + + + Antoine Poinsot' + 2024-03-27T10:35:00.000Z + + + Antoine Riard + 2024-03-27T18:57:00.000Z + + + Mark F + 2024-04-18T00:46:00.000Z + + + Antoine Poinsot' + 2024-04-18T10:04:00.000Z + + + Antoine Riard + 2024-04-25T06:08:00.000Z + + + Mark F + 2024-04-30T22:20:00.000Z + + + Antoine Riard + 2024-05-06T01:10:00.000Z + + + Eric Voskuil + 2024-06-17T22:15:00.000Z + + + Antoine Poinsot' + 2024-06-18T08:13:00.000Z + + + Eric Voskuil + 2024-06-18T13:02:00.000Z + + + Antoine Poinsot' + 2024-06-21T13:09:00.000Z + + + Eric Voskuil + 2024-06-24T00:35:00.000Z + + + Antoine Poinsot' + 2024-06-27T09:35:00.000Z + + + Eric Voskuil + 2024-06-28T17:14:00.000Z + + + Antoine Riard + 2024-06-29T01:06:00.000Z + + + Eric Voskuil + 2024-06-29T01:31:00.000Z + + + Antoine Riard + 2024-06-29T01:53:00.000Z + + + Eric Voskuil + 2024-06-29T20:29:00.000Z + + + Eric Voskuil + 2024-06-29T20:40:00.000Z + + + Antoine Riard + 2024-07-02T02:36:00.000Z + + + Antoine Poinsot' + 2024-07-02T10:23:00.000Z + + + Eric Voskuil + 2024-07-02T15:57:00.000Z + + + Larry Ruane + 2024-07-03T01:07:00.000Z + + + Eric Voskuil + 2024-07-03T01:13:00.000Z + + + Eric Voskuil + 2024-07-03T23:29:00.000Z + + + Antoine Riard + 2024-07-04T13:20:00.000Z + + + Eric Voskuil + 2024-07-04T14:45:00.000Z + + + Antoine Riard + 2024-07-18T17:39:00.000Z + + + Eric Voskuil + 2024-07-20T20:29:00.000Z + + + Murad Ali + 2024-07-20T21:39:00.000Z + + + Antoine Riard + 2024-11-28T05:18:00.000Z + + @@ -135,19 +171,16 @@ - python-feedgen + 2 Combined summary - Great Consensus Cleanup Revival - 2024-12-06T02:39:28.044085+00:00 + 2025-09-26T14:39:35.430789+00:00 + 2024-11-28T05:18:00+00:00 The conversation initiated by Antoine Poinsot sheds light on various aspects of the Bitcoin network's consensus mechanism, probing into areas that could benefit from improvement and adjustment. Poinsot zeroes in on concerns like the prolonged block validation times, which pose a threat to the network's overall efficacy and security framework. In response to this, he acknowledges existing solutions but proposes a supplementary strategy that caps the size of legacy transactions, aiming to bolster safety measures and ensure quicker validation processes. - Another significant point of discussion is the timewarp bug, which Poinsot indicates has not received the level of concern it rightfully demands. He emphasizes the critical need for addressing this flaw to safeguard the network’s stability. Moreover, the debate ventures into ensuring coinbase transaction uniqueness as a measure to circumvent the requirement for BIP30 validations beyond a specific block height, suggesting a potential pathway to streamline transaction verification while enhancing the network's security posture. - A nuanced proposal is introduced regarding the handling of transactions based on their sizes. Poinsot suggests maintaining the validity of transactions under 64 bytes while advocating for the invalidation of those exactly at this size threshold. This approach hints at a precise methodology aimed at refining transaction processing without imposing broad restrictions on transaction sizes. - The dialogue further extends an invitation to the community for additional insights, challenging others to identify possible disagreements, overlooked facets, or enhancements to the presented proposals. This initiative underscores a commitment to collaborative progress, aiming to cultivate a constructive forum for discussion that could lead to substantial improvements within the Bitcoin consensus mechanism. Through this exchange, Poinsot not only highlights key areas of concern but also catalyzes a broader dialogue aimed at fortifying the network against potential vulnerabilities and inefficiencies. - 2024-11-28T05:18:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_Multi-byte-opcodes.xml b/static/bitcoin-dev/Nov_2024/combined_Multi-byte-opcodes.xml index a22017a666..ea92ec5992 100644 --- a/static/bitcoin-dev/Nov_2024/combined_Multi-byte-opcodes.xml +++ b/static/bitcoin-dev/Nov_2024/combined_Multi-byte-opcodes.xml @@ -1,45 +1,51 @@ - + 2 Combined summary - Multi-byte opcodes - 2024-11-20T02:26:15.329201+00:00 - - Brandon Black 2024-11-19 19:35:00+00:00 - - - moonsettler 2024-11-19 16:38:00+00:00 - - - Ethan Heilman 2024-11-18 18:54:00+00:00 - - - Brandon Black 2024-11-18 17:15:00+00:00 - - - Garlo Nicon 2024-11-18 15:10:00+00:00 - - - Weikeng Chen 2024-11-16 00:45:00+00:00 - + 2025-09-26T14:39:43.951139+00:00 + python-feedgen + + + Multi-byte opcodes Weikeng Chen + 2024-11-16T00:45:00.000Z + + + Garlo Nicon + 2024-11-18T15:10:00.000Z + + + Brandon Black + 2024-11-18T17:15:00.000Z + + + Ethan Heilman + 2024-11-18T18:54:00.000Z + + + moonsettler' + 2024-11-19T16:38:00.000Z + + + Brandon Black + 2024-11-19T19:35:00.000Z + + - python-feedgen + 2 Combined summary - Multi-byte opcodes - 2024-11-20T02:26:15.329261+00:00 + 2025-09-26T14:39:43.952004+00:00 + 2024-11-19T19:35:00+00:00 In recent exchanges on the Bitcoin Development Mailing List, a series of proposals and insights regarding the development of Bitcoin script functionalities were discussed, focusing on enhancing flexibility and capability without compromising the blockchain's efficiency or existing operations. One innovative idea proposed involves the integration of opcode contexts through the script version, which would allow for a dynamic mapping from opcode numbers to their corresponding instructions. This mechanism is poised to significantly expand the scripting language of Bitcoin by enabling the inclusion of potentially an infinite number of new instructions. The proposal emphasizes the minimal overhead associated with changing contexts within a script, which could dramatically increase script complexity and execution capabilities without overloading the blockchain with excessive data. - Additionally, discussions highlighted the concept of utilizing opcode families that can adapt their behavior based on augmented flags. This approach is exemplified in opcodes like OP_CHECKSIG*, and extends to proposed opcodes such as OP_CHECKTEMPLATEVERIFY (CTV) and OP_CHECKSIGFROMSTACKVERIFY (CSFSV), allowing for a more nuanced specification of opcode behavior while maintaining efficiency in terms of data length and resource use. The flexibility offered by specifying varying lengths for these opcodes underscores an efficient utilization of the blockchain's space and resources, hinting at broader applications and optimizations within Bitcoin's scripting environment. - The conversation also revisited the historical context of operation codes in Bitcoin’s development, including the addition of new opcodes post-Taproot, such as OP_CHECKSIGADD, without removing existing ones. This reflects a forward-looking approach to expanding Bitcoin's functionality while preserving backward compatibility. The discussion sheds light on Satoshi Nakamoto's early contributions to operation codes and how the community continues to explore the potential for reintroducing or evolving these codes within the network's current framework. Such deliberations illustrate the depth of technical expertise within the Bitcoin community and its commitment to thoughtful, consensus-driven development. - A novel solution addressing the concern around depleting the finite supply of NOPs (No Operation codes) through the introduction of multi-byte opcodes was also proposed. This system, potentially named OP_OP, would conserve NOPs by interpreting subsequent bytes as new opcodes, offering a flexible extension method for introducing specific functionalities that are not covered by existing opcodes. The proposal considers the balance between structured rules for this new system and unrestricted flexibility, alongside the default behavior for unenabled multi-byte opcodes to ensure operational continuity. This idea reflects a strategic pivot towards enhancing opcode functionality in a sustainable manner, inviting further discussion and feedback within the community. For those interested in deeper engagement or contributing to this dialogue, the original thread on the Bitcoin Development Mailing List provides a comprehensive platform for collaboration, accessible [here](https://groups.google.com/g/bitcoindev/c/usHmnXDuJQc/m/hhtvAjSdCgAJ). - 2024-11-19T19:35:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml b/static/bitcoin-dev/Nov_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml index fa98b6b549..54f2a13806 100644 --- a/static/bitcoin-dev/Nov_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml +++ b/static/bitcoin-dev/Nov_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) - 2024-11-18T02:30:36.698421+00:00 - - Ethan Heilman 2024-11-17 21:59:00+00:00 - - - Ethan Heilman 2024-11-16 14:55:00+00:00 - - - Xiaohui Liu 2024-11-15 21:54:00+00:00 - - - Garlo Nicon 2024-10-25 09:58:00+00:00 - - - Vicky 2024-10-25 00:20:00+00:00 - - - Antoine Riard 2024-05-11 02:53:00+00:00 - - - Andrew Poelstra 2024-05-09 12:46:00+00:00 - - - Ben Carman 2024-05-09 00:31:00+00:00 - - - Ethan Heilman 2024-05-07 16:05:00+00:00 - - - Andrew Poelstra 2024-05-07 14:34:00+00:00 - - - David A. Harding 2024-05-07 04:11:00+00:00 - - - Antoine Riard 2024-05-07 00:55:00+00:00 - - - Andrew Poelstra 2024-05-06 19:06:00+00:00 - - - David A. Harding 2024-05-06 18:56:00+00:00 - - - Andrew Poelstra 2024-05-06 16:48:00+00:00 - - - David A. Harding 2024-05-06 07:39:00+00:00 - - - Ethan Heilman 2024-05-01 20:02:00+00:00 - - - Antoine Riard 2024-05-01 03:46:00+00:00 - - - Ethan Heilman 2024-04-30 20:43:00+00:00 - - - Andrew Poelstra 2024-04-30 14:21:00+00:00 - - - Ethan Heilman 2024-04-30 13:25:00+00:00 - - - Matthew Zipkin 2024-04-30 12:32:00+00:00 - - - Ethan Heilman 2024-04-29 00:30:00+00:00 - + 2025-09-26T14:39:52.508009+00:00 + python-feedgen + + + Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) Ethan Heilman + 2024-04-29T00:30:00.000Z + + + Matthew Zipkin + 2024-04-30T12:32:00.000Z + + + Ethan Heilman + 2024-04-30T13:25:00.000Z + + + Andrew Poelstra + 2024-04-30T14:21:00.000Z + + + Ethan Heilman + 2024-04-30T20:43:00.000Z + + + Antoine Riard + 2024-05-01T03:46:00.000Z + + + Ethan Heilman + 2024-05-01T20:02:00.000Z + + + David A. Harding + 2024-05-06T07:39:00.000Z + + + Andrew Poelstra + 2024-05-06T16:48:00.000Z + + + David A. Harding + 2024-05-06T18:56:00.000Z + + + Andrew Poelstra + 2024-05-06T19:06:00.000Z + + + Antoine Riard + 2024-05-07T00:55:00.000Z + + + David A. Harding + 2024-05-07T04:11:00.000Z + + + Andrew Poelstra + 2024-05-07T14:34:00.000Z + + + Ethan Heilman + 2024-05-07T16:05:00.000Z + + + Ben Carman + 2024-05-09T00:31:00.000Z + + + Andrew Poelstra + 2024-05-09T12:46:00.000Z + + + Antoine Riard + 2024-05-11T02:53:00.000Z + + + Vicky + 2024-10-25T00:20:00.000Z + + + Garlo Nicon + 2024-10-25T09:58:00.000Z + + + Xiaohui Liu + 2024-11-15T21:54:00.000Z + + + Ethan Heilman + 2024-11-16T14:55:00.000Z + + + Ethan Heilman + 2024-11-17T21:59:00.000Z + + @@ -95,35 +121,24 @@ - python-feedgen + 2 Combined summary - Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) - 2024-11-18T02:30:36.698570+00:00 + 2025-09-26T14:39:52.510678+00:00 + 2024-11-17T21:59:00+00:00 The conversation explores innovative approaches to blockchain technology, particularly focusing on the implementation of covenants and introspection within Bitcoin's blockchain without necessitating OP_CAT. The dialogue delves into the limitations and potentials of utilizing opcodes like OP_SIZE for creating sophisticated contracts or covenants. It outlines a theoretical framework where an unlimited opcode set could enable small scripts capable of enforcing rules or conditions by introspecting the entire blockchain, potentially incorporating snarks to maintain script size while enhancing privacy and security through cryptographic methods. - The discussion also touches upon the complexities of implementing covenants in Bitcoin's scripting language, highlighting the technical challenges involved in parsing transaction fields without OP_CAT. This inquiry underscores the foundational aspects of Bitcoin's programmability and security features, emphasizing the need for developers to understand these mechanisms thoroughly. - Further, the conversation shifts to examining the security implications of using multiple private keys for generating specific addresses, illustrating the computational difficulty associated with this process through examples of one-byte and two-byte grinds. This illustration serves to highlight the nuanced strategy in multisignature setups within the Bitcoin protocol, showcasing how developers can leverage cryptographic signatures to balance accessibility and security according to the needs of a transaction or wallet. - In another part of the conversation, the focus shifts to the examination of ECDSA signature size distribution within Bitcoin's cryptographic framework, discussing the practicality of enhancing transaction security through signature batching. Additionally, Adam's proposal on Proof-of-Work locked outputs is explored as a more feasible approach than employing full Lamport signature schemes, further probing the security model and practical applications of these cryptographic enhancements in light of Bitcoin's operability constraints. - -Antoine's email to Ethan provides an in-depth analysis of cryptographic techniques related to transaction security and flexibility within blockchain technologies. It discusses vulnerabilities and innovations in Lamport and ECDSA/Schnorr signatures, emphasizing the potential risks and solutions to secure transactions against quantum computing threats. The concept of a "faux-ctv" variant leveraging BIP118 for no-input signatures is introduced, offering insights into the evolving landscape of blockchain security and transaction integrity. - +Antoine's email to Ethan provides an in-depth analysis of cryptographic techniques related to transaction security and flexibility within blockchain technologies. It discusses vulnerabilities and innovations in Lamport and ECDSA/Schnorr signatures, emphasizing the potential risks and solutions to secure transactions against quantum computing threats. The concept of a "faux-ctv" variant leveraging BIP118 for no-input signatures is introduced, offering insights into the evolving landscape of blockchain security and transaction integrity. Andrew Poelstra's insight into transaction signing processes within blockchain highlights the importance of sighash flags in ensuring transaction integrity, providing a deeper understanding of blockchain technology's technical nuances. His affiliation with Blockstream Research and contributions to the field are acknowledged, inviting further exploration of his work for those interested in blockchain advancements. - The dialogue between Ethan Heilman and David A. Harding sheds light on novel techniques to implement covenants in Bitcoin's scripting language, tapscript, despite opcode limitations. This conversation underlines ongoing explorations into expanding Bitcoin's scripting capabilities, reflecting broader interests in enhancing smart contract provisions on the platform. - A nuanced discussion among blockchain enthusiasts addresses several key points regarding fee bumping, signature validation, and quantum computing vulnerabilities in Bitcoin transactions. This exchange encapsulates a deep understanding of managing transaction fees, ensuring signature security, and preparing for technological threats to the cryptocurrency protocol. - Andrew Poelstra's method to bridge gaps between pre-Taproot and post-Taproot transaction outputs using anti-equivocation schemes exemplifies innovative solutions to enhance Bitcoin's security measures without relying on newer Schnorr signatures. This proposal underscores creative approaches to developing blockchain technology within the constraints of Bitcoin's scripting language. - The discussion between Antoine Riard and Andrew Poelstra, involving Matthew Zipkin and Ethan Heilman, revolves around the intricacies of integrating ECDSA and Schnorr signatures within Tapscript. This technical exploration reveals the complexity and potential confusion surrounding cryptographic and scripting innovations, reflecting efforts to evolve Bitcoin's scripting abilities for increased transaction verification and execution flexibility. - The conversation highlights a potential vulnerability in using Lamport public keys for blockchain transactions, pointing out the susceptibility to DoS attacks and issues related to signature algorithms like ECDSA. Concerns about the robustness of such schemes against attackers with considerable computational resources are raised, alongside discussions on improving the overall resilience of the system through technical adjustments. - This comprehensive summary encapsulates the multifaceted discussions on cryptographic techniques, security concerns, and innovative approaches to enhancing Bitcoin's functionality and security. The conversations reflect the collaborative effort and ongoing research within the blockchain community to address technical challenges and expand the capabilities of cryptocurrency platforms. - 2024-11-17T21:59:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_Slashing-covenants.xml b/static/bitcoin-dev/Nov_2024/combined_Slashing-covenants.xml index cefe4b9a42..7c3027e26f 100644 --- a/static/bitcoin-dev/Nov_2024/combined_Slashing-covenants.xml +++ b/static/bitcoin-dev/Nov_2024/combined_Slashing-covenants.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - Slashing covenants - 2025-03-25T02:33:51.915511+00:00 - - Ethan Heilman 2025-03-24 21:51:00+00:00 - - - Hunter Beast 2025-03-24 13:41:00+00:00 - - - Ethan Heilman 2024-11-24 21:13:00+00:00 - + 2025-09-26T14:39:39.726858+00:00 + python-feedgen + + + Slashing covenants Ethan Heilman + 2024-11-24T21:13:00.000Z + + + Hunter Beast + 2025-03-24T13:41:00.000Z + + + Ethan Heilman + 2025-03-24T21:51:00.000Z + + - python-feedgen + 2 Combined summary - Slashing covenants - 2025-03-25T02:33:51.915555+00:00 + 2025-09-26T14:39:39.727509+00:00 + 2025-03-24T21:51:00+00:00 Slashing covenants offer an innovative enforcement mechanism for Bitcoin transactions, diverging from traditional methods that prevent the spending of outputs against covenant conditions. Instead, this protocol allows transactions to proceed but imposes financial penalties on violators who breach established rules, marking a less secure but more efficient alternative than employing specific opcodes for direct prevention. This approach leverages existing Bitcoin script capabilities and Lamport signatures to verify authenticity without necessitating complex cryptographic operations within the script. It operates on a two-part script system: the first part ensures covenant adherence if the spending signature matches its encoded counterpart, and the second part punishes discrepancies by enabling anyone to slash the violator's funds through costly transactions. - The discussion highlights the potential benefits of slashing covenants over traditional enforcement methods like BitVM, emphasizing their efficiency, compatibility with current infrastructure, and absence of new cryptographic assumptions. While initially compared to BitVM, it was clarified that BitVM does not utilize this precise strategy. The mechanism behind slashing covenants focuses on proving the identity of two signatures—one verified by Bitcoin’s CHECKSIGVERIFY and another through a simplified script—without direct comparison. This is seen as a significant innovation that maintains security through cryptoeconomic incentives, reminiscent of how bitcoin mining operates. Despite its reliance on financial disincentives rather than outright prevention, the method is deemed sufficient for maintaining transaction integrity within the Bitcoin network. - Furthermore, while the concept is tailored for Bitcoin, it is noted that implementation might be simpler on platforms like Ethereum due to their flexible nature. The conversation also opens up possibilities for expanding this model to support dynamic cosigner groups with advanced cryptographic proofs, potentially enhancing the resilience and applicability of covenants in blockchain systems. This exploration into slashing covenants exemplifies the ongoing search for balance between security and practicality in cryptocurrency protocols, highlighting both the challenges and innovations arising from the unique constraints of decentralized networks. - 2025-03-24T21:51:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2024/combined_Un-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml b/static/bitcoin-dev/Nov_2024/combined_Un-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml index 0efa213c7a..3c7e6ff55c 100644 --- a/static/bitcoin-dev/Nov_2024/combined_Un-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml +++ b/static/bitcoin-dev/Nov_2024/combined_Un-FE-d-Covenants-Char-ting-a-new-path-to-Emulated-Covenants-via-BitVM-Integrity-Checks.xml @@ -1,29 +1,34 @@ - + 2 Combined summary - Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks - 2024-12-01T02:54:58.537936+00:00 - - jeremy 2024-11-30 18:29:00+00:00 - - - Erik Aronesty 2024-11-30 17:19:00+00:00 - - - jeremy 2024-11-27 03:05:00+00:00 - + 2025-09-26T14:39:54.622704+00:00 + python-feedgen + + + Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks jeremy + 2024-11-27T03:05:00.000Z + + + Erik Aronesty + 2024-11-30T17:19:00.000Z + + + jeremy + 2024-11-30T18:29:00.000Z + + - python-feedgen + 2 Combined summary - Un-FE’d Covenants: Char-ting a new path to Emulated Covenants via BitVM Integrity Checks - 2024-12-01T02:54:58.537987+00:00 + 2025-09-26T14:39:54.623282+00:00 + 2024-11-30T18:29:00+00:00 The email introduces a novel methodology for the implementation of Bitcoin covenants that cleverly circumvents the need for alterations to the Bitcoin protocol itself. This is achieved through an inventive use of covenant emulators alongside signing servers, setting it apart from prior methods aimed at simulating covenants. A pivotal aspect of this strategy is the imposition of a requirement for oracle signers to place bonds with BitVM auditors. These bonds are subjected to a risk of forfeiture under a specific BITVM style fraud proof regime, where any act of authorizing transactions in contravention of the established covenant rules could result in the loss of these funds. This serves as a deterrent against violations of covenant conditions by introducing a financial repercussion for non-compliance. - This approach is detailed further in a paper that elucidates the framework necessary for enforcing Bitcoin covenants without necessitating direct modifications to the blockchain's underlying protocol. The paper presents a comprehensive exploration of the mechanics behind this innovative solution, offering valuable insights into its potential application within the Bitcoin ecosystem. Interested parties can delve into the specifics of this proposal by accessing the document provided online, which promises an extensive analysis of the operational aspects of the proposed system. The discussed mechanism highlights a significant advancement in the realm of Bitcoin technology, proposing a viable solution for the implementation of covenants that preserves the integrity of the existing protocol. The full details of this approach, including theoretical underpinnings and practical implications, are available in the paper accessible via [this link](https://rubin.io/bitcoin/2024/11/26/unfed-covenants/), inviting further scrutiny and discussion among Bitcoin developers and enthusiasts alike. - 2024-11-30T18:29:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml b/static/bitcoin-dev/Oct_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml index 2f15685578..98c36b58d4 100644 --- a/static/bitcoin-dev/Oct_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml +++ b/static/bitcoin-dev/Oct_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml @@ -1,242 +1,19 @@ - + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger - 2023-08-02T07:48:23.736188+00:00 - - angus 2022-12-05 12:21:44+00:00 - - - Daniel Lipshitz 2022-12-03 14:06:11+00:00 - - - Daniel Lipshitz 2022-12-03 14:03:58+00:00 - - - Daniel Lipshitz 2022-12-03 13:17:16+00:00 - - - Peter Todd 2022-12-03 12:12:02+00:00 - - - Daniel Lipshitz 2022-12-03 11:51:19+00:00 - - - Daniel Lipshitz 2022-12-03 11:01:16+00:00 - - - Peter Todd 2022-12-03 08:50:13+00:00 - - - Daniel Lipshitz 2022-12-02 07:06:26+00:00 - - - Daniel Lipshitz 2022-12-02 06:59:01+00:00 - - - Daniel Lipshitz 2022-12-02 06:34:07+00:00 - - - Peter Todd 2022-12-02 04:30:28+00:00 - - - Antoine Riard 2022-12-02 01:52:46+00:00 - - - Erik Aronesty 2022-12-01 22:03:55+00:00 - - - Daniel Lipshitz 2022-12-01 12:27:16+00:00 - - - ZmnSCPxj 2022-11-10 09:35:18+00:00 - - - ArmchairCryptologist 2022-11-09 13:19:28+00:00 - - - AdamISZ 2022-11-02 15:04:58+00:00 - - - Sergej Kotliar 2022-10-24 07:55:59+00:00 - - - Sergej Kotliar 2022-10-24 07:45:13+00:00 - - - alicexbt 2022-10-23 20:51:16+00:00 - - - David A. Harding 2022-10-23 19:20:41+00:00 - - - Peter Todd 2022-10-21 19:43:33+00:00 - - - Peter Todd 2022-10-21 19:35:24+00:00 - - - Peter Todd 2022-10-21 19:33:46+00:00 - - - Greg Sanders 2022-10-21 14:47:50+00:00 - - - Sergej Kotliar 2022-10-21 14:19:32+00:00 - - - Greg Sanders 2022-10-21 14:01:01+00:00 - - - Sergej Kotliar 2022-10-21 12:02:24+00:00 - - - Sergej Kotliar 2022-10-21 11:56:51+00:00 - - - Sergej Kotliar 2022-10-21 09:34:17+00:00 - - - Antoine Riard 2022-10-21 01:04:24+00:00 - - - Peter Todd 2022-10-20 23:18:16+00:00 - - - Peter Todd 2022-10-20 22:13:15+00:00 - - - Peter Todd 2022-10-20 22:08:17+00:00 - - - Greg Sanders 2022-10-20 21:07:07+00:00 - - - David A. Harding 2022-10-20 21:05:36+00:00 - - - Anthony Towns 2022-10-20 19:58:41+00:00 - - - Sergej Kotliar 2022-10-20 14:17:23+00:00 - - - Ruben Somsen 2022-10-20 14:14:14+00:00 - - - Sergej Kotliar 2022-10-20 14:11:48+00:00 - - - Sergej Kotliar 2022-10-20 12:37:53+00:00 - - - Anthony Towns 2022-10-20 07:22:34+00:00 - - - Peter Todd 2022-10-20 04:05:33+00:00 - - - Antoine Riard 2022-10-20 01:37:25+00:00 - - - Greg Sanders 2022-10-19 16:08:19+00:00 - - - Sergej Kotliar 2022-10-19 16:04:30+00:00 - - - Greg Sanders 2022-10-19 15:51:41+00:00 - - - Jeremy Rubin 2022-10-19 15:43:28+00:00 - - - Erik Aronesty 2022-10-19 14:45:44+00:00 - - - Sergej Kotliar 2022-10-19 14:29:57+00:00 - - - alicexbt 2022-10-19 03:17:51+00:00 - - - Antoine Riard 2022-10-19 03:01:12+00:00 - - - Anthony Towns 2022-10-18 07:00:45+00:00 - - - Antoine Riard 2022-10-17 22:14:52+00:00 - - - Antoine Riard 2022-10-17 21:41:48+00:00 - - - Antoine Riard 2022-10-17 20:31:50+00:00 - - - Greg Sanders 2022-10-17 14:25:33+00:00 - - - Anthony Towns 2022-10-16 08:08:49+00:00 - - - John Carvalho 2022-10-15 04:20:55+00:00 - - - John Carvalho 2022-10-15 04:08:15+00:00 - - - Erik Aronesty 2022-10-14 16:28:49+00:00 - - - Peter Todd 2022-10-14 15:04:56+00:00 - - - Peter Todd 2022-10-14 15:02:25+00:00 - - - John Carvalho 2022-10-14 10:03:21+00:00 - - - alicexbt 2022-10-14 02:44:04+00:00 - - - linuxfoundation.cndm1 at dralias.com 2022-10-13 16:07:19+00:00 - - - Anthony Towns 2022-10-13 04:35:22+00:00 - - - Dario Sneidermanis 2022-10-12 21:44:13+00:00 - - - Pieter Wuille 2022-10-12 16:11:05+00:00 - - - Anthony Towns 2022-10-12 05:42:14+00:00 - - - Pieter Wuille 2022-10-11 16:18:10+00:00 - - - alicexbt 2022-10-08 20:47:52+00:00 - - - Dario Sneidermanis 2022-10-07 21:37:38+00:00 - - - Luke Dashjr 2022-10-07 20:56:21+00:00 - - - Greg Sanders 2022-10-07 17:28:28+00:00 - - - David A. Harding 2022-10-07 17:21:29+00:00 - - - Dario Sneidermanis 2022-10-07 16:20:49+00:00 - + 2025-09-26T14:20:47.368884+00:00 + python-feedgen + + + [bitcoin-dev] Fwd: " Antoine Riard + 2022-12-02T22:35:00.000Z + + + Peter Todd + 2022-12-06T05:03:00.000Z + + @@ -315,13 +92,13 @@ - python-feedgen + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger - 2023-08-02T07:48:23.737154+00:00 + 2025-09-26T14:20:47.369425+00:00 - GAP600, a company specializing in processing cryptocurrency transactions, has processed approximately 15 million transactions with a total value of $2.3 billion USD from January to November 2022. The majority of their clients are payment processors and liquidity providers. However, the CEO of GAP600, Daniel Lipshitz, expressed concern over the potential adoption of full Replace-by-Fee (RBF) as default, as it would make zero-conf acceptance difficult. This could significantly impact GAP600's market share, as they currently process around 1.5 million transactions per month.GAP600 guarantees zero confirmed Bitcoin and other crypto transactions, allowing their customers to recognize zero-conf deposits. They reimburse clients if a transaction they confirmed gets double-spent. However, if full RBF were to become dominant, zero-conf acceptance would be affected. It is unclear how many of GAP600's processed transactions relied on their unconfirmed transaction tools.The email exchange also discussed the services provided by GAP600 to Shapeshift, one of their former clients. Shapeshift no longer uses GAP600's services but occasionally asks for fee recommendations. The conversation highlights the significance of zero-conf transactions in the cryptocurrency industry and raises questions about the implementation and reliance on unconfirmed transaction tools.The discussion on the bitcoin-dev mailing list explores the issue of full RBF and its impact on Bitcoin transactions. There are concerns about the degradation of user experience for 0-conf deposits and the risk of exchange rate changes between fiat and BTC. Various solutions, such as using Child-Pays-for-Parent (CPFP) to lock in FX risk or making the double-spender over-pay, are proposed but have limitations.The conversation emphasizes the need for collaboration between wallet developers, merchant developers, and protocol developers to address these issues and improve the Bitcoin payment experience. Specific implementations of RBF features in various wallets are also discussed, highlighting the need for collaboration to enhance the RBF experience.The risks associated with accepting Bitcoin payments are highlighted, including the zeroconf risk and the FX risk. The conversation mentions the "American call option," where users can make low-fee transactions and wait to see if the BTCUSD rate changes before canceling and making a cheaper transaction. This could potentially abuse the system and harm merchants.Sergej Kotliar, CEO of Bitrefill, raises concerns about the default use of RBF in Bitcoin transactions. He suggests a risk-based approach to determine which payments are non-trivial to reverse, considering user experience. There is also discussion about Lightning Network adoption and the challenges of RBF as a default policy.The bitcoin-dev mailing list recently discussed the relay of full-RBF (replace-by-fee) transactions. One member stated that it is already working well, except for a few percent of hashrate that doesn't accept fullrbf replacement transactions. However, another member disagreed, emphasizing the importance of all full node users trying fullrbf. The first member explained that the relay of full-rbf transactions currently works well due to preferential rbf peering implementations. They personally run four nodes with this feature enabled and haven't seen many non-opt-in doublespends get mined. However, they have observed a few through their Alice OTS calendar, which could increase as miners adopt full-rbf.There are concerns about the gaslighting happening with the advancement of RBF, while merchants wanting to manage their own 0conf risk better is not deemed acceptable. Some argue that miners can facilitate doublespends anyway if the fees are higher. However, proponents of RBF seem to threaten the use case of on-chain Bitcoin being useful at the point-of-sale for merchants and consumers. This may lead to the creation of alternative fee mechanisms and trusted/exclusive mempools where first-seen transactions are respected.According to a tweet by Sergej Kotliar in January 2022, lightning payments account for only 4% compared to on-chain payments, which make up 32%. Bitrefill and similar providers could promote the use of lightning payments by displaying them by default and presenting on-chain payments as a fallback. It would be interesting to know if these services face any obstacles or if they disagree that lightning is an improvement over accepting unconfirmed on-chain transactions from untrusted parties.Pieter Wuille via bitcoin-dev proposed a step towards getting full RBF on the network by allowing experimentation and socializing the notion that developers believe it is time. However, there seems to be confusion about what exactly they believe it is time for. There are two possibilities: (a) deprecating the acceptance of zeroconf transactions on mainnet over the next 6, 12, or 18 months, or (b) switching mainnet mining and relay nodes to full RBF.Pieter Wuille commented on the opt-in flag for full-RBF, stating that adding the flag is a likely step towards wider adoption on the network. However, he believes that the opt-in flag 2022-12-05T12:21:44+00:00 + GAP600, a company specializing in processing cryptocurrency transactions, has processed approximately 15 million transactions with a total value of $2.3 billion USD from January to November 2022. The majority of their clients are payment processors and liquidity providers. However, the CEO of GAP600, Daniel Lipshitz, expressed concern over the potential adoption of full Replace-by-Fee (RBF) as default, as it would make zero-conf acceptance difficult. This could significantly impact GAP600's market share, as they currently process around 1.5 million transactions per month.GAP600 guarantees zero confirmed Bitcoin and other crypto transactions, allowing their customers to recognize zero-conf deposits. They reimburse clients if a transaction they confirmed gets double-spent. However, if full RBF were to become dominant, zero-conf acceptance would be affected. It is unclear how many of GAP600's processed transactions relied on their unconfirmed transaction tools.The email exchange also discussed the services provided by GAP600 to Shapeshift, one of their former clients. Shapeshift no longer uses GAP600's services but occasionally asks for fee recommendations. The conversation highlights the significance of zero-conf transactions in the cryptocurrency industry and raises questions about the implementation and reliance on unconfirmed transaction tools.The discussion on the bitcoin-dev mailing list explores the issue of full RBF and its impact on Bitcoin transactions. There are concerns about the degradation of user experience for 0-conf deposits and the risk of exchange rate changes between fiat and BTC. Various solutions, such as using Child-Pays-for-Parent (CPFP) to lock in FX risk or making the double-spender over-pay, are proposed but have limitations.The conversation emphasizes the need for collaboration between wallet developers, merchant developers, and protocol developers to address these issues and improve the Bitcoin payment experience. Specific implementations of RBF features in various wallets are also discussed, highlighting the need for collaboration to enhance the RBF experience.The risks associated with accepting Bitcoin payments are highlighted, including the zeroconf risk and the FX risk. The conversation mentions the "American call option," where users can make low-fee transactions and wait to see if the BTCUSD rate changes before canceling and making a cheaper transaction. This could potentially abuse the system and harm merchants.Sergej Kotliar, CEO of Bitrefill, raises concerns about the default use of RBF in Bitcoin transactions. He suggests a risk-based approach to determine which payments are non-trivial to reverse, considering user experience. There is also discussion about Lightning Network adoption and the challenges of RBF as a default policy.The bitcoin-dev mailing list recently discussed the relay of full-RBF (replace-by-fee) transactions. One member stated that it is already working well, except for a few percent of hashrate that doesn't accept fullrbf replacement transactions. However, another member disagreed, emphasizing the importance of all full node users trying fullrbf. The first member explained that the relay of full-rbf transactions currently works well due to preferential rbf peering implementations. They personally run four nodes with this feature enabled and haven't seen many non-opt-in doublespends get mined. However, they have observed a few through their Alice OTS calendar, which could increase as miners adopt full-rbf.There are concerns about the gaslighting happening with the advancement of RBF, while merchants wanting to manage their own 0conf risk better is not deemed acceptable. Some argue that miners can facilitate doublespends anyway if the fees are higher. However, proponents of RBF seem to threaten the use case of on-chain Bitcoin being useful at the point-of-sale for merchants and consumers. This may lead to the creation of alternative fee mechanisms and trusted/exclusive mempools where first-seen transactions are respected.According to a tweet by Sergej Kotliar in January 2022, lightning payments account for only 4% compared to on-chain payments, which make up 32%. Bitrefill and similar providers could promote the use of lightning payments by displaying them by default and presenting on-chain payments as a fallback. It would be interesting to know if these services face any obstacles or if they disagree that lightning is an improvement over accepting unconfirmed on-chain transactions from untrusted parties.Pieter Wuille via bitcoin-dev proposed a step towards getting full RBF on the network by allowing experimentation and socializing the notion that developers believe it is time. However, there seems to be confusion about what exactly they believe it is time for. There are two possibilities: (a) deprecating the acceptance of zeroconf transactions on mainnet over the next 6, 12, or 18 months, or (b) switching mainnet mining and relay nodes to full RBF.Pieter Wuille commented on the opt-in flag for full-RBF, stating that adding the flag is a likely step towards wider adoption on the network. However, he believes that the opt-in flag - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Analysis-of-full-RBF-deployment-methods.xml b/static/bitcoin-dev/Oct_2022/combined_Analysis-of-full-RBF-deployment-methods.xml index dd35859ba0..5e43159fea 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Analysis-of-full-RBF-deployment-methods.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Analysis-of-full-RBF-deployment-methods.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Analysis of full-RBF deployment methods - 2023-08-02T08:17:08.125992+00:00 - - Antoine Riard 2022-10-23 23:10:16+00:00 - - - Dario Sneidermanis 2022-10-21 21:13:41+00:00 - - - Antoine Riard 2022-10-21 01:50:30+00:00 - - - Dario Sneidermanis 2022-10-20 16:51:24+00:00 - + 2025-09-26T14:20:28.051134+00:00 + python-feedgen + + + [bitcoin-dev] Analysis of full-RBF deployment methods Dario Sneidermanis + 2022-10-20T16:51:00.000Z + + + Antoine Riard + 2022-10-21T01:50:00.000Z + + + Dario Sneidermanis + 2022-10-21T21:13:00.000Z + + + Antoine Riard + 2022-10-23T23:10:00.000Z + + - python-feedgen + 2 Combined summary - Analysis of full-RBF deployment methods - 2023-08-02T08:17:08.126952+00:00 + 2025-09-26T14:20:28.051779+00:00 - In an email exchange between Antoine Riard and Dario Sneidermanis, they discuss the risks and benefits of implementing a full-replace-by-fee (RBF) deployment on the Bitcoin network. Antoine expresses concerns about potential disruptions to contracting protocols and multi-party applications, while Dario argues that a reliable full-RBF network is necessary to prevent pinning denial-of-service attacks. They agree that option 5 in the original post would be the best approach for achieving a reliable full-RBF network without threatening zero-conf applications until the activation time.Antoine suggests that May 1st, 2023, may be too early for full-RBF deployment and proposes a timeline of 10-12 months instead. He also emphasizes the need for better communication channels between business/service operators and protocol developers to clarify functional responsibilities. However, he does not believe that it should be solely the responsibility of developers to solve every operational risk faced by Bitcoin businesses.Dario counters Antoine's argument by stating that requesting a predictable deployment timeline for a change that increases the risk for certain applications should not be seen as burdening the developers. The goal of comparing deployment methods was to alleviate some of the burden on core developers.In their email exchange, Dario thanks Antoine for his detailed analysis and acknowledges Antoine's concerns about deferring full-RBF deployment. Antoine believes that the pinning DoS vector poses a risk to contracting protocols and multi-party applications. He mentions new developments such as ln-vortex, Phoenix wallet, and LDK users planning to use dual-funded soon, which have made these use cases more tangible.To address the attack described in [0], collaborative transaction protocols require a reliable way to replace transactions. Antoine suggests that option 5 (#26323) provides the fastest path to a reliable full-RBF network without endangering zero-conf applications. He believes that both security and zero-conf applications can coexist with this approach.Antoine raises the issue of interdependency between network policy rules and business risk, questioning whether developers should be responsible for every operational risk faced by Bitcoin businesses. Dario argues that asking for a predictable deployment timeline for a change that increases risk should not be seen as burdening the developers.In a recent Bitcoin Core IRC meeting, full-RBF deployment methods were extensively discussed. Antoine argues that deferring full-RBF deployment could be risky for contracting protocols and multi-party applications affected by the pinning DoS vector. He believes it is important to exchange different perspectives on this subject. Dario presents various alternatives for the deployment method of full-RBF and suggests five deployment options with different trade-offs. The details for these options can be found on Github. Dario compares the options based on dimensions such as immediate impact on zero-conf apps, predictability of deployment date, code complexity, smooth deployment, and time to figure out the right deployment.The stakeholders have differing opinions on whether to defer or activate full-RBF deployment in the upcoming stable release of version 24.0. They consider various dimensions of analysis to make a decision, including the impact on zero-conf apps, predictability of deployment, code complexity, smooth deployment, and the time required to determine the appropriate deployment method.With the impending release of version 24.0, a decision needs to be made regarding the deployment method of full-RBF. Several alternatives have been documented, each with its own trade-offs. These options include leaving the current version as is and merging opt-out in later versions, reverting opt-in full-RBF to allow more time for planning, and committing to a later date for opt-out activation. It is noted that once fully deployed, having a configuration option to disable it could be problematic.The analysis considers various dimensions, such as the impact on zero-conf apps, predictability of deployment date, code complexity, smooth deployment, and the time needed to determine the appropriate method. The comparison provides an overview of different approaches to address these dimensions. Regarding the timeline for full-RBF activation, Muun could be ready in six months with the necessary changes, while the larger application ecosystem may require more time for understanding the impact, designing solutions, implementing them, and deploying them. A smooth deployment can be achieved by setting an activation date in the code and allowing sufficient time for relaying nodes to upgrade before activation. Assuming uniform adoption distribution, two release cycles may be enough to achieve 61% adoption. 2022-10-23T23:10:16+00:00 + In an email exchange between Antoine Riard and Dario Sneidermanis, they discuss the risks and benefits of implementing a full-replace-by-fee (RBF) deployment on the Bitcoin network. Antoine expresses concerns about potential disruptions to contracting protocols and multi-party applications, while Dario argues that a reliable full-RBF network is necessary to prevent pinning denial-of-service attacks. They agree that option 5 in the original post would be the best approach for achieving a reliable full-RBF network without threatening zero-conf applications until the activation time.Antoine suggests that May 1st, 2023, may be too early for full-RBF deployment and proposes a timeline of 10-12 months instead. He also emphasizes the need for better communication channels between business/service operators and protocol developers to clarify functional responsibilities. However, he does not believe that it should be solely the responsibility of developers to solve every operational risk faced by Bitcoin businesses.Dario counters Antoine's argument by stating that requesting a predictable deployment timeline for a change that increases the risk for certain applications should not be seen as burdening the developers. The goal of comparing deployment methods was to alleviate some of the burden on core developers.In their email exchange, Dario thanks Antoine for his detailed analysis and acknowledges Antoine's concerns about deferring full-RBF deployment. Antoine believes that the pinning DoS vector poses a risk to contracting protocols and multi-party applications. He mentions new developments such as ln-vortex, Phoenix wallet, and LDK users planning to use dual-funded soon, which have made these use cases more tangible.To address the attack described in [0], collaborative transaction protocols require a reliable way to replace transactions. Antoine suggests that option 5 (#26323) provides the fastest path to a reliable full-RBF network without endangering zero-conf applications. He believes that both security and zero-conf applications can coexist with this approach.Antoine raises the issue of interdependency between network policy rules and business risk, questioning whether developers should be responsible for every operational risk faced by Bitcoin businesses. Dario argues that asking for a predictable deployment timeline for a change that increases risk should not be seen as burdening the developers.In a recent Bitcoin Core IRC meeting, full-RBF deployment methods were extensively discussed. Antoine argues that deferring full-RBF deployment could be risky for contracting protocols and multi-party applications affected by the pinning DoS vector. He believes it is important to exchange different perspectives on this subject. Dario presents various alternatives for the deployment method of full-RBF and suggests five deployment options with different trade-offs. The details for these options can be found on Github. Dario compares the options based on dimensions such as immediate impact on zero-conf apps, predictability of deployment date, code complexity, smooth deployment, and time to figure out the right deployment.The stakeholders have differing opinions on whether to defer or activate full-RBF deployment in the upcoming stable release of version 24.0. They consider various dimensions of analysis to make a decision, including the impact on zero-conf apps, predictability of deployment, code complexity, smooth deployment, and the time required to determine the appropriate deployment method.With the impending release of version 24.0, a decision needs to be made regarding the deployment method of full-RBF. Several alternatives have been documented, each with its own trade-offs. These options include leaving the current version as is and merging opt-out in later versions, reverting opt-in full-RBF to allow more time for planning, and committing to a later date for opt-out activation. It is noted that once fully deployed, having a configuration option to disable it could be problematic.The analysis considers various dimensions, such as the impact on zero-conf apps, predictability of deployment date, code complexity, smooth deployment, and the time needed to determine the appropriate method. The comparison provides an overview of different approaches to address these dimensions. Regarding the timeline for full-RBF activation, Muun could be ready in six months with the necessary changes, while the larger application ecosystem may require more time for understanding the impact, designing solutions, implementing them, and deploying them. A smooth deployment can be achieved by setting an activation date in the code and allowing sufficient time for relaying nodes to upgrade before activation. Assuming uniform adoption distribution, two release cycles may be enough to achieve 61% adoption. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Batch-validation-of-CHECKMULTISIG-using-an-extra-hint-field.xml b/static/bitcoin-dev/Oct_2022/combined_Batch-validation-of-CHECKMULTISIG-using-an-extra-hint-field.xml index 10ee35a486..e204f457f5 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Batch-validation-of-CHECKMULTISIG-using-an-extra-hint-field.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Batch-validation-of-CHECKMULTISIG-using-an-extra-hint-field.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Batch validation of CHECKMULTISIG using an extra hint field - 2023-08-02T08:15:12.146850+00:00 - - ZmnSCPxj 2022-10-20 22:02:51+00:00 - - - Mark Friedenbach 2022-10-19 03:51:42+00:00 - + 2025-09-26T14:20:34.512188+00:00 + python-feedgen + + + [bitcoin-dev] Batch validation of CHECKMULTISIG using an extra hint field Mark Friedenbach + 2022-10-19T03:51:00.000Z + + + ZmnSCPxj + 2022-10-20T22:02:00.000Z + + - python-feedgen + 2 Combined summary - Batch validation of CHECKMULTISIG using an extra hint field - 2023-08-02T08:15:12.146850+00:00 + 2025-09-26T14:20:34.512614+00:00 - In this conversation, Mark discusses a potential optimization opportunity for the CHECKMULTISIG algorithm in Bitcoin. The idea suggests using a minimally-encoded bitmap to specify which public keys are used or skipped, instead of requiring the final parameter on the stack to be zero. This would allow for a more efficient validation process and could be beneficial for applications where interactive signing is not possible.While MuSig-like key aggregation schemes can be used for n-of-n thresholds, there are still use cases where explicit k-of-n thresholds must be used. FROST is an alternative that supports k-of-n but requires participation from all signers in the set and additional data storage by privkey owners after the setup ritual. Despite this, the proposed batch-validation friendly CHECKMULTISIG algorithm would still be useful for such applications.Satoshi unintentionally made a mistake in the original CHECKMULTISIG implementation, causing an extra item to be popped off the stack upon completion. This extra value provides a malleability vector as anyone can change the value in the signature without invalidating a transaction. In legacy scripts, NULLDUMMY is a policy rule that states this value must be zero, and this was made a consensus rule for segwit scripts.Another issue with CHECKMULTISIG is that the algorithm seemingly precludes batch validation for threshold signatures. Batch validation could enable a 2x speedup during the initial block download phase. The algorithm cannot batch validate these signatures because it doesn't know which signatures map to which pubkeys.After SegWit was released, Luke-Jr observed that this new rule was suboptimal and Satoshi's mistake gave an extra parameter to CHECKMULTISIG. It was possible to use this parameter to convey extra information to the CHECKMULTISIG algorithm and enable batch validation of threshold signatures using this opcode.The updated CHECKMULTISIG algorithm requires the final parameter on the stack to be a minimally-encoded bitmap specifying which keys are used or skipped. Before validation, it is important to ensure that for a k-of-n threshold, only k bits are set in the bitfield indicating the used pubkeys (or n-k bits set indicating the keys to skip). During validation, the associated bit in the bitfield is checked to determine if the pubkey is used. If the bitfield indicates that the pubkey is not used, it can be skipped without even attempting validation.This solution is considered a soft-fork, as any validator operating under the original rules would still arrive at the correct pubkey-signature mapping through trial and error. This solution was completely forgotten and did not come up during Tapscript review. The justification given in the footnotes is that CHECKMULTISIG is not compatible with batch validation.Although threshold signatures can be implemented with the new CHECKSIGADD opcode, it requires six opcodes in addition to the pubkey pushes, instead of just 3, and the number of wasted opcodes scales linearly with the size of the threshold. Additionally, there are many use cases where interactive signing is not possible, and explicit thresholds must be used. For such applications, a batch-validation friendly CHECKMULTISIG would be useful. 2022-10-20T22:02:51+00:00 + In this conversation, Mark discusses a potential optimization opportunity for the CHECKMULTISIG algorithm in Bitcoin. The idea suggests using a minimally-encoded bitmap to specify which public keys are used or skipped, instead of requiring the final parameter on the stack to be zero. This would allow for a more efficient validation process and could be beneficial for applications where interactive signing is not possible.While MuSig-like key aggregation schemes can be used for n-of-n thresholds, there are still use cases where explicit k-of-n thresholds must be used. FROST is an alternative that supports k-of-n but requires participation from all signers in the set and additional data storage by privkey owners after the setup ritual. Despite this, the proposed batch-validation friendly CHECKMULTISIG algorithm would still be useful for such applications.Satoshi unintentionally made a mistake in the original CHECKMULTISIG implementation, causing an extra item to be popped off the stack upon completion. This extra value provides a malleability vector as anyone can change the value in the signature without invalidating a transaction. In legacy scripts, NULLDUMMY is a policy rule that states this value must be zero, and this was made a consensus rule for segwit scripts.Another issue with CHECKMULTISIG is that the algorithm seemingly precludes batch validation for threshold signatures. Batch validation could enable a 2x speedup during the initial block download phase. The algorithm cannot batch validate these signatures because it doesn't know which signatures map to which pubkeys.After SegWit was released, Luke-Jr observed that this new rule was suboptimal and Satoshi's mistake gave an extra parameter to CHECKMULTISIG. It was possible to use this parameter to convey extra information to the CHECKMULTISIG algorithm and enable batch validation of threshold signatures using this opcode.The updated CHECKMULTISIG algorithm requires the final parameter on the stack to be a minimally-encoded bitmap specifying which keys are used or skipped. Before validation, it is important to ensure that for a k-of-n threshold, only k bits are set in the bitfield indicating the used pubkeys (or n-k bits set indicating the keys to skip). During validation, the associated bit in the bitfield is checked to determine if the pubkey is used. If the bitfield indicates that the pubkey is not used, it can be skipped without even attempting validation.This solution is considered a soft-fork, as any validator operating under the original rules would still arrive at the correct pubkey-signature mapping through trial and error. This solution was completely forgotten and did not come up during Tapscript review. The justification given in the footnotes is that CHECKMULTISIG is not compatible with batch validation.Although threshold signatures can be implemented with the new CHECKSIGADD opcode, it requires six opcodes in addition to the pubkey pushes, instead of just 3, and the number of wasted opcodes scales linearly with the size of the threshold. Additionally, there are many use cases where interactive signing is not possible, and explicit thresholds must be used. For such applications, a batch-validation friendly CHECKMULTISIG would be useful. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-.xml b/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-.xml index 8ac2a322a7..c9469b1b3f 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Does Bitcoin require or have an honest majority or a rational one? (re rbf) - 2023-08-02T08:06:17.377284+00:00 - - S kang 2022-10-21 13:17:07+00:00 - - - email at yancy.lol 2022-10-21 08:47:19+00:00 - - - Peter Todd 2022-10-21 00:26:14+00:00 - - - Jeremy Rubin 2022-10-20 23:54:00+00:00 - - - Peter Todd 2022-10-20 22:28:16+00:00 - - - Peter Todd 2022-10-20 22:19:38+00:00 - - - email at yancy.lol 2022-10-20 19:21:58+00:00 - - - email at yancy.lol 2022-10-18 18:57:17+00:00 - - - Erik Aronesty 2022-10-18 17:33:15+00:00 - - - Jeremy Rubin 2022-10-18 16:27:26+00:00 - - - Russell O'Connor 2022-10-18 14:30:26+00:00 - - - Jeremy Rubin 2022-10-18 03:34:08+00:00 - - - email at yancy.lol 2022-10-17 22:31:39+00:00 - - - Jeremy Rubin 2022-10-17 19:10:18+00:00 - - - Jeremy Rubin 2022-10-17 19:02:01+00:00 - - - Russell O'Connor 2022-10-17 15:51:17+00:00 - - - email at yancy.lol 2022-10-16 19:03:51+00:00 - - - Jeremy Rubin 2022-10-16 17:35:54+00:00 - + 2025-09-26T14:21:08.766998+00:00 + python-feedgen + + + [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) Jeremy Rubin + 2022-10-16T17:35:00.000Z + + + email + 2022-10-16T19:03:00.000Z + + + Russell O'Connor + 2022-10-17T15:51:00.000Z + + + Jeremy Rubin + 2022-10-17T19:02:00.000Z + + + Jeremy Rubin + 2022-10-17T19:10:00.000Z + + + email + 2022-10-17T22:31:00.000Z + + + Jeremy Rubin + 2022-10-18T03:34:00.000Z + + + Russell O'Connor + 2022-10-18T14:30:00.000Z + + + Jeremy Rubin + 2022-10-18T16:27:00.000Z + + + Erik Aronesty + 2022-10-18T17:33:00.000Z + + + email + 2022-10-18T18:57:00.000Z + + + email + 2022-10-20T19:21:00.000Z + + + Peter Todd + 2022-10-20T22:19:00.000Z + + + Peter Todd + 2022-10-20T22:28:00.000Z + + + Jeremy Rubin + 2022-10-20T23:54:00.000Z + + + Peter Todd + 2022-10-21T00:26:00.000Z + + + email + 2022-10-21T08:47:00.000Z + + + S kang + 2022-10-21T13:17:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Does Bitcoin require or have an honest majority or a rational one? (re rbf) - 2023-08-02T08:06:17.377284+00:00 + 2025-09-26T14:21:08.768998+00:00 - In a recent discussion on the bitcoin-dev mailing list, participants explored various perspectives on the interplay between honesty and rationality within the Bitcoin ecosystem. Jeremy Rubin raised concerns about economic rationality potentially hijacking the network and going against Satoshi Nakamoto's original vision. Yancy suggested using the Nash Equilibrium as a basis for maintaining system integrity. Peter Todd, however, argued that relying solely on economic rationality may not be enough and highlighted risks associated with zeroconf reliance.The discussion also touched on the differences between honest majority and longest chain in Bitcoin. While the longest chain bug was acknowledged and patched by Satoshi, there is debate over whether relying solely on the assumption of an honest majority is sufficient. Participants also delved into the risks and challenges associated with mining off the tip, with disagreement over potential disruptions to the network.Erik Aronesty proposed an approach that focuses on improvement rather than evaluating changes independently, while Jeremy Rubin emphasized the importance of incentive-compatible rules and cautioning against assuming an honest majority without justification. The stability of mining in a low subsidy environment was also a topic of concern.In another discussion between Yancy and Jeremy Rubin, they debated whether an assumption of an honest majority or a rational majority is necessary for proper functioning of the network. They also discussed challenges related to fee sharing and the potential influence of bribes on selecting conflicting tips. Rubin argued that defining an honest behavior can create a higher utility system, even if it isn't the most rational choice. Both participants agreed on the need to document Bitcoin's assumptions and their implications for the network's properties.Rubin's post on the Bitcoin-dev mailing list highlighted the assumptions made about the majority of Bitcoin users, emphasizing that while there is a common assumption of rationality among the majority, there is also a minority who may act irrationally or dishonestly. This assumption applies to both mining rewards and electricity costs. Rubin clarified that Satoshi did not suggest that Bitcoin operates under a rational majority assumption and stressed the importance of understanding the nuances of assumptions made about user behavior.The controversy surrounding Replace-by-Fee (RBF) and its implications for honest behavior and rationality were also discussed. The safety of 0conf transactions was questioned, given the potential race conditions in the mempool, even with an assumed honest majority. Participants suggested documenting Bitcoin's assumptions and finding ways to weaken them without compromising expected behaviors.Overall, the discussions highlighted the ongoing exploration of different perspectives within the Bitcoin community regarding incentive compatibility, assumptions, and the need for continuous evaluation and modification to ensure the security and functionality of the system. The importance of incentivizing users to follow the rules of the system and defining and strengthening assumptions without compromising user expectations were emphasized. The role of the honest majority assumption in Bitcoin's design was highlighted, along with the challenges of ensuring the network's safety and stability. 2022-10-21T13:17:07+00:00 + In a recent discussion on the bitcoin-dev mailing list, participants explored various perspectives on the interplay between honesty and rationality within the Bitcoin ecosystem. Jeremy Rubin raised concerns about economic rationality potentially hijacking the network and going against Satoshi Nakamoto's original vision. Yancy suggested using the Nash Equilibrium as a basis for maintaining system integrity. Peter Todd, however, argued that relying solely on economic rationality may not be enough and highlighted risks associated with zeroconf reliance.The discussion also touched on the differences between honest majority and longest chain in Bitcoin. While the longest chain bug was acknowledged and patched by Satoshi, there is debate over whether relying solely on the assumption of an honest majority is sufficient. Participants also delved into the risks and challenges associated with mining off the tip, with disagreement over potential disruptions to the network.Erik Aronesty proposed an approach that focuses on improvement rather than evaluating changes independently, while Jeremy Rubin emphasized the importance of incentive-compatible rules and cautioning against assuming an honest majority without justification. The stability of mining in a low subsidy environment was also a topic of concern.In another discussion between Yancy and Jeremy Rubin, they debated whether an assumption of an honest majority or a rational majority is necessary for proper functioning of the network. They also discussed challenges related to fee sharing and the potential influence of bribes on selecting conflicting tips. Rubin argued that defining an honest behavior can create a higher utility system, even if it isn't the most rational choice. Both participants agreed on the need to document Bitcoin's assumptions and their implications for the network's properties.Rubin's post on the Bitcoin-dev mailing list highlighted the assumptions made about the majority of Bitcoin users, emphasizing that while there is a common assumption of rationality among the majority, there is also a minority who may act irrationally or dishonestly. This assumption applies to both mining rewards and electricity costs. Rubin clarified that Satoshi did not suggest that Bitcoin operates under a rational majority assumption and stressed the importance of understanding the nuances of assumptions made about user behavior.The controversy surrounding Replace-by-Fee (RBF) and its implications for honest behavior and rationality were also discussed. The safety of 0conf transactions was questioned, given the potential race conditions in the mempool, even with an assumed honest majority. Participants suggested documenting Bitcoin's assumptions and finding ways to weaken them without compromising expected behaviors.Overall, the discussions highlighted the ongoing exploration of different perspectives within the Bitcoin community regarding incentive compatibility, assumptions, and the need for continuous evaluation and modification to ensure the security and functionality of the system. The importance of incentivizing users to follow the rules of the system and defining and strengthening assumptions without compromising user expectations were emphasized. The role of the honest majority assumption in Bitcoin's design was highlighted, along with the challenges of ensuring the network's safety and stability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml b/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml index 169c1b1e94..0040f80feb 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) - 2023-08-02T08:06:38.367327+00:00 + 2025-09-26T14:21:15.183476+00:00 + python-feedgen Peter Todd 2022-10-20 22:52:03+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) - 2023-08-02T08:06:38.367327+00:00 + 2025-09-26T14:21:15.183618+00:00 - John Carvalho expresses concerns about replace-by-fee (RBF) and its potential negative impact on Bitcoin transactions. Although only a small percentage of transactions currently use RBF, the risk it poses is immeasurable. Transactions can be replaced without warning, making it difficult for merchants to effectively monitor and enforce acceptance of zero-conf (0conf) transactions.Carvalho argues that responsible 0conf acceptance is rational and trusting, as it mitigates exposure to double-spends and limits their size per block. He suggests that occasional double-spending is less costly than experiencing delayed checkout processes. However, if the remaining 71% of transactions also become subject to replaceability, relying on ignoring the risk becomes an unsustainable approach.The fact remains that merchants cannot rely on having seen all transactions being considered by miners for their block templates, nor can they guarantee receiving replacements before the original transaction is included in a block. The unstable gentlemen's agreement of "first-seen" is bound to fail eventually. Additionally, propping up the illusion of reliable payment promises hampers price discovery of blockspace and complicates protocol development.To address this, the context proposes converging on the inevitable outcome and facilitating replaceability for all transactions. This would involve reassessing business approaches in light of Bitcoin's natural modus operandi and embracing the uncertainty of the gossip system. By doing so, the band-aid can be ripped off rather than perpetually suffering from uncertainty.Peter Todd counters Carvalho's concerns by highlighting the use of RBF in his OpenTimestamps calendars for optimal fee discovery. Replacements account for approximately 95% of OpenTimestamps transactions mined. Todd also notes that at least 97.21% of hashing power supports opt-in RBF. He questions whether this indicates that almost all hashing power is irrational.Todd further mentions that Electrum has implemented an undo button using RBF successfully. Additionally, rejecting blocks containing double-spends could lead to severe consensus problems, despite the fact that it should be implemented.In summary, the context delves into the debate surrounding 0conf acceptance and RBF assurances in Bitcoin transactions. Carvalho argues for responsible 0conf acceptance, highlighting the risks of RBF and the potential impact on merchants. Todd counters with examples of successful RBF implementations and questions the rationality of opposing its use. The context ultimately raises the question of which approach, preferring blocks with replaced transactions or rejecting them, is more likely for the node set. 2022-10-20T22:52:03+00:00 + John Carvalho expresses concerns about replace-by-fee (RBF) and its potential negative impact on Bitcoin transactions. Although only a small percentage of transactions currently use RBF, the risk it poses is immeasurable. Transactions can be replaced without warning, making it difficult for merchants to effectively monitor and enforce acceptance of zero-conf (0conf) transactions.Carvalho argues that responsible 0conf acceptance is rational and trusting, as it mitigates exposure to double-spends and limits their size per block. He suggests that occasional double-spending is less costly than experiencing delayed checkout processes. However, if the remaining 71% of transactions also become subject to replaceability, relying on ignoring the risk becomes an unsustainable approach.The fact remains that merchants cannot rely on having seen all transactions being considered by miners for their block templates, nor can they guarantee receiving replacements before the original transaction is included in a block. The unstable gentlemen's agreement of "first-seen" is bound to fail eventually. Additionally, propping up the illusion of reliable payment promises hampers price discovery of blockspace and complicates protocol development.To address this, the context proposes converging on the inevitable outcome and facilitating replaceability for all transactions. This would involve reassessing business approaches in light of Bitcoin's natural modus operandi and embracing the uncertainty of the gossip system. By doing so, the band-aid can be ripped off rather than perpetually suffering from uncertainty.Peter Todd counters Carvalho's concerns by highlighting the use of RBF in his OpenTimestamps calendars for optimal fee discovery. Replacements account for approximately 95% of OpenTimestamps transactions mined. Todd also notes that at least 97.21% of hashing power supports opt-in RBF. He questions whether this indicates that almost all hashing power is irrational.Todd further mentions that Electrum has implemented an undo button using RBF successfully. Additionally, rejecting blocks containing double-spends could lead to severe consensus problems, despite the fact that it should be implemented.In summary, the context delves into the debate surrounding 0conf acceptance and RBF assurances in Bitcoin transactions. Carvalho argues for responsible 0conf acceptance, highlighting the risks of RBF and the potential impact on merchants. Todd counters with examples of successful RBF implementations and questions the rationality of opposing its use. The context ultimately raises the question of which approach, preferring blocks with replaced transactions or rejecting them, is more likely for the node set. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-against-package-limit-pinning.xml b/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-against-package-limit-pinning.xml index b79e43fa27..0a799de4a5 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-against-package-limit-pinning.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-against-package-limit-pinning.xml @@ -1,27 +1,109 @@ - + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning - 2023-08-02T08:07:07.237735+00:00 - - Greg Sanders 2022-10-19 13:22:08+00:00 - - - Antoine Riard 2022-10-19 00:33:13+00:00 - - - Greg Sanders 2022-10-18 13:52:46+00:00 - + 2025-09-26T14:20:40.955779+00:00 + python-feedgen + + + [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning Greg Sanders + 2022-10-18T13:52:00.000Z + + + [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage " Arik Sosman + 2022-10-18T15:33:00.000Z + + + Greg Sanders + 2022-10-18T15:51:00.000Z + + + Jeremy Rubin + 2022-10-18T16:41:00.000Z + + + Greg Sanders + 2022-10-18T18:18:00.000Z + + + [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF against package " Antoine Riard + 2022-10-19T00:33:00.000Z + + + Greg Sanders + 2022-10-19T13:22:00.000Z + + + James O'Beirne + 2022-10-19T15:11:00.000Z + + + Greg Sanders + 2022-10-20T13:42:00.000Z + + + Johan Torås Halseth + 2022-10-27T09:37:00.000Z + + + Greg Sanders + 2022-11-30T15:32:00.000Z + + + Greg Sanders + 2023-01-27T14:05:00.000Z + + + Peter Todd + 2023-02-02T14:52:00.000Z + + + Greg Sanders + 2023-02-02T14:59:00.000Z + + + Peter Todd + 2023-02-02T15:06:00.000Z + + + Greg Sanders + 2023-02-02T18:36:00.000Z + + + Peter Todd + 2023-02-02T20:22:00.000Z + + + Greg Sanders + 2023-02-02T20:47:00.000Z + + + Peter Todd + 2023-02-03T22:10:00.000Z + + + Greg Sanders + 2023-02-04T02:07:00.000Z + + + Peter Todd + 2023-02-04T16:02:00.000Z + + + Greg Sanders + 2023-03-13T16:38:00.000Z + + - python-feedgen + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF against package limit pinning - 2023-08-02T08:07:07.237735+00:00 + 2025-09-26T14:20:40.958387+00:00 - In an email thread discussing efficient mempool design within the constraints of existing Lightning Network protocols, Greg Sanders proposed a policy change called Ephemeral Anchors. This policy involves watermarked outputs that must be spent in V3 packages, with the anchor being marked by the bare script `OP_TRUE`. The proposal has several implications, including allowing any value (even dust) to be included without bloating the UTXO set, and enabling anyone to bump the transaction without key material.Sanders pointed out that V3 transactions may solve rule #3 and #5 pinning attacks under some constraints, but they don't address package limit pinning. He suggested two solutions: expand a carveout for "sibling eviction" or implement Ephemeral Anchors. With sibling eviction, a new child that pays enough to bump spends from the same parent would knock its sibling out of the mempool and take the one child slot. However, this mechanism might lead participants to overbid far beyond the top mempool block fees.Ephemeral Anchors would allow for more robust multi-party fee bumping, superseding the Lightning Carve-out. Change outputs would no longer be pinned, and RBF/CPFP would become more robust. The proposal also magnifies composability of smart contracts by removing the 1 block CSV timelock on outputs in certain situations.However, there are still open questions about whether allowing non-zero value in ephemeral outputs would open up MEV concerns, and whether SIGHASH_GROUP-like constructs would enable uncommitted ephemeral anchors to be added at spend time.Gloria proposed a solution for ln-penalty, reducing the number of anchors per commitment transaction to 1 and each version of the commitment transaction has a unique party's key on it worked around the problem. Antoine Riard suggested that package relay should be included in addition to package RBF, otherwise if Lightning transactions are still relayed one by one, the version of the commitment transaction won't replace the counterparties's commitments sleeping in network mempools. If non-zero value is allowed in ephemeral outputs, it could modify the incentives games of the channels counterparties.The author of an email to the Bitcoin-dev mailing list has elaborated on potential follow-up work related to V3 transactions and pinning attacks. While V3 transactions may solve some pinning attacks, they do not solve package limit pinning, which occurs when a fee-paying transaction cannot enter the mempool due to the existing mempool package being too large.The proposed solution is Ephemeral Anchors, which marks an output as one that must be spent in a V3 package. If this anchor must be spent, then anyone can bump the transaction without any transaction key material. This proposal also benefits more traditional wallet scenarios as change outputs can no longer be pinned, and RBF/CPFP becomes robust. Open questions include whether allowing non-zero value in ephemeral outputs opens up a MEV and whether SIGHASH_GROUP-like constructs would allow uncommitted ephemeral anchors to be added at spend time, depending on spending requirements. 2022-10-19T13:22:08+00:00 + In an email thread discussing efficient mempool design within the constraints of existing Lightning Network protocols, Greg Sanders proposed a policy change called Ephemeral Anchors. This policy involves watermarked outputs that must be spent in V3 packages, with the anchor being marked by the bare script `OP_TRUE`. The proposal has several implications, including allowing any value (even dust) to be included without bloating the UTXO set, and enabling anyone to bump the transaction without key material.Sanders pointed out that V3 transactions may solve rule #3 and #5 pinning attacks under some constraints, but they don't address package limit pinning. He suggested two solutions: expand a carveout for "sibling eviction" or implement Ephemeral Anchors. With sibling eviction, a new child that pays enough to bump spends from the same parent would knock its sibling out of the mempool and take the one child slot. However, this mechanism might lead participants to overbid far beyond the top mempool block fees.Ephemeral Anchors would allow for more robust multi-party fee bumping, superseding the Lightning Carve-out. Change outputs would no longer be pinned, and RBF/CPFP would become more robust. The proposal also magnifies composability of smart contracts by removing the 1 block CSV timelock on outputs in certain situations.However, there are still open questions about whether allowing non-zero value in ephemeral outputs would open up MEV concerns, and whether SIGHASH_GROUP-like constructs would enable uncommitted ephemeral anchors to be added at spend time.Gloria proposed a solution for ln-penalty, reducing the number of anchors per commitment transaction to 1 and each version of the commitment transaction has a unique party's key on it worked around the problem. Antoine Riard suggested that package relay should be included in addition to package RBF, otherwise if Lightning transactions are still relayed one by one, the version of the commitment transaction won't replace the counterparties's commitments sleeping in network mempools. If non-zero value is allowed in ephemeral outputs, it could modify the incentives games of the channels counterparties.The author of an email to the Bitcoin-dev mailing list has elaborated on potential follow-up work related to V3 transactions and pinning attacks. While V3 transactions may solve some pinning attacks, they do not solve package limit pinning, which occurs when a fee-paying transaction cannot enter the mempool due to the existing mempool package being too large.The proposed solution is Ephemeral Anchors, which marks an output as one that must be spent in a V3 package. If this anchor must be spent, then anyone can bump the transaction without any transaction key material. This proposal also benefits more traditional wallet scenarios as change outputs can no longer be pinned, and RBF/CPFP becomes robust. Open questions include whether allowing non-zero value in ephemeral outputs opens up a MEV and whether SIGHASH_GROUP-like constructs would allow uncommitted ephemeral anchors to be added at spend time, depending on spending requirements. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index d340330ad6..2d7ccb38a2 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:20:43.106885+00:00 + python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2023-08-02T08:08:51.134293+00:00 + 2025-09-26T14:20:43.107104+00:00 - On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to 2023-03-13T16:38:25+00:00 + On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Minor-DoS-vulnerability-in-BIP144-lack-of-tx-witness-data-size-limit.xml b/static/bitcoin-dev/Oct_2022/combined_Minor-DoS-vulnerability-in-BIP144-lack-of-tx-witness-data-size-limit.xml index c335d87a7d..da4170c50f 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Minor-DoS-vulnerability-in-BIP144-lack-of-tx-witness-data-size-limit.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Minor-DoS-vulnerability-in-BIP144-lack-of-tx-witness-data-size-limit.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Minor DoS vulnerability in BIP144 lack of tx witness data size limit - 2023-08-02T08:03:45.544323+00:00 - - Greg Sanders 2022-10-11 13:06:37+00:00 - - - Loki Verloren 2022-10-11 05:42:40+00:00 - + 2025-09-26T14:21:13.035388+00:00 + python-feedgen + + + [bitcoin-dev] Minor DoS vulnerability in BIP144 lack of tx witness data size limit Loki Verloren + 2022-10-11T05:42:00.000Z + + + Greg Sanders + 2022-10-11T13:06:00.000Z + + - python-feedgen + 2 Combined summary - Minor DoS vulnerability in BIP144 lack of tx witness data size limit - 2023-08-02T08:03:45.544323+00:00 + 2025-09-26T14:21:13.035820+00:00 - On October 11, 2022, Loki Verloren brought attention to a problem with BIP144 regarding a recent multisig segwit transaction. The issue arises from the fact that a single transaction witness can be as large as the maximum block size. This has resulted in a special case where a block contains over 33k worth of witness data. To address this, it is crucial to establish a specific limit on the size of a transaction witness and engage in a broader discussion about total transaction sizes.Implementing arbitrary size restrictions within the consensus may have negative consequences such as burned coins, adding complexity without any real gain. Therefore, it is essential to devise a proper specification for setting the maximum size limit of a transaction witness. Failure to do so would render proper implementation impossible, leaving the bitcoin core repository code as the only available option.Loki Verloren suggests that the weight calculation should increase exponentially to discourage the inclusion of transactions like the aforementioned one on the blockchain. The cost of executing such a transaction was approximately $5. While there are various issues associated with adding arbitrary size restrictions to the consensus, the primary focus must be on addressing the problem with BIP144 and establishing a concrete limit on the maximum size of a transaction witness. 2022-10-11T13:06:37+00:00 + On October 11, 2022, Loki Verloren brought attention to a problem with BIP144 regarding a recent multisig segwit transaction. The issue arises from the fact that a single transaction witness can be as large as the maximum block size. This has resulted in a special case where a block contains over 33k worth of witness data. To address this, it is crucial to establish a specific limit on the size of a transaction witness and engage in a broader discussion about total transaction sizes.Implementing arbitrary size restrictions within the consensus may have negative consequences such as burned coins, adding complexity without any real gain. Therefore, it is essential to devise a proper specification for setting the maximum size limit of a transaction witness. Failure to do so would render proper implementation impossible, leaving the bitcoin core repository code as the only available option.Loki Verloren suggests that the weight calculation should increase exponentially to discourage the inclusion of transactions like the aforementioned one on the blockchain. The cost of executing such a transaction was approximately $5. While there are various issues associated with adding arbitrary size restrictions to the consensus, the primary focus must be on addressing the problem with BIP144 and establishing a concrete limit on the maximum size of a transaction witness. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_MuSig2-BIP.xml b/static/bitcoin-dev/Oct_2022/combined_MuSig2-BIP.xml index 400b706661..a3ca911656 100644 --- a/static/bitcoin-dev/Oct_2022/combined_MuSig2-BIP.xml +++ b/static/bitcoin-dev/Oct_2022/combined_MuSig2-BIP.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 - - Jonas Nick 2022-11-03 14:43:22+00:00 - - - Jonas Nick 2022-10-11 15:34:23+00:00 - - - Jonas Nick 2022-10-03 20:41:08+00:00 - - - AdamISZ 2022-06-12 23:07:08+00:00 - - - AdamISZ 2022-05-26 17:34:47+00:00 - - - Jonas Nick 2022-05-26 15:32:33+00:00 - - - AdamISZ 2022-05-24 19:06:41+00:00 - - - AdamISZ 2022-05-23 22:09:52+00:00 - - - Jonas Nick 2022-05-23 15:56:54+00:00 - - - AdamISZ 2022-05-22 22:26:08+00:00 - - - Jonas Nick 2022-04-28 19:18:34+00:00 - - - Brandon Black 2022-04-28 15:33:42+00:00 - - - Olaoluwa Osuntokun 2022-04-28 03:53:59+00:00 - - - Olaoluwa Osuntokun 2022-04-28 01:47:33+00:00 - - - Jonas Nick 2022-04-05 22:57:13+00:00 - + 2025-09-26T14:20:55.933373+00:00 + python-feedgen + + + [bitcoin-dev] MuSig2 BIP Jonas Nick + 2022-04-05T22:57:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T01:47:00.000Z + + + Olaoluwa Osuntokun + 2022-04-28T03:53:00.000Z + + + Brandon Black + 2022-04-28T15:33:00.000Z + + + Jonas Nick + 2022-04-28T19:18:00.000Z + + + AdamISZ + 2022-05-22T22:26:00.000Z + + + Jonas Nick + 2022-05-23T15:56:00.000Z + + + AdamISZ + 2022-05-23T22:09:00.000Z + + + AdamISZ + 2022-05-24T19:06:00.000Z + + + Jonas Nick + 2022-05-26T15:32:00.000Z + + + AdamISZ + 2022-05-26T17:34:00.000Z + + + AdamISZ + 2022-06-12T23:07:00.000Z + + + Jonas Nick + 2022-10-03T20:41:00.000Z + + + Jonas Nick + 2022-10-11T15:34:00.000Z + + + Jonas Nick + 2022-11-03T14:43:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - MuSig2 BIP - 2023-08-02T06:03:24.136194+00:00 + 2025-09-26T14:20:55.935034+00:00 - The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary 2022-11-03T14:43:22+00:00 + The MuSig2 BIP draft has been updated to fix a vulnerability that was discovered in an earlier post. The vulnerability allowed for an attack using Wagner's algorithm, but a fixed scheme has been implemented that allows tweaking. The "BLLOR" attack mentioned in the article has also been implemented. The fix for the MuSig2 BIP now requires the signer to determine the secret key before calling ''NonceGen''. Changes can be seen in the pull request provided.A team of researchers have discovered an attack against the latest version of the BIP MuSig2. The attack is effective when certain conditions are met, including the use of a tweaked individual key and the signer's public key appearing multiple times with different tweaks. The researchers suggest making the secret key argument mandatory in the NonceGen algorithm as one possible fix. They are exploring other options and will provide a concrete fix soon. The security proof of the scheme presented in the MuSig2 paper is not affected by this discovery.The BIP draft has undergone improvements based on feedback from the mailing list and development repository. Multiple implementations are now in place, and no major changes or features have been requested recently. The MuSig2 BIP has been submitted as a pull request to the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The authors express gratitude to individuals who provided feedback during the drafting process.An email exchange between AdamISZ and Jonas Nick discusses the handling of duplicate keys in the MuSig2 protocol. There is a debate about whether identifying dishonest signers is useful and whether allowing duplicate keys adds complexity and risk. The authors respond to feedback, disagreeing with the suggestion that identifying dishonest signers is useless but agreeing that broken implementations should not be protected. They agree that aborting in KeyAgg when encountering duplicate keys is compatible with the MuSig2 BIP draft.AdamISZ reaches out to clarify points regarding handling duplicate keys in the MuSig2 protocol. He provides a summary of the concept and argues that the protocol does not fully identify disruptive signers. Waxwing also raises concerns about the implementation complexity and potential for errors.In a bitcoin-dev mailing list, AdamISZ requests clarifications on a point in the BIP draft regarding identical public keys. Jonas Nick responds, explaining how the draft handles identical keys and the solution proposed to identify and remove disruptive signers.The BIP draft addresses the issue of identical public keys in a multi-signature scheme. Simply aborting when faced with identical keys would allow for disruption by copying another signer's key. The proposed solution allows for the handling of identical keys but requires added complexity. The full details can be found in the BIP-MuSig2 draft.Waxwing/AdamISZ contacts Jonas Nick via email to discuss the BIP draft and its relation to MuSig2* optimization. They discuss the purpose of allowing identical pubkeys and potential risks. Jonas shares that they are working on a BIP that supports tweaking and allows deriving child keys from aggregate keys.The BIP draft is already useful, and test vectors have been extracted. Implementations need to make pre-tweaked combined keys available for Taproot tweak application. The specified algorithms in the BIP could be improved to avoid unnecessary recomputation. Key aggregation and tweaking are separated into different functions in the libsecp256k1-zkp implementation. A precise specification has been made to address this. The author will investigate how to minimize complexity and split key aggregation and tweaking.In an email conversation, Jonas and Brandon discuss a shortcut feature for a specific signer to send nonces last. This feature simplifies certain protocols and eliminates the need for randomness and state tracking for the last signer.The taproot interaction is defined as a function of the internal key itself, known as the taproot tweak. The full tweak cannot be known in advance and must be aggregated by obtaining the internal key first.A developer praises Jonas Nick and co-authors for publishing an excellent technical specification on the MuSig2 BIP. The developer has been following the BIP and updating their implementation accordingly. They have integrated their implementation into lnd to gain hands-on experience. They highlight the need to make the pre-tweaked combined key available for certain cases, which the current BIP does not address.Tim Ruffing, Elliott Jin, and another individual have collaborated on a MuSig2 BIP proposal. This proposal supports the two signing modes mentioned above and is compatible with BIP340 public keys and signatures. It also allows for tweaking and deriving BIP32 child keys from aggregate keys. Furthermore, the proposal enables the creation of BIP341 Taproot outputs with key and script paths.Interested parties can find the comprehensive information about the proposal on Github, where they can review the draft. The team has already tested the proposal and even written a reference implementation in python. However, it is important to note that the proposal is still in the draft stage, so minor tweaks may be necessary - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml b/static/bitcoin-dev/Oct_2022/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml index 17da6013f8..cc1d586651 100644 --- a/static/bitcoin-dev/Oct_2022/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml +++ b/static/bitcoin-dev/Oct_2022/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - New transaction policies (nVersion=3) for contracting protocols - 2023-08-02T07:37:32.592526+00:00 - - Greg Sanders 2023-06-21 20:57:45+00:00 - - - Ruben Somsen 2022-10-01 09:59:55+00:00 - - - Greg Sanders 2022-09-30 12:17:38+00:00 - - - Bastien TEINTURIER 2022-09-30 12:08:41+00:00 - - - Ruben Somsen 2022-09-30 00:13:53+00:00 - - - Greg Sanders 2022-09-29 14:41:28+00:00 - - - Bastien TEINTURIER 2022-09-29 09:15:02+00:00 - - - Gloria Zhao 2022-09-26 16:47:49+00:00 - - - Greg Sanders 2022-09-26 16:01:54+00:00 - - - Bastien TEINTURIER 2022-09-26 15:27:40+00:00 - - - Antoine Riard 2022-09-25 23:59:22+00:00 - - - Greg Sanders 2022-09-23 18:48:39+00:00 - - - Gloria Zhao 2022-09-23 15:18:21+00:00 - + 2025-09-26T14:20:32.396252+00:00 + python-feedgen + + + [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols Gloria Zhao + 2022-09-23T15:18:00.000Z + + + Greg Sanders + 2022-09-23T18:48:00.000Z + + + Antoine Riard + 2022-09-25T23:59:00.000Z + + + Bastien TEINTURIER + 2022-09-26T15:27:00.000Z + + + Greg Sanders + 2022-09-26T16:01:00.000Z + + + Gloria Zhao + 2022-09-26T16:47:00.000Z + + + Bastien TEINTURIER + 2022-09-29T09:15:00.000Z + + + Greg Sanders + 2022-09-29T14:41:00.000Z + + + Ruben Somsen + 2022-09-30T00:13:00.000Z + + + Bastien TEINTURIER + 2022-09-30T12:08:00.000Z + + + Greg Sanders + 2022-09-30T12:17:00.000Z + + + Ruben Somsen + 2022-10-01T09:59:00.000Z + + + Greg Sanders + 2023-06-21T20:57:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - New transaction policies (nVersion=3) for contracting protocols - 2023-08-02T07:37:32.592526+00:00 + 2025-09-26T14:20:32.397770+00:00 - Bitcoin developer Gloria Zhao has proposed a new transaction format called V3, which aims to improve replace-by-fee (RBF) and child-pays-for-parent (CPFP) protocols. The proposal includes rules that limit the size and number of descendant transactions, allowing for easier fee-bumping and reducing the need for managing a large UTXO pool. These rules provide flexibility for Layer 2 (L2) protocols while maintaining security and efficiency.Under the proposed rules, a V3 transaction can be replaced even without signaling BIP125 replaceability, as long as it meets other RBF rules. Any descendant of an unconfirmed V3 transaction must also be V3, and an unconfirmed V3 transaction cannot have more than one descendant. Additionally, a V3 transaction with an unconfirmed V3 ancestor cannot exceed 1000 virtual bytes in size.The proposal also discusses the intended usage for Lightning Network (LN) commitment transactions, which should be V3 and have one anchor output. If the commitment transaction needs to be broadcasted, the desired feerate at broadcast time should be determined, and the anchor output should be spent in a high feerate transaction. Multiple commitment transactions can be funded by one child, and to add more fees, the child should be replaced with a higher-feerate transaction.In addition to the V3 transaction format, the Bitcoin development team has proposed a new package relay policy to replace BIP125, the current Replace-by-Fee (RBF) policy. The new policy includes changes to the feerate requirements and ensures that replacement transactions are not less incentive-compatible to mine. It also addresses questions related to Rule 3 Pinning, counterparty's commitment transaction in the mempool, privacy concerns, backward compatibility, and replacing transactions between V2 and V3.The proposed policies aim to improve RBF and CPFP protocols, with specific rules for V3 transactions and modifications to package RBF rules. The changes aim to provide inherited replaceability signaling and prevent pinning attacks. Gloria Zhao has implemented these policies in Bitcoin Core and welcomes feedback from the community. The proposal offers potential benefits for L2/contract protocols and addresses some limitations of previous proposals. Feedback and review of the proposal are encouraged by the development team. 2023-06-21T20:57:45+00:00 + Bitcoin developer Gloria Zhao has proposed a new transaction format called V3, which aims to improve replace-by-fee (RBF) and child-pays-for-parent (CPFP) protocols. The proposal includes rules that limit the size and number of descendant transactions, allowing for easier fee-bumping and reducing the need for managing a large UTXO pool. These rules provide flexibility for Layer 2 (L2) protocols while maintaining security and efficiency.Under the proposed rules, a V3 transaction can be replaced even without signaling BIP125 replaceability, as long as it meets other RBF rules. Any descendant of an unconfirmed V3 transaction must also be V3, and an unconfirmed V3 transaction cannot have more than one descendant. Additionally, a V3 transaction with an unconfirmed V3 ancestor cannot exceed 1000 virtual bytes in size.The proposal also discusses the intended usage for Lightning Network (LN) commitment transactions, which should be V3 and have one anchor output. If the commitment transaction needs to be broadcasted, the desired feerate at broadcast time should be determined, and the anchor output should be spent in a high feerate transaction. Multiple commitment transactions can be funded by one child, and to add more fees, the child should be replaced with a higher-feerate transaction.In addition to the V3 transaction format, the Bitcoin development team has proposed a new package relay policy to replace BIP125, the current Replace-by-Fee (RBF) policy. The new policy includes changes to the feerate requirements and ensures that replacement transactions are not less incentive-compatible to mine. It also addresses questions related to Rule 3 Pinning, counterparty's commitment transaction in the mempool, privacy concerns, backward compatibility, and replacing transactions between V2 and V3.The proposed policies aim to improve RBF and CPFP protocols, with specific rules for V3 transactions and modifications to package RBF rules. The changes aim to provide inherited replaceability signaling and prevent pinning attacks. Gloria Zhao has implemented these policies in Bitcoin Core and welcomes feedback from the community. The proposal offers potential benefits for L2/contract protocols and addresses some limitations of previous proposals. Feedback and review of the proposal are encouraged by the development team. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 140fe3148d..8888512508 100644 --- a/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On a new community process to specify covenants - 2023-08-02T07:05:21.717413+00:00 + 2025-09-26T14:20:45.254287+00:00 + python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - On a new community process to specify covenants - 2023-08-02T07:05:21.718414+00:00 + 2025-09-26T14:20:45.254467+00:00 - The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest 2022-10-07T15:33:12+00:00 + The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml b/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml index 2fcbfee937..44d313982a 100644 --- a/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml +++ b/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On mempool policy consistency - 2023-08-02T08:19:04.219216+00:00 + 2025-09-26T14:20:30.199403+00:00 + python-feedgen email at yancy.lol 2022-11-10 14:38:27+00:00 @@ -135,13 +136,13 @@ - python-feedgen + 2 Combined summary - On mempool policy consistency - 2023-08-02T08:19:04.220213+00:00 + 2025-09-26T14:20:30.199636+00:00 - The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases. The discussion also touched upon 2022-11-10T14:38:27+00:00 + The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases. The discussion also touched upon - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml index b85393ef37..cb9019a4d4 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Packaged Transaction Relay - 2023-08-02T06:45:04.464151+00:00 + 2025-09-26T14:21:06.612499+00:00 + python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Packaged Transaction Relay - 2023-08-02T06:45:04.465148+00:00 + 2025-09-26T14:21:06.612658+00:00 - The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. 2022-10-10T22:05:38+00:00 + The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_RFC-for-a-BIP32-recurrent-address-derivation-scheme.xml b/static/bitcoin-dev/Oct_2022/combined_RFC-for-a-BIP32-recurrent-address-derivation-scheme.xml index 36a9f5c8b6..b5066b02f1 100644 --- a/static/bitcoin-dev/Oct_2022/combined_RFC-for-a-BIP32-recurrent-address-derivation-scheme.xml +++ b/static/bitcoin-dev/Oct_2022/combined_RFC-for-a-BIP32-recurrent-address-derivation-scheme.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - RFC for a BIP32 recurrent address derivation scheme - 2023-08-02T07:35:46.646061+00:00 - - El_Hoy 2022-10-04 19:08:34+00:00 - - - Ruben Somsen 2022-09-29 22:41:29+00:00 - - - El_Hoy 2022-09-22 03:06:50+00:00 - + 2025-09-26T14:20:25.936312+00:00 + python-feedgen + + + [bitcoin-dev] RFC for a BIP32 recurrent address derivation scheme El_Hoy + 2022-09-22T03:06:00.000Z + + + Ruben Somsen + 2022-09-29T22:41:00.000Z + + + El_Hoy + 2022-10-04T19:08:00.000Z + + - python-feedgen + 2 Combined summary - RFC for a BIP32 recurrent address derivation scheme - 2023-08-02T07:35:46.646061+00:00 + 2025-09-26T14:20:25.936827+00:00 - In an email thread on the bitcoin-dev mailing list, Eloy proposed a scheme that would enable recurring payments using a single offline interaction. The proposed scheme follows the structure described in BIP44 and involves the use of a "contact" level to represent a contact address for the recipient. By using Carol's contact address, Bob can generate multiple derived addresses for recurring payments without revealing any information on-chain.Eloy pointed out that while there are mentions of such a scheme, there is currently no framework to facilitate its usage and ensure interoperability between different implementations. To address this, Eloy proposed a BIP (Bitcoin Improvement Proposal) that would make it easier for developers to implement and users to utilize this scheme.Ruben responded to the proposal, acknowledging that it is an improvement over the current status quo. However, he noted that schemes like BIP47 and Silent Payments do not require any interaction with the sender, unlike this proposed scheme which requires a one-time interaction. This makes it less suitable for one-time donations.Ruben also raised concerns about how the "contact" level should be defined deterministically. If Bob defines it for Carol, it would be difficult to recover payments deterministically without backing up how it is defined. Additionally, Ruben highlighted the importance of considering the gap limit, suggesting that a low default gap limit should be defined for these extended public keys (xpubs) to avoid exponential blowup.Overall, the proposed scheme offers a positive solution to the issue of having to use a new address for every transaction, which can be inconvenient for making recurring payments. It provides privacy and allows for easy labeling of received payments. Furthermore, it gives Bob the advantage of choosing to send payments using multiple outputs. However, adjustments may be necessary for different address types on Bitcoin. 2022-10-04T19:08:34+00:00 + In an email thread on the bitcoin-dev mailing list, Eloy proposed a scheme that would enable recurring payments using a single offline interaction. The proposed scheme follows the structure described in BIP44 and involves the use of a "contact" level to represent a contact address for the recipient. By using Carol's contact address, Bob can generate multiple derived addresses for recurring payments without revealing any information on-chain.Eloy pointed out that while there are mentions of such a scheme, there is currently no framework to facilitate its usage and ensure interoperability between different implementations. To address this, Eloy proposed a BIP (Bitcoin Improvement Proposal) that would make it easier for developers to implement and users to utilize this scheme.Ruben responded to the proposal, acknowledging that it is an improvement over the current status quo. However, he noted that schemes like BIP47 and Silent Payments do not require any interaction with the sender, unlike this proposed scheme which requires a one-time interaction. This makes it less suitable for one-time donations.Ruben also raised concerns about how the "contact" level should be defined deterministically. If Bob defines it for Carol, it would be difficult to recover payments deterministically without backing up how it is defined. Additionally, Ruben highlighted the importance of considering the gap limit, suggesting that a low default gap limit should be defined for these extended public keys (xpubs) to avoid exponential blowup.Overall, the proposed scheme offers a positive solution to the issue of having to use a new address for every transaction, which can be inconvenient for making recurring payments. It provides privacy and allows for easy labeling of received payments. Furthermore, it gives Bob the advantage of choosing to send payments using multiple outputs. However, adjustments may be necessary for different address types on Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Refreshed-BIP324.xml b/static/bitcoin-dev/Oct_2022/combined_Refreshed-BIP324.xml index cd4118e47b..f0743539cc 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Refreshed-BIP324.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Refreshed-BIP324.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100274+00:00 - - Tim Ruffing 2023-10-11 20:52:52+00:00 - - - Erik Aronesty 2023-02-28 21:02:41+00:00 - - - Dhruv M 2023-02-28 18:07:06+00:00 - - - Anthony Towns 2023-02-21 16:03:37+00:00 - - - Pieter Wuille 2023-02-20 15:22:30+00:00 - - - Anthony Towns 2023-02-19 23:56:02+00:00 - - - Pieter Wuille 2023-02-17 22:13:05+00:00 - - - Anthony Towns 2023-02-17 15:51:19+00:00 - - - Dhruv M 2023-02-16 17:43:22+00:00 - - - Anthony Towns 2023-01-09 08:11:05+00:00 - - - Anthony Towns 2023-01-05 23:12:50+00:00 - - - Pieter Wuille 2023-01-05 22:06:29+00:00 - - - Anthony Towns 2022-11-18 08:24:49+00:00 - - - Yuval Kogman 2022-11-12 18:52:31+00:00 - - - Pieter Wuille 2022-11-12 03:23:16+00:00 - - - Pieter Wuille 2022-11-10 21:23:44+00:00 - - - Anthony Towns 2022-11-08 03:20:23+00:00 - - - Jonas Schnelli 2022-11-03 22:26:54+00:00 - - - Murch 2022-11-03 17:53:26+00:00 - - - Vasil Dimov 2022-10-27 07:28:38+00:00 - - - Pieter Wuille 2022-10-26 16:39:02+00:00 - - - Dhruv M 2022-10-08 12:59:58+00:00 - + 2025-09-26T14:21:10.918592+00:00 + python-feedgen + + + [bitcoin-dev] Refreshed BIP324 Dhruv M + 2022-10-08T12:59:00.000Z + + + Pieter Wuille + 2022-10-26T16:39:00.000Z + + + Vasil Dimov + 2022-10-27T07:28:00.000Z + + + Murch + 2022-11-03T17:53:00.000Z + + + Jonas Schnelli + 2022-11-03T22:26:00.000Z + + + Anthony Towns + 2022-11-08T03:20:00.000Z + + + Pieter Wuille + 2022-11-10T21:23:00.000Z + + + Pieter Wuille + 2022-11-12T03:23:00.000Z + + + Yuval Kogman + 2022-11-12T18:52:00.000Z + + + Anthony Towns + 2022-11-18T08:24:00.000Z + + + Pieter Wuille + 2023-01-05T22:06:00.000Z + + + Anthony Towns + 2023-01-05T23:12:00.000Z + + + Anthony Towns + 2023-01-09T08:11:00.000Z + + + Dhruv M + 2023-02-16T17:43:00.000Z + + + Anthony Towns + 2023-02-17T15:51:00.000Z + + + Pieter Wuille + 2023-02-17T22:13:00.000Z + + + Anthony Towns + 2023-02-19T23:56:00.000Z + + + Pieter Wuille + 2023-02-20T15:22:00.000Z + + + Anthony Towns + 2023-02-21T16:03:00.000Z + + + Dhruv M + 2023-02-28T18:07:00.000Z + + + Erik Aronesty + 2023-02-28T21:02:00.000Z + + + Tim Ruffing + 2023-10-11T20:52:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100469+00:00 + 2025-09-26T14:21:10.920935+00:00 - The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. 2023-10-11T20:52:52+00:00 + The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Relaxing-minimum-non-witness-transaction-size-policy-restriction.xml b/static/bitcoin-dev/Oct_2022/combined_Relaxing-minimum-non-witness-transaction-size-policy-restriction.xml index b9c115e350..0d61206a8f 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Relaxing-minimum-non-witness-transaction-size-policy-restriction.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Relaxing-minimum-non-witness-transaction-size-policy-restriction.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Relaxing minimum non-witness transaction size policy restriction - 2023-08-02T08:04:33.278936+00:00 - - Greg Sanders 2022-10-26 19:09:38+00:00 - - - Peter Todd 2022-10-21 00:13:15+00:00 - - - Greg Sanders 2022-10-21 00:07:54+00:00 - - - Peter Todd 2022-10-20 23:21:01+00:00 - - - Greg Sanders 2022-10-11 13:14:54+00:00 - - - Greg Sanders 2022-10-11 12:50:07+00:00 - + 2025-09-26T14:21:04.461850+00:00 + python-feedgen + + + [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction Greg Sanders + 2022-10-11T12:50:00.000Z + + + Greg Sanders + 2022-10-11T13:14:00.000Z + + + Peter Todd + 2022-10-20T23:21:00.000Z + + + Greg Sanders + 2022-10-21T00:07:00.000Z + + + Peter Todd + 2022-10-21T00:13:00.000Z + + + Greg Sanders + 2022-10-26T19:09:00.000Z + + - python-feedgen + 2 Combined summary - Relaxing minimum non-witness transaction size policy restriction - 2023-08-02T08:04:33.278936+00:00 + 2025-09-26T14:21:04.462756+00:00 - A competing pull request has been opened in response to feedback regarding the broadcasting of blocks that are 61, 62, or 63 bytes long but not 64 bytes. Greg Sanders initially opened an issue expressing concerns about the oddity of setting the limit at 64 bytes instead of the previously proposed values. However, Peter Todd commented that it is acceptable to restrict only blocks that are 64 bytes long due to a specific reason. It is important to note that this change is not a consensus change like the Great Consensus Cleanup, and it would only affect fairly technical use cases. Feedback is requested on the new pull request.In an email thread on October 20, 2022, Greg Sanders raised concerns about a proposal to limit the broadcasting of data packets larger than 64 bytes. He worried about people finding it odd that the limit was set at 64 bytes instead of the previously proposed values. Despite his concerns, he expressed willingness to modify his proposal and pull request if there were no strong objections. Peter Todd responded, stating that restricting only 64 bytes is justified because there is a specific reason for doing so, and it would only impact fairly technical use cases. The email thread included an attachment with Peter Todd's signature.Greg Sanders proposed relaxing the policy limit for transactions to be 85 non-witness serialized bytes in a message to the Bitcoin developers. He suggested effectively lowering the value to 65 non-witness bytes, which would allow a single input, single output transaction with 4 bytes of OP_RETURN padding. This proposal was made after considering various transaction types. The current policy limit was introduced as a covert fix for CVE-2017-12842, and the motivation behind the chosen "reasonable" constant was later revealed. Sanders wanted to ensure that his proposal did not face opposition due to the oddity of allowing blocks of 61, 62, or 63 bytes but not 64 bytes. Peter Todd responded, asking for clarification on any potential issues and suggesting that spending a single input to OP_RETURN with no payload is a valid use to eliminate dust in the UTXO set. Sanders was open to modifying his proposal if there were no strong objections.The current Bitcoin policy limit for transactions is set at 85 non-witness serialized bytes, introduced as a covert fix for CVE-2017-12842. Greg Sanders proposed relaxing this limit to 65 non-witness bytes, aligning with BlueMatt's proposal in the Great Consensus Cleanup. This change would allow for a single input, single output transaction with 4 bytes of OP_RETURN padding, eliminating the need to pad out 21 bytes to reach p2wpkh size. Alternatively, there is consideration for allowing anything below 64 non-witness bytes, although this may come with potential issues. Peter Todd suggests that spending a single input to OP_RETURN with no payload could serve as a valid use to eliminate dust in the UTXO set.On October 11, 2022, Greg Sanders proposed relaxing the minimum non-witness transaction size policy restriction from 85 to 65 non-witness bytes. This change is motivated by the need to support more exotic transaction types and address a covert fix for CVE-2017-12842. The proposed change would enable a single input, single output transaction with 4 bytes of OP_RETURN padding instead of having to pad out 21 bytes to reach p2wpkh size. However, there is also consideration being given to allowing anything below 64 non-witness bytes. Concerns were raised about backward compatibility for older clients like v0.18, which may not be able to receive transactions from newer clients requiring validation of 85 non-witness serialized bytes. The pull request for this proposed change can be found on GitHub. Until this change reaches a critical mass of 10%+ of the network, propagation of these types of transactions may be hindered.A proposal has been made to relax the current policy limit of 85 non-witness serialized bytes for Bitcoin transactions to 65 non-witness bytes. This change would enable a single input, single output transaction with 4 bytes of OP_RETURN padding instead of having to pad out 21 bytes to reach p2wpkh size. The current limit was introduced as a covert fix for CVE-2017-12842, but the chosen "reasonable" constant was not optimal. Consideration is also being given to allowing anything below 64 non-witness bytes, although this option may come with risks for only a small gain in bytes. The relevant pull request and alternative proposals can be found on GitHub, and feedback and concerns regarding this proposal are welcomed. 2022-10-26T19:09:38+00:00 + A competing pull request has been opened in response to feedback regarding the broadcasting of blocks that are 61, 62, or 63 bytes long but not 64 bytes. Greg Sanders initially opened an issue expressing concerns about the oddity of setting the limit at 64 bytes instead of the previously proposed values. However, Peter Todd commented that it is acceptable to restrict only blocks that are 64 bytes long due to a specific reason. It is important to note that this change is not a consensus change like the Great Consensus Cleanup, and it would only affect fairly technical use cases. Feedback is requested on the new pull request.In an email thread on October 20, 2022, Greg Sanders raised concerns about a proposal to limit the broadcasting of data packets larger than 64 bytes. He worried about people finding it odd that the limit was set at 64 bytes instead of the previously proposed values. Despite his concerns, he expressed willingness to modify his proposal and pull request if there were no strong objections. Peter Todd responded, stating that restricting only 64 bytes is justified because there is a specific reason for doing so, and it would only impact fairly technical use cases. The email thread included an attachment with Peter Todd's signature.Greg Sanders proposed relaxing the policy limit for transactions to be 85 non-witness serialized bytes in a message to the Bitcoin developers. He suggested effectively lowering the value to 65 non-witness bytes, which would allow a single input, single output transaction with 4 bytes of OP_RETURN padding. This proposal was made after considering various transaction types. The current policy limit was introduced as a covert fix for CVE-2017-12842, and the motivation behind the chosen "reasonable" constant was later revealed. Sanders wanted to ensure that his proposal did not face opposition due to the oddity of allowing blocks of 61, 62, or 63 bytes but not 64 bytes. Peter Todd responded, asking for clarification on any potential issues and suggesting that spending a single input to OP_RETURN with no payload is a valid use to eliminate dust in the UTXO set. Sanders was open to modifying his proposal if there were no strong objections.The current Bitcoin policy limit for transactions is set at 85 non-witness serialized bytes, introduced as a covert fix for CVE-2017-12842. Greg Sanders proposed relaxing this limit to 65 non-witness bytes, aligning with BlueMatt's proposal in the Great Consensus Cleanup. This change would allow for a single input, single output transaction with 4 bytes of OP_RETURN padding, eliminating the need to pad out 21 bytes to reach p2wpkh size. Alternatively, there is consideration for allowing anything below 64 non-witness bytes, although this may come with potential issues. Peter Todd suggests that spending a single input to OP_RETURN with no payload could serve as a valid use to eliminate dust in the UTXO set.On October 11, 2022, Greg Sanders proposed relaxing the minimum non-witness transaction size policy restriction from 85 to 65 non-witness bytes. This change is motivated by the need to support more exotic transaction types and address a covert fix for CVE-2017-12842. The proposed change would enable a single input, single output transaction with 4 bytes of OP_RETURN padding instead of having to pad out 21 bytes to reach p2wpkh size. However, there is also consideration being given to allowing anything below 64 non-witness bytes. Concerns were raised about backward compatibility for older clients like v0.18, which may not be able to receive transactions from newer clients requiring validation of 85 non-witness serialized bytes. The pull request for this proposed change can be found on GitHub. Until this change reaches a critical mass of 10%+ of the network, propagation of these types of transactions may be hindered.A proposal has been made to relax the current policy limit of 85 non-witness serialized bytes for Bitcoin transactions to 65 non-witness bytes. This change would enable a single input, single output transaction with 4 bytes of OP_RETURN padding instead of having to pad out 21 bytes to reach p2wpkh size. The current limit was introduced as a covert fix for CVE-2017-12842, but the chosen "reasonable" constant was not optimal. Consideration is also being given to allowing anything below 64 non-witness bytes, although this option may come with risks for only a small gain in bytes. The relevant pull request and alternative proposals can be found on GitHub, and feedback and concerns regarding this proposal are welcomed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Silent-Payment-v4-coinjoin-support-added-.xml b/static/bitcoin-dev/Oct_2022/combined_Silent-Payment-v4-coinjoin-support-added-.xml index a0ff3492fc..b0d279ab81 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Silent-Payment-v4-coinjoin-support-added-.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Silent-Payment-v4-coinjoin-support-added-.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Silent Payment v4 (coinjoin support added) - 2023-08-02T08:03:59.669673+00:00 - - alicexbt 2022-10-23 20:54:26+00:00 - - - woltx 2022-10-23 07:00:07+00:00 - - - alicexbt 2022-10-12 09:04:35+00:00 - - - woltx 2022-10-11 07:02:47+00:00 - + 2025-09-26T14:20:49.484138+00:00 + python-feedgen + + + [bitcoin-dev] Silent Payment v4 (coinjoin support added) woltx + 2022-10-11T07:02:00.000Z + + + alicexbt + 2022-10-12T09:04:00.000Z + + + woltx + 2022-10-23T07:00:00.000Z + + + alicexbt + 2022-10-23T20:54:00.000Z + + - python-feedgen + 2 Combined summary - Silent Payment v4 (coinjoin support added) - 2023-08-02T08:03:59.669673+00:00 + 2025-09-26T14:20:49.484801+00:00 - The latest update to Silent Payment, version 4, brings several important changes and improvements. One of the key enhancements is the use of all inputs to create transactions, which not only increases privacy but also makes it compatible with coinjoin. The `getspaddress` RPC command has been renamed to `getsilentaddress` for better clarity.Another significant addition is the support for silent payment in PSBT through the `walletcreatefundedpsbt` RPC. This allows for a more seamless integration of silent payments into the Bitcoin network.Furthermore, a new index scheme has been introduced, storing the sum of input public keys for each transaction. As a result, the previous index `bitcoin/signet/indexes/silentpaymentindex` has become incompatible with this new version and has been removed.Silent payments now rely solely on publicly available transaction data on the blockchain, eliminating the vulnerability to rogue-key attacks that can be present in multi-party schemes.However, the implementation of the new scheme encountered an issue due to the lack of support for x-only public key sum by `bitcoin-core/secp256k1`, possibly because of a missing prefix byte. To address this, a pull request (#1143) has been opened to introduce a function that converts x-only public keys to compressed public keys with even y.The tutorial has also been updated to reflect these changes, ensuring users have access to accurate and up-to-date information on how to utilize the new features and improvements.In summary, Silent Payment v4 introduces comprehensive improvements to enhance privacy, compatibility with coinjoin, and overall functionality. Users are encouraged to update to this latest version to leverage these advancements and enjoy a more secure and efficient silent payment experience. 2022-10-23T20:54:26+00:00 + The latest update to Silent Payment, version 4, brings several important changes and improvements. One of the key enhancements is the use of all inputs to create transactions, which not only increases privacy but also makes it compatible with coinjoin. The `getspaddress` RPC command has been renamed to `getsilentaddress` for better clarity.Another significant addition is the support for silent payment in PSBT through the `walletcreatefundedpsbt` RPC. This allows for a more seamless integration of silent payments into the Bitcoin network.Furthermore, a new index scheme has been introduced, storing the sum of input public keys for each transaction. As a result, the previous index `bitcoin/signet/indexes/silentpaymentindex` has become incompatible with this new version and has been removed.Silent payments now rely solely on publicly available transaction data on the blockchain, eliminating the vulnerability to rogue-key attacks that can be present in multi-party schemes.However, the implementation of the new scheme encountered an issue due to the lack of support for x-only public key sum by `bitcoin-core/secp256k1`, possibly because of a missing prefix byte. To address this, a pull request (#1143) has been opened to introduce a function that converts x-only public keys to compressed public keys with even y.The tutorial has also been updated to reflect these changes, ensuring users have access to accurate and up-to-date information on how to utilize the new features and improvements.In summary, Silent Payment v4 introduces comprehensive improvements to enhance privacy, compatibility with coinjoin, and overall functionality. Users are encouraged to update to this latest version to leverage these advancements and enjoy a more secure and efficient silent payment experience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml b/static/bitcoin-dev/Oct_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml index 04c7b66823..9ce6567a95 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Taro-A-Taproot-Asset-Representation-Overlay.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Taro: A Taproot Asset Representation Overlay - 2023-08-02T05:59:12.664244+00:00 - - Johan Torås Halseth 2022-11-07 13:51:12+00:00 - - - Olaoluwa Osuntokun 2022-11-05 00:35:53+00:00 - - - Johan Torås Halseth 2022-11-03 09:26:05+00:00 - - - Olaoluwa Osuntokun 2022-10-19 02:40:13+00:00 - - - Olaoluwa Osuntokun 2022-04-16 02:43:08+00:00 - - - Ruben Somsen 2022-04-15 13:14:40+00:00 - - - Bram Cohen 2022-04-11 21:29:31+00:00 - - - Olaoluwa Osuntokun 2022-04-11 19:51:55+00:00 - - - Olaoluwa Osuntokun 2022-04-11 18:21:14+00:00 - - - Bram Cohen 2022-04-11 00:30:29+00:00 - - - Ruben Somsen 2022-04-10 16:51:52+00:00 - - - Olaoluwa Osuntokun 2022-04-08 17:49:28+00:00 - - - Olaoluwa Osuntokun 2022-04-08 17:48:02+00:00 - - - Alex Schoof 2022-04-07 19:11:39+00:00 - - - Ruben Somsen 2022-04-07 17:14:03+00:00 - - - ZmnSCPxj 2022-04-06 00:43:23+00:00 - - - vjudeu at gazeta.pl 2022-04-05 20:23:05+00:00 - - - Olaoluwa Osuntokun 2022-04-05 15:06:03+00:00 - + 2025-09-26T14:20:53.783473+00:00 + python-feedgen + + + [bitcoin-dev] Taro: A Taproot Asset Representation Overlay Olaoluwa Osuntokun + 2022-04-05T15:06:00.000Z + + + [bitcoin-dev] " vjudeu + 2022-04-05T20:23:00.000Z + + + ZmnSCPxj + 2022-04-06T00:43:00.000Z + + + Ruben Somsen + 2022-04-07T17:14:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Alex Schoof + 2022-04-07T19:11:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2022-04-08T17:48:00.000Z + + + Olaoluwa Osuntokun + 2022-04-08T17:49:00.000Z + + + Ruben Somsen + 2022-04-10T16:51:00.000Z + + + Bram Cohen + 2022-04-11T00:30:00.000Z + + + Olaoluwa Osuntokun + 2022-04-11T18:21:00.000Z + + + Olaoluwa Osuntokun + 2022-04-11T19:51:00.000Z + + + Bram Cohen + 2022-04-11T21:29:00.000Z + + + Ruben Somsen + 2022-04-15T13:14:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2022-04-16T02:43:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Olaoluwa Osuntokun + 2022-10-19T02:40:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Johan Torås Halseth + 2022-11-03T09:26:00.000Z + + + Olaoluwa Osuntokun + 2022-11-05T00:35:00.000Z + + + Johan Torås Halseth + 2022-11-07T13:51:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Taro: A Taproot Asset Representation Overlay - 2023-08-02T05:59:12.664244+00:00 + 2025-09-26T14:20:53.785320+00:00 - During a discussion about the "utxo teleport" scheme, Johan and Olaoluwa express their opinions on its soundness and compatibility with LN channels. Johan believes that as long as tokens are not sent to a spent UTXO, the scheme is sound. However, he agrees with Olaoluwa's concern about losing the blockchain as the main synchronization point. Olaoluwa argues that the scheme may not be sound because the UTXO may no longer exist when the transaction hits the chain, and there is no total ordering for safety.In contrast, Taro's state transition model ensures everything is bound to a single synchronization point and has re-org safety traits like regular Bitcoin transactions. Olaoluwa also points out that the "utxo teleport" scheme is not ideal for anchoring assets in channels. With Taro, assets are committed to the funding output when the channel is created, providing better visibility. Additionally, the "utxo teleport" scheme requires additional synchronization, while Taro creates an on-chain taproot output that directly creates the new asset anchor/output. The sender and receiver can use the blockchain itself as a synchronization point.Johan suggests adding a "teleport" feature to Taro, which would allow token transfer to already spent TXOs, burning the tokens. This feature could be beneficial for LN channels, enabling the addition or topping up of tokens in open channels with proof of token transfer.Ruben raises concerns about the RGB protocol, which he believes apply to Taro as well. He notes that the Taro script is not enforced by Bitcoin, so those controlling the Bitcoin script can choose to ignore the Taro script and destroy Taro assets. However, Ruben acknowledges that Taro's design predates RGB and seems to have inspired it.The email exchange discusses issues with verifying asset provenance in Taro's specifications. Hiroki Gondo points out the possibility of asset inflation if an illicit copy of a UTXO is created in the asset tree. Laolu acknowledges the issue and mentions that they aim to address it by assuming a "no-op" state transition in the current spec. Gondo suggests setting a constraint that only explicitly changed UTXOs should change, rather than generating proofs for every unchanging UTXO.Olaoluwa announces the Taro protocol, which uses the Taproot script tree and MS-SMT hybrid merkle tree for tokenization and asset issuance on the Bitcoin chain. They mention that Taro supports Lightning Network integration and efficient proofs of non-existence.The email exchange explores the feasibility of adding a scripting language to Taro. Ruben argues that using Bitcoin script without an additional scripting language inside Taro is sufficient. Olaoluwa proposes an "issuance covenant" design sketch for certain collateralization requirements, which Ruben acknowledges could be useful. They also discuss the deterministic location of the Taro tree in the taproot tree and propose solutions.In another email exchange, Bram Cohen and Olaoluwa discuss witnesses in transactions and the potential usage of the annex field in taproot transactions. They talk about implementing partial reveal of data in the annex field and the philosophical question of its reserved use. They also discuss Taro's single event issuance and the provision for future issuance associated with discrete IDs under a single identifier. They address the terminology used for Taro assets, preferring to use widely used asset issuance/minting terminology instead of "colored coins."The email exchange further discusses the potential scripting layer in Taro, including a design sketch for an "issuance covenant" and the usage of Bitcoin covenants to enforce spending conditions on Taro assets. The email acknowledges that there are still questions to answer regarding the feasibility of these ideas.The email exchange between Olaoluwa Osuntokun and Bram Cohen discusses the limitations and tradeoffs of the Taro system. Witnesses for transactions need to be put into Bitcoin transactions despite the Bitcoin layer not understanding them. There needs to be a constraint on Taro transactions that is understood by the Bitcoin layer. Taro issuance is limited to a single event rather than potentially multiple events subject to special per-asset rules. Multiple Taro coins cannot consolidate their value into a single output because they only support a single linear history. Despite these limitations, there is nothing wrong with a system having well-documented limitations.Ruben and Olaoluwa discuss the Taro documentation and its relationship with RGB. Ruben had a bad experience with RGB's documentation and suggests rebuilding Taro from scratch. However, he believes Taro should still credit RGB in its documentation. The limitations of Taro in building scripting support were also discussed, where only certain types of smart contracts could be built due to Bitcoin's limitations in enforcing them. The conversation moved on to ways in which both RGB and Taro can prevent double spending or duplicate assets. Ruben explains potential issues with Taro's system, such as asset issuers choosing to issue assets in denomin 2022-11-07T13:51:12+00:00 + During a discussion about the "utxo teleport" scheme, Johan and Olaoluwa express their opinions on its soundness and compatibility with LN channels. Johan believes that as long as tokens are not sent to a spent UTXO, the scheme is sound. However, he agrees with Olaoluwa's concern about losing the blockchain as the main synchronization point. Olaoluwa argues that the scheme may not be sound because the UTXO may no longer exist when the transaction hits the chain, and there is no total ordering for safety.In contrast, Taro's state transition model ensures everything is bound to a single synchronization point and has re-org safety traits like regular Bitcoin transactions. Olaoluwa also points out that the "utxo teleport" scheme is not ideal for anchoring assets in channels. With Taro, assets are committed to the funding output when the channel is created, providing better visibility. Additionally, the "utxo teleport" scheme requires additional synchronization, while Taro creates an on-chain taproot output that directly creates the new asset anchor/output. The sender and receiver can use the blockchain itself as a synchronization point.Johan suggests adding a "teleport" feature to Taro, which would allow token transfer to already spent TXOs, burning the tokens. This feature could be beneficial for LN channels, enabling the addition or topping up of tokens in open channels with proof of token transfer.Ruben raises concerns about the RGB protocol, which he believes apply to Taro as well. He notes that the Taro script is not enforced by Bitcoin, so those controlling the Bitcoin script can choose to ignore the Taro script and destroy Taro assets. However, Ruben acknowledges that Taro's design predates RGB and seems to have inspired it.The email exchange discusses issues with verifying asset provenance in Taro's specifications. Hiroki Gondo points out the possibility of asset inflation if an illicit copy of a UTXO is created in the asset tree. Laolu acknowledges the issue and mentions that they aim to address it by assuming a "no-op" state transition in the current spec. Gondo suggests setting a constraint that only explicitly changed UTXOs should change, rather than generating proofs for every unchanging UTXO.Olaoluwa announces the Taro protocol, which uses the Taproot script tree and MS-SMT hybrid merkle tree for tokenization and asset issuance on the Bitcoin chain. They mention that Taro supports Lightning Network integration and efficient proofs of non-existence.The email exchange explores the feasibility of adding a scripting language to Taro. Ruben argues that using Bitcoin script without an additional scripting language inside Taro is sufficient. Olaoluwa proposes an "issuance covenant" design sketch for certain collateralization requirements, which Ruben acknowledges could be useful. They also discuss the deterministic location of the Taro tree in the taproot tree and propose solutions.In another email exchange, Bram Cohen and Olaoluwa discuss witnesses in transactions and the potential usage of the annex field in taproot transactions. They talk about implementing partial reveal of data in the annex field and the philosophical question of its reserved use. They also discuss Taro's single event issuance and the provision for future issuance associated with discrete IDs under a single identifier. They address the terminology used for Taro assets, preferring to use widely used asset issuance/minting terminology instead of "colored coins."The email exchange further discusses the potential scripting layer in Taro, including a design sketch for an "issuance covenant" and the usage of Bitcoin covenants to enforce spending conditions on Taro assets. The email acknowledges that there are still questions to answer regarding the feasibility of these ideas.The email exchange between Olaoluwa Osuntokun and Bram Cohen discusses the limitations and tradeoffs of the Taro system. Witnesses for transactions need to be put into Bitcoin transactions despite the Bitcoin layer not understanding them. There needs to be a constraint on Taro transactions that is understood by the Bitcoin layer. Taro issuance is limited to a single event rather than potentially multiple events subject to special per-asset rules. Multiple Taro coins cannot consolidate their value into a single output because they only support a single linear history. Despite these limitations, there is nothing wrong with a system having well-documented limitations.Ruben and Olaoluwa discuss the Taro documentation and its relationship with RGB. Ruben had a bad experience with RGB's documentation and suggests rebuilding Taro from scratch. However, he believes Taro should still credit RGB in its documentation. The limitations of Taro in building scripting support were also discussed, where only certain types of smart contracts could be built due to Bitcoin's limitations in enforcing them. The conversation moved on to ways in which both RGB and Taro can prevent double spending or duplicate assets. Ruben explains potential issues with Taro's system, such as asset issuers choosing to issue assets in denomin - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Third-version-of-Silent-Payment-implementation.xml b/static/bitcoin-dev/Oct_2022/combined_Third-version-of-Silent-Payment-implementation.xml index 246c87f6f9..7c9bde68d1 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Third-version-of-Silent-Payment-implementation.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Third-version-of-Silent-Payment-implementation.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Third version of Silent Payment implementation - 2023-08-02T07:43:10.225110+00:00 - - Ruben Somsen 2022-10-03 23:41:10+00:00 - - - Ruben Somsen 2022-09-29 23:03:36+00:00 - - - woltx 2022-09-29 22:19:38+00:00 - + 2025-09-26T14:20:38.806518+00:00 + python-feedgen + + + [bitcoin-dev] Third version of Silent Payment implementation woltx + 2022-09-29T22:19:00.000Z + + + Ruben Somsen + 2022-09-29T23:03:00.000Z + + + Ruben Somsen + 2022-10-03T23:41:00.000Z + + - python-feedgen + 2 Combined summary - Third version of Silent Payment implementation - 2023-08-02T07:43:10.225110+00:00 + 2025-09-26T14:20:38.807072+00:00 - In a recent clarification provided by Ruben Somsen, the function of the identifier in bitcoin addresses was discussed. The purpose of this identifier is to distinguish why someone has made a payment to you. However, it is important to note that third-party observers are unable to link these payments on-chain and cannot determine which identifier was used. In situations where you do not want your identity to be revealed, the identifier alone is insufficient, and a separate Silent Payment address is required.Ruben also introduced a scheme that allows for multiple silent addresses per wallet with minimal overhead. This scheme enables the resulting address to be marked in a recognizable way, allowing the recipient to differentiate between different payment purposes. To implement this scheme, a public identifier "f" is added to a key when tweaking. It is essential to communicate this identifier to the sender, possibly as part of the address format. The new address format includes a field called "identifier," which guides both the receiver and sender in setting the address correctly. If the receiver is unaware of which identifiers have been used, the wallet can scan all identifiers from 0 to 99. Currently, each wallet is limited to using only 100 different identifiers, but this limit can be increased in the future if needed. Furthermore, a new RPC (Remote Procedure Call) has been implemented to retrieve silent addresses. Users are now able to assign different labels to their addresses, allowing them to identify which silent address a specific UTXO (Unspent Transaction Output) came from. This feature enhances usability and organization within the wallet. It should be noted that the newly introduced silent payment (SP) addresses are not script-related, which means they can potentially include additional information, such as an expiration timestamp or block height in the future. To assist users in understanding and implementing this scheme, a step-by-step tutorial has been provided on Github. This comprehensive tutorial serves as a reference guide for users interested in utilizing the new scheme proposed by Ruben Somsen. 2022-10-03T23:41:10+00:00 + In a recent clarification provided by Ruben Somsen, the function of the identifier in bitcoin addresses was discussed. The purpose of this identifier is to distinguish why someone has made a payment to you. However, it is important to note that third-party observers are unable to link these payments on-chain and cannot determine which identifier was used. In situations where you do not want your identity to be revealed, the identifier alone is insufficient, and a separate Silent Payment address is required.Ruben also introduced a scheme that allows for multiple silent addresses per wallet with minimal overhead. This scheme enables the resulting address to be marked in a recognizable way, allowing the recipient to differentiate between different payment purposes. To implement this scheme, a public identifier "f" is added to a key when tweaking. It is essential to communicate this identifier to the sender, possibly as part of the address format. The new address format includes a field called "identifier," which guides both the receiver and sender in setting the address correctly. If the receiver is unaware of which identifiers have been used, the wallet can scan all identifiers from 0 to 99. Currently, each wallet is limited to using only 100 different identifiers, but this limit can be increased in the future if needed. Furthermore, a new RPC (Remote Procedure Call) has been implemented to retrieve silent addresses. Users are now able to assign different labels to their addresses, allowing them to identify which silent address a specific UTXO (Unspent Transaction Output) came from. This feature enhances usability and organization within the wallet. It should be noted that the newly introduced silent payment (SP) addresses are not script-related, which means they can potentially include additional information, such as an expiration timestamp or block height in the future. To assist users in understanding and implementing this scheme, a step-by-step tutorial has been provided on Github. This comprehensive tutorial serves as a reference guide for users interested in utilizing the new scheme proposed by Ruben Somsen. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses-to-prevent-address-reuse.xml b/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses-to-prevent-address-reuse.xml index fdfcbe8bfb..8c17fce876 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses-to-prevent-address-reuse.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses-to-prevent-address-reuse.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Trustless Address Server – Outsourcing handing out addresses to prevent address reuse - 2023-08-02T07:42:25.308687+00:00 - - rot13maxi 2022-10-18 22:46:13+00:00 - - - Andrew Poelstra 2022-10-18 12:42:21+00:00 - - - Ruben Somsen 2022-10-18 12:40:38+00:00 - - - Bryan Bishop 2022-10-18 00:07:07+00:00 - - - rot13maxi 2022-10-17 23:26:15+00:00 - - - Ruben Somsen 2022-10-03 23:01:06+00:00 - - - David A. Harding 2022-10-02 22:48:21+00:00 - - - Ruben Somsen 2022-09-29 15:39:18+00:00 - + 2025-09-26T14:21:00.167264+00:00 + python-feedgen + + + [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse Ruben Somsen + 2022-09-29T15:39:00.000Z + + + David A. Harding + 2022-10-02T22:48:00.000Z + + + Ruben Somsen + 2022-10-03T23:01:00.000Z + + + rot13maxi + 2022-10-17T23:26:00.000Z + + + Bryan Bishop + 2022-10-18T00:07:00.000Z + + + Ruben Somsen + 2022-10-18T12:40:00.000Z + + + Andrew Poelstra + 2022-10-18T12:42:00.000Z + + + rot13maxi + 2022-10-18T22:46:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Trustless Address Server – Outsourcing handing out addresses to prevent address reuse - 2023-08-02T07:42:25.308687+00:00 + 2025-09-26T14:21:00.168107+00:00 - In a discussion on the bitcoin-dev mailing list, concerns were raised about the security of copy-pasting public keys. Andrew Poelstra clarified that the public key held by the wallet is only used for authentication and never leaves the wallet. He suggested that compromising the wallet's memory is much harder than compromising data on the clipboard. The proposal could even be implemented on a hardware wallet with an out-of-band way to obtain and authenticate public keys.Ruben Somsen proposed a method for recipients to sign their public keys for authentication purposes. However, Bryan Bishop pointed out the need for secure communication of the public key itself. Ruben suggested that whether or not Bob runs the Trustless Address Server himself is the meaningful distinction and proposed depositing signed keys to prevent malicious addresses from being distributed.A member named rot13maxi expressed concerns about clipboard hijacking, where the contents of the clipboard can be replaced with a malicious address without the user realizing it. Bryan Bishop highlighted that this problem also applies to copy-pasting public keys. The discussion emphasized the importance of verifying the accuracy of addresses and public keys before sending any funds.A developer proposed a setup where an address server provides fresh receive addresses to senders, improving privacy and address authentication. When a user wants to pay someone, their wallet asks the address server for an address, which is then signed and returned to ensure its authenticity. This allows the wallet to verify the intended recipient even if the data is intercepted. The developer suggested a protocol for interoperability between wallets and address servers.Another developer suggested an alternative solution involving submitting a transaction paying a placeholder address to the server and receiving a guaranteed unique address in return. If the transaction is not seen within a reasonable time, the server broadcasts the transaction paying the placeholder address. This approach is similar to the BIP78 payjoin protocol.Ruben thanked David for his suggestion and agreed on potential privacy reduction with placeholder transactions. David proposed an alternative method where the sender reveals their intended transaction to the server before receiving the address. This would prevent transaction replay attacks. Dave believes this approach satisfies all design constraints and is essentially the BIP78 payjoin protocol without payjoining.The post discusses a protocol for non-interactive distribution of bitcoin addresses, outsourcing interaction to third-party servers. The sender interacts with the server, which represents the recipient and provides an address from an xpub. One remaining challenge is the gap limit. An alternative mitigation involves revealing the intended transaction to the server before receiving the address. This protocol is useful for users wanting to use light clients, accept privacy degradation, and receive payments non-interactively. 2022-10-18T22:46:13+00:00 + In a discussion on the bitcoin-dev mailing list, concerns were raised about the security of copy-pasting public keys. Andrew Poelstra clarified that the public key held by the wallet is only used for authentication and never leaves the wallet. He suggested that compromising the wallet's memory is much harder than compromising data on the clipboard. The proposal could even be implemented on a hardware wallet with an out-of-band way to obtain and authenticate public keys.Ruben Somsen proposed a method for recipients to sign their public keys for authentication purposes. However, Bryan Bishop pointed out the need for secure communication of the public key itself. Ruben suggested that whether or not Bob runs the Trustless Address Server himself is the meaningful distinction and proposed depositing signed keys to prevent malicious addresses from being distributed.A member named rot13maxi expressed concerns about clipboard hijacking, where the contents of the clipboard can be replaced with a malicious address without the user realizing it. Bryan Bishop highlighted that this problem also applies to copy-pasting public keys. The discussion emphasized the importance of verifying the accuracy of addresses and public keys before sending any funds.A developer proposed a setup where an address server provides fresh receive addresses to senders, improving privacy and address authentication. When a user wants to pay someone, their wallet asks the address server for an address, which is then signed and returned to ensure its authenticity. This allows the wallet to verify the intended recipient even if the data is intercepted. The developer suggested a protocol for interoperability between wallets and address servers.Another developer suggested an alternative solution involving submitting a transaction paying a placeholder address to the server and receiving a guaranteed unique address in return. If the transaction is not seen within a reasonable time, the server broadcasts the transaction paying the placeholder address. This approach is similar to the BIP78 payjoin protocol.Ruben thanked David for his suggestion and agreed on potential privacy reduction with placeholder transactions. David proposed an alternative method where the sender reveals their intended transaction to the server before receiving the address. This would prevent transaction replay attacks. Dave believes this approach satisfies all design constraints and is essentially the BIP78 payjoin protocol without payjoining.The post discusses a protocol for non-interactive distribution of bitcoin addresses, outsourcing interaction to third-party servers. The sender interacts with the server, which represents the recipient and provides an address from an xpub. One remaining challenge is the gap limit. An alternative mitigation involves revealing the intended transaction to the server before receiving the address. This protocol is useful for users wanting to use light clients, accept privacy degradation, and receive payments non-interactively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml b/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml index 13d8bb89e2..c0526faafd 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Trustless Address Server ? Outsourcing handing out addresses - 2023-08-02T07:43:42.662902+00:00 + 2025-09-26T14:20:36.693810+00:00 + python-feedgen Ruben Somsen 2022-10-01 10:18:49+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Trustless Address Server ? Outsourcing handing out addresses - 2023-08-02T07:43:42.662902+00:00 + 2025-09-26T14:20:36.693972+00:00 - In an email exchange on the bitcoin-dev mailing list, Ruben and Peter discussed various topics related to Bitcoin addresses. Ruben suggested that distributing xpubs could potentially reduce the gap limit for generated addresses since there would be less reason to expect a gap if those addresses are used by the same person. He shared a link to a related thread for further reference.Peter contributed to the discussion by highlighting some points worth considering. He mentioned that handing out xpubs can create a quadratic gap limit problem, where wallets need to scan multiple xpubs and their receive addresses. However, in the Lightning network, this issue can be avoided by utilizing Lightning addresses that employ plus addresses. This alternative approach proves to be effective in addressing the problem.Another topic of discussion was the need for an expiry date on layer 1 addresses to ensure that the receiver still possesses the corresponding keys. Peter pointed out that the Lightning network offers a solution to this concern as well.Furthermore, the conversation delved into the possibility of using a deterministic path that doesn't separate receive and change addresses. Satoshi's original wallet concept proposed an ever-growing key pool with a 100 address gap, which may serve as a potential solution to the gap limit problem.As the discussion continued, the idea of incorporating invoice functionality into wallets arose. This feature would allow wallets to issue fresh addresses even if they haven't been used, while also providing a configurable gap limit. Additionally, embedding a sunset date in the address format, similar to PGP keys, was suggested as a means to enable address expiry for layer 1 addresses.Overall, these discussions surrounding xpubs, invoice functionality, and address expiration are crucial considerations for businesses and individuals engaged in Bitcoin transactions. The Lightning network presents viable solutions to some of these concerns, and concepts such as an ever-growing key pool and configurable gap limits show promise in addressing the gap limit problem. 2022-10-01T10:18:49+00:00 + In an email exchange on the bitcoin-dev mailing list, Ruben and Peter discussed various topics related to Bitcoin addresses. Ruben suggested that distributing xpubs could potentially reduce the gap limit for generated addresses since there would be less reason to expect a gap if those addresses are used by the same person. He shared a link to a related thread for further reference.Peter contributed to the discussion by highlighting some points worth considering. He mentioned that handing out xpubs can create a quadratic gap limit problem, where wallets need to scan multiple xpubs and their receive addresses. However, in the Lightning network, this issue can be avoided by utilizing Lightning addresses that employ plus addresses. This alternative approach proves to be effective in addressing the problem.Another topic of discussion was the need for an expiry date on layer 1 addresses to ensure that the receiver still possesses the corresponding keys. Peter pointed out that the Lightning network offers a solution to this concern as well.Furthermore, the conversation delved into the possibility of using a deterministic path that doesn't separate receive and change addresses. Satoshi's original wallet concept proposed an ever-growing key pool with a 100 address gap, which may serve as a potential solution to the gap limit problem.As the discussion continued, the idea of incorporating invoice functionality into wallets arose. This feature would allow wallets to issue fresh addresses even if they haven't been used, while also providing a configurable gap limit. Additionally, embedding a sunset date in the address format, similar to PGP keys, was suggested as a means to enable address expiry for layer 1 addresses.Overall, these discussions surrounding xpubs, invoice functionality, and address expiration are crucial considerations for businesses and individuals engaged in Bitcoin transactions. The Lightning network presents viable solutions to some of these concerns, and concepts such as an ever-growing key pool and configurable gap limits show promise in addressing the gap limit problem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Validity-Rollups-on-Bitcoin.xml b/static/bitcoin-dev/Oct_2022/combined_Validity-Rollups-on-Bitcoin.xml index 55ee87c93b..2cc783755c 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Validity-Rollups-on-Bitcoin.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Validity-Rollups-on-Bitcoin.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Validity Rollups on Bitcoin - 2023-08-02T08:05:02.174011+00:00 - - ZmnSCPxj 2022-11-04 23:07:56+00:00 - - - Russell O'Connor 2022-11-04 20:29:26+00:00 - - - Trey Del Bonis 2022-11-04 19:53:31+00:00 - - - AdamISZ 2022-11-02 17:19:23+00:00 - - - John Light 2022-10-12 15:40:10+00:00 - - - Greg Sanders 2022-10-12 13:28:22+00:00 - - - John Light 2022-10-11 15:40:52+00:00 - + 2025-09-26T14:20:58.049585+00:00 + python-feedgen + + + [bitcoin-dev] Validity Rollups on Bitcoin John Light + 2022-10-11T15:40:00.000Z + + + Greg Sanders + 2022-10-12T13:28:00.000Z + + + John Light + 2022-10-12T15:40:00.000Z + + + AdamISZ + 2022-11-02T17:19:00.000Z + + + Trey Del Bonis + 2022-11-04T19:53:00.000Z + + + Russell O'Connor + 2022-11-04T20:29:00.000Z + + + ZmnSCPxj + 2022-11-04T23:07:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Validity Rollups on Bitcoin - 2023-08-02T08:05:02.174011+00:00 + 2025-09-26T14:20:58.050535+00:00 - ZmnSCPxj has proposed the implementation of new opcodes in Taproot to improve efficiency and avoid duplicating data in the witness. One potential opcode is a form of OP_MERKLEUPDATEVERIFY that checks a merkle proof against a root and verifies if replacing the leaf with some hash using the proof yields a specified updated root. Another proposal is a limited version of OP_EVAL for cases where different spend paths cannot be split into different tapleafs.ZmnSCPxj suggests reusing pay-to-contract to store a commitment to the state in Taproot. This involves using the Taproot outpoint script as the public key corresponding to the pay-to-contract of the Taproot MAST root and an internal public key. The internal public key can also be a pay-to-contract, allowing for the commitment of a covenant state. This proposed opcode would determine if the internal public key is a pay-to-contract of the current state on the internal-internal pubkey. If an expected new state exists, it would compute a new Taproot internal pubkey and recomputes the pay-to-contract on the new state. This approach eliminates the need for quining and OP_PUSHSCRIPT, only requiring a way to compute the new state from the old state.Trey Del Bonis discusses the idea of using granular transaction introspection opcodes from Elements for rollups. He acknowledges that the actual proof verification process is complex and suggests implementing a specific opcode for more efficient proof verification. This opcode would take the serialized proof, a verification key, and the public input as separate stack items. The public input includes various commitments and data from the transaction outputs, and the rollup batch data itself. Trey also expresses interest in Simplicity Jets that facilitate rollups, particularly pairing-friendly curve operations.The conversation between AdamISZ/waxwing and John Light explores the minimal functionality required for general-purpose off-chain contracting that is provable. They discuss the verification of bilinear pairings on-chain and the use of a covenant opcode for implementing rollups/sidechains with client-side computation and compact state update. They also touch on the security models of Optimism and Arbitrum, as well as the use of trusted setups in different security models.Greg Sanders inquired about a concise cheat sheet for transaction introspection/OP_ZKP and their uses in different rollup architectures. While such a cheat sheet does not exist yet, Trey Del Bonis has written a detailed technical post on how these components can be used in a validity rollup. However, more research and design work are needed to provide the requested details.John Light's report titled "Validity Rollups on Bitcoin" explores the benefits of validity rollups for Bitcoin and existing layer two protocols like the Lightning Network. The report examines the history, technical workings, and potential risks and benefits of implementing validity rollups on Bitcoin, highlighting their potential to improve scalability, privacy, and programmability without compromising Bitcoin's core values. The full report can be found at bitcoinrollups.org, and feedback from the Bitcoin dev community is welcomed.In summary, there are ongoing discussions and proposals regarding the implementation of new opcodes in Taproot to enhance efficiency and avoid data duplication. Transaction introspection opcodes from Elements are being considered for rollups, along with the need for efficient proof verification. The conversation also touches on security models, trusted setups, and the potential benefits of validity rollups for Bitcoin. John Light's report provides a comprehensive examination of validity rollups and their potential impact on Bitcoin's scalability, privacy, and programmability. 2022-11-04T23:07:56+00:00 + ZmnSCPxj has proposed the implementation of new opcodes in Taproot to improve efficiency and avoid duplicating data in the witness. One potential opcode is a form of OP_MERKLEUPDATEVERIFY that checks a merkle proof against a root and verifies if replacing the leaf with some hash using the proof yields a specified updated root. Another proposal is a limited version of OP_EVAL for cases where different spend paths cannot be split into different tapleafs.ZmnSCPxj suggests reusing pay-to-contract to store a commitment to the state in Taproot. This involves using the Taproot outpoint script as the public key corresponding to the pay-to-contract of the Taproot MAST root and an internal public key. The internal public key can also be a pay-to-contract, allowing for the commitment of a covenant state. This proposed opcode would determine if the internal public key is a pay-to-contract of the current state on the internal-internal pubkey. If an expected new state exists, it would compute a new Taproot internal pubkey and recomputes the pay-to-contract on the new state. This approach eliminates the need for quining and OP_PUSHSCRIPT, only requiring a way to compute the new state from the old state.Trey Del Bonis discusses the idea of using granular transaction introspection opcodes from Elements for rollups. He acknowledges that the actual proof verification process is complex and suggests implementing a specific opcode for more efficient proof verification. This opcode would take the serialized proof, a verification key, and the public input as separate stack items. The public input includes various commitments and data from the transaction outputs, and the rollup batch data itself. Trey also expresses interest in Simplicity Jets that facilitate rollups, particularly pairing-friendly curve operations.The conversation between AdamISZ/waxwing and John Light explores the minimal functionality required for general-purpose off-chain contracting that is provable. They discuss the verification of bilinear pairings on-chain and the use of a covenant opcode for implementing rollups/sidechains with client-side computation and compact state update. They also touch on the security models of Optimism and Arbitrum, as well as the use of trusted setups in different security models.Greg Sanders inquired about a concise cheat sheet for transaction introspection/OP_ZKP and their uses in different rollup architectures. While such a cheat sheet does not exist yet, Trey Del Bonis has written a detailed technical post on how these components can be used in a validity rollup. However, more research and design work are needed to provide the requested details.John Light's report titled "Validity Rollups on Bitcoin" explores the benefits of validity rollups for Bitcoin and existing layer two protocols like the Lightning Network. The report examines the history, technical workings, and potential risks and benefits of implementing validity rollups on Bitcoin, highlighting their potential to improve scalability, privacy, and programmability without compromising Bitcoin's core values. The full report can be found at bitcoinrollups.org, and feedback from the Bitcoin dev community is welcomed.In summary, there are ongoing discussions and proposals regarding the implementation of new opcodes in Taproot to enhance efficiency and avoid data duplication. Transaction introspection opcodes from Elements are being considered for rollups, along with the need for efficient proof verification. The conversation also touches on security models, trusted setups, and the potential benefits of validity rollups for Bitcoin. John Light's report provides a comprehensive examination of validity rollups and their potential impact on Bitcoin's scalability, privacy, and programmability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_bitcoin-inquistion-evaluating-soft-forks-on-signet.xml b/static/bitcoin-dev/Oct_2022/combined_bitcoin-inquistion-evaluating-soft-forks-on-signet.xml index 18a1f112ff..38234d3fcf 100644 --- a/static/bitcoin-dev/Oct_2022/combined_bitcoin-inquistion-evaluating-soft-forks-on-signet.xml +++ b/static/bitcoin-dev/Oct_2022/combined_bitcoin-inquistion-evaluating-soft-forks-on-signet.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - bitcoin-inquistion: evaluating soft forks on signet - 2023-08-02T07:24:40.953699+00:00 - - Anthony Towns 2022-10-03 22:54:04+00:00 - - - Michael Folkson 2022-10-02 15:25:19+00:00 - - - Anthony Towns 2022-10-02 06:12:10+00:00 - - - Anthony Towns 2022-10-02 04:06:54+00:00 - - - alicexbt 2022-09-28 20:01:46+00:00 - - - Michael Folkson 2022-09-28 11:48:32+00:00 - - - Anthony Towns 2022-09-19 10:05:47+00:00 - - - Antoine Riard 2022-09-18 18:47:38+00:00 - - - Michael Folkson 2022-09-18 18:44:31+00:00 - - - alicexbt 2022-09-18 12:27:43+00:00 - - - Michael Folkson 2022-09-17 15:53:48+00:00 - - - Matt Corallo 2022-09-17 08:39:07+00:00 - - - Anthony Towns 2022-09-17 06:14:05+00:00 - - - Matt Corallo 2022-09-16 16:46:53+00:00 - - - Anthony Towns 2022-09-16 07:15:45+00:00 - + 2025-09-26T14:21:02.318251+00:00 + python-feedgen + + + [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet Anthony Towns + 2022-09-16T07:15:00.000Z + + + Matt Corallo + 2022-09-16T16:46:00.000Z + + + Anthony Towns + 2022-09-17T06:14:00.000Z + + + Matt Corallo + 2022-09-17T08:39:00.000Z + + + Michael Folkson + 2022-09-17T15:53:00.000Z + + + alicexbt + 2022-09-18T12:27:00.000Z + + + Michael Folkson + 2022-09-18T18:44:00.000Z + + + Antoine Riard + 2022-09-18T18:47:00.000Z + + + Anthony Towns + 2022-09-19T10:05:00.000Z + + + Michael Folkson + 2022-09-28T11:48:00.000Z + + + alicexbt + 2022-09-28T20:01:00.000Z + + + Anthony Towns + 2022-10-02T04:06:00.000Z + + + Anthony Towns + 2022-10-02T06:12:00.000Z + + + Michael Folkson + 2022-10-02T15:25:00.000Z + + + Anthony Towns + 2022-10-03T22:54:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - bitcoin-inquistion: evaluating soft forks on signet - 2023-08-02T07:24:40.953699+00:00 + 2025-09-26T14:21:02.320113+00:00 - In an email thread on Bitcoin-dev, developers discussed the challenges of progressing soft fork proposals in Bitcoin. While some believe the current process is sufficient, others argue for more testing and evaluation before implementation. One suggestion is to experiment with soft forks on signet, which would allow for multiple consensus changes to be deployed and compared. Signet also has more activity than Liquid, making it a better testing ground. The community also discussed upgrades like APO/eltoo and Simplicity, as well as Antoine's covenant R&D effort.The lack of champions for soft forks was identified as a major issue. Matt Corallo disagreed with the idea that testing frameworks were the problem, stating that the lack of champions following all the necessary steps was the main obstacle. He emphasized that being a champion is a full-time job that requires months of attention. He encouraged those interested in contributing to Core and becoming a champion to seek mentorship. The group recognized the need for humility, confidence, interest, and time to move forward with soft forks.The importance of finding champions for proposed upgrades like CheckTemplateVerify (CTV) was also discussed. Critics pointed out the lack of a champion for CTV's implementation. Corallo argued that having only one author on the list did not constitute a completed step three. He suggested that the lack of progress could be due to issues with step four, the evaluation process, or the difficulty of steps two and three. He stressed the need for exploration, development, and research into covenants, as well as fostering a community open to new ideas while avoiding chain split fights.Matt Corallo posted a message on the bitcoin-dev mailing list, encouraging contributions towards Bitcoin's Taproot upgrade. He highlighted the importance of community involvement and mentioned that many people would be willing to mentor those interested in contributing. Taproot aims to improve privacy, scalability, and security by enhancing Bitcoin's scripting language.The email exchange between Anthony Towns and Matt Corallo discussed the process of progressing soft forks in Bitcoin. Corallo outlined a four-step process involving idea generation, socialization, proposal, and finding champions. Towns argued that the lack of progress on the great consensus cleanup indicated issues with the process. Corallo disagreed, stating that potential champions were deterred by the time-consuming nature of the role. He encouraged interested individuals to reach out for mentorship.The email thread on bitcoin-dev also addressed the difficulty of getting soft fork ideas from concept to deployment. The discussion touched on various topics, including the lack of community consensus, the potential of signet for testing proposed changes, and the importance of finding champions to push ideas forward. Matt Corallo disagreed with the notion that lack of test frameworks was a significant issue and emphasized the need for champions. The thread provided links to relevant discussions and alternative approaches to soft forks.In summary, the email thread discusses the pressure to merge unfinished or buggy soft fork proposals on the default signet and the need for proper evaluation and testing. Various suggestions are made, including using custom public signets, deploying bitcoin-inquisition on the default global signet, and implementing prototypes for evaluation. The importance of multiple developers and researchers reviewing pull requests and the ongoing evaluation of creative ideas in Bitcoin development are also emphasized.The article discussed the challenges faced in activating soft forks on Bitcoin and proposed a new approach. It suggested deploying soft forks on the default global signet to demonstrate their value but acknowledged the conundrum of activation without merging into Bitcoin Core. A fork called "bitcoin-inquisition" was proposed to add support for consensus changes, allowing miners to coordinate upgrades and avoiding the promotion of proposals by miners/maintainers. Overall, the proposal offered a solution to the challenges of activating soft forks on Bitcoin. 2022-10-03T22:54:04+00:00 + In an email thread on Bitcoin-dev, developers discussed the challenges of progressing soft fork proposals in Bitcoin. While some believe the current process is sufficient, others argue for more testing and evaluation before implementation. One suggestion is to experiment with soft forks on signet, which would allow for multiple consensus changes to be deployed and compared. Signet also has more activity than Liquid, making it a better testing ground. The community also discussed upgrades like APO/eltoo and Simplicity, as well as Antoine's covenant R&D effort.The lack of champions for soft forks was identified as a major issue. Matt Corallo disagreed with the idea that testing frameworks were the problem, stating that the lack of champions following all the necessary steps was the main obstacle. He emphasized that being a champion is a full-time job that requires months of attention. He encouraged those interested in contributing to Core and becoming a champion to seek mentorship. The group recognized the need for humility, confidence, interest, and time to move forward with soft forks.The importance of finding champions for proposed upgrades like CheckTemplateVerify (CTV) was also discussed. Critics pointed out the lack of a champion for CTV's implementation. Corallo argued that having only one author on the list did not constitute a completed step three. He suggested that the lack of progress could be due to issues with step four, the evaluation process, or the difficulty of steps two and three. He stressed the need for exploration, development, and research into covenants, as well as fostering a community open to new ideas while avoiding chain split fights.Matt Corallo posted a message on the bitcoin-dev mailing list, encouraging contributions towards Bitcoin's Taproot upgrade. He highlighted the importance of community involvement and mentioned that many people would be willing to mentor those interested in contributing. Taproot aims to improve privacy, scalability, and security by enhancing Bitcoin's scripting language.The email exchange between Anthony Towns and Matt Corallo discussed the process of progressing soft forks in Bitcoin. Corallo outlined a four-step process involving idea generation, socialization, proposal, and finding champions. Towns argued that the lack of progress on the great consensus cleanup indicated issues with the process. Corallo disagreed, stating that potential champions were deterred by the time-consuming nature of the role. He encouraged interested individuals to reach out for mentorship.The email thread on bitcoin-dev also addressed the difficulty of getting soft fork ideas from concept to deployment. The discussion touched on various topics, including the lack of community consensus, the potential of signet for testing proposed changes, and the importance of finding champions to push ideas forward. Matt Corallo disagreed with the notion that lack of test frameworks was a significant issue and emphasized the need for champions. The thread provided links to relevant discussions and alternative approaches to soft forks.In summary, the email thread discusses the pressure to merge unfinished or buggy soft fork proposals on the default signet and the need for proper evaluation and testing. Various suggestions are made, including using custom public signets, deploying bitcoin-inquisition on the default global signet, and implementing prototypes for evaluation. The importance of multiple developers and researchers reviewing pull requests and the ongoing evaluation of creative ideas in Bitcoin development are also emphasized.The article discussed the challenges faced in activating soft forks on Bitcoin and proposed a new approach. It suggested deploying soft forks on the default global signet to demonstrate their value but acknowledged the conundrum of activation without merging into Bitcoin Core. A fork called "bitcoin-inquisition" was proposed to add support for consensus changes, allowing miners to coordinate upgrades and avoiding the promotion of proposals by miners/maintainers. Overall, the proposal offered a solution to the challenges of activating soft forks on Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_brickchain.xml b/static/bitcoin-dev/Oct_2022/combined_brickchain.xml index ab68c81c7e..47f1e32dfb 100644 --- a/static/bitcoin-dev/Oct_2022/combined_brickchain.xml +++ b/static/bitcoin-dev/Oct_2022/combined_brickchain.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - brickchain - 2023-08-02T08:15:48.234195+00:00 - - mm-studios 2022-11-08 16:31:15+00:00 - - - Erik Aronesty 2022-11-08 15:49:10+00:00 - - - mm-studios 2022-11-08 14:25:04+00:00 - - - Erik Aronesty 2022-11-08 14:16:41+00:00 - - - mm-studios 2022-10-19 22:53:54+00:00 - - - mm-studios 2022-10-19 22:47:43+00:00 - - - G. Andrew Stone 2022-10-19 21:34:43+00:00 - - - mm-studios 2022-10-19 16:03:45+00:00 - - - Erik Aronesty 2022-10-19 14:24:48+00:00 - - - Bryan Bishop 2022-10-19 13:54:11+00:00 - - - angus 2022-10-19 13:40:35+00:00 - - - mm-studios 2022-10-19 09:04:50+00:00 - + 2025-09-26T14:20:51.631206+00:00 + python-feedgen + + + [bitcoin-dev] brickchain mm-studios + 2022-10-19T09:04:00.000Z + + + angus + 2022-10-19T13:40:00.000Z + + + Bryan Bishop + 2022-10-19T13:54:00.000Z + + + Erik Aronesty + 2022-10-19T14:24:00.000Z + + + mm-studios + 2022-10-19T16:03:00.000Z + + + G. Andrew Stone + 2022-10-19T21:34:00.000Z + + + mm-studios + 2022-10-19T22:47:00.000Z + + + mm-studios + 2022-10-19T22:53:00.000Z + + + Erik Aronesty + 2022-11-08T14:16:00.000Z + + + mm-studios + 2022-11-08T14:25:00.000Z + + + Erik Aronesty + 2022-11-08T15:49:00.000Z + + + mm-studios + 2022-11-08T16:31:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - brickchain - 2023-08-02T08:15:48.235232+00:00 + 2025-09-26T14:20:51.632727+00:00 - The author proposes a novel approach to enhance the speed of transactions in the Bitcoin network by modifying the Proof of Work (PoW) algorithm. Currently, the network's capacity is limited by the size of blocks produced by miners. Although some suggested removing these limits, it was widely rejected due to unfavorable consequences.To address this issue, the author introduces the concept of a 'brick', which aims to maintain small blocks while accommodating all transactions. A brick is essentially a block that does not meet the difficulty rule but is filled with transactions up to its maximum capacity. Once a brick is completely filled, it would be broadcasted, and the miner would proceed to work on a new brick connected to the previous one.Nodes within the network would accept incoming regular blocks as well as bricks with hashes that fail to satisfy the difficulty rule, under the condition that the brick is fully filled. If a series of minimum hashes is computationally equivalent to the network difficulty, then the entire 'brickchain' is considered valid as a block.Implementing this approach could effectively reduce the backlog of unconfirmed transactions (mempools), maintain low transaction fees, and ultimately enhance the network's throughput without the need for increasing the block size. However, there are potential concerns surrounding the determination of brick validity, the allocation of block rewards, distribution of fees, and integration of the brick sidechain into the main blockchain.In an email discussing the proposal, the author also mentions the importance of layer 2 protocols like MWEB, which allow holding and transferring uncommitted transactions as pools or joins. The email emphasizes the need to avoid increasing the workload of full-nodes and undermining layer 2 systems like the Lightning Network (LN). Layered financial systems, such as L3 projects like TARO and RGB, are considered superior in terms of layered financial systems.The email concludes by acknowledging that more work needs to be done to refine the proposal and determine its feasibility. The author recognizes the need for changes in the PoW algorithm and a better calculus to define the proposal. It is clear that increasing the throughput without increasing the block size is a primary goal, and the proposal aims to achieve this by introducing the concept of bricks and validating them as blocks within a brickchain. 2022-11-08T16:31:15+00:00 + The author proposes a novel approach to enhance the speed of transactions in the Bitcoin network by modifying the Proof of Work (PoW) algorithm. Currently, the network's capacity is limited by the size of blocks produced by miners. Although some suggested removing these limits, it was widely rejected due to unfavorable consequences.To address this issue, the author introduces the concept of a 'brick', which aims to maintain small blocks while accommodating all transactions. A brick is essentially a block that does not meet the difficulty rule but is filled with transactions up to its maximum capacity. Once a brick is completely filled, it would be broadcasted, and the miner would proceed to work on a new brick connected to the previous one.Nodes within the network would accept incoming regular blocks as well as bricks with hashes that fail to satisfy the difficulty rule, under the condition that the brick is fully filled. If a series of minimum hashes is computationally equivalent to the network difficulty, then the entire 'brickchain' is considered valid as a block.Implementing this approach could effectively reduce the backlog of unconfirmed transactions (mempools), maintain low transaction fees, and ultimately enhance the network's throughput without the need for increasing the block size. However, there are potential concerns surrounding the determination of brick validity, the allocation of block rewards, distribution of fees, and integration of the brick sidechain into the main blockchain.In an email discussing the proposal, the author also mentions the importance of layer 2 protocols like MWEB, which allow holding and transferring uncommitted transactions as pools or joins. The email emphasizes the need to avoid increasing the workload of full-nodes and undermining layer 2 systems like the Lightning Network (LN). Layered financial systems, such as L3 projects like TARO and RGB, are considered superior in terms of layered financial systems.The email concludes by acknowledging that more work needs to be done to refine the proposal and determine its feasibility. The author recognizes the need for changes in the PoW algorithm and a better calculus to define the proposal. It is clear that increasing the throughput without increasing the block size is a primary goal, and the proposal aims to achieve this by introducing the concept of bricks and validating them as blocks within a brickchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Actuarial-System-To-Reduce-Interactivity-In-N-of-N-N-2-Multiparticipant-Offchain-Mechanisms.xml b/static/bitcoin-dev/Oct_2023/combined_Actuarial-System-To-Reduce-Interactivity-In-N-of-N-N-2-Multiparticipant-Offchain-Mechanisms.xml index e7a9f6c413..67a93e5003 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Actuarial-System-To-Reduce-Interactivity-In-N-of-N-N-2-Multiparticipant-Offchain-Mechanisms.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Actuarial-System-To-Reduce-Interactivity-In-N-of-N-N-2-Multiparticipant-Offchain-Mechanisms.xml @@ -1,51 +1,63 @@ - + 2 Combined summary - Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms - 2023-11-01T20:04:06.010074+00:00 - - AdamISZ 2023-10-31 22:12:20+00:00 - - - Antoine Riard 2023-10-05 02:12:33+00:00 - - - ZmnSCPxj 2023-09-12 09:41:18+00:00 - - - Antoine Riard 2023-09-11 06:02:13+00:00 - - - ZmnSCPxj 2023-09-09 01:27:38+00:00 - + 2025-09-26T14:22:04.327939+00:00 + python-feedgen + + + [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms ZmnSCPxj + 2023-09-09T01:27:00.000Z + + + Antoine Riard + 2023-09-11T06:02:00.000Z + + + ZmnSCPxj + 2023-09-12T09:41:00.000Z + + + David A. Harding + 2023-09-18T00:12:00.000Z + + + ZmnSCPxj + 2023-09-18T03:37:00.000Z + + + Antoine Riard + 2023-10-05T02:12:00.000Z + + + ZmnSCPxj + 2023-10-15T13:36:00.000Z + + + AdamISZ + 2023-10-31T22:12:00.000Z + + - python-feedgen + 2 Combined summary - Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms - 2023-11-01T20:04:06.010074+00:00 + 2025-09-26T14:22:04.328960+00:00 + 2023-10-31T22:12:20+00:00 The email discusses various aspects related to off-chain mechanisms in blockchain technology, specifically focusing on the Bitcoin blockchain. The sender introduces the concept of an actuary role, similar to miners in the blockchain, who are responsible for deciding transaction ordering without having custody of funds. Two proposed softforks, namely `SIGHASH_ANYPREVOUT` and `OP_CHECKSEPARATEDSIG`, are suggested to enable this actuary role. - The advantages of using an N-of-N signatory set in off-chain mechanisms are highlighted, providing consensus and preventing a majority from forcing movement of funds against a participant's will. However, it is noted that all participants need to be online to sign a new state, which can stall the protocol if one participant is offline. - -The concept of an off-chain "mempool" is introduced, where the state of the mechanism is considered as pairs of Bitcoin SCRIPT and satoshis, instantiated as actual transaction outputs. Participants can create transactions within the current state and send money to each other, but these transactions remain unconfirmed until they are signed off by all participants. - +The concept of an off-chain "mempool" is introduced, where the state of the mechanism is considered as pairs of Bitcoin SCRIPT and satoshis, instantiated as actual transaction outputs. Participants can create transactions within the current state and send money to each other, but these transactions remain unconfirmed until they are signed off by all participants. To address the confirmation issue without custodianship, the email suggests adding the actuary to the contract controlling the funds with a specific `R` value, preventing `R` reuse and enforcing single-spend. This ensures non-custodiality while maintaining an N-of-N requirement for spending. - The desired properties for the actuary role are highlighted, including the ability to select one transaction, inability to spend funds unilaterally or hold them hostage, and assurance that participants can drop the mechanism on-chain and recover their funds if the actuary stops responding. A suggested method to ensure these properties is infecting the SCRIPT of all outputs with `(sign-only-once(M) || CSV) && C`. - -The email also discusses the `SIGHASH_ANYPREVOUT` feature in Bitcoin transactions and its relationship to the actuary role. With `SIGHASH_ANYPREVOUT`, participants can confirm transactions "confirmed" by the actuary even if the actual transaction ID changes. - +The email also discusses the `SIGHASH_ANYPREVOUT` feature in Bitcoin transactions and its relationship to the actuary role. With `SIGHASH_ANYPREVOUT`, participants can confirm transactions "confirmed" by the actuary even if the actual transaction ID changes. An example scenario is provided to illustrate the proposed mechanism, involving three participants (A, B, C) and an actuary (M). Each participant has a base contract, and the actuary signs transactions using a fixed `R` nonce. When A wants to send money to B, they create a transaction with two new outputs. A solicits a single-spend signature from the actuary to ensure B's assurance against double-spending. If dropped on-chain, the confirmed transaction can be immediately confirmed on-chain as well. - To update the state of the mechanism, the actuary proposes a new state to each participant. Participants only need to validate expected outputs, reducing bandwidth requirements and providing a scaling advantage. All participants must sign off on each state update, preventing invalid states and dropping the current state on-chain if needed. - Custodial solutions are avoided in this design to minimize control over coins. The actuary role only confirms transactions and cannot move funds without consent, ensuring consensus from all participants. Participants can go offline and online while the actuary coordinates new states. - 2023-10-31T22:12:20+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml b/static/bitcoin-dev/Oct_2023/combined_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml index d9bca01b84..70d5d41300 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml @@ -1,68 +1,47 @@ - + 2 Combined summary - Batch exchange withdrawal to lightning requires covenants - 2023-11-01T20:42:42.138977+00:00 - - Bastien TEINTURIER 2023-10-24 08:09:45+00:00 - - - David A. Harding 2023-10-24 04:41:34+00:00 - - - Antoine Riard 2023-10-19 17:09:51+00:00 - - - Antoine Riard 2023-10-19 17:09:51+00:00 - - - Bastien TEINTURIER 2023-10-19 07:35:23+00:00 - - - Bastien TEINTURIER 2023-10-19 07:35:23+00:00 - - - Antoine Riard 2023-10-18 18:03:48+00:00 - - - Antoine Riard 2023-10-18 18:03:48+00:00 - - - Bastien TEINTURIER 2023-10-18 14:35:40+00:00 - - - Bastien TEINTURIER 2023-10-18 14:35:40+00:00 - - - Antoine Riard 2023-10-17 19:10:40+00:00 - - - Antoine Riard 2023-10-17 19:10:40+00:00 - - - ZmnSCPxj 2023-10-17 17:17:04+00:00 - - - ZmnSCPxj 2023-10-17 17:17:04+00:00 - - - Greg Sanders 2023-10-17 17:10:42+00:00 - - - Greg Sanders 2023-10-17 17:10:42+00:00 - - - ZmnSCPxj 2023-10-17 17:04:06+00:00 - - - ZmnSCPxj 2023-10-17 17:04:06+00:00 - - - Bastien TEINTURIER 2023-10-17 13:03:05+00:00 - - - Bastien TEINTURIER 2023-10-17 13:03:05+00:00 - + 2025-09-26T14:21:40.873149+00:00 + python-feedgen + + + [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants Bastien TEINTURIER + 2023-10-17T13:03:00.000Z + + + ZmnSCPxj + 2023-10-17T17:04:00.000Z + + + Greg Sanders + 2023-10-17T17:10:00.000Z + + + ZmnSCPxj + 2023-10-17T17:17:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Antoine Riard + 2023-10-17T19:10:00.000Z + + + Bastien TEINTURIER + 2023-10-18T14:35:00.000Z + + + Antoine Riard + 2023-10-18T18:03:00.000Z + + + Bastien TEINTURIER + 2023-10-19T07:35:00.000Z + + + Antoine Riard + 2023-10-19T17:09:00.000Z + + @@ -83,21 +62,17 @@ - python-feedgen + 2 Combined summary - Batch exchange withdrawal to lightning requires covenants - 2023-11-01T20:42:42.139979+00:00 + 2025-09-26T14:21:40.874317+00:00 - The email discusses Antoine's concerns about the robustness of secure fee-bumping in multi-party transactions and covenant-enable constructions. Antoine acknowledges Bastien's proposed protocol for batched splices but raises a concern about the feasibility of interactive re-generation of a bumped Replace-By-Fee (RBF) transaction in a hypothetical scenario with mempool spikes. Antoine suggests further verification is required regarding re-broadcasting the batch splice transaction package with a bumped Child Pays for Parent (CPFP). Antoine also confirms the understanding that participants can potentially double spend the batch using a commit transaction but clarifies that this should not be done for the splice transaction. He agrees with Bastien's suggestion to use a "standard" transaction for the splice transaction with a reasonable feerate and nVersion=2. - + 2023-10-24T08:09:45+00:00 + The email discusses Antoine's concerns about the robustness of secure fee-bumping in multi-party transactions and covenant-enable constructions. Antoine acknowledges Bastien's proposed protocol for batched splices but raises a concern about the feasibility of interactive re-generation of a bumped Replace-By-Fee (RBF) transaction in a hypothetical scenario with mempool spikes. Antoine suggests further verification is required regarding re-broadcasting the batch splice transaction package with a bumped Child Pays for Parent (CPFP). Antoine also confirms the understanding that participants can potentially double spend the batch using a commit transaction but clarifies that this should not be done for the splice transaction. He agrees with Bastien's suggestion to use a "standard" transaction for the splice transaction with a reasonable feerate and nVersion=2. The email proposes a solution for reducing on-chain transaction size by avoiding settlement transactions and generating only one transaction. It discusses the possibility of using swap-in-potentiam (SiP) as an option and mentions its use in Eclair. The email shares a link for further information on SiP. It also discusses a protocol described by Bastien for batched withdrawals and raises a concern about the possibility of malicious cooperation against the batch withdrawal transactions, resulting in a replacement cycling attack. The email addresses the difference between multi-party and non-multi-party transactions in this context. - -Antoine raises concerns about the robustness of secure fee-bumping in multi-party transactions and covenant-enable constructions. They share a test on GitHub and request input from experts familiar with lightning and core mempool. ZmnSCPxj warns Greg about the risk of "not confirming" due to unexpected mempool usage and highlights the possibility of a previous splice transaction eventually confirming instead of the subsequent splice, leading to potential loss of funds if commitment transaction signatures are deleted. ZmnSCPxj also discusses the core risk associated with batched splicing mechanisms in the Lightning Network and emphasizes the need for a backout mechanism in batched splicing. They raise concerns about existing splice implementations and the risks involved. - +Antoine raises concerns about the robustness of secure fee-bumping in multi-party transactions and covenant-enable constructions. They share a test on GitHub and request input from experts familiar with lightning and core mempool. ZmnSCPxj warns Greg about the risk of "not confirming" due to unexpected mempool usage and highlights the possibility of a previous splice transaction eventually confirming instead of the subsequent splice, leading to potential loss of funds if commitment transaction signatures are deleted. ZmnSCPxj also discusses the core risk associated with batched splicing mechanisms in the Lightning Network and emphasizes the need for a backout mechanism in batched splicing. They raise concerns about existing splice implementations and the risks involved. ZmnSCPxj explains the design of a protocol to withdraw funds from exchanges directly into a lightning wallet using covenants. They mention the effectiveness of `SIGHASH_ANYPREVOUT` and propose batching multiple splice transactions into a single one without intermediate steps. They discuss the challenge of obtaining signatures from each wallet user and suggest a workaround using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY`. However, they mention the risk of the wallet provider potentially blackmailing the user. The author invites alternative suggestions and presents the use of `SIGHASH_ANYPREVOUT` as a resolution to allow exchanging anyprevout signatures for the commitment transaction. - The emails cover various topics related to multi-party transactions, covenant-enable constructions, risks in batched splicing mechanisms, and the design of a protocol for efficient lightning withdrawals from exchanges. - 2023-10-24T08:09:45+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_BitVM-Compute-Anything-on-Bitcoin.xml b/static/bitcoin-dev/Oct_2023/combined_BitVM-Compute-Anything-on-Bitcoin.xml index 92fbc059e7..5f078bd952 100644 --- a/static/bitcoin-dev/Oct_2023/combined_BitVM-Compute-Anything-on-Bitcoin.xml +++ b/static/bitcoin-dev/Oct_2023/combined_BitVM-Compute-Anything-on-Bitcoin.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - BitVM: Compute Anything on Bitcoin - 2023-10-18T01:54:52.381143+00:00 - - Russell O'Connor 2023-10-17 18:00:26+00:00 - - - ZmnSCPxj 2023-10-15 15:15:49+00:00 - - - Anthony Towns 2023-10-10 01:27:08+00:00 - - - symphonicbtc 2023-10-10 01:12:28+00:00 - - - Lloyd Fournier 2023-10-10 01:06:10+00:00 - - - Robin Linus 2023-10-09 13:46:24+00:00 - + 2025-09-26T14:21:49.401152+00:00 + python-feedgen + + + [bitcoin-dev] BitVM: Compute Anything on Bitcoin Robin Linus + 2023-10-09T13:46:00.000Z + + + Lloyd Fournier + 2023-10-10T01:06:00.000Z + + + symphonicbtc + 2023-10-10T01:12:00.000Z + + + Anthony Towns + 2023-10-10T01:27:00.000Z + + + ZmnSCPxj + 2023-10-15T15:15:00.000Z + + + Russell O'Connor + 2023-10-17T18:00:00.000Z + + - python-feedgen + 2 Combined summary - BitVM: Compute Anything on Bitcoin - 2023-10-18T01:54:52.381242+00:00 + 2025-09-26T14:21:49.402066+00:00 - The email from Adam Gibson discusses the concept of "scriptless script" and explores its potential applications in Bitcoin. Scriptless script refers to a technique that allows for the execution of complex smart contracts on Bitcoin without revealing the details of the contract on the blockchain. This can be achieved by using cryptographic protocols that enable parties to interact and enforce the terms of the contract off-chain while utilizing Bitcoin's security as a final arbiter.Adam Gibson provides an example of how scriptless script can be used in a Lightning Network context. In this scenario, two parties can create a Lightning channel without broadcasting any specific transaction on the blockchain. Instead, they establish a shared secret off-chain and use it to create commitment transactions that spend from their respective funding transactions. These commitment transactions can be enforced on-chain if necessary, providing the security guarantees of the Lightning Network.Additionally, Adam Gibson discusses the possibility of using scriptless script to implement more complex smart contracts. He mentions the idea of constructing state channels that allow for the execution of arbitrary programs without revealing the program details on the blockchain. This could enable the implementation of privacy-preserving decentralized applications (dApps) on Bitcoin.Furthermore, Adam Gibson highlights the benefits of scriptless script, such as improved scalability, enhanced privacy, and reduced on-chain transaction fees. By executing complex operations off-chain, the burden on the Bitcoin network is reduced, allowing for more efficient and scalable transactions. Additionally, the privacy of participants is preserved since the details of the contract are not exposed on the blockchain.In conclusion, Adam Gibson explores the concept of scriptless script and its potential applications in Bitcoin. The technique allows for the execution of complex smart contracts off-chain while utilizing Bitcoin's security as a final arbiter. This approach offers various benefits, including improved scalability, enhanced privacy, and reduced transaction fees. 2023-10-17T18:00:26+00:00 + The email from Adam Gibson discusses the concept of "scriptless script" and explores its potential applications in Bitcoin. Scriptless script refers to a technique that allows for the execution of complex smart contracts on Bitcoin without revealing the details of the contract on the blockchain. This can be achieved by using cryptographic protocols that enable parties to interact and enforce the terms of the contract off-chain while utilizing Bitcoin's security as a final arbiter.Adam Gibson provides an example of how scriptless script can be used in a Lightning Network context. In this scenario, two parties can create a Lightning channel without broadcasting any specific transaction on the blockchain. Instead, they establish a shared secret off-chain and use it to create commitment transactions that spend from their respective funding transactions. These commitment transactions can be enforced on-chain if necessary, providing the security guarantees of the Lightning Network.Additionally, Adam Gibson discusses the possibility of using scriptless script to implement more complex smart contracts. He mentions the idea of constructing state channels that allow for the execution of arbitrary programs without revealing the program details on the blockchain. This could enable the implementation of privacy-preserving decentralized applications (dApps) on Bitcoin.Furthermore, Adam Gibson highlights the benefits of scriptless script, such as improved scalability, enhanced privacy, and reduced on-chain transaction fees. By executing complex operations off-chain, the burden on the Bitcoin network is reduced, allowing for more efficient and scalable transactions. Additionally, the privacy of participants is preserved since the details of the contract are not exposed on the blockchain.In conclusion, Adam Gibson explores the concept of scriptless script and its potential applications in Bitcoin. The technique allows for the execution of complex smart contracts off-chain while utilizing Bitcoin's security as a final arbiter. This approach offers various benefits, including improved scalability, enhanced privacy, and reduced transaction fees. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Breaking-change-in-calculation-of-hash-serialized-2.xml b/static/bitcoin-dev/Oct_2023/combined_Breaking-change-in-calculation-of-hash-serialized-2.xml index 46295f2421..35e9854286 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Breaking-change-in-calculation-of-hash-serialized-2.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Breaking-change-in-calculation-of-hash-serialized-2.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Breaking change in calculation of hash_serialized_2 - 2023-10-22T01:59:07.871656+00:00 - - Fabian 2023-10-20 22:01:40+00:00 - - - Peter Todd 2023-10-20 17:34:28+00:00 - - - Fabian 2023-10-20 17:19:19+00:00 - + 2025-09-26T14:22:00.004520+00:00 + python-feedgen + + + [bitcoin-dev] Breaking change in calculation of hash_serialized_2 Fabian + 2023-10-20T17:19:00.000Z + + + Peter Todd + 2023-10-20T17:34:00.000Z + + + Fabian + 2023-10-20T22:01:00.000Z + + - python-feedgen + 2 Combined summary - Breaking change in calculation of hash_serialized_2 - 2023-10-22T01:59:07.871709+00:00 + 2025-09-26T14:22:00.005105+00:00 - A recent email discussion raised the question of using the SHA256 hash in a snapshot file. James suggested that instead of hashing the snapshot file separately, it would be more efficient to use the hash of the file itself as the canonical hash. This approach would eliminate any malleability issues. James argued that since the function "gettxoutsetinfo" already requires walking through the entire UTXO set to calculate the hash, it makes sense for this function to generate the actual contents of the dump file and calculate the hash of it. He provided a link to Peter Todd's website (https://petertodd.org), although the content of the linked resource was not included in the email.It is important to note that a potential malleability issue was discovered in the UTXO set dump files used by assumeutxo. The issue was caused by a bug in the serialization of UTXOs for the calculation of hash_serialized_2, which is used by Bitcoin Core to check if the UTXO set loaded from a dump file matches the expected value. A fix for this bug is currently being worked on and is scheduled for release in v26.0 in November. As a result of the fix, the serialization will change and all historical UTXO set hash results will also change after upgrading to v26.0. The version number returned in gettxoutset will be renamed to hash_serialized_3.The decision to switch the serialization completely was made due to additional potentially problematic issues found during fuzz testing. If anyone is currently using hash_serialized_2 for any security critical purposes, it is recommended to check if the bugs in the serialization code could cause issues. Switching to hash_serialized_3 or considering using MuHash is advised. For projects that rely on hash_serialized_2 and require time to upgrade and adapt to the changes, it is requested to inform the team. Although breaking changes in APIs without deprecation warning are typically avoided, it is currently believed that keeping the buggy hash_serialized_2 is not necessary as there are no known substantial use cases and its usage may even pose security risks.The team is open to reconsidering the decision if keeping hash_serialized_2 holds serious value for downstream projects. Contact can be made directly with Fabian or through commenting on the PR or the mailing list. 2023-10-20T22:01:40+00:00 + A recent email discussion raised the question of using the SHA256 hash in a snapshot file. James suggested that instead of hashing the snapshot file separately, it would be more efficient to use the hash of the file itself as the canonical hash. This approach would eliminate any malleability issues. James argued that since the function "gettxoutsetinfo" already requires walking through the entire UTXO set to calculate the hash, it makes sense for this function to generate the actual contents of the dump file and calculate the hash of it. He provided a link to Peter Todd's website (https://petertodd.org), although the content of the linked resource was not included in the email.It is important to note that a potential malleability issue was discovered in the UTXO set dump files used by assumeutxo. The issue was caused by a bug in the serialization of UTXOs for the calculation of hash_serialized_2, which is used by Bitcoin Core to check if the UTXO set loaded from a dump file matches the expected value. A fix for this bug is currently being worked on and is scheduled for release in v26.0 in November. As a result of the fix, the serialization will change and all historical UTXO set hash results will also change after upgrading to v26.0. The version number returned in gettxoutset will be renamed to hash_serialized_3.The decision to switch the serialization completely was made due to additional potentially problematic issues found during fuzz testing. If anyone is currently using hash_serialized_2 for any security critical purposes, it is recommended to check if the bugs in the serialization code could cause issues. Switching to hash_serialized_3 or considering using MuHash is advised. For projects that rely on hash_serialized_2 and require time to upgrade and adapt to the changes, it is requested to inform the team. Although breaking changes in APIs without deprecation warning are typically avoided, it is currently believed that keeping the buggy hash_serialized_2 is not necessary as there are no known substantial use cases and its usage may even pose security risks.The team is open to reconsidering the decision if keeping hash_serialized_2 holds serious value for downstream projects. Contact can be made directly with Fabian or through commenting on the PR or the mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Draft-BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml b/static/bitcoin-dev/Oct_2023/combined_Draft-BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml index f8ca479ded..cebbe37aa4 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Draft-BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Draft-BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Draft BIP: OP_TXHASH and OP_CHECKTXHASHVERIFY - 2023-10-07T01:53:23.790499+00:00 - - Steven Roose 2023-10-06 17:38:22+00:00 - - - Steven Roose 2023-09-30 11:44:02+00:00 - + 2025-09-26T14:21:53.627461+00:00 + python-feedgen + + + [bitcoin-dev] Draft BIP: OP_TXHASH and OP_CHECKTXHASHVERIFY Steven Roose + 2023-09-30T11:44:00.000Z + + + Steven Roose + 2023-10-06T17:38:00.000Z + + - python-feedgen + 2 Combined summary - Draft BIP: OP_TXHASH and OP_CHECKTXHASHVERIFY - 2023-10-07T01:53:23.790554+00:00 + 2025-09-26T14:21:53.627905+00:00 - In the email, Steven discusses the concept of a TxHash (Transaction Hash) and its formalization. He has been working on a specification and gathering feedback for several weeks. The full Bitcoin Improvement Proposal (BIP) text can be found in the attachment and also on the GitHub link provided.The BIP introduces the concept of a TxFieldSelector, which is a serialized data structure used to select data inside a transaction. It defines various global fields such as version, locktime, number of inputs, number of outputs, current input index, and current input control block. It also specifies the fields available for each input and output. The BIP introduces support for selecting inputs and outputs based on certain criteria, including all in/outputs, a single in/output at the same index as the input being executed, any number of leading in/outputs, and up to 64 individually selected in/outputs.Two new opcodes, OP_TXHASH and OP_CHECKTXHASHVERIFY, are introduced by the BIP. OP_TXHASH is enabled only in tapscript and takes a serialized TxFieldSelector from the stack and pushes on the stack a hash committing to all the selected data. OP_CHECKTXHASHVERIFY is enabled in all script contexts and expects a single item on the stack, interpreted as a 32-byte hash value concatenated with a serialized TxFieldSelector. Execution fails if the hash value in the data push doesn't match the calculated hash value based on the TxFieldSelector.The BIP also addresses concerns related to resource usage, particularly quadratic hashing. A potential caching strategy is proposed to prevent excessive hashing. Individual selection is limited to 64 items, and it suggests that selecting "all" in/outputs can mostly use the same caches as sighash calculations. Storing intermediate SHA256 contexts for prefix hashing is also mentioned as a possibility to minimize the number of items that need to be hashed repeatedly.The email highlights the achievements of this proposal, mentioning that the default TxFieldSelector is functionally equivalent to OP_CHECKTEMPLATEVERIFY, making it a strict upgrade of BIP-119. The flexibility of selecting transaction fields and in/outputs makes this construction more useful in designing protocols where users want to add fees to their transactions without breaking a transaction chain or when constructing transactions together with specific conditions on in/outputs. Additionally, OP_TXHASH, along with other opcodes like OP_CHECKSIGFROMSTACK, could be used as a replacement for complex sighash constructions.Some open questions are mentioned in the email. One question pertains to whether the proposal adequately addresses concerns around resource usage and quadratic hashing. Another question relates to including the TxFieldSelector as part of the hash, which would affect the ability to prove equality of fields. A potential solution is suggested, involving assigning additional bits in the "in/output selector" bytes to include the TxFieldSelector in the hash. The email seeks general feedback on the proposal and whether it should be implemented as a softfork.In conclusion, Steven is seeking wider feedback and community interest in this proposal for a TxHash concept. He expresses his willingness to spend time formalizing the BIP and working on an implementation for Bitcoin Core if there is community interest. 2023-10-06T17:38:22+00:00 + In the email, Steven discusses the concept of a TxHash (Transaction Hash) and its formalization. He has been working on a specification and gathering feedback for several weeks. The full Bitcoin Improvement Proposal (BIP) text can be found in the attachment and also on the GitHub link provided.The BIP introduces the concept of a TxFieldSelector, which is a serialized data structure used to select data inside a transaction. It defines various global fields such as version, locktime, number of inputs, number of outputs, current input index, and current input control block. It also specifies the fields available for each input and output. The BIP introduces support for selecting inputs and outputs based on certain criteria, including all in/outputs, a single in/output at the same index as the input being executed, any number of leading in/outputs, and up to 64 individually selected in/outputs.Two new opcodes, OP_TXHASH and OP_CHECKTXHASHVERIFY, are introduced by the BIP. OP_TXHASH is enabled only in tapscript and takes a serialized TxFieldSelector from the stack and pushes on the stack a hash committing to all the selected data. OP_CHECKTXHASHVERIFY is enabled in all script contexts and expects a single item on the stack, interpreted as a 32-byte hash value concatenated with a serialized TxFieldSelector. Execution fails if the hash value in the data push doesn't match the calculated hash value based on the TxFieldSelector.The BIP also addresses concerns related to resource usage, particularly quadratic hashing. A potential caching strategy is proposed to prevent excessive hashing. Individual selection is limited to 64 items, and it suggests that selecting "all" in/outputs can mostly use the same caches as sighash calculations. Storing intermediate SHA256 contexts for prefix hashing is also mentioned as a possibility to minimize the number of items that need to be hashed repeatedly.The email highlights the achievements of this proposal, mentioning that the default TxFieldSelector is functionally equivalent to OP_CHECKTEMPLATEVERIFY, making it a strict upgrade of BIP-119. The flexibility of selecting transaction fields and in/outputs makes this construction more useful in designing protocols where users want to add fees to their transactions without breaking a transaction chain or when constructing transactions together with specific conditions on in/outputs. Additionally, OP_TXHASH, along with other opcodes like OP_CHECKSIGFROMSTACK, could be used as a replacement for complex sighash constructions.Some open questions are mentioned in the email. One question pertains to whether the proposal adequately addresses concerns around resource usage and quadratic hashing. Another question relates to including the TxFieldSelector as part of the hash, which would affect the ability to prove equality of fields. A potential solution is suggested, involving assigning additional bits in the "in/output selector" bytes to include the TxFieldSelector in the hash. The email seeks general feedback on the proposal and whether it should be implemented as a softfork.In conclusion, Steven is seeking wider feedback and community interest in this proposal for a TxHash concept. He expresses his willingness to spend time formalizing the BIP and working on an implementation for Bitcoin Core if there is community interest. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Examining-ScriptPubkeys-in-Bitcoin-Script.xml b/static/bitcoin-dev/Oct_2023/combined_Examining-ScriptPubkeys-in-Bitcoin-Script.xml index 718da3702c..377cd6ae0c 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Examining-ScriptPubkeys-in-Bitcoin-Script.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Examining-ScriptPubkeys-in-Bitcoin-Script.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Examining ScriptPubkeys in Bitcoin Script - 2023-11-01T20:05:05.562799+00:00 - - Anthony Towns 2023-10-31 13:05:01+00:00 - - - Rusty Russell 2023-10-31 02:24:27+00:00 - - - James O'Beirne 2023-10-30 16:20:32+00:00 - - - Rusty Russell 2023-10-28 04:49:30+00:00 - - - Anthony Towns 2023-10-27 07:00:36+00:00 - - - Rusty Russell 2023-10-22 04:16:33+00:00 - - - Brandon Black 2023-10-20 14:19:06+00:00 - - - Rusty Russell 2023-10-20 03:40:37+00:00 - + 2025-09-26T14:22:19.378332+00:00 + python-feedgen + + + [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script Rusty Russell + 2023-10-20T03:40:00.000Z + + + Brandon Black + 2023-10-20T14:19:00.000Z + + + Rusty Russell + 2023-10-22T04:16:00.000Z + + + Anthony Towns + 2023-10-27T07:00:00.000Z + + + Rusty Russell + 2023-10-28T04:49:00.000Z + + + James O'Beirne + 2023-10-30T16:20:00.000Z + + + Rusty Russell + 2023-10-31T02:24:00.000Z + + + Anthony Towns + 2023-10-31T13:05:00.000Z + + @@ -35,23 +46,18 @@ - python-feedgen + 2 Combined summary - Examining ScriptPubkeys in Bitcoin Script - 2023-11-01T20:05:05.562799+00:00 + 2025-09-26T14:22:19.379339+00:00 + 2023-10-31T13:05:01+00:00 The email exchange discusses the exploration of different ways to implement vaults and improve the functionality of Bitcoin Script. The sender's goal is to create a usable vault that offers both security and flexibility. They mention considering the use of miniscript and descriptor layers to abstract certain vault patterns for better understanding and implementation. - -James O'Beirne shares his thoughts on vaults from a user's perspective. He suggests having a "master" key for emergencies and a "normal" delayed spend key as an ideal setup for users. However, he acknowledges the challenges in implementing vaults, such as limited script delegation, iteration, and amount arithmetic, which are not easily expressible in Bitcoin Script. - +James O'Beirne shares his thoughts on vaults from a user's perspective. He suggests having a "master" key for emergencies and a "normal" delayed spend key as an ideal setup for users. However, he acknowledges the challenges in implementing vaults, such as limited script delegation, iteration, and amount arithmetic, which are not easily expressible in Bitcoin Script. The sender mentions their plan to thoroughly review the design decisions of BIP 345, which introduces mechanisms for vaults. They find it interesting to explore the possibility of introducing certain functionality as a new address type instead of using script opcodes. They also highlight the need to evaluate whether the elements of BIP 345 should be part of the OP_VAULT opcode or separate entities. - Rusty Russell expresses his interest in seeing a specific address type designed for vaults. He believes that Bitcoin Script could be more powerful in implementing vaults if a popular use pattern emerged and a new address type was defined for it. However, he acknowledges the limitations of Bitcoin Script and the introduction of separate mechanisms in BIP 345 that are not easily expressible in script. - In addition to vaults, the emails discuss the sender's research on validating Taproot outputs in Bitcoin Script. They invite collaboration and encourage others to join in producing a prototype and debugging script examples. The sender summarizes their findings, stating that by adding certain operations like OP_MULTISHA256, OP_KEYADDTWEAK, and OP_LESS, along with weakening the OP_SUCCESSx rule, it is possible to prove a two-leaf tapscript tree in about 110 bytes of Script. This enables useful spending constraints based on a template approach. - In conclusion, the emails address the confusion and lack of understanding surrounding vaults and propose different approaches to improve their implementation and usability in Bitcoin Script. The sender also shares their research findings on validating Taproot outputs and invites collaboration for further development and testing of their ideas. - 2023-10-31T13:05:01+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml b/static/bitcoin-dev/Oct_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml index 4ee8ab95d8..366fdbf7f5 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml @@ -1,218 +1,247 @@ - + 2 - Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" - 2023-11-19T02:08:14.468907+00:00 - - Antoine Riard 2023-11-17 22:36:35+00:00 - - - Antoine Riard 2023-11-02 04:46:29+00:00 - - - Peter Todd 2023-10-27 00:43:30+00:00 - - - Peter Todd 2023-10-27 00:43:30+00:00 - - - Matt Corallo 2023-10-23 16:09:50+00:00 - - - Matt Corallo 2023-10-23 16:09:50+00:00 - - - David A. Harding 2023-10-23 08:49:55+00:00 - - - David A. Harding 2023-10-23 08:49:55+00:00 - - - Nadav Ivgi 2023-10-22 04:49:19+00:00 - - - Nadav Ivgi 2023-10-22 04:49:19+00:00 - - - Antoine Riard 2023-10-21 20:05:35+00:00 - - - Antoine Riard 2023-10-21 20:05:35+00:00 - - - Nagaev Boris 2023-10-21 14:21:48+00:00 - - - Peter Todd 2023-10-21 02:43:31+00:00 - - - Peter Todd 2023-10-21 02:43:31+00:00 - - - Matt Corallo 2023-10-21 01:55:12+00:00 - - - Matt Corallo 2023-10-21 01:55:12+00:00 - - - Peter Todd 2023-10-21 01:25:10+00:00 - - - Peter Todd 2023-10-21 01:25:10+00:00 - - - Matt Corallo 2023-10-21 01:03:49+00:00 - - - Matt Corallo 2023-10-21 01:03:49+00:00 - - - Olaoluwa Osuntokun 2023-10-21 00:18:58+00:00 - - - Olaoluwa Osuntokun 2023-10-21 00:18:58+00:00 - - - Peter Todd 2023-10-21 00:15:21+00:00 - - - Peter Todd 2023-10-21 00:15:21+00:00 - - - Matt Corallo 2023-10-20 21:05:48+00:00 - - - Matt Corallo 2023-10-20 21:05:48+00:00 - - - Matt Morehouse 2023-10-20 18:35:26+00:00 - - - Matt Morehouse 2023-10-20 18:35:26+00:00 - - - Jochen Hoenicke 2023-10-20 11:18:46+00:00 - - - Peter Todd 2023-10-20 11:03:43+00:00 - - - Peter Todd 2023-10-20 11:03:43+00:00 - - - Peter Todd 2023-10-20 10:47:38+00:00 - - - Peter Todd 2023-10-20 10:31:03+00:00 - - - Peter Todd 2023-10-20 10:31:03+00:00 - - - Antoine Riard 2023-10-20 06:56:34+00:00 - - - Antoine Riard 2023-10-20 06:56:34+00:00 - - - Antoine Riard 2023-10-19 19:33:22+00:00 - - - Antoine Riard 2023-10-19 19:33:22+00:00 - - - Matt Corallo 2023-10-19 18:02:38+00:00 - - - Matt Corallo 2023-10-19 18:02:38+00:00 - - - Matt Morehouse 2023-10-19 17:53:53+00:00 - - - Matt Morehouse 2023-10-19 17:53:53+00:00 - - - Antoine Riard 2023-10-19 17:22:01+00:00 - - - Antoine Riard 2023-10-19 17:22:01+00:00 - - - Matt Morehouse 2023-10-19 16:23:13+00:00 - - - Matt Morehouse 2023-10-19 16:23:13+00:00 - - - Bastien TEINTURIER 2023-10-19 08:12:08+00:00 - - - Bastien TEINTURIER 2023-10-19 08:12:08+00:00 - - - Antoine Riard 2023-10-18 02:57:34+00:00 - - - Antoine Riard 2023-10-18 02:57:34+00:00 - - - Matt Corallo 2023-10-18 00:17:44+00:00 - - - Matt Corallo 2023-10-18 00:17:44+00:00 - - - Antoine Riard 2023-10-17 18:47:59+00:00 - - - Antoine Riard 2023-10-17 18:47:59+00:00 - - - Antoine Riard 2023-10-17 18:34:52+00:00 - - - Antoine Riard 2023-10-17 18:34:52+00:00 - - - Antoine Riard 2023-10-17 17:47:14+00:00 - - - Antoine Riard 2023-10-17 17:47:14+00:00 - - - ZmnSCPxj 2023-10-17 10:34:04+00:00 - - - ZmnSCPxj 2023-10-17 10:34:04+00:00 - - - ziggie 2023-10-17 07:21:35+00:00 - - - ziggie 2023-10-17 07:21:35+00:00 - - - Antoine Riard 2023-10-17 01:11:20+00:00 - - - Olaoluwa Osuntokun 2023-10-16 22:51:19+00:00 - - - Olaoluwa Osuntokun 2023-10-16 22:51:19+00:00 - - - Matt Morehouse 2023-10-16 22:10:06+00:00 - - - Peter Todd 2023-10-16 19:13:52+00:00 - - - Antoine Riard 2023-10-16 16:57:36+00:00 - - - Antoine Riard 2023-10-16 16:57:36+00:00 - + Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2025-09-26T14:22:06.561621+00:00 + python-feedgen + + + [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Antoine Riard + 2023-10-16T16:57:00.000Z + + + Peter Todd + 2023-10-16T19:13:00.000Z + + + Matt Morehouse + 2023-10-16T22:10:00.000Z + + + Olaoluwa Osuntokun + 2023-10-16T22:51:00.000Z + + + Antoine Riard + 2023-10-17T01:11:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ziggie1984 + 2023-10-17T07:21:00.000Z + + + ZmnSCPxj + 2023-10-17T10:34:00.000Z + + + Antoine Riard + 2023-10-17T17:47:00.000Z + + + Antoine Riard + 2023-10-17T18:34:00.000Z + + + Antoine Riard + 2023-10-17T18:47:00.000Z + + + Matt Corallo + 2023-10-18T00:17:00.000Z + + + Antoine Riard + 2023-10-18T02:57:00.000Z + + + Bastien TEINTURIER + 2023-10-19T08:12:00.000Z + + + Matt Morehouse + 2023-10-19T16:23:00.000Z + + + Antoine Riard + 2023-10-19T17:22:00.000Z + + + Matt Morehouse + 2023-10-19T17:53:00.000Z + + + Matt Corallo + 2023-10-19T18:02:00.000Z + + + Antoine Riard + 2023-10-19T19:33:00.000Z + + + [bitcoin-dev] " Antoine Riard + 2023-10-20T06:56:00.000Z + + + Peter Todd + 2023-10-20T10:31:00.000Z + + + Peter Todd + 2023-10-20T10:47:00.000Z + + + Peter Todd + 2023-10-20T11:03:00.000Z + + + Jochen Hoenicke + 2023-10-20T11:18:00.000Z + + + Matt Morehouse + 2023-10-20T18:35:00.000Z + + + Matt Corallo + 2023-10-20T21:05:00.000Z + + + [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely Peter Todd + 2023-10-21T00:09:00.000Z + + + Peter Todd + 2023-10-21T00:15:00.000Z + + + Olaoluwa Osuntokun + 2023-10-21T00:18:00.000Z + + + Matt Corallo + 2023-10-21T01:03:00.000Z + + + Peter Todd + 2023-10-21T01:25:00.000Z + + + Matt Corallo + 2023-10-21T01:55:00.000Z + + + Peter Todd + 2023-10-21T02:43:00.000Z + + + David A. Harding + 2023-10-21T08:58:00.000Z + + + Peter Todd + 2023-10-21T10:31:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Nagaev Boris + 2023-10-21T14:21:00.000Z + + + Antoine Riard + 2023-10-21T20:05:00.000Z + + + [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Nadav Ivgi + 2023-10-22T04:49:00.000Z + + + vjudeu + 2023-10-22T08:30:00.000Z + + + David A. Harding + 2023-10-23T08:49:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2023-10-23T11:10:00.000Z + + + Peter Todd + 2023-10-23T15:45:00.000Z + + + Matt Corallo + 2023-10-23T16:09:00.000Z + + + Peter Todd + 2023-10-27T00:43:00.000Z + + + Antoine Riard + 2023-11-02T04:46:00.000Z + + + [bitcoin-dev] " Antoine Riard + 2023-11-02T05:24:00.000Z + + + Peter Todd + 2023-11-02T06:26:00.000Z + + + Matt Morehouse + 2023-11-02T17:07:00.000Z + + + Antoine Riard + 2023-11-03T05:25:00.000Z + + + Antoine Riard + 2023-11-03T05:27:00.000Z + + + Peter Todd + 2023-11-04T07:26:00.000Z + + + Antoine Riard + 2023-11-06T18:45:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2023-11-07T11:11:00.000Z + + + Antoine Riard + 2023-11-07T15:44:00.000Z + + + [bitcoin-dev] " Peter Todd + 2023-11-08T00:51:00.000Z + + + Peter Todd + 2023-11-08T02:06:00.000Z + + + Antoine Riard + 2023-11-13T02:18:00.000Z + + + Peter Todd + 2023-11-14T19:50:00.000Z + + + [bitcoin-dev] Fwd: " Antoine Riard + 2023-11-15T17:53:00.000Z + + + Antoine Riard + 2023-11-17T22:36:00.000Z + + @@ -283,39 +312,26 @@ - python-feedgen + 2 - Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" - 2023-11-19T02:08:14.469376+00:00 + Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2025-09-26T14:22:06.567064+00:00 - The recent discussions among programmers have focused on addressing security threats to the Lightning Network (LN), particularly vulnerabilities in Hashed Time-Locked Contracts (HTLCs). The "flood & loot" attack, where attackers exploit network mempools by closing channels and hindering defensive transactions, has been highlighted as a significant threat. It was noted that policy differences across Bitcoin Core implementations allow such attacks due to transaction prioritization based on fees. - + 2023-11-17T22:36:35+00:00 + The recent discussions among programmers have focused on addressing security threats to the Lightning Network (LN), particularly vulnerabilities in Hashed Time-Locked Contracts (HTLCs). The "flood & loot" attack, where attackers exploit network mempools by closing channels and hindering defensive transactions, has been highlighted as a significant threat. It was noted that policy differences across Bitcoin Core implementations allow such attacks due to transaction prioritization based on fees. Mitigation strategies are being implemented in various lightning node implementations to address these vulnerabilities. One suggestion is for nodes to monitor their mempool duplicates to reduce exploitation risk, although this does not eliminate the threat entirely. Additionally, there's a push for ecosystem-level solutions rather than quick fixes that could disrupt LN or lower miners' earnings. - To enhance security against replacement cycling attacks, a technical proposal suggests implementing a new opcode, OP_CSV_ALLINPUTS, which would require all inputs in an HTLC preimage branch to have a consistent nSequence, ensuring only confirmed inputs are used. - The email exchanges also reflect on one author's decision to step away from lightning development due to the severity of replacement cycling issues and the lack of standardized mechanisms to combat them. An expert assessment and dedicated time to improve lightning's robustness are called for. - Plans to demonstrate a real-world replacement cycling attack no earlier than the second semester of 2024 were disclosed, with encouragement for public discussion and correspondence on these topics. Debates continue over alternative methods for handling vulnerabilities within the technical community. - New opcodes like OP_CSV_ALLINPUTS and restructuring of presigned transactions are suggested to manage fees and prevent attacks more effectively. Insights into optimizing transaction handling and storage include proposals by Peter Todd, who advocates for combining multiple HTLC claims into one transaction for larger nodes using specific signatures. Discussions also mention the potential efficiency of Replace-by-Fee (RBF) over Child-Pays-for-Parent (CPFP) under most conditions. - For those seeking detailed information, Peter Todd's website at https://petertodd.org is recommended, with an invitation for further dialogue via direct email. - Security discussions extend to anchor outputs in LN for managing fees and transaction replacement strategies, recognizing the benefits of small transactions and deterministic forms. Concerns regarding default settings for RBF, fee overheads, and different feerate variants are raised, including identifying a possible policy bug that requires attention at the policy or Bitcoin Core layer. - An explained attack scenario clarifies that successful attacks depend on precise timing and execution by directly connected peers. Increased security parameters, like the CLTV delta, and the use of anchor channels for fee bumping through second-level HTLCs are considered to hinder such attacks. A proposal to limit spending to presigned second-stage transactions signed with SIGHASH_ALL is suggested to prevent replacement cycling attacks. - -Innovative approaches to mitigating aggressive fee bumping near the CLTV deadline are explored, recommending a "scorched earth" strategy to make it costly for attackers. Research on defensive fee rebroadcasting suggests foundational improvements at the bitcoin protocol level to reinforce Layer 2 protocols. - -Discussants suggest increasing the CLTV delta to give node operators more time for intervention and consider various mitigation strategies, including mempool scanning and transaction re-signing. Establishing a "black box" Lightning infrastructure on the mainnet to experiment with LN vulnerabilities and defenses is of interest, but limited by the scarcity of LN experts and undisclosed risks. - +Innovative approaches to mitigating aggressive fee bumping near the CLTV deadline are explored, recommending a "scorched earth" strategy to make it costly for attackers. Research on defensive fee rebroadcasting suggests foundational improvements at the bitcoin protocol level to reinforce Layer 2 protocols. +Discussants suggest increasing the CLTV delta to give node operators more time for intervention and consider various mitigation strategies, including mempool scanning and transaction re-signing. Establishing a "black box" Lightning infrastructure on the mainnet to experiment with LN vulnerabilities and defenses is of interest, but limited by the scarcity of LN experts and undisclosed risks. A complex payment channel scenario reveals strategic advantages and limitations of CPFP and presigned transactions, while an unobserved attack type exploiting neighboring nodes highlights the need for surveillance and countermeasures like aggressive fee-bumping. - Eclair and LND have partially implemented mitigation strategies against vulnerabilities, while Core-Lightning and LDK have yet to adopt similar mechanisms. Node operators are advised to limit HTLCs for large channels to unknown peers and monitor for suspicious behavior. - Lastly, the Lightning Network Daemon (lnd) version 0.16.1-beta includes safeguards against HTLC-related exploits, with performance improvements planned for the upcoming version 0.17.1. The collaborative nature of the community in enhancing lnd's security is acknowledged, and the importance of critical analysis and skepticism in technical discussions is emphasized ahead of the public disclosure of related CVEs on October 16, 2023. - 2023-11-17T22:36:35+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml b/static/bitcoin-dev/Oct_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml index 44ed433b99..148bc61f40 100644 --- a/static/bitcoin-dev/Oct_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml +++ b/static/bitcoin-dev/Oct_2023/combined_HTLC-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficiency-covenants-.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) - 2023-12-22T14:19:32.416217+00:00 - - Johan Torås Halseth 2023-12-21 13:34:36+00:00 - - - Antoine Riard 2023-12-17 22:56:38+00:00 - - - Johan Torås Halseth 2023-12-11 09:17:23+00:00 - - - Antoine Riard 2023-11-21 02:39:45+00:00 - - - Johan Torås Halseth 2023-10-26 16:52:03+00:00 - + 2025-09-26T14:22:15.116034+00:00 + python-feedgen + + + [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) Johan Torås Halseth + 2023-10-26T16:52:00.000Z + + + Antoine Riard + 2023-11-21T02:39:00.000Z + + + Johan Torås Halseth + 2023-12-11T09:17:00.000Z + + + Antoine Riard + 2023-12-17T22:56:00.000Z + + + Johan Torås Halseth + 2023-12-21T13:34:00.000Z + + - python-feedgen + 2 Combined summary - HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants) - 2023-12-22T14:19:32.416275+00:00 + 2025-09-26T14:22:15.116809+00:00 + 2023-12-21T13:34:36+00:00 In a detailed examination of the security and functionality of the Lightning Network (LN) within Bitcoin's financial ecosystem, programmers Antoine and Johan engage in a technical discourse exploring potential vulnerabilities and solutions. The focus lies on the new covenant mechanism proposed as part of Bitcoin's Eltoo update, which simplifies LN transactions by collapsing multiple Hash Time-Locked Contracts (HTLCs) into a single output. This mechanism requires a user to provide a preimage and signature to spend an aggregated HTLC output, which can represent numerous individual HTLC payouts within standard transaction relay limits. A revelation made during this conversation is that counterparty attacks could occur through partial preimage revelation during transactions, enabling the replacement of legitimate network transactions with high-fee, low-value spends that lead to double-spending. - Antoine elaborates on an attack scenario involving Alice and Bob, where Bob could steal a larger HTLC payout by repeatedly replacing Alice's transactions with his own that carry higher fees. Such attacks exploit network mempool congestion, delaying the confirmation of malicious transactions. Antoine suggests that simply implementing self-adjusting fees will not suffice; instead, he proposes adding a sliding delay to HTLC timelocks based on block feerate to thwart attackers. The discussion also ventures into how witness size growth in a taproot-world scenario could be managed and considers efficient Script-level testing of partial set membership as a solution. - Further discussions involve the security implications of not broadcasting a revoked state in the Eltoo protocol, as raised by Antoine, and Johan's concern about managing an exponential growth in state combinations resulting from this vulnerability. They delve into the practical aspects of addressing these complexities, emphasizing the need for strategies to maintain system integrity. - The blog post transitions to discussing transaction recycling and slot jamming attacks, which are enabled by changes in HTLC second-level transactions for anchor channel types. It now allows additional fees to be added without invalidating previous signatures. The aggregation of HTLC outputs, while beneficial for reducing fee-bumping reserve requirements, introduces concerns about malleability and the depletion of value through excessive miners' fees. Segregating HTLC claims into separate outputs and introducing covenants might be a viable mitigation strategy. Other considerations include the current protocol limit affecting long-term payment throughput on the LN and the use of taproot branches to maintain near-constant size for claimed offered HTLCs. An exploration is made regarding the use of advanced cryptosystems to enhance scalability and security, despite trimmed HTLCs due to dust limits. - For further insights, the email refers readers to additional resources including GitHub repositories, commits demonstrating test attacks, and scholarly discussions. This comprehensive analysis underscores the importance of understanding not only the technical aspects but also the game-theoretical implications of cryptocurrency protocols to safeguard against potential threats to transaction processes on the Lightning Network. - 2023-12-21T13:34:36+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_MATT-demo-Optimistic-execution-of-arbitrary-programs.xml b/static/bitcoin-dev/Oct_2023/combined_MATT-demo-Optimistic-execution-of-arbitrary-programs.xml index cda2e489b2..2e0b5d86f2 100644 --- a/static/bitcoin-dev/Oct_2023/combined_MATT-demo-Optimistic-execution-of-arbitrary-programs.xml +++ b/static/bitcoin-dev/Oct_2023/combined_MATT-demo-Optimistic-execution-of-arbitrary-programs.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - MATT: [demo] Optimistic execution of arbitrary programs - 2023-10-04T01:56:18.451166+00:00 - - Johan Torås Halseth 2023-10-03 07:53:08+00:00 - - - Anthony Towns 2023-10-02 15:10:08+00:00 - - - Johan Torås Halseth 2023-09-29 13:14:25+00:00 - + 2025-09-26T14:22:12.968163+00:00 + python-feedgen + + + [bitcoin-dev] MATT: [demo] Optimistic execution of arbitrary programs Johan Torås Halseth + 2023-09-29T13:14:00.000Z + + + Anthony Towns + 2023-10-02T15:10:00.000Z + + + Johan Torås Halseth + 2023-10-03T07:53:00.000Z + + - python-feedgen + 2 Combined summary - MATT: [demo] Optimistic execution of arbitrary programs - 2023-10-04T01:56:18.451224+00:00 + 2025-09-26T14:22:12.968717+00:00 - The email discusses the complexity notation of "O(n log n)" and suggests that it may be incorrect. The sender proposes that it should be denoted as "O(P + log(N))" where P represents the size of the program and N represents the number of steps (rounded up to a power of 2). However, the recipient disagrees with this suggestion and explains that it is necessary to directly know the values of h(sub_node1) and h(sub_node2) in order to compare them to the results obtained from running the computation. Without this direct knowledge, there is a 50/50 chance of choosing the incorrect subnode, making it difficult to prove a mistake with odds of only 1/2**N.The sender suggests an alternative representation of the nodes and leaves in the program, which would make it 32B longer but would eliminate the need for h() calculations. The proposed representation includes the start_pc, start_i, start_x, end_pc, end_i, end_x, h(sub_node1), and h(sub_node2) for nodes, and start_pc, start_i, start_x, end_pc, end_i, end_x, and null for leaves.The sender also raises a concern regarding the requirement for a balanced state tree. They argue that if a balanced tree is not mandatory, then there could be multiple possible trees for the same execution trace, making it easy to hide errors where the challenger cannot find them. To address this concern, the sender suggests adding a "start_stepcount" and "end_stepcount" to enforce a balanced state tree.Additionally, the recipient points out an error in a diagram illustrating the concept of state transitions. They clarify that the second node in the diagram should read "0|0|2 -> 0|1|4" instead of "0|0|2 -> 1|0|2", matching its left child.Lastly, the sender mentions that it is presumed that the counterparty verifies their knowledge of the program, i.e., all the leaves in the contract taptree, before agreeing to the contract. The recipient agrees with this assumption and concludes the email with a casual farewell.This email provides an introduction to the implementation of the original MATT challenge protocol. It includes a link to a write-up that provides a detailed description of how to transform a "high-level arbitrary program" into something that can be verified on-chain in Bitcoin Script. The write-up also contains instructions on running the code and inspecting the transactions using a local block explorer.The implementation utilizes the proposed opcode OP_CHECKCONTRACTVERIFY and OP_CAT. These opcodes are used to trace the execution of a program called `multiply`. The goal is to challenge the computation of this program in O(n logn) on-chain transactions.Unfortunately, the email does not provide any further details about the implementation or the specific challenges faced during the process. It mainly serves as an introduction to the topic and directs readers to the write-up for more information.[0] - Link to the original MATT challenge protocol: [insert link][1] - Link to the code for the `multiply` program: [insert link] 2023-10-03T07:53:08+00:00 + The email discusses the complexity notation of "O(n log n)" and suggests that it may be incorrect. The sender proposes that it should be denoted as "O(P + log(N))" where P represents the size of the program and N represents the number of steps (rounded up to a power of 2). However, the recipient disagrees with this suggestion and explains that it is necessary to directly know the values of h(sub_node1) and h(sub_node2) in order to compare them to the results obtained from running the computation. Without this direct knowledge, there is a 50/50 chance of choosing the incorrect subnode, making it difficult to prove a mistake with odds of only 1/2**N.The sender suggests an alternative representation of the nodes and leaves in the program, which would make it 32B longer but would eliminate the need for h() calculations. The proposed representation includes the start_pc, start_i, start_x, end_pc, end_i, end_x, h(sub_node1), and h(sub_node2) for nodes, and start_pc, start_i, start_x, end_pc, end_i, end_x, and null for leaves.The sender also raises a concern regarding the requirement for a balanced state tree. They argue that if a balanced tree is not mandatory, then there could be multiple possible trees for the same execution trace, making it easy to hide errors where the challenger cannot find them. To address this concern, the sender suggests adding a "start_stepcount" and "end_stepcount" to enforce a balanced state tree.Additionally, the recipient points out an error in a diagram illustrating the concept of state transitions. They clarify that the second node in the diagram should read "0|0|2 -> 0|1|4" instead of "0|0|2 -> 1|0|2", matching its left child.Lastly, the sender mentions that it is presumed that the counterparty verifies their knowledge of the program, i.e., all the leaves in the contract taptree, before agreeing to the contract. The recipient agrees with this assumption and concludes the email with a casual farewell.This email provides an introduction to the implementation of the original MATT challenge protocol. It includes a link to a write-up that provides a detailed description of how to transform a "high-level arbitrary program" into something that can be verified on-chain in Bitcoin Script. The write-up also contains instructions on running the code and inspecting the transactions using a local block explorer.The implementation utilizes the proposed opcode OP_CHECKCONTRACTVERIFY and OP_CAT. These opcodes are used to trace the execution of a program called `multiply`. The goal is to challenge the computation of this program in O(n logn) on-chain transactions.Unfortunately, the email does not provide any further details about the implementation or the specific challenges faced during the process. It mainly serves as an introduction to the topic and directs readers to the write-up for more information.[0] - Link to the original MATT challenge protocol: [insert link][1] - Link to the code for the `multiply` program: [insert link] - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml b/static/bitcoin-dev/Oct_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml index 8098ec034f..913499522d 100644 --- a/static/bitcoin-dev/Oct_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml +++ b/static/bitcoin-dev/Oct_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely - 2023-11-15T02:05:08.292575+00:00 + 2025-09-26T14:22:21.526749+00:00 + python-feedgen Peter Todd 2023-11-14 19:50:04+00:00 @@ -103,29 +104,21 @@ - python-feedgen + 2 Combined summary - OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely - 2023-11-15T02:05:08.292807+00:00 + 2025-09-26T14:22:21.526909+00:00 + 2023-11-14T19:50:04+00:00 The discussion addresses technical challenges within the Lightning Network, such as managing outdated states and transaction fees. It is recognized that while security could be improved, keeping transaction fees to a minimum relative to the channel's total value is essential for economic viability. - Miners benefit from the increase in feerate over discarded transactions when mining HTLC commitment transactions. Consequently, the need to minimize the proportion of channel value allocated to fees is highlighted, with suggestions to amend implementations that currently do not follow this principle. - The conversation also touches on Replace-by-Fee (RBF) mechanics, suggesting that increased channel fees could be extracted from the party broadcasting the commitment transaction to alleviate substantial fees upon closing channels. - SIGHASH_NOINPUT is proposed as a solution to sign HTLC refund transactions, which could simplify handling multiple fee rates. However, LN-Symmetry is considered insecure without a degree of trust between parties. - Package relay version 3 is introduced, changing how zero-value outputs are managed to prevent UTXO set growth. Anchor outputs must now be spent within the same package, impacting defensive strategies against double-spend attacks. - OP_Expire is presented, ensuring timely revelation of preimages in blockchain transactions and making them useless if not revealed promptly. This mechanism is critiqued for potentially enabling RBF without anchor outputs, leading to more efficient use of block space compared to CPFP with package relay. - Antoine's email highlights vulnerabilities in single-input commitment transactions and suggests pre-signing these with zero fees and using CPFP for necessary fee adjustments. However, there's a risk that replacement by CPFP could lead to eviction from the mempool. - An HTLC scenario explains how OP_EXPIRE can secure funds against potential attacks by enforcing timelocks. The ability of OP_Expire to prevent adversarial tactics like replacement cycling is questioned, indicating the need for further evaluation. - Overall, these discussions explore enhancements to the Lightning Network and smart contract scripting to improve security and efficiency. They address HTLCs and propose significant changes, such as introducing the OP_Expire opcode and considering soft fork upgrades for better transaction management and protection against attacks. - 2023-11-14T19:50:04+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_On-solving-pinning-replacement-cycling-and-mempool-issues-for-bitcoin-second-layers.xml b/static/bitcoin-dev/Oct_2023/combined_On-solving-pinning-replacement-cycling-and-mempool-issues-for-bitcoin-second-layers.xml index f6eeca4864..b19a245584 100644 --- a/static/bitcoin-dev/Oct_2023/combined_On-solving-pinning-replacement-cycling-and-mempool-issues-for-bitcoin-second-layers.xml +++ b/static/bitcoin-dev/Oct_2023/combined_On-solving-pinning-replacement-cycling-and-mempool-issues-for-bitcoin-second-layers.xml @@ -1,31 +1,31 @@ - + 2 Combined summary - On solving pinning, replacement cycling and mempool issues for bitcoin second-layers - 2023-11-16T02:02:45.685770+00:00 - - Antoine Riard 2023-11-15 18:14:28+00:00 - - - Antoine Riard 2023-10-22 02:27:37+00:00 - - - Antoine Riard 2023-10-22 02:27:37+00:00 - + 2025-09-26T14:21:42.988761+00:00 + python-feedgen + + + [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers Antoine Riard + 2023-10-22T02:27:00.000Z + + + Antoine Riard + 2023-11-15T18:14:00.000Z + + - python-feedgen + 2 Combined summary - On solving pinning, replacement cycling and mempool issues for bitcoin second-layers - 2023-11-16T02:02:45.685814+00:00 + 2025-09-26T14:21:42.989259+00:00 + 2023-11-15T18:14:28+00:00 The email outlines the considerations for creating a valid consensus-change based solution for Bitcoin L2, specifically regarding issues such as pinning and replacement cycling. The proposed solution should maintain non-interactive properties with off-chain counterparties, minimize fee-bumping reserves and UTXO locks, prevent malicious activities while allowing competition with ongoing fee rates, and ensure security for low-value lightning payments without relying on local knowledge of historical mempool states. It should also cater to multi-party off-chain constructions, reduce witness size through efficient scripting, guard against fee manipulation by low-hashrate miners, and be compatible with solutions to forced closure of time-sensitive off-chain states. Furthermore, it should not exacerbate problems like partial or global mempool partitioning. - A potential approach involves removing package malleability with annex and sighash_anyamount semantics, inspired by Peter Todd's op_expire proposal. However, there is no concrete design yet, and due to the complexity, any solution would require end-to-end implementation for validation, particularly for the Lightning Network. There's an acknowledgment that more mainnet experimentation is needed to address pinning, replacement cycling, and miner incentives alignment with second layers, urging further research within the Bitcoin community, especially given the importance of a reliable fee market in a post-subsidy world and sustaining a decentralized mining ecosystem. - Gleb Naumenko and the author intend to devote their research efforts to resolving these issues by examining cross-layer challenges they've previously explored together, referencing their expertise with bitcoin core and rust-lightning codebases. They plan to collaborate with Elichai Turkel on mathematical verification and risk assessments of potential fixes, aiming to reduce the fee-bumping reserve and locked UTXOs for lightning users. An issue on coordinated security handling has been reopened to bolster Lightning Network security. The sender stresses the need for game theory consideration and node network resource changes, following an open and responsible Bitcoin process, anticipating that this work will take significant time, much like the package relay design discussions that have recently advanced to review phases. Input from the Bitcoin and Lightning development community is welcomed as the solutions are developed. - 2023-11-15T18:14:28+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Ordinals-BIP-PR.xml b/static/bitcoin-dev/Oct_2023/combined_Ordinals-BIP-PR.xml index 006d68d834..942eb23b76 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Ordinals-BIP-PR.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Ordinals-BIP-PR.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Ordinals BIP PR - 2023-11-23T02:00:52.403974+00:00 - - Kostas Karasavvas 2023-11-22 11:27:03+00:00 - - - vjudeu at gazeta.pl 2023-11-21 23:10:55+00:00 - - - Kostas Karasavvas 2023-11-21 12:13:55+00:00 - - - vjudeu at gazeta.pl 2023-11-20 22:20:46+00:00 - - - Claus Ehrenberg 2023-11-09 22:32:10+00:00 - - - Casey Rodarmor 2023-11-09 02:15:05+00:00 - - - alicexbt 2023-10-27 17:05:46+00:00 - - - Alexander F. Moser 2023-10-27 09:39:44+00:00 - - - Peter Todd 2023-10-26 22:11:50+00:00 - - - Peter Todd 2023-10-26 22:05:30+00:00 - - - Luke Dashjr 2023-10-25 00:15:04+00:00 - - - Christopher Allen 2023-10-24 23:08:37+00:00 - - - Olaoluwa Osuntokun 2023-10-24 22:56:55+00:00 - - - alicexbt 2023-10-24 01:28:17+00:00 - - - Luke Dashjr 2023-10-23 18:29:50+00:00 - - - Andrew Poelstra 2023-10-23 17:43:29+00:00 - - - Ryan Breen 2023-10-23 17:26:06+00:00 - - - Tim Ruffing 2023-10-23 16:32:47+00:00 - - - Peter Todd 2023-10-23 15:35:30+00:00 - - - Léo Haf 2023-10-23 14:57:32+00:00 - - - Andrew Poelstra 2023-10-23 13:45:44+00:00 - - - Casey Rodarmor 2023-10-21 05:38:01+00:00 - + 2025-09-26T14:21:57.887652+00:00 + python-feedgen + + + [bitcoin-dev] Ordinals BIP PR Casey Rodarmor + 2023-10-21T05:38:00.000Z + + + Andrew Poelstra + 2023-10-23T13:45:00.000Z + + + Léo Haf + 2023-10-23T14:57:00.000Z + + + Peter Todd + 2023-10-23T15:35:00.000Z + + + Tim Ruffing + 2023-10-23T16:32:00.000Z + + + Ryan Breen + 2023-10-23T17:26:00.000Z + + + Andrew Poelstra + 2023-10-23T17:43:00.000Z + + + Luke Dashjr + 2023-10-23T18:29:00.000Z + + + alicexbt + 2023-10-24T01:28:00.000Z + + + Olaoluwa Osuntokun + 2023-10-24T22:56:00.000Z + + + Christopher Allen + 2023-10-24T23:08:00.000Z + + + Luke Dashjr + 2023-10-25T00:15:00.000Z + + + Peter Todd + 2023-10-26T22:05:00.000Z + + + Peter Todd + 2023-10-26T22:11:00.000Z + + + Alexander F. Moser + 2023-10-27T09:39:00.000Z + + + alicexbt + 2023-10-27T17:05:00.000Z + + + Casey Rodarmor + 2023-11-09T02:15:00.000Z + + + Claus Ehrenberg + 2023-11-09T22:32:00.000Z + + + vjudeu + 2023-11-20T22:20:00.000Z + + + Kostas Karasavvas + 2023-11-21T12:13:00.000Z + + + vjudeu + 2023-11-21T23:10:00.000Z + + + Kostas Karasavvas + 2023-11-22T11:27:00.000Z + + @@ -91,21 +116,17 @@ - python-feedgen + 2 Combined summary - Ordinals BIP PR - 2023-11-23T02:00:52.404120+00:00 + 2025-09-26T14:21:57.890232+00:00 + 2023-11-22T11:27:03+00:00 The discussion on Bitcoin ordinals highlights their design to ensure on-chain data persistence, which leads to fuller blocks and raises concerns about space competition between regular transactions and data embedding. A proposed technical solution suggests hiding ordinals behind an R-value in the witness part of a transaction input, which would reduce their size and cost while maintaining cryptographic proof and allowing for uncensorable inclusion in different types of addresses. - The role of Bitcoin Improvement Proposals (BIPs) is examined with the suggestion that they should focus on crucial protocol elements to preserve the integrity and functionality of Bitcoin. A minimalist approach is recommended to avoid overloading developers with non-essential features. Concerns are raised regarding the impartiality of BIP editors and the application of BIP 2 requirements, suggesting potential bias against proposals like ordinals. The conversation also explores the idea of listing BIPs not maintained in the official repository to challenge centralized management. - Debate surrounds the assignment and management of BIP numbers, with a proposal to automate this process using pull request numbers to address concerns about gatekeeping. This could lead to non-contiguous BIP numbers, but an offset starting at the highest manually assigned number could maintain order. Discussions also consider the subjective nature of terms in BIP 2, the workload of BIP editors, and calls for additional editorial assistance while addressing decentralization issues. - A restrained approach to BIPs is advocated, reserving them for widely-adopted standards and suggesting alternative repositories for non-BIP protocols. Transparency in the evaluation process of improvements is emphasized, as is the need to consider diverse community stakeholders in decision-making. Handling controversial proposals and recognizing the difference between technical documentation and implementation are also noted. - In a specific email, urgency is expressed concerning the progress of a PR for the Ordinals BIP. The sender seeks feedback from BIP editors to understand necessary actions for acceptance, emphasizing the importance of guidance in advancing the proposal's development process. The communication reflects professional persistence and a desire for pivotal editor interaction to facilitate the BIP's progression. - 2023-11-22T11:27:03+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-MuSig2-Descriptors.xml b/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-MuSig2-Descriptors.xml index df5bd8bb88..62f0400fdf 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-MuSig2-Descriptors.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-MuSig2-Descriptors.xml @@ -1,29 +1,31 @@ - + 2 Combined summary - Proposed BIP for MuSig2 Descriptors - 2023-11-08T17:08:56.337818+00:00 - - Salvatore Ingala 2023-11-07 11:34:46+00:00 - - - Andrew Chow 2023-10-10 22:30:21+00:00 - + 2025-09-26T14:21:55.737692+00:00 + python-feedgen + + + [bitcoin-dev] Proposed BIP for MuSig2 Descriptors Andrew Chow + 2023-10-10T22:30:00.000Z + + + Salvatore Ingala + 2023-11-07T11:34:00.000Z + + - python-feedgen + 2 Combined summary - Proposed BIP for MuSig2 Descriptors - 2023-11-08T17:08:56.337867+00:00 + 2025-09-26T14:21:55.738169+00:00 + 2023-11-07T11:34:46+00:00 The correspondence from Salvatore underscores a critical evaluation of the proposed Bitcoin Improvement Proposal (BIP) draft for MuSig2 descriptors, a new addition to Bitcoin Core intended to streamline the process for multiple signers to jointly create a single signature. The BIP draft, found on GitHub, introduces descriptors that offer an abstraction layer for defining sets of addresses and scripts within Bitcoin software. The proposal details syntax, semantics, and usage examples of MuSig2 descriptors to ensure standardization and ease of implementation for developers. - Salvatore's main point of contention lies in the utility of supporting KEY expressions with ranged derivations in the musig descriptor. He emphasizes the inefficiency of requiring each signer to derive the child xpub for each key and execute the KeyAgg algorithm multiple times when spending inputs. He proposes a more streamlined approach where KeyAgg is executed once for all inputs by appending the derivation path after the musig policy. This suggestion aims to reduce performance impact for signing devices and simplifies the creation of descriptor parsers. - The draft itself, along with the rationale behind the proposed structure and function of MuSig2 descriptors, is accessible through the provided GitHub link. Additionally, there is an active pull request to include this BIP draft in the official list of BIPs, which can be examined via the second link shared in the email. - In conclusion, while the overall goal of the BIP draft is to facilitate the use of MuSig2 descriptors, Salvatore advocates for a minimalistic approach that eschews unnecessary complexity and computational overhead unless justified by specific use cases. He suggests that a discussion on potential use cases and associated trade-offs may be beneficial if included in the BIP proposal, ensuring that the standard remains both practical and efficient. - 2023-11-07T11:34:46+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-MuSig2-PSBT-Fields.xml b/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-MuSig2-PSBT-Fields.xml index 48996d86c9..4e17d96bcc 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-MuSig2-PSBT-Fields.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-MuSig2-PSBT-Fields.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Proposed BIP for MuSig2 PSBT Fields - 2023-10-15T01:59:39.156314+00:00 - - Jonas Nick 2023-10-12 07:43:21+00:00 - - - Anthony Towns 2023-10-12 07:39:32+00:00 - - - Andrew Chow 2023-10-11 23:59:16+00:00 - - - Anthony Towns 2023-10-11 23:47:58+00:00 - - - Andrew Chow 2023-10-10 22:28:37+00:00 - + 2025-09-26T14:21:51.514034+00:00 + python-feedgen + + + [bitcoin-dev] Proposed BIP for MuSig2 PSBT Fields Andrew Chow + 2023-10-10T22:28:00.000Z + + + Anthony Towns + 2023-10-11T23:47:00.000Z + + + Andrew Chow + 2023-10-11T23:59:00.000Z + + + Anthony Towns + 2023-10-12T07:39:00.000Z + + + Jonas Nick + 2023-10-12T07:43:00.000Z + + - python-feedgen + 2 Combined summary - Proposed BIP for MuSig2 PSBT Fields - 2023-10-15T01:59:39.156379+00:00 + 2025-09-26T14:21:51.514876+00:00 - The email thread discusses the absence of adaptor signatures in BIP 327 ("MuSig2") and the rationale behind this decision. The author mentions that the BIP is already long and complicated enough without including adaptor signatures. However, it is possible to propose a separate adaptor signature BIP on top of MuSig2 in a modular fashion. The author also notes that there is no security proof for adaptor signatures except for a sketch that was written a few years ago. At the time, there seemed to be a higher demand for single-signer adaptor signatures.Despite the missing specification, some version of adaptor signatures has been added to the libsecp256k1-zkp MuSig2 module to allow experimentation. However, it is worth mentioning that alternative designs to the implementation in the libsecp256k1-zkp module exist. There is a current libsecp256k1-zkp PR for single-signer Schnorr adaptor signatures with the adaptor signature, where the point is extracted from an adaptor signature. This simplifies the API and reduces communication but makes batch verification of multiple adaptor signatures impossible.The email also touches upon the topic of anti-exfil and provides a link to libwally's protocol for anti-exfil with ecdsa signatures. The author suggests that adding support for anti-exfil and tweaks/adaptor signatures to musig capable signers would be beneficial. They mention that for signers who don't care about these features, the only difference is adding the tweak to the musig nonces before hashing/signing, which is straightforward. However, the author believes that specifying these features as part of the BIP would be an easy win, although it shouldn't be a blocker.In another email, a participant expresses disappointment at the absence of adaptor signature support in BIP 327. They mention that libsecp256k1-zkp has implemented it and provide links to the relevant code. The participant suggests adding additional fields to specify the adaptor and adaptor secret, along with changes to the PartialSigAgg. They note that signers who don't know the adaptor secret would need to ensure the validity of partial signatures provided by signers who do/might know the secret, but this depends on the protocol and cannot be automated at the PSBT level.Finally, the email includes a message from the author who shares a BIP draft for MuSig2 PSBT fields. They provide a link to the draft and mention some notable differences compared to a previous gist. The participant pubkeys field is keyed by only the aggregate xonly key, and the participant pubkeys themselves are compressed rather than xonly. 2023-10-12T07:43:21+00:00 + The email thread discusses the absence of adaptor signatures in BIP 327 ("MuSig2") and the rationale behind this decision. The author mentions that the BIP is already long and complicated enough without including adaptor signatures. However, it is possible to propose a separate adaptor signature BIP on top of MuSig2 in a modular fashion. The author also notes that there is no security proof for adaptor signatures except for a sketch that was written a few years ago. At the time, there seemed to be a higher demand for single-signer adaptor signatures.Despite the missing specification, some version of adaptor signatures has been added to the libsecp256k1-zkp MuSig2 module to allow experimentation. However, it is worth mentioning that alternative designs to the implementation in the libsecp256k1-zkp module exist. There is a current libsecp256k1-zkp PR for single-signer Schnorr adaptor signatures with the adaptor signature, where the point is extracted from an adaptor signature. This simplifies the API and reduces communication but makes batch verification of multiple adaptor signatures impossible.The email also touches upon the topic of anti-exfil and provides a link to libwally's protocol for anti-exfil with ecdsa signatures. The author suggests that adding support for anti-exfil and tweaks/adaptor signatures to musig capable signers would be beneficial. They mention that for signers who don't care about these features, the only difference is adding the tweak to the musig nonces before hashing/signing, which is straightforward. However, the author believes that specifying these features as part of the BIP would be an easy win, although it shouldn't be a blocker.In another email, a participant expresses disappointment at the absence of adaptor signature support in BIP 327. They mention that libsecp256k1-zkp has implemented it and provide links to the relevant code. The participant suggests adding additional fields to specify the adaptor and adaptor secret, along with changes to the PartialSigAgg. They note that signers who don't know the adaptor secret would need to ensure the validity of partial signatures provided by signers who do/might know the secret, but this depends on the protocol and cannot be automated at the PSBT level.Finally, the email includes a message from the author who shares a BIP draft for MuSig2 PSBT fields. They provide a link to the draft and mention some notable differences compared to a previous gist. The participant pubkeys field is keyed by only the aggregate xonly key, and the participant pubkeys themselves are compressed rather than xonly. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-OP-CAT.xml b/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-OP-CAT.xml index cf70e1b779..b221233a94 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-OP-CAT.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-OP-CAT.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed BIP for OP_CAT - 2023-11-01T20:05:42.246036+00:00 + 2025-09-26T14:22:17.263896+00:00 + python-feedgen Anthony Towns 2023-10-27 18:32:13+00:00 @@ -83,21 +84,17 @@ - python-feedgen + 2 Combined summary - Proposed BIP for OP_CAT - 2023-11-01T20:05:42.246036+00:00 + 2025-09-26T14:22:17.264071+00:00 + 2023-10-27T18:32:13+00:00 The email introduces a draft BIP proposing the activation of the OP_CAT opcode in Bitcoin tapscript. The proposed opcode allows for the concatenation of two values on the stack, providing a general-purpose way to combine objects in tapscript. This enhances the functionality and expressiveness of tapscript, enabling the construction and evaluation of merkle trees and other hashed data structures. - Enabling OP_CAT would have various use cases, including tree signatures, Post-Quantum Lamport Signatures, non-equivocation contracts in tapscript, vaults, and replicating CheckSigFromStack. Tree signatures allow for multisignature scripts with a logarithmic size in the number of public keys, while Post-Quantum Lamport Signatures require the ability to hash and concatenate values on the stack. Non-equivocation contracts provide a mechanism to punish double spending in Bitcoin payment channels, and vaults block malicious parties from stealing funds. Replicating CheckSigFromStack enables the creation of simple covenants and advanced contracts without presigning spending transactions. - OP_CAT was previously available in early versions of Bitcoin but was removed due to memory usage concerns. However, tapscript now enforces a maximum stack element size of 520 Bytes, making this opcode viable again. The specification for implementing OP_CAT includes checking the stack size, concatenating the values, and pushing the result onto the stack. A reference implementation can be found in the Elements project's interpreter.cpp file. - The email also provides several references for further reading on related topics, including program design in the UNIX environment, multisig using tree signatures, OP_CAT for quantum security, penalizing equivocation by loss of bitcoins, Bitcoin covenants, and covenants with CAT and ECDSA. These references offer additional information and insights into the proposed activation of OP_CAT as a tapscript opcode. - Overall, the proposed activation of OP_CAT aims to enhance Bitcoin tapscript by enabling the concatenation of stack values and facilitating the implementation of various use cases. The email encourages the community to provide feedback, comments, and suggestions for improvements or alternative approaches. - 2023-10-27T18:32:13+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Refreshed-BIP324.xml b/static/bitcoin-dev/Oct_2023/combined_Refreshed-BIP324.xml index c1ffa81b02..0ceaaae347 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Refreshed-BIP324.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Refreshed-BIP324.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100274+00:00 - - Tim Ruffing 2023-10-11 20:52:52+00:00 - - - Erik Aronesty 2023-02-28 21:02:41+00:00 - - - Dhruv M 2023-02-28 18:07:06+00:00 - - - Anthony Towns 2023-02-21 16:03:37+00:00 - - - Pieter Wuille 2023-02-20 15:22:30+00:00 - - - Anthony Towns 2023-02-19 23:56:02+00:00 - - - Pieter Wuille 2023-02-17 22:13:05+00:00 - - - Anthony Towns 2023-02-17 15:51:19+00:00 - - - Dhruv M 2023-02-16 17:43:22+00:00 - - - Anthony Towns 2023-01-09 08:11:05+00:00 - - - Anthony Towns 2023-01-05 23:12:50+00:00 - - - Pieter Wuille 2023-01-05 22:06:29+00:00 - - - Anthony Towns 2022-11-18 08:24:49+00:00 - - - Yuval Kogman 2022-11-12 18:52:31+00:00 - - - Pieter Wuille 2022-11-12 03:23:16+00:00 - - - Pieter Wuille 2022-11-10 21:23:44+00:00 - - - Anthony Towns 2022-11-08 03:20:23+00:00 - - - Jonas Schnelli 2022-11-03 22:26:54+00:00 - - - Murch 2022-11-03 17:53:26+00:00 - - - Vasil Dimov 2022-10-27 07:28:38+00:00 - - - Pieter Wuille 2022-10-26 16:39:02+00:00 - - - Dhruv M 2022-10-08 12:59:58+00:00 - + 2025-09-26T14:22:10.852984+00:00 + python-feedgen + + + [bitcoin-dev] Refreshed BIP324 Dhruv M + 2022-10-08T12:59:00.000Z + + + Pieter Wuille + 2022-10-26T16:39:00.000Z + + + Vasil Dimov + 2022-10-27T07:28:00.000Z + + + Murch + 2022-11-03T17:53:00.000Z + + + Jonas Schnelli + 2022-11-03T22:26:00.000Z + + + Anthony Towns + 2022-11-08T03:20:00.000Z + + + Pieter Wuille + 2022-11-10T21:23:00.000Z + + + Pieter Wuille + 2022-11-12T03:23:00.000Z + + + Yuval Kogman + 2022-11-12T18:52:00.000Z + + + Anthony Towns + 2022-11-18T08:24:00.000Z + + + Pieter Wuille + 2023-01-05T22:06:00.000Z + + + Anthony Towns + 2023-01-05T23:12:00.000Z + + + Anthony Towns + 2023-01-09T08:11:00.000Z + + + Dhruv M + 2023-02-16T17:43:00.000Z + + + Anthony Towns + 2023-02-17T15:51:00.000Z + + + Pieter Wuille + 2023-02-17T22:13:00.000Z + + + Anthony Towns + 2023-02-19T23:56:00.000Z + + + Pieter Wuille + 2023-02-20T15:22:00.000Z + + + Anthony Towns + 2023-02-21T16:03:00.000Z + + + Dhruv M + 2023-02-28T18:07:00.000Z + + + Erik Aronesty + 2023-02-28T21:02:00.000Z + + + Tim Ruffing + 2023-10-11T20:52:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Refreshed BIP324 - 2023-10-15T01:57:03.100469+00:00 + 2025-09-26T14:22:10.855525+00:00 - The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. 2023-10-11T20:52:52+00:00 + The discussion among Bitcoin developers revolves around the possibility of merging short and long command structures into a single variable-length command structure. Pieter Wuille suggests using a simple variable-length integer approach, with each byte indicating whether another byte follows. This would provide more space for message IDs and simplify the allocation process. The conversation also addresses the need for negotiation and coordination mechanisms for assigning message IDs, as well as the potential impact on bandwidth and implementation complexity.In order to increase space while maintaining conservatism, suggestions are made to treat the first bit as a 2-byte message ID or use an explicit signaling system. The group agrees to exclude rarely-sent commands from assigning short IDs. There is a discussion on introducing novel 1-byte messages before allocating them and reserving a byte for one-shot messages is discouraged. The mapping table between 1 byte IDs and commands is discussed, with three possible solutions presented: introducing a fixed initial table using the BIP process, maintaining a purely local and hardcoded internal mapping, or negotiating the mapping dynamically without a fixed table.The network is expected to have 35 message types with around 256 possible IDs. To increase conservatism, the first bit could be used to signal a 2-byte message ID or the short ID 0xFF could be reserved. The main benefit of short IDs is bandwidth optimization, but not all message types need to use them. It is suggested that only frequently sent messages should reserve a short ID or exclude one-time message types from assigning a short ID.Pieter Wuille proposes using the BIP process to introduce a fixed initial table for the mapping between IDs and commands. Murch suggests using the first bit to signal a 2-byte message ID, with less prevalent message types utilizing a 2-byte ID to mitigate collision risks.Pieter Wuille recently sent an email proposing the idea of using the BIP process to improve the protocol. Vasil Dimov agrees with the proposal and includes a quote from Edsger W. Dijkstra about considering the long-term implications of actions.The refreshed proposal for BIP324, a new bitcoin peer-to-peer protocol, is open for review by the community members. The proposal includes features such as opportunistic encryption, bandwidth reduction, and upgradability. Changes have been made since the last public appearance, including Elligator-swift encoding for pubkeys, x-only ECDH secret derivation, transport versioning, traffic shapability, and a shapable handshake. Links to the BIP pull request, historical and current PRs, and a gist of the previous appearance are provided for review and comments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml b/static/bitcoin-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml index 6ee6934bec..3f3869f53b 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Removing channel reserve for mobile wallet users - 2023-11-01T20:44:02.508794+00:00 + 2025-09-26T14:21:47.287672+00:00 + python-feedgen ziggie 2023-10-24 09:12:19+00:00 @@ -47,29 +48,21 @@ - python-feedgen + 2 Combined summary - Removing channel reserve for mobile wallet users - 2023-11-01T20:44:02.509787+00:00 + 2025-09-26T14:21:47.287833+00:00 + 2023-10-24T09:12:19+00:00 The email discusses the review of an implementation called lnd and mentions that it currently checks that the reserve is at least the dust limit, which the sender finds reasonable. However, with the proposed protocol update, this requirement will need to be modified. The sender expresses anticipation for the Blip, which is likely a reference to an upcoming communication or announcement related to the protocol update. - -Ziggie has requested Bastien to open a pull request (PR) to the bLIP repository. It is unclear what the statement "it doesn't work currently without it" refers to. There is a question regarding whether this is an issue specific to the implementation. Bastien suggests that if the channel reserve is removed, then there would be no need to consider the dust limit. - +Ziggie has requested Bastien to open a pull request (PR) to the bLIP repository. It is unclear what the statement "it doesn't work currently without it" refers to. There is a question regarding whether this is an issue specific to the implementation. Bastien suggests that if the channel reserve is removed, then there would be no need to consider the dust limit. The sender expresses support for introducing the 0-channel reserve option into the protocol. They suggest adding it via a Blip and mention that it would be useful to have the option to open zero-reserve channels. They also propose restricting this feature through a channel interceptor. The sender suggests including information on how to prove possible cheating attacks in the spec/blip. They ask if the recipient has already reported the issue. - There is a conversation between Tony and Kulpreet regarding the non-custodial wallet's ability to react to revoked commitments. Tony mentions that the important delay is the `to_self_delay` parameter, which is usually set to two weeks. He explains that the phone only needs to be online once every two weeks to detect the revoked commit and react to it. Mobile wallets should run frequent background jobs to perform these checks and notify the user if they've been unable to get enough CPU time to run those checks. Tony also clarifies that this discussion becomes irrelevant when removing the reserve requirement because there will always be at least one output since the channel total capacity stays greater than dust. This doesn't add anything new as this distinction already exists today and doesn't add any complication to the protocol. - John Carvalho, CEO of Synonym.to, mentions that they recently removed the reserve for their users in Bitkit, down to the dust limit. After learning more about it and the reasoning behind the reserve, they realized the design is nonsensical. They fully support Bastien's suggestion for more practical and user-friendly approaches as the reserve balance causes customer support issues and confusing UX. - Bastien acknowledges the concerns raised about the Lightning Service Provider (LSP) not keeping a reserve, stating that it's easier for them to steal since the offline concern is on the mobile user. He mentions that there are no reliable watch tower integrations/products yet to mitigate this. Tony asks if users should also be able to publish a previous commitment to solve this issue and shares a link to the GitHub repository where dust reserves still apply. - -Bastien responds to Tony, explaining that in Phoenix (a wallet), they've allowed the wallet user to have no reserve but require the LSP to meet the usual reserve requirements. He argues that the channel reserve is useful between routing nodes because they don't have a "service provider" relationship, so there is more incentive to always try cheating. He suggests removing the reserve between wallet users and their LSP, partly because LSPs are not anonymous nodes who don't care about their reputation. Tony asks for clarification on whether the proposal includes removing the 1% reserve requirement network-wide or just between mobile wallets and LSPs if they opt-in. He also mentions the dust reserve limit. - +Bastien responds to Tony, explaining that in Phoenix (a wallet), they've allowed the wallet user to have no reserve but require the LSP to meet the usual reserve requirements. He argues that the channel reserve is useful between routing nodes because they don't have a "service provider" relationship, so there is more incentive to always try cheating. He suggests removing the reserve between wallet users and their LSP, partly because LSPs are not anonymous nodes who don't care about their reputation. Tony asks for clarification on whether the proposal includes removing the 1% reserve requirement network-wide or just between mobile wallets and LSPs if they opt-in. He also mentions the dust reserve limit. Bastien starts a discussion by arguing for the removal of the channel reserve requirement for channels between mobile wallet users and their service provider. He acknowledges that the first reaction may be resistance due to it being a security parameter. However, he explains that the current design has drawbacks such as capital efficiency and user experience issues. He believes that removing the reserve on both sides can still maintain security through penalty transactions and reputation-based accountability. He also compares the proposed approach to LN-symmetry (Eltoo) and argues that if it's acceptable for Eltoo, it should be considered here as well. - In summary, the email covers discussions about the review of an implementation, the proposal to introduce the 0-channel reserve option, concerns about the LSP not keeping a reserve, and arguments for removing the channel reserve requirement between mobile wallet users and their service provider. The sender emphasizes the need for practical and user-friendly approaches while addressing security concerns through penalty transactions and reputation-based accountability. - 2023-10-24T09:12:19+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml b/static/bitcoin-dev/Oct_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml index c521c5b761..d47ad5211e 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml @@ -1,53 +1,67 @@ - + 2 Combined summary - Scaling Lightning With Simple Covenants - 2023-11-17T02:04:15.764762+00:00 - - jlspc 2023-11-15 19:59:37+00:00 - - - jlspc 2023-10-06 16:26:33+00:00 - - - jlspc 2023-10-06 16:26:33+00:00 - - - jlspc 2023-09-28 15:56:11+00:00 - - - Antoine Riard 2023-09-26 16:42:34+00:00 - - - ZmnSCPxj 2023-09-19 07:44:48+00:00 - - - ZmnSCPxj 2023-09-18 04:14:55+00:00 - - - Erik Aronesty 2023-09-17 11:32:52+00:00 - - - jlspc 2023-09-17 00:59:39+00:00 - - - jlspc 2023-09-17 00:56:04+00:00 - - - jlspc 2023-09-17 00:52:13+00:00 - - - Antoine Riard 2023-09-11 05:27:25+00:00 - - - Rusty Russell 2023-09-11 02:13:52+00:00 - - - Anthony Towns 2023-09-11 00:56:40+00:00 - - - jlspc 2023-09-08 18:54:46+00:00 - + 2025-09-26T14:21:45.139585+00:00 + python-feedgen + + + [bitcoin-dev] Scaling Lightning With Simple Covenants jlspc + 2023-09-08T18:54:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2023-09-11T00:56:00.000Z + + + [bitcoin-dev] " Rusty Russell + 2023-09-11T02:13:00.000Z + + + Antoine Riard + 2023-09-11T05:27:00.000Z + + + jlspc + 2023-09-17T00:52:00.000Z + + + jlspc + 2023-09-17T00:56:00.000Z + + + jlspc + 2023-09-17T00:59:00.000Z + + + Erik Aronesty + 2023-09-17T11:32:00.000Z + + + ZmnSCPxj + 2023-09-18T04:14:00.000Z + + + ZmnSCPxj + 2023-09-19T07:44:00.000Z + + + Antoine Riard + 2023-09-26T16:42:00.000Z + + + jlspc + 2023-09-28T15:56:00.000Z + + + jlspc + 2023-10-06T16:26:00.000Z + + + jlspc + 2023-11-15T19:59:00.000Z + + @@ -63,23 +77,18 @@ - python-feedgen + 2 Combined summary - Scaling Lightning With Simple Covenants - 2023-11-17T02:04:15.764876+00:00 + 2025-09-26T14:21:45.141270+00:00 + 2023-11-15T19:59:37+00:00 The recent discussions among programmers have centered on enhancing the Lightning Network's operation and scalability. John has analyzed trade-offs between trust/safety and capital efficiency, suggesting a prepayment system to balance channel lifetime risks and fund adjustments. He has calculated the scalability of timeout-tree leaves on-chain using a Python program and contributed to a paper on passive rollovers, detailing the functioning of commitment transactions in hierarchical channels. - Antoine has highlighted scaling issues for off-chain constructions, like liquidity imbalances, proposing improvements such as on-chain splicing. He also expressed concerns about coordinating a large number of users and mentioned cryptographic tools for better scalability. - -John agreed with Antoine on addressing the needs of casual users, proposing hierarchical channels and timeout-trees for their convenience. He acknowledged practical challenges in coordination for required signatures and emphasized solutions that limit interactivity. John recommended a consensus rule change to deal with the "thundering herd" problem by basing timeout-tree expirations on low-fee block occurrences. - -The email defines user categories as "casual" or "dedicated," discussing trust assumptions and different scaling aspects: onboarding, transactional, and user resource scaling. It questions the feasibility of casual users engaging in future time-bound actions and highlights concerns about fund access, mempool congestion, and fee risk mitigation. - -The correspondence outlines critical issues in off-chain scaling, such as enforcement costs in channel factories and the trade-off between trust and capital efficiency. The paper suggests tolerating an increase in transactions for rule enforcement in mature systems. It contemplates the role of "dedicated users" within the fee structure and the balancing act between capital commitment and efficiency. - +John agreed with Antoine on addressing the needs of casual users, proposing hierarchical channels and timeout-trees for their convenience. He acknowledged practical challenges in coordination for required signatures and emphasized solutions that limit interactivity. John recommended a consensus rule change to deal with the "thundering herd" problem by basing timeout-tree expirations on low-fee block occurrences. +The email defines user categories as "casual" or "dedicated," discussing trust assumptions and different scaling aspects: onboarding, transactional, and user resource scaling. It questions the feasibility of casual users engaging in future time-bound actions and highlights concerns about fund access, mempool congestion, and fee risk mitigation. +The correspondence outlines critical issues in off-chain scaling, such as enforcement costs in channel factories and the trade-off between trust and capital efficiency. The paper suggests tolerating an increase in transactions for rule enforcement in mature systems. It contemplates the role of "dedicated users" within the fee structure and the balancing act between capital commitment and efficiency. The email proposes covenant-based solutions like CheckTemplateVerify (CTV) or AnyPrevOut (APO) for creating scalable channels without all participants' signatures. This approach reduces the need for co-owning on-chain UTXOs, enhancing scalability. It recommends integrating simple covenants and off-chain transaction methods into Bitcoin's consensus rules to reduce the on-chain footprint and facilitate off-chain operations, making the Lightning Network more accessible for payments. - 2023-11-15T19:59:37+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Solving-CoinPool-high-interactivity-issue-with-cut-through-update-of-Taproot-leaves.xml b/static/bitcoin-dev/Oct_2023/combined_Solving-CoinPool-high-interactivity-issue-with-cut-through-update-of-Taproot-leaves.xml index 084c802cb7..9beebb64a8 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Solving-CoinPool-high-interactivity-issue-with-cut-through-update-of-Taproot-leaves.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Solving-CoinPool-high-interactivity-issue-with-cut-through-update-of-Taproot-leaves.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Solving CoinPool high-interactivity issue with cut-through update of Taproot leaves - 2023-10-15T01:58:55.359446+00:00 - - Johan Torås Halseth 2023-10-12 09:31:26+00:00 - - - Johan Torås Halseth 2023-10-05 07:38:24+00:00 - - - Antoine Riard 2023-10-05 01:13:06+00:00 - - - Johan Torås Halseth 2023-10-03 11:24:20+00:00 - - - Antoine Riard 2023-09-26 15:36:26+00:00 - - - ZmnSCPxj 2023-09-26 06:50:50+00:00 - - - Antoine Riard 2023-09-25 18:18:36+00:00 - + 2025-09-26T14:22:08.701639+00:00 + python-feedgen + + + [bitcoin-dev] Solving CoinPool high-interactivity issue with cut-through update of Taproot leaves Antoine Riard + 2023-09-25T18:18:00.000Z + + + ZmnSCPxj + 2023-09-26T06:50:00.000Z + + + Antoine Riard + 2023-09-26T15:36:00.000Z + + + Johan Torås Halseth + 2023-10-03T11:24:00.000Z + + + Antoine Riard + 2023-10-05T01:13:00.000Z + + + Johan Torås Halseth + 2023-10-05T07:38:00.000Z + + + Johan Torås Halseth + 2023-10-12T09:31:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Solving CoinPool high-interactivity issue with cut-through update of Taproot leaves - 2023-10-15T01:58:55.359525+00:00 + 2025-09-26T14:22:08.702540+00:00 - In the email, Johan discusses the concept of using a merkle root to track participants' keys and balances in a cryptocurrency system. He provides a demo script that shows how pubkeys and balances can be committed, how data can be traversed and modified, and how signatures can be validated for exiting users. Johan mentions that the script can likely be optimized and explains that the size of the script and witness will grow as more users exit a pool. He suggests that this growth in size would not be an issue in most cooperative settings.Johan also proposes the idea of performing the exit process off-chain, allowing offline users to revert back to the original coinpool output when they come back online. He believes this could work as long as the committed balances and keys remain compatible. The only change needed would be updating the merkle inclusion proofs in the jointly signed transactions. Johan asks Antoine if this functionality aligns with what he was looking for.Antoine's email discusses the use of OP_EVICT in the context of an off-chain payment pool. He expresses concerns about the safety of using OP_EVICT and mentions TLUV or MERKLESUB as possible alternative solutions. Antoine notes that there is currently no sound covenant proposal that combines TLUV and EVICT-like semantics while still allowing for unilateral withdrawal of promised balances. He expresses his interest in finding a better direction to solve the high interactivity issue of channel factory and payment pool.ZmnSCPxj reaches out to Antoine to inquire about the suitability of using "OP_EVICT" for an unknown purpose. The email lacks contextual information but includes a link to a mailing list archive for further reference.The email discusses the issue of interactivity constraints in payment pools and channel factories. It highlights the importance of ensuring the security of user funds and the need for unanimous agreement on updates to off-chain balances. Various proposed solutions are mentioned, including the introduction of a coordinator, partitioning balances, or layering balances among off-chain user subsets. The email also discusses the challenge of mitigating equivocation of off-chain balances and suggests punishing cheating counterparties through an external fidelity bond.The author proposes a solution to prevent off-chain group equivocation by proactively editing the funding utxo of the pool or factory. This approach involves registering new off-chain subgroups as needed and includes the concept of "cut-through" spends to update multiple leaves with a single witness. The email provides an example scenario illustrating how this solution would work in practice. The author believes that such a solution could also reduce the chain space consumed during mass pool withdrawals.Overall, the emails cover various topics related to cryptocurrency systems, including the use of merkle roots, OP_EVICT, alternative solutions, and the interactivity issue in payment pools and channel factories. 2023-10-12T09:31:26+00:00 + In the email, Johan discusses the concept of using a merkle root to track participants' keys and balances in a cryptocurrency system. He provides a demo script that shows how pubkeys and balances can be committed, how data can be traversed and modified, and how signatures can be validated for exiting users. Johan mentions that the script can likely be optimized and explains that the size of the script and witness will grow as more users exit a pool. He suggests that this growth in size would not be an issue in most cooperative settings.Johan also proposes the idea of performing the exit process off-chain, allowing offline users to revert back to the original coinpool output when they come back online. He believes this could work as long as the committed balances and keys remain compatible. The only change needed would be updating the merkle inclusion proofs in the jointly signed transactions. Johan asks Antoine if this functionality aligns with what he was looking for.Antoine's email discusses the use of OP_EVICT in the context of an off-chain payment pool. He expresses concerns about the safety of using OP_EVICT and mentions TLUV or MERKLESUB as possible alternative solutions. Antoine notes that there is currently no sound covenant proposal that combines TLUV and EVICT-like semantics while still allowing for unilateral withdrawal of promised balances. He expresses his interest in finding a better direction to solve the high interactivity issue of channel factory and payment pool.ZmnSCPxj reaches out to Antoine to inquire about the suitability of using "OP_EVICT" for an unknown purpose. The email lacks contextual information but includes a link to a mailing list archive for further reference.The email discusses the issue of interactivity constraints in payment pools and channel factories. It highlights the importance of ensuring the security of user funds and the need for unanimous agreement on updates to off-chain balances. Various proposed solutions are mentioned, including the introduction of a coordinator, partitioning balances, or layering balances among off-chain user subsets. The email also discusses the challenge of mitigating equivocation of off-chain balances and suggests punishing cheating counterparties through an external fidelity bond.The author proposes a solution to prevent off-chain group equivocation by proactively editing the funding utxo of the pool or factory. This approach involves registering new off-chain subgroups as needed and includes the concept of "cut-through" spends to update multiple leaves with a single witness. The email provides an example scenario illustrating how this solution would work in practice. The author believes that such a solution could also reduce the chain space consumed during mass pool withdrawals.Overall, the emails cover various topics related to cryptocurrency systems, including the use of merkle roots, OP_EVICT, alternative solutions, and the interactivity issue in payment pools and channel factories. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2023/combined_Taproot-Assets-on-Mainnet-Announcing-tapd-v0-3-0-alpha.xml b/static/bitcoin-dev/Oct_2023/combined_Taproot-Assets-on-Mainnet-Announcing-tapd-v0-3-0-alpha.xml index f32a2c6f28..1568fc8e8b 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Taproot-Assets-on-Mainnet-Announcing-tapd-v0-3-0-alpha.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Taproot-Assets-on-Mainnet-Announcing-tapd-v0-3-0-alpha.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Taproot Assets on Mainnet: Announcing tapd v0.3.0-alpha - 2023-10-21T01:54:05.224487+00:00 - - Peter Todd 2023-10-18 22:02:42+00:00 - - - Olaoluwa Osuntokun 2023-10-18 20:20:03+00:00 - + 2025-09-26T14:22:02.116123+00:00 + python-feedgen + + + [bitcoin-dev] Taproot Assets on Mainnet: Announcing tapd v0.3.0-alpha Olaoluwa Osuntokun + 2023-10-18T20:20:00.000Z + + + Peter Todd + 2023-10-18T22:02:00.000Z + + - python-feedgen + 2 Combined summary - Taproot Assets on Mainnet: Announcing tapd v0.3.0-alpha - 2023-10-21T01:54:05.224530+00:00 + 2025-09-26T14:22:02.116616+00:00 - In the email, the sender mentions that there is a missing citation to their scalable asset transfer work from 2017. They provide a link to the work: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer. The sender also mentions that the key concepts in universes are very similar.The sender then announces the release of tapd v0.3.0-alpha, which is the first software release that supports the Taproot Asset Protocol on mainnet. They provide a link to the deterministic and reproducible release: https://github.com/lightninglabs/taproot-assets/releases/tag/v0.3.0. Additionally, they share a blog post about the launch of the protocol: https://lightning.engineering/posts/2023-10-18-taproot-assets-v0.3/.For those interested in monitoring the usage and activity of the protocol, the sender mentions that two Universes servers are being run - one for mainnet and one for testnet. They provide the links to these servers: - Mainnet: https://universe.lightning.finance/v1/taproot-assets/universe/roots- Testnet: https://testnet.universe.lightning.finance/v1/taproot-assets/universe/rootsThe sender also mentions that there is REST API documentation available for the Universe servers, which can be found here: https://lightning.engineering/api-docs/api/taproot-assets/rest-endpoints. They mention that users can interact with the servers directly via gRPC as well. Users have the option to run their own Universe server and federate with other universe servers using the relevant `tapcli universe federation` command.A technical specification for the Universe/Multiverse protocol is provided in the BIP located here: https://github.com/Roasbeef/bips/blob/bip-tap-pr/bip-tap-universe.mediawiki. The sender explains that a Universe server is used by clients to verify new asset issuance, archive off-chain transaction data, and transmit proof information for transfers. They mention that a Universe data structure is an authenticated merkle-sum sparse merkle tree that maps an `(outpoint, scriptKey)` tuple to proof data. The `scriptKey` is described as the protocol's version of the pkScript/scriptPubkey.The email also mentions that Bitcoin transactions are signed and verified under the hood, and a mapping from an asset state transition to a "virtual" transaction can be found here: https://github.com/Roasbeef/bips/blob/bip-tap-pr/bip-tap-vm.mediawiki. The sender highlights that reusing Bitcoin Script in the first asset script version allows higher-level applications to use a familiar PSBT-like structure (vPSBTs) to construct off-chain multi-party interactions. They provide an example of using PSTBs, vPSBTs, and `SIGHASH_NONE` to construct a protocol for non-interactive, non-custodial swaps: https://github.com/lightninglabs/taproot-assets/issues/577.In conclusion, the sender expresses their excitement about the mainnet alpha release of the Taproot Asset Protocol and invites experimentation and feedback to further improve the protocol. They express gratitude to those who provided critical feedback for earlier versions of the protocol. 2023-10-18T22:02:42+00:00 + In the email, the sender mentions that there is a missing citation to their scalable asset transfer work from 2017. They provide a link to the work: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer. The sender also mentions that the key concepts in universes are very similar.The sender then announces the release of tapd v0.3.0-alpha, which is the first software release that supports the Taproot Asset Protocol on mainnet. They provide a link to the deterministic and reproducible release: https://github.com/lightninglabs/taproot-assets/releases/tag/v0.3.0. Additionally, they share a blog post about the launch of the protocol: https://lightning.engineering/posts/2023-10-18-taproot-assets-v0.3/.For those interested in monitoring the usage and activity of the protocol, the sender mentions that two Universes servers are being run - one for mainnet and one for testnet. They provide the links to these servers: - Mainnet: https://universe.lightning.finance/v1/taproot-assets/universe/roots- Testnet: https://testnet.universe.lightning.finance/v1/taproot-assets/universe/rootsThe sender also mentions that there is REST API documentation available for the Universe servers, which can be found here: https://lightning.engineering/api-docs/api/taproot-assets/rest-endpoints. They mention that users can interact with the servers directly via gRPC as well. Users have the option to run their own Universe server and federate with other universe servers using the relevant `tapcli universe federation` command.A technical specification for the Universe/Multiverse protocol is provided in the BIP located here: https://github.com/Roasbeef/bips/blob/bip-tap-pr/bip-tap-universe.mediawiki. The sender explains that a Universe server is used by clients to verify new asset issuance, archive off-chain transaction data, and transmit proof information for transfers. They mention that a Universe data structure is an authenticated merkle-sum sparse merkle tree that maps an `(outpoint, scriptKey)` tuple to proof data. The `scriptKey` is described as the protocol's version of the pkScript/scriptPubkey.The email also mentions that Bitcoin transactions are signed and verified under the hood, and a mapping from an asset state transition to a "virtual" transaction can be found here: https://github.com/Roasbeef/bips/blob/bip-tap-pr/bip-tap-vm.mediawiki. The sender highlights that reusing Bitcoin Script in the first asset script version allows higher-level applications to use a familiar PSBT-like structure (vPSBTs) to construct off-chain multi-party interactions. They provide an example of using PSTBs, vPSBTs, and `SIGHASH_NONE` to construct a protocol for non-interactive, non-custodial swaps: https://github.com/lightninglabs/taproot-assets/issues/577.In conclusion, the sender expresses their excitement about the mainnet alpha release of the Taproot Asset Protocol and invites experimentation and feedback to further improve the protocol. They express gratitude to those who provided critical feedback for earlier versions of the protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2024/combined_BIP-DLEQ.xml b/static/bitcoin-dev/Oct_2024/combined_BIP-DLEQ.xml index 6b19f76ead..bfb6f68fab 100644 --- a/static/bitcoin-dev/Oct_2024/combined_BIP-DLEQ.xml +++ b/static/bitcoin-dev/Oct_2024/combined_BIP-DLEQ.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - BIP: DLEQ - 2024-10-27T02:27:26.174140+00:00 - - waxwing/ AdamISZ 2024-10-25 14:49:00+00:00 - - - Andrew Toth 2024-10-24 01:51:00+00:00 - + 2025-09-26T14:27:52.960950+00:00 + python-feedgen + + + BIP: DLEQ Andrew Toth + 2024-10-24T01:51:00.000Z + + + waxwing/ AdamISZ + 2024-10-25T14:49:00.000Z + + - python-feedgen + 2 Combined summary - BIP: DLEQ - 2024-10-27T02:27:26.174191+00:00 + 2025-09-26T14:27:52.961467+00:00 + 2024-10-25T14:49:00+00:00 The discussion revolves around a Bitcoin Improvement Proposal (BIP) geared towards standardizing the generation and verification of discrete logarithm equality proofs (DLEQ proofs) within the context of the secp256k1 elliptic curve, crucial for Bitcoin and similar cryptocurrencies. This proposal is inspired by advancements in ECDSA adaptor signatures and aims for compatibility with implementations like those by BlockstreamResearch. It introduces a method for creating 64-byte zero-knowledge proofs, enabling provers to demonstrate the relationship between elliptic curve points and a scalar without compromising sensitive information. Such proofs are essential in applications like Elliptic Curve Diffie-Hellman (ECDH), where it's necessary to prove that the same secret key is used for generating public keys and their shared secret, thereby maintaining secrecy. - The impetus behind this BIP is primarily to enhance the security and reliability of silent payments in Partially Signed Bitcoin Transactions (PSBTs). It seeks to fulfill the requirements of BIP352, which demands that senders compute output scripts using ECDH shared secrets derived from the same secret keys employed for signing inputs. The rationale is to mitigate the risk of fund loss due to incorrectly generated output scripts, which could still be technically valid but potentially lead to lost funds when broadcasted. By facilitating the generation of DLEQ proofs for these ECDH shared secrets, the proposal allows signatories to verify the correctness of their output scripts to others without revealing their private keys. - The BIP details the algorithms for both generating and verifying DLEQ proofs. The generation process requires a secret key, its corresponding public key, and auxiliary random data to produce a verifiable proof. Verification is achieved by using the public keys, the multiplication result of these keys, and the proof itself. A successful verification confirms the validity of the proof and the accurate computation of the shared secret, highlighting the BIP's contribution to enhancing cryptographic operations' security and verifiability within the Bitcoin ecosystem. This initiative marks a significant advancement in blockchain technology, emphasizing the importance of secure and verifiable cryptographic practices. - 2024-10-25T14:49:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml b/static/bitcoin-dev/Oct_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml index 4a9927f576..389f963e21 100644 --- a/static/bitcoin-dev/Oct_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml +++ b/static/bitcoin-dev/Oct_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml @@ -1,47 +1,52 @@ - + 2 Combined summary - Demonstrating Pinning Attacks under Real-World Conditions - 2024-10-13T02:26:41.059288+00:00 - - Antoine Riard 2024-10-12 04:46:00+00:00 - - - waxwing/ AdamISZ 2024-10-11 15:01:00+00:00 - - - Antoine Riard 2024-10-11 00:21:00+00:00 - - - Antoine Riard 2024-09-03 20:12:00+00:00 - - - Peter Todd 2024-09-03 12:58:00+00:00 - - - Antoine Riard 2024-08-27 21:10:00+00:00 - + 2025-09-26T14:27:55.073462+00:00 + python-feedgen + + + Demonstrating Pinning Attacks under Real-World Conditions Antoine Riard + 2024-08-27T21:10:00.000Z + + + Peter Todd + 2024-09-03T12:58:00.000Z + + + Antoine Riard + 2024-09-03T20:12:00.000Z + + + Antoine Riard + 2024-10-11T00:21:00.000Z + + + waxwing/ AdamISZ + 2024-10-11T15:01:00.000Z + + + Antoine Riard + 2024-10-12T04:46:00.000Z + + - python-feedgen + 2 Combined summary - Demonstrating Pinning Attacks under Real-World Conditions - 2024-10-13T02:26:41.059346+00:00 + 2025-09-26T14:27:55.074239+00:00 + 2024-10-12T04:46:00+00:00 The conversation starts with the recognition of a need for clear, step-by-step instructions for volunteers interested in setting up new nodes, focusing on the use of current and default installations of Core/btcd along with lnd/cln/ldk. It delves into specifics such as the amount required in channels, the necessary number of channels, the relevance of channel types, volunteer interconnectivity, desired network topology, and the significance of network connectivity and Tor usage. This discussion illuminates the technical intricacies involved in setting up these nodes and underscores the importance of detailed guidance for volunteers with varying expertise levels. - The topic shifts to the exploration of real-world pinning attacks against production lightning nodes and the broader context of security vulnerabilities within the bitcoin network. The reluctance of developers to engage in real-world demonstrations of these exploits is highlighted, alongside the optimism for improved evaluations and reproductions of bitcoin security exploits. Drawing parallels with major information security conferences, there's an anticipation that increased scrutiny of security flaws will bolster the bitcoin ecosystem's resilience. This part of the discussion emphasizes the critical focus on security vulnerabilities and the proactive measures needed to safeguard blockchain technologies. - Antoine Riard discusses his personal commitment to testing without affecting CPU or RAM functionalities, focusing instead on transaction-relay and mempool logic. He proposes running a node on the mainnet to exploit channels for liquidity rebalancing, committing his own liquidity for this purpose. Additionally, Riard mentions a $100 donation to the OTS project, highlighting his support for its notarization services. His approach to handling transactions cautiously to avoid penalties reflects a nuanced understanding of the risks involved. - Furthermore, Riard has authorized attack tests on his Lightning node, part of the Alice OpenTimestamps calendar, until October 1st, emphasizing operational constraints due to the server's role in a production environment. Despite potential disruptions, the impact is considered minimal thanks to the redundancy of the OpenTimestamps protocol. This section outlines the conditions under which the testing should proceed, including reimbursement for any incurred expenses and encouragement for testers to make donations to the OTS community. - -Lastly, the email touches on Dave Harding's suggestion to establish "free-to-pwn" lightning nodes on the mainnet for conducting sophisticated cross-layer attacks like pinning. This initiative aims to bridge the gap between private testing and public verifiability, highlighting the differences in conducting attacks in testnets versus the mainnet. Antoine addresses the potential criticisms regarding the complexity of full-node software and lightning implementations, advocating for transparency and public demonstrations to uncover vulnerabilities, thereby fostering a more secure and trustworthy bitcoin ecosystem. - 2024-10-12T04:46:00+00:00 +Lastly, the email touches on Dave Harding's suggestion to establish "free-to-pwn" lightning nodes on the mainnet for conducting sophisticated cross-layer attacks like pinning. This initiative aims to bridge the gap between private testing and public verifiability, highlighting the differences in conducting attacks in testnets versus the mainnet. Antoine addresses the potential criticisms regarding the complexity of full-node software and lightning implementations, advocating for transparency and public demonstrations to uncover vulnerabilities, thereby fostering a more secure and trustworthy bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2024/combined_OP-ZKP-updates.xml b/static/bitcoin-dev/Oct_2024/combined_OP-ZKP-updates.xml index 8ca80dec7f..efb5868e0f 100644 --- a/static/bitcoin-dev/Oct_2024/combined_OP-ZKP-updates.xml +++ b/static/bitcoin-dev/Oct_2024/combined_OP-ZKP-updates.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - OP_ZKP updates - 2024-10-15T02:24:46.644195+00:00 - - Weiji Guo 2024-10-14 09:00:00+00:00 - - - Weiji Guo 2024-08-28 15:33:00+00:00 - - - Weiji Guo 2024-07-22 22:38:00+00:00 - - - Weikeng Chen 2024-07-22 18:45:00+00:00 - - - Weiji Guo 2024-07-22 14:05:00+00:00 - + 2025-09-26T14:27:57.190295+00:00 + python-feedgen + + + OP_ZKP updates Weiji Guo + 2024-07-22T14:05:00.000Z + + + Weikeng Chen + 2024-07-22T18:45:00.000Z + + + Weiji Guo + 2024-07-22T22:38:00.000Z + + + Weiji Guo + 2024-08-28T15:33:00.000Z + + + Weiji Guo + 2024-10-14T09:00:00.000Z + + - python-feedgen + 2 Combined summary - OP_ZKP updates - 2024-10-15T02:24:46.644247+00:00 + 2025-09-26T14:27:57.191077+00:00 - The recent updates in cryptographic solutions within the domain of open application circuits emphasize a shift towards recursive verification to streamline the process. This approach negates the requirement to publish each application circuit's verification key on-chain, opting instead for a singular circuit verified through recursion. A dedicated GitHub organization and repository, named "tea-horse," have been established to facilitate the sharing of ideas and developments related to this innovative strategy. While the repository is currently in the early stages of development, it is expected to become a valuable resource for those interested in contributing to or understanding the project further. The links to both the GitHub organization and the specific repository are made available for easy access. - + 2024-10-14T09:00:00+00:00 + The recent updates in cryptographic solutions within the domain of open application circuits emphasize a shift towards recursive verification to streamline the process. This approach negates the requirement to publish each application circuit's verification key on-chain, opting instead for a singular circuit verified through recursion. A dedicated GitHub organization and repository, named "tea-horse," have been established to facilitate the sharing of ideas and developments related to this innovative strategy. While the repository is currently in the early stages of development, it is expected to become a valuable resource for those interested in contributing to or understanding the project further. The links to both the GitHub organization and the specific repository are made available for easy access. The discussion also delves into the technical requisites for implementing Dory, a cryptographic solution that necessitates pairing-friendly curves, contrasting with secp256k1's lack of support for pairing operations. This distinction underscores the importance of selecting cryptographic curves that align with the operational requirements of Dory, highlighting its need for pairing to function properly. Despite Dory's promise in terms of transparency and efficiency, its larger proof size compared to other solutions presents a challenge, illustrating the complexities involved in choosing a cryptographic framework that balances technical specifications with desired outcomes such as transparency and scalability. - Weiji Guo highlighted a technical limitation regarding the compatibility of Dory with secp256k1, pointing out that Dory's reliance on pairing operations, which secp256k1 does not support, poses a significant hurdle. This highlights the need for further exploration or alternative solutions to overcome this compatibility issue, reflecting a nuanced understanding of cryptographic principles necessary to address these challenges. - The OP_ZKP proposal aims to integrate Zero-Knowledge Proofs within Bitcoin transactions by identifying an appropriate ZKP scheme that meets several high-level requirements. These include minimal security assumptions, small block size consumption, and the capability for batched verification and aggregated proving without necessitating a trusted setup. The Inner Product Argument (IPA) emerges as a potential candidate due to its transparent setup, compatibility with secp256k1, and relatively small proof size. However, challenges such as linear verification time and scalability of verification keys remain. Aggregated proving techniques are suggested to mitigate these issues, although concerns about the deployment of large verification keys and the overall system complexity persist. Future considerations involve evaluating the performance impact on lower-powered devices and potentially exploring alternative schemes like Dory, should unresolved issues with IPA persist. For those interested in further reading on SNARKs misconceptions and Torus-based optimization, additional resources are provided, including detailed articles from [a16zcrypto](https://a16zcrypto.com/posts/article/17-misconceptions-about-snarks/section--11) and links to a video and paper discussing Torus optimization. - 2024-10-14T09:00:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2024/combined_Proposal-for-Quantum-Resistant-Cryptography-in-Bitcoin-BIP-Submission.xml b/static/bitcoin-dev/Oct_2024/combined_Proposal-for-Quantum-Resistant-Cryptography-in-Bitcoin-BIP-Submission.xml index ee8998e24c..ead183b496 100644 --- a/static/bitcoin-dev/Oct_2024/combined_Proposal-for-Quantum-Resistant-Cryptography-in-Bitcoin-BIP-Submission.xml +++ b/static/bitcoin-dev/Oct_2024/combined_Proposal-for-Quantum-Resistant-Cryptography-in-Bitcoin-BIP-Submission.xml @@ -1,33 +1,36 @@ - + 2 Combined summary - Proposal for Quantum-Resistant Cryptography in Bitcoin - BIP Submission - 2024-12-14T02:30:30.367281+00:00 - - Ian Quantum 2024-12-13 02:07:00+00:00 - - - Jon Atack 2024-10-21 15:35:00+00:00 - - - Agustin Cruz 2024-10-17 22:54:00+00:00 - + 2025-09-26T14:27:59.302401+00:00 + python-feedgen + + + Proposal for Quantum-Resistant Cryptography in Bitcoin - BIP Submission Agustin Cruz + 2024-10-17T22:54:00.000Z + + + Jon Atack + 2024-10-21T15:35:00.000Z + + + Ian Quantum + 2024-12-13T02:07:00.000Z + + - python-feedgen + 2 Combined summary - Proposal for Quantum-Resistant Cryptography in Bitcoin - BIP Submission - 2024-12-14T02:30:30.367323+00:00 + 2025-09-26T14:27:59.302939+00:00 + 2024-12-13T02:07:00+00:00 The discourse on enhancing Bitcoin's security framework to counter the threats posed by advancements in quantum computing has been vibrant across various platforms, with significant contributions being made towards developing a Bitcoin Improvement Proposal (BIP) specifically designed to introduce quantum-resistant cryptographic measures into the Bitcoin protocol. This initiative is driven by the recognition of the potential vulnerabilities that quantum computing could exploit within the existing cryptographic foundations of Bitcoin. Central to this proposal is the adoption of post-quantum cryptographic algorithms, notably SPHINCS+ and Dilithium. These algorithms are identified for their capability to fortify Bitcoin against the anticipated quantum computing capabilities, thereby ensuring the digital currency's resilience in the face of such technological progress. - To facilitate the integration of these quantum-resistant algorithms, the BIP draft outlines a series of critical modifications to the Bitcoin protocol. Among these are the introduction of a new Bech32-based address format tailored for quantum-resistant addresses, alongside adjustments to the transaction structures and script opcodes. These modifications are necessitated by the larger signature sizes associated with quantum-resistant cryptographic algorithms. Moreover, the draft proposes a transition mechanism through a soft fork, aiming to preserve backward compatibility with the existing ecosystem of Bitcoin addresses and transactions. This approach underscores a commitment to minimizing disruption while bolstering the security of the network against quantum computing threats. - The open invitation for community review and feedback on the draft hosted at [this GitHub link](https://github.com/chucrut/bips/blob/master/bip-xxxx.md) reflects a collaborative ethos in the development process of this BIP. Agustín Cruz, the proponent of the BIP, emphasizes the value of community input in refining the proposal, signaling an inclusive strategy to enhance Bitcoin's security mechanisms. The provision for community engagement is seen as a critical step in ensuring that the proposed measures are robust, feasible, and reflective of the collective wisdom of the Bitcoin development community. - Parallel discussions highlight concerns regarding current encryption standards like FALCON and the suitability of alternative cryptographic solutions such as NTRU Prime for secure lattice operations in heterogeneous environments. These conversations underscore the ongoing evaluation of cryptographic resilience against potential quantum computing exploits. Moreover, developments in quantum networking and mass production of quantum computing resources, exemplified by initiatives from entities like PSI Quantum, Oxford Ionics, Riverlane, and Intel, further contextualize the urgency and complexity of preparing Bitcoin for a post-quantum computing era. The expected advancements in quantum computing capabilities necessitate a proactive and informed approach to securing the Bitcoin network, as evidenced by the comprehensive efforts to develop and refine the proposed BIP for quantum resistance. - 2024-12-13T02:07:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2024/combined_Redefine-packages-to-discourage-address-reuse.xml b/static/bitcoin-dev/Oct_2024/combined_Redefine-packages-to-discourage-address-reuse.xml index 4168fa9baa..9b0aeee87d 100644 --- a/static/bitcoin-dev/Oct_2024/combined_Redefine-packages-to-discourage-address-reuse.xml +++ b/static/bitcoin-dev/Oct_2024/combined_Redefine-packages-to-discourage-address-reuse.xml @@ -1,47 +1,52 @@ - + 2 Combined summary - Redefine packages to discourage address reuse - 2024-10-30T02:23:17.833915+00:00 - - Peter Todd 2024-10-29 16:43:00+00:00 - - - /dev /fd 2024-10-24 03:43:00+00:00 - - - /dev /fd 2024-10-24 03:38:00+00:00 - - - Peter Todd 2024-10-23 14:35:00+00:00 - - - Abubakar Ismail 2024-10-20 07:33:00+00:00 - - - /dev /fd 2024-10-20 06:19:00+00:00 - + 2025-09-26T14:28:03.636601+00:00 + python-feedgen + + + Redefine packages to discourage address reuse /dev /fd0 + 2024-10-20T06:19:00.000Z + + + Abubakar Ismail + 2024-10-20T07:33:00.000Z + + + Peter Todd + 2024-10-23T14:35:00.000Z + + + /dev /fd0 + 2024-10-24T03:38:00.000Z + + + /dev /fd0 + 2024-10-24T03:43:00.000Z + + + Peter Todd + 2024-10-29T16:43:00.000Z + + - python-feedgen + 2 Combined summary - Redefine packages to discourage address reuse - 2024-10-30T02:23:17.834001+00:00 + 2025-09-26T14:28:03.637425+00:00 + 2024-10-29T16:43:00+00:00 The introduction of package transactions in Bitcoin represents a pivotal development, emphasizing the potential to refine these structures for improved transaction integrity and efficiency. The discussion highlights the significance of early optimization to mitigate security and privacy concerns associated with address reuse. By redefining package transactions, the ecosystem could see enhancements in how Bitcoin functionalities, including covenants and Layer 2 protocols, interact, potentially reducing the vulnerabilities associated with reused addresses. - -Address reuse within the Bitcoin network does not adversely affect miner revenue or the processing of transactions, as these practices align with the network's existing incentive structures. The correspondence also introduces the concept of silent payments, which utilize reusable payment codes to foster privacy and efficiency without necessitating changes to discourage address reuse at the protocol level. This strategy suggests a pathway to maintain user privacy and streamline transactions without undermining the blockchain's foundation. Additionally, the reference to a "/dev/fd0 floppy disk guy" adds a touch of human interest to the technical discourse, alluding to a nostalgic or light-hearted view of technological progression. - +Address reuse within the Bitcoin network does not adversely affect miner revenue or the processing of transactions, as these practices align with the network's existing incentive structures. The correspondence also introduces the concept of silent payments, which utilize reusable payment codes to foster privacy and efficiency without necessitating changes to discourage address reuse at the protocol level. This strategy suggests a pathway to maintain user privacy and streamline transactions without undermining the blockchain's foundation. Additionally, the reference to a "/dev/fd0 floppy disk guy" adds a touch of human interest to the technical discourse, alluding to a nostalgic or light-hearted view of technological progression. The proposal to enforce restrictions against address reuse has faced consistent opposition due to the potential complications it could introduce, particularly in interfering with Layer 2 protocols and the risk of adversaries exploiting such a system. This underscores the challenges and unintended consequences of implementing strict policies against address reuse within decentralized networks and digital currency protocols. Information on this topic and related discussions can be further explored through resources like [Peter Todd's website](https://petertodd.org). - Concerns regarding the operational feasibility of rejecting transactions that reuse addresses within packages have been raised, pointing out the unlikely enforcement by miners and the possible repercussions on transaction processing efficiency. Instead of imposing stringent limitations, the dialogue leans towards encouraging alternative measures, such as silent payments, to mitigate risks without compromising network functionality. - Redefining mempool policy to reject address-reusing transactions might not sufficiently address privacy risks, suggesting that modifying package transaction definitions could offer a more effective solution. The proposed redefinition could prevent transactions involving address reuse from being relayed, enhancing privacy without altering Bitcoin's core transactional dynamics. However, this approach faces challenges, including increased scanning times for address reuse and potential resistance to amending current standards, highlighting the ongoing need for innovative solutions within the Bitcoin developer community. - 2024-10-29T16:43:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml b/static/bitcoin-dev/Oct_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml index 4652854445..3ba62f83bc 100644 --- a/static/bitcoin-dev/Oct_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml +++ b/static/bitcoin-dev/Oct_2024/combined_Signing-a-Bitcoin-Transaction-with-Lamport-Signatures-no-changes-needed-.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) - 2024-11-18T02:30:36.698421+00:00 - - Ethan Heilman 2024-11-17 21:59:00+00:00 - - - Ethan Heilman 2024-11-16 14:55:00+00:00 - - - Xiaohui Liu 2024-11-15 21:54:00+00:00 - - - Garlo Nicon 2024-10-25 09:58:00+00:00 - - - Vicky 2024-10-25 00:20:00+00:00 - - - Antoine Riard 2024-05-11 02:53:00+00:00 - - - Andrew Poelstra 2024-05-09 12:46:00+00:00 - - - Ben Carman 2024-05-09 00:31:00+00:00 - - - Ethan Heilman 2024-05-07 16:05:00+00:00 - - - Andrew Poelstra 2024-05-07 14:34:00+00:00 - - - David A. Harding 2024-05-07 04:11:00+00:00 - - - Antoine Riard 2024-05-07 00:55:00+00:00 - - - Andrew Poelstra 2024-05-06 19:06:00+00:00 - - - David A. Harding 2024-05-06 18:56:00+00:00 - - - Andrew Poelstra 2024-05-06 16:48:00+00:00 - - - David A. Harding 2024-05-06 07:39:00+00:00 - - - Ethan Heilman 2024-05-01 20:02:00+00:00 - - - Antoine Riard 2024-05-01 03:46:00+00:00 - - - Ethan Heilman 2024-04-30 20:43:00+00:00 - - - Andrew Poelstra 2024-04-30 14:21:00+00:00 - - - Ethan Heilman 2024-04-30 13:25:00+00:00 - - - Matthew Zipkin 2024-04-30 12:32:00+00:00 - - - Ethan Heilman 2024-04-29 00:30:00+00:00 - + 2025-09-26T14:28:01.485259+00:00 + python-feedgen + + + Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) Ethan Heilman + 2024-04-29T00:30:00.000Z + + + Matthew Zipkin + 2024-04-30T12:32:00.000Z + + + Ethan Heilman + 2024-04-30T13:25:00.000Z + + + Andrew Poelstra + 2024-04-30T14:21:00.000Z + + + Ethan Heilman + 2024-04-30T20:43:00.000Z + + + Antoine Riard + 2024-05-01T03:46:00.000Z + + + Ethan Heilman + 2024-05-01T20:02:00.000Z + + + David A. Harding + 2024-05-06T07:39:00.000Z + + + Andrew Poelstra + 2024-05-06T16:48:00.000Z + + + David A. Harding + 2024-05-06T18:56:00.000Z + + + Andrew Poelstra + 2024-05-06T19:06:00.000Z + + + Antoine Riard + 2024-05-07T00:55:00.000Z + + + David A. Harding + 2024-05-07T04:11:00.000Z + + + Andrew Poelstra + 2024-05-07T14:34:00.000Z + + + Ethan Heilman + 2024-05-07T16:05:00.000Z + + + Ben Carman + 2024-05-09T00:31:00.000Z + + + Andrew Poelstra + 2024-05-09T12:46:00.000Z + + + Antoine Riard + 2024-05-11T02:53:00.000Z + + + Vicky + 2024-10-25T00:20:00.000Z + + + Garlo Nicon + 2024-10-25T09:58:00.000Z + + + Xiaohui Liu + 2024-11-15T21:54:00.000Z + + + Ethan Heilman + 2024-11-16T14:55:00.000Z + + + Ethan Heilman + 2024-11-17T21:59:00.000Z + + @@ -95,35 +121,24 @@ - python-feedgen + 2 Combined summary - Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) - 2024-11-18T02:30:36.698570+00:00 + 2025-09-26T14:28:01.488237+00:00 + 2024-11-17T21:59:00+00:00 The conversation explores innovative approaches to blockchain technology, particularly focusing on the implementation of covenants and introspection within Bitcoin's blockchain without necessitating OP_CAT. The dialogue delves into the limitations and potentials of utilizing opcodes like OP_SIZE for creating sophisticated contracts or covenants. It outlines a theoretical framework where an unlimited opcode set could enable small scripts capable of enforcing rules or conditions by introspecting the entire blockchain, potentially incorporating snarks to maintain script size while enhancing privacy and security through cryptographic methods. - The discussion also touches upon the complexities of implementing covenants in Bitcoin's scripting language, highlighting the technical challenges involved in parsing transaction fields without OP_CAT. This inquiry underscores the foundational aspects of Bitcoin's programmability and security features, emphasizing the need for developers to understand these mechanisms thoroughly. - Further, the conversation shifts to examining the security implications of using multiple private keys for generating specific addresses, illustrating the computational difficulty associated with this process through examples of one-byte and two-byte grinds. This illustration serves to highlight the nuanced strategy in multisignature setups within the Bitcoin protocol, showcasing how developers can leverage cryptographic signatures to balance accessibility and security according to the needs of a transaction or wallet. - In another part of the conversation, the focus shifts to the examination of ECDSA signature size distribution within Bitcoin's cryptographic framework, discussing the practicality of enhancing transaction security through signature batching. Additionally, Adam's proposal on Proof-of-Work locked outputs is explored as a more feasible approach than employing full Lamport signature schemes, further probing the security model and practical applications of these cryptographic enhancements in light of Bitcoin's operability constraints. - -Antoine's email to Ethan provides an in-depth analysis of cryptographic techniques related to transaction security and flexibility within blockchain technologies. It discusses vulnerabilities and innovations in Lamport and ECDSA/Schnorr signatures, emphasizing the potential risks and solutions to secure transactions against quantum computing threats. The concept of a "faux-ctv" variant leveraging BIP118 for no-input signatures is introduced, offering insights into the evolving landscape of blockchain security and transaction integrity. - +Antoine's email to Ethan provides an in-depth analysis of cryptographic techniques related to transaction security and flexibility within blockchain technologies. It discusses vulnerabilities and innovations in Lamport and ECDSA/Schnorr signatures, emphasizing the potential risks and solutions to secure transactions against quantum computing threats. The concept of a "faux-ctv" variant leveraging BIP118 for no-input signatures is introduced, offering insights into the evolving landscape of blockchain security and transaction integrity. Andrew Poelstra's insight into transaction signing processes within blockchain highlights the importance of sighash flags in ensuring transaction integrity, providing a deeper understanding of blockchain technology's technical nuances. His affiliation with Blockstream Research and contributions to the field are acknowledged, inviting further exploration of his work for those interested in blockchain advancements. - The dialogue between Ethan Heilman and David A. Harding sheds light on novel techniques to implement covenants in Bitcoin's scripting language, tapscript, despite opcode limitations. This conversation underlines ongoing explorations into expanding Bitcoin's scripting capabilities, reflecting broader interests in enhancing smart contract provisions on the platform. - A nuanced discussion among blockchain enthusiasts addresses several key points regarding fee bumping, signature validation, and quantum computing vulnerabilities in Bitcoin transactions. This exchange encapsulates a deep understanding of managing transaction fees, ensuring signature security, and preparing for technological threats to the cryptocurrency protocol. - Andrew Poelstra's method to bridge gaps between pre-Taproot and post-Taproot transaction outputs using anti-equivocation schemes exemplifies innovative solutions to enhance Bitcoin's security measures without relying on newer Schnorr signatures. This proposal underscores creative approaches to developing blockchain technology within the constraints of Bitcoin's scripting language. - The discussion between Antoine Riard and Andrew Poelstra, involving Matthew Zipkin and Ethan Heilman, revolves around the intricacies of integrating ECDSA and Schnorr signatures within Tapscript. This technical exploration reveals the complexity and potential confusion surrounding cryptographic and scripting innovations, reflecting efforts to evolve Bitcoin's scripting abilities for increased transaction verification and execution flexibility. - The conversation highlights a potential vulnerability in using Lamport public keys for blockchain transactions, pointing out the susceptibility to DoS attacks and issues related to signature algorithms like ECDSA. Concerns about the robustness of such schemes against attackers with considerable computational resources are raised, alongside discussions on improving the overall resilience of the system through technical adjustments. - This comprehensive summary encapsulates the multifaceted discussions on cryptographic techniques, security concerns, and innovative approaches to enhancing Bitcoin's functionality and security. The conversations reflect the collaborative effort and ongoing research within the blockchain community to address technical challenges and expand the capabilities of cryptocurrency platforms. - 2024-11-17T21:59:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml b/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml index 56dca14636..8cb1e7f9cf 100644 --- a/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml +++ b/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2023-08-02T07:20:37.832503+00:00 + 2025-09-26T14:20:21.674234+00:00 + python-feedgen Craig Raw 2022-09-26 08:23:18+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2023-08-02T07:20:37.833503+00:00 + 2025-09-26T14:20:21.674427+00:00 - The proposed standard aims to create a defined format for transferring labels that users have applied to transactions, addresses, inputs, or outputs in their wallets. The format uses the comma-separated values (CSV) format, which is widely supported. Each record in the CSV file consists of two fields: the reference to a transaction, address, input, or output, and the label applied to that reference. The proposal suggests using ZIP compression for the CSV file, with optional AES encryption.Some feedback on the proposal includes suggestions for improvements, such as adding a version byte to the header line, making the header line mandatory, and using an unsigned 32-bit integer for the second column. There are also suggestions to remove the optional encryption feature and not include input and output types in the export to avoid privacy leaks. Instead, commentators suggest adding a third column for item type identification.Despite disagreement on the use of CSV as a standard format, the goal of the proposal is to create a standardized format for importing and exporting wallet labels. The proposed format is a simple two-column CSV file, aiming to make label management more accessible to users and ensure compatibility between different wallet implementations. Feedback on the proposal is appreciated, and further improvements may be made based on the feedback received.The use of CSV for transferring labels between wallet applications is motivated by its wide accessibility and integration with existing processes and tools like Excel. However, there is some disagreement about using CSV, with suggestions to use JSON instead due to concerns about CSV compatibility and parsing effort. Despite this disagreement, the proposal aims to create a standard for importing and exporting labels from a wallet, regardless of the chosen data format.The proposal specifies a two-column CSV format, where the first column contains the reference to a transaction, address, input, or output, and the second column contains the label. The CSV file can be compressed using ZIP and optionally encrypted using AES. Importing applications may truncate labels if necessary, while exporting applications may omit records with no labels or labels of zero length.The proposal seeks to make label management accessible to users without technical expertise and reduce file size while ensuring compatibility. The discussion on the Bitcoin-dev mailing list provides insight into ongoing development work on the Bitcoin protocol and the collaborative nature of the Bitcoin development community.There is some disagreement about using CSV as the standard format for transferring labels, with suggestions to use JSON instead. One commenter suggests including descriptors in the format for advanced users. In response to a question about SLIP-0015, it is stated that SLIP-0015 has different design goals and limitations compared to the proposed BIP.The proposal allows for ZIP compression and optional AES encryption of the CSV file. The password for encryption should be the textual representation of the wallet's extended public key. The aim of this proposal is to create a standard for exporting and importing labels from a wallet, avoiding lock-in to a specific application, and making label management accessible to non-technical users.Feedback on the proposal is requested, and a reference implementation is yet to be determined. Suggestions for additions and changes to the format include adding a version byte, making the header line mandatory, requiring double quotes around the label, and writing a more robust importer algorithm. The proposal aims to standardize the export and import of labels using a simple CSV format. 2022-09-26T08:23:18+00:00 + The proposed standard aims to create a defined format for transferring labels that users have applied to transactions, addresses, inputs, or outputs in their wallets. The format uses the comma-separated values (CSV) format, which is widely supported. Each record in the CSV file consists of two fields: the reference to a transaction, address, input, or output, and the label applied to that reference. The proposal suggests using ZIP compression for the CSV file, with optional AES encryption.Some feedback on the proposal includes suggestions for improvements, such as adding a version byte to the header line, making the header line mandatory, and using an unsigned 32-bit integer for the second column. There are also suggestions to remove the optional encryption feature and not include input and output types in the export to avoid privacy leaks. Instead, commentators suggest adding a third column for item type identification.Despite disagreement on the use of CSV as a standard format, the goal of the proposal is to create a standardized format for importing and exporting wallet labels. The proposed format is a simple two-column CSV file, aiming to make label management more accessible to users and ensure compatibility between different wallet implementations. Feedback on the proposal is appreciated, and further improvements may be made based on the feedback received.The use of CSV for transferring labels between wallet applications is motivated by its wide accessibility and integration with existing processes and tools like Excel. However, there is some disagreement about using CSV, with suggestions to use JSON instead due to concerns about CSV compatibility and parsing effort. Despite this disagreement, the proposal aims to create a standard for importing and exporting labels from a wallet, regardless of the chosen data format.The proposal specifies a two-column CSV format, where the first column contains the reference to a transaction, address, input, or output, and the second column contains the label. The CSV file can be compressed using ZIP and optionally encrypted using AES. Importing applications may truncate labels if necessary, while exporting applications may omit records with no labels or labels of zero length.The proposal seeks to make label management accessible to users without technical expertise and reduce file size while ensuring compatibility. The discussion on the Bitcoin-dev mailing list provides insight into ongoing development work on the Bitcoin protocol and the collaborative nature of the Bitcoin development community.There is some disagreement about using CSV as the standard format for transferring labels, with suggestions to use JSON instead. One commenter suggests including descriptors in the format for advanced users. In response to a question about SLIP-0015, it is stated that SLIP-0015 has different design goals and limitations compared to the proposed BIP.The proposal allows for ZIP compression and optional AES encryption of the CSV file. The password for encryption should be the textual representation of the wallet's extended public key. The aim of this proposal is to create a standard for exporting and importing labels from a wallet, avoiding lock-in to a specific application, and making label management accessible to non-technical users.Feedback on the proposal is requested, and a reference implementation is yet to be determined. Suggestions for additions and changes to the format include adding a version byte, making the header line mandatory, requiring double quotes around the label, and writing a more robust importer algorithm. The proposal aims to standardize the export and import of labels using a simple CSV format. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_Full-Disclosure-Denial-of-Service-in-STONEWALLx2-p2p-coinjoin-.xml b/static/bitcoin-dev/Sept_2022/combined_Full-Disclosure-Denial-of-Service-in-STONEWALLx2-p2p-coinjoin-.xml index b817285d7f..6e21fd52f3 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Full-Disclosure-Denial-of-Service-in-STONEWALLx2-p2p-coinjoin-.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Full-Disclosure-Denial-of-Service-in-STONEWALLx2-p2p-coinjoin-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Full Disclosure: Denial of Service in STONEWALLx2 (p2p coinjoin) - 2023-08-02T07:01:14.301183+00:00 - - alicexbt 2022-09-10 10:20:48+00:00 - - - alicexbt 2022-07-14 09:25:56+00:00 - + 2025-09-26T14:20:04.613601+00:00 + python-feedgen + + + [bitcoin-dev] Full Disclosure: Denial of Service in STONEWALLx2 (p2p coinjoin) alicexbt + 2022-07-14T09:25:00.000Z + + + alicexbt + 2022-09-10T10:20:00.000Z + + - python-feedgen + 2 Combined summary - Full Disclosure: Denial of Service in STONEWALLx2 (p2p coinjoin) - 2023-08-02T07:01:14.301183+00:00 + 2025-09-26T14:20:04.613998+00:00 - A vulnerability has been identified in the Samourai wallet's p2p coinjoin transaction STONEWALLx2, which has been assigned CVE-2022-35913. The issue was reported on July 14th, 2022, to the bitcoin-dev mailing list. The vulnerability involves a denial-of-service (DoS) attack where one participant spends the UTXO used in STONEWALLx2 before the transaction is completed, resulting in an error message for the other participant.Antoine Riard discovered and shared the details of this DoS attack in an email on June 21, 2022. To demonstrate the attack, he created a testnet wallet and used two Android devices to simulate Bob and Carol, who were following each other's paynyms. Carol initiated several paynyms, and when Bob initiated a STONEWALLx2 transaction that required collaboration with Carol, she spent the UTXO from her wallet before Bob could complete the final step. This action caused an error message to appear on Bob's app when trying to broadcast the transaction.In response to this vulnerability, the Samourai Wallet team proposed two suggestions to mitigate the issue. First, they recommended displaying an error message that informs the user that the collaborator has spent their UTXO used in STONEWALLx2, ending the p2p coinjoin process. The message would also suggest unfollowing the collaborator's paynym and recommend doing such transactions only with trusted users for the time being. Secondly, they suggested that once full Replace-by-Fee (RBF) is used by some nodes and miners, the attacker's transaction could be replaced with a higher fee rate. However, implementing this solution won't be straightforward as fees for STONEWALLx2 are shared equally between the participants.The timeline of events shows that Samourai acknowledged the issue on July 7, 2022, and shared their conclusions on July 14, 2022. Antoine Riard played a significant role in the discovery of the DoS vector in p2p coinjoin transactions and assisted during the testing phase by responding to emails. 2022-09-10T10:20:48+00:00 + A vulnerability has been identified in the Samourai wallet's p2p coinjoin transaction STONEWALLx2, which has been assigned CVE-2022-35913. The issue was reported on July 14th, 2022, to the bitcoin-dev mailing list. The vulnerability involves a denial-of-service (DoS) attack where one participant spends the UTXO used in STONEWALLx2 before the transaction is completed, resulting in an error message for the other participant.Antoine Riard discovered and shared the details of this DoS attack in an email on June 21, 2022. To demonstrate the attack, he created a testnet wallet and used two Android devices to simulate Bob and Carol, who were following each other's paynyms. Carol initiated several paynyms, and when Bob initiated a STONEWALLx2 transaction that required collaboration with Carol, she spent the UTXO from her wallet before Bob could complete the final step. This action caused an error message to appear on Bob's app when trying to broadcast the transaction.In response to this vulnerability, the Samourai Wallet team proposed two suggestions to mitigate the issue. First, they recommended displaying an error message that informs the user that the collaborator has spent their UTXO used in STONEWALLx2, ending the p2p coinjoin process. The message would also suggest unfollowing the collaborator's paynym and recommend doing such transactions only with trusted users for the time being. Secondly, they suggested that once full Replace-by-Fee (RBF) is used by some nodes and miners, the attacker's transaction could be replaced with a higher fee rate. However, implementing this solution won't be straightforward as fees for STONEWALLx2 are shared equally between the participants.The timeline of events shows that Samourai acknowledged the issue on July 7, 2022, and shared their conclusions on July 14, 2022. Antoine Riard played a significant role in the discovery of the DoS vector in p2p coinjoin transactions and assisted during the testing phase by responding to emails. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_More-uses-for-CTV.xml b/static/bitcoin-dev/Sept_2022/combined_More-uses-for-CTV.xml index 58313bef06..5abc056174 100644 --- a/static/bitcoin-dev/Sept_2022/combined_More-uses-for-CTV.xml +++ b/static/bitcoin-dev/Sept_2022/combined_More-uses-for-CTV.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - More uses for CTV - 2023-08-02T07:17:28.431852+00:00 - - Antoine Riard 2022-09-19 01:22:43+00:00 - - - ZmnSCPxj 2022-08-20 03:03:52+00:00 - - - Jeremy Rubin 2022-08-19 21:01:25+00:00 - - - David A. Harding 2022-08-19 18:53:39+00:00 - - - Greg Sanders 2022-08-19 17:20:41+00:00 - - - James O'Beirne 2022-08-19 16:33:37+00:00 - + 2025-09-26T14:20:08.883148+00:00 + python-feedgen + + + [bitcoin-dev] More uses for CTV James O'Beirne + 2022-08-19T16:33:00.000Z + + + Greg Sanders + 2022-08-19T17:20:00.000Z + + + David A. Harding + 2022-08-19T18:53:00.000Z + + + Jeremy Rubin + 2022-08-19T21:01:00.000Z + + + ZmnSCPxj + 2022-08-20T03:03:00.000Z + + + Antoine Riard + 2022-09-19T01:22:00.000Z + + - python-feedgen + 2 Combined summary - More uses for CTV - 2023-08-02T07:17:28.431852+00:00 + 2025-09-26T14:20:08.883841+00:00 - The email thread and conversation on the bitcoin-dev mailing list revolve around the potential uses of OP_CHECKTEMPLATEVERIFY (CTV) in Bitcoin transactions. One use case discussed is congestion control, where CTV can be used to compress settlement commitments and facilitate later unpacking of the CTV outputs into the contract's true end state. This can help smooth fee rates and create a less spiky incentive to mine. Another potential application is atomic mining pool payouts, where a single OP_CTV output could pay out an arbitrary number of participants within a single coinbase. However, there are concerns raised about the design of atomic mining pool payouts, including weird dependencies between scriptpubkey, merkle root commitment, and CTV hash.The conversation also delves into L2 contracts and time-out based protocols, exploring the possibility of using layered commitments with OP_CTV to enable speedy settlement styles for these contracts. It is mentioned that predetermined sets of UTXOs in offchain cases can be implemented with a single UTXO that is an n-of-n multisignature or P2WSH revealing an OP_CTV.The advantages of Commitment Transaction Verification (CTV) compared to presigned transactions for trustless collaboration between multiple parties are discussed. While CTV is considered the most parsimonious way to settle into a single output, presigned transactions have their own benefits such as better privacy enhancement. In-script commitments using a non-secret point can reduce the amount of stored state and be deterministic. For large protocol trees, the savings can be substantial. The limitations of coinbase outputs and their impact on the number of participants in mining pools are also highlighted. Paying into batches of channels can compress payouts without a custodial relationship.A proposal is made to use SIGHASH_ALL | ANYONECANPAY to trustlessly collaborate and settle into a single CTV output, similar to coinjoins. The advantages of this method are discussed, but concerns are raised about compatibility with presigned transactions and the need for privacy upgrades to Lightning Network. The idea of using a single OP_CTV output for direct-from-coinbase payouts is also mentioned, but the size limitation on coinbase outputs restricts the number of participants in mining pools.James O'Beirne discusses the potential uses of CTV in Layer 2 protocols like payment channels and vaults. CTV can help compress settlement commitments and avoid protocol failures due to lack of block space. Direct-from-coinbase payouts are desirable for mining pools, but the size limitation on coinbase outputs limits the number of participants. CTV is seen as a simple concept and implementation that is likely to yield potential applications, especially with the possible increase in L2 usage.Overall, the discussions provide insights into the technicalities of implementing efficient L2 contracts, time-out based protocols, and congestion control using CTV. Various use cases and limitations are explored, with suggestions for alternative designs and improvements. The potential benefits of settlement compression and trustless collaboration are highlighted, while considering the implications for privacy and scalability. 2022-09-19T01:22:43+00:00 + The email thread and conversation on the bitcoin-dev mailing list revolve around the potential uses of OP_CHECKTEMPLATEVERIFY (CTV) in Bitcoin transactions. One use case discussed is congestion control, where CTV can be used to compress settlement commitments and facilitate later unpacking of the CTV outputs into the contract's true end state. This can help smooth fee rates and create a less spiky incentive to mine. Another potential application is atomic mining pool payouts, where a single OP_CTV output could pay out an arbitrary number of participants within a single coinbase. However, there are concerns raised about the design of atomic mining pool payouts, including weird dependencies between scriptpubkey, merkle root commitment, and CTV hash.The conversation also delves into L2 contracts and time-out based protocols, exploring the possibility of using layered commitments with OP_CTV to enable speedy settlement styles for these contracts. It is mentioned that predetermined sets of UTXOs in offchain cases can be implemented with a single UTXO that is an n-of-n multisignature or P2WSH revealing an OP_CTV.The advantages of Commitment Transaction Verification (CTV) compared to presigned transactions for trustless collaboration between multiple parties are discussed. While CTV is considered the most parsimonious way to settle into a single output, presigned transactions have their own benefits such as better privacy enhancement. In-script commitments using a non-secret point can reduce the amount of stored state and be deterministic. For large protocol trees, the savings can be substantial. The limitations of coinbase outputs and their impact on the number of participants in mining pools are also highlighted. Paying into batches of channels can compress payouts without a custodial relationship.A proposal is made to use SIGHASH_ALL | ANYONECANPAY to trustlessly collaborate and settle into a single CTV output, similar to coinjoins. The advantages of this method are discussed, but concerns are raised about compatibility with presigned transactions and the need for privacy upgrades to Lightning Network. The idea of using a single OP_CTV output for direct-from-coinbase payouts is also mentioned, but the size limitation on coinbase outputs restricts the number of participants in mining pools.James O'Beirne discusses the potential uses of CTV in Layer 2 protocols like payment channels and vaults. CTV can help compress settlement commitments and avoid protocol failures due to lack of block space. Direct-from-coinbase payouts are desirable for mining pools, but the size limitation on coinbase outputs limits the number of participants. CTV is seen as a simple concept and implementation that is likely to yield potential applications, especially with the possible increase in L2 usage.Overall, the discussions provide insights into the technicalities of implementing efficient L2 contracts, time-out based protocols, and congestion control using CTV. Various use cases and limitations are explored, with suggestions for alternative designs and improvements. The potential benefits of settlement compression and trustless collaboration are highlighted, while considering the implications for privacy and scalability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_Multipayment-Channels-A-scalability-solution-for-Layer-1.xml b/static/bitcoin-dev/Sept_2022/combined_Multipayment-Channels-A-scalability-solution-for-Layer-1.xml index 547bfbab32..84f2a28a62 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Multipayment-Channels-A-scalability-solution-for-Layer-1.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Multipayment-Channels-A-scalability-solution-for-Layer-1.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Multipayment Channels - A scalability solution for Layer 1 - 2023-08-02T07:22:17.964261+00:00 - - ZmnSCPxj 2022-09-05 03:17:27+00:00 - - - Ali Sherief 2022-09-04 22:31:38+00:00 - + 2025-09-26T14:20:15.263197+00:00 + python-feedgen + + + [bitcoin-dev] Multipayment Channels - A scalability solution for Layer 1 Ali Sherief + 2022-09-04T22:31:00.000Z + + + ZmnSCPxj + 2022-09-05T03:17:00.000Z + + - python-feedgen + 2 Combined summary - Multipayment Channels - A scalability solution for Layer 1 - 2023-08-02T07:22:17.964261+00:00 + 2025-09-26T14:20:15.263635+00:00 - ZmnSCPxj has developed a novel method for batching transactions on layer 1 without the need for hardforks. The idea originated from a discussion with Greg Maxwell regarding the implementation of multisig using Taproot. The scheme utilizes MuSig1, OP_CHECKLOCKTIMEVERIFY (OP_CLTV) timelock type, and minimal OP_RETURN data to create "multipayment channels" that enable multiple individuals to pay in a single transaction.These multipayment channels consist of a fixed number of participants, denoted as N. Each participant opens a channel by creating an optional Taproot address using the specified script. Simultaneously, each participant receives the N signatures and constructs the N-of-N MuSig. This MuSig is then used to generate the participant's own independent "commitment transaction" with the aforementioned properties.However, there are some drawbacks to this scheme. One concern is that the N-of-N signature may be leaked to the public, potentially compromising the security of the channel. Additionally, all participants must be trustworthy for the scheme to function effectively.The author's scheme also incorporates Spilman channels, which are similar to CoinPools, multiparticipant channels, and Statechains. These modifications serve as modernizations of the Spilman channels.Overall, ZmnSCPxj's innovative approach allows for the batching of transactions into blocks, increasing the transactions-per-second without necessitating hardforks. Through the use of MuSig1, OP_CLTV timelocks, and negligible OP_RETURN data, multipayment channels are created to facilitate multiple payments in a single transaction. However, it is crucial to address the potential risks associated with the leakage of N-of-N signatures and the requirement of trustworthiness among participants. 2022-09-05T03:17:27+00:00 + ZmnSCPxj has developed a novel method for batching transactions on layer 1 without the need for hardforks. The idea originated from a discussion with Greg Maxwell regarding the implementation of multisig using Taproot. The scheme utilizes MuSig1, OP_CHECKLOCKTIMEVERIFY (OP_CLTV) timelock type, and minimal OP_RETURN data to create "multipayment channels" that enable multiple individuals to pay in a single transaction.These multipayment channels consist of a fixed number of participants, denoted as N. Each participant opens a channel by creating an optional Taproot address using the specified script. Simultaneously, each participant receives the N signatures and constructs the N-of-N MuSig. This MuSig is then used to generate the participant's own independent "commitment transaction" with the aforementioned properties.However, there are some drawbacks to this scheme. One concern is that the N-of-N signature may be leaked to the public, potentially compromising the security of the channel. Additionally, all participants must be trustworthy for the scheme to function effectively.The author's scheme also incorporates Spilman channels, which are similar to CoinPools, multiparticipant channels, and Statechains. These modifications serve as modernizations of the Spilman channels.Overall, ZmnSCPxj's innovative approach allows for the batching of transactions into blocks, increasing the transactions-per-second without necessitating hardforks. Through the use of MuSig1, OP_CLTV timelocks, and negligible OP_RETURN data, multipayment channels are created to facilitate multiple payments in a single transaction. However, it is crucial to address the potential risks associated with the leakage of N-of-N signatures and the requirement of trustworthiness among participants. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml b/static/bitcoin-dev/Sept_2022/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml index 8484ab309f..a0e818d631 100644 --- a/static/bitcoin-dev/Sept_2022/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml +++ b/static/bitcoin-dev/Sept_2022/combined_New-transaction-policies-nVersion-3-for-contracting-protocols.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - New transaction policies (nVersion=3) for contracting protocols - 2023-08-02T07:37:32.592526+00:00 - - Greg Sanders 2023-06-21 20:57:45+00:00 - - - Ruben Somsen 2022-10-01 09:59:55+00:00 - - - Greg Sanders 2022-09-30 12:17:38+00:00 - - - Bastien TEINTURIER 2022-09-30 12:08:41+00:00 - - - Ruben Somsen 2022-09-30 00:13:53+00:00 - - - Greg Sanders 2022-09-29 14:41:28+00:00 - - - Bastien TEINTURIER 2022-09-29 09:15:02+00:00 - - - Gloria Zhao 2022-09-26 16:47:49+00:00 - - - Greg Sanders 2022-09-26 16:01:54+00:00 - - - Bastien TEINTURIER 2022-09-26 15:27:40+00:00 - - - Antoine Riard 2022-09-25 23:59:22+00:00 - - - Greg Sanders 2022-09-23 18:48:39+00:00 - - - Gloria Zhao 2022-09-23 15:18:21+00:00 - + 2025-09-26T14:20:00.382702+00:00 + python-feedgen + + + [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols Gloria Zhao + 2022-09-23T15:18:00.000Z + + + Greg Sanders + 2022-09-23T18:48:00.000Z + + + Antoine Riard + 2022-09-25T23:59:00.000Z + + + Bastien TEINTURIER + 2022-09-26T15:27:00.000Z + + + Greg Sanders + 2022-09-26T16:01:00.000Z + + + Gloria Zhao + 2022-09-26T16:47:00.000Z + + + Bastien TEINTURIER + 2022-09-29T09:15:00.000Z + + + Greg Sanders + 2022-09-29T14:41:00.000Z + + + Ruben Somsen + 2022-09-30T00:13:00.000Z + + + Bastien TEINTURIER + 2022-09-30T12:08:00.000Z + + + Greg Sanders + 2022-09-30T12:17:00.000Z + + + Ruben Somsen + 2022-10-01T09:59:00.000Z + + + Greg Sanders + 2023-06-21T20:57:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - New transaction policies (nVersion=3) for contracting protocols - 2023-08-02T07:37:32.592526+00:00 + 2025-09-26T14:20:00.384103+00:00 - Bitcoin developer Gloria Zhao has proposed a new transaction format called V3, which aims to improve replace-by-fee (RBF) and child-pays-for-parent (CPFP) protocols. The proposal includes rules that limit the size and number of descendant transactions, allowing for easier fee-bumping and reducing the need for managing a large UTXO pool. These rules provide flexibility for Layer 2 (L2) protocols while maintaining security and efficiency.Under the proposed rules, a V3 transaction can be replaced even without signaling BIP125 replaceability, as long as it meets other RBF rules. Any descendant of an unconfirmed V3 transaction must also be V3, and an unconfirmed V3 transaction cannot have more than one descendant. Additionally, a V3 transaction with an unconfirmed V3 ancestor cannot exceed 1000 virtual bytes in size.The proposal also discusses the intended usage for Lightning Network (LN) commitment transactions, which should be V3 and have one anchor output. If the commitment transaction needs to be broadcasted, the desired feerate at broadcast time should be determined, and the anchor output should be spent in a high feerate transaction. Multiple commitment transactions can be funded by one child, and to add more fees, the child should be replaced with a higher-feerate transaction.In addition to the V3 transaction format, the Bitcoin development team has proposed a new package relay policy to replace BIP125, the current Replace-by-Fee (RBF) policy. The new policy includes changes to the feerate requirements and ensures that replacement transactions are not less incentive-compatible to mine. It also addresses questions related to Rule 3 Pinning, counterparty's commitment transaction in the mempool, privacy concerns, backward compatibility, and replacing transactions between V2 and V3.The proposed policies aim to improve RBF and CPFP protocols, with specific rules for V3 transactions and modifications to package RBF rules. The changes aim to provide inherited replaceability signaling and prevent pinning attacks. Gloria Zhao has implemented these policies in Bitcoin Core and welcomes feedback from the community. The proposal offers potential benefits for L2/contract protocols and addresses some limitations of previous proposals. Feedback and review of the proposal are encouraged by the development team. 2023-06-21T20:57:45+00:00 + Bitcoin developer Gloria Zhao has proposed a new transaction format called V3, which aims to improve replace-by-fee (RBF) and child-pays-for-parent (CPFP) protocols. The proposal includes rules that limit the size and number of descendant transactions, allowing for easier fee-bumping and reducing the need for managing a large UTXO pool. These rules provide flexibility for Layer 2 (L2) protocols while maintaining security and efficiency.Under the proposed rules, a V3 transaction can be replaced even without signaling BIP125 replaceability, as long as it meets other RBF rules. Any descendant of an unconfirmed V3 transaction must also be V3, and an unconfirmed V3 transaction cannot have more than one descendant. Additionally, a V3 transaction with an unconfirmed V3 ancestor cannot exceed 1000 virtual bytes in size.The proposal also discusses the intended usage for Lightning Network (LN) commitment transactions, which should be V3 and have one anchor output. If the commitment transaction needs to be broadcasted, the desired feerate at broadcast time should be determined, and the anchor output should be spent in a high feerate transaction. Multiple commitment transactions can be funded by one child, and to add more fees, the child should be replaced with a higher-feerate transaction.In addition to the V3 transaction format, the Bitcoin development team has proposed a new package relay policy to replace BIP125, the current Replace-by-Fee (RBF) policy. The new policy includes changes to the feerate requirements and ensures that replacement transactions are not less incentive-compatible to mine. It also addresses questions related to Rule 3 Pinning, counterparty's commitment transaction in the mempool, privacy concerns, backward compatibility, and replacing transactions between V2 and V3.The proposed policies aim to improve RBF and CPFP protocols, with specific rules for V3 transactions and modifications to package RBF rules. The changes aim to provide inherited replaceability signaling and prevent pinning attacks. Gloria Zhao has implemented these policies in Bitcoin Core and welcomes feedback from the community. The proposal offers potential benefits for L2/contract protocols and addresses some limitations of previous proposals. Feedback and review of the proposal are encouraged by the development team. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 8a089cfe54..52942a9564 100644 --- a/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On a new community process to specify covenants - 2023-08-02T07:05:21.717413+00:00 + 2025-09-26T14:20:06.769538+00:00 + python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - On a new community process to specify covenants - 2023-08-02T07:05:21.718414+00:00 + 2025-09-26T14:20:06.769730+00:00 - The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest 2022-10-07T15:33:12+00:00 + The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml index 27a78a7436..c6e5aabe75 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Packaged Transaction Relay - 2023-08-02T06:45:04.464151+00:00 + 2025-09-26T14:20:23.821984+00:00 + python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Packaged Transaction Relay - 2023-08-02T06:45:04.465148+00:00 + 2025-09-26T14:20:23.822159+00:00 - The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. 2022-10-10T22:05:38+00:00 + The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_RFC-for-a-BIP32-recurrent-address-derivation-scheme.xml b/static/bitcoin-dev/Sept_2022/combined_RFC-for-a-BIP32-recurrent-address-derivation-scheme.xml index a65dfa9bc1..0e742454c7 100644 --- a/static/bitcoin-dev/Sept_2022/combined_RFC-for-a-BIP32-recurrent-address-derivation-scheme.xml +++ b/static/bitcoin-dev/Sept_2022/combined_RFC-for-a-BIP32-recurrent-address-derivation-scheme.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - RFC for a BIP32 recurrent address derivation scheme - 2023-08-02T07:35:46.646061+00:00 - - El_Hoy 2022-10-04 19:08:34+00:00 - - - Ruben Somsen 2022-09-29 22:41:29+00:00 - - - El_Hoy 2022-09-22 03:06:50+00:00 - + 2025-09-26T14:19:56.043015+00:00 + python-feedgen + + + [bitcoin-dev] RFC for a BIP32 recurrent address derivation scheme El_Hoy + 2022-09-22T03:06:00.000Z + + + Ruben Somsen + 2022-09-29T22:41:00.000Z + + + El_Hoy + 2022-10-04T19:08:00.000Z + + - python-feedgen + 2 Combined summary - RFC for a BIP32 recurrent address derivation scheme - 2023-08-02T07:35:46.646061+00:00 + 2025-09-26T14:19:56.043578+00:00 - In an email thread on the bitcoin-dev mailing list, Eloy proposed a scheme that would enable recurring payments using a single offline interaction. The proposed scheme follows the structure described in BIP44 and involves the use of a "contact" level to represent a contact address for the recipient. By using Carol's contact address, Bob can generate multiple derived addresses for recurring payments without revealing any information on-chain.Eloy pointed out that while there are mentions of such a scheme, there is currently no framework to facilitate its usage and ensure interoperability between different implementations. To address this, Eloy proposed a BIP (Bitcoin Improvement Proposal) that would make it easier for developers to implement and users to utilize this scheme.Ruben responded to the proposal, acknowledging that it is an improvement over the current status quo. However, he noted that schemes like BIP47 and Silent Payments do not require any interaction with the sender, unlike this proposed scheme which requires a one-time interaction. This makes it less suitable for one-time donations.Ruben also raised concerns about how the "contact" level should be defined deterministically. If Bob defines it for Carol, it would be difficult to recover payments deterministically without backing up how it is defined. Additionally, Ruben highlighted the importance of considering the gap limit, suggesting that a low default gap limit should be defined for these extended public keys (xpubs) to avoid exponential blowup.Overall, the proposed scheme offers a positive solution to the issue of having to use a new address for every transaction, which can be inconvenient for making recurring payments. It provides privacy and allows for easy labeling of received payments. Furthermore, it gives Bob the advantage of choosing to send payments using multiple outputs. However, adjustments may be necessary for different address types on Bitcoin. 2022-10-04T19:08:34+00:00 + In an email thread on the bitcoin-dev mailing list, Eloy proposed a scheme that would enable recurring payments using a single offline interaction. The proposed scheme follows the structure described in BIP44 and involves the use of a "contact" level to represent a contact address for the recipient. By using Carol's contact address, Bob can generate multiple derived addresses for recurring payments without revealing any information on-chain.Eloy pointed out that while there are mentions of such a scheme, there is currently no framework to facilitate its usage and ensure interoperability between different implementations. To address this, Eloy proposed a BIP (Bitcoin Improvement Proposal) that would make it easier for developers to implement and users to utilize this scheme.Ruben responded to the proposal, acknowledging that it is an improvement over the current status quo. However, he noted that schemes like BIP47 and Silent Payments do not require any interaction with the sender, unlike this proposed scheme which requires a one-time interaction. This makes it less suitable for one-time donations.Ruben also raised concerns about how the "contact" level should be defined deterministically. If Bob defines it for Carol, it would be difficult to recover payments deterministically without backing up how it is defined. Additionally, Ruben highlighted the importance of considering the gap limit, suggesting that a low default gap limit should be defined for these extended public keys (xpubs) to avoid exponential blowup.Overall, the proposed scheme offers a positive solution to the issue of having to use a new address for every transaction, which can be inconvenient for making recurring payments. It provides privacy and allows for easy labeling of received payments. Furthermore, it gives Bob the advantage of choosing to send payments using multiple outputs. However, adjustments may be necessary for different address types on Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_Spookchains-Drivechain-Analog-with-One-Time-Trusted-Setup-APO.xml b/static/bitcoin-dev/Sept_2022/combined_Spookchains-Drivechain-Analog-with-One-Time-Trusted-Setup-APO.xml index 65fb34d378..67c14a3ad2 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Spookchains-Drivechain-Analog-with-One-Time-Trusted-Setup-APO.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Spookchains-Drivechain-Analog-with-One-Time-Trusted-Setup-APO.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Spookchains: Drivechain Analog with One-Time Trusted Setup & APO - 2023-08-02T07:23:19.347457+00:00 - - Antoine Riard 2022-09-30 02:00:30+00:00 - - - ZmnSCPxj 2022-09-19 22:43:44+00:00 - - - Jeremy Rubin 2022-09-14 18:31:55+00:00 - + 2025-09-26T14:20:19.526273+00:00 + python-feedgen + + + [bitcoin-dev] Spookchains: Drivechain Analog with One-Time Trusted Setup & APO Jeremy Rubin + 2022-09-14T18:31:00.000Z + + + ZmnSCPxj + 2022-09-19T22:43:00.000Z + + + Antoine Riard + 2022-09-30T02:00:00.000Z + + - python-feedgen + 2 Combined summary - Spookchains: Drivechain Analog with One-Time Trusted Setup & APO - 2023-08-02T07:23:19.347457+00:00 + 2025-09-26T14:20:19.526794+00:00 - In a recent email exchange, Antoine Riard and Jeremy Rubin discussed the use of covenant-based drivechain designs and recursive-covenant "embedded" sidechains as a solution to double-spending issues. They explored the possible security bounds and impacts on funds, along with variants of pegging mechanisms that influence the soundness of game-theory backing up functionaries' execution.Riard shared an entry he started for the ZmnSCPxj design on Github. In his post, Rubin showed techniques that could accomplish something similar using ANYPREVOUT with a one-time trusted setup ceremony. Rubin presented general techniques that could be applied to many different types of covenants. He started by building a Peano counter graph, which was a simple 1 to 5 counter that had inc / dec. To handle arbitrary deposits/withdrawals, Rubin suggested dividing the deposit amount into a counter UTXO per bit. To enforce that only one vote per block mined is allowed, Rubin ensured that all signatures set the input sequence to 1 block. When a counter reaches the Nth state, it represents a certain amount of accumulated work over a period where progress was agreed on for some outcome. Rubin also discussed several setup variants, including xpubs, single-party pre-signing, MuSig Multi-Party, unaggregated multi-party, and soft forking away trust. The advantage of such an optimization is theoretically nice because it means that only the non-destructuring recursive part of the computation is subject to the one-time-setup trust assumption, which might be of use in various other protocols.The email thread discusses a covenant model that relies on one-time setup and minimizes costs until the graph is a Directed Acyclic Graph (DAG), consisting of one or more components. The model defines covenants as a set of sets of transaction intents, potentially recursive or co-recursive, and a verifier generator function that generates a function that accepts an intent that is any element of one member of the family of intents and a proof for it and rejects others. It also includes a prover generator function that generates a function that takes an intent that is any element of one member of the family and some extra data and returns either a new prover function, a finished proof, or a rejection if not a valid intent. The covenant is verified under certain assumptions, including multi-sig covenant with at least 1-n honesty, Sha256 collision resistance, Discrete Log Hardness, and a SGX module being correct. In addition, there is perfect impedance match between the Prover, Verifier, and a set of intents. Composability is also possible as the Terminal State can pay out into a pre-specified covenant from any other family of covenants.The article discusses the concept of Terminal States/Thresholds in blockchain technology. These states represent accumulated work over a period and should have viable state transitions. The author suggests having the money sent to an OP_TRUE output, which would prevent the miner from swerving the car to a different output. This approach is not exactly like Drivechains but similar. The "ultimate threat" in Drivechains is everyone upgrading sidechain rules to mainchain rules. Still, there are concerns about using this approach in Spookchains. Alternatively, the administrator key/federation with a block timeout could be used for convenience, similar to Blockstream's separation of block-signing functionaries from money-keeping functionaries.The article presents a technique for creating drivechains with recursive covenants using ANYPREVOUT and a trusted setup ceremony. The Peano counter graph is used in this process to build a simple 1 to 5 counter that has an inc/dec feature, using a key instead of sha-256. For each Ki, when i < N in Rule Increment, the first signature should cover specified inputs, while for each Ki, when i > 1 in Rule Decrement, the second signature should cover the same inputs. To handle arbitrary deposits or withdrawals, the protocol can be instantiated for every amount or divided using base 2 or another base. Splitting and joining can also be accomplished by pre-signing. All signatures set the input sequence to one block to enforce that only one vote per block is allowed. When a counter reaches the Nth state, there should be some viable state transition at this point, such as sending the money to an OP_TRUE output that the miner incrementing that state is responsible for following the rules of the spookchain. From any K^i_1 state, the transaction transitioning to K^i_2 can be treated as “special,” and the OP_RETURN output type can be used to commit to the outputs that must be created when the Terminal State is reached.The article clarifies the issue of "what is being voted on." Instead of using randomly generated keys for each state, xpubs can be defined and derived for each state/satoshi amount. A single party pre-sign 2022-09-30T02:00:30+00:00 + In a recent email exchange, Antoine Riard and Jeremy Rubin discussed the use of covenant-based drivechain designs and recursive-covenant "embedded" sidechains as a solution to double-spending issues. They explored the possible security bounds and impacts on funds, along with variants of pegging mechanisms that influence the soundness of game-theory backing up functionaries' execution.Riard shared an entry he started for the ZmnSCPxj design on Github. In his post, Rubin showed techniques that could accomplish something similar using ANYPREVOUT with a one-time trusted setup ceremony. Rubin presented general techniques that could be applied to many different types of covenants. He started by building a Peano counter graph, which was a simple 1 to 5 counter that had inc / dec. To handle arbitrary deposits/withdrawals, Rubin suggested dividing the deposit amount into a counter UTXO per bit. To enforce that only one vote per block mined is allowed, Rubin ensured that all signatures set the input sequence to 1 block. When a counter reaches the Nth state, it represents a certain amount of accumulated work over a period where progress was agreed on for some outcome. Rubin also discussed several setup variants, including xpubs, single-party pre-signing, MuSig Multi-Party, unaggregated multi-party, and soft forking away trust. The advantage of such an optimization is theoretically nice because it means that only the non-destructuring recursive part of the computation is subject to the one-time-setup trust assumption, which might be of use in various other protocols.The email thread discusses a covenant model that relies on one-time setup and minimizes costs until the graph is a Directed Acyclic Graph (DAG), consisting of one or more components. The model defines covenants as a set of sets of transaction intents, potentially recursive or co-recursive, and a verifier generator function that generates a function that accepts an intent that is any element of one member of the family of intents and a proof for it and rejects others. It also includes a prover generator function that generates a function that takes an intent that is any element of one member of the family and some extra data and returns either a new prover function, a finished proof, or a rejection if not a valid intent. The covenant is verified under certain assumptions, including multi-sig covenant with at least 1-n honesty, Sha256 collision resistance, Discrete Log Hardness, and a SGX module being correct. In addition, there is perfect impedance match between the Prover, Verifier, and a set of intents. Composability is also possible as the Terminal State can pay out into a pre-specified covenant from any other family of covenants.The article discusses the concept of Terminal States/Thresholds in blockchain technology. These states represent accumulated work over a period and should have viable state transitions. The author suggests having the money sent to an OP_TRUE output, which would prevent the miner from swerving the car to a different output. This approach is not exactly like Drivechains but similar. The "ultimate threat" in Drivechains is everyone upgrading sidechain rules to mainchain rules. Still, there are concerns about using this approach in Spookchains. Alternatively, the administrator key/federation with a block timeout could be used for convenience, similar to Blockstream's separation of block-signing functionaries from money-keeping functionaries.The article presents a technique for creating drivechains with recursive covenants using ANYPREVOUT and a trusted setup ceremony. The Peano counter graph is used in this process to build a simple 1 to 5 counter that has an inc/dec feature, using a key instead of sha-256. For each Ki, when i < N in Rule Increment, the first signature should cover specified inputs, while for each Ki, when i > 1 in Rule Decrement, the second signature should cover the same inputs. To handle arbitrary deposits or withdrawals, the protocol can be instantiated for every amount or divided using base 2 or another base. Splitting and joining can also be accomplished by pre-signing. All signatures set the input sequence to one block to enforce that only one vote per block is allowed. When a counter reaches the Nth state, there should be some viable state transition at this point, such as sending the money to an OP_TRUE output that the miner incrementing that state is responsible for following the rules of the spookchain. From any K^i_1 state, the transaction transitioning to K^i_2 can be treated as “special,” and the OP_RETURN output type can be used to commit to the outputs that must be created when the Terminal State is reached.The article clarifies the issue of "what is being voted on." Instead of using randomly generated keys for each state, xpubs can be defined and derived for each state/satoshi amount. A single party pre-sign - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_Third-version-of-Silent-Payment-implementation.xml b/static/bitcoin-dev/Sept_2022/combined_Third-version-of-Silent-Payment-implementation.xml index a8be3947c0..a21d9bb161 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Third-version-of-Silent-Payment-implementation.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Third-version-of-Silent-Payment-implementation.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Third version of Silent Payment implementation - 2023-08-02T07:43:10.225110+00:00 - - Ruben Somsen 2022-10-03 23:41:10+00:00 - - - Ruben Somsen 2022-09-29 23:03:36+00:00 - - - woltx 2022-09-29 22:19:38+00:00 - + 2025-09-26T14:20:02.498774+00:00 + python-feedgen + + + [bitcoin-dev] Third version of Silent Payment implementation woltx + 2022-09-29T22:19:00.000Z + + + Ruben Somsen + 2022-09-29T23:03:00.000Z + + + Ruben Somsen + 2022-10-03T23:41:00.000Z + + - python-feedgen + 2 Combined summary - Third version of Silent Payment implementation - 2023-08-02T07:43:10.225110+00:00 + 2025-09-26T14:20:02.499436+00:00 - In a recent clarification provided by Ruben Somsen, the function of the identifier in bitcoin addresses was discussed. The purpose of this identifier is to distinguish why someone has made a payment to you. However, it is important to note that third-party observers are unable to link these payments on-chain and cannot determine which identifier was used. In situations where you do not want your identity to be revealed, the identifier alone is insufficient, and a separate Silent Payment address is required.Ruben also introduced a scheme that allows for multiple silent addresses per wallet with minimal overhead. This scheme enables the resulting address to be marked in a recognizable way, allowing the recipient to differentiate between different payment purposes. To implement this scheme, a public identifier "f" is added to a key when tweaking. It is essential to communicate this identifier to the sender, possibly as part of the address format. The new address format includes a field called "identifier," which guides both the receiver and sender in setting the address correctly. If the receiver is unaware of which identifiers have been used, the wallet can scan all identifiers from 0 to 99. Currently, each wallet is limited to using only 100 different identifiers, but this limit can be increased in the future if needed. Furthermore, a new RPC (Remote Procedure Call) has been implemented to retrieve silent addresses. Users are now able to assign different labels to their addresses, allowing them to identify which silent address a specific UTXO (Unspent Transaction Output) came from. This feature enhances usability and organization within the wallet. It should be noted that the newly introduced silent payment (SP) addresses are not script-related, which means they can potentially include additional information, such as an expiration timestamp or block height in the future. To assist users in understanding and implementing this scheme, a step-by-step tutorial has been provided on Github. This comprehensive tutorial serves as a reference guide for users interested in utilizing the new scheme proposed by Ruben Somsen. 2022-10-03T23:41:10+00:00 + In a recent clarification provided by Ruben Somsen, the function of the identifier in bitcoin addresses was discussed. The purpose of this identifier is to distinguish why someone has made a payment to you. However, it is important to note that third-party observers are unable to link these payments on-chain and cannot determine which identifier was used. In situations where you do not want your identity to be revealed, the identifier alone is insufficient, and a separate Silent Payment address is required.Ruben also introduced a scheme that allows for multiple silent addresses per wallet with minimal overhead. This scheme enables the resulting address to be marked in a recognizable way, allowing the recipient to differentiate between different payment purposes. To implement this scheme, a public identifier "f" is added to a key when tweaking. It is essential to communicate this identifier to the sender, possibly as part of the address format. The new address format includes a field called "identifier," which guides both the receiver and sender in setting the address correctly. If the receiver is unaware of which identifiers have been used, the wallet can scan all identifiers from 0 to 99. Currently, each wallet is limited to using only 100 different identifiers, but this limit can be increased in the future if needed. Furthermore, a new RPC (Remote Procedure Call) has been implemented to retrieve silent addresses. Users are now able to assign different labels to their addresses, allowing them to identify which silent address a specific UTXO (Unspent Transaction Output) came from. This feature enhances usability and organization within the wallet. It should be noted that the newly introduced silent payment (SP) addresses are not script-related, which means they can potentially include additional information, such as an expiration timestamp or block height in the future. To assist users in understanding and implementing this scheme, a step-by-step tutorial has been provided on Github. This comprehensive tutorial serves as a reference guide for users interested in utilizing the new scheme proposed by Ruben Somsen. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml b/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml index 3a2adc9aae..34ff6940ec 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Transcript: Online Socratic on MuSig2 - 2023-08-02T07:22:39.119209+00:00 + 2025-09-26T14:19:53.928963+00:00 + python-feedgen Michael Folkson 2022-09-12 16:00:52+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Transcript: Online Socratic on MuSig2 - 2023-08-02T07:22:39.119209+00:00 + 2025-09-26T14:19:53.929118+00:00 - In a conversation between Ali Sherief and Michael Folkson, the issue of theft and online connectivity with signature generation is discussed. Michael explains that generating a signature requires private keys, which raises concerns about security and theft. However, he suggests that using multisig arrangements can prevent loss of funds in case of theft of a single private key. Additionally, he mentions that key aggregation multisig increases interactivity requirements.Michael clarifies that while there isn't a concept of a "lite node" in signature generation, it makes more sense in the realm of verification. He gives an example of Liquid, where currently 11 signatures go onchain when funds are moved. However, if Liquid used a key aggregation scheme like FROST, only a single signature would be required onchain. He also suggests the possibility of increasing the number of signatures or implementing a nested MuSig/FROST scheme for added security.Ali contacts Michael regarding the detailed and comprehensive Socratic transcript, which covers various problems including theft and offline issues. Ali inquires if any research has been done that doesn't involve a trade-off between theft and online connectivity. While ROAST and Liquid provide solutions, they rely on centralized nodes. Ali proposes the idea of decentralizing federated nodes into "lite nodes" managed by each service wanting payment, creating a threshold signature from multiple subscribers paying simultaneously.On August 11th, an online Socratic session was held featuring Tim Ruffing and Elizabeth Crites, discussing topics related to MuSig(2), FROST, ROAST, and more. The transcript of the session can be found on btctranscripts.com, and the video is available on YouTube. A reading list has also been compiled, containing resources on MuSig(2), FROST, and ROAST. During the discussion, participants covered various subjects, including BIP340, handling x-only public keys in MuSig2, the proposed TLUV covenant opcode, the history and improvements of MuSig, comparisons between MuSig2 and FROST for multisig schemes, the absence of proofs of possession in MuSig2, and the current state of the draft MuSig2 BIP.Although the session was lengthy (approximately 2.5 hours), it offered valuable insights into these topics, making the transcript or video useful for anyone interested in the discussed subjects. Jonas Nick also tweeted that the MuSig2 BIP is nearing a stable version 1.0, which will be beneficial for those implementing it. All relevant sources and links have been provided for further reference. 2022-09-12T16:00:52+00:00 + In a conversation between Ali Sherief and Michael Folkson, the issue of theft and online connectivity with signature generation is discussed. Michael explains that generating a signature requires private keys, which raises concerns about security and theft. However, he suggests that using multisig arrangements can prevent loss of funds in case of theft of a single private key. Additionally, he mentions that key aggregation multisig increases interactivity requirements.Michael clarifies that while there isn't a concept of a "lite node" in signature generation, it makes more sense in the realm of verification. He gives an example of Liquid, where currently 11 signatures go onchain when funds are moved. However, if Liquid used a key aggregation scheme like FROST, only a single signature would be required onchain. He also suggests the possibility of increasing the number of signatures or implementing a nested MuSig/FROST scheme for added security.Ali contacts Michael regarding the detailed and comprehensive Socratic transcript, which covers various problems including theft and offline issues. Ali inquires if any research has been done that doesn't involve a trade-off between theft and online connectivity. While ROAST and Liquid provide solutions, they rely on centralized nodes. Ali proposes the idea of decentralizing federated nodes into "lite nodes" managed by each service wanting payment, creating a threshold signature from multiple subscribers paying simultaneously.On August 11th, an online Socratic session was held featuring Tim Ruffing and Elizabeth Crites, discussing topics related to MuSig(2), FROST, ROAST, and more. The transcript of the session can be found on btctranscripts.com, and the video is available on YouTube. A reading list has also been compiled, containing resources on MuSig(2), FROST, and ROAST. During the discussion, participants covered various subjects, including BIP340, handling x-only public keys in MuSig2, the proposed TLUV covenant opcode, the history and improvements of MuSig, comparisons between MuSig2 and FROST for multisig schemes, the absence of proofs of possession in MuSig2, and the current state of the draft MuSig2 BIP.Although the session was lengthy (approximately 2.5 hours), it offered valuable insights into these topics, making the transcript or video useful for anyone interested in the discussed subjects. Jonas Nick also tweeted that the MuSig2 BIP is nearing a stable version 1.0, which will be beneficial for those implementing it. All relevant sources and links have been provided for further reference. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses-to-prevent-address-reuse.xml b/static/bitcoin-dev/Sept_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses-to-prevent-address-reuse.xml index 81c98d05bd..6045472aaf 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses-to-prevent-address-reuse.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses-to-prevent-address-reuse.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Trustless Address Server – Outsourcing handing out addresses to prevent address reuse - 2023-08-02T07:42:25.308687+00:00 - - rot13maxi 2022-10-18 22:46:13+00:00 - - - Andrew Poelstra 2022-10-18 12:42:21+00:00 - - - Ruben Somsen 2022-10-18 12:40:38+00:00 - - - Bryan Bishop 2022-10-18 00:07:07+00:00 - - - rot13maxi 2022-10-17 23:26:15+00:00 - - - Ruben Somsen 2022-10-03 23:01:06+00:00 - - - David A. Harding 2022-10-02 22:48:21+00:00 - - - Ruben Somsen 2022-09-29 15:39:18+00:00 - + 2025-09-26T14:20:10.997446+00:00 + python-feedgen + + + [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse Ruben Somsen + 2022-09-29T15:39:00.000Z + + + David A. Harding + 2022-10-02T22:48:00.000Z + + + Ruben Somsen + 2022-10-03T23:01:00.000Z + + + rot13maxi + 2022-10-17T23:26:00.000Z + + + Bryan Bishop + 2022-10-18T00:07:00.000Z + + + Ruben Somsen + 2022-10-18T12:40:00.000Z + + + Andrew Poelstra + 2022-10-18T12:42:00.000Z + + + rot13maxi + 2022-10-18T22:46:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Trustless Address Server – Outsourcing handing out addresses to prevent address reuse - 2023-08-02T07:42:25.308687+00:00 + 2025-09-26T14:20:10.998549+00:00 - In a discussion on the bitcoin-dev mailing list, concerns were raised about the security of copy-pasting public keys. Andrew Poelstra clarified that the public key held by the wallet is only used for authentication and never leaves the wallet. He suggested that compromising the wallet's memory is much harder than compromising data on the clipboard. The proposal could even be implemented on a hardware wallet with an out-of-band way to obtain and authenticate public keys.Ruben Somsen proposed a method for recipients to sign their public keys for authentication purposes. However, Bryan Bishop pointed out the need for secure communication of the public key itself. Ruben suggested that whether or not Bob runs the Trustless Address Server himself is the meaningful distinction and proposed depositing signed keys to prevent malicious addresses from being distributed.A member named rot13maxi expressed concerns about clipboard hijacking, where the contents of the clipboard can be replaced with a malicious address without the user realizing it. Bryan Bishop highlighted that this problem also applies to copy-pasting public keys. The discussion emphasized the importance of verifying the accuracy of addresses and public keys before sending any funds.A developer proposed a setup where an address server provides fresh receive addresses to senders, improving privacy and address authentication. When a user wants to pay someone, their wallet asks the address server for an address, which is then signed and returned to ensure its authenticity. This allows the wallet to verify the intended recipient even if the data is intercepted. The developer suggested a protocol for interoperability between wallets and address servers.Another developer suggested an alternative solution involving submitting a transaction paying a placeholder address to the server and receiving a guaranteed unique address in return. If the transaction is not seen within a reasonable time, the server broadcasts the transaction paying the placeholder address. This approach is similar to the BIP78 payjoin protocol.Ruben thanked David for his suggestion and agreed on potential privacy reduction with placeholder transactions. David proposed an alternative method where the sender reveals their intended transaction to the server before receiving the address. This would prevent transaction replay attacks. Dave believes this approach satisfies all design constraints and is essentially the BIP78 payjoin protocol without payjoining.The post discusses a protocol for non-interactive distribution of bitcoin addresses, outsourcing interaction to third-party servers. The sender interacts with the server, which represents the recipient and provides an address from an xpub. One remaining challenge is the gap limit. An alternative mitigation involves revealing the intended transaction to the server before receiving the address. This protocol is useful for users wanting to use light clients, accept privacy degradation, and receive payments non-interactively. 2022-10-18T22:46:13+00:00 + In a discussion on the bitcoin-dev mailing list, concerns were raised about the security of copy-pasting public keys. Andrew Poelstra clarified that the public key held by the wallet is only used for authentication and never leaves the wallet. He suggested that compromising the wallet's memory is much harder than compromising data on the clipboard. The proposal could even be implemented on a hardware wallet with an out-of-band way to obtain and authenticate public keys.Ruben Somsen proposed a method for recipients to sign their public keys for authentication purposes. However, Bryan Bishop pointed out the need for secure communication of the public key itself. Ruben suggested that whether or not Bob runs the Trustless Address Server himself is the meaningful distinction and proposed depositing signed keys to prevent malicious addresses from being distributed.A member named rot13maxi expressed concerns about clipboard hijacking, where the contents of the clipboard can be replaced with a malicious address without the user realizing it. Bryan Bishop highlighted that this problem also applies to copy-pasting public keys. The discussion emphasized the importance of verifying the accuracy of addresses and public keys before sending any funds.A developer proposed a setup where an address server provides fresh receive addresses to senders, improving privacy and address authentication. When a user wants to pay someone, their wallet asks the address server for an address, which is then signed and returned to ensure its authenticity. This allows the wallet to verify the intended recipient even if the data is intercepted. The developer suggested a protocol for interoperability between wallets and address servers.Another developer suggested an alternative solution involving submitting a transaction paying a placeholder address to the server and receiving a guaranteed unique address in return. If the transaction is not seen within a reasonable time, the server broadcasts the transaction paying the placeholder address. This approach is similar to the BIP78 payjoin protocol.Ruben thanked David for his suggestion and agreed on potential privacy reduction with placeholder transactions. David proposed an alternative method where the sender reveals their intended transaction to the server before receiving the address. This would prevent transaction replay attacks. Dave believes this approach satisfies all design constraints and is essentially the BIP78 payjoin protocol without payjoining.The post discusses a protocol for non-interactive distribution of bitcoin addresses, outsourcing interaction to third-party servers. The sender interacts with the server, which represents the recipient and provides an address from an xpub. One remaining challenge is the gap limit. An alternative mitigation involves revealing the intended transaction to the server before receiving the address. This protocol is useful for users wanting to use light clients, accept privacy degradation, and receive payments non-interactively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_Wallet-policies-for-descriptor-wallets.xml b/static/bitcoin-dev/Sept_2022/combined_Wallet-policies-for-descriptor-wallets.xml index 004ec6551d..6af18a3682 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Wallet-policies-for-descriptor-wallets.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Wallet-policies-for-descriptor-wallets.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Wallet policies for descriptor wallets - 2023-08-02T06:23:33.636002+00:00 - - Salvatore Ingala 2023-01-24 08:38:29+00:00 - - - darosior 2023-01-23 19:53:18+00:00 - - - Salvatore Ingala 2022-11-21 11:27:25+00:00 - - - Andrew Poelstra 2022-09-29 23:56:51+00:00 - - - Salvatore Ingala 2022-05-17 08:44:53+00:00 - - - Salvatore Ingala 2022-05-10 09:37:26+00:00 - - - darosior 2022-05-09 11:36:47+00:00 - - - Billy Tetrud 2022-05-08 17:41:07+00:00 - - - Salvatore Ingala 2022-05-05 14:32:34+00:00 - + 2025-09-26T14:19:58.192851+00:00 + python-feedgen + + + [bitcoin-dev] Wallet policies for descriptor wallets Salvatore Ingala + 2022-05-05T14:32:00.000Z + + + Billy Tetrud + 2022-05-08T17:41:00.000Z + + + darosior + 2022-05-09T11:36:00.000Z + + + Salvatore Ingala + 2022-05-10T09:37:00.000Z + + + Salvatore Ingala + 2022-05-17T08:44:00.000Z + + + Andrew Poelstra + 2022-09-29T23:56:00.000Z + + + Salvatore Ingala + 2022-11-21T11:27:00.000Z + + + darosior + 2023-01-23T19:53:00.000Z + + + Salvatore Ingala + 2023-01-24T08:38:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Wallet policies for descriptor wallets - 2023-08-02T06:23:33.637054+00:00 + 2025-09-26T14:19:58.193972+00:00 - Salvatore Ingala, a Bitcoin developer, has proposed a new language called "wallet policies" to address challenges in implementing descriptors and miniscript support in hardware wallets. These challenges arise due to limited RAM, computational power, and storage capacity of hardware wallets.The proposed language aims to provide a native, compact representation of the wallet receive/change and improve the user experience of software wallets. The registration flow for wallet policies involves the software wallet initiating a registration process on the hardware wallet. The information includes the wallet policy and a unique name that identifies the policy. The hardware wallet displays the policy on its secure screen, allowing the user to review and compare it with a trusted source before approving it. The goal is to ensure that the user knows the policy being used to spend their funds, preventing any malicious modifications.To simplify implementation and improve user experience, the document proposes minimizing the amount of information shown on-screen and reducing the number of times the user needs to validate such information. It also suggests reusing the same xpub in multiple places to avoid blowup in descriptor size. The proof of registration is executed securely using message authentication codes.The document provides examples of wallet descriptor templates for different use cases, such as native segwit accounts, taproot BIP86 accounts, native segwit 2-of-3, and templates with miniscript for "1 of 2 equally likely keys." It also includes additional rules, implementation guidelines, and references to relevant Bitcoin Improvement Proposals (BIPs) for further information.The email exchange discusses the challenges of implementing output descriptors on signing devices, proposing optimizations to overcome difficulties for implementers. It suggests optimizations for common use cases, such as using two descriptors at different derivation indices for receive and change addresses. The conversation also touches on the feasibility of incorporating Musig2 descriptors into hardware wallets and the potential for improving key aliasing using wallet policies.Overall, the proposed wallet policies language aims to provide a secure and user-friendly solution for integrating descriptors and miniscript support in hardware wallets, addressing the limitations of embedded devices and ensuring good user experience.Salvatore Ingala addresses the challenges of implementing descriptors and miniscript support in hardware wallets due to technical constraints such as limited RAM and computational power. To overcome these limitations, Ingala proposes a "wallet policies" language that can be used by all hardware wallets to securely support complex scripts.The proposed solution involves a registration flow for the wallet policy in the hardware wallet. This registration process includes generating all relevant addresses/scripts and identifying keys controlled by the hardware wallet. The user registers a wallet policy into the hardware wallet, and the software wallet initiates the registration on the hardware wallet. The registered policy is stored in the hardware wallet's permanent memory, and a master key encrypts all necessary information required to spend funds sent to those addresses.The policy language suggested targets a stricter subset of the output descriptors language, making it easier to implement and allowing for human inspection during the registration flow. Wallet descriptor templates consist of key placeholders and key origin information, including various types such as P2SH, P2WSH, P2PKH, P2WPKH, multisig, sorted multi, P2TR, and miniscript templates.The document outlines a standard for output script descriptors used to derive addresses and scripts from wallet descriptor templates. It specifies that wallet policies are considered invalid if any placeholder has derivation steps while the corresponding element of the keys vector is not an xpub. The document provides examples of wallet descriptor templates for native segwit accounts, taproot BIP86 accounts, and multisig setups.Overall, the proposed wallet policies language aims to address the security and user experience challenges faced by hardware wallets when supporting complex scripts. By registering wallet policies, hardware wallets can securely perform operations like generating addresses and signing transactions. 2023-01-24T08:38:29+00:00 + Salvatore Ingala, a Bitcoin developer, has proposed a new language called "wallet policies" to address challenges in implementing descriptors and miniscript support in hardware wallets. These challenges arise due to limited RAM, computational power, and storage capacity of hardware wallets.The proposed language aims to provide a native, compact representation of the wallet receive/change and improve the user experience of software wallets. The registration flow for wallet policies involves the software wallet initiating a registration process on the hardware wallet. The information includes the wallet policy and a unique name that identifies the policy. The hardware wallet displays the policy on its secure screen, allowing the user to review and compare it with a trusted source before approving it. The goal is to ensure that the user knows the policy being used to spend their funds, preventing any malicious modifications.To simplify implementation and improve user experience, the document proposes minimizing the amount of information shown on-screen and reducing the number of times the user needs to validate such information. It also suggests reusing the same xpub in multiple places to avoid blowup in descriptor size. The proof of registration is executed securely using message authentication codes.The document provides examples of wallet descriptor templates for different use cases, such as native segwit accounts, taproot BIP86 accounts, native segwit 2-of-3, and templates with miniscript for "1 of 2 equally likely keys." It also includes additional rules, implementation guidelines, and references to relevant Bitcoin Improvement Proposals (BIPs) for further information.The email exchange discusses the challenges of implementing output descriptors on signing devices, proposing optimizations to overcome difficulties for implementers. It suggests optimizations for common use cases, such as using two descriptors at different derivation indices for receive and change addresses. The conversation also touches on the feasibility of incorporating Musig2 descriptors into hardware wallets and the potential for improving key aliasing using wallet policies.Overall, the proposed wallet policies language aims to provide a secure and user-friendly solution for integrating descriptors and miniscript support in hardware wallets, addressing the limitations of embedded devices and ensuring good user experience.Salvatore Ingala addresses the challenges of implementing descriptors and miniscript support in hardware wallets due to technical constraints such as limited RAM and computational power. To overcome these limitations, Ingala proposes a "wallet policies" language that can be used by all hardware wallets to securely support complex scripts.The proposed solution involves a registration flow for the wallet policy in the hardware wallet. This registration process includes generating all relevant addresses/scripts and identifying keys controlled by the hardware wallet. The user registers a wallet policy into the hardware wallet, and the software wallet initiates the registration on the hardware wallet. The registered policy is stored in the hardware wallet's permanent memory, and a master key encrypts all necessary information required to spend funds sent to those addresses.The policy language suggested targets a stricter subset of the output descriptors language, making it easier to implement and allowing for human inspection during the registration flow. Wallet descriptor templates consist of key placeholders and key origin information, including various types such as P2SH, P2WSH, P2PKH, P2WPKH, multisig, sorted multi, P2TR, and miniscript templates.The document outlines a standard for output script descriptors used to derive addresses and scripts from wallet descriptor templates. It specifies that wallet policies are considered invalid if any placeholder has derivation steps while the corresponding element of the keys vector is not an xpub. The document provides examples of wallet descriptor templates for native segwit accounts, taproot BIP86 accounts, and multisig setups.Overall, the proposed wallet policies language aims to address the security and user experience challenges faced by hardware wallets when supporting complex scripts. By registering wallet policies, hardware wallets can securely perform operations like generating addresses and signing transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_bitcoin-inquistion-evaluating-soft-forks-on-signet.xml b/static/bitcoin-dev/Sept_2022/combined_bitcoin-inquistion-evaluating-soft-forks-on-signet.xml index 2d1845b770..3beb8f63a5 100644 --- a/static/bitcoin-dev/Sept_2022/combined_bitcoin-inquistion-evaluating-soft-forks-on-signet.xml +++ b/static/bitcoin-dev/Sept_2022/combined_bitcoin-inquistion-evaluating-soft-forks-on-signet.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - bitcoin-inquistion: evaluating soft forks on signet - 2023-08-02T07:24:40.953699+00:00 - - Anthony Towns 2022-10-03 22:54:04+00:00 - - - Michael Folkson 2022-10-02 15:25:19+00:00 - - - Anthony Towns 2022-10-02 06:12:10+00:00 - - - Anthony Towns 2022-10-02 04:06:54+00:00 - - - alicexbt 2022-09-28 20:01:46+00:00 - - - Michael Folkson 2022-09-28 11:48:32+00:00 - - - Anthony Towns 2022-09-19 10:05:47+00:00 - - - Antoine Riard 2022-09-18 18:47:38+00:00 - - - Michael Folkson 2022-09-18 18:44:31+00:00 - - - alicexbt 2022-09-18 12:27:43+00:00 - - - Michael Folkson 2022-09-17 15:53:48+00:00 - - - Matt Corallo 2022-09-17 08:39:07+00:00 - - - Anthony Towns 2022-09-17 06:14:05+00:00 - - - Matt Corallo 2022-09-16 16:46:53+00:00 - - - Anthony Towns 2022-09-16 07:15:45+00:00 - + 2025-09-26T14:20:13.148933+00:00 + python-feedgen + + + [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet Anthony Towns + 2022-09-16T07:15:00.000Z + + + Matt Corallo + 2022-09-16T16:46:00.000Z + + + Anthony Towns + 2022-09-17T06:14:00.000Z + + + Matt Corallo + 2022-09-17T08:39:00.000Z + + + Michael Folkson + 2022-09-17T15:53:00.000Z + + + alicexbt + 2022-09-18T12:27:00.000Z + + + Michael Folkson + 2022-09-18T18:44:00.000Z + + + Antoine Riard + 2022-09-18T18:47:00.000Z + + + Anthony Towns + 2022-09-19T10:05:00.000Z + + + Michael Folkson + 2022-09-28T11:48:00.000Z + + + alicexbt + 2022-09-28T20:01:00.000Z + + + Anthony Towns + 2022-10-02T04:06:00.000Z + + + Anthony Towns + 2022-10-02T06:12:00.000Z + + + Michael Folkson + 2022-10-02T15:25:00.000Z + + + Anthony Towns + 2022-10-03T22:54:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - bitcoin-inquistion: evaluating soft forks on signet - 2023-08-02T07:24:40.953699+00:00 + 2025-09-26T14:20:13.150857+00:00 - In an email thread on Bitcoin-dev, developers discussed the challenges of progressing soft fork proposals in Bitcoin. While some believe the current process is sufficient, others argue for more testing and evaluation before implementation. One suggestion is to experiment with soft forks on signet, which would allow for multiple consensus changes to be deployed and compared. Signet also has more activity than Liquid, making it a better testing ground. The community also discussed upgrades like APO/eltoo and Simplicity, as well as Antoine's covenant R&D effort.The lack of champions for soft forks was identified as a major issue. Matt Corallo disagreed with the idea that testing frameworks were the problem, stating that the lack of champions following all the necessary steps was the main obstacle. He emphasized that being a champion is a full-time job that requires months of attention. He encouraged those interested in contributing to Core and becoming a champion to seek mentorship. The group recognized the need for humility, confidence, interest, and time to move forward with soft forks.The importance of finding champions for proposed upgrades like CheckTemplateVerify (CTV) was also discussed. Critics pointed out the lack of a champion for CTV's implementation. Corallo argued that having only one author on the list did not constitute a completed step three. He suggested that the lack of progress could be due to issues with step four, the evaluation process, or the difficulty of steps two and three. He stressed the need for exploration, development, and research into covenants, as well as fostering a community open to new ideas while avoiding chain split fights.Matt Corallo posted a message on the bitcoin-dev mailing list, encouraging contributions towards Bitcoin's Taproot upgrade. He highlighted the importance of community involvement and mentioned that many people would be willing to mentor those interested in contributing. Taproot aims to improve privacy, scalability, and security by enhancing Bitcoin's scripting language.The email exchange between Anthony Towns and Matt Corallo discussed the process of progressing soft forks in Bitcoin. Corallo outlined a four-step process involving idea generation, socialization, proposal, and finding champions. Towns argued that the lack of progress on the great consensus cleanup indicated issues with the process. Corallo disagreed, stating that potential champions were deterred by the time-consuming nature of the role. He encouraged interested individuals to reach out for mentorship.The email thread on bitcoin-dev also addressed the difficulty of getting soft fork ideas from concept to deployment. The discussion touched on various topics, including the lack of community consensus, the potential of signet for testing proposed changes, and the importance of finding champions to push ideas forward. Matt Corallo disagreed with the notion that lack of test frameworks was a significant issue and emphasized the need for champions. The thread provided links to relevant discussions and alternative approaches to soft forks.In summary, the email thread discusses the pressure to merge unfinished or buggy soft fork proposals on the default signet and the need for proper evaluation and testing. Various suggestions are made, including using custom public signets, deploying bitcoin-inquisition on the default global signet, and implementing prototypes for evaluation. The importance of multiple developers and researchers reviewing pull requests and the ongoing evaluation of creative ideas in Bitcoin development are also emphasized.The article discussed the challenges faced in activating soft forks on Bitcoin and proposed a new approach. It suggested deploying soft forks on the default global signet to demonstrate their value but acknowledged the conundrum of activation without merging into Bitcoin Core. A fork called "bitcoin-inquisition" was proposed to add support for consensus changes, allowing miners to coordinate upgrades and avoiding the promotion of proposals by miners/maintainers. Overall, the proposal offered a solution to the challenges of activating soft forks on Bitcoin. 2022-10-03T22:54:04+00:00 + In an email thread on Bitcoin-dev, developers discussed the challenges of progressing soft fork proposals in Bitcoin. While some believe the current process is sufficient, others argue for more testing and evaluation before implementation. One suggestion is to experiment with soft forks on signet, which would allow for multiple consensus changes to be deployed and compared. Signet also has more activity than Liquid, making it a better testing ground. The community also discussed upgrades like APO/eltoo and Simplicity, as well as Antoine's covenant R&D effort.The lack of champions for soft forks was identified as a major issue. Matt Corallo disagreed with the idea that testing frameworks were the problem, stating that the lack of champions following all the necessary steps was the main obstacle. He emphasized that being a champion is a full-time job that requires months of attention. He encouraged those interested in contributing to Core and becoming a champion to seek mentorship. The group recognized the need for humility, confidence, interest, and time to move forward with soft forks.The importance of finding champions for proposed upgrades like CheckTemplateVerify (CTV) was also discussed. Critics pointed out the lack of a champion for CTV's implementation. Corallo argued that having only one author on the list did not constitute a completed step three. He suggested that the lack of progress could be due to issues with step four, the evaluation process, or the difficulty of steps two and three. He stressed the need for exploration, development, and research into covenants, as well as fostering a community open to new ideas while avoiding chain split fights.Matt Corallo posted a message on the bitcoin-dev mailing list, encouraging contributions towards Bitcoin's Taproot upgrade. He highlighted the importance of community involvement and mentioned that many people would be willing to mentor those interested in contributing. Taproot aims to improve privacy, scalability, and security by enhancing Bitcoin's scripting language.The email exchange between Anthony Towns and Matt Corallo discussed the process of progressing soft forks in Bitcoin. Corallo outlined a four-step process involving idea generation, socialization, proposal, and finding champions. Towns argued that the lack of progress on the great consensus cleanup indicated issues with the process. Corallo disagreed, stating that potential champions were deterred by the time-consuming nature of the role. He encouraged interested individuals to reach out for mentorship.The email thread on bitcoin-dev also addressed the difficulty of getting soft fork ideas from concept to deployment. The discussion touched on various topics, including the lack of community consensus, the potential of signet for testing proposed changes, and the importance of finding champions to push ideas forward. Matt Corallo disagreed with the notion that lack of test frameworks was a significant issue and emphasized the need for champions. The thread provided links to relevant discussions and alternative approaches to soft forks.In summary, the email thread discusses the pressure to merge unfinished or buggy soft fork proposals on the default signet and the need for proper evaluation and testing. Various suggestions are made, including using custom public signets, deploying bitcoin-inquisition on the default global signet, and implementing prototypes for evaluation. The importance of multiple developers and researchers reviewing pull requests and the ongoing evaluation of creative ideas in Bitcoin development are also emphasized.The article discussed the challenges faced in activating soft forks on Bitcoin and proposed a new approach. It suggested deploying soft forks on the default global signet to demonstrate their value but acknowledged the conundrum of activation without merging into Bitcoin Core. A fork called "bitcoin-inquisition" was proposed to add support for consensus changes, allowing miners to coordinate upgrades and avoiding the promotion of proposals by miners/maintainers. Overall, the proposal offered a solution to the challenges of activating soft forks on Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml b/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml index 5ba5df5f2b..434f0f9c6e 100644 --- a/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml +++ b/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - joinstr: coinjoin implementation using nostr - 2023-08-02T07:18:10.724897+00:00 + 2025-09-26T14:20:17.411360+00:00 + python-feedgen alicexbt 2022-09-10 10:17:37+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - joinstr: coinjoin implementation using nostr - 2023-08-02T07:18:10.724897+00:00 + 2025-09-26T14:20:17.411525+00:00 - A developer named alicexbt has created a proof-of-concept python script to implement coinjoin using nostr, a decentralized network based on cryptographic keypairs. This implementation utilizes several Bitcoin Core wallet and RPC commands and requires the python-nostr library for coordination between peers. The process involves 5 peers coordinating to create, sign, and broadcast a coinjoin transaction. Each step of the process is published as an event using a nostr relay, and users can use multiple relays simultaneously to avoid trusting a single relay. However, there is a vulnerability of denial of service in the implementation, where a malicious user can register multiple outputs with the same secret, causing an ongoing free denial of service attack without attribution or defense.To address this issue, PR #24058 (basic support BIP-322) can be implemented to add proof of ownership. Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, they can send `txid:out` with a message signed with the address, verify using `verifymessage`, and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO. The cryptographic scheme mentioned as an alternative to blind signatures isn't implemented yet, as it requires a NIP and at least one relay using it.The author plans to continue developing coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. Custom relays are supported by Nostr, examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. The author will run a free and open nostr relay for this project and try to fix the DoS issues before a mainnet version is released for the python script (for nerds) and android app (for all users).The email is sent using Proton Mail secure email, and the author invites opinions on the experiment. The email thread is part of the bitcoin-dev mailing list hosted by lists.linuxfoundation.org. The author credits Fiatjaf, Andrew Chow, Jeff Thibault, and existing coinjoin implementations for their contributions. The author also mentions the creation of an Android app for joinstr in the coming week.Overall, the developer's message provides insights into a coinjoin implementation using Nostr, the challenges and limitations of the current system, and potential improvements to make it more secure. The email includes relevant links to GitHub repositories and provides event IDs and a Coinjoin transaction ID for reference. 2022-09-10T10:17:37+00:00 + A developer named alicexbt has created a proof-of-concept python script to implement coinjoin using nostr, a decentralized network based on cryptographic keypairs. This implementation utilizes several Bitcoin Core wallet and RPC commands and requires the python-nostr library for coordination between peers. The process involves 5 peers coordinating to create, sign, and broadcast a coinjoin transaction. Each step of the process is published as an event using a nostr relay, and users can use multiple relays simultaneously to avoid trusting a single relay. However, there is a vulnerability of denial of service in the implementation, where a malicious user can register multiple outputs with the same secret, causing an ongoing free denial of service attack without attribution or defense.To address this issue, PR #24058 (basic support BIP-322) can be implemented to add proof of ownership. Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, they can send `txid:out` with a message signed with the address, verify using `verifymessage`, and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO. The cryptographic scheme mentioned as an alternative to blind signatures isn't implemented yet, as it requires a NIP and at least one relay using it.The author plans to continue developing coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. Custom relays are supported by Nostr, examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. The author will run a free and open nostr relay for this project and try to fix the DoS issues before a mainnet version is released for the python script (for nerds) and android app (for all users).The email is sent using Proton Mail secure email, and the author invites opinions on the experiment. The email thread is part of the bitcoin-dev mailing list hosted by lists.linuxfoundation.org. The author credits Fiatjaf, Andrew Chow, Jeff Thibault, and existing coinjoin implementations for their contributions. The author also mentions the creation of an Android app for joinstr in the coming week.Overall, the developer's message provides insights into a coinjoin implementation using Nostr, the challenges and limitations of the current system, and potential improvements to make it more secure. The email includes relevant links to GitHub repositories and provides event IDs and a Coinjoin transaction ID for reference. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Actuarial-System-To-Reduce-Interactivity-In-N-of-N-N-2-Multiparticipant-Offchain-Mechanisms.xml b/static/bitcoin-dev/Sept_2023/combined_Actuarial-System-To-Reduce-Interactivity-In-N-of-N-N-2-Multiparticipant-Offchain-Mechanisms.xml index e7a9f6c413..4e2ab7a90b 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Actuarial-System-To-Reduce-Interactivity-In-N-of-N-N-2-Multiparticipant-Offchain-Mechanisms.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Actuarial-System-To-Reduce-Interactivity-In-N-of-N-N-2-Multiparticipant-Offchain-Mechanisms.xml @@ -1,51 +1,63 @@ - + 2 Combined summary - Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms - 2023-11-01T20:04:06.010074+00:00 - - AdamISZ 2023-10-31 22:12:20+00:00 - - - Antoine Riard 2023-10-05 02:12:33+00:00 - - - ZmnSCPxj 2023-09-12 09:41:18+00:00 - - - Antoine Riard 2023-09-11 06:02:13+00:00 - - - ZmnSCPxj 2023-09-09 01:27:38+00:00 - + 2025-09-26T14:30:14.286342+00:00 + python-feedgen + + + [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms ZmnSCPxj + 2023-09-09T01:27:00.000Z + + + Antoine Riard + 2023-09-11T06:02:00.000Z + + + ZmnSCPxj + 2023-09-12T09:41:00.000Z + + + David A. Harding + 2023-09-18T00:12:00.000Z + + + ZmnSCPxj + 2023-09-18T03:37:00.000Z + + + Antoine Riard + 2023-10-05T02:12:00.000Z + + + ZmnSCPxj + 2023-10-15T13:36:00.000Z + + + AdamISZ + 2023-10-31T22:12:00.000Z + + - python-feedgen + 2 Combined summary - Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms - 2023-11-01T20:04:06.010074+00:00 + 2025-09-26T14:30:14.287341+00:00 + 2023-10-31T22:12:20+00:00 The email discusses various aspects related to off-chain mechanisms in blockchain technology, specifically focusing on the Bitcoin blockchain. The sender introduces the concept of an actuary role, similar to miners in the blockchain, who are responsible for deciding transaction ordering without having custody of funds. Two proposed softforks, namely `SIGHASH_ANYPREVOUT` and `OP_CHECKSEPARATEDSIG`, are suggested to enable this actuary role. - The advantages of using an N-of-N signatory set in off-chain mechanisms are highlighted, providing consensus and preventing a majority from forcing movement of funds against a participant's will. However, it is noted that all participants need to be online to sign a new state, which can stall the protocol if one participant is offline. - -The concept of an off-chain "mempool" is introduced, where the state of the mechanism is considered as pairs of Bitcoin SCRIPT and satoshis, instantiated as actual transaction outputs. Participants can create transactions within the current state and send money to each other, but these transactions remain unconfirmed until they are signed off by all participants. - +The concept of an off-chain "mempool" is introduced, where the state of the mechanism is considered as pairs of Bitcoin SCRIPT and satoshis, instantiated as actual transaction outputs. Participants can create transactions within the current state and send money to each other, but these transactions remain unconfirmed until they are signed off by all participants. To address the confirmation issue without custodianship, the email suggests adding the actuary to the contract controlling the funds with a specific `R` value, preventing `R` reuse and enforcing single-spend. This ensures non-custodiality while maintaining an N-of-N requirement for spending. - The desired properties for the actuary role are highlighted, including the ability to select one transaction, inability to spend funds unilaterally or hold them hostage, and assurance that participants can drop the mechanism on-chain and recover their funds if the actuary stops responding. A suggested method to ensure these properties is infecting the SCRIPT of all outputs with `(sign-only-once(M) || CSV) && C`. - -The email also discusses the `SIGHASH_ANYPREVOUT` feature in Bitcoin transactions and its relationship to the actuary role. With `SIGHASH_ANYPREVOUT`, participants can confirm transactions "confirmed" by the actuary even if the actual transaction ID changes. - +The email also discusses the `SIGHASH_ANYPREVOUT` feature in Bitcoin transactions and its relationship to the actuary role. With `SIGHASH_ANYPREVOUT`, participants can confirm transactions "confirmed" by the actuary even if the actual transaction ID changes. An example scenario is provided to illustrate the proposed mechanism, involving three participants (A, B, C) and an actuary (M). Each participant has a base contract, and the actuary signs transactions using a fixed `R` nonce. When A wants to send money to B, they create a transaction with two new outputs. A solicits a single-spend signature from the actuary to ensure B's assurance against double-spending. If dropped on-chain, the confirmed transaction can be immediately confirmed on-chain as well. - To update the state of the mechanism, the actuary proposes a new state to each participant. Participants only need to validate expected outputs, reducing bandwidth requirements and providing a scaling advantage. All participants must sign off on each state update, preventing invalid states and dropping the current state on-chain if needed. - Custodial solutions are avoided in this design to minimize control over coins. The actuary role only confirms transactions and cannot move funds without consent, ensuring consensus from all participants. Participants can go offline and online while the actuary coordinates new states. - 2023-10-31T22:12:20+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_BIP-The-Taproot-Assets-Protocol.xml b/static/bitcoin-dev/Sept_2023/combined_BIP-The-Taproot-Assets-Protocol.xml index cd64cd0350..e5c17f7942 100644 --- a/static/bitcoin-dev/Sept_2023/combined_BIP-The-Taproot-Assets-Protocol.xml +++ b/static/bitcoin-dev/Sept_2023/combined_BIP-The-Taproot-Assets-Protocol.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP-????: The Taproot Assets Protocol - 2023-09-08T01:53:08.736058+00:00 - - Zac Greenwood 2023-09-07 16:31:57+00:00 - - - Olaoluwa Osuntokun 2023-09-06 19:01:20+00:00 - + 2025-09-26T14:30:22.776817+00:00 + python-feedgen + + + [bitcoin-dev] BIP-????: The Taproot Assets Protocol Olaoluwa Osuntokun + 2023-09-06T19:01:00.000Z + + + Zac Greenwood + 2023-09-07T16:31:00.000Z + + - python-feedgen + 2 Combined summary - BIP-????: The Taproot Assets Protocol - 2023-09-08T01:53:08.736111+00:00 + 2025-09-26T14:30:22.777275+00:00 - The email is a request for an explanation of how registering non-Bitcoin assets on the Bitcoin blockchain benefits the Bitcoin economy. It mentions the official publication of the Taproot Assets Protocol and the request for BIP numbers. The full set of documents, including the breakdown of the BIPs, can be found on GitHub.The BIPs covered in the email are as follows:- `bip-tap-mssmt`: This BIP describes the MS-SMT data structure used to store assets and various proofs.- `bip-tap`: This BIP describes the Taproot Assets Protocol validation and state transition rules.- `bip-tap-addr`: This BIP describes the address format used to send and receive assets.- `bip-tap-vm`: This BIP describes the initial version of the off-chain TAP VM used to lock and unlock assets.- `bip-tap-vpsbt`: This BIP describes a vPSBT, which is a series of custom types on top of the existing PSBT protocol to facilitate more elaborate asset-related transactions.- `bip-tap-proof-file`: This BIP describes the flat file format used to prove and verify the provenance of an asset.- `bip-tap-universe`: This BIP describes the Universe server construct, which is an off-chain index into TAP data on-chain, used for proof distribution, asset bootstrapping, and asset transaction archiving.Some notable additions/modifications to the BIPs since their initial drafts were published last year include:- Test JSON vectors are now included for each BIP document.- Further specification of the Universe construct for initial verification of assets, distributing asset proofs, and transaction archiving, with a syncing algorithm and standardized REST/gRPC interface.- Development of the asset group key structure, allowing for ongoing issuance and fungibility of disparate assets under the same sub-tree.- New versioning bytes across the protocol for extensibility and upgradability.- Changes to the asset metadata format, now committing to a hash of the serialized metadata and allowing structured data.- Observance of re-org protection for asset proofs and the use of an incremental hash function in the file format.- Specification of the vPSBT protocol, analogous to normal PSBTs for the TAP layer.Significant progress has also been made in the initial implementation of the protocol, with collaboration from wallets, explorers, services, and businesses to test and improve both the protocol and implementation. The team is actively working on the next major release towards the eventual deployment of the protocol on the mainnet. 2023-09-07T16:31:57+00:00 + The email is a request for an explanation of how registering non-Bitcoin assets on the Bitcoin blockchain benefits the Bitcoin economy. It mentions the official publication of the Taproot Assets Protocol and the request for BIP numbers. The full set of documents, including the breakdown of the BIPs, can be found on GitHub.The BIPs covered in the email are as follows:- `bip-tap-mssmt`: This BIP describes the MS-SMT data structure used to store assets and various proofs.- `bip-tap`: This BIP describes the Taproot Assets Protocol validation and state transition rules.- `bip-tap-addr`: This BIP describes the address format used to send and receive assets.- `bip-tap-vm`: This BIP describes the initial version of the off-chain TAP VM used to lock and unlock assets.- `bip-tap-vpsbt`: This BIP describes a vPSBT, which is a series of custom types on top of the existing PSBT protocol to facilitate more elaborate asset-related transactions.- `bip-tap-proof-file`: This BIP describes the flat file format used to prove and verify the provenance of an asset.- `bip-tap-universe`: This BIP describes the Universe server construct, which is an off-chain index into TAP data on-chain, used for proof distribution, asset bootstrapping, and asset transaction archiving.Some notable additions/modifications to the BIPs since their initial drafts were published last year include:- Test JSON vectors are now included for each BIP document.- Further specification of the Universe construct for initial verification of assets, distributing asset proofs, and transaction archiving, with a syncing algorithm and standardized REST/gRPC interface.- Development of the asset group key structure, allowing for ongoing issuance and fungibility of disparate assets under the same sub-tree.- New versioning bytes across the protocol for extensibility and upgradability.- Changes to the asset metadata format, now committing to a hash of the serialized metadata and allowing structured data.- Observance of re-org protection for asset proofs and the use of an incremental hash function in the file format.- Specification of the vPSBT protocol, analogous to normal PSBTs for the TAP layer.Significant progress has also been made in the initial implementation of the protocol, with collaboration from wallets, explorers, services, and businesses to test and improve both the protocol and implementation. The team is actively working on the next major release towards the eventual deployment of the protocol on the mainnet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Compressed-Bitcoin-Transactions.xml b/static/bitcoin-dev/Sept_2023/combined_Compressed-Bitcoin-Transactions.xml index 22cba7ac43..74f148a748 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Compressed-Bitcoin-Transactions.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Compressed-Bitcoin-Transactions.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Compressed Bitcoin Transactions - 2024-01-24T02:03:56.249090+00:00 - - Tom Briar 2024-01-19 21:09:35+00:00 - - - Jonas Schnelli 2024-01-18 09:24:02+00:00 - - - Tom Briar 2024-01-16 17:08:54+00:00 - - - Tom Briar 2024-01-09 15:31:37+00:00 - - - Andrew Poelstra 2024-01-05 15:19:31+00:00 - - - Tom Briar 2024-01-05 15:06:01+00:00 - - - Tom Briar 2023-09-05 18:30:42+00:00 - - - Peter Todd 2023-09-05 18:00:33+00:00 - - - Tom Briar 2023-09-01 17:05:17+00:00 - - - Jonas Schnelli 2023-09-01 16:56:22+00:00 - - - Tom Briar 2023-09-01 14:12:09+00:00 - - - Andrew Poelstra 2023-09-01 13:56:18+00:00 - - - Fabian 2023-09-01 10:43:26+00:00 - - - Fabian 2023-09-01 10:24:54+00:00 - - - Andrew Poelstra 2023-09-01 00:49:36+00:00 - - - Tom Briar 2023-08-31 21:30:16+00:00 - + 2025-09-26T14:30:12.136790+00:00 + python-feedgen + + + [bitcoin-dev] Compressed Bitcoin Transactions Tom Briar + 2023-08-31T21:30:00.000Z + + + Andrew Poelstra + 2023-09-01T00:49:00.000Z + + + Fabian + 2023-09-01T10:24:00.000Z + + + Fabian + 2023-09-01T10:43:00.000Z + + + Andrew Poelstra + 2023-09-01T13:56:00.000Z + + + Tom Briar + 2023-09-01T14:12:00.000Z + + + Jonas Schnelli + 2023-09-01T16:56:00.000Z + + + Tom Briar + 2023-09-01T17:05:00.000Z + + + Peter Todd + 2023-09-05T18:00:00.000Z + + + Tom Briar + 2023-09-05T18:30:00.000Z + + + Tom Briar + 2024-01-05T15:06:00.000Z + + + Andrew Poelstra + 2024-01-05T15:19:00.000Z + + + Tom Briar + 2024-01-09T15:31:00.000Z + + + Tom Briar + 2024-01-16T17:08:00.000Z + + + Jonas Schnelli + 2024-01-18T09:24:00.000Z + + + Tom Briar + 2024-01-19T21:09:00.000Z + + @@ -67,21 +86,17 @@ - python-feedgen + 2 Combined summary - Compressed Bitcoin Transactions - 2024-01-24T02:03:56.249206+00:00 + 2025-09-26T14:30:12.138735+00:00 + 2024-01-19T21:09:35+00:00 Tom's communication focuses on the development of data compression strategies for Bitcoin transactions, specifically targeting peer-to-peer encrypted traffic. He highlights that traditional compression tools like gzip are not efficient for compressing Bitcoin transactions due to their inability to handle pseudorandom data effectively. Instead, Tom suggests removing redundant elements such as hashes and public keys, which can be regenerated after decompression, to achieve significant size reductions. - He also emphasizes the necessity for application-layer solutions for version 2 encrypted P2P traffic, contrasting it with the OSI model layer adjustments suitable for non-encrypted version 1 traffic. A specific compression proposal at the application layer is scrutinized for its potential to enhance space savings without requiring substantial CPU resources, facilitating quicker block propagation throughout the network. These technical discussions continue on GitHub for a deeper evaluation of this approach. - The Compressed Transaction Schema, conceived by Tom Briar and Andrew Poelstra, is introduced as a technique to decrease transaction sizes within the Bitcoin network by up to 30%, particularly useful under BIP-324. The schema innovates by excluding optional components and introducing new formats such as relative block height and compressed inputs. It is especially beneficial in scenarios with limited bandwidth but sufficient processing power for decompression. Four methods are proposed to optimize compression, though one may complicate decompression in the event of block reorganizations. Details on this schema, including test vectors and performance examples, can be found in the documentation accessible via [this link](https://github.com/TomBriar/bitcoin/blob/2023-05--tx-compression/doc/compressed_transactions.md). - In practice, integrating this schema into Bitcoin Core requires balancing transaction size optimization with decompression time. Alternatives for handling lock time are discussed to conserve bytes, and a method involving encoding transaction outputs with a delta relative to a reference height is considered. Tom responds to feedback from Jonas and Fabian, noting efforts to gather empirical data and introducing a new RPC endpoint to monitor transaction age for compression eligibility. Clear guidelines in BIP documentation are emphasized to mitigate risks during blockchain reorganizations. - Fabian proposes future exploration of a sorted UTXO set index to save space and suggests alternatives for UTXO indexing, while Andrew requests a chart to illustrate the compression strength of specific transaction types. Tom has taken an active role in developing a compression schema for Bitcoin transactions, maintaining transaction integrity while optimizing for efficiency and security. He has made strides in implementing his schema, indicative of ongoing innovation in transaction processing. - 2024-01-19T21:09:35+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Concern-about-Inscriptions-.xml b/static/bitcoin-dev/Sept_2023/combined_Concern-about-Inscriptions-.xml index f9365da94b..500244f2e9 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Concern-about-Inscriptions-.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Concern-about-Inscriptions-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Concern about "Inscriptions" - 2023-09-07T01:54:05.383093+00:00 + Combined summary - Concern about "Inscriptions" + 2025-09-26T14:30:16.434293+00:00 + python-feedgen vjudeu at gazeta.pl 2023-09-06 08:00:53+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 - Combined summary - Concern about "Inscriptions" - 2023-09-07T01:54:05.383222+00:00 + Combined summary - Concern about "Inscriptions" + 2025-09-26T14:30:16.434464+00:00 - The email thread discusses the concept of cut-through transactions in the Bitcoin blockchain. Cut-through involves removing inscriptions from transaction chains while preserving the payment information. It is argued that cut-through is useful for scaling when there are only a few transactions, but it becomes less efficient when all transactions need to be included. The idea of implementing cut-through is seen as a natural consequence of enabling full Replace-By-Fee (RBF) transactions, which would lead to mempool-level batching.The discussion also revolves around the impact of cut-through on inscriptions. While cut-through can prove transaction chains using cryptography, it does not eliminate the presence of transactions in the blockchain. Full archival nodes still contain all the inscription data and can provide it to those who need it. It is compared to running pruned nodes in Bitcoin, where some nodes do not store all the data but can still access it from full archival nodes.Another topic brought up in the email thread is the suggestion of reducing the blocksize limit to address concerns about blockchain size increases and promote activity on the lightning network. It is proposed that the blocksize limit may have been increased unnecessarily in the past, and now it is worth considering a smaller blocksize to encourage more usage of the lightning network. The lightning network is seen as a potential solution to handle increased transaction volume while minimizing the growth of the blockchain.Inefficiencies and costs related to proof-of-secret-key schemes are also discussed. It is mentioned that reusing k values in ECDSA allows for data encoding in both k and the entire secret key, which can be exploited for encoding data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging and expensive.The email thread includes discussions on various topics related to the Bitcoin protocol. One of these topics involves adding a proof-of-work requirement to a public key on an open relay server protocol to deter spammers or scammers. The difficulty of embedding information in a public key is mentioned, particularly when considering the need for mobile devices to generate keys quickly.The email also touches on the issue of Bitcoin script exploits and vulnerabilities caused by the insertion of arbitrary data. Two strategies, Ordisrespector and Ordislow, are proposed as potential solutions to address these vulnerabilities. Ordisrespector allows node operators to opt-in to a self-defense mechanism against aggression via inserted arbitrary data, while Ordislow increases the coercion cost of mining entities relative to cooperation cost by delaying block propagation and requiring inserted arbitrary data in blocks.The inefficiency and costliness of proof-of-secret-key schemes are highlighted, with examples of how ECDSA can be exploited to encode data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging.The email thread also delves into the topic of inscription attacks and spam prevention in the Mimblewimble protocol. It is noted that range proofs in the protocol already prove knowledge of blinding factors in Pedersen commitments, eliminating the need for additional padding to prevent the encoding of spam. Pure Mimblewimble blockchains are seen as highly resistant to inscription and spam attacks.There is a mention of a project called STAMPS that embeds image data in multisig outputs, which increases the size of the UTXO set compared to other methods. Pay-to-Contact protocols are suggested as a way to tweak a pubkey with a small blob of data, allowing for the production of a signature proving knowledge of the private key.The email raises concerns about banning arbitrary data in programming and its consequences. It is argued that if arbitrary data is banned, actors will find ways to encode their data within sets of public keys. Public key data is indistinguishable from random data, making it difficult to determine if a given public key is used for encoding data or serving its intended purpose. Examples of how governments attempt to censor internet protocols and users adapt by tunneling their data through innocent-looking channels are mentioned.The email also mentions the ongoing struggle between decentralization and centralization in the Bitcoin system. It is suggested that incrementing the cost of operating a regular Bitcoin node could lead to reduced network decentralization and vulnerability to central entity control. The central entity does not necessarily have to be a government.Overall, the email thread covers various discussions related to block sizes, blockchain size increases, lightning network usage, proof-of-secret-key schemes, inscription attacks, spam prevention, and the struggle between decentralization and centralization in the Bitcoin system. 2023-09-06T08:00:53+00:00 + The email thread discusses the concept of cut-through transactions in the Bitcoin blockchain. Cut-through involves removing inscriptions from transaction chains while preserving the payment information. It is argued that cut-through is useful for scaling when there are only a few transactions, but it becomes less efficient when all transactions need to be included. The idea of implementing cut-through is seen as a natural consequence of enabling full Replace-By-Fee (RBF) transactions, which would lead to mempool-level batching.The discussion also revolves around the impact of cut-through on inscriptions. While cut-through can prove transaction chains using cryptography, it does not eliminate the presence of transactions in the blockchain. Full archival nodes still contain all the inscription data and can provide it to those who need it. It is compared to running pruned nodes in Bitcoin, where some nodes do not store all the data but can still access it from full archival nodes.Another topic brought up in the email thread is the suggestion of reducing the blocksize limit to address concerns about blockchain size increases and promote activity on the lightning network. It is proposed that the blocksize limit may have been increased unnecessarily in the past, and now it is worth considering a smaller blocksize to encourage more usage of the lightning network. The lightning network is seen as a potential solution to handle increased transaction volume while minimizing the growth of the blockchain.Inefficiencies and costs related to proof-of-secret-key schemes are also discussed. It is mentioned that reusing k values in ECDSA allows for data encoding in both k and the entire secret key, which can be exploited for encoding data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging and expensive.The email thread includes discussions on various topics related to the Bitcoin protocol. One of these topics involves adding a proof-of-work requirement to a public key on an open relay server protocol to deter spammers or scammers. The difficulty of embedding information in a public key is mentioned, particularly when considering the need for mobile devices to generate keys quickly.The email also touches on the issue of Bitcoin script exploits and vulnerabilities caused by the insertion of arbitrary data. Two strategies, Ordisrespector and Ordislow, are proposed as potential solutions to address these vulnerabilities. Ordisrespector allows node operators to opt-in to a self-defense mechanism against aggression via inserted arbitrary data, while Ordislow increases the coercion cost of mining entities relative to cooperation cost by delaying block propagation and requiring inserted arbitrary data in blocks.The inefficiency and costliness of proof-of-secret-key schemes are highlighted, with examples of how ECDSA can be exploited to encode data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging.The email thread also delves into the topic of inscription attacks and spam prevention in the Mimblewimble protocol. It is noted that range proofs in the protocol already prove knowledge of blinding factors in Pedersen commitments, eliminating the need for additional padding to prevent the encoding of spam. Pure Mimblewimble blockchains are seen as highly resistant to inscription and spam attacks.There is a mention of a project called STAMPS that embeds image data in multisig outputs, which increases the size of the UTXO set compared to other methods. Pay-to-Contact protocols are suggested as a way to tweak a pubkey with a small blob of data, allowing for the production of a signature proving knowledge of the private key.The email raises concerns about banning arbitrary data in programming and its consequences. It is argued that if arbitrary data is banned, actors will find ways to encode their data within sets of public keys. Public key data is indistinguishable from random data, making it difficult to determine if a given public key is used for encoding data or serving its intended purpose. Examples of how governments attempt to censor internet protocols and users adapt by tunneling their data through innocent-looking channels are mentioned.The email also mentions the ongoing struggle between decentralization and centralization in the Bitcoin system. It is suggested that incrementing the cost of operating a regular Bitcoin node could lead to reduced network decentralization and vulnerability to central entity control. The central entity does not necessarily have to be a government.Overall, the email thread covers various discussions related to block sizes, blockchain size increases, lightning network usage, proof-of-secret-key schemes, inscription attacks, spam prevention, and the struggle between decentralization and centralization in the Bitcoin system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Concrete-MATT-opcodes.xml b/static/bitcoin-dev/Sept_2023/combined_Concrete-MATT-opcodes.xml index a9b75f6c0e..f6b8dcf40a 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Concrete-MATT-opcodes.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Concrete-MATT-opcodes.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Concrete MATT opcodes - 2023-09-16T01:51:28.673509+00:00 - - Antoine Riard 2023-09-15 00:23:31+00:00 - - - Antoine Riard 2023-09-13 20:25:07+00:00 - - - symphonicbtc 2023-08-19 23:11:22+00:00 - - - Antoine Riard 2023-08-18 20:12:09+00:00 - - - Salvatore Ingala 2023-08-18 15:08:39+00:00 - - - symphonicbtc 2023-08-14 14:07:19+00:00 - - - Antoine Riard 2023-08-14 03:00:57+00:00 - - - Salvatore Ingala 2023-08-09 08:38:48+00:00 - - - Johan Torås Halseth 2023-08-07 11:37:07+00:00 - - - Salvatore Ingala 2023-08-07 08:31:40+00:00 - - - David A. Harding 2023-08-06 20:13:25+00:00 - - - Salvatore Ingala 2023-07-30 21:37:49+00:00 - + 2025-09-26T14:30:09.988442+00:00 + python-feedgen + + + [bitcoin-dev] Concrete MATT opcodes Salvatore Ingala + 2023-07-30T21:37:00.000Z + + + David A. Harding + 2023-08-06T20:13:00.000Z + + + Salvatore Ingala + 2023-08-07T08:31:00.000Z + + + Johan Torås Halseth + 2023-08-07T11:37:00.000Z + + + Salvatore Ingala + 2023-08-09T08:38:00.000Z + + + Antoine Riard + 2023-08-14T03:00:00.000Z + + + symphonicbtc + 2023-08-14T14:07:00.000Z + + + Salvatore Ingala + 2023-08-18T15:08:00.000Z + + + Antoine Riard + 2023-08-18T20:12:00.000Z + + + symphonicbtc + 2023-08-19T23:11:00.000Z + + + Antoine Riard + 2023-09-13T20:25:00.000Z + + + Antoine Riard + 2023-09-15T00:23:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Concrete MATT opcodes - 2023-09-16T01:51:28.673620+00:00 + 2025-09-26T14:30:09.989954+00:00 - Salvatore Ingala has presented a proposal for the core opcodes of MATT, including revisions and improvements to the implementation. The code is implemented in the bitcoin-inquisition repository fork, along with OP_CHECKTEMPLATEVERIFY. The changes made include replacing OP_CHECK{IN, OUT}CONTRACTVERIFY with a single opcode called OP_CHECKCONTRACTVERIFY (CCV) and introducing an additional `flags` parameter. The order of parameters has also been modified for better script writing. Various flags are defined, such as CCV_FLAG_CHECK_INPUT and CCV_FLAG_IGNORE_OUTPUT_AMOUNT. Special values are defined for certain parameters. The email emphasizes the flexibility and generality achieved with the new opcode, but acknowledges the potential benefits of additional opcodes and introspection. The email includes several references, including a website mentioning OP_CHECKCONTRACTVERIFY, a mailing list post discussing the MATT proposal, and a GitHub repository with the code implementation. 2023-09-15T00:23:31+00:00 + Salvatore Ingala has presented a proposal for the core opcodes of MATT, including revisions and improvements to the implementation. The code is implemented in the bitcoin-inquisition repository fork, along with OP_CHECKTEMPLATEVERIFY. The changes made include replacing OP_CHECK{IN, OUT}CONTRACTVERIFY with a single opcode called OP_CHECKCONTRACTVERIFY (CCV) and introducing an additional `flags` parameter. The order of parameters has also been modified for better script writing. Various flags are defined, such as CCV_FLAG_CHECK_INPUT and CCV_FLAG_IGNORE_OUTPUT_AMOUNT. Special values are defined for certain parameters. The email emphasizes the flexibility and generality achieved with the new opcode, but acknowledges the potential benefits of additional opcodes and introspection. The email includes several references, including a website mentioning OP_CHECKCONTRACTVERIFY, a mailing list post discussing the MATT proposal, and a GitHub repository with the code implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Draft-BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml b/static/bitcoin-dev/Sept_2023/combined_Draft-BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml index 0dac60bba5..c4e246e907 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Draft-BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Draft-BIP-OP-TXHASH-and-OP-CHECKTXHASHVERIFY.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Draft BIP: OP_TXHASH and OP_CHECKTXHASHVERIFY - 2023-10-07T01:53:23.790499+00:00 - - Steven Roose 2023-10-06 17:38:22+00:00 - - - Steven Roose 2023-09-30 11:44:02+00:00 - + 2025-09-26T14:30:05.725725+00:00 + python-feedgen + + + [bitcoin-dev] Draft BIP: OP_TXHASH and OP_CHECKTXHASHVERIFY Steven Roose + 2023-09-30T11:44:00.000Z + + + Steven Roose + 2023-10-06T17:38:00.000Z + + - python-feedgen + 2 Combined summary - Draft BIP: OP_TXHASH and OP_CHECKTXHASHVERIFY - 2023-10-07T01:53:23.790554+00:00 + 2025-09-26T14:30:05.726216+00:00 - In the email, Steven discusses the concept of a TxHash (Transaction Hash) and its formalization. He has been working on a specification and gathering feedback for several weeks. The full Bitcoin Improvement Proposal (BIP) text can be found in the attachment and also on the GitHub link provided.The BIP introduces the concept of a TxFieldSelector, which is a serialized data structure used to select data inside a transaction. It defines various global fields such as version, locktime, number of inputs, number of outputs, current input index, and current input control block. It also specifies the fields available for each input and output. The BIP introduces support for selecting inputs and outputs based on certain criteria, including all in/outputs, a single in/output at the same index as the input being executed, any number of leading in/outputs, and up to 64 individually selected in/outputs.Two new opcodes, OP_TXHASH and OP_CHECKTXHASHVERIFY, are introduced by the BIP. OP_TXHASH is enabled only in tapscript and takes a serialized TxFieldSelector from the stack and pushes on the stack a hash committing to all the selected data. OP_CHECKTXHASHVERIFY is enabled in all script contexts and expects a single item on the stack, interpreted as a 32-byte hash value concatenated with a serialized TxFieldSelector. Execution fails if the hash value in the data push doesn't match the calculated hash value based on the TxFieldSelector.The BIP also addresses concerns related to resource usage, particularly quadratic hashing. A potential caching strategy is proposed to prevent excessive hashing. Individual selection is limited to 64 items, and it suggests that selecting "all" in/outputs can mostly use the same caches as sighash calculations. Storing intermediate SHA256 contexts for prefix hashing is also mentioned as a possibility to minimize the number of items that need to be hashed repeatedly.The email highlights the achievements of this proposal, mentioning that the default TxFieldSelector is functionally equivalent to OP_CHECKTEMPLATEVERIFY, making it a strict upgrade of BIP-119. The flexibility of selecting transaction fields and in/outputs makes this construction more useful in designing protocols where users want to add fees to their transactions without breaking a transaction chain or when constructing transactions together with specific conditions on in/outputs. Additionally, OP_TXHASH, along with other opcodes like OP_CHECKSIGFROMSTACK, could be used as a replacement for complex sighash constructions.Some open questions are mentioned in the email. One question pertains to whether the proposal adequately addresses concerns around resource usage and quadratic hashing. Another question relates to including the TxFieldSelector as part of the hash, which would affect the ability to prove equality of fields. A potential solution is suggested, involving assigning additional bits in the "in/output selector" bytes to include the TxFieldSelector in the hash. The email seeks general feedback on the proposal and whether it should be implemented as a softfork.In conclusion, Steven is seeking wider feedback and community interest in this proposal for a TxHash concept. He expresses his willingness to spend time formalizing the BIP and working on an implementation for Bitcoin Core if there is community interest. 2023-10-06T17:38:22+00:00 + In the email, Steven discusses the concept of a TxHash (Transaction Hash) and its formalization. He has been working on a specification and gathering feedback for several weeks. The full Bitcoin Improvement Proposal (BIP) text can be found in the attachment and also on the GitHub link provided.The BIP introduces the concept of a TxFieldSelector, which is a serialized data structure used to select data inside a transaction. It defines various global fields such as version, locktime, number of inputs, number of outputs, current input index, and current input control block. It also specifies the fields available for each input and output. The BIP introduces support for selecting inputs and outputs based on certain criteria, including all in/outputs, a single in/output at the same index as the input being executed, any number of leading in/outputs, and up to 64 individually selected in/outputs.Two new opcodes, OP_TXHASH and OP_CHECKTXHASHVERIFY, are introduced by the BIP. OP_TXHASH is enabled only in tapscript and takes a serialized TxFieldSelector from the stack and pushes on the stack a hash committing to all the selected data. OP_CHECKTXHASHVERIFY is enabled in all script contexts and expects a single item on the stack, interpreted as a 32-byte hash value concatenated with a serialized TxFieldSelector. Execution fails if the hash value in the data push doesn't match the calculated hash value based on the TxFieldSelector.The BIP also addresses concerns related to resource usage, particularly quadratic hashing. A potential caching strategy is proposed to prevent excessive hashing. Individual selection is limited to 64 items, and it suggests that selecting "all" in/outputs can mostly use the same caches as sighash calculations. Storing intermediate SHA256 contexts for prefix hashing is also mentioned as a possibility to minimize the number of items that need to be hashed repeatedly.The email highlights the achievements of this proposal, mentioning that the default TxFieldSelector is functionally equivalent to OP_CHECKTEMPLATEVERIFY, making it a strict upgrade of BIP-119. The flexibility of selecting transaction fields and in/outputs makes this construction more useful in designing protocols where users want to add fees to their transactions without breaking a transaction chain or when constructing transactions together with specific conditions on in/outputs. Additionally, OP_TXHASH, along with other opcodes like OP_CHECKSIGFROMSTACK, could be used as a replacement for complex sighash constructions.Some open questions are mentioned in the email. One question pertains to whether the proposal adequately addresses concerns around resource usage and quadratic hashing. Another question relates to including the TxFieldSelector as part of the hash, which would affect the ability to prove equality of fields. A potential solution is suggested, involving assigning additional bits in the "in/output selector" bytes to include the TxFieldSelector in the hash. The email seeks general feedback on the proposal and whether it should be implemented as a softfork.In conclusion, Steven is seeking wider feedback and community interest in this proposal for a TxHash concept. He expresses his willingness to spend time formalizing the BIP and working on an implementation for Bitcoin Core if there is community interest. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_MATT-demo-Optimistic-execution-of-arbitrary-programs.xml b/static/bitcoin-dev/Sept_2023/combined_MATT-demo-Optimistic-execution-of-arbitrary-programs.xml index cda2e489b2..4b915e72b7 100644 --- a/static/bitcoin-dev/Sept_2023/combined_MATT-demo-Optimistic-execution-of-arbitrary-programs.xml +++ b/static/bitcoin-dev/Sept_2023/combined_MATT-demo-Optimistic-execution-of-arbitrary-programs.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - MATT: [demo] Optimistic execution of arbitrary programs - 2023-10-04T01:56:18.451166+00:00 - - Johan Torås Halseth 2023-10-03 07:53:08+00:00 - - - Anthony Towns 2023-10-02 15:10:08+00:00 - - - Johan Torås Halseth 2023-09-29 13:14:25+00:00 - + 2025-09-26T14:30:24.940150+00:00 + python-feedgen + + + [bitcoin-dev] MATT: [demo] Optimistic execution of arbitrary programs Johan Torås Halseth + 2023-09-29T13:14:00.000Z + + + Anthony Towns + 2023-10-02T15:10:00.000Z + + + Johan Torås Halseth + 2023-10-03T07:53:00.000Z + + - python-feedgen + 2 Combined summary - MATT: [demo] Optimistic execution of arbitrary programs - 2023-10-04T01:56:18.451224+00:00 + 2025-09-26T14:30:24.940693+00:00 - The email discusses the complexity notation of "O(n log n)" and suggests that it may be incorrect. The sender proposes that it should be denoted as "O(P + log(N))" where P represents the size of the program and N represents the number of steps (rounded up to a power of 2). However, the recipient disagrees with this suggestion and explains that it is necessary to directly know the values of h(sub_node1) and h(sub_node2) in order to compare them to the results obtained from running the computation. Without this direct knowledge, there is a 50/50 chance of choosing the incorrect subnode, making it difficult to prove a mistake with odds of only 1/2**N.The sender suggests an alternative representation of the nodes and leaves in the program, which would make it 32B longer but would eliminate the need for h() calculations. The proposed representation includes the start_pc, start_i, start_x, end_pc, end_i, end_x, h(sub_node1), and h(sub_node2) for nodes, and start_pc, start_i, start_x, end_pc, end_i, end_x, and null for leaves.The sender also raises a concern regarding the requirement for a balanced state tree. They argue that if a balanced tree is not mandatory, then there could be multiple possible trees for the same execution trace, making it easy to hide errors where the challenger cannot find them. To address this concern, the sender suggests adding a "start_stepcount" and "end_stepcount" to enforce a balanced state tree.Additionally, the recipient points out an error in a diagram illustrating the concept of state transitions. They clarify that the second node in the diagram should read "0|0|2 -> 0|1|4" instead of "0|0|2 -> 1|0|2", matching its left child.Lastly, the sender mentions that it is presumed that the counterparty verifies their knowledge of the program, i.e., all the leaves in the contract taptree, before agreeing to the contract. The recipient agrees with this assumption and concludes the email with a casual farewell.This email provides an introduction to the implementation of the original MATT challenge protocol. It includes a link to a write-up that provides a detailed description of how to transform a "high-level arbitrary program" into something that can be verified on-chain in Bitcoin Script. The write-up also contains instructions on running the code and inspecting the transactions using a local block explorer.The implementation utilizes the proposed opcode OP_CHECKCONTRACTVERIFY and OP_CAT. These opcodes are used to trace the execution of a program called `multiply`. The goal is to challenge the computation of this program in O(n logn) on-chain transactions.Unfortunately, the email does not provide any further details about the implementation or the specific challenges faced during the process. It mainly serves as an introduction to the topic and directs readers to the write-up for more information.[0] - Link to the original MATT challenge protocol: [insert link][1] - Link to the code for the `multiply` program: [insert link] 2023-10-03T07:53:08+00:00 + The email discusses the complexity notation of "O(n log n)" and suggests that it may be incorrect. The sender proposes that it should be denoted as "O(P + log(N))" where P represents the size of the program and N represents the number of steps (rounded up to a power of 2). However, the recipient disagrees with this suggestion and explains that it is necessary to directly know the values of h(sub_node1) and h(sub_node2) in order to compare them to the results obtained from running the computation. Without this direct knowledge, there is a 50/50 chance of choosing the incorrect subnode, making it difficult to prove a mistake with odds of only 1/2**N.The sender suggests an alternative representation of the nodes and leaves in the program, which would make it 32B longer but would eliminate the need for h() calculations. The proposed representation includes the start_pc, start_i, start_x, end_pc, end_i, end_x, h(sub_node1), and h(sub_node2) for nodes, and start_pc, start_i, start_x, end_pc, end_i, end_x, and null for leaves.The sender also raises a concern regarding the requirement for a balanced state tree. They argue that if a balanced tree is not mandatory, then there could be multiple possible trees for the same execution trace, making it easy to hide errors where the challenger cannot find them. To address this concern, the sender suggests adding a "start_stepcount" and "end_stepcount" to enforce a balanced state tree.Additionally, the recipient points out an error in a diagram illustrating the concept of state transitions. They clarify that the second node in the diagram should read "0|0|2 -> 0|1|4" instead of "0|0|2 -> 1|0|2", matching its left child.Lastly, the sender mentions that it is presumed that the counterparty verifies their knowledge of the program, i.e., all the leaves in the contract taptree, before agreeing to the contract. The recipient agrees with this assumption and concludes the email with a casual farewell.This email provides an introduction to the implementation of the original MATT challenge protocol. It includes a link to a write-up that provides a detailed description of how to transform a "high-level arbitrary program" into something that can be verified on-chain in Bitcoin Script. The write-up also contains instructions on running the code and inspecting the transactions using a local block explorer.The implementation utilizes the proposed opcode OP_CHECKCONTRACTVERIFY and OP_CAT. These opcodes are used to trace the execution of a program called `multiply`. The goal is to challenge the computation of this program in O(n logn) on-chain transactions.Unfortunately, the email does not provide any further details about the implementation or the specific challenges faced during the process. It mainly serves as an introduction to the topic and directs readers to the write-up for more information.[0] - Link to the original MATT challenge protocol: [insert link][1] - Link to the code for the `multiply` program: [insert link] - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_New-BIP-to-align-descriptors-xpub-derivation-and-miniscript.xml b/static/bitcoin-dev/Sept_2023/combined_New-BIP-to-align-descriptors-xpub-derivation-and-miniscript.xml index af3c75d9af..b9939419ee 100644 --- a/static/bitcoin-dev/Sept_2023/combined_New-BIP-to-align-descriptors-xpub-derivation-and-miniscript.xml +++ b/static/bitcoin-dev/Sept_2023/combined_New-BIP-to-align-descriptors-xpub-derivation-and-miniscript.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - New BIP to align descriptors, xpub derivation and miniscript - 2023-09-12T01:52:56.500179+00:00 - - Antoine Poinsot 2023-09-11 12:03:59+00:00 - - - Dr Maxim Orlovsky 2023-09-10 17:13:02+00:00 - + 2025-09-26T14:30:18.544414+00:00 + python-feedgen + + + [bitcoin-dev] New BIP to align descriptors, xpub derivation and miniscript Dr Maxim Orlovsky + 2023-09-10T17:13:00.000Z + + + Antoine Poinsot + 2023-09-11T12:03:00.000Z + + - python-feedgen + 2 Combined summary - New BIP to align descriptors, xpub derivation and miniscript - 2023-09-12T01:52:56.500227+00:00 + 2025-09-26T14:30:18.544846+00:00 - The email discusses the issues with the current implementation of script output descriptors, also known as "output descriptors" or "wallet descriptors," and proposes a new approach to address these problems. The combination of descriptors, miniscript, and extended BIP32 keys often leads to redundancy and unspecified caveats.One issue highlighted in the email is that the derivation path standards commit to a specific type of script pubkey, but this information is also present in the descriptor itself. This duplication creates redundancy and can lead to confusion. Additionally, each public key within the descriptor replicates the derivation information and information about the Bitcoin network, further adding to the redundancy.Another issue raised is the conflicting approaches for handling the use of the same signer in different miniscript branches. The email suggests two possible solutions: deriving a different hardened xpub from the signing device for each occurrence, which can be cumbersome, or querying a single xpub from the device and then appending an unhardened derivation step. The latter option can reduce the number of steps by reusing the multipath step.To address these issues, the email proposes a new BIP proposal that removes the redundancies and inconsistencies. The proposed approach suggests introducing a new BIP44 purpose field that will be used with all descriptor formats. This field will enforce a standardized format for all keys, ensuring that they follow the same standard and use the same network and terminal derivation format. The email provides an example of how these standardized descriptors would look like.The email emphasizes the importance of standardization and highlights that wallets unaware of client-side validation may spend UTXOs and burn external states if the meaning of certain segments is not extended through dedicated BIPs. Therefore, the author proposes that the new approach should be acknowledged by the mailing list and seeks Concept (n)ACKs and Approach (n)ACKs from the community.Once the approach is acknowledged, the email author plans to write a reference implementation in Rust and deploy it with the MyCitadel wallet, which is currently the only wallet that supports the combination of descriptors, miniscript, and taproot.In summary, the email discusses the issues with current script output descriptors and proposes a new approach to address these problems. The author plans to work on a BIP proposal after receiving feedback from the community and seeks support from the mailing list. 2023-09-11T12:03:59+00:00 + The email discusses the issues with the current implementation of script output descriptors, also known as "output descriptors" or "wallet descriptors," and proposes a new approach to address these problems. The combination of descriptors, miniscript, and extended BIP32 keys often leads to redundancy and unspecified caveats.One issue highlighted in the email is that the derivation path standards commit to a specific type of script pubkey, but this information is also present in the descriptor itself. This duplication creates redundancy and can lead to confusion. Additionally, each public key within the descriptor replicates the derivation information and information about the Bitcoin network, further adding to the redundancy.Another issue raised is the conflicting approaches for handling the use of the same signer in different miniscript branches. The email suggests two possible solutions: deriving a different hardened xpub from the signing device for each occurrence, which can be cumbersome, or querying a single xpub from the device and then appending an unhardened derivation step. The latter option can reduce the number of steps by reusing the multipath step.To address these issues, the email proposes a new BIP proposal that removes the redundancies and inconsistencies. The proposed approach suggests introducing a new BIP44 purpose field that will be used with all descriptor formats. This field will enforce a standardized format for all keys, ensuring that they follow the same standard and use the same network and terminal derivation format. The email provides an example of how these standardized descriptors would look like.The email emphasizes the importance of standardization and highlights that wallets unaware of client-side validation may spend UTXOs and burn external states if the meaning of certain segments is not extended through dedicated BIPs. Therefore, the author proposes that the new approach should be acknowledged by the mailing list and seeks Concept (n)ACKs and Approach (n)ACKs from the community.Once the approach is acknowledged, the email author plans to write a reference implementation in Rust and deploy it with the MyCitadel wallet, which is currently the only wallet that supports the combination of descriptors, miniscript, and taproot.In summary, the email discusses the issues with current script output descriptors and proposes a new approach to address these problems. The author plans to work on a BIP proposal after receiving feedback from the community and seeks support from the mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Parameters-in-BIP21-URIs.xml b/static/bitcoin-dev/Sept_2023/combined_Parameters-in-BIP21-URIs.xml index 0ae953e02a..5532abd3c5 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Parameters-in-BIP21-URIs.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Parameters-in-BIP21-URIs.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Parameters in BIP21 URIs - 2023-09-20T01:53:29.951989+00:00 - - Vincenzo Palazzo 2023-09-19 09:58:33+00:00 - - - Lucas Ontivero 2023-09-08 15:07:11+00:00 - - - kiminuo 2023-09-08 14:36:16+00:00 - + 2025-09-26T14:30:03.611990+00:00 + python-feedgen + + + [bitcoin-dev] Parameters in BIP21 URIs kiminuo + 2023-09-08T14:36:00.000Z + + + Lucas Ontivero + 2023-09-08T15:07:00.000Z + + + Vincenzo Palazzo + 2023-09-19T09:58:00.000Z + + - python-feedgen + 2 Combined summary - Parameters in BIP21 URIs - 2023-09-20T01:53:29.952052+00:00 + 2025-09-26T14:30:03.612689+00:00 - In a recent email, the sender refers to a previous discussion that took place on GitHub regarding a pull request for the Bitcoin Improvement Proposals (BIPs). The link provided leads to the specific discussion on the GitHub page. Please note that without access to the actual content of the email, it is difficult to provide a detailed summary. However, based on the given context, it can be inferred that the sender is directing the recipient's attention to a specific conversation or topic related to BIPs.The conversation on the GitHub page may involve discussions and debates among programmers regarding proposed improvements for the Bitcoin protocol. It is likely that various individuals have contributed their ideas and suggestions in the form of pull requests.As a programmer, it is important for the recipient to review this discussion and potentially contribute their own thoughts or insights. By examining the pull request and the associated comments, the recipient can gain a deeper understanding of the proposed changes and actively participate in the development process.It is essential to thoroughly analyze the conversation and consider different perspectives before forming an opinion or making any contributions. This will ensure that the recipient's input aligns with the overall goals and principles of the Bitcoin community.By following the link provided, the recipient can access the specific GitHub page and delve into the details of the ongoing discussion. Engaging with fellow programmers and staying up-to-date with the latest developments in the Bitcoin ecosystem is crucial for professional growth and contributing to the advancement of the technology.Moving on to another topic, BIP 21 defines a URI scheme for making Bitcoin payments, allowing users to easily make payments by clicking links on webpages or scanning QR codes. Bitcoin wallets register the "bitcoin" URI scheme to parse BIP21 URIs and pre-fill data in a form for sending bitcoin to a recipient.However, there seems to be a concern with the BIP21 grammar. According to the grammar, it is allowed to specify URI parameters multiple times. This means that parameters like 'amount' can be repeated in a URI. For example, the URI "bitcoin:bc1qd4fxq8y8c7qh76gfnvl7amuhag3z27uw0w9f8p?amount=0.004&label=Kiminuo&message=Donation&amount=1.004" is actually valid, with the 'amount' parameter specified twice.Bitcoin Core implements "the last value wins" behavior, meaning that the value specified last for a repeated parameter will be considered. In the mentioned example, the value "amount=1.004" will be taken into account instead of "amount=0.004".However, this ability to specify parameters multiple times can lead to confusion for users and developers. It could potentially be exploited by social engineering attempts to manipulate the behavior of a particular wallet software. Although there is currently no evidence of this happening, it is still a concern.Therefore, the main question posed in this email is whether allowing multiple specifications of BIP21 parameters is useful or harmful. To read the full context and explore the arguments presented, please refer to the original email. 2023-09-19T09:58:33+00:00 + In a recent email, the sender refers to a previous discussion that took place on GitHub regarding a pull request for the Bitcoin Improvement Proposals (BIPs). The link provided leads to the specific discussion on the GitHub page. Please note that without access to the actual content of the email, it is difficult to provide a detailed summary. However, based on the given context, it can be inferred that the sender is directing the recipient's attention to a specific conversation or topic related to BIPs.The conversation on the GitHub page may involve discussions and debates among programmers regarding proposed improvements for the Bitcoin protocol. It is likely that various individuals have contributed their ideas and suggestions in the form of pull requests.As a programmer, it is important for the recipient to review this discussion and potentially contribute their own thoughts or insights. By examining the pull request and the associated comments, the recipient can gain a deeper understanding of the proposed changes and actively participate in the development process.It is essential to thoroughly analyze the conversation and consider different perspectives before forming an opinion or making any contributions. This will ensure that the recipient's input aligns with the overall goals and principles of the Bitcoin community.By following the link provided, the recipient can access the specific GitHub page and delve into the details of the ongoing discussion. Engaging with fellow programmers and staying up-to-date with the latest developments in the Bitcoin ecosystem is crucial for professional growth and contributing to the advancement of the technology.Moving on to another topic, BIP 21 defines a URI scheme for making Bitcoin payments, allowing users to easily make payments by clicking links on webpages or scanning QR codes. Bitcoin wallets register the "bitcoin" URI scheme to parse BIP21 URIs and pre-fill data in a form for sending bitcoin to a recipient.However, there seems to be a concern with the BIP21 grammar. According to the grammar, it is allowed to specify URI parameters multiple times. This means that parameters like 'amount' can be repeated in a URI. For example, the URI "bitcoin:bc1qd4fxq8y8c7qh76gfnvl7amuhag3z27uw0w9f8p?amount=0.004&label=Kiminuo&message=Donation&amount=1.004" is actually valid, with the 'amount' parameter specified twice.Bitcoin Core implements "the last value wins" behavior, meaning that the value specified last for a repeated parameter will be considered. In the mentioned example, the value "amount=1.004" will be taken into account instead of "amount=0.004".However, this ability to specify parameters multiple times can lead to confusion for users and developers. It could potentially be exploited by social engineering attempts to manipulate the behavior of a particular wallet software. Although there is currently no evidence of this happening, it is still a concern.Therefore, the main question posed in this email is whether allowing multiple specifications of BIP21 parameters is useful or harmful. To read the full context and explore the arguments presented, please refer to the original email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml b/static/bitcoin-dev/Sept_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml index c521c5b761..c8e6a7cf01 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Scaling-Lightning-With-Simple-Covenants.xml @@ -1,53 +1,67 @@ - + 2 Combined summary - Scaling Lightning With Simple Covenants - 2023-11-17T02:04:15.764762+00:00 - - jlspc 2023-11-15 19:59:37+00:00 - - - jlspc 2023-10-06 16:26:33+00:00 - - - jlspc 2023-10-06 16:26:33+00:00 - - - jlspc 2023-09-28 15:56:11+00:00 - - - Antoine Riard 2023-09-26 16:42:34+00:00 - - - ZmnSCPxj 2023-09-19 07:44:48+00:00 - - - ZmnSCPxj 2023-09-18 04:14:55+00:00 - - - Erik Aronesty 2023-09-17 11:32:52+00:00 - - - jlspc 2023-09-17 00:59:39+00:00 - - - jlspc 2023-09-17 00:56:04+00:00 - - - jlspc 2023-09-17 00:52:13+00:00 - - - Antoine Riard 2023-09-11 05:27:25+00:00 - - - Rusty Russell 2023-09-11 02:13:52+00:00 - - - Anthony Towns 2023-09-11 00:56:40+00:00 - - - jlspc 2023-09-08 18:54:46+00:00 - + 2025-09-26T14:30:01.489381+00:00 + python-feedgen + + + [bitcoin-dev] Scaling Lightning With Simple Covenants jlspc + 2023-09-08T18:54:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2023-09-11T00:56:00.000Z + + + [bitcoin-dev] " Rusty Russell + 2023-09-11T02:13:00.000Z + + + Antoine Riard + 2023-09-11T05:27:00.000Z + + + jlspc + 2023-09-17T00:52:00.000Z + + + jlspc + 2023-09-17T00:56:00.000Z + + + jlspc + 2023-09-17T00:59:00.000Z + + + Erik Aronesty + 2023-09-17T11:32:00.000Z + + + ZmnSCPxj + 2023-09-18T04:14:00.000Z + + + ZmnSCPxj + 2023-09-19T07:44:00.000Z + + + Antoine Riard + 2023-09-26T16:42:00.000Z + + + jlspc + 2023-09-28T15:56:00.000Z + + + jlspc + 2023-10-06T16:26:00.000Z + + + jlspc + 2023-11-15T19:59:00.000Z + + @@ -63,23 +77,18 @@ - python-feedgen + 2 Combined summary - Scaling Lightning With Simple Covenants - 2023-11-17T02:04:15.764876+00:00 + 2025-09-26T14:30:01.491003+00:00 + 2023-11-15T19:59:37+00:00 The recent discussions among programmers have centered on enhancing the Lightning Network's operation and scalability. John has analyzed trade-offs between trust/safety and capital efficiency, suggesting a prepayment system to balance channel lifetime risks and fund adjustments. He has calculated the scalability of timeout-tree leaves on-chain using a Python program and contributed to a paper on passive rollovers, detailing the functioning of commitment transactions in hierarchical channels. - Antoine has highlighted scaling issues for off-chain constructions, like liquidity imbalances, proposing improvements such as on-chain splicing. He also expressed concerns about coordinating a large number of users and mentioned cryptographic tools for better scalability. - -John agreed with Antoine on addressing the needs of casual users, proposing hierarchical channels and timeout-trees for their convenience. He acknowledged practical challenges in coordination for required signatures and emphasized solutions that limit interactivity. John recommended a consensus rule change to deal with the "thundering herd" problem by basing timeout-tree expirations on low-fee block occurrences. - -The email defines user categories as "casual" or "dedicated," discussing trust assumptions and different scaling aspects: onboarding, transactional, and user resource scaling. It questions the feasibility of casual users engaging in future time-bound actions and highlights concerns about fund access, mempool congestion, and fee risk mitigation. - -The correspondence outlines critical issues in off-chain scaling, such as enforcement costs in channel factories and the trade-off between trust and capital efficiency. The paper suggests tolerating an increase in transactions for rule enforcement in mature systems. It contemplates the role of "dedicated users" within the fee structure and the balancing act between capital commitment and efficiency. - +John agreed with Antoine on addressing the needs of casual users, proposing hierarchical channels and timeout-trees for their convenience. He acknowledged practical challenges in coordination for required signatures and emphasized solutions that limit interactivity. John recommended a consensus rule change to deal with the "thundering herd" problem by basing timeout-tree expirations on low-fee block occurrences. +The email defines user categories as "casual" or "dedicated," discussing trust assumptions and different scaling aspects: onboarding, transactional, and user resource scaling. It questions the feasibility of casual users engaging in future time-bound actions and highlights concerns about fund access, mempool congestion, and fee risk mitigation. +The correspondence outlines critical issues in off-chain scaling, such as enforcement costs in channel factories and the trade-off between trust and capital efficiency. The paper suggests tolerating an increase in transactions for rule enforcement in mature systems. It contemplates the role of "dedicated users" within the fee structure and the balancing act between capital commitment and efficiency. The email proposes covenant-based solutions like CheckTemplateVerify (CTV) or AnyPrevOut (APO) for creating scalable channels without all participants' signatures. This approach reduces the need for co-owning on-chain UTXOs, enhancing scalability. It recommends integrating simple covenants and off-chain transaction methods into Bitcoin's consensus rules to reduce the on-chain footprint and facilitate off-chain operations, making the Lightning Network more accessible for payments. - 2023-11-15T19:59:37+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Solving-CoinPool-high-interactivity-issue-with-cut-through-update-of-Taproot-leaves.xml b/static/bitcoin-dev/Sept_2023/combined_Solving-CoinPool-high-interactivity-issue-with-cut-through-update-of-Taproot-leaves.xml index 084c802cb7..c7408b048f 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Solving-CoinPool-high-interactivity-issue-with-cut-through-update-of-Taproot-leaves.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Solving-CoinPool-high-interactivity-issue-with-cut-through-update-of-Taproot-leaves.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Solving CoinPool high-interactivity issue with cut-through update of Taproot leaves - 2023-10-15T01:58:55.359446+00:00 - - Johan Torås Halseth 2023-10-12 09:31:26+00:00 - - - Johan Torås Halseth 2023-10-05 07:38:24+00:00 - - - Antoine Riard 2023-10-05 01:13:06+00:00 - - - Johan Torås Halseth 2023-10-03 11:24:20+00:00 - - - Antoine Riard 2023-09-26 15:36:26+00:00 - - - ZmnSCPxj 2023-09-26 06:50:50+00:00 - - - Antoine Riard 2023-09-25 18:18:36+00:00 - + 2025-09-26T14:30:20.664197+00:00 + python-feedgen + + + [bitcoin-dev] Solving CoinPool high-interactivity issue with cut-through update of Taproot leaves Antoine Riard + 2023-09-25T18:18:00.000Z + + + ZmnSCPxj + 2023-09-26T06:50:00.000Z + + + Antoine Riard + 2023-09-26T15:36:00.000Z + + + Johan Torås Halseth + 2023-10-03T11:24:00.000Z + + + Antoine Riard + 2023-10-05T01:13:00.000Z + + + Johan Torås Halseth + 2023-10-05T07:38:00.000Z + + + Johan Torås Halseth + 2023-10-12T09:31:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Solving CoinPool high-interactivity issue with cut-through update of Taproot leaves - 2023-10-15T01:58:55.359525+00:00 + 2025-09-26T14:30:20.665201+00:00 - In the email, Johan discusses the concept of using a merkle root to track participants' keys and balances in a cryptocurrency system. He provides a demo script that shows how pubkeys and balances can be committed, how data can be traversed and modified, and how signatures can be validated for exiting users. Johan mentions that the script can likely be optimized and explains that the size of the script and witness will grow as more users exit a pool. He suggests that this growth in size would not be an issue in most cooperative settings.Johan also proposes the idea of performing the exit process off-chain, allowing offline users to revert back to the original coinpool output when they come back online. He believes this could work as long as the committed balances and keys remain compatible. The only change needed would be updating the merkle inclusion proofs in the jointly signed transactions. Johan asks Antoine if this functionality aligns with what he was looking for.Antoine's email discusses the use of OP_EVICT in the context of an off-chain payment pool. He expresses concerns about the safety of using OP_EVICT and mentions TLUV or MERKLESUB as possible alternative solutions. Antoine notes that there is currently no sound covenant proposal that combines TLUV and EVICT-like semantics while still allowing for unilateral withdrawal of promised balances. He expresses his interest in finding a better direction to solve the high interactivity issue of channel factory and payment pool.ZmnSCPxj reaches out to Antoine to inquire about the suitability of using "OP_EVICT" for an unknown purpose. The email lacks contextual information but includes a link to a mailing list archive for further reference.The email discusses the issue of interactivity constraints in payment pools and channel factories. It highlights the importance of ensuring the security of user funds and the need for unanimous agreement on updates to off-chain balances. Various proposed solutions are mentioned, including the introduction of a coordinator, partitioning balances, or layering balances among off-chain user subsets. The email also discusses the challenge of mitigating equivocation of off-chain balances and suggests punishing cheating counterparties through an external fidelity bond.The author proposes a solution to prevent off-chain group equivocation by proactively editing the funding utxo of the pool or factory. This approach involves registering new off-chain subgroups as needed and includes the concept of "cut-through" spends to update multiple leaves with a single witness. The email provides an example scenario illustrating how this solution would work in practice. The author believes that such a solution could also reduce the chain space consumed during mass pool withdrawals.Overall, the emails cover various topics related to cryptocurrency systems, including the use of merkle roots, OP_EVICT, alternative solutions, and the interactivity issue in payment pools and channel factories. 2023-10-12T09:31:26+00:00 + In the email, Johan discusses the concept of using a merkle root to track participants' keys and balances in a cryptocurrency system. He provides a demo script that shows how pubkeys and balances can be committed, how data can be traversed and modified, and how signatures can be validated for exiting users. Johan mentions that the script can likely be optimized and explains that the size of the script and witness will grow as more users exit a pool. He suggests that this growth in size would not be an issue in most cooperative settings.Johan also proposes the idea of performing the exit process off-chain, allowing offline users to revert back to the original coinpool output when they come back online. He believes this could work as long as the committed balances and keys remain compatible. The only change needed would be updating the merkle inclusion proofs in the jointly signed transactions. Johan asks Antoine if this functionality aligns with what he was looking for.Antoine's email discusses the use of OP_EVICT in the context of an off-chain payment pool. He expresses concerns about the safety of using OP_EVICT and mentions TLUV or MERKLESUB as possible alternative solutions. Antoine notes that there is currently no sound covenant proposal that combines TLUV and EVICT-like semantics while still allowing for unilateral withdrawal of promised balances. He expresses his interest in finding a better direction to solve the high interactivity issue of channel factory and payment pool.ZmnSCPxj reaches out to Antoine to inquire about the suitability of using "OP_EVICT" for an unknown purpose. The email lacks contextual information but includes a link to a mailing list archive for further reference.The email discusses the issue of interactivity constraints in payment pools and channel factories. It highlights the importance of ensuring the security of user funds and the need for unanimous agreement on updates to off-chain balances. Various proposed solutions are mentioned, including the introduction of a coordinator, partitioning balances, or layering balances among off-chain user subsets. The email also discusses the challenge of mitigating equivocation of off-chain balances and suggests punishing cheating counterparties through an external fidelity bond.The author proposes a solution to prevent off-chain group equivocation by proactively editing the funding utxo of the pool or factory. This approach involves registering new off-chain subgroups as needed and includes the concept of "cut-through" spends to update multiple leaves with a single witness. The email provides an example scenario illustrating how this solution would work in practice. The author believes that such a solution could also reduce the chain space consumed during mass pool withdrawals.Overall, the emails cover various topics related to cryptocurrency systems, including the use of merkle roots, OP_EVICT, alternative solutions, and the interactivity issue in payment pools and channel factories. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2023/combined_Trustless-2-way-peg-without-softfork.xml b/static/bitcoin-dev/Sept_2023/combined_Trustless-2-way-peg-without-softfork.xml index 6294a9e779..b676ed962a 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Trustless-2-way-peg-without-softfork.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Trustless-2-way-peg-without-softfork.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Trustless 2-way-peg without softfork - 2023-09-16T01:53:32.951192+00:00 - - Dr Maxim Orlovsky 2023-09-15 09:31:10+00:00 - - - G. Andrew Stone 2023-09-11 15:26:52+00:00 - - - Dr Maxim Orlovsky 2023-09-10 20:18:20+00:00 - - - Dr Maxim Orlovsky 2023-09-10 20:04:19+00:00 - + 2025-09-26T14:30:07.839815+00:00 + python-feedgen + + + [bitcoin-dev] Trustless 2-way-peg without softfork Dr Maxim Orlovsky + 2023-09-10T20:04:00.000Z + + + Dr Maxim Orlovsky + 2023-09-10T20:18:00.000Z + + + G. Andrew Stone + 2023-09-11T15:26:00.000Z + + + Dr Maxim Orlovsky + 2023-09-15T09:31:00.000Z + + - python-feedgen + 2 Combined summary - Trustless 2-way-peg without softfork - 2023-09-16T01:53:32.951245+00:00 + 2025-09-26T14:30:07.840491+00:00 - The email begins with Maxim mentioning that he received feedback on his proposal and acknowledges the need to work on a simpler paper explaining how the proposed generic model, Prometheus, can be applied to a specific case of two-way peg. He plans to complete this work over the next several weeks and will share it with the mailing list once ready.In response to Andrew's query, he seeks a quick explanation of how a certain protocol works in a permissionless, anonymous, and decentralized manner. Andrew specifically mentions a phrase from the protocol that involves consensus on the correctness of the state reported by an oracle. He wants to understand the functioning of this phrase and any associated caveats.To address Andrew's question, the email provides an overview of the protocol's functioning. It explains that the protocol enables a permissionless and decentralized network, where oracles play a crucial role in providing external data or information. The protocol operates based on a consensus mechanism, where the majority of network participants validate and agree upon the state reported by the oracle, ensuring its correctness.The design of the protocol emphasizes anonymity, allowing participants to engage without revealing their identities. This contributes to the decentralized nature of the network, as individuals can join and participate without explicit permission. While the email doesn't provide specific details about potential limitations or risks associated with the protocol, it mentions that decentralized systems often face challenges such as scalability, security, and reliance on trustworthy oracles.Moving on, the second article discussed in the email focuses on proofs for the Nash equilibrium in the protocol model. The author explains the concept of a protocol game, which represents interactions between multiple agents in a distributed system mathematically. They define the protocol model and its components, including players, strategies, and payoffs. The importance of proving the existence and uniqueness of the Nash equilibrium in ensuring stability and efficiency is emphasized.To prove the existence of the Nash equilibrium, the author introduces the concept of best response dynamics, where players iteratively choose strategies that maximize their payoffs based on the strategies chosen by others. The article explains how this process converges to a Nash equilibrium under certain conditions. Potential games, a special class of games, are discussed as a useful framework for proving the existence and uniqueness of the Nash equilibrium.The email concludes with a discussion on the Prometheus protocol, which allows for high-load computing on top of Bitcoin in a censorship-resistant manner. It operates as a multi-party game with an oracle, referred to as a "worker," performing computationally complex tasks. Consensus is reached on the accuracy of the worker's reported result. The protocol is cryptoeconomically safe, has a proven Nash equilibrium, and can be implemented without soft forks using Bitcoin transactions.The email also mentions that the Prometheus protocol can be used to build a trustless 2-way peg on the Bitcoin blockchain without requiring any soft forks. The worker acts as an oracle for an extra Bitcoin system, such as a sidechain or client-side validated protocol, with consensus ensuring the correctness of the state reported by the oracle. This alternative approach enables the trustless transfer of Bitcoins between the Bitcoin blockchain, RGB, and potentially a new layer 1 called "prime."In summary, the email covers Maxim's plan to work on a simpler paper explaining the application of the Prometheus protocol to a specific case of two-way peg. It provides an explanation of how the protocol functions in a permissionless, anonymous, and decentralized manner, highlighting the role of oracles and consensus. The second article discusses proofs for the Nash equilibrium in the protocol model, explaining concepts such as protocol games, best response dynamics, and potential games. Lastly, it introduces the Prometheus protocol for high-load computing on Bitcoin and its potential use in trustless 2-way pegs without requiring soft forks. 2023-09-15T09:31:10+00:00 + The email begins with Maxim mentioning that he received feedback on his proposal and acknowledges the need to work on a simpler paper explaining how the proposed generic model, Prometheus, can be applied to a specific case of two-way peg. He plans to complete this work over the next several weeks and will share it with the mailing list once ready.In response to Andrew's query, he seeks a quick explanation of how a certain protocol works in a permissionless, anonymous, and decentralized manner. Andrew specifically mentions a phrase from the protocol that involves consensus on the correctness of the state reported by an oracle. He wants to understand the functioning of this phrase and any associated caveats.To address Andrew's question, the email provides an overview of the protocol's functioning. It explains that the protocol enables a permissionless and decentralized network, where oracles play a crucial role in providing external data or information. The protocol operates based on a consensus mechanism, where the majority of network participants validate and agree upon the state reported by the oracle, ensuring its correctness.The design of the protocol emphasizes anonymity, allowing participants to engage without revealing their identities. This contributes to the decentralized nature of the network, as individuals can join and participate without explicit permission. While the email doesn't provide specific details about potential limitations or risks associated with the protocol, it mentions that decentralized systems often face challenges such as scalability, security, and reliance on trustworthy oracles.Moving on, the second article discussed in the email focuses on proofs for the Nash equilibrium in the protocol model. The author explains the concept of a protocol game, which represents interactions between multiple agents in a distributed system mathematically. They define the protocol model and its components, including players, strategies, and payoffs. The importance of proving the existence and uniqueness of the Nash equilibrium in ensuring stability and efficiency is emphasized.To prove the existence of the Nash equilibrium, the author introduces the concept of best response dynamics, where players iteratively choose strategies that maximize their payoffs based on the strategies chosen by others. The article explains how this process converges to a Nash equilibrium under certain conditions. Potential games, a special class of games, are discussed as a useful framework for proving the existence and uniqueness of the Nash equilibrium.The email concludes with a discussion on the Prometheus protocol, which allows for high-load computing on top of Bitcoin in a censorship-resistant manner. It operates as a multi-party game with an oracle, referred to as a "worker," performing computationally complex tasks. Consensus is reached on the accuracy of the worker's reported result. The protocol is cryptoeconomically safe, has a proven Nash equilibrium, and can be implemented without soft forks using Bitcoin transactions.The email also mentions that the Prometheus protocol can be used to build a trustless 2-way peg on the Bitcoin blockchain without requiring any soft forks. The worker acts as an oracle for an extra Bitcoin system, such as a sidechain or client-side validated protocol, with consensus ensuring the correctness of the state reported by the oracle. This alternative approach enables the trustless transfer of Bitcoins between the Bitcoin blockchain, RGB, and potentially a new layer 1 called "prime."In summary, the email covers Maxim's plan to work on a simpler paper explaining the application of the Prometheus protocol to a specific case of two-way peg. It provides an explanation of how the protocol functions in a permissionless, anonymous, and decentralized manner, highlighting the role of oracles and consensus. The second article discusses proofs for the Nash equilibrium in the protocol model, explaining concepts such as protocol games, best response dynamics, and potential games. Lastly, it introduces the Prometheus protocol for high-load computing on Bitcoin and its potential use in trustless 2-way pegs without requiring soft forks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2024/combined_Adding-New-BIP-Editors.xml b/static/bitcoin-dev/Sept_2024/combined_Adding-New-BIP-Editors.xml index 1a37caf149..e79c1228d9 100644 --- a/static/bitcoin-dev/Sept_2024/combined_Adding-New-BIP-Editors.xml +++ b/static/bitcoin-dev/Sept_2024/combined_Adding-New-BIP-Editors.xml @@ -1,308 +1,411 @@ - + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.152793+00:00 - - Murch 2024-12-10 22:37:00+00:00 - - - Mark Erhardt 2024-09-19 18:48:00+00:00 - - - Antoine Riard 2024-09-19 07:47:00+00:00 - - - Mark Erhardt 2024-09-18 18:25:00+00:00 - - - Murch 2024-05-13 18:33:00+00:00 - - - Antoine Riard 2024-04-25 06:42:00+00:00 - - - Anthony Towns 2024-04-23 22:15:00+00:00 - - - Ali Sherief 2024-04-22 04:28:00+00:00 - - - Steve Lee 2024-04-22 02:44:00+00:00 - - - Ava Chow 2024-04-22 00:06:00+00:00 - - - Matt Corallo 2024-04-21 23:01:00+00:00 - - - Antoine Riard 2024-04-21 20:48:00+00:00 - - - Michael Folkson 2024-04-21 19:18:00+00:00 - - - Ava Chow 2024-04-21 18:47:00+00:00 - - - Michael Folkson 2024-04-21 17:57:00+00:00 - - - Ava Chow 2024-04-21 16:39:00+00:00 - - - Michael Folkson 2024-04-21 11:43:00+00:00 - - - Ava Chow 2024-04-20 23:05:00+00:00 - - - Ava Chow 2024-04-20 22:47:00+00:00 - - - Michael Folkson 2024-04-20 22:21:00+00:00 - - - Steve Lee 2024-04-20 22:03:00+00:00 - - - Ava Chow 2024-04-20 21:37:00+00:00 - - - Steve Lee 2024-04-20 21:11:00+00:00 - - - Ava Chow 2024-04-20 21:08:00+00:00 - - - Ava Chow 2024-04-20 20:59:00+00:00 - - - Steve Lee 2024-04-20 20:46:00+00:00 - - - Michael Folkson 2024-04-20 19:59:00+00:00 - - - Ava Chow 2024-04-20 19:48:00+00:00 - - - Ava Chow 2024-04-20 19:14:00+00:00 - - - Olaoluwa Osuntokun 2024-04-19 22:32:00+00:00 - - - nsvrn 2024-04-17 23:58:00+00:00 - - - Ava Chow 2024-04-16 17:08:00+00:00 - - - NVK 2024-04-16 13:32:00+00:00 - - - Tim Ruffing 2024-04-16 12:34:00+00:00 - - - Matt Corallo 2024-04-15 17:50:00+00:00 - - - Sergi Delgado Segura 2024-04-11 14:22:00+00:00 - - - Ali Sherief 2024-04-07 10:11:00+00:00 - - - Larry Ruane 2024-04-05 19:18:00+00:00 - - - xBC 2024-04-04 12:58:00+00:00 - - - Niklas Goegge 2024-04-04 09:09:00+00:00 - - - Anthony Towns 2024-04-04 05:00:00+00:00 - - - Pieter Wuille 2024-04-03 19:44:00+00:00 - - - Fabian 2024-04-03 18:34:00+00:00 - - - Vasil Dimov 2024-04-03 17:24:00+00:00 - - - Juan Galt 2024-04-03 16:58:00+00:00 - - - Murch 2024-04-03 15:03:00+00:00 - - - Luke Dashjr 2024-04-02 15:39:00+00:00 - - - Gloria Zhao 2024-04-02 15:13:00+00:00 - - - Luke Dashjr 2024-04-02 14:28:00+00:00 - - - nvk 2024-04-02 14:24:00+00:00 - - - /dev /fd 2024-04-02 13:49:00+00:00 - - - Tim Ruffing 2024-04-02 13:17:00+00:00 - - - Michael Folkson 2024-04-02 08:18:00+00:00 - - - Ava Chow 2024-04-02 00:37:00+00:00 - - - /dev /fd 2024-04-01 23:55:00+00:00 - - - David A. Harding 2024-04-01 21:13:00+00:00 - - - Antoine Riard 2024-04-01 20:14:00+00:00 - - - Jonas Nick 2024-04-01 18:42:00+00:00 - - - Murch 2024-04-01 18:41:00+00:00 - - - Michael Folkson 2024-04-01 11:58:00+00:00 - - - /dev /fd 2024-04-01 06:21:00+00:00 - - - Ava Chow 2024-03-31 17:01:00+00:00 - - - Michael Folkson 2024-03-31 16:01:00+00:00 - - - Antoine Riard 2024-03-30 20:01:00+00:00 - - - Michael Folkson 2024-03-30 11:51:00+00:00 - - - Peter Todd 2024-03-30 04:04:00+00:00 - - - Keagan McClelland 2024-03-29 22:17:00+00:00 - - - Antoine Riard 2024-03-29 21:08:00+00:00 - - - /dev /fd 2024-03-29 05:24:00+00:00 - - - Michael Folkson 2024-03-29 02:34:00+00:00 - - - Matt Corallo 2024-03-28 21:19:00+00:00 - - - John C. Vernaleo 2024-03-28 20:59:00+00:00 - - - Matt Corallo 2024-03-28 20:31:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Matt Corallo 2024-03-28 20:04:00+00:00 - - - Antoine Riard 2024-03-28 19:42:00+00:00 - - - /dev /fd 2024-03-28 16:09:00+00:00 - - - Brandon Black 2024-03-28 15:50:00+00:00 - - - Murch 2024-03-28 13:02:00+00:00 - - - Matt Corallo 2024-03-27 23:54:00+00:00 - - - John C. Vernaleo 2024-03-27 23:39:00+00:00 - - - Murch 2024-03-27 23:36:00+00:00 - - - Murch 2024-03-27 21:25:00+00:00 - - - Chris Stewart 2024-03-14 11:56:00+00:00 - - - Jon A 2024-03-11 16:48:00+00:00 - - - Bitcoin Error Log 2024-03-10 17:27:00+00:00 - - - Michael Folkson 2024-03-09 10:46:00+00:00 - - - Keagan McClelland 2024-03-07 22:39:00+00:00 - - - Antoine Riard 2024-03-07 20:56:00+00:00 - - - Tim Ruffing 2024-02-28 16:31:00+00:00 - - - bitcoindevml.void 2024-02-28 11:12:00+00:00 - - - /dev /fd 2024-02-28 04:22:00+00:00 - - - Ava Chow 2024-02-27 23:26:00+00:00 - - - /dev /fd 2024-02-27 23:10:00+00:00 - - - Luke Dashjr 2024-02-27 22:57:00+00:00 - - - Luke Dashjr 2024-02-27 22:40:00+00:00 - - - Greg Tonoski 2024-02-27 21:48:00+00:00 - - - Léo Haf 2024-02-27 21:33:00+00:00 - - - Ava Chow 2024-02-27 20:11:00+00:00 - - - Ava Chow 2024-02-27 18:53:00+00:00 - + 2025-09-26T14:19:24.064437+00:00 + python-feedgen + + + Adding New BIP Editors 'Ava Chow' + 2024-02-27T18:53:00.000Z + + + Léo Haf' + 2024-02-27T20:11:00.000Z + + + Antoine Poinsot' + 2024-02-27T21:33:00.000Z + + + Greg Tonoski + 2024-02-27T21:48:00.000Z + + + Luke Dashjr + 2024-02-27T22:40:00.000Z + + + Ava Chow' + 2024-02-27T22:57:00.000Z + + + /dev /fd0 + 2024-02-27T23:10:00.000Z + + + Steve Lee + 2024-02-27T23:26:00.000Z + + + /dev /fd0 + 2024-02-28T04:22:00.000Z + + + bitcoin-dev-ml.void867 + 2024-02-28T11:12:00.000Z + + + Tim Ruffing + 2024-02-28T16:31:00.000Z + + + Antoine Riard + 2024-03-07T20:56:00.000Z + + + Keagan McClelland + 2024-03-07T22:39:00.000Z + + + Michael Folkson + 2024-03-09T10:46:00.000Z + + + Bitcoin Error Log + 2024-03-10T17:27:00.000Z + + + Jon A + 2024-03-11T16:48:00.000Z + + + Chris Stewart + 2024-03-14T11:56:00.000Z + + + Murch + 2024-03-27T21:25:00.000Z + + + Keagan McClelland + 2024-03-27T23:36:00.000Z + + + John C. Vernaleo + 2024-03-27T23:39:00.000Z + + + Matt Corallo + 2024-03-27T23:54:00.000Z + + + Murch + 2024-03-28T13:02:00.000Z + + + Brandon Black + 2024-03-28T15:50:00.000Z + + + /dev /fd0 + 2024-03-28T16:09:00.000Z + + + Antoine Riard + 2024-03-28T19:42:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Matt Corallo + 2024-03-28T20:04:00.000Z + + + Antoine Riard + 2024-03-28T20:31:00.000Z + + + John C. Vernaleo + 2024-03-28T20:59:00.000Z + + + Matt Corallo + 2024-03-28T21:19:00.000Z + + + Michael Folkson + 2024-03-29T02:34:00.000Z + + + /dev /fd0 + 2024-03-29T05:24:00.000Z + + + Antoine Riard + 2024-03-29T21:08:00.000Z + + + Keagan McClelland + 2024-03-29T22:17:00.000Z + + + Peter Todd + 2024-03-30T04:04:00.000Z + + + Michael Folkson + 2024-03-30T11:51:00.000Z + + + Antoine Riard + 2024-03-30T20:01:00.000Z + + + Michael Folkson + 2024-03-31T16:01:00.000Z + + + Ava Chow' + 2024-03-31T17:01:00.000Z + + + /dev /fd0 + 2024-04-01T06:21:00.000Z + + + Michael Folkson + 2024-04-01T11:58:00.000Z + + + Re: Adding New BIP Editors Murch + 2024-04-01T18:41:00.000Z + + + Jonas Nick + 2024-04-01T18:42:00.000Z + + + Antoine Riard + 2024-04-01T20:14:00.000Z + + + David A. Harding + 2024-04-01T21:13:00.000Z + + + /dev /fd0 + 2024-04-01T23:55:00.000Z + + + Ava Chow' + 2024-04-02T00:37:00.000Z + + + Michael Folkson + 2024-04-02T08:18:00.000Z + + + Time for an update to BIP2? Tim Ruffing + 2024-04-02T13:17:00.000Z + + + /dev /fd0 + 2024-04-02T13:49:00.000Z + + + nvk + 2024-04-02T14:24:00.000Z + + + Luke Dashjr + 2024-04-02T14:28:00.000Z + + + Gloria Zhao + 2024-04-02T15:13:00.000Z + + + Luke Dashjr + 2024-04-02T15:39:00.000Z + + + Murch + 2024-04-03T15:03:00.000Z + + + Juan Galt + 2024-04-03T16:58:00.000Z + + + Vasil Dimov + 2024-04-03T17:24:00.000Z + + + Fabian' + 2024-04-03T18:34:00.000Z + + + Pieter Wuille + 2024-04-03T19:44:00.000Z + + + Anthony Towns + 2024-04-04T05:00:00.000Z + + + Niklas Goegge + 2024-04-04T09:09:00.000Z + + + Adding New BIP Editors 0xB10C + 2024-04-04T12:58:00.000Z + + + Larry Ruane + 2024-04-05T19:18:00.000Z + + + Ali Sherief + 2024-04-07T10:11:00.000Z + + + Sergi Delgado Segura + 2024-04-11T14:22:00.000Z + + + Matt Corallo + 2024-04-15T17:50:00.000Z + + + Tim Ruffing + 2024-04-16T12:34:00.000Z + + + NVK + 2024-04-16T13:32:00.000Z + + + Ava Chow' + 2024-04-16T17:08:00.000Z + + + nsvrn' + 2024-04-17T23:58:00.000Z + + + Olaoluwa Osuntokun + 2024-04-19T22:32:00.000Z + + + Ava Chow' + 2024-04-20T19:14:00.000Z + + + NVK + 2024-04-20T19:48:00.000Z + + + Michael Folkson + 2024-04-20T19:59:00.000Z + + + Steve Lee + 2024-04-20T20:46:00.000Z + + + Ava Chow' + 2024-04-20T20:59:00.000Z + + + Ava Chow' + 2024-04-20T21:08:00.000Z + + + Steve Lee + 2024-04-20T21:11:00.000Z + + + Ava Chow' + 2024-04-20T21:37:00.000Z + + + Steve Lee + 2024-04-20T22:03:00.000Z + + + Michael Folkson + 2024-04-20T22:21:00.000Z + + + Ava Chow' + 2024-04-20T22:47:00.000Z + + + Ava Chow' + 2024-04-20T23:05:00.000Z + + + Michael Folkson + 2024-04-21T11:43:00.000Z + + + Ava Chow' + 2024-04-21T16:39:00.000Z + + + Michael Folkson + 2024-04-21T17:57:00.000Z + + + Ava Chow' + 2024-04-21T18:47:00.000Z + + + Michael Folkson + 2024-04-21T19:18:00.000Z + + + Antoine Riard + 2024-04-21T20:48:00.000Z + + + Matt Corallo + 2024-04-21T23:01:00.000Z + + + Ava Chow' + 2024-04-22T00:06:00.000Z + + + Steve Lee + 2024-04-22T02:44:00.000Z + + + Ali Sherief + 2024-04-22T04:28:00.000Z + + + Anthony Towns + 2024-04-23T22:15:00.000Z + + + Antoine Riard + 2024-04-25T06:42:00.000Z + + + Time for an update to BIP2? Murch + 2024-05-13T18:33:00.000Z + + + Murch + 2024-09-18T18:25:00.000Z + + + Antoine Riard + 2024-09-19T07:47:00.000Z + + + Murch + 2024-09-19T18:48:00.000Z + + + Murch + 2024-12-10T22:37:00.000Z + + @@ -403,21 +506,17 @@ - python-feedgen + 2 Combined summary - Adding New BIP Editors - 2024-12-11T02:42:37.153617+00:00 + 2025-09-26T14:19:24.073749+00:00 + 2024-12-10T22:37:00+00:00 In the realm of Bitcoin development, discussions pertaining to the enhancement of the Bitcoin Improvement Proposal (BIP) process have been prominent. A key focus has been on addressing the current bottleneck in managing BIPs, emphasized by Luke Dashjr's acknowledgment of his limited capacity to actively maintain the BIPs repository. This acknowledgment underscores the critical need for additional BIP editors to ensure an efficient and effective review and integration process for new proposals and amendments to existing ones. - The role of a BIP editor is significant, encompassing responsibilities such as assigning BIP numbers, merging pull requests for new proposals, making fixes to existing BIPs, and more, as outlined in BIP 2. The addition of new editors is envisaged as a pivotal measure to alleviate the backlog of submissions and augment the process's overall productivity. For the continuity and coherence of the BIP numbering system, it is imperative that any incoming editors concur on the established numbering scheme. - The selection criteria for new BIP editors highlight the necessity for candidates with a comprehensive background in Bitcoin development, showcasing a history of active participation and contributions. These individuals must possess the ability to impartially assess proposals, a quality that underscores the importance of objectivity in the role. - Within this context, Kanzure and RubenSomsen have been identified as exemplary candidates for the position of BIP editors. Their extensive involvement in Bitcoin development positions them as valuable additions to the editorial team. Their potential inclusion is anticipated to significantly ameliorate the management and advancement of the BIPs repository, offering substantial benefits to the Bitcoin development community. - This dialogue illustrates the collective effort within the Bitcoin developer ecosystem to refine the governance mechanisms surrounding BIPs. It emphasizes the commitment to ensuring that the process remains robust, transparent, and inclusive, facilitating the continuous evolution and improvement of Bitcoin. - 2024-12-10T22:37:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml b/static/bitcoin-dev/Sept_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml index ef68b02a43..8d99903507 100644 --- a/static/bitcoin-dev/Sept_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml +++ b/static/bitcoin-dev/Sept_2024/combined_Demonstrating-Pinning-Attacks-under-Real-World-Conditions.xml @@ -1,47 +1,52 @@ - + 2 Combined summary - Demonstrating Pinning Attacks under Real-World Conditions - 2024-10-13T02:26:41.059288+00:00 - - Antoine Riard 2024-10-12 04:46:00+00:00 - - - waxwing/ AdamISZ 2024-10-11 15:01:00+00:00 - - - Antoine Riard 2024-10-11 00:21:00+00:00 - - - Antoine Riard 2024-09-03 20:12:00+00:00 - - - Peter Todd 2024-09-03 12:58:00+00:00 - - - Antoine Riard 2024-08-27 21:10:00+00:00 - + 2025-09-26T14:19:11.120074+00:00 + python-feedgen + + + Demonstrating Pinning Attacks under Real-World Conditions Antoine Riard + 2024-08-27T21:10:00.000Z + + + Peter Todd + 2024-09-03T12:58:00.000Z + + + Antoine Riard + 2024-09-03T20:12:00.000Z + + + Antoine Riard + 2024-10-11T00:21:00.000Z + + + waxwing/ AdamISZ + 2024-10-11T15:01:00.000Z + + + Antoine Riard + 2024-10-12T04:46:00.000Z + + - python-feedgen + 2 Combined summary - Demonstrating Pinning Attacks under Real-World Conditions - 2024-10-13T02:26:41.059346+00:00 + 2025-09-26T14:19:11.120967+00:00 + 2024-10-12T04:46:00+00:00 The conversation starts with the recognition of a need for clear, step-by-step instructions for volunteers interested in setting up new nodes, focusing on the use of current and default installations of Core/btcd along with lnd/cln/ldk. It delves into specifics such as the amount required in channels, the necessary number of channels, the relevance of channel types, volunteer interconnectivity, desired network topology, and the significance of network connectivity and Tor usage. This discussion illuminates the technical intricacies involved in setting up these nodes and underscores the importance of detailed guidance for volunteers with varying expertise levels. - The topic shifts to the exploration of real-world pinning attacks against production lightning nodes and the broader context of security vulnerabilities within the bitcoin network. The reluctance of developers to engage in real-world demonstrations of these exploits is highlighted, alongside the optimism for improved evaluations and reproductions of bitcoin security exploits. Drawing parallels with major information security conferences, there's an anticipation that increased scrutiny of security flaws will bolster the bitcoin ecosystem's resilience. This part of the discussion emphasizes the critical focus on security vulnerabilities and the proactive measures needed to safeguard blockchain technologies. - Antoine Riard discusses his personal commitment to testing without affecting CPU or RAM functionalities, focusing instead on transaction-relay and mempool logic. He proposes running a node on the mainnet to exploit channels for liquidity rebalancing, committing his own liquidity for this purpose. Additionally, Riard mentions a $100 donation to the OTS project, highlighting his support for its notarization services. His approach to handling transactions cautiously to avoid penalties reflects a nuanced understanding of the risks involved. - Furthermore, Riard has authorized attack tests on his Lightning node, part of the Alice OpenTimestamps calendar, until October 1st, emphasizing operational constraints due to the server's role in a production environment. Despite potential disruptions, the impact is considered minimal thanks to the redundancy of the OpenTimestamps protocol. This section outlines the conditions under which the testing should proceed, including reimbursement for any incurred expenses and encouragement for testers to make donations to the OTS community. - -Lastly, the email touches on Dave Harding's suggestion to establish "free-to-pwn" lightning nodes on the mainnet for conducting sophisticated cross-layer attacks like pinning. This initiative aims to bridge the gap between private testing and public verifiability, highlighting the differences in conducting attacks in testnets versus the mainnet. Antoine addresses the potential criticisms regarding the complexity of full-node software and lightning implementations, advocating for transparency and public demonstrations to uncover vulnerabilities, thereby fostering a more secure and trustworthy bitcoin ecosystem. - 2024-10-12T04:46:00+00:00 +Lastly, the email touches on Dave Harding's suggestion to establish "free-to-pwn" lightning nodes on the mainnet for conducting sophisticated cross-layer attacks like pinning. This initiative aims to bridge the gap between private testing and public verifiability, highlighting the differences in conducting attacks in testnets versus the mainnet. Antoine addresses the potential criticisms regarding the complexity of full-node software and lightning implementations, advocating for transparency and public demonstrations to uncover vulnerabilities, thereby fostering a more secure and trustworthy bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2024/combined_OP-CAT-Research-Fund-sponsored-by-StarkWare.xml b/static/bitcoin-dev/Sept_2024/combined_OP-CAT-Research-Fund-sponsored-by-StarkWare.xml index f492ce05b6..16943ad220 100644 --- a/static/bitcoin-dev/Sept_2024/combined_OP-CAT-Research-Fund-sponsored-by-StarkWare.xml +++ b/static/bitcoin-dev/Sept_2024/combined_OP-CAT-Research-Fund-sponsored-by-StarkWare.xml @@ -1,43 +1,47 @@ - + 2 Combined summary - OP_CAT Research Fund sponsored by StarkWare - 2024-09-03T02:14:48.897337+00:00 - - Antoine Riard 2024-09-03 00:35:00+00:00 - - - /dev /fd 2024-08-29 16:08:00+00:00 - - - Matt Corallo 2024-08-29 14:08:00+00:00 - - - Victor Kolobov 2024-08-29 13:43:00+00:00 - - - Victor Kolobov 2024-08-29 13:18:00+00:00 - + 2025-09-26T14:19:08.991759+00:00 + python-feedgen + + + OP_CAT Research Fund sponsored by StarkWare 'Victor Kolobov' + 2024-08-29T13:18:00.000Z + + + Greg Tonoski + 2024-08-29T13:43:00.000Z + + + Matt Corallo + 2024-08-29T14:08:00.000Z + + + /dev /fd0 + 2024-08-29T16:08:00.000Z + + + Antoine Riard + 2024-09-03T00:35:00.000Z + + - python-feedgen + 2 Combined summary - OP_CAT Research Fund sponsored by StarkWare - 2024-09-03T02:14:48.897425+00:00 + 2025-09-26T14:19:08.992527+00:00 + 2024-09-03T00:35:00+00:00 The discussion encompasses a variety of topics related to Bitcoin development, particularly focusing on the post-Taproot activation landscape and the exploration of covenants or contracting primitives extending Bitcoin script. It reflects on the historical stalemate in consensus discussions since Taproot's activation in 2021, suggesting that a lack of trial-and-error design and development processes akin to those used for Schnorr/Taproot changes has hindered progress. The narrative recalls the Taproot design and development process, including debates over technical ideas, the proposal and review process, and the implementation and discussion phases leading up to its activation. - The discourse also touches upon subsequent initiatives aimed at improving Bitcoin's scripting capabilities, highlighting Jeremy's CTV proposal as a notable attempt despite its failure to gather enough support for activation. The author mentions organizing IRC meetings to facilitate open discussions among covenant developers, aiming to identify areas of agreement and divergence within the community. However, challenges such as the discontinuation of certain working groups and the lack of active participation in proposed forks like the bitcoin-inquisition are noted, pointing to a broader issue of engaging skilled contributors beyond financial incentives. - Moreover, the conversation extends to the broader Bitcoin ecosystem's communication dynamics, criticizing the dominance of FOSS veterans and the limitations of invitation-only developer meetings. It advocates for leveraging bounties to foster more open and public processes, including IRC meetings and conferences, to nurture a high-quality dialogue about Bitcoin's technical development. The author warns against repeating past mistakes, such as the blocksize war, by failing to maintain an open and public space for intellectual discussion, especially given the increasing attention from nation-states and political actors. - Additionally, there's mention of StarkWare's initiative offering a $1 million bounty for arguments regarding the activation of OP_CAT, aiming to stimulate a comprehensive community debate on its implications for Bitcoin. This includes concerns over security, potential applications, and the overall impact on the Bitcoin ecosystem. The committee overseeing this initiative is composed of prominent figures from various organizations, emphasizing the importance of community contributions to the ongoing discourse around OP_CAT's role in Bitcoin's future development. - In parallel, advancements in blockchain technology are highlighted, including projects aimed at enhancing interoperability, streamlining cryptographic procedures within Bitcoin, and exploring decentralized finance (DeFi) mechanisms like Automated Market Makers (AMM). The discussion points to specific efforts in developing on-chain decentralized exchanges (DEX) and reducing transaction confirmation times, illustrating the wide-ranging research and development activities underway within the blockchain space. - 2024-09-03T00:35:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2024/combined_OP-KEEPCHANGE-mitigating-dust-outputs.xml b/static/bitcoin-dev/Sept_2024/combined_OP-KEEPCHANGE-mitigating-dust-outputs.xml index 58b11fa53e..fd7a5f7f70 100644 --- a/static/bitcoin-dev/Sept_2024/combined_OP-KEEPCHANGE-mitigating-dust-outputs.xml +++ b/static/bitcoin-dev/Sept_2024/combined_OP-KEEPCHANGE-mitigating-dust-outputs.xml @@ -1,35 +1,40 @@ - + 2 Combined summary - OP_KEEPCHANGE - mitigating dust outputs - 2024-09-29T02:27:11.491655+00:00 - - Keagan McClelland 2024-09-28 02:28:00+00:00 - - - James Ferguson 2024-09-26 09:05:00+00:00 - - - Pieter Wuille 2024-09-26 01:22:00+00:00 - - - James Ferguson 2024-09-26 00:44:00+00:00 - + 2025-09-26T14:19:15.348518+00:00 + python-feedgen + + + OP_KEEPCHANGE - mitigating dust outputs James Ferguson + 2024-09-26T00:44:00.000Z + + + Pieter Wuille + 2024-09-26T01:22:00.000Z + + + James Ferguson + 2024-09-26T09:05:00.000Z + + + Keagan McClelland + 2024-09-28T02:28:00.000Z + + - python-feedgen + 2 Combined summary - OP_KEEPCHANGE - mitigating dust outputs - 2024-09-29T02:27:11.491726+00:00 + 2025-09-26T14:19:15.349230+00:00 - In the realm of cryptocurrency, particularly Bitcoin, managing small, unspendable residual amounts known as dust is a challenge that impacts network efficiency, transaction fees, and privacy. The proposal titled "Keep the Change," which introduces the concept of "OP_KEEPCHANGE," aims to address these issues by crediting small residual Unspent Transaction Outputs (UTXOs) to the primary recipient’s address instead of generating new change outputs. This innovative approach is expected to mitigate inefficiencies associated with dust outputs by reducing blockchain bloat and simplifying transaction construction. By doing so, it also enhances privacy by making it more difficult to identify change outputs and preserves the overall Bitcoin money supply by preventing the accumulation of economically unspendable UTXOs. - -The mechanism behind "OP_KEEPCHANGE" involves configuring a dust threshold and selecting inputs for transactions in such a way that minimizes the creation of change, thereby fostering a more equitable system. Transactions falling below this threshold would be marked with "OP_KEEPCHANGE," allowing any excess change to be added to the primary output. This method not only promises backward compatibility with existing systems but also aims at improving Bitcoin network efficiency, lowering transaction costs, enhancing privacy, and maintaining a stable money supply. Secondary benefits include preventing value erosion when transferring funds between wallets owned by the same entity and providing a slight revenue uplift for recipients such as merchants or fiat exchange users without imposing additional costs on the sender. - -Bitcoin operates based on a unique model that relies heavily on Unspent Transaction Outputs (UTXOs) rather than conventional account balances. This methodology, which fundamentally differs from traditional financial systems, calculates an address's balance by summing the values of UTXOs that can be spent by the address in question. Proposals aiming to credit an address directly face significant challenges due to Bitcoin's foundational design, which is built to enhance privacy and operational efficiency. The current model intentionally obscures whether outputs are payments to recipients or change being returned to the sender, thus providing a significant privacy advantage. Adapting Bitcoin to a direct balance model would require a complete overhaul of the protocol and could potentially undermine the privacy benefits inherent in the UTXO model. As such, while addressing inefficiencies like dust accumulation is crucial, any modifications must carefully consider the fundamental principles and trade-offs embedded within the Bitcoin protocol. 2024-09-28T02:28:00+00:00 + In the realm of cryptocurrency, particularly Bitcoin, managing small, unspendable residual amounts known as dust is a challenge that impacts network efficiency, transaction fees, and privacy. The proposal titled "Keep the Change," which introduces the concept of "OP_KEEPCHANGE," aims to address these issues by crediting small residual Unspent Transaction Outputs (UTXOs) to the primary recipient’s address instead of generating new change outputs. This innovative approach is expected to mitigate inefficiencies associated with dust outputs by reducing blockchain bloat and simplifying transaction construction. By doing so, it also enhances privacy by making it more difficult to identify change outputs and preserves the overall Bitcoin money supply by preventing the accumulation of economically unspendable UTXOs. +The mechanism behind "OP_KEEPCHANGE" involves configuring a dust threshold and selecting inputs for transactions in such a way that minimizes the creation of change, thereby fostering a more equitable system. Transactions falling below this threshold would be marked with "OP_KEEPCHANGE," allowing any excess change to be added to the primary output. This method not only promises backward compatibility with existing systems but also aims at improving Bitcoin network efficiency, lowering transaction costs, enhancing privacy, and maintaining a stable money supply. Secondary benefits include preventing value erosion when transferring funds between wallets owned by the same entity and providing a slight revenue uplift for recipients such as merchants or fiat exchange users without imposing additional costs on the sender. +Bitcoin operates based on a unique model that relies heavily on Unspent Transaction Outputs (UTXOs) rather than conventional account balances. This methodology, which fundamentally differs from traditional financial systems, calculates an address's balance by summing the values of UTXOs that can be spent by the address in question. Proposals aiming to credit an address directly face significant challenges due to Bitcoin's foundational design, which is built to enhance privacy and operational efficiency. The current model intentionally obscures whether outputs are payments to recipients or change being returned to the sender, thus providing a significant privacy advantage. Adapting Bitcoin to a direct balance model would require a complete overhaul of the protocol and could potentially undermine the privacy benefits inherent in the UTXO model. As such, while addressing inefficiencies like dust accumulation is crucial, any modifications must carefully consider the fundamental principles and trade-offs embedded within the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2024/combined_Proposal-to-upgrade-the-transaction-relay-protocol-to-a-new-version.xml b/static/bitcoin-dev/Sept_2024/combined_Proposal-to-upgrade-the-transaction-relay-protocol-to-a-new-version.xml index c3a5336c54..31e340d80e 100644 --- a/static/bitcoin-dev/Sept_2024/combined_Proposal-to-upgrade-the-transaction-relay-protocol-to-a-new-version.xml +++ b/static/bitcoin-dev/Sept_2024/combined_Proposal-to-upgrade-the-transaction-relay-protocol-to-a-new-version.xml @@ -1,33 +1,36 @@ - + 2 Combined summary - Proposal to upgrade the transaction relay protocol to a new version - 2024-09-07T02:18:21.642738+00:00 - - Antoine Riard 2024-09-06 19:52:00+00:00 - - - Peter Todd 2024-09-06 10:49:00+00:00 - - - Antoine Riard 2024-09-05 22:49:00+00:00 - + 2025-09-26T14:19:17.462822+00:00 + python-feedgen + + + Proposal to upgrade the transaction relay protocol to a new version Antoine Riard + 2024-09-05T22:49:00.000Z + + + Peter Todd + 2024-09-06T10:49:00.000Z + + + Antoine Riard + 2024-09-06T19:52:00.000Z + + - python-feedgen + 2 Combined summary - Proposal to upgrade the transaction relay protocol to a new version - 2024-09-07T02:18:21.642791+00:00 + 2025-09-26T14:19:17.463383+00:00 + 2024-09-06T19:52:00+00:00 Antoine Riard has proposed a significant update to the Bitcoin transaction relay protocol. This proposal, aimed at introducing a new node service bit, is designed to refine how transactions are broadcast within the Bitcoin network. The draft of this proposal has been submitted and is accessible for review on [GitHub](https://github.com/bitcoin/bips/pull/1663) and [GitHub](https://github.com/bitcoin/bips/pull/1664). The motivation behind this initiative stems from discussions in the community that highlighted a need for improvements in transaction propagation methods. These discussions, archived in a [Linux Foundation's mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018391.html), provide a backdrop to the current efforts to enhance the Bitcoin infrastructure. - Riard’s proposal does not anticipate immediate changes for non-upgraded wallets as they will continue to process unannounced transaction messages in the same manner with upgraded peers. The proposal also considers the potential future direction where a few inbound slots might always be reserved for non-upgraded peers, following insights from bitcoinj – a foundational library in the Bitcoin ecosystem used for building wallets. This consideration reflects upon the importance of maintaining inclusivity within the network, ensuring that transactions can still be processed seamlessly without mandatory upgrades. - Moreover, there's an ongoing discussion regarding the intricacies involved in transaction message relays, particularly focusing on the reliability of transaction delivery similar to TCP’s guarantees. Splitting the Bitcoin Improvement Proposal (BIP) into two separate proposals – one for the signaling mechanism and another for the transaction message processing mechanism – is suggested to adhere to the UNIX philosophy about modularity. This division aims to clarify and streamline the upgrade process. - Furthermore, concerns were raised about the potential impact of discontinuing unannounced transaction messages on wallet user experience (UX). Specifically, the delay in transaction broadcasts could complicate the implementation of wallets with optimal UX. Addressing these concerns is crucial for understanding how clients utilizing unannounced transaction messages aim to achieve their goals post-update. This aspect underscores the need for a comprehensive discussion around the implications of the proposed changes on various stakeholders within the Bitcoin ecosystem. - 2024-09-06T19:52:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml b/static/bitcoin-dev/Sept_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml index 74bdc74a4c..3f32ffad3c 100644 --- a/static/bitcoin-dev/Sept_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml +++ b/static/bitcoin-dev/Sept_2024/combined_Proposing-a-P2QRH-BIP-towards-a-quantum-resistant-soft-fork.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Proposing a P2QRH BIP towards a quantum resistant soft fork - 2024-09-26T03:18:36.202311+00:00 - - Hunter Beast 2024-09-25 12:04:00+00:00 - - - Antoine Riard 2024-08-22 06:20:00+00:00 - - - Hunter Beast 2024-08-15 05:05:00+00:00 - - - Hunter Beast 2024-08-06 17:37:00+00:00 - - - Antoine Riard 2024-07-13 01:34:00+00:00 - - - hunter 2024-06-17 20:27:00+00:00 - - - Antoine Riard 2024-06-17 01:07:00+00:00 - - - Hunter Beast 2024-06-14 14:28:00+00:00 - - - PierreLuc DallaireDemers 2024-06-14 13:51:00+00:00 - - - Hunter Beast 2024-06-08 21:04:00+00:00 - + 2025-09-26T14:19:19.646171+00:00 + python-feedgen + + + Proposing a P2QRH BIP towards a quantum resistant soft fork Hunter Beast + 2024-06-08T21:04:00.000Z + + + Pierre-Luc Dallaire-Demers + 2024-06-14T13:51:00.000Z + + + Hunter Beast + 2024-06-14T14:28:00.000Z + + + Antoine Riard + 2024-06-17T01:07:00.000Z + + + hunter + 2024-06-17T20:27:00.000Z + + + Antoine Riard + 2024-07-13T01:34:00.000Z + + + Hunter Beast + 2024-08-06T17:37:00.000Z + + + Hunter Beast + 2024-08-15T05:05:00.000Z + + + Antoine Riard + 2024-08-22T06:20:00.000Z + + + Hunter Beast + 2024-09-25T12:04:00.000Z + + @@ -43,21 +56,17 @@ - python-feedgen + 2 Combined summary - Proposing a P2QRH BIP towards a quantum resistant soft fork - 2024-09-26T03:18:36.202392+00:00 + 2025-09-26T14:19:19.647315+00:00 + 2024-09-25T12:04:00+00:00 The recent discussions and updates surrounding the development of a Bitcoin Improvement Proposal (BIP) to introduce quantum resistance into Bitcoin's cryptographic framework underscore the community's proactive approach towards safeguarding the cryptocurrency against potential quantum computing threats. Central to these discussions is the acknowledgment of IBM's advancements in quantum computing, particularly with its Quantum System Two, which potentially supports up to 16,000 qubits. This advancement hints at a future where quantum computing could significantly impact cryptographic security, necessitating the exploration of post-quantum cryptographic algorithms. - The discourse extends beyond merely recognizing the threat, delving into specific cryptographic considerations and solutions. For example, the integration of FALCON, a post-quantum signature algorithm, into the proposed BIP reflects a thoughtful response to the nuanced challenges posed by quantum computing. This choice is indicative of the community's effort to balance security needs with practical implementation concerns such as signature size and transaction costs. The dialogue also touches on broader strategic issues, including the potential for increased witness discounts to accommodate larger transactions, underscoring the ongoing effort to maintain Bitcoin's scalability and security in tandem. - Moreover, the discussions reveal an awareness of the limitations and uncertainties inherent in predicting quantum computing's progression. References to IBM's roadmap and the need for cautious optimism highlight the complex interplay between technological advancement and cryptographic security. The conversation acknowledges the diversity of quantum computing architectures and their implications for cryptographic attacks, emphasizing the importance of a robust, adaptable approach to security. - Significantly, the proposal outlines defensive measures that Bitcoin users can implement today, such as configuring spending scripts to require artificially inflated witness stacks. This strategy exemplifies the multifaceted approach needed to address quantum threats, combining immediate practical measures with long-term cryptographic evolution. The suggestion to use trusted mining pools for transaction submission further illustrates the community's willingness to explore diverse strategies to mitigate risk. - In summary, the ongoing dialogue around introducing quantum resistance to Bitcoin through a dedicated BIP reflects a comprehensive and forward-looking approach to cryptocurrency security. It underscores the community's commitment to addressing emerging threats through research, collaboration, and innovation. The inclusion of FALCON signatures and the consideration of various post-quantum cryptographic schemes highlight the technical complexity of this endeavor, while discussions about implementation strategies and the potential impact on transaction throughput reveal the broader strategic considerations at play. As the landscape of quantum computing continues to evolve, the Bitcoin community's proactive engagement with these challenges will be crucial in ensuring the cryptocurrency's resilience and longevity. - 2024-09-25T12:04:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2024/combined_Public-disclosure-of-1-vulnerability-affecting-Bitcoin-Core-24-0-1.xml b/static/bitcoin-dev/Sept_2024/combined_Public-disclosure-of-1-vulnerability-affecting-Bitcoin-Core-24-0-1.xml index f1c34c42bc..e3eff4bf95 100644 --- a/static/bitcoin-dev/Sept_2024/combined_Public-disclosure-of-1-vulnerability-affecting-Bitcoin-Core-24-0-1.xml +++ b/static/bitcoin-dev/Sept_2024/combined_Public-disclosure-of-1-vulnerability-affecting-Bitcoin-Core-24-0-1.xml @@ -1,25 +1,29 @@ - + 2 Combined summary - Public disclosure of 1 vulnerability affecting Bitcoin Core <24.0.1 - 2024-09-20T02:23:36.698146+00:00 - - Antoine Riard 2024-09-19 08:12:00+00:00 - - - Antoine Poinsot 2024-09-19 05:15:00+00:00 - + 2025-09-26T14:19:21.769746+00:00 + python-feedgen + + + Public disclosure of 1 vulnerability affecting Bitcoin Core <24.0.1 'Antoine Poinsot' + 2024-09-19T05:15:00.000Z + + + Antoine Riard + 2024-09-19T08:12:00.000Z + + - python-feedgen + 2 Combined summary - Public disclosure of 1 vulnerability affecting Bitcoin Core <24.0.1 - 2024-09-20T02:23:36.698195+00:00 + 2025-09-26T14:19:21.770212+00:00 + 2024-09-19T08:12:00+00:00 Antoine Poinsot has highlighted a pivotal update concerning Bitcoin Core, specifically addressing the misconception that checkpoints are no longer utilized as a defense mechanism against known attacks. This clarification comes in the wake of discussions sparked by the report produced by Darosior, which led to the reevaluation of the role of checkpoints within the Bitcoin Core infrastructure. The referenced GitHub pull request ([link](https://github.com/bitcoin/bitcoin/pull/25725)) serves to correct misunderstandings and confirms that, as of commit ab0b5706b, checkpoints remain a critical component of the system's security measures. - In addition to this, there has been an announcement regarding the exposure of a vulnerability detailed on the official Bitcoin Core website ([link](https://bitcoincore.org/en/2024/09/18/disclose-headers-oom)). This announcement is part of a broader strategy to embrace a new vulnerability disclosure policy, details of which can be found at [link](https://bitcoincore.org/en/security-advisories/policy). The significance of this development lies in its timing and the commitment to transparency and security it represents for the Bitcoin Core project. Furthermore, there is an anticipation of disclosing additional vulnerabilities next month that affect versions of Bitcoin Core prior to version 25.0, highlighting an ongoing effort to fortify security measures surrounding the software. - 2024-09-19T08:12:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2024/combined_Shielded-CSV-Private-and-Efficient-Client-Side-Validation.xml b/static/bitcoin-dev/Sept_2024/combined_Shielded-CSV-Private-and-Efficient-Client-Side-Validation.xml index 68cefd031d..6ffb8adb9b 100644 --- a/static/bitcoin-dev/Sept_2024/combined_Shielded-CSV-Private-and-Efficient-Client-Side-Validation.xml +++ b/static/bitcoin-dev/Sept_2024/combined_Shielded-CSV-Private-and-Efficient-Client-Side-Validation.xml @@ -1,39 +1,42 @@ - + 2 Combined summary - Shielded CSV: Private and Efficient Client-Side Validation - 2024-09-27T02:25:31.464595+00:00 - - Weikeng Chen 2024-09-26 15:02:00+00:00 - - - Jonas Nick 2024-09-26 14:34:00+00:00 - - - Antoine Riard 2024-09-25 12:23:00+00:00 - - - Jonas Nick 2024-09-24 13:24:00+00:00 - + 2025-09-26T14:19:13.234822+00:00 + python-feedgen + + + Shielded CSV: Private and Efficient Client-Side Validation Jonas Nick + 2024-09-24T13:24:00.000Z + + + Antoine Riard + 2024-09-25T12:23:00.000Z + + + Jonas Nick + 2024-09-26T14:34:00.000Z + + + Weikeng Chen + 2024-09-26T15:02:00.000Z + + - python-feedgen + 2 Combined summary - Shielded CSV: Private and Efficient Client-Side Validation - 2024-09-27T02:25:31.464644+00:00 + 2025-09-26T14:19:13.235492+00:00 + 2024-09-26T15:02:00+00:00 The discussion revolves around several key challenges and innovations in the realm of blockchain technology, with a particular focus on privacy, scalability, and efficiency. One significant challenge highlighted is the process of bridging within blockchain protocols, which is crucial for enhancing Bitcoin's capabilities, including the introduction of strong privacy measures. The potential integration of BitVM and upgrades like a full-fledged SNARK verification opcode are suggested as solutions to swiftly deploy the protocol on Bitcoin, thereby broadening its utility. - -A detailed analysis into the workings of Shielded Client-Side Validation (CSV) nodes reveals their necessity to access and scan the entire blockchain for 64-byte nullifiers, which are then verified and stored in a structure known as a "nullifier accumulator". This process underscores both the bandwidth demands placed on participants and the potential for a lighter client scheme. Such a scheme would not require direct block validation but rather rely on proof-of-work to infer blockchain validity and obtain nullifier accumulator values, thus facilitating transaction receiving. However, creating transactions would necessitate knowledge of nullifiers, pointing to areas ripe for further exploration and innovation. - +A detailed analysis into the workings of Shielded Client-Side Validation (CSV) nodes reveals their necessity to access and scan the entire blockchain for 64-byte nullifiers, which are then verified and stored in a structure known as a "nullifier accumulator". This process underscores both the bandwidth demands placed on participants and the potential for a lighter client scheme. Such a scheme would not require direct block validation but rather rely on proof-of-work to infer blockchain validity and obtain nullifier accumulator values, thus facilitating transaction receiving. However, creating transactions would necessitate knowledge of nullifiers, pointing to areas ripe for further exploration and innovation. Within this technological landscape, privacy concerns emerge, particularly regarding the visibility of coin creation times, which could inadvertently facilitate transaction linkability. Suggestions to address these concerns include limiting wallets to create single outputs and modifying the protocol to support prunable wallet states without compromising privacy by revealing only the block in which a coin was created, rather than precise nullifier information. - The Shielded CSV whitepaper introduces an advanced approach to client-side validation that emphasizes privacy and efficiency in cryptocurrency transactions. By employing Proof-Carrying Data abstraction, possibly through recursive zkSNARKs or folding schemes, Shielded CSV aims to conceal the transaction graph while ensuring the transaction verification time remains unaffected by the history. This method greatly reduces the blockchain data footprint by requiring only minimal data posting, showcasing a significant departure from traditional Bitcoin transactions. The paper presents a Rust-based pseudocode implementation, highlighting the practicality and potential for further development within this domain. - Client-Side Validation (CSV) is posited as a solution to the inherent trade-offs between privacy and scalability faced by cryptocurrencies. By relocating transaction validation away from the consensus mechanism, CSV significantly reduces the resources needed for transaction processing, thus addressing scalability issues. Shielded CSV, in particular, promises enhanced privacy and scalability by minimizing the blockchain data written and simplifying the verification process, potentially supporting a substantially higher transaction rate on platforms like Bitcoin. The technical foundation and future extensions of Shielded CSV are thoroughly explored, indicating a robust framework for ongoing and future enhancements in blockchain privacy and efficiency. Interested readers can delve into the specifics by accessing the whitepaper [here](https://github.com/ShieldedCSV/ShieldedCSV/releases/latest/download/shieldedcsv.pdf). - 2024-09-26T15:02:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Add-BIP-0093-Codex32-as-application-to-BIP-0085.xml b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Add-BIP-0093-Codex32-as-application-to-BIP-0085.xml index 8ebc6ddb0b..b7de0c77a1 100644 --- a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Add-BIP-0093-Codex32-as-application-to-BIP-0085.xml +++ b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Add-BIP-0093-Codex32-as-application-to-BIP-0085.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - [BIP Proposal] Add BIP-0093 (Codex32) as application to BIP-0085 - 2025-09-09T02:31:28.716754+00:00 - - Aneesh Karve 2025-09-07 23:13:00+00:00 - - - Aneesh Karve 2025-09-07 20:42:00+00:00 - - - Ben Westgate 2025-09-03 00:44:00+00:00 - - - Javier Mateos 2025-09-02 02:30:00+00:00 - - - Ben Westgate 2025-09-01 18:37:00+00:00 - - - Javier Mateos 2025-09-01 08:41:00+00:00 - - - Ben Westgate 2025-08-31 22:25:00+00:00 - + 2025-09-26T14:30:37.808353+00:00 + python-feedgen + + + [BIP Proposal] Add BIP-0093 (Codex32) as application to BIP-0085 'Ben Westgate' + 2025-08-31T22:25:00.000Z + + + Javier Mateos + 2025-09-01T08:41:00.000Z + + + Ben Westgate' + 2025-09-01T18:37:00.000Z + + + Javier Mateos + 2025-09-02T02:30:00.000Z + + + Ben Westgate' + 2025-09-03T00:44:00.000Z + + + Aneesh Karve + 2025-09-07T20:42:00.000Z + + + Aneesh Karve + 2025-09-07T23:13:00.000Z + + @@ -31,21 +41,17 @@ - python-feedgen + 2 Combined summary - [BIP Proposal] Add BIP-0093 (Codex32) as application to BIP-0085 - 2025-09-09T02:31:28.716821+00:00 + 2025-09-26T14:30:37.809459+00:00 + 2025-09-07T23:13:00+00:00 The recent discussions and developments around the integration of BIP-0093, also known as codex32, within the framework of BIP-0085 have garnered significant attention in the cryptocurrency community. This proposed integration aims to leverage BIP-0085's capabilities for generating deterministic entropy from BIP32 keychains to create codex32 strings directly from BIP-0032 master keys. Codex32 is designed to enhance the security and reliability of cryptographic seed storage and recovery by introducing features such as error correction, hand verification, identifiers, and secret sharing capabilities, surpassing those available through the existing BIP-39 application. The feedback received has been largely positive, with specific commendations for its potential to facilitate recoverable child codex32 strings for scenarios involving forgetful relatives, thereby improving the overall user experience in managing wallet backups. - In response to the feedback, substantial updates have been made to address concerns and clarify implementation details. Notably, modifications include the incorporation of pseudocode to elucidate the character value selection process and adjustments to the documentation to more clearly define conditions under which certain parameters are set. These changes aim to ensure a uniform application across different tools that utilize BIP-85 derivation, fostering consistency and technical robustness in the implementation of codex32. Furthermore, a recent commit has documented these updates in the project repository, indicating a proactive approach to incorporating community input into the proposal’s development process. - One area of focus in the ongoing discussion has been the need for greater clarity in the specification, particularly regarding the derivation paths and the usage of human-readable prefixes (hrp) and identifiers. Suggestions have been made to simplify or clarify the derivation paths and provide more detailed explanations of each path segment to aid future implementers. Additionally, there is an emphasis on refining the reference implementation to align with the latest version to avoid confusion and compatibility issues. - Ben Westgate's proposal for integrating BIP-0093 (codex32) with BIP-0085 is outlined in detail, highlighting the methodological approach towards utilizing BIP-85 for generating codex32 backups directly from BIP-0032 master keys. This proposition not only aims to standardize the generation of codex32 backups but also underscores the advantages of codex32 over BIP-39, including its error correction capabilities and secret sharing attributes. The initiative has seen supportive momentum, with draft PRs and potential applications being explored to enhance interoperability and ease of use across systems. - Feedback from the community is crucial to the ongoing development and refinement of this proposal. Interested parties are encouraged to review the detailed insights and participate in further discussions, which can be found in the proposal documentation linked here: [BIP-0093 Proposal](https://github.com/bitcoin/bips/compare/master.BenWestgate:bips:codex32). This collaborative effort reflects the commitment of the Bitcoin Development community to enhance and rigorously assess the technical soundness of proposals, aiming to streamline wallet backup processes and improve interoperability across the cryptocurrency ecosystem. - 2025-09-07T23:13:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Elliptic-Curve-Operations-for-Bitcoin-Script.xml b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Elliptic-Curve-Operations-for-Bitcoin-Script.xml index 8e75e263e4..c78218c01e 100644 --- a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Elliptic-Curve-Operations-for-Bitcoin-Script.xml +++ b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Elliptic-Curve-Operations-for-Bitcoin-Script.xml @@ -1,31 +1,35 @@ - + 2 Combined summary - [BIP Proposal] Elliptic Curve Operations for Bitcoin Script - 2025-09-02T02:42:16.810149+00:00 - - jeremy 2025-09-01 22:43:00+00:00 - - - jeremy 2025-08-25 16:45:00+00:00 - - - Olaoluwa Osuntokun 2025-08-25 00:50:00+00:00 - + 2025-09-26T14:30:35.682234+00:00 + python-feedgen + + + [BIP Proposal] Elliptic Curve Operations for Bitcoin Script Olaoluwa Osuntokun + 2025-08-25T00:50:00.000Z + + + jeremy + 2025-08-25T16:45:00.000Z + + + jeremy + 2025-09-01T22:43:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Elliptic Curve Operations for Bitcoin Script - 2025-09-02T02:42:16.810194+00:00 + 2025-09-26T14:30:35.682775+00:00 + 2025-09-01T22:43:00+00:00 The proposal to enhance Bitcoin's scripting language by introducing new Elliptic Curve (EC) operation op codes is aimed at leveraging the Taproot infrastructure to expand the blockchain's capabilities in facilitating complex operations directly within its script. This initiative paves the way for the computation of the top-level Taproot output public key using Bitcoin Script, enabling a more dynamic approach to creating smart contracts on the Bitcoin blockchain. The integration of these op codes, including `OP_EC_POINT_ADD`, `OP_EC_POINT_MUL`, `OP_EC_POINT_NEGATE`, and `OP_EC_POINT_X_COORD`, is designed to broaden the range of functional operations available to developers, thereby fostering the development of versatile smart contracts and innovative applications such as optimized Discreet Log Contracts (DLCs), partial musig2 signature verifications, and EC-based sigma protocols. - A specific aspect of the proposal highlights the introduction of an operation named *OP_EC_LIFT_X_EVEN*, which seeks to counteract the effects of *OP_EC_POINT_X_COORD* with some limitations due to parity considerations, useful in conjunction with *OP_IKEY*. Moreover, the proposal suggests the addition of *OP_EC_GENERATOR* to simplify script composability by pushing the generator point G onto the stack directly, which addresses the ambiguity associated with representing G as 0 and facilitates a more intuitive execution of operations involving the point at infinity. This modification is expected to streamline processes like *OP_TWEAKADD* by enabling a more coherent sequence of generating a point, multiplication, lifting, and adding points together. - These proposed changes aim to rectify and clarify the procedures for elliptic curve operations within Bitcoin's scripting language, addressing current shortcomings and inaccuracies. By doing so, they set the stage for more accurate and efficient implementations of elliptic curve operations in Bitcoin scripts. For those interested in the technical specifics or contributing to the ongoing discussion, comprehensive details can be accessed through the Bitcoin Improvement Proposal (BIP) [here](https://github.com/bitcoin/bips/pull/1945), alongside a reference implementation for `btcd` available [here](https://github.com/btcsuite/btcd/pull/2413). Through these enhancements, Bitcoin's scripting language is poised for significant advancements in its ability to support complex and secure on-chain logic implementations, marking a substantial step forward in the evolution of Bitcoin's scripting functionalities. - 2025-09-01T22:43:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Mempool-Validation-and-Relay-Policies-via-User-Defined-Scripts.xml b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Mempool-Validation-and-Relay-Policies-via-User-Defined-Scripts.xml index 8fcd758cd0..23ac5e1f65 100644 --- a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Mempool-Validation-and-Relay-Policies-via-User-Defined-Scripts.xml +++ b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-Mempool-Validation-and-Relay-Policies-via-User-Defined-Scripts.xml @@ -1,62 +1,95 @@ - + 2 Combined summary - [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts - 2025-09-26T02:30:13.368486+00:00 - - Andrew Poelstra 2025-09-25 23:33:00+00:00 - - - Greg Maxwell 2025-09-25 21:51:00+00:00 - - - Aiden McClelland 2025-09-25 21:25:00+00:00 - - - Greg Maxwell 2025-09-25 21:14:00+00:00 - - - Chris Guida 2025-09-25 21:02:00+00:00 - - - Aiden McClelland 2025-09-25 20:51:00+00:00 - - - Greg Maxwell 2025-09-25 20:46:00+00:00 - - - Greg Maxwell 2025-09-25 20:03:00+00:00 - - - Chris Guida 2025-09-25 17:52:00+00:00 - - - Luke Dashjr 2025-09-25 14:33:00+00:00 - - - yes_please 2025-09-25 09:21:00+00:00 - - - bigshiny 2025-09-25 02:20:00+00:00 - - - Greg Maxwell 2025-09-24 22:49:00+00:00 - - - Greg Maxwell 2025-09-24 20:01:00+00:00 - - - Chris Guida 2025-09-24 19:16:00+00:00 - - - Aiden McClelland 2025-09-24 18:54:00+00:00 - - - Greg Maxwell 2025-09-24 18:46:00+00:00 - - - [BIP Proposal] Mempool Validation and Relay Policies via UserDefined Scripts Aiden McClelland 2025-09-24 18:18:00+00:00 - + 2025-09-26T14:30:39.959964+00:00 + python-feedgen + + + [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts Aiden McClelland + 2025-09-24T18:18:00.000Z + + + Greg Maxwell + 2025-09-24T18:46:00.000Z + + + Aiden McClelland + 2025-09-24T18:54:00.000Z + + + Chris Guida + 2025-09-24T19:16:00.000Z + + + Greg Maxwell + 2025-09-24T20:01:00.000Z + + + Greg Maxwell + 2025-09-24T22:49:00.000Z + + + bigshiny + 2025-09-25T02:20:00.000Z + + + yes_please + 2025-09-25T09:21:00.000Z + + + Luke Dashjr + 2025-09-25T14:33:00.000Z + + + Chris Guida + 2025-09-25T17:52:00.000Z + + + Greg Maxwell + 2025-09-25T20:03:00.000Z + + + Greg Maxwell + 2025-09-25T20:46:00.000Z + + + Aiden McClelland + 2025-09-25T20:51:00.000Z + + + Chris Guida + 2025-09-25T21:02:00.000Z + + + Greg Maxwell + 2025-09-25T21:14:00.000Z + + + Aiden McClelland + 2025-09-25T21:25:00.000Z + + + Greg Maxwell + 2025-09-25T21:51:00.000Z + + + Andrew Poelstra + 2025-09-25T23:33:00.000Z + + + Chris Riley + 2025-09-26T02:06:00.000Z + + + Aiden McClelland + 2025-09-26T02:17:00.000Z + + + Chris Riley + 2025-09-26T02:28:00.000Z + + @@ -75,21 +108,17 @@ - python-feedgen + 2 Combined summary - [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts - 2025-09-26T02:30:13.368617+00:00 + 2025-09-26T14:30:39.962446+00:00 + 2025-09-25T23:33:00+00:00 The dialogue across the Bitcoin Development Mailing List revolves around critical considerations about mempool policy, transaction filtering, and the overarching philosophy of decentralization in Bitcoin. Greg Maxwell's insights bring to light the inherent conflict between maintaining a consensus-driven system and the attempts to filter transactions beyond what is done by miners. Maxwell emphasizes that any form of filtering beyond miner activity contradicts the purpose of the mempool, which is to approximate the contents of future blocks and ensure smooth network operation. - The discussions further delve into the implications of proposed changes to the mempool relay policies. A key theme is the balance between enabling user autonomy in transaction relay choices and the potential for such flexibility to lead to censorship or a departure from Bitcoin's foundational principles. The discourse suggests a tension between the desire for individual control over transaction relays and the risk of undermining the network's decentralized ethos through selective filtering mechanisms. - Contributions from various participants, including Aiden McClelland and Chris Guida, highlight a spectrum of opinions on how to best manage mempool policies. While some advocate for greater user control as a means to democratize the process and potentially resolve disputes, others caution against the risks of fragmenting the network's consistency or inadvertently introducing mechanisms that could facilitate censorship. - Central to the conversation is the proposal for a new Bitcoin Improvement Proposal (BIP) aimed at creating a modular mempool/relay policy framework. This initiative seeks to offer a middle ground by allowing more tailored configurations of relay policies without necessitating divergent node implementations. McClelland's efforts to develop a reference implementation using QuickJS reflect a pragmatic approach to addressing community conflicts, albeit with an acknowledgment of the technical challenges involved due to his hiatus from C++ programming. - In essence, the discussions encapsulate the complexities of governance within the Bitcoin network, exploring the fine line between enhancing user agency and preserving the core attributes of decentralization and consensus. The dialogue underscores the ongoing efforts within the community to reconcile differing perspectives on network management while adhering to the principles that have guided Bitcoin's development since its inception. - 2025-09-25T23:33:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-No-burn-Quantum-Migration-Proposal-Quantum-Secure-Asset-Verification-Escrow-QSAVE-.xml b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-No-burn-Quantum-Migration-Proposal-Quantum-Secure-Asset-Verification-Escrow-QSAVE-.xml index a2534b9f1f..75b667c125 100644 --- a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-No-burn-Quantum-Migration-Proposal-Quantum-Secure-Asset-Verification-Escrow-QSAVE-.xml +++ b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-No-burn-Quantum-Migration-Proposal-Quantum-Secure-Asset-Verification-Escrow-QSAVE-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) - 2025-09-16T02:27:19.692898+00:00 - - conduition 2025-09-15 16:52:00+00:00 - - - James T 2025-08-24 22:24:00+00:00 - - - Erik Aronesty 2025-08-19 20:59:00+00:00 - - - conduition 2025-08-19 15:01:00+00:00 - - - James T 2025-08-19 10:43:00+00:00 - - - James T 2025-08-14 21:26:00+00:00 - - - conduition 2025-08-09 01:33:00+00:00 - - - James T 2025-08-04 21:18:00+00:00 - + 2025-09-26T14:30:27.122279+00:00 + python-feedgen + + + [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) 'James T' + 2025-08-04T21:18:00.000Z + + + conduition' + 2025-08-09T01:33:00.000Z + + + James T' + 2025-08-14T21:26:00.000Z + + + Javier Mateos + 2025-08-19T10:43:00.000Z + + + conduition' + 2025-08-19T15:01:00.000Z + + + Erik Aronesty + 2025-08-19T20:59:00.000Z + + + James T' + 2025-08-24T22:24:00.000Z + + + conduition' + 2025-09-15T16:52:00.000Z + + @@ -35,23 +46,18 @@ - python-feedgen + 2 Combined summary - [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) - 2025-09-16T02:27:19.692982+00:00 + 2025-09-26T14:30:27.123295+00:00 + 2025-09-15T16:52:00+00:00 The discussion surrounding the future of Bitcoin's cryptographic security, particularly in light of potential vulnerabilities exposed by advancements in quantum computing, reveals a complex landscape of technical challenges and proposed solutions. At the heart of these deliberations is the notion that the decentralized and algorithm-driven ethos of Bitcoin may, paradoxically, necessitate human intervention to navigate unforeseen technological threats such as the advent of quantum computing capable of breaking current cryptographic safeguards. - One of the primary concerns discussed is the vulnerability of Bitcoin’s Elliptic Curve Digital Signature Algorithm (ECDSA) to quantum decryption, posing a significant risk to the integrity and ownership verification mechanisms of the blockchain. The suggested responses to this threat range from consensus-based updates to the cryptographic algorithms underpinning Bitcoin to more radical proposals advocating for a managed transition to quantum-resistant signatures. Such measures underscore the community's willingness to adaptively manage the blockchain's security in response to evolving technological landscapes, emphasizing a collective approach to decision-making and protocol evolution. - Within this context, various proposals have been put forward, including soft-fork upgrades to introduce quantum-resistant algorithms and innovative methods to secure existing wallets against quantum attacks. These approaches highlight a proactive stance towards securing Bitcoin against future threats while maintaining continuity and stability within the network. The discourse also explores the utilization of zero-knowledge proofs and commit/reveal protocols as potential mechanisms for enhancing security without compromising decentralization principles, indicating a nuanced exploration of technical solutions that align with Bitcoin's foundational tenets. - However, the conversation also acknowledges the limitations and challenges associated with these technical solutions, such as the difficulty in protecting certain types of wallets and the broader implications of significant protocol changes on the Bitcoin ecosystem. This includes concerns over centralization, the ethical and practical ramifications of integrating Know Your Customer (KYC) measures, and the potential for contentious forks that could fracture the community. These discussions reflect an ongoing negotiation between innovation and pragmatism, underscoring the importance of community consensus and legal considerations in shaping the future trajectory of Bitcoin's development. - Moreover, proposals like the Quantum Secure Asset Verification & Escrow (QSAVE) initiative represent a blend of technical foresight and social responsibility, proposing a mechanism not only to protect vulnerable Bitcoins from quantum threats but also to leverage these assets for public good. This reflects a broader recognition within the community of the need to balance technological advancement with ethical stewardship and a commitment to public welfare. - In conclusion, the dialogue around securing Bitcoin against quantum computing threats illustrates a multifaceted approach encompassing technical innovation, community consensus-building, and ethical consideration. It highlights the cryptocurrency community's readiness to confront emerging challenges through adaptive problem-solving and collaborative decision-making, rooted in a desire to preserve the integrity, decentralization, and visionary promise of Bitcoin in the face of evolving technological landscapes. - 2025-09-15T16:52:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-OP-TWEAKADD.xml b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-OP-TWEAKADD.xml index 536caf7cd9..2b69c7da0d 100644 --- a/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-OP-TWEAKADD.xml +++ b/static/bitcoin-dev/Sept_2025/combined_-BIP-Proposal-OP-TWEAKADD.xml @@ -1,41 +1,46 @@ - + 2 Combined summary - [BIP Proposal] OP_TWEAKADD - 2025-09-08T02:44:06.618906+00:00 - - jeremy 2025-09-06 21:27:00+00:00 - - - Olaoluwa Osuntokun 2025-09-04 22:46:00+00:00 - - - Olaoluwa Osuntokun 2025-09-04 02:38:00+00:00 - - - jeremy 2025-08-23 18:24:00+00:00 - - - jeremy 2025-08-23 17:35:00+00:00 - + 2025-09-26T14:30:29.234071+00:00 + python-feedgen + + + [BIP Proposal] OP_TWEAKADD jeremy + 2025-08-23T17:35:00.000Z + + + jeremy + 2025-08-23T18:24:00.000Z + + + Olaoluwa Osuntokun + 2025-09-04T02:38:00.000Z + + + Olaoluwa Osuntokun + 2025-09-04T22:46:00.000Z + + + jeremy + 2025-09-06T21:27:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] OP_TWEAKADD - 2025-09-08T02:44:06.618962+00:00 + 2025-09-26T14:30:29.234822+00:00 + 2025-09-06T21:27:00+00:00 The ongoing discussions among Bitcoin developers have brought to light several key considerations and proposals aimed at refining the protocol's security and functionality. A significant point of discussion has been the potential adjustment of the operational cost associated with a new opcode, specifically considering its computational demands relative to existing operations such as `OP_CHECKSIG`. The debate underscores the importance of aligning opcode costs with their computational requirements to ensure the efficiency and security of script operations within the Bitcoin network. This conversation is part of a broader effort to continually optimize Bitcoin's scripting capabilities, reflecting the community's commitment to advancing the protocol. - In addition to opcode cost considerations, there has been detailed deliberation on the use of cryptographic techniques within the Bitcoin Improvement Proposal framework. Specifically, the introduction of tweak reveal scripts in BIP-348 and BIP-349 proposes utilizing combinations of operations like OP_TWEAKADD to enable complex cryptographic functions. These include signature composition and message verification through tailored witness and program structures, emphasizing the enhancement of security and flexibility in transaction verification processes. Techniques such as Proof-of-Signing-Order and delegation mechanisms further illustrate the sophistication of these proposed advancements, aiming to bolster the sequential integrity of signatures and provide versatile frameworks for signing authority management. - Jeremy's recent draft BIP proposing the OP_TWEAKADD opcode highlights another facet of the ongoing technical discourse within the Bitcoin development community. The proposal, which aims to enhance scripting capabilities by allowing for more efficient execution of on-chain operations, reflects careful consideration of design choices such as push versus verify semantics and the arrangement of arguments. The decision to advocate for a plain tweak, as opposed to a hashed version, indicates a preference for simplicity and flexibility, leaving room for future enhancements that could further refine the protocol's cryptographic operations. - These discussions and proposals collectively represent the Bitcoin development community's proactive approach to addressing the complexities and challenges of cryptocurrency protocol enhancement. By focusing on optimizing operational costs, advancing cryptographic techniques, and refining scripting capabilities, the community demonstrates an enduring commitment to securing and improving the Bitcoin network. For further exploration of these topics, including the detailed conversation surrounding the acceptance of compressed public keys over x-only keys in the musig2 BIP, interested readers can refer to the documented discussion [here](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/020756.html). - 2025-09-06T21:27:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2025/combined_A-Post-Quantum-Migration-Proposal.xml b/static/bitcoin-dev/Sept_2025/combined_A-Post-Quantum-Migration-Proposal.xml index 26784ef9fd..258944a8d2 100644 --- a/static/bitcoin-dev/Sept_2025/combined_A-Post-Quantum-Migration-Proposal.xml +++ b/static/bitcoin-dev/Sept_2025/combined_A-Post-Quantum-Migration-Proposal.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - A Post Quantum Migration Proposal - 2025-09-16T02:26:25.679229+00:00 - - conduition 2025-09-15 16:24:00+00:00 - - - Saint Wenhao 2025-08-23 10:22:00+00:00 - - - conduition 2025-08-22 19:59:00+00:00 - - - Saint Wenhao 2025-08-19 08:55:00+00:00 - - - Marc Johnson 2025-08-16 18:40:00+00:00 - - - Jameson Lopp 2025-08-12 14:56:00+00:00 - - - Marc Johnson 2025-07-25 10:58:00+00:00 - - - Boris Nagaev 2025-07-20 22:54:00+00:00 - - - Marin Ivezic 2025-07-20 17:39:00+00:00 - - - conduition 2025-07-20 15:56:00+00:00 - - - conduition 2025-07-20 15:37:00+00:00 - - - Peter Todd 2025-07-19 12:05:00+00:00 - - - Antoine Riard 2025-07-18 19:13:00+00:00 - - - Boris Nagaev 2025-07-16 17:34:00+00:00 - - - conduition 2025-07-16 16:43:00+00:00 - - - Ethan Heilman 2025-07-15 17:57:00+00:00 - - - Boris Nagaev 2025-07-15 14:13:00+00:00 - - - Boris Nagaev 2025-07-15 02:50:00+00:00 - - - conduition 2025-07-15 02:32:00+00:00 - - - Jameson Lopp 2025-07-14 18:52:00+00:00 - - - Ethan Heilman 2025-07-14 16:08:00+00:00 - - - Jameson Lopp 2025-07-14 13:50:00+00:00 - - - Antoine Riard 2025-07-14 02:07:00+00:00 - - - Tadge Dryja 2025-07-13 23:19:00+00:00 - - - Jameson Lopp 2025-07-12 21:36:00+00:00 - + 2025-09-26T14:30:33.565589+00:00 + python-feedgen + + + A Post Quantum Migration Proposal Jameson Lopp + 2025-07-12T21:36:00.000Z + + + Tadge Dryja + 2025-07-13T23:19:00.000Z + + + Antoine Riard + 2025-07-14T02:07:00.000Z + + + Jameson Lopp + 2025-07-14T13:50:00.000Z + + + Ethan Heilman + 2025-07-14T16:08:00.000Z + + + Jameson Lopp + 2025-07-14T18:52:00.000Z + + + conduition' + 2025-07-15T02:32:00.000Z + + + Boris Nagaev + 2025-07-15T02:50:00.000Z + + + Boris Nagaev + 2025-07-15T14:13:00.000Z + + + Ethan Heilman + 2025-07-15T17:57:00.000Z + + + conduition' + 2025-07-16T16:43:00.000Z + + + Boris Nagaev + 2025-07-16T17:34:00.000Z + + + Antoine Riard + 2025-07-18T19:13:00.000Z + + + Peter Todd + 2025-07-19T12:05:00.000Z + + + conduition' + 2025-07-20T15:37:00.000Z + + + conduition' + 2025-07-20T15:56:00.000Z + + + Marin Ivezic + 2025-07-20T17:39:00.000Z + + + Boris Nagaev + 2025-07-20T22:54:00.000Z + + + Marc Johnson + 2025-07-25T10:58:00.000Z + + + Jameson Lopp + 2025-08-12T14:56:00.000Z + + + Marc Johnson + 2025-08-16T18:40:00.000Z + + + Saint Wenhao + 2025-08-19T08:55:00.000Z + + + conduition' + 2025-08-22T19:59:00.000Z + + + Saint Wenhao + 2025-08-23T10:22:00.000Z + + + conduition' + 2025-09-15T16:24:00.000Z + + @@ -103,17 +131,15 @@ - python-feedgen + 2 Combined summary - A Post Quantum Migration Proposal - 2025-09-16T02:26:25.679400+00:00 + 2025-09-26T14:30:33.568461+00:00 + 2025-09-15T16:24:00+00:00 The discourse on enhancing Bitcoin's defense against quantum computing threats posits a phased proposal to transition the network towards post-quantum cryptographic standards. This approach is rooted in the urgency to protect the network against potential quantum attacks that could compromise its cryptographic underpinnings. By introducing a new post-quantum output type (P2QRH) and setting a timeline for phasing out legacy ECDSA/Schnorr signatures, the proposal aims to preemptively secure Bitcoin's future. The initial phase mandates stopping transactions to quantum-vulnerable addresses, advocating for a swift migration to P2QRH address types. Subsequently, spending from quantum-vulnerable UTXOs would be deemed invalid, halting transactions reliant on traditional cryptographic methods. An optional third phase explores the possibility of recovering frozen assets through zero-knowledge proofs, pending further research and consensus within the community. - This strategic initiative underscores the critical need for a proactive stance against the quantum threat, motivated by recent advancements in quantum algorithms and NIST's endorsement of post-quantum signature schemes. A successful quantum breach could drastically erode confidence in Bitcoin, inflicting substantial economic repercussions. Hence, the proposal articulates a defensive maneuver, prescribing deadlines for adopting quantum-resistant cryptographic practices to galvanize stakeholders across the Bitcoin ecosystem towards a unified response. - The proposal delineates specific expectations from various ecosystem participants, including miners, institutional holders, exchanges, custodians, and regular users, highlighting the tailored incentives for each group to upgrade. This collective effort aims to diminish the attack surface and mitigate potential losses, portraying the shift to quantum-resistant cryptography as a communal benefit. Moreover, it addresses the technical feasibility of implementing these changes via soft forks, ensuring backward compatibility and offering a gradual, inclusive path towards enhancing Bitcoin's resilience in the quantum era. - 2025-09-15T16:24:00+00:00 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2025/combined_BIP-Booby-Trapped-Wallets-Covenant-Only-Taproot-Outputs.xml b/static/bitcoin-dev/Sept_2025/combined_BIP-Booby-Trapped-Wallets-Covenant-Only-Taproot-Outputs.xml index 9ef1b04a64..49f8dab258 100644 --- a/static/bitcoin-dev/Sept_2025/combined_BIP-Booby-Trapped-Wallets-Covenant-Only-Taproot-Outputs.xml +++ b/static/bitcoin-dev/Sept_2025/combined_BIP-Booby-Trapped-Wallets-Covenant-Only-Taproot-Outputs.xml @@ -1,27 +1,30 @@ - + 2 Combined summary - BIP Booby Trapped Wallets - Covenant-Only Taproot Outputs - 2025-09-12T02:25:15.315423+00:00 - - Matias Monteagudo 2025-09-11 09:47:00+00:00 - - - Matias Monteagudo 2025-08-21 17:46:00+00:00 - + 2025-09-26T14:30:31.345477+00:00 + python-feedgen + + + BIP Booby Trapped Wallets - Covenant-Only Taproot Outputs Matias Monteagudo + 2025-08-21T17:46:00.000Z + + + Matias Monteagudo + 2025-09-11T09:47:00.000Z + + - python-feedgen + 2 Combined summary - BIP Booby Trapped Wallets - Covenant-Only Taproot Outputs - 2025-09-12T02:25:15.315484+00:00 + 2025-09-26T14:30:31.345985+00:00 + 2025-09-11T09:47:00+00:00 The proposal in question introduces a cutting-edge approach designed to bolster the security of Bitcoin wallets, particularly catering to the needs of institutional holders with significant Bitcoin assets. Authored by Matias Monteagudo, this Bitcoin Improvement Proposal (BIP) advocates for an additional, voluntary security layer that could fundamentally alter how high-value Bitcoin wallets defend against unauthorized access. Central to this proposal is the concept of covenant-only Taproot outputs, which essentially prohibit key-path spending—a conventional method allowing transactions to be signed off directly with a private key—thereby enforcing transactions to exclusively proceed via script-path spending. This mechanism not only restricts transactions to pre-approved destinations but also cleverly conceals these restrictions until an actual attempt at unauthorized access is made, thus adding a robust layer of security while maintaining transaction privacy until it's necessary to reveal such details. - The underlying motivation for this BIP stems from the escalating security risks faced by large-scale Bitcoin operators, such as exchanges, where the visible nature of current security protocols does little to deter advanced cyber threats. By enabling wallet owners to limit transaction flows to specified destinations and automatically diverting any unauthorized transactions to so-called arbitration wallets, the proposed system aims to maintain operational normalcy, thereby deterring potential attackers who rely on preemptive knowledge of security measures. The technical groundwork for implementing these covenant-only Taproot outputs involves invalidating the internal key to make key-path spending nonviable, ensuring all transactions comply with the set covenant conditions. A detailed activation plan adheres to the BIP 9 framework, calling for widespread miner consensus before this new protocol can take effect, assuring backward compatibility to preserve the existing ecosystem's integrity. - From a security standpoint, the proposal meticulously outlines cryptographic safeguards to render the internal key unusable, thus blocking direct path spending avenues. It further suggests concealing the covenant logic to prevent attackers from identifying and exploiting potential vulnerabilities ahead of their malicious attempts. On the economic front, the proposal posits that creating a high-risk environment for theft, promoting fair arbitration practices, and highlighting the network-wide benefits of improved security protocols could collectively enhance the Bitcoin network's resilience against attacks without sacrificing privacy or efficiency. Final sections of the proposal include reference implementations for essential validation logic, wallet integration guidelines, and test vectors to assess the proposal's practical viability. The document closes with acknowledgments to the broader Bitcoin development community and credits to the creators of the Taproot script commitment scheme, indicating a phased review, testing, and eventual deployment strategy aimed at significantly enhancing institutional Bitcoin security without compromising the user experience or network performance. - 2025-09-11T09:47:00+00:00 - + \ No newline at end of file From 2d416eb63aa1f040eda715096cacf62ee62b4862 Mon Sep 17 00:00:00 2001 From: urvishp80 Date: Fri, 26 Sep 2025 16:06:26 +0000 Subject: [PATCH 3/5] Updated XML files with threading structure (threading update only) for years 2016-2022 --- .../April_2016/combined_AsicBoost.xml | 13 +- ...ned_BIP-CPRKV-Check-private-key-verify.xml | 13 +- ...e-0-12-1-release-candidate-1-available.xml | 13 +- .../combined_Proposal-to-update-BIP-32.xml | 13 +- ...p2p-authentication-and-encryption-BIPs.xml | 13 +- ...and-multi-sender-coinjoin-transactions.xml | 13 +- .../combined_A-Better-MMR-Definition.xml | 218 +++++---- ...ombined_A-Small-Modification-to-Segwit.xml | 302 ++++++------ ...and-understand-softforks-and-hardforks.xml | 13 +- ...timization-on-the-Bitcoin-POW-function.xml | 29 +- ...P-draft-Extended-block-header-hardfork.xml | 78 ++-- ...d-version-bits-voting-bip-genvbvoting-.xml | 78 ++-- ...ert-attack-on-the-Bitcoin-POW-function.xml | 13 +- ...-BIP43-purpose-allocation-for-Ethereum.xml | 33 +- ...ed-wallet-performance-and-SPV-security.xml | 256 ++++++----- ...-blocks-from-malicious-miner-takeover-.xml | 166 ++++--- ...T-in-Bitcoin-without-extension-blocks-.xml | 29 +- ...ith-versionbits-and-guaranteed-lock-in.xml | 29 +- ...bits-extension-with-guaranteed-lock-in.xml | 13 +- ...ension-block-proposal-by-Jeffrey-et-al.xml | 13 +- ...entness-status-of-the-pruned-relatives.xml | 13 +- ...fork-proposal-from-last-week-s-meeting.xml | 13 +- .../combined_High-fees-centralization.xml | 71 +-- ...ined_I-do-not-support-the-BIP-148-UASF.xml | 302 ++++++------ ...otecting-Bitcoin-from-malicious-miners.xml | 120 +++-- ...sis-of-PoW-Policy-Changes-Re-ASICBOOST.xml | 29 +- .../April_2017/combined_Proof-of-Loss.xml | 50 +- ...-an-ideal-PoW-algorithm-implementation.xml | 43 +- ...Proposal-Soft-Fork-Threshold-Signaling.xml | 50 +- .../April_2017/combined_Segwit-v2.xml | 64 +-- ...ed-soft-hard-fork-Request-For-Comments.xml | 219 +++++---- ...s-A-Better-Alternative-to-Pruned-Nodes.xml | 183 ++++---- .../combined_Transaction-signalling.xml | 64 +-- ...ounty-protocol-aka-bribing-the-miners-.xml | 57 ++- ...ng-a-storage-engine-without-UTXO-index.xml | 260 ++++++----- ...-activation-of-segwit-for-legacy-nodes.xml | 36 +- .../combined_BIP-sighash-noinput.xml | 253 +++++----- ...loomFilter-issue-with-segwit-addresses.xml | 64 +-- ...ew-questions-regarding-ListTransaction.xml | 85 ++-- ...rous-cryptocurrency-products-affected-.xml | 85 ++-- ...mbined_Low-bandwidth-transaction-relay.xml | 50 +- ...-in-one-BIP32-derivation-path-new-BIP-.xml | 57 ++- ...-trust-authority-on-Bitcoin-blockchain.xml | 29 +- .../combined_Optimized-Header-Sync.xml | 57 ++- .../April_2018/combined_Signature-bundles.xml | 43 +- ...-for-Lightning-and-Off-Chain-Contracts.xml | 113 +++-- ...-Enhance-privacy-by-change-obfuscation.xml | 50 +- ..._proposal-extend-WIF-format-for-segwit.xml | 64 +-- ...d-to-PSBT-to-make-multisig-more-secure.xml | 64 +-- ...IP-Bitcoin-Integrated-Address-Feature-.xml | 36 +- ...bilities-With-Rewriting-Core-In-Python.xml | 43 +- ...ing-SPV-security-with-PoW-fraud-proofs.xml | 106 +++-- .../April_2019/combined_IsStandard.xml | 99 ++-- .../combined_License-for-BIP39-word-lists.xml | 50 +- ...t-of-proposals-for-hard-fork-soft-fork.xml | 29 +- ...ing-Payjoin-Without-Merchant-Purchases.xml | 29 +- .../combined_Smart-Contracts-Unchained.xml | 106 +++-- ...posal-for-minimum-price-of-50k-USD-BTC.xml | 103 +++-- ...combined_assumeutxo-and-UTXO-snapshots.xml | 141 +++--- ...cessively-low-high-fees-and-block-size.xml | 64 +-- ...ed_Academic-research-regarding-BIP0002.xml | 36 +- ...scriptPubKeys-in-the-signature-message.xml | 106 +++-- ...rministic-Entropy-From-BIP32-Keychains.xml | 50 +- ...hain-protocol-using-schnorr-signatures.xml | 106 +++-- .../April_2020/combined_PSBT-in-QR-codes.xml | 29 +- ...-Counterparties-and-Competing-Interest.xml | 224 ++++----- ...vault-a-multi-party-vault-architecture.xml | 29 +- ...in-alphabetic-order-to-protect-privacy.xml | 29 +- .../combined_Statechain-implementations.xml | 190 ++++---- ...-Motivating-Address-type-for-OP-RETURN.xml | 64 +-- .../combined_7z-block-compression-18-.xml | 36 +- ...tional-BIPs-related-to-other-proposals.xml | 43 +- ...fining-a-Complete-Process-for-Upgrades.xml | 29 +- ...-new-standard-for-soft-fork-activation.xml | 36 +- .../combined_BIP-limiting-OP-RETURN-HF.xml | 190 ++++---- ...col-and-decentralized-storage-protocol.xml | 29 +- ...ion-protocol-and-decentralized-storage.xml | 13 +- ...ock-weight-penalty-for-UTXO-set-growth.xml | 29 +- ...ined_Decentralized-Naming-Protocol-BIP.xml | 36 +- ...with-Sapio-available-on-Mainnet-today-.xml | 36 +- .../combined_Fee-estimates-and-RBF.xml | 13 +- ...n-alternate-proof-without-a-hard-fork-.xml | 71 +-- ...bined_L2s-Onchain-Support-IRC-Workshop.xml | 57 ++- ...-2021-Taproot-Activation-Meeting-Notes.xml | 13 +- .../combined_New-PSBT-version-proposal.xml | 102 ++-- ...SA-Taproot-loss-of-quantum-protections.xml | 206 +++++---- ...ombined_Prediction-Markets-and-Bitcoin.xml | 43 +- ...Proposal-Bitcoin-Secure-Multisig-Setup.xml | 274 ++++++----- ...combined_Proposed-BIP-editor-Kalle-Alm.xml | 134 +++--- ...mbined_Reminder-on-the-Purpose-of-BIPs.xml | 13 +- ..._Response-to-Rusty-Russell-from-Github.xml | 36 +- ...root-Activation-Meeting-4-20-Cancelled.xml | 29 +- ...n-Meeting-Notes-April-6th-The-CoinFlip.xml | 29 +- ...pril-6th-19-00-UTC-bitcoin-bitcoin-dev.xml | 99 ++-- ...ng-on-IRC-Tuesday-13th-April-19-00-UTC.xml | 13 +- ...te-on-Speedy-Trial-The-circus-rolls-on.xml | 61 +-- ...ay-s-Taproot-activation-meeting-on-IRC.xml | 29 +- ...ed_maximum-block-height-on-transaction.xml | 13 +- ...ting-transitory-soft-forks-e-g-for-CTV.xml | 5 +- ...cally-reverting-transitory-soft-forks-.xml | 5 +- ...us-soft-fork-activations-are-attempted.xml | 5 +- ...combined_-Changing-the-blocksize-limit.xml | 13 +- ...transactions-after-segwit-is-accepted-.xml | 13 +- .../Aug_2016/combined_Authentication-BIP.xml | 13 +- .../bitcoin-dev/Aug_2016/combined_BIP-151.xml | 13 +- ...IP-Number-Request-Addresses-over-Audio.xml | 13 +- ...combined_BIP-Number-Request-Open-Asset.xml | 13 +- ...-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml | 13 +- .../combined_BIP-clearing-house-addresses.xml | 13 +- .../combined_BIP-draft-HTLC-transactions.xml | 13 +- ...orched-Earth-Doublespending-Protection.xml | 17 +- .../Aug_2016/combined_Fees-and-Accounts.xml | 13 +- ...ntire-content-of-on-chain-transactions.xml | 13 +- ...ed_General-bitcoin-users-mailing-list-.xml | 13 +- .../combined_Hardware-Wallet-Standard.xml | 13 +- ...ntire-content-of-on-chain-transactions.xml | 13 +- ...-IF-and-OP-NOTIF-malleability-in-P2WSH.xml | 13 +- ...mbined_New-BIP-Low-S-values-signatures.xml | 13 +- ...5-Retarget-Call-For-Proposals-Now-Open.xml | 13 +- ...tatus-updates-for-BIP-9-68-112-and-113.xml | 13 +- ...Signed-Bitcoin-Transaction-PSBT-format.xml | 50 +- .../combined_-Compressed-headers-stream.xml | 122 +++-- ...osal-Pay-to-Contract-BIP43-Application.xml | 57 ++- ...ented-multiaccount-multisig-HD-wallets.xml | 50 +- ...mbined_BIP49-Derivation-scheme-changes.xml | 64 +-- ...combined_Fwd-Compressed-headers-stream.xml | 17 +- ...in-the-setting-of-blockchain-hardforks.xml | 13 +- ...lockchain-database-to-reduce-its-size-.xml | 43 +- ...Addresses-and-Uncompressed-Public-Keys.xml | 54 ++- ...lability-Problem-Part-II-Adam-Shem-Tov.xml | 50 +- ...ing-the-Scalability-Problem-on-Bitcoin.xml | 13 +- ...allets-Using-P2SH-for-Recovery-Options.xml | 36 +- ..._UTXO-growth-scaling-solution-proposal.xml | 13 +- ...o-adding-a-dlopen-message-hook-system-.xml | 50 +- .../combined_BLS-library-released.xml | 36 +- .../Aug_2018/combined_Brock-Pierce-.xml | 43 +- ...ilding-a-Bitcoin-API-and-query-system-.xml | 120 +++-- ...-locators-trivial-protocol-change-BIP-.xml | 29 +- .../combined_Claiming-an-OP-RETURN-Prefix.xml | 13 +- ...-around-to-fixing-the-timewarp-attack-.xml | 13 +- ...ombined_Multisignature-for-bip-schnorr.xml | 50 +- ...GHASH2-for-version-1-witness-programme.xml | 85 ++-- .../combined_Schnorr-signatures-BIP.xml | 232 ++++++---- ...on-for-a-universal-bitcoin-value-scale.xml | 64 +-- .../Aug_2018/combined_Testnet3-Reest.xml | 64 +-- ...erialization-in-PSBT-non-witness-UTXOs.xml | 36 +- .../combined_bitcoin-transactions.xml | 43 +- ...ical-sender-receiver-coinjoin-protocol.xml | 120 +++-- .../combined_-Meta-bitcoin-dev-moderation.xml | 29 +- ...yte-public-keys-in-Schnorr-and-Taproot.xml | 36 +- ...ing-checkpoint-to-the-Bitcoin-protocol.xml | 85 ++-- ...sable-Bloom-based-Filtering-by-default.xml | 176 ++++--- ...nti-theft-recovery-clawback-mechanisms.xml | 96 ++-- ...g-CSV-and-segwit-soft-fork-activations.xml | 36 +- ...-to-sybil-attacks-using-fidelity-bonds.xml | 232 ++++++---- .../Aug_2019/combined_Miniscript.xml | 36 +- .../combined_OP-LOOKUP-OUTPUT-proposal.xml | 85 ++-- ...ns-to-BIP-174-for-Future-Extensibility.xml | 78 ++-- ...scrowed-storage-and-messaging-at-L2-L3.xml | 71 +-- .../Aug_2019/combined_Taproot-proposal.xml | 183 ++++---- .../combined_testing-bitcoin-nodes.xml | 43 +- ...ombined_BIP-118-and-SIGHASH-ANYPREVOUT.xml | 113 +++-- ...t-Custom-Signets-and-Resetting-Testnet.xml | 29 +- ...-for-routed-multi-transaction-CoinSwap.xml | 177 ++++--- ...ion-when-new-p2p-connections-are-setup.xml | 225 +++++---- ...that-saves-space-and-give-more-privacy.xml | 29 +- ...dness-tiebreaker-for-R-point-in-BIP340.xml | 57 ++- ...bined_Smaller-Transactions-with-PubRef.xml | 43 +- .../combined_Time-to-lower-minrelaytxfee-.xml | 36 +- .../combined_reviving-op-difficulty.xml | 106 +++-- ...org-a-web-based-PSBT-viewer-and-editor.xml | 50 +- ...roposals-for-Output-Script-Descriptors.xml | 99 ++-- .../combined_Bip-0039-Wordlist-Romanian.xml | 43 +- ...tions-Per-Second-with-stronger-privacy.xml | 302 ++++++------ ...oposal-for-a-decentralised-mining-pool.xml | 13 +- ...lage-A-project-dedicated-to-Hal-Finney.xml | 43 +- ...unt-as-a-function-of-total-input-value.xml | 100 ++-- ...o-avoid-errors-on-BTC-public-addresses.xml | 113 +++-- ...eum-EVM-at-present-for-Bitcoin-script-.xml | 71 +-- ...t-roll-out-Tuesday-July-20th-17-15-UTC.xml | 29 +- ...SA-Taproot-loss-of-quantum-protections.xml | 206 +++++---- ...few-IANA-mime-types-related-to-Bitcoin.xml | 64 +-- .../combined_Removing-the-Dust-Limit.xml | 266 ++++++----- ...n-version-number-in-different-projects.xml | 29 +- ...bined_src-httprpc-cpp-InterruptHTTPRPC.xml | 29 +- ...A-method-for-BIP322-signing-delegation.xml | 5 +- ...erivation-Paths-in-a-Single-Descriptor.xml | 5 +- ...P-Proposal-Wallet-Labels-Export-Format.xml | 5 +- ...e-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml | 5 +- .../combined_New-Silent-Payment-version.xml | 5 +- ...community-process-to-specify-covenants.xml | 5 +- .../combined_Regarding-BIP322-edge-cases.xml | 5 +- ...ngly-Tail-Emission-Is-Not-Inflationary.xml | 5 +- ...tr-coinjoin-implementation-using-nostr.xml | 5 +- .../Dec_2016/combined_Bitcoin-Currency.xml | 13 +- ...ental-network-with-a-new-header-format.xml | 13 +- ...same-way-we-do-difficulty-aka-Block75-.xml | 13 +- ...ultisig-with-hashes-instead-of-pubkeys.xml | 13 +- ...mbined_New-BIP-Hardfork-warning-system.xml | 13 +- .../combined_Planned-Obsolescence.xml | 13 +- ...-failures-was-Re-Planned-Obsolescence-.xml | 13 +- .../combined_-Compressed-headers-stream.xml | 122 +++-- ...tralized-mapping-for-wallet-addresses-.xml | 99 ++-- ...ty-For-Ordering-Transactions-In-Blocks.xml | 36 +- ...mbined_BIP-21-amendment-proposal-no125.xml | 71 +-- .../combined_BIP-Dead-Man-s-Switch.xml | 78 ++-- .../combined_BIP-Idea-Marginal-Pricing.xml | 99 ++-- ...sal-Crypto-Open-Exchange-Protocol-COX-.xml | 50 +- ...ty-For-Ordering-Transactions-In-Blocks.xml | 169 ++++--- ...ht-For-Ordering-Transactions-In-Blocks.xml | 78 ++-- ...posal-Utilization-of-bits-denomination.xml | 92 ++-- ...d_BIP-for-Legacy-Sign-Verify-functions.xml | 50 +- ...out-SegWit-transaction-size-and-bech32.xml | 57 ++- ...evel-language-targeting-Bitcoin-Script.xml | 36 +- ...gle-Use-Seals-and-Proof-of-Publication.xml | 36 +- ...message-against-SegWit-P2SH-addresses-.xml | 71 +-- ...ature-for-all-transactions-in-a-block-.xml | 36 +- ...s-have-almost-crossed-the-block-reward.xml | 106 +++-- ...action-aging-to-relieve-user-concerns-.xml | 29 +- .../Dec_2017/combined_Two-Drivechain-BIPs.xml | 127 ++--- ...n-Confidential-Transactions-efficiency.xml | 57 ++- .../combined_Why-not-witnessless-nodes-.xml | 92 ++-- ...think-about-having-a-maximum-fee-rate-.xml | 36 +- ...BIP-Proposal-Address-Paste-Improvement.xml | 85 ++-- .../Dec_2018/combined_BIP39-seeds.xml | 69 +-- ...Contracting-Applications-eg-Lightning-.xml | 124 +++-- ...fidential-Transactions-in-Bitcoin-Core.xml | 43 +- ...-much-time-between-difficulty-changes-.xml | 29 +- ...l-for-Palindromic-Reversible-Mnemonics.xml | 50 +- ...ined_Safer-NOINPUT-with-output-tagging.xml | 158 +++---- ...shes-and-more-granular-SIGHASH-NOINPUT.xml | 184 +------- ...mbined_Schnorr-and-taproot-etc-upgrade.xml | 57 ++- ...ility-through-wallet-interoperability-.xml | 36 +- ...insert-delete-detection-and-next-steps.xml | 36 +- .../combined_BIP-OP-CHECKTEMPLATEVERIFY.xml | 104 +++-- .../combined_Base64-encoded-descriptors.xml | 57 ++- ...h-covenants-sighash-anyprevout-op-ctv-.xml | 36 +- .../Dec_2019/combined_Composable-MuSig.xml | 61 +-- ...Human-readable-format-for-private-keys.xml | 29 +- ...ed_Non-equal-value-CoinJoins-Opinions-.xml | 46 +- ...d-increasing-security-at-the-same-time.xml | 13 +- ...Signing-CHECKSIG-position-in-Tapscript.xml | 57 ++- ...col-to-send-payments-without-addresses.xml | 85 ++-- ...-0322-generic-signmessage-improvements.xml | 57 ++- ...BIP-Automated-and-Secure-Communication.xml | 36 +- ...combined_BIP-Proposal-Wallet-Interface.xml | 64 +-- .../combined_New-PSBT-version-proposal.xml | 102 ++-- .../combined_Out-of-band-transaction-fees.xml | 57 ++- ...32-for-future-Segwit-Versions-BIP-173-.xml | 183 ++++---- ...ft-Fork-via-Proof-of-Work-Fraud-Proofs.xml | 34 +- .../Dec_2020/combined_bip48-proposal.xml | 53 +-- ...-of-Having-Fun-and-maybe-staying-poor-.xml | 29 +- ...s-Organizations-DAOs-Will-Save-Bitcoin.xml | 36 +- ...ralized-Coordination-Free-Mining-Pools.xml | 162 ++++--- ...dvent-Calendar-Derivatives-and-Options.xml | 50 +- ...r-Oracles-Bonds-and-Attestation-Chains.xml | 43 +- ...ndar-Review-of-Smart-Contract-Concepts.xml | 13 +- ...dar-What-s-Smart-about-Smart-Contracts.xml | 13 +- .../Dec_2021/combined_A-fee-bumping-model.xml | 13 +- ...IP-119-Deployment-and-Review-Workshops.xml | 29 +- ...nts-and-capabilities-in-the-UTXO-model.xml | 67 +-- ...kshares-to-Improve-Finality-Heuristics.xml | 36 +- ...mbined_On-the-regularity-of-soft-forks.xml | 90 ++-- ...iece-Breaking-bitcoin-by-playing-chess.xml | 36 +- ...Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml | 99 ++-- ...dcast-mechanism-in-Bitcoin-P2P-network.xml | 85 ++-- ...ending-OP-RETURN-via-Bitcoin-Lightning.xml | 85 ++-- ...ombined_Take-2-Removing-the-Dust-Limit.xml | 67 +-- ...o-conf-apps-in-immediate-danger-angus-.xml | 5 +- ...RBF-Zero-conf-apps-in-immediate-danger.xml | 5 +- ...ed_Pseudocode-for-robust-tail-emission.xml | 5 +- ...ined_bitcoin-dev-Digest-Vol-91-Issue-5.xml | 5 +- ...-listening-nodes-are-running-full-rbf-.xml | 5 +- ...ro-value-OP-RETURN-in-Payment-Protocol.xml | 13 +- ...BIP-Proposal-New-feefilter-p2p-message.xml | 17 +- ...er-header-format-and-bigger-block-size.xml | 13 +- ...ned_BIP-CPRKV-Check-private-key-verify.xml | 13 +- .../Feb_2016/combined_BIP-Final-status.xml | 13 +- ...Status-comments-and-copyright-licenses.xml | 13 +- ...rd-fork-opt-in-mechanism-for-SPV-nodes.xml | 13 +- ...crease-block-size-limit-to-2-megabytes.xml | 13 +- ...p-some-misconceptions-about-full-nodes.xml | 13 +- ...with-a-pre-generated-UTXO-set-database.xml | 13 +- .../Feb_2016/combined_Hardfork-bit-BIP.xml | 13 +- ...tched-INVs-to-reduce-full-node-traffic.xml | 13 +- ...Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml | 13 +- ..._On-Hardforks-in-the-Context-of-SegWit.xml | 13 +- .../combined_Pre-BIP-Growth-Soft-hardfork.xml | 13 +- ...on-regarding-Confidential-Transactions.xml | 13 +- ...eterogeneous-Input-Script-Transactions.xml | 13 +- ..._SIGHASH-NOINPUT-in-Segregated-Witness.xml | 13 +- .../Feb_2016/combined_SegWit-GBT-updates.xml | 13 +- ...pgrade-Procedures-Block-Extension-Data.xml | 13 +- ...fork-fix-for-block-withholding-attacks.xml | 13 +- ...sful-Zero-Knowledge-Contingent-Payment.xml | 13 +- ...ee-Month-bitcoin-dev-Moderation-Review.xml | 13 +- ...-BIP-Community-Consensus-Voting-System.xml | 99 ++-- .../combined_A-Better-MMR-Definition.xml | 218 +++++---- ...ed-Version-of-Luke-jr-s-Block-Size-BIP.xml | 127 ++--- .../combined_BIP-Block75-New-algorithm.xml | 99 ++-- ..._BIP150-151-concerns-and-some-comments.xml | 43 +- ...mbined_BIP151-protocol-incompatibility.xml | 106 +++-- ...ed-wallet-performance-and-SPV-security.xml | 256 ++++++----- .../combined_Generalized-Commitments.xml | 13 +- ...ds-user-activated-soft-fork-activation.xml | 141 +++--- .../Feb_2017/combined_Proof-of-Loss.xml | 50 +- ...r-storing-and-verifying-the-blockchain.xml | 50 +- ...hird-parties-not-just-repo-maintainers.xml | 239 ++++++---- ...Spoonnet-another-experimental-hardfork.xml | 29 +- ...s-do-not-need-a-soft-fork-to-be-useful.xml | 57 ++- .../combined_Three-hardfork-related-BIPs.xml | 176 ++++--- ...nalling-through-output-address-hashing.xml | 40 +- ...ed_-BIP-Stratum-protocol-specification.xml | 29 +- ...mbined_Alternative-way-to-count-sigops.xml | 29 +- ...-process-to-include-buried-deployments.xml | 57 ++- .../combined_BIP0008-clarification.xml | 29 +- .../Feb_2018/combined_Built-in-encryption.xml | 29 +- ...Electrum-Personal-Server-alpha-release.xml | 29 +- ...e-scripts-under-the-taproot-assumption.xml | 78 ++-- ...y-SegWit-limited-to-just-witness-data-.xml | 57 ++- .../combined_Multi-CSV-Transaction.xml | 36 +- ...ST-8202-Blockchain-Technology-Overview.xml | 71 +-- ...ned_New-Bitcoin-Core-macOS-signing-key.xml | 43 +- ...ned_Possible-change-to-the-MIT-license.xml | 13 +- ...ombined_Revisiting-BIP-125-RBF-policy-.xml | 141 +++--- ...-dev-environment-bitcoind-bitcoin-cli-.xml | 29 +- .../combined_Simple-lock-unlock-mechanism.xml | 57 ++- ...thoughts-on-removing-timestamps-in-PoW.xml | 13 +- ...rivacy-preserving-switchable-scripting.xml | 181 +++++--- ...s-have-almost-crossed-the-block-reward.xml | 106 +++-- .../combined_Transition-to-post-quantum.xml | 99 ++-- ...-Simple-Proof-of-Reserves-Transactions.xml | 37 +- .../combined_BIP-Symbol-for-satoshi.xml | 50 +- ...of-Messages-using-Bitcoin-Private-Keys.xml | 61 ++- .../combined_BIP-proposal-addrv2-message.xml | 36 +- ...Contracting-Applications-eg-Lightning-.xml | 124 +++-- .../combined_Card-Shuffle-To-Bitcoin-Seed.xml | 64 +-- ...mbined_Fortune-Cookies-to-Bitcoin-Seed.xml | 36 +- ...ntial-Transactions-in-extension-blocks.xml | 57 ++- ...a-BIP157-server-BIP158-change-proposal.xml | 113 +++-- ...Simple-Proof-of-Reserves-Transactions-.xml | 13 +- ...ee-in-ZkVM-a-variant-of-Taproot-G-root.xml | 29 +- .../combined_Privacy-literature-review.xml | 29 +- ...ined_Proof-of-Stake-Bitcoin-Sidechains.xml | 120 +++-- ...ined_Safer-NOINPUT-with-output-tagging.xml | 158 +++---- ...shes-and-more-granular-SIGHASH-NOINPUT.xml | 184 +------- ...et-Log-Contract-Protocol-Specification.xml | 36 +- ...n-pubkeys-more-secure-nonce-generation.xml | 54 ++- .../combined_BIP-OP-CHECKTEMPLATEVERIFY.xml | 104 +++-- .../combined_CTV-through-SIGHASH-flags.xml | 29 +- ...han-transaction-in-the-Bitcoin-network.xml | 29 +- .../Feb_2020/combined_Composable-MuSig.xml | 61 +-- ..._LN-Coinjoin-a-Great-Tx-Format-Wedding.xml | 71 +-- ...ed_Non-equal-value-CoinJoins-Opinions-.xml | 46 +- ...hardware-wallets-and-airgapped-signers.xml | 13 +- ...mbined_Onchain-fee-insurance-mechanism.xml | 36 +- ...urge-attacks-spin-on-sabotage-attacks-.xml | 71 +-- ...nt-of-Failure-with-Seed-Phrase-Storage.xml | 54 ++- ...oot-and-graftroot-complexity-reflowed-.xml | 13 +- ...bined_Taproot-and-graftroot-complexity.xml | 114 +++-- ...n-Re-Taproot-and-graftroot-complexity-.xml | 13 +- ...sign-for-Probabilistic-Partial-Pruning.xml | 85 ++-- ...norr-signatures-decentralized-identity.xml | 85 ++-- .../combined_BIP70-is-dead-What-now-.xml | 50 +- ...vation-mechanisms-decreasing-threshold.xml | 64 +-- ...lse-is-dangerous-and-shouldn-t-be-used.xml | 78 ++-- ...re-Open-blockchain-cryptographic-ASICs.xml | 106 +++-- ...Proposal-Bitcoin-Secure-Multisig-Setup.xml | 274 ++++++----- ...requested-transactions-in-Bitcoin-Core.xml | 43 +- ...ght-Flag-Day-Height-Taproot-Activation.xml | 120 +++-- .../Feb_2021/combined_Taproot-NACK.xml | 13 +- ...ting-2-Tuesday-16th-February-19-00-UTC.xml | 36 +- ...-A-CoinSwap-implementation-for-Bitcoin.xml | 29 +- ...ay-s-Taproot-activation-meeting-on-IRC.xml | 29 +- ...vation-meeting-on-lockinontimeout-LOT-.xml | 13 +- .../Feb_2021/combined_bip48-proposal.xml | 53 +-- ...tralized-BIP-47-payment-code-directory.xml | 5 +- ...CKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml | 5 +- ...ntentious-soft-fork-activation-attempt.xml | 5 +- ...ECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml | 5 +- .../Feb_2022/combined_Why-CTV-why-now-.xml | 5 +- ...ro-value-OP-RETURN-in-Payment-Protocol.xml | 13 +- ...ined_-BIP-Draft-BIP-Acceptance-Process.xml | 13 +- ...ft-Decentralized-Improvement-Proposals.xml | 13 +- ...mplementation-of-BIP102-as-a-softfork-.xml | 13 +- .../combined_BIP-Classification-Process.xml | 13 +- ...lock-nr-2016-for-hard-fork-activation-.xml | 13 +- ...e-0-12-0-release-candidate-1-available.xml | 13 +- ...city-increases-for-the-Bitcoin-system-.xml | 13 +- .../Jan_2016/combined_Fee-smoothing.xml | 13 +- ...mbined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml | 13 +- ...e-blocksize-as-a-generalized-softfork-.xml | 13 +- .../combined_Libconsensus-phase-2.xml | 13 +- ...BIP-editor-and-request-for-information.xml | 13 +- .../Jan_2016/combined_SegWit-GBT-updates.xml | 13 +- .../combined_SegWit-testnet-is-live.xml | 13 +- ...ned_Segregated-Witness-App-Development.xml | 13 +- .../combined_Segregated-Witness-BIPs.xml | 13 +- ...ed-witnesses-and-validationless-mining.xml | 13 +- ...pgrade-Procedures-Block-Extension-Data.xml | 13 +- ...ee-Month-bitcoin-dev-Moderation-Review.xml | 13 +- ...about-80-bit-collision-attacks-or-not-.xml | 13 +- ...mbined_What-is-OpenSSL-still-used-for-.xml | 13 +- .../combined_nSequence-multiple-uses.xml | 13 +- ...tion-serialization-would-it-be-useful-.xml | 13 +- ..._Anti-transaction-replay-in-a-hardfork.xml | 13 +- ...torical-and-future-projections-t-khan-.xml | 13 +- .../combined_BIP-Block75-New-algorithm.xml | 99 ++-- ...ombined_Bitcoin-Classic-1-2-0-released.xml | 13 +- ...ransaction-version-number-to-be-varint.xml | 13 +- ...ed-wallet-performance-and-SPV-security.xml | 256 ++++++----- ...ined_Extension-block-softfork-proposal.xml | 13 +- ...ental-network-with-a-new-header-format.xml | 13 +- .../combined_Mutli-push-op-return.xml | 13 +- .../combined_Script-Abuse-Potential-.xml | 13 +- .../combined_Three-hardfork-related-BIPs.xml | 176 ++++--- ...ombined_Transaction-Replacement-by-Fee.xml | 13 +- .../combined_2-step-confirmation-system.xml | 13 +- .../Jan_2018/combined_BIP-117-Feedback.xml | 85 ++-- ...guage-identifier-strings-for-wordlists.xml | 141 +++--- ...ty-For-Ordering-Transactions-In-Blocks.xml | 169 ++++--- .../Jan_2018/combined_Bech32-and-P2SH-.xml | 43 +- ...untary-Fork-Split-Proposal-Chaofan-Li-.xml | 13 +- ...ockchain-Voluntary-Fork-Split-Proposal.xml | 50 +- ...ng-BIP70-Payment-Protocol-from-Wallets.xml | 29 +- ...n-approaches-for-Signature-Aggregation.xml | 29 +- ...w-accurate-are-the-Bitcoin-timestamps-.xml | 71 +-- ...evel-language-targeting-Bitcoin-Script.xml | 36 +- .../Jan_2018/combined_Merge-of-protocol.xml | 29 +- ...ST-8202-Blockchain-Technology-Overview.xml | 71 +-- ...ned_New-Bitcoin-Core-macOS-signing-key.xml | 43 +- ...labs-secret-shared-private-key-scheme-.xml | 13 +- .../Jan_2018/combined_Proof-of-Loss.xml | 50 +- ...sal-rewarding-fees-to-next-block-miner.xml | 92 ++-- ...d_Proposal-to-reduce-mining-power-bill.xml | 57 ++- ...-datacarriersize-to-220-byte-or-higher.xml | 29 +- ...ilabs-secret-shared-private-key-scheme.xml | 255 ++++++---- ...ned_ScriptPubkey-consensus-translation.xml | 36 +- ...emove-word-from-BIP39-English-wordlist.xml | 13 +- ...rivacy-preserving-switchable-scripting.xml | 181 +++++--- ...Transaction-Merging-bip125-relaxation-.xml | 13 +- ...e-ssl-variant-to-opensource-org-x-MIT-.xml | 29 +- .../combined_Upgrading-PoW-algorithm.xml | 57 ++- ...from-the-signature-not-used-in-Segwit-.xml | 64 +-- ...-Simple-Proof-of-Reserves-Transactions.xml | 37 +- .../Jan_2019/combined_BIP39-seeds.xml | 69 +-- ...Contracting-Applications-eg-Lightning-.xml | 124 +++-- .../Jan_2019/combined_Contribution.xml | 29 +- ...fidential-Transactions-in-Bitcoin-Core.xml | 43 +- ...ee-in-ZkVM-a-variant-of-Taproot-G-root.xml | 29 +- ...ined_Proof-of-Stake-Bitcoin-Sidechains.xml | 120 +++-- ...ined_Safer-NOINPUT-with-output-tagging.xml | 158 +++---- ...ical-sender-receiver-coinjoin-protocol.xml | 120 +++-- ...et-Log-Contract-Protocol-Specification.xml | 36 +- ...ding-and-receiving-bitcoin-anonymously.xml | 29 +- ...han-transaction-in-the-Bitcoin-network.xml | 29 +- ...d_Coins-A-trustless-sidechain-protocol.xml | 169 ++++--- ...-want-to-rebuild-the-GUI-in-JavaScript.xml | 34 +- .../combined_Modern-Soft-Fork-Activation.xml | 106 +++-- ..._OP-CTV-Workshop-CFP-February-1st-2020.xml | 29 +- ...mbined_Onchain-fee-insurance-mechanism.xml | 36 +- ...uthenticating-source-output-PSBT-files.xml | 64 +-- .../bitcoin-dev/Jan_2020/combined_Payswap.xml | 29 +- ...urge-attacks-spin-on-sabotage-attacks-.xml | 71 +-- ...ecktemplateverify-and-number-of-inputs.xml | 29 +- ...-checksum-and-usage-for-segwit-address.xml | 71 +-- ...-wallets-and-advanced-Bitcoin-features.xml | 54 ++- ...re-Open-blockchain-cryptographic-ASICs.xml | 106 +++-- .../combined_New-PSBT-version-proposal.xml | 102 ++-- .../Jan_2021/combined_PayJoin-adoption.xml | 50 +- ...Proposal-for-new-disabletx-p2p-message.xml | 96 ++-- ...ft-Fork-via-Proof-of-Work-Fraud-Proofs.xml | 34 +- ...dlc-dev-CTV-dramatically-improves-DLCs.xml | 5 +- .../Jan_2022/combined_CTV-BIP-review.xml | 5 +- ...ntentious-soft-fork-activation-attempt.xml | 5 +- .../combined_BIP-151-use-of-HMAC-SHA512.xml | 13 +- .../July_2016/combined_BIP-151.xml | 13 +- ...combined_BIP-Number-Request-Open-Asset.xml | 13 +- .../combined_BIP-draft-HTLC-transactions.xml | 13 +- ...ombined_BIP-proposal-derived-mnemonics.xml | 13 +- ...Critical-Parts-of-Segwit-by-Peter-Todd.xml | 13 +- ...ed-wallet-performance-and-SPV-security.xml | 256 ++++++----- ...d_Holdup-on-Block-Alerts-Fraud-Proofs-.xml | 13 +- ...bined_Merkle-trees-and-mountain-ranges.xml | 13 +- ...d_Reasons-to-add-sync-flags-to-Bitcoin.xml | 13 +- ...tatus-updates-for-BIP-9-68-112-and-113.xml | 13 +- ...rd-address-format-for-timelocked-funds.xml | 36 +- ...ly-referring-to-confirmed-transactions.xml | 43 +- .../July_2017/combined_A-Segwit2x-BIP.xml | 162 ++++--- ...eded-for-Blind-Merge-Mined-drivechains.xml | 190 ++++---- ...-chaining-off-replaceable-transactions.xml | 85 ++-- .../combined_Drivechain-RfD-Follow-Up.xml | 13 +- ...t-based-vs-block-time-based-thresholds.xml | 113 +++-- ...ll-Network-Upgrade-Activated-by-Miners.xml | 183 ++++---- ...ined_The-Nuclear-Option-BIP148-MR-POWA.xml | 33 +- ..._UTXO-growth-scaling-solution-proposal.xml | 13 +- ...d_Updating-the-Scaling-Roadmap-Update-.xml | 13 +- .../combined_Updating-the-Scaling-Roadmap.xml | 207 ++++----- ...ned_how-to-disable-segwit-in-my-build-.xml | 13 +- ...ed_A-BIP-proposal-for-segwit-addresses.xml | 85 ++-- ...lementation-of-Electrum-Server-in-Rust.xml | 29 +- .../July_2018/combined_BIP-174-thoughts.xml | 397 +++++++++------- ...acy-Preserving-Transaction-Propagation.xml | 84 ++-- .../combined_BIP-sighash-noinput.xml | 253 +++++----- .../combined_Generalised-taproot.xml | 13 +- .../combined_Multiparty-signatures.xml | 197 ++++---- ...GHASH2-for-version-1-witness-programme.xml | 85 ++-- .../combined_Schnorr-signatures-BIP.xml | 232 ++++++---- .../July_2018/combined_Transaction-Coins.xml | 36 +- ...RI-scheme-with-optional-bech32-address.xml | 13 +- .../combined_Weekly-IRC-Meeting-Time-Poll.xml | 43 +- .../combined_bitcoin-transactions.xml | 43 +- ..._v0-16-1-test-bitcoin-fails-on-Deian-9.xml | 36 +- ...ombined_Absent-authors-and-BIP-updates.xml | 29 +- ...ing-checkpoint-to-the-Bitcoin-protocol.xml | 85 ++-- ...tant-Signer-Check-should-be-mentioned-.xml | 36 +- ...lobal-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml | 134 +++--- ...sable-Bloom-based-Filtering-by-default.xml | 176 ++++--- ...t-inflation-through-fractional-reserve.xml | 245 +++++++--- ...-to-sybil-attacks-using-fidelity-bonds.xml | 232 ++++++---- ...EBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml | 134 +++--- ...ns-to-BIP-174-for-Future-Extensibility.xml | 78 ++-- ...ipt-OP-Code-For-Public-Data-References.xml | 106 +++-- ...oof-Of-Stake-implementation-on-Bitcoin.xml | 162 ++++--- ...ombined_BIP-118-and-SIGHASH-ANYPREVOUT.xml | 113 +++-- ...ombined_BIP-draft-BIP32-Path-Templates.xml | 57 ++- ...ss-and-impact-on-bip-taproot-addresses.xml | 127 ++--- ...inSwap-Makers-Among-Custodial-Services.xml | 50 +- ...ed_Implementing-Investment-Aggregation.xml | 36 +- ...bined_Is-Bitcoin-mempool-synchronized-.xml | 29 +- ...rable-And-mention-of-Channel-Factories.xml | 36 +- .../July_2020/combined_MAD-HTLC.xml | 204 ++++---- ...Device-For-Smart-Transferable-Hardware.xml | 43 +- ...bined_Thoughts-on-soft-fork-activation.xml | 36 +- ...es-Input-Based-vs-Child-Pay-For-Parent.xml | 148 +++--- ...es-from-reaching-the-peers-dat-buckets.xml | 29 +- ...roposals-for-Output-Script-Descriptors.xml | 99 ++-- ...mprove-privacy-for-off-chain-protocols.xml | 43 +- ...tions-Per-Second-with-stronger-privacy.xml | 302 ++++++------ ...ECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml | 172 +++++-- ...heckSigFromStack-for-Arithmetic-Values.xml | 57 ++- ...NDESTINATION-an-alternative-to-OP-CTV-.xml | 161 +++++-- ...n-Paths-for-Single-Key-Taproot-Scripts.xml | 43 +- ...ed_Eltoo-Anyprevout-Baked-in-Sequences.xml | 57 ++- ...unt-as-a-function-of-total-input-value.xml | 100 ++-- ...shop-on-L2-onchain-support-and-wrap-up.xml | 29 +- ...bined_Multisig-Enhanced-Privacy-Scheme.xml | 29 +- ...eckSigFromStack-for-Arithmetic-Values-.xml | 57 ++- ...t-roll-out-Tuesday-July-20th-17-15-UTC.xml | 29 +- .../combined_Proof-of-reserves-recording.xml | 162 ++++--- .../combined_Taproot-Fields-for-PSBT.xml | 71 +-- ...ule-VASP-UID-and-bitcoin-URI-A-new-BIP.xml | 29 +- ...ECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml | 13 +- ...erivation-Paths-in-a-Single-Descriptor.xml | 5 +- ...community-process-to-specify-covenants.xml | 5 +- ...ngly-Tail-Emission-Is-Not-Inflationary.xml | 5 +- .../June_2016/combined_BIP-151-MITM.xml | 13 +- .../combined_BIP-151-use-of-HMAC-SHA512.xml | 13 +- .../June_2016/combined_BIP-151.xml | 13 +- .../combined_BIP-draft-Memo-server.xml | 13 +- ...xtension-of-witness-program-definition.xml | 13 +- ...he-State-Machine-Approach-to-Consensus.xml | 13 +- ...Critical-Parts-of-Segwit-by-Peter-Todd.xml | 13 +- ...re-proposed-BIP-extensions-to-BIP-0070.xml | 13 +- ...bined_Merkle-trees-and-mountain-ranges.xml | 13 +- ...r-P2WPKH-nested-in-P2SH-based-accounts.xml | 13 +- ...Lightning-invoice-payment-format-draft.xml | 43 +- ...Merkle-Roots-of-Annotated-Binary-Trees.xml | 92 ++-- ...ect-the-network-from-51-attacks-threat.xml | 36 +- ...stance-via-decentrilized-proof-of-work.xml | 47 +- ...eded-for-Blind-Merge-Mined-drivechains.xml | 190 ++++---- ...lient-Side-Filtering-for-Light-Clients.xml | 285 +++++++----- ...acy-Preserving-Transaction-Propagation.xml | 84 ++-- ...ned_BIP148-temporary-service-bit-1-27-.xml | 36 +- ...P149-timeout-why-so-far-in-the-future-.xml | 78 ++-- .../June_2017/combined_Bitcoin-pointers.xml | 29 +- ...ompatibility-Oriented-Omnibus-Proposal.xml | 71 +-- ...ined_Drivechain-Request-for-Discussion.xml | 259 +++++++---- .../combined_Drivechain-RfD-Follow-Up.xml | 13 +- ...hetical-2-MB-hardfork-to-follow-BIP148.xml | 106 +++-- ...-code-in-order-to-get-segwit-activated.xml | 141 +++--- ...ll-Network-Upgrade-Activated-by-Miners.xml | 183 ++++---- ...acks-make-BIP148-and-BIP149-untennable.xml | 162 ++++--- ...ed-soft-hard-fork-Request-For-Comments.xml | 219 +++++---- ...e-BIP148-chain-split-may-be-inevitable.xml | 57 ++- ...r-Activated-Soft-Fork-Split-Protection.xml | 218 +++++---- ...-activation-of-segwit-for-legacy-nodes.xml | 36 +- ...etterHash-Mining-Protocol-Replacements.xml | 36 +- ...ed_BIP-158-Flexibility-and-Filter-Size.xml | 435 ++++++++++-------- .../June_2018/combined_BIP-174-thoughts.xml | 397 +++++++++------- ...acy-Preserving-Transaction-Propagation.xml | 84 ++-- ...-proportional-to-block-transaction-sum.xml | 36 +- ...P039-How-to-add-a-Portuguese-wordlist-.xml | 29 +- .../June_2018/combined_BetterHash-status.xml | 29 +- ...isallow-insecure-use-of-SIGHASH-SINGLE.xml | 43 +- ...e-scripts-under-the-taproot-assumption.xml | 78 ++-- ...n-Bitcoin-is-that-something-plausible-.xml | 64 +-- ...ation-encoding-format-for-key-material.xml | 92 ++-- ...GHASH2-for-version-1-witness-programme.xml | 85 ++-- ...combined_Should-Graftroot-be-optional-.xml | 162 ++++--- .../combined_Testnet-block-generation.xml | 29 +- ...x-inclusion-proofs-without-a-soft-fork.xml | 92 ++-- ...ty-without-maintaining-a-full-UTXO-set.xml | 64 +-- ...ive-the-backend-of-Bitcoin-blockchain-.xml | 85 ++-- ...-for-Lightning-and-Off-Chain-Contracts.xml | 113 +++-- ...bined_-PROPOSAL-Emergency-RBF-BIP-125-.xml | 85 ++-- ...lternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml | 127 ++--- ...lobal-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml | 134 +++--- ...as-a-minimalistic-blind-signing-server.xml | 64 +-- ...-embedded-into-the-bitcoin-block-chain.xml | 50 +- ...t-inflation-through-fractional-reserve.xml | 245 +++++++--- ...eer-to-peer-message-transport-protocol.xml | 13 +- ...EBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml | 134 +++--- .../June_2019/combined_Taproot-proposal.xml | 183 ++++---- ...om-coredev-tech-Amsterdam-2019-meeting.xml | 29 +- ...ined_bitcoin-dev-Digest-Vol-49-Issue-8.xml | 13 +- .../June_2019/combined_testnet4.xml | 50 +- ...CKTEMPLATEVERIFY-Fee-Bumping-Operation.xml | 13 +- ...ined_Announcing-Bitcoin-Wallet-Tracker.xml | 29 +- .../combined_BIP-OP-CHECKTEMPLATEVERIFY.xml | 104 +++-- ...y-pegged-childchains-via-Proof-of-Burn.xml | 29 +- .../June_2020/combined_Blind-Statechains.xml | 36 +- ...eric-payment-pools-for-Fun-and-Privacy.xml | 71 +-- ...roving-Bitcoin-privacy-and-fungibility.xml | 169 ++++--- ...ased-accumulators-with-quick-insertion.xml | 13 +- ...inSwap-Makers-Among-Custodial-Services.xml | 50 +- ...bined_Is-Bitcoin-mempool-synchronized-.xml | 29 +- .../June_2020/combined_MAD-HTLC.xml | 204 ++++---- ...d_Question-about-PayJoin-effectiveness.xml | 43 +- ...-Counterparties-and-Competing-Interest.xml | 224 ++++----- .../combined_SAS-Succinct-Atomic-Swap.xml | 155 ++++--- .../combined_Stamping-transaction.xml | 57 ++- ...-specification-for-Succint-Atomic-Swap.xml | 64 +-- ...ned_Tainting-CoinJoin-PayJoin-CoinSwap.xml | 57 ++- ...ation-Attacks-on-the-Lightning-Network.xml | 85 ++-- ...bined_WabiSabi-Inside-Batched-CoinSwap.xml | 29 +- ...es-Input-Based-vs-Child-Pay-For-Parent.xml | 148 +++--- ...roposals-for-Output-Script-Descriptors.xml | 99 ++-- ...mprove-privacy-for-off-chain-protocols.xml | 43 +- ...PUT-is-now-SIGHASH-ANYPREVOUT-i-think-.xml | 29 +- ...tions-Per-Second-with-stronger-privacy.xml | 302 ++++++------ ...n-Paths-for-Single-Key-Taproot-Scripts.xml | 43 +- ...shop-on-L2-onchain-support-and-wrap-up.xml | 29 +- ...tes-a-spend-path-after-a-certain-block.xml | 92 ++-- ...ed_Opinion-on-proof-of-stake-in-future.xml | 13 +- ...Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml | 99 ++-- .../combined_Taproot-Fields-for-PSBT.xml | 71 +-- ...ersion-Signaling-for-softfork-upgrades.xml | 155 ++++--- ...Trinary-Version-Signaling-for-softfork.xml | 13 +- ...y-s-IRC-workshop-on-L2-onchain-support.xml | 50 +- ...IGHASH-ANYPREVOUT-and-Packing-Packages.xml | 57 ++- .../combined_Packaged-Transaction-Relay.xml | 5 +- ...ps-does-not-linearize-its-transactions.xml | 5 +- ...ined_bitcoin-dev-Digest-Vol-85-Issue-4.xml | 5 +- .../combined_BIP-2-promotion-to-Final.xml | 13 +- ...Status-comments-and-copyright-licenses.xml | 13 +- .../combined_BIP147-minor-error.xml | 13 +- ...ned_BIP75-Out-of-Band-Address-Exchange.xml | 13 +- ...ntees-Strong-not-Eventual-Consistency-.xml | 13 +- ...dfork-to-fix-difficulty-drop-algorithm.xml | 13 +- ...acy-Questionnaire-Mid-Year-2015-report.xml | 13 +- ...median-block-size-adaptive-block-size-.xml | 13 +- ...ned_Proposed-BIP-extension-to-BIP-0070.xml | 13 +- ...bined_Proposed-release-schedule-0-13-0.xml | 13 +- ...combined_Services-bit-for-xthin-blocks.xml | 13 +- ...ned_bitcoin-dev-Digest-Vol-10-Issue-13.xml | 13 +- ...onsensus-rule-change-for-TX-fee-safety.xml | 13 +- ...p2p-authentication-and-encryption-BIPs.xml | 13 +- ...ed_A-BIP-proposal-for-segwit-addresses.xml | 85 ++-- .../combined_A-Better-MMR-Definition.xml | 218 +++++---- ...-UTXO-set-Balances-file-data-structure.xml | 47 +- ...and-LN-w-node-relay-network-topography.xml | 29 +- ...g-proportional-to-block-size-fee-pool-.xml | 57 ++- ...ed-wallet-performance-and-SPV-security.xml | 256 ++++++----- ...Currency-exchange-rate-information-API.xml | 113 +++-- ...-blocks-from-malicious-miner-takeover-.xml | 166 ++++--- .../combined_Encouraging-good-miners.xml | 71 +-- ...combined_Flag-day-activation-of-segwit.xml | 85 ++-- ...ned_Fraud-proofs-for-block-size-weight.xml | 64 +-- ...fork-proposal-from-last-week-s-meeting.xml | 13 +- ...fork-system-for-scaling-without-limits.xml | 36 +- .../combined_High-fees-centralization.xml | 71 +-- .../combined_Inquiry-Transaction-Tiering.xml | 141 +++--- .../combined_Issolated-Bitcoin-Nodes.xml | 64 +-- ...otecting-Bitcoin-from-malicious-miners.xml | 120 +++-- ...ds-user-activated-soft-fork-activation.xml | 141 +++--- ...g-solution-for-a-post-segwit-hard-fork.xml | 43 +- ..._Refund-Excesss-Fee-Hard-Fork-Proposal.xml | 36 +- ...ement-for-pseudonymous-BIP-submissions.xml | 13 +- ...egated-witness-p2p-layer-compatibility.xml | 36 +- ...ed-soft-hard-fork-Request-For-Comments.xml | 219 +++++---- ...ze-by-bitcoin-network-protocol-itself-.xml | 57 ++- ...-Anti-Replay-via-Coinbase-Transactions.xml | 29 +- ...ed_Unique-node-identifiers-and-BIP150-.xml | 13 +- .../combined_Unique-node-identifiers.xml | 128 ++++-- ...bined_-sign-verify-message-replacement.xml | 127 ++--- .../March_2018/combined_BIP-117-Feedback.xml | 85 ++-- ...n-blockheader-stratum-mining-configure.xml | 13 +- ...-Reserved-nversion-bits-in-blockheader.xml | 37 +- ...proof-CT-as-basis-for-election-voting-.xml | 43 +- ...ed_Lookinf-for-issues-to-contribute-to.xml | 29 +- .../combined_Optimized-Header-Sync.xml | 57 ++- ...ombined_Revisiting-BIP-125-RBF-policy-.xml | 141 +++--- .../combined_Simple-lock-unlock-mechanism.xml | 57 ++- ...-Activation-Enforcement-w-o-Signaling-.xml | 43 +- ...orks-and-schnorr-signature-aggregation.xml | 71 +-- ...-Enhance-privacy-by-change-obfuscation.xml | 50 +- ...combined_version-relay-behavior-change.xml | 50 +- ...P-Proposal-The-Great-Consensus-Cleanup.xml | 140 +++++- .../combined_BIP-Symbol-for-satoshi.xml | 50 +- ...osal-Pay-to-Contract-BIP43-Application.xml | 57 ++- .../combined_BIP-proposal-addrv2-message.xml | 36 +- .../combined_BIP174-PSBT-extensions.xml | 36 +- ...mbined_Fortune-Cookies-to-Bitcoin-Seed.xml | 36 +- ...mbined_More-thoughts-on-NOINPUT-safety.xml | 148 +++--- ...sage-transport-protocol-former-BIP151-.xml | 50 +- ...d_Notice-List-Infrastructure-Migration.xml | 36 +- ...P-Proposal-The-Great-Consensus-Cleanup.xml | 13 +- ...y-with-the-receiver-of-the-transaction.xml | 50 +- ...-for-spam-and-other-abuse-with-an-HTLB.xml | 57 ++- .../combined_Privacy-literature-review.xml | 29 +- ...work-messages-from-Bitcoin-Core-BIP61-.xml | 169 ++++--- ...P-Proposal-The-Great-Consensus-Cleanup.xml | 13 +- .../March_2019/combined_Signet.xml | 13 +- ...n-pubkeys-more-secure-nonce-generation.xml | 54 ++- ...d_Block-solving-slowdown-question-poll.xml | 111 +++-- .../combined_Block-solving-slowdown.xml | 13 +- ...Hash-function-requirements-for-Taproot.xml | 50 +- ...Differential-Power-Analysis-in-BIP-340.xml | 36 +- ...hardware-wallets-and-airgapped-signers.xml | 13 +- ...anti-covert-channel-signing-techniques.xml | 85 ++-- ...rministic-Entropy-From-BIP32-Keychains.xml | 85 ++-- ...ng-BIP-322-message-signing-into-motion.xml | 50 +- ...nt-of-Failure-with-Seed-Phrase-Storage.xml | 54 ++- .../combined_Schnorr-sigs-vs-pairing-sigs.xml | 29 +- .../combined_Statechain-implementations.xml | 190 ++++---- ...y-23rd-March-19-00-UTC-every-fortnight.xml | 36 +- ...sign-for-Probabilistic-Partial-Pruning.xml | 85 ++-- .../combined_An-alternative-to-BIP-32-.xml | 78 ++-- ...-Datastore-for-Energy-Efficient-Mining.xml | 13 +- .../combined_BIP70-is-dead-What-now-.xml | 50 +- ...within-existing-rules-no-fork-required.xml | 57 ++- ...vation-mechanisms-decreasing-threshold.xml | 64 +-- ...lse-is-dangerous-and-shouldn-t-be-used.xml | 78 ++-- .../combined_MASF-true-LOT-informational.xml | 29 +- ...ase-for-flag-day-activation-of-taproot.xml | 120 +++-- ...-2021-Taproot-Activation-Meeting-Notes.xml | 13 +- .../combined_New-PSBT-version-proposal.xml | 102 ++-- ...SA-Taproot-loss-of-quantum-protections.xml | 206 +++++---- ...Proposal-for-new-disabletx-p2p-message.xml | 96 ++-- ...A-Taproot-loss-of-quantum-protections-.xml | 13 +- ..._Response-to-Rusty-Russell-from-Github.xml | 36 +- ...t-Hierarchy-for-Deterministic-Wallets-.xml | 13 +- ...ght-Flag-Day-Height-Taproot-Activation.xml | 120 +++-- .../March_2021/combined_Taproot-NACK.xml | 13 +- ...ng-on-IRC-Tuesday-16th-March-19-00-UTC.xml | 78 ++-- ...root-activation-proposal-Speedy-Trial-.xml | 17 +- ...arch-2nd-19-00-UTC-on-uasf-IRC-channel.xml | 50 +- ...vation-meeting-on-lockinontimeout-LOT-.xml | 13 +- ...erday-s-UASF-LOT-true-kick-off-meeting.xml | 36 +- ...d_Yet-another-Taproot-activation-logic.xml | 36 +- ...ed_activation-mechanism-considerations.xml | 36 +- ...tralized-BIP-47-payment-code-directory.xml | 5 +- ...CKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml | 5 +- ...combined_BIP-Number-Request-Open-Asset.xml | 13 +- .../May_2016/combined_BIP-OP-PRANDOM.xml | 13 +- ...mbined_Bip44-extension-for-P2SH-P2WSH-.xml | 13 +- ...ed-wallet-performance-and-SPV-security.xml | 256 ++++++----- .../combined_Compact-Block-Relay-BIP.xml | 13 +- .../combined_Making-AsicBoost-irrelevant.xml | 13 +- ...th-Low-Latency-Delayed-TXO-Commitments.xml | 13 +- .../combined_Proposal-to-update-BIP-32.xml | 13 +- ...eterogeneous-Input-Script-Transactions.xml | 13 +- ...p2p-authentication-and-encryption-BIPs.xml | 13 +- ...and-multi-sender-coinjoin-transactions.xml | 13 +- ...ly-referring-to-confirmed-transactions.xml | 43 +- ...ed_A-BIP-proposal-for-segwit-addresses.xml | 85 ++-- ...Merkle-Roots-of-Annotated-Binary-Trees.xml | 92 ++-- ...eintroduce-the-disabled-script-opcodes.xml | 57 ++- ...P-Block-signal-enforcement-via-tx-fees.xml | 134 +++--- ...ver-specified-Proof-of-Work-challenges.xml | 43 +- ...osal-NODE-NETWORK-LIMITED-service-bits.xml | 64 +-- ...P149-timeout-why-so-far-in-the-future-.xml | 78 ++-- ...ombined_Barry-Silbert-segwit-agreement.xml | 106 +++-- ...ed_Combining-SPV-and-Stealth-addresses.xml | 36 +- ...ompatibility-Oriented-Omnibus-Proposal.xml | 71 +-- ...ined_Drivechain-Request-for-Discussion.xml | 259 +++++++---- ...-a-partial-mitigation-of-CVE-2017-9230.xml | 99 ++-- ...ension-block-proposal-by-Jeffrey-et-al.xml | 13 +- .../combined_Full-node-tip-function.xml | 124 ++--- ...hetical-2-MB-hardfork-to-follow-BIP148.xml | 106 +++-- ...ined_I-do-not-support-the-BIP-148-UASF.xml | 302 ++++++------ .../combined_Improvement-Proposal.xml | 29 +- .../combined_Network-layer-attacks.xml | 36 +- ...mbined_Non-confirming-block-signalling.xml | 13 +- ...eractive-Schnorr-signature-aggregation.xml | 43 +- ...ck-weight-based-on-a-support-threshold.xml | 36 +- ...tivation-of-existing-segwit-deployment.xml | 89 ++-- .../combined_Rolling-UTXO-set-hashes.xml | 85 ++-- ...s-A-Better-Alternative-to-Pruned-Nodes.xml | 183 ++++---- ...ults-about-the-current-Segwit-Discount.xml | 162 ++++--- .../combined_TXMempool-and-dirty-entries.xml | 29 +- ...s-do-not-need-a-soft-fork-to-be-useful.xml | 57 ++- .../combined_Transaction-signalling.xml | 64 +-- ...-ASICBOOST-as-a-Security-Vulnerability.xml | 64 +-- ...discuss-Checkpoints-in-the-Blockchain-.xml | 13 +- ...ed_BIP-158-Flexibility-and-Filter-Size.xml | 435 ++++++++++-------- ...acy-Preserving-Transaction-Propagation.xml | 84 ++-- .../May_2018/combined_BIP-sighash-noinput.xml | 253 +++++----- ...-proportional-to-block-transaction-sum.xml | 36 +- ...isallow-insecure-use-of-SIGHASH-SINGLE.xml | 43 +- ...e-decimal-places-for-lower-minimum-fee.xml | 29 +- ...mbined_MAST-Schnorr-related-soft-forks.xml | 43 +- .../combined_Making-OP-TRUE-standard-.xml | 197 ++++---- ...ng-the-redundancy-in-Golomb-Coded-Sets.xml | 50 +- ...g-away-from-BIP37-unsetting-NODE-BLOOM.xml | 29 +- ...-in-one-BIP32-derivation-path-new-BIP-.xml | 57 ++- ...ation-encoding-format-for-key-material.xml | 92 ++-- ...GHASH2-for-version-1-witness-programme.xml | 85 ++-- ...combined_Should-Graftroot-be-optional-.xml | 162 ++++--- .../combined_TXO-bitfield-size-graphs.xml | 36 +- ...ty-without-maintaining-a-full-UTXO-set.xml | 64 +-- ...ive-the-backend-of-Bitcoin-blockchain-.xml | 85 ++-- ...-for-Lightning-and-Off-Chain-Contracts.xml | 113 +++-- ...d-to-PSBT-to-make-multisig-more-secure.xml | 64 +-- ...lternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml | 127 ++--- ...via-OP-CHECKOUTPUTSHASHVERIFY-proposal.xml | 162 +++++-- .../May_2019/combined_IBLT-Bitcoin.xml | 29 +- .../May_2019/combined_IsStandard.xml | 99 ++-- ...-bets-without-an-oracle-and-3rd-party-.xml | 13 +- .../combined_SIGHASH-ANYPREVOUT-proposal.xml | 43 +- ...committing-only-to-transaction-outputs.xml | 36 +- .../May_2019/combined_Taproot-proposal.xml | 183 ++++---- ...-questions-about-segwit-implementation.xml | 85 ++-- ...ined_Announcing-Bitcoin-Wallet-Tracker.xml | 29 +- ...scriptPubKeys-in-the-signature-message.xml | 106 +++-- .../combined_Compressed-block-headers.xml | 43 +- ...roving-Bitcoin-privacy-and-fungibility.xml | 169 ++++--- ...hain-protocol-using-schnorr-signatures.xml | 106 +++-- ...NDARD-TX-NONWITNESS-SIZE-and-OP-RETURN.xml | 50 +- ...boarding-millions-of-LN-mobile-clients.xml | 232 ++++++---- ...ltisig-and-cpfp-in-bitcoin-core-wallet.xml | 57 ++- ...vault-a-multi-party-vault-architecture.xml | 29 +- .../combined_SAS-Succinct-Atomic-Swap.xml | 155 ++++--- .../combined_Statechain-implementations.xml | 190 ++++---- ...-specification-for-Succint-Atomic-Swap.xml | 64 +-- .../May_2020/combined_hashcash-newhash.xml | 92 ++-- ...es-Input-Based-vs-Child-Pay-For-Parent.xml | 148 +++--- ...tional-BIPs-related-to-other-proposals.xml | 43 +- .../combined_BIP-limiting-OP-RETURN-HF.xml | 190 ++++---- ...sus-protocol-immutability-is-a-feature.xml | 13 +- ...P39-mnemonic-without-changing-the-seed.xml | 50 +- .../combined_Fee-estimates-and-RBF.xml | 13 +- ...-Defect-in-Bitcoin-Core-s-bip125-logic.xml | 64 +-- ...n-alternate-proof-without-a-hard-fork-.xml | 71 +-- .../combined_Improvement-on-Blockbuilding.xml | 36 +- ...ed_Opinion-on-proof-of-stake-in-future.xml | 13 +- ...ombined_Prediction-Markets-and-Bitcoin.xml | 43 +- ...-9-minutes-to-save-90-of-mining-energy.xml | 13 +- ...mbined_Proposal-Low-Energy-Bitcoin-PoW.xml | 120 +++-- ...ined_Proposal-for-an-Informational-BIP.xml | 64 +-- ...ed_Reducing-block-reward-via-soft-fork.xml | 117 +++-- ...ined_Sum-of-the-keys-attack-on-taproot.xml | 36 +- ...eaking-tapscript-instead-of-public-key.xml | 29 +- ...ed_maximum-block-height-on-transaction.xml | 13 +- ...us-soft-fork-activations-are-attempted.xml | 5 +- ...bined_-BIP-Proposal-Buried-Deployments.xml | 13 +- ...n-arbitrary-and-or-combination-of-keys.xml | 13 +- ...as-Re-BIP-Proposal-Buried-Deployments-.xml | 13 +- .../combined_Flexible-Transactions-.xml | 13 +- ...enants-with-OP-CHECKSIGFROMSTACKVERIFY.xml | 13 +- ...Unlimited-Node-Deals-With-Large-Blocks.xml | 13 +- ...tralized-mapping-for-wallet-addresses-.xml | 99 ++-- .../combined_BIP-Idea-Marginal-Pricing.xml | 99 ++-- ...lient-Side-Filtering-for-Light-Clients.xml | 285 +++++++----- ...ORK-LIMITED-service-bits-extendability.xml | 43 +- ...itcoin-Cash-s-new-difficulty-algorithm.xml | 71 +-- .../Nov_2017/combined_Block-compression.xml | 40 +- .../combined_Centralizing-mining-by-force.xml | 43 +- ...eplay-Protection-for-Future-Hard-Forks.xml | 99 ++-- ..._Introducing-a-POW-through-a-soft-fork.xml | 85 ++-- ...ete-in-non-segwit-scripts-non-standard.xml | 57 ++- ...il-call-semantics-for-generalized-MAST.xml | 222 ++++++--- ...instead-of-wiki-page-to-BIP-discussion.xml | 29 +- .../combined_Protocol-Level-Pruning.xml | 43 +- ...ed_Simplicity-An-alternative-to-Script.xml | 99 ++-- .../combined_Simplicity-proposal-Jets-.xml | 13 +- ...n-Confidential-Transactions-efficiency.xml | 57 ++- .../Nov_2017/combined_Why-SegWit-Anyway-.xml | 85 ++-- ...BIP-Proposal-Address-Paste-Improvement.xml | 85 ++-- ...LIP-0039-better-multi-language-support.xml | 13 +- ...Contracting-Applications-eg-Lightning-.xml | 124 +++-- ...y-full-node-implementation-Any-advice-.xml | 13 +- ...ulti-party-Schnorr-Rust-implementation.xml | 50 +- ...shes-and-more-granular-SIGHASH-NOINPUT.xml | 184 +------- ...ility-through-wallet-interoperability-.xml | 36 +- .../combined_BIP-OP-CHECKTEMPLATEVERIFY.xml | 104 +++-- ...ss-and-impact-on-bip-taproot-addresses.xml | 127 ++--- .../combined_CVE-2017-18350-disclosure.xml | 50 +- .../Nov_2019/combined_Composable-MuSig.xml | 61 +-- .../combined_Draft-BIP-for-SNICKER.xml | 85 ++-- ...d_Dynamic-MaxBlockSize-3-Byte-Solution.xml | 78 ++-- ...-want-to-rebuild-the-GUI-in-JavaScript.xml | 34 +- ...PSBT-GLOBAL-XPUB-Version-bytes-in-xpub.xml | 29 +- ...Signing-CHECKSIG-position-in-Tapscript.xml | 57 ++- ...ed_Towards-a-singular-payment-protocol.xml | 43 +- .../Nov_2019/combined_v3-onion-services.xml | 78 ++-- ...prietary-and-PoR-fields-in-PSBT-BIP174.xml | 36 +- .../Nov_2020/combined_Bitcoin-Archaeology.xml | 43 +- ...bility-for-bitcoin-fungibility-markets.xml | 43 +- ...n-m-of-n-Schnorr-aggregated-signatures.xml | 29 +- ...l-specification-of-Miniscript-in-Alloy.xml | 36 +- .../combined_Out-of-band-transaction-fees.xml | 57 ++- ...32-for-future-Segwit-Versions-BIP-173-.xml | 183 ++++---- ...ombined_RFC-BIP-0002-Defer-not-reject-.xml | 29 +- .../Nov_2021/combined_A-fee-bumping-model.xml | 13 +- ...NDESTINATION-an-alternative-to-OP-CTV-.xml | 161 +++++-- ...rability-in-important-Bitcoin-projects.xml | 113 +++-- ...root-and-The-Evolution-of-BiPs-157-158.xml | 29 +- .../combined_Taproot-Fields-for-PSBT.xml | 71 +-- ...ed_Taproot-activates-A-time-block-line.xml | 29 +- ...-publish-unconfirmed-transactions-How-.xml | 17 +- ...-org-missing-bitcoin-core-version-22-0.xml | 106 +++-- ...ned_bitcoinj-fork-with-Taproot-support.xml | 13 +- ...h-to-the-mempool-long-live-the-mempool.xml | 113 +++-- ...ckage-RBF-againstpackage-limit-pinning.xml | 5 +- ...combined_On-mempool-policy-consistency.xml | 5 +- ...-BIP-125-Rule-3-Pinning-with-nLockTime.xml | 5 +- .../Oct_2016/combined_-no-subject-.xml | 13 +- ...d_1-Year-bitcoin-dev-Moderation-Review.xml | 13 +- .../Oct_2016/combined_About-ASICBoost.xml | 13 +- .../combined_BIP-2-revival-and-rework.xml | 13 +- ...mbined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml | 13 +- ...of-Blockchains-and-facilitate-scaling-.xml | 17 +- ...-unfounded-confidence-to-Bitcoin-users.xml | 13 +- ..._Defensive-Patent-License-Offer-Notice.xml | 13 +- ...rivechain-proposal-using-OP-COUNT-ACKS.xml | 13 +- ...n-going-work-Coin-Selection-Simulation.xml | 13 +- ...combined_Start-time-for-BIP141-segwit-.xml | 13 +- .../combined_The-Soft-Fork-Deception.xml | 13 +- ...or-paying-for-a-common-good-for-miners.xml | 13 +- ...ion-may-solve-Block-Withholding-Attack.xml | 36 +- ...n-Core-build-system-automake-vs-cmake-.xml | 36 +- ...-scaling-without-Miners-owning-our-BTC.xml | 134 +++--- ...ng-Scalability-via-Block-Time-Decrease.xml | 29 +- ...il-call-semantics-for-generalized-MAST.xml | 222 ++++++--- ...ed-for-SegWit2x-fork-reformatted-text-.xml | 82 ++-- ...mbined_New-difficulty-algorithm-part-2.xml | 57 ++- ...ed_Simplicity-An-alternative-to-Script.xml | 99 ++-- ...ersion-1-witness-programs-first-draft-.xml | 155 ++++--- ...ually-Differentiable-Bitcoin-Addresses.xml | 78 ++-- ...ned_bitcoin-dev-Digest-Vol-29-Issue-21.xml | 13 +- ...ned_bitcoin-dev-Digest-Vol-29-Issue-24.xml | 13 +- ...sal-Nym-Enrolment-Transaction-Template.xml | 29 +- ...ined_BIP-for-segwit-compatibility-URIs.xml | 50 +- .../combined_Bitcoin-Core-0-17-0-released.xml | 29 +- .../Oct_2018/combined_Generalised-taproot.xml | 13 +- ...combined_MultiSig-request-URI-proposal.xml | 29 +- ..._Request-OP-CHECKTXOUTSCRIPTHASHVERIFY.xml | 43 +- ...bined_Transaction-Input-Output-Sorting.xml | 64 +-- ...better-definition-of-the-term-address-.xml | 92 ++-- ..._Block-Batch-Filters-for-Light-Clients.xml | 13 +- ...Contracting-Applications-eg-Lightning-.xml | 124 +++-- .../combined_Chain-width-expansion.xml | 134 +++--- ...ent-loss-of-funds-by-physical-violence.xml | 29 +- ...he-discussion-about-noinput-anyprevout.xml | 228 ++++++--- .../combined_Draft-BIP-for-SNICKER.xml | 85 ++-- ...Human-readable-format-for-private-keys.xml | 29 +- .../Oct_2019/combined_Is-Signet-Bitcoin-.xml | 36 +- ...he-discussion-about-noinput-anyprevout.xml | 13 +- ...EBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml | 134 +++--- .../combined_PSBT-global-key-for-network.xml | 29 +- ...work-messages-from-Bitcoin-Core-BIP61-.xml | 169 ++++--- ...ing-support-for-addr-relay-revision-1-.xml | 29 +- ...in-address-accounts-in-the-blockchain-.xml | 33 +- .../combined_Transition-to-post-quantum.xml | 99 ++-- ...ustless-hash-price-insurance-contracts.xml | 85 ++-- ...eriment-on-bitcoin-for-payroll-privacy.xml | 64 +-- ...ombined_BIP-draft-BIP32-Path-Templates.xml | 57 ++- ...d-multi-transaction-CoinSwap-appendium.xml | 13 +- ...ined_Floating-Point-Nakamoto-Consensus.xml | 176 ++++--- ...combined_Is-BIP32-s-chain-code-needed-.xml | 50 +- ...ned_Progress-on-Miner-Withholding-FPNC.xml | 13 +- ...32-for-future-Segwit-Versions-BIP-173-.xml | 183 ++++---- ...ombined_RFC-BIP-0002-Defer-not-reject-.xml | 29 +- ...-problem-by-taking-timestamps-mod-2-32.xml | 29 +- ...BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml | 13 +- ...a-BIP157-server-BIP158-change-proposal.xml | 113 +++-- ...rability-in-important-Bitcoin-projects.xml | 113 +++-- ...mbined_On-the-regularity-of-soft-forks.xml | 90 ++-- ...Package-Mempool-Accept-and-Package-RBF.xml | 127 ++--- ...-every-mining-rig-attempt-every-block-.xml | 43 +- .../combined_Removing-the-Dust-Limit.xml | 266 ++++++----- ...or-feedback-on-approach-and-parameters.xml | 141 +++--- ..._TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml | 134 +++--- .../combined_Taproot-testnet-wallet.xml | 13 +- ...st-cases-for-Taproot-signature-message.xml | 50 +- ...Wednesday-s-second-BIP-process-meeting.xml | 13 +- ...38-problem-and-year-2106-chain-halting.xml | 120 +++-- ...ned_bitcoin-java-a-new-bitcoin-library.xml | 43 +- ...-org-missing-bitcoin-core-version-22-0.xml | 106 +++-- ...h-to-the-mempool-long-live-the-mempool.xml | 113 +++-- ...or-a-rational-one-re-rbf-Jeremy-Rubin-.xml | 5 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 5 +- ...community-process-to-specify-covenants.xml | 5 +- ...combined_On-mempool-policy-consistency.xml | 5 +- .../combined_Packaged-Transaction-Relay.xml | 5 +- ...rver-Outsourcing-handing-out-addresses.xml | 5 +- ...transactions-after-segwit-is-accepted-.xml | 13 +- .../combined_BIP-2-revival-and-rework.xml | 13 +- ...mbined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml | 13 +- ...ing-the-retirement-of-the-alert-system.xml | 13 +- ...purpose-of-Bitcoin-attested-timestamps.xml | 13 +- ...-IF-and-OP-NOTIF-malleability-in-P2WSH.xml | 13 +- ...-with-dummy-stack-element-malleability.xml | 13 +- ...mbined_New-BIP-Low-S-values-signatures.xml | 13 +- ...n-going-work-Coin-Selection-Simulation.xml | 13 +- ...-change-removing-OPL-licensing-option-.xml | 13 +- ...-BIP-assignment-Flexible-Transactions-.xml | 13 +- ...5-Retarget-Call-For-Proposals-Now-Open.xml | 13 +- ...ty-fix-opcode-proposal-OP-TXHASHVERIFY.xml | 13 +- ...-Proposal-Token-Protocol-Specification.xml | 50 +- .../combined_-Compressed-headers-stream.xml | 122 +++-- ...rks-to-cut-the-blockchain-and-IBD-time.xml | 29 +- ...ation-times-should-be-added-to-BIP-173.xml | 239 ++++++---- ...the-tail-call-and-MBV-approach-to-MAST.xml | 29 +- ...acy-Preserving-Transaction-Propagation.xml | 84 ++-- ...osal-Pay-to-Contract-BIP43-Application.xml | 57 ++- ...mbined_BIP49-Derivation-scheme-changes.xml | 64 +-- .../Sept_2017/combined_Bitcoin-Assistance.xml | 64 +-- .../Sept_2017/combined_Fast-Merkle-Trees.xml | 13 +- ...combined_Fwd-Compressed-headers-stream.xml | 17 +- ...ication-of-drivechains-and-spv-proofs-.xml | 13 +- ...bined_Horizontal-scaling-of-blockchain.xml | 64 +-- ...il-call-semantics-for-generalized-MAST.xml | 222 ++++++--- ...ibit-unspendable-outputs-with-amount-0.xml | 29 +- ...Addresses-and-Uncompressed-Public-Keys.xml | 54 ++- ...d_Paper-Wallet-support-in-bitcoin-core.xml | 113 +++-- ...erialization-format-for-BIP-32-wallets.xml | 120 +++-- ...tended-serialization-format-for-BIP-32.xml | 13 +- ...bip32-version-bytes-for-segwit-scripts.xml | 13 +- ...atable-fees-incentive-safe-fee-markets.xml | 134 +++--- ...ombined_Responsible-disclosure-of-bugs.xml | 134 +++--- ...ng-BIP-2-to-expand-editorial-authority.xml | 57 ++- ...ibit-unspendable-outputs-with-amount-0.xml | 92 ++-- ...ication-of-drivechains-and-spv-proofs-.xml | 59 ++- .../combined_Sidechains-Mainstake.xml | 36 +- ...ndard-is-Insecure-Against-MITM-Attacks.xml | 13 +- ...l-call-semantics-for-generalized-MAST-.xml | 13 +- ...hetical-Could-soft-forks-be-prevented-.xml | 13 +- ...post-bitcoin-side-chain-implementation.xml | 57 ++- ...bined_idea-post-trimming-and-demurrage.xml | 64 +-- ..._proposal-extend-WIF-format-for-segwit.xml | 64 +-- ...in-core-dev-Bitcoin-Core-update-notice.xml | 13 +- ...hain-with-recent-history-plus-UTXO-Set.xml | 13 +- ...for-transactions-that-are-cancellable-.xml | 92 ++-- .../combined_BIP-sighash-noinput.xml | 253 +++++----- .../combined_Extending-BIP174-for-HTLCs.xml | 29 +- ...n-the-initial-notice-of-CVE-2018-17144.xml | 36 +- ...ds-a-more-censorship-resistant-outcome.xml | 33 +- ...ombined_Multisignature-for-bip-schnorr.xml | 50 +- .../Sept_2018/combined_Overhauled-BIP151.xml | 57 ++- ...hain-with-recent-history-plus-UTXO-Set.xml | 29 +- ...-BIP-322-Generic-Signed-Message-Format.xml | 29 +- ...GHASH2-for-version-1-witness-programme.xml | 85 ++-- ...ir-s-Secret-Sharing-for-Mnemonic-Codes.xml | 57 ++- .../combined_Schnorr-signatures-BIP.xml | 232 ++++++---- .../combined_Selfish-Mining-Prevention.xml | 13 +- ...on-for-a-universal-bitcoin-value-scale.xml | 64 +-- .../Sept_2018/combined_Testnet3-Reest.xml | 64 +-- ...RI-scheme-with-optional-bech32-address.xml | 13 +- ...ical-sender-receiver-coinjoin-protocol.xml | 120 +++-- ...d_-BIP-able-idea-Regular-testnet-reset.xml | 29 +- ..._Block-Batch-Filters-for-Light-Clients.xml | 13 +- ...he-discussion-about-noinput-anyprevout.xml | 228 ++++++--- .../combined_Draft-BIP-for-SNICKER.xml | 85 ++-- ...side-memory-network-to-bitcoin-for-ads.xml | 36 +- ...-reconciliation-based-protocols-Erlay-.xml | 29 +- ...d_PoW-fraud-proofs-without-a-soft-fork.xml | 64 +-- ...f-chain-and-on-chain-models-with-eltoo.xml | 64 +-- .../Sept_2019/combined_Taproot-proposal.xml | 183 ++++---- ...imelocks-and-Lightning-on-MimbleWimble.xml | 71 +-- ..._Transcripts-from-Scaling-Bitcoin-2019.xml | 29 +- ...e-TXID-Dependencies-for-Fee-Sponsoring.xml | 148 +++--- .../combined_BIP-OP-CHECKTEMPLATEVERIFY.xml | 104 +++-- ...t-Custom-Signets-and-Resetting-Testnet.xml | 29 +- ...-for-routed-multi-transaction-CoinSwap.xml | 177 ++++--- ...ined_Floating-Point-Nakamoto-Consensus.xml | 176 ++++--- ...combined_Is-BIP32-s-chain-code-needed-.xml | 50 +- ...lure-in-a-two-stage-transfer-protocol-.xml | 78 ++-- ...-problem-by-taking-timestamps-mod-2-32.xml | 29 +- ...bined_Taproot-and-graftroot-complexity.xml | 114 +++-- .../combined_reviving-op-difficulty.xml | 106 +++-- .../Sept_2021/combined_BIP-extensions.xml | 13 +- ...th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml | 13 +- ...oposal-for-a-decentralised-mining-pool.xml | 13 +- ...he-use-of-getblocktemplate-RPC-method-.xml | 29 +- .../combined_Drivechain-BIP-300-and-301.xml | 57 ++- ...old-hardwallet-with-proof-of-creation-.xml | 29 +- ...unt-as-a-function-of-total-input-value.xml | 100 ++-- ...o-avoid-errors-on-BTC-public-addresses.xml | 113 +++-- ...BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml | 32 +- ...rability-in-important-Bitcoin-projects.xml | 113 +++-- ..._Note-on-Sequence-Lock-Upgrades-Defect.xml | 64 +-- ...al-Auto-shutdown-as-5-year-fork-window.xml | 29 +- ...Package-Mempool-Accept-and-Package-RBF.xml | 127 ++--- ...few-IANA-mime-types-related-to-Bitcoin.xml | 64 +-- ...mbined_Reminder-on-the-Purpose-of-BIPs.xml | 13 +- .../combined_Removing-the-Dust-Limit.xml | 266 ++++++----- ...or-feedback-on-approach-and-parameters.xml | 141 +++--- ...oring-the-Merkle-Tree-in-a-compact-way.xml | 29 +- ..._TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml | 134 +++--- ...st-cases-for-Taproot-signature-message.xml | 50 +- ...P-Proposal-Wallet-Labels-Export-Format.xml | 5 +- ...community-process-to-specify-covenants.xml | 5 +- .../combined_Packaged-Transaction-Relay.xml | 5 +- ...d_Transcript-Online-Socratic-on-MuSig2.xml | 5 +- ...tr-coinjoin-implementation-using-nostr.xml | 5 +- 1118 files changed, 42048 insertions(+), 31509 deletions(-) diff --git a/static/bitcoin-dev/April_2016/combined_AsicBoost.xml b/static/bitcoin-dev/April_2016/combined_AsicBoost.xml index a4a934789e..5b0e1464d7 100644 --- a/static/bitcoin-dev/April_2016/combined_AsicBoost.xml +++ b/static/bitcoin-dev/April_2016/combined_AsicBoost.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - AsicBoost - 2023-08-01T18:02:58.906127+00:00 + 2025-09-26T15:37:30.393594+00:00 + python-feedgen Timo Hanke 2016-04-08 20:58:57+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - AsicBoost - 2023-08-01T18:02:58.906127+00:00 + 2025-09-26T15:37:30.393730+00:00 - On April 1, 2016, Timo Hanke announced a new algorithmic improvement to the Bitcoin mining process called AsicBoost. This improvement, outlined in a white paper, aims to reduce power consumption and increase mining efficiency by optimizing the Bitcoin mining algorithm. It can be applied to all types of mining hardware and chip designs.However, concerns have been raised about centralization due to the patenting of this improvement. Depending on the licensing model used, one manufacturer could potentially have exclusive rights, leading to greater centralization of mining power. Peter Todd has expressed concern over this issue and questioned how equal opportunity access to the improvement will be ensured for all ASIC designers and manufacturers.There is also debate regarding whether AsicBoost is purely a software-based improvement or if it can be utilized by modifying hardware. Marek Palatinus believes it is a software thing that cannot be detected from outside if a miner uses it or not. However, Mustafa Al-Bassam suggests that if the algorithm is patented in certain countries like China, it could lead to a geographical decentralization of miners.Despite the potential for patenting mining algorithms in specific countries, many argue that it would be ultimately pointless due to Bitcoin's decentralized nature and international economy. Additionally, the patenting of AsicBoost could cause a sudden increase in Bitcoin mines in countries where the algorithm is not patented, leading to a geographical decentralization of miners from countries like China.Overall, the announcement of AsicBoost by Timo Hanke has sparked discussions about its potential impact on mining efficiency, centralization concerns, and geographic decentralization of miners. The white paper describing the improvement can be found at http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf. 2016-04-08T20:58:57+00:00 + On April 1, 2016, Timo Hanke announced a new algorithmic improvement to the Bitcoin mining process called AsicBoost. This improvement, outlined in a white paper, aims to reduce power consumption and increase mining efficiency by optimizing the Bitcoin mining algorithm. It can be applied to all types of mining hardware and chip designs.However, concerns have been raised about centralization due to the patenting of this improvement. Depending on the licensing model used, one manufacturer could potentially have exclusive rights, leading to greater centralization of mining power. Peter Todd has expressed concern over this issue and questioned how equal opportunity access to the improvement will be ensured for all ASIC designers and manufacturers.There is also debate regarding whether AsicBoost is purely a software-based improvement or if it can be utilized by modifying hardware. Marek Palatinus believes it is a software thing that cannot be detected from outside if a miner uses it or not. However, Mustafa Al-Bassam suggests that if the algorithm is patented in certain countries like China, it could lead to a geographical decentralization of miners.Despite the potential for patenting mining algorithms in specific countries, many argue that it would be ultimately pointless due to Bitcoin's decentralized nature and international economy. Additionally, the patenting of AsicBoost could cause a sudden increase in Bitcoin mines in countries where the algorithm is not patented, leading to a geographical decentralization of miners from countries like China.Overall, the announcement of AsicBoost by Timo Hanke has sparked discussions about its potential impact on mining efficiency, centralization concerns, and geographic decentralization of miners. The white paper describing the improvement can be found at http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2016/combined_BIP-CPRKV-Check-private-key-verify.xml b/static/bitcoin-dev/April_2016/combined_BIP-CPRKV-Check-private-key-verify.xml index 121153d1c1..d2a61742a1 100644 --- a/static/bitcoin-dev/April_2016/combined_BIP-CPRKV-Check-private-key-verify.xml +++ b/static/bitcoin-dev/April_2016/combined_BIP-CPRKV-Check-private-key-verify.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP CPRKV: Check private key verify - 2023-08-01T17:50:26.142424+00:00 + 2025-09-26T15:37:36.732364+00:00 + python-feedgen jl2012 at xbt.hk 2016-04-18 19:03:07+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BIP CPRKV: Check private key verify - 2023-08-01T17:50:26.142424+00:00 + 2025-09-26T15:37:36.732543+00:00 - In a recent proposal on the bitcoin-dev mailing list, there was a suggestion to remove the OP_CHECKPRIVPUBPAIR opcode and replace it with OP_CAT and OP_CHECKSIGVERIFY. This proposal involves two parties, Bob and Alice, agreeing upon a random secret nonce, k, and calculating r in the same way as signing a transaction. The script consists of various operations such as SIZE, ADD, SWAP, CAT, CECHKSIGVERIFY, and CHECKSIG. This proposal is deemed useful for the lightning network. It is mentioned that a patch to the reference client may be coded up, but segregated witness is likely to take priority for soft-fork slot usage.On February 29th, 2016, Mats Jerratsch shared a link to a discussion on the bitcoin-dev mailing list from November 2015 regarding a Bitcoin Improvement Proposal (BIP) for Schnorr signatures. Jerratsch noted that this proposal is relevant to the Lightning Network and asked if there was a demand for coding up a patch to the reference client. However, it is also mentioned that segregated witness might be taking up any potential soft-fork slot.Another discussion on the bitcoin-dev mailing list revolves around the usefulness of a certain feature for the Lightning Network. This feature involves the creation of a non-standard script to execute a payment in an altcoin without requiring a new opcode. However, it is noted that this method will only work for coins that allow non-standard scripts, as it violates the standard output script assumption. There was initial focus on maintaining standard scripts on the altcoin, but the non-standard script approach is considered an improvement over the cut and choose method.In a previous email conversation on February 12, 2016, the possibility of creating a new opcode for an altcoin was discussed. However, it was later determined that the altcoin would only accept standard output scripts. As a result, the suggestion of paying to a non-standard script instead was considered an improvement over the previous method of cut and choose. It is mentioned that this approach would only work for coins that allow non-standard scripts. The focus then shifted to maintaining standard scripts on the altcoin.A new BIP draft proposed by Tier Nolan via the bitcoin-dev mailing list discusses using CLTV for cross-chain transfers. Many altcoins do not support CLTV, making the transfer insecure. Therefore, the proposed protocol doesn't require any new opcode and uses cut and choose to allow commitments to publish private keys. However, it is acknowledged that this protocol is clunky and not entirely secure. The proposed protocol involves four steps where Bob trades bitcoins for altcoins with Alice. The BIP CPRKV, Check Private Key Verify, allows outputs to be locked until a private key is published that matches a given public key. The BIP CPRKV is available on GitHub, and the email sender ensured the safety of their computer.The email conversation also explores the possibility of increasing the sigop count for a NOP without using segwit. It is determined that this would be a soft fork, as it makes previously allowed actions disallowed. The increased sigop count would be valid under both old and new rules, without requiring specific support on the altcoin. This allows the Bitcoin network to act as a trusted third party for safe use of channels on the altcoin, despite its malleability issues and lack of OP_CHECKLOCKTIMEVERIFY. In regards to seg-witness, the ideal scenario would be repurposing OP_NOP3 to work in both old and new scripts.Overall, these discussions among Bitcoin developers highlight various proposals and considerations regarding the use of CLTV for cross-chain transfers, the introduction of new opcodes, the improvement of scripting for the lightning network, and the potential impact on soft-fork slot usage. 2016-04-18T19:03:07+00:00 + In a recent proposal on the bitcoin-dev mailing list, there was a suggestion to remove the OP_CHECKPRIVPUBPAIR opcode and replace it with OP_CAT and OP_CHECKSIGVERIFY. This proposal involves two parties, Bob and Alice, agreeing upon a random secret nonce, k, and calculating r in the same way as signing a transaction. The script consists of various operations such as SIZE, ADD, SWAP, CAT, CECHKSIGVERIFY, and CHECKSIG. This proposal is deemed useful for the lightning network. It is mentioned that a patch to the reference client may be coded up, but segregated witness is likely to take priority for soft-fork slot usage.On February 29th, 2016, Mats Jerratsch shared a link to a discussion on the bitcoin-dev mailing list from November 2015 regarding a Bitcoin Improvement Proposal (BIP) for Schnorr signatures. Jerratsch noted that this proposal is relevant to the Lightning Network and asked if there was a demand for coding up a patch to the reference client. However, it is also mentioned that segregated witness might be taking up any potential soft-fork slot.Another discussion on the bitcoin-dev mailing list revolves around the usefulness of a certain feature for the Lightning Network. This feature involves the creation of a non-standard script to execute a payment in an altcoin without requiring a new opcode. However, it is noted that this method will only work for coins that allow non-standard scripts, as it violates the standard output script assumption. There was initial focus on maintaining standard scripts on the altcoin, but the non-standard script approach is considered an improvement over the cut and choose method.In a previous email conversation on February 12, 2016, the possibility of creating a new opcode for an altcoin was discussed. However, it was later determined that the altcoin would only accept standard output scripts. As a result, the suggestion of paying to a non-standard script instead was considered an improvement over the previous method of cut and choose. It is mentioned that this approach would only work for coins that allow non-standard scripts. The focus then shifted to maintaining standard scripts on the altcoin.A new BIP draft proposed by Tier Nolan via the bitcoin-dev mailing list discusses using CLTV for cross-chain transfers. Many altcoins do not support CLTV, making the transfer insecure. Therefore, the proposed protocol doesn't require any new opcode and uses cut and choose to allow commitments to publish private keys. However, it is acknowledged that this protocol is clunky and not entirely secure. The proposed protocol involves four steps where Bob trades bitcoins for altcoins with Alice. The BIP CPRKV, Check Private Key Verify, allows outputs to be locked until a private key is published that matches a given public key. The BIP CPRKV is available on GitHub, and the email sender ensured the safety of their computer.The email conversation also explores the possibility of increasing the sigop count for a NOP without using segwit. It is determined that this would be a soft fork, as it makes previously allowed actions disallowed. The increased sigop count would be valid under both old and new rules, without requiring specific support on the altcoin. This allows the Bitcoin network to act as a trusted third party for safe use of channels on the altcoin, despite its malleability issues and lack of OP_CHECKLOCKTIMEVERIFY. In regards to seg-witness, the ideal scenario would be repurposing OP_NOP3 to work in both old and new scripts.Overall, these discussions among Bitcoin developers highlight various proposals and considerations regarding the use of CLTV for cross-chain transfers, the introduction of new opcodes, the improvement of scripting for the lightning network, and the potential impact on soft-fork slot usage. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2016/combined_Bitcoin-Core-0-12-1-release-candidate-1-available.xml b/static/bitcoin-dev/April_2016/combined_Bitcoin-Core-0-12-1-release-candidate-1-available.xml index cb987a71f2..97e72ff1d5 100644 --- a/static/bitcoin-dev/April_2016/combined_Bitcoin-Core-0-12-1-release-candidate-1-available.xml +++ b/static/bitcoin-dev/April_2016/combined_Bitcoin-Core-0-12-1-release-candidate-1-available.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.12.1 release candidate 1 available - 2023-08-01T18:03:16.972271+00:00 + 2025-09-26T15:37:32.505000+00:00 + python-feedgen Wladimir J. van der Laan 2016-04-11 09:12:13+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.12.1 release candidate 1 available - 2023-08-01T18:03:16.972271+00:00 + 2025-09-26T15:37:32.505128+00:00 - Wladimir J. van der Laan has released an updated version of Bitcoin Core, rc2, following the previous release candidate, rc1, being deemed "DOA" in meeting minutes from Thursday. The binaries for the updated version can be found at https://bitcoin.org/bin/bitcoin-core-0.12.1/test.rc2/, while the source code is available on Github at https://github.com/bitcoin/bitcoin/tree/v0.12.1rc2.This new release candidate, 0.12.1rc2, includes the BIP9, BIP68, and BIP112 softfork, along with various bugfixes and updated translations. Detailed release notes for this version can be accessed at https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md. It is important to note that release candidates serve as test versions for releases, and if no critical problems are discovered, this release candidate will become the official 0.12.1 release.Additionally, the previous release candidate, 0.12.1rc1, is also available for testing purposes. The binaries for this version can be downloaded from https://bitcoin.org/bin/bitcoin-core-0.12.1/test.rc2/, and the corresponding source code can be found on Github under the signed tag at https://github.com/bitcoin/bitcoin/tree/v0.12.1rc1. The 0.12.1rc1 release candidate includes the BIP9, BIP68, and BIP112 softfork, bugfixes, and updated translations. Preliminary release notes for this version can be accessed at https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md.As with any software, it is important to report any bugs or issues encountered during testing. Users can report bugs using the issue tracker on Github at https://github.com/bitcoin/bitcoin/issues. By actively engaging with the Bitcoin community and contributing to bug reporting, users can help improve the quality and stability of future releases. 2016-04-11T09:12:13+00:00 + Wladimir J. van der Laan has released an updated version of Bitcoin Core, rc2, following the previous release candidate, rc1, being deemed "DOA" in meeting minutes from Thursday. The binaries for the updated version can be found at https://bitcoin.org/bin/bitcoin-core-0.12.1/test.rc2/, while the source code is available on Github at https://github.com/bitcoin/bitcoin/tree/v0.12.1rc2.This new release candidate, 0.12.1rc2, includes the BIP9, BIP68, and BIP112 softfork, along with various bugfixes and updated translations. Detailed release notes for this version can be accessed at https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md. It is important to note that release candidates serve as test versions for releases, and if no critical problems are discovered, this release candidate will become the official 0.12.1 release.Additionally, the previous release candidate, 0.12.1rc1, is also available for testing purposes. The binaries for this version can be downloaded from https://bitcoin.org/bin/bitcoin-core-0.12.1/test.rc2/, and the corresponding source code can be found on Github under the signed tag at https://github.com/bitcoin/bitcoin/tree/v0.12.1rc1. The 0.12.1rc1 release candidate includes the BIP9, BIP68, and BIP112 softfork, bugfixes, and updated translations. Preliminary release notes for this version can be accessed at https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md.As with any software, it is important to report any bugs or issues encountered during testing. Users can report bugs using the issue tracker on Github at https://github.com/bitcoin/bitcoin/issues. By actively engaging with the Bitcoin community and contributing to bug reporting, users can help improve the quality and stability of future releases. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2016/combined_Proposal-to-update-BIP-32.xml b/static/bitcoin-dev/April_2016/combined_Proposal-to-update-BIP-32.xml index d0cb3a864d..675bb55fc0 100644 --- a/static/bitcoin-dev/April_2016/combined_Proposal-to-update-BIP-32.xml +++ b/static/bitcoin-dev/April_2016/combined_Proposal-to-update-BIP-32.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal to update BIP-32 - 2023-08-01T18:03:45.159425+00:00 + 2025-09-26T15:37:34.617840+00:00 + python-feedgen Gregory Maxwell 2016-05-08 11:09:45+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Proposal to update BIP-32 - 2023-08-01T18:03:45.159425+00:00 + 2025-09-26T15:37:34.618013+00:00 - On May 8, 2016, Pavol Rusnak reached out to the bitcoin-dev mailing list seeking Sipa's opinion on a proposed fix. Marek Palatinus also requested Sipa's input and expressed support for the proposal. However, since Sipa had not been active on the mailing list, he did not receive the message.In an email exchange between Eric Lombrozo and Jochen Hoenicke, they discussed the probability of a specific case of BIP32 triggering. They concluded that the likelihood of it happening is incredibly small at 2^-128. While many have been using BIP32 for years, some app developers feel that dealing with this level of complexity is not worth the effort. However, if handling the case is easy to implement and isolate in program flow, Lombrozo would be in favor of implementing a solution. The idea is to handle the problem in the library so app developers don't have to worry about missing addresses or ignore the issue. This could be achieved by having the library retry instead of returning an error.On April 21, 2016, Eric Lombrozo raised a concern on bitcoin-dev regarding the handling of cases where the BIP-32 derivation path is invalid. This issue is further complicated by limited software performing these checks. Additionally, even if a check is performed, handling the exception can be challenging as skipping may not always be an option. The motivation behind addressing this issue is to enable BIP-32 usage for non-secp256k1 curves such as the NIST P-256 curve with a chance of 2^-32. An example of an invalid BIP-32 path was found by Jochen at m/28578'/33941 derived from a hexadecimal seed.Jochen Hoenicke proposed an update to BIP-32, suggesting that if the computed hash is larger or equal to the prime or 0, the node should be considered invalid and skipped in the BIP-32 tree. He recommended modifying the procedure by repeating the hashing with slightly different input data until a valid private key is found. This way, the library will always return a valid node for all paths. Jochen believes that the chance of this affecting anyone is less than 10^-30 and that backward compatibility issues are minimal. However, many app developers feel that dealing with this complexity may not be worth the effort. Nevertheless, if the handling of this case is simple to implement and isolate in the program flow, Jochen is in favor of making changes.The proposal suggests updating BIP-32 to make it easier for developers to use. Currently, the specification requires all callers of CKDpriv or CKDpub to check for errors when the computed hash is larger or equal to the prime or zero, and handle these errors appropriately. This places an additional burden on application developers instead of being able to handle it within the BIP-32 library. Furthermore, it is unclear how to proceed if an intermediate node is missing. The suggestion is to repeat the hashing with slightly different input data until a valid private key is found. This approach ensures that the library always returns a valid node for all paths, avoiding issues encountered with the original version. The proposal also includes suggestions for updating the derivation functions and root node derivation from the seed. While there may be minimal backward compatibility issues, the author believes that the benefits of the update outweigh any potential consequences. The post concludes with questions regarding how to update the BIP and which algorithm is preferred for implementation. 2016-05-08T11:09:45+00:00 + On May 8, 2016, Pavol Rusnak reached out to the bitcoin-dev mailing list seeking Sipa's opinion on a proposed fix. Marek Palatinus also requested Sipa's input and expressed support for the proposal. However, since Sipa had not been active on the mailing list, he did not receive the message.In an email exchange between Eric Lombrozo and Jochen Hoenicke, they discussed the probability of a specific case of BIP32 triggering. They concluded that the likelihood of it happening is incredibly small at 2^-128. While many have been using BIP32 for years, some app developers feel that dealing with this level of complexity is not worth the effort. However, if handling the case is easy to implement and isolate in program flow, Lombrozo would be in favor of implementing a solution. The idea is to handle the problem in the library so app developers don't have to worry about missing addresses or ignore the issue. This could be achieved by having the library retry instead of returning an error.On April 21, 2016, Eric Lombrozo raised a concern on bitcoin-dev regarding the handling of cases where the BIP-32 derivation path is invalid. This issue is further complicated by limited software performing these checks. Additionally, even if a check is performed, handling the exception can be challenging as skipping may not always be an option. The motivation behind addressing this issue is to enable BIP-32 usage for non-secp256k1 curves such as the NIST P-256 curve with a chance of 2^-32. An example of an invalid BIP-32 path was found by Jochen at m/28578'/33941 derived from a hexadecimal seed.Jochen Hoenicke proposed an update to BIP-32, suggesting that if the computed hash is larger or equal to the prime or 0, the node should be considered invalid and skipped in the BIP-32 tree. He recommended modifying the procedure by repeating the hashing with slightly different input data until a valid private key is found. This way, the library will always return a valid node for all paths. Jochen believes that the chance of this affecting anyone is less than 10^-30 and that backward compatibility issues are minimal. However, many app developers feel that dealing with this complexity may not be worth the effort. Nevertheless, if the handling of this case is simple to implement and isolate in the program flow, Jochen is in favor of making changes.The proposal suggests updating BIP-32 to make it easier for developers to use. Currently, the specification requires all callers of CKDpriv or CKDpub to check for errors when the computed hash is larger or equal to the prime or zero, and handle these errors appropriately. This places an additional burden on application developers instead of being able to handle it within the BIP-32 library. Furthermore, it is unclear how to proceed if an intermediate node is missing. The suggestion is to repeat the hashing with slightly different input data until a valid private key is found. This approach ensures that the library always returns a valid node for all paths, avoiding issues encountered with the original version. The proposal also includes suggestions for updating the derivation functions and root node derivation from the seed. While there may be minimal backward compatibility issues, the author believes that the benefits of the update outweigh any potential consequences. The post concludes with questions regarding how to update the BIP and which algorithm is preferred for implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2016/combined_p2p-authentication-and-encryption-BIPs.xml b/static/bitcoin-dev/April_2016/combined_p2p-authentication-and-encryption-BIPs.xml index f54bcffec0..311142a598 100644 --- a/static/bitcoin-dev/April_2016/combined_p2p-authentication-and-encryption-BIPs.xml +++ b/static/bitcoin-dev/April_2016/combined_p2p-authentication-and-encryption-BIPs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - p2p authentication and encryption BIPs - 2023-08-01T18:00:13.282875+00:00 + 2025-09-26T15:37:28.284156+00:00 + python-feedgen Jonas Schnelli 2016-05-25 09:36:24+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - p2p authentication and encryption BIPs - 2023-08-01T18:00:13.282875+00:00 + 2025-09-26T15:37:28.284351+00:00 - The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, 2016-05-25T09:36:24+00:00 + The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml b/static/bitcoin-dev/April_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml index 09b75bf762..673f15a456 100644 --- a/static/bitcoin-dev/April_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml +++ b/static/bitcoin-dev/April_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - segwit subsidy and multi-sender (coinjoin) transactions - 2023-08-01T18:04:29.439589+00:00 + 2025-09-26T15:37:26.173862+00:00 + python-feedgen Peter Todd 2016-05-03 02:05:11+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - segwit subsidy and multi-sender (coinjoin) transactions - 2023-08-01T18:04:29.440590+00:00 + 2025-09-26T15:37:26.173998+00:00 - Kristov Atlas, a developer, has shared a sample of 16 transaction IDs from the BitcoinTalk thread on JoinMarket. These transactions reveal an average ratio of 1.38 outputs to inputs. Atlas points out that this situation is unsustainable because eventually the change needs to be combined again or else the unspent transaction outputs (UTXOs) will not get spent. However, the advantage of segwit discount for CoinJoin transactions is that it makes spending UTXOs cheaper and recovers funds that would otherwise be lost to dust.In a discussion on bitcoin-dev about the impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones, Kristov Atlas raises the question of whether this subsidy serves as a financial disincentive against CoinJoin transactions. It is noted that CoinJoin transactions do not necessitate any specific behavior that would be affected by this subsidy. Normal transactions spend a coin and create a payment of a specified amount along with change, and CoinJoins are no different in this regard. While users may sometimes split their outputs to enhance privacy, resulting in the "more outputs" effect, this alone does not increase costs under segwit. The total cost for a user to create an output paying themselves includes both the cost of creation and the eventual cost of spending it. Segwit's cost calculation improvements shift some relative cost from spending to creation, but the same users pay for both. It is important to consider where other transactions are when evaluating the output to input ratio for self-sends. For example, in block 409711, there is an average of 1.4647 outputs per input, although this figure varies across different blocks.Regarding the sample of the 16 transaction IDs posted in the JoinMarket thread on BitcoinTalk, which showed an average ratio of 1.38 outputs to inputs, it is pointed out that it is strange to state this as a fact right after providing data that disproves it. The author also requests that people refrain from discussing Schnorr signatures since they are not currently part of any immediate roadmap. However, it is mentioned that Schnorr signatures for Bitcoin have been in development for years and are one of the first proposed uses of segwit versioning. Schnorr multisignature signature aggregates would significantly reduce the cost of CoinJoin transactions, and if there were any disincentive, it would be eliminated by planned use of segwit versioning.The impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones has raised questions. This subsidy makes signature data, which does not affect the size of the unspent transaction output (UTXO) set, 75% cheaper than data that does impact the UTXO set size. The expectation is that users will prefer transactions that minimize the impact on the UTXO set in order to reduce fees, and developers will design new features that also minimize this impact. While this could potentially act as a disincentive against CoinJoin transactions, it remains unclear if there is any evidence to support this claim. It is worth noting that traditional CoinJoin transactions typically create around two UTXOs for every one they consume, unless address reuse is involved. The author emphasizes that they do not wish to discuss Schnorr signatures in replies, as they are not currently part of any immediate roadmap. 2016-05-03T02:05:11+00:00 + Kristov Atlas, a developer, has shared a sample of 16 transaction IDs from the BitcoinTalk thread on JoinMarket. These transactions reveal an average ratio of 1.38 outputs to inputs. Atlas points out that this situation is unsustainable because eventually the change needs to be combined again or else the unspent transaction outputs (UTXOs) will not get spent. However, the advantage of segwit discount for CoinJoin transactions is that it makes spending UTXOs cheaper and recovers funds that would otherwise be lost to dust.In a discussion on bitcoin-dev about the impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones, Kristov Atlas raises the question of whether this subsidy serves as a financial disincentive against CoinJoin transactions. It is noted that CoinJoin transactions do not necessitate any specific behavior that would be affected by this subsidy. Normal transactions spend a coin and create a payment of a specified amount along with change, and CoinJoins are no different in this regard. While users may sometimes split their outputs to enhance privacy, resulting in the "more outputs" effect, this alone does not increase costs under segwit. The total cost for a user to create an output paying themselves includes both the cost of creation and the eventual cost of spending it. Segwit's cost calculation improvements shift some relative cost from spending to creation, but the same users pay for both. It is important to consider where other transactions are when evaluating the output to input ratio for self-sends. For example, in block 409711, there is an average of 1.4647 outputs per input, although this figure varies across different blocks.Regarding the sample of the 16 transaction IDs posted in the JoinMarket thread on BitcoinTalk, which showed an average ratio of 1.38 outputs to inputs, it is pointed out that it is strange to state this as a fact right after providing data that disproves it. The author also requests that people refrain from discussing Schnorr signatures since they are not currently part of any immediate roadmap. However, it is mentioned that Schnorr signatures for Bitcoin have been in development for years and are one of the first proposed uses of segwit versioning. Schnorr multisignature signature aggregates would significantly reduce the cost of CoinJoin transactions, and if there were any disincentive, it would be eliminated by planned use of segwit versioning.The impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones has raised questions. This subsidy makes signature data, which does not affect the size of the unspent transaction output (UTXO) set, 75% cheaper than data that does impact the UTXO set size. The expectation is that users will prefer transactions that minimize the impact on the UTXO set in order to reduce fees, and developers will design new features that also minimize this impact. While this could potentially act as a disincentive against CoinJoin transactions, it remains unclear if there is any evidence to support this claim. It is worth noting that traditional CoinJoin transactions typically create around two UTXOs for every one they consume, unless address reuse is involved. The author emphasizes that they do not wish to discuss Schnorr signatures in replies, as they are not currently part of any immediate roadmap. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_A-Better-MMR-Definition.xml b/static/bitcoin-dev/April_2017/combined_A-Better-MMR-Definition.xml index a1bd7fdad0..01558e9592 100644 --- a/static/bitcoin-dev/April_2017/combined_A-Better-MMR-Definition.xml +++ b/static/bitcoin-dev/April_2017/combined_A-Better-MMR-Definition.xml @@ -1,95 +1,127 @@ - + 2 Combined summary - A Better MMR Definition - 2023-08-01T19:34:55.774037+00:00 - - praxeology_guy 2017-04-01 19:46:12+00:00 - - - praxeology_guy 2017-04-01 10:18:12+00:00 - - - Bram Cohen 2017-03-31 20:38:16+00:00 - - - Peter Todd 2017-03-01 22:31:01+00:00 - - - Peter Todd 2017-03-01 01:56:16+00:00 - - - Bram Cohen 2017-03-01 01:47:30+00:00 - - - Pieter Wuille 2017-02-28 23:24:28+00:00 - - - Bram Cohen 2017-02-28 23:10:16+00:00 - - - G. Andrew Stone 2017-02-28 16:43:29+00:00 - - - Bram Cohen 2017-02-25 06:23:20+00:00 - - - Peter Todd 2017-02-25 04:12:02+00:00 - - - Bram Cohen 2017-02-24 22:20:19+00:00 - - - Peter Todd 2017-02-24 04:36:13+00:00 - - - Bram Cohen 2017-02-24 03:32:43+00:00 - - - Peter Todd 2017-02-24 03:15:31+00:00 - - - Bram Cohen 2017-02-24 03:02:36+00:00 - - - Peter Todd 2017-02-24 02:58:11+00:00 - - - Bram Cohen 2017-02-24 02:50:10+00:00 - - - Peter Todd 2017-02-24 01:09:43+00:00 - - - Bram Cohen 2017-02-24 00:49:01+00:00 - - - Peter Todd 2017-02-23 23:51:05+00:00 - - - Bram Cohen 2017-02-23 23:13:43+00:00 - - - Peter Todd 2017-02-23 18:31:40+00:00 - - - G. Andrew Stone 2017-02-23 18:28:18+00:00 - - - Peter Todd 2017-02-23 18:19:29+00:00 - - - Chris Priest 2017-02-23 17:53:58+00:00 - - - Peter Todd 2017-02-23 07:41:37+00:00 - - - Bram Cohen 2017-02-23 03:07:08+00:00 - - - Peter Todd 2017-02-23 01:15:06+00:00 - + 2025-09-26T15:45:43.037756+00:00 + python-feedgen + + + [bitcoin-dev] A Better MMR Definition Peter Todd + 2017-02-23T01:15:00.000Z + + + Bram Cohen + 2017-02-23T03:07:00.000Z + + + Peter Todd + 2017-02-23T07:41:00.000Z + + + Chris Priest + 2017-02-23T17:53:00.000Z + + + Peter Todd + 2017-02-23T18:19:00.000Z + + + G. Andrew Stone + 2017-02-23T18:28:00.000Z + + + Peter Todd + 2017-02-23T18:31:00.000Z + + + Bram Cohen + 2017-02-23T23:13:00.000Z + + + Peter Todd + 2017-02-23T23:51:00.000Z + + + Bram Cohen + 2017-02-24T00:49:00.000Z + + + Peter Todd + 2017-02-24T01:09:00.000Z + + + Bram Cohen + 2017-02-24T02:50:00.000Z + + + Peter Todd + 2017-02-24T02:58:00.000Z + + + Bram Cohen + 2017-02-24T03:02:00.000Z + + + Peter Todd + 2017-02-24T03:15:00.000Z + + + Bram Cohen + 2017-02-24T03:32:00.000Z + + + Peter Todd + 2017-02-24T04:36:00.000Z + + + Bram Cohen + 2017-02-24T22:20:00.000Z + + + Peter Todd + 2017-02-25T04:12:00.000Z + + + Bram Cohen + 2017-02-25T06:23:00.000Z + + + G. Andrew Stone + 2017-02-28T16:43:00.000Z + + + Bram Cohen + 2017-02-28T23:10:00.000Z + + + Pieter Wuille + 2017-02-28T23:24:00.000Z + + + Bram Cohen + 2017-03-01T01:47:00.000Z + + + Peter Todd + 2017-03-01T01:56:00.000Z + + + Peter Todd + 2017-03-01T22:31:00.000Z + + + Bram Cohen + 2017-03-31T20:38:00.000Z + + + praxeology_guy + 2017-04-01T10:18:00.000Z + + + praxeology_guy + 2017-04-01T19:46:00.000Z + + @@ -119,13 +151,13 @@ - python-feedgen + 2 Combined summary - A Better MMR Definition - 2023-08-01T19:34:55.775036+00:00 + 2025-09-26T15:45:43.040747+00:00 - In an email exchange between Bram Cohen and Peter Todd, the concept of UTXO commitments and the use of merkle trees for proving the current state of an output were discussed. Todd suggested committing to the state of all transaction outputs with a merkle tree structure, while Cohen argued that MMRs seemed redundant with the actual blockchain history. However, they agreed on the main goal of UTXO commitments: making a compact proof that something is still in the UTXO set.There were concerns about the performance and scalability of implementing UTXO commitments, particularly due to the size of the txo set. Cohen believed that with appropriate format and implementation tricks, good enough performance could be achieved. The benefits and drawbacks of using MMRs were also discussed. Todd argued that MMRs were redundant because you could prove something is in the TXO or STXO set using the actual blockchain, while Cohen believed that UTXO commitments provided benefits in terms of proving block validity and preventing fraud.The importance of independent validation by full nodes and the potential issues of relying too heavily on proofs were also touched upon. Todd emphasized the need to consider MMRs on their own merits before comparing them to UTXO commitments.Another email conversation involved G. Andrew Stone asking about efficient nonexistence proofs in an insertion-ordered MMR. This proposal aimed to enhance the efficiency of non-existence proofs and improve TXO commitments. Additionally, there was a discussion about the definition of a prunable MMR for use in Bitcoin. The improved definition committed to the number of items in the tree implicitly, allowing for an efficient proof-of-tree-size by following the right-most nodes. The insertion-ordered MMR was seen as a way to enhance non-existence proofs and overall TXO commitments.Overall, these discussions highlighted the ongoing exploration of UTXO commitments and MMRs as potential solutions for improving the scalability, performance, and security of blockchain transactions. 2017-04-01T19:46:12+00:00 + In an email exchange between Bram Cohen and Peter Todd, the concept of UTXO commitments and the use of merkle trees for proving the current state of an output were discussed. Todd suggested committing to the state of all transaction outputs with a merkle tree structure, while Cohen argued that MMRs seemed redundant with the actual blockchain history. However, they agreed on the main goal of UTXO commitments: making a compact proof that something is still in the UTXO set.There were concerns about the performance and scalability of implementing UTXO commitments, particularly due to the size of the txo set. Cohen believed that with appropriate format and implementation tricks, good enough performance could be achieved. The benefits and drawbacks of using MMRs were also discussed. Todd argued that MMRs were redundant because you could prove something is in the TXO or STXO set using the actual blockchain, while Cohen believed that UTXO commitments provided benefits in terms of proving block validity and preventing fraud.The importance of independent validation by full nodes and the potential issues of relying too heavily on proofs were also touched upon. Todd emphasized the need to consider MMRs on their own merits before comparing them to UTXO commitments.Another email conversation involved G. Andrew Stone asking about efficient nonexistence proofs in an insertion-ordered MMR. This proposal aimed to enhance the efficiency of non-existence proofs and improve TXO commitments. Additionally, there was a discussion about the definition of a prunable MMR for use in Bitcoin. The improved definition committed to the number of items in the tree implicitly, allowing for an efficient proof-of-tree-size by following the right-most nodes. The insertion-ordered MMR was seen as a way to enhance non-existence proofs and overall TXO commitments.Overall, these discussions highlighted the ongoing exploration of UTXO commitments and MMRs as potential solutions for improving the scalability, performance, and security of blockchain transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_A-Small-Modification-to-Segwit.xml b/static/bitcoin-dev/April_2017/combined_A-Small-Modification-to-Segwit.xml index ed0bc395d0..b06ab53a96 100644 --- a/static/bitcoin-dev/April_2017/combined_A-Small-Modification-to-Segwit.xml +++ b/static/bitcoin-dev/April_2017/combined_A-Small-Modification-to-Segwit.xml @@ -1,131 +1,175 @@ - + 2 Combined summary - A Small Modification to Segwit - 2023-08-01T20:22:19.656223+00:00 - - Jimmy Song 2017-04-11 23:42:41+00:00 - - - Jorge Timón 2017-04-11 21:25:45+00:00 - - - Staf Verhaegen 2017-04-11 18:39:11+00:00 - - - Jimmy Song 2017-04-11 14:40:28+00:00 - - - Sancho Panza 2017-04-11 13:25:21+00:00 - - - Jorge Timón 2017-04-11 13:00:29+00:00 - - - Sancho Panza 2017-04-11 09:31:43+00:00 - - - Tom Zander 2017-04-11 07:59:33+00:00 - - - g 2017-04-11 02:39:32+00:00 - - - Erik Aronesty 2017-04-10 18:17:03+00:00 - - - g 2017-04-10 15:25:05+00:00 - - - Bram Cohen 2017-04-10 14:46:35+00:00 - - - Bram Cohen 2017-04-10 14:34:47+00:00 - - - Jorge Timón 2017-04-10 09:16:50+00:00 - - - Thomas Daede 2017-04-10 01:45:24+00:00 - - - Erik Aronesty 2017-04-10 00:20:49+00:00 - - - David Vorick 2017-04-09 23:51:29+00:00 - - - Jared Lee Richardson 2017-04-09 21:16:26+00:00 - - - Erik Aronesty 2017-04-09 18:44:47+00:00 - - - Jimmy Song 2017-04-09 14:01:01+00:00 - - - Jorge Timón 2017-04-09 11:48:27+00:00 - - - Jorge Timón 2017-04-09 11:46:22+00:00 - - - Jimmy Song 2017-04-08 22:26:25+00:00 - - - Jimmy Song 2017-04-08 22:19:11+00:00 - - - praxeology_guy 2017-04-08 20:38:43+00:00 - - - Eric Voskuil 2017-04-08 18:51:32+00:00 - - - praxeology_guy 2017-04-08 18:15:43+00:00 - - - Jorge Timón 2017-04-08 17:22:22+00:00 - - - Pavel Moravec 2017-04-08 16:38:03+00:00 - - - Jorge Timón 2017-04-08 16:27:48+00:00 - - - Timo Hanke 2017-04-08 16:19:01+00:00 - - - Jimmy Song 2017-04-08 16:16:05+00:00 - - - Luke Dashjr 2017-04-08 16:05:09+00:00 - - - Jimmy Song 2017-04-08 15:17:47+00:00 - - - Luke Dashjr 2017-04-08 14:59:12+00:00 - - - Jimmy Song 2017-04-08 14:35:30+00:00 - - - Pavel Moravec 2017-04-08 08:33:01+00:00 - - - Jimmy Song 2017-04-08 02:46:29+00:00 - - - praxeology_guy 2017-04-08 01:48:01+00:00 - - - Jimmy Song 2017-04-08 00:05:16+00:00 - - - Jimmy Song 2017-04-07 20:06:39+00:00 - + 2025-09-26T15:45:36.673977+00:00 + python-feedgen + + + [bitcoin-dev] A Small Modification to Segwit Jimmy Song + 2017-04-07T20:06:00.000Z + + + Jimmy Song + 2017-04-08T00:05:00.000Z + + + praxeology_guy + 2017-04-08T01:48:00.000Z + + + Jimmy Song + 2017-04-08T02:46:00.000Z + + + Pavel Moravec + 2017-04-08T08:33:00.000Z + + + Jimmy Song + 2017-04-08T14:35:00.000Z + + + Luke Dashjr + 2017-04-08T14:59:00.000Z + + + Jimmy Song + 2017-04-08T15:17:00.000Z + + + Luke Dashjr + 2017-04-08T16:05:00.000Z + + + Jimmy Song + 2017-04-08T16:16:00.000Z + + + Timo Hanke + 2017-04-08T16:19:00.000Z + + + Jorge Timón + 2017-04-08T16:27:00.000Z + + + Pavel Moravec + 2017-04-08T16:38:00.000Z + + + Jorge Timón + 2017-04-08T17:22:00.000Z + + + praxeology_guy + 2017-04-08T18:15:00.000Z + + + Eric Voskuil + 2017-04-08T18:51:00.000Z + + + praxeology_guy + 2017-04-08T20:38:00.000Z + + + Jimmy Song + 2017-04-08T22:19:00.000Z + + + Jimmy Song + 2017-04-08T22:26:00.000Z + + + Jorge Timón + 2017-04-09T11:46:00.000Z + + + Jorge Timón + 2017-04-09T11:48:00.000Z + + + Jimmy Song + 2017-04-09T14:01:00.000Z + + + Erik Aronesty + 2017-04-09T18:44:00.000Z + + + Jared Lee Richardson + 2017-04-09T21:16:00.000Z + + + David Vorick + 2017-04-09T23:51:00.000Z + + + Erik Aronesty + 2017-04-10T00:20:00.000Z + + + Thomas Daede + 2017-04-10T01:45:00.000Z + + + Jorge Timón + 2017-04-10T09:16:00.000Z + + + Bram Cohen + 2017-04-10T14:34:00.000Z + + + Bram Cohen + 2017-04-10T14:46:00.000Z + + + Unknown Author + 2017-04-10T15:25:00.000Z + + + Erik Aronesty + 2017-04-10T18:17:00.000Z + + + Unknown Author + 2017-04-11T02:39:00.000Z + + + Tom Zander + 2017-04-11T07:59:00.000Z + + + Sancho Panza + 2017-04-11T09:31:00.000Z + + + Jorge Timón + 2017-04-11T13:00:00.000Z + + + Sancho Panza + 2017-04-11T13:25:00.000Z + + + Jimmy Song + 2017-04-11T14:40:00.000Z + + + Staf Verhaegen + 2017-04-11T18:39:00.000Z + + + Jorge Timón + 2017-04-11T21:25:00.000Z + + + Jimmy Song + 2017-04-11T23:42:00.000Z + + @@ -167,13 +211,13 @@ - python-feedgen + 2 Combined summary - A Small Modification to Segwit - 2023-08-01T20:22:19.656223+00:00 + 2025-09-26T15:45:36.678080+00:00 - In a recent email thread on the Bitcoin-dev mailing list, there has been a debate over whether or not ASICBoost should be allowed or prevented completely. Jimmy Song questioned why end users of Bitcoin would want to change its policy to make their money more vulnerable to a 51% attack. He argued that while one company may have an advantage by using extra nonce space, the use of ASICBoosted hash rate will help secure the network against newer optimizations in the future.Song proposed a modification to Gregory Maxwell's proposal on ASICBoost, specifically regarding overt ASICBoost. Overt ASICBoost requires grinding on the version bits of the block header instead of the Merkle Root, which is more efficient and requires fewer resources. His proposal suggests changing the version bits in the header to a nonce-space so miners can use it for overt ASICBoost, while moving the 32-bits over to the Coinbase transaction as part of the witness commitment. This modification aims to make ASICBoost more useful to miners and appeal to their financial interests.Currently, overt ASICBoost is not allowed as it would be considered an attack on the network and cause harm similar to mining only empty blocks. However, there is some disagreement among participants about whether overt ASICBoost is already implicitly allowed on the network or not. Luke Dashjr refuted the claim that overt ASICBoost is allowed, stating that it would still be an attack on the network and cause harm.The email thread also discusses concerns and reservations about the proposed modification. Some participants express concerns about the vulnerability exploited by ASICBoost and the barrier of entry it creates for new mining chip manufacturers. Luke Dashjr suggests fixing the vulnerability entirely or changing the PoW algorithm to one that is more ASIC-friendly. However, he may not oppose Song's proposal if it gains better support than Segwit currently has, and concerns such as Bitfury and Canaan stating they can compete using ASICBoost and the patents being licensed freely to everyone are addressed.The conversation also revolves around the compatibility of the new optimization with overt ASICBoost and whether or not it should be allowed openly or hidden. There are potential legal implications, but those risks exist regardless of whether BIP-141 is modified. Adding the modification would explicitly allow overt ASICBoost. Concerns are raised about the advantage one company may have if they are the only ones using the extra nonce space, but market incentives are suggested to play a role in determining how quickly this would happen.There is also discussion about the feasibility of implementing the proposed changes. The current Stratum protocol does not support block version changing, so a new standard extension would need to be added to the mining protocol and pool operators would need to change their software. Additionally, all miners would have to update their firmware unless they already have compatible hardware. Until all miners update, the change could result in large differences in mining efficiency, potentially giving an advantage to larger mining operations.In conclusion, the email thread revolves around the debate over whether or not to allow overt ASICBoost and the proposed modification to BIP-141 to make ASICBoost more attractive to miners. There are concerns and reservations expressed by participants, and the feasibility of implementing the changes is discussed. The compatibility of the new optimization with overt ASICBoost is also a central point of the discussion, as well as the decision of whether to allow it openly or hide it. 2017-04-11T23:42:41+00:00 + In a recent email thread on the Bitcoin-dev mailing list, there has been a debate over whether or not ASICBoost should be allowed or prevented completely. Jimmy Song questioned why end users of Bitcoin would want to change its policy to make their money more vulnerable to a 51% attack. He argued that while one company may have an advantage by using extra nonce space, the use of ASICBoosted hash rate will help secure the network against newer optimizations in the future.Song proposed a modification to Gregory Maxwell's proposal on ASICBoost, specifically regarding overt ASICBoost. Overt ASICBoost requires grinding on the version bits of the block header instead of the Merkle Root, which is more efficient and requires fewer resources. His proposal suggests changing the version bits in the header to a nonce-space so miners can use it for overt ASICBoost, while moving the 32-bits over to the Coinbase transaction as part of the witness commitment. This modification aims to make ASICBoost more useful to miners and appeal to their financial interests.Currently, overt ASICBoost is not allowed as it would be considered an attack on the network and cause harm similar to mining only empty blocks. However, there is some disagreement among participants about whether overt ASICBoost is already implicitly allowed on the network or not. Luke Dashjr refuted the claim that overt ASICBoost is allowed, stating that it would still be an attack on the network and cause harm.The email thread also discusses concerns and reservations about the proposed modification. Some participants express concerns about the vulnerability exploited by ASICBoost and the barrier of entry it creates for new mining chip manufacturers. Luke Dashjr suggests fixing the vulnerability entirely or changing the PoW algorithm to one that is more ASIC-friendly. However, he may not oppose Song's proposal if it gains better support than Segwit currently has, and concerns such as Bitfury and Canaan stating they can compete using ASICBoost and the patents being licensed freely to everyone are addressed.The conversation also revolves around the compatibility of the new optimization with overt ASICBoost and whether or not it should be allowed openly or hidden. There are potential legal implications, but those risks exist regardless of whether BIP-141 is modified. Adding the modification would explicitly allow overt ASICBoost. Concerns are raised about the advantage one company may have if they are the only ones using the extra nonce space, but market incentives are suggested to play a role in determining how quickly this would happen.There is also discussion about the feasibility of implementing the proposed changes. The current Stratum protocol does not support block version changing, so a new standard extension would need to be added to the mining protocol and pool operators would need to change their software. Additionally, all miners would have to update their firmware unless they already have compatible hardware. Until all miners update, the change could result in large differences in mining efficiency, potentially giving an advantage to larger mining operations.In conclusion, the email thread revolves around the debate over whether or not to allow overt ASICBoost and the proposed modification to BIP-141 to make ASICBoost more attractive to miners. There are concerns and reservations expressed by participants, and the feasibility of implementing the changes is discussed. The compatibility of the new optimization with overt ASICBoost is also a central point of the discussion, as well as the decision of whether to allow it openly or hide it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_A-different-approach-to-define-and-understand-softforks-and-hardforks.xml b/static/bitcoin-dev/April_2017/combined_A-different-approach-to-define-and-understand-softforks-and-hardforks.xml index 8d4b3de612..920cb78880 100644 --- a/static/bitcoin-dev/April_2017/combined_A-different-approach-to-define-and-understand-softforks-and-hardforks.xml +++ b/static/bitcoin-dev/April_2017/combined_A-different-approach-to-define-and-understand-softforks-and-hardforks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A different approach to define and understand softforks and hardforks - 2023-08-01T20:16:11.877834+00:00 + 2025-09-26T15:46:23.101364+00:00 + python-feedgen Matt Corallo 2017-04-07 10:14:07+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - A different approach to define and understand softforks and hardforks - 2023-08-01T20:16:11.877834+00:00 + 2025-09-26T15:46:23.101546+00:00 - In a recent email on the bitcoin-dev mailing list, Johnson Lau has proposed a redefinition of the terminology surrounding hard and soft forks. Instead of focusing on changes to block validity, Lau suggests defining these terms based on software upgrade necessity and difficulty. Under this new system, soft forks would refer to consensus rule changes that non-upgraded software can still use, while hard forks would require upgraded software for proper functionality. Lau introduces the concept of "hardfork-ness," which represents a continuum between the two types of forks.According to Lau, this notion of hardfork-ness can be applied to various components of the Bitcoin network, including mining nodes, non-mining full nodes, fully validating wallets, and fake SPV wallets. The level of hardfork-ness can also be influenced by the costs associated with running a border node. For instance, certain consensus rule changes like BIP34, 65, 66, and CSV have minimal resource requirements, resulting in low hardfork-ness. On the other hand, proposals such as the extension block proposal pose high hardfork-ness for wallets because legacy wallets may experience sudden invalidation of transactions and need to resign them without any intention of double spending.Lau delves into other interesting scenarios, such as soft-hardforks, which entail miners mining empty blocks with zero rewards and placing the transaction merkle tree in the legacy coinbase. Although technically classified as softforks in terms of block validity, they function more like hardforks in practice. Additionally, Lau highlights the distinction between technically softforks, such as on-chain KYC, blacklist implementation, and account freezing, and their significant disruptive impact on user experience, making them akin to hardforks.Moreover, Lau emphasizes that both the Lightning Network and side chains do not necessitate consensus rule changes and have the potential to introduce new features without any hardfork-ness. These innovations offer opportunities for enhanced functionality within the Bitcoin ecosystem.Overall, Lau's proposal aims to redefine the terminology surrounding hard and soft forks based on software upgrade necessity and difficulty, introducing the concept of hardfork-ness as a continuum between the two. This approach allows for a more nuanced understanding of the impact and implications of various consensus rule changes within the Bitcoin network. 2017-04-07T10:14:07+00:00 + In a recent email on the bitcoin-dev mailing list, Johnson Lau has proposed a redefinition of the terminology surrounding hard and soft forks. Instead of focusing on changes to block validity, Lau suggests defining these terms based on software upgrade necessity and difficulty. Under this new system, soft forks would refer to consensus rule changes that non-upgraded software can still use, while hard forks would require upgraded software for proper functionality. Lau introduces the concept of "hardfork-ness," which represents a continuum between the two types of forks.According to Lau, this notion of hardfork-ness can be applied to various components of the Bitcoin network, including mining nodes, non-mining full nodes, fully validating wallets, and fake SPV wallets. The level of hardfork-ness can also be influenced by the costs associated with running a border node. For instance, certain consensus rule changes like BIP34, 65, 66, and CSV have minimal resource requirements, resulting in low hardfork-ness. On the other hand, proposals such as the extension block proposal pose high hardfork-ness for wallets because legacy wallets may experience sudden invalidation of transactions and need to resign them without any intention of double spending.Lau delves into other interesting scenarios, such as soft-hardforks, which entail miners mining empty blocks with zero rewards and placing the transaction merkle tree in the legacy coinbase. Although technically classified as softforks in terms of block validity, they function more like hardforks in practice. Additionally, Lau highlights the distinction between technically softforks, such as on-chain KYC, blacklist implementation, and account freezing, and their significant disruptive impact on user experience, making them akin to hardforks.Moreover, Lau emphasizes that both the Lightning Network and side chains do not necessitate consensus rule changes and have the potential to introduce new features without any hardfork-ness. These innovations offer opportunities for enhanced functionality within the Bitcoin ecosystem.Overall, Lau's proposal aims to redefine the terminology surrounding hard and soft forks based on software upgrade necessity and difficulty, introducing the concept of hardfork-ness as a continuum between the two. This approach allows for a more nuanced understanding of the impact and implications of various consensus rule changes within the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_BIP-Proposal-Inhibiting-a-covert-optimization-on-the-Bitcoin-POW-function.xml b/static/bitcoin-dev/April_2017/combined_BIP-Proposal-Inhibiting-a-covert-optimization-on-the-Bitcoin-POW-function.xml index 9ab4ba5e62..ab4456cc12 100644 --- a/static/bitcoin-dev/April_2017/combined_BIP-Proposal-Inhibiting-a-covert-optimization-on-the-Bitcoin-POW-function.xml +++ b/static/bitcoin-dev/April_2017/combined_BIP-Proposal-Inhibiting-a-covert-optimization-on-the-Bitcoin-POW-function.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP Proposal: Inhibiting a covert optimization on the Bitcoin POW function - 2023-08-01T20:22:36.324178+00:00 - - Jan Čapek 2017-04-07 22:48:11+00:00 - - - Sergio Demian Lerner 2017-04-07 20:52:17+00:00 - + 2025-09-26T15:46:33.593329+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Inhibiting a covert optimization on the Bitcoin POW function Sergio Demian Lerner + 2017-04-07T20:52:00.000Z + + + Jan Čapek + 2017-04-07T22:48:00.000Z + + - python-feedgen + 2 Combined summary - BIP Proposal: Inhibiting a covert optimization on the Bitcoin POW function - 2023-08-01T20:22:36.324178+00:00 + 2025-09-26T15:46:33.593799+00:00 - Sergio Demian Lerner has proposed a new Bitcoin consensus rule to prevent the covert use of an optimization in the Bitcoin Proof of Work function. This optimization, known as ASICBOOST, allows miners to save up to 30% of their energy costs. The patent for ASICBOOST was applied for by Timo Hanke and Sergio Demian Lerner, and it is being offered for licensing by Sunrise Tech Group.There are two ways to take advantage of this optimization: one that is highly detectable and another that interferes with the Bitcoin protocol. The covert mechanism is not easily detected unless it interferes with the protocol. The use of this optimization could result in significant financial gain, depending on the research, investment, and effort put into designing improved cores.However, the potential for covert use and interference with improvements poses a danger to the Bitcoin system. To address this, the proposed rule aims to block the final optimization of ASICBOOST. This optimization involves computing a square root number of candidates on the left and right sides of the hash tree using transaction permutation or substitution. By preventing this final optimization, the benefit of the optimization is substantially eroded.The proposed rule automatically sunsets if it is no longer needed due to the introduction of stronger rules or the acceptance of the version-grinding form. One way to avoid erroneous warning messages when miners use the overt version of ASICBOOST is by reconsidering a rejected BIP (Bitcoin Improvement Proposal) that was proposed several years ago. This BIP aimed to deter covert use of the optimization but was previously rejected.In summary, the proposal aims to inhibit the covert use of the ASICBOOST optimization in the Bitcoin Proof of Work function. The authors applied for a patent for this optimization, and there are two ways to take advantage of it. However, its use poses a danger to the Bitcoin system. The proposed rule blocks the final optimization of ASICBOOST, and it automatically sunsets if no longer needed. Reconsidering a rejected BIP could help avoid erroneous warning messages when miners use the overt version of the optimization. The document acknowledges Greg Maxwell for the original report that identified errors in the proposal. 2017-04-07T22:48:11+00:00 + Sergio Demian Lerner has proposed a new Bitcoin consensus rule to prevent the covert use of an optimization in the Bitcoin Proof of Work function. This optimization, known as ASICBOOST, allows miners to save up to 30% of their energy costs. The patent for ASICBOOST was applied for by Timo Hanke and Sergio Demian Lerner, and it is being offered for licensing by Sunrise Tech Group.There are two ways to take advantage of this optimization: one that is highly detectable and another that interferes with the Bitcoin protocol. The covert mechanism is not easily detected unless it interferes with the protocol. The use of this optimization could result in significant financial gain, depending on the research, investment, and effort put into designing improved cores.However, the potential for covert use and interference with improvements poses a danger to the Bitcoin system. To address this, the proposed rule aims to block the final optimization of ASICBOOST. This optimization involves computing a square root number of candidates on the left and right sides of the hash tree using transaction permutation or substitution. By preventing this final optimization, the benefit of the optimization is substantially eroded.The proposed rule automatically sunsets if it is no longer needed due to the introduction of stronger rules or the acceptance of the version-grinding form. One way to avoid erroneous warning messages when miners use the overt version of ASICBOOST is by reconsidering a rejected BIP (Bitcoin Improvement Proposal) that was proposed several years ago. This BIP aimed to deter covert use of the optimization but was previously rejected.In summary, the proposal aims to inhibit the covert use of the ASICBOOST optimization in the Bitcoin Proof of Work function. The authors applied for a patent for this optimization, and there are two ways to take advantage of it. However, its use poses a danger to the Bitcoin system. The proposed rule blocks the final optimization of ASICBOOST, and it automatically sunsets if no longer needed. Reconsidering a rejected BIP could help avoid erroneous warning messages when miners use the overt version of the optimization. The document acknowledges Greg Maxwell for the original report that identified errors in the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_BIP-draft-Extended-block-header-hardfork.xml b/static/bitcoin-dev/April_2017/combined_BIP-draft-Extended-block-header-hardfork.xml index 5ab13a5470..aeffdd7f41 100644 --- a/static/bitcoin-dev/April_2017/combined_BIP-draft-Extended-block-header-hardfork.xml +++ b/static/bitcoin-dev/April_2017/combined_BIP-draft-Extended-block-header-hardfork.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP draft: Extended block header hardfork - 2023-08-01T20:12:53.998107+00:00 - - Tom Zander 2017-04-04 16:17:02+00:00 - - - Jean-Paul Kogelman 2017-04-04 16:03:51+00:00 - - - Greg Sanders 2017-04-04 15:44:40+00:00 - - - Tom Zander 2017-04-04 15:32:47+00:00 - - - James Hilliard 2017-04-04 14:59:12+00:00 - - - Tom Zander 2017-04-04 11:47:57+00:00 - - - Johnson Lau 2017-04-03 03:36:13+00:00 - - - Russell O'Connor 2017-04-02 20:39:13+00:00 - - - Johnson Lau 2017-04-02 20:13:23+00:00 - + 2025-09-26T15:46:27.284005+00:00 + python-feedgen + + + [bitcoin-dev] BIP draft: Extended block header hardfork Johnson Lau + 2017-04-02T20:13:00.000Z + + + Russell O'Connor + 2017-04-02T20:39:00.000Z + + + Johnson Lau + 2017-04-03T03:36:00.000Z + + + Tom Zander + 2017-04-04T11:47:00.000Z + + + James Hilliard + 2017-04-04T14:59:00.000Z + + + Tom Zander + 2017-04-04T15:32:00.000Z + + + Greg Sanders + 2017-04-04T15:44:00.000Z + + + Jean-Paul Kogelman + 2017-04-04T16:03:00.000Z + + + Tom Zander + 2017-04-04T16:17:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - BIP draft: Extended block header hardfork - 2023-08-01T20:12:53.998107+00:00 + 2025-09-26T15:46:27.285074+00:00 - In a communication on the Bitcoin-dev mailing list, a developer named Tom Zander asked for clarification on where a specific rule is enforced in Bitcoin's code. James Hilliard responded by providing a link to BIP-0034, which outlines the consensus rule in question. Russell O'Connor suggested moving nHeight from the coinbase script to the coinbase locktime, but Tom Zander pointed out that this change would not require a consensus change and could be made at any time. Throughout the conversation, various links to relevant code were shared.The discussion centers around a consensus rule in Bitcoin, with Tom Zander trying to find where this rule is enforced in the code. However, he only finds code that checks for unknown or fully spent transaction IDs. This leads him to believe that a proposed change by Russell O'Connor, which moves nHeight from the coinbase script to the coinbase locktime, would not be rejected by a full client. James Hilliard responds with a link to BIP-0034, confirming that the current protocol operates under a consensus rule specified in the BIP. Any changes to this rule would require consensus among network participants.Russell O'Connor suggests moving nHeight from the coinbase script to the coinbase locktime, stating that it would be more natural. However, Tom Zander argues that such a change does not require consensus and can be implemented at any time. It is important to note that the current protocol operates under a consensus rule detailed in BIP-0034, which mandates the inclusion of a merkle root of all transactions in the block, including the coinbase transaction, in the block headers. Changes to this rule necessitate consensus among network participants.Russell O'Connor proposes a new approach to the coinbase transaction input, suggesting the use of the hash of the previous block instead of a hash of all zeroes in the coinbase script. He believes this change would enable payments to be made to a child of a specific block using a new SIGHASH design. O'Connor has already implemented this in his spoonnet2 branch and plans to describe it with a BIP soon. However, this proposal is separate from his goal of allowing people to know the height of a block through the extended header. The current proposal states that the witness of the first input of the coinbase transaction should contain bytes 0 to 3, representing the nHeight of the block in signed little endian format. While a suggestion is made to move nHeight to the coinbase locktime, O'Connor is exploring a different approach.On April 2, 2017, Johnson Lau sent an email to the bitcoin-dev mailing list discussing a proposed change to the Bitcoin protocol. The proposal suggests that the witness of the first input of the coinbase transaction should have exactly one stack item, referred to as the "extended header." This extended header would include data consisting of bytes 0 to 3, with nHeight representing the height of the block in signed little endian format. While someone suggests moving nHeight from the coinbase script to the coinbase locktime, Johnson Lau does not directly address this suggestion in their email.The proposed hardfork, called "spoonnet," aims to fulfill requested features for bitcoin businesses, including deterministic activation logic, strong and simple 2-way replay protection, wipe-out protection, and predictable resource use. The activation is based on flag day, as measuring community consensus on-chain is challenging. A reference implementation for consensus codes can be found at https://github.com/jl2012/bitcoin/tree/spoonnet2. The extended block header hardfork proposal seeks to provide a flexible and upgradable header format through a hardfork. The current Bitcoin protocol has a fixed 80-byte block header with no reserved space for additional data, which is not ideal for light clients. The proposed extended block header format aims to be easily upgradeable with softforks, compatible with the Stratum mining protocol, and have a deterministic hardfork activation. The hardfork employs a simple flag day deployment based on the median timestamp of previous blocks, ensuring a deterministic and permanent departure from the original rules. The witness field of the coinbase input is used to store the extended header, minimizing changes in the peer-to-peer protocol between full nodes. Committing to the block height allows determining the value before obtaining all parental headers. This hard forking change breaks compatibility with old full nodes and light nodes and should not be deployed without widespread consensus. Old full nodes consider the block header nVersion invalid, while light nodes may consider the hardfork chain as the best chain if it has the most total proof-of-work, but they will not see any transactions in the chain. The proposed hardfork specifies requirements such as signaling the most significant bit in the nVersion of the block header, enabling segregated witness, and replacing bytes 36 to 67 in the block header with the double SHA256 hash of the extended header. The special extheader softfork allows future 2017-04-04T16:17:02+00:00 + In a communication on the Bitcoin-dev mailing list, a developer named Tom Zander asked for clarification on where a specific rule is enforced in Bitcoin's code. James Hilliard responded by providing a link to BIP-0034, which outlines the consensus rule in question. Russell O'Connor suggested moving nHeight from the coinbase script to the coinbase locktime, but Tom Zander pointed out that this change would not require a consensus change and could be made at any time. Throughout the conversation, various links to relevant code were shared.The discussion centers around a consensus rule in Bitcoin, with Tom Zander trying to find where this rule is enforced in the code. However, he only finds code that checks for unknown or fully spent transaction IDs. This leads him to believe that a proposed change by Russell O'Connor, which moves nHeight from the coinbase script to the coinbase locktime, would not be rejected by a full client. James Hilliard responds with a link to BIP-0034, confirming that the current protocol operates under a consensus rule specified in the BIP. Any changes to this rule would require consensus among network participants.Russell O'Connor suggests moving nHeight from the coinbase script to the coinbase locktime, stating that it would be more natural. However, Tom Zander argues that such a change does not require consensus and can be implemented at any time. It is important to note that the current protocol operates under a consensus rule detailed in BIP-0034, which mandates the inclusion of a merkle root of all transactions in the block, including the coinbase transaction, in the block headers. Changes to this rule necessitate consensus among network participants.Russell O'Connor proposes a new approach to the coinbase transaction input, suggesting the use of the hash of the previous block instead of a hash of all zeroes in the coinbase script. He believes this change would enable payments to be made to a child of a specific block using a new SIGHASH design. O'Connor has already implemented this in his spoonnet2 branch and plans to describe it with a BIP soon. However, this proposal is separate from his goal of allowing people to know the height of a block through the extended header. The current proposal states that the witness of the first input of the coinbase transaction should contain bytes 0 to 3, representing the nHeight of the block in signed little endian format. While a suggestion is made to move nHeight to the coinbase locktime, O'Connor is exploring a different approach.On April 2, 2017, Johnson Lau sent an email to the bitcoin-dev mailing list discussing a proposed change to the Bitcoin protocol. The proposal suggests that the witness of the first input of the coinbase transaction should have exactly one stack item, referred to as the "extended header." This extended header would include data consisting of bytes 0 to 3, with nHeight representing the height of the block in signed little endian format. While someone suggests moving nHeight from the coinbase script to the coinbase locktime, Johnson Lau does not directly address this suggestion in their email.The proposed hardfork, called "spoonnet," aims to fulfill requested features for bitcoin businesses, including deterministic activation logic, strong and simple 2-way replay protection, wipe-out protection, and predictable resource use. The activation is based on flag day, as measuring community consensus on-chain is challenging. A reference implementation for consensus codes can be found at https://github.com/jl2012/bitcoin/tree/spoonnet2. The extended block header hardfork proposal seeks to provide a flexible and upgradable header format through a hardfork. The current Bitcoin protocol has a fixed 80-byte block header with no reserved space for additional data, which is not ideal for light clients. The proposed extended block header format aims to be easily upgradeable with softforks, compatible with the Stratum mining protocol, and have a deterministic hardfork activation. The hardfork employs a simple flag day deployment based on the median timestamp of previous blocks, ensuring a deterministic and permanent departure from the original rules. The witness field of the coinbase input is used to store the extended header, minimizing changes in the peer-to-peer protocol between full nodes. Committing to the block height allows determining the value before obtaining all parental headers. This hard forking change breaks compatibility with old full nodes and light nodes and should not be deployed without widespread consensus. Old full nodes consider the block header nVersion invalid, while light nodes may consider the hardfork chain as the best chain if it has the most total proof-of-work, but they will not see any transactions in the chain. The proposed hardfork specifies requirements such as signaling the most significant bit in the nVersion of the block header, enabling segregated witness, and replacing bytes 36 to 67 in the block header with the double SHA256 hash of the extended header. The special extheader softfork allows future - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_BIP-proposal-Generalized-version-bits-voting-bip-genvbvoting-.xml b/static/bitcoin-dev/April_2017/combined_BIP-proposal-Generalized-version-bits-voting-bip-genvbvoting-.xml index 6081d6ac60..eefce807c1 100644 --- a/static/bitcoin-dev/April_2017/combined_BIP-proposal-Generalized-version-bits-voting-bip-genvbvoting-.xml +++ b/static/bitcoin-dev/April_2017/combined_BIP-proposal-Generalized-version-bits-voting-bip-genvbvoting-.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP proposal: Generalized version bits voting (bip-genvbvoting) - 2023-08-01T20:13:29.959145+00:00 - - Sancho Panza 2017-04-08 21:58:43+00:00 - - - Thomas Kerin 2017-04-05 14:09:59+00:00 - - - Tom Zander 2017-04-05 10:08:51+00:00 - - - Sancho Panza 2017-04-04 19:28:38+00:00 - - - Luke Dashjr 2017-04-04 18:01:51+00:00 - - - Sancho Panza 2017-04-04 16:49:58+00:00 - - - Sancho Panza 2017-04-04 16:41:31+00:00 - - - Tom Zander 2017-04-04 11:16:08+00:00 - - - Sancho Panza 2017-04-03 09:06:02+00:00 - + 2025-09-26T15:46:08.352761+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting) Sancho Panza + 2017-04-03T09:06:00.000Z + + + Tom Zander + 2017-04-04T11:16:00.000Z + + + Sancho Panza + 2017-04-04T16:41:00.000Z + + + Sancho Panza + 2017-04-04T16:49:00.000Z + + + Luke Dashjr + 2017-04-04T18:01:00.000Z + + + Sancho Panza + 2017-04-04T19:28:00.000Z + + + Tom Zander + 2017-04-05T10:08:00.000Z + + + Thomas Kerin + 2017-04-05T14:09:00.000Z + + + Sancho Panza + 2017-04-08T21:58:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: Generalized version bits voting (bip-genvbvoting) - 2023-08-01T20:13:29.960147+00:00 + 2025-09-26T15:46:08.353789+00:00 - There is a need for coordination to activate soft and hard forks without much orphan risk to miners. For software to validate correctly, it is not opt-in. The continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening. This situation applies to soft forks as well. After activation, it depends on people running it, most notably miners, otherwise the soft-fork is no longer enforced leading to a hard fork. Awareness alone does not ensure full validation capability is retained during a soft fork. Therefore, these differences seem insignificant enough to merit treating soft and hard forks equal in terms of the coordination features afforded through the versionbits. Witness the long preparation time ahead of SegWit deployment for wallet providers, miners etc. to coordinate to support it on their systems.Miners are irrelevant when it comes to hardforks as they cannot make the process any smoother. While BIP9 can indicate censorship in a soft fork, a hard fork always requires nodes to upgrade to the version increasing the degrees of freedom of the system. Signaling is less useful here since the change is not opt-in and will require coordination, and the continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening. Miners became a convenient way to activate soft-forks but they can't ameliorate a HF transition in the way they can censor transactions without permission.In a post on the bitcoin-dev mailing list, Luke Dashjr discussed how BIP 9 provides a mechanism for miners to coordinate softforks, but not hardforks. He explained that miners are essentially irrelevant to hardforks and cannot make the process any smoother. Tom Zander asked for an explanation of how miners are irrelevant to non-soft fork upgrades.BIP 9 is a mechanism for coordinating softforks among miners in order to make the upgrade process smoother. It does not apply to hardforks as miners are essentially irrelevant to them and cannot make the process any smoother. However, there is no fundamental distinction between the role of miners in softforks and hardforks when it comes to proper coordination with the rest of the users in the system. BIP 9 can be used as a coordination mechanism for both softforks and hardforks, allowing miners to use versionbits to make the process smoother. BIP 9 is a useful tool that allows a determination of how much hashing power supports a particular fork proposal. Both soft and hard forks without support from the majority of miners place themselves at high risk. In general, every soft fork can result in a counter hardfork by those who are not aligned with its objectives, just like every hardfork can result in a counter softfork for the same reason by those opposed to it. This balances out the advantages and disadvantages of each type of fork and effectively puts them on a similar footing. Developers must still choose whether their feature is best deployed by softfork or hardfork, but introducing more flexibility into the signaling framework of BIP9 means it will be more useful for further developments - including a potential hardfork. Softforks are not required to use BIP 9, and even if they do, they are not required to use the recommended thresholds.On April 3, 2017, a Bitcoin developer named Sancho Panza wrote about the shortcomings of BIP 9 in an email to the bitcoin-dev mailing list. He noted that BIP 9 limits itself to backward-compatible changes, making it unsuitable for hard forks. However, others have pointed out that this is not a limitation of BIP 9 but rather an inherent feature of soft forks. BIP 9 provides a mechanism for miners to coordinate soft forks, but it is not useful for deploying hard forks.Additionally, Panza argued that the fixed 95% threshold in BIP 9 is not flexible enough to account for a "spectrum of contentiousness" and can allow small minorities to veto proposed changes, leading to stagnation. However, it should be noted that soft forks are not required to use BIP 9, and even if they do, they are not obligated to adhere to the recommended thresholds.In summary, while Panza identified certain issues with BIP 9, some argue that these problems are not unique to BIP 9 and that the limitations of soft forks are simply inherent to the technology. Additionally, soft forks are not bound to use the recommended thresholds in BIP 9.The email thread discusses a proposal that aims to add flexibility to the tallying window size of BIP9. The author plans to post a link to a more refined proposal on GitHub once elaboration is complete. The discussion revolves around the idea of retaining full compatibility with BIP9 for a certain version bit if users wish to do so. One participant suggests that it might not be possible to have a state machine without the variables in the 2017-04-08T21:58:43+00:00 + There is a need for coordination to activate soft and hard forks without much orphan risk to miners. For software to validate correctly, it is not opt-in. The continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening. This situation applies to soft forks as well. After activation, it depends on people running it, most notably miners, otherwise the soft-fork is no longer enforced leading to a hard fork. Awareness alone does not ensure full validation capability is retained during a soft fork. Therefore, these differences seem insignificant enough to merit treating soft and hard forks equal in terms of the coordination features afforded through the versionbits. Witness the long preparation time ahead of SegWit deployment for wallet providers, miners etc. to coordinate to support it on their systems.Miners are irrelevant when it comes to hardforks as they cannot make the process any smoother. While BIP9 can indicate censorship in a soft fork, a hard fork always requires nodes to upgrade to the version increasing the degrees of freedom of the system. Signaling is less useful here since the change is not opt-in and will require coordination, and the continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening. Miners became a convenient way to activate soft-forks but they can't ameliorate a HF transition in the way they can censor transactions without permission.In a post on the bitcoin-dev mailing list, Luke Dashjr discussed how BIP 9 provides a mechanism for miners to coordinate softforks, but not hardforks. He explained that miners are essentially irrelevant to hardforks and cannot make the process any smoother. Tom Zander asked for an explanation of how miners are irrelevant to non-soft fork upgrades.BIP 9 is a mechanism for coordinating softforks among miners in order to make the upgrade process smoother. It does not apply to hardforks as miners are essentially irrelevant to them and cannot make the process any smoother. However, there is no fundamental distinction between the role of miners in softforks and hardforks when it comes to proper coordination with the rest of the users in the system. BIP 9 can be used as a coordination mechanism for both softforks and hardforks, allowing miners to use versionbits to make the process smoother. BIP 9 is a useful tool that allows a determination of how much hashing power supports a particular fork proposal. Both soft and hard forks without support from the majority of miners place themselves at high risk. In general, every soft fork can result in a counter hardfork by those who are not aligned with its objectives, just like every hardfork can result in a counter softfork for the same reason by those opposed to it. This balances out the advantages and disadvantages of each type of fork and effectively puts them on a similar footing. Developers must still choose whether their feature is best deployed by softfork or hardfork, but introducing more flexibility into the signaling framework of BIP9 means it will be more useful for further developments - including a potential hardfork. Softforks are not required to use BIP 9, and even if they do, they are not required to use the recommended thresholds.On April 3, 2017, a Bitcoin developer named Sancho Panza wrote about the shortcomings of BIP 9 in an email to the bitcoin-dev mailing list. He noted that BIP 9 limits itself to backward-compatible changes, making it unsuitable for hard forks. However, others have pointed out that this is not a limitation of BIP 9 but rather an inherent feature of soft forks. BIP 9 provides a mechanism for miners to coordinate soft forks, but it is not useful for deploying hard forks.Additionally, Panza argued that the fixed 95% threshold in BIP 9 is not flexible enough to account for a "spectrum of contentiousness" and can allow small minorities to veto proposed changes, leading to stagnation. However, it should be noted that soft forks are not required to use BIP 9, and even if they do, they are not obligated to adhere to the recommended thresholds.In summary, while Panza identified certain issues with BIP 9, some argue that these problems are not unique to BIP 9 and that the limitations of soft forks are simply inherent to the technology. Additionally, soft forks are not bound to use the recommended thresholds in BIP 9.The email thread discusses a proposal that aims to add flexibility to the tallying window size of BIP9. The author plans to post a link to a more refined proposal on GitHub once elaboration is complete. The discussion revolves around the idea of retaining full compatibility with BIP9 for a certain version bit if users wish to do so. One participant suggests that it might not be possible to have a state machine without the variables in the - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_BIP-proposal-Inhibiting-a-covert-attack-on-the-Bitcoin-POW-function.xml b/static/bitcoin-dev/April_2017/combined_BIP-proposal-Inhibiting-a-covert-attack-on-the-Bitcoin-POW-function.xml index fc4a1f36eb..1696ab312e 100644 --- a/static/bitcoin-dev/April_2017/combined_BIP-proposal-Inhibiting-a-covert-attack-on-the-Bitcoin-POW-function.xml +++ b/static/bitcoin-dev/April_2017/combined_BIP-proposal-Inhibiting-a-covert-attack-on-the-Bitcoin-POW-function.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP proposal: Inhibiting a covert attack on the Bitcoin POW function - 2023-08-01T20:18:06.346495+00:00 + 2025-09-26T15:45:49.421199+00:00 + python-feedgen Erik Aronesty 2017-04-07 13:28:13+00:00 @@ -183,13 +184,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: Inhibiting a covert attack on the Bitcoin POW function - 2023-08-01T20:18:06.347495+00:00 + 2025-09-26T15:45:49.421495+00:00 - The discussion surrounding ASICBOOST and other mining optimizations in the Bitcoin community revolves around ethical implications, technical details, and potential impacts. One argument is that ASICBOOST reduces the amount of work needed to prove a certain amount of work has been done in Bitcoin's Proof of Work, but it is debated whether this qualifies as an attack. The debate also raises concerns about the ethical implications of keeping optimizations for oneself and how they could discourage growth and improvement of the Bitcoin protocol.There is a debate about implementing a system to invalidate covert ASICBOOST, with some miners resisting due to potential loss of mining revenue. The difficulty of implementing such a change is acknowledged, as it involves invalidating hardware or optimized bits. The concept of burn, which occurs regardless of successful mining, is also discussed, with suggestions of a burn-network to prevent burns by blocking transactions other than one's own. However, this approach is seen as weak, and there is no intention to roll back the blockchain like in the DAO fork.The discussion also focuses on Bitmain's claims regarding ASICBOOST support and the need for independent verification. There are proposals to inhibit covert attacks on the Bitcoin Proof of Work function, with scrutiny due to conflicts with other proposals. The feasibility and potential benefits of optimization techniques involving partial hash collisions in Merkle roots are examined, along with their compatibility with the stratum mining protocol.Concerns are raised about the incentive created by ASICBOOST to make blocks smaller, which is undesirable for the Bitcoin network. The complexity of the Proof of Work algorithm and the potential for unique optimizations that can be patented are also discussed. Simplifying the algorithm is suggested as a way to prevent hidden or unexpected optimizations. The conversation highlights the various viewpoints on ASICBOOST and its impact, with some arguing for its elimination to prevent unfair advantages and maintain network security, while others raise ethical concerns and potential negative impact on miners.Gregory Maxwell proposes updates to the Bitcoin protocol to inhibit covert forms of ASICBOOST mining, citing the reduction in work required and potential harm to the system. The ongoing conflict between Bitmain and Bitcoin developers over the use of ASICBOOST is compared to the DAO hack. There are arguments for and against blocking ASICBOOST, with some emphasizing the need for strong justification before changing the blockchain rules.Discussions also touch on other topics, such as potential security flaws in Bitcoin and proposals for soft fork solutions. A BIP draft is proposed to address ASICBOOST mining, aiming to inhibit covert usage that interferes with protocol improvements. Gregory Maxwell proposes a solution to a potential security problem caused by a design oversight in the proof of work function, suggesting a new consensus rule to prevent covert attacks.Overall, these discussions show ongoing efforts to address vulnerabilities, improve the Bitcoin protocol, and find a balance between fairness, network security, and the interests of miners. Proposed rules aim to sunset when no longer necessary and address potential vulnerabilities associated with non-covert forms. 2017-04-07T13:28:13+00:00 + The discussion surrounding ASICBOOST and other mining optimizations in the Bitcoin community revolves around ethical implications, technical details, and potential impacts. One argument is that ASICBOOST reduces the amount of work needed to prove a certain amount of work has been done in Bitcoin's Proof of Work, but it is debated whether this qualifies as an attack. The debate also raises concerns about the ethical implications of keeping optimizations for oneself and how they could discourage growth and improvement of the Bitcoin protocol.There is a debate about implementing a system to invalidate covert ASICBOOST, with some miners resisting due to potential loss of mining revenue. The difficulty of implementing such a change is acknowledged, as it involves invalidating hardware or optimized bits. The concept of burn, which occurs regardless of successful mining, is also discussed, with suggestions of a burn-network to prevent burns by blocking transactions other than one's own. However, this approach is seen as weak, and there is no intention to roll back the blockchain like in the DAO fork.The discussion also focuses on Bitmain's claims regarding ASICBOOST support and the need for independent verification. There are proposals to inhibit covert attacks on the Bitcoin Proof of Work function, with scrutiny due to conflicts with other proposals. The feasibility and potential benefits of optimization techniques involving partial hash collisions in Merkle roots are examined, along with their compatibility with the stratum mining protocol.Concerns are raised about the incentive created by ASICBOOST to make blocks smaller, which is undesirable for the Bitcoin network. The complexity of the Proof of Work algorithm and the potential for unique optimizations that can be patented are also discussed. Simplifying the algorithm is suggested as a way to prevent hidden or unexpected optimizations. The conversation highlights the various viewpoints on ASICBOOST and its impact, with some arguing for its elimination to prevent unfair advantages and maintain network security, while others raise ethical concerns and potential negative impact on miners.Gregory Maxwell proposes updates to the Bitcoin protocol to inhibit covert forms of ASICBOOST mining, citing the reduction in work required and potential harm to the system. The ongoing conflict between Bitmain and Bitcoin developers over the use of ASICBOOST is compared to the DAO hack. There are arguments for and against blocking ASICBOOST, with some emphasizing the need for strong justification before changing the blockchain rules.Discussions also touch on other topics, such as potential security flaws in Bitcoin and proposals for soft fork solutions. A BIP draft is proposed to address ASICBOOST mining, aiming to inhibit covert usage that interferes with protocol improvements. Gregory Maxwell proposes a solution to a potential security problem caused by a design oversight in the proof of work function, suggesting a new consensus rule to prevent covert attacks.Overall, these discussions show ongoing efforts to address vulnerabilities, improve the Bitcoin protocol, and find a balance between fairness, network security, and the interests of miners. Proposed rules aim to sunset when no longer necessary and address potential vulnerabilities associated with non-covert forms. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_BIP-proposal-draft-BIP43-purpose-allocation-for-Ethereum.xml b/static/bitcoin-dev/April_2017/combined_BIP-proposal-draft-BIP43-purpose-allocation-for-Ethereum.xml index 435a9ef2b6..058d982344 100644 --- a/static/bitcoin-dev/April_2017/combined_BIP-proposal-draft-BIP43-purpose-allocation-for-Ethereum.xml +++ b/static/bitcoin-dev/April_2017/combined_BIP-proposal-draft-BIP43-purpose-allocation-for-Ethereum.xml @@ -1,23 +1,28 @@ - + 2 - Combined summary - BIP proposal draft: BIP43 "purpose" allocation for Ethereum - 2023-08-01T20:22:48.665160+00:00 - - Tom Zander 2017-04-14 19:26:14+00:00 - - - Nick Johnson 2017-04-12 10:02:37+00:00 - + Combined summary - BIP proposal draft: BIP43 "purpose" allocation for Ethereum + 2025-09-26T15:45:34.553065+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal draft: BIP43 "purpose" allocation for Ethereum Nick Johnson + 2017-04-12T10:02:00.000Z + + + Tom Zander + 2017-04-14T19:26:00.000Z + + - python-feedgen + 2 - Combined summary - BIP proposal draft: BIP43 "purpose" allocation for Ethereum - 2023-08-01T20:22:48.665160+00:00 + Combined summary - BIP proposal draft: BIP43 "purpose" allocation for Ethereum + 2025-09-26T15:45:34.553509+00:00 - In a recent email thread on the bitcoin-dev mailing list, user Tom Zander expressed support for a proposal to create a Bitcoin Improvement Proposal (BIP) that defines a logical hierarchy for deterministic wallets on the Ethereum blockchain. The proposed BIP, called bip-nickjohnson-ethereum-purpose, is based on the algorithm described in BIP-0032 and the purpose scheme described in BIP-0043.The proposed hierarchy aims to address the unique requirements of Ethereum, as the current hierarchy defined by BIP44 is not well-suited for the platform and has resulted in compatibility issues between different clients. The new hierarchy defines two levels in the BIP32 path: purpose and subpurpose. The purpose level is set to the hardened value of the BIP number assigned to this BIP, indicating that the subtree of this node should be used according to this specification.The subpurpose level is set to the Ethereum Improvement Proposal (EIP) number, which specifies the remainder of the BIP32 derivation path. This allows for the creation of new Ethereum-focused applications of deterministic wallets without needing to interface with the traditional BIP process. The proposal seeks to provide a standardized approach to hierarchical deterministic wallets that better aligns with Ethereum's unique requirements.By adopting this proposed BIP, developers will have a clear framework to build Ethereum-focused applications of deterministic wallets. The use of BIP32 and BIP43 references in the proposal ensures compatibility with existing standards and technologies. Overall, this proposal aims to improve interoperability and standardization within the Ethereum ecosystem. 2017-04-14T19:26:14+00:00 + In a recent email thread on the bitcoin-dev mailing list, user Tom Zander expressed support for a proposal to create a Bitcoin Improvement Proposal (BIP) that defines a logical hierarchy for deterministic wallets on the Ethereum blockchain. The proposed BIP, called bip-nickjohnson-ethereum-purpose, is based on the algorithm described in BIP-0032 and the purpose scheme described in BIP-0043.The proposed hierarchy aims to address the unique requirements of Ethereum, as the current hierarchy defined by BIP44 is not well-suited for the platform and has resulted in compatibility issues between different clients. The new hierarchy defines two levels in the BIP32 path: purpose and subpurpose. The purpose level is set to the hardened value of the BIP number assigned to this BIP, indicating that the subtree of this node should be used according to this specification.The subpurpose level is set to the Ethereum Improvement Proposal (EIP) number, which specifies the remainder of the BIP32 derivation path. This allows for the creation of new Ethereum-focused applications of deterministic wallets without needing to interface with the traditional BIP process. The proposal seeks to provide a standardized approach to hierarchical deterministic wallets that better aligns with Ethereum's unique requirements.By adopting this proposed BIP, developers will have a clear framework to build Ethereum-focused applications of deterministic wallets. The use of BIP32 and BIP43 references in the proposal ensures compatibility with existing standards and technologies. Overall, this proposal aims to improve interoperability and standardization within the Ethereum ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml b/static/bitcoin-dev/April_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml index f4364d22b6..0f9feb810a 100644 --- a/static/bitcoin-dev/April_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml +++ b/static/bitcoin-dev/April_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml @@ -1,113 +1,147 @@ - + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 - - bfd at cock.lu 2017-04-01 23:49:03+00:00 - - - Tom Harding 2017-03-16 15:05:11+00:00 - - - bfd at cock.lu 2017-03-16 00:25:01+00:00 - - - Tom Harding 2017-03-15 22:36:09+00:00 - - - Chris Belcher 2017-02-17 00:28:59+00:00 - - - Erik Aronesty 2017-01-06 22:07:36+00:00 - - - Eric Voskuil 2017-01-06 21:50:47+00:00 - - - James MacWhyte 2017-01-06 21:35:58+00:00 - - - Chris Priest 2017-01-06 20:15:46+00:00 - - - Aaron Voisine 2017-01-06 07:07:34+00:00 - - - bfd at cock.lu 2017-01-06 02:15:26+00:00 - - - bfd at cock.lu 2017-01-06 02:04:22+00:00 - - - Christian Decker 2017-01-05 14:48:33+00:00 - - - Eric Voskuil 2017-01-05 07:45:18+00:00 - - - Chris Priest 2017-01-05 07:06:36+00:00 - - - Leo Wandersleb 2017-01-04 16:13:41+00:00 - - - Adam Back 2017-01-04 11:00:55+00:00 - - - Jorge Timón 2017-01-04 10:13:02+00:00 - - - Aaron Voisine 2017-01-04 08:56:21+00:00 - - - Jonas Schnelli 2017-01-04 07:47:10+00:00 - - - Eric Voskuil 2017-01-04 06:06:31+00:00 - - - Aaron Voisine 2017-01-04 00:36:34+00:00 - - - bfd at cock.lu 2017-01-04 00:10:14+00:00 - - - Aaron Voisine 2017-01-03 23:46:00+00:00 - - - adiabat 2017-01-03 23:06:26+00:00 - - - bfd at cock.lu 2017-01-03 22:28:56+00:00 - - - Aaron Voisine 2017-01-03 22:18:21+00:00 - - - bfd at cock.lu 2017-01-03 20:24:35+00:00 - - - bfd at cock.lu 2017-01-03 20:18:59+00:00 - - - Jonas Schnelli 2017-01-01 21:01:23+00:00 - - - Leo Wandersleb 2016-07-28 21:07:29+00:00 - - - Bob McElrath 2016-05-11 20:29:33+00:00 - - - Bob McElrath 2016-05-11 20:06:48+00:00 - - - Gregory Maxwell 2016-05-09 08:57:08+00:00 - - - bfd at cock.lu 2016-05-09 08:26:06+00:00 - + 2025-09-26T15:46:31.496391+00:00 + python-feedgen + + + [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd + 2016-05-09T08:26:00.000Z + + + Gregory Maxwell + 2016-05-09T08:57:00.000Z + + + Bob McElrath + 2016-05-11T20:06:00.000Z + + + Bob McElrath + 2016-05-11T20:29:00.000Z + + + Leo Wandersleb + 2016-07-28T21:07:00.000Z + + + bfd + 2017-01-03T20:18:00.000Z + + + bfd + 2017-01-03T20:24:00.000Z + + + Aaron Voisine + 2017-01-03T22:18:00.000Z + + + bfd + 2017-01-03T22:28:00.000Z + + + adiabat + 2017-01-03T23:06:00.000Z + + + Aaron Voisine + 2017-01-03T23:46:00.000Z + + + bfd + 2017-01-04T00:10:00.000Z + + + Aaron Voisine + 2017-01-04T00:36:00.000Z + + + Eric Voskuil + 2017-01-04T06:06:00.000Z + + + Jonas Schnelli + 2017-01-04T07:47:00.000Z + + + Aaron Voisine + 2017-01-04T08:56:00.000Z + + + Jorge Timón + 2017-01-04T10:13:00.000Z + + + Adam Back + 2017-01-04T11:00:00.000Z + + + Leo Wandersleb + 2017-01-04T16:13:00.000Z + + + Chris Priest + 2017-01-05T07:06:00.000Z + + + Eric Voskuil + 2017-01-05T07:45:00.000Z + + + Christian Decker + 2017-01-05T14:48:00.000Z + + + bfd + 2017-01-06T02:04:00.000Z + + + bfd + 2017-01-06T02:15:00.000Z + + + Aaron Voisine + 2017-01-06T07:07:00.000Z + + + Chris Priest + 2017-01-06T20:15:00.000Z + + + James MacWhyte + 2017-01-06T21:35:00.000Z + + + Eric Voskuil + 2017-01-06T21:50:00.000Z + + + Erik Aronesty + 2017-01-06T22:07:00.000Z + + + Chris Belcher + 2017-02-17T00:28:00.000Z + + + Tom Harding + 2017-03-15T22:36:00.000Z + + + bfd + 2017-03-16T00:25:00.000Z + + + Tom Harding + 2017-03-16T15:05:00.000Z + + + bfd + 2017-04-01T23:49:00.000Z + + @@ -143,13 +177,13 @@ - python-feedgen + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 + 2025-09-26T15:46:31.499831+00:00 - In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On 2017-04-01T23:49:03+00:00 + In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Defending-against-empty-or-near-empty-blocks-from-malicious-miner-takeover-.xml b/static/bitcoin-dev/April_2017/combined_Defending-against-empty-or-near-empty-blocks-from-malicious-miner-takeover-.xml index d06fdc77b9..8f8f498c03 100644 --- a/static/bitcoin-dev/April_2017/combined_Defending-against-empty-or-near-empty-blocks-from-malicious-miner-takeover-.xml +++ b/static/bitcoin-dev/April_2017/combined_Defending-against-empty-or-near-empty-blocks-from-malicious-miner-takeover-.xml @@ -1,71 +1,99 @@ - + 2 Combined summary - Defending against empty or near empty blocks from malicious miner takeover? - 2023-08-01T19:54:14.648636+00:00 - - CANNON 2017-04-14 02:22:18+00:00 - - - Aymeric Vitte 2017-03-27 10:25:00+00:00 - - - Eric Voskuil 2017-03-26 22:15:54+00:00 - - - Tom Harding 2017-03-26 21:42:51+00:00 - - - Eric Voskuil 2017-03-26 21:12:20+00:00 - - - Bryan Bishop 2017-03-26 20:44:12+00:00 - - - Trevin Hofmann 2017-03-26 20:37:28+00:00 - - - Bryan Bishop 2017-03-26 20:22:19+00:00 - - - Alphonse Pace 2017-03-26 20:20:56+00:00 - - - Peter R 2017-03-26 19:05:38+00:00 - - - Alex Morcos 2017-03-26 11:27:30+00:00 - - - Chris Pacia 2017-03-26 09:13:17+00:00 - - - Alex Morcos 2017-03-26 02:38:16+00:00 - - - Peter R 2017-03-25 20:28:44+00:00 - - - CANNON 2017-03-25 16:12:54+00:00 - - - Aymeric Vitte 2017-03-24 19:00:40+00:00 - - - Aymeric Vitte 2017-03-24 19:00:31+00:00 - - - Hampus Sjöberg 2017-03-24 17:37:25+00:00 - - - Nick ODell 2017-03-24 17:29:54+00:00 - - - Emin Gün Sirer 2017-03-24 16:27:47+00:00 - - - CANNON 2017-03-24 16:03:31+00:00 - + 2025-09-26T15:46:12.566738+00:00 + python-feedgen + + + [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? CANNON + 2017-03-24T16:03:00.000Z + + + Emin Gün Sirer + 2017-03-24T16:27:00.000Z + + + Nick ODell + 2017-03-24T17:29:00.000Z + + + Hampus Sjöberg + 2017-03-24T17:37:00.000Z + + + Aymeric Vitte + 2017-03-24T19:00:00.000Z + + + [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? Aymeric Vitte + 2017-03-24T19:00:00.000Z + + + CANNON + 2017-03-25T16:12:00.000Z + + + Peter R + 2017-03-25T20:28:00.000Z + + + Alex Morcos + 2017-03-26T02:38:00.000Z + + + [bitcoin-dev] Two altcoins and a 51% attack (was: Defending against empty or near empty blocks from malicious miner takeover?) Eric Voskuil + 2017-03-26T03:00:00.000Z + + + Chris Pacia + 2017-03-26T09:13:00.000Z + + + Alex Morcos + 2017-03-26T11:27:00.000Z + + + Peter R + 2017-03-26T19:05:00.000Z + + + Alphonse Pace + 2017-03-26T20:20:00.000Z + + + Bryan Bishop + 2017-03-26T20:22:00.000Z + + + Trevin Hofmann + 2017-03-26T20:37:00.000Z + + + Bryan Bishop + 2017-03-26T20:44:00.000Z + + + Eric Voskuil + 2017-03-26T21:12:00.000Z + + + Tom Harding + 2017-03-26T21:42:00.000Z + + + Eric Voskuil + 2017-03-26T22:15:00.000Z + + + Aymeric Vitte + 2017-03-27T10:25:00.000Z + + + CANNON + 2017-04-14T02:22:00.000Z + + @@ -87,13 +115,13 @@ - python-feedgen + 2 Combined summary - Defending against empty or near empty blocks from malicious miner takeover? - 2023-08-01T19:54:14.648636+00:00 + 2025-09-26T15:46:12.569102+00:00 - In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the language used to describe future network upgrades. The debate focused on whether the term "network upgrade" was misleading and whether a proposed attack on the old chain was an attempt to transfer economic activity from BTC to BTU. There were also questions about the ethics of minority hash power producers in such situations.One concern raised by Emin Gün Sirer was that filling empty blocks with transactions could lead to forks and create a new attack vector. He warned that bad actors could time the flood of new transactions with the discovery of a block by a competitor in order to orphan the block and fork the chain. However, Peter R criticized the use of the term "network upgrade" instead of the technical term "hard fork," finding it misleading. Eric Voskuil had presented the proposal on behalf of an unknown group, which led to questions about the lack of clarity around the proposal and its proponents.The discussion also touched on the activation of segwit through bip9-based soft-fork. Bryan Bishop and Peter R discussed the possibility of a hash power minority not upgrading and producing a minority branch. Peter R suggested that any invalid blocks produced by the minority would be orphaned, serving as a wake-up call to upgrade. However, Bishop refuted this claim, stating that miner blocks will not be orphaned unless they are intentionally segwit-invalid.Trevin Hofmann and Bryan also discussed the issue of non-upgraded miners producing invalid blocks. Hofmann argued that if non-upgraded miners follow the new rules, their blocks will not be orphaned. Bryan countered that there is no need for a "wake-up call to upgrade" as the point of a soft-fork is to reduce incompatibility. He suggested running "border nodes" to ensure compliance.The proposed techniques to reduce the chances of a blockchain split involve orphaning the blocks of non-compliant miners and re-organizing any minority branch with empty blocks. However, some members of the community believe that a peaceful split would be preferable to these proposed tactics for enforcing the upgrade. Peter R believes that miners will not upgrade until they are confident that no minority chain will survive.The discussion also touched on the definition and implementation of soft forks and hard forks. There were concerns about the lack of precision and consistency in discussing these concepts, and whether miners should have the right to enforce soft forks. Alex Morcos expressed disapproval of implementing Segregated Witness (SegWit) as a soft fork, arguing that it prevents users from using the rules they want.Overall, there is ongoing debate and concern within the Bitcoin community regarding network upgrades, terminology, consensus requirements, and the potential for blockchain splits. Various proposals and arguments have been put forward to address these issues, with differing opinions on the best approaches to ensuring a smooth transition and minimizing disruption.Another issue of concern within the Bitcoin community is the centralization of mining power. Currently, only a small group of people control a majority of the hashing power, leading to concerns about their ability to manipulate the network for their own agenda. The fear is that these miners could kill the valid chain to force economic activity onto their adversary-controlled chain.One proposed update is to ignore empty blocks as a means of mitigating the problem of blocking empty or near-empty blocks. However, there are concerns about defense from blocks that are intentionally small but not empty. It may be possible to have nodes ignore not only empty blocks but also abnormally small blocks compared to the number of valid transactions in the mempool.There needs to be discussion on various attacks and how they can be guarded against, along with contingency plans. Increasing the number of full nodes is suggested as a priority, along with designing incentives for people to run full nodes and setting up a system for people to set up full nodes in a timely manner. It is proposed that Bram Cohen be asked to resurrect the bitcoin miner Epic Scale, which could increase mining power if users upgrade. Additionally, activating proof of space by anticipation is suggested as an alternative solution.Promoting full nodes by making the bitcoin-qt blockchain and chain state available through torrents is also suggested to encourage more people to set up full nodes. However, it is acknowledged that there is historical consensus between miners and developers that may have hindered the prioritization of increasing the number of full nodes.In the email conversation on the bitcoin-dev mailing list, concerns were raised over a proposal to update nodes to ignore empty blocks. The concern was that this would make block validity depend on things that are not in the blockchain and could lead to different mempool sizes for different nodes, causing a lack of consensus. There was also concern about malicious miners orphaning the chain after many blocks, even with non-empty blocks, and whether it was possible to mitigate this.The overall discussion revolved around the issue of centralization of mining power and the potential threat posed by a small group of miners controlling a large amount of hash power. The 2017-04-14T02:22:18+00:00 + In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the language used to describe future network upgrades. The debate focused on whether the term "network upgrade" was misleading and whether a proposed attack on the old chain was an attempt to transfer economic activity from BTC to BTU. There were also questions about the ethics of minority hash power producers in such situations.One concern raised by Emin Gün Sirer was that filling empty blocks with transactions could lead to forks and create a new attack vector. He warned that bad actors could time the flood of new transactions with the discovery of a block by a competitor in order to orphan the block and fork the chain. However, Peter R criticized the use of the term "network upgrade" instead of the technical term "hard fork," finding it misleading. Eric Voskuil had presented the proposal on behalf of an unknown group, which led to questions about the lack of clarity around the proposal and its proponents.The discussion also touched on the activation of segwit through bip9-based soft-fork. Bryan Bishop and Peter R discussed the possibility of a hash power minority not upgrading and producing a minority branch. Peter R suggested that any invalid blocks produced by the minority would be orphaned, serving as a wake-up call to upgrade. However, Bishop refuted this claim, stating that miner blocks will not be orphaned unless they are intentionally segwit-invalid.Trevin Hofmann and Bryan also discussed the issue of non-upgraded miners producing invalid blocks. Hofmann argued that if non-upgraded miners follow the new rules, their blocks will not be orphaned. Bryan countered that there is no need for a "wake-up call to upgrade" as the point of a soft-fork is to reduce incompatibility. He suggested running "border nodes" to ensure compliance.The proposed techniques to reduce the chances of a blockchain split involve orphaning the blocks of non-compliant miners and re-organizing any minority branch with empty blocks. However, some members of the community believe that a peaceful split would be preferable to these proposed tactics for enforcing the upgrade. Peter R believes that miners will not upgrade until they are confident that no minority chain will survive.The discussion also touched on the definition and implementation of soft forks and hard forks. There were concerns about the lack of precision and consistency in discussing these concepts, and whether miners should have the right to enforce soft forks. Alex Morcos expressed disapproval of implementing Segregated Witness (SegWit) as a soft fork, arguing that it prevents users from using the rules they want.Overall, there is ongoing debate and concern within the Bitcoin community regarding network upgrades, terminology, consensus requirements, and the potential for blockchain splits. Various proposals and arguments have been put forward to address these issues, with differing opinions on the best approaches to ensuring a smooth transition and minimizing disruption.Another issue of concern within the Bitcoin community is the centralization of mining power. Currently, only a small group of people control a majority of the hashing power, leading to concerns about their ability to manipulate the network for their own agenda. The fear is that these miners could kill the valid chain to force economic activity onto their adversary-controlled chain.One proposed update is to ignore empty blocks as a means of mitigating the problem of blocking empty or near-empty blocks. However, there are concerns about defense from blocks that are intentionally small but not empty. It may be possible to have nodes ignore not only empty blocks but also abnormally small blocks compared to the number of valid transactions in the mempool.There needs to be discussion on various attacks and how they can be guarded against, along with contingency plans. Increasing the number of full nodes is suggested as a priority, along with designing incentives for people to run full nodes and setting up a system for people to set up full nodes in a timely manner. It is proposed that Bram Cohen be asked to resurrect the bitcoin miner Epic Scale, which could increase mining power if users upgrade. Additionally, activating proof of space by anticipation is suggested as an alternative solution.Promoting full nodes by making the bitcoin-qt blockchain and chain state available through torrents is also suggested to encourage more people to set up full nodes. However, it is acknowledged that there is historical consensus between miners and developers that may have hindered the prioritization of increasing the number of full nodes.In the email conversation on the bitcoin-dev mailing list, concerns were raised over a proposal to update nodes to ignore empty blocks. The concern was that this would make block validity depend on things that are not in the blockchain and could lead to different mempool sizes for different nodes, causing a lack of consensus. There was also concern about malicious miners orphaning the chain after many blocks, even with non-empty blocks, and whether it was possible to mitigate this.The overall discussion revolved around the issue of centralization of mining power and the potential threat posed by a small group of miners controlling a large amount of hash power. The - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Deploying-CT-in-Bitcoin-without-extension-blocks-.xml b/static/bitcoin-dev/April_2017/combined_Deploying-CT-in-Bitcoin-without-extension-blocks-.xml index 32b750d9f5..2f253c2a76 100644 --- a/static/bitcoin-dev/April_2017/combined_Deploying-CT-in-Bitcoin-without-extension-blocks-.xml +++ b/static/bitcoin-dev/April_2017/combined_Deploying-CT-in-Bitcoin-without-extension-blocks-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Deploying CT in Bitcoin without extension blocks? - 2023-08-01T20:23:03.974157+00:00 - - Adam Back 2017-04-13 01:43:46+00:00 - - - Oleg Andreev 2017-04-13 00:43:50+00:00 - + 2025-09-26T15:46:25.189025+00:00 + python-feedgen + + + [bitcoin-dev] Deploying CT in Bitcoin without extension blocks? Oleg Andreev + 2017-04-13T00:43:00.000Z + + + Adam Back + 2017-04-13T01:43:00.000Z + + - python-feedgen + 2 Combined summary - Deploying CT in Bitcoin without extension blocks? - 2023-08-01T20:23:03.974157+00:00 + 2025-09-26T15:46:25.189485+00:00 - On the Bitcoin-dev mailing list, Oleg Andreev has put forward a proposal for implementing Confidential Transactions on the Bitcoin network. The proposal suggests a new accounting model and representation of numbers, using EC points as Pedersen commitments. The goal is to make the change compatible with the existing system and maintain the 1 MB limit. To achieve this, the proposal introduces two new script versions (version A and version B) and implements six new soft fork rules.One of the key features of the proposal is that it allows for the use of confidential transactions alongside plaintext inputs/outputs using legacy software. This means that users can still participate in confidential transactions without having to upgrade their software. The proposal also utilizes the same UTXO set, further ensuring compatibility.In terms of transaction structure, the proposal suggests sticking confidential values directly into the existing format. It also introduces a range proof, which can be either confidential or non-confidential. Additionally, the transaction witness can include an excess value and cleartext amount for a miner's fee.The proposal has a side effect that benefits miners. As they are the ones minting the confidential coins, they have the ability to sell them at a premium. This creates an incentive for miners to support the feature and work on improving the performance of rangeproof validation.To enhance scalability, the proposal suggests compressing on-chain transactions using mimblewimble cut-through. However, implementing more complex support from miners to merge outputs representing "plaintext value bank" would require further development of non-malleable TxID, which excludes miner-adjustable export/import outputs.Overall, the proposal offers a comprehensive plan for implementing Confidential Transactions on the Bitcoin network. It takes into account compatibility with existing systems, introduces new script versions and soft fork rules, and provides incentives for miners to support and improve the feature. By utilizing the same UTXO set and allowing co-authorship with plaintext inputs/outputs, the proposal ensures that users can participate in confidential transactions without the need for significant software upgrades. 2017-04-13T01:43:46+00:00 + On the Bitcoin-dev mailing list, Oleg Andreev has put forward a proposal for implementing Confidential Transactions on the Bitcoin network. The proposal suggests a new accounting model and representation of numbers, using EC points as Pedersen commitments. The goal is to make the change compatible with the existing system and maintain the 1 MB limit. To achieve this, the proposal introduces two new script versions (version A and version B) and implements six new soft fork rules.One of the key features of the proposal is that it allows for the use of confidential transactions alongside plaintext inputs/outputs using legacy software. This means that users can still participate in confidential transactions without having to upgrade their software. The proposal also utilizes the same UTXO set, further ensuring compatibility.In terms of transaction structure, the proposal suggests sticking confidential values directly into the existing format. It also introduces a range proof, which can be either confidential or non-confidential. Additionally, the transaction witness can include an excess value and cleartext amount for a miner's fee.The proposal has a side effect that benefits miners. As they are the ones minting the confidential coins, they have the ability to sell them at a premium. This creates an incentive for miners to support the feature and work on improving the performance of rangeproof validation.To enhance scalability, the proposal suggests compressing on-chain transactions using mimblewimble cut-through. However, implementing more complex support from miners to merge outputs representing "plaintext value bank" would require further development of non-malleable TxID, which excludes miner-adjustable export/import outputs.Overall, the proposal offers a comprehensive plan for implementing Confidential Transactions on the Bitcoin network. It takes into account compatibility with existing systems, introduces new script versions and soft fork rules, and provides incentives for miners to support and improve the feature. By utilizing the same UTXO set and allowing co-authorship with plaintext inputs/outputs, the proposal ensures that users can participate in confidential transactions without the need for significant software upgrades. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Draft-BIP-Segwit-deployment-with-versionbits-and-guaranteed-lock-in.xml b/static/bitcoin-dev/April_2017/combined_Draft-BIP-Segwit-deployment-with-versionbits-and-guaranteed-lock-in.xml index 6804155d35..6bab320343 100644 --- a/static/bitcoin-dev/April_2017/combined_Draft-BIP-Segwit-deployment-with-versionbits-and-guaranteed-lock-in.xml +++ b/static/bitcoin-dev/April_2017/combined_Draft-BIP-Segwit-deployment-with-versionbits-and-guaranteed-lock-in.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Draft BIP: Segwit deployment with versionbits and guaranteed lock-in - 2023-08-01T20:31:30.698280+00:00 - - Luke Dashjr 2017-04-26 18:33:56+00:00 - - - shaolinfry 2017-04-26 18:15:26+00:00 - + 2025-09-26T15:45:32.462315+00:00 + python-feedgen + + + [bitcoin-dev] Draft BIP: Segwit deployment with versionbits and guaranteed lock-in shaolinfry + 2017-04-26T18:15:00.000Z + + + Luke Dashjr + 2017-04-26T18:33:00.000Z + + - python-feedgen + 2 Combined summary - Draft BIP: Segwit deployment with versionbits and guaranteed lock-in - 2023-08-01T20:31:30.698280+00:00 + 2025-09-26T15:45:32.462797+00:00 - On April 26, 2017, shaolinfry proposed a draft BIP (Bitcoin Improvement Proposal) to redeploy segwit (Segregated Witness) using BIP-8. This proposal aims to activate segwit through a user activated soft fork (UASF) by utilizing versionbits with guaranteed lock-in. The motivation behind this proposal is the reluctance of miners to signal the BIP9 segwit deployment, despite a significant portion of the Bitcoin ecosystem desiring its activation.The draft BIP specifies that if the BIP is not already locked-in or activated by the timeout, a UASF will be triggered to deploy segwit again using versionbits. This approach allows users to have sufficient time to prepare and eliminates the need for a miner supermajority. However, it still permits the possibility of an earlier miner activated soft fork (MASF). The proposed start date for this deployment is November 16, 2017, with a BIP8 timeout set for July 4, 2018.It should be noted that these dates are specific to Bitcoin mainnet, as segwit is already activated on Bitcoin testnet. The deployment will utilize service bit (1) and will be deployed by BIP8 under the name "uasegwit" using bit 2.The author suggests deploying this BIP well in advance of the BIP8 start time to ensure that the timeout is sufficiently far in the future, giving Bitcoin users ample time to upgrade their systems. The start time of this BIP comes after the BIP9 "segwit" timeout to avoid compatibility issues with older nodes.Currently, there have been no comments on this draft BIP proposal, which is still in the draft status under Standards Track. The reference implementation for this deployment can be found at the provided GitHub link. 2017-04-26T18:33:56+00:00 + On April 26, 2017, shaolinfry proposed a draft BIP (Bitcoin Improvement Proposal) to redeploy segwit (Segregated Witness) using BIP-8. This proposal aims to activate segwit through a user activated soft fork (UASF) by utilizing versionbits with guaranteed lock-in. The motivation behind this proposal is the reluctance of miners to signal the BIP9 segwit deployment, despite a significant portion of the Bitcoin ecosystem desiring its activation.The draft BIP specifies that if the BIP is not already locked-in or activated by the timeout, a UASF will be triggered to deploy segwit again using versionbits. This approach allows users to have sufficient time to prepare and eliminates the need for a miner supermajority. However, it still permits the possibility of an earlier miner activated soft fork (MASF). The proposed start date for this deployment is November 16, 2017, with a BIP8 timeout set for July 4, 2018.It should be noted that these dates are specific to Bitcoin mainnet, as segwit is already activated on Bitcoin testnet. The deployment will utilize service bit (1) and will be deployed by BIP8 under the name "uasegwit" using bit 2.The author suggests deploying this BIP well in advance of the BIP8 start time to ensure that the timeout is sufficiently far in the future, giving Bitcoin users ample time to upgrade their systems. The start time of this BIP comes after the BIP9 "segwit" timeout to avoid compatibility issues with older nodes.Currently, there have been no comments on this draft BIP proposal, which is still in the draft status under Standards Track. The reference implementation for this deployment can be found at the provided GitHub link. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Draft-BIP-Version-bits-extension-with-guaranteed-lock-in.xml b/static/bitcoin-dev/April_2017/combined_Draft-BIP-Version-bits-extension-with-guaranteed-lock-in.xml index dfb7c07e21..feb77df33e 100644 --- a/static/bitcoin-dev/April_2017/combined_Draft-BIP-Version-bits-extension-with-guaranteed-lock-in.xml +++ b/static/bitcoin-dev/April_2017/combined_Draft-BIP-Version-bits-extension-with-guaranteed-lock-in.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP: Version bits extension with guaranteed lock-in - 2023-08-01T20:18:52.263031+00:00 + 2025-09-26T15:46:06.262756+00:00 + python-feedgen Kekcoin 2017-04-18 12:37:29+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Draft BIP: Version bits extension with guaranteed lock-in - 2023-08-01T20:18:52.263031+00:00 + 2025-09-26T15:46:06.262918+00:00 - The proposed uaversionbits aims to simplify the activation process of BIP9 by introducing a boolean flag to ensure lock-in of a BIP9 deployment by the timeout. This allows for user-activated soft forks that can be activated early by the hash power. However, one criticism is the lack of a back-out procedure if a critical flaw is found after activation. To address this, the author suggests using a second version bit as an abandonment vote, which would require sufficient hashpower to abandon the protocol change. This changes the dynamic from BIP9's "opt-in" system to an "opt-out" system, still governed by hashpower but less susceptible to minority miner veto.In an email exchange between two individuals, it was challenged whether a misconfiguration could result in a stopped chain. The respondent clarified that this statement is only true for BIP9 soft forks. They explained that if rule changes are made at different times from the chain with the most work, there could be subjective hardfork-ness. This occurs when miners create blocks that the economic majority accepts despite having less restrictive rules than other chains. The segwit soft fork narrows the definition of a nonstandard transaction, and any block with a transaction violating cleanstack on a non-segwit chain would likely be considered malicious. However, they acknowledged that future forks may restrict more common things. In response to the suggestion of notifying users when a newly activated soft fork rule causes a block to be rejected, the respondent suggested that clients could make these decisions themselves.A discussion on the Bitcoin-dev mailing list revolved around the failure mode of a user's misconfiguration of nTimeout, which could result in a stopped chain. Praxeology Guy pointed out that this claim is incorrect since BIP9 only applies to soft forks and not hard forks. To have a stopped chain with a soft fork, a user must adopt more stringent rules while someone maliciously creates an invalid block that is valid to older nodes, and no miner ever mines a different block at the height of the block in question. Praxeology Guy also suggested that users should be notified when a newly activated more stringent soft fork rule causes a block to be rejected, as it could serve as an excellent trigger to enable replay attack prevention.The importance of understanding and properly configuring nTimeout to avoid potential issues with blockchain progress is highlighted. It is suggested that if less-sophisticated users are given these configuration settings, any chaintip progress failures resulting from them should be displayed prominently. Clear and visible notifications when such failures occur are emphasized, particularly for users who may not be as familiar with the technology.A proposal to orphan valid old blocks has been deemed unnecessary. The "lockinontimeout" variable has been extracted so that the same method can be used in future softfork proposals instead of hardcoding a special case hack for SegWit. Users are suggested to have the ability to set this variable in a configuration file, along with the "nTimeout" in "src/chainparams.cpp". This would allow users to expedite when a softfork becomes active on their node when combined with "lockinontimeout". Developers like the Core team could provide more conservative values in the program, while community members such as miners and nodes who feel strongly about SegWit could either compile their own settings or use a popular configuration file if available.The proposed BIP is an extension to BIP9 that introduces an additional activation parameter to guarantee the activation of backward-compatible changes, or soft forks. It aims to simplify the original uaversionbits proposal by introducing a boolean flag to ensure lock-in of a BIP9 deployment by the timeout. This combines optional flag day activation with BIP9, allowing for user-activated soft forks that can be activated early by the hash power. The specification adds a new per-chain deployment parameter to the existing BIP9 specification. A reference implementation of the proposed BIP is available on GitHub, and the document is licensed under BSD 3-clause and Creative Commons CC0 1.0 Universal. 2017-04-18T12:37:29+00:00 + The proposed uaversionbits aims to simplify the activation process of BIP9 by introducing a boolean flag to ensure lock-in of a BIP9 deployment by the timeout. This allows for user-activated soft forks that can be activated early by the hash power. However, one criticism is the lack of a back-out procedure if a critical flaw is found after activation. To address this, the author suggests using a second version bit as an abandonment vote, which would require sufficient hashpower to abandon the protocol change. This changes the dynamic from BIP9's "opt-in" system to an "opt-out" system, still governed by hashpower but less susceptible to minority miner veto.In an email exchange between two individuals, it was challenged whether a misconfiguration could result in a stopped chain. The respondent clarified that this statement is only true for BIP9 soft forks. They explained that if rule changes are made at different times from the chain with the most work, there could be subjective hardfork-ness. This occurs when miners create blocks that the economic majority accepts despite having less restrictive rules than other chains. The segwit soft fork narrows the definition of a nonstandard transaction, and any block with a transaction violating cleanstack on a non-segwit chain would likely be considered malicious. However, they acknowledged that future forks may restrict more common things. In response to the suggestion of notifying users when a newly activated soft fork rule causes a block to be rejected, the respondent suggested that clients could make these decisions themselves.A discussion on the Bitcoin-dev mailing list revolved around the failure mode of a user's misconfiguration of nTimeout, which could result in a stopped chain. Praxeology Guy pointed out that this claim is incorrect since BIP9 only applies to soft forks and not hard forks. To have a stopped chain with a soft fork, a user must adopt more stringent rules while someone maliciously creates an invalid block that is valid to older nodes, and no miner ever mines a different block at the height of the block in question. Praxeology Guy also suggested that users should be notified when a newly activated more stringent soft fork rule causes a block to be rejected, as it could serve as an excellent trigger to enable replay attack prevention.The importance of understanding and properly configuring nTimeout to avoid potential issues with blockchain progress is highlighted. It is suggested that if less-sophisticated users are given these configuration settings, any chaintip progress failures resulting from them should be displayed prominently. Clear and visible notifications when such failures occur are emphasized, particularly for users who may not be as familiar with the technology.A proposal to orphan valid old blocks has been deemed unnecessary. The "lockinontimeout" variable has been extracted so that the same method can be used in future softfork proposals instead of hardcoding a special case hack for SegWit. Users are suggested to have the ability to set this variable in a configuration file, along with the "nTimeout" in "src/chainparams.cpp". This would allow users to expedite when a softfork becomes active on their node when combined with "lockinontimeout". Developers like the Core team could provide more conservative values in the program, while community members such as miners and nodes who feel strongly about SegWit could either compile their own settings or use a popular configuration file if available.The proposed BIP is an extension to BIP9 that introduces an additional activation parameter to guarantee the activation of backward-compatible changes, or soft forks. It aims to simplify the original uaversionbits proposal by introducing a boolean flag to ensure lock-in of a BIP9 deployment by the timeout. This combines optional flag day activation with BIP9, allowing for user-activated soft forks that can be activated early by the hash power. The specification adds a new per-chain deployment parameter to the existing BIP9 specification. A reference implementation of the proposed BIP is available on GitHub, and the document is licensed under BSD 3-clause and Creative Commons CC0 1.0 Universal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml b/static/bitcoin-dev/April_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml index 82e92a5d86..c6730ba283 100644 --- a/static/bitcoin-dev/April_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml +++ b/static/bitcoin-dev/April_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Extension block proposal by Jeffrey et al - 2023-08-01T20:14:37.007434+00:00 + 2025-09-26T15:45:47.303195+00:00 + python-feedgen Christopher Jeffrey 2017-05-10 01:19:30+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Extension block proposal by Jeffrey et al - 2023-08-01T20:14:37.008942+00:00 + 2025-09-26T15:45:47.303363+00:00 - A proposal has been made for an extension block that would allow atomic swaps between Bitcoin and Xbitcoin. However, there are concerns about the maturity rule and its impact on legacy wallets. Christopher Jeffrey suggests revising the extension block code to coexist with mainchain segwit and require exiting outputs to only be witness programs. This would mitigate the issue assuming most segwit-supporting wallets implement this rule before the activation of segwit.There is also discussion about allowing direct exit payments to legacy addresses and the lock-up period for exiting outputs. One solution is to add a maturity requirement for exiting outputs, but this would make non-upgraded wallets unusable. Another solution is to move all exiting outputs to the coinbase, but this would deteriorate user experience and essentially become a hardfork. It is suggested that switching to witness programs only and requiring exiting outputs to be witness programs may be a good balance between fungibility and backward-compatibility.The proposal also addresses the issue of making return outputs transparent to unupgraded wallets. The proposed solution is to send them to something non-standard today. The mainchain segwit is important in enabling atomic swaps between Bitcoin and Xbitcoin. The extension block specification/code is being revised to coexist with mainchain segwit and require exiting outputs to only be witness programs.In another discussion, Olaoluwa Osuntokun analyzes the xblock proposal and focuses on the sub-proposal for Lightning Network (LN) safety enhancement. The proposal involves a block-size decrease for each open channel within the network, which reserves space for honest parties to punish dishonest channel counter parties. There is also a proposal for a Pre-Allocated Smart-contract Dispute Arena (PASDA) to address systematic risks in the LN. However, the system has not been fully specified and evaluated yet.Overall, the discussions revolve around the proposed extension block, its compatibility with segwit, the issue of direct exit payments to legacy addresses, and the need for a balance between fungibility and backward-compatibility. The proposal also introduces additional safety measures for Lightning Network (LN) and blockchain availability in case of channel disputes.The writer of the context raises concerns about a new Bitcoin Improvement Proposal (BIP) and expresses disappointment that their proposal was not given more consideration. They criticize the lack of specificity in the proposed approach to resolving transaction malleability and suggest changes to how the merkle root is calculated. Additionally, they question whether direct exit payment to legacy addresses should be allowed and propose limiting the number of soft-fork upgrades, increasing the points for witness v0 outputs, and setting a higher dust threshold.A work-in-progress extension block proposal has been introduced by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. The proposal is available on Github and aims to increase bitcoin transaction throughput without altering existing consensus rules. However, the writer argues that extension blocks create additional complexity compared to other proposals and can potentially create two classes of "full nodes," leaving some insecure. They also mention potential issues with the maximum extension size and the validity of output script code in extension blocks.The Witness Vector specification details that every 73 bytes in the serialized witness vector is worth one additional point, but it doesn't explain why this number was chosen. The writer emphasizes the importance of submitting BIPs in MediaWiki format and for discussion on the bitcoin-dev mailing list rather than social media and news outlets. They assert that extension blocks are more like a hard-fork rather than a soft-fork and highlight the potential legal implications of BIPs not being recognized in certain jurisdictions.The UTXO set behaves fundamentally differently with the extension block proposal, but mostly in a compatible manner. Canonical blocks containing entering outputs must have an extension block commitment, even if it contains all zeroes. The writer suggests adding a special message to the genesis resolution transaction and mentions the possibility of including a witness vector using BIP141 transaction serialization within the extended transaction vector. They also note the enforcement of a consensus dust threshold within the extension block.The deployment name for this specification is "extblk" and appears as "!extblk" in GBT. The writer points out that while the start time for the deactivation deployment is mentioned, there is no information about the timeout or how to continue the extension block. They critique the lack of clarity and specificity in the new BIP and propose alternative solutions. Finally, they caution against specifying policy in BIPs and comment on the potential negative effects of deactivating unused chains. 2017-05-10T01:19:30+00:00 + A proposal has been made for an extension block that would allow atomic swaps between Bitcoin and Xbitcoin. However, there are concerns about the maturity rule and its impact on legacy wallets. Christopher Jeffrey suggests revising the extension block code to coexist with mainchain segwit and require exiting outputs to only be witness programs. This would mitigate the issue assuming most segwit-supporting wallets implement this rule before the activation of segwit.There is also discussion about allowing direct exit payments to legacy addresses and the lock-up period for exiting outputs. One solution is to add a maturity requirement for exiting outputs, but this would make non-upgraded wallets unusable. Another solution is to move all exiting outputs to the coinbase, but this would deteriorate user experience and essentially become a hardfork. It is suggested that switching to witness programs only and requiring exiting outputs to be witness programs may be a good balance between fungibility and backward-compatibility.The proposal also addresses the issue of making return outputs transparent to unupgraded wallets. The proposed solution is to send them to something non-standard today. The mainchain segwit is important in enabling atomic swaps between Bitcoin and Xbitcoin. The extension block specification/code is being revised to coexist with mainchain segwit and require exiting outputs to only be witness programs.In another discussion, Olaoluwa Osuntokun analyzes the xblock proposal and focuses on the sub-proposal for Lightning Network (LN) safety enhancement. The proposal involves a block-size decrease for each open channel within the network, which reserves space for honest parties to punish dishonest channel counter parties. There is also a proposal for a Pre-Allocated Smart-contract Dispute Arena (PASDA) to address systematic risks in the LN. However, the system has not been fully specified and evaluated yet.Overall, the discussions revolve around the proposed extension block, its compatibility with segwit, the issue of direct exit payments to legacy addresses, and the need for a balance between fungibility and backward-compatibility. The proposal also introduces additional safety measures for Lightning Network (LN) and blockchain availability in case of channel disputes.The writer of the context raises concerns about a new Bitcoin Improvement Proposal (BIP) and expresses disappointment that their proposal was not given more consideration. They criticize the lack of specificity in the proposed approach to resolving transaction malleability and suggest changes to how the merkle root is calculated. Additionally, they question whether direct exit payment to legacy addresses should be allowed and propose limiting the number of soft-fork upgrades, increasing the points for witness v0 outputs, and setting a higher dust threshold.A work-in-progress extension block proposal has been introduced by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. The proposal is available on Github and aims to increase bitcoin transaction throughput without altering existing consensus rules. However, the writer argues that extension blocks create additional complexity compared to other proposals and can potentially create two classes of "full nodes," leaving some insecure. They also mention potential issues with the maximum extension size and the validity of output script code in extension blocks.The Witness Vector specification details that every 73 bytes in the serialized witness vector is worth one additional point, but it doesn't explain why this number was chosen. The writer emphasizes the importance of submitting BIPs in MediaWiki format and for discussion on the bitcoin-dev mailing list rather than social media and news outlets. They assert that extension blocks are more like a hard-fork rather than a soft-fork and highlight the potential legal implications of BIPs not being recognized in certain jurisdictions.The UTXO set behaves fundamentally differently with the extension block proposal, but mostly in a compatible manner. Canonical blocks containing entering outputs must have an extension block commitment, even if it contains all zeroes. The writer suggests adding a special message to the genesis resolution transaction and mentions the possibility of including a witness vector using BIP141 transaction serialization within the extended transaction vector. They also note the enforcement of a consensus dust threshold within the extension block.The deployment name for this specification is "extblk" and appears as "!extblk" in GBT. The writer points out that while the start time for the deactivation deployment is mentioned, there is no information about the timeout or how to continue the extension block. They critique the lack of clarity and specificity in the new BIP and propose alternative solutions. Finally, they caution against specifying policy in BIPs and comment on the potential negative effects of deactivating unused chains. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Guessing-the-spentness-status-of-the-pruned-relatives.xml b/static/bitcoin-dev/April_2017/combined_Guessing-the-spentness-status-of-the-pruned-relatives.xml index 9ef61a8812..37b8ad7abb 100644 --- a/static/bitcoin-dev/April_2017/combined_Guessing-the-spentness-status-of-the-pruned-relatives.xml +++ b/static/bitcoin-dev/April_2017/combined_Guessing-the-spentness-status-of-the-pruned-relatives.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Guessing the spentness status of the pruned relatives - 2023-08-01T20:12:13.958943+00:00 + 2025-09-26T15:45:40.918868+00:00 + python-feedgen Bram Cohen 2017-04-03 03:13:52+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Guessing the spentness status of the pruned relatives - 2023-08-01T20:12:13.958943+00:00 + 2025-09-26T15:45:40.919007+00:00 - The scalability of Bitcoin transactions was discussed on the bitcoin-dev mailing list. It was noted that using spentness bits scales linearly compared to swapping digest leafs with empties, which can scale logarithmically but increases storage requirements. The limitation of 8 to 12 layers corresponds to an MMR proof length of 512 to 768 bytes if a 32-byte hash and spentness bits are used. However, making memory commitments smaller would increase CPU requirements and proof size. Full nodes can cache the top layers or remember a root per block to make proofs smaller.Using spentness bits in merkle tree hashes has limitations. Increasing the DLH_REQUIRED beyond 8 has diminishing returns. With a 32-byte hash and spentness bits, pruning is limited to 8 to 12 layers, resulting in an MMR proof length of 512 to 768 bytes. The growth rate of the MMR depends on the number of txos added. Adding 12E6 delayed utxo only txos per year leads to a growth of about 1.5MB (or 5MB) per year, while adding 200E6 txos per year leads to a growth of about 27.5MB (or 80MB) per year. This puts a limit on potential gains through pruning. Increasing the block size may require switching from spentness bits to changing digest nodes to empty nodes.In a discussion between Bram Cohen and Praxeology Guy, the idea of "The TXO bitfield" was presented. This idea suggests changing how the MMR data is modified on spend by moving from changing leaf nodes to changing a node closer to the root. This allows for commitments on the entire TXO set. However, Praxeology Guy still prefers the MMR structure if only UTxOs are added after a long delay. The index changes when delayed additions happen. Bram Cohen appreciated the idea and clarified that it is different from the Patricia Tree for bitcoin txos.Bram Cohen shared his approach to research and development, emphasizing the exploration of interesting ideas and collaboration before making decisions. He expressed his reservations about the Patricia Tree for bitcoin txos, stating that it may be too much work compared to other options. However, he clarified that he wasn't saying the design is bad or won't work but that he personally isn't interested in it at this time.The use of MMR data structure for transaction output (TXO) commitments was discussed in a Bitcoin development discussion. It was suggested that wallets should only keep information relevant to their own spendable coins and maintain the changing MMR proof for their old coins. However, wallets need to know the spentness status of close relatives in the MMR tree to construct a valid MMR proof. An alternative solution called the TXO bitfield was proposed, which would allow wallets to track only the proof of position of their TXO, avoiding the need to keep track of other data.In an email thread, a user suggested committed bloom filters as a solution to similar issues without needing a growing list of spent outputs. Praxeology Guy argued that wallets still need to know the spentness status of close relatives in the MMR tree to construct a valid MMR proof. Bitcoin nodes could keep a spentness status list to address this issue and prevent DoS attacks. However, there was some confusion in the email subject.In summary, the discussion on the scalability of Bitcoin transactions focused on the use of spentness bits and the limitations of the MMR data structure. Different proposals, such as the TXO bitfield and committed bloom filters, were put forward to address the challenges of tracking spent outputs and constructing valid proofs. Bram Cohen emphasized the importance of exploring ideas and collaborating in the research and development process. 2017-04-03T03:13:52+00:00 + The scalability of Bitcoin transactions was discussed on the bitcoin-dev mailing list. It was noted that using spentness bits scales linearly compared to swapping digest leafs with empties, which can scale logarithmically but increases storage requirements. The limitation of 8 to 12 layers corresponds to an MMR proof length of 512 to 768 bytes if a 32-byte hash and spentness bits are used. However, making memory commitments smaller would increase CPU requirements and proof size. Full nodes can cache the top layers or remember a root per block to make proofs smaller.Using spentness bits in merkle tree hashes has limitations. Increasing the DLH_REQUIRED beyond 8 has diminishing returns. With a 32-byte hash and spentness bits, pruning is limited to 8 to 12 layers, resulting in an MMR proof length of 512 to 768 bytes. The growth rate of the MMR depends on the number of txos added. Adding 12E6 delayed utxo only txos per year leads to a growth of about 1.5MB (or 5MB) per year, while adding 200E6 txos per year leads to a growth of about 27.5MB (or 80MB) per year. This puts a limit on potential gains through pruning. Increasing the block size may require switching from spentness bits to changing digest nodes to empty nodes.In a discussion between Bram Cohen and Praxeology Guy, the idea of "The TXO bitfield" was presented. This idea suggests changing how the MMR data is modified on spend by moving from changing leaf nodes to changing a node closer to the root. This allows for commitments on the entire TXO set. However, Praxeology Guy still prefers the MMR structure if only UTxOs are added after a long delay. The index changes when delayed additions happen. Bram Cohen appreciated the idea and clarified that it is different from the Patricia Tree for bitcoin txos.Bram Cohen shared his approach to research and development, emphasizing the exploration of interesting ideas and collaboration before making decisions. He expressed his reservations about the Patricia Tree for bitcoin txos, stating that it may be too much work compared to other options. However, he clarified that he wasn't saying the design is bad or won't work but that he personally isn't interested in it at this time.The use of MMR data structure for transaction output (TXO) commitments was discussed in a Bitcoin development discussion. It was suggested that wallets should only keep information relevant to their own spendable coins and maintain the changing MMR proof for their old coins. However, wallets need to know the spentness status of close relatives in the MMR tree to construct a valid MMR proof. An alternative solution called the TXO bitfield was proposed, which would allow wallets to track only the proof of position of their TXO, avoiding the need to keep track of other data.In an email thread, a user suggested committed bloom filters as a solution to similar issues without needing a growing list of spent outputs. Praxeology Guy argued that wallets still need to know the spentness status of close relatives in the MMR tree to construct a valid MMR proof. Bitcoin nodes could keep a spentness status list to address this issue and prevent DoS attacks. However, there was some confusion in the email subject.In summary, the discussion on the scalability of Bitcoin transactions focused on the use of spentness bits and the limitations of the MMR data structure. Different proposals, such as the TXO bitfield and committed bloom filters, were put forward to address the challenges of tracking spent outputs and constructing valid proofs. Bram Cohen emphasized the importance of exploring ideas and collaborating in the research and development process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml b/static/bitcoin-dev/April_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml index f63baf35ba..6b50bffc04 100644 --- a/static/bitcoin-dev/April_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml +++ b/static/bitcoin-dev/April_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hard fork proposal from last week's meeting - 2023-08-01T20:00:31.147207+00:00 + 2025-09-26T15:46:04.147963+00:00 + python-feedgen Staf Verhaegen 2017-04-02 19:12:06+00:00 @@ -327,13 +328,13 @@ - python-feedgen + 2 Combined summary - Hard fork proposal from last week's meeting - 2023-08-01T20:00:31.150204+00:00 + 2025-09-26T15:46:04.148241+00:00 - The Bitcoin community has been engaged in ongoing discussions about the scalability of Bitcoin and the balance between on-chain scaling and layer two scaling. Some members argue that on-chain bandwidth should be available for layer two scaling to thrive and propose exploring sharding solutions. However, others emphasize the importance of individuals running full nodes on personal computers for security and challenge this assertion.The scalability of processing transactions in a distributed system like Bitcoin is a significant challenge. While network speeds have improved, there is still a debate about raising the block size limit. Some participants believe it is possible but risky, while others suggest waiting until SegWit activates before considering any additional increases.Running full nodes on personal computers is seen as crucial for the security of Bitcoin. There are discussions about the feasibility of running nodes and potential alternatives such as lightweight clients, zero-knowledge proofs, and hardware wallets. Maintaining the security of the Bitcoin network is highly dependent on personal computers.The importance of low node costs and the consequences of high transaction fees are also discussed. Some argue that a true fee-market is needed, where miners can choose to make blocks smaller to increase fees. However, increasing transaction fees may allow other cryptocurrencies to gain market share for low-value use cases. The market will continue to innovate solutions when there is profit to be made.The ongoing debate over block size increases involves different factions with differing opinions. It is crucial to carefully consider the impact on node costs and the potential burden on archival nodes. Before making any changes to the block size, implementing fixes and conducting studies are important steps.Overall, the Bitcoin community is actively discussing the scalability of Bitcoin, the importance of individuals running full nodes on personal computers for security, and the ongoing debate over on-chain scaling versus layer two scaling. The cost implications of running a node capable of handling massive transaction volumes are also being considered. In order to address these challenges and ensure the growth and security of Bitcoin, the community is exploring various solutions and technologies. 2017-04-02T19:12:06+00:00 + The Bitcoin community has been engaged in ongoing discussions about the scalability of Bitcoin and the balance between on-chain scaling and layer two scaling. Some members argue that on-chain bandwidth should be available for layer two scaling to thrive and propose exploring sharding solutions. However, others emphasize the importance of individuals running full nodes on personal computers for security and challenge this assertion.The scalability of processing transactions in a distributed system like Bitcoin is a significant challenge. While network speeds have improved, there is still a debate about raising the block size limit. Some participants believe it is possible but risky, while others suggest waiting until SegWit activates before considering any additional increases.Running full nodes on personal computers is seen as crucial for the security of Bitcoin. There are discussions about the feasibility of running nodes and potential alternatives such as lightweight clients, zero-knowledge proofs, and hardware wallets. Maintaining the security of the Bitcoin network is highly dependent on personal computers.The importance of low node costs and the consequences of high transaction fees are also discussed. Some argue that a true fee-market is needed, where miners can choose to make blocks smaller to increase fees. However, increasing transaction fees may allow other cryptocurrencies to gain market share for low-value use cases. The market will continue to innovate solutions when there is profit to be made.The ongoing debate over block size increases involves different factions with differing opinions. It is crucial to carefully consider the impact on node costs and the potential burden on archival nodes. Before making any changes to the block size, implementing fixes and conducting studies are important steps.Overall, the Bitcoin community is actively discussing the scalability of Bitcoin, the importance of individuals running full nodes on personal computers for security, and the ongoing debate over on-chain scaling versus layer two scaling. The cost implications of running a node capable of handling massive transaction volumes are also being considered. In order to address these challenges and ensure the growth and security of Bitcoin, the community is exploring various solutions and technologies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_High-fees-centralization.xml b/static/bitcoin-dev/April_2017/combined_High-fees-centralization.xml index eb28f83a94..577aa3d7a4 100644 --- a/static/bitcoin-dev/April_2017/combined_High-fees-centralization.xml +++ b/static/bitcoin-dev/April_2017/combined_High-fees-centralization.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - High fees / centralization - 2023-08-01T20:05:59.101814+00:00 - - Staf Verhaegen 2017-04-02 19:45:11+00:00 - - - Vladimir Zaytsev 2017-03-31 02:26:31+00:00 - - - Jared Lee Richardson 2017-03-31 02:01:49+00:00 - - - Vladimir Zaytsev 2017-03-31 01:39:23+00:00 - - - Tom Harding 2017-03-31 01:13:35+00:00 - - - Jared Lee Richardson 2017-03-30 21:52:01+00:00 - - - David Vorick 2017-03-30 16:14:24+00:00 - - - Tom Harding 2017-03-30 15:38:20+00:00 - + 2025-09-26T15:45:55.734277+00:00 + python-feedgen + + + [bitcoin-dev] High fees / centralization Tom Harding + 2017-03-30T15:38:00.000Z + + + David Vorick + 2017-03-30T16:14:00.000Z + + + Jared Lee Richardson + 2017-03-30T21:52:00.000Z + + + Tom Harding + 2017-03-31T01:13:00.000Z + + + Vladimir Zaytsev + 2017-03-31T01:39:00.000Z + + + Jared Lee Richardson + 2017-03-31T02:01:00.000Z + + + Vladimir Zaytsev + 2017-03-31T02:26:00.000Z + + + Staf Verhaegen + 2017-04-02T19:45:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - High fees / centralization - 2023-08-01T20:05:59.102816+00:00 + 2025-09-26T15:45:55.735471+00:00 - Jared Lee Richardson, a member of the bitcoin development community, expressed interest in the concept of blockchain sharding - dividing the blockchain into smaller parts to increase efficiency. However, he expressed doubts about the possibility of resolving conflicts between these shards and committing transactions between them in a trustless manner. Staf suggested a system where different nodes could agree to process parts of transactions, allowing 20,000 nodes to work like 5,000 full nodes.The discussion revolves around the possibility of implementing blockchain sharding in a trustless manner. The concern is about resolving conflicts between the shards and committing transactions between them. Vladimir Zaytsev suggests organizing "branches" of smaller activity to join the main tree after they grow. However, it may not be necessary to accept everything in the chain, and it is too early to record every sight.Jared Lee Richardson points out that fees higher than $1 per transaction are inevitable without blocksize increases, most likely before 2020. He argues that if both monetary sovereignty and supporting daily transactions can be achieved, then why not have both? An altcoin with both will take Bitcoin's monetary sovereignty crown by default.The author suggests that there should be a way to organize "branches" of smaller activity to join the main tree after they grow. They feel that not everything needs to be accepted in the chain and that it is too early to record every sight. The discussion then turns to the topic of transaction fees and whether or not they will become high enough to block home users from using the network. The consensus is that, even without a blocksize increase, most home purchases will be large enough to fit on the blocksize in the foreseeable future. However, it is uncertain what level transaction fees will become unappealing for consumers, with some predicting above $1 per tx, while others predict above $10 as being niche-level. Without a blocksize increase, fees higher than $1/tx are basically inevitable before 2020. The author suggests that if node operational costs are going to be highly weighted, there needs to be a solid justification with mathematical models or examples. The author argues that Bitcoin's core innovation of monetary sovereignty should not be thrown away in pursuit of supporting only 0.1% of the world's daily transactions. They suggest that if both can easily coexist, why not have both? Finally, the author warns that an altcoin with both (monetary sovereignty and support for daily transactions) will take Bitcoin's monetary sovereignty crown by default.In a message exchange between David Vorick and Tom Harding on the bitcoin-dev mailing list, Harding expressed concerns over the effects of rising fees on small miners. He argued that small miners use pools for smaller and more frequent payments, which rising fees will make less feasible, potentially causing them to give up mining altogether. In response, Vorick pointed out that miners get paid once every ten minutes, regardless of the size or number of fee transactions. He also stated that fees are not yet high enough to block home users from using the network, and that it would be unwise to sacrifice the core innovation of monetary sovereignty in order to support a small fraction of daily transactions. However, he acknowledged that rising fees could lead to unintended consequences, such as increased miner centralization and fewer full nodes.The discussion on Bitcoin-dev mailing list revolves around how rising fees could affect the Bitcoin network and its users. While some argue that increasing fees would force home users to stop using the network, others believe that most home purchases will still fit within the blocksize limit even without a blocksize increase. The focus should be on not losing the core innovation of monetary sovereignty in pursuit of supporting only 0.1% of the world's daily transactions. An altcoin with both lower fees and monetary sovereignty would take over Bitcoin's crown. Additionally, small miners who use pools for smaller, more frequent payments would be affected by rising fees and it could lead to centralization of mining power. However, it is argued that fees do not change the payout rate for miners who get paid on average once every ten minutes.In an email to the bitcoin-dev mailing list, Tom Harding responded to Raystonn's argument against small miners using pools by stating that small miners use pools because they want smaller, more frequent payments. Rising fees force them to take payments less frequently and will only lead to more small miners giving up. The centralizing effect is much stronger than the oft-cited worry of small miners joining large pools to decrease orphan rates. According to Harding, miners get paid on average once every ten minutes and the size of fees and number of fee transactions does not change the payout rate. However, he believes that we are still far from the point where fees are high enough to block home users from using the network. Finally, Harding argues that Bitcoin has many high-value use cases such as savings and that the core innovation of monetary sovereignty should not be thrown away in pursuit of supporting 0.1% 2017-04-02T19:45:11+00:00 + Jared Lee Richardson, a member of the bitcoin development community, expressed interest in the concept of blockchain sharding - dividing the blockchain into smaller parts to increase efficiency. However, he expressed doubts about the possibility of resolving conflicts between these shards and committing transactions between them in a trustless manner. Staf suggested a system where different nodes could agree to process parts of transactions, allowing 20,000 nodes to work like 5,000 full nodes.The discussion revolves around the possibility of implementing blockchain sharding in a trustless manner. The concern is about resolving conflicts between the shards and committing transactions between them. Vladimir Zaytsev suggests organizing "branches" of smaller activity to join the main tree after they grow. However, it may not be necessary to accept everything in the chain, and it is too early to record every sight.Jared Lee Richardson points out that fees higher than $1 per transaction are inevitable without blocksize increases, most likely before 2020. He argues that if both monetary sovereignty and supporting daily transactions can be achieved, then why not have both? An altcoin with both will take Bitcoin's monetary sovereignty crown by default.The author suggests that there should be a way to organize "branches" of smaller activity to join the main tree after they grow. They feel that not everything needs to be accepted in the chain and that it is too early to record every sight. The discussion then turns to the topic of transaction fees and whether or not they will become high enough to block home users from using the network. The consensus is that, even without a blocksize increase, most home purchases will be large enough to fit on the blocksize in the foreseeable future. However, it is uncertain what level transaction fees will become unappealing for consumers, with some predicting above $1 per tx, while others predict above $10 as being niche-level. Without a blocksize increase, fees higher than $1/tx are basically inevitable before 2020. The author suggests that if node operational costs are going to be highly weighted, there needs to be a solid justification with mathematical models or examples. The author argues that Bitcoin's core innovation of monetary sovereignty should not be thrown away in pursuit of supporting only 0.1% of the world's daily transactions. They suggest that if both can easily coexist, why not have both? Finally, the author warns that an altcoin with both (monetary sovereignty and support for daily transactions) will take Bitcoin's monetary sovereignty crown by default.In a message exchange between David Vorick and Tom Harding on the bitcoin-dev mailing list, Harding expressed concerns over the effects of rising fees on small miners. He argued that small miners use pools for smaller and more frequent payments, which rising fees will make less feasible, potentially causing them to give up mining altogether. In response, Vorick pointed out that miners get paid once every ten minutes, regardless of the size or number of fee transactions. He also stated that fees are not yet high enough to block home users from using the network, and that it would be unwise to sacrifice the core innovation of monetary sovereignty in order to support a small fraction of daily transactions. However, he acknowledged that rising fees could lead to unintended consequences, such as increased miner centralization and fewer full nodes.The discussion on Bitcoin-dev mailing list revolves around how rising fees could affect the Bitcoin network and its users. While some argue that increasing fees would force home users to stop using the network, others believe that most home purchases will still fit within the blocksize limit even without a blocksize increase. The focus should be on not losing the core innovation of monetary sovereignty in pursuit of supporting only 0.1% of the world's daily transactions. An altcoin with both lower fees and monetary sovereignty would take over Bitcoin's crown. Additionally, small miners who use pools for smaller, more frequent payments would be affected by rising fees and it could lead to centralization of mining power. However, it is argued that fees do not change the payout rate for miners who get paid on average once every ten minutes.In an email to the bitcoin-dev mailing list, Tom Harding responded to Raystonn's argument against small miners using pools by stating that small miners use pools because they want smaller, more frequent payments. Rising fees force them to take payments less frequently and will only lead to more small miners giving up. The centralizing effect is much stronger than the oft-cited worry of small miners joining large pools to decrease orphan rates. According to Harding, miners get paid on average once every ten minutes and the size of fees and number of fee transactions does not change the payout rate. However, he believes that we are still far from the point where fees are high enough to block home users from using the network. Finally, Harding argues that Bitcoin has many high-value use cases such as savings and that the core innovation of monetary sovereignty should not be thrown away in pursuit of supporting 0.1% - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_I-do-not-support-the-BIP-148-UASF.xml b/static/bitcoin-dev/April_2017/combined_I-do-not-support-the-BIP-148-UASF.xml index 0ced82c7a1..8d1f7a6e1d 100644 --- a/static/bitcoin-dev/April_2017/combined_I-do-not-support-the-BIP-148-UASF.xml +++ b/static/bitcoin-dev/April_2017/combined_I-do-not-support-the-BIP-148-UASF.xml @@ -1,131 +1,175 @@ - + 2 Combined summary - I do not support the BIP 148 UASF - 2023-08-01T20:25:06.816096+00:00 - - Jorge Timón 2017-05-23 13:20:10+00:00 - - - Luke Dashjr 2017-05-23 12:55:26+00:00 - - - Hampus Sjöberg 2017-05-23 09:47:48+00:00 - - - Karl Johan Alm 2017-05-23 06:30:01+00:00 - - - Steven Pine 2017-05-23 04:03:49+00:00 - - - Suhas Daftuar 2017-05-22 19:23:22+00:00 - - - Erik Aronesty 2017-05-02 16:54:35+00:00 - - - Luke Dashjr 2017-04-25 18:46:09+00:00 - - - Gregory Maxwell 2017-04-25 18:28:14+00:00 - - - shaolinfry 2017-04-20 18:39:36+00:00 - - - Erik Aronesty 2017-04-20 15:48:21+00:00 - - - Alphonse Pace 2017-04-20 14:23:40+00:00 - - - Erik Aronesty 2017-04-19 16:17:39+00:00 - - - Gregory Maxwell 2017-04-15 18:50:17+00:00 - - - Ryan Grant 2017-04-15 14:54:00+00:00 - - - Greg Sanders 2017-04-15 13:54:57+00:00 - - - Mark Friedenbach 2017-04-15 13:42:25+00:00 - - - Natanael 2017-04-15 13:23:35+00:00 - - - Cameron Garnham 2017-04-15 08:05:10+00:00 - - - Chris Acheson 2017-04-15 07:46:47+00:00 - - - Gregory Maxwell 2017-04-15 07:04:45+00:00 - - - Cameron Garnham 2017-04-15 06:28:41+00:00 - - - Gregory Maxwell 2017-04-15 04:47:43+00:00 - - - Steven Pine 2017-04-15 04:10:26+00:00 - - - Gregory Maxwell 2017-04-15 03:29:10+00:00 - - - Chris Stewart 2017-04-15 03:05:25+00:00 - - - Steven Pine 2017-04-15 02:01:17+00:00 - - - Gregory Maxwell 2017-04-14 21:12:47+00:00 - - - James Hilliard 2017-04-14 21:10:46+00:00 - - - Gregory Maxwell 2017-04-14 20:59:55+00:00 - - - Tom Zander 2017-04-14 20:58:15+00:00 - - - James Hilliard 2017-04-14 20:51:04+00:00 - - - Tom Zander 2017-04-14 20:34:26+00:00 - - - James Hilliard 2017-04-14 19:33:49+00:00 - - - Tom Zander 2017-04-14 19:20:39+00:00 - - - Tom Zander 2017-04-14 19:12:19+00:00 - - - praxeology_guy 2017-04-14 18:33:39+00:00 - - - Chris Stewart 2017-04-14 17:36:34+00:00 - - - praxeology_guy 2017-04-14 16:50:47+00:00 - - - Chris Acheson 2017-04-14 10:52:46+00:00 - - - Gregory Maxwell 2017-04-14 07:56:31+00:00 - + 2025-09-26T15:46:18.890008+00:00 + python-feedgen + + + [bitcoin-dev] I do not support the BIP 148 UASF Gregory Maxwell + 2017-04-14T07:56:00.000Z + + + Chris Acheson + 2017-04-14T10:52:00.000Z + + + praxeology_guy + 2017-04-14T16:50:00.000Z + + + Chris Stewart + 2017-04-14T17:36:00.000Z + + + praxeology_guy + 2017-04-14T18:33:00.000Z + + + Tom Zander + 2017-04-14T19:12:00.000Z + + + Tom Zander + 2017-04-14T19:20:00.000Z + + + James Hilliard + 2017-04-14T19:33:00.000Z + + + Tom Zander + 2017-04-14T20:34:00.000Z + + + James Hilliard + 2017-04-14T20:51:00.000Z + + + Tom Zander + 2017-04-14T20:58:00.000Z + + + Gregory Maxwell + 2017-04-14T20:59:00.000Z + + + James Hilliard + 2017-04-14T21:10:00.000Z + + + Gregory Maxwell + 2017-04-14T21:12:00.000Z + + + Steven Pine + 2017-04-15T02:01:00.000Z + + + Chris Stewart + 2017-04-15T03:05:00.000Z + + + Gregory Maxwell + 2017-04-15T03:29:00.000Z + + + Steven Pine + 2017-04-15T04:10:00.000Z + + + Gregory Maxwell + 2017-04-15T04:47:00.000Z + + + Cameron Garnham + 2017-04-15T06:28:00.000Z + + + Gregory Maxwell + 2017-04-15T07:04:00.000Z + + + Chris Acheson + 2017-04-15T07:46:00.000Z + + + Cameron Garnham + 2017-04-15T08:05:00.000Z + + + Natanael + 2017-04-15T13:23:00.000Z + + + Mark Friedenbach + 2017-04-15T13:42:00.000Z + + + Greg Sanders + 2017-04-15T13:54:00.000Z + + + Ryan Grant + 2017-04-15T14:54:00.000Z + + + Gregory Maxwell + 2017-04-15T18:50:00.000Z + + + Erik Aronesty + 2017-04-19T16:17:00.000Z + + + Alphonse Pace + 2017-04-20T14:23:00.000Z + + + Erik Aronesty + 2017-04-20T15:48:00.000Z + + + shaolinfry + 2017-04-20T18:39:00.000Z + + + Gregory Maxwell + 2017-04-25T18:28:00.000Z + + + Luke Dashjr + 2017-04-25T18:46:00.000Z + + + Erik Aronesty + 2017-05-02T16:54:00.000Z + + + Suhas Daftuar + 2017-05-22T19:23:00.000Z + + + Steven Pine + 2017-05-23T04:03:00.000Z + + + Karl Johan Alm + 2017-05-23T06:30:00.000Z + + + Hampus Sjöberg + 2017-05-23T09:47:00.000Z + + + Luke Dashjr + 2017-05-23T12:55:00.000Z + + + Jorge Timón + 2017-05-23T13:20:00.000Z + + @@ -167,13 +211,13 @@ - python-feedgen + 2 Combined summary - I do not support the BIP 148 UASF - 2023-08-01T20:25:06.816096+00:00 + 2025-09-26T15:46:18.894487+00:00 - The ongoing discussion within the bitcoin-dev community revolves around the activation of Segwit in Bitcoin. There are debates and concerns raised regarding the User Activated Soft Fork (UASF) proposal for activating soft forks. One member questions the requirement for public support while not allowing members to express doubts about the UASF proposal. Concerns are raised about the effectiveness and reliability of UASF, as well as the potential for consensus bugs and the inability for nodes to identify invalid transactions.Another member expresses disappointment over public statements against UASF proposals, stating that they detract from grassroots efforts. Mark Friedenbach suggests a new proposal called "Catch-All Segwit Activation" as a potential solution to address this issue.Discussions focus on the safety and effectiveness of UASFs, with arguments made for orphaning non-compliant blocks on the flag date rather than considering the fork active on that date. Concerns about consensus bugs and the lack of communication between nodes regarding invalid transactions are also raised.The controversy surrounding BIP16 vs BIP17 is discussed, with criticisms of the inferior solution resulting from the split. The need for careful review and consideration of specific proposals is emphasized, rather than rushing to implement something quickly. The ongoing scaling debate within the Bitcoin community is mentioned, with calls for a quick resolution and the prioritization of user needs over miners.Conversations also address the technical requirements for timeout and bit assignments in BIP9. BIP148 is classified as a "user enforced miner soft-fork activation" rather than a UASF. The limitation of this approach, in terms of disruptiveness, is acknowledged.Discussions touch on the activation of SegWit and the expectations surrounding it. It is clarified that SegWit will continue to be used until a better solution comes along or interest in it diminishes. The lack of a clear definition of "the core team" is highlighted, making it difficult for outsiders to make credible proposals without contributing to the project. Caution is urged, with a reminder that changes in decentralized systems like Bitcoin cannot be expected to happen at the same speed as centralized systems.Overall, the discussions revolve around the effectiveness, safety, and controversies surrounding UASFs, BIPs, and the activation of SegWit in the Bitcoin community.Gregory Maxwell expresses reservations about the UASF approach to force Segwit activation, advocating for a patient approach instead. He suggests alternative ways to achieve the benefits of Segwit, such as removing the discount on signature data to address UTXO bloat. Despite differences in approach, most agree that Segwit will bring significant improvements to Bitcoin, including the elimination of transaction malleability and script versioning.Maxwell supports Segwit but criticizes the BIP148 UASF proposal for its disruptive nature. He believes that the forced activation of existing nodes almost guarantees disruption, while Segwit was designed to allow older unmodified miners to continue operating without interruption. Maxwell emphasizes the importance of maintaining Bitcoin's engineering standards and stability, suggesting less disruptive mechanisms and patience in activating Segwit.Discussions address the risk of non-upgraded nodes mining invalid blocks on a SegWit network. While there are concerns, it is clarified that the only real risk lies in intentionally mining on top of an invalid block, which is unlikely to happen accidentally.The conversation delves into the policy and protocol rules for mining transactions on the blockchain. It is explained that policy rules are not guaranteed to be present on all mining nodes, necessitating consensus rule enforcement to avoid chain forks.Concerns about orphaning and forking caused by the BIP148 proposal are discussed. Suggestions are made to reject only blocks containing Segwit transactions rather than rejecting all pre-Segwit transaction blocks. Various proposals for a reliable activation method are discussed, with differing opinions on the most practical approach. However, it is agreed that Segwit has undergone enough testing and it is time to activate it.There are arguments about the disruptive nature of the BIP148 UASF proposal for miners who do not upgrade. Alternative proposals aim to avoid forced disruption by allowing non-upgraded miners and nodes to continue operating as non-upgraded. The prioritization of minimizing disruption for users is emphasized, with the expectation that all miners will eventually upgrade after the initial disruption. The forced orphaning aspect of the proposal is seen as an unavoidable side-effect to make the UASF less disruptive for Bitcoin users.The author of this piece supports the implementation of segwit in Bitcoin but expresses their lack of support for the BIP148 UASF proposal. They argue that BIP148 does not meet the same engineering standards as segwit and best practices in protocol development. The main flaw with BIP148 is the forced activation of existing nodes, which may cause minor disruption. In contrast, segwit was designed to ensure that older unmodified miners could continue operating without interruption after activation.While acknowledging the motivation behind the BIP148 proposal, the author believes it falls short of the normal standards upheld by the Bitcoin 2017-05-23T13:20:10+00:00 + The ongoing discussion within the bitcoin-dev community revolves around the activation of Segwit in Bitcoin. There are debates and concerns raised regarding the User Activated Soft Fork (UASF) proposal for activating soft forks. One member questions the requirement for public support while not allowing members to express doubts about the UASF proposal. Concerns are raised about the effectiveness and reliability of UASF, as well as the potential for consensus bugs and the inability for nodes to identify invalid transactions.Another member expresses disappointment over public statements against UASF proposals, stating that they detract from grassroots efforts. Mark Friedenbach suggests a new proposal called "Catch-All Segwit Activation" as a potential solution to address this issue.Discussions focus on the safety and effectiveness of UASFs, with arguments made for orphaning non-compliant blocks on the flag date rather than considering the fork active on that date. Concerns about consensus bugs and the lack of communication between nodes regarding invalid transactions are also raised.The controversy surrounding BIP16 vs BIP17 is discussed, with criticisms of the inferior solution resulting from the split. The need for careful review and consideration of specific proposals is emphasized, rather than rushing to implement something quickly. The ongoing scaling debate within the Bitcoin community is mentioned, with calls for a quick resolution and the prioritization of user needs over miners.Conversations also address the technical requirements for timeout and bit assignments in BIP9. BIP148 is classified as a "user enforced miner soft-fork activation" rather than a UASF. The limitation of this approach, in terms of disruptiveness, is acknowledged.Discussions touch on the activation of SegWit and the expectations surrounding it. It is clarified that SegWit will continue to be used until a better solution comes along or interest in it diminishes. The lack of a clear definition of "the core team" is highlighted, making it difficult for outsiders to make credible proposals without contributing to the project. Caution is urged, with a reminder that changes in decentralized systems like Bitcoin cannot be expected to happen at the same speed as centralized systems.Overall, the discussions revolve around the effectiveness, safety, and controversies surrounding UASFs, BIPs, and the activation of SegWit in the Bitcoin community.Gregory Maxwell expresses reservations about the UASF approach to force Segwit activation, advocating for a patient approach instead. He suggests alternative ways to achieve the benefits of Segwit, such as removing the discount on signature data to address UTXO bloat. Despite differences in approach, most agree that Segwit will bring significant improvements to Bitcoin, including the elimination of transaction malleability and script versioning.Maxwell supports Segwit but criticizes the BIP148 UASF proposal for its disruptive nature. He believes that the forced activation of existing nodes almost guarantees disruption, while Segwit was designed to allow older unmodified miners to continue operating without interruption. Maxwell emphasizes the importance of maintaining Bitcoin's engineering standards and stability, suggesting less disruptive mechanisms and patience in activating Segwit.Discussions address the risk of non-upgraded nodes mining invalid blocks on a SegWit network. While there are concerns, it is clarified that the only real risk lies in intentionally mining on top of an invalid block, which is unlikely to happen accidentally.The conversation delves into the policy and protocol rules for mining transactions on the blockchain. It is explained that policy rules are not guaranteed to be present on all mining nodes, necessitating consensus rule enforcement to avoid chain forks.Concerns about orphaning and forking caused by the BIP148 proposal are discussed. Suggestions are made to reject only blocks containing Segwit transactions rather than rejecting all pre-Segwit transaction blocks. Various proposals for a reliable activation method are discussed, with differing opinions on the most practical approach. However, it is agreed that Segwit has undergone enough testing and it is time to activate it.There are arguments about the disruptive nature of the BIP148 UASF proposal for miners who do not upgrade. Alternative proposals aim to avoid forced disruption by allowing non-upgraded miners and nodes to continue operating as non-upgraded. The prioritization of minimizing disruption for users is emphasized, with the expectation that all miners will eventually upgrade after the initial disruption. The forced orphaning aspect of the proposal is seen as an unavoidable side-effect to make the UASF less disruptive for Bitcoin users.The author of this piece supports the implementation of segwit in Bitcoin but expresses their lack of support for the BIP148 UASF proposal. They argue that BIP148 does not meet the same engineering standards as segwit and best practices in protocol development. The main flaw with BIP148 is the forced activation of existing nodes, which may cause minor disruption. In contrast, segwit was designed to ensure that older unmodified miners could continue operating without interruption after activation.While acknowledging the motivation behind the BIP148 proposal, the author believes it falls short of the normal standards upheld by the Bitcoin - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Malice-Reactive-Proof-of-Work-Additions-MR-POWA-Protecting-Bitcoin-from-malicious-miners.xml b/static/bitcoin-dev/April_2017/combined_Malice-Reactive-Proof-of-Work-Additions-MR-POWA-Protecting-Bitcoin-from-malicious-miners.xml index 0751922306..070f759743 100644 --- a/static/bitcoin-dev/April_2017/combined_Malice-Reactive-Proof-of-Work-Additions-MR-POWA-Protecting-Bitcoin-from-malicious-miners.xml +++ b/static/bitcoin-dev/April_2017/combined_Malice-Reactive-Proof-of-Work-Additions-MR-POWA-Protecting-Bitcoin-from-malicious-miners.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners - 2023-08-01T19:47:38.144810+00:00 - - Natanael 2017-04-17 22:34:55+00:00 - - - Erik Aronesty 2017-04-17 11:17:17+00:00 - - - Erik Aronesty 2017-04-17 07:47:48+00:00 - - - bfd at cock.lu 2017-04-17 01:28:56+00:00 - - - Erik Aronesty 2017-04-16 20:04:56+00:00 - - - John Hardy 2017-03-20 21:29:29+00:00 - - - John Hardy 2017-03-20 21:23:17+00:00 - - - David Vorick 2017-03-20 18:51:51+00:00 - - - Nick ODell 2017-03-20 18:02:52+00:00 - - - Bram Cohen 2017-03-20 17:49:59+00:00 - - - Andrew Johnson 2017-03-20 16:10:32+00:00 - - - Marcos mayorga 2017-03-20 15:55:41+00:00 - - - John Hardy 2017-03-20 15:46:28+00:00 - - - Andrew Johnson 2017-03-20 15:38:01+00:00 - - - John Hardy 2017-03-18 16:01:08+00:00 - + 2025-09-26T15:46:02.030806+00:00 + python-feedgen + + + [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners John Hardy + 2017-03-18T16:01:00.000Z + + + Andrew Johnson + 2017-03-20T15:38:00.000Z + + + John Hardy + 2017-03-20T15:46:00.000Z + + + Marcos mayorga + 2017-03-20T15:55:00.000Z + + + Andrew Johnson + 2017-03-20T16:10:00.000Z + + + Bram Cohen + 2017-03-20T17:49:00.000Z + + + Nick ODell + 2017-03-20T18:02:00.000Z + + + David Vorick + 2017-03-20T18:51:00.000Z + + + John Hardy + 2017-03-20T21:23:00.000Z + + + John Hardy + 2017-03-20T21:29:00.000Z + + + Erik Aronesty + 2017-04-16T20:04:00.000Z + + + bfd + 2017-04-17T01:28:00.000Z + + + Erik Aronesty + 2017-04-17T07:47:00.000Z + + + Erik Aronesty + 2017-04-17T11:17:00.000Z + + + Natanael + 2017-04-17T22:34:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners - 2023-08-01T19:47:38.144810+00:00 + 2025-09-26T15:46:02.032652+00:00 - John Hardy proposes the implementation of Malicious Miner Reactive Proof of Work Additions (MR POWA) as a solution to the issue of miner centralization in Bitcoin. This proposal suggests introducing multiple new proofs of work (PoW) that have been proven in altcoin implementations, such as Scrypt, Ethash, and Equihash. The goal is to diversify hardware and reduce the impact of subsidized or inexpensive electricity in certain regions.MR POWA would be activated as a hard fork in response to a malicious attempt by a hashpower majority to introduce a contentious hard fork. Instead of completely eliminating SHA256 as a hashing method and changing the PoW algorithm, Hardy recommends adding new PoWs to diversify hardware. This approach would improve decentralization.Under MR POWA, there would be four proofs of work with a 40-minute block target difficulty for each. Additionally, a rule could be implemented where two different proofs of work must find a block before a method can start hashing again. This ensures that only 50% of hardware is hashing at any given time, preventing a sudden gain or drop in hashpower from significantly impacting the network.Hardy believes that MR POWA would serve as a deterrent to malicious actors attempting to abuse their position and create a huge risk for them. If consensus were to form around a future hard fork, nodes would be able to upgrade, and MR POWA would have no economic significance on non-upgraded nodes, resulting in an immediately abandoned vestigial chain with no miner incentive.Overall, Hardy sees MR POWA as a proactive measure to prevent malicious use of hashpower and emphasizes that Bitcoin's strength lies in the ability of the economic majority to find solutions to emerging challenges. 2017-04-17T22:34:55+00:00 + John Hardy proposes the implementation of Malicious Miner Reactive Proof of Work Additions (MR POWA) as a solution to the issue of miner centralization in Bitcoin. This proposal suggests introducing multiple new proofs of work (PoW) that have been proven in altcoin implementations, such as Scrypt, Ethash, and Equihash. The goal is to diversify hardware and reduce the impact of subsidized or inexpensive electricity in certain regions.MR POWA would be activated as a hard fork in response to a malicious attempt by a hashpower majority to introduce a contentious hard fork. Instead of completely eliminating SHA256 as a hashing method and changing the PoW algorithm, Hardy recommends adding new PoWs to diversify hardware. This approach would improve decentralization.Under MR POWA, there would be four proofs of work with a 40-minute block target difficulty for each. Additionally, a rule could be implemented where two different proofs of work must find a block before a method can start hashing again. This ensures that only 50% of hardware is hashing at any given time, preventing a sudden gain or drop in hashpower from significantly impacting the network.Hardy believes that MR POWA would serve as a deterrent to malicious actors attempting to abuse their position and create a huge risk for them. If consensus were to form around a future hard fork, nodes would be able to upgrade, and MR POWA would have no economic significance on non-upgraded nodes, resulting in an immediately abandoned vestigial chain with no miner incentive.Overall, Hardy sees MR POWA as a proactive measure to prevent malicious use of hashpower and emphasizes that Bitcoin's strength lies in the ability of the economic majority to find solutions to emerging challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Praxeological-Analysis-of-PoW-Policy-Changes-Re-ASICBOOST.xml b/static/bitcoin-dev/April_2017/combined_Praxeological-Analysis-of-PoW-Policy-Changes-Re-ASICBOOST.xml index 8c7af542ad..37c6d3824f 100644 --- a/static/bitcoin-dev/April_2017/combined_Praxeological-Analysis-of-PoW-Policy-Changes-Re-ASICBOOST.xml +++ b/static/bitcoin-dev/April_2017/combined_Praxeological-Analysis-of-PoW-Policy-Changes-Re-ASICBOOST.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Praxeological Analysis of PoW Policy Changes, Re: ASICBOOST - 2023-08-01T20:18:21.456780+00:00 - - praxeology_guy 2017-04-07 00:11:00+00:00 - - - praxeology_guy 2017-04-06 20:12:21+00:00 - + 2025-09-26T15:45:57.824144+00:00 + python-feedgen + + + [bitcoin-dev] Praxeological Analysis of PoW Policy Changes, Re: ASICBOOST praxeology_guy + 2017-04-06T20:12:00.000Z + + + praxeology_guy + 2017-04-07T00:11:00.000Z + + - python-feedgen + 2 Combined summary - Praxeological Analysis of PoW Policy Changes, Re: ASICBOOST - 2023-08-01T20:18:21.457780+00:00 + 2025-09-26T15:45:57.824706+00:00 - Efficient mining hardware development plays a crucial role in ensuring the long-term viability of Bitcoin transactions. The recent controversy surrounding the use of ASICBOOST technology highlights the need for careful policy changes to safeguard against patent-encumbered optimizations that could potentially hinder research and development efforts. Gregory Maxwell's proposed BIP, which aims to block the covert optimization of ASICBOOST, is seen as a positive step towards addressing this issue.The article confirms claims that the covert use of ASICBOOST could generate profits of up to $100 million USD annually. However, it also emphasizes the differing motivations of miners and money owners. While miners are primarily concerned with short-term return on investment, money owners prioritize a decentralized Proof of Work algorithm. It is important to note that any changes to the PoW algorithm must be made cautiously to avoid rendering existing ASIC miner capital worthless, as doing so could inadvertently centralize mining operations.Gregory Maxwell's proposal addresses this concern by specifically targeting the patent-encumbered optimization of ASICBOOST without rendering existing mining capital useless. The article suggests implementing a policy that counters or prevents patent-encumbered PoW optimizations while minimizing disruptions to the utility and availability of optimized mining equipment. To support this initiative, owners of Bitcoin are urged to endorse and activate the proposed PoW policy change as soon as possible.Looking towards the future, the article recommends designing future ASICs and mining equipment with the flexibility to operate without assumptions about potential policy changes. This would allow for adaptability in the face of future soft forks, preventing the need for significant hardware alterations. By adopting these measures, the Bitcoin community can effectively combat the issues associated with the ASICBOOST patent encumbrance and ensure the continued progress of the mining industry. 2017-04-07T00:11:00+00:00 + Efficient mining hardware development plays a crucial role in ensuring the long-term viability of Bitcoin transactions. The recent controversy surrounding the use of ASICBOOST technology highlights the need for careful policy changes to safeguard against patent-encumbered optimizations that could potentially hinder research and development efforts. Gregory Maxwell's proposed BIP, which aims to block the covert optimization of ASICBOOST, is seen as a positive step towards addressing this issue.The article confirms claims that the covert use of ASICBOOST could generate profits of up to $100 million USD annually. However, it also emphasizes the differing motivations of miners and money owners. While miners are primarily concerned with short-term return on investment, money owners prioritize a decentralized Proof of Work algorithm. It is important to note that any changes to the PoW algorithm must be made cautiously to avoid rendering existing ASIC miner capital worthless, as doing so could inadvertently centralize mining operations.Gregory Maxwell's proposal addresses this concern by specifically targeting the patent-encumbered optimization of ASICBOOST without rendering existing mining capital useless. The article suggests implementing a policy that counters or prevents patent-encumbered PoW optimizations while minimizing disruptions to the utility and availability of optimized mining equipment. To support this initiative, owners of Bitcoin are urged to endorse and activate the proposed PoW policy change as soon as possible.Looking towards the future, the article recommends designing future ASICs and mining equipment with the flexibility to operate without assumptions about potential policy changes. This would allow for adaptability in the face of future soft forks, preventing the need for significant hardware alterations. By adopting these measures, the Bitcoin community can effectively combat the issues associated with the ASICBOOST patent encumbrance and ensure the continued progress of the mining industry. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Proof-of-Loss.xml b/static/bitcoin-dev/April_2017/combined_Proof-of-Loss.xml index 275b42b983..e30465b547 100644 --- a/static/bitcoin-dev/April_2017/combined_Proof-of-Loss.xml +++ b/static/bitcoin-dev/April_2017/combined_Proof-of-Loss.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Proof-of-Loss - 2023-08-01T19:30:46.090435+00:00 - - Mirelo 2018-01-04 10:54:31+00:00 - - - Mirelo 2017-04-06 05:47:17+00:00 - - - Erik Aronesty 2017-04-06 02:43:18+00:00 - - - Mirelo 2017-04-05 19:12:20+00:00 - - - Mirelo 2017-02-04 12:39:45+00:00 - + 2025-09-26T15:45:59.913152+00:00 + python-feedgen + + + [bitcoin-dev] Proof-of-Loss Mirelo + 2017-02-04T12:39:00.000Z + + + Mirelo + 2017-04-05T19:12:00.000Z + + + Erik Aronesty + 2017-04-06T02:43:00.000Z + + + Mirelo + 2017-04-06T05:47:00.000Z + + + [bitcoin-dev] Proof-of-Loss Mirelo + 2018-01-04T10:54:00.000Z + + - python-feedgen + 2 Combined summary - Proof-of-Loss - 2023-08-01T19:30:46.091448+00:00 + 2025-09-26T15:45:59.913927+00:00 - Mirelo, the creator of Proof-of-Loss, has made revisions to the algorithm and is seeking feedback. The updated version includes a more explicit definition of transaction rights, an overview of how the algorithm works, and the incorporation of the current block height in the proof-of-loss data. Mirelo has requested feedback through his email or the links provided on the Proof-of-Loss homepage. The revised algorithm also corrects transaction prioritization and inactivity fees, as well as revises the design. Proof-of-Loss is an alternative consensus algorithm that aims to address the deficiencies of both proof-of-work and proof-of-stake. It tackles issues such as mining centralization and the "nothing at stake" problem. In an email to bitcoin-dev, Mirelo acknowledges that previous feedback indicated the article was difficult to comprehend, prompting him to make revisions. The new version clarifies transaction rights and provides an overview of the algorithm's functioning. Additionally, the inclusion of the current block height in the proof-of-loss data simplifies the enforcement of serial chaining without requiring additional block height information. The updated version can be accessed at https://proof-of-loss.money/. The revised Proof-of-Loss algorithm incorporates suggestions received from feedback. It addresses the need for a clearer definition of transaction rights and a comprehensive explanation of the algorithm's operation. The updated version also facilitates serial chaining through the integration of the current block height in the proof-of-loss data. Furthermore, it rectifies transaction prioritization by utilizing fees rather than rights, and includes adjustments to inactivity fees. The new version of the algorithm is available at https://proof-of-loss.money/. Proof-of-Loss presents a novel consensus algorithm that seeks to overcome the limitations of both proof-of-work and proof-of-stake. Its objective is to resolve issues such as the absence of an organic block size limit, risks associated with mining centralization, and the "nothing at stake" problem. A detailed explanation of the algorithm can be found on the proof-of-loss.money website. 2018-01-04T10:54:31+00:00 + Mirelo, the creator of Proof-of-Loss, has made revisions to the algorithm and is seeking feedback. The updated version includes a more explicit definition of transaction rights, an overview of how the algorithm works, and the incorporation of the current block height in the proof-of-loss data. Mirelo has requested feedback through his email or the links provided on the Proof-of-Loss homepage. The revised algorithm also corrects transaction prioritization and inactivity fees, as well as revises the design. Proof-of-Loss is an alternative consensus algorithm that aims to address the deficiencies of both proof-of-work and proof-of-stake. It tackles issues such as mining centralization and the "nothing at stake" problem. In an email to bitcoin-dev, Mirelo acknowledges that previous feedback indicated the article was difficult to comprehend, prompting him to make revisions. The new version clarifies transaction rights and provides an overview of the algorithm's functioning. Additionally, the inclusion of the current block height in the proof-of-loss data simplifies the enforcement of serial chaining without requiring additional block height information. The updated version can be accessed at https://proof-of-loss.money/. The revised Proof-of-Loss algorithm incorporates suggestions received from feedback. It addresses the need for a clearer definition of transaction rights and a comprehensive explanation of the algorithm's operation. The updated version also facilitates serial chaining through the integration of the current block height in the proof-of-loss data. Furthermore, it rectifies transaction prioritization by utilizing fees rather than rights, and includes adjustments to inactivity fees. The new version of the algorithm is available at https://proof-of-loss.money/. Proof-of-Loss presents a novel consensus algorithm that seeks to overcome the limitations of both proof-of-work and proof-of-stake. Its objective is to resolve issues such as the absence of an organic block size limit, risks associated with mining centralization, and the "nothing at stake" problem. A detailed explanation of the algorithm can be found on the proof-of-loss.money website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Properties-of-an-ideal-PoW-algorithm-implementation.xml b/static/bitcoin-dev/April_2017/combined_Properties-of-an-ideal-PoW-algorithm-implementation.xml index bd2258d253..1a27fe896d 100644 --- a/static/bitcoin-dev/April_2017/combined_Properties-of-an-ideal-PoW-algorithm-implementation.xml +++ b/static/bitcoin-dev/April_2017/combined_Properties-of-an-ideal-PoW-algorithm-implementation.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Properties of an ideal PoW algorithm & implementation - 2023-08-01T20:30:55.007540+00:00 - - Bram Cohen 2017-04-19 17:43:03+00:00 - - - Tim Ruffing 2017-04-19 11:08:15+00:00 - - - praxeology_guy 2017-04-18 19:14:05+00:00 - - - Natanael 2017-04-18 10:34:04+00:00 - + 2025-09-26T15:46:10.445608+00:00 + python-feedgen + + + [bitcoin-dev] Properties of an ideal PoW algorithm & implementation Natanael + 2017-04-18T10:34:00.000Z + + + praxeology_guy + 2017-04-18T19:14:00.000Z + + + Tim Ruffing + 2017-04-19T11:08:00.000Z + + + Bram Cohen + 2017-04-19T17:43:00.000Z + + - python-feedgen + 2 Combined summary - Properties of an ideal PoW algorithm & implementation - 2023-08-01T20:30:55.008538+00:00 + 2025-09-26T15:46:10.446223+00:00 - The author suggests using a repeated hashing method with blake2b to prevent lossy implementations and avoid relying on a single crypto primitive. Blake2b is conservative due to its large block size, which prevents asicboost-style attacks and eliminates the need for building logic for multiple blocks. Memory hard functions are effective but fail catastrophically when they do, limiting their use to hardware from a single vendor. The best PoW function for commodity mining hardware is repeatedly hashing with blake2b ten or a hundred times. However, the author believes that hard forking the PoW function is not a good idea.Natanael discusses the idea of proving optimal implementation for hash functions in an email thread. While it is a good idea in theory, it seems impossible to prove currently. He also suggests avoiding internal state reuse through measures such as "whitening" and pre-hashing to prevent ASICBOOST type optimizations. A slower hash function or iterating the hash function multiple times could be used practically. PoW verification will still be fast enough, and memory-hard functions are currently the best option for PoW functions.The cost of producing a chip depends on the number of metal layers required for routing interconnects in a particular area. Fewer layers mean quicker and easier manufacturing, and fewer patentable costs. A paper discussing factors impacting chip design costs has been linked, although its validity cannot be vouched for. To minimize asicboost-like optimizations, there needs to be early nonce mixing with variable-length input that has near-constant work. The entirety of the input should be mixed with the nonce data as soon as possible to prevent unexpected optimizations. A hash algorithm with more linear computation time versus input size would be ideal. It would consist of a first-stage Merkle tree hash to pre-lossy-mix-compress the variable length input stream to the size of the second-stage state vector. Each bit of input should have about equal influence on each of the output bits. Then there would be multi-round mixing of the second stage, which would be significantly more work than the first stage.In an email dated April 18, 2017, Natanael proposed that the best option for changing proof-of-work (PoW) is an algorithm that is moderately processing heavy and resists partial state reuse. The algorithm should have an existing reference implementation for hardware that is provably close in performance to the theoretical ideal implementation. For miners, cost primarily depends on correctly computed hashes per joule, which is related to the number of transistor activations per computed hash. An implementation must be near optimal with a minimum number of necessary transistor activations per computed hash. To prevent ASICBOOST-style optimization, the implementation should not allow much internal state reuse and the PoW step should always be the most expensive part of creating a complete block candidate. Any proof of an implementation being near optimal must consider the possibility of designs that deliberately allow errors to reduce the total count of transistor activations. The algorithm should be reasonably easy to verify, have adjustable difficulty, cryptographic strength, predictable and constant PoW computation performance, no significant reusable state, no meaningful precomputation possible, and rely only on transistors for implementation. The mining PoW should be highly parallelizable, with minimal or no gain from batch computation, and performance scaling should be linear with increased chip size and cycle speed. Overall, the algorithm should have a constant verification speed, be reasonably fast even on slow hardware, have no hidden shortcuts, and be reasonably compact in implementation with small inputs and outputs. 2017-04-19T17:43:03+00:00 + The author suggests using a repeated hashing method with blake2b to prevent lossy implementations and avoid relying on a single crypto primitive. Blake2b is conservative due to its large block size, which prevents asicboost-style attacks and eliminates the need for building logic for multiple blocks. Memory hard functions are effective but fail catastrophically when they do, limiting their use to hardware from a single vendor. The best PoW function for commodity mining hardware is repeatedly hashing with blake2b ten or a hundred times. However, the author believes that hard forking the PoW function is not a good idea.Natanael discusses the idea of proving optimal implementation for hash functions in an email thread. While it is a good idea in theory, it seems impossible to prove currently. He also suggests avoiding internal state reuse through measures such as "whitening" and pre-hashing to prevent ASICBOOST type optimizations. A slower hash function or iterating the hash function multiple times could be used practically. PoW verification will still be fast enough, and memory-hard functions are currently the best option for PoW functions.The cost of producing a chip depends on the number of metal layers required for routing interconnects in a particular area. Fewer layers mean quicker and easier manufacturing, and fewer patentable costs. A paper discussing factors impacting chip design costs has been linked, although its validity cannot be vouched for. To minimize asicboost-like optimizations, there needs to be early nonce mixing with variable-length input that has near-constant work. The entirety of the input should be mixed with the nonce data as soon as possible to prevent unexpected optimizations. A hash algorithm with more linear computation time versus input size would be ideal. It would consist of a first-stage Merkle tree hash to pre-lossy-mix-compress the variable length input stream to the size of the second-stage state vector. Each bit of input should have about equal influence on each of the output bits. Then there would be multi-round mixing of the second stage, which would be significantly more work than the first stage.In an email dated April 18, 2017, Natanael proposed that the best option for changing proof-of-work (PoW) is an algorithm that is moderately processing heavy and resists partial state reuse. The algorithm should have an existing reference implementation for hardware that is provably close in performance to the theoretical ideal implementation. For miners, cost primarily depends on correctly computed hashes per joule, which is related to the number of transistor activations per computed hash. An implementation must be near optimal with a minimum number of necessary transistor activations per computed hash. To prevent ASICBOOST-style optimization, the implementation should not allow much internal state reuse and the PoW step should always be the most expensive part of creating a complete block candidate. Any proof of an implementation being near optimal must consider the possibility of designs that deliberately allow errors to reduce the total count of transistor activations. The algorithm should be reasonably easy to verify, have adjustable difficulty, cryptographic strength, predictable and constant PoW computation performance, no significant reusable state, no meaningful precomputation possible, and rely only on transistors for implementation. The mining PoW should be highly parallelizable, with minimal or no gain from batch computation, and performance scaling should be linear with increased chip size and cycle speed. Overall, the algorithm should have a constant verification speed, be reasonably fast even on slow hardware, have no hidden shortcuts, and be reasonably compact in implementation with small inputs and outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Proposal-Soft-Fork-Threshold-Signaling.xml b/static/bitcoin-dev/April_2017/combined_Proposal-Soft-Fork-Threshold-Signaling.xml index c9893122ac..3d5b934030 100644 --- a/static/bitcoin-dev/April_2017/combined_Proposal-Soft-Fork-Threshold-Signaling.xml +++ b/static/bitcoin-dev/April_2017/combined_Proposal-Soft-Fork-Threshold-Signaling.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Proposal: Soft Fork Threshold Signaling - 2023-08-01T20:23:20.704114+00:00 - - Thomas Voegtlin 2017-04-13 17:30:08+00:00 - - - Sancho Panza 2017-04-13 16:35:41+00:00 - - - Thomas Voegtlin 2017-04-13 14:55:29+00:00 - - - Sancho Panza 2017-04-13 14:17:59+00:00 - - - Thomas Voegtlin 2017-04-13 11:36:36+00:00 - + 2025-09-26T15:46:14.656955+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Soft Fork Threshold Signaling Thomas Voegtlin + 2017-04-13T11:36:00.000Z + + + Sancho Panza + 2017-04-13T14:17:00.000Z + + + Thomas Voegtlin + 2017-04-13T14:55:00.000Z + + + Sancho Panza + 2017-04-13T16:35:00.000Z + + + Thomas Voegtlin + 2017-04-13T17:30:00.000Z + + - python-feedgen + 2 Combined summary - Proposal: Soft Fork Threshold Signaling - 2023-08-01T20:23:20.705113+00:00 + 2025-09-26T15:46:14.657704+00:00 - There is a discussion about the use of coinbase and its potential clash with other proposals. Some suggest using a small set of standard thresholds to encode different values, while others prefer the coinbase idea. The writer proposes making the threshold configurable and not fixed in the soft-fork. They also suggest using a BIP9 conformant schedule to map threshold levels onto one byte. In an email exchange, Thomas suggests encoding the threshold in the version bits, while Sancho proposes extending BIP9 with a coinbase signaling feature. Sancho shares his proposal on GitHub for Thomas to review, but embedding data in coinbase poses a challenge due to limited space.The writer supports SegWit activation through BIP148 but believes that if a soft fork is initially activated by miners before the date set in BIP148, it would be less risky. User Activated Soft Fork (UASF) has risks like two competing branches and non-empty blocks being orphaned. The argument for UASF is that users give value to Bitcoin, so they should have the power to decide which branch has more value. However, this only works if the forking branch is usable. If adverse miners render it unusable, new coins may never reach markets. Lack of hashrate information prior to the soft fork increases risk. A soft fork initiated with more than 33% of the hashing power would likely be viable, as the remaining hashing power cannot successfully allocate to mine blocks on the non-forking branch and orphan blocks on the forking branch. Currently, about 30% of the hashing power signals support for SegWit using BIP9, close to the 33% threshold.The proposal suggests that miners signal the threshold at which they are willing to activate a soft fork. This information is published in the coinbase transaction of the block. Miners activate the soft fork if their threshold has been reached over the last retargeting period. This proposal reduces the risks associated with UASF by providing hashrate threshold information prior to the soft fork. However, it is susceptible to fake signaling and miners withholding hashing power before the fork. 2017-04-13T17:30:08+00:00 + There is a discussion about the use of coinbase and its potential clash with other proposals. Some suggest using a small set of standard thresholds to encode different values, while others prefer the coinbase idea. The writer proposes making the threshold configurable and not fixed in the soft-fork. They also suggest using a BIP9 conformant schedule to map threshold levels onto one byte. In an email exchange, Thomas suggests encoding the threshold in the version bits, while Sancho proposes extending BIP9 with a coinbase signaling feature. Sancho shares his proposal on GitHub for Thomas to review, but embedding data in coinbase poses a challenge due to limited space.The writer supports SegWit activation through BIP148 but believes that if a soft fork is initially activated by miners before the date set in BIP148, it would be less risky. User Activated Soft Fork (UASF) has risks like two competing branches and non-empty blocks being orphaned. The argument for UASF is that users give value to Bitcoin, so they should have the power to decide which branch has more value. However, this only works if the forking branch is usable. If adverse miners render it unusable, new coins may never reach markets. Lack of hashrate information prior to the soft fork increases risk. A soft fork initiated with more than 33% of the hashing power would likely be viable, as the remaining hashing power cannot successfully allocate to mine blocks on the non-forking branch and orphan blocks on the forking branch. Currently, about 30% of the hashing power signals support for SegWit using BIP9, close to the 33% threshold.The proposal suggests that miners signal the threshold at which they are willing to activate a soft fork. This information is published in the coinbase transaction of the block. Miners activate the soft fork if their threshold has been reached over the last retargeting period. This proposal reduces the risks associated with UASF by providing hashrate threshold information prior to the soft fork. However, it is susceptible to fake signaling and miners withholding hashing power before the fork. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Segwit-v2.xml b/static/bitcoin-dev/April_2017/combined_Segwit-v2.xml index 794692cd8e..cae6084288 100644 --- a/static/bitcoin-dev/April_2017/combined_Segwit-v2.xml +++ b/static/bitcoin-dev/April_2017/combined_Segwit-v2.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Segwit v2 - 2023-08-01T20:31:14.548610+00:00 - - praxeology_guy 2017-04-27 02:18:57+00:00 - - - Russell O'Connor 2017-04-26 21:34:29+00:00 - - - Johnson Lau 2017-04-26 20:09:34+00:00 - - - Luke Dashjr 2017-04-26 20:01:10+00:00 - - - Johnson Lau 2017-04-26 19:31:38+00:00 - - - praxeology_guy 2017-04-26 08:51:51+00:00 - - - Luke Dashjr 2017-04-20 20:28:52+00:00 - + 2025-09-26T15:45:51.514084+00:00 + python-feedgen + + + [bitcoin-dev] Segwit v2 Luke Dashjr + 2017-04-20T20:28:00.000Z + + + praxeology_guy + 2017-04-26T08:51:00.000Z + + + Johnson Lau + 2017-04-26T19:31:00.000Z + + + Luke Dashjr + 2017-04-26T20:01:00.000Z + + + Johnson Lau + 2017-04-26T20:09:00.000Z + + + Russell O'Connor + 2017-04-26T21:34:00.000Z + + + praxeology_guy + 2017-04-27T02:18:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Segwit v2 - 2023-08-01T20:31:14.548610+00:00 + 2025-09-26T15:45:51.515169+00:00 - In a recent discussion on the Bitcoin-dev mailing list, Luke Dashjr proposed some minor tweaks to BIP 141's version bit assignment for SegWit v2. The first suggested change is to replace the dummy marker with 0xFF instead of 0. This change aims to avoid ambiguity with incomplete zero-input transactions that has been a source of confusion for raw transaction APIs. The second proposed change involves relaxing the consensus rules on when witness data is allowed for an input.Currently, witness data is only allowed when the scriptSig is null and the scriptPubKey being spent matches a specific pattern. Luke suggests allowing witness data in combination with scriptSig and with any scriptPubKey, considering these cases to be "upgrade-safe" policy ignoring. This change would make the system more flexible to future softforks.Johnson Lau also proposed a change in commitment structure that is backwards compatible. He suggested merging two arrays to create a simpler format, but noted that it would be harder to compress. The new format includes OP_RETURN, Push the following 36 bytes, Commitment header, Commitment hash, Extension roots, and optional data. The extension roots consist of an array of extension identifier, extension root length, and extension root.Luke Dashjr and Johnson Lau had an email exchange discussing the use of a dummy marker and scriptSig in Bitcoin. Johnson Lau expressed his preference to keep the dummy marker and not change the commitment structure as suggested by another post. Luke Dashjr argued that the dummy marker could be non-consensus critical as long as hashing replaces it with a 0. They also debated the use of scriptSig and witness, with Luke suggesting that scriptSig should not be obsoleted just yet since there are things it can do that witness cannot currently.In a separate discussion, Praxeology Guy proposed a more future-proof Commitment Extension Methodology that uses fewer bytes and eliminates arbitrary storage locations for the "witness reserved value." This methodology includes a variable length array of extension identifiers and roots. Additionally, he suggests implementing the Policy ID 'replay attack" prevention that increases each wtx length by 1 byte and can be reduced in a block by clustering Policy ID ranges in the coinbase or guessing the Policy ID. Finally, witness data would sign on the Policy ID, preventing replay if at least one branch adopted a new Policy ID.Overall, these proposed changes aim to improve the functionality and flexibility of the Bitcoin system, particularly in relation to scriptSig, witness data, and commitment structure. The suggestions have been shared with the Bitcoin-dev mailing list for further discussion and feedback from participants. 2017-04-27T02:18:57+00:00 + In a recent discussion on the Bitcoin-dev mailing list, Luke Dashjr proposed some minor tweaks to BIP 141's version bit assignment for SegWit v2. The first suggested change is to replace the dummy marker with 0xFF instead of 0. This change aims to avoid ambiguity with incomplete zero-input transactions that has been a source of confusion for raw transaction APIs. The second proposed change involves relaxing the consensus rules on when witness data is allowed for an input.Currently, witness data is only allowed when the scriptSig is null and the scriptPubKey being spent matches a specific pattern. Luke suggests allowing witness data in combination with scriptSig and with any scriptPubKey, considering these cases to be "upgrade-safe" policy ignoring. This change would make the system more flexible to future softforks.Johnson Lau also proposed a change in commitment structure that is backwards compatible. He suggested merging two arrays to create a simpler format, but noted that it would be harder to compress. The new format includes OP_RETURN, Push the following 36 bytes, Commitment header, Commitment hash, Extension roots, and optional data. The extension roots consist of an array of extension identifier, extension root length, and extension root.Luke Dashjr and Johnson Lau had an email exchange discussing the use of a dummy marker and scriptSig in Bitcoin. Johnson Lau expressed his preference to keep the dummy marker and not change the commitment structure as suggested by another post. Luke Dashjr argued that the dummy marker could be non-consensus critical as long as hashing replaces it with a 0. They also debated the use of scriptSig and witness, with Luke suggesting that scriptSig should not be obsoleted just yet since there are things it can do that witness cannot currently.In a separate discussion, Praxeology Guy proposed a more future-proof Commitment Extension Methodology that uses fewer bytes and eliminates arbitrary storage locations for the "witness reserved value." This methodology includes a variable length array of extension identifiers and roots. Additionally, he suggests implementing the Policy ID 'replay attack" prevention that increases each wtx length by 1 byte and can be reduced in a block by clustering Policy ID ranges in the coinbase or guessing the Policy ID. Finally, witness data would sign on the Policy ID, preventing replay if at least one branch adopted a new Policy ID.Overall, these proposed changes aim to improve the functionality and flexibility of the Bitcoin system, particularly in relation to scriptSig, witness data, and commitment structure. The suggestions have been shared with the Bitcoin-dev mailing list for further discussion and feedback from participants. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml b/static/bitcoin-dev/April_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml index 714ac16a19..04dd1346fb 100644 --- a/static/bitcoin-dev/April_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml +++ b/static/bitcoin-dev/April_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml @@ -1,92 +1,131 @@ - + 2 Combined summary - Segwit2Mb - combined soft/hard fork - Request For Comments - 2023-08-01T20:08:23.855216+00:00 - - Oliver Petruzel 2017-06-03 21:05:23+00:00 - - - Oliver Petruzel 2017-06-03 02:03:47+00:00 - - - Erik Aronesty 2017-06-03 00:53:55+00:00 - - - Sergio Demian Lerner 2017-06-02 21:51:45+00:00 - - - Erik Aronesty 2017-06-02 20:04:25+00:00 - - - Erik Aronesty 2017-06-02 20:04:16+00:00 - - - R E Broadley 2017-06-02 12:29:19+00:00 - - - Aymeric Vitte 2017-04-06 22:29:51+00:00 - - - Sergio Demian Lerner 2017-04-06 21:03:12+00:00 - - - Sergio Demian Lerner 2017-04-06 20:58:56+00:00 - - - Sergio Demian Lerner 2017-04-06 20:42:19+00:00 - - - Erik Aronesty 2017-04-06 02:27:34+00:00 - - - Btc Drak 2017-04-03 14:40:04+00:00 - - - Jorge Timón 2017-04-02 11:43:54+00:00 - - - Natanael 2017-04-02 10:03:31+00:00 - - - Jorge Timón 2017-04-02 04:57:48+00:00 - - - Natanael 2017-04-01 15:34:24+00:00 - - - Jorge Timón 2017-04-01 14:07:32+00:00 - - - Natanael 2017-04-01 13:15:15+00:00 - - - Jorge Timón 2017-04-01 12:33:18+00:00 - - - Sergio Demian Lerner 2017-04-01 11:44:11+00:00 - - - Jared Lee Richardson 2017-04-01 06:55:42+00:00 - - - Sergio Demian Lerner 2017-04-01 03:35:11+00:00 - - - Samson Mow 2017-04-01 03:03:03+00:00 - - - Sergio Demian Lerner 2017-03-31 22:13:35+00:00 - - - Sergio Demian Lerner 2017-03-31 21:50:05+00:00 - - - praxeology_guy 2017-03-31 21:22:02+00:00 - - - Sergio Demian Lerner 2017-03-31 21:09:18+00:00 - + 2025-09-26T15:45:45.184382+00:00 + python-feedgen + + + [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments Sergio Demian Lerner + 2017-03-31T21:09:00.000Z + + + Matt Corallo + 2017-03-31T21:18:00.000Z + + + praxeology_guy + 2017-03-31T21:22:00.000Z + + + Matt Corallo + 2017-03-31T21:22:00.000Z + + + Sergio Demian Lerner + 2017-03-31T21:50:00.000Z + + + Sergio Demian Lerner + 2017-03-31T22:13:00.000Z + + + Samson Mow + 2017-04-01T03:03:00.000Z + + + Sergio Demian Lerner + 2017-04-01T03:35:00.000Z + + + Jared Lee Richardson + 2017-04-01T06:55:00.000Z + + + Sergio Demian Lerner + 2017-04-01T11:44:00.000Z + + + Jorge Timón + 2017-04-01T12:33:00.000Z + + + Natanael + 2017-04-01T13:15:00.000Z + + + Jorge Timón + 2017-04-01T14:07:00.000Z + + + Natanael + 2017-04-01T15:34:00.000Z + + + Jorge Timón + 2017-04-02T04:57:00.000Z + + + Natanael + 2017-04-02T10:03:00.000Z + + + Jorge Timón + 2017-04-02T11:43:00.000Z + + + Btc Drak + 2017-04-03T14:40:00.000Z + + + Erik Aronesty + 2017-04-06T02:27:00.000Z + + + Sergio Demian Lerner + 2017-04-06T20:42:00.000Z + + + Sergio Demian Lerner + 2017-04-06T20:58:00.000Z + + + Sergio Demian Lerner + 2017-04-06T21:03:00.000Z + + + Aymeric Vitte + 2017-04-06T22:29:00.000Z + + + R E Broadley + 2017-06-02T12:29:00.000Z + + + Erik Aronesty + 2017-06-02T20:04:00.000Z + + + Erik Aronesty + 2017-06-02T20:04:00.000Z + + + Sergio Demian Lerner + 2017-06-02T21:51:00.000Z + + + Erik Aronesty + 2017-06-03T00:53:00.000Z + + + Oliver Petruzel + 2017-06-03T02:03:00.000Z + + + Oliver Petruzel + 2017-06-03T21:05:00.000Z + + @@ -115,13 +154,13 @@ - python-feedgen + 2 Combined summary - Segwit2Mb - combined soft/hard fork - Request For Comments - 2023-08-01T20:08:23.855216+00:00 + 2025-09-26T15:45:45.187417+00:00 - Sergio Demian Lerner has proposed two solutions to address the ongoing conflict within the Bitcoin community regarding the activation of segwit and the block size increase. The first proposal, called Segwit2Mb, combines SegWit with a 2MB block size hard-fork that would be activated only if SegWit activates with 95% miner signaling. The objective is to reunite the Bitcoin community and prevent a cryptocurrency split. The second proposal, known as the COOP proposal, suggests gradually increasing the block size limit over a four-year period to 4MB, aiming to prevent sudden spikes in transaction fees and ensure efficient handling of increased network traffic.Both proposals aim to address scalability and efficiency issues in the Bitcoin network. The implementation of segwit has already increased transaction capacity, and further improvements have been made to boost the network's processing speed. However, the current 1MB block size limit has been criticized for limiting the network's capacity during periods of high demand.There are concerns about potential centralization and security risks associated with larger blocks, particularly with the COOP proposal. The COOP proposal has received mixed reactions from the Bitcoin community, while the Segwit2Mb proposal aims to find a middle ground solution.Sergio Demian Lerner emphasizes the importance of 95% miner signaling to prevent a potential Bitcoin fork. He explains that a fork with only 95% miner support would result in reduced transaction capacity and slower confirmation times, leading to higher fees and a growing mempool. He also highlights the need for consensus among nodes and miners to avoid a split similar to what happened with Ethereum HF and Ethereum Classic.The proposed implementation of SegWit, according to the conversation between Natanael and Jorge Timón, would replace the current 1MB block-size limit with a weight limit of 4MB. This implementation is considered a backward compatible soft fork.The Segwit2Mb proposal has received criticism from developers who argue that it ignores previous research and understanding of hardforks. However, Sergio Demian Lerner welcomes community feedback and contributions to improve the proposal.In response to suggestions for improvement, Sergio Demian Lerner considers delaying the hard-fork date and emphasizes the need for further comments from the community. He also suggests considering the impact of technological innovations like Lightning, TumbleBit, and RootStock. However, there are concerns about the potential risks and confusion that could arise from a sudden change in block size increase.The proposed solution, Segwit2Mb, requires all Bitcoin nodes to be updated to prevent them from being forked away in a chain with almost no hashing power before the hard-fork occurs. The proposal aims to see the Lightning Network in action, utilize the non-malleability features in segwit, and discuss other soft-forks in the scaling roadmap.Overall, Sergio Demian Lerner's proposal seeks to find a compromise solution to address the issue of halting innovation for years. While controversial, the proposal encourages community participation and feedback to unlock the current deadlock within the Bitcoin community. 2017-06-03T21:05:23+00:00 + Sergio Demian Lerner has proposed two solutions to address the ongoing conflict within the Bitcoin community regarding the activation of segwit and the block size increase. The first proposal, called Segwit2Mb, combines SegWit with a 2MB block size hard-fork that would be activated only if SegWit activates with 95% miner signaling. The objective is to reunite the Bitcoin community and prevent a cryptocurrency split. The second proposal, known as the COOP proposal, suggests gradually increasing the block size limit over a four-year period to 4MB, aiming to prevent sudden spikes in transaction fees and ensure efficient handling of increased network traffic.Both proposals aim to address scalability and efficiency issues in the Bitcoin network. The implementation of segwit has already increased transaction capacity, and further improvements have been made to boost the network's processing speed. However, the current 1MB block size limit has been criticized for limiting the network's capacity during periods of high demand.There are concerns about potential centralization and security risks associated with larger blocks, particularly with the COOP proposal. The COOP proposal has received mixed reactions from the Bitcoin community, while the Segwit2Mb proposal aims to find a middle ground solution.Sergio Demian Lerner emphasizes the importance of 95% miner signaling to prevent a potential Bitcoin fork. He explains that a fork with only 95% miner support would result in reduced transaction capacity and slower confirmation times, leading to higher fees and a growing mempool. He also highlights the need for consensus among nodes and miners to avoid a split similar to what happened with Ethereum HF and Ethereum Classic.The proposed implementation of SegWit, according to the conversation between Natanael and Jorge Timón, would replace the current 1MB block-size limit with a weight limit of 4MB. This implementation is considered a backward compatible soft fork.The Segwit2Mb proposal has received criticism from developers who argue that it ignores previous research and understanding of hardforks. However, Sergio Demian Lerner welcomes community feedback and contributions to improve the proposal.In response to suggestions for improvement, Sergio Demian Lerner considers delaying the hard-fork date and emphasizes the need for further comments from the community. He also suggests considering the impact of technological innovations like Lightning, TumbleBit, and RootStock. However, there are concerns about the potential risks and confusion that could arise from a sudden change in block size increase.The proposed solution, Segwit2Mb, requires all Bitcoin nodes to be updated to prevent them from being forked away in a chain with almost no hashing power before the hard-fork occurs. The proposal aims to see the Lightning Network in action, utilize the non-malleability features in segwit, and discuss other soft-forks in the scaling roadmap.Overall, Sergio Demian Lerner's proposal seeks to find a compromise solution to address the issue of halting innovation for years. While controversial, the proposal encourages community participation and feedback to unlock the current deadlock within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Small-Nodes-A-Better-Alternative-to-Pruned-Nodes.xml b/static/bitcoin-dev/April_2017/combined_Small-Nodes-A-Better-Alternative-to-Pruned-Nodes.xml index 46bcf17f2a..c956753ea8 100644 --- a/static/bitcoin-dev/April_2017/combined_Small-Nodes-A-Better-Alternative-to-Pruned-Nodes.xml +++ b/static/bitcoin-dev/April_2017/combined_Small-Nodes-A-Better-Alternative-to-Pruned-Nodes.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Small Nodes: A Better Alternative to Pruned Nodes - 2023-08-01T20:28:26.315407+00:00 - - Aymeric Vitte 2017-05-03 22:45:40+00:00 - - - Natanael 2017-05-03 19:10:47+00:00 - - - Erik Aronesty 2017-05-03 14:03:58+00:00 - - - Aymeric Vitte 2017-04-23 16:27:15+00:00 - - - Gregory Maxwell 2017-04-21 20:38:36+00:00 - - - Leandro Coutinho 2017-04-21 15:58:43+00:00 - - - David Kaufman 2017-04-21 13:35:51+00:00 - - - Tom Zander 2017-04-21 08:27:36+00:00 - - - Aymeric Vitte 2017-04-20 23:42:03+00:00 - - - Andrew Poelstra 2017-04-20 20:32:12+00:00 - - - Erik Aronesty 2017-04-20 15:50:24+00:00 - - - Aymeric Vitte 2017-04-20 11:27:32+00:00 - - - Tom Zander 2017-04-20 09:46:33+00:00 - - - David Vorick 2017-04-19 17:30:30+00:00 - - - Angel Leon 2017-04-19 13:47:40+00:00 - - - udevNull 2017-04-19 04:28:48+00:00 - - - Aymeric Vitte 2017-04-18 23:19:04+00:00 - - - Tier Nolan 2017-04-18 13:07:09+00:00 - - - Tom Zander 2017-04-18 10:50:31+00:00 - - - Jonas Schnelli 2017-04-18 07:43:52+00:00 - - - Aymeric Vitte 2017-04-17 10:14:25+00:00 - - - David Vorick 2017-04-17 07:27:35+00:00 - - - Danny Thorpe 2017-04-17 07:11:07+00:00 - - - David Vorick 2017-04-17 06:54:49+00:00 - + 2025-09-26T15:45:53.639822+00:00 + python-feedgen + + + [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes David Vorick + 2017-04-17T06:54:00.000Z + + + Danny Thorpe + 2017-04-17T07:11:00.000Z + + + David Vorick + 2017-04-17T07:27:00.000Z + + + Aymeric Vitte + 2017-04-17T10:14:00.000Z + + + Jonas Schnelli + 2017-04-18T07:43:00.000Z + + + Tom Zander + 2017-04-18T10:50:00.000Z + + + Tier Nolan + 2017-04-18T13:07:00.000Z + + + Aymeric Vitte + 2017-04-18T23:19:00.000Z + + + udevNull + 2017-04-19T04:28:00.000Z + + + Angel Leon + 2017-04-19T13:47:00.000Z + + + David Vorick + 2017-04-19T17:30:00.000Z + + + Tom Zander + 2017-04-20T09:46:00.000Z + + + Aymeric Vitte + 2017-04-20T11:27:00.000Z + + + Erik Aronesty + 2017-04-20T15:50:00.000Z + + + Andrew Poelstra + 2017-04-20T20:32:00.000Z + + + Aymeric Vitte + 2017-04-20T23:42:00.000Z + + + Tom Zander + 2017-04-21T08:27:00.000Z + + + David Kaufman + 2017-04-21T13:35:00.000Z + + + Leandro Coutinho + 2017-04-21T15:58:00.000Z + + + Gregory Maxwell + 2017-04-21T20:38:00.000Z + + + Aymeric Vitte + 2017-04-23T16:27:00.000Z + + + Erik Aronesty + 2017-05-03T14:03:00.000Z + + + Natanael + 2017-05-03T19:10:00.000Z + + + Aymeric Vitte + 2017-05-03T22:45:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Small Nodes: A Better Alternative to Pruned Nodes - 2023-08-01T20:28:26.316422+00:00 + 2025-09-26T15:45:53.642455+00:00 - The discussions on the bitcoin-dev mailing list revolve around finding solutions to reduce failure probabilities, increase the number of full nodes, and decrease the storage requirement for running a full Bitcoin node. Various proposals are suggested, including storing random percentages of less commonly available blocks, using Forward Error Correction (FEC) codes like Reed-Solomon codes, allowing pruning of old transactions, and implementing small nodes with Reed-Solomon coding. These proposals aim to improve network health, scalability, and accessibility while addressing security and reliability concerns.One proposal suggests adding a third mode for nodes, allowing them to signal that they keep the last 1000 blocks. This would be beneficial for pruned nodes, as they could partially serve historical blocks instead of serving all or none. Another proposal suggests a "random pruning mode" for nodes, which stores a random set of blocks and drops random blocks as disk space runs out. However, this proposal has disadvantages due to the potential inability to download certain blocks, particularly with active adversaries.The aim is to decrease the resource requirements for running a full node, which is crucial for decentralization, security, and protection against political interference. A suggestion is to compactly indicate which blocks a node has, allowing each node to store a subset of blocks. However, missing even a single block could pose a significant problem. Financially incentivizing nodes is a complex issue, as it may lead to malicious actors automating deployment. However, offering rewards for long-term commitment could be a potential solution.There are concerns about the default setting of pruned nodes in bitcoin-core, with claims that it could become problematic. The priority should be to increase the number of full nodes with incentives for people to run them. In a previous discussion, there was a suggestion to compactly indicate which blocks a node has, and it was recommended that each node store the last few days' worth of blocks.David Vorick proposes a solution called "small nodes" to increase the number of users running full nodes. Small nodes would only need to store about 20% of the blockchain using Reed-Solomon coding. Each small node has a permanent index and stores a piece that corresponds to its index. The full block can be recovered by connecting to six random small node peers. Vorick believes this solution would greatly benefit decentralization without putting pressure on archival nodes.Disk space consumption is identified as a significant factor preventing more people from running full nodes. Pruned nodes are currently the best alternative, but this puts pressure on archival nodes. The proposed solution is a new node type called a "small node" that stores only 20% of the blockchain. Small nodes use erasure coding to store fragments of blocks and can recover the entire blockchain by connecting to six random small node peers. There are challenges in preventing denial-of-service attacks and ensuring the correctness of the stored pieces. Implementing small nodes would require a non-trivial amount of code but could significantly increase the percentage of users running full nodes and create a healthier network. 2017-05-03T22:45:40+00:00 + The discussions on the bitcoin-dev mailing list revolve around finding solutions to reduce failure probabilities, increase the number of full nodes, and decrease the storage requirement for running a full Bitcoin node. Various proposals are suggested, including storing random percentages of less commonly available blocks, using Forward Error Correction (FEC) codes like Reed-Solomon codes, allowing pruning of old transactions, and implementing small nodes with Reed-Solomon coding. These proposals aim to improve network health, scalability, and accessibility while addressing security and reliability concerns.One proposal suggests adding a third mode for nodes, allowing them to signal that they keep the last 1000 blocks. This would be beneficial for pruned nodes, as they could partially serve historical blocks instead of serving all or none. Another proposal suggests a "random pruning mode" for nodes, which stores a random set of blocks and drops random blocks as disk space runs out. However, this proposal has disadvantages due to the potential inability to download certain blocks, particularly with active adversaries.The aim is to decrease the resource requirements for running a full node, which is crucial for decentralization, security, and protection against political interference. A suggestion is to compactly indicate which blocks a node has, allowing each node to store a subset of blocks. However, missing even a single block could pose a significant problem. Financially incentivizing nodes is a complex issue, as it may lead to malicious actors automating deployment. However, offering rewards for long-term commitment could be a potential solution.There are concerns about the default setting of pruned nodes in bitcoin-core, with claims that it could become problematic. The priority should be to increase the number of full nodes with incentives for people to run them. In a previous discussion, there was a suggestion to compactly indicate which blocks a node has, and it was recommended that each node store the last few days' worth of blocks.David Vorick proposes a solution called "small nodes" to increase the number of users running full nodes. Small nodes would only need to store about 20% of the blockchain using Reed-Solomon coding. Each small node has a permanent index and stores a piece that corresponds to its index. The full block can be recovered by connecting to six random small node peers. Vorick believes this solution would greatly benefit decentralization without putting pressure on archival nodes.Disk space consumption is identified as a significant factor preventing more people from running full nodes. Pruned nodes are currently the best alternative, but this puts pressure on archival nodes. The proposed solution is a new node type called a "small node" that stores only 20% of the blockchain. Small nodes use erasure coding to store fragments of blocks and can recover the entire blockchain by connecting to six random small node peers. There are challenges in preventing denial-of-service attacks and ensuring the correctness of the stored pieces. Implementing small nodes would require a non-trivial amount of code but could significantly increase the percentage of users running full nodes and create a healthier network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Transaction-signalling.xml b/static/bitcoin-dev/April_2017/combined_Transaction-signalling.xml index b185eb5093..90dcf6b4e7 100644 --- a/static/bitcoin-dev/April_2017/combined_Transaction-signalling.xml +++ b/static/bitcoin-dev/April_2017/combined_Transaction-signalling.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Transaction signalling - 2023-08-01T20:30:08.114536+00:00 - - Erik Aronesty 2017-05-03 19:41:07+00:00 - - - Erik Aronesty 2017-04-20 16:14:18+00:00 - - - Tim Ruffing 2017-04-18 22:29:17+00:00 - - - Christian Decker 2017-04-18 18:07:25+00:00 - - - Erik Aronesty 2017-04-18 18:01:52+00:00 - - - Marcel Jamin 2017-04-18 14:52:04+00:00 - - - Erik Aronesty 2017-04-17 15:50:51+00:00 - + 2025-09-26T15:46:16.750057+00:00 + python-feedgen + + + [bitcoin-dev] Transaction signalling Erik Aronesty + 2017-04-17T15:50:00.000Z + + + Marcel Jamin + 2017-04-18T14:52:00.000Z + + + Erik Aronesty + 2017-04-18T18:01:00.000Z + + + Christian Decker + 2017-04-18T18:07:00.000Z + + + Tim Ruffing + 2017-04-18T22:29:00.000Z + + + Erik Aronesty + 2017-04-20T16:14:00.000Z + + + Erik Aronesty + 2017-05-03T19:41:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Transaction signalling - 2023-08-01T20:30:08.114536+00:00 + 2025-09-26T15:46:16.751060+00:00 - BIP XXXX proposes a change to the usage of the 'OP_RETURN' script opcode in Bitcoin transactions, allowing multiple changes (features) to be deployed in parallel. The proposal relies on interpreting the output field as a bit vector, where each bit can be used to track an independent change. BIP9 introduced a mechanism for doing soft-forking changes relying on measuring miner support indicated by version bits in block headers.However, any change which may conflict with miners but is acceptable to users may be difficult to deploy. BIP XXXX can be used in conjunction with BIP 9 to more safely deploy soft-forking changes that do not require a supermajority of miners but do require a large percentage of active users. Alternatively, BIP XXXX signalling can be used to gauge user support for "features" - independent of its use as a direct deployment mechanism. Each "feature" is specified by the same set of per-chain parameters as in BIP9, with the same usage and meaning (name, bit, starttime and timeout).If the outputs contain a zero valued OP_RETURN, and the length of the key is 2 bytes, and if the first byte (prefix) of that OP_RETURN's key parameter is 0x012, then the remaining byte is to be interpreted as an 8-bit little-endian integer, and bits are selected within this integer as values. The alternative to flag-day deployment can cause issues for users of a feature that has failed to achieve adequate miner support. BIP XXXX proposes a solution to this problem.In a bitcoin-dev thread, Christian Decker proposed the extension of signaling capabilities to end-users, which would give stakeholders a voice in network decisions. He suggested using output scripts as the best field for signaling since they are specified by the recipient of funds and are already stored in the UTXO. The last 4 bits of the pubkey/pubkeyhash could be used to opt-in, with the vote (0/1) depending on the stakeholders' desired signal.However, unlike the OP_RETURN proposal, users who do not intend to signal will also be included in the tally. To ensure voluntary votes, the opt-in should be adjusted accordingly, but too many opt-in bits may exacerbate existing problems with HD Wallet lookahead. Tim Ruffing added that using addresses creates vulnerabilities, so an OP_RETURN signal seems the safest way to go for UA signaling. He suggested modeling a BIP after BIP9, with some discussion of how to properly collect statistics and the ability for nodes to activate features based on an "economic majority" defined in this way.One member of the bitcoin-dev mailing list, Tim, doesn't have a general opinion on signaling, but does express concern about using addresses for signaling, citing privacy implications. Christian Decker responds to Tim's concerns, suggesting that extending signaling capabilities to end-users would give stakeholders a voice in network decisions and provide data for informed decisions. Decker suggests several fields that could be used for signaling, including OP_RETURN, locktime, and output scripts, but ultimately decides that output scripts are likely the best option due to their easy tallying and the fact that they are already stored in the UTXO.The writer is in favor of extending signaling capabilities to the end-users. While exploring various signaling ideas, the writer suggests that fields such as OP_RETURN and locktime may not be suitable for this purpose due to issues related to data transfer, storage, and tagging. The output script field is suggested as the best option for signaling as it is specified by the recipient of funds and is already stored in UTXO. The writer also suggests using the last 4 bits of the pubkey/pubkeyhash to opt-in and vote.A proposal has been made to tag fee-paying transactions with information about the capabilities of the node that created it. The tagging would occur on the addresses, and the weighting would be by value, so it's a measure of economic significance. This could be useful in gauging economic support for certain upgrades, especially if excluding long transaction chains.A suggestion was made on the Bitcoin-dev mailing list about adding a signal to OP_RETURN that would allow users to tag validated input addresses. With this information, nodes could activate new features after a certain percentage of tagged input addresses is reached within a specific time period. This tagging may provide a better indication of economic support for certain upgrades than simply counting reachable nodes.The proposal suggests using a signal added to OP_RETURN to tag all validated input addresses. This would allow a node to activate a new feature after a certain percentage of tagged input addresses are reached within a specified time period. The idea is to use this in addition to a flag day to trigger feature activation with some reassurance of user uptake. 2017-05-03T19:41:07+00:00 + BIP XXXX proposes a change to the usage of the 'OP_RETURN' script opcode in Bitcoin transactions, allowing multiple changes (features) to be deployed in parallel. The proposal relies on interpreting the output field as a bit vector, where each bit can be used to track an independent change. BIP9 introduced a mechanism for doing soft-forking changes relying on measuring miner support indicated by version bits in block headers.However, any change which may conflict with miners but is acceptable to users may be difficult to deploy. BIP XXXX can be used in conjunction with BIP 9 to more safely deploy soft-forking changes that do not require a supermajority of miners but do require a large percentage of active users. Alternatively, BIP XXXX signalling can be used to gauge user support for "features" - independent of its use as a direct deployment mechanism. Each "feature" is specified by the same set of per-chain parameters as in BIP9, with the same usage and meaning (name, bit, starttime and timeout).If the outputs contain a zero valued OP_RETURN, and the length of the key is 2 bytes, and if the first byte (prefix) of that OP_RETURN's key parameter is 0x012, then the remaining byte is to be interpreted as an 8-bit little-endian integer, and bits are selected within this integer as values. The alternative to flag-day deployment can cause issues for users of a feature that has failed to achieve adequate miner support. BIP XXXX proposes a solution to this problem.In a bitcoin-dev thread, Christian Decker proposed the extension of signaling capabilities to end-users, which would give stakeholders a voice in network decisions. He suggested using output scripts as the best field for signaling since they are specified by the recipient of funds and are already stored in the UTXO. The last 4 bits of the pubkey/pubkeyhash could be used to opt-in, with the vote (0/1) depending on the stakeholders' desired signal.However, unlike the OP_RETURN proposal, users who do not intend to signal will also be included in the tally. To ensure voluntary votes, the opt-in should be adjusted accordingly, but too many opt-in bits may exacerbate existing problems with HD Wallet lookahead. Tim Ruffing added that using addresses creates vulnerabilities, so an OP_RETURN signal seems the safest way to go for UA signaling. He suggested modeling a BIP after BIP9, with some discussion of how to properly collect statistics and the ability for nodes to activate features based on an "economic majority" defined in this way.One member of the bitcoin-dev mailing list, Tim, doesn't have a general opinion on signaling, but does express concern about using addresses for signaling, citing privacy implications. Christian Decker responds to Tim's concerns, suggesting that extending signaling capabilities to end-users would give stakeholders a voice in network decisions and provide data for informed decisions. Decker suggests several fields that could be used for signaling, including OP_RETURN, locktime, and output scripts, but ultimately decides that output scripts are likely the best option due to their easy tallying and the fact that they are already stored in the UTXO.The writer is in favor of extending signaling capabilities to the end-users. While exploring various signaling ideas, the writer suggests that fields such as OP_RETURN and locktime may not be suitable for this purpose due to issues related to data transfer, storage, and tagging. The output script field is suggested as the best option for signaling as it is specified by the recipient of funds and is already stored in UTXO. The writer also suggests using the last 4 bits of the pubkey/pubkeyhash to opt-in and vote.A proposal has been made to tag fee-paying transactions with information about the capabilities of the node that created it. The tagging would occur on the addresses, and the weighting would be by value, so it's a measure of economic significance. This could be useful in gauging economic support for certain upgrades, especially if excluding long transaction chains.A suggestion was made on the Bitcoin-dev mailing list about adding a signal to OP_RETURN that would allow users to tag validated input addresses. With this information, nodes could activate new features after a certain percentage of tagged input addresses is reached within a specific time period. This tagging may provide a better indication of economic support for certain upgrades than simply counting reachable nodes.The proposal suggests using a signal added to OP_RETURN to tag all validated input addresses. This would allow a node to activate a new feature after a certain percentage of tagged input addresses are reached within a specified time period. The idea is to use this in addition to a flag day to trigger feature activation with some reassurance of user uptake. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Trustless-Segwit-activation-bounty-protocol-aka-bribing-the-miners-.xml b/static/bitcoin-dev/April_2017/combined_Trustless-Segwit-activation-bounty-protocol-aka-bribing-the-miners-.xml index 05ee7f3483..26da44c0c0 100644 --- a/static/bitcoin-dev/April_2017/combined_Trustless-Segwit-activation-bounty-protocol-aka-bribing-the-miners-.xml +++ b/static/bitcoin-dev/April_2017/combined_Trustless-Segwit-activation-bounty-protocol-aka-bribing-the-miners-.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Trustless Segwit activation bounty protocol (aka. bribing the miners) - 2023-08-01T20:31:59.647539+00:00 - - ZmnSCPxj 2017-04-27 21:05:47+00:00 - - - Johnson Lau 2017-04-27 20:10:03+00:00 - - - Antoine Le Calvez 2017-04-27 19:45:54+00:00 - - - Alex Mizrahi 2017-04-27 18:41:17+00:00 - - - Alex Mizrahi 2017-04-27 18:25:15+00:00 - - - Matt Bell 2017-04-27 17:48:16+00:00 - + 2025-09-26T15:46:20.986600+00:00 + python-feedgen + + + [bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners) Matt Bell + 2017-04-27T17:48:00.000Z + + + Alex Mizrahi + 2017-04-27T18:25:00.000Z + + + Alex Mizrahi + 2017-04-27T18:41:00.000Z + + + Antoine Le Calvez + 2017-04-27T19:45:00.000Z + + + Johnson Lau + 2017-04-27T20:10:00.000Z + + + ZmnSCPxj + 2017-04-27T21:05:00.000Z + + - python-feedgen + 2 Combined summary - Trustless Segwit activation bounty protocol (aka. bribing the miners) - 2023-08-01T20:31:59.647539+00:00 + 2025-09-26T15:46:20.987516+00:00 - In a recent discussion, the possibility of creating bounties for softforks and hardforks was explored. It was highlighted that in a decentralized system, it is not feasible to create a bounty for a softfork unless there is a softfork implemented first. However, creating a bounty for a hardfork is relatively simple by ensuring that the transaction violates existing rules.To address this limitation, an alternative approach was suggested. Economic agents who wish to push for a softfork can select specific block heights (H1 and H2), where H1 precedes the activation of the proposed softfork and H2 follows it. They can then offer a bounty to the first person who creates a transaction that is valid at H1 but invalid at H2.Another proposal discussed involved activating Segwit through bribing miners. A trustless contract protocol was suggested, wherein contributors would pledge to a Segwit bounty. If Segwit is activated, the funds would be paid out to the miners, otherwise they would be returned to the contributors. The protocol entails the creation of three private keys and corresponding pubkeys, as well as the generation of a Funding Transaction with two outputs. Additionally, a Segwit Assertion Transaction and a Bounty Payout Transaction would be created. Miners can verify the correctness and validity of these transactions once Funding Transactions are confirmed on the blockchain. If Segwit activates at height H-1, miners can claim the bounty payout by including the Segwit Assertion and Bounty Payout transactions in their block H. On the other hand, if Segwit does not activate at height H, Input 1 of the Bounty Payout becomes invalid, preventing inclusion of the Bounty Payout transaction in the block. In such cases, contributors can reclaim the funds from Output 0 of the Funding tx by creating a new transaction signed with k1. This proposal is considered advantageous for contributors, as the activation of Segwit is likely to increase the price of Bitcoin, resulting in a positive return if the price rises sufficiently.During the discussion, the concept of transactions without any outputs was raised. However, it was pointed out that according to the validation.cpp file in the Bitcoin GitHub repository, a transaction must have at least one output. Nonetheless, a similar effect can be achieved by adding an OP_RETURN output with 0 satoshis.In the context of Segwit activation, if Segwit has not been activated at height H, Input 1 of the Bounty Payout becomes invalid as it spends a P2WPKH output. This prevents miners from including the Bounty Payout transaction in their block. However, the output of the Segwit Assertion transaction can still be claimed, as it is treated as an "anyone-can-spend" output. Although the amount may be small, miners who are aware of the Bounty Payout Transaction will attempt to include both transactions, as they are valid on both Segwit and non-Segwit chains due to the nature of Segwit being a soft fork. By setting the timelock of the Bounty Payout Transaction to (H+1), the miner of Block H may not be the same as the miner of Block (H+1), reducing the guarantee of capturing the bounty. However, there is still a possibility that the same miner may mine both blocks, making it strategically sensible to include the transaction since the expected payoff is positive. Consequently, miners may still strive to claim these bounties regardless of Segwit activation.In summary, it is evident that the activation of Segwit at a specific height plays a crucial role in determining the validity of certain transactions. Various proposals, such as implementing bounties for softforks and hardforks or bribing miners to activate Segwit, have been discussed. These proposals aim to incentivize desirable outcomes within the Bitcoin ecosystem while considering the potential benefits and risks involved. 2017-04-27T21:05:47+00:00 + In a recent discussion, the possibility of creating bounties for softforks and hardforks was explored. It was highlighted that in a decentralized system, it is not feasible to create a bounty for a softfork unless there is a softfork implemented first. However, creating a bounty for a hardfork is relatively simple by ensuring that the transaction violates existing rules.To address this limitation, an alternative approach was suggested. Economic agents who wish to push for a softfork can select specific block heights (H1 and H2), where H1 precedes the activation of the proposed softfork and H2 follows it. They can then offer a bounty to the first person who creates a transaction that is valid at H1 but invalid at H2.Another proposal discussed involved activating Segwit through bribing miners. A trustless contract protocol was suggested, wherein contributors would pledge to a Segwit bounty. If Segwit is activated, the funds would be paid out to the miners, otherwise they would be returned to the contributors. The protocol entails the creation of three private keys and corresponding pubkeys, as well as the generation of a Funding Transaction with two outputs. Additionally, a Segwit Assertion Transaction and a Bounty Payout Transaction would be created. Miners can verify the correctness and validity of these transactions once Funding Transactions are confirmed on the blockchain. If Segwit activates at height H-1, miners can claim the bounty payout by including the Segwit Assertion and Bounty Payout transactions in their block H. On the other hand, if Segwit does not activate at height H, Input 1 of the Bounty Payout becomes invalid, preventing inclusion of the Bounty Payout transaction in the block. In such cases, contributors can reclaim the funds from Output 0 of the Funding tx by creating a new transaction signed with k1. This proposal is considered advantageous for contributors, as the activation of Segwit is likely to increase the price of Bitcoin, resulting in a positive return if the price rises sufficiently.During the discussion, the concept of transactions without any outputs was raised. However, it was pointed out that according to the validation.cpp file in the Bitcoin GitHub repository, a transaction must have at least one output. Nonetheless, a similar effect can be achieved by adding an OP_RETURN output with 0 satoshis.In the context of Segwit activation, if Segwit has not been activated at height H, Input 1 of the Bounty Payout becomes invalid as it spends a P2WPKH output. This prevents miners from including the Bounty Payout transaction in their block. However, the output of the Segwit Assertion transaction can still be claimed, as it is treated as an "anyone-can-spend" output. Although the amount may be small, miners who are aware of the Bounty Payout Transaction will attempt to include both transactions, as they are valid on both Segwit and non-Segwit chains due to the nature of Segwit being a soft fork. By setting the timelock of the Bounty Payout Transaction to (H+1), the miner of Block H may not be the same as the miner of Block (H+1), reducing the guarantee of capturing the bounty. However, there is still a possibility that the same miner may mine both blocks, making it strategically sensible to include the transaction since the expected payoff is positive. Consequently, miners may still strive to claim these bounties regardless of Segwit activation.In summary, it is evident that the activation of Segwit at a specific height plays a crucial role in determining the validity of certain transactions. Various proposals, such as implementing bounties for softforks and hardforks or bribing miners to activate Segwit, have been discussed. These proposals aim to incentivize desirable outcomes within the Bitcoin ecosystem while considering the potential benefits and risks involved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_Using-a-storage-engine-without-UTXO-index.xml b/static/bitcoin-dev/April_2017/combined_Using-a-storage-engine-without-UTXO-index.xml index f21152453b..24a9315b31 100644 --- a/static/bitcoin-dev/April_2017/combined_Using-a-storage-engine-without-UTXO-index.xml +++ b/static/bitcoin-dev/April_2017/combined_Using-a-storage-engine-without-UTXO-index.xml @@ -1,113 +1,151 @@ - + 2 Combined summary - Using a storage engine without UTXO-index - 2023-08-01T20:20:45.215731+00:00 - - Tomas 2017-04-11 10:04:01+00:00 - - - Eric Voskuil 2017-04-11 09:41:34+00:00 - - - Tomas 2017-04-11 08:43:30+00:00 - - - Eric Voskuil 2017-04-11 01:44:57+00:00 - - - Tomas 2017-04-08 23:58:02+00:00 - - - Eric Voskuil 2017-04-08 22:37:50+00:00 - - - Tomas 2017-04-08 22:34:11+00:00 - - - Gregory Maxwell 2017-04-08 22:12:09+00:00 - - - Troy Benjegerdes 2017-04-08 21:22:11+00:00 - - - Tomas 2017-04-08 20:42:57+00:00 - - - Johnson Lau 2017-04-08 20:21:04+00:00 - - - Tomas 2017-04-08 19:56:18+00:00 - - - Tomas 2017-04-08 19:23:40+00:00 - - - Johnson Lau 2017-04-08 19:23:29+00:00 - - - Tom Harding 2017-04-08 18:27:19+00:00 - - - Tomas 2017-04-08 07:28:48+00:00 - - - Gregory Maxwell 2017-04-08 00:44:50+00:00 - - - Eric Voskuil 2017-04-07 23:51:08+00:00 - - - Tomas 2017-04-07 21:44:43+00:00 - - - Tomas 2017-04-07 21:14:51+00:00 - - - Eric Voskuil 2017-04-07 19:55:58+00:00 - - - Gregory Maxwell 2017-04-07 19:42:22+00:00 - - - Tom Harding 2017-04-07 18:52:20+00:00 - - - Bram Cohen 2017-04-07 18:39:18+00:00 - - - Gregory Maxwell 2017-04-07 18:18:32+00:00 - - - Tomas 2017-04-07 16:02:35+00:00 - - - Greg Sanders 2017-04-07 14:14:31+00:00 - - - Tomas 2017-04-07 08:47:56+00:00 - - - Marcos mayorga 2017-04-07 07:55:48+00:00 - - - Tomas 2017-04-07 01:29:07+00:00 - - - Gregory Maxwell 2017-04-07 01:09:26+00:00 - - - Tomas 2017-04-07 00:48:52+00:00 - - - Tomas 2017-04-07 00:17:47+00:00 - - - Eric Voskuil 2017-04-06 23:38:23+00:00 - - - Tomas 2017-04-06 22:12:27+00:00 - + 2025-09-26T15:45:38.799494+00:00 + python-feedgen + + + [bitcoin-dev] Using a storage engine without UTXO-index Tomas + 2017-04-06T22:12:00.000Z + + + Eric Voskuil + 2017-04-06T23:38:00.000Z + + + Tomas + 2017-04-07T00:17:00.000Z + + + Tomas + 2017-04-07T00:48:00.000Z + + + Gregory Maxwell + 2017-04-07T01:09:00.000Z + + + Tomas + 2017-04-07T01:29:00.000Z + + + Marcos mayorga + 2017-04-07T07:55:00.000Z + + + Tomas + 2017-04-07T08:47:00.000Z + + + Greg Sanders + 2017-04-07T14:14:00.000Z + + + Tomas + 2017-04-07T16:02:00.000Z + + + Gregory Maxwell + 2017-04-07T18:18:00.000Z + + + Bram Cohen + 2017-04-07T18:39:00.000Z + + + Tom Harding + 2017-04-07T18:52:00.000Z + + + Gregory Maxwell + 2017-04-07T19:42:00.000Z + + + Eric Voskuil + 2017-04-07T19:55:00.000Z + + + Tomas + 2017-04-07T21:14:00.000Z + + + Tomas + 2017-04-07T21:44:00.000Z + + + Eric Voskuil + 2017-04-07T23:51:00.000Z + + + Gregory Maxwell + 2017-04-08T00:44:00.000Z + + + Tomas + 2017-04-08T07:28:00.000Z + + + Tom Harding + 2017-04-08T18:27:00.000Z + + + Tomas + 2017-04-08T19:23:00.000Z + + + Johnson Lau + 2017-04-08T19:23:00.000Z + + + Tomas + 2017-04-08T19:56:00.000Z + + + Johnson Lau + 2017-04-08T20:21:00.000Z + + + Tomas + 2017-04-08T20:42:00.000Z + + + Troy Benjegerdes + 2017-04-08T21:22:00.000Z + + + Gregory Maxwell + 2017-04-08T22:12:00.000Z + + + Tomas + 2017-04-08T22:34:00.000Z + + + Eric Voskuil + 2017-04-08T22:37:00.000Z + + + Tomas + 2017-04-08T23:58:00.000Z + + + Eric Voskuil + 2017-04-11T01:44:00.000Z + + + Tomas + 2017-04-11T08:43:00.000Z + + + Eric Voskuil + 2017-04-11T09:41:00.000Z + + + Tomas + 2017-04-11T10:04:00.000Z + + @@ -143,13 +181,13 @@ - python-feedgen + 2 Combined summary - Using a storage engine without UTXO-index - 2023-08-01T20:20:45.216731+00:00 + 2025-09-26T15:45:38.803070+00:00 - In a recent email discussion on the bitcoin-dev mailing list, Tom Harding suggested that maintaining a transaction index in a network with multiple nodes could enable light node applications to verify the existence and spentness of transaction outputs (TXOs). However, Gregory Maxwell pointed out that additional commitment structures, such as those proposed by Peter Todd in his stxo/txo commitment designs, would be necessary for this to work effectively. These commitment structures would improve light nodes by detecting invalid transactions before they are mined.Tomas, a developer, stressed the importance of protocol/implementation separation in response to a previous comment. He explained that while UTXO data is always a resource cost for script validation, the ratio of different costs can vary across implementations. In Bitcrust, if the last few blocks contain many inputs, the peak load verification for these blocks is slower compared to Core. Another user suggested limiting the number of 1-in-100-out transactions to prevent UTXO growth and improve efficiency. They also mentioned experimenting with regtest to compare the performance of Bitcrust with Core and asked about the minimum disk and memory usage in Bitcrust compared to Core's pruning mode.The conversation between Gregory Maxwell and Tom Harding focused on transaction indexes and light nodes. Harding suggested that maintaining a transaction index in a network of nodes would allow light node applications to request peers to prove the existence and usage of TXOs. Maxwell added that this would require additional commitment structures proposed by Peter Todd. The email exchange also included a link to Todd's proposal for delayed txo commitments.The discussion between Gregory Maxwell and Tomas revolved around the resource costs and latency-related costs in Bitcoin Core. Tomas noted that Bitcrust has slower peak load verification if the last few blocks contain many inputs, unlike Core. Tomas argued that the minimal disk storage required in Bitcoin cannot be less than all the unspent outputs. He mentioned that improvements like improving locality or keeping spentness in memory do not change the fact that UTXO data remains a significant long-term resource cost. However, during peak load block validation with pre-synced transactions, accessing storage can be minimized. The conversation also touched on the misaligned incentives and the impact of small outputs on long-term costs.The bitcoin-dev mailing list discussion debated whether application-layer caching is necessary or if allowing the operating system to use disk caching or memory map caching would be more effective. It was mentioned that an explicit cache is beneficial on lower memory systems but actually a de-optimization on high RAM systems. Eric Voskuil suggested that reducing the need for paging can be achieved through caching, while another participant argued that sorting data based on frequency of use would beat any application-layer cache. They suggested leaving caching decisions to the operating system based on spatial and temporal locality of reference.The discussion on optimization for lower memory platforms focused on reducing the need for paging through caching. Bram Cohen suggested maximizing memory usage and minimizing disk access, but others disagreed, stating that an application-layer cache only makes sense with a clear distinction between often-used and not often-used data. They emphasized the importance of proper spatial and temporal locality of reference and letting the operating system make caching decisions.The discussion on the long-term resource requirements of proposals with regards to unspent output data questioned whether cramming as much as possible into memory and minimizing disk access is the best approach. Bram Cohen asked if this optimization overlooks considerations such as startup time, warm-up time, shutdown time, fault tolerance, etc. The discussion highlighted the trade-offs and complexities involved in managing these considerations.Tomas introduced Bitcrust, a new Bitcoin implementation that uses a different approach to indexing for verifying the order of transactions. Instead of using an index of unspent outputs, double spends are verified using a spend-tree. Bitcrust has shown excellent performance characteristics, particularly in peak load order validation. The discussion also mentioned the possibility of integrating Bitcrust into Bitcoin Core as a selectable feature.Tomas proposed a solution to address the issue of UTXO growth in the Bitcoin protocol by reversing the costs of outputs and inputs. However, there are concerns about the long-term resource requirements and whether this protocol improvement is worth considering.Overall, the discussions on the bitcoin-dev mailing list covered various topics related to transaction indexes, resource costs, caching, and optimization for lower memory platforms. The conversations provided insights into different perspectives and considerations in Bitcoin development.In another conversation, Tomas explained how Bitcrust separates script validation from order validation and deals with changing validity rules based on block height. Script validation requires a (U)TXO database that consumes around 2GB of outputs. Order validation, on the other hand, requires a spent-index (~200MB) and a spent-tree (~500MB). Tomas mentioned that pruning the 5.7GB full spend tree is not worth it at the moment. When asked about how the spent index rejects a transaction that claims to spend an output that never existed, Tomas did not provide a direct answer.Tomas has 2017-04-11T10:04:01+00:00 + In a recent email discussion on the bitcoin-dev mailing list, Tom Harding suggested that maintaining a transaction index in a network with multiple nodes could enable light node applications to verify the existence and spentness of transaction outputs (TXOs). However, Gregory Maxwell pointed out that additional commitment structures, such as those proposed by Peter Todd in his stxo/txo commitment designs, would be necessary for this to work effectively. These commitment structures would improve light nodes by detecting invalid transactions before they are mined.Tomas, a developer, stressed the importance of protocol/implementation separation in response to a previous comment. He explained that while UTXO data is always a resource cost for script validation, the ratio of different costs can vary across implementations. In Bitcrust, if the last few blocks contain many inputs, the peak load verification for these blocks is slower compared to Core. Another user suggested limiting the number of 1-in-100-out transactions to prevent UTXO growth and improve efficiency. They also mentioned experimenting with regtest to compare the performance of Bitcrust with Core and asked about the minimum disk and memory usage in Bitcrust compared to Core's pruning mode.The conversation between Gregory Maxwell and Tom Harding focused on transaction indexes and light nodes. Harding suggested that maintaining a transaction index in a network of nodes would allow light node applications to request peers to prove the existence and usage of TXOs. Maxwell added that this would require additional commitment structures proposed by Peter Todd. The email exchange also included a link to Todd's proposal for delayed txo commitments.The discussion between Gregory Maxwell and Tomas revolved around the resource costs and latency-related costs in Bitcoin Core. Tomas noted that Bitcrust has slower peak load verification if the last few blocks contain many inputs, unlike Core. Tomas argued that the minimal disk storage required in Bitcoin cannot be less than all the unspent outputs. He mentioned that improvements like improving locality or keeping spentness in memory do not change the fact that UTXO data remains a significant long-term resource cost. However, during peak load block validation with pre-synced transactions, accessing storage can be minimized. The conversation also touched on the misaligned incentives and the impact of small outputs on long-term costs.The bitcoin-dev mailing list discussion debated whether application-layer caching is necessary or if allowing the operating system to use disk caching or memory map caching would be more effective. It was mentioned that an explicit cache is beneficial on lower memory systems but actually a de-optimization on high RAM systems. Eric Voskuil suggested that reducing the need for paging can be achieved through caching, while another participant argued that sorting data based on frequency of use would beat any application-layer cache. They suggested leaving caching decisions to the operating system based on spatial and temporal locality of reference.The discussion on optimization for lower memory platforms focused on reducing the need for paging through caching. Bram Cohen suggested maximizing memory usage and minimizing disk access, but others disagreed, stating that an application-layer cache only makes sense with a clear distinction between often-used and not often-used data. They emphasized the importance of proper spatial and temporal locality of reference and letting the operating system make caching decisions.The discussion on the long-term resource requirements of proposals with regards to unspent output data questioned whether cramming as much as possible into memory and minimizing disk access is the best approach. Bram Cohen asked if this optimization overlooks considerations such as startup time, warm-up time, shutdown time, fault tolerance, etc. The discussion highlighted the trade-offs and complexities involved in managing these considerations.Tomas introduced Bitcrust, a new Bitcoin implementation that uses a different approach to indexing for verifying the order of transactions. Instead of using an index of unspent outputs, double spends are verified using a spend-tree. Bitcrust has shown excellent performance characteristics, particularly in peak load order validation. The discussion also mentioned the possibility of integrating Bitcrust into Bitcoin Core as a selectable feature.Tomas proposed a solution to address the issue of UTXO growth in the Bitcoin protocol by reversing the costs of outputs and inputs. However, there are concerns about the long-term resource requirements and whether this protocol improvement is worth considering.Overall, the discussions on the bitcoin-dev mailing list covered various topics related to transaction indexes, resource costs, caching, and optimization for lower memory platforms. The conversations provided insights into different perspectives and considerations in Bitcoin development.In another conversation, Tomas explained how Bitcrust separates script validation from order validation and deals with changing validity rules based on block height. Script validation requires a (U)TXO database that consumes around 2GB of outputs. Order validation, on the other hand, requires a spent-index (~200MB) and a spent-tree (~500MB). Tomas mentioned that pruning the 5.7GB full spend tree is not worth it at the moment. When asked about how the spent index rejects a transaction that claims to spend an output that never existed, Tomas did not provide a direct answer.Tomas has - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2017/combined_extended-BIP9-activation-of-segwit-for-legacy-nodes.xml b/static/bitcoin-dev/April_2017/combined_extended-BIP9-activation-of-segwit-for-legacy-nodes.xml index 6c202dce6f..49cce9a4cd 100644 --- a/static/bitcoin-dev/April_2017/combined_extended-BIP9-activation-of-segwit-for-legacy-nodes.xml +++ b/static/bitcoin-dev/April_2017/combined_extended-BIP9-activation-of-segwit-for-legacy-nodes.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - extended BIP9 activation of segwit, for legacy nodes - 2023-08-01T20:27:08.540728+00:00 - - Ryan Grant 2017-06-11 19:31:00+00:00 - - - shaolinfry 2017-04-14 20:33:40+00:00 - - - Ryan Grant 2017-04-14 20:12:34+00:00 - + 2025-09-26T15:46:29.374380+00:00 + python-feedgen + + + [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes Ryan Grant + 2017-04-14T20:12:00.000Z + + + shaolinfry + 2017-04-14T20:33:00.000Z + + + Ryan Grant + 2017-06-11T19:31:00.000Z + + - python-feedgen + 2 Combined summary - extended BIP9 activation of segwit, for legacy nodes - 2023-08-01T20:27:08.540728+00:00 + 2025-09-26T15:46:29.374948+00:00 - The proposal aims to activate a BIP149-like segwit in November, allowing for easy testing and deployment. It emphasizes the need for inevitability rather than time for legacy nodes to upgrade. The proposal suggests deploying segwit separately for legacy and semi-legacy nodes to provide immediate participation for semi-legacy nodes. It does not specify deployment specifics but leaves it to future proposals.If the proposed idea is found to be broken or of no benefit during testing, the alternative deployment method (DEPLOYMENT_SEGWIT_ALT1) can be avoided until it expires. Without this proposal, the activation process for BIP149ish would be slow and difficult to plan due to debates, tests, and a courtesy timeout. However, with this proposal, the courtesy period begins as soon as it goes live, simplifying the debate on how BIP149ish should deploy and enabling quicker activation of segwit.Additionally, Shaolinfry has suggested the bip-uaversionbits proposal, which involves reserving a backward compatibility bit for all yet-unknown segwit-compatible proposals to utilize. This proposal aims to allow validating nodes that already support segwit to participate fully without further upgrades, even if segwit is activated through alternate means. It also suggests that future BIP9-compatible deployment attempts may include a date-dependent UASF fallback.By using the proposed backward-compatible bit, more legacy nodes would understand and validate transactions using segregated witnesses after 95% of recent blocks signal for the alternate segwit deployment. The proposal suggests a conservative expiration time of five years for Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147). The provided email includes the proposed deployment logic for segwit.Overall, the activation of segwit has proven to be more challenging than anticipated, but the technical consensus remains clear. The proposal aims to enable validating nodes capable of supporting segwit to participate fully without further upgrades. Despite the slow nature of upgrades on the Bitcoin network, there are distinct advantages to validating and generating segregated witness transactions. 2017-06-11T19:31:00+00:00 + The proposal aims to activate a BIP149-like segwit in November, allowing for easy testing and deployment. It emphasizes the need for inevitability rather than time for legacy nodes to upgrade. The proposal suggests deploying segwit separately for legacy and semi-legacy nodes to provide immediate participation for semi-legacy nodes. It does not specify deployment specifics but leaves it to future proposals.If the proposed idea is found to be broken or of no benefit during testing, the alternative deployment method (DEPLOYMENT_SEGWIT_ALT1) can be avoided until it expires. Without this proposal, the activation process for BIP149ish would be slow and difficult to plan due to debates, tests, and a courtesy timeout. However, with this proposal, the courtesy period begins as soon as it goes live, simplifying the debate on how BIP149ish should deploy and enabling quicker activation of segwit.Additionally, Shaolinfry has suggested the bip-uaversionbits proposal, which involves reserving a backward compatibility bit for all yet-unknown segwit-compatible proposals to utilize. This proposal aims to allow validating nodes that already support segwit to participate fully without further upgrades, even if segwit is activated through alternate means. It also suggests that future BIP9-compatible deployment attempts may include a date-dependent UASF fallback.By using the proposed backward-compatible bit, more legacy nodes would understand and validate transactions using segregated witnesses after 95% of recent blocks signal for the alternate segwit deployment. The proposal suggests a conservative expiration time of five years for Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147). The provided email includes the proposed deployment logic for segwit.Overall, the activation of segwit has proven to be more challenging than anticipated, but the technical consensus remains clear. The proposal aims to enable validating nodes capable of supporting segwit to participate fully without further upgrades. Despite the slow nature of upgrades on the Bitcoin network, there are distinct advantages to validating and generating segregated witness transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_BIP-sighash-noinput.xml b/static/bitcoin-dev/April_2018/combined_BIP-sighash-noinput.xml index 43f6d8d1b4..bdd26dd23f 100644 --- a/static/bitcoin-dev/April_2018/combined_BIP-sighash-noinput.xml +++ b/static/bitcoin-dev/April_2018/combined_BIP-sighash-noinput.xml @@ -1,110 +1,147 @@ - + 2 Combined summary - BIP sighash_noinput - 2023-08-01T22:58:34.573011+00:00 - - Jonas Nick 2018-09-26 20:40:02+00:00 - - - Johnson Lau 2018-09-26 19:45:49+00:00 - - - Jonas Nick 2018-09-26 09:36:57+00:00 - - - Christian Decker 2018-07-13 11:07:48+00:00 - - - fred savage 2018-07-13 09:50:47+00:00 - - - Rusty Russell 2018-07-13 00:04:14+00:00 - - - ZmnSCPxj 2018-07-11 07:43:49+00:00 - - - Peter Todd 2018-07-09 09:41:39+00:00 - - - vv01f 2018-07-05 08:18:44+00:00 - - - fred savage 2018-07-04 18:08:43+00:00 - - - Gregory Maxwell 2018-07-03 23:45:22+00:00 - - - Luke Dashjr 2018-07-03 12:13:44+00:00 - - - Christian Decker 2018-07-03 12:05:09+00:00 - - - William Casarin 2018-07-03 11:54:37+00:00 - - - ZmnSCPxj 2018-07-03 06:58:36+00:00 - - - Peter Todd 2018-07-03 05:21:00+00:00 - - - Rusty Russell 2018-07-03 04:56:53+00:00 - - - Gregory Maxwell 2018-07-02 18:11:54+00:00 - - - Christian Decker 2018-05-15 14:28:22+00:00 - - - Anthony Towns 2018-05-14 09:23:29+00:00 - - - Christian Decker 2018-05-10 14:12:21+00:00 - - - Rusty Russell 2018-05-09 23:04:58+00:00 - - - Olaoluwa Osuntokun 2018-05-09 23:01:39+00:00 - - - Anthony Towns 2018-05-08 14:40:21+00:00 - - - Olaoluwa Osuntokun 2018-05-07 23:47:23+00:00 - - - Bram Cohen 2018-05-07 20:51:11+00:00 - - - Christian Decker 2018-05-07 19:40:46+00:00 - - - ZmnSCPxj 2018-05-04 14:25:46+00:00 - - - Christian Decker 2018-05-04 11:09:09+00:00 - - - ZmnSCPxj 2018-05-04 09:15:41+00:00 - - - Christian Decker 2018-05-01 17:32:32+00:00 - - - Russell O'Connor 2018-05-01 16:58:37+00:00 - - - Dario Sneidermanis 2018-04-30 18:25:42+00:00 - - - Christian Decker 2018-04-30 16:29:53+00:00 - + 2025-09-26T16:06:11.559590+00:00 + python-feedgen + + + [bitcoin-dev] BIP sighash_noinput Christian Decker + 2018-04-30T16:29:00.000Z + + + Dario Sneidermanis + 2018-04-30T18:25:00.000Z + + + Russell O'Connor + 2018-05-01T16:58:00.000Z + + + Christian Decker + 2018-05-01T17:32:00.000Z + + + ZmnSCPxj + 2018-05-04T09:15:00.000Z + + + Christian Decker + 2018-05-04T11:09:00.000Z + + + ZmnSCPxj + 2018-05-04T14:25:00.000Z + + + Christian Decker + 2018-05-07T19:40:00.000Z + + + Bram Cohen + 2018-05-07T20:51:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2018-05-07T23:47:00.000Z + + + [bitcoin-dev] " Anthony Towns + 2018-05-08T14:40:00.000Z + + + Olaoluwa Osuntokun + 2018-05-09T23:01:00.000Z + + + Rusty Russell + 2018-05-09T23:04:00.000Z + + + Christian Decker + 2018-05-10T14:12:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2018-05-14T09:23:00.000Z + + + Christian Decker + 2018-05-15T14:28:00.000Z + + + Gregory Maxwell + 2018-07-02T18:11:00.000Z + + + Rusty Russell + 2018-07-03T04:56:00.000Z + + + Peter Todd + 2018-07-03T05:21:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2018-07-03T06:58:00.000Z + + + William Casarin + 2018-07-03T11:54:00.000Z + + + Christian Decker + 2018-07-03T12:05:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Luke Dashjr + 2018-07-03T12:13:00.000Z + + + Gregory Maxwell + 2018-07-03T23:45:00.000Z + + + fred savage + 2018-07-04T18:08:00.000Z + + + vv01f + 2018-07-05T08:18:00.000Z + + + Peter Todd + 2018-07-09T09:41:00.000Z + + + ZmnSCPxj + 2018-07-11T07:43:00.000Z + + + Rusty Russell + 2018-07-13T00:04:00.000Z + + + fred savage + 2018-07-13T09:50:00.000Z + + + Christian Decker + 2018-07-13T11:07:00.000Z + + + Jonas Nick + 2018-09-26T09:36:00.000Z + + + Johnson Lau + 2018-09-26T19:45:00.000Z + + + Jonas Nick + 2018-09-26T20:40:00.000Z + + @@ -139,13 +176,13 @@ - python-feedgen + 2 Combined summary - BIP sighash_noinput - 2023-08-01T22:58:34.573011+00:00 + 2025-09-26T16:06:11.562967+00:00 - The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions. Laolu emphasizes the importance of making the proposal small 2018-09-26T20:40:02+00:00 + The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions. Laolu emphasizes the importance of making the proposal small - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_BloomFilter-issue-with-segwit-addresses.xml b/static/bitcoin-dev/April_2018/combined_BloomFilter-issue-with-segwit-addresses.xml index 234050eaed..0e8fe0abc3 100644 --- a/static/bitcoin-dev/April_2018/combined_BloomFilter-issue-with-segwit-addresses.xml +++ b/static/bitcoin-dev/April_2018/combined_BloomFilter-issue-with-segwit-addresses.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - BloomFilter issue with segwit addresses - 2023-08-01T22:53:14.904926+00:00 - - Andreas Schildbach 2018-04-15 18:37:45+00:00 - - - Jim Posen 2018-04-14 19:46:01+00:00 - - - Christian Decker 2018-04-14 16:14:04+00:00 - - - Luke Dashjr 2018-04-13 22:52:23+00:00 - - - Jim Posen 2018-04-13 22:15:50+00:00 - - - Jonas Schnelli 2018-04-13 19:12:47+00:00 - - - Andreas Schildbach 2018-04-13 15:32:15+00:00 - + 2025-09-26T16:06:17.890191+00:00 + python-feedgen + + + [bitcoin-dev] BloomFilter issue with segwit addresses Andreas Schildbach + 2018-04-13T15:32:00.000Z + + + Jonas Schnelli + 2018-04-13T19:12:00.000Z + + + Jim Posen + 2018-04-13T22:15:00.000Z + + + Luke Dashjr + 2018-04-13T22:52:00.000Z + + + Christian Decker + 2018-04-14T16:14:00.000Z + + + Jim Posen + 2018-04-14T19:46:00.000Z + + + Andreas Schildbach + 2018-04-15T18:37:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - BloomFilter issue with segwit addresses - 2023-08-01T22:53:14.904926+00:00 + 2025-09-26T16:06:17.891011+00:00 - A recent discussion on the Bitcoin-dev mailing list focused on the use of outpoints in filters for standard transactions. Jim Posen suggested including the wallet's owned outpoints in the filter instead of elements in the input script or witness data. However, Christian Decker raised concerns about privacy leaks and the potential for detailed clusters. He also noted that bloom filters are not ideal for privacy. Jonas Schnelli agreed that the current method could be improved and proposed inserting witness data into the bloom filter. A pull request would be needed for any changes to be implemented.Another discussion on the bitcoin-dev mailing list involved Christian Decker expressing privacy concerns about the BIP 158 implementation. He mentioned a possible privacy leak identified by Jonas Nick, where address clusters were discovered through bloom filters. However, Decker acknowledged that bloom filters are not effective for privacy anyway. Jim Posen suggested adding the wallet's owned outpoints to the filter as an alternative to input script or witness data. Jonas Schnelli proposed extending BIP37 and inserting witness data into the bloom filter. The conversation continued on the mailing list.In a separate thread, Andreas Brekken raised the issue of privacy leaks when using bloom filters to identify address clusters. Jonas Schnelli suggested extending BIP37 to match witness data against the filter. Jim Posen proposed including the wallet's owned outpoints in the filter. It was noted that bloom filters are not suitable for privacy, so this concern may not be significant. Bitcoin Core cannot reject or extend features, so a proposal in the form of a pull request is needed.Anton, a developer on the bitcoinj mailing list, highlighted a compatibility issue between SegWit and BIP37. This issue only affects P2WPKH and transactions without change outputs. In such cases, there are no data elements in the inputs or outputs that would match the filter. Anton suggested using an OP_RETURN output with a matching public key as a workaround. Bitcoin Core was asked to extend the BIP37 matching rules to include data elements in the witness. Bitcoin Knots currently supports the MSG_FILTERED_WITNESS_BLOCK extension, but light clients cannot verify the correctness of witness data. It was suggested to look for specific COutPoints for matching, which should already work with standard BIP37. The plan is to deprecate and remove BIP37 once BIP158 is implemented.On April 13th, 2018, Jonas Schnelli responded to Andreas Schildbach's suggestion about the suboptimal matching of data elements and owned outpoints in Bitcoin Core. Jonas proposed inserting witness data into the bloom filter as an easy solution instead of creating an extension for BIP37. He also clarified that Bitcoin Core does not have the authority to decide on features, and proposals need to be presented through pull requests. This conversation took place on the bitcoin-dev mailing list.Andreas suggested extending the BIP37 matching rules for Bitcoin Core to include witness data elements, but Jonas explained that Bitcoin Core cannot make decisions on extending or rejecting features. He recommended submitting a pull request and mentioned inserting witness data into the bloom filter as a potential solution. The discussion appears to be centered around optimizing Bitcoin Core's functionality.Anton, from the bitcoinj mailing list, brought up a compatibility issue between segwit and BIP37 regarding P2WPKH and transactions without change outputs. In these cases, there are no data elements in the inputs or outputs that would match the filter. To address this, it was suggested to include an OP_RETURN output with a matching public key. Anton confirmed that this workaround is effective, although it nullifies some of the size improvements of segwit. There is a question of whether Bitcoin Core would be open to extending the BIP37 matching rules to include data elements in the witness. 2018-04-15T18:37:45+00:00 + A recent discussion on the Bitcoin-dev mailing list focused on the use of outpoints in filters for standard transactions. Jim Posen suggested including the wallet's owned outpoints in the filter instead of elements in the input script or witness data. However, Christian Decker raised concerns about privacy leaks and the potential for detailed clusters. He also noted that bloom filters are not ideal for privacy. Jonas Schnelli agreed that the current method could be improved and proposed inserting witness data into the bloom filter. A pull request would be needed for any changes to be implemented.Another discussion on the bitcoin-dev mailing list involved Christian Decker expressing privacy concerns about the BIP 158 implementation. He mentioned a possible privacy leak identified by Jonas Nick, where address clusters were discovered through bloom filters. However, Decker acknowledged that bloom filters are not effective for privacy anyway. Jim Posen suggested adding the wallet's owned outpoints to the filter as an alternative to input script or witness data. Jonas Schnelli proposed extending BIP37 and inserting witness data into the bloom filter. The conversation continued on the mailing list.In a separate thread, Andreas Brekken raised the issue of privacy leaks when using bloom filters to identify address clusters. Jonas Schnelli suggested extending BIP37 to match witness data against the filter. Jim Posen proposed including the wallet's owned outpoints in the filter. It was noted that bloom filters are not suitable for privacy, so this concern may not be significant. Bitcoin Core cannot reject or extend features, so a proposal in the form of a pull request is needed.Anton, a developer on the bitcoinj mailing list, highlighted a compatibility issue between SegWit and BIP37. This issue only affects P2WPKH and transactions without change outputs. In such cases, there are no data elements in the inputs or outputs that would match the filter. Anton suggested using an OP_RETURN output with a matching public key as a workaround. Bitcoin Core was asked to extend the BIP37 matching rules to include data elements in the witness. Bitcoin Knots currently supports the MSG_FILTERED_WITNESS_BLOCK extension, but light clients cannot verify the correctness of witness data. It was suggested to look for specific COutPoints for matching, which should already work with standard BIP37. The plan is to deprecate and remove BIP37 once BIP158 is implemented.On April 13th, 2018, Jonas Schnelli responded to Andreas Schildbach's suggestion about the suboptimal matching of data elements and owned outpoints in Bitcoin Core. Jonas proposed inserting witness data into the bloom filter as an easy solution instead of creating an extension for BIP37. He also clarified that Bitcoin Core does not have the authority to decide on features, and proposals need to be presented through pull requests. This conversation took place on the bitcoin-dev mailing list.Andreas suggested extending the BIP37 matching rules for Bitcoin Core to include witness data elements, but Jonas explained that Bitcoin Core cannot make decisions on extending or rejecting features. He recommended submitting a pull request and mentioned inserting witness data into the bloom filter as a potential solution. The discussion appears to be centered around optimizing Bitcoin Core's functionality.Anton, from the bitcoinj mailing list, brought up a compatibility issue between segwit and BIP37 regarding P2WPKH and transactions without change outputs. In these cases, there are no data elements in the inputs or outputs that would match the filter. To address this, it was suggested to include an OP_RETURN output with a matching public key. Anton confirmed that this workaround is effective, although it nullifies some of the size improvements of segwit. There is a question of whether Bitcoin Core would be open to extending the BIP37 matching rules to include data elements in the witness. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_Few-questions-regarding-ListTransaction.xml b/static/bitcoin-dev/April_2018/combined_Few-questions-regarding-ListTransaction.xml index 3f056d394d..c4a6976d48 100644 --- a/static/bitcoin-dev/April_2018/combined_Few-questions-regarding-ListTransaction.xml +++ b/static/bitcoin-dev/April_2018/combined_Few-questions-regarding-ListTransaction.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Few questions regarding ListTransaction - 2023-08-01T22:52:47.537604+00:00 - - Maksim Solovjov 2018-04-11 19:58:45+00:00 - - - Karl-Johan Alm 2018-04-11 10:00:45+00:00 - - - ZmnSCPxj 2018-04-11 09:48:39+00:00 - - - Peter Todd 2018-04-11 09:37:24+00:00 - - - Karl-Johan Alm 2018-04-11 08:10:43+00:00 - - - Peter Todd 2018-04-11 07:52:25+00:00 - - - Karl-Johan Alm 2018-04-11 05:22:42+00:00 - - - Karl-Johan Alm 2018-04-11 05:21:10+00:00 - - - Joseph Gleason ⑈ 2018-04-10 20:41:07+00:00 - - - Maksim Solovjov 2018-04-10 20:29:23+00:00 - + 2025-09-26T16:06:26.252706+00:00 + python-feedgen + + + [bitcoin-dev] Few questions regarding ListTransaction Maksim Solovjov + 2018-04-10T20:29:00.000Z + + + Joseph Gleason ⑈ + 2018-04-10T20:41:00.000Z + + + Karl-Johan Alm + 2018-04-11T05:21:00.000Z + + + Karl-Johan Alm + 2018-04-11T05:22:00.000Z + + + Peter Todd + 2018-04-11T07:52:00.000Z + + + Karl-Johan Alm + 2018-04-11T08:10:00.000Z + + + Peter Todd + 2018-04-11T09:37:00.000Z + + + ZmnSCPxj + 2018-04-11T09:48:00.000Z + + + Karl-Johan Alm + 2018-04-11T10:00:00.000Z + + + Maksim Solovjov + 2018-04-11T19:58:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Few questions regarding ListTransaction - 2023-08-01T22:52:47.537604+00:00 + 2025-09-26T16:06:26.253928+00:00 - In a recent discussion on the bitcoin-dev mailing list, it was clarified that miners can ignore nSequence when adding transactions to blocks. This means that if there are conflicting transactions with different fees, miners can include the one with the higher fee even if they learned about the other one first. As a result, "full replace-by-fee" is expected to become the norm, where nSequence is ignored for replace-by-fee purposes. The convention of nSequence=0xFFFFFFFF meaning opt-out of RBF is only followed by full nodes running standard bitcoind. Miners can run patched bitcoind that ignores this rule and connect with similar peers who also ignore it.Peter Todd, a member of the bitcoin-dev mailing list, mentioned that his full-replace-by-fee tree ignores nSequence=0xFFFFFFFF and does preferential peering to ensure it's well connected with like-minded peers and the whole network. In an email conversation between ZmnSCPxj and Karl-Johan Alm, it was clarified that miners can completely ignore nSequence when putting transactions in blocks. Therefore, "full replace-by-fee" is expected to become the norm, and wallets should be designed to only trust transactions with confirmations.Furthermore, Peter Todd stated that his full-replace-by-fee tree ignores the convention of nSequence=0xFFFFFFFF. He also mentioned that full replace-by-fee appears to be used by a significant minority of miners. Todd's system uses preferential peering to ensure it is well connected with like-minded peers on the network.Additionally, the email conversation between Karl-Johan Alm and Peter Todd discussed the possibility of using full replace-by-fee, which is allegedly used by a significant minority of miners. Alm questioned whether final transactions with sequence=0xffffffff could be replaced using RBF, but Todd's full-replace-by-fee tree ignores this rule. Todd also noted that his system uses preferential peering to ensure it is well connected with like-minded peers on the network.In another email exchange between Karl-Johan Alm and Peter Todd, Todd mentioned that a significant minority of miners are using full replace-by-fee (RBF). However, he was unsure if final transactions with a sequence of 0xffffffff could be replaced using RBF. Todd's GitHub includes information about RBF in Bitcoin version 0.16.0, and replacing transactions via RBF is reportedly easy.The discussion also touched on the topic of transaction confirmations. A transaction is considered trusted if it is final, not in a block that was reorged out, has the 'spend zero conf change' option set, is in the mempool, and all inputs are from the sender. However, it is always possible to replace an unconfirmed transaction by asking a miner to mine a conflicting transaction directly. Full replace-by-fee (RBF) can be used by a significant minority of miners to replace any transaction. Therefore, wallets should be designed to only trust transactions that have confirmations, making it difficult for malicious actors to exploit the replace-by-fee feature.There were also discussions about the trustworthiness of transactions with zero confirmations. A transaction is considered trusted if it meets certain criteria, including being final, not in a reorged block, and having all inputs from the sender. It is important to note that having zero confirmations does not necessarily mean a transaction is untrustworthy, but rather its trustworthiness depends on the criteria mentioned above.Another conversation focused on questions related to the ListTransaction RPC call. One question asked about the meaning of a transaction being "trusted" or not, particularly in the case of transactions with zero confirmations. The response suggested that nothing in bitcoin is trusted without a certain number of confirmations. Another question asked about when the "confirmations" field can be -1 (conflicted) and what it means to have a conflicted transaction. The response clarified that -1 does not mean conflicted but rather indicates that the transaction is unconfirmed and depends on another unconfirmed transaction. There was also a question about adding a watch-only address to bitcoind and whether a first transaction will appear in walletconflicts if a second transaction occurs due to Transaction Malleability, but no response was provided to this question.Overall, these discussions shed light on the use of full replace-by-fee by miners, the importance of transaction confirmations, and the criteria for trusting transactions with zero confirmations. It also highlighted the possibility of replacing unconfirmed transactions through RBF and the potential vulnerabilities associated with this feature. 2018-04-11T19:58:45+00:00 + In a recent discussion on the bitcoin-dev mailing list, it was clarified that miners can ignore nSequence when adding transactions to blocks. This means that if there are conflicting transactions with different fees, miners can include the one with the higher fee even if they learned about the other one first. As a result, "full replace-by-fee" is expected to become the norm, where nSequence is ignored for replace-by-fee purposes. The convention of nSequence=0xFFFFFFFF meaning opt-out of RBF is only followed by full nodes running standard bitcoind. Miners can run patched bitcoind that ignores this rule and connect with similar peers who also ignore it.Peter Todd, a member of the bitcoin-dev mailing list, mentioned that his full-replace-by-fee tree ignores nSequence=0xFFFFFFFF and does preferential peering to ensure it's well connected with like-minded peers and the whole network. In an email conversation between ZmnSCPxj and Karl-Johan Alm, it was clarified that miners can completely ignore nSequence when putting transactions in blocks. Therefore, "full replace-by-fee" is expected to become the norm, and wallets should be designed to only trust transactions with confirmations.Furthermore, Peter Todd stated that his full-replace-by-fee tree ignores the convention of nSequence=0xFFFFFFFF. He also mentioned that full replace-by-fee appears to be used by a significant minority of miners. Todd's system uses preferential peering to ensure it is well connected with like-minded peers on the network.Additionally, the email conversation between Karl-Johan Alm and Peter Todd discussed the possibility of using full replace-by-fee, which is allegedly used by a significant minority of miners. Alm questioned whether final transactions with sequence=0xffffffff could be replaced using RBF, but Todd's full-replace-by-fee tree ignores this rule. Todd also noted that his system uses preferential peering to ensure it is well connected with like-minded peers on the network.In another email exchange between Karl-Johan Alm and Peter Todd, Todd mentioned that a significant minority of miners are using full replace-by-fee (RBF). However, he was unsure if final transactions with a sequence of 0xffffffff could be replaced using RBF. Todd's GitHub includes information about RBF in Bitcoin version 0.16.0, and replacing transactions via RBF is reportedly easy.The discussion also touched on the topic of transaction confirmations. A transaction is considered trusted if it is final, not in a block that was reorged out, has the 'spend zero conf change' option set, is in the mempool, and all inputs are from the sender. However, it is always possible to replace an unconfirmed transaction by asking a miner to mine a conflicting transaction directly. Full replace-by-fee (RBF) can be used by a significant minority of miners to replace any transaction. Therefore, wallets should be designed to only trust transactions that have confirmations, making it difficult for malicious actors to exploit the replace-by-fee feature.There were also discussions about the trustworthiness of transactions with zero confirmations. A transaction is considered trusted if it meets certain criteria, including being final, not in a reorged block, and having all inputs from the sender. It is important to note that having zero confirmations does not necessarily mean a transaction is untrustworthy, but rather its trustworthiness depends on the criteria mentioned above.Another conversation focused on questions related to the ListTransaction RPC call. One question asked about the meaning of a transaction being "trusted" or not, particularly in the case of transactions with zero confirmations. The response suggested that nothing in bitcoin is trusted without a certain number of confirmations. Another question asked about when the "confirmations" field can be -1 (conflicted) and what it means to have a conflicted transaction. The response clarified that -1 does not mean conflicted but rather indicates that the transaction is unconfirmed and depends on another unconfirmed transaction. There was also a question about adding a watch-only address to bitcoind and whether a first transaction will appear in walletconflicts if a second transaction occurs due to Transaction Malleability, but no response was provided to this question.Overall, these discussions shed light on the use of full replace-by-fee by miners, the importance of transaction confirmations, and the criteria for trusting transactions with zero confirmations. It also highlighted the possibility of replacing unconfirmed transactions through RBF and the potential vulnerabilities associated with this feature. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_KETAMINE-Multiple-vulnerabilities-in-SecureRandom-numerous-cryptocurrency-products-affected-.xml b/static/bitcoin-dev/April_2018/combined_KETAMINE-Multiple-vulnerabilities-in-SecureRandom-numerous-cryptocurrency-products-affected-.xml index 30c257c323..ba14c0026d 100644 --- a/static/bitcoin-dev/April_2018/combined_KETAMINE-Multiple-vulnerabilities-in-SecureRandom-numerous-cryptocurrency-products-affected-.xml +++ b/static/bitcoin-dev/April_2018/combined_KETAMINE-Multiple-vulnerabilities-in-SecureRandom-numerous-cryptocurrency-products-affected-.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. - 2023-08-01T22:52:15.274680+00:00 - - Aymeric Vitte 2018-04-10 13:50:40+00:00 - - - Jason Davies 2018-04-10 13:32:36+00:00 - - - Aymeric Vitte 2018-04-10 13:15:22+00:00 - - - Jason Davies 2018-04-10 08:51:51+00:00 - - - Jason Davies 2018-04-10 00:42:32+00:00 - - - Mustafa Al-Bassam 2018-04-09 23:39:15+00:00 - - - Mustafa Al-Bassam 2018-04-09 21:17:11+00:00 - - - Mustafa Al-Bassam 2018-04-09 21:11:02+00:00 - - - Matias Alejo Garcia 2018-04-06 20:51:11+00:00 - - - ketamine at national.shitposting.agency 2018-04-06 19:53:13+00:00 - + 2025-09-26T16:06:03.164220+00:00 + python-feedgen + + + [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected ketamine + 2018-04-06T19:53:00.000Z + + + Matias Alejo Garcia + 2018-04-06T20:51:00.000Z + + + Mustafa Al-Bassam + 2018-04-09T21:11:00.000Z + + + Mustafa Al-Bassam + 2018-04-09T21:17:00.000Z + + + Mustafa Al-Bassam + 2018-04-09T23:39:00.000Z + + + Jason Davies + 2018-04-10T00:42:00.000Z + + + Jason Davies + 2018-04-10T08:51:00.000Z + + + Aymeric Vitte + 2018-04-10T13:15:00.000Z + + + Jason Davies + 2018-04-10T13:32:00.000Z + + + Aymeric Vitte + 2018-04-10T13:50:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected. - 2023-08-01T22:52:15.274680+00:00 + 2025-09-26T16:06:03.165405+00:00 - The implementation of the Web Cryptography API in Internet Explorer differs from other browsers as it uses window.msCrypto instead of window.crypto. This means that without using msCrypto.getRandomValues, high-quality entropy will not be utilized by any library under Internet Explorer. Bitcoin wallets using a pre-2013 version of jsbn, a JavaScript crypto library, may not be using a CSPRNG when run on a modern browser. Even with the latest version of jsbn, high-quality entropy is still not used for Internet Explorer because getRandomValues is provided under window.msCrypto for that browser. Additionally, the library passes the output of the CSPRNG through RC4, which generates biased bits and can lead to possible private key recovery.A vulnerability disclosure was made regarding the pre-2013 version of jsbn, stating that it contains a JavaScript class named SecureRandom() with deficient entropy collection and a PRNG. This allows for key material to be recovered by a third party with medium complexity. The library attempts to collect entropy from window.crypto's CSPRNG, but due to a type error in a comparison, this function is silently skipped. Entropy is then gathered from math.Random and a single execution of a medium-resolution timer, resulting in less than 48 bits of entropy in some configurations. The core of the RNG is an implementation of RC4, which has biases that can be exploited to recover an ECDSA private key. Necessary actions include identifying and moving funds stored using SecureRandom(), rotating all key material generated by or in contact with any software using SecureRandom(), and not passing the output of a CSPRNG through RC4.Further investigation revealed that many cryptocurrency products contain the SecureRandom() class with deficient entropy collection and a PRNG. The library attempts to collect entropy from window.crypto's CSPRNG, but a type error causes it to be skipped without failing. Entropy is then gathered from math.Random and a timer, resulting in less than 48 bits of entropy in some cases. The core of the RNG is an implementation of RC4, which has biases that can be exploited to recover an ECDSA private key. It is recommended to identify and move funds stored using SecureRandom(), rotate all key material generated by or in contact with any software using SecureRandom(), and avoid passing the output of a CSPRNG through RC4.A JavaScript class named SecureRandom() used in many cryptocurrency products has deficient entropy collection and a PRNG, allowing for key material to be recovered by a third party. The library attempts to collect entropy from window.crypto's CSPRNG, but due to a type error, this function is silently skipped. Entropy is then gathered from math.Random and a timer, resulting in less than 48 bits of entropy in some configurations. The core of the RNG is an implementation of RC4, which has biases that can be exploited to recover an ECDSA private key. It is advised to identify and move funds stored using SecureRandom(), rotate all key material generated by or in contact with any software using SecureRandom(), and avoid passing the output of a CSPRNG through RC4. 2018-04-10T13:50:40+00:00 + The implementation of the Web Cryptography API in Internet Explorer differs from other browsers as it uses window.msCrypto instead of window.crypto. This means that without using msCrypto.getRandomValues, high-quality entropy will not be utilized by any library under Internet Explorer. Bitcoin wallets using a pre-2013 version of jsbn, a JavaScript crypto library, may not be using a CSPRNG when run on a modern browser. Even with the latest version of jsbn, high-quality entropy is still not used for Internet Explorer because getRandomValues is provided under window.msCrypto for that browser. Additionally, the library passes the output of the CSPRNG through RC4, which generates biased bits and can lead to possible private key recovery.A vulnerability disclosure was made regarding the pre-2013 version of jsbn, stating that it contains a JavaScript class named SecureRandom() with deficient entropy collection and a PRNG. This allows for key material to be recovered by a third party with medium complexity. The library attempts to collect entropy from window.crypto's CSPRNG, but due to a type error in a comparison, this function is silently skipped. Entropy is then gathered from math.Random and a single execution of a medium-resolution timer, resulting in less than 48 bits of entropy in some configurations. The core of the RNG is an implementation of RC4, which has biases that can be exploited to recover an ECDSA private key. Necessary actions include identifying and moving funds stored using SecureRandom(), rotating all key material generated by or in contact with any software using SecureRandom(), and not passing the output of a CSPRNG through RC4.Further investigation revealed that many cryptocurrency products contain the SecureRandom() class with deficient entropy collection and a PRNG. The library attempts to collect entropy from window.crypto's CSPRNG, but a type error causes it to be skipped without failing. Entropy is then gathered from math.Random and a timer, resulting in less than 48 bits of entropy in some cases. The core of the RNG is an implementation of RC4, which has biases that can be exploited to recover an ECDSA private key. It is recommended to identify and move funds stored using SecureRandom(), rotate all key material generated by or in contact with any software using SecureRandom(), and avoid passing the output of a CSPRNG through RC4.A JavaScript class named SecureRandom() used in many cryptocurrency products has deficient entropy collection and a PRNG, allowing for key material to be recovered by a third party. The library attempts to collect entropy from window.crypto's CSPRNG, but due to a type error, this function is silently skipped. Entropy is then gathered from math.Random and a timer, resulting in less than 48 bits of entropy in some configurations. The core of the RNG is an implementation of RC4, which has biases that can be exploited to recover an ECDSA private key. It is advised to identify and move funds stored using SecureRandom(), rotate all key material generated by or in contact with any software using SecureRandom(), and avoid passing the output of a CSPRNG through RC4. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_Low-bandwidth-transaction-relay.xml b/static/bitcoin-dev/April_2018/combined_Low-bandwidth-transaction-relay.xml index c64056a297..0f42b133d9 100644 --- a/static/bitcoin-dev/April_2018/combined_Low-bandwidth-transaction-relay.xml +++ b/static/bitcoin-dev/April_2018/combined_Low-bandwidth-transaction-relay.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Low-bandwidth transaction relay - 2023-08-01T22:51:24.393448+00:00 - - Gleb Naumenko 2018-04-04 04:55:45+00:00 - - - Gleb Naumenko 2018-04-04 02:10:56+00:00 - - - Gregory Maxwell 2018-04-03 19:05:40+00:00 - - - Jim Posen 2018-04-03 17:45:34+00:00 - - - Gleb Naumenko 2018-04-02 22:18:07+00:00 - + 2025-09-26T16:06:07.347197+00:00 + python-feedgen + + + [bitcoin-dev] Low-bandwidth transaction relay Gleb Naumenko + 2018-04-02T22:18:00.000Z + + + Jim Posen + 2018-04-03T17:45:00.000Z + + + Gregory Maxwell + 2018-04-03T19:05:00.000Z + + + Gleb Naumenko + 2018-04-04T02:10:00.000Z + + + Gleb Naumenko + 2018-04-04T04:55:00.000Z + + - python-feedgen + 2 Combined summary - Low-bandwidth transaction relay - 2023-08-01T22:51:24.393448+00:00 + 2025-09-26T16:06:07.347948+00:00 - Bitcoin developer Gleb Naumenko has proposed a new protocol to reduce redundancy in transaction relay and improve the efficiency of the Bitcoin network's mempool synchronization. Currently, around 90% of INV messages sent by public-IP nodes are idle duplicates, consuming significant bandwidth. Naumenko's idea involves having new nodes agree on filters with each of the eight nodes they connect to when joining the network. This would allow nodes to relay only a subset of transactions, significantly reducing redundancy. To maintain robustness and latency while protecting against attacks, Naumenko suggests implementing set reconciliation and rotating filters every N minutes.Naumenko conducted emulation and simulation tests to validate his proposal. He found that the proposed protocol could filter transactions through N=2 links, similar to BIP37 but applied to public-IP nodes. By implementing this protocol, the redundancy issue can be addressed without compromising zero-trust and decentralization guarantees. However, Naumenko acknowledges potential concerns about latency and the need for further experiments before setting filters on inbound peers.On April 2, 2018, Naumenko shared his ideas on the bitcoin-dev mailing list and invited feedback. The proposal received mixed reactions from the community. Some expressed concerns about its impact on privacy and censorship resistance, while others praised it for its potential to improve network performance and scalability. Although the discussion thread on the mailing list is now closed, the links to Naumenko's proposal and the discussion thread remain available for those interested in reviewing the details.Overall, Naumenko's proposal aims to reduce redundancy in transaction relay and improve the efficiency of the Bitcoin network's mempool synchronization. The protocol involves filtering transactions through agreed-upon filters between new nodes and their connecting peers. While there are concerns and considerations to address, such as latency and potential impact on privacy, Naumenko's proposal offers potential solutions to enhance network performance and scalability. 2018-04-04T04:55:45+00:00 + Bitcoin developer Gleb Naumenko has proposed a new protocol to reduce redundancy in transaction relay and improve the efficiency of the Bitcoin network's mempool synchronization. Currently, around 90% of INV messages sent by public-IP nodes are idle duplicates, consuming significant bandwidth. Naumenko's idea involves having new nodes agree on filters with each of the eight nodes they connect to when joining the network. This would allow nodes to relay only a subset of transactions, significantly reducing redundancy. To maintain robustness and latency while protecting against attacks, Naumenko suggests implementing set reconciliation and rotating filters every N minutes.Naumenko conducted emulation and simulation tests to validate his proposal. He found that the proposed protocol could filter transactions through N=2 links, similar to BIP37 but applied to public-IP nodes. By implementing this protocol, the redundancy issue can be addressed without compromising zero-trust and decentralization guarantees. However, Naumenko acknowledges potential concerns about latency and the need for further experiments before setting filters on inbound peers.On April 2, 2018, Naumenko shared his ideas on the bitcoin-dev mailing list and invited feedback. The proposal received mixed reactions from the community. Some expressed concerns about its impact on privacy and censorship resistance, while others praised it for its potential to improve network performance and scalability. Although the discussion thread on the mailing list is now closed, the links to Naumenko's proposal and the discussion thread remain available for those interested in reviewing the details.Overall, Naumenko's proposal aims to reduce redundancy in transaction relay and improve the efficiency of the Bitcoin network's mempool synchronization. The protocol involves filtering transactions through agreed-upon filters between new nodes and their connecting peers. While there are concerns and considerations to address, such as latency and potential impact on privacy, Naumenko's proposal offers potential solutions to enhance network performance and scalability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_Multi-signature-and-multi-coin-HD-wallet-in-one-BIP32-derivation-path-new-BIP-.xml b/static/bitcoin-dev/April_2018/combined_Multi-signature-and-multi-coin-HD-wallet-in-one-BIP32-derivation-path-new-BIP-.xml index 2eef42eb8c..aa2364609e 100644 --- a/static/bitcoin-dev/April_2018/combined_Multi-signature-and-multi-coin-HD-wallet-in-one-BIP32-derivation-path-new-BIP-.xml +++ b/static/bitcoin-dev/April_2018/combined_Multi-signature-and-multi-coin-HD-wallet-in-one-BIP32-derivation-path-new-BIP-.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP) - 2023-08-01T22:53:40.079698+00:00 - - Paul Brown 2018-05-04 08:23:21+00:00 - - - Clark Moody 2018-05-04 00:09:38+00:00 - - - Paul Brown 2018-04-26 14:05:06+00:00 - - - Paul Brown 2018-04-25 16:44:55+00:00 - - - Clark Moody 2018-04-25 14:35:57+00:00 - - - Paul Brown 2018-04-25 09:35:03+00:00 - + 2025-09-26T16:06:19.981916+00:00 + python-feedgen + + + [bitcoin-dev] Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP) Paul Brown + 2018-04-25T09:35:00.000Z + + + Clark Moody + 2018-04-25T14:35:00.000Z + + + Paul Brown + 2018-04-25T16:44:00.000Z + + + Paul Brown + 2018-04-26T14:05:00.000Z + + + Clark Moody + 2018-05-04T00:09:00.000Z + + + Paul Brown + 2018-05-04T08:23:00.000Z + + - python-feedgen + 2 Combined summary - Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP) - 2023-08-01T22:53:40.079698+00:00 + 2025-09-26T16:06:19.982809+00:00 - In a discussion on the Bitcoin Development mailing list, Paul Brown proposed a new BIP32 derivation path that supports a single or multi-signature and multi-coin wallet from a single master seed. The proposal combines BIP44 and BIP45, addressing issues with BIP44's lack of clarity in terms of address format, representation of single-sig or multi-sig wallets, number of cosigners, and collision prevention on the same address index. Brown suggests using bech32 serialized addresses and extending the derivation path below coin type to represent the address format. He proposes creating a separate specification similar to SLIP-0044 to define the list of address formats and derivation path values, allowing for future address formats to be easily supported. Clark Moody suggests using the xpub serialization format described in SLIP-0032 as an alternative solution, which includes the derivation path within the xpub itself and uses Bech32 for encoding. Moody argues that this solves the bootstrapping problem and avoids the requirement for users to know the specific BIP number. Brown responds by acknowledging that his initial encoding was incorrect and suggests further extending the derivation path based on the coin type value. He believes a separate spec can be created to support different address formats without requiring new BIPs. The proposal includes several links to other related Bitcoin Improvement Proposals and discussions on addressing collisions and separating cosigners in the derivation path. 2018-05-04T08:23:21+00:00 + In a discussion on the Bitcoin Development mailing list, Paul Brown proposed a new BIP32 derivation path that supports a single or multi-signature and multi-coin wallet from a single master seed. The proposal combines BIP44 and BIP45, addressing issues with BIP44's lack of clarity in terms of address format, representation of single-sig or multi-sig wallets, number of cosigners, and collision prevention on the same address index. Brown suggests using bech32 serialized addresses and extending the derivation path below coin type to represent the address format. He proposes creating a separate specification similar to SLIP-0044 to define the list of address formats and derivation path values, allowing for future address formats to be easily supported. Clark Moody suggests using the xpub serialization format described in SLIP-0032 as an alternative solution, which includes the derivation path within the xpub itself and uses Bech32 for encoding. Moody argues that this solves the bootstrapping problem and avoids the requirement for users to know the specific BIP number. Brown responds by acknowledging that his initial encoding was incorrect and suggests further extending the derivation path based on the coin type value. He believes a separate spec can be created to support different address formats without requiring new BIPs. The proposal includes several links to other related Bitcoin Improvement Proposals and discussions on addressing collisions and separating cosigners in the derivation path. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_Numerifides-Proposal-for-Decentralized-trust-authority-on-Bitcoin-blockchain.xml b/static/bitcoin-dev/April_2018/combined_Numerifides-Proposal-for-Decentralized-trust-authority-on-Bitcoin-blockchain.xml index a1231ae1e4..bc047347c4 100644 --- a/static/bitcoin-dev/April_2018/combined_Numerifides-Proposal-for-Decentralized-trust-authority-on-Bitcoin-blockchain.xml +++ b/static/bitcoin-dev/April_2018/combined_Numerifides-Proposal-for-Decentralized-trust-authority-on-Bitcoin-blockchain.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Numerifides - Proposal for Decentralized trust/authority on Bitcoin blockchain - 2023-08-01T22:53:27.856017+00:00 - - Tyler H 2018-04-25 06:58:45+00:00 - - - Tyler H 2018-04-21 12:35:28+00:00 - + 2025-09-26T16:06:22.072670+00:00 + python-feedgen + + + [bitcoin-dev] Numerifides - Proposal for Decentralized trust/authority on Bitcoin blockchain Tyler H + 2018-04-21T12:35:00.000Z + + + Tyler H + 2018-04-25T06:58:00.000Z + + - python-feedgen + 2 Combined summary - Numerifides - Proposal for Decentralized trust/authority on Bitcoin blockchain - 2023-08-01T22:53:27.856017+00:00 + 2025-09-26T16:06:22.073137+00:00 - Tyler Hawkins has proposed a new method called Numerifides, which aims to enable the registration of human-readable names and arbitrary data on the Bitcoin network. This innovative approach involves creating a new transaction type known as "numerifides" transactions, where Bitcoin is locked up for a specific period to discourage name squatting. Furthermore, these transactions include a puzzle that allows for the revocation of highly contested names or "squatted" mappings through community consensus. To ensure censorship resistance and the inclusion of high-fee transactions, Numerifides adopts the Replace-By-Fee (RBF) mechanism. This means that if a name is contentious or miners wish to censor, an honest greedy miner can include the censored user's high-fee transaction. By incrementing a nonce in the registration data off-chain, the mining process prevents "namesquatting" commonly observed in Namecoin.In addition to the Bitcoin blockchain, Numerifides establishes a secondary network for gossipping name-to-data mappings. This network is rooted from the numerifide transactions and facilitates the exchange of information. Through this approach, Numerifides successfully addresses Zooko's triangle by providing secure, decentralized, and human meaningful solutions.Tyler Hawkins encourages feedback and potential enhancements for Numerifides, and interested individuals can access the full working spec on GitHub at https://github.com/tyzbit/numerifides. As a possible change, it is proposed that a P2WSH defining the mapping could be gossiped about outside of the Bitcoin network, incentivizing the inclusion of such data in blocks. 2018-04-25T06:58:45+00:00 + Tyler Hawkins has proposed a new method called Numerifides, which aims to enable the registration of human-readable names and arbitrary data on the Bitcoin network. This innovative approach involves creating a new transaction type known as "numerifides" transactions, where Bitcoin is locked up for a specific period to discourage name squatting. Furthermore, these transactions include a puzzle that allows for the revocation of highly contested names or "squatted" mappings through community consensus. To ensure censorship resistance and the inclusion of high-fee transactions, Numerifides adopts the Replace-By-Fee (RBF) mechanism. This means that if a name is contentious or miners wish to censor, an honest greedy miner can include the censored user's high-fee transaction. By incrementing a nonce in the registration data off-chain, the mining process prevents "namesquatting" commonly observed in Namecoin.In addition to the Bitcoin blockchain, Numerifides establishes a secondary network for gossipping name-to-data mappings. This network is rooted from the numerifide transactions and facilitates the exchange of information. Through this approach, Numerifides successfully addresses Zooko's triangle by providing secure, decentralized, and human meaningful solutions.Tyler Hawkins encourages feedback and potential enhancements for Numerifides, and interested individuals can access the full working spec on GitHub at https://github.com/tyzbit/numerifides. As a possible change, it is proposed that a P2WSH defining the mapping could be gossiped about outside of the Bitcoin network, incentivizing the inclusion of such data in blocks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_Optimized-Header-Sync.xml b/static/bitcoin-dev/April_2018/combined_Optimized-Header-Sync.xml index 7041f54313..eb26edeceb 100644 --- a/static/bitcoin-dev/April_2018/combined_Optimized-Header-Sync.xml +++ b/static/bitcoin-dev/April_2018/combined_Optimized-Header-Sync.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Optimized Header Sync - 2023-08-01T22:50:48.395157+00:00 - - Jim Posen 2018-04-03 05:34:39+00:00 - - - Riccardo Casatta 2018-03-30 08:06:24+00:00 - - - Anthony Towns 2018-03-30 06:14:18+00:00 - - - Jim Posen 2018-03-30 00:50:30+00:00 - - - Riccardo Casatta 2018-03-29 08:17:12+00:00 - - - Jim Posen 2018-03-27 23:31:58+00:00 - + 2025-09-26T16:06:15.799131+00:00 + python-feedgen + + + [bitcoin-dev] Optimized Header Sync Jim Posen + 2018-03-27T23:31:00.000Z + + + Riccardo Casatta + 2018-03-29T08:17:00.000Z + + + Jim Posen + 2018-03-30T00:50:00.000Z + + + Anthony Towns + 2018-03-30T06:14:00.000Z + + + Riccardo Casatta + 2018-03-30T08:06:00.000Z + + + Jim Posen + 2018-04-03T05:34:00.000Z + + - python-feedgen + 2 Combined summary - Optimized Header Sync - 2023-08-01T22:50:48.395157+00:00 + 2025-09-26T16:06:15.799979+00:00 - In a recent bitcoin-dev discussion, the topic of handling checkpoints and compressed header streams was brought up. It was suggested that these items should be handled in chunks of 2016 headers and queried by chunk number instead of height. This method is cache-friendly and avoids using bit 0 and bit 1 in the bitfield.Jim Posen expressed interest in treating checkpoints as commitments to chain work. Another user suggested setting checkpoints every 2016 blocks and including the corresponding bits value for that set of blocks. This would allow each node to commit to approximately how much work their entire chain has by sending around 10KB of data. The deltas in each node's chain's target could then be verified by downloading the 2016 headers between those checkpoints and checking the timestamps and proof of work match both the old target and the new target from adjacent checkpoints.A new P2P network extension has been proposed to improve the syncing of block headers in Bitcoin clients. Optimized clients fetch all block headers before fetching all blocks themselves. The current protocol for fetching headers can be optimized further by compressing header data and downloading more headers simultaneously. The proposed messages enable sync strategies that are resilient against types of attacks. The NODE_HEADERS_V2 service bit is used to list block hashes at specified intervals. The proposed header download protocol reduces bandwidth usage by ~40%-50% and supports downloading headers ranges from multiple peers in parallel, which is not possible with the current mechanism. This also enables sync strategies with better resistance to denial-of-service attacks.Sync strategies include forward sequential syncing, parallel header download, and random sampling proof-of-work. The rationale behind including the coinbase transaction in the headers messages is due to its cryptographic commitments to a block's height. A simpler approach could be to encode the headers in groups of 2016 headers. The P2P messages are designed to be flexible, supporting multiple header sync strategies and leaving room for future innovations. A checkpoint is defined for a block as a tuple of its hash and the chain work. The proposed messages enable sync strategies that are resilient against types of attacks. The checkpts response includes a start height, end height, start checkpoint, end checkpoint, interval, checkpoints length, and checkpoints.The full BIP specification can be found at https://github.com/jimpo/bips/blob/headers-sync/headersv2.mediawiki. Credit is given to Gregory Maxwell, Suhas Daftuar, and Pieter Wuille for their contributions. The proposed protocol is backwards compatible and has no changes to consensus rules.Overall, the proposed P2P network extension aims to improve the syncing of block headers in Bitcoin clients by introducing compressed header data and efficient syncing strategies. This extension reduces bandwidth usage and supports parallel header downloads, making the synchronization process faster and more resistant to attacks. By treating checkpoints as commitments to chain work, nodes can estimate the amount of work in their chains and verify it using the 2016 headers between checkpoints. The proposed protocol is designed to be flexible and leaves room for future innovations, while also being compatible with existing implementations and consensus rules. 2018-04-03T05:34:39+00:00 + In a recent bitcoin-dev discussion, the topic of handling checkpoints and compressed header streams was brought up. It was suggested that these items should be handled in chunks of 2016 headers and queried by chunk number instead of height. This method is cache-friendly and avoids using bit 0 and bit 1 in the bitfield.Jim Posen expressed interest in treating checkpoints as commitments to chain work. Another user suggested setting checkpoints every 2016 blocks and including the corresponding bits value for that set of blocks. This would allow each node to commit to approximately how much work their entire chain has by sending around 10KB of data. The deltas in each node's chain's target could then be verified by downloading the 2016 headers between those checkpoints and checking the timestamps and proof of work match both the old target and the new target from adjacent checkpoints.A new P2P network extension has been proposed to improve the syncing of block headers in Bitcoin clients. Optimized clients fetch all block headers before fetching all blocks themselves. The current protocol for fetching headers can be optimized further by compressing header data and downloading more headers simultaneously. The proposed messages enable sync strategies that are resilient against types of attacks. The NODE_HEADERS_V2 service bit is used to list block hashes at specified intervals. The proposed header download protocol reduces bandwidth usage by ~40%-50% and supports downloading headers ranges from multiple peers in parallel, which is not possible with the current mechanism. This also enables sync strategies with better resistance to denial-of-service attacks.Sync strategies include forward sequential syncing, parallel header download, and random sampling proof-of-work. The rationale behind including the coinbase transaction in the headers messages is due to its cryptographic commitments to a block's height. A simpler approach could be to encode the headers in groups of 2016 headers. The P2P messages are designed to be flexible, supporting multiple header sync strategies and leaving room for future innovations. A checkpoint is defined for a block as a tuple of its hash and the chain work. The proposed messages enable sync strategies that are resilient against types of attacks. The checkpts response includes a start height, end height, start checkpoint, end checkpoint, interval, checkpoints length, and checkpoints.The full BIP specification can be found at https://github.com/jimpo/bips/blob/headers-sync/headersv2.mediawiki. Credit is given to Gregory Maxwell, Suhas Daftuar, and Pieter Wuille for their contributions. The proposed protocol is backwards compatible and has no changes to consensus rules.Overall, the proposed P2P network extension aims to improve the syncing of block headers in Bitcoin clients by introducing compressed header data and efficient syncing strategies. This extension reduces bandwidth usage and supports parallel header downloads, making the synchronization process faster and more resistant to attacks. By treating checkpoints as commitments to chain work, nodes can estimate the amount of work in their chains and verify it using the 2016 headers between checkpoints. The proposed protocol is designed to be flexible and leaves room for future innovations, while also being compatible with existing implementations and consensus rules. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_Signature-bundles.xml b/static/bitcoin-dev/April_2018/combined_Signature-bundles.xml index dda9822fff..b0fb7493cf 100644 --- a/static/bitcoin-dev/April_2018/combined_Signature-bundles.xml +++ b/static/bitcoin-dev/April_2018/combined_Signature-bundles.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Signature bundles - 2023-08-01T22:51:54.298404+00:00 - - Jim Posen 2018-04-04 23:11:52+00:00 - - - Rusty Russell 2018-04-03 05:31:24+00:00 - - - Anthony Towns 2018-04-03 03:57:23+00:00 - - - Rusty Russell 2018-04-02 23:46:45+00:00 - + 2025-09-26T16:06:24.160526+00:00 + python-feedgen + + + [bitcoin-dev] Signature bundles Rusty Russell + 2018-04-02T23:46:00.000Z + + + Anthony Towns + 2018-04-03T03:57:00.000Z + + + Rusty Russell + 2018-04-03T05:31:00.000Z + + + Jim Posen + 2018-04-04T23:11:00.000Z + + - python-feedgen + 2 Combined summary - Signature bundles - 2023-08-01T22:51:54.298404+00:00 + 2025-09-26T16:06:24.161156+00:00 - In the bitcoin-dev mailing list, a discussion took place regarding the potential problems of combining transactions with varying fee amounts. The issue arises when one bundle overpays and another underpays, as they can only be safely combined if a SIGHASH_ALL signature is included in the overpaying bundle. Otherwise, miners could create their own transaction using only the overpaying bundle. One solution suggested was to commit to a set of keys that are allowed to bundle, but this would limit the generality of outsourcing.Another problem discussed was the difficulty of guessing future fees for commitment transactions in lightning. Pre-signing HTLC-Success/HTLC-Timeout transactions by channel partners is necessary to ensure the correct output address. However, if the commitment transaction gets bundled, its txid will change, making pre-signing impossible without SIGHASH_NOINPUT. To solve this, a proposal was made to add a zero-value anyone-can-spend output to commitment transactions that can be used with CPFP (Child Pays For Parent) to bump the fees. However, this would lead to UTXO bloat and may not pass the dust threshold.A potential solution suggested was to have after-the-fact fee-bumping via special sighash flags at the block level. This involves providing a third transaction whose witness includes the txids and a signature committing to them. This transaction can only be included in a block if the referenced transactions (X and Y) are also in the same block. However, it raises the question of what the new transaction would spend since an existing output cannot be used. It was suggested that an unspendable zero-amount output script, such as 'OP_NOP4', could be used instead.Anthony Towns raised concerns about combining bundles with different fees and proposed using a SIGHASH_ALL sig in the overpaying bundle to prevent miners from creating their own transactions. He also suggested replacing SINGLE|ANYONECANPAY with additional witness bytes. In response, the discussion revolved around guessing future fees for commitment transactions and using parent-pays-for-child. However, due to timelocked outputs, this approach cannot work with HTLC-Success/HTLC-Timeout transactions as they spend outputs from the commitment transaction and need to be pre-signed. The proposed solutions included adding a zero-value anyone-can-spend output to commitment transactions for CPFP or after-the-fact fee-bumping via special sighash flags at the block level.The bitcoin-dev community proposed a new way to bundle transactions in order to address the issue of guessing future fees for commitment transactions. This proposal involves indicating that a signature only applies to part of a transaction, or a "bundle". Bundles can be combined into larger transactions and non-bundled signature inputs/outputs can be appended. The proposed bundling method includes SIGHASH_BUNDLESTART and SIGHASH_INBUNDLE flags, which indicate the number of inputs and outputs in a bundle and that a signature applies to the current bundle. Additionally, two per-tx counters track the number of inputs and outputs used in each bundle. This bundling method could replace SINGLE|ANYONECANPAY but requires an extra couple of witness bytes. BIP-69 style ordering rules can also be established within a bundle. While the bundling does not offer privacy benefits, it allows for dealing with discrepancies in fees.A suggested solution for pre-signing HTLC-Success/HTLC-Timeout transactions, which require the correct output address, is to add a zero-value anyone-can-spend output to commitment transactions. Another idea is after-the-fact fee-bumping via special sighash flags at the block level. However, implementing this is not straightforward. Rusty proposed a more flexible alternative to SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, including SIGHASH_BUNDLESTART and SIGHASH_INBUNDLE bits. This proposed signature indicates that it only signs part of a transaction's inputs and outputs, allowing for the combination of multiple bundles into larger transactions. Two counters track the inputs and outputs used in each bundle. This approach could be useful for guessing future fees and allows public aggregators to provide throughput promises and add additional fees. Feedback on this proposal is welcome. 2018-04-04T23:11:52+00:00 + In the bitcoin-dev mailing list, a discussion took place regarding the potential problems of combining transactions with varying fee amounts. The issue arises when one bundle overpays and another underpays, as they can only be safely combined if a SIGHASH_ALL signature is included in the overpaying bundle. Otherwise, miners could create their own transaction using only the overpaying bundle. One solution suggested was to commit to a set of keys that are allowed to bundle, but this would limit the generality of outsourcing.Another problem discussed was the difficulty of guessing future fees for commitment transactions in lightning. Pre-signing HTLC-Success/HTLC-Timeout transactions by channel partners is necessary to ensure the correct output address. However, if the commitment transaction gets bundled, its txid will change, making pre-signing impossible without SIGHASH_NOINPUT. To solve this, a proposal was made to add a zero-value anyone-can-spend output to commitment transactions that can be used with CPFP (Child Pays For Parent) to bump the fees. However, this would lead to UTXO bloat and may not pass the dust threshold.A potential solution suggested was to have after-the-fact fee-bumping via special sighash flags at the block level. This involves providing a third transaction whose witness includes the txids and a signature committing to them. This transaction can only be included in a block if the referenced transactions (X and Y) are also in the same block. However, it raises the question of what the new transaction would spend since an existing output cannot be used. It was suggested that an unspendable zero-amount output script, such as 'OP_NOP4', could be used instead.Anthony Towns raised concerns about combining bundles with different fees and proposed using a SIGHASH_ALL sig in the overpaying bundle to prevent miners from creating their own transactions. He also suggested replacing SINGLE|ANYONECANPAY with additional witness bytes. In response, the discussion revolved around guessing future fees for commitment transactions and using parent-pays-for-child. However, due to timelocked outputs, this approach cannot work with HTLC-Success/HTLC-Timeout transactions as they spend outputs from the commitment transaction and need to be pre-signed. The proposed solutions included adding a zero-value anyone-can-spend output to commitment transactions for CPFP or after-the-fact fee-bumping via special sighash flags at the block level.The bitcoin-dev community proposed a new way to bundle transactions in order to address the issue of guessing future fees for commitment transactions. This proposal involves indicating that a signature only applies to part of a transaction, or a "bundle". Bundles can be combined into larger transactions and non-bundled signature inputs/outputs can be appended. The proposed bundling method includes SIGHASH_BUNDLESTART and SIGHASH_INBUNDLE flags, which indicate the number of inputs and outputs in a bundle and that a signature applies to the current bundle. Additionally, two per-tx counters track the number of inputs and outputs used in each bundle. This bundling method could replace SINGLE|ANYONECANPAY but requires an extra couple of witness bytes. BIP-69 style ordering rules can also be established within a bundle. While the bundling does not offer privacy benefits, it allows for dealing with discrepancies in fees.A suggested solution for pre-signing HTLC-Success/HTLC-Timeout transactions, which require the correct output address, is to add a zero-value anyone-can-spend output to commitment transactions. Another idea is after-the-fact fee-bumping via special sighash flags at the block level. However, implementing this is not straightforward. Rusty proposed a more flexible alternative to SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, including SIGHASH_BUNDLESTART and SIGHASH_INBUNDLE bits. This proposed signature indicates that it only signs part of a transaction's inputs and outputs, allowing for the combination of multiple bundles into larger transactions. Two counters track the inputs and outputs used in each bundle. This approach could be useful for guessing future fees and allows public aggregators to provide throughput promises and add additional fees. Feedback on this proposal is welcome. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml b/static/bitcoin-dev/April_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml index 0a88ff0d7d..73afe136bf 100644 --- a/static/bitcoin-dev/April_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml +++ b/static/bitcoin-dev/April_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts - 2023-08-01T22:54:50.676286+00:00 - - Rusty Russell 2018-06-22 00:32:01+00:00 - - - Christian Decker 2018-05-10 13:57:30+00:00 - - - Olaoluwa Osuntokun 2018-05-07 23:26:05+00:00 - - - Jim Posen 2018-05-02 01:15:10+00:00 - - - Christian Decker 2018-05-01 17:31:28+00:00 - - - Jim Posen 2018-05-01 17:07:22+00:00 - - - Christian Decker 2018-05-01 16:29:09+00:00 - - - Jim Posen 2018-05-01 15:50:27+00:00 - - - Christian Decker 2018-05-01 11:38:12+00:00 - - - Christian Decker 2018-05-01 11:36:32+00:00 - - - ZmnSCPxj 2018-05-01 05:07:54+00:00 - - - ZmnSCPxj 2018-05-01 05:01:52+00:00 - - - Jim Posen 2018-04-30 23:00:55+00:00 - - - Christian Decker 2018-04-30 15:41:38+00:00 - + 2025-09-26T16:06:13.677865+00:00 + python-feedgen + + + [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts Christian Decker + 2018-04-30T15:41:00.000Z + + + Jim Posen + 2018-04-30T23:00:00.000Z + + + ZmnSCPxj + 2018-05-01T05:01:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2018-05-01T05:07:00.000Z + + + Christian Decker + 2018-05-01T11:36:00.000Z + + + Christian Decker + 2018-05-01T11:38:00.000Z + + + Jim Posen + 2018-05-01T15:50:00.000Z + + + Christian Decker + 2018-05-01T16:29:00.000Z + + + Jim Posen + 2018-05-01T17:07:00.000Z + + + Christian Decker + 2018-05-01T17:31:00.000Z + + + Jim Posen + 2018-05-02T01:15:00.000Z + + + Olaoluwa Osuntokun + 2018-05-07T23:26:00.000Z + + + Christian Decker + 2018-05-10T13:57:00.000Z + + + Rusty Russell + 2018-06-22T00:32:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts - 2023-08-01T22:54:50.676286+00:00 + 2025-09-26T16:06:13.679411+00:00 - The discussions surrounding the Lightning Network cover several topics. One of the concerns is the potential for attacks and the need for mitigations. Another topic is the impact of symmetric state and eltoo on HTLC (Hashed Timelock Contract) timeouts. The accumulation of timeout delays is also discussed, along with the use of a fixed offset versus an increased delta at each hop in the network. Additionally, there are concerns raised about the terminology used in a research paper, specifically regarding the terms "input script" and "output script." These conversations contribute to the ongoing development and improvement of the Lightning Network protocol.The Lightning Network implementation teams have introduced a new update mechanism called eltoo. This mechanism addresses some of the challenges faced in specifying and implementing the Lightning Network, and it can be used as a generic update mechanism for off-chain contracts with multiple participants. However, before implementing eltoo, a minor change to Bitcoin is required: the introduction of the SIGHASH_NOINPUT flag for signatures.Currently, the penalty-based invalidation mechanism used in the Lightning specification results in lost funds when an old state is published. Eltoo, on the other hand, is not penalty-based, meaning that publishing an old state does not result in lost funds. Instead, it operates similarly to the duplex micropayment channel construction, where all participants share an identical set of transactions. Eltoo ensures that the last agreed-upon state is settled on-chain, with tradeoffs similar to the current Lightning Network.One advantage of eltoo is its ability to attach fees when settling and even bump fees using CPFP (Child-Pays-For-Parent) or RBF (Replace-By-Fee). It also simplifies outsourcing since old states becoming public no longer pose a threat. Furthermore, eltoo eliminates the need to estimate fees ahead of time and can be utilized for other protocols such as channel factories. When combined with Schnorr signatures, eltoo facilitates the creation of large off-chain contracts with minimal on-chain footprint.However, implementing eltoo would require an increase in the safe CLTV (CheckLockTimeVerify) delta requirements. Currently, HTLCs can be timed out immediately on the settlement transaction. With eltoo, when a downstream channel is closed on-chain, it must wait for the CSV (CheckSequenceVerify) timeout on the update transaction before locking in the timed-out HTLC. This means that the CLTV delta needs to be greater than the CSV timeout, plus some extra time. However, it is believed that the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.Overall, eltoo presents a promising update mechanism for off-chain protocols like the Lightning Network. It offers improvements in terms of simplicity, flexibility in fee management, and potential use in various applications beyond Lightning. More details about the eltoo proposal can be found in the paper linked at [2]. 2018-06-22T00:32:01+00:00 + The discussions surrounding the Lightning Network cover several topics. One of the concerns is the potential for attacks and the need for mitigations. Another topic is the impact of symmetric state and eltoo on HTLC (Hashed Timelock Contract) timeouts. The accumulation of timeout delays is also discussed, along with the use of a fixed offset versus an increased delta at each hop in the network. Additionally, there are concerns raised about the terminology used in a research paper, specifically regarding the terms "input script" and "output script." These conversations contribute to the ongoing development and improvement of the Lightning Network protocol.The Lightning Network implementation teams have introduced a new update mechanism called eltoo. This mechanism addresses some of the challenges faced in specifying and implementing the Lightning Network, and it can be used as a generic update mechanism for off-chain contracts with multiple participants. However, before implementing eltoo, a minor change to Bitcoin is required: the introduction of the SIGHASH_NOINPUT flag for signatures.Currently, the penalty-based invalidation mechanism used in the Lightning specification results in lost funds when an old state is published. Eltoo, on the other hand, is not penalty-based, meaning that publishing an old state does not result in lost funds. Instead, it operates similarly to the duplex micropayment channel construction, where all participants share an identical set of transactions. Eltoo ensures that the last agreed-upon state is settled on-chain, with tradeoffs similar to the current Lightning Network.One advantage of eltoo is its ability to attach fees when settling and even bump fees using CPFP (Child-Pays-For-Parent) or RBF (Replace-By-Fee). It also simplifies outsourcing since old states becoming public no longer pose a threat. Furthermore, eltoo eliminates the need to estimate fees ahead of time and can be utilized for other protocols such as channel factories. When combined with Schnorr signatures, eltoo facilitates the creation of large off-chain contracts with minimal on-chain footprint.However, implementing eltoo would require an increase in the safe CLTV (CheckLockTimeVerify) delta requirements. Currently, HTLCs can be timed out immediately on the settlement transaction. With eltoo, when a downstream channel is closed on-chain, it must wait for the CSV (CheckSequenceVerify) timeout on the update transaction before locking in the timed-out HTLC. This means that the CLTV delta needs to be greater than the CSV timeout, plus some extra time. However, it is believed that the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.Overall, eltoo presents a promising update mechanism for off-chain protocols like the Lightning Network. It offers improvements in terms of simplicity, flexibility in fee management, and potential use in various applications beyond Lightning. More details about the eltoo proposal can be found in the paper linked at [2]. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_feature-Enhance-privacy-by-change-obfuscation.xml b/static/bitcoin-dev/April_2018/combined_feature-Enhance-privacy-by-change-obfuscation.xml index 82a30b0b5e..b1dd0b3bc3 100644 --- a/static/bitcoin-dev/April_2018/combined_feature-Enhance-privacy-by-change-obfuscation.xml +++ b/static/bitcoin-dev/April_2018/combined_feature-Enhance-privacy-by-change-obfuscation.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - feature: Enhance privacy by change obfuscation - 2023-08-01T22:49:09.755739+00:00 - - Damian Williamson 2018-04-01 14:37:13+00:00 - - - Eric Voskuil 2018-03-18 18:59:28+00:00 - - - Damian Williamson 2018-03-18 07:07:58+00:00 - - - Evan Klitzke 2018-03-18 05:50:34+00:00 - - - Damian Williamson 2018-03-18 01:34:20+00:00 - + 2025-09-26T16:06:09.435804+00:00 + python-feedgen + + + [bitcoin-dev] feature: Enhance privacy by change obfuscation Damian Williamson + 2018-03-18T01:34:00.000Z + + + Evan Klitzke + 2018-03-18T05:50:00.000Z + + + Damian Williamson + 2018-03-18T07:07:00.000Z + + + Eric Voskuil + 2018-03-18T18:59:00.000Z + + + Damian Williamson + 2018-04-01T14:37:00.000Z + + - python-feedgen + 2 Combined summary - feature: Enhance privacy by change obfuscation - 2023-08-01T22:49:09.756739+00:00 + 2025-09-26T16:06:09.436551+00:00 - Electrum version 3.0.6 now offers a new option for multiple change addresses, although it is not enabled by default. Eric Voskuil responded to a proposal regarding privacy enhancement through change obfuscation by clarifying a misconception about the cost of unspent outputs. He explained that the perceived increase in cost is not necessary and arises from specific node software implementations.There is a common belief that the count of unspent outputs in a network leads to higher costs due to the bloat in UTXO size. However, this belief is inaccurate, as the additional cost is not required but rather a result of implementation details in certain node software. Redundant indexing of unspent outputs is unnecessary, meaning not everyone has to bear the cost.In a Bitcoin-dev thread, Damian Williamson proposed a feature called change obfuscation to enhance transaction privacy. The idea was to randomly distribute change across up to twenty output addresses, ensuring each output is not dust. However, Evan Klitzke pointed out that this approach would be costly for the network due to the increased UTXO size. Moreover, it may not provide the desired level of privacy, since the wallet would need to combine those inputs in future transactions, resulting in higher transaction fees. Despite understanding the additional cost, Klitzke did not support the suggestion.In response to Williamson's proposal, an "Enhanced privacy" option was introduced in Bitcoin Core for transaction creation. This feature allows users to distribute change randomly across up to twenty output addresses (with a minimum of five), as long as each output is not dust. It is recommended to limit the total number of random addresses based on the change amount. If additional inputs are available, they can be selected to increase the change, although this may reduce obfuscation when the outputs are spent. However, the initial spend with change will have a higher transaction cost due to increased outputs, and subsequent spending of the change will depend on the future spend amount(s) and the number of inputs required.Although there is still a possibility of transaction linkage, guessing what was retained by the owner of the original utxo's becomes more challenging unless the new change outputs are spent together in the same transaction. Ultimately, the "Enhanced privacy" option significantly improves privacy for Bitcoin Core users. 2018-04-01T14:37:13+00:00 + Electrum version 3.0.6 now offers a new option for multiple change addresses, although it is not enabled by default. Eric Voskuil responded to a proposal regarding privacy enhancement through change obfuscation by clarifying a misconception about the cost of unspent outputs. He explained that the perceived increase in cost is not necessary and arises from specific node software implementations.There is a common belief that the count of unspent outputs in a network leads to higher costs due to the bloat in UTXO size. However, this belief is inaccurate, as the additional cost is not required but rather a result of implementation details in certain node software. Redundant indexing of unspent outputs is unnecessary, meaning not everyone has to bear the cost.In a Bitcoin-dev thread, Damian Williamson proposed a feature called change obfuscation to enhance transaction privacy. The idea was to randomly distribute change across up to twenty output addresses, ensuring each output is not dust. However, Evan Klitzke pointed out that this approach would be costly for the network due to the increased UTXO size. Moreover, it may not provide the desired level of privacy, since the wallet would need to combine those inputs in future transactions, resulting in higher transaction fees. Despite understanding the additional cost, Klitzke did not support the suggestion.In response to Williamson's proposal, an "Enhanced privacy" option was introduced in Bitcoin Core for transaction creation. This feature allows users to distribute change randomly across up to twenty output addresses (with a minimum of five), as long as each output is not dust. It is recommended to limit the total number of random addresses based on the change amount. If additional inputs are available, they can be selected to increase the change, although this may reduce obfuscation when the outputs are spent. However, the initial spend with change will have a higher transaction cost due to increased outputs, and subsequent spending of the change will depend on the future spend amount(s) and the number of inputs required.Although there is still a possibility of transaction linkage, guessing what was retained by the owner of the original utxo's becomes more challenging unless the new change outputs are spent together in the same transaction. Ultimately, the "Enhanced privacy" option significantly improves privacy for Bitcoin Core users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2018/combined_proposal-extend-WIF-format-for-segwit.xml b/static/bitcoin-dev/April_2018/combined_proposal-extend-WIF-format-for-segwit.xml index 6131599cac..4f90815829 100644 --- a/static/bitcoin-dev/April_2018/combined_proposal-extend-WIF-format-for-segwit.xml +++ b/static/bitcoin-dev/April_2018/combined_proposal-extend-WIF-format-for-segwit.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - proposal: extend WIF format for segwit - 2023-08-01T21:53:22.351002+00:00 - - Karl-Johan Alm 2018-04-10 02:54:08+00:00 - - - Karl Johan Alm 2018-04-04 06:06:19+00:00 - - - Mark Friedenbach 2017-09-17 15:36:48+00:00 - - - AJ West 2017-09-17 14:42:52+00:00 - - - Thomas Voegtlin 2017-09-17 08:10:17+00:00 - - - Pieter Wuille 2017-09-17 02:29:41+00:00 - - - Thomas Voegtlin 2017-09-15 08:55:37+00:00 - + 2025-09-26T16:06:05.256685+00:00 + python-feedgen + + + [bitcoin-dev] proposal: extend WIF format for segwit Thomas Voegtlin + 2017-09-15T08:55:00.000Z + + + Pieter Wuille + 2017-09-17T02:29:00.000Z + + + Thomas Voegtlin + 2017-09-17T08:10:00.000Z + + + AJ West + 2017-09-17T14:42:00.000Z + + + Mark Friedenbach + 2017-09-17T15:36:00.000Z + + + Karl Johan Alm + 2018-04-04T06:06:00.000Z + + + Karl-Johan Alm + 2018-04-10T02:54:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - proposal: extend WIF format for segwit - 2023-08-01T21:53:22.351002+00:00 + 2025-09-26T16:06:05.257592+00:00 - The proposed Bitcoin Improvement Proposal (BIP XXX) aims to extend the private key format in order to specify the type of public key it corresponds to. Currently, when importing a private key, the wallet has to assume all possible types of public keys, resulting in the need to track each alternative. The proposal suggests adding new values to the table to indicate the type of public key associated with the private key, such as P2PKH, P2WPKH, and P2SH. This extension would allow wallets to track only the specific corresponding public key when importing a private key.The motivation behind this proposal is the presence of various types of public keys that can be associated with a given private key, such as legacy formats and SegWit formats. The existing private key format lacks the ability to specify which type of public key was used, leading to ambiguity and the need for wallets to try all possible scripts. The proposed extension seeks to address this issue by providing a clear indication of the type of public key associated with a private key.The compatibility of the Bech32 and Wallet Import Format (WIF) payload format is discussed in the Bitcoin-dev mailing list. The ambiguity of the current WIF format is causing obstacles for the release of a SegWit-capable version of Electrum. Two options are presented: either disable private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or define a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Other wallet developers are asked about their plans for exporting private keys used in SegWit scripts in the current WIF format.In the discussion, user AJ West raises concerns about whether wallet software should attempt to error-correct private keys. Thomas Voegtlin, the developer of Electrum, responds to Pieter Wuille's comment on checksum computation for the Bech32 format, stating that the ambiguity in the WIF format is holding him back from releasing a SegWit-capable version of Electrum. Voegtlin believes it is unacceptable to use the current WIF format with SegWit scripts and suggests either disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon or defining his own WIF extension for Electrum. He seeks input from other wallet developers, particularly Core.Pieter Wuille, a Bitcoin Core developer, expresses concerns about the ambiguity of the Wallet Import Format (WIF) when used with Segregated Witness (SegWit) scripts. He argues that the current WIF format is not suitable for use with SegWit scripts and could create technological debt by requiring wallets to try all possible scripts. He suggests two options: disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or defining a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Wuille seeks information on the plans of other wallet developers, especially Core.Thomas Voegtlin proposes using a bech32 format for private keys if they are to be used with a bech32 address. However, he is unsure if such a format has already been proposed. Meanwhile, Pieter has been working on an "extended bech32" format with a stronger checksum protection compared to the normal bech32 format. This extended format is particularly useful for private keys since there is no option to ask the receiver for a corrected version. Although this task is low priority, significant computation work is required to find a good checksum.The Wallet Import Format (WIF) is a representation of private keys for Bitcoin. The current WIF format appends a 0x01 byte after the raw private key when used with a compressed public key, allowing wallets to associate a single Bitcoin address with a WIF key. However, extending the semantics of that byte to signal segwit scripts would be useful, as these scripts result in different addresses. Proposals suggest adding new bytes to WIF for segwit script embedded in P2SH and native segwit script. It is not necessary to use distinct bytes for certain types as the P2SH script is not known anyway. Additionally, a bech32 format can be used for private keys intended for use with a bech32 address. It is important to note that this proposal will not result in a visible change at the beginning of the string, similar to the compressed/uncompressed indicator. However, improvements to this aspect may be made in the future. These proposed changes to WIF are similar to the {x,y,z}{pub,prv} proposal for bip32 extended keys.In conclusion, the proposed BIP aims to extend the private 2018-04-10T02:54:08+00:00 + The proposed Bitcoin Improvement Proposal (BIP XXX) aims to extend the private key format in order to specify the type of public key it corresponds to. Currently, when importing a private key, the wallet has to assume all possible types of public keys, resulting in the need to track each alternative. The proposal suggests adding new values to the table to indicate the type of public key associated with the private key, such as P2PKH, P2WPKH, and P2SH. This extension would allow wallets to track only the specific corresponding public key when importing a private key.The motivation behind this proposal is the presence of various types of public keys that can be associated with a given private key, such as legacy formats and SegWit formats. The existing private key format lacks the ability to specify which type of public key was used, leading to ambiguity and the need for wallets to try all possible scripts. The proposed extension seeks to address this issue by providing a clear indication of the type of public key associated with a private key.The compatibility of the Bech32 and Wallet Import Format (WIF) payload format is discussed in the Bitcoin-dev mailing list. The ambiguity of the current WIF format is causing obstacles for the release of a SegWit-capable version of Electrum. Two options are presented: either disable private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or define a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Other wallet developers are asked about their plans for exporting private keys used in SegWit scripts in the current WIF format.In the discussion, user AJ West raises concerns about whether wallet software should attempt to error-correct private keys. Thomas Voegtlin, the developer of Electrum, responds to Pieter Wuille's comment on checksum computation for the Bech32 format, stating that the ambiguity in the WIF format is holding him back from releasing a SegWit-capable version of Electrum. Voegtlin believes it is unacceptable to use the current WIF format with SegWit scripts and suggests either disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon or defining his own WIF extension for Electrum. He seeks input from other wallet developers, particularly Core.Pieter Wuille, a Bitcoin Core developer, expresses concerns about the ambiguity of the Wallet Import Format (WIF) when used with Segregated Witness (SegWit) scripts. He argues that the current WIF format is not suitable for use with SegWit scripts and could create technological debt by requiring wallets to try all possible scripts. He suggests two options: disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or defining a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Wuille seeks information on the plans of other wallet developers, especially Core.Thomas Voegtlin proposes using a bech32 format for private keys if they are to be used with a bech32 address. However, he is unsure if such a format has already been proposed. Meanwhile, Pieter has been working on an "extended bech32" format with a stronger checksum protection compared to the normal bech32 format. This extended format is particularly useful for private keys since there is no option to ask the receiver for a corrected version. Although this task is low priority, significant computation work is required to find a good checksum.The Wallet Import Format (WIF) is a representation of private keys for Bitcoin. The current WIF format appends a 0x01 byte after the raw private key when used with a compressed public key, allowing wallets to associate a single Bitcoin address with a WIF key. However, extending the semantics of that byte to signal segwit scripts would be useful, as these scripts result in different addresses. Proposals suggest adding new bytes to WIF for segwit script embedded in P2SH and native segwit script. It is not necessary to use distinct bytes for certain types as the P2SH script is not known anyway. Additionally, a bech32 format can be used for private keys intended for use with a bech32 address. It is important to note that this proposal will not result in a visible change at the beginning of the string, similar to the compressed/uncompressed indicator. However, improvements to this aspect may be made in the future. These proposed changes to WIF are similar to the {x,y,z}{pub,prv} proposal for bip32 extended keys.In conclusion, the proposed BIP aims to extend the private - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_Adding-xpub-field-to-PSBT-to-make-multisig-more-secure.xml b/static/bitcoin-dev/April_2019/combined_Adding-xpub-field-to-PSBT-to-make-multisig-more-secure.xml index 00307a4e42..a6a0e6be22 100644 --- a/static/bitcoin-dev/April_2019/combined_Adding-xpub-field-to-PSBT-to-make-multisig-more-secure.xml +++ b/static/bitcoin-dev/April_2019/combined_Adding-xpub-field-to-PSBT-to-make-multisig-more-secure.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Adding xpub field to PSBT to make multisig more secure - 2023-08-02T00:44:57.994125+00:00 - - Dmitry Petukhov 2019-05-09 17:08:47+00:00 - - - jan matejek 2019-05-08 07:54:53+00:00 - - - Dmitry Petukhov 2019-05-07 13:40:34+00:00 - - - Stepan Snigirev 2019-05-07 09:23:44+00:00 - - - Peter D. Gray 2019-05-03 13:29:45+00:00 - - - Andrew Chow 2019-05-01 16:57:38+00:00 - - - Stepan Snigirev 2019-04-26 15:21:06+00:00 - + 2025-09-26T15:44:27.373402+00:00 + python-feedgen + + + [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure Stepan Snigirev + 2019-04-26T15:21:00.000Z + + + Andrew Chow + 2019-05-01T16:57:00.000Z + + + Peter D. Gray + 2019-05-03T13:29:00.000Z + + + Stepan Snigirev + 2019-05-07T09:23:00.000Z + + + Dmitry Petukhov + 2019-05-07T13:40:00.000Z + + + jan matejek + 2019-05-08T07:54:00.000Z + + + Dmitry Petukhov + 2019-05-09T17:08:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Adding xpub field to PSBT to make multisig more secure - 2023-08-02T00:44:57.994125+00:00 + 2025-09-26T15:44:27.374236+00:00 - In a bitcoin-dev thread, the author proposes a solution to aggregate spending from different wallets into one transaction for efficiency and convenience. They suggest using stateful signers that store trusted xpubs to apply it to stateless hardware wallets. This would allow distinguishing trusted outputs even if the inputs are not derived from the same set of xpubs. However, this idea is seen as an attempt at a different and broader problem.Dmitry Petukhov suggests in the thread that a hardware wallet can sign a message consisting of xpubs of participants and auxiliary text during the setup phase. However, this method seems overly complicated and its purpose is unclear. The thread discusses the threat model and suggests that each individual multisig signature signs the set of signers. This ensures that if an attacker provides bad xpubs, the signature won't be valid for the given multisig output. The weak spot in the process is generating the receiving address, but this issue is unrelated to PSBT.To safely show an incoming address to the user, PSBT-signing devices still need to store the xpubs of their co-signers. However, hardware wallets need to be stateless for easy wiping and recovering. To solve this, the user can verify a multisignature address or xpub on the screens of all devices during the setup phase. Hardware wallets can then mark outputs that use the pubkeys derived from 'verified' xpubs as 'trusted' outputs. This allows distinguishing trusted outputs even if the inputs are not all derived from the same set of xpubs.The proposal suggests sharing xpubs in the global section of the file, with a restriction that they must only include the hardened prefix of the path. The existing bip32 derivation path included in individual inputs and outputs should be merged in as needed. However, it is not necessary to restrict xpubs to have only hardened derivation. PSBT-signing devices still need to store the xpubs of their co-signers for safe verification of incoming addresses. The proposal also suggests using the extension serialization format without any encodings for PSBT, and keeping the prefix that defines if the key is used for testnet or mainnet may also be useful.Stepan Snigirev raises concerns about the possibility of user funds being stolen in multisignature setups using the current specifications for PSBT. An attacker could replace half of the keys in the change address with their own keys and still get the transaction signed. To fix this issue, Snigirev suggests adding an xpub field to the inputs and outputs metadata so that signers can verify that the same xpubs are used for public keys in inputs and outputs. He proposes two new key-value pairs to be added to PSBT: `PSBT_IN_BIP32_XPUB` and `PSBT_OUT_BIP32_XPUB`. This would ensure that the output is indeed a change. Snigirev also suggests reviewing the communication protocols of existing hardware and multisignature wallets to see if there are other solutions to this issue. If the proposal is accepted, he plans to prepare a pull request to the bip. 2019-05-09T17:08:47+00:00 + In a bitcoin-dev thread, the author proposes a solution to aggregate spending from different wallets into one transaction for efficiency and convenience. They suggest using stateful signers that store trusted xpubs to apply it to stateless hardware wallets. This would allow distinguishing trusted outputs even if the inputs are not derived from the same set of xpubs. However, this idea is seen as an attempt at a different and broader problem.Dmitry Petukhov suggests in the thread that a hardware wallet can sign a message consisting of xpubs of participants and auxiliary text during the setup phase. However, this method seems overly complicated and its purpose is unclear. The thread discusses the threat model and suggests that each individual multisig signature signs the set of signers. This ensures that if an attacker provides bad xpubs, the signature won't be valid for the given multisig output. The weak spot in the process is generating the receiving address, but this issue is unrelated to PSBT.To safely show an incoming address to the user, PSBT-signing devices still need to store the xpubs of their co-signers. However, hardware wallets need to be stateless for easy wiping and recovering. To solve this, the user can verify a multisignature address or xpub on the screens of all devices during the setup phase. Hardware wallets can then mark outputs that use the pubkeys derived from 'verified' xpubs as 'trusted' outputs. This allows distinguishing trusted outputs even if the inputs are not all derived from the same set of xpubs.The proposal suggests sharing xpubs in the global section of the file, with a restriction that they must only include the hardened prefix of the path. The existing bip32 derivation path included in individual inputs and outputs should be merged in as needed. However, it is not necessary to restrict xpubs to have only hardened derivation. PSBT-signing devices still need to store the xpubs of their co-signers for safe verification of incoming addresses. The proposal also suggests using the extension serialization format without any encodings for PSBT, and keeping the prefix that defines if the key is used for testnet or mainnet may also be useful.Stepan Snigirev raises concerns about the possibility of user funds being stolen in multisignature setups using the current specifications for PSBT. An attacker could replace half of the keys in the change address with their own keys and still get the transaction signed. To fix this issue, Snigirev suggests adding an xpub field to the inputs and outputs metadata so that signers can verify that the same xpubs are used for public keys in inputs and outputs. He proposes two new key-value pairs to be added to PSBT: `PSBT_IN_BIP32_XPUB` and `PSBT_OUT_BIP32_XPUB`. This would ensure that the output is indeed a change. Snigirev also suggests reviewing the communication protocols of existing hardware and multisignature wallets to see if there are other solutions to this issue. If the proposal is accepted, he plans to prepare a pull request to the bip. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_BIP-Bitcoin-Integrated-Address-Feature-.xml b/static/bitcoin-dev/April_2019/combined_BIP-Bitcoin-Integrated-Address-Feature-.xml index cecd569c4c..ac44ea9887 100644 --- a/static/bitcoin-dev/April_2019/combined_BIP-Bitcoin-Integrated-Address-Feature-.xml +++ b/static/bitcoin-dev/April_2019/combined_BIP-Bitcoin-Integrated-Address-Feature-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP: Bitcoin Integrated Address Feature? - 2023-08-02T00:40:38.371585+00:00 - - Ricardo Filipe 2019-04-02 23:52:16+00:00 - - - htimSxelA 2019-04-02 20:01:34+00:00 - - - nathanw at tutanota.com 2019-04-02 16:53:11+00:00 - + 2025-09-26T15:44:25.287584+00:00 + python-feedgen + + + [bitcoin-dev] BIP: Bitcoin Integrated Address Feature? nathanw + 2019-04-02T16:53:00.000Z + + + htimSxelA + 2019-04-02T20:01:00.000Z + + + Ricardo Filipe + 2019-04-02T23:52:00.000Z + + - python-feedgen + 2 Combined summary - BIP: Bitcoin Integrated Address Feature? - 2023-08-02T00:40:38.371585+00:00 + 2025-09-26T15:44:25.288178+00:00 - Nathan Worsley, the CTO of LocalCoinSwap.com, has suggested a missing feature in Bitcoin that could enhance the security of exchange cold wallet systems. In a message posted to the bitcoin-dev mailing list, Worsley proposes an "integrated address" feature that would allow addresses to resolve into a Bitcoin address and a transaction message or identifier. This feature would enable exchange cold-wallet systems to receive payments from multiple customers to a single address without the need to move deposits from a hot address to a cold address.The proposed feature aims to simplify the setup and management of exchange cold-wallet systems by eliminating the "sweeping" step currently required to consolidate multiple customer deposits into a single cold address. By allowing customers to deposit directly into a singular cold wallet address, exchanges can switch to a more secure alternative than the hot-deposit system commonly used. This system carries the risk of sophisticated hackers capturing private keys to customer deposit addresses.Aside from enhancing security, the integrated address feature offers other advantages. Exchanges would benefit from lower fees and reduced need for large rescans after loading significant amounts of customer addresses into client software. Provisioning deposit addresses to new customers securely would also become easier, as well as verifying that customers have been provided with the correct address to deposit to.Worsley suggests that the integrated address could work by combining the Bitcoin address with a hex or other value. This combination would allow users to choose the amount they wish to deposit while ensuring their deposits can be uniquely tracked. However, Worsley is unsure if this functionality already exists in BTC and is considering submitting a proposal to implement this feature.It is important to note that while the integrated address feature presents several benefits, there are potential drawbacks. Increased resource requirements per transaction and the embedding of identifying information into the blockchain may compromise user privacy. Despite these considerations, Worsley believes that the integration of such a feature would greatly benefit exchange developers if widely accepted. 2019-04-02T23:52:16+00:00 + Nathan Worsley, the CTO of LocalCoinSwap.com, has suggested a missing feature in Bitcoin that could enhance the security of exchange cold wallet systems. In a message posted to the bitcoin-dev mailing list, Worsley proposes an "integrated address" feature that would allow addresses to resolve into a Bitcoin address and a transaction message or identifier. This feature would enable exchange cold-wallet systems to receive payments from multiple customers to a single address without the need to move deposits from a hot address to a cold address.The proposed feature aims to simplify the setup and management of exchange cold-wallet systems by eliminating the "sweeping" step currently required to consolidate multiple customer deposits into a single cold address. By allowing customers to deposit directly into a singular cold wallet address, exchanges can switch to a more secure alternative than the hot-deposit system commonly used. This system carries the risk of sophisticated hackers capturing private keys to customer deposit addresses.Aside from enhancing security, the integrated address feature offers other advantages. Exchanges would benefit from lower fees and reduced need for large rescans after loading significant amounts of customer addresses into client software. Provisioning deposit addresses to new customers securely would also become easier, as well as verifying that customers have been provided with the correct address to deposit to.Worsley suggests that the integrated address could work by combining the Bitcoin address with a hex or other value. This combination would allow users to choose the amount they wish to deposit while ensuring their deposits can be uniquely tracked. However, Worsley is unsure if this functionality already exists in BTC and is considering submitting a proposal to implement this feature.It is important to note that while the integrated address feature presents several benefits, there are potential drawbacks. Increased resource requirements per transaction and the embedding of identifying information into the blockchain may compromise user privacy. Despite these considerations, Worsley believes that the integration of such a feature would greatly benefit exchange developers if widely accepted. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_Improving-Pre-and-Post-Merging-Abilities-With-Rewriting-Core-In-Python.xml b/static/bitcoin-dev/April_2019/combined_Improving-Pre-and-Post-Merging-Abilities-With-Rewriting-Core-In-Python.xml index 0700c8e1ac..e37ad4bddb 100644 --- a/static/bitcoin-dev/April_2019/combined_Improving-Pre-and-Post-Merging-Abilities-With-Rewriting-Core-In-Python.xml +++ b/static/bitcoin-dev/April_2019/combined_Improving-Pre-and-Post-Merging-Abilities-With-Rewriting-Core-In-Python.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Improving Pre and Post Merging Abilities With Rewriting Core In Python - 2023-08-02T00:44:34.084428+00:00 - - Peter Todd 2019-04-27 03:32:27+00:00 - - - Hampus Sjöberg 2019-04-26 09:38:03+00:00 - - - Achow101 2019-04-23 15:23:27+00:00 - - - Ahmer Regos 2019-04-23 08:16:28+00:00 - + 2025-09-26T15:44:29.460326+00:00 + python-feedgen + + + [bitcoin-dev] Improving Pre and Post Merging Abilities With Rewriting Core In Python Ahmer Regos + 2019-04-23T08:16:00.000Z + + + Achow101 + 2019-04-23T15:23:00.000Z + + + Hampus Sjöberg + 2019-04-26T09:38:00.000Z + + + Peter Todd + 2019-04-27T03:32:00.000Z + + - python-feedgen + 2 Combined summary - Improving Pre and Post Merging Abilities With Rewriting Core In Python - 2023-08-02T00:44:34.084428+00:00 + 2025-09-26T15:44:29.461008+00:00 - In a discussion on the Bitcoin-dev mailing list, Achow101 suggested the implementation of Bitcoin Core in Python, citing its open-source nature. However, he acknowledged that this was unlikely due to Python's inefficiency and the potential for introducing bugs. Peter Todd, the maintainer of python-bitcoinlib, agreed with this sentiment, cautioning against the use of Python for security-critical codebases due to the ease of making mistakes. Instead, Todd recommended Rust as a language with significant benefits in terms of its type system and handling of immutability. While Todd's preference for Rust does not exclude other languages, he believes it aligns well with his programming style.The proposal to rewrite the Bitcoin codebase in Python aims to improve pre and post merging abilities, expedite operations, and enhance understandability. However, Hampus expressed concerns about the risks associated with rewriting a consensus critical system like Bitcoin in another language. He also argued that there would be no tangible benefit in switching to Python. Additionally, he highlighted past consensus issues between different versions of Bitcoin Core.While Bitcoin Core is open source and can be re-implemented in Python, experts caution against rewriting the entire codebase from C/C++. This undertaking would introduce numerous bugs and lack significant advantages. Moreover, Python is less efficient than C/C++. Consequently, Bitcoin Core will not transition to Python for the entire codebase, but individuals are free to port it themselves.Ahmer Regos from Regain Beaches has proposed a rewrite of the Bitcoin codebase in Python to enhance pre and post merging abilities, expedite operations, and improve overall understandability. Advocating for Python's speed, C support, good syntax, and readability, Regos sees coordinating this transformation as beneficial and eliminating C++ as a positive change. 2019-04-27T03:32:27+00:00 + In a discussion on the Bitcoin-dev mailing list, Achow101 suggested the implementation of Bitcoin Core in Python, citing its open-source nature. However, he acknowledged that this was unlikely due to Python's inefficiency and the potential for introducing bugs. Peter Todd, the maintainer of python-bitcoinlib, agreed with this sentiment, cautioning against the use of Python for security-critical codebases due to the ease of making mistakes. Instead, Todd recommended Rust as a language with significant benefits in terms of its type system and handling of immutability. While Todd's preference for Rust does not exclude other languages, he believes it aligns well with his programming style.The proposal to rewrite the Bitcoin codebase in Python aims to improve pre and post merging abilities, expedite operations, and enhance understandability. However, Hampus expressed concerns about the risks associated with rewriting a consensus critical system like Bitcoin in another language. He also argued that there would be no tangible benefit in switching to Python. Additionally, he highlighted past consensus issues between different versions of Bitcoin Core.While Bitcoin Core is open source and can be re-implemented in Python, experts caution against rewriting the entire codebase from C/C++. This undertaking would introduce numerous bugs and lack significant advantages. Moreover, Python is less efficient than C/C++. Consequently, Bitcoin Core will not transition to Python for the entire codebase, but individuals are free to port it themselves.Ahmer Regos from Regain Beaches has proposed a rewrite of the Bitcoin codebase in Python to enhance pre and post merging abilities, expedite operations, and improve overall understandability. Advocating for Python's speed, C support, good syntax, and readability, Regos sees coordinating this transformation as beneficial and eliminating C++ as a positive change. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_Improving-SPV-security-with-PoW-fraud-proofs.xml b/static/bitcoin-dev/April_2019/combined_Improving-SPV-security-with-PoW-fraud-proofs.xml index 92382522c9..d57b03040c 100644 --- a/static/bitcoin-dev/April_2019/combined_Improving-SPV-security-with-PoW-fraud-proofs.xml +++ b/static/bitcoin-dev/April_2019/combined_Improving-SPV-security-with-PoW-fraud-proofs.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Improving SPV security with PoW fraud proofs - 2023-08-02T00:44:08.482399+00:00 - - Ruben Somsen 2019-04-21 09:13:00+00:00 - - - ZmnSCPxj 2019-04-20 04:45:19+00:00 - - - Ruben Somsen 2019-04-20 03:26:03+00:00 - - - ZmnSCPxj 2019-04-20 01:59:25+00:00 - - - Ruben Somsen 2019-04-19 13:23:50+00:00 - - - ZmnSCPxj 2019-04-19 04:48:23+00:00 - - - Ethan Heilman 2019-04-19 03:21:53+00:00 - - - ZmnSCPxj 2019-04-19 02:53:49+00:00 - - - Ethan Heilman 2019-04-19 01:13:07+00:00 - - - ZmnSCPxj 2019-04-19 00:25:25+00:00 - - - Ethan Heilman 2019-04-18 20:12:20+00:00 - - - ZmnSCPxj 2019-04-18 16:55:10+00:00 - - - Ruben Somsen 2019-04-15 06:37:43+00:00 - + 2025-09-26T15:44:10.608432+00:00 + python-feedgen + + + [bitcoin-dev] Improving SPV security with PoW fraud proofs Ruben Somsen + 2019-04-15T06:37:00.000Z + + + ZmnSCPxj + 2019-04-18T16:55:00.000Z + + + Ethan Heilman + 2019-04-18T20:12:00.000Z + + + ZmnSCPxj + 2019-04-19T00:25:00.000Z + + + Ethan Heilman + 2019-04-19T01:13:00.000Z + + + ZmnSCPxj + 2019-04-19T02:53:00.000Z + + + Ethan Heilman + 2019-04-19T03:21:00.000Z + + + ZmnSCPxj + 2019-04-19T04:48:00.000Z + + + Ruben Somsen + 2019-04-19T13:23:00.000Z + + + ZmnSCPxj + 2019-04-20T01:59:00.000Z + + + Ruben Somsen + 2019-04-20T03:26:00.000Z + + + ZmnSCPxj + 2019-04-20T04:45:00.000Z + + + Ruben Somsen + 2019-04-21T09:13:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Improving SPV security with PoW fraud proofs - 2023-08-02T00:44:08.482399+00:00 + 2025-09-26T15:44:10.610001+00:00 - The discussion between Ruben Somsen and ZmnSCPxj revolves around the possibility of enabling light clients to verify a single block in isolation. Ruben suggests options like UTXO set commitments, BIP157/158 commitments, or BIP141 fraud proof commitments. While BIP157 can function without commitments, UTXO sets can only be validated by running the entire blockchain. The issue of data unavailability arises when peers allow hearing of all chains while denying proof of the invalidity of some UTXO.Ruben suggests using BIP157/158 filters that contain UTXO spends and are committed to on-chain to resolve this issue. However, ZmnSCPxj argues that validating every input in a block through the filter of every past block may be computationally expensive. Ruben also points out that storing and transmitting UTXO set commitments, utreexo commitments, or BIP158 filter digests over the network needs to be addressed. Storing these commitments in fullnodes at each block may increase resource usage.The current understanding of options for enabling light clients to verify a single block in isolation is UTXO set commitments, BIP157/158 commitments, and BIP141 fraud proof commitments.The discussion also delves into the validity of UTXO sets and fraud proofs in blockchain technology. Trusting every peer or omitting the proof is not acceptable as it requires one honest peer. Peers can be set up to allow hearing of all chains while denying proof of invalidity of some UTXO, leading to the issue of data unavailability.BIP157 manages to function without commitments, but UTXO sets require downloading the entire blockchain for validation. Ruben suggests combining BIP157/158 with UTXO set commitments, but ZmnSCPxj raises concerns about the computational expense of running every input in a block through the filter of every past block. The need to store and transmit commitments over the network is also highlighted, with potential resource usage increase in fullnodes if stored in coinbase.The conversation explores the possibility of using UTXO sets without identifying who validates them or making it expensive to lie. Ruben proposes committing to the location of UTXOs being spent by miners, allowing full nodes to prove invalidity to SPV clients. However, ZmnSCPxj argues that validating a block requires knowing the validity of every UTXO spent by transactions in that block, which may require downloading all blocks between the current block being verified and the block containing the UTXO to be validated.The email thread also discusses the security concerns related to Simplified Payment Verification (SPV) in Bitcoin. It is noted that a minority miner with significant mining power can disrupt SPV clients by creating multiple 1-block chainsplits and forcing them to download every block. Ethan Heilman suggests that SPV clients should download and validate the "longest chain" up to more than one block greater than the height of the losing chain to prevent such attacks. However, ZmnSCPxj highlights the potential loopholes and new attack possibilities that every rule imposes.The discussion concludes with the reminder to exercise caution when implementing rules to prevent attacks on the Bitcoin network.In summary, the email conversation covers various aspects of enabling light clients to verify a single block in isolation, including options like UTXO set commitments, BIP157/158 commitments, and BIP141 fraud proof commitments. The challenges of data unavailability and computational expense are discussed, along with the need to store and transmit commitments over the network. The vulnerability of SPV clients and the potential for disruption by a minority miner are also explored, emphasizing the importance of careful consideration when implementing rules to prevent attacks.Ruben Somsen proposed an improvement to Simplified-Payment-Verification (SPV) mechanism which is secure under the assumption that the chain with the most Proof-of-Work (PoW) is valid. He suggested that invalid blocks will be rejected as long as there are enough honest miners to create a block within a reasonable time frame. This improves SPV clients against dishonest miners and is compatible with the privacy improvements of BIP157.The idea is that a fork is an indication of potential misbehavior, and its block header can serve as a PoW fraud proof. Conversely, the lack of a fork is an indication that a block is valid. If a fork is created from a block at height N, this means a subset of miners may disagree on the validity of block N+1. If SPV clients download and verify this block, they can judge for themselves whether or not the chain should be rejected.Bitcoin currently cannot verify the validity of block N+1 without knowing the UTXO set at block N, even if you are willing to assume that block N (and everything before it) is valid. This would change with the introduction of UTXO set commitments, allowing block N+1 to be validated by verifying 2019-04-21T09:13:00+00:00 + The discussion between Ruben Somsen and ZmnSCPxj revolves around the possibility of enabling light clients to verify a single block in isolation. Ruben suggests options like UTXO set commitments, BIP157/158 commitments, or BIP141 fraud proof commitments. While BIP157 can function without commitments, UTXO sets can only be validated by running the entire blockchain. The issue of data unavailability arises when peers allow hearing of all chains while denying proof of the invalidity of some UTXO.Ruben suggests using BIP157/158 filters that contain UTXO spends and are committed to on-chain to resolve this issue. However, ZmnSCPxj argues that validating every input in a block through the filter of every past block may be computationally expensive. Ruben also points out that storing and transmitting UTXO set commitments, utreexo commitments, or BIP158 filter digests over the network needs to be addressed. Storing these commitments in fullnodes at each block may increase resource usage.The current understanding of options for enabling light clients to verify a single block in isolation is UTXO set commitments, BIP157/158 commitments, and BIP141 fraud proof commitments.The discussion also delves into the validity of UTXO sets and fraud proofs in blockchain technology. Trusting every peer or omitting the proof is not acceptable as it requires one honest peer. Peers can be set up to allow hearing of all chains while denying proof of invalidity of some UTXO, leading to the issue of data unavailability.BIP157 manages to function without commitments, but UTXO sets require downloading the entire blockchain for validation. Ruben suggests combining BIP157/158 with UTXO set commitments, but ZmnSCPxj raises concerns about the computational expense of running every input in a block through the filter of every past block. The need to store and transmit commitments over the network is also highlighted, with potential resource usage increase in fullnodes if stored in coinbase.The conversation explores the possibility of using UTXO sets without identifying who validates them or making it expensive to lie. Ruben proposes committing to the location of UTXOs being spent by miners, allowing full nodes to prove invalidity to SPV clients. However, ZmnSCPxj argues that validating a block requires knowing the validity of every UTXO spent by transactions in that block, which may require downloading all blocks between the current block being verified and the block containing the UTXO to be validated.The email thread also discusses the security concerns related to Simplified Payment Verification (SPV) in Bitcoin. It is noted that a minority miner with significant mining power can disrupt SPV clients by creating multiple 1-block chainsplits and forcing them to download every block. Ethan Heilman suggests that SPV clients should download and validate the "longest chain" up to more than one block greater than the height of the losing chain to prevent such attacks. However, ZmnSCPxj highlights the potential loopholes and new attack possibilities that every rule imposes.The discussion concludes with the reminder to exercise caution when implementing rules to prevent attacks on the Bitcoin network.In summary, the email conversation covers various aspects of enabling light clients to verify a single block in isolation, including options like UTXO set commitments, BIP157/158 commitments, and BIP141 fraud proof commitments. The challenges of data unavailability and computational expense are discussed, along with the need to store and transmit commitments over the network. The vulnerability of SPV clients and the potential for disruption by a minority miner are also explored, emphasizing the importance of careful consideration when implementing rules to prevent attacks.Ruben Somsen proposed an improvement to Simplified-Payment-Verification (SPV) mechanism which is secure under the assumption that the chain with the most Proof-of-Work (PoW) is valid. He suggested that invalid blocks will be rejected as long as there are enough honest miners to create a block within a reasonable time frame. This improves SPV clients against dishonest miners and is compatible with the privacy improvements of BIP157.The idea is that a fork is an indication of potential misbehavior, and its block header can serve as a PoW fraud proof. Conversely, the lack of a fork is an indication that a block is valid. If a fork is created from a block at height N, this means a subset of miners may disagree on the validity of block N+1. If SPV clients download and verify this block, they can judge for themselves whether or not the chain should be rejected.Bitcoin currently cannot verify the validity of block N+1 without knowing the UTXO set at block N, even if you are willing to assume that block N (and everything before it) is valid. This would change with the introduction of UTXO set commitments, allowing block N+1 to be validated by verifying - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_IsStandard.xml b/static/bitcoin-dev/April_2019/combined_IsStandard.xml index ac9236c0d6..3fcb4150d9 100644 --- a/static/bitcoin-dev/April_2019/combined_IsStandard.xml +++ b/static/bitcoin-dev/April_2019/combined_IsStandard.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - IsStandard - 2023-08-02T00:45:44.650088+00:00 - - Aymeric Vitte 2019-05-03 09:51:25+00:00 - - - Pieter Wuille 2019-05-02 23:35:06+00:00 - - - James Prestwich 2019-05-02 23:33:09+00:00 - - - Aymeric Vitte 2019-05-02 10:01:54+00:00 - - - ZmnSCPxj 2019-05-02 00:10:37+00:00 - - - Aymeric Vitte 2019-04-30 09:43:27+00:00 - - - ZmnSCPxj 2019-04-30 04:29:18+00:00 - - - Marco Falke 2019-04-29 17:27:29+00:00 - - - Aymeric Vitte 2019-04-29 09:30:39+00:00 - - - Luke Dashjr 2019-04-29 03:01:41+00:00 - - - ZmnSCPxj 2019-04-29 01:46:35+00:00 - - - Aymeric Vitte 2019-04-27 10:37:29+00:00 - + 2025-09-26T15:44:08.493414+00:00 + python-feedgen + + + [bitcoin-dev] IsStandard Aymeric Vitte + 2019-04-27T10:37:00.000Z + + + ZmnSCPxj + 2019-04-29T01:46:00.000Z + + + Luke Dashjr + 2019-04-29T03:01:00.000Z + + + Aymeric Vitte + 2019-04-29T09:30:00.000Z + + + Marco Falke + 2019-04-29T17:27:00.000Z + + + ZmnSCPxj + 2019-04-30T04:29:00.000Z + + + Aymeric Vitte + 2019-04-30T09:43:00.000Z + + + ZmnSCPxj + 2019-05-02T00:10:00.000Z + + + Aymeric Vitte + 2019-05-02T10:01:00.000Z + + + James Prestwich + 2019-05-02T23:33:00.000Z + + + Pieter Wuille + 2019-05-02T23:35:00.000Z + + + Aymeric Vitte + 2019-05-03T09:51:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - IsStandard - 2023-08-02T00:45:44.650088+00:00 + 2025-09-26T15:44:08.494829+00:00 - In a recent bitcoin-dev discussion, the standardness of bitcoin scripting was brought into question. Contributors discussed whether non-usual transactions would be relayed by nodes and how to determine what nodes will accept. It was agreed upon that any custom script can be wrapped in P2SH and P2WSH and it will be propagated. However, P2PKH and P2WPKH cannot have custom scripts. Once a claim on a modified x-of-3 is propagated, the redeemScript becomes known and someone can attempt to RBF with a modified witness stack or scriptSig to claim the UTXO. The standardness of Bitcoin Cash (BCH) transactions is still unclear. SHA bounties were also discussed, which can be propagated if they are wrapped in P2SH or P2WSH. However, the redeemScript must be published by the creator or bribed a miner if the transaction is not time-sensitive.Pieter clarified that all spends of P2SH/P2WSH are standard, except for non-push operations in the scriptSig, resource limitations, protections against known attack vectors, and usage of unconditionally spendable constructions intended for future extensions. He also confirmed that redeem scripts for the sha bounties are in op_return.James Prestwich provided a reference for default TX_NONSTANDARD policies in v0.18, but noted that documenting standardness is challenging as it varies from version to version. His reference only applied to v0.18 and may already be outdated.The conversation highlighted that P2PKH, P2WPKH, P2SH, and P2WSH are recognized as templates by most current nodes and are expected to be propagated by a majority of nodes. Any custom script can be wrapped in P2SH and P2WSH and will be propagated, as these templates hide the details of the custom script. However, filtering based on the custom script is not possible. For BCH, it was noted that P2PKH and P2WPKH cannot have custom scripts, but the standardness of other transactions remains unclear.ZmnSCPxj explained that nodes can have any policy for propagating transactions, but transactions that do not pay out to P2PKH, P2WPKH, P2SH, or P2WSH are unlikely to be propagated by most nodes. However, coordination with miners is still possible to get these non-standard transactions mined. The standardness of Bitcoin transactions and scripts is not described in a single document and may change over time or across different implementations.Luke Dashjr emphasized that IsStandard, which implements a node's policy, should not be given much attention when defining new standards. Instead, he recommended focusing on documenting actual standards rather than IsStandard beyond the code.In conclusion, the standardness of Bitcoin transactions varies from version to version and across different implementations. P2PKH, P2WPKH, P2SH, and P2WSH are generally recognized as standard templates, but anything that does not fit into these templates is less likely to be propagated by nodes. However, coordination with miners can still allow non-standard transactions to be mined. It is important to document actual standards rather than relying solely on IsStandard function in the code. 2019-05-03T09:51:25+00:00 + In a recent bitcoin-dev discussion, the standardness of bitcoin scripting was brought into question. Contributors discussed whether non-usual transactions would be relayed by nodes and how to determine what nodes will accept. It was agreed upon that any custom script can be wrapped in P2SH and P2WSH and it will be propagated. However, P2PKH and P2WPKH cannot have custom scripts. Once a claim on a modified x-of-3 is propagated, the redeemScript becomes known and someone can attempt to RBF with a modified witness stack or scriptSig to claim the UTXO. The standardness of Bitcoin Cash (BCH) transactions is still unclear. SHA bounties were also discussed, which can be propagated if they are wrapped in P2SH or P2WSH. However, the redeemScript must be published by the creator or bribed a miner if the transaction is not time-sensitive.Pieter clarified that all spends of P2SH/P2WSH are standard, except for non-push operations in the scriptSig, resource limitations, protections against known attack vectors, and usage of unconditionally spendable constructions intended for future extensions. He also confirmed that redeem scripts for the sha bounties are in op_return.James Prestwich provided a reference for default TX_NONSTANDARD policies in v0.18, but noted that documenting standardness is challenging as it varies from version to version. His reference only applied to v0.18 and may already be outdated.The conversation highlighted that P2PKH, P2WPKH, P2SH, and P2WSH are recognized as templates by most current nodes and are expected to be propagated by a majority of nodes. Any custom script can be wrapped in P2SH and P2WSH and will be propagated, as these templates hide the details of the custom script. However, filtering based on the custom script is not possible. For BCH, it was noted that P2PKH and P2WPKH cannot have custom scripts, but the standardness of other transactions remains unclear.ZmnSCPxj explained that nodes can have any policy for propagating transactions, but transactions that do not pay out to P2PKH, P2WPKH, P2SH, or P2WSH are unlikely to be propagated by most nodes. However, coordination with miners is still possible to get these non-standard transactions mined. The standardness of Bitcoin transactions and scripts is not described in a single document and may change over time or across different implementations.Luke Dashjr emphasized that IsStandard, which implements a node's policy, should not be given much attention when defining new standards. Instead, he recommended focusing on documenting actual standards rather than IsStandard beyond the code.In conclusion, the standardness of Bitcoin transactions varies from version to version and across different implementations. P2PKH, P2WPKH, P2SH, and P2WSH are generally recognized as standard templates, but anything that does not fit into these templates is less likely to be propagated by nodes. However, coordination with miners can still allow non-standard transactions to be mined. It is important to document actual standards rather than relying solely on IsStandard function in the code. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_License-for-BIP39-word-lists.xml b/static/bitcoin-dev/April_2019/combined_License-for-BIP39-word-lists.xml index 4513d7f117..4a1d59465f 100644 --- a/static/bitcoin-dev/April_2019/combined_License-for-BIP39-word-lists.xml +++ b/static/bitcoin-dev/April_2019/combined_License-for-BIP39-word-lists.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - License for BIP39 word lists - 2023-08-02T00:42:04.116633+00:00 - - Aymeric Vitte 2019-04-09 16:19:40+00:00 - - - Pavol Rusnak 2019-04-09 09:49:53+00:00 - - - Aymeric Vitte 2019-04-09 09:46:37+00:00 - - - Pavol Rusnak 2019-04-03 09:19:40+00:00 - - - Elia 2019-04-03 05:53:25+00:00 - + 2025-09-26T15:44:21.063280+00:00 + python-feedgen + + + [bitcoin-dev] License for BIP39 word lists Elia + 2019-04-03T05:53:00.000Z + + + Pavol Rusnak + 2019-04-03T09:19:00.000Z + + + Aymeric Vitte + 2019-04-09T09:46:00.000Z + + + Pavol Rusnak + 2019-04-09T09:49:00.000Z + + + Aymeric Vitte + 2019-04-09T16:19:00.000Z + + - python-feedgen + 2 Combined summary - License for BIP39 word lists - 2023-08-02T00:42:04.116633+00:00 + 2025-09-26T15:44:21.064014+00:00 - Pavol Rusnak, the author of the BIP39 wordlist, has confirmed that there are no restrictions on using it. However, a new standard called SLIP39 for splitting shares is being finalized and will use a different wordlist with better properties. This standard might be more suitable for Elia's project.In response to Elia's question about the license associated with the BIP39 wordlists posted on Github, Pavol Rusnak stated that there are no restrictions on using his wordlist. He also mentioned that they are currently finalizing the SLIP39 standard, which uses a different wordlist with better properties. The links to the SLIP39 standard and its associated wordlist can be found in his reply.The SLIP39 standard, along with its wordlist, can be found on SatoshiLabs' GitHub page. Elia had expressed concern about the lack of a license for the BIP39 wordlists on the GitHub BIP repository and asked if usage for other projects was permitted. It is unclear whether Elia was made aware of the unrestricted usage of the wordlist by the author.In an email thread on the Bitcoin-dev mailing list, Elia inquired about using the BIP39 word lists for their own project as there was no license associated with the lists provided on Github. Pavol Rusnak, the author of the wordlist, responded that the list can be used without any restrictions and suggested the use of the SLIP39 standard for splitting shares which uses a different wordlist with better properties. The SLIP39 standard can be found on Github along with its wordlist. It is not mentioned who else will adopt the wordlist or whether it is live in Trezor.Elia is interested in using the BIP39 word lists available on the Github BIP repository for their own project. However, there is no license agreement associated with the lists provided which raises concerns about whether or not usage for other projects is permitted. Elia is unable to file issues on the repository to suggest adding a license. They are seeking information about under which license these lists are published.On GitHub, there are other resources available such as Peersm.com, a browser version for moving coins, and repositories for bitcoin-transactions and bitcoin-wallets made simple. Additionally, Torrent-live.org is recommended as a good resource for dynamic blocklists for anti-spies and private torrents. 2019-04-09T16:19:40+00:00 + Pavol Rusnak, the author of the BIP39 wordlist, has confirmed that there are no restrictions on using it. However, a new standard called SLIP39 for splitting shares is being finalized and will use a different wordlist with better properties. This standard might be more suitable for Elia's project.In response to Elia's question about the license associated with the BIP39 wordlists posted on Github, Pavol Rusnak stated that there are no restrictions on using his wordlist. He also mentioned that they are currently finalizing the SLIP39 standard, which uses a different wordlist with better properties. The links to the SLIP39 standard and its associated wordlist can be found in his reply.The SLIP39 standard, along with its wordlist, can be found on SatoshiLabs' GitHub page. Elia had expressed concern about the lack of a license for the BIP39 wordlists on the GitHub BIP repository and asked if usage for other projects was permitted. It is unclear whether Elia was made aware of the unrestricted usage of the wordlist by the author.In an email thread on the Bitcoin-dev mailing list, Elia inquired about using the BIP39 word lists for their own project as there was no license associated with the lists provided on Github. Pavol Rusnak, the author of the wordlist, responded that the list can be used without any restrictions and suggested the use of the SLIP39 standard for splitting shares which uses a different wordlist with better properties. The SLIP39 standard can be found on Github along with its wordlist. It is not mentioned who else will adopt the wordlist or whether it is live in Trezor.Elia is interested in using the BIP39 word lists available on the Github BIP repository for their own project. However, there is no license agreement associated with the lists provided which raises concerns about whether or not usage for other projects is permitted. Elia is unable to file issues on the repository to suggest adding a license. They are seeking information about under which license these lists are published.On GitHub, there are other resources available such as Peersm.com, a browser version for moving coins, and repositories for bitcoin-transactions and bitcoin-wallets made simple. Additionally, Torrent-live.org is recommended as a good resource for dynamic blocklists for anti-spies and private torrents. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_List-of-proposals-for-hard-fork-soft-fork.xml b/static/bitcoin-dev/April_2019/combined_List-of-proposals-for-hard-fork-soft-fork.xml index cdda729357..4284a33955 100644 --- a/static/bitcoin-dev/April_2019/combined_List-of-proposals-for-hard-fork-soft-fork.xml +++ b/static/bitcoin-dev/April_2019/combined_List-of-proposals-for-hard-fork-soft-fork.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - List of proposals for hard fork/soft fork - 2023-08-02T00:42:46.641599+00:00 - - ZmnSCPxj 2019-04-15 02:59:44+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2019-04-14 14:44:53+00:00 - + 2025-09-26T15:44:16.881387+00:00 + python-feedgen + + + [bitcoin-dev] List of proposals for hard fork/soft fork LORD HIS EXCELLENCY JAMES HRMH + 2019-04-14T14:44:00.000Z + + + ZmnSCPxj + 2019-04-15T02:59:00.000Z + + - python-feedgen + 2 Combined summary - List of proposals for hard fork/soft fork - 2023-08-02T00:42:46.641599+00:00 + 2025-09-26T15:44:16.881813+00:00 - A list of potential softfork proposals for SegWit v1 has been provided, which includes Schnorr signatures, MuSig, Taproot, SIGHASH_NOINPUT, signature aggregation, and MAST. It is uncertain if this list is exhaustive, as other proposals may exist. Only SIGHASH_NOINPUT currently has a BIP (BIP 118), although it may not match the version that will ultimately be integrated into Bitcoin Core.To mitigate the risk of incorrect usage of SIGHASH_NOINPUT, it is suggested that each input signed with a SIGHASH_NOINPUT signature also require a signature without SIGHASH_NOINPUT. However, further details regarding this proposal are currently unavailable.Lord His Excellency James HRMH initially requested a list of solid proposals for future consensus-driven forks to generate momentum for valuable implementations. In response to this, it is recommended that a list be compiled consisting of strong proposals and BIPs to be included in a future consensus-driven fork. This approach would help propel the development of useful implementations that might otherwise struggle to gain traction.It is important to acknowledge that not every proposal will be considered for inclusion in the fork packages. To determine which proposals should be included, pre-consensus voting could be conducted, allowing stakeholders to have a voice in the decision-making process. 2019-04-15T02:59:44+00:00 + A list of potential softfork proposals for SegWit v1 has been provided, which includes Schnorr signatures, MuSig, Taproot, SIGHASH_NOINPUT, signature aggregation, and MAST. It is uncertain if this list is exhaustive, as other proposals may exist. Only SIGHASH_NOINPUT currently has a BIP (BIP 118), although it may not match the version that will ultimately be integrated into Bitcoin Core.To mitigate the risk of incorrect usage of SIGHASH_NOINPUT, it is suggested that each input signed with a SIGHASH_NOINPUT signature also require a signature without SIGHASH_NOINPUT. However, further details regarding this proposal are currently unavailable.Lord His Excellency James HRMH initially requested a list of solid proposals for future consensus-driven forks to generate momentum for valuable implementations. In response to this, it is recommended that a list be compiled consisting of strong proposals and BIPs to be included in a future consensus-driven fork. This approach would help propel the development of useful implementations that might otherwise struggle to gain traction.It is important to acknowledge that not every proposal will be considered for inclusion in the fork packages. To determine which proposals should be included, pre-consensus voting could be conducted, allowing stakeholders to have a voice in the decision-making process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_Payjoin2swap-Enabling-Payjoin-Without-Merchant-Purchases.xml b/static/bitcoin-dev/April_2019/combined_Payjoin2swap-Enabling-Payjoin-Without-Merchant-Purchases.xml index 6076c68f48..e2b8982fe5 100644 --- a/static/bitcoin-dev/April_2019/combined_Payjoin2swap-Enabling-Payjoin-Without-Merchant-Purchases.xml +++ b/static/bitcoin-dev/April_2019/combined_Payjoin2swap-Enabling-Payjoin-Without-Merchant-Purchases.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Payjoin2swap: Enabling Payjoin Without Merchant Purchases - 2023-08-02T00:44:21.360585+00:00 - - ZmnSCPxj 2019-04-22 17:06:43+00:00 - - - ZmnSCPxj 2019-04-22 00:07:20+00:00 - + 2025-09-26T15:44:06.398352+00:00 + python-feedgen + + + [bitcoin-dev] Payjoin2swap: Enabling Payjoin Without Merchant Purchases ZmnSCPxj + 2019-04-22T00:07:00.000Z + + + ZmnSCPxj + 2019-04-22T17:06:00.000Z + + - python-feedgen + 2 Combined summary - Payjoin2swap: Enabling Payjoin Without Merchant Purchases - 2023-08-02T00:44:21.360585+00:00 + 2025-09-26T15:44:06.398867+00:00 - The post introduces Payjoin2swap as a method to implement payjoin using Lightning Network operations. The author explains that payjoin allows two parties to exchange Bitcoin value without revealing identifying information, breaking the common-input heuristic used by blockchain analysts. However, payjoin is primarily designed for payments rather than hodling. To address this issue, the article suggests that hodlers can still utilize payjoin by using bitcoins in a payjoin to buy bitcoins of similar value.The article then introduces Payjoin2swap, a protocol that enables participants to exchange Bitcoin value without revealing identifying information. In a Payjoin2swap, two transactions occur at about the same time on the blockchain, appearing to pay two different addresses with change outputs. Participants in Payjoin2swap need to own two UTXOs onchain, and the values do not need to be equal. The article provides examples of how Payjoin2swap works, including exchanging Bitcoin value between Alice and Bob and paying Carol without reducing the privacy of mix participants.Participants in Payjoin2swap must agree on various parameters, such as the amount to be swapped, safe confirmation depth for anchoring, future block heights, and the exchange of private keys. To ensure plausible transactions, one output should always be larger than the sum of all inputs except the smallest input. Additional rules can be imposed if both parties have two UTXOs each.The article also discusses Linking and Overlinking Payjoin2swap, which involves monitoring the mempool for specific transaction types and computing an "apparent swap value" from the difference of an input and the lower input or 0 if one-output. This can potentially link unrelated transactions.Overall, Payjoin2swap is presented as a privacy-enhancing protocol that allows two parties to swap their bitcoin without revealing any information about their transactions. 2019-04-22T17:06:43+00:00 + The post introduces Payjoin2swap as a method to implement payjoin using Lightning Network operations. The author explains that payjoin allows two parties to exchange Bitcoin value without revealing identifying information, breaking the common-input heuristic used by blockchain analysts. However, payjoin is primarily designed for payments rather than hodling. To address this issue, the article suggests that hodlers can still utilize payjoin by using bitcoins in a payjoin to buy bitcoins of similar value.The article then introduces Payjoin2swap, a protocol that enables participants to exchange Bitcoin value without revealing identifying information. In a Payjoin2swap, two transactions occur at about the same time on the blockchain, appearing to pay two different addresses with change outputs. Participants in Payjoin2swap need to own two UTXOs onchain, and the values do not need to be equal. The article provides examples of how Payjoin2swap works, including exchanging Bitcoin value between Alice and Bob and paying Carol without reducing the privacy of mix participants.Participants in Payjoin2swap must agree on various parameters, such as the amount to be swapped, safe confirmation depth for anchoring, future block heights, and the exchange of private keys. To ensure plausible transactions, one output should always be larger than the sum of all inputs except the smallest input. Additional rules can be imposed if both parties have two UTXOs each.The article also discusses Linking and Overlinking Payjoin2swap, which involves monitoring the mempool for specific transaction types and computing an "apparent swap value" from the difference of an input and the lower input or 0 if one-output. This can potentially link unrelated transactions.Overall, Payjoin2swap is presented as a privacy-enhancing protocol that allows two parties to swap their bitcoin without revealing any information about their transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_Smart-Contracts-Unchained.xml b/static/bitcoin-dev/April_2019/combined_Smart-Contracts-Unchained.xml index 6abe15c076..a2568467ee 100644 --- a/static/bitcoin-dev/April_2019/combined_Smart-Contracts-Unchained.xml +++ b/static/bitcoin-dev/April_2019/combined_Smart-Contracts-Unchained.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Smart Contracts Unchained - 2023-08-02T00:42:32.622132+00:00 - - ZmnSCPxj 2019-04-18 05:33:42+00:00 - - - Nadav Kohen 2019-04-17 16:17:11+00:00 - - - Aymeric Vitte 2019-04-08 16:28:27+00:00 - - - ZmnSCPxj 2019-04-08 10:45:29+00:00 - - - Aymeric Vitte 2019-04-05 17:46:35+00:00 - - - ZmnSCPxj 2019-04-05 06:00:20+00:00 - - - ZmnSCPxj 2019-04-04 23:52:20+00:00 - - - Aymeric Vitte 2019-04-04 17:18:30+00:00 - - - ZmnSCPxj 2019-04-04 15:03:39+00:00 - - - ZmnSCPxj 2019-04-04 07:07:10+00:00 - - - Ariel Lorenzo-Luaces 2019-04-04 03:37:47+00:00 - - - Tamas Blummer 2019-04-04 02:35:03+00:00 - - - ZmnSCPxj 2019-04-04 01:55:06+00:00 - + 2025-09-26T15:44:14.792038+00:00 + python-feedgen + + + [bitcoin-dev] Smart Contracts Unchained ZmnSCPxj + 2019-04-04T01:55:00.000Z + + + Tamas Blummer + 2019-04-04T02:35:00.000Z + + + Ariel Lorenzo-Luaces + 2019-04-04T03:37:00.000Z + + + ZmnSCPxj + 2019-04-04T07:07:00.000Z + + + ZmnSCPxj + 2019-04-04T15:03:00.000Z + + + Aymeric Vitte + 2019-04-04T17:18:00.000Z + + + ZmnSCPxj + 2019-04-04T23:52:00.000Z + + + ZmnSCPxj + 2019-04-05T06:00:00.000Z + + + Aymeric Vitte + 2019-04-05T17:46:00.000Z + + + ZmnSCPxj + 2019-04-08T10:45:00.000Z + + + Aymeric Vitte + 2019-04-08T16:28:00.000Z + + + Nadav Kohen + 2019-04-17T16:17:00.000Z + + + ZmnSCPxj + 2019-04-18T05:33:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Smart Contracts Unchained - 2023-08-02T00:42:32.622132+00:00 + 2025-09-26T15:44:14.793668+00:00 - In an email conversation, the benefits of Lightning in smart contracts are discussed. The proposal suggests using locked funds from a Lightning channel to create a 2/3 MultiSig output for an escrow scheme. Three scenarios are presented: Smart Contracts in a Lightning Channel, Single Hop Smart Contracts, and Fully Routed Smart Contracts. Each scenario has its own challenges, such as ensuring only the intended party can claim the output in Single Hop Smart Contracts. The proposal aims to achieve the benefits of Lightning without the need for a separate blockchain or sidechain.The conversation also touches on the comparison between Ethereum and Bitcoin sidechains. The writer emphasizes precision in terminology and defines a blockchain as a Merklized singly-linked list containing state transformations. While Lightning Network is not considered a sidechain, it shares a "federated" off-chain structure with federated sidechains. The security of Lightning is highlighted due to its consensus mechanism.Aymeric and ZmnSCPxj discuss the disappearance of smart contract platforms and the possibility of recovering funds. They suggest that if all participants agree on a fair distribution, funds can be recovered even if the platform disappears. The conversation raises concerns about the centralization of existing sidechains and proposes a decentralized system for storing intermediate states. However, it is noted that this may be a future step. The issue of platforms going down needs to be addressed.ZmnSCPxj proposes an alternative method for implementing smart contracts without launching a separate blockchain or sidechain. This method allows participants to select trusted executors of smart contracts and determine the necessary voting quorum for consensus. However, too many choices may complicate decision-making. The importance of addressing the issue of disappearing platforms is emphasized.The conversation between Aymeric and ZmnSCPxj revolves around the decentralization and security of sidechains. The possibility of recovery in case of disappearing smart contract platforms is discussed. A decentralized system to store intermediate states is suggested, but its feasibility is uncertain. The proposal does not directly address the concerns about centralization and sidechains.ZmnSCPxj proposes a mechanism for implementing smart contracts without a separate blockchain or sidechain. This mechanism offers security similar to federated sidechains and additional benefits to privacy and smart-contract-patching. It allows participants to select trusted executors of smart contracts and determine the necessary voting quorum for consensus. However, too many choices may complicate decision-making.The conversation discusses the possibility of recovering funds in case smart contract platforms disappear. It is suggested that all participants agree on a fair distribution of funds. Existing sidechains are criticized for being centralized, except for Lightning Network. The proposal aims to move towards offchain techniques and highlights concerns about the decentralization and security of sidechains.The author questions the use of sidechains for smart contracts and proposes a decentralized system for storing intermediate states. They believe existing sidechains are centralized except for Lightning Network. The proposal advocates for a distributed escrow to store intermediate states. Concerns are raised about the decentralization and security of sidechains and the issue of disappearing platforms is acknowledged.ZmnSCPxj proposes an alternative method for implementing smart contracts without launching a separate blockchain or sidechain. This method achieves security similar to federated sidechains and offers additional benefits. The proposal suggests using an "as long as everybody agrees" escape hatch for buggy contracts. Concerns are raised about the ability to determine if a contract state is old without a consensus mechanism. The proposal addresses traditional smart contract implementation and offers a different approach.A proposal suggests an alternative method for implementing smart contracts without a separate blockchain or sidechain. This method achieves security similar to federated sidechains and offers additional benefits. The proposal uses Bitcoin's script language to create custom transaction types. It introduces Vault Transactions for time-locked payments and escrow services. Patchable Smart Contracts allow for updates without a hard fork. The proposal offers enhanced security, privacy, and patchability. 2019-04-18T05:33:42+00:00 + In an email conversation, the benefits of Lightning in smart contracts are discussed. The proposal suggests using locked funds from a Lightning channel to create a 2/3 MultiSig output for an escrow scheme. Three scenarios are presented: Smart Contracts in a Lightning Channel, Single Hop Smart Contracts, and Fully Routed Smart Contracts. Each scenario has its own challenges, such as ensuring only the intended party can claim the output in Single Hop Smart Contracts. The proposal aims to achieve the benefits of Lightning without the need for a separate blockchain or sidechain.The conversation also touches on the comparison between Ethereum and Bitcoin sidechains. The writer emphasizes precision in terminology and defines a blockchain as a Merklized singly-linked list containing state transformations. While Lightning Network is not considered a sidechain, it shares a "federated" off-chain structure with federated sidechains. The security of Lightning is highlighted due to its consensus mechanism.Aymeric and ZmnSCPxj discuss the disappearance of smart contract platforms and the possibility of recovering funds. They suggest that if all participants agree on a fair distribution, funds can be recovered even if the platform disappears. The conversation raises concerns about the centralization of existing sidechains and proposes a decentralized system for storing intermediate states. However, it is noted that this may be a future step. The issue of platforms going down needs to be addressed.ZmnSCPxj proposes an alternative method for implementing smart contracts without launching a separate blockchain or sidechain. This method allows participants to select trusted executors of smart contracts and determine the necessary voting quorum for consensus. However, too many choices may complicate decision-making. The importance of addressing the issue of disappearing platforms is emphasized.The conversation between Aymeric and ZmnSCPxj revolves around the decentralization and security of sidechains. The possibility of recovery in case of disappearing smart contract platforms is discussed. A decentralized system to store intermediate states is suggested, but its feasibility is uncertain. The proposal does not directly address the concerns about centralization and sidechains.ZmnSCPxj proposes a mechanism for implementing smart contracts without a separate blockchain or sidechain. This mechanism offers security similar to federated sidechains and additional benefits to privacy and smart-contract-patching. It allows participants to select trusted executors of smart contracts and determine the necessary voting quorum for consensus. However, too many choices may complicate decision-making.The conversation discusses the possibility of recovering funds in case smart contract platforms disappear. It is suggested that all participants agree on a fair distribution of funds. Existing sidechains are criticized for being centralized, except for Lightning Network. The proposal aims to move towards offchain techniques and highlights concerns about the decentralization and security of sidechains.The author questions the use of sidechains for smart contracts and proposes a decentralized system for storing intermediate states. They believe existing sidechains are centralized except for Lightning Network. The proposal advocates for a distributed escrow to store intermediate states. Concerns are raised about the decentralization and security of sidechains and the issue of disappearing platforms is acknowledged.ZmnSCPxj proposes an alternative method for implementing smart contracts without launching a separate blockchain or sidechain. This method achieves security similar to federated sidechains and offers additional benefits. The proposal suggests using an "as long as everybody agrees" escape hatch for buggy contracts. Concerns are raised about the ability to determine if a contract state is old without a consensus mechanism. The proposal addresses traditional smart contract implementation and offers a different approach.A proposal suggests an alternative method for implementing smart contracts without a separate blockchain or sidechain. This method achieves security similar to federated sidechains and offers additional benefits. The proposal uses Bitcoin's script language to create custom transaction types. It introduces Vault Transactions for time-locked payments and escrow services. Patchable Smart Contracts allow for updates without a hard fork. The proposal offers enhanced security, privacy, and patchability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_Softfork-proposal-for-minimum-price-of-50k-USD-BTC.xml b/static/bitcoin-dev/April_2019/combined_Softfork-proposal-for-minimum-price-of-50k-USD-BTC.xml index bb9334c482..b12e87d188 100644 --- a/static/bitcoin-dev/April_2019/combined_Softfork-proposal-for-minimum-price-of-50k-USD-BTC.xml +++ b/static/bitcoin-dev/April_2019/combined_Softfork-proposal-for-minimum-price-of-50k-USD-BTC.xml @@ -1,44 +1,63 @@ - + 2 Combined summary - Softfork proposal for minimum price of $50k USD/BTC - 2023-08-02T00:40:23.042983+00:00 - - Aymeric Vitte 2019-04-02 16:48:55+00:00 - - - Dana L. Coe 2019-04-01 11:50:24+00:00 - - - Melvin Carvalho 2019-04-01 11:22:28+00:00 - - - Satoshin 2019-04-01 03:07:41+00:00 - - - Dave Scotese 2019-04-01 03:04:18+00:00 - - - ZmnSCPxj 2019-04-01 03:02:28+00:00 - - - Thomas France 2019-04-01 02:57:57+00:00 - - - Omar Shibli 2019-04-01 02:55:41+00:00 - - - Omar Shibli 2019-04-01 02:54:16+00:00 - - - Peter Todd 2019-04-01 01:11:12+00:00 - - - Ricardo Filipe 2019-04-01 01:04:10+00:00 - - - Luke Dashjr 2019-04-01 00:30:34+00:00 - + 2025-09-26T15:44:12.702852+00:00 + python-feedgen + + + [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC Luke Dashjr + 2019-04-01T00:30:00.000Z + + + Ricardo Filipe + 2019-04-01T01:04:00.000Z + + + Peter Todd + 2019-04-01T01:11:00.000Z + + + Omar Shibli + 2019-04-01T02:54:00.000Z + + + Omar Shibli + 2019-04-01T02:55:00.000Z + + + Thomas France + 2019-04-01T02:57:00.000Z + + + ZmnSCPxj + 2019-04-01T03:02:00.000Z + + + Dave Scotese + 2019-04-01T03:04:00.000Z + + + Satoshin + 2019-04-01T03:07:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2019-04-01T08:55:00.000Z + + + Melvin Carvalho + 2019-04-01T11:22:00.000Z + + + Dana L. Coe + 2019-04-01T11:50:00.000Z + + + Aymeric Vitte + 2019-04-02T16:48:00.000Z + + @@ -51,13 +70,13 @@ - python-feedgen + 2 Combined summary - Softfork proposal for minimum price of $50k USD/BTC - 2023-08-02T00:40:23.042983+00:00 + 2025-09-26T15:44:12.704435+00:00 - On April 1, 2019, Luke Dashjr proposed two Bitcoin Improvement Proposals (BIPs) to address the issue of certain parts of the community selling bitcoins for unreasonably low prices. The first BIP suggests adding a signed price field to Bitcoin transactions, allowing the sender to affirm the true USD/BTC rate used in the transaction. This would be achieved by adding a new field to Bitcoin transactions and signing it. The second BIP proposes a soft fork to set a minimum price of $50k USD/BTC for Bitcoin transactions. This would require all transactions to declare a USD/BTC price and specify a price that is at least $50k USD/BTC.The motivation behind these proposals is the concern that low-priced bitcoin sales have halted Bitcoin's valuation at $20k and driven the price down below $15k. By setting a minimum price, Dashjr hopes to establish a global minimum for bitcoin prices and prevent further undervaluation. The reference implementations for the BIPs can be found on GitHub, and a soft fork activation is expected around April 2020.However, some members of the Bitcoin developer community have raised concerns about the proposals. One concern is that the second BIP could potentially make Bitcoin fail the SEC test of a viable asset, as it does not allow for market demand to determine prices. Additionally, there is no limit on the maximum supply of USD, which poses a vulnerability in the proposal.The discussion also includes alternative suggestions. Dana proposes using USDT instead of USD as the reference currency, arguing that Tethers are more flexible in tracking the true value of the US dollar. Melvin Carvalho questions the use of fiat currency altogether and suggests denominating the minimum value in satoshis themselves, which would be a negligible upgrade to the network. There is also a wider discussion about the arbitrary nature of using USD as the reference currency and the potential future changes in dominant currencies.Overall, the discussion centers around the proposed minimum price and whether it is necessary or desirable for Bitcoin's valuation. The community is actively engaging with the proposals and considering alternative approaches to address the issue of undervaluation in Bitcoin transactions. 2019-04-02T16:48:55+00:00 + On April 1, 2019, Luke Dashjr proposed two Bitcoin Improvement Proposals (BIPs) to address the issue of certain parts of the community selling bitcoins for unreasonably low prices. The first BIP suggests adding a signed price field to Bitcoin transactions, allowing the sender to affirm the true USD/BTC rate used in the transaction. This would be achieved by adding a new field to Bitcoin transactions and signing it. The second BIP proposes a soft fork to set a minimum price of $50k USD/BTC for Bitcoin transactions. This would require all transactions to declare a USD/BTC price and specify a price that is at least $50k USD/BTC.The motivation behind these proposals is the concern that low-priced bitcoin sales have halted Bitcoin's valuation at $20k and driven the price down below $15k. By setting a minimum price, Dashjr hopes to establish a global minimum for bitcoin prices and prevent further undervaluation. The reference implementations for the BIPs can be found on GitHub, and a soft fork activation is expected around April 2020.However, some members of the Bitcoin developer community have raised concerns about the proposals. One concern is that the second BIP could potentially make Bitcoin fail the SEC test of a viable asset, as it does not allow for market demand to determine prices. Additionally, there is no limit on the maximum supply of USD, which poses a vulnerability in the proposal.The discussion also includes alternative suggestions. Dana proposes using USDT instead of USD as the reference currency, arguing that Tethers are more flexible in tracking the true value of the US dollar. Melvin Carvalho questions the use of fiat currency altogether and suggests denominating the minimum value in satoshis themselves, which would be a negligible upgrade to the network. There is also a wider discussion about the arbitrary nature of using USD as the reference currency and the potential future changes in dominant currencies.Overall, the discussion centers around the proposed minimum price and whether it is necessary or desirable for Bitcoin's valuation. The community is actively engaging with the proposals and considering alternative approaches to address the issue of undervaluation in Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_assumeutxo-and-UTXO-snapshots.xml b/static/bitcoin-dev/April_2019/combined_assumeutxo-and-UTXO-snapshots.xml index d28451ddf9..11c785bf50 100644 --- a/static/bitcoin-dev/April_2019/combined_assumeutxo-and-UTXO-snapshots.xml +++ b/static/bitcoin-dev/April_2019/combined_assumeutxo-and-UTXO-snapshots.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - assumeutxo and UTXO snapshots - 2023-08-02T00:41:44.233181+00:00 - - James O'Beirne 2019-04-23 14:17:06+00:00 - - - Dave Scotese 2019-04-15 00:44:51+00:00 - - - Omar Shibli 2019-04-14 13:16:53+00:00 - - - Peter Todd 2019-04-13 19:09:25+00:00 - - - James O'Beirne 2019-04-04 14:36:53+00:00 - - - Kulpreet Singh 2019-04-04 10:27:02+00:00 - - - Jim Posen 2019-04-04 05:59:32+00:00 - - - Ethan Scruples 2019-04-04 03:04:58+00:00 - - - Luke Dashjr 2019-04-04 03:01:00+00:00 - - - Luke Dashjr 2019-04-04 02:48:33+00:00 - - - Jim Posen 2019-04-03 23:03:12+00:00 - - - Dave Scotese 2019-04-03 21:39:32+00:00 - - - James O'Beirne 2019-04-03 19:51:32+00:00 - - - Ethan Scruples 2019-04-03 15:39:29+00:00 - - - Luke Dashjr 2019-04-03 09:55:26+00:00 - - - Nicolas Dorier 2019-04-03 07:51:04+00:00 - - - Jonas Schnelli 2019-04-03 06:37:31+00:00 - - - James O'Beirne 2019-04-02 20:43:11+00:00 - + 2025-09-26T15:44:23.195031+00:00 + python-feedgen + + + [bitcoin-dev] assumeutxo and UTXO snapshots James O'Beirne + 2019-04-02T20:43:00.000Z + + + Jonas Schnelli + 2019-04-03T06:37:00.000Z + + + Nicolas Dorier + 2019-04-03T07:51:00.000Z + + + Luke Dashjr + 2019-04-03T09:55:00.000Z + + + Ethan Scruples + 2019-04-03T15:39:00.000Z + + + James O'Beirne + 2019-04-03T19:51:00.000Z + + + Dave Scotese + 2019-04-03T21:39:00.000Z + + + Jim Posen + 2019-04-03T23:03:00.000Z + + + Luke Dashjr + 2019-04-04T02:48:00.000Z + + + Luke Dashjr + 2019-04-04T03:01:00.000Z + + + Ethan Scruples + 2019-04-04T03:04:00.000Z + + + Jim Posen + 2019-04-04T05:59:00.000Z + + + Kulpreet Singh + 2019-04-04T10:27:00.000Z + + + James O'Beirne + 2019-04-04T14:36:00.000Z + + + Peter Todd + 2019-04-13T19:09:00.000Z + + + Omar Shibli + 2019-04-14T13:16:00.000Z + + + Dave Scotese + 2019-04-15T00:44:00.000Z + + + James O'Beirne + 2019-04-23T14:17:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - assumeutxo and UTXO snapshots - 2023-08-02T00:41:44.233181+00:00 + 2025-09-26T15:44:23.196863+00:00 - The propose of assumeutxo is to provide an alternative to SPV modes for clients with resource constraints. These clients, running on modest hardware and limited bandwidth, face challenges during initial block download. Currently, they rely on the SPV trust model due to the unrealistic nature of having fully validating clients. Assumeutxo aims to address this issue by allowing nodes to initialize using a serialized version of the UTXO set rendered by another node at a predetermined height.By syncing the headers chain from the network and loading one of these UTXO snapshots, the initializing node can quickly reconstruct its chainstate. It then compares the resulting UTXO set's hash to a preordained hash hard-coded in the software, similar to assumevalid. This process provides a security model that closely resembles full validation within minutes instead of hours or days.However, there are practical security risks associated with assumeutxo. If an attacker convinces a user to accept a malicious `-assumeutxo` parameter and provides them with a false UTXO snapshot, the user could be tricked into transacting under a false history. To mitigate this risk, it is recommended not to allow the specification of assumeutxo via a command-line argument.There have been discussions and proposals regarding the use of memorable features in the Bitcoin consensus to provide anti-sybil-attack checking. Some suggest tying these features to work-intensive results, such as the ratio of the hash to the target. However, others argue against using hash size as a basis for identification, as it may confuse people about how the Bitcoin consensus works. Similarly, there have been suggestions to use the ratio of block hash to difficulty requirement as a way to identify "special" blocks, but this idea is also met with skepticism.The feasibility and implications of assumeutxo and UTXO commitments have been discussed on the Bitcoin-dev mailing list. While assumeutxo could enable mobile devices to function as fully validating nodes, providing faster startup using a small accumulator instead of a multi-GB snapshot, there are significant security implications involved. Some propose soft forking mandatory UTXO commitments into Bitcoin to avoid a growing Initial Block Download (IBD), but others disagree, emphasizing the dangers and arguing against adding UTXO commitments to Bitcoin.In addition to these technical discussions, there have been suggestions about learning C++ and auditing the Bitcoin Core codebase to ensure the security of assumeutxo. The author also mentions their involvement in various projects and provides links related to Bitcoin development.Overall, these discussions and proposals aim to improve the usability, security, and efficiency of the Bitcoin network, particularly in terms of validation processes and mobile device integration. However, there are important considerations and risks that need to be addressed before implementing these changes. Concrete plans for deployment steps are expected to be discussed in the Github issue related to assumeutxo's implementation. 2019-04-23T14:17:06+00:00 + The propose of assumeutxo is to provide an alternative to SPV modes for clients with resource constraints. These clients, running on modest hardware and limited bandwidth, face challenges during initial block download. Currently, they rely on the SPV trust model due to the unrealistic nature of having fully validating clients. Assumeutxo aims to address this issue by allowing nodes to initialize using a serialized version of the UTXO set rendered by another node at a predetermined height.By syncing the headers chain from the network and loading one of these UTXO snapshots, the initializing node can quickly reconstruct its chainstate. It then compares the resulting UTXO set's hash to a preordained hash hard-coded in the software, similar to assumevalid. This process provides a security model that closely resembles full validation within minutes instead of hours or days.However, there are practical security risks associated with assumeutxo. If an attacker convinces a user to accept a malicious `-assumeutxo` parameter and provides them with a false UTXO snapshot, the user could be tricked into transacting under a false history. To mitigate this risk, it is recommended not to allow the specification of assumeutxo via a command-line argument.There have been discussions and proposals regarding the use of memorable features in the Bitcoin consensus to provide anti-sybil-attack checking. Some suggest tying these features to work-intensive results, such as the ratio of the hash to the target. However, others argue against using hash size as a basis for identification, as it may confuse people about how the Bitcoin consensus works. Similarly, there have been suggestions to use the ratio of block hash to difficulty requirement as a way to identify "special" blocks, but this idea is also met with skepticism.The feasibility and implications of assumeutxo and UTXO commitments have been discussed on the Bitcoin-dev mailing list. While assumeutxo could enable mobile devices to function as fully validating nodes, providing faster startup using a small accumulator instead of a multi-GB snapshot, there are significant security implications involved. Some propose soft forking mandatory UTXO commitments into Bitcoin to avoid a growing Initial Block Download (IBD), but others disagree, emphasizing the dangers and arguing against adding UTXO commitments to Bitcoin.In addition to these technical discussions, there have been suggestions about learning C++ and auditing the Bitcoin Core codebase to ensure the security of assumeutxo. The author also mentions their involvement in various projects and provides links related to Bitcoin development.Overall, these discussions and proposals aim to improve the usability, security, and efficiency of the Bitcoin network, particularly in terms of validation processes and mobile device integration. However, there are important considerations and risks that need to be addressed before implementing these changes. Concrete plans for deployment steps are expected to be discussed in the Github issue related to assumeutxo's implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2019/combined_new-BIP-Self-balancing-between-excessively-low-high-fees-and-block-size.xml b/static/bitcoin-dev/April_2019/combined_new-BIP-Self-balancing-between-excessively-low-high-fees-and-block-size.xml index 6713fc962a..b6bc448d58 100644 --- a/static/bitcoin-dev/April_2019/combined_new-BIP-Self-balancing-between-excessively-low-high-fees-and-block-size.xml +++ b/static/bitcoin-dev/April_2019/combined_new-BIP-Self-balancing-between-excessively-low-high-fees-and-block-size.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - new BIP: Self balancing between excessively low/high fees and block size - 2023-08-02T00:42:35.763198+00:00 - - simondev1 2019-04-12 15:49:57+00:00 - - - simondev1 2019-04-12 15:45:25+00:00 - - - Omar Shibli 2019-04-09 00:13:21+00:00 - - - ZmnSCPxj 2019-04-08 00:55:18+00:00 - - - Bernd Jendrissek 2019-04-07 22:11:55+00:00 - - - Natanael 2019-04-07 18:52:30+00:00 - - - simondev1 2019-04-07 08:50:46+00:00 - + 2025-09-26T15:44:18.973696+00:00 + python-feedgen + + + [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size simondev1 + 2019-04-07T08:50:00.000Z + + + Natanael + 2019-04-07T18:52:00.000Z + + + Bernd Jendrissek + 2019-04-07T22:11:00.000Z + + + ZmnSCPxj + 2019-04-08T00:55:00.000Z + + + Omar Shibli + 2019-04-09T00:13:00.000Z + + + simondev1 + 2019-04-12T15:45:00.000Z + + + simondev1 + 2019-04-12T15:49:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - new BIP: Self balancing between excessively low/high fees and block size - 2023-08-02T00:42:35.763198+00:00 + 2025-09-26T15:44:18.974506+00:00 - I'm sorry, but there is no context provided for me to generate a summary. Can you please provide more information? 2019-04-12T15:49:57+00:00 + I'm sorry, but there is no context provided for me to generate a summary. Can you please provide more information? - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_Academic-research-regarding-BIP0002.xml b/static/bitcoin-dev/April_2020/combined_Academic-research-regarding-BIP0002.xml index 4541b8901a..c1f23f4c99 100644 --- a/static/bitcoin-dev/April_2020/combined_Academic-research-regarding-BIP0002.xml +++ b/static/bitcoin-dev/April_2020/combined_Academic-research-regarding-BIP0002.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Academic research regarding BIP0002 - 2023-08-02T02:04:50.699384+00:00 - - Shiva Jairam 2020-04-22 12:48:56+00:00 - - - nopara73 2020-04-22 11:38:37+00:00 - - - Shiva Jairam 2020-04-21 20:28:55+00:00 - + 2025-09-26T15:32:54.527433+00:00 + python-feedgen + + + [bitcoin-dev] Academic research regarding BIP0002 Shiva Jairam + 2020-04-21T20:28:00.000Z + + + nopara73 + 2020-04-22T11:38:00.000Z + + + Shiva Jairam + 2020-04-22T12:48:00.000Z + + - python-feedgen + 2 Combined summary - Academic research regarding BIP0002 - 2023-08-02T02:04:50.699384+00:00 + 2025-09-26T15:32:54.528019+00:00 - In a recent email thread on the bitcoin-dev mailing list, Shiva Jairam has requested feedback on his project. The project involves mapping out BIP002 into a business process model using BPMN2.0. Shiva, who is not an expert in Blockchain or Bitcoin, emphasizes that this is an academic research project and he is seeking guidance from experts in the field. He has shared a link to the concept model he has created so far and is looking for review or discussion.Nopara73, another member of the mailing list, responds with a tip, suggesting that sharing the work first would help others understand the scope of the project and potentially encourage more people to provide assistance. Shiva Jairam clarifies his intentions and requests anyone willing to review or discuss his model to come forward. He also asks for guidance on where to seek help if the bitcoin-dev mailing list is not the appropriate platform.The email thread includes links to BIP0002 on Github and the bitcoin-dev mailing list. Shiva Jairam's request for feedback on his project, which involves mapping out BIP002 into a business process model using BPMN2.0, is part of an academic research endeavor. Despite not being an expert in Blockchain or Bitcoin, he is actively seeking assistance and guidance from experts in the field. If the bitcoin-dev mailing list is not the appropriate platform for such discussions, Shiva is open to suggestions on where to seek help. 2020-04-22T12:48:56+00:00 + In a recent email thread on the bitcoin-dev mailing list, Shiva Jairam has requested feedback on his project. The project involves mapping out BIP002 into a business process model using BPMN2.0. Shiva, who is not an expert in Blockchain or Bitcoin, emphasizes that this is an academic research project and he is seeking guidance from experts in the field. He has shared a link to the concept model he has created so far and is looking for review or discussion.Nopara73, another member of the mailing list, responds with a tip, suggesting that sharing the work first would help others understand the scope of the project and potentially encourage more people to provide assistance. Shiva Jairam clarifies his intentions and requests anyone willing to review or discuss his model to come forward. He also asks for guidance on where to seek help if the bitcoin-dev mailing list is not the appropriate platform.The email thread includes links to BIP0002 on Github and the bitcoin-dev mailing list. Shiva Jairam's request for feedback on his project, which involves mapping out BIP002 into a business process model using BPMN2.0, is part of an academic research endeavor. Despite not being an expert in Blockchain or Bitcoin, he is actively seeking assistance and guidance from experts in the field. If the bitcoin-dev mailing list is not the appropriate platform for such discussions, Shiva is open to suggestions on where to seek help. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_BIP-341-Committing-to-all-scriptPubKeys-in-the-signature-message.xml b/static/bitcoin-dev/April_2020/combined_BIP-341-Committing-to-all-scriptPubKeys-in-the-signature-message.xml index 7e2511abbf..ad7b5d41be 100644 --- a/static/bitcoin-dev/April_2020/combined_BIP-341-Committing-to-all-scriptPubKeys-in-the-signature-message.xml +++ b/static/bitcoin-dev/April_2020/combined_BIP-341-Committing-to-all-scriptPubKeys-in-the-signature-message.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - BIP-341: Committing to all scriptPubKeys in the signature message - 2023-08-02T02:08:51.329382+00:00 - - Pieter Wuille 2020-05-11 22:12:33+00:00 - - - Jonas Nick 2020-05-05 10:20:18+00:00 - - - Andrew Kozlik 2020-05-04 15:48:00+00:00 - - - Russell O'Connor 2020-05-02 21:15:51+00:00 - - - Russell O'Connor 2020-05-02 14:43:13+00:00 - - - Anthony Towns 2020-05-02 14:26:02+00:00 - - - David A. Harding 2020-05-02 12:53:12+00:00 - - - Jeremy 2020-05-02 04:35:41+00:00 - - - Greg Sanders 2020-05-01 12:25:53+00:00 - - - Russell O'Connor 2020-05-01 12:23:07+00:00 - - - Andrew Kozlik 2020-05-01 08:48:41+00:00 - - - Jeremy 2020-05-01 06:57:09+00:00 - - - Andrew Kozlik 2020-04-29 14:57:46+00:00 - + 2025-09-26T15:32:52.436834+00:00 + python-feedgen + + + [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message Andrew Kozlik + 2020-04-29T14:57:00.000Z + + + Jeremy + 2020-05-01T06:57:00.000Z + + + Andrew Kozlik + 2020-05-01T08:48:00.000Z + + + Russell O'Connor + 2020-05-01T12:23:00.000Z + + + Greg Sanders + 2020-05-01T12:25:00.000Z + + + Jeremy + 2020-05-02T04:35:00.000Z + + + David A. Harding + 2020-05-02T12:53:00.000Z + + + Anthony Towns + 2020-05-02T14:26:00.000Z + + + Russell O'Connor + 2020-05-02T14:43:00.000Z + + + Russell O'Connor + 2020-05-02T21:15:00.000Z + + + Andrew Kozlik + 2020-05-04T15:48:00.000Z + + + Jonas Nick + 2020-05-05T10:20:00.000Z + + + Pieter Wuille + 2020-05-11T22:12:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - BIP-341: Committing to all scriptPubKeys in the signature message - 2023-08-02T02:08:51.329382+00:00 + 2025-09-26T15:32:52.438427+00:00 - Pieter Wuille, a Bitcoin Core developer, has proposed a change to the existing BIP341 and BIP342. This change aims to improve the ability of signers to determine whether they can safely sign with only O(1) information per input. The current model poses limitations as in some cases signers may need to be provided with the entire creating transaction. Wuille supports AJ's approach, which does not increase per-signature hashing while retaining the ability to cache information across BIP141/BIP341. Coinbaseness and height are also being considered, but Wuille believes their utility is low.The proposed amendment to BIP-341 suggests committing to the scriptPubKeys of all transaction inputs instead of just the output being spent. This change is aimed at improving the reliability of determining ownership of external inputs, particularly in applications like CoinJoin where transactions contain external inputs. Without this mechanism, an adversary could display incorrect information about the amount being spent, resulting in theft of user funds. The proposed solution commits to every spent scriptPubKey and therefore every element of the TxOut instead of just the amount. Committing to the input values in the transaction digest would allow for compact fee proofs, and the same reasoning applies to scriptPubKeys. Coinjoin with offline signers would be substantially harder without this proposal.The proposal being discussed is related to the inclusion of sha_scriptPubKeys in a transaction's signature message. However, this would limit some use cases where SIGHASH_ALL behavior is not required. The proposal suggests that sha_scriptPubKeys should only be included if hash_type does not match SIGHASH_ANYONECANPAY. The context also highlights an attack scenario in CoinJoin transactions where the attacker can construct a transaction with two inputs and outputs of identical value, one belonging to the user and another to the attacker. As an alternative proposal, it is suggested that a separate BIP for new sigash flags be created. Additionally, the email mentions the importance of including the scriptPubKey to verify the ownership proof signature. Finally, the email describes how adding the height of the coin to the signature message would constitute a change of a different caliber and is not currently proposed.In an email exchange, Anthony Towns raises concerns about missing information in Bitcoin transactions, specifically the height of a coin and whether it is a Coinbase output. He suggests that committing to the coinbase flag might have some use, but cautions against adding the height of the coin as it would make it hard to chain unconfirmed spends. In a discussion about verifying output scriptPubKeys in Bitcoin transactions, it is pointed out that not verifying these keys would limit one's ability to track where funds went. The current design of sharing the hashOutputs value with BIP-143 is seen as a valuable property to maintain.Russell O'Connor suggests separating the hashes of the ScriptPubKeys from the input values in sha_scriptPubKeys, while Andrew's suggestion to add another hash to the signature message for sha_scriptPubKeys achieves this. They could also make the scriptPubKey field dependent on hash_type matching ANYONECANPAY, which would mean committing to each component of the UTXOs being spent. Russell O'Connor also proposed separating the hashing of the output values from the output ScriptPubKeys in sha_outputs so that applications interested only in summing the values of the outputs do not have to wade through those arbitrary long ScriptPubKeys in the outputs.Andrew Kozlik discusses the need for a wallet to ascertain non-ownership of an external input by obtaining the scriptPubKey of the previous output spent by the input. He mentions the impracticality of checking whether a scriptPubKey contains any of the possible two billion keys in a specific BIP32 derivation path. Greg Saunders' scheme can be used as an alternative, which requires one-way communication from a signing device to a coordinator.In a Bitcoin development discussion, Andrew Kozlik proposed a modification to the signature message of BIP-0341. He suggested that the signature message should commit to the scriptPubKeys of all transaction inputs, rather than just the scriptPubKey of the output being spent. This proposal is motivated by the need for wallets in situations such as CoinJoin to accurately determine if an input belongs to the wallet or not, in order to calculate the actual amount being spent by the user.The proposed solution involves adding another hash to the signature message: sha_scriptPubKeys (32). This hash would be the SHA256 of the serialization of all scriptPubKeys of the previous outputs spent by the transaction. By including this hash, wallets would be able to reliably determine for each input whether it belongs to the wallet or not, ensuring the accuracy of the amount being spent.Jeremy Rubin responded to Andrew's proposal by suggesting that using SIGHASH_ALL would sign the COutPoints of all inputs, eliminating the need for signing any additional data. Additionally, he proposed using the metadata protocol to provide all input transactions for checking the 2020-05-11T22:12:33+00:00 + Pieter Wuille, a Bitcoin Core developer, has proposed a change to the existing BIP341 and BIP342. This change aims to improve the ability of signers to determine whether they can safely sign with only O(1) information per input. The current model poses limitations as in some cases signers may need to be provided with the entire creating transaction. Wuille supports AJ's approach, which does not increase per-signature hashing while retaining the ability to cache information across BIP141/BIP341. Coinbaseness and height are also being considered, but Wuille believes their utility is low.The proposed amendment to BIP-341 suggests committing to the scriptPubKeys of all transaction inputs instead of just the output being spent. This change is aimed at improving the reliability of determining ownership of external inputs, particularly in applications like CoinJoin where transactions contain external inputs. Without this mechanism, an adversary could display incorrect information about the amount being spent, resulting in theft of user funds. The proposed solution commits to every spent scriptPubKey and therefore every element of the TxOut instead of just the amount. Committing to the input values in the transaction digest would allow for compact fee proofs, and the same reasoning applies to scriptPubKeys. Coinjoin with offline signers would be substantially harder without this proposal.The proposal being discussed is related to the inclusion of sha_scriptPubKeys in a transaction's signature message. However, this would limit some use cases where SIGHASH_ALL behavior is not required. The proposal suggests that sha_scriptPubKeys should only be included if hash_type does not match SIGHASH_ANYONECANPAY. The context also highlights an attack scenario in CoinJoin transactions where the attacker can construct a transaction with two inputs and outputs of identical value, one belonging to the user and another to the attacker. As an alternative proposal, it is suggested that a separate BIP for new sigash flags be created. Additionally, the email mentions the importance of including the scriptPubKey to verify the ownership proof signature. Finally, the email describes how adding the height of the coin to the signature message would constitute a change of a different caliber and is not currently proposed.In an email exchange, Anthony Towns raises concerns about missing information in Bitcoin transactions, specifically the height of a coin and whether it is a Coinbase output. He suggests that committing to the coinbase flag might have some use, but cautions against adding the height of the coin as it would make it hard to chain unconfirmed spends. In a discussion about verifying output scriptPubKeys in Bitcoin transactions, it is pointed out that not verifying these keys would limit one's ability to track where funds went. The current design of sharing the hashOutputs value with BIP-143 is seen as a valuable property to maintain.Russell O'Connor suggests separating the hashes of the ScriptPubKeys from the input values in sha_scriptPubKeys, while Andrew's suggestion to add another hash to the signature message for sha_scriptPubKeys achieves this. They could also make the scriptPubKey field dependent on hash_type matching ANYONECANPAY, which would mean committing to each component of the UTXOs being spent. Russell O'Connor also proposed separating the hashing of the output values from the output ScriptPubKeys in sha_outputs so that applications interested only in summing the values of the outputs do not have to wade through those arbitrary long ScriptPubKeys in the outputs.Andrew Kozlik discusses the need for a wallet to ascertain non-ownership of an external input by obtaining the scriptPubKey of the previous output spent by the input. He mentions the impracticality of checking whether a scriptPubKey contains any of the possible two billion keys in a specific BIP32 derivation path. Greg Saunders' scheme can be used as an alternative, which requires one-way communication from a signing device to a coordinator.In a Bitcoin development discussion, Andrew Kozlik proposed a modification to the signature message of BIP-0341. He suggested that the signature message should commit to the scriptPubKeys of all transaction inputs, rather than just the scriptPubKey of the output being spent. This proposal is motivated by the need for wallets in situations such as CoinJoin to accurately determine if an input belongs to the wallet or not, in order to calculate the actual amount being spent by the user.The proposed solution involves adding another hash to the signature message: sha_scriptPubKeys (32). This hash would be the SHA256 of the serialization of all scriptPubKeys of the previous outputs spent by the transaction. By including this hash, wallets would be able to reliably determine for each input whether it belongs to the wallet or not, ensuring the accuracy of the amount being spent.Jeremy Rubin responded to Andrew's proposal by suggesting that using SIGHASH_ALL would sign the COutPoints of all inputs, eliminating the need for signing any additional data. Additionally, he proposed using the metadata protocol to provide all input transactions for checking the - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_Deterministic-Entropy-From-BIP32-Keychains.xml b/static/bitcoin-dev/April_2020/combined_Deterministic-Entropy-From-BIP32-Keychains.xml index a6ef566878..bffa69e82c 100644 --- a/static/bitcoin-dev/April_2020/combined_Deterministic-Entropy-From-BIP32-Keychains.xml +++ b/static/bitcoin-dev/April_2020/combined_Deterministic-Entropy-From-BIP32-Keychains.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Deterministic Entropy From BIP32 Keychains - 2023-08-02T02:01:39.479479+00:00 - - Ethan Kosakovsky 2020-04-16 17:53:38+00:00 - - - Ethan Kosakovsky 2020-04-11 00:09:51+00:00 - - - Christopher Allen 2020-04-06 21:45:37+00:00 - - - Adam Back 2020-04-06 20:02:00+00:00 - - - Rodolfo Novak 2020-04-06 17:36:17+00:00 - + 2025-09-26T15:32:56.616572+00:00 + python-feedgen + + + [bitcoin-dev] Deterministic Entropy From BIP32 Keychains Rodolfo Novak + 2020-04-06T17:36:00.000Z + + + Adam Back + 2020-04-06T20:02:00.000Z + + + Christopher Allen + 2020-04-06T21:45:00.000Z + + + Ethan Kosakovsky + 2020-04-11T00:09:00.000Z + + + Ethan Kosakovsky + 2020-04-16T17:53:00.000Z + + - python-feedgen + 2 Combined summary - Deterministic Entropy From BIP32 Keychains - 2023-08-02T02:01:39.479479+00:00 + 2025-09-26T15:32:56.617330+00:00 - A user has opened a BIP PR at https://github.com/bitcoin/bips/pull/910 and created a Python library with test vectors referenced in the BIP text. It is unclear whether or not the "Applications" section of the BIP will be split into a separate document or remain in the current BIP.In an email conversation, Ethan discussed his plan to submit a BIP for the deterministic entropy from BIP32 keychains. He had considered this idea previously and let it sit for others to consider as well. He was also considering splitting the BIP into two parts: one for the entropy derivation and another for the applications section. This approach would be similar to how BIP32 serves as the basis for derivation schemes like BIP39, BIP44, BIP49, etc.Rodolfo Novak contacted Ethan to inquire about the assigned BIP number and if there had been any review of the BIP yet. It is unclear if Ethan provided an answer to these questions in his response.Christopher Allen believes that a cryptographic engineering expert, ideally Pieter Wuille, should review the BIP. He thinks this review will suggest improvements and believes that something in this area should be done. He mentions the offline tool #LetheKit provided by BlockchainCommons/bc-lethe-kit as a potential solution. This tool allows users to input their BIP39 from an offline titanium key or SLIP39 Shamir shards and derive a child key in BIP39 form using the LetheKit. The derived key can be delivered via QR from the air-gapped LetheKit to another device.Adam, a member of the bitcoin-dev mailing list, shared his thoughts on the use-case of having an offline seed manager in a recent email. He believes that such a manager can be backed up once and support multiple wallets, solving a practical and under-addressed problem for many users and businesses. He also noted that using a bip39 mnemonic seed as an interface between an offline seed manager and a hardware or software wallet is convenient and an improvement over using custom derivation paths, given the complexity of custom paths and variable support for them in wallets.Rodolfo Novak, via bitcoin-dev, announced plans to implement the Deterministic Entropy From BIP32 Keychains BIP on Coldcard in another email. He asked if there was a planned BIP number and if there had been any review of the BIP yet. The email includes Rodolfo's contact information and GPG signature. 2020-04-16T17:53:38+00:00 + A user has opened a BIP PR at https://github.com/bitcoin/bips/pull/910 and created a Python library with test vectors referenced in the BIP text. It is unclear whether or not the "Applications" section of the BIP will be split into a separate document or remain in the current BIP.In an email conversation, Ethan discussed his plan to submit a BIP for the deterministic entropy from BIP32 keychains. He had considered this idea previously and let it sit for others to consider as well. He was also considering splitting the BIP into two parts: one for the entropy derivation and another for the applications section. This approach would be similar to how BIP32 serves as the basis for derivation schemes like BIP39, BIP44, BIP49, etc.Rodolfo Novak contacted Ethan to inquire about the assigned BIP number and if there had been any review of the BIP yet. It is unclear if Ethan provided an answer to these questions in his response.Christopher Allen believes that a cryptographic engineering expert, ideally Pieter Wuille, should review the BIP. He thinks this review will suggest improvements and believes that something in this area should be done. He mentions the offline tool #LetheKit provided by BlockchainCommons/bc-lethe-kit as a potential solution. This tool allows users to input their BIP39 from an offline titanium key or SLIP39 Shamir shards and derive a child key in BIP39 form using the LetheKit. The derived key can be delivered via QR from the air-gapped LetheKit to another device.Adam, a member of the bitcoin-dev mailing list, shared his thoughts on the use-case of having an offline seed manager in a recent email. He believes that such a manager can be backed up once and support multiple wallets, solving a practical and under-addressed problem for many users and businesses. He also noted that using a bip39 mnemonic seed as an interface between an offline seed manager and a hardware or software wallet is convenient and an improvement over using custom derivation paths, given the complexity of custom paths and variable support for them in wallets.Rodolfo Novak, via bitcoin-dev, announced plans to implement the Deterministic Entropy From BIP32 Keychains BIP on Coldcard in another email. He asked if there was a planned BIP number and if there had been any review of the BIP yet. The email includes Rodolfo's contact information and GPG signature. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_Fwd-Semi-Traceless-2-party-coinjoin-off-chain-protocol-using-schnorr-signatures.xml b/static/bitcoin-dev/April_2020/combined_Fwd-Semi-Traceless-2-party-coinjoin-off-chain-protocol-using-schnorr-signatures.xml index d8b57e8480..8b3d439db5 100644 --- a/static/bitcoin-dev/April_2020/combined_Fwd-Semi-Traceless-2-party-coinjoin-off-chain-protocol-using-schnorr-signatures.xml +++ b/static/bitcoin-dev/April_2020/combined_Fwd-Semi-Traceless-2-party-coinjoin-off-chain-protocol-using-schnorr-signatures.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures - 2023-08-02T02:05:31.929016+00:00 - - ZmnSCPxj 2020-05-04 08:28:41+00:00 - - - Chris Belcher 2020-05-03 19:28:23+00:00 - - - ZmnSCPxj 2020-05-01 07:17:19+00:00 - - - Chris Belcher 2020-04-30 17:18:03+00:00 - - - ZmnSCPxj 2020-04-30 08:54:28+00:00 - - - Chris Belcher 2020-04-29 15:06:01+00:00 - - - ZmnSCPxj 2020-04-29 07:56:16+00:00 - - - Chris Belcher 2020-04-28 13:03:36+00:00 - - - German Luna 2020-04-24 13:42:12+00:00 - - - ZmnSCPxj 2020-04-24 01:34:51+00:00 - - - German Luna 2020-04-23 18:40:06+00:00 - - - ZmnSCPxj 2020-04-23 17:56:08+00:00 - - - German Luna 2020-04-22 18:42:18+00:00 - + 2025-09-26T15:32:58.741678+00:00 + python-feedgen + + + [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures German Luna + 2020-04-22T18:42:00.000Z + + + ZmnSCPxj + 2020-04-23T17:56:00.000Z + + + German Luna + 2020-04-23T18:40:00.000Z + + + ZmnSCPxj + 2020-04-24T01:34:00.000Z + + + German Luna + 2020-04-24T13:42:00.000Z + + + Chris Belcher + 2020-04-28T13:03:00.000Z + + + ZmnSCPxj + 2020-04-29T07:56:00.000Z + + + Chris Belcher + 2020-04-29T15:06:00.000Z + + + ZmnSCPxj + 2020-04-30T08:54:00.000Z + + + Chris Belcher + 2020-04-30T17:18:00.000Z + + + ZmnSCPxj + 2020-05-01T07:17:00.000Z + + + Chris Belcher + 2020-05-03T19:28:00.000Z + + + ZmnSCPxj + 2020-05-04T08:28:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures - 2023-08-02T02:05:31.929016+00:00 + 2025-09-26T15:32:58.743152+00:00 - CoinSwap is a Bitcoin protocol that aims to improve privacy in transactions. However, there are limitations to the current approach of using CoinSwap with mixdepths. While mixdepths can protect against co-spending inputs, they may not be necessary for multi-transaction CoinSwaps where no coins are merged. If coins need to be merged, it is suggested that they should be in the same mixdepth.To address the issue of 1-input-1-output transactions being markers, a proposal is made to use a PayJoin construction for the second transaction. Additionally, Alice can spend her UTXOs in 2-output transactions and manipulate the change output detection heuristics to enhance privacy.The concept of private key turnover in CoinSwap is discussed, which involves turning over bilateral control to the swap partner after exchanging the swap secret. This allows for more flexibility and efficiency in the transaction process. Bob, the maker, can merge transactions without coordination with Alice and can fee bump using RBF instead of CPFP, reducing blockchain space usage.In terms of privacy, the conversation highlights the use of false positives in creating a large number of sets of transactions that add up to a certain value by chance, making it difficult for adversaries to identify the user's transactions. Standardized swap amounts are suggested to increase anonymity sets, and the distribution of output values on the blockchain is considered as a factor in achieving privacy.Overall, CoinSwap is seen as a promising method for improving privacy in Bitcoin transactions. However, there are ongoing discussions and proposals to further enhance its effectiveness and address potential limitations.In another topic of discussion, a protocol for traceless atomic swaps within the same chain is mentioned. This protocol involves using a suitably chosen schnorr signature instead of the secret 't' typically used in atomic swaps. The protocol enables parties to exchange funds without revealing their transaction histories.To perform the atomic swap, Alice and Bob provide each other with public keys and create P2PKH addresses where the funds will eventually be sent. They exchange time-locked refund transactions for the funding transactions, and adaptor signatures are used to validate the spending from these addresses. Steps are taken to ensure that the funds cannot be separated or claimed prematurely, while maintaining plausible deniability as the joint private keys are not accessible.The email suggests reaching out to experts in privacy tech for further insights and mentions specific individuals such as belcher, waxwing, and nopara73. Feedback is encouraged, and the author emphasizes the need for consultation with experts to gather more information on these topics. 2020-05-04T08:28:41+00:00 + CoinSwap is a Bitcoin protocol that aims to improve privacy in transactions. However, there are limitations to the current approach of using CoinSwap with mixdepths. While mixdepths can protect against co-spending inputs, they may not be necessary for multi-transaction CoinSwaps where no coins are merged. If coins need to be merged, it is suggested that they should be in the same mixdepth.To address the issue of 1-input-1-output transactions being markers, a proposal is made to use a PayJoin construction for the second transaction. Additionally, Alice can spend her UTXOs in 2-output transactions and manipulate the change output detection heuristics to enhance privacy.The concept of private key turnover in CoinSwap is discussed, which involves turning over bilateral control to the swap partner after exchanging the swap secret. This allows for more flexibility and efficiency in the transaction process. Bob, the maker, can merge transactions without coordination with Alice and can fee bump using RBF instead of CPFP, reducing blockchain space usage.In terms of privacy, the conversation highlights the use of false positives in creating a large number of sets of transactions that add up to a certain value by chance, making it difficult for adversaries to identify the user's transactions. Standardized swap amounts are suggested to increase anonymity sets, and the distribution of output values on the blockchain is considered as a factor in achieving privacy.Overall, CoinSwap is seen as a promising method for improving privacy in Bitcoin transactions. However, there are ongoing discussions and proposals to further enhance its effectiveness and address potential limitations.In another topic of discussion, a protocol for traceless atomic swaps within the same chain is mentioned. This protocol involves using a suitably chosen schnorr signature instead of the secret 't' typically used in atomic swaps. The protocol enables parties to exchange funds without revealing their transaction histories.To perform the atomic swap, Alice and Bob provide each other with public keys and create P2PKH addresses where the funds will eventually be sent. They exchange time-locked refund transactions for the funding transactions, and adaptor signatures are used to validate the spending from these addresses. Steps are taken to ensure that the funds cannot be separated or claimed prematurely, while maintaining plausible deniability as the joint private keys are not accessible.The email suggests reaching out to experts in privacy tech for further insights and mentions specific individuals such as belcher, waxwing, and nopara73. Feedback is encouraged, and the author emphasizes the need for consultation with experts to gather more information on these topics. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_PSBT-in-QR-codes.xml b/static/bitcoin-dev/April_2020/combined_PSBT-in-QR-codes.xml index 8802290582..9073c7f638 100644 --- a/static/bitcoin-dev/April_2020/combined_PSBT-in-QR-codes.xml +++ b/static/bitcoin-dev/April_2020/combined_PSBT-in-QR-codes.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - PSBT in QR codes - 2023-08-02T02:07:18.778919+00:00 - - Christopher Allen 2020-04-28 01:47:26+00:00 - - - Riccardo Casatta 2020-04-27 20:11:43+00:00 - + 2025-09-26T15:33:05.046858+00:00 + python-feedgen + + + [bitcoin-dev] PSBT in QR codes Riccardo Casatta + 2020-04-27T20:11:00.000Z + + + Christopher Allen + 2020-04-28T01:47:00.000Z + + - python-feedgen + 2 Combined summary - PSBT in QR codes - 2023-08-02T02:07:18.778919+00:00 + 2025-09-26T15:33:05.047283+00:00 - The discussion on finding a common QR code compatible format for Partially Signed Bitcoin Transactions (PSBT) has been moved to the BlockchainCommons/AirgappedSigning repository from the specter-diy repository. This move was made to prevent overwhelming the former repository and provide a dedicated space for sharing examples and prototypes until a consensus can be reached among wallet developers. Christopher Allen shared this information in response to a post by Riccardo Casatta on the bitcoin-dev forum, which included a link to the relevant GitHub issue.The focus of the discussion revolves around how to encode PSBT in QR codes. While a version 40 QR code specification allows up to 3706 bytes of data, the practical limitations and potential size of a PSBT make it impossible to fit in a single QR code. Several proposals have been put forth, including animated QR codes and alphanumeric mode with custom headers for data reconstruction. However, these suggestions come with drawbacks such as printing difficulties, uncertainty regarding data transfer, and compatibility issues with older hardware.In light of these challenges, the author proposes the use of binary encoding and structured append. This approach allows for chaining up to 16 QR codes with 1 byte of parity. Although there are concerns about the support for structured append in QR code libraries, the widely used zxing library on Android and the Apple built-in scanner both offer access to the scanned raw bytes, enabling the parsing of the structured append header.Despite some downsides, binary encoding and structured append offer several advantages. These include efficient encoding, copypaste functionality, and compatibility with bech32. By adopting this approach, the hope is to find a solution that addresses the limitations of other proposals while still allowing for the effective use of QR codes in the context of PSBT. 2020-04-28T01:47:26+00:00 + The discussion on finding a common QR code compatible format for Partially Signed Bitcoin Transactions (PSBT) has been moved to the BlockchainCommons/AirgappedSigning repository from the specter-diy repository. This move was made to prevent overwhelming the former repository and provide a dedicated space for sharing examples and prototypes until a consensus can be reached among wallet developers. Christopher Allen shared this information in response to a post by Riccardo Casatta on the bitcoin-dev forum, which included a link to the relevant GitHub issue.The focus of the discussion revolves around how to encode PSBT in QR codes. While a version 40 QR code specification allows up to 3706 bytes of data, the practical limitations and potential size of a PSBT make it impossible to fit in a single QR code. Several proposals have been put forth, including animated QR codes and alphanumeric mode with custom headers for data reconstruction. However, these suggestions come with drawbacks such as printing difficulties, uncertainty regarding data transfer, and compatibility issues with older hardware.In light of these challenges, the author proposes the use of binary encoding and structured append. This approach allows for chaining up to 16 QR codes with 1 byte of parity. Although there are concerns about the support for structured append in QR code libraries, the widely used zxing library on Android and the Apple built-in scanner both offer access to the scanned raw bytes, enabling the parsing of the structured append header.Despite some downsides, binary encoding and structured append offer several advantages. These include efficient encoding, copypaste functionality, and compatibility with bech32. By adopting this approach, the hope is to find a solution that addresses the limitations of other proposals while still allowing for the effective use of QR codes in the context of PSBT. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_RBF-Pinning-with-Counterparties-and-Competing-Interest.xml b/static/bitcoin-dev/April_2020/combined_RBF-Pinning-with-Counterparties-and-Competing-Interest.xml index 356fe8bc46..c754631fc3 100644 --- a/static/bitcoin-dev/April_2020/combined_RBF-Pinning-with-Counterparties-and-Competing-Interest.xml +++ b/static/bitcoin-dev/April_2020/combined_RBF-Pinning-with-Counterparties-and-Competing-Interest.xml @@ -1,125 +1,103 @@ - + 2 Combined summary - RBF Pinning with Counterparties and Competing Interest - 2023-08-02T02:03:13.395560+00:00 - - Matt Corallo 2020-06-24 08:32:52+00:00 - - - Bastien TEINTURIER 2020-06-22 08:25:09+00:00 - - - ZmnSCPxj 2020-06-22 08:15:37+00:00 - - - Bastien TEINTURIER 2020-06-22 07:35:20+00:00 - - - ZmnSCPxj 2020-06-21 02:10:32+00:00 - - - ZmnSCPxj 2020-06-20 16:01:16+00:00 - - - David A. Harding 2020-06-20 10:36:47+00:00 - - - Bastien TEINTURIER 2020-06-20 08:54:03+00:00 - - - David A. Harding 2020-06-19 20:52:20+00:00 - - - David A. Harding 2020-06-19 19:58:46+00:00 - - - Bastien TEINTURIER 2020-06-19 07:44:11+00:00 - - - Rusty Russell 2020-04-27 21:26:19+00:00 - - - Matt Corallo 2020-04-23 22:47:46+00:00 - - - ZmnSCPxj 2020-04-23 12:52:57+00:00 - - - ZmnSCPxj 2020-04-23 12:46:59+00:00 - - - David A. Harding 2020-04-23 09:59:57+00:00 - - - Matt Corallo 2020-04-23 06:21:50+00:00 - - - ZmnSCPxj 2020-04-23 04:50:09+00:00 - - - Jeremy 2020-04-23 01:18:05+00:00 - - - Matt Corallo 2020-04-23 01:10:47+00:00 - - - Olaoluwa Osuntokun 2020-04-22 23:27:49+00:00 - - - Matt Corallo 2020-04-22 23:20:03+00:00 - - - Olaoluwa Osuntokun 2020-04-22 23:13:01+00:00 - - - Olaoluwa Osuntokun 2020-04-22 23:11:08+00:00 - - - Olaoluwa Osuntokun 2020-04-22 23:05:17+00:00 - - - Matt Corallo 2020-04-22 22:53:37+00:00 - - - David A. Harding 2020-04-22 20:28:13+00:00 - - - Antoine Riard 2020-04-22 19:03:29+00:00 - - - David A. Harding 2020-04-22 18:24:54+00:00 - - - Matt Corallo 2020-04-22 16:56:38+00:00 - - - Matt Corallo 2020-04-22 16:50:46+00:00 - - - David A. Harding 2020-04-22 11:51:30+00:00 - - - Bastien TEINTURIER 2020-04-22 08:55:42+00:00 - - - Antoine Riard 2020-04-22 08:01:23+00:00 - - - ZmnSCPxj 2020-04-22 06:08:06+00:00 - - - Olaoluwa Osuntokun 2020-04-22 04:18:29+00:00 - - - Olaoluwa Osuntokun 2020-04-22 04:13:34+00:00 - - - ZmnSCPxj 2020-04-22 04:12:59+00:00 - - - Matt Corallo 2020-04-21 02:43:14+00:00 - + 2025-09-26T15:33:00.864928+00:00 + python-feedgen + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2020-04-22T04:12:00.000Z + + + Olaoluwa Osuntokun + 2020-04-22T04:18:00.000Z + + + ZmnSCPxj + 2020-04-22T06:08:00.000Z + + + Antoine Riard + 2020-04-22T08:01:00.000Z + + + Bastien TEINTURIER + 2020-04-22T08:55:00.000Z + + + Matt Corallo + 2020-04-22T16:56:00.000Z + + + Olaoluwa Osuntokun + 2020-04-22T23:05:00.000Z + + + Olaoluwa Osuntokun + 2020-04-22T23:11:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2020-04-23T04:50:00.000Z + + + Matt Corallo + 2020-04-23T06:21:00.000Z + + + ZmnSCPxj + 2020-04-23T12:46:00.000Z + + + Matt Corallo + 2020-04-23T22:47:00.000Z + + + Bastien TEINTURIER + 2020-06-19T07:44:00.000Z + + + David A. Harding + 2020-06-19T19:58:00.000Z + + + David A. Harding + 2020-06-19T20:52:00.000Z + + + Bastien TEINTURIER + 2020-06-20T08:54:00.000Z + + + David A. Harding + 2020-06-20T10:36:00.000Z + + + ZmnSCPxj + 2020-06-20T16:01:00.000Z + + + ZmnSCPxj + 2020-06-21T02:10:00.000Z + + + Bastien TEINTURIER + 2020-06-22T07:35:00.000Z + + + ZmnSCPxj + 2020-06-22T08:15:00.000Z + + + Bastien TEINTURIER + 2020-06-22T08:25:00.000Z + + + Matt Corallo + 2020-06-24T08:32:00.000Z + + @@ -159,13 +137,13 @@ - python-feedgen + 2 Combined summary - RBF Pinning with Counterparties and Competing Interest - 2023-08-02T02:03:13.395560+00:00 + 2025-09-26T15:33:00.867307+00:00 - The conversations and email threads discussed various proposals and concerns related to the Lightning Network, mempool evictions, double-spend attacks, HTLC spends, and policy rules. One proposal involved bribing miners for knowledge, but it was acknowledged that additional software and complexity would be needed. There were discussions about limiting low-fee-rate packages in the mempool, marking transactions as "likely-to-be-RBF'ed", and potential changes to the Poon-Dryja channels contract text. Increasing development resources to address mempool issues was emphasized. The lightning network community explored solutions such as mempool-watching and the use of anchor outputs. Concerns were raised about computational complexity, bidding wars, and the choice of internal data structures. The economic rationality of accepting higher fee rate packages and the challenges of monitoring the global mempool were also discussed. Overall, the discussions highlighted ongoing efforts to improve the efficiency and security of the Lightning Network and address various challenges and vulnerabilities.The discussion on the Lightning-dev mailing list focused on a potential vulnerability in the Bitcoin Lightning Network's hash locked time contracts (HTLC). The vulnerability arises when a transaction from party A to party C has already timed out, allowing party B and C to engage in a bidding war with miners to get their version of the transaction committed on-chain. To mitigate this, party B must ensure that the HTLC-Timeout is committed on-chain before the timeout, preventing the bidding war from starting. A proposed solution involves using `OP_CHECKSEQUENCEVERIFY` to enforce RBF-flagging and allowing B to fee-bump the HTLC-Timeout signature from C with some on-chain funds if the L+1 timeout is approaching. The current anchors proposal enforces a CSV of 1 block before the HTLCs can be spent, further mitigating the attack. However, there are concerns regarding the reliability of the proposed solutions, including the risk of losing money if the remote party broadcasts their version of the commitment without revoking. There are also discussions about using reject messages with extended functionality to handle conflicts in the mempool, but practical design issues and concerns about potential DoS vectors need to be considered.In an email exchange, limitations of Bitcoin contracts with nested trees of transactions were discussed, as well as the use of mempool-watching as a mitigation measure against attacks on Lightning nodes. Suggestions were made to resolve issues such as eliminating the commitment fee guessing game and allowing users to pay less on force close. Different proposals were presented, including pre-signing all HTLC output spends and making them more free-form, but there were concerns about the need for an overhaul in the channel state machine. The enforcement of BIP125 rule 3, which requires each replacement transaction to pay a higher fee rate than the previous one, was also discussed. Two attack vectors on the Lightning Network were mentioned: delaying the confirmation of honest party transactions to provoke an unbalanced settlement for the victim, and a vulnerability in RBF Pinning HTLC Transactions. Suggestions were made to add an RBF carve-out output to HTLC-Timeout or allow for re-signing the B-side signature for a higher-fee version.ZmnSCPxj proposed a mechanism to protect against RBF attacks on HTLC transactions in the Lightning Network. The suggested solution involved confirming HTLC-Timeout on-chain before a certain time to prevent the theft of the HTLC value. Another proposal was to add an RBF carve-out output to HTLC-Timeout or use SIGHASH_NOINPUT to allow for fee-bumping. The limitations of Bitcoin contracts were discussed, as well as the choice of internal data structures and monitoring the global mempool as a mitigation measure for Lightning implementations.The lightning protocol's vulnerability, where a counterparty could steal HTLC funds using a low-fee, RBF-disabled transaction, was highlighted. Solutions were proposed, such as adding an RBF carve-out output to HTLC-Timeout or allowing for fees using SIGHASH_NOINPUT. The Decker-Russell-Osuntokun approach was mentioned as a way to sidestep this issue. Concerns about anchor outputs and the possibility of using RBF Pinning to steal in-flight HTLCs enforced on-chain were also raised. Alternative proposals were suggested to improve the security of the Lightning Network.Overall, the discussions delved into various technical solutions, concerns, and potential attacks related to transaction security, mempool information, and the Lightning Network. Different proposals and suggestions were presented, highlighting the complexities and challenges of ensuring the integrity and efficiency of Bitcoin transactions. 2020-06-24T08:32:52+00:00 + The conversations and email threads discussed various proposals and concerns related to the Lightning Network, mempool evictions, double-spend attacks, HTLC spends, and policy rules. One proposal involved bribing miners for knowledge, but it was acknowledged that additional software and complexity would be needed. There were discussions about limiting low-fee-rate packages in the mempool, marking transactions as "likely-to-be-RBF'ed", and potential changes to the Poon-Dryja channels contract text. Increasing development resources to address mempool issues was emphasized. The lightning network community explored solutions such as mempool-watching and the use of anchor outputs. Concerns were raised about computational complexity, bidding wars, and the choice of internal data structures. The economic rationality of accepting higher fee rate packages and the challenges of monitoring the global mempool were also discussed. Overall, the discussions highlighted ongoing efforts to improve the efficiency and security of the Lightning Network and address various challenges and vulnerabilities.The discussion on the Lightning-dev mailing list focused on a potential vulnerability in the Bitcoin Lightning Network's hash locked time contracts (HTLC). The vulnerability arises when a transaction from party A to party C has already timed out, allowing party B and C to engage in a bidding war with miners to get their version of the transaction committed on-chain. To mitigate this, party B must ensure that the HTLC-Timeout is committed on-chain before the timeout, preventing the bidding war from starting. A proposed solution involves using `OP_CHECKSEQUENCEVERIFY` to enforce RBF-flagging and allowing B to fee-bump the HTLC-Timeout signature from C with some on-chain funds if the L+1 timeout is approaching. The current anchors proposal enforces a CSV of 1 block before the HTLCs can be spent, further mitigating the attack. However, there are concerns regarding the reliability of the proposed solutions, including the risk of losing money if the remote party broadcasts their version of the commitment without revoking. There are also discussions about using reject messages with extended functionality to handle conflicts in the mempool, but practical design issues and concerns about potential DoS vectors need to be considered.In an email exchange, limitations of Bitcoin contracts with nested trees of transactions were discussed, as well as the use of mempool-watching as a mitigation measure against attacks on Lightning nodes. Suggestions were made to resolve issues such as eliminating the commitment fee guessing game and allowing users to pay less on force close. Different proposals were presented, including pre-signing all HTLC output spends and making them more free-form, but there were concerns about the need for an overhaul in the channel state machine. The enforcement of BIP125 rule 3, which requires each replacement transaction to pay a higher fee rate than the previous one, was also discussed. Two attack vectors on the Lightning Network were mentioned: delaying the confirmation of honest party transactions to provoke an unbalanced settlement for the victim, and a vulnerability in RBF Pinning HTLC Transactions. Suggestions were made to add an RBF carve-out output to HTLC-Timeout or allow for re-signing the B-side signature for a higher-fee version.ZmnSCPxj proposed a mechanism to protect against RBF attacks on HTLC transactions in the Lightning Network. The suggested solution involved confirming HTLC-Timeout on-chain before a certain time to prevent the theft of the HTLC value. Another proposal was to add an RBF carve-out output to HTLC-Timeout or use SIGHASH_NOINPUT to allow for fee-bumping. The limitations of Bitcoin contracts were discussed, as well as the choice of internal data structures and monitoring the global mempool as a mitigation measure for Lightning implementations.The lightning protocol's vulnerability, where a counterparty could steal HTLC funds using a low-fee, RBF-disabled transaction, was highlighted. Solutions were proposed, such as adding an RBF carve-out output to HTLC-Timeout or allowing for fees using SIGHASH_NOINPUT. The Decker-Russell-Osuntokun approach was mentioned as a way to sidestep this issue. Concerns about anchor outputs and the possibility of using RBF Pinning to steal in-flight HTLCs enforced on-chain were also raised. Alternative proposals were suggested to improve the security of the Lightning Network.Overall, the discussions delved into various technical solutions, concerns, and potential attacks related to transaction security, mempool information, and the Lightning Network. Different proposals and suggestions were presented, highlighting the complexities and challenges of ensuring the integrity and efficiency of Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_Revault-a-multi-party-vault-architecture.xml b/static/bitcoin-dev/April_2020/combined_Revault-a-multi-party-vault-architecture.xml index baf63c3a7c..6b946aaa92 100644 --- a/static/bitcoin-dev/April_2020/combined_Revault-a-multi-party-vault-architecture.xml +++ b/static/bitcoin-dev/April_2020/combined_Revault-a-multi-party-vault-architecture.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Revault: a multi-party vault architecture - 2023-08-02T02:06:47.849604+00:00 - - darosior 2020-05-08 10:34:49+00:00 - - - darosior 2020-04-24 15:00:16+00:00 - + 2025-09-26T15:32:50.344346+00:00 + python-feedgen + + + [bitcoin-dev] Revault: a multi-party vault architecture darosior + 2020-04-24T15:00:00.000Z + + + darosior + 2020-05-08T10:34:00.000Z + + - python-feedgen + 2 Combined summary - Revault: a multi-party vault architecture - 2023-08-02T02:06:47.849604+00:00 + 2025-09-26T15:32:50.344867+00:00 - Antoine and Kevin have developed a new multiparty vault architecture called Revault, which aims to secure shared storage of coins without relying on a trusted third party and disincentivizing theft attempts. The system uses N-of-N multisigs and relies on pre-signed and revocable transactions. However, it does not protect against intentional locking of funds, so users are expected to solve blockage issues outside the Bitcoin network through legal contracts.Revault utilizes six transaction types: Vault Transaction, Emergency Transaction, Unvault Transaction, Unvault Emergency Transaction, Cancel Transaction, and Spend Transaction. Stakeholders exchange the signatures of all the revaulting transactions after receiving a new vault utxo and then exchange the signatures of the unvaulting transaction before proceeding. Until this process is complete, the coins are not available to be spent.To avoid weak security assumptions, stakeholders exchange SINGLE | ANYONECANPAY signatures for the revaulting transactions and append their own as SIGHASH_ALL before broadcasting. They also have the option to add an additional input (and potentially output) to increase fees. This protection leverages the fact that revaulting transactions only have one input and one output, with the change being part of the spend transaction.In order to cover a feerate increase after broadcast, revaulting transactions may signal for RBF. However, the fee bumping construction is potentially vulnerable to transaction pinning. To address this, ALL | ANYONECANPAY signatures are now exchanged for revaulting transactions, restricting the creation of a new output only spendable by one party.The fee bumping process is now done in two stages to avoid consuming an entire UTXO. If any issues arise, any stakeholder can trigger an emergency transaction at any point.The architecture was first designed by Kevin Loaec, who was hired by NOIA for this purpose. It was inspired by Bryan Bishop's single-party vault architecture. A work-in-progress draft/demo/PoC is available on Github, which uses 4 stakeholders, 2 or 3 traders, a CSV of 6 blocks for the unvault script, and a CSV of approximately 1 month for the emergency scripts. The detailed transactions used can be found in the doc/ directory of the same repository and are coded in the revault/transactions/ module. 2020-05-08T10:34:49+00:00 + Antoine and Kevin have developed a new multiparty vault architecture called Revault, which aims to secure shared storage of coins without relying on a trusted third party and disincentivizing theft attempts. The system uses N-of-N multisigs and relies on pre-signed and revocable transactions. However, it does not protect against intentional locking of funds, so users are expected to solve blockage issues outside the Bitcoin network through legal contracts.Revault utilizes six transaction types: Vault Transaction, Emergency Transaction, Unvault Transaction, Unvault Emergency Transaction, Cancel Transaction, and Spend Transaction. Stakeholders exchange the signatures of all the revaulting transactions after receiving a new vault utxo and then exchange the signatures of the unvaulting transaction before proceeding. Until this process is complete, the coins are not available to be spent.To avoid weak security assumptions, stakeholders exchange SINGLE | ANYONECANPAY signatures for the revaulting transactions and append their own as SIGHASH_ALL before broadcasting. They also have the option to add an additional input (and potentially output) to increase fees. This protection leverages the fact that revaulting transactions only have one input and one output, with the change being part of the spend transaction.In order to cover a feerate increase after broadcast, revaulting transactions may signal for RBF. However, the fee bumping construction is potentially vulnerable to transaction pinning. To address this, ALL | ANYONECANPAY signatures are now exchanged for revaulting transactions, restricting the creation of a new output only spendable by one party.The fee bumping process is now done in two stages to avoid consuming an entire UTXO. If any issues arise, any stakeholder can trigger an emergency transaction at any point.The architecture was first designed by Kevin Loaec, who was hired by NOIA for this purpose. It was inspired by Bryan Bishop's single-party vault architecture. A work-in-progress draft/demo/PoC is available on Github, which uses 4 stakeholders, 2 or 3 traders, a CSV of 6 blocks for the unvault script, and a CSV of approximately 1 month for the emergency scripts. The detailed transactions used can be found in the doc/ directory of the same repository and are coded in the revault/transactions/ module. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_Sorting-outputs-of-a-transaction-in-alphabetic-order-to-protect-privacy.xml b/static/bitcoin-dev/April_2020/combined_Sorting-outputs-of-a-transaction-in-alphabetic-order-to-protect-privacy.xml index 30c2714fab..c5ce3a04d1 100644 --- a/static/bitcoin-dev/April_2020/combined_Sorting-outputs-of-a-transaction-in-alphabetic-order-to-protect-privacy.xml +++ b/static/bitcoin-dev/April_2020/combined_Sorting-outputs-of-a-transaction-in-alphabetic-order-to-protect-privacy.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Sorting outputs of a transaction in alphabetic order to protect privacy - 2023-08-02T02:07:28.726130+00:00 - - Pavol Rusnak 2020-04-30 12:14:28+00:00 - - - SatoshiSingh 2020-04-29 06:47:39+00:00 - + 2025-09-26T15:33:02.954982+00:00 + python-feedgen + + + [bitcoin-dev] Sorting outputs of a transaction in alphabetic order to protect privacy SatoshiSingh + 2020-04-29T06:47:00.000Z + + + Pavol Rusnak + 2020-04-30T12:14:00.000Z + + - python-feedgen + 2 Combined summary - Sorting outputs of a transaction in alphabetic order to protect privacy - 2023-08-02T02:07:28.726130+00:00 + 2025-09-26T15:33:02.955488+00:00 - SatoshiSingh, a member of the bitcoin-dev mailing list, has put forward a suggestion to enhance user privacy in cryptocurrency transactions. The current practice followed by wallet developers involves constructing transactions with the sender's change address as the second output. However, this makes it relatively easy for chain analyzers to track addresses and compromise user privacy.To tackle this issue, SatoshiSingh proposes a solution that involves sorting the outputs in either alphabetical or random order before broadcasting the transaction. By doing so, the aim is to make it more challenging for chain analyzers to identify which output represents the change address. This alteration could potentially strengthen user privacy and safeguard their personal information.The proposal received mixed reactions from other members of the mailing list. While some expressed support for the idea, others may have had reservations or alternative suggestions. Pavol Rusnak, the Chief Technology Officer (CTO) of SatoshiLabs, responded to the thread with his regards, indicating engagement and interest in the topic.This contribution from SatoshiSingh marks their first active involvement in the group after previously being an observer, or "lurker." Their suggestion has sparked a discussion within the community about the potential benefits and implications of altering transaction construction methods to bolster user privacy in the realm of cryptocurrencies. 2020-04-30T12:14:28+00:00 + SatoshiSingh, a member of the bitcoin-dev mailing list, has put forward a suggestion to enhance user privacy in cryptocurrency transactions. The current practice followed by wallet developers involves constructing transactions with the sender's change address as the second output. However, this makes it relatively easy for chain analyzers to track addresses and compromise user privacy.To tackle this issue, SatoshiSingh proposes a solution that involves sorting the outputs in either alphabetical or random order before broadcasting the transaction. By doing so, the aim is to make it more challenging for chain analyzers to identify which output represents the change address. This alteration could potentially strengthen user privacy and safeguard their personal information.The proposal received mixed reactions from other members of the mailing list. While some expressed support for the idea, others may have had reservations or alternative suggestions. Pavol Rusnak, the Chief Technology Officer (CTO) of SatoshiLabs, responded to the thread with his regards, indicating engagement and interest in the topic.This contribution from SatoshiSingh marks their first active involvement in the group after previously being an observer, or "lurker." Their suggestion has sparked a discussion within the community about the potential benefits and implications of altering transaction construction methods to bolster user privacy in the realm of cryptocurrencies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2020/combined_Statechain-implementations.xml b/static/bitcoin-dev/April_2020/combined_Statechain-implementations.xml index 8801004338..2cc3d67c1a 100644 --- a/static/bitcoin-dev/April_2020/combined_Statechain-implementations.xml +++ b/static/bitcoin-dev/April_2020/combined_Statechain-implementations.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - Statechain implementations - 2023-08-02T01:58:10.360456+00:00 - - Tom Trevethan 2020-05-07 14:54:53+00:00 - - - Tom Trevethan 2020-04-05 21:25:51+00:00 - - - ZmnSCPxj 2020-04-05 18:24:39+00:00 - - - Bob McElrath 2020-04-05 14:17:17+00:00 - - - ZmnSCPxj 2020-04-04 12:07:28+00:00 - - - Nadav Kohen 2020-04-03 16:37:15+00:00 - - - Tom Trevethan 2020-04-02 22:56:17+00:00 - - - Tom Trevethan 2020-03-31 11:41:46+00:00 - - - David A. Harding 2020-03-31 10:35:08+00:00 - - - ZmnSCPxj 2020-03-30 01:25:36+00:00 - - - Ruben Somsen 2020-03-28 17:42:58+00:00 - - - Ruben Somsen 2020-03-28 17:38:47+00:00 - - - ZmnSCPxj 2020-03-28 02:42:27+00:00 - - - ZmnSCPxj 2020-03-28 02:20:33+00:00 - - - Bob McElrath 2020-03-27 17:10:18+00:00 - - - Ruben Somsen 2020-03-27 15:12:33+00:00 - - - ZmnSCPxj 2020-03-27 01:46:15+00:00 - - - Ruben Somsen 2020-03-26 18:53:13+00:00 - - - Greg Sanders 2020-03-26 17:17:13+00:00 - - - Christian Decker 2020-03-26 17:12:44+00:00 - - - Bob McElrath 2020-03-26 14:52:36+00:00 - - - Ruben Somsen 2020-03-26 12:36:20+00:00 - - - Albert 2020-03-26 03:55:50+00:00 - - - ZmnSCPxj 2020-03-26 01:20:47+00:00 - - - Tom Trevethan 2020-03-25 13:52:10+00:00 - + 2025-09-26T15:32:48.248080+00:00 + python-feedgen + + + [bitcoin-dev] Statechain implementations Tom Trevethan + 2020-03-25T13:52:00.000Z + + + ZmnSCPxj + 2020-03-26T01:20:00.000Z + + + Albert + 2020-03-26T03:55:00.000Z + + + Ruben Somsen + 2020-03-26T12:36:00.000Z + + + Bob McElrath + 2020-03-26T14:52:00.000Z + + + Christian Decker + 2020-03-26T17:12:00.000Z + + + Greg Sanders + 2020-03-26T17:17:00.000Z + + + Ruben Somsen + 2020-03-26T18:53:00.000Z + + + ZmnSCPxj + 2020-03-27T01:46:00.000Z + + + Ruben Somsen + 2020-03-27T15:12:00.000Z + + + Bob McElrath + 2020-03-27T17:10:00.000Z + + + ZmnSCPxj + 2020-03-28T02:20:00.000Z + + + ZmnSCPxj + 2020-03-28T02:42:00.000Z + + + Ruben Somsen + 2020-03-28T17:38:00.000Z + + + Ruben Somsen + 2020-03-28T17:42:00.000Z + + + ZmnSCPxj + 2020-03-30T01:25:00.000Z + + + David A. Harding + 2020-03-31T10:35:00.000Z + + + Tom Trevethan + 2020-03-31T11:41:00.000Z + + + Tom Trevethan + 2020-04-02T22:56:00.000Z + + + Nadav Kohen + 2020-04-03T16:37:00.000Z + + + ZmnSCPxj + 2020-04-04T12:07:00.000Z + + + Bob McElrath + 2020-04-05T14:17:00.000Z + + + ZmnSCPxj + 2020-04-05T18:24:00.000Z + + + Tom Trevethan + 2020-04-05T21:25:00.000Z + + + Tom Trevethan + 2020-05-07T14:54:00.000Z + + @@ -103,13 +131,13 @@ - python-feedgen + 2 Combined summary - Statechain implementations - 2023-08-02T01:58:10.360456+00:00 + 2025-09-26T15:32:48.250917+00:00 - CommerceBlock is actively working on implementing their statechain using KZen's 2P ECDSA protocol and Rust. They plan to use a sparse Merkle tree attested to a Mainstay slot for the proof-of-publication/proof-of-ownership. The statechain will allow the current owner to prove if there has been theft from them.Nadav has concerns about potential scams by the Statechain Entity (SE) where they buy the UTXO, transfer it, and then steal it. This issue can be solved by adding a new user key to the protocol that would make it traceable/provable. For open-ended UTXOs, an invalidation tree relative locktime backup mechanism will likely be used. Tom Trevethan clarifies that his patent application is different from the ideas currently being worked on. On the bitcoin-dev mailing list, a proposal was made for an exchange platform that operates using off-chain transactions and does not require on-chain transactions. This platform would be capable of generating multiple transactions, which can be recorded on a blockchain under different circumstances. The proposal suggests that some off-chain transactions should still be valid for recording on the blockchain in the event of a catastrophic failure of the exchange, such as the permanent shutdown of the exchange or loss of key shares.A two-party elliptic curve digital signature algorithm script would be used to perform functions of a two-party elliptic curve digital signature algorithm. The proposal also notes that a malicious actor would have to collude with a previous owner of the funds to recreate the full key making it difficult for them to compromise the exchange platform. Dave proposed this idea, and Bob McElrath responded to it by quoting H.L. Mencken's famous statement that "For every complex problem, there is a solution that is simple, neat, and wrong."In an email chain on the Bitcoin development mailing list, several proposals were discussed to increase platform security. One proposal involved using two-party elliptic curve digital signature algorithms to make it difficult for malicious actors to compromise the exchange platform. The processor would be configured to perform these functions, which would limit opportunities for attackers to compromise the platform. Bob McElrath noted that this proposed solution may not be effective in preventing all attacks and ended his email with a quote by H.L. Mencken: "For every complex problem, there is a solution that is simple, neat, and wrong."Another proposal discussed was the statechain protocol. Nadav Kohen raised concerns over the possibility of a malicious Statechain Entity (SE) stealing a user's UTXO by collaborating with or being a previous owner. Tom suggested using proof-of-publication as a way to enable the current owner to prove ownership and prevent double-spending, as well as provide evidence of fraud on the part of the SE. Bob McElrath suggested using single use seals to track ownership history and prevent the SE from buying the UTXO, noting that the attack would require collusion with the current UTXO owner. Nadav proposed adding a new user key to the protocol, which would be required for a transfer to be valid on the statechain.Tom provided a more detailed document specifying the proposed protocol, including improvements to the transfer mechanism and an explanation of how this can be used to transfer/novate positions in DLCs. He also addressed concerns about nChain Holdings' patent application related to secure off-chain blockchain transactions.The discussion is about the security assumptions of statechains. It is mentioned that an attack on statechains requires collaboration with the current UTXO owner, who is transferring the UXTO to a non-statechain entity and knows the target of the transfer, obtaining the target pubkey for the transfer out-of-band with respect to the SE or the SE can MITM that. The security assumption is that the sender or receiver does not collude with the SE. If either does, then the attack is generally possible.The SE cannot be allowed to be both operator of the SE and a customer of it as this clearly violates the no-receiver collusion principle. Adding a new user key doesn't change the situation as the user has already acquiesced to the transfer. Any past owner of the coin can collude with the statechain authority in order to steal the onchain funds regardless of who the current owner is within the statechain. So, trust must still be put in the statechain authority. The security assumptions should be that the statechain authority really does delete keys and does not make backups, and no past or current owner of the coin colludes with the statechain authority.The Statechain concept proposes non-custodial off-chain Bitcoin transfer. The current holder of UTXO must obtain the target pubkey for the transfer out-of-band with respect to the SE, or the SE can MITM that. Nadav Kohen raised concerns about an untraceable scam by the Statechain Entity (SE). It involves buying the UTXO, transferring it to someone else, 2020-05-07T14:54:53+00:00 + CommerceBlock is actively working on implementing their statechain using KZen's 2P ECDSA protocol and Rust. They plan to use a sparse Merkle tree attested to a Mainstay slot for the proof-of-publication/proof-of-ownership. The statechain will allow the current owner to prove if there has been theft from them.Nadav has concerns about potential scams by the Statechain Entity (SE) where they buy the UTXO, transfer it, and then steal it. This issue can be solved by adding a new user key to the protocol that would make it traceable/provable. For open-ended UTXOs, an invalidation tree relative locktime backup mechanism will likely be used. Tom Trevethan clarifies that his patent application is different from the ideas currently being worked on. On the bitcoin-dev mailing list, a proposal was made for an exchange platform that operates using off-chain transactions and does not require on-chain transactions. This platform would be capable of generating multiple transactions, which can be recorded on a blockchain under different circumstances. The proposal suggests that some off-chain transactions should still be valid for recording on the blockchain in the event of a catastrophic failure of the exchange, such as the permanent shutdown of the exchange or loss of key shares.A two-party elliptic curve digital signature algorithm script would be used to perform functions of a two-party elliptic curve digital signature algorithm. The proposal also notes that a malicious actor would have to collude with a previous owner of the funds to recreate the full key making it difficult for them to compromise the exchange platform. Dave proposed this idea, and Bob McElrath responded to it by quoting H.L. Mencken's famous statement that "For every complex problem, there is a solution that is simple, neat, and wrong."In an email chain on the Bitcoin development mailing list, several proposals were discussed to increase platform security. One proposal involved using two-party elliptic curve digital signature algorithms to make it difficult for malicious actors to compromise the exchange platform. The processor would be configured to perform these functions, which would limit opportunities for attackers to compromise the platform. Bob McElrath noted that this proposed solution may not be effective in preventing all attacks and ended his email with a quote by H.L. Mencken: "For every complex problem, there is a solution that is simple, neat, and wrong."Another proposal discussed was the statechain protocol. Nadav Kohen raised concerns over the possibility of a malicious Statechain Entity (SE) stealing a user's UTXO by collaborating with or being a previous owner. Tom suggested using proof-of-publication as a way to enable the current owner to prove ownership and prevent double-spending, as well as provide evidence of fraud on the part of the SE. Bob McElrath suggested using single use seals to track ownership history and prevent the SE from buying the UTXO, noting that the attack would require collusion with the current UTXO owner. Nadav proposed adding a new user key to the protocol, which would be required for a transfer to be valid on the statechain.Tom provided a more detailed document specifying the proposed protocol, including improvements to the transfer mechanism and an explanation of how this can be used to transfer/novate positions in DLCs. He also addressed concerns about nChain Holdings' patent application related to secure off-chain blockchain transactions.The discussion is about the security assumptions of statechains. It is mentioned that an attack on statechains requires collaboration with the current UTXO owner, who is transferring the UXTO to a non-statechain entity and knows the target of the transfer, obtaining the target pubkey for the transfer out-of-band with respect to the SE or the SE can MITM that. The security assumption is that the sender or receiver does not collude with the SE. If either does, then the attack is generally possible.The SE cannot be allowed to be both operator of the SE and a customer of it as this clearly violates the no-receiver collusion principle. Adding a new user key doesn't change the situation as the user has already acquiesced to the transfer. Any past owner of the coin can collude with the statechain authority in order to steal the onchain funds regardless of who the current owner is within the statechain. So, trust must still be put in the statechain authority. The security assumptions should be that the statechain authority really does delete keys and does not make backups, and no past or current owner of the coin colludes with the statechain authority.The Statechain concept proposes non-custodial off-chain Bitcoin transfer. The current holder of UTXO must obtain the target pubkey for the transfer out-of-band with respect to the SE, or the SE can MITM that. Nadav Kohen raised concerns about an untraceable scam by the Statechain Entity (SE). It involves buying the UTXO, transferring it to someone else, - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_-Pre-BIP-Motivating-Address-type-for-OP-RETURN.xml b/static/bitcoin-dev/April_2021/combined_-Pre-BIP-Motivating-Address-type-for-OP-RETURN.xml index 462d9a28d7..6cd78c2fc0 100644 --- a/static/bitcoin-dev/April_2021/combined_-Pre-BIP-Motivating-Address-type-for-OP-RETURN.xml +++ b/static/bitcoin-dev/April_2021/combined_-Pre-BIP-Motivating-Address-type-for-OP-RETURN.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - [Pre-BIP] Motivating Address type for OP_RETURN - 2023-08-02T03:39:18.174145+00:00 - - Jeremy 2021-04-25 00:25:30+00:00 - - - Zac Greenwood 2021-04-24 23:37:56+00:00 - - - Jeremy 2021-04-24 22:29:39+00:00 - - - David A. Harding 2021-04-24 21:59:00+00:00 - - - Jeremy 2021-04-24 20:05:25+00:00 - - - David A. Harding 2021-04-23 18:15:50+00:00 - - - Jeremy 2021-04-20 15:46:07+00:00 - + 2025-09-26T15:45:13.644930+00:00 + python-feedgen + + + [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN Jeremy + 2021-04-20T15:46:00.000Z + + + David A. Harding + 2021-04-23T18:15:00.000Z + + + Jeremy + 2021-04-24T20:05:00.000Z + + + David A. Harding + 2021-04-24T21:59:00.000Z + + + Jeremy + 2021-04-24T22:29:00.000Z + + + Zac Greenwood + 2021-04-24T23:37:00.000Z + + + Jeremy + 2021-04-25T00:25:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - [Pre-BIP] Motivating Address type for OP_RETURN - 2023-08-02T03:39:18.174145+00:00 + 2025-09-26T15:45:13.646008+00:00 - In a discussion on the bitcoin-dev mailing list, the topic of introducing a non-transaction data structure that allows for storing data on-chain while maximizing payload size versus on-chain size was explored. The proposal aims to ensure that using this data structure is almost as expensive in use per payload-byte as the next-cheapest alternative, which currently is using OP_RETURN with weight units. Concerns were raised regarding the 10,000-byte limit when EvalScript is run and the potential abuse of bech32m addressed outputs. The benefits of using OP_RETURN include allowing more data in scriptSig, exemption from the dust limit, and potential future use for metadata like stealth addresses. However, there are also concerns about block chain graffiti. A demonstration was provided showing the creation of an 11,000 byte OP_RETURN on regtest.The discussion further delved into the use of OP_RETURN addresses in Bitcoin. While some participants expressed annoyance with having to program around them, they acknowledged their historical significance and advantages over other address types in terms of allowing more data in scriptSig and being exempt from the dust limit. The conversation also touched on the structure of PSBTs and the possibility of creating a standard OP_RETURN address format. It was emphasized that the motivation behind such a standard and its potential impact on block chain graffiti should be further considered.In an email conversation, Dave discussed with Jeremy the concept of script commitments and the max size of a scriptsig/scriptpubkey. Jeremy inquired about the possibility of making inappropriate messages using bech32m addressed outputs. Dave explained that people have done it in the past with base58check, but an IsStandard OP_RETURN attempts to minimize this abuse by being cheaper. The conversation also touched on the PSBT interface and the convenience of having a uniform handling for strongly typed RPC bindings. Dave expressed interest in the idea of an address format for OP_RETURN as long as it is not underwhelmingly motivated or leads to block chain graffiti.The bitcoin-dev mailing list discussion focused on the use of OP_RETURN outputs. Concerns were raised about the wide range of possibilities that can be represented by script and the potential for offensive or illegal text in OP_RETURN data. Suggestions were made to default to meaningless representations of OP_RETURN data, such as displaying it in hex, to discourage inappropriate usage. The discussion also explored whether the OP_RETURN output should have a fixed length or support arbitrary length strings, and whether it should be possible to pay into such an OP_RETURN or categorize them as non-payable addresses. It was argued that including arbitrary data in the blockchain is not currently useful for typical end-users, but applications can already call create(psbt|rawtransaction) with the 'data' field. The increasing transaction fees were noted to push uses of OP_RETURN off the network or into more efficient constructions, so optimizing its use may not be necessary. However, some uses like stealth addresses or open timestamps may still warrant a standard address type.Jeremy Rubin suggested the need for an address type for OP_RETURN. He highlighted the challenge of handling common classes of user transactions generically while dealing with OP_RETURN. He argued that OP_RETURN should be represented by an Address type to simplify types for programs. The counterargument was that OP_RETURN, being unspendable and usually proprietary in purpose, should not have an address. Jeremy countered by stating that Addresses should represent things commonly created outputs for, and OP_RETURN is one such thing. He proposed design constraints for the proposed OP_RETURN address type and questioned whether it should be human-readable and checksummed or encoded, have a fixed length or support arbitrary length strings, and be payable or non-payable.Overall, the discussions revolved around the use of OP_RETURN addresses in Bitcoin, addressing concerns such as the potential for abuse, block chain graffiti, and the need for a standard address format. Different perspectives were presented, highlighting potential benefits and drawbacks of implementing an address type for OP_RETURN. 2021-04-25T00:25:30+00:00 + In a discussion on the bitcoin-dev mailing list, the topic of introducing a non-transaction data structure that allows for storing data on-chain while maximizing payload size versus on-chain size was explored. The proposal aims to ensure that using this data structure is almost as expensive in use per payload-byte as the next-cheapest alternative, which currently is using OP_RETURN with weight units. Concerns were raised regarding the 10,000-byte limit when EvalScript is run and the potential abuse of bech32m addressed outputs. The benefits of using OP_RETURN include allowing more data in scriptSig, exemption from the dust limit, and potential future use for metadata like stealth addresses. However, there are also concerns about block chain graffiti. A demonstration was provided showing the creation of an 11,000 byte OP_RETURN on regtest.The discussion further delved into the use of OP_RETURN addresses in Bitcoin. While some participants expressed annoyance with having to program around them, they acknowledged their historical significance and advantages over other address types in terms of allowing more data in scriptSig and being exempt from the dust limit. The conversation also touched on the structure of PSBTs and the possibility of creating a standard OP_RETURN address format. It was emphasized that the motivation behind such a standard and its potential impact on block chain graffiti should be further considered.In an email conversation, Dave discussed with Jeremy the concept of script commitments and the max size of a scriptsig/scriptpubkey. Jeremy inquired about the possibility of making inappropriate messages using bech32m addressed outputs. Dave explained that people have done it in the past with base58check, but an IsStandard OP_RETURN attempts to minimize this abuse by being cheaper. The conversation also touched on the PSBT interface and the convenience of having a uniform handling for strongly typed RPC bindings. Dave expressed interest in the idea of an address format for OP_RETURN as long as it is not underwhelmingly motivated or leads to block chain graffiti.The bitcoin-dev mailing list discussion focused on the use of OP_RETURN outputs. Concerns were raised about the wide range of possibilities that can be represented by script and the potential for offensive or illegal text in OP_RETURN data. Suggestions were made to default to meaningless representations of OP_RETURN data, such as displaying it in hex, to discourage inappropriate usage. The discussion also explored whether the OP_RETURN output should have a fixed length or support arbitrary length strings, and whether it should be possible to pay into such an OP_RETURN or categorize them as non-payable addresses. It was argued that including arbitrary data in the blockchain is not currently useful for typical end-users, but applications can already call create(psbt|rawtransaction) with the 'data' field. The increasing transaction fees were noted to push uses of OP_RETURN off the network or into more efficient constructions, so optimizing its use may not be necessary. However, some uses like stealth addresses or open timestamps may still warrant a standard address type.Jeremy Rubin suggested the need for an address type for OP_RETURN. He highlighted the challenge of handling common classes of user transactions generically while dealing with OP_RETURN. He argued that OP_RETURN should be represented by an Address type to simplify types for programs. The counterargument was that OP_RETURN, being unspendable and usually proprietary in purpose, should not have an address. Jeremy countered by stating that Addresses should represent things commonly created outputs for, and OP_RETURN is one such thing. He proposed design constraints for the proposed OP_RETURN address type and questioned whether it should be human-readable and checksummed or encoded, have a fixed length or support arbitrary length strings, and be payable or non-payable.Overall, the discussions revolved around the use of OP_RETURN addresses in Bitcoin, addressing concerns such as the potential for abuse, block chain graffiti, and the need for a standard address format. Different perspectives were presented, highlighting potential benefits and drawbacks of implementing an address type for OP_RETURN. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_7z-block-compression-18-.xml b/static/bitcoin-dev/April_2021/combined_7z-block-compression-18-.xml index ee03d831bb..a23a510c32 100644 --- a/static/bitcoin-dev/April_2021/combined_7z-block-compression-18-.xml +++ b/static/bitcoin-dev/April_2021/combined_7z-block-compression-18-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - 7z block compression, 18% - 2023-08-02T03:41:12.142651+00:00 - - Greg Maxwell 2021-04-24 19:17:41+00:00 - - - Pavol Rusnak 2021-04-24 18:20:47+00:00 - - - NITSOPOULOS KONSTANTINOS 2021-04-24 11:02:31+00:00 - + 2025-09-26T15:44:48.374169+00:00 + python-feedgen + + + [bitcoin-dev] 7z block compression, 18% NITSOPOULOS KONSTANTINOS + 2021-04-24T11:02:00.000Z + + + Pavol Rusnak + 2021-04-24T18:20:00.000Z + + + Greg Maxwell + 2021-04-24T19:17:00.000Z + + - python-feedgen + 2 Combined summary - 7z block compression, 18% - 2023-08-02T03:41:12.142651+00:00 + 2025-09-26T15:44:48.374735+00:00 - A recent discussion on Bitcointalk revealed that the Blockstream satellite codebase has an alternative serialization that can save up to 20% on a single transaction. This method avoids violating layering, allows for single transaction access, and is compatible with transaction relay. The format also optimizes predictable hashes, achieving savings that cannot be achieved by generic compressors. However, the savings from generic compressors mostly come from repeated pubkeys and addresses, which may be diminished by taproot and signature aggregation in the future.Using generic compression interfaces like zlib across networks has had a disappointing security track record. Previous discussions have centered around using generic compressors, as seen in the list archive and bitcoin-core Github. Recently, Nitsopoulos Konstantinos proposed using the 7z file type to compress new blocks by up to 18%, potentially reducing the size of the blockchain to under 290GB if converted into a 7z archive-chain. However, he admitted that programming compression was too difficult for him and hoped someone else would take on the task. He also suggested compressing transactions by replacing addresses and coins with their own unique sequential index, which could potentially reduce the size of a transaction between two existing addresses to half or even a quarter of its current size.Pavol Rusnak, the co-founder and CTO of SatoshiLabs, shared information about Zstandard (zstd), a block compression algorithm that offers better properties than its competitors, especially for decompression. The provided link leads to the GitHub repository for zstd, where more information about the algorithm can be found. 2021-04-24T19:17:41+00:00 + A recent discussion on Bitcointalk revealed that the Blockstream satellite codebase has an alternative serialization that can save up to 20% on a single transaction. This method avoids violating layering, allows for single transaction access, and is compatible with transaction relay. The format also optimizes predictable hashes, achieving savings that cannot be achieved by generic compressors. However, the savings from generic compressors mostly come from repeated pubkeys and addresses, which may be diminished by taproot and signature aggregation in the future.Using generic compression interfaces like zlib across networks has had a disappointing security track record. Previous discussions have centered around using generic compressors, as seen in the list archive and bitcoin-core Github. Recently, Nitsopoulos Konstantinos proposed using the 7z file type to compress new blocks by up to 18%, potentially reducing the size of the blockchain to under 290GB if converted into a 7z archive-chain. However, he admitted that programming compression was too difficult for him and hoped someone else would take on the task. He also suggested compressing transactions by replacing addresses and coins with their own unique sequential index, which could potentially reduce the size of a transaction between two existing addresses to half or even a quarter of its current size.Pavol Rusnak, the co-founder and CTO of SatoshiLabs, shared information about Zstandard (zstd), a block compression algorithm that offers better properties than its competitors, especially for decompression. The provided link leads to the GitHub repository for zstd, where more information about the algorithm can be found. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Additional-BIPs-related-to-other-proposals.xml b/static/bitcoin-dev/April_2021/combined_Additional-BIPs-related-to-other-proposals.xml index 1d27328ab2..fa0f3a446a 100644 --- a/static/bitcoin-dev/April_2021/combined_Additional-BIPs-related-to-other-proposals.xml +++ b/static/bitcoin-dev/April_2021/combined_Additional-BIPs-related-to-other-proposals.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Additional BIPs related to other proposals - 2023-08-02T03:40:48.914889+00:00 - - Billy Tetrud 2021-05-22 06:01:19+00:00 - - - Luke Dashjr 2021-05-22 02:33:45+00:00 - - - Billy Tetrud 2021-05-21 07:56:51+00:00 - - - Christopher Gilliard 2021-04-24 02:05:53+00:00 - + 2025-09-26T15:45:05.249534+00:00 + python-feedgen + + + [bitcoin-dev] Additional BIPs related to other proposals Christopher Gilliard + 2021-04-24T02:05:00.000Z + + + Billy Tetrud + 2021-05-21T07:56:00.000Z + + + Luke Dashjr + 2021-05-22T02:33:00.000Z + + + Billy Tetrud + 2021-05-22T06:01:00.000Z + + - python-feedgen + 2 Combined summary - Additional BIPs related to other proposals - 2023-08-02T03:40:48.914889+00:00 + 2025-09-26T15:45:05.250159+00:00 - During a conversation on the bitcoin-dev mailing list, Luke Dashjr and Billy Tetrud discussed Bitcoin Improvement Proposals (BIPs). Tetrud expressed his opinion that the BIPs seemed unrelated to changing the base layer of Bitcoin, although they were well organized. Dashjr clarified that BIPs are not limited to the base layer and can be used for coordinating Bitcoin software at any layer.The email exchange on the mailing list also revealed that Christopher Gilliard has created three additional BIPs related to his recent proposals. These BIPs, which focus on notification, moderation, and web of trust (WoT), can be found on Github. While the documents are well put together, they are seen as building on top of the Bitcoin platform without directly changing its base layer. Feedback, questions, and comments regarding these proposals are encouraged.To access Chris's BIPs related to his recent proposals, the links provided on Github can be followed. The first link is associated with notification, the second one with moderation, and the third one with Web of Trust (WoT). Chris is seeking feedback, questions, or comments on these proposals. 2021-05-22T06:01:19+00:00 + During a conversation on the bitcoin-dev mailing list, Luke Dashjr and Billy Tetrud discussed Bitcoin Improvement Proposals (BIPs). Tetrud expressed his opinion that the BIPs seemed unrelated to changing the base layer of Bitcoin, although they were well organized. Dashjr clarified that BIPs are not limited to the base layer and can be used for coordinating Bitcoin software at any layer.The email exchange on the mailing list also revealed that Christopher Gilliard has created three additional BIPs related to his recent proposals. These BIPs, which focus on notification, moderation, and web of trust (WoT), can be found on Github. While the documents are well put together, they are seen as building on top of the Bitcoin platform without directly changing its base layer. Feedback, questions, and comments regarding these proposals are encouraged.To access Chris's BIPs related to his recent proposals, the links provided on Github can be followed. The first link is associated with notification, the second one with moderation, and the third one with Web of Trust (WoT). Chris is seeking feedback, questions, or comments on these proposals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_And-Then-What-Defining-a-Complete-Process-for-Upgrades.xml b/static/bitcoin-dev/April_2021/combined_And-Then-What-Defining-a-Complete-Process-for-Upgrades.xml index 01d4618671..9cf1af2379 100644 --- a/static/bitcoin-dev/April_2021/combined_And-Then-What-Defining-a-Complete-Process-for-Upgrades.xml +++ b/static/bitcoin-dev/April_2021/combined_And-Then-What-Defining-a-Complete-Process-for-Upgrades.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - And Then What? Defining a Complete Process for Upgrades - 2023-08-02T03:40:08.296937+00:00 - - Keagan McClelland 2021-04-23 00:06:02+00:00 - - - Jeremy 2021-04-22 22:41:56+00:00 - + 2025-09-26T15:45:11.553835+00:00 + python-feedgen + + + [bitcoin-dev] And Then What? Defining a Complete Process for Upgrades Jeremy + 2021-04-22T22:41:00.000Z + + + Keagan McClelland + 2021-04-23T00:06:00.000Z + + - python-feedgen + 2 Combined summary - And Then What? Defining a Complete Process for Upgrades - 2023-08-02T03:40:08.296937+00:00 + 2025-09-26T15:45:11.554293+00:00 - In an email sent to the bitcoin-dev mailing list, Jeremy Rubin proposes a new upgrade mechanism for Bitcoin. The proposed mechanism involves a series of state transitions spread over two years, with two soft forks and two quieting periods. The main objective is to achieve consensus among miners and node operators while avoiding lost hashrate. To address concerns, forced signaling is used during the process. The email provides a detailed timeline for the upgrade process.However, there are some questions and concerns regarding the proposal. One concern is the missing state transitions, as well as the adjustment of signaling thresholds and the flexibility of parameters during quieting periods. The most contentious part of the proposal is the PoW fork, which highlights the risk of committing to a minority chain due to rule activation with low hashrate.The email also discusses the struggle to identify the complete set of problems that the process of organizing discussion around a repeatable process for soft-fork upgrades aims to solve. The writer argues against LOT=false deployment and the idea of miners having veto power over proposals. The proposal is seen as not solving any meaningful progress on a consensus change process, particularly because it lacks a mechanism for gathering reliable information about user-preference in a sybil resistant way.The proposal aims to be compatible with Taproot's ST and seeks to form rough consensus on what to try next. However, the specific parameters are open to debate. Forced signaling is discussed, but its merit is unclear to the writer. The email concludes with a call for someone to write the software for the proposed mechanism.Overall, the letter proposes a development process that respects all groups involved in a balance of powers. It aims to form rough consensus and considers compatibility with Taproot's ST. While questions and concerns exist regarding various aspects of the proposal, such as missing state transitions and parameter flexibility, the proposal emphasizes the potential disruption caused by committing to a minority chain with low hashrate. 2021-04-23T00:06:02+00:00 + In an email sent to the bitcoin-dev mailing list, Jeremy Rubin proposes a new upgrade mechanism for Bitcoin. The proposed mechanism involves a series of state transitions spread over two years, with two soft forks and two quieting periods. The main objective is to achieve consensus among miners and node operators while avoiding lost hashrate. To address concerns, forced signaling is used during the process. The email provides a detailed timeline for the upgrade process.However, there are some questions and concerns regarding the proposal. One concern is the missing state transitions, as well as the adjustment of signaling thresholds and the flexibility of parameters during quieting periods. The most contentious part of the proposal is the PoW fork, which highlights the risk of committing to a minority chain due to rule activation with low hashrate.The email also discusses the struggle to identify the complete set of problems that the process of organizing discussion around a repeatable process for soft-fork upgrades aims to solve. The writer argues against LOT=false deployment and the idea of miners having veto power over proposals. The proposal is seen as not solving any meaningful progress on a consensus change process, particularly because it lacks a mechanism for gathering reliable information about user-preference in a sybil resistant way.The proposal aims to be compatible with Taproot's ST and seeks to form rough consensus on what to try next. However, the specific parameters are open to debate. Forced signaling is discussed, but its merit is unclear to the writer. The email concludes with a call for someone to write the software for the proposed mechanism.Overall, the letter proposes a development process that respects all groups involved in a balance of powers. It aims to form rough consensus and considers compatibility with Taproot's ST. While questions and concerns exist regarding various aspects of the proposal, such as missing state transitions and parameter flexibility, the proposal emphasizes the potential disruption caused by committing to a minority chain with low hashrate. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Announcing-a-new-standard-for-soft-fork-activation.xml b/static/bitcoin-dev/April_2021/combined_Announcing-a-new-standard-for-soft-fork-activation.xml index 81033f4d9c..8fa9d9cf79 100644 --- a/static/bitcoin-dev/April_2021/combined_Announcing-a-new-standard-for-soft-fork-activation.xml +++ b/static/bitcoin-dev/April_2021/combined_Announcing-a-new-standard-for-soft-fork-activation.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Announcing a new standard for soft fork activation - 2023-08-02T03:31:40.538437+00:00 - - Erik Aronesty 2021-04-05 22:36:48+00:00 - - - Ben Woosley 2021-04-01 18:05:28+00:00 - - - Michael Folkson 2021-04-01 14:58:04+00:00 - + 2025-09-26T15:44:56.808295+00:00 + python-feedgen + + + [bitcoin-dev] Announcing a new standard for soft fork activation Michael Folkson + 2021-04-01T14:58:00.000Z + + + Ben Woosley + 2021-04-01T18:05:00.000Z + + + Erik Aronesty + 2021-04-05T22:36:00.000Z + + - python-feedgen + 2 Combined summary - Announcing a new standard for soft fork activation - 2023-08-02T03:31:40.538437+00:00 + 2025-09-26T15:44:56.808846+00:00 - On April 1, 2021, Michael Folkson proposed a comprehensive standard for soft fork activation in an email to the bitcoin-dev mailing list. This new standard aims to incorporate all the recent proposals into one multi-phase, multi-year plan. The proposal consists of 14 phases that must be successfully passed before a soft fork can activate.The first phase, called "Let's See What Happens - BIP 8," is the shortest and serves as an initial test. The subsequent phases include important concepts such as "Start now, improve later," "BIP 9 equivalent," "Gently discourage apathy," "BIP 91," "BIP 148," "Speedy Trial on mainnet and signet," "Modern Soft Fork Activation," "UASF BIP 8," and "Second flag day."The most complex and longest phase is Phase 12, known as "Modern Soft Fork Activation." This phase itself is multi-phase and multi-year, highlighting the meticulous nature of the proposed standard. According to Folkson, if a soft fork fails at any point during activation, it must start again from Phase 1.Folkson emphasizes the need for conservatism in the activation process, demonstrating Bitcoin's cautious approach. He expects that this rigorous standard will eventually receive a BIP number. However, the proposed standard comes with a significant time commitment. Assuming successful passage through all 14 phases, a soft fork would still take a minimum of 13 years to activate.Furthermore, it is important to note that the proposed standard is copyrighted. Therefore, anyone utilizing this standard for future soft forks would be required to pay royalties into a quantum secure Bitcoin vanity address.In conclusion, the proposal put forth by Michael Folkson introduces a new standard for soft fork activation. This standard incorporates various concepts and proposals into a comprehensive multi-phase, multi-year plan. The proposed standard aims to demonstrate Bitcoin's conservative nature and requires successful passage through all 14 phases before activation. However, the time commitment is substantial, with a minimum of 13 years needed for activation. Additionally, the standard is copyrighted, necessitating royalty payments into a quantum secure Bitcoin vanity address. 2021-04-05T22:36:48+00:00 + On April 1, 2021, Michael Folkson proposed a comprehensive standard for soft fork activation in an email to the bitcoin-dev mailing list. This new standard aims to incorporate all the recent proposals into one multi-phase, multi-year plan. The proposal consists of 14 phases that must be successfully passed before a soft fork can activate.The first phase, called "Let's See What Happens - BIP 8," is the shortest and serves as an initial test. The subsequent phases include important concepts such as "Start now, improve later," "BIP 9 equivalent," "Gently discourage apathy," "BIP 91," "BIP 148," "Speedy Trial on mainnet and signet," "Modern Soft Fork Activation," "UASF BIP 8," and "Second flag day."The most complex and longest phase is Phase 12, known as "Modern Soft Fork Activation." This phase itself is multi-phase and multi-year, highlighting the meticulous nature of the proposed standard. According to Folkson, if a soft fork fails at any point during activation, it must start again from Phase 1.Folkson emphasizes the need for conservatism in the activation process, demonstrating Bitcoin's cautious approach. He expects that this rigorous standard will eventually receive a BIP number. However, the proposed standard comes with a significant time commitment. Assuming successful passage through all 14 phases, a soft fork would still take a minimum of 13 years to activate.Furthermore, it is important to note that the proposed standard is copyrighted. Therefore, anyone utilizing this standard for future soft forks would be required to pay royalties into a quantum secure Bitcoin vanity address.In conclusion, the proposal put forth by Michael Folkson introduces a new standard for soft fork activation. This standard incorporates various concepts and proposals into a comprehensive multi-phase, multi-year plan. The proposed standard aims to demonstrate Bitcoin's conservative nature and requires successful passage through all 14 phases before activation. However, the time commitment is substantial, with a minimum of 13 years needed for activation. Additionally, the standard is copyrighted, necessitating royalty payments into a quantum secure Bitcoin vanity address. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_BIP-limiting-OP-RETURN-HF.xml b/static/bitcoin-dev/April_2021/combined_BIP-limiting-OP-RETURN-HF.xml index 43895ad5b3..6a79d009f6 100644 --- a/static/bitcoin-dev/April_2021/combined_BIP-limiting-OP-RETURN-HF.xml +++ b/static/bitcoin-dev/April_2021/combined_BIP-limiting-OP-RETURN-HF.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - BIP - limiting OP_RETURN / HF - 2023-08-02T03:36:18.290138+00:00 - - Ruben Somsen 2021-05-04 12:51:14+00:00 - - - ZmnSCPxj 2021-05-03 05:17:46+00:00 - - - Ruben Somsen 2021-04-20 19:07:00+00:00 - - - Christopher Gilliard 2021-04-20 17:12:35+00:00 - - - Zach Greenwood 2021-04-20 08:45:31+00:00 - - - yanmaani at cock.li 2021-04-20 01:23:12+00:00 - - - yanmaani at cock.li 2021-04-20 01:22:51+00:00 - - - Christopher Gilliard 2021-04-17 16:57:34+00:00 - - - Peter Todd 2021-04-17 15:50:08+00:00 - - - Kostas Karasavvas 2021-04-17 07:41:39+00:00 - - - Christopher Gilliard 2021-04-17 03:57:55+00:00 - - - ZmnSCPxj 2021-04-16 23:52:48+00:00 - - - Christopher Gilliard 2021-04-16 21:09:25+00:00 - - - Ruben Somsen 2021-04-16 20:30:06+00:00 - - - Christopher Gilliard 2021-04-16 20:12:07+00:00 - - - Kostas Karasavvas 2021-04-16 19:15:28+00:00 - - - Jeremy 2021-04-16 18:00:29+00:00 - - - Christopher Gilliard 2021-04-16 17:05:12+00:00 - - - Jeremy 2021-04-16 16:32:13+00:00 - - - Andrew Poelstra 2021-04-16 15:55:47+00:00 - - - Christopher Gilliard 2021-04-16 15:34:33+00:00 - - - Christopher Gilliard 2021-04-16 15:33:40+00:00 - - - Clark Moody 2021-04-16 13:59:01+00:00 - - - Russell O'Connor 2021-04-16 13:56:11+00:00 - - - Christopher Gilliard 2021-04-16 07:45:15+00:00 - + 2025-09-26T15:44:31.573151+00:00 + python-feedgen + + + [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard + 2021-04-16T07:45:00.000Z + + + Russell O'Connor + 2021-04-16T13:56:00.000Z + + + Clark Moody + 2021-04-16T13:59:00.000Z + + + Christopher Gilliard + 2021-04-16T15:33:00.000Z + + + Christopher Gilliard + 2021-04-16T15:34:00.000Z + + + Andrew Poelstra + 2021-04-16T15:55:00.000Z + + + Jeremy + 2021-04-16T16:32:00.000Z + + + Christopher Gilliard + 2021-04-16T17:05:00.000Z + + + Jeremy + 2021-04-16T18:00:00.000Z + + + Kostas Karasavvas + 2021-04-16T19:15:00.000Z + + + Christopher Gilliard + 2021-04-16T20:12:00.000Z + + + Ruben Somsen + 2021-04-16T20:30:00.000Z + + + Christopher Gilliard + 2021-04-16T21:09:00.000Z + + + ZmnSCPxj + 2021-04-16T23:52:00.000Z + + + Christopher Gilliard + 2021-04-17T03:57:00.000Z + + + Kostas Karasavvas + 2021-04-17T07:41:00.000Z + + + Peter Todd + 2021-04-17T15:50:00.000Z + + + Christopher Gilliard + 2021-04-17T16:57:00.000Z + + + yanmaani + 2021-04-20T01:22:00.000Z + + + yanmaani + 2021-04-20T01:23:00.000Z + + + Zach Greenwood + 2021-04-20T08:45:00.000Z + + + Christopher Gilliard + 2021-04-20T17:12:00.000Z + + + Ruben Somsen + 2021-04-20T19:07:00.000Z + + + ZmnSCPxj + 2021-05-03T05:17:00.000Z + + + Ruben Somsen + 2021-05-04T12:51:00.000Z + + @@ -103,13 +131,13 @@ - python-feedgen + 2 Combined summary - BIP - limiting OP_RETURN / HF - 2023-08-02T03:36:18.290138+00:00 + 2025-09-26T15:44:31.575887+00:00 - In a recent email exchange, Ruben Somsen and ZmnSCPxj discussed the concept of blind merged mining (BMM) and its potential drawbacks. They discussed how sidechain functionaries may not earn anything once there are multiple functionaries, as they do all the work but gain nothing in return. However, Ruben explained that if one entity consistently creates all the sidechain blocks without leaving any profit for others, it's easy for anyone to step in and outbid them if they try to abuse their position. He also highlighted the similarity between being a spacechain miner and a spacechain user, with the only difference being the availability of BTC to mine the block reward.The conversation also touched upon the use of the term "sidechain" and whether it accurately describes a chain with its own altcoin. Ruben preferred not to call it a "BMM chain" because, in his view, it's not a sidechain if it has its own altcoin. ZmnSCPxj expressed concern about BMM on the mainchain, stating that sidechain functionaries would not earn anything once there are multiple functionaries, and even with just one functionary, the entire sidechain would depend on that entity. The potential drawbacks of blind merged mining were explored, and the possibility of addressing some of these issues through the spacechain design was discussed.The conversation between Yanmaani and Ruben focused on merged mining. Ruben suggested that the current method of storing one hash for a merkle root in Coinbase is not "blind" and proposed a mechanism called the perpetual one-way peg to enable fair "spacecoin" creation by burning BTC to pay for fees. ZmnSCPxj expressed concern about BMM on the main chain, highlighting the issue of bidding wars among functionaries resulting in no earnings for sidechain functionaries. The dependence on a single sidechain functionary was seen as a potential problem. Ruben proposed a mechanism for blind merged mining using a native token called "spacecoin" and explained how it could avoid some of the issues associated with BMM.Zach Greenwood and Yanmaani discussed the issue of storing data on the blockchain, with Zach suggesting the need for a more efficient way to store data while still being almost as expensive per byte compared to using OP_RETURN. Yanmaani proposed adding rules to limit OP_RETURN transactions and committing data in the coinbase transaction to simplify merged mining. The question of payment handling and potential storage costs were raised. Chris responded, mentioning another email sent to the dev alias with additional BIPs and suggesting discussing those BIPs in a new thread.A message posted to the Bitcoin-dev mailing list proposed the development of a facility for more efficient and cost-effective storage of data on-chain. The post highlighted the limitations of using OP_RETURN and suggested a layer two solution for timestamping that integrates into other services. The existing aggregated timestamping service was mentioned, and the high transaction fees were seen as a deterrent to excessive data embedding in the Bitcoin blockchain.The concept of merged mining and the use of one hash per block were discussed. The issue of competition between users wanting to use the hash was raised, resulting in fee-bidding. The proposal included implementing rules to limit OP_RETURN transactions and committing data in the coinbase transaction. Payment handling and storage costs were also considered.The idea of replacing SHA-256d with another solution was explored, considering the malleability of calculating expensive Proof of Work (PoW) and the need to retool the Peer-to-Peer (P2P) protocol. Incentives for miners to upgrade were also discussed, highlighting the challenges of implementing changes without weaker hash power producing alternate chains that appear valid to old clients. The issues that need to be addressed before replacing SHA-256d were emphasized.Christopher Gilliard and Peter Todd discussed the proposal for a layer 2 solution for timestamping that integrates into other services. The limitations of timestamping for proving uniqueness were highlighted, and an existing aggregated timestamping service was mentioned. The need to prevent excessive data embedding through consensus changes and the current high transaction fees were also discussed.Christopher Gilliard's proposed Bitcoin Improvement Proposal (BIP) regarding OP_RETURN limitations was met with feedback and objections. The proposal suggests increasing the limit and implementing a layer two protocol for data aggregation using merkle trees. Concerns were raised about the need for a hard fork and the lack of detail in the proposal. Additional BIPs were mentioned as a response to address these concerns. Feedback included correcting the byte limit for OP_RETURN and discussing the need for incentives and flexibility in accommodating different use cases.The limitations on OP_RETURN transactions were seen as ineffective in blocking arbitrary data embedding on the blockchain. Encoding data inside legacy multi-signature scriptpubkeys was noted as a workaround, but it posed problems in terms of UTXO set management. The same technique was suggested for P2PKH and P2WSH as well, making it difficult 2021-05-04T12:51:14+00:00 + In a recent email exchange, Ruben Somsen and ZmnSCPxj discussed the concept of blind merged mining (BMM) and its potential drawbacks. They discussed how sidechain functionaries may not earn anything once there are multiple functionaries, as they do all the work but gain nothing in return. However, Ruben explained that if one entity consistently creates all the sidechain blocks without leaving any profit for others, it's easy for anyone to step in and outbid them if they try to abuse their position. He also highlighted the similarity between being a spacechain miner and a spacechain user, with the only difference being the availability of BTC to mine the block reward.The conversation also touched upon the use of the term "sidechain" and whether it accurately describes a chain with its own altcoin. Ruben preferred not to call it a "BMM chain" because, in his view, it's not a sidechain if it has its own altcoin. ZmnSCPxj expressed concern about BMM on the mainchain, stating that sidechain functionaries would not earn anything once there are multiple functionaries, and even with just one functionary, the entire sidechain would depend on that entity. The potential drawbacks of blind merged mining were explored, and the possibility of addressing some of these issues through the spacechain design was discussed.The conversation between Yanmaani and Ruben focused on merged mining. Ruben suggested that the current method of storing one hash for a merkle root in Coinbase is not "blind" and proposed a mechanism called the perpetual one-way peg to enable fair "spacecoin" creation by burning BTC to pay for fees. ZmnSCPxj expressed concern about BMM on the main chain, highlighting the issue of bidding wars among functionaries resulting in no earnings for sidechain functionaries. The dependence on a single sidechain functionary was seen as a potential problem. Ruben proposed a mechanism for blind merged mining using a native token called "spacecoin" and explained how it could avoid some of the issues associated with BMM.Zach Greenwood and Yanmaani discussed the issue of storing data on the blockchain, with Zach suggesting the need for a more efficient way to store data while still being almost as expensive per byte compared to using OP_RETURN. Yanmaani proposed adding rules to limit OP_RETURN transactions and committing data in the coinbase transaction to simplify merged mining. The question of payment handling and potential storage costs were raised. Chris responded, mentioning another email sent to the dev alias with additional BIPs and suggesting discussing those BIPs in a new thread.A message posted to the Bitcoin-dev mailing list proposed the development of a facility for more efficient and cost-effective storage of data on-chain. The post highlighted the limitations of using OP_RETURN and suggested a layer two solution for timestamping that integrates into other services. The existing aggregated timestamping service was mentioned, and the high transaction fees were seen as a deterrent to excessive data embedding in the Bitcoin blockchain.The concept of merged mining and the use of one hash per block were discussed. The issue of competition between users wanting to use the hash was raised, resulting in fee-bidding. The proposal included implementing rules to limit OP_RETURN transactions and committing data in the coinbase transaction. Payment handling and storage costs were also considered.The idea of replacing SHA-256d with another solution was explored, considering the malleability of calculating expensive Proof of Work (PoW) and the need to retool the Peer-to-Peer (P2P) protocol. Incentives for miners to upgrade were also discussed, highlighting the challenges of implementing changes without weaker hash power producing alternate chains that appear valid to old clients. The issues that need to be addressed before replacing SHA-256d were emphasized.Christopher Gilliard and Peter Todd discussed the proposal for a layer 2 solution for timestamping that integrates into other services. The limitations of timestamping for proving uniqueness were highlighted, and an existing aggregated timestamping service was mentioned. The need to prevent excessive data embedding through consensus changes and the current high transaction fees were also discussed.Christopher Gilliard's proposed Bitcoin Improvement Proposal (BIP) regarding OP_RETURN limitations was met with feedback and objections. The proposal suggests increasing the limit and implementing a layer two protocol for data aggregation using merkle trees. Concerns were raised about the need for a hard fork and the lack of detail in the proposal. Additional BIPs were mentioned as a response to address these concerns. Feedback included correcting the byte limit for OP_RETURN and discussing the need for incentives and flexibility in accommodating different use cases.The limitations on OP_RETURN transactions were seen as ineffective in blocking arbitrary data embedding on the blockchain. Encoding data inside legacy multi-signature scriptpubkeys was noted as a workaround, but it posed problems in terms of UTXO set management. The same technique was suggested for P2PKH and P2WSH as well, making it difficult - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage-protocol.xml b/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage-protocol.xml index 6894bdf865..cf78664e04 100644 --- a/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage-protocol.xml +++ b/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage-protocol.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIPs - notarization protocol and decentralized storage protocol - 2023-08-02T03:39:32.532486+00:00 - - Robert Spigler 2021-04-20 22:44:45+00:00 - - - Christopher Gilliard 2021-04-20 17:07:35+00:00 - + 2025-09-26T15:45:22.007212+00:00 + python-feedgen + + + [bitcoin-dev] BIPs - notarization protocol and decentralized storage protocol Christopher Gilliard + 2021-04-20T17:07:00.000Z + + + Robert Spigler + 2021-04-20T22:44:00.000Z + + - python-feedgen + 2 Combined summary - BIPs - notarization protocol and decentralized storage protocol - 2023-08-02T03:39:32.533486+00:00 + 2025-09-26T15:45:22.007670+00:00 - Robert Spigler expressed his interest in the use of Bitcoin/LN by Storj/Sia instead of an alt. In response to this, Christopher Gilliard, a member of the Bitcoin community, has created two additional Bitcoin Improvement Proposals (BIPs) that are related to the BIP he sent out last week. The first BIP, named "storage," can be found on GitHub at https://github.com/cgilliard/bips/blob/storage/bip-XXXX.mediawiki. This BIP focuses on storage and its implications within the Bitcoin network.The second BIP, named "notarization," is also available on GitHub at https://github.com/cgilliard/bips/blob/notarization-l2/bip-XXXX.mediawiki. This BIP explores the concept of notarization and its potential applications within the Bitcoin ecosystem. Chris is seeking feedback and comments on both of these new BIPs.By creating these additional BIPs, Chris aims to further contribute to the ongoing development and enhancement of the Bitcoin network. He is inviting the Bitcoin community to review and provide input on the proposed ideas and solutions put forth in the BIPs. This collaborative effort will help refine the proposals and potentially lead to their implementation in future updates or forks of the Bitcoin protocol.As Robert Spigler expressed interest in the use of Bitcoin/LN by Storj/Sia, it is likely that these new BIPs may offer insights or solutions that align with his interests. The links provided allow interested individuals to access the BIPs directly on GitHub and engage in discussions or share their thoughts on the proposed concepts.Overall, Christopher Gilliard's creation of these additional BIPs demonstrates his dedication to contributing to the Bitcoin community's growth and progress. By seeking feedback and comments, he encourages active participation from other members of the community, fostering collaboration and innovation within the Bitcoin ecosystem. 2021-04-20T22:44:45+00:00 + Robert Spigler expressed his interest in the use of Bitcoin/LN by Storj/Sia instead of an alt. In response to this, Christopher Gilliard, a member of the Bitcoin community, has created two additional Bitcoin Improvement Proposals (BIPs) that are related to the BIP he sent out last week. The first BIP, named "storage," can be found on GitHub at https://github.com/cgilliard/bips/blob/storage/bip-XXXX.mediawiki. This BIP focuses on storage and its implications within the Bitcoin network.The second BIP, named "notarization," is also available on GitHub at https://github.com/cgilliard/bips/blob/notarization-l2/bip-XXXX.mediawiki. This BIP explores the concept of notarization and its potential applications within the Bitcoin ecosystem. Chris is seeking feedback and comments on both of these new BIPs.By creating these additional BIPs, Chris aims to further contribute to the ongoing development and enhancement of the Bitcoin network. He is inviting the Bitcoin community to review and provide input on the proposed ideas and solutions put forth in the BIPs. This collaborative effort will help refine the proposals and potentially lead to their implementation in future updates or forks of the Bitcoin protocol.As Robert Spigler expressed interest in the use of Bitcoin/LN by Storj/Sia, it is likely that these new BIPs may offer insights or solutions that align with his interests. The links provided allow interested individuals to access the BIPs directly on GitHub and engage in discussions or share their thoughts on the proposed concepts.Overall, Christopher Gilliard's creation of these additional BIPs demonstrates his dedication to contributing to the Bitcoin community's growth and progress. By seeking feedback and comments, he encourages active participation from other members of the community, fostering collaboration and innovation within the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage.xml b/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage.xml index 19db3cbe2b..c5e12e604c 100644 --- a/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage.xml +++ b/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIPs - notarization protocol and decentralized storage - 2023-08-02T03:39:47.078187+00:00 + 2025-09-26T15:44:35.771836+00:00 + python-feedgen Luke Dashjr 2021-04-25 18:29:21+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIPs - notarization protocol and decentralized storage - 2023-08-02T03:39:47.078187+00:00 + 2025-09-26T15:44:35.771990+00:00 - During a discussion on Bitcoin development, the topic of decentralized storage for Bitcoin projects was brought up. Prayank suggested that instead of using a Bitcoin Improvement Proposal (BIP), it may be more appropriate to create a Lightning Network (LN) project. Luke added to the conversation by suggesting that LN should actually consist of a collection of BIPs, highlighting the need for further standardization proposals.Prayank emphasized the importance of implementation or proof of concept code in the BIP, and proposed that it could just be an LN project instead. They shared some relevant links related to decentralized storage, including bkiac/tarnhelm and ElementsProject/filebazaar. Prayank explained that their idea of decentralized storage for Bitcoin projects involves using torrents for files and communication with Tor. They also suggested the inclusion of an easy-to-use API for saving, reading, editing, etc., specifically for Bitcoin projects utilizing torrents. Payments through the Lightning Network would only be involved when spamming becomes an issue.Christopher expressed agreement with Prayank's suggestion of defining an API for both proposals and keeping it in a separate document from the BIPs. He also agreed with Prayank's opinion on the use of Tor. Christopher mentioned that he has been using the BIP format for his proposals, including the one being discussed, as well as other BIPs he is currently working on. However, he expressed openness to changing the format if it is decided that there is a better one for these BIPs. Christopher also brought up the incentivized moderation protocol, which is mentioned in the BIP under consideration.The writer of the context is conducting research on decentralized storage for a Bitcoin project and expresses interest in the concept. They suggest that including implementation or proof of concept code in the BIP would have been preferable, but since it involves the Lightning Network, it could potentially be its own LN project. The writer provides two links, bkiac/tarnhelm and ElementsProject/filebazaar, as potentially helpful resources for Christopher. They also explain their belief that decentralized storage utilizing torrents with Tor can be beneficial for Bitcoin projects. The writer proposes the creation of an easy-to-use API for various functions in Bitcoin projects using torrents, with payments through the Lightning Network only being involved when spamming becomes a concern. Additionally, they share a link to a project called JoinMarket-Org/joinmarket-clientserver/issues/415, which explores similar options. 2021-04-25T18:29:21+00:00 + During a discussion on Bitcoin development, the topic of decentralized storage for Bitcoin projects was brought up. Prayank suggested that instead of using a Bitcoin Improvement Proposal (BIP), it may be more appropriate to create a Lightning Network (LN) project. Luke added to the conversation by suggesting that LN should actually consist of a collection of BIPs, highlighting the need for further standardization proposals.Prayank emphasized the importance of implementation or proof of concept code in the BIP, and proposed that it could just be an LN project instead. They shared some relevant links related to decentralized storage, including bkiac/tarnhelm and ElementsProject/filebazaar. Prayank explained that their idea of decentralized storage for Bitcoin projects involves using torrents for files and communication with Tor. They also suggested the inclusion of an easy-to-use API for saving, reading, editing, etc., specifically for Bitcoin projects utilizing torrents. Payments through the Lightning Network would only be involved when spamming becomes an issue.Christopher expressed agreement with Prayank's suggestion of defining an API for both proposals and keeping it in a separate document from the BIPs. He also agreed with Prayank's opinion on the use of Tor. Christopher mentioned that he has been using the BIP format for his proposals, including the one being discussed, as well as other BIPs he is currently working on. However, he expressed openness to changing the format if it is decided that there is a better one for these BIPs. Christopher also brought up the incentivized moderation protocol, which is mentioned in the BIP under consideration.The writer of the context is conducting research on decentralized storage for a Bitcoin project and expresses interest in the concept. They suggest that including implementation or proof of concept code in the BIP would have been preferable, but since it involves the Lightning Network, it could potentially be its own LN project. The writer provides two links, bkiac/tarnhelm and ElementsProject/filebazaar, as potentially helpful resources for Christopher. They also explain their belief that decentralized storage utilizing torrents with Tor can be beneficial for Bitcoin projects. The writer proposes the creation of an easy-to-use API for various functions in Bitcoin projects using torrents, with payments through the Lightning Network only being involved when spamming becomes a concern. Additionally, they share a link to a project called JoinMarket-Org/joinmarket-clientserver/issues/415, which explores similar options. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Block-weight-penalty-for-UTXO-set-growth.xml b/static/bitcoin-dev/April_2021/combined_Block-weight-penalty-for-UTXO-set-growth.xml index 4e72577a45..9444c18574 100644 --- a/static/bitcoin-dev/April_2021/combined_Block-weight-penalty-for-UTXO-set-growth.xml +++ b/static/bitcoin-dev/April_2021/combined_Block-weight-penalty-for-UTXO-set-growth.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Block weight penalty for UTXO set growth - 2023-08-02T03:38:55.546110+00:00 - - Prayank 2021-04-21 04:59:56+00:00 - - - yanmaani at cock.li 2021-04-20 01:22:34+00:00 - + 2025-09-26T15:44:37.859301+00:00 + python-feedgen + + + [bitcoin-dev] Block weight penalty for UTXO set growth yanmaani + 2021-04-20T01:22:00.000Z + + + Prayank + 2021-04-21T04:59:00.000Z + + - python-feedgen + 2 Combined summary - Block weight penalty for UTXO set growth - 2023-08-02T03:38:55.546110+00:00 + 2025-09-26T15:44:37.859815+00:00 - In a conversation between Prayank and Yanmaani, it is mentioned that UTXO consolidation is already incentivized. When the fee rates are low, consolidating can save money and reduce the size of the UTXO set for Bitcoin full node operators. However, there are privacy concerns regarding post coinjoin. Prayank expresses uncertainty about Yanmaani's proposal, particularly regarding the part about fees decreasing due to smaller blocks. They believe that fees should actually increase if such blocks are regularly mined and predictable.To address the unconstrained growth of Bitcoin's UTXO set, a suggestion is made to add a block weight penalty for UTXO creation and a bonus for UTXO destruction. The net change in UTXOs within each block would be calculated to determine the weight limit, which would be reduced by the penalty. For example, if the penalty is 10 vB/UTXO, a block with a net change of +256 would be 10 * 256 = 2560 vB smaller. This reduction in size could potentially decrease transaction fees by 0.00384000 BTC ($230 at current prices). Alternatively, the penalty could be in the form of coins, requiring miners to fail to claim/burn an equivalent amount of subsidy.It is important to note that the weight limit or block reward cannot be increased. Therefore, three possible solutions have been proposed. The first option suggests allowing any excess weight to be wasted, meaning miners would only use consolidated UTXOs to offset new ones. The second option involves slightly decreasing the weight limit by 1%, giving miners an incentive to consolidate UTXOs up to that limit. The third option proposes increasing the weight limit, but only if miners consolidate enough UTXOs. However, this would make it more difficult for low-fee transactions to be confirmed, and miners might create dust UTXOs to destroy on blocks with higher fees, thereby freeing up capacity.This proposal raises questions about whether it has been discussed before and invites thoughts on the matter. 2021-04-21T04:59:56+00:00 + In a conversation between Prayank and Yanmaani, it is mentioned that UTXO consolidation is already incentivized. When the fee rates are low, consolidating can save money and reduce the size of the UTXO set for Bitcoin full node operators. However, there are privacy concerns regarding post coinjoin. Prayank expresses uncertainty about Yanmaani's proposal, particularly regarding the part about fees decreasing due to smaller blocks. They believe that fees should actually increase if such blocks are regularly mined and predictable.To address the unconstrained growth of Bitcoin's UTXO set, a suggestion is made to add a block weight penalty for UTXO creation and a bonus for UTXO destruction. The net change in UTXOs within each block would be calculated to determine the weight limit, which would be reduced by the penalty. For example, if the penalty is 10 vB/UTXO, a block with a net change of +256 would be 10 * 256 = 2560 vB smaller. This reduction in size could potentially decrease transaction fees by 0.00384000 BTC ($230 at current prices). Alternatively, the penalty could be in the form of coins, requiring miners to fail to claim/burn an equivalent amount of subsidy.It is important to note that the weight limit or block reward cannot be increased. Therefore, three possible solutions have been proposed. The first option suggests allowing any excess weight to be wasted, meaning miners would only use consolidated UTXOs to offset new ones. The second option involves slightly decreasing the weight limit by 1%, giving miners an incentive to consolidate UTXOs up to that limit. The third option proposes increasing the weight limit, but only if miners consolidate enough UTXOs. However, this would make it more difficult for low-fee transactions to be confirmed, and miners might create dust UTXOs to destroy on blocks with higher fees, thereby freeing up capacity.This proposal raises questions about whether it has been discussed before and invites thoughts on the matter. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Decentralized-Naming-Protocol-BIP.xml b/static/bitcoin-dev/April_2021/combined_Decentralized-Naming-Protocol-BIP.xml index b09afe049f..ea89186e5a 100644 --- a/static/bitcoin-dev/April_2021/combined_Decentralized-Naming-Protocol-BIP.xml +++ b/static/bitcoin-dev/April_2021/combined_Decentralized-Naming-Protocol-BIP.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Decentralized Naming Protocol BIP - 2023-08-02T03:39:56.441084+00:00 - - Christopher Gilliard 2021-04-22 21:32:19+00:00 - - - yanmaani at cock.li 2021-04-22 20:55:22+00:00 - - - Christopher Gilliard 2021-04-21 20:28:15+00:00 - + 2025-09-26T15:45:26.187249+00:00 + python-feedgen + + + [bitcoin-dev] Decentralized Naming Protocol BIP Christopher Gilliard + 2021-04-21T20:28:00.000Z + + + yanmaani + 2021-04-22T20:55:00.000Z + + + Christopher Gilliard + 2021-04-22T21:32:00.000Z + + - python-feedgen + 2 Combined summary - Decentralized Naming Protocol BIP - 2023-08-02T03:39:56.441084+00:00 + 2025-09-26T15:45:26.187814+00:00 - Christopher Gilliard, a member of the cryptocurrency community, has created a new Bitcoin Improvement Proposal (BIP) that introduces a decentralized naming protocol. This BIP, which can be found on GitHub, is associated with other recent BIPs that have been sent to the bitcoin-dev mailing list. The proposed protocol aims to provide a more efficient method for naming and identifying various elements within the blockchain network.The protocol outlined in Gilliard's BIP maps names to onion addresses instead of IPs, and it is integrated into the other systems he has proposed. It is worth noting that one respondent to the mailing list mentioned that the protocol appeared similar to Namecoin, a decentralized naming system built on top of the Bitcoin blockchain. However, Gilliard did not respond to this comment.At present, there is limited information available regarding how Gilliard's proposal will differ from existing systems like Namecoin or whether it will gain traction in the cryptocurrency community. There have been no further updates or announcements regarding the proposed protocol. Therefore, it remains to be seen how this new naming protocol will be received and if it will bring any significant changes to the cryptocurrency space.For those interested in reviewing the details of Gilliard's BIP or providing feedback, questions, or comments, the BIP can be accessed on GitHub at https://github.com/cgilliard/bips/blob/naming/bip-XXXX.mediawiki. 2021-04-22T21:32:19+00:00 + Christopher Gilliard, a member of the cryptocurrency community, has created a new Bitcoin Improvement Proposal (BIP) that introduces a decentralized naming protocol. This BIP, which can be found on GitHub, is associated with other recent BIPs that have been sent to the bitcoin-dev mailing list. The proposed protocol aims to provide a more efficient method for naming and identifying various elements within the blockchain network.The protocol outlined in Gilliard's BIP maps names to onion addresses instead of IPs, and it is integrated into the other systems he has proposed. It is worth noting that one respondent to the mailing list mentioned that the protocol appeared similar to Namecoin, a decentralized naming system built on top of the Bitcoin blockchain. However, Gilliard did not respond to this comment.At present, there is limited information available regarding how Gilliard's proposal will differ from existing systems like Namecoin or whether it will gain traction in the cryptocurrency community. There have been no further updates or announcements regarding the proposed protocol. Therefore, it remains to be seen how this new naming protocol will be received and if it will bring any significant changes to the cryptocurrency space.For those interested in reviewing the details of Gilliard's BIP or providing feedback, questions, or comments, the BIP can be accessed on GitHub at https://github.com/cgilliard/bips/blob/naming/bip-XXXX.mediawiki. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Designing-Bitcoin-Smart-Contracts-with-Sapio-available-on-Mainnet-today-.xml b/static/bitcoin-dev/April_2021/combined_Designing-Bitcoin-Smart-Contracts-with-Sapio-available-on-Mainnet-today-.xml index c94d2459fb..94d7f28760 100644 --- a/static/bitcoin-dev/April_2021/combined_Designing-Bitcoin-Smart-Contracts-with-Sapio-available-on-Mainnet-today-.xml +++ b/static/bitcoin-dev/April_2021/combined_Designing-Bitcoin-Smart-Contracts-with-Sapio-available-on-Mainnet-today-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today) - 2023-08-02T03:33:33.928834+00:00 - - Jeremy 2021-04-16 18:12:10+00:00 - - - ZmnSCPxj 2021-04-16 14:35:31+00:00 - - - Jeremy 2021-04-09 03:57:39+00:00 - + 2025-09-26T15:45:09.463623+00:00 + python-feedgen + + + [bitcoin-dev] Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today) Jeremy + 2021-04-09T03:57:00.000Z + + + ZmnSCPxj + 2021-04-16T14:35:00.000Z + + + Jeremy + 2021-04-16T18:12:00.000Z + + - python-feedgen + 2 Combined summary - Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today) - 2023-08-02T03:33:33.928834+00:00 + 2025-09-26T15:45:09.464233+00:00 - Jeremy Rubin has introduced Sapio, a shallow e-DSL built in Rust for Bitcoin smart contract programming flows. Inspired by his experience with BlueSpec and transaction circuits, Sapio aims to be Turing complete for federated operators and allows for tracking logic via updatable finish clauses while producing a finite deterministic "binary" of transactions. It plans to integrate Miniscript as the backend key description language and is similar to Solidity, but with Solidity contracts being "stateless". The hosting language is full, general, and Turing-complete, complementing the non-Turing-complete contract description. ZmnSCPxj suggests a language design with two layers, a non-Turing-complete total "base language" and a syntax meta-language similar to Scheme `syntax-rules`, which can construct ASTs for the "base language". This design allows developers to observe whether the meta-program halts and strike a balance between human brain input bandwidth and limited processing power.ZmnSCPxj, a Bitcoin developer, introduces Sapio to the Bitcoin Developers community and agrees with the rant on monetary units. In C-Lightning, values are output as strings with an explicit `msat` unit, even for on-chain values. He prefers a non-embedded DSL over an embedded one, as it requires users to learn two languages. He proposes using a non-Turing-complete total "base language" and a syntax meta-language similar to Scheme `syntax-rules` for designing a more effective language. This scheme provides developers with the ability to observe whether the meta-program halts and assures end-users that the program will terminate. ZmnSCPxj emphasizes the importance of striking a balance between the low input bandwidth of human brains and their limited processing power.Sapio is an innovative tool that enables Bitcoin developers to create smart contracts in an intuitive, safe, and composable manner. Contrary to the belief that creating complex smart contracts for Bitcoin is impossible, Sapio opens the door for easily defining new ideas. It currently works on mainnet without any protocol changes and will be compatible with BIP-119 OP_CHECKTEMPLATEVERIFY and Taproot in the future. The language has undergone significant evolution since its introduction. Those interested can learn more about what's possible by reading "Designing Bitcoin Smart Contracts with Sapio" and watching "My Reckless VR Talk". The first Sapio contract to run on mainnet, a Congestion Control Tree contract with 25 recipients, is currently being executed. The source code, arguments, compiler outputs, and transactions of this contract are available for review.The Sapio repository includes examples for derivatives, vaults, coin pools, games, side chains, and more. While these examples are not production-grade contracts, they serve as demonstrations of the potential capabilities of Sapio. Developers are encouraged to open pull requests (PRs) with their ideas or issues encountered during implementation. Tux, an experimental GUI, allows users to inspect, simulate, and interact with smart contracts. However, as the software is still a work-in-progress, it is advised to use regtest cautiously. Sufficient components of Sapio are functional enough to share the project and invite more developers to contribute or support it. Judica.org develops Sapio as a free and open-source tool for all bitcoiners. The achievement of the first mainnet Sapio contract milestone was made possible with the support of Ryan Grant, BitMEX, ACINQ, Delphi Digital, Backend Capital, Jeremy Rubin’s GitHub sponsors, and other fiscal and technical supporters. The contributions made to Miniscript and the rust-bitcoin ecosystem are also acknowledged. 2021-04-16T18:12:10+00:00 + Jeremy Rubin has introduced Sapio, a shallow e-DSL built in Rust for Bitcoin smart contract programming flows. Inspired by his experience with BlueSpec and transaction circuits, Sapio aims to be Turing complete for federated operators and allows for tracking logic via updatable finish clauses while producing a finite deterministic "binary" of transactions. It plans to integrate Miniscript as the backend key description language and is similar to Solidity, but with Solidity contracts being "stateless". The hosting language is full, general, and Turing-complete, complementing the non-Turing-complete contract description. ZmnSCPxj suggests a language design with two layers, a non-Turing-complete total "base language" and a syntax meta-language similar to Scheme `syntax-rules`, which can construct ASTs for the "base language". This design allows developers to observe whether the meta-program halts and strike a balance between human brain input bandwidth and limited processing power.ZmnSCPxj, a Bitcoin developer, introduces Sapio to the Bitcoin Developers community and agrees with the rant on monetary units. In C-Lightning, values are output as strings with an explicit `msat` unit, even for on-chain values. He prefers a non-embedded DSL over an embedded one, as it requires users to learn two languages. He proposes using a non-Turing-complete total "base language" and a syntax meta-language similar to Scheme `syntax-rules` for designing a more effective language. This scheme provides developers with the ability to observe whether the meta-program halts and assures end-users that the program will terminate. ZmnSCPxj emphasizes the importance of striking a balance between the low input bandwidth of human brains and their limited processing power.Sapio is an innovative tool that enables Bitcoin developers to create smart contracts in an intuitive, safe, and composable manner. Contrary to the belief that creating complex smart contracts for Bitcoin is impossible, Sapio opens the door for easily defining new ideas. It currently works on mainnet without any protocol changes and will be compatible with BIP-119 OP_CHECKTEMPLATEVERIFY and Taproot in the future. The language has undergone significant evolution since its introduction. Those interested can learn more about what's possible by reading "Designing Bitcoin Smart Contracts with Sapio" and watching "My Reckless VR Talk". The first Sapio contract to run on mainnet, a Congestion Control Tree contract with 25 recipients, is currently being executed. The source code, arguments, compiler outputs, and transactions of this contract are available for review.The Sapio repository includes examples for derivatives, vaults, coin pools, games, side chains, and more. While these examples are not production-grade contracts, they serve as demonstrations of the potential capabilities of Sapio. Developers are encouraged to open pull requests (PRs) with their ideas or issues encountered during implementation. Tux, an experimental GUI, allows users to inspect, simulate, and interact with smart contracts. However, as the software is still a work-in-progress, it is advised to use regtest cautiously. Sufficient components of Sapio are functional enough to share the project and invite more developers to contribute or support it. Judica.org develops Sapio as a free and open-source tool for all bitcoiners. The achievement of the first mainnet Sapio contract milestone was made possible with the support of Ryan Grant, BitMEX, ACINQ, Delphi Digital, Backend Capital, Jeremy Rubin’s GitHub sponsors, and other fiscal and technical supporters. The contributions made to Miniscript and the rust-bitcoin ecosystem are also acknowledged. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Fee-estimates-and-RBF.xml b/static/bitcoin-dev/April_2021/combined_Fee-estimates-and-RBF.xml index 5de092c4ea..49334697a4 100644 --- a/static/bitcoin-dev/April_2021/combined_Fee-estimates-and-RBF.xml +++ b/static/bitcoin-dev/April_2021/combined_Fee-estimates-and-RBF.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fee estimates and RBF - 2023-08-02T03:43:36.516184+00:00 + 2025-09-26T15:45:01.041516+00:00 + python-feedgen ZmnSCPxj 2021-05-18 13:10:12+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Fee estimates and RBF - 2023-08-02T03:43:36.516184+00:00 + 2025-09-26T15:45:01.041704+00:00 - Implementing Replace-By-Fee (RBF) in financial code presents challenges in exception handling and testing reorgs. Thorough testing is necessary, but code with many branches due to handling exceptions is difficult to cover completely. C-lightning supports RBF, but potential edge cases may cause mishandling of replaced transactions and loss of onchain funds. The combination of RBF and Child-Pays-for-Parent (CPFP) has yet to be explored fully, with potential use cases like the maker-taker model requiring careful exception handling.In a discussion on Bitcoin Stack Exchange, Jeremy and ZmnSCPxj share their thoughts on fee estimation. The recent CVE related to RBF by Antoine Riard and the differences between RBF implementation in Bitcoin Core and btcd are also discussed. However, the reasoning behind not implementing inherited signalling in Bitcoin Core remains unclear.In an email exchange, ZmnSCPxj and Prayank discuss engineering issues related to a full RBF wallet. While ZmnSCPxj believes a true full-RBF wallet should be the goal, he acknowledges the engineering challenges. He explains the process of a true full-RBF wallet and warns about race conditions when miners find new blocks while fees are being bumped. The wallet needs to track "pending spends" and correlate them with actual transactions. ZmnSCPxj also notes that spending unconfirmed inputs may not be safe due to conflicting transactions. Engineering issues pose significant challenges in achieving a true full-RBF wallet.The author of the message agrees that a "true" full-RBF wallet should be the goal for every on-chain wallet but notes the difficulties in achieving this. They explain how some wallets handle unconfirmed inputs and the simplification of database design. To achieve a true full-RBF wallet, the wallet must keep track of pending spends and correlate them with actual transactions. The author admits they have not considered all factors related to this issue.Jeremy Rubin shares a link with Prayank explaining the concept of a "fee-only" wallet. This feature allows users to arrange fee bumps using a separate wallet without disturbing on-chain dependents. It can be cheaper than RBF since users are not subject to the feerate improvement rule. Rubin suggests creating a market via LN for transaction inclusion by a particular date. Prayank raises concerns about different estimations used in wallets and proposes a three-step approach: showing mempool stats, leaving the fee rate decision to the user, and using RBF algorithms for automated bidding.In an email exchange, Jeremy Rubin shares a post on Bitcoin-dev related to background services. He highlights the potential of a separate fee-only wallet for arranging fee bumps without disturbing on-chain dependents. He suggests it could be cheaper than RBF and discusses the idea of creating a market for transaction inclusion. Prayank discusses different fee estimations and suggests sharing mempool stats and allowing users to decide the fee rate. He proposes using RBF algorithms and wonders if the proposed approach would work offline.The writer begins with personal well-being and recovery from COVID-19 before discussing Bitcoin transactions and fee estimations. They question the use of different estimations and propose showing mempool stats and allowing users to decide on the fee rate. They compare this to estimating buy orders in the BTCUSD orderbook. The writer finds current estimations misleading and suggests a three-step approach, including RBF algorithms for automated bidding. They seek input on the proposed approach and provide an example of replacing transactions with different fee rates even when offline. 2021-05-18T13:10:12+00:00 + Implementing Replace-By-Fee (RBF) in financial code presents challenges in exception handling and testing reorgs. Thorough testing is necessary, but code with many branches due to handling exceptions is difficult to cover completely. C-lightning supports RBF, but potential edge cases may cause mishandling of replaced transactions and loss of onchain funds. The combination of RBF and Child-Pays-for-Parent (CPFP) has yet to be explored fully, with potential use cases like the maker-taker model requiring careful exception handling.In a discussion on Bitcoin Stack Exchange, Jeremy and ZmnSCPxj share their thoughts on fee estimation. The recent CVE related to RBF by Antoine Riard and the differences between RBF implementation in Bitcoin Core and btcd are also discussed. However, the reasoning behind not implementing inherited signalling in Bitcoin Core remains unclear.In an email exchange, ZmnSCPxj and Prayank discuss engineering issues related to a full RBF wallet. While ZmnSCPxj believes a true full-RBF wallet should be the goal, he acknowledges the engineering challenges. He explains the process of a true full-RBF wallet and warns about race conditions when miners find new blocks while fees are being bumped. The wallet needs to track "pending spends" and correlate them with actual transactions. ZmnSCPxj also notes that spending unconfirmed inputs may not be safe due to conflicting transactions. Engineering issues pose significant challenges in achieving a true full-RBF wallet.The author of the message agrees that a "true" full-RBF wallet should be the goal for every on-chain wallet but notes the difficulties in achieving this. They explain how some wallets handle unconfirmed inputs and the simplification of database design. To achieve a true full-RBF wallet, the wallet must keep track of pending spends and correlate them with actual transactions. The author admits they have not considered all factors related to this issue.Jeremy Rubin shares a link with Prayank explaining the concept of a "fee-only" wallet. This feature allows users to arrange fee bumps using a separate wallet without disturbing on-chain dependents. It can be cheaper than RBF since users are not subject to the feerate improvement rule. Rubin suggests creating a market via LN for transaction inclusion by a particular date. Prayank raises concerns about different estimations used in wallets and proposes a three-step approach: showing mempool stats, leaving the fee rate decision to the user, and using RBF algorithms for automated bidding.In an email exchange, Jeremy Rubin shares a post on Bitcoin-dev related to background services. He highlights the potential of a separate fee-only wallet for arranging fee bumps without disturbing on-chain dependents. He suggests it could be cheaper than RBF and discusses the idea of creating a market for transaction inclusion. Prayank discusses different fee estimations and suggests sharing mempool stats and allowing users to decide the fee rate. He proposes using RBF algorithms and wonders if the proposed approach would work offline.The writer begins with personal well-being and recovery from COVID-19 before discussing Bitcoin transactions and fee estimations. They question the use of different estimations and propose showing mempool stats and allowing users to decide on the fee rate. They compare this to estimating buy orders in the BTCUSD orderbook. The writer finds current estimations misleading and suggests a three-step approach, including RBF algorithms for automated bidding. They seek input on the proposed approach and provide an example of replacing transactions with different fee rates even when offline. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Gradual-transition-to-an-alternate-proof-without-a-hard-fork-.xml b/static/bitcoin-dev/April_2021/combined_Gradual-transition-to-an-alternate-proof-without-a-hard-fork-.xml index 7f7cca8899..c571d93b8b 100644 --- a/static/bitcoin-dev/April_2021/combined_Gradual-transition-to-an-alternate-proof-without-a-hard-fork-.xml +++ b/static/bitcoin-dev/April_2021/combined_Gradual-transition-to-an-alternate-proof-without-a-hard-fork-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Gradual transition to an alternate proof without a hard fork. - 2023-08-02T03:38:04.408573+00:00 - - Erik Aronesty 2021-05-21 20:54:57+00:00 - - - Billy Tetrud 2021-05-21 20:11:27+00:00 - - - Anthony Towns 2021-04-17 11:47:17+00:00 - - - Devrandom 2021-04-17 11:19:46+00:00 - - - vjudeu 2021-04-17 09:41:44+00:00 - - - Erik Aronesty 2021-04-16 21:47:44+00:00 - - - Jeremy 2021-04-16 21:24:30+00:00 - - - Erik Aronesty 2021-04-16 20:48:35+00:00 - + 2025-09-26T15:45:28.278640+00:00 + python-feedgen + + + [bitcoin-dev] Gradual transition to an alternate proof without a hard fork Erik Aronesty + 2021-04-16T20:48:00.000Z + + + Jeremy + 2021-04-16T21:24:00.000Z + + + Erik Aronesty + 2021-04-16T21:47:00.000Z + + + vjudeu + 2021-04-17T09:41:00.000Z + + + Devrandom + 2021-04-17T11:19:00.000Z + + + Anthony Towns + 2021-04-17T11:47:00.000Z + + + Billy Tetrud + 2021-05-21T20:11:00.000Z + + + Erik Aronesty + 2021-05-21T20:54:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Gradual transition to an alternate proof without a hard fork. - 2023-08-02T03:38:04.408573+00:00 + 2025-09-26T15:45:28.279588+00:00 - A proposal has been made to switch the consensus protocol and hash function for proof of work in Bitcoin. It suggests a transitionary period where both consensus mechanisms are used, allowing miners time to manage the logistics of switching over. The goal is to smoothly switch from 100% of blocks created by the old mechanism to 0%, then gradually increase the blocks created by the new mechanism. However, there is a risk that miners may not cooperate, leading to an unfair distribution of blocks.One possibility discussed is transitioning to a proof-of-burn system, which would require burners to provide proof of burning in addition to proof of work. This would make mining more expensive and decrease the need for proof of work over time. Eventually, the required proof of burn would reach 100% of the required work to mine. It is unclear whether a hard fork would be necessary for this transition, as it could potentially be done in a back-compatible way. However, it is suggested that everyone should be running the new software by a certain date to ensure they follow the same chain.Another option considered is a soft fork to switch to a different proof-of-work algorithm. This would require miners and users to support the transition. The difficulty of proof of work would need to drop to one, and the rest would be solved by a different proof mechanism. As long as enough proof of the new mechanism is produced and most nodes use upgraded software, it should be resistant to attacks. However, gaining support from miners and users may be challenging.The proposed transition from proof of work to proof of burn assumes the existence of a proof-of-burn model that accurately reflects the investment in ASICs for maintaining miner incentives. It suggests a gradual decrease in the need for proof of work as proof of burn becomes more prominent. It questions whether a hard fork would be necessary for this transition, as existing nodes not aware of the rules could continue to validate. However, concerns are raised about the possibility of miners not willing to switch to proof of burn and the potential for one miner to disrupt the system by ramping up difficulty.In a discussion on the bitcoin-dev mailing list, the idea of transitioning from proof of work to proof of burn is proposed. The transition would involve validating nodes requiring proof of burn in addition to proof of work, gradually decreasing the need for proof of work. Eventually, proof of burn would be required at 100% of the "required work" to mine. It is suggested that a hard fork may not be necessary for this transition, as it could be done in a back-compatible way. However, concerns are raised about miners not cooperating and the potential for one miner to increase difficulty for everyone else.Overall, the proposals put forth aim to transition from proof of work to alternative consensus mechanisms such as proof of burn. The transition would require careful planning and coordination among miners and users to ensure a smooth switch over. The necessity of a hard fork or soft fork depends on the specific approach taken, but both options have their challenges and considerations. 2021-05-21T20:54:57+00:00 + A proposal has been made to switch the consensus protocol and hash function for proof of work in Bitcoin. It suggests a transitionary period where both consensus mechanisms are used, allowing miners time to manage the logistics of switching over. The goal is to smoothly switch from 100% of blocks created by the old mechanism to 0%, then gradually increase the blocks created by the new mechanism. However, there is a risk that miners may not cooperate, leading to an unfair distribution of blocks.One possibility discussed is transitioning to a proof-of-burn system, which would require burners to provide proof of burning in addition to proof of work. This would make mining more expensive and decrease the need for proof of work over time. Eventually, the required proof of burn would reach 100% of the required work to mine. It is unclear whether a hard fork would be necessary for this transition, as it could potentially be done in a back-compatible way. However, it is suggested that everyone should be running the new software by a certain date to ensure they follow the same chain.Another option considered is a soft fork to switch to a different proof-of-work algorithm. This would require miners and users to support the transition. The difficulty of proof of work would need to drop to one, and the rest would be solved by a different proof mechanism. As long as enough proof of the new mechanism is produced and most nodes use upgraded software, it should be resistant to attacks. However, gaining support from miners and users may be challenging.The proposed transition from proof of work to proof of burn assumes the existence of a proof-of-burn model that accurately reflects the investment in ASICs for maintaining miner incentives. It suggests a gradual decrease in the need for proof of work as proof of burn becomes more prominent. It questions whether a hard fork would be necessary for this transition, as existing nodes not aware of the rules could continue to validate. However, concerns are raised about the possibility of miners not willing to switch to proof of burn and the potential for one miner to disrupt the system by ramping up difficulty.In a discussion on the bitcoin-dev mailing list, the idea of transitioning from proof of work to proof of burn is proposed. The transition would involve validating nodes requiring proof of burn in addition to proof of work, gradually decreasing the need for proof of work. Eventually, proof of burn would be required at 100% of the "required work" to mine. It is suggested that a hard fork may not be necessary for this transition, as it could be done in a back-compatible way. However, concerns are raised about miners not cooperating and the potential for one miner to increase difficulty for everyone else.Overall, the proposals put forth aim to transition from proof of work to alternative consensus mechanisms such as proof of burn. The transition would require careful planning and coordination among miners and users to ensure a smooth switch over. The necessity of a hard fork or soft fork depends on the specific approach taken, but both options have their challenges and considerations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_L2s-Onchain-Support-IRC-Workshop.xml b/static/bitcoin-dev/April_2021/combined_L2s-Onchain-Support-IRC-Workshop.xml index 96c823eeec..99982217dc 100644 --- a/static/bitcoin-dev/April_2021/combined_L2s-Onchain-Support-IRC-Workshop.xml +++ b/static/bitcoin-dev/April_2021/combined_L2s-Onchain-Support-IRC-Workshop.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - L2s Onchain Support IRC Workshop - 2023-08-02T03:40:40.608811+00:00 - - Antoine Riard 2021-04-27 14:54:12+00:00 - - - Gloria Zhao 2021-04-26 23:06:34+00:00 - - - Bastien TEINTURIER 2021-04-23 16:17:36+00:00 - - - Antoine Riard 2021-04-23 15:39:15+00:00 - - - Jeremy 2021-04-23 15:25:19+00:00 - - - Antoine Riard 2021-04-23 15:11:56+00:00 - + 2025-09-26T15:45:15.738050+00:00 + python-feedgen + + + [bitcoin-dev] L2s Onchain Support IRC Workshop Antoine Riard + 2021-04-23T15:11:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Jeremy + 2021-04-23T15:25:00.000Z + + + Antoine Riard + 2021-04-23T15:39:00.000Z + + + Bastien TEINTURIER + 2021-04-23T16:17:00.000Z + + + [bitcoin-dev] " Gloria Zhao + 2021-04-26T23:06:00.000Z + + + Antoine Riard + 2021-04-27T14:54:00.000Z + + - python-feedgen + 2 Combined summary - L2s Onchain Support IRC Workshop - 2023-08-02T03:40:40.608811+00:00 + 2025-09-26T15:45:15.739012+00:00 - Antoine Riard, a developer, has proposed a series of online meetings to address security and operational concerns for Lightning and other Bitcoin second-layers. Due to travel restrictions, in-person workshops are not possible this year. The proposed discussion topics include package relay design, deprecation of opt-in RBF towards full-RBF, coordinated cross-layers security disclosures, and L2 protocols onchain security design.Gloria, a Bitcoin developer, has expressed interest in joining the discussion regarding tx-relay and mempool acceptance rules of the base layer. She suggests that the discussion should cover topics such as package relay design and sponsorship as separate discussions. Gloria also recommends being concrete and providing test vectors to create a stable API/set of assumptions between layers.The primary goals of the discussion are to reach technical consensus, establish a security incident response policy, and develop philosophy designs and associated documentations (BIPs, best practices, etc.). A two-week consultation period has been proposed to submit additional topics related to tx-relay or mempools improvements toward L2s before finalizing the scope and agenda.The IRC meetings are planned to be held in late May to early June. Antoine Riard has already started collecting documents on GitHub to assist with the workshop. However, Gloria notes that there is a lack of normative, reliable rules and documentation surrounding tx-relay and mempool acceptances. L2 projects maintainers should be prepared to upgrade their protocols in emergencies in coordination with base layer developers.Overall, the proposal aims to address the security and operational concerns of Lightning and Bitcoin second-layers through virtual meetings, with the goal of improving tx-relay and mempool acceptance rules. The timeline includes a consultation period, submission of additional topics, and the actual IRC meetings. Antoine Riard's collection of documents on GitHub is available to assist with the workshop, and interested individuals are encouraged to get involved. 2021-04-27T14:54:12+00:00 + Antoine Riard, a developer, has proposed a series of online meetings to address security and operational concerns for Lightning and other Bitcoin second-layers. Due to travel restrictions, in-person workshops are not possible this year. The proposed discussion topics include package relay design, deprecation of opt-in RBF towards full-RBF, coordinated cross-layers security disclosures, and L2 protocols onchain security design.Gloria, a Bitcoin developer, has expressed interest in joining the discussion regarding tx-relay and mempool acceptance rules of the base layer. She suggests that the discussion should cover topics such as package relay design and sponsorship as separate discussions. Gloria also recommends being concrete and providing test vectors to create a stable API/set of assumptions between layers.The primary goals of the discussion are to reach technical consensus, establish a security incident response policy, and develop philosophy designs and associated documentations (BIPs, best practices, etc.). A two-week consultation period has been proposed to submit additional topics related to tx-relay or mempools improvements toward L2s before finalizing the scope and agenda.The IRC meetings are planned to be held in late May to early June. Antoine Riard has already started collecting documents on GitHub to assist with the workshop. However, Gloria notes that there is a lack of normative, reliable rules and documentation surrounding tx-relay and mempool acceptances. L2 projects maintainers should be prepared to upgrade their protocols in emergencies in coordination with base layer developers.Overall, the proposal aims to address the security and operational concerns of Lightning and Bitcoin second-layers through virtual meetings, with the goal of improving tx-relay and mempool acceptance rules. The timeline includes a consultation period, submission of additional topics, and the actual IRC meetings. Antoine Riard's collection of documents on GitHub is available to assist with the workshop, and interested individuals are encouraged to get involved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml b/static/bitcoin-dev/April_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml index c661cce9c0..8bec6b2da4 100644 --- a/static/bitcoin-dev/April_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml +++ b/static/bitcoin-dev/April_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - March 23rd 2021 Taproot Activation Meeting Notes - 2023-08-02T03:29:44.650329+00:00 + 2025-09-26T15:44:42.088276+00:00 + python-feedgen Anthony Towns 2021-04-08 11:11:06+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - March 23rd 2021 Taproot Activation Meeting Notes - 2023-08-02T03:29:44.651293+00:00 + 2025-09-26T15:44:42.088472+00:00 - In recent discussions on the bitcoin-dev mailing list, the focus has been on establishing developer and user consensus for Bitcoin. One suggestion is to create a contingency plan for a chain split, which some argue is good preparation. However, others believe that this approach does not address the underlying issue of consensus. The ideal scenario would allow users to download any version of bitcoind and run it with default settings, confident in the validity of their payments. Third-party explorers can track invalid chains, but these measures are only useful after a split has occurred. The risk of a split is higher during an attack on Bitcoin. Suggestions like lockinontimeout have been made, but they are not seen as the ideal solution. Businesses accepting Bitcoin payments need to know what software to run to stay in consensus with the network. Streamlining the consensus-building process is crucial. One possible solution is to implement an approach dealing with miners who don't upgrade to enforce a soft-fork quickly.Another thread discussed the Signet-based Taproot activation proposal. Different opinions were expressed regarding whether to use a Lot=false compromise or embrace brinkmanship tooling. Some argued that de-escalation in the strategy toolkit makes Bitcoin stronger, while others disagreed and emphasized the lack of agreement on a grand plan. Downsides of using LOT=true were mentioned, including dropping blocks from apathetic miners and the risk of a split. However, tracking economic majority is already possible based on previous experiences. The disagreement continued regarding the normalization of brinkmanship, with some members highlighting the need to optimize for a reliable Bitcoin and avoid strife.Claus Ehrenberg suggested that Taproot should be activated if either miners or users decide for it, with a chain split as the fairest way to resolve conflicts. Rusty Russell proposed the Speedy Trial approach, pretending that miners were not asked, and letting users ultimately decide. Preparation for a UASF branch along with ST was also discussed.The Bitcoin development community discussed the implementation of Taproot and parameter selection for an upcoming release. They targeted a May 1st release date and discussed the use of block heights or MTP for signaling periods. The team considered the advantages and disadvantages of each approach and adjusted the timing and other parameters based on preferences and technical considerations.Jeremy Rubin accused Michael Folkson of being disingenuous in his response and disagreed with his rejection of MTP-based ST. Folkson expressed his preference for consistent use of block heights and rejected the idea of using a mix of block heights and MTP in the same activation mechanism.Overall, the discussions revolve around finding the best approach to establish consensus for Bitcoin, activate Taproot, and handle potential challenges such as chain splits and miners failing to upgrade. The community aims to optimize the decision-making process, ensure payment validity, and strengthen the Bitcoin network.During a recent meeting on the activation mechanism for Taproot, there was a discussion about using block heights consistently or a mix of block heights and MTP. Michael Folkson preferred consistent use of block heights and disagreed with using a mix. The meeting also addressed the use of a speedy trial variant, which received no new objections. However, there was uncertainty about Rusty Russell's objection and whether it remains if sufficiently addressed.There was no consensus reached on selecting between block heights and MTP. Parameter selection discussions included targeting a May 1st release, specific start and stop times, and activation height proposals. It was agreed that November 15th should remain a target date, with limited belief that the release could be stretched into June if necessary.Simultaneous User Activated Soft Fork (UASF) was also discussed, with luke-jr suggesting that a UASF client must be able to release before the Taproot client. However, this sentiment was not shared by others, and it was agreed that a UASF can proceed independently of Taproot. Additionally, luke-jr objected to using MTP in combination with Taproot, while Jeremy Rubin objected to using block heights, citing concerns about avoiding contentious forks. 2021-04-08T11:11:06+00:00 + In recent discussions on the bitcoin-dev mailing list, the focus has been on establishing developer and user consensus for Bitcoin. One suggestion is to create a contingency plan for a chain split, which some argue is good preparation. However, others believe that this approach does not address the underlying issue of consensus. The ideal scenario would allow users to download any version of bitcoind and run it with default settings, confident in the validity of their payments. Third-party explorers can track invalid chains, but these measures are only useful after a split has occurred. The risk of a split is higher during an attack on Bitcoin. Suggestions like lockinontimeout have been made, but they are not seen as the ideal solution. Businesses accepting Bitcoin payments need to know what software to run to stay in consensus with the network. Streamlining the consensus-building process is crucial. One possible solution is to implement an approach dealing with miners who don't upgrade to enforce a soft-fork quickly.Another thread discussed the Signet-based Taproot activation proposal. Different opinions were expressed regarding whether to use a Lot=false compromise or embrace brinkmanship tooling. Some argued that de-escalation in the strategy toolkit makes Bitcoin stronger, while others disagreed and emphasized the lack of agreement on a grand plan. Downsides of using LOT=true were mentioned, including dropping blocks from apathetic miners and the risk of a split. However, tracking economic majority is already possible based on previous experiences. The disagreement continued regarding the normalization of brinkmanship, with some members highlighting the need to optimize for a reliable Bitcoin and avoid strife.Claus Ehrenberg suggested that Taproot should be activated if either miners or users decide for it, with a chain split as the fairest way to resolve conflicts. Rusty Russell proposed the Speedy Trial approach, pretending that miners were not asked, and letting users ultimately decide. Preparation for a UASF branch along with ST was also discussed.The Bitcoin development community discussed the implementation of Taproot and parameter selection for an upcoming release. They targeted a May 1st release date and discussed the use of block heights or MTP for signaling periods. The team considered the advantages and disadvantages of each approach and adjusted the timing and other parameters based on preferences and technical considerations.Jeremy Rubin accused Michael Folkson of being disingenuous in his response and disagreed with his rejection of MTP-based ST. Folkson expressed his preference for consistent use of block heights and rejected the idea of using a mix of block heights and MTP in the same activation mechanism.Overall, the discussions revolve around finding the best approach to establish consensus for Bitcoin, activate Taproot, and handle potential challenges such as chain splits and miners failing to upgrade. The community aims to optimize the decision-making process, ensure payment validity, and strengthen the Bitcoin network.During a recent meeting on the activation mechanism for Taproot, there was a discussion about using block heights consistently or a mix of block heights and MTP. Michael Folkson preferred consistent use of block heights and disagreed with using a mix. The meeting also addressed the use of a speedy trial variant, which received no new objections. However, there was uncertainty about Rusty Russell's objection and whether it remains if sufficiently addressed.There was no consensus reached on selecting between block heights and MTP. Parameter selection discussions included targeting a May 1st release, specific start and stop times, and activation height proposals. It was agreed that November 15th should remain a target date, with limited belief that the release could be stretched into June if necessary.Simultaneous User Activated Soft Fork (UASF) was also discussed, with luke-jr suggesting that a UASF client must be able to release before the Taproot client. However, this sentiment was not shared by others, and it was agreed that a UASF can proceed independently of Taproot. Additionally, luke-jr objected to using MTP in combination with Taproot, while Jeremy Rubin objected to using block heights, citing concerns about avoiding contentious forks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_New-PSBT-version-proposal.xml b/static/bitcoin-dev/April_2021/combined_New-PSBT-version-proposal.xml index cf4fd98ec8..8132dea78f 100644 --- a/static/bitcoin-dev/April_2021/combined_New-PSBT-version-proposal.xml +++ b/static/bitcoin-dev/April_2021/combined_New-PSBT-version-proposal.xml @@ -1,59 +1,47 @@ - + 2 Combined summary - New PSBT version proposal - 2023-08-02T02:54:05.328979+00:00 - - Lloyd Fournier 2021-04-05 00:35:14+00:00 - - - Lloyd Fournier 2021-03-10 00:20:58+00:00 - - - Andrew Chow 2021-01-21 19:50:45+00:00 - - - Andrew Chow 2021-01-15 17:28:09+00:00 - - - Andrew Chow 2021-01-14 17:07:44+00:00 - - - Rusty Russell 2021-01-08 00:40:06+00:00 - - - Andrew Chow 2021-01-06 23:48:31+00:00 - - - Rusty Russell 2021-01-06 23:26:25+00:00 - - - Jeremy 2021-01-02 06:34:00+00:00 - - - Andrew Chow 2020-12-23 21:32:33+00:00 - - - Andrew Chow 2020-12-23 21:30:04+00:00 - - - Andrew Poelstra 2020-12-23 15:22:01+00:00 - - - fiatjaf 2020-12-23 03:30:20+00:00 - - - Andrew Chow 2020-12-22 20:12:22+00:00 - - - Andrew Poelstra 2020-12-16 17:44:11+00:00 - - - Sanket Kanjalkar 2020-12-10 11:28:23+00:00 - - - Andrew Chow 2020-12-09 22:25:37+00:00 - + 2025-09-26T15:45:03.159250+00:00 + python-feedgen + + + Jeremy + 2021-01-02T06:34:00.000Z + + + Rusty Russell + 2021-01-06T23:26:00.000Z + + + Andrew Chow + 2021-01-06T23:48:00.000Z + + + Rusty Russell + 2021-01-08T00:40:00.000Z + + + Andrew Chow + 2021-01-14T17:07:00.000Z + + + Andrew Chow + 2021-01-15T17:28:00.000Z + + + Andrew Chow + 2021-01-21T19:50:00.000Z + + + Lloyd Fournier + 2021-03-10T00:20:00.000Z + + + Lloyd Fournier + 2021-04-05T00:35:00.000Z + + @@ -71,13 +59,13 @@ - python-feedgen + 2 Combined summary - New PSBT version proposal - 2023-08-02T02:54:05.328979+00:00 + 2025-09-26T15:45:03.160372+00:00 - A proposal has been made to introduce a new version of Partially Signed Bitcoin Transactions (PSBTs) called PSBT v1. This new version addresses deficiencies in the current PSBT v0 and allows for inputs and outputs to be added to the transaction after its creation. The primary change is that all input and output data will be contained in their respective maps, eliminating the need to parse an unsigned transaction. Several new fields will be added to support this change, including PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, and PSBT_GLOBAL_UNDER_CONSTRUCTION.Andrew Chow has also proposed another version called PSBTv2, which is a backward-incompatible update to the PSBT protocol. It introduces fields like Transaction Version, Fallback Locktime, Input Count, Output Count, and Transaction Modifiable Flags. Additionally, the process of determining the nLockTime field of a transaction is explained in detail.Rusty Russell and Andrew Chow discuss the addition of a new global field called PSBT_GLOBAL_UNDER_CONSTRUCTION in an email exchange. This field is used to signal whether inputs and outputs can be added to the PSBT. Rusty suggests flagging this by omitting redundant fields, but Andrew explains that those fields are necessary to determine the number of input and output maps. They also discuss the possibility of signed inputs being added to transactions and the complexity of allowing modification of inputs and outputs after the Creator role is done.Overall, these proposed changes aim to improve the usability and functionality of the PSBT format, allowing for easier construction of transactions and the addition of inputs and outputs as needed.Andrew Chow has proposed a new version of Partially Signed Bitcoin Transactions (PSBT), called PSBT v1, to address the deficiencies in the current PSBT v0. The primary change in the new version is to have all input and output data for each contained within their respective maps, disallowing PSBT_GLOBAL_UNSIGNED_TX. Several new fields are added for Global, Input, and Output, including PSBT_GLOBAL_TX_VERSION, PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, PSBT_GLOBAL_OUTPUT_COUNT, PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE, PSBT_IN_REQUIRED_LOCKTIME, PSBT_OUT_VALUE, and PSBT_OUT_OUTPUT_SCRIPT.These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, care must be taken to ensure that adding additional inputs and outputs will not invalidate existing signatures. Finalizers must choose the maximum of all the *_LOCKTIME fields to choose the locktime for the transaction.PSBT v1 also introduces two lock time fields - one for a time-based lock time and the other for a height-based lock time. This is necessary because all inputs must use the same type of lock time (height or time). Additionally, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, is added to signal whether inputs and outputs can be added to the PSBT. Rules must be followed to ensure that adding new inputs and outputs does not invalidate existing signatures.To uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. Combiners can create an unsigned transaction given the transaction version, input prevouts, outputs, and computed locktime, which can then be used as a way to identify PSBTs.As the changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1 needs a version number bump to enforce backward incompatibility. However, once the inputs and outputs are decided, a PSBT can be downgraded back to v0 by creating an unsigned transaction from the fields mentioned above and dropping these new fields.Andrew Chow has proposed these changes in BIP 174 and is willing to write a pull request to modify it if the changes are deemed reasonable.A new version of Partially Signed Bitcoin Transaction (PSBT) has been proposed to address the deficiencies in the current PSBT v0. The main change in this proposal is to store all input and output data for each in their respective maps, eliminating the need to parse an unsigned transaction and perform a lookup for data. This change would disallow the use of the PSBT_GLOBAL_UNSIGNED_TX field in the new version.To implement these changes, several fields are suggested to be added to both the Global and Input/Output sections of PSBT. One notable addition is the PSBT_GLOBAL_PREFERRED_LOCKTIME, which specifies the locktime to use if no inputs require a specific locktime. Another important field is the PSBT_IN_REQUIRED_LOCKTIME, which is necessary for inputs involving OP_CHECKLOCKTIMEVERIFY. This field allows finalizers to choose a locktime that meets the minimum requirement without needing to understand the scripts involved.It is worth mentioning that a Bitcoin transaction only has a single locktime, while a PSBT may have multiple locktimes. Therefore, finalizers must select 2021-04-05T00:35:14+00:00 + A proposal has been made to introduce a new version of Partially Signed Bitcoin Transactions (PSBTs) called PSBT v1. This new version addresses deficiencies in the current PSBT v0 and allows for inputs and outputs to be added to the transaction after its creation. The primary change is that all input and output data will be contained in their respective maps, eliminating the need to parse an unsigned transaction. Several new fields will be added to support this change, including PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, and PSBT_GLOBAL_UNDER_CONSTRUCTION.Andrew Chow has also proposed another version called PSBTv2, which is a backward-incompatible update to the PSBT protocol. It introduces fields like Transaction Version, Fallback Locktime, Input Count, Output Count, and Transaction Modifiable Flags. Additionally, the process of determining the nLockTime field of a transaction is explained in detail.Rusty Russell and Andrew Chow discuss the addition of a new global field called PSBT_GLOBAL_UNDER_CONSTRUCTION in an email exchange. This field is used to signal whether inputs and outputs can be added to the PSBT. Rusty suggests flagging this by omitting redundant fields, but Andrew explains that those fields are necessary to determine the number of input and output maps. They also discuss the possibility of signed inputs being added to transactions and the complexity of allowing modification of inputs and outputs after the Creator role is done.Overall, these proposed changes aim to improve the usability and functionality of the PSBT format, allowing for easier construction of transactions and the addition of inputs and outputs as needed.Andrew Chow has proposed a new version of Partially Signed Bitcoin Transactions (PSBT), called PSBT v1, to address the deficiencies in the current PSBT v0. The primary change in the new version is to have all input and output data for each contained within their respective maps, disallowing PSBT_GLOBAL_UNSIGNED_TX. Several new fields are added for Global, Input, and Output, including PSBT_GLOBAL_TX_VERSION, PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, PSBT_GLOBAL_OUTPUT_COUNT, PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE, PSBT_IN_REQUIRED_LOCKTIME, PSBT_OUT_VALUE, and PSBT_OUT_OUTPUT_SCRIPT.These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, care must be taken to ensure that adding additional inputs and outputs will not invalidate existing signatures. Finalizers must choose the maximum of all the *_LOCKTIME fields to choose the locktime for the transaction.PSBT v1 also introduces two lock time fields - one for a time-based lock time and the other for a height-based lock time. This is necessary because all inputs must use the same type of lock time (height or time). Additionally, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, is added to signal whether inputs and outputs can be added to the PSBT. Rules must be followed to ensure that adding new inputs and outputs does not invalidate existing signatures.To uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. Combiners can create an unsigned transaction given the transaction version, input prevouts, outputs, and computed locktime, which can then be used as a way to identify PSBTs.As the changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1 needs a version number bump to enforce backward incompatibility. However, once the inputs and outputs are decided, a PSBT can be downgraded back to v0 by creating an unsigned transaction from the fields mentioned above and dropping these new fields.Andrew Chow has proposed these changes in BIP 174 and is willing to write a pull request to modify it if the changes are deemed reasonable.A new version of Partially Signed Bitcoin Transaction (PSBT) has been proposed to address the deficiencies in the current PSBT v0. The main change in this proposal is to store all input and output data for each in their respective maps, eliminating the need to parse an unsigned transaction and perform a lookup for data. This change would disallow the use of the PSBT_GLOBAL_UNSIGNED_TX field in the new version.To implement these changes, several fields are suggested to be added to both the Global and Input/Output sections of PSBT. One notable addition is the PSBT_GLOBAL_PREFERRED_LOCKTIME, which specifies the locktime to use if no inputs require a specific locktime. Another important field is the PSBT_IN_REQUIRED_LOCKTIME, which is necessary for inputs involving OP_CHECKLOCKTIMEVERIFY. This field allows finalizers to choose a locktime that meets the minimum requirement without needing to understand the scripts involved.It is worth mentioning that a Bitcoin transaction only has a single locktime, while a PSBT may have multiple locktimes. Therefore, finalizers must select - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml b/static/bitcoin-dev/April_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml index b85f409a74..c4deeec127 100644 --- a/static/bitcoin-dev/April_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml +++ b/static/bitcoin-dev/April_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml @@ -1,83 +1,127 @@ - + 2 Combined summary - PSA: Taproot loss of quantum protections - 2023-08-02T03:25:39.708542+00:00 - - Erik Aronesty 2021-08-12 22:08:40+00:00 - - - Lloyd Fournier 2021-04-16 05:00:07+00:00 - - - ZmnSCPxj 2021-04-16 03:47:45+00:00 - - - Lloyd Fournier 2021-04-05 00:27:50+00:00 - - - Tim Ruffing 2021-03-23 10:50:20+00:00 - - - Martin Schwarz 2021-03-23 09:36:32+00:00 - - - Erik Aronesty 2021-03-22 14:24:55+00:00 - - - Eoin McQuinn 2021-03-17 11:56:26+00:00 - - - Ryan Grant 2021-03-17 01:23:50+00:00 - - - Matt Corallo 2021-03-16 17:25:40+00:00 - - - Andrea 2021-03-16 14:10:21+00:00 - - - Andrew Poelstra 2021-03-16 13:28:34+00:00 - - - Luke Dashjr 2021-03-16 03:44:25+00:00 - - - ZmnSCPxj 2021-03-16 02:38:55+00:00 - - - Anthony Towns 2021-03-16 00:50:01+00:00 - - - David A. Harding 2021-03-16 00:24:01+00:00 - - - Lloyd Fournier 2021-03-15 23:46:05+00:00 - - - Matt Corallo 2021-03-15 23:19:22+00:00 - - - Andrew Poelstra 2021-03-15 23:12:18+00:00 - - - Karl-Johan Alm 2021-03-15 23:01:47+00:00 - - - Matt Corallo 2021-03-15 22:48:21+00:00 - - - Jeremy 2021-03-15 22:40:07+00:00 - - - Robert Spigler 2021-03-15 22:30:35+00:00 - - - Matt Corallo 2021-03-15 22:05:45+00:00 - - - Luke Dashjr 2021-03-15 21:48:15+00:00 - + 2025-09-26T15:45:07.368904+00:00 + python-feedgen + + + [bitcoin-dev] PSA: Taproot loss of quantum protections Luke Dashjr + 2021-03-15T21:48:00.000Z + + + Matt Corallo + 2021-03-15T22:05:00.000Z + + + Robert Spigler + 2021-03-15T22:30:00.000Z + + + Jeremy + 2021-03-15T22:40:00.000Z + + + Matt Corallo + 2021-03-15T22:48:00.000Z + + + Karl-Johan Alm + 2021-03-15T23:01:00.000Z + + + Andrew Poelstra + 2021-03-15T23:12:00.000Z + + + Matt Corallo + 2021-03-15T23:19:00.000Z + + + Lloyd Fournier + 2021-03-15T23:46:00.000Z + + + [bitcoin-dev] PSA: Taproot loss of quantum protections David A. Harding + 2021-03-16T00:24:00.000Z + + + Anthony Towns + 2021-03-16T00:50:00.000Z + + + ZmnSCPxj + 2021-03-16T02:38:00.000Z + + + Luke Dashjr + 2021-03-16T03:44:00.000Z + + + Andrew Poelstra + 2021-03-16T13:28:00.000Z + + + Andrea + 2021-03-16T14:10:00.000Z + + + [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections) Andrew Poelstra + 2021-03-16T15:15:00.000Z + + + Matt Corallo + 2021-03-16T17:25:00.000Z + + + Ryan Grant + 2021-03-17T01:23:00.000Z + + + ZmnSCPxj + 2021-03-17T04:24:00.000Z + + + Andrea + 2021-03-17T08:29:00.000Z + + + Eoin McQuinn + 2021-03-17T11:56:00.000Z + + + Andrea Barontini + 2021-03-20T16:31:00.000Z + + + Erik Aronesty + 2021-03-22T14:24:00.000Z + + + Martin Schwarz + 2021-03-23T09:36:00.000Z + + + Tim Ruffing + 2021-03-23T10:50:00.000Z + + + Lloyd Fournier + 2021-04-05T00:27:00.000Z + + + ZmnSCPxj + 2021-04-16T03:47:00.000Z + + + Lloyd Fournier + 2021-04-16T05:00:00.000Z + + + Erik Aronesty + 2021-08-12T22:08:00.000Z + + @@ -103,13 +147,13 @@ - python-feedgen + 2 Combined summary - PSA: Taproot loss of quantum protections - 2023-08-02T03:25:39.708542+00:00 + 2025-09-26T15:45:07.372293+00:00 - The safety of Taproot, a proposed upgrade to Bitcoin's software, has been a topic of discussion on the bitcoin-dev mailing list. Some individuals have expressed concerns about the vulnerability of Taproot to quantum computing attacks. They argue that Taproot lacks an important safety protection against quantum computers. However, others believe that there is no significant difference in terms of Bitcoin's vulnerability to quantum computing before and after Taproot.Address reuse has also been brought up as a factor in the debate. While hash-based addresses are recommended to reduce the risk of address reuse, many people still reuse Bitcoin invoice addresses. It has been pointed out that 37% of the supply is at risk of quantum attack due to this practice.Developer Mark Friedenbach is particularly concerned about Taproot's vulnerability to quantum computers. He suggests that without Taproot, the network could "pause" while a full quantum-safe solution is developed. However, with Taproot, it could become an unrecoverable situation if quantum computers come online before a solution is implemented. Friedenbach argues that Taproot does not provide any additional benefits, as the features it proposes can be implemented using hashed keys instead of raw keys. Despite these concerns, Friedenbach believes that Taproot should not be rejected and suggests adding a hash on top in an additional softfork to address the safety issue.In response to the argument that 37% of the supply being at risk is a security concern, Friedenbach suggests that social efforts discouraging address reuse can improve the situation. He also mentions that when neglected or abandoned/lost coins are compromised by quantum computers, it can be seen as equivalent to Bitcoin mining. Therefore, he argues that 37% of the supply minable by quantum computers is no different than 37% minable by ASICs.Despite the concerns raised, Taproot has entered the activation phase, and it is expected that the software will be released in the next month or two. Friedenbach recommends that anyone using Bitcoin read his article and other arguments on the topic to decide if this is a concern for them, and encourages them to make their own posts accordingly.Overall, the discussions revolve around the potential risks and mitigations related to quantum computing and Taproot in the Bitcoin ecosystem. The community is actively addressing these challenges and working towards ensuring the security and resilience of the network. 2021-08-12T22:08:40+00:00 + The safety of Taproot, a proposed upgrade to Bitcoin's software, has been a topic of discussion on the bitcoin-dev mailing list. Some individuals have expressed concerns about the vulnerability of Taproot to quantum computing attacks. They argue that Taproot lacks an important safety protection against quantum computers. However, others believe that there is no significant difference in terms of Bitcoin's vulnerability to quantum computing before and after Taproot.Address reuse has also been brought up as a factor in the debate. While hash-based addresses are recommended to reduce the risk of address reuse, many people still reuse Bitcoin invoice addresses. It has been pointed out that 37% of the supply is at risk of quantum attack due to this practice.Developer Mark Friedenbach is particularly concerned about Taproot's vulnerability to quantum computers. He suggests that without Taproot, the network could "pause" while a full quantum-safe solution is developed. However, with Taproot, it could become an unrecoverable situation if quantum computers come online before a solution is implemented. Friedenbach argues that Taproot does not provide any additional benefits, as the features it proposes can be implemented using hashed keys instead of raw keys. Despite these concerns, Friedenbach believes that Taproot should not be rejected and suggests adding a hash on top in an additional softfork to address the safety issue.In response to the argument that 37% of the supply being at risk is a security concern, Friedenbach suggests that social efforts discouraging address reuse can improve the situation. He also mentions that when neglected or abandoned/lost coins are compromised by quantum computers, it can be seen as equivalent to Bitcoin mining. Therefore, he argues that 37% of the supply minable by quantum computers is no different than 37% minable by ASICs.Despite the concerns raised, Taproot has entered the activation phase, and it is expected that the software will be released in the next month or two. Friedenbach recommends that anyone using Bitcoin read his article and other arguments on the topic to decide if this is a concern for them, and encourages them to make their own posts accordingly.Overall, the discussions revolve around the potential risks and mitigations related to quantum computing and Taproot in the Bitcoin ecosystem. The community is actively addressing these challenges and working towards ensuring the security and resilience of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Prediction-Markets-and-Bitcoin.xml b/static/bitcoin-dev/April_2021/combined_Prediction-Markets-and-Bitcoin.xml index 98ad75b819..55209e1a5e 100644 --- a/static/bitcoin-dev/April_2021/combined_Prediction-Markets-and-Bitcoin.xml +++ b/static/bitcoin-dev/April_2021/combined_Prediction-Markets-and-Bitcoin.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Prediction Markets and Bitcoin - 2023-08-02T03:32:35.386426+00:00 - - ZmnSCPxj 2021-05-18 12:15:58+00:00 - - - Prayank 2021-05-11 09:05:40+00:00 - - - ZmnSCPxj 2021-04-16 03:39:27+00:00 - - - Prayank 2021-04-07 19:07:45+00:00 - + 2025-09-26T15:44:54.718618+00:00 + python-feedgen + + + [bitcoin-dev] Prediction Markets and Bitcoin Prayank + 2021-04-07T19:07:00.000Z + + + ZmnSCPxj + 2021-04-16T03:39:00.000Z + + + Prayank + 2021-05-11T09:05:00.000Z + + + ZmnSCPxj + 2021-05-18T12:15:00.000Z + + - python-feedgen + 2 Combined summary - Prediction Markets and Bitcoin - 2023-08-02T03:32:35.386426+00:00 + 2025-09-26T15:44:54.719316+00:00 - The direction of Bitcoin development should not be solely determined by those funding it, as they may have their own opinions and influence. While a position in a futures market represents a prediction about the possible outcomes of an event, it is not equivalent to funding Bitcoin development. Bitcoin developers often have a significant stake in Bitcoin, and changes in its price can greatly affect their life savings. A position in a futures market can represent an implicit threat to "fund" or "de-fund" developers based on the direction of development.The email discusses the use of futures markets in Bitcoin, acknowledging their potential benefits for hedging and collecting information, but also warning about their potential misuse. The writer agrees that development must be free to experiment and follow what is best technically, but disagrees that development must follow the market. They argue that people funding Bitcoin development can have opinions and influence but cannot impose or force anything on the Bitcoin protocol. Prediction markets are suggested as a way to negotiate between the two aspects.The email provides examples of how futures markets can be used in Bitcoin, such as hedging transaction fees or the activation of soft forks like Taproot. However, the email also warns about issues with incentives, legality, knowledge, and volume and liquidity that could lead to incorrect usage of futures markets. The inaccuracies of prediction markets are also discussed, including past failures in predicting events such as Brexit and the 2016 US presidential elections.The CEO of Sid Meier's Alpha Centauri, Nwabudike Morgan, once stated that human behavior is economic behavior and competition for limited resources remains a constant. This statement holds true in the world of cryptocurrency and blockchain technology where every joule of negentropy is a carefully measured resource. While it is essential for development to be free and experiment with new techniques, the people funding the development must impose the direction of the development. The negotiation between these two aspects is difficult and often unclear, which is why prediction markets are necessary to advance the negotiation process.Bitcoin futures markets provide an opportunity to make money and filter out noise, but require money to participate. They can also be manipulated by exchanges or traders with large amounts of money and could distract from the development of Bitcoin itself. Prediction markets or tokens could help improve information about Bitcoin, but should not replace Bitcoin development. The writer suggests a chatroom requiring payments in satoshis as a better way to filter out noise while also supporting developers.In conclusion, the email acknowledges the role of futures markets in Bitcoin, but cautions against relying solely on them to decide important matters in Bitcoin. Instead, the writer emphasizes the importance of considering a wide range of sources such as the Bitcoin Dev Mailing List, GitHub repositories, IRC channels, and conversations with various stakeholders involved in Bitcoin. 2021-05-18T12:15:58+00:00 + The direction of Bitcoin development should not be solely determined by those funding it, as they may have their own opinions and influence. While a position in a futures market represents a prediction about the possible outcomes of an event, it is not equivalent to funding Bitcoin development. Bitcoin developers often have a significant stake in Bitcoin, and changes in its price can greatly affect their life savings. A position in a futures market can represent an implicit threat to "fund" or "de-fund" developers based on the direction of development.The email discusses the use of futures markets in Bitcoin, acknowledging their potential benefits for hedging and collecting information, but also warning about their potential misuse. The writer agrees that development must be free to experiment and follow what is best technically, but disagrees that development must follow the market. They argue that people funding Bitcoin development can have opinions and influence but cannot impose or force anything on the Bitcoin protocol. Prediction markets are suggested as a way to negotiate between the two aspects.The email provides examples of how futures markets can be used in Bitcoin, such as hedging transaction fees or the activation of soft forks like Taproot. However, the email also warns about issues with incentives, legality, knowledge, and volume and liquidity that could lead to incorrect usage of futures markets. The inaccuracies of prediction markets are also discussed, including past failures in predicting events such as Brexit and the 2016 US presidential elections.The CEO of Sid Meier's Alpha Centauri, Nwabudike Morgan, once stated that human behavior is economic behavior and competition for limited resources remains a constant. This statement holds true in the world of cryptocurrency and blockchain technology where every joule of negentropy is a carefully measured resource. While it is essential for development to be free and experiment with new techniques, the people funding the development must impose the direction of the development. The negotiation between these two aspects is difficult and often unclear, which is why prediction markets are necessary to advance the negotiation process.Bitcoin futures markets provide an opportunity to make money and filter out noise, but require money to participate. They can also be manipulated by exchanges or traders with large amounts of money and could distract from the development of Bitcoin itself. Prediction markets or tokens could help improve information about Bitcoin, but should not replace Bitcoin development. The writer suggests a chatroom requiring payments in satoshis as a better way to filter out noise while also supporting developers.In conclusion, the email acknowledges the role of futures markets in Bitcoin, but cautions against relying solely on them to decide important matters in Bitcoin. Instead, the writer emphasizes the importance of considering a wide range of sources such as the Bitcoin Dev Mailing List, GitHub repositories, IRC channels, and conversations with various stakeholders involved in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Proposal-Bitcoin-Secure-Multisig-Setup.xml b/static/bitcoin-dev/April_2021/combined_Proposal-Bitcoin-Secure-Multisig-Setup.xml index aa652fa75f..e63267dee0 100644 --- a/static/bitcoin-dev/April_2021/combined_Proposal-Bitcoin-Secure-Multisig-Setup.xml +++ b/static/bitcoin-dev/April_2021/combined_Proposal-Bitcoin-Secure-Multisig-Setup.xml @@ -1,119 +1,159 @@ - + 2 Combined summary - Proposal: Bitcoin Secure Multisig Setup - 2023-08-02T03:06:18.370020+00:00 - - Robert Spigler 2021-04-12 20:43:39+00:00 - - - Christopher Allen 2021-04-12 18:45:27+00:00 - - - Hugo Nguyen 2021-04-12 17:55:36+00:00 - - - Salvatore Ingala 2021-04-12 15:03:12+00:00 - - - Hugo Nguyen 2021-04-11 16:45:00+00:00 - - - Michael.flaxman 2021-04-11 02:34:21+00:00 - - - Robert Spigler 2021-04-10 19:32:25+00:00 - - - Erik Aronesty 2021-04-10 13:53:20+00:00 - - - Sjors Provoost 2021-04-09 15:33:31+00:00 - - - Hugo Nguyen 2021-04-09 14:54:11+00:00 - - - Hugo Nguyen 2021-04-09 14:09:51+00:00 - - - Sjors Provoost 2021-04-09 12:07:05+00:00 - - - Hugo Nguyen 2021-04-05 07:02:45+00:00 - - - Hugo Nguyen 2021-02-15 16:45:10+00:00 - - - Hugo Nguyen 2021-02-15 14:19:14+00:00 - - - Craig Raw 2021-02-15 13:53:05+00:00 - - - Hugo Nguyen 2021-02-15 08:44:19+00:00 - - - Dmitry Petukhov 2021-02-14 11:28:58+00:00 - - - Dmitry Petukhov 2021-02-14 10:37:52+00:00 - - - Hugo Nguyen 2021-02-12 17:54:57+00:00 - - - Dmitry Petukhov 2021-02-12 17:48:09+00:00 - - - Dmitry Petukhov 2021-02-12 17:42:31+00:00 - - - Hugo Nguyen 2021-02-12 16:55:55+00:00 - - - Peter D. Gray 2021-02-12 13:48:16+00:00 - - - Hugo Nguyen 2021-02-12 12:31:24+00:00 - - - Christopher Allen 2021-02-11 22:29:46+00:00 - - - Hugo Nguyen 2021-02-11 19:11:45+00:00 - - - Hugo Nguyen 2021-02-11 19:11:11+00:00 - - - Dmitry Petukhov 2021-02-11 16:29:10+00:00 - - - Hugo Nguyen 2021-02-11 13:45:33+00:00 - - - Pavol Rusnak 2021-02-11 13:25:08+00:00 - - - Hugo Nguyen 2021-02-09 10:58:06+00:00 - - - Hugo Nguyen 2021-02-09 10:05:54+00:00 - - - Hugo Nguyen 2021-02-09 09:45:48+00:00 - - - Christopher Allen 2021-02-09 09:38:43+00:00 - - - Craig Raw 2021-02-09 09:33:38+00:00 - - - Hugo Nguyen 2021-02-08 23:14:17+00:00 - + 2025-09-26T15:44:50.527239+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup Hugo Nguyen + 2021-02-08T23:14:00.000Z + + + Craig Raw + 2021-02-09T09:33:00.000Z + + + Christopher Allen + 2021-02-09T09:38:00.000Z + + + Hugo Nguyen + 2021-02-09T09:45:00.000Z + + + Hugo Nguyen + 2021-02-09T10:05:00.000Z + + + Hugo Nguyen + 2021-02-09T10:58:00.000Z + + + Pavol Rusnak + 2021-02-11T13:25:00.000Z + + + Hugo Nguyen + 2021-02-11T13:45:00.000Z + + + Dmitry Petukhov + 2021-02-11T16:29:00.000Z + + + Hugo Nguyen + 2021-02-11T19:11:00.000Z + + + Hugo Nguyen + 2021-02-11T19:11:00.000Z + + + Christopher Allen + 2021-02-11T22:29:00.000Z + + + Hugo Nguyen + 2021-02-12T12:31:00.000Z + + + Peter D. Gray + 2021-02-12T13:48:00.000Z + + + Hugo Nguyen + 2021-02-12T16:55:00.000Z + + + Dmitry Petukhov + 2021-02-12T17:42:00.000Z + + + Dmitry Petukhov + 2021-02-12T17:48:00.000Z + + + Hugo Nguyen + 2021-02-12T17:54:00.000Z + + + Dmitry Petukhov + 2021-02-14T10:37:00.000Z + + + Dmitry Petukhov + 2021-02-14T11:28:00.000Z + + + Hugo Nguyen + 2021-02-15T08:44:00.000Z + + + Craig Raw + 2021-02-15T13:53:00.000Z + + + Hugo Nguyen + 2021-02-15T14:19:00.000Z + + + Hugo Nguyen + 2021-02-15T16:45:00.000Z + + + Hugo Nguyen + 2021-04-05T07:02:00.000Z + + + Sjors Provoost + 2021-04-09T12:07:00.000Z + + + Hugo Nguyen + 2021-04-09T14:09:00.000Z + + + Hugo Nguyen + 2021-04-09T14:54:00.000Z + + + Sjors Provoost + 2021-04-09T15:33:00.000Z + + + Erik Aronesty + 2021-04-10T13:53:00.000Z + + + Robert Spigler + 2021-04-10T19:32:00.000Z + + + Michael.flaxman + 2021-04-11T02:34:00.000Z + + + Hugo Nguyen + 2021-04-11T16:45:00.000Z + + + Salvatore Ingala + 2021-04-12T15:03:00.000Z + + + Hugo Nguyen + 2021-04-12T17:55:00.000Z + + + Christopher Allen + 2021-04-12T18:45:00.000Z + + + Robert Spigler + 2021-04-12T20:43:00.000Z + + @@ -151,13 +191,13 @@ - python-feedgen + 2 Combined summary - Proposal: Bitcoin Secure Multisig Setup - 2023-08-02T03:06:18.371020+00:00 + 2025-09-26T15:44:50.530682+00:00 - In a recent discussion on the bitcoin-dev mailing list, Christopher Allen proposed best practices for avoiding xpub reuse in multisig account creation. He recommends backing up multisig account maps and cosigner key material to enable fund recovery. It is suggested that transaction coordinators should send the cosigner "policy" and final "account map" to all cosigner wallets. These practices are possible with new generation multisig hardware and software wallets.Christopher Allen, a member of Blockchain Commons, has proposed measures to improve privacy in Bitcoin multisig accounts. He suggests that cosigner wallets and transaction coordinator services should not share the master xpub, and that the master xpub fingerprint should not be used due to privacy risks. Instead, a single parent fingerprint should be offered for each account. Transaction coordinators should also send the cosigner "policy" and final "account map" to all cosigner wallets.Salvatore Ingala and Hugo discuss the distinction between a "Signer" and a "Signing device" in a multisig setup. Salvatore proposes a wallet registration flow that allows a Signer to persist a multisig setup in its storage. Hugo emphasizes that signers must be stateful and highlights the problems with signing the descriptor record.Michael expresses concerns about the xpub validation problem and the risk of stateless hardware wallets having their xpubs swapped out. He suggests using a checksum with higher entropy to reduce xpub validation to O(n) and creating an unambiguous format for wallet ID. Hugo disagrees with going stateless and argues that signers must be stateful. Michael raises concerns about malicious receive addresses and the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP aims to set up multisig wallets securely. Michael raises concerns about the BIP's shortcomings in addressing verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption to improve privacy. The coordinator gathers key records from all participating signers and verifies their validity before generating a descriptor record. The descriptor record is encrypted and sent to all signers.In a conversation between Michael and Hugo, they discuss the issues with multisig in Bitcoin. Michael raises concerns about the xpub validation problem and the risk of compromised coordinators swapping out xpubs in stateless hardware wallets. Hugo disagrees with going stateless and highlights problems with signing the descriptor record. Michael also suggests avoiding the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP has been drafted to address concerns surrounding tampering during initial setup. Michael Flaxman expresses concerns about the BIP's failure to address verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption. The coordinator generates key records and a descriptor record, which are encrypted and sent to all signers.The context provided includes discussions on multisig setup context, the need for devices to persist the descriptor, and the redundancy of BIP48 with descriptors. It is suggested that Shamir Secret Sharing could be used for encryption convention and a preference for plain text over binary. Multisig setup context is considered important for developing multisig setups.Bitcoin Secure Multisig Setup (BSMS) proposal introduces a Coordinator and multiple Signers in the setup process. The Coordinator takes the lead in initiating the multisig setup, determining the type of multisig used, and gathering information from the signers to generate a descriptor record. Signers are responsible for providing their XPUB to the Coordinator, verifying its inclusion in the descriptor record, and persisting the record in their storage.The setup process involves two rounds of communication. In round one, the Coordinator creates a multisig wallet creation session, generates a secret token, and shares it securely with all participating signers. The signers then generate a key record by prompting the user for the token and a derivation path. In round two, the Coordinator gathers key records from all signers, decrypts them using an encryption key, verifies the included signatures, and generates a descriptor record. The descriptor record is encrypted and sent to all signers.To ensure security during setup, the proposal recommends using multi-round Distributed Key Generation (DKG) with appropriate commitments and verification of components. It also suggests using encryption conventions for the descriptor data, allowing decryption with any of the seeds to access the full setup. Additional suggestions include using magic bytes for file extensions and plaintext files for human readability.One concern raised is losing multisig setup context, which could result in lost coins. If one device is lost in a 2-of-3 setup without metadata, the coins will be lost. To address this, the proposal recommends an encryption convention that allows decryption of the full setup file with any of the seeds. It also suggests ways to communicate signers' capabilities and extend the specification with path restrictions.The document highlights the importance 2021-04-12T20:43:39+00:00 + In a recent discussion on the bitcoin-dev mailing list, Christopher Allen proposed best practices for avoiding xpub reuse in multisig account creation. He recommends backing up multisig account maps and cosigner key material to enable fund recovery. It is suggested that transaction coordinators should send the cosigner "policy" and final "account map" to all cosigner wallets. These practices are possible with new generation multisig hardware and software wallets.Christopher Allen, a member of Blockchain Commons, has proposed measures to improve privacy in Bitcoin multisig accounts. He suggests that cosigner wallets and transaction coordinator services should not share the master xpub, and that the master xpub fingerprint should not be used due to privacy risks. Instead, a single parent fingerprint should be offered for each account. Transaction coordinators should also send the cosigner "policy" and final "account map" to all cosigner wallets.Salvatore Ingala and Hugo discuss the distinction between a "Signer" and a "Signing device" in a multisig setup. Salvatore proposes a wallet registration flow that allows a Signer to persist a multisig setup in its storage. Hugo emphasizes that signers must be stateful and highlights the problems with signing the descriptor record.Michael expresses concerns about the xpub validation problem and the risk of stateless hardware wallets having their xpubs swapped out. He suggests using a checksum with higher entropy to reduce xpub validation to O(n) and creating an unambiguous format for wallet ID. Hugo disagrees with going stateless and argues that signers must be stateful. Michael raises concerns about malicious receive addresses and the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP aims to set up multisig wallets securely. Michael raises concerns about the BIP's shortcomings in addressing verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption to improve privacy. The coordinator gathers key records from all participating signers and verifies their validity before generating a descriptor record. The descriptor record is encrypted and sent to all signers.In a conversation between Michael and Hugo, they discuss the issues with multisig in Bitcoin. Michael raises concerns about the xpub validation problem and the risk of compromised coordinators swapping out xpubs in stateless hardware wallets. Hugo disagrees with going stateless and highlights problems with signing the descriptor record. Michael also suggests avoiding the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP has been drafted to address concerns surrounding tampering during initial setup. Michael Flaxman expresses concerns about the BIP's failure to address verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption. The coordinator generates key records and a descriptor record, which are encrypted and sent to all signers.The context provided includes discussions on multisig setup context, the need for devices to persist the descriptor, and the redundancy of BIP48 with descriptors. It is suggested that Shamir Secret Sharing could be used for encryption convention and a preference for plain text over binary. Multisig setup context is considered important for developing multisig setups.Bitcoin Secure Multisig Setup (BSMS) proposal introduces a Coordinator and multiple Signers in the setup process. The Coordinator takes the lead in initiating the multisig setup, determining the type of multisig used, and gathering information from the signers to generate a descriptor record. Signers are responsible for providing their XPUB to the Coordinator, verifying its inclusion in the descriptor record, and persisting the record in their storage.The setup process involves two rounds of communication. In round one, the Coordinator creates a multisig wallet creation session, generates a secret token, and shares it securely with all participating signers. The signers then generate a key record by prompting the user for the token and a derivation path. In round two, the Coordinator gathers key records from all signers, decrypts them using an encryption key, verifies the included signatures, and generates a descriptor record. The descriptor record is encrypted and sent to all signers.To ensure security during setup, the proposal recommends using multi-round Distributed Key Generation (DKG) with appropriate commitments and verification of components. It also suggests using encryption conventions for the descriptor data, allowing decryption with any of the seeds to access the full setup. Additional suggestions include using magic bytes for file extensions and plaintext files for human readability.One concern raised is losing multisig setup context, which could result in lost coins. If one device is lost in a 2-of-3 setup without metadata, the coins will be lost. To address this, the proposal recommends an encryption convention that allows decryption of the full setup file with any of the seeds. It also suggests ways to communicate signers' capabilities and extend the specification with path restrictions.The document highlights the importance - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Proposed-BIP-editor-Kalle-Alm.xml b/static/bitcoin-dev/April_2021/combined_Proposed-BIP-editor-Kalle-Alm.xml index 3cd09fafc8..a40bb6faa9 100644 --- a/static/bitcoin-dev/April_2021/combined_Proposed-BIP-editor-Kalle-Alm.xml +++ b/static/bitcoin-dev/April_2021/combined_Proposed-BIP-editor-Kalle-Alm.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - Proposed BIP editor: Kalle Alm - 2023-08-02T03:40:28.848975+00:00 - - Jameson Lopp 2021-04-30 16:58:04+00:00 - - - Karl 2021-04-30 15:39:23+00:00 - - - Amir Taaki 2021-04-28 09:52:33+00:00 - - - Jaime Caring 2021-04-27 22:30:56+00:00 - - - W. J. van der Laan 2021-04-26 18:13:43+00:00 - - - James O'Beirne 2021-04-26 16:56:19+00:00 - - - Sjors Provoost 2021-04-26 15:02:06+00:00 - - - David A. Harding 2021-04-26 00:36:40+00:00 - - - Matt Corallo 2021-04-24 14:45:46+00:00 - - - nopara73 2021-04-24 10:16:15+00:00 - - - Greg Maxwell 2021-04-24 04:42:12+00:00 - - - Antoine Riard 2021-04-23 15:34:53+00:00 - - - Eric Martindale 2021-04-23 09:11:41+00:00 - - - Pindar Wong 2021-04-23 07:50:53+00:00 - - - John Newbery 2021-04-23 07:49:39+00:00 - - - Jeremy 2021-04-23 03:36:16+00:00 - - - Luke Dashjr 2021-04-23 02:09:05+00:00 - + 2025-09-26T15:44:52.625098+00:00 + python-feedgen + + + [bitcoin-dev] Proposed BIP editor: Kalle Alm Luke Dashjr + 2021-04-23T02:09:00.000Z + + + Jeremy + 2021-04-23T03:36:00.000Z + + + John Newbery + 2021-04-23T07:49:00.000Z + + + Pindar Wong + 2021-04-23T07:50:00.000Z + + + Eric Martindale + 2021-04-23T09:11:00.000Z + + + Antoine Riard + 2021-04-23T15:34:00.000Z + + + Greg Maxwell + 2021-04-24T04:42:00.000Z + + + nopara73 + 2021-04-24T10:16:00.000Z + + + Matt Corallo + 2021-04-24T14:45:00.000Z + + + David A. Harding + 2021-04-26T00:36:00.000Z + + + [bitcoin-dev] Proposed BIP editor: Kalle Alm Sjors Provoost + 2021-04-26T15:02:00.000Z + + + James O'Beirne + 2021-04-26T16:56:00.000Z + + + W. J. van der Laan + 2021-04-26T18:13:00.000Z + + + Jaime Caring + 2021-04-27T22:30:00.000Z + + + Amir Taaki + 2021-04-28T09:52:00.000Z + + + Karl + 2021-04-30T15:39:00.000Z + + + Jameson Lopp + 2021-04-30T16:58:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - Proposed BIP editor: Kalle Alm - 2023-08-02T03:40:28.848975+00:00 + 2025-09-26T15:44:52.626959+00:00 - Amir Taaki, a former Bitcoin developer, has criticized the Bitcoin Core team for its lack of vision and long-term roadmap. He proposes that Bitcoin Core be dissolved as the official Bitcoin project and calls for a period of self-reflection to address the problems within the team. In response, some members of the Bitcoin community suggest forming a stewardship committee made up of frequent contributors to oversee the appointment of editors for the Bitcoin Improvement Proposals (BIPs).There is controversy surrounding the addition of Kalle Alm as an editor to the BIP process. Greg Maxwell opposes this addition, stating that it will not resolve the situation regarding PR1104, which has already been merged. The discussion regarding this issue takes place on the bitcoin-dev mailing list.The proposal to form a stewardship committee receives opposition, indicating that finding a resolution to the ongoing controversies within the Bitcoin community will not be easy. It is suggested that facilitation, mediation, and organization help is needed in the core development team, with the possibility of hiring experts in these areas. However, compromising on quality is cautioned against.The addition of Kalle Alm as a BIP editor is met with mixed opinions. Some express their approval, noting that it is positive to have someone else interested in the BIP maintainer role. Others raise concerns about the impact on the situation involving Luke-jr's behavior and PR1104, suggesting that automation may be necessary but with some reservations.There are discussions regarding the BIP maintainership role and whether it should be given to a bot or a human. Despite recent drama, having a single editor is deemed less than ideal due to the large number of open pull requests. The proposal to add Kalle Alm as a BIP editor follows the suggestion to use BIP 2's Process BIP progression, which allows proposals to achieve rough consensus on the mailing list before becoming active. Prior precedent exists for BIP editors appointing new editors.Greg Maxwell expresses opposition to the addition of Kalle Alm, believing it will not resolve the situation regarding PR1104. However, PR1104 has since been merged, prompting a query about Maxwell's continued opposition. Further details are not provided in the context.Antoine Riard voices his disagreement with admins of the Bitcoin GitHub organization intervening in the extension of BIP editorship membership. He suggests waiting for a solution that satisfies everyone and recommends that the BIP editorship be moved to its own repository in the future. Luke Dashjr's proposal to add Kalle Alm as a BIP editor follows the suggestion to use BIP 2's Process BIP progression, which requires rough consensus on the mailing list and no unaddressed objections before becoming active.There is a difference of opinion regarding the addition of Kalle Alm as a BIP editor. Some support the proposal, acknowledging Alm's contributions and qualifications, while others may have objections. The discussions take place on the bitcoin-dev mailing list, and no objections are raised at the time of the given context. 2021-04-30T16:58:04+00:00 + Amir Taaki, a former Bitcoin developer, has criticized the Bitcoin Core team for its lack of vision and long-term roadmap. He proposes that Bitcoin Core be dissolved as the official Bitcoin project and calls for a period of self-reflection to address the problems within the team. In response, some members of the Bitcoin community suggest forming a stewardship committee made up of frequent contributors to oversee the appointment of editors for the Bitcoin Improvement Proposals (BIPs).There is controversy surrounding the addition of Kalle Alm as an editor to the BIP process. Greg Maxwell opposes this addition, stating that it will not resolve the situation regarding PR1104, which has already been merged. The discussion regarding this issue takes place on the bitcoin-dev mailing list.The proposal to form a stewardship committee receives opposition, indicating that finding a resolution to the ongoing controversies within the Bitcoin community will not be easy. It is suggested that facilitation, mediation, and organization help is needed in the core development team, with the possibility of hiring experts in these areas. However, compromising on quality is cautioned against.The addition of Kalle Alm as a BIP editor is met with mixed opinions. Some express their approval, noting that it is positive to have someone else interested in the BIP maintainer role. Others raise concerns about the impact on the situation involving Luke-jr's behavior and PR1104, suggesting that automation may be necessary but with some reservations.There are discussions regarding the BIP maintainership role and whether it should be given to a bot or a human. Despite recent drama, having a single editor is deemed less than ideal due to the large number of open pull requests. The proposal to add Kalle Alm as a BIP editor follows the suggestion to use BIP 2's Process BIP progression, which allows proposals to achieve rough consensus on the mailing list before becoming active. Prior precedent exists for BIP editors appointing new editors.Greg Maxwell expresses opposition to the addition of Kalle Alm, believing it will not resolve the situation regarding PR1104. However, PR1104 has since been merged, prompting a query about Maxwell's continued opposition. Further details are not provided in the context.Antoine Riard voices his disagreement with admins of the Bitcoin GitHub organization intervening in the extension of BIP editorship membership. He suggests waiting for a solution that satisfies everyone and recommends that the BIP editorship be moved to its own repository in the future. Luke Dashjr's proposal to add Kalle Alm as a BIP editor follows the suggestion to use BIP 2's Process BIP progression, which requires rough consensus on the mailing list and no unaddressed objections before becoming active.There is a difference of opinion regarding the addition of Kalle Alm as a BIP editor. Some support the proposal, acknowledging Alm's contributions and qualifications, while others may have objections. The discussions take place on the bitcoin-dev mailing list, and no objections are raised at the time of the given context. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml b/static/bitcoin-dev/April_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml index 89fc3f70b9..18a1d3cdca 100644 --- a/static/bitcoin-dev/April_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml +++ b/static/bitcoin-dev/April_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reminder on the Purpose of BIPs - 2023-08-02T03:42:08.191963+00:00 + 2025-09-26T15:44:39.970908+00:00 + python-feedgen Prayank 2021-09-15 09:50:34+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Reminder on the Purpose of BIPs - 2023-08-02T03:42:08.191963+00:00 + 2025-09-26T15:44:39.971054+00:00 - During a recent meeting, the suggestion to decentralize the Bitcoin Improvement Proposals (BIPs) process was made in response to the lack of participation and discussion. The proposal aims to create multiple BIP directories to reduce dependency on one repository or a few individuals. While documentation is important, the focus should be on implementation.An example was given to demonstrate this point. Greg Maxwell proposed a solution to the mirroring issue of decentralized BIPs. He suggested assigning each BIP a genesis transaction ID that moves in time on the blockchain and mirrors the evolution in Git using commit hashes. This would provide a definitive HEAD of a BIP and its history, which can be reconstructed from any one transaction. Commit trees can be mirrored and hosted on popular sites like Github or Gitlab. The proposal also includes assigning BIP numbers in the Bitcoin repository and requiring spending money on transactions to prevent sybil attacks.David A. Harding recommended changes to the BIP process. His recommendations include adding more BIP editors, seeking the resignation of Luke Dashjr as BIP editor, and treating protocol documents outside the BIPs repository as first-class BIP documentation. He proposed an alternative to the BIPs system where anyone writing protocol documentation can post their idea to the mailing list and assign themselves a unique decentralized identifier starting with "bip-". Implementations of BIPs would link to the relevant protocol documentation. Harding's proposal aims to address issues such as users considering documents in the BIPs repo as authoritative and development teams wanting control over their own documentation.Matt Corallo criticized the BIP process, calling it a failure. W.J. van der Laan suggested decentralizing the process and adding more editors to address the bottleneck in open pull requests. Corallo also expressed frustration towards the community for irrational debates and ignoring input. The debate highlighted the need for a more decentralized approach to the BIP process.Luke Dashjr responded to accusations of deliberately refusing changes to BIPs. He denied the claims and stated that he follows the currently-defined process neutrally, despite being harassed by certain advocates. Dashjr proposed adding Kalle Alm as a BIP editor, but Antoine Riard suggested that the BIP editorship should have its own repository and follow procedural forms.Overall, there is ongoing discussion and debate about the BIP process and how it can be improved to better serve the Bitcoin community.In recent years, there has been a significant increase in the use of artificial intelligence (AI) in various industries. AI is a branch of computer science that focuses on creating intelligent machines capable of performing tasks that typically require human intelligence. It involves the development of algorithms and models that allow computers to learn from and adapt to data.One industry that has greatly benefited from the use of AI is healthcare. AI has the potential to revolutionize healthcare by improving diagnosis, treatment, and patient care. For example, AI algorithms can analyze large amounts of medical data to identify patterns and make predictions, helping doctors make more accurate diagnoses and develop personalized treatment plans. AI can also be used to monitor patients remotely, providing timely intervention and reducing the need for hospital visits.Another area where AI is making a significant impact is transportation. Self-driving cars, powered by AI technology, have the potential to reduce accidents and improve road safety. These cars are equipped with sensors and cameras that allow them to navigate and make decisions based on real-time data. AI algorithms enable the car to interpret the environment and react accordingly, ensuring a smooth and safe ride.AI is also being used in the finance industry to automate processes and enhance decision-making. For instance, AI-powered chatbots can assist customers with basic banking tasks, such as checking account balances or transferring funds. AI algorithms can also analyze financial data to detect fraud and identify investment opportunities. Additionally, AI can help financial institutions streamline operations and improve customer service through personalized recommendations.The retail industry has also embraced AI to enhance customer experience and optimize business operations. AI-powered recommendation systems analyze customer preferences and behavior to provide personalized product suggestions. This not only improves customer satisfaction but also increases sales. AI can also be used to automate inventory management, pricing strategies, and supply chain optimization, leading to cost savings and improved efficiency.In conclusion, AI is revolutionizing various industries, including healthcare, transportation, finance, and retail. Its ability to analyze large amounts of data, make predictions, and automate processes is transforming how these industries operate. As AI technology continues to advance, it is expected to have an even greater impact in the future, driving innovation and improving efficiency across multiple sectors. 2021-09-15T09:50:34+00:00 + During a recent meeting, the suggestion to decentralize the Bitcoin Improvement Proposals (BIPs) process was made in response to the lack of participation and discussion. The proposal aims to create multiple BIP directories to reduce dependency on one repository or a few individuals. While documentation is important, the focus should be on implementation.An example was given to demonstrate this point. Greg Maxwell proposed a solution to the mirroring issue of decentralized BIPs. He suggested assigning each BIP a genesis transaction ID that moves in time on the blockchain and mirrors the evolution in Git using commit hashes. This would provide a definitive HEAD of a BIP and its history, which can be reconstructed from any one transaction. Commit trees can be mirrored and hosted on popular sites like Github or Gitlab. The proposal also includes assigning BIP numbers in the Bitcoin repository and requiring spending money on transactions to prevent sybil attacks.David A. Harding recommended changes to the BIP process. His recommendations include adding more BIP editors, seeking the resignation of Luke Dashjr as BIP editor, and treating protocol documents outside the BIPs repository as first-class BIP documentation. He proposed an alternative to the BIPs system where anyone writing protocol documentation can post their idea to the mailing list and assign themselves a unique decentralized identifier starting with "bip-". Implementations of BIPs would link to the relevant protocol documentation. Harding's proposal aims to address issues such as users considering documents in the BIPs repo as authoritative and development teams wanting control over their own documentation.Matt Corallo criticized the BIP process, calling it a failure. W.J. van der Laan suggested decentralizing the process and adding more editors to address the bottleneck in open pull requests. Corallo also expressed frustration towards the community for irrational debates and ignoring input. The debate highlighted the need for a more decentralized approach to the BIP process.Luke Dashjr responded to accusations of deliberately refusing changes to BIPs. He denied the claims and stated that he follows the currently-defined process neutrally, despite being harassed by certain advocates. Dashjr proposed adding Kalle Alm as a BIP editor, but Antoine Riard suggested that the BIP editorship should have its own repository and follow procedural forms.Overall, there is ongoing discussion and debate about the BIP process and how it can be improved to better serve the Bitcoin community.In recent years, there has been a significant increase in the use of artificial intelligence (AI) in various industries. AI is a branch of computer science that focuses on creating intelligent machines capable of performing tasks that typically require human intelligence. It involves the development of algorithms and models that allow computers to learn from and adapt to data.One industry that has greatly benefited from the use of AI is healthcare. AI has the potential to revolutionize healthcare by improving diagnosis, treatment, and patient care. For example, AI algorithms can analyze large amounts of medical data to identify patterns and make predictions, helping doctors make more accurate diagnoses and develop personalized treatment plans. AI can also be used to monitor patients remotely, providing timely intervention and reducing the need for hospital visits.Another area where AI is making a significant impact is transportation. Self-driving cars, powered by AI technology, have the potential to reduce accidents and improve road safety. These cars are equipped with sensors and cameras that allow them to navigate and make decisions based on real-time data. AI algorithms enable the car to interpret the environment and react accordingly, ensuring a smooth and safe ride.AI is also being used in the finance industry to automate processes and enhance decision-making. For instance, AI-powered chatbots can assist customers with basic banking tasks, such as checking account balances or transferring funds. AI algorithms can also analyze financial data to detect fraud and identify investment opportunities. Additionally, AI can help financial institutions streamline operations and improve customer service through personalized recommendations.The retail industry has also embraced AI to enhance customer experience and optimize business operations. AI-powered recommendation systems analyze customer preferences and behavior to provide personalized product suggestions. This not only improves customer satisfaction but also increases sales. AI can also be used to automate inventory management, pricing strategies, and supply chain optimization, leading to cost savings and improved efficiency.In conclusion, AI is revolutionizing various industries, including healthcare, transportation, finance, and retail. Its ability to analyze large amounts of data, make predictions, and automate processes is transforming how these industries operate. As AI technology continues to advance, it is expected to have an even greater impact in the future, driving innovation and improving efficiency across multiple sectors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Response-to-Rusty-Russell-from-Github.xml b/static/bitcoin-dev/April_2021/combined_Response-to-Rusty-Russell-from-Github.xml index 1a6b927677..8a7dd865a0 100644 --- a/static/bitcoin-dev/April_2021/combined_Response-to-Rusty-Russell-from-Github.xml +++ b/static/bitcoin-dev/April_2021/combined_Response-to-Rusty-Russell-from-Github.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Response to Rusty Russell from Github - 2023-08-02T03:31:06.862084+00:00 - - Matt Corallo 2021-04-07 00:46:16+00:00 - - - Rusty Russell 2021-04-06 04:40:55+00:00 - - - Jeremy 2021-03-25 17:35:25+00:00 - + 2025-09-26T15:45:24.097888+00:00 + python-feedgen + + + [bitcoin-dev] Response to Rusty Russell from Github Jeremy + 2021-03-25T17:35:00.000Z + + + Rusty Russell + 2021-04-06T04:40:00.000Z + + + Matt Corallo + 2021-04-07T00:46:00.000Z + + - python-feedgen + 2 Combined summary - Response to Rusty Russell from Github - 2023-08-02T03:31:06.862084+00:00 + 2025-09-26T15:45:24.098374+00:00 - Developer Rusty Russell recently expressed his disagreement with using BIP8 with LOT configuration as a long-term solution for Bitcoin's future. In a post on bitcoin-dev, he argued that a regular flag day without signaling but openly communicated may be a better alternative. He emphasized the importance of considering infrastructure and drew parallels to the need for elections in government. Russell also outlined four reasons why a fresh release, rather than individually setting LOT configuration, could be simpler and safer. These reasons include avoiding consensus sensitivity issues, eliminating the risk of missed windows, enabling a faster soft-fail process, and preventing block invalidation if miners continue without signaling.While acknowledging that this approach isn't perfect, Russell didn't propose any immediate solutions to make it easier. He also discussed the technical aspects of BIP-8 and its effectiveness in preventing forks. With hopes of maintaining a harmonious ecosystem, he suggested that having BIP-8 deployed and ready could provide a safety net if necessary.The discussion primarily centered around the activation logic for Taproot. While Speedy Trial (ST) is not the final decision on activation logic, BIP8 with LOT configuration doesn't formalize how economic nodes send a network-legible signal before a chain split. Russell proposed a three-step process where developers release but do not activate, miners signal, and users have the option to override by compiling and releasing a patched Bitcoin with moderate changes to activate Taproot at a later date. He argued that this process is simpler and safer than using a configurable LOT.Furthermore, there was a discussion about the limitations of tying improvements together and the belief that each improvement should stand or fall on its own merits. Additionally, serious objections were raised regarding BIP8 in various deployment modes, including the risk of unnecessary chain splits, potential downtime for those running lot=true, and the possibility of reorganizations and wipeouts for those running lot=false. The author stressed the need for significant improvements in these areas.Lastly, the author suggested that once Taproot is resolved, there are other opportunities to enhance activation methodologies, such as consensus cleanup, anyprevout, ctv, graftroot, annex-based block commitments, and op_cat/covenants. 2021-04-07T00:46:16+00:00 + Developer Rusty Russell recently expressed his disagreement with using BIP8 with LOT configuration as a long-term solution for Bitcoin's future. In a post on bitcoin-dev, he argued that a regular flag day without signaling but openly communicated may be a better alternative. He emphasized the importance of considering infrastructure and drew parallels to the need for elections in government. Russell also outlined four reasons why a fresh release, rather than individually setting LOT configuration, could be simpler and safer. These reasons include avoiding consensus sensitivity issues, eliminating the risk of missed windows, enabling a faster soft-fail process, and preventing block invalidation if miners continue without signaling.While acknowledging that this approach isn't perfect, Russell didn't propose any immediate solutions to make it easier. He also discussed the technical aspects of BIP-8 and its effectiveness in preventing forks. With hopes of maintaining a harmonious ecosystem, he suggested that having BIP-8 deployed and ready could provide a safety net if necessary.The discussion primarily centered around the activation logic for Taproot. While Speedy Trial (ST) is not the final decision on activation logic, BIP8 with LOT configuration doesn't formalize how economic nodes send a network-legible signal before a chain split. Russell proposed a three-step process where developers release but do not activate, miners signal, and users have the option to override by compiling and releasing a patched Bitcoin with moderate changes to activate Taproot at a later date. He argued that this process is simpler and safer than using a configurable LOT.Furthermore, there was a discussion about the limitations of tying improvements together and the belief that each improvement should stand or fall on its own merits. Additionally, serious objections were raised regarding BIP8 in various deployment modes, including the risk of unnecessary chain splits, potential downtime for those running lot=true, and the possibility of reorganizations and wipeouts for those running lot=false. The author stressed the need for significant improvements in these areas.Lastly, the author suggested that once Taproot is resolved, there are other opportunities to enhance activation methodologies, such as consensus cleanup, anyprevout, ctv, graftroot, annex-based block commitments, and op_cat/covenants. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-4-20-Cancelled.xml b/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-4-20-Cancelled.xml index e24ad9743c..458265f538 100644 --- a/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-4-20-Cancelled.xml +++ b/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-4-20-Cancelled.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Taproot Activation Meeting 4/20 Cancelled - 2023-08-02T03:38:40.832205+00:00 - - yancy 2021-04-17 20:10:39+00:00 - - - Jeremy 2021-04-17 18:45:31+00:00 - + 2025-09-26T15:45:17.827212+00:00 + python-feedgen + + + [bitcoin-dev] Taproot Activation Meeting 4/20 Cancelled Jeremy + 2021-04-17T18:45:00.000Z + + + yancy + 2021-04-17T20:10:00.000Z + + - python-feedgen + 2 Combined summary - Taproot Activation Meeting 4/20 Cancelled - 2023-08-02T03:38:40.832205+00:00 + 2025-09-26T15:45:17.827722+00:00 - Yancy agrees with Jeremy's statement that it is time for people to enjoy the holiday. The tone of Yancy's message is appreciative and informal, signing off with "cheers". Jeremy Rubin addressed Bitcoin Developers, stating that there are currently no agenda items or technical issues to address. The Bitcoin Core team has successfully released Release Candidate 1 with Speedy Trial MTP in the pipeline. Rubin directed readers to https://github.com/bitcoin/bips/pull/1104 for more details on changes to BIP 341 made by joint agreement of many community members. He also suggested that everyone take the opportunity to enjoy the holiday given the high tensions. 2021-04-17T20:10:39+00:00 + Yancy agrees with Jeremy's statement that it is time for people to enjoy the holiday. The tone of Yancy's message is appreciative and informal, signing off with "cheers". Jeremy Rubin addressed Bitcoin Developers, stating that there are currently no agenda items or technical issues to address. The Bitcoin Core team has successfully released Release Candidate 1 with Speedy Trial MTP in the pipeline. Rubin directed readers to https://github.com/bitcoin/bips/pull/1104 for more details on changes to BIP 341 made by joint agreement of many community members. He also suggested that everyone take the opportunity to enjoy the holiday given the high tensions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-Notes-April-6th-The-CoinFlip.xml b/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-Notes-April-6th-The-CoinFlip.xml index 576bee3edc..af5cfcadab 100644 --- a/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-Notes-April-6th-The-CoinFlip.xml +++ b/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-Notes-April-6th-The-CoinFlip.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Taproot Activation Meeting Notes, April 6th: The CoinFlip - 2023-08-02T03:32:16.089247+00:00 - - Jeremy 2021-04-07 00:02:35+00:00 - - - Jeremy 2021-04-06 21:31:31+00:00 - + 2025-09-26T15:45:19.918614+00:00 + python-feedgen + + + [bitcoin-dev] Taproot Activation Meeting Notes, April 6th: The CoinFlip Jeremy + 2021-04-06T21:31:00.000Z + + + Jeremy + 2021-04-07T00:02:00.000Z + + - python-feedgen + 2 Combined summary - Taproot Activation Meeting Notes, April 6th: The CoinFlip - 2023-08-02T03:32:16.089247+00:00 + 2025-09-26T15:45:19.919016+00:00 - During the second fortnightly taproot activation meeting, Bitcoin developers discussed various topics related to the technology. One of the main points of discussion was the modifications to Median Time Past (MTP) and Height for Taproot activation. Most attendees agreed that both options were acceptable, but a coin flip was conducted to break the stalemate, with MTP winning.Contributors who agreed to abide by the coin flip outcome will now focus on moving MTP forward. Additionally, Andrew Chow and AJ are working together to find a solution to the contention between them regarding MTP-based ST. This collaboration is expected to lead to a compromise that Bitcoin's community will support.Luke-jr expressed his disagreement with anything related to MTP during the meeting. However, it was acknowledged that both MTP and Heights have their benefits and are technically viable for Taproot. The coin flip decision was seen as a way to prioritize the bigger picture over individual preferences.While there were mixed feelings about using a coin flip for a technical decision, many participants recognized the importance of reaching rough consensus and having running code. The changes agreed upon during the meeting are expected to be implemented soon, bringing Bitcoin closer to the deployment of Taproot.Overall, the meeting addressed the ongoing discussions surrounding Taproot activation, with a focus on resolving disagreements and finding a path forward that garners support from the Bitcoin community. 2021-04-07T00:02:35+00:00 + During the second fortnightly taproot activation meeting, Bitcoin developers discussed various topics related to the technology. One of the main points of discussion was the modifications to Median Time Past (MTP) and Height for Taproot activation. Most attendees agreed that both options were acceptable, but a coin flip was conducted to break the stalemate, with MTP winning.Contributors who agreed to abide by the coin flip outcome will now focus on moving MTP forward. Additionally, Andrew Chow and AJ are working together to find a solution to the contention between them regarding MTP-based ST. This collaboration is expected to lead to a compromise that Bitcoin's community will support.Luke-jr expressed his disagreement with anything related to MTP during the meeting. However, it was acknowledged that both MTP and Heights have their benefits and are technically viable for Taproot. The coin flip decision was seen as a way to prioritize the bigger picture over individual preferences.While there were mixed feelings about using a coin flip for a technical decision, many participants recognized the importance of reaching rough consensus and having running code. The changes agreed upon during the meeting are expected to be implemented soon, bringing Bitcoin closer to the deployment of Taproot.Overall, the meeting addressed the ongoing discussions surrounding Taproot activation, with a focus on resolving disagreements and finding a path forward that garners support from the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-Reminder-April-6th-19-00-UTC-bitcoin-bitcoin-dev.xml b/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-Reminder-April-6th-19-00-UTC-bitcoin-bitcoin-dev.xml index 11fa436035..b0f355d348 100644 --- a/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-Reminder-April-6th-19-00-UTC-bitcoin-bitcoin-dev.xml +++ b/static/bitcoin-dev/April_2021/combined_Taproot-Activation-Meeting-Reminder-April-6th-19-00-UTC-bitcoin-bitcoin-dev.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev - 2023-08-02T03:32:05.456893+00:00 - - David A. Harding 2021-04-06 21:31:23+00:00 - - - Anthony Towns 2021-04-06 19:48:19+00:00 - - - Russell O'Connor 2021-04-06 17:17:58+00:00 - - - Russell O'Connor 2021-04-06 16:27:34+00:00 - - - David A. Harding 2021-04-06 16:22:16+00:00 - - - Adam Back 2021-04-06 14:51:21+00:00 - - - Russell O'Connor 2021-04-06 14:34:57+00:00 - - - Jeremy 2021-04-06 04:18:52+00:00 - - - Anthony Towns 2021-04-05 10:34:52+00:00 - - - Robert Spigler 2021-04-04 22:00:02+00:00 - - - Jorge Timón 2021-04-04 09:31:45+00:00 - - - Jeremy 2021-04-04 04:39:11+00:00 - + 2025-09-26T15:45:30.370828+00:00 + python-feedgen + + + [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev Jeremy + 2021-04-04T04:39:00.000Z + + + Jorge Timón + 2021-04-04T09:31:00.000Z + + + Robert Spigler + 2021-04-04T22:00:00.000Z + + + Anthony Towns + 2021-04-05T10:34:00.000Z + + + Jeremy + 2021-04-06T04:18:00.000Z + + + Russell O'Connor + 2021-04-06T14:34:00.000Z + + + Adam Back + 2021-04-06T14:51:00.000Z + + + David A. Harding + 2021-04-06T16:22:00.000Z + + + Russell O'Connor + 2021-04-06T16:27:00.000Z + + + Russell O'Connor + 2021-04-06T17:17:00.000Z + + + Anthony Towns + 2021-04-06T19:48:00.000Z + + + David A. Harding + 2021-04-06T21:31:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev - 2023-08-02T03:32:05.456893+00:00 + 2025-09-26T15:45:30.372193+00:00 - In an email exchange, Russell O'Connor corrected a mistake made by Dave about Bitcoin's activation scheme. Dave expressed his preference for a predictable activation date and recommended infrastructure adjustments. However, he acknowledged the simplicity of the current height-based activation. On the Bitcoin development mailing list, a discussion took place regarding the MTP lock-in for activation of soft forks. The variable "time_until_next_retargeting_period" was highlighted as one whose distribution could straddle between 0 and 14 days if the MIN_LOCKIN_TIME ends up close to a retargeting boundary. It was noted that the observed time frame of a single retarget period over the last few years on mainnet is 11-17 days.Russell O'Connor argued in an email exchange with David A. Harding that height-based activation provides more accurate estimates consistently and smoothly as activation approaches. In contrast, MTP LOCKIN only guarantees a minimum two-week notice prior to activation. O'Connor emphasized the simplicity and ease of reasoning about height-based activation. In another email from David A. Harding, instructions were provided for upgrading a system using the command "date -d "$MIN_LOCKIN_TIME + 11 days". A correction was made to the ten-minute estimator's command, stating that it should be "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016)) minutes" instead of just adding 10 times 2016 minutes.The Bitcoin community is discussing the activation of Taproot, with debate around height-based activation versus Median Time Past (MTP) activation. Some community members prefer height-based activation due to its predictability and cleanliness. However, MTP activation can ensure a minimum of seven retargeting periods by carefully selecting signaling start and end dates. Anthony Towns provided data on the number of retarget periods and stats from the last few years of mainnet for different signaling periods. The community must determine if they can reach consensus on either approach.The author presented a table of results obtained from running tests to determine the probability of success for different percentages and numbers of trials. The author concluded that MTP can be used to ensure a smooth upgrade, and provided a link to the code used in the tests. In another email discussion, the number of retarget periods required for successful activation was discussed. The email also provided stats on the number of periods required to reach successful activation over the last few years on mainnet. Questions were raised regarding whether signaling is still possible by the time enough miners have upgraded and are ready to start signaling, and whether nodes have upgraded to enforce new rules when activation occurs. Corresponding numbers for testnet were also provided.In a Bitcoin development meeting, the pros and cons of using height or MTP to determine consensus were discussed. The conversation centered around the number of retarget periods needed for successful activation. A timeline discussion was held in hopes of reaching consensus on parameters mindful of Core's process. One participant suggested continuing the search for the ideal activation method. The meeting also mentioned an update to MTP time by AJ, which is intended to be compatible with a mandatory signaling period and makes it easier to deploy ST on signets. If rough consensus is not reached, the group will discuss scheduling realities.A bitcoin-dev meeting is scheduled to discuss topics related to activation, including the update to MTP time, selecting between MTP and height, and timeline discussion. Participants expressed frustration and the need for consensus. The update to MTP time has been updated and simplified to be compatible with mandatory signaling periods and make it easier to deploy ST on signets. If rough consensus is not reached, there may be a discussion about scheduling realities. 2021-04-06T21:31:23+00:00 + In an email exchange, Russell O'Connor corrected a mistake made by Dave about Bitcoin's activation scheme. Dave expressed his preference for a predictable activation date and recommended infrastructure adjustments. However, he acknowledged the simplicity of the current height-based activation. On the Bitcoin development mailing list, a discussion took place regarding the MTP lock-in for activation of soft forks. The variable "time_until_next_retargeting_period" was highlighted as one whose distribution could straddle between 0 and 14 days if the MIN_LOCKIN_TIME ends up close to a retargeting boundary. It was noted that the observed time frame of a single retarget period over the last few years on mainnet is 11-17 days.Russell O'Connor argued in an email exchange with David A. Harding that height-based activation provides more accurate estimates consistently and smoothly as activation approaches. In contrast, MTP LOCKIN only guarantees a minimum two-week notice prior to activation. O'Connor emphasized the simplicity and ease of reasoning about height-based activation. In another email from David A. Harding, instructions were provided for upgrading a system using the command "date -d "$MIN_LOCKIN_TIME + 11 days". A correction was made to the ten-minute estimator's command, stating that it should be "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016)) minutes" instead of just adding 10 times 2016 minutes.The Bitcoin community is discussing the activation of Taproot, with debate around height-based activation versus Median Time Past (MTP) activation. Some community members prefer height-based activation due to its predictability and cleanliness. However, MTP activation can ensure a minimum of seven retargeting periods by carefully selecting signaling start and end dates. Anthony Towns provided data on the number of retarget periods and stats from the last few years of mainnet for different signaling periods. The community must determine if they can reach consensus on either approach.The author presented a table of results obtained from running tests to determine the probability of success for different percentages and numbers of trials. The author concluded that MTP can be used to ensure a smooth upgrade, and provided a link to the code used in the tests. In another email discussion, the number of retarget periods required for successful activation was discussed. The email also provided stats on the number of periods required to reach successful activation over the last few years on mainnet. Questions were raised regarding whether signaling is still possible by the time enough miners have upgraded and are ready to start signaling, and whether nodes have upgraded to enforce new rules when activation occurs. Corresponding numbers for testnet were also provided.In a Bitcoin development meeting, the pros and cons of using height or MTP to determine consensus were discussed. The conversation centered around the number of retarget periods needed for successful activation. A timeline discussion was held in hopes of reaching consensus on parameters mindful of Core's process. One participant suggested continuing the search for the ideal activation method. The meeting also mentioned an update to MTP time by AJ, which is intended to be compatible with a mandatory signaling period and makes it easier to deploy ST on signets. If rough consensus is not reached, the group will discuss scheduling realities.A bitcoin-dev meeting is scheduled to discuss topics related to activation, including the update to MTP time, selecting between MTP and height, and timeline discussion. Participants expressed frustration and the need for consensus. The update to MTP time has been updated and simplified to be compatible with mandatory signaling periods and make it easier to deploy ST on signets. If rough consensus is not reached, there may be a discussion about scheduling realities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-13th-April-19-00-UTC.xml b/static/bitcoin-dev/April_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-13th-April-19-00-UTC.xml index f61b2c419c..f77c213771 100644 --- a/static/bitcoin-dev/April_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-13th-April-19-00-UTC.xml +++ b/static/bitcoin-dev/April_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-13th-April-19-00-UTC.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC - 2023-08-02T03:34:52.261862+00:00 + 2025-09-26T15:44:58.927693+00:00 + python-feedgen Billy Tetrud 2021-04-12 19:39:13+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC - 2023-08-02T03:34:52.261862+00:00 + 2025-09-26T15:44:58.927869+00:00 - BitcoinMechanic has announced an upcoming Taproot activation meeting on Tuesday, April 13th at 19:00 UTC. The purpose of the meeting is to ratify the Taproot activation plan that was previously discussed in a meeting held on March 16th. This plan, also known as 2021-03 Plan Y, will be the main focus of the upcoming meeting.While there was no consensus reached on the LOT parameter, there appears to be agreement on other parameters, such as BIP8. Additionally, there is sufficient support for LOT=True to proceed with activation safely. Miners will have a period of 18 months to signal and accelerate the activation process. If they fail to do so, Taproot will activate regardless.The activation plan aims to ensure the eventual lock-in of Taproot with the least possibility of a chain split. This is important as the majority of the economy is running on Taproot. The channel for ongoing discussion related to Taproot activation remains open 24/7, allowing participants to engage in discussions even outside of the scheduled meeting time. To facilitate communication, a web chat client is available for use.Michael Folkson, a key figure in the Bitcoin community, has expressed his intention to attend the Taproot activation meeting. He encourages other reviewers to carefully review Core PR #21377. In the event that this pull request is merged into Core, Folkson recommends any alternative release to be fully compatible with the activation parameters outlined in Core.The meeting organized by Bitcoin Mechanic will also cover discussions on an alternative release to Core with Taproot activation code. It will involve deciding when Core should no longer be considered in the process. Detailed contact information for Michael Folkson is provided for further inquiries or correspondence.Interested parties can find the meeting details sent via email by Bitcoin Mechanic, using ProtonMail Secure Email. A summary of the previous meeting is also available through the provided link, offering additional context for those interested in the Taproot activation discussions. 2021-04-12T19:39:13+00:00 + BitcoinMechanic has announced an upcoming Taproot activation meeting on Tuesday, April 13th at 19:00 UTC. The purpose of the meeting is to ratify the Taproot activation plan that was previously discussed in a meeting held on March 16th. This plan, also known as 2021-03 Plan Y, will be the main focus of the upcoming meeting.While there was no consensus reached on the LOT parameter, there appears to be agreement on other parameters, such as BIP8. Additionally, there is sufficient support for LOT=True to proceed with activation safely. Miners will have a period of 18 months to signal and accelerate the activation process. If they fail to do so, Taproot will activate regardless.The activation plan aims to ensure the eventual lock-in of Taproot with the least possibility of a chain split. This is important as the majority of the economy is running on Taproot. The channel for ongoing discussion related to Taproot activation remains open 24/7, allowing participants to engage in discussions even outside of the scheduled meeting time. To facilitate communication, a web chat client is available for use.Michael Folkson, a key figure in the Bitcoin community, has expressed his intention to attend the Taproot activation meeting. He encourages other reviewers to carefully review Core PR #21377. In the event that this pull request is merged into Core, Folkson recommends any alternative release to be fully compatible with the activation parameters outlined in Core.The meeting organized by Bitcoin Mechanic will also cover discussions on an alternative release to Core with Taproot activation code. It will involve deciding when Core should no longer be considered in the process. Detailed contact information for Michael Folkson is provided for further inquiries or correspondence.Interested parties can find the meeting details sent via email by Bitcoin Mechanic, using ProtonMail Secure Email. A summary of the previous meeting is also available through the provided link, offering additional context for those interested in the Taproot activation discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Update-on-Speedy-Trial-The-circus-rolls-on.xml b/static/bitcoin-dev/April_2021/combined_Update-on-Speedy-Trial-The-circus-rolls-on.xml index cee345f8d9..57ff212c82 100644 --- a/static/bitcoin-dev/April_2021/combined_Update-on-Speedy-Trial-The-circus-rolls-on.xml +++ b/static/bitcoin-dev/April_2021/combined_Update-on-Speedy-Trial-The-circus-rolls-on.xml @@ -1,39 +1,48 @@ - + 2 - Combined summary - Update on "Speedy" Trial: The circus rolls on - 2023-08-02T03:33:09.646590+00:00 - - Michael Folkson 2021-04-10 12:07:40+00:00 - - - Michael Folkson 2021-04-09 11:19:02+00:00 - - - David A. Harding 2021-04-08 21:56:05+00:00 - - - Matt Corallo 2021-04-08 15:18:33+00:00 - - - Andrew Poelstra 2021-04-08 14:30:05+00:00 - - - Michael Folkson 2021-04-08 11:40:42+00:00 - + Combined summary - Update on "Speedy" Trial: The circus rolls on + 2025-09-26T15:44:44.175737+00:00 + python-feedgen + + + [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on Michael Folkson + 2021-04-08T11:40:00.000Z + + + Andrew Poelstra + 2021-04-08T14:30:00.000Z + + + Matt Corallo + 2021-04-08T15:18:00.000Z + + + David A. Harding + 2021-04-08T21:56:00.000Z + + + Michael Folkson + 2021-04-09T11:19:00.000Z + + + Michael Folkson + 2021-04-10T12:07:00.000Z + + - python-feedgen + 2 - Combined summary - Update on "Speedy" Trial: The circus rolls on - 2023-08-02T03:33:09.646590+00:00 + Combined summary - Update on "Speedy" Trial: The circus rolls on + 2025-09-26T15:44:44.176420+00:00 - The recent debate over the activation mechanism for Taproot, Bitcoin's upcoming upgrade, has sparked controversy within the community. The discussion involved two competing pull requests, and developer David Harding proposed using a coin toss to make the decision. While some members expressed concern about the use of informal methods in decision-making, Harding argued that it was a valid way to break a deadlock. Ultimately, a compromise solution was found, rendering the coin toss unnecessary. However, there is widespread support for Taproot, and progress on Speedy Trial continues, aiming to implement the upgrade. Another developer, Jeremy Rubin, initially proposed the coin toss, but it was revealed that the idea came from Dave Harding, who had used this method before in other discussions. Harding believes that a coin toss is a useful tool for coordinating work when there is disagreement about the best option. He hopes that those waiting for Taproot's implementation understand that the activation method is separate from Taproot itself. Furthermore, he is open to discussing better activation mechanisms for future deployments.On the Bitcoin-dev mailing list, Andrew Poelstra expressed his indifference towards the activation parameters for Taproot. He stated that, as someone who wants to use Taproot, he does not care about block height versus MTP. He even suggested that if a coin toss can help move past the controversy, it is acceptable to him. Michael Folkson, another member of the mailing list, voiced discomfort with the situation, expressing concern for individuals and businesses planning to utilize Taproot. However, it should be noted that the authors of the two proposals ultimately reached an agreement on the way forward, making it more than just a coin toss to overrule one side.In light of the ongoing controversy, Michael Folkson shared StackExchange links on block height vs MTP for those interested in the technical considerations. Despite the disagreements, progress is being made, and efforts are underway to reach a resolution for Taproot's activation. 2021-04-10T12:07:40+00:00 + The recent debate over the activation mechanism for Taproot, Bitcoin's upcoming upgrade, has sparked controversy within the community. The discussion involved two competing pull requests, and developer David Harding proposed using a coin toss to make the decision. While some members expressed concern about the use of informal methods in decision-making, Harding argued that it was a valid way to break a deadlock. Ultimately, a compromise solution was found, rendering the coin toss unnecessary. However, there is widespread support for Taproot, and progress on Speedy Trial continues, aiming to implement the upgrade. Another developer, Jeremy Rubin, initially proposed the coin toss, but it was revealed that the idea came from Dave Harding, who had used this method before in other discussions. Harding believes that a coin toss is a useful tool for coordinating work when there is disagreement about the best option. He hopes that those waiting for Taproot's implementation understand that the activation method is separate from Taproot itself. Furthermore, he is open to discussing better activation mechanisms for future deployments.On the Bitcoin-dev mailing list, Andrew Poelstra expressed his indifference towards the activation parameters for Taproot. He stated that, as someone who wants to use Taproot, he does not care about block height versus MTP. He even suggested that if a coin toss can help move past the controversy, it is acceptable to him. Michael Folkson, another member of the mailing list, voiced discomfort with the situation, expressing concern for individuals and businesses planning to utilize Taproot. However, it should be noted that the authors of the two proposals ultimately reached an agreement on the way forward, making it more than just a coin toss to overrule one side.In light of the ongoing controversy, Michael Folkson shared StackExchange links on block height vs MTP for those interested in the technical considerations. Despite the disagreements, progress is being made, and efforts are underway to reach a resolution for Taproot's activation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_Yesterday-s-Taproot-activation-meeting-on-IRC.xml b/static/bitcoin-dev/April_2021/combined_Yesterday-s-Taproot-activation-meeting-on-IRC.xml index 68969c393e..3f5a89c265 100644 --- a/static/bitcoin-dev/April_2021/combined_Yesterday-s-Taproot-activation-meeting-on-IRC.xml +++ b/static/bitcoin-dev/April_2021/combined_Yesterday-s-Taproot-activation-meeting-on-IRC.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Yesterday's Taproot activation meeting on IRC - 2023-08-02T03:03:26.764149+00:00 - - Michael Folkson 2021-04-14 11:58:58+00:00 - - - Michael Folkson 2021-02-03 14:24:59+00:00 - + 2025-09-26T15:44:33.661358+00:00 + python-feedgen + + + Michael Folkson + 2021-02-03T14:24:00.000Z + + + [bitcoin-dev] Yesterday's Taproot activation meeting on IRC Michael Folkson + 2021-04-14T11:58:00.000Z + + - python-feedgen + 2 Combined summary - Yesterday's Taproot activation meeting on IRC - 2023-08-02T03:03:26.764149+00:00 + 2025-09-26T15:44:33.661932+00:00 - Yesterday, a Taproot activation meeting was held on the ##taproot-activation Freenode channel. The agenda for the meeting was posted in advance on the mailing list by BitcoinMechanic. The conversation log from the meeting is available on gnusha.org. During the meeting, participants discussed an alternative release to Bitcoin Core with Speedy Trial as the activation mechanism, followed by BIP 8. However, there were concerns raised about having "Bitcoin Core" in the name of the alternative release, as it could confuse users and make them think it was approved by Bitcoin Core maintainers.The draft release notes for this alternative release can be found on Google Docs, and the GitHub repository is available on BitcoinActivation's GitHub page. In comparison, Bitcoin Core is considering Core PR #21377 for merge, which proposes using Speedy Trial as the activation mechanism with a mix of block height and MTP. A BIP PR has also been opened for the Core release, suggesting finalized parameters. However, if these plans continue, Bitcoin Core and the alternative release may not be entirely compatible due to differences in startheight and timeout definitions.While both Bitcoin Core and the alternative release should activate at the same block height in most cases, there are potential edge cases where one activates and the other doesn't. The use of MTP in Speedy Trial for Bitcoin Core has been extensively discussed, and opinions from reviewers are summarized in a GitHub comment. It is worth noting that anyone can host a meeting on the ##taproot-activation channel by contacting Michael Folkson to book a time slot and posting an agenda in advance on the mailing list. The meeting host has the authority to issue warnings and, if necessary, remove disruptive participants who divert from the agenda.On February 2nd, an open meeting was held on IRC to discuss Taproot activation. This meeting was previously announced on a Linux Foundation mailing list. The conversation log from the meeting is available online for those who are interested. Rusty Russell provided his takeaways from the meeting, which included unanimous support for BIP 8 and overwhelming consensus that a one-year timeout is appropriate. While there was majority consensus for lockinontimeout false, some individuals, such as Luke Dashjr, opposed it. No decision was made regarding the start time.Following the meeting, two BIP 8 PRs were merged in response to an observation by Jonas Nick that without them, nodes could end up on the wrong chain. Bitcoin Core PR #19573 still requires further review before it can be considered for merging. A follow-up meeting will be organized in the format of John Newbery’s Bitcoin Core PR review club.In other news, Chun Wang, co-founder of F2Pool with approximately 16% of global hash rate, announced support for BIP 8 (false, 1 year) according to an update on taprootactivation.com by Alejandro De La Torre. 2021-04-14T11:58:58+00:00 + Yesterday, a Taproot activation meeting was held on the ##taproot-activation Freenode channel. The agenda for the meeting was posted in advance on the mailing list by BitcoinMechanic. The conversation log from the meeting is available on gnusha.org. During the meeting, participants discussed an alternative release to Bitcoin Core with Speedy Trial as the activation mechanism, followed by BIP 8. However, there were concerns raised about having "Bitcoin Core" in the name of the alternative release, as it could confuse users and make them think it was approved by Bitcoin Core maintainers.The draft release notes for this alternative release can be found on Google Docs, and the GitHub repository is available on BitcoinActivation's GitHub page. In comparison, Bitcoin Core is considering Core PR #21377 for merge, which proposes using Speedy Trial as the activation mechanism with a mix of block height and MTP. A BIP PR has also been opened for the Core release, suggesting finalized parameters. However, if these plans continue, Bitcoin Core and the alternative release may not be entirely compatible due to differences in startheight and timeout definitions.While both Bitcoin Core and the alternative release should activate at the same block height in most cases, there are potential edge cases where one activates and the other doesn't. The use of MTP in Speedy Trial for Bitcoin Core has been extensively discussed, and opinions from reviewers are summarized in a GitHub comment. It is worth noting that anyone can host a meeting on the ##taproot-activation channel by contacting Michael Folkson to book a time slot and posting an agenda in advance on the mailing list. The meeting host has the authority to issue warnings and, if necessary, remove disruptive participants who divert from the agenda.On February 2nd, an open meeting was held on IRC to discuss Taproot activation. This meeting was previously announced on a Linux Foundation mailing list. The conversation log from the meeting is available online for those who are interested. Rusty Russell provided his takeaways from the meeting, which included unanimous support for BIP 8 and overwhelming consensus that a one-year timeout is appropriate. While there was majority consensus for lockinontimeout false, some individuals, such as Luke Dashjr, opposed it. No decision was made regarding the start time.Following the meeting, two BIP 8 PRs were merged in response to an observation by Jonas Nick that without them, nodes could end up on the wrong chain. Bitcoin Core PR #19573 still requires further review before it can be considered for merging. A follow-up meeting will be organized in the format of John Newbery’s Bitcoin Core PR review club.In other news, Chun Wang, co-founder of F2Pool with approximately 16% of global hash rate, announced support for BIP 8 (false, 1 year) according to an update on taprootactivation.com by Alejandro De La Torre. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2021/combined_maximum-block-height-on-transaction.xml b/static/bitcoin-dev/April_2021/combined_maximum-block-height-on-transaction.xml index 773f4917be..14e7d0a5a0 100644 --- a/static/bitcoin-dev/April_2021/combined_maximum-block-height-on-transaction.xml +++ b/static/bitcoin-dev/April_2021/combined_maximum-block-height-on-transaction.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - maximum block height on transaction - 2023-08-02T03:34:07.044664+00:00 + 2025-09-26T15:44:46.286344+00:00 + python-feedgen ZmnSCPxj 2021-05-03 02:30:07+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - maximum block height on transaction - 2023-08-02T03:34:07.044664+00:00 + 2025-09-26T15:44:46.286506+00:00 - The email thread on the bitcoin-dev mailing list discusses the issue of increasing CPU usage and code complexity when adding a field or opcode to transactions. It proposes a solution involving a "hidden" field in a transaction with a default value compatible with pre-softfork rules, along with an opcode that manipulates this field. Additionally, the proposal suggests implementing a maximum block height on transactions using a new field and opcode. This functionality allows users to be safely offline at the time of timeout in any complicated timeout-based contract. However, it also increases risk for the contractor holding lien on the hashlock branch in a two-participant contract, making the proposal less significant improvement to Bitcoin.Satoshi's statement about the inability to safely implement OP_BLOCKNUMBER is brought up in the discussion. One user suggests that software could be written to warn users about edge cases, arguing that if a person waits for 6 blocks before accepting a transaction as confirmed, there should be no likely scenario where any finalized transaction needs to be reverted. They believe that any transaction with 5 or fewer confirmations should be considered fair game for reversal. The possibility of buggy software is not seen as a good reason to block an opcode. Another user suggests using two transactions, one with a desired expiry at H and another with nlocktime H, to accomplish the goal of a rough expiry. After a timeout, participants in the first transaction can cancel the action using the second transaction. However, limiting the maximum block height for a specific transaction would have the same problem as cited above for OP_BLOCKNUMBER. A third user asks if there is any way to specify a maximum block height on a transaction and considers it useful. The discussion emphasizes the risks and limitations of implementing OP_BLOCKNUMBER. It is noted that limiting the maximum block height for a specific transaction would face the same problem as OP_BLOCKNUMBER in the event of a blockchain reorganization. Instead, nTimeLock is suggested as an alternative solution. nTimeLock is an open transaction that can be replaced with new versions until the deadline. It could be used to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. While nTimeLock is not currently enabled or used, the support for its implementation is available.In response to the discussion, a user suggests accomplishing a rough goal by using tx A with a desired expiry at H and then using tx B with nlocktime H and creating outputs equivalent to inputs. After a timeout, participants in tx A can cancel the action using tx B. However, the effectiveness of this approach depends on the use case and further clarification is needed.The possibility of specifying a maximum block height on a transaction is raised during a discussion on the bitcoin-dev mailing list. However, it is pointed out that such a feature would encounter the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorganization. As an alternative, nTimeLock is suggested. This open transaction can be replaced with new versions until the deadline, and the highest version at the deadline is recorded. It can be utilized for escrow transactions that automatically lock and proceed unless revoked before the deadline. Although nTimeLock is not currently enabled or used, the necessary support exists for its future implementation.A user on the Bitcoin development mailing list inquires about the possibility of specifying a maximum block height for a transaction. However, it is noted that implementing such a feature would present the same issue as the OP_BLOCKNUMBER transaction, which becomes invalid during a blockchain reorganization. Instead, an alternative option called nTimeLock is proposed. nTimeLock allows for an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is then recorded. This feature could be used for escrow transactions that automatically lock and proceed unless revoked before the deadline. While nTimeLock is not currently enabled or used, the necessary support exists for its implementation in the future.The inquiry regarding the possibility of specifying a maximum block height on a transaction is raised by a user. However, it is pointed out that this feature would face the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorg. An alternative suggestion is made to use nTimeLock, which is an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is recorded. This feature could be useful for creating escrow transactions that automatically lock and go through unless revoked before the deadline. While nTimeLock is currently not enabled or used, the support for its implementation is available. In conclusion, the discussions on the bitcoin-dev mailing list revolve around the issue of increasing CPU usage and code complexity when adding fields or opcodes to transactions. Various suggestions and alternatives are proposed, such as using hidden fields, implementing a maximum block height, and utilizing nTimeLock. The limitations of implementing OP_BLOCKNUMBER and the potential risks associated with each solution are thoroughly examined. Ultimately, any modification to 2021-05-03T02:30:07+00:00 + The email thread on the bitcoin-dev mailing list discusses the issue of increasing CPU usage and code complexity when adding a field or opcode to transactions. It proposes a solution involving a "hidden" field in a transaction with a default value compatible with pre-softfork rules, along with an opcode that manipulates this field. Additionally, the proposal suggests implementing a maximum block height on transactions using a new field and opcode. This functionality allows users to be safely offline at the time of timeout in any complicated timeout-based contract. However, it also increases risk for the contractor holding lien on the hashlock branch in a two-participant contract, making the proposal less significant improvement to Bitcoin.Satoshi's statement about the inability to safely implement OP_BLOCKNUMBER is brought up in the discussion. One user suggests that software could be written to warn users about edge cases, arguing that if a person waits for 6 blocks before accepting a transaction as confirmed, there should be no likely scenario where any finalized transaction needs to be reverted. They believe that any transaction with 5 or fewer confirmations should be considered fair game for reversal. The possibility of buggy software is not seen as a good reason to block an opcode. Another user suggests using two transactions, one with a desired expiry at H and another with nlocktime H, to accomplish the goal of a rough expiry. After a timeout, participants in the first transaction can cancel the action using the second transaction. However, limiting the maximum block height for a specific transaction would have the same problem as cited above for OP_BLOCKNUMBER. A third user asks if there is any way to specify a maximum block height on a transaction and considers it useful. The discussion emphasizes the risks and limitations of implementing OP_BLOCKNUMBER. It is noted that limiting the maximum block height for a specific transaction would face the same problem as OP_BLOCKNUMBER in the event of a blockchain reorganization. Instead, nTimeLock is suggested as an alternative solution. nTimeLock is an open transaction that can be replaced with new versions until the deadline. It could be used to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. While nTimeLock is not currently enabled or used, the support for its implementation is available.In response to the discussion, a user suggests accomplishing a rough goal by using tx A with a desired expiry at H and then using tx B with nlocktime H and creating outputs equivalent to inputs. After a timeout, participants in tx A can cancel the action using tx B. However, the effectiveness of this approach depends on the use case and further clarification is needed.The possibility of specifying a maximum block height on a transaction is raised during a discussion on the bitcoin-dev mailing list. However, it is pointed out that such a feature would encounter the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorganization. As an alternative, nTimeLock is suggested. This open transaction can be replaced with new versions until the deadline, and the highest version at the deadline is recorded. It can be utilized for escrow transactions that automatically lock and proceed unless revoked before the deadline. Although nTimeLock is not currently enabled or used, the necessary support exists for its future implementation.A user on the Bitcoin development mailing list inquires about the possibility of specifying a maximum block height for a transaction. However, it is noted that implementing such a feature would present the same issue as the OP_BLOCKNUMBER transaction, which becomes invalid during a blockchain reorganization. Instead, an alternative option called nTimeLock is proposed. nTimeLock allows for an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is then recorded. This feature could be used for escrow transactions that automatically lock and proceed unless revoked before the deadline. While nTimeLock is not currently enabled or used, the necessary support exists for its implementation in the future.The inquiry regarding the possibility of specifying a maximum block height on a transaction is raised by a user. However, it is pointed out that this feature would face the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorg. An alternative suggestion is made to use nTimeLock, which is an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is recorded. This feature could be useful for creating escrow transactions that automatically lock and go through unless revoked before the deadline. While nTimeLock is currently not enabled or used, the support for its implementation is available. In conclusion, the discussions on the bitcoin-dev mailing list revolve around the issue of increasing CPU usage and code complexity when adding fields or opcodes to transactions. Various suggestions and alternatives are proposed, such as using hidden fields, implementing a maximum block height, and utilizing nTimeLock. The limitations of implementing OP_BLOCKNUMBER and the potential risks associated with each solution are thoroughly examined. Ultimately, any modification to - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml b/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml index 2048c1a11d..2f25ea7884 100644 --- a/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml +++ b/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml @@ -2,7 +2,7 @@ 2 Combined summary - Automatically reverting ("transitory") soft forks, e.g. for CTV - 2025-09-26T14:33:35.444629+00:00 + 2025-09-26T15:51:02.969283+00:00 python-feedgen ZmnSCPxj 2022-04-25 05:12:10+00:00 @@ -109,10 +109,11 @@ + 2 Combined summary - Automatically reverting ("transitory") soft forks, e.g. for CTV - 2025-09-26T14:33:35.444821+00:00 + 2025-09-26T15:51:02.969465+00:00 2022-04-25T05:12:10+00:00 In an email thread discussing the implementation of new features or opcodes in Bitcoin SCRIPT, a proposal is made to use real-world funds to prove demand. This involves using Smart Contracts Unchained and creating a mapping from Bitcoin SCRIPT opcodes to micro-opcodes. While this approach demonstrates real demand, there are concerns about security erosion and reliance on a federation. The possibility of reverting activated soft forks is discussed, but it is suggested that reverting without disrupting the network may not be possible. Concerns about specific covenant designs being discussed without actual implementations or sample usages are raised, with a suggestion to address this issue in the short-term. The focus of the discussion shifts to the implementation of covenants in Bitcoin, with arguments for and against CTV as the preferred design. The difficulty in choosing the "best" covenant design is acknowledged, along with the challenges and risks associated with doing a fork in Bitcoin. The lack of serious proposals other than CTV is noted, highlighting its simplicity and positive reviews. The potential uses of covenants, particularly vaults, are discussed, with CTV seen as a low-risk way to implement them. However, there is recognition of the need for more general covenant abilities and the time and effort required for their development. The practicality and utility of various covenant proposals are debated, with a preference for CTV due to its low-risk approach to vaulting. The criteria for adding a covenant to Bitcoin are outlined, including demonstrated use cases, alignment with Bitcoin's design, technical feasibility, and a well-reviewed implementation. The possibility of reverting to earlier consensus rules is also mentioned. The ongoing discussion about covenant designs is highlighted, with a lack of serious proposals other than CTV. The challenges of finding a preferable alternative and the need for complete specifications and tooling are discussed. Concerns about the long-term nature of CTV's use cases and its compatibility with a sunset period are raised. The suggestion is made to use CTV for most of the deployment to demonstrate real-world usage and convince others to make it permanent. Bitcoin developers discuss the best way to implement covenant functionality in Bitcoin, with no clear consensus on the best design. More data about user demand and usage is deemed necessary. The proposal of a transitory soft fork to activate different covenant designs is met with concerns about safety risks and recursion. Criticisms of CTV are discussed, including concerns about usage, maintenance burden, and the lack of consensus around concrete proposals for covenants. The need for real usage data and optimizing for demonstrated needs is emphasized. The risk and cost of doing a fork and the suggestion of adding "technical community consensus" as a factor in the process are also mentioned. The viability of the proposed BIP119 CTV is debated, with considerations of usage, maintenance burden, and consensus within the technical community. The importance of maintaining Bitcoin's culture of security and careful design is stressed. The possibility of modifying the witness discount in SegWit transactions through an additional soft fork is suggested, but concerns about potential confiscation of funds are raised. The variant of Speedy Trial being used and accusations of efforts to sabotage parallel UASF initiatives are also discussed. The importance of advocacy and improving logic is emphasized. The question of whether changes made by already activated soft forks can be reverted is raised, with suggestions for potential solutions. Concerns about increased weight making transactions invalid and criticism of the variant of Speedy Trial being used are expressed. The idea of making CTV an automatically reverting consensus change with an option to renew after five years is proposed. This allows experimentation with new features without permanent commitment. However, concerns about usage, maintenance burden, and the risk of losing money and potential miner censorship near the reversion date are raised. Alternative ways to activate CTV, such as a UASF client compatible with a speedy trial release, are suggested. The importance of allowing users to decide and preventing miner veto power is emphasized. Despite the downsides, an automatically reverting soft fork provides the opportunity to experiment with new features.The Bitcoin community expresses concerns about the future use of CTV due to maintenance and security issues. The proposal to automatically revert CTV as a consensus change after five years is discussed, allowing for experimentation without permanent commitment. However, there are potential risks such as the loss of funds and potential miner censorship. Further discussions on CTV are anticipated. A proposal is made to address criticisms against CTV by making it an automatically reverting consensus change with an option to renew, allowing for experimentation without permanent commitment. However, concerns about risks and potential miner censorship remain. Further discussions on CTV are expected. diff --git a/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml b/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml index 0e5e203ee4..dc60a21433 100644 --- a/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml +++ b/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Vaulting (Was: Automatically reverting ("transitory") soft forks) - 2025-09-26T14:33:56.912712+00:00 + 2025-09-26T15:51:07.201964+00:00 python-feedgen Billy Tetrud 2022-04-28 23:51:31+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Vaulting (Was: Automatically reverting ("transitory") soft forks) - 2025-09-26T14:33:56.912873+00:00 + 2025-09-26T15:51:07.202111+00:00 2022-04-28T23:51:31+00:00 The discussion on the bitcoin-dev mailing list revolves around the benefits and tradeoffs of using multisig versus a wallet vault. Nadav Ivgi highlights the primary benefit of a vault, which is the ability to keep primary wallet keys in deep cold storage for enhanced security. On the other hand, Billy Tetrud argues that the purpose of a wallet vault is to gain the security of a multisig wallet without having to sign using as many keys. The conversation also delves into the COV proposal in MES, which allows users to check if an output's scriptPubKey matches the corresponding script item from the stack, while accommodating wildcard values. Signing the transaction with the hot wallet key removes third-party malleability.The discussions explore different setups and approaches to securing Bitcoin transactions. The use of a warmer model for covenant-encumbered two-step spending with more frequently used keys is suggested, while keeping primary keys in deep cold storage for increased security. The viability of a CTV vault where the hot key signer is a multisig is discussed, with some arguing that it does not offer the advantages of either wallet type. The COV proposal in MES allows checking if the output's scriptPubKey matches the corresponding script item from the stack, with wildcard values available. However, the signing of the transaction with the hot wallet key eliminates malleability issues.The conversation also touches on the limitations and risks associated with different vault schemes. The theft of a hot wallet key is highlighted as a security concern in CTV-based vaults, as it may not be immediately apparent that the key has been stolen. The MES vault scheme is compared to the CTV vault, with the former offering more advantages for managing payments through a vault. Fee management and less constrained covenant designs are identified as areas that could benefit from further exploration.In addition, there are discussions about the limitations and potential solutions to security issues in vault proposals. The theft of a hot key and the possibility of waiting for the user to unvault their funds are identified as concerns. Alternative solutions such as the OP_BEFOREBLOCKVERIFY opcode and encoding transactions with OP_POS and OP_CD are proposed. The MES vault design is mentioned as one that commits to the destination address during unvaulting, but this requires a less constrained covenant design. The CTV vault is acknowledged as potentially containing the damage from a hot key theft more effectively, but fee management remains an issue.Overall, the discussions highlight the advantages and disadvantages of different wallet vault setups and COV proposals in MES. The focus is on security concerns, risk management, and exploring alternative approaches to address limitations. diff --git a/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml b/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml index 85ecfcf73e..0c8af9ddc7 100644 --- a/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml +++ b/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml @@ -2,7 +2,7 @@ 2 Combined summary - What to do when contentious soft fork activations are attempted - 2025-09-26T14:33:46.160602+00:00 + 2025-09-26T15:51:05.086175+00:00 python-feedgen Jorge Timón 2022-05-07 01:57:39+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - What to do when contentious soft fork activations are attempted - 2025-09-26T14:33:46.160767+00:00 + 2025-09-26T15:51:05.086316+00:00 2022-05-07T01:57:39+00:00 The email conversation between Jorge Timón and John Tromp on the Bitcoin-dev mailing list has sparked a discussion on irony. Timón accused Tromp of making personal attacks against Andreas Antonopoulos for his opinions on bip8. However, Tromp pointed out that Timón himself had made a personal attack by calling Jeremy ignorant about bip8. This led to a discussion on how ironic it is that people who base their arguments on personal attacks are also the ones who complain the most about personal attacks.In a separate discussion on the bitcoin-dev mailing list, Jorge Timón questioned a claim made by Russell O'Connor about the design of Speedy Trial (ST). Timón found the claim strange and stated that the grace period for slower activation after lock-in was added to address concerns raised by people who disliked the proposal. However, he still believed that speedy trial was a bad proposal due to incorrect analysis. O'Connor responded by quoting his own blog post where he clarified that the design of speedy trial was not based on any activation philosophy about failing fast.In another email exchange, Jorge Timón suggested that it is unnecessary to personally attack Andreas for his opinions. He argued that the only reason Jeremy Rubin does not like BIP8 is because he is ignorant about it and has not reviewed it enough. However, John Tromp pointed out the irony in equating 'clueless about BIP119' with a personal attack and then calling Jeremy ignorant about BIP8. The conversation seems to revolve around differences of opinion regarding different Bitcoin Improvement Proposals (BIPs).In a separate email thread, Ryan Grant defends the OP_CTV covenant proposal after Jorge Timón questioned Andreas' criticism. Ryan argues that OP_CTV covenants cannot restrict any address that the sender does not control and criticizes Andreas for not code-reviewing BIP119 or the pull request. Ryan believes that Andreas did not look into the reason why the proposed client was safe and would not cause a chain split. The conversation also references Russell O'Connor's explanation for how Speedy Trials arose in the consensus process and how it was designed.The email threads also touch upon the concept of covenants in Bitcoin and the contributions made by individuals towards it. There is a mention of Bip8 and the importance of being open-minded to understand its analysis. The discussions revolve around the need for education, avoiding personal attacks, addressing misinformation, and looking at technical details when discussing contentious soft forks and covenant proposals.Michael Folkson expresses his thoughts on the recent attempt to activate a contentious soft fork and questions what should be done differently if such attempts happen again. He believes that it is unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split and suggests there should be a personal cost to dissuade them from trying it again. Folkson acknowledges that Bitcoin is a permissionless network and no authority can stop such attempts, but hopes that people will actively resist and prevent the network from being fundamentally broken.Overall, the email exchanges and threads highlight discussions on irony, differences of opinion regarding Bitcoin Improvement Proposals, the design of Speedy Trial, criticism of covenant proposals, addressing misinformation, and the recent attempt to activate a contentious soft fork. The conversations emphasize the importance of education, avoiding personal attacks, and considering technical details when discussing contentious topics in the Bitcoin community. diff --git a/static/bitcoin-dev/Aug_2016/combined_-Changing-the-blocksize-limit.xml b/static/bitcoin-dev/Aug_2016/combined_-Changing-the-blocksize-limit.xml index 2907ae23ab..ef51682fa1 100644 --- a/static/bitcoin-dev/Aug_2016/combined_-Changing-the-blocksize-limit.xml +++ b/static/bitcoin-dev/Aug_2016/combined_-Changing-the-blocksize-limit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - *Changing* the blocksize limit - 2023-08-01T18:50:29.558915+00:00 + 2025-09-26T15:30:20.731554+00:00 + python-feedgen Peter Todd 2016-08-09 02:21:29+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - *Changing* the blocksize limit - 2023-08-01T18:50:29.558915+00:00 + 2025-09-26T15:30:20.731715+00:00 - Chris Priest, a bitcoin developer, proposed a change to the blocksize limit of Bitcoin in August 2016. The current blocksize limit is denominated in bytes, which means that miners choose transactions based on their fee/byte ratio. Transactions with many inputs require more fees as they are bigger in size. Priest believed that this was a flaw in Bitcoin and suggested a change to the blocksize limit denominated in outputs.This change would incentivize microtransactions, decrease the UTXO set, and bring data that could be used to determine how to scale Bitcoin in the future. However, his initial proposal was rejected due to requiring a database index. Priest's new proposal, called BIP131, achieves the same effect as his initial proposal without needing a database index.If the blocksize limit were removed and replaced with a "block output limit", miners would choose transactions based on maximum fee per output. This would essentially make it free to include an input to a transaction. If the blocksize limit is to be changed to a block output limit, the number should be roughly the amount of outputs found in 1MB blocks today. Blocks can be bigger than 1MB, but the extra data in the block will not result in more people using bitcoin, but rather existing users spending inputs to decrease the UTXO set.Priest's proposal would also serve to decrease the UTXO set, as there is a "minimum profitability to include an input to a transaction" which increases as blocks fill up and fees rise. Any UTXO worth less than a certain amount, such as 2 cents, is not economical to add to a transaction and is likely to never be spent. This contributes to the "UTXO bloat problem" that many people talk about as being a significant issue.In conclusion, Chris Priest's proposal to change the blocksize limit of Bitcoin to a block output limit would incentivize microtransactions, decrease the UTXO set, and bring about data that could be used to determine how to scale Bitcoin in the future. Though his initial proposal was rejected, his new proposal achieves the same effect without requiring a database index. The blocksize limit should be roughly the amount of outputs found in 1MB blocks today if this change is to be implemented. However, there are still those who oppose the change. 2016-08-09T02:21:29+00:00 + Chris Priest, a bitcoin developer, proposed a change to the blocksize limit of Bitcoin in August 2016. The current blocksize limit is denominated in bytes, which means that miners choose transactions based on their fee/byte ratio. Transactions with many inputs require more fees as they are bigger in size. Priest believed that this was a flaw in Bitcoin and suggested a change to the blocksize limit denominated in outputs.This change would incentivize microtransactions, decrease the UTXO set, and bring data that could be used to determine how to scale Bitcoin in the future. However, his initial proposal was rejected due to requiring a database index. Priest's new proposal, called BIP131, achieves the same effect as his initial proposal without needing a database index.If the blocksize limit were removed and replaced with a "block output limit", miners would choose transactions based on maximum fee per output. This would essentially make it free to include an input to a transaction. If the blocksize limit is to be changed to a block output limit, the number should be roughly the amount of outputs found in 1MB blocks today. Blocks can be bigger than 1MB, but the extra data in the block will not result in more people using bitcoin, but rather existing users spending inputs to decrease the UTXO set.Priest's proposal would also serve to decrease the UTXO set, as there is a "minimum profitability to include an input to a transaction" which increases as blocks fill up and fees rise. Any UTXO worth less than a certain amount, such as 2 cents, is not economical to add to a transaction and is likely to never be spent. This contributes to the "UTXO bloat problem" that many people talk about as being a significant issue.In conclusion, Chris Priest's proposal to change the blocksize limit of Bitcoin to a block output limit would incentivize microtransactions, decrease the UTXO set, and bring about data that could be used to determine how to scale Bitcoin in the future. Though his initial proposal was rejected, his new proposal achieves the same effect without requiring a database index. The blocksize limit should be roughly the amount of outputs found in 1MB blocks today if this change is to be implemented. However, there are still those who oppose the change. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml b/static/bitcoin-dev/Aug_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml index e8ea463244..5bcbd29348 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Attack by modifying non-segwit transactions after segwit is accepted ? - 2023-08-01T18:59:18.023773+00:00 + 2025-09-26T15:30:01.688003+00:00 + python-feedgen Johnson Lau 2016-09-01 11:29:29+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Attack by modifying non-segwit transactions after segwit is accepted ? - 2023-08-01T18:59:18.024770+00:00 + 2025-09-26T15:30:01.688132+00:00 - In a recent discussion on Reddit, Johnson Lau clarified that there is no real attack in the segwit code and explained how a check in the code can prevent potential vulnerabilities. The subject of the thread had a question mark, indicating that clarification was being sought from the community rather than asserting the existence of a vulnerability. The complexity of the segwit code was acknowledged by Sergio Demian Lerner, with key parts of the consensus code spread across source files.Johnson Lau's clarifications were appreciated by the community, and he emphasized that adding witness data to a non-segwit script is invalid according to consensus. He shared a pull request that detects such violations early and bans the peer. Another approach proposed by Lau is to run the scripts of all incoming transactions, which is feasible as the unspent transaction outputs (utxos) have already been fetched, making validation easier.The consensus in the Bitcoin community is that adding witness data to a non-segwit script is considered invalid. This consensus is highlighted in a code snippet on Github's bitcoin repository. A new pull request has been made to detect any violations of this consensus early and ban the peer responsible. Additionally, another suggested approach is to run the scripts of all incoming transactions, taking advantage of the fact that utxos have already been fetched during the validation process.The potential for malicious nodes to modify non-segwit transactions after segwit activation was discussed in a recent thread on Bitcoin Improvement Proposals (BIP). It was suggested that a malicious node could re-format a non-segwit transaction into a segwit transaction with up to 400 Kbytes of segwit witness program data, resulting in both transactions having the same hash. However, due to low fees per byte, such a modified transaction would likely not be properly relayed by the network. An attacker could still modify the original transaction by adding segwit witness program data up to the point of relaying the transaction, successfully preventing it from being mined.Another concern is that an attacker could encode arbitrary data, such as virus signatures or illegal content, into passing non-segwit transactions. One proposed solution is to increase the transaction version to 3 for segwit transactions, ensuring that a non-segwit transaction cannot be converted into a segwit transaction without changing the transaction hash. However, this solution does not address all potential problems, as transactions with a mixture of segwit and non-segwit inputs could still be vulnerable to the same attack, even if they are version 3.To mitigate these issues, a simple check could be added to the IsStandardTX() function to prevent witness programs from having a stack element length greater than the maximum script element size (MAX_SCRIPT_ELEMENT_SIZE). However, a more long-term solution would be to introduce a field for each input or the entire transaction that specifies the maximum size of the witness stack in bytes (maxWitnessSize).Overall, the discussion revolves around the complexities of the segwit code and various approaches to prevent potential attacks or vulnerabilities. It underscores the importance of raising questions and seeking clarification from the community when necessary. The provided links to relevant code and pull requests serve as valuable references for further exploration of the topic. 2016-09-01T11:29:29+00:00 + In a recent discussion on Reddit, Johnson Lau clarified that there is no real attack in the segwit code and explained how a check in the code can prevent potential vulnerabilities. The subject of the thread had a question mark, indicating that clarification was being sought from the community rather than asserting the existence of a vulnerability. The complexity of the segwit code was acknowledged by Sergio Demian Lerner, with key parts of the consensus code spread across source files.Johnson Lau's clarifications were appreciated by the community, and he emphasized that adding witness data to a non-segwit script is invalid according to consensus. He shared a pull request that detects such violations early and bans the peer. Another approach proposed by Lau is to run the scripts of all incoming transactions, which is feasible as the unspent transaction outputs (utxos) have already been fetched, making validation easier.The consensus in the Bitcoin community is that adding witness data to a non-segwit script is considered invalid. This consensus is highlighted in a code snippet on Github's bitcoin repository. A new pull request has been made to detect any violations of this consensus early and ban the peer responsible. Additionally, another suggested approach is to run the scripts of all incoming transactions, taking advantage of the fact that utxos have already been fetched during the validation process.The potential for malicious nodes to modify non-segwit transactions after segwit activation was discussed in a recent thread on Bitcoin Improvement Proposals (BIP). It was suggested that a malicious node could re-format a non-segwit transaction into a segwit transaction with up to 400 Kbytes of segwit witness program data, resulting in both transactions having the same hash. However, due to low fees per byte, such a modified transaction would likely not be properly relayed by the network. An attacker could still modify the original transaction by adding segwit witness program data up to the point of relaying the transaction, successfully preventing it from being mined.Another concern is that an attacker could encode arbitrary data, such as virus signatures or illegal content, into passing non-segwit transactions. One proposed solution is to increase the transaction version to 3 for segwit transactions, ensuring that a non-segwit transaction cannot be converted into a segwit transaction without changing the transaction hash. However, this solution does not address all potential problems, as transactions with a mixture of segwit and non-segwit inputs could still be vulnerable to the same attack, even if they are version 3.To mitigate these issues, a simple check could be added to the IsStandardTX() function to prevent witness programs from having a stack element length greater than the maximum script element size (MAX_SCRIPT_ELEMENT_SIZE). However, a more long-term solution would be to introduce a field for each input or the entire transaction that specifies the maximum size of the witness stack in bytes (maxWitnessSize).Overall, the discussion revolves around the complexities of the segwit code and various approaches to prevent potential attacks or vulnerabilities. It underscores the importance of raising questions and seeking clarification from the community when necessary. The provided links to relevant code and pull requests serve as valuable references for further exploration of the topic. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_Authentication-BIP.xml b/static/bitcoin-dev/Aug_2016/combined_Authentication-BIP.xml index d69195c0f8..08b1dd2263 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Authentication-BIP.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Authentication-BIP.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Authentication BIP - 2023-08-01T18:50:48.866575+00:00 + 2025-09-26T15:30:12.270644+00:00 + python-feedgen Jonas Schnelli 2016-08-12 12:47:31+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Authentication BIP - 2023-08-01T18:50:48.866575+00:00 + 2025-09-26T15:30:12.270786+00:00 - The discussion revolves around the privacy protection of OpenSSH users and the comparison with Bitcoin Core. It is noted that OpenSSH does not prioritize user privacy like Bitcoin Core does. In the discussion, it is suggested that OpenSSH should allow multiple identity-keys per network interface to enhance privacy. The proposal includes using different identity-keys for each network interface. The relevant changes to the proposal can be viewed on GitHub.In the bitcoin-dev mailing list conversation, members discuss whether identity-public-keys should be tied to static IP addresses or if DNS names should be allowed. The purpose of this table is to inform clients which server ID to expect. The design aims to inhibit fingerprinting and prevent tracking unless pubkeys are published. To protect against MITM attacks, the client must know the expected server identity. The idea of allowing wildcard options is raised, but it is clarified that such nodes would not be listed and clients could request authentication without authenticating themselves. The limitation of one identity-key per listening network interface for each node is questioned, suggesting that nodes should be able to have multiple identities at a similar cost to having a large authorized keys list.Andy Schroder expresses mixed feelings about tying identity-public-keys with static IP addresses in a bitcoin-dev post and suggests supporting DNS names in addition to IP addresses. The purpose of the table remains to identify the expected server ID, while also preserving privacy in case of IP address changes. MITM attacks are prevented by ensuring the client knows the server's identity. OpenSSH is mentioned as not prioritizing user privacy like Bitcoin does. The limitation of only one identity-key per listening network interface is questioned, advocating for the ability to have multiple identities with a similar cost to managing a large authorized keys list.Jonas Schnelli raises concerns about the format of known-peers and authorized-peers files, questioning the strict tie between identity-public-keys and network identifiers due to potential spoofing. For individuals running a Bitcoin node with a dynamic IP address, secure connections back to their own node may be desired. A suggestion is made for a compromise between strict checks and wildcard options. It is unclear if different identity-keys can be used for each IPv4 interface, and one solution proposed is running two instances of bitcoind and pairing them over a local network. The disadvantage mentioned is the potential slowness when dealing with a large authorized-peers database.Jonas Schnelli proposes an authentication scheme to detect and reject MITM attacks in conjunction with BIP151. This requires building trusted connections, and the authentication process uses ECDSA without transmitting secrets. The identity-public-keys used for authentication must be shared over a different channel. Each peer supporting p2p authentication must maintain an editable "database" for authentication state until the encryption/connection terminates. Only one authentication process is allowed per connection. Peers should display/log the identity-public-key as an identity-address to users, encoded as a base58-check ripemd160(sha256) hash. 2016-08-12T12:47:31+00:00 + The discussion revolves around the privacy protection of OpenSSH users and the comparison with Bitcoin Core. It is noted that OpenSSH does not prioritize user privacy like Bitcoin Core does. In the discussion, it is suggested that OpenSSH should allow multiple identity-keys per network interface to enhance privacy. The proposal includes using different identity-keys for each network interface. The relevant changes to the proposal can be viewed on GitHub.In the bitcoin-dev mailing list conversation, members discuss whether identity-public-keys should be tied to static IP addresses or if DNS names should be allowed. The purpose of this table is to inform clients which server ID to expect. The design aims to inhibit fingerprinting and prevent tracking unless pubkeys are published. To protect against MITM attacks, the client must know the expected server identity. The idea of allowing wildcard options is raised, but it is clarified that such nodes would not be listed and clients could request authentication without authenticating themselves. The limitation of one identity-key per listening network interface for each node is questioned, suggesting that nodes should be able to have multiple identities at a similar cost to having a large authorized keys list.Andy Schroder expresses mixed feelings about tying identity-public-keys with static IP addresses in a bitcoin-dev post and suggests supporting DNS names in addition to IP addresses. The purpose of the table remains to identify the expected server ID, while also preserving privacy in case of IP address changes. MITM attacks are prevented by ensuring the client knows the server's identity. OpenSSH is mentioned as not prioritizing user privacy like Bitcoin does. The limitation of only one identity-key per listening network interface is questioned, advocating for the ability to have multiple identities with a similar cost to managing a large authorized keys list.Jonas Schnelli raises concerns about the format of known-peers and authorized-peers files, questioning the strict tie between identity-public-keys and network identifiers due to potential spoofing. For individuals running a Bitcoin node with a dynamic IP address, secure connections back to their own node may be desired. A suggestion is made for a compromise between strict checks and wildcard options. It is unclear if different identity-keys can be used for each IPv4 interface, and one solution proposed is running two instances of bitcoind and pairing them over a local network. The disadvantage mentioned is the potential slowness when dealing with a large authorized-peers database.Jonas Schnelli proposes an authentication scheme to detect and reject MITM attacks in conjunction with BIP151. This requires building trusted connections, and the authentication process uses ECDSA without transmitting secrets. The identity-public-keys used for authentication must be shared over a different channel. Each peer supporting p2p authentication must maintain an editable "database" for authentication state until the encryption/connection terminates. Only one authentication process is allowed per connection. Peers should display/log the identity-public-key as an identity-address to users, encoded as a base58-check ripemd160(sha256) hash. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-151.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-151.xml index 325b9b855d..1b8ca13695 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-151.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-151.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 151 - 2023-08-01T18:42:21.264751+00:00 + 2025-09-26T15:30:03.811236+00:00 + python-feedgen Pieter Wuille 2016-08-31 14:29:53+00:00 @@ -167,13 +168,13 @@ - python-feedgen + 2 Combined summary - BIP 151 - 2023-08-01T18:42:21.264751+00:00 + 2025-09-26T15:30:03.811470+00:00 - In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. 2016-08-31T14:29:53+00:00 + In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Addresses-over-Audio.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Addresses-over-Audio.xml index 21647411d7..d817557d76 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Addresses-over-Audio.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Addresses-over-Audio.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Number Request: Addresses over Audio - 2023-08-01T18:52:20.679598+00:00 + 2025-09-26T15:29:48.992790+00:00 + python-feedgen Daniel Hoffman 2016-08-13 04:41:32+00:00 @@ -115,13 +116,13 @@ - python-feedgen + 2 Combined summary - BIP Number Request: Addresses over Audio - 2023-08-01T18:52:20.679598+00:00 + 2025-09-26T15:29:48.993008+00:00 - A proposal has been put forth to create a Bitcoin Improvement Proposal (BIP) for the transmission of Bitcoin addresses over audio. This would involve encoding the binary representation of a Bitcoin address into an audible tone, allowing for easy transmission of the address. The proposal suggests including error correction mechanisms, but concerns have been raised about the efficiency of repeating the message multiple times for error recovery. As alternatives, trellis modulation or other convolutional codes have been suggested.To guide the development of this proposal, it has been recommended to study existing implementations of audio modems and consider selecting frequencies that are harmonics of each other to complicate detection due to nonlinear distortion. The Bell 202 and similar modem standards chose AFSK frequencies to minimize interference. Additionally, it has been proposed to define channel models to simulate different use cases and evaluate if the requirements have been met.Daniel Hoffman has made updates to a GitHub repository related to this proposal, providing changes and samples of both tone tables. However, a decoder is still needed to fully evaluate the viability of the proposal. Although some individuals on Reddit have expressed interest in conducting decoding experiments, the lack of a decoder means that it remains an idea rather than a formal proposal.Developing a decoder for noisy or distorted channels is expected to be the most complex part of the project and will heavily influence the design of the encoder. To assess its viability, Daniel needs to complete the entire system. Further research and experimentation are anticipated in this area.Another aspect of the proposal involves creating a standardized method for representing Bitcoin addresses over audio. The proposed protocol suggests chopping up the binary representation of the address into 4 or 2-bit chunks, depending on the quality of the audio, and generating tones based on these values. The intention is to make it easy for consumers to donate Bitcoins to podcasts they listen to. Some suggestions have been made to add additional tones to denote amounts in satoshis. However, there are considerations regarding making the signal detectable and easy to decode, while also ensuring it is pleasant to listen to and does not interfere with speech frequencies.The full specification of the BIP can be found on the proposer's GitHub page. Further research and experimentation are expected to be conducted in this area to fully evaluate the proposed method of representing Bitcoin addresses over audio. 2016-08-13T04:41:32+00:00 + A proposal has been put forth to create a Bitcoin Improvement Proposal (BIP) for the transmission of Bitcoin addresses over audio. This would involve encoding the binary representation of a Bitcoin address into an audible tone, allowing for easy transmission of the address. The proposal suggests including error correction mechanisms, but concerns have been raised about the efficiency of repeating the message multiple times for error recovery. As alternatives, trellis modulation or other convolutional codes have been suggested.To guide the development of this proposal, it has been recommended to study existing implementations of audio modems and consider selecting frequencies that are harmonics of each other to complicate detection due to nonlinear distortion. The Bell 202 and similar modem standards chose AFSK frequencies to minimize interference. Additionally, it has been proposed to define channel models to simulate different use cases and evaluate if the requirements have been met.Daniel Hoffman has made updates to a GitHub repository related to this proposal, providing changes and samples of both tone tables. However, a decoder is still needed to fully evaluate the viability of the proposal. Although some individuals on Reddit have expressed interest in conducting decoding experiments, the lack of a decoder means that it remains an idea rather than a formal proposal.Developing a decoder for noisy or distorted channels is expected to be the most complex part of the project and will heavily influence the design of the encoder. To assess its viability, Daniel needs to complete the entire system. Further research and experimentation are anticipated in this area.Another aspect of the proposal involves creating a standardized method for representing Bitcoin addresses over audio. The proposed protocol suggests chopping up the binary representation of the address into 4 or 2-bit chunks, depending on the quality of the audio, and generating tones based on these values. The intention is to make it easy for consumers to donate Bitcoins to podcasts they listen to. Some suggestions have been made to add additional tones to denote amounts in satoshis. However, there are considerations regarding making the signal detectable and easy to decode, while also ensuring it is pleasant to listen to and does not interfere with speech frequencies.The full specification of the BIP can be found on the proposer's GitHub page. Further research and experimentation are expected to be conducted in this area to fully evaluate the proposed method of representing Bitcoin addresses over audio. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Open-Asset.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Open-Asset.xml index 7b3ca6d33f..7376e784d3 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Open-Asset.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Open-Asset.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Number Request: Open Asset - 2023-08-01T18:24:14.439237+00:00 + 2025-09-26T15:30:10.157715+00:00 + python-feedgen Nicolas Dorier 2016-08-13 02:25:04+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - BIP Number Request: Open Asset - 2023-08-01T18:24:14.439237+00:00 + 2025-09-26T15:30:10.157898+00:00 - The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it 2016-08-13T02:25:04+00:00 + The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-Status-updates-including-to-Active-Final-Status-BIP-39-BIP-43-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-Status-updates-including-to-Active-Final-Status-BIP-39-BIP-43-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml index 549b1cd809..2d964885f5 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-Status-updates-including-to-Active-Final-Status-BIP-39-BIP-43-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-Status-updates-including-to-Active-Final-Status-BIP-39-BIP-43-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130 - 2023-08-01T18:58:06.605884+00:00 + 2025-09-26T15:29:53.218880+00:00 + python-feedgen Pieter Wuille 2016-08-25 09:02:27+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130 - 2023-08-01T18:58:06.605884+00:00 + 2025-09-26T15:29:53.219073+00:00 - The discussion on the bitcoin-dev mailing list revolves around the consideration of whether certain Bitcoin Improvement Proposals (BIPs) should be treated as final or not. BIP44, which is widely used by many wallets without any real-world issues, is suggested to be set as final despite its imperfections. Jonas Schnelli initially expresses disagreement with the development paradigm of "maybe detect funds," but later clarifies his statement. The discussion also raises concerns about the gap limits in BIP44 and the potential issues it may cause for merchants who generate multiple addresses. There is a conversation thread discussing the sequential scanning of blockchain transactions and a hypothetical scenario where a user generates 21 addresses, with only one receiving funds immediately and another receiving funds after 180 days. This scenario triggers a resize+20 of the address-lookup-window, but the wallet would need to go back 180 days to detect the transaction on the second address. The discussion ends with a question about whether there is a misunderstanding in this hypothetical scenario.Andreas Schildbach discusses the BIP44 protocol and its lack of encoding a seed birthday necessary for SPV wallets to scan from the beginning of the blockchain. However, some wallets still interoperate on this standard. The status of the protocol depends on its usage rather than its quality. Additionally, BIP43 is suggested to be made final as it only advises other BIPs on how they could do things.Jonas Schnelli raises a concern about the BIP44 Gap Limits, stating that if 20 unused addresses are found in a row, the software stops searching for used addresses beyond that point. The discussion clarifies that this does not require a transaction rescan back to the genesis block every 20 addresses and suggests starting scanning sequentially from the genesis block or a block around the time when BIP44 was written.The discussion highlights potential misdesigns in BIP39 seed phrases and BIP44 gap limits for Bitcoin wallets. The absence of a version number in BIP39 seed phrases raises questions about deriving addresses from an old seed phrase when new derivation methods are used. The BIP44 gap limit, currently set at 20, is also questioned regarding whether it requires a transaction rescan back to the genesis block every 20 addresses or if wallet recovery after BIP44's implementation is necessary for full access to a blockchain indexed by addresses. Overall, the discussion reflects concern for potential issues and limitations in the current design of Bitcoin wallets.Luke Dashjr criticizes the design of BIP39 and BIP44, stating that they are poorly designed. He mentions several reasons, including limited support in Electrum and the complexity of multiple accounts breaking the property of using the same wallet instance on different devices. He also points out inconsistencies and potential problems with BIP39 seed phrases not having a version number. He suggests separating BIP43 from BIP44 to allow for the development of a better standard.Kenneth Heutmaker raises concerns about broken Simplified Payment Verification (SPV) wallets that lack bloom filtering detection. SPV wallets connect only to nodes that support bloom filtering, and if they don't get updates, the wallet becomes outdated, causing panic among users who end up rescanning the blockchain and losing their transaction history. The discussion highlights the need for robustness against abusive peers and the challenges in achieving this due to the design of bloom filtering.BIP 111, also known as NODE_BLOOM service bit, has been implemented in Bitcoin Core and derivatives, but it is unclear if clients are using it. Multibit plans to add detection of the NODE_BLOOM bit, and SPV wallets are advised to update to respect NODE_BLOOM. The discussion emphasizes the importance of detecting the NODE_BLOOM bit to avoid issues with outdated SPV wallets and recommends the use of the new DNS seeder filter option.Luke proposes updating several BIPs to Final Status if no objections are raised, including BIP 39, 44, 67, 125, and 130. He also suggests upgrading the status of BIP 43 to Active as it guides the creation of new BIPs. Developers of Bitcoin clients are requested to comment on their software's support for BIP 111 (NODE_BLOOM service bit) and their intention to support it in the future. If any clients are already using this service bit, BIP 111 will be updated to Final Status in two weeks. 2016-08-25T09:02:27+00:00 + The discussion on the bitcoin-dev mailing list revolves around the consideration of whether certain Bitcoin Improvement Proposals (BIPs) should be treated as final or not. BIP44, which is widely used by many wallets without any real-world issues, is suggested to be set as final despite its imperfections. Jonas Schnelli initially expresses disagreement with the development paradigm of "maybe detect funds," but later clarifies his statement. The discussion also raises concerns about the gap limits in BIP44 and the potential issues it may cause for merchants who generate multiple addresses. There is a conversation thread discussing the sequential scanning of blockchain transactions and a hypothetical scenario where a user generates 21 addresses, with only one receiving funds immediately and another receiving funds after 180 days. This scenario triggers a resize+20 of the address-lookup-window, but the wallet would need to go back 180 days to detect the transaction on the second address. The discussion ends with a question about whether there is a misunderstanding in this hypothetical scenario.Andreas Schildbach discusses the BIP44 protocol and its lack of encoding a seed birthday necessary for SPV wallets to scan from the beginning of the blockchain. However, some wallets still interoperate on this standard. The status of the protocol depends on its usage rather than its quality. Additionally, BIP43 is suggested to be made final as it only advises other BIPs on how they could do things.Jonas Schnelli raises a concern about the BIP44 Gap Limits, stating that if 20 unused addresses are found in a row, the software stops searching for used addresses beyond that point. The discussion clarifies that this does not require a transaction rescan back to the genesis block every 20 addresses and suggests starting scanning sequentially from the genesis block or a block around the time when BIP44 was written.The discussion highlights potential misdesigns in BIP39 seed phrases and BIP44 gap limits for Bitcoin wallets. The absence of a version number in BIP39 seed phrases raises questions about deriving addresses from an old seed phrase when new derivation methods are used. The BIP44 gap limit, currently set at 20, is also questioned regarding whether it requires a transaction rescan back to the genesis block every 20 addresses or if wallet recovery after BIP44's implementation is necessary for full access to a blockchain indexed by addresses. Overall, the discussion reflects concern for potential issues and limitations in the current design of Bitcoin wallets.Luke Dashjr criticizes the design of BIP39 and BIP44, stating that they are poorly designed. He mentions several reasons, including limited support in Electrum and the complexity of multiple accounts breaking the property of using the same wallet instance on different devices. He also points out inconsistencies and potential problems with BIP39 seed phrases not having a version number. He suggests separating BIP43 from BIP44 to allow for the development of a better standard.Kenneth Heutmaker raises concerns about broken Simplified Payment Verification (SPV) wallets that lack bloom filtering detection. SPV wallets connect only to nodes that support bloom filtering, and if they don't get updates, the wallet becomes outdated, causing panic among users who end up rescanning the blockchain and losing their transaction history. The discussion highlights the need for robustness against abusive peers and the challenges in achieving this due to the design of bloom filtering.BIP 111, also known as NODE_BLOOM service bit, has been implemented in Bitcoin Core and derivatives, but it is unclear if clients are using it. Multibit plans to add detection of the NODE_BLOOM bit, and SPV wallets are advised to update to respect NODE_BLOOM. The discussion emphasizes the importance of detecting the NODE_BLOOM bit to avoid issues with outdated SPV wallets and recommends the use of the new DNS seeder filter option.Luke proposes updating several BIPs to Final Status if no objections are raised, including BIP 39, 44, 67, 125, and 130. He also suggests upgrading the status of BIP 43 to Active as it guides the creation of new BIPs. Developers of Bitcoin clients are requested to comment on their software's support for BIP 111 (NODE_BLOOM service bit) and their intention to support it in the future. If any clients are already using this service bit, BIP 111 will be updated to Final Status in two weeks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-clearing-house-addresses.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-clearing-house-addresses.xml index 4adf84c0f4..2211e58645 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-clearing-house-addresses.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-clearing-house-addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP clearing house addresses - 2023-08-01T18:50:10.053142+00:00 + 2025-09-26T15:29:55.332272+00:00 + python-feedgen Tier Nolan 2016-08-08 11:01:57+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - BIP clearing house addresses - 2023-08-01T18:50:10.053142+00:00 + 2025-09-26T15:29:55.332422+00:00 - There is a discussion about the possibility of doing instant trades between altcoins using channels and the exchange as a hub. However, this doesn't work with fiat accounts. To eliminate counter-party risk, a "100% reserve" company could issue fiat tokens that the exchange could trade. This would ensure that investors still have their altcoins and fiat tokens even if the exchange goes down. However, there is still a risk that the token company could go bankrupt. This risk could be mitigated by requiring verified accounts to cash out tokens. The company could set up a blockchain where it signs blocks instead of mining, earning transaction fees and minting fees.Matthew Roberts discusses the usage of centralized exchanges for speculative purposes. Many users do not care about decentralization or security, but use these exchanges to enter and exit complex positions quickly. Centralized exchanges also allow for limit orders, which cannot be executed with channels. However, using channels alongside a centralized exchange can provide the benefits of a distributed exchange. Channels allow for instant funding while giving customers control over their funds. Margin account holders appreciate knowing which funds are under their control versus those held by the exchange.Centralized exchanges play an important role in the Bitcoin ecosystem by allowing efficient price discovery and improving liquidity. Decentralized exchanges may offer greater security, but they are not as efficient for speculators who need to enter and exit complex positions quickly. Erik Aronesty suggests using lightning networks for margin trading to avoid centralization. He proposes a P2P order routing system with market makers running nodes to facilitate routing and execute channel trades instantly.The conversation also touches on the topic of protecting coins in hot wallets from theft. One proposed solution is using output scripts that only allow coins to be sent to a new transaction whose output script is redeemable after several confirmations. This approach could benefit crucial services such as wallets, gambling websites, e-commerce websites, and exchange hot/cold wallets. Managing private keys is also discussed as a way to mitigate risks associated with key management. Keeping some keys offline is an important part of managing risk.The recent hack on Bitcoin has sparked discussions about creating a new address type with a reversal key and settlement layer to revoke transactions. However, this proposal conflicts with Bitcoin's design, which makes transaction reversals impossible. There are also concerns about security and the acceptance of payments from "vaults" by merchants. The author argues that hacks and losses are often due to wrong implementations or poor security practices, rather than flaws in Bitcoin's design.On the Bitcoin-dev mailing list, Matthew Roberts proposed the idea of creating a new address type with a reversal key and settlement layer to revoke transactions. However, it was pointed out that transactions are not sent from addresses, and nLockTime can be used to prevent unauthorized transactions. The discussion explores different ideas for preventing hacks and improving security, including the use of offline keys as firebreaks and the implementation of an "instant" system to prevent double spending.A proposal has been made on the bitcoin-dev mailing list to address the recent hack by creating a new address type with a reversal key and settlement layer. This would provide users with key revocation in case of a breach, as there is currently no defined process to roll back unexpected behavior in computer systems. The proposed address type would require transactions to receive N confirmations before they can't be revoked, and after that, the transaction would be "settled" and coins would become redeemable from their destination output.One of the main advantages of this proposal is that it would improve centralized exchange security by making it impossible for a hot wallet to be raided all at once. Currently, OP codes and TX types are not suitable for a secure clearing mechanism. Existing options such as Nlocktimed TXs and OP_CHECKLOCKTIMEVERIFY have limitations. The proposed settlement phase would also allow for transparent fraud prevention and auditing, as transaction progress would be publicly visible.The proposal builds upon existing background material, including a time-based clearing house proposal by Hacking Distributed and a similar idea for secure wallet design implemented using time-locked ECDSA keys by Matthew Roberts. These related ideas contribute to the development of a more robust and secure system for handling transactions.However, some members of the community argue that the proposed time-based clearing house using blockchains directly is a much better idea than the current proposal. They believe that this approach would offer greater security and efficiency when dealing with reversals and settlements.In conclusion, the discussion around creating a new address type with a reversal key and settlement layer aims to address the recent hack and provide users with key revocation in case of breaches. The proposed system would require transactions to receive N confirmations before becoming irreversible, and a settlement phase would allow for transparent fraud prevention and auditing. While the proposal builds upon existing background material and offers improvements to centralized exchange security, there are alternative ideas, such as a time-based clearing house using blockchains directly, that some members of the community consider to be a better solution. 2016-08-08T11:01:57+00:00 + There is a discussion about the possibility of doing instant trades between altcoins using channels and the exchange as a hub. However, this doesn't work with fiat accounts. To eliminate counter-party risk, a "100% reserve" company could issue fiat tokens that the exchange could trade. This would ensure that investors still have their altcoins and fiat tokens even if the exchange goes down. However, there is still a risk that the token company could go bankrupt. This risk could be mitigated by requiring verified accounts to cash out tokens. The company could set up a blockchain where it signs blocks instead of mining, earning transaction fees and minting fees.Matthew Roberts discusses the usage of centralized exchanges for speculative purposes. Many users do not care about decentralization or security, but use these exchanges to enter and exit complex positions quickly. Centralized exchanges also allow for limit orders, which cannot be executed with channels. However, using channels alongside a centralized exchange can provide the benefits of a distributed exchange. Channels allow for instant funding while giving customers control over their funds. Margin account holders appreciate knowing which funds are under their control versus those held by the exchange.Centralized exchanges play an important role in the Bitcoin ecosystem by allowing efficient price discovery and improving liquidity. Decentralized exchanges may offer greater security, but they are not as efficient for speculators who need to enter and exit complex positions quickly. Erik Aronesty suggests using lightning networks for margin trading to avoid centralization. He proposes a P2P order routing system with market makers running nodes to facilitate routing and execute channel trades instantly.The conversation also touches on the topic of protecting coins in hot wallets from theft. One proposed solution is using output scripts that only allow coins to be sent to a new transaction whose output script is redeemable after several confirmations. This approach could benefit crucial services such as wallets, gambling websites, e-commerce websites, and exchange hot/cold wallets. Managing private keys is also discussed as a way to mitigate risks associated with key management. Keeping some keys offline is an important part of managing risk.The recent hack on Bitcoin has sparked discussions about creating a new address type with a reversal key and settlement layer to revoke transactions. However, this proposal conflicts with Bitcoin's design, which makes transaction reversals impossible. There are also concerns about security and the acceptance of payments from "vaults" by merchants. The author argues that hacks and losses are often due to wrong implementations or poor security practices, rather than flaws in Bitcoin's design.On the Bitcoin-dev mailing list, Matthew Roberts proposed the idea of creating a new address type with a reversal key and settlement layer to revoke transactions. However, it was pointed out that transactions are not sent from addresses, and nLockTime can be used to prevent unauthorized transactions. The discussion explores different ideas for preventing hacks and improving security, including the use of offline keys as firebreaks and the implementation of an "instant" system to prevent double spending.A proposal has been made on the bitcoin-dev mailing list to address the recent hack by creating a new address type with a reversal key and settlement layer. This would provide users with key revocation in case of a breach, as there is currently no defined process to roll back unexpected behavior in computer systems. The proposed address type would require transactions to receive N confirmations before they can't be revoked, and after that, the transaction would be "settled" and coins would become redeemable from their destination output.One of the main advantages of this proposal is that it would improve centralized exchange security by making it impossible for a hot wallet to be raided all at once. Currently, OP codes and TX types are not suitable for a secure clearing mechanism. Existing options such as Nlocktimed TXs and OP_CHECKLOCKTIMEVERIFY have limitations. The proposed settlement phase would also allow for transparent fraud prevention and auditing, as transaction progress would be publicly visible.The proposal builds upon existing background material, including a time-based clearing house proposal by Hacking Distributed and a similar idea for secure wallet design implemented using time-locked ECDSA keys by Matthew Roberts. These related ideas contribute to the development of a more robust and secure system for handling transactions.However, some members of the community argue that the proposed time-based clearing house using blockchains directly is a much better idea than the current proposal. They believe that this approach would offer greater security and efficiency when dealing with reversals and settlements.In conclusion, the discussion around creating a new address type with a reversal key and settlement layer aims to address the recent hack and provide users with key revocation in case of breaches. The proposed system would require transactions to receive N confirmations before becoming irreversible, and a settlement phase would allow for transparent fraud prevention and auditing. While the proposal builds upon existing background material and offers improvements to centralized exchange security, there are alternative ideas, such as a time-based clearing house using blockchains directly, that some members of the community consider to be a better solution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-draft-HTLC-transactions.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-draft-HTLC-transactions.xml index 4e57aa0661..00b983a976 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-draft-HTLC-transactions.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-draft-HTLC-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft: HTLC transactions - 2023-08-01T18:46:03.562680+00:00 + 2025-09-26T15:30:16.500040+00:00 + python-feedgen Johnson Lau 2016-08-17 10:00:37+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP draft: HTLC transactions - 2023-08-01T18:46:03.562680+00:00 + 2025-09-26T15:30:16.500196+00:00 - On July 20, 2016, a discussion took place on the bitcoin-dev mailing list regarding Hash Time-Locked Contract (HTLC) transactions in Bitcoin. Sean Bowe requested feedback on these transactions which allow payment for the preimage of a hash, with CSV/CLTV used to recover funds if the other party is uncooperative. Luke Dashjr proposed using OP_SIZE to address the malleability issue caused by hashing the top item on the stack, and Peter Todd praised this idea.The HTLC scripts have a specific structure, starting with [HASHOP] OP_EQUAL followed by an OP_IF and an OP_ELSE, with a [TIMEOUTOP] OP_DROP in between. The script concludes with an OP_CHECKSIG. However, this design makes the scripts malleable as the top stack item can be modified without invalidating the scriptSig. Todd suggests using the OP_SIZE opcode to make it more difficult for attackers to manipulate transactions. This additional requirement involves adding OP_SIZE OP_2 OP_PICK OP_HASH160 [PUBKEYHASH] OP_EQUALVERIFY to the script.Todd also emphasizes the importance of considering different scenarios, such as malicious parties attempting double-spend attacks. The discussion delves into the vulnerabilities of HTLC transactions and provides suggestions for enhancing their security.In addition to the discussion, Sean Bowe shares his draft BIP for HTLC transactions on GitHub. Members of the community express interest in submitting a BIP to support these transactions in wallets with modifications to Bitcoin Core. An implementation of Bowe's draft BIP is currently under development. The HTLC scripts are seen as valuable for applications like the Lightning network and zero-knowledge contingent payments, as demonstrated by the author's 'pay-to-sudoku' ZKCP demo earlier in the year, which utilized the same script implemented with CLTV and SHA256. 2016-08-17T10:00:37+00:00 + On July 20, 2016, a discussion took place on the bitcoin-dev mailing list regarding Hash Time-Locked Contract (HTLC) transactions in Bitcoin. Sean Bowe requested feedback on these transactions which allow payment for the preimage of a hash, with CSV/CLTV used to recover funds if the other party is uncooperative. Luke Dashjr proposed using OP_SIZE to address the malleability issue caused by hashing the top item on the stack, and Peter Todd praised this idea.The HTLC scripts have a specific structure, starting with [HASHOP] OP_EQUAL followed by an OP_IF and an OP_ELSE, with a [TIMEOUTOP] OP_DROP in between. The script concludes with an OP_CHECKSIG. However, this design makes the scripts malleable as the top stack item can be modified without invalidating the scriptSig. Todd suggests using the OP_SIZE opcode to make it more difficult for attackers to manipulate transactions. This additional requirement involves adding OP_SIZE OP_2 OP_PICK OP_HASH160 [PUBKEYHASH] OP_EQUALVERIFY to the script.Todd also emphasizes the importance of considering different scenarios, such as malicious parties attempting double-spend attacks. The discussion delves into the vulnerabilities of HTLC transactions and provides suggestions for enhancing their security.In addition to the discussion, Sean Bowe shares his draft BIP for HTLC transactions on GitHub. Members of the community express interest in submitting a BIP to support these transactions in wallets with modifications to Bitcoin Core. An implementation of Bowe's draft BIP is currently under development. The HTLC scripts are seen as valuable for applications like the Lightning network and zero-knowledge contingent payments, as demonstrated by the author's 'pay-to-sudoku' ZKCP demo earlier in the year, which utilized the same script implemented with CLTV and SHA256. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_Capital-Efficient-Honeypots-w-Scorched-Earth-Doublespending-Protection.xml b/static/bitcoin-dev/Aug_2016/combined_Capital-Efficient-Honeypots-w-Scorched-Earth-Doublespending-Protection.xml index 9aa6638f88..2d26fa49f6 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Capital-Efficient-Honeypots-w-Scorched-Earth-Doublespending-Protection.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Capital-Efficient-Honeypots-w-Scorched-Earth-Doublespending-Protection.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection - 2023-08-01T18:58:52.364232+00:00 + Combined summary - Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection + 2025-09-26T15:29:59.554648+00:00 + python-feedgen Peter Todd 2016-08-31 20:01:14+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 - Combined summary - Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection - 2023-08-01T18:58:52.364232+00:00 + Combined summary - Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection + 2025-09-26T15:29:59.554815+00:00 - In the context of the Bitcoin blockchain, securing multiple servers can be challenging. One solution is to use one private key per server, but this can be costly when there are many servers to protect. Previous proposals for using tree signatures as honeypots have not been implemented in the Bitcoin protocol. However, a viable option is to use a 2-of-2 multisig and the SIGHASH_SINGLE feature.To implement this approach, a honeypot secret key is shared among all N servers, while a discriminator secret key is kept secret. Each server creates a unique signature with SIGHASH_SINGLE, paying a token amount to a notification address. Additionally, a pre-signed signature created with the discriminator secret key is left on the associated server along with the honeypot secret key.However, using non-standard SIGHASH flags may flag the transactions involved in risk analysis at exchanges and other platforms, which could threaten the fungibility of the reward. To address this, a suggestion is made to use a pre-signed standard transaction instead. This transaction spends the honeypot output to two addresses: a per-server canary address and a change address. Importantly, the private key associated with the change address is left on the server, giving the intruder the ability to spend the change output and claim their reward.A refinement to this concept involves the use of opt-in RBF flags and CPFP-aware transaction replacement. This allows the honeypot owner to potentially recover the honeypot while still learning about the intrusion. In cases where there are attempts at double-spending, the "scorched earth" concept can be employed. A second version of the honeypot pre-signed transaction would spend the entirety of the honeypot output to fees, making it costly for the honeypot owner to double-spend. By publishing this "scorched earth" transaction, the honeypot owner's honesty is encouraged, and CPFP-aware transaction replacement becomes irrelevant.It should be noted that the complexity of these methods may discourage intruders from targeting honeypots altogether. However, the use of Bitcoin-based honeypots provides an incentive for hackers to reveal their presence and activity, ultimately enhancing security measures.Overall, by utilizing a 2-of-2 multisig and the SIGHASH_SINGLE feature, along with additional measures such as opt-in RBF flags and CPFP-aware transaction replacement, the security of multiple servers on the Bitcoin blockchain can be enhanced, providing a more efficient and effective means of protection against intrusion. Additionally, the implementation of CHECKSEQUENCEVERIFY can further ensure that the honeypot output can only be spent if transaction replacement is enabled. 2016-08-31T20:01:14+00:00 + In the context of the Bitcoin blockchain, securing multiple servers can be challenging. One solution is to use one private key per server, but this can be costly when there are many servers to protect. Previous proposals for using tree signatures as honeypots have not been implemented in the Bitcoin protocol. However, a viable option is to use a 2-of-2 multisig and the SIGHASH_SINGLE feature.To implement this approach, a honeypot secret key is shared among all N servers, while a discriminator secret key is kept secret. Each server creates a unique signature with SIGHASH_SINGLE, paying a token amount to a notification address. Additionally, a pre-signed signature created with the discriminator secret key is left on the associated server along with the honeypot secret key.However, using non-standard SIGHASH flags may flag the transactions involved in risk analysis at exchanges and other platforms, which could threaten the fungibility of the reward. To address this, a suggestion is made to use a pre-signed standard transaction instead. This transaction spends the honeypot output to two addresses: a per-server canary address and a change address. Importantly, the private key associated with the change address is left on the server, giving the intruder the ability to spend the change output and claim their reward.A refinement to this concept involves the use of opt-in RBF flags and CPFP-aware transaction replacement. This allows the honeypot owner to potentially recover the honeypot while still learning about the intrusion. In cases where there are attempts at double-spending, the "scorched earth" concept can be employed. A second version of the honeypot pre-signed transaction would spend the entirety of the honeypot output to fees, making it costly for the honeypot owner to double-spend. By publishing this "scorched earth" transaction, the honeypot owner's honesty is encouraged, and CPFP-aware transaction replacement becomes irrelevant.It should be noted that the complexity of these methods may discourage intruders from targeting honeypots altogether. However, the use of Bitcoin-based honeypots provides an incentive for hackers to reveal their presence and activity, ultimately enhancing security measures.Overall, by utilizing a 2-of-2 multisig and the SIGHASH_SINGLE feature, along with additional measures such as opt-in RBF flags and CPFP-aware transaction replacement, the security of multiple servers on the Bitcoin blockchain can be enhanced, providing a more efficient and effective means of protection against intrusion. Additionally, the implementation of CHECKSEQUENCEVERIFY can further ensure that the honeypot output can only be spent if transaction replacement is enabled. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_Fees-and-Accounts.xml b/static/bitcoin-dev/Aug_2016/combined_Fees-and-Accounts.xml index 0206937593..a6f199d7b7 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Fees-and-Accounts.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Fees-and-Accounts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fees and Accounts - 2023-08-01T18:48:41.126636+00:00 + 2025-09-26T15:29:57.444434+00:00 + python-feedgen James MacWhyte 2016-08-04 00:59:11+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Fees and Accounts - 2023-08-01T18:48:41.126636+00:00 + 2025-09-26T15:29:57.444612+00:00 - In a message posted to the bitcoin-dev mailing list, it is highlighted that many people rely on their own separate account systems and use bitcoind primarily for sending, receiving, and verifying transactions. However, it is noted that bitcoind is not intended to be a comprehensive solution for running an entire bitcoin deposit and withdrawal system; it simply provides the necessary tools for building such a system. For those in need of a pre-built solution, companies like BitGo offer platforms that can fulfill this role.The message also raises concerns about the deprecation of accounts in bitcoind. The poster explains that if they have accounts, they must ensure that account holders do not overcharge their accounts. One potential solution suggested is to use "createrawtransaction() + fundrawtransaction() + signrawtransaction()" to guarantee that the transaction can be paid by an account. However, with accounts being deprecated and no sendrawtransactionfrom() method available, the poster faces the dilemma of either constructing their own account system or presuming that the account code will not be untangled and hacking bitcoind to incorporate a sendfrom function with a fixed fee parameter that overrides the size multiplication.The absence of an integrated account system in bitcoind is deemed problematic as it hinders the effective tracking of all incoming funds to all addresses. Without accounts, bitcoind essentially functions as a person-to-person manual client, making it challenging to establish many-to-many automatic organizations on top of the platform. The poster asserts that there are likely numerous developers facing similar predicaments and warns that deprecating accounts without offering a viable alternative could discourage further bitcoin-related development.The writer identifies two key issues with bitcoind that render it unsuitable for many projects. Firstly, if accounts are present, it becomes crucial to prevent account holders from overcharging their accounts. The suggested workaround involves using "createrawtransaction() + fundrawtransaction() + signrawtransaction()" and ensuring that the transaction can be paid by an account. However, since accounts are deprecated and there is no sendrawtransactionfrom() method, the writer must either develop their own account system or hope that they can successfully modify bitcoind to include a sendfrom function with a fixed fee parameter. Secondly, without accounts, bitcoind is limited to being a person-to-person manual client, making it impossible to construct many-to-many automatic organizations on top of the platform. The writer argues against deprecating accounts as it severely restricts the usability of bitcoind for various projects. They even disclose that they ceased development related to bitcoin after encountering difficulties with transactions requiring fees and the platform's inability to handle such fees within accounts.In conclusion, the writer hopes that developers understand their concerns are genuine rather than mere trolling. They emphasize that without accounts, building many-to-many automatic organizations becomes arduous, necessitating predictable fees. While acknowledging privacy issues with using accounts for off-chain microtransactions, the writer asserts that it currently remains the most viable option. 2016-08-04T00:59:11+00:00 + In a message posted to the bitcoin-dev mailing list, it is highlighted that many people rely on their own separate account systems and use bitcoind primarily for sending, receiving, and verifying transactions. However, it is noted that bitcoind is not intended to be a comprehensive solution for running an entire bitcoin deposit and withdrawal system; it simply provides the necessary tools for building such a system. For those in need of a pre-built solution, companies like BitGo offer platforms that can fulfill this role.The message also raises concerns about the deprecation of accounts in bitcoind. The poster explains that if they have accounts, they must ensure that account holders do not overcharge their accounts. One potential solution suggested is to use "createrawtransaction() + fundrawtransaction() + signrawtransaction()" to guarantee that the transaction can be paid by an account. However, with accounts being deprecated and no sendrawtransactionfrom() method available, the poster faces the dilemma of either constructing their own account system or presuming that the account code will not be untangled and hacking bitcoind to incorporate a sendfrom function with a fixed fee parameter that overrides the size multiplication.The absence of an integrated account system in bitcoind is deemed problematic as it hinders the effective tracking of all incoming funds to all addresses. Without accounts, bitcoind essentially functions as a person-to-person manual client, making it challenging to establish many-to-many automatic organizations on top of the platform. The poster asserts that there are likely numerous developers facing similar predicaments and warns that deprecating accounts without offering a viable alternative could discourage further bitcoin-related development.The writer identifies two key issues with bitcoind that render it unsuitable for many projects. Firstly, if accounts are present, it becomes crucial to prevent account holders from overcharging their accounts. The suggested workaround involves using "createrawtransaction() + fundrawtransaction() + signrawtransaction()" and ensuring that the transaction can be paid by an account. However, since accounts are deprecated and there is no sendrawtransactionfrom() method, the writer must either develop their own account system or hope that they can successfully modify bitcoind to include a sendfrom function with a fixed fee parameter. Secondly, without accounts, bitcoind is limited to being a person-to-person manual client, making it impossible to construct many-to-many automatic organizations on top of the platform. The writer argues against deprecating accounts as it severely restricts the usability of bitcoind for various projects. They even disclose that they ceased development related to bitcoin after encountering difficulties with transactions requiring fees and the platform's inability to handle such fees within accounts.In conclusion, the writer hopes that developers understand their concerns are genuine rather than mere trolling. They emphasize that without accounts, building many-to-many automatic organizations becomes arduous, necessitating predictable fees. While acknowledging privacy issues with using accounts for off-chain microtransactions, the writer asserts that it currently remains the most viable option. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_Fwd-Hiding-entire-content-of-on-chain-transactions.xml b/static/bitcoin-dev/Aug_2016/combined_Fwd-Hiding-entire-content-of-on-chain-transactions.xml index 3193d5faf9..dc4e949839 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Fwd-Hiding-entire-content-of-on-chain-transactions.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Fwd-Hiding-entire-content-of-on-chain-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Hiding entire content of on-chain transactions - 2023-08-01T18:52:45.059568+00:00 + 2025-09-26T15:29:42.653035+00:00 + python-feedgen Tony Churyumoff 2016-08-10 07:53:01+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Fwd: Hiding entire content of on-chain transactions - 2023-08-01T18:52:45.059568+00:00 + 2025-09-26T15:29:42.653196+00:00 - In a 2016 email thread, James MacWhyte discusses the potential need for verification by miners to protect against duplicate spends. He mentions a scenario where Alice sends Bob a transaction and Timothy broadcasts a transaction with a random hash that references the same output. Miners are unable to verify if this is valid, resulting in Bob's money becoming useless. MacWhyte explains that a duplicate spend proof must be signed by the same user (Alice) to be considered a double spend.A new proposal has been put forward to hide the entire content of bitcoin transactions. This goes beyond previous privacy measures such as CoinJoin, ring signatures, and Confidential Transactions. The idea is to publish only the hash of inputs and outputs in the blockchain as OP_RETURN, while hiding the entire inputs and outputs. To prevent double-spends, the payer must also publish another hash known as the spend proof, which is the hash of the output being spent. The proposal suggests using a new private coin called Black Bitcoin or BBC, which can be obtained by burning regular BTC. Private transactions would require one input, one previous output, and every output would include a blinding factor.The proposal acknowledges that larger outputs may need to be split into smaller ones, and more inputs may need to be combined when sending large amounts. This could potentially cause privacy leakage, but it can be avoided by using multiple addresses and storing smaller amounts on each address. Exchanges and large merchants may accumulate large coin histories, which should be kept in mind.No hard or soft fork is required for the proposed privacy-preserving currency, BBC. It operates on top of the bitcoin blockchain using the same private keys and addresses as BTC. Each BBC transaction must be enclosed in a small BTC transaction that stores the OP_RETURNs and pays for the fees. The proposal lacks encryption, so true privacy can only be achieved when using bitcoin over Tor.In a discussion on bitcoin transaction design, concerns were raised about the proposed design of hiding entire inputs and outputs. James MacWhyte pointed out that users would need to back up entire histories of every output sent to them, rather than just backing up a single private key. Additionally, being online to receive payments could pose challenges in sending the private message containing the coin's history. Tony Churyumoff suggested using hubs to route end-to-end encrypted messages to address these concerns.Peter Todd responded to a proposal made by James MacWhyte, stating that while verifying transactions is important, preventing double-spending is a fundamental requirement of Bitcoin. He mentioned his own proposal from 2016, which focused on closed seal sets and truth lists for privacy without sacrificing the ability to prevent double-spending. 2016-08-10T07:53:01+00:00 + In a 2016 email thread, James MacWhyte discusses the potential need for verification by miners to protect against duplicate spends. He mentions a scenario where Alice sends Bob a transaction and Timothy broadcasts a transaction with a random hash that references the same output. Miners are unable to verify if this is valid, resulting in Bob's money becoming useless. MacWhyte explains that a duplicate spend proof must be signed by the same user (Alice) to be considered a double spend.A new proposal has been put forward to hide the entire content of bitcoin transactions. This goes beyond previous privacy measures such as CoinJoin, ring signatures, and Confidential Transactions. The idea is to publish only the hash of inputs and outputs in the blockchain as OP_RETURN, while hiding the entire inputs and outputs. To prevent double-spends, the payer must also publish another hash known as the spend proof, which is the hash of the output being spent. The proposal suggests using a new private coin called Black Bitcoin or BBC, which can be obtained by burning regular BTC. Private transactions would require one input, one previous output, and every output would include a blinding factor.The proposal acknowledges that larger outputs may need to be split into smaller ones, and more inputs may need to be combined when sending large amounts. This could potentially cause privacy leakage, but it can be avoided by using multiple addresses and storing smaller amounts on each address. Exchanges and large merchants may accumulate large coin histories, which should be kept in mind.No hard or soft fork is required for the proposed privacy-preserving currency, BBC. It operates on top of the bitcoin blockchain using the same private keys and addresses as BTC. Each BBC transaction must be enclosed in a small BTC transaction that stores the OP_RETURNs and pays for the fees. The proposal lacks encryption, so true privacy can only be achieved when using bitcoin over Tor.In a discussion on bitcoin transaction design, concerns were raised about the proposed design of hiding entire inputs and outputs. James MacWhyte pointed out that users would need to back up entire histories of every output sent to them, rather than just backing up a single private key. Additionally, being online to receive payments could pose challenges in sending the private message containing the coin's history. Tony Churyumoff suggested using hubs to route end-to-end encrypted messages to address these concerns.Peter Todd responded to a proposal made by James MacWhyte, stating that while verifying transactions is important, preventing double-spending is a fundamental requirement of Bitcoin. He mentioned his own proposal from 2016, which focused on closed seal sets and truth lists for privacy without sacrificing the ability to prevent double-spending. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_General-bitcoin-users-mailing-list-.xml b/static/bitcoin-dev/Aug_2016/combined_General-bitcoin-users-mailing-list-.xml index 42302c1e8d..ab1bb78f28 100644 --- a/static/bitcoin-dev/Aug_2016/combined_General-bitcoin-users-mailing-list-.xml +++ b/static/bitcoin-dev/Aug_2016/combined_General-bitcoin-users-mailing-list-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - General bitcoin users mailing list? - 2023-08-01T18:52:59.192967+00:00 + 2025-09-26T15:30:08.045052+00:00 + python-feedgen Luke Dashjr 2016-08-14 04:22:40+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - General bitcoin users mailing list? - 2023-08-01T18:52:59.192967+00:00 + 2025-09-26T15:30:08.045184+00:00 - On August 14th, 2016, a user named Cannon sent a message to the bitcoin-dev mailing list inquiring about the existence of a mailing list specifically for general users of Bitcoin. The bitcoin-dev mailing list is primarily focused on development-related topics and Cannon was looking for a forum for non-development questions related to Bitcoin. In response to Cannon's inquiry, a link was provided leading to the bitcoin-discuss mailing list, which is intended for general discussion about Bitcoin and related technologies. This mailing list is open to anyone who wants to participate and discuss various aspects of Bitcoin that may not be directly related to development.In another email sent to the bitcoin-dev mailing list on August 13, 2016, Cannon sought information about a general users mailing list for bitcoin-related topics that do not necessarily involve development. The bitcoin-dev mailing list is specifically designed for development-related discussions, so Cannon was searching for a platform for more general conversations. In this email, Cannon included their contact information, including a PGP fingerprint, Bitmessage address, and Ricochet-IM.As a response to Cannon's inquiry, other users suggested exploring the /r/btc and /r/Bitcoin subreddits on Reddit as potential forums for more general discussions about Bitcoin.To summarize, the author of the communication posed a question regarding the existence of a mailing list for general users of Bitcoin, separate from the development-focused bitcoin-dev mailing list. They provided their contact information and were directed towards the bitcoin-discuss mailing list as well as the /r/btc and /r/Bitcoin subreddits on Reddit for broader discussions about Bitcoin. 2016-08-14T04:22:40+00:00 + On August 14th, 2016, a user named Cannon sent a message to the bitcoin-dev mailing list inquiring about the existence of a mailing list specifically for general users of Bitcoin. The bitcoin-dev mailing list is primarily focused on development-related topics and Cannon was looking for a forum for non-development questions related to Bitcoin. In response to Cannon's inquiry, a link was provided leading to the bitcoin-discuss mailing list, which is intended for general discussion about Bitcoin and related technologies. This mailing list is open to anyone who wants to participate and discuss various aspects of Bitcoin that may not be directly related to development.In another email sent to the bitcoin-dev mailing list on August 13, 2016, Cannon sought information about a general users mailing list for bitcoin-related topics that do not necessarily involve development. The bitcoin-dev mailing list is specifically designed for development-related discussions, so Cannon was searching for a platform for more general conversations. In this email, Cannon included their contact information, including a PGP fingerprint, Bitmessage address, and Ricochet-IM.As a response to Cannon's inquiry, other users suggested exploring the /r/btc and /r/Bitcoin subreddits on Reddit as potential forums for more general discussions about Bitcoin.To summarize, the author of the communication posed a question regarding the existence of a mailing list for general users of Bitcoin, separate from the development-focused bitcoin-dev mailing list. They provided their contact information and were directed towards the bitcoin-discuss mailing list as well as the /r/btc and /r/Bitcoin subreddits on Reddit for broader discussions about Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_Hardware-Wallet-Standard.xml b/static/bitcoin-dev/Aug_2016/combined_Hardware-Wallet-Standard.xml index 334d99ccdd..2d0048ca69 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Hardware-Wallet-Standard.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Hardware-Wallet-Standard.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hardware Wallet Standard - 2023-08-01T18:55:11.739631+00:00 + 2025-09-26T15:30:18.618203+00:00 + python-feedgen Corey Haddad 2016-08-28 23:14:03+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Hardware Wallet Standard - 2023-08-01T18:55:11.739631+00:00 + 2025-09-26T15:30:18.618389+00:00 - The discussion surrounding hardware wallets and their integration into Bitcoin Core revolves around several key points. One concern is the possibility of a "cosmic ray" flipping a bit during address generation, leading to lost funds. To mitigate this risk, some users generate addresses on two independent machines using different software. However, a proposed solution suggests that both a detached signer and a normal wallet should verify the correctness of generated addresses before coins are sent there. This would offer protection against losing money due to a defective hardware wallet.There is also a debate about the usefulness of a signing protocol, with some arguing that it is only valuable for hardware wallets. However, others believe that any website wanting to request public keys/signatures from users would find this protocol beneficial. The focus should not only be on servicing hardware but also on allowing users to choose their own ECDSA implementation, whether it be hardware or software.One participant in the discussion expresses concerns about defining rigid standards for hardware wallet development and integration. They argue that the TREZOR concept of a device as a server and primary source of workflow management goes against the proposal of wallet software as a workflow manager. Another member of the discussion agrees with this sentiment, stating that driving any hardware wallet from the wallet itself or from a third-party daemon implementing a URL scheme would provide better device interoperability and easier maintenance and update paths for wallets.The concept of building a standard on top of the URI protocol is seen as a limitation by some. Instead, it is suggested that high-level APIs be used to implement hardware-specific protocols and transports as plugins. This approach would make life easier for app developers without defining artificial "standards." Additionally, there are discussions about the use of smartcards in hardware wallets and the potential risks associated with blindly signing transactions. Suggestions are made to use hardware security modules (HSMs) instead of smartcards and to utilize out-of-band communication channels for validating business logic.Other topics of discussion include the use of the stdio/pipe approach versus the URI scheme for hardware wallets, the need for a clear interface between wallet and signing device, and the possibility of defining a standard on the hardware interaction layer. Finally, there is debate about the feasibility of ECC-enabled smart-cards signing Bitcoin transactions and the suggestion to add custom logic for validation to these cards.Overall, the discussions highlight the importance of security, interoperability, and ease of use when it comes to integrating hardware wallets into Bitcoin Core. The proposals and debates aim to provide improved security measures and a better user experience for Bitcoin Core users.In a Bitcoin development discussion, Thomas proposes a protocol for offline signing of transactions initiated on merchant websites. He suggests that the procedure is similar to multi-signature addresses but emphasizes the need for requesting an xpub/public key. He also mentions the importance of redeemScript and witnessScript for full validation and signing of transaction inputs. Thomas believes that his proposal allows users to provide their own xpub and leverage services provided by GreenAddress without relying on their signing code.Jochen responds to Jonas' draft and suggests that a wallet needs to connect with a hardware wallet to learn the xpubs controlled by the hardware. He highlights missing points in the specification, including the amount spent by each input and checks required for multisig change addresses. Jochen also finds the specification ambiguous for P2SH transactions and proposes a solution to clarify the inputscript.A user asks why a normal smart-card with ECC encryption cannot be used for the hardware signing component of a wallet app. Peter Todd responds, stating that ECC-enabled smart cards cannot sign the specific curve used by Bitcoin and generally only support higher-level protocols. He also mentions the security risks and blind signing associated with smart cards.Bitcoin developers discuss standardizing the hardware protocol to improve user experience. Some hardware wallets have already implemented Trezor's interface. The existing URI scheme allows disambiguation by manufacturer but lacks a way to enumerate available manufacturers or enabled wallets. The specification could have two layers - raw messages and transport mechanism. Luke-Jr argues for standardization to eliminate the need for plugin installation.Jonas receives feedback from Jochen on the draft for detached signing. Jochen suggests connecting with a hardware wallet to learn xpubs and provides additional points missing from the specification. He also proposes a solution for ambiguous inputscript in P2SH transactions.Jonas and Pavol Rusnak discuss the need for a better way to validate input amounts in Bitcoin transactions. They agree on creating a standard for new forms of transactions like SegWit and Lightning. The lack of a standard for hardware wallet interfaces has led to proprietary code additions by wallet vendors.Pavol Rusnak expresses his opinion that standardizing extended validation of inputs for current Bitcoin transactions is not sensible due to complexity. However, he suggests considering it for SegWit and Lightning transactions. He mentions TREZOR's extended validation of inputs and believes making the standard unnecessarily complicated is not worth it.The lack of a standard for desktop and mobile wallets to interact with hardware 2016-08-28T23:14:03+00:00 + The discussion surrounding hardware wallets and their integration into Bitcoin Core revolves around several key points. One concern is the possibility of a "cosmic ray" flipping a bit during address generation, leading to lost funds. To mitigate this risk, some users generate addresses on two independent machines using different software. However, a proposed solution suggests that both a detached signer and a normal wallet should verify the correctness of generated addresses before coins are sent there. This would offer protection against losing money due to a defective hardware wallet.There is also a debate about the usefulness of a signing protocol, with some arguing that it is only valuable for hardware wallets. However, others believe that any website wanting to request public keys/signatures from users would find this protocol beneficial. The focus should not only be on servicing hardware but also on allowing users to choose their own ECDSA implementation, whether it be hardware or software.One participant in the discussion expresses concerns about defining rigid standards for hardware wallet development and integration. They argue that the TREZOR concept of a device as a server and primary source of workflow management goes against the proposal of wallet software as a workflow manager. Another member of the discussion agrees with this sentiment, stating that driving any hardware wallet from the wallet itself or from a third-party daemon implementing a URL scheme would provide better device interoperability and easier maintenance and update paths for wallets.The concept of building a standard on top of the URI protocol is seen as a limitation by some. Instead, it is suggested that high-level APIs be used to implement hardware-specific protocols and transports as plugins. This approach would make life easier for app developers without defining artificial "standards." Additionally, there are discussions about the use of smartcards in hardware wallets and the potential risks associated with blindly signing transactions. Suggestions are made to use hardware security modules (HSMs) instead of smartcards and to utilize out-of-band communication channels for validating business logic.Other topics of discussion include the use of the stdio/pipe approach versus the URI scheme for hardware wallets, the need for a clear interface between wallet and signing device, and the possibility of defining a standard on the hardware interaction layer. Finally, there is debate about the feasibility of ECC-enabled smart-cards signing Bitcoin transactions and the suggestion to add custom logic for validation to these cards.Overall, the discussions highlight the importance of security, interoperability, and ease of use when it comes to integrating hardware wallets into Bitcoin Core. The proposals and debates aim to provide improved security measures and a better user experience for Bitcoin Core users.In a Bitcoin development discussion, Thomas proposes a protocol for offline signing of transactions initiated on merchant websites. He suggests that the procedure is similar to multi-signature addresses but emphasizes the need for requesting an xpub/public key. He also mentions the importance of redeemScript and witnessScript for full validation and signing of transaction inputs. Thomas believes that his proposal allows users to provide their own xpub and leverage services provided by GreenAddress without relying on their signing code.Jochen responds to Jonas' draft and suggests that a wallet needs to connect with a hardware wallet to learn the xpubs controlled by the hardware. He highlights missing points in the specification, including the amount spent by each input and checks required for multisig change addresses. Jochen also finds the specification ambiguous for P2SH transactions and proposes a solution to clarify the inputscript.A user asks why a normal smart-card with ECC encryption cannot be used for the hardware signing component of a wallet app. Peter Todd responds, stating that ECC-enabled smart cards cannot sign the specific curve used by Bitcoin and generally only support higher-level protocols. He also mentions the security risks and blind signing associated with smart cards.Bitcoin developers discuss standardizing the hardware protocol to improve user experience. Some hardware wallets have already implemented Trezor's interface. The existing URI scheme allows disambiguation by manufacturer but lacks a way to enumerate available manufacturers or enabled wallets. The specification could have two layers - raw messages and transport mechanism. Luke-Jr argues for standardization to eliminate the need for plugin installation.Jonas receives feedback from Jochen on the draft for detached signing. Jochen suggests connecting with a hardware wallet to learn xpubs and provides additional points missing from the specification. He also proposes a solution for ambiguous inputscript in P2SH transactions.Jonas and Pavol Rusnak discuss the need for a better way to validate input amounts in Bitcoin transactions. They agree on creating a standard for new forms of transactions like SegWit and Lightning. The lack of a standard for hardware wallet interfaces has led to proprietary code additions by wallet vendors.Pavol Rusnak expresses his opinion that standardizing extended validation of inputs for current Bitcoin transactions is not sensible due to complexity. However, he suggests considering it for SegWit and Lightning transactions. He mentions TREZOR's extended validation of inputs and believes making the standard unnecessarily complicated is not worth it.The lack of a standard for desktop and mobile wallets to interact with hardware - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_Hiding-entire-content-of-on-chain-transactions.xml b/static/bitcoin-dev/Aug_2016/combined_Hiding-entire-content-of-on-chain-transactions.xml index 305dab2e64..f67cf51543 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Hiding-entire-content-of-on-chain-transactions.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Hiding-entire-content-of-on-chain-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hiding entire content of on-chain transactions - 2023-08-01T18:51:36.883189+00:00 + 2025-09-26T15:30:05.931123+00:00 + python-feedgen Tony Churyumoff 2016-08-10 08:37:37+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Hiding entire content of on-chain transactions - 2023-08-01T18:51:36.883189+00:00 + 2025-09-26T15:30:05.931269+00:00 - A proposed design has been suggested to enhance the privacy of Bitcoin transactions. Unlike current methods such as CoinJoin, ring signatures, and Confidential Transactions, this proposal aims to hide the entire inputs and outputs by only publishing their hashes on the blockchain. The plaintext of inputs and outputs would be sent directly to the recipient via a private message.The main concept behind this design is to ensure that the entire inputs and outputs remain hidden while only their hashes are visible on the blockchain. To prevent double-spending, the payer also needs to publish another hash representing the output being spent. Each private payment must include a blinding factor for every output.To track the ownership of the private coin, each new owner must store its complete history. When spending the coin, the user forwards the entire history to the next owner and extends it with their own transaction. Merging coins is prohibited, but splitting them is allowed. However, to avoid excessive fragmentation, private coins must be issued in specific denominations.To issue the new private coins, regular BTC can be burned by sending it to unspendable bitcoin addresses assigned to each denomination. This burning process entitles the user to receive an equal amount of the new private coin, referred to as "black bitcoins" (BBC).After user A sends a private payment to user B, user A will know when the coin is spent by B through the spend proof. However, A will not have any knowledge about the new owner or subsequent movements of the coin. There may be concerns regarding larger outputs being split into smaller ones, potentially causing exchanges and large merchants to accumulate significant coin histories. However, using multiple addresses and storing small amounts on each address can help avoid privacy leakage.Overall, this proposed design offers increased privacy for Bitcoin transactions without requiring a hard or soft fork. It utilizes the same private keys and addresses for both BBC and the base currency BTC, allowing for seamless integration into the existing blockchain infrastructure. The author of the proposal is seeking feedback from the community but has not received any so far. The discussion continues on the bitcoin-dev mailing list, where contact information for Dr. Fabian Kopp, a member of the Institute of Distributed Systems at Ulm University in Germany, can be found. 2016-08-10T08:37:37+00:00 + A proposed design has been suggested to enhance the privacy of Bitcoin transactions. Unlike current methods such as CoinJoin, ring signatures, and Confidential Transactions, this proposal aims to hide the entire inputs and outputs by only publishing their hashes on the blockchain. The plaintext of inputs and outputs would be sent directly to the recipient via a private message.The main concept behind this design is to ensure that the entire inputs and outputs remain hidden while only their hashes are visible on the blockchain. To prevent double-spending, the payer also needs to publish another hash representing the output being spent. Each private payment must include a blinding factor for every output.To track the ownership of the private coin, each new owner must store its complete history. When spending the coin, the user forwards the entire history to the next owner and extends it with their own transaction. Merging coins is prohibited, but splitting them is allowed. However, to avoid excessive fragmentation, private coins must be issued in specific denominations.To issue the new private coins, regular BTC can be burned by sending it to unspendable bitcoin addresses assigned to each denomination. This burning process entitles the user to receive an equal amount of the new private coin, referred to as "black bitcoins" (BBC).After user A sends a private payment to user B, user A will know when the coin is spent by B through the spend proof. However, A will not have any knowledge about the new owner or subsequent movements of the coin. There may be concerns regarding larger outputs being split into smaller ones, potentially causing exchanges and large merchants to accumulate significant coin histories. However, using multiple addresses and storing small amounts on each address can help avoid privacy leakage.Overall, this proposed design offers increased privacy for Bitcoin transactions without requiring a hard or soft fork. It utilizes the same private keys and addresses for both BBC and the base currency BTC, allowing for seamless integration into the existing blockchain infrastructure. The author of the proposal is seeking feedback from the community but has not received any so far. The discussion continues on the bitcoin-dev mailing list, where contact information for Dr. Fabian Kopp, a member of the Institute of Distributed Systems at Ulm University in Germany, can be found. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml b/static/bitcoin-dev/Aug_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml index cf303e3e20..7e5b477d0e 100644 --- a/static/bitcoin-dev/Aug_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml +++ b/static/bitcoin-dev/Aug_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH - 2023-08-01T18:56:33.083218+00:00 + 2025-09-26T15:30:14.384371+00:00 + python-feedgen Russell O'Connor 2016-09-05 14:55:10+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH - 2023-08-01T18:56:33.083218+00:00 + 2025-09-26T15:30:14.384598+00:00 - Suppose we have a marginal fee rate of 50 satoshis per byte. Reducing the size of the witness data by 1 byte is equivalent to a replace by fee that increases the fee by 50 satoshis. In both cases, miners get an extra potential of 50 satoshis in revenue. Replacing witness data with smaller witness data can pay for its own relay cost as much as RBF can, simply by requiring that the smaller witness be small enough to cover the same RBF threshold. BIP125 and mempool eviction both require the replacing transaction to have a higher fee, to compensate for the cost of relaying the replaced transaction(s).Johnson Lau, a member of the bitcoin-dev community, has proposed a restriction for segwit OP_IF argument as a policy. He is seeking more feedback from users of OP_IF to ACK or NACK his proposal. It is expected that Lightning network would use OP_IF frequently. Rusty, another member of the community, mentions that his current scripts use OP_IF and OP_NOTIF only after OP_EQUAL, except for one place where they use OP_EQUAL...OP_EQUAL...OP_ADD OP_IF. However, he notes that there will be no effect on the c-lightning implementation either way.The Bitcoin script validity rules are proposed to change in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts. This would result in the argument for OP_IF and OP_NOTIF being exactly an empty vector or 0x01, or the script evaluation fails immediately. The policy has received a few concept ACKs. A BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts. The proposed changes affect the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts. This is a softfork on top of BIP141. It is enforced as a relay policy by the reference client since the first release of BIP141. Users must not create P2WSH scripts that are incompatible with this BIP to avoid risks of fund loss.In a bitcoin-dev email, Sergio Demian Lerner raised concerns about transactions sent to IoT devices, which may be rejected if their witness program is too large for the device's implementation-imposed limit. This can result in the loss of bitcoins as the private key is stored on the device, rendering it unable to accept the cloned transaction. Lerner suggests invalidating transactions with a higher witness size than expected by the sender. The design of segwit means that resource constrained devices don't need to receive witness data to verify lite-client merkle-path proofs, which are useless for lite-clients anyway.In a discussion on the bitcoin-dev mailing list, Sergio Demian Lerner suggested that the real problem with witness data size is that it is not signed. However, Gregory Maxwell pointed out that this is not possible for the general case as you may not know the witness size in advance. Maxwell believes fees are not the problem, but rather the fact that the maximum witness size may be changed by a miner which could cause issues for devices like IoT or side-chains that have certain restrictions on transaction sizes they can accept. He proposes that if the witness size is higher than the expected size by the sender, the transaction becomes invalid.The issue at hand is that witness data size is not signed, leading to potential malleability issues and problems for systems with hard limits on the size of witness programs they can accept. A proposed solution is to soft-fork and add an opcode OP_PROGSIZE that pushes the size of the segwit program being evaluated onto the stack, which would allow scripts to take action based on the size. This would prevent an attacker from creating a clone of a transaction with a witness ECDSA signature longer than 0x50 bytes. The discussion also touches on workarounds for current behavior and the need to enforce MINIMALIF in some cases, with the suggestion to make it a relay policy first before considering a softfork.On August 17, 2016, Luke Dashjr and Johnson Lau discussed a workaround for the issue of malleability in Bitcoin transactions. The suggested code to replicate the original behavior was deemed ugly by Dashjr, who argued that it was unnecessary in most real-world use cases. He proposed simplifying the code by replacing "OP_SIZE OP_IF" with "OP_SIZE OP_0NOTEQUAL OP_IF", as OP_SIZE must return a valid MINIMALDATA number. However, Lau noted that 2016-09-05T14:55:10+00:00 + Suppose we have a marginal fee rate of 50 satoshis per byte. Reducing the size of the witness data by 1 byte is equivalent to a replace by fee that increases the fee by 50 satoshis. In both cases, miners get an extra potential of 50 satoshis in revenue. Replacing witness data with smaller witness data can pay for its own relay cost as much as RBF can, simply by requiring that the smaller witness be small enough to cover the same RBF threshold. BIP125 and mempool eviction both require the replacing transaction to have a higher fee, to compensate for the cost of relaying the replaced transaction(s).Johnson Lau, a member of the bitcoin-dev community, has proposed a restriction for segwit OP_IF argument as a policy. He is seeking more feedback from users of OP_IF to ACK or NACK his proposal. It is expected that Lightning network would use OP_IF frequently. Rusty, another member of the community, mentions that his current scripts use OP_IF and OP_NOTIF only after OP_EQUAL, except for one place where they use OP_EQUAL...OP_EQUAL...OP_ADD OP_IF. However, he notes that there will be no effect on the c-lightning implementation either way.The Bitcoin script validity rules are proposed to change in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts. This would result in the argument for OP_IF and OP_NOTIF being exactly an empty vector or 0x01, or the script evaluation fails immediately. The policy has received a few concept ACKs. A BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts. The proposed changes affect the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts. This is a softfork on top of BIP141. It is enforced as a relay policy by the reference client since the first release of BIP141. Users must not create P2WSH scripts that are incompatible with this BIP to avoid risks of fund loss.In a bitcoin-dev email, Sergio Demian Lerner raised concerns about transactions sent to IoT devices, which may be rejected if their witness program is too large for the device's implementation-imposed limit. This can result in the loss of bitcoins as the private key is stored on the device, rendering it unable to accept the cloned transaction. Lerner suggests invalidating transactions with a higher witness size than expected by the sender. The design of segwit means that resource constrained devices don't need to receive witness data to verify lite-client merkle-path proofs, which are useless for lite-clients anyway.In a discussion on the bitcoin-dev mailing list, Sergio Demian Lerner suggested that the real problem with witness data size is that it is not signed. However, Gregory Maxwell pointed out that this is not possible for the general case as you may not know the witness size in advance. Maxwell believes fees are not the problem, but rather the fact that the maximum witness size may be changed by a miner which could cause issues for devices like IoT or side-chains that have certain restrictions on transaction sizes they can accept. He proposes that if the witness size is higher than the expected size by the sender, the transaction becomes invalid.The issue at hand is that witness data size is not signed, leading to potential malleability issues and problems for systems with hard limits on the size of witness programs they can accept. A proposed solution is to soft-fork and add an opcode OP_PROGSIZE that pushes the size of the segwit program being evaluated onto the stack, which would allow scripts to take action based on the size. This would prevent an attacker from creating a clone of a transaction with a witness ECDSA signature longer than 0x50 bytes. The discussion also touches on workarounds for current behavior and the need to enforce MINIMALIF in some cases, with the suggestion to make it a relay policy first before considering a softfork.On August 17, 2016, Luke Dashjr and Johnson Lau discussed a workaround for the issue of malleability in Bitcoin transactions. The suggested code to replicate the original behavior was deemed ugly by Dashjr, who argued that it was unnecessary in most real-world use cases. He proposed simplifying the code by replacing "OP_SIZE OP_IF" with "OP_SIZE OP_0NOTEQUAL OP_IF", as OP_SIZE must return a valid MINIMALDATA number. However, Lau noted that - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_New-BIP-Low-S-values-signatures.xml b/static/bitcoin-dev/Aug_2016/combined_New-BIP-Low-S-values-signatures.xml index c7431fa523..1d682b3978 100644 --- a/static/bitcoin-dev/Aug_2016/combined_New-BIP-Low-S-values-signatures.xml +++ b/static/bitcoin-dev/Aug_2016/combined_New-BIP-Low-S-values-signatures.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP: Low S values signatures - 2023-08-01T18:53:25.651454+00:00 + 2025-09-26T15:29:51.108786+00:00 + python-feedgen Johnson Lau 2016-09-02 08:28:14+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - New BIP: Low S values signatures - 2023-08-01T18:53:25.652447+00:00 + 2025-09-26T15:29:51.108972+00:00 - BIP146 proposes changes to the Bitcoin transaction validity rules in order to address signature malleability related to ECDSA signature encoding. This malleability allows relay nodes on the network to alter signatures without needing access to private keys. The BIP introduces two new rules: LOW_S and NULLFAIL. LOW_S restricts the S value inside ECDSA signatures to be at most half of the curve order, with strict DER encoding. If a signature fails the Low S value check and is not an empty byte array, the entire script will evaluate to false immediately. NULLFAIL requires that if an OP_CHECKSIG returns a FALSE value, the relevant signature must be an empty byte array. If an OP_CHECKMULTISIG returns a FALSE value, all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays. The NULLDUMMY rule has been removed from BIP146 and will become another softfork implemented along with segwit. This revision of BIP146 adds the newly implemented NULLFAIL rules which should cover all special cases. The LOW_S softfork may be deployed later due to some undocumented behavior discovered. However, NULLFAIL will be implemented as a policy rule in 0.13.1, but the softfork won't be deployed in 0.13.1.Recently, the BIP146 was updated to include NULLDUMMY as part of the softfork. The update can be found on the Github page of Bitcoin Improvement Proposals (BIPs). This trivial softfork aims to fix malleability related to the extra stack element consumed by CHECKMULTISIG(VERIFY). It is considered important as it prevents attackers from replacing the stack element with any value, which could have serious implications. The inclusion of NULLDUMMY in BIP146 addresses this issue and enhances the security of the cryptocurrency system. This update demonstrates the continuous improvement made to the Bitcoin protocol to enhance security and prevent malicious attacks.On August 16, 2016, there was a discussion between Luke Dashjr and Johnson Lau regarding the ECDSA verification process for signatures passed to operators like OP_CHECKSIG and OP_CHECKMULTISIG. These operators perform verifications on pubkey/signature pairs in reverse order from the top of the stack. If a signature fails the IsLowDERSignature check, it is not processed. However, there is ambiguity in the reference to "the IsLowDERSignature check" as it is not clearly defined. Dashjr points out that the IsLowDERSignature function in Bitcoin Core is not directly called, but he will clarify this.A new Bitcoin Improvement Proposal (BIP) has been proposed to make low S value signatures a consensus rule. The proposal aims to restrict signatures to using low S values to fix malleability issues. ECDSA signatures are malleable, but restricting the S value helps prevent invalidation by taking the negative of the number S. The BIP states that every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY must use an S value between certain limits with strict DER encoding. The BIP will be deployed using version bits BIP9, likely in v0.13.1. The implementation for the reference client can be found on Github. This proposal also reduces transaction malleability, providing additional benefits to the Bitcoin system. 2016-09-02T08:28:14+00:00 + BIP146 proposes changes to the Bitcoin transaction validity rules in order to address signature malleability related to ECDSA signature encoding. This malleability allows relay nodes on the network to alter signatures without needing access to private keys. The BIP introduces two new rules: LOW_S and NULLFAIL. LOW_S restricts the S value inside ECDSA signatures to be at most half of the curve order, with strict DER encoding. If a signature fails the Low S value check and is not an empty byte array, the entire script will evaluate to false immediately. NULLFAIL requires that if an OP_CHECKSIG returns a FALSE value, the relevant signature must be an empty byte array. If an OP_CHECKMULTISIG returns a FALSE value, all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays. The NULLDUMMY rule has been removed from BIP146 and will become another softfork implemented along with segwit. This revision of BIP146 adds the newly implemented NULLFAIL rules which should cover all special cases. The LOW_S softfork may be deployed later due to some undocumented behavior discovered. However, NULLFAIL will be implemented as a policy rule in 0.13.1, but the softfork won't be deployed in 0.13.1.Recently, the BIP146 was updated to include NULLDUMMY as part of the softfork. The update can be found on the Github page of Bitcoin Improvement Proposals (BIPs). This trivial softfork aims to fix malleability related to the extra stack element consumed by CHECKMULTISIG(VERIFY). It is considered important as it prevents attackers from replacing the stack element with any value, which could have serious implications. The inclusion of NULLDUMMY in BIP146 addresses this issue and enhances the security of the cryptocurrency system. This update demonstrates the continuous improvement made to the Bitcoin protocol to enhance security and prevent malicious attacks.On August 16, 2016, there was a discussion between Luke Dashjr and Johnson Lau regarding the ECDSA verification process for signatures passed to operators like OP_CHECKSIG and OP_CHECKMULTISIG. These operators perform verifications on pubkey/signature pairs in reverse order from the top of the stack. If a signature fails the IsLowDERSignature check, it is not processed. However, there is ambiguity in the reference to "the IsLowDERSignature check" as it is not clearly defined. Dashjr points out that the IsLowDERSignature function in Bitcoin Core is not directly called, but he will clarify this.A new Bitcoin Improvement Proposal (BIP) has been proposed to make low S value signatures a consensus rule. The proposal aims to restrict signatures to using low S values to fix malleability issues. ECDSA signatures are malleable, but restricting the S value helps prevent invalidation by taking the negative of the number S. The BIP states that every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY must use an S value between certain limits with strict DER encoding. The BIP will be deployed using version bits BIP9, likely in v0.13.1. The implementation for the reference client can be found on Github. This proposal also reduces transaction malleability, providing additional benefits to the Bitcoin system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml b/static/bitcoin-dev/Aug_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml index 9918fc11b1..74ca3f5881 100644 --- a/static/bitcoin-dev/Aug_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml +++ b/static/bitcoin-dev/Aug_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ScalingBitcoin 2015: Retarget - Call For Proposals Now Open - 2023-08-01T18:48:10.467162+00:00 + 2025-09-26T15:29:44.765134+00:00 + python-feedgen Matt Corallo 2016-09-01 00:56:08+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - ScalingBitcoin 2015: Retarget - Call For Proposals Now Open - 2023-08-01T18:48:10.467162+00:00 + 2025-09-26T15:29:44.765291+00:00 - The Scaling Bitcoin 2016: Retarget conference has extended its deadline for submissions to September 9th. This year, the conference is offering rolling acceptance in an effort to respond to most proposals before September 23rd. The conference defines "scaling" broadly, encompassing topics such as improving Bitcoin throughput, layer 2 ideas, security and privacy, incentives and fee structures, testing, simulation and modeling, network resilience and latency, fungibility, anti-spam measures, block size proposals, and mining concerns.The Call for Proposals (CFP) was opened on August 2nd and can be found on the scalingbitcoin.org website. Interested parties who wish to submit their proposals have until September 2nd to do so. After the submission deadline, applicants will be notified of their acceptance status by September 23rd. The Scaling Bitcoin 2016: Retarget conference will take place in Milan on October 8th and 9th. For more information and to access the CFP, interested individuals can visit the scalingbitcoin.org website. 2016-09-01T00:56:08+00:00 + The Scaling Bitcoin 2016: Retarget conference has extended its deadline for submissions to September 9th. This year, the conference is offering rolling acceptance in an effort to respond to most proposals before September 23rd. The conference defines "scaling" broadly, encompassing topics such as improving Bitcoin throughput, layer 2 ideas, security and privacy, incentives and fee structures, testing, simulation and modeling, network resilience and latency, fungibility, anti-spam measures, block size proposals, and mining concerns.The Call for Proposals (CFP) was opened on August 2nd and can be found on the scalingbitcoin.org website. Interested parties who wish to submit their proposals have until September 2nd to do so. After the submission deadline, applicants will be notified of their acceptance status by September 23rd. The Scaling Bitcoin 2016: Retarget conference will take place in Milan on October 8th and 9th. For more information and to access the CFP, interested individuals can visit the scalingbitcoin.org website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml b/static/bitcoin-dev/Aug_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml index e0a3c3d820..15fcb8d71c 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Status updates for BIP 9, 68, 112, and 113 - 2023-08-01T18:45:24.408771+00:00 + 2025-09-26T15:29:46.880010+00:00 + python-feedgen Btc Drak 2016-08-18 23:05:59+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Status updates for BIP 9, 68, 112, and 113 - 2023-08-01T18:45:24.408771+00:00 + 2025-09-26T15:29:46.880165+00:00 - Luke Dashjr, a Bitcoin Core developer, has announced his plans to update the status of BIPs 9, 68, 112, and 113 to Final in one month. Previously, there was confusion surrounding the classification of BIP 9, as it was unclear whether it fell under the Draft/Accepted/Final or Draft/Active classification. However, Dashjr believes that since BIPs 68, 112, and 113 have already been successfully deployed, BIP 9 should now be considered an informational BIP falling under the Draft/Accepted/Final class. In order to proceed with this update, Dashjr requires at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage.The discussion surrounding BIP 9 centers around its classification as just an "Informational" BIP, despite its importance in the consensus logic. Luke Jr. argues that BIP 9 is merely informational in advising how other BIPs should deploy themselves, making it a grey area. Wladimir J. van der Laan raises concerns over such an important deployment mechanism being classified solely as an informational BIP. However, none of the authors have commented on changing the type of BIP 9, even after a month of discussion. Thus, Luke asks if anyone objects to him updating BIP 9 to Final status.Dashjr suggests that BIP 9 should be reclassified as a "Standard BIP" rather than just an informational one, as it is included as part of the BIP 68 standard. He further explains that any modifications to BIP 9 would likely require a new BIP, and soft-forks utilizing the new standard would refer to the new BIP number. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be considered as part of the Draft/Accepted/Final classification. Additionally, he highlights that BIPs 68, 112, and 113 have already been successfully deployed to the network, satisfying the requirements for both Accepted and Final status. Consequently, Dashjr proposes that all four BIPs (BIPs 9, 68, 112, and 113) should be updated to Final status within one month.To proceed with this update, Dashjr needs at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage. Peter Todd, a developer at Bitcoin, has responded with an ACK in support of the "Final" status. The discussion regarding these updates can be found on the Github BIPs repository. However, it is recommended to continue the discussion via email.In summary, Luke Dashjr plans to update the status of BIPs 9, 68, 112, and 113 to Final within one month. There is a debate surrounding the classification of BIP 9, with Dashjr suggesting it should be considered a "Standard BIP" rather than just informational. He argues that BIP 9 is included as part of the BIP 68 standard and that any modifications would likely require a new BIP. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be classified under the Draft/Accepted/Final category. To proceed with the updates, Dashjr needs sign-offs from authors of each BIP. The discussion took place on the Github BIPs repository, but further communication is recommended via email. 2016-08-18T23:05:59+00:00 + Luke Dashjr, a Bitcoin Core developer, has announced his plans to update the status of BIPs 9, 68, 112, and 113 to Final in one month. Previously, there was confusion surrounding the classification of BIP 9, as it was unclear whether it fell under the Draft/Accepted/Final or Draft/Active classification. However, Dashjr believes that since BIPs 68, 112, and 113 have already been successfully deployed, BIP 9 should now be considered an informational BIP falling under the Draft/Accepted/Final class. In order to proceed with this update, Dashjr requires at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage.The discussion surrounding BIP 9 centers around its classification as just an "Informational" BIP, despite its importance in the consensus logic. Luke Jr. argues that BIP 9 is merely informational in advising how other BIPs should deploy themselves, making it a grey area. Wladimir J. van der Laan raises concerns over such an important deployment mechanism being classified solely as an informational BIP. However, none of the authors have commented on changing the type of BIP 9, even after a month of discussion. Thus, Luke asks if anyone objects to him updating BIP 9 to Final status.Dashjr suggests that BIP 9 should be reclassified as a "Standard BIP" rather than just an informational one, as it is included as part of the BIP 68 standard. He further explains that any modifications to BIP 9 would likely require a new BIP, and soft-forks utilizing the new standard would refer to the new BIP number. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be considered as part of the Draft/Accepted/Final classification. Additionally, he highlights that BIPs 68, 112, and 113 have already been successfully deployed to the network, satisfying the requirements for both Accepted and Final status. Consequently, Dashjr proposes that all four BIPs (BIPs 9, 68, 112, and 113) should be updated to Final status within one month.To proceed with this update, Dashjr needs at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage. Peter Todd, a developer at Bitcoin, has responded with an ACK in support of the "Final" status. The discussion regarding these updates can be found on the Github BIPs repository. However, it is recommended to continue the discussion via email.In summary, Luke Dashjr plans to update the status of BIPs 9, 68, 112, and 113 to Final within one month. There is a debate surrounding the classification of BIP 9, with Dashjr suggesting it should be considered a "Standard BIP" rather than just informational. He argues that BIP 9 is included as part of the BIP 68 standard and that any modifications would likely require a new BIP. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be classified under the Draft/Accepted/Final category. To proceed with the updates, Dashjr needs sign-offs from authors of each BIP. The discussion took place on the Github BIPs repository, but further communication is recommended via email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_-BIP-Proposal-Partially-Signed-Bitcoin-Transaction-PSBT-format.xml b/static/bitcoin-dev/Aug_2017/combined_-BIP-Proposal-Partially-Signed-Bitcoin-Transaction-PSBT-format.xml index a3ad147a77..947968cc38 100644 --- a/static/bitcoin-dev/Aug_2017/combined_-BIP-Proposal-Partially-Signed-Bitcoin-Transaction-PSBT-format.xml +++ b/static/bitcoin-dev/Aug_2017/combined_-BIP-Proposal-Partially-Signed-Bitcoin-Transaction-PSBT-format.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format - 2023-08-01T21:28:28.062120+00:00 - - Greg Sanders 2017-08-22 19:26:30+00:00 - - - Jochen Hoenicke 2017-08-21 21:36:24+00:00 - - - Greg Sanders 2017-08-21 18:12:47+00:00 - - - Bryan Bishop 2017-08-21 00:00:19+00:00 - - - Andrew Chow 2017-08-18 22:11:14+00:00 - + 2025-09-26T15:58:49.516958+00:00 + python-feedgen + + + [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format Andrew Chow + 2017-08-18T22:11:00.000Z + + + Bryan Bishop + 2017-08-21T00:00:00.000Z + + + Greg Sanders + 2017-08-21T18:12:00.000Z + + + Jochen Hoenicke + 2017-08-21T21:36:00.000Z + + + Greg Sanders + 2017-08-22T19:26:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format - 2023-08-01T21:28:28.062120+00:00 + 2025-09-26T15:58:49.517734+00:00 - The discussion revolves around securing partially signed transactions for inputs without compromising privacy. One suggestion is to include an ownership proof for each input, which involves a signature over H(A || x) using the key for A. However, this approach raises concerns about privacy and re-use of signatures. To address these issues, it is proposed to sign a message like HMAC("ownership proof", H(A || x)) instead. This ensures non-ownership proof or proof that the hardware wallet doesn't own the address. The verification of the signature requires making 'x' public. The challenge is to prevent the reuse of signatures as ownership proof for different purposes.On August 21, 2017, Greg Sanders proposed a solution to address the problem with partially signed transactions. He collaborated with andytoshi and developed a solution that works in all cases. According to the proposal, when a signing device receives a partially signed transaction, all inputs must come with an ownership proof. The hardware wallet validates each signature and attempts to decode the hash using its private fixed key. If the hash doesn't match, it cannot be its own input. The hardware wallet signs for every input that belongs to it. Jochen raised concerns about the private fixed key 'x' and suggested making it public for signature verification. It was unclear what exactly is signed with which key and how it is checked. Additionally, the prevention of signature reuse for different purposes was emphasized.The writer discusses the issue of hardware wallet attacks through input ownership omission and proposes a possible solution. They highlight the importance of protecting users while performing safe automated coinjoins and avoiding repeated actions with reversed sets of inputs. The writer also mentions the problem related to Segwit inputs, where an attacker can claim a lower value than the actual amount. To fix these problems, a solution is proposed that requires all inputs in a partially signed transaction to come with an ownership proof. The validation of signatures and decoding of the hash using the private fixed key 'x' ensure the security of the transaction. This approach offers several benefits such as a small memory footprint, user-interactionless coinjoins without risk, and the ability to create and pass around proofs for Partially Signed Bitcoin Transactions. The writer also refers to a standard format proposal for unsigned and partially signed transactions and provides a link to a related thread on hardware wallet BIP drafting.In an email to the bitcoin-dev mailing list, Andrew Chow introduces a proposed standard format for unsigned and partially signed transactions. Bryan suggests that a thread on hardware wallet BIP drafting could be relevant to this proposal, with a provided link to the thread.The proposed format aims to standardize the binary transaction format for unsigned and partially signed transactions. It enables signers to produce signatures offline based on the information provided in the transaction. The current lack of a standardized format makes it challenging for users of different wallet software to create unsigned or partially signed transactions easily. This document seeks to establish a standard and extensible format that allows clients to pass around the same transaction for signing and combining signatures. The format is designed to facilitate future extensions, which is not feasible with existing transaction formats. It also enables offline signers like air-gapped wallets and hardware wallets to sign transactions without direct access to the UTXO set, reducing the risk of fraud. The full text of the proposal can be found on GitHub. 2017-08-22T19:26:30+00:00 + The discussion revolves around securing partially signed transactions for inputs without compromising privacy. One suggestion is to include an ownership proof for each input, which involves a signature over H(A || x) using the key for A. However, this approach raises concerns about privacy and re-use of signatures. To address these issues, it is proposed to sign a message like HMAC("ownership proof", H(A || x)) instead. This ensures non-ownership proof or proof that the hardware wallet doesn't own the address. The verification of the signature requires making 'x' public. The challenge is to prevent the reuse of signatures as ownership proof for different purposes.On August 21, 2017, Greg Sanders proposed a solution to address the problem with partially signed transactions. He collaborated with andytoshi and developed a solution that works in all cases. According to the proposal, when a signing device receives a partially signed transaction, all inputs must come with an ownership proof. The hardware wallet validates each signature and attempts to decode the hash using its private fixed key. If the hash doesn't match, it cannot be its own input. The hardware wallet signs for every input that belongs to it. Jochen raised concerns about the private fixed key 'x' and suggested making it public for signature verification. It was unclear what exactly is signed with which key and how it is checked. Additionally, the prevention of signature reuse for different purposes was emphasized.The writer discusses the issue of hardware wallet attacks through input ownership omission and proposes a possible solution. They highlight the importance of protecting users while performing safe automated coinjoins and avoiding repeated actions with reversed sets of inputs. The writer also mentions the problem related to Segwit inputs, where an attacker can claim a lower value than the actual amount. To fix these problems, a solution is proposed that requires all inputs in a partially signed transaction to come with an ownership proof. The validation of signatures and decoding of the hash using the private fixed key 'x' ensure the security of the transaction. This approach offers several benefits such as a small memory footprint, user-interactionless coinjoins without risk, and the ability to create and pass around proofs for Partially Signed Bitcoin Transactions. The writer also refers to a standard format proposal for unsigned and partially signed transactions and provides a link to a related thread on hardware wallet BIP drafting.In an email to the bitcoin-dev mailing list, Andrew Chow introduces a proposed standard format for unsigned and partially signed transactions. Bryan suggests that a thread on hardware wallet BIP drafting could be relevant to this proposal, with a provided link to the thread.The proposed format aims to standardize the binary transaction format for unsigned and partially signed transactions. It enables signers to produce signatures offline based on the information provided in the transaction. The current lack of a standardized format makes it challenging for users of different wallet software to create unsigned or partially signed transactions easily. This document seeks to establish a standard and extensible format that allows clients to pass around the same transaction for signing and combining signatures. The format is designed to facilitate future extensions, which is not feasible with existing transaction formats. It also enables offline signers like air-gapped wallets and hardware wallets to sign transactions without direct access to the UTXO set, reducing the risk of fraud. The full text of the proposal can be found on GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_-Compressed-headers-stream.xml b/static/bitcoin-dev/Aug_2017/combined_-Compressed-headers-stream.xml index ad3d4b2424..e03028b96f 100644 --- a/static/bitcoin-dev/Aug_2017/combined_-Compressed-headers-stream.xml +++ b/static/bitcoin-dev/Aug_2017/combined_-Compressed-headers-stream.xml @@ -1,47 +1,75 @@ - + 2 - Combined summary - "Compressed" headers stream - 2023-08-01T21:30:19.625066+00:00 - - Gregory Maxwell 2017-12-13 00:12:45+00:00 - - - Gregory Maxwell 2017-12-13 00:01:32+00:00 - - - Suhas Daftuar 2017-12-12 21:07:11+00:00 - - - Gregory Maxwell 2017-12-11 23:11:24+00:00 - - - Tier Nolan 2017-12-11 22:41:50+00:00 - - - Jim Posen 2017-12-11 21:56:08+00:00 - - - Gregory Maxwell 2017-12-11 21:04:01+00:00 - - - Jim Posen 2017-12-11 20:40:00+00:00 - - - Peter Todd 2017-09-04 14:10:17+00:00 - - - Greg Sanders 2017-08-28 16:26:48+00:00 - - - Riccardo Casatta 2017-08-28 16:25:01+00:00 - - - Greg Sanders 2017-08-28 16:13:11+00:00 - - - Riccardo Casatta 2017-08-28 15:50:23+00:00 - + Combined summary - "Compressed" headers stream + 2025-09-26T15:58:36.796377+00:00 + python-feedgen + + + Riccardo Casatta + 2017-08-28T15:50:00.000Z + + + Greg Sanders + 2017-08-28T16:13:00.000Z + + + Riccardo Casatta + 2017-08-28T16:25:00.000Z + + + Greg Sanders + 2017-08-28T16:26:00.000Z + + + [bitcoin-dev] Fwd: " Gregory Maxwell + 2017-08-28T17:12:00.000Z + + + Kalle Rosenbaum + 2017-08-28T17:54:00.000Z + + + Peter Todd + 2017-09-04T14:06:00.000Z + + + Peter Todd + 2017-09-04T14:10:00.000Z + + + [bitcoin-dev] "Compressed" headers stream Jim Posen + 2017-12-11T20:40:00.000Z + + + Gregory Maxwell + 2017-12-11T21:04:00.000Z + + + Jim Posen + 2017-12-11T21:56:00.000Z + + + Tier Nolan + 2017-12-11T22:41:00.000Z + + + Gregory Maxwell + 2017-12-11T23:11:00.000Z + + + Suhas Daftuar + 2017-12-12T21:07:00.000Z + + + Gregory Maxwell + 2017-12-13T00:01:00.000Z + + + Gregory Maxwell + 2017-12-13T00:12:00.000Z + + @@ -55,13 +83,13 @@ - python-feedgen + 2 - Combined summary - "Compressed" headers stream - 2023-08-01T21:30:19.625066+00:00 + Combined summary - "Compressed" headers stream + 2025-09-26T15:58:36.798304+00:00 - In a recent discussion among Bitcoin developers, Suhas Daftuar and Gregory Maxwell proposed the introduction of a new 'cmpctheaders'/'getcmpcthdrs' message pair for syncing, while keeping the existing 'headers'/'getheaders' messages unchanged. The idea is to never use 'getheaders' messages when communicating with upgraded peers and only use 'headers' messages for potentially announcing new blocks. Peers would fetch headers based on a weak heuristic where they fetch first from those with the tip at the highest difficulty and then work backwards. This proposal also mentions the possibility of changing the interface. [source]Another topic of discussion among Bitcoin developers is the inclusion of nBits in p2p messages without requiring the consensus-correct calculation of nBits. The purpose is to calculate the work on a chain as an anti-DoS measure. It is suggested that nBits could be included in any messages where the value is ambiguous, such as with the first header in a message and whenever it changes from the previous header's nBits. The serialization of existing messages should not be changed, so a new 'cmpctheaders'/'getcmpcthdrs' message pair could be introduced for syncing using this new message type. When communicating with upgraded peers, 'getheaders' messages would never be used, and only 'headers' messages would be used for potentially announcing new blocks. The splitting off of headers chain-sync functionality to a new message pair is seen as a nice side-effect benefit in the long run. [source]Tier Nolan shared a method called "high hash highway" in a Bitcoin-dev discussion, which allows compact proofs of total Proof-of-Work (POW). However, it was deemed off-topic as it provides no security without additional consensus enforced commitments. [source]Jim Posen proposed omitting nBits entirely in Bitcoin headers to save an extra 4 bytes. However, this could lead to more complexity in the validation code. As a compromise, Posen suggested using a one-byte flag to indicate the difference since the last header and stealing bits from the exponent to indicate mode. This approach would save three of the four bytes. Posen also proposed parallel header fetching, where nodes could request the lowest N hashes between two heights on the main chain and receive pairs of {height, header} for the N headers with the lowest hash in the specified range. [source]There is a proposal to reduce the bandwidth needed for Bitcoin header messages by removing the nBits field, which contains difficulty information. The proposal has received criticism for being too dependent on specific validation rules of the Bitcoin protocol. However, supporters argue that omitting nBits saves bytes and is worth the extra complexity in validation code. The discussion also covers the need to encode leading bits of prev, which are used as an extra nonce for miners. While some altcoins have already changed their header structures, making the proposed change possibly incompatible, supporters argue that it would be worth it to competitively advance Bitcoin. Additionally, the possibility of parallel header fetching to optimize header download is discussed. [source]In a Bitcoin-dev mailing list discussion, Greg Sanders raised a question about the use-case of timestamping in Bitcoin. Peter Todd responded by explaining that timestamping can be more vulnerable to malicious miners than financial applications due to the lack of a financial feedback loop. He also noted that timestamping is a non-financial piggy-back application that does not directly interact with the Bitcoin economy beyond a trivial number of timestamp transactions. [source]Riccardo Casatta proposed an optimization for transmitting Bitcoin block headers in a recent email on the Bitcoin-dev mailing list. The proposal suggests that after the first header, subsequent headers need not transmit the previous hash as the receiver can compute it by double hashing the previous header. This optimization could save about 40% bandwidth in a long stream of headers. Casatta believes this optimization could be particularly useful in instances where full node security isn't feasible, such as when dealing with private databases that require timestamping. He also suggests using fixed position chunks in an HTTP API to leverage HTTP caching and speed up synchronization for new clients. [source]In the Bitcoin-dev email thread, Jim Posen expressed his dislike of making the net header encoding dependent on specific header validation rules used by Bitcoin. He proposed a one-byte flag on each header to indicate what was included, suggesting that nBits does not need to be sent even with other consensus rules since it is more or less necessarily a strict function of the prior headers. Posen believes that another >18% reduction in size beyond the removal of prev is significant and should not be ignored. However, Prev omission itself is not compatible, and Posen suggests that if there is a Bitcoin hardfork, it would recover the necessary bits from prev to use as an extra nonce for miners. Many altcoins have also changed their header structures, so even if the proposed change is altcoin incompatible, it should still be considered. Changing the serialization of 2017-12-13T00:12:45+00:00 + In a recent discussion among Bitcoin developers, Suhas Daftuar and Gregory Maxwell proposed the introduction of a new 'cmpctheaders'/'getcmpcthdrs' message pair for syncing, while keeping the existing 'headers'/'getheaders' messages unchanged. The idea is to never use 'getheaders' messages when communicating with upgraded peers and only use 'headers' messages for potentially announcing new blocks. Peers would fetch headers based on a weak heuristic where they fetch first from those with the tip at the highest difficulty and then work backwards. This proposal also mentions the possibility of changing the interface. [source]Another topic of discussion among Bitcoin developers is the inclusion of nBits in p2p messages without requiring the consensus-correct calculation of nBits. The purpose is to calculate the work on a chain as an anti-DoS measure. It is suggested that nBits could be included in any messages where the value is ambiguous, such as with the first header in a message and whenever it changes from the previous header's nBits. The serialization of existing messages should not be changed, so a new 'cmpctheaders'/'getcmpcthdrs' message pair could be introduced for syncing using this new message type. When communicating with upgraded peers, 'getheaders' messages would never be used, and only 'headers' messages would be used for potentially announcing new blocks. The splitting off of headers chain-sync functionality to a new message pair is seen as a nice side-effect benefit in the long run. [source]Tier Nolan shared a method called "high hash highway" in a Bitcoin-dev discussion, which allows compact proofs of total Proof-of-Work (POW). However, it was deemed off-topic as it provides no security without additional consensus enforced commitments. [source]Jim Posen proposed omitting nBits entirely in Bitcoin headers to save an extra 4 bytes. However, this could lead to more complexity in the validation code. As a compromise, Posen suggested using a one-byte flag to indicate the difference since the last header and stealing bits from the exponent to indicate mode. This approach would save three of the four bytes. Posen also proposed parallel header fetching, where nodes could request the lowest N hashes between two heights on the main chain and receive pairs of {height, header} for the N headers with the lowest hash in the specified range. [source]There is a proposal to reduce the bandwidth needed for Bitcoin header messages by removing the nBits field, which contains difficulty information. The proposal has received criticism for being too dependent on specific validation rules of the Bitcoin protocol. However, supporters argue that omitting nBits saves bytes and is worth the extra complexity in validation code. The discussion also covers the need to encode leading bits of prev, which are used as an extra nonce for miners. While some altcoins have already changed their header structures, making the proposed change possibly incompatible, supporters argue that it would be worth it to competitively advance Bitcoin. Additionally, the possibility of parallel header fetching to optimize header download is discussed. [source]In a Bitcoin-dev mailing list discussion, Greg Sanders raised a question about the use-case of timestamping in Bitcoin. Peter Todd responded by explaining that timestamping can be more vulnerable to malicious miners than financial applications due to the lack of a financial feedback loop. He also noted that timestamping is a non-financial piggy-back application that does not directly interact with the Bitcoin economy beyond a trivial number of timestamp transactions. [source]Riccardo Casatta proposed an optimization for transmitting Bitcoin block headers in a recent email on the Bitcoin-dev mailing list. The proposal suggests that after the first header, subsequent headers need not transmit the previous hash as the receiver can compute it by double hashing the previous header. This optimization could save about 40% bandwidth in a long stream of headers. Casatta believes this optimization could be particularly useful in instances where full node security isn't feasible, such as when dealing with private databases that require timestamping. He also suggests using fixed position chunks in an HTTP API to leverage HTTP caching and speed up synchronization for new clients. [source]In the Bitcoin-dev email thread, Jim Posen expressed his dislike of making the net header encoding dependent on specific header validation rules used by Bitcoin. He proposed a one-byte flag on each header to indicate what was included, suggesting that nBits does not need to be sent even with other consensus rules since it is more or less necessarily a strict function of the prior headers. Posen believes that another >18% reduction in size beyond the removal of prev is significant and should not be ignored. However, Prev omission itself is not compatible, and Posen suggests that if there is a Bitcoin hardfork, it would recover the necessary bits from prev to use as an extra nonce for miners. Many altcoins have also changed their header structures, so even if the proposed change is altcoin incompatible, it should still be considered. Changing the serialization of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml b/static/bitcoin-dev/Aug_2017/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml index 7db93a92a4..0766c4d471 100644 --- a/static/bitcoin-dev/Aug_2017/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml +++ b/static/bitcoin-dev/Aug_2017/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - BIP proposal, Pay to Contract BIP43 Application - 2023-08-01T21:26:35.599175+00:00 - - ZmnSCPxj 2019-03-12 07:05:37+00:00 - - - Omar Shibli 2019-03-12 05:53:45+00:00 - - - Omar Shibli 2017-09-01 07:16:41+00:00 - - - omar shibli 2017-08-15 16:40:36+00:00 - - - Gregory Maxwell 2017-08-15 05:12:11+00:00 - - - omar shibli 2017-08-14 06:05:35+00:00 - + 2025-09-26T15:58:53.783517+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application omar shibli + 2017-08-14T06:05:00.000Z + + + Gregory Maxwell + 2017-08-15T05:12:00.000Z + + + omar shibli + 2017-08-15T16:40:00.000Z + + + Omar Shibli + 2017-09-01T07:16:00.000Z + + + Omar Shibli + 2019-03-12T05:53:00.000Z + + + ZmnSCPxj + 2019-03-12T07:05:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal, Pay to Contract BIP43 Application - 2023-08-01T21:26:35.600176+00:00 + 2025-09-26T15:58:53.784406+00:00 - The email conversation revolves around a proposed method for embedding cryptographic signatures into public keys based on HD Wallets - BIP32. ZmnSCPxj raised concerns about the possibility of an attacker finding two contracts whose derivations alias each other and the possibility of multiple contracting systems. Omar Shibli responded to Gregory Maxwell's feedback with some fixes which he submitted on Github. Omar Shibli further expressed his opinion that the security fix was redundant. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey.In August 2017, Omar Shibli shared his method for embedding cryptographic signatures into a public key based on HD Wallets - BIP32, in a trade finance application. He proposed defining various levels in BIP32 path to compute child public keys and addresses. He also provided an example of contract commitment address computation. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey. Gregory also pointed out that the proposal did not address durability issues. Omar Shibli updated the BIP to address Gregory's concerns.The email thread includes a message from Omar Shibli expressing his appreciation for Gregory Maxwell's work in the FOSS ecosystem, particularly in Bitcoin and Blockstream. He also submitted fixes to Gregory's concerns regarding a security fix patch in the CKD function (BIP32) and requested his review. In another email, Omar shared an updated draft of a BIP specifying the multiparty key derivation scheme for the pay-to-contract protocol and sought feedback. Gregory had previously raised concerns about the security of the construction and durability issues which were not addressed in the proposal. Omar clarified the application of the construction, provided an example and updated the BIP to address Gregory's concerns. The full BIP draft is available on GitHub.A team has developed a basic trade finance application to conduct transactions using the Homomorphic Payment Addresses and the Pay-to-Contract Protocol paper. They have generalised it and made it BIP43 complaint. The team defines levels in BIP32 path as m / purpose' / coin_type' / contract_id' / *. Contract_id is an arbitrary number within the valid range of indices. Then, they define contract base as following prefix: m / purpose' / coin_type' / contract_id'. Contract commitment address is computed by hashing a document with a cryptographic hash function of your choice (e.g. Blake2), mapping the hash to partial derivation path and computing child public key by chaining the derivation path from step 2 with contract base. Payment address funds could be reclaimed only if the customer_contract_signature is provided by the customer. In terms of durability, their app is pretty simple at this point, they don't store anything, they let customer download and manage the files.The construction appears to be completely insecure, according to Gregory Maxwell. He believes that this is because the pubkey is easily manipulated. The team updated the BIP to explicitly specify the multiparty key derivation scheme, which they hope will address Maxwell's concerns. The BIP draft can be found on GitHub. Omar, from the team, thanks Gregory for his feedback and welcomes any further feedback.The email conversation is about a method to embed cryptographic signatures into public keys based on HD Wallets - BIP32. The application uses two cryptographic signatures from both sides for practical purposes. The proposed construction includes contract base, payment base, and payment address which can only be reclaimed by the customer_contract_signature. The current application is not very durable as it doesn't store anything, instead, the customer downloads and manages the files. Gregory Maxwell raises concerns about the security of the construction, its applications, and durability issues. Omar Shibli describes an abstract idea where levels are defined in BIP32 path, contract_id is an arbitrary number within valid indices and contract commitment address is computed using a cryptographic hash function. He also provides an example to illustrate the process. The full BIP draft is available on GitHub, and they seek feedback to develop a standard.A developer named Omar Shibli has proposed a new method for conducting transactions using the Homomorphic Payment Addresses and Pay-to-Contract Protocol, which uses the homomorphic property of elliptic curve encryption to achieve payment. The proposal defines levels in BIP32 path and contract commitment address that is computed by hashing a document with a cryptographic hash function, partitioning the array into parts, converting each part to an integer in decimal format, and joining all strings with a slash. The proposal does not address security concerns around payment to contracts or durability issues when losing funds if the exact contract is lost. There is no standard specification on how to conduct such transactions in cyberspace, but developers hope this proposal will result in a standard for the benefit of the community. The full BIP draft can be found at the provided link.The pay-to-contract protocol 2019-03-12T07:05:37+00:00 + The email conversation revolves around a proposed method for embedding cryptographic signatures into public keys based on HD Wallets - BIP32. ZmnSCPxj raised concerns about the possibility of an attacker finding two contracts whose derivations alias each other and the possibility of multiple contracting systems. Omar Shibli responded to Gregory Maxwell's feedback with some fixes which he submitted on Github. Omar Shibli further expressed his opinion that the security fix was redundant. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey.In August 2017, Omar Shibli shared his method for embedding cryptographic signatures into a public key based on HD Wallets - BIP32, in a trade finance application. He proposed defining various levels in BIP32 path to compute child public keys and addresses. He also provided an example of contract commitment address computation. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey. Gregory also pointed out that the proposal did not address durability issues. Omar Shibli updated the BIP to address Gregory's concerns.The email thread includes a message from Omar Shibli expressing his appreciation for Gregory Maxwell's work in the FOSS ecosystem, particularly in Bitcoin and Blockstream. He also submitted fixes to Gregory's concerns regarding a security fix patch in the CKD function (BIP32) and requested his review. In another email, Omar shared an updated draft of a BIP specifying the multiparty key derivation scheme for the pay-to-contract protocol and sought feedback. Gregory had previously raised concerns about the security of the construction and durability issues which were not addressed in the proposal. Omar clarified the application of the construction, provided an example and updated the BIP to address Gregory's concerns. The full BIP draft is available on GitHub.A team has developed a basic trade finance application to conduct transactions using the Homomorphic Payment Addresses and the Pay-to-Contract Protocol paper. They have generalised it and made it BIP43 complaint. The team defines levels in BIP32 path as m / purpose' / coin_type' / contract_id' / *. Contract_id is an arbitrary number within the valid range of indices. Then, they define contract base as following prefix: m / purpose' / coin_type' / contract_id'. Contract commitment address is computed by hashing a document with a cryptographic hash function of your choice (e.g. Blake2), mapping the hash to partial derivation path and computing child public key by chaining the derivation path from step 2 with contract base. Payment address funds could be reclaimed only if the customer_contract_signature is provided by the customer. In terms of durability, their app is pretty simple at this point, they don't store anything, they let customer download and manage the files.The construction appears to be completely insecure, according to Gregory Maxwell. He believes that this is because the pubkey is easily manipulated. The team updated the BIP to explicitly specify the multiparty key derivation scheme, which they hope will address Maxwell's concerns. The BIP draft can be found on GitHub. Omar, from the team, thanks Gregory for his feedback and welcomes any further feedback.The email conversation is about a method to embed cryptographic signatures into public keys based on HD Wallets - BIP32. The application uses two cryptographic signatures from both sides for practical purposes. The proposed construction includes contract base, payment base, and payment address which can only be reclaimed by the customer_contract_signature. The current application is not very durable as it doesn't store anything, instead, the customer downloads and manages the files. Gregory Maxwell raises concerns about the security of the construction, its applications, and durability issues. Omar Shibli describes an abstract idea where levels are defined in BIP32 path, contract_id is an arbitrary number within valid indices and contract commitment address is computed using a cryptographic hash function. He also provides an example to illustrate the process. The full BIP draft is available on GitHub, and they seek feedback to develop a standard.A developer named Omar Shibli has proposed a new method for conducting transactions using the Homomorphic Payment Addresses and Pay-to-Contract Protocol, which uses the homomorphic property of elliptic curve encryption to achieve payment. The proposal defines levels in BIP32 path and contract commitment address that is computed by hashing a document with a cryptographic hash function, partitioning the array into parts, converting each part to an integer in decimal format, and joining all strings with a slash. The proposal does not address security concerns around payment to contracts or durability issues when losing funds if the exact contract is lost. There is no standard specification on how to conduct such transactions in cyberspace, but developers hope this proposal will result in a standard for the benefit of the community. The full BIP draft can be found at the provided link.The pay-to-contract protocol - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_BIP-proposal-for-Lightning-oriented-multiaccount-multisig-HD-wallets.xml b/static/bitcoin-dev/Aug_2017/combined_BIP-proposal-for-Lightning-oriented-multiaccount-multisig-HD-wallets.xml index b1ebd5c2a9..e7bbd42f6b 100644 --- a/static/bitcoin-dev/Aug_2017/combined_BIP-proposal-for-Lightning-oriented-multiaccount-multisig-HD-wallets.xml +++ b/static/bitcoin-dev/Aug_2017/combined_BIP-proposal-for-Lightning-oriented-multiaccount-multisig-HD-wallets.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - BIP proposal for Lightning-oriented multiaccount multisig HD wallets - 2023-08-01T21:32:08.647487+00:00 - - Simone Bronzini 2017-08-30 12:48:24+00:00 - - - Simone Bronzini 2017-08-30 12:22:30+00:00 - - - Thomas Voegtlin 2017-08-30 10:07:24+00:00 - - - Luke Dashjr 2017-08-29 20:07:43+00:00 - - - Simone Bronzini 2017-08-29 10:19:10+00:00 - + 2025-09-26T15:59:02.286928+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal for Lightning-oriented multiaccount multisig HD wallets Simone Bronzini + 2017-08-29T10:19:00.000Z + + + Luke Dashjr + 2017-08-29T20:07:00.000Z + + + Thomas Voegtlin + 2017-08-30T10:07:00.000Z + + + Simone Bronzini + 2017-08-30T12:22:00.000Z + + + Simone Bronzini + 2017-08-30T12:48:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal for Lightning-oriented multiaccount multisig HD wallets - 2023-08-01T21:32:08.647487+00:00 + 2025-09-26T15:59:02.287658+00:00 - In an email sent to the bitcoin-dev mailing list, Simone Bronzini discussed the issue of mixing SegWit and non-SegWit addresses on the same BIP44 structure. This mixture could cause problems with the recognition of unspent transaction outputs (UTXOs) by old wallets. As a solution, Bronzini proposed the Bitcoin Improvement Proposal (BIP) 49, which suggested separating the key space for SegWit addresses to avoid this issue. However, it was pointed out that this separation would lead to old UTXOs not being recognized by new wallets as they discard support for old standards over time.To address this problem, the suggestion was made to move away from bip39 and bip43 and include a version number in the mnemonic seed. The idea of versioning on mnemonic seeds was considered useful and recommended to be discussed separately.Bronzini also proposed a new structure to facilitate the management of different multisig accounts under the same master key. This proposal aims to improve multi-account management, particularly for handling multiple payment channels now that Lightning Network (LN) is becoming a reality. The draft of the BIP can be found on GitHub, and feedback is highly appreciated, especially regarding issues such as the coin_type level and SegWit addresses.Regarding the coin_type level, objections have been raised about the proposal's consideration of alt-coins since it is a Bitcoin Improvement Proposal. However, having a coin_type level improves interoperability with multi-currency wallets without major drawbacks. Additionally, even a Bitcoin maximalist may hold multiple coins for various reasons, such as short-term speculation or testing.Furthermore, the proposal addresses the concern of mixing SegWit and non-SegWit addresses on the same BIP44 structure, which could result in UTXOs not being completely recognized by old wallets. Two possible solutions were suggested: creating separate purposes for SegWit and non-SegWit addresses or introducing a new level in the proposed structure to divide SegWit and non-SegWit addresses. The latter solution would allow for a multisig wallet with non-SegWit-aware cosigners without the need for two different subtrees.The proposal is still a work in progress, and feedback is needed before it can be submitted as a BIP draft. Simone Bronzini is the author of the email and welcomes input from the community. 2017-08-30T12:48:24+00:00 + In an email sent to the bitcoin-dev mailing list, Simone Bronzini discussed the issue of mixing SegWit and non-SegWit addresses on the same BIP44 structure. This mixture could cause problems with the recognition of unspent transaction outputs (UTXOs) by old wallets. As a solution, Bronzini proposed the Bitcoin Improvement Proposal (BIP) 49, which suggested separating the key space for SegWit addresses to avoid this issue. However, it was pointed out that this separation would lead to old UTXOs not being recognized by new wallets as they discard support for old standards over time.To address this problem, the suggestion was made to move away from bip39 and bip43 and include a version number in the mnemonic seed. The idea of versioning on mnemonic seeds was considered useful and recommended to be discussed separately.Bronzini also proposed a new structure to facilitate the management of different multisig accounts under the same master key. This proposal aims to improve multi-account management, particularly for handling multiple payment channels now that Lightning Network (LN) is becoming a reality. The draft of the BIP can be found on GitHub, and feedback is highly appreciated, especially regarding issues such as the coin_type level and SegWit addresses.Regarding the coin_type level, objections have been raised about the proposal's consideration of alt-coins since it is a Bitcoin Improvement Proposal. However, having a coin_type level improves interoperability with multi-currency wallets without major drawbacks. Additionally, even a Bitcoin maximalist may hold multiple coins for various reasons, such as short-term speculation or testing.Furthermore, the proposal addresses the concern of mixing SegWit and non-SegWit addresses on the same BIP44 structure, which could result in UTXOs not being completely recognized by old wallets. Two possible solutions were suggested: creating separate purposes for SegWit and non-SegWit addresses or introducing a new level in the proposed structure to divide SegWit and non-SegWit addresses. The latter solution would allow for a multisig wallet with non-SegWit-aware cosigners without the need for two different subtrees.The proposal is still a work in progress, and feedback is needed before it can be submitted as a BIP draft. Simone Bronzini is the author of the email and welcomes input from the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_BIP49-Derivation-scheme-changes.xml b/static/bitcoin-dev/Aug_2017/combined_BIP49-Derivation-scheme-changes.xml index 849e4eb388..1baa332e8d 100644 --- a/static/bitcoin-dev/Aug_2017/combined_BIP49-Derivation-scheme-changes.xml +++ b/static/bitcoin-dev/Aug_2017/combined_BIP49-Derivation-scheme-changes.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - BIP49 Derivation scheme changes - 2023-08-01T21:42:39.503945+00:00 - - Dan Libby 2017-09-06 07:19:31+00:00 - - - shiva sitamraju 2017-09-06 05:20:31+00:00 - - - Thomas Voegtlin 2017-09-05 16:33:00+00:00 - - - Pavol Rusnak 2017-09-05 15:41:37+00:00 - - - shiva sitamraju 2017-09-05 07:10:15+00:00 - - - Thomas Voegtlin 2017-09-03 05:19:12+00:00 - - - shiva sitamraju 2017-08-30 07:24:13+00:00 - + 2025-09-26T15:59:00.171071+00:00 + python-feedgen + + + [bitcoin-dev] BIP49 Derivation scheme changes shiva sitamraju + 2017-08-30T07:24:00.000Z + + + Thomas Voegtlin + 2017-09-03T05:19:00.000Z + + + shiva sitamraju + 2017-09-05T07:10:00.000Z + + + Pavol Rusnak + 2017-09-05T15:41:00.000Z + + + Thomas Voegtlin + 2017-09-05T16:33:00.000Z + + + shiva sitamraju + 2017-09-06T05:20:00.000Z + + + Dan Libby + 2017-09-06T07:19:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - BIP49 Derivation scheme changes - 2023-08-01T21:42:39.503945+00:00 + 2025-09-26T15:59:00.171993+00:00 - In a discussion on the bitcoin-dev mailing list, the topic of recovering a wallet using seed words was brought up. It was noted that there is no distinction between seed words for segwit and non-segwit wallets, leading to the discovery of both m/44' and m/49' accounts. However, constantly monitoring both accounts for transactions was considered an undesirable solution. The conversation also touched on the issue of XPUB Derivation, which has not been addressed in the BIP yet. The inability to differentiate between xpub from m/44' or m/49' was identified as problematic, affecting functionalities such as importing xpub as a watch-only wallet and displaying balance/generating merchant addresses. The author of tools hd-wallet-addrs and hd-wallet-derive expressed agreement and suggested finding a way for xpub/xprv to encode their absolute path in the wallet for easier reading by tools. Another email exchange on the bitcoin-dev mailing list involved a user asking Thomas Voegtlin about the need for a different version for P2WPKH nested in BIP16 P2SH compared to P2WPKH. The user questioned if both would generate the same Bitcoin address in txout and be part of the same wallet account. Pavol Rusnak responded, expressing support for both proposals and urging the group to reach a decision soon. The discussion then moved on to proposed changes to the BIP32 serialization format, with Thomas suggesting the use of letters z, y, and z combined with pub/prv to indicate three types of keys, while Luke Dashjr favored utilizing a child number field. In a separate thread, Chris Stewart raised concerns about sidechain headers on mainchain and potential issues with invalid transactions impacting the consensus valid chain constructed by sidechain miners. He recommended incentivizing miners to collaborate by extending the coinbase maturity period on the sidechain beyond 288. Thomas later shared his own proposal for three different versions of P2WPKH nested in BIP16 P2SH for testnet and mainnet.On September 5th, 2017, Shiva Sitamraju expressed gratitude on the Bitcoin development mailing list for a procedure outlined in Electrum's documentation related to seed phrases. They questioned the value of following BIP49 and suggested proposing an alternative structure similar to Electrum. Changes to the BIP32 serialization format were proposed to differentiate segwit xpub/xprv, with new version bytes resulting in base58 prefixes and network types. The use of letters z, y, and z combined with pub/prv for three types of keys was suggested due to the existence of native and nested segwit output scripts. Testnet could utilize t, u, and v as prefixes. Shiva Sitamraju also shared four keys related to segwit mainnet and testnet.In a bitcoin-dev mailing list thread discussing scaling solutions and fee reduction, various proposals were put forward. Cserveny Tamas suggested splitting the chain, Thomas Guyot-Sionnest argued for reducing complexity without compromising security if confirmation is adjusted accordingly, and Tom Zander believed that the limit of blockchain is determined by technology and will continue to evolve. Timestamping in Bitcoin was brought up, highlighting its vulnerability to malicious miners due to the lack of a financial feedback loop. Concerns were raised about using compact SPV proofs for timestamping in OpenTimestamps, citing potential security issues and the need for further analysis.The discussion concluded with the acknowledgment that Segwit wallet seed words have a distinct format incompatible with previous wallet seed words. It was noted that Electrum has already addressed this issue by defining a structure for Segwit wallet seed words in their documentation. The writer of the message proposed breaking backwards compatibility in BIP49 due to issues with recovering wallets using seed words. They suggested creating new segwit m/49' wallets by default, with the option to choose non-segwit from advanced options. The format of segwit wallet seed words would encode the information that the wallet is segwit. Another concern raised was the lack of differentiation between xpub from m/44' and m/49', affecting functionalities like importing xpub as a watch-only wallet and displaying balance/generating merchant addresses. The writer invited thoughts on these suggestions. 2017-09-06T07:19:31+00:00 + In a discussion on the bitcoin-dev mailing list, the topic of recovering a wallet using seed words was brought up. It was noted that there is no distinction between seed words for segwit and non-segwit wallets, leading to the discovery of both m/44' and m/49' accounts. However, constantly monitoring both accounts for transactions was considered an undesirable solution. The conversation also touched on the issue of XPUB Derivation, which has not been addressed in the BIP yet. The inability to differentiate between xpub from m/44' or m/49' was identified as problematic, affecting functionalities such as importing xpub as a watch-only wallet and displaying balance/generating merchant addresses. The author of tools hd-wallet-addrs and hd-wallet-derive expressed agreement and suggested finding a way for xpub/xprv to encode their absolute path in the wallet for easier reading by tools. Another email exchange on the bitcoin-dev mailing list involved a user asking Thomas Voegtlin about the need for a different version for P2WPKH nested in BIP16 P2SH compared to P2WPKH. The user questioned if both would generate the same Bitcoin address in txout and be part of the same wallet account. Pavol Rusnak responded, expressing support for both proposals and urging the group to reach a decision soon. The discussion then moved on to proposed changes to the BIP32 serialization format, with Thomas suggesting the use of letters z, y, and z combined with pub/prv to indicate three types of keys, while Luke Dashjr favored utilizing a child number field. In a separate thread, Chris Stewart raised concerns about sidechain headers on mainchain and potential issues with invalid transactions impacting the consensus valid chain constructed by sidechain miners. He recommended incentivizing miners to collaborate by extending the coinbase maturity period on the sidechain beyond 288. Thomas later shared his own proposal for three different versions of P2WPKH nested in BIP16 P2SH for testnet and mainnet.On September 5th, 2017, Shiva Sitamraju expressed gratitude on the Bitcoin development mailing list for a procedure outlined in Electrum's documentation related to seed phrases. They questioned the value of following BIP49 and suggested proposing an alternative structure similar to Electrum. Changes to the BIP32 serialization format were proposed to differentiate segwit xpub/xprv, with new version bytes resulting in base58 prefixes and network types. The use of letters z, y, and z combined with pub/prv for three types of keys was suggested due to the existence of native and nested segwit output scripts. Testnet could utilize t, u, and v as prefixes. Shiva Sitamraju also shared four keys related to segwit mainnet and testnet.In a bitcoin-dev mailing list thread discussing scaling solutions and fee reduction, various proposals were put forward. Cserveny Tamas suggested splitting the chain, Thomas Guyot-Sionnest argued for reducing complexity without compromising security if confirmation is adjusted accordingly, and Tom Zander believed that the limit of blockchain is determined by technology and will continue to evolve. Timestamping in Bitcoin was brought up, highlighting its vulnerability to malicious miners due to the lack of a financial feedback loop. Concerns were raised about using compact SPV proofs for timestamping in OpenTimestamps, citing potential security issues and the need for further analysis.The discussion concluded with the acknowledgment that Segwit wallet seed words have a distinct format incompatible with previous wallet seed words. It was noted that Electrum has already addressed this issue by defining a structure for Segwit wallet seed words in their documentation. The writer of the message proposed breaking backwards compatibility in BIP49 due to issues with recovering wallets using seed words. They suggested creating new segwit m/49' wallets by default, with the option to choose non-segwit from advanced options. The format of segwit wallet seed words would encode the information that the wallet is segwit. Another concern raised was the lack of differentiation between xpub from m/44' and m/49', affecting functionalities like importing xpub as a watch-only wallet and displaying balance/generating merchant addresses. The writer invited thoughts on these suggestions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_Fwd-Compressed-headers-stream.xml b/static/bitcoin-dev/Aug_2017/combined_Fwd-Compressed-headers-stream.xml index 0c5eb32d2f..193235c4f7 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Fwd-Compressed-headers-stream.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Fwd-Compressed-headers-stream.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Fwd: "Compressed" headers stream - 2023-08-01T21:31:35.396695+00:00 + Combined summary - Fwd: "Compressed" headers stream + 2025-09-26T15:58:51.666527+00:00 + python-feedgen Peter Todd 2017-09-04 14:06:44+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 - Combined summary - Fwd: "Compressed" headers stream - 2023-08-01T21:31:35.396695+00:00 + Combined summary - Fwd: "Compressed" headers stream + 2025-09-26T15:58:51.666709+00:00 - In a discussion on the bitcoin-dev mailing list, Gregory Maxwell highlighted various methods to reduce the number of bytes required for block headers. These techniques involve minimizing changes to the bits field, setting the timestamp to be slightly higher than the previous one, and recognizing that the block version is typically one of the last few. However, these improvements offer only a constant factor reduction in size.The compact SPV proofs, outlined in the appendix of the sidechains whitepaper, introduce logarithmic scaling proofs but solely validate total work, not validity. OpenTimestamps aims to establish a framework for trusted validity attestations, as timestamping via proof-of-work presents security concerns due to the potential manipulation of block times by miners. It is crucial to comprehend the associated risks before implementing compact SPV proofs. Additionally, there may be an opportunity to enhance initial download bandwidth by including a known-good sum-merkle-tree tip hash with the software.Riccardo Casatta expressed his belief in an email to bitcoin-dev that Bitcoin headers represent the most vital data globally, with an anticipated increase in demand. He proposed optimizing transmitted data when sending a continuous stream of block headers by eliminating the transmission of previous hashes after the first header. The receiver can calculate the previous hash by double hashing the previous header, which is necessary for verifying the proof of work. This approach could potentially save approximately 40% in bandwidth when transmitting a lengthy sequence of block headers.However, another participant in the discussion countered this suggestion by mentioning alternative ways to reduce bytes in the block headers field, such as avoiding changes to the bits field every 2016 blocks or only including the timestamp if it surpasses the median of the last 11 blocks. These optimizations also provide only a constant factor reduction in size. The contributor recommended exploring the compact SPV proofs described in the appendix of the sidechains whitepaper for logarithmic scaling proofs. 2017-09-04T14:06:44+00:00 + In a discussion on the bitcoin-dev mailing list, Gregory Maxwell highlighted various methods to reduce the number of bytes required for block headers. These techniques involve minimizing changes to the bits field, setting the timestamp to be slightly higher than the previous one, and recognizing that the block version is typically one of the last few. However, these improvements offer only a constant factor reduction in size.The compact SPV proofs, outlined in the appendix of the sidechains whitepaper, introduce logarithmic scaling proofs but solely validate total work, not validity. OpenTimestamps aims to establish a framework for trusted validity attestations, as timestamping via proof-of-work presents security concerns due to the potential manipulation of block times by miners. It is crucial to comprehend the associated risks before implementing compact SPV proofs. Additionally, there may be an opportunity to enhance initial download bandwidth by including a known-good sum-merkle-tree tip hash with the software.Riccardo Casatta expressed his belief in an email to bitcoin-dev that Bitcoin headers represent the most vital data globally, with an anticipated increase in demand. He proposed optimizing transmitted data when sending a continuous stream of block headers by eliminating the transmission of previous hashes after the first header. The receiver can calculate the previous hash by double hashing the previous header, which is necessary for verifying the proof of work. This approach could potentially save approximately 40% in bandwidth when transmitting a lengthy sequence of block headers.However, another participant in the discussion countered this suggestion by mentioning alternative ways to reduce bytes in the block headers field, such as avoiding changes to the bits field every 2016 blocks or only including the timestamp if it surpasses the median of the last 11 blocks. These optimizations also provide only a constant factor reduction in size. The contributor recommended exploring the compact SPV proofs described in the appendix of the sidechains whitepaper for logarithmic scaling proofs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_Fwd-Lightning-in-the-setting-of-blockchain-hardforks.xml b/static/bitcoin-dev/Aug_2017/combined_Fwd-Lightning-in-the-setting-of-blockchain-hardforks.xml index 2eb7dba85c..0136450cce 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Fwd-Lightning-in-the-setting-of-blockchain-hardforks.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Fwd-Lightning-in-the-setting-of-blockchain-hardforks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Lightning in the setting of blockchain hardforks - 2023-08-01T21:28:01.255982+00:00 + 2025-09-26T15:59:04.457577+00:00 + python-feedgen Natanael 2017-08-17 13:38:26+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Fwd: Lightning in the setting of blockchain hardforks - 2023-08-01T21:28:01.255982+00:00 + 2025-09-26T15:59:04.457728+00:00 - The conversation among Bitcoin developers revolves around the issue of payment channels during hardforks. Payment channels are not a concern for hardforks like Bitcoin ABC without a malleability fix. However, in the case of a hardfork with a malleability fix, replay protection is needed to prevent problems. One possible solution is to timestamp commitments and integrate them into the channel design. By accepting only old commitments for a certain period of time, this replay protection can be reused for future hardforks. However, hardforking while having open channels presents challenges. Open channels require monitoring the blockchain, and those unaware of the hardfork or late in updating their client could have their funds stolen through old commitment transactions. The risk of retaliation is relatively low for attackers, as others can likely determine the client version. If no replay protection is implemented on the fork, open channels will need to be settled twice. If replay protection is implemented, commitments become invalid on the fork, resulting in financial losses for users.The discussion on Lightning in the context of blockchain hardforks began in an email thread between Christian Decker and Martin Schwarz. They addressed the issue of open channels during a fork, noting that if no replay protection is implemented, the last commitment can be used to close the channel. However, if replay protection is in place, commitments become invalid on the fork, leading to potential financial losses. To solve this problem, the suggestion was made to redefine chain_id as the hash of the first block of the new branch and require replay and wipe-out protection. The question of whether these requirements can be relaxed and concerns about slow block times were also raised. It was proposed that timestamping of commitments could be integrated into the channel design to address replay protection. It was acknowledged that hardforking with open channels will always be problematic, and those unaware of or late to update their client risk losing their funds.Christian Decker welcomes Martin Schwarz to the Lightning-dev mailing list and agrees with his proposal of using the first forked block as the genesis block for the forkchain to minimize disruption. In cases where channels are open during the fork, a single channel would need to be settled twice. If no replay protection is implemented, the last commitment can be used to close the channel. However, if replay protection is in place, commitments become invalid on the fork, potentially resulting in financial losses. Martin Schwarz raises the question of how Lightning can function across distinct permanent forks of a parent blockchain that share the same genesis block with hardforks branching off the Bitcoin blockchain. He suggests redefining chain_id to the hash of the first block of the new branch and requiring replay and wipe-out protection. The discussion also touches on concerns about slow block times and whether Lightning can transact on "almost frozen" block chains that experience a sudden loss of hash power. Additionally, the participants inquire about previous discussions or studies on Lightning in the context of hardforks. Bryan's contact information is provided at the end of the email thread. 2017-08-17T13:38:26+00:00 + The conversation among Bitcoin developers revolves around the issue of payment channels during hardforks. Payment channels are not a concern for hardforks like Bitcoin ABC without a malleability fix. However, in the case of a hardfork with a malleability fix, replay protection is needed to prevent problems. One possible solution is to timestamp commitments and integrate them into the channel design. By accepting only old commitments for a certain period of time, this replay protection can be reused for future hardforks. However, hardforking while having open channels presents challenges. Open channels require monitoring the blockchain, and those unaware of the hardfork or late in updating their client could have their funds stolen through old commitment transactions. The risk of retaliation is relatively low for attackers, as others can likely determine the client version. If no replay protection is implemented on the fork, open channels will need to be settled twice. If replay protection is implemented, commitments become invalid on the fork, resulting in financial losses for users.The discussion on Lightning in the context of blockchain hardforks began in an email thread between Christian Decker and Martin Schwarz. They addressed the issue of open channels during a fork, noting that if no replay protection is implemented, the last commitment can be used to close the channel. However, if replay protection is in place, commitments become invalid on the fork, leading to potential financial losses. To solve this problem, the suggestion was made to redefine chain_id as the hash of the first block of the new branch and require replay and wipe-out protection. The question of whether these requirements can be relaxed and concerns about slow block times were also raised. It was proposed that timestamping of commitments could be integrated into the channel design to address replay protection. It was acknowledged that hardforking with open channels will always be problematic, and those unaware of or late to update their client risk losing their funds.Christian Decker welcomes Martin Schwarz to the Lightning-dev mailing list and agrees with his proposal of using the first forked block as the genesis block for the forkchain to minimize disruption. In cases where channels are open during the fork, a single channel would need to be settled twice. If no replay protection is implemented, the last commitment can be used to close the channel. However, if replay protection is in place, commitments become invalid on the fork, potentially resulting in financial losses. Martin Schwarz raises the question of how Lightning can function across distinct permanent forks of a parent blockchain that share the same genesis block with hardforks branching off the Bitcoin blockchain. He suggests redefining chain_id to the hash of the first block of the new branch and requiring replay and wipe-out protection. The discussion also touches on concerns about slow block times and whether Lightning can transact on "almost frozen" block chains that experience a sudden loss of hash power. Additionally, the participants inquire about previous discussions or studies on Lightning in the context of hardforks. Bryan's contact information is provided at the end of the email thread. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_Fwd-Proposal-of-a-new-BIP-annual-splitting-blockchain-database-to-reduce-its-size-.xml b/static/bitcoin-dev/Aug_2017/combined_Fwd-Proposal-of-a-new-BIP-annual-splitting-blockchain-database-to-reduce-its-size-.xml index 71cf6b032e..24a8e4d549 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Fwd-Proposal-of-a-new-BIP-annual-splitting-blockchain-database-to-reduce-its-size-.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Fwd-Proposal-of-a-new-BIP-annual-splitting-blockchain-database-to-reduce-its-size-.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Fwd: Proposal of a new BIP : annual splitting blockchain database to reduce its size. - 2023-08-01T21:27:36.188295+00:00 - - Luke Dashjr 2017-08-16 18:33:47+00:00 - - - Алексей Мутовкин 2017-08-16 17:37:34+00:00 - - - Nick ODell 2017-08-16 16:52:01+00:00 - - - Алексей Мутовкин 2017-08-16 16:20:45+00:00 - + 2025-09-26T15:58:58.053043+00:00 + python-feedgen + + + [bitcoin-dev] Fwd: Proposal of a new BIP : annual splitting blockchain database to reduce its size Алексей Мутовкин + 2017-08-16T16:20:00.000Z + + + Nick ODell + 2017-08-16T16:52:00.000Z + + + Алексей Мутовкин + 2017-08-16T17:37:00.000Z + + + Luke Dashjr + 2017-08-16T18:33:00.000Z + + - python-feedgen + 2 Combined summary - Fwd: Proposal of a new BIP : annual splitting blockchain database to reduce its size. - 2023-08-01T21:27:36.188295+00:00 + 2025-09-26T15:58:58.053738+00:00 - The proposal, introduced by Алексей Мутовкин via bitcoin-dev, suggests splitting the Bitcoin blockchain database (BBD) annually to address the inconvenience of a 140gb full wallet. Under this proposed routine, the BBD will be divided into two parts: old blocks before the split date and new blocks starting from the first technical block with all rolled totals on the split date.To further enhance efficiency, tiny totals that are not profitable may be transferred to miners or deleted altogether, aiming to cut the long tail of tiny holders. Additionally, the old blocks will be consolidated into annual megablocks and stored in the side archive chain. This storage system will serve future purposes such as FBI investigations or other goals.This concept, historically referred to as "flip the chain" and/or "UTXO commitments," is not entirely new but requires intricate design and implementation. The proposed approach offers an alternative to pruning, which involves deleting old transactions to reduce the blockchain size. While the prune option saves disk space, the initial synchronization still necessitates downloading the complete database. Therefore, the annual split provides a more convenient solution for users, allowing most nodes to hold only the rolled database while fewer archive nodes maintain a full expanded database. By implementing this routine, the goal is to improve the overall user experience and alleviate the burden of managing a large wallet. 2017-08-16T18:33:47+00:00 + The proposal, introduced by Алексей Мутовкин via bitcoin-dev, suggests splitting the Bitcoin blockchain database (BBD) annually to address the inconvenience of a 140gb full wallet. Under this proposed routine, the BBD will be divided into two parts: old blocks before the split date and new blocks starting from the first technical block with all rolled totals on the split date.To further enhance efficiency, tiny totals that are not profitable may be transferred to miners or deleted altogether, aiming to cut the long tail of tiny holders. Additionally, the old blocks will be consolidated into annual megablocks and stored in the side archive chain. This storage system will serve future purposes such as FBI investigations or other goals.This concept, historically referred to as "flip the chain" and/or "UTXO commitments," is not entirely new but requires intricate design and implementation. The proposed approach offers an alternative to pruning, which involves deleting old transactions to reduce the blockchain size. While the prune option saves disk space, the initial synchronization still necessitates downloading the complete database. Therefore, the annual split provides a more convenient solution for users, allowing most nodes to hold only the rolled database while fewer archive nodes maintain a full expanded database. By implementing this routine, the goal is to improve the overall user experience and alleviate the burden of managing a large wallet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_P2WPKH-Scripts-P2PKH-Addresses-and-Uncompressed-Public-Keys.xml b/static/bitcoin-dev/Aug_2017/combined_P2WPKH-Scripts-P2PKH-Addresses-and-Uncompressed-Public-Keys.xml index 85f1f369cf..c137e2cb13 100644 --- a/static/bitcoin-dev/Aug_2017/combined_P2WPKH-Scripts-P2PKH-Addresses-and-Uncompressed-Public-Keys.xml +++ b/static/bitcoin-dev/Aug_2017/combined_P2WPKH-Scripts-P2PKH-Addresses-and-Uncompressed-Public-Keys.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys - 2023-08-01T21:29:19.658245+00:00 - - Peter Todd 2017-09-04 13:51:35+00:00 - - - Johnson Lau 2017-08-29 03:30:07+00:00 - - - Mark Friedenbach 2017-08-28 21:33:52+00:00 - - - Alex Nagy 2017-08-28 20:55:47+00:00 - - - Alex Nagy 2017-08-28 15:29:31+00:00 - + 2025-09-26T15:58:41.030185+00:00 + python-feedgen + + + [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys Alex Nagy + 2017-08-28T15:29:00.000Z + + + [bitcoin-dev] Fwd: " Gregory Maxwell + 2017-08-28T17:06:00.000Z + + + [bitcoin-dev] " Alex Nagy + 2017-08-28T20:55:00.000Z + + + Mark Friedenbach + 2017-08-28T21:33:00.000Z + + + Johnson Lau + 2017-08-29T03:30:00.000Z + + + Peter Todd + 2017-09-04T13:51:00.000Z + + - python-feedgen + 2 Combined summary - P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys - 2023-08-01T21:29:19.658245+00:00 + 2025-09-26T15:58:41.031132+00:00 - In a recent discussion on the bitcoin-dev mailing list, there was a question raised about whether native P2WPKH scripts should only be used in redeem scripts or if they could also be encoded in TxOuts. The purpose of this would be to save space in transactions with multiple outputs. Gregory Maxwell responded by saying that native P2WPKH and P2WSH are indeed valid and identifiable even when encoded in TxOuts. However, he cautioned against assuming that the recipient understands this new format. If someone wants to utilize this method to save space, they should first request a new BIP173 address from the recipient instead of converting a P2PKH address without consent.Another topic that came up in the Bitcoin-dev forum discussion was whether Bob can safely issue native P2WPKH outputs to Alice if she provides him with a specific address. The answer to this question is no, and it does not matter whether the address is compressed or uncompressed. If Alice provides Bob with a specific address, she is essentially stating that she will only accept payment to the scriptPubKey associated with that address. Any payment made to a different scriptPubKey may not be recognized by Alice.In an email exchange between Alex Nagy and Gregory Maxwell, the question was posed about whether Bob can issue native P2WPKH outputs to Alice if she gives him the address 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a. Gregory's response was that it is not possible to pay someone to a script pubkey that they have not specified. Attempting to construct an alternative script pubkey would be akin to burying a check in a locked safe labeled "danger radioactive" in someone's backyard. While there have been instances where wallets displayed outputs they didn't generate but could spend, these cases are considered flaws and cannot be relied upon for all situations. Furthermore, if uncompressed keys are used, it could render the payment unspendable.The context also mentions that Alice has a P2PKH address derived from an uncompressed public key. However, BIPs 141 and 143 state that P2WPKH scripts can only be derived from compressed public keys. Due to this restriction, if Alice were to provide Bob with her P2PKH address, he would not be able to safely issue native P2WPKH outputs to her because he would have no way of knowing whether her P2PKH address represents a compressed or uncompressed public key. The existing P2PKH address format is generally considered unsafe to use with SegWit since it allows for addresses derived from uncompressed public keys. Transactions that violate the rule of using compressed public keys in P2WPKH and P2WSH will not be relayed or mined by default, as stated in BIP143. To avoid potential loss of funds in the future, users should refrain from using uncompressed keys in version 0 witness programs. 2017-09-04T13:51:35+00:00 + In a recent discussion on the bitcoin-dev mailing list, there was a question raised about whether native P2WPKH scripts should only be used in redeem scripts or if they could also be encoded in TxOuts. The purpose of this would be to save space in transactions with multiple outputs. Gregory Maxwell responded by saying that native P2WPKH and P2WSH are indeed valid and identifiable even when encoded in TxOuts. However, he cautioned against assuming that the recipient understands this new format. If someone wants to utilize this method to save space, they should first request a new BIP173 address from the recipient instead of converting a P2PKH address without consent.Another topic that came up in the Bitcoin-dev forum discussion was whether Bob can safely issue native P2WPKH outputs to Alice if she provides him with a specific address. The answer to this question is no, and it does not matter whether the address is compressed or uncompressed. If Alice provides Bob with a specific address, she is essentially stating that she will only accept payment to the scriptPubKey associated with that address. Any payment made to a different scriptPubKey may not be recognized by Alice.In an email exchange between Alex Nagy and Gregory Maxwell, the question was posed about whether Bob can issue native P2WPKH outputs to Alice if she gives him the address 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a. Gregory's response was that it is not possible to pay someone to a script pubkey that they have not specified. Attempting to construct an alternative script pubkey would be akin to burying a check in a locked safe labeled "danger radioactive" in someone's backyard. While there have been instances where wallets displayed outputs they didn't generate but could spend, these cases are considered flaws and cannot be relied upon for all situations. Furthermore, if uncompressed keys are used, it could render the payment unspendable.The context also mentions that Alice has a P2PKH address derived from an uncompressed public key. However, BIPs 141 and 143 state that P2WPKH scripts can only be derived from compressed public keys. Due to this restriction, if Alice were to provide Bob with her P2PKH address, he would not be able to safely issue native P2WPKH outputs to her because he would have no way of knowing whether her P2PKH address represents a compressed or uncompressed public key. The existing P2PKH address format is generally considered unsafe to use with SegWit since it allows for addresses derived from uncompressed public keys. Transactions that violate the rule of using compressed public keys in P2WPKH and P2WSH will not be relayed or mined by default, as stated in BIP143. To avoid potential loss of funds in the future, users should refrain from using uncompressed keys in version 0 witness programs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-Part-II-Adam-Shem-Tov.xml b/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-Part-II-Adam-Shem-Tov.xml index ff16ca1cc1..e72162e56a 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-Part-II-Adam-Shem-Tov.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-Part-II-Adam-Shem-Tov.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Solving the Scalability Problem Part II - Adam Shem-Tov - 2023-08-01T21:28:57.729455+00:00 - - Jorge Timón 2017-08-27 11:33:04+00:00 - - - Adam Tamir Shem-Tov 2017-08-26 22:26:15+00:00 - - - Christian Riley 2017-08-26 21:42:16+00:00 - - - Thomas Guyot-Sionnest 2017-08-26 21:41:34+00:00 - - - Adam Tamir Shem-Tov 2017-08-26 21:01:56+00:00 - + 2025-09-26T15:58:47.401257+00:00 + python-feedgen + + + [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov Adam Tamir Shem-Tov + 2017-08-26T21:01:00.000Z + + + Thomas Guyot-Sionnest + 2017-08-26T21:41:00.000Z + + + Christian Riley + 2017-08-26T21:42:00.000Z + + + Adam Tamir Shem-Tov + 2017-08-26T22:26:00.000Z + + + Jorge Timón + 2017-08-27T11:33:00.000Z + + - python-feedgen + 2 Combined summary - Solving the Scalability Problem Part II - Adam Shem-Tov - 2023-08-01T21:28:57.729455+00:00 + 2025-09-26T15:58:47.402039+00:00 - Adam Tamir Shem-Tov proposed a solution to the scalability problem in Bitcoin by minimizing blocks on the blockchain without losing relevant information. This involves rewriting the transaction chain and creating a special account called the "Genesis Account." The Genesis Account's private and public keys would be available to everyone but would not be able to send or receive funds in a normal block. It would only be used in the pruning block or Exodus Block, where all funds must be legitimate and sent from a verified account. The funds in the Exodus Block would appear as though they originated from the Genesis Account and the account would also receive the mining bonus by pretending to mine all coins in the Exodus Block. This proposal aims to address the storage space issue before it becomes too expensive for private citizens to afford, potentially compromising the decentralization of Bitcoin. 2017-08-27T11:33:04+00:00 + Adam Tamir Shem-Tov proposed a solution to the scalability problem in Bitcoin by minimizing blocks on the blockchain without losing relevant information. This involves rewriting the transaction chain and creating a special account called the "Genesis Account." The Genesis Account's private and public keys would be available to everyone but would not be able to send or receive funds in a normal block. It would only be used in the pruning block or Exodus Block, where all funds must be legitimate and sent from a verified account. The funds in the Exodus Block would appear as though they originated from the Genesis Account and the account would also receive the mining bonus by pretending to mine all coins in the Exodus Block. This proposal aims to address the storage space issue before it becomes too expensive for private citizens to afford, potentially compromising the decentralization of Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-on-Bitcoin.xml b/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-on-Bitcoin.xml index 1558ef04d8..f08ee71901 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-on-Bitcoin.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-on-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Solving the Scalability Problem on Bitcoin - 2023-08-01T21:28:49.981793+00:00 + 2025-09-26T15:58:45.290634+00:00 + python-feedgen Matthew Beton 2017-08-27 13:19:25+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Solving the Scalability Problem on Bitcoin - 2023-08-01T21:28:49.981793+00:00 + 2025-09-26T15:58:45.290803+00:00 - There is a potential issue with pruning in Bitcoin, as some wallets do not fully empty when instructed to send all funds. This could lead to difficulties in pruning, as wallets with any coins left cannot be pruned. To address this, users need to be encouraged to send everything instead of leaving a small fraction. The problem with node pruning is that it is not standardized, and new nodes need to download and prune all data themselves. The blockchain size is increasing exponentially and could reach a terabyte soon. Adam Tamir Shem-Tov proposes the concept of "trusted" nodes to solve this scalability problem. However, Thomas Guyot-Sionnest argues that implementing this solution is impossible without keeping all blocks until a hard-coded checkpoint. Shem-Tov suggests combining and pruning the blockchain every 999 blocks to one block, leaving only the genesis block. The network would wait for a special "pruned block" before accepting new blocks, and the ledger would always be a maximum of 1000 blocks.In response to a query about shortening transactions in Bitcoin, changes to the hash reference system, UTXO table, and reward mechanism are proposed. The author suggests blocks should refer to the hash of the balance sheet instead of the previous block's hash and that a new signature must be placed on the shortened transaction. However, there are issues with nLockTime and non-standard transactions. These changes would affect wallets, UTXO references, and the proof of work system.The email thread discusses a proposal to solve the scalability issue in Bitcoin by combining and pruning the blockchain every 999 blocks to one block. This would limit the ledger to a maximum of 1000 blocks. The size of the blockchain is currently around 140GB and growing rapidly. Node pruning is not standardized, making it difficult for new nodes to verify data. The proposal suggests adding a Genesis Account to remove intermediate origins and make funds untraceable. However, implementing this solution is deemed impossible due to the difficulty of determining the authenticity of the blockchain midway. Saving all necessary data every 1000 blocks does not guarantee dropping older blocks.The proposal to solve the scalability issue involves combining and pruning the blockchain every 999 blocks, leaving only the genesis block. The network would wait for a "pruned block" before accepting new blocks. However, implementing this is considered impossible due to authenticity and compatibility issues. The current implementation of node pruning keeps unspent inputs and recent blocks. Adam Tamir Shem-Tov suggests trusted nodes as a solution, but Thomas Guyot-Sionnest argues against it. The size of Bitcoin's data is currently around 140GB and could reach a terabyte soon, requiring action.The author suggests combining and pruning the blockchain every 999 blocks to one block to solve the scalability issue. This pruned block would contain a summed up transaction of all transactions in the previous 999 blocks and its hash pointer would reference the genesis block. Full nodes would verify the pruned block before accepting a new block. However, implementing this solution is considered impossible due to difficulties in determining the authenticity of the blockchain midway. Node pruning currently keeps unspent inputs and recent blocks, but there are also proposals to include UTXO in some blocks. The size of Bitcoin's data is growing exponentially and action needs to be taken. 2017-08-27T13:19:25+00:00 + There is a potential issue with pruning in Bitcoin, as some wallets do not fully empty when instructed to send all funds. This could lead to difficulties in pruning, as wallets with any coins left cannot be pruned. To address this, users need to be encouraged to send everything instead of leaving a small fraction. The problem with node pruning is that it is not standardized, and new nodes need to download and prune all data themselves. The blockchain size is increasing exponentially and could reach a terabyte soon. Adam Tamir Shem-Tov proposes the concept of "trusted" nodes to solve this scalability problem. However, Thomas Guyot-Sionnest argues that implementing this solution is impossible without keeping all blocks until a hard-coded checkpoint. Shem-Tov suggests combining and pruning the blockchain every 999 blocks to one block, leaving only the genesis block. The network would wait for a special "pruned block" before accepting new blocks, and the ledger would always be a maximum of 1000 blocks.In response to a query about shortening transactions in Bitcoin, changes to the hash reference system, UTXO table, and reward mechanism are proposed. The author suggests blocks should refer to the hash of the balance sheet instead of the previous block's hash and that a new signature must be placed on the shortened transaction. However, there are issues with nLockTime and non-standard transactions. These changes would affect wallets, UTXO references, and the proof of work system.The email thread discusses a proposal to solve the scalability issue in Bitcoin by combining and pruning the blockchain every 999 blocks to one block. This would limit the ledger to a maximum of 1000 blocks. The size of the blockchain is currently around 140GB and growing rapidly. Node pruning is not standardized, making it difficult for new nodes to verify data. The proposal suggests adding a Genesis Account to remove intermediate origins and make funds untraceable. However, implementing this solution is deemed impossible due to the difficulty of determining the authenticity of the blockchain midway. Saving all necessary data every 1000 blocks does not guarantee dropping older blocks.The proposal to solve the scalability issue involves combining and pruning the blockchain every 999 blocks, leaving only the genesis block. The network would wait for a "pruned block" before accepting new blocks. However, implementing this is considered impossible due to authenticity and compatibility issues. The current implementation of node pruning keeps unspent inputs and recent blocks. Adam Tamir Shem-Tov suggests trusted nodes as a solution, but Thomas Guyot-Sionnest argues against it. The size of Bitcoin's data is currently around 140GB and could reach a terabyte soon, requiring action.The author suggests combining and pruning the blockchain every 999 blocks to one block to solve the scalability issue. This pruned block would contain a summed up transaction of all transactions in the previous 999 blocks and its hash pointer would reference the genesis block. Full nodes would verify the pruned block before accepting a new block. However, implementing this solution is considered impossible due to difficulties in determining the authenticity of the blockchain midway. Node pruning currently keeps unspent inputs and recent blocks, but there are also proposals to include UTXO in some blocks. The size of Bitcoin's data is growing exponentially and action needs to be taken. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_Structure-for-Trustless-Hybrid-Bitcoin-Wallets-Using-P2SH-for-Recovery-Options.xml b/static/bitcoin-dev/Aug_2017/combined_Structure-for-Trustless-Hybrid-Bitcoin-Wallets-Using-P2SH-for-Recovery-Options.xml index 753db0363c..e2fb120ca6 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Structure-for-Trustless-Hybrid-Bitcoin-Wallets-Using-P2SH-for-Recovery-Options.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Structure-for-Trustless-Hybrid-Bitcoin-Wallets-Using-P2SH-for-Recovery-Options.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options - 2023-08-01T21:25:44.425124+00:00 - - Nick ODell 2017-08-09 20:14:18+00:00 - - - Jonas Schnelli 2017-08-09 19:35:26+00:00 - - - Colin Lacina 2017-08-09 18:49:59+00:00 - + 2025-09-26T15:58:38.914396+00:00 + python-feedgen + + + [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options Colin Lacina + 2017-08-09T18:49:00.000Z + + + Jonas Schnelli + 2017-08-09T19:35:00.000Z + + + Nick ODell + 2017-08-09T20:14:00.000Z + + - python-feedgen + 2 Combined summary - Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options - 2023-08-01T21:25:44.425124+00:00 + 2025-09-26T15:58:38.914976+00:00 - Colin has proposed a structure for trustless use of hybrid wallets, allowing for emergency recovery of funds in case of a lost wallet. The transaction script involves the user signing a transaction with their userWalletPrivKey and authenticating with the server, which then signs with their serverWalletPrivKey. If the server goes rogue and refuses to sign, the user can use their userRecoveryPrivKey to send the funds anywhere they choose. In case the user forgets their password and loses access to their userWalletPrivKey and recovery key, they can rely on the serverRecoveryPrivKey.During wallet setup, users provide basic identity information and set up a recovery password or answer recovery questions. None of this information is sent to the server except for the 256-bit hash used to identify the recovery wallet. The server creates a 1025-bit nonce, encrypts it, stores it, and transmits it to the user's client along with the server's recovery private key. The client uses SHA512 on the combination of identity questions and answers, recovery password (if used), recovery questions and answers, and the nonce. It encrypts the serverRecoveryPrivKey using the resulting hash, which is then encrypted again for transmission to the server.In the event that the user needs to resort to using the recovery option, they use their information to build their recovery identifier. The server may request e-mail and/or SMS confirmation before proceeding. The server decrypts the saved nonce and the first layer of encryption on the serverRecoveryPrivKey, then encrypts both for transmission to the user's client. The client removes the transmission encryption and calculates the 512-bit hash used to originally encrypt the serverRecoveryPrivKey. Finally, the user can decrypt the airbitzServerRecoveryPrivKey and use it to send a transaction to any chosen destination.Nick has provided feedback on Colin's proposal, suggesting that the key used to encrypt the nonce by the server should be included and questioning the effectiveness of the recovery questions asked. Nick also raises concerns about potential mitigations to prevent the server from stealing the wallet using a dictionary of common pet names.The userRecoveryPrivKey can be used to send funds if the server stops signing, and it is recommended to store it in cold wallet storage for security reasons. The userWalletPubKey, on the other hand, is a hot key stored on the user's computer, typically in a browser-based local storage container. If there is an attack on the serverWalletPubKey, which stores the user's personal information, including xpub, this increases the user's risk compared to cold or HWW keys.The proposed structure aims to allow trustless use of hybrid wallets without having to fully trust them. The TX script running this structure involves the use of "IF 1 2 CHECKMULTISIGVERIFY ELSE 2 2 CHECKMULTISIG ENDIF". In case of a lost wallet, recovery of funds can be done using the userRecoveryPrivKey. Authentication with the server can be done using two-factor authentication (2FA) methods like Authy or Google Authenticator. The author suggests that this structure could make a good informational BIP (Bitcoin Improvement Proposal). 2017-08-09T20:14:18+00:00 + Colin has proposed a structure for trustless use of hybrid wallets, allowing for emergency recovery of funds in case of a lost wallet. The transaction script involves the user signing a transaction with their userWalletPrivKey and authenticating with the server, which then signs with their serverWalletPrivKey. If the server goes rogue and refuses to sign, the user can use their userRecoveryPrivKey to send the funds anywhere they choose. In case the user forgets their password and loses access to their userWalletPrivKey and recovery key, they can rely on the serverRecoveryPrivKey.During wallet setup, users provide basic identity information and set up a recovery password or answer recovery questions. None of this information is sent to the server except for the 256-bit hash used to identify the recovery wallet. The server creates a 1025-bit nonce, encrypts it, stores it, and transmits it to the user's client along with the server's recovery private key. The client uses SHA512 on the combination of identity questions and answers, recovery password (if used), recovery questions and answers, and the nonce. It encrypts the serverRecoveryPrivKey using the resulting hash, which is then encrypted again for transmission to the server.In the event that the user needs to resort to using the recovery option, they use their information to build their recovery identifier. The server may request e-mail and/or SMS confirmation before proceeding. The server decrypts the saved nonce and the first layer of encryption on the serverRecoveryPrivKey, then encrypts both for transmission to the user's client. The client removes the transmission encryption and calculates the 512-bit hash used to originally encrypt the serverRecoveryPrivKey. Finally, the user can decrypt the airbitzServerRecoveryPrivKey and use it to send a transaction to any chosen destination.Nick has provided feedback on Colin's proposal, suggesting that the key used to encrypt the nonce by the server should be included and questioning the effectiveness of the recovery questions asked. Nick also raises concerns about potential mitigations to prevent the server from stealing the wallet using a dictionary of common pet names.The userRecoveryPrivKey can be used to send funds if the server stops signing, and it is recommended to store it in cold wallet storage for security reasons. The userWalletPubKey, on the other hand, is a hot key stored on the user's computer, typically in a browser-based local storage container. If there is an attack on the serverWalletPubKey, which stores the user's personal information, including xpub, this increases the user's risk compared to cold or HWW keys.The proposed structure aims to allow trustless use of hybrid wallets without having to fully trust them. The TX script running this structure involves the use of "IF 1 2 CHECKMULTISIGVERIFY ELSE 2 2 CHECKMULTISIG ENDIF". In case of a lost wallet, recovery of funds can be done using the userRecoveryPrivKey. Authentication with the server can be done using two-factor authentication (2FA) methods like Authy or Google Authenticator. The author suggests that this structure could make a good informational BIP (Bitcoin Improvement Proposal). - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_UTXO-growth-scaling-solution-proposal.xml b/static/bitcoin-dev/Aug_2017/combined_UTXO-growth-scaling-solution-proposal.xml index 0bfee4f7d5..ba24ae740d 100644 --- a/static/bitcoin-dev/Aug_2017/combined_UTXO-growth-scaling-solution-proposal.xml +++ b/static/bitcoin-dev/Aug_2017/combined_UTXO-growth-scaling-solution-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - UTXO growth scaling solution proposal - 2023-08-01T21:23:22.653747+00:00 + 2025-09-26T15:58:55.935161+00:00 + python-feedgen Mark Friedenbach 2017-08-23 03:26:19+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - UTXO growth scaling solution proposal - 2023-08-01T21:23:22.653747+00:00 + 2025-09-26T15:58:55.935345+00:00 - Bitcoin developers are engaged in discussions about implementing features that could change the operation of Bitcoin. One proposal suggests making coins "expire" after a certain period of time, while another proposes creating a "never expire" transaction output. The potential security risks and the need for transparency and warning are also emphasized. Additionally, there is debate about implementing free transactions based on old priority rules, with suggestions including requiring the inclusion of free transactions in each block or a two-step transaction with a fee to register a UTXO refresh. However, there is no consensus on how to implement these proposals without burdening consensus rules.The threat of quantum computing to Bitcoin's security is also discussed, with suggestions for new proof-of-work algorithms, address formats, and signing protocols. Removing stale coins to prevent hacking is proposed, but there are differing opinions on whether this aligns with the principles of Bitcoin. The conversation highlights the challenges of implementing significant changes to Bitcoin, touching on issues of transparency, security, taxation, and adapting to technological advancements.Bitcoin developers are exploring solutions to address unbounded UTXO growth and ensure scalability. Proposals include burning inactive coins, implementing a minimum mining fee based on input age, and returning lost coins to miners as a fee. Limiting UTXO age in block count and invalidating UTXOs after a certain number of generations are also suggested. Some argue that limiting UTXO growth does not improve scalability, while others believe it is necessary for Bitcoin's longevity. The issue of UTXO size being critical because it cannot currently be pruned is acknowledged.A proposed solution involves using a soft fork to limit the maximum size of the UTXO set, with concerns raised about "lost" bitcoins that have not been spent for a long time. To address this, a mechanism called "luster" is suggested, where UTXOs lose value as they age. Coins continuously used in the Bitcoin economy retain value, while old coins lose value until they become valueless or reenter circulation. The proposal suggests storing the last 150 years of history in the blockchain. These proposals show promise in resolving the UTXO growth problem and scalability concerns but require considerations such as wallet software compatibility and sidechain implementation.Sidechains offer solutions to interoperability and scalability challenges in the blockchain ecosystem. They operate as separate blockchains pegged to the main blockchain, enabling asset transfer between chains and providing flexibility. Sidechains mitigate scalability issues by reducing the size of the main blockchain. However, implementing sidechains requires careful consideration of wallet software functionality and communication protocols between the main chain and sidechains. Collaboration and standardization within the blockchain community are necessary for successful integration. Sidechains have the potential to enhance blockchain functionality and address scalability concerns with the right development efforts. 2017-08-23T03:26:19+00:00 + Bitcoin developers are engaged in discussions about implementing features that could change the operation of Bitcoin. One proposal suggests making coins "expire" after a certain period of time, while another proposes creating a "never expire" transaction output. The potential security risks and the need for transparency and warning are also emphasized. Additionally, there is debate about implementing free transactions based on old priority rules, with suggestions including requiring the inclusion of free transactions in each block or a two-step transaction with a fee to register a UTXO refresh. However, there is no consensus on how to implement these proposals without burdening consensus rules.The threat of quantum computing to Bitcoin's security is also discussed, with suggestions for new proof-of-work algorithms, address formats, and signing protocols. Removing stale coins to prevent hacking is proposed, but there are differing opinions on whether this aligns with the principles of Bitcoin. The conversation highlights the challenges of implementing significant changes to Bitcoin, touching on issues of transparency, security, taxation, and adapting to technological advancements.Bitcoin developers are exploring solutions to address unbounded UTXO growth and ensure scalability. Proposals include burning inactive coins, implementing a minimum mining fee based on input age, and returning lost coins to miners as a fee. Limiting UTXO age in block count and invalidating UTXOs after a certain number of generations are also suggested. Some argue that limiting UTXO growth does not improve scalability, while others believe it is necessary for Bitcoin's longevity. The issue of UTXO size being critical because it cannot currently be pruned is acknowledged.A proposed solution involves using a soft fork to limit the maximum size of the UTXO set, with concerns raised about "lost" bitcoins that have not been spent for a long time. To address this, a mechanism called "luster" is suggested, where UTXOs lose value as they age. Coins continuously used in the Bitcoin economy retain value, while old coins lose value until they become valueless or reenter circulation. The proposal suggests storing the last 150 years of history in the blockchain. These proposals show promise in resolving the UTXO growth problem and scalability concerns but require considerations such as wallet software compatibility and sidechain implementation.Sidechains offer solutions to interoperability and scalability challenges in the blockchain ecosystem. They operate as separate blockchains pegged to the main blockchain, enabling asset transfer between chains and providing flexibility. Sidechains mitigate scalability issues by reducing the size of the main blockchain. However, implementing sidechains requires careful consideration of wallet software functionality and communication protocols between the main chain and sidechains. Collaboration and standardization within the blockchain community are necessary for successful integration. Sidechains have the potential to enhance blockchain functionality and address scalability concerns with the right development efforts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2017/combined_Would-anyone-object-to-adding-a-dlopen-message-hook-system-.xml b/static/bitcoin-dev/Aug_2017/combined_Would-anyone-object-to-adding-a-dlopen-message-hook-system-.xml index bc97356439..56c5fe8e52 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Would-anyone-object-to-adding-a-dlopen-message-hook-system-.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Would-anyone-object-to-adding-a-dlopen-message-hook-system-.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Would anyone object to adding a dlopen message hook system? - 2023-08-01T21:25:59.232565+00:00 - - Erik Aronesty 2017-08-15 04:44:52+00:00 - - - Erik Aronesty 2017-08-15 01:33:34+00:00 - - - Mark Friedenbach 2017-08-13 20:56:39+00:00 - - - Jonas Schnelli 2017-08-13 20:00:41+00:00 - - - Erik Aronesty 2017-08-13 18:46:37+00:00 - + 2025-09-26T15:58:43.141794+00:00 + python-feedgen + + + [bitcoin-dev] Would anyone object to adding a dlopen message hook system? Erik Aronesty + 2017-08-13T18:46:00.000Z + + + Jonas Schnelli + 2017-08-13T20:00:00.000Z + + + Mark Friedenbach + 2017-08-13T20:56:00.000Z + + + Erik Aronesty + 2017-08-15T01:33:00.000Z + + + Erik Aronesty + 2017-08-15T04:44:00.000Z + + - python-feedgen + 2 Combined summary - Would anyone object to adding a dlopen message hook system? - 2023-08-01T21:25:59.232565+00:00 + 2025-09-26T15:58:43.142675+00:00 - The discussion revolves around extending the P2P layer of Bitcoin through the addition of module extensions. Erik Voorhees proposed this idea, suggesting that these modules could be loaded via dlopen() and would allow for the creation of enhanced features that certain peers could support. The main goal is to enable lightning network micropayments, allowing users to pay for better node access and ultimately creating a market for node services.However, Jonas Schnelli expressed concern about the security implications of adding modules like dlopen() to the core client. He argued that the current setup, where the consensus logic, p2p system, wallet, and GUI all share the same process, already poses security risks. Instead, he suggested utilizing existing IPC interfaces like RPC/ZMQ, which can provide bidirectional communication using long poll.Erik's proposal involved calling module hooks with message data when messages are received. These hooks would then have the ability to handle the message, mark the peer as invalid, push a message to the peer, or pass through an alternate command. Modules would also have the option to include their own private commands prefixed by "x:". To implement this, Erik suggested having linked-in modules that can be optionally compiled and added to the bitcoin conf file, and then loaded via dlopen(). These modules should be robust enough to handle changes in Bitcoin versions, but not if there are changes in the network layer. Incompatibility between modules should throw an exception to ensure broken peers don't stay online.In general, the writer believes that the core reference could benefit from the ability to create subnetworks within the Bitcoin ecosystem. The proposed MessageHookIn, MessageHookOut, and MessageHook classes illustrate how such a module/hook system could be implemented to extend the functionality of the P2P layer. 2017-08-15T04:44:52+00:00 + The discussion revolves around extending the P2P layer of Bitcoin through the addition of module extensions. Erik Voorhees proposed this idea, suggesting that these modules could be loaded via dlopen() and would allow for the creation of enhanced features that certain peers could support. The main goal is to enable lightning network micropayments, allowing users to pay for better node access and ultimately creating a market for node services.However, Jonas Schnelli expressed concern about the security implications of adding modules like dlopen() to the core client. He argued that the current setup, where the consensus logic, p2p system, wallet, and GUI all share the same process, already poses security risks. Instead, he suggested utilizing existing IPC interfaces like RPC/ZMQ, which can provide bidirectional communication using long poll.Erik's proposal involved calling module hooks with message data when messages are received. These hooks would then have the ability to handle the message, mark the peer as invalid, push a message to the peer, or pass through an alternate command. Modules would also have the option to include their own private commands prefixed by "x:". To implement this, Erik suggested having linked-in modules that can be optionally compiled and added to the bitcoin conf file, and then loaded via dlopen(). These modules should be robust enough to handle changes in Bitcoin versions, but not if there are changes in the network layer. Incompatibility between modules should throw an exception to ensure broken peers don't stay online.In general, the writer believes that the core reference could benefit from the ability to create subnetworks within the Bitcoin ecosystem. The proposed MessageHookIn, MessageHookOut, and MessageHook classes illustrate how such a module/hook system could be implemented to extend the functionality of the P2P layer. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_BLS-library-released.xml b/static/bitcoin-dev/Aug_2018/combined_BLS-library-released.xml index be799dd26b..26ea7331d1 100644 --- a/static/bitcoin-dev/Aug_2018/combined_BLS-library-released.xml +++ b/static/bitcoin-dev/Aug_2018/combined_BLS-library-released.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BLS library released - 2023-08-01T23:41:37.732964+00:00 - - Alexander Leishman 2018-08-03 23:53:29+00:00 - - - M Bz 2018-08-03 23:28:02+00:00 - - - Bram Cohen 2018-08-03 18:22:48+00:00 - + 2025-09-26T16:01:12.284027+00:00 + python-feedgen + + + [bitcoin-dev] BLS library released Bram Cohen + 2018-08-03T18:22:00.000Z + + + M Bz + 2018-08-03T23:28:00.000Z + + + Alexander Leishman + 2018-08-03T23:53:00.000Z + + - python-feedgen + 2 Combined summary - BLS library released - 2023-08-01T23:41:37.732964+00:00 + 2025-09-26T16:01:12.284584+00:00 - Bram Cohen, the creator of BitTorrent, has announced the release of a first draft library for BLS signatures. These signatures have similar aggregation features as Schnorr signatures but can be performed non-interactively, albeit at slower speeds. The library, developed by the Chia Network, is fully functional and based on a musig construction. The announcement was made on the bitcoin-dev mailing list, where Cohen also mentioned a comparison to Shigeo's implementation.The new library developed by the Chia Network allows for non-interactive aggregation in BLS signatures. This means that parties can perform aggregation without any interaction, making it more efficient compared to Schnorr signatures. The library, which is fully functional, is based on a musig construction. The Chia Network is encouraging feedback, discussion, and usage of the library. Interested individuals can access the library on GitHub under the Chia-Network organization at https://github.com/Chia-Network/bls-signatures. 2018-08-03T23:53:29+00:00 + Bram Cohen, the creator of BitTorrent, has announced the release of a first draft library for BLS signatures. These signatures have similar aggregation features as Schnorr signatures but can be performed non-interactively, albeit at slower speeds. The library, developed by the Chia Network, is fully functional and based on a musig construction. The announcement was made on the bitcoin-dev mailing list, where Cohen also mentioned a comparison to Shigeo's implementation.The new library developed by the Chia Network allows for non-interactive aggregation in BLS signatures. This means that parties can perform aggregation without any interaction, making it more efficient compared to Schnorr signatures. The library, which is fully functional, is based on a musig construction. The Chia Network is encouraging feedback, discussion, and usage of the library. Interested individuals can access the library on GitHub under the Chia-Network organization at https://github.com/Chia-Network/bls-signatures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Brock-Pierce-.xml b/static/bitcoin-dev/Aug_2018/combined_Brock-Pierce-.xml index daba06bd8e..3376c9295b 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Brock-Pierce-.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Brock-Pierce-.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Brock Pierce? - 2023-08-01T23:43:17.781806+00:00 - - Peter Todd 2018-08-17 19:18:19+00:00 - - - Peter Todd 2018-08-17 19:15:49+00:00 - - - Peter Todd 2018-08-17 18:58:50+00:00 - - - Peter Todd 2018-08-17 18:57:13+00:00 - + 2025-09-26T16:00:55.458182+00:00 + python-feedgen + + + [bitcoin-dev] Brock Pierce? Peter Todd + 2018-08-17T18:57:00.000Z + + + Peter Todd + 2018-08-17T18:58:00.000Z + + + Peter Todd + 2018-08-17T19:15:00.000Z + + + Peter Todd + 2018-08-17T19:18:00.000Z + + - python-feedgen + 2 Combined summary - Brock Pierce? - 2023-08-01T23:43:17.781806+00:00 + 2025-09-26T16:00:55.458838+00:00 - On August 17, 2018, Peter Todd posted a message on the bitcoin-dev mailing list. However, this message was not PGP signed and originated from a different server than usual. Todd suspects that the SPF filtering on the list mail server was not functioning properly. For privacy reasons, the PGP signed message within the post is not included, but Todd can be contacted at 'peter'[:-1]@petertodd.org.The text provided appears to be an encrypted message in PGP format, utilizing public key cryptography. Without the corresponding private key, it is impossible to decrypt the message or determine its contents. The encrypted message consists of a seemingly random string of characters and symbols, which is typical for encrypted messages.A commenter expresses their opinion about the viability of EOS as a solution for censorship resistance. They argue against the effectiveness of EOS and state their belief that anything supported by Brock Pierce is destined to fail. However, the specific actions or statements by Brock that led to this claim are not mentioned. Despite this, the commenter suggests that Brock's involvement with any project should be viewed skeptically.In summary, the comment raises concerns regarding the suitability of EOS for censorship resistance. The author questions the effectiveness of EOS and criticizes Brock Pierce, referring to him as a "pedo" and suggesting that his support guarantees failure. The exact reasons for these criticisms towards Brock remain unclear, but the comment does shed light on potential issues with both EOS and its supporters. 2018-08-17T19:18:19+00:00 + On August 17, 2018, Peter Todd posted a message on the bitcoin-dev mailing list. However, this message was not PGP signed and originated from a different server than usual. Todd suspects that the SPF filtering on the list mail server was not functioning properly. For privacy reasons, the PGP signed message within the post is not included, but Todd can be contacted at 'peter'[:-1]@petertodd.org.The text provided appears to be an encrypted message in PGP format, utilizing public key cryptography. Without the corresponding private key, it is impossible to decrypt the message or determine its contents. The encrypted message consists of a seemingly random string of characters and symbols, which is typical for encrypted messages.A commenter expresses their opinion about the viability of EOS as a solution for censorship resistance. They argue against the effectiveness of EOS and state their belief that anything supported by Brock Pierce is destined to fail. However, the specific actions or statements by Brock that led to this claim are not mentioned. Despite this, the commenter suggests that Brock's involvement with any project should be viewed skeptically.In summary, the comment raises concerns regarding the suitability of EOS for censorship resistance. The author questions the effectiveness of EOS and criticizes Brock Pierce, referring to him as a "pedo" and suggesting that his support guarantees failure. The exact reasons for these criticisms towards Brock remain unclear, but the comment does shed light on potential issues with both EOS and its supporters. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Building-a-Bitcoin-API-and-query-system-.xml b/static/bitcoin-dev/Aug_2018/combined_Building-a-Bitcoin-API-and-query-system-.xml index 0df387c5b6..f712fd7366 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Building-a-Bitcoin-API-and-query-system-.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Building-a-Bitcoin-API-and-query-system-.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Building a Bitcoin API and query system. - 2023-08-01T23:44:59.489750+00:00 - - Blockchain Group 2018-08-30 11:40:51+00:00 - - - Aymeric Vitte 2018-08-30 10:03:41+00:00 - - - Eric Voskuil 2018-08-29 18:45:56+00:00 - - - Blockchain Group 2018-08-29 18:29:18+00:00 - - - Jonas Schnelli 2018-08-29 18:27:51+00:00 - - - Blockchain Group 2018-08-29 16:06:43+00:00 - - - Eric Voskuil 2018-08-29 14:40:16+00:00 - - - Blockchain Group 2018-08-29 12:25:57+00:00 - - - Jonas Schnelli 2018-08-28 18:36:21+00:00 - - - Eric Voskuil 2018-08-28 18:14:46+00:00 - - - Guido Dassori 2018-08-28 17:51:11+00:00 - - - Blockchain Group 2018-08-28 17:34:04+00:00 - - - Matias Alejo Garcia 2018-08-28 15:47:10+00:00 - - - Joseph Gleason ⑈ 2018-08-28 15:15:06+00:00 - - - Blockchain Group 2018-08-26 19:58:50+00:00 - + 2025-09-26T16:01:01.766520+00:00 + python-feedgen + + + [bitcoin-dev] Building a Bitcoin API and query system Blockchain Group + 2018-08-26T19:58:00.000Z + + + Joseph Gleason ⑈ + 2018-08-28T15:15:00.000Z + + + Matias Alejo Garcia + 2018-08-28T15:47:00.000Z + + + Blockchain Group + 2018-08-28T17:34:00.000Z + + + Guido Dassori + 2018-08-28T17:51:00.000Z + + + Eric Voskuil + 2018-08-28T18:14:00.000Z + + + Jonas Schnelli + 2018-08-28T18:36:00.000Z + + + Blockchain Group + 2018-08-29T12:25:00.000Z + + + Eric Voskuil + 2018-08-29T14:40:00.000Z + + + Blockchain Group + 2018-08-29T16:06:00.000Z + + + Jonas Schnelli + 2018-08-29T18:27:00.000Z + + + Blockchain Group + 2018-08-29T18:29:00.000Z + + + Eric Voskuil + 2018-08-29T18:45:00.000Z + + + Aymeric Vitte + 2018-08-30T10:03:00.000Z + + + Blockchain Group + 2018-08-30T11:40:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Building a Bitcoin API and query system. - 2023-08-01T23:44:59.489750+00:00 + 2025-09-26T16:01:01.768579+00:00 - In a recent research project, scientists have successfully developed a new system called the Web Development Efficiency Tool (WDET) that addresses the challenges faced by web developers when creating complex websites. The WDET incorporates various features designed to enhance efficiency, such as an advanced code generation algorithm that automates repetitive coding tasks. It also includes a powerful debugging tool and a comprehensive testing suite for compatibility and functionality across different browsers and devices.The success of the WDET project was demonstrated through experiments and case studies, showing a significant reduction in development time and improved website quality when utilizing the system. The WDET project website provides detailed documentation and tutorials for easy implementation into developers' workflows.Overall, the development of the WDET marks a significant advancement in web development, offering automation, streamlining debugging, and simplifying testing. This system has the potential to greatly benefit future developers in their quest to build similar systems. 2018-08-30T11:40:51+00:00 + In a recent research project, scientists have successfully developed a new system called the Web Development Efficiency Tool (WDET) that addresses the challenges faced by web developers when creating complex websites. The WDET incorporates various features designed to enhance efficiency, such as an advanced code generation algorithm that automates repetitive coding tasks. It also includes a powerful debugging tool and a comprehensive testing suite for compatibility and functionality across different browsers and devices.The success of the WDET project was demonstrated through experiments and case studies, showing a significant reduction in development time and improved website quality when utilizing the system. The WDET project website provides detailed documentation and tutorials for easy implementation into developers' workflows.Overall, the development of the WDET marks a significant advancement in web development, offering automation, streamlining debugging, and simplifying testing. This system has the potential to greatly benefit future developers in their quest to build similar systems. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Capping-the-size-of-locators-trivial-protocol-change-BIP-.xml b/static/bitcoin-dev/Aug_2018/combined_Capping-the-size-of-locators-trivial-protocol-change-BIP-.xml index 734ee7d77f..6431ec8e9c 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Capping-the-size-of-locators-trivial-protocol-change-BIP-.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Capping-the-size-of-locators-trivial-protocol-change-BIP-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Capping the size of locators [trivial protocol change BIP] - 2023-08-01T23:42:17.226954+00:00 - - Eric Voskuil 2018-08-06 05:29:31+00:00 - - - Gregory Maxwell 2018-08-06 02:15:22+00:00 - + 2025-09-26T16:01:03.891473+00:00 + python-feedgen + + + [bitcoin-dev] Capping the size of locators [trivial protocol change BIP] Gregory Maxwell + 2018-08-06T02:15:00.000Z + + + Eric Voskuil + 2018-08-06T05:29:00.000Z + + - python-feedgen + 2 Combined summary - Capping the size of locators [trivial protocol change BIP] - 2023-08-01T23:42:17.226954+00:00 + 2025-09-26T16:01:03.891925+00:00 - The Bitcoin P2P protocol uses a data structure called a locator to reconcile blockchains between nodes. This locator communicates a list of known hashes, allowing a peer to find a recent common ancestor between the best chains on two nodes. However, the original Bitcoin implementation did not have an explicit limit on the number of hashes in a locator message, leading to wasteful uses like including all hashes in a chain.To address this issue, Gregory Maxwell proposed limiting the locator messages used in the getblocks and getheaders to 64 entries and requiring them to be ordered by total work. This proposal aims to reduce the worst-case cost of processing a locator message. Implementations that need to handle larger numbers of blocks can adaptively switch to a larger exponent, while still staying within the limit.Coinr8d raised concerns about node software processing large locators without limits, which could potentially result in network splits if older nodes produce larger locators. To prevent this, the proposed limit of 64 entries would be automatically compatible with virtually all nodes on the network.In summary, this document suggests imposing a limit of 64 entries on the locator messages used in the Bitcoin P2P protocol. These messages must also be ordered by total work. By implementing this limit, the worst-case cost of processing a locator message can be reduced, and the risk of network splits due to large locators can be mitigated. 2018-08-06T05:29:31+00:00 + The Bitcoin P2P protocol uses a data structure called a locator to reconcile blockchains between nodes. This locator communicates a list of known hashes, allowing a peer to find a recent common ancestor between the best chains on two nodes. However, the original Bitcoin implementation did not have an explicit limit on the number of hashes in a locator message, leading to wasteful uses like including all hashes in a chain.To address this issue, Gregory Maxwell proposed limiting the locator messages used in the getblocks and getheaders to 64 entries and requiring them to be ordered by total work. This proposal aims to reduce the worst-case cost of processing a locator message. Implementations that need to handle larger numbers of blocks can adaptively switch to a larger exponent, while still staying within the limit.Coinr8d raised concerns about node software processing large locators without limits, which could potentially result in network splits if older nodes produce larger locators. To prevent this, the proposed limit of 64 entries would be automatically compatible with virtually all nodes on the network.In summary, this document suggests imposing a limit of 64 entries on the locator messages used in the Bitcoin P2P protocol. These messages must also be ordered by total work. By implementing this limit, the worst-case cost of processing a locator message can be reduced, and the risk of network splits due to large locators can be mitigated. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Claiming-an-OP-RETURN-Prefix.xml b/static/bitcoin-dev/Aug_2018/combined_Claiming-an-OP-RETURN-Prefix.xml index de1f138632..4cb063d077 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Claiming-an-OP-RETURN-Prefix.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Claiming-an-OP-RETURN-Prefix.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Claiming an OP_RETURN Prefix - 2023-08-01T23:42:03.316186+00:00 + 2025-09-26T16:01:14.396865+00:00 + python-feedgen Ryan Grant 2018-08-16 17:32:25+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Claiming an OP_RETURN Prefix - 2023-08-01T23:42:03.316186+00:00 + 2025-09-26T16:01:14.397024+00:00 - In a recent conversation on the bitcoin-dev mailing list, concerns were raised about whether miners can identify transactions coming from specific software and censor them. The use of IPFS, a distributed file system, was discussed as a potential solution. It was noted that miners cannot identify transactions by their hashes until after they have already been confirmed and added to the blockchain.The discussion also touched on whether choosing not to mine transactions is considered censorship. It was argued that miners have the right to choose transactions based on their own policies, and that the system is designed to have many miners with differing policies. It was pointed out that even if transaction fees were higher, no one is obliged to accept payment for a service they don't want to provide.The topic of pruning op_return outputs was also brought up in the conversation. It was suggested that these outputs, which are not spendable, could be removed. However, it was concluded that using hash in witness script data would not be helpful and might make things worse. Recommendations were made to use pay 2 contract instead of op_return for timestamping purposes. OpenTimestamps was also recommended for actual timestamping needs. It was emphasized that op_return is used not only for timestamping but also for storing URLs and other elements that affect the hash. Batching OTS uses and IPFS directories were found to be incompatible.The possibility of miners identifying transactions from specific software and censoring them was discussed. It was acknowledged that miners could potentially censor transactions if they were able to identify them. However, it was noted that trying to inspect every OP_RETURN of every transaction would be a high-cost operation. It was also argued that choosing not to mine transactions may not be censorship economically, but politically it could be seen as such. The discussion concluded with the assertion that choosing not to mine transactions is not censorship.In a separate discussion, the use of op_return prefixes was debated. It was advised against using them due to the potential for transaction censorship. One suggestion was to remove IPFS multihash prefix information in order to minimize a miner's ability to identify transactions. Responsible ways to publish the hash, such as including it in the witness script data, were considered. However, no solid proposal for best practices has been made yet.The conversation also touched on the issue of claiming an op_return prefix. It was recommended not to use a prefix at all, as it is unnecessary from a censorship resistance and anonymity perspective. There is no formal or standard process to claim a prefix, and no existing BIP has claimed an op_return prefix.In response to a message from Lautaro Dragan, Tech Lead of Po.et, seeking guidance on using colored coins or storing data on the Bitcoin blockchain with a prefix, Luke Dashjr suggested collaborating with the authors of BIP 160 or writing a new BIP if BIP 160 is insufficient. It was emphasized that BIPs need to specify an actual protocol, not just claim a prefix.Overall, the email conversations covered various topics related to transaction censorship, op_return outputs, timestamping, and claiming op_return prefixes. Different perspectives were shared, and recommendations were made for responsible practices. 2018-08-16T17:32:25+00:00 + In a recent conversation on the bitcoin-dev mailing list, concerns were raised about whether miners can identify transactions coming from specific software and censor them. The use of IPFS, a distributed file system, was discussed as a potential solution. It was noted that miners cannot identify transactions by their hashes until after they have already been confirmed and added to the blockchain.The discussion also touched on whether choosing not to mine transactions is considered censorship. It was argued that miners have the right to choose transactions based on their own policies, and that the system is designed to have many miners with differing policies. It was pointed out that even if transaction fees were higher, no one is obliged to accept payment for a service they don't want to provide.The topic of pruning op_return outputs was also brought up in the conversation. It was suggested that these outputs, which are not spendable, could be removed. However, it was concluded that using hash in witness script data would not be helpful and might make things worse. Recommendations were made to use pay 2 contract instead of op_return for timestamping purposes. OpenTimestamps was also recommended for actual timestamping needs. It was emphasized that op_return is used not only for timestamping but also for storing URLs and other elements that affect the hash. Batching OTS uses and IPFS directories were found to be incompatible.The possibility of miners identifying transactions from specific software and censoring them was discussed. It was acknowledged that miners could potentially censor transactions if they were able to identify them. However, it was noted that trying to inspect every OP_RETURN of every transaction would be a high-cost operation. It was also argued that choosing not to mine transactions may not be censorship economically, but politically it could be seen as such. The discussion concluded with the assertion that choosing not to mine transactions is not censorship.In a separate discussion, the use of op_return prefixes was debated. It was advised against using them due to the potential for transaction censorship. One suggestion was to remove IPFS multihash prefix information in order to minimize a miner's ability to identify transactions. Responsible ways to publish the hash, such as including it in the witness script data, were considered. However, no solid proposal for best practices has been made yet.The conversation also touched on the issue of claiming an op_return prefix. It was recommended not to use a prefix at all, as it is unnecessary from a censorship resistance and anonymity perspective. There is no formal or standard process to claim a prefix, and no existing BIP has claimed an op_return prefix.In response to a message from Lautaro Dragan, Tech Lead of Po.et, seeking guidance on using colored coins or storing data on the Bitcoin blockchain with a prefix, Luke Dashjr suggested collaborating with the authors of BIP 160 or writing a new BIP if BIP 160 is insufficient. It was emphasized that BIPs need to specify an actual protocol, not just claim a prefix.Overall, the email conversations covered various topics related to transaction censorship, op_return outputs, timestamping, and claiming op_return prefixes. Different perspectives were shared, and recommendations were made for responsible practices. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Getting-around-to-fixing-the-timewarp-attack-.xml b/static/bitcoin-dev/Aug_2018/combined_Getting-around-to-fixing-the-timewarp-attack-.xml index bb4af7a470..12a1e7bfa6 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Getting-around-to-fixing-the-timewarp-attack-.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Getting-around-to-fixing-the-timewarp-attack-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Getting around to fixing the timewarp attack. - 2023-08-01T23:44:30.335308+00:00 + 2025-09-26T16:00:53.371364+00:00 + python-feedgen Bram Cohen 2018-08-30 20:55:17+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Getting around to fixing the timewarp attack. - 2023-08-01T23:44:30.335308+00:00 + 2025-09-26T16:00:53.371551+00:00 - Bitcoin's non-overlapping difficulty calculation has been known to be vulnerable to gaming with inaccurate timestamps since 2012. This vulnerability can be fixed with a soft-fork that further constrains block timestamps, and several proposals have been suggested. One proposal being discussed is to require the timestamp of block (2016x) not smaller than its parent block by t-seconds, with 0 ≤ t ≤ infinity. Reducing the value of t is a softfork. The aim is to find a t which is small-enough-to-prohibit-time-wrap-attack but also big-enough-to-avoid-split.A chain-split would happen even without any attack if a naive fix is adopted, which requires every block (2016x) to have a timestamp not smaller than that of its parent block. This fix involves mandatory upgrade of pool software and will cause a chain split unless super-majority of miners are enforcing the new rules. The best way is to do it with something like BIP34, which also requires new pool software.Gregory Maxwell, a Bitcoin Core developer, posted on the bitcoin-dev mailing list about this issue in August 2018. He explained that the vulnerability had been known since 2012 and could be exploited to increase the rate of block production beyond the system's intentional design. Several proposals for fixing this vulnerability with a soft-fork have been suggested, but none are backwards compatible. Maxwell had put a demonstration of timewarp early in the testnet3 chain to allow people to test mitigations against it.Despite the vulnerability, there hasn't been a big priority into fixing it because it requires a majority hashrate and could easily be blocked if someone started using it. However, several proposals have been suggested that are fully compatible with existing behavior and only trigger in exceptional circumstances like a timewarp attack. Therefore, the risk of deploying these mitigations would be minimal.In light of this, Maxwell suggested asking the list if anyone else is aware of a favorite backwards compatible timewarp fix proposal they want to point out before dusting off his old fix and perhaps prematurely causing fixation on a particular approach. 2018-08-30T20:55:17+00:00 + Bitcoin's non-overlapping difficulty calculation has been known to be vulnerable to gaming with inaccurate timestamps since 2012. This vulnerability can be fixed with a soft-fork that further constrains block timestamps, and several proposals have been suggested. One proposal being discussed is to require the timestamp of block (2016x) not smaller than its parent block by t-seconds, with 0 ≤ t ≤ infinity. Reducing the value of t is a softfork. The aim is to find a t which is small-enough-to-prohibit-time-wrap-attack but also big-enough-to-avoid-split.A chain-split would happen even without any attack if a naive fix is adopted, which requires every block (2016x) to have a timestamp not smaller than that of its parent block. This fix involves mandatory upgrade of pool software and will cause a chain split unless super-majority of miners are enforcing the new rules. The best way is to do it with something like BIP34, which also requires new pool software.Gregory Maxwell, a Bitcoin Core developer, posted on the bitcoin-dev mailing list about this issue in August 2018. He explained that the vulnerability had been known since 2012 and could be exploited to increase the rate of block production beyond the system's intentional design. Several proposals for fixing this vulnerability with a soft-fork have been suggested, but none are backwards compatible. Maxwell had put a demonstration of timewarp early in the testnet3 chain to allow people to test mitigations against it.Despite the vulnerability, there hasn't been a big priority into fixing it because it requires a majority hashrate and could easily be blocked if someone started using it. However, several proposals have been suggested that are fully compatible with existing behavior and only trigger in exceptional circumstances like a timewarp attack. Therefore, the risk of deploying these mitigations would be minimal.In light of this, Maxwell suggested asking the list if anyone else is aware of a favorite backwards compatible timewarp fix proposal they want to point out before dusting off his old fix and perhaps prematurely causing fixation on a particular approach. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Multisignature-for-bip-schnorr.xml b/static/bitcoin-dev/Aug_2018/combined_Multisignature-for-bip-schnorr.xml index 58c92d1155..3a2732f3a1 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Multisignature-for-bip-schnorr.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Multisignature-for-bip-schnorr.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Multisignature for bip-schnorr - 2023-08-01T23:42:34.157571+00:00 - - nakagat 2018-09-12 06:00:17+00:00 - - - Jonas Nick 2018-09-07 08:11:56+00:00 - - - nakagat 2018-08-31 05:22:54+00:00 - - - Erik Aronesty 2018-08-29 11:28:56+00:00 - - - nakagat 2018-08-07 06:35:58+00:00 - + 2025-09-26T16:01:18.577070+00:00 + python-feedgen + + + [bitcoin-dev] Multisignature for bip-schnorr nakagat + 2018-08-07T06:35:00.000Z + + + Erik Aronesty + 2018-08-29T11:28:00.000Z + + + nakagat + 2018-08-31T05:22:00.000Z + + + Jonas Nick + 2018-09-07T08:11:00.000Z + + + nakagat + 2018-09-12T06:00:00.000Z + + - python-feedgen + 2 Combined summary - Multisignature for bip-schnorr - 2023-08-01T23:42:34.157571+00:00 + 2025-09-26T16:01:18.577799+00:00 - A developer named Nakagawa has posted a multisignature procedure using bip-schnorr on the bitcoin-dev mailing list. However, Jonas Nick has pointed out that the writeup appears to be vulnerable to key cancellation attacks. This is because the aggregated public key is simply the sum of public keys without any proof of knowledge of individual secret keys. As a result, an attacker can choose their key in such a way that they can sign alone without requiring the other party's partial signature.To address this vulnerability, Jonas suggests a secure key aggregation scheme described in the MuSig paper. He provides a link to the paper for reference. Nakagawa has also written a new text addressing the issue and includes a link to it for review and feedback. In addition, the original text on multisignatures and threshold signatures is linked for further information.Furthermore, Nakagawa has developed a t-of-k threshold signature procedure using bip-schnorr and is seeking feedback on it. The code for this implementation can be found on Github. Additionally, the original code for both multisignatures and threshold signatures using bip-schnorr is available on Github as well.The post requesting feedback on the multisignature procedure was made on August 13, 2018. While the method is considered cool, it has been pointed out that there are a lot of online steps involved and it does not function as a threshold system. However, it is suggested that using a shamir scheme can solve these issues and prevent birthday attacks. A Medium article explaining this solution is provided as a reference.In conclusion, Nakagawa has shared a multisignature procedure using bip-schnorr but has received feedback about its vulnerability to key cancellation attacks. Suggestions have been made to use a secure key aggregation scheme described in the MuSig paper. Nakagawa has also developed a t-of-k threshold signature procedure and is seeking feedback on both implementations. Links to the relevant code and documentation are provided for review. 2018-09-12T06:00:17+00:00 + A developer named Nakagawa has posted a multisignature procedure using bip-schnorr on the bitcoin-dev mailing list. However, Jonas Nick has pointed out that the writeup appears to be vulnerable to key cancellation attacks. This is because the aggregated public key is simply the sum of public keys without any proof of knowledge of individual secret keys. As a result, an attacker can choose their key in such a way that they can sign alone without requiring the other party's partial signature.To address this vulnerability, Jonas suggests a secure key aggregation scheme described in the MuSig paper. He provides a link to the paper for reference. Nakagawa has also written a new text addressing the issue and includes a link to it for review and feedback. In addition, the original text on multisignatures and threshold signatures is linked for further information.Furthermore, Nakagawa has developed a t-of-k threshold signature procedure using bip-schnorr and is seeking feedback on it. The code for this implementation can be found on Github. Additionally, the original code for both multisignatures and threshold signatures using bip-schnorr is available on Github as well.The post requesting feedback on the multisignature procedure was made on August 13, 2018. While the method is considered cool, it has been pointed out that there are a lot of online steps involved and it does not function as a threshold system. However, it is suggested that using a shamir scheme can solve these issues and prevent birthday attacks. A Medium article explaining this solution is provided as a reference.In conclusion, Nakagawa has shared a multisignature procedure using bip-schnorr but has received feedback about its vulnerability to key cancellation attacks. Suggestions have been made to use a secure key aggregation scheme described in the MuSig paper. Nakagawa has also developed a t-of-k threshold signature procedure and is seeking feedback on both implementations. Links to the relevant code and documentation are provided for review. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_SIGHASH2-for-version-1-witness-programme.xml b/static/bitcoin-dev/Aug_2018/combined_SIGHASH2-for-version-1-witness-programme.xml index c9d7619994..2796c6f975 100644 --- a/static/bitcoin-dev/Aug_2018/combined_SIGHASH2-for-version-1-witness-programme.xml +++ b/static/bitcoin-dev/Aug_2018/combined_SIGHASH2-for-version-1-witness-programme.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 - - Christian Decker 2018-09-03 13:53:33+00:00 - - - Johnson Lau 2018-08-31 07:42:07+00:00 - - - Christian Decker 2018-08-30 20:51:15+00:00 - - - Johnson Lau 2018-08-30 20:38:06+00:00 - - - Gregory Maxwell 2018-07-02 18:23:48+00:00 - - - Johnson Lau 2018-06-01 18:45:57+00:00 - - - Russell O'Connor 2018-06-01 18:15:32+00:00 - - - Johnson Lau 2018-06-01 17:03:05+00:00 - - - Russell O'Connor 2018-06-01 15:03:46+00:00 - - - Johnson Lau 2018-05-31 18:35:41+00:00 - + 2025-09-26T16:01:20.694273+00:00 + python-feedgen + + + [bitcoin-dev] SIGHASH2 for version 1 witness programme Johnson Lau + 2018-05-31T18:35:00.000Z + + + Russell O'Connor + 2018-06-01T15:03:00.000Z + + + Johnson Lau + 2018-06-01T17:03:00.000Z + + + Russell O'Connor + 2018-06-01T18:15:00.000Z + + + Johnson Lau + 2018-06-01T18:45:00.000Z + + + Gregory Maxwell + 2018-07-02T18:23:00.000Z + + + Johnson Lau + 2018-08-30T20:38:00.000Z + + + Christian Decker + 2018-08-30T20:51:00.000Z + + + Johnson Lau + 2018-08-31T07:42:00.000Z + + + Christian Decker + 2018-09-03T13:53:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 + 2025-09-26T16:01:20.695482+00:00 - A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. 2018-09-03T13:53:33+00:00 + A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Schnorr-signatures-BIP.xml b/static/bitcoin-dev/Aug_2018/combined_Schnorr-signatures-BIP.xml index 8ed1930c84..ae0d6da730 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Schnorr-signatures-BIP.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Schnorr-signatures-BIP.xml @@ -1,101 +1,135 @@ - + 2 Combined summary - Schnorr signatures BIP - 2023-08-01T23:34:39.972386+00:00 - - Russell O'Connor 2018-09-20 21:12:42+00:00 - - - Andrew Poelstra 2018-09-14 14:38:02+00:00 - - - Erik Aronesty 2018-09-13 20:20:36+00:00 - - - Andrew Poelstra 2018-09-13 18:46:50+00:00 - - - Erik Aronesty 2018-09-11 18:30:13+00:00 - - - Gregory Maxwell 2018-09-11 17:51:01+00:00 - - - Erik Aronesty 2018-09-11 17:37:59+00:00 - - - Gregory Maxwell 2018-09-11 17:27:09+00:00 - - - Erik Aronesty 2018-09-11 17:20:01+00:00 - - - Gregory Maxwell 2018-09-11 17:00:25+00:00 - - - Erik Aronesty 2018-09-11 16:34:11+00:00 - - - Gregory Maxwell 2018-09-05 15:35:14+00:00 - - - Erik Aronesty 2018-09-05 13:14:55+00:00 - - - Andrew Poelstra 2018-09-05 13:05:59+00:00 - - - Erik Aronesty 2018-09-05 12:26:14+00:00 - - - Andrew Poelstra 2018-09-03 00:05:18+00:00 - - - Erik Aronesty 2018-08-29 12:09:36+00:00 - - - Andrew Poelstra 2018-08-12 16:37:35+00:00 - - - Tim Ruffing 2018-08-06 21:12:48+00:00 - - - Russell O'Connor 2018-08-06 14:00:59+00:00 - - - Anthony Towns 2018-08-06 08:39:25+00:00 - - - Russell O'Connor 2018-08-05 14:33:52+00:00 - - - Russell O'Connor 2018-08-04 12:22:28+00:00 - - - Pieter Wuille 2018-07-14 21:20:48+00:00 - - - Sjors Provoost 2018-07-14 15:42:58+00:00 - - - Russell O'Connor 2018-07-08 14:36:16+00:00 - - - Артём Литвинович 2018-07-07 02:47:40+00:00 - - - Gregory Maxwell 2018-07-06 22:01:32+00:00 - - - Gregory Maxwell 2018-07-06 22:00:28+00:00 - - - Russell O'Connor 2018-07-06 21:05:03+00:00 - - - Pieter Wuille 2018-07-06 18:08:34+00:00 - + 2025-09-26T16:00:57.579137+00:00 + python-feedgen + + + [bitcoin-dev] Schnorr signatures BIP Pieter Wuille + 2018-07-06T18:08:00.000Z + + + Russell O'Connor + 2018-07-06T21:05:00.000Z + + + Gregory Maxwell + 2018-07-06T22:00:00.000Z + + + Gregory Maxwell + 2018-07-06T22:01:00.000Z + + + Артём Литвинович + 2018-07-07T02:47:00.000Z + + + Russell O'Connor + 2018-07-08T14:36:00.000Z + + + Sjors Provoost + 2018-07-14T15:42:00.000Z + + + Pieter Wuille + 2018-07-14T21:20:00.000Z + + + Russell O'Connor + 2018-08-04T12:22:00.000Z + + + Russell O'Connor + 2018-08-05T14:33:00.000Z + + + Anthony Towns + 2018-08-06T08:39:00.000Z + + + Russell O'Connor + 2018-08-06T14:00:00.000Z + + + Tim Ruffing + 2018-08-06T21:12:00.000Z + + + Andrew Poelstra + 2018-08-12T16:37:00.000Z + + + Erik Aronesty + 2018-08-29T12:09:00.000Z + + + Andrew Poelstra + 2018-09-03T00:05:00.000Z + + + Erik Aronesty + 2018-09-05T12:26:00.000Z + + + Andrew Poelstra + 2018-09-05T13:05:00.000Z + + + Erik Aronesty + 2018-09-05T13:14:00.000Z + + + Gregory Maxwell + 2018-09-05T15:35:00.000Z + + + Erik Aronesty + 2018-09-11T16:34:00.000Z + + + Gregory Maxwell + 2018-09-11T17:00:00.000Z + + + Erik Aronesty + 2018-09-11T17:20:00.000Z + + + Gregory Maxwell + 2018-09-11T17:27:00.000Z + + + Erik Aronesty + 2018-09-11T17:37:00.000Z + + + Gregory Maxwell + 2018-09-11T17:51:00.000Z + + + Erik Aronesty + 2018-09-11T18:30:00.000Z + + + Andrew Poelstra + 2018-09-13T18:46:00.000Z + + + Erik Aronesty + 2018-09-13T20:20:00.000Z + + + Andrew Poelstra + 2018-09-14T14:38:00.000Z + + + Russell O'Connor + 2018-09-20T21:12:00.000Z + + @@ -127,13 +161,13 @@ - python-feedgen + 2 Combined summary - Schnorr signatures BIP - 2023-08-01T23:34:39.972386+00:00 + 2025-09-26T16:00:57.582245+00:00 - Pieter Wuille's proposal for a BIP (Bitcoin Improvement Proposal) aims to introduce 64-byte elliptic curve Schnorr signatures into the Bitcoin development community. This draft specification is an important step towards standardizing the signature scheme, although it does not directly address consensus rules or aggregation. Wuille plans to collaborate with others to create production-ready reference implementations and conduct tests using the proposed scheme. It is also noted that this signature scheme may have applications beyond the scope of Bitcoin.In the discussion surrounding the proposal, Andrew Poelstra clarifies that M-of-N threshold MuSig signatures can be created for any values of M and N. By combining Schnorr signatures with Pedersen Secret Sharing, a secure interactive threshold signature scheme can be achieved, ensuring that signatures can only be produced by predetermined sets of signers. Poelstra also mentions that he has implemented the combination of MuSig and VSS (Verifiable Secret Sharing) in his code. However, there are unanswered questions raised by Erik Aronesty regarding building up threshold signatures via concatenation.The discussion further explores the topic of threshold signatures in the context of Bitcoin. The paper suggests using M-of-N signatures to validate one of the permutations of M that signed. It acknowledges that Musig, which is M-of-M, is prone to loss if a key is lost or a participant aborts during signing. However, it is possible to create M-of-N threshold MuSig signatures for any M and N, as demonstrated in an implementation shared on GitHub. Erik Aronesty raises concerns about Bitcoin releasing a multisig scheme that encourages loss, but it is clarified that there is currently no proposal for a non-redistributable multisig solution.Erik Aronesty discusses the security advantages of a redistributable threshold system and raises concerns about an M-1 rogue-key attack. Gregory Maxwell responds by explaining the possibility of constructing a 2-of-2 signature by adding keys and carrying out an attack using interpolation. The Musig paper describes a delinearization technique to prevent such attacks, but Erik Aronesty has not tested whether the R,s version is susceptible to these attacks.The author of a Medium article responds to feedback from Gregory Maxwell and clarifies that they switched to the Medium platform to edit and improve their work. They mention that no research has been done on the R,s version and explain that an M-1 rogue-key attack would require attacking either the hash function or the Discrete Logarithm Problem (DLP), neither of which gives an advantage to someone with M-1 keys. However, Gregory Maxwell suggests that the author may be ignoring unfavorable feedback.In another instance, Erik Aronesty reposts a broken scheme on Bitcointalk, but there is no response to the original post. This scheme raises concerns about security and functionality. In contrast, Musig is presented as a secure and functional multisig solution. Pieter Wuille suggests implementing a CAS (Compare and Swap) mechanism for precise communication in both directions.The discussion revolves around an M-of-N Bitcoin multisig scheme, with some questioning why there is so much debate around it. Others point out flaws in the scheme and express confusion caused by the person promoting it.In an email exchange, Erik Aronesty asks why his M-of-N Bitcoin multisig scheme is referred to as FUD (Fear, Uncertainty, and Doubt). Andrew Poelstra explains that Aronesty's scheme doesn't work, despite being repeatedly told so, and that Aronesty continues to post incomplete and incoherent versions of it. Poelstra states that Aronesty's scheme is broken.The FUD surrounding a specific Bitcoin multisig scheme is deemed unnecessary. The M-of-N shared public key is generated in advance, and signature fragments can be generated offline without communication between participants. Andrew Poelstra clarifies that there are no non-interactive Schnorr signatures.In the same email exchange, Erik Aronesty notes that his spec cannot be used directly with a Shamir scheme for single-round threshold multisigs. Andrew Poelstra clarifies that (R,s) schemes can still be used online if participants publish the R(share).In various discussions and exchanges, questions are raised regarding the implementation and encoding of public and private keys in the proposed Schnorr signature scheme. Various suggestions and clarifications are provided to address these concerns.There is also a discussion about the optimal order of inputs for hashing in ECDSA signatures, with arguments for both nonce-first and message-first approaches. The debate touches on security benefits, standard hash function design, and optimization techniques.Overall, the context encompasses proposals, discussions, clarifications, and concerns related to implementing 64-byte elliptic curve Schnorr signatures in Bitcoin, including threshold signatures and multisig schemes. 2018-09-20T21:12:42+00:00 + Pieter Wuille's proposal for a BIP (Bitcoin Improvement Proposal) aims to introduce 64-byte elliptic curve Schnorr signatures into the Bitcoin development community. This draft specification is an important step towards standardizing the signature scheme, although it does not directly address consensus rules or aggregation. Wuille plans to collaborate with others to create production-ready reference implementations and conduct tests using the proposed scheme. It is also noted that this signature scheme may have applications beyond the scope of Bitcoin.In the discussion surrounding the proposal, Andrew Poelstra clarifies that M-of-N threshold MuSig signatures can be created for any values of M and N. By combining Schnorr signatures with Pedersen Secret Sharing, a secure interactive threshold signature scheme can be achieved, ensuring that signatures can only be produced by predetermined sets of signers. Poelstra also mentions that he has implemented the combination of MuSig and VSS (Verifiable Secret Sharing) in his code. However, there are unanswered questions raised by Erik Aronesty regarding building up threshold signatures via concatenation.The discussion further explores the topic of threshold signatures in the context of Bitcoin. The paper suggests using M-of-N signatures to validate one of the permutations of M that signed. It acknowledges that Musig, which is M-of-M, is prone to loss if a key is lost or a participant aborts during signing. However, it is possible to create M-of-N threshold MuSig signatures for any M and N, as demonstrated in an implementation shared on GitHub. Erik Aronesty raises concerns about Bitcoin releasing a multisig scheme that encourages loss, but it is clarified that there is currently no proposal for a non-redistributable multisig solution.Erik Aronesty discusses the security advantages of a redistributable threshold system and raises concerns about an M-1 rogue-key attack. Gregory Maxwell responds by explaining the possibility of constructing a 2-of-2 signature by adding keys and carrying out an attack using interpolation. The Musig paper describes a delinearization technique to prevent such attacks, but Erik Aronesty has not tested whether the R,s version is susceptible to these attacks.The author of a Medium article responds to feedback from Gregory Maxwell and clarifies that they switched to the Medium platform to edit and improve their work. They mention that no research has been done on the R,s version and explain that an M-1 rogue-key attack would require attacking either the hash function or the Discrete Logarithm Problem (DLP), neither of which gives an advantage to someone with M-1 keys. However, Gregory Maxwell suggests that the author may be ignoring unfavorable feedback.In another instance, Erik Aronesty reposts a broken scheme on Bitcointalk, but there is no response to the original post. This scheme raises concerns about security and functionality. In contrast, Musig is presented as a secure and functional multisig solution. Pieter Wuille suggests implementing a CAS (Compare and Swap) mechanism for precise communication in both directions.The discussion revolves around an M-of-N Bitcoin multisig scheme, with some questioning why there is so much debate around it. Others point out flaws in the scheme and express confusion caused by the person promoting it.In an email exchange, Erik Aronesty asks why his M-of-N Bitcoin multisig scheme is referred to as FUD (Fear, Uncertainty, and Doubt). Andrew Poelstra explains that Aronesty's scheme doesn't work, despite being repeatedly told so, and that Aronesty continues to post incomplete and incoherent versions of it. Poelstra states that Aronesty's scheme is broken.The FUD surrounding a specific Bitcoin multisig scheme is deemed unnecessary. The M-of-N shared public key is generated in advance, and signature fragments can be generated offline without communication between participants. Andrew Poelstra clarifies that there are no non-interactive Schnorr signatures.In the same email exchange, Erik Aronesty notes that his spec cannot be used directly with a Shamir scheme for single-round threshold multisigs. Andrew Poelstra clarifies that (R,s) schemes can still be used online if participants publish the R(share).In various discussions and exchanges, questions are raised regarding the implementation and encoding of public and private keys in the proposed Schnorr signature scheme. Various suggestions and clarifications are provided to address these concerns.There is also a discussion about the optimal order of inputs for hashing in ECDSA signatures, with arguments for both nonce-first and message-first approaches. The debate touches on security benefits, standard hash function design, and optimization techniques.Overall, the context encompasses proposals, discussions, clarifications, and concerns related to implementing 64-byte elliptic curve Schnorr signatures in Bitcoin, including threshold signatures and multisig schemes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Suggestion-for-a-universal-bitcoin-value-scale.xml b/static/bitcoin-dev/Aug_2018/combined_Suggestion-for-a-universal-bitcoin-value-scale.xml index 9a9e554387..5819798b7a 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Suggestion-for-a-universal-bitcoin-value-scale.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Suggestion-for-a-universal-bitcoin-value-scale.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Suggestion for a universal bitcoin value scale - 2023-08-01T23:43:45.667818+00:00 - - Clark Moody 2018-09-12 14:54:15+00:00 - - - damgaard.martin at gmail.com 2018-09-12 06:32:10+00:00 - - - Karl-Johan Alm 2018-09-12 06:13:56+00:00 - - - rhavar at protonmail.com 2018-08-20 23:36:14+00:00 - - - damgaard.martin at gmail.com 2018-08-19 14:21:55+00:00 - - - Rodolfo Novak 2018-08-19 11:42:13+00:00 - - - damgaard.martin at gmail.com 2018-08-18 20:10:04+00:00 - + 2025-09-26T16:01:16.487322+00:00 + python-feedgen + + + [bitcoin-dev] Suggestion for a universal bitcoin value scale damgaard.martin + 2018-08-18T20:10:00.000Z + + + Rodolfo Novak + 2018-08-19T11:42:00.000Z + + + damgaard.martin + 2018-08-19T14:21:00.000Z + + + rhavar + 2018-08-20T23:36:00.000Z + + + Karl-Johan Alm + 2018-09-12T06:13:00.000Z + + + damgaard.martin + 2018-09-12T06:32:00.000Z + + + Clark Moody + 2018-09-12T14:54:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Suggestion for a universal bitcoin value scale - 2023-08-01T23:43:45.667818+00:00 + 2025-09-26T16:01:16.488290+00:00 - In a bitcoin-dev mailing list thread, Clark shares his opinion on the use of Bitcoin on the street. He emphasizes the importance of observing how local wallet software displays bitcoin amounts and suggests letting the standards write themselves over time. Clark acknowledges that the units debate has been ongoing for as long as he has known about Bitcoin, but most tools currently display standard bitcoin amounts.In response to an earlier suggestion for a universal bitcoin value color scale, Karl-Johan Alm raises concerns about the potential for it to be a new attack vector. Martin Damgaard, the author of the initial suggestion, later retracts it due to this feedback and other good remarks. The email thread provides formats for the attached document, including .rtf, .pdf, and .docx.Martin Damgaard, unfamiliar with normal BIP procedures, proposes a universal bitcoin value color scale in an email thread on the Bitcoin Protocol Discussion. His suggestion aims to address the decimal problem identified by the BIP 176 proposal. However, Karl-Johan Alm points out that such a system could be a potential attack vector, as something could be colored to appear as more than it really is if everyone started using this system. After receiving feedback and realizing the immature nature of his suggestion, Damgaard retracts his initial proposal. He thanks the group and expresses all the best wishes. The email thread includes the attached document in three different formats.The email discusses a proposal for a universal bitcoin value color scale to address the issue of dealing with small amounts in the bitcoin denomination. While the idea may be helpful, the author believes that it is not a good solution, as many services or wallets are unlikely to adopt it due to its potential impact on design and cumbersome typing. Instead, the author suggests using BIP76 (Bits Denomination), which has been successful with people of varying levels of familiarity. Additionally, the author proposes writing the bitcoin denomination to 8 decimal places (e.g., 0.00001100 BTC) for improved readability. The email includes an attachment containing the proposal in three different formats.Martin Damgaard, unfamiliar with BIP procedures, contributes to the Bitcoin community by suggesting a universal bitcoin value color scale to address the decimal problem identified by Jimmy Song's BIP 176 proposal. Adán Sánchez de Pedro Crespo suggests that Martin submit his work as a markdown document published somewhere with version control, such as GitHub, to facilitate contributions from others. Martin creates a GitHub version of his suggestion and collects comments on the first version in a remarks-file. He plans to create a new version incorporating the different comments and welcomes help from interested contributors.The context discusses the use of colors in user experience (UX) design and their expected meanings, such as red indicating an error and green indicating a possible action. However, the use of colors can also create issues with legibility for text and accessibility for colorblind individuals. In an email to the bitcoin-dev mailing list, Martin Damgaard suggests a universal bitcoin value color scale to address the decimal problem identified in BIP 176. He acknowledges his unfamiliarity with BIP procedures but follows the example set by Jimmy Song in creating a similar proposal. The attached document is provided in three different formats.Martin Damgaard makes a suggestion to the bitcoin-dev mailing list, proposing a universal bitcoin value color scale to address the decimal problem identified in BIP 176 by Jimmy Song. While he admits his unfamiliarity with normal BIP procedures, he provides his suggestion in three different formats (rtf, pdf, and docx) for the convenience of the recipients. The attached files are available for review, and Martin hopes that the bitcoin-dev community will find his contribution useful. 2018-09-12T14:54:15+00:00 + In a bitcoin-dev mailing list thread, Clark shares his opinion on the use of Bitcoin on the street. He emphasizes the importance of observing how local wallet software displays bitcoin amounts and suggests letting the standards write themselves over time. Clark acknowledges that the units debate has been ongoing for as long as he has known about Bitcoin, but most tools currently display standard bitcoin amounts.In response to an earlier suggestion for a universal bitcoin value color scale, Karl-Johan Alm raises concerns about the potential for it to be a new attack vector. Martin Damgaard, the author of the initial suggestion, later retracts it due to this feedback and other good remarks. The email thread provides formats for the attached document, including .rtf, .pdf, and .docx.Martin Damgaard, unfamiliar with normal BIP procedures, proposes a universal bitcoin value color scale in an email thread on the Bitcoin Protocol Discussion. His suggestion aims to address the decimal problem identified by the BIP 176 proposal. However, Karl-Johan Alm points out that such a system could be a potential attack vector, as something could be colored to appear as more than it really is if everyone started using this system. After receiving feedback and realizing the immature nature of his suggestion, Damgaard retracts his initial proposal. He thanks the group and expresses all the best wishes. The email thread includes the attached document in three different formats.The email discusses a proposal for a universal bitcoin value color scale to address the issue of dealing with small amounts in the bitcoin denomination. While the idea may be helpful, the author believes that it is not a good solution, as many services or wallets are unlikely to adopt it due to its potential impact on design and cumbersome typing. Instead, the author suggests using BIP76 (Bits Denomination), which has been successful with people of varying levels of familiarity. Additionally, the author proposes writing the bitcoin denomination to 8 decimal places (e.g., 0.00001100 BTC) for improved readability. The email includes an attachment containing the proposal in three different formats.Martin Damgaard, unfamiliar with BIP procedures, contributes to the Bitcoin community by suggesting a universal bitcoin value color scale to address the decimal problem identified by Jimmy Song's BIP 176 proposal. Adán Sánchez de Pedro Crespo suggests that Martin submit his work as a markdown document published somewhere with version control, such as GitHub, to facilitate contributions from others. Martin creates a GitHub version of his suggestion and collects comments on the first version in a remarks-file. He plans to create a new version incorporating the different comments and welcomes help from interested contributors.The context discusses the use of colors in user experience (UX) design and their expected meanings, such as red indicating an error and green indicating a possible action. However, the use of colors can also create issues with legibility for text and accessibility for colorblind individuals. In an email to the bitcoin-dev mailing list, Martin Damgaard suggests a universal bitcoin value color scale to address the decimal problem identified in BIP 176. He acknowledges his unfamiliarity with BIP procedures but follows the example set by Jimmy Song in creating a similar proposal. The attached document is provided in three different formats.Martin Damgaard makes a suggestion to the bitcoin-dev mailing list, proposing a universal bitcoin value color scale to address the decimal problem identified in BIP 176 by Jimmy Song. While he admits his unfamiliarity with normal BIP procedures, he provides his suggestion in three different formats (rtf, pdf, and docx) for the convenience of the recipients. The attached files are available for review, and Martin hopes that the bitcoin-dev community will find his contribution useful. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Testnet3-Reest.xml b/static/bitcoin-dev/Aug_2018/combined_Testnet3-Reest.xml index 93efe7b543..dc179bddc1 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Testnet3-Reest.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Testnet3-Reest.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Testnet3 Reest - 2023-08-01T23:45:31.105467+00:00 - - Karl-Johan Alm 2018-09-05 03:00:39+00:00 - - - rhavar at protonmail.com 2018-09-01 14:47:53+00:00 - - - Gregory Maxwell 2018-08-31 00:06:06+00:00 - - - Johnson Lau 2018-08-30 20:44:25+00:00 - - - Jimmy Song 2018-08-30 20:36:16+00:00 - - - Peter Todd 2018-08-30 20:02:39+00:00 - - - shiva sitamraju 2018-08-30 07:28:42+00:00 - + 2025-09-26T16:01:05.980748+00:00 + python-feedgen + + + [bitcoin-dev] Testnet3 Reest shiva sitamraju + 2018-08-30T07:28:00.000Z + + + Peter Todd + 2018-08-30T20:02:00.000Z + + + Jimmy Song + 2018-08-30T20:36:00.000Z + + + Johnson Lau + 2018-08-30T20:44:00.000Z + + + Gregory Maxwell + 2018-08-31T00:06:00.000Z + + + rhavar + 2018-09-01T14:47:00.000Z + + + Karl-Johan Alm + 2018-09-05T03:00:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Testnet3 Reest - 2023-08-01T23:45:31.105467+00:00 + 2025-09-26T16:01:05.981729+00:00 - Gregory Maxwell, a developer at Bitcoin core, has been working on increasing the size of blockindex objects in memory to accommodate signed testnet mode. However, this approach did not prove successful as it increased the size of objects even when not in signed testnet mode. An alternative solution proposed by jtimon involves turning one of the fields, such as the merkel root, into a union with a pointer to a look-aside block index used only in signed block testnet mode. A new implementation is currently being worked on, which includes a global mapping of block hash to signature that is (de)serialized in the block header. The code for this implementation can be found on GitHub.Ryan, a contributor to the bitcoin-dev mailing list, suggested implementing small blocks on testnet to simulate a fee-market-like situation. However, there are concerns about how long the current situation of testnet spam and full blocks will last. Gregory Maxwell proposed creating a signed blocks testnet with a structured reorg pattern as an alternative to the current testnet. This would serve as a middle ground between regtest and a full testnet, providing useful testing opportunities without being subject to the network's whims. Concerns were raised about the increased memory usage due to the larger size of blockindex objects, but this could potentially be addressed by turning one of the fields into a union with a pointer to a look-aside block index.The idea of a signed blocks testnet with a predictable structured reorg pattern was proposed as an alternative to having two testnets with different block sizes. The current testnet is considered too stable when some instability is desired, and too unstable when stability is needed. A signed blocks testnet would provide a middle ground between regtest and a full testnet, allowing for more controlled testing opportunities. Although patches were previously developed for such a testnet in Bitcoin core, concerns about increased memory usage have been raised. However, turning one of the fields into a union with a pointer to a look-aside block index used only in signed block testnet mode could potentially address this issue.On the bitcoin-dev mailing list, a user named shiva sitamraju asked about a potential reset for testnet in the next release due to its length and long sync time. Peter Todd disagreed with this suggestion and advocated for testnet to be a larger blockchain than mainnet to identify size-related issues first. He also suggested using regtest as an alternative for testing, as private regtest blockchains offer better control over block creation. There was a proposal for having two testnets simultaneously, with one having a smaller block size for faster testing. However, Peter Todd favored the idea of a larger testnet. While a public testnet remains useful for referencing transactions in articles, there are various alternatives available for testing purposes, including regtest and private blockchains.In response to a user's question about the lack of multiple testnets, Peter Todd suggested having a larger blockchain for testing instead of resetting the current testnet. He also recommended using regtest as an alternative, as it allows for easy setup and control over block creation. The user mentioned that the current testnet is over 1.4 million blocks long and takes at least 48 hours to fully sync.In an email to the Bitcoin development mailing list, a user raised concerns about the increasing length of the Testnet, which now stands at 1,411,795 blocks, and the significant time required for a full sync. They inquired about the possibility of a reset in the next release or any reasons not to do so. Another member of the mailing list argued in favor of keeping Testnet as a larger blockchain than mainnet to identify size-related issues early on. They also suggested using regtest as a more suitable alternative for testing, as it offers easy setup and better control over block creation. The email was signed by Shiva S, the CEO of Blockonomics, a company specializing in decentralized and permissionless payments.The sender of the message is seeking information regarding the potential for a testnet reset in the next release or any reasons against it. They highlight that the current testnet's length and sync time are causing delays and increased disk overheads for testing purposes. The email is signed by Shiva S, the CEO of Blockonomics, and includes links to their Telegram group and Welcome Guide for further engagement. 2018-09-05T03:00:39+00:00 + Gregory Maxwell, a developer at Bitcoin core, has been working on increasing the size of blockindex objects in memory to accommodate signed testnet mode. However, this approach did not prove successful as it increased the size of objects even when not in signed testnet mode. An alternative solution proposed by jtimon involves turning one of the fields, such as the merkel root, into a union with a pointer to a look-aside block index used only in signed block testnet mode. A new implementation is currently being worked on, which includes a global mapping of block hash to signature that is (de)serialized in the block header. The code for this implementation can be found on GitHub.Ryan, a contributor to the bitcoin-dev mailing list, suggested implementing small blocks on testnet to simulate a fee-market-like situation. However, there are concerns about how long the current situation of testnet spam and full blocks will last. Gregory Maxwell proposed creating a signed blocks testnet with a structured reorg pattern as an alternative to the current testnet. This would serve as a middle ground between regtest and a full testnet, providing useful testing opportunities without being subject to the network's whims. Concerns were raised about the increased memory usage due to the larger size of blockindex objects, but this could potentially be addressed by turning one of the fields into a union with a pointer to a look-aside block index.The idea of a signed blocks testnet with a predictable structured reorg pattern was proposed as an alternative to having two testnets with different block sizes. The current testnet is considered too stable when some instability is desired, and too unstable when stability is needed. A signed blocks testnet would provide a middle ground between regtest and a full testnet, allowing for more controlled testing opportunities. Although patches were previously developed for such a testnet in Bitcoin core, concerns about increased memory usage have been raised. However, turning one of the fields into a union with a pointer to a look-aside block index used only in signed block testnet mode could potentially address this issue.On the bitcoin-dev mailing list, a user named shiva sitamraju asked about a potential reset for testnet in the next release due to its length and long sync time. Peter Todd disagreed with this suggestion and advocated for testnet to be a larger blockchain than mainnet to identify size-related issues first. He also suggested using regtest as an alternative for testing, as private regtest blockchains offer better control over block creation. There was a proposal for having two testnets simultaneously, with one having a smaller block size for faster testing. However, Peter Todd favored the idea of a larger testnet. While a public testnet remains useful for referencing transactions in articles, there are various alternatives available for testing purposes, including regtest and private blockchains.In response to a user's question about the lack of multiple testnets, Peter Todd suggested having a larger blockchain for testing instead of resetting the current testnet. He also recommended using regtest as an alternative, as it allows for easy setup and control over block creation. The user mentioned that the current testnet is over 1.4 million blocks long and takes at least 48 hours to fully sync.In an email to the Bitcoin development mailing list, a user raised concerns about the increasing length of the Testnet, which now stands at 1,411,795 blocks, and the significant time required for a full sync. They inquired about the possibility of a reset in the next release or any reasons not to do so. Another member of the mailing list argued in favor of keeping Testnet as a larger blockchain than mainnet to identify size-related issues early on. They also suggested using regtest as a more suitable alternative for testing, as it offers easy setup and better control over block creation. The email was signed by Shiva S, the CEO of Blockonomics, a company specializing in decentralized and permissionless payments.The sender of the message is seeking information regarding the potential for a testnet reset in the next release or any reasons against it. They highlight that the current testnet's length and sync time are causing delays and increased disk overheads for testing purposes. The email is signed by Shiva S, the CEO of Blockonomics, and includes links to their Telegram group and Welcome Guide for further engagement. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_Witness-serialization-in-PSBT-non-witness-UTXOs.xml b/static/bitcoin-dev/Aug_2018/combined_Witness-serialization-in-PSBT-non-witness-UTXOs.xml index 81c95dc021..b29e981ca4 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Witness-serialization-in-PSBT-non-witness-UTXOs.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Witness-serialization-in-PSBT-non-witness-UTXOs.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Witness serialization in PSBT non-witness UTXOs - 2023-08-01T23:43:05.724825+00:00 - - Gregory Maxwell 2018-08-13 20:39:38+00:00 - - - Achow101 2018-08-13 20:32:33+00:00 - - - Pieter Wuille 2018-08-13 18:56:41+00:00 - + 2025-09-26T16:00:59.673206+00:00 + python-feedgen + + + [bitcoin-dev] Witness serialization in PSBT non-witness UTXOs Pieter Wuille + 2018-08-13T18:56:00.000Z + + + Achow101 + 2018-08-13T20:32:00.000Z + + + Gregory Maxwell + 2018-08-13T20:39:00.000Z + + - python-feedgen + 2 Combined summary - Witness serialization in PSBT non-witness UTXOs - 2023-08-01T23:43:05.725831+00:00 + 2025-09-26T16:00:59.673767+00:00 - Bitcoin developer Pieter Wuille has proposed an update to the Bitcoin Improvement Proposal (BIP) 174 specification regarding non-witness unspent transaction outputs (UTXOs). Currently, the specification requires these transactions to be serialized in network format. However, Wuille argues that this approach is problematic for two reasons. Firstly, he states that the inclusion of witness data, even if present in the spent transaction, is irrelevant to PSBT (partially signed bitcoin transactions). Secondly, the term "network format" is ambiguous and could lead to compatibility issues in the future.To address these concerns, Wuille suggests updating the specification to require non-witness UTXOs to be serialized without the witness. If this is not feasible, he proposes explicitly stating whether the witness is required or not. Another developer, Andrew Chow, supports Wuille's proposal and adds that specifying non-witness UTXOs as "witness or non-witness" serialization would ensure backward and forward compatibility.The group involved in the discussion agrees that clarifying the specification is crucial for maintaining compatibility with existing signers and ensuring forward compatibility. They believe that the inclusion of witness data in non-witness UTXOs is unnecessary for PSBT and that the term "network format" should be clarified to avoid potential compatibility issues in the future.Pieter Wuille, a Bitcoin developer and contributor to BIP174, has raised concerns about the current specification for non-witness UTXOs. He argues that including witness data is irrelevant to PSBT and that the term "network format" is ambiguous. He proposes updating the specification to serialize non-witness UTXOs without the witness or explicitly specifying whether the witness is required. The group agrees that clarifying the specification is necessary for compatibility and seeks opinions on the matter. 2018-08-13T20:39:38+00:00 + Bitcoin developer Pieter Wuille has proposed an update to the Bitcoin Improvement Proposal (BIP) 174 specification regarding non-witness unspent transaction outputs (UTXOs). Currently, the specification requires these transactions to be serialized in network format. However, Wuille argues that this approach is problematic for two reasons. Firstly, he states that the inclusion of witness data, even if present in the spent transaction, is irrelevant to PSBT (partially signed bitcoin transactions). Secondly, the term "network format" is ambiguous and could lead to compatibility issues in the future.To address these concerns, Wuille suggests updating the specification to require non-witness UTXOs to be serialized without the witness. If this is not feasible, he proposes explicitly stating whether the witness is required or not. Another developer, Andrew Chow, supports Wuille's proposal and adds that specifying non-witness UTXOs as "witness or non-witness" serialization would ensure backward and forward compatibility.The group involved in the discussion agrees that clarifying the specification is crucial for maintaining compatibility with existing signers and ensuring forward compatibility. They believe that the inclusion of witness data in non-witness UTXOs is unnecessary for PSBT and that the term "network format" should be clarified to avoid potential compatibility issues in the future.Pieter Wuille, a Bitcoin developer and contributor to BIP174, has raised concerns about the current specification for non-witness UTXOs. He argues that including witness data is irrelevant to PSBT and that the term "network format" is ambiguous. He proposes updating the specification to serialize non-witness UTXOs without the witness or explicitly specifying whether the witness is required. The group agrees that clarifying the specification is necessary for compatibility and seeks opinions on the matter. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_bitcoin-transactions.xml b/static/bitcoin-dev/Aug_2018/combined_bitcoin-transactions.xml index bd7720d517..615afd6edb 100644 --- a/static/bitcoin-dev/Aug_2018/combined_bitcoin-transactions.xml +++ b/static/bitcoin-dev/Aug_2018/combined_bitcoin-transactions.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - bitcoin-transactions - 2023-08-01T23:41:18.312752+00:00 - - hth lipsch 2018-08-09 08:38:09+00:00 - - - Aymeric Vitte 2018-08-01 09:58:43+00:00 - - - Marcel Jamin 2018-08-01 05:45:54+00:00 - - - Aymeric Vitte 2018-07-31 11:25:48+00:00 - + 2025-09-26T16:01:10.194391+00:00 + python-feedgen + + + [bitcoin-dev] bitcoin-transactions Aymeric Vitte + 2018-07-31T11:25:00.000Z + + + Marcel Jamin + 2018-08-01T05:45:00.000Z + + + Aymeric Vitte + 2018-08-01T09:58:00.000Z + + + hth lipsch + 2018-08-09T08:38:00.000Z + + - python-feedgen + 2 Combined summary - bitcoin-transactions - 2023-08-01T23:41:18.312752+00:00 + 2025-09-26T16:01:10.195079+00:00 - The email thread between Aymeric Vitte and Marcel Jamin discusses the issue of online services that ask for private keys and seeds in exchange for "free" coins. Jamin strongly advises against publishing a service that requires users to provide their private keys, as it poses a significant security risk if the server gets compromised. He also argues that moving coins by oneself is not the correct approach if the server is involved. In response, Vitte warns that people cannot resist the temptation of obtaining "free" coins by giving away their private keys. He mentions his web interface tool for bitcoin-transactions, which allows users to move their coins without any fees. However, he acknowledges that it is currently not advisable to use private keys on this tool. He suggests that an offline tool would be ideal if there is some incentive to do so. Vitte claims that his web interface tool, located at https://peersm.com/wallet, is the only online tool that can convert bech32 addresses, decode redeem scripts, and create transactions on its own. He emphasizes that using private keys on this platform is not recommended until it becomes an offline tool. The discussion also touches upon the issue of invalid bech32 addresses from Electrum wallets after segwit, which has caused confusion among users. Overall, Vitte believes that a safe and secure tool like his web interface would be a positive step forward for mainstream bitcoin users who value efficiency and simplicity. In addition, he provides links to various projects he is involved in on GitHub, including Bitcoin wallets made simple, Zcash wallets made simple, Peersm, torrent-live, node-Tor, and GitHub. 2018-08-09T08:38:09+00:00 + The email thread between Aymeric Vitte and Marcel Jamin discusses the issue of online services that ask for private keys and seeds in exchange for "free" coins. Jamin strongly advises against publishing a service that requires users to provide their private keys, as it poses a significant security risk if the server gets compromised. He also argues that moving coins by oneself is not the correct approach if the server is involved. In response, Vitte warns that people cannot resist the temptation of obtaining "free" coins by giving away their private keys. He mentions his web interface tool for bitcoin-transactions, which allows users to move their coins without any fees. However, he acknowledges that it is currently not advisable to use private keys on this tool. He suggests that an offline tool would be ideal if there is some incentive to do so. Vitte claims that his web interface tool, located at https://peersm.com/wallet, is the only online tool that can convert bech32 addresses, decode redeem scripts, and create transactions on its own. He emphasizes that using private keys on this platform is not recommended until it becomes an offline tool. The discussion also touches upon the issue of invalid bech32 addresses from Electrum wallets after segwit, which has caused confusion among users. Overall, Vitte believes that a safe and secure tool like his web interface would be a positive step forward for mainstream bitcoin users who value efficiency and simplicity. In addition, he provides links to various projects he is involved in on GitHub, including Bitcoin wallets made simple, Zcash wallets made simple, Peersm, torrent-live, node-Tor, and GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2018/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml b/static/bitcoin-dev/Aug_2018/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml index c1019a1c72..51d1041973 100644 --- a/static/bitcoin-dev/Aug_2018/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml +++ b/static/bitcoin-dev/Aug_2018/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - bustapay BIP :: a practical sender/receiver coinjoin protocol - 2023-08-01T23:47:19.394119+00:00 - - James MacWhyte 2019-01-30 20:58:03+00:00 - - - ZmnSCPxj 2019-01-30 08:34:46+00:00 - - - rhavar at protonmail.com 2019-01-30 02:46:47+00:00 - - - James MacWhyte 2019-01-30 02:06:30+00:00 - - - Adam Gibson 2019-01-28 13:19:09+00:00 - - - ZmnSCPxj 2019-01-28 04:14:41+00:00 - - - rhavar at protonmail.com 2019-01-27 22:11:47+00:00 - - - James MacWhyte 2019-01-27 19:42:03+00:00 - - - rhavar at protonmail.com 2019-01-27 19:24:11+00:00 - - - Adam Gibson 2019-01-27 12:20:54+00:00 - - - rhavar at protonmail.com 2019-01-27 07:36:59+00:00 - - - Adam Gibson 2019-01-25 14:47:34+00:00 - - - rhavar at protonmail.com 2018-09-10 15:49:29+00:00 - - - Sjors Provoost 2018-09-10 12:30:46+00:00 - - - rhavar at protonmail.com 2018-08-30 20:24:58+00:00 - + 2025-09-26T16:01:08.101067+00:00 + python-feedgen + + + [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol rhavar + 2018-08-30T20:24:00.000Z + + + Sjors Provoost + 2018-09-10T12:30:00.000Z + + + rhavar + 2018-09-10T15:49:00.000Z + + + Adam Gibson + 2019-01-25T14:47:00.000Z + + + rhavar + 2019-01-27T07:36:00.000Z + + + Adam Gibson + 2019-01-27T12:20:00.000Z + + + rhavar + 2019-01-27T19:24:00.000Z + + + James MacWhyte + 2019-01-27T19:42:00.000Z + + + rhavar + 2019-01-27T22:11:00.000Z + + + ZmnSCPxj + 2019-01-28T04:14:00.000Z + + + Adam Gibson + 2019-01-28T13:19:00.000Z + + + James MacWhyte + 2019-01-30T02:06:00.000Z + + + rhavar + 2019-01-30T02:46:00.000Z + + + ZmnSCPxj + 2019-01-30T08:34:00.000Z + + + James MacWhyte + 2019-01-30T20:58:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - bustapay BIP :: a practical sender/receiver coinjoin protocol - 2023-08-01T23:47:19.395084+00:00 + 2025-09-26T16:01:08.102697+00:00 - The conversation revolves around the potential attack on a transaction template and the weaknesses identified in the proposed protocol. The sender suggests that refusing to sign the final transaction can still propagate the template transaction, but the real attack would be if the sender double-spends it before propagation. The receiver acknowledges the weaknesses and agrees that there may not be a better solution. They also understand that implementers unable to integrate signing and UTXO validation are unlikely to implement this feature.Another discussion focuses on the issues faced by a "PayJoin-only" merchant who repeatedly uses a single UTXO. This could lead to an imbalance of funds violating UIH2. To avoid this, it is suggested to have a mix of PayJoin and non-PayJoin transactions. The concept of Bustapay is introduced, which allows for PayJoin transactions with a single UTXO. However, repeated use of the same UTXO can still suggest a naive approach. A heuristic is proposed to randomly flip coins for each UTXO owned to determine when to use PayJoin or not, although no formal analysis has been conducted.James MacWhyte expresses concerns about the complexity of the Bustapay spec and questions the effectiveness of the anti-spy feature. He suggests simplifying the protocol by dropping the signing requirement in the first step. However, he acknowledges the transaction malleability issues that may arise. MacWhyte concludes that the only viable way to use Bustapay with increased privacy would be to pay the first part of the invoice in lightning and then pay the rest with Bustapay, but admits that this approach has too many moving parts and implementation difficulties.ZmnSCPxj proposes solutions to address the UIH2 issue, suggesting standard coin selection algorithms and the inclusion of contributed inputs. AdamISZ raises concerns about mismatched input sizes and the concentration of funds in a single UTXO. Belcher suggests having a mix of PayJoin and non-PayJoin transactions to avoid violating UIH2.The conversation also discusses the steganographic hiding of transaction ownership and the adoption of the PayJoin protocol. Members debate the practicality and complexity of the protocol, as well as the need for versioning and inclusion of PSBT/BIP174. The importance of explicit transaction details like version and locktime is also debated.The implementation of Bustapay is discussed, including its integration into BtcPayServer and the need for a standardized format for moving UTXOs between wallets. Concerns are raised about wallets violating standards and the need for uniformity in Bitcoin transactions.Ryan Havar acknowledges mistakes in his recent BIP 0079 proposal and agrees with Adam Gibson's opinion on steganographic hiding of transaction inputs. He suggests better support for moving UTXOs between wallets through a standardized format. Adam emphasizes the need for consensus on protocols, versioning, and the inclusion of PSBT/BIP174. He suggests avoiding unnecessary inputs and making the payjoin transaction appear as an ordinary payment. Adam also highlights the value of being explicit about simple things like transaction version and locktime.In conclusion, the discussions revolve around the potential attacks, weaknesses, and proposed solutions in the Bustapay protocol. There are debates on issues such as the concentration of funds, UIH2, steganographic hiding, standardization, and protocol versioning. The importance of simplifying the process, ensuring privacy, and protecting both senders and receivers is emphasized.Ryan and Adam Gibson discussed the standardization of PayJoin as a transaction that breaks the assumption of common ownership of transaction inputs. They talked about various aspects such as protocol versioning, using PSBT/BIP174, version/locktime, and avoiding non-payment "Unnecessary Input Heuristic."The proposal, known as Bustapay, aims to address fungibility concerns and blockchain analysis by creating indistinguishable Bitcoin transactions. The sender creates a fully valid, signed "template transaction" and gives it to the receiver through an HTTP POST request. The receiver adds their own input and increases the output that pays themselves by the contributed input amount. The partial transaction is then sent back to the sender to sign and propagated on the Bitcoin network by the receiver.Implementing Bustapay payments requires receivers to be aware of implementation notes, including checking if the transaction is suitable for the mempool with testmempoolaccept in Bitcoin Core 0.17. Sending applications should validate the HTTP response to ensure no unexpected changes have been made to the transaction.A proposal has been suggested to standardize the Bustapay protocol, which allows for hiding transaction information and increasing privacy. Steganographic hiding is considered worth pursuing, as Joinmarket and Samourai have already begun implementing the protocol. The aim is to create a cross-wallet standard that can be included in projects like BTCPayServer. Generic comments on protocol versioning, naming conventions, and the need for x-wallet compatibility standards are discussed.The Bustapay payment system involves several steps 2019-01-30T20:58:03+00:00 + The conversation revolves around the potential attack on a transaction template and the weaknesses identified in the proposed protocol. The sender suggests that refusing to sign the final transaction can still propagate the template transaction, but the real attack would be if the sender double-spends it before propagation. The receiver acknowledges the weaknesses and agrees that there may not be a better solution. They also understand that implementers unable to integrate signing and UTXO validation are unlikely to implement this feature.Another discussion focuses on the issues faced by a "PayJoin-only" merchant who repeatedly uses a single UTXO. This could lead to an imbalance of funds violating UIH2. To avoid this, it is suggested to have a mix of PayJoin and non-PayJoin transactions. The concept of Bustapay is introduced, which allows for PayJoin transactions with a single UTXO. However, repeated use of the same UTXO can still suggest a naive approach. A heuristic is proposed to randomly flip coins for each UTXO owned to determine when to use PayJoin or not, although no formal analysis has been conducted.James MacWhyte expresses concerns about the complexity of the Bustapay spec and questions the effectiveness of the anti-spy feature. He suggests simplifying the protocol by dropping the signing requirement in the first step. However, he acknowledges the transaction malleability issues that may arise. MacWhyte concludes that the only viable way to use Bustapay with increased privacy would be to pay the first part of the invoice in lightning and then pay the rest with Bustapay, but admits that this approach has too many moving parts and implementation difficulties.ZmnSCPxj proposes solutions to address the UIH2 issue, suggesting standard coin selection algorithms and the inclusion of contributed inputs. AdamISZ raises concerns about mismatched input sizes and the concentration of funds in a single UTXO. Belcher suggests having a mix of PayJoin and non-PayJoin transactions to avoid violating UIH2.The conversation also discusses the steganographic hiding of transaction ownership and the adoption of the PayJoin protocol. Members debate the practicality and complexity of the protocol, as well as the need for versioning and inclusion of PSBT/BIP174. The importance of explicit transaction details like version and locktime is also debated.The implementation of Bustapay is discussed, including its integration into BtcPayServer and the need for a standardized format for moving UTXOs between wallets. Concerns are raised about wallets violating standards and the need for uniformity in Bitcoin transactions.Ryan Havar acknowledges mistakes in his recent BIP 0079 proposal and agrees with Adam Gibson's opinion on steganographic hiding of transaction inputs. He suggests better support for moving UTXOs between wallets through a standardized format. Adam emphasizes the need for consensus on protocols, versioning, and the inclusion of PSBT/BIP174. He suggests avoiding unnecessary inputs and making the payjoin transaction appear as an ordinary payment. Adam also highlights the value of being explicit about simple things like transaction version and locktime.In conclusion, the discussions revolve around the potential attacks, weaknesses, and proposed solutions in the Bustapay protocol. There are debates on issues such as the concentration of funds, UIH2, steganographic hiding, standardization, and protocol versioning. The importance of simplifying the process, ensuring privacy, and protecting both senders and receivers is emphasized.Ryan and Adam Gibson discussed the standardization of PayJoin as a transaction that breaks the assumption of common ownership of transaction inputs. They talked about various aspects such as protocol versioning, using PSBT/BIP174, version/locktime, and avoiding non-payment "Unnecessary Input Heuristic."The proposal, known as Bustapay, aims to address fungibility concerns and blockchain analysis by creating indistinguishable Bitcoin transactions. The sender creates a fully valid, signed "template transaction" and gives it to the receiver through an HTTP POST request. The receiver adds their own input and increases the output that pays themselves by the contributed input amount. The partial transaction is then sent back to the sender to sign and propagated on the Bitcoin network by the receiver.Implementing Bustapay payments requires receivers to be aware of implementation notes, including checking if the transaction is suitable for the mempool with testmempoolaccept in Bitcoin Core 0.17. Sending applications should validate the HTTP response to ensure no unexpected changes have been made to the transaction.A proposal has been suggested to standardize the Bustapay protocol, which allows for hiding transaction information and increasing privacy. Steganographic hiding is considered worth pursuing, as Joinmarket and Samourai have already begun implementing the protocol. The aim is to create a cross-wallet standard that can be included in projects like BTCPayServer. Generic comments on protocol versioning, naming conventions, and the need for x-wallet compatibility standards are discussed.The Bustapay payment system involves several steps - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_-Meta-bitcoin-dev-moderation.xml b/static/bitcoin-dev/Aug_2019/combined_-Meta-bitcoin-dev-moderation.xml index bebfae8aef..a119963311 100644 --- a/static/bitcoin-dev/Aug_2019/combined_-Meta-bitcoin-dev-moderation.xml +++ b/static/bitcoin-dev/Aug_2019/combined_-Meta-bitcoin-dev-moderation.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - [Meta] bitcoin-dev moderation - 2023-08-02T01:14:30.271424+00:00 - - Bryan Bishop 2019-08-02 11:43:27+00:00 - - - Emil Engler 2019-08-01 19:47:40+00:00 - + 2025-09-26T15:55:37.475572+00:00 + python-feedgen + + + [bitcoin-dev] [Meta] bitcoin-dev moderation Emil Engler + 2019-08-01T19:47:00.000Z + + + Bryan Bishop + 2019-08-02T11:43:00.000Z + + - python-feedgen + 2 Combined summary - [Meta] bitcoin-dev moderation - 2023-08-02T01:14:30.271424+00:00 + 2025-09-26T15:55:37.476004+00:00 - During a recent bitcoin-dev email thread, concerns were raised about the slow moderation process for the mailing list. Emil Engler expressed frustration that it takes more than 24 hours for an email to be approved and posted on the list. The current strategy of having moderators in different time zones to cover sleep shifts or disruptions has not been effective. To address this issue, Jonas Schnelli suggested adding more moderators to reduce the lag in moderation and make debates less cumbersome.Engler also proposed a solution where people who have previously contributed emails to the mailing list would not require approval for future emails. The idea is that the number of previous emails, denoted as "n," would determine whether approval is needed. However, it is unclear if this feature already exists or if it needs to be implemented.One challenge that has been identified is an active software vulnerability that requires moderation to be enabled. Additionally, the current version of mailman, the software used for managing the mailing list, is unmaintained. This lack of maintenance has resulted in downtime and missing emails that never reached the moderation queue.The Linux Foundation, which oversees the bitcoin-core-dev IRC meeting, is migrating away from or abandoning the email protocol. As a result, they are becoming less willing to provide backend infrastructure support. This lack of support has contributed to the issues with the moderation process.Despite these challenges with email as a protocol, Bryan shared his contact information for anyone needing to get in touch. This indicates that alternative means of communication may be necessary due to the ongoing issues with the mailing list.In the latest #bitcoin-core-dev IRC meeting, the topic of the slow mailing list moderation process was discussed. It was decided that further discussion on this matter would be conducted via the mailing list itself, as it is considered the most appropriate platform for such conversations.The conversation ended with greetings from Emil Engler and an attachment of pEpkey.asc, which is an application/pgp-keys file. This suggests that Engler is using Pretty Easy Privacy (pEp) encryption to secure his email communications.Overall, the discussion highlighted the need for improvements in the moderation process for the bitcoin-dev mailing list due to delays, software vulnerabilities, and lack of maintenance. The suggestion of adding more moderators and addressing the approval requirement for previous contributors were put forward as potential solutions. However, it remains unclear whether these proposals will be implemented. 2019-08-02T11:43:27+00:00 + During a recent bitcoin-dev email thread, concerns were raised about the slow moderation process for the mailing list. Emil Engler expressed frustration that it takes more than 24 hours for an email to be approved and posted on the list. The current strategy of having moderators in different time zones to cover sleep shifts or disruptions has not been effective. To address this issue, Jonas Schnelli suggested adding more moderators to reduce the lag in moderation and make debates less cumbersome.Engler also proposed a solution where people who have previously contributed emails to the mailing list would not require approval for future emails. The idea is that the number of previous emails, denoted as "n," would determine whether approval is needed. However, it is unclear if this feature already exists or if it needs to be implemented.One challenge that has been identified is an active software vulnerability that requires moderation to be enabled. Additionally, the current version of mailman, the software used for managing the mailing list, is unmaintained. This lack of maintenance has resulted in downtime and missing emails that never reached the moderation queue.The Linux Foundation, which oversees the bitcoin-core-dev IRC meeting, is migrating away from or abandoning the email protocol. As a result, they are becoming less willing to provide backend infrastructure support. This lack of support has contributed to the issues with the moderation process.Despite these challenges with email as a protocol, Bryan shared his contact information for anyone needing to get in touch. This indicates that alternative means of communication may be necessary due to the ongoing issues with the mailing list.In the latest #bitcoin-core-dev IRC meeting, the topic of the slow mailing list moderation process was discussed. It was decided that further discussion on this matter would be conducted via the mailing list itself, as it is considered the most appropriate platform for such conversations.The conversation ended with greetings from Emil Engler and an attachment of pEpkey.asc, which is an application/pgp-keys file. This suggests that Engler is using Pretty Easy Privacy (pEp) encryption to secure his email communications.Overall, the discussion highlighted the need for improvements in the moderation process for the bitcoin-dev mailing list due to delays, software vulnerabilities, and lack of maintenance. The suggestion of adding more moderators and addressing the approval requirement for previous contributors were put forward as potential solutions. However, it remains unclear whether these proposals will be implemented. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_32-byte-public-keys-in-Schnorr-and-Taproot.xml b/static/bitcoin-dev/Aug_2019/combined_32-byte-public-keys-in-Schnorr-and-Taproot.xml index 48bba6f12d..87a096dce1 100644 --- a/static/bitcoin-dev/Aug_2019/combined_32-byte-public-keys-in-Schnorr-and-Taproot.xml +++ b/static/bitcoin-dev/Aug_2019/combined_32-byte-public-keys-in-Schnorr-and-Taproot.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - 32-byte public keys in Schnorr and Taproot - 2023-08-02T01:16:16.596719+00:00 - - Karl-Johan Alm 2019-08-11 06:08:48+00:00 - - - Christopher Allen 2019-08-09 18:37:13+00:00 - - - Pieter Wuille 2019-08-09 18:16:29+00:00 - + 2025-09-26T15:55:20.442332+00:00 + python-feedgen + + + [bitcoin-dev] 32-byte public keys in Schnorr and Taproot Pieter Wuille + 2019-08-09T18:16:00.000Z + + + Christopher Allen + 2019-08-09T18:37:00.000Z + + + Karl-Johan Alm + 2019-08-11T06:08:00.000Z + + - python-feedgen + 2 Combined summary - 32-byte public keys in Schnorr and Taproot - 2023-08-02T01:16:16.596719+00:00 + 2025-09-26T15:55:20.442860+00:00 - In a Bitcoin developer mailing list, a suggestion has been made to drop the Y oddness bit in the witness program for Taproot outputs. This change would not affect security and would prevent Taproot outputs from being more expensive than v0 P2WSH. It would also allow for future changes that may still require the additional byte. As part of exploring this option, it has been found that introducing a type of 32-byte public keys in bip-schnorr would be the cleanest approach. This raises the question of whether 33-byte public keys are necessary at all. While bip-schnorr public keys would not be exactly the same as ECDSA public keys if this change is implemented, all derivation logic would still apply. Under this modification, the Q point in bip-taproot (the one going in the scriptPubKey) would follow the 32-byte pubkey encoding instead of needing a 33rd byte. The P point in bip-taproot (the internal key revealed during the script path) would become a 32-byte public key. All public keys inside bip-tapscript would also be 32-bytes long. If desired, the "upgradable public key" construction in bip-tapscript can be retained by triggering based on the length of public keys. However, opinions are being sought about whether it is worth making this change to bip-schnorr at this stage, considering that it has already been in use for some time. While it is possible to keep verification compatible by hashing the implied "even" byte inside the scheme, which commits to the pubkey, if changes are to be made, it is best to do so as cleanly as possible and drop that byte as well. In conclusion, this is a discussion within the Bitcoin developer community about modifying bip-schnorr to only define 32-byte public keys and how it would impact Taproot outputs and bip-tapscript. Pieter Wuille suggests making the change cleanly and dropping the extra byte, while Christopher Allen proposes considering a non-binary format for sharing public keys. 2019-08-11T06:08:48+00:00 + In a Bitcoin developer mailing list, a suggestion has been made to drop the Y oddness bit in the witness program for Taproot outputs. This change would not affect security and would prevent Taproot outputs from being more expensive than v0 P2WSH. It would also allow for future changes that may still require the additional byte. As part of exploring this option, it has been found that introducing a type of 32-byte public keys in bip-schnorr would be the cleanest approach. This raises the question of whether 33-byte public keys are necessary at all. While bip-schnorr public keys would not be exactly the same as ECDSA public keys if this change is implemented, all derivation logic would still apply. Under this modification, the Q point in bip-taproot (the one going in the scriptPubKey) would follow the 32-byte pubkey encoding instead of needing a 33rd byte. The P point in bip-taproot (the internal key revealed during the script path) would become a 32-byte public key. All public keys inside bip-tapscript would also be 32-bytes long. If desired, the "upgradable public key" construction in bip-tapscript can be retained by triggering based on the length of public keys. However, opinions are being sought about whether it is worth making this change to bip-schnorr at this stage, considering that it has already been in use for some time. While it is possible to keep verification compatible by hashing the implied "even" byte inside the scheme, which commits to the pubkey, if changes are to be made, it is best to do so as cleanly as possible and drop that byte as well. In conclusion, this is a discussion within the Bitcoin developer community about modifying bip-schnorr to only define 32-byte public keys and how it would impact Taproot outputs and bip-tapscript. Pieter Wuille suggests making the change cleanly and dropping the extra byte, while Christopher Allen proposes considering a non-binary format for sharing public keys. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Add-a-moving-checkpoint-to-the-Bitcoin-protocol.xml b/static/bitcoin-dev/Aug_2019/combined_Add-a-moving-checkpoint-to-the-Bitcoin-protocol.xml index 20c96441ee..fe8fa8bdd5 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Add-a-moving-checkpoint-to-the-Bitcoin-protocol.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Add-a-moving-checkpoint-to-the-Bitcoin-protocol.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Add a moving checkpoint to the Bitcoin protocol - 2023-08-02T01:14:06.767072+00:00 - - Kenshiro [] 2019-08-03 10:35:51+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2019-08-03 00:51:12+00:00 - - - Kenshiro [] 2019-08-02 13:08:44+00:00 - - - Ethan Heilman 2019-08-02 12:19:03+00:00 - - - Kenshiro [] 2019-08-01 10:17:56+00:00 - - - Alistair Mann 2019-07-31 23:28:56+00:00 - - - Kenshiro [] 2019-07-31 14:53:25+00:00 - - - Kenshiro [] 2019-07-31 14:40:50+00:00 - - - Alistair Mann 2019-07-31 13:59:33+00:00 - - - Kenshiro [] 2019-07-31 12:28:58+00:00 - + 2025-09-26T15:55:43.864559+00:00 + python-feedgen + + + [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Kenshiro [] + 2019-07-31T12:28:00.000Z + + + Alistair Mann + 2019-07-31T13:59:00.000Z + + + Kenshiro [] + 2019-07-31T14:40:00.000Z + + + Kenshiro [] + 2019-07-31T14:53:00.000Z + + + Alistair Mann + 2019-07-31T23:28:00.000Z + + + Kenshiro [] + 2019-08-01T10:17:00.000Z + + + Ethan Heilman + 2019-08-02T12:19:00.000Z + + + Kenshiro [] + 2019-08-02T13:08:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2019-08-03T00:51:00.000Z + + + Kenshiro [] + 2019-08-03T10:35:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Add a moving checkpoint to the Bitcoin protocol - 2023-08-02T01:14:06.767072+00:00 + 2025-09-26T15:55:43.865734+00:00 - A proposal has been made to add a "moving checkpoint" to the Bitcoin protocol, similar to the one implemented in NXT coin. The rule would make the blockchain truly immutable after a certain number of blocks, even during a 51% attack. However, concerns have been raised about how this rule would handle a potential state-sponsored network split lasting longer than the specified block limit.To address these concerns, an additional rule has been suggested. If a node detects a fork with both sides having a length greater than 144 blocks, it would halt and request user intervention to determine which chain to follow. This is seen as a safer way to handle long network splits.However, critics argue that this rule could make Bitcoin more vulnerable to 51% attacks. To mitigate this vulnerability, a limit of X blocks has been proposed. The length of X blocks could be measured as the number of blocks multiplied by the average block difficulty, taking into account any difficulty adjustment that occurs over time.Under this proposed rule, the moving checkpoint would only be valid if the difference in blocks between the main chain and the new fork is smaller than X blocks, such as the blocks generated in 3 days. If a node sees a fork longer than its main chain, and the fork has at least X blocks more than the main chain, the node would ignore the moving checkpoint and follow the longest chain.Two possible scenarios are considered: a 51% attack where older blocks are protected against history rewrites for at least 3 days, allowing developers to release an emergency update with a different mining algorithm to counter the attack; and a network split where if the split is older than a certain number of blocks, there would be two permanent forks, but in 3 days or more, the blockchain heights would differ by more than X blocks, resulting in the abandonment of the losing chain.The discussion also addresses concerns about how a netsplit lasting longer than the block limit would be handled. It is suggested that the community would detect it before reaching the limit, allowing nodes to stop until the netsplit is fixed. In extreme cases where no one notices the split for more than the block limit and there are two permanent forks longer than the limit, nodes from one branch could delete their local history to join the other branch.However, critics argue that implementing a moving checkpoint rule as described could make Bitcoin more vulnerable to 51% attacks. They believe that the security of the rule could be further improved by making the number of blocks a fork must reach to halt the network proportional to the difference in time between the timestamp prior to the fork and the current time. Despite these discussions, it should be noted that the proposal is still under consideration and not yet adopted by the Bitcoin protocol.Overall, the proposal for a "moving checkpoint" in the Bitcoin protocol aims to improve security and address concerns regarding network splits and 51% attacks. However, there are ongoing debates about its effectiveness and potential vulnerabilities, and further discussions and analysis are needed before any implementation decisions are made. 2019-08-03T10:35:51+00:00 + A proposal has been made to add a "moving checkpoint" to the Bitcoin protocol, similar to the one implemented in NXT coin. The rule would make the blockchain truly immutable after a certain number of blocks, even during a 51% attack. However, concerns have been raised about how this rule would handle a potential state-sponsored network split lasting longer than the specified block limit.To address these concerns, an additional rule has been suggested. If a node detects a fork with both sides having a length greater than 144 blocks, it would halt and request user intervention to determine which chain to follow. This is seen as a safer way to handle long network splits.However, critics argue that this rule could make Bitcoin more vulnerable to 51% attacks. To mitigate this vulnerability, a limit of X blocks has been proposed. The length of X blocks could be measured as the number of blocks multiplied by the average block difficulty, taking into account any difficulty adjustment that occurs over time.Under this proposed rule, the moving checkpoint would only be valid if the difference in blocks between the main chain and the new fork is smaller than X blocks, such as the blocks generated in 3 days. If a node sees a fork longer than its main chain, and the fork has at least X blocks more than the main chain, the node would ignore the moving checkpoint and follow the longest chain.Two possible scenarios are considered: a 51% attack where older blocks are protected against history rewrites for at least 3 days, allowing developers to release an emergency update with a different mining algorithm to counter the attack; and a network split where if the split is older than a certain number of blocks, there would be two permanent forks, but in 3 days or more, the blockchain heights would differ by more than X blocks, resulting in the abandonment of the losing chain.The discussion also addresses concerns about how a netsplit lasting longer than the block limit would be handled. It is suggested that the community would detect it before reaching the limit, allowing nodes to stop until the netsplit is fixed. In extreme cases where no one notices the split for more than the block limit and there are two permanent forks longer than the limit, nodes from one branch could delete their local history to join the other branch.However, critics argue that implementing a moving checkpoint rule as described could make Bitcoin more vulnerable to 51% attacks. They believe that the security of the rule could be further improved by making the number of blocks a fork must reach to halt the network proportional to the difference in time between the timestamp prior to the fork and the current time. Despite these discussions, it should be noted that the proposal is still under consideration and not yet adopted by the Bitcoin protocol.Overall, the proposal for a "moving checkpoint" in the Bitcoin protocol aims to improve security and address concerns regarding network splits and 51% attacks. However, there are ongoing debates about its effectiveness and potential vulnerabilities, and further discussions and analysis are needed before any implementation decisions are made. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Bitcoin-Core-to-disable-Bloom-based-Filtering-by-default.xml b/static/bitcoin-dev/Aug_2019/combined_Bitcoin-Core-to-disable-Bloom-based-Filtering-by-default.xml index 4d21957d51..236a8c4f35 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Bitcoin-Core-to-disable-Bloom-based-Filtering-by-default.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Bitcoin-Core-to-disable-Bloom-based-Filtering-by-default.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Bitcoin Core to disable Bloom-based Filtering by default - 2023-08-02T01:07:45.944093+00:00 - - Matt Corallo 2019-08-14 15:07:19+00:00 - - - Luke Dashjr 2019-07-27 19:19:49+00:00 - - - Matt Corallo 2019-07-27 16:10:03+00:00 - - - Chris 2019-07-26 16:48:36+00:00 - - - Jonas Schnelli 2019-07-26 10:04:32+00:00 - - - Tamas Blummer 2019-07-26 07:45:19+00:00 - - - Luke Dashjr 2019-07-25 03:04:25+00:00 - - - Justus Ranvier 2019-07-24 13:11:28+00:00 - - - Peter Todd 2019-07-23 20:36:50+00:00 - - - Andreas Schildbach 2019-07-23 14:47:18+00:00 - - - Luke Dashjr 2019-07-22 21:17:29+00:00 - - - Greg Sanders 2019-07-22 20:42:50+00:00 - - - Peter 2019-07-22 18:52:10+00:00 - - - Luke Dashjr 2019-07-22 17:26:56+00:00 - - - Luke Dashjr 2019-07-22 17:17:28+00:00 - - - Justus Ranvier 2019-07-22 15:58:49+00:00 - - - Dustin Dettmer 2019-07-22 15:15:49+00:00 - - - Tom Harding 2019-07-22 15:04:16+00:00 - - - Jonas Schnelli 2019-07-22 13:25:25+00:00 - - - Peter Todd 2019-07-22 08:32:15+00:00 - - - Matt Corallo 2019-07-22 05:01:58+00:00 - - - Andreas Schildbach 2019-07-21 22:56:33+00:00 - - - Matt Corallo 2019-07-20 17:46:52+00:00 - + 2025-09-26T15:55:26.869597+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default Matt Corallo + 2019-07-20T17:46:00.000Z + + + Andreas Schildbach + 2019-07-21T22:56:00.000Z + + + Matt Corallo + 2019-07-22T05:01:00.000Z + + + Peter Todd + 2019-07-22T08:32:00.000Z + + + Jonas Schnelli + 2019-07-22T13:25:00.000Z + + + Tom Harding + 2019-07-22T15:04:00.000Z + + + Dustin Dettmer + 2019-07-22T15:15:00.000Z + + + Justus Ranvier + 2019-07-22T15:58:00.000Z + + + Luke Dashjr + 2019-07-22T17:17:00.000Z + + + Luke Dashjr + 2019-07-22T17:26:00.000Z + + + Peter + 2019-07-22T18:52:00.000Z + + + Greg Sanders + 2019-07-22T20:42:00.000Z + + + Luke Dashjr + 2019-07-22T21:17:00.000Z + + + Andreas Schildbach + 2019-07-23T14:47:00.000Z + + + Peter Todd + 2019-07-23T20:36:00.000Z + + + Justus Ranvier + 2019-07-24T13:11:00.000Z + + + Luke Dashjr + 2019-07-25T03:04:00.000Z + + + Tamas Blummer + 2019-07-26T07:45:00.000Z + + + Jonas Schnelli + 2019-07-26T10:04:00.000Z + + + Chris + 2019-07-26T16:48:00.000Z + + + Matt Corallo + 2019-07-27T16:10:00.000Z + + + Luke Dashjr + 2019-07-27T19:19:00.000Z + + + Matt Corallo + 2019-08-14T15:07:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core to disable Bloom-based Filtering by default - 2023-08-02T01:07:45.944093+00:00 + 2025-09-26T15:55:26.872031+00:00 - In a recent announcement on the bitcoin-dev mailing list, it was revealed that bloom filter serving will be turned off by default in the next Bitcoin Core release. This decision comes as bloom filter serving has been a known DoS vector for some time and closing this vulnerability is seen as low-hanging fruit. While some users have expressed concerns about the impact on SPV implementations and centralization, it is expected that there will still be a sufficient number of NODE_BLOOM-enabled nodes available. Clients relying on NODE_BLOOM-supporting nodes are encouraged to consider migrating to alternative options in the coming years.Another discussion on the mailing list focused on the BIP158 compact block filter implemented in Bitcoin Core 0.19. Concerns were raised about address re-use and how the server determines the filter and false positive rate. It was suggested that the hardcoded filter may lead to wallets with many addresses having to wrap their key chains back to the beginning. However, it was clarified that wallets only need to match outstanding addresses that haven't been paid, rather than every single address used. This provides clarity on the potential issue of address re-use and its impact on wallet functionality.The conversation also touched upon the use of NODE_BLOOM peers and BIP 37 wallets. The change in defaults to serve BIP 37 peers does not imply the removal of the code for those who still wish to use it. Historical upgrade cycles suggest that many nodes will continue to serve NODE_BLOOM for years. However, there is an argument that BIP 158 offers better privacy and DoS protection, although it may result in increased traffic. The discussion emphasizes the importance of developers being transparent about the implications of different filtering options and providing users with choices based on their needs.In regards to BIP 157/158, it was noted that these are not alternatives to BIP 37 but rather complementary to it. Both can be used by wallets to save deterministic GCS filters, allowing offline re-scanning if necessary. While BIP 158 may cause more traffic, it provides the ability to filter blocks without relying on serving peers that could compromise financial privacy.The discussions also touched upon other topics such as the Rust implementation of BIP 158 and the potential use of DNS seed infrastructure to direct wallets to specific nodes. The ongoing debates within the Bitcoin community regarding security, scalability, and decentralization were also highlighted.In conclusion, the recent discussions on the bitcoin-dev mailing list have shed light on various aspects of Bitcoin Core, including the decision to turn off bloom filter serving by default, concerns about the BIP 158 compact block filter, and debates surrounding the use of NODE_BLOOM peers and BIP 37 wallets. Developers are encouraged to be transparent about the implications of different filtering options and provide users with choices based on their needs for privacy and bandwidth availability.The Bitcoin-dev mailing list recently discussed the potential removal of the NODE_BLOOM feature from the Bitcoin network. Developers expressed concern about the impact on over 10 million wallets that rely on this feature for updates. While alternatives like Electrum's JSON-based protocol and Stratum have been suggested, there is a consensus that BIP37 (public server-based tx filtering) was a conceptual mistake and should not be extended. The Neutrino protocol was also deemed controversial and less trustworthy. Matt Corallo raised concerns about privacy-violating alternatives to Bitcoin and pointed out that mitigations for these issues have been presented in a paper that requires further exploration.Andreas Schildbach argued against disabling the NODE_BLOOM feature, citing its importance to millions of wallets and the lack of a suitable alternative. He highlighted the potential risk of denial-of-service attacks but clarified that the myth surrounding them has been debunked. Andreas recommended improving the current filtering for segwit and urged developers to postpone the removal until a viable alternative exists. It was noted that NODE_BLOOM was added in Core 0.12 and BIP111 in 2015, indicating that this change was anticipated by most developers.The discussion also touched on the bandwidth usage of Compact Filters (CFB) compared to bloom filters, raising concerns about accessibility in impoverished countries where data rates are expensive. The plan is for such users to rely on custodial services, but questions were raised about the exact increase in bandwidth required by CFB. The conventional wisdom regarding CFB as privacy-violating was established by a paper that proposed mitigations but received little exploration. Despite these concerns, there has been a push towards custodial solutions, including custodial Lightning Network and L-BTC altcoin.Overall, the debate revolves around the potential impact on network security, privacy, and trust in Bitcoin. Developers are examining alternatives and calling for careful consideration before implementing any changes. 2019-08-14T15:07:19+00:00 + In a recent announcement on the bitcoin-dev mailing list, it was revealed that bloom filter serving will be turned off by default in the next Bitcoin Core release. This decision comes as bloom filter serving has been a known DoS vector for some time and closing this vulnerability is seen as low-hanging fruit. While some users have expressed concerns about the impact on SPV implementations and centralization, it is expected that there will still be a sufficient number of NODE_BLOOM-enabled nodes available. Clients relying on NODE_BLOOM-supporting nodes are encouraged to consider migrating to alternative options in the coming years.Another discussion on the mailing list focused on the BIP158 compact block filter implemented in Bitcoin Core 0.19. Concerns were raised about address re-use and how the server determines the filter and false positive rate. It was suggested that the hardcoded filter may lead to wallets with many addresses having to wrap their key chains back to the beginning. However, it was clarified that wallets only need to match outstanding addresses that haven't been paid, rather than every single address used. This provides clarity on the potential issue of address re-use and its impact on wallet functionality.The conversation also touched upon the use of NODE_BLOOM peers and BIP 37 wallets. The change in defaults to serve BIP 37 peers does not imply the removal of the code for those who still wish to use it. Historical upgrade cycles suggest that many nodes will continue to serve NODE_BLOOM for years. However, there is an argument that BIP 158 offers better privacy and DoS protection, although it may result in increased traffic. The discussion emphasizes the importance of developers being transparent about the implications of different filtering options and providing users with choices based on their needs.In regards to BIP 157/158, it was noted that these are not alternatives to BIP 37 but rather complementary to it. Both can be used by wallets to save deterministic GCS filters, allowing offline re-scanning if necessary. While BIP 158 may cause more traffic, it provides the ability to filter blocks without relying on serving peers that could compromise financial privacy.The discussions also touched upon other topics such as the Rust implementation of BIP 158 and the potential use of DNS seed infrastructure to direct wallets to specific nodes. The ongoing debates within the Bitcoin community regarding security, scalability, and decentralization were also highlighted.In conclusion, the recent discussions on the bitcoin-dev mailing list have shed light on various aspects of Bitcoin Core, including the decision to turn off bloom filter serving by default, concerns about the BIP 158 compact block filter, and debates surrounding the use of NODE_BLOOM peers and BIP 37 wallets. Developers are encouraged to be transparent about the implications of different filtering options and provide users with choices based on their needs for privacy and bandwidth availability.The Bitcoin-dev mailing list recently discussed the potential removal of the NODE_BLOOM feature from the Bitcoin network. Developers expressed concern about the impact on over 10 million wallets that rely on this feature for updates. While alternatives like Electrum's JSON-based protocol and Stratum have been suggested, there is a consensus that BIP37 (public server-based tx filtering) was a conceptual mistake and should not be extended. The Neutrino protocol was also deemed controversial and less trustworthy. Matt Corallo raised concerns about privacy-violating alternatives to Bitcoin and pointed out that mitigations for these issues have been presented in a paper that requires further exploration.Andreas Schildbach argued against disabling the NODE_BLOOM feature, citing its importance to millions of wallets and the lack of a suitable alternative. He highlighted the potential risk of denial-of-service attacks but clarified that the myth surrounding them has been debunked. Andreas recommended improving the current filtering for segwit and urged developers to postpone the removal until a viable alternative exists. It was noted that NODE_BLOOM was added in Core 0.12 and BIP111 in 2015, indicating that this change was anticipated by most developers.The discussion also touched on the bandwidth usage of Compact Filters (CFB) compared to bloom filters, raising concerns about accessibility in impoverished countries where data rates are expensive. The plan is for such users to rely on custodial services, but questions were raised about the exact increase in bandwidth required by CFB. The conventional wisdom regarding CFB as privacy-violating was established by a paper that proposed mitigations but received little exploration. Despite these concerns, there has been a push towards custodial solutions, including custodial Lightning Network and L-BTC altcoin.Overall, the debate revolves around the potential impact on network security, privacy, and trust in Bitcoin. Developers are examining alternatives and calling for careful consideration before implementing any changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Bitcoin-vaults-with-anti-theft-recovery-clawback-mechanisms.xml b/static/bitcoin-dev/Aug_2019/combined_Bitcoin-vaults-with-anti-theft-recovery-clawback-mechanisms.xml index addb46b5c7..3f12ff5f72 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Bitcoin-vaults-with-anti-theft-recovery-clawback-mechanisms.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Bitcoin-vaults-with-anti-theft-recovery-clawback-mechanisms.xml @@ -1,41 +1,59 @@ - + 2 Combined summary - Bitcoin vaults with anti-theft recovery/clawback mechanisms - 2023-08-02T01:15:25.991008+00:00 - - Peter Todd 2019-08-13 14:15:32+00:00 - - - Praveen Baratam 2019-08-13 02:44:03+00:00 - - - Bryan Bishop 2019-08-13 02:09:43+00:00 - - - Peter Todd 2019-08-12 15:01:10+00:00 - - - ZmnSCPxj 2019-08-08 03:03:04+00:00 - - - Sergio Demian Lerner 2019-08-08 02:09:20+00:00 - - - Bryan Bishop 2019-08-08 01:16:42+00:00 - - - ZmnSCPxj 2019-08-08 00:27:32+00:00 - - - Dustin Dettmer 2019-08-07 21:19:05+00:00 - - - Bryan Bishop 2019-08-07 20:32:47+00:00 - - - Bryan Bishop 2019-08-07 13:48:06+00:00 - + 2025-09-26T15:55:41.748891+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms Bryan Bishop + 2019-08-07T13:48:00.000Z + + + Bryan Bishop + 2019-08-07T20:32:00.000Z + + + Dustin Dettmer + 2019-08-07T21:19:00.000Z + + + ZmnSCPxj + 2019-08-08T00:27:00.000Z + + + Bryan Bishop + 2019-08-08T01:16:00.000Z + + + Sergio Demian Lerner + 2019-08-08T02:09:00.000Z + + + ZmnSCPxj + 2019-08-08T03:03:00.000Z + + + [bitcoin-dev] Single-use-Seal Implementation Peter Todd + 2019-08-12T14:40:00.000Z + + + [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms Peter Todd + 2019-08-12T15:01:00.000Z + + + Bryan Bishop + 2019-08-13T02:09:00.000Z + + + Praveen Baratam + 2019-08-13T02:44:00.000Z + + + Peter Todd + 2019-08-13T14:15:00.000Z + + @@ -47,13 +65,13 @@ - python-feedgen + 2 Combined summary - Bitcoin vaults with anti-theft recovery/clawback mechanisms - 2023-08-02T01:15:25.991008+00:00 + 2025-09-26T15:55:41.750258+00:00 - The email thread discusses various covenant proposals, such as CHECKSIGFROMSTACK, SECURETHEBAG, and CHECKOUTPUTVERIFY, that could address the issue at hand. Bishop's proposal is highlighted, along with previous works on the subject that he recently became aware of. Links to related works, including a 2018 proposal on the bitcoin-dev mailing list, a blog post on SegWit's security improvements, a YouTube video, and a Bitcointalk thread, are shared.Re-vaulting transactions and their limitations are also discussed in the email thread. These transactions are signed during the setup of the delayed-spend transaction for the parent vault, preventing coin withdrawals during the public observation delay period. However, there may be practical limits on the number of times a vault can be used for re-vaulting, as the transactions need to be signed in reverse order. The discussion also covers whether the same keys or new ones should be used for revaulting, depending on individual vault users' preferences.The conversation delves into various techniques and proposals for securing Bitcoin transactions, particularly in the context of implementing vaults without the need for soft-forks. Topics covered include delete-the-key pre-signed transactions, multisig gated by ECDSA pubkey recovery, alternative fee rates, fail-deadly mechanisms, key rotation, single-use seals, paid defection, financial privacy for custody and segregated vaults, and more. Multiple individuals contribute to the conversation, and links to related works are shared throughout.The article presents a proposal called "pre-signed vaults" as a method for implementing bitcoin vaults without relying on soft-forks or software upgrades. This method involves a public observation and delay period before a weakly-secured hot key can spend coins. The concept of "delete-the-key" pre-signed transactions plays a crucial role, where the key is deleted after a single transaction is pre-signed. Vaults are particularly useful for cold storage security as they allow for a publicly observable delay period during which a watchtower can alert the user if their coins are being stolen. The security of the scheme is enforced through pre-signed transactions and deleting private keys.The article also explores using pre-signed transactions to emulate covenants in Bitcoin, where a condition must be fulfilled for a transaction to occur. This can be achieved by using a series of pre-signed transactions with relative locktimes. Managing fees for pre-signed transactions is discussed, as well as the introduction of the "delete-the-key" trick. However, this trick does not work for multisig scenarios due to a lack of trust. An alternative technique using provably-unknown ECDSA keys in a multisig scheme is proposed. The article suggests a construction that allows for scripts exceeding size limits and explains how multi-party multisig bitcoin vaults can enforce a covenant.To improve financial privacy and security using vault constructions, the article suggests using a script template with different parameters instead of self-referential values to avoid dependency loops. The final transaction is created first and then used as input to the script template function. An early nuclear abort option and different multisig variations are proposed to enhance security. Key rotation and single-use seals are suggested for better financial privacy. The article emphasizes the importance of funding the vault only once and with the configured amount during setup.The author acknowledges the contributions of various individuals, including Jeremy Rubin, Bob McElrath, Andrew Poelstra, Joe Rayhawk, and Tadge Dryja. The article concludes by providing references to related works and acknowledging sources of inspiration for the proposal. 2019-08-13T14:15:32+00:00 + The email thread discusses various covenant proposals, such as CHECKSIGFROMSTACK, SECURETHEBAG, and CHECKOUTPUTVERIFY, that could address the issue at hand. Bishop's proposal is highlighted, along with previous works on the subject that he recently became aware of. Links to related works, including a 2018 proposal on the bitcoin-dev mailing list, a blog post on SegWit's security improvements, a YouTube video, and a Bitcointalk thread, are shared.Re-vaulting transactions and their limitations are also discussed in the email thread. These transactions are signed during the setup of the delayed-spend transaction for the parent vault, preventing coin withdrawals during the public observation delay period. However, there may be practical limits on the number of times a vault can be used for re-vaulting, as the transactions need to be signed in reverse order. The discussion also covers whether the same keys or new ones should be used for revaulting, depending on individual vault users' preferences.The conversation delves into various techniques and proposals for securing Bitcoin transactions, particularly in the context of implementing vaults without the need for soft-forks. Topics covered include delete-the-key pre-signed transactions, multisig gated by ECDSA pubkey recovery, alternative fee rates, fail-deadly mechanisms, key rotation, single-use seals, paid defection, financial privacy for custody and segregated vaults, and more. Multiple individuals contribute to the conversation, and links to related works are shared throughout.The article presents a proposal called "pre-signed vaults" as a method for implementing bitcoin vaults without relying on soft-forks or software upgrades. This method involves a public observation and delay period before a weakly-secured hot key can spend coins. The concept of "delete-the-key" pre-signed transactions plays a crucial role, where the key is deleted after a single transaction is pre-signed. Vaults are particularly useful for cold storage security as they allow for a publicly observable delay period during which a watchtower can alert the user if their coins are being stolen. The security of the scheme is enforced through pre-signed transactions and deleting private keys.The article also explores using pre-signed transactions to emulate covenants in Bitcoin, where a condition must be fulfilled for a transaction to occur. This can be achieved by using a series of pre-signed transactions with relative locktimes. Managing fees for pre-signed transactions is discussed, as well as the introduction of the "delete-the-key" trick. However, this trick does not work for multisig scenarios due to a lack of trust. An alternative technique using provably-unknown ECDSA keys in a multisig scheme is proposed. The article suggests a construction that allows for scripts exceeding size limits and explains how multi-party multisig bitcoin vaults can enforce a covenant.To improve financial privacy and security using vault constructions, the article suggests using a script template with different parameters instead of self-referential values to avoid dependency loops. The final transaction is created first and then used as input to the script template function. An early nuclear abort option and different multisig variations are proposed to enhance security. Key rotation and single-use seals are suggested for better financial privacy. The article emphasizes the importance of funding the vault only once and with the configured amount during setup.The author acknowledges the contributions of various individuals, including Jeremy Rubin, Bob McElrath, Andrew Poelstra, Joe Rayhawk, and Tadge Dryja. The article concludes by providing references to related works and acknowledging sources of inspiration for the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Burying-CSV-and-segwit-soft-fork-activations.xml b/static/bitcoin-dev/Aug_2019/combined_Burying-CSV-and-segwit-soft-fork-activations.xml index 63a4537933..a0e963beaa 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Burying-CSV-and-segwit-soft-fork-activations.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Burying-CSV-and-segwit-soft-fork-activations.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Burying CSV and segwit soft fork activations - 2023-08-02T01:16:35.454181+00:00 - - Eric Voskuil 2019-08-16 17:44:47+00:00 - - - Peter Todd 2019-08-16 16:06:50+00:00 - - - John Newbery 2019-08-16 15:23:37+00:00 - + 2025-09-26T15:55:33.211354+00:00 + python-feedgen + + + [bitcoin-dev] Burying CSV and segwit soft fork activations John Newbery + 2019-08-16T15:23:00.000Z + + + Peter Todd + 2019-08-16T16:06:00.000Z + + + Eric Voskuil + 2019-08-16T17:44:00.000Z + + - python-feedgen + 2 Combined summary - Burying CSV and segwit soft fork activations - 2023-08-02T01:16:35.454181+00:00 + 2025-09-26T15:55:33.211901+00:00 - In a recent email exchange on the bitcoin-dev mailing list, John Newbery discussed the concept of consensus changes in Bitcoin. He stated that once a consensus change has been activated and buried by sufficient work, its height is considered to be a historic fact. However, he noted that the exact activation method becomes less important over time.Another participant in the discussion, Peter Todd, pointed out that this notion is debatable due to Bitcoin's decentralized nature. Soft-forks, such as the activation of segwit, are backwards compatible, making it difficult to measure the preferences of economically significant nodes. Todd highlighted that it remains unclear why 100% of known blocks produced after August 1st, 2017 complied with segwit rules and the BIP9 signaling protocol for segwit.The post also mentioned the example of segwit activation at height 481,824 and raised questions about whether it was due to BIP9 version bits signaling, BIP 148 User Activated Soft Fork (UASF), or a combination of both. While these methods had similar effects in enforcing segwit, the BIP 148 UASF rejected blocks that didn't signal via the BIP9 version bits.It is possible that miners were running either the BIP9 signaling Bitcoin Core release or UASF enforcing software, or even a combination of different software. The motivations behind miners producing segwit-compliant blocks are also uncertain. It could be speculated that they expected rejection from the majority of economically significant nodes or simply wanted to enforce segwit. However, as Bitcoin is a decentralized network, no authority can definitively answer these questions.Additionally, the burying of deployments, where a consensus change is activated and buried by sufficient work, offers various benefits such as simplified consensus code, improved performance, and code structure benefits. Examples of burying deployments include the implementation of 3 ISM soft forks in BIP 90 and the enforcement of P2SH and segwit scripts.A recent merge in Bitcoin Core, PR 16060, buried the CSV and segwit activation heights to 419,328 and 481,824 respectively. However, this change could potentially cause a non-backwards compatible change and result in a chainsplit between pre-0.19 nodes and 0.19 nodes if a re-org occurs below the BIP9 segwit LOCKED_IN height. Such a scenario would require redoing over 93% of the total work ever committed to Bitcoin mining.While the proposal may theoretically lead to a consensus split, it is highly unlikely. Any circumstances that would lead to such a split would raise fundamental concerns about the security assumptions of Bitcoin. More details on these considerations can be found in the 'Considerations' section of BIP 90. 2019-08-16T17:44:47+00:00 + In a recent email exchange on the bitcoin-dev mailing list, John Newbery discussed the concept of consensus changes in Bitcoin. He stated that once a consensus change has been activated and buried by sufficient work, its height is considered to be a historic fact. However, he noted that the exact activation method becomes less important over time.Another participant in the discussion, Peter Todd, pointed out that this notion is debatable due to Bitcoin's decentralized nature. Soft-forks, such as the activation of segwit, are backwards compatible, making it difficult to measure the preferences of economically significant nodes. Todd highlighted that it remains unclear why 100% of known blocks produced after August 1st, 2017 complied with segwit rules and the BIP9 signaling protocol for segwit.The post also mentioned the example of segwit activation at height 481,824 and raised questions about whether it was due to BIP9 version bits signaling, BIP 148 User Activated Soft Fork (UASF), or a combination of both. While these methods had similar effects in enforcing segwit, the BIP 148 UASF rejected blocks that didn't signal via the BIP9 version bits.It is possible that miners were running either the BIP9 signaling Bitcoin Core release or UASF enforcing software, or even a combination of different software. The motivations behind miners producing segwit-compliant blocks are also uncertain. It could be speculated that they expected rejection from the majority of economically significant nodes or simply wanted to enforce segwit. However, as Bitcoin is a decentralized network, no authority can definitively answer these questions.Additionally, the burying of deployments, where a consensus change is activated and buried by sufficient work, offers various benefits such as simplified consensus code, improved performance, and code structure benefits. Examples of burying deployments include the implementation of 3 ISM soft forks in BIP 90 and the enforcement of P2SH and segwit scripts.A recent merge in Bitcoin Core, PR 16060, buried the CSV and segwit activation heights to 419,328 and 481,824 respectively. However, this change could potentially cause a non-backwards compatible change and result in a chainsplit between pre-0.19 nodes and 0.19 nodes if a re-org occurs below the BIP9 segwit LOCKED_IN height. Such a scenario would require redoing over 93% of the total work ever committed to Bitcoin mining.While the proposal may theoretically lead to a consensus split, it is highly unlikely. Any circumstances that would lead to such a split would raise fundamental concerns about the security assumptions of Bitcoin. More details on these considerations can be found in the 'Considerations' section of BIP 90. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Improving-JoinMarket-s-resistance-to-sybil-attacks-using-fidelity-bonds.xml b/static/bitcoin-dev/Aug_2019/combined_Improving-JoinMarket-s-resistance-to-sybil-attacks-using-fidelity-bonds.xml index 556c7d64da..9a2e775d06 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Improving-JoinMarket-s-resistance-to-sybil-attacks-using-fidelity-bonds.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Improving-JoinMarket-s-resistance-to-sybil-attacks-using-fidelity-bonds.xml @@ -1,101 +1,135 @@ - + 2 Combined summary - Improving JoinMarket's resistance to sybil attacks using fidelity bonds - 2023-08-02T01:11:05.109132+00:00 - - Chris Belcher 2019-08-08 20:06:07+00:00 - - - ZmnSCPxj 2019-08-08 13:59:13+00:00 - - - Dmitry Petukhov 2019-08-08 12:05:05+00:00 - - - Dmitry Petukhov 2019-08-08 11:37:50+00:00 - - - ZmnSCPxj 2019-08-08 09:35:24+00:00 - - - ZmnSCPxj 2019-08-08 00:09:11+00:00 - - - Dmitry Petukhov 2019-08-07 15:10:17+00:00 - - - ZmnSCPxj 2019-08-07 11:35:34+00:00 - - - ZmnSCPxj 2019-08-07 11:20:38+00:00 - - - Chris Belcher 2019-08-07 10:05:41+00:00 - - - Chris Belcher 2019-08-07 09:38:43+00:00 - - - ZmnSCPxj 2019-08-06 23:33:19+00:00 - - - Dmitry Petukhov 2019-08-06 21:37:42+00:00 - - - Dmitry Petukhov 2019-08-06 20:55:41+00:00 - - - Leo Wandersleb 2019-08-06 13:07:19+00:00 - - - Chris Belcher 2019-08-06 10:27:17+00:00 - - - ZmnSCPxj 2019-08-06 02:54:14+00:00 - - - Leo Wandersleb 2019-08-06 01:51:02+00:00 - - - Chris Belcher 2019-08-05 19:04:26+00:00 - - - Adam Gibson 2019-08-02 14:24:11+00:00 - - - Chris Belcher 2019-08-02 09:21:57+00:00 - - - David A. Harding 2019-07-31 17:59:40+00:00 - - - Dmitry Petukhov 2019-07-31 15:50:18+00:00 - - - Chris Belcher 2019-07-30 21:39:14+00:00 - - - Chris Belcher 2019-07-30 21:27:17+00:00 - - - Tamas Blummer 2019-07-28 18:29:34+00:00 - - - Tamas Blummer 2019-07-28 14:17:35+00:00 - - - David A. Harding 2019-07-27 19:34:17+00:00 - - - Dmitry Petukhov 2019-07-26 09:38:38+00:00 - - - Tamas Blummer 2019-07-26 08:10:15+00:00 - - - Chris Belcher 2019-07-25 11:47:54+00:00 - + 2025-09-26T15:55:18.322199+00:00 + python-feedgen + + + [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds Chris Belcher + 2019-07-25T11:47:00.000Z + + + Tamas Blummer + 2019-07-26T08:10:00.000Z + + + Dmitry Petukhov + 2019-07-26T09:38:00.000Z + + + David A. Harding + 2019-07-27T19:34:00.000Z + + + Tamas Blummer + 2019-07-28T14:17:00.000Z + + + Tamas Blummer + 2019-07-28T18:29:00.000Z + + + Chris Belcher + 2019-07-30T21:27:00.000Z + + + Chris Belcher + 2019-07-30T21:39:00.000Z + + + Dmitry Petukhov + 2019-07-31T15:50:00.000Z + + + David A. Harding + 2019-07-31T17:59:00.000Z + + + Chris Belcher + 2019-08-02T09:21:00.000Z + + + Adam Gibson + 2019-08-02T14:24:00.000Z + + + Chris Belcher + 2019-08-05T19:04:00.000Z + + + Leo Wandersleb + 2019-08-06T01:51:00.000Z + + + ZmnSCPxj + 2019-08-06T02:54:00.000Z + + + Chris Belcher + 2019-08-06T10:27:00.000Z + + + Leo Wandersleb + 2019-08-06T13:07:00.000Z + + + Dmitry Petukhov + 2019-08-06T20:55:00.000Z + + + Dmitry Petukhov + 2019-08-06T21:37:00.000Z + + + ZmnSCPxj + 2019-08-06T23:33:00.000Z + + + Chris Belcher + 2019-08-07T09:38:00.000Z + + + Chris Belcher + 2019-08-07T10:05:00.000Z + + + ZmnSCPxj + 2019-08-07T11:20:00.000Z + + + ZmnSCPxj + 2019-08-07T11:35:00.000Z + + + Dmitry Petukhov + 2019-08-07T15:10:00.000Z + + + ZmnSCPxj + 2019-08-08T00:09:00.000Z + + + ZmnSCPxj + 2019-08-08T09:35:00.000Z + + + Dmitry Petukhov + 2019-08-08T11:37:00.000Z + + + Dmitry Petukhov + 2019-08-08T12:05:00.000Z + + + ZmnSCPxj + 2019-08-08T13:59:00.000Z + + + Chris Belcher + 2019-08-08T20:06:00.000Z + + @@ -127,13 +161,13 @@ - python-feedgen + 2 Combined summary - Improving JoinMarket's resistance to sybil attacks using fidelity bonds - 2023-08-02T01:11:05.109132+00:00 + 2025-09-26T15:55:18.325439+00:00 - In a recent email exchange, the writer discusses the importance of the V^2 term in providing Sybil protection in JoinMarket coinjoin. They argue that consolidation into fewer makers is not as bad as having no Sybil protection, and the V^2 term penalizes sybil attacks and does more good than harm. The writer also addresses concerns about exchanges running makers and explains that the proposed fidelity bond scheme doesn't make it worse.The email exchange between Dmitry Petukhov and ZmnSCPxj discusses the anti-snitch protection of OP_CHECKSIGVERIFY and OP_CHECKSIG. It is suggested to change the MuSig(all_except_snitch) scheme to 1-of-n multisig construction to prevent issues with multiple snitches. Consolidation can be subsidized by paying rent to consolidators, and the lessee adds its rent payment in the same transaction that atomically instantiates the fidelity bond. Protection from multiple snitches is achieved by using a multitude of taproot leaves.In a recent Bitcoin-dev post, Dmitry Petukhov describes a shared ownership rent scheme where the 'TXO rentier' has a signed timelocked 'backout' transaction that spends the locked TXO and assigns the reward to the rentier. Any transaction that spends any TXO in the bond invalidates the bond when presented to takers. Takers can verify the transaction validity and mark the entire bond as revoked. Verification rules may need to be relaxed or dependent transactions checked to account for backout transactions that are not timelocked themselves.ZmnSCPxj raises concerns about the anti-snitch protection scheme in consolidated bonds in a recent discussion on Bitcoin's mailing list. The current scheme won't work if there are two snitches, and it is proposed to change it to 1-of-n multisig construction. The discussion also highlights the possibility of aggregation by off-blockchain agreements, which could be problematic for the system. Centralized exchanges and custodial services already control TXOs of their customers, which they can use to create fidelity bonds without consent. They may be willing to participate in deanonymization efforts to explain their participation in coinjoins to regulators.ZmnSCPxj proposes a solution to identify and punish snitches who report the consolidation scheme to takers. The participants in the consolidation scheme put up a fraction of the value into revocable bonds, and a punishment transaction divides it equally among the other participants. Participants provide adaptor signatures to their own participant_snitch_key, and if a participant snitches, their previously-shown adaptor signature can be used to reveal the private key behind their participant_snitch_key.The email discusses the problem of fidelity bonds, which are used to ensure makers on Lightning Network remain honest. Several schemes are proposed, including revocation of the whole bond by controlling even a single TXO, shared ownership rent schemes, and encryption with sequential operations. Aggregation is still possible through off-blockchain agreements, which could give entities like exchanges an undeservedly large weight in the fidelity bond system.Chris Belcher has discussed two schemes to prevent easy mindless renting of TXOs. One scheme allows revocation of the whole bond by controlling even a single TXO, while the other requires all locked TXOs to be spendable by any key that controls any TXO in the bond. However, both schemes have limitations and increase risk for the renter and co-rentiers.The email is a response to Chris Belcher's post on bitcoin-dev about the proposed JoinMarket fidelity bonds. ZmnSCPxj discusses the potential weaknesses of the V^2 proposal and suggests an alternative scheme using V^0.999. They also mention ongoing efforts to expand ECDSA to more than two-party n-of-n "true" multisignatures. The risks associated with custodial solutions and non-custodial renting of TXO signatures are also highlighted. The consolidation of makers due to renting TXOs is compared to sybil attacks, and the writer suggests that consolidation may be a lesser evil in terms of privacy-relevant information sharing.In a Bitcoin-dev mailing list, ZmnSCPxj warns about the pooling pressure to proof-of-work caused by tiny non-linearities in fidelity bond schemes. They suggest that any non-linearity exerts the same pooling pressure and propose using V^0.999 instead of V^2. The complexity of 2P-ECDSA is also mentioned, as well as the possibility of using transaction malleability as protection in bond transactions. The concept of "contract law" in the real world is explored as a form of smart contracts.Efforts are being made to expand ECDSA to enable more than two-party n-of-n "true" multisignatures. However, simply banning muSig or using transaction malleability as protection may not be sufficient. Contract law in the real world, which is a half-baked implementation of Bitcoin cryptographic smart contracts, already exists and allows for the acceptance of money with 2019-08-08T20:06:07+00:00 + In a recent email exchange, the writer discusses the importance of the V^2 term in providing Sybil protection in JoinMarket coinjoin. They argue that consolidation into fewer makers is not as bad as having no Sybil protection, and the V^2 term penalizes sybil attacks and does more good than harm. The writer also addresses concerns about exchanges running makers and explains that the proposed fidelity bond scheme doesn't make it worse.The email exchange between Dmitry Petukhov and ZmnSCPxj discusses the anti-snitch protection of OP_CHECKSIGVERIFY and OP_CHECKSIG. It is suggested to change the MuSig(all_except_snitch) scheme to 1-of-n multisig construction to prevent issues with multiple snitches. Consolidation can be subsidized by paying rent to consolidators, and the lessee adds its rent payment in the same transaction that atomically instantiates the fidelity bond. Protection from multiple snitches is achieved by using a multitude of taproot leaves.In a recent Bitcoin-dev post, Dmitry Petukhov describes a shared ownership rent scheme where the 'TXO rentier' has a signed timelocked 'backout' transaction that spends the locked TXO and assigns the reward to the rentier. Any transaction that spends any TXO in the bond invalidates the bond when presented to takers. Takers can verify the transaction validity and mark the entire bond as revoked. Verification rules may need to be relaxed or dependent transactions checked to account for backout transactions that are not timelocked themselves.ZmnSCPxj raises concerns about the anti-snitch protection scheme in consolidated bonds in a recent discussion on Bitcoin's mailing list. The current scheme won't work if there are two snitches, and it is proposed to change it to 1-of-n multisig construction. The discussion also highlights the possibility of aggregation by off-blockchain agreements, which could be problematic for the system. Centralized exchanges and custodial services already control TXOs of their customers, which they can use to create fidelity bonds without consent. They may be willing to participate in deanonymization efforts to explain their participation in coinjoins to regulators.ZmnSCPxj proposes a solution to identify and punish snitches who report the consolidation scheme to takers. The participants in the consolidation scheme put up a fraction of the value into revocable bonds, and a punishment transaction divides it equally among the other participants. Participants provide adaptor signatures to their own participant_snitch_key, and if a participant snitches, their previously-shown adaptor signature can be used to reveal the private key behind their participant_snitch_key.The email discusses the problem of fidelity bonds, which are used to ensure makers on Lightning Network remain honest. Several schemes are proposed, including revocation of the whole bond by controlling even a single TXO, shared ownership rent schemes, and encryption with sequential operations. Aggregation is still possible through off-blockchain agreements, which could give entities like exchanges an undeservedly large weight in the fidelity bond system.Chris Belcher has discussed two schemes to prevent easy mindless renting of TXOs. One scheme allows revocation of the whole bond by controlling even a single TXO, while the other requires all locked TXOs to be spendable by any key that controls any TXO in the bond. However, both schemes have limitations and increase risk for the renter and co-rentiers.The email is a response to Chris Belcher's post on bitcoin-dev about the proposed JoinMarket fidelity bonds. ZmnSCPxj discusses the potential weaknesses of the V^2 proposal and suggests an alternative scheme using V^0.999. They also mention ongoing efforts to expand ECDSA to more than two-party n-of-n "true" multisignatures. The risks associated with custodial solutions and non-custodial renting of TXO signatures are also highlighted. The consolidation of makers due to renting TXOs is compared to sybil attacks, and the writer suggests that consolidation may be a lesser evil in terms of privacy-relevant information sharing.In a Bitcoin-dev mailing list, ZmnSCPxj warns about the pooling pressure to proof-of-work caused by tiny non-linearities in fidelity bond schemes. They suggest that any non-linearity exerts the same pooling pressure and propose using V^0.999 instead of V^2. The complexity of 2P-ECDSA is also mentioned, as well as the possibility of using transaction malleability as protection in bond transactions. The concept of "contract law" in the real world is explored as a form of smart contracts.Efforts are being made to expand ECDSA to enable more than two-party n-of-n "true" multisignatures. However, simply banning muSig or using transaction malleability as protection may not be sufficient. Contract law in the real world, which is a half-baked implementation of Bitcoin cryptographic smart contracts, already exists and allows for the acceptance of money with - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Miniscript.xml b/static/bitcoin-dev/Aug_2019/combined_Miniscript.xml index 0df428c69f..c2a1014108 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Miniscript.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Miniscript.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Miniscript - 2023-08-02T01:17:18.548175+00:00 - - ZmnSCPxj 2019-08-20 08:14:13+00:00 - - - David Vorick 2019-08-20 07:15:24+00:00 - - - Pieter Wuille 2019-08-19 23:17:21+00:00 - + 2025-09-26T15:55:28.985070+00:00 + python-feedgen + + + [bitcoin-dev] Miniscript Pieter Wuille + 2019-08-19T23:17:00.000Z + + + David Vorick + 2019-08-20T07:15:00.000Z + + + ZmnSCPxj + 2019-08-20T08:14:00.000Z + + - python-feedgen + 2 Combined summary - Miniscript - 2023-08-02T01:17:18.549126+00:00 + 2025-09-26T15:55:28.985635+00:00 - Miniscript is a language for writing Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more. It is a joint project between Pieter Wuille, Andrew Poelstra, and Sanket Sanjalkar. The language allows for the creation of descriptors for addresses that implement more complex scripts than multisig. This opens up possibilities for software that can handle policy composition and compile complex spending policies into efficient scripts. Miniscript also enables users to determine the necessary and/or sufficient conditions for a script to be satisfied. With signatures for a set of keys, it can generically construct a witness for arbitrary scripts without any additional metadata. This means that generic PSBT signers are possible for this class of scripts.Furthermore, Miniscript computes the bounds on the size of a witness for arbitrary scripts and performs static analysis to identify any resource limitations that might interfere with spending ability. Currently, there are two implementations of Miniscript: a C++ version and a Rust library. While still a work in progress, the developers have conducted large-scale randomized tests to ensure compatibility with existing consensus and standardness rules. Importantly, Miniscript is designed for Bitcoin as it stands today, primarily utilizing P2WSH, and does not require any consensus changes. However, the developers plan to extend the design to support future script changes that may be included in Bitcoin.The adoption of Miniscript would have significant benefits for the Bitcoin ecosystem. It would reduce the barrier for new application writers by providing tools for analyzing code and mitigating the risk of user funds being lost. Developers could utilize Miniscript to assure themselves and others that their code maintains the desired outcome of no loss of coins, aside from transaction fees. While Miniscript may not identify specific transaction types, such as CoinJoin, it can verify that the final result is the same as the initial holdings. In essence, Miniscript would provide a valuable tool for ensuring the integrity and security of Bitcoin transactions. 2019-08-20T08:14:13+00:00 + Miniscript is a language for writing Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more. It is a joint project between Pieter Wuille, Andrew Poelstra, and Sanket Sanjalkar. The language allows for the creation of descriptors for addresses that implement more complex scripts than multisig. This opens up possibilities for software that can handle policy composition and compile complex spending policies into efficient scripts. Miniscript also enables users to determine the necessary and/or sufficient conditions for a script to be satisfied. With signatures for a set of keys, it can generically construct a witness for arbitrary scripts without any additional metadata. This means that generic PSBT signers are possible for this class of scripts.Furthermore, Miniscript computes the bounds on the size of a witness for arbitrary scripts and performs static analysis to identify any resource limitations that might interfere with spending ability. Currently, there are two implementations of Miniscript: a C++ version and a Rust library. While still a work in progress, the developers have conducted large-scale randomized tests to ensure compatibility with existing consensus and standardness rules. Importantly, Miniscript is designed for Bitcoin as it stands today, primarily utilizing P2WSH, and does not require any consensus changes. However, the developers plan to extend the design to support future script changes that may be included in Bitcoin.The adoption of Miniscript would have significant benefits for the Bitcoin ecosystem. It would reduce the barrier for new application writers by providing tools for analyzing code and mitigating the risk of user funds being lost. Developers could utilize Miniscript to assure themselves and others that their code maintains the desired outcome of no loss of coins, aside from transaction fees. While Miniscript may not identify specific transaction types, such as CoinJoin, it can verify that the final result is the same as the initial holdings. In essence, Miniscript would provide a valuable tool for ensuring the integrity and security of Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_OP-LOOKUP-OUTPUT-proposal.xml b/static/bitcoin-dev/Aug_2019/combined_OP-LOOKUP-OUTPUT-proposal.xml index 6f8d95e634..55219b3763 100644 --- a/static/bitcoin-dev/Aug_2019/combined_OP-LOOKUP-OUTPUT-proposal.xml +++ b/static/bitcoin-dev/Aug_2019/combined_OP-LOOKUP-OUTPUT-proposal.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - OP_LOOKUP_OUTPUT proposal - 2023-08-02T01:16:02.707170+00:00 - - ZmnSCPxj 2019-08-12 13:15:04+00:00 - - - Runchao Han 2019-08-12 10:02:33+00:00 - - - Lloyd Fournier 2019-08-12 09:22:29+00:00 - - - ZmnSCPxj 2019-08-12 08:05:53+00:00 - - - Runchao Han 2019-08-12 03:19:53+00:00 - - - Runchao Han 2019-08-10 13:01:41+00:00 - - - ZmnSCPxj 2019-08-10 12:50:18+00:00 - - - Runchao Han 2019-08-10 05:46:35+00:00 - - - ZmnSCPxj 2019-08-09 14:29:25+00:00 - - - Haoyu LIN 2019-08-09 13:35:19+00:00 - + 2025-09-26T15:55:35.358382+00:00 + python-feedgen + + + [bitcoin-dev] OP_LOOKUP_OUTPUT proposal Haoyu LIN + 2019-08-09T13:35:00.000Z + + + ZmnSCPxj + 2019-08-09T14:29:00.000Z + + + Runchao Han + 2019-08-10T05:46:00.000Z + + + ZmnSCPxj + 2019-08-10T12:50:00.000Z + + + Runchao Han + 2019-08-10T13:01:00.000Z + + + Runchao Han + 2019-08-12T03:19:00.000Z + + + ZmnSCPxj + 2019-08-12T08:05:00.000Z + + + Lloyd Fournier + 2019-08-12T09:22:00.000Z + + + Runchao Han + 2019-08-12T10:02:00.000Z + + + ZmnSCPxj + 2019-08-12T13:15:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - OP_LOOKUP_OUTPUT proposal - 2023-08-02T01:16:02.707170+00:00 + 2025-09-26T15:55:35.359626+00:00 - The email exchange discussed various aspects of atomic swaps, payment channels, and the challenges associated with them. One proposed solution involved using the OP_LOOKUP_OUTPUT opcode to check the status of a dependent transaction before claiming the premium. However, there was disagreement about whether this opcode could look at anything outside of the transaction spending from the script.Another topic of discussion was the protocol for atomic swaps proposed by Fournier et al. The protocol involved creating a payment channel on the WJT blockchain, with one party responsible for preparing the WJT transaction and the other responsible for preparing the BTC transaction. Concerns were raised about potential attacks or double-spending if both parties published transactions simultaneously. It was clarified that the correct order of the protocol would prevent such issues, and there was no need for optimism as most payment channel systems have unilateral closes.The group also discussed the problem of non-cooperation in payment channels. It was pointed out that any payment channel has the risk of non-cooperation by the other party, and introducing various attacks only increases the likelihood of it occurring. This makes it difficult to support multiple currencies on the same Lightning network.Moving on to the proposal itself, it discussed the profitability of arbitrage with the default timelock setting, estimating a profit range of 1% to 2.3%. Previous studies had suggested solutions to this problem but introduced the issue of Bob receiving the premium without payment. To address this, a new opcode called OP_LOOKUP_OUTPUT was proposed. This opcode would allow the transaction verifier to determine the status of a dependent transaction, which Bitcoin does not currently support. By using OP_LOOKUP_OUTPUT in the Bitcoin script, a decision could be made on whether Alice or Bob should receive the premium.The proposal also explored the application of Atomic Swaps in an American Call Options scenario, where Alice is required to pay for the premium regardless of the success of the swap. A sample implementation of a premium transaction for Atomic Swaps involving Spot and Option was provided based on the OP_LOOKUP_OUTPUT opcode.For more details on the proposal, the BIP draft can be accessed at https://github.com/HAOYUatHZ/bips/blob/bip-lookup_output/bip-lookup_output.mediawiki. Overall, the proposal aimed to eliminate risk-free optionality in Atomic Swaps by introducing the OP_LOOKUP_OUTPUT opcode, which used premiums to mitigate risks in both Spot and Option scenarios. 2019-08-12T13:15:04+00:00 + The email exchange discussed various aspects of atomic swaps, payment channels, and the challenges associated with them. One proposed solution involved using the OP_LOOKUP_OUTPUT opcode to check the status of a dependent transaction before claiming the premium. However, there was disagreement about whether this opcode could look at anything outside of the transaction spending from the script.Another topic of discussion was the protocol for atomic swaps proposed by Fournier et al. The protocol involved creating a payment channel on the WJT blockchain, with one party responsible for preparing the WJT transaction and the other responsible for preparing the BTC transaction. Concerns were raised about potential attacks or double-spending if both parties published transactions simultaneously. It was clarified that the correct order of the protocol would prevent such issues, and there was no need for optimism as most payment channel systems have unilateral closes.The group also discussed the problem of non-cooperation in payment channels. It was pointed out that any payment channel has the risk of non-cooperation by the other party, and introducing various attacks only increases the likelihood of it occurring. This makes it difficult to support multiple currencies on the same Lightning network.Moving on to the proposal itself, it discussed the profitability of arbitrage with the default timelock setting, estimating a profit range of 1% to 2.3%. Previous studies had suggested solutions to this problem but introduced the issue of Bob receiving the premium without payment. To address this, a new opcode called OP_LOOKUP_OUTPUT was proposed. This opcode would allow the transaction verifier to determine the status of a dependent transaction, which Bitcoin does not currently support. By using OP_LOOKUP_OUTPUT in the Bitcoin script, a decision could be made on whether Alice or Bob should receive the premium.The proposal also explored the application of Atomic Swaps in an American Call Options scenario, where Alice is required to pay for the premium regardless of the success of the swap. A sample implementation of a premium transaction for Atomic Swaps involving Spot and Option was provided based on the OP_LOOKUP_OUTPUT opcode.For more details on the proposal, the BIP draft can be accessed at https://github.com/HAOYUatHZ/bips/blob/bip-lookup_output/bip-lookup_output.mediawiki. Overall, the proposal aimed to eliminate risk-free optionality in Atomic Swaps by introducing the OP_LOOKUP_OUTPUT opcode, which used premiums to mitigate risks in both Spot and Option scenarios. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Proposed-Extensions-to-BIP-174-for-Future-Extensibility.xml b/static/bitcoin-dev/Aug_2019/combined_Proposed-Extensions-to-BIP-174-for-Future-Extensibility.xml index 2e32da895b..96fd44effb 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Proposed-Extensions-to-BIP-174-for-Future-Extensibility.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Proposed-Extensions-to-BIP-174-for-Future-Extensibility.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Proposed Extensions to BIP 174 for Future Extensibility - 2023-08-02T01:13:15.378026+00:00 - - Jonathan Underwood 2019-08-04 00:15:17+00:00 - - - Dmitry Petukhov 2019-08-02 09:18:36+00:00 - - - Andrew Chow 2019-08-01 19:01:06+00:00 - - - Andrew Chow 2019-08-01 17:57:26+00:00 - - - Stepan Snigirev 2019-08-01 13:50:47+00:00 - - - Andrew Chow 2019-07-31 19:16:36+00:00 - - - Dmitry Petukhov 2019-07-31 16:19:48+00:00 - - - jan matejek 2019-07-31 14:32:00+00:00 - - - Andrew Chow 2019-07-31 01:13:46+00:00 - + 2025-09-26T15:55:39.592761+00:00 + python-feedgen + + + [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility Andrew Chow + 2019-07-31T01:13:00.000Z + + + jan matejek + 2019-07-31T14:32:00.000Z + + + Dmitry Petukhov + 2019-07-31T16:19:00.000Z + + + Andrew Chow + 2019-07-31T19:16:00.000Z + + + Stepan Snigirev + 2019-08-01T13:50:00.000Z + + + Andrew Chow + 2019-08-01T17:57:00.000Z + + + Andrew Chow + 2019-08-01T19:01:00.000Z + + + Dmitry Petukhov + 2019-08-02T09:18:00.000Z + + + Jonathan Underwood + 2019-08-04T00:15:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Proposed Extensions to BIP 174 for Future Extensibility - 2023-08-02T01:13:15.378026+00:00 + 2025-09-26T15:55:39.593868+00:00 - The email thread discusses the idea of having a prefix string in BIP174 and how it adds complexity to parser code. Some people are against the idea, while others argue that the benefit for the whole industry is greater if there is a conflict-avoidance prefix. The author suggests using a specific type for all (global, input, and output) in BIP174, which means "see the BIP numbered in the next byte." This would allow for a BIP43-ish system for BIP174. The author also mentions that POR COMMITMENT and their current signature protocol proposal should go in there. They will keep an eye on the bips repo and implement it if someone pings them once things settle down.In a discussion about implementing a prefix string for private types, Andrew Chow spoke to some individuals who didn't like the idea because they had already created proprietary types without a prefix. This would add additional complexity to the parser code. However, others suggested that those who didn't want the added complexity could simply ignore it altogether. Since this is a private construction, and their private format specifies 'no prefix,' they can just disregard everything that doesn't start with "{0xFC}|{0x00}". The only added complexity would be one condition check. Others argued that having a conflict-avoidance prefix as the first thing after 0xFC would benefit more people in the industry than those who have already implemented proprietary types. Those who don't want to use the prefix can set it to 0x00, and the set of possible conflicting types are limited only to those entities that made this explicit decision. As for those who have already created squatted types, it only matters if they squatted on the 0xFC type in particular. In other cases, they will need to implement changes anyway to be compatible with the BIP. It was suggested that they consider the small burden of one additional condition check for the benefit of reducing interoperability problems between future PSBT/private types implementers.After speaking to some individuals, Andrew Chow has decided to simplify the implementation of proprietary types in Bitcoin by not using a prefix string. Instead, he suggests using {0xFC}|{private_type} with an optional prefix string that is strongly recommended. The concern was that people would use unused type values instead of following the specification for proprietary types, which would add complexity to the parser code. Since public parsers will not be enforcing the rules for proprietary types, it does not make sense to specify and enforce how they should be. The key is just an opaque data blob. Andrew also confirms that Compact Size Unsigned Integers will be used for the field types and will be minimally encoded CSUints. For proprietary types, there will only be one proprietary type, 0xFC, followed by a variable length string that serves as a unique identifier to prevent usage of proprietary types outside of private contexts. The actual type for data will then follow, defined by the user of the proprietary type. The prefix will just be a string, prefixed with a compact size unsigned integer. If no prefix is wanted, a single 0x00 byte can be used. It's important to note that for public software, these proprietary types don't need to be handled at all. Therefore, they do not need to check the string or the data type. Although it is not necessary to enforce the above rules about proprietary types, it is necessary to use the proprietary type value.It has been decided that Compact Size Unsigned Integers will be used for field types in an upcoming project. For proprietary types, one suggestion is to use a unique identifier, in the form of a variable length string prefixed with a compact size unsigned integer, followed by the actual type for the data as defined by the user. This will help prevent usage of proprietary types outside of private contexts. A single 0x00 byte can be used if no prefix is wanted. Public software does not need to handle these proprietary types and does not need to enforce the above rules except for the use of the proprietary type value.The suggestion has been made to use Bitcoin compact uint, which is already implemented in all bitcoin applications, wallets and libraries. This would be a logical choice for PSBT consumers. For certain proprietary applications, multi-byte keys could also be used where the first byte defines the application type and the next bytes define application-specific fields. It is recommended to set proprietary bytes to 0xF0-0xFC or 0xE0-0xEF, possibly using E for Enterprise.In a Bitcoin Development email thread, Dmitry Petukhov suggested that private formats should have at least a basic format with a prefix to distinguish different private formats and avoid unintentional confusion. He proposed that private types can start with the size of the prefix, allowing organizations to choose any prefix they like or no prefix if they are fine with possible conflicts with other empty-prefix private types. However, Andrew disagreed that this should be required and suggested it could be strongly recommended 2019-08-04T00:15:17+00:00 + The email thread discusses the idea of having a prefix string in BIP174 and how it adds complexity to parser code. Some people are against the idea, while others argue that the benefit for the whole industry is greater if there is a conflict-avoidance prefix. The author suggests using a specific type for all (global, input, and output) in BIP174, which means "see the BIP numbered in the next byte." This would allow for a BIP43-ish system for BIP174. The author also mentions that POR COMMITMENT and their current signature protocol proposal should go in there. They will keep an eye on the bips repo and implement it if someone pings them once things settle down.In a discussion about implementing a prefix string for private types, Andrew Chow spoke to some individuals who didn't like the idea because they had already created proprietary types without a prefix. This would add additional complexity to the parser code. However, others suggested that those who didn't want the added complexity could simply ignore it altogether. Since this is a private construction, and their private format specifies 'no prefix,' they can just disregard everything that doesn't start with "{0xFC}|{0x00}". The only added complexity would be one condition check. Others argued that having a conflict-avoidance prefix as the first thing after 0xFC would benefit more people in the industry than those who have already implemented proprietary types. Those who don't want to use the prefix can set it to 0x00, and the set of possible conflicting types are limited only to those entities that made this explicit decision. As for those who have already created squatted types, it only matters if they squatted on the 0xFC type in particular. In other cases, they will need to implement changes anyway to be compatible with the BIP. It was suggested that they consider the small burden of one additional condition check for the benefit of reducing interoperability problems between future PSBT/private types implementers.After speaking to some individuals, Andrew Chow has decided to simplify the implementation of proprietary types in Bitcoin by not using a prefix string. Instead, he suggests using {0xFC}|{private_type} with an optional prefix string that is strongly recommended. The concern was that people would use unused type values instead of following the specification for proprietary types, which would add complexity to the parser code. Since public parsers will not be enforcing the rules for proprietary types, it does not make sense to specify and enforce how they should be. The key is just an opaque data blob. Andrew also confirms that Compact Size Unsigned Integers will be used for the field types and will be minimally encoded CSUints. For proprietary types, there will only be one proprietary type, 0xFC, followed by a variable length string that serves as a unique identifier to prevent usage of proprietary types outside of private contexts. The actual type for data will then follow, defined by the user of the proprietary type. The prefix will just be a string, prefixed with a compact size unsigned integer. If no prefix is wanted, a single 0x00 byte can be used. It's important to note that for public software, these proprietary types don't need to be handled at all. Therefore, they do not need to check the string or the data type. Although it is not necessary to enforce the above rules about proprietary types, it is necessary to use the proprietary type value.It has been decided that Compact Size Unsigned Integers will be used for field types in an upcoming project. For proprietary types, one suggestion is to use a unique identifier, in the form of a variable length string prefixed with a compact size unsigned integer, followed by the actual type for the data as defined by the user. This will help prevent usage of proprietary types outside of private contexts. A single 0x00 byte can be used if no prefix is wanted. Public software does not need to handle these proprietary types and does not need to enforce the above rules except for the use of the proprietary type value.The suggestion has been made to use Bitcoin compact uint, which is already implemented in all bitcoin applications, wallets and libraries. This would be a logical choice for PSBT consumers. For certain proprietary applications, multi-byte keys could also be used where the first byte defines the application type and the next bytes define application-specific fields. It is recommended to set proprietary bytes to 0xF0-0xFC or 0xE0-0xEF, possibly using E for Enterprise.In a Bitcoin Development email thread, Dmitry Petukhov suggested that private formats should have at least a basic format with a prefix to distinguish different private formats and avoid unintentional confusion. He proposed that private types can start with the size of the prefix, allowing organizations to choose any prefix they like or no prefix if they are fine with possible conflicts with other empty-prefix private types. However, Andrew disagreed that this should be required and suggested it could be strongly recommended - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Storm-escrowed-storage-and-messaging-at-L2-L3.xml b/static/bitcoin-dev/Aug_2019/combined_Storm-escrowed-storage-and-messaging-at-L2-L3.xml index a0dda19af7..33b333740c 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Storm-escrowed-storage-and-messaging-at-L2-L3.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Storm-escrowed-storage-and-messaging-at-L2-L3.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Storm: escrowed storage and messaging at L2/L3 - 2023-08-02T01:17:03.927119+00:00 - - Dr Maxim Orlovsky 2019-08-21 17:04:35+00:00 - - - ZmnSCPxj 2019-08-21 12:48:16+00:00 - - - ZmnSCPxj 2019-08-21 12:12:30+00:00 - - - Dr Maxim Orlovsky 2019-08-21 10:51:58+00:00 - - - Stefan Richter 2019-08-21 09:33:24+00:00 - - - ZmnSCPxj 2019-08-21 07:32:25+00:00 - - - ZmnSCPxj 2019-08-21 04:14:13+00:00 - - - Dr Maxim Orlovsky 2019-08-19 22:08:09+00:00 - + 2025-09-26T15:55:31.098197+00:00 + python-feedgen + + + [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3 Dr Maxim Orlovsky + 2019-08-19T22:08:00.000Z + + + ZmnSCPxj + 2019-08-21T04:14:00.000Z + + + ZmnSCPxj + 2019-08-21T07:32:00.000Z + + + Stefan Richter + 2019-08-21T09:33:00.000Z + + + Dr Maxim Orlovsky + 2019-08-21T10:51:00.000Z + + + ZmnSCPxj + 2019-08-21T12:12:00.000Z + + + ZmnSCPxj + 2019-08-21T12:48:00.000Z + + + Dr Maxim Orlovsky + 2019-08-21T17:04:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Storm: escrowed storage and messaging at L2/L3 - 2023-08-02T01:17:03.927119+00:00 + 2025-09-26T15:55:31.099268+00:00 - Maxim Orlovsky has proposed a solution to address the Deaf Bob Attack, which involves the addition of two intermediary HTLC transactions called confirmation and fallbacks. This solution allows Alice to sign the HTLC fallback transaction and receive compensation if she doesn't receive the data from Bob. Bob, on the other hand, can prove that he still has the data by providing a "preimage" to the secret hashed by Alice. To ensure this, Bob selects the decryption key during setup and encrypts the data using EC multiplication with a factor provided by Alice. The only possibility for cheating now is if Alice no longer needs the data and avoids paying the full amount for storage, which Bob must consider during setup.The conversation between Maxim and ZmnSCPxj focuses on implementing Storm, a new off-chain payment channel network. They discuss the validation of probabilistically checkable proofs by Alice and the need for her to take a "shot" from the data in the form of a Merkle tree and keep its root. Asymmetric encryption using EC for atomic payments and threshold ECDSA signatures are also discussed. Additionally, they mention dual-funding channels, but note that it may not be necessary in a world where atomic cross-system swaps are possible. Fulgurite, a project to split a channel into Lightning part and DLC part, is mentioned as a potential solution.In their email conversation, ZmnSCPxj and Maxim Orlovsky discuss the proposed solution called Storm, which utilizes the Lightning Network for decentralized data storage. They address potential issues raised, including the insufficient description of probabilistic proof, asymmetrical encryption, and transportability over LN channels. ZmnSCPxj suggests elegant solutions to these problems, such as using EC for encryption/decryption and threshold ECDSA signatures. They acknowledge that the solution may be limited to a single LN channel, which must be dually-funded. To overcome potential attack risks for intermediate nodes, ZmnSCPxj proposes using EC magic homomorphisms. Maxim Orlovsky plans to analyze this solution further and open an issue on GitHub for discussion.ZmnSCPxj raises concerns about the Deaf Bob Attack on the bitcoin-dev mailing list. The attack scenario involves Bob claiming to have lost the data needed for a transaction, allowing him to receive the stake and reward without providing the data to Alice. If Alice publishes the HTLC settlement transaction, Bob can reveal the decryption key, but without the encrypted data, it is useless. This raises questions about the workability of the scenario, as the decryption key is embedded in the HTLC and cannot be obtained without being selected by Bob during setup.ZmnSCPxj writes a letter to Maxim pointing out issues with the probabilistic checkable proof for data storage on the Lightning network. The main concern is that the proof can only confirm that the encrypted data corresponds to the given plaintext, not if the source data matches what Alice originally stored. To address this, Alice needs to compute a Merkle Tree of the data chunks and store its root before sending the data to Bob for storage. The proof should include the Merkle Tree Path proofs of the selected source data chunks. The use of asymmetrical encryption, where Bob shares the decryption key only after acquiring funds, is also discussed. However, it is unclear how to assure Alice that the hash of the decryption key is indeed the correct one. ZmnSCPxj suggests using asymmetric encryption using EC to atomically pay for knowledge of the scalar/decryption key while revealing only the hash and encryption key to Alice. They also note that any mechanism requiring multiple participants to put up money into a contract can only live inside a single LN channel due to potential attacks on intermediate nodes.Dr. Maxim Orlovsky proposes a design for distributed storage and messaging with escrow/economic incentivization, leveraging the LNP/BP ecosystem at Layer 2 and 3. This design allows for the construction of payment channels that guarantee remote data storage and retrieval while mitigating counterparty risks through economic stimulus. It can be combined with Lightning Network for off-chain operation. The proposal originated from joint work on RGB and single-use seals technologies but has potential applications for other L2/L3 technologies requiring client-stored data. Feedback and discussions on driving Storm development forward are welcome. 2019-08-21T17:04:35+00:00 + Maxim Orlovsky has proposed a solution to address the Deaf Bob Attack, which involves the addition of two intermediary HTLC transactions called confirmation and fallbacks. This solution allows Alice to sign the HTLC fallback transaction and receive compensation if she doesn't receive the data from Bob. Bob, on the other hand, can prove that he still has the data by providing a "preimage" to the secret hashed by Alice. To ensure this, Bob selects the decryption key during setup and encrypts the data using EC multiplication with a factor provided by Alice. The only possibility for cheating now is if Alice no longer needs the data and avoids paying the full amount for storage, which Bob must consider during setup.The conversation between Maxim and ZmnSCPxj focuses on implementing Storm, a new off-chain payment channel network. They discuss the validation of probabilistically checkable proofs by Alice and the need for her to take a "shot" from the data in the form of a Merkle tree and keep its root. Asymmetric encryption using EC for atomic payments and threshold ECDSA signatures are also discussed. Additionally, they mention dual-funding channels, but note that it may not be necessary in a world where atomic cross-system swaps are possible. Fulgurite, a project to split a channel into Lightning part and DLC part, is mentioned as a potential solution.In their email conversation, ZmnSCPxj and Maxim Orlovsky discuss the proposed solution called Storm, which utilizes the Lightning Network for decentralized data storage. They address potential issues raised, including the insufficient description of probabilistic proof, asymmetrical encryption, and transportability over LN channels. ZmnSCPxj suggests elegant solutions to these problems, such as using EC for encryption/decryption and threshold ECDSA signatures. They acknowledge that the solution may be limited to a single LN channel, which must be dually-funded. To overcome potential attack risks for intermediate nodes, ZmnSCPxj proposes using EC magic homomorphisms. Maxim Orlovsky plans to analyze this solution further and open an issue on GitHub for discussion.ZmnSCPxj raises concerns about the Deaf Bob Attack on the bitcoin-dev mailing list. The attack scenario involves Bob claiming to have lost the data needed for a transaction, allowing him to receive the stake and reward without providing the data to Alice. If Alice publishes the HTLC settlement transaction, Bob can reveal the decryption key, but without the encrypted data, it is useless. This raises questions about the workability of the scenario, as the decryption key is embedded in the HTLC and cannot be obtained without being selected by Bob during setup.ZmnSCPxj writes a letter to Maxim pointing out issues with the probabilistic checkable proof for data storage on the Lightning network. The main concern is that the proof can only confirm that the encrypted data corresponds to the given plaintext, not if the source data matches what Alice originally stored. To address this, Alice needs to compute a Merkle Tree of the data chunks and store its root before sending the data to Bob for storage. The proof should include the Merkle Tree Path proofs of the selected source data chunks. The use of asymmetrical encryption, where Bob shares the decryption key only after acquiring funds, is also discussed. However, it is unclear how to assure Alice that the hash of the decryption key is indeed the correct one. ZmnSCPxj suggests using asymmetric encryption using EC to atomically pay for knowledge of the scalar/decryption key while revealing only the hash and encryption key to Alice. They also note that any mechanism requiring multiple participants to put up money into a contract can only live inside a single LN channel due to potential attacks on intermediate nodes.Dr. Maxim Orlovsky proposes a design for distributed storage and messaging with escrow/economic incentivization, leveraging the LNP/BP ecosystem at Layer 2 and 3. This design allows for the construction of payment channels that guarantee remote data storage and retrieval while mitigating counterparty risks through economic stimulus. It can be combined with Lightning Network for off-chain operation. The proposal originated from joint work on RGB and single-use seals technologies but has potential applications for other L2/L3 technologies requiring client-stored data. Feedback and discussions on driving Storm development forward are welcome. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_Taproot-proposal.xml b/static/bitcoin-dev/Aug_2019/combined_Taproot-proposal.xml index e88df4e080..949627e979 100644 --- a/static/bitcoin-dev/Aug_2019/combined_Taproot-proposal.xml +++ b/static/bitcoin-dev/Aug_2019/combined_Taproot-proposal.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Taproot proposal - 2023-08-02T00:47:13.477592+00:00 - - Pieter Wuille 2019-09-18 21:21:56+00:00 - - - ZmnSCPxj 2019-09-17 04:09:50+00:00 - - - Greg Sanders 2019-09-16 16:18:35+00:00 - - - Pieter Wuille 2019-08-09 18:29:55+00:00 - - - Elichai Turkel 2019-08-09 14:58:58+00:00 - - - Russell O'Connor 2019-06-28 11:16:46+00:00 - - - Anthony Towns 2019-06-28 09:49:37+00:00 - - - Russell O'Connor 2019-06-27 00:08:01+00:00 - - - Russell O'Connor 2019-05-23 02:32:26+00:00 - - - Pieter Wuille 2019-05-23 02:06:42+00:00 - - - John Newbery 2019-05-22 14:14:44+00:00 - - - Russell O'Connor 2019-05-21 17:20:32+00:00 - - - ZmnSCPxj 2019-05-18 17:51:16+00:00 - - - ZmnSCPxj 2019-05-10 05:38:52+00:00 - - - Johnson Lau 2019-05-09 16:56:57+00:00 - - - Pieter Wuille 2019-05-08 23:06:51+00:00 - - - Luke Dashjr 2019-05-08 13:10:17+00:00 - - - ZmnSCPxj 2019-05-08 05:16:03+00:00 - - - Anthony Towns 2019-05-08 04:49:28+00:00 - - - ZmnSCPxj 2019-05-08 04:37:37+00:00 - - - ZmnSCPxj 2019-05-08 03:44:29+00:00 - - - Sjors Provoost 2019-05-07 20:42:58+00:00 - - - Luke Dashjr 2019-05-06 20:17:09+00:00 - - - Pieter Wuille 2019-05-06 17:57:57+00:00 - + 2025-09-26T15:55:22.596518+00:00 + python-feedgen + + + [bitcoin-dev] Taproot proposal Pieter Wuille + 2019-05-06T17:57:00.000Z + + + Luke Dashjr + 2019-05-06T20:17:00.000Z + + + Sjors Provoost + 2019-05-07T20:42:00.000Z + + + ZmnSCPxj + 2019-05-08T03:44:00.000Z + + + ZmnSCPxj + 2019-05-08T04:37:00.000Z + + + Anthony Towns + 2019-05-08T04:49:00.000Z + + + ZmnSCPxj + 2019-05-08T05:16:00.000Z + + + Luke Dashjr + 2019-05-08T13:10:00.000Z + + + Pieter Wuille + 2019-05-08T23:06:00.000Z + + + Johnson Lau + 2019-05-09T16:56:00.000Z + + + ZmnSCPxj + 2019-05-10T05:38:00.000Z + + + ZmnSCPxj + 2019-05-18T17:51:00.000Z + + + Russell O'Connor + 2019-05-21T17:20:00.000Z + + + John Newbery + 2019-05-22T14:14:00.000Z + + + Pieter Wuille + 2019-05-23T02:06:00.000Z + + + Russell O'Connor + 2019-05-23T02:32:00.000Z + + + Russell O'Connor + 2019-06-27T00:08:00.000Z + + + Anthony Towns + 2019-06-28T09:49:00.000Z + + + Russell O'Connor + 2019-06-28T11:16:00.000Z + + + Elichai Turkel + 2019-08-09T14:58:00.000Z + + + Pieter Wuille + 2019-08-09T18:29:00.000Z + + + Greg Sanders + 2019-09-16T16:18:00.000Z + + + ZmnSCPxj + 2019-09-17T04:09:00.000Z + + + Pieter Wuille + 2019-09-18T21:21:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Taproot proposal - 2023-08-02T00:47:13.477592+00:00 + 2025-09-26T15:55:22.599273+00:00 - Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown. This technique offers improved privacy and can be useful for setting up Pedersen commitments.Another topic of conversation revolves around signing an additional 2019-09-18T21:21:56+00:00 + Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown. This technique offers improved privacy and can be useful for setting up Pedersen commitments.Another topic of conversation revolves around signing an additional - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2019/combined_testing-bitcoin-nodes.xml b/static/bitcoin-dev/Aug_2019/combined_testing-bitcoin-nodes.xml index 5f64768b94..bb2cb8d71d 100644 --- a/static/bitcoin-dev/Aug_2019/combined_testing-bitcoin-nodes.xml +++ b/static/bitcoin-dev/Aug_2019/combined_testing-bitcoin-nodes.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - testing bitcoin nodes - 2023-08-02T01:14:40.131273+00:00 - - Pieter Wuille 2019-08-21 18:33:03+00:00 - - - Alexander Leishman 2019-08-21 17:33:28+00:00 - - - Niels Thijssen 2019-08-21 12:35:45+00:00 - - - Niels Thijssen 2019-08-06 10:36:18+00:00 - + 2025-09-26T15:55:24.716586+00:00 + python-feedgen + + + [bitcoin-dev] testing bitcoin nodes Niels Thijssen + 2019-08-06T10:36:00.000Z + + + Niels Thijssen + 2019-08-21T12:35:00.000Z + + + Alexander Leishman + 2019-08-21T17:33:00.000Z + + + Pieter Wuille + 2019-08-21T18:33:00.000Z + + - python-feedgen + 2 Combined summary - testing bitcoin nodes - 2023-08-02T01:14:40.131273+00:00 + 2025-09-26T15:55:24.717193+00:00 - Niels Thijssen, a software test specialist running a private full Bitcoin node on Raspberry Pi 4, has reached out for guidance regarding the tests performed during installation, upgrade, and compilation of software for the node. He is specifically interested in obtaining an overview of the common approach to testing and refining test cases. Niels has attempted to utilize the tests available on GitHub but has found them lacking in helpfulness. He is now seeking assistance from individuals who can either join him in his pursuit of knowledge or provide relevant information that can guide him in the testing process.It is important to note that the email thread containing this inquiry ends with a standard disclaimer from Improve Quality Services B.V., stating that the email and any files transmitted may contain proprietary and confidential information. Unauthorized disclosure, use, dissemination, forwarding, printing, or copying of the email and its attachments, either in whole or in part, is strictly prohibited. If anyone has received this message in error or is not the intended recipient, they are instructed to immediately notify the sender and delete the email from their computer. The views or opinions expressed in the email are solely those of the author and do not necessarily represent those of Improve Quality Services B.V. Furthermore, Improve QS cannot guarantee the security and error-free nature of email communications and assumes no liability for damages resulting from their use. All transactions and undertakings resulting from the email are subject to the general terms and conditions of purchase, sale, and delivery of Improve QS. 2019-08-21T18:33:03+00:00 + Niels Thijssen, a software test specialist running a private full Bitcoin node on Raspberry Pi 4, has reached out for guidance regarding the tests performed during installation, upgrade, and compilation of software for the node. He is specifically interested in obtaining an overview of the common approach to testing and refining test cases. Niels has attempted to utilize the tests available on GitHub but has found them lacking in helpfulness. He is now seeking assistance from individuals who can either join him in his pursuit of knowledge or provide relevant information that can guide him in the testing process.It is important to note that the email thread containing this inquiry ends with a standard disclaimer from Improve Quality Services B.V., stating that the email and any files transmitted may contain proprietary and confidential information. Unauthorized disclosure, use, dissemination, forwarding, printing, or copying of the email and its attachments, either in whole or in part, is strictly prohibited. If anyone has received this message in error or is not the intended recipient, they are instructed to immediately notify the sender and delete the email from their computer. The views or opinions expressed in the email are solely those of the author and do not necessarily represent those of Improve Quality Services B.V. Furthermore, Improve QS cannot guarantee the security and error-free nature of email communications and assumes no liability for damages resulting from their use. All transactions and undertakings resulting from the email are subject to the general terms and conditions of purchase, sale, and delivery of Improve QS. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_BIP-118-and-SIGHASH-ANYPREVOUT.xml b/static/bitcoin-dev/Aug_2020/combined_BIP-118-and-SIGHASH-ANYPREVOUT.xml index 46cacb7cf7..ad23c660f6 100644 --- a/static/bitcoin-dev/Aug_2020/combined_BIP-118-and-SIGHASH-ANYPREVOUT.xml +++ b/static/bitcoin-dev/Aug_2020/combined_BIP-118-and-SIGHASH-ANYPREVOUT.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - BIP 118 and SIGHASH_ANYPREVOUT - 2023-08-02T02:29:39.241532+00:00 - - Matt Corallo 2020-08-11 00:14:29+00:00 - - - Richard Myers 2020-08-07 15:34:43+00:00 - - - Matt Corallo 2020-08-06 15:58:53+00:00 - - - ZmnSCPxj 2020-08-04 14:59:52+00:00 - - - Matt Corallo 2020-08-04 13:10:02+00:00 - - - Christian Decker 2020-08-04 10:38:20+00:00 - - - ZmnSCPxj 2020-08-04 04:23:03+00:00 - - - lf-lists at mattcorallo.com 2020-08-04 04:02:21+00:00 - - - ZmnSCPxj 2020-08-04 01:38:55+00:00 - - - Richard Myers 2020-08-03 19:27:13+00:00 - - - Christian Decker 2020-07-10 07:46:54+00:00 - - - ZmnSCPxj 2020-07-10 03:29:39+00:00 - - - Anthony Towns 2020-07-09 22:30:50+00:00 - - - Anthony Towns 2020-07-09 21:40:48+00:00 - + 2025-09-26T15:54:39.857589+00:00 + python-feedgen + + + [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns + 2020-07-09T21:40:00.000Z + + + Anthony Towns + 2020-07-09T22:30:00.000Z + + + ZmnSCPxj + 2020-07-10T03:29:00.000Z + + + Christian Decker + 2020-07-10T07:46:00.000Z + + + Richard Myers + 2020-08-03T19:27:00.000Z + + + ZmnSCPxj + 2020-08-04T01:38:00.000Z + + + lf-lists + 2020-08-04T04:02:00.000Z + + + ZmnSCPxj + 2020-08-04T04:23:00.000Z + + + Christian Decker + 2020-08-04T10:38:00.000Z + + + Matt Corallo + 2020-08-04T13:10:00.000Z + + + ZmnSCPxj + 2020-08-04T14:59:00.000Z + + + Matt Corallo + 2020-08-06T15:58:00.000Z + + + Richard Myers + 2020-08-07T15:34:00.000Z + + + Matt Corallo + 2020-08-11T00:14:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - BIP 118 and SIGHASH_ANYPREVOUT - 2023-08-02T02:29:39.241532+00:00 + 2025-09-26T15:54:39.859162+00:00 - In a recent conversation on the Bitcoin-dev mailing list, Matt Corallo discussed the potential of a relay network that could handle transactions with SIGHASH_ANYPREVOUT. This network would need to rewrite transactions before passing them on to a local bitcoind. The idea is that a sender could relay a transaction with one input that is valid for any output index 0 in a transaction spending output B. The receiver would then look up which transaction spends output B and fill in the input with that outpoint.Richard Myers asked if such a relay network could be more "smart about replacement" in the context of ANYPREVOUT by RBF-ing parts of a package. Matt responded that SIGHASH_NOINPUT would simplify these issues if nodes could be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. However, shoving this complexity into the Bitcoin P2P network may not be feasible. Instead, a relay network of lightning nodes could potentially handle the calculation and pass the transactions to their local full nodes.In the context of ANYPREVOUT*, a special relay network could be more intelligent about replacement. This would involve relaying only the higher up-front fee-rate transactions from a lower total fee package (Package B) which get spent by the high absolute fee child transactions from a higher total fee package (Package A). The result is Package A', which includes the higher fee rate versions of the ANYPREVOUT* transactions from Package B, but with an overall lower total fee. However, implementing this solution requires nodes to be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else in the mempool already spends.The conversation between Matt and ZmnSCPxj revolves around a relay-based attack that can compromise HTLC security in the Lightning Network. The attacker connects twice to the LN - once to any node near the victim and once to the victim. The attacker arranges for the victim-attacker channel to have most funds on the victim's side and routes a circular payment terminating in the victim-attacker channel. The attacker broadcasts a very low-fee old-state transaction of the victim-attacker channel just before the HTLC timeout, forcing the victim to broadcast a unilateral close attempt for the victim-attacker channel to enforce the HTLC on-chain. However, relay shenanigans prevent the latest commitment from being broadcast, leaving the victim at risk.ZmnSCPxj suggests that forwarding nodes drop channels on-chain "early" if the HTLC will time out soon. Matt notes that SIGHASH_NOINPUT makes these issues much simpler to address if nodes can be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. They also discuss the possibility of an overlay relay network of lightning nodes that do calculation and pass transactions to their local full nodes.Christian discusses a feasible attack that can be executed without the victim's knowledge in a Lightning universe primarily utilizing SIGHASH_NOINPUT-based mechanisms. He suggests monitoring on-chain events and ignoring mempool events to react to confirmed transactions. To ensure security, deep timeouts for mechanisms are necessary so that a SIGHASH_NOINPUT signature can be "locked" to a confirmed txid, unless a reorg unconfirms the transaction. Additionally, implementing scorch-the-earth, keep-bumping-the-fee strategies can help keep rebroadcasting new versions of the spending transaction.In the context of recent relay-based attacks, there have been concerns about the security of Hash Time-Locked Contract (HTLC) transactions. ZmnSCPxj raises a design consideration for the p2p protocol layer that would allow relaying a transaction to a full node without knowing which input transaction that full node has in its mempool or active chain. This is important for systems like lighting where you may not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending them nonetheless.Richard expresses his interest in implementing a Taproot version of Decker-Russell-Osuntokun (eltoo) and discusses the differences between ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and their exploitation. ZmnSCPxj provides clarifications on key-path spending, reducing the round trips for MuSig signing sessions, and the security implications of chaperone signatures for SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT. They also discuss the implementation of scorch-the-earth, keep-bumping-the-fee strategies.In another email thread, Anthony Towns opens a draft pull request to update BIP 118 with the ANYPREVOUT bip, including significant changes since previous discussions. The complete lack of chaperone signatures in the new BIP text is noted.Overall, 2020-08-11T00:14:29+00:00 + In a recent conversation on the Bitcoin-dev mailing list, Matt Corallo discussed the potential of a relay network that could handle transactions with SIGHASH_ANYPREVOUT. This network would need to rewrite transactions before passing them on to a local bitcoind. The idea is that a sender could relay a transaction with one input that is valid for any output index 0 in a transaction spending output B. The receiver would then look up which transaction spends output B and fill in the input with that outpoint.Richard Myers asked if such a relay network could be more "smart about replacement" in the context of ANYPREVOUT by RBF-ing parts of a package. Matt responded that SIGHASH_NOINPUT would simplify these issues if nodes could be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. However, shoving this complexity into the Bitcoin P2P network may not be feasible. Instead, a relay network of lightning nodes could potentially handle the calculation and pass the transactions to their local full nodes.In the context of ANYPREVOUT*, a special relay network could be more intelligent about replacement. This would involve relaying only the higher up-front fee-rate transactions from a lower total fee package (Package B) which get spent by the high absolute fee child transactions from a higher total fee package (Package A). The result is Package A', which includes the higher fee rate versions of the ANYPREVOUT* transactions from Package B, but with an overall lower total fee. However, implementing this solution requires nodes to be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else in the mempool already spends.The conversation between Matt and ZmnSCPxj revolves around a relay-based attack that can compromise HTLC security in the Lightning Network. The attacker connects twice to the LN - once to any node near the victim and once to the victim. The attacker arranges for the victim-attacker channel to have most funds on the victim's side and routes a circular payment terminating in the victim-attacker channel. The attacker broadcasts a very low-fee old-state transaction of the victim-attacker channel just before the HTLC timeout, forcing the victim to broadcast a unilateral close attempt for the victim-attacker channel to enforce the HTLC on-chain. However, relay shenanigans prevent the latest commitment from being broadcast, leaving the victim at risk.ZmnSCPxj suggests that forwarding nodes drop channels on-chain "early" if the HTLC will time out soon. Matt notes that SIGHASH_NOINPUT makes these issues much simpler to address if nodes can be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. They also discuss the possibility of an overlay relay network of lightning nodes that do calculation and pass transactions to their local full nodes.Christian discusses a feasible attack that can be executed without the victim's knowledge in a Lightning universe primarily utilizing SIGHASH_NOINPUT-based mechanisms. He suggests monitoring on-chain events and ignoring mempool events to react to confirmed transactions. To ensure security, deep timeouts for mechanisms are necessary so that a SIGHASH_NOINPUT signature can be "locked" to a confirmed txid, unless a reorg unconfirms the transaction. Additionally, implementing scorch-the-earth, keep-bumping-the-fee strategies can help keep rebroadcasting new versions of the spending transaction.In the context of recent relay-based attacks, there have been concerns about the security of Hash Time-Locked Contract (HTLC) transactions. ZmnSCPxj raises a design consideration for the p2p protocol layer that would allow relaying a transaction to a full node without knowing which input transaction that full node has in its mempool or active chain. This is important for systems like lighting where you may not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending them nonetheless.Richard expresses his interest in implementing a Taproot version of Decker-Russell-Osuntokun (eltoo) and discusses the differences between ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and their exploitation. ZmnSCPxj provides clarifications on key-path spending, reducing the round trips for MuSig signing sessions, and the security implications of chaperone signatures for SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT. They also discuss the implementation of scorch-the-earth, keep-bumping-the-fee strategies.In another email thread, Anthony Towns opens a draft pull request to update BIP 118 with the ANYPREVOUT bip, including significant changes since previous discussions. The complete lack of chaperone signatures in the new BIP text is noted.Overall, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_Default-Signet-Custom-Signets-and-Resetting-Testnet.xml b/static/bitcoin-dev/Aug_2020/combined_Default-Signet-Custom-Signets-and-Resetting-Testnet.xml index d6684c4691..a2b7d4ac03 100644 --- a/static/bitcoin-dev/Aug_2020/combined_Default-Signet-Custom-Signets-and-Resetting-Testnet.xml +++ b/static/bitcoin-dev/Aug_2020/combined_Default-Signet-Custom-Signets-and-Resetting-Testnet.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Default Signet, Custom Signets and Resetting Testnet - 2023-08-02T02:38:56.976981+00:00 - - Matt Corallo 2020-09-14 02:11:32+00:00 - - - Michael Folkson 2020-08-29 10:14:50+00:00 - + 2025-09-26T15:54:27.002971+00:00 + python-feedgen + + + [bitcoin-dev] Default Signet, Custom Signets and Resetting Testnet Michael Folkson + 2020-08-29T10:14:00.000Z + + + Matt Corallo + 2020-09-14T02:11:00.000Z + + - python-feedgen + 2 Combined summary - Default Signet, Custom Signets and Resetting Testnet - 2023-08-02T02:38:56.976981+00:00 + 2025-09-26T15:54:27.003491+00:00 - The Bitcoin Core has announced that Signet PR 18267 is now in an advanced stage of review, and they are encouraging additional code review and testing. However, there are some meta questions surrounding Signets that need to be discussed outside of the Bitcoin Core repo to ensure that everyone's testing needs are being met.The first question raised is whether there should be one "default" Signet for specific purposes or if multiple custom Signets should exist. The argument for a "default" Signet with a network effect is that it would provide a staging ground for testing proposed soft forks and prevent splintered Signet networks with different combinations of proposed soft forks enabled. However, there would have to be a formal understanding of at what stage a proposed soft fork should be enabled on the "default" Signet. This could present challenges if soft forks are enabled and then change or get updated.The second question raised is who should have keys to sign each new block on the "default" Signet assuming it exists. Currently, it is a 1-of-2 multisig with Kalle Alm and AJ Towns having keys. However, it was suggested on IRC that there should be at least one additional key present in the EU/US timezone so blocks can continue to be mined during an Asia-Pacific outage.The third question raised is regarding concerns from some in the community that testnet will be replaced by Signet. Michael Folkson assures that testnet will continue as long as someone out there is mining testnet blocks. However, there is a question of whether testnet needs to be reset since it was last reset in 2012. Assuming Signet is successful, there will be less testing on testnet, but certain testing use cases will still prefer testnet. It has been argued that testnet should be a large chain to stress test certain scenarios, and in that case, we may not want to reset testnet.Michael encourages thoughts, feedback, and questions from the Bitcoin community to ensure that everyone's testing needs are being considered. While there is a closed issue on the Bitcoin Core repo for prior conversation, it is ideal for discussions outside of Bitcoin Core to take place on the mailing list or on IRC. 2020-09-14T02:11:32+00:00 + The Bitcoin Core has announced that Signet PR 18267 is now in an advanced stage of review, and they are encouraging additional code review and testing. However, there are some meta questions surrounding Signets that need to be discussed outside of the Bitcoin Core repo to ensure that everyone's testing needs are being met.The first question raised is whether there should be one "default" Signet for specific purposes or if multiple custom Signets should exist. The argument for a "default" Signet with a network effect is that it would provide a staging ground for testing proposed soft forks and prevent splintered Signet networks with different combinations of proposed soft forks enabled. However, there would have to be a formal understanding of at what stage a proposed soft fork should be enabled on the "default" Signet. This could present challenges if soft forks are enabled and then change or get updated.The second question raised is who should have keys to sign each new block on the "default" Signet assuming it exists. Currently, it is a 1-of-2 multisig with Kalle Alm and AJ Towns having keys. However, it was suggested on IRC that there should be at least one additional key present in the EU/US timezone so blocks can continue to be mined during an Asia-Pacific outage.The third question raised is regarding concerns from some in the community that testnet will be replaced by Signet. Michael Folkson assures that testnet will continue as long as someone out there is mining testnet blocks. However, there is a question of whether testnet needs to be reset since it was last reset in 2012. Assuming Signet is successful, there will be less testing on testnet, but certain testing use cases will still prefer testnet. It has been argued that testnet should be a large chain to stress test certain scenarios, and in that case, we may not want to reset testnet.Michael encourages thoughts, feedback, and questions from the Bitcoin community to ensure that everyone's testing needs are being considered. While there is a closed issue on the Bitcoin Core repo for prior conversation, it is ideal for discussions outside of Bitcoin Core to take place on the mailing list or on IRC. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap.xml b/static/bitcoin-dev/Aug_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap.xml index 7398de4f91..57b91a33b3 100644 --- a/static/bitcoin-dev/Aug_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap.xml +++ b/static/bitcoin-dev/Aug_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap.xml @@ -1,74 +1,107 @@ - + 2 Combined summary - Detailed protocol design for routed multi-transaction CoinSwap - 2023-08-02T02:33:40.925726+00:00 - - seid Mohammed 2020-09-06 03:06:52+00:00 - - - ZmnSCPxj 2020-09-05 02:45:00+00:00 - - - ZmnSCPxj 2020-09-05 02:29:18+00:00 - - - Antoine Riard 2020-09-05 01:10:36+00:00 - - - Antoine Riard 2020-09-05 01:07:15+00:00 - - - ZmnSCPxj 2020-09-03 23:39:02+00:00 - - - Chris Belcher 2020-09-03 10:50:57+00:00 - - - ZmnSCPxj 2020-09-03 09:45:53+00:00 - - - Chris Belcher 2020-09-03 09:00:00+00:00 - - - ZmnSCPxj 2020-08-30 13:38:11+00:00 - - - Chris Belcher 2020-08-29 22:03:09+00:00 - - - ZmnSCPxj 2020-08-25 03:16:05+00:00 - - - Antoine Riard 2020-08-24 19:30:05+00:00 - - - ZmnSCPxj 2020-08-22 01:09:35+00:00 - - - Chris Belcher 2020-08-21 09:47:31+00:00 - - - ZmnSCPxj 2020-08-21 04:20:23+00:00 - - - Chris Belcher 2020-08-20 22:37:35+00:00 - - - Chris Belcher 2020-08-20 22:15:34+00:00 - - - ZmnSCPxj 2020-08-20 21:38:16+00:00 - - - Nadav Kohen 2020-08-20 15:28:56+00:00 - - - ZmnSCPxj 2020-08-20 11:17:07+00:00 - - - Chris Belcher 2020-08-11 12:05:57+00:00 - + 2025-09-26T15:54:35.617497+00:00 + python-feedgen + + + [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap Chris Belcher + 2020-08-11T12:05:00.000Z + + + ZmnSCPxj + 2020-08-20T11:17:00.000Z + + + Nadav Kohen + 2020-08-20T15:28:00.000Z + + + ZmnSCPxj + 2020-08-20T21:38:00.000Z + + + Chris Belcher + 2020-08-20T22:15:00.000Z + + + Chris Belcher + 2020-08-20T22:37:00.000Z + + + ZmnSCPxj + 2020-08-21T04:20:00.000Z + + + Chris Belcher + 2020-08-21T09:47:00.000Z + + + ZmnSCPxj + 2020-08-22T01:09:00.000Z + + + Antoine Riard + 2020-08-24T19:30:00.000Z + + + ZmnSCPxj + 2020-08-25T03:16:00.000Z + + + Chris Belcher + 2020-08-29T22:03:00.000Z + + + ZmnSCPxj + 2020-08-30T13:38:00.000Z + + + Chris Belcher + 2020-09-03T09:00:00.000Z + + + ZmnSCPxj + 2020-09-03T09:45:00.000Z + + + Chris Belcher + 2020-09-03T10:50:00.000Z + + + ZmnSCPxj + 2020-09-03T23:39:00.000Z + + + Antoine Riard + 2020-09-05T01:07:00.000Z + + + Antoine Riard + 2020-09-05T01:10:00.000Z + + + ZmnSCPxj + 2020-09-05T02:29:00.000Z + + + ZmnSCPxj + 2020-09-05T02:45:00.000Z + + + seid Mohammed + 2020-09-06T03:06:00.000Z + + + [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium Chris Belcher + 2020-10-03T10:36:00.000Z + + + ZmnSCPxj + 2020-10-03T13:31:00.000Z + + @@ -91,13 +124,13 @@ - python-feedgen + 2 Combined summary - Detailed protocol design for routed multi-transaction CoinSwap - 2023-08-02T02:33:40.926761+00:00 + 2025-09-26T15:54:35.620009+00:00 - to create multisig addresses, and funds were locked into these addresses. Contract transactions were created to transfer funds using timelocks or hash preimage values. Various vulnerabilities in the protocol were identified, such as fee model vulnerability and transaction pinning vulnerability. Proposed solutions included using anchor outputs in contract transactions and separating timelock and hashlock cases into separate transactions. The implementation of CoinSwap involved broadcasting and mining contract transactions, waiting for timeouts, and using hash preimage values to retrieve funds. Parties paid their own miner fees in timeout failure cases, and anti-DOS features were implemented to prevent attacks.The email exchanges also discussed the usage of relative and absolute locktimes in contract transactions with Scriptless Script, specifically Pointlock transactions. Absolute locktimes allowed participants to define their fee ranges without negotiation. Private key turnover was suggested to reduce funding lockup time for multi-hop swaps, and diagrams were provided to illustrate different scenarios.The CoinSwap protocol aimed to improve privacy by allowing users to swap Bitcoin without revealing amounts or addresses. Multiple transactions were used in a single CoinSwap to avoid amount correlation. Makers only knew their previous and next transactions, while the taker knew the entire route. Funding transactions paid into 2-of-2 multisig addresses, and contract transactions transferred coins to a contract that could be spent with timelocks or hash preimage values. Vulnerabilities such as pinning scenarios and theft attempts were addressed through various solutions, including watchtowers to guard CoinSwaps and prevent theft attempts.The implementation of CoinSwap for privacy and fungibility was being worked on by Chris Belcher. The protocol included multi-transaction CoinSwaps, routed CoinSwaps, liquidity markets, private key handover, and fidelity bonds. Contract transactions played a crucial role, and vulnerabilities and proposed solutions were discussed. Absolute timelocks, watchtowers, and split UTXOs were proposed to enhance the protocol. Relative timelocks, DOS-resistance, and deviations from the protocol were also addressed.In an email exchange between Nadav and ZmnSCPxj, concerns about the security of a proposed public key scheme for Bitcoin transactions were discussed. The main concern was the potential for the taker to steal funds by manipulating the nonce point used in the transaction. ZmnSCPxj clarified that the taker must provide the actual value of the nonce to the maker, eliminating the need for the maker to trust the taker's calculations. The discussion then shifted towards the use of 2p-ECDSA for privacy protection in CoinSwap transactions. While ZmnSCPxj argued that using OP_CHECKMULTISIG instead of 2p-ECDSA would remove most of the privacy advantages, he acknowledged the possibility of implementing OP_CHECKMULTISIG first and adding 2p-ECDSA later. Nadav agreed but emphasized the significant privacy benefits of singlesig anonymity sets.The implementation of CoinSwap involved two parties, the taker and maker, exchanging coins through atomic cross-chain trading. The protocol started with the taker broadcasting a funding transaction to a 2-of-2 multisig address and creating HTLCs specifying amounts and addresses. The maker signed the HTLCs, creating contract transactions that were not broadcast but exchanged between the parties. The EC tweak trick could be used to reduce round trips required for agreeing on public keys. Concerns were raised about a possible attack by a malicious taker who intentionally aborts the swap, causing makers to lose more money than the attacker. Parties needed to be prepared to respond to contract transactions at all times, as the outputs of the funding transactions could remain unspent indefinitely.ZmnSCPxj raised concerns about the security of CoinSwap, particularly regarding the taker providing the nonce 'p' to the maker, which could potentially lead to fund theft. He suggested using 2p-ECDSA to address this issue. Additionally, he emphasized the importance of hiding among larger singlesig anonymity sets and discussed the use of HTLCs in open-coded SCRIPTs for increased privacy.Nadav raised concerns about the proposed CoinSwap protocol on the bitcoin-dev mailing list, particularly regarding the generation of signatures for HTLCs from the pubkey used in Bitcoin transactions. He suggested the use of Zero Knowledge Proof of Knowledge (ZKPoK) or a different key implementation like MuSig. The email also explored the advantages of direct connections to Alice over CoinJoin and potential leaks in CoinSwap. Makers having no incentive to pay fees and takers setting limits on maker's transactions were mentioned. Contract transactions that spend from the 2-of-2 multisig outputs were explained, with staggered timelocks to allow for recovery in case of malicious actions. The EC tweak trick was highlighted as a way to reduce one round trip when agreeing on public keys.The email thread provided insights into the proposed CoinSwap protocol and its potential deviations. It highlighted the use of multi-transaction CoinSwaps, routed CoinSwaps, 2020-09-06T03:06:52+00:00 + to create multisig addresses, and funds were locked into these addresses. Contract transactions were created to transfer funds using timelocks or hash preimage values. Various vulnerabilities in the protocol were identified, such as fee model vulnerability and transaction pinning vulnerability. Proposed solutions included using anchor outputs in contract transactions and separating timelock and hashlock cases into separate transactions. The implementation of CoinSwap involved broadcasting and mining contract transactions, waiting for timeouts, and using hash preimage values to retrieve funds. Parties paid their own miner fees in timeout failure cases, and anti-DOS features were implemented to prevent attacks.The email exchanges also discussed the usage of relative and absolute locktimes in contract transactions with Scriptless Script, specifically Pointlock transactions. Absolute locktimes allowed participants to define their fee ranges without negotiation. Private key turnover was suggested to reduce funding lockup time for multi-hop swaps, and diagrams were provided to illustrate different scenarios.The CoinSwap protocol aimed to improve privacy by allowing users to swap Bitcoin without revealing amounts or addresses. Multiple transactions were used in a single CoinSwap to avoid amount correlation. Makers only knew their previous and next transactions, while the taker knew the entire route. Funding transactions paid into 2-of-2 multisig addresses, and contract transactions transferred coins to a contract that could be spent with timelocks or hash preimage values. Vulnerabilities such as pinning scenarios and theft attempts were addressed through various solutions, including watchtowers to guard CoinSwaps and prevent theft attempts.The implementation of CoinSwap for privacy and fungibility was being worked on by Chris Belcher. The protocol included multi-transaction CoinSwaps, routed CoinSwaps, liquidity markets, private key handover, and fidelity bonds. Contract transactions played a crucial role, and vulnerabilities and proposed solutions were discussed. Absolute timelocks, watchtowers, and split UTXOs were proposed to enhance the protocol. Relative timelocks, DOS-resistance, and deviations from the protocol were also addressed.In an email exchange between Nadav and ZmnSCPxj, concerns about the security of a proposed public key scheme for Bitcoin transactions were discussed. The main concern was the potential for the taker to steal funds by manipulating the nonce point used in the transaction. ZmnSCPxj clarified that the taker must provide the actual value of the nonce to the maker, eliminating the need for the maker to trust the taker's calculations. The discussion then shifted towards the use of 2p-ECDSA for privacy protection in CoinSwap transactions. While ZmnSCPxj argued that using OP_CHECKMULTISIG instead of 2p-ECDSA would remove most of the privacy advantages, he acknowledged the possibility of implementing OP_CHECKMULTISIG first and adding 2p-ECDSA later. Nadav agreed but emphasized the significant privacy benefits of singlesig anonymity sets.The implementation of CoinSwap involved two parties, the taker and maker, exchanging coins through atomic cross-chain trading. The protocol started with the taker broadcasting a funding transaction to a 2-of-2 multisig address and creating HTLCs specifying amounts and addresses. The maker signed the HTLCs, creating contract transactions that were not broadcast but exchanged between the parties. The EC tweak trick could be used to reduce round trips required for agreeing on public keys. Concerns were raised about a possible attack by a malicious taker who intentionally aborts the swap, causing makers to lose more money than the attacker. Parties needed to be prepared to respond to contract transactions at all times, as the outputs of the funding transactions could remain unspent indefinitely.ZmnSCPxj raised concerns about the security of CoinSwap, particularly regarding the taker providing the nonce 'p' to the maker, which could potentially lead to fund theft. He suggested using 2p-ECDSA to address this issue. Additionally, he emphasized the importance of hiding among larger singlesig anonymity sets and discussed the use of HTLCs in open-coded SCRIPTs for increased privacy.Nadav raised concerns about the proposed CoinSwap protocol on the bitcoin-dev mailing list, particularly regarding the generation of signatures for HTLCs from the pubkey used in Bitcoin transactions. He suggested the use of Zero Knowledge Proof of Knowledge (ZKPoK) or a different key implementation like MuSig. The email also explored the advantages of direct connections to Alice over CoinJoin and potential leaks in CoinSwap. Makers having no incentive to pay fees and takers setting limits on maker's transactions were mentioned. Contract transactions that spend from the 2-of-2 multisig outputs were explained, with staggered timelocks to allow for recovery in case of malicious actions. The EC tweak trick was highlighted as a way to reduce one round trip when agreeing on public keys.The email thread provided insights into the proposed CoinSwap protocol and its potential deviations. It highlighted the use of multi-transaction CoinSwaps, routed CoinSwaps, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_Generalizing-feature-negotiation-when-new-p2p-connections-are-setup.xml b/static/bitcoin-dev/Aug_2020/combined_Generalizing-feature-negotiation-when-new-p2p-connections-are-setup.xml index 9733f34aa9..a1415a2cb3 100644 --- a/static/bitcoin-dev/Aug_2020/combined_Generalizing-feature-negotiation-when-new-p2p-connections-are-setup.xml +++ b/static/bitcoin-dev/Aug_2020/combined_Generalizing-feature-negotiation-when-new-p2p-connections-are-setup.xml @@ -1,98 +1,131 @@ - + 2 Combined summary - Generalizing feature negotiation when new p2p connections are setup - 2023-08-02T02:37:06.021825+00:00 - - Eric Voskuil 2020-08-24 20:33:46+00:00 - - - Jeremy 2020-08-24 20:21:52+00:00 - - - Eric Voskuil 2020-08-24 20:17:17+00:00 - - - Jeremy 2020-08-24 19:58:56+00:00 - - - G. Andrew Stone 2020-08-24 13:59:26+00:00 - - - Suhas Daftuar 2020-08-24 09:44:07+00:00 - - - Eric Voskuil 2020-08-23 17:49:35+00:00 - - - Eric Voskuil 2020-08-23 17:45:45+00:00 - - - Matt Corallo 2020-08-21 22:16:02+00:00 - - - Eric Voskuil 2020-08-21 21:17:55+00:00 - - - Jeremy 2020-08-21 21:17:32+00:00 - - - Jeremy 2020-08-21 21:08:33+00:00 - - - Matt Corallo 2020-08-21 20:45:26+00:00 - - - Jeremy 2020-08-21 19:50:21+00:00 - - - Eric Voskuil 2020-08-21 16:42:46+00:00 - - - lf-lists at mattcorallo.com 2020-08-21 14:15:10+00:00 - - - Eric Voskuil 2020-08-21 04:25:08+00:00 - - - Anthony Towns 2020-08-21 02:36:47+00:00 - - - David A. Harding 2020-08-20 14:13:39+00:00 - - - Eric Voskuil 2020-08-18 18:56:13+00:00 - - - Matt Corallo 2020-08-18 18:25:26+00:00 - - - Eric Voskuil 2020-08-18 18:11:12+00:00 - - - Matt Corallo 2020-08-18 17:26:36+00:00 - - - Eric Voskuil 2020-08-18 16:54:58+00:00 - - - Matt Corallo 2020-08-18 14:59:00+00:00 - - - Eric Voskuil 2020-08-17 21:21:53+00:00 - - - Suhas Daftuar 2020-08-17 20:40:02+00:00 - - - Eric Voskuil 2020-08-16 19:06:55+00:00 - - - Jeremy 2020-08-16 17:24:09+00:00 - - - Suhas Daftuar 2020-08-14 19:28:41+00:00 - + 2025-09-26T15:54:33.381643+00:00 + python-feedgen + + + [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup Suhas Daftuar + 2020-08-14T19:28:00.000Z + + + Jeremy + 2020-08-16T17:24:00.000Z + + + Eric Voskuil + 2020-08-16T19:06:00.000Z + + + Suhas Daftuar + 2020-08-17T20:40:00.000Z + + + Eric Voskuil + 2020-08-17T21:21:00.000Z + + + Matt Corallo + 2020-08-18T14:59:00.000Z + + + Eric Voskuil + 2020-08-18T16:54:00.000Z + + + Matt Corallo + 2020-08-18T17:26:00.000Z + + + Eric Voskuil + 2020-08-18T18:11:00.000Z + + + Matt Corallo + 2020-08-18T18:25:00.000Z + + + Eric Voskuil + 2020-08-18T18:56:00.000Z + + + David A. Harding + 2020-08-20T14:13:00.000Z + + + Anthony Towns + 2020-08-21T02:36:00.000Z + + + Eric Voskuil + 2020-08-21T04:25:00.000Z + + + lf-lists + 2020-08-21T14:15:00.000Z + + + Eric Voskuil + 2020-08-21T16:42:00.000Z + + + Jeremy + 2020-08-21T19:50:00.000Z + + + Matt Corallo + 2020-08-21T20:45:00.000Z + + + Jeremy + 2020-08-21T21:08:00.000Z + + + Jeremy + 2020-08-21T21:17:00.000Z + + + Eric Voskuil + 2020-08-21T21:17:00.000Z + + + Matt Corallo + 2020-08-21T22:16:00.000Z + + + Eric Voskuil + 2020-08-23T17:45:00.000Z + + + Eric Voskuil + 2020-08-23T17:49:00.000Z + + + Suhas Daftuar + 2020-08-24T09:44:00.000Z + + + G. Andrew Stone + 2020-08-24T13:59:00.000Z + + + Jeremy + 2020-08-24T19:58:00.000Z + + + Eric Voskuil + 2020-08-24T20:17:00.000Z + + + Jeremy + 2020-08-24T20:21:00.000Z + + + Eric Voskuil + 2020-08-24T20:33:00.000Z + + @@ -123,13 +156,13 @@ - python-feedgen + 2 Combined summary - Generalizing feature negotiation when new p2p connections are setup - 2023-08-02T02:37:06.021825+00:00 + 2025-09-26T15:54:33.384688+00:00 - Bitcoin developer Suhas Daftuar has proposed a new Bitcoin Improvement Proposal (BIP) that suggests Bitcoin network clients should ignore unknown messages received before a VERACK. This proposal builds on his previous suggestion for feature negotiation in the WTXID-based transaction relay, known as BIP 339. The implementation of BIP 339 has been merged into Bitcoin Core but has not yet been released. Daftuar believes that software upgrading past protocol version 70016 was already planning to either implement BIP 339 or ignore the wtxidrelay message proposed in it. To ensure future protocol upgrades benefit from feature negotiation at the time of connection, he suggests using the same method as proposed in BIP 339 without needing to bump the protocol version. Having a standard understanding of how other network clients operate would be helpful in this regard.However, there are concerns about the requirement to ignore unknown messages, as it is both a protocol-breaking change and poor protocol design. Changes to version negotiation itself can be problematic. Daftuar proposes making features optional at the new protocol level, allowing each client to limit its communication to the negotiated protocol and ignore unsupported/disabled features.In addition to Daftuar's proposal, the context discusses the inclusion of negotiation utility functions in a bip, specifically a "polite disconnect" function for nodes that do not want to connect due to incompatibility. It suggests standardizing naming conventions and negotiation message types to avoid different systems and limit the bip to defining ignorable vs. non-ignorable message types. This would make it easier for old nodes to apply generic rules around reporting, rejecting or responding to unknown feature negotiations versus untagged messages which could be a negotiation or something else.Daftuar hopes to receive feedback on any potential issues with his proposal to prevent disruption in deploying future peer-to-peer changes. 2020-08-24T20:33:46+00:00 + Bitcoin developer Suhas Daftuar has proposed a new Bitcoin Improvement Proposal (BIP) that suggests Bitcoin network clients should ignore unknown messages received before a VERACK. This proposal builds on his previous suggestion for feature negotiation in the WTXID-based transaction relay, known as BIP 339. The implementation of BIP 339 has been merged into Bitcoin Core but has not yet been released. Daftuar believes that software upgrading past protocol version 70016 was already planning to either implement BIP 339 or ignore the wtxidrelay message proposed in it. To ensure future protocol upgrades benefit from feature negotiation at the time of connection, he suggests using the same method as proposed in BIP 339 without needing to bump the protocol version. Having a standard understanding of how other network clients operate would be helpful in this regard.However, there are concerns about the requirement to ignore unknown messages, as it is both a protocol-breaking change and poor protocol design. Changes to version negotiation itself can be problematic. Daftuar proposes making features optional at the new protocol level, allowing each client to limit its communication to the negotiated protocol and ignore unsupported/disabled features.In addition to Daftuar's proposal, the context discusses the inclusion of negotiation utility functions in a bip, specifically a "polite disconnect" function for nodes that do not want to connect due to incompatibility. It suggests standardizing naming conventions and negotiation message types to avoid different systems and limit the bip to defining ignorable vs. non-ignorable message types. This would make it easier for old nodes to apply generic rules around reporting, rejecting or responding to unknown feature negotiations versus untagged messages which could be a negotiation or something else.Daftuar hopes to receive feedback on any potential issues with his proposal to prevent disruption in deploying future peer-to-peer changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_New-tipe-of-outputs-that-saves-space-and-give-more-privacy.xml b/static/bitcoin-dev/Aug_2020/combined_New-tipe-of-outputs-that-saves-space-and-give-more-privacy.xml index d47514e141..35346c81f5 100644 --- a/static/bitcoin-dev/Aug_2020/combined_New-tipe-of-outputs-that-saves-space-and-give-more-privacy.xml +++ b/static/bitcoin-dev/Aug_2020/combined_New-tipe-of-outputs-that-saves-space-and-give-more-privacy.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - New tipe of outputs that saves space and give more privacy - 2023-08-02T02:38:41.576826+00:00 - - Jeremy 2020-08-25 15:24:46+00:00 - - - Jule.Adka 2020-08-25 13:42:05+00:00 - + 2025-09-26T15:54:31.230889+00:00 + python-feedgen + + + [bitcoin-dev] New tipe of outputs that saves space and give more privacy Jule.Adka + 2020-08-25T13:42:00.000Z + + + Jeremy + 2020-08-25T15:24:00.000Z + + - python-feedgen + 2 Combined summary - New tipe of outputs that saves space and give more privacy - 2023-08-02T02:38:41.576826+00:00 + 2025-09-26T15:54:31.231404+00:00 - A new proposal has been put forward by Jule.Adka to address the scalability and privacy concerns surrounding Bitcoin transactions. The proposal suggests using a Mekelized Output Set and the p2mos (pay to Mekelized Output Set) standard as a solution. Instead of listing all the outputs, the proposal recommends only specifying a Markle root. When a coin is spent, the user provides a Merkle Path and proof that their output exists. This approach significantly reduces the amount of data generated by transactions, resulting in a 49 bytes-wide output set regardless of the number of outputs. Only peers have knowledge of the number and value of the outputs, enhancing privacy. The proposal also resolves privacy issues related to Equal-output CoinJoin and different output types.To implement this proposal, an opcode may be required to direct nodes to the witness data for finding the actual output. The amount is preserved for compatibility and mining fee calculations, even though miners are unaware of the locked value. The fee calculus remains unchanged. By utilizing p2mos, information about outputs remains private until they are spent. This not only saves space in blocks but also reduces the size of transactions for SPV nodes, without considering the witness data. However, implementing this approach as a soft-fork presents challenges.Old nodes can still accept this type of transaction if it is made as "anyone can spend" in the current consensus. However, on a second spend, the node will interpret it as a double spend and invalidate it. While the proposal offers significant benefits, there are some drawbacks. It requires increased coordination between wallets, poses computational challenges for validators, and necessitates additional bandwidth for downloading the witness data. Nonetheless, retro compatibility is possible with implementation as a soft-fork. 2020-08-25T15:24:46+00:00 + A new proposal has been put forward by Jule.Adka to address the scalability and privacy concerns surrounding Bitcoin transactions. The proposal suggests using a Mekelized Output Set and the p2mos (pay to Mekelized Output Set) standard as a solution. Instead of listing all the outputs, the proposal recommends only specifying a Markle root. When a coin is spent, the user provides a Merkle Path and proof that their output exists. This approach significantly reduces the amount of data generated by transactions, resulting in a 49 bytes-wide output set regardless of the number of outputs. Only peers have knowledge of the number and value of the outputs, enhancing privacy. The proposal also resolves privacy issues related to Equal-output CoinJoin and different output types.To implement this proposal, an opcode may be required to direct nodes to the witness data for finding the actual output. The amount is preserved for compatibility and mining fee calculations, even though miners are unaware of the locked value. The fee calculus remains unchanged. By utilizing p2mos, information about outputs remains private until they are spent. This not only saves space in blocks but also reduces the size of transactions for SPV nodes, without considering the witness data. However, implementing this approach as a soft-fork presents challenges.Old nodes can still accept this type of transaction if it is made as "anyone can spend" in the current consensus. However, on a second spend, the node will interpret it as a double spend and invalidate it. While the proposal offers significant benefits, there are some drawbacks. It requires increased coordination between wallets, poses computational challenges for validators, and necessitates additional bandwidth for downloading the witness data. Nonetheless, retro compatibility is possible with implementation as a soft-fork. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_Revisiting-squaredness-tiebreaker-for-R-point-in-BIP340.xml b/static/bitcoin-dev/Aug_2020/combined_Revisiting-squaredness-tiebreaker-for-R-point-in-BIP340.xml index b24c1516de..264cf01980 100644 --- a/static/bitcoin-dev/Aug_2020/combined_Revisiting-squaredness-tiebreaker-for-R-point-in-BIP340.xml +++ b/static/bitcoin-dev/Aug_2020/combined_Revisiting-squaredness-tiebreaker-for-R-point-in-BIP340.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Revisiting squaredness tiebreaker for R point in BIP340 - 2023-08-02T02:35:47.729379+00:00 - - Pieter Wuille 2020-08-27 01:10:21+00:00 - - - John Newbery 2020-08-21 08:50:49+00:00 - - - Pieter Wuille 2020-08-19 23:16:17+00:00 - - - Lloyd Fournier 2020-08-13 05:31:58+00:00 - - - Nadav Kohen 2020-08-12 20:19:01+00:00 - - - Pieter Wuille 2020-08-12 18:49:56+00:00 - + 2025-09-26T15:54:29.118826+00:00 + python-feedgen + + + [bitcoin-dev] Revisiting squaredness tiebreaker for R point in BIP340 Pieter Wuille + 2020-08-12T18:49:00.000Z + + + Nadav Kohen + 2020-08-12T20:19:00.000Z + + + Lloyd Fournier + 2020-08-13T05:31:00.000Z + + + Pieter Wuille + 2020-08-19T23:16:00.000Z + + + John Newbery + 2020-08-21T08:50:00.000Z + + + Pieter Wuille + 2020-08-27T01:10:00.000Z + + - python-feedgen + 2 Combined summary - Revisiting squaredness tiebreaker for R point in BIP340 - 2023-08-02T02:35:47.729379+00:00 + 2025-09-26T15:54:29.119692+00:00 - On August 21, 2020, John Newbery suggested changing the proposal and implementation to use even tie-breakers everywhere. The comments received unanimously supported this change, reducing the mental overhead needed for explaining design decisions. Pieter Wuille expressed his happiness with the outcome of the change. Wuille proposed changing the tiebreaker used in conveying the Y coordinate of points in the BIP340 draft. Currently, squaredness is used as the tiebreaker for the R point inside signatures, while evenness is used for public keys. Recent developments have shown that determining evenness may be more efficient than squaredness. Wuille provides numbers that indicate the expected performance change from squareness to evenness, with positive numbers indicating that evenness is faster. Using a single tiebreaker for R points and public keys simplifies explanations and makes it easier for implementers and developers to understand. Changing to even tiebreakers everywhere may improve cryptographic code speedups by a couple of percent. Wuille suggests that changing the proposal and implementation to use even tiebreakers everywhere would be beneficial and worth considering.Pieter Wuille proposes changing the tiebreaker rule for block validation. Currently, blocks with an odd number of transactions have a higher chance of being orphaned due to a tiebreaker rule that prioritizes the block with the lowest hash. Wuille suggests changing the rule to prioritize the block with the even number of transactions. Following positive responses, Wuille has created a patch to implement the change and plans to submit it to the BIPs repository if there are no further arguments against it.Wuille also suggests reconsidering the use of squaredness as a tie-breaker for conveying the Y coordinate of points in BIP340. Recent developments have shown that using evenness as the tiebreaker may be faster. The impact of using evenness instead of squaredness on performance varies depending on hardware and algorithmic optimizations. While there may be a small speedup in verification and a slowdown in signing, the change is relatively simple to implement and may simplify code maintenance. Other developers are invited to share their thoughts on the matter.Nadav, a maintainer of Bitcoin-S and secp256k1 bindings, supports the change in tiebreaker for conveying the Y coordinate of points. Performance tests show that changing the tiebreaker will have a positive impact on verification and signing speed. The change involves modifying the BIP, proposed implementation, test vectors, and other draft implementations. Nadav believes that it is worth making the switch.The current BIP340 draft uses two different tiebreakers for conveying the Y coordinate of points. The R point inside signatures uses squaredness while for public keys evenness is used. Recent developments show that using evenness may be a better choice than squaredness. The justification for choosing squaredness as a tiebreaker was performance-related, but it slows down signing and is a less conventional choice. The proposed change involves modifying the BIP, libsecp256k1, and Bitcoin Core. The impact of changing the standard at this stage must be weighed against the relatively simple change required. 2020-08-27T01:10:21+00:00 + On August 21, 2020, John Newbery suggested changing the proposal and implementation to use even tie-breakers everywhere. The comments received unanimously supported this change, reducing the mental overhead needed for explaining design decisions. Pieter Wuille expressed his happiness with the outcome of the change. Wuille proposed changing the tiebreaker used in conveying the Y coordinate of points in the BIP340 draft. Currently, squaredness is used as the tiebreaker for the R point inside signatures, while evenness is used for public keys. Recent developments have shown that determining evenness may be more efficient than squaredness. Wuille provides numbers that indicate the expected performance change from squareness to evenness, with positive numbers indicating that evenness is faster. Using a single tiebreaker for R points and public keys simplifies explanations and makes it easier for implementers and developers to understand. Changing to even tiebreakers everywhere may improve cryptographic code speedups by a couple of percent. Wuille suggests that changing the proposal and implementation to use even tiebreakers everywhere would be beneficial and worth considering.Pieter Wuille proposes changing the tiebreaker rule for block validation. Currently, blocks with an odd number of transactions have a higher chance of being orphaned due to a tiebreaker rule that prioritizes the block with the lowest hash. Wuille suggests changing the rule to prioritize the block with the even number of transactions. Following positive responses, Wuille has created a patch to implement the change and plans to submit it to the BIPs repository if there are no further arguments against it.Wuille also suggests reconsidering the use of squaredness as a tie-breaker for conveying the Y coordinate of points in BIP340. Recent developments have shown that using evenness as the tiebreaker may be faster. The impact of using evenness instead of squaredness on performance varies depending on hardware and algorithmic optimizations. While there may be a small speedup in verification and a slowdown in signing, the change is relatively simple to implement and may simplify code maintenance. Other developers are invited to share their thoughts on the matter.Nadav, a maintainer of Bitcoin-S and secp256k1 bindings, supports the change in tiebreaker for conveying the Y coordinate of points. Performance tests show that changing the tiebreaker will have a positive impact on verification and signing speed. The change involves modifying the BIP, proposed implementation, test vectors, and other draft implementations. Nadav believes that it is worth making the switch.The current BIP340 draft uses two different tiebreakers for conveying the Y coordinate of points. The R point inside signatures uses squaredness while for public keys evenness is used. Recent developments show that using evenness may be a better choice than squaredness. The justification for choosing squaredness as a tiebreaker was performance-related, but it slows down signing and is a less conventional choice. The proposed change involves modifying the BIP, libsecp256k1, and Bitcoin Core. The impact of changing the standard at this stage must be weighed against the relatively simple change required. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_Smaller-Transactions-with-PubRef.xml b/static/bitcoin-dev/Aug_2020/combined_Smaller-Transactions-with-PubRef.xml index 78aca1cf87..4d986efe75 100644 --- a/static/bitcoin-dev/Aug_2020/combined_Smaller-Transactions-with-PubRef.xml +++ b/static/bitcoin-dev/Aug_2020/combined_Smaller-Transactions-with-PubRef.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Smaller Transactions with PubRef - 2023-08-02T02:32:11.433756+00:00 - - ZmnSCPxj 2020-08-02 14:22:30+00:00 - - - Mike Brooks 2020-08-02 01:12:16+00:00 - - - ZmnSCPxj 2020-08-02 00:36:08+00:00 - - - Mike Brooks 2020-08-01 05:09:25+00:00 - + 2025-09-26T15:54:37.738319+00:00 + python-feedgen + + + [bitcoin-dev] Smaller Transactions with PubRef Mike Brooks + 2020-08-01T05:09:00.000Z + + + ZmnSCPxj + 2020-08-02T00:36:00.000Z + + + Mike Brooks + 2020-08-02T01:12:00.000Z + + + ZmnSCPxj + 2020-08-02T14:22:00.000Z + + - python-feedgen + 2 Combined summary - Smaller Transactions with PubRef - 2023-08-02T02:32:11.433756+00:00 + 2025-09-26T15:54:37.738950+00:00 - In an email exchange, ZmnSCPxj discussed the issue with SCRIPT re-evaluation and reorgs. They explained that reorgs cause nodes to do more processing even with Floating-point Nakamoto Consensus. This is because a node can still observe a reorg if it first receives a lower-scored block before a higher-scored block. This increases the processing load on validating fullnodes and prevents pruning from working for them.Miners can also mount a DoS on validating fullnodes with `OP_PUBREF` and Floating-Point Nakamoto Consensus by re-mining the same block and broadcasting it if it has a higher score than the previous chain tip. This locks the blockchain and increases the load on fullnodes, which have to re-validate uses of `OP_PUBREF` that might refer to the chain tip.ZmnSCPxj responded to Michael's suggestion for solving re-orgs in a different way by saying "Hard NAK." They pointed out important problems with Michael's proposal, such as encouraging address reuse, hurting fungibility and privacy, preventing pruning, requiring the creation of another index to previous block data, increasing requirements on fullnodes, and needing SCRIPT to be re-evaluated on transactions arriving in new blocks to protect against reorgs of the chaintip, particularly `OP_PUBREF` references near the chaintip. ZmnSCPxj noted that none of these issues were addressed in Michael's proposal and that the proposal only considered clients without considering the implications for validators.The email thread includes an HTML attachment and a non-text attachment titled "Floating-Point Nakamoto Consensus.pdf," which may contain further information related to the discussion.In response to an original posting, ZmnSCPxj highlighted several important issues with the proposed opcode called Hard NAK. These issues include hurting fungibility and privacy by encouraging address reuse, preventing pruning, requiring the creation of another index to previous block data, which increases requirements on fullnodes, and needing SCRIPT to be re-evaluated on transactions arriving in new blocks to protect against reorgs of the chaintip. ZmnSCPxj noted that none of these issues have been addressed in the current proposal and that it only considers clients without considering what validators would need to implement to validate new blocks with this opcode.The email thread also mentions a BIP that describes a new opcode enabling transactions that are about 37% smaller than traditional single-source segwit transactions. The size savings vary based on the number of inputs. This pursuit of smaller transactions is important for Inclusive Accountability as it reduces the amount of data recorded on the chain, leading to improved frugality by allowing more transactions to be confirmed in a block and enabling small value inputs to be referenced without losing unrecoverable value due to transaction overhead. The BIP can be found on GitHub at https://github.com/TheRook/bip-pubref/blob/master/bip-PubRef.mediawiki.On the Ethereum side, a variant of this technology called Ditto Transactions is described, which can be found at https://ethereum-magicians.org/t/eip-ditto-transactions/4455. 2020-08-02T14:22:30+00:00 + In an email exchange, ZmnSCPxj discussed the issue with SCRIPT re-evaluation and reorgs. They explained that reorgs cause nodes to do more processing even with Floating-point Nakamoto Consensus. This is because a node can still observe a reorg if it first receives a lower-scored block before a higher-scored block. This increases the processing load on validating fullnodes and prevents pruning from working for them.Miners can also mount a DoS on validating fullnodes with `OP_PUBREF` and Floating-Point Nakamoto Consensus by re-mining the same block and broadcasting it if it has a higher score than the previous chain tip. This locks the blockchain and increases the load on fullnodes, which have to re-validate uses of `OP_PUBREF` that might refer to the chain tip.ZmnSCPxj responded to Michael's suggestion for solving re-orgs in a different way by saying "Hard NAK." They pointed out important problems with Michael's proposal, such as encouraging address reuse, hurting fungibility and privacy, preventing pruning, requiring the creation of another index to previous block data, increasing requirements on fullnodes, and needing SCRIPT to be re-evaluated on transactions arriving in new blocks to protect against reorgs of the chaintip, particularly `OP_PUBREF` references near the chaintip. ZmnSCPxj noted that none of these issues were addressed in Michael's proposal and that the proposal only considered clients without considering the implications for validators.The email thread includes an HTML attachment and a non-text attachment titled "Floating-Point Nakamoto Consensus.pdf," which may contain further information related to the discussion.In response to an original posting, ZmnSCPxj highlighted several important issues with the proposed opcode called Hard NAK. These issues include hurting fungibility and privacy by encouraging address reuse, preventing pruning, requiring the creation of another index to previous block data, which increases requirements on fullnodes, and needing SCRIPT to be re-evaluated on transactions arriving in new blocks to protect against reorgs of the chaintip. ZmnSCPxj noted that none of these issues have been addressed in the current proposal and that it only considers clients without considering what validators would need to implement to validate new blocks with this opcode.The email thread also mentions a BIP that describes a new opcode enabling transactions that are about 37% smaller than traditional single-source segwit transactions. The size savings vary based on the number of inputs. This pursuit of smaller transactions is important for Inclusive Accountability as it reduces the amount of data recorded on the chain, leading to improved frugality by allowing more transactions to be confirmed in a block and enabling small value inputs to be referenced without losing unrecoverable value due to transaction overhead. The BIP can be found on GitHub at https://github.com/TheRook/bip-pubref/blob/master/bip-PubRef.mediawiki.On the Ethereum side, a variant of this technology called Ditto Transactions is described, which can be found at https://ethereum-magicians.org/t/eip-ditto-transactions/4455. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_Time-to-lower-minrelaytxfee-.xml b/static/bitcoin-dev/Aug_2020/combined_Time-to-lower-minrelaytxfee-.xml index 090b47979c..b9ccfa7790 100644 --- a/static/bitcoin-dev/Aug_2020/combined_Time-to-lower-minrelaytxfee-.xml +++ b/static/bitcoin-dev/Aug_2020/combined_Time-to-lower-minrelaytxfee-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Time to lower minrelaytxfee ? - 2023-08-02T02:38:28.855383+00:00 - - Greg Sanders 2020-08-21 16:57:32+00:00 - - - Nadav Ivgi 2020-08-21 16:36:30+00:00 - - - Dan Bryant 2020-08-21 05:55:59+00:00 - + 2025-09-26T15:54:44.093117+00:00 + python-feedgen + + + [bitcoin-dev] Time to lower minrelaytxfee ? Dan Bryant + 2020-08-21T05:55:00.000Z + + + Nadav Ivgi + 2020-08-21T16:36:00.000Z + + + Greg Sanders + 2020-08-21T16:57:00.000Z + + - python-feedgen + 2 Combined summary - Time to lower minrelaytxfee ? - 2023-08-02T02:38:28.855383+00:00 + 2025-09-26T15:54:44.093645+00:00 - The bitcoin-dev mailing list recently discussed the possibility of reducing the minimum relay transaction fee (minrelaytxfee) on the Bitcoin network. The current fee, which was set five years ago when Bitcoin was trading at $255, is 1000 sat/vkB. However, some argue that this fee is too high and a reduction to as low as 22 sat/vKB would be more appropriate. The proposed reduction is driven by the need for ultra-low-fee on-chain transactions due to growing adoption of the Lightning Network.While it is acknowledged that reducing the minrelaytxfee could make denial of service attacks cheaper, proponents argue that thoroughly testing any changes can prevent bugs that could cause issues on the peer-to-peer network. The discussion also referenced previous pull requests (#13922 and #13990) related to reducing the minrelaytxfee.The concern raised is that having large portions of the network using a different minrelayfee could make it easier to double-spend unconfirmed non-rbf transactions. Node operators that accept unconfirmed payments with a minrelayfee higher than what other nodes/miners are typically accepting would be at risk. Although relying on unconfirmed transactions is discouraged, this potential issue is worth considering.Dan Bryant suggests further reducing the minrelaytxfee to allow for ultra-low-fee on-chain transactions, which are needed for the growing adoption of the Lightning Network. He proposes reducing the fee to 22 sat/vkB, but notes that a conservative reduction to 100 or 50 sat/vkB would also be welcome. Two years ago, there was a pull request to reduce the fee from 1000 to 200 sat/vkB, but it was eventually closed in favor of another pull request.Bryant questions why changing the default minrelaytxfee would be detrimental to node operation if it is already parameterized and configurable in bitcoin.conf. He provides various reference links, including the commit for lowering the minrelaytxfee, the pull requests for further fee reductions, and the need for ultra-low fee transactions to accommodate the growth of the Lightning Network.Overall, the discussion revolves around the possibility of reducing the minimum relay transaction fee on the Bitcoin network. While some argue for a significant reduction to facilitate ultra-low-fee on-chain transactions for the Lightning Network, concerns about potential risks and double-spending vulnerabilities are also raised. Despite being configurable in bitcoin.conf, the impact of changing the default minrelaytxfee on node operation is still uncertain. The reference links provided offer more information on the topic. 2020-08-21T16:57:32+00:00 + The bitcoin-dev mailing list recently discussed the possibility of reducing the minimum relay transaction fee (minrelaytxfee) on the Bitcoin network. The current fee, which was set five years ago when Bitcoin was trading at $255, is 1000 sat/vkB. However, some argue that this fee is too high and a reduction to as low as 22 sat/vKB would be more appropriate. The proposed reduction is driven by the need for ultra-low-fee on-chain transactions due to growing adoption of the Lightning Network.While it is acknowledged that reducing the minrelaytxfee could make denial of service attacks cheaper, proponents argue that thoroughly testing any changes can prevent bugs that could cause issues on the peer-to-peer network. The discussion also referenced previous pull requests (#13922 and #13990) related to reducing the minrelaytxfee.The concern raised is that having large portions of the network using a different minrelayfee could make it easier to double-spend unconfirmed non-rbf transactions. Node operators that accept unconfirmed payments with a minrelayfee higher than what other nodes/miners are typically accepting would be at risk. Although relying on unconfirmed transactions is discouraged, this potential issue is worth considering.Dan Bryant suggests further reducing the minrelaytxfee to allow for ultra-low-fee on-chain transactions, which are needed for the growing adoption of the Lightning Network. He proposes reducing the fee to 22 sat/vkB, but notes that a conservative reduction to 100 or 50 sat/vkB would also be welcome. Two years ago, there was a pull request to reduce the fee from 1000 to 200 sat/vkB, but it was eventually closed in favor of another pull request.Bryant questions why changing the default minrelaytxfee would be detrimental to node operation if it is already parameterized and configurable in bitcoin.conf. He provides various reference links, including the commit for lowering the minrelaytxfee, the pull requests for further fee reductions, and the need for ultra-low fee transactions to accommodate the growth of the Lightning Network.Overall, the discussion revolves around the possibility of reducing the minimum relay transaction fee on the Bitcoin network. While some argue for a significant reduction to facilitate ultra-low-fee on-chain transactions for the Lightning Network, concerns about potential risks and double-spending vulnerabilities are also raised. Despite being configurable in bitcoin.conf, the impact of changing the default minrelaytxfee on node operation is still uncertain. The reference links provided offer more information on the topic. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2020/combined_reviving-op-difficulty.xml b/static/bitcoin-dev/Aug_2020/combined_reviving-op-difficulty.xml index a8dc717ec1..c6cedff100 100644 --- a/static/bitcoin-dev/Aug_2020/combined_reviving-op-difficulty.xml +++ b/static/bitcoin-dev/Aug_2020/combined_reviving-op-difficulty.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - reviving op_difficulty - 2023-08-02T02:37:38.474787+00:00 - - Jeremy 2020-09-02 18:27:00+00:00 - - - Thomas Hartman 2020-09-02 14:40:28+00:00 - - - Thomas Hartman 2020-09-01 20:07:21+00:00 - - - David A. Harding 2020-08-22 16:46:20+00:00 - - - Thomas Hartman 2020-08-19 23:32:25+00:00 - - - Thomas Hartman 2020-08-19 21:15:08+00:00 - - - ZmnSCPxj 2020-08-17 23:14:00+00:00 - - - Tier Nolan 2020-08-17 21:55:04+00:00 - - - Thomas Hartman 2020-08-17 19:48:27+00:00 - - - ZmnSCPxj 2020-08-17 05:04:42+00:00 - - - Anthony Towns 2020-08-16 22:29:23+00:00 - - - Tier Nolan 2020-08-16 18:59:25+00:00 - - - Thomas Hartman 2020-08-16 15:41:30+00:00 - + 2025-09-26T15:54:41.979888+00:00 + python-feedgen + + + [bitcoin-dev] reviving op_difficulty Thomas Hartman + 2020-08-16T15:41:00.000Z + + + Tier Nolan + 2020-08-16T18:59:00.000Z + + + Anthony Towns + 2020-08-16T22:29:00.000Z + + + ZmnSCPxj + 2020-08-17T05:04:00.000Z + + + Thomas Hartman + 2020-08-17T19:48:00.000Z + + + Tier Nolan + 2020-08-17T21:55:00.000Z + + + ZmnSCPxj + 2020-08-17T23:14:00.000Z + + + Thomas Hartman + 2020-08-19T21:15:00.000Z + + + Thomas Hartman + 2020-08-19T23:32:00.000Z + + + David A. Harding + 2020-08-22T16:46:00.000Z + + + Thomas Hartman + 2020-09-01T20:07:00.000Z + + + Thomas Hartman + 2020-09-02T14:40:00.000Z + + + Jeremy + 2020-09-02T18:27:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - reviving op_difficulty - 2023-08-02T02:37:38.474787+00:00 + 2025-09-26T15:54:41.981355+00:00 - In a recent bitcoin-dev mailing list discussion, there have been proposals and discussions regarding the implementation of difficulty futures in Bitcoin. Tamas Blummer had initially proposed an additional opcode for enabling Bitcoin difficulty futures, but Jeremy Rubin introduced an alternate scheme that does not require changes to the Bitcoin protocol. This scheme takes advantage of the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposal involves creating conflicting spends from a multisig, with different nLockTime values based on the current height or time. Depending on the subsequent change in hashrate, either Alice or Bob will receive their payment first. This method can be embedded in a taproot commitment using OP_CLTV or OP_CSV instead of nLockTime.Thomas Hartman expressed admiration for Powswap, a platform that allows users to bet on the future hash rate of the Bitcoin network without protocol changes. However, he raised concerns about watchtowers to prevent fund sweeping by the losing party and the impact on lightning channels. Hartman also suggested the possibility of betting on specific time slices and difficulty thresholds using Powswap. Currently, Powswap only creates contracts from the current time to the future, but Hartman proposed creating synthetic hashrate binaries by subtracting the time from the current time to B from the time from the current time to A. He also questioned the feasibility of betting on the first six blocks after retarget being found under an hour and the new difficulty exceeding a certain threshold.The community mourned the loss of Tamas Blummer, a developer who proposed the opcode for Bitcoin difficulty futures. Jeremy Rubin's scheme was introduced as an alternative method that does not require protocol changes and leverages the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposed scheme is compatible with off-chain commitments and can be embedded in a taproot commitment using OP_CLTV or OP_CSV. The author of the discussion proposed using a packed difficulty target instead of using op_diff to calculate the ratio, and expressed their satisfaction with not having to deal with floating point numbers.Tier Nolan proposed a new method for speculation contracts that considers the ratio between future and current difficulty instead of difficulty itself. This ratio can be obtained from packed representations already included in blocks. Nolan provided an example using the current and last difficulties and targets, demonstrating how op_diff could return the ratio for ticks instead of difficulty.The discussion explored the creation of difficulty futures instruments using Taproot MAST and op_diff. The proposed idea involved creating partial versions of difficulty futures funded by Bob and spendable by Alice after a certain number of blocks. A payment from Alice to Bob with a hash lock was also suggested to enable this process. While it would be simpler to have all outputs in the same transaction, the proposed construction requires two signatures for the hash-branch to ensure specific contract payouts.In another email thread, a solution to binary payouts was discussed. Taproot MAST was suggested as an option, and another proposal involved paying outputs based on the diff value using division and binary operators. The payout would be enabled or disabled based on the value of D. This solution has logarithmic performance in terms of the number of ticks.Taproot MAST was mentioned again as a potential solution to enable difficulty futures instruments. The proposal focused on creating partial versions of difficulty futures funded by one party and spendable by another party after a certain period of time. A hash lock on the payment with a preimage secret was suggested to ensure the correct execution of the contract. The goal is to eventually implement this with lightning and high-frequency trading.Thomas Hartman proposed adding an opcode called "op_difficulty" to enable binary options on difficulty futures. However, another approach suggested using taproot's annex concept to create restrictions based on specific difficulty values or ranges. Participants would deposit into a UTXO and construct signed payouts timelocked for the future date. The payouts would go to different parties depending on the predicted difficulty range. Specifying an exact value for the difficulty was considered better for privacy, but it would require multiple signatures for pre-signed payouts.The discussion also touched upon the concept of binary options and pseudo-continuous futures. It was suggested that any opcode can be considered a binary option, but creating numerous outputs with different thresholds is necessary for a pseudo-continuous future. Taproot MAST was mentioned as a way to improve this method by generating fresh keypairs and tapleaf scripts.Another proposal for enabling binary options on difficulty futures involved using an operation called "op_difficulty" or taproot's annex concept. The protocol design included participants depositing into a UTXO and constructing signed payouts timelocked for the future date. The payouts would be based on specific difficulty values or ranges. The use of an exact difficulty value was considered better for blockchain size and privacy, although it would require multiple signatures for pre-signed payouts.Lastly, the idea of adding a single op_difficulty operation to enable binary options on difficulty 2020-09-02T18:27:00+00:00 + In a recent bitcoin-dev mailing list discussion, there have been proposals and discussions regarding the implementation of difficulty futures in Bitcoin. Tamas Blummer had initially proposed an additional opcode for enabling Bitcoin difficulty futures, but Jeremy Rubin introduced an alternate scheme that does not require changes to the Bitcoin protocol. This scheme takes advantage of the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposal involves creating conflicting spends from a multisig, with different nLockTime values based on the current height or time. Depending on the subsequent change in hashrate, either Alice or Bob will receive their payment first. This method can be embedded in a taproot commitment using OP_CLTV or OP_CSV instead of nLockTime.Thomas Hartman expressed admiration for Powswap, a platform that allows users to bet on the future hash rate of the Bitcoin network without protocol changes. However, he raised concerns about watchtowers to prevent fund sweeping by the losing party and the impact on lightning channels. Hartman also suggested the possibility of betting on specific time slices and difficulty thresholds using Powswap. Currently, Powswap only creates contracts from the current time to the future, but Hartman proposed creating synthetic hashrate binaries by subtracting the time from the current time to B from the time from the current time to A. He also questioned the feasibility of betting on the first six blocks after retarget being found under an hour and the new difficulty exceeding a certain threshold.The community mourned the loss of Tamas Blummer, a developer who proposed the opcode for Bitcoin difficulty futures. Jeremy Rubin's scheme was introduced as an alternative method that does not require protocol changes and leverages the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposed scheme is compatible with off-chain commitments and can be embedded in a taproot commitment using OP_CLTV or OP_CSV. The author of the discussion proposed using a packed difficulty target instead of using op_diff to calculate the ratio, and expressed their satisfaction with not having to deal with floating point numbers.Tier Nolan proposed a new method for speculation contracts that considers the ratio between future and current difficulty instead of difficulty itself. This ratio can be obtained from packed representations already included in blocks. Nolan provided an example using the current and last difficulties and targets, demonstrating how op_diff could return the ratio for ticks instead of difficulty.The discussion explored the creation of difficulty futures instruments using Taproot MAST and op_diff. The proposed idea involved creating partial versions of difficulty futures funded by Bob and spendable by Alice after a certain number of blocks. A payment from Alice to Bob with a hash lock was also suggested to enable this process. While it would be simpler to have all outputs in the same transaction, the proposed construction requires two signatures for the hash-branch to ensure specific contract payouts.In another email thread, a solution to binary payouts was discussed. Taproot MAST was suggested as an option, and another proposal involved paying outputs based on the diff value using division and binary operators. The payout would be enabled or disabled based on the value of D. This solution has logarithmic performance in terms of the number of ticks.Taproot MAST was mentioned again as a potential solution to enable difficulty futures instruments. The proposal focused on creating partial versions of difficulty futures funded by one party and spendable by another party after a certain period of time. A hash lock on the payment with a preimage secret was suggested to ensure the correct execution of the contract. The goal is to eventually implement this with lightning and high-frequency trading.Thomas Hartman proposed adding an opcode called "op_difficulty" to enable binary options on difficulty futures. However, another approach suggested using taproot's annex concept to create restrictions based on specific difficulty values or ranges. Participants would deposit into a UTXO and construct signed payouts timelocked for the future date. The payouts would go to different parties depending on the predicted difficulty range. Specifying an exact value for the difficulty was considered better for privacy, but it would require multiple signatures for pre-signed payouts.The discussion also touched upon the concept of binary options and pseudo-continuous futures. It was suggested that any opcode can be considered a binary option, but creating numerous outputs with different thresholds is necessary for a pseudo-continuous future. Taproot MAST was mentioned as a way to improve this method by generating fresh keypairs and tapleaf scripts.Another proposal for enabling binary options on difficulty futures involved using an operation called "op_difficulty" or taproot's annex concept. The protocol design included participants depositing into a UTXO and constructing signed payouts timelocked for the future date. The payouts would be based on specific difficulty values or ranges. The use of an exact difficulty value was considered better for blockchain size and privacy, although it would require multiple signatures for pre-signed payouts.Lastly, the idea of adding a single op_difficulty operation to enable binary options on difficulty - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Announcing-bip174-org-a-web-based-PSBT-viewer-and-editor.xml b/static/bitcoin-dev/Aug_2021/combined_Announcing-bip174-org-a-web-based-PSBT-viewer-and-editor.xml index a6c9dc916a..095680b357 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Announcing-bip174-org-a-web-based-PSBT-viewer-and-editor.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Announcing-bip174-org-a-web-based-PSBT-viewer-and-editor.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Announcing bip174.org, a web-based PSBT viewer and editor - 2023-08-02T04:37:50.423206+00:00 - - Alekos Filini 2021-08-26 14:07:30+00:00 - - - Alekos Filini 2021-08-26 13:57:47+00:00 - - - Prayank 2021-08-26 09:20:02+00:00 - - - Christopher Allen 2021-08-25 20:05:31+00:00 - - - Alekos Filini 2021-08-25 18:03:24+00:00 - + 2025-09-26T15:38:25.179906+00:00 + python-feedgen + + + [bitcoin-dev] Announcing bip174.org, a web-based PSBT viewer and editor Alekos Filini + 2021-08-25T18:03:00.000Z + + + Christopher Allen + 2021-08-25T20:05:00.000Z + + + Prayank + 2021-08-26T09:20:00.000Z + + + Alekos Filini + 2021-08-26T13:57:00.000Z + + + Alekos Filini + 2021-08-26T14:07:00.000Z + + - python-feedgen + 2 Combined summary - Announcing bip174.org, a web-based PSBT viewer and editor - 2023-08-02T04:37:50.423206+00:00 + 2025-09-26T15:38:25.180733+00:00 - Prayank, who is not skilled in UI/UX, expressed gratitude to Alekos for launching bip174.org, a PSBT viewer and editor that runs in the browser. Prayank suggested adding a light and dark theme switch option and color highlighting for certain elements. He also proposed a similar project for experimenting with descriptors. In response, Alekos mentioned the availability of a web-based tool on BDK's website for building descriptors graphically based on Scratch.Alekos Filini, a member of the Bitcoin development community, announced the launch of bip174.org, a PSBT viewer and editor that operates in the browser. The Airgapped Wallet Community has requested the addition of UR-based animated QRs as an output option on the website. This is because advanced hardware and software wallets now support Airgapped UR/QR PSBT signing. There are multiple libraries available in various languages to support these UR QRs, making it easy to output them from the site. Furthermore, major web-based transaction coordinator services plan to incorporate browser scanning of PSBTs using laptop cameras. Christopher Allen shared a video example demonstrating this capability between the Foundation Devices hardware wallet and Blue Wallet.bip174.org allows users to paste a PSBT to view its content. Any changes made to the fields within the PSBT are automatically updated on the site. The website includes pre-built examples for quick testing. Daniela Brozzoni and Alekos developed this tool to simplify the dumping and modification of PSBTs they encounter in their daily work. Inspired by bip32.org, the web app is entirely built in Rust compiled to WASM. Contributions, feedback, and bug reports are encouraged, and the source code can be found on GitHub. 2021-08-26T14:07:30+00:00 + Prayank, who is not skilled in UI/UX, expressed gratitude to Alekos for launching bip174.org, a PSBT viewer and editor that runs in the browser. Prayank suggested adding a light and dark theme switch option and color highlighting for certain elements. He also proposed a similar project for experimenting with descriptors. In response, Alekos mentioned the availability of a web-based tool on BDK's website for building descriptors graphically based on Scratch.Alekos Filini, a member of the Bitcoin development community, announced the launch of bip174.org, a PSBT viewer and editor that operates in the browser. The Airgapped Wallet Community has requested the addition of UR-based animated QRs as an output option on the website. This is because advanced hardware and software wallets now support Airgapped UR/QR PSBT signing. There are multiple libraries available in various languages to support these UR QRs, making it easy to output them from the site. Furthermore, major web-based transaction coordinator services plan to incorporate browser scanning of PSBTs using laptop cameras. Christopher Allen shared a video example demonstrating this capability between the Foundation Devices hardware wallet and Blue Wallet.bip174.org allows users to paste a PSBT to view its content. Any changes made to the fields within the PSBT are automatically updated on the site. The website includes pre-built examples for quick testing. Daniela Brozzoni and Alekos developed this tool to simplify the dumping and modification of PSBTs they encounter in their daily work. Inspired by bip32.org, the web app is entirely built in Rust compiled to WASM. Contributions, feedback, and bug reports are encouraged, and the source code can be found on GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml b/static/bitcoin-dev/Aug_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml index 08b17b37d1..4f47411bbb 100644 --- a/static/bitcoin-dev/Aug_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml +++ b/static/bitcoin-dev/Aug_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - BIP Proposals for Output Script Descriptors - 2023-08-02T04:16:38.460464+00:00 - - Christopher Allen 2021-08-05 20:49:43+00:00 - - - Sjors Provoost 2021-08-05 14:27:12+00:00 - - - Daniel Bayerdorffer 2021-07-04 17:56:28+00:00 - - - Craig Raw 2021-07-03 14:00:51+00:00 - - - David A. Harding 2021-07-03 10:05:40+00:00 - - - Craig Raw 2021-07-03 08:35:48+00:00 - - - Andrew Chow 2021-07-03 05:12:35+00:00 - - - David A. Harding 2021-07-03 03:24:05+00:00 - - - Andrew Chow 2021-07-02 20:05:45+00:00 - - - Andrew Chow 2021-06-29 22:35:49+00:00 - - - Christopher Allen 2021-06-29 22:22:39+00:00 - - - Andrew Chow 2021-06-29 21:14:39+00:00 - + 2025-09-26T15:38:29.385919+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposals for Output Script Descriptors Andrew Chow + 2021-06-29T21:14:00.000Z + + + Christopher Allen + 2021-06-29T22:22:00.000Z + + + Andrew Chow + 2021-06-29T22:35:00.000Z + + + Andrew Chow + 2021-07-02T20:05:00.000Z + + + David A. Harding + 2021-07-03T03:24:00.000Z + + + Andrew Chow + 2021-07-03T05:12:00.000Z + + + Craig Raw + 2021-07-03T08:35:00.000Z + + + David A. Harding + 2021-07-03T10:05:00.000Z + + + Craig Raw + 2021-07-03T14:00:00.000Z + + + Daniel Bayerdorffer + 2021-07-04T17:56:00.000Z + + + Sjors Provoost + 2021-08-05T14:27:00.000Z + + + Christopher Allen + 2021-08-05T20:49:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - BIP Proposals for Output Script Descriptors - 2023-08-02T04:16:38.461465+00:00 + 2025-09-26T15:38:29.387235+00:00 - In a discussion on the bitcoin-dev mailing list, Sjors Provoost proposed adding a birth date or minimum block height to the BIP 32 and BIP 88 standards for Hierarchical Deterministic Path Templates. He suggested using a metadata format to track this information alongside descriptors.The Airgap Wallet Community supports metadata in their UR standards, which use CBOR's tagging capability. The UR standards also provide efficient transport via QR codes or URLs. Interested parties can learn more about these standards by watching a video on Blockchain Commons Technology Overview or reading articles on URs, including guides for key material and SSKRs, as well as UR Request & Response. Additionally, there are specs available on Uniform Resources (UR) and HD Keys. For further questions, individuals can visit the Airgapped Wallet Community on GitHub.Bitcoin Core developer Andrew Chow has proposed formalizing the Output Script Descriptors in a set of 7 BIPs. These descriptors are used to describe collections of output scripts and offer a generic solution to issues with wallet backups and exports. The 7 BIPs specify various descriptors such as non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo descriptor, and opaque descriptors (raw, addr). The proposal also suggests including a birth date and metadata format to track birth data, gap limits, and other necessary information for future wallets. Another document outlines specifications for Bitcoin output script descriptors, specifically for P2WPKH and P2WSH formats (wpkh() and wsh() expressions), as well as P2PK, P2PKH, and P2SH formats (pk(), pkh(), and sh() expressions).There has been a debate on whether to use an apostrophe or 'h' in Bitcoin output script descriptors. Craig Raw argued that using an apostrophe allows for more whitespace and easier visual parsing, while David A. Harding countered that the difference in space usage is negligible and that using 'h' or 'H' avoids potential errors in shell-quoting and is more efficient for metal backups. Daniel Bayerdorffer of Numberall Stamp & Tool Co., Inc. recommended the Bitcoin Recovery Tag as a metal backup option that supports both apostrophes and 'h'. The discussion highlights the importance of considering user experience and practical considerations in the design of Bitcoin-related tools and protocols.The debate over using 'h' or an apostrophe in Bitcoin descriptors continued, with David A. Harding expressing concerns about using 'h' as it takes up more space and makes derivation paths and descriptors more difficult to read. However, Andrew Chow pointed out that the difference in space is only 0.7% and there are no issues with readability or transcription errors due to the use of a fixed character width font and checksums. Additionally, he mentioned that using apostrophes actually provides more whitespace and makes the path easier to parse visually. The real concern lies in using "-containing descriptors in a bourne-style shell, which can lead to loss of money. Ultimately, Raw agreed with Harding's points.David A. Harding proposed making "h"/"H" the preferred aliases instead of "'" in Bitcoin descriptors to improve user experience. However, Andrew Chow raised concerns about increased space usage and difficulty in reading descriptors and derivation paths. David suggested alternative options like completely eliminating "'", but it was not feasible due to widespread use of descriptors, or calculating the checksum over s/(h|H)/', which had been discussed before but not implemented due to the need for dumb checksum checkers that don't have to parse descriptors. In conclusion, the text was updated to use "h", but alternatives were still being considered.Andrew Chow has submitted a pull request to formalize Bitcoin Core's Output Script Descriptors into BIPs. The specifications are split into seven BIPs, with the first one providing general information and the rest specifying different descriptors. These descriptors offer a generic solution to issues with wallet backups by explicitly specifying script types and key derivation paths. They include non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), taproot descriptor (tr), combo descriptor, and opaque descriptors (raw, addr). Jeremy Rubin suggested collecting feedback through WIP PRs. Bitcoin Core has implemented pk(), pkh(), sh(), and tr() descriptors since version 0.17 and version 22.0.In an email exchange between Christopher Allen and Andrew Poelstra, the possibility of supporting time locks in descriptors other than 'raw' was discussed. Andrew mentioned that he expects miniscript to be a follow-up BIP that extends these descriptors and includes timelock functionality. Christopher shared a link to a document titled "Designing Multisig for Independence & Resilience" on Github, which discusses scenarios 2021-08-05T20:49:43+00:00 + In a discussion on the bitcoin-dev mailing list, Sjors Provoost proposed adding a birth date or minimum block height to the BIP 32 and BIP 88 standards for Hierarchical Deterministic Path Templates. He suggested using a metadata format to track this information alongside descriptors.The Airgap Wallet Community supports metadata in their UR standards, which use CBOR's tagging capability. The UR standards also provide efficient transport via QR codes or URLs. Interested parties can learn more about these standards by watching a video on Blockchain Commons Technology Overview or reading articles on URs, including guides for key material and SSKRs, as well as UR Request & Response. Additionally, there are specs available on Uniform Resources (UR) and HD Keys. For further questions, individuals can visit the Airgapped Wallet Community on GitHub.Bitcoin Core developer Andrew Chow has proposed formalizing the Output Script Descriptors in a set of 7 BIPs. These descriptors are used to describe collections of output scripts and offer a generic solution to issues with wallet backups and exports. The 7 BIPs specify various descriptors such as non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo descriptor, and opaque descriptors (raw, addr). The proposal also suggests including a birth date and metadata format to track birth data, gap limits, and other necessary information for future wallets. Another document outlines specifications for Bitcoin output script descriptors, specifically for P2WPKH and P2WSH formats (wpkh() and wsh() expressions), as well as P2PK, P2PKH, and P2SH formats (pk(), pkh(), and sh() expressions).There has been a debate on whether to use an apostrophe or 'h' in Bitcoin output script descriptors. Craig Raw argued that using an apostrophe allows for more whitespace and easier visual parsing, while David A. Harding countered that the difference in space usage is negligible and that using 'h' or 'H' avoids potential errors in shell-quoting and is more efficient for metal backups. Daniel Bayerdorffer of Numberall Stamp & Tool Co., Inc. recommended the Bitcoin Recovery Tag as a metal backup option that supports both apostrophes and 'h'. The discussion highlights the importance of considering user experience and practical considerations in the design of Bitcoin-related tools and protocols.The debate over using 'h' or an apostrophe in Bitcoin descriptors continued, with David A. Harding expressing concerns about using 'h' as it takes up more space and makes derivation paths and descriptors more difficult to read. However, Andrew Chow pointed out that the difference in space is only 0.7% and there are no issues with readability or transcription errors due to the use of a fixed character width font and checksums. Additionally, he mentioned that using apostrophes actually provides more whitespace and makes the path easier to parse visually. The real concern lies in using "-containing descriptors in a bourne-style shell, which can lead to loss of money. Ultimately, Raw agreed with Harding's points.David A. Harding proposed making "h"/"H" the preferred aliases instead of "'" in Bitcoin descriptors to improve user experience. However, Andrew Chow raised concerns about increased space usage and difficulty in reading descriptors and derivation paths. David suggested alternative options like completely eliminating "'", but it was not feasible due to widespread use of descriptors, or calculating the checksum over s/(h|H)/', which had been discussed before but not implemented due to the need for dumb checksum checkers that don't have to parse descriptors. In conclusion, the text was updated to use "h", but alternatives were still being considered.Andrew Chow has submitted a pull request to formalize Bitcoin Core's Output Script Descriptors into BIPs. The specifications are split into seven BIPs, with the first one providing general information and the rest specifying different descriptors. These descriptors offer a generic solution to issues with wallet backups by explicitly specifying script types and key derivation paths. They include non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), taproot descriptor (tr), combo descriptor, and opaque descriptors (raw, addr). Jeremy Rubin suggested collecting feedback through WIP PRs. Bitcoin Core has implemented pk(), pkh(), sh(), and tr() descriptors since version 0.17 and version 22.0.In an email exchange between Christopher Allen and Andrew Poelstra, the possibility of supporting time locks in descriptors other than 'raw' was discussed. Andrew mentioned that he expects miniscript to be a follow-up BIP that extends these descriptors and includes timelock functionality. Christopher shared a link to a document titled "Designing Multisig for Independence & Resilience" on Github, which discusses scenarios - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Bip-0039-Wordlist-Romanian.xml b/static/bitcoin-dev/Aug_2021/combined_Bip-0039-Wordlist-Romanian.xml index 8c90b806df..4ae821cf5d 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Bip-0039-Wordlist-Romanian.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Bip-0039-Wordlist-Romanian.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Bip-0039/Wordlist - Romanian - 2023-08-02T04:29:13.482604+00:00 - - Justin Valceanu 2021-08-05 06:16:27+00:00 - - - s7r 2021-08-04 22:29:07+00:00 - - - ic 2021-08-04 13:28:55+00:00 - - - Justin Valceanu 2021-08-04 10:30:37+00:00 - + 2025-09-26T15:38:37.840217+00:00 + python-feedgen + + + [bitcoin-dev] Bip-0039/Wordlist - Romanian Justin Valceanu + 2021-08-04T10:30:00.000Z + + + ic + 2021-08-04T13:28:00.000Z + + + s7r + 2021-08-04T22:29:00.000Z + + + Justin Valceanu + 2021-08-05T06:16:00.000Z + + - python-feedgen + 2 Combined summary - Bip-0039/Wordlist - Romanian - 2023-08-02T04:29:13.482604+00:00 + 2025-09-26T15:38:37.840844+00:00 - A new Romanian wordlist for Bip-0039 has been created and updated files have been attached. The list was reviewed by s7r who suggested that the words be uniquely identified using the first 4 letters, which has been done. They also removed words starting with the letters Q, W, X, and Y because most of the words used in Romanian were borrowed from other languages (mostly English). Additionally, they removed incorrect or non-Romanian words such as _adesiv_ (changed to *adeziv*), _topmodel_, _walkman_, _web_, _yachting_, and _acvaplanare_. Between _acvatic_ and _acvaplanare_, only _acvatic_ remains in the list. The entire word list and some statistics about the word distribution can be found in the attached file. The wordlist is now complete and correct.The given context consists of a list of 2048 words, ranging from three to twelve characters in length. The first four characters of the words are all distinct groups. The number of words with each length is as follows: 42 (3 characters), 186 (4 characters), 595 (5 characters), 549 (6 characters), 383 (7 characters), 199 (8 characters), 53 (9 characters), 34 (10 characters), 5 (11 characters), and 2 (12 characters). Words starting with the letter 'A' make up 7.86% of the list, with a total of 161 words. Among these words, there are 3 three-letter words (1.86%), 10 four-letter words (6.21%), 41 five-letter words (25.47%), 37 six-letter words (22.98%), 35 seven-letter words (21.74%). The rest of the context consists of a random collection of words with no particular pattern or topic. It includes words related to various fields such as science, literature, technology, and many others.The context provides information about the frequency of words starting with different letters. It includes the number of words and percentage of words for each letter in the English alphabet ranging from A to H. The data is presented in a table-like format with separate entries for each letter and word length. For example, the entry for letter A shows that there are 26 words (16.15%) starting with this letter, with only 1.27% of them being in the dictionary. Similarly, the entry for letter B shows that there are 112 words starting with it, with the majority (39.29%) being 5 characters long. The data also includes the percentages of words that are in the dictionary for each letter and word length. For instance, the entry for letter C shows that 33.33% of its 5-character words are in the dictionary, while only 0.15% of its 10-character words are. Overall, the context provides a quantitative analysis of the frequency and dictionary usage of words starting with different letters and word lengths in the English language.At 09:07:05 on August 5th, a log was recorded detailing the frequency of words starting with various letters. The log includes the number of words and percentage of those words that start with each letter, as well as the number of characters in those words and the percentage of those words that are present in a given dictionary. In total, there were 80 words starting with "I", with 25 words containing seven characters and making up 1.22% of the dictionary. There were also 19 words starting with "J", with six words containing five characters and making up 0.29% of the dictionary. For words starting with "L", there were 64 words, with 22 containing five characters and making up 1.07% of the dictionary. Words starting with "M" included 128 words, with 49 containing five characters and making up 2.39% of the dictionary. There were 93 words starting with "O", with 28 containing five characters and making up 1.37% of the dictionary. Finally, there were 160 words starting with "P", with 47 containing five or six characters and making up 4.60% of the dictionary.The given context lists the frequencies of words starting with each letter of the alphabet. It provides data for the number of words, percentage of words, and the frequency of dictionary words for each letter. The letter 'R' has the highest number of words starting with it, followed by 'S', 'T', 'Z', 'U', 'V', 'P', 'Q', 'W', 'X', and 'Y'. The word length ranges from 3 to 12 characters. The percentages for dictionary words are all very low, ranging from 0.05% to 2.39%. This 2021-08-05T06:16:27+00:00 + A new Romanian wordlist for Bip-0039 has been created and updated files have been attached. The list was reviewed by s7r who suggested that the words be uniquely identified using the first 4 letters, which has been done. They also removed words starting with the letters Q, W, X, and Y because most of the words used in Romanian were borrowed from other languages (mostly English). Additionally, they removed incorrect or non-Romanian words such as _adesiv_ (changed to *adeziv*), _topmodel_, _walkman_, _web_, _yachting_, and _acvaplanare_. Between _acvatic_ and _acvaplanare_, only _acvatic_ remains in the list. The entire word list and some statistics about the word distribution can be found in the attached file. The wordlist is now complete and correct.The given context consists of a list of 2048 words, ranging from three to twelve characters in length. The first four characters of the words are all distinct groups. The number of words with each length is as follows: 42 (3 characters), 186 (4 characters), 595 (5 characters), 549 (6 characters), 383 (7 characters), 199 (8 characters), 53 (9 characters), 34 (10 characters), 5 (11 characters), and 2 (12 characters). Words starting with the letter 'A' make up 7.86% of the list, with a total of 161 words. Among these words, there are 3 three-letter words (1.86%), 10 four-letter words (6.21%), 41 five-letter words (25.47%), 37 six-letter words (22.98%), 35 seven-letter words (21.74%). The rest of the context consists of a random collection of words with no particular pattern or topic. It includes words related to various fields such as science, literature, technology, and many others.The context provides information about the frequency of words starting with different letters. It includes the number of words and percentage of words for each letter in the English alphabet ranging from A to H. The data is presented in a table-like format with separate entries for each letter and word length. For example, the entry for letter A shows that there are 26 words (16.15%) starting with this letter, with only 1.27% of them being in the dictionary. Similarly, the entry for letter B shows that there are 112 words starting with it, with the majority (39.29%) being 5 characters long. The data also includes the percentages of words that are in the dictionary for each letter and word length. For instance, the entry for letter C shows that 33.33% of its 5-character words are in the dictionary, while only 0.15% of its 10-character words are. Overall, the context provides a quantitative analysis of the frequency and dictionary usage of words starting with different letters and word lengths in the English language.At 09:07:05 on August 5th, a log was recorded detailing the frequency of words starting with various letters. The log includes the number of words and percentage of those words that start with each letter, as well as the number of characters in those words and the percentage of those words that are present in a given dictionary. In total, there were 80 words starting with "I", with 25 words containing seven characters and making up 1.22% of the dictionary. There were also 19 words starting with "J", with six words containing five characters and making up 0.29% of the dictionary. For words starting with "L", there were 64 words, with 22 containing five characters and making up 1.07% of the dictionary. Words starting with "M" included 128 words, with 49 containing five characters and making up 2.39% of the dictionary. There were 93 words starting with "O", with 28 containing five characters and making up 1.37% of the dictionary. Finally, there were 160 words starting with "P", with 47 containing five or six characters and making up 4.60% of the dictionary.The given context lists the frequencies of words starting with each letter of the alphabet. It provides data for the number of words, percentage of words, and the frequency of dictionary words for each letter. The letter 'R' has the highest number of words starting with it, followed by 'S', 'T', 'Z', 'U', 'V', 'P', 'Q', 'W', 'X', and 'Y'. The word length ranges from 3 to 12 characters. The percentages for dictionary words are all very low, ranging from 0.05% to 2.39%. This - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml b/static/bitcoin-dev/Aug_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml index 1c91c16afb..9ace9bf236 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml @@ -1,131 +1,175 @@ - + 2 Combined summary - Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy - 2023-08-02T04:05:11.326798+00:00 - - Erik Aronesty 2022-11-02 17:30:13+00:00 - - - raymo at riseup.net 2021-08-09 20:22:57+00:00 - - - raymo at riseup.net 2021-08-09 16:22:29+00:00 - - - s7r 2021-08-09 00:03:31+00:00 - - - raymo at riseup.net 2021-08-08 09:11:42+00:00 - - - Tao Effect 2021-07-17 18:54:22+00:00 - - - raymo at riseup.net 2021-07-17 15:50:30+00:00 - - - Billy Tetrud 2021-07-07 03:20:38+00:00 - - - raymo at riseup.net 2021-07-03 08:02:09+00:00 - - - Billy Tetrud 2021-07-02 17:57:54+00:00 - - - raymo at riseup.net 2021-07-01 22:15:13+00:00 - - - Erik Aronesty 2021-07-01 20:49:16+00:00 - - - raymo at riseup.net 2021-07-01 20:11:10+00:00 - - - raymo at riseup.net 2021-06-30 12:21:27+00:00 - - - ZmnSCPxj 2021-06-29 21:42:26+00:00 - - - raymo at riseup.net 2021-06-28 19:07:40+00:00 - - - Ricardo Filipe 2021-06-28 18:05:46+00:00 - - - Alex Schoof 2021-06-28 17:58:47+00:00 - - - raymo at riseup.net 2021-06-28 17:38:10+00:00 - - - Tao Effect 2021-06-28 17:29:40+00:00 - - - raymo at riseup.net 2021-06-28 16:58:37+00:00 - - - raymo at riseup.net 2021-06-28 16:33:24+00:00 - - - ZmnSCPxj 2021-06-28 15:28:44+00:00 - - - James Hilliard 2021-06-28 11:28:13+00:00 - - - raymo at riseup.net 2021-06-28 09:52:38+00:00 - - - James Hilliard 2021-06-28 08:23:00+00:00 - - - raymo at riseup.net 2021-06-28 06:29:59+00:00 - - - ZmnSCPxj 2021-06-28 05:20:08+00:00 - - - raymo at riseup.net 2021-06-27 11:05:04+00:00 - - - ZmnSCPxj 2021-06-27 04:53:52+00:00 - - - raymo at riseup.net 2021-06-26 21:54:26+00:00 - - - Billy Tetrud 2021-06-22 18:20:51+00:00 - - - James Hilliard 2021-06-20 01:59:54+00:00 - - - ZmnSCPxj 2021-06-20 00:53:58+00:00 - - - Erik Aronesty 2021-06-19 21:14:08+00:00 - - - raymo at riseup.net 2021-06-18 20:22:08+00:00 - - - raymo at riseup.net 2021-06-18 20:00:12+00:00 - - - Alex Schoof 2021-06-18 13:44:17+00:00 - - - Erik Aronesty 2021-06-18 13:37:54+00:00 - - - Erik Aronesty 2021-06-18 01:42:39+00:00 - - - raymo at riseup.net 2021-06-16 13:44:24+00:00 - + 2025-09-26T15:38:18.879886+00:00 + python-feedgen + + + [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo + 2021-06-16T13:44:00.000Z + + + Erik Aronesty + 2021-06-18T01:42:00.000Z + + + Erik Aronesty + 2021-06-18T13:37:00.000Z + + + Alex Schoof + 2021-06-18T13:44:00.000Z + + + raymo + 2021-06-18T20:00:00.000Z + + + raymo + 2021-06-18T20:22:00.000Z + + + Erik Aronesty + 2021-06-19T21:14:00.000Z + + + ZmnSCPxj + 2021-06-20T00:53:00.000Z + + + James Hilliard + 2021-06-20T01:59:00.000Z + + + Billy Tetrud + 2021-06-22T18:20:00.000Z + + + raymo + 2021-06-26T21:54:00.000Z + + + ZmnSCPxj + 2021-06-27T04:53:00.000Z + + + raymo + 2021-06-27T11:05:00.000Z + + + ZmnSCPxj + 2021-06-28T05:20:00.000Z + + + raymo + 2021-06-28T06:29:00.000Z + + + James Hilliard + 2021-06-28T08:23:00.000Z + + + raymo + 2021-06-28T09:52:00.000Z + + + James Hilliard + 2021-06-28T11:28:00.000Z + + + ZmnSCPxj + 2021-06-28T15:28:00.000Z + + + raymo + 2021-06-28T16:33:00.000Z + + + raymo + 2021-06-28T16:58:00.000Z + + + Tao Effect + 2021-06-28T17:29:00.000Z + + + raymo + 2021-06-28T17:38:00.000Z + + + Alex Schoof + 2021-06-28T17:58:00.000Z + + + Ricardo Filipe + 2021-06-28T18:05:00.000Z + + + raymo + 2021-06-28T19:07:00.000Z + + + ZmnSCPxj + 2021-06-29T21:42:00.000Z + + + raymo + 2021-06-30T12:21:00.000Z + + + raymo + 2021-07-01T20:11:00.000Z + + + Erik Aronesty + 2021-07-01T20:49:00.000Z + + + raymo + 2021-07-01T22:15:00.000Z + + + Billy Tetrud + 2021-07-02T17:57:00.000Z + + + raymo + 2021-07-03T08:02:00.000Z + + + Billy Tetrud + 2021-07-07T03:20:00.000Z + + + raymo + 2021-07-17T15:50:00.000Z + + + Tao Effect + 2021-07-17T18:54:00.000Z + + + raymo + 2021-08-08T09:11:00.000Z + + + s7r + 2021-08-09T00:03:00.000Z + + + raymo + 2021-08-09T16:22:00.000Z + + + raymo + 2021-08-09T20:22:00.000Z + + + Erik Aronesty + 2022-11-02T17:30:00.000Z + + @@ -167,13 +211,13 @@ - python-feedgen + 2 Combined summary - Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy - 2023-08-02T04:05:11.326798+00:00 + 2025-09-26T15:38:18.884025+00:00 - Full Replace-By-Fee (RBF) is becoming the norm in the Sabu protocol, and transactions without it can be rejected. Watchtowers can prevent attacks in progress by offering an always-on watchtower service for a small fee. The Sabu state functions as another mempool, so it's important for all parties to maintain it.An email exchange between Raymo and Chris Riley discusses the uncertainty surrounding potential revenue increases under the Sabu protocol. While upgrading the Bitcoin protocol wouldn't be technically difficult, consensus on implementation changes is required. If there are difficulties with implementing changes to the Bitcoin core protocol, the Stratum protocol could be changed instead.Miners have the incentive to accept the highest fee transaction, but there is no guarantee due to the untrusted nature of the network. It is still uncertain whether miners will prefer the highest fee transaction or keep the first transaction received and drop subsequent ones.The Guarantee Transaction is created based on the Main Transaction but has no direct relation to it. Miners choose the Guarantee Transaction over other transactions spending the same UTXO(s) because it offers a notably higher fee. Bob must be online 24/7 to prevent Alice's attack from succeeding completely.The email thread also discusses a hypothetical fraudulent attack on Bitcoin's Lightning Network. This attack involves a malicious actor using already-spent inputs to defraud a creditor. Despite a higher fee in the Guarantee transaction, miners are unlikely to drop the Sabu-Killing-transaction and consider only the Guarantee transaction. The attack has a 99% chance of success, and Bob needs to be online continuously to prevent it.The email raises a question about how Bob can spend the coins he received and become an issuer in relation to another creditor, Dave. If Alice tries to defraud Bob after he spent his Sabu credit to Dave, Dave would need to hold all parent "guarantee transactions" and watch for potential fraudulent transactions.Raymo, the creator of Sabu, suggests penalties for issuers, creditors, and miners instead of a claw-back mechanism. He is actively working on realizing the Sabu protocol and Gazin wallet. The proposal is open for review and feedback on various platforms.The Sabu protocol aims to improve Bitcoin circulation, transaction processing speed (TPS), and privacy. It allows users to send and receive Bitcoin without opening channels or paying transaction fees. Transactions are recorded on the Bitcoin blockchain only in case of fraudulent activity. The protocol involves issuers who own Bitcoin and creditors who receive it in exchange for goods or services.The security model of Sabu relies on guarantee transactions to ensure creditors receive payment even in case of fraud. The protocol offers self-sovereignty and decentralized communication, with PGP encryption ensuring privacy. Wallets can add friends using email addresses or scanned public keys. Each transaction is a small money transfer with specific inputs and outputs, and creditors pay a Sabu-transaction-fee to issuers.Despite concerns about the assumptions made in the proposal and the use of email for user identification and communication, the Sabu protocol offers a promising solution to improve Bitcoin circulation, TPS, and privacy. It provides an alternative to the Lightning Network and traditional custodial solutions.In conclusion, the Sabu protocol proposes a peer-to-peer network architecture that allows for improved Bitcoin trading with enhanced privacy and self-sovereignty. It addresses concerns about cheating through guarantee transactions and offers an alternative approach to transaction processing speed. However, further evaluation and addressing of concerns are necessary for successful implementation.The author of the article suggests using email as the primary communication method for transactions, despite potential privacy concerns. They argue that email is the most neutral, free, and globally accessible option. However, this protocol does not address the issue of preventing fraud proofs. As alternatives, QR codes and device-to-device linking are proposed for adding contacts to the contact list.To improve Bitcoin's transaction per second (TPS) and privacy, a proposal has been made to create a new cryptocurrency called IOUs that would run on top of Bitcoin. However, there are concerns about preventing double-spending, network latency, and spam filters when using email as the remote procedure call mechanism. Consensus among nodes is necessary to avoid conflicts regarding the correct set of "sent notes".Another plan to enhance Bitcoin's TPS and privacy involves implementing an off-chain transaction network, as suggested by Raymo. This system guarantees security through relative fees and the cost-of-theft. It is recommended for small transactions similar to Lightning but without limits or routing protocols. More details can be found in Raymo's Medium post and Bitcointalk forum, where the community is invited to provide feedback and thoughts.In summary, various discussions have taken place regarding mining behavior, high transaction fees, and latency issues in the Bitcoin network. The vulnerability of sybil attacks and proxy attacks has also been addressed, along with suggestions for defense mechanisms. Both the Sabu protocol and Raymo's proposal aim to improve Bitcoin's TPS and 2022-11-02T17:30:13+00:00 + Full Replace-By-Fee (RBF) is becoming the norm in the Sabu protocol, and transactions without it can be rejected. Watchtowers can prevent attacks in progress by offering an always-on watchtower service for a small fee. The Sabu state functions as another mempool, so it's important for all parties to maintain it.An email exchange between Raymo and Chris Riley discusses the uncertainty surrounding potential revenue increases under the Sabu protocol. While upgrading the Bitcoin protocol wouldn't be technically difficult, consensus on implementation changes is required. If there are difficulties with implementing changes to the Bitcoin core protocol, the Stratum protocol could be changed instead.Miners have the incentive to accept the highest fee transaction, but there is no guarantee due to the untrusted nature of the network. It is still uncertain whether miners will prefer the highest fee transaction or keep the first transaction received and drop subsequent ones.The Guarantee Transaction is created based on the Main Transaction but has no direct relation to it. Miners choose the Guarantee Transaction over other transactions spending the same UTXO(s) because it offers a notably higher fee. Bob must be online 24/7 to prevent Alice's attack from succeeding completely.The email thread also discusses a hypothetical fraudulent attack on Bitcoin's Lightning Network. This attack involves a malicious actor using already-spent inputs to defraud a creditor. Despite a higher fee in the Guarantee transaction, miners are unlikely to drop the Sabu-Killing-transaction and consider only the Guarantee transaction. The attack has a 99% chance of success, and Bob needs to be online continuously to prevent it.The email raises a question about how Bob can spend the coins he received and become an issuer in relation to another creditor, Dave. If Alice tries to defraud Bob after he spent his Sabu credit to Dave, Dave would need to hold all parent "guarantee transactions" and watch for potential fraudulent transactions.Raymo, the creator of Sabu, suggests penalties for issuers, creditors, and miners instead of a claw-back mechanism. He is actively working on realizing the Sabu protocol and Gazin wallet. The proposal is open for review and feedback on various platforms.The Sabu protocol aims to improve Bitcoin circulation, transaction processing speed (TPS), and privacy. It allows users to send and receive Bitcoin without opening channels or paying transaction fees. Transactions are recorded on the Bitcoin blockchain only in case of fraudulent activity. The protocol involves issuers who own Bitcoin and creditors who receive it in exchange for goods or services.The security model of Sabu relies on guarantee transactions to ensure creditors receive payment even in case of fraud. The protocol offers self-sovereignty and decentralized communication, with PGP encryption ensuring privacy. Wallets can add friends using email addresses or scanned public keys. Each transaction is a small money transfer with specific inputs and outputs, and creditors pay a Sabu-transaction-fee to issuers.Despite concerns about the assumptions made in the proposal and the use of email for user identification and communication, the Sabu protocol offers a promising solution to improve Bitcoin circulation, TPS, and privacy. It provides an alternative to the Lightning Network and traditional custodial solutions.In conclusion, the Sabu protocol proposes a peer-to-peer network architecture that allows for improved Bitcoin trading with enhanced privacy and self-sovereignty. It addresses concerns about cheating through guarantee transactions and offers an alternative approach to transaction processing speed. However, further evaluation and addressing of concerns are necessary for successful implementation.The author of the article suggests using email as the primary communication method for transactions, despite potential privacy concerns. They argue that email is the most neutral, free, and globally accessible option. However, this protocol does not address the issue of preventing fraud proofs. As alternatives, QR codes and device-to-device linking are proposed for adding contacts to the contact list.To improve Bitcoin's transaction per second (TPS) and privacy, a proposal has been made to create a new cryptocurrency called IOUs that would run on top of Bitcoin. However, there are concerns about preventing double-spending, network latency, and spam filters when using email as the remote procedure call mechanism. Consensus among nodes is necessary to avoid conflicts regarding the correct set of "sent notes".Another plan to enhance Bitcoin's TPS and privacy involves implementing an off-chain transaction network, as suggested by Raymo. This system guarantees security through relative fees and the cost-of-theft. It is recommended for small transactions similar to Lightning but without limits or routing protocols. More details can be found in Raymo's Medium post and Bitcointalk forum, where the community is invited to provide feedback and thoughts.In summary, various discussions have taken place regarding mining behavior, high transaction fees, and latency issues in the Bitcoin network. The vulnerability of sybil attacks and proxy attacks has also been addressed, along with suggestions for defense mechanisms. Both the Sabu protocol and Raymo's proposal aim to improve Bitcoin's TPS and - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml b/static/bitcoin-dev/Aug_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml index 8f3d3f67e3..1ef6b265e5 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Braidpool: Proposal for a decentralised mining pool - 2023-08-02T04:38:29.528678+00:00 + 2025-09-26T15:38:21.001997+00:00 + python-feedgen pool2win 2021-09-13 08:03:42+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Braidpool: Proposal for a decentralised mining pool - 2023-08-02T04:38:29.528678+00:00 + 2025-09-26T15:38:21.002197+00:00 - The issue of a malicious miner cheating other miners of their reward is discussed in the context. The problem arises as the bitcoin block is used as the sentinel to mark the shares from DAG that need to be rewarded. A proposed solution is to have the hub broadcast a "sentinel" to mark out the point in logical time up to which shares will be rewarded.A proposal is made to reward miners for creating valid blocks, but concerns are raised about rogue miners avoiding referencing other miners' shares to keep rewards for themselves. Two methods are suggested for resolving conflicts between conflicting versions of the DAG: using the longest chain or the one with more work. However, both methods present issues such as the potential for bad hashers to create low-difficulty shares and then mine and publish higher-difficulty shares without sharing the reward.In an email exchange, questions are raised about the proposal that every share can reference multiple previous shares. Concerns are expressed about rogue miners not referencing any shares from other miners to avoid sharing the reward. Doubts are also raised about how conflicts between different valid states will be resolved.A discussion on the Bitcoin-dev mailing list focuses on the centralization of Braidpool's payout server, which is seen as a single point of failure. Suggestions are made to use multiple hubs to reduce the risk of a single point of failure. One idea presented is a Lightning model where multiple hubs offer liquidity to the network, and the winning hasher elects one of the hubs to receive the payout. It is acknowledged that getting something working now may be more beneficial than waiting for a perfect solution.ZmnSCPxj points out that Braidpool's payout server remains a single central point of failure despite claims of using Tor hidden service to protect against DDoS attacks. Multiple hubs are suggested as a preferable solution, with Chris Belcher's proposal for using payment channels mentioned as a potential construction for multiple hubs. It is acknowledged that more ideas for decentralization may emerge as Braidpool is built.The benefits of Stratum v2 and its comparison to other mining methods are discussed. It is noted that mining pools still have the ability to reject negotiations and censor payments. Suggestions are made to use Stratum v2 in combination with other technologies, such as discreet log contracts.Braidpool is viewed as an improvement to P2Pool in making a peer-to-peer pool work on a larger scale. It offers transparent views of shares received by the pool, allowing miners to verify reward calculations. It also offers payouts over a one-way channel, unlike P2Pool. Braidpool prepares for future attacks on centralized mining pools while attracting miners to the platform now.In a discussion on centralized mining control and payment censorship, concerns are raised about the control of transaction selection and potential censorship. The use of Lightning Network (LN) for payouts is suggested as a way to mitigate these issues, but the advantages of Braidpool over an idealized version of centralized mining with independent transaction selection are questioned.A comparison is made between a decentralized mining pool using BetterHash or Stratum v2 with LN-based payouts and a centralized mining pool. The advantages of a decentralized pool are highlighted, including the ability for miners to choose their own transactions and prevent any single entity from having control over the selection process.Pool2win proposes a decentralized solution to the problems faced by P2Pool. The proposal aims to provide lower variance for smaller miners and enable a futures market for hash rates. The solution uses a DAG of shares replicated at all miners to compute rewards, with payouts made via one-way payment channels by an anonymous hub communicating through Tor's hidden services. Comparisons to Stratum v2 are not provided.The Pool2Win team develops Braidpool, a decentralized mining pool aimed at overcoming issues faced by P2Pool and enabling a futures market for hash rates. The pool offers lower variance for smaller miners, allows miners to build their own blocks, and provides transparent views of shares received by the pool. Rewards are paid out via one-way payment channels using Tor's hidden services to prevent cheating. The team also provides details on trading hash rate. The ultimate goal is to provide a more efficient and fair mining experience while contributing to Bitcoin's decentralization. 2021-09-13T08:03:42+00:00 + The issue of a malicious miner cheating other miners of their reward is discussed in the context. The problem arises as the bitcoin block is used as the sentinel to mark the shares from DAG that need to be rewarded. A proposed solution is to have the hub broadcast a "sentinel" to mark out the point in logical time up to which shares will be rewarded.A proposal is made to reward miners for creating valid blocks, but concerns are raised about rogue miners avoiding referencing other miners' shares to keep rewards for themselves. Two methods are suggested for resolving conflicts between conflicting versions of the DAG: using the longest chain or the one with more work. However, both methods present issues such as the potential for bad hashers to create low-difficulty shares and then mine and publish higher-difficulty shares without sharing the reward.In an email exchange, questions are raised about the proposal that every share can reference multiple previous shares. Concerns are expressed about rogue miners not referencing any shares from other miners to avoid sharing the reward. Doubts are also raised about how conflicts between different valid states will be resolved.A discussion on the Bitcoin-dev mailing list focuses on the centralization of Braidpool's payout server, which is seen as a single point of failure. Suggestions are made to use multiple hubs to reduce the risk of a single point of failure. One idea presented is a Lightning model where multiple hubs offer liquidity to the network, and the winning hasher elects one of the hubs to receive the payout. It is acknowledged that getting something working now may be more beneficial than waiting for a perfect solution.ZmnSCPxj points out that Braidpool's payout server remains a single central point of failure despite claims of using Tor hidden service to protect against DDoS attacks. Multiple hubs are suggested as a preferable solution, with Chris Belcher's proposal for using payment channels mentioned as a potential construction for multiple hubs. It is acknowledged that more ideas for decentralization may emerge as Braidpool is built.The benefits of Stratum v2 and its comparison to other mining methods are discussed. It is noted that mining pools still have the ability to reject negotiations and censor payments. Suggestions are made to use Stratum v2 in combination with other technologies, such as discreet log contracts.Braidpool is viewed as an improvement to P2Pool in making a peer-to-peer pool work on a larger scale. It offers transparent views of shares received by the pool, allowing miners to verify reward calculations. It also offers payouts over a one-way channel, unlike P2Pool. Braidpool prepares for future attacks on centralized mining pools while attracting miners to the platform now.In a discussion on centralized mining control and payment censorship, concerns are raised about the control of transaction selection and potential censorship. The use of Lightning Network (LN) for payouts is suggested as a way to mitigate these issues, but the advantages of Braidpool over an idealized version of centralized mining with independent transaction selection are questioned.A comparison is made between a decentralized mining pool using BetterHash or Stratum v2 with LN-based payouts and a centralized mining pool. The advantages of a decentralized pool are highlighted, including the ability for miners to choose their own transactions and prevent any single entity from having control over the selection process.Pool2win proposes a decentralized solution to the problems faced by P2Pool. The proposal aims to provide lower variance for smaller miners and enable a futures market for hash rates. The solution uses a DAG of shares replicated at all miners to compute rewards, with payouts made via one-way payment channels by an anonymous hub communicating through Tor's hidden services. Comparisons to Stratum v2 are not provided.The Pool2Win team develops Braidpool, a decentralized mining pool aimed at overcoming issues faced by P2Pool and enabling a futures market for hash rates. The pool offers lower variance for smaller miners, allows miners to build their own blocks, and provides transparent views of shares received by the pool. Rewards are paid out via one-way payment channels using Tor's hidden services to prevent cheating. The team also provides details on trading hash rate. The ultimate goal is to provide a more efficient and fair mining experience while contributing to Bitcoin's decentralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Camouflage-A-project-dedicated-to-Hal-Finney.xml b/static/bitcoin-dev/Aug_2021/combined_Camouflage-A-project-dedicated-to-Hal-Finney.xml index 150998df05..6391ca57a1 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Camouflage-A-project-dedicated-to-Hal-Finney.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Camouflage-A-project-dedicated-to-Hal-Finney.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Camouflage: A project dedicated to Hal Finney - 2023-08-02T04:38:06.030931+00:00 - - Aymeric Vitte 2021-08-29 09:51:39+00:00 - - - Prayank 2021-08-28 22:40:38+00:00 - - - Aymeric Vitte 2021-08-28 16:36:26+00:00 - - - Prayank 2021-08-27 21:29:35+00:00 - + 2025-09-26T15:38:48.323578+00:00 + python-feedgen + + + [bitcoin-dev] Camouflage: A project dedicated to Hal Finney Prayank + 2021-08-27T21:29:00.000Z + + + Aymeric Vitte + 2021-08-28T16:36:00.000Z + + + Prayank + 2021-08-28T22:40:00.000Z + + + Aymeric Vitte + 2021-08-29T09:51:00.000Z + + - python-feedgen + 2 Combined summary - Camouflage: A project dedicated to Hal Finney - 2023-08-02T04:38:06.030931+00:00 + 2025-09-26T15:38:48.324196+00:00 - In their email conversation, Aymeric and Prayank discuss the use of the Tor protocol between Bitcoin nodes via node-Tor. They note that while the project uses JavaScript and WebRTC, which some privacy-conscious users disable while browsing, the use of Tor browser is not anticipated or encouraged. Aymeric suggests including a discussion/issue on improving privacy in Bitcoin projects to Prayank's links.Prayank introduces his own project called 'Camouflage' aimed at improving privacy in various Bitcoin projects. The project includes an issue and pull request tracking system for privacy-related topics, a blog section for Prayank's opinions on privacy issues, and a 'Hall of Fame' section to acknowledge developers contributing to privacy improvements. He emphasizes that the project will not become a paid newsletter or require sponsors, but welcomes contributions to enhance the website. Prayank shares a link to the current website location and mentions plans to move it to a new repository soon.The developer Prayank initiates a project to enhance privacy in Bitcoin, with the goal of benefiting both users and developers. The project encompasses a tracking system for privacy-related issues and pull requests across different Bitcoin projects, a blog section containing Prayank's insights on privacy matters, and a 'Hall of Fame' segment honoring developers contributing to privacy enhancements. Prayank assures that the project will remain free of charge and sponsor-free, but invites contributions to improve the website. He provides links to a relevant discussion/issue on Github and an email he sent in July concerning privacy-related topics. The current project website is hosted on Github pages but will be relocated to a new repository during the upcoming weekend.The email author expresses a desire to improve privacy in Bitcoin and holds admiration for Hal Finney, whom they believe could have made valuable contributions in this regard. They share a link to one of Finney's posts on the subject and mention having emailed about privacy issues on their birthday, which may have been less focused due to alcohol consumption. Despite receiving only one positive response to a video mentioned in the email, the author has created the Bitcoin Camouflage project to aid in enhancing privacy across various Bitcoin projects. This initiative incorporates a section for privacy-related issues and pull requests from different Bitcoin projects, a blog section for the author's opinions on privacy matters, and a 'Hall of Fame' segment for recognizing developers working on privacy improvements. The author emphasizes that the project will never become a paid newsletter or seek sponsors, but appreciates contributions to improve the website. Additionally, the author extends an invitation to Edward Snowden to contribute beyond tweeting about enhancing Bitcoin privacy. They provide links to the current project location and its intended future repository. 2021-08-29T09:51:39+00:00 + In their email conversation, Aymeric and Prayank discuss the use of the Tor protocol between Bitcoin nodes via node-Tor. They note that while the project uses JavaScript and WebRTC, which some privacy-conscious users disable while browsing, the use of Tor browser is not anticipated or encouraged. Aymeric suggests including a discussion/issue on improving privacy in Bitcoin projects to Prayank's links.Prayank introduces his own project called 'Camouflage' aimed at improving privacy in various Bitcoin projects. The project includes an issue and pull request tracking system for privacy-related topics, a blog section for Prayank's opinions on privacy issues, and a 'Hall of Fame' section to acknowledge developers contributing to privacy improvements. He emphasizes that the project will not become a paid newsletter or require sponsors, but welcomes contributions to enhance the website. Prayank shares a link to the current website location and mentions plans to move it to a new repository soon.The developer Prayank initiates a project to enhance privacy in Bitcoin, with the goal of benefiting both users and developers. The project encompasses a tracking system for privacy-related issues and pull requests across different Bitcoin projects, a blog section containing Prayank's insights on privacy matters, and a 'Hall of Fame' segment honoring developers contributing to privacy enhancements. Prayank assures that the project will remain free of charge and sponsor-free, but invites contributions to improve the website. He provides links to a relevant discussion/issue on Github and an email he sent in July concerning privacy-related topics. The current project website is hosted on Github pages but will be relocated to a new repository during the upcoming weekend.The email author expresses a desire to improve privacy in Bitcoin and holds admiration for Hal Finney, whom they believe could have made valuable contributions in this regard. They share a link to one of Finney's posts on the subject and mention having emailed about privacy issues on their birthday, which may have been less focused due to alcohol consumption. Despite receiving only one positive response to a video mentioned in the email, the author has created the Bitcoin Camouflage project to aid in enhancing privacy across various Bitcoin projects. This initiative incorporates a section for privacy-related issues and pull requests from different Bitcoin projects, a blog section for the author's opinions on privacy matters, and a 'Hall of Fame' segment for recognizing developers working on privacy improvements. The author emphasizes that the project will never become a paid newsletter or seek sponsors, but appreciates contributions to improve the website. Additionally, the author extends an invitation to Edward Snowden to contribute beyond tweeting about enhancing Bitcoin privacy. They provide links to the current project location and its intended future repository. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml b/static/bitcoin-dev/Aug_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml index bcab1dff83..92d295ba4b 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml @@ -1,65 +1,39 @@ - + 2 Combined summary - Exploring: limiting transaction output amount as a function of total input value - 2023-08-02T04:27:02.335436+00:00 - - Zac Greenwood 2021-09-01 15:15:30+00:00 - - - ZmnSCPxj 2021-08-31 14:22:29+00:00 - - - Zac Greenwood 2021-08-31 14:09:04+00:00 - - - ZmnSCPxj 2021-08-31 09:00:15+00:00 - - - Zac Greenwood 2021-08-30 14:43:30+00:00 - - - ZmnSCPxj 2021-08-16 11:48:43+00:00 - - - Zac Greenwood 2021-08-16 11:17:19+00:00 - - - ZmnSCPxj 2021-08-14 01:50:45+00:00 - - - Zac Greenwood 2021-08-13 11:02:14+00:00 - - - ZmnSCPxj 2021-08-10 02:17:47+00:00 - - - Billy Tetrud 2021-08-10 00:41:12+00:00 - - - Zac Greenwood 2021-08-05 14:22:12+00:00 - - - Billy Tetrud 2021-08-05 06:39:34+00:00 - - - Zac Greenwood 2021-08-04 10:48:44+00:00 - - - Billy Tetrud 2021-08-03 18:12:28+00:00 - - - Zac Greenwood 2021-08-02 09:32:36+00:00 - - - Billy Tetrud 2021-08-02 04:40:47+00:00 - - - Zac Greenwood 2021-08-01 08:09:26+00:00 - - - Zac Greenwood 2021-07-31 20:01:49+00:00 - + 2025-09-26T15:38:33.632145+00:00 + python-feedgen + + + [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood + 2021-08-01T08:09:00.000Z + + + Zac Greenwood + 2021-08-02T09:32:00.000Z + + + Billy Tetrud + 2021-08-03T18:12:00.000Z + + + Zac Greenwood + 2021-08-04T10:48:00.000Z + + + Billy Tetrud + 2021-08-05T06:39:00.000Z + + + Zac Greenwood + 2021-08-05T14:22:00.000Z + + + Billy Tetrud + 2021-08-10T00:41:00.000Z + + @@ -79,13 +53,13 @@ - python-feedgen + 2 Combined summary - Exploring: limiting transaction output amount as a function of total input value - 2023-08-02T04:27:02.335436+00:00 + 2025-09-26T15:38:33.633095+00:00 - The email thread discusses the implementation of a rate-limiting algorithm in a privacy-preserving manner. The proposed algorithm involves creating an output at a specific block height [h0] that serves as input and limits the maximum amount that can be sent. This rule is permanent and always copied over to a change output. At another block height [h1], a transaction occurs, spending a certain amount [h1_spent]. The payment output created at [h1] is not restricted, while the change output must be encumbered with a second transaction occurring at another block height [h2], spending a certain amount [h2_spent]. However, implementing this algorithm in a privacy-preserving way poses challenges, as it reduces the anonymity set for everyone and makes the payment and change outputs identifiable on-chain. The author suggests using clever MAST-fu in covenant schemes to address these challenges. Several proposals for such covenant schemes exist, but none have gained significant traction.In their email exchange, Zac and ZmnSCPxj discuss the potential reduction of privacy in a proposal due to the introduction of a new type of transaction. This would decrease the anonymity set for everyone and result in identifiable payment and change outputs. Zac proposes using clever MAST-fu to resolve these issues but lacks the technical skills to determine if it's possible. ZmnSCPxj directs Zac towards covenant efforts with MAST-integration developed by aj and RubenSomsen. While various proposals exist, ZmnSCPxj cannot pinpoint one that seems likely to gain significant traction.Zac expresses concerns about the privacy implications of a proposed algorithm that requires a new type of transaction and encumbered change outputs. ZmnSCPxj explains that this proposal would reduce privacy by decreasing the anonymity set for everyone, making payment and change outputs identifiable, and requiring visible on-chain specifics regarding how the output is encumbered. Zac believes that the functionality should not justify the privacy reductions unless these concerns can be addressed. ZmnSCPxj provides further details about the challenges involved in implementing the proposal, including explicit flagging and data storage requirements for each output. These challenges make implementation without consensus code changes difficult, but dropping the "change outputs must also be rate-limited" requirement could improve privacy and ease implementation.ZmnSCPxj's email discusses the potential costs and benefits of implementing a proposal. One issue is the need for explicit visibility to implement the "change outputs must also be rate-limited" requirement. Two options, allocating new SegWit versions or using anyone-can-spend `scriptPubKey` templates, have drawbacks related to privacy concerns. Another challenge is storing data with each output, which increases the size of stored outputs. Ideally, outputs should only contain commitments rather than actual data. However, explicit tagging is necessary to ensure rate-limiting of change outputs, which adds to the amount of data required. The residual limit also needs to be kept with the output. Dropping the "change outputs must also be rate-limited" requirement would address some gaps in the proposal but reduce privacy. Overall, the email highlights various challenges and considerations for implementing this proposal.Zac and ZmnSCPxj discuss the functionality of limiting the amount spent from an address within a certain timeframe. Zac proposes implementing consensus changes to support this functionality, while ZmnSCPxj suggests using covenant opcodes instead. However, there are multiple proposals with overlapping abilities and tradeoffs, potentially leading to disagreements. Zac requests more information on what is needed to implement his unmodified proposal so that the community can assess the cost versus the benefits. He acknowledges that consensus changes take years but believes it is essential to explore the appetite for the proposed functionality and possible technical solutions.Zac and ZmnSCPxj agree on the importance of determining whether the proposed functionality can be implemented without consensus changes. ZmnSCPxj presents a technical counterproposal that explores an implementation on top of the existing Bitcoin system. They discuss the differences between the proposals, highlighting significant gaps. Zac believes that the counterproposal does not meet the basic requirements of the original proposal and prefers implementing consensus changes to support the functionality. They suggest looking into covenant opcodes as an alternative to the counterproposal, as they closely align with one of the motivating examples for covenants. The conversation emphasizes the need to address the gaps between the proposals.In their conversation, Zac proposes functionality that allows control of a coin using two private keys, with spending limited over time for one key and unrestricted for the other. ZmnSCPxj presents a counterproposal using `nSequence` in relative-locktime mode but acknowledges its disadvantages, including obviousness and limits on the number of windows. Zac argues that implementing consensus changes to support the proposed functionality would be preferable over the counterproposal. However, ZmnSCPxj contends that the functionality can be implemented using `nSequence`-in-relative-locktime-mode without any consensus changes. They agree that the functionality is 2021-09-01T15:15:30+00:00 + The email thread discusses the implementation of a rate-limiting algorithm in a privacy-preserving manner. The proposed algorithm involves creating an output at a specific block height [h0] that serves as input and limits the maximum amount that can be sent. This rule is permanent and always copied over to a change output. At another block height [h1], a transaction occurs, spending a certain amount [h1_spent]. The payment output created at [h1] is not restricted, while the change output must be encumbered with a second transaction occurring at another block height [h2], spending a certain amount [h2_spent]. However, implementing this algorithm in a privacy-preserving way poses challenges, as it reduces the anonymity set for everyone and makes the payment and change outputs identifiable on-chain. The author suggests using clever MAST-fu in covenant schemes to address these challenges. Several proposals for such covenant schemes exist, but none have gained significant traction.In their email exchange, Zac and ZmnSCPxj discuss the potential reduction of privacy in a proposal due to the introduction of a new type of transaction. This would decrease the anonymity set for everyone and result in identifiable payment and change outputs. Zac proposes using clever MAST-fu to resolve these issues but lacks the technical skills to determine if it's possible. ZmnSCPxj directs Zac towards covenant efforts with MAST-integration developed by aj and RubenSomsen. While various proposals exist, ZmnSCPxj cannot pinpoint one that seems likely to gain significant traction.Zac expresses concerns about the privacy implications of a proposed algorithm that requires a new type of transaction and encumbered change outputs. ZmnSCPxj explains that this proposal would reduce privacy by decreasing the anonymity set for everyone, making payment and change outputs identifiable, and requiring visible on-chain specifics regarding how the output is encumbered. Zac believes that the functionality should not justify the privacy reductions unless these concerns can be addressed. ZmnSCPxj provides further details about the challenges involved in implementing the proposal, including explicit flagging and data storage requirements for each output. These challenges make implementation without consensus code changes difficult, but dropping the "change outputs must also be rate-limited" requirement could improve privacy and ease implementation.ZmnSCPxj's email discusses the potential costs and benefits of implementing a proposal. One issue is the need for explicit visibility to implement the "change outputs must also be rate-limited" requirement. Two options, allocating new SegWit versions or using anyone-can-spend `scriptPubKey` templates, have drawbacks related to privacy concerns. Another challenge is storing data with each output, which increases the size of stored outputs. Ideally, outputs should only contain commitments rather than actual data. However, explicit tagging is necessary to ensure rate-limiting of change outputs, which adds to the amount of data required. The residual limit also needs to be kept with the output. Dropping the "change outputs must also be rate-limited" requirement would address some gaps in the proposal but reduce privacy. Overall, the email highlights various challenges and considerations for implementing this proposal.Zac and ZmnSCPxj discuss the functionality of limiting the amount spent from an address within a certain timeframe. Zac proposes implementing consensus changes to support this functionality, while ZmnSCPxj suggests using covenant opcodes instead. However, there are multiple proposals with overlapping abilities and tradeoffs, potentially leading to disagreements. Zac requests more information on what is needed to implement his unmodified proposal so that the community can assess the cost versus the benefits. He acknowledges that consensus changes take years but believes it is essential to explore the appetite for the proposed functionality and possible technical solutions.Zac and ZmnSCPxj agree on the importance of determining whether the proposed functionality can be implemented without consensus changes. ZmnSCPxj presents a technical counterproposal that explores an implementation on top of the existing Bitcoin system. They discuss the differences between the proposals, highlighting significant gaps. Zac believes that the counterproposal does not meet the basic requirements of the original proposal and prefers implementing consensus changes to support the functionality. They suggest looking into covenant opcodes as an alternative to the counterproposal, as they closely align with one of the motivating examples for covenants. The conversation emphasizes the need to address the gaps between the proposals.In their conversation, Zac proposes functionality that allows control of a coin using two private keys, with spending limited over time for one key and unrestricted for the other. ZmnSCPxj presents a counterproposal using `nSequence` in relative-locktime mode but acknowledges its disadvantages, including obviousness and limits on the number of windows. Zac argues that implementing consensus changes to support the proposed functionality would be preferable over the counterproposal. However, ZmnSCPxj contends that the functionality can be implemented using `nSequence`-in-relative-locktime-mode without any consensus changes. They agree that the functionality is - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Human-readable-checksum-verification-code-to-avoid-errors-on-BTC-public-addresses.xml b/static/bitcoin-dev/Aug_2021/combined_Human-readable-checksum-verification-code-to-avoid-errors-on-BTC-public-addresses.xml index 5065fe7326..5455b45d88 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Human-readable-checksum-verification-code-to-avoid-errors-on-BTC-public-addresses.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Human-readable-checksum-verification-code-to-avoid-errors-on-BTC-public-addresses.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Human readable checksum (verification code) to avoid errors on BTC public addresses - 2023-08-02T04:36:53.862644+00:00 - - ts 2021-09-03 05:08:42+00:00 - - - Marek Palatinus 2021-08-31 08:47:26+00:00 - - - ts 2021-08-31 02:17:07+00:00 - - - ts 2021-08-31 02:16:00+00:00 - - - Pieter Wuille 2021-08-29 14:42:07+00:00 - - - Pieter Wuille 2021-08-29 14:24:48+00:00 - - - ts 2021-08-28 21:17:35+00:00 - - - ts 2021-08-21 04:52:26+00:00 - - - ts 2021-08-21 04:52:16+00:00 - - - Karl 2021-08-19 21:05:28+00:00 - - - Christopher Allen 2021-08-19 17:37:29+00:00 - - - ts 2021-08-19 17:02:38+00:00 - - - ZmnSCPxj 2021-08-16 10:34:36+00:00 - - - ts 2021-08-16 04:23:25+00:00 - + 2025-09-26T15:38:23.090284+00:00 + python-feedgen + + + [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses ts + 2021-08-16T04:23:00.000Z + + + ZmnSCPxj + 2021-08-16T10:34:00.000Z + + + ts + 2021-08-19T17:02:00.000Z + + + Christopher Allen + 2021-08-19T17:37:00.000Z + + + Karl + 2021-08-19T21:05:00.000Z + + + ts + 2021-08-21T04:52:00.000Z + + + ts + 2021-08-21T04:52:00.000Z + + + ts + 2021-08-28T21:17:00.000Z + + + Pieter Wuille + 2021-08-29T14:24:00.000Z + + + Pieter Wuille + 2021-08-29T14:42:00.000Z + + + ts + 2021-08-31T02:16:00.000Z + + + ts + 2021-08-31T02:17:00.000Z + + + Marek Palatinus + 2021-08-31T08:47:00.000Z + + + ts + 2021-09-03T05:08:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Human readable checksum (verification code) to avoid errors on BTC public addresses - 2023-08-02T04:36:53.862644+00:00 + 2025-09-26T15:38:23.091765+00:00 - One solution to reduce the probability of performing transactions to the wrong address is to match the DC (destination checksum) from the receiving address. This implementation is relatively simple, but it requires agreement on a checksum standard for generating the code. Once this standard is established, developers of wallets and exchanges can begin implementing it.To encourage fast adoption, it would be helpful to have a catchy name for this code, such as "human readable checksum," "verification code," or "4DC." This solution could potentially be used for all other coins and networks, although it is ideal for each to have its own checksum algorithm. This would prevent funds from being sent to the wrong network, especially in cases where the address standard is the same, like with BTC and BCH.The hope is that Bitcoin can lead the way in implementing this solution and serve as an example for other coins and networks to follow suit. By adopting this method, the likelihood of mistakenly sending transactions to the wrong address can be greatly reduced. 2021-09-03T05:08:42+00:00 + One solution to reduce the probability of performing transactions to the wrong address is to match the DC (destination checksum) from the receiving address. This implementation is relatively simple, but it requires agreement on a checksum standard for generating the code. Once this standard is established, developers of wallets and exchanges can begin implementing it.To encourage fast adoption, it would be helpful to have a catchy name for this code, such as "human readable checksum," "verification code," or "4DC." This solution could potentially be used for all other coins and networks, although it is ideal for each to have its own checksum algorithm. This would prevent funds from being sent to the wrong network, especially in cases where the address standard is the same, like with BTC and BCH.The hope is that Bitcoin can lead the way in implementing this solution and serve as an example for other coins and networks to follow suit. By adopting this method, the likelihood of mistakenly sending transactions to the wrong address can be greatly reduced. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Is-there-a-tool-like-Ethereum-EVM-at-present-for-Bitcoin-script-.xml b/static/bitcoin-dev/Aug_2021/combined_Is-there-a-tool-like-Ethereum-EVM-at-present-for-Bitcoin-script-.xml index aeef969cf0..27041988b5 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Is-there-a-tool-like-Ethereum-EVM-at-present-for-Bitcoin-script-.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Is-there-a-tool-like-Ethereum-EVM-at-present-for-Bitcoin-script-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Is there a tool like Ethereum EVM at present for Bitcoin script? - 2023-08-02T04:37:38.132373+00:00 - - Jeremy 2021-08-26 20:03:47+00:00 - - - Michael Folkson 2021-08-26 13:09:49+00:00 - - - Jeremy 2021-08-26 10:26:23+00:00 - - - Oleg Andreev 2021-08-26 08:12:22+00:00 - - - Null Null 2021-08-26 02:43:27+00:00 - - - Andrew Poelstra 2021-08-24 13:08:49+00:00 - - - Gijs van Dam 2021-08-24 07:36:29+00:00 - - - Null Null 2021-08-24 03:39:44+00:00 - + 2025-09-26T15:38:39.931825+00:00 + python-feedgen + + + [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script? Null Null + 2021-08-24T03:39:00.000Z + + + Gijs van Dam + 2021-08-24T07:36:00.000Z + + + Andrew Poelstra + 2021-08-24T13:08:00.000Z + + + Null Null + 2021-08-26T02:43:00.000Z + + + Oleg Andreev + 2021-08-26T08:12:00.000Z + + + Jeremy + 2021-08-26T10:26:00.000Z + + + Michael Folkson + 2021-08-26T13:09:00.000Z + + + Jeremy + 2021-08-26T20:03:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Is there a tool like Ethereum EVM at present for Bitcoin script? - 2023-08-02T04:37:38.132373+00:00 + 2025-09-26T15:38:39.932767+00:00 - In a recent email exchange, Andrew Poelstra of Sapio discussed the company's plans to take advantage of Taproot with Sapio. He mentioned that they need the rust Bitcoin taproot ecosystem to mature before they can fully utilize Taproot with Sapio. Additionally, he stated that they require a spec for miniscript taproot, but they could "monkey patch" one in without it. There were questions about Sapio and CTV on Libera equivalents of Freenode channels #sapio and ##ctv-bip-review, and it is unclear whether Sapio plans to join and claim those channels.Sapio assumes extensions to Bitcoin Script that are not currently part of the consensus code. However, users can stub out missing extensions with a signing federation instead, configurable as flags. It is also possible to write contracts that do not use ctv based components at all. The protocol for emulation ensures that contract compilation is completely offline and the oracles are stateless. Relevant links to resources on the Sapio website were provided.Bitcoin does not have a virtual machine, but higher level languages like Miniscript, Min.sc, Simplicity, and Sapio can compile to Bitcoin Script. Although programming with Bitcoin script is based on reverse Polish expression, it has rich opcode expression ability which may be unfriendly for programmers and affect the promotion of Bitcoin in the technical community. A tool similar to Ethereum EVM does not exist at present, but users can write bitcoin scripts in a syntax similar to Python or other programming languages and translate them into original bitcoin scripts. Gijs van Dam suggests Sapio as it is written in Rust and might fit better in a user's setting. The Ivy lang Playground by Dan Robinson compiles contracts to Bitcoin Script but is not actively maintained.A user on the bitcoin-dev mailing list asked if there is a tool similar to Ethereum's EVM that allows users to write Bitcoin scripts in a syntax like Python and translate them into Bitcoin original scripts. In response, Gijs van Dam suggested using higher-level languages like Miniscript, Min.sc, Simplicity, or Sapio, which all compile to Bitcoin Script. The user spent some time learning Miniscript and wondered if it is a brand new Bitcoin scripting language and whether they need to compile it into a Bitcoin OP_CODE script. They also found a compiler implemented in C++ on GitHub by sipa, which translates the policy language into Miniscript.In a recent email sent to the Bitcoin-dev mailing list, a user asked if there was a tool available that allows users to write Bitcoin scripts in a syntax similar to Python. In response, Andrew Poelstra provided a list of higher-level languages that can compile to Bitcoin Script, including Miniscript, Min.sc, Simplicity, and Sapio. These languages offer simpler ways to write Bitcoin scripts. While Bitcoin does not have a virtual machine, these languages provide alternatives for programming with Bitcoin Script. However, it should be noted that these extensions are not currently part of the consensus code.Bitcoin does not have a virtual machine, but there are higher level languages like Miniscript, Min.sc, Simplicity and Sapio that compile to Bitcoin Script. Sapio is based on Rust and may be the best fit for certain settings. A question was posed on the Bitcoin Stackexchange about whether there is a tool like Ethereum EVM at present for Bitcoin script programming, where users can write scripts in a syntax similar to Python and translate them into Bitcoin original scripts. The writer suggests that Bitcoin's opcode expression ability is rich but unfriendly, which has affected its promotion in the technical community. 2021-08-26T20:03:47+00:00 + In a recent email exchange, Andrew Poelstra of Sapio discussed the company's plans to take advantage of Taproot with Sapio. He mentioned that they need the rust Bitcoin taproot ecosystem to mature before they can fully utilize Taproot with Sapio. Additionally, he stated that they require a spec for miniscript taproot, but they could "monkey patch" one in without it. There were questions about Sapio and CTV on Libera equivalents of Freenode channels #sapio and ##ctv-bip-review, and it is unclear whether Sapio plans to join and claim those channels.Sapio assumes extensions to Bitcoin Script that are not currently part of the consensus code. However, users can stub out missing extensions with a signing federation instead, configurable as flags. It is also possible to write contracts that do not use ctv based components at all. The protocol for emulation ensures that contract compilation is completely offline and the oracles are stateless. Relevant links to resources on the Sapio website were provided.Bitcoin does not have a virtual machine, but higher level languages like Miniscript, Min.sc, Simplicity, and Sapio can compile to Bitcoin Script. Although programming with Bitcoin script is based on reverse Polish expression, it has rich opcode expression ability which may be unfriendly for programmers and affect the promotion of Bitcoin in the technical community. A tool similar to Ethereum EVM does not exist at present, but users can write bitcoin scripts in a syntax similar to Python or other programming languages and translate them into original bitcoin scripts. Gijs van Dam suggests Sapio as it is written in Rust and might fit better in a user's setting. The Ivy lang Playground by Dan Robinson compiles contracts to Bitcoin Script but is not actively maintained.A user on the bitcoin-dev mailing list asked if there is a tool similar to Ethereum's EVM that allows users to write Bitcoin scripts in a syntax like Python and translate them into Bitcoin original scripts. In response, Gijs van Dam suggested using higher-level languages like Miniscript, Min.sc, Simplicity, or Sapio, which all compile to Bitcoin Script. The user spent some time learning Miniscript and wondered if it is a brand new Bitcoin scripting language and whether they need to compile it into a Bitcoin OP_CODE script. They also found a compiler implemented in C++ on GitHub by sipa, which translates the policy language into Miniscript.In a recent email sent to the Bitcoin-dev mailing list, a user asked if there was a tool available that allows users to write Bitcoin scripts in a syntax similar to Python. In response, Andrew Poelstra provided a list of higher-level languages that can compile to Bitcoin Script, including Miniscript, Min.sc, Simplicity, and Sapio. These languages offer simpler ways to write Bitcoin scripts. While Bitcoin does not have a virtual machine, these languages provide alternatives for programming with Bitcoin Script. However, it should be noted that these extensions are not currently part of the consensus code.Bitcoin does not have a virtual machine, but there are higher level languages like Miniscript, Min.sc, Simplicity and Sapio that compile to Bitcoin Script. Sapio is based on Rust and may be the best fit for certain settings. A question was posed on the Bitcoin Stackexchange about whether there is a tool like Ethereum EVM at present for Bitcoin script programming, where users can write scripts in a syntax similar to Python and translate them into Bitcoin original scripts. The writer suggests that Bitcoin's opcode expression ability is rich but unfriendly, which has affected its promotion in the technical community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Online-discussion-on-Taproot-roll-out-Tuesday-July-20th-17-15-UTC.xml b/static/bitcoin-dev/Aug_2021/combined_Online-discussion-on-Taproot-roll-out-Tuesday-July-20th-17-15-UTC.xml index 9d1b99e4e1..63dee0287a 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Online-discussion-on-Taproot-roll-out-Tuesday-July-20th-17-15-UTC.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Online-discussion-on-Taproot-roll-out-Tuesday-July-20th-17-15-UTC.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC - 2023-08-02T04:23:27.411386+00:00 - - Michael Folkson 2021-08-03 09:59:25+00:00 - - - Michael Folkson 2021-07-17 13:16:19+00:00 - + 2025-09-26T15:38:46.234808+00:00 + python-feedgen + + + [bitcoin-dev] Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC Michael Folkson + 2021-07-17T13:16:00.000Z + + + Michael Folkson + 2021-08-03T09:59:00.000Z + + - python-feedgen + 2 Combined summary - Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC - 2023-08-02T04:23:27.411386+00:00 + 2025-09-26T15:38:46.235265+00:00 - On July 20th, there was an online Zoom call held to discuss the Taproot roll out post activation in November. The focus of the discussion was on developers and the event was livestreamed on YouTube, allowing anyone to attend or watch. Murch, a participant in the call, has created a wiki page that tracks planned ecosystem support of P2TR addresses. The organizers of the event encouraged projects and businesses with Taproot support on their development roadmaps to contribute to the discussion. The meetup link, where the Zoom link was announced, was shared for participants to access. Prior to the call, draft pre-reading links were provided, which were expected to be finalized before Tuesday. These links can be found on https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254.In summary, the online discussion on Taproot roll out took place on July 20th. It was primarily focused on developers but open to everyone. Murch's wiki page monitoring planned ecosystem support of P2TR addresses was highlighted, and participants were encouraged to share their Taproot support plans. The meetup link and draft pre-reading links were also shared for participants' convenience. 2021-08-03T09:59:25+00:00 + On July 20th, there was an online Zoom call held to discuss the Taproot roll out post activation in November. The focus of the discussion was on developers and the event was livestreamed on YouTube, allowing anyone to attend or watch. Murch, a participant in the call, has created a wiki page that tracks planned ecosystem support of P2TR addresses. The organizers of the event encouraged projects and businesses with Taproot support on their development roadmaps to contribute to the discussion. The meetup link, where the Zoom link was announced, was shared for participants to access. Prior to the call, draft pre-reading links were provided, which were expected to be finalized before Tuesday. These links can be found on https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254.In summary, the online discussion on Taproot roll out took place on July 20th. It was primarily focused on developers but open to everyone. Murch's wiki page monitoring planned ecosystem support of P2TR addresses was highlighted, and participants were encouraged to share their Taproot support plans. The meetup link and draft pre-reading links were also shared for participants' convenience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml b/static/bitcoin-dev/Aug_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml index b85f409a74..4777b6ef9d 100644 --- a/static/bitcoin-dev/Aug_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml +++ b/static/bitcoin-dev/Aug_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml @@ -1,83 +1,127 @@ - + 2 Combined summary - PSA: Taproot loss of quantum protections - 2023-08-02T03:25:39.708542+00:00 - - Erik Aronesty 2021-08-12 22:08:40+00:00 - - - Lloyd Fournier 2021-04-16 05:00:07+00:00 - - - ZmnSCPxj 2021-04-16 03:47:45+00:00 - - - Lloyd Fournier 2021-04-05 00:27:50+00:00 - - - Tim Ruffing 2021-03-23 10:50:20+00:00 - - - Martin Schwarz 2021-03-23 09:36:32+00:00 - - - Erik Aronesty 2021-03-22 14:24:55+00:00 - - - Eoin McQuinn 2021-03-17 11:56:26+00:00 - - - Ryan Grant 2021-03-17 01:23:50+00:00 - - - Matt Corallo 2021-03-16 17:25:40+00:00 - - - Andrea 2021-03-16 14:10:21+00:00 - - - Andrew Poelstra 2021-03-16 13:28:34+00:00 - - - Luke Dashjr 2021-03-16 03:44:25+00:00 - - - ZmnSCPxj 2021-03-16 02:38:55+00:00 - - - Anthony Towns 2021-03-16 00:50:01+00:00 - - - David A. Harding 2021-03-16 00:24:01+00:00 - - - Lloyd Fournier 2021-03-15 23:46:05+00:00 - - - Matt Corallo 2021-03-15 23:19:22+00:00 - - - Andrew Poelstra 2021-03-15 23:12:18+00:00 - - - Karl-Johan Alm 2021-03-15 23:01:47+00:00 - - - Matt Corallo 2021-03-15 22:48:21+00:00 - - - Jeremy 2021-03-15 22:40:07+00:00 - - - Robert Spigler 2021-03-15 22:30:35+00:00 - - - Matt Corallo 2021-03-15 22:05:45+00:00 - - - Luke Dashjr 2021-03-15 21:48:15+00:00 - + 2025-09-26T15:38:42.047186+00:00 + python-feedgen + + + [bitcoin-dev] PSA: Taproot loss of quantum protections Luke Dashjr + 2021-03-15T21:48:00.000Z + + + Matt Corallo + 2021-03-15T22:05:00.000Z + + + Robert Spigler + 2021-03-15T22:30:00.000Z + + + Jeremy + 2021-03-15T22:40:00.000Z + + + Matt Corallo + 2021-03-15T22:48:00.000Z + + + Karl-Johan Alm + 2021-03-15T23:01:00.000Z + + + Andrew Poelstra + 2021-03-15T23:12:00.000Z + + + Matt Corallo + 2021-03-15T23:19:00.000Z + + + Lloyd Fournier + 2021-03-15T23:46:00.000Z + + + [bitcoin-dev] PSA: Taproot loss of quantum protections David A. Harding + 2021-03-16T00:24:00.000Z + + + Anthony Towns + 2021-03-16T00:50:00.000Z + + + ZmnSCPxj + 2021-03-16T02:38:00.000Z + + + Luke Dashjr + 2021-03-16T03:44:00.000Z + + + Andrew Poelstra + 2021-03-16T13:28:00.000Z + + + Andrea + 2021-03-16T14:10:00.000Z + + + [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections) Andrew Poelstra + 2021-03-16T15:15:00.000Z + + + Matt Corallo + 2021-03-16T17:25:00.000Z + + + Ryan Grant + 2021-03-17T01:23:00.000Z + + + ZmnSCPxj + 2021-03-17T04:24:00.000Z + + + Andrea + 2021-03-17T08:29:00.000Z + + + Eoin McQuinn + 2021-03-17T11:56:00.000Z + + + Andrea Barontini + 2021-03-20T16:31:00.000Z + + + Erik Aronesty + 2021-03-22T14:24:00.000Z + + + Martin Schwarz + 2021-03-23T09:36:00.000Z + + + Tim Ruffing + 2021-03-23T10:50:00.000Z + + + Lloyd Fournier + 2021-04-05T00:27:00.000Z + + + ZmnSCPxj + 2021-04-16T03:47:00.000Z + + + Lloyd Fournier + 2021-04-16T05:00:00.000Z + + + Erik Aronesty + 2021-08-12T22:08:00.000Z + + @@ -103,13 +147,13 @@ - python-feedgen + 2 Combined summary - PSA: Taproot loss of quantum protections - 2023-08-02T03:25:39.708542+00:00 + 2025-09-26T15:38:42.049988+00:00 - The safety of Taproot, a proposed upgrade to Bitcoin's software, has been a topic of discussion on the bitcoin-dev mailing list. Some individuals have expressed concerns about the vulnerability of Taproot to quantum computing attacks. They argue that Taproot lacks an important safety protection against quantum computers. However, others believe that there is no significant difference in terms of Bitcoin's vulnerability to quantum computing before and after Taproot.Address reuse has also been brought up as a factor in the debate. While hash-based addresses are recommended to reduce the risk of address reuse, many people still reuse Bitcoin invoice addresses. It has been pointed out that 37% of the supply is at risk of quantum attack due to this practice.Developer Mark Friedenbach is particularly concerned about Taproot's vulnerability to quantum computers. He suggests that without Taproot, the network could "pause" while a full quantum-safe solution is developed. However, with Taproot, it could become an unrecoverable situation if quantum computers come online before a solution is implemented. Friedenbach argues that Taproot does not provide any additional benefits, as the features it proposes can be implemented using hashed keys instead of raw keys. Despite these concerns, Friedenbach believes that Taproot should not be rejected and suggests adding a hash on top in an additional softfork to address the safety issue.In response to the argument that 37% of the supply being at risk is a security concern, Friedenbach suggests that social efforts discouraging address reuse can improve the situation. He also mentions that when neglected or abandoned/lost coins are compromised by quantum computers, it can be seen as equivalent to Bitcoin mining. Therefore, he argues that 37% of the supply minable by quantum computers is no different than 37% minable by ASICs.Despite the concerns raised, Taproot has entered the activation phase, and it is expected that the software will be released in the next month or two. Friedenbach recommends that anyone using Bitcoin read his article and other arguments on the topic to decide if this is a concern for them, and encourages them to make their own posts accordingly.Overall, the discussions revolve around the potential risks and mitigations related to quantum computing and Taproot in the Bitcoin ecosystem. The community is actively addressing these challenges and working towards ensuring the security and resilience of the network. 2021-08-12T22:08:40+00:00 + The safety of Taproot, a proposed upgrade to Bitcoin's software, has been a topic of discussion on the bitcoin-dev mailing list. Some individuals have expressed concerns about the vulnerability of Taproot to quantum computing attacks. They argue that Taproot lacks an important safety protection against quantum computers. However, others believe that there is no significant difference in terms of Bitcoin's vulnerability to quantum computing before and after Taproot.Address reuse has also been brought up as a factor in the debate. While hash-based addresses are recommended to reduce the risk of address reuse, many people still reuse Bitcoin invoice addresses. It has been pointed out that 37% of the supply is at risk of quantum attack due to this practice.Developer Mark Friedenbach is particularly concerned about Taproot's vulnerability to quantum computers. He suggests that without Taproot, the network could "pause" while a full quantum-safe solution is developed. However, with Taproot, it could become an unrecoverable situation if quantum computers come online before a solution is implemented. Friedenbach argues that Taproot does not provide any additional benefits, as the features it proposes can be implemented using hashed keys instead of raw keys. Despite these concerns, Friedenbach believes that Taproot should not be rejected and suggests adding a hash on top in an additional softfork to address the safety issue.In response to the argument that 37% of the supply being at risk is a security concern, Friedenbach suggests that social efforts discouraging address reuse can improve the situation. He also mentions that when neglected or abandoned/lost coins are compromised by quantum computers, it can be seen as equivalent to Bitcoin mining. Therefore, he argues that 37% of the supply minable by quantum computers is no different than 37% minable by ASICs.Despite the concerns raised, Taproot has entered the activation phase, and it is expected that the software will be released in the next month or two. Friedenbach recommends that anyone using Bitcoin read his article and other arguments on the topic to decide if this is a concern for them, and encourages them to make their own posts accordingly.Overall, the discussions revolve around the potential risks and mitigations related to quantum computing and Taproot in the Bitcoin ecosystem. The community is actively addressing these challenges and working towards ensuring the security and resilience of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Proposal-for-a-few-IANA-mime-types-related-to-Bitcoin.xml b/static/bitcoin-dev/Aug_2021/combined_Proposal-for-a-few-IANA-mime-types-related-to-Bitcoin.xml index f7672ad4b1..346c7c4980 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Proposal-for-a-few-IANA-mime-types-related-to-Bitcoin.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Proposal-for-a-few-IANA-mime-types-related-to-Bitcoin.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Proposal for a few IANA mime-types related to Bitcoin - 2023-08-02T04:39:09.961743+00:00 - - Dr Maxim Orlovsky 2021-09-02 10:52:13+00:00 - - - Peter D. Gray 2021-09-01 13:39:30+00:00 - - - Christopher Allen 2021-08-31 20:02:44+00:00 - - - Andrew Chow 2021-08-31 19:46:55+00:00 - - - Peter D. Gray 2021-08-31 19:18:00+00:00 - - - Christopher Allen 2021-08-31 19:01:23+00:00 - - - Peter D. Gray 2021-08-31 18:27:41+00:00 - + 2025-09-26T15:38:27.270316+00:00 + python-feedgen + + + [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin Peter D. Gray + 2021-08-31T18:27:00.000Z + + + Christopher Allen + 2021-08-31T19:01:00.000Z + + + Peter D. Gray + 2021-08-31T19:18:00.000Z + + + Andrew Chow + 2021-08-31T19:46:00.000Z + + + Christopher Allen + 2021-08-31T20:02:00.000Z + + + Peter D. Gray + 2021-09-01T13:39:00.000Z + + + Dr Maxim Orlovsky + 2021-09-02T10:52:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Proposal for a few IANA mime-types related to Bitcoin - 2023-08-02T04:39:09.961743+00:00 + 2025-09-26T15:38:27.271233+00:00 - In a recent discussion on the Bitcoin-dev mailing list, Peter D. Gray proposed registering three new MIME media types with the Internet Assigned Numbers Authority (IANA) for Bitcoin-related content. The proposed media types are bitcoin/psbt, bitcoin/txn, and bitcoin/uri. However, Andrew Chow expressed doubts about the feasibility of registering these MIME types due to the limited number of accepted top-level types and the requirements for registration in the Standards tree. Chow explained that the best tree for the MIME type would be the Standards tree, but it requires registration either associated with an IETF specification or registered by a recognized standards-related organization. Since Bitcoin does not have a recognized standards organization, Chow suggested ignoring the IANA and declaring useful "mime types" in a new BIP that can be agreed upon within the Bitcoin community. Maxim Orlovsky from LNP/BP Standards Association expressed willingness to write the draft of the proposed BIP. Peter acknowledged Andrew's concerns and suggested writing an independent submission RFC for the proposed MIME types. He provided details on the proposed MIME types, including their descriptions and potential uses. He also indicated that they could be useful beyond web servers, such as in NFC (NDEF records) where shorter length is critical. Peter noted that while some MIME types were proposed in BIP-71, they were unrelated to the proposed ones and were never registered.In conclusion, Peter proposed new MIME types for Bitcoin-related content. While there were concerns about the registration process, a new BIP will be drafted to declare these useful "mime types" and agree upon their usage within the Bitcoin community. 2021-09-02T10:52:13+00:00 + In a recent discussion on the Bitcoin-dev mailing list, Peter D. Gray proposed registering three new MIME media types with the Internet Assigned Numbers Authority (IANA) for Bitcoin-related content. The proposed media types are bitcoin/psbt, bitcoin/txn, and bitcoin/uri. However, Andrew Chow expressed doubts about the feasibility of registering these MIME types due to the limited number of accepted top-level types and the requirements for registration in the Standards tree. Chow explained that the best tree for the MIME type would be the Standards tree, but it requires registration either associated with an IETF specification or registered by a recognized standards-related organization. Since Bitcoin does not have a recognized standards organization, Chow suggested ignoring the IANA and declaring useful "mime types" in a new BIP that can be agreed upon within the Bitcoin community. Maxim Orlovsky from LNP/BP Standards Association expressed willingness to write the draft of the proposed BIP. Peter acknowledged Andrew's concerns and suggested writing an independent submission RFC for the proposed MIME types. He provided details on the proposed MIME types, including their descriptions and potential uses. He also indicated that they could be useful beyond web servers, such as in NFC (NDEF records) where shorter length is critical. Peter noted that while some MIME types were proposed in BIP-71, they were unrelated to the proposed ones and were never registered.In conclusion, Peter proposed new MIME types for Bitcoin-related content. While there were concerns about the registration process, a new BIP will be drafted to declare these useful "mime types" and agree upon their usage within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Removing-the-Dust-Limit.xml b/static/bitcoin-dev/Aug_2021/combined_Removing-the-Dust-Limit.xml index 4cbc05258f..87792684e7 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Removing-the-Dust-Limit.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Removing-the-Dust-Limit.xml @@ -1,119 +1,151 @@ - + 2 Combined summary - Removing the Dust Limit - 2023-08-02T04:31:39.825006+00:00 - - vjudeu at gazeta.pl 2022-03-12 13:02:24+00:00 - - - ZmnSCPxj 2021-10-08 22:47:11+00:00 - - - ZmnSCPxj 2021-10-08 10:38:50+00:00 - - - shymaa arafat 2021-10-08 07:44:59+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 10:35:16+00:00 - - - ZmnSCPxj 2021-10-07 10:01:53+00:00 - - - shymaa arafat 2021-10-07 09:13:33+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 08:34:17+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 08:17:40+00:00 - - - ZmnSCPxj 2021-10-07 04:52:01+00:00 - - - Erik Aronesty 2021-10-01 13:40:06+00:00 - - - Pieter Wuille 2021-09-30 22:07:08+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-08-30 03:31:56+00:00 - - - shymaa arafat 2021-08-27 09:07:35+00:00 - - - Billy Tetrud 2021-08-26 21:21:25+00:00 - - - ZmnSCPxj 2021-08-21 03:10:46+00:00 - - - shymaa arafat 2021-08-20 05:45:31+00:00 - - - Jeremy 2021-08-20 04:51:31+00:00 - - - shymaa arafat 2021-08-18 19:06:30+00:00 - - - Anthony Towns 2021-08-12 22:03:39+00:00 - - - ZmnSCPxj 2021-08-11 00:46:36+00:00 - - - Antoine Riard 2021-08-10 22:37:48+00:00 - - - Charlie Lee 2021-08-10 18:39:39+00:00 - - - ZmnSCPxj 2021-08-10 11:37:37+00:00 - - - David A. Harding 2021-08-10 06:14:41+00:00 - - - Billy Tetrud 2021-08-10 05:44:04+00:00 - - - Jeremy 2021-08-10 05:04:07+00:00 - - - Billy Tetrud 2021-08-10 00:30:02+00:00 - - - Antoine Riard 2021-08-09 13:22:28+00:00 - - - Karl 2021-08-09 11:58:03+00:00 - - - Prayank 2021-08-09 10:25:50+00:00 - - - Jeremy 2021-08-08 23:07:27+00:00 - - - Jeremy 2021-08-08 22:46:26+00:00 - - - David A. Harding 2021-08-08 21:51:01+00:00 - - - Oleg Andreev 2021-08-08 21:41:32+00:00 - - - Matt Corallo 2021-08-08 21:14:23+00:00 - - - Jeremy 2021-08-08 18:52:55+00:00 - + 2025-09-26T15:38:31.506500+00:00 + python-feedgen + + + [bitcoin-dev] Removing the Dust Limit Jeremy + 2021-08-08T18:52:00.000Z + + + Matt Corallo + 2021-08-08T21:14:00.000Z + + + Oleg Andreev + 2021-08-08T21:41:00.000Z + + + [bitcoin-dev] [Lightning-dev] " David A. Harding + 2021-08-08T21:51:00.000Z + + + Jeremy + 2021-08-08T22:46:00.000Z + + + Jeremy + 2021-08-08T23:07:00.000Z + + + [bitcoin-dev] " Prayank + 2021-08-09T10:25:00.000Z + + + Karl + 2021-08-09T11:58:00.000Z + + + Antoine Riard + 2021-08-09T13:22:00.000Z + + + Billy Tetrud + 2021-08-10T00:30:00.000Z + + + Jeremy + 2021-08-10T05:04:00.000Z + + + Billy Tetrud + 2021-08-10T05:44:00.000Z + + + David A. Harding + 2021-08-10T06:14:00.000Z + + + ZmnSCPxj + 2021-08-10T11:37:00.000Z + + + Charlie Lee + 2021-08-10T18:39:00.000Z + + + Antoine Riard + 2021-08-10T22:37:00.000Z + + + ZmnSCPxj + 2021-08-11T00:46:00.000Z + + + Anthony Towns + 2021-08-12T22:03:00.000Z + + + Jeremy + 2021-08-20T04:51:00.000Z + + + shymaa arafat + 2021-08-20T05:45:00.000Z + + + ZmnSCPxj + 2021-08-21T03:10:00.000Z + + + Billy Tetrud + 2021-08-26T21:21:00.000Z + + + shymaa arafat + 2021-08-27T09:07:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-08-30T03:31:00.000Z + + + Pieter Wuille + 2021-09-30T22:07:00.000Z + + + Erik Aronesty + 2021-10-01T13:40:00.000Z + + + ZmnSCPxj + 2021-10-07T04:52:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T08:17:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T08:34:00.000Z + + + shymaa arafat + 2021-10-07T09:13:00.000Z + + + ZmnSCPxj + 2021-10-07T10:01:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T10:35:00.000Z + + + shymaa arafat + 2021-10-08T07:44:00.000Z + + + ZmnSCPxj + 2021-10-08T10:38:00.000Z + + + ZmnSCPxj + 2021-10-08T22:47:00.000Z + + @@ -151,13 +183,13 @@ - python-feedgen + 2 Combined summary - Removing the Dust Limit - 2023-08-02T04:31:39.825967+00:00 + 2025-09-26T15:38:31.510058+00:00 - Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees. However, this short-term incentive is countered by concerns about spam and dust fingerprinting attacks.In conclusion, 2022-03-12T13:02:24+00:00 + Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees. However, this short-term incentive is countered by concerns about spam and dust fingerprinting attacks.In conclusion, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_Using-transaction-version-number-in-different-projects.xml b/static/bitcoin-dev/Aug_2021/combined_Using-transaction-version-number-in-different-projects.xml index 5b418ac8b1..97d7913214 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Using-transaction-version-number-in-different-projects.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Using-transaction-version-number-in-different-projects.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Using transaction version number in different projects - 2023-08-02T04:38:59.600303+00:00 - - Pieter Wuille 2021-08-29 14:56:16+00:00 - - - Prayank 2021-08-29 09:32:47+00:00 - + 2025-09-26T15:38:35.723699+00:00 + python-feedgen + + + [bitcoin-dev] Using transaction version number in different projects Prayank + 2021-08-29T09:32:00.000Z + + + Pieter Wuille + 2021-08-29T14:56:00.000Z + + - python-feedgen + 2 Combined summary - Using transaction version number in different projects - 2023-08-02T04:38:59.600303+00:00 + 2025-09-26T15:38:35.724141+00:00 - On August 29th, 2021, a user named Prayank initiated a discussion on the bitcoin-dev forum regarding whether more numbers should be permitted in transaction version. They presented an example illustrating how transaction version could be utilized for betting on events with two possible outcomes. However, another user named Pieter expressed confusion regarding the relevance of this suggestion to transaction version numbers.Pieter argued that Bitcoin transactions should solely contain essential information for validation purposes. Currently, there are no consensus rules or relay policies that consider the version number, except for it being 1 or 2 (due to BIP68). Therefore, utilizing any numbers beyond these two would be futile and compromise privacy. Additionally, unused version numbers may be employed for future consensus rules, so employing them for non-protocol-defined purposes could disrupt these rules.To support their viewpoint, Pieter referenced a code snippet of "Hello, world!" shared by the original poster. The snippet included a link to a question on Bitcoin Stackexchange related to Bitcoin transaction version. In the question, the author provided an example demonstrating how transaction version can be used for betting on events involving two outcomes, without relying on centralized servers or trusting third parties. The approach involved creating a multisig address using two public keys, one entered by the user and the other from mempool. A funding transaction was then executed, utilizing version bits to indicate whether Alice wanted to bet on India or Australia. The author sought confirmation on the correctness of their approach until the funding transaction and asked for opinions on whether more numbers should be allowed in transaction version.The original poster also shared a link to a Github repository containing the complete example for reference. Despite this detailed example, Pieter remained unconvinced and emphasized that version numbers lacking protocol-defined significance should not become standard, but rather be reserved for future extensions. 2021-08-29T14:56:16+00:00 + On August 29th, 2021, a user named Prayank initiated a discussion on the bitcoin-dev forum regarding whether more numbers should be permitted in transaction version. They presented an example illustrating how transaction version could be utilized for betting on events with two possible outcomes. However, another user named Pieter expressed confusion regarding the relevance of this suggestion to transaction version numbers.Pieter argued that Bitcoin transactions should solely contain essential information for validation purposes. Currently, there are no consensus rules or relay policies that consider the version number, except for it being 1 or 2 (due to BIP68). Therefore, utilizing any numbers beyond these two would be futile and compromise privacy. Additionally, unused version numbers may be employed for future consensus rules, so employing them for non-protocol-defined purposes could disrupt these rules.To support their viewpoint, Pieter referenced a code snippet of "Hello, world!" shared by the original poster. The snippet included a link to a question on Bitcoin Stackexchange related to Bitcoin transaction version. In the question, the author provided an example demonstrating how transaction version can be used for betting on events involving two outcomes, without relying on centralized servers or trusting third parties. The approach involved creating a multisig address using two public keys, one entered by the user and the other from mempool. A funding transaction was then executed, utilizing version bits to indicate whether Alice wanted to bet on India or Australia. The author sought confirmation on the correctness of their approach until the funding transaction and asked for opinions on whether more numbers should be allowed in transaction version.The original poster also shared a link to a Github repository containing the complete example for reference. Despite this detailed example, Pieter remained unconvinced and emphasized that version numbers lacking protocol-defined significance should not become standard, but rather be reserved for future extensions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2021/combined_src-httprpc-cpp-InterruptHTTPRPC.xml b/static/bitcoin-dev/Aug_2021/combined_src-httprpc-cpp-InterruptHTTPRPC.xml index e5f84f476f..56e898681f 100644 --- a/static/bitcoin-dev/Aug_2021/combined_src-httprpc-cpp-InterruptHTTPRPC.xml +++ b/static/bitcoin-dev/Aug_2021/combined_src-httprpc-cpp-InterruptHTTPRPC.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - src/httprpc.cpp InterruptHTTPRPC - 2023-08-02T04:36:28.320218+00:00 - - Jeremy 2021-08-12 18:09:19+00:00 - - - Ali Sherief 2021-08-12 16:26:23+00:00 - + 2025-09-26T15:38:44.136478+00:00 + python-feedgen + + + [bitcoin-dev] src/httprpc.cpp InterruptHTTPRPC Ali Sherief + 2021-08-12T16:26:00.000Z + + + Jeremy + 2021-08-12T18:09:00.000Z + + - python-feedgen + 2 Combined summary - src/httprpc.cpp InterruptHTTPRPC - 2023-08-02T04:36:28.320218+00:00 + 2025-09-26T15:38:44.136961+00:00 - Ali, a developer working on his own application using Bitcoin Core's HTTP RPC server, has come across a question regarding the functionality of the InterruptHTTPRPC function in src/httprpc.cpp. He noticed that the function only calls LogPrint() without any further action. This leads Ali to wonder if the function is simply a stub or if it actually supports interrupting the event loop at this time.To get a more detailed response, another user suggests that Ali open an issue on Github. This will allow him to engage with the community and receive further insights into the functionality of the InterruptHTTPRPC function. By opening an issue, Ali can expect to get a more comprehensive answer to his inquiry, providing him with the necessary information for his own application development.Overall, Ali's question about the InterruptHTTPRPC function and its ability to interrupt the event loop in Bitcoin Core's HTTP RPC server highlights the importance of community engagement and seeking clarification when encountering uncertainties in source code. Opening an issue on Github presents an opportunity for Ali to gain valuable insights from the community, ensuring the successful development of his own application. 2021-08-12T18:09:19+00:00 + Ali, a developer working on his own application using Bitcoin Core's HTTP RPC server, has come across a question regarding the functionality of the InterruptHTTPRPC function in src/httprpc.cpp. He noticed that the function only calls LogPrint() without any further action. This leads Ali to wonder if the function is simply a stub or if it actually supports interrupting the event loop at this time.To get a more detailed response, another user suggests that Ali open an issue on Github. This will allow him to engage with the community and receive further insights into the functionality of the InterruptHTTPRPC function. By opening an issue, Ali can expect to get a more comprehensive answer to his inquiry, providing him with the necessary information for his own application development.Overall, Ali's question about the InterruptHTTPRPC function and its ability to interrupt the event loop in Bitcoin Core's HTTP RPC server highlights the importance of community engagement and seeking clarification when encountering uncertainties in source code. Opening an issue on Github presents an opportunity for Ali to gain valuable insights from the community, ensuring the successful development of his own application. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml b/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml index c81a11d54d..3ae6bc4158 100644 --- a/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml +++ b/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml @@ -2,7 +2,7 @@ 2 Combined summary - A method for BIP322 signing delegation - 2025-09-26T14:26:10.364022+00:00 + 2025-09-26T15:35:26.065718+00:00 python-feedgen Ali Sherief 2022-08-22 07:56:12+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - A method for BIP322 signing delegation - 2025-09-26T14:26:10.364175+00:00 + 2025-09-26T15:35:26.065851+00:00 2022-08-22T07:56:12+00:00 The message discusses an edge case that BIP322 only partially solves - Proof of Payment. In P2P transactions, there is always a risk that the other party will be dishonest and deny receiving payment. This type of dispute is rampant in cryptocurrencies as it can be used as a scam attempt to extract more money from the buyer. BIP322 signed messages can prove that the UTXO(s) belong to the buyer, but not *who* it was sent to.The proposal is to use P2WSH 2-of-2 multisig to solve this problem. The script challenge consists of something like OP_SHA256 OP_EQUAL. The idea behind the scheme is to make it verifiable to the public. Alice signs a BIP322 message from a UTXO and provides one of the signatures, Bob is forced to sign another BIP322 message from his address if he wants his money, and provides another signature. Both signatures are published on the blockchain. The signatures in the Multisig transaction prove who has control of which inputs, so it can be proven who paid who.A delegation scheme for privacy purposes has been proposed that utilizes multisig to make the possible delegatees known at signing time. This would replace the message challenge of "to_spend" with a 1-of-N standard P2WPKH multisig, where N is the number of people you want to be able to create the signature, and their respective pubkeys are included in the script. The possible delegatees are fixed at signature creation time and cannot be extended by creating more transactions. The challenge solution in "to_sign" is then replaced with a witness stack containing n ... 1 0. The signature is generated as if it were for a real P2WPKH-multisig transaction.The proposal has some advantages: no recursive transactions, address verification is provable, there is no opcode or new algorithm introduced, so no soft-fork is required, and signature fraud is still impossible to carry out. There is also a major privacy advantage in that only the delegatee who actually signs the message has a revealed public key, the others' are hidden. There are some disadvantages, such as everyone knows the public keys of the delegators, so there is no privacy. However, this is possibly a non-issue in light of the signature fraud problem. Additionally, Taproot is not widely deployed in applications yet.Moreover, some people have suggested writing this delegation scheme in TapScript, which could avoid revealing the unspent public keys. Single leaf k-of-n multisig is functionally identical to "Using a single OP_CHECKSIGADD-based script" described in BIP 0342, footnote 5, but it won't hide the non-signing public keys. That leaves multi-leaf k-of-k multisig, which swells as k increases, but for the purposes of delegation, K will always be 1, because we only utilize 1-n multisig signatures as per the previous message.This post discusses a proposal for BIP322 polishing, specifically regarding delegating signatures to other scriptPubKeys for privacy purposes. Instead of using a complicated transaction scheme, the proposal suggests using a multisig approach that makes possible delegatees known at signing time. The proposal outlines steps to replace the message challenge and challenge solution with a witness stack containing n...1 0, generating the signature as if it were for a real P2WPKH-multisig transaction. The pros of this approach are outlined, including no recursive transactions and provable address verification, while the con is that public keys of delegators are known, potentially compromising privacy. Input from others is requested, particularly from luke-jr who participated in the original Github discussion on delegation.A proposal has been made to solve the delegation problem in BIP322. This solution is built on Jeremy Rubin's transaction delegation post and allows a person to delegate signing to another person. This delegation can be useful for various purposes such as Lightning Network, CoinJoin, Mixers, and Silent Payments. The delegation works by signing a preliminary transaction with specific inputs and outputs. The signed message includes the Message, Address, and Signature. BIP322 specifies that the signature is just the raw transaction format of "to_sign". The address used can represent a kind of company; it can represent a channel, a coinjoin, or a silent payment. Bech32 is used to encode the "address" to make it look like a real address.The advantages of this scheme include privacy, arbitrary number of delegations, and delegated signatures can wrap Full and Full with UTXOs signing formats. There are no disadvantages to this scheme. The FAQ section clarifies how the delegation works, how to differentiate between non-delegated and delegated signatures, and how to verify a delegated BIP322 transaction if the address-hash is private. The proposal is cc'd to Kalle for consideration. diff --git a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml index 757f99d7c1..770e920ac8 100644 --- a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml +++ b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2025-09-26T14:26:33.913889+00:00 + 2025-09-26T15:35:40.880700+00:00 python-feedgen Dmitry Petukhov 2022-08-04 07:09:33+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2025-09-26T14:26:33.914059+00:00 + 2025-09-26T15:35:40.880846+00:00 2022-08-04T07:09:33+00:00 A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. The proposal uses tuples of diff --git a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml index de300f839c..fcd4be2604 100644 --- a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml +++ b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2025-09-26T14:26:23.216006+00:00 + 2025-09-26T15:35:32.401962+00:00 python-feedgen Craig Raw 2022-09-26 08:23:18+00:00 @@ -85,10 +85,11 @@ + 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2025-09-26T14:26:23.216188+00:00 + 2025-09-26T15:35:32.402150+00:00 2022-09-26T08:23:18+00:00 The proposed standard aims to create a defined format for transferring labels that users have applied to transactions, addresses, inputs, or outputs in their wallets. The format uses the comma-separated values (CSV) format, which is widely supported. Each record in the CSV file consists of two fields: the reference to a transaction, address, input, or output, and the label applied to that reference. The proposal suggests using ZIP compression for the CSV file, with optional AES encryption.Some feedback on the proposal includes suggestions for improvements, such as adding a version byte to the header line, making the header line mandatory, and using an unsigned 32-bit integer for the second column. There are also suggestions to remove the optional encryption feature and not include input and output types in the export to avoid privacy leaks. Instead, commentators suggest adding a third column for item type identification.Despite disagreement on the use of CSV as a standard format, the goal of the proposal is to create a standardized format for importing and exporting wallet labels. The proposed format is a simple two-column CSV file, aiming to make label management more accessible to users and ensure compatibility between different wallet implementations. Feedback on the proposal is appreciated, and further improvements may be made based on the feedback received.The use of CSV for transferring labels between wallet applications is motivated by its wide accessibility and integration with existing processes and tools like Excel. However, there is some disagreement about using CSV, with suggestions to use JSON instead due to concerns about CSV compatibility and parsing effort. Despite this disagreement, the proposal aims to create a standard for importing and exporting labels from a wallet, regardless of the chosen data format.The proposal specifies a two-column CSV format, where the first column contains the reference to a transaction, address, input, or output, and the second column contains the label. The CSV file can be compressed using ZIP and optionally encrypted using AES. Importing applications may truncate labels if necessary, while exporting applications may omit records with no labels or labels of zero length.The proposal seeks to make label management accessible to users without technical expertise and reduce file size while ensuring compatibility. The discussion on the Bitcoin-dev mailing list provides insight into ongoing development work on the Bitcoin protocol and the collaborative nature of the Bitcoin development community.There is some disagreement about using CSV as the standard format for transferring labels, with suggestions to use JSON instead. One commenter suggests including descriptors in the format for advanced users. In response to a question about SLIP-0015, it is stated that SLIP-0015 has different design goals and limitations compared to the proposed BIP.The proposal allows for ZIP compression and optional AES encryption of the CSV file. The password for encryption should be the textual representation of the wallet's extended public key. The aim of this proposal is to create a standard for exporting and importing labels from a wallet, avoiding lock-in to a specific application, and making label management accessible to non-technical users.Feedback on the proposal is requested, and a reference implementation is yet to be determined. Suggestions for additions and changes to the format include adding a version byte, making the header line mandatory, requiring double quotes around the label, and writing a more robust importer algorithm. The proposal aims to standardize the export and import of labels using a simple CSV format. diff --git a/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml b/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml index 86d8f7aa6c..2efb31db2e 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Huge wallets make Bitcoin Core unusable (Daemon+CLI & Qt) - 2025-09-26T14:26:27.506762+00:00 + 2025-09-26T15:35:36.631669+00:00 python-feedgen Andrew Chow 2022-08-20 15:10:57+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Huge wallets make Bitcoin Core unusable (Daemon+CLI & Qt) - 2025-09-26T14:26:27.506895+00:00 + 2025-09-26T15:35:36.631812+00:00 2022-08-20T15:10:57+00:00 A developer named Felipe Micaroni Lalli raised two questions on the bitcoin-dev mailing list regarding the optimization of Bitcoin wallet module. The first question was about optimizing a large wallet without moving funds to a new one. In response, it was suggested to use removeprunedfunds RPC which can remove old transactions and speed up balance calculations and transaction creation. The second question was about improving cache usage by putting the entire wallet in memory. However, it was clarified that the wallet is already entirely in memory. The issue with the wallet module is a known one and changing it takes significant time as it is a large module in Bitcoin Core.A user named Felipe Micaroni Lalli posted on the bitcoin-dev forum about the issue he faced with a 5-year-old production server wallet, which had 2.079.337 transactions and 446.503 generated addresses and was around 273 MB in size. The wallet's performance started to degrade exponentially, with most commands timing out. Increasing the timeout and RPC threads in the config file worsened the situation. Even after moving the wallet.dat to a fast SSD disk and increasing cache size, performance wasn't sufficient. If loaded in Bitcoin-qt, the system became unresponsive, making it difficult to use. Felipe questioned if improvements could be made or if the wallet feature should be removed altogether.To run a large Bitcoin core wallet, just call `RemovePrunedFunds` on old transactions. However, it is tricky as one has to ensure that the transaction is "safe to remove." Transactions become unsafe if they have a wallet utxo that you haven't spent or recently spent. Additionally, if transaction B spends from transaction A, removing transaction B will make the wallet think transaction A is unspent when it is not. Thus, pruning should be done depth-first.Bitcoin Core becomes almost useless for the wallet feature since the standard client is slow to sync, hard to use, and not preferred by end-users who opt for Electrum or Wasabi. It also becomes useless for servers in production, forcing them to use third-party solutions for huge wallets. The only current "solution" for huge wallets is to create a new one and send the funds there from time to time, but it can cause privacy concerns and break monitoring of old addresses.Felipe suggested caching the entire wallet in memory, but some code optimization might also be necessary. He asked whether it was possible to optimize a huge wallet without moving funds to a new one, improving cache usage, reducing wallet size, ignoring old addresses, improving I/O treatment, and CPU usage in the main thread on Bitcoin-Qt to avoid window freezing on big and huge wallets. Felipe proposed an "autoarchivehugewallets=1" feature in the file config to create a new wallet and move funds automatically. Felipe included links to several related issues and tests that he thought could be useful for developers. He also mentioned another possible bug where even after moving funds to a new wallet, the old wallet shows an old balance. Rescanblockchain command takes a long time to fix it.A user with a 5-year-old wallet, containing 2.079.337 transactions, and 446.503 generated addresses, has experienced exponential performance degradation when using the Bitcoin Core client. Most of the commands, such as "getbalance", "walletpassphrase" and "getreceivedbyaddress", timed out, while the CPU was 100% used, making the machine almost unusable. The default configuration of 16 RPC threads and 15 min timeout and some attempt calls per mi did not help. Increasing the timeout and/or the RPC threads in the config file made things worse. Loading the wallet in the "bitcoin-qt" caused everything to become unresponsive, including the system (OS/UI).This is bad because the standard client becomes almost useless for the wallet feature. Wallet Qt is already unpopular among end-users, being slow to first sync, hard to use, and not modern. It becomes useless now also for servers in production, forcing them to use third-party solutions for huge wallets. Currently, the only "solution" for huge wallets is to create a new one and send the funds there from time to time. However, this solution is not elegant and can break old address monitoring, leading to privacy concerns and unifying lots of inputs in a big and expensive transaction. The issue could also potentially become an issue if we have LN nodes that use the Bitcoin Core wallet infrastructure behind to open/close many channels for a long time.The user suggests that if moving the wallet from an HDD to an SSD improved a lot, maybe caching the entire wallet in memory could improve even more, but some code optimization is necessary. The following questions were raised: Can we "optimize" a huge wallet without moving the funds to a new one? Can we improve the cache usage somehow? Is it possible to reduce the wallet size? Can we tell the CLI to ignore old addresses? diff --git a/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml b/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml index b18d53f69e..b26cbd0d60 100644 --- a/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml +++ b/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml @@ -2,7 +2,7 @@ 2 Combined summary - New Silent Payment version - 2025-09-26T14:26:08.214181+00:00 + 2025-09-26T15:35:23.950079+00:00 python-feedgen Ali Sherief 2022-08-22 12:55:58+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - New Silent Payment version - 2025-09-26T14:26:08.214364+00:00 + 2025-09-26T15:35:23.950246+00:00 2022-08-22T12:55:58+00:00 A new version of Bitcoin's Silent Payment implementation has been introduced through a Pull Request update (PR #24897) on the Bitcoin codebase on GitHub. This updated version improves upon the previous implementation by eliminating manual steps and introducing a new descriptor type called "sp()". This descriptor type contains exactly one key and generates a unique 'silent-payment' address.The silent payment address can be used as one of the outputs in a transaction, alongside standard addresses. The "send" RPC automatically identifies and tweaks the silent payment address. The output generated is a standard Taproot script with HRP changed from "bc" to "sp" on the mainnet or "tsp" on testnet and signet.It is important to note that the introduction of silent payments does not affect the consensus or auditability rules. These silent transactions are still included in publicly auditable blocks. The only difference is that the addresses cannot be hierarchically derived with BIP44 or any other path.Some critics have expressed concerns about the auditability of these transactions. However, Ali, the developer behind this update, explains that the silent payments are still publicly auditable and adhere to the original consensus that gave Bitcoin fungibility. Despite this explanation, some critics remain skeptical.To facilitate the review process, a step-by-step signet tutorial has been created for testers to easily test this new version. Overall, this updated version of Bitcoin's Silent Payment implementation simplifies the process of making silent payments, making it easier and more efficient for users. diff --git a/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 6d664cbb70..db36920738 100644 --- a/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -2,7 +2,7 @@ 2 Combined summary - On a new community process to specify covenants - 2025-09-26T14:26:14.700951+00:00 + 2025-09-26T15:35:28.177168+00:00 python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -105,10 +105,11 @@ + 2 Combined summary - On a new community process to specify covenants - 2025-09-26T14:26:14.701147+00:00 + 2025-09-26T15:35:28.177355+00:00 2022-10-07T15:33:12+00:00 The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest diff --git a/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml b/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml index b5ea93871d..f641cca7ac 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml @@ -2,7 +2,7 @@ 2 Combined summary - Regarding BIP322 edge cases - 2025-09-26T14:26:25.361822+00:00 + 2025-09-26T15:35:34.516828+00:00 python-feedgen Ali Sherief 2022-08-11 16:56:29+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Regarding BIP322 edge cases - 2025-09-26T14:26:25.361955+00:00 + 2025-09-26T15:35:34.516982+00:00 2022-08-11T16:56:29+00:00 The Bitcoin community is currently exploring a way for the initial signer to delegate to another scriptPubKey in order to improve privacy and compatibility with CoinJoin/Lightning. One suggestion that has been proposed is to use MAST (two Merkle branches) to achieve this. The first branch would contain the original signer's scriptPubKey, while the second branch would contain the delegated signer's scriptPubKey. It appears that all parties involved can make signatures on both the delegating and delegated keys. However, more documentation is needed to fully understand the motivation behind this requirement.In relation to OP_CHECKDATASIG, it has been discovered that this opcode already exists in Bitcoin Cash. However, proponents of BIP322 do not prioritize BCH script compatibility. In order to create an opcode called OP_CHECKDATASIG for the internal purposes of BIP322, a lengthy soft-fork would be required to modify the consensus rules. This raises the question of how Script should verify a single signature on the stack without affecting any inputs or outputs. Several suggestions have been made, including performing key recovery for legacy ECDSA and using specific output scripts to require valid signatures and public keys. Additionally, backward compatibility with Bitcoin Message and the use of opcodes like OP_RESERVED have been discussed, although introducing new opcodes may add unnecessary complexity to the Script.To address these issues, it has been proposed to introduce a hypothetical OP_CHECKDATASIG opcode that can perform ECDSA public key recovery for legacy P2PKH signing. This could be done safely within the BIP. However, in order to ensure compatibility with existing schemes, the opcode would need to be assigned a specific byte, such as OP_CHECKDATASIG. Backward compatibility is crucial, and one possible approach is to use OP_RESERVED to maintain compatibility with "Bitcoin Message". The draft of BIP322 also includes TODO items such as Silent Transactions, limiting eligible opcodes in scriptPubKeys for signing, and delegation to another scriptPubKey. Suggestions have been made, such as placing a NOP at the beginning of the script to activate proof parsing mode and using MAST for delegation.During the discussion on the bitcoin-dev mailing list, user Ali Sherief brought up several TODO items from an older version of the BIP322 draft. These items included addressing the interaction with Silent Transactions, considering whether to introduce an invalid opcode for specific proof types, and finding a solution for delegating to another scriptPubKey. Suggestions were made to limit which opcodes scriptPubKeys can use for signing by placing a NOP at the beginning of the script to activate proof parsing mode. Additionally, a subsection for Silent Transactions could be created to operate using its scriptPubKey. It was also proposed to use MAST with two Merkle branches to specify the original signer's scriptPubKey and delegated signer's scriptPubKey for delegation.BIP322 is still a work in progress, with several TODO items that need to be addressed. The Github issue/PR at https://github.com/bitcoin/bips/pull/1347 has been created to address these items. Ali shared the TODO items from an older version of the draft and suggested limiting the opcodes that scriptPubKeys can sign from, potentially by using a NOP at the beginning of the script. However, it is important to note that an opcode may not be necessary if the program can infer the source of the proof from context. For silent transactions, a suggestion has been made to create a subsection that operates using its scriptPubKey. As for the delegation to another scriptPubKey, the proposal suggests using MAST with two Merkle branches to contain both scriptPubKeys.Overall, the Bitcoin community is actively discussing various solutions to ensure backward compatibility in Bitcoin Scripting language. The lack of certain opcodes, such as OP_CHECKDATASIG, and the need for delegation to another scriptPubKey are being addressed through proposals like MAST and limited opcode usage. However, more documentation and clarification are required to fully understand the motivations behind these requirements and how they will be implemented. diff --git a/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml b/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml index 1bfaf7241d..facf8be17a 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml @@ -2,7 +2,7 @@ 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2025-09-26T14:26:31.766987+00:00 + 2025-09-26T15:35:38.764420+00:00 python-feedgen Billy Tetrud 2022-08-20 15:30:26+00:00 @@ -229,10 +229,11 @@ + 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2025-09-26T14:26:31.767233+00:00 + 2025-09-26T15:35:38.764697+00:00 2022-08-20T15:30:26+00:00 The context discusses various discussions and debates related to the functioning and security of the Bitcoin network. One aspect discussed is the concept of "free lunches" in the network, where some users benefit without contributing, while others bear the costs. It is argued that this is an unhealthy state for the financial system and may not be sustainable in the long term.One suggestion to address this issue is to remove halvings, which are events that reduce the block reward for miners, if they become destructive to the network's security. It is also mentioned that a balanced system with a low annual inflation rate is preferable to any fiat system. While widespread consensus would be ideal, it is acknowledged that a hard fork may be necessary to implement necessary changes.The feasibility of large Bitcoin holders running ASICs to secure their holdings is also discussed. The assumption is made that fees alone may not compensate for low block rewards, and therefore, large holders may mine at a loss to preserve the value of their holdings. However, it is acknowledged that this approach may not work in practice due to trust issues and the potential for betrayal.The concept of the Prisoner's Dilemma is mentioned in relation to cooperation between Bitcoin users. It is highlighted that even though cooperation may be in the best interest of both parties, mistrust and self-interest can lead to suboptimal outcomes.The importance of transaction fees in providing censorship resistance and incentivizing miners to keep the network secure is emphasized. The discussion explores different approaches, such as tying miner revenue to the total value of Bitcoin or relying solely on transaction fees.There are debates about the business model of miners who intend to censor transactions when there is no block reward. It is argued that transaction fees provide censorship resistance, and miners may prioritize high fee transactions to maximize their earnings.The role of the block reward in the functioning of the Bitcoin network is highlighted. The question is raised about whether a perpetual block subsidy should be tied to the total value of Bitcoin or if other methods should be considered to incentivize miners.The assumption of a constant rate for losses in Bitcoin is challenged, and it is argued that losses can occur at a predictable rate. The potential impact of lost coins on the overall value of Bitcoin is discussed.There are also discussions about the subjective nature of defining Bitcoin and the role of leading bodies versus individual autonomy. The importance of the capped supply and predictable issuance curve is mentioned, and tinkering with the protocol is seen as potentially inviting further subversion.The discussion revolves around the predictability of losses in tail emission. While Peter assumes that there is a rate, it is possible for losses to be at a different predictable rate. However, if there exists any fixed central tendency for the rate, tail emission will eventually become non-inflationary. There are two other factors to consider: firstly, if people improve custody faster than 1/(N(t)*P), tail emission can still be inflationary, although this seems unlikely. Secondly, the rate is somewhat stochastic, with "black swan events" like popular wallet losing keys in coding error being possible but not relevant to tail-emission being non-inflationary. However, even such events can be factored into a fixed central tendency over a long enough time period.In the discussion on whether or not to extend block rewards after the current deadline, it is noted that this is only relevant if the community agrees that it is necessary to maintain network security. It is worth noting that a mild inflation can sometimes be compensated by coin loss, which is like a bonus. The assumption of a constant coin loss rate seems unreasonable as people improve their key storage habits over time, leading to a decrease in the rate of coin loss. Additionally, there may be common causes for coin losses that result in heavily correlated losses rather than independent ones.The conversation further explores the potential implications of tail emission on the ability of individuals to access their coins. Todd clarifies that his proposal does not involve re-assigning ownership of coins and therefore does not take away anyone's ability to access their coins. The concern raised by naman naman about the ability to move coins after a long period of inactivity is addressed, with Todd stating that his article on tail emission is focused on maintaining blockchain security without causing inflation.The latest blog post by Peter Todd titled "Surprisingly, Tail Emission Is Not Inflationary" explores the concept of tail emission and its impact on the supply of Bitcoin. Todd argues that tail emission, which is a fixed reward per block that continues indefinitely, can result in a stable monetary supply rather than a monetarily inflationary one. He explains that lost coins contribute to this stability, as they are constantly being lost due to various factors such as deaths, forgotten passphrases, and accidents.The article also discusses the feasibility of implementing tail emission in Bitcoin. While other currencies like Monero have successfully implemented it, adding tail emission to Bitcoin would require convincing a substantial fraction of the Bitcoin community to support the idea. Todd suggests that diff --git a/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml b/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml index 7d5b07b285..706fba470f 100644 --- a/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml +++ b/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml @@ -2,7 +2,7 @@ 2 Combined summary - joinstr: coinjoin implementation using nostr - 2025-09-26T14:26:18.959116+00:00 + 2025-09-26T15:35:30.290173+00:00 python-feedgen alicexbt 2022-09-10 10:17:37+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - joinstr: coinjoin implementation using nostr - 2025-09-26T14:26:18.959275+00:00 + 2025-09-26T15:35:30.290351+00:00 2022-09-10T10:17:37+00:00 A developer named alicexbt has created a proof-of-concept python script to implement coinjoin using nostr, a decentralized network based on cryptographic keypairs. This implementation utilizes several Bitcoin Core wallet and RPC commands and requires the python-nostr library for coordination between peers. The process involves 5 peers coordinating to create, sign, and broadcast a coinjoin transaction. Each step of the process is published as an event using a nostr relay, and users can use multiple relays simultaneously to avoid trusting a single relay. However, there is a vulnerability of denial of service in the implementation, where a malicious user can register multiple outputs with the same secret, causing an ongoing free denial of service attack without attribution or defense.To address this issue, PR #24058 (basic support BIP-322) can be implemented to add proof of ownership. Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, they can send `txid:out` with a message signed with the address, verify using `verifymessage`, and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO. The cryptographic scheme mentioned as an alternative to blind signatures isn't implemented yet, as it requires a NIP and at least one relay using it.The author plans to continue developing coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. Custom relays are supported by Nostr, examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. The author will run a free and open nostr relay for this project and try to fix the DoS issues before a mainnet version is released for the python script (for nerds) and android app (for all users).The email is sent using Proton Mail secure email, and the author invites opinions on the experiment. The email thread is part of the bitcoin-dev mailing list hosted by lists.linuxfoundation.org. The author credits Fiatjaf, Andrew Chow, Jeff Thibault, and existing coinjoin implementations for their contributions. The author also mentions the creation of an Android app for joinstr in the coming week.Overall, the developer's message provides insights into a coinjoin implementation using Nostr, the challenges and limitations of the current system, and potential improvements to make it more secure. The email includes relevant links to GitHub repositories and provides event IDs and a Coinjoin transaction ID for reference. diff --git a/static/bitcoin-dev/Dec_2016/combined_Bitcoin-Currency.xml b/static/bitcoin-dev/Dec_2016/combined_Bitcoin-Currency.xml index 8a79530b46..5ac5551baa 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Bitcoin-Currency.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Bitcoin-Currency.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Currency - 2023-08-01T19:20:33.768324+00:00 + 2025-09-26T15:53:02.673314+00:00 + python-feedgen Henning Kopp 2016-12-14 08:00:51+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Currency - 2023-08-01T19:20:33.768324+00:00 + 2025-09-26T15:53:02.673438+00:00 - In a Bitcoin developer mailing list discussion, Ben West raised a question about whether there exists a specific number or ID that can uniquely determine the value of Bitcoin. Additionally, he inquired if there is any hash, address, or key that could be used to identify and claim ownership of a specific amount of Bitcoin, such as 50BTC or 20BTC.Responding to Ben's query, Henning Kopp suggested that the private key of a user might hold the answer to his question. By obtaining this private key, one could spend their Bitcoin funds and provide proof of ownership. To further expand on the topic, Henning recommended a blog post that offers insights into how the Bitcoin protocol functions. He emphasized that the usefulness of the blog post would depend on Ben's level of understanding regarding the subject matter.Henning concluded his response by sharing his contact information from Ulm University in Germany, where he works at the Institute of Distributed Systems.In a separate forum post, another user sought clarification on whether there is a unique identifier for Bitcoin value (BTC) or a method to identify specific amounts of BTC using a hash, address, or key. Essentially, the user was interested in knowing if it is possible to establish ownership of a particular quantity of BTC. 2016-12-14T08:00:51+00:00 + In a Bitcoin developer mailing list discussion, Ben West raised a question about whether there exists a specific number or ID that can uniquely determine the value of Bitcoin. Additionally, he inquired if there is any hash, address, or key that could be used to identify and claim ownership of a specific amount of Bitcoin, such as 50BTC or 20BTC.Responding to Ben's query, Henning Kopp suggested that the private key of a user might hold the answer to his question. By obtaining this private key, one could spend their Bitcoin funds and provide proof of ownership. To further expand on the topic, Henning recommended a blog post that offers insights into how the Bitcoin protocol functions. He emphasized that the usefulness of the blog post would depend on Ben's level of understanding regarding the subject matter.Henning concluded his response by sharing his contact information from Ulm University in Germany, where he works at the Institute of Distributed Systems.In a separate forum post, another user sought clarification on whether there is a unique identifier for Bitcoin value (BTC) or a method to identify specific amounts of BTC using a hash, address, or key. Essentially, the user was interested in knowing if it is possible to establish ownership of a particular quantity of BTC. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2016/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml b/static/bitcoin-dev/Dec_2016/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml index a5c91bcc7c..38ffdba9f3 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Forcenet: an experimental network with a new header format - 2023-08-01T19:17:12.881545+00:00 + 2025-09-26T15:53:13.243130+00:00 + python-feedgen Matt Corallo 2017-01-28 17:14:02+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Forcenet: an experimental network with a new header format - 2023-08-01T19:17:12.882543+00:00 + 2025-09-26T15:53:13.243275+00:00 - The Bitcoin-dev mailing list has been discussing proposals for changes to the Bitcoin protocol. Some of the proposed changes include removing the block size limit, limiting the creation of unspent transaction outputs (UTXOs) and encouraging their spending, and implementing a smoother halving cycle for block rewards. There are also proposals for a new coinbase transaction format and a Merkle sum tree for fraud-proofing.Matt Corallo suggests minimizing header size, having only one merkle tree for transactions, and avoiding variable-length header fields. He also discusses light wallet functionality without an upgrade and the Stratum protocol. Another proposal titled "Client Side Block Filtering" suggests an alternative method of block downloading that allows clients to filter blocks based on specific criteria.Johnson Lau introduces a second version of forcenet with experimental features, including anti-tx-replay and block sighashlimit. The author of the context also creates a second version of forcenet with new experimental features, such as a new header format and anti-tx-replay. There is a discussion about the concept of a sum tree and softfork in Bitcoin, as well as the issue with redefining nSigOp in a sum tree and the proposal to combine the two costs into a unified cost.In December 2016, a discussion took place regarding the use of a timestamp beyond 4 bytes. Luke Dashjr proposed stealing a few bits from the tx nVersion through a softfork as a solution. There were also discussions about the implementation of a new merkle algorithm using a sum tree, communication with legacy nodes, and the possibility of enabling easier soft forks through a bridge node. Suggestions were made to keep hashing to a minimum and to consider an 8-byte timestamp due to the approaching year 2106.Overall, the Bitcoin-dev mailing list concludes that some proposals may not be essential for the hard fork and could be added later through a soft fork. Forcenet, an experimental network, was created to demonstrate a new header format, but some aspects have not yet been implemented. Codes for testing can be found on Github, and joining the network is possible by running "bitcoind --forcenet" and connecting to the node running at 8333.info with the default port. 2017-01-28T17:14:02+00:00 + The Bitcoin-dev mailing list has been discussing proposals for changes to the Bitcoin protocol. Some of the proposed changes include removing the block size limit, limiting the creation of unspent transaction outputs (UTXOs) and encouraging their spending, and implementing a smoother halving cycle for block rewards. There are also proposals for a new coinbase transaction format and a Merkle sum tree for fraud-proofing.Matt Corallo suggests minimizing header size, having only one merkle tree for transactions, and avoiding variable-length header fields. He also discusses light wallet functionality without an upgrade and the Stratum protocol. Another proposal titled "Client Side Block Filtering" suggests an alternative method of block downloading that allows clients to filter blocks based on specific criteria.Johnson Lau introduces a second version of forcenet with experimental features, including anti-tx-replay and block sighashlimit. The author of the context also creates a second version of forcenet with new experimental features, such as a new header format and anti-tx-replay. There is a discussion about the concept of a sum tree and softfork in Bitcoin, as well as the issue with redefining nSigOp in a sum tree and the proposal to combine the two costs into a unified cost.In December 2016, a discussion took place regarding the use of a timestamp beyond 4 bytes. Luke Dashjr proposed stealing a few bits from the tx nVersion through a softfork as a solution. There were also discussions about the implementation of a new merkle algorithm using a sum tree, communication with legacy nodes, and the possibility of enabling easier soft forks through a bridge node. Suggestions were made to keep hashing to a minimum and to consider an 8-byte timestamp due to the approaching year 2106.Overall, the Bitcoin-dev mailing list concludes that some proposals may not be essential for the hard fork and could be added later through a soft fork. Forcenet, an experimental network, was created to demonstrate a new header format, but some aspects have not yet been implemented. Codes for testing can be found on Github, and joining the network is possible by running "bitcoind --forcenet" and connecting to the node running at 8333.info with the default port. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2016/combined_Managing-block-size-the-same-way-we-do-difficulty-aka-Block75-.xml b/static/bitcoin-dev/Dec_2016/combined_Managing-block-size-the-same-way-we-do-difficulty-aka-Block75-.xml index 5c78385679..dd5e11030e 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Managing-block-size-the-same-way-we-do-difficulty-aka-Block75-.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Managing-block-size-the-same-way-we-do-difficulty-aka-Block75-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Managing block size the same way we do difficulty (aka Block75) - 2023-08-01T19:20:22.399312+00:00 + 2025-09-26T15:53:04.787491+00:00 + python-feedgen Tom Harding 2016-12-19 01:42:38+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - Managing block size the same way we do difficulty (aka Block75) - 2023-08-01T19:20:22.400313+00:00 + 2025-09-26T15:53:04.787655+00:00 - In a discussion on the bitcoin-dev mailing list, participants were discussing the Block75 proposal, which allows miners to determine the maximum block size. One participant expressed concern about the linear growth proposed by Block75 and the potential for miners to manipulate their block content. James argued that allowing miners to choose the block size would incentivize them to include legitimate transactions while keeping the block small enough to propagate effectively.Another user disagreed with Andrew Johnson's assertion that an attack on the proposal would be easily detectable. They explained that intentionally orphaning a block would only make sense if 51% of the hash rate was intentionally orphaning it. The conversation also touched on the possibility of miners creating transactions to themselves and not broadcasting them to the network. However, this tactic is easily detectable by other miners who may intentionally orphan blocks that contain unknown transactions.The discussion also delved into the impact of Block75 on transaction fees. James Hilliard explained that there will always be transactions available to mine, and users can stop miners from continuously increasing block size by not sending transactions. James expressed concern that miners will increase block sizes to maximize fees, but it was clarified that Block75 is not exponential scaling and the maximum increase in the first year would be 7x.On December 11, 2016, an email thread discussed the proposed Block75 solution for scaling Bitcoin. The author argued that Block75 is not exponential scaling and would only increase by a maximum of 7x in the first year, followed by slower increases in subsequent years. Critics raised concerns about system instability and block propagation time due to dynamically increasing the maximum block size based on transaction volume.Bram Cohen compared the Block75 approach to Bitcoin Unlimited, highlighting concerns about transaction fees. However, Block75 aims to maintain transaction fees and a fee market, albeit at lower levels than current fees. The proposal offers a way to manage block size automatically without human intervention.In another discussion, t. khan introduced the concept of Block75, which focuses on keeping blocks 75% full instead of enforcing a maximum block size. Some members argued that this effectively removes the block size limit and fails to differentiate between genuine transactions and low-value spam attacks. Concerns were raised about miners imposing their own cap on block size and potential forks.Daniele Pinna asked about objective measures to estimate the probability of orphaned blocks based on network bandwidth and block size. Pieter Wuille responded by stating that models can predict orphan rates based on certain factors but noted that topology cannot be controlled.The Block75 proposal suggests adjusting the maximum block size every two weeks based on transaction volume, aiming to keep blocks at 75% total capacity over each two-week period. Concerns were raised about block propagation time, potential miner manipulation, and the need for a consensus rule on the maximum block size. Despite these concerns, Block75 provides an automated and scalable solution to manage block size. 2016-12-19T01:42:38+00:00 + In a discussion on the bitcoin-dev mailing list, participants were discussing the Block75 proposal, which allows miners to determine the maximum block size. One participant expressed concern about the linear growth proposed by Block75 and the potential for miners to manipulate their block content. James argued that allowing miners to choose the block size would incentivize them to include legitimate transactions while keeping the block small enough to propagate effectively.Another user disagreed with Andrew Johnson's assertion that an attack on the proposal would be easily detectable. They explained that intentionally orphaning a block would only make sense if 51% of the hash rate was intentionally orphaning it. The conversation also touched on the possibility of miners creating transactions to themselves and not broadcasting them to the network. However, this tactic is easily detectable by other miners who may intentionally orphan blocks that contain unknown transactions.The discussion also delved into the impact of Block75 on transaction fees. James Hilliard explained that there will always be transactions available to mine, and users can stop miners from continuously increasing block size by not sending transactions. James expressed concern that miners will increase block sizes to maximize fees, but it was clarified that Block75 is not exponential scaling and the maximum increase in the first year would be 7x.On December 11, 2016, an email thread discussed the proposed Block75 solution for scaling Bitcoin. The author argued that Block75 is not exponential scaling and would only increase by a maximum of 7x in the first year, followed by slower increases in subsequent years. Critics raised concerns about system instability and block propagation time due to dynamically increasing the maximum block size based on transaction volume.Bram Cohen compared the Block75 approach to Bitcoin Unlimited, highlighting concerns about transaction fees. However, Block75 aims to maintain transaction fees and a fee market, albeit at lower levels than current fees. The proposal offers a way to manage block size automatically without human intervention.In another discussion, t. khan introduced the concept of Block75, which focuses on keeping blocks 75% full instead of enforcing a maximum block size. Some members argued that this effectively removes the block size limit and fails to differentiate between genuine transactions and low-value spam attacks. Concerns were raised about miners imposing their own cap on block size and potential forks.Daniele Pinna asked about objective measures to estimate the probability of orphaned blocks based on network bandwidth and block size. Pieter Wuille responded by stating that models can predict orphan rates based on certain factors but noted that topology cannot be controlled.The Block75 proposal suggests adjusting the maximum block size every two weeks based on transaction volume, aiming to keep blocks at 75% total capacity over each two-week period. Concerns were raised about block propagation time, potential miner manipulation, and the need for a consensus rule on the maximum block size. Despite these concerns, Block75 provides an automated and scalable solution to manage block size. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2016/combined_Multisig-with-hashes-instead-of-pubkeys.xml b/static/bitcoin-dev/Dec_2016/combined_Multisig-with-hashes-instead-of-pubkeys.xml index 0283c58fc2..4421f15c15 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Multisig-with-hashes-instead-of-pubkeys.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Multisig-with-hashes-instead-of-pubkeys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Multisig with hashes instead of pubkeys - 2023-08-01T19:21:41.166019+00:00 + 2025-09-26T15:53:09.014644+00:00 + python-feedgen Matthew Roberts 2016-12-23 18:21:43+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Multisig with hashes instead of pubkeys - 2023-08-01T19:21:41.166019+00:00 + 2025-09-26T15:53:09.014802+00:00 - In the field of cryptography, Lamport Signatures offer a method to sign a message solely using hash functions. This approach involves exchanging a table of hashes before signing a message and then revealing the corresponding "secrets" behind these hashes. By selectively masking the bits of the message hash, one can effectively sign specific portions of the message. Notably, Lamport Signatures are both elegant and quantum secure.However, relying solely on hashes in this scheme presents a vulnerability, as anyone could obtain these values and potentially double spend the original transaction by redirecting it to a different destination. To address this concern, a similar smart contract algorithm called "atomic cross-chain contracts" utilizes hash values for protocol-based coin swapping across blockchains while employing ECDSA public keys to prevent double-spending.In the case of Bitcoin multi-signature transactions, the use of hash values is viable, but additional protection is required to safeguard against attackers on the network. For instance, including an ECDSA public key alongside the hash values would enhance security. Nonetheless, if one desires to incorporate Lamport Signatures into their consensus system, it is necessary for the system to comprehend Lamport signature operations within the "scriptPubKey." The specific use-case for this integration remains unspecified.Addressing a user named Andrew's query regarding a scriptPubKey for conducting multisig with only participant hashes, it was pointed out that the proposed script had several issues. Firstly, performing two OP_SWAP operations consecutively would simply revert to the original state. Moreover, all the hashes generated in the script ended up hashing the same key, making it susceptible to being spent by anyone on the network. Instead, it was suggested that utilizing P2SH (Pay-to-Script-Hash) scripts would offer better security by preventing the exposure of public keys until spending occurs.To further assist Andrew, the email provided a resource link to learn more about opcodes and simulators. The poster also requested either a confirmed solution or a link to a worked-out script for the scriptSig, which is not included in the provided information. 2016-12-23T18:21:43+00:00 + In the field of cryptography, Lamport Signatures offer a method to sign a message solely using hash functions. This approach involves exchanging a table of hashes before signing a message and then revealing the corresponding "secrets" behind these hashes. By selectively masking the bits of the message hash, one can effectively sign specific portions of the message. Notably, Lamport Signatures are both elegant and quantum secure.However, relying solely on hashes in this scheme presents a vulnerability, as anyone could obtain these values and potentially double spend the original transaction by redirecting it to a different destination. To address this concern, a similar smart contract algorithm called "atomic cross-chain contracts" utilizes hash values for protocol-based coin swapping across blockchains while employing ECDSA public keys to prevent double-spending.In the case of Bitcoin multi-signature transactions, the use of hash values is viable, but additional protection is required to safeguard against attackers on the network. For instance, including an ECDSA public key alongside the hash values would enhance security. Nonetheless, if one desires to incorporate Lamport Signatures into their consensus system, it is necessary for the system to comprehend Lamport signature operations within the "scriptPubKey." The specific use-case for this integration remains unspecified.Addressing a user named Andrew's query regarding a scriptPubKey for conducting multisig with only participant hashes, it was pointed out that the proposed script had several issues. Firstly, performing two OP_SWAP operations consecutively would simply revert to the original state. Moreover, all the hashes generated in the script ended up hashing the same key, making it susceptible to being spent by anyone on the network. Instead, it was suggested that utilizing P2SH (Pay-to-Script-Hash) scripts would offer better security by preventing the exposure of public keys until spending occurs.To further assist Andrew, the email provided a resource link to learn more about opcodes and simulators. The poster also requested either a confirmed solution or a link to a worked-out script for the scriptSig, which is not included in the provided information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2016/combined_New-BIP-Hardfork-warning-system.xml b/static/bitcoin-dev/Dec_2016/combined_New-BIP-Hardfork-warning-system.xml index 95ef974d22..d9e520db86 100644 --- a/static/bitcoin-dev/Dec_2016/combined_New-BIP-Hardfork-warning-system.xml +++ b/static/bitcoin-dev/Dec_2016/combined_New-BIP-Hardfork-warning-system.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP: Hardfork warning system - 2023-08-01T19:15:55.469736+00:00 + 2025-09-26T15:53:06.901884+00:00 + python-feedgen Jorge Timón 2016-12-02 06:35:36+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - New BIP: Hardfork warning system - 2023-08-01T19:15:55.469736+00:00 + 2025-09-26T15:53:06.902060+00:00 - On December 2, 2016, Jorge Timón proposed a new Bitcoin Improvement Proposal (BIP) that aims to warn users of a hard fork when a block is invalid. The proposal suggests implementing a soft fork that would hold back at the best-common block between the best-valid chain and the invalid chain, forcing the user to decide whether to reject the invalid chain permanently or upgrade to a version that understands the chain as valid. The proposal also discusses the use of a prohibited bit to signal a soft-hardfork while distinguishing it from a regular hardfork. Nodes implementing this BIP would view it as a simple hardfork but intentionally provide equivalent behavior as older nodes that see it as a soft-hardfork. This proposal could potentially make it easier to resist an un-consented-to hardfork and may eliminate the need for a soft-hardfork design in the future.In a separate discussion on December 1, 2016, Johnson Lau emphasized the necessity for any Bitcoin implementation supporting a softfork to implement a hardfork warning system. Lau argued that if a generalized block header chain with non-trivial total proof-of-work is emerging and not considered a valid blockchain, a hardfork with unknown rules may be occurring. Lau proposed that wallet implementations issue warnings to users and stop processing transactions until further instructions are given. Mining implementations should also issue warnings to operators and may either stop mining or ignore the hardfork with unknown rules. Light nodes, such as wallet implementations, should observe hardfork notification bits in block headers and issue warnings to their users if any of the bits are set. Lau also noted that various types of hardforks can be detected by the warning system, including changes to the Merkle root hash field, block content validation rules, and the introduction of secondary proof-of-work.Johnson Lau's proposal involves changing consensus rules related to block nVersion and creating a concept of a generalized block header to implement a hardfork warning system for both full nodes and light nodes. The hardfork warning system is responsible for informing users that a hardfork may be happening and prompting them for further instructions. However, it does not guarantee the success of the hardfork or prevent the creation of two permanent incompatible forks. The proposal provides specifications for a block nVersion softfork and the validation of a generalized block header. It also outlines the terms used in the proposal and clarifies the limitations of the warning system.Overall, these proposals highlight the ongoing discussions within the Bitcoin community regarding the use of softforks and hardforks to introduce new features or address consensus disagreements. The implementation of a hardfork warning system aims to provide users with the necessary information and prompts to navigate potential hardfork situations effectively. 2016-12-02T06:35:36+00:00 + On December 2, 2016, Jorge Timón proposed a new Bitcoin Improvement Proposal (BIP) that aims to warn users of a hard fork when a block is invalid. The proposal suggests implementing a soft fork that would hold back at the best-common block between the best-valid chain and the invalid chain, forcing the user to decide whether to reject the invalid chain permanently or upgrade to a version that understands the chain as valid. The proposal also discusses the use of a prohibited bit to signal a soft-hardfork while distinguishing it from a regular hardfork. Nodes implementing this BIP would view it as a simple hardfork but intentionally provide equivalent behavior as older nodes that see it as a soft-hardfork. This proposal could potentially make it easier to resist an un-consented-to hardfork and may eliminate the need for a soft-hardfork design in the future.In a separate discussion on December 1, 2016, Johnson Lau emphasized the necessity for any Bitcoin implementation supporting a softfork to implement a hardfork warning system. Lau argued that if a generalized block header chain with non-trivial total proof-of-work is emerging and not considered a valid blockchain, a hardfork with unknown rules may be occurring. Lau proposed that wallet implementations issue warnings to users and stop processing transactions until further instructions are given. Mining implementations should also issue warnings to operators and may either stop mining or ignore the hardfork with unknown rules. Light nodes, such as wallet implementations, should observe hardfork notification bits in block headers and issue warnings to their users if any of the bits are set. Lau also noted that various types of hardforks can be detected by the warning system, including changes to the Merkle root hash field, block content validation rules, and the introduction of secondary proof-of-work.Johnson Lau's proposal involves changing consensus rules related to block nVersion and creating a concept of a generalized block header to implement a hardfork warning system for both full nodes and light nodes. The hardfork warning system is responsible for informing users that a hardfork may be happening and prompting them for further instructions. However, it does not guarantee the success of the hardfork or prevent the creation of two permanent incompatible forks. The proposal provides specifications for a block nVersion softfork and the validation of a generalized block header. It also outlines the terms used in the proposal and clarifies the limitations of the warning system.Overall, these proposals highlight the ongoing discussions within the Bitcoin community regarding the use of softforks and hardforks to introduce new features or address consensus disagreements. The implementation of a hardfork warning system aims to provide users with the necessary information and prompts to navigate potential hardfork situations effectively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2016/combined_Planned-Obsolescence.xml b/static/bitcoin-dev/Dec_2016/combined_Planned-Obsolescence.xml index 82c22133a5..765335c711 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Planned-Obsolescence.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Planned-Obsolescence.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Planned Obsolescence - 2023-08-01T19:21:04.077225+00:00 + 2025-09-26T15:53:00.562333+00:00 + python-feedgen Btc Drak 2016-12-19 06:39:46+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Planned Obsolescence - 2023-08-01T19:21:04.077225+00:00 + 2025-09-26T15:53:00.562500+00:00 - A Bitcoin developer, Matt Corallo, is urging people to report bugs to the Bitcoin Github repository, emphasizing that if bugs aren't reported, they won't get fixed. One user, Alice Wonder, almost didn't update to version 0.13.0 due to Python errors in the test suite. She stated that she will only upgrade when the test suite works in her environment and urged others to report bugs as well. The lack of Python 3 dependency on older CentOS builds could be a reason for node operator's lack of client upgrades.Juan Garavaglia expressed concern over the significant number of node operators who do not update their clients. He mentioned that he almost did not update to version 0.13.0 due to failing python errors in the test suite, and when version 0.13.1 was released with new python errors, he decided not to upgrade at all. Garavaglia will only upgrade when the test suite works in his standard environment (CentOS) and will not run clients that have not passed the test suite.The Bitcoin community is discussing the issue of developer centralization and finding the right balance between software upgrades. Concerns were raised about nodes not applying patches, making them vulnerable to exploits, and older nodes becoming obsolete and incompatible with new upgrades, leading to network fragmentation. Planned obsolescence in new versions of Bitcoin Core node was suggested to avoid fragmentation, but others felt that this may not be the best solution as anti-features can easily be removed. Instead, users should be left to determine when to upgrade, although security updates should be encouraged. It is recognized that developers have limited resources and are unlikely to give support for older versions.The difficulty of encouraging users to upgrade their node versions to avoid compatibility issues and security vulnerabilities is being discussed. Suggestions include implementing a message system to notify users of available updates and potential risks, automatically distributing patches and updates, and introducing planned obsolescence in each new version of Bitcoin Core. However, concerns were raised about the effectiveness of these approaches and the potential for anti-features to be removed. A simpler solution would be to stop supporting older versions, as developers have limited resources and rarely fix bugs for outdated software.Juan Garavaglia has proposed implementing planned obsolescence in each new version of Bitcoin Core node software to avoid fragmentation and simplify developers' jobs. The suggestion recommends that after a new version is released, it remains valid for approximately one year before becoming obsolete and incompatible with the network. If a node does not upgrade, it will stop working instead of participating with an outdated protocol version. However, some users may remove anti-features from free software. A simpler solution, such as stopping maintenance and support for older versions, has been suggested in response to this proposal.The size of the Bitcoin network in terms of full nodes is decreasing rapidly, raising concerns about its decentralization. The lack of incentive for people to run full nodes and upgrade their clients is a major issue that has not been discussed enough. It is noted that over 30% of nodes running Bitcoin Core are using versions older than 0.13.0, indicating that many node operators do not upgrade. Introducing planned obsolescence in each new version and addressing the lack of incentives may help solve these issues.According to statistics, the majority of Bitcoin running node versions are older than 0.13.1, indicating that many node operators do not upgrade their clients. Newer versions require the same or fewer hardware resources to run compared to older versions, and introducing planned obsolescence in each new version is worth considering to avoid fragmentation and simplify the developer's job. If a node does not upgrade, it will stop working instead of participating with an outdated protocol version. 2016-12-19T06:39:46+00:00 + A Bitcoin developer, Matt Corallo, is urging people to report bugs to the Bitcoin Github repository, emphasizing that if bugs aren't reported, they won't get fixed. One user, Alice Wonder, almost didn't update to version 0.13.0 due to Python errors in the test suite. She stated that she will only upgrade when the test suite works in her environment and urged others to report bugs as well. The lack of Python 3 dependency on older CentOS builds could be a reason for node operator's lack of client upgrades.Juan Garavaglia expressed concern over the significant number of node operators who do not update their clients. He mentioned that he almost did not update to version 0.13.0 due to failing python errors in the test suite, and when version 0.13.1 was released with new python errors, he decided not to upgrade at all. Garavaglia will only upgrade when the test suite works in his standard environment (CentOS) and will not run clients that have not passed the test suite.The Bitcoin community is discussing the issue of developer centralization and finding the right balance between software upgrades. Concerns were raised about nodes not applying patches, making them vulnerable to exploits, and older nodes becoming obsolete and incompatible with new upgrades, leading to network fragmentation. Planned obsolescence in new versions of Bitcoin Core node was suggested to avoid fragmentation, but others felt that this may not be the best solution as anti-features can easily be removed. Instead, users should be left to determine when to upgrade, although security updates should be encouraged. It is recognized that developers have limited resources and are unlikely to give support for older versions.The difficulty of encouraging users to upgrade their node versions to avoid compatibility issues and security vulnerabilities is being discussed. Suggestions include implementing a message system to notify users of available updates and potential risks, automatically distributing patches and updates, and introducing planned obsolescence in each new version of Bitcoin Core. However, concerns were raised about the effectiveness of these approaches and the potential for anti-features to be removed. A simpler solution would be to stop supporting older versions, as developers have limited resources and rarely fix bugs for outdated software.Juan Garavaglia has proposed implementing planned obsolescence in each new version of Bitcoin Core node software to avoid fragmentation and simplify developers' jobs. The suggestion recommends that after a new version is released, it remains valid for approximately one year before becoming obsolete and incompatible with the network. If a node does not upgrade, it will stop working instead of participating with an outdated protocol version. However, some users may remove anti-features from free software. A simpler solution, such as stopping maintenance and support for older versions, has been suggested in response to this proposal.The size of the Bitcoin network in terms of full nodes is decreasing rapidly, raising concerns about its decentralization. The lack of incentive for people to run full nodes and upgrade their clients is a major issue that has not been discussed enough. It is noted that over 30% of nodes running Bitcoin Core are using versions older than 0.13.0, indicating that many node operators do not upgrade. Introducing planned obsolescence in each new version and addressing the lack of incentives may help solve these issues.According to statistics, the majority of Bitcoin running node versions are older than 0.13.1, indicating that many node operators do not upgrade their clients. Newer versions require the same or fewer hardware resources to run compared to older versions, and introducing planned obsolescence in each new version is worth considering to avoid fragmentation and simplify the developer's job. If a node does not upgrade, it will stop working instead of participating with an outdated protocol version. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2016/combined_Python-test-suite-failures-was-Re-Planned-Obsolescence-.xml b/static/bitcoin-dev/Dec_2016/combined_Python-test-suite-failures-was-Re-Planned-Obsolescence-.xml index 3d85be46fc..7939122145 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Python-test-suite-failures-was-Re-Planned-Obsolescence-.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Python-test-suite-failures-was-Re-Planned-Obsolescence-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Python test suite failures (was Re: Planned Obsolescence) - 2023-08-01T19:21:22.642448+00:00 + 2025-09-26T15:53:11.127328+00:00 + python-feedgen Marco Falke 2016-12-21 18:33:14+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Python test suite failures (was Re: Planned Obsolescence) - 2023-08-01T19:21:22.643455+00:00 + 2025-09-26T15:53:11.127475+00:00 - The error message in question is from version 0.13.1 of Bitcoin, specifically related to the "bitcoin-util-test.py" file. The traceback indicates that the problem lies within the "bctest.py" file, where a line of code attempting to read output data from a file is causing a FileNotFoundError due to the specified file not being found in the directory. This issue was previously known on the master branch. Users encountering similar issues with the current 0.13.2 release candidate are advised to report it on the Bitcoin GitHub issues page, along with their CentOS version.In a thread on bitcoin-dev, Alice Wonder expressed her hesitation to update to version 0.13.0 of Bitcoin due to failing tests caused by Python errors. She mentioned that these issues were addressed on bitcointalk, but new Python errors arose in version 0.13.1, leading her to abandon the update entirely. When asked for more details about the encountered issues, Alice explained that the main cause was the LANG environment variable and had to set it to "en_US.utf8" before running the test suite for version 0.13.0. However, she noted that this issue was resolved in version 0.13.1. The errors in version 0.13.1 occurred during the execution of the "bitcoin-util-test.py" file, resulting in a traceback error. The error message indicated that the test failed because it couldn't find the file "./test/data/blanktx.json", resulting in an Error 1. Alice also mentioned that she builds in a clean chroot build environment to avoid linking to non-standard libraries and that the LANG environment variable typically doesn't affect software compilation. Despite these challenges, Alice reported that version 0.13.0 worked fine once the LANG variable was set to "en_US.utf8".In a post on the bitcoin-dev mailing list, Alice Wonder expressed her frustration with testing errors in Bitcoin Core updates. She nearly decided against updating to version 0.13.0 due to Python errors in the test suite, which were eventually resolved by following instructions on bitcointalk. However, she encountered new Python errors in version 0.13.1 and chose not to update until the test suite functions properly in her CentOS environment. Douglas Roark requested more information about these issues and offered assistance, suggesting that posting an issue on Github would be beneficial. 2016-12-21T18:33:14+00:00 + The error message in question is from version 0.13.1 of Bitcoin, specifically related to the "bitcoin-util-test.py" file. The traceback indicates that the problem lies within the "bctest.py" file, where a line of code attempting to read output data from a file is causing a FileNotFoundError due to the specified file not being found in the directory. This issue was previously known on the master branch. Users encountering similar issues with the current 0.13.2 release candidate are advised to report it on the Bitcoin GitHub issues page, along with their CentOS version.In a thread on bitcoin-dev, Alice Wonder expressed her hesitation to update to version 0.13.0 of Bitcoin due to failing tests caused by Python errors. She mentioned that these issues were addressed on bitcointalk, but new Python errors arose in version 0.13.1, leading her to abandon the update entirely. When asked for more details about the encountered issues, Alice explained that the main cause was the LANG environment variable and had to set it to "en_US.utf8" before running the test suite for version 0.13.0. However, she noted that this issue was resolved in version 0.13.1. The errors in version 0.13.1 occurred during the execution of the "bitcoin-util-test.py" file, resulting in a traceback error. The error message indicated that the test failed because it couldn't find the file "./test/data/blanktx.json", resulting in an Error 1. Alice also mentioned that she builds in a clean chroot build environment to avoid linking to non-standard libraries and that the LANG environment variable typically doesn't affect software compilation. Despite these challenges, Alice reported that version 0.13.0 worked fine once the LANG variable was set to "en_US.utf8".In a post on the bitcoin-dev mailing list, Alice Wonder expressed her frustration with testing errors in Bitcoin Core updates. She nearly decided against updating to version 0.13.0 due to Python errors in the test suite, which were eventually resolved by following instructions on bitcointalk. However, she encountered new Python errors in version 0.13.1 and chose not to update until the test suite functions properly in her CentOS environment. Douglas Roark requested more information about these issues and offered assistance, suggesting that posting an issue on Github would be beneficial. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_-Compressed-headers-stream.xml b/static/bitcoin-dev/Dec_2017/combined_-Compressed-headers-stream.xml index ad3d4b2424..4a84fa8adc 100644 --- a/static/bitcoin-dev/Dec_2017/combined_-Compressed-headers-stream.xml +++ b/static/bitcoin-dev/Dec_2017/combined_-Compressed-headers-stream.xml @@ -1,47 +1,75 @@ - + 2 - Combined summary - "Compressed" headers stream - 2023-08-01T21:30:19.625066+00:00 - - Gregory Maxwell 2017-12-13 00:12:45+00:00 - - - Gregory Maxwell 2017-12-13 00:01:32+00:00 - - - Suhas Daftuar 2017-12-12 21:07:11+00:00 - - - Gregory Maxwell 2017-12-11 23:11:24+00:00 - - - Tier Nolan 2017-12-11 22:41:50+00:00 - - - Jim Posen 2017-12-11 21:56:08+00:00 - - - Gregory Maxwell 2017-12-11 21:04:01+00:00 - - - Jim Posen 2017-12-11 20:40:00+00:00 - - - Peter Todd 2017-09-04 14:10:17+00:00 - - - Greg Sanders 2017-08-28 16:26:48+00:00 - - - Riccardo Casatta 2017-08-28 16:25:01+00:00 - - - Greg Sanders 2017-08-28 16:13:11+00:00 - - - Riccardo Casatta 2017-08-28 15:50:23+00:00 - + Combined summary - "Compressed" headers stream + 2025-09-26T15:52:14.420198+00:00 + python-feedgen + + + Riccardo Casatta + 2017-08-28T15:50:00.000Z + + + Greg Sanders + 2017-08-28T16:13:00.000Z + + + Riccardo Casatta + 2017-08-28T16:25:00.000Z + + + Greg Sanders + 2017-08-28T16:26:00.000Z + + + [bitcoin-dev] Fwd: " Gregory Maxwell + 2017-08-28T17:12:00.000Z + + + Kalle Rosenbaum + 2017-08-28T17:54:00.000Z + + + Peter Todd + 2017-09-04T14:06:00.000Z + + + Peter Todd + 2017-09-04T14:10:00.000Z + + + [bitcoin-dev] "Compressed" headers stream Jim Posen + 2017-12-11T20:40:00.000Z + + + Gregory Maxwell + 2017-12-11T21:04:00.000Z + + + Jim Posen + 2017-12-11T21:56:00.000Z + + + Tier Nolan + 2017-12-11T22:41:00.000Z + + + Gregory Maxwell + 2017-12-11T23:11:00.000Z + + + Suhas Daftuar + 2017-12-12T21:07:00.000Z + + + Gregory Maxwell + 2017-12-13T00:01:00.000Z + + + Gregory Maxwell + 2017-12-13T00:12:00.000Z + + @@ -55,13 +83,13 @@ - python-feedgen + 2 - Combined summary - "Compressed" headers stream - 2023-08-01T21:30:19.625066+00:00 + Combined summary - "Compressed" headers stream + 2025-09-26T15:52:14.421976+00:00 - In a recent discussion among Bitcoin developers, Suhas Daftuar and Gregory Maxwell proposed the introduction of a new 'cmpctheaders'/'getcmpcthdrs' message pair for syncing, while keeping the existing 'headers'/'getheaders' messages unchanged. The idea is to never use 'getheaders' messages when communicating with upgraded peers and only use 'headers' messages for potentially announcing new blocks. Peers would fetch headers based on a weak heuristic where they fetch first from those with the tip at the highest difficulty and then work backwards. This proposal also mentions the possibility of changing the interface. [source]Another topic of discussion among Bitcoin developers is the inclusion of nBits in p2p messages without requiring the consensus-correct calculation of nBits. The purpose is to calculate the work on a chain as an anti-DoS measure. It is suggested that nBits could be included in any messages where the value is ambiguous, such as with the first header in a message and whenever it changes from the previous header's nBits. The serialization of existing messages should not be changed, so a new 'cmpctheaders'/'getcmpcthdrs' message pair could be introduced for syncing using this new message type. When communicating with upgraded peers, 'getheaders' messages would never be used, and only 'headers' messages would be used for potentially announcing new blocks. The splitting off of headers chain-sync functionality to a new message pair is seen as a nice side-effect benefit in the long run. [source]Tier Nolan shared a method called "high hash highway" in a Bitcoin-dev discussion, which allows compact proofs of total Proof-of-Work (POW). However, it was deemed off-topic as it provides no security without additional consensus enforced commitments. [source]Jim Posen proposed omitting nBits entirely in Bitcoin headers to save an extra 4 bytes. However, this could lead to more complexity in the validation code. As a compromise, Posen suggested using a one-byte flag to indicate the difference since the last header and stealing bits from the exponent to indicate mode. This approach would save three of the four bytes. Posen also proposed parallel header fetching, where nodes could request the lowest N hashes between two heights on the main chain and receive pairs of {height, header} for the N headers with the lowest hash in the specified range. [source]There is a proposal to reduce the bandwidth needed for Bitcoin header messages by removing the nBits field, which contains difficulty information. The proposal has received criticism for being too dependent on specific validation rules of the Bitcoin protocol. However, supporters argue that omitting nBits saves bytes and is worth the extra complexity in validation code. The discussion also covers the need to encode leading bits of prev, which are used as an extra nonce for miners. While some altcoins have already changed their header structures, making the proposed change possibly incompatible, supporters argue that it would be worth it to competitively advance Bitcoin. Additionally, the possibility of parallel header fetching to optimize header download is discussed. [source]In a Bitcoin-dev mailing list discussion, Greg Sanders raised a question about the use-case of timestamping in Bitcoin. Peter Todd responded by explaining that timestamping can be more vulnerable to malicious miners than financial applications due to the lack of a financial feedback loop. He also noted that timestamping is a non-financial piggy-back application that does not directly interact with the Bitcoin economy beyond a trivial number of timestamp transactions. [source]Riccardo Casatta proposed an optimization for transmitting Bitcoin block headers in a recent email on the Bitcoin-dev mailing list. The proposal suggests that after the first header, subsequent headers need not transmit the previous hash as the receiver can compute it by double hashing the previous header. This optimization could save about 40% bandwidth in a long stream of headers. Casatta believes this optimization could be particularly useful in instances where full node security isn't feasible, such as when dealing with private databases that require timestamping. He also suggests using fixed position chunks in an HTTP API to leverage HTTP caching and speed up synchronization for new clients. [source]In the Bitcoin-dev email thread, Jim Posen expressed his dislike of making the net header encoding dependent on specific header validation rules used by Bitcoin. He proposed a one-byte flag on each header to indicate what was included, suggesting that nBits does not need to be sent even with other consensus rules since it is more or less necessarily a strict function of the prior headers. Posen believes that another >18% reduction in size beyond the removal of prev is significant and should not be ignored. However, Prev omission itself is not compatible, and Posen suggests that if there is a Bitcoin hardfork, it would recover the necessary bits from prev to use as an extra nonce for miners. Many altcoins have also changed their header structures, so even if the proposed change is altcoin incompatible, it should still be considered. Changing the serialization of 2017-12-13T00:12:45+00:00 + In a recent discussion among Bitcoin developers, Suhas Daftuar and Gregory Maxwell proposed the introduction of a new 'cmpctheaders'/'getcmpcthdrs' message pair for syncing, while keeping the existing 'headers'/'getheaders' messages unchanged. The idea is to never use 'getheaders' messages when communicating with upgraded peers and only use 'headers' messages for potentially announcing new blocks. Peers would fetch headers based on a weak heuristic where they fetch first from those with the tip at the highest difficulty and then work backwards. This proposal also mentions the possibility of changing the interface. [source]Another topic of discussion among Bitcoin developers is the inclusion of nBits in p2p messages without requiring the consensus-correct calculation of nBits. The purpose is to calculate the work on a chain as an anti-DoS measure. It is suggested that nBits could be included in any messages where the value is ambiguous, such as with the first header in a message and whenever it changes from the previous header's nBits. The serialization of existing messages should not be changed, so a new 'cmpctheaders'/'getcmpcthdrs' message pair could be introduced for syncing using this new message type. When communicating with upgraded peers, 'getheaders' messages would never be used, and only 'headers' messages would be used for potentially announcing new blocks. The splitting off of headers chain-sync functionality to a new message pair is seen as a nice side-effect benefit in the long run. [source]Tier Nolan shared a method called "high hash highway" in a Bitcoin-dev discussion, which allows compact proofs of total Proof-of-Work (POW). However, it was deemed off-topic as it provides no security without additional consensus enforced commitments. [source]Jim Posen proposed omitting nBits entirely in Bitcoin headers to save an extra 4 bytes. However, this could lead to more complexity in the validation code. As a compromise, Posen suggested using a one-byte flag to indicate the difference since the last header and stealing bits from the exponent to indicate mode. This approach would save three of the four bytes. Posen also proposed parallel header fetching, where nodes could request the lowest N hashes between two heights on the main chain and receive pairs of {height, header} for the N headers with the lowest hash in the specified range. [source]There is a proposal to reduce the bandwidth needed for Bitcoin header messages by removing the nBits field, which contains difficulty information. The proposal has received criticism for being too dependent on specific validation rules of the Bitcoin protocol. However, supporters argue that omitting nBits saves bytes and is worth the extra complexity in validation code. The discussion also covers the need to encode leading bits of prev, which are used as an extra nonce for miners. While some altcoins have already changed their header structures, making the proposed change possibly incompatible, supporters argue that it would be worth it to competitively advance Bitcoin. Additionally, the possibility of parallel header fetching to optimize header download is discussed. [source]In a Bitcoin-dev mailing list discussion, Greg Sanders raised a question about the use-case of timestamping in Bitcoin. Peter Todd responded by explaining that timestamping can be more vulnerable to malicious miners than financial applications due to the lack of a financial feedback loop. He also noted that timestamping is a non-financial piggy-back application that does not directly interact with the Bitcoin economy beyond a trivial number of timestamp transactions. [source]Riccardo Casatta proposed an optimization for transmitting Bitcoin block headers in a recent email on the Bitcoin-dev mailing list. The proposal suggests that after the first header, subsequent headers need not transmit the previous hash as the receiver can compute it by double hashing the previous header. This optimization could save about 40% bandwidth in a long stream of headers. Casatta believes this optimization could be particularly useful in instances where full node security isn't feasible, such as when dealing with private databases that require timestamping. He also suggests using fixed position chunks in an HTTP API to leverage HTTP caching and speed up synchronization for new clients. [source]In the Bitcoin-dev email thread, Jim Posen expressed his dislike of making the net header encoding dependent on specific header validation rules used by Bitcoin. He proposed a one-byte flag on each header to indicate what was included, suggesting that nBits does not need to be sent even with other consensus rules since it is more or less necessarily a strict function of the prior headers. Posen believes that another >18% reduction in size beyond the removal of prev is significant and should not be ignored. However, Prev omission itself is not compatible, and Posen suggests that if there is a Bitcoin hardfork, it would recover the necessary bits from prev to use as an extra nonce for miners. Many altcoins have also changed their header structures, so even if the proposed change is altcoin incompatible, it should still be considered. Changing the serialization of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_A-DNS-like-decentralized-mapping-for-wallet-addresses-.xml b/static/bitcoin-dev/Dec_2017/combined_A-DNS-like-decentralized-mapping-for-wallet-addresses-.xml index 1b620d4d16..5def5e2b5d 100644 --- a/static/bitcoin-dev/Dec_2017/combined_A-DNS-like-decentralized-mapping-for-wallet-addresses-.xml +++ b/static/bitcoin-dev/Dec_2017/combined_A-DNS-like-decentralized-mapping-for-wallet-addresses-.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - A DNS-like decentralized mapping for wallet addresses? - 2023-08-01T22:13:01.316898+00:00 - - Hampus Sjöberg 2017-12-19 13:11:24+00:00 - - - Damian Williamson 2017-12-19 09:05:34+00:00 - - - Sjors Provoost 2017-12-18 11:26:19+00:00 - - - Antonis Anastasiadis 2017-12-01 11:07:14+00:00 - - - Jérémie Dubois-Lacoste 2017-12-01 08:24:44+00:00 - - - CANNON 2017-12-01 04:17:37+00:00 - - - CANNON 2017-12-01 04:12:24+00:00 - - - Lucas Clemente Vella 2017-12-01 03:15:00+00:00 - - - Douglas Roark 2017-12-01 03:08:24+00:00 - - - Justin Newton 2017-12-01 00:10:29+00:00 - - - Tao Effect 2017-12-01 00:00:26+00:00 - - - mandar mulherkar 2017-11-30 22:20:10+00:00 - + 2025-09-26T15:52:35.322383+00:00 + python-feedgen + + + [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses? mandar mulherkar + 2017-11-30T22:20:00.000Z + + + Tao Effect + 2017-12-01T00:00:00.000Z + + + Justin Newton + 2017-12-01T00:10:00.000Z + + + Douglas Roark + 2017-12-01T03:08:00.000Z + + + Lucas Clemente Vella + 2017-12-01T03:15:00.000Z + + + CANNON + 2017-12-01T04:12:00.000Z + + + CANNON + 2017-12-01T04:17:00.000Z + + + Jérémie Dubois-Lacoste + 2017-12-01T08:24:00.000Z + + + Antonis Anastasiadis + 2017-12-01T11:07:00.000Z + + + Sjors Provoost + 2017-12-18T11:26:00.000Z + + + Damian Williamson + 2017-12-19T09:05:00.000Z + + + Hampus Sjöberg + 2017-12-19T13:11:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - A DNS-like decentralized mapping for wallet addresses? - 2023-08-01T22:13:01.316898+00:00 + 2025-09-26T15:52:35.323685+00:00 - The Bitcoin community has been discussing the possibility of a store-and-forward server that would allow users to trade privacy for convenience. This proposed solution, similar to BIP75, would allow users to use an email address as their account instead of a single Bitcoin address or xpubkey. While some members of the community express concerns about the security risks associated with the addition of DNS, others find it intriguing and believe it could be developed into something useful, especially when combined with BIP32 and BIP-47.The idea is to develop a Bitcoin wallet with an integrated name to address mapping feature, potentially based on Bitcoin Core. This mapping feature could include names, strings, and email addresses. However, relying on an additional service like DNS does introduce availability risks. It has been suggested that combining this mapping feature with BIP-47 could be beneficial, as payment codes could be associated with email addresses via DNS. The sender could then email the recipient the necessary information to retrieve funds, and the first transaction could have a time-locked refund in case the payment code becomes stale.The concept of a DNS-like decentralized mapping service for cryptocurrency addresses has been discussed on the bitcoin-dev mailing list. Douglas Roark shared his experience of working on a similar project with Armory and Verisign, which leveraged BIP32 to generate payment requests that automatically directed payees to the correct branch. Sjors proposed combining this with BIP-47 to associate payment codes with email addresses via DNS. The Open Alias project was recommended as a resource for further exploration.Lucas Clemente Vella expressed that a certain feature, which he believes has great potential, did not gain widespread adoption. He mentioned Namecoin as an alternative, as it aimed to build a decentralized domain name system (DNS) similar to Bitcoin's blockchain. Mandar Mulherkar questioned whether a DNS-like decentralized mapping service could provide user-friendly crypto addresses instead of long wallet addresses. OpenAlias.org was suggested as a possible solution.A new member of the bitcoin-dev community, Mandar Mulherkar, proposed the creation of a DNS-like decentralized mapping service for cryptocurrency addresses. This would allow users to input human-readable addresses that can be converted into wallet addresses by software. The original altcoin, Namecoin, attempted to build a similar system but did not gain widespread adoption. The user requested guidance on where to research this concept further.Another proposal for a DNS-like decentralized mapping service for crypto addresses was discussed on the bitcoin-dev mailing list. Armory and Verisign had previously attempted such a project, leveraging BIP32 to generate payment requests that directed payees to the correct branch. Douglas Roark considered this an interesting draft that could be developed further, with DNSSEC as a means to bootstrap identity to a common, reasonably secure standard.Mandar Mulherkar expressed curiosity about whether a DNS-like decentralized mapping service could provide user-friendly crypto addresses instead of long wallet addresses. The idea is to simplify the adoption process by eliminating the need for long strings or QR codes. One responder recommended WalletNames.com, which provides users with a human-readable name that can be mapped to their cryptocurrency address.In summary, there have been discussions within the Bitcoin community about the potential of a DNS-like decentralized mapping service for cryptocurrency addresses. This would enable users to input human-readable addresses that could be converted into wallet addresses by software. While some projects have attempted this in the past, there are ongoing efforts to explore and develop this concept further. Resources like Open Alias, Namecoin, Blockstack, and WalletNames.com have been suggested to research and potentially implement this idea. 2017-12-19T13:11:24+00:00 + The Bitcoin community has been discussing the possibility of a store-and-forward server that would allow users to trade privacy for convenience. This proposed solution, similar to BIP75, would allow users to use an email address as their account instead of a single Bitcoin address or xpubkey. While some members of the community express concerns about the security risks associated with the addition of DNS, others find it intriguing and believe it could be developed into something useful, especially when combined with BIP32 and BIP-47.The idea is to develop a Bitcoin wallet with an integrated name to address mapping feature, potentially based on Bitcoin Core. This mapping feature could include names, strings, and email addresses. However, relying on an additional service like DNS does introduce availability risks. It has been suggested that combining this mapping feature with BIP-47 could be beneficial, as payment codes could be associated with email addresses via DNS. The sender could then email the recipient the necessary information to retrieve funds, and the first transaction could have a time-locked refund in case the payment code becomes stale.The concept of a DNS-like decentralized mapping service for cryptocurrency addresses has been discussed on the bitcoin-dev mailing list. Douglas Roark shared his experience of working on a similar project with Armory and Verisign, which leveraged BIP32 to generate payment requests that automatically directed payees to the correct branch. Sjors proposed combining this with BIP-47 to associate payment codes with email addresses via DNS. The Open Alias project was recommended as a resource for further exploration.Lucas Clemente Vella expressed that a certain feature, which he believes has great potential, did not gain widespread adoption. He mentioned Namecoin as an alternative, as it aimed to build a decentralized domain name system (DNS) similar to Bitcoin's blockchain. Mandar Mulherkar questioned whether a DNS-like decentralized mapping service could provide user-friendly crypto addresses instead of long wallet addresses. OpenAlias.org was suggested as a possible solution.A new member of the bitcoin-dev community, Mandar Mulherkar, proposed the creation of a DNS-like decentralized mapping service for cryptocurrency addresses. This would allow users to input human-readable addresses that can be converted into wallet addresses by software. The original altcoin, Namecoin, attempted to build a similar system but did not gain widespread adoption. The user requested guidance on where to research this concept further.Another proposal for a DNS-like decentralized mapping service for crypto addresses was discussed on the bitcoin-dev mailing list. Armory and Verisign had previously attempted such a project, leveraging BIP32 to generate payment requests that directed payees to the correct branch. Douglas Roark considered this an interesting draft that could be developed further, with DNSSEC as a means to bootstrap identity to a common, reasonably secure standard.Mandar Mulherkar expressed curiosity about whether a DNS-like decentralized mapping service could provide user-friendly crypto addresses instead of long wallet addresses. The idea is to simplify the adoption process by eliminating the need for long strings or QR codes. One responder recommended WalletNames.com, which provides users with a human-readable name that can be mapped to their cryptocurrency address.In summary, there have been discussions within the Bitcoin community about the potential of a DNS-like decentralized mapping service for cryptocurrency addresses. This would enable users to input human-readable addresses that could be converted into wallet addresses by software. While some projects have attempted this in the past, there are ongoing efforts to explore and develop this concept further. Resources like Open Alias, Namecoin, Blockstack, and WalletNames.com have been suggested to research and potentially implement this idea. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-177-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-177-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml index 1e26db4981..0e8e0fe2ae 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-177-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-177-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP 177: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks - 2023-08-01T22:22:38.578433+00:00 - - Damian Williamson 2017-12-24 22:20:50+00:00 - - - Luke Dashjr 2017-12-24 07:21:24+00:00 - - - Damian Williamson 2017-12-24 02:57:38+00:00 - + 2025-09-26T15:52:18.605694+00:00 + python-feedgen + + + [bitcoin-dev] BIP 177: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks Damian Williamson + 2017-12-24T02:57:00.000Z + + + Luke Dashjr + 2017-12-24T07:21:00.000Z + + + Damian Williamson + 2017-12-24T22:20:00.000Z + + - python-feedgen + 2 Combined summary - BIP 177: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks - 2023-08-01T22:22:38.578433+00:00 + 2025-09-26T15:52:18.606253+00:00 - Damian Williamson, a developer, proposed BIP 177 as a solution to transactional reliability issues in Bitcoin. This proposal aims to address two main problems: the current transaction bandwidth limit and the ad-hoc methods used to include transactions in blocks, resulting in variable and confusing confirmation times. The proposed solution involves implementing a stable fee for priority service auction model instead of an auction model for limited bandwidth. This change is crucial to protect the value of fees, as they will eventually be the only payment that miners receive.Damian plans to share the full proposal on his blog in the near future, after incorporating feedback from various sources. He also provided links to previous threads related to this proposal where further discussions have taken place. It is important to note that BIP 177 has not been officially assigned, and Damian emphasizes the importance of not self-assigning BIP numbers.Overall, Damian Williamson's BIP 177 aims to tackle transactional reliability issues in Bitcoin by addressing the current transaction bandwidth limit and the ad-hoc methods of including transactions in blocks. The proposed solution involves implementing a stable fee for priority service auction model to ensure consistent confirmation times for valid transactions. Damian is actively seeking feedback and plans to post the complete proposal on his blog, incorporating input from various sources. The provided links offer additional information and previous discussions on this proposal. 2017-12-24T22:20:50+00:00 + Damian Williamson, a developer, proposed BIP 177 as a solution to transactional reliability issues in Bitcoin. This proposal aims to address two main problems: the current transaction bandwidth limit and the ad-hoc methods used to include transactions in blocks, resulting in variable and confusing confirmation times. The proposed solution involves implementing a stable fee for priority service auction model instead of an auction model for limited bandwidth. This change is crucial to protect the value of fees, as they will eventually be the only payment that miners receive.Damian plans to share the full proposal on his blog in the near future, after incorporating feedback from various sources. He also provided links to previous threads related to this proposal where further discussions have taken place. It is important to note that BIP 177 has not been officially assigned, and Damian emphasizes the importance of not self-assigning BIP numbers.Overall, Damian Williamson's BIP 177 aims to tackle transactional reliability issues in Bitcoin by addressing the current transaction bandwidth limit and the ad-hoc methods of including transactions in blocks. The proposed solution involves implementing a stable fee for priority service auction model to ensure consistent confirmation times for valid transactions. Damian is actively seeking feedback and plans to post the complete proposal on his blog, incorporating input from various sources. The provided links offer additional information and previous discussions on this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-21-amendment-proposal-no125.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-21-amendment-proposal-no125.xml index e0c55578f4..c0a3a853f7 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-21-amendment-proposal-no125.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-21-amendment-proposal-no125.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - BIP-21 amendment proposal: -no125 - 2023-08-01T22:16:34.514348+00:00 - - Paul Iverson 2017-12-23 18:33:21+00:00 - - - Matt Corallo 2017-12-23 16:25:08+00:00 - - - Peter Todd 2017-12-11 18:19:43+00:00 - - - CryptAxe 2017-12-05 20:06:31+00:00 - - - Sjors Provoost 2017-12-05 20:00:01+00:00 - - - CryptAxe 2017-12-05 19:40:42+00:00 - - - Luke Dashjr 2017-12-05 19:39:32+00:00 - - - Sjors Provoost 2017-12-05 19:24:04+00:00 - + 2025-09-26T15:52:33.230713+00:00 + python-feedgen + + + [bitcoin-dev] BIP-21 amendment proposal: -no125 Sjors Provoost + 2017-12-05T19:24:00.000Z + + + Luke Dashjr + 2017-12-05T19:39:00.000Z + + + CryptAxe + 2017-12-05T19:40:00.000Z + + + Sjors Provoost + 2017-12-05T20:00:00.000Z + + + CryptAxe + 2017-12-05T20:06:00.000Z + + + Peter Todd + 2017-12-11T18:19:00.000Z + + + Matt Corallo + 2017-12-23T16:25:00.000Z + + + Paul Iverson + 2017-12-23T18:33:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - BIP-21 amendment proposal: -no125 - 2023-08-01T22:16:34.514348+00:00 + 2025-09-26T15:52:33.231680+00:00 - A recent discussion has arisen regarding the removal of the "no-RBF" flag in Bitcoin transactions. The flag is believed to confuse new users about the security of 0-conf transactions. It is assumed that miners are profit maximizers and will replace low fee transactions with higher fee ones, making full RBF a de facto policy in Bitcoin. Therefore, it is recommended to remove the flag and adopt full RBF as the "de jure" policy. However, there are legitimate reasons why people use non-RBF transactions despite their poor usability. If people want to overpay on fees for these transactions, there is no reason not to let them. A recent pull request has been submitted to turn on Replace-by-Fee (RBF) by default. This has sparked some discussion, and a no125=1 flag was suggested to accommodate merchants who don't want their customers to use RBF. When this flag is set, wallets should not use RBF unless the user explicitly overrides the merchant's preference. However, objections have been raised against this suggestion, stating that there is no reason to avoid the RBF flag and it doesn't reduce the risk of double-spending. Some miners also allow RBF regardless of the flag, making it less effective in preventing malicious double spending.In a separate discussion, the possibility of reusing sections of Bitcoin Improvement Proposals (BIPs) for other purposes was explored. It was agreed that not all BIPs would be suitable for this, but it is worth considering for some. One suggestion was to reuse a section of the payment request URI for multiple purposes, such as Confidential Transactions (CT). However, it was noted that any ignored flags would need to be clearly defined in the BIP to ensure proper behavior.Another alternative solution was proposed in a discussion about using flags to disable specific operations. This involved having an "-ignoredflags=x,y,z" section of the URI that can be used to ignore whatever BIP. However, it was acknowledged that not all BIPs would work with this pattern and each ignored flag would require carefully defined behavior. It was also mentioned that this BIP may soon be superseded entirely due to discussions of variations on BIP-71.There was also a discussion about the use of bech32 addresses, with questions raised about the need for a param when bech32 addresses are just normal addresses. The idea of using a backwards compatible P2SH address with a param to allow modern wallets to use bech32 was introduced. This is encouraged as it is cheaper for the recipient to spend these funds, but merchants can eventually drop support for old wallets once the new format has sufficient adoption.In summary, there is ongoing debate about the removal of the "no-RBF" flag in Bitcoin transactions. While some argue for its removal and the adoption of full RBF as the default policy, others believe there are legitimate reasons to continue using non-RBF transactions. A pull request to turn on RBF by default has been submitted, but concerns have been raised about how this will affect merchants. Suggestions have been made to accommodate merchant preferences through the use of flags in the URI. Additionally, discussions have taken place regarding the reuse of BIP sections for other purposes and the use of bech32 addresses. 2017-12-23T18:33:21+00:00 + A recent discussion has arisen regarding the removal of the "no-RBF" flag in Bitcoin transactions. The flag is believed to confuse new users about the security of 0-conf transactions. It is assumed that miners are profit maximizers and will replace low fee transactions with higher fee ones, making full RBF a de facto policy in Bitcoin. Therefore, it is recommended to remove the flag and adopt full RBF as the "de jure" policy. However, there are legitimate reasons why people use non-RBF transactions despite their poor usability. If people want to overpay on fees for these transactions, there is no reason not to let them. A recent pull request has been submitted to turn on Replace-by-Fee (RBF) by default. This has sparked some discussion, and a no125=1 flag was suggested to accommodate merchants who don't want their customers to use RBF. When this flag is set, wallets should not use RBF unless the user explicitly overrides the merchant's preference. However, objections have been raised against this suggestion, stating that there is no reason to avoid the RBF flag and it doesn't reduce the risk of double-spending. Some miners also allow RBF regardless of the flag, making it less effective in preventing malicious double spending.In a separate discussion, the possibility of reusing sections of Bitcoin Improvement Proposals (BIPs) for other purposes was explored. It was agreed that not all BIPs would be suitable for this, but it is worth considering for some. One suggestion was to reuse a section of the payment request URI for multiple purposes, such as Confidential Transactions (CT). However, it was noted that any ignored flags would need to be clearly defined in the BIP to ensure proper behavior.Another alternative solution was proposed in a discussion about using flags to disable specific operations. This involved having an "-ignoredflags=x,y,z" section of the URI that can be used to ignore whatever BIP. However, it was acknowledged that not all BIPs would work with this pattern and each ignored flag would require carefully defined behavior. It was also mentioned that this BIP may soon be superseded entirely due to discussions of variations on BIP-71.There was also a discussion about the use of bech32 addresses, with questions raised about the need for a param when bech32 addresses are just normal addresses. The idea of using a backwards compatible P2SH address with a param to allow modern wallets to use bech32 was introduced. This is encouraged as it is cheaper for the recipient to spend these funds, but merchants can eventually drop support for old wallets once the new format has sufficient adoption.In summary, there is ongoing debate about the removal of the "no-RBF" flag in Bitcoin transactions. While some argue for its removal and the adoption of full RBF as the default policy, others believe there are legitimate reasons to continue using non-RBF transactions. A pull request to turn on RBF by default has been submitted, but concerns have been raised about how this will affect merchants. Suggestions have been made to accommodate merchant preferences through the use of flags in the URI. Additionally, discussions have taken place regarding the reuse of BIP sections for other purposes and the use of bech32 addresses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-Dead-Man-s-Switch.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-Dead-Man-s-Switch.xml index 4f74204ec4..0ccb2bc4b4 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-Dead-Man-s-Switch.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-Dead-Man-s-Switch.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP - Dead Man's Switch - 2023-08-01T22:19:35.455559+00:00 - - Ricardo Filipe 2017-12-12 14:02:12+00:00 - - - Teweldemedhin Aberra 2017-12-12 01:10:38+00:00 - - - Luke Dashjr 2017-12-11 18:34:12+00:00 - - - Chris Riley 2017-12-11 18:28:03+00:00 - - - Pieter Wuille 2017-12-11 18:26:40+00:00 - - - Radoslaw Biernacki 2017-12-11 18:13:26+00:00 - - - Nick Pudar 2017-12-11 18:12:05+00:00 - - - Douglas Roark 2017-12-11 18:12:02+00:00 - - - Teweldemedhin Aberra 2017-12-11 17:30:37+00:00 - + 2025-09-26T15:52:58.447603+00:00 + python-feedgen + + + [bitcoin-dev] BIP - Dead Man's Switch Teweldemedhin Aberra + 2017-12-11T17:30:00.000Z + + + Douglas Roark + 2017-12-11T18:12:00.000Z + + + Nick Pudar + 2017-12-11T18:12:00.000Z + + + Radoslaw Biernacki + 2017-12-11T18:13:00.000Z + + + Pieter Wuille + 2017-12-11T18:26:00.000Z + + + Chris Riley + 2017-12-11T18:28:00.000Z + + + Luke Dashjr + 2017-12-11T18:34:00.000Z + + + Teweldemedhin Aberra + 2017-12-12T01:10:00.000Z + + + Ricardo Filipe + 2017-12-12T14:02:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - BIP - Dead Man's Switch - 2023-08-01T22:19:35.455559+00:00 + 2025-09-26T15:52:58.448705+00:00 - In recent discussions among Bitcoin developers, a solution to the problem of lost Bitcoins has been proposed. It is estimated that around 4 million out of the 16.4 million Bitcoins ever mined are lost due to human error resulting in the loss of private keys. One proposed solution is to implement a Dead Man's Switch, which would cause dormant Bitcoin addresses to automatically expire after a fixed length of time, such as ten years.Luke Dashjr has suggested an alternative solution to increase the divisibility of Bitcoins by extending the range of relative lock-times. Currently, this feature can only be implemented for one year expirations, but Dashjr proposes allowing several years. However, this solution would require integer values larger than 64 bits and could only be implemented on the base layer through a hard fork, which undermines the invariants of Bitcoin.The implementation of the Dead Man's Switch or the extension of relative lock-times would help address the issue of lost Bitcoins. It is estimated that approximately 4 million Bitcoins are lost forever. Dormant addresses would automatically expire after a fixed length of time, and the calculation of miner rewards would take into account expired Bitcoins. However, it is important to note that there is no way to eliminate human errors causing these losses, and the total number of Bitcoins in circulation will eventually reach zero when the cap of 21 million is reached.There are concerns and debates surrounding the proposed solutions. Some argue that the loss of Bitcoins is not necessarily a problem, as Bitcoin is divisible up to 100 million units and potentially more if needed. Others question the morality of expiring dormant Bitcoins, especially in cases where individuals may have placed their Bitcoins in cold storage before passing away. Implementing a Dead Man's Switch could also potentially encourage censorship by miners for people attempting to move their coins.In conclusion, proposals have been made to address the issue of lost Bitcoins in circulation. The implementation of a Dead Man's Switch or the extension of relative lock-times could help prevent the loss of Bitcoins. However, there are concerns and debates surrounding these proposals, including the morality and potential consequences of expiring dormant Bitcoins. The discussion among Bitcoin developers continues, and anyone is welcome to propose and convince others to follow a new chain and code. 2017-12-12T14:02:12+00:00 + In recent discussions among Bitcoin developers, a solution to the problem of lost Bitcoins has been proposed. It is estimated that around 4 million out of the 16.4 million Bitcoins ever mined are lost due to human error resulting in the loss of private keys. One proposed solution is to implement a Dead Man's Switch, which would cause dormant Bitcoin addresses to automatically expire after a fixed length of time, such as ten years.Luke Dashjr has suggested an alternative solution to increase the divisibility of Bitcoins by extending the range of relative lock-times. Currently, this feature can only be implemented for one year expirations, but Dashjr proposes allowing several years. However, this solution would require integer values larger than 64 bits and could only be implemented on the base layer through a hard fork, which undermines the invariants of Bitcoin.The implementation of the Dead Man's Switch or the extension of relative lock-times would help address the issue of lost Bitcoins. It is estimated that approximately 4 million Bitcoins are lost forever. Dormant addresses would automatically expire after a fixed length of time, and the calculation of miner rewards would take into account expired Bitcoins. However, it is important to note that there is no way to eliminate human errors causing these losses, and the total number of Bitcoins in circulation will eventually reach zero when the cap of 21 million is reached.There are concerns and debates surrounding the proposed solutions. Some argue that the loss of Bitcoins is not necessarily a problem, as Bitcoin is divisible up to 100 million units and potentially more if needed. Others question the morality of expiring dormant Bitcoins, especially in cases where individuals may have placed their Bitcoins in cold storage before passing away. Implementing a Dead Man's Switch could also potentially encourage censorship by miners for people attempting to move their coins.In conclusion, proposals have been made to address the issue of lost Bitcoins in circulation. The implementation of a Dead Man's Switch or the extension of relative lock-times could help prevent the loss of Bitcoins. However, there are concerns and debates surrounding these proposals, including the morality and potential consequences of expiring dormant Bitcoins. The discussion among Bitcoin developers continues, and anyone is welcome to propose and convince others to follow a new chain and code. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-Idea-Marginal-Pricing.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-Idea-Marginal-Pricing.xml index 2f834bcb1f..37e9fef4d2 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-Idea-Marginal-Pricing.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-Idea-Marginal-Pricing.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - BIP Idea: Marginal Pricing - 2023-08-01T22:11:38.305271+00:00 - - Damian Williamson 2017-12-02 03:55:22+00:00 - - - Ryan J Martin 2017-12-01 07:58:01+00:00 - - - Chenxi Cai 2017-11-30 16:15:01+00:00 - - - Eric Voskuil 2017-11-30 12:03:30+00:00 - - - Gregory Maxwell 2017-11-30 11:40:54+00:00 - - - Federico Tenga 2017-11-30 09:37:57+00:00 - - - Gregory Maxwell 2017-11-30 09:12:48+00:00 - - - William Morriss 2017-11-30 06:13:15+00:00 - - - William Morriss 2017-11-30 06:05:02+00:00 - - - Chenxi Cai 2017-11-30 05:52:24+00:00 - - - Ben Kloester 2017-11-30 02:38:25+00:00 - - - William Morriss 2017-11-30 00:47:43+00:00 - + 2025-09-26T15:52:45.838654+00:00 + python-feedgen + + + [bitcoin-dev] BIP Idea: Marginal Pricing William Morriss + 2017-11-30T00:47:00.000Z + + + Ben Kloester + 2017-11-30T02:38:00.000Z + + + Chenxi Cai + 2017-11-30T05:52:00.000Z + + + William Morriss + 2017-11-30T06:05:00.000Z + + + William Morriss + 2017-11-30T06:13:00.000Z + + + Gregory Maxwell + 2017-11-30T09:12:00.000Z + + + Federico Tenga + 2017-11-30T09:37:00.000Z + + + Gregory Maxwell + 2017-11-30T11:40:00.000Z + + + Eric Voskuil + 2017-11-30T12:03:00.000Z + + + Chenxi Cai + 2017-11-30T16:15:00.000Z + + + Ryan J Martin + 2017-12-01T07:58:00.000Z + + + Damian Williamson + 2017-12-02T03:55:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - BIP Idea: Marginal Pricing - 2023-08-01T22:11:38.305271+00:00 + 2025-09-26T15:52:45.840043+00:00 - A proposal has been made on the Bitcoin-dev mailing list to maximize total transaction fees and hash power. The proposal suggests using a marginal pricing system without a block size limit. Each transaction would have a transaction weight based on the fee paid and time waiting in the pool. A higher fee would increase the likelihood of a transaction being included in the current block. The dynamic block size limit would be regulated by profit motive, and all fees would be fair.William Morriss proposed the idea of Marginal Pricing in a Bitcoin Improvement Proposal (BIP) to address challenges in the current transaction market. The proposal aims to reduce pending transaction time, individual transaction fees, and increase total transaction fees. It suggests miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block, refunding excess fees. The block size limit would be removed to allow for a dynamic limit regulated by profit motive. However, there are challenges in implementing this proposal, including the need for validators to agree on the maximum block size and the risk of miners cheating by including extra transactions.The current fee system used in Bitcoin, Generalized first-price auction, may not be maximizing miners' fees. A two-part pricing scheme with a fixed fee per transaction and variable fee per byte could deter spamming and capture revenue from users with higher willingness to pay. While Vickrey–Clarke–Groves auction elicits truthful bids from bidders, it may not maximize miners' fees as much as other systems. The choice of fee design will not impact miners' fees unless the outcomes of the auction change. Switching to a marginal price bidding system could supersede the block size limit and change the outcome of the auction.An email thread on the Bitcoin-dev mailing list discussed a proposal to redesign Bitcoin's fee market. The proposal suggested changing the fee structure but not removing the block size limit. Out-of-band payments were a concern, but it was argued that miners would not have incentives to mine only out-of-band transactions. Bitcoin is neutral on how miners are paid, and on-chain fee payment has benefits such as preserving anonymity. There is no evidence of centralization pressure with marginal fees.The discussion also touched on the topic of Out of Band (OOB) fees in Bitcoin. The system disincentivizes both miners and users from preferring OOB fees. Competent wallet software can draft transactions paying OOB and min fee at equivalent rates. Miners would construct blocks that maximize their revenue. The use of MINFEE is not an equilibrium. Variance in fee willingness could result in variance in network capacity. However, rich uncle bill wasting money with high fees would handicap the network. Super-rational behavior could lead to collusion among miners to permit high fee-rate transactions every other block.The conversation among members of the bitcoin-dev mailing list discussed a proposal to change the fee structure in order to reduce the cost of running a node. Concerns were raised about miners spamming the network for free, which could increase the cost of running a node. A previous article proposed redesigning Bitcoin's fee market, but it broke down due to concerns about out-of-band payments. The author argues that the system disincentivizes out-of-band tx fees, and there is no more centralization pressure with marginal fees than before.The email thread also addressed the possibility of using alternative auction systems in Bitcoin. Currently, Bitcoin uses a Generalized first-price auction, but alternative approaches such as Generalized second-price or Vickrey-Clarke-Groves auctions were considered. However, the choice of fee design will not impact miners' fees unless the outcomes of the auction change. Changing the bidding system to the marginal price would allow for a superseding of the block size limit and change the outcome of the auction.The proposal aims to maximize total transaction fees, reduce pending transaction time, and lower individual transaction fees. It suggests accepting zero fees natively in the protocol and instead accepting actual fees out-of-band or via OP_TRUE outputs. Miners would implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block, and excess transaction fees would be refunded to the inputs. This dynamic block size limit regulated by profit motive would maximize transaction fees for every block.Overall, the discussion revolves around proposals to redesign Bitcoin's fee market, maximize total transaction fees, reduce pending transaction time, and lower individual transaction fees. Various approaches, such as marginal pricing and alternative auction systems, have been considered. Challenges such as validators agreeing on maximum block size and miners cheating by including extra transactions need to be addressed.The proposal in this context is to remove the block size limit in order to address the downsides associated with a fixed block size. These downsides include unpredictable transaction settlement time, variable transaction fees depending on network congestion, and frequent overpay. By eliminating the block size limit, miners would be able to choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees would 2017-12-02T03:55:22+00:00 + A proposal has been made on the Bitcoin-dev mailing list to maximize total transaction fees and hash power. The proposal suggests using a marginal pricing system without a block size limit. Each transaction would have a transaction weight based on the fee paid and time waiting in the pool. A higher fee would increase the likelihood of a transaction being included in the current block. The dynamic block size limit would be regulated by profit motive, and all fees would be fair.William Morriss proposed the idea of Marginal Pricing in a Bitcoin Improvement Proposal (BIP) to address challenges in the current transaction market. The proposal aims to reduce pending transaction time, individual transaction fees, and increase total transaction fees. It suggests miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block, refunding excess fees. The block size limit would be removed to allow for a dynamic limit regulated by profit motive. However, there are challenges in implementing this proposal, including the need for validators to agree on the maximum block size and the risk of miners cheating by including extra transactions.The current fee system used in Bitcoin, Generalized first-price auction, may not be maximizing miners' fees. A two-part pricing scheme with a fixed fee per transaction and variable fee per byte could deter spamming and capture revenue from users with higher willingness to pay. While Vickrey–Clarke–Groves auction elicits truthful bids from bidders, it may not maximize miners' fees as much as other systems. The choice of fee design will not impact miners' fees unless the outcomes of the auction change. Switching to a marginal price bidding system could supersede the block size limit and change the outcome of the auction.An email thread on the Bitcoin-dev mailing list discussed a proposal to redesign Bitcoin's fee market. The proposal suggested changing the fee structure but not removing the block size limit. Out-of-band payments were a concern, but it was argued that miners would not have incentives to mine only out-of-band transactions. Bitcoin is neutral on how miners are paid, and on-chain fee payment has benefits such as preserving anonymity. There is no evidence of centralization pressure with marginal fees.The discussion also touched on the topic of Out of Band (OOB) fees in Bitcoin. The system disincentivizes both miners and users from preferring OOB fees. Competent wallet software can draft transactions paying OOB and min fee at equivalent rates. Miners would construct blocks that maximize their revenue. The use of MINFEE is not an equilibrium. Variance in fee willingness could result in variance in network capacity. However, rich uncle bill wasting money with high fees would handicap the network. Super-rational behavior could lead to collusion among miners to permit high fee-rate transactions every other block.The conversation among members of the bitcoin-dev mailing list discussed a proposal to change the fee structure in order to reduce the cost of running a node. Concerns were raised about miners spamming the network for free, which could increase the cost of running a node. A previous article proposed redesigning Bitcoin's fee market, but it broke down due to concerns about out-of-band payments. The author argues that the system disincentivizes out-of-band tx fees, and there is no more centralization pressure with marginal fees than before.The email thread also addressed the possibility of using alternative auction systems in Bitcoin. Currently, Bitcoin uses a Generalized first-price auction, but alternative approaches such as Generalized second-price or Vickrey-Clarke-Groves auctions were considered. However, the choice of fee design will not impact miners' fees unless the outcomes of the auction change. Changing the bidding system to the marginal price would allow for a superseding of the block size limit and change the outcome of the auction.The proposal aims to maximize total transaction fees, reduce pending transaction time, and lower individual transaction fees. It suggests accepting zero fees natively in the protocol and instead accepting actual fees out-of-band or via OP_TRUE outputs. Miners would implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block, and excess transaction fees would be refunded to the inputs. This dynamic block size limit regulated by profit motive would maximize transaction fees for every block.Overall, the discussion revolves around proposals to redesign Bitcoin's fee market, maximize total transaction fees, reduce pending transaction time, and lower individual transaction fees. Various approaches, such as marginal pricing and alternative auction systems, have been considered. Challenges such as validators agreeing on maximum block size and miners cheating by including extra transactions need to be addressed.The proposal in this context is to remove the block size limit in order to address the downsides associated with a fixed block size. These downsides include unpredictable transaction settlement time, variable transaction fees depending on network congestion, and frequent overpay. By eliminating the block size limit, miners would be able to choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees would - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Crypto-Open-Exchange-Protocol-COX-.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Crypto-Open-Exchange-Protocol-COX-.xml index 8585c0386e..8fdf14493c 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Crypto-Open-Exchange-Protocol-COX-.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Crypto-Open-Exchange-Protocol-COX-.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - BIP Proposal: Crypto Open Exchange Protocol (COX) - 2023-08-01T22:21:18.489772+00:00 - - Sjors Provoost 2017-12-21 09:04:44+00:00 - - - Nicolas Dorier 2017-12-21 08:20:11+00:00 - - - Sjors Provoost 2017-12-20 08:49:09+00:00 - - - Dan Libby 2017-12-20 06:50:42+00:00 - - - Nicolas Dorier 2017-12-20 06:28:07+00:00 - + 2025-09-26T15:52:20.697101+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX) Nicolas Dorier + 2017-12-20T06:28:00.000Z + + + Dan Libby + 2017-12-20T06:50:00.000Z + + + Sjors Provoost + 2017-12-20T08:49:00.000Z + + + Nicolas Dorier + 2017-12-21T08:20:00.000Z + + + Sjors Provoost + 2017-12-21T09:04:00.000Z + + - python-feedgen + 2 Combined summary - BIP Proposal: Crypto Open Exchange Protocol (COX) - 2023-08-01T22:21:18.489772+00:00 + 2025-09-26T15:52:20.697859+00:00 - Nicolas Dorier has proposed the Crypto Open Exchange Protocol (COX), a standard that allows merchants to accept cryptocurrency payments and sell them automatically. The protocol aims to reduce transaction fees for merchants and provide more flexibility in choosing payment processors. By decoupling payment processors from exchanges, COX helps local exchanges lacking resources to develop their own payment solutions. The COX protocol offers an address source creation wizard that allows merchants to specify what to do when cryptocurrency is sent to the address source. It also provides an "address source URI" that can be input into the payment processor. An exchange compatible with COX would respond to HTTP POST requests to the address source URI by providing a deposit address, current rate, and optional details about rate fluctuation risks. PROCCO, a payment processor, has developed a Crypto Open Exchange Protocol that enables e-commerce websites to accept bitcoin payments. It retrieves the rate and conditions from the address source URI and presents a Bitcoin Payment Checkout page when a customer pays in bitcoin. After the payment is made, PROCCO marks it as paid and redirects to the e-commerce website. MYCOIN credits the merchant's account with the received amount of bitcoin and creates a market sell order on behalf of the merchant. The response from an exchange varies depending on whether the rate is guaranteed or not. Although the adoption of COX is not mandatory, local exchanges have incentives to implement it. Alternatively, an adapter server can be developed to expose COX endpoints and connect to underlying exchange APIs. The COX protocol is dual-licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal.In addition to decoupling payment processors from exchanges, COX aims to simplify the payment process and reduce potential risks for merchants. It proposes adding an invoice mechanism similar to Lightning, where a pre-image is sent to the user's wallet upon receipt of funds. This pre-image can be presented to the merchant in case of any issues, alleviating the burden of dealing with user support requests from exchanges. The protocol could also be expanded for Lightning and include a callback from the exchange to confirm payment.COX offers merchants more flexibility by allowing them to choose their preferred method of payment using buySymbol and sellSymbol instead of currencyCode and cryptoCurrencyCode. This change would make the system more generic and enable merchants to easily switch between different cryptocurrencies without limitations. It promotes the use of different cryptocurrencies as more merchants would be willing to accept them as payment, providing greater choice and flexibility for both merchants and customers.Overall, COX is a simple protocol that addresses the issues faced by existing cryptocurrency merchant adoption solutions. It gives merchants the freedom to choose their own payment processor solution while protecting against cryptocurrency volatility. The draft of the COX protocol can be found on Github and is dual-licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal. 2017-12-21T09:04:44+00:00 + Nicolas Dorier has proposed the Crypto Open Exchange Protocol (COX), a standard that allows merchants to accept cryptocurrency payments and sell them automatically. The protocol aims to reduce transaction fees for merchants and provide more flexibility in choosing payment processors. By decoupling payment processors from exchanges, COX helps local exchanges lacking resources to develop their own payment solutions. The COX protocol offers an address source creation wizard that allows merchants to specify what to do when cryptocurrency is sent to the address source. It also provides an "address source URI" that can be input into the payment processor. An exchange compatible with COX would respond to HTTP POST requests to the address source URI by providing a deposit address, current rate, and optional details about rate fluctuation risks. PROCCO, a payment processor, has developed a Crypto Open Exchange Protocol that enables e-commerce websites to accept bitcoin payments. It retrieves the rate and conditions from the address source URI and presents a Bitcoin Payment Checkout page when a customer pays in bitcoin. After the payment is made, PROCCO marks it as paid and redirects to the e-commerce website. MYCOIN credits the merchant's account with the received amount of bitcoin and creates a market sell order on behalf of the merchant. The response from an exchange varies depending on whether the rate is guaranteed or not. Although the adoption of COX is not mandatory, local exchanges have incentives to implement it. Alternatively, an adapter server can be developed to expose COX endpoints and connect to underlying exchange APIs. The COX protocol is dual-licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal.In addition to decoupling payment processors from exchanges, COX aims to simplify the payment process and reduce potential risks for merchants. It proposes adding an invoice mechanism similar to Lightning, where a pre-image is sent to the user's wallet upon receipt of funds. This pre-image can be presented to the merchant in case of any issues, alleviating the burden of dealing with user support requests from exchanges. The protocol could also be expanded for Lightning and include a callback from the exchange to confirm payment.COX offers merchants more flexibility by allowing them to choose their preferred method of payment using buySymbol and sellSymbol instead of currencyCode and cryptoCurrencyCode. This change would make the system more generic and enable merchants to easily switch between different cryptocurrencies without limitations. It promotes the use of different cryptocurrencies as more merchants would be willing to accept them as payment, providing greater choice and flexibility for both merchants and customers.Overall, COX is a simple protocol that addresses the issues faced by existing cryptocurrency merchant adoption solutions. It gives merchants the freedom to choose their own payment processor solution while protecting against cryptocurrency volatility. The draft of the COX protocol can be found on Github and is dual-licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Revised-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Revised-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml index 14547fe2e8..acd588840a 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Revised-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Revised-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks - 2023-08-01T22:17:41.455084+00:00 - - Damian Williamson 2018-01-21 05:49:25+00:00 - - - Alan Evans 2018-01-20 14:46:41+00:00 - - - Damian Williamson 2018-01-20 12:04:20+00:00 - - - Damian Williamson 2018-01-19 23:25:43+00:00 - - - Damian Williamson 2018-01-04 09:01:10+00:00 - - - Damian Williamson 2018-01-01 11:04:57+00:00 - - - Damian Williamson 2017-12-27 12:29:41+00:00 - - - ZmnSCPxj 2017-12-27 03:55:43+00:00 - - - Damian Williamson 2017-12-26 05:14:14+00:00 - - - Spartacus Rex 2017-12-24 09:02:09+00:00 - - - Damian Williamson 2017-12-24 03:44:26+00:00 - - - Damian Williamson 2017-12-23 01:24:28+00:00 - - - Spartacus Rex 2017-12-22 18:07:49+00:00 - - - Damian Williamson 2017-12-22 06:22:40+00:00 - - - Damian Williamson 2017-12-19 07:51:39+00:00 - - - Damian Williamson 2017-12-19 07:48:37+00:00 - - - Chris Riley 2017-12-18 12:09:34+00:00 - - - Damian Williamson 2017-12-17 04:14:39+00:00 - - - Damian Williamson 2017-12-15 20:59:51+00:00 - - - Rhavar 2017-12-15 16:38:46+00:00 - - - Damian Williamson 2017-12-15 09:42:42+00:00 - - - Damian Williamson 2017-12-07 21:01:43+00:00 - + 2025-09-26T15:52:56.354415+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks Damian Williamson + 2017-12-07T21:01:00.000Z + + + Damian Williamson + 2017-12-15T09:42:00.000Z + + + Rhavar + 2017-12-15T16:38:00.000Z + + + Damian Williamson + 2017-12-15T20:59:00.000Z + + + Damian Williamson + 2017-12-17T04:14:00.000Z + + + Chris Riley + 2017-12-18T12:09:00.000Z + + + Damian Williamson + 2017-12-19T07:48:00.000Z + + + Damian Williamson + 2017-12-19T07:51:00.000Z + + + Damian Williamson + 2017-12-22T06:22:00.000Z + + + Spartacus Rex + 2017-12-22T18:07:00.000Z + + + Damian Williamson + 2017-12-23T01:24:00.000Z + + + Damian Williamson + 2017-12-24T03:44:00.000Z + + + Spartacus Rex + 2017-12-24T09:02:00.000Z + + + Damian Williamson + 2017-12-26T05:14:00.000Z + + + ZmnSCPxj + 2017-12-27T03:55:00.000Z + + + Damian Williamson + 2017-12-27T12:29:00.000Z + + + [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks Damian Williamson + 2018-01-01T11:04:00.000Z + + + Damian Williamson + 2018-01-04T09:01:00.000Z + + + Damian Williamson + 2018-01-19T23:25:00.000Z + + + Damian Williamson + 2018-01-20T12:04:00.000Z + + + Alan Evans + 2018-01-20T14:46:00.000Z + + + Damian Williamson + 2018-01-21T05:49:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks - 2023-08-01T22:17:41.456084+00:00 + 2025-09-26T15:52:56.356773+00:00 - Damian Williamson has proposed a Bitcoin Improvement Proposal (BIP) called UTPFOTIB (Use Transaction Priority For Ordering Transactions In Blocks) to address the limitations and inconsistencies with Bitcoin's transaction bandwidth. The proposal aims to improve transaction reliability and scalability, which are crucial for the success and uptake of Bitcoin as a payment system.Currently, transactions with lower fees are being overshadowed by those with higher fees, leading to a large number of valid transactions never confirming. This unreliable payment system undermines consumer confidence and threatens the value of Bitcoin. Williamson's proposal suggests assigning each transaction an individual priority based on the fee paid and time waiting in the transaction pool. This priority would determine the likelihood of inclusion in a block.By prioritizing transactions based on these factors rather than using an auction model, the proposal aims to provide full transaction confirmation for every valid transaction. This approach also maximizes transaction reliability and increases the potential for consumer and business uptake.To implement this proposal, the target block size would be determined based on the number of transactions in the pool. The priority of each transaction would influence its probability of being included in the block. The revised BIP aims to maximize transaction reliability, scalability, and total fees paid per block without compromising reliability.However, there are some drawbacks to consider. Initially, this approach may lower total transaction fees per block. Additionally, programming is required to implement the proposal, and a mathematician would need to verify if blocks conform to the proposed method.In conclusion, Damian Williamson's proposed BIP seeks to address the current limitations of Bitcoin's transaction bandwidth. By utilizing transaction priority to order transactions in blocks, the proposal aims to enhance transaction reliability, scalability, and overall fees paid per block. While there are potential downsides such as initial reduction in total transaction fees and the need for programming, Williamson emphasizes the importance of validating full transaction reliability and enabling scalability of block sizes. Collaboration and feedback from the Bitcoin developer community are encouraged to further refine and implement the proposal. 2018-01-21T05:49:25+00:00 + Damian Williamson has proposed a Bitcoin Improvement Proposal (BIP) called UTPFOTIB (Use Transaction Priority For Ordering Transactions In Blocks) to address the limitations and inconsistencies with Bitcoin's transaction bandwidth. The proposal aims to improve transaction reliability and scalability, which are crucial for the success and uptake of Bitcoin as a payment system.Currently, transactions with lower fees are being overshadowed by those with higher fees, leading to a large number of valid transactions never confirming. This unreliable payment system undermines consumer confidence and threatens the value of Bitcoin. Williamson's proposal suggests assigning each transaction an individual priority based on the fee paid and time waiting in the transaction pool. This priority would determine the likelihood of inclusion in a block.By prioritizing transactions based on these factors rather than using an auction model, the proposal aims to provide full transaction confirmation for every valid transaction. This approach also maximizes transaction reliability and increases the potential for consumer and business uptake.To implement this proposal, the target block size would be determined based on the number of transactions in the pool. The priority of each transaction would influence its probability of being included in the block. The revised BIP aims to maximize transaction reliability, scalability, and total fees paid per block without compromising reliability.However, there are some drawbacks to consider. Initially, this approach may lower total transaction fees per block. Additionally, programming is required to implement the proposal, and a mathematician would need to verify if blocks conform to the proposed method.In conclusion, Damian Williamson's proposed BIP seeks to address the current limitations of Bitcoin's transaction bandwidth. By utilizing transaction priority to order transactions in blocks, the proposal aims to enhance transaction reliability, scalability, and overall fees paid per block. While there are potential downsides such as initial reduction in total transaction fees and the need for programming, Williamson emphasizes the importance of validating full transaction reliability and enabling scalability of block sizes. Collaboration and feedback from the Bitcoin developer community are encouraged to further refine and implement the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-UTWFOTIB-Use-Transaction-Weight-For-Ordering-Transactions-In-Blocks.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-UTWFOTIB-Use-Transaction-Weight-For-Ordering-Transactions-In-Blocks.xml index 8448aabb20..ab944a693b 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-UTWFOTIB-Use-Transaction-Weight-For-Ordering-Transactions-In-Blocks.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-UTWFOTIB-Use-Transaction-Weight-For-Ordering-Transactions-In-Blocks.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks - 2023-08-01T22:15:54.112779+00:00 - - Erik Aronesty 2017-12-07 21:39:56+00:00 - - - Damian Williamson 2017-12-07 20:49:41+00:00 - - - Damian Williamson 2017-12-07 08:13:14+00:00 - - - ZmnSCPxj 2017-12-07 06:46:08+00:00 - - - Damian Williamson 2017-12-07 06:34:39+00:00 - - - Damian Williamson 2017-12-06 09:27:30+00:00 - - - ZmnSCPxj 2017-12-06 05:46:45+00:00 - - - Jim Renkel 2017-12-06 05:18:11+00:00 - - - Damian Williamson 2017-12-03 04:07:16+00:00 - + 2025-09-26T15:52:39.505373+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks Damian Williamson + 2017-12-03T04:07:00.000Z + + + Jim Renkel + 2017-12-06T05:18:00.000Z + + + ZmnSCPxj + 2017-12-06T05:46:00.000Z + + + Damian Williamson + 2017-12-06T09:27:00.000Z + + + Damian Williamson + 2017-12-07T06:34:00.000Z + + + ZmnSCPxj + 2017-12-07T06:46:00.000Z + + + Damian Williamson + 2017-12-07T08:13:00.000Z + + + Damian Williamson + 2017-12-07T20:49:00.000Z + + + Erik Aronesty + 2017-12-07T21:39:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks - 2023-08-01T22:15:54.112779+00:00 + 2025-09-26T15:52:39.506491+00:00 - The email exchange between Damian Williamson and ZmnSCPxj on the bitcoin-dev mailing list revolves around a BIP proposal called UTWFOTIB, which stands for Use Transaction Weight For Ordering Transactions In Blocks. The discussion focuses on the idea of using the next block size to order transactions in blocks, with some concerns being raised about the feasibility of this proposal.ZmnSCPxj argues that consensus rules should restrict themselves to the characteristics of the block and its transactions, rather than depending on the transaction pool, which is not safe for any consensus rules. This point is echoed by Damian Williamson, who revises the proposal and posts it back to the mailing list.Despite the concerns raised, both parties agree that the proposal is worth considering and discussing further.In a Bitcoin Developer email thread, Damian Williamson proposed a BIP (Bitcoin Improvement Proposal) called Use Transaction Weight For Ordering Transactions In Blocks (UTWFOTIB). However, there was concern raised by ZmnSCPxj over the proposal's reliance on the transaction pool. ZmnSCPxj argued that consensus rules should only focus on the characteristics of the block and its transactions. He also pointed out that if a node is temporarily stopped, it may not have a view of the "consensus" transaction pool during that time and can only trust the longest chain.The context discusses the issue of SPV confirmation faced by a node that is temporarily stopped and restarted after some time. The node cannot verify the "consensus" transaction pool during the time it was stopped and can only trust the longest chain, which makes it an SPV for this particular rule.The email exchange between Jim Renkel and Damian Williamson discusses the recent BIP proposal, UTWFOTIB (Use Transaction Weight For Ordering Transactions In Blocks). Jim questions whether miners would follow the proposal as it is not enforceable and could be implemented on an individual basis. Damian suggests that block sizes based on transaction weight could be implemented if the transactions conform to a probability distribution curve or fee distribution curve.Damian Williamson has proposed a new BIP (Bitcoin Improvement Proposal) called UTWFOTIB, which stands for Use Transaction Weight for Ordering Transactions in Blocks. The proposal aims to maximize transaction reliability and total fees paid per block without reducing reliability. It suggests providing each transaction with a transaction weight, which is a function of the fee paid and the time waiting in the transaction pool. The transaction weight will serve as the likelihood of a transaction being included in the current block.Damian Williamson proposed a BIP (Bitcoin Improvement Proposal) called "UTWFOTIB - Use Transaction Weight for Ordering Transactions in Blocks". The proposal suggests to provide each transaction with a weight function of the fee paid and the time waiting in the transaction pool. The transaction weight would serve as the likelihood of a transaction being included in the current block and then use a target block size. The curves used for the weight of transactions would have to be appropriate.A proposal named UTWFOTIB (Use Transaction Weight For Ordering Transactions In Blocks) was put forward on the bitcoin-dev mailing list by Damian Williamson. The proposal aims to address the issue of transaction bandwidth limit, which is a limiting factor for both miners and consumers. It suggests assigning each transaction a transaction weight based on the fee paid (on a curve) and the time waiting in the transaction pool (also on a curve) out to n days (n=30 ?); the transaction weight serving as the likelihood of a transaction being included in the current block, and then using a target block size. This way, it maximizes transaction reliability, total fees paid per block, and provides additional block entropy and greater security since there is less probability of predicting the next block.The proposal, titled 'UTWFOTIB', suggests using a transaction weight for ordering transactions in blocks. The current bandwidth limit is a limiting factor for both miners and consumers, who want to maximize revenue from fees and transaction reliability respectively. The proposed solution is to provide each transaction with a transaction weight, determined by the fee paid and time waiting in the transaction pool, out to a certain number of days (possibly 30). This transaction weight will serve as the likelihood of a transaction being included in the current block, which will have a target size determined by the protocol. The curves used for the weight of transactions would have to be appropriate. The benefits of this proposal include maximizing transaction reliability, total fees paid per block, and market-determined fee paid for transaction priority. Additionally, fee recommendations work all the way out to 30 days or greater, and provides additional block entropy and greater security since there is less probability of predicting the next block. However, the proposal must first be programmed and any potential cons are yet to be identified. 2017-12-07T21:39:56+00:00 + The email exchange between Damian Williamson and ZmnSCPxj on the bitcoin-dev mailing list revolves around a BIP proposal called UTWFOTIB, which stands for Use Transaction Weight For Ordering Transactions In Blocks. The discussion focuses on the idea of using the next block size to order transactions in blocks, with some concerns being raised about the feasibility of this proposal.ZmnSCPxj argues that consensus rules should restrict themselves to the characteristics of the block and its transactions, rather than depending on the transaction pool, which is not safe for any consensus rules. This point is echoed by Damian Williamson, who revises the proposal and posts it back to the mailing list.Despite the concerns raised, both parties agree that the proposal is worth considering and discussing further.In a Bitcoin Developer email thread, Damian Williamson proposed a BIP (Bitcoin Improvement Proposal) called Use Transaction Weight For Ordering Transactions In Blocks (UTWFOTIB). However, there was concern raised by ZmnSCPxj over the proposal's reliance on the transaction pool. ZmnSCPxj argued that consensus rules should only focus on the characteristics of the block and its transactions. He also pointed out that if a node is temporarily stopped, it may not have a view of the "consensus" transaction pool during that time and can only trust the longest chain.The context discusses the issue of SPV confirmation faced by a node that is temporarily stopped and restarted after some time. The node cannot verify the "consensus" transaction pool during the time it was stopped and can only trust the longest chain, which makes it an SPV for this particular rule.The email exchange between Jim Renkel and Damian Williamson discusses the recent BIP proposal, UTWFOTIB (Use Transaction Weight For Ordering Transactions In Blocks). Jim questions whether miners would follow the proposal as it is not enforceable and could be implemented on an individual basis. Damian suggests that block sizes based on transaction weight could be implemented if the transactions conform to a probability distribution curve or fee distribution curve.Damian Williamson has proposed a new BIP (Bitcoin Improvement Proposal) called UTWFOTIB, which stands for Use Transaction Weight for Ordering Transactions in Blocks. The proposal aims to maximize transaction reliability and total fees paid per block without reducing reliability. It suggests providing each transaction with a transaction weight, which is a function of the fee paid and the time waiting in the transaction pool. The transaction weight will serve as the likelihood of a transaction being included in the current block.Damian Williamson proposed a BIP (Bitcoin Improvement Proposal) called "UTWFOTIB - Use Transaction Weight for Ordering Transactions in Blocks". The proposal suggests to provide each transaction with a weight function of the fee paid and the time waiting in the transaction pool. The transaction weight would serve as the likelihood of a transaction being included in the current block and then use a target block size. The curves used for the weight of transactions would have to be appropriate.A proposal named UTWFOTIB (Use Transaction Weight For Ordering Transactions In Blocks) was put forward on the bitcoin-dev mailing list by Damian Williamson. The proposal aims to address the issue of transaction bandwidth limit, which is a limiting factor for both miners and consumers. It suggests assigning each transaction a transaction weight based on the fee paid (on a curve) and the time waiting in the transaction pool (also on a curve) out to n days (n=30 ?); the transaction weight serving as the likelihood of a transaction being included in the current block, and then using a target block size. This way, it maximizes transaction reliability, total fees paid per block, and provides additional block entropy and greater security since there is less probability of predicting the next block.The proposal, titled 'UTWFOTIB', suggests using a transaction weight for ordering transactions in blocks. The current bandwidth limit is a limiting factor for both miners and consumers, who want to maximize revenue from fees and transaction reliability respectively. The proposed solution is to provide each transaction with a transaction weight, determined by the fee paid and time waiting in the transaction pool, out to a certain number of days (possibly 30). This transaction weight will serve as the likelihood of a transaction being included in the current block, which will have a target size determined by the protocol. The curves used for the weight of transactions would have to be appropriate. The benefits of this proposal include maximizing transaction reliability, total fees paid per block, and market-determined fee paid for transaction priority. Additionally, fee recommendations work all the way out to 30 days or greater, and provides additional block entropy and greater security since there is less probability of predicting the next block. However, the proposal must first be programmed and any potential cons are yet to be identified. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Utilization-of-bits-denomination.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Utilization-of-bits-denomination.xml index f006962ffc..7af785274a 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Utilization-of-bits-denomination.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-Proposal-Utilization-of-bits-denomination.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - BIP Proposal: Utilization of bits denomination - 2023-08-01T22:20:02.258005+00:00 - - Tamas Blummer 2017-12-24 04:26:04+00:00 - - - Rhavar 2017-12-15 18:46:45+00:00 - - - Moral Agent 2017-12-15 18:20:34+00:00 - - - Marcel Jamin 2017-12-15 06:27:10+00:00 - - - Clark Moody 2017-12-14 23:11:17+00:00 - - - Natanael 2017-12-14 22:01:09+00:00 - - - Sjors Provoost 2017-12-14 15:52:24+00:00 - - - Marcel Jamin 2017-12-14 08:02:44+00:00 - - - Daniel McNally 2017-12-13 23:00:02+00:00 - - - David A. Harding 2017-12-13 21:36:07+00:00 - - - Jimmy Song 2017-12-13 19:46:09+00:00 - + 2025-09-26T15:52:31.140795+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Utilization of bits denomination Jimmy Song + 2017-12-13T19:46:00.000Z + + + David A. Harding + 2017-12-13T21:36:00.000Z + + + Daniel McNally + 2017-12-13T23:00:00.000Z + + + Marcel Jamin + 2017-12-14T08:02:00.000Z + + + Sjors Provoost + 2017-12-14T15:52:00.000Z + + + Natanael + 2017-12-14T22:01:00.000Z + + + Clark Moody + 2017-12-14T23:11:00.000Z + + + Marcel Jamin + 2017-12-15T06:27:00.000Z + + + Moral Agent + 2017-12-15T18:20:00.000Z + + + Rhavar + 2017-12-15T18:46:00.000Z + + + Tamas Blummer + 2017-12-24T04:26:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Utilization of bits denomination - 2023-08-01T22:20:02.258005+00:00 + 2025-09-26T15:52:31.142119+00:00 - The ongoing debate about the standard unit of measurement for Bitcoin has sparked discussions among users. Some argue in favor of using "bits" as a denomination due to its compatibility with existing financial software, making integration into legacy systems easier. The simplicity and clarity of the term also appeal to users. However, others raise concerns about the potential confusion caused by homonyms within the same context.Ryan, a user who has been using "bits" on his website, believes it is a great unit that people quickly adapt to when dealing with large amounts of money. He suggests making "bits" the default unit everywhere for consistency. Ethan agrees with the use of SI prefixes but argues that the base unit should be easy for intuition to comprehend. Marcel Jamin argues for using Bitcoin (BTC), Millibitcoin (mBTC), and Microbitcoin (µBTC) as the correct units to prevent confusion for beginners.Coinbase, a popular platform, has already adopted "bits" as the default unit for over two years, which could lead to it becoming the standard due to linguistic network effects. However, Natanael raises concerns about the potential confusion caused by multiple meanings of "bits."The discussion also touches on the use of SI prefixes in Bitcoin units. One suggestion is to make 100 satoshi equal to 1 mu. The idea of using "finney" as a unit of value is also supported, with its smallest unit being 1 satoshi. Redefining "satoshi" to 10^-9 BTC is dismissed. The argument against using "bits" revolves around the confusion that could arise from its multiple meanings within the same context.A post on Reddit argues against using "bits" due to its potential confusion for beginners. The author acknowledges the interpretation of homonyms based on context but highlights the difficulty of distinguishing between different meanings of "bits" within the same context. This could cause confusion for users.David A. Harding suggests that "microbitcoins" would be a better denomination than "bits." He argues that "microbitcoins" is not a homonym for any other word and emphasizes the importance of training users to understand SI prefixes. The shift to "bits" as the standard unit may happen eventually, but the major Bitcoin denomination is likely to remain.The proposal to standardize the term "bits" has received mixed responses. Some see it as a practical solution, while others find it unnecessary and confusing. The use of "microbitcoins" is suggested to train users in understanding SI prefixes. However, some prefer terms that are easy to grasp immediately. The potential need for a new term and hard fork if bitcoin prices rise significantly is also discussed.Jimmy Song proposes a BIP to standardize the term "bits" within the Bitcoin ecosystem. The motivation behind this proposal is to facilitate comprehension as the price of bitcoin grows. Using "bits" instead of satoshis or milli-bitcoin reduces user error on small amounts and allows for easier comparisons of prices with fiat currencies. The proposal suggests displaying all Bitcoin-denominated items in bits. The specification defines 1 bit as 1/1,000,000 bitcoin and pluralizes "bit" as "bits." Existing terms such as satoshi and milli-bitcoin do not conflict and can coexist with "bits."In conclusion, the debate about the standard unit of measurement for Bitcoin continues. The use of "bits" has both practical benefits and potential confusion concerns. Users have different perspectives on the matter, with some advocating for "bits" and others suggesting alternatives like microbitcoins. The proposal to standardize "bits" has gained attention, highlighting its advantages in simplifying comprehension and facilitating comparisons. 2017-12-24T04:26:04+00:00 + The ongoing debate about the standard unit of measurement for Bitcoin has sparked discussions among users. Some argue in favor of using "bits" as a denomination due to its compatibility with existing financial software, making integration into legacy systems easier. The simplicity and clarity of the term also appeal to users. However, others raise concerns about the potential confusion caused by homonyms within the same context.Ryan, a user who has been using "bits" on his website, believes it is a great unit that people quickly adapt to when dealing with large amounts of money. He suggests making "bits" the default unit everywhere for consistency. Ethan agrees with the use of SI prefixes but argues that the base unit should be easy for intuition to comprehend. Marcel Jamin argues for using Bitcoin (BTC), Millibitcoin (mBTC), and Microbitcoin (µBTC) as the correct units to prevent confusion for beginners.Coinbase, a popular platform, has already adopted "bits" as the default unit for over two years, which could lead to it becoming the standard due to linguistic network effects. However, Natanael raises concerns about the potential confusion caused by multiple meanings of "bits."The discussion also touches on the use of SI prefixes in Bitcoin units. One suggestion is to make 100 satoshi equal to 1 mu. The idea of using "finney" as a unit of value is also supported, with its smallest unit being 1 satoshi. Redefining "satoshi" to 10^-9 BTC is dismissed. The argument against using "bits" revolves around the confusion that could arise from its multiple meanings within the same context.A post on Reddit argues against using "bits" due to its potential confusion for beginners. The author acknowledges the interpretation of homonyms based on context but highlights the difficulty of distinguishing between different meanings of "bits" within the same context. This could cause confusion for users.David A. Harding suggests that "microbitcoins" would be a better denomination than "bits." He argues that "microbitcoins" is not a homonym for any other word and emphasizes the importance of training users to understand SI prefixes. The shift to "bits" as the standard unit may happen eventually, but the major Bitcoin denomination is likely to remain.The proposal to standardize the term "bits" has received mixed responses. Some see it as a practical solution, while others find it unnecessary and confusing. The use of "microbitcoins" is suggested to train users in understanding SI prefixes. However, some prefer terms that are easy to grasp immediately. The potential need for a new term and hard fork if bitcoin prices rise significantly is also discussed.Jimmy Song proposes a BIP to standardize the term "bits" within the Bitcoin ecosystem. The motivation behind this proposal is to facilitate comprehension as the price of bitcoin grows. Using "bits" instead of satoshis or milli-bitcoin reduces user error on small amounts and allows for easier comparisons of prices with fiat currencies. The proposal suggests displaying all Bitcoin-denominated items in bits. The specification defines 1 bit as 1/1,000,000 bitcoin and pluralizes "bit" as "bits." Existing terms such as satoshi and milli-bitcoin do not conflict and can coexist with "bits."In conclusion, the debate about the standard unit of measurement for Bitcoin continues. The use of "bits" has both practical benefits and potential confusion concerns. Users have different perspectives on the matter, with some advocating for "bits" and others suggesting alternatives like microbitcoins. The proposal to standardize "bits" has gained attention, highlighting its advantages in simplifying comprehension and facilitating comparisons. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_BIP-for-Legacy-Sign-Verify-functions.xml b/static/bitcoin-dev/Dec_2017/combined_BIP-for-Legacy-Sign-Verify-functions.xml index 6103144aad..878e8aec74 100644 --- a/static/bitcoin-dev/Dec_2017/combined_BIP-for-Legacy-Sign-Verify-functions.xml +++ b/static/bitcoin-dev/Dec_2017/combined_BIP-for-Legacy-Sign-Verify-functions.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - BIP for Legacy Sign Verify functions - 2023-08-01T22:22:15.251919+00:00 - - Aymeric Vitte 2017-12-22 23:06:20+00:00 - - - Aymeric Vitte 2017-12-22 10:29:13+00:00 - - - Dan Bryant 2017-12-21 23:21:24+00:00 - - - Luke Dashjr 2017-12-21 23:09:05+00:00 - - - Dan Bryant 2017-12-21 22:26:25+00:00 - + 2025-09-26T15:52:26.968954+00:00 + python-feedgen + + + [bitcoin-dev] BIP for Legacy Sign Verify functions Dan Bryant + 2017-12-21T22:26:00.000Z + + + Luke Dashjr + 2017-12-21T23:09:00.000Z + + + Dan Bryant + 2017-12-21T23:21:00.000Z + + + Aymeric Vitte + 2017-12-22T10:29:00.000Z + + + Aymeric Vitte + 2017-12-22T23:06:00.000Z + + - python-feedgen + 2 Combined summary - BIP for Legacy Sign Verify functions - 2023-08-01T22:22:15.252884+00:00 + 2025-09-26T15:52:26.969694+00:00 - In a discussion on the bitcoin-dev mailing list, Luke Dashjr raises questions about the use of signatures and public keys in Bitcoin transactions. He explains how key recovery is performed using the signature and message to extract the public key of the signer, which is then hashed and compared to the provided address. Aymeric Vitte also questions the role of pubkey in sigscript for standard p2pkh transactions.Luke Dashjr criticizes a proposal to enhance the Bitcoin Improvement Proposal (BIP) by providing a reference point for new address schemes. He argues that it is impossible to get a public key from an address and suggests that new schemes should not be based on the current one.Dan Bryant also criticizes a proposed BIP by Brian Deery, which suggests deriving a public key from a Bitcoin address. Bryant claims that this is incorrect and highlights that key recovery is used to extract the public key of the signer for comparison.The proposal for expanding capabilities into new address schemes is put forward by brianddk. Although the functionality of signing or verifying messages against SegWit P2SH addresses has been established, it has not yet been published in a BIP. The aim of the proposal is to provide a reference point for future expansion.Aymeric Vitte has shared various links related to simplifying Bitcoin transactions, Zcash wallets, Bitcoin wallets on GitHub, torrent dynamic blocklists, anti-spies and private torrents, and peersm. The original reference thread for the proposal can be found at the provided link. 2017-12-22T23:06:20+00:00 + In a discussion on the bitcoin-dev mailing list, Luke Dashjr raises questions about the use of signatures and public keys in Bitcoin transactions. He explains how key recovery is performed using the signature and message to extract the public key of the signer, which is then hashed and compared to the provided address. Aymeric Vitte also questions the role of pubkey in sigscript for standard p2pkh transactions.Luke Dashjr criticizes a proposal to enhance the Bitcoin Improvement Proposal (BIP) by providing a reference point for new address schemes. He argues that it is impossible to get a public key from an address and suggests that new schemes should not be based on the current one.Dan Bryant also criticizes a proposed BIP by Brian Deery, which suggests deriving a public key from a Bitcoin address. Bryant claims that this is incorrect and highlights that key recovery is used to extract the public key of the signer for comparison.The proposal for expanding capabilities into new address schemes is put forward by brianddk. Although the functionality of signing or verifying messages against SegWit P2SH addresses has been established, it has not yet been published in a BIP. The aim of the proposal is to provide a reference point for future expansion.Aymeric Vitte has shared various links related to simplifying Bitcoin transactions, Zcash wallets, Bitcoin wallets on GitHub, torrent dynamic blocklists, anti-spies and private torrents, and peersm. The original reference thread for the proposal can be found at the provided link. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Clarification-about-SegWit-transaction-size-and-bech32.xml b/static/bitcoin-dev/Dec_2017/combined_Clarification-about-SegWit-transaction-size-and-bech32.xml index 27f1cffb56..3ba4720d1d 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Clarification-about-SegWit-transaction-size-and-bech32.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Clarification-about-SegWit-transaction-size-and-bech32.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Clarification about SegWit transaction size and bech32 - 2023-08-01T22:20:36.656332+00:00 - - Alberto De Luigi 2017-12-19 13:45:09+00:00 - - - mail at albertodeluigi.com 2017-12-18 22:19:34+00:00 - - - Mark Friedenbach 2017-12-18 22:03:44+00:00 - - - mail at albertodeluigi.com 2017-12-18 21:41:18+00:00 - - - Mark Friedenbach 2017-12-18 17:38:01+00:00 - - - Alberto De Luigi 2017-12-18 16:40:08+00:00 - + 2025-09-26T15:52:47.932587+00:00 + python-feedgen + + + [bitcoin-dev] Clarification about SegWit transaction size and bech32 Alberto De Luigi + 2017-12-18T16:40:00.000Z + + + Mark Friedenbach + 2017-12-18T17:38:00.000Z + + + mail + 2017-12-18T21:41:00.000Z + + + Mark Friedenbach + 2017-12-18T22:03:00.000Z + + + mail + 2017-12-18T22:19:00.000Z + + + Alberto De Luigi + 2017-12-19T13:45:00.000Z + + - python-feedgen + 2 Combined summary - Clarification about SegWit transaction size and bech32 - 2023-08-01T22:20:36.656332+00:00 + 2025-09-26T15:52:47.933297+00:00 - The discussion revolves around the benefits and drawbacks of Segregated Witness (SegWit) and bech32 address formats in Bitcoin transactions. Gregory Maxwell explains that ordinary P2WPKH transactions have less weight than P2PHK, while SegWit transactions like P2WSH and P2WSH/P2SH cost more space compared to P2SH. Alberto De Luigi argues that exchanges have no incentive to adopt SegWit as it increases blockchain weight without saving space or offering cheaper fees. Bech32, on the other hand, can save up to 22% of space and could help scale Bitcoin with coordination among wallets.The conversation between Alberto De Luigi and Mark Friedenbach focuses on the adoption of SegWit and the concerns surrounding it. Alberto questions the usability of bech32 addresses and their recognition by certain software. Mark clarifies that the recipient has control over which payment script is used, and bech32 addresses offer better security guarantees or lower fees. Alberto also raises concerns about the increased block weight and lack of incentives for exchanges to adopt SegWit. He suggests a hard fork upgrade to bech32 along with a 2x block size increase to promote SegWit adoption and test the Lightning Network (LN). The conversation emphasizes the need for consensus among the community for coordinated upgrades.In the email thread on the bitcoin-dev mailing list, Alberto asks about the transaction size of SegWit. Mark explains that addresses are a user-interface issue and changing them does not constitute a fork in the bitcoin protocol. He highlights the benefits of bech32 addresses and the potential to reduce fees and improve security. Alberto expresses concerns about exchanges' reluctance to adopt SegWit due to increased block weight and lack of incentives. He suggests a hard fork upgrade to bech32 alongside a block size increase to enforce adoption. The email includes links to resources discussing the benefits and costs of SegWit adoption and different address formats.The email exchange also discusses the technical aspects of SegWit adoption. Mark explains that addresses are a UI convention and do not affect the bitcoin protocol. He suggests that bech32 addresses offer better security or lower fees compared to older address formats. Alberto raises concerns about SegWit adoption by exchanges, particularly regarding transactions with multiple outputs. While SegWit can save space and reduce fees in some cases, it may not be beneficial for all transaction types. Alberto suggests a coordinated upgrade to bech32 combined with a block size increase as a solution to promote SegWit adoption. The email thread includes links to further information on the benefits and costs of SegWit adoption and different address formats.Overall, the discussions highlight the complexity of SegWit adoption and the need for consensus among the Bitcoin community. The use of bech32 addresses is seen as a potential solution to improve scalability and promote SegWit adoption, but compatibility issues and the need for coordinated upgrades pose challenges. The provided links offer additional resources on the technical aspects and benefits of SegWit adoption. 2017-12-19T13:45:09+00:00 + The discussion revolves around the benefits and drawbacks of Segregated Witness (SegWit) and bech32 address formats in Bitcoin transactions. Gregory Maxwell explains that ordinary P2WPKH transactions have less weight than P2PHK, while SegWit transactions like P2WSH and P2WSH/P2SH cost more space compared to P2SH. Alberto De Luigi argues that exchanges have no incentive to adopt SegWit as it increases blockchain weight without saving space or offering cheaper fees. Bech32, on the other hand, can save up to 22% of space and could help scale Bitcoin with coordination among wallets.The conversation between Alberto De Luigi and Mark Friedenbach focuses on the adoption of SegWit and the concerns surrounding it. Alberto questions the usability of bech32 addresses and their recognition by certain software. Mark clarifies that the recipient has control over which payment script is used, and bech32 addresses offer better security guarantees or lower fees. Alberto also raises concerns about the increased block weight and lack of incentives for exchanges to adopt SegWit. He suggests a hard fork upgrade to bech32 along with a 2x block size increase to promote SegWit adoption and test the Lightning Network (LN). The conversation emphasizes the need for consensus among the community for coordinated upgrades.In the email thread on the bitcoin-dev mailing list, Alberto asks about the transaction size of SegWit. Mark explains that addresses are a user-interface issue and changing them does not constitute a fork in the bitcoin protocol. He highlights the benefits of bech32 addresses and the potential to reduce fees and improve security. Alberto expresses concerns about exchanges' reluctance to adopt SegWit due to increased block weight and lack of incentives. He suggests a hard fork upgrade to bech32 alongside a block size increase to enforce adoption. The email includes links to resources discussing the benefits and costs of SegWit adoption and different address formats.The email exchange also discusses the technical aspects of SegWit adoption. Mark explains that addresses are a UI convention and do not affect the bitcoin protocol. He suggests that bech32 addresses offer better security or lower fees compared to older address formats. Alberto raises concerns about SegWit adoption by exchanges, particularly regarding transactions with multiple outputs. While SegWit can save space and reduce fees in some cases, it may not be beneficial for all transaction types. Alberto suggests a coordinated upgrade to bech32 combined with a block size increase as a solution to promote SegWit adoption. The email thread includes links to further information on the benefits and costs of SegWit adoption and different address formats.Overall, the discussions highlight the complexity of SegWit adoption and the need for consensus among the Bitcoin community. The use of bech32 addresses is seen as a potential solution to improve scalability and promote SegWit adoption, but compatibility issues and the need for coordinated upgrades pose challenges. The provided links offer additional resources on the technical aspects and benefits of SegWit adoption. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Ivy-a-higher-level-language-targeting-Bitcoin-Script.xml b/static/bitcoin-dev/Dec_2017/combined_Ivy-a-higher-level-language-targeting-Bitcoin-Script.xml index e9fb349997..ec91925b7a 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Ivy-a-higher-level-language-targeting-Bitcoin-Script.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Ivy-a-higher-level-language-targeting-Bitcoin-Script.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Ivy: a higher-level language targeting Bitcoin Script - 2023-08-01T22:20:46.287366+00:00 - - Daniel Robinson 2018-01-15 22:39:05+00:00 - - - Matt Corallo 2018-01-14 22:41:55+00:00 - - - Daniel Robinson 2017-12-18 20:32:17+00:00 - + 2025-09-26T15:52:22.786320+00:00 + python-feedgen + + + [bitcoin-dev] Ivy: a higher-level language targeting Bitcoin Script Daniel Robinson + 2017-12-18T20:32:00.000Z + + + Matt Corallo + 2018-01-14T22:41:00.000Z + + + Daniel Robinson + 2018-01-15T22:39:00.000Z + + - python-feedgen + 2 Combined summary - Ivy: a higher-level language targeting Bitcoin Script - 2023-08-01T22:20:46.287366+00:00 + 2025-09-26T15:52:22.786885+00:00 - The Ivy team has released a prototype higher-level language and development environment called Ivy for creating custom Bitcoin Script programs. Ivy aims to improve the usability of Bitcoin Script by adding features like named variables and clauses, static types, and a familiar syntax for function calls. It is a simple smart contract language that can compile to Bitcoin Script. However, there was an issue with how the compiler was handling clause selection that led to a minor witness malleability problem. This problem has been fixed in version 0.0.7 of the compiler. To prevent witness malleability, a user suggested adding some form of compiler-time enforcement, but the team believes it would be easier to build a static analyzer for low-level Bitcoin Script.Ivy is currently a prototype software intended for educational and research purposes only. It should not be used to control real or testnet Bitcoins. The Ivy Playground for Bitcoin allows users to create and test simulated contracts in a sandboxed environment. By providing a higher-level language and development environment, Ivy offers a more user-friendly approach to writing Bitcoin scripts and potentially resolving witness malleability issues. 2018-01-15T22:39:05+00:00 + The Ivy team has released a prototype higher-level language and development environment called Ivy for creating custom Bitcoin Script programs. Ivy aims to improve the usability of Bitcoin Script by adding features like named variables and clauses, static types, and a familiar syntax for function calls. It is a simple smart contract language that can compile to Bitcoin Script. However, there was an issue with how the compiler was handling clause selection that led to a minor witness malleability problem. This problem has been fixed in version 0.0.7 of the compiler. To prevent witness malleability, a user suggested adding some form of compiler-time enforcement, but the team believes it would be easier to build a static analyzer for low-level Bitcoin Script.Ivy is currently a prototype software intended for educational and research purposes only. It should not be used to control real or testnet Bitcoins. The Ivy Playground for Bitcoin allows users to create and test simulated contracts in a sandboxed environment. By providing a higher-level language and development environment, Ivy offers a more user-friendly approach to writing Bitcoin scripts and potentially resolving witness malleability issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Scalable-Semi-Trustless-Asset-Transfer-via-Single-Use-Seals-and-Proof-of-Publication.xml b/static/bitcoin-dev/Dec_2017/combined_Scalable-Semi-Trustless-Asset-Transfer-via-Single-Use-Seals-and-Proof-of-Publication.xml index 707c3b912c..d34bb06bba 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Scalable-Semi-Trustless-Asset-Transfer-via-Single-Use-Seals-and-Proof-of-Publication.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Scalable-Semi-Trustless-Asset-Transfer-via-Single-Use-Seals-and-Proof-of-Publication.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication - 2023-08-01T22:16:15.958018+00:00 - - Peter Todd 2017-12-11 23:16:19+00:00 - - - Pulat Yunusov 2017-12-11 22:23:21+00:00 - - - Peter Todd 2017-12-05 10:15:51+00:00 - + 2025-09-26T15:52:37.414006+00:00 + python-feedgen + + + [bitcoin-dev] Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication Peter Todd + 2017-12-05T10:15:00.000Z + + + Pulat Yunusov + 2017-12-11T22:23:00.000Z + + + Peter Todd + 2017-12-11T23:16:00.000Z + + - python-feedgen + 2 Combined summary - Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication - 2023-08-01T22:16:15.958018+00:00 + 2025-09-26T15:52:37.414551+00:00 - In a Bitcoin development email thread, Peter Todd discusses the centralization and decentralization aspects of proof-of-publication (PoP) sidechains. He points out that the centralized version of PoP is easier to maintain and scale, as more hardware can be added and the key space can be distributed over multiple shards. However, this simplicity comes at the cost of trust, as valid trees and distributed results need to be ensured without trust. Peter Todd's previous work on Treechains attempts to address this issue, but it remains a significantly more difficult problem.Peter Todd proposes a system of secure token transfers using single-use-seals. The system relies on the unique closing of a seal over a message to prevent double-spends. Single-use-seals are generated by a trusted notary, with each seal committing to the notary's identity through cryptographic signatures. The system can be used for both indivisible and divisible asset transfers. In the case of divisible assets, spend commitments are made to sets of outputs, and split commitments are made to sets of zero or seal/value tuples. The recipient can verify the secure transfer by generating a fresh seal, requesting a new split output from the sender, and confirming its validity.To achieve scalability, a proof-of-publication ledger can be utilized. This ledger achieves consensus over its state through a second implementation of single-use-seals. The size of data required for ownership proof in a trustless manner is discussed, with the merkle path down the k/v tree and key/value components amounting to approximately 3KB per ledger. The update rate is estimated at 356 days per year with 12 updates per day, resulting in 13MB of data annually. However, these numbers can be reduced by publishing only valid signatures or assuming no constant attacks. Furthermore, for clients with multiple tokens, much of the data can be shared among each token, reducing the marginal cost per token after the first one to just 1KB/ledger update, or 4.4MB/year.The author presents a worked example of a scalable and trust-minimized system using a proof-of-publication ledger and single-use-seals for secure transfer of indivisible and divisible assets. The implementation supports two fundamental operations: Close and Verify. A secure single-use-seal protocol prevents double-spending by disallowing the closure of a single seal over multiple messages. To achieve scalability, the protocol commits to a merkelized key:value tree instead of unstructured messages in each ledger entry. Each token is identified by its genesis seal, and the most recent seal is closed over a message committing to a new seal. An actual implementation can use a merkle-sum-tree to commit to the split set, allowing outputs to be proven to the recipient by providing only a single branch of the tree. The marginal cost per token after the first one is just 1KB/ledger update, resulting in 4.4MB/year, which is favorable for many use cases. 2017-12-11T23:16:19+00:00 + In a Bitcoin development email thread, Peter Todd discusses the centralization and decentralization aspects of proof-of-publication (PoP) sidechains. He points out that the centralized version of PoP is easier to maintain and scale, as more hardware can be added and the key space can be distributed over multiple shards. However, this simplicity comes at the cost of trust, as valid trees and distributed results need to be ensured without trust. Peter Todd's previous work on Treechains attempts to address this issue, but it remains a significantly more difficult problem.Peter Todd proposes a system of secure token transfers using single-use-seals. The system relies on the unique closing of a seal over a message to prevent double-spends. Single-use-seals are generated by a trusted notary, with each seal committing to the notary's identity through cryptographic signatures. The system can be used for both indivisible and divisible asset transfers. In the case of divisible assets, spend commitments are made to sets of outputs, and split commitments are made to sets of zero or seal/value tuples. The recipient can verify the secure transfer by generating a fresh seal, requesting a new split output from the sender, and confirming its validity.To achieve scalability, a proof-of-publication ledger can be utilized. This ledger achieves consensus over its state through a second implementation of single-use-seals. The size of data required for ownership proof in a trustless manner is discussed, with the merkle path down the k/v tree and key/value components amounting to approximately 3KB per ledger. The update rate is estimated at 356 days per year with 12 updates per day, resulting in 13MB of data annually. However, these numbers can be reduced by publishing only valid signatures or assuming no constant attacks. Furthermore, for clients with multiple tokens, much of the data can be shared among each token, reducing the marginal cost per token after the first one to just 1KB/ledger update, or 4.4MB/year.The author presents a worked example of a scalable and trust-minimized system using a proof-of-publication ledger and single-use-seals for secure transfer of indivisible and divisible assets. The implementation supports two fundamental operations: Close and Verify. A secure single-use-seal protocol prevents double-spending by disallowing the closure of a single seal over multiple messages. To achieve scalability, the protocol commits to a merkelized key:value tree instead of unstructured messages in each ledger entry. Each token is identified by its genesis seal, and the most recent seal is closed over a message committing to a new seal. An actual implementation can use a merkle-sum-tree to commit to the split set, allowing outputs to be proven to the recipient by providing only a single branch of the tree. The marginal cost per token after the first one is just 1KB/ledger update, resulting in 4.4MB/year, which is favorable for many use cases. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Sign-Verify-message-against-SegWit-P2SH-addresses-.xml b/static/bitcoin-dev/Dec_2017/combined_Sign-Verify-message-against-SegWit-P2SH-addresses-.xml index 46ac1dab85..a22b8b637b 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Sign-Verify-message-against-SegWit-P2SH-addresses-.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Sign-Verify-message-against-SegWit-P2SH-addresses-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Sign / Verify message against SegWit P2SH addresses. - 2023-08-01T22:19:18.005776+00:00 - - Dan Bryant 2017-12-21 22:22:58+00:00 - - - Jason Dreyzehner 2017-12-21 17:23:49+00:00 - - - Mark Friedenbach 2017-12-21 16:29:13+00:00 - - - Damian Williamson 2017-12-21 11:19:52+00:00 - - - Mark Friedenbach 2017-12-19 21:58:40+00:00 - - - Pavol Rusnak 2017-12-19 21:36:45+00:00 - - - Sjors Provoost 2017-12-09 12:57:52+00:00 - - - Dan Bryant 2017-12-08 18:25:47+00:00 - + 2025-09-26T15:52:43.718921+00:00 + python-feedgen + + + [bitcoin-dev] Sign / Verify message against SegWit P2SH addresses Dan Bryant + 2017-12-08T18:25:00.000Z + + + Sjors Provoost + 2017-12-09T12:57:00.000Z + + + Pavol Rusnak + 2017-12-19T21:36:00.000Z + + + Mark Friedenbach + 2017-12-19T21:58:00.000Z + + + Damian Williamson + 2017-12-21T11:19:00.000Z + + + Mark Friedenbach + 2017-12-21T16:29:00.000Z + + + Jason Dreyzehner + 2017-12-21T17:23:00.000Z + + + Dan Bryant + 2017-12-21T22:22:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Sign / Verify message against SegWit P2SH addresses. - 2023-08-01T22:19:18.005776+00:00 + 2025-09-26T15:52:43.719936+00:00 - On December 19, 2017, Pavol Rusnak inquired about the progress of a proposed BIP for Sign/Verify message against a SegWit address. The request was made to Dan Bryant via bitcoin-dev mailing list. An early draft for the same was available on Github as well. No further information was provided regarding the status or progress of the BIP.A proposal has been made to improve the message signing system by using an actual Bitcoin transaction with inputs that have the script being signed. This would allow for signing by any infrastructure that supports FORKID signing, including hardware wallets and 2FA signing services, and would also generalize the message signing to allow for multi-party signing setups as complicated as those allowed by Bitcoin transactions. The proposal also suggests that this approach would unify a single approach for message signing, proof of reserve, and off-chain colored coins. Mark Friedenbach made this proposal and noted that there is an issue of size efficiency, but suggested that it could be handled by a BIP specifying a template for constructing the pseudo-transaction and its inputs from a raw script. Pavol Rusnak had previously asked if anyone was writing a BIP for Sign/Verify message against a SegWit address, but it is unclear if this proposal addresses that specifically.The discussion in the Bitcoin-dev mailing list revolves around the signing of messages, specifically against SegWit P2SH addresses. Damian Williamson expresses his opinion that signing a message is an important feature regardless of the method used. He suggests updating it for SegWit addresses while retaining its current simplicity. Another member, Mark Friedenbach, proposes a solution that involves having the signature be an actual bitcoin transaction with inputs that have the script being signed. This would enable signing by any existing infrastructure and allow multi-party signing setups using Partially Signed Bitcoin Transactions. The proposal also unifies a single approach for message signing, proof of reserve, and off-chain colored coins. Dan Bryant asks if anyone is writing a BIP for Sign/Verify message against a SegWit address, to which Pavol Rusnak asks if he is still planning to write it.Damian Williamson suggests that signing a message is an important feature whether it is with Bitcoin Core or some other method. He believes that it would be worthwhile to update it for SegWit addresses. A signed message helps to verify that the message is indeed what was said. In response to a query by Pavol Rusnak about writing a BIP for Sign/Verify message against a SegWit address, Mark Friedenbach suggests a solution for message signing. Instead of rejiggering the message signing system to support non-P2PKH scripts, he proposes that the signature be an actual bitcoin transaction with inputs that have the script being signed. This approach has several benefits like enabling signing by any infrastructure out there, allowing multi-party signing setups, and unifying a single approach for message signing, proof of reserve and off-chain colored coins. While there is an issue of size efficiency, this can be handled by a BIP that specifies a template for constructing the pseudo-transaction and its inputs from a raw script.A recent post on the Bitcoin-dev mailing list discusses the possibility of improving message signing protocols to support non-P2PKH scripts. The author suggests using an actual bitcoin transaction with inputs that have the script being signed and using the salted hash of the message being signed as the FORKID for spin-off with replay protection. This approach would enable signing by any infrastructure out there, including hardware wallets and 2FA signing services, that have enabled support for FORKID signing. It also generalizes the message signing to allow multi-party signing setups and unifies a single approach for message signing, proof of reserve, and off-chain colored coins. Although there's an issue of size efficiency, a BIP can specify a template for constructing the pseudo-transaction and its inputs from a raw script for the single-party message signing application. Finally, the discussion thread asks if anyone is writing a BIP for Sign/Verify message against a SegWit address, which remains unanswered.A member of the bitcoin-dev mailing list, Dan Bryant, inquired about any developments towards a BIP for signing or verifying messages against SegWit addresses. This query was made on 08/12/17 at 19:25 and received a response from Pavol Rusnak, CTO of SatoshiLabs. Pavol asked if Dan still intended to write this BIP. This inquiry is related to the development of Bitcoin Improvement Proposals that suggest new features or changes to the Bitcoin protocol.The post discusses the need for a BIP for Sign/Verify message against a SegWit address, specifically for P2SH-PWPKH and/or native SegWit bech32 addresses. The author suggests that such functionality is important in scenarios where proof of assets is needed, or for cases where a person needs to prove that they are in charge 2017-12-21T22:22:58+00:00 + On December 19, 2017, Pavol Rusnak inquired about the progress of a proposed BIP for Sign/Verify message against a SegWit address. The request was made to Dan Bryant via bitcoin-dev mailing list. An early draft for the same was available on Github as well. No further information was provided regarding the status or progress of the BIP.A proposal has been made to improve the message signing system by using an actual Bitcoin transaction with inputs that have the script being signed. This would allow for signing by any infrastructure that supports FORKID signing, including hardware wallets and 2FA signing services, and would also generalize the message signing to allow for multi-party signing setups as complicated as those allowed by Bitcoin transactions. The proposal also suggests that this approach would unify a single approach for message signing, proof of reserve, and off-chain colored coins. Mark Friedenbach made this proposal and noted that there is an issue of size efficiency, but suggested that it could be handled by a BIP specifying a template for constructing the pseudo-transaction and its inputs from a raw script. Pavol Rusnak had previously asked if anyone was writing a BIP for Sign/Verify message against a SegWit address, but it is unclear if this proposal addresses that specifically.The discussion in the Bitcoin-dev mailing list revolves around the signing of messages, specifically against SegWit P2SH addresses. Damian Williamson expresses his opinion that signing a message is an important feature regardless of the method used. He suggests updating it for SegWit addresses while retaining its current simplicity. Another member, Mark Friedenbach, proposes a solution that involves having the signature be an actual bitcoin transaction with inputs that have the script being signed. This would enable signing by any existing infrastructure and allow multi-party signing setups using Partially Signed Bitcoin Transactions. The proposal also unifies a single approach for message signing, proof of reserve, and off-chain colored coins. Dan Bryant asks if anyone is writing a BIP for Sign/Verify message against a SegWit address, to which Pavol Rusnak asks if he is still planning to write it.Damian Williamson suggests that signing a message is an important feature whether it is with Bitcoin Core or some other method. He believes that it would be worthwhile to update it for SegWit addresses. A signed message helps to verify that the message is indeed what was said. In response to a query by Pavol Rusnak about writing a BIP for Sign/Verify message against a SegWit address, Mark Friedenbach suggests a solution for message signing. Instead of rejiggering the message signing system to support non-P2PKH scripts, he proposes that the signature be an actual bitcoin transaction with inputs that have the script being signed. This approach has several benefits like enabling signing by any infrastructure out there, allowing multi-party signing setups, and unifying a single approach for message signing, proof of reserve and off-chain colored coins. While there is an issue of size efficiency, this can be handled by a BIP that specifies a template for constructing the pseudo-transaction and its inputs from a raw script.A recent post on the Bitcoin-dev mailing list discusses the possibility of improving message signing protocols to support non-P2PKH scripts. The author suggests using an actual bitcoin transaction with inputs that have the script being signed and using the salted hash of the message being signed as the FORKID for spin-off with replay protection. This approach would enable signing by any infrastructure out there, including hardware wallets and 2FA signing services, that have enabled support for FORKID signing. It also generalizes the message signing to allow multi-party signing setups and unifies a single approach for message signing, proof of reserve, and off-chain colored coins. Although there's an issue of size efficiency, a BIP can specify a template for constructing the pseudo-transaction and its inputs from a raw script for the single-party message signing application. Finally, the discussion thread asks if anyone is writing a BIP for Sign/Verify message against a SegWit address, which remains unanswered.A member of the bitcoin-dev mailing list, Dan Bryant, inquired about any developments towards a BIP for signing or verifying messages against SegWit addresses. This query was made on 08/12/17 at 19:25 and received a response from Pavol Rusnak, CTO of SatoshiLabs. Pavol asked if Dan still intended to write this BIP. This inquiry is related to the development of Bitcoin Improvement Proposals that suggest new features or changes to the Bitcoin protocol.The post discusses the need for a BIP for Sign/Verify message against a SegWit address, specifically for P2SH-PWPKH and/or native SegWit bech32 addresses. The author suggests that such functionality is important in scenarios where proof of assets is needed, or for cases where a person needs to prove that they are in charge - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Single-signature-for-all-transactions-in-a-block-.xml b/static/bitcoin-dev/Dec_2017/combined_Single-signature-for-all-transactions-in-a-block-.xml index 6115d6c7c7..9c120d2a94 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Single-signature-for-all-transactions-in-a-block-.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Single-signature-for-all-transactions-in-a-block-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Single signature for all transactions in a block? - 2023-08-01T22:23:07.765645+00:00 - - Rhavar 2017-12-31 23:49:15+00:00 - - - Bryan Bishop 2017-12-31 23:46:57+00:00 - - - CANNON 2017-12-31 23:39:17+00:00 - + 2025-09-26T15:52:54.200238+00:00 + python-feedgen + + + [bitcoin-dev] Single signature for all transactions in a block? CANNON + 2017-12-31T23:39:00.000Z + + + Bryan Bishop + 2017-12-31T23:46:00.000Z + + + Rhavar + 2017-12-31T23:49:00.000Z + + - python-feedgen + 2 Combined summary - Single signature for all transactions in a block? - 2023-08-01T22:23:07.765645+00:00 + 2025-09-26T15:52:54.200833+00:00 - In a post on the Bitcoin Protocol Discussion mailing list, a user raised a question about potential scaling and privacy improvements in Bitcoin. They proposed combining SegWit, aggregated signatures, and coinjoin to achieve these enhancements. The idea is to utilize aggregated signatures in conjunction with coinjoin, resulting in all inputs of a coinjoin transaction having a single signature. This approach would significantly reduce the size of the transaction and also provide privacy.The user wanted clarification on whether the extra blockspace made possible by SegWit is limited only to witness data or if it can also be used for transaction data, as described in their proposed scenario. To understand this, it's important to shift the focus from a block size limit to a block weight limit. A block must have a weight of less than 4 million, without separate limits for different types of data. Therefore, any savings in the witness space, such as through signature aggregation, would benefit both witness and non-witness data.Following this discussion, an email was sent to bitcoin-dev by CANNON, who echoed the same concerns about scaling and privacy enhancements. They suggested that combining SegWit with aggregated signatures and coinjoin could potentially address these issues. The use of aggregated signatures with coinjoin would result in a single signature for all inputs of a coinjoin transaction, leading to decreased transaction size while maintaining privacy. If a majority of transactions in a block adopted this approach, more transactions could fit into a block.To support their point, resources were provided by Bryan, including links to transcripts and articles related to signature aggregation, scalability, Schnorr signatures, and secp256k1. These additional resources offer further insights and information for those interested in understanding the proposed solutions.In conclusion, the user's inquiry on the Bitcoin Protocol Discussion mailing list and the subsequent email to bitcoin-dev highlight the potential benefits of combining SegWit, aggregated signatures, and coinjoin to improve scaling and privacy in Bitcoin transactions. The use of aggregated signatures with coinjoin would reduce transaction size, while the extra blockspace made possible by SegWit would benefit both witness and non-witness data. Additional resources provided by Bryan offer further exploration of the proposed solutions. 2017-12-31T23:49:15+00:00 + In a post on the Bitcoin Protocol Discussion mailing list, a user raised a question about potential scaling and privacy improvements in Bitcoin. They proposed combining SegWit, aggregated signatures, and coinjoin to achieve these enhancements. The idea is to utilize aggregated signatures in conjunction with coinjoin, resulting in all inputs of a coinjoin transaction having a single signature. This approach would significantly reduce the size of the transaction and also provide privacy.The user wanted clarification on whether the extra blockspace made possible by SegWit is limited only to witness data or if it can also be used for transaction data, as described in their proposed scenario. To understand this, it's important to shift the focus from a block size limit to a block weight limit. A block must have a weight of less than 4 million, without separate limits for different types of data. Therefore, any savings in the witness space, such as through signature aggregation, would benefit both witness and non-witness data.Following this discussion, an email was sent to bitcoin-dev by CANNON, who echoed the same concerns about scaling and privacy enhancements. They suggested that combining SegWit with aggregated signatures and coinjoin could potentially address these issues. The use of aggregated signatures with coinjoin would result in a single signature for all inputs of a coinjoin transaction, leading to decreased transaction size while maintaining privacy. If a majority of transactions in a block adopted this approach, more transactions could fit into a block.To support their point, resources were provided by Bryan, including links to transcripts and articles related to signature aggregation, scalability, Schnorr signatures, and secp256k1. These additional resources offer further insights and information for those interested in understanding the proposed solutions.In conclusion, the user's inquiry on the Bitcoin Protocol Discussion mailing list and the subsequent email to bitcoin-dev highlight the potential benefits of combining SegWit, aggregated signatures, and coinjoin to improve scaling and privacy in Bitcoin transactions. The use of aggregated signatures with coinjoin would reduce transaction size, while the extra blockspace made possible by SegWit would benefit both witness and non-witness data. Additional resources provided by Bryan offer further exploration of the proposed solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Total-fees-have-almost-crossed-the-block-reward.xml b/static/bitcoin-dev/Dec_2017/combined_Total-fees-have-almost-crossed-the-block-reward.xml index ea860c0388..279f81b189 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Total-fees-have-almost-crossed-the-block-reward.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Total-fees-have-almost-crossed-the-block-reward.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Total fees have almost crossed the block reward - 2023-08-01T22:21:48.742306+00:00 - - Peter Todd 2018-02-13 19:03:17+00:00 - - - Christian Decker 2018-02-12 19:41:39+00:00 - - - Peter Todd 2018-02-12 18:12:32+00:00 - - - rhavar at protonmail.com 2018-02-12 17:47:50+00:00 - - - Melvin Carvalho 2018-02-12 17:23:35+00:00 - - - Gregory Maxwell 2017-12-22 01:15:46+00:00 - - - Mark Friedenbach 2017-12-22 00:30:52+00:00 - - - Paul Iverson 2017-12-21 23:35:28+00:00 - - - Michel 'ic' Luczak 2017-12-21 23:15:18+00:00 - - - Gregory Maxwell 2017-12-21 22:44:32+00:00 - - - Jim Rogers 2017-12-21 22:18:32+00:00 - - - Jameson Lopp 2017-12-21 22:02:37+00:00 - - - Melvin Carvalho 2017-12-21 21:30:20+00:00 - + 2025-09-26T15:52:16.512231+00:00 + python-feedgen + + + [bitcoin-dev] Total fees have almost crossed the block reward Melvin Carvalho + 2017-12-21T21:30:00.000Z + + + Jameson Lopp + 2017-12-21T22:02:00.000Z + + + Jim Rogers + 2017-12-21T22:18:00.000Z + + + Gregory Maxwell + 2017-12-21T22:44:00.000Z + + + Michel 'ic' Luczak + 2017-12-21T23:15:00.000Z + + + Paul Iverson + 2017-12-21T23:35:00.000Z + + + Mark Friedenbach + 2017-12-22T00:30:00.000Z + + + Gregory Maxwell + 2017-12-22T01:15:00.000Z + + + Melvin Carvalho + 2018-02-12T17:23:00.000Z + + + rhavar + 2018-02-12T17:47:00.000Z + + + Peter Todd + 2018-02-12T18:12:00.000Z + + + Christian Decker + 2018-02-12T19:41:00.000Z + + + Peter Todd + 2018-02-13T19:03:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Total fees have almost crossed the block reward - 2023-08-01T22:21:48.742306+00:00 + 2025-09-26T15:52:16.513740+00:00 - In a recent discussion on the Bitcoin development mailing list, Christian Decker and Peter Todd discuss how shabang.io determines whether a transaction has funded a Lightning channel. Decker suggests that the website collects short_channel_ids which point to on-chain outputs that funded a channel, but this method only works for public channels. Todd recommends that shabang.io document their process on their website to provide more transparency.Melvin Carvalho, a member of the Bitcoin development team, discovers shabang.io, a website that shows the adoption of the Lightning Network on the mainnet. He notes that the Lightning Network is growing well and predicts that over 1% of bitcoin transactions will be lightning-based by the end of the year. However, Peter Todd questions how shabang.io determines whether a transaction has funded a Lightning channel.Carvalho also shares some data points on the current state of Bitcoin, including increasing fees, the potential for fees to become prohibitive for some use cases, segwit adoption at around 10%, mempool congestion, fee distribution, and Lightning Network adoption on the mainnet. He hopes these stats will provide useful information for the evolution of the project.In another discussion on the Bitcoin-dev mailing list, Mark Friedenbach states that every transaction is already replace-by-fee capable, and opt-in replace by fee is a fiction that was only relevant when fees were smaller than subsidy. The debate revolves around whether or not to default opt-in replace by fee in Bitcoin Core. Electrum has been using opt-in replace by fee as default without issues. Some industrial users express concerns, but Friedenbach believes they can easily change their settings upon release.The rise in Bitcoin transaction fees is seen by some experts as a sign of success and the manifestation of a long-desired fee market. Gregory Maxwell believes that the increased activity level and fee-paying backlogs are necessary for consensus progress as the subsidy declines. However, users are frustrated when transactions get stuck. Paul Iverson suggests making replace-by-fee (RBF) ubiquitous to improve user experience, and Melvin Carvalho expresses concern that fees may be prohibitive for some use cases. Segwit adoption is around 10%, indicating room for education on efficient transaction styles.Gregory Maxwell expresses excitement about the fee market in action and proposes making every transaction RBF by default to address stuck transaction issues. He believes this would improve the user experience and secure the blockchain in the long term. Melvin Carvalho raises concerns about the security of the blockchain once the reward goes away and fees replace it. Segwit adoption stands at around 10%, and congestion is currently high. Maxwell suggests looking at difficult-to-forge market signals and other inefficient transaction styles for further analysis.In an email thread, Jameson Lopp thanks someone for an interview and discusses the high fees experienced in the blockchain. He believes that most hardware and software wallets miscalculate fees, causing the issue. He suggests that high volume senders should be more efficient in their use of block space by batching transactions and implementing SegWit. Melvin Carvalho asks about the long-term security of Bitcoin once the reward goes away, expressing concern about the fee per transaction being prohibitive for certain use cases. Observations show around 10% segwit adoption and peak congestion in the mempool.The long-term security of the blockchain is a concern as fees replace the block reward. Fees currently make up 45% of the block reward, with potential to reach 50%. However, there is concern that the fee per transaction may be too high for some use cases, especially as segwit adoption stands at around 10%. Efforts are being made to encourage efficient use of block space through batching transactions and implementing segwit. The mempool shows congestion, but it may decrease over time.Overall, the discussions and emails highlight concerns about the long-term security of the blockchain, the need for efficient use of block space, the rise in transaction fees, segwit adoption, and the increasing use of the Lightning Network. 2018-02-13T19:03:17+00:00 + In a recent discussion on the Bitcoin development mailing list, Christian Decker and Peter Todd discuss how shabang.io determines whether a transaction has funded a Lightning channel. Decker suggests that the website collects short_channel_ids which point to on-chain outputs that funded a channel, but this method only works for public channels. Todd recommends that shabang.io document their process on their website to provide more transparency.Melvin Carvalho, a member of the Bitcoin development team, discovers shabang.io, a website that shows the adoption of the Lightning Network on the mainnet. He notes that the Lightning Network is growing well and predicts that over 1% of bitcoin transactions will be lightning-based by the end of the year. However, Peter Todd questions how shabang.io determines whether a transaction has funded a Lightning channel.Carvalho also shares some data points on the current state of Bitcoin, including increasing fees, the potential for fees to become prohibitive for some use cases, segwit adoption at around 10%, mempool congestion, fee distribution, and Lightning Network adoption on the mainnet. He hopes these stats will provide useful information for the evolution of the project.In another discussion on the Bitcoin-dev mailing list, Mark Friedenbach states that every transaction is already replace-by-fee capable, and opt-in replace by fee is a fiction that was only relevant when fees were smaller than subsidy. The debate revolves around whether or not to default opt-in replace by fee in Bitcoin Core. Electrum has been using opt-in replace by fee as default without issues. Some industrial users express concerns, but Friedenbach believes they can easily change their settings upon release.The rise in Bitcoin transaction fees is seen by some experts as a sign of success and the manifestation of a long-desired fee market. Gregory Maxwell believes that the increased activity level and fee-paying backlogs are necessary for consensus progress as the subsidy declines. However, users are frustrated when transactions get stuck. Paul Iverson suggests making replace-by-fee (RBF) ubiquitous to improve user experience, and Melvin Carvalho expresses concern that fees may be prohibitive for some use cases. Segwit adoption is around 10%, indicating room for education on efficient transaction styles.Gregory Maxwell expresses excitement about the fee market in action and proposes making every transaction RBF by default to address stuck transaction issues. He believes this would improve the user experience and secure the blockchain in the long term. Melvin Carvalho raises concerns about the security of the blockchain once the reward goes away and fees replace it. Segwit adoption stands at around 10%, and congestion is currently high. Maxwell suggests looking at difficult-to-forge market signals and other inefficient transaction styles for further analysis.In an email thread, Jameson Lopp thanks someone for an interview and discusses the high fees experienced in the blockchain. He believes that most hardware and software wallets miscalculate fees, causing the issue. He suggests that high volume senders should be more efficient in their use of block space by batching transactions and implementing SegWit. Melvin Carvalho asks about the long-term security of Bitcoin once the reward goes away, expressing concern about the fee per transaction being prohibitive for certain use cases. Observations show around 10% segwit adoption and peak congestion in the mempool.The long-term security of the blockchain is a concern as fees replace the block reward. Fees currently make up 45% of the block reward, with potential to reach 50%. However, there is concern that the fee per transaction may be too high for some use cases, especially as segwit adoption stands at around 10%. Efforts are being made to encourage efficient use of block space through batching transactions and implementing segwit. The mempool shows congestion, but it may decrease over time.Overall, the discussions and emails highlight concerns about the long-term security of the blockchain, the need for efficient use of block space, the rise in transaction fees, segwit adoption, and the increasing use of the Lightning Network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Transaction-aging-to-relieve-user-concerns-.xml b/static/bitcoin-dev/Dec_2017/combined_Transaction-aging-to-relieve-user-concerns-.xml index 0674b510b6..5f77393340 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Transaction-aging-to-relieve-user-concerns-.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Transaction-aging-to-relieve-user-concerns-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Transaction aging to relieve user concerns. - 2023-08-01T22:22:50.931917+00:00 - - Mark Friedenbach 2017-12-28 20:49:38+00:00 - - - Dan Bryant 2017-12-28 19:55:01+00:00 - + 2025-09-26T15:52:29.053874+00:00 + python-feedgen + + + [bitcoin-dev] Transaction aging to relieve user concerns Dan Bryant + 2017-12-28T19:55:00.000Z + + + Mark Friedenbach + 2017-12-28T20:49:00.000Z + + - python-feedgen + 2 Combined summary - Transaction aging to relieve user concerns. - 2023-08-01T22:22:50.931917+00:00 + 2025-09-26T15:52:29.054317+00:00 - In a message posted on Dec 28, 2017, Dan Bryant proposed a solution to address the uncertainty surrounding transaction aging in the Bitcoin network. Currently, the relay policy of the network specifies when transactions will "age out," but there is no guarantee that miners will exclude these transactions from the blockchain even after the specified timeout. This lack of certainty prevents users from having actionable information about transaction aging.To tackle this issue, Bryant suggested expanding the transaction format through a Bitcoin Improvement Proposal (BIP). The proposal involves including the chain-height or block number in the transaction (TXN), allowing nodes and miners to determine the age of the TXN and choose not to rebroadcast it once it reaches a certain age threshold. Presently, nodes and miners maintain a "seen-list" of transactions and age them based on when they were last seen. However, this approach could result in TXNs being broadcast indefinitely if the unspent transaction output (UTXO) remains untouched.The objective of the proposed BIP is not to enhance the protocol itself, but rather to provide users with better certainty regarding transaction aging. However, there are potential abuse vectors to consider. For instance, a malicious party could broadcast a low fee transaction near the age-out threshold, hoping to exploit the fact that the transaction will age out in the next block.If the Bitcoin Core team is open to considering this proposal, Bryant expressed his willingness to draft a BIP. By expanding the transaction format and incorporating chain-height, this proposal aims to make it easier for users to know when a transaction will age out with greater certainty. 2017-12-28T20:49:38+00:00 + In a message posted on Dec 28, 2017, Dan Bryant proposed a solution to address the uncertainty surrounding transaction aging in the Bitcoin network. Currently, the relay policy of the network specifies when transactions will "age out," but there is no guarantee that miners will exclude these transactions from the blockchain even after the specified timeout. This lack of certainty prevents users from having actionable information about transaction aging.To tackle this issue, Bryant suggested expanding the transaction format through a Bitcoin Improvement Proposal (BIP). The proposal involves including the chain-height or block number in the transaction (TXN), allowing nodes and miners to determine the age of the TXN and choose not to rebroadcast it once it reaches a certain age threshold. Presently, nodes and miners maintain a "seen-list" of transactions and age them based on when they were last seen. However, this approach could result in TXNs being broadcast indefinitely if the unspent transaction output (UTXO) remains untouched.The objective of the proposed BIP is not to enhance the protocol itself, but rather to provide users with better certainty regarding transaction aging. However, there are potential abuse vectors to consider. For instance, a malicious party could broadcast a low fee transaction near the age-out threshold, hoping to exploit the fact that the transaction will age out in the next block.If the Bitcoin Core team is open to considering this proposal, Bryant expressed his willingness to draft a BIP. By expanding the transaction format and incorporating chain-height, this proposal aims to make it easier for users to know when a transaction will age out with greater certainty. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Two-Drivechain-BIPs.xml b/static/bitcoin-dev/Dec_2017/combined_Two-Drivechain-BIPs.xml index ef80d97211..c00270a11b 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Two-Drivechain-BIPs.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Two-Drivechain-BIPs.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Two Drivechain BIPs - 2023-08-01T22:15:16.788973+00:00 - - ZmnSCPxj 2017-12-14 03:24:07+00:00 - - - Paul Sztorc 2017-12-12 22:29:39+00:00 - - - Paul Sztorc 2017-12-12 22:16:47+00:00 - - - ZmnSCPxj 2017-12-08 15:40:11+00:00 - - - ZmnSCPxj 2017-12-07 07:28:03+00:00 - - - CryptAxe 2017-12-06 20:51:43+00:00 - - - ZmnSCPxj 2017-12-06 04:49:12+00:00 - - - Paul Sztorc 2017-12-05 19:55:33+00:00 - - - AJ West 2017-12-05 18:20:49+00:00 - - - Paul Sztorc 2017-12-05 18:05:39+00:00 - - - Luke Dashjr 2017-12-05 07:41:59+00:00 - - - Chris Stewart 2017-12-04 20:11:13+00:00 - - - Chris Pacia 2017-12-04 19:36:31+00:00 - - - Paul Sztorc 2017-12-04 19:05:09+00:00 - - - Matt Corallo 2017-12-03 21:32:15+00:00 - - - Paul Sztorc 2017-12-01 18:38:16+00:00 - + 2025-09-26T15:52:41.626397+00:00 + python-feedgen + + + [bitcoin-dev] Two Drivechain BIPs Paul Sztorc + 2017-12-01T18:38:00.000Z + + + Matt Corallo + 2017-12-03T21:32:00.000Z + + + Paul Sztorc + 2017-12-04T19:05:00.000Z + + + Chris Pacia + 2017-12-04T19:36:00.000Z + + + Chris Stewart + 2017-12-04T20:11:00.000Z + + + Luke Dashjr + 2017-12-05T07:41:00.000Z + + + Paul Sztorc + 2017-12-05T18:05:00.000Z + + + AJ West + 2017-12-05T18:20:00.000Z + + + Paul Sztorc + 2017-12-05T19:55:00.000Z + + + ZmnSCPxj + 2017-12-06T04:49:00.000Z + + + CryptAxe + 2017-12-06T20:51:00.000Z + + + ZmnSCPxj + 2017-12-07T07:28:00.000Z + + + ZmnSCPxj + 2017-12-08T15:40:00.000Z + + + Paul Sztorc + 2017-12-12T22:16:00.000Z + + + Paul Sztorc + 2017-12-12T22:29:00.000Z + + + ZmnSCPxj + 2017-12-14T03:24:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - Two Drivechain BIPs - 2023-08-01T22:15:16.788973+00:00 + 2025-09-26T15:52:41.628217+00:00 - In a series of email exchanges, Paul and ZmnSCPxj discuss the collective action problem in fraudulent withdrawals from sidechains and propose a solution using smart contracts. The proposed solution involves recruiting accomplices who are paid cuts of the theft through Accomplice Contracts. The thief broadcasts the existence of Hashed Time-Locked Contracts (HTLCs) without negotiating with the accomplices, reducing communication overhead. However, this solution requires significant funds in reserve and could be vulnerable if withdrawals are not restricted to simple P2PKH or P2WPKH.The conversation also delves into various topics related to drivechain technology. They discuss the potential for miners colluding and undercutting their competition by upvoting their own withdrawals and downvoting others. Paul argues that atomic swaps make such behavior unnecessary. They also address concerns about pools being created or destroyed multiple times and the possibility of miners harassing each other using strategy. Paul suggests that orphaning can be used as a response to spiteful miners. The security model of drivechain is discussed, relying on investor disappointment and the slow withdrawal process to increase security.The author proposes using P2PKH to create Theft and Accomplice Contracts, both being HTLCs. The timelock in the Theft Contract allows anyone to spend after the time limit, while the Accomplice Contract is an ordinary HTLC. By using P2PKH and an off-chain method, a HTLC with anyone-can-spend after the timelock can be formed. However, there are issues with timelock-encryption as a time measure. The author suggests that someone may exploit the mathematics of P2PKH to create something similar to a HTLC.The article discusses potential outcomes of miners colluding and making invalid withdrawals, as well as the issue of three mining pools with slightly different hashpower percentages. It is noted that three equal mining pools are unnatural and may lead to collusion. The possibility of miners colluding together and stealing all sidechain funds is also mentioned.In a post on the bitcoin-dev mailing list, ZmnSCPxj suggests restricting withdrawals to simple P2PKH or P2WPKH to fix a vulnerability. However, it is noted that this may not be enough due to Scriptless Script and Bellare-Neven signatures.The collective action problem in fraudulent withdrawals from sidechains is discussed, and a solution using smart contracts is proposed. The thief pays out to a destination address that is a P2SH of the Theft Contract and recruits accomplices who vote for the invalid withdrawal. Negotiation can be done parallel to the theft attempt, reducing the cost of organizing collective action. This method requires significant funds in reserve but aims to utilize existing miner funds. Restricting withdrawals to simple P2PKH or P2WPKH is suggested as a way to fix vulnerabilities.Paul Sztorc responds to criticisms of the security model for drivechains, addressing concerns about non-verifying miners being complicit in theft. He explains mechanisms in place to address problems with multiple withdrawals and argues against the idea that miners should always downvote. The email thread also includes a discussion on the security model for sidechains versus drivechains, with Sztorc stating that criticisms of drivechains' security are unfounded.The writer requests BIP numbers for the ideas discussed in the thread and argues for the benefits of technical review. They disagree with claims that there are no repercussions for fraudulent withdrawals and accuse others of committing the "useless sidechain fallacy."An email conversation between Chris Pacia and Paul discusses the security model of sidechains, the marginal cost of casting a malicious vote, and the repercussions of fraudulent withdrawals. The potential impact of these repercussions is uncertain. The useless sidechain fallacy is also discussed, as well as the collective action problem inherent in fraudulent withdrawals.On December 3, 2017, Matt Corallo expresses concerns about the risk of centralization of mining in sidechains and the need for new sidechains to be rare events. However, it is noted that federated sidechains are already possible and the value of permissionless sidechain innovation is significant.A Reddit user presents an analysis on blind merged mining (BMM) and drivechains, highlighting the disconnect between voting and "blind" merge mining. The security model for sidechains is compared to every blockchain, but the lack of opportunity costs or collective action barriers in drivechains makes it less secure.The author of this context argues that the security model for sidechains is the same as that of every blockchain. They refute claims that 51% hashrate can steal coins in sidechains, stating that this is also true of the mainchain. However, they note that there are substantial opportunity costs and a collective action problem when it comes to re-writing the mainchain. The author questions whether there is anything similar for drivechains, as they see no opportunity cost or repercussions for casting a malicious vote, nor any collective action barrier 2017-12-14T03:24:07+00:00 + In a series of email exchanges, Paul and ZmnSCPxj discuss the collective action problem in fraudulent withdrawals from sidechains and propose a solution using smart contracts. The proposed solution involves recruiting accomplices who are paid cuts of the theft through Accomplice Contracts. The thief broadcasts the existence of Hashed Time-Locked Contracts (HTLCs) without negotiating with the accomplices, reducing communication overhead. However, this solution requires significant funds in reserve and could be vulnerable if withdrawals are not restricted to simple P2PKH or P2WPKH.The conversation also delves into various topics related to drivechain technology. They discuss the potential for miners colluding and undercutting their competition by upvoting their own withdrawals and downvoting others. Paul argues that atomic swaps make such behavior unnecessary. They also address concerns about pools being created or destroyed multiple times and the possibility of miners harassing each other using strategy. Paul suggests that orphaning can be used as a response to spiteful miners. The security model of drivechain is discussed, relying on investor disappointment and the slow withdrawal process to increase security.The author proposes using P2PKH to create Theft and Accomplice Contracts, both being HTLCs. The timelock in the Theft Contract allows anyone to spend after the time limit, while the Accomplice Contract is an ordinary HTLC. By using P2PKH and an off-chain method, a HTLC with anyone-can-spend after the timelock can be formed. However, there are issues with timelock-encryption as a time measure. The author suggests that someone may exploit the mathematics of P2PKH to create something similar to a HTLC.The article discusses potential outcomes of miners colluding and making invalid withdrawals, as well as the issue of three mining pools with slightly different hashpower percentages. It is noted that three equal mining pools are unnatural and may lead to collusion. The possibility of miners colluding together and stealing all sidechain funds is also mentioned.In a post on the bitcoin-dev mailing list, ZmnSCPxj suggests restricting withdrawals to simple P2PKH or P2WPKH to fix a vulnerability. However, it is noted that this may not be enough due to Scriptless Script and Bellare-Neven signatures.The collective action problem in fraudulent withdrawals from sidechains is discussed, and a solution using smart contracts is proposed. The thief pays out to a destination address that is a P2SH of the Theft Contract and recruits accomplices who vote for the invalid withdrawal. Negotiation can be done parallel to the theft attempt, reducing the cost of organizing collective action. This method requires significant funds in reserve but aims to utilize existing miner funds. Restricting withdrawals to simple P2PKH or P2WPKH is suggested as a way to fix vulnerabilities.Paul Sztorc responds to criticisms of the security model for drivechains, addressing concerns about non-verifying miners being complicit in theft. He explains mechanisms in place to address problems with multiple withdrawals and argues against the idea that miners should always downvote. The email thread also includes a discussion on the security model for sidechains versus drivechains, with Sztorc stating that criticisms of drivechains' security are unfounded.The writer requests BIP numbers for the ideas discussed in the thread and argues for the benefits of technical review. They disagree with claims that there are no repercussions for fraudulent withdrawals and accuse others of committing the "useless sidechain fallacy."An email conversation between Chris Pacia and Paul discusses the security model of sidechains, the marginal cost of casting a malicious vote, and the repercussions of fraudulent withdrawals. The potential impact of these repercussions is uncertain. The useless sidechain fallacy is also discussed, as well as the collective action problem inherent in fraudulent withdrawals.On December 3, 2017, Matt Corallo expresses concerns about the risk of centralization of mining in sidechains and the need for new sidechains to be rare events. However, it is noted that federated sidechains are already possible and the value of permissionless sidechain innovation is significant.A Reddit user presents an analysis on blind merged mining (BMM) and drivechains, highlighting the disconnect between voting and "blind" merge mining. The security model for sidechains is compared to every blockchain, but the lack of opportunity costs or collective action barriers in drivechains makes it less secure.The author of this context argues that the security model for sidechains is the same as that of every blockchain. They refute claims that 51% hashrate can steal coins in sidechains, stating that this is also true of the mainchain. However, they note that there are substantial opportunity costs and a collective action problem when it comes to re-writing the mainchain. The author questions whether there is anything similar for drivechains, as they see no opportunity cost or repercussions for casting a malicious vote, nor any collective action barrier - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Updates-on-Confidential-Transactions-efficiency.xml b/static/bitcoin-dev/Dec_2017/combined_Updates-on-Confidential-Transactions-efficiency.xml index 91a5a7f398..732bbf0b54 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Updates-on-Confidential-Transactions-efficiency.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Updates-on-Confidential-Transactions-efficiency.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Updates on Confidential Transactions efficiency - 2023-08-01T22:08:18.215647+00:00 - - Andrew Poelstra 2017-12-04 17:17:11+00:00 - - - Gregory Maxwell 2017-11-14 10:51:13+00:00 - - - Gregory Maxwell 2017-11-14 10:38:33+00:00 - - - Peter Todd 2017-11-14 10:07:28+00:00 - - - Peter Todd 2017-11-14 09:11:23+00:00 - - - Gregory Maxwell 2017-11-14 01:21:14+00:00 - + 2025-09-26T15:52:52.111581+00:00 + python-feedgen + + + [bitcoin-dev] Updates on Confidential Transactions efficiency Gregory Maxwell + 2017-11-14T01:21:00.000Z + + + Peter Todd + 2017-11-14T09:11:00.000Z + + + Peter Todd + 2017-11-14T10:07:00.000Z + + + Gregory Maxwell + 2017-11-14T10:38:00.000Z + + + Gregory Maxwell + 2017-11-14T10:51:00.000Z + + + Andrew Poelstra + 2017-12-04T17:17:00.000Z + + - python-feedgen + 2 Combined summary - Updates on Confidential Transactions efficiency - 2023-08-01T22:08:18.215647+00:00 + 2025-09-26T15:52:52.112416+00:00 - Andrew Poelstra has implemented the single-output version of Bulletproofs, a cryptographic proof system that can prove statements about encrypted data. The benchmarks were performed on one core of an Intel i7-6820MQ, and reflect verification of a single 64-bit rangeproof. By using GLV endomorphism supported by the curve secp256k1, speedup was observed. It reflects a 3.47x speedup over the verification speed of the old rangeproofs without the endomorphism. Even without aggregation, two rangeproofs are verified nearly 15% faster than verifying one twice. The old rangeproofs require only 128 multiplies for a 64-bit proof, then 256 for two, and so on, while at the same time the new Bulletproofs perform significantly better. The Bulletproof verification process is a recursive process which does not appear to be expressible as a single multiproduct, and in fact it appears to require nearly twice as many multiplications as claimed. There are still a few open issues that Andrew plans to help resolve in the coming month.In an email exchange, Gregory Maxwell discussed the scalability and privacy of different transaction topologies. He noted that ring-in and tree-in approaches, used by Monero and Zcash, are more private but less scalable than CT+valueshuffle. However, he also mentioned a fourth topology that is closely related to ring-in, which involves taking N inputs and writing >= N outputs, replacing some coins with new outputs or encrypted dummies while re-encrypting others in a way that their owner can still decode. This approach avoids the spent coins list by allowing for malleation of inputs. In the past, there was no efficient way to construct this topology in a plain DL setting, but it may be possible with bulletproofs.In an email exchange, Peter Todd and Gregory Maxwell discuss the risks associated with privacy in cryptocurrency systems. Todd argues that privacy breaches threaten users' freedom, while Maxwell questions the feasibility of implementing perfectly hiding systems in practice. They also discuss the possibility of using switch commitments to retain computational-hiding-depending-on-the-hardness-of-inverting-hashes while retaining an option to upgrade or block spending via unsound mechanisms in the event of a crypto break. The conversation then shifts to the scalability of ring-in and tree-in approaches in Monero and Zcash, with Maxwell suggesting ways to extend these approaches to a traceable 1 of N input for Monero. He also proposes using a hash tree to provide tree-in style transactions with proofs that grow with the log() of the size of the tree, although he acknowledges that this would come at the cost of larger proofs and slower verification. Despite its drawbacks, Maxwell believes that the interactive-sparse-in (CJ) approach has its own attractiveness.Gregory Maxwell discusses an approach that could be constructed without new cryptographic assumptions, be high-performance compared to alternatives, have no trusted setup, and not involve the creation of any forever-growing unprunable accumulators. All major alternative schemes failed multiple criteria in comparison. In response to the issue of unprunable accumulators, it was suggested that it would be feasible to use accumulator epochs. This would either make unspent coins in a previous epoch unspendable after some expiry time is reached or make use of a merkelized key-value scheme with transaction-provided proofs to shift the costs of maintaining the accumulator to wallets. Epoch size would be a tradeoff between state size and k-anonymity set size.Gregory Maxwell announces the release of Bulletproofs, a new zero-knowledge proof system that shrinks the size of cryptographic proofs and makes them safer. Bulletproofs can be used to increase the privacy and confidentiality of cryptocurrencies such as Bitcoin, while also making them more scalable. The technology was developed by researchers at University College London (UCL), Blockstream and Stanford University, and is based on previous work by UCL's Jonathan Bootle.Adam Back proposed the use of additive homomorphic commitments in Bitcoin to improve transaction privacy. This approach, known as confidential transactions, makes transaction amounts private and complements CoinJoin by avoiding the issue of joins being decoded due to different amounts being used. Recent work has focused on reducing the range proof size further. In a recent publication on confidential assets, the size was reduced to 96*log3(2)*bits + 32. Benedikt Bünz at Stanford was able to apply and optimize the inner product argument of Jonathan Bootle to achieve an aggregate range proof for CT with size 64 * (log2(bits * num_outputs)) + 288. This scheme also has a straightforward and efficient method for multi-party computation, which means that the aggregates can be used in all-party-private coinjoins like the value shuffle work mentioned above. Verification in this new work requires computation which is more than linear in the size of the proof. 2017-12-04T17:17:11+00:00 + Andrew Poelstra has implemented the single-output version of Bulletproofs, a cryptographic proof system that can prove statements about encrypted data. The benchmarks were performed on one core of an Intel i7-6820MQ, and reflect verification of a single 64-bit rangeproof. By using GLV endomorphism supported by the curve secp256k1, speedup was observed. It reflects a 3.47x speedup over the verification speed of the old rangeproofs without the endomorphism. Even without aggregation, two rangeproofs are verified nearly 15% faster than verifying one twice. The old rangeproofs require only 128 multiplies for a 64-bit proof, then 256 for two, and so on, while at the same time the new Bulletproofs perform significantly better. The Bulletproof verification process is a recursive process which does not appear to be expressible as a single multiproduct, and in fact it appears to require nearly twice as many multiplications as claimed. There are still a few open issues that Andrew plans to help resolve in the coming month.In an email exchange, Gregory Maxwell discussed the scalability and privacy of different transaction topologies. He noted that ring-in and tree-in approaches, used by Monero and Zcash, are more private but less scalable than CT+valueshuffle. However, he also mentioned a fourth topology that is closely related to ring-in, which involves taking N inputs and writing >= N outputs, replacing some coins with new outputs or encrypted dummies while re-encrypting others in a way that their owner can still decode. This approach avoids the spent coins list by allowing for malleation of inputs. In the past, there was no efficient way to construct this topology in a plain DL setting, but it may be possible with bulletproofs.In an email exchange, Peter Todd and Gregory Maxwell discuss the risks associated with privacy in cryptocurrency systems. Todd argues that privacy breaches threaten users' freedom, while Maxwell questions the feasibility of implementing perfectly hiding systems in practice. They also discuss the possibility of using switch commitments to retain computational-hiding-depending-on-the-hardness-of-inverting-hashes while retaining an option to upgrade or block spending via unsound mechanisms in the event of a crypto break. The conversation then shifts to the scalability of ring-in and tree-in approaches in Monero and Zcash, with Maxwell suggesting ways to extend these approaches to a traceable 1 of N input for Monero. He also proposes using a hash tree to provide tree-in style transactions with proofs that grow with the log() of the size of the tree, although he acknowledges that this would come at the cost of larger proofs and slower verification. Despite its drawbacks, Maxwell believes that the interactive-sparse-in (CJ) approach has its own attractiveness.Gregory Maxwell discusses an approach that could be constructed without new cryptographic assumptions, be high-performance compared to alternatives, have no trusted setup, and not involve the creation of any forever-growing unprunable accumulators. All major alternative schemes failed multiple criteria in comparison. In response to the issue of unprunable accumulators, it was suggested that it would be feasible to use accumulator epochs. This would either make unspent coins in a previous epoch unspendable after some expiry time is reached or make use of a merkelized key-value scheme with transaction-provided proofs to shift the costs of maintaining the accumulator to wallets. Epoch size would be a tradeoff between state size and k-anonymity set size.Gregory Maxwell announces the release of Bulletproofs, a new zero-knowledge proof system that shrinks the size of cryptographic proofs and makes them safer. Bulletproofs can be used to increase the privacy and confidentiality of cryptocurrencies such as Bitcoin, while also making them more scalable. The technology was developed by researchers at University College London (UCL), Blockstream and Stanford University, and is based on previous work by UCL's Jonathan Bootle.Adam Back proposed the use of additive homomorphic commitments in Bitcoin to improve transaction privacy. This approach, known as confidential transactions, makes transaction amounts private and complements CoinJoin by avoiding the issue of joins being decoded due to different amounts being used. Recent work has focused on reducing the range proof size further. In a recent publication on confidential assets, the size was reduced to 96*log3(2)*bits + 32. Benedikt Bünz at Stanford was able to apply and optimize the inner product argument of Jonathan Bootle to achieve an aggregate range proof for CT with size 64 * (log2(bits * num_outputs)) + 288. This scheme also has a straightforward and efficient method for multi-party computation, which means that the aggregates can be used in all-party-private coinjoins like the value shuffle work mentioned above. Verification in this new work requires computation which is more than linear in the size of the proof. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_Why-not-witnessless-nodes-.xml b/static/bitcoin-dev/Dec_2017/combined_Why-not-witnessless-nodes-.xml index b3afac812f..55c0c6496d 100644 --- a/static/bitcoin-dev/Dec_2017/combined_Why-not-witnessless-nodes-.xml +++ b/static/bitcoin-dev/Dec_2017/combined_Why-not-witnessless-nodes-.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - Why not witnessless nodes? - 2023-08-01T22:20:16.458943+00:00 - - Eric Voskuil 2017-12-18 21:58:58+00:00 - - - Kalle Rosenbaum 2017-12-18 21:51:40+00:00 - - - Kalle Rosenbaum 2017-12-18 21:27:14+00:00 - - - Gregory Maxwell 2017-12-18 20:42:34+00:00 - - - Kalle Rosenbaum 2017-12-18 20:34:30+00:00 - - - Mark Friedenbach 2017-12-18 17:30:17+00:00 - - - Eric Voskuil 2017-12-18 16:19:34+00:00 - - - Kalle Rosenbaum 2017-12-18 13:35:44+00:00 - - - Eric Voskuil 2017-12-18 12:43:58+00:00 - - - Ozgur 2017-12-18 12:11:10+00:00 - - - Kalle Rosenbaum 2017-12-18 08:32:23+00:00 - + 2025-09-26T15:52:24.879718+00:00 + python-feedgen + + + [bitcoin-dev] Why not witnessless nodes? Kalle Rosenbaum + 2017-12-18T08:32:00.000Z + + + Ozgur + 2017-12-18T12:11:00.000Z + + + Eric Voskuil + 2017-12-18T12:43:00.000Z + + + Kalle Rosenbaum + 2017-12-18T13:35:00.000Z + + + Eric Voskuil + 2017-12-18T16:19:00.000Z + + + Mark Friedenbach + 2017-12-18T17:30:00.000Z + + + Kalle Rosenbaum + 2017-12-18T20:34:00.000Z + + + Gregory Maxwell + 2017-12-18T20:42:00.000Z + + + Kalle Rosenbaum + 2017-12-18T21:27:00.000Z + + + Kalle Rosenbaum + 2017-12-18T21:51:00.000Z + + + Eric Voskuil + 2017-12-18T21:58:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - Why not witnessless nodes? - 2023-08-01T22:20:16.458943+00:00 + 2025-09-26T15:52:24.881021+00:00 - The discussion on the Bitcoin-dev mailing list revolves around the use and necessity of Bitcoin witnesses. Witnesses are used to authenticate updates to the UTXO set, but once they have been buried deep enough in the blockchain, they are no longer needed as consensus has formed around the UTXO set update. The question arises if sign-to-contract protocols can work in a witnessless environment. While witnesses are required for SPV nodes validating these protocols, it is argued that full nodes do not need to download witnesses when they skip signature verification for blocks earlier than X, as their purpose is mainly to be able to send witnesses to other nodes and verify the witness root hash of the blocks.Kalle Rosenbaum suggests the concept of witnessless nodes, which would only be witnessless for blocks up to X and would not download witnesses but instead send witnessless blocks to peers. This would allow witnessless nodes to sync faster, provide full service to SPV wallets and local wallets, serve blocks to other witnessless nodes with the same or higher assumevalid block, and potentially even serve blocks to non-segwit nodes. However, there is a concern that implementing witnessless nodes could divide the network in two parts, one witnessless and one with full nodes, with few connections between the parts.There is further debate on the mailing list about the importance of downloading witnesses for initial block download and whether witnessless nodes could provide benefits such as faster syncing and serving blocks to other nodes. However, concerns are raised about the potential risk of dividing the network into two parts with limited connectivity. The reasons for not implementing witnessless nodes are not fully addressed in the discussion.Overall, the discussion highlights the ongoing debate and considerations surrounding the use of witnesses and the potential benefits and risks of implementing witnessless nodes in the Bitcoin network. 2017-12-18T21:58:58+00:00 + The discussion on the Bitcoin-dev mailing list revolves around the use and necessity of Bitcoin witnesses. Witnesses are used to authenticate updates to the UTXO set, but once they have been buried deep enough in the blockchain, they are no longer needed as consensus has formed around the UTXO set update. The question arises if sign-to-contract protocols can work in a witnessless environment. While witnesses are required for SPV nodes validating these protocols, it is argued that full nodes do not need to download witnesses when they skip signature verification for blocks earlier than X, as their purpose is mainly to be able to send witnesses to other nodes and verify the witness root hash of the blocks.Kalle Rosenbaum suggests the concept of witnessless nodes, which would only be witnessless for blocks up to X and would not download witnesses but instead send witnessless blocks to peers. This would allow witnessless nodes to sync faster, provide full service to SPV wallets and local wallets, serve blocks to other witnessless nodes with the same or higher assumevalid block, and potentially even serve blocks to non-segwit nodes. However, there is a concern that implementing witnessless nodes could divide the network in two parts, one witnessless and one with full nodes, with few connections between the parts.There is further debate on the mailing list about the importance of downloading witnesses for initial block download and whether witnessless nodes could provide benefits such as faster syncing and serving blocks to other nodes. However, concerns are raised about the potential risk of dividing the network into two parts with limited connectivity. The reasons for not implementing witnessless nodes are not fully addressed in the discussion.Overall, the discussion highlights the ongoing debate and considerations surrounding the use of witnesses and the potential benefits and risks of implementing witnessless nodes in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2017/combined_what-do-you-think-about-having-a-maximum-fee-rate-.xml b/static/bitcoin-dev/Dec_2017/combined_what-do-you-think-about-having-a-maximum-fee-rate-.xml index 7d9e71f597..c253d44843 100644 --- a/static/bitcoin-dev/Dec_2017/combined_what-do-you-think-about-having-a-maximum-fee-rate-.xml +++ b/static/bitcoin-dev/Dec_2017/combined_what-do-you-think-about-having-a-maximum-fee-rate-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - what do you think about having a maximum fee rate? - 2023-08-01T22:22:27.442139+00:00 - - oscar 2017-12-24 13:59:23+00:00 - - - Damian Williamson 2017-12-24 01:13:27+00:00 - - - oscar 2017-12-22 08:26:12+00:00 - + 2025-09-26T15:52:50.021826+00:00 + python-feedgen + + + [bitcoin-dev] what do you think about having a maximum fee rate? oscar + 2017-12-22T08:26:00.000Z + + + Damian Williamson + 2017-12-24T01:13:00.000Z + + + oscar + 2017-12-24T13:59:00.000Z + + - python-feedgen + 2 Combined summary - what do you think about having a maximum fee rate? - 2023-08-01T22:22:27.442139+00:00 + 2025-09-26T15:52:50.022317+00:00 - Damian Williamson, a developer, has raised concerns about the profitability of wasting space on the blockchain and suggests increasing fees to discourage wasteful usage. Another developer proposes a complex solution, but Williamson favors a simpler approach. He suggests that nodes should stop propagating transactions with fees over the maximum limit, and miners should reject blocks where the coinbase exceeds the block reward plus the maximum fee rate multiplied by the block size. This would incentivize efficient usage by both users and miners. However, Williamson acknowledges that unbounded fees, small blocks, and big miners introduce a flaw in the incentives equilibrium. To address this, he suggests gradually increasing the block size along with his proposal.An email sent to the bitcoin-dev mailing list discusses a potential issue with the current incentive system in Bitcoin. The author points out that miners may be incentivized to spam the network with low-fee transactions, leading regular users to pay higher fees to confirm their transactions. The author presents calculations showing that even with just 5-10% of the hashing power, such an attack could be profitable. To mitigate this problem, the author proposes several solutions, including increasing the block size, changing the proof-of-work algorithm, or implementing a protocol-level maximum transaction fee.The author suggests that a maximum fee would make spamming the network more expensive than the fees recovered, ensuring fair competition among miners. The email includes links to additional information and discussions on the topic. In conclusion, the author seeks input from others on addressing the current incentive system and preventing high fees for regular users. 2017-12-24T13:59:23+00:00 + Damian Williamson, a developer, has raised concerns about the profitability of wasting space on the blockchain and suggests increasing fees to discourage wasteful usage. Another developer proposes a complex solution, but Williamson favors a simpler approach. He suggests that nodes should stop propagating transactions with fees over the maximum limit, and miners should reject blocks where the coinbase exceeds the block reward plus the maximum fee rate multiplied by the block size. This would incentivize efficient usage by both users and miners. However, Williamson acknowledges that unbounded fees, small blocks, and big miners introduce a flaw in the incentives equilibrium. To address this, he suggests gradually increasing the block size along with his proposal.An email sent to the bitcoin-dev mailing list discusses a potential issue with the current incentive system in Bitcoin. The author points out that miners may be incentivized to spam the network with low-fee transactions, leading regular users to pay higher fees to confirm their transactions. The author presents calculations showing that even with just 5-10% of the hashing power, such an attack could be profitable. To mitigate this problem, the author proposes several solutions, including increasing the block size, changing the proof-of-work algorithm, or implementing a protocol-level maximum transaction fee.The author suggests that a maximum fee would make spamming the network more expensive than the fees recovered, ensuring fair competition among miners. The email includes links to additional information and discussions on the topic. In conclusion, the author seeks input from others on addressing the current incentive system and preventing high fees for regular users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_BIP-Proposal-Address-Paste-Improvement.xml b/static/bitcoin-dev/Dec_2018/combined_BIP-Proposal-Address-Paste-Improvement.xml index e92b95ff76..fedb0e2be3 100644 --- a/static/bitcoin-dev/Dec_2018/combined_BIP-Proposal-Address-Paste-Improvement.xml +++ b/static/bitcoin-dev/Dec_2018/combined_BIP-Proposal-Address-Paste-Improvement.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - BIP Proposal - Address Paste Improvement - 2023-08-01T23:58:56.562249+00:00 - - Adam Ficsor 2018-12-01 12:07:40+00:00 - - - James MacWhyte 2018-12-01 04:57:20+00:00 - - - Adam Ficsor 2018-11-12 03:23:53+00:00 - - - Dmitry Petukhov 2018-11-08 18:00:04+00:00 - - - Moral Agent 2018-11-08 17:43:36+00:00 - - - Jeffrey Paul 2018-11-08 17:12:17+00:00 - - - Andreas Schildbach 2018-11-08 15:28:41+00:00 - - - Dmitry Petukhov 2018-11-08 08:11:30+00:00 - - - Andreas Schildbach 2018-11-07 21:28:54+00:00 - - - Adam Ficsor 2018-11-07 14:09:53+00:00 - + 2025-09-26T15:59:15.109214+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal - Address Paste Improvement Adam Ficsor + 2018-11-07T14:09:00.000Z + + + Andreas Schildbach + 2018-11-07T21:28:00.000Z + + + Dmitry Petukhov + 2018-11-08T08:11:00.000Z + + + Andreas Schildbach + 2018-11-08T15:28:00.000Z + + + Jeffrey Paul + 2018-11-08T17:12:00.000Z + + + Moral Agent + 2018-11-08T17:43:00.000Z + + + Dmitry Petukhov + 2018-11-08T18:00:00.000Z + + + Adam Ficsor + 2018-11-12T03:23:00.000Z + + + James MacWhyte + 2018-12-01T04:57:00.000Z + + + Adam Ficsor + 2018-12-01T12:07:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal - Address Paste Improvement - 2023-08-01T23:58:56.562249+00:00 + 2025-09-26T15:59:15.110400+00:00 - The discussion thread focuses on the need to establish a standard for transferring Bitcoin addresses from web pages or messages to wallet address input fields. Various methods were suggested, including QR code scanning, "bitcoin:" URI intent, and the BIP70 payment protocol. However, concerns were raised about incentivizing users to use copypaste functionality extensively, as it can be easily compromised by crypto hijackers. It was argued that moving to other ways of specifying destinations could also pose security issues. The conversation also touched on BIP75 and BIP47 protocols, which may help with address transfer but have limited wallet support due to their complexity. A work-in-progress implementation exists in Wasabi. Ultimately, the decision whether this needs to be a BIP or not depends on the community's valuation of user experience.In the Bitcoin developer email thread, the issue of transferring an address from a webpage to a wallet address input field was discussed. Suggestions included QR code scanning and using "bitcoin:" URI intent on Android. However, in many cases, addresses are presented as text to copy. Some proposed autodetecting Bitcoin addresses and converting them to "bitcoin:" links, but adoption of this feature may be slow. The conversation also delved into the BIP70, BIP75, and BIP47 payment protocols, with limited wallet support for the latter two due to their complexity. One commenter questioned the need for this to be a BIP, emphasizing that it is more of a UX detail rather than a Bitcoin protocol. They requested further elaboration on the need for documentation. Another commenter raised concerns about incentivizing excessive use of copypaste functionality, but argued that crypto hijackers use the clipboard because it is convenient, not because it is the only method they can hijack. The existence of a work-in-progress implementation in Wasabi was mentioned.The mechanism for end-users to transfer an address from a web page to the wallet address input field was discussed in the thread. Various methods such as QR code scanning, "bitcoin:" URI intent, and BIP70 payment message intent were suggested. However, in many cases, addresses are presented as text for users to copy. There were concerns about incentivizing excessive use of copypaste functionality, countered by the argument that crypto hijackers use the clipboard because it is convenient, not because it is their only method of hijacking. The conversation also touched on crypto hijackers, which was considered off-topic. It was noted that there is a work-in-progress implementation in Wasabi. For well-known entities, the BIP70 payment protocol with authentication via certificates can be used, but it does not cover the use case of relying solely on the person in front of you as the trust anchor. BIP75 and BIP47 protocols may help, but their limited wallet support is attributed to their complexity.There are several mechanisms available for end-users to transfer an address from a web page to the wallet address input field, including QR code scanning, "bitcoin:" URI intent, and BIP70 payment message intent. However, in many cases, addresses are presented as text for users to copy. This raised concerns about incentivizing excessive use of copypaste functionality. On the other hand, it was argued that crypto hijackers use the clipboard because it is convenient, rather than it being their only method of hijacking. The discussion also mentioned the existence of a work-in-progress implementation in Wasabi. For cases where the payee is a well-known entity, the BIP70 payment protocol with authentication via certificates can be used. However, this protocol does not address the use case where the person in front of you is the only trust anchor. BIP75 and BIP47 protocols were also mentioned as potential solutions, but their limited wallet support is likely due to their relative complexity.The act of copying addresses to the clipboard is discouraged due to security risks, as malware can easily replace addresses with their own. Suggestions were made to implement an address authentication procedure that balances convenience and security. These suggestions include using 2FA, visual fingerprints, and signing the destination address with the key of an already-known address. However, finding a solution that meets both criteria remains a challenge. The discussion also highlighted the need for a convenient mechanism for end-users to transfer an address from a web page to the wallet address input field. Various methods such as QR code scanning and URI intents were suggested, but the adoption of these features may be slow. The BIP70 payment protocol with authentication via certificates was mentioned as a solution for well-known entities, but it does not cover the use case of relying solely on the person in front of you as the trust anchor. 2018-12-01T12:07:40+00:00 + The discussion thread focuses on the need to establish a standard for transferring Bitcoin addresses from web pages or messages to wallet address input fields. Various methods were suggested, including QR code scanning, "bitcoin:" URI intent, and the BIP70 payment protocol. However, concerns were raised about incentivizing users to use copypaste functionality extensively, as it can be easily compromised by crypto hijackers. It was argued that moving to other ways of specifying destinations could also pose security issues. The conversation also touched on BIP75 and BIP47 protocols, which may help with address transfer but have limited wallet support due to their complexity. A work-in-progress implementation exists in Wasabi. Ultimately, the decision whether this needs to be a BIP or not depends on the community's valuation of user experience.In the Bitcoin developer email thread, the issue of transferring an address from a webpage to a wallet address input field was discussed. Suggestions included QR code scanning and using "bitcoin:" URI intent on Android. However, in many cases, addresses are presented as text to copy. Some proposed autodetecting Bitcoin addresses and converting them to "bitcoin:" links, but adoption of this feature may be slow. The conversation also delved into the BIP70, BIP75, and BIP47 payment protocols, with limited wallet support for the latter two due to their complexity. One commenter questioned the need for this to be a BIP, emphasizing that it is more of a UX detail rather than a Bitcoin protocol. They requested further elaboration on the need for documentation. Another commenter raised concerns about incentivizing excessive use of copypaste functionality, but argued that crypto hijackers use the clipboard because it is convenient, not because it is the only method they can hijack. The existence of a work-in-progress implementation in Wasabi was mentioned.The mechanism for end-users to transfer an address from a web page to the wallet address input field was discussed in the thread. Various methods such as QR code scanning, "bitcoin:" URI intent, and BIP70 payment message intent were suggested. However, in many cases, addresses are presented as text for users to copy. There were concerns about incentivizing excessive use of copypaste functionality, countered by the argument that crypto hijackers use the clipboard because it is convenient, not because it is their only method of hijacking. The conversation also touched on crypto hijackers, which was considered off-topic. It was noted that there is a work-in-progress implementation in Wasabi. For well-known entities, the BIP70 payment protocol with authentication via certificates can be used, but it does not cover the use case of relying solely on the person in front of you as the trust anchor. BIP75 and BIP47 protocols may help, but their limited wallet support is attributed to their complexity.There are several mechanisms available for end-users to transfer an address from a web page to the wallet address input field, including QR code scanning, "bitcoin:" URI intent, and BIP70 payment message intent. However, in many cases, addresses are presented as text for users to copy. This raised concerns about incentivizing excessive use of copypaste functionality. On the other hand, it was argued that crypto hijackers use the clipboard because it is convenient, rather than it being their only method of hijacking. The discussion also mentioned the existence of a work-in-progress implementation in Wasabi. For cases where the payee is a well-known entity, the BIP70 payment protocol with authentication via certificates can be used. However, this protocol does not address the use case where the person in front of you is the only trust anchor. BIP75 and BIP47 protocols were also mentioned as potential solutions, but their limited wallet support is likely due to their relative complexity.The act of copying addresses to the clipboard is discouraged due to security risks, as malware can easily replace addresses with their own. Suggestions were made to implement an address authentication procedure that balances convenience and security. These suggestions include using 2FA, visual fingerprints, and signing the destination address with the key of an already-known address. However, finding a solution that meets both criteria remains a challenge. The discussion also highlighted the need for a convenient mechanism for end-users to transfer an address from a web page to the wallet address input field. Various methods such as QR code scanning and URI intents were suggested, but the adoption of these features may be slow. The BIP70 payment protocol with authentication via certificates was mentioned as a solution for well-known entities, but it does not cover the use case of relying solely on the person in front of you as the trust anchor. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_BIP39-seeds.xml b/static/bitcoin-dev/Dec_2018/combined_BIP39-seeds.xml index 965949b257..686e5c4bc1 100644 --- a/static/bitcoin-dev/Dec_2018/combined_BIP39-seeds.xml +++ b/static/bitcoin-dev/Dec_2018/combined_BIP39-seeds.xml @@ -1,50 +1,23 @@ - + 2 Combined summary - BIP39 seeds - 2023-08-02T00:22:41.587136+00:00 - - Aymeric Vitte 2019-01-04 00:02:35+00:00 - - - James MacWhyte 2019-01-02 18:06:08+00:00 - - - Aymeric Vitte 2019-01-01 19:44:57+00:00 - - - Alan Evans 2018-12-31 16:52:24+00:00 - - - Aymeric Vitte 2018-12-27 11:04:18+00:00 - - - James MacWhyte 2018-12-26 18:54:25+00:00 - - - Aymeric Vitte 2018-12-26 11:33:27+00:00 - - - James MacWhyte 2018-12-25 00:30:26+00:00 - - - Tiago Romagnani Silveira 2018-12-24 14:58:43+00:00 - - - Aymeric Vitte 2018-12-23 22:41:00+00:00 - - - Jameson Lopp 2018-12-23 21:08:13+00:00 - - - Eric Scrivner 2018-12-23 20:55:31+00:00 - - - Pavol Rusnak 2018-12-23 18:46:12+00:00 - - - Aymeric Vitte 2018-12-21 23:58:04+00:00 - + 2025-09-26T15:59:17.223403+00:00 + python-feedgen + + + Aymeric Vitte + 2019-01-01T19:44:00.000Z + + + James MacWhyte + 2019-01-02T18:06:00.000Z + + + Aymeric Vitte + 2019-01-04T00:02:00.000Z + + @@ -59,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP39 seeds - 2023-08-02T00:22:41.587136+00:00 + 2025-09-26T15:59:17.223984+00:00 - In a recent online forum post, an individual raised an intriguing question regarding the probability of obtaining a "valid" BIP39 seed from randomly selected words from a 2048 word dictionary. The author expresses surprise at the results and speculates about potential use cases for this information. Curious to know if this topic has been discussed before, they reach out to the community for insights.To support their query, the author includes several links to relevant websites related to Bitcoin and Zcash wallets. These websites offer valuable resources for managing transactions and ensuring privacy. Furthermore, the author shares links to GitHub repositories for various projects such as node-Tor, torrent-live, and dynamic blocklists. These repositories likely provide useful tools and software related to the aforementioned cryptocurrencies.By including these links, the author seeks to foster a comprehensive discussion around the probability of generating a valid BIP39 seed and potential applications for this knowledge. This demonstrates their eagerness to engage with the community and further explore this intriguing subject matter. 2019-01-04T00:02:35+00:00 + In a recent online forum post, an individual raised an intriguing question regarding the probability of obtaining a "valid" BIP39 seed from randomly selected words from a 2048 word dictionary. The author expresses surprise at the results and speculates about potential use cases for this information. Curious to know if this topic has been discussed before, they reach out to the community for insights.To support their query, the author includes several links to relevant websites related to Bitcoin and Zcash wallets. These websites offer valuable resources for managing transactions and ensuring privacy. Furthermore, the author shares links to GitHub repositories for various projects such as node-Tor, torrent-live, and dynamic blocklists. These repositories likely provide useful tools and software related to the aforementioned cryptocurrencies.By including these links, the author seeks to foster a comprehensive discussion around the probability of generating a valid BIP39 seed and potential applications for this knowledge. This demonstrates their eagerness to engage with the community and further explore this intriguing subject matter. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml b/static/bitcoin-dev/Dec_2018/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml index ba0ee494d2..5b40829366 100644 --- a/static/bitcoin-dev/Dec_2018/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml +++ b/static/bitcoin-dev/Dec_2018/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml @@ -1,65 +1,63 @@ - + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 - - Johan Torås Halseth 2019-10-30 07:22:53+00:00 - - - David A. Harding 2019-10-28 17:14:38+00:00 - - - Johan Torås Halseth 2019-10-28 09:45:39+00:00 - - - David A. Harding 2019-10-27 22:54:02+00:00 - - - Jeremy 2019-10-27 19:13:09+00:00 - - - Matt Corallo 2019-10-25 17:30:41+00:00 - - - Johan Torås Halseth 2019-10-25 07:05:15+00:00 - - - Matt Corallo 2019-10-24 21:25:14+00:00 - - - Johan Torås Halseth 2019-10-24 13:49:09+00:00 - - - Rusty Russell 2019-02-13 04:22:39+00:00 - - - Matt Corallo 2019-01-08 14:46:45+00:00 - - - Rusty Russell 2019-01-08 05:50:20+00:00 - - - Matt Corallo 2019-01-07 15:18:52+00:00 - - - Rusty Russell 2018-12-04 03:33:53+00:00 - - - ZmnSCPxj 2018-12-03 04:16:10+00:00 - - - Bob McElrath 2018-12-02 15:08:39+00:00 - - - Matt Corallo 2018-11-30 19:33:56+00:00 - - - Russell O'Connor 2018-11-30 17:38:04+00:00 - - - Matt Corallo 2018-11-29 19:37:54+00:00 - + 2025-09-26T15:59:06.607056+00:00 + python-feedgen + + + Matt Corallo + 2019-01-07T15:18:00.000Z + + + Rusty Russell + 2019-01-08T05:50:00.000Z + + + Matt Corallo + 2019-01-08T14:46:00.000Z + + + Rusty Russell + 2019-02-13T04:22:00.000Z + + + Johan Torås Halseth + 2019-10-24T13:49:00.000Z + + + Matt Corallo + 2019-10-24T21:25:00.000Z + + + Johan Torås Halseth + 2019-10-25T07:05:00.000Z + + + Matt Corallo + 2019-10-25T17:30:00.000Z + + + Jeremy + 2019-10-27T19:13:00.000Z + + + David A. Harding + 2019-10-27T22:54:00.000Z + + + Johan Torås Halseth + 2019-10-28T09:45:00.000Z + + + David A. Harding + 2019-10-28T17:14:00.000Z + + + Johan Torås Halseth + 2019-10-30T07:22:00.000Z + + @@ -79,13 +77,13 @@ - python-feedgen + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 + 2025-09-26T15:59:06.608544+00:00 - In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly 2019-10-30T07:22:53+00:00 + In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_Create-a-BIP-to-implement-Confidential-Transactions-in-Bitcoin-Core.xml b/static/bitcoin-dev/Dec_2018/combined_Create-a-BIP-to-implement-Confidential-Transactions-in-Bitcoin-Core.xml index d3e65ad2ff..b67e7d0f07 100644 --- a/static/bitcoin-dev/Dec_2018/combined_Create-a-BIP-to-implement-Confidential-Transactions-in-Bitcoin-Core.xml +++ b/static/bitcoin-dev/Dec_2018/combined_Create-a-BIP-to-implement-Confidential-Transactions-in-Bitcoin-Core.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Create a BIP to implement Confidential Transactions in Bitcoin Core - 2023-08-02T00:23:44.403047+00:00 - - ZmnSCPxj 2019-01-02 13:39:57+00:00 - - - Kenshiro [] 2018-12-29 11:56:08+00:00 - - - SomberNight 2018-12-28 21:41:51+00:00 - - - Kenshiro [] 2018-12-27 20:15:19+00:00 - + 2025-09-26T15:59:25.682361+00:00 + python-feedgen + + + [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core Kenshiro [] + 2018-12-27T20:15:00.000Z + + + SomberNight + 2018-12-28T21:41:00.000Z + + + Kenshiro [] + 2018-12-29T11:56:00.000Z + + + ZmnSCPxj + 2019-01-02T13:39:00.000Z + + - python-feedgen + 2 Combined summary - Create a BIP to implement Confidential Transactions in Bitcoin Core - 2023-08-02T00:23:44.403047+00:00 + 2025-09-26T15:59:25.683089+00:00 - In an email to the bitcoin-dev mailing list, a user named Kenshiro has requested the creation of a Bitcoin Improvement Proposal (BIP) to implement Confidential Transactions (CT) in Bitcoin Core. Kenshiro believes that CT would provide privacy and fungibility for normal users. They suggest that if the CT transaction size is three times larger than a regular transaction, the block size could also be increased by three times or keep the current block size and make CT transactions optional.However, a recipient of the email, known as SomberNight, disagrees with the idea of requesting the creation of a BIP to implement CT in Bitcoin Core. SomberNight explains that instead of making a request, one should directly create a BIP proposal. They express doubts about achieving consensus for CT implementation in Bitcoin, citing concerns about computational binding and the potential for undetectable inflation. SomberNight references section 4.6 of the Bulletproofs paper, which states that breaking the binding property of the commitment scheme or soundness of the proof system could lead to the generation of coins out of thin air, rendering the currency useless. They also mention the uncertainty surrounding the existence of quantum computers and their potential impact on range proofs for confidential transactions. SomberNight provides a link to the Bulletproofs paper for further reference.The user who suggested CT implementation highlights its successful implementation in Grin and Monero, indicating its maturity for adoption in Bitcoin. They argue that increasing privacy for normal users and ensuring fungibility are key advantages of CT. However, there is no mention of whether the user agrees or disagrees with SomberNight's concerns about computational binding and undetectable inflation. The user proposes either increasing the block size by three times if the CT transaction size is three times larger or keeping the current block size and making CT transactions optional.Overall, there seems to be a difference of opinion regarding the implementation of Confidential Transactions in Bitcoin Core, with one party requesting the creation of a BIP while the other expresses doubts about achieving consensus and raises concerns about potential vulnerabilities. 2019-01-02T13:39:57+00:00 + In an email to the bitcoin-dev mailing list, a user named Kenshiro has requested the creation of a Bitcoin Improvement Proposal (BIP) to implement Confidential Transactions (CT) in Bitcoin Core. Kenshiro believes that CT would provide privacy and fungibility for normal users. They suggest that if the CT transaction size is three times larger than a regular transaction, the block size could also be increased by three times or keep the current block size and make CT transactions optional.However, a recipient of the email, known as SomberNight, disagrees with the idea of requesting the creation of a BIP to implement CT in Bitcoin Core. SomberNight explains that instead of making a request, one should directly create a BIP proposal. They express doubts about achieving consensus for CT implementation in Bitcoin, citing concerns about computational binding and the potential for undetectable inflation. SomberNight references section 4.6 of the Bulletproofs paper, which states that breaking the binding property of the commitment scheme or soundness of the proof system could lead to the generation of coins out of thin air, rendering the currency useless. They also mention the uncertainty surrounding the existence of quantum computers and their potential impact on range proofs for confidential transactions. SomberNight provides a link to the Bulletproofs paper for further reference.The user who suggested CT implementation highlights its successful implementation in Grin and Monero, indicating its maturity for adoption in Bitcoin. They argue that increasing privacy for normal users and ensuring fungibility are key advantages of CT. However, there is no mention of whether the user agrees or disagrees with SomberNight's concerns about computational binding and undetectable inflation. The user proposes either increasing the block size by three times if the CT transaction size is three times larger or keeping the current block size and making CT transactions optional.Overall, there seems to be a difference of opinion regarding the implementation of Confidential Transactions in Bitcoin Core, with one party requesting the creation of a BIP while the other expresses doubts about achieving consensus and raises concerns about potential vulnerabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_How-much-is-too-much-time-between-difficulty-changes-.xml b/static/bitcoin-dev/Dec_2018/combined_How-much-is-too-much-time-between-difficulty-changes-.xml index 5f63f123ab..04612e9f37 100644 --- a/static/bitcoin-dev/Dec_2018/combined_How-much-is-too-much-time-between-difficulty-changes-.xml +++ b/static/bitcoin-dev/Dec_2018/combined_How-much-is-too-much-time-between-difficulty-changes-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - How much is too much time between difficulty changes? - 2023-08-02T00:16:58.473091+00:00 - - Zawy 2018-12-05 14:08:56+00:00 - - - Dave Scotese 2018-12-03 20:37:17+00:00 - + 2025-09-26T15:59:23.567311+00:00 + python-feedgen + + + [bitcoin-dev] How much is too much time between difficulty changes? Dave Scotese + 2018-12-03T20:37:00.000Z + + + Zawy + 2018-12-05T14:08:00.000Z + + - python-feedgen + 2 Combined summary - How much is too much time between difficulty changes? - 2023-08-02T00:16:58.473091+00:00 + 2025-09-26T15:59:23.567816+00:00 - In this context, the author discusses various aspects related to difficulty adjustments in blockchain technology. They propose allowing the difficulty in solving a block to linearly drop as the solvetime exceeds a certain limit, which would be compatible with past delays. This idea could be beneficial for smaller coins that struggle with persistent hash rate changes causing long delays. The author suggests using a daily-rolling average difficulty adjustment, similar to Bitcoin Cash (BCH), as a potential solution. They also mention an interesting research concept called "intra-block" timestamp-based difficulty adjustment, which tightens the Poisson distribution and increases availability at the expense of consistency. However, this approach requires a tight future time limit to prevent timestamp manipulation.The author highlights that currently, three coins have implemented and tested this timestamp-based difficulty adjustment on their testnets. Although the idea may not be necessary for Bitcoin, it is being researched and implemented for other cryptocurrencies. Moving forward, the author raises questions about the time it would take to make changes in block confirmation times and whether a hardfork would be necessary if confirmation times averaged hours or days. They suggest that enough economic interests might align to amass computing power to prioritize important bitcoin transactions, while other cryptocurrencies and technologies like the Lightning Network fill in the gaps. Alternatively, a group could fork the code to adjust the difficulty more rapidly, creating a value for a "Faster-Difficulty-Adjustment" (FDA) version of bitcoin. The author believes that peaceful forking can be learned from previous experiences with Bitcoin Cash and other splits. Lastly, the author emphasizes the importance of gaining insight into how core developers will respond to increasing demands for faster difficulty adjustments.Overall, the author presents ideas and potential solutions for addressing persistent hash rate changes and long delays in smaller coins, while also contemplating the implications and possibilities for Bitcoin's block confirmation times. 2018-12-05T14:08:56+00:00 + In this context, the author discusses various aspects related to difficulty adjustments in blockchain technology. They propose allowing the difficulty in solving a block to linearly drop as the solvetime exceeds a certain limit, which would be compatible with past delays. This idea could be beneficial for smaller coins that struggle with persistent hash rate changes causing long delays. The author suggests using a daily-rolling average difficulty adjustment, similar to Bitcoin Cash (BCH), as a potential solution. They also mention an interesting research concept called "intra-block" timestamp-based difficulty adjustment, which tightens the Poisson distribution and increases availability at the expense of consistency. However, this approach requires a tight future time limit to prevent timestamp manipulation.The author highlights that currently, three coins have implemented and tested this timestamp-based difficulty adjustment on their testnets. Although the idea may not be necessary for Bitcoin, it is being researched and implemented for other cryptocurrencies. Moving forward, the author raises questions about the time it would take to make changes in block confirmation times and whether a hardfork would be necessary if confirmation times averaged hours or days. They suggest that enough economic interests might align to amass computing power to prioritize important bitcoin transactions, while other cryptocurrencies and technologies like the Lightning Network fill in the gaps. Alternatively, a group could fork the code to adjust the difficulty more rapidly, creating a value for a "Faster-Difficulty-Adjustment" (FDA) version of bitcoin. The author believes that peaceful forking can be learned from previous experiences with Bitcoin Cash and other splits. Lastly, the author emphasizes the importance of gaining insight into how core developers will respond to increasing demands for faster difficulty adjustments.Overall, the author presents ideas and potential solutions for addressing persistent hash rate changes and long delays in smaller coins, while also contemplating the implications and possibilities for Bitcoin's block confirmation times. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_Proposal-for-Palindromic-Reversible-Mnemonics.xml b/static/bitcoin-dev/Dec_2018/combined_Proposal-for-Palindromic-Reversible-Mnemonics.xml index 7697e083c9..c70a126893 100644 --- a/static/bitcoin-dev/Dec_2018/combined_Proposal-for-Palindromic-Reversible-Mnemonics.xml +++ b/static/bitcoin-dev/Dec_2018/combined_Proposal-for-Palindromic-Reversible-Mnemonics.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Proposal for Palindromic (Reversible) Mnemonics - 2023-08-02T00:16:45.725822+00:00 - - Steven Hatzakis 2018-12-04 21:39:17+00:00 - - - Steven Hatzakis 2018-12-04 12:42:42+00:00 - - - James MacWhyte 2018-12-04 12:16:12+00:00 - - - Joseph Gleason ⑈ 2018-12-03 20:54:10+00:00 - - - Steven Hatzakis 2018-12-03 18:27:52+00:00 - + 2025-09-26T15:59:10.883406+00:00 + python-feedgen + + + [bitcoin-dev] Proposal for Palindromic (Reversible) Mnemonics Steven Hatzakis + 2018-12-03T18:27:00.000Z + + + Joseph Gleason ⑈ + 2018-12-03T20:54:00.000Z + + + James MacWhyte + 2018-12-04T12:16:00.000Z + + + Steven Hatzakis + 2018-12-04T12:42:00.000Z + + + Steven Hatzakis + 2018-12-04T21:39:00.000Z + + - python-feedgen + 2 Combined summary - Proposal for Palindromic (Reversible) Mnemonics - 2023-08-02T00:16:45.725822+00:00 + 2025-09-26T15:59:10.884117+00:00 - Steven Hatzakis has developed a method to check if a mnemonic is also valid when the words are put into reverse order, where a given 12 or 24-word mnemonic could be valid both in little endian and big endian format. These are called "Palindromic Mnemonics." A checksum-valid reversible mnemonic allows two separate vaults to be connected to the same mnemonic string of words, where all a users must do is enter the words in reverse order to access the secondary (reversed words) vault.This utility could provide multiple use-cases, including related to combinations with passphrases and plausible deniability, as well as conveniences for those wishing to use a separate vault tied to the same string of words. For any randomly generated 12-word mnemonic (128-bits of security) the chances of it also being reversible are 1/16. For a 24-word mnemonic, those values increase to 8 bits which need to match 8 bits from the reversed string, leading to about 1 in every 256 mnemonics also being reversible.While the message space of valid reversible mnemonics should be 2^124 for 12 words, that search must still be conducted over a field of 2 ^128, as the hash-derived checksum values otherwise prevent a way to deterministically find valid reversible mnemonics without first going through invalid reversible ones to check. Some users suggest that if someone is concerned about plausible deniability, then it might make sense to just have the single mnemonic seed lead to a single xprv key (as usual) and then do a private key derivation from that based on a password string. A simple reverse scheme like this would just be another thing a person would know to check if given some seed so they don't see it as providing much value.While others found it interesting, they don't believe there is any security loss, in terms of entropy bits (assuming the initial 128 bits were generated securely). Steven Hatzakis believes that having a mnemonic that is also reversible could be useful for other reasons - convenience related perhaps. He notes that plausible deniability was not the motive but just an example use-case, there are perhaps other use-cases that would be on the user to decide.Steven Hatzakis has already written the code that can be used for testing (on GitHub user @hatgit), and when run from terminal/command prompt it is pretty fast to find a valid reversible mnemonic. However, on IDLE in Python on a 32-bit and 64-bit machine, it could take a few seconds for 12 words and sometimes 10 minutes to find a valid 24-word reversible mnemonic. Steven Hatzakis has two questions: 1) How useful could this be for users/devs/service providers etc.? and 2) Is any security loss occurring and whether it is negligible or not? 2018-12-04T21:39:17+00:00 + Steven Hatzakis has developed a method to check if a mnemonic is also valid when the words are put into reverse order, where a given 12 or 24-word mnemonic could be valid both in little endian and big endian format. These are called "Palindromic Mnemonics." A checksum-valid reversible mnemonic allows two separate vaults to be connected to the same mnemonic string of words, where all a users must do is enter the words in reverse order to access the secondary (reversed words) vault.This utility could provide multiple use-cases, including related to combinations with passphrases and plausible deniability, as well as conveniences for those wishing to use a separate vault tied to the same string of words. For any randomly generated 12-word mnemonic (128-bits of security) the chances of it also being reversible are 1/16. For a 24-word mnemonic, those values increase to 8 bits which need to match 8 bits from the reversed string, leading to about 1 in every 256 mnemonics also being reversible.While the message space of valid reversible mnemonics should be 2^124 for 12 words, that search must still be conducted over a field of 2 ^128, as the hash-derived checksum values otherwise prevent a way to deterministically find valid reversible mnemonics without first going through invalid reversible ones to check. Some users suggest that if someone is concerned about plausible deniability, then it might make sense to just have the single mnemonic seed lead to a single xprv key (as usual) and then do a private key derivation from that based on a password string. A simple reverse scheme like this would just be another thing a person would know to check if given some seed so they don't see it as providing much value.While others found it interesting, they don't believe there is any security loss, in terms of entropy bits (assuming the initial 128 bits were generated securely). Steven Hatzakis believes that having a mnemonic that is also reversible could be useful for other reasons - convenience related perhaps. He notes that plausible deniability was not the motive but just an example use-case, there are perhaps other use-cases that would be on the user to decide.Steven Hatzakis has already written the code that can be used for testing (on GitHub user @hatgit), and when run from terminal/command prompt it is pretty fast to find a valid reversible mnemonic. However, on IDLE in Python on a 32-bit and 64-bit machine, it could take a few seconds for 12 words and sometimes 10 minutes to find a valid 24-word reversible mnemonic. Steven Hatzakis has two questions: 1) How useful could this be for users/devs/service providers etc.? and 2) Is any security loss occurring and whether it is negligible or not? - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_Safer-NOINPUT-with-output-tagging.xml b/static/bitcoin-dev/Dec_2018/combined_Safer-NOINPUT-with-output-tagging.xml index 1091eec635..bb870562ba 100644 --- a/static/bitcoin-dev/Dec_2018/combined_Safer-NOINPUT-with-output-tagging.xml +++ b/static/bitcoin-dev/Dec_2018/combined_Safer-NOINPUT-with-output-tagging.xml @@ -1,95 +1,67 @@ - + 2 Combined summary - Safer NOINPUT with output tagging - 2023-08-02T00:18:41.848463+00:00 - - Johnson Lau 2019-02-19 20:36:51+00:00 - - - Luke Dashjr 2019-02-19 20:24:12+00:00 - - - Johnson Lau 2019-02-19 19:22:07+00:00 - - - Luke Dashjr 2019-02-19 19:04:03+00:00 - - - Anthony Towns 2019-02-10 04:46:30+00:00 - - - Johnson Lau 2019-02-09 17:43:50+00:00 - - - Jonas Nick 2019-02-09 16:54:09+00:00 - - - Jonas Nick 2019-02-09 16:52:07+00:00 - - - Johnson Lau 2019-02-09 16:48:40+00:00 - - - Johnson Lau 2019-02-09 10:15:17+00:00 - - - Alejandro Ranchal Pedrosa 2019-02-09 10:01:20+00:00 - - - Jonas Nick 2019-02-08 19:01:40+00:00 - - - ZmnSCPxj 2019-02-01 09:36:50+00:00 - - - Anthony Towns 2019-01-31 06:04:05+00:00 - - - ZmnSCPxj 2018-12-24 11:47:38+00:00 - - - Johnson Lau 2018-12-22 16:56:29+00:00 - - - ZmnSCPxj 2018-12-22 14:25:16+00:00 - - - Johnson Lau 2018-12-21 16:21:42+00:00 - - - Johnson Lau 2018-12-21 15:37:05+00:00 - - - ZmnSCPxj 2018-12-21 11:40:06+00:00 - - - Christian Decker 2018-12-21 11:15:37+00:00 - - - Johnson Lau 2018-12-20 18:04:37+00:00 - - - Christian Decker 2018-12-20 17:20:54+00:00 - - - Johnson Lau 2018-12-20 11:00:53+00:00 - - - Christian Decker 2018-12-19 22:09:50+00:00 - - - Johnson Lau 2018-12-18 10:48:40+00:00 - - - Johnson Lau 2018-12-17 20:08:55+00:00 - - - Ruben Somsen 2018-12-17 15:48:15+00:00 - - - Johnson Lau 2018-12-13 12:32:44+00:00 - + 2025-09-26T15:59:08.762489+00:00 + python-feedgen + + + Anthony Towns + 2019-01-31T06:04:00.000Z + + + ZmnSCPxj + 2019-02-01T09:36:00.000Z + + + Jonas Nick + 2019-02-08T19:01:00.000Z + + + Alejandro Ranchal Pedrosa + 2019-02-09T10:01:00.000Z + + + Johnson Lau + 2019-02-09T10:15:00.000Z + + + Johnson Lau + 2019-02-09T16:48:00.000Z + + + Jonas Nick + 2019-02-09T16:52:00.000Z + + + Jonas Nick + 2019-02-09T16:54:00.000Z + + + Johnson Lau + 2019-02-09T17:43:00.000Z + + + Anthony Towns + 2019-02-10T04:46:00.000Z + + + Luke Dashjr + 2019-02-19T19:04:00.000Z + + + Johnson Lau + 2019-02-19T19:22:00.000Z + + + Luke Dashjr + 2019-02-19T20:24:00.000Z + + + Johnson Lau + 2019-02-19T20:36:00.000Z + + @@ -119,13 +91,13 @@ - python-feedgen + 2 Combined summary - Safer NOINPUT with output tagging - 2023-08-02T00:18:41.848463+00:00 + 2025-09-26T15:59:08.764070+00:00 - The discussion on the bitcoin-dev mailing list revolves around various aspects of implementing a wallet that prevents address reuse and the compatibility of such a feature with NOINPUT. Johnson Lau suggests that addressing address reuse should be a social agreement between the payer and the payee, as it cannot be banned at the protocol level. He proposes publishing the key after a coin is confirmed as a stronger way to prevent address reuse. Luke Dashjr argues against implementing a nanny in the protocol, stating that it limits developers who want certain features. He also highlights the issue of address reuse rejection when using NOINPUT for everything.The acceptability of address reuse in Bitcoin transactions depends on the contract between the payer and payee and cannot be banned at the protocol level. NOINPUT, which allows multiple transactions to spend the same output, has limitations and risks associated with it. To prevent accidental double payments, Lau suggests tagging outputs to make them spendable with NOINPUT. Two possible ways to tag are discussed: setting a certain bit in the tx version or scriptPubKey. Each method has its advantages and disadvantages. The tradeoff between smart contracts and dumb contracts is also mentioned, with the aim of finding a design that enables desired smart contracts while minimizing misuse risks.The discussion also delves into the compatibility of tagging with multiparty eltoo channels, settlement transactions, and various attack scenarios. Alejandro Ranchal Pedrosa proposes Transaction Fragments as a solution to an eltoo-like protocol that works without going on-chain when participants' actions cannot be predicted in advance. Signature replay risks associated with NOINPUT are addressed, and Lau suggests extending version tagging to enhance NOINPUT safety.Another topic of discussion is the potential impact of tagging on fungibility in multiparty eltoo channels. A solution is proposed where settlement transactions are created with different locktimes, and the branch channel is opened on a tagged output. If cooperative channel closing is desired, it can be done on an untagged output without using NOINPUT to avoid fungibility loss.The bitcoin-dev community plays a vital role in identifying and addressing potential issues related to proposals like NOINPUT and ensuring compatibility between various proposals. The aim is to maintain the stability and security of the Bitcoin network while enabling desired smart contracts and minimizing risks.In a recent email exchange between Christian Decker and Johnson Lau, they discussed the use of OP_CSV (BIP112) in a 2-of-2 branch. It was argued that BIP68 relative locktime is not necessary since both parties need to agree on it. However, with taproot, the use of BIP68 actually saves more than just a few bytes. The conversation also discussed the idea of tagging an output to make it spendable with NOINPUT, which is compatible with eltoo. This would allow for walletless offchain software, where on-chain wallets can directly put their funds into an off-chain system without requiring an on-chain transfer. However, there are concerns regarding address reuse, dual-funding, and the need for a standard way of signing transactions without broadcasting them.The discussion also delved into the process of setting up, updating, and closing a Lightning Network channel using eltoo. This involves creating a setup transaction, followed by update transactions and a settlement transaction. Collaborative close and unilateral close were explained as different scenarios depending on the agreement between parties. The number of transactions involved depends on whether cheating occurs.Johnson Lau further explained the process of setting up and closing a payment channel between two parties using Bitcoin. This involves multiple steps, including creating setup, update, and settlement transactions. The concept of collaborative close and unilateral close was explained, along with the number of transactions involved depending on the scenario.The bitcoin-dev mailing list also discussed the design considerations of a channel setup using BIP118, 143, and 141-P2WSH without taproot. The compatibility of this setup with Statechains was explored, as well as the impact on fungibility if taproot was added. It was clarified that combining the trigger and setup transactions is not currently possible, and the purpose of having separate timeouts would be defeated if they were combined.Concerns were raised about the compatibility of NOINPUT with proposals such as Graftroot and Statechains, as well as the impact on fungibility if Taproot was added to Eltoo. The discussion also explored the use of output tagging and NOINPUT in the context of Eltoo and Statechains. The tradeoff between privacy, complexity, and fungibility was considered.In another email exchange, Johnson Lau discussed the risks of signature replay associated with NOINPUT and proposed a solution of "tagging" outputs that are spendable with NOINPUT. Two possible ways of tagging outputs were mentioned, either by setting a certain bit in the tx version or scriptPubKey. The implications of tagging for fungibility were discussed, along with the advantages and limitations of each tagging method. The philosophy behind output tagging was to avoid using NOINPUT unless absolutely necessary.Overall, the discussions focused on the 2019-02-19T20:36:51+00:00 + The discussion on the bitcoin-dev mailing list revolves around various aspects of implementing a wallet that prevents address reuse and the compatibility of such a feature with NOINPUT. Johnson Lau suggests that addressing address reuse should be a social agreement between the payer and the payee, as it cannot be banned at the protocol level. He proposes publishing the key after a coin is confirmed as a stronger way to prevent address reuse. Luke Dashjr argues against implementing a nanny in the protocol, stating that it limits developers who want certain features. He also highlights the issue of address reuse rejection when using NOINPUT for everything.The acceptability of address reuse in Bitcoin transactions depends on the contract between the payer and payee and cannot be banned at the protocol level. NOINPUT, which allows multiple transactions to spend the same output, has limitations and risks associated with it. To prevent accidental double payments, Lau suggests tagging outputs to make them spendable with NOINPUT. Two possible ways to tag are discussed: setting a certain bit in the tx version or scriptPubKey. Each method has its advantages and disadvantages. The tradeoff between smart contracts and dumb contracts is also mentioned, with the aim of finding a design that enables desired smart contracts while minimizing misuse risks.The discussion also delves into the compatibility of tagging with multiparty eltoo channels, settlement transactions, and various attack scenarios. Alejandro Ranchal Pedrosa proposes Transaction Fragments as a solution to an eltoo-like protocol that works without going on-chain when participants' actions cannot be predicted in advance. Signature replay risks associated with NOINPUT are addressed, and Lau suggests extending version tagging to enhance NOINPUT safety.Another topic of discussion is the potential impact of tagging on fungibility in multiparty eltoo channels. A solution is proposed where settlement transactions are created with different locktimes, and the branch channel is opened on a tagged output. If cooperative channel closing is desired, it can be done on an untagged output without using NOINPUT to avoid fungibility loss.The bitcoin-dev community plays a vital role in identifying and addressing potential issues related to proposals like NOINPUT and ensuring compatibility between various proposals. The aim is to maintain the stability and security of the Bitcoin network while enabling desired smart contracts and minimizing risks.In a recent email exchange between Christian Decker and Johnson Lau, they discussed the use of OP_CSV (BIP112) in a 2-of-2 branch. It was argued that BIP68 relative locktime is not necessary since both parties need to agree on it. However, with taproot, the use of BIP68 actually saves more than just a few bytes. The conversation also discussed the idea of tagging an output to make it spendable with NOINPUT, which is compatible with eltoo. This would allow for walletless offchain software, where on-chain wallets can directly put their funds into an off-chain system without requiring an on-chain transfer. However, there are concerns regarding address reuse, dual-funding, and the need for a standard way of signing transactions without broadcasting them.The discussion also delved into the process of setting up, updating, and closing a Lightning Network channel using eltoo. This involves creating a setup transaction, followed by update transactions and a settlement transaction. Collaborative close and unilateral close were explained as different scenarios depending on the agreement between parties. The number of transactions involved depends on whether cheating occurs.Johnson Lau further explained the process of setting up and closing a payment channel between two parties using Bitcoin. This involves multiple steps, including creating setup, update, and settlement transactions. The concept of collaborative close and unilateral close was explained, along with the number of transactions involved depending on the scenario.The bitcoin-dev mailing list also discussed the design considerations of a channel setup using BIP118, 143, and 141-P2WSH without taproot. The compatibility of this setup with Statechains was explored, as well as the impact on fungibility if taproot was added. It was clarified that combining the trigger and setup transactions is not currently possible, and the purpose of having separate timeouts would be defeated if they were combined.Concerns were raised about the compatibility of NOINPUT with proposals such as Graftroot and Statechains, as well as the impact on fungibility if Taproot was added to Eltoo. The discussion also explored the use of output tagging and NOINPUT in the context of Eltoo and Statechains. The tradeoff between privacy, complexity, and fungibility was considered.In another email exchange, Johnson Lau discussed the risks of signature replay associated with NOINPUT and proposed a solution of "tagging" outputs that are spendable with NOINPUT. Two possible ways of tagging outputs were mentioned, either by setting a certain bit in the tx version or scriptPubKey. The implications of tagging for fungibility were discussed, along with the advantages and limitations of each tagging method. The philosophy behind output tagging was to avoid using NOINPUT unless absolutely necessary.Overall, the discussions focused on the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml b/static/bitcoin-dev/Dec_2018/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml index 4e8d0ace44..a1a29a7e4b 100644 --- a/static/bitcoin-dev/Dec_2018/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml +++ b/static/bitcoin-dev/Dec_2018/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml @@ -1,173 +1,15 @@ - + 2 Combined summary - Safer sighashes and more granular SIGHASH_NOINPUT - 2023-08-02T00:02:39.338876+00:00 - - Pieter Wuille 2019-02-09 00:39:54+00:00 - - - Johnson Lau 2018-12-24 21:23:44+00:00 - - - ZmnSCPxj 2018-12-24 12:01:58+00:00 - - - Johnson Lau 2018-12-23 16:33:48+00:00 - - - Anthony Towns 2018-12-23 04:26:59+00:00 - - - Johnson Lau 2018-12-21 18:54:42+00:00 - - - Rusty Russell 2018-12-20 23:17:15+00:00 - - - Johnson Lau 2018-12-20 19:34:38+00:00 - - - Rusty Russell 2018-12-19 00:39:26+00:00 - - - Peter Todd 2018-12-18 04:22:58+00:00 - - - Johnson Lau 2018-12-17 19:08:26+00:00 - - - Rusty Russell 2018-12-17 03:10:42+00:00 - - - Rusty Russell 2018-12-16 06:55:48+00:00 - - - Johnson Lau 2018-12-14 13:55:43+00:00 - - - Anthony Towns 2018-12-14 09:30:02+00:00 - - - Anthony Towns 2018-12-14 00:47:29+00:00 - - - Russell O'Connor 2018-12-13 16:50:10+00:00 - - - Russell O'Connor 2018-12-13 16:34:17+00:00 - - - Russell O'Connor 2018-12-13 16:21:10+00:00 - - - Rusty Russell 2018-12-13 00:37:28+00:00 - - - Anthony Towns 2018-12-13 00:24:38+00:00 - - - Anthony Towns 2018-12-13 00:05:53+00:00 - - - Rusty Russell 2018-12-12 23:49:02+00:00 - - - Johnson Lau 2018-12-12 20:00:50+00:00 - - - Johnson Lau 2018-12-12 19:53:38+00:00 - - - Rusty Russell 2018-12-12 09:42:10+00:00 - - - Russell O'Connor 2018-12-11 22:50:24+00:00 - - - David A. Harding 2018-12-11 17:47:24+00:00 - - - Russell O'Connor 2018-12-11 15:36:59+00:00 - - - David A. Harding 2018-12-09 22:41:57+00:00 - - - Johnson Lau 2018-12-09 19:13:34+00:00 - - - Russell O'Connor 2018-12-06 16:57:09+00:00 - - - Christian Decker 2018-11-29 18:29:10+00:00 - - - Christian Decker 2018-11-29 17:00:09+00:00 - - - Bob McElrath 2018-11-28 14:04:13+00:00 - - - Johnson Lau 2018-11-28 08:40:34+00:00 - - - Johnson Lau 2018-11-28 08:31:48+00:00 - - - Pieter Wuille 2018-11-28 03:41:02+00:00 - - - Bob McElrath 2018-11-28 00:54:16+00:00 - - - Johnson Lau 2018-11-24 08:13:46+00:00 - - - Russell O'Connor 2018-11-23 20:18:13+00:00 - - - Johnson Lau 2018-11-23 10:47:10+00:00 - - - Christian Decker 2018-11-23 09:40:20+00:00 - - - Anthony Towns 2018-11-23 06:04:04+00:00 - - - Anthony Towns 2018-11-23 05:03:30+00:00 - - - Russell O'Connor 2018-11-22 22:10:11+00:00 - - - Johnson Lau 2018-11-22 20:52:54+00:00 - - - Russell O'Connor 2018-11-22 16:23:54+00:00 - - - Johnson Lau 2018-11-22 14:28:35+00:00 - - - Johnson Lau 2018-11-21 17:55:22+00:00 - - - Russell O'Connor 2018-11-21 17:07:30+00:00 - - - Christian Decker 2018-11-21 11:20:44+00:00 - - - Christian Decker 2018-11-21 11:15:44+00:00 - - - Anthony Towns 2018-11-20 20:29:04+00:00 - - - Pieter Wuille 2018-11-19 22:37:57+00:00 - + 2025-09-26T15:59:21.450309+00:00 + python-feedgen + + + Pieter Wuille + 2019-02-09T00:39:00.000Z + + @@ -223,13 +65,13 @@ - python-feedgen + 2 Combined summary - Safer sighashes and more granular SIGHASH_NOINPUT - 2023-08-02T00:02:39.340876+00:00 + 2025-09-26T15:59:21.450718+00:00 - In recent discussions among Bitcoin developers, several proposals and considerations were raised regarding the Bitcoin protocol. Pieter Wuille raised concerns about the reuse of OP_MASK and SIGHASH_NOINPUT, with the latter posing a greater risk. Realistic risks associated with NOINPUT were discussed, and output tagging was suggested as an alternative. A proposed script involving CODESEPARATOR was presented, which could eliminate the need for certain cases under taproot. The use of CODESEPARATOR for Scriptless Script without Schnorr was also mentioned.There were debates on the usefulness of OP_CODESEPARATOR under Taproot. Some argued that committing to the masked script is not necessary if best practices are followed, while others believed that using IF+CODESEP approach could be cheaper for certain scripts. The usability and security of OP_CODESEPARATOR with NOINPUT were questioned, but its usefulness in some cases was acknowledged.The discussions also touched upon witness weight malleability in Bitcoin Script and the proposal to use a 64-byte signature for the default "signing all" sighash. There were concerns about estimating witness weight in multisig cases. The discussion explored the possibility of transforming any script into an equivalent one that avoids witness weight malleability.The role of scriptmask in a taproot world and its tradeoff with security were discussed. Opcodes like IF, NOTIF, VERIFY, DROP, and arithmetic opcodes accepting CScriptNum inputs posed challenges. Suggestions were made to eliminate witness weight malleability in practice through policies and consensus enforcement.The discussions also covered topics such as the implementation of covenants/vaults using NOINPUT, changes to Bitcoin script, the efficiency of the sighash cache, and the removal of OP_CODESEPARATOR.In summary, the discussions revolved around various proposals and considerations related to Bitcoin Script, including mask complexity, witness weight malleability, sighash flags, opcodes, and their impact on security and functionality. The ongoing efforts of the Bitcoin development community to improve the efficiency, security, and flexibility of the Bitcoin protocol were reflected in these discussions.The Bitcoin development community is currently exploring options for replacing OP_CODESEPARATOR, which takes a significant amount of time to execute. One suggestion is to add an internal counter that increments with every control flow operator, allowing signatures to cover the value of this counter or the index of the block within the Bitcoin Script program. The community is open to any solution that can replace the functionality of OP_CODESEPARATOR.Anthony Towns, a member of the Bitcoin development community, has raised concerns about the implementation of NOINPUT in the BIP 118 specification. He suggests that implementing NOINPUT implies the ANYONECANPAY feature, but removing the blanking of the 'hashSequence' field may affect this implication. Christian, another community member, agrees that there may not be a good use case for keeping the number of inputs with NOINPUT.Pieter Wuille, a Bitcoin Core developer, has proposed additions to the sighash for future segwit versions. These additions include committing to the absolute transaction fee and scriptPubKey in addition to the scriptCode. To prevent lying about the type of output being spent, these additions are made optional. Wuille's proposal introduces three new sighash flags: SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK. He also suggests adding a new opcode, OP_MASK, which acts as a NOP during execution.The computation of the sighash would follow the BIP143 method, with modifications based on the presence of the new flags. If SIGHASH_SCRIPTMASK is present, every subsequent opcode/push after an OP_MASK in scriptCode is removed. The scriptPubKey being spent is added to the sighash unless SIGHASH_SCRIPTMASK is set. The transaction fee is added to the sighash unless SIGHASH_NOFEE is set. Additionally, when SIGHASH_NOINPUT is set, hashPrevouts, hashSequence, and outpoint are set to null.Christian expresses concern about introducing a new opcode to mask things in the sighash, but considers it a minor issue. He also notes that Wuille's proposal may address some downsides of BIP118 by committing to the script when possible. Wuille seeks feedback on whether his proposal introduces redundant flexibility or overlooks any obvious use cases.In summary, Pieter Wuille proposes three new sighash flags, namely SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK, along with the addition of a new opcode called OP_MASK. These additions aim to enhance the functionality of the sighash in future segwit versions. The proposal suggests specific modifications to the sighash computation process, including the addition of transaction fee and scriptPubKey commitment. The community is encouraged to provide feedback on these proposals and identify any potential issues or use cases that may have been overlooked. 2019-02-09T00:39:54+00:00 + In recent discussions among Bitcoin developers, several proposals and considerations were raised regarding the Bitcoin protocol. Pieter Wuille raised concerns about the reuse of OP_MASK and SIGHASH_NOINPUT, with the latter posing a greater risk. Realistic risks associated with NOINPUT were discussed, and output tagging was suggested as an alternative. A proposed script involving CODESEPARATOR was presented, which could eliminate the need for certain cases under taproot. The use of CODESEPARATOR for Scriptless Script without Schnorr was also mentioned.There were debates on the usefulness of OP_CODESEPARATOR under Taproot. Some argued that committing to the masked script is not necessary if best practices are followed, while others believed that using IF+CODESEP approach could be cheaper for certain scripts. The usability and security of OP_CODESEPARATOR with NOINPUT were questioned, but its usefulness in some cases was acknowledged.The discussions also touched upon witness weight malleability in Bitcoin Script and the proposal to use a 64-byte signature for the default "signing all" sighash. There were concerns about estimating witness weight in multisig cases. The discussion explored the possibility of transforming any script into an equivalent one that avoids witness weight malleability.The role of scriptmask in a taproot world and its tradeoff with security were discussed. Opcodes like IF, NOTIF, VERIFY, DROP, and arithmetic opcodes accepting CScriptNum inputs posed challenges. Suggestions were made to eliminate witness weight malleability in practice through policies and consensus enforcement.The discussions also covered topics such as the implementation of covenants/vaults using NOINPUT, changes to Bitcoin script, the efficiency of the sighash cache, and the removal of OP_CODESEPARATOR.In summary, the discussions revolved around various proposals and considerations related to Bitcoin Script, including mask complexity, witness weight malleability, sighash flags, opcodes, and their impact on security and functionality. The ongoing efforts of the Bitcoin development community to improve the efficiency, security, and flexibility of the Bitcoin protocol were reflected in these discussions.The Bitcoin development community is currently exploring options for replacing OP_CODESEPARATOR, which takes a significant amount of time to execute. One suggestion is to add an internal counter that increments with every control flow operator, allowing signatures to cover the value of this counter or the index of the block within the Bitcoin Script program. The community is open to any solution that can replace the functionality of OP_CODESEPARATOR.Anthony Towns, a member of the Bitcoin development community, has raised concerns about the implementation of NOINPUT in the BIP 118 specification. He suggests that implementing NOINPUT implies the ANYONECANPAY feature, but removing the blanking of the 'hashSequence' field may affect this implication. Christian, another community member, agrees that there may not be a good use case for keeping the number of inputs with NOINPUT.Pieter Wuille, a Bitcoin Core developer, has proposed additions to the sighash for future segwit versions. These additions include committing to the absolute transaction fee and scriptPubKey in addition to the scriptCode. To prevent lying about the type of output being spent, these additions are made optional. Wuille's proposal introduces three new sighash flags: SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK. He also suggests adding a new opcode, OP_MASK, which acts as a NOP during execution.The computation of the sighash would follow the BIP143 method, with modifications based on the presence of the new flags. If SIGHASH_SCRIPTMASK is present, every subsequent opcode/push after an OP_MASK in scriptCode is removed. The scriptPubKey being spent is added to the sighash unless SIGHASH_SCRIPTMASK is set. The transaction fee is added to the sighash unless SIGHASH_NOFEE is set. Additionally, when SIGHASH_NOINPUT is set, hashPrevouts, hashSequence, and outpoint are set to null.Christian expresses concern about introducing a new opcode to mask things in the sighash, but considers it a minor issue. He also notes that Wuille's proposal may address some downsides of BIP118 by committing to the script when possible. Wuille seeks feedback on whether his proposal introduces redundant flexibility or overlooks any obvious use cases.In summary, Pieter Wuille proposes three new sighash flags, namely SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK, along with the addition of a new opcode called OP_MASK. These additions aim to enhance the functionality of the sighash in future segwit versions. The proposal suggests specific modifications to the sighash computation process, including the addition of transaction fee and scriptPubKey commitment. The community is encouraged to provide feedback on these proposals and identify any potential issues or use cases that may have been overlooked. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_Schnorr-and-taproot-etc-upgrade.xml b/static/bitcoin-dev/Dec_2018/combined_Schnorr-and-taproot-etc-upgrade.xml index 2852b752ba..d3dc89fa50 100644 --- a/static/bitcoin-dev/Dec_2018/combined_Schnorr-and-taproot-etc-upgrade.xml +++ b/static/bitcoin-dev/Dec_2018/combined_Schnorr-and-taproot-etc-upgrade.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Schnorr and taproot (etc) upgrade - 2023-08-02T00:22:05.367725+00:00 - - Johnson Lau 2018-12-18 10:00:59+00:00 - - - Anthony Towns 2018-12-18 04:58:26+00:00 - - - Russell O'Connor 2018-12-18 03:18:40+00:00 - - - Johnson Lau 2018-12-17 20:16:12+00:00 - - - Russell O'Connor 2018-12-15 23:38:46+00:00 - - - Anthony Towns 2018-12-14 10:48:39+00:00 - + 2025-09-26T15:59:19.335049+00:00 + python-feedgen + + + [bitcoin-dev] Schnorr and taproot (etc) upgrade Anthony Towns + 2018-12-14T10:48:00.000Z + + + Russell O'Connor + 2018-12-15T23:38:00.000Z + + + Johnson Lau + 2018-12-17T20:16:00.000Z + + + Russell O'Connor + 2018-12-18T03:18:00.000Z + + + Anthony Towns + 2018-12-18T04:58:00.000Z + + + Johnson Lau + 2018-12-18T10:00:00.000Z + + - python-feedgen + 2 Combined summary - Schnorr and taproot (etc) upgrade - 2023-08-02T00:22:05.367725+00:00 + 2025-09-26T15:59:19.335874+00:00 - In an email thread among developers, the possibility of disabling CHECKSIG and CHECKMULTISIG in favor of using CHECKDLS, CHECKDLSVERIFY, and CHECKDLSADD was discussed. This change would cause issues with copying script templates from v0 to v1. Additionally, there was a suggestion to pop the stack after OP_CLTV and OP_CSV to save weight units. However, this change could affect constructions that avoid the DROP. The developers acknowledged the potential tech debt but did not have strong opinions on the topic.During a discussion between Russell O'Connor and Johnson Lau, it was suggested that disabling CHECKSIG* and CHECKMULTISIG* in favor of CHECKDLS, CHECKDLSVERIFY, and CHECKDLSADD with different names and opcodes would result in script template failures. It was also proposed to pop the stack after OP_CLTV and OP_CSV to save weight units. Although these suggestions were considered bikeshedding, having identical semantics for opcodes in v0 and v1 scripts was seen as beneficial. However, constructions that rely on an expected true value on the stack would not work if an empty stack is required.Johnson Lau proposed a change to Bitcoin Improvement Proposal (BIP) 114 in an email conversation dated December 17, 2018. He expressed concerns about potential consequences, such as people losing money by copying existing script templates. Lau also suggested popping the stack after OP_CLTV and OP_CSV to save weight units. The decision on implementing these changes remained uncertain.Russell O'Connor proposed a change to the Script language in Bitcoin in a bitcoin-dev mailing list. The proposal aimed to require an exactly empty stack for success, eliminating the need for special logic to handle top-level CHECKSIG versus mid-level CHECKSIGVERIFY. O'Connor acknowledged similarities to his previous proposal in BIP114 but expressed uncertainty about potential negative consequences. Another related topic brought up was popping the stack after OP_CLTV and OP_CSV.Anthony Towns suggested a change to script composition in a discussion among developers on the bitcoin-dev mailing list. The proposal was to require an exactly empty stack for success, making the script more composable and eliminating the need for special logic. This suggestion prompted further discussion on the mailing list.The article discusses potential improvements to the Bitcoin system, including a new segwit version, different length segwit v1 public keys, a new segwit v1 script version, and additional opcodes. Changes proposed include introducing 33-byte v1 witness addresses that encode a secp256k1 ECC point and using new Schnorr ops to replace ECDSA CHECKSIG/CHECKMULTISIG ops. The author notes that these changes are modest compared to other possibilities such as graftroot and cross-input signature aggregation. The article also provides an example of how Eltoo could work in a taproot world and describes preparing HTLC outputs for SHA256 preimages and secp256k1 preimages. The suggestion is made to implement simple OP_SUCCESS upgrades alongside schnorr/taproot/etc. independently at the BIP/concept/implementation levels. 2018-12-18T10:00:59+00:00 + In an email thread among developers, the possibility of disabling CHECKSIG and CHECKMULTISIG in favor of using CHECKDLS, CHECKDLSVERIFY, and CHECKDLSADD was discussed. This change would cause issues with copying script templates from v0 to v1. Additionally, there was a suggestion to pop the stack after OP_CLTV and OP_CSV to save weight units. However, this change could affect constructions that avoid the DROP. The developers acknowledged the potential tech debt but did not have strong opinions on the topic.During a discussion between Russell O'Connor and Johnson Lau, it was suggested that disabling CHECKSIG* and CHECKMULTISIG* in favor of CHECKDLS, CHECKDLSVERIFY, and CHECKDLSADD with different names and opcodes would result in script template failures. It was also proposed to pop the stack after OP_CLTV and OP_CSV to save weight units. Although these suggestions were considered bikeshedding, having identical semantics for opcodes in v0 and v1 scripts was seen as beneficial. However, constructions that rely on an expected true value on the stack would not work if an empty stack is required.Johnson Lau proposed a change to Bitcoin Improvement Proposal (BIP) 114 in an email conversation dated December 17, 2018. He expressed concerns about potential consequences, such as people losing money by copying existing script templates. Lau also suggested popping the stack after OP_CLTV and OP_CSV to save weight units. The decision on implementing these changes remained uncertain.Russell O'Connor proposed a change to the Script language in Bitcoin in a bitcoin-dev mailing list. The proposal aimed to require an exactly empty stack for success, eliminating the need for special logic to handle top-level CHECKSIG versus mid-level CHECKSIGVERIFY. O'Connor acknowledged similarities to his previous proposal in BIP114 but expressed uncertainty about potential negative consequences. Another related topic brought up was popping the stack after OP_CLTV and OP_CSV.Anthony Towns suggested a change to script composition in a discussion among developers on the bitcoin-dev mailing list. The proposal was to require an exactly empty stack for success, making the script more composable and eliminating the need for special logic. This suggestion prompted further discussion on the mailing list.The article discusses potential improvements to the Bitcoin system, including a new segwit version, different length segwit v1 public keys, a new segwit v1 script version, and additional opcodes. Changes proposed include introducing 33-byte v1 witness addresses that encode a secp256k1 ECC point and using new Schnorr ops to replace ECDSA CHECKSIG/CHECKMULTISIG ops. The author notes that these changes are modest compared to other possibilities such as graftroot and cross-input signature aggregation. The article also provides an example of how Eltoo could work in a taproot world and describes preparing HTLC outputs for SHA256 preimages and secp256k1 preimages. The suggestion is made to implement simple OP_SUCCESS upgrades alongside schnorr/taproot/etc. independently at the BIP/concept/implementation levels. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2018/combined_draft-proposal-change-forwarding-improved-fungibility-through-wallet-interoperability-.xml b/static/bitcoin-dev/Dec_2018/combined_draft-proposal-change-forwarding-improved-fungibility-through-wallet-interoperability-.xml index 6180a4788e..d0b16a9c02 100644 --- a/static/bitcoin-dev/Dec_2018/combined_draft-proposal-change-forwarding-improved-fungibility-through-wallet-interoperability-.xml +++ b/static/bitcoin-dev/Dec_2018/combined_draft-proposal-change-forwarding-improved-fungibility-through-wallet-interoperability-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - draft proposal: change forwarding (improved fungibility through wallet interoperability) - 2023-08-01T23:57:16.773016+00:00 - - Yuval Kogman 2018-12-01 15:33:52+00:00 - - - James MacWhyte 2018-12-01 05:06:29+00:00 - - - Yuval Kogman 2018-11-06 15:50:38+00:00 - + 2025-09-26T15:59:12.994757+00:00 + python-feedgen + + + [bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability) Yuval Kogman + 2018-11-06T15:50:00.000Z + + + James MacWhyte + 2018-12-01T05:06:00.000Z + + + Yuval Kogman + 2018-12-01T15:33:00.000Z + + - python-feedgen + 2 Combined summary - draft proposal: change forwarding (improved fungibility through wallet interoperability) - 2023-08-01T23:57:16.773016+00:00 + 2025-09-26T15:59:12.995376+00:00 - In an email thread on the bitcoin-dev mailing list, a proposed method based on BIP32 to improve fungibility and on-chain privacy with wallets that don't prioritize these factors was questioned by James. He sought clarification on the user experience (UX) and how wallet developers could implement this feature. James also raised doubts about why a privacy-conscious user would choose a non-private wallet in the first place, and why a non-privacy-conscious user would bother enabling this option. He expressed skepticism about the proposal's usefulness from a product standpoint and questioned its need to be a BIP.The proposal, introduced by Yuval Kogman, aims to enhance fungibility and on-chain privacy in wallets that do not focus on these aspects. It suggests making minimal changes to safely forward change outputs to more specialized wallets. The draft proposal is still incomplete, with unresolved questions regarding the specific format to use. However, Yuval included two viable options in the proposal, seeking input and criticism from the mailing list. They also mentioned that the proposal is intended to complement more comprehensive proposals like BIP79.Yuval acknowledged the contributions of SirMeow, Adam Ficsor, and Adam Gibson, who reviewed earlier versions of the proposal and provided valuable feedback and suggestions. While Yuval has a slight preference for the first option presented in the proposal, they remain undecided due to tradeoffs. Hence, Yuval reached out to the mailing list for further insights and opinions. 2018-12-01T15:33:52+00:00 + In an email thread on the bitcoin-dev mailing list, a proposed method based on BIP32 to improve fungibility and on-chain privacy with wallets that don't prioritize these factors was questioned by James. He sought clarification on the user experience (UX) and how wallet developers could implement this feature. James also raised doubts about why a privacy-conscious user would choose a non-private wallet in the first place, and why a non-privacy-conscious user would bother enabling this option. He expressed skepticism about the proposal's usefulness from a product standpoint and questioned its need to be a BIP.The proposal, introduced by Yuval Kogman, aims to enhance fungibility and on-chain privacy in wallets that do not focus on these aspects. It suggests making minimal changes to safely forward change outputs to more specialized wallets. The draft proposal is still incomplete, with unresolved questions regarding the specific format to use. However, Yuval included two viable options in the proposal, seeking input and criticism from the mailing list. They also mentioned that the proposal is intended to complement more comprehensive proposals like BIP79.Yuval acknowledged the contributions of SirMeow, Adam Ficsor, and Adam Gibson, who reviewed earlier versions of the proposal and provided valuable feedback and suggestions. While Yuval has a slight preference for the first option presented in the proposal, they remain undecided due to tradeoffs. Hence, Yuval reached out to the mailing list for further insights and opinions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_Analysis-of-Bech32-swap-insert-delete-detection-and-next-steps.xml b/static/bitcoin-dev/Dec_2019/combined_Analysis-of-Bech32-swap-insert-delete-detection-and-next-steps.xml index abb112296e..df5db0a212 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Analysis-of-Bech32-swap-insert-delete-detection-and-next-steps.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Analysis-of-Bech32-swap-insert-delete-detection-and-next-steps.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Analysis of Bech32 swap/insert/delete detection and next steps - 2023-08-02T01:42:19.625908+00:00 - - Pieter Wuille 2019-12-10 06:36:20+00:00 - - - ZmnSCPxj 2019-12-10 01:50:38+00:00 - - - Pieter Wuille 2019-12-09 22:31:13+00:00 - + 2025-09-26T16:01:50.243962+00:00 + python-feedgen + + + [bitcoin-dev] Analysis of Bech32 swap/insert/delete detection and next steps Pieter Wuille + 2019-12-09T22:31:00.000Z + + + ZmnSCPxj + 2019-12-10T01:50:00.000Z + + + Pieter Wuille + 2019-12-10T06:36:00.000Z + + - python-feedgen + 2 Combined summary - Analysis of Bech32 swap/insert/delete detection and next steps - 2023-08-02T01:42:19.625908+00:00 + 2025-09-26T16:01:50.244538+00:00 - Pieter, in a detailed analysis, has examined the detection abilities of Bech32, a type of address format used in cryptocurrencies. He found that the only deviation from the expected failure to detect errors occurs when a 'q' is inserted or deleted right before a final 'p'. This specific issue can be resolved by changing one constant in Bech32 without affecting its ability to detect other types of errors.To address this insertion weakness, Pieter suggests making several changes. Firstly, he recommends adding an erratum section to BIP173, which is the Bitcoin Improvement Proposal for Bech32 addresses, to document the issue and its analysis. This would help raise awareness and provide guidance on how to handle this weakness.Secondly, Pieter proposes amending SegWit addresses, which are a type of address format used in Bitcoin, to restrict them to only length 20 or 32. By doing so, the addresses will become fixed-length strings and will be unaffected by the insertion issue. This change would enhance the security and reliability of SegWit addresses.In addition, Pieter suggests defining a variant of Bech32 with the modified constant. This would allow non-BIP173 uses of Bech32 to choose a version that is not impacted by this particular class of errors. It provides flexibility for those who are concerned about the insertion weakness but still want to use Bech32 for their applications.Furthermore, Pieter highlights the importance of defining two variants of checksum for readers of Bech32-based formats. Both variants should be supported to ensure compatibility. The current Bech32 checksum should be flagged or signaled with a deprecation warning if detected, and at some point in the future, support for the current checksum should be dropped. These measures would help transition smoothly to the modified Bech32 variant.Lastly, Pieter suggests that using the modified Bech32 variant should only be implemented if there is a need for non-32-byte witness programs for a particular non-zero SegWit version. This ensures that the modified variant is used appropriately and only when necessary.Pieter believes that implementing these changes will have minimal impact on production systems, as many wallets already do not accept unknown witness versions in outputs. He also mentions that it gives us probably years to adapt to the updated address scheme. Overall, these proposed steps aim to address the insertion weakness issue in BIP173 and SegWit addresses, enhancing the security and reliability of Bech32-based formats. 2019-12-10T06:36:20+00:00 + Pieter, in a detailed analysis, has examined the detection abilities of Bech32, a type of address format used in cryptocurrencies. He found that the only deviation from the expected failure to detect errors occurs when a 'q' is inserted or deleted right before a final 'p'. This specific issue can be resolved by changing one constant in Bech32 without affecting its ability to detect other types of errors.To address this insertion weakness, Pieter suggests making several changes. Firstly, he recommends adding an erratum section to BIP173, which is the Bitcoin Improvement Proposal for Bech32 addresses, to document the issue and its analysis. This would help raise awareness and provide guidance on how to handle this weakness.Secondly, Pieter proposes amending SegWit addresses, which are a type of address format used in Bitcoin, to restrict them to only length 20 or 32. By doing so, the addresses will become fixed-length strings and will be unaffected by the insertion issue. This change would enhance the security and reliability of SegWit addresses.In addition, Pieter suggests defining a variant of Bech32 with the modified constant. This would allow non-BIP173 uses of Bech32 to choose a version that is not impacted by this particular class of errors. It provides flexibility for those who are concerned about the insertion weakness but still want to use Bech32 for their applications.Furthermore, Pieter highlights the importance of defining two variants of checksum for readers of Bech32-based formats. Both variants should be supported to ensure compatibility. The current Bech32 checksum should be flagged or signaled with a deprecation warning if detected, and at some point in the future, support for the current checksum should be dropped. These measures would help transition smoothly to the modified Bech32 variant.Lastly, Pieter suggests that using the modified Bech32 variant should only be implemented if there is a need for non-32-byte witness programs for a particular non-zero SegWit version. This ensures that the modified variant is used appropriately and only when necessary.Pieter believes that implementing these changes will have minimal impact on production systems, as many wallets already do not accept unknown witness versions in outputs. He also mentions that it gives us probably years to adapt to the updated address scheme. Overall, these proposed steps aim to address the insertion weakness issue in BIP173 and SegWit addresses, enhancing the security and reliability of Bech32-based formats. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml b/static/bitcoin-dev/Dec_2019/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml index 94e1116eb0..09309839d2 100644 --- a/static/bitcoin-dev/Dec_2019/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml +++ b/static/bitcoin-dev/Dec_2019/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml @@ -1,53 +1,55 @@ - + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.880650+00:00 - - Jeremy 2020-09-03 17:47:35+00:00 - - - Jeremy 2020-09-03 17:34:15+00:00 - - - Dmitry Petukhov 2020-09-03 14:42:23+00:00 - - - Dmitry Petukhov 2020-06-08 06:05:45+00:00 - - - Jeremy 2020-06-07 22:45:16+00:00 - - - Joachim Strömbergson 2020-06-07 16:51:10+00:00 - - - ZmnSCPxj 2020-02-15 00:24:37+00:00 - - - Jeremy 2020-02-14 19:16:26+00:00 - - - Dmitry Petukhov 2020-02-14 11:18:26+00:00 - - - Jeremy 2019-12-19 20:08:03+00:00 - - - Jeremy 2019-12-13 23:06:59+00:00 - - - Jeremy 2019-12-11 00:37:59+00:00 - - - Jeremy 2019-11-28 19:59:42+00:00 - - - Russell O'Connor 2019-11-27 21:32:51+00:00 - - - Jeremy 2019-11-26 01:50:40+00:00 - + 2025-09-26T16:01:54.477157+00:00 + python-feedgen + + + Dmitry Petukhov + 2020-02-14T11:18:00.000Z + + + Jeremy + 2020-02-14T19:16:00.000Z + + + ZmnSCPxj + 2020-02-15T00:24:00.000Z + + + Joachim Strömbergson + 2020-06-07T16:51:00.000Z + + + Jeremy + 2020-06-07T22:45:00.000Z + + + Dmitry Petukhov + 2020-06-08T06:05:00.000Z + + + [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation Jeremy + 2020-06-08T06:43:00.000Z + + + Dmitry Petukhov + 2020-06-08T07:15:00.000Z + + + Dmitry Petukhov + 2020-09-03T14:42:00.000Z + + + Jeremy + 2020-09-03T17:34:00.000Z + + + Jeremy + 2020-09-03T17:47:00.000Z + + @@ -63,13 +65,13 @@ - python-feedgen + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.881652+00:00 + 2025-09-26T16:01:54.478596+00:00 - In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast 2020-09-03T17:47:35+00:00 + In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_Base64-encoded-descriptors.xml b/static/bitcoin-dev/Dec_2019/combined_Base64-encoded-descriptors.xml index 45a53b620e..2b91cd9426 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Base64-encoded-descriptors.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Base64-encoded-descriptors.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Base64-encoded descriptors - 2023-08-02T01:42:42.528074+00:00 - - Andrew Chow 2019-12-26 05:18:00+00:00 - - - William Casarin 2019-12-25 17:17:18+00:00 - - - Trey Del Bonis 2019-12-25 01:02:09+00:00 - - - Pavol Rusnak 2019-12-24 19:25:02+00:00 - - - Spencer Dupre` 2019-12-24 19:09:33+00:00 - - - Chris Belcher 2019-12-24 17:06:01+00:00 - + 2025-09-26T16:01:56.568171+00:00 + python-feedgen + + + [bitcoin-dev] Base64-encoded descriptors Chris Belcher + 2019-12-24T17:06:00.000Z + + + Spencer Dupre + 2019-12-24T19:09:00.000Z + + + Pavol Rusnak + 2019-12-24T19:25:00.000Z + + + Trey Del Bonis + 2019-12-25T01:02:00.000Z + + + William Casarin + 2019-12-25T17:17:00.000Z + + + Andrew Chow + 2019-12-26T05:18:00.000Z + + - python-feedgen + 2 Combined summary - Base64-encoded descriptors - 2023-08-02T01:42:42.528074+00:00 + 2025-09-26T16:01:56.568995+00:00 - The Bitcoin community is discussing ways to make descriptors easier to handle for users. Currently, the syntax of descriptors, which include commas, parentheses, and brackets, can be intimidating and difficult to work with. One possible solution is to encode descriptors using Base64, although some community members prefer alternatives like Bech32, Base58, or Base62 due to their user-friendly nature.However, it is important to consider the checksum scheme used by encoding methods like Base58 and Bech32, as they already exist and may not be compatible with descriptors. Descriptors have their own BCH code for descriptor checksums that are optimized for their length and character set. This suggests that the descriptor checksum can be repurposed to work with any encoding scheme, as long as the encoding's character set is covered by the descriptor checksum character set. The descriptor checksum covers all characters on a standard keyboard, allowing for future expansion of descriptors.Chris Belcher, a developer at bitcoin-dev, proposed that descriptors should become the standard for master public keys. However, he acknowledges that the current syntax of descriptors makes it difficult for users to copy and paste them for creating watch-only wallets. The presence of parentheses and commas prevents highlighting by double-clicking, and the syntax can be overwhelming for new users. One solution suggested during discussions with Chris is to base64 encode the descriptors, resulting in a text blob as the master public key without any extra details. This would simplify the process for users and developers alike.Another developer named Will disagrees with encoding descriptors, arguing that it obfuscates useful information that can be quickly viewed. He suggests using alternative encoding methods like base58 or base62 +hrp for PSBT, as they are better suited for double-click copying and pasting. Will also prefers Bech32, base58, or base62 and believes that encoding descriptors does not make much sense in this case.In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the use of bech32 for error detection in longer messages. While bech32 can still encode and decode perfectly well, it cannot guarantee detecting errors beyond a certain length. To address this issue, it was suggested to define derivatives of bech32 that retain error detection properties for longer message lengths, particularly for lightning invoices. It is worth noting that QR codes have their own BCH code scheme for built-in error detection, mitigating this problem when used with descriptors.Despite the usefulness of descriptors, some members expressed skepticism about their practicality for quick transactions, which are well-suited for QR codes. The discussion also touched upon the use of base64 encoding for descriptors as a standard for master public keys. While this encoding method simplifies working with descriptors, there are concerns about the potential for typos in the base64 text decoding into multiple character errors in the descriptor. To overcome this, it was suggested to attach the checksum to the end of the base64 text.Overall, the Bitcoin community is exploring ways to enhance the usability and efficiency of descriptors. Base64 encoding has been proposed as a solution to make descriptors more user-friendly, but complications regarding the descriptor checksum need to be addressed. Discussions with developers like achow101 have contributed to these ideas. Additionally, alternatives to Base64, such as Base58 or Bech32, have been suggested for URL/QR code friendly purposes. 2019-12-26T05:18:00+00:00 + The Bitcoin community is discussing ways to make descriptors easier to handle for users. Currently, the syntax of descriptors, which include commas, parentheses, and brackets, can be intimidating and difficult to work with. One possible solution is to encode descriptors using Base64, although some community members prefer alternatives like Bech32, Base58, or Base62 due to their user-friendly nature.However, it is important to consider the checksum scheme used by encoding methods like Base58 and Bech32, as they already exist and may not be compatible with descriptors. Descriptors have their own BCH code for descriptor checksums that are optimized for their length and character set. This suggests that the descriptor checksum can be repurposed to work with any encoding scheme, as long as the encoding's character set is covered by the descriptor checksum character set. The descriptor checksum covers all characters on a standard keyboard, allowing for future expansion of descriptors.Chris Belcher, a developer at bitcoin-dev, proposed that descriptors should become the standard for master public keys. However, he acknowledges that the current syntax of descriptors makes it difficult for users to copy and paste them for creating watch-only wallets. The presence of parentheses and commas prevents highlighting by double-clicking, and the syntax can be overwhelming for new users. One solution suggested during discussions with Chris is to base64 encode the descriptors, resulting in a text blob as the master public key without any extra details. This would simplify the process for users and developers alike.Another developer named Will disagrees with encoding descriptors, arguing that it obfuscates useful information that can be quickly viewed. He suggests using alternative encoding methods like base58 or base62 +hrp for PSBT, as they are better suited for double-click copying and pasting. Will also prefers Bech32, base58, or base62 and believes that encoding descriptors does not make much sense in this case.In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the use of bech32 for error detection in longer messages. While bech32 can still encode and decode perfectly well, it cannot guarantee detecting errors beyond a certain length. To address this issue, it was suggested to define derivatives of bech32 that retain error detection properties for longer message lengths, particularly for lightning invoices. It is worth noting that QR codes have their own BCH code scheme for built-in error detection, mitigating this problem when used with descriptors.Despite the usefulness of descriptors, some members expressed skepticism about their practicality for quick transactions, which are well-suited for QR codes. The discussion also touched upon the use of base64 encoding for descriptors as a standard for master public keys. While this encoding method simplifies working with descriptors, there are concerns about the potential for typos in the base64 text decoding into multiple character errors in the descriptor. To overcome this, it was suggested to attach the checksum to the end of the base64 text.Overall, the Bitcoin community is exploring ways to enhance the usability and efficiency of descriptors. Base64 encoding has been proposed as a solution to make descriptors more user-friendly, but complications regarding the descriptor checksum need to be addressed. Discussions with developers like achow101 have contributed to these ideas. Additionally, alternatives to Base64, such as Base58 or Bech32, have been suggested for URL/QR code friendly purposes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_Blind-Merged-Mining-with-covenants-sighash-anyprevout-op-ctv-.xml b/static/bitcoin-dev/Dec_2019/combined_Blind-Merged-Mining-with-covenants-sighash-anyprevout-op-ctv-.xml index e09d5528d5..0cbd960292 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Blind-Merged-Mining-with-covenants-sighash-anyprevout-op-ctv-.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Blind-Merged-Mining-with-covenants-sighash-anyprevout-op-ctv-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv ) - 2023-08-02T01:42:59.533107+00:00 - - Ruben Somsen 2019-12-26 16:52:43+00:00 - - - Nick Gregory 2019-12-26 12:32:26+00:00 - - - Ruben Somsen 2019-12-26 02:23:10+00:00 - + 2025-09-26T16:02:00.748524+00:00 + python-feedgen + + + [bitcoin-dev] Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv ) Ruben Somsen + 2019-12-26T02:23:00.000Z + + + Nick Gregory + 2019-12-26T12:32:00.000Z + + + Ruben Somsen + 2019-12-26T16:52:00.000Z + + - python-feedgen + 2 Combined summary - Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv ) - 2023-08-02T01:42:59.533107+00:00 + 2025-09-26T16:02:00.749040+00:00 - Blind Merged Mining (BMM) is a decentralized consensus mechanism proposed by Ruben Somsen that allows external blockchains to outsource their mining to the Bitcoin blockchain. This mechanism involves miners committing the hash of another blockchain into a unique location on the Bitcoin blockchain, and in return, they are paid with Bitcoin fees for capturing the fees inside the other blockchain. The purpose of BMM is to increase the total Proof of Work (PoW) on the Bitcoin blockchain, thereby enhancing its security.One key aspect of BMM is that it does not require any additional validation from miners. Instead, they only need to choose the highest bidder. This makes the implementation of BMM relatively straightforward. A complete transaction flow diagram for BMM can be found in a GitHub link provided in the context.In order for the BMM chain to function, it will need some kind of native token to pay for fees. The fairest and least speculation-inducing method proposed is a perpetual one-way peg, where 1 BTC can be burned for 1 token at any time, thus preserving the 21M coin limit.However, there may be challenges in moving the BMM chain forward due to the lack of a block subsidy. This raises the question of whether enacting a reorg would be a more viable option. BMM reorgs have a unique characteristic in that they will have to compete for the same unique location that the original chain is using. As a result, a 10-block reorg would take an average of 100 minutes to catch up, during which the original chain would not move forward. Whether this mitigation is sufficient remains an open question.Another consideration is whether BMM interferes too much with the existing incentive structure of Bitcoin. While the exact signature is committed ahead of time in BMM, private key security is irrelevant. Assuming taproot, the spending script will be inside a taproot leaf, which means that a key spend path should be made unusable to enforce the covenant. This can be achieved with a NUMS, such as hashToCurve(G) = H, which can then be used as the internal taproot key T = H + hash(H||bmm_hash)*G.Overall, BMM offers interesting possibilities for decentralized consensus and the outsourcing of mining work from external blockchains to the Bitcoin blockchain. It remains to be seen how this mechanism will be adopted and whether it will have a significant impact on the existing incentive structure of Bitcoin. 2019-12-26T16:52:43+00:00 + Blind Merged Mining (BMM) is a decentralized consensus mechanism proposed by Ruben Somsen that allows external blockchains to outsource their mining to the Bitcoin blockchain. This mechanism involves miners committing the hash of another blockchain into a unique location on the Bitcoin blockchain, and in return, they are paid with Bitcoin fees for capturing the fees inside the other blockchain. The purpose of BMM is to increase the total Proof of Work (PoW) on the Bitcoin blockchain, thereby enhancing its security.One key aspect of BMM is that it does not require any additional validation from miners. Instead, they only need to choose the highest bidder. This makes the implementation of BMM relatively straightforward. A complete transaction flow diagram for BMM can be found in a GitHub link provided in the context.In order for the BMM chain to function, it will need some kind of native token to pay for fees. The fairest and least speculation-inducing method proposed is a perpetual one-way peg, where 1 BTC can be burned for 1 token at any time, thus preserving the 21M coin limit.However, there may be challenges in moving the BMM chain forward due to the lack of a block subsidy. This raises the question of whether enacting a reorg would be a more viable option. BMM reorgs have a unique characteristic in that they will have to compete for the same unique location that the original chain is using. As a result, a 10-block reorg would take an average of 100 minutes to catch up, during which the original chain would not move forward. Whether this mitigation is sufficient remains an open question.Another consideration is whether BMM interferes too much with the existing incentive structure of Bitcoin. While the exact signature is committed ahead of time in BMM, private key security is irrelevant. Assuming taproot, the spending script will be inside a taproot leaf, which means that a key spend path should be made unusable to enforce the covenant. This can be achieved with a NUMS, such as hashToCurve(G) = H, which can then be used as the internal taproot key T = H + hash(H||bmm_hash)*G.Overall, BMM offers interesting possibilities for decentralized consensus and the outsourcing of mining work from external blockchains to the Bitcoin blockchain. It remains to be seen how this mechanism will be adopted and whether it will have a significant impact on the existing incentive structure of Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_Composable-MuSig.xml b/static/bitcoin-dev/Dec_2019/combined_Composable-MuSig.xml index bbe7c973a1..8ef24326c8 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Composable-MuSig.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Composable-MuSig.xml @@ -1,38 +1,27 @@ - + 2 Combined summary - Composable MuSig - 2023-08-02T01:34:08.477767+00:00 - - Tim Ruffing 2020-02-24 16:56:06+00:00 - - - Erik Aronesty 2020-02-24 15:30:54+00:00 - - - Tim Ruffing 2020-02-24 11:16:38+00:00 - - - Erik Aronesty 2020-02-23 07:27:39+00:00 - - - Lloyd Fournier 2019-12-08 06:10:00+00:00 - - - ZmnSCPxj 2019-12-08 01:15:51+00:00 - - - Lloyd Fournier 2019-12-02 03:30:26+00:00 - - - ZmnSCPxj 2019-12-02 02:05:01+00:00 - - - Lloyd Fournier 2019-11-29 05:50:33+00:00 - - - ZmnSCPxj 2019-11-25 11:00:22+00:00 - + 2025-09-26T16:01:58.657776+00:00 + python-feedgen + + + Erik Aronesty + 2020-02-23T07:27:00.000Z + + + Tim Ruffing + 2020-02-24T11:16:00.000Z + + + Erik Aronesty + 2020-02-24T15:30:00.000Z + + + Tim Ruffing + 2020-02-24T16:56:00.000Z + + @@ -43,13 +32,13 @@ - python-feedgen + 2 Combined summary - Composable MuSig - 2023-08-02T01:34:08.477767+00:00 + 2025-09-26T16:01:58.658369+00:00 - The discussion on the bitcoin-dev mailing list focuses on preventing repeated signings of the same message and using a "validity" time window to limit an attacker's control. The Drijvers, et al paper addresses parallel and aborted signings, where ksums can be used. Adding a signature timeout to the message is proposed as a solution, where participants refuse to sign if the time is too far in the future or if a message has been used previously within that time window.There are concerns about the safety of two-phase MuSig, with reference to a paper arguing it may be unsafe due to the number of parallel sessions. It is suggested that using 3-round MuSig could eliminate this issue.The MuSig protocol is discussed, highlighting its vulnerability to attacks when used in compositions. A proposal called Multi-R is introduced to address this problem by allowing participants to submit multiple R commitments. Alternative proposals involving Pedersen or ElGamal commitments are also mentioned but found to have security flaws.A composable commitment scheme appropriate for MuSig R coin tossing is discussed, with the author stating that deeper analysis is needed to determine the requirements of MuSig for the commitment scheme. The author suggests that Schnorr and ECDSA signatures can be viewed as commitment schemes on points and proposes using them as composable commitments in a MuSig scheme.Pedersen commitments are discussed in relation to MuSig R coin tossing, suggesting that using `X` committed with Pedersen commitments in place of `q * G` in an ElGamal commitment can prevent cancellation attacks. However, alternative methods involving Schnorr signatures and using contributions `R[a]` and `R[b]` as public keys are also suggested, albeit with increased complexity.The MuSig composition problem is addressed, emphasizing the need for the three-phase MuSig protocol instead of the potentially unsafe two-phase variant when one participant is an aggregate entity. The potential security issues of the two-phase protocol and the Wagner Generalized Birthday Paradox attack are highlighted. The Multi-R proposal is suggested as a modification to address this vulnerability.The Lightning Nodelets proposal on lightning-dev is discussed, mentioning the use of MuSig on public keys of participants and the need for one or more participants to be an aggregate entity. The MuSig composition problem arises when there is a possibility of participant equality. The three-phase MuSig protocol is described, along with its potential vulnerabilities and proposed solutions such as the Multi-R proposal.Overall, the discussion focuses on addressing the security flaws of the MuSig protocol, proposing various solutions including signature timeouts, multi-round MuSig, composable commitment schemes, and modifications to the protocol structure. 2020-02-24T16:56:06+00:00 + The discussion on the bitcoin-dev mailing list focuses on preventing repeated signings of the same message and using a "validity" time window to limit an attacker's control. The Drijvers, et al paper addresses parallel and aborted signings, where ksums can be used. Adding a signature timeout to the message is proposed as a solution, where participants refuse to sign if the time is too far in the future or if a message has been used previously within that time window.There are concerns about the safety of two-phase MuSig, with reference to a paper arguing it may be unsafe due to the number of parallel sessions. It is suggested that using 3-round MuSig could eliminate this issue.The MuSig protocol is discussed, highlighting its vulnerability to attacks when used in compositions. A proposal called Multi-R is introduced to address this problem by allowing participants to submit multiple R commitments. Alternative proposals involving Pedersen or ElGamal commitments are also mentioned but found to have security flaws.A composable commitment scheme appropriate for MuSig R coin tossing is discussed, with the author stating that deeper analysis is needed to determine the requirements of MuSig for the commitment scheme. The author suggests that Schnorr and ECDSA signatures can be viewed as commitment schemes on points and proposes using them as composable commitments in a MuSig scheme.Pedersen commitments are discussed in relation to MuSig R coin tossing, suggesting that using `X` committed with Pedersen commitments in place of `q * G` in an ElGamal commitment can prevent cancellation attacks. However, alternative methods involving Schnorr signatures and using contributions `R[a]` and `R[b]` as public keys are also suggested, albeit with increased complexity.The MuSig composition problem is addressed, emphasizing the need for the three-phase MuSig protocol instead of the potentially unsafe two-phase variant when one participant is an aggregate entity. The potential security issues of the two-phase protocol and the Wagner Generalized Birthday Paradox attack are highlighted. The Multi-R proposal is suggested as a modification to address this vulnerability.The Lightning Nodelets proposal on lightning-dev is discussed, mentioning the use of MuSig on public keys of participants and the need for one or more participants to be an aggregate entity. The MuSig composition problem arises when there is a possibility of participant equality. The three-phase MuSig protocol is described, along with its potential vulnerabilities and proposed solutions such as the Multi-R proposal.Overall, the discussion focuses on addressing the security flaws of the MuSig protocol, proposing various solutions including signature timeouts, multi-round MuSig, composable commitment schemes, and modifications to the protocol structure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_Human-readable-format-for-private-keys.xml b/static/bitcoin-dev/Dec_2019/combined_Human-readable-format-for-private-keys.xml index 2709963509..bdb326770c 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Human-readable-format-for-private-keys.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Human-readable-format-for-private-keys.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Human readable format for private keys - 2023-08-02T01:28:16.279158+00:00 - - JW Weatherman 2019-12-10 02:11:10+00:00 - - - JW Weatherman 2019-10-05 22:51:20+00:00 - + 2025-09-26T16:02:02.838722+00:00 + python-feedgen + + + [bitcoin-dev] Human readable format for private keys JW Weatherman + 2019-10-05T22:51:00.000Z + + + JW Weatherman + 2019-12-10T02:11:00.000Z + + - python-feedgen + 2 Combined summary - Human readable format for private keys - 2023-08-02T01:28:16.279158+00:00 + 2025-09-26T16:02:02.839157+00:00 - JW Weatherman has proposed a feature for Bitcoin that aims to solve issues related to private keys. Currently, mistakes can be made when reading or writing private keys, and errors are only identified once the entire key is entered. This lack of error indication and the potential loss of private keys stored on paper due to the loss of a single character pose significant problems.To address these issues, JW Weatherman suggests using the NATO phonetic alphabet to display or enter private keys. In this system, lower case letters are indicated by not capitalizing the word, while capital letters and numbers should be capitalized. The use of the internationally recognized NATO phonetic alphabet ensures that each letter is easily distinguishable when spoken and written, reducing the likelihood of errors during recovery.The proposal also includes the insertion of checksum letters into the private key. Specifically, every 5th word in the key would serve as a checksum for the previous 4 words. For example, a sentence like "ALFA tango THREE SIX bravo" would have "bravo" as the checksum for the preceding 4 words. This checksum can be calculated and verified as the private key is entered. If an error is made, the checksum would immediately indicate it within the 5-word segment. Moreover, even if an entire word is lost across multiple lines, the checksum would make it relatively easy to guess the correct words.During a live demonstration, JW Weatherman showcased the use of the NATO alphabet and checksums every 4 words. This approach removes the stress of attempting to write unambiguous characters and makes typing with autocomplete easier, particularly when the word dictionary is not involved.The proposal seeks adoption by Bitcoin Core as it utilizes existing private keys without impacting key generation. Furthermore, it does not require a standardized and well-known word list for every language. Essentially, this proposal serves as a display format that ideally would not necessitate invasive code changes. 2019-12-10T02:11:10+00:00 + JW Weatherman has proposed a feature for Bitcoin that aims to solve issues related to private keys. Currently, mistakes can be made when reading or writing private keys, and errors are only identified once the entire key is entered. This lack of error indication and the potential loss of private keys stored on paper due to the loss of a single character pose significant problems.To address these issues, JW Weatherman suggests using the NATO phonetic alphabet to display or enter private keys. In this system, lower case letters are indicated by not capitalizing the word, while capital letters and numbers should be capitalized. The use of the internationally recognized NATO phonetic alphabet ensures that each letter is easily distinguishable when spoken and written, reducing the likelihood of errors during recovery.The proposal also includes the insertion of checksum letters into the private key. Specifically, every 5th word in the key would serve as a checksum for the previous 4 words. For example, a sentence like "ALFA tango THREE SIX bravo" would have "bravo" as the checksum for the preceding 4 words. This checksum can be calculated and verified as the private key is entered. If an error is made, the checksum would immediately indicate it within the 5-word segment. Moreover, even if an entire word is lost across multiple lines, the checksum would make it relatively easy to guess the correct words.During a live demonstration, JW Weatherman showcased the use of the NATO alphabet and checksums every 4 words. This approach removes the stress of attempting to write unambiguous characters and makes typing with autocomplete easier, particularly when the word dictionary is not involved.The proposal seeks adoption by Bitcoin Core as it utilizes existing private keys without impacting key generation. Furthermore, it does not require a standardized and well-known word list for every language. Essentially, this proposal serves as a display format that ideally would not necessitate invasive code changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_Non-equal-value-CoinJoins-Opinions-.xml b/static/bitcoin-dev/Dec_2019/combined_Non-equal-value-CoinJoins-Opinions-.xml index 1026e4f997..98b7771998 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Non-equal-value-CoinJoins-Opinions-.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Non-equal-value-CoinJoins-Opinions-.xml @@ -1,35 +1,15 @@ - + 2 Combined summary - Non-equal value CoinJoins. Opinions. - 2023-08-02T01:43:31.866332+00:00 - - nopara73 2020-02-22 18:01:14+00:00 - - - Lucas Ontivero 2019-12-30 01:14:19+00:00 - - - Yuval Kogman 2019-12-29 17:48:38+00:00 - - - ZmnSCPxj 2019-12-29 10:23:39+00:00 - - - Yuval Kogman 2019-12-29 09:57:48+00:00 - - - Yuval Kogman 2019-12-29 03:31:48+00:00 - - - ZmnSCPxj 2019-12-28 23:25:07+00:00 - - - Ethan Heilman 2019-12-28 17:38:11+00:00 - - - nopara73 2019-12-27 18:03:49+00:00 - + 2025-09-26T16:02:04.927038+00:00 + python-feedgen + + + nopara73 + 2020-02-22T18:01:00.000Z + + @@ -39,13 +19,13 @@ - python-feedgen + 2 Combined summary - Non-equal value CoinJoins. Opinions. - 2023-08-02T01:43:31.866332+00:00 + 2025-09-26T16:02:04.927385+00:00 - In a recent email conversation between Ádám Ficsór and ZmnSCPxj, the topic of non-equal value CoinJoins and their privacy implications was discussed. The conversation focused on a paragraph from the CashFusion specification that claimed there is essentially no linkage with 10^92 possibilities. However, ZmnSCPxj argued that most users would not have the same output value of "around 1 BTC" in a real live mainnet scenario. He suggested that if the math requires equal-valued outputs per user, it would be more practical to use equal-valued CoinJoins. ZmnSCPxj also pointed out that change outputs in equal-valued CoinJoins have similar linkability to CashFusion outputs. The CashFusion research proposes a combinatorial approach to avoid amount linkages in non-equal value CoinJoins, but ZmnSCPxj argues that it is not as effective as equal-outputs transactions. The Knapsack paper in 2017 also had a similar idea, splitting original outputs into partitions that match selected groups of outputs. However, the simulation showed exponential growth in the number of valid transactions, making it impossible to determine the real ones. Additionally, there are concerns about the effectiveness and security of this mechanism. In contrast, Knapsack provides a general solution with good mathematical backing and has been backtested against historical data from Bitcoin's blockchain. Overall, Knapsack is currently considered the best solution for unequal inputs/outputs CoinJoins.The limitations of CoinJoin and ZeroLink protocols in terms of preventing linkage between pre- and post-mix coins were discussed in the email thread. The author proposed a new protocol that introduces chaumian reissuable/redenominatable tokens as an intermediary stage between input/output phases. This allows for unequal amounts while retaining the advantages of fixed denominations. The protocol includes several subtypes of mixing rounds and suggests subsidizing mining fees and batching to preserve exact denomination sizes. The author also mentions the possibility of keeping low hamming weight outputs virtual to make the approach size-efficient, but further exploration is needed.Another email conversation between Yuval and ZmnSCPxj focused on privacy issues related to CoinJoin transactions. They discussed broader criticisms of CoinJoin-based privacy and the assertion of 0 linkability. ZmnSCPxj expressed concern about perspectives that analyze linkability information in isolation, as the post/pre mix transaction graph presents a more complex problem. They mentioned ZeroLink protocol as a solution, but noted that it is not purely implemented in Wasabi and still has some privacy concerns. Equal-valued CoinJoins were suggested as a solution with a Chaumian bank constraining value transfers. CashFusion was also discussed, but there are doubts about its privacy guarantees and the involvement of a server.In an email exchange, Yuval Kogman made a mistake in his calculation regarding the number of inputs and indistinguishable outputs. He later corrected himself, stating that n is actually the smaller of the two numbers. While this correction did not affect his arguments, it was important to clarify the mistake.In a bitcoin-dev email thread, nopara73 responded to a document about CoinJoin-based privacy called "The Breaking of Mixing Secrets". They questioned the premises and implications of the document, highlighting the potential efficiency of computational strategies in deanonymization. Nopara73 also expressed concerns about analyzing linkability information in isolation and mentioned Cash Fusion's extension of obfuscation by allowing multiple inputs and outputs. They cautiously mentioned the potential of small popcounts/Hamming weights and the use of OP_CHECKTEMPLATEVERIFY and Taproot to mitigate overhead. Doubts were raised about the proof and its applicability due to trust in servers and a dubious hardness assumption.CashFusion is a privacy-enhancing technique developed by the Bitcoin Cash community. It claims that non-equal value CoinJoins can be relied on for privacy. The research highlights the large number of ways to partition inputs into sets, making it hard to track transactions. The Cash Fusion scheme allows players to bring many inputs and outputs, further extending obfuscation. However, equal-valued CoinJoins offer unlinked equal-valued outputs, making them a viable alternative if the math requires such outputs. CashFusion involves a single UTXO value, while equal-valued CoinJoin has zero linkability between inputs and outputs.In summary, CashFusion is a privacy-focused approach for Bitcoin Cash transactions that offers obfuscation through combinatorial techniques. However, there are potential attacks and limitations that need to be addressed. Knapsack is considered the best solution for unequal inputs/outputs CoinJoins, while equal-valued CoinJoins provide unlinked equal-valued outputs. Privacy concerns related to CoinJoin transactions still need to be addressed, and there are doubts about the proof and its applicability. Further exploration of design spaces and protocols is needed to improve privacy in CoinJoin transactions 2020-02-22T18:01:14+00:00 + In a recent email conversation between Ádám Ficsór and ZmnSCPxj, the topic of non-equal value CoinJoins and their privacy implications was discussed. The conversation focused on a paragraph from the CashFusion specification that claimed there is essentially no linkage with 10^92 possibilities. However, ZmnSCPxj argued that most users would not have the same output value of "around 1 BTC" in a real live mainnet scenario. He suggested that if the math requires equal-valued outputs per user, it would be more practical to use equal-valued CoinJoins. ZmnSCPxj also pointed out that change outputs in equal-valued CoinJoins have similar linkability to CashFusion outputs. The CashFusion research proposes a combinatorial approach to avoid amount linkages in non-equal value CoinJoins, but ZmnSCPxj argues that it is not as effective as equal-outputs transactions. The Knapsack paper in 2017 also had a similar idea, splitting original outputs into partitions that match selected groups of outputs. However, the simulation showed exponential growth in the number of valid transactions, making it impossible to determine the real ones. Additionally, there are concerns about the effectiveness and security of this mechanism. In contrast, Knapsack provides a general solution with good mathematical backing and has been backtested against historical data from Bitcoin's blockchain. Overall, Knapsack is currently considered the best solution for unequal inputs/outputs CoinJoins.The limitations of CoinJoin and ZeroLink protocols in terms of preventing linkage between pre- and post-mix coins were discussed in the email thread. The author proposed a new protocol that introduces chaumian reissuable/redenominatable tokens as an intermediary stage between input/output phases. This allows for unequal amounts while retaining the advantages of fixed denominations. The protocol includes several subtypes of mixing rounds and suggests subsidizing mining fees and batching to preserve exact denomination sizes. The author also mentions the possibility of keeping low hamming weight outputs virtual to make the approach size-efficient, but further exploration is needed.Another email conversation between Yuval and ZmnSCPxj focused on privacy issues related to CoinJoin transactions. They discussed broader criticisms of CoinJoin-based privacy and the assertion of 0 linkability. ZmnSCPxj expressed concern about perspectives that analyze linkability information in isolation, as the post/pre mix transaction graph presents a more complex problem. They mentioned ZeroLink protocol as a solution, but noted that it is not purely implemented in Wasabi and still has some privacy concerns. Equal-valued CoinJoins were suggested as a solution with a Chaumian bank constraining value transfers. CashFusion was also discussed, but there are doubts about its privacy guarantees and the involvement of a server.In an email exchange, Yuval Kogman made a mistake in his calculation regarding the number of inputs and indistinguishable outputs. He later corrected himself, stating that n is actually the smaller of the two numbers. While this correction did not affect his arguments, it was important to clarify the mistake.In a bitcoin-dev email thread, nopara73 responded to a document about CoinJoin-based privacy called "The Breaking of Mixing Secrets". They questioned the premises and implications of the document, highlighting the potential efficiency of computational strategies in deanonymization. Nopara73 also expressed concerns about analyzing linkability information in isolation and mentioned Cash Fusion's extension of obfuscation by allowing multiple inputs and outputs. They cautiously mentioned the potential of small popcounts/Hamming weights and the use of OP_CHECKTEMPLATEVERIFY and Taproot to mitigate overhead. Doubts were raised about the proof and its applicability due to trust in servers and a dubious hardness assumption.CashFusion is a privacy-enhancing technique developed by the Bitcoin Cash community. It claims that non-equal value CoinJoins can be relied on for privacy. The research highlights the large number of ways to partition inputs into sets, making it hard to track transactions. The Cash Fusion scheme allows players to bring many inputs and outputs, further extending obfuscation. However, equal-valued CoinJoins offer unlinked equal-valued outputs, making them a viable alternative if the math requires such outputs. CashFusion involves a single UTXO value, while equal-valued CoinJoin has zero linkability between inputs and outputs.In summary, CashFusion is a privacy-focused approach for Bitcoin Cash transactions that offers obfuscation through combinatorial techniques. However, there are potential attacks and limitations that need to be addressed. Knapsack is considered the best solution for unequal inputs/outputs CoinJoins, while equal-valued CoinJoins provide unlinked equal-valued outputs. Privacy concerns related to CoinJoin transactions still need to be addressed, and there are doubts about the proof and its applicability. Further exploration of design spaces and protocols is needed to improve privacy in CoinJoin transactions - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_Reducing-energy-consumption-and-increasing-security-at-the-same-time.xml b/static/bitcoin-dev/Dec_2019/combined_Reducing-energy-consumption-and-increasing-security-at-the-same-time.xml index b8e84bc3a5..c19c015d9d 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Reducing-energy-consumption-and-increasing-security-at-the-same-time.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Reducing-energy-consumption-and-increasing-security-at-the-same-time.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reducing energy consumption and increasing security at the same time - 2023-08-02T01:42:02.355770+00:00 + 2025-09-26T16:02:09.158074+00:00 + python-feedgen Cheng Wang 2019-12-09 09:47:49+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Reducing energy consumption and increasing security at the same time - 2023-08-02T01:42:02.355770+00:00 + 2025-09-26T16:02:09.158231+00:00 - Cheng Wang, the founder of Alephium, has introduced a novel algorithm called Proof of Linear Work (PoLW) to address the issue of high energy consumption in Proof of Work (PoW) while maintaining security. PoLW allows miners to sacrifice a portion of their coinbase rewards in exchange for weight in the block hash they produce. This approach aims to shift some of the external costs of mining, primarily energy consumption, to the internal cost of the network.In his paper, Cheng outlines two variations of the PoLW algorithm: linear PoLW and exponential PoLW. Linear PoLW is projected to reduce energy consumption by approximately 50% in equilibrium, while exponential PoLW has the potential to achieve even greater reductions. The equilibrium state ensures that the total cost of generating a new block remains equal to the maximal coinbase reward.Runchao Han had raised concerns about double spending and transaction fees in relation to PoLW. Cheng addresses these concerns by proposing a dynamic upper bound on the amount of coinbase reward miners can sacrifice, which is based on the actual mining difficulty of the recent epoch. Additionally, if the value of Bitcoin becomes comparable to gold, miners could be allowed to give up more rewards. To handle transaction fees, PoLW could eliminate the halving mechanism, as it already adjusts adaptively.Cheng emphasizes that his work is grounded in solid mathematical calculations and invites feedback and discussions. His paper can be accessed at https://github.com/alephium/research/raw/master/polw.pdf. It is worth noting that Cheng's research was inspired by a recent paper authored by Itay, Alexander, and Ittay, available at https://arxiv.org/abs/1911.04124.While Cheng acknowledges that immediate reduction of external costs in existing systems may not be feasible, the principle behind implementing PoLW is to continually increase the absolute external cost while gradually reducing its percentage in the total cost. As a result, transitioning from PoW to PoLW would lead to decreased external costs and increased internal costs, ultimately contributing to enhanced security. 2019-12-09T09:47:49+00:00 + Cheng Wang, the founder of Alephium, has introduced a novel algorithm called Proof of Linear Work (PoLW) to address the issue of high energy consumption in Proof of Work (PoW) while maintaining security. PoLW allows miners to sacrifice a portion of their coinbase rewards in exchange for weight in the block hash they produce. This approach aims to shift some of the external costs of mining, primarily energy consumption, to the internal cost of the network.In his paper, Cheng outlines two variations of the PoLW algorithm: linear PoLW and exponential PoLW. Linear PoLW is projected to reduce energy consumption by approximately 50% in equilibrium, while exponential PoLW has the potential to achieve even greater reductions. The equilibrium state ensures that the total cost of generating a new block remains equal to the maximal coinbase reward.Runchao Han had raised concerns about double spending and transaction fees in relation to PoLW. Cheng addresses these concerns by proposing a dynamic upper bound on the amount of coinbase reward miners can sacrifice, which is based on the actual mining difficulty of the recent epoch. Additionally, if the value of Bitcoin becomes comparable to gold, miners could be allowed to give up more rewards. To handle transaction fees, PoLW could eliminate the halving mechanism, as it already adjusts adaptively.Cheng emphasizes that his work is grounded in solid mathematical calculations and invites feedback and discussions. His paper can be accessed at https://github.com/alephium/research/raw/master/polw.pdf. It is worth noting that Cheng's research was inspired by a recent paper authored by Itay, Alexander, and Ittay, available at https://arxiv.org/abs/1911.04124.While Cheng acknowledges that immediate reduction of external costs in existing systems may not be feasible, the principle behind implementing PoLW is to continually increase the absolute external cost while gradually reducing its percentage in the total cost. As a result, transitioning from PoW to PoLW would lead to decreased external costs and increased internal costs, ultimately contributing to enhanced security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_Signing-CHECKSIG-position-in-Tapscript.xml b/static/bitcoin-dev/Dec_2019/combined_Signing-CHECKSIG-position-in-Tapscript.xml index 079f6b987d..4b0ca9d9d7 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Signing-CHECKSIG-position-in-Tapscript.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Signing-CHECKSIG-position-in-Tapscript.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Signing CHECKSIG position in Tapscript - 2023-08-02T01:41:18.154125+00:00 - - Anthony Towns 2019-12-06 04:51:53+00:00 - - - Russell O'Connor 2019-12-05 20:24:46+00:00 - - - Anthony Towns 2019-12-03 08:35:38+00:00 - - - Russell O'Connor 2019-12-01 16:09:54+00:00 - - - Anthony Towns 2019-11-28 08:06:59+00:00 - - - Russell O'Connor 2019-11-27 21:29:32+00:00 - + 2025-09-26T16:02:07.042937+00:00 + python-feedgen + + + [bitcoin-dev] Signing CHECKSIG position in Tapscript Russell O'Connor + 2019-11-27T21:29:00.000Z + + + Anthony Towns + 2019-11-28T08:06:00.000Z + + + Russell O'Connor + 2019-12-01T16:09:00.000Z + + + Anthony Towns + 2019-12-03T08:35:00.000Z + + + Russell O'Connor + 2019-12-05T20:24:00.000Z + + + Anthony Towns + 2019-12-06T04:51:00.000Z + + - python-feedgen + 2 Combined summary - Signing CHECKSIG position in Tapscript - 2023-08-02T01:41:18.154125+00:00 + 2025-09-26T16:02:07.043787+00:00 - In an email thread, Russell O'Connor and gmaxwell discuss potential amendments to the CODESEPARATOR's behavior in Bitcoin's scripting language. The proposed amendment aims to update an accumulator with a running hash value to ensure that all executed CODESEPARATOR positions are covered by the signature. Gmaxwell suggests using the name "OP_BREADCRUMB" for this new functionality. However, aj cautions against proposing this idea too soon, citing concerns about practical need and whether opcode or sighash flag functionality is more appropriate. Aj also suggests a policy that would allow signatures to cover some function of witness value and proposes a replacement for CODESEPARATOR's behavior that pushes a stack item into the accumulator rather than pushing the CODESEPARATOR position. Aj also notes that the annex may not be general enough to accommodate these changes and proposes committing to a hash of all witness data as a possible solution. They propose an "OP_DATACOMMIT" opcode that pops an element from the stack, does hash_"DataCommit", and later signatures commit to that value. Aj suggests implementing CODESEP at position "x" in the script as equivalent to "DATACOMMIT," but acknowledges that this approach warrants something better. Overall, aj suggests that this proposal needs further exploration before it can be coded into consensus.After discussing and considering the concern of other users masquerading pubkeys in complex scripts, it is determined that this is a non-issue because any policy expressed in a script is logically equivalent to a set of conditions and signatures on pubkeys that can be expressed in disjunctive normal form. However, there is still an issue with pubkey reuse within a single script, as it can allow someone to take a signature intended for one condition and transplant it to redeem under another. To avoid this, it is important for Alice to ensure she doesn't reuse pubkeys that she considers under her control for different conditions when she wants her signature to distinguish between them. While avoiding pubkey reuse within a script should be easier than avoiding it for different UTXOs, converting a policy to disjunctive normal form can involve an exponential blowup. Additionally, there may be cases where a policy requires an exponential number of pubkeys, which isn't tractable to do in Script. Taproot's MAST (Merklized Alternative Script Tree) can provide a solution for certain cases.The email conversation revolves around the vulnerability of signature copying attacks, particularly pertaining to the use of CODESEPARATOR in the Taproot script version. The issue is that signing the CODESEPARATOR position without signing the script code is considered nonsensical as it is signing a piece of data without an interpretation of its meaning. However, the current implementation includes an index to the digest being signed, so signatures at different indexes are distinct. Participants discuss various techniques such as miniscript and fixed templates to allow limited safe changes to policy and prevent signature reuse in different scripts. The proposed solution, ANYPREVOUTANYSCRIPT, would not sign the script code but would continue signing the CODESEPARATOR position, allowing for restricted signature reuse. This means users can prevent their funds from going to certain addresses without compromising security.While the concept of CODESEPARATOR in taproot is discussed as a possible solution, some argue that it would not be widely used or sufficient. There are only two known use cases for CODESEPARATOR, one being the reveal-a-secret-key-by-forced-nonce-reuse script, which requires pubkey recovery and does not work with bip-schnorr, and the other is ntumblebit's escrow script. It is ultimately agreed that analyzing scripts before collaborating is necessary to prevent vulnerability to signature copying attacks. Although the proposal to eliminate CODESEPARATOR opcode in the Taproot script version is seen as effective enough to save most people most of the time, it may not save everyone all the time. Some participants suggest that CODESEP is a marginally more efficient/general fix than the proposal made.In an email exchange, Anthony Towns shares a link to a discussion on Taproot BIP review. The conversation revolves around signing the position of the enclosing OP_IF/OP_NOTIF/OP_ELSE of the OP_IF/OP_NOTIF/OP_ELSE block that the checksig is within, or signing the byte offset instead of the opcode number offset. It is suggested that signing the enclosing OP_IF... would allow sharing of the hashed signed data in a normal multisig sequence of operations. A sighash flag could control whether or not the signature covers the CHECKSIG position or not, with SIGHASH_ALL including the CHECKSIG position.Russell O'Connor proposed an amendment to the current tapscript proposal, which requires a signature on the last executed CODESEPRATOR position. He suggested that instead of signing the last executed CODESEPRATOR position, we should sign the position of the CHECKSIG (or other signing opcode) being executed. There is a discussion about this topic at http://www.erisian.com 2019-12-06T04:51:53+00:00 + In an email thread, Russell O'Connor and gmaxwell discuss potential amendments to the CODESEPARATOR's behavior in Bitcoin's scripting language. The proposed amendment aims to update an accumulator with a running hash value to ensure that all executed CODESEPARATOR positions are covered by the signature. Gmaxwell suggests using the name "OP_BREADCRUMB" for this new functionality. However, aj cautions against proposing this idea too soon, citing concerns about practical need and whether opcode or sighash flag functionality is more appropriate. Aj also suggests a policy that would allow signatures to cover some function of witness value and proposes a replacement for CODESEPARATOR's behavior that pushes a stack item into the accumulator rather than pushing the CODESEPARATOR position. Aj also notes that the annex may not be general enough to accommodate these changes and proposes committing to a hash of all witness data as a possible solution. They propose an "OP_DATACOMMIT" opcode that pops an element from the stack, does hash_"DataCommit", and later signatures commit to that value. Aj suggests implementing CODESEP at position "x" in the script as equivalent to "DATACOMMIT," but acknowledges that this approach warrants something better. Overall, aj suggests that this proposal needs further exploration before it can be coded into consensus.After discussing and considering the concern of other users masquerading pubkeys in complex scripts, it is determined that this is a non-issue because any policy expressed in a script is logically equivalent to a set of conditions and signatures on pubkeys that can be expressed in disjunctive normal form. However, there is still an issue with pubkey reuse within a single script, as it can allow someone to take a signature intended for one condition and transplant it to redeem under another. To avoid this, it is important for Alice to ensure she doesn't reuse pubkeys that she considers under her control for different conditions when she wants her signature to distinguish between them. While avoiding pubkey reuse within a script should be easier than avoiding it for different UTXOs, converting a policy to disjunctive normal form can involve an exponential blowup. Additionally, there may be cases where a policy requires an exponential number of pubkeys, which isn't tractable to do in Script. Taproot's MAST (Merklized Alternative Script Tree) can provide a solution for certain cases.The email conversation revolves around the vulnerability of signature copying attacks, particularly pertaining to the use of CODESEPARATOR in the Taproot script version. The issue is that signing the CODESEPARATOR position without signing the script code is considered nonsensical as it is signing a piece of data without an interpretation of its meaning. However, the current implementation includes an index to the digest being signed, so signatures at different indexes are distinct. Participants discuss various techniques such as miniscript and fixed templates to allow limited safe changes to policy and prevent signature reuse in different scripts. The proposed solution, ANYPREVOUTANYSCRIPT, would not sign the script code but would continue signing the CODESEPARATOR position, allowing for restricted signature reuse. This means users can prevent their funds from going to certain addresses without compromising security.While the concept of CODESEPARATOR in taproot is discussed as a possible solution, some argue that it would not be widely used or sufficient. There are only two known use cases for CODESEPARATOR, one being the reveal-a-secret-key-by-forced-nonce-reuse script, which requires pubkey recovery and does not work with bip-schnorr, and the other is ntumblebit's escrow script. It is ultimately agreed that analyzing scripts before collaborating is necessary to prevent vulnerability to signature copying attacks. Although the proposal to eliminate CODESEPARATOR opcode in the Taproot script version is seen as effective enough to save most people most of the time, it may not save everyone all the time. Some participants suggest that CODESEP is a marginally more efficient/general fix than the proposal made.In an email exchange, Anthony Towns shares a link to a discussion on Taproot BIP review. The conversation revolves around signing the position of the enclosing OP_IF/OP_NOTIF/OP_ELSE of the OP_IF/OP_NOTIF/OP_ELSE block that the checksig is within, or signing the byte offset instead of the opcode number offset. It is suggested that signing the enclosing OP_IF... would allow sharing of the hashed signed data in a normal multisig sequence of operations. A sighash flag could control whether or not the signature covers the CHECKSIG position or not, with SIGHASH_ALL including the CHECKSIG position.Russell O'Connor proposed an amendment to the current tapscript proposal, which requires a signature on the last executed CODESEPRATOR position. He suggested that instead of signing the last executed CODESEPRATOR position, we should sign the position of the CHECKSIG (or other signing opcode) being executed. There is a discussion about this topic at http://www.erisian.com - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2019/combined_easypaysy-A-layer-two-protocol-to-send-payments-without-addresses.xml b/static/bitcoin-dev/Dec_2019/combined_easypaysy-A-layer-two-protocol-to-send-payments-without-addresses.xml index 74d5ce9f52..a44f8cebf2 100644 --- a/static/bitcoin-dev/Dec_2019/combined_easypaysy-A-layer-two-protocol-to-send-payments-without-addresses.xml +++ b/static/bitcoin-dev/Dec_2019/combined_easypaysy-A-layer-two-protocol-to-send-payments-without-addresses.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - easypaysy - A layer-two protocol to send payments without addresses - 2023-08-02T01:41:49.353446+00:00 - - ZmnSCPxj 2019-12-07 04:09:52+00:00 - - - Jose Femenías Cañuelo 2019-12-06 18:47:38+00:00 - - - ZmnSCPxj 2019-12-06 17:16:44+00:00 - - - Jose Femenías Cañuelo 2019-12-06 07:56:52+00:00 - - - ZmnSCPxj 2019-12-06 02:53:34+00:00 - - - Jose Femenías Cañuelo 2019-12-05 20:00:03+00:00 - - - Jose Femenías Cañuelo 2019-12-02 21:25:01+00:00 - - - ZmnSCPxj 2019-12-02 21:10:19+00:00 - - - Tim Blokdijk 2019-12-02 17:27:21+00:00 - - - Jose Femenias 2019-12-02 14:00:57+00:00 - + 2025-09-26T16:01:52.359862+00:00 + python-feedgen + + + Jose Femenias + 2019-12-02T14:00:00.000Z + + + Tim Blokdijk + 2019-12-02T17:27:00.000Z + + + ZmnSCPxj + 2019-12-02T21:10:00.000Z + + + Jose Femenías Cañuelo + 2019-12-02T21:25:00.000Z + + + [bitcoin-dev] easypaysy - A layer-two protocol to send payments without addresses Jose Femenías Cañuelo + 2019-12-05T20:00:00.000Z + + + ZmnSCPxj + 2019-12-06T02:53:00.000Z + + + Jose Femenías Cañuelo + 2019-12-06T07:56:00.000Z + + + ZmnSCPxj + 2019-12-06T17:16:00.000Z + + + Jose Femenías Cañuelo + 2019-12-06T18:47:00.000Z + + + ZmnSCPxj + 2019-12-07T04:09:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - easypaysy - A layer-two protocol to send payments without addresses - 2023-08-02T01:41:49.353446+00:00 + 2025-09-26T16:01:52.361133+00:00 - I apologize for the confusion. Based on the provided context, the conversation between Jose and ZmnSCPXj revolves around the implementation of master accounts in the easypaysy protocol. The discussion covers various aspects such as service providers retaining control over user accounts, using MAST smart contracts to resolve issues, the possibility of sub-accounts detaching from the master account, controlling transactions on top of the funding transaction output, and the need for mirror servers to mitigate the risk of losing account information if the service provider disappears.The email exchange also touches upon the easypaysy identifier, which refers to the funding transaction output that roots further control transactions. The conversation highlights the importance of making the protocol easy to implement for SPV wallets and addresses concerns about the output index in the account ID. Furthermore, the white paper is mentioned as a draft of ideas that can drive a working set of specifications, and there is a discussion about the implications for the Lightning Network and the use of Tor hidden services.In addition to the conversation between Jose and ZmnSCPXj, there are other discussions related to Easypaysy. These discussions cover topics such as account registration, cost-effectiveness compared to Lightning, the number of transactions required to construct an account, and the benefits of encoding output index and using Tor hidden services as contact-information protocols. The Easypaysy white paper is mentioned as a resource for more detailed information about the protocol.Overall, the conversations provide insights into the features, challenges, and potential improvements of the Easypaysy protocol, which aims to enable non-custodial accounts on the Bitcoin blockchain. 2019-12-07T04:09:52+00:00 + I apologize for the confusion. Based on the provided context, the conversation between Jose and ZmnSCPXj revolves around the implementation of master accounts in the easypaysy protocol. The discussion covers various aspects such as service providers retaining control over user accounts, using MAST smart contracts to resolve issues, the possibility of sub-accounts detaching from the master account, controlling transactions on top of the funding transaction output, and the need for mirror servers to mitigate the risk of losing account information if the service provider disappears.The email exchange also touches upon the easypaysy identifier, which refers to the funding transaction output that roots further control transactions. The conversation highlights the importance of making the protocol easy to implement for SPV wallets and addresses concerns about the output index in the account ID. Furthermore, the white paper is mentioned as a draft of ideas that can drive a working set of specifications, and there is a discussion about the implications for the Lightning Network and the use of Tor hidden services.In addition to the conversation between Jose and ZmnSCPXj, there are other discussions related to Easypaysy. These discussions cover topics such as account registration, cost-effectiveness compared to Lightning, the number of transactions required to construct an account, and the benefits of encoding output index and using Tor hidden services as contact-information protocols. The Easypaysy white paper is mentioned as a resource for more detailed information about the protocol.Overall, the conversations provide insights into the features, challenges, and potential improvements of the Easypaysy protocol, which aims to enable non-custodial accounts on the Bitcoin blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2020/combined_BIP-0322-generic-signmessage-improvements.xml b/static/bitcoin-dev/Dec_2020/combined_BIP-0322-generic-signmessage-improvements.xml index f87fe6dc7d..602f530b31 100644 --- a/static/bitcoin-dev/Dec_2020/combined_BIP-0322-generic-signmessage-improvements.xml +++ b/static/bitcoin-dev/Dec_2020/combined_BIP-0322-generic-signmessage-improvements.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - BIP-0322 (generic signmessage) improvements - 2023-08-02T02:58:52.043931+00:00 - - Andrew Poelstra 2020-12-23 15:55:42+00:00 - - - Andrew Poelstra 2020-12-22 01:11:42+00:00 - - - Pieter Wuille 2020-12-22 00:22:37+00:00 - - - Pieter Wuille 2020-12-21 22:57:15+00:00 - - - Karl-Johan Alm 2020-12-21 05:37:38+00:00 - - - Andrew Poelstra 2020-12-18 15:27:20+00:00 - + 2025-09-26T16:04:55.927767+00:00 + python-feedgen + + + [bitcoin-dev] BIP-0322 (generic signmessage) improvements Andrew Poelstra + 2020-12-18T15:27:00.000Z + + + Karl-Johan Alm + 2020-12-21T05:37:00.000Z + + + Pieter Wuille + 2020-12-21T22:57:00.000Z + + + Pieter Wuille + 2020-12-22T00:22:00.000Z + + + Andrew Poelstra + 2020-12-22T01:11:00.000Z + + + Andrew Poelstra + 2020-12-23T15:55:00.000Z + + - python-feedgen + 2 Combined summary - BIP-0322 (generic signmessage) improvements - 2023-08-02T02:58:52.043931+00:00 + 2025-09-26T16:04:55.928640+00:00 - Pieter Wuille and Andrew Poelstra had a discussion on the bitcoin-dev mailing list regarding the proposed text for consensus-only validation extension. Pieter Wuille was uncertain about whether this extension would replace the inconclusive-due-to-consensus-and-standardness-differ state. Andrew suggested a way to specify it, where every signature has a well-defined result of valid, invalid, or inconclusive. If validators do not understand anything, they may choose to report it as inconclusive.Andrew updated his PR at Github with four differences. These include compacting all the validation states into three categories, removing extensions sections, removing "to_sign" transaction from wire serialization, and not complicating the protocol for obscure things like bare public keys or multisigs.On December 22, 2020, Pieter Wuille made a proposal on the bitcoin-dev mailing list regarding the "consensus-only validation" extension. Andrew Poelstra responded with his thoughts on standardness vs consensus rules and his desire to enforce standardness rules for anti-malleability reasons. However, he acknowledged the difficulty of enforcing these rules as an implementer because libbitcoinconsensus does not expose them. He also agreed with Wuille's idea of allowing validators to signal when a signature appears to use future consensus rules and using the "inconclusive" state as an elegant way to achieve this.Both Pieter and Andrew agreed that confirming validators should never disagree on valid vs invalid. Poelstra added a commit to his PR at https://github.com/bitcoin/bips/pull/1048 which reflects their thoughts.Pieter Wuille responded to Karl-Johan Alm's request for feedback on changes to the BIP (Bitcoin Improvement Proposal) by suggesting a modification to the proposal. He agreed with the idea of allowing incomplete validators to return "inconclusive" results, making it more accessible to various software. However, he pointed out that this suggestion would break the original use of "inconclusive" as a way to detect future features used in the signature.Pieter suggested that whenever validation fails due to any of the standardness features listed in the BIP, validators should report "inconclusive" instead of "invalid". This ensures that every signature has a well-defined result of valid, invalid, or inconclusive. Validators may choose to report "inconclusive" for anything they don't understand. This modification ensures that no two validators will ever claim valid and invalid for the same signature, only valid+inconclusive or invalid+inconclusive.Karl-Johan Alm expressed his support for recent changes to the BIP in an email to bitcoin-dev. He agreed with the idea of allowing incomplete validators to return inconclusive results, considering it a clear improvement. However, he noted that this suggestion breaks the original use of inconclusive as a way to detect future features used in the signature. He suggested a fix by requiring reporting inconclusive instead of invalid whenever validation fails due to any standardness features unless something is actually invalid. Pieter also supported Karl-Johan's suggestion.A developer has rewritten the text of BIP-0322, a standard for interoperable signed messages based on the Bitcoin Script format, to simplify and clarify the protocol. The changes include merging "consensus" and "upgradeable" rules into one set of rules consisting of consensus checks plus additional restrictions. The BIP specifies three formats for signing messages: legacy, simple, and full. Validators must output one of four states: valid, valid at time t and age s, consensus-valid, or inconclusive. The BIP outlines additional states that can be output instead of "valid" or "invalid" to ease implementation.The author of BIP-0322 has rewritten the text to make it easier to follow and address objections regarding signmessage functionality. The consensus and upgradeable rules have been merged, and a new "Extensions" section allows validators to output the state "consensus-valid" if they don't want to check additional restrictions. The author welcomes comments on Github.In addition to BIP-0322, the document outlines a specification for a new message signing scheme called "signet." These signatures serve as proof of funds, indicating that a set of coins is under the control of a particular address. Validators require access to the current UTXO set and scriptPubKeys to confirm the claimed inputs exist on the blockchain. The specification includes detailed restrictions and requirements for all signature types except legacy. The validation process involves confirming message_hash, message_challenge, and more. If all conditions are met, the signature is considered valid; otherwise, it's invalid. The document also includes information on signing, extensions, compatibility, and references. 2020-12-23T15:55:42+00:00 + Pieter Wuille and Andrew Poelstra had a discussion on the bitcoin-dev mailing list regarding the proposed text for consensus-only validation extension. Pieter Wuille was uncertain about whether this extension would replace the inconclusive-due-to-consensus-and-standardness-differ state. Andrew suggested a way to specify it, where every signature has a well-defined result of valid, invalid, or inconclusive. If validators do not understand anything, they may choose to report it as inconclusive.Andrew updated his PR at Github with four differences. These include compacting all the validation states into three categories, removing extensions sections, removing "to_sign" transaction from wire serialization, and not complicating the protocol for obscure things like bare public keys or multisigs.On December 22, 2020, Pieter Wuille made a proposal on the bitcoin-dev mailing list regarding the "consensus-only validation" extension. Andrew Poelstra responded with his thoughts on standardness vs consensus rules and his desire to enforce standardness rules for anti-malleability reasons. However, he acknowledged the difficulty of enforcing these rules as an implementer because libbitcoinconsensus does not expose them. He also agreed with Wuille's idea of allowing validators to signal when a signature appears to use future consensus rules and using the "inconclusive" state as an elegant way to achieve this.Both Pieter and Andrew agreed that confirming validators should never disagree on valid vs invalid. Poelstra added a commit to his PR at https://github.com/bitcoin/bips/pull/1048 which reflects their thoughts.Pieter Wuille responded to Karl-Johan Alm's request for feedback on changes to the BIP (Bitcoin Improvement Proposal) by suggesting a modification to the proposal. He agreed with the idea of allowing incomplete validators to return "inconclusive" results, making it more accessible to various software. However, he pointed out that this suggestion would break the original use of "inconclusive" as a way to detect future features used in the signature.Pieter suggested that whenever validation fails due to any of the standardness features listed in the BIP, validators should report "inconclusive" instead of "invalid". This ensures that every signature has a well-defined result of valid, invalid, or inconclusive. Validators may choose to report "inconclusive" for anything they don't understand. This modification ensures that no two validators will ever claim valid and invalid for the same signature, only valid+inconclusive or invalid+inconclusive.Karl-Johan Alm expressed his support for recent changes to the BIP in an email to bitcoin-dev. He agreed with the idea of allowing incomplete validators to return inconclusive results, considering it a clear improvement. However, he noted that this suggestion breaks the original use of inconclusive as a way to detect future features used in the signature. He suggested a fix by requiring reporting inconclusive instead of invalid whenever validation fails due to any standardness features unless something is actually invalid. Pieter also supported Karl-Johan's suggestion.A developer has rewritten the text of BIP-0322, a standard for interoperable signed messages based on the Bitcoin Script format, to simplify and clarify the protocol. The changes include merging "consensus" and "upgradeable" rules into one set of rules consisting of consensus checks plus additional restrictions. The BIP specifies three formats for signing messages: legacy, simple, and full. Validators must output one of four states: valid, valid at time t and age s, consensus-valid, or inconclusive. The BIP outlines additional states that can be output instead of "valid" or "invalid" to ease implementation.The author of BIP-0322 has rewritten the text to make it easier to follow and address objections regarding signmessage functionality. The consensus and upgradeable rules have been merged, and a new "Extensions" section allows validators to output the state "consensus-valid" if they don't want to check additional restrictions. The author welcomes comments on Github.In addition to BIP-0322, the document outlines a specification for a new message signing scheme called "signet." These signatures serve as proof of funds, indicating that a set of coins is under the control of a particular address. Validators require access to the current UTXO set and scriptPubKeys to confirm the claimed inputs exist on the blockchain. The specification includes detailed restrictions and requirements for all signature types except legacy. The validation process involves confirming message_hash, message_challenge, and more. If all conditions are met, the signature is considered valid; otherwise, it's invalid. The document also includes information on signing, extensions, compatibility, and references. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2020/combined_BIP-Automated-and-Secure-Communication.xml b/static/bitcoin-dev/Dec_2020/combined_BIP-Automated-and-Secure-Communication.xml index 2d214b2aca..97feff9f13 100644 --- a/static/bitcoin-dev/Dec_2020/combined_BIP-Automated-and-Secure-Communication.xml +++ b/static/bitcoin-dev/Dec_2020/combined_BIP-Automated-and-Secure-Communication.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP - Automated and Secure Communication - 2023-08-02T02:52:51.056559+00:00 - - Luke Dashjr 2020-12-06 19:36:48+00:00 - - - yanmaani at cock.li 2020-12-06 19:14:13+00:00 - - - Prayank 2020-12-06 18:20:02+00:00 - + 2025-09-26T16:05:02.208636+00:00 + python-feedgen + + + [bitcoin-dev] BIP - Automated and Secure Communication Prayank + 2020-12-06T18:20:00.000Z + + + yanmaani + 2020-12-06T19:14:00.000Z + + + Luke Dashjr + 2020-12-06T19:36:00.000Z + + - python-feedgen + 2 Combined summary - BIP - Automated and Secure Communication - 2023-08-02T02:52:51.056559+00:00 + 2025-09-26T16:05:02.209238+00:00 - The bitcoin-dev mailing list is currently discussing whether a Bitcoin Improvement Proposal (BIP) should be proposed for the automated and secure communication used in Soroban, a project by Samourai wallet. While some members argue that this is not directly related to improving the Bitcoin protocol, others, including Ben from Square Crypto, believe that a BIP would be appropriate. Prayank, the original poster, suggests that such a BIP could benefit other Bitcoin projects like joinmarket, coinswap, snickr, etc., as anything facilitating coordination between different programs is considered BIP material. Prayank provides links to the client library in Java and the server component in Go for those interested in the technical details of Soroban.Although Samourai, a Bitcoin wallet provider, has declined to propose a BIP for the Soroban communication system, citing its lack of impact on the Bitcoin protocol and the mailing list's unsuitability for writing a specification, Prayank seeks opinions on potential interest in a BIP. Despite past controversies surrounding Samourai, Prayank emphasizes the importance of putting aside differences and focusing on what benefits Bitcoin. Furthermore, a medium article linked in the post highlights the potential benefits of Soroban for other projects such as joinmarket, coinswap, and snickr.In addition, Prayank has shared the source code for the Soroban client library in Java and the Go-based server component, which can be accessed through the provided links. Prayank requests assistance from anyone willing to help create a BIP for implementing Soroban in other Bitcoin projects.Prayank has also taken the discussion to Reddit, seeking opinions on whether there is enough interest in proposing a BIP related to Soroban's automated and secure communication. Despite previous controversies involving Samourai, Prayank emphasizes the importance of prioritizing actions that benefit Bitcoin. The potential benefits of a BIP for other Bitcoin projects, as mentioned in the medium article linked by Prayank, are also highlighted. Additionally, the Samourai team has tweeted their lack of interest in proposing a Soroban-related BIP, while Ben from Square Crypto has expressed support for such a proposal. Prayank provides links to the source code for the Java client library and Go-based server component and invites assistance in creating a BIP for this implementation. 2020-12-06T19:36:48+00:00 + The bitcoin-dev mailing list is currently discussing whether a Bitcoin Improvement Proposal (BIP) should be proposed for the automated and secure communication used in Soroban, a project by Samourai wallet. While some members argue that this is not directly related to improving the Bitcoin protocol, others, including Ben from Square Crypto, believe that a BIP would be appropriate. Prayank, the original poster, suggests that such a BIP could benefit other Bitcoin projects like joinmarket, coinswap, snickr, etc., as anything facilitating coordination between different programs is considered BIP material. Prayank provides links to the client library in Java and the server component in Go for those interested in the technical details of Soroban.Although Samourai, a Bitcoin wallet provider, has declined to propose a BIP for the Soroban communication system, citing its lack of impact on the Bitcoin protocol and the mailing list's unsuitability for writing a specification, Prayank seeks opinions on potential interest in a BIP. Despite past controversies surrounding Samourai, Prayank emphasizes the importance of putting aside differences and focusing on what benefits Bitcoin. Furthermore, a medium article linked in the post highlights the potential benefits of Soroban for other projects such as joinmarket, coinswap, and snickr.In addition, Prayank has shared the source code for the Soroban client library in Java and the Go-based server component, which can be accessed through the provided links. Prayank requests assistance from anyone willing to help create a BIP for implementing Soroban in other Bitcoin projects.Prayank has also taken the discussion to Reddit, seeking opinions on whether there is enough interest in proposing a BIP related to Soroban's automated and secure communication. Despite previous controversies involving Samourai, Prayank emphasizes the importance of prioritizing actions that benefit Bitcoin. The potential benefits of a BIP for other Bitcoin projects, as mentioned in the medium article linked by Prayank, are also highlighted. Additionally, the Samourai team has tweeted their lack of interest in proposing a Soroban-related BIP, while Ben from Square Crypto has expressed support for such a proposal. Prayank provides links to the source code for the Java client library and Go-based server component and invites assistance in creating a BIP for this implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2020/combined_BIP-Proposal-Wallet-Interface.xml b/static/bitcoin-dev/Dec_2020/combined_BIP-Proposal-Wallet-Interface.xml index d82a04600b..c2efa8a0d8 100644 --- a/static/bitcoin-dev/Dec_2020/combined_BIP-Proposal-Wallet-Interface.xml +++ b/static/bitcoin-dev/Dec_2020/combined_BIP-Proposal-Wallet-Interface.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - BIP Proposal: Wallet Interface - 2023-08-02T02:59:00.364012+00:00 - - Shane Jonas 2020-12-25 18:11:23+00:00 - - - Aymeric Vitte 2020-12-25 11:49:11+00:00 - - - Erik Aronesty 2020-12-23 21:13:29+00:00 - - - Omar Shibli 2020-12-23 11:44:52+00:00 - - - monokh 2020-12-23 07:29:23+00:00 - - - Luke Dashjr 2020-12-23 02:15:45+00:00 - - - monokh 2020-12-22 14:43:11+00:00 - + 2025-09-26T16:04:58.021853+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Wallet Interface monokh + 2020-12-22T14:43:00.000Z + + + Luke Dashjr + 2020-12-23T02:15:00.000Z + + + monokh + 2020-12-23T07:29:00.000Z + + + Omar Shibli + 2020-12-23T11:44:00.000Z + + + Erik Aronesty + 2020-12-23T21:13:00.000Z + + + Aymeric Vitte + 2020-12-25T11:49:00.000Z + + + Shane Jonas + 2020-12-25T18:11:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Wallet Interface - 2023-08-02T02:59:00.364012+00:00 + 2025-09-26T16:04:58.022835+00:00 - A proposed Bitcoin Improvement Proposal (BIP) outlines a standardized wallet API that aims to define a simple interface for Bitcoin wallets and applications. The goal is to cover the majority of use cases and facilitate the development of more robust Bitcoin applications. The proposed API would expose a wallet's address derivation and signing functions in a standardized way, allowing for greater interoperability between wallets and applications. Wallet software should prompt users for confirmation when performing sensitive operations like signing. The proposal includes mandatory methods such as `wallet_getAddresses`, `wallet_signMessage`, and `wallet_signPSBT`. The standardization of the wallet API would provide clear expectations for wallet interface and behavior, increase user choice, and enhance confidence in application development. External access to wallet functionality should be carefully managed to protect user security and privacy. Examples of Ethereum APIs and wallet interfaces are provided, along with a live demo and interactive documentation. The hope is that this standard API document will simplify the creation of development tools and documentation. 2020-12-25T18:11:23+00:00 + A proposed Bitcoin Improvement Proposal (BIP) outlines a standardized wallet API that aims to define a simple interface for Bitcoin wallets and applications. The goal is to cover the majority of use cases and facilitate the development of more robust Bitcoin applications. The proposed API would expose a wallet's address derivation and signing functions in a standardized way, allowing for greater interoperability between wallets and applications. Wallet software should prompt users for confirmation when performing sensitive operations like signing. The proposal includes mandatory methods such as `wallet_getAddresses`, `wallet_signMessage`, and `wallet_signPSBT`. The standardization of the wallet API would provide clear expectations for wallet interface and behavior, increase user choice, and enhance confidence in application development. External access to wallet functionality should be carefully managed to protect user security and privacy. Examples of Ethereum APIs and wallet interfaces are provided, along with a live demo and interactive documentation. The hope is that this standard API document will simplify the creation of development tools and documentation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2020/combined_New-PSBT-version-proposal.xml b/static/bitcoin-dev/Dec_2020/combined_New-PSBT-version-proposal.xml index cf4fd98ec8..35514db0f0 100644 --- a/static/bitcoin-dev/Dec_2020/combined_New-PSBT-version-proposal.xml +++ b/static/bitcoin-dev/Dec_2020/combined_New-PSBT-version-proposal.xml @@ -1,59 +1,47 @@ - + 2 Combined summary - New PSBT version proposal - 2023-08-02T02:54:05.328979+00:00 - - Lloyd Fournier 2021-04-05 00:35:14+00:00 - - - Lloyd Fournier 2021-03-10 00:20:58+00:00 - - - Andrew Chow 2021-01-21 19:50:45+00:00 - - - Andrew Chow 2021-01-15 17:28:09+00:00 - - - Andrew Chow 2021-01-14 17:07:44+00:00 - - - Rusty Russell 2021-01-08 00:40:06+00:00 - - - Andrew Chow 2021-01-06 23:48:31+00:00 - - - Rusty Russell 2021-01-06 23:26:25+00:00 - - - Jeremy 2021-01-02 06:34:00+00:00 - - - Andrew Chow 2020-12-23 21:32:33+00:00 - - - Andrew Chow 2020-12-23 21:30:04+00:00 - - - Andrew Poelstra 2020-12-23 15:22:01+00:00 - - - fiatjaf 2020-12-23 03:30:20+00:00 - - - Andrew Chow 2020-12-22 20:12:22+00:00 - - - Andrew Poelstra 2020-12-16 17:44:11+00:00 - - - Sanket Kanjalkar 2020-12-10 11:28:23+00:00 - - - Andrew Chow 2020-12-09 22:25:37+00:00 - + 2025-09-26T16:05:04.326284+00:00 + python-feedgen + + + Jeremy + 2021-01-02T06:34:00.000Z + + + Rusty Russell + 2021-01-06T23:26:00.000Z + + + Andrew Chow + 2021-01-06T23:48:00.000Z + + + Rusty Russell + 2021-01-08T00:40:00.000Z + + + Andrew Chow + 2021-01-14T17:07:00.000Z + + + Andrew Chow + 2021-01-15T17:28:00.000Z + + + Andrew Chow + 2021-01-21T19:50:00.000Z + + + Lloyd Fournier + 2021-03-10T00:20:00.000Z + + + Lloyd Fournier + 2021-04-05T00:35:00.000Z + + @@ -71,13 +59,13 @@ - python-feedgen + 2 Combined summary - New PSBT version proposal - 2023-08-02T02:54:05.328979+00:00 + 2025-09-26T16:05:04.327478+00:00 - A proposal has been made to introduce a new version of Partially Signed Bitcoin Transactions (PSBTs) called PSBT v1. This new version addresses deficiencies in the current PSBT v0 and allows for inputs and outputs to be added to the transaction after its creation. The primary change is that all input and output data will be contained in their respective maps, eliminating the need to parse an unsigned transaction. Several new fields will be added to support this change, including PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, and PSBT_GLOBAL_UNDER_CONSTRUCTION.Andrew Chow has also proposed another version called PSBTv2, which is a backward-incompatible update to the PSBT protocol. It introduces fields like Transaction Version, Fallback Locktime, Input Count, Output Count, and Transaction Modifiable Flags. Additionally, the process of determining the nLockTime field of a transaction is explained in detail.Rusty Russell and Andrew Chow discuss the addition of a new global field called PSBT_GLOBAL_UNDER_CONSTRUCTION in an email exchange. This field is used to signal whether inputs and outputs can be added to the PSBT. Rusty suggests flagging this by omitting redundant fields, but Andrew explains that those fields are necessary to determine the number of input and output maps. They also discuss the possibility of signed inputs being added to transactions and the complexity of allowing modification of inputs and outputs after the Creator role is done.Overall, these proposed changes aim to improve the usability and functionality of the PSBT format, allowing for easier construction of transactions and the addition of inputs and outputs as needed.Andrew Chow has proposed a new version of Partially Signed Bitcoin Transactions (PSBT), called PSBT v1, to address the deficiencies in the current PSBT v0. The primary change in the new version is to have all input and output data for each contained within their respective maps, disallowing PSBT_GLOBAL_UNSIGNED_TX. Several new fields are added for Global, Input, and Output, including PSBT_GLOBAL_TX_VERSION, PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, PSBT_GLOBAL_OUTPUT_COUNT, PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE, PSBT_IN_REQUIRED_LOCKTIME, PSBT_OUT_VALUE, and PSBT_OUT_OUTPUT_SCRIPT.These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, care must be taken to ensure that adding additional inputs and outputs will not invalidate existing signatures. Finalizers must choose the maximum of all the *_LOCKTIME fields to choose the locktime for the transaction.PSBT v1 also introduces two lock time fields - one for a time-based lock time and the other for a height-based lock time. This is necessary because all inputs must use the same type of lock time (height or time). Additionally, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, is added to signal whether inputs and outputs can be added to the PSBT. Rules must be followed to ensure that adding new inputs and outputs does not invalidate existing signatures.To uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. Combiners can create an unsigned transaction given the transaction version, input prevouts, outputs, and computed locktime, which can then be used as a way to identify PSBTs.As the changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1 needs a version number bump to enforce backward incompatibility. However, once the inputs and outputs are decided, a PSBT can be downgraded back to v0 by creating an unsigned transaction from the fields mentioned above and dropping these new fields.Andrew Chow has proposed these changes in BIP 174 and is willing to write a pull request to modify it if the changes are deemed reasonable.A new version of Partially Signed Bitcoin Transaction (PSBT) has been proposed to address the deficiencies in the current PSBT v0. The main change in this proposal is to store all input and output data for each in their respective maps, eliminating the need to parse an unsigned transaction and perform a lookup for data. This change would disallow the use of the PSBT_GLOBAL_UNSIGNED_TX field in the new version.To implement these changes, several fields are suggested to be added to both the Global and Input/Output sections of PSBT. One notable addition is the PSBT_GLOBAL_PREFERRED_LOCKTIME, which specifies the locktime to use if no inputs require a specific locktime. Another important field is the PSBT_IN_REQUIRED_LOCKTIME, which is necessary for inputs involving OP_CHECKLOCKTIMEVERIFY. This field allows finalizers to choose a locktime that meets the minimum requirement without needing to understand the scripts involved.It is worth mentioning that a Bitcoin transaction only has a single locktime, while a PSBT may have multiple locktimes. Therefore, finalizers must select 2021-04-05T00:35:14+00:00 + A proposal has been made to introduce a new version of Partially Signed Bitcoin Transactions (PSBTs) called PSBT v1. This new version addresses deficiencies in the current PSBT v0 and allows for inputs and outputs to be added to the transaction after its creation. The primary change is that all input and output data will be contained in their respective maps, eliminating the need to parse an unsigned transaction. Several new fields will be added to support this change, including PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, and PSBT_GLOBAL_UNDER_CONSTRUCTION.Andrew Chow has also proposed another version called PSBTv2, which is a backward-incompatible update to the PSBT protocol. It introduces fields like Transaction Version, Fallback Locktime, Input Count, Output Count, and Transaction Modifiable Flags. Additionally, the process of determining the nLockTime field of a transaction is explained in detail.Rusty Russell and Andrew Chow discuss the addition of a new global field called PSBT_GLOBAL_UNDER_CONSTRUCTION in an email exchange. This field is used to signal whether inputs and outputs can be added to the PSBT. Rusty suggests flagging this by omitting redundant fields, but Andrew explains that those fields are necessary to determine the number of input and output maps. They also discuss the possibility of signed inputs being added to transactions and the complexity of allowing modification of inputs and outputs after the Creator role is done.Overall, these proposed changes aim to improve the usability and functionality of the PSBT format, allowing for easier construction of transactions and the addition of inputs and outputs as needed.Andrew Chow has proposed a new version of Partially Signed Bitcoin Transactions (PSBT), called PSBT v1, to address the deficiencies in the current PSBT v0. The primary change in the new version is to have all input and output data for each contained within their respective maps, disallowing PSBT_GLOBAL_UNSIGNED_TX. Several new fields are added for Global, Input, and Output, including PSBT_GLOBAL_TX_VERSION, PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, PSBT_GLOBAL_OUTPUT_COUNT, PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE, PSBT_IN_REQUIRED_LOCKTIME, PSBT_OUT_VALUE, and PSBT_OUT_OUTPUT_SCRIPT.These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, care must be taken to ensure that adding additional inputs and outputs will not invalidate existing signatures. Finalizers must choose the maximum of all the *_LOCKTIME fields to choose the locktime for the transaction.PSBT v1 also introduces two lock time fields - one for a time-based lock time and the other for a height-based lock time. This is necessary because all inputs must use the same type of lock time (height or time). Additionally, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, is added to signal whether inputs and outputs can be added to the PSBT. Rules must be followed to ensure that adding new inputs and outputs does not invalidate existing signatures.To uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. Combiners can create an unsigned transaction given the transaction version, input prevouts, outputs, and computed locktime, which can then be used as a way to identify PSBTs.As the changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1 needs a version number bump to enforce backward incompatibility. However, once the inputs and outputs are decided, a PSBT can be downgraded back to v0 by creating an unsigned transaction from the fields mentioned above and dropping these new fields.Andrew Chow has proposed these changes in BIP 174 and is willing to write a pull request to modify it if the changes are deemed reasonable.A new version of Partially Signed Bitcoin Transaction (PSBT) has been proposed to address the deficiencies in the current PSBT v0. The main change in this proposal is to store all input and output data for each in their respective maps, eliminating the need to parse an unsigned transaction and perform a lookup for data. This change would disallow the use of the PSBT_GLOBAL_UNSIGNED_TX field in the new version.To implement these changes, several fields are suggested to be added to both the Global and Input/Output sections of PSBT. One notable addition is the PSBT_GLOBAL_PREFERRED_LOCKTIME, which specifies the locktime to use if no inputs require a specific locktime. Another important field is the PSBT_IN_REQUIRED_LOCKTIME, which is necessary for inputs involving OP_CHECKLOCKTIMEVERIFY. This field allows finalizers to choose a locktime that meets the minimum requirement without needing to understand the scripts involved.It is worth mentioning that a Bitcoin transaction only has a single locktime, while a PSBT may have multiple locktimes. Therefore, finalizers must select - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2020/combined_Out-of-band-transaction-fees.xml b/static/bitcoin-dev/Dec_2020/combined_Out-of-band-transaction-fees.xml index 60f4690e9a..7c0ab346e8 100644 --- a/static/bitcoin-dev/Dec_2020/combined_Out-of-band-transaction-fees.xml +++ b/static/bitcoin-dev/Dec_2020/combined_Out-of-band-transaction-fees.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Out-of-band transaction fees - 2023-08-02T02:52:26.033368+00:00 - - Sebastian Geisler 2020-12-01 19:14:26+00:00 - - - ZmnSCPxj 2020-12-01 16:24:11+00:00 - - - ZmnSCPxj 2020-12-01 15:49:49+00:00 - - - Sebastian Geisler 2020-12-01 14:19:56+00:00 - - - eric at voskuil.org 2020-12-01 01:06:13+00:00 - - - Sebastian Geisler 2020-11-30 23:03:06+00:00 - + 2025-09-26T16:05:00.109207+00:00 + python-feedgen + + + [bitcoin-dev] Out-of-band transaction fees Sebastian Geisler + 2020-11-30T23:03:00.000Z + + + eric + 2020-12-01T01:06:00.000Z + + + Sebastian Geisler + 2020-12-01T14:19:00.000Z + + + ZmnSCPxj + 2020-12-01T15:49:00.000Z + + + ZmnSCPxj + 2020-12-01T16:24:00.000Z + + + Sebastian Geisler + 2020-12-01T19:14:00.000Z + + - python-feedgen + 2 Combined summary - Out-of-band transaction fees - 2023-08-02T02:52:26.033368+00:00 + 2025-09-26T16:05:00.110042+00:00 - In a discussion about improving the privacy of Bitcoin, participants consider alternative methods to enhance blockchain layer privacy. They explore the idea of paying someone to add their unspent transaction output (UTXO) to a transaction for fees, rather than relying on distinguishing honest service providers. The goal is to improve privacy regardless of standardized UTXO sizes. While protocols like JoinMarket and SwapMarket have been successful in this area, they have some overheads and require more UTXOs and larger transactions than necessary.Unequal output size CoinJoins are not well understood in terms of privacy properties, whereas evenly sized output CoinJoins offer efficiency. Speculatively, if Bitcoin becomes mainstream and transaction prices increase significantly, using Layer 2 (L2) technology and evenly sized UTXOs could be more cost-effective. However, this approach only works when exact values are unimportant and requires fee hacks.Although the initial idea has regulatory risks, there is potential for exploring an arbitrary-amount scheme that provides strong assurances efficiently. The conversation aims to devise a method for individuals to pay fees for transaction confirmation without linking other coins. A CoinJoin-like approach is suggested, using only Layer 1 (L1) and combining fees through a "FeeJoin" mechanism.The proposed mechanism involves a third-party service dividing its service into fixed-feerate bins. Clients can select their preferred feerate bin, ensuring miners and chain analysis cannot link the resulting transaction as they only see the resulting transaction. The ultimate objective is to improve privacy at the Bitcoin blockchain layer, regardless of the method used or whether standardized UTXO sizes are employed. Both JoinMarket and the upcoming SwapMarket do not require specific standardized UTXO sizes, giving clients the flexibility to choose any sizes they prefer.Developer Sebastian Geisler suggests the possibility of out-of-band transactions, allowing fees to be paid externally while preserving privacy. This would benefit tumbling and CoinJoin-type protocols. However, this approach relies on Layer 2 mechanisms like the Lightning Network and requires a reliable fee-bumping mechanism at Layer 1. Geisler highlights that out-of-band transaction fees have seen little interest thus far. One potential use case is sending UTXOs "intact" for settlement applications in Layer 2 systems.Geisler proposes having a standardized system for out-of-band transactions instead of each pool implementing its own API. Each service would announce the means of payment it supports, allowing users and miners to choose when paying or redeeming fees. Miners including a transaction would authenticate their claim with a unique public key. Nevertheless, concerns are raised about the centralizing effects and the potential difficulty of evaluating the trustworthiness of multiple third-party services.In summary, Sebastian Geisler's proposal of out-of-band transaction fees offers privacy-preserving fee payments in Bitcoin transactions. This can be beneficial for sending UTXOs "intact" and introducing further ambiguity in CoinJoin-like protocols. Standardizing such a system and mitigating centralizing effects are crucial. Users should be able to choose from different means of payment, and miners should authenticate their claims with a unique public key. Although not a general solution for fee payments, out-of-band options can assist specific protocols as Bitcoin serves as a settlement and reserve layer. 2020-12-01T19:14:26+00:00 + In a discussion about improving the privacy of Bitcoin, participants consider alternative methods to enhance blockchain layer privacy. They explore the idea of paying someone to add their unspent transaction output (UTXO) to a transaction for fees, rather than relying on distinguishing honest service providers. The goal is to improve privacy regardless of standardized UTXO sizes. While protocols like JoinMarket and SwapMarket have been successful in this area, they have some overheads and require more UTXOs and larger transactions than necessary.Unequal output size CoinJoins are not well understood in terms of privacy properties, whereas evenly sized output CoinJoins offer efficiency. Speculatively, if Bitcoin becomes mainstream and transaction prices increase significantly, using Layer 2 (L2) technology and evenly sized UTXOs could be more cost-effective. However, this approach only works when exact values are unimportant and requires fee hacks.Although the initial idea has regulatory risks, there is potential for exploring an arbitrary-amount scheme that provides strong assurances efficiently. The conversation aims to devise a method for individuals to pay fees for transaction confirmation without linking other coins. A CoinJoin-like approach is suggested, using only Layer 1 (L1) and combining fees through a "FeeJoin" mechanism.The proposed mechanism involves a third-party service dividing its service into fixed-feerate bins. Clients can select their preferred feerate bin, ensuring miners and chain analysis cannot link the resulting transaction as they only see the resulting transaction. The ultimate objective is to improve privacy at the Bitcoin blockchain layer, regardless of the method used or whether standardized UTXO sizes are employed. Both JoinMarket and the upcoming SwapMarket do not require specific standardized UTXO sizes, giving clients the flexibility to choose any sizes they prefer.Developer Sebastian Geisler suggests the possibility of out-of-band transactions, allowing fees to be paid externally while preserving privacy. This would benefit tumbling and CoinJoin-type protocols. However, this approach relies on Layer 2 mechanisms like the Lightning Network and requires a reliable fee-bumping mechanism at Layer 1. Geisler highlights that out-of-band transaction fees have seen little interest thus far. One potential use case is sending UTXOs "intact" for settlement applications in Layer 2 systems.Geisler proposes having a standardized system for out-of-band transactions instead of each pool implementing its own API. Each service would announce the means of payment it supports, allowing users and miners to choose when paying or redeeming fees. Miners including a transaction would authenticate their claim with a unique public key. Nevertheless, concerns are raised about the centralizing effects and the potential difficulty of evaluating the trustworthiness of multiple third-party services.In summary, Sebastian Geisler's proposal of out-of-band transaction fees offers privacy-preserving fee payments in Bitcoin transactions. This can be beneficial for sending UTXOs "intact" and introducing further ambiguity in CoinJoin-like protocols. Standardizing such a system and mitigating centralizing effects are crucial. Users should be able to choose from different means of payment, and miners should authenticate their claims with a unique public key. Although not a general solution for fee payments, out-of-band options can assist specific protocols as Bitcoin serves as a settlement and reserve layer. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml b/static/bitcoin-dev/Dec_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml index 37fc060e18..056f4b21fe 100644 --- a/static/bitcoin-dev/Dec_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml +++ b/static/bitcoin-dev/Dec_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Progress on bech32 for future Segwit Versions (BIP-173) - 2023-08-02T02:47:10.950630+00:00 - - Pieter Wuille 2020-12-18 02:02:04+00:00 - - - Ryan Grant 2020-12-08 17:39:23+00:00 - - - Pieter Wuille 2020-12-06 20:43:49+00:00 - - - David A. Harding 2020-12-06 13:04:53+00:00 - - - Pieter Wuille 2020-12-05 23:10:51+00:00 - - - Pieter Wuille 2020-12-05 22:59:17+00:00 - - - Mike Schmidt 2020-11-06 19:49:44+00:00 - - - Pieter Wuille 2020-10-28 00:20:40+00:00 - - - Rusty Russell 2020-10-21 04:51:34+00:00 - - - Rusty Russell 2020-10-21 04:39:32+00:00 - - - ZmnSCPxj 2020-10-21 03:05:35+00:00 - - - Mike Schmidt 2020-10-20 23:52:07+00:00 - - - Pieter Wuille 2020-10-20 20:12:25+00:00 - - - David A. Harding 2020-10-20 10:29:52+00:00 - - - Riccardo Casatta 2020-10-20 09:21:43+00:00 - - - Rusty Russell 2020-10-20 03:31:45+00:00 - - - Rusty Russell 2020-10-20 00:42:06+00:00 - - - Pieter Wuille 2020-10-19 22:55:50+00:00 - - - Rusty Russell 2020-10-19 00:49:17+00:00 - - - Pieter Wuille 2020-10-16 21:09:04+00:00 - - - Rusty Russell 2020-10-15 01:40:30+00:00 - - - Russell O'Connor 2020-10-08 15:21:47+00:00 - - - David A. Harding 2020-10-08 14:59:38+00:00 - - - Rusty Russell 2020-10-08 00:21:10+00:00 - + 2025-09-26T16:04:51.744349+00:00 + python-feedgen + + + [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173) Rusty Russell + 2020-10-08T00:21:00.000Z + + + David A. Harding + 2020-10-08T14:59:00.000Z + + + Russell O'Connor + 2020-10-08T15:21:00.000Z + + + Rusty Russell + 2020-10-15T01:40:00.000Z + + + Pieter Wuille + 2020-10-16T21:09:00.000Z + + + Rusty Russell + 2020-10-19T00:49:00.000Z + + + Pieter Wuille + 2020-10-19T22:55:00.000Z + + + Rusty Russell + 2020-10-20T00:42:00.000Z + + + Rusty Russell + 2020-10-20T03:31:00.000Z + + + Riccardo Casatta + 2020-10-20T09:21:00.000Z + + + David A. Harding + 2020-10-20T10:29:00.000Z + + + Pieter Wuille + 2020-10-20T20:12:00.000Z + + + Mike Schmidt + 2020-10-20T23:52:00.000Z + + + ZmnSCPxj + 2020-10-21T03:05:00.000Z + + + Rusty Russell + 2020-10-21T04:39:00.000Z + + + Rusty Russell + 2020-10-21T04:51:00.000Z + + + Pieter Wuille + 2020-10-28T00:20:00.000Z + + + Mike Schmidt + 2020-11-06T19:49:00.000Z + + + Pieter Wuille + 2020-12-05T22:59:00.000Z + + + Pieter Wuille + 2020-12-05T23:10:00.000Z + + + David A. Harding + 2020-12-06T13:04:00.000Z + + + Pieter Wuille + 2020-12-06T20:43:00.000Z + + + Ryan Grant + 2020-12-08T17:39:00.000Z + + + Pieter Wuille + 2020-12-18T02:02:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Progress on bech32 for future Segwit Versions (BIP-173) - 2023-08-02T02:47:10.950630+00:00 + 2025-09-26T16:04:51.747103+00:00 - In a recent discussion on the Bitcoin mailing list, Pieter Wuille and Rusty Russell explored the implementation of changes to witness version 1 (v1) addresses. Currently, there are no v1 receivers, so the focus is on determining what software and infrastructure support sending to v1 addresses and whether they will upgrade. The first option discussed is to continue using v1, while the second option involves upgrading to a new version. There are concerns about trailing typos causing issues for non-upgraded software under option 1. Option 2, on the other hand, would likely lead to fixes when someone attempts a v1 send. However, it is possible that non-upgraded software may never get fixed, delaying the ability to use v1 addresses.Pieter is interested in understanding which codebases, services, and infrastructure currently support sending to witness v1 BIP173 addresses. Rusty suggests spamming an address from various sources to test compatibility with v1 addresses. They discuss the potential adoption of new technology based on the replacement of older infrastructure and codebases. Both Pieter and Rusty acknowledge that their thinking on this matter may change over time.Another proposal brought up by Rusty Russell involves two options for the future of v1 receivers. The first option is to continue using v1, while the second option requires upgrading to a new version. The support for sending to v1 BIP173 addresses is a key consideration in making this decision. Rusty favors the second option as it forces upgrades and breaks clearly. He believes that accepting v1 addresses without upgrades could create liabilities. David A. Harding agrees with the first proposal, highlighting the effort put into obtaining widespread support for bech32 addresses. Harding suggests that consensus should restrict v1 witness program size to maximize safety.In a separate thread, David A. Harding expresses his preference for using the backwards compatible proposal from BIPs PR#945. He suggests that consensus should restrict v1 witness program size by rejecting transactions with scriptPubKeys paying v1 witness programs that aren't exactly 32 bytes. Harding believes that deferring a hard decision is not useful, and he hopes that most software will have implemented length limits by the time segwit v2 is used.Rusty Russell proposes an alternative to the length restrictions discussed in a BIPs pull request. The alternative involves using a checksum change based on the first byte, unless the first byte is 0. There are two proposals debated in the discussion. The first proposal suggests length restrictions for future segwits, while the second proposal suggests a checksum change based on the first byte. Rusty prefers the second option as it forces upgrades and breaks clearly. However, David A. Harding argues that the second option does not force upgrades but creates another opt-in address format. Harding favors the backwards compatible proposal from BIPs PR#945 and suggests consensus restricting v1 witness program size for safety purposes.The author of the proposal suggests an alternative to length restrictions proposed by Rusty Russell. The alternative involves using a variant based on the first byte, unless the first byte is 0. There are two proposals discussed: length restrictions and a checksum change based on the first byte. The first proposal restricts future segwit versions, while the second weakens guarantees against typos. The author prefers the second proposal as it forces upgrades and addresses the length extension bug. They emphasize the need for a decision to be made promptly to begin upgrading software. It is also mentioned that Lightning uses bech32 over longer lengths but will follow Bitcoin's choice.Overall, the discussions revolve around the implementation of changes to witness version 1 addresses, the support for sending to v1 BIP173 addresses, and the options for future versions. Various proposals and concerns are raised regarding compatibility, upgrades, safety, and the simplicity of the changes. The participants acknowledge that their perspectives may evolve over time and emphasize the importance of gathering data and making informed decisions. 2020-12-18T02:02:04+00:00 + In a recent discussion on the Bitcoin mailing list, Pieter Wuille and Rusty Russell explored the implementation of changes to witness version 1 (v1) addresses. Currently, there are no v1 receivers, so the focus is on determining what software and infrastructure support sending to v1 addresses and whether they will upgrade. The first option discussed is to continue using v1, while the second option involves upgrading to a new version. There are concerns about trailing typos causing issues for non-upgraded software under option 1. Option 2, on the other hand, would likely lead to fixes when someone attempts a v1 send. However, it is possible that non-upgraded software may never get fixed, delaying the ability to use v1 addresses.Pieter is interested in understanding which codebases, services, and infrastructure currently support sending to witness v1 BIP173 addresses. Rusty suggests spamming an address from various sources to test compatibility with v1 addresses. They discuss the potential adoption of new technology based on the replacement of older infrastructure and codebases. Both Pieter and Rusty acknowledge that their thinking on this matter may change over time.Another proposal brought up by Rusty Russell involves two options for the future of v1 receivers. The first option is to continue using v1, while the second option requires upgrading to a new version. The support for sending to v1 BIP173 addresses is a key consideration in making this decision. Rusty favors the second option as it forces upgrades and breaks clearly. He believes that accepting v1 addresses without upgrades could create liabilities. David A. Harding agrees with the first proposal, highlighting the effort put into obtaining widespread support for bech32 addresses. Harding suggests that consensus should restrict v1 witness program size to maximize safety.In a separate thread, David A. Harding expresses his preference for using the backwards compatible proposal from BIPs PR#945. He suggests that consensus should restrict v1 witness program size by rejecting transactions with scriptPubKeys paying v1 witness programs that aren't exactly 32 bytes. Harding believes that deferring a hard decision is not useful, and he hopes that most software will have implemented length limits by the time segwit v2 is used.Rusty Russell proposes an alternative to the length restrictions discussed in a BIPs pull request. The alternative involves using a checksum change based on the first byte, unless the first byte is 0. There are two proposals debated in the discussion. The first proposal suggests length restrictions for future segwits, while the second proposal suggests a checksum change based on the first byte. Rusty prefers the second option as it forces upgrades and breaks clearly. However, David A. Harding argues that the second option does not force upgrades but creates another opt-in address format. Harding favors the backwards compatible proposal from BIPs PR#945 and suggests consensus restricting v1 witness program size for safety purposes.The author of the proposal suggests an alternative to length restrictions proposed by Rusty Russell. The alternative involves using a variant based on the first byte, unless the first byte is 0. There are two proposals discussed: length restrictions and a checksum change based on the first byte. The first proposal restricts future segwit versions, while the second weakens guarantees against typos. The author prefers the second proposal as it forces upgrades and addresses the length extension bug. They emphasize the need for a decision to be made promptly to begin upgrading software. It is also mentioned that Lightning uses bech32 over longer lengths but will follow Bitcoin's choice.Overall, the discussions revolve around the implementation of changes to witness version 1 addresses, the support for sending to v1 BIP173 addresses, and the options for future versions. Various proposals and concerns are raised regarding compatibility, upgrades, safety, and the simplicity of the changes. The participants acknowledge that their perspectives may evolve over time and emphasize the importance of gathering data and making informed decisions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2020/combined_Softchains-Sidechains-as-a-Soft-Fork-via-Proof-of-Work-Fraud-Proofs.xml b/static/bitcoin-dev/Dec_2020/combined_Softchains-Sidechains-as-a-Soft-Fork-via-Proof-of-Work-Fraud-Proofs.xml index 750fbb4915..1fbe8de7c6 100644 --- a/static/bitcoin-dev/Dec_2020/combined_Softchains-Sidechains-as-a-Soft-Fork-via-Proof-of-Work-Fraud-Proofs.xml +++ b/static/bitcoin-dev/Dec_2020/combined_Softchains-Sidechains-as-a-Soft-Fork-via-Proof-of-Work-Fraud-Proofs.xml @@ -1,35 +1,27 @@ - + 2 Combined summary - Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs - 2023-08-02T02:59:13.920871+00:00 - - Ruben Somsen 2021-01-01 00:05:59+00:00 - - - Ruben Somsen 2020-12-31 23:39:10+00:00 - - - Sergio Demian Lerner 2020-12-31 23:37:58+00:00 - - - ZmnSCPxj 2020-12-31 23:26:24+00:00 - - - Ruben Somsen 2020-12-31 22:00:17+00:00 - + 2025-09-26T16:04:53.836935+00:00 + python-feedgen + + + Ruben Somsen + 2021-01-01T00:05:00.000Z + + - python-feedgen + 2 Combined summary - Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs - 2023-08-02T02:59:13.920871+00:00 + 2025-09-26T16:04:53.837368+00:00 - Ruben Somsen has proposed a fully decentralized two-way peg sidechain design called Softchains. This design requires a soft fork to activate new sidechains and utilizes Proof-of-Work Fraud Proofs (PoW FP) as the consensus mechanism for validating disputed blocks. All Softchains are validated by everyone through PoW FP consensus. If a user wants to directly use a specific Softchain, they need to run it as a full node to achieve fast consensus.Peg-ins occur by freezing coins on the mainchain and assigning them to a Softchain, while peg-outs involve creating a mainchain transaction that points to a peg-out transaction on a Softchain and waiting for enough mainchain confirmations. However, Softchain consensus still requires validation from mainchain users, and consensus bugs can have negative consequences. These bugs could potentially cause a chain split in mainchain consensus or invalidate a peg-out right after it becomes accepted on the mainchain, thus splitting consensus.There are potential risks associated with Softchains, such as non-deterministic consensus bugs and major reorgs. To mitigate these risks, Ruben suggests basing Softchain designs on Bitcoin Core and implementing a rule disallowing reorgs larger than half the peg-out time. It is important for each Softchain to produce a significant amount of PoW to ensure security and prevent cost reductions in creating forks. Merged mining could aid in maintaining security, but it would place an additional burden on miners for validation.In conclusion, the Softchains proposal offers the potential for more opt-in block space and the ability to introduce chains with different consensus rules. However, there are significant risks involved, and Ruben welcomes feedback and ideas on how to address these issues and ensure maximum safety. 2021-01-01T00:05:59+00:00 + Ruben Somsen has proposed a fully decentralized two-way peg sidechain design called Softchains. This design requires a soft fork to activate new sidechains and utilizes Proof-of-Work Fraud Proofs (PoW FP) as the consensus mechanism for validating disputed blocks. All Softchains are validated by everyone through PoW FP consensus. If a user wants to directly use a specific Softchain, they need to run it as a full node to achieve fast consensus.Peg-ins occur by freezing coins on the mainchain and assigning them to a Softchain, while peg-outs involve creating a mainchain transaction that points to a peg-out transaction on a Softchain and waiting for enough mainchain confirmations. However, Softchain consensus still requires validation from mainchain users, and consensus bugs can have negative consequences. These bugs could potentially cause a chain split in mainchain consensus or invalidate a peg-out right after it becomes accepted on the mainchain, thus splitting consensus.There are potential risks associated with Softchains, such as non-deterministic consensus bugs and major reorgs. To mitigate these risks, Ruben suggests basing Softchain designs on Bitcoin Core and implementing a rule disallowing reorgs larger than half the peg-out time. It is important for each Softchain to produce a significant amount of PoW to ensure security and prevent cost reductions in creating forks. Merged mining could aid in maintaining security, but it would place an additional burden on miners for validation.In conclusion, the Softchains proposal offers the potential for more opt-in block space and the ability to introduce chains with different consensus rules. However, there are significant risks involved, and Ruben welcomes feedback and ideas on how to address these issues and ensure maximum safety. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2020/combined_bip48-proposal.xml b/static/bitcoin-dev/Dec_2020/combined_bip48-proposal.xml index d5afe2f1e7..e0b8cd99b4 100644 --- a/static/bitcoin-dev/Dec_2020/combined_bip48-proposal.xml +++ b/static/bitcoin-dev/Dec_2020/combined_bip48-proposal.xml @@ -1,38 +1,19 @@ - + 2 Combined summary - bip48 proposal - 2023-08-02T02:57:59.641543+00:00 - - Craig Raw 2021-02-25 10:23:59+00:00 - - - dentondevelopment 2021-02-24 14:02:00+00:00 - - - Luke Dashjr 2020-12-18 04:08:30+00:00 - - - dentondevelopment 2020-12-18 01:49:07+00:00 - - - dentondevelopment 2020-12-18 01:44:27+00:00 - - - Pavol Rusnak 2020-12-17 10:58:08+00:00 - - - Keagan McClelland 2020-12-16 18:48:30+00:00 - - - Luke Dashjr 2020-12-16 17:16:54+00:00 - - - dentondevelopment 2020-12-16 14:10:28+00:00 - - - dentondevelopment 2020-12-16 12:43:58+00:00 - + 2025-09-26T16:05:06.415258+00:00 + python-feedgen + + + dentondevelopment + 2021-02-24T14:02:00.000Z + + + Craig Raw + 2021-02-25T10:23:00.000Z + + @@ -43,13 +24,13 @@ - python-feedgen + 2 Combined summary - bip48 proposal - 2023-08-02T02:57:59.641543+00:00 + 2025-09-26T16:05:06.415884+00:00 - A proposal for a new Bitcoin Improvement Proposal (BIP) called bip48 has been put forward by Fontaine. The purpose of this BIP is to document modern multi-sig derivations and provide clarity on the usage of 48 paths. The proposal draws inspiration from bip44 and aims to define an already existing standard used in practice across multi-sig wallets. However, some key points have been raised during discussions, such as not defining a `script_type` as a path level and including a defined "wild card" in the script_type level to accommodate future address types.Fontaine has created a pull request (PR) for the proposed bip48, allowing anyone to easily comment and raise concerns. The community feedback has been positive, with other developers expressing support for the proposal. The proposal is still a work in progress, and Fontaine is incorporating feedback from Pavol Rusnak and others before sharing the next draft.In response to the proposal, Luke Dashjr reminded Fontaine not to self-assign BIP numbers and asked about compatibility with another pull request. Fontaine clarified that they had only received guidance from the README and suggested that bip48 would be fitting if it remained unused. The communication regarding the proposal took place through email, using ProtonMail for secure communication.Pavol Rusnak, co-founder and CTO of SatoshiLabs, commended Fontaine's effort in proposing bip48 and pointed out that their documentation of 48 path usage also includes script_type=0 for raw BIP-11 multisig. They suggested that this should be included in the proposed BIP as well. Fontaine expressed gratitude for the link provided by Pavol Rusnak and welcomed comments and input on the proposed bip48.The proposal and discussions surrounding bip48 were shared through email threads on the bitcoin-dev mailing list. The proposal was initially shared via a static link and later through a GitHub repository, where others could provide comments and suggestions. It should be noted that self-assigning BIP numbers is not allowed, and the compatibility of bip48 with another pull request remains unclear.In summary, Fontaine has proposed bip48 as a BIP to document modern multi-sig derivations. The proposal aims to define an existing standard used in multi-sig wallets, with a focus on p2sh-p2wsh and p2wsh derivations. Feedback and support from the community have been positive, and Fontaine is incorporating feedback before sharing the next draft. The proposal and discussions have taken place through email threads and a GitHub repository, ensuring secure communication. 2021-02-25T10:23:59+00:00 + A proposal for a new Bitcoin Improvement Proposal (BIP) called bip48 has been put forward by Fontaine. The purpose of this BIP is to document modern multi-sig derivations and provide clarity on the usage of 48 paths. The proposal draws inspiration from bip44 and aims to define an already existing standard used in practice across multi-sig wallets. However, some key points have been raised during discussions, such as not defining a `script_type` as a path level and including a defined "wild card" in the script_type level to accommodate future address types.Fontaine has created a pull request (PR) for the proposed bip48, allowing anyone to easily comment and raise concerns. The community feedback has been positive, with other developers expressing support for the proposal. The proposal is still a work in progress, and Fontaine is incorporating feedback from Pavol Rusnak and others before sharing the next draft.In response to the proposal, Luke Dashjr reminded Fontaine not to self-assign BIP numbers and asked about compatibility with another pull request. Fontaine clarified that they had only received guidance from the README and suggested that bip48 would be fitting if it remained unused. The communication regarding the proposal took place through email, using ProtonMail for secure communication.Pavol Rusnak, co-founder and CTO of SatoshiLabs, commended Fontaine's effort in proposing bip48 and pointed out that their documentation of 48 path usage also includes script_type=0 for raw BIP-11 multisig. They suggested that this should be included in the proposed BIP as well. Fontaine expressed gratitude for the link provided by Pavol Rusnak and welcomed comments and input on the proposed bip48.The proposal and discussions surrounding bip48 were shared through email threads on the bitcoin-dev mailing list. The proposal was initially shared via a static link and later through a GitHub repository, where others could provide comments and suggestions. It should be noted that self-assigning BIP numbers is not allowed, and the compatibility of bip48 with another pull request remains unclear.In summary, Fontaine has proposed bip48 as a BIP to document modern multi-sig derivations. The proposal aims to define an existing standard used in multi-sig wallets, with a focus on p2sh-p2wsh and p2wsh derivations. Feedback and support from the community have been positive, and Fontaine is incorporating feedback before sharing the next draft. The proposal and discussions have taken place through email threads and a GitHub repository, ensuring secure communication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-A-Defense-of-Having-Fun-and-maybe-staying-poor-.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-A-Defense-of-Having-Fun-and-maybe-staying-poor-.xml index 2603065559..f8800d13d5 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-A-Defense-of-Having-Fun-and-maybe-staying-poor-.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-A-Defense-of-Having-Fun-and-maybe-staying-poor-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - [Bitcoin Advent Calendar] A Defense of Having Fun (and maybe staying poor) - 2023-08-02T05:15:19.654537+00:00 - - Prayank 2021-12-23 14:09:13+00:00 - - - Jeremy 2021-12-14 18:37:59+00:00 - + 2025-09-26T15:31:17.505588+00:00 + python-feedgen + + + [bitcoin-dev] [Bitcoin Advent Calendar] A Defense of Having Fun (and maybe staying poor) Jeremy + 2021-12-14T18:37:00.000Z + + + Prayank + 2021-12-23T14:09:00.000Z + + - python-feedgen + 2 Combined summary - [Bitcoin Advent Calendar] A Defense of Having Fun (and maybe staying poor) - 2023-08-02T05:15:19.654537+00:00 + 2025-09-26T15:31:17.506094+00:00 - A developer named Eugene has decided to abandon his project of implementing a human versus chess engine in Solidity. The project involved creating interactive NFTs that represent the contract's internal states, although it is unclear why NFTs were incorporated into the project. Some suggestions were made to try implementing the project on Lightning as well. When asked about working on Bitcoin instead, Eugene stated that while Bitcoin development can be fun, it is often not enjoyable. This sentiment has caused multiple contributors to step down from their involvement recently, as even small features require significant effort to ship. It is difficult to convince newcomers to work on Bitcoin full-time due to these challenges. The issue of funding in open-source projects extends beyond Bitcoin and is being addressed by various individuals and organizations.Despite the difficulties, Eugene believes that any issues with Bitcoin development can be resolved. He argues that NFTs are a phenomenon that people should care about, citing examples such as the development of Zero Knowledge Roll-Ups to address scaling challenges in Ethereum, as well as privacy solutions like Tornado Cash. However, Prayank disagrees and claims that the trend towards NFTs is primarily driven by the desire for financial gain and lacks true innovation.In a recent post by Jeremy Rubin, he takes a less technical and more philosophical approach. The post has received positive feedback from readers and focuses on the importance of having fun as a treat. Rubin mentions that he will continue to share posts based on private feedback he has received from multiple individuals. Those interested in reading the post can find the link provided. Overall, the post delivers a lighthearted message encouraging readers to find enjoyment in the midst of their work and responsibilities. 2021-12-23T14:09:13+00:00 + A developer named Eugene has decided to abandon his project of implementing a human versus chess engine in Solidity. The project involved creating interactive NFTs that represent the contract's internal states, although it is unclear why NFTs were incorporated into the project. Some suggestions were made to try implementing the project on Lightning as well. When asked about working on Bitcoin instead, Eugene stated that while Bitcoin development can be fun, it is often not enjoyable. This sentiment has caused multiple contributors to step down from their involvement recently, as even small features require significant effort to ship. It is difficult to convince newcomers to work on Bitcoin full-time due to these challenges. The issue of funding in open-source projects extends beyond Bitcoin and is being addressed by various individuals and organizations.Despite the difficulties, Eugene believes that any issues with Bitcoin development can be resolved. He argues that NFTs are a phenomenon that people should care about, citing examples such as the development of Zero Knowledge Roll-Ups to address scaling challenges in Ethereum, as well as privacy solutions like Tornado Cash. However, Prayank disagrees and claims that the trend towards NFTs is primarily driven by the desire for financial gain and lacks true innovation.In a recent post by Jeremy Rubin, he takes a less technical and more philosophical approach. The post has received positive feedback from readers and focuses on the importance of having fun as a treat. Rubin mentions that he will continue to share posts based on private feedback he has received from multiple individuals. Those interested in reading the post can find the link provided. Overall, the post delivers a lighthearted message encouraging readers to find enjoyment in the midst of their work and responsibilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Decentralized-Autonomous-Organizations-DAOs-Will-Save-Bitcoin.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Decentralized-Autonomous-Organizations-DAOs-Will-Save-Bitcoin.xml index cc81175a03..4e6fc2e3cd 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Decentralized-Autonomous-Organizations-DAOs-Will-Save-Bitcoin.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Decentralized-Autonomous-Organizations-DAOs-Will-Save-Bitcoin.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - [Bitcoin Advent Calendar] Decentralized Autonomous Organizations (DAOs) Will Save Bitcoin - 2023-08-02T05:16:15.939936+00:00 - - Jeremy 2021-12-23 19:30:50+00:00 - - - Oscar Lafarga 2021-12-23 18:10:48+00:00 - - - Jeremy 2021-12-23 03:47:06+00:00 - + 2025-09-26T15:31:13.302034+00:00 + python-feedgen + + + [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Autonomous Organizations (DAOs) Will Save Bitcoin Jeremy + 2021-12-23T03:47:00.000Z + + + Oscar Lafarga + 2021-12-23T18:10:00.000Z + + + Jeremy + 2021-12-23T19:30:00.000Z + + - python-feedgen + 2 Combined summary - [Bitcoin Advent Calendar] Decentralized Autonomous Organizations (DAOs) Will Save Bitcoin - 2023-08-02T05:16:15.939936+00:00 + 2025-09-26T15:31:13.302594+00:00 - Jeremy Rubin, a Bitcoin developer, recently expressed his enthusiasm for the potential of capital formation within the Bitcoin ecosystem. In an email to the bitcoin-dev mailing list, he highlighted the ability for individuals to run their own small companies with shareholders inside of Bitcoin, aligning with the ethos of "be your own bank" that Bitcoin promotes. While this does not necessarily require Consensus-enforced Transaction Outputs (CTV), it does rely on the development of flexible and composable software.Rubin introduced Sapio as a compiler toolchain that enables users to interact with Bitcoin contract outputs through its graphical user interface (GUI) called Sapio Studio. Similar to Solidity in Ethereum and Metamask/web3.js, Sapio provides a means for users to engage with Bitcoin's smart contract capabilities. However, Rubin clarified that Sapio is not comparable to Lightning, the scaling solution for Bitcoin.Curious about the implementation of Sapio, the author of the email wonders if there is a client for Sapio that can be run alongside a Bitcoin full node, akin to how a Lightning node operates. They also question whether the computational requirements, bandwidth usage, and liveness considerations for running Sapio contracts are similar to those of Lightning. To delve deeper into Sapio's functionality, the author suggests exploring the Sapio GitHub repository at https://github.com/sapio-lang/sapio as a recommended starting point.In terms of future plans, Rubin mentions that two more posts will be published, focusing on further dissemination of the ideas behind capital formation in Bitcoin. He invites individuals to share their thoughts on BIP-119 activation, either publicly or privately. Public "soft-signals" can be expressed by editing the appropriate file(s) found at https://utxos.org/signals and submitting a pull request. Alternatively, individuals can publicly comment on the topic and provide Jeremy Rubin with the link to their contribution, allowing him to make the necessary edits.Overall, Rubin's blog post emphasizes the potential for capital formation in Bitcoin and highlights Sapio as a toolchain that enables users to engage with Bitcoin contract outputs. He invites further discussions on BIP-119 activation and encourages individuals to participate in shaping the future of Bitcoin's capital formation capabilities. 2021-12-23T19:30:50+00:00 + Jeremy Rubin, a Bitcoin developer, recently expressed his enthusiasm for the potential of capital formation within the Bitcoin ecosystem. In an email to the bitcoin-dev mailing list, he highlighted the ability for individuals to run their own small companies with shareholders inside of Bitcoin, aligning with the ethos of "be your own bank" that Bitcoin promotes. While this does not necessarily require Consensus-enforced Transaction Outputs (CTV), it does rely on the development of flexible and composable software.Rubin introduced Sapio as a compiler toolchain that enables users to interact with Bitcoin contract outputs through its graphical user interface (GUI) called Sapio Studio. Similar to Solidity in Ethereum and Metamask/web3.js, Sapio provides a means for users to engage with Bitcoin's smart contract capabilities. However, Rubin clarified that Sapio is not comparable to Lightning, the scaling solution for Bitcoin.Curious about the implementation of Sapio, the author of the email wonders if there is a client for Sapio that can be run alongside a Bitcoin full node, akin to how a Lightning node operates. They also question whether the computational requirements, bandwidth usage, and liveness considerations for running Sapio contracts are similar to those of Lightning. To delve deeper into Sapio's functionality, the author suggests exploring the Sapio GitHub repository at https://github.com/sapio-lang/sapio as a recommended starting point.In terms of future plans, Rubin mentions that two more posts will be published, focusing on further dissemination of the ideas behind capital formation in Bitcoin. He invites individuals to share their thoughts on BIP-119 activation, either publicly or privately. Public "soft-signals" can be expressed by editing the appropriate file(s) found at https://utxos.org/signals and submitting a pull request. Alternatively, individuals can publicly comment on the topic and provide Jeremy Rubin with the link to their contribution, allowing him to make the necessary edits.Overall, Rubin's blog post emphasizes the potential for capital formation in Bitcoin and highlights Sapio as a toolchain that enables users to engage with Bitcoin contract outputs. He invites further discussions on BIP-119 activation and encourages individuals to participate in shaping the future of Bitcoin's capital formation capabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Decentralized-Coordination-Free-Mining-Pools.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Decentralized-Coordination-Free-Mining-Pools.xml index 6643207da2..7b9ddbd1cc 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Decentralized-Coordination-Free-Mining-Pools.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Decentralized-Coordination-Free-Mining-Pools.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools - 2023-08-02T05:14:21.409949+00:00 - - Billy Tetrud 2022-01-18 18:15:15+00:00 - - - Jeremy 2021-12-23 19:05:22+00:00 - - - vjudeu at gazeta.pl 2021-12-23 11:56:18+00:00 - - - Billy Tetrud 2021-12-20 17:18:44+00:00 - - - vjudeu at gazeta.pl 2021-12-17 06:37:17+00:00 - - - Jeremy 2021-12-17 00:37:09+00:00 - - - Billy Tetrud 2021-12-16 16:57:03+00:00 - - - vjudeu at gazeta.pl 2021-12-16 09:35:04+00:00 - - - Jeremy 2021-12-15 21:53:50+00:00 - - - yanmaani at cock.li 2021-12-15 21:10:51+00:00 - - - Bob McElrath 2021-12-15 18:51:41+00:00 - - - Jeremy 2021-12-15 18:39:28+00:00 - - - Billy Tetrud 2021-12-15 17:25:15+00:00 - - - Bob McElrath 2021-12-15 00:12:00+00:00 - - - Bob McElrath 2021-12-14 23:33:05+00:00 - - - Jeremy 2021-12-14 19:50:33+00:00 - - - Jeremy 2021-12-14 19:39:06+00:00 - - - vjudeu at gazeta.pl 2021-12-13 14:10:49+00:00 - - - Jeremy 2021-12-13 01:31:42+00:00 - - - vjudeu at gazeta.pl 2021-12-12 23:14:45+00:00 - - - Jeremy 2021-12-12 16:43:12+00:00 - + 2025-09-26T15:31:21.739424+00:00 + python-feedgen + + + [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools Jeremy + 2021-12-12T16:43:00.000Z + + + vjudeu + 2021-12-12T23:14:00.000Z + + + Jeremy + 2021-12-13T01:31:00.000Z + + + vjudeu + 2021-12-13T14:10:00.000Z + + + Jeremy + 2021-12-14T19:39:00.000Z + + + Jeremy + 2021-12-14T19:50:00.000Z + + + Bob McElrath + 2021-12-14T23:33:00.000Z + + + Bob McElrath + 2021-12-15T00:12:00.000Z + + + Billy Tetrud + 2021-12-15T17:25:00.000Z + + + Jeremy + 2021-12-15T18:39:00.000Z + + + Bob McElrath + 2021-12-15T18:51:00.000Z + + + yanmaani + 2021-12-15T21:10:00.000Z + + + Jeremy + 2021-12-15T21:53:00.000Z + + + vjudeu + 2021-12-16T09:35:00.000Z + + + Billy Tetrud + 2021-12-16T16:57:00.000Z + + + Jeremy + 2021-12-17T00:37:00.000Z + + + vjudeu + 2021-12-17T06:37:00.000Z + + + Billy Tetrud + 2021-12-20T17:18:00.000Z + + + vjudeu + 2021-12-23T11:56:00.000Z + + + Jeremy + 2021-12-23T19:05:00.000Z + + + Billy Tetrud + 2022-01-18T18:15:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools - 2023-08-02T05:14:21.409949+00:00 + 2025-09-26T15:31:21.741804+00:00 - The discussion revolves around proposals for improving Bitcoin mining pools. One proposal suggests creating a separate blockchain called "superblocks" that would progress linearly and keep block headers instead of transactions. The idea is to collect uncollected blocks into the next superblock and reward the block creator based on the number of blocks included. Various approaches to defining windows and reward functions are discussed, including paying less for blocks found in rapid succession. Concerns have been raised about the feasibility and security of this design, as well as the issue of unspendable block rewards.Other suggestions include using weak blocks and an ephemeral blockchain or utilizing multisig and leaf nodes to enable smaller miners to participate without centralized control. These proposals aim to increase payout regularity and reduce on-chain footprint through combined payouts or non-custodial mining pools. However, questions remain about the distribution of block rewards and data availability.The role of Proof of Stake and the value of signing in mining are also discussed. Some participants suggest focusing on specific problems where CheckTemplateVerify (CTV) is the best solution, rather than trying to cover all aspects. Safety concerns are raised about throwing block rewards into a channel for immediate spending, and there is a need to reduce on-chain wait time for spending block rewards.The Braidpool project is mentioned, which proposes a separate blockchain with superblocks storing only block headers. There are public forums and mailing lists available for people to join, and the creators welcome additional contributors. However, concerns have been expressed about the design, suggesting a focus on one specific problem that CTV can effectively solve.The debate also includes discussions on the definition of a pool, reducing profit variance, resource management, and the goals of payout functions for solo miners and mining pools. There are suggestions for simplifying verification of coinbase rewards, assigning difficulty levels to shares, and using longer windows of difficulty periods to hedge against changes in hashrate.Overall, the discussion showcases ongoing debates among Bitcoin developers regarding the efficiency and security of mining pools. While there are differing opinions and concerns about the proposed solutions, there is a recognition of the potential benefits in exploring different designs and techniques to address issues related to payout regularity, on-chain footprint, and unspendable block rewards. 2022-01-18T18:15:15+00:00 + The discussion revolves around proposals for improving Bitcoin mining pools. One proposal suggests creating a separate blockchain called "superblocks" that would progress linearly and keep block headers instead of transactions. The idea is to collect uncollected blocks into the next superblock and reward the block creator based on the number of blocks included. Various approaches to defining windows and reward functions are discussed, including paying less for blocks found in rapid succession. Concerns have been raised about the feasibility and security of this design, as well as the issue of unspendable block rewards.Other suggestions include using weak blocks and an ephemeral blockchain or utilizing multisig and leaf nodes to enable smaller miners to participate without centralized control. These proposals aim to increase payout regularity and reduce on-chain footprint through combined payouts or non-custodial mining pools. However, questions remain about the distribution of block rewards and data availability.The role of Proof of Stake and the value of signing in mining are also discussed. Some participants suggest focusing on specific problems where CheckTemplateVerify (CTV) is the best solution, rather than trying to cover all aspects. Safety concerns are raised about throwing block rewards into a channel for immediate spending, and there is a need to reduce on-chain wait time for spending block rewards.The Braidpool project is mentioned, which proposes a separate blockchain with superblocks storing only block headers. There are public forums and mailing lists available for people to join, and the creators welcome additional contributors. However, concerns have been expressed about the design, suggesting a focus on one specific problem that CTV can effectively solve.The debate also includes discussions on the definition of a pool, reducing profit variance, resource management, and the goals of payout functions for solo miners and mining pools. There are suggestions for simplifying verification of coinbase rewards, assigning difficulty levels to shares, and using longer windows of difficulty periods to hedge against changes in hashrate.Overall, the discussion showcases ongoing debates among Bitcoin developers regarding the efficiency and security of mining pools. While there are differing opinions and concerns about the proposed solutions, there is a recognition of the potential benefits in exploring different designs and techniques to address issues related to payout regularity, on-chain footprint, and unspendable block rewards. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Derivatives-and-Options.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Derivatives-and-Options.xml index 86241d27f8..e26047843d 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Derivatives-and-Options.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Derivatives-and-Options.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - [Bitcoin Advent Calendar] Derivatives and Options - 2023-08-02T05:16:02.602032+00:00 - - Thibaut Le Guilly 2021-12-27 12:05:36+00:00 - - - email at yancy.lol 2021-12-26 20:49:30+00:00 - - - Jeremy 2021-12-24 17:17:16+00:00 - - - Prayank 2021-12-24 16:42:42+00:00 - - - Jeremy 2021-12-21 01:17:34+00:00 - + 2025-09-26T15:30:56.562850+00:00 + python-feedgen + + + [bitcoin-dev] [Bitcoin Advent Calendar] Derivatives and Options Jeremy + 2021-12-21T01:17:00.000Z + + + Prayank + 2021-12-24T16:42:00.000Z + + + Jeremy + 2021-12-24T17:17:00.000Z + + + email + 2021-12-26T20:49:00.000Z + + + Thibaut Le Guilly + 2021-12-27T12:05:00.000Z + + - python-feedgen + 2 Combined summary - [Bitcoin Advent Calendar] Derivatives and Options - 2023-08-02T05:16:02.602032+00:00 + 2025-09-26T15:30:56.563625+00:00 - In a Bitcoin developer mailing list, users discussed the ongoing development of the p2pderivatives DLC application. Yancy shared that the project is still under active development and provided a GitHub link to the project. Prayank mentioned the use of discreet log contracts for multi oracles and linked the p2pderivatives-client, p2pderivatives-server, and p2pderivatives-oracle GitHub repositories. The discussion also touched on the potential benefits of implementing OP_CTV in the project and explored the concept of unilateral derivatives. Thibaut introduced rust-dlc as another actively developed project that supports multi oracle contracts and other features found in the DLC specifications. They invited Jeremy to join their monthly DLC spec meeting to discuss how CTV could enhance the Bitcoin derivatives ecosystem and what aspects could be reused from DLCs. This conversation highlights the ongoing development and exploration of derivatives within the Bitcoin community.In an email exchange between Yancy and Prayank, it was revealed that the p2pderivatives DLC application is still being developed on GitHub using a single oracle. Yancy shared links to the repository for the client, server, and oracle components of the project. Prayank further discussed the use of multi-oracles in discreet log contracts and referenced the p2pderivatives project. The necessity of OP_CTV in the p2pderivatives project was questioned, to which Yancy responded that while not necessary, certain aspects of the project could benefit from its implementation. The conversation also delved into the concept of unilateral derivatives and how they could function even without a peer to take the other side of the trade. Both participants expressed interest in exploring derivatives as a lesser-explored area of Bitcoin projects that could potentially address various problems. Links to powswap.com and the bitcoin-dev mailing list were shared during the conversation.Prayank and Jeremy engaged in an email conversation discussing the implementation of threshold oracles in Bitcoin and their potential application in derivatives trading. They mentioned a project called P2P Derivatives that employs a similar approach but has not been used for real trades on the mainnet or further developed. The discussion then shifted to the advantages of unilateral opens, which enable one party to make payments into a derivative without requiring the counterparty to be online. This feature is particularly useful when dealing with counterparties who may not always be available. While CTV is not necessarily required for this, its implementation would enhance certain aspects and open up new possibilities for unilaterally opening these contracts. The conversation also touched upon the workings of unilateral options, involving the creation of a payment to the counterparty into an Option expiring next week, granting them the right to purchase a magnesium risk reversal contract from the sender, with settlement scheduled for the following month. The participants concluded by discussing how this pattern must be used in conjunction with DCFMP and PowSwap, where miners could commit to "trade specs," and an automatic market maker inside the DCFMP could attempt to match the miner with a counterparty seeking the opposite hashrate hedge.The message also mentions developer Jeremy Rubin's recent post about building options and derivatives on the Sapio platform. Further details and insights can be found in the full post, accessible at rubin.io/bitcoin/2021/12/20/advent-23. The brief message sharing this information was shared via Twitter. 2021-12-27T12:05:36+00:00 + In a Bitcoin developer mailing list, users discussed the ongoing development of the p2pderivatives DLC application. Yancy shared that the project is still under active development and provided a GitHub link to the project. Prayank mentioned the use of discreet log contracts for multi oracles and linked the p2pderivatives-client, p2pderivatives-server, and p2pderivatives-oracle GitHub repositories. The discussion also touched on the potential benefits of implementing OP_CTV in the project and explored the concept of unilateral derivatives. Thibaut introduced rust-dlc as another actively developed project that supports multi oracle contracts and other features found in the DLC specifications. They invited Jeremy to join their monthly DLC spec meeting to discuss how CTV could enhance the Bitcoin derivatives ecosystem and what aspects could be reused from DLCs. This conversation highlights the ongoing development and exploration of derivatives within the Bitcoin community.In an email exchange between Yancy and Prayank, it was revealed that the p2pderivatives DLC application is still being developed on GitHub using a single oracle. Yancy shared links to the repository for the client, server, and oracle components of the project. Prayank further discussed the use of multi-oracles in discreet log contracts and referenced the p2pderivatives project. The necessity of OP_CTV in the p2pderivatives project was questioned, to which Yancy responded that while not necessary, certain aspects of the project could benefit from its implementation. The conversation also delved into the concept of unilateral derivatives and how they could function even without a peer to take the other side of the trade. Both participants expressed interest in exploring derivatives as a lesser-explored area of Bitcoin projects that could potentially address various problems. Links to powswap.com and the bitcoin-dev mailing list were shared during the conversation.Prayank and Jeremy engaged in an email conversation discussing the implementation of threshold oracles in Bitcoin and their potential application in derivatives trading. They mentioned a project called P2P Derivatives that employs a similar approach but has not been used for real trades on the mainnet or further developed. The discussion then shifted to the advantages of unilateral opens, which enable one party to make payments into a derivative without requiring the counterparty to be online. This feature is particularly useful when dealing with counterparties who may not always be available. While CTV is not necessarily required for this, its implementation would enhance certain aspects and open up new possibilities for unilaterally opening these contracts. The conversation also touched upon the workings of unilateral options, involving the creation of a payment to the counterparty into an Option expiring next week, granting them the right to purchase a magnesium risk reversal contract from the sender, with settlement scheduled for the following month. The participants concluded by discussing how this pattern must be used in conjunction with DCFMP and PowSwap, where miners could commit to "trade specs," and an automatic market maker inside the DCFMP could attempt to match the miner with a counterparty seeking the opposite hashrate hedge.The message also mentions developer Jeremy Rubin's recent post about building options and derivatives on the Sapio platform. Further details and insights can be found in the full post, accessible at rubin.io/bitcoin/2021/12/20/advent-23. The brief message sharing this information was shared via Twitter. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Oracles-Bonds-and-Attestation-Chains.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Oracles-Bonds-and-Attestation-Chains.xml index 36975fe815..205a596359 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Oracles-Bonds-and-Attestation-Chains.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Oracles-Bonds-and-Attestation-Chains.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains - 2023-08-02T05:15:37.006176+00:00 - - ZmnSCPxj 2021-12-18 03:49:15+00:00 - - - Jeremy 2021-12-18 02:00:32+00:00 - - - ZmnSCPxj 2021-12-18 01:00:14+00:00 - - - Jeremy 2021-12-17 18:24:01+00:00 - + 2025-09-26T15:31:00.744673+00:00 + python-feedgen + + + [bitcoin-dev] [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains Jeremy + 2021-12-17T18:24:00.000Z + + + ZmnSCPxj + 2021-12-18T01:00:00.000Z + + + Jeremy + 2021-12-18T02:00:00.000Z + + + ZmnSCPxj + 2021-12-18T03:49:00.000Z + + - python-feedgen + 2 Combined summary - [Bitcoin Advent Calendar] Oracles, Bonds, and Attestation Chains - 2023-08-02T05:15:37.006176+00:00 + 2025-09-26T15:31:00.745267+00:00 - In an email exchange, ZmnSCPxj discusses the use of musig keys for staking in a blockchain network. He explains that users can sign with different keys until they equivocate once, after which they must switch to the other keys. This mechanism allows for correcting signing mistakes. However, if a staker equivocates three times, they are disqualified. ZmnSCPxj also proposes a way to incentivize stakers to sign the "correct" statement in line with their peers. Only stakers who sign with the majority receive reward tokens for that slot. This creates an incentive for stakers to try to sign the correct statement, but it also means that stakers who equivocate to switch and get tokens would burn their collateral.The context explores the issue of punishing stakeholders for signing the wrong thing and making changes without risking funds. The author points out that a single equivocation can lead to unbounded equivocation by third parties, allowing for the complete rewriting of the signature chain. Additionally, the use of a musig key for staking means that if an individual equivocates three times, they are disqualified. The author is unsure about the practical implementation of this approach. While lying cannot be punished, stakers who sign with the majority receive reward tokens; however, stakers who equivocate to switch and obtain tokens would burn their collateral. This creates an incentive for stakers to try to sign the correct statement in line with their peers.ZmnSCPxj shares a post discussing how covenants like CTV can address the timeout/rollover issue and collusion issues on punishment in on-chain bitcoin signing oracles. The post also mentions a protocol that enables the creation of "branch-free" attestation chains where equivocation results in burned funds. Robin Linus has written a whitepaper providing further details on these concepts, which is linked in the post. The post emphasizes that bonds are more effective when the bonder cannot recover their funds, and with a covenant, the bonder can definitely lose funds. While an oracle can still lie, it must consistently lie and avoid equivocation. If an oracle signs an invalid sidechain block, it can still do so, but it is prevented from later denying this by signing an alternative valid sidechain block. If the oracle sticks to its initial decision, the sidechain ceases operation, resulting in the loss of funds for sidecoin holders while the bond remains secure.The post provides insights into how covenants like CTV can enhance on-chain bitcoin signing oracles by resolving the timeout/rollover issue and addressing collusion problems on punishment. The author also mentions a protocol that facilitates the creation of "branch-free" attestation chains where equivocation leads to burned funds. Furthermore, the post briefly touches on various applications of these chained attestations. To delve deeper into these concepts, the author includes a link to Robin Linus's whitepaper. 2021-12-18T03:49:15+00:00 + In an email exchange, ZmnSCPxj discusses the use of musig keys for staking in a blockchain network. He explains that users can sign with different keys until they equivocate once, after which they must switch to the other keys. This mechanism allows for correcting signing mistakes. However, if a staker equivocates three times, they are disqualified. ZmnSCPxj also proposes a way to incentivize stakers to sign the "correct" statement in line with their peers. Only stakers who sign with the majority receive reward tokens for that slot. This creates an incentive for stakers to try to sign the correct statement, but it also means that stakers who equivocate to switch and get tokens would burn their collateral.The context explores the issue of punishing stakeholders for signing the wrong thing and making changes without risking funds. The author points out that a single equivocation can lead to unbounded equivocation by third parties, allowing for the complete rewriting of the signature chain. Additionally, the use of a musig key for staking means that if an individual equivocates three times, they are disqualified. The author is unsure about the practical implementation of this approach. While lying cannot be punished, stakers who sign with the majority receive reward tokens; however, stakers who equivocate to switch and obtain tokens would burn their collateral. This creates an incentive for stakers to try to sign the correct statement in line with their peers.ZmnSCPxj shares a post discussing how covenants like CTV can address the timeout/rollover issue and collusion issues on punishment in on-chain bitcoin signing oracles. The post also mentions a protocol that enables the creation of "branch-free" attestation chains where equivocation results in burned funds. Robin Linus has written a whitepaper providing further details on these concepts, which is linked in the post. The post emphasizes that bonds are more effective when the bonder cannot recover their funds, and with a covenant, the bonder can definitely lose funds. While an oracle can still lie, it must consistently lie and avoid equivocation. If an oracle signs an invalid sidechain block, it can still do so, but it is prevented from later denying this by signing an alternative valid sidechain block. If the oracle sticks to its initial decision, the sidechain ceases operation, resulting in the loss of funds for sidecoin holders while the bond remains secure.The post provides insights into how covenants like CTV can enhance on-chain bitcoin signing oracles by resolving the timeout/rollover issue and addressing collusion problems on punishment. The author also mentions a protocol that facilitates the creation of "branch-free" attestation chains where equivocation leads to burned funds. Furthermore, the post briefly touches on various applications of these chained attestations. To delve deeper into these concepts, the author includes a link to Robin Linus's whitepaper. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Review-of-Smart-Contract-Concepts.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Review-of-Smart-Contract-Concepts.xml index 3f522057e6..f8d508ddd6 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Review-of-Smart-Contract-Concepts.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Review-of-Smart-Contract-Concepts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [Bitcoin Advent Calendar] Review of Smart Contract Concepts - 2023-08-02T05:12:42.151272+00:00 + 2025-09-26T15:31:19.620376+00:00 + python-feedgen Prayank 2021-12-23 11:55:31+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [Bitcoin Advent Calendar] Review of Smart Contract Concepts - 2023-08-02T05:12:42.151272+00:00 + 2025-09-26T15:31:19.620581+00:00 - The blog post by Jeremy Rubin explores various high-level smart contract concepts related to different opcodes or proposals. The author begins by discussing the concept of recursion in programming, also known as "Turing Complete". To help remember this concept, the author references an Indian movie titled 'Karthik calling Karthik'. Moving on, the limitations of unrolling loops are addressed, particularly when choices are introduced, leading to exponential blowup. However, the author notes that clever and careful programmers can mitigate this complexity through memoization. The author agrees with these limitations and acknowledges the possibility of optimization.The conversation then delves into the distinction between fully enumerated and open-ended contract cases. In the latter, dynamic specification of bits and pieces is permitted. An intriguing example is provided where Alice is paid 1 BTC by December 25th, 2021 Midnight, and subsequently transfers 100 tokens to one of Bob's addresses at his discretion.Towards the end of the blog post, the author shares a newfound knowledge about signing the transaction fee rate as a function of locktime. This adds another layer of understanding to the subject matter.Overall, the blog post by Jeremy Rubin covers a range of smart contract concepts, discussing recursion, limitations of unrolling loops, open-ended contract cases, and transaction fee rate signing. The author encourages readers to share their thoughts on other relevant properties. The post was published on December 4, 2021, and is accessible on rubin.io. 2021-12-23T11:55:31+00:00 + The blog post by Jeremy Rubin explores various high-level smart contract concepts related to different opcodes or proposals. The author begins by discussing the concept of recursion in programming, also known as "Turing Complete". To help remember this concept, the author references an Indian movie titled 'Karthik calling Karthik'. Moving on, the limitations of unrolling loops are addressed, particularly when choices are introduced, leading to exponential blowup. However, the author notes that clever and careful programmers can mitigate this complexity through memoization. The author agrees with these limitations and acknowledges the possibility of optimization.The conversation then delves into the distinction between fully enumerated and open-ended contract cases. In the latter, dynamic specification of bits and pieces is permitted. An intriguing example is provided where Alice is paid 1 BTC by December 25th, 2021 Midnight, and subsequently transfers 100 tokens to one of Bob's addresses at his discretion.Towards the end of the blog post, the author shares a newfound knowledge about signing the transaction fee rate as a function of locktime. This adds another layer of understanding to the subject matter.Overall, the blog post by Jeremy Rubin covers a range of smart contract concepts, discussing recursion, limitations of unrolling loops, open-ended contract cases, and transaction fee rate signing. The author encourages readers to share their thoughts on other relevant properties. The post was published on December 4, 2021, and is accessible on rubin.io. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-What-s-Smart-about-Smart-Contracts.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-What-s-Smart-about-Smart-Contracts.xml index 7e1b253cb7..0969ddc3ee 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-What-s-Smart-about-Smart-Contracts.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-What-s-Smart-about-Smart-Contracts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [Bitcoin Advent Calendar] What's Smart about Smart Contracts - 2023-08-02T05:12:32.377523+00:00 + 2025-09-26T15:31:15.417854+00:00 + python-feedgen Prayank 2021-12-23 09:42:02+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - [Bitcoin Advent Calendar] What's Smart about Smart Contracts - 2023-08-02T05:12:32.377523+00:00 + 2025-09-26T15:31:15.418020+00:00 - In his day 6 post, Bitcoin developer Jeremy Rubin emphasizes the importance of smart contracts as a critical precursor to securing Bitcoin's future. He addresses several differences between Bitcoin and Ethereum that impact the fee market, including block size, block limit, UTXO vs account model, failed transactions, and the need for nodes to run smart contracts. Rubin also highlights that various platforms, such as stablecoins, DEX, NFT platforms, CEX, and VCs, are all paying fees.He further discusses other factors influencing the fee market, such as darknet markets using Monero, stablecoins no longer using Omni, and the majority of transactions being related to exchanges. Additionally, he notes that new users are primarily interested in quick riches rather than technologies like DeFi that could enhance the Bitcoin ecosystem. Rubin also mentions that projects like DLCs have not yet been implemented in high-volume projects.The article explores the concept of "smart" contracts, which enforce themselves without requiring a third party. The author proposes a redesign in Bitcoin terms to include a "default branch" that automatically executes when the future block height arrives. However, the author cautions that any changes to the programming model can introduce bugs that may undermine the "smartness" of the contracts. The N-of-N rule is discussed, highlighting the challenges of decentralized coordination-free mining pools when all participants must be online. Ultimately, the article emphasizes the need to improve the hardware supporting Bitcoin to enhance its ability to facilitate value transfers.Responding to ZmnSCPxj's critique, Rubin clarifies that his discussion revolves around the community's definition of smart contracts, focusing on enhanced functionality rather than true self-enforcement. He suggests pursuing improvements in the hardware running Bitcoin to strengthen its ability to adjudicate transfers of value. Rubin also touches upon the N-of-N rule, cautioning against its exclusive use due to potential obstacles for decentralized mining pools. Instead, he advocates for enhancing Bitcoin's scalability, privacy, self-custody, and decentralization to solidify its adjudication of value transfers.In his one-a-day blog post series until Christmas, Rubin shares his insights on Bitcoin development. He acknowledges that the initial posts are more philosophical but recommends readers start from Day 6 for relevant Bitcoin development discussions. Rubin plans to post the remaining entries up to Day 10 on the platform, providing an archive of all posts at https://rubin.io/archive/. The day 6 post specifically delves into the significance of smart contracts as a crucial element in securing Bitcoin's future, rather than an afterthought following base layer improvements. 2021-12-23T09:42:02+00:00 + In his day 6 post, Bitcoin developer Jeremy Rubin emphasizes the importance of smart contracts as a critical precursor to securing Bitcoin's future. He addresses several differences between Bitcoin and Ethereum that impact the fee market, including block size, block limit, UTXO vs account model, failed transactions, and the need for nodes to run smart contracts. Rubin also highlights that various platforms, such as stablecoins, DEX, NFT platforms, CEX, and VCs, are all paying fees.He further discusses other factors influencing the fee market, such as darknet markets using Monero, stablecoins no longer using Omni, and the majority of transactions being related to exchanges. Additionally, he notes that new users are primarily interested in quick riches rather than technologies like DeFi that could enhance the Bitcoin ecosystem. Rubin also mentions that projects like DLCs have not yet been implemented in high-volume projects.The article explores the concept of "smart" contracts, which enforce themselves without requiring a third party. The author proposes a redesign in Bitcoin terms to include a "default branch" that automatically executes when the future block height arrives. However, the author cautions that any changes to the programming model can introduce bugs that may undermine the "smartness" of the contracts. The N-of-N rule is discussed, highlighting the challenges of decentralized coordination-free mining pools when all participants must be online. Ultimately, the article emphasizes the need to improve the hardware supporting Bitcoin to enhance its ability to facilitate value transfers.Responding to ZmnSCPxj's critique, Rubin clarifies that his discussion revolves around the community's definition of smart contracts, focusing on enhanced functionality rather than true self-enforcement. He suggests pursuing improvements in the hardware running Bitcoin to strengthen its ability to adjudicate transfers of value. Rubin also touches upon the N-of-N rule, cautioning against its exclusive use due to potential obstacles for decentralized mining pools. Instead, he advocates for enhancing Bitcoin's scalability, privacy, self-custody, and decentralization to solidify its adjudication of value transfers.In his one-a-day blog post series until Christmas, Rubin shares his insights on Bitcoin development. He acknowledges that the initial posts are more philosophical but recommends readers start from Day 6 for relevant Bitcoin development discussions. Rubin plans to post the remaining entries up to Day 10 on the platform, providing an archive of all posts at https://rubin.io/archive/. The day 6 post specifically delves into the significance of smart contracts as a crucial element in securing Bitcoin's future, rather than an afterthought following base layer improvements. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_A-fee-bumping-model.xml b/static/bitcoin-dev/Dec_2021/combined_A-fee-bumping-model.xml index 75d96dfe19..47a84174a6 100644 --- a/static/bitcoin-dev/Dec_2021/combined_A-fee-bumping-model.xml +++ b/static/bitcoin-dev/Dec_2021/combined_A-fee-bumping-model.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A fee-bumping model - 2023-08-02T05:10:48.545853+00:00 + 2025-09-26T15:31:09.126709+00:00 + python-feedgen Peter Todd 2021-12-09 13:50:33+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - A fee-bumping model - 2023-08-02T05:10:48.545853+00:00 + 2025-09-26T15:31:09.126864+00:00 - emails discussing the topic. It also mentions the idea of creating an insurance project for the LGBTQ community in India and shares a presentation by Jack Mallers on creating derivatives to hedge fees.In summary, the discussions and articles revolve around the importance of fee-bumping strategies for the security and efficiency of protocols built on Bitcoin. The challenges of fee estimation, confirmation of transactions, and overpayments are addressed, along with proposed solutions such as presigned transactions, reserve feerates, and consolidation with fanout. The need for accurate fee estimation, policy-level mitigations, new consensus rules, and potential insurance markets are emphasized throughout the conversations and articles. 2021-12-09T13:50:33+00:00 + emails discussing the topic. It also mentions the idea of creating an insurance project for the LGBTQ community in India and shares a presentation by Jack Mallers on creating derivatives to hedge fees.In summary, the discussions and articles revolve around the importance of fee-bumping strategies for the security and efficiency of protocols built on Bitcoin. The challenges of fee estimation, confirmation of transactions, and overpayments are addressed, along with proposed solutions such as presigned transactions, reserve feerates, and consolidation with fanout. The need for accurate fee estimation, policy-level mitigations, new consensus rules, and potential insurance markets are emphasized throughout the conversations and articles. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_BIP-119-Deployment-and-Review-Workshops.xml b/static/bitcoin-dev/Dec_2021/combined_BIP-119-Deployment-and-Review-Workshops.xml index 10a5b9d4aa..48b810371f 100644 --- a/static/bitcoin-dev/Dec_2021/combined_BIP-119-Deployment-and-Review-Workshops.xml +++ b/static/bitcoin-dev/Dec_2021/combined_BIP-119-Deployment-and-Review-Workshops.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP-119 Deployment and Review Workshops - 2023-08-02T05:16:21.724208+00:00 - - Heritage Samuel Falodun 2021-12-31 16:56:17+00:00 - - - Jeremy 2021-12-30 20:28:48+00:00 - + 2025-09-26T15:31:04.919828+00:00 + python-feedgen + + + [bitcoin-dev] BIP-119 Deployment and Review Workshops Jeremy + 2021-12-30T20:28:00.000Z + + + Heritage Samuel Falodun + 2021-12-31T16:56:00.000Z + + - python-feedgen + 2 Combined summary - BIP-119 Deployment and Review Workshops - 2023-08-02T05:16:21.724208+00:00 + 2025-09-26T15:31:04.920277+00:00 - Jeremy Rubin, a Bitcoin developer, has announced the scheduling of a recurring meeting every two weeks on Tuesdays at 12:00 PM PT starting January 11th. The purpose of these meetings is to discuss BIP-119 review and deployment topics. Participants are invited to send in topics they would like to cover before each meeting for inclusion in the preliminary agenda.The author emphasizes that the meetings will be moderated closely to ensure that the discussions remain on topic while covering all relevant issues. The goal is to coordinate the review, testing, and iron out any wrinkles around release timelines and procedures based on the author's request for comment.It is important to note that participation in these meetings does not signify endorsement of BIP-119's inclusion or any specific roadmap. Instead, the meetings aim to continue the 'gradient descent process' of consensus in an open, interactive, and productive format. The author assures that logs will be available via gnusha.Interested parties are encouraged to drop a private note to Jeremy or reply to his email if they plan to attend the meetings. 2021-12-31T16:56:17+00:00 + Jeremy Rubin, a Bitcoin developer, has announced the scheduling of a recurring meeting every two weeks on Tuesdays at 12:00 PM PT starting January 11th. The purpose of these meetings is to discuss BIP-119 review and deployment topics. Participants are invited to send in topics they would like to cover before each meeting for inclusion in the preliminary agenda.The author emphasizes that the meetings will be moderated closely to ensure that the discussions remain on topic while covering all relevant issues. The goal is to coordinate the review, testing, and iron out any wrinkles around release timelines and procedures based on the author's request for comment.It is important to note that participation in these meetings does not signify endorsement of BIP-119's inclusion or any specific roadmap. Instead, the meetings aim to continue the 'gradient descent process' of consensus in an open, interactive, and productive format. The author assures that logs will be available via gnusha.Interested parties are encouraged to drop a private note to Jeremy or reply to his email if they plan to attend the meetings. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_Covenants-and-capabilities-in-the-UTXO-model.xml b/static/bitcoin-dev/Dec_2021/combined_Covenants-and-capabilities-in-the-UTXO-model.xml index adc81516f5..d2808a141b 100644 --- a/static/bitcoin-dev/Dec_2021/combined_Covenants-and-capabilities-in-the-UTXO-model.xml +++ b/static/bitcoin-dev/Dec_2021/combined_Covenants-and-capabilities-in-the-UTXO-model.xml @@ -1,32 +1,39 @@ - + 2 Combined summary - Covenants and capabilities in the UTXO model - 2023-08-02T05:16:41.582819+00:00 - - Bram Cohen 2022-01-22 00:19:07+00:00 - - - Billy Tetrud 2022-01-21 17:32:27+00:00 - - - Peter Todd 2022-01-21 02:22:15+00:00 - - - Bram Cohen 2022-01-20 19:23:30+00:00 - - - Billy Tetrud 2022-01-19 02:24:47+00:00 - - - Bram Cohen 2022-01-18 17:16:25+00:00 - - - Billy Tetrud 2022-01-18 15:10:33+00:00 - - - Bram Cohen 2021-12-31 23:22:08+00:00 - + 2025-09-26T15:30:58.652977+00:00 + python-feedgen + + + Billy Tetrud + 2022-01-18T15:10:00.000Z + + + Bram Cohen + 2022-01-18T17:16:00.000Z + + + Billy Tetrud + 2022-01-19T02:24:00.000Z + + + Bram Cohen + 2022-01-20T19:23:00.000Z + + + Peter Todd + 2022-01-21T02:22:00.000Z + + + Billy Tetrud + 2022-01-21T17:32:00.000Z + + + Bram Cohen + 2022-01-22T00:19:00.000Z + + @@ -35,13 +42,13 @@ - python-feedgen + 2 Combined summary - Covenants and capabilities in the UTXO model - 2023-08-02T05:16:41.582819+00:00 + 2025-09-26T15:30:58.653910+00:00 - The conversation between Billy Tetrud and an unknown recipient revolves around the concept of a 'parent' in Bitcoin transactions and the optimization of the UXTO model. The recipient expresses concern about transactions becoming invalid due to limitations on how far they can point back, which could cause problems during reorgs. The discussion also touches on the use of capabilities validation tricks and optional mappings of inputs to outputs.The author questions the need to verify the secure hash chain from parent to child in Bitcoin transactions, suggesting that transactions should be defined as invalid unless they match the covenant in the parent. However, this can lead to transactions becoming invalid and create issues during reorgs. There is limited information available on why valid transactions becoming invalid is seen as a problem. Peter Todd points out that allowing references to old blocks could bring in old block data into the UTXO set and cause issues.In another discussion, Bram Cohen raises concerns about a proposal that would require nodes to keep the entire blockchain, potentially causing scalability issues. He mentions that Monero's UTXO set is already the whole blockchain, resulting in problems for pruned nodes. Allowing references to old blocks could lead to similar issues for Bitcoin. It is important to carefully consider proposals before implementation to avoid unintended consequences.Billy Tetrud and an anonymous party discuss the concept of covenants in Bitcoin and the ability to specify spending rules for UTXOs. They mention the lack of a strong single concept for a 'parent' in Bitcoin transactions and the ability for a coin to check its own ID and verify the secure hash chain from parent to child. They also discuss the potential for scalability issues if references to old blocks are allowed.Bram Cohen and Billy Tetrud discuss the implementation of covenants in Bitcoin and suggest adding programmatic capabilities to the language. They mention the complexity of Bitcoin transactions and the need for special-purpose opcodes to make coherent statements. They discuss the potential for deduplicating common script snippets to save bandwidth. They highlight the importance of ensuring recipients fully understand the covenant attached to a payment and the potential scalability issues with allowing references to old blocks.In a recent post on the bitcoin-dev mailing list, Bram Cohen discusses adding covenants and capabilities to the UTXO model. He suggests adding programmatic capabilities to the language and special-purpose opcodes for coherent statements about transactions. He emphasizes the need for recipients to fully understand payment covenants and discusses potential issues with implementing complex functionality. He proposes ways to compress or deduplicate code snippets for better scalability. Cohen's suggestions aim to add covenants and capabilities while making minimal compromises to Bitcoin's current practices.The UTXO model can be modified to include covenants and capabilities by adding programmatic capabilities to the language and using programmatic tricks. However, a clear concept of a single parent in Bitcoin transactions is missing. Implementing complex functionality can be expensive, and deduplicating code snippets is necessary for optimization. The controversy lies in whether covenants and capabilities should be opt-in or opt-out. Recipients must fully understand the implications of covenants, and retroactive veto or clawback actions are unacceptable. Concerns have been raised about potential attacks on the underlying chain if colored coins' value exceeds the tokenized chain. Backwards pointing covenants can be used for more complex functionality. The chialisp.com website offers a detailed implementation of these ideas in a slightly different model. 2022-01-22T00:19:07+00:00 + The conversation between Billy Tetrud and an unknown recipient revolves around the concept of a 'parent' in Bitcoin transactions and the optimization of the UXTO model. The recipient expresses concern about transactions becoming invalid due to limitations on how far they can point back, which could cause problems during reorgs. The discussion also touches on the use of capabilities validation tricks and optional mappings of inputs to outputs.The author questions the need to verify the secure hash chain from parent to child in Bitcoin transactions, suggesting that transactions should be defined as invalid unless they match the covenant in the parent. However, this can lead to transactions becoming invalid and create issues during reorgs. There is limited information available on why valid transactions becoming invalid is seen as a problem. Peter Todd points out that allowing references to old blocks could bring in old block data into the UTXO set and cause issues.In another discussion, Bram Cohen raises concerns about a proposal that would require nodes to keep the entire blockchain, potentially causing scalability issues. He mentions that Monero's UTXO set is already the whole blockchain, resulting in problems for pruned nodes. Allowing references to old blocks could lead to similar issues for Bitcoin. It is important to carefully consider proposals before implementation to avoid unintended consequences.Billy Tetrud and an anonymous party discuss the concept of covenants in Bitcoin and the ability to specify spending rules for UTXOs. They mention the lack of a strong single concept for a 'parent' in Bitcoin transactions and the ability for a coin to check its own ID and verify the secure hash chain from parent to child. They also discuss the potential for scalability issues if references to old blocks are allowed.Bram Cohen and Billy Tetrud discuss the implementation of covenants in Bitcoin and suggest adding programmatic capabilities to the language. They mention the complexity of Bitcoin transactions and the need for special-purpose opcodes to make coherent statements. They discuss the potential for deduplicating common script snippets to save bandwidth. They highlight the importance of ensuring recipients fully understand the covenant attached to a payment and the potential scalability issues with allowing references to old blocks.In a recent post on the bitcoin-dev mailing list, Bram Cohen discusses adding covenants and capabilities to the UTXO model. He suggests adding programmatic capabilities to the language and special-purpose opcodes for coherent statements about transactions. He emphasizes the need for recipients to fully understand payment covenants and discusses potential issues with implementing complex functionality. He proposes ways to compress or deduplicate code snippets for better scalability. Cohen's suggestions aim to add covenants and capabilities while making minimal compromises to Bitcoin's current practices.The UTXO model can be modified to include covenants and capabilities by adding programmatic capabilities to the language and using programmatic tricks. However, a clear concept of a single parent in Bitcoin transactions is missing. Implementing complex functionality can be expensive, and deduplicating code snippets is necessary for optimization. The controversy lies in whether covenants and capabilities should be opt-in or opt-out. Recipients must fully understand the implications of covenants, and retroactive veto or clawback actions are unacceptable. Concerns have been raised about potential attacks on the underlying chain if colored coins' value exceeds the tokenized chain. Backwards pointing covenants can be used for more complex functionality. The chialisp.com website offers a detailed implementation of these ideas in a slightly different model. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_Globally-Broadcasting-Workshares-to-Improve-Finality-Heuristics.xml b/static/bitcoin-dev/Dec_2021/combined_Globally-Broadcasting-Workshares-to-Improve-Finality-Heuristics.xml index 9f5ad4e5fd..4cb95e3a50 100644 --- a/static/bitcoin-dev/Dec_2021/combined_Globally-Broadcasting-Workshares-to-Improve-Finality-Heuristics.xml +++ b/static/bitcoin-dev/Dec_2021/combined_Globally-Broadcasting-Workshares-to-Improve-Finality-Heuristics.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Globally Broadcasting Workshares to Improve Finality Heuristics - 2023-08-02T05:15:43.471908+00:00 - - Rune K. Svendsen 2021-12-18 13:25:08+00:00 - - - Newsletter Catcher 2021-12-18 08:36:07+00:00 - - - Jeremy 2021-12-17 18:53:55+00:00 - + 2025-09-26T15:31:11.213867+00:00 + python-feedgen + + + [bitcoin-dev] Globally Broadcasting Workshares to Improve Finality Heuristics Jeremy + 2021-12-17T18:53:00.000Z + + + Newsletter Catcher + 2021-12-18T08:36:00.000Z + + + Rune K. Svendsen + 2021-12-18T13:25:00.000Z + + - python-feedgen + 2 Combined summary - Globally Broadcasting Workshares to Improve Finality Heuristics - 2023-08-02T05:15:43.471908+00:00 + 2025-09-26T15:31:11.214492+00:00 - During a conversation with Nic Carter, Jeremy Rubin proposed an interesting concept related to Bitcoin Core that could potentially enhance the accuracy of finality estimates and provide warnings in case of hashrate abandonment. The concept involves setting up Bitcoin Core to gossip headers for work shares. By doing so, the system would have the ability to detect missing work, regardless of whether dishonest miners choose to publish their work on non-tip shares. This feature could be utilized to notify users of sudden hashrate decreases, prompting them to wait longer before accepting payments. It is worth noting that this concept, similar to Bobtail, was presented at Scaling Bitcoin a few years ago. The paper linked above provides more information on the concept, although further context is required to fully understand its relation to Jeremy's discussion. Additionally, it remains uncertain whether this concept has been previously discussed on the bitcoin-dev mailing list. 2021-12-18T13:25:08+00:00 + During a conversation with Nic Carter, Jeremy Rubin proposed an interesting concept related to Bitcoin Core that could potentially enhance the accuracy of finality estimates and provide warnings in case of hashrate abandonment. The concept involves setting up Bitcoin Core to gossip headers for work shares. By doing so, the system would have the ability to detect missing work, regardless of whether dishonest miners choose to publish their work on non-tip shares. This feature could be utilized to notify users of sudden hashrate decreases, prompting them to wait longer before accepting payments. It is worth noting that this concept, similar to Bobtail, was presented at Scaling Bitcoin a few years ago. The paper linked above provides more information on the concept, although further context is required to fully understand its relation to Jeremy's discussion. Additionally, it remains uncertain whether this concept has been previously discussed on the bitcoin-dev mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_On-the-regularity-of-soft-forks.xml b/static/bitcoin-dev/Dec_2021/combined_On-the-regularity-of-soft-forks.xml index 5f16bb52e7..5ac9daf374 100644 --- a/static/bitcoin-dev/Dec_2021/combined_On-the-regularity-of-soft-forks.xml +++ b/static/bitcoin-dev/Dec_2021/combined_On-the-regularity-of-soft-forks.xml @@ -1,47 +1,47 @@ - + 2 Combined summary - On the regularity of soft forks - 2023-08-02T04:54:30.049777+00:00 - - Billy Tetrud 2022-01-19 02:26:12+00:00 - - - Prayank 2022-01-18 17:22:05+00:00 - - - Billy Tetrud 2022-01-18 16:00:06+00:00 - - - vjudeu at gazeta.pl 2022-01-01 15:45:11+00:00 - - - Keagan McClelland 2021-12-31 03:10:48+00:00 - - - Michael Folkson 2021-10-16 11:02:08+00:00 - - - micaroni at gmail.com 2021-10-15 00:43:40+00:00 - - - Anthony Towns 2021-10-14 23:52:07+00:00 - - - Jorge Timón 2021-10-12 19:04:02+00:00 - - - ZmnSCPxj 2021-10-11 19:53:39+00:00 - - - Jeremy 2021-10-11 19:12:58+00:00 - - - Prayank 2021-10-11 16:03:16+00:00 - - - Michael Folkson 2021-10-11 12:24:10+00:00 - + 2025-09-26T15:30:52.358688+00:00 + python-feedgen + + + [bitcoin-dev] On the regularity of soft forks Michael Folkson + 2021-10-11T12:24:00.000Z + + + Prayank + 2021-10-11T16:03:00.000Z + + + Jeremy + 2021-10-11T19:12:00.000Z + + + ZmnSCPxj + 2021-10-11T19:53:00.000Z + + + Jorge Timón + 2021-10-12T19:04:00.000Z + + + Anthony Towns + 2021-10-14T23:52:00.000Z + + + micaroni + 2021-10-15T00:43:00.000Z + + + Michael Folkson + 2021-10-16T11:02:00.000Z + + + Keagan McClelland + 2021-12-31T03:10:00.000Z + + @@ -55,13 +55,13 @@ - python-feedgen + 2 Combined summary - On the regularity of soft forks - 2023-08-02T04:54:30.049777+00:00 + 2025-09-26T15:30:52.359827+00:00 - Miner signaling is a tool used to indicate readiness for a soft fork, but it should not be seen as a form of voting or expressing support for the fork. This distinction is crucial in order to avoid confusion and misinterpretation by users. The signaling process for taproot, for example, caused confusion among different communities as many believed that miners were actually voting for taproot. To address this issue, there needs to be sufficient community consensus before enabling miner signaling.Prayank, the author of the article, acknowledges that despite sharing a link to clarify the matter, there are still people who hold the misconception that miners vote during signaling. This confusion is further fueled by the differing opinions of developers on MASF (Miner Activated Soft Fork) versus UASF (User Activated Soft Fork). Finding a solution to this problem is a concern for Prayank.The author argues against frequent soft forks with only a single or minimal set of features, advocating instead for infrequent soft forks that include batches of features. The primary focus should be on ensuring the robustness, security, and resistance to harmful or suboptimal changes within the system. Soft fork code should not be merged into a Bitcoin implementation until there is sufficient community consensus on the entirety of that soft fork.In situations where there is no overwhelming community consensus on the activation method, activation parameters, and what to do if the initial attempt fails, the activation of soft forks carries additional risks. These risks include the potential for bugs, consensus divergences, and flawed implementations of soft fork features. Therefore, infrequent soft forks with batches of features are favored over frequent soft forks with only a single feature.Overall, the article emphasizes the need for clear communication and understanding regarding miner signaling, as well as the importance of community consensus in the implementation of soft forks. It also highlights the benefits of infrequent soft forks with multiple features in order to prioritize the security and stability of the Bitcoin system. 2022-01-19T02:26:12+00:00 + Miner signaling is a tool used to indicate readiness for a soft fork, but it should not be seen as a form of voting or expressing support for the fork. This distinction is crucial in order to avoid confusion and misinterpretation by users. The signaling process for taproot, for example, caused confusion among different communities as many believed that miners were actually voting for taproot. To address this issue, there needs to be sufficient community consensus before enabling miner signaling.Prayank, the author of the article, acknowledges that despite sharing a link to clarify the matter, there are still people who hold the misconception that miners vote during signaling. This confusion is further fueled by the differing opinions of developers on MASF (Miner Activated Soft Fork) versus UASF (User Activated Soft Fork). Finding a solution to this problem is a concern for Prayank.The author argues against frequent soft forks with only a single or minimal set of features, advocating instead for infrequent soft forks that include batches of features. The primary focus should be on ensuring the robustness, security, and resistance to harmful or suboptimal changes within the system. Soft fork code should not be merged into a Bitcoin implementation until there is sufficient community consensus on the entirety of that soft fork.In situations where there is no overwhelming community consensus on the activation method, activation parameters, and what to do if the initial attempt fails, the activation of soft forks carries additional risks. These risks include the potential for bugs, consensus divergences, and flawed implementations of soft fork features. Therefore, infrequent soft forks with batches of features are favored over frequent soft forks with only a single feature.Overall, the article emphasizes the need for clear communication and understanding regarding miner signaling, as well as the importance of community consensus in the implementation of soft forks. It also highlights the benefits of infrequent soft forks with multiple features in order to prioritize the security and stability of the Bitcoin system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_Pawn-chess-piece-Breaking-bitcoin-by-playing-chess.xml b/static/bitcoin-dev/Dec_2021/combined_Pawn-chess-piece-Breaking-bitcoin-by-playing-chess.xml index 893154f37a..d624bedbd2 100644 --- a/static/bitcoin-dev/Dec_2021/combined_Pawn-chess-piece-Breaking-bitcoin-by-playing-chess.xml +++ b/static/bitcoin-dev/Dec_2021/combined_Pawn-chess-piece-Breaking-bitcoin-by-playing-chess.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Pawn (chess piece) | Breaking bitcoin by playing chess - 2023-08-02T05:11:49.573743+00:00 - - Prayank 2021-12-04 15:28:32+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-12-04 10:00:13+00:00 - - - Prayank 2021-12-04 04:36:02+00:00 - + 2025-09-26T15:31:02.834231+00:00 + python-feedgen + + + [bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess Prayank + 2021-12-04T04:36:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-12-04T10:00:00.000Z + + + Prayank + 2021-12-04T15:28:00.000Z + + - python-feedgen + 2 Combined summary - Pawn (chess piece) | Breaking bitcoin by playing chess - 2023-08-02T05:11:49.573743+00:00 + 2025-09-26T15:31:02.834867+00:00 - The email thread discusses the use of Bitcoin transactions for playing chess and its potential impact on increasing demand for block space. The original sender is seeking approval or permission for certain types of Bitcoin transactions, such as opening and closing Lightning Network channels or using OP_RETURN. The response states that as long as a transaction is valid, standard, and pays fees, there should be no issues with the desired transaction. However, it is noted that frivolous use of block space is not encouraged.The sender shares a link to a GitHub page outlining their project to play chess on the Lightning Network. They mention two related projects, Koala Studio and Etleneum, which have previously attempted chess on LN but have either shut down or work differently. As a result, the current project may have to explore other two-player games that can be played over several hours or days and are compatible with the setup. The primary goal of the project remains testing Bitcoin transactions while having fun and contributing to increasing demand for block space.It is clarified that zero fee transactions no longer work, and all transactions will need to pay the required fees in the long term. The email also mentions the use of OP_RETURN by many projects, which is excluded from the UTXO set. The email is signed by Lord His Excellency James HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire and Mr. Damian A. James Williamson from Willtech, go-overt.com, duigco.org DUIGCO API, and other projects. Contact information for Willtech, including a phone number and fax number, is provided. The email notes that it does not constitute general advice and should be disregarded if misdelivered. In conclusion, Prayank23, the sender of the email, clarifies that they will not be actively working on this project as they are currently occupied with another project and have recently started contributing to Wasabi. 2021-12-04T15:28:32+00:00 + The email thread discusses the use of Bitcoin transactions for playing chess and its potential impact on increasing demand for block space. The original sender is seeking approval or permission for certain types of Bitcoin transactions, such as opening and closing Lightning Network channels or using OP_RETURN. The response states that as long as a transaction is valid, standard, and pays fees, there should be no issues with the desired transaction. However, it is noted that frivolous use of block space is not encouraged.The sender shares a link to a GitHub page outlining their project to play chess on the Lightning Network. They mention two related projects, Koala Studio and Etleneum, which have previously attempted chess on LN but have either shut down or work differently. As a result, the current project may have to explore other two-player games that can be played over several hours or days and are compatible with the setup. The primary goal of the project remains testing Bitcoin transactions while having fun and contributing to increasing demand for block space.It is clarified that zero fee transactions no longer work, and all transactions will need to pay the required fees in the long term. The email also mentions the use of OP_RETURN by many projects, which is excluded from the UTXO set. The email is signed by Lord His Excellency James HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire and Mr. Damian A. James Williamson from Willtech, go-overt.com, duigco.org DUIGCO API, and other projects. Contact information for Willtech, including a phone number and fax number, is provided. The email notes that it does not constitute general advice and should be disregarded if misdelivered. In conclusion, Prayank23, the sender of the email, clarifies that they will not be actively working on this project as they are currently occupied with another project and have recently started contributing to Wasabi. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml b/static/bitcoin-dev/Dec_2021/combined_Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml index ae2b5c66d8..ed44f238ee 100644 --- a/static/bitcoin-dev/Dec_2021/combined_Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml +++ b/static/bitcoin-dev/Dec_2021/combined_Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Proposal: Full-RBF in Bitcoin Core 24.0 - 2023-08-02T04:01:48.545744+00:00 - - damian at willtech.com.au 2021-12-20 02:30:57+00:00 - - - Antoine Riard 2021-12-19 18:55:01+00:00 - - - Peter Todd 2021-12-18 17:52:07+00:00 - - - Jeremy 2021-12-18 16:51:46+00:00 - - - Billy Tetrud 2021-06-30 19:21:29+00:00 - - - Corey Haddad 2021-06-30 14:06:50+00:00 - - - Jeremy 2021-06-26 19:00:02+00:00 - - - Billy Tetrud 2021-06-26 16:13:23+00:00 - - - Antoine Riard 2021-06-25 00:23:01+00:00 - - - Greg Sanders 2021-06-17 22:28:45+00:00 - - - Billy Tetrud 2021-06-17 00:58:22+00:00 - - - Antoine Riard 2021-06-15 16:55:14+00:00 - + 2025-09-26T15:30:54.475801+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0 Antoine Riard + 2021-06-15T16:55:00.000Z + + + Billy Tetrud + 2021-06-17T00:58:00.000Z + + + Greg Sanders + 2021-06-17T22:28:00.000Z + + + Antoine Riard + 2021-06-25T00:23:00.000Z + + + Billy Tetrud + 2021-06-26T16:13:00.000Z + + + Jeremy + 2021-06-26T19:00:00.000Z + + + Corey Haddad + 2021-06-30T14:06:00.000Z + + + Billy Tetrud + 2021-06-30T19:21:00.000Z + + + Jeremy + 2021-12-18T16:51:00.000Z + + + Peter Todd + 2021-12-18T17:52:00.000Z + + + Antoine Riard + 2021-12-19T18:55:00.000Z + + + damian + 2021-12-20T02:30:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Proposal: Full-RBF in Bitcoin Core 24.0 - 2023-08-02T04:01:48.545744+00:00 + 2025-09-26T15:30:54.477301+00:00 - The Bitcoin community is currently engaged in a discussion about the future of 0-conf transactions and how to address the associated security risks. One proposal that has been put forward is to deprecate opt-in Replace-by-Fee (RBF) and replace it with full-RBF as the default replacement policy in Bitcoin Core version 24.0. The rationale behind this proposal is to mitigate the risk of denial-of-service (DoS) attacks on multi-party funded transactions enabled by RBF opt-out. These attacks can occur when a malicious counterparty broadcasts a low-feerate, opt-out spending of its own collateral input before engaging in cooperative funding, leading to a DoS situation.Another concern is the risk of mempool malicious partitions, where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets. Opt-in RBF serves as a low-cost partitioning tool, which nullifies most potential progress to mitigate such malicious partitioning. To address these issues, it has been suggested to gradually transition away from full-RBF by enforcing non-replaceability n seconds after the first seen transaction. The goal is to reduce the ability to partition mempools by broadcasting irreplaceable conflicts all at once.In terms of enhancing the security of 0-conf transactions, proactive and reactive security models have been proposed. Proactive models include double-spend monitoring and receiver-side fee-topping with package relay, while reactive models involve economic reputation-based compensations. These approaches aim to detect and respond to successful double-spend attempts and ensure the integrity of 0-conf transactions.The discussion also highlights the need to balance the interests of existing 0-conf users and the development of Layer 2 solutions. While some argue for the preservation of 0-conf transactions, others believe that enabling upcoming interests of fancy Layer 2 solutions is crucial. The decision to switch to full-RBF may be deferred to future updates if it is deemed too early.The proposal to deprecate opt-in Replace-by-Fee (RBF) in favor of full-RBF as the default replacement policy in Bitcoin Core version 24.0 has been put forward by Antoine Riard. This proposal is motivated by ongoing and anticipated changes in the Bitcoin ecosystem. One issue with opt-in RBF is that it doesn't suit the deployment of robust second-layer protocols, and opt-out RBF can be used as a Denial-of-Service (DoS) vector against multi-party funded transactions and mempool partitions.There are questions about whether the community wants to support 0-conf payments at this point, given that there are better mechanisms for fast payments such as Lightning. While few service providers are offering zero-conf channels, where you can start to spend instantly, the security model of 0-conf is far weaker than other payment models. However, there are some Bitcoin services well-known to rely on 0-conf, but beyond how much of the Bitcoin traffic is tied to 0-conf is a hard question. Furthermore, it's not clear how software generally informs the user about 0-conf payment detection, though typically, it's something like an "Unconfirmed" annotation on incoming transactions.To enhance 0-conf security, double-spend monitoring/receiver-side fee-topping with package relay and economic reputation-based compensations are some approaches that could be considered. Overall, the proposal highlights the fact that a transaction relay/mempool acceptance policy might be beneficial to some class of already-deployed Bitcoin applications while being detrimental to newer ones. It is essential to preserve the current interests of 0-conf users while enabling upcoming interests of fancy Layer 2 solutions to flourish. If there is agreement on switching to full-RBF, but 0.24 sounds too early, it can be deferred to 0.25 or 0.26.The bitcoin-dev mailing list has been discussing the adoption of RBF as a standard treatment for all transactions, rather than an opt-in/out feature. Some members believe that opting out of RBF is a weak defense and could lead to theft events. However, there are concerns that eliminating opt-in RBF could affect users who rely on 0-conf payments, which are based on far weaker assumptions. The use of 0-conf payments is still unclear, and it is uncertain how often they are used in the Bitcoin ecosystem at this point.One issue with opt-out RBF is that it allows attackers to perform DoS attacks against multi-party funded transactions by propagating an RBF opt-out double-spend of its contributed input before the honest transaction is broadcasted by the protocol orchestra. This can waste the time value of the victim's inputs or force exhaustion of the fee-bumping reserve. Another problem with opt-out RBF is the risk of mempool malicious partitions where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets.To enhance 0-conf security, reactive security models such as economic reputation-based compens 2021-12-20T02:30:57+00:00 + The Bitcoin community is currently engaged in a discussion about the future of 0-conf transactions and how to address the associated security risks. One proposal that has been put forward is to deprecate opt-in Replace-by-Fee (RBF) and replace it with full-RBF as the default replacement policy in Bitcoin Core version 24.0. The rationale behind this proposal is to mitigate the risk of denial-of-service (DoS) attacks on multi-party funded transactions enabled by RBF opt-out. These attacks can occur when a malicious counterparty broadcasts a low-feerate, opt-out spending of its own collateral input before engaging in cooperative funding, leading to a DoS situation.Another concern is the risk of mempool malicious partitions, where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets. Opt-in RBF serves as a low-cost partitioning tool, which nullifies most potential progress to mitigate such malicious partitioning. To address these issues, it has been suggested to gradually transition away from full-RBF by enforcing non-replaceability n seconds after the first seen transaction. The goal is to reduce the ability to partition mempools by broadcasting irreplaceable conflicts all at once.In terms of enhancing the security of 0-conf transactions, proactive and reactive security models have been proposed. Proactive models include double-spend monitoring and receiver-side fee-topping with package relay, while reactive models involve economic reputation-based compensations. These approaches aim to detect and respond to successful double-spend attempts and ensure the integrity of 0-conf transactions.The discussion also highlights the need to balance the interests of existing 0-conf users and the development of Layer 2 solutions. While some argue for the preservation of 0-conf transactions, others believe that enabling upcoming interests of fancy Layer 2 solutions is crucial. The decision to switch to full-RBF may be deferred to future updates if it is deemed too early.The proposal to deprecate opt-in Replace-by-Fee (RBF) in favor of full-RBF as the default replacement policy in Bitcoin Core version 24.0 has been put forward by Antoine Riard. This proposal is motivated by ongoing and anticipated changes in the Bitcoin ecosystem. One issue with opt-in RBF is that it doesn't suit the deployment of robust second-layer protocols, and opt-out RBF can be used as a Denial-of-Service (DoS) vector against multi-party funded transactions and mempool partitions.There are questions about whether the community wants to support 0-conf payments at this point, given that there are better mechanisms for fast payments such as Lightning. While few service providers are offering zero-conf channels, where you can start to spend instantly, the security model of 0-conf is far weaker than other payment models. However, there are some Bitcoin services well-known to rely on 0-conf, but beyond how much of the Bitcoin traffic is tied to 0-conf is a hard question. Furthermore, it's not clear how software generally informs the user about 0-conf payment detection, though typically, it's something like an "Unconfirmed" annotation on incoming transactions.To enhance 0-conf security, double-spend monitoring/receiver-side fee-topping with package relay and economic reputation-based compensations are some approaches that could be considered. Overall, the proposal highlights the fact that a transaction relay/mempool acceptance policy might be beneficial to some class of already-deployed Bitcoin applications while being detrimental to newer ones. It is essential to preserve the current interests of 0-conf users while enabling upcoming interests of fancy Layer 2 solutions to flourish. If there is agreement on switching to full-RBF, but 0.24 sounds too early, it can be deferred to 0.25 or 0.26.The bitcoin-dev mailing list has been discussing the adoption of RBF as a standard treatment for all transactions, rather than an opt-in/out feature. Some members believe that opting out of RBF is a weak defense and could lead to theft events. However, there are concerns that eliminating opt-in RBF could affect users who rely on 0-conf payments, which are based on far weaker assumptions. The use of 0-conf payments is still unclear, and it is uncertain how often they are used in the Bitcoin ecosystem at this point.One issue with opt-out RBF is that it allows attackers to perform DoS attacks against multi-party funded transactions by propagating an RBF opt-out double-spend of its contributed input before the honest transaction is broadcasted by the protocol orchestra. This can waste the time value of the victim's inputs or force exhaustion of the fee-bumping reserve. Another problem with opt-out RBF is the risk of mempool malicious partitions where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets.To enhance 0-conf security, reactive security models such as economic reputation-based compens - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_Rebroadcast-mechanism-in-Bitcoin-P2P-network.xml b/static/bitcoin-dev/Dec_2021/combined_Rebroadcast-mechanism-in-Bitcoin-P2P-network.xml index 2e77def6f0..3f54487833 100644 --- a/static/bitcoin-dev/Dec_2021/combined_Rebroadcast-mechanism-in-Bitcoin-P2P-network.xml +++ b/static/bitcoin-dev/Dec_2021/combined_Rebroadcast-mechanism-in-Bitcoin-P2P-network.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Rebroadcast mechanism in Bitcoin P2P network - 2023-08-02T05:13:27.088673+00:00 - - Aymeric Vitte 2021-12-13 12:40:51+00:00 - - - damian at willtech.com.au 2021-12-12 22:32:21+00:00 - - - Prayank 2021-12-12 18:49:37+00:00 - - - Pieter Wuille 2021-12-12 15:15:16+00:00 - - - Aymeric Vitte 2021-12-12 14:23:44+00:00 - - - Karl 2021-12-12 13:38:18+00:00 - - - Aymeric Vitte 2021-12-12 11:48:18+00:00 - - - Pieter Wuille 2021-12-11 16:21:21+00:00 - - - damian at willtech.com.au 2021-12-11 03:49:55+00:00 - - - Prayank 2021-12-10 15:13:02+00:00 - + 2025-09-26T15:31:23.833106+00:00 + python-feedgen + + + [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network Prayank + 2021-12-10T15:13:00.000Z + + + damian + 2021-12-11T03:49:00.000Z + + + Pieter Wuille + 2021-12-11T16:21:00.000Z + + + Aymeric Vitte + 2021-12-12T11:48:00.000Z + + + Karl + 2021-12-12T13:38:00.000Z + + + Aymeric Vitte + 2021-12-12T14:23:00.000Z + + + Pieter Wuille + 2021-12-12T15:15:00.000Z + + + Prayank + 2021-12-12T18:49:00.000Z + + + damian + 2021-12-12T22:32:00.000Z + + + Aymeric Vitte + 2021-12-13T12:40:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Rebroadcast mechanism in Bitcoin P2P network - 2023-08-02T05:13:27.088673+00:00 + 2025-09-26T15:31:23.834399+00:00 - The context discusses the use of Tor for Bitcoin traffic and its limitations in addressing privacy concerns. It suggests using Tor differently with node-Tor and hybrid nodes to mitigate these issues. The author emphasizes the importance of privacy-enhancing network communications, such as TOR, but acknowledges that it has downsides like susceptibility to attacks.In an email exchange on the bitcoin-dev mailing list, the author discusses privacy concerns in rebroadcasting transactions and proposes measures to address them. They suggest implementing pseudo-random and lengthening per attempt time between receiving gossip about a transaction and rebroadcasting attempts. This would help protect the privacy of the connection, identification of the public IP, and the suspected origin of a transaction. The author also notes the potential benefits of moving towards a model where mempools/nodes themselves are responsible for rebroadcasting.The conversation revolves around using the Tor protocol independently of the Tor network and from browsers acting as nodes. The recipient appreciates the proposer's passion for privacy and suggests presenting the idea with a demo and engaging other developers in the community. They even offer sponsorship for flight tickets if needed.Aymeric Vitte expresses concerns over using the Tor network to bypass censorship for Bitcoin, citing centralization, small size, and susceptibility to surveillance as drawbacks. Pieter adds that creating hidden services is easy, making nodes that only connect to hidden services susceptible to eclipsing. While they don't discourage using Tor for Bitcoin traffic, they emphasize that it doesn't solve all privacy problems.The Tor network is not recommended for bypassing censorship for Bitcoin due to its centralization and susceptibility to control. However, using the Tor protocol independently and within browsers for wallets can be beneficial for anonymizing nodes. Moving towards a model where mempools/nodes handle rebroadcasting can help fix privacy leaks, but it's not a simple solution.The context highlights the writer's belief in using privacy-enhancing network communications, like TOR, to address privacy concerns in Bitcoin transactions. They suggest that the current rebroadcasting approach reveals information about nodes and transactions, leading to privacy leaks. They propose a model where mempools/nodes are responsible for rebroadcasting to improve privacy.The email from Lord His Excellency James HRMH advocates for privacy in Bitcoin through the use of privacy-enhancing network communications like TOR. They express doubt about the effectiveness of rebroadcast mechanisms and provide contact information for further communication. The email also includes a forwarded message from Prayank discussing their blog dedicated to Hal Finney, focusing on privacy issues and pull requests from various Bitcoin projects.Prayank's blog tracks issues and pull requests related to privacy in Bitcoin projects and lists developers who have contributed to improving privacy. They highlight a problem with the current rebroadcast mechanism and propose a new mechanism based on fee rate and mempool age. The blog provides additional details, opinions, and links to related comments by Suhas Daftuar.Overall, the context emphasizes the importance of privacy in Bitcoin transactions and explores different approaches, including the use of Tor and alternative rebroadcast mechanisms, to address privacy concerns. It also highlights ongoing discussions, blog posts, and contributions from developers in the Bitcoin community to improve privacy in Bitcoin projects. 2021-12-13T12:40:51+00:00 + The context discusses the use of Tor for Bitcoin traffic and its limitations in addressing privacy concerns. It suggests using Tor differently with node-Tor and hybrid nodes to mitigate these issues. The author emphasizes the importance of privacy-enhancing network communications, such as TOR, but acknowledges that it has downsides like susceptibility to attacks.In an email exchange on the bitcoin-dev mailing list, the author discusses privacy concerns in rebroadcasting transactions and proposes measures to address them. They suggest implementing pseudo-random and lengthening per attempt time between receiving gossip about a transaction and rebroadcasting attempts. This would help protect the privacy of the connection, identification of the public IP, and the suspected origin of a transaction. The author also notes the potential benefits of moving towards a model where mempools/nodes themselves are responsible for rebroadcasting.The conversation revolves around using the Tor protocol independently of the Tor network and from browsers acting as nodes. The recipient appreciates the proposer's passion for privacy and suggests presenting the idea with a demo and engaging other developers in the community. They even offer sponsorship for flight tickets if needed.Aymeric Vitte expresses concerns over using the Tor network to bypass censorship for Bitcoin, citing centralization, small size, and susceptibility to surveillance as drawbacks. Pieter adds that creating hidden services is easy, making nodes that only connect to hidden services susceptible to eclipsing. While they don't discourage using Tor for Bitcoin traffic, they emphasize that it doesn't solve all privacy problems.The Tor network is not recommended for bypassing censorship for Bitcoin due to its centralization and susceptibility to control. However, using the Tor protocol independently and within browsers for wallets can be beneficial for anonymizing nodes. Moving towards a model where mempools/nodes handle rebroadcasting can help fix privacy leaks, but it's not a simple solution.The context highlights the writer's belief in using privacy-enhancing network communications, like TOR, to address privacy concerns in Bitcoin transactions. They suggest that the current rebroadcasting approach reveals information about nodes and transactions, leading to privacy leaks. They propose a model where mempools/nodes are responsible for rebroadcasting to improve privacy.The email from Lord His Excellency James HRMH advocates for privacy in Bitcoin through the use of privacy-enhancing network communications like TOR. They express doubt about the effectiveness of rebroadcast mechanisms and provide contact information for further communication. The email also includes a forwarded message from Prayank discussing their blog dedicated to Hal Finney, focusing on privacy issues and pull requests from various Bitcoin projects.Prayank's blog tracks issues and pull requests related to privacy in Bitcoin projects and lists developers who have contributed to improving privacy. They highlight a problem with the current rebroadcast mechanism and propose a new mechanism based on fee rate and mempool age. The blog provides additional details, opinions, and links to related comments by Suhas Daftuar.Overall, the context emphasizes the importance of privacy in Bitcoin transactions and explores different approaches, including the use of Tor and alternative rebroadcast mechanisms, to address privacy concerns. It also highlights ongoing discussions, blog posts, and contributions from developers in the Bitcoin community to improve privacy in Bitcoin projects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_Sending-OP-RETURN-via-Bitcoin-Lightning.xml b/static/bitcoin-dev/Dec_2021/combined_Sending-OP-RETURN-via-Bitcoin-Lightning.xml index ae1482061e..f0c957d462 100644 --- a/static/bitcoin-dev/Dec_2021/combined_Sending-OP-RETURN-via-Bitcoin-Lightning.xml +++ b/static/bitcoin-dev/Dec_2021/combined_Sending-OP-RETURN-via-Bitcoin-Lightning.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Sending OP_RETURN via Bitcoin Lightning - 2023-08-02T05:12:16.839321+00:00 - - Peter Todd 2021-12-09 12:56:19+00:00 - - - Alex Schoof 2021-12-09 12:12:45+00:00 - - - Peter Todd 2021-12-09 10:07:37+00:00 - - - Christian Moss 2021-12-09 09:49:11+00:00 - - - Peter Todd 2021-12-09 09:12:59+00:00 - - - Christian Moss 2021-12-06 16:35:19+00:00 - - - Christian Moss 2021-12-06 12:38:30+00:00 - - - Martin Habovštiak 2021-12-06 11:31:29+00:00 - - - Karl 2021-12-06 10:20:55+00:00 - - - Héctor José Cárdenas Pacheco 2021-12-06 09:54:30+00:00 - + 2025-09-26T15:31:07.010529+00:00 + python-feedgen + + + [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning Héctor José Cárdenas Pacheco + 2021-12-06T09:54:00.000Z + + + Karl + 2021-12-06T10:20:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Martin Habovštiak + 2021-12-06T11:31:00.000Z + + + [bitcoin-dev] " Christian Moss + 2021-12-06T12:38:00.000Z + + + Christian Moss + 2021-12-06T16:35:00.000Z + + + Peter Todd + 2021-12-09T09:12:00.000Z + + + Christian Moss + 2021-12-09T09:49:00.000Z + + + Peter Todd + 2021-12-09T10:07:00.000Z + + + Alex Schoof + 2021-12-09T12:12:00.000Z + + + Peter Todd + 2021-12-09T12:56:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Sending OP_RETURN via Bitcoin Lightning - 2023-08-02T05:12:16.839321+00:00 + 2025-09-26T15:31:07.011813+00:00 - The discussion revolves around the multisig scheme and Single Use Seals. The author suggests that for on-chain aggregation seals, instead of relying on a single common service provider, it would be better to use multiple aggregation services. This mitigates both availability and censorship risks.However, the other person in the discussion misunderstands the protocol, as seals are trustless with regard to validity, and one can validate any seal regardless of which aggregation service is used. An example is given of an exchange being their own aggregator and not needing multisig, while a customer might use a 3-of-5 multisig since they only do a few transactions a month.Interestingly, it might be worthwhile to run your own aggregator and use multisig in some scenarios. For example, Alice can use a 2-of-3 with two third-party aggregators and her own aggregation chain. If both third-parties are up, she does no on-chain transactions at all; if one third-party is down, she can use her own and the remaining third-party. Thus, she would only do an on-chain transaction to defeat censorship or failure.In a recent email exchange, Christian Moss and Peter Todd discussed the use of single-use seals for asset transfers on the Bitcoin ledger. Todd explains that such seals require an on-chain transaction to post proof of publication to the ledger. However, he notes that scalability is possible because multiple proofs of transfer can be batched into a Merkle tree and added as a single transaction to the ledger.Peter Todd, a well-known Bitcoin developer, responded to a question on the scalability of non-fungible tokens (NFTs) in the context of the RGB protocol. Todd explained that RGB intends to scale NFTs and similar assets in the future via scalable single-use-seals. He referred to an article he wrote back in 2017 explaining how single use seals require an on-chain transaction to post the proof of publication to the ledger. However, batch processing can be used by adding the merkle root into the single transaction going into the ledger, thus allowing scalability.In a recent email thread on the bitcoin-dev mailing list, Christian Moss brought up the issue of scalability for non-fungible tokens (NFTs) in the context of the RGB protocol. Moss questioned whether RGB could scale NFTs as each transaction to transfer ownership of an NFT would require an on-chain transaction. In response, Peter Todd, one of the co-founders of the RGB protocol, pointed out that they intend to address this issue in the future by using scalable single-use-seals. Todd provided a link to his 2017 blog post that explains how these seals can be used to transfer assets off-chain while still maintaining their integrity and security.A discussion on the usage of OP_RETURN for creating and trading NFTs on Bitcoin led to questions about the possibility of using this opcode via Lightning. The idea was to explore if OP_RETURN could be inside a channel's opening or closing transaction and if it could change hands within that channel or network of channels. It was noted that OP_RETURNs do not have ownership according to the bitcoin network, but it is possible to define a protocol that associates an OP_RETURN with ownership, which could then be transferred via lightning by sending associated currency.The discussion also touched on the possibility of making OP_RETURN divisible and sending a piece of OP_RETURN just like one can do on the primary ledger. It was noted that OP_RETURNs themselves do not have ownership, but a protocol that gives them divisible ownership, including via lightning, could be defined. However, it was assumed that this would need a protocol layer parallel to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the ones involving the node's channels as well as the ones with the OP_RETURN. One participant recommended researching RGB, which does not scale NFTs as each transaction to transfer ownership of an NFT would require an on-chain transaction. The participants in the discussion were from the bitcoin-dev and lightning-dev mailing lists.It has been discussed that it is not possible to use Lightning network for NFTs on Bitcoin because lightning relies on liquidity to work, which NFTs are not. A solution suggested is using Ruben Somsens state chain protocol, which allows swapping utxos off-chain and could harbor an op return/nft. The discussion also mentioned the possibility of defining a protocol that associates an OP_RETURN with ownership, which could then be transferred via lightning by sending associated currency via lightning.The discussion thread revolves around the possibility of using OP_RETURN to create and trade NFTs on Bitcoin via Lightning, and if it could be divisible. The potential of defining a protocol for OP_RETURN ownership transfer via lightning is also discussed. The conversation includes questions on whether OP_RETURN can be used in opening or closing transactions within a channel or network of channels and if they have ownership. The need for a parallel protocol layer that stores and reads all Bitcoin transactions and those involving the node's channels 2021-12-09T12:56:19+00:00 + The discussion revolves around the multisig scheme and Single Use Seals. The author suggests that for on-chain aggregation seals, instead of relying on a single common service provider, it would be better to use multiple aggregation services. This mitigates both availability and censorship risks.However, the other person in the discussion misunderstands the protocol, as seals are trustless with regard to validity, and one can validate any seal regardless of which aggregation service is used. An example is given of an exchange being their own aggregator and not needing multisig, while a customer might use a 3-of-5 multisig since they only do a few transactions a month.Interestingly, it might be worthwhile to run your own aggregator and use multisig in some scenarios. For example, Alice can use a 2-of-3 with two third-party aggregators and her own aggregation chain. If both third-parties are up, she does no on-chain transactions at all; if one third-party is down, she can use her own and the remaining third-party. Thus, she would only do an on-chain transaction to defeat censorship or failure.In a recent email exchange, Christian Moss and Peter Todd discussed the use of single-use seals for asset transfers on the Bitcoin ledger. Todd explains that such seals require an on-chain transaction to post proof of publication to the ledger. However, he notes that scalability is possible because multiple proofs of transfer can be batched into a Merkle tree and added as a single transaction to the ledger.Peter Todd, a well-known Bitcoin developer, responded to a question on the scalability of non-fungible tokens (NFTs) in the context of the RGB protocol. Todd explained that RGB intends to scale NFTs and similar assets in the future via scalable single-use-seals. He referred to an article he wrote back in 2017 explaining how single use seals require an on-chain transaction to post the proof of publication to the ledger. However, batch processing can be used by adding the merkle root into the single transaction going into the ledger, thus allowing scalability.In a recent email thread on the bitcoin-dev mailing list, Christian Moss brought up the issue of scalability for non-fungible tokens (NFTs) in the context of the RGB protocol. Moss questioned whether RGB could scale NFTs as each transaction to transfer ownership of an NFT would require an on-chain transaction. In response, Peter Todd, one of the co-founders of the RGB protocol, pointed out that they intend to address this issue in the future by using scalable single-use-seals. Todd provided a link to his 2017 blog post that explains how these seals can be used to transfer assets off-chain while still maintaining their integrity and security.A discussion on the usage of OP_RETURN for creating and trading NFTs on Bitcoin led to questions about the possibility of using this opcode via Lightning. The idea was to explore if OP_RETURN could be inside a channel's opening or closing transaction and if it could change hands within that channel or network of channels. It was noted that OP_RETURNs do not have ownership according to the bitcoin network, but it is possible to define a protocol that associates an OP_RETURN with ownership, which could then be transferred via lightning by sending associated currency.The discussion also touched on the possibility of making OP_RETURN divisible and sending a piece of OP_RETURN just like one can do on the primary ledger. It was noted that OP_RETURNs themselves do not have ownership, but a protocol that gives them divisible ownership, including via lightning, could be defined. However, it was assumed that this would need a protocol layer parallel to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the ones involving the node's channels as well as the ones with the OP_RETURN. One participant recommended researching RGB, which does not scale NFTs as each transaction to transfer ownership of an NFT would require an on-chain transaction. The participants in the discussion were from the bitcoin-dev and lightning-dev mailing lists.It has been discussed that it is not possible to use Lightning network for NFTs on Bitcoin because lightning relies on liquidity to work, which NFTs are not. A solution suggested is using Ruben Somsens state chain protocol, which allows swapping utxos off-chain and could harbor an op return/nft. The discussion also mentioned the possibility of defining a protocol that associates an OP_RETURN with ownership, which could then be transferred via lightning by sending associated currency via lightning.The discussion thread revolves around the possibility of using OP_RETURN to create and trade NFTs on Bitcoin via Lightning, and if it could be divisible. The potential of defining a protocol for OP_RETURN ownership transfer via lightning is also discussed. The conversation includes questions on whether OP_RETURN can be used in opening or closing transactions within a channel or network of channels and if they have ownership. The need for a parallel protocol layer that stores and reads all Bitcoin transactions and those involving the node's channels - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2021/combined_Take-2-Removing-the-Dust-Limit.xml b/static/bitcoin-dev/Dec_2021/combined_Take-2-Removing-the-Dust-Limit.xml index 28b30b723a..d6eaa64999 100644 --- a/static/bitcoin-dev/Dec_2021/combined_Take-2-Removing-the-Dust-Limit.xml +++ b/static/bitcoin-dev/Dec_2021/combined_Take-2-Removing-the-Dust-Limit.xml @@ -1,32 +1,39 @@ - + 2 Combined summary - Take 2: Removing the Dust Limit - 2023-08-02T05:12:48.753724+00:00 - - shymaa arafat 2022-01-21 12:16:35+00:00 - - - damian at willtech.com.au 2021-12-09 06:27:04+00:00 - - - Ruben Somsen 2021-12-08 22:51:50+00:00 - - - Jeremy 2021-12-08 17:41:34+00:00 - - - Jeremy 2021-12-08 17:18:49+00:00 - - - Ruben Somsen 2021-12-08 10:46:22+00:00 - - - Bastien TEINTURIER 2021-12-08 08:34:32+00:00 - - - Jeremy 2021-12-08 01:28:42+00:00 - + 2025-09-26T15:30:50.242588+00:00 + python-feedgen + + + [bitcoin-dev] Take 2: Removing the Dust Limit Jeremy + 2021-12-08T01:28:00.000Z + + + Bastien TEINTURIER + 2021-12-08T08:34:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Ruben Somsen + 2021-12-08T10:46:00.000Z + + + [bitcoin-dev] " Jeremy + 2021-12-08T17:18:00.000Z + + + Jeremy + 2021-12-08T17:41:00.000Z + + + Ruben Somsen + 2021-12-08T22:51:00.000Z + + + damian + 2021-12-09T06:27:00.000Z + + @@ -35,13 +42,13 @@ - python-feedgen + 2 Combined summary - Take 2: Removing the Dust Limit - 2023-08-02T05:12:48.753724+00:00 + 2025-09-26T15:30:50.243571+00:00 - In an email exchange between Bitcoin developers, the issue of 0 value outputs in transactions is discussed. Jeremy Rubin proposes a carve-out that would allow 0 value outputs to be used as Intermediate Outputs, but with certain conditions. The parent transaction must have a higher feerate after Child Pays For Parent (CPFP) than the parent alone. This proposal aims to prevent the proliferation of 0 value utxos while still allowing them to be spent by the fee-paying transaction later. It is suggested that this rule could be beneficial for Anchor Outputs and CTV-based contracts, as well as spacechains. Rubin believes that introducing this rule as a mempool policy would not require new validation rules. However, it is noted that this proposal relies on a fully functional package relay system. Overall, Rubin's proposal addresses the issues surrounding the creation of 0 value outputs for immediately spendable outputs. 2022-01-21T12:16:35+00:00 + In an email exchange between Bitcoin developers, the issue of 0 value outputs in transactions is discussed. Jeremy Rubin proposes a carve-out that would allow 0 value outputs to be used as Intermediate Outputs, but with certain conditions. The parent transaction must have a higher feerate after Child Pays For Parent (CPFP) than the parent alone. This proposal aims to prevent the proliferation of 0 value utxos while still allowing them to be spent by the fee-paying transaction later. It is suggested that this rule could be beneficial for Anchor Outputs and CTV-based contracts, as well as spacechains. Rubin believes that introducing this rule as a mempool policy would not require new validation rules. However, it is noted that this proposal relies on a fully functional package relay system. Overall, Rubin's proposal addresses the issues surrounding the creation of 0 value outputs for immediately spendable outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml b/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml index a0b06eff9e..b2a8446ba3 100644 --- a/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml +++ b/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml @@ -2,7 +2,7 @@ 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) - 2025-09-26T14:23:12.919262+00:00 + 2025-09-26T15:33:07.157101+00:00 python-feedgen Anthony Towns 2022-12-13 12:55:08+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) - 2025-09-26T14:23:12.919396+00:00 + 2025-09-26T15:33:07.157262+00:00 2022-12-13T12:55:08+00:00 The bitcoin-dev mailing list is currently engaged in a discussion about Full RBF (Replace-by-Fee) and its potential impact on mempool policy. Advocates for Full RBF argue that relying on predictable mempool policy is not advisable, as miners will always prioritize optimizing fees in the short term. This could lead to a scenario where miners advertise how to connect to their nodes, allowing those who prefer higher fee transactions to send them directly. However, this assumption is not an economic fact of life, as there are alternative options such as stablecoins or ETH that users could switch to, resulting in a substantial drop in bitcoin traffic, transaction fees, and price.The outcome of implementing Full RBF is uncertain in terms of its effect on the desirability of bitcoin and its price. The use of BTC for payments may shift towards lightning network, causing a reduction in on-chain traffic and fee income. The author emphasizes the importance of prioritizing long-term income over immediate revenue to prevent 51% attacks from becoming a dominant strategy. Consistent and predictable relay policy across nodes remains possible regardless of whether the policy follows the "first seen is final, highest fee rate wins" principle or something else. The author sees Full RBF as a way to eliminate a use-case that carries risk, ultimately strengthening Bitcoin. However, they disagree with preventing others from voluntarily taking on small risks that can be easily managed or avoided. The author clarifies that "money for enemies" refers to empowering the majority rather than an elite minority within the Bitcoin community.Regarding the claim that RBF is a fee-minimization feature, the author responds by highlighting the economics of the situation. Fees serve as a price on confirmation, and there exists an optimum price where total earnings vs price reaches a peak. RBF optimizes the discovery of this optimum price, which is desirable. However, many merchants and consumers reject opt-in-RBF, necessitating the need for full-RBF to improve price discovery of blockspace when such acceptors are prevalent. The author also disputes the implication that demand follows supply, asserting that if Bitcoin offers less utility, it will experience reduced demand regardless of its optimization for capacity saturation. The optimal state is achieved by providing the most value per blockspace per time period. Zero-conf transactions currently generate added demand for blockspace from merchants and consumers due to their qualification for zero-conf acceptance based on fee rates.A discussion on full RBF highlights its alignment with miner and user economic incentives. However, this argument can be refuted as RBF primarily serves as a fee-minimization feature, resulting in lower earnings for miners. Additionally, nodes providing replacement service and propagation incur expenses. The author emphasizes that fees are the price of confirmation and applies the concept of "price theory" where an optimum price may be lower than the prevailing market price. Therefore, RBF optimizes the discovery of this optimum price, but many zero-conf acceptors reject opt-in-RBF despite its improved price discovery. Thus, full-RBF becomes necessary in such cases.There exists a fundamental disagreement regarding Full RBF. Supporters perceive it as a means to eliminate the risk associated with zero-conf transactions, while opponents believe that relying on predictable mempool policy has worked well thus far. Those in favor argue that node policy is not a consensus rule, and changing mempool policy is essential to actively discourage zero-conf. Opponents contend that zero-conf acceptance is already widely used and valuable, and full-RBF can be discarded if the majority of node operators do not care about it. The economic incentive argument currently holds little significance, and there remains an obvious incentive for someone to attempt a double-spend attack on a zero-conf merchant. Angus suggests that accepting zero-conf changes from being tolerated with occasional issues to being strongly discouraged due to potential financial losses. For now, Angus supports running a full-RBF node, considering it a measure that strengthens Bitcoin. However, he is open to reversing his stance if a strong economic argument convinces him and other miners or users to oppose full-RBF.While many proponents of zero-conf focus on supporting Lightning as an alternative, the author argues that Lightning is not without risks and should not be solely relied upon for commercial payments. Lightning is suitable for low-value payments due to the current low-fee environment's lack of scalability. However, for high-value payments, zero-conf has never been valuable or useful and likely never will be. The author highlights instances where double-spends of zero-conf transactions without RBF have been repeatedly demonstrated, emphasizing the absence of a long-term scenario where zero-conf holds value. Although low fees may seem appealing, they incentivize network-wide surveillance, increase the burden on nodes, and promote unsustainable practices resembling a "mev" (miner-extractable value) bounty for merchants. Nevertheless, the author identifies the risk involved in waiting 20 minutes before shipping items as insignificant, with the only potential issue being a user replacing a transaction with a different destination. Even if such an event were to diff --git a/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml b/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml index 4614355caf..ad4804b16d 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger - 2025-09-26T14:23:29.978227+00:00 + 2025-09-26T15:33:11.378868+00:00 python-feedgen Peter Todd 2022-12-06 05:03:56+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger - 2025-09-26T14:23:29.978358+00:00 + 2025-09-26T15:33:11.379023+00:00 2022-12-06T05:03:56+00:00 The bitcoin-dev community is currently discussing the use of a different nVersion to signal full-rbf in multi-party transactions such as coinjoin and contracting protocols like Lightning. Originally, this option was proposed to address a DoS vector affecting these use-cases. However, alternative solutions have been developed that also solve this issue but have their own trade-offs and privacy concerns.One of the proposals suggests that multi-party protocols use a different nVersion to signal full-rbf in their transactions. However, this approach negatively impacts privacy by making it easier for bad actors to deanonymize transactions. Single-party wallets are discouraged from using this option due to complaints from services like Bitrefill about RBF transactions. Designing a protocol without harming privacy seems impossible, as it would require zeroconf services to determine whether a txout has opted into full-rbf while preventing Chainalysis services from doing the same.The decision on how to balance the interests of centralized services and other users regarding privacy tradeoffs needs to be made by the community. Another v3 proposal also presents similar privacy issues, but there may be potential ways to avoid this impact through mempool design.Antoine's message addresses Daniel, who operates a zero-conf risk analysis business. Antoine expresses concerns about the deployment of fullrbf, which could lower the cost of double-spend attacks and increase risk exposure for users. He questions the statistics on the 1.5M transactions per month received by Daniel's business, specifically asking how many are Bitcoin-only transactions excluded from zeroconf due to factors like RBF, long-chain of unconfirmed ancestors, or high value. Antoine also asks about the average feerate.Antoine shares his personal position on fullrbf deployment, as expressed in #26525, stating that there is still no consensus on deploying or removing it. He believes that before considering removing the current option from Bitcoin Core, the community needs to determine the qualification of enough economic flows at risk and the presence of a significant loss in miners' income. He also raises the question of whether the Bitcoin protocol development community should limit user choice in policy settings to preserve mining income and established use-case stability.The original technical motivation for the fullrbf option was to address a DoS vector affecting multi-party transactions like coinjoin and contracting protocols like Lightning. However, alternative solutions have been proposed since then, each with their own trade-offs and conceptual issues. Antoine provides links to previous discussions on these matters, emphasizing the potential risks associated with fullrbf deployment and the importance of balancing user choice with preserving mining income and established use-case stability. diff --git a/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml b/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml index 100aa434b6..96bfa855a3 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml @@ -2,7 +2,7 @@ 2 Combined summary - Pseudocode for robust tail emission - 2025-09-26T14:23:34.234399+00:00 + 2025-09-26T15:33:13.490486+00:00 python-feedgen jk_14 at op.pl 2023-02-01 22:04:11+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - Pseudocode for robust tail emission - 2025-09-26T14:23:34.234602+00:00 + 2025-09-26T15:33:13.490630+00:00 2023-02-01T22:04:11+00:00 In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the diff --git a/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml b/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml index 8e42382c7c..0101b084d7 100644 --- a/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml +++ b/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 91, Issue 5 - 2025-09-26T14:23:38.529860+00:00 + 2025-09-26T15:33:15.604949+00:00 python-feedgen Antoine Riard 2022-12-06 04:06:34+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 91, Issue 5 - 2025-09-26T14:23:38.530025+00:00 + 2025-09-26T15:33:15.605122+00:00 2022-12-06T04:06:34+00:00 Antoine Riard has proposed the removal of the "mempoolfullrbf" feature from Bitcoin Core, citing potential impacts on various use-cases such as on-chain payments, Lightning, and coinjoins. He acknowledges that this decision should follow the same process as any code change, considering factors such as ecosystem impact and utility. While he recognizes the potential benefits for wallets and multi-party applications/contracting protocols, Antoine also sees a lowering of the technical bar for double-spends.A mempool policy design philosophy was suggested to accommodate all Bitcoin use-cases without harming network interests, but concerns remain about miner incentives and potential asymmetries in mining incomes. Antoine believes that removing the "risk-induction" feature is better for the ecosystem, as it alters security expectations for 0conf operators. He suggests that more effective usage data from merchants/service operators would be valuable.The deployment of fullrbf could increase the risk exposure for users of GAP600, a zero-conf risk analysis business integrated with payment processors/liquidity providers and merchants. This increased risk exposure may affect the acceptance of incoming zero-conf transactions. Antoine requests clarification on transaction statistics, such as the number of Bitcoin-only transactions, those excluded from zeroconf, and the average feerate.Antoine maintains his personal position on fullrbf and notes that there is no conceptual consensus within the community on deploying or removing it. He emphasizes the need to address economic flows at risk and potential loss in miners' income before removing the option from Bitcoin Core. Additionally, he questions whether user choice in policy settings should be restrained to preserve mining income and established use-case stability.The original technical motivation for the mempoolfullrbf option was to address a denial-of-service (DoS) vector affecting multi-party transactions like coinjoin and contracting protocols such as Lightning. However, alternative solutions with their own trade-offs and conceptual issues have since been devised. John Carvalho, CEO of Synonym.to, supports zero-conf support for Lightning Network adoption, as it reduces friction and allows for instant, seamless user experiences within wallets. diff --git a/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml b/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml index 3a49a93491..9595dc5fd1 100644 --- a/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml +++ b/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml @@ -2,7 +2,7 @@ 2 Combined summary - onion addresses to try [At least 17% of Bitcoin Core 24.x listening nodes are running full-rbf] - 2025-09-26T14:23:23.600414+00:00 + 2025-09-26T15:33:09.269075+00:00 python-feedgen Peter Todd 2022-12-23 09:46:19+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - onion addresses to try [At least 17% of Bitcoin Core 24.x listening nodes are running full-rbf] - 2025-09-26T14:23:23.600548+00:00 + 2025-09-26T15:33:09.269232+00:00 2022-12-23T09:46:19+00:00 In a recent Bitcoin-dev thread, Peter Todd expressed his concern about the lack of easily accessible sources for onion addresses to try. However, Vasil Dimov pointed out that the issue is more complex than it seems at first glance. Dimov highlighted the fact that obtaining onion addresses is inexpensive and trying them without considering their longer-term track record can lead to problems. There is a risk of inadvertently obtaining the addresses associated with a one-time Sybil attack.To address this challenge, Dimov proposed an alternative solution – using DNS seed records instead. These addresses have been tested over extended periods, offering a higher probability of representing genuine nodes. However, Dimov mentioned that his DNS seed is not currently configured to track nodes using Tor, which limits its effectiveness in this context.On December 22, 2022, Peter Todd shared his concerns on the bitcoin-dev forum regarding the limited availability of convenient sources for onion addresses. In response to Todd's post, Vasil Dimov offered a potential solution in the form of a command that can be executed in the terminal. The command, "bitcoin-cli getnodeaddresses 0 |jq -r 'map(select(.network == "onion")) | .[].address'", could help obtain onion addresses for testing purposes.Dimov concluded his email by including a quote emphasizing the importance of living life to the fullest. diff --git a/static/bitcoin-dev/Feb_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml b/static/bitcoin-dev/Feb_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml index 25283ee185..4a92ee3fbf 100644 --- a/static/bitcoin-dev/Feb_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml +++ b/static/bitcoin-dev/Feb_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP Draft] Allow zero value OP_RETURN in Payment Protocol - 2023-08-01T17:38:01.419169+00:00 + 2025-09-26T15:40:48.249741+00:00 + python-feedgen Toby Padilla 2016-02-02 19:22:10+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - [BIP Draft] Allow zero value OP_RETURN in Payment Protocol - 2023-08-01T17:38:01.419169+00:00 + 2025-09-26T15:40:48.249931+00:00 - In a discussion between Toby Padilla and Luke Dashjr, the use of OP_RETURN values in Bitcoin transactions is debated. Toby argues that PaymentRequests limit the use of OP_RETURN values, as they must be greater than zero, creating a pre-OP_RETURN environment. Luke counters, suggesting that coins should be burned instead of allowing zero value OP_RETURNs. However, Toby believes there is a better alternative.The conversation revolves around the limitations of PaymentRequests regarding OP_RETURN values. Toby explains that PaymentRequests allow for similar transactions as non-PaymentRequest based transactions, but with the limitation that OP_RETURN values must be greater than zero. In contrast, Luke believes that OP_RETURN can be used, but coins would need to be burned, and he sees no benefit in changing that.Toby clarifies his point by mentioning BIP70, where the key for redeeming inputs can be in the user's wallet, allowing transaction construction on another machine without needing a key. However, currently, transaction construction on another machine with zero value OP_RETURNs is not possible. Despite their disagreement, both parties acknowledge that a key is always necessary for redeeming inputs in Bitcoin transactions.On January 26, 2016, Toby sent a message to Luke discussing the encoding of data on the blockchain. Luke suggests that supporting OP_RETURN in PaymentRequests is unnecessary, but Toby argues that it is important because people may use worse methods for encoding data. Toby also mentions the difficulty of constructing a transaction with a zero value OP_RETURN without keys in an environment without keys. Luke does not understand Toby's statement.The discussion focuses on a draft proposal that has not been approved by the mailing list yet. The draft suggests accepting zero value OP_RETURN outputs in BIP70 payment requests, which were previously ignored. The author argues that this feature would be useful for encoding data on the blockchain using PaymentRequests. However, Luke strongly advises against publishing or implementing this BIP, as he sees no benefit to the network and believes it could encourage spam. He also argues that the proposed changes are detrimental and would make users unwilling participants in spam.The author responds by giving an example of how merchants can add the hash of a plain text invoice to the checkout transaction by constructing the PaymentRequest with the invoice hash in an OP_RETURN. Toby argues that merchants and Bitcoin application developers would benefit from this BIP because they can construct transactions with OP_RETURN data without needing keys. Prior to this BIP, such transactions needed to be executed within the same software. Luke questions the relevance to keys and argues that the proposed changes are not compatible with existing and future software. He concludes that implementing either BIP 70 or this draft would have severe consequences, emphasizing that losing burned bitcoins is better than having a way to avoid them.The author of a Bitcoin Improvement Proposal (BIP) warns against publishing or implementing it due to potential spam and user unwillingness. The BIP suggests allowing merchants to add plain text invoice hashes to checkout transactions using PaymentRequests with zero value OP_RETURN outputs. However, the proposal lacks wallet support for checking upfront, may encourage spam, and does not consider the relevance to keys. The proposed changes are also not backward nor forward compatible, resulting in severe consequences.The author has submitted a new BIP draft that alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. This allows wallets to participate in current and future use cases that benefit from metadata stored in OP_RETURN. Previously, OP_RETURN transactions required custom software, but now wallets can process PaymentRequests with OP_RETURN data, supporting sophisticated Bitcoin applications without prior knowledge. Merchants and Bitcoin application developers benefit from this BIP by being able to construct transactions with OP_RETURN data in a keyless environment. Without supporting this BIP, wallets that support BIP70 will allow wasteful data storage. 2016-02-02T19:22:10+00:00 + In a discussion between Toby Padilla and Luke Dashjr, the use of OP_RETURN values in Bitcoin transactions is debated. Toby argues that PaymentRequests limit the use of OP_RETURN values, as they must be greater than zero, creating a pre-OP_RETURN environment. Luke counters, suggesting that coins should be burned instead of allowing zero value OP_RETURNs. However, Toby believes there is a better alternative.The conversation revolves around the limitations of PaymentRequests regarding OP_RETURN values. Toby explains that PaymentRequests allow for similar transactions as non-PaymentRequest based transactions, but with the limitation that OP_RETURN values must be greater than zero. In contrast, Luke believes that OP_RETURN can be used, but coins would need to be burned, and he sees no benefit in changing that.Toby clarifies his point by mentioning BIP70, where the key for redeeming inputs can be in the user's wallet, allowing transaction construction on another machine without needing a key. However, currently, transaction construction on another machine with zero value OP_RETURNs is not possible. Despite their disagreement, both parties acknowledge that a key is always necessary for redeeming inputs in Bitcoin transactions.On January 26, 2016, Toby sent a message to Luke discussing the encoding of data on the blockchain. Luke suggests that supporting OP_RETURN in PaymentRequests is unnecessary, but Toby argues that it is important because people may use worse methods for encoding data. Toby also mentions the difficulty of constructing a transaction with a zero value OP_RETURN without keys in an environment without keys. Luke does not understand Toby's statement.The discussion focuses on a draft proposal that has not been approved by the mailing list yet. The draft suggests accepting zero value OP_RETURN outputs in BIP70 payment requests, which were previously ignored. The author argues that this feature would be useful for encoding data on the blockchain using PaymentRequests. However, Luke strongly advises against publishing or implementing this BIP, as he sees no benefit to the network and believes it could encourage spam. He also argues that the proposed changes are detrimental and would make users unwilling participants in spam.The author responds by giving an example of how merchants can add the hash of a plain text invoice to the checkout transaction by constructing the PaymentRequest with the invoice hash in an OP_RETURN. Toby argues that merchants and Bitcoin application developers would benefit from this BIP because they can construct transactions with OP_RETURN data without needing keys. Prior to this BIP, such transactions needed to be executed within the same software. Luke questions the relevance to keys and argues that the proposed changes are not compatible with existing and future software. He concludes that implementing either BIP 70 or this draft would have severe consequences, emphasizing that losing burned bitcoins is better than having a way to avoid them.The author of a Bitcoin Improvement Proposal (BIP) warns against publishing or implementing it due to potential spam and user unwillingness. The BIP suggests allowing merchants to add plain text invoice hashes to checkout transactions using PaymentRequests with zero value OP_RETURN outputs. However, the proposal lacks wallet support for checking upfront, may encourage spam, and does not consider the relevance to keys. The proposed changes are also not backward nor forward compatible, resulting in severe consequences.The author has submitted a new BIP draft that alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. This allows wallets to participate in current and future use cases that benefit from metadata stored in OP_RETURN. Previously, OP_RETURN transactions required custom software, but now wallets can process PaymentRequests with OP_RETURN data, supporting sophisticated Bitcoin applications without prior knowledge. Merchants and Bitcoin application developers benefit from this BIP by being able to construct transactions with OP_RETURN data in a keyless environment. Without supporting this BIP, wallets that support BIP70 will allow wasteful data storage. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_-BIP-Proposal-New-feefilter-p2p-message.xml b/static/bitcoin-dev/Feb_2016/combined_-BIP-Proposal-New-feefilter-p2p-message.xml index 20a9d75ce8..8d297f66cc 100644 --- a/static/bitcoin-dev/Feb_2016/combined_-BIP-Proposal-New-feefilter-p2p-message.xml +++ b/static/bitcoin-dev/Feb_2016/combined_-BIP-Proposal-New-feefilter-p2p-message.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - [BIP Proposal] New "feefilter" p2p message - 2023-08-01T17:51:50.789054+00:00 + Combined summary - [BIP Proposal] New "feefilter" p2p message + 2025-09-26T15:41:28.407384+00:00 + python-feedgen Gregory Maxwell 2016-02-17 02:43:02+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 - Combined summary - [BIP Proposal] New "feefilter" p2p message - 2023-08-01T17:51:50.789054+00:00 + Combined summary - [BIP Proposal] New "feefilter" p2p message + 2025-09-26T15:41:28.407550+00:00 - In a bitcoin-dev mailing list thread, developers discussed the feefilter message and its usefulness. The message is defined as a message containing an int64_t where pchCommand == "feefilter". Luke Dashjr questioned the lack of extensibility in the message, suggesting that a priorityrate filter could be interesting. However, as there are currently no plans to add an index for ancestor priority rate or create a space-limited priority mempool, a new "priorityfilt" command could be added if needed.Alex Morcos suggested the feefilter message could be useless for wallets because it is additive with a bloom filter for transactions. Transactions would only be relayed if they passed both filters, making it difficult for SPV clients to learn about their own transactions. Dashjr argued that regardless of a user's feefilter, if a transaction has too low of a rate for peers to relay, users won't learn of it. He mentioned a use case for an OR behavior where he would relay very high fee transactions or his own. However, due to the privacy disaster of bloom filters and the need for validation to relay third-party transactions, it would not be practical. Dashjr suggested that a priorityrate filter could be used as an OR instead.The Bitcoin Developer mailing list discussed the "feefilter" message and its definition as a message containing an int64_t, which raised questions about extensibility. The use of different feerate definition versions was suggested to avoid the need for a new protocol extension for every new policy.Luke Dashjr questioned the usefulness of the message for wallets due to the fact that transactions would only be relayed if they passed both the fee filter and a bloom filter. However, Alex Morcos clarified that sending feefilter messages should not reduce the number of transactions accepted into the mempool. The discussion also highlighted the issue of privacy concerns with light clients using bloom filters.In this email exchange, Luke Dashjr questions the use of an int64_t datatype for the feefilter message in Bitcoin development. He argues that it is wasteful to allocate such a large number of bits for what will likely be a small number. Additionally, he questions the lack of extensibility in the current system.Alex Morcos defends his decision by stating that the command string system already provides sufficient extensibility and that a different command name can be given to a better version of feefilter if developed later. He also notes that the 8-byte size of the message is not a significant optimization issue given the low frequency of its use compared to ping traffic. Morcos also clarifies that the feefilter is additive with a bloom filter for transactions, meaning that transactions must pass both filters to be relayed.Dashjr questions the usefulness of this for wallets, but Morcos points out that sending feefilter messages should not affect the acceptance of transactions into the mempool. The email thread ends with no further resolution on the issue.In a Bitcoin developer forum post on February 16, 2016, Alex Morcos questioned the use of the feefilter message, which is defined as a message containing an int64_t where pchCommand == "feefilter". He asked about extensibility and why 64 bits would be used for what is likely a small number. Another user, Luke, pointed out that the fee filter is additive with a bloom filter for transactions, so if an SPV client loaded a bloom filter and sent a feefilter message, transactions would only be relayed if they passed both filters. Luke indicated that this seemed to make feefilter entirely useless for wallets.A proposal has been made to add a new optional peer-to-peer (p2p) message called "feefilter" that would help to reduce unnecessary network traffic. This message would inform peers of the minimum fee below which no transactions are accepted to a node's mempool, saving them from requesting transaction ids and saving the node from requesting transactions that are not in its recentRejects filter.The feefilter message is optional and can be ignored as a protocol rule, and there is also an option to turn off sending the messages within the implementation. The draft BIP text provides an abstract, motivation, specification, considerations, backward compatibility, and implementation details.The feefilter message is designed to instruct peers not to send inv's to a node for transactions with fees below the specified fee rate, and it is meant to filter transactions that are not accepted to a node's mempool, without adversely affecting the propagation efficiency of transactions across the network.There are privacy concerns related to deanonymizing a node by broadcasting identifying information about its mempool min fee, but these concerns are addressed by quantizing the filter value broadcast with a small amount of randomness and broadcasting messages to different peers at individually randomly distributed times. The sending of feefilter messages can be disabled by unsetting the "-feefilter" option, and older clients 2016-02-17T02:43:02+00:00 + In a bitcoin-dev mailing list thread, developers discussed the feefilter message and its usefulness. The message is defined as a message containing an int64_t where pchCommand == "feefilter". Luke Dashjr questioned the lack of extensibility in the message, suggesting that a priorityrate filter could be interesting. However, as there are currently no plans to add an index for ancestor priority rate or create a space-limited priority mempool, a new "priorityfilt" command could be added if needed.Alex Morcos suggested the feefilter message could be useless for wallets because it is additive with a bloom filter for transactions. Transactions would only be relayed if they passed both filters, making it difficult for SPV clients to learn about their own transactions. Dashjr argued that regardless of a user's feefilter, if a transaction has too low of a rate for peers to relay, users won't learn of it. He mentioned a use case for an OR behavior where he would relay very high fee transactions or his own. However, due to the privacy disaster of bloom filters and the need for validation to relay third-party transactions, it would not be practical. Dashjr suggested that a priorityrate filter could be used as an OR instead.The Bitcoin Developer mailing list discussed the "feefilter" message and its definition as a message containing an int64_t, which raised questions about extensibility. The use of different feerate definition versions was suggested to avoid the need for a new protocol extension for every new policy.Luke Dashjr questioned the usefulness of the message for wallets due to the fact that transactions would only be relayed if they passed both the fee filter and a bloom filter. However, Alex Morcos clarified that sending feefilter messages should not reduce the number of transactions accepted into the mempool. The discussion also highlighted the issue of privacy concerns with light clients using bloom filters.In this email exchange, Luke Dashjr questions the use of an int64_t datatype for the feefilter message in Bitcoin development. He argues that it is wasteful to allocate such a large number of bits for what will likely be a small number. Additionally, he questions the lack of extensibility in the current system.Alex Morcos defends his decision by stating that the command string system already provides sufficient extensibility and that a different command name can be given to a better version of feefilter if developed later. He also notes that the 8-byte size of the message is not a significant optimization issue given the low frequency of its use compared to ping traffic. Morcos also clarifies that the feefilter is additive with a bloom filter for transactions, meaning that transactions must pass both filters to be relayed.Dashjr questions the usefulness of this for wallets, but Morcos points out that sending feefilter messages should not affect the acceptance of transactions into the mempool. The email thread ends with no further resolution on the issue.In a Bitcoin developer forum post on February 16, 2016, Alex Morcos questioned the use of the feefilter message, which is defined as a message containing an int64_t where pchCommand == "feefilter". He asked about extensibility and why 64 bits would be used for what is likely a small number. Another user, Luke, pointed out that the fee filter is additive with a bloom filter for transactions, so if an SPV client loaded a bloom filter and sent a feefilter message, transactions would only be relayed if they passed both filters. Luke indicated that this seemed to make feefilter entirely useless for wallets.A proposal has been made to add a new optional peer-to-peer (p2p) message called "feefilter" that would help to reduce unnecessary network traffic. This message would inform peers of the minimum fee below which no transactions are accepted to a node's mempool, saving them from requesting transaction ids and saving the node from requesting transactions that are not in its recentRejects filter.The feefilter message is optional and can be ignored as a protocol rule, and there is also an option to turn off sending the messages within the implementation. The draft BIP text provides an abstract, motivation, specification, considerations, backward compatibility, and implementation details.The feefilter message is designed to instruct peers not to send inv's to a node for transactions with fees below the specified fee rate, and it is meant to filter transactions that are not accepted to a node's mempool, without adversely affecting the propagation efficiency of transactions across the network.There are privacy concerns related to deanonymizing a node by broadcasting identifying information about its mempool min fee, but these concerns are addressed by quantizing the filter value broadcast with a small amount of randomness and broadcasting messages to different peers at individually randomly distributed times. The sending of feefilter messages can be disabled by unsetting the "-feefilter" option, and older clients - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_A-roadmap-to-a-better-header-format-and-bigger-block-size.xml b/static/bitcoin-dev/Feb_2016/combined_A-roadmap-to-a-better-header-format-and-bigger-block-size.xml index 6464053b8a..bb69f59f70 100644 --- a/static/bitcoin-dev/Feb_2016/combined_A-roadmap-to-a-better-header-format-and-bigger-block-size.xml +++ b/static/bitcoin-dev/Feb_2016/combined_A-roadmap-to-a-better-header-format-and-bigger-block-size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A roadmap to a better header format and bigger block size - 2023-08-01T17:48:35.590987+00:00 + 2025-09-26T15:41:32.628537+00:00 + python-feedgen jl2012 at xbt.hk 2016-02-10 04:26:03+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - A roadmap to a better header format and bigger block size - 2023-08-01T17:48:35.591989+00:00 + 2025-09-26T15:41:32.628670+00:00 - In a discussion about improving the header format and increasing the block size for Bitcoin, developer Matt Corallo supports a proposal to implement changes in stages. However, he suggests that only one hardfork should be scheduled at a time to avoid complications. Corallo agrees with most of the proposal but wants to spend more time considering Luke-Jr's header changes and also suggests adding timewarp fixes for enhanced safety and reduced disruption. It is important to note that any client designed for stage 2 should also be ready for stage 3.Another developer on the Bitcoin-dev mailing list, jl2012, proposed a 2-3 year roadmap with three stages of rule changes. Stage 1 is Segregated Witness (BIP141), which will not break any existing full or light nodes. This stage may happen in Q2-Q3 2016. Stage 2 includes fixes that will break existing full nodes but not light nodes, which may occur in Q1-Q2 2017. Stage 3 involves fixes that will break all existing full and light nodes and may take place in 2018 to 2019. An alternative roadmap suggests implementing stage 2, which will break existing full nodes and light nodes, mid-2017 or later, and stage 3, which will fix the time warp attack, in 2018 to 2019. The second proposal is considered safer in terms of safety, but the first proposal is less disruptive. It is emphasized that it is the responsibility of miners, not developers, to confirm that the supermajority of the community accepts changes in stages 2 and 3.The proposed roadmap aims to improve the header format and block size over a 2-3 year period. The objectives include making multistage rule changes, making mining easier without breaking existing hardware and the Stratum protocol, and minimizing disruption during future hardforks. Stage 1, Segregated Witness (BIP141), will not break any existing full or light nodes. Stage 2 includes several fixes that will break existing full nodes but not light nodes, such as increasing the MAX_BLOCK_SIZE and adding anti-DoS rules for non-segwit scripts. Stage 3 involves changes that will break all existing full and light nodes, including changing the header format to Luke-Jr's proposal, reclaiming unused bits in the header for mining, and fixing the time warp attack.Both proposals have their pros and cons. The first proposal offers longer upgrade times for light nodes, opt-in stages for full and light nodes, and not following the minority chain during stage 2. However, it also has the drawback of non-upgraded nodes following the old chain during stages 2 and 3, which may result in lower value. The alternative roadmap presents pros such as opt-in stages for everyone and not following the minority chain during stage 2. However, it also has the downside of a longer implementation time for stage 2 and non-upgraded nodes following the old chain during stage 3.It is reiterated that miners have a responsibility to confirm that the supermajority of the community accepts changes in stages 2 and 3. The proposals by Matt Corallo and Luke-Jr are referenced for further information. 2016-02-10T04:26:03+00:00 + In a discussion about improving the header format and increasing the block size for Bitcoin, developer Matt Corallo supports a proposal to implement changes in stages. However, he suggests that only one hardfork should be scheduled at a time to avoid complications. Corallo agrees with most of the proposal but wants to spend more time considering Luke-Jr's header changes and also suggests adding timewarp fixes for enhanced safety and reduced disruption. It is important to note that any client designed for stage 2 should also be ready for stage 3.Another developer on the Bitcoin-dev mailing list, jl2012, proposed a 2-3 year roadmap with three stages of rule changes. Stage 1 is Segregated Witness (BIP141), which will not break any existing full or light nodes. This stage may happen in Q2-Q3 2016. Stage 2 includes fixes that will break existing full nodes but not light nodes, which may occur in Q1-Q2 2017. Stage 3 involves fixes that will break all existing full and light nodes and may take place in 2018 to 2019. An alternative roadmap suggests implementing stage 2, which will break existing full nodes and light nodes, mid-2017 or later, and stage 3, which will fix the time warp attack, in 2018 to 2019. The second proposal is considered safer in terms of safety, but the first proposal is less disruptive. It is emphasized that it is the responsibility of miners, not developers, to confirm that the supermajority of the community accepts changes in stages 2 and 3.The proposed roadmap aims to improve the header format and block size over a 2-3 year period. The objectives include making multistage rule changes, making mining easier without breaking existing hardware and the Stratum protocol, and minimizing disruption during future hardforks. Stage 1, Segregated Witness (BIP141), will not break any existing full or light nodes. Stage 2 includes several fixes that will break existing full nodes but not light nodes, such as increasing the MAX_BLOCK_SIZE and adding anti-DoS rules for non-segwit scripts. Stage 3 involves changes that will break all existing full and light nodes, including changing the header format to Luke-Jr's proposal, reclaiming unused bits in the header for mining, and fixing the time warp attack.Both proposals have their pros and cons. The first proposal offers longer upgrade times for light nodes, opt-in stages for full and light nodes, and not following the minority chain during stage 2. However, it also has the drawback of non-upgraded nodes following the old chain during stages 2 and 3, which may result in lower value. The alternative roadmap presents pros such as opt-in stages for everyone and not following the minority chain during stage 2. However, it also has the downside of a longer implementation time for stage 2 and non-upgraded nodes following the old chain during stage 3.It is reiterated that miners have a responsibility to confirm that the supermajority of the community accepts changes in stages 2 and 3. The proposals by Matt Corallo and Luke-Jr are referenced for further information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-CPRKV-Check-private-key-verify.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-CPRKV-Check-private-key-verify.xml index 011a84545f..acedbd963d 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-CPRKV-Check-private-key-verify.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-CPRKV-Check-private-key-verify.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP CPRKV: Check private key verify - 2023-08-01T17:50:26.142424+00:00 + 2025-09-26T15:41:09.381072+00:00 + python-feedgen jl2012 at xbt.hk 2016-04-18 19:03:07+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BIP CPRKV: Check private key verify - 2023-08-01T17:50:26.142424+00:00 + 2025-09-26T15:41:09.381208+00:00 - In a recent proposal on the bitcoin-dev mailing list, there was a suggestion to remove the OP_CHECKPRIVPUBPAIR opcode and replace it with OP_CAT and OP_CHECKSIGVERIFY. This proposal involves two parties, Bob and Alice, agreeing upon a random secret nonce, k, and calculating r in the same way as signing a transaction. The script consists of various operations such as SIZE, ADD, SWAP, CAT, CECHKSIGVERIFY, and CHECKSIG. This proposal is deemed useful for the lightning network. It is mentioned that a patch to the reference client may be coded up, but segregated witness is likely to take priority for soft-fork slot usage.On February 29th, 2016, Mats Jerratsch shared a link to a discussion on the bitcoin-dev mailing list from November 2015 regarding a Bitcoin Improvement Proposal (BIP) for Schnorr signatures. Jerratsch noted that this proposal is relevant to the Lightning Network and asked if there was a demand for coding up a patch to the reference client. However, it is also mentioned that segregated witness might be taking up any potential soft-fork slot.Another discussion on the bitcoin-dev mailing list revolves around the usefulness of a certain feature for the Lightning Network. This feature involves the creation of a non-standard script to execute a payment in an altcoin without requiring a new opcode. However, it is noted that this method will only work for coins that allow non-standard scripts, as it violates the standard output script assumption. There was initial focus on maintaining standard scripts on the altcoin, but the non-standard script approach is considered an improvement over the cut and choose method.In a previous email conversation on February 12, 2016, the possibility of creating a new opcode for an altcoin was discussed. However, it was later determined that the altcoin would only accept standard output scripts. As a result, the suggestion of paying to a non-standard script instead was considered an improvement over the previous method of cut and choose. It is mentioned that this approach would only work for coins that allow non-standard scripts. The focus then shifted to maintaining standard scripts on the altcoin.A new BIP draft proposed by Tier Nolan via the bitcoin-dev mailing list discusses using CLTV for cross-chain transfers. Many altcoins do not support CLTV, making the transfer insecure. Therefore, the proposed protocol doesn't require any new opcode and uses cut and choose to allow commitments to publish private keys. However, it is acknowledged that this protocol is clunky and not entirely secure. The proposed protocol involves four steps where Bob trades bitcoins for altcoins with Alice. The BIP CPRKV, Check Private Key Verify, allows outputs to be locked until a private key is published that matches a given public key. The BIP CPRKV is available on GitHub, and the email sender ensured the safety of their computer.The email conversation also explores the possibility of increasing the sigop count for a NOP without using segwit. It is determined that this would be a soft fork, as it makes previously allowed actions disallowed. The increased sigop count would be valid under both old and new rules, without requiring specific support on the altcoin. This allows the Bitcoin network to act as a trusted third party for safe use of channels on the altcoin, despite its malleability issues and lack of OP_CHECKLOCKTIMEVERIFY. In regards to seg-witness, the ideal scenario would be repurposing OP_NOP3 to work in both old and new scripts.Overall, these discussions among Bitcoin developers highlight various proposals and considerations regarding the use of CLTV for cross-chain transfers, the introduction of new opcodes, the improvement of scripting for the lightning network, and the potential impact on soft-fork slot usage. 2016-04-18T19:03:07+00:00 + In a recent proposal on the bitcoin-dev mailing list, there was a suggestion to remove the OP_CHECKPRIVPUBPAIR opcode and replace it with OP_CAT and OP_CHECKSIGVERIFY. This proposal involves two parties, Bob and Alice, agreeing upon a random secret nonce, k, and calculating r in the same way as signing a transaction. The script consists of various operations such as SIZE, ADD, SWAP, CAT, CECHKSIGVERIFY, and CHECKSIG. This proposal is deemed useful for the lightning network. It is mentioned that a patch to the reference client may be coded up, but segregated witness is likely to take priority for soft-fork slot usage.On February 29th, 2016, Mats Jerratsch shared a link to a discussion on the bitcoin-dev mailing list from November 2015 regarding a Bitcoin Improvement Proposal (BIP) for Schnorr signatures. Jerratsch noted that this proposal is relevant to the Lightning Network and asked if there was a demand for coding up a patch to the reference client. However, it is also mentioned that segregated witness might be taking up any potential soft-fork slot.Another discussion on the bitcoin-dev mailing list revolves around the usefulness of a certain feature for the Lightning Network. This feature involves the creation of a non-standard script to execute a payment in an altcoin without requiring a new opcode. However, it is noted that this method will only work for coins that allow non-standard scripts, as it violates the standard output script assumption. There was initial focus on maintaining standard scripts on the altcoin, but the non-standard script approach is considered an improvement over the cut and choose method.In a previous email conversation on February 12, 2016, the possibility of creating a new opcode for an altcoin was discussed. However, it was later determined that the altcoin would only accept standard output scripts. As a result, the suggestion of paying to a non-standard script instead was considered an improvement over the previous method of cut and choose. It is mentioned that this approach would only work for coins that allow non-standard scripts. The focus then shifted to maintaining standard scripts on the altcoin.A new BIP draft proposed by Tier Nolan via the bitcoin-dev mailing list discusses using CLTV for cross-chain transfers. Many altcoins do not support CLTV, making the transfer insecure. Therefore, the proposed protocol doesn't require any new opcode and uses cut and choose to allow commitments to publish private keys. However, it is acknowledged that this protocol is clunky and not entirely secure. The proposed protocol involves four steps where Bob trades bitcoins for altcoins with Alice. The BIP CPRKV, Check Private Key Verify, allows outputs to be locked until a private key is published that matches a given public key. The BIP CPRKV is available on GitHub, and the email sender ensured the safety of their computer.The email conversation also explores the possibility of increasing the sigop count for a NOP without using segwit. It is determined that this would be a soft fork, as it makes previously allowed actions disallowed. The increased sigop count would be valid under both old and new rules, without requiring specific support on the altcoin. This allows the Bitcoin network to act as a trusted third party for safe use of channels on the altcoin, despite its malleability issues and lack of OP_CHECKLOCKTIMEVERIFY. In regards to seg-witness, the ideal scenario would be repurposing OP_NOP3 to work in both old and new scripts.Overall, these discussions among Bitcoin developers highlight various proposals and considerations regarding the use of CLTV for cross-chain transfers, the introduction of new opcodes, the improvement of scripting for the lightning network, and the potential impact on soft-fork slot usage. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-Final-status.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-Final-status.xml index d73b54f956..b20d3b501d 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-Final-status.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-Final-status.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Final status - 2023-08-01T17:47:44.092268+00:00 + 2025-09-26T15:41:15.725530+00:00 + python-feedgen Luke Dashjr 2016-02-08 22:57:34+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP Final status - 2023-08-01T17:47:44.092268+00:00 + 2025-09-26T15:41:15.725664+00:00 - On the bitcoin-dev mailing list, Peter Todd and Luke Dashjr engaged in a discussion about upgrading five Bitcoin Improvement Proposals (BIPs) from Draft to Final status. One of these BIPs, BIP 50, was specifically addressed by Peter Todd. He suggested that referring to the March 2013 Chain Fork described in BIP 50 as a "hard fork" oversimplifies the nuances of what occurred during that fork. However, he agreed that some rephrasing of BIP 50 could be beneficial. Peter Todd also noted that despite the issues with the pre-March protocol, the May 2013 change was undoubtedly a hard fork. The proposal for the upgrade is available on GitHub and requires the acknowledgment (ACK) of the BIP champions.Luke Dashjr proposed an upgrade to five additional BIPs on February 8, 2016, seeking their approval to transition from Draft to Final status. One of these BIPs is BIP 50, which focuses on the March 2013 Chain Fork Post-Mortem written by Gavin Andresen. During the discussion, it was suggested that describing this fork as a "hard fork" might not accurately capture the situation. The rejection of the chain by version 0.7 was non-deterministic and depended on observing a specific type of reorganization. Notably, a digital signature was attached to the email exchanged during this discussion.The Bitcoin Improvement Proposals (BIPs) are currently undergoing updates, including proposed changes to the status of several BIPs. These updates are being discussed on GitHub and encompass modifications such as elevating Accepted BIPs to Final status. The proposal has been open for a week and is expected to be merged within the next week, unless any objections arise. Additionally, another proposal aims to upgrade five more BIPs, transitioning them from Draft to Final status. The champions of these BIPs have been called upon to provide their acknowledgments (ACKs). The BIPs targeted for upgrade are the March 2013 Chain Fork Post-Mortem, Fixed Length "version" Message (Relay-Transactions Field), getutxo message, Strict DER signatures, and Use "Accept" header for response type negotiation with Payment Request URLs. 2016-02-08T22:57:34+00:00 + On the bitcoin-dev mailing list, Peter Todd and Luke Dashjr engaged in a discussion about upgrading five Bitcoin Improvement Proposals (BIPs) from Draft to Final status. One of these BIPs, BIP 50, was specifically addressed by Peter Todd. He suggested that referring to the March 2013 Chain Fork described in BIP 50 as a "hard fork" oversimplifies the nuances of what occurred during that fork. However, he agreed that some rephrasing of BIP 50 could be beneficial. Peter Todd also noted that despite the issues with the pre-March protocol, the May 2013 change was undoubtedly a hard fork. The proposal for the upgrade is available on GitHub and requires the acknowledgment (ACK) of the BIP champions.Luke Dashjr proposed an upgrade to five additional BIPs on February 8, 2016, seeking their approval to transition from Draft to Final status. One of these BIPs is BIP 50, which focuses on the March 2013 Chain Fork Post-Mortem written by Gavin Andresen. During the discussion, it was suggested that describing this fork as a "hard fork" might not accurately capture the situation. The rejection of the chain by version 0.7 was non-deterministic and depended on observing a specific type of reorganization. Notably, a digital signature was attached to the email exchanged during this discussion.The Bitcoin Improvement Proposals (BIPs) are currently undergoing updates, including proposed changes to the status of several BIPs. These updates are being discussed on GitHub and encompass modifications such as elevating Accepted BIPs to Final status. The proposal has been open for a week and is expected to be merged within the next week, unless any objections arise. Additionally, another proposal aims to upgrade five more BIPs, transitioning them from Draft to Final status. The champions of these BIPs have been called upon to provide their acknowledgments (ACKs). The BIPs targeted for upgrade are the March 2013 Chain Fork Post-Mortem, Fixed Length "version" Message (Relay-Transactions Field), getutxo message, Strict DER signatures, and Use "Accept" header for response type negotiation with Payment Request URLs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml index c40edb99e6..119cfa7b74 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Process: Status, comments, and copyright licenses - 2023-08-01T17:42:26.680157+00:00 + 2025-09-26T15:41:19.954945+00:00 + python-feedgen Mustafa Al-Bassam 2016-03-10 00:37:46+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - BIP Process: Status, comments, and copyright licenses - 2023-08-01T17:42:26.681157+00:00 + 2025-09-26T15:41:19.955125+00:00 - The Bitcoin Improvement Proposals (BIPs) are currently overseen by the mailing list, which could lead to centralized control. A proposal has been made to replace the mailing list with a "public discussion medium" such as forums or conferences. Luke Dashjr has created a draft BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concern about too much control being given to those who control the mailing list and wiki.Luke Dashjr suggested keeping reviews on the mailing list while using author-chosen forums in addition to the Bitcoin Wiki. Ryan Grant questioned the process for changing the status of a BIP from Draft to Active when rough consensus is reached on the mailing list. Luke explained that the wiki page is for leaving comments after discussion is over, and all review should remain on the mailing list. He also suggested that any forum used for review should have indisputable records of moderation and user edits.Luke Dashjr has made changes to BIP 2 to reduce hard feelings during comments. He proposed that a BIP author gather new/edited comment titles and report them once a week. Mediawiki offers watchlists for this purpose, and the wiki as a whole should be verifiable.A draft BIP by Luke Dashjr provides clarification on the Status field, expands allowable licenses, and adds public comments. Feedback on the draft is welcome. BIP99 aims to establish safe deployment requirements for an uncontroversial hardfork, but the concept of "adoption consensus" needs a neutral term. Suggestions are sought to make this clearer.Dave Scotese suggested that rules and code define Bitcoin, but consensus is needed after release. Gavin Andresen expressed concern about the definition of "consensus" giving too much control to the mailing list and wiki. Suggestions to make the meaning of "consensus" clear are welcomed.Jorge Timón suggested finding another term for "consensus" in the BIP document to avoid confusion. Luke-Jr agreed and proposed using "concord rules/code" instead of "consensus rules/code".Gavin Andresen expressed concern about the definition of "consensus" in the BIP process, giving too much control to the mailing list and wiki. He added a statement clarifying that the criteria for updating the status of BIPs should not be used to oppose or reject a BIP.The overuse of the term "consensus" in various contexts has caused confusion. Suggestions for alternative terms are welcomed. Luke-Jr suggested replacing it with "nearly universal acceptance" or "ecosystem-harmonious".Luke Dashjr and Dave Scotese discussed the need for coordination among multiple applications providing their own implementations of API/RPC and corresponding BIPs. They agreed that only one application would be standard to avoid confusion. The status of a BIP and comments should be unrelated metrics. The author of a BIP should be allowed to specify other internet locations for comments, but this could potentially be abused.Luke Dashjr proposed a draft BIP that provides clarity on the Status field, expands allowable licenses, and introduces public comments. Gavin Andresen expressed concerns about the definition of "consensus" giving too much control to the mailing list and wiki.Dave Scotese addressed the question of multiple applications providing their own implementations of API/RPC and corresponding BIPs. He stated that only one such application should be standard to avoid confusion. The status of a BIP and comments should not influence each other. The author of a BIP should be allowed to specify other internet locations for comments, although this could be potentially abused.Luke Dashjr requested objections to reach consensus on formally defining consensus. Clear reasoning must be given for objections not deemed substantiated by the community. Comments on BIPs should be solicited on the bitcoin-dev mailing list and summarized fairly in the wiki. Wiki registration and monitoring should not be a required hurdle to participation.Luke Dashjr completed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. Comments and status are unrelated metrics. The author of a BIP can specify other internet locations for comments.Luke Dashjr proposed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concerns about the definition of "consensus" giving too much centralized control.Dave Scotese stated that multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. The status of a BIP and comments should not directly influence each other. The author of a BIP should be allowed to specify other internet locations for comments. Clear reasoning must be offered for objections not deemed substantiated by the community.Luke Dashjr requested objections for consensus on formally defining consensus. Comments on BIPs should be solicited on 2016-03-10T00:37:46+00:00 + The Bitcoin Improvement Proposals (BIPs) are currently overseen by the mailing list, which could lead to centralized control. A proposal has been made to replace the mailing list with a "public discussion medium" such as forums or conferences. Luke Dashjr has created a draft BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concern about too much control being given to those who control the mailing list and wiki.Luke Dashjr suggested keeping reviews on the mailing list while using author-chosen forums in addition to the Bitcoin Wiki. Ryan Grant questioned the process for changing the status of a BIP from Draft to Active when rough consensus is reached on the mailing list. Luke explained that the wiki page is for leaving comments after discussion is over, and all review should remain on the mailing list. He also suggested that any forum used for review should have indisputable records of moderation and user edits.Luke Dashjr has made changes to BIP 2 to reduce hard feelings during comments. He proposed that a BIP author gather new/edited comment titles and report them once a week. Mediawiki offers watchlists for this purpose, and the wiki as a whole should be verifiable.A draft BIP by Luke Dashjr provides clarification on the Status field, expands allowable licenses, and adds public comments. Feedback on the draft is welcome. BIP99 aims to establish safe deployment requirements for an uncontroversial hardfork, but the concept of "adoption consensus" needs a neutral term. Suggestions are sought to make this clearer.Dave Scotese suggested that rules and code define Bitcoin, but consensus is needed after release. Gavin Andresen expressed concern about the definition of "consensus" giving too much control to the mailing list and wiki. Suggestions to make the meaning of "consensus" clear are welcomed.Jorge Timón suggested finding another term for "consensus" in the BIP document to avoid confusion. Luke-Jr agreed and proposed using "concord rules/code" instead of "consensus rules/code".Gavin Andresen expressed concern about the definition of "consensus" in the BIP process, giving too much control to the mailing list and wiki. He added a statement clarifying that the criteria for updating the status of BIPs should not be used to oppose or reject a BIP.The overuse of the term "consensus" in various contexts has caused confusion. Suggestions for alternative terms are welcomed. Luke-Jr suggested replacing it with "nearly universal acceptance" or "ecosystem-harmonious".Luke Dashjr and Dave Scotese discussed the need for coordination among multiple applications providing their own implementations of API/RPC and corresponding BIPs. They agreed that only one application would be standard to avoid confusion. The status of a BIP and comments should be unrelated metrics. The author of a BIP should be allowed to specify other internet locations for comments, but this could potentially be abused.Luke Dashjr proposed a draft BIP that provides clarity on the Status field, expands allowable licenses, and introduces public comments. Gavin Andresen expressed concerns about the definition of "consensus" giving too much control to the mailing list and wiki.Dave Scotese addressed the question of multiple applications providing their own implementations of API/RPC and corresponding BIPs. He stated that only one such application should be standard to avoid confusion. The status of a BIP and comments should not influence each other. The author of a BIP should be allowed to specify other internet locations for comments, although this could be potentially abused.Luke Dashjr requested objections to reach consensus on formally defining consensus. Clear reasoning must be given for objections not deemed substantiated by the community. Comments on BIPs should be solicited on the bitcoin-dev mailing list and summarized fairly in the wiki. Wiki registration and monitoring should not be a required hurdle to participation.Luke Dashjr completed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. Comments and status are unrelated metrics. The author of a BIP can specify other internet locations for comments.Luke Dashjr proposed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concerns about the definition of "consensus" giving too much centralized control.Dave Scotese stated that multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. The status of a BIP and comments should not directly influence each other. The author of a BIP should be allowed to specify other internet locations for comments. Clear reasoning must be offered for objections not deemed substantiated by the community.Luke Dashjr requested objections for consensus on formally defining consensus. Comments on BIPs should be solicited on - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-draft-Hard-fork-opt-in-mechanism-for-SPV-nodes.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-draft-Hard-fork-opt-in-mechanism-for-SPV-nodes.xml index f05ff5d4bd..e1aac1e401 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-draft-Hard-fork-opt-in-mechanism-for-SPV-nodes.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-draft-Hard-fork-opt-in-mechanism-for-SPV-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft: Hard fork opt-in mechanism for SPV nodes - 2023-08-01T17:44:38.355983+00:00 + 2025-09-26T15:41:24.181406+00:00 + python-feedgen Luke Dashjr 2016-02-05 23:25:14+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP draft: Hard fork opt-in mechanism for SPV nodes - 2023-08-01T17:44:38.355983+00:00 + 2025-09-26T15:41:24.181573+00:00 - Johnson Lau proposed a new algorithm for the transaction commitment in block header to address the issue of Simplified Payment Verification (SPV) nodes automatically following a planned hard fork without explicit opt-in consent. This proposal aims to ensure that SPV nodes will not accept any incoming transactions on a new chain without being able to verify them with the new commitment format. The proposed Bitcoin Improvement Proposal (BIP) specifies using Double-SHA256(zero|merkle_root|zero) as the commitment instead of directly committing the Merkle root to the header. This change does not alter the header structure, allowing non-upgraded SPV nodes to still verify the proof-of-work of the new chain. However, they will not accept any transactions on the new chain until further actions are taken by their operators. Additionally, SPV nodes will not accept any new transactions on the old chain either, as it has less proof-of-work.This proposal acts as a supplement to the hardfork bit BIP, which informs full and SPV nodes about a planned hard fork. Lau's proposal ensures that SPV nodes will not lose any money in a hard fork, even if they do not check the hardfork bit. While this mechanism intentionally breaks backward compatibility, non-upgraded full nodes and SPV nodes can still verify the proof-of-work of upgraded blocks.To address potential fraudulent behavior during hard forks, a fraud-proof system is proposed. This system generates compact proofs to identify invalid blocks on the blockchain, which can be verified by SPV nodes. Hard forks without malicious intentions may also be considered as "fraud" among non-upgraded nodes. With this proposal, non-upgraded SPV nodes will always believe the new chain is valid but cannot be defrauded as they will not see any incoming transactions.The proposed BIP, authored by Johnson Lau, is currently in draft mode and available in the public domain. The compatibility of this proposal may need to be evaluated on a case-by-case basis, as changing the padding value may not always be necessary and could cause unnecessary disruption. 2016-02-05T23:25:14+00:00 + Johnson Lau proposed a new algorithm for the transaction commitment in block header to address the issue of Simplified Payment Verification (SPV) nodes automatically following a planned hard fork without explicit opt-in consent. This proposal aims to ensure that SPV nodes will not accept any incoming transactions on a new chain without being able to verify them with the new commitment format. The proposed Bitcoin Improvement Proposal (BIP) specifies using Double-SHA256(zero|merkle_root|zero) as the commitment instead of directly committing the Merkle root to the header. This change does not alter the header structure, allowing non-upgraded SPV nodes to still verify the proof-of-work of the new chain. However, they will not accept any transactions on the new chain until further actions are taken by their operators. Additionally, SPV nodes will not accept any new transactions on the old chain either, as it has less proof-of-work.This proposal acts as a supplement to the hardfork bit BIP, which informs full and SPV nodes about a planned hard fork. Lau's proposal ensures that SPV nodes will not lose any money in a hard fork, even if they do not check the hardfork bit. While this mechanism intentionally breaks backward compatibility, non-upgraded full nodes and SPV nodes can still verify the proof-of-work of upgraded blocks.To address potential fraudulent behavior during hard forks, a fraud-proof system is proposed. This system generates compact proofs to identify invalid blocks on the blockchain, which can be verified by SPV nodes. Hard forks without malicious intentions may also be considered as "fraud" among non-upgraded nodes. With this proposal, non-upgraded SPV nodes will always believe the new chain is valid but cannot be defrauded as they will not see any incoming transactions.The proposed BIP, authored by Johnson Lau, is currently in draft mode and available in the public domain. The compatibility of this proposal may need to be evaluated on a case-by-case basis, as changing the padding value may not always be necessary and could cause unnecessary disruption. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-proposal-Increase-block-size-limit-to-2-megabytes.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-proposal-Increase-block-size-limit-to-2-megabytes.xml index b6a3c732d6..148d195515 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-proposal-Increase-block-size-limit-to-2-megabytes.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-proposal-Increase-block-size-limit-to-2-megabytes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP proposal: Increase block size limit to 2 megabytes - 2023-08-01T17:46:29.343154+00:00 + 2025-09-26T15:40:56.709546+00:00 + python-feedgen Tier Nolan 2016-02-10 12:58:01+00:00 @@ -167,13 +168,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: Increase block size limit to 2 megabytes - 2023-08-01T17:46:29.343154+00:00 + 2025-09-26T15:40:56.709763+00:00 - In a discussion on the bitcoin-dev mailing list, the potential risks and uncertainties of a proposed hard fork for Bitcoin were debated. The conversation focused on the possibility of a minority fork arising if the Classic hard fork was activated with 75% acceptance, as opposed to a complete switch over. Gavin Andresen argued that based on past soft-fork adoption by miners, there would be almost no hash power left on the weaker branch of the fork. However, others pointed out the uncertainty of the situation and the need for open, honest communication within the Bitcoin community. The discussion also touched on technical parameters such as the length of time given for development work and the likelihood of Bitcoin Core pursuing a minority fork. The email exchange highlighted the importance of addressing the potential risks and uncertainties associated with any changes to the Bitcoin protocol.The debate surrounding the threshold for a block size increase in Bitcoin revolved around whether to require 75% or 95% of miners to signal their support. There were concerns that a 75% threshold could give too much power to a single large miner or mining pool, while a 20% minority could still sabotage an upgrade by voting in favor of it and then refusing to mine on the new chain. Regardless of the threshold chosen, both chains would have equal difficulty in mining blocks during the adjustment period. If a fork does occur, one branch would have 2MB blocks every 18 minutes while the other would have 1MB blocks every 22 minutes. The former branch would be able to handle more transaction volume, resulting in a higher market value for newly minted coins and incentivizing miners to switch to the more profitable 2MB branch.The email exchange also discussed the potential risks and uncertainties associated with outdated nodes. If a node is not updated, it will eventually stop receiving new blocks and funds won't be confirmed. However, if someone decides to attack the node, they could receive confirmations for a large payment, leading users to believe it is irreversibly confirmed when it's actually part of a double-spend attack. If the node is on a weaker branch of a fork, it could take up to a week to get six confirmations. Full nodes are advised to upgrade their software, but lightweight nodes may not be aware of the issue. It is suggested that DNS seeds avoid reporting nodes significantly behind the rest of the network.In terms of implementation, Gavin Andresen proposed increasing the block size limit to 2,000,000 bytes with accurate sigop counting and a high limit on signature hashing. He suggested combining these limits into a single weighted sum formula as a solution. Constructive feedback was welcomed on his proposal.The email exchange also addressed security considerations for the proposed hard fork. There were discussions about testing the change, potential rollback plans in case of false voting triggering the hard fork, and monitoring and managing security through the hard fork. It was emphasized that the Bitcoin network is self-monitoring and self-managing, and various providers such as exchanges, libraries, wallets, and pools were conducting their own testing.Overall, the email exchange shed light on the potential risks and uncertainties associated with a hard fork in Bitcoin and the need for open communication and thorough consideration of security measures.In a series of email conversations and discussions on the bitcoin-dev mailing list, various aspects of the proposed hard fork to increase the block size limit in the Bitcoin network were addressed. Gavin Andresen, Luke Dashjr, Tom Zander, and others discussed issues such as security considerations, rollback plans, monitoring and managing security, SPV wallets compatibility, and economic support for the hard fork.Andresen suggested using version bits to trigger a soft-hard fork and emphasized the importance of considering security implications. He also mentioned that monitoring and management of the network would be done by services like statoshi.info, with miners and businesses playing their roles as well.The conversation also delved into the impact of nodes being kicked out of the network, with Zander explaining that old nodes would stop receiving new blocks and funds wouldn't get confirmed until the software is upgraded. Timón raised concerns about users unknowingly confirming fraudulent payments due to being lost from the network.There were discussions regarding the need for a capacity increase and the opinions of miners and the broader community. Dashjr disagreed with the claim of broad agreement and highlighted evidence to the contrary. The difference between SPV wallets and light clients was also debated, with suggestions for addressing both in the proposed hard fork.The controversy surrounding the 28-day grace period for implementing the upgrade was discussed, with differing views on the potential impact on users and the feasibility of longer grace periods. Andresen argued that there was no evidence to support the claim that 28 days is insufficient time.The article touched on the blog posts by Andresen, which discussed the constants chosen for the proposed hard fork and their potential impact on static analysis. Dashjr expressed concerns about these changes breaking static analysis and suggested alternative approaches.There were also discussions about economic support for the hard 2016-02-10T12:58:01+00:00 + In a discussion on the bitcoin-dev mailing list, the potential risks and uncertainties of a proposed hard fork for Bitcoin were debated. The conversation focused on the possibility of a minority fork arising if the Classic hard fork was activated with 75% acceptance, as opposed to a complete switch over. Gavin Andresen argued that based on past soft-fork adoption by miners, there would be almost no hash power left on the weaker branch of the fork. However, others pointed out the uncertainty of the situation and the need for open, honest communication within the Bitcoin community. The discussion also touched on technical parameters such as the length of time given for development work and the likelihood of Bitcoin Core pursuing a minority fork. The email exchange highlighted the importance of addressing the potential risks and uncertainties associated with any changes to the Bitcoin protocol.The debate surrounding the threshold for a block size increase in Bitcoin revolved around whether to require 75% or 95% of miners to signal their support. There were concerns that a 75% threshold could give too much power to a single large miner or mining pool, while a 20% minority could still sabotage an upgrade by voting in favor of it and then refusing to mine on the new chain. Regardless of the threshold chosen, both chains would have equal difficulty in mining blocks during the adjustment period. If a fork does occur, one branch would have 2MB blocks every 18 minutes while the other would have 1MB blocks every 22 minutes. The former branch would be able to handle more transaction volume, resulting in a higher market value for newly minted coins and incentivizing miners to switch to the more profitable 2MB branch.The email exchange also discussed the potential risks and uncertainties associated with outdated nodes. If a node is not updated, it will eventually stop receiving new blocks and funds won't be confirmed. However, if someone decides to attack the node, they could receive confirmations for a large payment, leading users to believe it is irreversibly confirmed when it's actually part of a double-spend attack. If the node is on a weaker branch of a fork, it could take up to a week to get six confirmations. Full nodes are advised to upgrade their software, but lightweight nodes may not be aware of the issue. It is suggested that DNS seeds avoid reporting nodes significantly behind the rest of the network.In terms of implementation, Gavin Andresen proposed increasing the block size limit to 2,000,000 bytes with accurate sigop counting and a high limit on signature hashing. He suggested combining these limits into a single weighted sum formula as a solution. Constructive feedback was welcomed on his proposal.The email exchange also addressed security considerations for the proposed hard fork. There were discussions about testing the change, potential rollback plans in case of false voting triggering the hard fork, and monitoring and managing security through the hard fork. It was emphasized that the Bitcoin network is self-monitoring and self-managing, and various providers such as exchanges, libraries, wallets, and pools were conducting their own testing.Overall, the email exchange shed light on the potential risks and uncertainties associated with a hard fork in Bitcoin and the need for open communication and thorough consideration of security measures.In a series of email conversations and discussions on the bitcoin-dev mailing list, various aspects of the proposed hard fork to increase the block size limit in the Bitcoin network were addressed. Gavin Andresen, Luke Dashjr, Tom Zander, and others discussed issues such as security considerations, rollback plans, monitoring and managing security, SPV wallets compatibility, and economic support for the hard fork.Andresen suggested using version bits to trigger a soft-hard fork and emphasized the importance of considering security implications. He also mentioned that monitoring and management of the network would be done by services like statoshi.info, with miners and businesses playing their roles as well.The conversation also delved into the impact of nodes being kicked out of the network, with Zander explaining that old nodes would stop receiving new blocks and funds wouldn't get confirmed until the software is upgraded. Timón raised concerns about users unknowingly confirming fraudulent payments due to being lost from the network.There were discussions regarding the need for a capacity increase and the opinions of miners and the broader community. Dashjr disagreed with the claim of broad agreement and highlighted evidence to the contrary. The difference between SPV wallets and light clients was also debated, with suggestions for addressing both in the proposed hard fork.The controversy surrounding the 28-day grace period for implementing the upgrade was discussed, with differing views on the potential impact on users and the feasibility of longer grace periods. Andresen argued that there was no evidence to support the claim that 28 days is insufficient time.The article touched on the blog posts by Andresen, which discussed the constants chosen for the proposed hard fork and their potential impact on static analysis. Dashjr expressed concerns about these changes breaking static analysis and suggested alternative approaches.There were also discussions about economic support for the hard - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Clearing-up-some-misconceptions-about-full-nodes.xml b/static/bitcoin-dev/Feb_2016/combined_Clearing-up-some-misconceptions-about-full-nodes.xml index acad3d1008..f9ba9d95b9 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Clearing-up-some-misconceptions-about-full-nodes.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Clearing-up-some-misconceptions-about-full-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Clearing up some misconceptions about full nodes - 2023-08-01T17:49:10.410886+00:00 + 2025-09-26T15:40:52.480472+00:00 + python-feedgen Sean Greenslade 2016-02-13 06:20:06+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Clearing up some misconceptions about full nodes - 2023-08-01T17:49:10.410886+00:00 + 2025-09-26T15:40:52.480630+00:00 - In a discussion about running full nodes on desktop systems, Patrick Shirkey expressed concerns about the viability of running a full node on a system used for other purposes. He believes that bitcoin-qt consumes a lot of CPU/GPU resources, which can be problematic for users who need to share their system resources between normal desktop workload and running a full node. However, Sean challenged this statement by stating that when running a full node in non-mining mode, the CPU load is fairly light and the GPU is not used at all. Sean also mentioned that Bitcoin is tolerant of nodes entering and leaving the network at will, and even part-time nodes help improve the network's quality.Regarding the move to a 2MB hard fork, every node will need to upgrade. Planning the rollout effect of the hard fork on the entire bitcoin ecosystem is difficult, and relying solely on press releases to encourage users to upgrade their nodes is not viable. Sean emphasized the importance of learning from past experiences and not making hard forks on a whim.Running Bitcoin-qt on a spinning hard disk can cause system responsiveness issues and disrupt the user experience. However, moving the Bitcoin data to an SSD significantly improves the user experience. After initial synchronization, Bitcoin-qt only uses a small amount of CPU to verify new blocks and transactions. Running Bitcoin-qt continuously is less painful than running it occasionally. To run a full node on a small desktop machine, it is recommended to move the Bitcoin data off spinning media onto an SSD, have plenty of RAM, and leave bitcoin-qt running all the time.The number of full nodes worldwide is unknown because not all nodes have open ports that can be probed. While there are around 5,500 full nodes with open ports, there are likely several thousand more nodes with closed ports that cannot be measured. Full nodes play a crucial role in ensuring that all of Bitcoin's rules are being followed, making it trustless and secure. It is recommended to run a full node as a wallet for increased security and privacy. Running a full node as a wallet has become easier with improved user experience and efficiency.The rollout of the 2MB hard fork on the entire bitcoin ecosystem is a complex process that cannot rely solely on press releases to encourage users to upgrade their nodes. The Pulse Audio debacle during the mid-2000s serves as a lesson in this regard. However, enabling users to move their wallets to the new blockchain at their leisure does not cause instant degradation in the ecosystem. Bitcoin "brand" loyalty ensures that users who want to explore the economic potential of the 2MB blocksize can keep their existing funds safe while testing the waters with the new blocksize. Bitcoin remains the only game in town when it comes to scale and a proven history of financial return. As the new blockchain gains momentum, the old one will eventually become obsolete but may also serve as a useful and profitable alternative.A post by Chris Belcher on the bitcoin-dev mailing list debunks some myths about full nodes. The misconception that there are only around 5,500 full nodes worldwide stems from websites that measure open ports for probing. However, not all nodes have open ports, so the actual number is likely much higher. While open-port nodes are useful for measuring bandwidth capacity, closed-port nodes are equally important for trust, security, and privacy. Running a full node as a wallet is in an individual bitcoin user's rational self-interest because it ensures that none of Bitcoin's rules have been broken and increases security against possible attacks. Full node wallets are also the most private way to use Bitcoin, as no other parties learn which Bitcoin addresses belong to the user. To enjoy the benefits of running a full node, users should use it as their wallet on hardware they control. Using cloud servers is not recommended due to concerns about trust, security, and privacy. The user experience of full node software has significantly improved since 2012, and there are several ways to run a full node as a wallet, such as using bitcoin-qt, wallet software backed by a full node, or a lightweight wallet that only connects to the user's full node. 2016-02-13T06:20:06+00:00 + In a discussion about running full nodes on desktop systems, Patrick Shirkey expressed concerns about the viability of running a full node on a system used for other purposes. He believes that bitcoin-qt consumes a lot of CPU/GPU resources, which can be problematic for users who need to share their system resources between normal desktop workload and running a full node. However, Sean challenged this statement by stating that when running a full node in non-mining mode, the CPU load is fairly light and the GPU is not used at all. Sean also mentioned that Bitcoin is tolerant of nodes entering and leaving the network at will, and even part-time nodes help improve the network's quality.Regarding the move to a 2MB hard fork, every node will need to upgrade. Planning the rollout effect of the hard fork on the entire bitcoin ecosystem is difficult, and relying solely on press releases to encourage users to upgrade their nodes is not viable. Sean emphasized the importance of learning from past experiences and not making hard forks on a whim.Running Bitcoin-qt on a spinning hard disk can cause system responsiveness issues and disrupt the user experience. However, moving the Bitcoin data to an SSD significantly improves the user experience. After initial synchronization, Bitcoin-qt only uses a small amount of CPU to verify new blocks and transactions. Running Bitcoin-qt continuously is less painful than running it occasionally. To run a full node on a small desktop machine, it is recommended to move the Bitcoin data off spinning media onto an SSD, have plenty of RAM, and leave bitcoin-qt running all the time.The number of full nodes worldwide is unknown because not all nodes have open ports that can be probed. While there are around 5,500 full nodes with open ports, there are likely several thousand more nodes with closed ports that cannot be measured. Full nodes play a crucial role in ensuring that all of Bitcoin's rules are being followed, making it trustless and secure. It is recommended to run a full node as a wallet for increased security and privacy. Running a full node as a wallet has become easier with improved user experience and efficiency.The rollout of the 2MB hard fork on the entire bitcoin ecosystem is a complex process that cannot rely solely on press releases to encourage users to upgrade their nodes. The Pulse Audio debacle during the mid-2000s serves as a lesson in this regard. However, enabling users to move their wallets to the new blockchain at their leisure does not cause instant degradation in the ecosystem. Bitcoin "brand" loyalty ensures that users who want to explore the economic potential of the 2MB blocksize can keep their existing funds safe while testing the waters with the new blocksize. Bitcoin remains the only game in town when it comes to scale and a proven history of financial return. As the new blockchain gains momentum, the old one will eventually become obsolete but may also serve as a useful and profitable alternative.A post by Chris Belcher on the bitcoin-dev mailing list debunks some myths about full nodes. The misconception that there are only around 5,500 full nodes worldwide stems from websites that measure open ports for probing. However, not all nodes have open ports, so the actual number is likely much higher. While open-port nodes are useful for measuring bandwidth capacity, closed-port nodes are equally important for trust, security, and privacy. Running a full node as a wallet is in an individual bitcoin user's rational self-interest because it ensures that none of Bitcoin's rules have been broken and increases security against possible attacks. Full node wallets are also the most private way to use Bitcoin, as no other parties learn which Bitcoin addresses belong to the user. To enjoy the benefits of running a full node, users should use it as their wallet on hardware they control. Using cloud servers is not recommended due to concerns about trust, security, and privacy. The user experience of full node software has significantly improved since 2012, and there are several ways to run a full node as a wallet, such as using bitcoin-qt, wallet software backed by a full node, or a lightweight wallet that only connects to the user's full node. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Fast-bootstrapping-with-a-pre-generated-UTXO-set-database.xml b/static/bitcoin-dev/Feb_2016/combined_Fast-bootstrapping-with-a-pre-generated-UTXO-set-database.xml index 00114a8a22..89f1faf3d3 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Fast-bootstrapping-with-a-pre-generated-UTXO-set-database.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Fast-bootstrapping-with-a-pre-generated-UTXO-set-database.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fast bootstrapping with a pre-generated UTXO-set database - 2023-08-01T17:53:48.366090+00:00 + 2025-09-26T15:41:30.518311+00:00 + python-feedgen Tier Nolan 2016-02-29 11:49:57+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Fast bootstrapping with a pre-generated UTXO-set database - 2023-08-01T17:53:48.366090+00:00 + 2025-09-26T15:41:30.518472+00:00 - One proposal to enhance the efficiency of bitcoin nodes suggests building the UTXO set in reverse, starting from the newest block and working backwards. The UTXO set consists of unspent transaction outputs (UTXOs) and unfunded transaction inputs (UFTXIs). The proposed procedure involves checking each transaction in a last-to-first order. For each output, it will be checked if it is part of the UFTXI set. If it is not, the signatures will be validated, and the output will be added to the UTXO set. Each input will be added to the UFTXI set. When a transaction is received, all its inputs will be checked. If they are in the UTXO set, the transaction will be marked as confirmed; otherwise, it will be marked as having "unknown inputs." Additionally, a counter will keep track of the number of blocks validated.Transactions with unfunded inputs will be considered validated back to the block they were included in, while transactions will be considered confirmed up to their ancestor with the newest validation time. A reference client can mark transactions with six or more output confirms and 1000 or more input confirms as confirmed. Once the genesis block is reached, all transactions will be marked as confirmed and the second number can be dropped.Another proposal aims to reduce node bootstrap time and network usage by loading a pre-generated UTXO-set datafile. To achieve this, full node clients like Bitcoin-core need to provide a feature that allows freezing the UTXO-set at a specified height and linearizing it in an unspecified data-serializing format. Along with this, a serialized form of the current chain-index up to the specified height will be appended to the pre-generated UTXO-set-datafile. This combined data will be hashed using double SHA256 and signed by a group of developers who sign deterministic builds.To ensure the integrity of developer pubkeys and signatures, methods like the current gitian build must be used. Full node client implementations supporting bootstrapping from a pre-generated UTXO-set should include trusted developer pubkeys, the hash (or hashes) of the pre-generated UTXO-set-datafile(s), and n signatures of the hash(es) from a subset of developers defined earlier.New nodes can download a copy of the pre-generated UTXO-set, verify its hash against the allowed UTXO-sets, and check the ECDSA signatures from various developers. If the user accepts the number of valid signatures, the node can continue bootstrapping from the specified height. Sharing of the pre-generated UTXO-set can be done through CDNs, BitTorrent, or other file hosting solutions. Additionally, it is possible to extend the bitcoin peer-to-peer layer with features to distribute and share such a pre-generated UTXO-set. 2016-02-29T11:49:57+00:00 + One proposal to enhance the efficiency of bitcoin nodes suggests building the UTXO set in reverse, starting from the newest block and working backwards. The UTXO set consists of unspent transaction outputs (UTXOs) and unfunded transaction inputs (UFTXIs). The proposed procedure involves checking each transaction in a last-to-first order. For each output, it will be checked if it is part of the UFTXI set. If it is not, the signatures will be validated, and the output will be added to the UTXO set. Each input will be added to the UFTXI set. When a transaction is received, all its inputs will be checked. If they are in the UTXO set, the transaction will be marked as confirmed; otherwise, it will be marked as having "unknown inputs." Additionally, a counter will keep track of the number of blocks validated.Transactions with unfunded inputs will be considered validated back to the block they were included in, while transactions will be considered confirmed up to their ancestor with the newest validation time. A reference client can mark transactions with six or more output confirms and 1000 or more input confirms as confirmed. Once the genesis block is reached, all transactions will be marked as confirmed and the second number can be dropped.Another proposal aims to reduce node bootstrap time and network usage by loading a pre-generated UTXO-set datafile. To achieve this, full node clients like Bitcoin-core need to provide a feature that allows freezing the UTXO-set at a specified height and linearizing it in an unspecified data-serializing format. Along with this, a serialized form of the current chain-index up to the specified height will be appended to the pre-generated UTXO-set-datafile. This combined data will be hashed using double SHA256 and signed by a group of developers who sign deterministic builds.To ensure the integrity of developer pubkeys and signatures, methods like the current gitian build must be used. Full node client implementations supporting bootstrapping from a pre-generated UTXO-set should include trusted developer pubkeys, the hash (or hashes) of the pre-generated UTXO-set-datafile(s), and n signatures of the hash(es) from a subset of developers defined earlier.New nodes can download a copy of the pre-generated UTXO-set, verify its hash against the allowed UTXO-sets, and check the ECDSA signatures from various developers. If the user accepts the number of valid signatures, the node can continue bootstrapping from the specified height. Sharing of the pre-generated UTXO-set can be done through CDNs, BitTorrent, or other file hosting solutions. Additionally, it is possible to extend the bitcoin peer-to-peer layer with features to distribute and share such a pre-generated UTXO-set. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Hardfork-bit-BIP.xml b/static/bitcoin-dev/Feb_2016/combined_Hardfork-bit-BIP.xml index 1d48de4774..3d31ccb96d 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Hardfork-bit-BIP.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Hardfork-bit-BIP.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hardfork bit BIP - 2023-08-01T17:44:22.020333+00:00 + 2025-09-26T15:41:13.611509+00:00 + python-feedgen Anthony Towns 2016-02-08 02:44:32+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Hardfork bit BIP - 2023-08-01T17:44:22.020333+00:00 + 2025-09-26T15:41:13.611664+00:00 - The proposal aims to address the risks associated with hardforks in the Bitcoin blockchain. Hardforks are considered difficult and risky due to the need for support from miners and supermajority support from the Bitcoin economy. This level of support is not sufficient to safely introduce hardforks. Moreover, full nodes and Simplified Payment Verification (SPV) nodes following the original consensus rules may not be aware of a hardfork's deployment. This lack of awareness can lead users to unknowingly accept devalued legacy tokens and potentially revert back to the original chain if it grows faster than the new one.To mitigate these risks, the proposal suggests a change to the semantics of the sign bit in the "version" field of Bitcoin block headers. This change introduces an explicit "point of no return" in the blockchain. The mechanism involves using the sign bit in the nVersion field as the hardfork bit. Blocks with this header bit set to 1 would be considered invalid. For a planned hardfork, there must be one and only one flag block that serves as the "point of no return." This flag block is determined either by block height or as the first block with GetMedianTimePast() greater than a specified threshold.The construction of the flag block is crucial. Nodes adhering to the original consensus rules must reject it, while nodes following the new consensus rules must reject any block that is not a flag block when it should be. To avoid confusion and unexpected behavior, a flag block should indicate the deployment of only one hardfork. Additionally, a hardfork proposal must ensure that its flag block threshold does not clash with other ongoing hardfork proposals.When a flag block for an unknown hardfork is discovered on the network, full nodes and SPV nodes should alert their users and potentially cease accepting or sending transactions. The proposed mechanism is compatible with BIP9, which employs the version bits mechanism to gauge miner support for a hardfork proposal and determine the height or time threshold of the flag block.Once the flag block is generated, a miner can choose to support either the original rules or the new rules, but not both simultaneously. This mechanism aims to provide a clearer indication of hardfork deployments in the Bitcoin blockchain while reducing the associated risks. 2016-02-08T02:44:32+00:00 + The proposal aims to address the risks associated with hardforks in the Bitcoin blockchain. Hardforks are considered difficult and risky due to the need for support from miners and supermajority support from the Bitcoin economy. This level of support is not sufficient to safely introduce hardforks. Moreover, full nodes and Simplified Payment Verification (SPV) nodes following the original consensus rules may not be aware of a hardfork's deployment. This lack of awareness can lead users to unknowingly accept devalued legacy tokens and potentially revert back to the original chain if it grows faster than the new one.To mitigate these risks, the proposal suggests a change to the semantics of the sign bit in the "version" field of Bitcoin block headers. This change introduces an explicit "point of no return" in the blockchain. The mechanism involves using the sign bit in the nVersion field as the hardfork bit. Blocks with this header bit set to 1 would be considered invalid. For a planned hardfork, there must be one and only one flag block that serves as the "point of no return." This flag block is determined either by block height or as the first block with GetMedianTimePast() greater than a specified threshold.The construction of the flag block is crucial. Nodes adhering to the original consensus rules must reject it, while nodes following the new consensus rules must reject any block that is not a flag block when it should be. To avoid confusion and unexpected behavior, a flag block should indicate the deployment of only one hardfork. Additionally, a hardfork proposal must ensure that its flag block threshold does not clash with other ongoing hardfork proposals.When a flag block for an unknown hardfork is discovered on the network, full nodes and SPV nodes should alert their users and potentially cease accepting or sending transactions. The proposed mechanism is compatible with BIP9, which employs the version bits mechanism to gauge miner support for a hardfork proposal and determine the height or time threshold of the flag block.Once the flag block is generated, a miner can choose to support either the original rules or the new rules, but not both simultaneously. This mechanism aims to provide a clearer indication of hardfork deployments in the Bitcoin blockchain while reducing the associated risks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_INV-overhead-and-batched-INVs-to-reduce-full-node-traffic.xml b/static/bitcoin-dev/Feb_2016/combined_INV-overhead-and-batched-INVs-to-reduce-full-node-traffic.xml index 3a5098ec75..dcddd09175 100644 --- a/static/bitcoin-dev/Feb_2016/combined_INV-overhead-and-batched-INVs-to-reduce-full-node-traffic.xml +++ b/static/bitcoin-dev/Feb_2016/combined_INV-overhead-and-batched-INVs-to-reduce-full-node-traffic.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - INV overhead and batched INVs to reduce full node traffic - 2023-08-01T17:53:01.494130+00:00 + 2025-09-26T15:41:22.068303+00:00 + python-feedgen Jonathan Toomim 2016-02-27 09:08:22+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - INV overhead and batched INVs to reduce full node traffic - 2023-08-01T17:53:01.494130+00:00 + 2025-09-26T15:41:22.068486+00:00 - One idea to reduce the size of transaction hashes is to use a 4 to 6 byte shorthash, which would have a low chance of resulting in collision with another transaction in a large mempool. To protect against potential attacks, different salt values can be set up for each connection and a salted hash can be used instead of the full thing. This technique could potentially reduce INV traffic by 5-8x in the asymptotic case, or maybe 2-3x for a realistic case. The additional memory overhead per peer per tx would be about 12 bytes, but it would save up to 28 bytes per peer*tx of network bandwidth.In an email exchange on Feb 25, 2016, Gregory Maxwell reported that the batching feature in versions 0.10 and 0.12 of a certain software was temporarily affected, but has since been fully functional again. This feature enables the ability to batch many transactions per INV effectively. The response was prompted by examination of 0.11-series versions which rarely send out INV batches. In this examination, it was noted that about 85% of the packets had a single hash.Jonathan Toomim, a Bitcoin developer, suggested implementing an option for batched INV (inventory) on the Bitcoin network that would increase efficiency by including the hashes for two transactions in one IP packet. This would increase the INV size to 229 bytes for 64 bytes of payload, resulting in an 88.8% marginal efficiency increase for each hash after the first.He believed waiting and accumulating several hashes together before sending as a batched INV could reduce Bitcoin node traffic by a factor of 2. However, this suggestion was found to have already been implemented since the early days of Bitcoin. The batching feature was temporarily affected between the 0.10 and 0.12 versions but has been fully functional again, with one INV now managing to batch many transactions effectively. The average batching size is about 5 seconds long and usually contains around 10 transactions per INV, as seen from debug measurements. While tweaking the system may improve efficiency, it is not expected to change the asymptotic efficiency of the network.The INV scheme used by Bitcoin is very inefficient due to the overheads of TCP, IP, ethernet and ACKs. Each INV takes up to 193 bytes, with only 16.5% efficiency for each of the payloads. An improvement could be the implementation of batched INVs where the hashes for two transactions per IP packet instead of one can be included. This would increase the INV size to 229 bytes for 64 bytes of payload (88.8% efficiency) after the first hash. Waiting a short period of time to accumulate several hashes together and send them could reduce the traffic of running bitcoin nodes by a factor of 2 or more. However, if too many people used it, it could slow down the propagation of transactions across the bitcoin network slightly. This could be mitigated by choosing a different batch size for each peer based on their preferences. 2016-02-27T09:08:22+00:00 + One idea to reduce the size of transaction hashes is to use a 4 to 6 byte shorthash, which would have a low chance of resulting in collision with another transaction in a large mempool. To protect against potential attacks, different salt values can be set up for each connection and a salted hash can be used instead of the full thing. This technique could potentially reduce INV traffic by 5-8x in the asymptotic case, or maybe 2-3x for a realistic case. The additional memory overhead per peer per tx would be about 12 bytes, but it would save up to 28 bytes per peer*tx of network bandwidth.In an email exchange on Feb 25, 2016, Gregory Maxwell reported that the batching feature in versions 0.10 and 0.12 of a certain software was temporarily affected, but has since been fully functional again. This feature enables the ability to batch many transactions per INV effectively. The response was prompted by examination of 0.11-series versions which rarely send out INV batches. In this examination, it was noted that about 85% of the packets had a single hash.Jonathan Toomim, a Bitcoin developer, suggested implementing an option for batched INV (inventory) on the Bitcoin network that would increase efficiency by including the hashes for two transactions in one IP packet. This would increase the INV size to 229 bytes for 64 bytes of payload, resulting in an 88.8% marginal efficiency increase for each hash after the first.He believed waiting and accumulating several hashes together before sending as a batched INV could reduce Bitcoin node traffic by a factor of 2. However, this suggestion was found to have already been implemented since the early days of Bitcoin. The batching feature was temporarily affected between the 0.10 and 0.12 versions but has been fully functional again, with one INV now managing to batch many transactions effectively. The average batching size is about 5 seconds long and usually contains around 10 transactions per INV, as seen from debug measurements. While tweaking the system may improve efficiency, it is not expected to change the asymptotic efficiency of the network.The INV scheme used by Bitcoin is very inefficient due to the overheads of TCP, IP, ethernet and ACKs. Each INV takes up to 193 bytes, with only 16.5% efficiency for each of the payloads. An improvement could be the implementation of batched INVs where the hashes for two transactions per IP packet instead of one can be included. This would increase the INV size to 229 bytes for 64 bytes of payload (88.8% efficiency) after the first hash. Waiting a short period of time to accumulate several hashes together and send them could reduce the traffic of running bitcoin nodes by a factor of 2 or more. However, if too many people used it, it could slow down the propagation of transactions across the bitcoin network slightly. This could be mitigated by choosing a different batch size for each peer based on their preferences. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Multi-Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml b/static/bitcoin-dev/Feb_2016/combined_Multi-Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml index 40c9b15e70..2d1111407b 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Multi-Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Multi-Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Multi-Stage Merge-Mine Headers Hard-Fork BIP - 2023-08-01T17:52:13.773992+00:00 + 2025-09-26T15:41:17.837329+00:00 + python-feedgen James Hilliard 2016-02-24 11:37:10+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Multi-Stage Merge-Mine Headers Hard-Fork BIP - 2023-08-01T17:52:13.773992+00:00 + 2025-09-26T15:41:17.837509+00:00 - A proposal for a hard fork has been made, suggesting a two-stage process with a single lock-in period to implement changes to the Bitcoin header format. The goal of this hard fork is to kill off the previous chain by artificially increasing the network difficulty on the original chain. The first stage of the hard fork is designed to make it difficult to mine the 2016 blocks needed to trigger a difficulty adjustment. This stage aims to make it clear to unupgraded clients that they need to upgrade. The second stage, called the headers change stage, makes the header format incompatible with merge mining. This stage is activated approximately 50,000 blocks after the Merge Mine Stage and at the start of the 2016 block difficulty boundary.There are serious issues with pooled mining, such as block withhold attacks, which can only be fixed by making major changes to the headers format. These desirable changes can only be made in a non-merge mine compatible way. If a way to permanently disable the original chain is not implemented, there is a high risk of there being two viable chains.To activate the fork, a block version flag will be used. This flag locks in both stages simultaneously when 3900 out of the previous 4032 blocks have the version flag set. The initial hard fork is implemented using a merge mine that requires the original pre-fork chain to be mined with a generation transaction that creates no new coins and does not contain any transactions. Additionally, a consensus rule requires manipulation of ntime on the original chain to artificially increase difficulty and hold back the original chain so that all non-upgraded clients can never catch up with current time. The artificial ntime is implemented as a consensus rule for blocks in the new chain.The proposal also mentions the possibility of an attack called the "nuclear option," which could potentially knock out the main chain. To prevent this, the median time past will increase very slowly, needing to increase by 1 every 6th block. This caps the update rate and gives an increase of 4X every doubling. The new headers will not meet the difficulty, so they will likely repeat the last header. If the bitcoin chain stays at a constant difficulty, each quadrupling will take more time. After 2 weeks, there will be a 4X difficulty increase (2 weeks per difficulty period), after 10 weeks, a 16X difficulty increase (8 weeks per difficulty period), and after 42 weeks, a 256X difficulty increase (32 weeks per difficulty period).It is important to note that the proposal is still in the draft stage, and a reference implementation has yet to be created. 2016-02-24T11:37:10+00:00 + A proposal for a hard fork has been made, suggesting a two-stage process with a single lock-in period to implement changes to the Bitcoin header format. The goal of this hard fork is to kill off the previous chain by artificially increasing the network difficulty on the original chain. The first stage of the hard fork is designed to make it difficult to mine the 2016 blocks needed to trigger a difficulty adjustment. This stage aims to make it clear to unupgraded clients that they need to upgrade. The second stage, called the headers change stage, makes the header format incompatible with merge mining. This stage is activated approximately 50,000 blocks after the Merge Mine Stage and at the start of the 2016 block difficulty boundary.There are serious issues with pooled mining, such as block withhold attacks, which can only be fixed by making major changes to the headers format. These desirable changes can only be made in a non-merge mine compatible way. If a way to permanently disable the original chain is not implemented, there is a high risk of there being two viable chains.To activate the fork, a block version flag will be used. This flag locks in both stages simultaneously when 3900 out of the previous 4032 blocks have the version flag set. The initial hard fork is implemented using a merge mine that requires the original pre-fork chain to be mined with a generation transaction that creates no new coins and does not contain any transactions. Additionally, a consensus rule requires manipulation of ntime on the original chain to artificially increase difficulty and hold back the original chain so that all non-upgraded clients can never catch up with current time. The artificial ntime is implemented as a consensus rule for blocks in the new chain.The proposal also mentions the possibility of an attack called the "nuclear option," which could potentially knock out the main chain. To prevent this, the median time past will increase very slowly, needing to increase by 1 every 6th block. This caps the update rate and gives an increase of 4X every doubling. The new headers will not meet the difficulty, so they will likely repeat the last header. If the bitcoin chain stays at a constant difficulty, each quadrupling will take more time. After 2 weeks, there will be a 4X difficulty increase (2 weeks per difficulty period), after 10 weeks, a 16X difficulty increase (8 weeks per difficulty period), and after 42 weeks, a 256X difficulty increase (32 weeks per difficulty period).It is important to note that the proposal is still in the draft stage, and a reference implementation has yet to be created. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_On-Hardforks-in-the-Context-of-SegWit.xml b/static/bitcoin-dev/Feb_2016/combined_On-Hardforks-in-the-Context-of-SegWit.xml index ae83831e32..6929757306 100644 --- a/static/bitcoin-dev/Feb_2016/combined_On-Hardforks-in-the-Context-of-SegWit.xml +++ b/static/bitcoin-dev/Feb_2016/combined_On-Hardforks-in-the-Context-of-SegWit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On Hardforks in the Context of SegWit - 2023-08-01T17:47:24.948210+00:00 + 2025-09-26T15:41:26.295576+00:00 + python-feedgen Anthony Towns 2016-02-10 05:16:56+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - On Hardforks in the Context of SegWit - 2023-08-01T17:47:24.948210+00:00 + 2025-09-26T15:41:26.295730+00:00 - Bitcoin developer Matt Corallo has proposed changes to increase the extranonce space in mining, which would allow for more transaction data in the blockchain. He suggests passing a mask of nonce bytes to ASICs and rearranging the block to include additional nonce space. However, these changes are incompatible with Luke-Jr's soft-hardfork approach. Corallo also recommends making merge-mining easier and splitting the proof of work between miners and pool operators to reduce hard forks visible to lightweight clients.The Bitcoin community is discussing increasing the extranonce space to simplify mining control and move complexity back into Bitcoin Core. The proposal includes adding nonce space in the first compression function and increasing the minimum difficulty. However, some believe this adds unnecessary complexity. These changes would enable greater ASIC speeds and increased dynamic extranonce space.In an email thread, Corallo proposes increasing the extranonce space available for ASICs by setting a maximum number of bytes. Changing the minimum difficulty to six 0-bytes would reserve more space for extranonce rolling. Luke agrees with the proposal and sees no reason not to increase the minimum difficulty at the same time.The discussion also explores potential changes to Bitcoin mining hardware to reduce required logic. Suggestions include allowing the first four bytes of the previous block hash field to contain any value, which could optimize brute forcing the SHA256 midstate. However, there are concerns about strong incentives to use the version field as nonce space. Another suggestion is using leading non-zero bytes of the prevhash as additional nonce. The author concludes that closer examination of midstate optimization is necessary.A hard fork proposal is being discussed in the context of segwit. The proposal includes changing the segregated witness discount from 75% to 50%, setting the block size limit to 1.5MB, and allowing for a maximum block size of 3MB with a "network-upgraded" block size of roughly 2.1MB. The aim is to decrease the worst-case scenario while keeping the total size in line with network capacity. The proposal also addresses cost and validation concerns by limiting non-segwit inputs and potentially implementing a per-transaction limit for MAX_BLOCK_SIGOPS. Additionally, it suggests allowing any value in the first four bytes of the previous block hash field to make hardware production more competitive.To prevent significant cost blowups in transaction validation, there are restrictions on non-segwit inputs. However, this move has raised concerns about disrupting services and invalidating time-locked transactions. Other limitations, such as scriptPubKeys being limited to 100 bytes and no OP_CODESEPARATOR allowed, have also raised concerns regarding native multisig.In another email thread, Corallo proposes a hard fork outline in the context of segwit. The segregated witness discount would be changed from 75% to 50%, and the block size limit set to 1.5MB. This would result in a maximum block size of 3MB and a "network-upgraded" block size of roughly 2.1MB. Additional limits would be placed on the size of non-segwit transactions, and the first four bytes of the previous block hash field could contain any value. The proposal aims to balance efficient block space usage, low fees, and network security.The author argues that Bitcoin scaling is not an emergency and highlights mining centralization and privacy as more pressing concerns. They suggest a hard fork could be used to enforce decentralized mining pools and express concern about rising transaction fees. They provide links for further information on what constitutes a qualifying emergency and suggestions for addressing mining centralization.In a separate discussion, Simon Liu questions the rationale for offering a discount from segregated witness. Peter Todd responds that UTXO set space is more expensive for the network, leading to the discount. He emphasizes the need to consider engineering decisions and proposes a miner vote threshold for hard forks.The segregated witness discount has been changed from 75% to 50%, and the block size limit set at 1.5MB, resulting in a maximum block size of 3MB. The purpose is to offer a discount on script data while maintaining a limited maximum block size. The rationale for the discount and specific boundary limits are unclear. These changes aim to balance efficient block space usage, low fees, and network security.Bitcoin developers are discussing a hard fork to address mining centralization and privacy challenges. Hard forks should only occur in response to a major crisis agreed upon by all participants. The community has unified around roughly 2MB of transactions per block via Segregated Witness or a hard fork. Technical planning is crucial to avoid risks and protect value. Suggestions include adding decentralization pressure and switching MAX_BLOCK_SIGOPS to a per-transaction limit. Hard forks must address real threats facing Bitcoin.The Bitcoin community has unified around roughly 2MB of transactions per block via Segregated Witness or a hard fork. Implementing SegWit and planning for a safe hard fork is essential. Proposed changes include changing the segregated witness 2016-02-10T05:16:56+00:00 + Bitcoin developer Matt Corallo has proposed changes to increase the extranonce space in mining, which would allow for more transaction data in the blockchain. He suggests passing a mask of nonce bytes to ASICs and rearranging the block to include additional nonce space. However, these changes are incompatible with Luke-Jr's soft-hardfork approach. Corallo also recommends making merge-mining easier and splitting the proof of work between miners and pool operators to reduce hard forks visible to lightweight clients.The Bitcoin community is discussing increasing the extranonce space to simplify mining control and move complexity back into Bitcoin Core. The proposal includes adding nonce space in the first compression function and increasing the minimum difficulty. However, some believe this adds unnecessary complexity. These changes would enable greater ASIC speeds and increased dynamic extranonce space.In an email thread, Corallo proposes increasing the extranonce space available for ASICs by setting a maximum number of bytes. Changing the minimum difficulty to six 0-bytes would reserve more space for extranonce rolling. Luke agrees with the proposal and sees no reason not to increase the minimum difficulty at the same time.The discussion also explores potential changes to Bitcoin mining hardware to reduce required logic. Suggestions include allowing the first four bytes of the previous block hash field to contain any value, which could optimize brute forcing the SHA256 midstate. However, there are concerns about strong incentives to use the version field as nonce space. Another suggestion is using leading non-zero bytes of the prevhash as additional nonce. The author concludes that closer examination of midstate optimization is necessary.A hard fork proposal is being discussed in the context of segwit. The proposal includes changing the segregated witness discount from 75% to 50%, setting the block size limit to 1.5MB, and allowing for a maximum block size of 3MB with a "network-upgraded" block size of roughly 2.1MB. The aim is to decrease the worst-case scenario while keeping the total size in line with network capacity. The proposal also addresses cost and validation concerns by limiting non-segwit inputs and potentially implementing a per-transaction limit for MAX_BLOCK_SIGOPS. Additionally, it suggests allowing any value in the first four bytes of the previous block hash field to make hardware production more competitive.To prevent significant cost blowups in transaction validation, there are restrictions on non-segwit inputs. However, this move has raised concerns about disrupting services and invalidating time-locked transactions. Other limitations, such as scriptPubKeys being limited to 100 bytes and no OP_CODESEPARATOR allowed, have also raised concerns regarding native multisig.In another email thread, Corallo proposes a hard fork outline in the context of segwit. The segregated witness discount would be changed from 75% to 50%, and the block size limit set to 1.5MB. This would result in a maximum block size of 3MB and a "network-upgraded" block size of roughly 2.1MB. Additional limits would be placed on the size of non-segwit transactions, and the first four bytes of the previous block hash field could contain any value. The proposal aims to balance efficient block space usage, low fees, and network security.The author argues that Bitcoin scaling is not an emergency and highlights mining centralization and privacy as more pressing concerns. They suggest a hard fork could be used to enforce decentralized mining pools and express concern about rising transaction fees. They provide links for further information on what constitutes a qualifying emergency and suggestions for addressing mining centralization.In a separate discussion, Simon Liu questions the rationale for offering a discount from segregated witness. Peter Todd responds that UTXO set space is more expensive for the network, leading to the discount. He emphasizes the need to consider engineering decisions and proposes a miner vote threshold for hard forks.The segregated witness discount has been changed from 75% to 50%, and the block size limit set at 1.5MB, resulting in a maximum block size of 3MB. The purpose is to offer a discount on script data while maintaining a limited maximum block size. The rationale for the discount and specific boundary limits are unclear. These changes aim to balance efficient block space usage, low fees, and network security.Bitcoin developers are discussing a hard fork to address mining centralization and privacy challenges. Hard forks should only occur in response to a major crisis agreed upon by all participants. The community has unified around roughly 2MB of transactions per block via Segregated Witness or a hard fork. Technical planning is crucial to avoid risks and protect value. Suggestions include adding decentralization pressure and switching MAX_BLOCK_SIGOPS to a per-transaction limit. Hard forks must address real threats facing Bitcoin.The Bitcoin community has unified around roughly 2MB of transactions per block via Segregated Witness or a hard fork. Implementing SegWit and planning for a safe hard fork is essential. Proposed changes include changing the segregated witness - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Pre-BIP-Growth-Soft-hardfork.xml b/static/bitcoin-dev/Feb_2016/combined_Pre-BIP-Growth-Soft-hardfork.xml index 646cd12e12..afc6e65ae6 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Pre-BIP-Growth-Soft-hardfork.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Pre-BIP-Growth-Soft-hardfork.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pre-BIP Growth Soft-hardfork - 2023-08-01T17:46:45.370934+00:00 + 2025-09-26T15:41:03.045567+00:00 + python-feedgen jl2012 at xbt.hk 2016-02-07 17:53:53+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Pre-BIP Growth Soft-hardfork - 2023-08-01T17:46:45.370934+00:00 + 2025-09-26T15:41:03.045717+00:00 - Luke Dashjr has shared a draft BIP for the Pre-BIP Growth Soft-hardfork. This BIP aims to implement proper merge-mining, as suggested by Satoshi, in order to expand the nonce space that miners can scan in-chip. It also proposes a method for safely deploying hardforks without leaving old nodes vulnerable to attack. Although the initial implementation of the BIP may be challenging, it will facilitate future hardforks.The proposal suggests including the median timestamp of the past 11 blocks after the block height in coinbase, which would serve as an activation threshold for consensus rule changes. Additionally, the BIP recommends treating witness commitment as a merge mined commitment. Miners are encouraged to ensure that the hardfork is accepted by the supermajority of the economy.The email accompanying the draft BIP discusses a specific implementation of the "nuclear option" soft fork. This involves adding fields to header 3 that can be expanded later, saving the need to immediately convert the merkle tree into a sum tree. The proposal also suggests having dedicated hard fork and soft fork counters, as well as a field for parallel soft forks. In response to hard forks, nodes would stall the chain, and the hard fork counter would determine if this action should be taken for all new hard forks going forward. If a hard fork occurs, transaction processing would be halted, and users informed. Non-upgraded miners could blacklist the hard forking block and continue mining on their own chain, while still giving users the option to accept or reject the hard fork.The author of the BIP wrote a draft a year ago, which aimed to achieve important objectives such as merge-mining, nonce space expansion, and safe deployment of hardforks. The author plans to revise and complete the BIP soon and welcomes suggestions for improvement. The link to the BIP can be found on GitHub. 2016-02-07T17:53:53+00:00 + Luke Dashjr has shared a draft BIP for the Pre-BIP Growth Soft-hardfork. This BIP aims to implement proper merge-mining, as suggested by Satoshi, in order to expand the nonce space that miners can scan in-chip. It also proposes a method for safely deploying hardforks without leaving old nodes vulnerable to attack. Although the initial implementation of the BIP may be challenging, it will facilitate future hardforks.The proposal suggests including the median timestamp of the past 11 blocks after the block height in coinbase, which would serve as an activation threshold for consensus rule changes. Additionally, the BIP recommends treating witness commitment as a merge mined commitment. Miners are encouraged to ensure that the hardfork is accepted by the supermajority of the economy.The email accompanying the draft BIP discusses a specific implementation of the "nuclear option" soft fork. This involves adding fields to header 3 that can be expanded later, saving the need to immediately convert the merkle tree into a sum tree. The proposal also suggests having dedicated hard fork and soft fork counters, as well as a field for parallel soft forks. In response to hard forks, nodes would stall the chain, and the hard fork counter would determine if this action should be taken for all new hard forks going forward. If a hard fork occurs, transaction processing would be halted, and users informed. Non-upgraded miners could blacklist the hard forking block and continue mining on their own chain, while still giving users the option to accept or reject the hard fork.The author of the BIP wrote a draft a year ago, which aimed to achieve important objectives such as merge-mining, nonce space expansion, and safe deployment of hardforks. The author plans to revise and complete the BIP soon and welcomes suggestions for improvement. The link to the BIP can be found on GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Question-regarding-Confidential-Transactions.xml b/static/bitcoin-dev/Feb_2016/combined_Question-regarding-Confidential-Transactions.xml index be03a68de3..93b6e5bf4f 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Question-regarding-Confidential-Transactions.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Question-regarding-Confidential-Transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Question regarding Confidential Transactions - 2023-08-01T17:48:08.274738+00:00 + 2025-09-26T15:41:05.159068+00:00 + python-feedgen Adam Gibson 2016-02-13 16:55:31+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Question regarding Confidential Transactions - 2023-08-01T17:48:08.275738+00:00 + 2025-09-26T15:41:05.159202+00:00 - In an email conversation between Henning Kopp and Jeremy Papp, they discuss the inclusion of the blinding factor in range proofs for confidential transactions. They explore various possibilities, such as encrypting the blinding factor with the receiver's public key or using shared secret generation. They note that ECC works differently from RSA, and instead of directly encrypting with a public key, a shared secret is generated using ECDH. Adding extraneous data is not a major issue since it would likely require segwit. However, it is important to consider that the sender would need to know the recipient's unhashed public key, which is not commonly used in Bitcoin transactions due to potential vulnerabilities to quantum computers. The conversation delves into technical aspects of blinding factors and shared secrets in Bitcoin transactions.The discussion continues in an email exchange where Jeremy suggests including the blinding factor in the extra data incorporated into the ring signatures used in the range proof. He considers the range proof optional for single output transactions, as there is only one possible value that can work. However, he is uncertain about how to transmit the blinding factor. Both Jeremy and Henning agree that adding extraneous data is not a significant concern, given that its usage would likely require segwit. They also envision protecting the blinding factor from outside examination through some form of shared secret generation. However, this approach necessitates the sender knowing the recipient's unhashed public key, which differs from the usual practice in Bitcoin transactions. Henning raises a question about how the receiver can verify the amount sent to them and suggests that the receiver needs to learn the blinding factor to reveal the commit off-chain. Henning is associated with Ulm University in Germany.In response to a user's query on Bitcoin development, the responder explains that the blinding factor would be included in the extra data embedded in the ring signatures used in the range proof for confidential transactions. They highlight that the range proof is optional for single output transactions and would require segwit if utilized. Adding extraneous data is not a significant concern in this context. The responder suggests that the blinding factor would likely be safeguarded from external scrutiny through shared secret generation. However, this would entail the sender knowing the recipient's unhashed public key, which deviates from the common practice of using hashed keys. The responder expresses uncertainty about any shared secret schemes applicable to hashed keys.Henning Kopp, a researcher at Ulm University in Germany, seeks clarification on confidential transactions. He raises a question regarding how the receiver can verify the amount sent to them when the sender creates a confidential transaction and accurately selects the blinding values. While anyone can still confirm the validity of the transaction as it remains publicly verifiable, Henning believes that the receiver needs to learn the blinding factor to reveal the commit off-chain. However, he requests further explanation regarding the process. 2016-02-13T16:55:31+00:00 + In an email conversation between Henning Kopp and Jeremy Papp, they discuss the inclusion of the blinding factor in range proofs for confidential transactions. They explore various possibilities, such as encrypting the blinding factor with the receiver's public key or using shared secret generation. They note that ECC works differently from RSA, and instead of directly encrypting with a public key, a shared secret is generated using ECDH. Adding extraneous data is not a major issue since it would likely require segwit. However, it is important to consider that the sender would need to know the recipient's unhashed public key, which is not commonly used in Bitcoin transactions due to potential vulnerabilities to quantum computers. The conversation delves into technical aspects of blinding factors and shared secrets in Bitcoin transactions.The discussion continues in an email exchange where Jeremy suggests including the blinding factor in the extra data incorporated into the ring signatures used in the range proof. He considers the range proof optional for single output transactions, as there is only one possible value that can work. However, he is uncertain about how to transmit the blinding factor. Both Jeremy and Henning agree that adding extraneous data is not a significant concern, given that its usage would likely require segwit. They also envision protecting the blinding factor from outside examination through some form of shared secret generation. However, this approach necessitates the sender knowing the recipient's unhashed public key, which differs from the usual practice in Bitcoin transactions. Henning raises a question about how the receiver can verify the amount sent to them and suggests that the receiver needs to learn the blinding factor to reveal the commit off-chain. Henning is associated with Ulm University in Germany.In response to a user's query on Bitcoin development, the responder explains that the blinding factor would be included in the extra data embedded in the ring signatures used in the range proof for confidential transactions. They highlight that the range proof is optional for single output transactions and would require segwit if utilized. Adding extraneous data is not a significant concern in this context. The responder suggests that the blinding factor would likely be safeguarded from external scrutiny through shared secret generation. However, this would entail the sender knowing the recipient's unhashed public key, which deviates from the common practice of using hashed keys. The responder expresses uncertainty about any shared secret schemes applicable to hashed keys.Henning Kopp, a researcher at Ulm University in Germany, seeks clarification on confidential transactions. He raises a question regarding how the receiver can verify the amount sent to them when the sender creates a confidential transaction and accurately selects the blinding values. While anyone can still confirm the validity of the transaction as it remains publicly verifiable, Henning believes that the receiver needs to learn the blinding factor to reveal the commit off-chain. However, he requests further explanation regarding the process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml b/static/bitcoin-dev/Feb_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml index 704bd747a9..05e1bc1300 100644 --- a/static/bitcoin-dev/Feb_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml +++ b/static/bitcoin-dev/Feb_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC for BIP: Best Practices for Heterogeneous Input Script Transactions - 2023-08-01T17:49:34.520202+00:00 + 2025-09-26T15:41:07.271107+00:00 + python-feedgen Luke Dashjr 2016-05-26 00:00:37+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - RFC for BIP: Best Practices for Heterogeneous Input Script Transactions - 2023-08-01T17:49:34.520202+00:00 + 2025-09-26T15:41:07.271297+00:00 - On May 19, 2016, Kristov Atlas introduced a Bitcoin Improvement Proposal (BIP) known as BIP 126. This proposal suggests the implementation of Heterogenous Input Script Transactions (HITs), which allow for transactions to have multiple inputs with different scripts. It is important to note that transactions are not associated with specific Bitcoin addresses, but rather with inputs that spend from Unspent Transaction Outputs (UTXOs). Furthermore, it is uncommon for inputs to have identical scripts.The draft proposal titled "Best Practices for Heterogeneous Input Script Transactions (HITs)" aims to mitigate the negative impact on privacy and user protection protocols when transactions involve inputs with different scripts. The document outlines a set of guidelines to address the privacy concerns associated with HITs, while maximizing the effectiveness of user protection protocols. To achieve this, the specification proposes two forms of HITs: Standard form and alternate form.Standard form HIT transactions must adhere to specific rules. These rules include having an equal number of unique input/output scripts, ensuring all output scripts are unique, requiring at least one pair of outputs with equal value, and making sure the largest output in the transaction belongs to a set containing at least two identically-sized outputs. These requirements serve various purposes such as preventing address reuse, limiting the growth of the UTXO set, and optimizing behavior to make intentional HITs resemble unavoidable HITs.In cases where standard form HITs are not feasible, such as when HITs are unavoidable or the user does not possess sets of UTXOs with identical scripts, alternate form HITs can be employed. A compliant implementation can construct a transaction by finding the smallest combination of inputs whose value is equal to or greater than the desired spend. These inputs are then added to the transaction along with a spend output and change output. The process is repeated to create a second spend output and change output, with the change outputs adjusted as necessary to cover the transaction fee. The aim of this approach is to maximize the effectiveness of user-protecting protocols, minimize the adverse consequences of unavoidable HITs, and limit the impact on UTXO set growth.Non-compliant heterogenous input script transactions may be created if a user wishes to create an output larger than half the total size of their spendable outputs or if their inputs are not distributed in a manner that allows for the completion of the alternate form procedure.In conclusion, this document proposes a set of best practice guidelines to minimize the adverse privacy consequences of creating transactions with inputs composed of different scripts. The guidelines aim to maximize the effectiveness of protection protocols, minimize the negative consequences of unavoidable HITs, and limit the effect on the UTXO set growth. It defines terms related to HITs and provides rules for both standard form and alternate form HITs. The recommendations aim to enhance privacy and optimize the usage of HITs while ensuring compliance with the proposed guidelines. 2016-05-26T00:00:37+00:00 + On May 19, 2016, Kristov Atlas introduced a Bitcoin Improvement Proposal (BIP) known as BIP 126. This proposal suggests the implementation of Heterogenous Input Script Transactions (HITs), which allow for transactions to have multiple inputs with different scripts. It is important to note that transactions are not associated with specific Bitcoin addresses, but rather with inputs that spend from Unspent Transaction Outputs (UTXOs). Furthermore, it is uncommon for inputs to have identical scripts.The draft proposal titled "Best Practices for Heterogeneous Input Script Transactions (HITs)" aims to mitigate the negative impact on privacy and user protection protocols when transactions involve inputs with different scripts. The document outlines a set of guidelines to address the privacy concerns associated with HITs, while maximizing the effectiveness of user protection protocols. To achieve this, the specification proposes two forms of HITs: Standard form and alternate form.Standard form HIT transactions must adhere to specific rules. These rules include having an equal number of unique input/output scripts, ensuring all output scripts are unique, requiring at least one pair of outputs with equal value, and making sure the largest output in the transaction belongs to a set containing at least two identically-sized outputs. These requirements serve various purposes such as preventing address reuse, limiting the growth of the UTXO set, and optimizing behavior to make intentional HITs resemble unavoidable HITs.In cases where standard form HITs are not feasible, such as when HITs are unavoidable or the user does not possess sets of UTXOs with identical scripts, alternate form HITs can be employed. A compliant implementation can construct a transaction by finding the smallest combination of inputs whose value is equal to or greater than the desired spend. These inputs are then added to the transaction along with a spend output and change output. The process is repeated to create a second spend output and change output, with the change outputs adjusted as necessary to cover the transaction fee. The aim of this approach is to maximize the effectiveness of user-protecting protocols, minimize the adverse consequences of unavoidable HITs, and limit the impact on UTXO set growth.Non-compliant heterogenous input script transactions may be created if a user wishes to create an output larger than half the total size of their spendable outputs or if their inputs are not distributed in a manner that allows for the completion of the alternate form procedure.In conclusion, this document proposes a set of best practice guidelines to minimize the adverse privacy consequences of creating transactions with inputs composed of different scripts. The guidelines aim to maximize the effectiveness of protection protocols, minimize the negative consequences of unavoidable HITs, and limit the effect on the UTXO set growth. It defines terms related to HITs and provides rules for both standard form and alternate form HITs. The recommendations aim to enhance privacy and optimize the usage of HITs while ensuring compliance with the proposed guidelines. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_SIGHASH-NOINPUT-in-Segregated-Witness.xml b/static/bitcoin-dev/Feb_2016/combined_SIGHASH-NOINPUT-in-Segregated-Witness.xml index 858d6396c2..c7bd53cd6b 100644 --- a/static/bitcoin-dev/Feb_2016/combined_SIGHASH-NOINPUT-in-Segregated-Witness.xml +++ b/static/bitcoin-dev/Feb_2016/combined_SIGHASH-NOINPUT-in-Segregated-Witness.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SIGHASH_NOINPUT in Segregated Witness - 2023-08-01T17:52:36.461912+00:00 + 2025-09-26T15:41:00.931900+00:00 + python-feedgen Rusty Russell 2016-02-29 00:25:53+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - SIGHASH_NOINPUT in Segregated Witness - 2023-08-01T17:52:36.461912+00:00 + 2025-09-26T15:41:00.932055+00:00 - In a discussion on the Bitcoin-dev mailing list, developers are considering a new feature that would allow for outsourced monitoring of Lightning network channels. This feature would involve three transactions: an anchor transaction, a commitment transaction, and a penalty transaction. The commitment transaction includes multiple payments and HTLCs to different parties, while the penalty transaction enables one party to take 99% of the commitment transaction's value in case of foul play. However, outsourcing the monitoring of these channels would require sending a lot of data to the chain-monitoring service.To address this issue, Joseph Poon proposed the use of a SIGHASH flag called SIGHASH_NOINPUT. This flag would allow for the inclusion of the spent outpoint's script as part of the signature, without including the outpoint being spent or the amount. This proposed flag would make it possible to write fully malleability-proof wallet software. However, Poon emphasized that the flag should only be used in SegWit transactions, as SegWit provides sufficient malleability solutions. Implementing the flag in pre-SegWit transactions would complicate matters unnecessarily.The topic of SIGHASH flags was further discussed in an email conversation between Bryan Bishop and Joseph Poon. Bryan suggested considering other types of SIGHASH flags while drafting a BIP for the new flag. Poon agreed to review those proposals and expressed interest in hearing about other sighash flags if there were clear use cases for them. However, he also mentioned concerns about replay attacks when using SIGHASH_NOINPUT, stating that SegWit resolves malleability without worrying about such attacks.Another email chain between Gregory Maxwell and Joseph Poon focused on implementing a new SegWit script type that would include fees as part of the signature. This would prevent wallets from having to download input transactions and reduce the risk of users being exposed to replay attacks. They suggested naming the new flag SIGHASH_REPLAY_VULNERABLE to emphasize its importance.Poon also discussed the idea of adding a "without-inputs SIGHASH flag" to make it easier to create transactions that spend from the same inputs as other transactions. However, he warned about the potential for replay attacks and suggested deploying a fee-committing sighash-all option to protect users.In summary, developers are considering adding new SIGHASH flags to enhance the functionality and security of SegWit transactions. These flags would allow for outsourced monitoring of Lightning network channels, prevent the need to download input transactions, and protect against replay attacks. The design of SegWit was carefully crafted to allow for safe soft-forks for future script enhancements, and developers are cautious about making unnecessary changes beyond what is necessary for a safe deployment of SegWit. 2016-02-29T00:25:53+00:00 + In a discussion on the Bitcoin-dev mailing list, developers are considering a new feature that would allow for outsourced monitoring of Lightning network channels. This feature would involve three transactions: an anchor transaction, a commitment transaction, and a penalty transaction. The commitment transaction includes multiple payments and HTLCs to different parties, while the penalty transaction enables one party to take 99% of the commitment transaction's value in case of foul play. However, outsourcing the monitoring of these channels would require sending a lot of data to the chain-monitoring service.To address this issue, Joseph Poon proposed the use of a SIGHASH flag called SIGHASH_NOINPUT. This flag would allow for the inclusion of the spent outpoint's script as part of the signature, without including the outpoint being spent or the amount. This proposed flag would make it possible to write fully malleability-proof wallet software. However, Poon emphasized that the flag should only be used in SegWit transactions, as SegWit provides sufficient malleability solutions. Implementing the flag in pre-SegWit transactions would complicate matters unnecessarily.The topic of SIGHASH flags was further discussed in an email conversation between Bryan Bishop and Joseph Poon. Bryan suggested considering other types of SIGHASH flags while drafting a BIP for the new flag. Poon agreed to review those proposals and expressed interest in hearing about other sighash flags if there were clear use cases for them. However, he also mentioned concerns about replay attacks when using SIGHASH_NOINPUT, stating that SegWit resolves malleability without worrying about such attacks.Another email chain between Gregory Maxwell and Joseph Poon focused on implementing a new SegWit script type that would include fees as part of the signature. This would prevent wallets from having to download input transactions and reduce the risk of users being exposed to replay attacks. They suggested naming the new flag SIGHASH_REPLAY_VULNERABLE to emphasize its importance.Poon also discussed the idea of adding a "without-inputs SIGHASH flag" to make it easier to create transactions that spend from the same inputs as other transactions. However, he warned about the potential for replay attacks and suggested deploying a fee-committing sighash-all option to protect users.In summary, developers are considering adding new SIGHASH flags to enhance the functionality and security of SegWit transactions. These flags would allow for outsourced monitoring of Lightning network channels, prevent the need to download input transactions, and protect against replay attacks. The design of SegWit was carefully crafted to allow for safe soft-forks for future script enhancements, and developers are cautious about making unnecessary changes beyond what is necessary for a safe deployment of SegWit. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_SegWit-GBT-updates.xml b/static/bitcoin-dev/Feb_2016/combined_SegWit-GBT-updates.xml index f6d457dd77..067c674f32 100644 --- a/static/bitcoin-dev/Feb_2016/combined_SegWit-GBT-updates.xml +++ b/static/bitcoin-dev/Feb_2016/combined_SegWit-GBT-updates.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SegWit GBT updates - 2023-08-01T17:41:26.093139+00:00 + 2025-09-26T15:40:54.592047+00:00 + python-feedgen Luke Dashjr 2016-02-02 02:30:55+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - SegWit GBT updates - 2023-08-01T17:41:26.093139+00:00 + 2025-09-26T15:40:54.592179+00:00 - The discussion revolves around the inclusion of the "default_witness_commitment" in the standard protocol. One argument against including it is that it may lead to centralization of mining pools and make server-side implementation more susceptible to DoS attacks. However, there is also an argument for including it to simplify initial adoption and have a known-correct value to use. It is mentioned that libblkmaker can handle the heavy lifting for mining software. Ultimately, the decision to include or exclude "default_witness_commitment" depends on the specific implementation and goals.In the email exchange between Luke Dashjr and Cory Fields, they discuss the default witness commitment for GBT (GetBlockTemplate) protocol. Dashjr argues that including it could enable centralization, while Fields suggests that providing a known-working commitment would be beneficial for adoption. Dashjr expresses concerns about security and suggests leaving out the default witness commitment from the standard protocol. Fields seeks clarification on potential DoS vectors and the use of libblkmaker. Dashjr reassures that the burden on mining software is not significant and that libblkmaker can handle the heavy lifting. He also mentions the need to consider the sign bit when serializing heights and the risk of introducing bugs into working code.The conversation on February 1, 2016, between Cory Fields and Luke Dashjr delves into the use of "default_witness_commitment" within the GBT protocol. Dashjr argues against including it in the standard protocol, as it contradicts GBT's design principles by enabling and encouraging centralization. Fields raises the point that providing a known-working commitment can simplify the process. Dashjr acknowledges this but emphasizes the potential for bugs. They also discuss a bug introduced by ckpool, where a positive number was serialized as a signed one.Another discussion between Luke Dashjr and Cory Fields focuses on the omission of the "default_witness_commitment" key in the Bitcoin protocol. Fields believes that omitting it would encourage pools to build their own commitment, while Dashjr argues that it could increase vulnerability to DoS attacks. Dashjr suggests leaving it as a bitcoind-specific extension to promote adoption but recommends keeping it out of the standard protocol for now. Fields expresses concerns about the burden on mining software and the risk of bugs, but Dashjr highlights the capability of libblkmaker to handle the heavy lifting. Fields mentions fixing serialization or commitment creation bugs in mining/pool software.The email conversation discusses the absence of the "default_witness_commitment" key in the current reference implementation. The omission allows clients to create the commitment themselves instead of having it provided. However, this simplicity can encourage laziness and complicate server-side implementation, making it more vulnerable to DoS attacks. The burden on mining software increases, raising the odds of bugs. It is mentioned that serialization or commitment creation bugs related to mining/pool software have already been fixed in SegWit.Luke Dashjr has drafted a BIP for updating getblocktemplate for segregated witness. The draft does not include the "default_witness_commitment" key present in the current reference implementation. This omission allows clients to create their commitment instead of relying on provided values. However, excluding the key increases the burden on mining software and the likelihood of bugs. Cory supports this argument and plans to submit the change to the BIP, enabling mining software to handle more serialization and complex structure calculations. Links to related sources are provided.Luke-jr has announced the creation of an initial draft for a BIP regarding getblocktemplate for segregated witness. The draft is available on GitHub, and Luke-jr invites others to review and comment on the changes made, particularly with regard to sigoplimits handling. However, he notes that libblkmaker's reference implementation is currently incompatible with the "last output" rule in this BIP. Luke-jr expresses gratitude in advance for any feedback received. 2016-02-02T02:30:55+00:00 + The discussion revolves around the inclusion of the "default_witness_commitment" in the standard protocol. One argument against including it is that it may lead to centralization of mining pools and make server-side implementation more susceptible to DoS attacks. However, there is also an argument for including it to simplify initial adoption and have a known-correct value to use. It is mentioned that libblkmaker can handle the heavy lifting for mining software. Ultimately, the decision to include or exclude "default_witness_commitment" depends on the specific implementation and goals.In the email exchange between Luke Dashjr and Cory Fields, they discuss the default witness commitment for GBT (GetBlockTemplate) protocol. Dashjr argues that including it could enable centralization, while Fields suggests that providing a known-working commitment would be beneficial for adoption. Dashjr expresses concerns about security and suggests leaving out the default witness commitment from the standard protocol. Fields seeks clarification on potential DoS vectors and the use of libblkmaker. Dashjr reassures that the burden on mining software is not significant and that libblkmaker can handle the heavy lifting. He also mentions the need to consider the sign bit when serializing heights and the risk of introducing bugs into working code.The conversation on February 1, 2016, between Cory Fields and Luke Dashjr delves into the use of "default_witness_commitment" within the GBT protocol. Dashjr argues against including it in the standard protocol, as it contradicts GBT's design principles by enabling and encouraging centralization. Fields raises the point that providing a known-working commitment can simplify the process. Dashjr acknowledges this but emphasizes the potential for bugs. They also discuss a bug introduced by ckpool, where a positive number was serialized as a signed one.Another discussion between Luke Dashjr and Cory Fields focuses on the omission of the "default_witness_commitment" key in the Bitcoin protocol. Fields believes that omitting it would encourage pools to build their own commitment, while Dashjr argues that it could increase vulnerability to DoS attacks. Dashjr suggests leaving it as a bitcoind-specific extension to promote adoption but recommends keeping it out of the standard protocol for now. Fields expresses concerns about the burden on mining software and the risk of bugs, but Dashjr highlights the capability of libblkmaker to handle the heavy lifting. Fields mentions fixing serialization or commitment creation bugs in mining/pool software.The email conversation discusses the absence of the "default_witness_commitment" key in the current reference implementation. The omission allows clients to create the commitment themselves instead of having it provided. However, this simplicity can encourage laziness and complicate server-side implementation, making it more vulnerable to DoS attacks. The burden on mining software increases, raising the odds of bugs. It is mentioned that serialization or commitment creation bugs related to mining/pool software have already been fixed in SegWit.Luke Dashjr has drafted a BIP for updating getblocktemplate for segregated witness. The draft does not include the "default_witness_commitment" key present in the current reference implementation. This omission allows clients to create their commitment instead of relying on provided values. However, excluding the key increases the burden on mining software and the likelihood of bugs. Cory supports this argument and plans to submit the change to the BIP, enabling mining software to handle more serialization and complex structure calculations. Links to related sources are provided.Luke-jr has announced the creation of an initial draft for a BIP regarding getblocktemplate for segregated witness. The draft is available on GitHub, and Luke-jr invites others to review and comment on the changes made, particularly with regard to sigoplimits handling. However, he notes that libblkmaker's reference implementation is currently incompatible with the "last output" rule in this BIP. Luke-jr expresses gratitude in advance for any feedback received. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml b/static/bitcoin-dev/Feb_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml index 6223be70c6..2ec7f4a660 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segwit Upgrade Procedures & Block Extension Data - 2023-08-01T17:39:45.031342+00:00 + 2025-09-26T15:40:58.820504+00:00 + python-feedgen Tier Nolan 2016-02-01 19:29:32+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Segwit Upgrade Procedures & Block Extension Data - 2023-08-01T17:39:45.031342+00:00 + 2025-09-26T15:40:58.820678+00:00 - On February 1, 2016, Pieter Wuille proposed a second number push in the coinbase scriptSig, which would point to a 32-byte hash H. This push was accepted as it provided a more flexible and compact system than the current one. Concerns were raised about adding arbitrary data, so it was suggested that the data in the coinbase witness stack have a fixed number of entries depending on the block version number. This would allow for soft-forks to add new entries in the stack.Peter Todd discussed upgrade procedures related to segregated witnesses, suggesting the addition of a new service bit or bumping the protocol version. However, this solution did not address the issue of relaying more block data in the future, requiring another soft-fork upgrade. To solve this problem, Todd proposed making the witness data more extensible by using unvalidated block extension data. This involved a backward-incompatible change to the current segwit change, where the coinbase scriptSig would receive a second number push pointing to a 32-byte hash H. Todd also addressed concerns about miners using arbitrary data by suggesting a merkelized key:value mapping with collision-resistant IDs as keys.Pieter Wuille's segwit branch was discussed on the Bitcoin developers mailing list. It was suggested to add a new service bit or bump up the protocol version to only connect to peers with segwit support. The branch had a fHaveWitness flag for each connection, but BIP144 proposed changing this to a service bit. A pull request to change this to a NODE_WITNESS service bit has been made on GitHub.Peter Todd suggested adding a new service bit, NODE_SEGWIT, and/or bumping the protocol version to ensure outgoing peers only connect to peers with segwit support. He also proposed solutions for future upgrades adding new block data, such as removing the restriction on the coinbase witness containing exactly one 32-byte value. Another proposal involved hashing the contents of the coinbase witness as a merkle tree and committing them in place of the current nonce commitment. These proposals were discussed in a pull request on the segwit branch, including the idea of including the merkle path to the segwit data in the coinbase witness.The deployment of segregated witness poses a problem as nodes need witness data to function after activation. If full node adoption lags behind miner adoption, the segwit-supporting P2P network may partition and lose consensus. The issue is not yet fixed in Pieter Wuille's segwit branch, but one solution is to add a new service bit or bump the protocol version to only connect to peers with segwit support. However, if full node operators do not widely adopt segwit, the network could become more vulnerable. Future upgrades will require the relay network to upgrade, and BIP141 suggests an Extensible Commitment Structure to address this. This structure consists of a hashed linked list of consensus-critical commitments, with a redefinable nonce for future soft-forks. To allow for additional data in future soft-forks, the proposal is to remove the restriction on the coinbase witness, hash its contents as a merkle tree, and include that data in the blocksize limit. This allows all nodes to validate the data came from the miner and propagate it without risk of attack. This method is efficient as most future upgrades are expected to be additional commitments, and the additional data for each commitment is just 32 bytes. 2016-02-01T19:29:32+00:00 + On February 1, 2016, Pieter Wuille proposed a second number push in the coinbase scriptSig, which would point to a 32-byte hash H. This push was accepted as it provided a more flexible and compact system than the current one. Concerns were raised about adding arbitrary data, so it was suggested that the data in the coinbase witness stack have a fixed number of entries depending on the block version number. This would allow for soft-forks to add new entries in the stack.Peter Todd discussed upgrade procedures related to segregated witnesses, suggesting the addition of a new service bit or bumping the protocol version. However, this solution did not address the issue of relaying more block data in the future, requiring another soft-fork upgrade. To solve this problem, Todd proposed making the witness data more extensible by using unvalidated block extension data. This involved a backward-incompatible change to the current segwit change, where the coinbase scriptSig would receive a second number push pointing to a 32-byte hash H. Todd also addressed concerns about miners using arbitrary data by suggesting a merkelized key:value mapping with collision-resistant IDs as keys.Pieter Wuille's segwit branch was discussed on the Bitcoin developers mailing list. It was suggested to add a new service bit or bump up the protocol version to only connect to peers with segwit support. The branch had a fHaveWitness flag for each connection, but BIP144 proposed changing this to a service bit. A pull request to change this to a NODE_WITNESS service bit has been made on GitHub.Peter Todd suggested adding a new service bit, NODE_SEGWIT, and/or bumping the protocol version to ensure outgoing peers only connect to peers with segwit support. He also proposed solutions for future upgrades adding new block data, such as removing the restriction on the coinbase witness containing exactly one 32-byte value. Another proposal involved hashing the contents of the coinbase witness as a merkle tree and committing them in place of the current nonce commitment. These proposals were discussed in a pull request on the segwit branch, including the idea of including the merkle path to the segwit data in the coinbase witness.The deployment of segregated witness poses a problem as nodes need witness data to function after activation. If full node adoption lags behind miner adoption, the segwit-supporting P2P network may partition and lose consensus. The issue is not yet fixed in Pieter Wuille's segwit branch, but one solution is to add a new service bit or bump the protocol version to only connect to peers with segwit support. However, if full node operators do not widely adopt segwit, the network could become more vulnerable. Future upgrades will require the relay network to upgrade, and BIP141 suggests an Extensible Commitment Structure to address this. This structure consists of a hashed linked list of consensus-critical commitments, with a redefinable nonce for future soft-forks. To allow for additional data in future soft-forks, the proposal is to remove the restriction on the coinbase witness, hash its contents as a merkle tree, and include that data in the blocksize limit. This allows all nodes to validate the data came from the miner and propagate it without risk of attack. This method is efficient as most future upgrades are expected to be additional commitments, and the additional data for each commitment is just 32 bytes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Soft-fork-fix-for-block-withholding-attacks.xml b/static/bitcoin-dev/Feb_2016/combined_Soft-fork-fix-for-block-withholding-attacks.xml index 6f09469a4f..6b7faf63fb 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Soft-fork-fix-for-block-withholding-attacks.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Soft-fork-fix-for-block-withholding-attacks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Soft fork fix for block withholding attacks - 2023-08-01T17:51:11.708328+00:00 + 2025-09-26T15:41:11.497034+00:00 + python-feedgen Tier Nolan 2016-02-12 16:09:01+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Soft fork fix for block withholding attacks - 2023-08-01T17:51:11.709333+00:00 + 2025-09-26T15:41:11.497190+00:00 - The context explores the idea of designing clients to warn users about soft forks and the potential safety advantages of doing so. While the reference client can provide warnings for high Proof-of-Work (POW) soft forks, many Simplified Payment Verification (SPV) clients cannot. To address this, it is suggested to implement a delay between version number changes and rule activation. This would allow nodes to receive a warning urging them to update their software.Furthermore, the context proposes specific guidelines for increasing difficulty intervals and updating targets at each difficulty re-targetting. The aim is to eventually reach a target of zero after 64 weeks, resulting in a difficulty level that is 256 times higher than the header. By implementing these guidelines, the hope is to enhance the security and stability of the network.Additionally, the context highlights an important point about the vulnerability of block withholding attacks. A proposal to fix this issue with a soft fork was presented, but it was noted that the technique does not align with the standard definition of a soft fork used by the Bitcoin development and research community. The proposed approach may be termed a "pseudo-soft-fork" and requires further analysis to determine its effectiveness compared to a simpler hard-fork implementation.To tackle block withholding attacks, another solution is put forth in the context. This solution involves redefining the block Proof-of-Work (PoW) target to be less than the difficulty, with the last two bytes representing the target. Miners are required to include a blinded hash of the target along with additional data in the coinbase of the blocks. Importantly, miners cannot switch targets arbitrarily and must submit all shares that meet the PoW criteria. Secondary verification is delegated to the miner, who must communicate proof of their target hash in a non-hashed area of the block.This proposed solution can be deployed as a soft fork with miner opt-in triggering across multiple difficulty cycles. Initially, the last bit of the block hash must be zero, followed by the last two bits in the next cycle. This progression continues over 16 difficulty cycles to minimize significant increases in block timings. By the end of this process, the nominal difficulty would have been reduced by a factor of 2^16 (65536), while the block target makes mining each block significantly harder.The context concludes by mentioning the possibility of progressing over more difficulty cycles through clever soft fork rules, such as Vitalik's "timewalking" attacks that allow for effective granular lowering of the nominal difficulty. Critiques are welcomed regarding these proposals, demonstrating an openness to further improvements and refinements in the Bitcoin network's security and performance. 2016-02-12T16:09:01+00:00 + The context explores the idea of designing clients to warn users about soft forks and the potential safety advantages of doing so. While the reference client can provide warnings for high Proof-of-Work (POW) soft forks, many Simplified Payment Verification (SPV) clients cannot. To address this, it is suggested to implement a delay between version number changes and rule activation. This would allow nodes to receive a warning urging them to update their software.Furthermore, the context proposes specific guidelines for increasing difficulty intervals and updating targets at each difficulty re-targetting. The aim is to eventually reach a target of zero after 64 weeks, resulting in a difficulty level that is 256 times higher than the header. By implementing these guidelines, the hope is to enhance the security and stability of the network.Additionally, the context highlights an important point about the vulnerability of block withholding attacks. A proposal to fix this issue with a soft fork was presented, but it was noted that the technique does not align with the standard definition of a soft fork used by the Bitcoin development and research community. The proposed approach may be termed a "pseudo-soft-fork" and requires further analysis to determine its effectiveness compared to a simpler hard-fork implementation.To tackle block withholding attacks, another solution is put forth in the context. This solution involves redefining the block Proof-of-Work (PoW) target to be less than the difficulty, with the last two bytes representing the target. Miners are required to include a blinded hash of the target along with additional data in the coinbase of the blocks. Importantly, miners cannot switch targets arbitrarily and must submit all shares that meet the PoW criteria. Secondary verification is delegated to the miner, who must communicate proof of their target hash in a non-hashed area of the block.This proposed solution can be deployed as a soft fork with miner opt-in triggering across multiple difficulty cycles. Initially, the last bit of the block hash must be zero, followed by the last two bits in the next cycle. This progression continues over 16 difficulty cycles to minimize significant increases in block timings. By the end of this process, the nominal difficulty would have been reduced by a factor of 2^16 (65536), while the block target makes mining each block significantly harder.The context concludes by mentioning the possibility of progressing over more difficulty cycles through clever soft fork rules, such as Vitalik's "timewalking" attacks that allow for effective granular lowering of the nominal difficulty. Critiques are welcomed regarding these proposals, demonstrating an openness to further improvements and refinements in the Bitcoin network's security and performance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_The-first-successful-Zero-Knowledge-Contingent-Payment.xml b/static/bitcoin-dev/Feb_2016/combined_The-first-successful-Zero-Knowledge-Contingent-Payment.xml index 70e4ee979a..ab532a83dc 100644 --- a/static/bitcoin-dev/Feb_2016/combined_The-first-successful-Zero-Knowledge-Contingent-Payment.xml +++ b/static/bitcoin-dev/Feb_2016/combined_The-first-successful-Zero-Knowledge-Contingent-Payment.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The first successful Zero-Knowledge Contingent Payment - 2023-08-01T17:53:24.934051+00:00 + 2025-09-26T15:40:46.136510+00:00 + python-feedgen Tier Nolan 2016-02-26 23:56:58+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - The first successful Zero-Knowledge Contingent Payment - 2023-08-01T17:53:24.934051+00:00 + 2025-09-26T15:40:46.136679+00:00 - In February 2016, Gregory Maxwell proposed a scheme to reveal a private key in Bitcoin through a single-show-signature approach. This scheme was previously developed by Maxwell and discussed on the lightning-dev mailing list. Tier Nolan also inquired about atomic cross-chain transfers between Bitcoin and legacy altcoins, which are outdated coins with strict IsStandard() rules and no advanced script opcodes. Nolan suggested using the single-show-signature scheme he created on the Bitcoin side instead of performing an EC multiply. Discussions have been ongoing regarding atomic cross-chain transfers between Bitcoin and legacy altcoins. A legacy altcoin is defined as one with strict IsStandard() rules and lacking advanced script opcodes. To transfer funds, Bob must prove that he has a private key that matches his public key. This can be achieved through a cut-and-choose scheme that uses a fee to ensure attackers lose money on average. However, this scheme is vulnerable to attackers who don't mind losing money as long as the target loses money too. The feasibility of using an elliptic curve multiply for this scheme is questioned. The discussion took place on the Bitcoin-dev mailing list.Gregory Maxwell successfully demonstrated a Zero-Knowledge Contingent Payment (ZKCP) transaction protocol on the Bitcoin network. This protocol allows a buyer to purchase information from a seller using Bitcoin in a private, scalable, and secure manner without relying on trust or third-party arbitration. The buyer receives the expected information only if the payment is made. ZKCP eliminates significant transactional costs and risks associated with irreversible sales across multiple jurisdictions. In a live demonstration, Gregory purchased a 16x16 Sudoku puzzle solution for 0.10 BTC from Sean Bowe of the Zcash team at Financial Cryptography 2016 in Barbados. The transfer involved two transactions, and most of the engineering work behind the ZKCP implementation was done by Sean Bowe, with support from Pieter Wuille, Gregory Maxwell, and Madars Virza.The first successful Zero-Knowledge Contingent Payment (ZKCP) on the Bitcoin network has been announced. ZKCP enables buyers to purchase information from sellers in a private, scalable, and secure manner without relying on trust or third-party arbitration. The payment is only made if the expected information is transferred. This eliminates transactional costs and risks associated with irreversible sales across multiple jurisdictions. In a demonstration, Gregory purchased a 16x16 Sudoku puzzle solution for 0.10 BTC from Sean Bowe of the Zcash team. The transfer involved two transactions, and most of the engineering work was done by Sean Bowe, with support from Pieter Wuille, Gregory Maxwell, and Madars Virza. More technical details about ZKCP can be found at the provided link. The buyer also plans to launch a ZKCP sudoku buying faucet soon. 2016-02-26T23:56:58+00:00 + In February 2016, Gregory Maxwell proposed a scheme to reveal a private key in Bitcoin through a single-show-signature approach. This scheme was previously developed by Maxwell and discussed on the lightning-dev mailing list. Tier Nolan also inquired about atomic cross-chain transfers between Bitcoin and legacy altcoins, which are outdated coins with strict IsStandard() rules and no advanced script opcodes. Nolan suggested using the single-show-signature scheme he created on the Bitcoin side instead of performing an EC multiply. Discussions have been ongoing regarding atomic cross-chain transfers between Bitcoin and legacy altcoins. A legacy altcoin is defined as one with strict IsStandard() rules and lacking advanced script opcodes. To transfer funds, Bob must prove that he has a private key that matches his public key. This can be achieved through a cut-and-choose scheme that uses a fee to ensure attackers lose money on average. However, this scheme is vulnerable to attackers who don't mind losing money as long as the target loses money too. The feasibility of using an elliptic curve multiply for this scheme is questioned. The discussion took place on the Bitcoin-dev mailing list.Gregory Maxwell successfully demonstrated a Zero-Knowledge Contingent Payment (ZKCP) transaction protocol on the Bitcoin network. This protocol allows a buyer to purchase information from a seller using Bitcoin in a private, scalable, and secure manner without relying on trust or third-party arbitration. The buyer receives the expected information only if the payment is made. ZKCP eliminates significant transactional costs and risks associated with irreversible sales across multiple jurisdictions. In a live demonstration, Gregory purchased a 16x16 Sudoku puzzle solution for 0.10 BTC from Sean Bowe of the Zcash team at Financial Cryptography 2016 in Barbados. The transfer involved two transactions, and most of the engineering work behind the ZKCP implementation was done by Sean Bowe, with support from Pieter Wuille, Gregory Maxwell, and Madars Virza.The first successful Zero-Knowledge Contingent Payment (ZKCP) on the Bitcoin network has been announced. ZKCP enables buyers to purchase information from sellers in a private, scalable, and secure manner without relying on trust or third-party arbitration. The payment is only made if the expected information is transferred. This eliminates transactional costs and risks associated with irreversible sales across multiple jurisdictions. In a demonstration, Gregory purchased a 16x16 Sudoku puzzle solution for 0.10 BTC from Sean Bowe of the Zcash team. The transfer involved two transactions, and most of the engineering work was done by Sean Bowe, with support from Pieter Wuille, Gregory Maxwell, and Madars Virza. More technical details about ZKCP can be found at the provided link. The buyer also plans to launch a ZKCP sudoku buying faucet soon. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml b/static/bitcoin-dev/Feb_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml index 274ebf41ad..89a992a60c 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Three Month bitcoin-dev Moderation Review - 2023-08-01T17:36:07.470670+00:00 + 2025-09-26T15:40:50.365567+00:00 + python-feedgen David Vorick 2016-02-09 23:24:28+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Three Month bitcoin-dev Moderation Review - 2023-08-01T17:36:07.471670+00:00 + 2025-09-26T15:40:50.365743+00:00 - The Bitcoin-dev mailing list recently discussed the importance of providing unique and valuable contributions to conversations. Contributors emphasized that comments should contribute to the discussion with technical details or additional relevant data, rather than simply stating agreement with a proposal. The sentiment expressed was that evidence trumps votes, and comments should provide readers with another thing to consider in favor of something beyond just the number of people who support it.In this context, various members of the mailing list shared their opinions. Dave Scotese suggested that contributors should provide additional evidence in favor of something, while Gavin offered his services as a techie and shared information about his projects Litmocracy and Meme Racing. Peter Todd and another member stressed that comments should contribute uniquely to the discussion and not simply repeat what has already been said. They proposed using a "+1" vote with an explanation that provides unique insights to the conversation.Another member, Xor, suggested allowing "+1" votes as long as a technical explanation is provided for why the person agrees. However, Peter Todd disagreed, stating that the explanation should also contribute uniquely to the conversation. Rusty Russell expressed his view that "+1s" on a list are not useful unless they carry additional information. He recommended amending the rules to clarify that "+1s" are not allowed without an explanation.In addition to discussing comments, the mailing list also addressed other issues. Dave Scotese expressed disappointment at the difficulty in accessing moderated messages and suggested having a downloadable version of these messages on the ozlabs website. Rusty Russell explained that the difficulty arises because the messages are forwarded to the bitcoin-dev-moderation mailing list, which strips them out as attachments. Rusty called for volunteers to help develop a filter to address this issue.Furthermore, Rusty Russell raised the question of what moderation should look like going forward. Xor pointed out that the original announcement of moderation had discouraged the use of "+1s" without additional information. Rusty clarified that statements like "I prefer proposal X over Y because..." or "I dislike X because..." carry more weight than simply saying "+1." The discussion highlighted the need for moderation to be information-rich and not solely focused on managing a process of indicating agreement or disagreement.Overall, the Bitcoin-dev mailing list engaged in a thoughtful discussion about the value of comments, the importance of providing unique contributions, and potential improvements to the moderation system. 2016-02-09T23:24:28+00:00 + The Bitcoin-dev mailing list recently discussed the importance of providing unique and valuable contributions to conversations. Contributors emphasized that comments should contribute to the discussion with technical details or additional relevant data, rather than simply stating agreement with a proposal. The sentiment expressed was that evidence trumps votes, and comments should provide readers with another thing to consider in favor of something beyond just the number of people who support it.In this context, various members of the mailing list shared their opinions. Dave Scotese suggested that contributors should provide additional evidence in favor of something, while Gavin offered his services as a techie and shared information about his projects Litmocracy and Meme Racing. Peter Todd and another member stressed that comments should contribute uniquely to the discussion and not simply repeat what has already been said. They proposed using a "+1" vote with an explanation that provides unique insights to the conversation.Another member, Xor, suggested allowing "+1" votes as long as a technical explanation is provided for why the person agrees. However, Peter Todd disagreed, stating that the explanation should also contribute uniquely to the conversation. Rusty Russell expressed his view that "+1s" on a list are not useful unless they carry additional information. He recommended amending the rules to clarify that "+1s" are not allowed without an explanation.In addition to discussing comments, the mailing list also addressed other issues. Dave Scotese expressed disappointment at the difficulty in accessing moderated messages and suggested having a downloadable version of these messages on the ozlabs website. Rusty Russell explained that the difficulty arises because the messages are forwarded to the bitcoin-dev-moderation mailing list, which strips them out as attachments. Rusty called for volunteers to help develop a filter to address this issue.Furthermore, Rusty Russell raised the question of what moderation should look like going forward. Xor pointed out that the original announcement of moderation had discouraged the use of "+1s" without additional information. Rusty clarified that statements like "I prefer proposal X over Y because..." or "I dislike X because..." carry more weight than simply saying "+1." The discussion highlighted the need for moderation to be information-rich and not solely focused on managing a process of indicating agreement or disagreement.Overall, the Bitcoin-dev mailing list engaged in a thoughtful discussion about the value of comments, the importance of providing unique contributions, and potential improvements to the moderation system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_-Pre-BIP-Community-Consensus-Voting-System.xml b/static/bitcoin-dev/Feb_2017/combined_-Pre-BIP-Community-Consensus-Voting-System.xml index 87f0673489..5d2958a87d 100644 --- a/static/bitcoin-dev/Feb_2017/combined_-Pre-BIP-Community-Consensus-Voting-System.xml +++ b/static/bitcoin-dev/Feb_2017/combined_-Pre-BIP-Community-Consensus-Voting-System.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - [Pre-BIP] Community Consensus Voting System - 2023-08-01T19:30:16.129279+00:00 - - Peter Todd 2017-02-14 12:33:17+00:00 - - - Staf Verhaegen 2017-02-11 15:57:46+00:00 - - - t. khan 2017-02-04 22:02:00+00:00 - - - t. khan 2017-02-04 21:23:19+00:00 - - - Chris Priest 2017-02-04 00:57:52+00:00 - - - alp alp 2017-02-03 19:22:10+00:00 - - - t. khan 2017-02-03 18:20:13+00:00 - - - alp alp 2017-02-03 16:19:19+00:00 - - - Dave Scotese 2017-02-03 01:32:34+00:00 - - - Luke Dashjr 2017-02-03 00:24:09+00:00 - - - David Vorick 2017-02-02 23:19:39+00:00 - - - t. khan 2017-02-02 19:39:51+00:00 - + 2025-09-26T15:51:49.205337+00:00 + python-feedgen + + + [bitcoin-dev] [Pre-BIP] Community Consensus Voting System t. khan + 2017-02-02T19:39:00.000Z + + + David Vorick + 2017-02-02T23:19:00.000Z + + + Luke Dashjr + 2017-02-03T00:24:00.000Z + + + Dave Scotese + 2017-02-03T01:32:00.000Z + + + alp alp + 2017-02-03T16:19:00.000Z + + + t. khan + 2017-02-03T18:20:00.000Z + + + alp alp + 2017-02-03T19:22:00.000Z + + + Chris Priest + 2017-02-04T00:57:00.000Z + + + t. khan + 2017-02-04T21:23:00.000Z + + + t. khan + 2017-02-04T22:02:00.000Z + + + Staf Verhaegen + 2017-02-11T15:57:00.000Z + + + Peter Todd + 2017-02-14T12:33:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - [Pre-BIP] Community Consensus Voting System - 2023-08-01T19:30:16.130277+00:00 + 2025-09-26T15:51:49.206723+00:00 - The CCVS (Community Consensus Voting System) has been proposed to address the challenges faced by the Bitcoin protocol in making controversial changes like the max block size limit. The goal of the CCVS is to allow the general public, miners, companies using Bitcoin, and developers to vote for their preferred BIP (Bitcoin Improvement Proposal) in a transparent and difficult-to-manipulate manner.Under the CCVS system, each competing BIP is assigned a unique bitcoin address that is added to each header. Individuals can vote for their preferred BIP by sending 0.0001 BTC to the corresponding address, with each transaction counting as one vote. Mining pools, companies using Bitcoin, and Core maintainers/contributors are granted one confirmed vote each, which is worth 10,000 times a regular vote. Confirmed votes are recorded in a new section of each respective BIP as a public record.However, there are still unresolved questions and concerns regarding the CCVS proposal. These include determining eligibility criteria for companies and websites, verifying voters' identities, preventing manipulation through fake companies, and deciding who administers the voting system. The proposal is still in need of further discussion and refinement.During the conversation, other contentious issues in the technology world, such as DRM, were also discussed. It was noted that disagreements in the tech industry are not always purely technical but can be influenced by political factors. The example of the W3C's debate over including DRM in web standards was cited to highlight this point.There were also concerns raised about the idea of buying "votes" and portraying open standards as a voting process. Some participants disagreed with this approach, arguing that it relies on address reuse and is fundamentally flawed in design. Alternatives were suggested, such as finding ways for people to express their support without spending their bitcoins or using full nodes to weigh their opinions.Overall, the CCVS proposal aims to provide a more transparent and inclusive process for measuring support for BIPs in the Bitcoin community. However, there are still many unresolved issues and differing opinions on how such a system should be implemented. One unresolved issue is node voting, which falls outside the scope of the current proposal but is considered desirable by some to give blockchain-running full nodes the ability to vote with a multiplier. 2017-02-14T12:33:17+00:00 + The CCVS (Community Consensus Voting System) has been proposed to address the challenges faced by the Bitcoin protocol in making controversial changes like the max block size limit. The goal of the CCVS is to allow the general public, miners, companies using Bitcoin, and developers to vote for their preferred BIP (Bitcoin Improvement Proposal) in a transparent and difficult-to-manipulate manner.Under the CCVS system, each competing BIP is assigned a unique bitcoin address that is added to each header. Individuals can vote for their preferred BIP by sending 0.0001 BTC to the corresponding address, with each transaction counting as one vote. Mining pools, companies using Bitcoin, and Core maintainers/contributors are granted one confirmed vote each, which is worth 10,000 times a regular vote. Confirmed votes are recorded in a new section of each respective BIP as a public record.However, there are still unresolved questions and concerns regarding the CCVS proposal. These include determining eligibility criteria for companies and websites, verifying voters' identities, preventing manipulation through fake companies, and deciding who administers the voting system. The proposal is still in need of further discussion and refinement.During the conversation, other contentious issues in the technology world, such as DRM, were also discussed. It was noted that disagreements in the tech industry are not always purely technical but can be influenced by political factors. The example of the W3C's debate over including DRM in web standards was cited to highlight this point.There were also concerns raised about the idea of buying "votes" and portraying open standards as a voting process. Some participants disagreed with this approach, arguing that it relies on address reuse and is fundamentally flawed in design. Alternatives were suggested, such as finding ways for people to express their support without spending their bitcoins or using full nodes to weigh their opinions.Overall, the CCVS proposal aims to provide a more transparent and inclusive process for measuring support for BIPs in the Bitcoin community. However, there are still many unresolved issues and differing opinions on how such a system should be implemented. One unresolved issue is node voting, which falls outside the scope of the current proposal but is considered desirable by some to give blockchain-running full nodes the ability to vote with a multiplier. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_A-Better-MMR-Definition.xml b/static/bitcoin-dev/Feb_2017/combined_A-Better-MMR-Definition.xml index a1bd7fdad0..1c0ea53928 100644 --- a/static/bitcoin-dev/Feb_2017/combined_A-Better-MMR-Definition.xml +++ b/static/bitcoin-dev/Feb_2017/combined_A-Better-MMR-Definition.xml @@ -1,95 +1,127 @@ - + 2 Combined summary - A Better MMR Definition - 2023-08-01T19:34:55.774037+00:00 - - praxeology_guy 2017-04-01 19:46:12+00:00 - - - praxeology_guy 2017-04-01 10:18:12+00:00 - - - Bram Cohen 2017-03-31 20:38:16+00:00 - - - Peter Todd 2017-03-01 22:31:01+00:00 - - - Peter Todd 2017-03-01 01:56:16+00:00 - - - Bram Cohen 2017-03-01 01:47:30+00:00 - - - Pieter Wuille 2017-02-28 23:24:28+00:00 - - - Bram Cohen 2017-02-28 23:10:16+00:00 - - - G. Andrew Stone 2017-02-28 16:43:29+00:00 - - - Bram Cohen 2017-02-25 06:23:20+00:00 - - - Peter Todd 2017-02-25 04:12:02+00:00 - - - Bram Cohen 2017-02-24 22:20:19+00:00 - - - Peter Todd 2017-02-24 04:36:13+00:00 - - - Bram Cohen 2017-02-24 03:32:43+00:00 - - - Peter Todd 2017-02-24 03:15:31+00:00 - - - Bram Cohen 2017-02-24 03:02:36+00:00 - - - Peter Todd 2017-02-24 02:58:11+00:00 - - - Bram Cohen 2017-02-24 02:50:10+00:00 - - - Peter Todd 2017-02-24 01:09:43+00:00 - - - Bram Cohen 2017-02-24 00:49:01+00:00 - - - Peter Todd 2017-02-23 23:51:05+00:00 - - - Bram Cohen 2017-02-23 23:13:43+00:00 - - - Peter Todd 2017-02-23 18:31:40+00:00 - - - G. Andrew Stone 2017-02-23 18:28:18+00:00 - - - Peter Todd 2017-02-23 18:19:29+00:00 - - - Chris Priest 2017-02-23 17:53:58+00:00 - - - Peter Todd 2017-02-23 07:41:37+00:00 - - - Bram Cohen 2017-02-23 03:07:08+00:00 - - - Peter Todd 2017-02-23 01:15:06+00:00 - + 2025-09-26T15:51:44.984938+00:00 + python-feedgen + + + [bitcoin-dev] A Better MMR Definition Peter Todd + 2017-02-23T01:15:00.000Z + + + Bram Cohen + 2017-02-23T03:07:00.000Z + + + Peter Todd + 2017-02-23T07:41:00.000Z + + + Chris Priest + 2017-02-23T17:53:00.000Z + + + Peter Todd + 2017-02-23T18:19:00.000Z + + + G. Andrew Stone + 2017-02-23T18:28:00.000Z + + + Peter Todd + 2017-02-23T18:31:00.000Z + + + Bram Cohen + 2017-02-23T23:13:00.000Z + + + Peter Todd + 2017-02-23T23:51:00.000Z + + + Bram Cohen + 2017-02-24T00:49:00.000Z + + + Peter Todd + 2017-02-24T01:09:00.000Z + + + Bram Cohen + 2017-02-24T02:50:00.000Z + + + Peter Todd + 2017-02-24T02:58:00.000Z + + + Bram Cohen + 2017-02-24T03:02:00.000Z + + + Peter Todd + 2017-02-24T03:15:00.000Z + + + Bram Cohen + 2017-02-24T03:32:00.000Z + + + Peter Todd + 2017-02-24T04:36:00.000Z + + + Bram Cohen + 2017-02-24T22:20:00.000Z + + + Peter Todd + 2017-02-25T04:12:00.000Z + + + Bram Cohen + 2017-02-25T06:23:00.000Z + + + G. Andrew Stone + 2017-02-28T16:43:00.000Z + + + Bram Cohen + 2017-02-28T23:10:00.000Z + + + Pieter Wuille + 2017-02-28T23:24:00.000Z + + + Bram Cohen + 2017-03-01T01:47:00.000Z + + + Peter Todd + 2017-03-01T01:56:00.000Z + + + Peter Todd + 2017-03-01T22:31:00.000Z + + + Bram Cohen + 2017-03-31T20:38:00.000Z + + + praxeology_guy + 2017-04-01T10:18:00.000Z + + + praxeology_guy + 2017-04-01T19:46:00.000Z + + @@ -119,13 +151,13 @@ - python-feedgen + 2 Combined summary - A Better MMR Definition - 2023-08-01T19:34:55.775036+00:00 + 2025-09-26T15:51:44.987693+00:00 - In an email exchange between Bram Cohen and Peter Todd, the concept of UTXO commitments and the use of merkle trees for proving the current state of an output were discussed. Todd suggested committing to the state of all transaction outputs with a merkle tree structure, while Cohen argued that MMRs seemed redundant with the actual blockchain history. However, they agreed on the main goal of UTXO commitments: making a compact proof that something is still in the UTXO set.There were concerns about the performance and scalability of implementing UTXO commitments, particularly due to the size of the txo set. Cohen believed that with appropriate format and implementation tricks, good enough performance could be achieved. The benefits and drawbacks of using MMRs were also discussed. Todd argued that MMRs were redundant because you could prove something is in the TXO or STXO set using the actual blockchain, while Cohen believed that UTXO commitments provided benefits in terms of proving block validity and preventing fraud.The importance of independent validation by full nodes and the potential issues of relying too heavily on proofs were also touched upon. Todd emphasized the need to consider MMRs on their own merits before comparing them to UTXO commitments.Another email conversation involved G. Andrew Stone asking about efficient nonexistence proofs in an insertion-ordered MMR. This proposal aimed to enhance the efficiency of non-existence proofs and improve TXO commitments. Additionally, there was a discussion about the definition of a prunable MMR for use in Bitcoin. The improved definition committed to the number of items in the tree implicitly, allowing for an efficient proof-of-tree-size by following the right-most nodes. The insertion-ordered MMR was seen as a way to enhance non-existence proofs and overall TXO commitments.Overall, these discussions highlighted the ongoing exploration of UTXO commitments and MMRs as potential solutions for improving the scalability, performance, and security of blockchain transactions. 2017-04-01T19:46:12+00:00 + In an email exchange between Bram Cohen and Peter Todd, the concept of UTXO commitments and the use of merkle trees for proving the current state of an output were discussed. Todd suggested committing to the state of all transaction outputs with a merkle tree structure, while Cohen argued that MMRs seemed redundant with the actual blockchain history. However, they agreed on the main goal of UTXO commitments: making a compact proof that something is still in the UTXO set.There were concerns about the performance and scalability of implementing UTXO commitments, particularly due to the size of the txo set. Cohen believed that with appropriate format and implementation tricks, good enough performance could be achieved. The benefits and drawbacks of using MMRs were also discussed. Todd argued that MMRs were redundant because you could prove something is in the TXO or STXO set using the actual blockchain, while Cohen believed that UTXO commitments provided benefits in terms of proving block validity and preventing fraud.The importance of independent validation by full nodes and the potential issues of relying too heavily on proofs were also touched upon. Todd emphasized the need to consider MMRs on their own merits before comparing them to UTXO commitments.Another email conversation involved G. Andrew Stone asking about efficient nonexistence proofs in an insertion-ordered MMR. This proposal aimed to enhance the efficiency of non-existence proofs and improve TXO commitments. Additionally, there was a discussion about the definition of a prunable MMR for use in Bitcoin. The improved definition committed to the number of items in the tree implicitly, allowing for an efficient proof-of-tree-size by following the right-most nodes. The insertion-ordered MMR was seen as a way to enhance non-existence proofs and overall TXO commitments.Overall, these discussions highlighted the ongoing exploration of UTXO commitments and MMRs as potential solutions for improving the scalability, performance, and security of blockchain transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_A-Modified-Version-of-Luke-jr-s-Block-Size-BIP.xml b/static/bitcoin-dev/Feb_2017/combined_A-Modified-Version-of-Luke-jr-s-Block-Size-BIP.xml index 30cc4b637e..2defdd49d2 100644 --- a/static/bitcoin-dev/Feb_2017/combined_A-Modified-Version-of-Luke-jr-s-Block-Size-BIP.xml +++ b/static/bitcoin-dev/Feb_2017/combined_A-Modified-Version-of-Luke-jr-s-Block-Size-BIP.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - A Modified Version of Luke-jr's Block Size BIP - 2023-08-01T19:31:56.939005+00:00 - - Btc Drak 2017-02-10 10:33:52+00:00 - - - Ryan J Martin 2017-02-10 04:10:15+00:00 - - - alp alp 2017-02-08 20:13:18+00:00 - - - Andrew Johnson 2017-02-08 19:56:19+00:00 - - - t. khan 2017-02-08 19:53:15+00:00 - - - alp alp 2017-02-08 18:16:07+00:00 - - - Andrew Johnson 2017-02-08 16:28:55+00:00 - - - alp alp 2017-02-08 15:57:21+00:00 - - - Andrew Johnson 2017-02-08 15:51:24+00:00 - - - alp alp 2017-02-08 14:44:52+00:00 - - - Andrew C 2017-02-06 21:00:18+00:00 - - - t. khan 2017-02-06 20:25:13+00:00 - - - t. khan 2017-02-06 18:19:43+00:00 - - - Andrew C 2017-02-05 23:53:03+00:00 - - - Luke Dashjr 2017-02-05 23:02:28+00:00 - - - Andrew C 2017-02-05 21:50:26+00:00 - + 2025-09-26T15:51:42.869619+00:00 + python-feedgen + + + [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP Andrew C + 2017-02-05T21:50:00.000Z + + + Luke Dashjr + 2017-02-05T23:02:00.000Z + + + Andrew C + 2017-02-05T23:53:00.000Z + + + t. khan + 2017-02-06T18:19:00.000Z + + + t. khan + 2017-02-06T20:25:00.000Z + + + Andrew C + 2017-02-06T21:00:00.000Z + + + alp alp + 2017-02-08T14:44:00.000Z + + + Andrew Johnson + 2017-02-08T15:51:00.000Z + + + alp alp + 2017-02-08T15:57:00.000Z + + + Andrew Johnson + 2017-02-08T16:28:00.000Z + + + alp alp + 2017-02-08T18:16:00.000Z + + + t. khan + 2017-02-08T19:53:00.000Z + + + Andrew Johnson + 2017-02-08T19:56:00.000Z + + + alp alp + 2017-02-08T20:13:00.000Z + + + Ryan J Martin + 2017-02-10T04:10:00.000Z + + + Btc Drak + 2017-02-10T10:33:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - A Modified Version of Luke-jr's Block Size BIP - 2023-08-01T19:31:56.940006+00:00 + 2025-09-26T15:51:42.871376+00:00 - There has been a contentious debate within the Bitcoin community regarding Luke-jr's proposed block size BIP. The proposal suggests decreasing the block size, but many users argue that the current block size is already too small and would prefer an increase or no decrease at all. The intention behind the decrease was to slow down blockchain growth, but with the blockchain already exceeding 100 GB, reducing the block size will not make it any smaller or easier to run a full node.Additionally, users point out that ISPs are implementing data and bandwidth caps, making it unlikely for users to start new full nodes regardless of any changes made to the block size. In response to the opposition, Andrew C modified Luke-jr's proposal to begin the increase steps at the current 1 MB limit and calculate increases based on the MTP (Median Time Past) of the activation block. This modified proposal aims to be less controversial while still allowing Bitcoin to scale.One of the main concerns raised against Luke-jr's proposal is the significant decrease in size that would occur if it were activated before 2024. In response to these objections, Andrew C. has come up with a modified version of the proposal. Andrew's modified proposal takes a different approach by starting the increase steps at the current 1,000,000 byte limit, rather than the initial proposal's 300,000 bytes. The time span for each increase remains the same, but now it will be calculated off of the Median Time Past (MTP) of the activation block, instead of following a fixed schedule from a fixed point in time.Despite these modifications, Luke-jr has expressed discontent with Andrew's version. He argues that it fails to address the current block size issues and that it is exclusively a hardfork, rendering the use of BIP 9 deployment unnecessary. Nevertheless, Andrew is hopeful that his modified proposal will be less controversial and will allow for progress towards scaling Bitcoin. The full text of the proposal, along with Andrew's implementation, can be found on Github, as provided in the link.Despite the differing opinions on block size, there is a consensus within the Bitcoin community that the issue needs to be addressed in order to facilitate the scaling of the network. 2017-02-10T10:33:52+00:00 + There has been a contentious debate within the Bitcoin community regarding Luke-jr's proposed block size BIP. The proposal suggests decreasing the block size, but many users argue that the current block size is already too small and would prefer an increase or no decrease at all. The intention behind the decrease was to slow down blockchain growth, but with the blockchain already exceeding 100 GB, reducing the block size will not make it any smaller or easier to run a full node.Additionally, users point out that ISPs are implementing data and bandwidth caps, making it unlikely for users to start new full nodes regardless of any changes made to the block size. In response to the opposition, Andrew C modified Luke-jr's proposal to begin the increase steps at the current 1 MB limit and calculate increases based on the MTP (Median Time Past) of the activation block. This modified proposal aims to be less controversial while still allowing Bitcoin to scale.One of the main concerns raised against Luke-jr's proposal is the significant decrease in size that would occur if it were activated before 2024. In response to these objections, Andrew C. has come up with a modified version of the proposal. Andrew's modified proposal takes a different approach by starting the increase steps at the current 1,000,000 byte limit, rather than the initial proposal's 300,000 bytes. The time span for each increase remains the same, but now it will be calculated off of the Median Time Past (MTP) of the activation block, instead of following a fixed schedule from a fixed point in time.Despite these modifications, Luke-jr has expressed discontent with Andrew's version. He argues that it fails to address the current block size issues and that it is exclusively a hardfork, rendering the use of BIP 9 deployment unnecessary. Nevertheless, Andrew is hopeful that his modified proposal will be less controversial and will allow for progress towards scaling Bitcoin. The full text of the proposal, along with Andrew's implementation, can be found on Github, as provided in the link.Despite the differing opinions on block size, there is a consensus within the Bitcoin community that the issue needs to be addressed in order to facilitate the scaling of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_BIP-Block75-New-algorithm.xml b/static/bitcoin-dev/Feb_2017/combined_BIP-Block75-New-algorithm.xml index bb696917b9..19b38502e4 100644 --- a/static/bitcoin-dev/Feb_2017/combined_BIP-Block75-New-algorithm.xml +++ b/static/bitcoin-dev/Feb_2017/combined_BIP-Block75-New-algorithm.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - BIP - 'Block75' - New algorithm - 2023-08-01T19:22:01.373245+00:00 - - Hampus Sjöberg 2017-02-13 11:21:44+00:00 - - - t. khan 2017-01-03 14:28:27+00:00 - - - Tom Zander 2017-01-02 22:33:16+00:00 - - - Tom Zander 2017-01-02 22:01:08+00:00 - - - Luke Dashjr 2017-01-02 21:19:10+00:00 - - - t. khan 2017-01-02 21:05:58+00:00 - - - t. khan 2017-01-02 20:41:42+00:00 - - - Tom Zander 2017-01-02 20:35:40+00:00 - - - Luke Dashjr 2017-01-02 20:04:56+00:00 - - - t. khan 2017-01-02 19:32:24+00:00 - - - Tom Zander 2017-01-02 19:01:11+00:00 - - - t. khan 2017-01-02 18:04:37+00:00 - + 2025-09-26T15:51:57.623781+00:00 + python-feedgen + + + [bitcoin-dev] BIP - 'Block75' - New algorithm t. khan + 2017-01-02T18:04:00.000Z + + + Tom Zander + 2017-01-02T19:01:00.000Z + + + t. khan + 2017-01-02T19:32:00.000Z + + + Luke Dashjr + 2017-01-02T20:04:00.000Z + + + Tom Zander + 2017-01-02T20:35:00.000Z + + + t. khan + 2017-01-02T20:41:00.000Z + + + t. khan + 2017-01-02T21:05:00.000Z + + + Luke Dashjr + 2017-01-02T21:19:00.000Z + + + Tom Zander + 2017-01-02T22:01:00.000Z + + + Tom Zander + 2017-01-02T22:33:00.000Z + + + t. khan + 2017-01-03T14:28:00.000Z + + + Hampus Sjöberg + 2017-02-13T11:21:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - BIP - 'Block75' - New algorithm - 2023-08-01T19:22:01.373245+00:00 + 2025-09-26T15:51:57.625052+00:00 - The discussion revolves around the control of miners over the block size limit in Bitcoin. The proposal of Block75 algorithm is analyzed, which aims to manage the maximum block size without human intervention. However, concerns are raised about the potential centralization and loss of transaction fees that may arise from increasing the block size. The debate also delves into the definition of "miner spam" and the need for evidence to support this claim. The importance of miners in determining the block size limit is emphasized, as they have a financial incentive to produce bigger blocks but also face the risk of orphaned blocks. A discussion on the bitcoin-dev mailing list focuses on whether the maximum block size limit should be part of the protocol or set by node operators as a policy. It is argued that rejecting a block based on a condition falls under the consensus protocol, while policies can vary between nodes without affecting block validity. The proposal of Block75 is criticized for giving miners complete control over the limit, contradicting the purpose of the block size limit to restrict miners and prevent spam. Another email exchange highlights the question of whether math or humans created Bitcoin. The writer argues that everything in Bitcoin is math except for the block size limit, which was a temporary solution at the time. The suggestion of a simple policy set by node operators is deemed unfeasible due to differing opinions and potential disasters. The role of miners in deciding the block size is discussed, as they earn more fee-based income with bigger blocks but also take on more risks.In a bitcoin-dev thread, a user proposes Block75 as a means to manage the maximum block size without human intervention. Some users express doubts about the proposal, stating that it gives miners control over the limit, which goes against the purpose of restricting miners. The importance of preventing a single nefarious miner from creating an overly large block is emphasized.The Block75 algorithm has undergone updates based on community feedback and simulations. The new algorithm aims to keep blocks 75% full by adjusting the maximum block size every 2016 blocks. The activation of the algorithm would require support from the majority of the last 1,000 blocks mined. The goal is to prevent a small mining pool from blocking the adoption of Block75 and mitigate risks associated with a hard fork. Questions are raised regarding compatibility with SegWit and the need for a minimum maximum block size. The community is encouraged to provide input on how the algorithm would behave in practice. The hope is that 2017 will mark the end of the block size debate. 2017-02-13T11:21:44+00:00 + The discussion revolves around the control of miners over the block size limit in Bitcoin. The proposal of Block75 algorithm is analyzed, which aims to manage the maximum block size without human intervention. However, concerns are raised about the potential centralization and loss of transaction fees that may arise from increasing the block size. The debate also delves into the definition of "miner spam" and the need for evidence to support this claim. The importance of miners in determining the block size limit is emphasized, as they have a financial incentive to produce bigger blocks but also face the risk of orphaned blocks. A discussion on the bitcoin-dev mailing list focuses on whether the maximum block size limit should be part of the protocol or set by node operators as a policy. It is argued that rejecting a block based on a condition falls under the consensus protocol, while policies can vary between nodes without affecting block validity. The proposal of Block75 is criticized for giving miners complete control over the limit, contradicting the purpose of the block size limit to restrict miners and prevent spam. Another email exchange highlights the question of whether math or humans created Bitcoin. The writer argues that everything in Bitcoin is math except for the block size limit, which was a temporary solution at the time. The suggestion of a simple policy set by node operators is deemed unfeasible due to differing opinions and potential disasters. The role of miners in deciding the block size is discussed, as they earn more fee-based income with bigger blocks but also take on more risks.In a bitcoin-dev thread, a user proposes Block75 as a means to manage the maximum block size without human intervention. Some users express doubts about the proposal, stating that it gives miners control over the limit, which goes against the purpose of restricting miners. The importance of preventing a single nefarious miner from creating an overly large block is emphasized.The Block75 algorithm has undergone updates based on community feedback and simulations. The new algorithm aims to keep blocks 75% full by adjusting the maximum block size every 2016 blocks. The activation of the algorithm would require support from the majority of the last 1,000 blocks mined. The goal is to prevent a small mining pool from blocking the adoption of Block75 and mitigate risks associated with a hard fork. Questions are raised regarding compatibility with SegWit and the need for a minimum maximum block size. The community is encouraged to provide input on how the algorithm would behave in practice. The hope is that 2017 will mark the end of the block size debate. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_BIP150-151-concerns-and-some-comments.xml b/static/bitcoin-dev/Feb_2017/combined_BIP150-151-concerns-and-some-comments.xml index 586febf24d..f2e5ed9eb8 100644 --- a/static/bitcoin-dev/Feb_2017/combined_BIP150-151-concerns-and-some-comments.xml +++ b/static/bitcoin-dev/Feb_2017/combined_BIP150-151-concerns-and-some-comments.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - BIP150/151 concerns and some comments - 2023-08-01T19:33:08.847167+00:00 - - Tom Zander 2017-02-16 15:10:46+00:00 - - - Jonas Schnelli 2017-02-14 21:01:51+00:00 - - - Tom Zander 2017-02-14 18:01:03+00:00 - - - Jonas Schnelli 2017-02-14 16:10:15+00:00 - + 2025-09-26T15:52:08.087913+00:00 + python-feedgen + + + [bitcoin-dev] BIP150/151 concerns and some comments Jonas Schnelli + 2017-02-14T16:10:00.000Z + + + Tom Zander + 2017-02-14T18:01:00.000Z + + + Jonas Schnelli + 2017-02-14T21:01:00.000Z + + + Tom Zander + 2017-02-16T15:10:00.000Z + + - python-feedgen + 2 Combined summary - BIP150/151 concerns and some comments - 2023-08-01T19:33:08.847167+00:00 + 2025-09-26T15:52:08.088624+00:00 - On February 14th, 2017, a potential security vulnerability with Simplified Payment Verification (SPV) clients was highlighted by Jonas Schnelli via bitcoin-dev mailing list. He warned that using current SPV clients could expose a user's complete wallet content to any network observer between the user and the connected node. This means that coffee shop owners, ISPs, and cellphone providers could potentially correlate a user's wallet with their other internet behavior. To address this issue, Tom Zander suggested allowing trusted users to connect on a different, encrypted connection similar to RPC.There have been concerns raised about BIP150/151 and its "identity system". Some worry that BIP150 could partition the network, but most of these worries are unfounded. Users already filter and authenticate peers using IP tables, the 'addnode' command, peer banning in app-layer, and fast block relay. BIP150 allows for switching from IP-based authentication to a secure form of authentication with pre-shared keys (ECDH). While there are debates about whether identity is something desired in Bitcoin, BIP150 introduces optional authentication over an EC pubkey that can be changed per network interface and only revealed to peers who have proven knowledge of the user's identity.It has been suggested that BIP150/151 is not necessary as Tor and STunnel already exist. However, using Tor for a single secure channel may be excessive. Additionally, not many SPV users have encrypted channels to trusted nodes currently. The main focus of Tor is on onion routing and anonymity, rather than securing individual channels. Some feel that BIP151 provides a false sense of security and lacks MITM detection. Although BIP151 does not have MITM detection, it does add complexity to attacks. Without BIP151, anyone can intercept and read the stream, whereas with BIP151, an attacker needs to actively substitute ephemeral keys in both directions, accepting the risk of being detected.There is a debate regarding the encryption of Bitcoin traffic since it is inherently trustless. However, using current SPV clients exposes wallet content to network observers. Some suggest using a different channel to communicate with a full node than the p2p layer, but this may be undesirable for end users. Keeping users on the p2p layer allows for future changes where they can contribute to the network. Additionally, having a trusted connection through the p2p layer enables fallback to non-trusted nodes if the trusted node becomes unreachable. 2017-02-16T15:10:46+00:00 + On February 14th, 2017, a potential security vulnerability with Simplified Payment Verification (SPV) clients was highlighted by Jonas Schnelli via bitcoin-dev mailing list. He warned that using current SPV clients could expose a user's complete wallet content to any network observer between the user and the connected node. This means that coffee shop owners, ISPs, and cellphone providers could potentially correlate a user's wallet with their other internet behavior. To address this issue, Tom Zander suggested allowing trusted users to connect on a different, encrypted connection similar to RPC.There have been concerns raised about BIP150/151 and its "identity system". Some worry that BIP150 could partition the network, but most of these worries are unfounded. Users already filter and authenticate peers using IP tables, the 'addnode' command, peer banning in app-layer, and fast block relay. BIP150 allows for switching from IP-based authentication to a secure form of authentication with pre-shared keys (ECDH). While there are debates about whether identity is something desired in Bitcoin, BIP150 introduces optional authentication over an EC pubkey that can be changed per network interface and only revealed to peers who have proven knowledge of the user's identity.It has been suggested that BIP150/151 is not necessary as Tor and STunnel already exist. However, using Tor for a single secure channel may be excessive. Additionally, not many SPV users have encrypted channels to trusted nodes currently. The main focus of Tor is on onion routing and anonymity, rather than securing individual channels. Some feel that BIP151 provides a false sense of security and lacks MITM detection. Although BIP151 does not have MITM detection, it does add complexity to attacks. Without BIP151, anyone can intercept and read the stream, whereas with BIP151, an attacker needs to actively substitute ephemeral keys in both directions, accepting the risk of being detected.There is a debate regarding the encryption of Bitcoin traffic since it is inherently trustless. However, using current SPV clients exposes wallet content to network observers. Some suggest using a different channel to communicate with a full node than the p2p layer, but this may be undesirable for end users. Keeping users on the p2p layer allows for future changes where they can contribute to the network. Additionally, having a trusted connection through the p2p layer enables fallback to non-trusted nodes if the trusted node becomes unreachable. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_BIP151-protocol-incompatibility.xml b/static/bitcoin-dev/Feb_2017/combined_BIP151-protocol-incompatibility.xml index c5f323aa7f..257a386588 100644 --- a/static/bitcoin-dev/Feb_2017/combined_BIP151-protocol-incompatibility.xml +++ b/static/bitcoin-dev/Feb_2017/combined_BIP151-protocol-incompatibility.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - BIP151 protocol incompatibility - 2023-08-01T19:32:50.588870+00:00 - - Jonas Schnelli 2017-02-14 20:58:54+00:00 - - - Eric Voskuil 2017-02-14 19:54:37+00:00 - - - Matt Corallo 2017-02-13 13:04:15+00:00 - - - Eric Voskuil 2017-02-13 11:17:11+00:00 - - - Jonas Schnelli 2017-02-13 11:14:01+00:00 - - - Matt Corallo 2017-02-13 11:11:11+00:00 - - - Eric Voskuil 2017-02-13 10:54:23+00:00 - - - Eric Voskuil 2017-02-13 10:30:14+00:00 - - - Matt Corallo 2017-02-13 10:16:13+00:00 - - - Jonas Schnelli 2017-02-13 10:07:12+00:00 - - - Eric Voskuil 2017-02-13 09:36:21+00:00 - - - Pieter Wuille 2017-02-13 08:47:38+00:00 - - - Eric Voskuil 2017-02-13 05:18:41+00:00 - + 2025-09-26T15:51:47.087472+00:00 + python-feedgen + + + [bitcoin-dev] BIP151 protocol incompatibility Eric Voskuil + 2017-02-13T05:18:00.000Z + + + Pieter Wuille + 2017-02-13T08:47:00.000Z + + + Eric Voskuil + 2017-02-13T09:36:00.000Z + + + Jonas Schnelli + 2017-02-13T10:07:00.000Z + + + Matt Corallo + 2017-02-13T10:16:00.000Z + + + Eric Voskuil + 2017-02-13T10:30:00.000Z + + + Eric Voskuil + 2017-02-13T10:54:00.000Z + + + Matt Corallo + 2017-02-13T11:11:00.000Z + + + Jonas Schnelli + 2017-02-13T11:14:00.000Z + + + Eric Voskuil + 2017-02-13T11:17:00.000Z + + + Matt Corallo + 2017-02-13T13:04:00.000Z + + + Eric Voskuil + 2017-02-14T19:54:00.000Z + + + Jonas Schnelli + 2017-02-14T20:58:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - BIP151 protocol incompatibility - 2023-08-01T19:32:50.589877+00:00 + 2025-09-26T15:51:47.088930+00:00 - In a discussion about the implementation of BIP151, which aims to improve security in communication between Bitcoin nodes by encrypting messages, concerns were raised regarding its backward compatibility. While some argued that allowing unknown messages in a protocol encourages protocol incompatibility and potential denial-of-service attacks, others believed that the exchange of otherwise-ignored messages for setting up optional features is a valid part of the version handshake and protocol negotiation.The conversation also touched on the fact that control messages apart from BIP151 are not sent until after the version is negotiated. It was noted that BIP151 negotiates encryption before any other communications, including the version handshake. The compatibility of feefilter BIP133 and sendheaders BIP130 with BIP151 was also discussed, with the consensus being that if these messages are received by a node below the version at which they are activated, they are considered unknown messages and indicate an invalid peer.There was debate regarding whether sending content that existing nodes do not expect constitutes an incompatibility. Some argued that this approach could leave the implementation vulnerable to DOS attacks, while others believed that it allows for a strict linear progression of allowed network protocol features. The importance of maintaining existing protocol behavior and soliciting community feedback before implementing changes that could break fundamental aspects of the P2P protocol handshake was emphasized.Overall, it was concluded that while the BIP151 proposal claims to be backward compatible, there are concerns regarding its compatibility and potential security implications. Further revisions and community feedback may be necessary before its implementation. 2017-02-14T20:58:54+00:00 + In a discussion about the implementation of BIP151, which aims to improve security in communication between Bitcoin nodes by encrypting messages, concerns were raised regarding its backward compatibility. While some argued that allowing unknown messages in a protocol encourages protocol incompatibility and potential denial-of-service attacks, others believed that the exchange of otherwise-ignored messages for setting up optional features is a valid part of the version handshake and protocol negotiation.The conversation also touched on the fact that control messages apart from BIP151 are not sent until after the version is negotiated. It was noted that BIP151 negotiates encryption before any other communications, including the version handshake. The compatibility of feefilter BIP133 and sendheaders BIP130 with BIP151 was also discussed, with the consensus being that if these messages are received by a node below the version at which they are activated, they are considered unknown messages and indicate an invalid peer.There was debate regarding whether sending content that existing nodes do not expect constitutes an incompatibility. Some argued that this approach could leave the implementation vulnerable to DOS attacks, while others believed that it allows for a strict linear progression of allowed network protocol features. The importance of maintaining existing protocol behavior and soliciting community feedback before implementing changes that could break fundamental aspects of the P2P protocol handshake was emphasized.Overall, it was concluded that while the BIP151 proposal claims to be backward compatible, there are concerns regarding its compatibility and potential security implications. Further revisions and community feedback may be necessary before its implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml b/static/bitcoin-dev/Feb_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml index f4364d22b6..fd368ef020 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml @@ -1,113 +1,147 @@ - + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 - - bfd at cock.lu 2017-04-01 23:49:03+00:00 - - - Tom Harding 2017-03-16 15:05:11+00:00 - - - bfd at cock.lu 2017-03-16 00:25:01+00:00 - - - Tom Harding 2017-03-15 22:36:09+00:00 - - - Chris Belcher 2017-02-17 00:28:59+00:00 - - - Erik Aronesty 2017-01-06 22:07:36+00:00 - - - Eric Voskuil 2017-01-06 21:50:47+00:00 - - - James MacWhyte 2017-01-06 21:35:58+00:00 - - - Chris Priest 2017-01-06 20:15:46+00:00 - - - Aaron Voisine 2017-01-06 07:07:34+00:00 - - - bfd at cock.lu 2017-01-06 02:15:26+00:00 - - - bfd at cock.lu 2017-01-06 02:04:22+00:00 - - - Christian Decker 2017-01-05 14:48:33+00:00 - - - Eric Voskuil 2017-01-05 07:45:18+00:00 - - - Chris Priest 2017-01-05 07:06:36+00:00 - - - Leo Wandersleb 2017-01-04 16:13:41+00:00 - - - Adam Back 2017-01-04 11:00:55+00:00 - - - Jorge Timón 2017-01-04 10:13:02+00:00 - - - Aaron Voisine 2017-01-04 08:56:21+00:00 - - - Jonas Schnelli 2017-01-04 07:47:10+00:00 - - - Eric Voskuil 2017-01-04 06:06:31+00:00 - - - Aaron Voisine 2017-01-04 00:36:34+00:00 - - - bfd at cock.lu 2017-01-04 00:10:14+00:00 - - - Aaron Voisine 2017-01-03 23:46:00+00:00 - - - adiabat 2017-01-03 23:06:26+00:00 - - - bfd at cock.lu 2017-01-03 22:28:56+00:00 - - - Aaron Voisine 2017-01-03 22:18:21+00:00 - - - bfd at cock.lu 2017-01-03 20:24:35+00:00 - - - bfd at cock.lu 2017-01-03 20:18:59+00:00 - - - Jonas Schnelli 2017-01-01 21:01:23+00:00 - - - Leo Wandersleb 2016-07-28 21:07:29+00:00 - - - Bob McElrath 2016-05-11 20:29:33+00:00 - - - Bob McElrath 2016-05-11 20:06:48+00:00 - - - Gregory Maxwell 2016-05-09 08:57:08+00:00 - - - bfd at cock.lu 2016-05-09 08:26:06+00:00 - + 2025-09-26T15:52:10.210896+00:00 + python-feedgen + + + [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd + 2016-05-09T08:26:00.000Z + + + Gregory Maxwell + 2016-05-09T08:57:00.000Z + + + Bob McElrath + 2016-05-11T20:06:00.000Z + + + Bob McElrath + 2016-05-11T20:29:00.000Z + + + Leo Wandersleb + 2016-07-28T21:07:00.000Z + + + bfd + 2017-01-03T20:18:00.000Z + + + bfd + 2017-01-03T20:24:00.000Z + + + Aaron Voisine + 2017-01-03T22:18:00.000Z + + + bfd + 2017-01-03T22:28:00.000Z + + + adiabat + 2017-01-03T23:06:00.000Z + + + Aaron Voisine + 2017-01-03T23:46:00.000Z + + + bfd + 2017-01-04T00:10:00.000Z + + + Aaron Voisine + 2017-01-04T00:36:00.000Z + + + Eric Voskuil + 2017-01-04T06:06:00.000Z + + + Jonas Schnelli + 2017-01-04T07:47:00.000Z + + + Aaron Voisine + 2017-01-04T08:56:00.000Z + + + Jorge Timón + 2017-01-04T10:13:00.000Z + + + Adam Back + 2017-01-04T11:00:00.000Z + + + Leo Wandersleb + 2017-01-04T16:13:00.000Z + + + Chris Priest + 2017-01-05T07:06:00.000Z + + + Eric Voskuil + 2017-01-05T07:45:00.000Z + + + Christian Decker + 2017-01-05T14:48:00.000Z + + + bfd + 2017-01-06T02:04:00.000Z + + + bfd + 2017-01-06T02:15:00.000Z + + + Aaron Voisine + 2017-01-06T07:07:00.000Z + + + Chris Priest + 2017-01-06T20:15:00.000Z + + + James MacWhyte + 2017-01-06T21:35:00.000Z + + + Eric Voskuil + 2017-01-06T21:50:00.000Z + + + Erik Aronesty + 2017-01-06T22:07:00.000Z + + + Chris Belcher + 2017-02-17T00:28:00.000Z + + + Tom Harding + 2017-03-15T22:36:00.000Z + + + bfd + 2017-03-16T00:25:00.000Z + + + Tom Harding + 2017-03-16T15:05:00.000Z + + + bfd + 2017-04-01T23:49:00.000Z + + @@ -143,13 +177,13 @@ - python-feedgen + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 + 2025-09-26T15:52:10.214382+00:00 - In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On 2017-04-01T23:49:03+00:00 + In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_Generalized-Commitments.xml b/static/bitcoin-dev/Feb_2017/combined_Generalized-Commitments.xml index 6e15a49390..7d66d305e9 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Generalized-Commitments.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Generalized-Commitments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Generalized Commitments - 2023-08-01T19:37:07.603099+00:00 + 2025-09-26T15:52:05.999759+00:00 + python-feedgen Bram Cohen 2017-02-23 02:56:35+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Generalized Commitments - 2023-08-01T19:37:07.603099+00:00 + 2025-09-26T15:52:05.999909+00:00 - Peter Todd suggests that a commitment scheme should ensure that two messages cannot map to the same commitment, rather than focusing on the difficulty of finding the message given the commitment. Additionally, he mentions that commitments do not need to be of the same size and proposes a scheme where the commitment to short messages is the message itself, with only one additional bit of data added to the minimum serialized size of the commitment.However, in order to maintain uniform size for all values, two bits of security need to be sacrificed to allow for four values: terminal, middle, empty, and invalid. For a set containing a single value, the root would be that value with the two high order bits of the first byte reset to the appropriate value.In the bitcoin-dev discussion, Bram Cohen introduces the concept of 'generalized commitment' as a use-case specific approach to reduce hashing requirements. The proposal suggests that when one side of a node is empty and the other contains exactly two things, the secure hash of the child is adopted without rehashing it. This can potentially halve the amount of hashing done and increase resistance to malicious data, although it does introduce extra complexity.Cohen emphasizes that a commitment scheme only needs to ensure that two messages cannot map to the same commitment, without requiring difficulty in finding the message given the commitment. He believes that designing a scheme where the commitment to short messages is the message itself, with just one additional bit of data, could lead to overall savings, especially for situations where sub-digest-sized messages are common.Furthermore, Cohen highlights that this approach also enhances user-friendliness because programmers will be able to notice when a commitment is not effectively hiding the message. However, if message privacy is essential, an explicit nonce should be implemented instead of relying solely on the data being non-brute-forcible.Finally, Cohen mentions his increasing consideration of bit-granularity serialization schemes for these types of systems, suggesting a potential direction for future development. 2017-02-23T02:56:35+00:00 + Peter Todd suggests that a commitment scheme should ensure that two messages cannot map to the same commitment, rather than focusing on the difficulty of finding the message given the commitment. Additionally, he mentions that commitments do not need to be of the same size and proposes a scheme where the commitment to short messages is the message itself, with only one additional bit of data added to the minimum serialized size of the commitment.However, in order to maintain uniform size for all values, two bits of security need to be sacrificed to allow for four values: terminal, middle, empty, and invalid. For a set containing a single value, the root would be that value with the two high order bits of the first byte reset to the appropriate value.In the bitcoin-dev discussion, Bram Cohen introduces the concept of 'generalized commitment' as a use-case specific approach to reduce hashing requirements. The proposal suggests that when one side of a node is empty and the other contains exactly two things, the secure hash of the child is adopted without rehashing it. This can potentially halve the amount of hashing done and increase resistance to malicious data, although it does introduce extra complexity.Cohen emphasizes that a commitment scheme only needs to ensure that two messages cannot map to the same commitment, without requiring difficulty in finding the message given the commitment. He believes that designing a scheme where the commitment to short messages is the message itself, with just one additional bit of data, could lead to overall savings, especially for situations where sub-digest-sized messages are common.Furthermore, Cohen highlights that this approach also enhances user-friendliness because programmers will be able to notice when a commitment is not effectively hiding the message. However, if message privacy is essential, an explicit nonce should be implemented instead of relying solely on the data being non-brute-forcible.Finally, Cohen mentions his increasing consideration of bit-granularity serialization schemes for these types of systems, suggesting a potential direction for future development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_Moving-towards-user-activated-soft-fork-activation.xml b/static/bitcoin-dev/Feb_2017/combined_Moving-towards-user-activated-soft-fork-activation.xml index 212f72f459..dc40a296c5 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Moving-towards-user-activated-soft-fork-activation.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Moving-towards-user-activated-soft-fork-activation.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Moving towards user activated soft fork activation - 2023-08-01T19:40:15.088441+00:00 - - shaolinfry 2017-03-12 15:47:28+00:00 - - - Alphonse Pace 2017-03-07 19:13:29+00:00 - - - Eric Voskuil 2017-03-07 18:13:36+00:00 - - - Eric Voskuil 2017-03-07 17:37:15+00:00 - - - Tom Zander 2017-03-07 09:17:18+00:00 - - - Edmund Edgar 2017-03-07 01:07:05+00:00 - - - Gareth Williams 2017-03-06 23:23:47+00:00 - - - Edmund Edgar 2017-03-06 10:29:35+00:00 - - - David Vorick 2017-03-06 09:18:38+00:00 - - - Nick ODell 2017-03-05 21:31:26+00:00 - - - Eric Voskuil 2017-03-05 18:48:33+00:00 - - - David Vorick 2017-03-05 18:10:15+00:00 - - - Chris Belcher 2017-03-05 14:33:06+00:00 - - - Luke Dashjr 2017-02-28 21:20:29+00:00 - - - Eric Voskuil 2017-02-27 16:50:07+00:00 - - - shaolinfry 2017-02-27 16:02:52+00:00 - - - Jameson Lopp 2017-02-26 17:34:57+00:00 - - - shaolinfry 2017-02-25 23:55:51+00:00 - + 2025-09-26T15:51:53.410765+00:00 + python-feedgen + + + [bitcoin-dev] Moving towards user activated soft fork activation shaolinfry + 2017-02-25T23:55:00.000Z + + + Jameson Lopp + 2017-02-26T17:34:00.000Z + + + shaolinfry + 2017-02-27T16:02:00.000Z + + + Eric Voskuil + 2017-02-27T16:50:00.000Z + + + Luke Dashjr + 2017-02-28T21:20:00.000Z + + + Chris Belcher + 2017-03-05T14:33:00.000Z + + + David Vorick + 2017-03-05T18:10:00.000Z + + + Eric Voskuil + 2017-03-05T18:48:00.000Z + + + Nick ODell + 2017-03-05T21:31:00.000Z + + + David Vorick + 2017-03-06T09:18:00.000Z + + + Edmund Edgar + 2017-03-06T10:29:00.000Z + + + Gareth Williams + 2017-03-06T23:23:00.000Z + + + Edmund Edgar + 2017-03-07T01:07:00.000Z + + + Tom Zander + 2017-03-07T09:17:00.000Z + + + Eric Voskuil + 2017-03-07T17:37:00.000Z + + + Eric Voskuil + 2017-03-07T18:13:00.000Z + + + Alphonse Pace + 2017-03-07T19:13:00.000Z + + + shaolinfry + 2017-03-12T15:47:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Moving towards user activated soft fork activation - 2023-08-01T19:40:15.088441+00:00 + 2025-09-26T15:51:53.412740+00:00 - The author of BIP9 has proposed an extension to the existing protocol that introduces an additional activation parameter for soft forks. The new parameter, called "activationtime," specifies a minimum median time past of a block at which the deployment should transition to the locked-in state. This allows full nodes to coordinate synchronized activation based on a median past time using the BIP9 state machine.The state transition workflow for this proposal is the same as in BIP9, except when the activation time is greater than zero. In such cases, the workflow will be DEFINED -> STARTED -> PRE_LOCK_IN -> LOCKED_IN -> ACTIVE. The guidelines suggest setting the activation time to some date in the future, which must be less than the BIP9 timeout.A living list of deployment proposals can be found on GitHub, and an optional mandatory signaling function is included in the reference implementation. The discussion on the Bitcoin-dev mailing list revolves around the possibility of a hash-minority attacking a hash-majority in Bitcoin. Some argue that it is impossible for non-mining users to attack miners, while others believe it is possible by refusing to buy their coinbase transaction.The majority of hash rate can choose to continue with old rules or not, and users are free to follow tighter rules than before or reject them. The disagreement can be resolved peacefully through unilateral separation. However, if the majority of users are hostile and reject blocks that miners create, then what the miners bring to the table is also removed. Bitcoin works when the majority of the hashpower and the (economic) majority of users are balanced in power and have their goals aligned. A hash-minority attacking the hash-majority is an attack upon Bitcoin as a whole and opens up the possibility of governments trying to push through changes in the same way.In another discussion on the Bitcoin-dev mailing list, participants debated whether a "hashpower activated soft fork to censor transactions" could be seen as censorship. One member argued that Bitcoin's defense against censorship and disruption is due to the broad distribution of over 50% of hash power among a large number of people. The conversation then turned to the idea that miners have no technical or ethical obligation to follow any particular set of rules. Instead, security is based on decentralization, not well-behaved people or software. They also noted that if every person on the planet was a miner, it would be much harder to achieve consensus on any proposed material change. Regardless, the nature of sound money is that it doesn't change.In another email thread, concerns were raised over hashpower activated soft forks to censor transactions in response to user-activated soft forks (UASF) that the majority of hashpower disagrees with. However, it was clarified that the suggestion was not to censor transactions but to change the form they take. It was argued that a set of users forcing miners to do something is silly, and a minority miner fraction forcing the majority to do something is equally silly. Responding to such attacks with a proof-of-work hard fork that would result in two chains, allowing the market to decide which one "wins," was suggested. It was emphasized that Bitcoin only works when the majority of hashpower and the economic majority of users are balanced in power and have their goals aligned.In an email exchange, participants discussed whether a "hashpower activated soft fork to censor transactions" could be seen as censorship. It was argued that Bitcoin's defense against censorship and disruption is due to the broad distribution of over 50% of hash power among a large number of people. The conversation then turned to the idea that miners have no technical or ethical obligation to follow any particular set of rules. Instead, security is based on decentralization, not well-behaved people or software. It was noted that if every person on the planet was a miner, it would be much harder to achieve consensus on any proposed material change. The nature of sound money is that it doesn't change.The concept of User Activated Soft Fork (UASF) in Bitcoin is seen as a positive development that aligns with the balance of powers in the cryptocurrency. Unlike hard forks, UASF provides an opt-in feature that appeals to users interested in participating in the fork. In a UASF, the segwit-valid chain will be favored over the segwit-invalid chain if it has more work, leading to the annihilation of the latter. Only miners who recode their software can initiate such a fork.The accidental fork created after BIP66 was short-lived and lasted only a few blocks. Segwit-invalid coins are considered riskier assets and have a lower price than segwit-valid coins. Investors demand higher risk premiums for holding them, and short sellers may sell down the price if the value goes to zero. Hashpower follows price in cryptocurrencies like Bitcoin, so the segwit-invalid chain will eventually be overtaken by a higher-hashrate chain. UASF should only proceed if a significant portion of the economic majority ensures 2017-03-12T15:47:28+00:00 + The author of BIP9 has proposed an extension to the existing protocol that introduces an additional activation parameter for soft forks. The new parameter, called "activationtime," specifies a minimum median time past of a block at which the deployment should transition to the locked-in state. This allows full nodes to coordinate synchronized activation based on a median past time using the BIP9 state machine.The state transition workflow for this proposal is the same as in BIP9, except when the activation time is greater than zero. In such cases, the workflow will be DEFINED -> STARTED -> PRE_LOCK_IN -> LOCKED_IN -> ACTIVE. The guidelines suggest setting the activation time to some date in the future, which must be less than the BIP9 timeout.A living list of deployment proposals can be found on GitHub, and an optional mandatory signaling function is included in the reference implementation. The discussion on the Bitcoin-dev mailing list revolves around the possibility of a hash-minority attacking a hash-majority in Bitcoin. Some argue that it is impossible for non-mining users to attack miners, while others believe it is possible by refusing to buy their coinbase transaction.The majority of hash rate can choose to continue with old rules or not, and users are free to follow tighter rules than before or reject them. The disagreement can be resolved peacefully through unilateral separation. However, if the majority of users are hostile and reject blocks that miners create, then what the miners bring to the table is also removed. Bitcoin works when the majority of the hashpower and the (economic) majority of users are balanced in power and have their goals aligned. A hash-minority attacking the hash-majority is an attack upon Bitcoin as a whole and opens up the possibility of governments trying to push through changes in the same way.In another discussion on the Bitcoin-dev mailing list, participants debated whether a "hashpower activated soft fork to censor transactions" could be seen as censorship. One member argued that Bitcoin's defense against censorship and disruption is due to the broad distribution of over 50% of hash power among a large number of people. The conversation then turned to the idea that miners have no technical or ethical obligation to follow any particular set of rules. Instead, security is based on decentralization, not well-behaved people or software. They also noted that if every person on the planet was a miner, it would be much harder to achieve consensus on any proposed material change. Regardless, the nature of sound money is that it doesn't change.In another email thread, concerns were raised over hashpower activated soft forks to censor transactions in response to user-activated soft forks (UASF) that the majority of hashpower disagrees with. However, it was clarified that the suggestion was not to censor transactions but to change the form they take. It was argued that a set of users forcing miners to do something is silly, and a minority miner fraction forcing the majority to do something is equally silly. Responding to such attacks with a proof-of-work hard fork that would result in two chains, allowing the market to decide which one "wins," was suggested. It was emphasized that Bitcoin only works when the majority of hashpower and the economic majority of users are balanced in power and have their goals aligned.In an email exchange, participants discussed whether a "hashpower activated soft fork to censor transactions" could be seen as censorship. It was argued that Bitcoin's defense against censorship and disruption is due to the broad distribution of over 50% of hash power among a large number of people. The conversation then turned to the idea that miners have no technical or ethical obligation to follow any particular set of rules. Instead, security is based on decentralization, not well-behaved people or software. It was noted that if every person on the planet was a miner, it would be much harder to achieve consensus on any proposed material change. The nature of sound money is that it doesn't change.The concept of User Activated Soft Fork (UASF) in Bitcoin is seen as a positive development that aligns with the balance of powers in the cryptocurrency. Unlike hard forks, UASF provides an opt-in feature that appeals to users interested in participating in the fork. In a UASF, the segwit-valid chain will be favored over the segwit-invalid chain if it has more work, leading to the annihilation of the latter. Only miners who recode their software can initiate such a fork.The accidental fork created after BIP66 was short-lived and lasted only a few blocks. Segwit-invalid coins are considered riskier assets and have a lower price than segwit-valid coins. Investors demand higher risk premiums for holding them, and short sellers may sell down the price if the value goes to zero. Hashpower follows price in cryptocurrencies like Bitcoin, so the segwit-invalid chain will eventually be overtaken by a higher-hashrate chain. UASF should only proceed if a significant portion of the economic majority ensures - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_Proof-of-Loss.xml b/static/bitcoin-dev/Feb_2017/combined_Proof-of-Loss.xml index 275b42b983..56d17cc407 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Proof-of-Loss.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Proof-of-Loss.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Proof-of-Loss - 2023-08-01T19:30:46.090435+00:00 - - Mirelo 2018-01-04 10:54:31+00:00 - - - Mirelo 2017-04-06 05:47:17+00:00 - - - Erik Aronesty 2017-04-06 02:43:18+00:00 - - - Mirelo 2017-04-05 19:12:20+00:00 - - - Mirelo 2017-02-04 12:39:45+00:00 - + 2025-09-26T15:51:59.714829+00:00 + python-feedgen + + + [bitcoin-dev] Proof-of-Loss Mirelo + 2017-02-04T12:39:00.000Z + + + Mirelo + 2017-04-05T19:12:00.000Z + + + Erik Aronesty + 2017-04-06T02:43:00.000Z + + + Mirelo + 2017-04-06T05:47:00.000Z + + + [bitcoin-dev] Proof-of-Loss Mirelo + 2018-01-04T10:54:00.000Z + + - python-feedgen + 2 Combined summary - Proof-of-Loss - 2023-08-01T19:30:46.091448+00:00 + 2025-09-26T15:51:59.715586+00:00 - Mirelo, the creator of Proof-of-Loss, has made revisions to the algorithm and is seeking feedback. The updated version includes a more explicit definition of transaction rights, an overview of how the algorithm works, and the incorporation of the current block height in the proof-of-loss data. Mirelo has requested feedback through his email or the links provided on the Proof-of-Loss homepage. The revised algorithm also corrects transaction prioritization and inactivity fees, as well as revises the design. Proof-of-Loss is an alternative consensus algorithm that aims to address the deficiencies of both proof-of-work and proof-of-stake. It tackles issues such as mining centralization and the "nothing at stake" problem. In an email to bitcoin-dev, Mirelo acknowledges that previous feedback indicated the article was difficult to comprehend, prompting him to make revisions. The new version clarifies transaction rights and provides an overview of the algorithm's functioning. Additionally, the inclusion of the current block height in the proof-of-loss data simplifies the enforcement of serial chaining without requiring additional block height information. The updated version can be accessed at https://proof-of-loss.money/. The revised Proof-of-Loss algorithm incorporates suggestions received from feedback. It addresses the need for a clearer definition of transaction rights and a comprehensive explanation of the algorithm's operation. The updated version also facilitates serial chaining through the integration of the current block height in the proof-of-loss data. Furthermore, it rectifies transaction prioritization by utilizing fees rather than rights, and includes adjustments to inactivity fees. The new version of the algorithm is available at https://proof-of-loss.money/. Proof-of-Loss presents a novel consensus algorithm that seeks to overcome the limitations of both proof-of-work and proof-of-stake. Its objective is to resolve issues such as the absence of an organic block size limit, risks associated with mining centralization, and the "nothing at stake" problem. A detailed explanation of the algorithm can be found on the proof-of-loss.money website. 2018-01-04T10:54:31+00:00 + Mirelo, the creator of Proof-of-Loss, has made revisions to the algorithm and is seeking feedback. The updated version includes a more explicit definition of transaction rights, an overview of how the algorithm works, and the incorporation of the current block height in the proof-of-loss data. Mirelo has requested feedback through his email or the links provided on the Proof-of-Loss homepage. The revised algorithm also corrects transaction prioritization and inactivity fees, as well as revises the design. Proof-of-Loss is an alternative consensus algorithm that aims to address the deficiencies of both proof-of-work and proof-of-stake. It tackles issues such as mining centralization and the "nothing at stake" problem. In an email to bitcoin-dev, Mirelo acknowledges that previous feedback indicated the article was difficult to comprehend, prompting him to make revisions. The new version clarifies transaction rights and provides an overview of the algorithm's functioning. Additionally, the inclusion of the current block height in the proof-of-loss data simplifies the enforcement of serial chaining without requiring additional block height information. The updated version can be accessed at https://proof-of-loss.money/. The revised Proof-of-Loss algorithm incorporates suggestions received from feedback. It addresses the need for a clearer definition of transaction rights and a comprehensive explanation of the algorithm's operation. The updated version also facilitates serial chaining through the integration of the current block height in the proof-of-loss data. Furthermore, it rectifies transaction prioritization by utilizing fees rather than rights, and includes adjustments to inactivity fees. The new version of the algorithm is available at https://proof-of-loss.money/. Proof-of-Loss presents a novel consensus algorithm that seeks to overcome the limitations of both proof-of-work and proof-of-stake. Its objective is to resolve issues such as the absence of an organic block size limit, risks associated with mining centralization, and the "nothing at stake" problem. A detailed explanation of the algorithm can be found on the proof-of-loss.money website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_Proof-of-Nodework-PoNW-a-method-to-trustlessly-reward-nodes-for-storing-and-verifying-the-blockchain.xml b/static/bitcoin-dev/Feb_2017/combined_Proof-of-Nodework-PoNW-a-method-to-trustlessly-reward-nodes-for-storing-and-verifying-the-blockchain.xml index d567e23da5..ba9312416a 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Proof-of-Nodework-PoNW-a-method-to-trustlessly-reward-nodes-for-storing-and-verifying-the-blockchain.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Proof-of-Nodework-PoNW-a-method-to-trustlessly-reward-nodes-for-storing-and-verifying-the-blockchain.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain - 2023-08-01T19:32:36.789676+00:00 - - Aymeric Vitte 2017-02-14 18:44:26+00:00 - - - Sergio Demian Lerner 2017-02-13 14:48:24+00:00 - - - John Hardy 2017-02-13 11:58:09+00:00 - - - Sergio Demian Lerner 2017-02-12 20:22:33+00:00 - - - John Hardy 2017-02-07 11:27:55+00:00 - + 2025-09-26T15:51:40.776674+00:00 + python-feedgen + + + [bitcoin-dev] Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain John Hardy + 2017-02-07T11:27:00.000Z + + + Sergio Demian Lerner + 2017-02-12T20:22:00.000Z + + + John Hardy + 2017-02-13T11:58:00.000Z + + + Sergio Demian Lerner + 2017-02-13T14:48:00.000Z + + + Aymeric Vitte + 2017-02-14T18:44:00.000Z + + - python-feedgen + 2 Combined summary - Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain - 2023-08-01T19:32:36.789676+00:00 + 2025-09-26T15:51:40.777390+00:00 - John Hardy proposed a method called Proof of Nodework (PoNW) to reward individual nodes for storing and verifying the blockchain. This method involves creating a separate block space called nodeblock, where nodes register their Bitcoin addresses through an addNode transaction along with a security deposit. The PoNW process begins once the addNode transaction is added to the blockchain. During each epoch of 2016 blocks, there is an extended window for PoNW transactions to be added to nodeblocks, reducing minor censorship. To prevent nodes from having multiple keys registered, the share of reward that a node receives is multiplied based on the number of blocks it performs PoNW on within an epoch.At the end of an epoch, after a wait period for any delayed or censored transactions or challenges to be included and settled, the reward calculation for each node can begin. The source and amount of the reward are still open for discussion, with possibilities including using the existing miner reward or implementing a special new tx donation fee for nodes.Sergio Demian Lerner responded to John's proposal by mentioning RSK platform, which has already implemented a similar system. RSK allocates 1% of the block reward to automatically reward full nodes. They are evaluating two systems: Proof of Unique Blockchain Storage (PoUBS) and traditional proof of retrievability. PoUBS uses asymmetric-time operations to encode the blockchain based on each user's public key, ensuring fast decoding but slow encoding. The second system requires ASIC-resistance assumptions.To prevent blockchain bloat, RSK designed an Ephemeral Payload transaction payload that gets discarded after N blocks if no smart contract references it. If referenced, it is solidified in the blockchain forever. RSK's short block interval of 10 seconds allows for quick and efficient execution of these processes, minimizing computation and storage requirements.Overall, both PoNW and RSK's system provide incentives for full nodes to participate in the network and contribute to its security and decentralization. The use of smart contracts, challenges, and rewards ensures the integrity of the system while minimizing blockchain bloat. 2017-02-14T18:44:26+00:00 + John Hardy proposed a method called Proof of Nodework (PoNW) to reward individual nodes for storing and verifying the blockchain. This method involves creating a separate block space called nodeblock, where nodes register their Bitcoin addresses through an addNode transaction along with a security deposit. The PoNW process begins once the addNode transaction is added to the blockchain. During each epoch of 2016 blocks, there is an extended window for PoNW transactions to be added to nodeblocks, reducing minor censorship. To prevent nodes from having multiple keys registered, the share of reward that a node receives is multiplied based on the number of blocks it performs PoNW on within an epoch.At the end of an epoch, after a wait period for any delayed or censored transactions or challenges to be included and settled, the reward calculation for each node can begin. The source and amount of the reward are still open for discussion, with possibilities including using the existing miner reward or implementing a special new tx donation fee for nodes.Sergio Demian Lerner responded to John's proposal by mentioning RSK platform, which has already implemented a similar system. RSK allocates 1% of the block reward to automatically reward full nodes. They are evaluating two systems: Proof of Unique Blockchain Storage (PoUBS) and traditional proof of retrievability. PoUBS uses asymmetric-time operations to encode the blockchain based on each user's public key, ensuring fast decoding but slow encoding. The second system requires ASIC-resistance assumptions.To prevent blockchain bloat, RSK designed an Ephemeral Payload transaction payload that gets discarded after N blocks if no smart contract references it. If referenced, it is solidified in the blockchain forever. RSK's short block interval of 10 seconds allows for quick and efficient execution of these processes, minimizing computation and storage requirements.Overall, both PoNW and RSK's system provide incentives for full nodes to participate in the network and contribute to its security and decentralization. The use of smart contracts, challenges, and rewards ensures the integrity of the system while minimizing blockchain bloat. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_SHA1-collisions-make-Git-vulnerable-to-attakcs-by-third-parties-not-just-repo-maintainers.xml b/static/bitcoin-dev/Feb_2017/combined_SHA1-collisions-make-Git-vulnerable-to-attakcs-by-third-parties-not-just-repo-maintainers.xml index 5552854a6f..57ad3cfc26 100644 --- a/static/bitcoin-dev/Feb_2017/combined_SHA1-collisions-make-Git-vulnerable-to-attakcs-by-third-parties-not-just-repo-maintainers.xml +++ b/static/bitcoin-dev/Feb_2017/combined_SHA1-collisions-make-Git-vulnerable-to-attakcs-by-third-parties-not-just-repo-maintainers.xml @@ -1,104 +1,139 @@ - + 2 Combined summary - SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers - 2023-08-01T19:38:33.391073+00:00 - - Henning Kopp 2017-02-27 09:15:29+00:00 - - - Steve Davis 2017-02-26 16:53:29+00:00 - - - Steve Davis 2017-02-26 07:16:37+00:00 - - - Pieter Wuille 2017-02-26 06:36:25+00:00 - - - Steve Davis 2017-02-26 06:26:45+00:00 - - - Leandro Coutinho 2017-02-25 23:09:18+00:00 - - - Ethan Heilman 2017-02-25 22:34:38+00:00 - - - Pieter Wuille 2017-02-25 22:14:44+00:00 - - - Steve Davis 2017-02-25 21:54:16+00:00 - - - Peter Todd 2017-02-25 21:40:18+00:00 - - - Steve Davis 2017-02-25 21:34:33+00:00 - - - Dave Scotese 2017-02-25 21:21:56+00:00 - - - Peter Todd 2017-02-25 21:04:06+00:00 - - - Peter Todd 2017-02-25 20:57:06+00:00 - - - Russell O'Connor 2017-02-25 20:53:12+00:00 - - - Watson Ladd 2017-02-25 20:42:56+00:00 - - - Peter Todd 2017-02-25 19:12:01+00:00 - - - Ethan Heilman 2017-02-25 18:36:49+00:00 - - - Alice Wonder 2017-02-25 18:19:11+00:00 - - - Shin'ichiro Matsuo 2017-02-25 17:45:36+00:00 - - - Ethan Heilman 2017-02-25 16:10:02+00:00 - - - Leandro Coutinho 2017-02-25 14:50:30+00:00 - - - Steve Davis 2017-02-25 12:04:28+00:00 - - - Peter Todd 2017-02-25 01:01:22+00:00 - - - Steve Davis 2017-02-24 23:49:36+00:00 - - - Aymeric Vitte 2017-02-24 17:29:50+00:00 - - - Tim Ruffing 2017-02-24 16:30:49+00:00 - - - Aymeric Vitte 2017-02-24 15:18:43+00:00 - - - Tim Ruffing 2017-02-24 10:04:54+00:00 - - - Aymeric Vitte 2017-02-23 23:57:45+00:00 - - - Peter Todd 2017-02-23 21:28:02+00:00 - - - Peter Todd 2017-02-23 18:14:09+00:00 - + 2025-09-26T15:51:55.528122+00:00 + python-feedgen + + + [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers Peter Todd + 2017-02-23T18:14:00.000Z + + + Peter Todd + 2017-02-23T21:28:00.000Z + + + Aymeric Vitte + 2017-02-23T23:57:00.000Z + + + Tim Ruffing + 2017-02-24T10:04:00.000Z + + + Aymeric Vitte + 2017-02-24T15:18:00.000Z + + + Tim Ruffing + 2017-02-24T16:30:00.000Z + + + Aymeric Vitte + 2017-02-24T17:29:00.000Z + + + Steve Davis + 2017-02-24T23:49:00.000Z + + + Peter Todd + 2017-02-25T01:01:00.000Z + + + Steve Davis + 2017-02-25T12:04:00.000Z + + + Leandro Coutinho + 2017-02-25T14:50:00.000Z + + + Ethan Heilman + 2017-02-25T16:10:00.000Z + + + Shin'ichiro Matsuo + 2017-02-25T17:45:00.000Z + + + Alice Wonder + 2017-02-25T18:19:00.000Z + + + Ethan Heilman + 2017-02-25T18:36:00.000Z + + + Peter Todd + 2017-02-25T19:12:00.000Z + + + Watson Ladd + 2017-02-25T20:42:00.000Z + + + Russell O'Connor + 2017-02-25T20:53:00.000Z + + + Peter Todd + 2017-02-25T20:57:00.000Z + + + Peter Todd + 2017-02-25T21:04:00.000Z + + + Dave Scotese + 2017-02-25T21:21:00.000Z + + + Steve Davis + 2017-02-25T21:34:00.000Z + + + Peter Todd + 2017-02-25T21:40:00.000Z + + + Steve Davis + 2017-02-25T21:54:00.000Z + + + Pieter Wuille + 2017-02-25T22:14:00.000Z + + + Ethan Heilman + 2017-02-25T22:34:00.000Z + + + Leandro Coutinho + 2017-02-25T23:09:00.000Z + + + Steve Davis + 2017-02-26T06:26:00.000Z + + + Pieter Wuille + 2017-02-26T06:36:00.000Z + + + Steve Davis + 2017-02-26T07:16:00.000Z + + + Steve Davis + 2017-02-26T16:53:00.000Z + + + Henning Kopp + 2017-02-27T09:15:00.000Z + + @@ -131,13 +166,13 @@ - python-feedgen + 2 Combined summary - SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers - 2023-08-01T19:38:33.392071+00:00 + 2025-09-26T15:51:55.531267+00:00 - The failure of crypto primitives in Bitcoin has been a topic of discussion, but a recent paper only highlighted the problems without providing any solutions. While contingency plans are available on the wiki, they lack detail and should be carefully evaluated. The length and algorithm of hash output play a crucial role in collision resistance. SHA-0 was found to be insecure in 2004, and extensive research has been done on SHA-1. It has been observed that SHA-2 is more resistant to collisions compared to SHA-1. RIPEMD160 also requires analysis and consideration of potential attacks.Currently, Bitcoin uses RIPEMD160(SHA256(msg)), which may make creating collisions more difficult than using RIPEMD160 alone. In an email conversation, Pieter Wuille explains that collision attacks are typical hash function breaks, while reducing single-key address security requires a preimage attack. There was a mistake made by a participant in calculating the unit operation, with the correct number of times being 2.9*10^42 instead of the original estimate of 2.4*10^18.Concerns have been raised about the 80-bit collision attack, which only applies to jointly constructed addresses like multisig P2SH. However, there is less certainty regarding the comparison between SHA1 and RIPEMD. Pieter Wuille is checking his own numbers and can see a vector. If RIPEMD is weakened in any way, single-key transactions could become vulnerable.In discussions between Steve Davis and Pieter Wuille, alternatives to RIPEMD160 are explored. Pieter emphasizes the need for any alternative to avoid using the 160-bit hash function. One suggestion is to use [, OP_CHECKSIG] as an alternative, but Pieter clarifies that this wouldn't address the issue with multisig P2SH addresses where the 80-bit collision attack applies. He states that for single-key addresses, preimage security is relied upon, and RIPEMD160 provides more security than ECDSA signatures.An unknown sender suggests an alternative to using RIPEMD160 in Bitcoin transactions by reverting to OP_CHECKSIG or later versions. However, they express concerns about introducing new issues while trying to solve the original problem. The use of RIPEMD160 is justified for its convenience and compactness.Splitting bitcoins into multiple addresses could reduce the computational cost of attacking Bitcoin. Google recently announced the first SHA1 collision attack, which involved nine quintillion SHA1 computations. In comparison, the richest Bitcoin address contains 124,178 BTC. It is important to expose potential attacks so that mitigations can be developed, even if the computational costs limit their real-world impact. Deploying segwit's 256-bit digests is suggested as a response, as it is already fully coded and ready to deploy.Pieter Wuille suggests moving from 80-bit collision resistance to 128-bit collision resistance in Bitcoin. He outlines the requirements for any alternative proposal and notes that most of these requirements have already been met by segwit. Any alternative would only apply to wallets that adopt it. Steve Davis expresses concerns about the time it would take for segwit to reach critical mass and suggests exploring alternative approaches. However, Pieter points out that any alternative approach would require significant work similar to what has already been done for segwit, making it the most viable option.In a discussion on the bitcoin-dev mailing list, the security level of RIPEMD160(SHA256(msg)) in relation to Bitcoin addresses is debated. While collisions are possible, it is argued that they do not cause harm to the Bitcoin network itself. However, more complex contracts like P2SH 2-of-2 multisig can be vulnerable to collision attacks. A commit-reveal mitigation is mentioned as a potential solution.Another discussion on the bitcoin-dev mailing list focuses on whether 160-bit security is sufficient for collision resistance in Bitcoin. Some argue that RIPEMD-160 is not adequate and suggest exploring alternatives. The potential vulnerability of tree objects is highlighted, as they can be constructed with garbage data at the end that many review tools may not detect. Implementing a technique similar to the one used in the Tor protocol, where progressive hash operations are performed on objects and the intermediary hash state is kept, is suggested as a possible mitigation.The recent SHA1 collision attack on Git has implications for maintainers and third-party submissions. It can be exploited in practice, especially with binary files where reviewers may not detect garbage data at the end of a file. If the attack can be expanded to constrained character sets like Unicode or ASCII, it could pose an even greater problem. The attack involves preparing a pair of files with the same SHA1 hash, submitting a pull request with the "clean" version of the file, and then replacing it with the malicious version after the merge. This method raises significant security concerns, as many review tools cannot detect the presence of garbage data at the end of tree objects. Maintainers and reviewers must 2017-02-27T09:15:29+00:00 + The failure of crypto primitives in Bitcoin has been a topic of discussion, but a recent paper only highlighted the problems without providing any solutions. While contingency plans are available on the wiki, they lack detail and should be carefully evaluated. The length and algorithm of hash output play a crucial role in collision resistance. SHA-0 was found to be insecure in 2004, and extensive research has been done on SHA-1. It has been observed that SHA-2 is more resistant to collisions compared to SHA-1. RIPEMD160 also requires analysis and consideration of potential attacks.Currently, Bitcoin uses RIPEMD160(SHA256(msg)), which may make creating collisions more difficult than using RIPEMD160 alone. In an email conversation, Pieter Wuille explains that collision attacks are typical hash function breaks, while reducing single-key address security requires a preimage attack. There was a mistake made by a participant in calculating the unit operation, with the correct number of times being 2.9*10^42 instead of the original estimate of 2.4*10^18.Concerns have been raised about the 80-bit collision attack, which only applies to jointly constructed addresses like multisig P2SH. However, there is less certainty regarding the comparison between SHA1 and RIPEMD. Pieter Wuille is checking his own numbers and can see a vector. If RIPEMD is weakened in any way, single-key transactions could become vulnerable.In discussions between Steve Davis and Pieter Wuille, alternatives to RIPEMD160 are explored. Pieter emphasizes the need for any alternative to avoid using the 160-bit hash function. One suggestion is to use [, OP_CHECKSIG] as an alternative, but Pieter clarifies that this wouldn't address the issue with multisig P2SH addresses where the 80-bit collision attack applies. He states that for single-key addresses, preimage security is relied upon, and RIPEMD160 provides more security than ECDSA signatures.An unknown sender suggests an alternative to using RIPEMD160 in Bitcoin transactions by reverting to OP_CHECKSIG or later versions. However, they express concerns about introducing new issues while trying to solve the original problem. The use of RIPEMD160 is justified for its convenience and compactness.Splitting bitcoins into multiple addresses could reduce the computational cost of attacking Bitcoin. Google recently announced the first SHA1 collision attack, which involved nine quintillion SHA1 computations. In comparison, the richest Bitcoin address contains 124,178 BTC. It is important to expose potential attacks so that mitigations can be developed, even if the computational costs limit their real-world impact. Deploying segwit's 256-bit digests is suggested as a response, as it is already fully coded and ready to deploy.Pieter Wuille suggests moving from 80-bit collision resistance to 128-bit collision resistance in Bitcoin. He outlines the requirements for any alternative proposal and notes that most of these requirements have already been met by segwit. Any alternative would only apply to wallets that adopt it. Steve Davis expresses concerns about the time it would take for segwit to reach critical mass and suggests exploring alternative approaches. However, Pieter points out that any alternative approach would require significant work similar to what has already been done for segwit, making it the most viable option.In a discussion on the bitcoin-dev mailing list, the security level of RIPEMD160(SHA256(msg)) in relation to Bitcoin addresses is debated. While collisions are possible, it is argued that they do not cause harm to the Bitcoin network itself. However, more complex contracts like P2SH 2-of-2 multisig can be vulnerable to collision attacks. A commit-reveal mitigation is mentioned as a potential solution.Another discussion on the bitcoin-dev mailing list focuses on whether 160-bit security is sufficient for collision resistance in Bitcoin. Some argue that RIPEMD-160 is not adequate and suggest exploring alternatives. The potential vulnerability of tree objects is highlighted, as they can be constructed with garbage data at the end that many review tools may not detect. Implementing a technique similar to the one used in the Tor protocol, where progressive hash operations are performed on objects and the intermediary hash state is kept, is suggested as a possible mitigation.The recent SHA1 collision attack on Git has implications for maintainers and third-party submissions. It can be exploited in practice, especially with binary files where reviewers may not detect garbage data at the end of a file. If the attack can be expanded to constrained character sets like Unicode or ASCII, it could pose an even greater problem. The attack involves preparing a pair of files with the same SHA1 hash, submitting a pull request with the "clean" version of the file, and then replacing it with the malicious version after the merge. This method raises significant security concerns, as many review tools cannot detect the presence of garbage data at the end of tree objects. Maintainers and reviewers must - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_Spoonnet-another-experimental-hardfork.xml b/static/bitcoin-dev/Feb_2017/combined_Spoonnet-another-experimental-hardfork.xml index e6979882e9..65bcd1f88a 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Spoonnet-another-experimental-hardfork.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Spoonnet-another-experimental-hardfork.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Spoonnet: another experimental hardfork - 2023-08-01T19:32:18.790817+00:00 - - Johnson Lau 2017-02-06 18:06:22+00:00 - - - Johnson Lau 2017-02-06 12:39:21+00:00 - + 2025-09-26T15:52:03.889867+00:00 + python-feedgen + + + [bitcoin-dev] Spoonnet: another experimental hardfork Johnson Lau + 2017-02-06T12:39:00.000Z + + + Johnson Lau + 2017-02-06T18:06:00.000Z + + - python-feedgen + 2 Combined summary - Spoonnet: another experimental hardfork - 2023-08-01T19:32:18.790817+00:00 + 2025-09-26T15:52:03.890393+00:00 - Bitcoin developers have proposed a series of consensus changes to the Bitcoin network, which are outlined in the bitcoin-dev mailing list. These changes include modifications to the pre-hardfork policy, sighash limitations, transaction weight definitions, and block weight growth over time.One proposal is to introduce a new extended and flexible header in the witness field of the coinbase transaction. This extended header allows miners to include any information they want, which bitcoin users can ignore. It also makes the network merge-mining friendly. Additionally, there is space for miners to include non-consensus enforced bitcoin-related data that is useful for fee estimation.Other proposed changes involve the coinbase transaction format and the witness merkle root. The sign bit in BIP9 would be ignored, and a full hardfork with more drastic changes would be implemented to address issues with SHA256 shortcut like ASICBoost and block withholding attacks.To activate the hard fork, at least 51% of miners are needed to build the new block format. The hard fork time is determined by a consensus of the community to prevent splitting. A special BIP9 softfork has been defined to relax the size limit of Header 2 and Header 3, allowing expansion without a hardfork. However, these changes would require firmware upgrades for all existing miners and light wallet upgrades, which are not expected to happen until at least two years after the initial activation of the hardfork.An experimental implementation of these proposals can be found on GitHub, but it is still untested and not independently reviewed. Therefore, it should not be used in production, although it may work fine on testnet.Furthermore, a new transaction weight formula encourages responsible use of UTXO, while the block size will grow linearly until a certain limit. There is also Sighash O(n^2) protection for legacy (non-segwit) outputs.Some aspects of the proposals are still under development, such as automated testing, post-hardfork support for old light wallets, and wallet support for anti-tx-replay. Additionally, there is no new p2p message to transmit the secondary header, and there is currently no full mining or mempool support.In summary, Bitcoin developers have proposed a hardfork to increase the block weight limit and make changes to the transaction and coinbase formats. These proposals aim to improve the efficiency and functionality of the Bitcoin network, but they are still in the development stage and should not be used in production at this time. 2017-02-06T18:06:22+00:00 + Bitcoin developers have proposed a series of consensus changes to the Bitcoin network, which are outlined in the bitcoin-dev mailing list. These changes include modifications to the pre-hardfork policy, sighash limitations, transaction weight definitions, and block weight growth over time.One proposal is to introduce a new extended and flexible header in the witness field of the coinbase transaction. This extended header allows miners to include any information they want, which bitcoin users can ignore. It also makes the network merge-mining friendly. Additionally, there is space for miners to include non-consensus enforced bitcoin-related data that is useful for fee estimation.Other proposed changes involve the coinbase transaction format and the witness merkle root. The sign bit in BIP9 would be ignored, and a full hardfork with more drastic changes would be implemented to address issues with SHA256 shortcut like ASICBoost and block withholding attacks.To activate the hard fork, at least 51% of miners are needed to build the new block format. The hard fork time is determined by a consensus of the community to prevent splitting. A special BIP9 softfork has been defined to relax the size limit of Header 2 and Header 3, allowing expansion without a hardfork. However, these changes would require firmware upgrades for all existing miners and light wallet upgrades, which are not expected to happen until at least two years after the initial activation of the hardfork.An experimental implementation of these proposals can be found on GitHub, but it is still untested and not independently reviewed. Therefore, it should not be used in production, although it may work fine on testnet.Furthermore, a new transaction weight formula encourages responsible use of UTXO, while the block size will grow linearly until a certain limit. There is also Sighash O(n^2) protection for legacy (non-segwit) outputs.Some aspects of the proposals are still under development, such as automated testing, post-hardfork support for old light wallets, and wallet support for anti-tx-replay. Additionally, there is no new p2p message to transmit the secondary header, and there is currently no full mining or mempool support.In summary, Bitcoin developers have proposed a hardfork to increase the block weight limit and make changes to the transaction and coinbase formats. These proposals aim to improve the efficiency and functionality of the Bitcoin network, but they are still in the development stage and should not be used in production at this time. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_TXO-commitments-do-not-need-a-soft-fork-to-be-useful.xml b/static/bitcoin-dev/Feb_2017/combined_TXO-commitments-do-not-need-a-soft-fork-to-be-useful.xml index 52afa4bedf..4e7fb18448 100644 --- a/static/bitcoin-dev/Feb_2017/combined_TXO-commitments-do-not-need-a-soft-fork-to-be-useful.xml +++ b/static/bitcoin-dev/Feb_2017/combined_TXO-commitments-do-not-need-a-soft-fork-to-be-useful.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - TXO commitments do not need a soft-fork to be useful - 2023-08-01T19:33:38.969799+00:00 - - Peter Todd 2017-05-16 12:23:53+00:00 - - - Alex Mizrahi 2017-05-16 12:15:17+00:00 - - - praxeology_guy 2017-02-28 16:26:40+00:00 - - - Peter Todd 2017-02-23 07:23:10+00:00 - - - Eric Lombrozo 2017-02-23 03:30:37+00:00 - - - Peter Todd 2017-02-23 01:11:47+00:00 - + 2025-09-26T15:51:51.292354+00:00 + python-feedgen + + + [bitcoin-dev] TXO commitments do not need a soft-fork to be useful Peter Todd + 2017-02-23T01:11:00.000Z + + + Eric Lombrozo + 2017-02-23T03:30:00.000Z + + + Peter Todd + 2017-02-23T07:23:00.000Z + + + praxeology_guy + 2017-02-28T16:26:00.000Z + + + Alex Mizrahi + 2017-05-16T12:15:00.000Z + + + Peter Todd + 2017-05-16T12:23:00.000Z + + - python-feedgen + 2 Combined summary - TXO commitments do not need a soft-fork to be useful - 2023-08-01T19:33:38.969799+00:00 + 2025-09-26T15:51:51.293177+00:00 - In a bitcoin-dev discussion thread, it has been pointed out that TXO commitments can be useful without the need for a consensus protocol change. This realization was shared by Alex Mizrahi, who noted that TXO commitments do not require changes to the consensus protocol to be valuable. It was also mentioned that Peter Todd had previously discussed the idea of a distributed file system in 2013, but his explanation may have been confusing to some due to its reference to a DHT. The importance of clear explanations and analogies was emphasized in the discussion.Another topic of discussion among the bitcoin-dev community is the usefulness of communicating the UTXO (Transaction Output). Praxeology suggested using commitments to incentivize miners to verify the UTXO. Praxeology wrote a detailed write-up called "Synchronization Checkpoints" on Github, outlining the idea. The proposal involves miners putting a commitment at the current Checkpoint Block, which would be a hash of the full state of the UTXO at the previous Checkpoint Block. To ensure high performance, Praxeology suggests maintaining a DB table for sorting the UTXO, waiting for no forks blocks after a CheckPoint Block is made, populating a new UTXO Checkpoint File, and using Merkle tree or bittorrent style hashing for the UTXO Checkpoint File.The discussion also touched on the possibility of implementing a cryptographic data structure to improve delayed TXO commitments using lazy hashing. The proposed data structure would replace commitments with pointers, combining a cryptographic data structure with a standard pointer-based data structure. However, one challenge is how to handle proofs, as the level of verification possible depends on the digests calculated by each node. This approach only works for data structures where the overall structure of the tree does not change as nodes are added and updated.The email thread posted on the Bitcoin-dev mailing list focuses on the implementation of TXO commitments in Bitcoin. Peter Todd proposed that TXO commitments can be implemented without miners committing to the TXO commitment itself. Instead, a TXO commitment allows the data set (TXO set) to be securely provided by an untrusted third party, allowing the data itself to be discarded. If a valid TXO commitment exists, the TXO data can be discarded and untrusted entities can provide that data on demand. Todd argues that this implementation would allow full nodes with limited storage space to keep track of a TXO commitment and prune older UTXOs that are unlikely to be spent. Transactions and blocks spending these UTXOs can trustlessly provide the necessary data to temporarily fill in the node's local TXO set database. Todd suggests a deployment plan for implementing a TXO commitment scheme, including P2P support for advertising pruned parts of the TXO set, and producing, consuming, and updating TXO unspentness proofs during transaction and block relaying.Todd also proposes that a snapshot with an attestation from trusted individuals is a better security model than having miners attest to validity. This security model is similar to the recently implemented -assumevalid scheme, where anyone with a full node can audit the validity of assumed valid TXO commitments. However, Todd acknowledges that this is a weaker security model as a false TXO commitment can more easily trick a node into accepting invalid transactions or blocks. A compromise could be using assumed valid TXO commitments and extending the suggestion of having nodes validate the chain backwards to eventually validate 100% of the chain. Todd provides references to related work on SPV bitcoind and the -assumevalid scheme.In conclusion, the discussions revolve around the potential usefulness of TXO commitments without consensus protocol changes, the implementation of a cryptographic data structure for delayed commitments, and the practicality of implementing a TXO commitment scheme in Bitcoin. 2017-05-16T12:23:53+00:00 + In a bitcoin-dev discussion thread, it has been pointed out that TXO commitments can be useful without the need for a consensus protocol change. This realization was shared by Alex Mizrahi, who noted that TXO commitments do not require changes to the consensus protocol to be valuable. It was also mentioned that Peter Todd had previously discussed the idea of a distributed file system in 2013, but his explanation may have been confusing to some due to its reference to a DHT. The importance of clear explanations and analogies was emphasized in the discussion.Another topic of discussion among the bitcoin-dev community is the usefulness of communicating the UTXO (Transaction Output). Praxeology suggested using commitments to incentivize miners to verify the UTXO. Praxeology wrote a detailed write-up called "Synchronization Checkpoints" on Github, outlining the idea. The proposal involves miners putting a commitment at the current Checkpoint Block, which would be a hash of the full state of the UTXO at the previous Checkpoint Block. To ensure high performance, Praxeology suggests maintaining a DB table for sorting the UTXO, waiting for no forks blocks after a CheckPoint Block is made, populating a new UTXO Checkpoint File, and using Merkle tree or bittorrent style hashing for the UTXO Checkpoint File.The discussion also touched on the possibility of implementing a cryptographic data structure to improve delayed TXO commitments using lazy hashing. The proposed data structure would replace commitments with pointers, combining a cryptographic data structure with a standard pointer-based data structure. However, one challenge is how to handle proofs, as the level of verification possible depends on the digests calculated by each node. This approach only works for data structures where the overall structure of the tree does not change as nodes are added and updated.The email thread posted on the Bitcoin-dev mailing list focuses on the implementation of TXO commitments in Bitcoin. Peter Todd proposed that TXO commitments can be implemented without miners committing to the TXO commitment itself. Instead, a TXO commitment allows the data set (TXO set) to be securely provided by an untrusted third party, allowing the data itself to be discarded. If a valid TXO commitment exists, the TXO data can be discarded and untrusted entities can provide that data on demand. Todd argues that this implementation would allow full nodes with limited storage space to keep track of a TXO commitment and prune older UTXOs that are unlikely to be spent. Transactions and blocks spending these UTXOs can trustlessly provide the necessary data to temporarily fill in the node's local TXO set database. Todd suggests a deployment plan for implementing a TXO commitment scheme, including P2P support for advertising pruned parts of the TXO set, and producing, consuming, and updating TXO unspentness proofs during transaction and block relaying.Todd also proposes that a snapshot with an attestation from trusted individuals is a better security model than having miners attest to validity. This security model is similar to the recently implemented -assumevalid scheme, where anyone with a full node can audit the validity of assumed valid TXO commitments. However, Todd acknowledges that this is a weaker security model as a false TXO commitment can more easily trick a node into accepting invalid transactions or blocks. A compromise could be using assumed valid TXO commitments and extending the suggestion of having nodes validate the chain backwards to eventually validate 100% of the chain. Todd provides references to related work on SPV bitcoind and the -assumevalid scheme.In conclusion, the discussions revolve around the potential usefulness of TXO commitments without consensus protocol changes, the implementation of a cryptographic data structure for delayed commitments, and the practicality of implementing a TXO commitment scheme in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_Three-hardfork-related-BIPs.xml b/static/bitcoin-dev/Feb_2017/combined_Three-hardfork-related-BIPs.xml index 8ee3b942a0..187016d678 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Three-hardfork-related-BIPs.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Three-hardfork-related-BIPs.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Three hardfork-related BIPs - 2023-08-01T19:28:00.093200+00:00 - - Staf Verhaegen 2017-02-11 15:26:33+00:00 - - - Eric Voskuil 2017-02-07 20:32:46+00:00 - - - mbtc-dev at xe0.me 2017-02-06 16:24:10+00:00 - - - David Vorick 2017-01-29 19:39:46+00:00 - - - Eric Voskuil 2017-01-29 19:37:07+00:00 - - - Tom Harding 2017-01-29 19:15:38+00:00 - - - Peter Todd 2017-01-28 21:54:00+00:00 - - - Luke Dashjr 2017-01-28 19:43:48+00:00 - - - Peter Todd 2017-01-28 18:29:32+00:00 - - - Peter Todd 2017-01-28 18:22:25+00:00 - - - Natanael 2017-01-28 10:36:16+00:00 - - - Luke Dashjr 2017-01-28 04:03:03+00:00 - - - Andrew Johnson 2017-01-27 23:53:02+00:00 - - - Christian Decker 2017-01-27 21:28:10+00:00 - - - Greg Sanders 2017-01-27 20:47:20+00:00 - - - Russell O'Connor 2017-01-27 20:34:13+00:00 - - - t. khan 2017-01-27 18:54:26+00:00 - - - Daniele Pinna 2017-01-27 12:12:57+00:00 - - - Andrew Johnson 2017-01-27 06:13:34+00:00 - - - Johnson Lau 2017-01-27 04:21:21+00:00 - - - Luke Dashjr 2017-01-27 04:14:16+00:00 - - - Andrew Johnson 2017-01-27 03:04:50+00:00 - - - Luke Dashjr 2017-01-27 01:06:59+00:00 - + 2025-09-26T15:52:12.328313+00:00 + python-feedgen + + + [bitcoin-dev] Three hardfork-related BIPs Luke Dashjr + 2017-01-27T01:06:00.000Z + + + Andrew Johnson + 2017-01-27T03:04:00.000Z + + + Luke Dashjr + 2017-01-27T04:14:00.000Z + + + Johnson Lau + 2017-01-27T04:21:00.000Z + + + Andrew Johnson + 2017-01-27T06:13:00.000Z + + + Daniele Pinna + 2017-01-27T12:12:00.000Z + + + t. khan + 2017-01-27T18:54:00.000Z + + + Russell O'Connor + 2017-01-27T20:34:00.000Z + + + Greg Sanders + 2017-01-27T20:47:00.000Z + + + Christian Decker + 2017-01-27T21:28:00.000Z + + + Andrew Johnson + 2017-01-27T23:53:00.000Z + + + Luke Dashjr + 2017-01-28T04:03:00.000Z + + + Natanael + 2017-01-28T10:36:00.000Z + + + Peter Todd + 2017-01-28T18:22:00.000Z + + + Peter Todd + 2017-01-28T18:29:00.000Z + + + Luke Dashjr + 2017-01-28T19:43:00.000Z + + + Peter Todd + 2017-01-28T21:54:00.000Z + + + Tom Harding + 2017-01-29T19:15:00.000Z + + + Eric Voskuil + 2017-01-29T19:37:00.000Z + + + David Vorick + 2017-01-29T19:39:00.000Z + + + mbtc-dev + 2017-02-06T16:24:00.000Z + + + Eric Voskuil + 2017-02-07T20:32:00.000Z + + + Staf Verhaegen + 2017-02-11T15:26:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - Three hardfork-related BIPs - 2023-08-01T19:28:00.093200+00:00 + 2025-09-26T15:52:12.330739+00:00 - A recent research paper has established that the maximum block size that the Bitcoin network can handle safely is conservatively no more than 4MB. However, this conclusion only takes into account a subset of possible metrics and may be viewed as an upper bound. The paper does not discuss mining centralization pressure or DoS attacks, which are important factors to consider when determining the safe block size limit.There has been disagreement over a hardfork proposal submitted by Luke Dashjr to gradually increase the block size limit to 31MB while extending witness discount to non-segwit transactions. Critics argue that this proposal may alienate miners, assumes the current 1MB limit is already at its upper limit, and lacks incentives for individuals to run full nodes. They believe that the proposal would hinder Bitcoin Core and drive miners towards using Unlimited instead.Luke Dashjr has proposed three hardfork-related BIPs to address the block size issue. The first proposal suggests reducing the block size limit initially to a more sustainable size and gradually increasing it to 31 MB over time. The second proposal allows certain hardforks to be transformed into softforks in the future. The third proposal aims to prevent replay attacks induced by a hardfork-related chain split or in ordinary operation. Dashjr recommends immediate adoption of the first proposal but welcomes review and suggested changes.In response to criticism, Luke Dashjr clarified that his proposal to reduce the block size limit to 300KB would only occur if it activates before April 2017. He believes that such a reduction would be beneficial for the network in the long-term by squeezing out spam and unsustainable microtransaction use. Dashjr disagrees with claims that the network is already at capacity and argues that a reduction in block size could address these concerns.The current block size limit of 1MB is a point of contention, with some arguing it is too small and others arguing it is too big. However, alternatives to reducing the block size exist, such as blockchain pruning and limiting UTXO size. Luke Dashjr's proposals provide potential solutions to the block size issue, but further review and feedback are needed.Overall, the block size debate in the Bitcoin community continues, with different proposals and viewpoints being discussed. 2017-02-11T15:26:33+00:00 + A recent research paper has established that the maximum block size that the Bitcoin network can handle safely is conservatively no more than 4MB. However, this conclusion only takes into account a subset of possible metrics and may be viewed as an upper bound. The paper does not discuss mining centralization pressure or DoS attacks, which are important factors to consider when determining the safe block size limit.There has been disagreement over a hardfork proposal submitted by Luke Dashjr to gradually increase the block size limit to 31MB while extending witness discount to non-segwit transactions. Critics argue that this proposal may alienate miners, assumes the current 1MB limit is already at its upper limit, and lacks incentives for individuals to run full nodes. They believe that the proposal would hinder Bitcoin Core and drive miners towards using Unlimited instead.Luke Dashjr has proposed three hardfork-related BIPs to address the block size issue. The first proposal suggests reducing the block size limit initially to a more sustainable size and gradually increasing it to 31 MB over time. The second proposal allows certain hardforks to be transformed into softforks in the future. The third proposal aims to prevent replay attacks induced by a hardfork-related chain split or in ordinary operation. Dashjr recommends immediate adoption of the first proposal but welcomes review and suggested changes.In response to criticism, Luke Dashjr clarified that his proposal to reduce the block size limit to 300KB would only occur if it activates before April 2017. He believes that such a reduction would be beneficial for the network in the long-term by squeezing out spam and unsustainable microtransaction use. Dashjr disagrees with claims that the network is already at capacity and argues that a reduction in block size could address these concerns.The current block size limit of 1MB is a point of contention, with some arguing it is too small and others arguing it is too big. However, alternatives to reducing the block size exist, such as blockchain pruning and limiting UTXO size. Luke Dashjr's proposals provide potential solutions to the block size issue, but further review and feedback are needed.Overall, the block size debate in the Bitcoin community continues, with different proposals and viewpoints being discussed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2017/combined_Transaction-signalling-through-output-address-hashing.xml b/static/bitcoin-dev/Feb_2017/combined_Transaction-signalling-through-output-address-hashing.xml index c3667595cd..3087b1d6cc 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Transaction-signalling-through-output-address-hashing.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Transaction-signalling-through-output-address-hashing.xml @@ -1,27 +1,37 @@ - + 2 Combined summary - Transaction signalling through output address hashing - 2023-08-01T19:30:29.017919+00:00 - - Andrew C 2017-02-05 16:26:30+00:00 - - - Natanael 2017-02-05 16:22:11+00:00 - - - John Hardy 2017-02-03 00:13:04+00:00 - + 2025-09-26T15:52:01.804054+00:00 + python-feedgen + + + [bitcoin-dev] Transaction signalling through output address hashing John Hardy + 2017-02-03T00:13:00.000Z + + + Natanael + 2017-02-05T16:22:00.000Z + + + [bitcoin-dev] " Andrew C + 2017-02-05T16:26:00.000Z + + + [bitcoin-dev] Fw: " John Hardy + 2017-02-05T21:06:00.000Z + + - python-feedgen + 2 Combined summary - Transaction signalling through output address hashing - 2023-08-01T19:30:29.017919+00:00 + 2025-09-26T15:52:01.804770+00:00 - In a recent post on the bitcoin-dev mailing list, John Hardy has proposed a solution to the issue of only miners being able to signal support for changes to Bitcoin through BIP9. Currently, the rest of the community is not able to participate in consensus, and other methods of assessing community support are easily manipulated through Sybil. Hardy's proposal suggests using the output address of a transaction to signal support for a particular proposal, drawing inspiration from hashcash and vanity addresses.The idea behind this proposal is that generating an address with four consecutive case-insensitive characters would require approximately 34^4 attempts, which can be done in less than a second on typical hardware. The popularity of a proposal could then be measured by the fee paid per voting kb, weighted by popularity. This approach would provide an accessible way for the entire economic community to signal their support within transactions without requiring a hard fork or increasing the size of transactions.However, there are potential challenges with this system. It could be easily gamed by spammers and miners who have control over which transactions they include in their blocks. Additionally, existing and normal transactions may collide with these schemes, and most wallets do not currently have a straightforward way of supporting this method. Censorship by miners is also identified as a problem.Despite these limitations, Hardy's proposal offers an accessible and cost-effective way for the entire economic community to participate in signaling their support for changes in Bitcoin. If considered effective, it could also be used to activate changes in the future. 2017-02-05T16:26:30+00:00 + In a recent post on the bitcoin-dev mailing list, John Hardy has proposed a solution to the issue of only miners being able to signal support for changes to Bitcoin through BIP9. Currently, the rest of the community is not able to participate in consensus, and other methods of assessing community support are easily manipulated through Sybil. Hardy's proposal suggests using the output address of a transaction to signal support for a particular proposal, drawing inspiration from hashcash and vanity addresses.The idea behind this proposal is that generating an address with four consecutive case-insensitive characters would require approximately 34^4 attempts, which can be done in less than a second on typical hardware. The popularity of a proposal could then be measured by the fee paid per voting kb, weighted by popularity. This approach would provide an accessible way for the entire economic community to signal their support within transactions without requiring a hard fork or increasing the size of transactions.However, there are potential challenges with this system. It could be easily gamed by spammers and miners who have control over which transactions they include in their blocks. Additionally, existing and normal transactions may collide with these schemes, and most wallets do not currently have a straightforward way of supporting this method. Censorship by miners is also identified as a problem.Despite these limitations, Hardy's proposal offers an accessible and cost-effective way for the entire economic community to participate in signaling their support for changes in Bitcoin. If considered effective, it could also be used to activate changes in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_-BIP-Stratum-protocol-specification.xml b/static/bitcoin-dev/Feb_2018/combined_-BIP-Stratum-protocol-specification.xml index 569ccd2953..6fb19fa8d1 100644 --- a/static/bitcoin-dev/Feb_2018/combined_-BIP-Stratum-protocol-specification.xml +++ b/static/bitcoin-dev/Feb_2018/combined_-BIP-Stratum-protocol-specification.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - [BIP] Stratum protocol specification - 2023-08-01T22:37:39.252143+00:00 - - Sergio Demian Lerner 2018-02-13 00:54:00+00:00 - - - Jules Lamur 2018-02-09 13:48:39+00:00 - + 2025-09-26T15:40:14.546107+00:00 + python-feedgen + + + [bitcoin-dev] [BIP] Stratum protocol specification Jules Lamur + 2018-02-09T13:48:00.000Z + + + Sergio Demian Lerner + 2018-02-13T00:54:00.000Z + + - python-feedgen + 2 Combined summary - [BIP] Stratum protocol specification - 2023-08-01T22:37:39.252143+00:00 + 2025-09-26T15:40:14.546522+00:00 - Jules Lamur, a student working on developing a mining pool with two colleagues, has expressed concern about the lack of documentation on existing protocol implementations. In an email exchange on the bitcoin-dev mailing list, Jules discussed the need to rectify this issue by publishing a specification for the protocol. While Jules' professor suggested publishing an IETF RFC draft for the protocol's specification, Jules believes that a Bitcoin Improvement Proposal (BIP) would be more appropriate.Upon further investigation, Jules discovered that BIP 40 and BIP 41 were allocated for the wire protocol and mining protocol respectively back in August 2013. However, no progress has been made since then. In light of this, Jules and his colleagues are considering writing a draft for BIP 41 (mining protocol) themselves.In addition to their work on the mining pool, Jules and his colleagues have also been involved in developing extensions for RSK merge mining. As part of this process, they have prepared an internal document with the most up-to-date Straum protocol description. This document can be accessed at the provided link.Overall, Jules Lamur and his colleagues are taking proactive steps to address the lack of documentation in existing protocol implementations. They are considering writing a draft for BIP 41 (mining protocol), while also working on extensions for RSK merge mining. By doing so, they aim to contribute to the development and improvement of the Bitcoin ecosystem. 2018-02-13T00:54:00+00:00 + Jules Lamur, a student working on developing a mining pool with two colleagues, has expressed concern about the lack of documentation on existing protocol implementations. In an email exchange on the bitcoin-dev mailing list, Jules discussed the need to rectify this issue by publishing a specification for the protocol. While Jules' professor suggested publishing an IETF RFC draft for the protocol's specification, Jules believes that a Bitcoin Improvement Proposal (BIP) would be more appropriate.Upon further investigation, Jules discovered that BIP 40 and BIP 41 were allocated for the wire protocol and mining protocol respectively back in August 2013. However, no progress has been made since then. In light of this, Jules and his colleagues are considering writing a draft for BIP 41 (mining protocol) themselves.In addition to their work on the mining pool, Jules and his colleagues have also been involved in developing extensions for RSK merge mining. As part of this process, they have prepared an internal document with the most up-to-date Straum protocol description. This document can be accessed at the provided link.Overall, Jules Lamur and his colleagues are taking proactive steps to address the lack of documentation in existing protocol implementations. They are considering writing a draft for BIP 41 (mining protocol), while also working on extensions for RSK merge mining. By doing so, they aim to contribute to the development and improvement of the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Alternative-way-to-count-sigops.xml b/static/bitcoin-dev/Feb_2018/combined_Alternative-way-to-count-sigops.xml index f1b9a33e1d..c0b4f51cf1 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Alternative-way-to-count-sigops.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Alternative-way-to-count-sigops.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Alternative way to count sigops - 2023-08-01T22:44:24.984635+00:00 - - Gregory Maxwell 2018-02-17 02:33:32+00:00 - - - Johnson Lau 2018-02-16 22:49:17+00:00 - + 2025-09-26T15:39:45.236472+00:00 + python-feedgen + + + [bitcoin-dev] Alternative way to count sigops Johnson Lau + 2018-02-16T22:49:00.000Z + + + Gregory Maxwell + 2018-02-17T02:33:00.000Z + + - python-feedgen + 2 Combined summary - Alternative way to count sigops - 2023-08-01T22:44:24.984635+00:00 + 2025-09-26T15:39:45.236911+00:00 - In a recent discussion on the bitcoin-dev forum, Johnson Lau highlighted the current limitations on block weight and sigops. Currently, the block weight limit is set at 4,000,000, with a sigop limit of 80,000. This means that each sigop cannot use more than 50 weight units. To address new script proposals, there is a suggestion to count the actual number of sigops during execution and ensure that the total number of executed sigops multiplied by 50 does not exceed the size of the input.Bitcoin Core has had a related policy rule in place for some time, where the weight of a transaction for mining purposes is determined by max(weight, lambda*sigops). However, lambda has been set lower than ideal due to limitations in checkmultisig. This policy replaced an earlier rule that rejected transactions with too many sigops per byte count, but it was found to block valid transactions. Moving forward, this framework may not be ideal as new operation proposals may require additional input but have relatively small computational costs, such as aggregation.In the early days of Bitcoin, Satoshi implemented sigops counting as a softfork to limit the number of signature operations in a block. However, this counting method was not contextual, resulting in an overestimation of the cost of multi-signature transactions and counting of sigops in unexecuted branches. As P2SH (Pay-to-Script-Hash) was introduced, sigop counting also encompassed the sigop redeemScript, improving the counting of OP_CHECKMULTISIG but making counting without the UTXO (Unspent Transaction Output) set impossible.Segwit (BIP141) addressed this issue by scaling the legacy sigop limit by 4x, with a new block limit of 80,000 sigops. Despite this improvement, implementing static sigop counting for second-generation script proposals like BIP114, BIP117, and taproot is challenging. However, it is still necessary to have a limit for more complex script functions in order to prevent unexpected Denial-of-Service (DoS) attacks.A proposal suggests that each sigop should not consume more than 50 weight units on average, with a per-input limit of (164 + input witness size) >= (actual_sigop * 50), where script validation is parallel. In cases where many signatures are aggregated, the 1:50 ratio may not be sufficient, and it could be reduced to 1:32 or lower to ensure that legitimate usage does not exceed the limit. This approach would allow relay nodes to determine if a transaction requires excessive CPU power by simply examining its size. If it does, the transaction would be considered invalid, and script execution could be terminated early. 2018-02-17T02:33:32+00:00 + In a recent discussion on the bitcoin-dev forum, Johnson Lau highlighted the current limitations on block weight and sigops. Currently, the block weight limit is set at 4,000,000, with a sigop limit of 80,000. This means that each sigop cannot use more than 50 weight units. To address new script proposals, there is a suggestion to count the actual number of sigops during execution and ensure that the total number of executed sigops multiplied by 50 does not exceed the size of the input.Bitcoin Core has had a related policy rule in place for some time, where the weight of a transaction for mining purposes is determined by max(weight, lambda*sigops). However, lambda has been set lower than ideal due to limitations in checkmultisig. This policy replaced an earlier rule that rejected transactions with too many sigops per byte count, but it was found to block valid transactions. Moving forward, this framework may not be ideal as new operation proposals may require additional input but have relatively small computational costs, such as aggregation.In the early days of Bitcoin, Satoshi implemented sigops counting as a softfork to limit the number of signature operations in a block. However, this counting method was not contextual, resulting in an overestimation of the cost of multi-signature transactions and counting of sigops in unexecuted branches. As P2SH (Pay-to-Script-Hash) was introduced, sigop counting also encompassed the sigop redeemScript, improving the counting of OP_CHECKMULTISIG but making counting without the UTXO (Unspent Transaction Output) set impossible.Segwit (BIP141) addressed this issue by scaling the legacy sigop limit by 4x, with a new block limit of 80,000 sigops. Despite this improvement, implementing static sigop counting for second-generation script proposals like BIP114, BIP117, and taproot is challenging. However, it is still necessary to have a limit for more complex script functions in order to prevent unexpected Denial-of-Service (DoS) attacks.A proposal suggests that each sigop should not consume more than 50 weight units on average, with a per-input limit of (164 + input witness size) >= (actual_sigop * 50), where script validation is parallel. In cases where many signatures are aggregated, the 1:50 ratio may not be sufficient, and it could be reduced to 1:32 or lower to ensure that legitimate usage does not exceed the limit. This approach would allow relay nodes to determine if a transaction requires excessive CPU power by simply examining its size. If it does, the transaction would be considered invalid, and script execution could be terminated early. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Amend-the-BIP-123-process-to-include-buried-deployments.xml b/static/bitcoin-dev/Feb_2018/combined_Amend-the-BIP-123-process-to-include-buried-deployments.xml index ea26e7000b..d5927a33b0 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Amend-the-BIP-123-process-to-include-buried-deployments.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Amend-the-BIP-123-process-to-include-buried-deployments.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Amend the BIP 123 process to include buried deployments - 2023-08-01T22:44:02.071141+00:00 - - Eric Voskuil 2018-02-21 17:27:53+00:00 - - - Marco Falke 2018-02-18 18:57:03+00:00 - - - Eric Voskuil 2018-02-14 23:57:10+00:00 - - - Gregory Maxwell 2018-02-14 22:20:31+00:00 - - - Luke Dashjr 2018-02-14 22:11:42+00:00 - - - Marco Falke 2018-02-14 22:01:46+00:00 - + 2025-09-26T15:40:20.873728+00:00 + python-feedgen + + + [bitcoin-dev] Amend the BIP 123 process to include buried deployments Marco Falke + 2018-02-14T22:01:00.000Z + + + Luke Dashjr + 2018-02-14T22:11:00.000Z + + + Gregory Maxwell + 2018-02-14T22:20:00.000Z + + + Eric Voskuil + 2018-02-14T23:57:00.000Z + + + Marco Falke + 2018-02-18T18:57:00.000Z + + + Eric Voskuil + 2018-02-21T17:27:00.000Z + + - python-feedgen + 2 Combined summary - Amend the BIP 123 process to include buried deployments - 2023-08-01T22:44:02.071141+00:00 + 2025-09-26T15:40:20.874553+00:00 - In a recent discussion on the bitcoin-dev mailing list, the topic of documenting buried deployments using BIPs (Bitcoin Improvement Proposals) was brought up. Buried deployments refer to changes in consensus rules that impact the validity of blocks buried by a sufficient number of blocks in the most-work chain. The question was raised as to whether BIPs are necessary for these types of deployments since they do not require software coordination.While some participants argued against the need for BIPs, noting that buried deployments do not require community and miner coordination, others believed that documentation is important for consensus rules and that the BIPs repository would be a suitable place to host these documents. To prevent an overload of BIPs, related buried deployments could be bundled together.It was emphasized that buried deployments should not be labeled as "soft forks" or "hard forks" since they do not require community and miner coordination. Instead, they should be treated as an independent category. However, it was noted that regardless of their classification, buried deployments cannot prevent massive chain reorganizations in the event of a security breach.The discussion then delved into the depth assumption required to ensure that buried deployments do not result in a chain split. It was suggested that multiplying the expected number of blocks in two weeks by 10 or 20 could be an appropriate lower bound. There was also debate over whether the threshold of 25,000 blocks is an objective measure to avoid a chain split.Furthermore, there were differing opinions on whether a massive chain reorganization must occur off of a block in the very past for a chain fork to happen due to a buried deployment, or if a buried deployment is a subjective subcategory of a hard fork. It was acknowledged that in the unlikely event of such a large chain reorganization, Bitcoin's general security assumptions would be violated regardless of the presence of a buried deployment.Marco Falke, a participant in the discussion, defined buried deployments as consensus rule changes that affect the validity of blocks buried by a sufficient number of blocks in the most-work chain. However, there were concerns raised about the assumption that only blocks deeper than the most recent 25,000 need to be validated, as it relies on relying on an authority like Bitcoin Core to determine the checkpoint for tip-25,000.Falke also argued against categorizing buried deployments as soft forks or hard forks, due to their lack of community and miner coordination. He suggested that BIPs for buried deployments could be added to the existing soft fork/hard fork BIP as an Annex, instead of creating separate BIPs. The importance of clear documentation was emphasized to prevent inaccurate analyses and potential consequences.In conclusion, the discussion revolved around the necessity of using BIPs to document buried deployments, whether they should be classified as soft or hard forks, and the depth assumption required to avoid chain splits. It was noted that buried deployments do not require community and miner coordination, but cannot prevent massive chain reorganizations. Clear documentation was highlighted as crucial for understanding the Bitcoin system and ensuring accurate safety analyses. 2018-02-21T17:27:53+00:00 + In a recent discussion on the bitcoin-dev mailing list, the topic of documenting buried deployments using BIPs (Bitcoin Improvement Proposals) was brought up. Buried deployments refer to changes in consensus rules that impact the validity of blocks buried by a sufficient number of blocks in the most-work chain. The question was raised as to whether BIPs are necessary for these types of deployments since they do not require software coordination.While some participants argued against the need for BIPs, noting that buried deployments do not require community and miner coordination, others believed that documentation is important for consensus rules and that the BIPs repository would be a suitable place to host these documents. To prevent an overload of BIPs, related buried deployments could be bundled together.It was emphasized that buried deployments should not be labeled as "soft forks" or "hard forks" since they do not require community and miner coordination. Instead, they should be treated as an independent category. However, it was noted that regardless of their classification, buried deployments cannot prevent massive chain reorganizations in the event of a security breach.The discussion then delved into the depth assumption required to ensure that buried deployments do not result in a chain split. It was suggested that multiplying the expected number of blocks in two weeks by 10 or 20 could be an appropriate lower bound. There was also debate over whether the threshold of 25,000 blocks is an objective measure to avoid a chain split.Furthermore, there were differing opinions on whether a massive chain reorganization must occur off of a block in the very past for a chain fork to happen due to a buried deployment, or if a buried deployment is a subjective subcategory of a hard fork. It was acknowledged that in the unlikely event of such a large chain reorganization, Bitcoin's general security assumptions would be violated regardless of the presence of a buried deployment.Marco Falke, a participant in the discussion, defined buried deployments as consensus rule changes that affect the validity of blocks buried by a sufficient number of blocks in the most-work chain. However, there were concerns raised about the assumption that only blocks deeper than the most recent 25,000 need to be validated, as it relies on relying on an authority like Bitcoin Core to determine the checkpoint for tip-25,000.Falke also argued against categorizing buried deployments as soft forks or hard forks, due to their lack of community and miner coordination. He suggested that BIPs for buried deployments could be added to the existing soft fork/hard fork BIP as an Annex, instead of creating separate BIPs. The importance of clear documentation was emphasized to prevent inaccurate analyses and potential consequences.In conclusion, the discussion revolved around the necessity of using BIPs to document buried deployments, whether they should be classified as soft or hard forks, and the depth assumption required to avoid chain splits. It was noted that buried deployments do not require community and miner coordination, but cannot prevent massive chain reorganizations. Clear documentation was highlighted as crucial for understanding the Bitcoin system and ensuring accurate safety analyses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_BIP0008-clarification.xml b/static/bitcoin-dev/Feb_2018/combined_BIP0008-clarification.xml index 3a1331d778..55ec749702 100644 --- a/static/bitcoin-dev/Feb_2018/combined_BIP0008-clarification.xml +++ b/static/bitcoin-dev/Feb_2018/combined_BIP0008-clarification.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP0008 clarification - 2023-08-01T22:36:49.545403+00:00 - - ZmnSCPxj 2018-02-13 03:26:47+00:00 - - - Helder Garcia 2018-02-08 02:49:45+00:00 - + 2025-09-26T15:39:51.497304+00:00 + python-feedgen + + + [bitcoin-dev] BIP0008 clarification Helder Garcia + 2018-02-08T02:49:00.000Z + + + ZmnSCPxj + 2018-02-13T03:26:00.000Z + + - python-feedgen + 2 Combined summary - BIP0008 clarification - 2023-08-01T22:36:49.545403+00:00 + 2025-09-26T15:39:51.497885+00:00 - During a conversation with ZmnSCPxj, Helder Garcia seeks clarification on the signalling and activation process of updates in Bitcoin. ZmnSCPxj explains that even if the 95% signalling threshold is not met during the STARTED state, an update will still be activated once the blockchain height reaches or surpasses the timeout_height. This means that the update will proceed regardless of whether the majority of hash power accepts it.However, ZmnSCPxj highlights that if the update is widely adopted by economic actors, miners who do not comply with the new rules will face consequences. Their blocks are likely to deviate from the updated rules and consequently be rejected by economic actors. In contrast, rational miners, regardless of their small share of hash power, would prefer to build on blocks that strictly adhere to the updated rules. They understand that economic actors will only accept such blocks as valid.The time period between the STARTED and ACTIVE states serves the purpose of allowing miners to upgrade their software. This concession recognizes that deploying new software across the entire network cannot be done safely in a single day.Overall, Helder learns that an update can be activated without reaching the 95% signalling threshold if the blockchain height meets the timeout_height condition. While there may be a risk associated with activating a change without majority acceptance, rational miners who follow the update's rules will prioritize building on blocks accepted by economic actors. The gradual transition from STARTED to ACTIVE provides miners with the necessary time to upgrade their software. 2018-02-13T03:26:47+00:00 + During a conversation with ZmnSCPxj, Helder Garcia seeks clarification on the signalling and activation process of updates in Bitcoin. ZmnSCPxj explains that even if the 95% signalling threshold is not met during the STARTED state, an update will still be activated once the blockchain height reaches or surpasses the timeout_height. This means that the update will proceed regardless of whether the majority of hash power accepts it.However, ZmnSCPxj highlights that if the update is widely adopted by economic actors, miners who do not comply with the new rules will face consequences. Their blocks are likely to deviate from the updated rules and consequently be rejected by economic actors. In contrast, rational miners, regardless of their small share of hash power, would prefer to build on blocks that strictly adhere to the updated rules. They understand that economic actors will only accept such blocks as valid.The time period between the STARTED and ACTIVE states serves the purpose of allowing miners to upgrade their software. This concession recognizes that deploying new software across the entire network cannot be done safely in a single day.Overall, Helder learns that an update can be activated without reaching the 95% signalling threshold if the blockchain height meets the timeout_height condition. While there may be a risk associated with activating a change without majority acceptance, rational miners who follow the update's rules will prioritize building on blocks accepted by economic actors. The gradual transition from STARTED to ACTIVE provides miners with the necessary time to upgrade their software. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Built-in-encryption.xml b/static/bitcoin-dev/Feb_2018/combined_Built-in-encryption.xml index 59d367e8ba..86d68ec282 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Built-in-encryption.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Built-in-encryption.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Built in encryption - 2023-08-01T22:45:16.666021+00:00 - - Lucas Clemente Vella 2018-02-19 20:11:56+00:00 - - - Ilan Oh 2018-02-19 09:21:34+00:00 - + 2025-09-26T15:40:08.248271+00:00 + python-feedgen + + + [bitcoin-dev] Built in encryption Ilan Oh + 2018-02-19T09:21:00.000Z + + + Lucas Clemente Vella + 2018-02-19T20:11:00.000Z + + - python-feedgen + 2 Combined summary - Built in encryption - 2023-08-01T22:45:16.666021+00:00 + 2025-09-26T15:40:08.248734+00:00 - In a recent post on the bitcoin-dev mailing list, a user raised an interesting question regarding the possibility of encrypting data in Bitcoin transactions in such a way that only the intended recipient can access it. The user specifically emphasized the need for a solution that does not require exchanging information off the network. In response to this query, a suggestion was made that if the recipient's address had already disclosed or shared their public key with the sender alongside the address, the sender could potentially encrypt the message using Elliptic Curve Cryptography (ECC) and the recipient's ECDSA key.Theoretically, this approach seems feasible as both ECDSA and ECC utilize the same kind of public/private key pair. However, the practicality of this method remains uncertain due to concerns about whether nodes would broadcast a non-standard transaction of this nature. The email also touched upon the possibility of utilizing a sidechain or RSK (Rootstock) for encryption purposes. These alternative solutions might offer more flexibility and support for encrypted transactions.The original post not only sought answers to the technical feasibility of encrypting text data within Bitcoin transactions but also highlighted the writer's concrete use cases for such encryption. Additionally, the writer encouraged other members to share their ideas and suggestions on this topic. With the potential benefits of secure, on-chain encryption in mind, this discussion opens up possibilities for innovative applications within the Bitcoin ecosystem. 2018-02-19T20:11:56+00:00 + In a recent post on the bitcoin-dev mailing list, a user raised an interesting question regarding the possibility of encrypting data in Bitcoin transactions in such a way that only the intended recipient can access it. The user specifically emphasized the need for a solution that does not require exchanging information off the network. In response to this query, a suggestion was made that if the recipient's address had already disclosed or shared their public key with the sender alongside the address, the sender could potentially encrypt the message using Elliptic Curve Cryptography (ECC) and the recipient's ECDSA key.Theoretically, this approach seems feasible as both ECDSA and ECC utilize the same kind of public/private key pair. However, the practicality of this method remains uncertain due to concerns about whether nodes would broadcast a non-standard transaction of this nature. The email also touched upon the possibility of utilizing a sidechain or RSK (Rootstock) for encryption purposes. These alternative solutions might offer more flexibility and support for encrypted transactions.The original post not only sought answers to the technical feasibility of encrypting text data within Bitcoin transactions but also highlighted the writer's concrete use cases for such encryption. Additionally, the writer encouraged other members to share their ideas and suggestions on this topic. With the potential benefits of secure, on-chain encryption in mind, this discussion opens up possibilities for innovative applications within the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Electrum-Personal-Server-alpha-release.xml b/static/bitcoin-dev/Feb_2018/combined_Electrum-Personal-Server-alpha-release.xml index 4a68a1e73a..924a1d56ef 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Electrum-Personal-Server-alpha-release.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Electrum-Personal-Server-alpha-release.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Electrum Personal Server alpha release - 2023-08-01T22:37:09.996851+00:00 - - Jonas Schnelli 2018-02-08 20:22:38+00:00 - - - Chris Belcher 2018-02-08 16:51:59+00:00 - + 2025-09-26T15:39:57.768078+00:00 + python-feedgen + + + [bitcoin-dev] Electrum Personal Server alpha release Chris Belcher + 2018-02-08T16:51:00.000Z + + + Jonas Schnelli + 2018-02-08T20:22:00.000Z + + - python-feedgen + 2 Combined summary - Electrum Personal Server alpha release - 2023-08-01T22:37:09.996851+00:00 + 2025-09-26T15:39:57.768608+00:00 - Two different approaches to improving Bitcoin wallet security have been proposed recently. The first proposal involves running a Bitcoin Core instance either with internal support for the proposed interface or via an external script (Python bridge). This approach allows for the creation of new wallets, the addition of addresses to a wallet as watch-only, and the creation of new transactions through the interface using fundrawtransaction with watch-only-addresses in the background.The second approach is Electrum Personal Server, which is an implementation of the Electrum server protocol that allows users to use the Electrum UI with full node verification and privacy, but without the heavyweight server backend, for a single user. This means users can benefit from all of Bitcoin Core's resource-saving features like pruning, blocksonly, and disabled txindex, while still being able to use Electrum's feature-richness like hardware wallet integration, multisignature wallets, offline signing, mnemonic recovery phrases, and more.One of the main issues with the widely used bitcoin wallet, Electrum, is that it relies on third-party servers for synchronization, posing potential security risks. These servers can trick Electrum wallets into accepting fake bitcoin transactions and can also compromise user privacy since wallets send all their bitcoin addresses to the server. To avoid these problems, users can run their own Electrum server and connect their wallets only to it. However, this requires significant resource usage and the server must always be online.To address these challenges, Electrum Personal Server has been introduced. It allows users to enjoy the resource-saving features of Bitcoin Core, such as pruning, blocksonly, and disabled txindex, while using their own full node. By configuring Electrum Personal Server with their master public key and importing those addresses into Bitcoin Core as watch-only, users can continue to use Electrum's features without relying on third-party servers.Although using Electrum Personal Server trades away Electrum's "instant on" feature for full node verification and privacy, it remains the most resource-efficient way to use a hardware wallet connected to your own full node. An alpha version of Electrum Personal Server is available on the repository for users to try.In addition to Electrum, similar ideas could be applied to other lightweight wallets. For example, a full node running on smartphones with pruning and blocksonly could be connected to Samourai Wallet, Breadwallet, or GreenAddress app using a similar script. This would provide users with enhanced security and privacy while still enjoying the convenience of lightweight wallets.Overall, these proposed approaches aim to improve Bitcoin wallet security by allowing users to run their own full nodes and connect their wallets directly to them. This reduces reliance on third-party servers and enhances user control over their funds and privacy. 2018-02-08T20:22:38+00:00 + Two different approaches to improving Bitcoin wallet security have been proposed recently. The first proposal involves running a Bitcoin Core instance either with internal support for the proposed interface or via an external script (Python bridge). This approach allows for the creation of new wallets, the addition of addresses to a wallet as watch-only, and the creation of new transactions through the interface using fundrawtransaction with watch-only-addresses in the background.The second approach is Electrum Personal Server, which is an implementation of the Electrum server protocol that allows users to use the Electrum UI with full node verification and privacy, but without the heavyweight server backend, for a single user. This means users can benefit from all of Bitcoin Core's resource-saving features like pruning, blocksonly, and disabled txindex, while still being able to use Electrum's feature-richness like hardware wallet integration, multisignature wallets, offline signing, mnemonic recovery phrases, and more.One of the main issues with the widely used bitcoin wallet, Electrum, is that it relies on third-party servers for synchronization, posing potential security risks. These servers can trick Electrum wallets into accepting fake bitcoin transactions and can also compromise user privacy since wallets send all their bitcoin addresses to the server. To avoid these problems, users can run their own Electrum server and connect their wallets only to it. However, this requires significant resource usage and the server must always be online.To address these challenges, Electrum Personal Server has been introduced. It allows users to enjoy the resource-saving features of Bitcoin Core, such as pruning, blocksonly, and disabled txindex, while using their own full node. By configuring Electrum Personal Server with their master public key and importing those addresses into Bitcoin Core as watch-only, users can continue to use Electrum's features without relying on third-party servers.Although using Electrum Personal Server trades away Electrum's "instant on" feature for full node verification and privacy, it remains the most resource-efficient way to use a hardware wallet connected to your own full node. An alpha version of Electrum Personal Server is available on the repository for users to try.In addition to Electrum, similar ideas could be applied to other lightweight wallets. For example, a full node running on smartphones with pruning and blocksonly could be connected to Samourai Wallet, Breadwallet, or GreenAddress app using a similar script. This would provide users with enhanced security and privacy while still enjoying the convenience of lightweight wallets.Overall, these proposed approaches aim to improve Bitcoin wallet security by allowing users to run their own full nodes and connect their wallets directly to them. This reduces reliance on third-party servers and enhances user control over their funds and privacy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Graftroot-Private-and-efficient-surrogate-scripts-under-the-taproot-assumption.xml b/static/bitcoin-dev/Feb_2018/combined_Graftroot-Private-and-efficient-surrogate-scripts-under-the-taproot-assumption.xml index a02d8e21dd..57a9b726d8 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Graftroot-Private-and-efficient-surrogate-scripts-under-the-taproot-assumption.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Graftroot-Private-and-efficient-surrogate-scripts-under-the-taproot-assumption.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Graftroot: Private and efficient surrogate scripts under the taproot assumption - 2023-08-01T22:36:03.841733+00:00 - - Sjors Provoost 2018-06-30 11:49:36+00:00 - - - Gregory Maxwell 2018-02-24 18:58:59+00:00 - - - Daniel Edgecumbe 2018-02-22 19:44:21+00:00 - - - Ryan Grant 2018-02-22 12:19:36+00:00 - - - Jeremy 2018-02-09 07:42:52+00:00 - - - Jeremy 2018-02-09 07:29:58+00:00 - - - Gregory Maxwell 2018-02-05 19:58:24+00:00 - - - Ryan Grant 2018-02-05 15:56:23+00:00 - - - Gregory Maxwell 2018-02-05 05:58:43+00:00 - + 2025-09-26T15:39:49.411137+00:00 + python-feedgen + + + [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption Gregory Maxwell + 2018-02-05T05:58:00.000Z + + + Ryan Grant + 2018-02-05T15:56:00.000Z + + + Gregory Maxwell + 2018-02-05T19:58:00.000Z + + + Jeremy + 2018-02-09T07:29:00.000Z + + + Jeremy + 2018-02-09T07:42:00.000Z + + + Ryan Grant + 2018-02-22T12:19:00.000Z + + + Daniel Edgecumbe + 2018-02-22T19:44:00.000Z + + + Gregory Maxwell + 2018-02-24T18:58:00.000Z + + + Sjors Provoost + 2018-06-30T11:49:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Graftroot: Private and efficient surrogate scripts under the taproot assumption - 2023-08-01T22:36:03.841733+00:00 + 2025-09-26T15:39:49.412266+00:00 - On February 22nd, 2018, a suggestion was made by Jeremy on the Bitcoin-dev list to improve the utility of a construction by introducing functionality that makes a script invalid after a certain time. This suggestion was discussed in a thread tagged with "nExpiryTime" and users were encouraged to search the archives for more information. The term "fill-or-kill transaction" was also mentioned in a previous discussion on the same list in September 2015. The post was signed off by Sjors.In a recent email conversation on the bitcoin-dev mailing list, Daniel Edgecumbe proposed a method to bind grafts to a specific transaction without requiring aggregation. He suggested signing H(txid, script) instead of H(script), but its impact on aggregation is unknown. This method requires knowing the txid in advance, which can be handled by a graftroot sighash flag. However, in most cases, the txid is not known. Another alternative solution is signing a transaction spending the multisig coin to the graft, but it lacks atomicity, scalability, and privacy. The advantage of the aggregation approach is that it works just in time even on grafts created in advance. A non-interactive schnorr aggregation trick can be used to merge the S values of all graftroots and signatures into a single aggregate, reducing overhead to ~32 bytes, similar to taproot's overhead.The discussion on the Bitcoin-dev mailing list focuses on the case where a delegate is signed conditional on another delegate being signed. Participants suggest the need for something like segwit internally to refer to one side's delegation using a signature-stable identity, but no good solution is currently available. Another point raised in the discussion is the introduction of functionality to make a script invalid after a certain time, allowing exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. This construction enables unilateral key rotation without invalidating the interests of other parties in the existing multisig, requiring only storing the signed delegation.The email thread discusses the introduction of functionality to make a script invalid after a certain time, which can enhance the utility of a construction despite previous re-org behavior. Proposed timelocks would be valid before a certain time or block height and invalid after, allowing for exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. Unilateral key rotation is possible in a multisig setup without invalidating the interests of other parties, as long as all parties agree to add a new key while still allowing the old key to sign.The context suggests the existence of a method that enables unilateral key rotation in a multisig setup without invalidating the interests of other parties. This method does not require any on-chain transactions but involves storing the signed delegation. The Taproot protocol provides only one alternative natively, while the Graftroot protocol allows for an unlimited number of alternatives while maintaining efficiency and privacy. With Graftroot, participants can delegate their ability to sign to a surrogate script by signing just the script with their taproot key and sharing the delegation. When spending the coin, if the signers aren't available, the redeeming party satisfies the script and presents the information along with the signer's signature. Non-interactive schnorr aggregation can be applied to merge the S values of all graftroots and signatures into a single aggregate, lowering overhead to ~32 bytes. However, this approach requires interaction with participants and storage of resulting signatures. Graftroot allows delegation before or after the fact and requires storage. The potential for unexpected surrogate replay and the existence of unused surrogates are considerations to keep in mind. 2018-06-30T11:49:36+00:00 + On February 22nd, 2018, a suggestion was made by Jeremy on the Bitcoin-dev list to improve the utility of a construction by introducing functionality that makes a script invalid after a certain time. This suggestion was discussed in a thread tagged with "nExpiryTime" and users were encouraged to search the archives for more information. The term "fill-or-kill transaction" was also mentioned in a previous discussion on the same list in September 2015. The post was signed off by Sjors.In a recent email conversation on the bitcoin-dev mailing list, Daniel Edgecumbe proposed a method to bind grafts to a specific transaction without requiring aggregation. He suggested signing H(txid, script) instead of H(script), but its impact on aggregation is unknown. This method requires knowing the txid in advance, which can be handled by a graftroot sighash flag. However, in most cases, the txid is not known. Another alternative solution is signing a transaction spending the multisig coin to the graft, but it lacks atomicity, scalability, and privacy. The advantage of the aggregation approach is that it works just in time even on grafts created in advance. A non-interactive schnorr aggregation trick can be used to merge the S values of all graftroots and signatures into a single aggregate, reducing overhead to ~32 bytes, similar to taproot's overhead.The discussion on the Bitcoin-dev mailing list focuses on the case where a delegate is signed conditional on another delegate being signed. Participants suggest the need for something like segwit internally to refer to one side's delegation using a signature-stable identity, but no good solution is currently available. Another point raised in the discussion is the introduction of functionality to make a script invalid after a certain time, allowing exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. This construction enables unilateral key rotation without invalidating the interests of other parties in the existing multisig, requiring only storing the signed delegation.The email thread discusses the introduction of functionality to make a script invalid after a certain time, which can enhance the utility of a construction despite previous re-org behavior. Proposed timelocks would be valid before a certain time or block height and invalid after, allowing for exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. Unilateral key rotation is possible in a multisig setup without invalidating the interests of other parties, as long as all parties agree to add a new key while still allowing the old key to sign.The context suggests the existence of a method that enables unilateral key rotation in a multisig setup without invalidating the interests of other parties. This method does not require any on-chain transactions but involves storing the signed delegation. The Taproot protocol provides only one alternative natively, while the Graftroot protocol allows for an unlimited number of alternatives while maintaining efficiency and privacy. With Graftroot, participants can delegate their ability to sign to a surrogate script by signing just the script with their taproot key and sharing the delegation. When spending the coin, if the signers aren't available, the redeeming party satisfies the script and presents the information along with the signer's signature. Non-interactive schnorr aggregation can be applied to merge the S values of all graftroots and signatures into a single aggregate, lowering overhead to ~32 bytes. However, this approach requires interaction with participants and storage of resulting signatures. Graftroot allows delegation before or after the fact and requires storage. The potential for unexpected surrogate replay and the existence of unused surrogates are considerations to keep in mind. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Increased-blockspace-enabled-by-SegWit-limited-to-just-witness-data-.xml b/static/bitcoin-dev/Feb_2018/combined_Increased-blockspace-enabled-by-SegWit-limited-to-just-witness-data-.xml index 6f7e403958..f21b4d0e8a 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Increased-blockspace-enabled-by-SegWit-limited-to-just-witness-data-.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Increased-blockspace-enabled-by-SegWit-limited-to-just-witness-data-.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Increased blockspace enabled by SegWit limited to just witness data? - 2023-08-01T22:44:46.968281+00:00 - - Eric Voskuil 2018-02-18 19:14:22+00:00 - - - rhavar at protonmail.com 2018-02-18 19:04:57+00:00 - - - Eric Voskuil 2018-02-18 18:39:09+00:00 - - - rhavar at protonmail.com 2018-02-18 17:04:17+00:00 - - - Austin Maier 2018-02-18 16:57:49+00:00 - - - CANNON 2018-02-18 16:26:14+00:00 - + 2025-09-26T15:40:04.068903+00:00 + python-feedgen + + + [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data? CANNON + 2018-02-18T16:26:00.000Z + + + Austin Maier + 2018-02-18T16:57:00.000Z + + + rhavar + 2018-02-18T17:04:00.000Z + + + Eric Voskuil + 2018-02-18T18:39:00.000Z + + + rhavar + 2018-02-18T19:04:00.000Z + + + Eric Voskuil + 2018-02-18T19:14:00.000Z + + - python-feedgen + 2 Combined summary - Increased blockspace enabled by SegWit limited to just witness data? - 2023-08-01T22:44:46.968281+00:00 + 2025-09-26T15:40:04.069777+00:00 - The email thread revolves around the block size limit in bitcoin following the segregated witness upgrade. Ryan argues that the block size limit has been replaced by a more restrictive block weight limit, while Eric maintains that the previous rules remain in effect and no rule has been "replaced." However, both agree that additional rules have been applied to further restrict block validity and consider additional data in the context of the block.Specifically, the block size limit of one megabyte has been replaced with a block weight limit of four million weight units. Although there is a debate over whether this constitutes replacing a rule or adding a new one, it is evident that the new limit is more restrictive than the previous one. As a soft fork, all preceding rules continue to apply, and blocks must validate against pre-SegWit rules to be considered valid.The discussion also touches upon the increased block space enabled by the segregated witness upgrade. The upgrade replaces the 1MB block size limit with a block weight limit of 4M weight units. Bytes sent to old clients are weighted at four units each, allowing for compatibility as a soft fork. It is emphasized that all preceding rules remain in effect, and blocks must adhere to pre-segwit rules to be deemed valid. Additional rules are introduced to further restrict validity and account for additional witness data.CANNON raises a question regarding the extra block space beyond the legacy 1 MB limit and whether it is exclusively allocated to witness data. The response clarifies that the block size limit has indeed been replaced by a block weight limit, and there are no separate limits. Bytes sent to old clients are assigned a weight of four units each, enabling the soft fork implementation. The email from CANNON includes a PGP signature, ensuring secure communication, and serves as a reminder that any unsigned or unencrypted email correspondence should be considered potentially forged and not private.On February 18, 2018, a question was posed on the bitcoin-dev mailing list regarding the increased block space resulting from the segregated witness upgrade. CANNON inquired whether the additional block space beyond the 1 MB limit exclusively accommodated witness data. The response confirms that this is effectively the case, with the weight discount applying to the witness data. Furthermore, CANNON's PGP fingerprint and email address are provided for secure communication purposes. The email signature emphasizes the importance of PGP-signed or encrypted correspondence, cautioning against potentially forged and non-private messages. Additionally, an HTML attachment is included, although no further details about its content are provided.In summary, the email thread delves into the block size limit in bitcoin after the segregated witness upgrade. While differing opinions exist regarding the replacement of rules or the addition of new ones, it is evident that the new block weight limit is more restrictive than its predecessor. The discussion also touches upon the increased block space enabled by the upgrade, with clarification that the extra space primarily caters to witness data. The inclusion of PGP signatures and reminders about secure communication highlight the importance of privacy and authenticity in email correspondences. 2018-02-18T19:14:22+00:00 + The email thread revolves around the block size limit in bitcoin following the segregated witness upgrade. Ryan argues that the block size limit has been replaced by a more restrictive block weight limit, while Eric maintains that the previous rules remain in effect and no rule has been "replaced." However, both agree that additional rules have been applied to further restrict block validity and consider additional data in the context of the block.Specifically, the block size limit of one megabyte has been replaced with a block weight limit of four million weight units. Although there is a debate over whether this constitutes replacing a rule or adding a new one, it is evident that the new limit is more restrictive than the previous one. As a soft fork, all preceding rules continue to apply, and blocks must validate against pre-SegWit rules to be considered valid.The discussion also touches upon the increased block space enabled by the segregated witness upgrade. The upgrade replaces the 1MB block size limit with a block weight limit of 4M weight units. Bytes sent to old clients are weighted at four units each, allowing for compatibility as a soft fork. It is emphasized that all preceding rules remain in effect, and blocks must adhere to pre-segwit rules to be deemed valid. Additional rules are introduced to further restrict validity and account for additional witness data.CANNON raises a question regarding the extra block space beyond the legacy 1 MB limit and whether it is exclusively allocated to witness data. The response clarifies that the block size limit has indeed been replaced by a block weight limit, and there are no separate limits. Bytes sent to old clients are assigned a weight of four units each, enabling the soft fork implementation. The email from CANNON includes a PGP signature, ensuring secure communication, and serves as a reminder that any unsigned or unencrypted email correspondence should be considered potentially forged and not private.On February 18, 2018, a question was posed on the bitcoin-dev mailing list regarding the increased block space resulting from the segregated witness upgrade. CANNON inquired whether the additional block space beyond the 1 MB limit exclusively accommodated witness data. The response confirms that this is effectively the case, with the weight discount applying to the witness data. Furthermore, CANNON's PGP fingerprint and email address are provided for secure communication purposes. The email signature emphasizes the importance of PGP-signed or encrypted correspondence, cautioning against potentially forged and non-private messages. Additionally, an HTML attachment is included, although no further details about its content are provided.In summary, the email thread delves into the block size limit in bitcoin after the segregated witness upgrade. While differing opinions exist regarding the replacement of rules or the addition of new ones, it is evident that the new block weight limit is more restrictive than its predecessor. The discussion also touches upon the increased block space enabled by the upgrade, with clarification that the extra space primarily caters to witness data. The inclusion of PGP signatures and reminders about secure communication highlight the importance of privacy and authenticity in email correspondences. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Multi-CSV-Transaction.xml b/static/bitcoin-dev/Feb_2018/combined_Multi-CSV-Transaction.xml index 892ff4b545..0d6dcd340e 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Multi-CSV-Transaction.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Multi-CSV-Transaction.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Multi CSV Transaction - 2023-08-01T22:45:26.526093+00:00 - - Praveen Baratam 2018-02-21 02:36:31+00:00 - - - Daniel Robinson 2018-02-21 00:59:45+00:00 - - - Praveen Baratam 2018-02-20 16:53:25+00:00 - + 2025-09-26T15:40:10.337250+00:00 + python-feedgen + + + [bitcoin-dev] Multi CSV Transaction Praveen Baratam + 2018-02-20T16:53:00.000Z + + + Daniel Robinson + 2018-02-21T00:59:00.000Z + + + Praveen Baratam + 2018-02-21T02:36:00.000Z + + - python-feedgen + 2 Combined summary - Multi CSV Transaction - 2023-08-01T22:45:26.526093+00:00 + 2025-09-26T15:40:10.337839+00:00 - In a discussion on the bitcoin-dev mailing list, Praveen Baratam raises a question about the usage of OP_CHECKSEQUENCEVERIFY (CSV) in transactions. He includes an image attachment illustrating multiple CSV endpoints with different conditions at different delays. Praveen is curious to know if this can be accomplished using OP_CHECKSEQUENCEVERIFY.Daniel Robinson responds to Praveen's query, explaining that it is indeed possible to achieve the desired functionality with Bitcoin Script. By utilizing nested IF statements, different conditions can be enforced in each branch. To demonstrate this, Daniel provides an Ivy script and its corresponding Bitcoin Script. The Ivy script, called MultiCSV, compiles into the Bitcoin Script presented.The MultiCSV contract consists of three clauses: bobSpend, carolSpend, and bothSpend. Each clause has its own specific set of conditions that must be satisfied before unlocking the value. This allows for different conditions to be applied at different delays, as requested by Praveen.Overall, Praveen seeks clarification on the workings of OP_CHECKSEQUENCEVERIFY in transactions and whether it can support the usage of multiple CSV endpoints with varying conditions and delays. 2018-02-21T02:36:31+00:00 + In a discussion on the bitcoin-dev mailing list, Praveen Baratam raises a question about the usage of OP_CHECKSEQUENCEVERIFY (CSV) in transactions. He includes an image attachment illustrating multiple CSV endpoints with different conditions at different delays. Praveen is curious to know if this can be accomplished using OP_CHECKSEQUENCEVERIFY.Daniel Robinson responds to Praveen's query, explaining that it is indeed possible to achieve the desired functionality with Bitcoin Script. By utilizing nested IF statements, different conditions can be enforced in each branch. To demonstrate this, Daniel provides an Ivy script and its corresponding Bitcoin Script. The Ivy script, called MultiCSV, compiles into the Bitcoin Script presented.The MultiCSV contract consists of three clauses: bobSpend, carolSpend, and bothSpend. Each clause has its own specific set of conditions that must be satisfied before unlocking the value. This allows for different conditions to be applied at different delays, as requested by Praveen.Overall, Praveen seeks clarification on the workings of OP_CHECKSEQUENCEVERIFY in transactions and whether it can support the usage of multiple CSV endpoints with varying conditions and delays. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_NIST-8202-Blockchain-Technology-Overview.xml b/static/bitcoin-dev/Feb_2018/combined_NIST-8202-Blockchain-Technology-Overview.xml index ac185d48a3..6f40877a1c 100644 --- a/static/bitcoin-dev/Feb_2018/combined_NIST-8202-Blockchain-Technology-Overview.xml +++ b/static/bitcoin-dev/Feb_2018/combined_NIST-8202-Blockchain-Technology-Overview.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - NIST 8202 Blockchain Technology Overview - 2023-08-01T22:34:39.673001+00:00 - - CANNON 2018-02-18 16:20:13+00:00 - - - Damian Williamson 2018-02-06 07:07:26+00:00 - - - CANNON 2018-02-06 02:08:24+00:00 - - - Peter Todd 2018-01-30 07:22:55+00:00 - - - CANNON 2018-01-30 03:30:21+00:00 - - - CANNON 2018-01-30 01:43:22+00:00 - - - CANNON 2018-01-29 01:08:24+00:00 - - - CANNON 2018-01-29 00:40:32+00:00 - + 2025-09-26T15:39:55.679261+00:00 + python-feedgen + + + [bitcoin-dev] NIST 8202 Blockchain Technology Overview CANNON + 2018-01-29T00:40:00.000Z + + + CANNON + 2018-01-29T01:08:00.000Z + + + CANNON + 2018-01-30T01:43:00.000Z + + + CANNON + 2018-01-30T03:30:00.000Z + + + Peter Todd + 2018-01-30T07:22:00.000Z + + + CANNON + 2018-02-06T02:08:00.000Z + + + Damian Williamson + 2018-02-06T07:07:00.000Z + + + CANNON + 2018-02-18T16:20:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - NIST 8202 Blockchain Technology Overview - 2023-08-01T22:34:39.673001+00:00 + 2025-09-26T15:39:55.680280+00:00 - In an email conversation between Damian Williamson and CANNON, disagreements arise regarding the implementation of SegWit changes and the increase in blocksize by Bitcoin Cash. Williamson suggests that Bitcoin Cash developers decided to increase the blocksize in addition to implementing SegWit changes, whereas CANNON points out that Bitcoin Cash has yet to implement these improvements. SegWit, a softfork, enables advanced smart contracts, micropayment networks, and increases signature security. The conversation also includes a PGP signed message.Another email conversation between Damian Williamson and an anonymous individual revolves around the method used by Bitcoin Cash developers to improve the cryptocurrency's capabilities. Williamson argues that the statement implying Bitcoin Cash chose to increase blocksize over implementing SegWit is incorrect because the developers wanted to implement other improvements as well. However, the anonymous individual counters by stating that SegWit includes features beyond scaling and Bitcoin Cash has yet to implement them. The wording used by Williamson suggests that Bitcoin Cash has implemented SegWit, which is not the case.A forwarded email sent to the bitcoin-dev mailing list discusses concerns about section 8.1.2 of the NIST 8202 Blockchain Technology Overview. Dylan Yaga from Fed revises the section and sends it to CANNON for further comment and transparency. Section 8.1.2 covers Bitcoin Cash (BCH), which resulted from a hard fork of the Bitcoin blockchain. Instead of implementing SegWit changes, Bitcoin Cash developers increased the blocksize, allowing people to have access to the same amount of coins on both Bitcoin and Bitcoin Cash. A question arises about whether transactions are more compact due to SegWit, with the answer being that they appear more compact to un-upgraded nodes but are not actually more compact.Dylan Yaga of the Federal government responds to feedback on section 8.1.2 of the NIST 8202 Blockchain Technology Overview. Bitcoin Cash (BCH), a hard fork of the Bitcoin blockchain in 2017, opted for an increased blocksize instead of implementing SegWit changes. This resulted in users having access to the same amount of coins on both Bitcoin and Bitcoin Cash. The revised section is sent for further comment to ensure transparency.The context also includes a correction to an email that was previously sent with an incorrect date. The original email titled "NIST 8202 Blockchain Technology Overview" had the wrong date in the header, which is corrected to Jan 28th. The corrected date can be verified through the email signature. The sender also sends an email with the corrected date to the NIST comments email address. The message is signed with PGP and includes a SHA512 hash. The author's identity is not mentioned.The author of the message comments on Draft NISTIR 8202 Blockchain Technology Overview, expressing their belief that the paper contains false information and is technologically invalid. Specifically, they point out errors in the section about "Bitcoin Cash (BCC)" and provide four corrections. They clarify that Bitcoin Cash uses the ticker BCH, not BCC, emphasize that SegWit was a softfork, highlight that the original bitcoin blockchain is still called Bitcoin, and note that Bitcoin Cash is a forked altcoin, not the original chain. The author hopes that their comments will contribute to improving the paper and suggests that better research could have prevented these errors. 2018-02-18T16:20:13+00:00 + In an email conversation between Damian Williamson and CANNON, disagreements arise regarding the implementation of SegWit changes and the increase in blocksize by Bitcoin Cash. Williamson suggests that Bitcoin Cash developers decided to increase the blocksize in addition to implementing SegWit changes, whereas CANNON points out that Bitcoin Cash has yet to implement these improvements. SegWit, a softfork, enables advanced smart contracts, micropayment networks, and increases signature security. The conversation also includes a PGP signed message.Another email conversation between Damian Williamson and an anonymous individual revolves around the method used by Bitcoin Cash developers to improve the cryptocurrency's capabilities. Williamson argues that the statement implying Bitcoin Cash chose to increase blocksize over implementing SegWit is incorrect because the developers wanted to implement other improvements as well. However, the anonymous individual counters by stating that SegWit includes features beyond scaling and Bitcoin Cash has yet to implement them. The wording used by Williamson suggests that Bitcoin Cash has implemented SegWit, which is not the case.A forwarded email sent to the bitcoin-dev mailing list discusses concerns about section 8.1.2 of the NIST 8202 Blockchain Technology Overview. Dylan Yaga from Fed revises the section and sends it to CANNON for further comment and transparency. Section 8.1.2 covers Bitcoin Cash (BCH), which resulted from a hard fork of the Bitcoin blockchain. Instead of implementing SegWit changes, Bitcoin Cash developers increased the blocksize, allowing people to have access to the same amount of coins on both Bitcoin and Bitcoin Cash. A question arises about whether transactions are more compact due to SegWit, with the answer being that they appear more compact to un-upgraded nodes but are not actually more compact.Dylan Yaga of the Federal government responds to feedback on section 8.1.2 of the NIST 8202 Blockchain Technology Overview. Bitcoin Cash (BCH), a hard fork of the Bitcoin blockchain in 2017, opted for an increased blocksize instead of implementing SegWit changes. This resulted in users having access to the same amount of coins on both Bitcoin and Bitcoin Cash. The revised section is sent for further comment to ensure transparency.The context also includes a correction to an email that was previously sent with an incorrect date. The original email titled "NIST 8202 Blockchain Technology Overview" had the wrong date in the header, which is corrected to Jan 28th. The corrected date can be verified through the email signature. The sender also sends an email with the corrected date to the NIST comments email address. The message is signed with PGP and includes a SHA512 hash. The author's identity is not mentioned.The author of the message comments on Draft NISTIR 8202 Blockchain Technology Overview, expressing their belief that the paper contains false information and is technologically invalid. Specifically, they point out errors in the section about "Bitcoin Cash (BCC)" and provide four corrections. They clarify that Bitcoin Cash uses the ticker BCH, not BCC, emphasize that SegWit was a softfork, highlight that the original bitcoin blockchain is still called Bitcoin, and note that Bitcoin Cash is a forked altcoin, not the original chain. The author hopes that their comments will contribute to improving the paper and suggests that better research could have prevented these errors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_New-Bitcoin-Core-macOS-signing-key.xml b/static/bitcoin-dev/Feb_2018/combined_New-Bitcoin-Core-macOS-signing-key.xml index 4056db12d2..13bc6c0d32 100644 --- a/static/bitcoin-dev/Feb_2018/combined_New-Bitcoin-Core-macOS-signing-key.xml +++ b/static/bitcoin-dev/Feb_2018/combined_New-Bitcoin-Core-macOS-signing-key.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - New Bitcoin Core macOS signing key - 2023-08-01T22:27:54.667619+00:00 - - Cory Fields 2018-02-01 01:14:45+00:00 - - - nullius 2018-01-12 10:14:11+00:00 - - - Peter Todd 2018-01-12 08:54:12+00:00 - - - Cory Fields 2018-01-12 05:04:44+00:00 - + 2025-09-26T15:40:16.660083+00:00 + python-feedgen + + + [bitcoin-dev] New Bitcoin Core macOS signing key Cory Fields + 2018-01-12T05:04:00.000Z + + + Peter Todd + 2018-01-12T08:54:00.000Z + + + nullius + 2018-01-12T10:14:00.000Z + + + Cory Fields + 2018-02-01T01:14:00.000Z + + - python-feedgen + 2 Combined summary - New Bitcoin Core macOS signing key - 2023-08-01T22:27:54.667619+00:00 + 2025-09-26T15:40:16.660785+00:00 - A new public key has been generated for Bitcoin Core releases starting with 0.16.0rc1 due to an error in the previously published key that was created for iPhone OS instead of macOS. The purpose of the new key is to sign future macOS releases, and it can be verified using openssl smime -verify -noverify -in msg.pem. This announcement apologizes for the confusion caused by the noise, and the previous email contains the original pubkey that is no longer valid.Meanwhile, Bitcoin Core developer Peter Todd discussed how OpenTimestamps (OTS) provided little proof when verifying an important certificate in the Bitcoin software. While OTS extracted a timestamped proof of existence for the BitcoinFoundation_Apple_Cert.pem file within the repo, it failed to prove who had put it there. Todd explained that if someone could create a collision between the real certificate and one for which they had the private key, they could switch them at a later date. Furthermore, Todd found a security hole related to clearsigned PGP recently. He suggests using a detached signature or piping gpg --verify -o - to grep instead of separating verification from use of data.In another post on the bitcoin-dev mailing list, Todd described how to use the `-signer` option in OpenSSL to write the signer's certificate to a file, which can then be compared to the one from the repository. He also noted that OpenTimestamps has git integration, allowing the extraction of an OTS proof generated as of Oct 13, 2016 for the certificate from the repo. However, he questioned if the proof generated by those three commands are crypto snakeoil that proved little since there was no proof of who put it there. Additionally, with the breaking of SHA-1, there may be scenarios involving two different PEMs with the same hash but different public keys. Todd discussed potential solutions using PGP, such as not using clearsigning, using a detached signature, or having shell scripts written by someone knowledgeable about security.The email conversation on the bitcoin-dev mailing list suggested using openssl smime to verify the certificate used to sign Bitcoin Core binaries. The -ignore_critical flag is required to ignore Apple specific critical extensions that OpenSSL doesn't understand, and the -purpose any allows skipping the purpose == smimesign check since the certificate is only authorized to sign code, not arbitrary messages. However, it is noted that the signature will fail to validate as the certificate has expired. If openssl doesn't have the Apple Certificate Authority in its CA list, -noverify needs to be added. To compare the signer's certificate to the one from the repo, the -signer option can be used to write the signer's certificate to a file. OpenTimestamps has git integration, which allows the extraction of an OTS proof from 2016 for that certificate from the repo. The signed message was timestamped on the Bitcoin blockchain using OpenTimestamps. The issue is that asking the user to cut-n-paste that PKCS7-encoded message is problematic, as differences in whitespace and line endings will make the verification fail. Bitcoin Core's contrib/verifybinaries/verify.sh isn't vulnerable to this mistake.Bitcoin Core's macOS code signing certificate has expired, and a new threshold signing scheme is being established to handle code signing without any single point of failure. Until then, releases will be signed as before, just with a new certificate. The old code-signing key/certificate was used to sign a message containing the pubkey that matches the new key/certificate for record purposes. The attached pkcs7 format contains the current signing certificate to make verification easier. Verification can be done using openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose any command. The signature will probably fail to validate now because the certificate has expired. To timestamp the signed message on the Bitcoin blockchain, OpenTimestamps was used. An ots file containing the timestamp proof is attached.The context also includes a PKCS7 encoded file with the encryption key MCVVMCCCdK9a7psn2QMAkGBSsOAwIaBQCggbEw and a signature in OpenDocument format named expire.txt.sig.ots. However, the URL for the attachment is not provided in the context. 2018-02-01T01:14:45+00:00 + A new public key has been generated for Bitcoin Core releases starting with 0.16.0rc1 due to an error in the previously published key that was created for iPhone OS instead of macOS. The purpose of the new key is to sign future macOS releases, and it can be verified using openssl smime -verify -noverify -in msg.pem. This announcement apologizes for the confusion caused by the noise, and the previous email contains the original pubkey that is no longer valid.Meanwhile, Bitcoin Core developer Peter Todd discussed how OpenTimestamps (OTS) provided little proof when verifying an important certificate in the Bitcoin software. While OTS extracted a timestamped proof of existence for the BitcoinFoundation_Apple_Cert.pem file within the repo, it failed to prove who had put it there. Todd explained that if someone could create a collision between the real certificate and one for which they had the private key, they could switch them at a later date. Furthermore, Todd found a security hole related to clearsigned PGP recently. He suggests using a detached signature or piping gpg --verify -o - to grep instead of separating verification from use of data.In another post on the bitcoin-dev mailing list, Todd described how to use the `-signer` option in OpenSSL to write the signer's certificate to a file, which can then be compared to the one from the repository. He also noted that OpenTimestamps has git integration, allowing the extraction of an OTS proof generated as of Oct 13, 2016 for the certificate from the repo. However, he questioned if the proof generated by those three commands are crypto snakeoil that proved little since there was no proof of who put it there. Additionally, with the breaking of SHA-1, there may be scenarios involving two different PEMs with the same hash but different public keys. Todd discussed potential solutions using PGP, such as not using clearsigning, using a detached signature, or having shell scripts written by someone knowledgeable about security.The email conversation on the bitcoin-dev mailing list suggested using openssl smime to verify the certificate used to sign Bitcoin Core binaries. The -ignore_critical flag is required to ignore Apple specific critical extensions that OpenSSL doesn't understand, and the -purpose any allows skipping the purpose == smimesign check since the certificate is only authorized to sign code, not arbitrary messages. However, it is noted that the signature will fail to validate as the certificate has expired. If openssl doesn't have the Apple Certificate Authority in its CA list, -noverify needs to be added. To compare the signer's certificate to the one from the repo, the -signer option can be used to write the signer's certificate to a file. OpenTimestamps has git integration, which allows the extraction of an OTS proof from 2016 for that certificate from the repo. The signed message was timestamped on the Bitcoin blockchain using OpenTimestamps. The issue is that asking the user to cut-n-paste that PKCS7-encoded message is problematic, as differences in whitespace and line endings will make the verification fail. Bitcoin Core's contrib/verifybinaries/verify.sh isn't vulnerable to this mistake.Bitcoin Core's macOS code signing certificate has expired, and a new threshold signing scheme is being established to handle code signing without any single point of failure. Until then, releases will be signed as before, just with a new certificate. The old code-signing key/certificate was used to sign a message containing the pubkey that matches the new key/certificate for record purposes. The attached pkcs7 format contains the current signing certificate to make verification easier. Verification can be done using openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose any command. The signature will probably fail to validate now because the certificate has expired. To timestamp the signed message on the Bitcoin blockchain, OpenTimestamps was used. An ots file containing the timestamp proof is attached.The context also includes a PKCS7 encoded file with the encryption key MCVVMCCCdK9a7psn2QMAkGBSsOAwIaBQCggbEw and a signature in OpenDocument format named expire.txt.sig.ots. However, the URL for the attachment is not provided in the context. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Possible-change-to-the-MIT-license.xml b/static/bitcoin-dev/Feb_2018/combined_Possible-change-to-the-MIT-license.xml index ae4f32c468..a0c4cdb919 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Possible-change-to-the-MIT-license.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Possible-change-to-the-MIT-license.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Possible change to the MIT license - 2023-08-01T22:43:39.277251+00:00 + 2025-09-26T15:39:59.883055+00:00 + python-feedgen Damian Williamson 2018-02-14 10:09:25+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Possible change to the MIT license - 2023-08-01T22:43:39.277251+00:00 + 2025-09-26T15:39:59.883226+00:00 - Damian Williamson expresses his disagreement with any changes to the current MIT license for Bitcoin's software, arguing that altering even a single word could have significant legal consequences. On the other hand, Cory Fields suggests focusing on copyright litigation and trademark dilution concerns while emphasizing the importance of Bitcoin's position. There is a statement from an unknown individual who disapproves of changing open source principles due to personal reasons. They emphasize the need to maintain the integrity of open source and not dilute its core values. The use of open source software follows specific principles that should not be altered according to personal preferences.Several members of the bitcoin-dev mailing list disagree with a proposed change to Bitcoin Core's license terms. They argue that this solution may not effectively address the problem of fork coins using the Bitcoin name and suggest social and marketing-based approaches instead. They also express concerns about the potential legal uncertainty and harm to Bitcoin's philosophy of being free and independent. Additionally, they argue that prohibiting the use of the name Bitcoin would be like prohibiting the use of the word "Linux" in brands based on the Linux kernel.A proposal has been raised to amend the MIT license under which Bitcoin is licensed to limit the use of the Bitcoin name by other projects unless they are fully compatible with the Bitcoin Core blockchain. This is intended to mitigate confusion among users caused by multiple hard forks. However, there are concerns about the enforceability of this amendment and its potential impact on forking older versions of Bitcoin or using existing independent blockchain implementations under the Bitcoin name.Custom open-source licenses can create compliance issues for organizations using software. Deviations from universally-accepted open-source licensing terms can lead to legal complications, necessitating approval from employers before using the software. Therefore, changes to the license may not be viable, regardless of how it is phrased. A suggestion was made to limit cryptocurrencies with the same Proof of Work, but there is opposition due to potential branding attacks.A recent discussion on the Bitcoin-dev mailing list addresses a potential license change that could impact the use of the Bitcoin name as a brand or trademark. Some argue that this change could be seen as an attack on Bitcoin's open source nature and fundamental principles. Others suggest social and marketing-based solutions rather than legal ones to address confusion caused by fork coins using the Bitcoin name. Concerns are raised about legal uncertainty and the impact on forking older versions of Bitcoin or using existing independent blockchain implementations. The challenges of balancing brand protection with free and open source software development are highlighted.The speaker agrees with opposition to changing the license due to branding attacks but suggests limiting cryptocurrencies with the same Proof of Work to ensure the stability and security of Bitcoin.Developers discuss a proposal to alter Bitcoin Core's license terms to limit liability for developers subject to lawsuits. Concerns are raised regarding who would have the right to assert an offensive claim of breached license terms. Some argue that defending against branding attacks should be social and marketing-based rather than relying on courts or governments. Frustration is expressed over ongoing FUD and scammery without an official response. Suggestions include altering the license terms or using trademarks, but there are concerns about legal uncertainty and being unable to mention Bitcoin.The proposed solution to disincentivize fork coins from using the word Bitcoin by altering the license terms is met with criticism. It is argued that a social or marketing-based defense would be more effective since the problem is social and marketing-based. Bitcoin should not rely on courts or governments to defend itself against attacks. Trademarks are suggested as an alternative solution, but there are concerns about legal uncertainty and the impact on forking older versions of Bitcoin or using existing independent blockchain implementations. Being unable to mention Bitcoin is considered excessive, and the license does not affect blockchain data.Bitcoin is facing a branding attack by fork coins, and suggestions to alter the license terms to disincentivize their use of the word Bitcoin are met with criticism. A social or marketing-based defense is proposed as more effective, and Bitcoin should not rely on courts or governments for defense. Trademarks are suggested as an alternative solution, but concerns about legal uncertainty and compatibility with older versions are raised. Being unable to mention Bitcoin is seen as excessive, and the license does not affect blockchain data.The ongoing branding attack on Bitcoin by fork coins prompts discussions about possible solutions. Altering the license terms is suggested, but its effectiveness is questioned without an entity using court systems. A social or marketing-based defense is proposed, emphasizing that Bitcoin should not rely on courts or governments. Trademarks are also suggested, but concerns about legal uncertainty and compatibility with older versions arise. Frustration over unanswered FUD and scammery is expressed.Bitcoin is facing a branding attack by fork coins, and altering the license terms to disincentivize their use of the word "Bitcoin" is proposed. However, it may not be effective without an entity using court systems. A social or marketing-based defense is argued to be more appropriate, and Bitcoin should not rely on courts or 2018-02-14T10:09:25+00:00 + Damian Williamson expresses his disagreement with any changes to the current MIT license for Bitcoin's software, arguing that altering even a single word could have significant legal consequences. On the other hand, Cory Fields suggests focusing on copyright litigation and trademark dilution concerns while emphasizing the importance of Bitcoin's position. There is a statement from an unknown individual who disapproves of changing open source principles due to personal reasons. They emphasize the need to maintain the integrity of open source and not dilute its core values. The use of open source software follows specific principles that should not be altered according to personal preferences.Several members of the bitcoin-dev mailing list disagree with a proposed change to Bitcoin Core's license terms. They argue that this solution may not effectively address the problem of fork coins using the Bitcoin name and suggest social and marketing-based approaches instead. They also express concerns about the potential legal uncertainty and harm to Bitcoin's philosophy of being free and independent. Additionally, they argue that prohibiting the use of the name Bitcoin would be like prohibiting the use of the word "Linux" in brands based on the Linux kernel.A proposal has been raised to amend the MIT license under which Bitcoin is licensed to limit the use of the Bitcoin name by other projects unless they are fully compatible with the Bitcoin Core blockchain. This is intended to mitigate confusion among users caused by multiple hard forks. However, there are concerns about the enforceability of this amendment and its potential impact on forking older versions of Bitcoin or using existing independent blockchain implementations under the Bitcoin name.Custom open-source licenses can create compliance issues for organizations using software. Deviations from universally-accepted open-source licensing terms can lead to legal complications, necessitating approval from employers before using the software. Therefore, changes to the license may not be viable, regardless of how it is phrased. A suggestion was made to limit cryptocurrencies with the same Proof of Work, but there is opposition due to potential branding attacks.A recent discussion on the Bitcoin-dev mailing list addresses a potential license change that could impact the use of the Bitcoin name as a brand or trademark. Some argue that this change could be seen as an attack on Bitcoin's open source nature and fundamental principles. Others suggest social and marketing-based solutions rather than legal ones to address confusion caused by fork coins using the Bitcoin name. Concerns are raised about legal uncertainty and the impact on forking older versions of Bitcoin or using existing independent blockchain implementations. The challenges of balancing brand protection with free and open source software development are highlighted.The speaker agrees with opposition to changing the license due to branding attacks but suggests limiting cryptocurrencies with the same Proof of Work to ensure the stability and security of Bitcoin.Developers discuss a proposal to alter Bitcoin Core's license terms to limit liability for developers subject to lawsuits. Concerns are raised regarding who would have the right to assert an offensive claim of breached license terms. Some argue that defending against branding attacks should be social and marketing-based rather than relying on courts or governments. Frustration is expressed over ongoing FUD and scammery without an official response. Suggestions include altering the license terms or using trademarks, but there are concerns about legal uncertainty and being unable to mention Bitcoin.The proposed solution to disincentivize fork coins from using the word Bitcoin by altering the license terms is met with criticism. It is argued that a social or marketing-based defense would be more effective since the problem is social and marketing-based. Bitcoin should not rely on courts or governments to defend itself against attacks. Trademarks are suggested as an alternative solution, but there are concerns about legal uncertainty and the impact on forking older versions of Bitcoin or using existing independent blockchain implementations. Being unable to mention Bitcoin is considered excessive, and the license does not affect blockchain data.Bitcoin is facing a branding attack by fork coins, and suggestions to alter the license terms to disincentivize their use of the word Bitcoin are met with criticism. A social or marketing-based defense is proposed as more effective, and Bitcoin should not rely on courts or governments for defense. Trademarks are suggested as an alternative solution, but concerns about legal uncertainty and compatibility with older versions are raised. Being unable to mention Bitcoin is seen as excessive, and the license does not affect blockchain data.The ongoing branding attack on Bitcoin by fork coins prompts discussions about possible solutions. Altering the license terms is suggested, but its effectiveness is questioned without an entity using court systems. A social or marketing-based defense is proposed, emphasizing that Bitcoin should not rely on courts or governments. Trademarks are also suggested, but concerns about legal uncertainty and compatibility with older versions arise. Frustration over unanswered FUD and scammery is expressed.Bitcoin is facing a branding attack by fork coins, and altering the license terms to disincentivize their use of the word "Bitcoin" is proposed. However, it may not be effective without an entity using court systems. A social or marketing-based defense is argued to be more appropriate, and Bitcoin should not rely on courts or - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Revisiting-BIP-125-RBF-policy-.xml b/static/bitcoin-dev/Feb_2018/combined_Revisiting-BIP-125-RBF-policy-.xml index 5ace799e9f..38d50f870c 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Revisiting-BIP-125-RBF-policy-.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Revisiting-BIP-125-RBF-policy-.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Revisiting BIP 125 RBF policy. - 2023-08-01T22:41:40.917212+00:00 - - rhavar at protonmail.com 2018-03-09 18:40:34+00:00 - - - Peter Todd 2018-03-09 18:28:03+00:00 - - - Russell O'Connor 2018-03-08 20:07:43+00:00 - - - Peter Todd 2018-03-08 18:34:26+00:00 - - - Russell O'Connor 2018-03-08 15:39:46+00:00 - - - Peter Todd 2018-03-01 15:11:29+00:00 - - - Russell O'Connor 2018-02-27 16:25:59+00:00 - - - Greg Sanders 2018-02-14 14:16:29+00:00 - - - Russell O'Connor 2018-02-14 14:08:01+00:00 - - - rhavar at protonmail.com 2018-02-14 02:07:25+00:00 - - - Peter Todd 2018-02-13 18:40:34+00:00 - - - Russell O'Connor 2018-02-12 23:46:43+00:00 - - - Peter Todd 2018-02-12 23:42:25+00:00 - - - rhavar at protonmail.com 2018-02-12 23:23:12+00:00 - - - Russell O'Connor 2018-02-12 23:19:40+00:00 - - - Peter Todd 2018-02-12 22:58:28+00:00 - - - rhavar at protonmail.com 2018-02-12 17:30:04+00:00 - - - Russell O'Connor 2018-02-12 15:52:30+00:00 - + 2025-09-26T15:40:12.453751+00:00 + python-feedgen + + + [bitcoin-dev] Revisiting BIP 125 RBF policy Russell O'Connor + 2018-02-12T15:52:00.000Z + + + rhavar + 2018-02-12T17:30:00.000Z + + + Peter Todd + 2018-02-12T22:58:00.000Z + + + Russell O'Connor + 2018-02-12T23:19:00.000Z + + + rhavar + 2018-02-12T23:23:00.000Z + + + Peter Todd + 2018-02-12T23:42:00.000Z + + + Russell O'Connor + 2018-02-12T23:46:00.000Z + + + Peter Todd + 2018-02-13T18:40:00.000Z + + + rhavar + 2018-02-14T02:07:00.000Z + + + Russell O'Connor + 2018-02-14T14:08:00.000Z + + + Greg Sanders + 2018-02-14T14:16:00.000Z + + + Russell O'Connor + 2018-02-27T16:25:00.000Z + + + Peter Todd + 2018-03-01T15:11:00.000Z + + + Russell O'Connor + 2018-03-08T15:39:00.000Z + + + Peter Todd + 2018-03-08T18:34:00.000Z + + + Russell O'Connor + 2018-03-08T20:07:00.000Z + + + Peter Todd + 2018-03-09T18:28:00.000Z + + + rhavar + 2018-03-09T18:40:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Revisiting BIP 125 RBF policy. - 2023-08-01T22:41:40.917212+00:00 + 2025-09-26T15:40:12.455576+00:00 - The email thread on the bitcoin-dev mailing list discusses the relaxation of some of the Denial of Service (DoS) prevention rules to open up more use cases and adoption. The issue of institutional wallets sweeping incoming payments and sweeping unconfirmed outputs is raised, but it is believed that this behavior is unintentional. It is suggested that if people start using the new replacement behavior, then institutions doing these sweeps may stop doing it. The development of a reasonable standard Replace-by-Fee (RBF) policy that aligns with miner incentives is discussed as miners prefer transactions with higher package fee rates. The weakening of DoS protections is not considered a huge problem, and it is proposed to try relaxing some of the rules in a release and see what happens.In a discussion about Bitcoin's Replace-by-Fee (RBF) policy, Russell O'Connor suggested that replaced transactions should require a fee increase of at least the min-fee-rate times the size of all the transactions being ejected. Peter Todd raised concerns about weakening anti-DoS protections, but O'Connor clarified that he was not suggesting removing them entirely. The issue of institutional wallets sweeping unconfirmed outputs was also discussed as they seem to be happy to sweep unconfirmed outputs, which is potentially problematic. Additionally, there was a discussion about miner incentives and developing a reasonable standard RBF policy that aligns with those incentives. There was some disagreement about whether miners and full nodes have slightly different priorities. Nonetheless, Todd agreed to try the new replacement behavior in a release and see what happens. If people use this new replacement behavior, it may discourage institutions from sweeping unconfirmed outputs, which can be dangerous in reorgs.Peter Todd and Russell O'Connor were discussing the proposed change in RBF policy. Peter Todd pointed out that replacing a transaction without paying fees is identical to what an attacker is trying to do, making any such scheme vulnerable to attack. Russell argued that the current policy is problematic in practice where normal transactions are being performed and no one is attacking each other. However, Peter countered that the argument is not valid as normal users creating issues has nothing to do with relaxing anti-DoS protections. He suggested that replaced transactions require a fee increase of at least min-fee-rate times the size of all the transactions being ejected (in addition to the other proposed requirements). Moreover, Peter questioned how often non-attacking users face issues, but Russell pointed out that institutional wallets sweeping incoming payments regularly cause this problem. They also discussed miners' preference for higher package fee rates regardless of personal preferred RBF policies, making it important to develop a reasonable standard RBF policy that aligns with miner incentives and is robust against possible DoS vectors. This change in RBF policy can partially mitigate the problem of pinned transactions.Russell O'Connor proposed a change in RBF policy, but Peter Todd argued that solving this problem is impossible because it opens up an attack by relaxing anti-DoS protections. Todd stated that normal users creating issues does not happen often and can be avoided by skipping the use of RBF replacements if someone spends an unconfirmed output that was sent to them. He also pointed out that the argument of normal users not attacking each other has nothing to do with the issue at hand and that any protection scheme will be as vulnerable to attack as not having protection in the first place. Ultimately, Todd suggested that the attack may not be important enough to matter.In an email exchange, Peter Todd and Russell O'Connor discussed the possibility of solving the problem of replacing transactions that have been offered a new transaction with a higher fee rate. Todd expressed his belief that it is not possible to solve this issue because someone has already consumed network bandwidth that should be paid for with fees. He stated that any attempt to replace a transaction without paying those fees would be vulnerable to attack and likened it to what an attacker would try to do. However, he did mention that if the attack isn't significant enough, it may not matter. O'Connor agreed with Todd's assessment but still believes that pursuing the proposed change in Replace-by-Fee (RBF) policy is worthwhile as the current policy is problematic in practice for normal transactions.In a discussion on the Bitcoin Development mailing list, Peter Todd expressed his opinion that it is not possible to solve the problem of unconfirmed payments. Specifically, he was referring to the case where Alice resends her unconfirmed payment. He believes that an attack aimed at replacing a transaction without paying fees would be just as vulnerable as not having any protection in place at all. Todd suggests that solving this issue may not be of great importance and could be tolerated. Russell O'Connor had asked Todd for clarification on whether he meant there was a specific problem with a proposal to replace transactions when offered a new transaction whose fee rate exceeds the package fee rate of the original transaction or if there was another issue he foresees.On February 14, 2018, a discussion took place on the bitcoin-dev mailing list regarding the computation. 2018-03-09T18:40:34+00:00 + The email thread on the bitcoin-dev mailing list discusses the relaxation of some of the Denial of Service (DoS) prevention rules to open up more use cases and adoption. The issue of institutional wallets sweeping incoming payments and sweeping unconfirmed outputs is raised, but it is believed that this behavior is unintentional. It is suggested that if people start using the new replacement behavior, then institutions doing these sweeps may stop doing it. The development of a reasonable standard Replace-by-Fee (RBF) policy that aligns with miner incentives is discussed as miners prefer transactions with higher package fee rates. The weakening of DoS protections is not considered a huge problem, and it is proposed to try relaxing some of the rules in a release and see what happens.In a discussion about Bitcoin's Replace-by-Fee (RBF) policy, Russell O'Connor suggested that replaced transactions should require a fee increase of at least the min-fee-rate times the size of all the transactions being ejected. Peter Todd raised concerns about weakening anti-DoS protections, but O'Connor clarified that he was not suggesting removing them entirely. The issue of institutional wallets sweeping unconfirmed outputs was also discussed as they seem to be happy to sweep unconfirmed outputs, which is potentially problematic. Additionally, there was a discussion about miner incentives and developing a reasonable standard RBF policy that aligns with those incentives. There was some disagreement about whether miners and full nodes have slightly different priorities. Nonetheless, Todd agreed to try the new replacement behavior in a release and see what happens. If people use this new replacement behavior, it may discourage institutions from sweeping unconfirmed outputs, which can be dangerous in reorgs.Peter Todd and Russell O'Connor were discussing the proposed change in RBF policy. Peter Todd pointed out that replacing a transaction without paying fees is identical to what an attacker is trying to do, making any such scheme vulnerable to attack. Russell argued that the current policy is problematic in practice where normal transactions are being performed and no one is attacking each other. However, Peter countered that the argument is not valid as normal users creating issues has nothing to do with relaxing anti-DoS protections. He suggested that replaced transactions require a fee increase of at least min-fee-rate times the size of all the transactions being ejected (in addition to the other proposed requirements). Moreover, Peter questioned how often non-attacking users face issues, but Russell pointed out that institutional wallets sweeping incoming payments regularly cause this problem. They also discussed miners' preference for higher package fee rates regardless of personal preferred RBF policies, making it important to develop a reasonable standard RBF policy that aligns with miner incentives and is robust against possible DoS vectors. This change in RBF policy can partially mitigate the problem of pinned transactions.Russell O'Connor proposed a change in RBF policy, but Peter Todd argued that solving this problem is impossible because it opens up an attack by relaxing anti-DoS protections. Todd stated that normal users creating issues does not happen often and can be avoided by skipping the use of RBF replacements if someone spends an unconfirmed output that was sent to them. He also pointed out that the argument of normal users not attacking each other has nothing to do with the issue at hand and that any protection scheme will be as vulnerable to attack as not having protection in the first place. Ultimately, Todd suggested that the attack may not be important enough to matter.In an email exchange, Peter Todd and Russell O'Connor discussed the possibility of solving the problem of replacing transactions that have been offered a new transaction with a higher fee rate. Todd expressed his belief that it is not possible to solve this issue because someone has already consumed network bandwidth that should be paid for with fees. He stated that any attempt to replace a transaction without paying those fees would be vulnerable to attack and likened it to what an attacker would try to do. However, he did mention that if the attack isn't significant enough, it may not matter. O'Connor agreed with Todd's assessment but still believes that pursuing the proposed change in Replace-by-Fee (RBF) policy is worthwhile as the current policy is problematic in practice for normal transactions.In a discussion on the Bitcoin Development mailing list, Peter Todd expressed his opinion that it is not possible to solve the problem of unconfirmed payments. Specifically, he was referring to the case where Alice resends her unconfirmed payment. He believes that an attack aimed at replacing a transaction without paying fees would be just as vulnerable as not having any protection in place at all. Todd suggests that solving this issue may not be of great importance and could be tolerated. Russell O'Connor had asked Todd for clarification on whether he meant there was a specific problem with a proposal to replace transactions when offered a new transaction whose fee rate exceeds the package fee rate of the original transaction or if there was another issue he foresees.On February 14, 2018, a discussion took place on the bitcoin-dev mailing list regarding the computation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Setting-up-bitcoin-dev-environment-bitcoind-bitcoin-cli-.xml b/static/bitcoin-dev/Feb_2018/combined_Setting-up-bitcoin-dev-environment-bitcoind-bitcoin-cli-.xml index f30d1992b7..7e53b41dea 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Setting-up-bitcoin-dev-environment-bitcoind-bitcoin-cli-.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Setting-up-bitcoin-dev-environment-bitcoind-bitcoin-cli-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Setting up bitcoin dev environment ( bitcoind, bitcoin-cli ) - 2023-08-01T22:37:27.531067+00:00 - - Bernd Jendrissek 2018-02-09 20:10:25+00:00 - - - Maksim Solovjov 2018-02-09 10:55:44+00:00 - + 2025-09-26T15:39:53.587557+00:00 + python-feedgen + + + [bitcoin-dev] Setting up bitcoin dev environment ( bitcoind, bitcoin-cli ) Maksim Solovjov + 2018-02-09T10:55:00.000Z + + + Bernd Jendrissek + 2018-02-09T20:10:00.000Z + + - python-feedgen + 2 Combined summary - Setting up bitcoin dev environment ( bitcoind, bitcoin-cli ) - 2023-08-01T22:37:27.531067+00:00 + 2025-09-26T15:39:53.588009+00:00 - On February 9th, 2018, Maksim Solovjov encountered problems when trying to launch bitcoind in the -regtest regime. Specifically, when attempting to run the command "bitcoin-cli -regtest setgenerate true 101", an error with the code -32601 and the message "Method not found" was displayed. Further investigation revealed that the setgenerate command had been removed in version 0.13.0, as explained in the release notes (doc/release-notes/release-notes-0.13.0.md). Additionally, when the writer tried to execute the command "bitcoin-cli getinfo", another error occurred. This time, the error message stated that no authentication cookie could be found and that no rpcpassword was set in the configuration file located at "/Users/..../Library/Application Support/Bitcoin/bitcoin.conf". The user was advised to check their installed version of Bitcoin and understand that, even before deprecation, a bitcoin.conf file needs to be correctly located for bitcoin-cli to locate it.The writer is seeking assistance in setting up a bitcoin development environment on their Mac. They have installed the Bitcoin Core client and downloaded the binaries, but are encountering several issues. Firstly, they are unable to open the bitcoin.conf configuration file from the bitcoin-qt application, despite its existence at the path "$HOME/Library/Application Support/Bitcoin/bitcoin.conf". When attempting to access it through bitcoin-qt's preferences and selecting "Show configuration file", an error message appears stating "Configuration file could not be opened". The writer has also attempted to change the permissions of the file, but this did not resolve the issue.In addition to the configuration file problem, the writer is experiencing errors when launching bitcoind in the -regtest regime. Although they can successfully launch it, when attempting to use the command "bitcoin-cli -regtest setgenerate true 101", they receive an error message with the code -32601 and the message "Method not found". Furthermore, when they try to execute the command "bitcoin-cli getinfo", they receive an error stating that no authentication cookie could be found and no rpcpassword is set in the bitcoin.conf configuration file.Given these challenges, the writer is hoping that someone can provide guidance or assistance in resolving these issues. Their ultimate goal is to successfully set up their bitcoin development environment. 2018-02-09T20:10:25+00:00 + On February 9th, 2018, Maksim Solovjov encountered problems when trying to launch bitcoind in the -regtest regime. Specifically, when attempting to run the command "bitcoin-cli -regtest setgenerate true 101", an error with the code -32601 and the message "Method not found" was displayed. Further investigation revealed that the setgenerate command had been removed in version 0.13.0, as explained in the release notes (doc/release-notes/release-notes-0.13.0.md). Additionally, when the writer tried to execute the command "bitcoin-cli getinfo", another error occurred. This time, the error message stated that no authentication cookie could be found and that no rpcpassword was set in the configuration file located at "/Users/..../Library/Application Support/Bitcoin/bitcoin.conf". The user was advised to check their installed version of Bitcoin and understand that, even before deprecation, a bitcoin.conf file needs to be correctly located for bitcoin-cli to locate it.The writer is seeking assistance in setting up a bitcoin development environment on their Mac. They have installed the Bitcoin Core client and downloaded the binaries, but are encountering several issues. Firstly, they are unable to open the bitcoin.conf configuration file from the bitcoin-qt application, despite its existence at the path "$HOME/Library/Application Support/Bitcoin/bitcoin.conf". When attempting to access it through bitcoin-qt's preferences and selecting "Show configuration file", an error message appears stating "Configuration file could not be opened". The writer has also attempted to change the permissions of the file, but this did not resolve the issue.In addition to the configuration file problem, the writer is experiencing errors when launching bitcoind in the -regtest regime. Although they can successfully launch it, when attempting to use the command "bitcoin-cli -regtest setgenerate true 101", they receive an error message with the code -32601 and the message "Method not found". Furthermore, when they try to execute the command "bitcoin-cli getinfo", they receive an error stating that no authentication cookie could be found and no rpcpassword is set in the bitcoin.conf configuration file.Given these challenges, the writer is hoping that someone can provide guidance or assistance in resolving these issues. Their ultimate goal is to successfully set up their bitcoin development environment. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Simple-lock-unlock-mechanism.xml b/static/bitcoin-dev/Feb_2018/combined_Simple-lock-unlock-mechanism.xml index 98de5c6e66..12cbc559f1 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Simple-lock-unlock-mechanism.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Simple-lock-unlock-mechanism.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Simple lock/unlock mechanism - 2023-08-01T22:45:54.958542+00:00 - - アルム　カールヨハン 2018-03-05 14:53:16+00:00 - - - アルム　カールヨハン 2018-03-01 05:11:54+00:00 - - - Adam Back 2018-02-28 23:36:05+00:00 - - - Anthony Towns 2018-02-28 22:30:44+00:00 - - - アルム　カールヨハン 2018-02-28 04:34:18+00:00 - - - アルム　カールヨハン 2018-02-28 03:47:29+00:00 - + 2025-09-26T15:40:01.977272+00:00 + python-feedgen + + + [bitcoin-dev] Simple lock/unlock mechanism アルム　カールヨハン + 2018-02-28T03:47:00.000Z + + + アルム　カールヨハン + 2018-02-28T04:34:00.000Z + + + Anthony Towns + 2018-02-28T22:30:00.000Z + + + Adam Back + 2018-02-28T23:36:00.000Z + + + アルム　カールヨハン + 2018-03-01T05:11:00.000Z + + + アルム　カールヨハン + 2018-03-05T14:53:00.000Z + + - python-feedgen + 2 Combined summary - Simple lock/unlock mechanism - 2023-08-01T22:45:54.958542+00:00 + 2025-09-26T15:40:01.978298+00:00 - In an email conversation, a user named Kalle expressed confusion about the use of graftroot in relation to multisig and freezing. Another user had suggested that using multisig would be simpler than freezing coins, but Kalle pointed out that both methods require both signatories to access the coins, and graftroot can override CLTV. Kalle also noted that graftroot requires a pubkey instead of a p2sh format.Discussions within the bitcoin-dev community are centered around the possibility of a software-only time-lock vault. Concerns have been raised about Graftroot potentially breaking the system if someone signs a time-locked output with a script that has no time-lock. To address this, some propose using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. However, others argue that this defeats the purpose and suggest using multisig instead and skipping the freezing process altogether. Adam Back suggests a method involving a CSV timelock, deleting one private key after broadcasting, and using graftroot and another privkey to spend the coins. But this approach has the drawback of the robber forcing the user to execute a step. It is suggested to include as part of 'freezing' a send to a new ephemeral key as 'initialization'. A simpler model would involve a third party refusing to co-sign until a pre-arranged time, avoiding the need for two on-chain transactions. Some users are seeking an easy way to lock up a significant portion of their coins. A security firm could offer a service where unexpected unfreeze transactions trigger an alarm.In a recent discussion on bitcoin-dev, Kalle proposed a software-only time-lock vault. Another participant mentioned that Root compatibility wouldn't be an issue if the key is deleted and delegated signatures cannot bypass the CSV timeout restriction. However, marking keys as Rootable vs not in a sighash sense could lead to privacy/fungibility loss. One drawback of this proposal is the difficulty in assuring key deletion with HD wallet seeds setup-time backup model.Anthony suggests a simpler model where a third party refuses to co-sign until a pre-arranged time, eliminating the need for two on-chain transactions. With bulletproofs and CT rangeproofs / general ECDL ZKPS, it's possible to prove things about private keys or hidden attributes of public keys without disclosing them. Private key covenants could be used to prove that certain conditions are met without revealing them.To address Kalle's concern about graftroot breaking the time-lock function, Anthony suggests using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. Increasing it to 3-of-3 or 5-of-5 could be even better if multiple independent services support it.A member of the Bitcoin development community has raised concerns about Graftroot potentially allowing someone to sign a time-locked output without a time-lock script. To prevent this, it has been suggested to use a 2-of-2 muSig with an independent third party that only signs CLTV scripts. It may also be possible to increase the number of required signatures to enhance security.Kalle recently proposed the idea of locking up bitcoin with an "OP_CSV" attached to it. The concept involves creating a transaction that spends UTXOs to a P2SH address and then discarding the private keys. To spend the bitcoin, the transaction must be broadcasted and a specified amount of time must pass before using the new txout. Kalle suggests Bitcoin Core could introduce "freeze" and "unfreeze" commands to facilitate this process. The "freeze" command would lock a certain amount of bitcoin for a given number of days, while the "unfreeze" command would list all frozen transactions and allow users to unfreeze specific ones. This locking system could disincentivize potential robbers, but there may be issues with high transaction fees and stuck transactions.In summary, discussions within the bitcoin-dev community revolve around the use of graftroot, multisig, and freezing to enhance security in Bitcoin transactions. There are proposals for a software-only time-lock vault and suggestions for addressing potential issues with graftroot. Additionally, Kalle's idea of locking up bitcoin with an "OP_CSV" has been discussed, along with the introduction of new commands in Bitcoin Core. These developments aim to prevent physical thefts of cryptocurrencies but come with their own challenges. 2018-03-05T14:53:16+00:00 + In an email conversation, a user named Kalle expressed confusion about the use of graftroot in relation to multisig and freezing. Another user had suggested that using multisig would be simpler than freezing coins, but Kalle pointed out that both methods require both signatories to access the coins, and graftroot can override CLTV. Kalle also noted that graftroot requires a pubkey instead of a p2sh format.Discussions within the bitcoin-dev community are centered around the possibility of a software-only time-lock vault. Concerns have been raised about Graftroot potentially breaking the system if someone signs a time-locked output with a script that has no time-lock. To address this, some propose using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. However, others argue that this defeats the purpose and suggest using multisig instead and skipping the freezing process altogether. Adam Back suggests a method involving a CSV timelock, deleting one private key after broadcasting, and using graftroot and another privkey to spend the coins. But this approach has the drawback of the robber forcing the user to execute a step. It is suggested to include as part of 'freezing' a send to a new ephemeral key as 'initialization'. A simpler model would involve a third party refusing to co-sign until a pre-arranged time, avoiding the need for two on-chain transactions. Some users are seeking an easy way to lock up a significant portion of their coins. A security firm could offer a service where unexpected unfreeze transactions trigger an alarm.In a recent discussion on bitcoin-dev, Kalle proposed a software-only time-lock vault. Another participant mentioned that Root compatibility wouldn't be an issue if the key is deleted and delegated signatures cannot bypass the CSV timeout restriction. However, marking keys as Rootable vs not in a sighash sense could lead to privacy/fungibility loss. One drawback of this proposal is the difficulty in assuring key deletion with HD wallet seeds setup-time backup model.Anthony suggests a simpler model where a third party refuses to co-sign until a pre-arranged time, eliminating the need for two on-chain transactions. With bulletproofs and CT rangeproofs / general ECDL ZKPS, it's possible to prove things about private keys or hidden attributes of public keys without disclosing them. Private key covenants could be used to prove that certain conditions are met without revealing them.To address Kalle's concern about graftroot breaking the time-lock function, Anthony suggests using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. Increasing it to 3-of-3 or 5-of-5 could be even better if multiple independent services support it.A member of the Bitcoin development community has raised concerns about Graftroot potentially allowing someone to sign a time-locked output without a time-lock script. To prevent this, it has been suggested to use a 2-of-2 muSig with an independent third party that only signs CLTV scripts. It may also be possible to increase the number of required signatures to enhance security.Kalle recently proposed the idea of locking up bitcoin with an "OP_CSV" attached to it. The concept involves creating a transaction that spends UTXOs to a P2SH address and then discarding the private keys. To spend the bitcoin, the transaction must be broadcasted and a specified amount of time must pass before using the new txout. Kalle suggests Bitcoin Core could introduce "freeze" and "unfreeze" commands to facilitate this process. The "freeze" command would lock a certain amount of bitcoin for a given number of days, while the "unfreeze" command would list all frozen transactions and allow users to unfreeze specific ones. This locking system could disincentivize potential robbers, but there may be issues with high transaction fees and stuck transactions.In summary, discussions within the bitcoin-dev community revolve around the use of graftroot, multisig, and freezing to enhance security in Bitcoin transactions. There are proposals for a software-only time-lock vault and suggestions for addressing potential issues with graftroot. Additionally, Kalle's idea of locking up bitcoin with an "OP_CSV" has been discussed, along with the introduction of new commands in Bitcoin Core. These developments aim to prevent physical thefts of cryptocurrencies but come with their own challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Some-thoughts-on-removing-timestamps-in-PoW.xml b/static/bitcoin-dev/Feb_2018/combined_Some-thoughts-on-removing-timestamps-in-PoW.xml index 93afd6dc77..2f215660b4 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Some-thoughts-on-removing-timestamps-in-PoW.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Some-thoughts-on-removing-timestamps-in-PoW.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Some thoughts on removing timestamps in PoW - 2023-08-01T22:45:05.494815+00:00 + 2025-09-26T15:40:18.784351+00:00 + python-feedgen Tao Effect 2018-02-21 21:58:10+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Some thoughts on removing timestamps in PoW - 2023-08-01T22:45:05.494815+00:00 + 2025-09-26T15:40:18.784504+00:00 - The email conversation explores the idea of modifying the Bitcoin blockchain to address concerns about state checkpoints and full node verification. The proposal suggests creating a new protocol that solves these issues rather than being limited by Bitcoin's current design constraints. However, Damian Williamson raises concerns that new full nodes may not have complete knowledge of utxo's if large sections of the blockchain are skipped during verification.Another proposal suggests removing timestamps from the Bitcoin blockchain's difficulty adjustment algorithm. The author argues that timestamps may be unnecessary for the blockchain to operate with the same level of security. Under this proposal, miners would have the freedom to mine blocks of any difficulty they choose, up to a certain maximum deviation. This could incentivize powerful miners to raise the difficulty and remove competitors. While timestamps could still be included in blocks, they would no longer represent anything significant other than metadata about when the block was produced.This alternative difficulty adjustment algorithm carries some risks, including potential centralization pressures. To mitigate these risks, two solutions are proposed. One is introducing state checkpoints into the chain itself, which would allow full nodes to skip verification of large sections of historical data when booting up. The other solution is implementing a sharded protocol that uses a sufficiently different Proof-of-Work (PoW) algorithm. These mitigations aim to address concerns about centralization pressures on both miners and full nodes.A member of the Bitcoin community suggests that the Y% difficulty adjustment should still be calculated through an averaging of a certain number N of past blocks. This suggestion aims to prevent a network halt caused by two lucky high difficulty blocks in a row. They also propose a logarithmic scaling reward function based on past average difficulty and the total number of mined coins. This function could discourage mining blocks with excessively large difficulties while still maintaining the 21 million coin cap.While these proposals generate discussions within the Bitcoin community, it is important to note that there are no concrete plans mentioned to modify Bitcoin in the thread. Greg Slepak, the author of the article, suggests that attempting to make these changes to the existing Bitcoin blockchain would be a non-starter and proposes forking to a new coin as an alternative.In summary, Greg Slepak questions the necessity of timestamps in Bitcoin's blockchain and proposes an alternative difficulty adjustment algorithm. This algorithm ties the number of coins issued per block directly to the difficulty of the block. However, implementing such a system may introduce risks, including centralization pressures on miners and full nodes. Mitigations such as state checkpoints and a sharded protocol using a different PoW algorithm are suggested. While these proposals generate discussions, there are no concrete plans mentioned to modify Bitcoin in the thread. Greg Slepak ultimately suggests forking to a new coin instead of modifying the existing Bitcoin blockchain. 2018-02-21T21:58:10+00:00 + The email conversation explores the idea of modifying the Bitcoin blockchain to address concerns about state checkpoints and full node verification. The proposal suggests creating a new protocol that solves these issues rather than being limited by Bitcoin's current design constraints. However, Damian Williamson raises concerns that new full nodes may not have complete knowledge of utxo's if large sections of the blockchain are skipped during verification.Another proposal suggests removing timestamps from the Bitcoin blockchain's difficulty adjustment algorithm. The author argues that timestamps may be unnecessary for the blockchain to operate with the same level of security. Under this proposal, miners would have the freedom to mine blocks of any difficulty they choose, up to a certain maximum deviation. This could incentivize powerful miners to raise the difficulty and remove competitors. While timestamps could still be included in blocks, they would no longer represent anything significant other than metadata about when the block was produced.This alternative difficulty adjustment algorithm carries some risks, including potential centralization pressures. To mitigate these risks, two solutions are proposed. One is introducing state checkpoints into the chain itself, which would allow full nodes to skip verification of large sections of historical data when booting up. The other solution is implementing a sharded protocol that uses a sufficiently different Proof-of-Work (PoW) algorithm. These mitigations aim to address concerns about centralization pressures on both miners and full nodes.A member of the Bitcoin community suggests that the Y% difficulty adjustment should still be calculated through an averaging of a certain number N of past blocks. This suggestion aims to prevent a network halt caused by two lucky high difficulty blocks in a row. They also propose a logarithmic scaling reward function based on past average difficulty and the total number of mined coins. This function could discourage mining blocks with excessively large difficulties while still maintaining the 21 million coin cap.While these proposals generate discussions within the Bitcoin community, it is important to note that there are no concrete plans mentioned to modify Bitcoin in the thread. Greg Slepak, the author of the article, suggests that attempting to make these changes to the existing Bitcoin blockchain would be a non-starter and proposes forking to a new coin as an alternative.In summary, Greg Slepak questions the necessity of timestamps in Bitcoin's blockchain and proposes an alternative difficulty adjustment algorithm. This algorithm ties the number of coins issued per block directly to the difficulty of the block. However, implementing such a system may introduce risks, including centralization pressures on miners and full nodes. Mitigations such as state checkpoints and a sharded protocol using a different PoW algorithm are suggested. While these proposals generate discussions, there are no concrete plans mentioned to modify Bitcoin in the thread. Greg Slepak ultimately suggests forking to a new coin instead of modifying the existing Bitcoin blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Taproot-Privacy-preserving-switchable-scripting.xml b/static/bitcoin-dev/Feb_2018/combined_Taproot-Privacy-preserving-switchable-scripting.xml index dbd3819689..0402cd5edc 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Taproot-Privacy-preserving-switchable-scripting.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Taproot-Privacy-preserving-switchable-scripting.xml @@ -1,74 +1,111 @@ - + 2 Combined summary - Taproot: Privacy preserving switchable scripting - 2023-08-01T22:32:02.453935+00:00 - - ZmnSCPxj 2018-02-05 09:27:07+00:00 - - - Matt Corallo 2018-01-27 17:23:12+00:00 - - - Russell O'Connor 2018-01-27 17:07:25+00:00 - - - Gregory Maxwell 2018-01-26 21:34:39+00:00 - - - Natanael 2018-01-25 00:09:31+00:00 - - - Tim Ruffing 2018-01-24 23:22:05+00:00 - - - Natanael 2018-01-24 18:51:27+00:00 - - - Tim Ruffing 2018-01-24 15:38:11+00:00 - - - Natanael 2018-01-24 12:51:45+00:00 - - - Tim Ruffing 2018-01-24 09:28:20+00:00 - - - Andrew Poelstra 2018-01-24 01:52:57+00:00 - - - Gregory Maxwell 2018-01-23 22:45:06+00:00 - - - Anthony Towns 2018-01-23 22:22:29+00:00 - - - Gregory Maxwell 2018-01-23 21:38:13+00:00 - - - Matt Corallo 2018-01-23 21:23:21+00:00 - - - Greg Sanders 2018-01-23 15:43:59+00:00 - - - Mark Friedenbach 2018-01-23 14:39:37+00:00 - - - Gregory Maxwell 2018-01-23 13:15:38+00:00 - - - Anthony Towns 2018-01-23 06:44:19+00:00 - - - Matt Corallo 2018-01-23 02:51:51+00:00 - - - Chris Belcher 2018-01-23 01:55:07+00:00 - - - Gregory Maxwell 2018-01-23 00:30:06+00:00 - + 2025-09-26T15:40:22.988217+00:00 + python-feedgen + + + [bitcoin-dev] Taproot: Privacy preserving switchable scripting Gregory Maxwell + 2018-01-23T00:30:00.000Z + + + Chris Belcher + 2018-01-23T01:55:00.000Z + + + Matt Corallo + 2018-01-23T02:51:00.000Z + + + Anthony Towns + 2018-01-23T06:44:00.000Z + + + Gregory Maxwell + 2018-01-23T13:15:00.000Z + + + Mark Friedenbach + 2018-01-23T14:39:00.000Z + + + Greg Sanders + 2018-01-23T15:43:00.000Z + + + Matt Corallo + 2018-01-23T21:23:00.000Z + + + Gregory Maxwell + 2018-01-23T21:38:00.000Z + + + Anthony Towns + 2018-01-23T22:22:00.000Z + + + Gregory Maxwell + 2018-01-23T22:45:00.000Z + + + Andrew Poelstra + 2018-01-24T01:52:00.000Z + + + Tim Ruffing + 2018-01-24T09:28:00.000Z + + + Natanael + 2018-01-24T12:51:00.000Z + + + Tim Ruffing + 2018-01-24T15:38:00.000Z + + + Natanael + 2018-01-24T18:51:00.000Z + + + Tim Ruffing + 2018-01-24T23:22:00.000Z + + + Natanael + 2018-01-25T00:09:00.000Z + + + [bitcoin-dev] Recovery of old UTXOs in a post-quantum world Tim Ruffing + 2018-01-26T13:14:00.000Z + + + Gregory Maxwell + 2018-01-26T21:34:00.000Z + + + [bitcoin-dev] Taproot: Privacy preserving switchable scripting Russell O'Connor + 2018-01-27T17:07:00.000Z + + + Matt Corallo + 2018-01-27T17:23:00.000Z + + + [bitcoin-dev] Taproot: Privacy preserving switchable scripting ZmnSCPxj + 2018-02-05T09:27:00.000Z + + + [bitcoin-dev] Generalised taproot Anthony Towns + 2018-07-13T01:51:00.000Z + + + Pieter Wuille + 2018-10-24T02:22:00.000Z + + @@ -91,13 +128,13 @@ - python-feedgen + 2 Combined summary - Taproot: Privacy preserving switchable scripting - 2023-08-01T22:32:02.454936+00:00 + 2025-09-26T15:40:22.990817+00:00 - The bitcoin community is currently discussing the adoption of Taproot, a privacy-enhancing upgrade proposed by Gregory Maxwell. Taproot aims to make complex smart contract conditions indistinguishable from normal payments, increasing the anonymity set of smart contract users. Some members of the community argue that while Taproot may offer benefits, it is not optimal and suggest enabling features in a generic way first before creating specialized templates.The use of merkelized abstract syntax trees (MAST) in Bitcoin is also being discussed, with MAST providing efficiency and privacy benefits. Matt Corallo expresses concerns about the adoption of Taproot without support for a privacy-encouraging wrapper, emphasizing the importance of privacy in Bitcoin transactions.Anthony Towns questions whether paying directly to a pubkey instead of a pubkey hash is a step backwards in terms of resistance to quantum attacks against ECC. However, using hashing for quantum resistance may not be as effective as previously thought.The proposal for Taproot is generally well-received, as it allows for greater privacy and efficiency in smart contracts. It makes special cases indistinguishable from normal payments and supports any number of participants. Taproot enables the largest possible anonymity set for fixed-party smart contracts without requiring impractical techniques or extra rounds of interaction between participants. Merkelized ScriptPubKeys (MAST) are also gaining popularity due to their efficiency and privacy benefits. The use of a delegating CHECKSIG called Taproot allows for the creation of smart contracts that look like simple payments, without any overhead.Overall, the adoption of Taproot and MAST in Bitcoin has the potential to enhance privacy and efficiency in smart contract transactions. 2018-02-05T09:27:07+00:00 + The bitcoin community is currently discussing the adoption of Taproot, a privacy-enhancing upgrade proposed by Gregory Maxwell. Taproot aims to make complex smart contract conditions indistinguishable from normal payments, increasing the anonymity set of smart contract users. Some members of the community argue that while Taproot may offer benefits, it is not optimal and suggest enabling features in a generic way first before creating specialized templates.The use of merkelized abstract syntax trees (MAST) in Bitcoin is also being discussed, with MAST providing efficiency and privacy benefits. Matt Corallo expresses concerns about the adoption of Taproot without support for a privacy-encouraging wrapper, emphasizing the importance of privacy in Bitcoin transactions.Anthony Towns questions whether paying directly to a pubkey instead of a pubkey hash is a step backwards in terms of resistance to quantum attacks against ECC. However, using hashing for quantum resistance may not be as effective as previously thought.The proposal for Taproot is generally well-received, as it allows for greater privacy and efficiency in smart contracts. It makes special cases indistinguishable from normal payments and supports any number of participants. Taproot enables the largest possible anonymity set for fixed-party smart contracts without requiring impractical techniques or extra rounds of interaction between participants. Merkelized ScriptPubKeys (MAST) are also gaining popularity due to their efficiency and privacy benefits. The use of a delegating CHECKSIG called Taproot allows for the creation of smart contracts that look like simple payments, without any overhead.Overall, the adoption of Taproot and MAST in Bitcoin has the potential to enhance privacy and efficiency in smart contract transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Total-fees-have-almost-crossed-the-block-reward.xml b/static/bitcoin-dev/Feb_2018/combined_Total-fees-have-almost-crossed-the-block-reward.xml index 3fa3cade60..6b3b531b9c 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Total-fees-have-almost-crossed-the-block-reward.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Total-fees-have-almost-crossed-the-block-reward.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Total fees have almost crossed the block reward - 2023-08-01T22:21:48.742306+00:00 - - Peter Todd 2018-02-13 19:03:17+00:00 - - - Christian Decker 2018-02-12 19:41:39+00:00 - - - Peter Todd 2018-02-12 18:12:32+00:00 - - - rhavar at protonmail.com 2018-02-12 17:47:50+00:00 - - - Melvin Carvalho 2018-02-12 17:23:35+00:00 - - - Gregory Maxwell 2017-12-22 01:15:46+00:00 - - - Mark Friedenbach 2017-12-22 00:30:52+00:00 - - - Paul Iverson 2017-12-21 23:35:28+00:00 - - - Michel 'ic' Luczak 2017-12-21 23:15:18+00:00 - - - Gregory Maxwell 2017-12-21 22:44:32+00:00 - - - Jim Rogers 2017-12-21 22:18:32+00:00 - - - Jameson Lopp 2017-12-21 22:02:37+00:00 - - - Melvin Carvalho 2017-12-21 21:30:20+00:00 - + 2025-09-26T15:39:47.322805+00:00 + python-feedgen + + + [bitcoin-dev] Total fees have almost crossed the block reward Melvin Carvalho + 2017-12-21T21:30:00.000Z + + + Jameson Lopp + 2017-12-21T22:02:00.000Z + + + Jim Rogers + 2017-12-21T22:18:00.000Z + + + Gregory Maxwell + 2017-12-21T22:44:00.000Z + + + Michel 'ic' Luczak + 2017-12-21T23:15:00.000Z + + + Paul Iverson + 2017-12-21T23:35:00.000Z + + + Mark Friedenbach + 2017-12-22T00:30:00.000Z + + + Gregory Maxwell + 2017-12-22T01:15:00.000Z + + + Melvin Carvalho + 2018-02-12T17:23:00.000Z + + + rhavar + 2018-02-12T17:47:00.000Z + + + Peter Todd + 2018-02-12T18:12:00.000Z + + + Christian Decker + 2018-02-12T19:41:00.000Z + + + Peter Todd + 2018-02-13T19:03:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Total fees have almost crossed the block reward - 2023-08-01T22:21:48.742306+00:00 + 2025-09-26T15:39:47.324282+00:00 - In a recent discussion on the Bitcoin development mailing list, Christian Decker and Peter Todd discuss how shabang.io determines whether a transaction has funded a Lightning channel. Decker suggests that the website collects short_channel_ids which point to on-chain outputs that funded a channel, but this method only works for public channels. Todd recommends that shabang.io document their process on their website to provide more transparency.Melvin Carvalho, a member of the Bitcoin development team, discovers shabang.io, a website that shows the adoption of the Lightning Network on the mainnet. He notes that the Lightning Network is growing well and predicts that over 1% of bitcoin transactions will be lightning-based by the end of the year. However, Peter Todd questions how shabang.io determines whether a transaction has funded a Lightning channel.Carvalho also shares some data points on the current state of Bitcoin, including increasing fees, the potential for fees to become prohibitive for some use cases, segwit adoption at around 10%, mempool congestion, fee distribution, and Lightning Network adoption on the mainnet. He hopes these stats will provide useful information for the evolution of the project.In another discussion on the Bitcoin-dev mailing list, Mark Friedenbach states that every transaction is already replace-by-fee capable, and opt-in replace by fee is a fiction that was only relevant when fees were smaller than subsidy. The debate revolves around whether or not to default opt-in replace by fee in Bitcoin Core. Electrum has been using opt-in replace by fee as default without issues. Some industrial users express concerns, but Friedenbach believes they can easily change their settings upon release.The rise in Bitcoin transaction fees is seen by some experts as a sign of success and the manifestation of a long-desired fee market. Gregory Maxwell believes that the increased activity level and fee-paying backlogs are necessary for consensus progress as the subsidy declines. However, users are frustrated when transactions get stuck. Paul Iverson suggests making replace-by-fee (RBF) ubiquitous to improve user experience, and Melvin Carvalho expresses concern that fees may be prohibitive for some use cases. Segwit adoption is around 10%, indicating room for education on efficient transaction styles.Gregory Maxwell expresses excitement about the fee market in action and proposes making every transaction RBF by default to address stuck transaction issues. He believes this would improve the user experience and secure the blockchain in the long term. Melvin Carvalho raises concerns about the security of the blockchain once the reward goes away and fees replace it. Segwit adoption stands at around 10%, and congestion is currently high. Maxwell suggests looking at difficult-to-forge market signals and other inefficient transaction styles for further analysis.In an email thread, Jameson Lopp thanks someone for an interview and discusses the high fees experienced in the blockchain. He believes that most hardware and software wallets miscalculate fees, causing the issue. He suggests that high volume senders should be more efficient in their use of block space by batching transactions and implementing SegWit. Melvin Carvalho asks about the long-term security of Bitcoin once the reward goes away, expressing concern about the fee per transaction being prohibitive for certain use cases. Observations show around 10% segwit adoption and peak congestion in the mempool.The long-term security of the blockchain is a concern as fees replace the block reward. Fees currently make up 45% of the block reward, with potential to reach 50%. However, there is concern that the fee per transaction may be too high for some use cases, especially as segwit adoption stands at around 10%. Efforts are being made to encourage efficient use of block space through batching transactions and implementing segwit. The mempool shows congestion, but it may decrease over time.Overall, the discussions and emails highlight concerns about the long-term security of the blockchain, the need for efficient use of block space, the rise in transaction fees, segwit adoption, and the increasing use of the Lightning Network. 2018-02-13T19:03:17+00:00 + In a recent discussion on the Bitcoin development mailing list, Christian Decker and Peter Todd discuss how shabang.io determines whether a transaction has funded a Lightning channel. Decker suggests that the website collects short_channel_ids which point to on-chain outputs that funded a channel, but this method only works for public channels. Todd recommends that shabang.io document their process on their website to provide more transparency.Melvin Carvalho, a member of the Bitcoin development team, discovers shabang.io, a website that shows the adoption of the Lightning Network on the mainnet. He notes that the Lightning Network is growing well and predicts that over 1% of bitcoin transactions will be lightning-based by the end of the year. However, Peter Todd questions how shabang.io determines whether a transaction has funded a Lightning channel.Carvalho also shares some data points on the current state of Bitcoin, including increasing fees, the potential for fees to become prohibitive for some use cases, segwit adoption at around 10%, mempool congestion, fee distribution, and Lightning Network adoption on the mainnet. He hopes these stats will provide useful information for the evolution of the project.In another discussion on the Bitcoin-dev mailing list, Mark Friedenbach states that every transaction is already replace-by-fee capable, and opt-in replace by fee is a fiction that was only relevant when fees were smaller than subsidy. The debate revolves around whether or not to default opt-in replace by fee in Bitcoin Core. Electrum has been using opt-in replace by fee as default without issues. Some industrial users express concerns, but Friedenbach believes they can easily change their settings upon release.The rise in Bitcoin transaction fees is seen by some experts as a sign of success and the manifestation of a long-desired fee market. Gregory Maxwell believes that the increased activity level and fee-paying backlogs are necessary for consensus progress as the subsidy declines. However, users are frustrated when transactions get stuck. Paul Iverson suggests making replace-by-fee (RBF) ubiquitous to improve user experience, and Melvin Carvalho expresses concern that fees may be prohibitive for some use cases. Segwit adoption is around 10%, indicating room for education on efficient transaction styles.Gregory Maxwell expresses excitement about the fee market in action and proposes making every transaction RBF by default to address stuck transaction issues. He believes this would improve the user experience and secure the blockchain in the long term. Melvin Carvalho raises concerns about the security of the blockchain once the reward goes away and fees replace it. Segwit adoption stands at around 10%, and congestion is currently high. Maxwell suggests looking at difficult-to-forge market signals and other inefficient transaction styles for further analysis.In an email thread, Jameson Lopp thanks someone for an interview and discusses the high fees experienced in the blockchain. He believes that most hardware and software wallets miscalculate fees, causing the issue. He suggests that high volume senders should be more efficient in their use of block space by batching transactions and implementing SegWit. Melvin Carvalho asks about the long-term security of Bitcoin once the reward goes away, expressing concern about the fee per transaction being prohibitive for certain use cases. Observations show around 10% segwit adoption and peak congestion in the mempool.The long-term security of the blockchain is a concern as fees replace the block reward. Fees currently make up 45% of the block reward, with potential to reach 50%. However, there is concern that the fee per transaction may be too high for some use cases, especially as segwit adoption stands at around 10%. Efforts are being made to encourage efficient use of block space through batching transactions and implementing segwit. The mempool shows congestion, but it may decrease over time.Overall, the discussions and emails highlight concerns about the long-term security of the blockchain, the need for efficient use of block space, the rise in transaction fees, segwit adoption, and the increasing use of the Lightning Network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2018/combined_Transition-to-post-quantum.xml b/static/bitcoin-dev/Feb_2018/combined_Transition-to-post-quantum.xml index 7b517340f4..bd28f59fa0 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Transition-to-post-quantum.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Transition-to-post-quantum.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Transition to post-quantum - 2023-08-01T22:39:00.161188+00:00 - - Erik Aronesty 2019-10-24 15:34:14+00:00 - - - Tim Ruffing 2018-02-15 23:44:19+00:00 - - - Natanael 2018-02-15 22:45:09+00:00 - - - Natanael 2018-02-15 22:44:05+00:00 - - - Tim Ruffing 2018-02-15 21:57:41+00:00 - - - Natanael 2018-02-15 20:27:27+00:00 - - - Tim Ruffing 2018-02-15 15:59:27+00:00 - - - Tristan Hoy 2018-02-13 10:06:31+00:00 - - - Tim Ruffing 2018-02-13 06:46:14+00:00 - - - Tristan Hoy 2018-02-12 21:32:35+00:00 - - - Tim Ruffing 2018-02-12 15:50:50+00:00 - - - Tristan Hoy 2018-02-12 14:13:11+00:00 - + 2025-09-26T15:40:06.160984+00:00 + python-feedgen + + + [bitcoin-dev] Transition to post-quantum Tristan Hoy + 2018-02-12T14:13:00.000Z + + + Tim Ruffing + 2018-02-12T15:50:00.000Z + + + Tristan Hoy + 2018-02-12T21:32:00.000Z + + + Tim Ruffing + 2018-02-13T06:46:00.000Z + + + Tristan Hoy + 2018-02-13T10:06:00.000Z + + + Tim Ruffing + 2018-02-15T15:59:00.000Z + + + Natanael + 2018-02-15T20:27:00.000Z + + + Tim Ruffing + 2018-02-15T21:57:00.000Z + + + Natanael + 2018-02-15T22:44:00.000Z + + + Natanael + 2018-02-15T22:45:00.000Z + + + Tim Ruffing + 2018-02-15T23:44:00.000Z + + + Erik Aronesty + 2019-10-24T15:34:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Transition to post-quantum - 2023-08-01T22:39:00.161188+00:00 + 2025-09-26T15:40:06.162486+00:00 - A spam-proof scheme has been proposed to address the quantum threat in blockchain. The scheme involves publishing a transaction on the blockchain that lists pre-quantum signature and hash of post-quantum address. Future transactions would require both pre and post-quantum signatures. There are two quantum addressing schemes, and if a new discovery shows a second scheme with smaller transactions and faster validation, Soft-fork 2 will refuse upgrades to the first scheme beyond a certain block number.Zero-knowledge proofs are discussed as a means to recover an UTXO with a P2PKH address, but it can be complex for arbitrary scripts. Natanael suggests publishing the full transaction except for public keys and signatures, committing to it, and revealing it later to prevent attackers from modifying the transaction. However, this approach can be a target for Denial of Service (DoS) attacks. Rate limiting is not considered safe, but requiring transaction fees even for commitments may be a solution. The feasibility of such solutions depends on the efficiency of zero-knowledge proof systems.In an email conversation, Natanael expresses concerns about the security implications of allowing expiration for a certain system. However, the exact details of the system and context of the conversation are not provided. The email exchange involves a discussion about the potential security risks associated with allowing expiration for a particular system.In an email discussion on the Bitcoin development mailing list, Tim Ruffing proposes a scheme for securing transactions using hash commitments. Some members raise concerns about the security and practicality of the proposal. One issue raised is the vulnerability to denial-of-service attacks if transactions expire. No consensus is reached on the proposal.In an email exchange between Natanael and Tim, they discuss a potential attack on Bitcoin's commitment scheme. In one situation, an attacker can block an honest user's transaction and make their own commitment and transaction. However, the honest commitment wins and the attacker is unsuccessful.Tim Ruffing sends a message to the bitcoin-dev mailing list regarding consensus rules for UTXOs and commitments. He describes two different situations related to commitment expiration and doubles in the blockchain. No consensus is reached on the proposal.The proposal is to include a classic signature to ensure that if the classic_pk has been revealed, then anyone can prevent spending funds as desired. A fixed variant is presented that supports any hash-based addresses. The scheme requires multiple hash functions and authenticated symmetric encryption. It proposes a commit step and a decommit step to spend a UTXO. The scheme is a variant of Adam Back's proposal for committed transactions. The main problem is the flooding of the blockchain with commitments, but it can be addressed through transaction fees. Double-spending is excluded after the first step is confirmed.In a post-quantum world, a certain type of transaction in Bitcoin is vulnerable to front-running if ECDSA is broken. The decommit step does not specify the effects, while the commit step fixes this. A proactive measure is required before ECDSA is compromised. Tristan Hoy proposes a strategy that mitigates against a post-quantum attack without changes to the Bitcoin protocol. It involves changing key generation only and would be implemented by wallet providers.Tristan Hoy presents research on post-quantum attacks on Bitcoin and options for mitigation. Recommended post-quantum DSAs are not scalable, and committing to a specific one would be premature. He proposes a strategy that mitigates against the worst-case scenario without protocol changes or commitment to a specific DSA. The strategy involves a change to key generation and would be implemented by wallet providers.Tristan Hoy proposes a strategy to mitigate the potential effects of a post-quantum attack on Bitcoin. None of the recommended post-quantum DSAs are scalable. The strategy involves changing key generation and would be implemented by wallet providers.In a recent message, Tristan Hoy shares research on post-quantum attacks on Bitcoin and options for mitigation. None of the recommended post-quantum DSA algorithms are scalable, but a strategy that mitigates against the worst-case scenario without protocol changes or commitment to a specific DSA is proposed. The strategy involves a change to key generation and would be implemented by wallet providers. Feedback on the proposal is requested.Dr. Matt Green, a cryptography expert, has proposed a scalable solution for addressing the security vulnerabilities that may arise from quantum computers attacking Bitcoin's Elliptic Curve Digital Signature Algorithm (ECDSA). In his proposal, Dr. Green outlines a strategy to mitigate the potential risks of an early attack on ECDSA without making any alterations to the Bitcoin protocol or committing to a specific post-quantum Digital Signature Algorithm (DSA) that may become outdated in the next 3-5 years.The suggested solution revolves around modifying only the key generation process, which would be implemented by wallet providers. By making this change, the proposal aims to provide a secure method for transferring balances into a post-quantum DSA address space, even if ECDSA is completely compromised. The 2019-10-24T15:34:14+00:00 + A spam-proof scheme has been proposed to address the quantum threat in blockchain. The scheme involves publishing a transaction on the blockchain that lists pre-quantum signature and hash of post-quantum address. Future transactions would require both pre and post-quantum signatures. There are two quantum addressing schemes, and if a new discovery shows a second scheme with smaller transactions and faster validation, Soft-fork 2 will refuse upgrades to the first scheme beyond a certain block number.Zero-knowledge proofs are discussed as a means to recover an UTXO with a P2PKH address, but it can be complex for arbitrary scripts. Natanael suggests publishing the full transaction except for public keys and signatures, committing to it, and revealing it later to prevent attackers from modifying the transaction. However, this approach can be a target for Denial of Service (DoS) attacks. Rate limiting is not considered safe, but requiring transaction fees even for commitments may be a solution. The feasibility of such solutions depends on the efficiency of zero-knowledge proof systems.In an email conversation, Natanael expresses concerns about the security implications of allowing expiration for a certain system. However, the exact details of the system and context of the conversation are not provided. The email exchange involves a discussion about the potential security risks associated with allowing expiration for a particular system.In an email discussion on the Bitcoin development mailing list, Tim Ruffing proposes a scheme for securing transactions using hash commitments. Some members raise concerns about the security and practicality of the proposal. One issue raised is the vulnerability to denial-of-service attacks if transactions expire. No consensus is reached on the proposal.In an email exchange between Natanael and Tim, they discuss a potential attack on Bitcoin's commitment scheme. In one situation, an attacker can block an honest user's transaction and make their own commitment and transaction. However, the honest commitment wins and the attacker is unsuccessful.Tim Ruffing sends a message to the bitcoin-dev mailing list regarding consensus rules for UTXOs and commitments. He describes two different situations related to commitment expiration and doubles in the blockchain. No consensus is reached on the proposal.The proposal is to include a classic signature to ensure that if the classic_pk has been revealed, then anyone can prevent spending funds as desired. A fixed variant is presented that supports any hash-based addresses. The scheme requires multiple hash functions and authenticated symmetric encryption. It proposes a commit step and a decommit step to spend a UTXO. The scheme is a variant of Adam Back's proposal for committed transactions. The main problem is the flooding of the blockchain with commitments, but it can be addressed through transaction fees. Double-spending is excluded after the first step is confirmed.In a post-quantum world, a certain type of transaction in Bitcoin is vulnerable to front-running if ECDSA is broken. The decommit step does not specify the effects, while the commit step fixes this. A proactive measure is required before ECDSA is compromised. Tristan Hoy proposes a strategy that mitigates against a post-quantum attack without changes to the Bitcoin protocol. It involves changing key generation only and would be implemented by wallet providers.Tristan Hoy presents research on post-quantum attacks on Bitcoin and options for mitigation. Recommended post-quantum DSAs are not scalable, and committing to a specific one would be premature. He proposes a strategy that mitigates against the worst-case scenario without protocol changes or commitment to a specific DSA. The strategy involves a change to key generation and would be implemented by wallet providers.Tristan Hoy proposes a strategy to mitigate the potential effects of a post-quantum attack on Bitcoin. None of the recommended post-quantum DSAs are scalable. The strategy involves changing key generation and would be implemented by wallet providers.In a recent message, Tristan Hoy shares research on post-quantum attacks on Bitcoin and options for mitigation. None of the recommended post-quantum DSA algorithms are scalable, but a strategy that mitigates against the worst-case scenario without protocol changes or commitment to a specific DSA is proposed. The strategy involves a change to key generation and would be implemented by wallet providers. Feedback on the proposal is requested.Dr. Matt Green, a cryptography expert, has proposed a scalable solution for addressing the security vulnerabilities that may arise from quantum computers attacking Bitcoin's Elliptic Curve Digital Signature Algorithm (ECDSA). In his proposal, Dr. Green outlines a strategy to mitigate the potential risks of an early attack on ECDSA without making any alterations to the Bitcoin protocol or committing to a specific post-quantum Digital Signature Algorithm (DSA) that may become outdated in the next 3-5 years.The suggested solution revolves around modifying only the key generation process, which would be implemented by wallet providers. By making this change, the proposal aims to provide a secure method for transferring balances into a post-quantum DSA address space, even if ECDSA is completely compromised. The - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_-BIP-Proposal-Simple-Proof-of-Reserves-Transactions.xml b/static/bitcoin-dev/Feb_2019/combined_-BIP-Proposal-Simple-Proof-of-Reserves-Transactions.xml index b34c0875cb..4d0b90e103 100644 --- a/static/bitcoin-dev/Feb_2019/combined_-BIP-Proposal-Simple-Proof-of-Reserves-Transactions.xml +++ b/static/bitcoin-dev/Feb_2019/combined_-BIP-Proposal-Simple-Proof-of-Reserves-Transactions.xml @@ -1,23 +1,36 @@ - + 2 Combined summary - [BIP Proposal] Simple Proof-of-Reserves Transactions - 2023-08-02T00:26:06.910385+00:00 - - Luke Dashjr 2019-02-15 15:18:18+00:00 - - - Steven Roose 2019-01-29 22:03:04+00:00 - + 2025-09-26T15:48:06.288128+00:00 + python-feedgen + + + [bitcoin-dev] [BIP Proposal] Simple Proof-of-Reserves Transactions Steven Roose + 2019-01-29T22:03:00.000Z + + + Luke Dashjr + 2019-02-15T15:18:00.000Z + + + [bitcoin-dev] NIH warning (was Re: [BIP Proposal] Simple Proof-of-Reserves Transactions) Pavol Rusnak + 2019-02-16T16:49:00.000Z + + + William Casarin + 2019-02-17T18:00:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Simple Proof-of-Reserves Transactions - 2023-08-02T00:26:06.910385+00:00 + 2025-09-26T15:48:06.288765+00:00 - Recently, there was a discussion on the Bitcoin-developer mailing list regarding a proposed proof format that aims to combine multiple proofs and associated metadata in a standardized way. The format, specified in the Protocol Buffers format, is designed to ensure easy verification of proofs even when some of the UTXOs used in the proof are no longer unspent.However, one participant expressed concerns about the format's content, citing previous controversies surrounding its use in BIP70, which might hinder its adoption. Another participant highlighted the lack of sufficient information in the format and suggested the inclusion of a merkle proof.In a related development, a draft of a new Bitcoin Improvement Proposal (BIP) has been introduced, outlining a proposal for constructing proof-of-reserves transactions. The BIP seeks to establish a standard format for creating proofs, enabling the development of general proof-verification software and facilitating integration with existing wallet infrastructure.The motivation behind this proposal is to provide companies managing significant amounts of Bitcoin with a means to prove ownership over their funds without disclosing events publicly, thereby preventing substantial losses. The proposed proof format is designed to be flexible and compatible with existing systems, resembling regular Bitcoin transactions with slight adaptations.To package multiple proofs and relevant metadata, the proposal includes a file format based on Protocol Buffers. Additionally, an extension to BIP 174 PSBT format is suggested to aid signing devices in recognizing proof-of-reserve transactions. Interested individuals can find a proof-of-concept implementation of the PSBT extension in the rust-bitcoin project, along with a work-in-progress implementation for producing and verifying proofs in the described format. It's worth noting that although an invalid transaction cannot be proven by nodes, it may still be cached as a "transaction," occupying memory resources. 2019-02-15T15:18:18+00:00 + Recently, there was a discussion on the Bitcoin-developer mailing list regarding a proposed proof format that aims to combine multiple proofs and associated metadata in a standardized way. The format, specified in the Protocol Buffers format, is designed to ensure easy verification of proofs even when some of the UTXOs used in the proof are no longer unspent.However, one participant expressed concerns about the format's content, citing previous controversies surrounding its use in BIP70, which might hinder its adoption. Another participant highlighted the lack of sufficient information in the format and suggested the inclusion of a merkle proof.In a related development, a draft of a new Bitcoin Improvement Proposal (BIP) has been introduced, outlining a proposal for constructing proof-of-reserves transactions. The BIP seeks to establish a standard format for creating proofs, enabling the development of general proof-verification software and facilitating integration with existing wallet infrastructure.The motivation behind this proposal is to provide companies managing significant amounts of Bitcoin with a means to prove ownership over their funds without disclosing events publicly, thereby preventing substantial losses. The proposed proof format is designed to be flexible and compatible with existing systems, resembling regular Bitcoin transactions with slight adaptations.To package multiple proofs and relevant metadata, the proposal includes a file format based on Protocol Buffers. Additionally, an extension to BIP 174 PSBT format is suggested to aid signing devices in recognizing proof-of-reserve transactions. Interested individuals can find a proof-of-concept implementation of the PSBT extension in the rust-bitcoin project, along with a work-in-progress implementation for producing and verifying proofs in the described format. It's worth noting that although an invalid transaction cannot be proven by nodes, it may still be cached as a "transaction," occupying memory resources. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_BIP-Symbol-for-satoshi.xml b/static/bitcoin-dev/Feb_2019/combined_BIP-Symbol-for-satoshi.xml index 0df8fe31f4..281267723f 100644 --- a/static/bitcoin-dev/Feb_2019/combined_BIP-Symbol-for-satoshi.xml +++ b/static/bitcoin-dev/Feb_2019/combined_BIP-Symbol-for-satoshi.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - BIP - Symbol for satoshi - 2023-08-02T00:32:15.254714+00:00 - - Federico Tenga 2019-03-07 18:10:41+00:00 - - - Tamas Blummer 2019-03-07 10:57:03+00:00 - - - Amine Chakak 2019-03-06 23:59:12+00:00 - - - Gregory Maxwell 2019-03-06 23:35:49+00:00 - - - Amine Chakak 2019-02-23 22:10:28+00:00 - + 2025-09-26T15:48:18.847546+00:00 + python-feedgen + + + [bitcoin-dev] BIP - Symbol for satoshi Amine Chakak + 2019-02-23T22:10:00.000Z + + + Gregory Maxwell + 2019-03-06T23:35:00.000Z + + + Amine Chakak + 2019-03-06T23:59:00.000Z + + + Tamas Blummer + 2019-03-07T10:57:00.000Z + + + Federico Tenga + 2019-03-07T18:10:00.000Z + + - python-feedgen + 2 Combined summary - BIP - Symbol for satoshi - 2023-08-02T00:32:15.254714+00:00 + 2025-09-26T15:48:18.848276+00:00 - In a recent discussion on the bitcoin-dev mailing list, Gregory Maxwell expressed his opposition to naming the smallest unit of bitcoin after Satoshi. He argued that if Satoshi wanted this, he would have done it himself and that the behavior is "creepy" and harmful to Bitcoin. However, another participant in the discussion disagreed, stating that having a common term for small amounts is important for improving user experience. They believe that using satoshis as a unit is more likely to achieve this goal than scientific notations.One potential issue with using satoshis as a unit is that it may sound strange or even humorous to native Japanese speakers. The discussion suggests that getting feedback from Japanese speakers on this topic could be useful. Regarding the proposal to formalize the symbol for satoshi, there is some disagreement about whether it has sufficient support to become a standard. The suggestion is made to wait for something to emerge that already has widespread usage, such as a symbol used by popular wallets or service providers.Non-engineers are unlikely to adopt scientific notation or mili/nano/pico prefixes for money. The convention is that most common currencies either have no change or only one that is 1/100 of the base unit, which is what practically all existing finance software and non-Bitcoin related UI that deals with money assumes. Bitcoin engineering blindness ignores evident cultural preference and pre-existing finance-related software.Tamas Blummer supports the BIP for bits as a base unit for Bitcoin. However, Gregory Maxwell finds it creepy and harmful to Bitcoin to name currency units after Satoshi. Lightning network does not use satoshis as a base unit but uses units of 10 picobitcoin. A BIP for satoshi as a base unit is not appropriate.In an email exchange between Amine Chakak and Gregory Maxwell, the idea of switching the base unit of Bitcoin to Satoshi was discussed. However, Maxwell expressed his disagreement with the idea, stating that if Satoshi Nakamoto had wanted the currency units named after him, he would have done so himself. Maxwell also criticized the behavior as "creepy" and "harmful" to Bitcoin. Chakak also mentioned the use of satoshis as a base unit in the Lightning Network, but Maxwell corrected him, stating that Lightning uses units of 10 picobitcoin (1e-11 btc), which is significantly smaller. Finally, Chakak asked if it would be appropriate to write a BIP for the proposed change, but Maxwell advised against it, stating "Please don't."A proposal to switch to "satoshi" as a base unit for Bitcoin has been floated around, but it has met with criticism from some members of the Bitcoin community. The idea was presented on the bitcoin-dev mailing list by Amine Chakak, but one user argued that if Bitcoin creator Satoshi Nakamoto had wanted the currency units named after him, he would have done so himself. Additionally, another user pointed out that the lightning network, which is built on top of Bitcoin, actually uses units of 10 picobitcoin rather than satoshis. As a result, the idea of creating a Bitcoin Improvement Proposal (BIP) for the switch to satoshi as a base unit was discouraged.The writer is proposing an idea for a satoshi symbol to be used as the base unit in cryptocurrency transactions. The proposal comes from Twitter user @bitficus, and the idea has already been discussed within the community since the lightning network already uses satoshis as a base unit. The proposal link is provided and the writer asks if it would be appropriate to write a BIP (Bitcoin Improvement Proposal) for it. The writer is following the website's instruction to first propose ideas for BIPS on the mailing list before submitting them formally. 2019-03-07T18:10:41+00:00 + In a recent discussion on the bitcoin-dev mailing list, Gregory Maxwell expressed his opposition to naming the smallest unit of bitcoin after Satoshi. He argued that if Satoshi wanted this, he would have done it himself and that the behavior is "creepy" and harmful to Bitcoin. However, another participant in the discussion disagreed, stating that having a common term for small amounts is important for improving user experience. They believe that using satoshis as a unit is more likely to achieve this goal than scientific notations.One potential issue with using satoshis as a unit is that it may sound strange or even humorous to native Japanese speakers. The discussion suggests that getting feedback from Japanese speakers on this topic could be useful. Regarding the proposal to formalize the symbol for satoshi, there is some disagreement about whether it has sufficient support to become a standard. The suggestion is made to wait for something to emerge that already has widespread usage, such as a symbol used by popular wallets or service providers.Non-engineers are unlikely to adopt scientific notation or mili/nano/pico prefixes for money. The convention is that most common currencies either have no change or only one that is 1/100 of the base unit, which is what practically all existing finance software and non-Bitcoin related UI that deals with money assumes. Bitcoin engineering blindness ignores evident cultural preference and pre-existing finance-related software.Tamas Blummer supports the BIP for bits as a base unit for Bitcoin. However, Gregory Maxwell finds it creepy and harmful to Bitcoin to name currency units after Satoshi. Lightning network does not use satoshis as a base unit but uses units of 10 picobitcoin. A BIP for satoshi as a base unit is not appropriate.In an email exchange between Amine Chakak and Gregory Maxwell, the idea of switching the base unit of Bitcoin to Satoshi was discussed. However, Maxwell expressed his disagreement with the idea, stating that if Satoshi Nakamoto had wanted the currency units named after him, he would have done so himself. Maxwell also criticized the behavior as "creepy" and "harmful" to Bitcoin. Chakak also mentioned the use of satoshis as a base unit in the Lightning Network, but Maxwell corrected him, stating that Lightning uses units of 10 picobitcoin (1e-11 btc), which is significantly smaller. Finally, Chakak asked if it would be appropriate to write a BIP for the proposed change, but Maxwell advised against it, stating "Please don't."A proposal to switch to "satoshi" as a base unit for Bitcoin has been floated around, but it has met with criticism from some members of the Bitcoin community. The idea was presented on the bitcoin-dev mailing list by Amine Chakak, but one user argued that if Bitcoin creator Satoshi Nakamoto had wanted the currency units named after him, he would have done so himself. Additionally, another user pointed out that the lightning network, which is built on top of Bitcoin, actually uses units of 10 picobitcoin rather than satoshis. As a result, the idea of creating a Bitcoin Improvement Proposal (BIP) for the switch to satoshi as a base unit was discouraged.The writer is proposing an idea for a satoshi symbol to be used as the base unit in cryptocurrency transactions. The proposal comes from Twitter user @bitficus, and the idea has already been discussed within the community since the lightning network already uses satoshis as a base unit. The proposal link is provided and the writer asks if it would be appropriate to write a BIP (Bitcoin Improvement Proposal) for it. The writer is following the website's instruction to first propose ideas for BIPS on the mailing list before submitting them formally. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_BIP-proposal-Signatures-of-Messages-using-Bitcoin-Private-Keys.xml b/static/bitcoin-dev/Feb_2019/combined_BIP-proposal-Signatures-of-Messages-using-Bitcoin-Private-Keys.xml index ad13858ec9..da10522f0e 100644 --- a/static/bitcoin-dev/Feb_2019/combined_BIP-proposal-Signatures-of-Messages-using-Bitcoin-Private-Keys.xml +++ b/static/bitcoin-dev/Feb_2019/combined_BIP-proposal-Signatures-of-Messages-using-Bitcoin-Private-Keys.xml @@ -1,39 +1,52 @@ - + 2 Combined summary - BIP proposal - Signatures of Messages using Bitcoin Private Keys - 2023-08-02T00:30:29.642223+00:00 - - Christopher Gilliard 2019-02-19 00:29:34+00:00 - - - Aymeric Vitte 2019-02-18 23:50:30+00:00 - - - Christopher Gilliard 2019-02-18 23:24:27+00:00 - - - Aymeric Vitte 2019-02-18 22:59:25+00:00 - - - Adam Ficsor 2019-02-17 19:42:05+00:00 - - - Christopher Gilliard 2019-02-17 14:14:37+00:00 - + 2025-09-26T15:48:20.937489+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys Christopher Gilliard + 2019-02-17T14:14:00.000Z + + + Adam Ficsor + 2019-02-17T19:42:00.000Z + + + Aymeric Vitte + 2019-02-18T22:59:00.000Z + + + Christopher Gilliard + 2019-02-18T23:24:00.000Z + + + Aymeric Vitte + 2019-02-18T23:50:00.000Z + + + Christopher Gilliard + 2019-02-19T00:29:00.000Z + + + [bitcoin-dev] Fwd: " Aymeric Vitte + 2019-03-06T10:37:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal - Signatures of Messages using Bitcoin Private Keys - 2023-08-02T00:30:29.642223+00:00 + 2025-09-26T15:48:20.938402+00:00 - A proposed Bitcoin Improvement Proposal (BIP) has been written by Christopher Gilliard, addressing signature formats when using Bitcoin private keys. The proposal includes code for verification but lacks code for signing. Gilliard's proposal aligns with Trezor's implementation in a previous GitHub issue. Feedback on the proposal is welcomed and Gilliard is seeking guidance on how to assign a BIP number or any other necessary process steps. Aymeric Vitte suggests adding a more precise description of the signing/verification process, as it is currently undocumented. Vitte also questions the purpose of the header and its link to keys and signatures. The inclusion of compressed/uncompressed keys in the header serves to identify the type of key used for the signature, avoiding the need to test all options. Gilliard clarifies that the proposal documents existing practices rather than presenting an original invention. The document could be useful to others since this information was not previously specified. 2019-02-19T00:29:34+00:00 + A proposed Bitcoin Improvement Proposal (BIP) has been written by Christopher Gilliard, addressing signature formats when using Bitcoin private keys. The proposal includes code for verification but lacks code for signing. Gilliard's proposal aligns with Trezor's implementation in a previous GitHub issue. Feedback on the proposal is welcomed and Gilliard is seeking guidance on how to assign a BIP number or any other necessary process steps. Aymeric Vitte suggests adding a more precise description of the signing/verification process, as it is currently undocumented. Vitte also questions the purpose of the header and its link to keys and signatures. The inclusion of compressed/uncompressed keys in the header serves to identify the type of key used for the signature, avoiding the need to test all options. Gilliard clarifies that the proposal documents existing practices rather than presenting an original invention. The document could be useful to others since this information was not previously specified. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_BIP-proposal-addrv2-message.xml b/static/bitcoin-dev/Feb_2019/combined_BIP-proposal-addrv2-message.xml index c873c511c5..8770b8ee21 100644 --- a/static/bitcoin-dev/Feb_2019/combined_BIP-proposal-addrv2-message.xml +++ b/static/bitcoin-dev/Feb_2019/combined_BIP-proposal-addrv2-message.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP proposal - addrv2 message - 2023-08-02T00:30:54.606027+00:00 - - Sjors Provoost 2019-03-06 09:05:09+00:00 - - - Gregory Maxwell 2019-03-06 03:02:51+00:00 - - - Wladimir J. van der Laan 2019-02-18 07:56:38+00:00 - + 2025-09-26T15:48:10.490716+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal - addrv2 message Wladimir J. van der Laan + 2019-02-18T07:56:00.000Z + + + Gregory Maxwell + 2019-03-06T03:02:00.000Z + + + Sjors Provoost + 2019-03-06T09:05:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal - addrv2 message - 2023-08-02T00:30:54.606027+00:00 + 2025-09-26T15:48:10.491288+00:00 - The concept ACK discusses several considerations regarding the gossip protocol in Bitcoin. The first consideration is whether a client should store and gossip address formats that they do not know about, especially those outside a certain overlay network. Three scenarios where a node may not know about an address format are discussed, followed by recommendations on how to proceed in each case. Despite concerns about gossiping unverified information, it is suggested that sharing information about other networks could be useful for nodes to help bootstrap connections.Another consideration is the precision of the time field in the protocol. It is argued that using seconds precision can be excessive and harmful. To address this, it is recommended to reduce the time field to 16 bits and quantize it to 1-hour precision, creating a "time ago seen" metric. This would reduce space requirements and mitigate attacks that exploit high-precision timestamps for mapping the current network topology.The document also proposes the inclusion of optional (per-service) data, which could be useful for various purposes, including optional flags. To encode the length of the payload for each flag, a byte count and type system is recommended. The authors acknowledge that while adding more information would create more opportunities for mapping the network topology, it could also be beneficial for certain use cases.A discussion on the Bitcoin-dev mailing list has raised questions about the maximum length of addresses for the Bitcoin protocol, specifically for the I2P network. It is suggested that the maximum address length should be defined per address type, considering there are two formats in use. Additionally, there was a debate on whether clients should store and gossip address formats they do not know about. It is proposed that clients should be discouraged from gossiping types they don't understand but not forbidden from doing so. However, caution should be exercised when gossiping unknown address types to prevent file transfer over invalid address types, particularly for networks without exit nodes.The document proposes a new P2P message called addrv2 to gossip longer node addresses over the P2P network. This is necessary to support new-generation Onion addresses, I2P, and other networks with longer endpoint addresses than what currently fits in the 128 bits of the addr message. The addrv2 message is defined as a message where pchCommand == "addrv2" and is serialized in the standard encoding for P2P messages. It has a format similar to the current addr message but with changes to accommodate longer addresses and a different time and services format.The list of reserved network IDs includes IPV4, IPV6, TORV2, TORV3, I2P, and CJDNS. Clients must ignore address types they do not know about to allow for future extensibility. They may also store and gossip address formats that they do not know about. However, they should reject addresses that have a different length than specified in the table for a specific address ID. The addrv2 messages should only be sent to peers with a certain protocol version or higher.The document lists various considerations that need further discussion, such as gossiping addresses outside a certain overlay network, the lower precision of the time field, rolling port into addr, or making the port optional. It is noted that the reference implementation is not yet available. 2019-03-06T09:05:09+00:00 + The concept ACK discusses several considerations regarding the gossip protocol in Bitcoin. The first consideration is whether a client should store and gossip address formats that they do not know about, especially those outside a certain overlay network. Three scenarios where a node may not know about an address format are discussed, followed by recommendations on how to proceed in each case. Despite concerns about gossiping unverified information, it is suggested that sharing information about other networks could be useful for nodes to help bootstrap connections.Another consideration is the precision of the time field in the protocol. It is argued that using seconds precision can be excessive and harmful. To address this, it is recommended to reduce the time field to 16 bits and quantize it to 1-hour precision, creating a "time ago seen" metric. This would reduce space requirements and mitigate attacks that exploit high-precision timestamps for mapping the current network topology.The document also proposes the inclusion of optional (per-service) data, which could be useful for various purposes, including optional flags. To encode the length of the payload for each flag, a byte count and type system is recommended. The authors acknowledge that while adding more information would create more opportunities for mapping the network topology, it could also be beneficial for certain use cases.A discussion on the Bitcoin-dev mailing list has raised questions about the maximum length of addresses for the Bitcoin protocol, specifically for the I2P network. It is suggested that the maximum address length should be defined per address type, considering there are two formats in use. Additionally, there was a debate on whether clients should store and gossip address formats they do not know about. It is proposed that clients should be discouraged from gossiping types they don't understand but not forbidden from doing so. However, caution should be exercised when gossiping unknown address types to prevent file transfer over invalid address types, particularly for networks without exit nodes.The document proposes a new P2P message called addrv2 to gossip longer node addresses over the P2P network. This is necessary to support new-generation Onion addresses, I2P, and other networks with longer endpoint addresses than what currently fits in the 128 bits of the addr message. The addrv2 message is defined as a message where pchCommand == "addrv2" and is serialized in the standard encoding for P2P messages. It has a format similar to the current addr message but with changes to accommodate longer addresses and a different time and services format.The list of reserved network IDs includes IPV4, IPV6, TORV2, TORV3, I2P, and CJDNS. Clients must ignore address types they do not know about to allow for future extensibility. They may also store and gossip address formats that they do not know about. However, they should reject addresses that have a different length than specified in the table for a specific address ID. The addrv2 messages should only be sent to peers with a certain protocol version or higher.The document lists various considerations that need further discussion, such as gossiping addresses outside a certain overlay network, the lower precision of the time field, rolling port into addr, or making the port optional. It is noted that the reference implementation is not yet available. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml b/static/bitcoin-dev/Feb_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml index ba0ee494d2..d3b491dfac 100644 --- a/static/bitcoin-dev/Feb_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml +++ b/static/bitcoin-dev/Feb_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml @@ -1,65 +1,63 @@ - + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 - - Johan Torås Halseth 2019-10-30 07:22:53+00:00 - - - David A. Harding 2019-10-28 17:14:38+00:00 - - - Johan Torås Halseth 2019-10-28 09:45:39+00:00 - - - David A. Harding 2019-10-27 22:54:02+00:00 - - - Jeremy 2019-10-27 19:13:09+00:00 - - - Matt Corallo 2019-10-25 17:30:41+00:00 - - - Johan Torås Halseth 2019-10-25 07:05:15+00:00 - - - Matt Corallo 2019-10-24 21:25:14+00:00 - - - Johan Torås Halseth 2019-10-24 13:49:09+00:00 - - - Rusty Russell 2019-02-13 04:22:39+00:00 - - - Matt Corallo 2019-01-08 14:46:45+00:00 - - - Rusty Russell 2019-01-08 05:50:20+00:00 - - - Matt Corallo 2019-01-07 15:18:52+00:00 - - - Rusty Russell 2018-12-04 03:33:53+00:00 - - - ZmnSCPxj 2018-12-03 04:16:10+00:00 - - - Bob McElrath 2018-12-02 15:08:39+00:00 - - - Matt Corallo 2018-11-30 19:33:56+00:00 - - - Russell O'Connor 2018-11-30 17:38:04+00:00 - - - Matt Corallo 2018-11-29 19:37:54+00:00 - + 2025-09-26T15:47:53.678698+00:00 + python-feedgen + + + Matt Corallo + 2019-01-07T15:18:00.000Z + + + Rusty Russell + 2019-01-08T05:50:00.000Z + + + Matt Corallo + 2019-01-08T14:46:00.000Z + + + Rusty Russell + 2019-02-13T04:22:00.000Z + + + Johan Torås Halseth + 2019-10-24T13:49:00.000Z + + + Matt Corallo + 2019-10-24T21:25:00.000Z + + + Johan Torås Halseth + 2019-10-25T07:05:00.000Z + + + Matt Corallo + 2019-10-25T17:30:00.000Z + + + Jeremy + 2019-10-27T19:13:00.000Z + + + David A. Harding + 2019-10-27T22:54:00.000Z + + + Johan Torås Halseth + 2019-10-28T09:45:00.000Z + + + David A. Harding + 2019-10-28T17:14:00.000Z + + + Johan Torås Halseth + 2019-10-30T07:22:00.000Z + + @@ -79,13 +77,13 @@ - python-feedgen + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 + 2025-09-26T15:47:53.680259+00:00 - In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly 2019-10-30T07:22:53+00:00 + In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Card-Shuffle-To-Bitcoin-Seed.xml b/static/bitcoin-dev/Feb_2019/combined_Card-Shuffle-To-Bitcoin-Seed.xml index fee6e37a6d..9446b4de4a 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Card-Shuffle-To-Bitcoin-Seed.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Card-Shuffle-To-Bitcoin-Seed.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Card Shuffle To Bitcoin Seed - 2023-08-02T00:27:07.431926+00:00 - - James MacWhyte 2019-02-07 02:42:55+00:00 - - - Alan Evans 2019-02-06 13:51:59+00:00 - - - Alan Evans 2019-02-06 13:48:25+00:00 - - - Devrandom 2019-02-05 01:37:16+00:00 - - - James MacWhyte 2019-02-04 21:05:41+00:00 - - - Adam Ficsor 2019-02-04 06:49:27+00:00 - - - rhavar at protonmail.com 2019-02-02 19:51:59+00:00 - + 2025-09-26T15:47:59.998622+00:00 + python-feedgen + + + [bitcoin-dev] Card Shuffle To Bitcoin Seed rhavar + 2019-02-02T19:51:00.000Z + + + Adam Ficsor + 2019-02-04T06:49:00.000Z + + + James MacWhyte + 2019-02-04T21:05:00.000Z + + + Devrandom + 2019-02-05T01:37:00.000Z + + + Alan Evans + 2019-02-06T13:48:00.000Z + + + Alan Evans + 2019-02-06T13:51:00.000Z + + + James MacWhyte + 2019-02-07T02:42:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Card Shuffle To Bitcoin Seed - 2023-08-02T00:27:07.431926+00:00 + 2025-09-26T15:47:59.999441+00:00 - A discussion on the bitcoin-dev mailing list focused on using shuffled decks of cards as a physical backup for private keys. Devrandom suggested using 50+ 6-sided dice rolls to obtain around 128 bits of entropy, while Alan Evans pointed out that simply using SHA512 was not enough and highlighted a condition where the master key would be invalid if IL is 0 or ≥n. Evans also suggested creating a scheme that takes Cards -> Entropy so that both BIP39 and non-BIP39 fans can generate and store their root xprv.Prior art was mentioned in Ian Coleman's BIP39 site, which already supports cards and dice and can calculate the Total Bits of Entropy. The site can handle card replacement and multiple decks, addressing some of the concerns raised in the discussion. Additionally, James MacWhyte suggested drawing a diagonal line on the side of the deck from corner to corner to ensure the order of the shuffled deck remains intact.In summary, the discussion highlighted the limitations of using SHA512 alone for generating a secure master key and suggested a scheme that takes cards and generates entropy. Ian Coleman's BIP39 site was referenced as an example that supports this approach. A suggestion was made to use 50+ 6-sided dice rolls for additional entropy. Finally, a tip was provided on how to prevent the order of shuffled cards from being mixed up by drawing a diagonal line on the side of the deck. 2019-02-07T02:42:55+00:00 + A discussion on the bitcoin-dev mailing list focused on using shuffled decks of cards as a physical backup for private keys. Devrandom suggested using 50+ 6-sided dice rolls to obtain around 128 bits of entropy, while Alan Evans pointed out that simply using SHA512 was not enough and highlighted a condition where the master key would be invalid if IL is 0 or ≥n. Evans also suggested creating a scheme that takes Cards -> Entropy so that both BIP39 and non-BIP39 fans can generate and store their root xprv.Prior art was mentioned in Ian Coleman's BIP39 site, which already supports cards and dice and can calculate the Total Bits of Entropy. The site can handle card replacement and multiple decks, addressing some of the concerns raised in the discussion. Additionally, James MacWhyte suggested drawing a diagonal line on the side of the deck from corner to corner to ensure the order of the shuffled deck remains intact.In summary, the discussion highlighted the limitations of using SHA512 alone for generating a secure master key and suggested a scheme that takes cards and generates entropy. Ian Coleman's BIP39 site was referenced as an example that supports this approach. A suggestion was made to use 50+ 6-sided dice rolls for additional entropy. Finally, a tip was provided on how to prevent the order of shuffled cards from being mixed up by drawing a diagonal line on the side of the deck. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Fortune-Cookies-to-Bitcoin-Seed.xml b/static/bitcoin-dev/Feb_2019/combined_Fortune-Cookies-to-Bitcoin-Seed.xml index 5dfb74250d..8a47d53238 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Fortune-Cookies-to-Bitcoin-Seed.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Fortune-Cookies-to-Bitcoin-Seed.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Fortune Cookies to Bitcoin Seed - 2023-08-02T00:32:53.894879+00:00 - - Trey Del Bonis 2019-03-06 01:37:35+00:00 - - - James MacWhyte 2019-03-06 01:05:54+00:00 - - - Trey Del Bonis 2019-02-28 03:48:57+00:00 - + 2025-09-26T15:48:16.759849+00:00 + python-feedgen + + + [bitcoin-dev] Fortune Cookies to Bitcoin Seed Trey Del Bonis + 2019-02-28T03:48:00.000Z + + + James MacWhyte + 2019-03-06T01:05:00.000Z + + + Trey Del Bonis + 2019-03-06T01:37:00.000Z + + - python-feedgen + 2 Combined summary - Fortune Cookies to Bitcoin Seed - 2023-08-02T00:32:53.894879+00:00 + 2025-09-26T15:48:16.760460+00:00 - A member of the bitcoin-dev community proposed a method of generating wallets using a list of 20 Chinese take-out menu items as seed phrases. However, another member pointed out that this method lacks sufficient security, providing only 77 bits of entropy and being vulnerable to brute force attacks within a few hours. They recommended using a BIP-39 seed phrase or incorporating additional secret phrases for greater entropy. Moreover, it was noted that some vendors print only 35 different combinations of Chinese food items, further reducing the security of this approach. The original poster acknowledged that their idea was merely for amusement and lacked practical applicability.In an email thread discussing Bitcoin development, Trey Del Bonis suggested that having 20 paper wallets might be excessive, although it would yield a staggering 390700800 possible wallets. Nevertheless, the speed at which mid-level hardware can check addresses (50k per second) means that all possibilities could be explored in just two hours. Consequently, Del Bonis cautioned against considering this method as a challenge for someone who discovers the 20 pieces of paper, assuming they are concealing the wallet. Instead, relying on a strong random number generator (RNG) would offer better entropy than trusting the printing company.Another proposal put forth by a Bitcoin developer involves creating a wallet seed from the numbers found in fortune cookies. Each number is estimated to possess approximately 6.6 bits of entropy, suggesting that around seven fortunes would be sufficient for a "very secure" wallet seed. To enhance security, it is recommended to divide the information between something physical and something memorized, making compromise more difficult. Additionally, this scheme allows for plausible deniability by generating decoy wallets using other fortune numbers. Although a Python script has been created to demonstrate the concept, it should be noted that the idea is still in its early stages, with concerns raised about potential weaknesses, such as individuals discarding their fortunes. 2019-03-06T01:37:35+00:00 + A member of the bitcoin-dev community proposed a method of generating wallets using a list of 20 Chinese take-out menu items as seed phrases. However, another member pointed out that this method lacks sufficient security, providing only 77 bits of entropy and being vulnerable to brute force attacks within a few hours. They recommended using a BIP-39 seed phrase or incorporating additional secret phrases for greater entropy. Moreover, it was noted that some vendors print only 35 different combinations of Chinese food items, further reducing the security of this approach. The original poster acknowledged that their idea was merely for amusement and lacked practical applicability.In an email thread discussing Bitcoin development, Trey Del Bonis suggested that having 20 paper wallets might be excessive, although it would yield a staggering 390700800 possible wallets. Nevertheless, the speed at which mid-level hardware can check addresses (50k per second) means that all possibilities could be explored in just two hours. Consequently, Del Bonis cautioned against considering this method as a challenge for someone who discovers the 20 pieces of paper, assuming they are concealing the wallet. Instead, relying on a strong random number generator (RNG) would offer better entropy than trusting the printing company.Another proposal put forth by a Bitcoin developer involves creating a wallet seed from the numbers found in fortune cookies. Each number is estimated to possess approximately 6.6 bits of entropy, suggesting that around seven fortunes would be sufficient for a "very secure" wallet seed. To enhance security, it is recommended to divide the information between something physical and something memorized, making compromise more difficult. Additionally, this scheme allows for plausible deniability by generating decoy wallets using other fortune numbers. Although a Python script has been created to demonstrate the concept, it should be noted that the idea is still in its early stages, with concerns raised about potential weaknesses, such as individuals discarding their fortunes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Implementing-Confidential-Transactions-in-extension-blocks.xml b/static/bitcoin-dev/Feb_2019/combined_Implementing-Confidential-Transactions-in-extension-blocks.xml index 96233995b1..f2bc83eeab 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Implementing-Confidential-Transactions-in-extension-blocks.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Implementing-Confidential-Transactions-in-extension-blocks.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Implementing Confidential Transactions in extension blocks - 2023-08-02T00:30:10.427557+00:00 - - Hampus Sjöberg 2019-02-14 22:32:17+00:00 - - - Kenshiro [] 2019-02-14 21:14:03+00:00 - - - Trey Del Bonis 2019-02-12 17:27:32+00:00 - - - Kenshiro [] 2019-02-11 10:19:15+00:00 - - - ZmnSCPxj 2019-02-11 04:29:42+00:00 - - - Kenshiro [] 2019-02-08 10:12:06+00:00 - + 2025-09-26T15:47:57.905974+00:00 + python-feedgen + + + [bitcoin-dev] Implementing Confidential Transactions in extension blocks Kenshiro [] + 2019-02-08T10:12:00.000Z + + + ZmnSCPxj + 2019-02-11T04:29:00.000Z + + + Kenshiro [] + 2019-02-11T10:19:00.000Z + + + Trey Del Bonis + 2019-02-12T17:27:00.000Z + + + Kenshiro [] + 2019-02-14T21:14:00.000Z + + + Hampus Sjöberg + 2019-02-14T22:32:00.000Z + + - python-feedgen + 2 Combined summary - Implementing Confidential Transactions in extension blocks - 2023-08-02T00:30:10.427557+00:00 + 2025-09-26T15:47:57.906856+00:00 - The debate surrounding extension blocks and their classification as a soft fork is the central focus of the email thread. Some argue that these blocks hinder older nodes from accurately viewing the Unspent Transaction Output (UTXO) set, forcing them to upgrade and making extension blocks no better than a hard fork. The discussion delves into the specific implementation of Confidential Transactions (CT) within extension blocks, highlighting concerns about the safety of CT and potential future breaches by quantum computing. The suggestion of implementing a globally-verified publicly-visible counter is put forth as a means to prevent inflation in case of such breaches, albeit requiring a hard fork. Additionally, it is noted that while CT transactions increase block capacity, they also result in greater network usage across all fullnodes. The email concludes by emphasizing the need for regular computers to be capable of running full nodes and light wallets to be accessible in developing countries. 2019-02-14T22:32:17+00:00 + The debate surrounding extension blocks and their classification as a soft fork is the central focus of the email thread. Some argue that these blocks hinder older nodes from accurately viewing the Unspent Transaction Output (UTXO) set, forcing them to upgrade and making extension blocks no better than a hard fork. The discussion delves into the specific implementation of Confidential Transactions (CT) within extension blocks, highlighting concerns about the safety of CT and potential future breaches by quantum computing. The suggestion of implementing a globally-verified publicly-visible counter is put forth as a means to prevent inflation in case of such breaches, albeit requiring a hard fork. Additionally, it is noted that while CT transactions increase block capacity, they also result in greater network usage across all fullnodes. The email concludes by emphasizing the need for regular computers to be capable of running full nodes and light wallets to be accessible in developing countries. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Interrogating-a-BIP157-server-BIP158-change-proposal.xml b/static/bitcoin-dev/Feb_2019/combined_Interrogating-a-BIP157-server-BIP158-change-proposal.xml index 9ebbf4e2d1..1943aa448b 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Interrogating-a-BIP157-server-BIP158-change-proposal.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Interrogating-a-BIP157-server-BIP158-change-proposal.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Interrogating a BIP157 server, BIP158 change proposal - 2023-08-02T00:28:46.332040+00:00 - - Dustin Dettmer 2021-10-03 09:53:00+00:00 - - - Pieter Wuille 2019-02-07 20:36:25+00:00 - - - Tamas Blummer 2019-02-06 21:17:17+00:00 - - - Tamas Blummer 2019-02-06 19:48:09+00:00 - - - Gregory Maxwell 2019-02-06 18:17:11+00:00 - - - Tamas Blummer 2019-02-06 08:09:55+00:00 - - - Olaoluwa Osuntokun 2019-02-06 00:17:05+00:00 - - - Olaoluwa Osuntokun 2019-02-06 00:05:57+00:00 - - - Tamas Blummer 2019-02-05 20:10:09+00:00 - - - Matt Corallo 2019-02-05 12:21:45+00:00 - - - Olaoluwa Osuntokun 2019-02-05 01:42:57+00:00 - - - Tamas Blummer 2019-02-04 20:59:44+00:00 - - - Jim Posen 2019-02-04 20:18:08+00:00 - - - Tamas Blummer 2019-02-04 11:41:20+00:00 - + 2025-09-26T15:48:04.199583+00:00 + python-feedgen + + + [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal Tamas Blummer + 2019-02-04T11:41:00.000Z + + + Jim Posen + 2019-02-04T20:18:00.000Z + + + Tamas Blummer + 2019-02-04T20:59:00.000Z + + + Olaoluwa Osuntokun + 2019-02-05T01:42:00.000Z + + + Matt Corallo + 2019-02-05T12:21:00.000Z + + + Tamas Blummer + 2019-02-05T20:10:00.000Z + + + Olaoluwa Osuntokun + 2019-02-06T00:05:00.000Z + + + Olaoluwa Osuntokun + 2019-02-06T00:17:00.000Z + + + Tamas Blummer + 2019-02-06T08:09:00.000Z + + + Gregory Maxwell + 2019-02-06T18:17:00.000Z + + + Tamas Blummer + 2019-02-06T19:48:00.000Z + + + Tamas Blummer + 2019-02-06T21:17:00.000Z + + + Pieter Wuille + 2019-02-07T20:36:00.000Z + + + Dustin Dettmer + 2021-10-03T09:53:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Interrogating a BIP157 server, BIP158 change proposal - 2023-08-02T00:28:46.333042+00:00 + 2025-09-26T15:48:04.201157+00:00 - In a recent email exchange, Tamas Blummer and Olaoluwa Osuntokun discussed the advantages and disadvantages of various Bitcoin block filters. Blummer suggested that moving to a spent outpoint + output script filter would be more secure and allow light clients to perform further probabilistic checks. However, Osuntokun believes it is too late to change the current deployment of the BIPs and instead suggests adding new filter types in the future.Jim Posen also adds to the discussion, proposing three possibilities for improving client protocol given the limitations of the current filter system. Option two, which involves clients tracking multiple possible filter header chains and considering the union of their matches, is favored by Posen due to its simplicity and support from the BIP 157 P2P protocol.Tamas Blummer has suggested a change to BIP158, which would allow for a decision on which filter chain is correct at lower bandwidth usage. He proposes having a basic filter that contains exactly the spent outpoints and the scriptPubKey of each output aside from all OP_RETURN output scripts for each transaction in a block. The client could then download the entire filter of the block and check it entirely against the contents of the same block. If there is a divergence at a checkpoint, the client would request the filter headers between the last matching and first divergent checkpoint to figure out which block's filter is the first that does not match previous assumptions. The client would then download the corresponding block, check that its header fits the PoW secured best header chain, re-calculate merkle root of its transaction list to know that it is complete and query the filter to see if every output script of every transaction is contained in there. If not, the server is lying, and the case is closed, and the server disconnected.In an email exchange between Tamas Blummer and Laolu Osuntokun, Tamas argued that the current design choice of filters limits light clients from proving filter correctness. He suggested a change to BIP158 to use spent outpoints and output scripts instead of input and output scripts, which would allow for filter correctness to be proven by downloading only the block in question. The advantages of this approach include a simpler interrogation process for filter servers and the ability for clients to decide on the availability of spent coins without maintaining the UTXO set. Jim Posen suggested three possibilities to address this issue, including introducing a new P2P message to retrieve all prev-outputs for a given block, tracking multiple possible filter header chains, or committing filters into the chain via witness reserved value or coinbase OP_RETURN. However, option 2 was favored as it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written.In a Bitcoin development thread, Jim Posen proposed a solution to prevent "input script malleability" and restrict what an attacker can do. This involves introducing a new P2P message to retrieve all prev-outputs for a given block, and verifying the scripts against the block by executing them. However, Olaoluwa Osuntokun stated that it is too late in the current deployment of the BIPs to change things around yet again. Instead, he suggests that the BIP already has measures in place for adding new filter types in the future, which may be worthwhile additions. Matt expressed confusion regarding this proposal and its potential effectiveness.A potential change to Bitcoin Improvement Proposal (BIP) 157/158 has been discussed on the Bitcoin-dev mailing list. Tamas Blummer suggests that a filter collecting spent output and output scripts would be more useful than the current design, as it allows for a decision on filter correctness by knowing the block only. This filter is just as useful for wallets as one on spent script since they naturally scan the blockchain forward and learn about their coins by the output script before they need to check spends of those outpoints.Blummer's proposal involves implementing an interrogation by downloading blocks at checkpoints since it is much simpler than following multiple possible filter paths. A spent outpoint filter allows for deciding on coin availability based on immutable store without the updated and eventually rolled back UTXO store. False positives can be sorted out with a block download.On the other hand, Jim Posen suggested three possibilities in this regard. The first involves introducing a new P2P message to retrieve all prev-outputs for a given block and verifying the scripts against the block by executing them. The second includes clients tracking multiple possible filter header chains and considering the union of their matches. If any filter received for a particular block header matches, the client downloads the block. The third possibility involves committing the filters into the chain via witness reserved value or coinbase OP_RETURN and giving up on the pre-softfork BIP 157 P2P mode.The discussion indicates the need for more discussion on the client protocol since clients cannot reliably determine the integrity of a block filter in a bandwidth-efficient manner 2021-10-03T09:53:00+00:00 + In a recent email exchange, Tamas Blummer and Olaoluwa Osuntokun discussed the advantages and disadvantages of various Bitcoin block filters. Blummer suggested that moving to a spent outpoint + output script filter would be more secure and allow light clients to perform further probabilistic checks. However, Osuntokun believes it is too late to change the current deployment of the BIPs and instead suggests adding new filter types in the future.Jim Posen also adds to the discussion, proposing three possibilities for improving client protocol given the limitations of the current filter system. Option two, which involves clients tracking multiple possible filter header chains and considering the union of their matches, is favored by Posen due to its simplicity and support from the BIP 157 P2P protocol.Tamas Blummer has suggested a change to BIP158, which would allow for a decision on which filter chain is correct at lower bandwidth usage. He proposes having a basic filter that contains exactly the spent outpoints and the scriptPubKey of each output aside from all OP_RETURN output scripts for each transaction in a block. The client could then download the entire filter of the block and check it entirely against the contents of the same block. If there is a divergence at a checkpoint, the client would request the filter headers between the last matching and first divergent checkpoint to figure out which block's filter is the first that does not match previous assumptions. The client would then download the corresponding block, check that its header fits the PoW secured best header chain, re-calculate merkle root of its transaction list to know that it is complete and query the filter to see if every output script of every transaction is contained in there. If not, the server is lying, and the case is closed, and the server disconnected.In an email exchange between Tamas Blummer and Laolu Osuntokun, Tamas argued that the current design choice of filters limits light clients from proving filter correctness. He suggested a change to BIP158 to use spent outpoints and output scripts instead of input and output scripts, which would allow for filter correctness to be proven by downloading only the block in question. The advantages of this approach include a simpler interrogation process for filter servers and the ability for clients to decide on the availability of spent coins without maintaining the UTXO set. Jim Posen suggested three possibilities to address this issue, including introducing a new P2P message to retrieve all prev-outputs for a given block, tracking multiple possible filter header chains, or committing filters into the chain via witness reserved value or coinbase OP_RETURN. However, option 2 was favored as it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written.In a Bitcoin development thread, Jim Posen proposed a solution to prevent "input script malleability" and restrict what an attacker can do. This involves introducing a new P2P message to retrieve all prev-outputs for a given block, and verifying the scripts against the block by executing them. However, Olaoluwa Osuntokun stated that it is too late in the current deployment of the BIPs to change things around yet again. Instead, he suggests that the BIP already has measures in place for adding new filter types in the future, which may be worthwhile additions. Matt expressed confusion regarding this proposal and its potential effectiveness.A potential change to Bitcoin Improvement Proposal (BIP) 157/158 has been discussed on the Bitcoin-dev mailing list. Tamas Blummer suggests that a filter collecting spent output and output scripts would be more useful than the current design, as it allows for a decision on filter correctness by knowing the block only. This filter is just as useful for wallets as one on spent script since they naturally scan the blockchain forward and learn about their coins by the output script before they need to check spends of those outpoints.Blummer's proposal involves implementing an interrogation by downloading blocks at checkpoints since it is much simpler than following multiple possible filter paths. A spent outpoint filter allows for deciding on coin availability based on immutable store without the updated and eventually rolled back UTXO store. False positives can be sorted out with a block download.On the other hand, Jim Posen suggested three possibilities in this regard. The first involves introducing a new P2P message to retrieve all prev-outputs for a given block and verifying the scripts against the block by executing them. The second includes clients tracking multiple possible filter header chains and considering the union of their matches. If any filter received for a particular block header matches, the client downloads the block. The third possibility involves committing the filters into the chain via witness reserved value or coinbase OP_RETURN and giving up on the pre-softfork BIP 157 P2P mode.The discussion indicates the need for more discussion on the client protocol since clients cannot reliably determine the integrity of a block filter in a bandwidth-efficient manner - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_NIH-warning-was-Re-BIP-Proposal-Simple-Proof-of-Reserves-Transactions-.xml b/static/bitcoin-dev/Feb_2019/combined_NIH-warning-was-Re-BIP-Proposal-Simple-Proof-of-Reserves-Transactions-.xml index e8456dcd8b..148f123028 100644 --- a/static/bitcoin-dev/Feb_2019/combined_NIH-warning-was-Re-BIP-Proposal-Simple-Proof-of-Reserves-Transactions-.xml +++ b/static/bitcoin-dev/Feb_2019/combined_NIH-warning-was-Re-BIP-Proposal-Simple-Proof-of-Reserves-Transactions-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - NIH warning (was Re: [BIP Proposal] Simple Proof-of-Reserves Transactions) - 2023-08-02T00:30:21.220334+00:00 + 2025-09-26T15:48:23.075383+00:00 + python-feedgen William Casarin 2019-02-17 18:00:32+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - NIH warning (was Re: [BIP Proposal] Simple Proof-of-Reserves Transactions) - 2023-08-02T00:30:21.220334+00:00 + 2025-09-26T15:48:23.075555+00:00 - Developer Pavol Rusnak has praised the use of Protocol Buffers in Trezor, despite the risk of adding an exotic dependency to a software project. He argues that Protocol Buffers are easy to work with and have many interoperable implementations in various languages. However, there are discussions about whether people are moving away from Protocol Buffers in favor of FlatBuffers. Another developer named Will suggests providing custom format to protobuf conversion tools, allowing users who prefer not to include large dependencies to convert it into their preferred format.On 15/02/2019, Luke Dashjr discussed the proposed proof-file format, which aims to provide a standard way to combine multiple proofs and associated metadata. The specification for this format is in Protocol Buffers. Despite some concerns about using Protocol Buffers, Pavol "stick" Rusnak believes that it is not risky because of its interoperable implementations in all possible languages and its ease of use. He compares it to the PSBT format, which was almost as complex as protobuf but proprietary to Bitcoin, hindering adoption. He believes that if Protocol Buffers had been used since the beginning, there would have been much more usage of the PSBT format already. Overall, Protocol Buffers have proven to be a successful choice for Trezor. 2019-02-17T18:00:32+00:00 + Developer Pavol Rusnak has praised the use of Protocol Buffers in Trezor, despite the risk of adding an exotic dependency to a software project. He argues that Protocol Buffers are easy to work with and have many interoperable implementations in various languages. However, there are discussions about whether people are moving away from Protocol Buffers in favor of FlatBuffers. Another developer named Will suggests providing custom format to protobuf conversion tools, allowing users who prefer not to include large dependencies to convert it into their preferred format.On 15/02/2019, Luke Dashjr discussed the proposed proof-file format, which aims to provide a standard way to combine multiple proofs and associated metadata. The specification for this format is in Protocol Buffers. Despite some concerns about using Protocol Buffers, Pavol "stick" Rusnak believes that it is not risky because of its interoperable implementations in all possible languages and its ease of use. He compares it to the PSBT format, which was almost as complex as protobuf but proprietary to Bitcoin, hindering adoption. He believes that if Protocol Buffers had been used since the beginning, there would have been much more usage of the PSBT format already. Overall, Protocol Buffers have proven to be a successful choice for Trezor. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Predicate-Tree-in-ZkVM-a-variant-of-Taproot-G-root.xml b/static/bitcoin-dev/Feb_2019/combined_Predicate-Tree-in-ZkVM-a-variant-of-Taproot-G-root.xml index b6f7a609f9..3da8cc0577 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Predicate-Tree-in-ZkVM-a-variant-of-Taproot-G-root.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Predicate-Tree-in-ZkVM-a-variant-of-Taproot-G-root.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Predicate Tree in ZkVM: a variant of Taproot/G'root - 2023-08-02T00:26:42.501283+00:00 - - Oleg Andreev 2019-02-01 17:56:49+00:00 - - - Oleg Andreev 2019-01-31 23:44:43+00:00 - + 2025-09-26T15:48:14.672053+00:00 + python-feedgen + + + [bitcoin-dev] Predicate Tree in ZkVM: a variant of Taproot/G'root Oleg Andreev + 2019-01-31T23:44:00.000Z + + + Oleg Andreev + 2019-02-01T17:56:00.000Z + + - python-feedgen + 2 Combined summary - Predicate Tree in ZkVM: a variant of Taproot/G'root - 2023-08-02T00:26:42.501283+00:00 + 2025-09-26T15:48:14.672303+00:00 - ZkVM is a blockchain virtual machine that offers multi-asset transfers and zero-knowledge programmable constraints. It introduces the concept of Predicate Trees, which are a variant of Taproot and G'root. The Predicate Tree is represented by a single group element and can be satisfied in multiple ways, unlocking its contents. ZkVM provides four instructions to use the predicate trees: signtx, call, left/right, and delegate.The signtx instruction verifies the signature over the transaction ID, treating the predicate as a public key. The call instruction reveals and executes a pre-arranged program, while the delegate instruction allows choosing the program later, which can be signed with a pre-arranged public key. The left and right instructions replace the contract's predicate with one of the sub-predicates in a disjunction.To optimize performance, ZkVM defers all point operations, including signature checks, disjunction proofs, and program commitment proofs. These deferred operations are verified in a batch after the VM execution is complete, resulting in significant savings. Additionally, ZkVM uses a single aggregated signature for the entire transaction instead of accepting individual signatures.One notable feature of ZkVM is the absence of dynamic branching based on expensive operation outcomes. Signature checks and predicate tree traversals must unconditionally succeed, making program execution (excluding ECC ops) fast and proportional to the program length. This approach provides an accurate measurement of the validation cost based on the collected ECC ops and the constraint system proof blob included with the transaction.It's worth mentioning that the upstream protocol, also known as "blockchain rules," can impose soft or hard caps on program length and the number of ECC operations. This limitation is similar to the restriction on signature checks per block in Bitcoin. Overall, ZkVM offers a powerful and efficient solution for executing transactions with programmable constraints in a blockchain environment. 2019-02-01T17:56:49+00:00 + ZkVM is a blockchain virtual machine that offers multi-asset transfers and zero-knowledge programmable constraints. It introduces the concept of Predicate Trees, which are a variant of Taproot and G'root. The Predicate Tree is represented by a single group element and can be satisfied in multiple ways, unlocking its contents. ZkVM provides four instructions to use the predicate trees: signtx, call, left/right, and delegate.The signtx instruction verifies the signature over the transaction ID, treating the predicate as a public key. The call instruction reveals and executes a pre-arranged program, while the delegate instruction allows choosing the program later, which can be signed with a pre-arranged public key. The left and right instructions replace the contract's predicate with one of the sub-predicates in a disjunction.To optimize performance, ZkVM defers all point operations, including signature checks, disjunction proofs, and program commitment proofs. These deferred operations are verified in a batch after the VM execution is complete, resulting in significant savings. Additionally, ZkVM uses a single aggregated signature for the entire transaction instead of accepting individual signatures.One notable feature of ZkVM is the absence of dynamic branching based on expensive operation outcomes. Signature checks and predicate tree traversals must unconditionally succeed, making program execution (excluding ECC ops) fast and proportional to the program length. This approach provides an accurate measurement of the validation cost based on the collected ECC ops and the constraint system proof blob included with the transaction.It's worth mentioning that the upstream protocol, also known as "blockchain rules," can impose soft or hard caps on program length and the number of ECC operations. This limitation is similar to the restriction on signature checks per block in Bitcoin. Overall, ZkVM offers a powerful and efficient solution for executing transactions with programmable constraints in a blockchain environment. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Privacy-literature-review.xml b/static/bitcoin-dev/Feb_2019/combined_Privacy-literature-review.xml index bc4bfe859a..76291cd276 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Privacy-literature-review.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Privacy-literature-review.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Privacy literature review - 2023-08-02T00:31:34.989521+00:00 - - Adam Ficsor 2019-03-06 14:28:02+00:00 - - - Chris Belcher 2019-02-23 20:17:17+00:00 - + 2025-09-26T15:48:02.087882+00:00 + python-feedgen + + + [bitcoin-dev] Privacy literature review Chris Belcher + 2019-02-23T20:17:00.000Z + + + Adam Ficsor + 2019-03-06T14:28:00.000Z + + - python-feedgen + 2 Combined summary - Privacy literature review - 2023-08-02T00:31:34.989521+00:00 + 2025-09-26T15:48:02.088315+00:00 - Ádám Ficsór, a member of the Bitcoin community, expressed his gratitude for Chris Belcher's work on a comprehensive literature review focused on Bitcoin privacy. This literature review, which can be accessed on the Bitcoin Wiki, covers all aspects of privacy in Bitcoin, including the Lightning network. Notably, it includes practical examples to illustrate the concepts discussed. Belcher has also created a new wiki category that contains smaller articles related to Bitcoin privacy.Ficsór mentioned that he is contributing to the same cause by delivering presentations on the topic. These presentations will eventually become a six-part series, with the first two parts already available. The initial presentation delves into network level privacy, while the second part focuses on blockchain level privacy. Both presentations can be found using the provided links.In conclusion, the author of the email, signed off as "CB," has been diligently working on a literature review regarding Bitcoin privacy. This review comprehensively addresses privacy concerns in Bitcoin, including the Lightning Network, and provides practical examples. Additionally, the author has established a new wiki category for smaller articles related to Bitcoin privacy, further contributing to the community's understanding of this important subject. 2019-03-06T14:28:02+00:00 + Ádám Ficsór, a member of the Bitcoin community, expressed his gratitude for Chris Belcher's work on a comprehensive literature review focused on Bitcoin privacy. This literature review, which can be accessed on the Bitcoin Wiki, covers all aspects of privacy in Bitcoin, including the Lightning network. Notably, it includes practical examples to illustrate the concepts discussed. Belcher has also created a new wiki category that contains smaller articles related to Bitcoin privacy.Ficsór mentioned that he is contributing to the same cause by delivering presentations on the topic. These presentations will eventually become a six-part series, with the first two parts already available. The initial presentation delves into network level privacy, while the second part focuses on blockchain level privacy. Both presentations can be found using the provided links.In conclusion, the author of the email, signed off as "CB," has been diligently working on a literature review regarding Bitcoin privacy. This review comprehensively addresses privacy concerns in Bitcoin, including the Lightning Network, and provides practical examples. Additionally, the author has established a new wiki category for smaller articles related to Bitcoin privacy, further contributing to the community's understanding of this important subject. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Proof-of-Stake-Bitcoin-Sidechains.xml b/static/bitcoin-dev/Feb_2019/combined_Proof-of-Stake-Bitcoin-Sidechains.xml index ca651c5c4a..5927059f87 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Proof-of-Stake-Bitcoin-Sidechains.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Proof-of-Stake-Bitcoin-Sidechains.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Proof-of-Stake Bitcoin Sidechains - 2023-08-02T00:24:58.034506+00:00 - - ZmnSCPxj 2019-02-01 09:19:00+00:00 - - - ZmnSCPxj 2019-01-25 05:33:37+00:00 - - - Peter Todd 2019-01-25 00:16:30+00:00 - - - Matt Bell 2019-01-24 18:46:11+00:00 - - - ZmnSCPxj 2019-01-24 10:03:25+00:00 - - - Dr Adam Back 2019-01-22 20:22:36+00:00 - - - Dustin Dettmer 2019-01-22 20:03:06+00:00 - - - Dustin Dettmer 2019-01-22 16:33:23+00:00 - - - Satoshin 2019-01-22 14:58:25+00:00 - - - ZmnSCPxj 2019-01-22 09:19:27+00:00 - - - Matt Bell 2019-01-21 18:47:13+00:00 - - - ZmnSCPxj 2019-01-20 02:06:08+00:00 - - - Matt Bell 2019-01-19 05:35:43+00:00 - - - ZmnSCPxj 2019-01-19 01:42:47+00:00 - - - Matt Bell 2019-01-18 22:59:35+00:00 - + 2025-09-26T15:48:12.583096+00:00 + python-feedgen + + + [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains Matt Bell + 2019-01-18T22:59:00.000Z + + + ZmnSCPxj + 2019-01-19T01:42:00.000Z + + + Matt Bell + 2019-01-19T05:35:00.000Z + + + ZmnSCPxj + 2019-01-20T02:06:00.000Z + + + Matt Bell + 2019-01-21T18:47:00.000Z + + + ZmnSCPxj + 2019-01-22T09:19:00.000Z + + + Satoshin + 2019-01-22T14:58:00.000Z + + + Dustin Dettmer + 2019-01-22T16:33:00.000Z + + + Dustin Dettmer + 2019-01-22T20:03:00.000Z + + + Dr Adam Back + 2019-01-22T20:22:00.000Z + + + ZmnSCPxj + 2019-01-24T10:03:00.000Z + + + Matt Bell + 2019-01-24T18:46:00.000Z + + + Peter Todd + 2019-01-25T00:16:00.000Z + + + ZmnSCPxj + 2019-01-25T05:33:00.000Z + + + ZmnSCPxj + 2019-02-01T09:19:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Proof-of-Stake Bitcoin Sidechains - 2023-08-02T00:24:58.034506+00:00 + 2025-09-26T15:48:12.584789+00:00 - In a recent discussion on the bitcoin-dev mailing list, ZmnSCPxj proposed a design for a proof-of-mainstake sidechain without any modifications to the Bitcoin mainchain. The writer suggests embedding sidechain block headers on the mainchain by spending the previous transaction, requiring authorization from the sufficient signatory set of stakers. Mainchain-to-sidechain requests are defined as indications that a mainchain coin owner wants to stake or transfer coins to the sidechain. The sidechain-to-mainchain withdrawals are left up to the sidechain to define.The writer also discusses the possibility of a revealed private key for time-locked funds creating a race to spend and suggests that races could be won by bidding up fees if Bitcoin had implemented RBF properly. The context further explores the security features of staking in sidechains, where miners can claim the stake themselves due to the public knowledge of the private key. However, it becomes unlikely for the staker to win unless they possess significant mining hash power. The integrity of the sidechain is proportional to the attacker's share of the Bitcoin hashrate. The storage of Bitcoin moved to the sidechain can be stolen if 67% of the stakers collude.A discussion on the bitcoin-dev mailing list suggests using fixed R values derived through standard hierarchical derivation to prevent multiple signatures in Bitcoin sidechains. The staking pubkey would be revealed as `staking_pubkey = P + hash(P || parent_R) * G`, with the specific R value obtained from hierarchical derivation using parent_R and the blockheight as an index. The potential downsides and impact on blockweight are still unclear.In a separate thread, the discussion focuses on Matt Bell's design for Bitcoin sidechains using the Tendermint BFT consensus protocol. The design is similar to Blockstream's Liquid sidechain and seeks feedback from the community. The source of voting power for the sidechain network is a topic of debate, with suggestions including time-locked Bitcoin and UTXOs on the Bitcoin blockchain. ZmnSCPxj proposes using fixed R values to prevent multiple signatures and introduces the concept of "mainstake," where UTXOs on the Bitcoin blockchain are used as the source of stake for voting power.In an email sent to Matt Bell via Bitcoin-dev, ZmnSCPxj proposed an idea called "mainstake," which involves using UTXOs on the Bitcoin blockchain as stakes for voting power. This approach is seen as more secure than having a blockchain with its own token that is self-attesting. The same script proposed by Bell for sidechains could be used for mainstake. Bell, who has been working on a design for Bitcoin sidechains using the Tendermint BFT consensus protocol, welcomes feedback about improvements or critical flaws in his design. The Tendermint consensus is commonly used to build proof-of-stake networks and is similar to Blockstream's Liquid sidechain, known for its "strong federation" consensus.The sidechain network may accept potential stakers on the mainchain if they prove the existence of a mainchain transaction. The value of this output would then be used as the weight of the vote of that stake. The designer acknowledges that there may be an issue with the fact that the Bitcoin itself is not slashable, but their voting power is. However, their UTXO can be blacklisted, making their attack costly as they lose out on the time-value of their stake.While the current thinking for the source of stake is to pay out stake to Bitcoin merged-miners, the designer is interested in exploring the idea of using time-locked Bitcoin as stake. The GitHub repository contains a simplified implementation of this sidechain design. For further details and a comprehensive understanding of the design, please refer to the design document available at https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md. 2019-02-01T09:19:00+00:00 + In a recent discussion on the bitcoin-dev mailing list, ZmnSCPxj proposed a design for a proof-of-mainstake sidechain without any modifications to the Bitcoin mainchain. The writer suggests embedding sidechain block headers on the mainchain by spending the previous transaction, requiring authorization from the sufficient signatory set of stakers. Mainchain-to-sidechain requests are defined as indications that a mainchain coin owner wants to stake or transfer coins to the sidechain. The sidechain-to-mainchain withdrawals are left up to the sidechain to define.The writer also discusses the possibility of a revealed private key for time-locked funds creating a race to spend and suggests that races could be won by bidding up fees if Bitcoin had implemented RBF properly. The context further explores the security features of staking in sidechains, where miners can claim the stake themselves due to the public knowledge of the private key. However, it becomes unlikely for the staker to win unless they possess significant mining hash power. The integrity of the sidechain is proportional to the attacker's share of the Bitcoin hashrate. The storage of Bitcoin moved to the sidechain can be stolen if 67% of the stakers collude.A discussion on the bitcoin-dev mailing list suggests using fixed R values derived through standard hierarchical derivation to prevent multiple signatures in Bitcoin sidechains. The staking pubkey would be revealed as `staking_pubkey = P + hash(P || parent_R) * G`, with the specific R value obtained from hierarchical derivation using parent_R and the blockheight as an index. The potential downsides and impact on blockweight are still unclear.In a separate thread, the discussion focuses on Matt Bell's design for Bitcoin sidechains using the Tendermint BFT consensus protocol. The design is similar to Blockstream's Liquid sidechain and seeks feedback from the community. The source of voting power for the sidechain network is a topic of debate, with suggestions including time-locked Bitcoin and UTXOs on the Bitcoin blockchain. ZmnSCPxj proposes using fixed R values to prevent multiple signatures and introduces the concept of "mainstake," where UTXOs on the Bitcoin blockchain are used as the source of stake for voting power.In an email sent to Matt Bell via Bitcoin-dev, ZmnSCPxj proposed an idea called "mainstake," which involves using UTXOs on the Bitcoin blockchain as stakes for voting power. This approach is seen as more secure than having a blockchain with its own token that is self-attesting. The same script proposed by Bell for sidechains could be used for mainstake. Bell, who has been working on a design for Bitcoin sidechains using the Tendermint BFT consensus protocol, welcomes feedback about improvements or critical flaws in his design. The Tendermint consensus is commonly used to build proof-of-stake networks and is similar to Blockstream's Liquid sidechain, known for its "strong federation" consensus.The sidechain network may accept potential stakers on the mainchain if they prove the existence of a mainchain transaction. The value of this output would then be used as the weight of the vote of that stake. The designer acknowledges that there may be an issue with the fact that the Bitcoin itself is not slashable, but their voting power is. However, their UTXO can be blacklisted, making their attack costly as they lose out on the time-value of their stake.While the current thinking for the source of stake is to pay out stake to Bitcoin merged-miners, the designer is interested in exploring the idea of using time-locked Bitcoin as stake. The GitHub repository contains a simplified implementation of this sidechain design. For further details and a comprehensive understanding of the design, please refer to the design document available at https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Safer-NOINPUT-with-output-tagging.xml b/static/bitcoin-dev/Feb_2019/combined_Safer-NOINPUT-with-output-tagging.xml index 1091eec635..ac9f282b0e 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Safer-NOINPUT-with-output-tagging.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Safer-NOINPUT-with-output-tagging.xml @@ -1,95 +1,67 @@ - + 2 Combined summary - Safer NOINPUT with output tagging - 2023-08-02T00:18:41.848463+00:00 - - Johnson Lau 2019-02-19 20:36:51+00:00 - - - Luke Dashjr 2019-02-19 20:24:12+00:00 - - - Johnson Lau 2019-02-19 19:22:07+00:00 - - - Luke Dashjr 2019-02-19 19:04:03+00:00 - - - Anthony Towns 2019-02-10 04:46:30+00:00 - - - Johnson Lau 2019-02-09 17:43:50+00:00 - - - Jonas Nick 2019-02-09 16:54:09+00:00 - - - Jonas Nick 2019-02-09 16:52:07+00:00 - - - Johnson Lau 2019-02-09 16:48:40+00:00 - - - Johnson Lau 2019-02-09 10:15:17+00:00 - - - Alejandro Ranchal Pedrosa 2019-02-09 10:01:20+00:00 - - - Jonas Nick 2019-02-08 19:01:40+00:00 - - - ZmnSCPxj 2019-02-01 09:36:50+00:00 - - - Anthony Towns 2019-01-31 06:04:05+00:00 - - - ZmnSCPxj 2018-12-24 11:47:38+00:00 - - - Johnson Lau 2018-12-22 16:56:29+00:00 - - - ZmnSCPxj 2018-12-22 14:25:16+00:00 - - - Johnson Lau 2018-12-21 16:21:42+00:00 - - - Johnson Lau 2018-12-21 15:37:05+00:00 - - - ZmnSCPxj 2018-12-21 11:40:06+00:00 - - - Christian Decker 2018-12-21 11:15:37+00:00 - - - Johnson Lau 2018-12-20 18:04:37+00:00 - - - Christian Decker 2018-12-20 17:20:54+00:00 - - - Johnson Lau 2018-12-20 11:00:53+00:00 - - - Christian Decker 2018-12-19 22:09:50+00:00 - - - Johnson Lau 2018-12-18 10:48:40+00:00 - - - Johnson Lau 2018-12-17 20:08:55+00:00 - - - Ruben Somsen 2018-12-17 15:48:15+00:00 - - - Johnson Lau 2018-12-13 12:32:44+00:00 - + 2025-09-26T15:47:55.811488+00:00 + python-feedgen + + + Anthony Towns + 2019-01-31T06:04:00.000Z + + + ZmnSCPxj + 2019-02-01T09:36:00.000Z + + + Jonas Nick + 2019-02-08T19:01:00.000Z + + + Alejandro Ranchal Pedrosa + 2019-02-09T10:01:00.000Z + + + Johnson Lau + 2019-02-09T10:15:00.000Z + + + Johnson Lau + 2019-02-09T16:48:00.000Z + + + Jonas Nick + 2019-02-09T16:52:00.000Z + + + Jonas Nick + 2019-02-09T16:54:00.000Z + + + Johnson Lau + 2019-02-09T17:43:00.000Z + + + Anthony Towns + 2019-02-10T04:46:00.000Z + + + Luke Dashjr + 2019-02-19T19:04:00.000Z + + + Johnson Lau + 2019-02-19T19:22:00.000Z + + + Luke Dashjr + 2019-02-19T20:24:00.000Z + + + Johnson Lau + 2019-02-19T20:36:00.000Z + + @@ -119,13 +91,13 @@ - python-feedgen + 2 Combined summary - Safer NOINPUT with output tagging - 2023-08-02T00:18:41.848463+00:00 + 2025-09-26T15:47:55.813183+00:00 - The discussion on the bitcoin-dev mailing list revolves around various aspects of implementing a wallet that prevents address reuse and the compatibility of such a feature with NOINPUT. Johnson Lau suggests that addressing address reuse should be a social agreement between the payer and the payee, as it cannot be banned at the protocol level. He proposes publishing the key after a coin is confirmed as a stronger way to prevent address reuse. Luke Dashjr argues against implementing a nanny in the protocol, stating that it limits developers who want certain features. He also highlights the issue of address reuse rejection when using NOINPUT for everything.The acceptability of address reuse in Bitcoin transactions depends on the contract between the payer and payee and cannot be banned at the protocol level. NOINPUT, which allows multiple transactions to spend the same output, has limitations and risks associated with it. To prevent accidental double payments, Lau suggests tagging outputs to make them spendable with NOINPUT. Two possible ways to tag are discussed: setting a certain bit in the tx version or scriptPubKey. Each method has its advantages and disadvantages. The tradeoff between smart contracts and dumb contracts is also mentioned, with the aim of finding a design that enables desired smart contracts while minimizing misuse risks.The discussion also delves into the compatibility of tagging with multiparty eltoo channels, settlement transactions, and various attack scenarios. Alejandro Ranchal Pedrosa proposes Transaction Fragments as a solution to an eltoo-like protocol that works without going on-chain when participants' actions cannot be predicted in advance. Signature replay risks associated with NOINPUT are addressed, and Lau suggests extending version tagging to enhance NOINPUT safety.Another topic of discussion is the potential impact of tagging on fungibility in multiparty eltoo channels. A solution is proposed where settlement transactions are created with different locktimes, and the branch channel is opened on a tagged output. If cooperative channel closing is desired, it can be done on an untagged output without using NOINPUT to avoid fungibility loss.The bitcoin-dev community plays a vital role in identifying and addressing potential issues related to proposals like NOINPUT and ensuring compatibility between various proposals. The aim is to maintain the stability and security of the Bitcoin network while enabling desired smart contracts and minimizing risks.In a recent email exchange between Christian Decker and Johnson Lau, they discussed the use of OP_CSV (BIP112) in a 2-of-2 branch. It was argued that BIP68 relative locktime is not necessary since both parties need to agree on it. However, with taproot, the use of BIP68 actually saves more than just a few bytes. The conversation also discussed the idea of tagging an output to make it spendable with NOINPUT, which is compatible with eltoo. This would allow for walletless offchain software, where on-chain wallets can directly put their funds into an off-chain system without requiring an on-chain transfer. However, there are concerns regarding address reuse, dual-funding, and the need for a standard way of signing transactions without broadcasting them.The discussion also delved into the process of setting up, updating, and closing a Lightning Network channel using eltoo. This involves creating a setup transaction, followed by update transactions and a settlement transaction. Collaborative close and unilateral close were explained as different scenarios depending on the agreement between parties. The number of transactions involved depends on whether cheating occurs.Johnson Lau further explained the process of setting up and closing a payment channel between two parties using Bitcoin. This involves multiple steps, including creating setup, update, and settlement transactions. The concept of collaborative close and unilateral close was explained, along with the number of transactions involved depending on the scenario.The bitcoin-dev mailing list also discussed the design considerations of a channel setup using BIP118, 143, and 141-P2WSH without taproot. The compatibility of this setup with Statechains was explored, as well as the impact on fungibility if taproot was added. It was clarified that combining the trigger and setup transactions is not currently possible, and the purpose of having separate timeouts would be defeated if they were combined.Concerns were raised about the compatibility of NOINPUT with proposals such as Graftroot and Statechains, as well as the impact on fungibility if Taproot was added to Eltoo. The discussion also explored the use of output tagging and NOINPUT in the context of Eltoo and Statechains. The tradeoff between privacy, complexity, and fungibility was considered.In another email exchange, Johnson Lau discussed the risks of signature replay associated with NOINPUT and proposed a solution of "tagging" outputs that are spendable with NOINPUT. Two possible ways of tagging outputs were mentioned, either by setting a certain bit in the tx version or scriptPubKey. The implications of tagging for fungibility were discussed, along with the advantages and limitations of each tagging method. The philosophy behind output tagging was to avoid using NOINPUT unless absolutely necessary.Overall, the discussions focused on the 2019-02-19T20:36:51+00:00 + The discussion on the bitcoin-dev mailing list revolves around various aspects of implementing a wallet that prevents address reuse and the compatibility of such a feature with NOINPUT. Johnson Lau suggests that addressing address reuse should be a social agreement between the payer and the payee, as it cannot be banned at the protocol level. He proposes publishing the key after a coin is confirmed as a stronger way to prevent address reuse. Luke Dashjr argues against implementing a nanny in the protocol, stating that it limits developers who want certain features. He also highlights the issue of address reuse rejection when using NOINPUT for everything.The acceptability of address reuse in Bitcoin transactions depends on the contract between the payer and payee and cannot be banned at the protocol level. NOINPUT, which allows multiple transactions to spend the same output, has limitations and risks associated with it. To prevent accidental double payments, Lau suggests tagging outputs to make them spendable with NOINPUT. Two possible ways to tag are discussed: setting a certain bit in the tx version or scriptPubKey. Each method has its advantages and disadvantages. The tradeoff between smart contracts and dumb contracts is also mentioned, with the aim of finding a design that enables desired smart contracts while minimizing misuse risks.The discussion also delves into the compatibility of tagging with multiparty eltoo channels, settlement transactions, and various attack scenarios. Alejandro Ranchal Pedrosa proposes Transaction Fragments as a solution to an eltoo-like protocol that works without going on-chain when participants' actions cannot be predicted in advance. Signature replay risks associated with NOINPUT are addressed, and Lau suggests extending version tagging to enhance NOINPUT safety.Another topic of discussion is the potential impact of tagging on fungibility in multiparty eltoo channels. A solution is proposed where settlement transactions are created with different locktimes, and the branch channel is opened on a tagged output. If cooperative channel closing is desired, it can be done on an untagged output without using NOINPUT to avoid fungibility loss.The bitcoin-dev community plays a vital role in identifying and addressing potential issues related to proposals like NOINPUT and ensuring compatibility between various proposals. The aim is to maintain the stability and security of the Bitcoin network while enabling desired smart contracts and minimizing risks.In a recent email exchange between Christian Decker and Johnson Lau, they discussed the use of OP_CSV (BIP112) in a 2-of-2 branch. It was argued that BIP68 relative locktime is not necessary since both parties need to agree on it. However, with taproot, the use of BIP68 actually saves more than just a few bytes. The conversation also discussed the idea of tagging an output to make it spendable with NOINPUT, which is compatible with eltoo. This would allow for walletless offchain software, where on-chain wallets can directly put their funds into an off-chain system without requiring an on-chain transfer. However, there are concerns regarding address reuse, dual-funding, and the need for a standard way of signing transactions without broadcasting them.The discussion also delved into the process of setting up, updating, and closing a Lightning Network channel using eltoo. This involves creating a setup transaction, followed by update transactions and a settlement transaction. Collaborative close and unilateral close were explained as different scenarios depending on the agreement between parties. The number of transactions involved depends on whether cheating occurs.Johnson Lau further explained the process of setting up and closing a payment channel between two parties using Bitcoin. This involves multiple steps, including creating setup, update, and settlement transactions. The concept of collaborative close and unilateral close was explained, along with the number of transactions involved depending on the scenario.The bitcoin-dev mailing list also discussed the design considerations of a channel setup using BIP118, 143, and 141-P2WSH without taproot. The compatibility of this setup with Statechains was explored, as well as the impact on fungibility if taproot was added. It was clarified that combining the trigger and setup transactions is not currently possible, and the purpose of having separate timeouts would be defeated if they were combined.Concerns were raised about the compatibility of NOINPUT with proposals such as Graftroot and Statechains, as well as the impact on fungibility if Taproot was added to Eltoo. The discussion also explored the use of output tagging and NOINPUT in the context of Eltoo and Statechains. The tradeoff between privacy, complexity, and fungibility was considered.In another email exchange, Johnson Lau discussed the risks of signature replay associated with NOINPUT and proposed a solution of "tagging" outputs that are spendable with NOINPUT. Two possible ways of tagging outputs were mentioned, either by setting a certain bit in the tx version or scriptPubKey. The implications of tagging for fungibility were discussed, along with the advantages and limitations of each tagging method. The philosophy behind output tagging was to avoid using NOINPUT unless absolutely necessary.Overall, the discussions focused on the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2019/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml b/static/bitcoin-dev/Feb_2019/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml index 4e8d0ace44..7755542853 100644 --- a/static/bitcoin-dev/Feb_2019/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml +++ b/static/bitcoin-dev/Feb_2019/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml @@ -1,173 +1,15 @@ - + 2 Combined summary - Safer sighashes and more granular SIGHASH_NOINPUT - 2023-08-02T00:02:39.338876+00:00 - - Pieter Wuille 2019-02-09 00:39:54+00:00 - - - Johnson Lau 2018-12-24 21:23:44+00:00 - - - ZmnSCPxj 2018-12-24 12:01:58+00:00 - - - Johnson Lau 2018-12-23 16:33:48+00:00 - - - Anthony Towns 2018-12-23 04:26:59+00:00 - - - Johnson Lau 2018-12-21 18:54:42+00:00 - - - Rusty Russell 2018-12-20 23:17:15+00:00 - - - Johnson Lau 2018-12-20 19:34:38+00:00 - - - Rusty Russell 2018-12-19 00:39:26+00:00 - - - Peter Todd 2018-12-18 04:22:58+00:00 - - - Johnson Lau 2018-12-17 19:08:26+00:00 - - - Rusty Russell 2018-12-17 03:10:42+00:00 - - - Rusty Russell 2018-12-16 06:55:48+00:00 - - - Johnson Lau 2018-12-14 13:55:43+00:00 - - - Anthony Towns 2018-12-14 09:30:02+00:00 - - - Anthony Towns 2018-12-14 00:47:29+00:00 - - - Russell O'Connor 2018-12-13 16:50:10+00:00 - - - Russell O'Connor 2018-12-13 16:34:17+00:00 - - - Russell O'Connor 2018-12-13 16:21:10+00:00 - - - Rusty Russell 2018-12-13 00:37:28+00:00 - - - Anthony Towns 2018-12-13 00:24:38+00:00 - - - Anthony Towns 2018-12-13 00:05:53+00:00 - - - Rusty Russell 2018-12-12 23:49:02+00:00 - - - Johnson Lau 2018-12-12 20:00:50+00:00 - - - Johnson Lau 2018-12-12 19:53:38+00:00 - - - Rusty Russell 2018-12-12 09:42:10+00:00 - - - Russell O'Connor 2018-12-11 22:50:24+00:00 - - - David A. Harding 2018-12-11 17:47:24+00:00 - - - Russell O'Connor 2018-12-11 15:36:59+00:00 - - - David A. Harding 2018-12-09 22:41:57+00:00 - - - Johnson Lau 2018-12-09 19:13:34+00:00 - - - Russell O'Connor 2018-12-06 16:57:09+00:00 - - - Christian Decker 2018-11-29 18:29:10+00:00 - - - Christian Decker 2018-11-29 17:00:09+00:00 - - - Bob McElrath 2018-11-28 14:04:13+00:00 - - - Johnson Lau 2018-11-28 08:40:34+00:00 - - - Johnson Lau 2018-11-28 08:31:48+00:00 - - - Pieter Wuille 2018-11-28 03:41:02+00:00 - - - Bob McElrath 2018-11-28 00:54:16+00:00 - - - Johnson Lau 2018-11-24 08:13:46+00:00 - - - Russell O'Connor 2018-11-23 20:18:13+00:00 - - - Johnson Lau 2018-11-23 10:47:10+00:00 - - - Christian Decker 2018-11-23 09:40:20+00:00 - - - Anthony Towns 2018-11-23 06:04:04+00:00 - - - Anthony Towns 2018-11-23 05:03:30+00:00 - - - Russell O'Connor 2018-11-22 22:10:11+00:00 - - - Johnson Lau 2018-11-22 20:52:54+00:00 - - - Russell O'Connor 2018-11-22 16:23:54+00:00 - - - Johnson Lau 2018-11-22 14:28:35+00:00 - - - Johnson Lau 2018-11-21 17:55:22+00:00 - - - Russell O'Connor 2018-11-21 17:07:30+00:00 - - - Christian Decker 2018-11-21 11:20:44+00:00 - - - Christian Decker 2018-11-21 11:15:44+00:00 - - - Anthony Towns 2018-11-20 20:29:04+00:00 - - - Pieter Wuille 2018-11-19 22:37:57+00:00 - + 2025-09-26T15:48:08.377004+00:00 + python-feedgen + + + Pieter Wuille + 2019-02-09T00:39:00.000Z + + @@ -223,13 +65,13 @@ - python-feedgen + 2 Combined summary - Safer sighashes and more granular SIGHASH_NOINPUT - 2023-08-02T00:02:39.340876+00:00 + 2025-09-26T15:48:08.377380+00:00 - In recent discussions among Bitcoin developers, several proposals and considerations were raised regarding the Bitcoin protocol. Pieter Wuille raised concerns about the reuse of OP_MASK and SIGHASH_NOINPUT, with the latter posing a greater risk. Realistic risks associated with NOINPUT were discussed, and output tagging was suggested as an alternative. A proposed script involving CODESEPARATOR was presented, which could eliminate the need for certain cases under taproot. The use of CODESEPARATOR for Scriptless Script without Schnorr was also mentioned.There were debates on the usefulness of OP_CODESEPARATOR under Taproot. Some argued that committing to the masked script is not necessary if best practices are followed, while others believed that using IF+CODESEP approach could be cheaper for certain scripts. The usability and security of OP_CODESEPARATOR with NOINPUT were questioned, but its usefulness in some cases was acknowledged.The discussions also touched upon witness weight malleability in Bitcoin Script and the proposal to use a 64-byte signature for the default "signing all" sighash. There were concerns about estimating witness weight in multisig cases. The discussion explored the possibility of transforming any script into an equivalent one that avoids witness weight malleability.The role of scriptmask in a taproot world and its tradeoff with security were discussed. Opcodes like IF, NOTIF, VERIFY, DROP, and arithmetic opcodes accepting CScriptNum inputs posed challenges. Suggestions were made to eliminate witness weight malleability in practice through policies and consensus enforcement.The discussions also covered topics such as the implementation of covenants/vaults using NOINPUT, changes to Bitcoin script, the efficiency of the sighash cache, and the removal of OP_CODESEPARATOR.In summary, the discussions revolved around various proposals and considerations related to Bitcoin Script, including mask complexity, witness weight malleability, sighash flags, opcodes, and their impact on security and functionality. The ongoing efforts of the Bitcoin development community to improve the efficiency, security, and flexibility of the Bitcoin protocol were reflected in these discussions.The Bitcoin development community is currently exploring options for replacing OP_CODESEPARATOR, which takes a significant amount of time to execute. One suggestion is to add an internal counter that increments with every control flow operator, allowing signatures to cover the value of this counter or the index of the block within the Bitcoin Script program. The community is open to any solution that can replace the functionality of OP_CODESEPARATOR.Anthony Towns, a member of the Bitcoin development community, has raised concerns about the implementation of NOINPUT in the BIP 118 specification. He suggests that implementing NOINPUT implies the ANYONECANPAY feature, but removing the blanking of the 'hashSequence' field may affect this implication. Christian, another community member, agrees that there may not be a good use case for keeping the number of inputs with NOINPUT.Pieter Wuille, a Bitcoin Core developer, has proposed additions to the sighash for future segwit versions. These additions include committing to the absolute transaction fee and scriptPubKey in addition to the scriptCode. To prevent lying about the type of output being spent, these additions are made optional. Wuille's proposal introduces three new sighash flags: SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK. He also suggests adding a new opcode, OP_MASK, which acts as a NOP during execution.The computation of the sighash would follow the BIP143 method, with modifications based on the presence of the new flags. If SIGHASH_SCRIPTMASK is present, every subsequent opcode/push after an OP_MASK in scriptCode is removed. The scriptPubKey being spent is added to the sighash unless SIGHASH_SCRIPTMASK is set. The transaction fee is added to the sighash unless SIGHASH_NOFEE is set. Additionally, when SIGHASH_NOINPUT is set, hashPrevouts, hashSequence, and outpoint are set to null.Christian expresses concern about introducing a new opcode to mask things in the sighash, but considers it a minor issue. He also notes that Wuille's proposal may address some downsides of BIP118 by committing to the script when possible. Wuille seeks feedback on whether his proposal introduces redundant flexibility or overlooks any obvious use cases.In summary, Pieter Wuille proposes three new sighash flags, namely SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK, along with the addition of a new opcode called OP_MASK. These additions aim to enhance the functionality of the sighash in future segwit versions. The proposal suggests specific modifications to the sighash computation process, including the addition of transaction fee and scriptPubKey commitment. The community is encouraged to provide feedback on these proposals and identify any potential issues or use cases that may have been overlooked. 2019-02-09T00:39:54+00:00 + In recent discussions among Bitcoin developers, several proposals and considerations were raised regarding the Bitcoin protocol. Pieter Wuille raised concerns about the reuse of OP_MASK and SIGHASH_NOINPUT, with the latter posing a greater risk. Realistic risks associated with NOINPUT were discussed, and output tagging was suggested as an alternative. A proposed script involving CODESEPARATOR was presented, which could eliminate the need for certain cases under taproot. The use of CODESEPARATOR for Scriptless Script without Schnorr was also mentioned.There were debates on the usefulness of OP_CODESEPARATOR under Taproot. Some argued that committing to the masked script is not necessary if best practices are followed, while others believed that using IF+CODESEP approach could be cheaper for certain scripts. The usability and security of OP_CODESEPARATOR with NOINPUT were questioned, but its usefulness in some cases was acknowledged.The discussions also touched upon witness weight malleability in Bitcoin Script and the proposal to use a 64-byte signature for the default "signing all" sighash. There were concerns about estimating witness weight in multisig cases. The discussion explored the possibility of transforming any script into an equivalent one that avoids witness weight malleability.The role of scriptmask in a taproot world and its tradeoff with security were discussed. Opcodes like IF, NOTIF, VERIFY, DROP, and arithmetic opcodes accepting CScriptNum inputs posed challenges. Suggestions were made to eliminate witness weight malleability in practice through policies and consensus enforcement.The discussions also covered topics such as the implementation of covenants/vaults using NOINPUT, changes to Bitcoin script, the efficiency of the sighash cache, and the removal of OP_CODESEPARATOR.In summary, the discussions revolved around various proposals and considerations related to Bitcoin Script, including mask complexity, witness weight malleability, sighash flags, opcodes, and their impact on security and functionality. The ongoing efforts of the Bitcoin development community to improve the efficiency, security, and flexibility of the Bitcoin protocol were reflected in these discussions.The Bitcoin development community is currently exploring options for replacing OP_CODESEPARATOR, which takes a significant amount of time to execute. One suggestion is to add an internal counter that increments with every control flow operator, allowing signatures to cover the value of this counter or the index of the block within the Bitcoin Script program. The community is open to any solution that can replace the functionality of OP_CODESEPARATOR.Anthony Towns, a member of the Bitcoin development community, has raised concerns about the implementation of NOINPUT in the BIP 118 specification. He suggests that implementing NOINPUT implies the ANYONECANPAY feature, but removing the blanking of the 'hashSequence' field may affect this implication. Christian, another community member, agrees that there may not be a good use case for keeping the number of inputs with NOINPUT.Pieter Wuille, a Bitcoin Core developer, has proposed additions to the sighash for future segwit versions. These additions include committing to the absolute transaction fee and scriptPubKey in addition to the scriptCode. To prevent lying about the type of output being spent, these additions are made optional. Wuille's proposal introduces three new sighash flags: SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK. He also suggests adding a new opcode, OP_MASK, which acts as a NOP during execution.The computation of the sighash would follow the BIP143 method, with modifications based on the presence of the new flags. If SIGHASH_SCRIPTMASK is present, every subsequent opcode/push after an OP_MASK in scriptCode is removed. The scriptPubKey being spent is added to the sighash unless SIGHASH_SCRIPTMASK is set. The transaction fee is added to the sighash unless SIGHASH_NOFEE is set. Additionally, when SIGHASH_NOINPUT is set, hashPrevouts, hashSequence, and outpoint are set to null.Christian expresses concern about introducing a new opcode to mask things in the sighash, but considers it a minor issue. He also notes that Wuille's proposal may address some downsides of BIP118 by committing to the script when possible. Wuille seeks feedback on whether his proposal introduces redundant flexibility or overlooks any obvious use cases.In summary, Pieter Wuille proposes three new sighash flags, namely SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK, along with the addition of a new opcode called OP_MASK. These additions aim to enhance the functionality of the sighash in future segwit versions. The proposal suggests specific modifications to the sighash computation process, including the addition of transaction fee and scriptPubKey commitment. The community is encouraged to provide feedback on these proposals and identify any potential issues or use cases that may have been overlooked. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_-Annoucement-Discreet-Log-Contract-Protocol-Specification.xml b/static/bitcoin-dev/Feb_2020/combined_-Annoucement-Discreet-Log-Contract-Protocol-Specification.xml index d39ae44d27..3da01844c5 100644 --- a/static/bitcoin-dev/Feb_2020/combined_-Annoucement-Discreet-Log-Contract-Protocol-Specification.xml +++ b/static/bitcoin-dev/Feb_2020/combined_-Annoucement-Discreet-Log-Contract-Protocol-Specification.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - [Annoucement] Discreet Log Contract Protocol Specification - 2023-08-02T01:47:22.313644+00:00 - - Nadav Kohen 2020-02-27 16:17:47+00:00 - - - Lloyd Fournier 2020-01-28 09:28:27+00:00 - - - Chris Stewart 2020-01-13 12:27:34+00:00 - + 2025-09-26T15:51:30.298532+00:00 + python-feedgen + + + [bitcoin-dev] [Annoucement] Discreet Log Contract Protocol Specification Chris Stewart + 2020-01-13T12:27:00.000Z + + + Lloyd Fournier + 2020-01-28T09:28:00.000Z + + + Nadav Kohen + 2020-02-27T16:17:00.000Z + + - python-feedgen + 2 Combined summary - [Annoucement] Discreet Log Contract Protocol Specification - 2023-08-02T01:47:22.313644+00:00 + 2025-09-26T15:51:30.299051+00:00 - Additionally, Suredbits and Crypto Garage have released working code for executing 2-outcome Discreet Log Contracts and provided documentation on how to use it. They have also shared a short blog post containing a video demo of an execution. The team encourages interested individuals to review and contribute to the work-in-progress specification.The team's secondary goal is to ensure that DLCs become widely accepted and standardized tools in the Bitcoin ecosystem. They want to establish DLCs as a commonly used technology by creating a set of agreed-upon standards for funding transactions and closing transactions. This will allow every future Bitcoin-related protocol to have access to a toolbox of standards, making software integration more streamlined and efficient.For those interested in learning more about DLCs, there are several resources available. These include a whitepaper, articles, and research papers that provide in-depth information on the topic. By making DLCs easily accessible through comprehensive resources, the team hopes to foster widespread understanding and adoption of this technology within the Bitcoin community.Overall, Suredbits and Crypto Garage are determined to develop a robust protocol specification for using DLCs in a safe, private, and interoperable manner. They aim to create a common standard for using Bitcoin oracles, while remaining compatible with existing Bitcoin-related protocols. Through their efforts, they hope to establish DLCs as widely accepted and standardized tools in the Bitcoin ecosystem, benefiting developers and users alike. 2020-02-27T16:17:47+00:00 + Additionally, Suredbits and Crypto Garage have released working code for executing 2-outcome Discreet Log Contracts and provided documentation on how to use it. They have also shared a short blog post containing a video demo of an execution. The team encourages interested individuals to review and contribute to the work-in-progress specification.The team's secondary goal is to ensure that DLCs become widely accepted and standardized tools in the Bitcoin ecosystem. They want to establish DLCs as a commonly used technology by creating a set of agreed-upon standards for funding transactions and closing transactions. This will allow every future Bitcoin-related protocol to have access to a toolbox of standards, making software integration more streamlined and efficient.For those interested in learning more about DLCs, there are several resources available. These include a whitepaper, articles, and research papers that provide in-depth information on the topic. By making DLCs easily accessible through comprehensive resources, the team hopes to foster widespread understanding and adoption of this technology within the Bitcoin community.Overall, Suredbits and Crypto Garage are determined to develop a robust protocol specification for using DLCs in a safe, private, and interoperable manner. They aim to create a common standard for using Bitcoin oracles, while remaining compatible with existing Bitcoin-related protocols. Through their efforts, they hope to establish DLCs as widely accepted and standardized tools in the Bitcoin ecosystem, benefiting developers and users alike. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_BIP-340-updates-even-pubkeys-more-secure-nonce-generation.xml b/static/bitcoin-dev/Feb_2020/combined_BIP-340-updates-even-pubkeys-more-secure-nonce-generation.xml index ac27e1d6a4..ff47922439 100644 --- a/static/bitcoin-dev/Feb_2020/combined_BIP-340-updates-even-pubkeys-more-secure-nonce-generation.xml +++ b/static/bitcoin-dev/Feb_2020/combined_BIP-340-updates-even-pubkeys-more-secure-nonce-generation.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP 340 updates: even pubkeys, more secure nonce generation - 2023-08-02T01:51:58.348605+00:00 - - Lloyd Fournier 2020-03-22 05:51:59+00:00 - - - Lloyd Fournier 2020-02-27 04:55:21+00:00 - - - Jonas Nick 2020-02-26 15:34:04+00:00 - - - Lloyd Fournier 2020-02-26 04:20:58+00:00 - - - Pieter Wuille 2020-02-24 04:26:17+00:00 - + 2025-09-26T15:51:11.407380+00:00 + python-feedgen + + + [bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation Pieter Wuille + 2020-02-24T04:26:00.000Z + + + [bitcoin-dev] Fwd: " Russell O'Connor + 2020-02-26T03:26:00.000Z + + + [bitcoin-dev] " Lloyd Fournier + 2020-02-26T04:20:00.000Z + + + Jonas Nick + 2020-02-26T15:34:00.000Z + + + Lloyd Fournier + 2020-02-27T04:55:00.000Z + + + Lloyd Fournier + 2020-03-22T05:51:00.000Z + + - python-feedgen + 2 Combined summary - BIP 340 updates: even pubkeys, more secure nonce generation - 2023-08-02T01:51:58.348605+00:00 + 2025-09-26T15:51:11.408222+00:00 - The bitcoin-dev mailing list has been discussing the need to protect against differential power analysis, which is a method used to extract sensitive information from cryptographic systems by analyzing their power consumption. The traditional method of mixing randomness was found to be vulnerable, so a different approach is now being recommended. This involves completely masking the private key with randomness before continuing. The writer suggests that including this method in the specification would be beneficial. They also raise concerns about the vulnerability of hardware wallets to these attacks during key derivation, as getting side channel information from hashes in nonce derivation means getting it from hashes in HD key derivation as well.In the discussion on BIP 340-342, two changes have been proposed. The first change involves modifying the Y coordinate of 32-byte public keys from implicitly square to implicitly even. This change will make signing slightly faster and verification negligibly slower. Importantly, it simplifies integration with existing key generation infrastructure like BIP32 and PSBT. The second change focuses on more secure nonce generation. It is recommended to include actual signing-time randomness into the nonce generation process to protect against fault injection attacks and differential power analysis. These changes aim to improve the security of the specification while still allowing optimization for use cases. One participant suggests that specifying the most minimal way to produce a signature securely is the most useful thing for the document, while another participant emphasizes the importance of a standard for nonce exfiltration protection and MuSig for compatibility across wallets. To ensure consistent failure of code written for earlier BIP texts, new tagged hash tags have been introduced.Pieter Wuille, a Bitcoin Core developer and co-founder of Blockstream, has made several small changes to BIP 340-342, despite initially stating that no further semantical changes were expected. In the first change, the Y coordinate of 32-byte public keys is changed from implicitly square to implicitly even. This modification improves signing speed, simplifies integration with existing key generation infrastructure, and has minimal impact on verification speed. The second change focuses on more secure nonce generation by including the public key in the process, incorporating actual signing-time randomness, and using a different method of mixing in this randomness to protect against differential power analysis. Additionally, new tagged hash tags have been added to ensure consistent failure of code written for earlier BIP texts.Pieter Wuille's updates to BIP 340-342 proposals aim to improve the security of the specifications. These changes include modifying the Y-coordinate of 32-byte public keys, enhancing nonce generation security, and adjusting tagged hash tags. Most changes are related to more secure nonce generation, with only one change affecting validation rules. The Y coordinate of the internal R point in the signature remains implicitly square. Implementers are encouraged to use precomputed values for public key data and include it in the nonce generation to mitigate the risk of private key leakage. A different method of mixing randomness is used to protect against differential power analysis. The modified tagged hash tags ensure consistent failure of code written for earlier BIP texts. 2020-03-22T05:51:59+00:00 + The bitcoin-dev mailing list has been discussing the need to protect against differential power analysis, which is a method used to extract sensitive information from cryptographic systems by analyzing their power consumption. The traditional method of mixing randomness was found to be vulnerable, so a different approach is now being recommended. This involves completely masking the private key with randomness before continuing. The writer suggests that including this method in the specification would be beneficial. They also raise concerns about the vulnerability of hardware wallets to these attacks during key derivation, as getting side channel information from hashes in nonce derivation means getting it from hashes in HD key derivation as well.In the discussion on BIP 340-342, two changes have been proposed. The first change involves modifying the Y coordinate of 32-byte public keys from implicitly square to implicitly even. This change will make signing slightly faster and verification negligibly slower. Importantly, it simplifies integration with existing key generation infrastructure like BIP32 and PSBT. The second change focuses on more secure nonce generation. It is recommended to include actual signing-time randomness into the nonce generation process to protect against fault injection attacks and differential power analysis. These changes aim to improve the security of the specification while still allowing optimization for use cases. One participant suggests that specifying the most minimal way to produce a signature securely is the most useful thing for the document, while another participant emphasizes the importance of a standard for nonce exfiltration protection and MuSig for compatibility across wallets. To ensure consistent failure of code written for earlier BIP texts, new tagged hash tags have been introduced.Pieter Wuille, a Bitcoin Core developer and co-founder of Blockstream, has made several small changes to BIP 340-342, despite initially stating that no further semantical changes were expected. In the first change, the Y coordinate of 32-byte public keys is changed from implicitly square to implicitly even. This modification improves signing speed, simplifies integration with existing key generation infrastructure, and has minimal impact on verification speed. The second change focuses on more secure nonce generation by including the public key in the process, incorporating actual signing-time randomness, and using a different method of mixing in this randomness to protect against differential power analysis. Additionally, new tagged hash tags have been added to ensure consistent failure of code written for earlier BIP texts.Pieter Wuille's updates to BIP 340-342 proposals aim to improve the security of the specifications. These changes include modifying the Y-coordinate of 32-byte public keys, enhancing nonce generation security, and adjusting tagged hash tags. Most changes are related to more secure nonce generation, with only one change affecting validation rules. The Y coordinate of the internal R point in the signature remains implicitly square. Implementers are encouraged to use precomputed values for public key data and include it in the nonce generation to mitigate the risk of private key leakage. A different method of mixing randomness is used to protect against differential power analysis. The modified tagged hash tags ensure consistent failure of code written for earlier BIP texts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml b/static/bitcoin-dev/Feb_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml index 94e1116eb0..bb10598ec5 100644 --- a/static/bitcoin-dev/Feb_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml +++ b/static/bitcoin-dev/Feb_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml @@ -1,53 +1,55 @@ - + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.880650+00:00 - - Jeremy 2020-09-03 17:47:35+00:00 - - - Jeremy 2020-09-03 17:34:15+00:00 - - - Dmitry Petukhov 2020-09-03 14:42:23+00:00 - - - Dmitry Petukhov 2020-06-08 06:05:45+00:00 - - - Jeremy 2020-06-07 22:45:16+00:00 - - - Joachim Strömbergson 2020-06-07 16:51:10+00:00 - - - ZmnSCPxj 2020-02-15 00:24:37+00:00 - - - Jeremy 2020-02-14 19:16:26+00:00 - - - Dmitry Petukhov 2020-02-14 11:18:26+00:00 - - - Jeremy 2019-12-19 20:08:03+00:00 - - - Jeremy 2019-12-13 23:06:59+00:00 - - - Jeremy 2019-12-11 00:37:59+00:00 - - - Jeremy 2019-11-28 19:59:42+00:00 - - - Russell O'Connor 2019-11-27 21:32:51+00:00 - - - Jeremy 2019-11-26 01:50:40+00:00 - + 2025-09-26T15:51:17.712049+00:00 + python-feedgen + + + Dmitry Petukhov + 2020-02-14T11:18:00.000Z + + + Jeremy + 2020-02-14T19:16:00.000Z + + + ZmnSCPxj + 2020-02-15T00:24:00.000Z + + + Joachim Strömbergson + 2020-06-07T16:51:00.000Z + + + Jeremy + 2020-06-07T22:45:00.000Z + + + Dmitry Petukhov + 2020-06-08T06:05:00.000Z + + + [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation Jeremy + 2020-06-08T06:43:00.000Z + + + Dmitry Petukhov + 2020-06-08T07:15:00.000Z + + + Dmitry Petukhov + 2020-09-03T14:42:00.000Z + + + Jeremy + 2020-09-03T17:34:00.000Z + + + Jeremy + 2020-09-03T17:47:00.000Z + + @@ -63,13 +65,13 @@ - python-feedgen + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.881652+00:00 + 2025-09-26T15:51:17.713074+00:00 - In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast 2020-09-03T17:47:35+00:00 + In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_CTV-through-SIGHASH-flags.xml b/static/bitcoin-dev/Feb_2020/combined_CTV-through-SIGHASH-flags.xml index 4798b4970b..16be9ed820 100644 --- a/static/bitcoin-dev/Feb_2020/combined_CTV-through-SIGHASH-flags.xml +++ b/static/bitcoin-dev/Feb_2020/combined_CTV-through-SIGHASH-flags.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - CTV through SIGHASH flags - 2023-08-02T01:50:00.155787+00:00 - - Jeremy 2020-02-03 08:20:52+00:00 - - - Bob McElrath 2020-02-01 20:39:42+00:00 - + 2025-09-26T15:51:38.686077+00:00 + python-feedgen + + + [bitcoin-dev] CTV through SIGHASH flags Bob McElrath + 2020-02-01T20:39:00.000Z + + + Jeremy + 2020-02-03T08:20:00.000Z + + - python-feedgen + 2 Combined summary - CTV through SIGHASH flags - 2023-08-02T01:50:00.155787+00:00 + 2025-09-26T15:51:38.686539+00:00 - The bitcoin-dev mailing list is currently discussing proposals to change the behavior of OP_CHECKTEMPLATEVERIFY (CTV) and how it should be specified. One proposal suggests that CTV should behave more like CHECKSIG, including a flags byte that specifies what is hashed. Another idea presented is the use of a flag called SIGHASH_NOSIG instead of an actual CheckSig SIGHASH Flag. However, this proposal has been criticized for being ill-advised due to the awkward API it would create and its incompatibility with soft-fork encoding rules.It was also suggested that committing to the input index using a flag instead of CTV may be less flexible. Enabling a flag right away may enable a big footgun right off the bat. NOINPUT as specified in a BIP isn't a great surrogate for CTV because CTV commits to the input index, which prevents half-spend. Committing to the input-index is not a sender policy choice, but a receiver policy choice. CSV is an example where redemption policies are committed to in the output by the sender via the sequence_no field, and then checked with an opcode OP_CSV to enable relative timelocks.The proposal imposes "MUST" conditions on the existence of the covenant itself, as well as the number of inputs and outputs, to prevent txid malleability so that such transactions can be used in offline protocols. Txid non-malleability can be achieved by enforcing that the output must be spent using SIGHASH_ALL instead of committing to the number of inputs separately with a new opcode. The MUST condition also helps with sighash caching for batch validation.The discussion revolves around the use of "MUST" conditions for validity caching, which is not actually helpful in precomputing information before fetching outputs from the database. Input indexes eliminate third-party malleability of input order and prevent half-spend, but there is confusion regarding their usage in transactions.CTV is equivalent to a flag in sequence_no that is logically MUST|ALL|NOSIG|INPUTINDEX and a redeemScript of <>. Lightning-like use cases might put sequence_no flags that are logically MAY|ALL|NOINPUT. OP_CAT already allows similar functionality with SIGHASHes, but it requires careful review due to its surprising functional consequences.The idea of expressing CTV as a sighash type today does not offer any benefits since a future soft fork can make CTV a valid hash in a new language. Instead of cramming logic into flags, it is suggested to construct the digest pattern in script or write an actual language for dealing with sighashes. However, this may lead to quadratic hashing if every output commits to a different complex thing. CTV is fully compatible with context-free validation optimizations, while other approaches may not be.The proposal suggests that OP_CHECKTEMPLATEVERIFY should behave more like CHECKSIG and have a flags byte that specifies what is hashed, unifying the ways a SigHash is computed. The CTV-type functionality using CHECKSIG is achievable with some form of NOINPUT flag. Committing to the number of inputs and outputs makes CTV hashes easier to compute with script, but it requires OP_CAT. However, committing to the input index is a sender-specified-policy choice and can be considered using a flag instead.A new flag SIGHASH_NOSIG might work as an alternative type of CHECKSIG operator or CTV might be renamed to CHECKSIGHASH, appending flag bytes to the hash to be checked. The flags discussed above, NOINPUT, NOSIG, INPUTINDEX are all really sender-policy choices, while SIGHASH flags are redeemer-choice. CSV (CHECKSEQUENCEVERIFY) shows that redemption policies are committed to in the output by the sender via the sequence_no field. As user policy choices, NOINPUT might be considered "MAY" conditions, while covenants are a MUST condition.Txid non-malleability can be achieved by enforcing that the output must be spent using SIGHASH_ALL instead of committing to the number of inputs separately with a new opcode. Assuming a CSV-type mechanism can be devised using sequence_no, CTV is equivalent to a flag in sequence_no that is logically MUST|ALL|NOSIG|INPUTINDEX and a redeemScript of <>. Lightning-like use cases might put sequence_no flags that are logically MAY|ALL|NOINPUT. The other mechanism for sender policy is scriptPubKey, which is heavily restricted by isStandard, but might be another place to specify flags like the above. 2020-02-03T08:20:52+00:00 + The bitcoin-dev mailing list is currently discussing proposals to change the behavior of OP_CHECKTEMPLATEVERIFY (CTV) and how it should be specified. One proposal suggests that CTV should behave more like CHECKSIG, including a flags byte that specifies what is hashed. Another idea presented is the use of a flag called SIGHASH_NOSIG instead of an actual CheckSig SIGHASH Flag. However, this proposal has been criticized for being ill-advised due to the awkward API it would create and its incompatibility with soft-fork encoding rules.It was also suggested that committing to the input index using a flag instead of CTV may be less flexible. Enabling a flag right away may enable a big footgun right off the bat. NOINPUT as specified in a BIP isn't a great surrogate for CTV because CTV commits to the input index, which prevents half-spend. Committing to the input-index is not a sender policy choice, but a receiver policy choice. CSV is an example where redemption policies are committed to in the output by the sender via the sequence_no field, and then checked with an opcode OP_CSV to enable relative timelocks.The proposal imposes "MUST" conditions on the existence of the covenant itself, as well as the number of inputs and outputs, to prevent txid malleability so that such transactions can be used in offline protocols. Txid non-malleability can be achieved by enforcing that the output must be spent using SIGHASH_ALL instead of committing to the number of inputs separately with a new opcode. The MUST condition also helps with sighash caching for batch validation.The discussion revolves around the use of "MUST" conditions for validity caching, which is not actually helpful in precomputing information before fetching outputs from the database. Input indexes eliminate third-party malleability of input order and prevent half-spend, but there is confusion regarding their usage in transactions.CTV is equivalent to a flag in sequence_no that is logically MUST|ALL|NOSIG|INPUTINDEX and a redeemScript of <>. Lightning-like use cases might put sequence_no flags that are logically MAY|ALL|NOINPUT. OP_CAT already allows similar functionality with SIGHASHes, but it requires careful review due to its surprising functional consequences.The idea of expressing CTV as a sighash type today does not offer any benefits since a future soft fork can make CTV a valid hash in a new language. Instead of cramming logic into flags, it is suggested to construct the digest pattern in script or write an actual language for dealing with sighashes. However, this may lead to quadratic hashing if every output commits to a different complex thing. CTV is fully compatible with context-free validation optimizations, while other approaches may not be.The proposal suggests that OP_CHECKTEMPLATEVERIFY should behave more like CHECKSIG and have a flags byte that specifies what is hashed, unifying the ways a SigHash is computed. The CTV-type functionality using CHECKSIG is achievable with some form of NOINPUT flag. Committing to the number of inputs and outputs makes CTV hashes easier to compute with script, but it requires OP_CAT. However, committing to the input index is a sender-specified-policy choice and can be considered using a flag instead.A new flag SIGHASH_NOSIG might work as an alternative type of CHECKSIG operator or CTV might be renamed to CHECKSIGHASH, appending flag bytes to the hash to be checked. The flags discussed above, NOINPUT, NOSIG, INPUTINDEX are all really sender-policy choices, while SIGHASH flags are redeemer-choice. CSV (CHECKSEQUENCEVERIFY) shows that redemption policies are committed to in the output by the sender via the sequence_no field. As user policy choices, NOINPUT might be considered "MAY" conditions, while covenants are a MUST condition.Txid non-malleability can be achieved by enforcing that the output must be spent using SIGHASH_ALL instead of committing to the number of inputs separately with a new opcode. Assuming a CSV-type mechanism can be devised using sequence_no, CTV is equivalent to a flag in sequence_no that is logically MUST|ALL|NOSIG|INPUTINDEX and a redeemScript of <>. Lightning-like use cases might put sequence_no flags that are logically MAY|ALL|NOINPUT. The other mechanism for sender policy is scriptPubKey, which is heavily restricted by isStandard, but might be another place to specify flags like the above. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Characterizing-orphan-transaction-in-the-Bitcoin-network.xml b/static/bitcoin-dev/Feb_2020/combined_Characterizing-orphan-transaction-in-the-Bitcoin-network.xml index da63f4b204..17e08b5d17 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Characterizing-orphan-transaction-in-the-Bitcoin-network.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Characterizing-orphan-transaction-in-the-Bitcoin-network.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Characterizing orphan transaction in the Bitcoin network - 2023-08-02T01:49:23.060727+00:00 - - Matt Corallo 2020-02-03 03:41:21+00:00 - - - Anas 2020-01-31 23:07:26+00:00 - + 2025-09-26T15:51:36.596072+00:00 + python-feedgen + + + [bitcoin-dev] Characterizing orphan transaction in the Bitcoin network Anas + 2020-01-31T23:07:00.000Z + + + Matt Corallo + 2020-02-03T03:41:00.000Z + + - python-feedgen + 2 Combined summary - Characterizing orphan transaction in the Bitcoin network - 2023-08-02T01:49:23.060727+00:00 + 2025-09-26T15:51:36.596536+00:00 - The paper's findings highlight the importance of understanding and reducing the impact of orphan transactions on network throughput. It suggests that increasing the size of the orphan pool can reduce network overhead without adding much performance overhead. This is because orphan transactions tend to have fewer parents with lower fees and larger sizes compared to non-orphan transactions, resulting in a lower transaction fee per byte. The study also notes that the network overhead caused by orphan transactions can be significant, reaching up to 17% when using the default orphan memory pool size. However, this overhead can be made negligible by increasing the pool size to 1000 transactions, without requiring significant computational or memory resources. The email discussing this paper suggests that further discussion on the software-level aspects of Bitcoin Core should take place on Github rather than the current forum. Overall, the discussion sheds light on the characteristics of orphan transactions and emphasizes the need to minimize their impact on network throughput. 2020-02-03T03:41:21+00:00 + The paper's findings highlight the importance of understanding and reducing the impact of orphan transactions on network throughput. It suggests that increasing the size of the orphan pool can reduce network overhead without adding much performance overhead. This is because orphan transactions tend to have fewer parents with lower fees and larger sizes compared to non-orphan transactions, resulting in a lower transaction fee per byte. The study also notes that the network overhead caused by orphan transactions can be significant, reaching up to 17% when using the default orphan memory pool size. However, this overhead can be made negligible by increasing the pool size to 1000 transactions, without requiring significant computational or memory resources. The email discussing this paper suggests that further discussion on the software-level aspects of Bitcoin Core should take place on Github rather than the current forum. Overall, the discussion sheds light on the characteristics of orphan transactions and emphasizes the need to minimize their impact on network throughput. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Composable-MuSig.xml b/static/bitcoin-dev/Feb_2020/combined_Composable-MuSig.xml index bbe7c973a1..41683b5154 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Composable-MuSig.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Composable-MuSig.xml @@ -1,38 +1,27 @@ - + 2 Combined summary - Composable MuSig - 2023-08-02T01:34:08.477767+00:00 - - Tim Ruffing 2020-02-24 16:56:06+00:00 - - - Erik Aronesty 2020-02-24 15:30:54+00:00 - - - Tim Ruffing 2020-02-24 11:16:38+00:00 - - - Erik Aronesty 2020-02-23 07:27:39+00:00 - - - Lloyd Fournier 2019-12-08 06:10:00+00:00 - - - ZmnSCPxj 2019-12-08 01:15:51+00:00 - - - Lloyd Fournier 2019-12-02 03:30:26+00:00 - - - ZmnSCPxj 2019-12-02 02:05:01+00:00 - - - Lloyd Fournier 2019-11-29 05:50:33+00:00 - - - ZmnSCPxj 2019-11-25 11:00:22+00:00 - + 2025-09-26T15:51:24.008544+00:00 + python-feedgen + + + Erik Aronesty + 2020-02-23T07:27:00.000Z + + + Tim Ruffing + 2020-02-24T11:16:00.000Z + + + Erik Aronesty + 2020-02-24T15:30:00.000Z + + + Tim Ruffing + 2020-02-24T16:56:00.000Z + + @@ -43,13 +32,13 @@ - python-feedgen + 2 Combined summary - Composable MuSig - 2023-08-02T01:34:08.477767+00:00 + 2025-09-26T15:51:24.009302+00:00 - The discussion on the bitcoin-dev mailing list focuses on preventing repeated signings of the same message and using a "validity" time window to limit an attacker's control. The Drijvers, et al paper addresses parallel and aborted signings, where ksums can be used. Adding a signature timeout to the message is proposed as a solution, where participants refuse to sign if the time is too far in the future or if a message has been used previously within that time window.There are concerns about the safety of two-phase MuSig, with reference to a paper arguing it may be unsafe due to the number of parallel sessions. It is suggested that using 3-round MuSig could eliminate this issue.The MuSig protocol is discussed, highlighting its vulnerability to attacks when used in compositions. A proposal called Multi-R is introduced to address this problem by allowing participants to submit multiple R commitments. Alternative proposals involving Pedersen or ElGamal commitments are also mentioned but found to have security flaws.A composable commitment scheme appropriate for MuSig R coin tossing is discussed, with the author stating that deeper analysis is needed to determine the requirements of MuSig for the commitment scheme. The author suggests that Schnorr and ECDSA signatures can be viewed as commitment schemes on points and proposes using them as composable commitments in a MuSig scheme.Pedersen commitments are discussed in relation to MuSig R coin tossing, suggesting that using `X` committed with Pedersen commitments in place of `q * G` in an ElGamal commitment can prevent cancellation attacks. However, alternative methods involving Schnorr signatures and using contributions `R[a]` and `R[b]` as public keys are also suggested, albeit with increased complexity.The MuSig composition problem is addressed, emphasizing the need for the three-phase MuSig protocol instead of the potentially unsafe two-phase variant when one participant is an aggregate entity. The potential security issues of the two-phase protocol and the Wagner Generalized Birthday Paradox attack are highlighted. The Multi-R proposal is suggested as a modification to address this vulnerability.The Lightning Nodelets proposal on lightning-dev is discussed, mentioning the use of MuSig on public keys of participants and the need for one or more participants to be an aggregate entity. The MuSig composition problem arises when there is a possibility of participant equality. The three-phase MuSig protocol is described, along with its potential vulnerabilities and proposed solutions such as the Multi-R proposal.Overall, the discussion focuses on addressing the security flaws of the MuSig protocol, proposing various solutions including signature timeouts, multi-round MuSig, composable commitment schemes, and modifications to the protocol structure. 2020-02-24T16:56:06+00:00 + The discussion on the bitcoin-dev mailing list focuses on preventing repeated signings of the same message and using a "validity" time window to limit an attacker's control. The Drijvers, et al paper addresses parallel and aborted signings, where ksums can be used. Adding a signature timeout to the message is proposed as a solution, where participants refuse to sign if the time is too far in the future or if a message has been used previously within that time window.There are concerns about the safety of two-phase MuSig, with reference to a paper arguing it may be unsafe due to the number of parallel sessions. It is suggested that using 3-round MuSig could eliminate this issue.The MuSig protocol is discussed, highlighting its vulnerability to attacks when used in compositions. A proposal called Multi-R is introduced to address this problem by allowing participants to submit multiple R commitments. Alternative proposals involving Pedersen or ElGamal commitments are also mentioned but found to have security flaws.A composable commitment scheme appropriate for MuSig R coin tossing is discussed, with the author stating that deeper analysis is needed to determine the requirements of MuSig for the commitment scheme. The author suggests that Schnorr and ECDSA signatures can be viewed as commitment schemes on points and proposes using them as composable commitments in a MuSig scheme.Pedersen commitments are discussed in relation to MuSig R coin tossing, suggesting that using `X` committed with Pedersen commitments in place of `q * G` in an ElGamal commitment can prevent cancellation attacks. However, alternative methods involving Schnorr signatures and using contributions `R[a]` and `R[b]` as public keys are also suggested, albeit with increased complexity.The MuSig composition problem is addressed, emphasizing the need for the three-phase MuSig protocol instead of the potentially unsafe two-phase variant when one participant is an aggregate entity. The potential security issues of the two-phase protocol and the Wagner Generalized Birthday Paradox attack are highlighted. The Multi-R proposal is suggested as a modification to address this vulnerability.The Lightning Nodelets proposal on lightning-dev is discussed, mentioning the use of MuSig on public keys of participants and the need for one or more participants to be an aggregate entity. The MuSig composition problem arises when there is a possibility of participant equality. The three-phase MuSig protocol is described, along with its potential vulnerabilities and proposed solutions such as the Multi-R proposal.Overall, the discussion focuses on addressing the security flaws of the MuSig protocol, proposing various solutions including signature timeouts, multi-round MuSig, composable commitment schemes, and modifications to the protocol structure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_LN-Coinjoin-a-Great-Tx-Format-Wedding.xml b/static/bitcoin-dev/Feb_2020/combined_LN-Coinjoin-a-Great-Tx-Format-Wedding.xml index abcd0e7802..2724c69398 100644 --- a/static/bitcoin-dev/Feb_2020/combined_LN-Coinjoin-a-Great-Tx-Format-Wedding.xml +++ b/static/bitcoin-dev/Feb_2020/combined_LN-Coinjoin-a-Great-Tx-Format-Wedding.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - LN & Coinjoin, a Great Tx Format Wedding - 2023-08-02T01:51:40.449154+00:00 - - Antoine Riard 2020-02-25 19:16:03+00:00 - - - ZmnSCPxj 2020-02-24 23:35:56+00:00 - - - Antoine Riard 2020-02-24 18:26:52+00:00 - - - Antoine Riard 2020-02-24 17:58:02+00:00 - - - ZmnSCPxj 2020-02-23 01:29:09+00:00 - - - ZmnSCPxj 2020-02-23 00:59:46+00:00 - - - AdamISZ 2020-02-22 12:10:52+00:00 - - - Antoine Riard 2020-02-21 22:17:54+00:00 - + 2025-09-26T15:51:15.594434+00:00 + python-feedgen + + + [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding Antoine Riard + 2020-02-21T22:17:00.000Z + + + AdamISZ + 2020-02-22T12:10:00.000Z + + + ZmnSCPxj + 2020-02-23T00:59:00.000Z + + + ZmnSCPxj + 2020-02-23T01:29:00.000Z + + + Antoine Riard + 2020-02-24T17:58:00.000Z + + + Antoine Riard + 2020-02-24T18:26:00.000Z + + + ZmnSCPxj + 2020-02-24T23:35:00.000Z + + + Antoine Riard + 2020-02-25T19:16:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - LN & Coinjoin, a Great Tx Format Wedding - 2023-08-02T01:51:40.449154+00:00 + 2025-09-26T15:51:15.595394+00:00 - In a recent email exchange between ZmnSCPxj and Antoine, the discussion focused on various topics related to Lightning Network (LN) and Bitcoin. One topic explored was the possibility of splicing as a form of merged closing plus funding, which would require changing the short channel ID and channel ID for compatibility purposes. The conversation also touched on the need for an alias to maintain channel routing-score across splicing. Privacy concerns were raised in relation to Coinjoin traffic, with the suggestion that redirecting it through LN could potentially enhance privacy properties in the future.The controversy surrounding Replace-By-Fee (RBF) was another point of discussion. ZmnSCPxj proposed that RBF should always be turned on, even if there is no facility to re-interact and increase fees. This would force surveillors to record information themselves, although merchants who refuse RBF transactions may complain. Another issue highlighted was the incentive for participants in MuSig to only broadcast the highest-fee version if not all participants contribute equally to fees.The conversation then shifted towards the importance of nailing down details of a format that could be used by other protocols such as submarine swaps and lightning loops. Splicing was further explored as a potential solution to address liquidity reasons in LN nodes and its impact on CoinJoin spending delta versus LN ones.In a separate discussion on the Bitcoin-dev mailing list, Antoine asked how a Bitcoin transaction could leak protocol usage. Several factors were identified, including output type, spending policy, outputs ordering, nLocktime/nSequence, RBF-signaling, equal-value outputs, weird watermark, fees strategy like CPFP, and in-protocol announcements. The utxo selection algorithm and nVersion were also mentioned as possible sources of leakage. CoinJoinXT was suggested as a potential privacy enhancement solution in a Taproot/Schnorr world. It allows participants to arrange the effect of CoinJoin without the on-chain watermark through a short interaction, with multisig requiring Taproot/Schnorr.On the Lightning-dev mailing list, ZmnSCPxj discussed the use of nLocktime and a weird watermark on unilateral closes in LN channels. HTLCs were noted to only exist on unilateral closes, while mutual closes wait for HTLCs to settle before closing. ZmnSCPxj also provided links for further reading on the difficulties with unilateral closes. The post addressed questions about protocol-specific semantic incompatibility between CoinJoin and cooperative LN transactions, RBF-by-default, and artificially increasing the number of outputs to mimic CoinJoin transactions.Furthermore, the issue of coinjoin interceptions and their detection by chain observers was raised. While banning coinjoined coins or any other coins linked through a common owner would undermine long-term fungibility, it was suggested that all on-chain transactions should conform to a common transaction pattern that provides unobservability. The adoption of a common transaction format could help blur multiple protocol on-chain transactions and circumvent potential bans. Questions were posed regarding the compatibility of this format with various protocols, including Coinjoin and cooperative LN transactions, as well as concerns about utxo bloat/fees resulting from artificially increasing the number of outputs to mimic Coinjoin transactions.Overall, the discussions revolved around exploring various aspects of Lightning Network, CoinJoin, privacy enhancement, RBF, splicing, and the need for a common transaction format to enhance unobservability. 2020-02-25T19:16:03+00:00 + In a recent email exchange between ZmnSCPxj and Antoine, the discussion focused on various topics related to Lightning Network (LN) and Bitcoin. One topic explored was the possibility of splicing as a form of merged closing plus funding, which would require changing the short channel ID and channel ID for compatibility purposes. The conversation also touched on the need for an alias to maintain channel routing-score across splicing. Privacy concerns were raised in relation to Coinjoin traffic, with the suggestion that redirecting it through LN could potentially enhance privacy properties in the future.The controversy surrounding Replace-By-Fee (RBF) was another point of discussion. ZmnSCPxj proposed that RBF should always be turned on, even if there is no facility to re-interact and increase fees. This would force surveillors to record information themselves, although merchants who refuse RBF transactions may complain. Another issue highlighted was the incentive for participants in MuSig to only broadcast the highest-fee version if not all participants contribute equally to fees.The conversation then shifted towards the importance of nailing down details of a format that could be used by other protocols such as submarine swaps and lightning loops. Splicing was further explored as a potential solution to address liquidity reasons in LN nodes and its impact on CoinJoin spending delta versus LN ones.In a separate discussion on the Bitcoin-dev mailing list, Antoine asked how a Bitcoin transaction could leak protocol usage. Several factors were identified, including output type, spending policy, outputs ordering, nLocktime/nSequence, RBF-signaling, equal-value outputs, weird watermark, fees strategy like CPFP, and in-protocol announcements. The utxo selection algorithm and nVersion were also mentioned as possible sources of leakage. CoinJoinXT was suggested as a potential privacy enhancement solution in a Taproot/Schnorr world. It allows participants to arrange the effect of CoinJoin without the on-chain watermark through a short interaction, with multisig requiring Taproot/Schnorr.On the Lightning-dev mailing list, ZmnSCPxj discussed the use of nLocktime and a weird watermark on unilateral closes in LN channels. HTLCs were noted to only exist on unilateral closes, while mutual closes wait for HTLCs to settle before closing. ZmnSCPxj also provided links for further reading on the difficulties with unilateral closes. The post addressed questions about protocol-specific semantic incompatibility between CoinJoin and cooperative LN transactions, RBF-by-default, and artificially increasing the number of outputs to mimic CoinJoin transactions.Furthermore, the issue of coinjoin interceptions and their detection by chain observers was raised. While banning coinjoined coins or any other coins linked through a common owner would undermine long-term fungibility, it was suggested that all on-chain transactions should conform to a common transaction pattern that provides unobservability. The adoption of a common transaction format could help blur multiple protocol on-chain transactions and circumvent potential bans. Questions were posed regarding the compatibility of this format with various protocols, including Coinjoin and cooperative LN transactions, as well as concerns about utxo bloat/fees resulting from artificially increasing the number of outputs to mimic Coinjoin transactions.Overall, the discussions revolved around exploring various aspects of Lightning Network, CoinJoin, privacy enhancement, RBF, splicing, and the need for a common transaction format to enhance unobservability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Non-equal-value-CoinJoins-Opinions-.xml b/static/bitcoin-dev/Feb_2020/combined_Non-equal-value-CoinJoins-Opinions-.xml index 3bed67e26f..7824a62476 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Non-equal-value-CoinJoins-Opinions-.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Non-equal-value-CoinJoins-Opinions-.xml @@ -1,35 +1,15 @@ - + 2 Combined summary - Non-equal value CoinJoins. Opinions. - 2023-08-02T01:43:31.866332+00:00 - - nopara73 2020-02-22 18:01:14+00:00 - - - Lucas Ontivero 2019-12-30 01:14:19+00:00 - - - Yuval Kogman 2019-12-29 17:48:38+00:00 - - - ZmnSCPxj 2019-12-29 10:23:39+00:00 - - - Yuval Kogman 2019-12-29 09:57:48+00:00 - - - Yuval Kogman 2019-12-29 03:31:48+00:00 - - - ZmnSCPxj 2019-12-28 23:25:07+00:00 - - - Ethan Heilman 2019-12-28 17:38:11+00:00 - - - nopara73 2019-12-27 18:03:49+00:00 - + 2025-09-26T15:51:26.095780+00:00 + python-feedgen + + + nopara73 + 2020-02-22T18:01:00.000Z + + @@ -39,13 +19,13 @@ - python-feedgen + 2 Combined summary - Non-equal value CoinJoins. Opinions. - 2023-08-02T01:43:31.866332+00:00 + 2025-09-26T15:51:26.096171+00:00 - In a recent email conversation between Ádám Ficsór and ZmnSCPxj, the topic of non-equal value CoinJoins and their privacy implications was discussed. The conversation focused on a paragraph from the CashFusion specification that claimed there is essentially no linkage with 10^92 possibilities. However, ZmnSCPxj argued that most users would not have the same output value of "around 1 BTC" in a real live mainnet scenario. He suggested that if the math requires equal-valued outputs per user, it would be more practical to use equal-valued CoinJoins. ZmnSCPxj also pointed out that change outputs in equal-valued CoinJoins have similar linkability to CashFusion outputs. The CashFusion research proposes a combinatorial approach to avoid amount linkages in non-equal value CoinJoins, but ZmnSCPxj argues that it is not as effective as equal-outputs transactions. The Knapsack paper in 2017 also had a similar idea, splitting original outputs into partitions that match selected groups of outputs. However, the simulation showed exponential growth in the number of valid transactions, making it impossible to determine the real ones. Additionally, there are concerns about the effectiveness and security of this mechanism. In contrast, Knapsack provides a general solution with good mathematical backing and has been backtested against historical data from Bitcoin's blockchain. Overall, Knapsack is currently considered the best solution for unequal inputs/outputs CoinJoins.The limitations of CoinJoin and ZeroLink protocols in terms of preventing linkage between pre- and post-mix coins were discussed in the email thread. The author proposed a new protocol that introduces chaumian reissuable/redenominatable tokens as an intermediary stage between input/output phases. This allows for unequal amounts while retaining the advantages of fixed denominations. The protocol includes several subtypes of mixing rounds and suggests subsidizing mining fees and batching to preserve exact denomination sizes. The author also mentions the possibility of keeping low hamming weight outputs virtual to make the approach size-efficient, but further exploration is needed.Another email conversation between Yuval and ZmnSCPxj focused on privacy issues related to CoinJoin transactions. They discussed broader criticisms of CoinJoin-based privacy and the assertion of 0 linkability. ZmnSCPxj expressed concern about perspectives that analyze linkability information in isolation, as the post/pre mix transaction graph presents a more complex problem. They mentioned ZeroLink protocol as a solution, but noted that it is not purely implemented in Wasabi and still has some privacy concerns. Equal-valued CoinJoins were suggested as a solution with a Chaumian bank constraining value transfers. CashFusion was also discussed, but there are doubts about its privacy guarantees and the involvement of a server.In an email exchange, Yuval Kogman made a mistake in his calculation regarding the number of inputs and indistinguishable outputs. He later corrected himself, stating that n is actually the smaller of the two numbers. While this correction did not affect his arguments, it was important to clarify the mistake.In a bitcoin-dev email thread, nopara73 responded to a document about CoinJoin-based privacy called "The Breaking of Mixing Secrets". They questioned the premises and implications of the document, highlighting the potential efficiency of computational strategies in deanonymization. Nopara73 also expressed concerns about analyzing linkability information in isolation and mentioned Cash Fusion's extension of obfuscation by allowing multiple inputs and outputs. They cautiously mentioned the potential of small popcounts/Hamming weights and the use of OP_CHECKTEMPLATEVERIFY and Taproot to mitigate overhead. Doubts were raised about the proof and its applicability due to trust in servers and a dubious hardness assumption.CashFusion is a privacy-enhancing technique developed by the Bitcoin Cash community. It claims that non-equal value CoinJoins can be relied on for privacy. The research highlights the large number of ways to partition inputs into sets, making it hard to track transactions. The Cash Fusion scheme allows players to bring many inputs and outputs, further extending obfuscation. However, equal-valued CoinJoins offer unlinked equal-valued outputs, making them a viable alternative if the math requires such outputs. CashFusion involves a single UTXO value, while equal-valued CoinJoin has zero linkability between inputs and outputs.In summary, CashFusion is a privacy-focused approach for Bitcoin Cash transactions that offers obfuscation through combinatorial techniques. However, there are potential attacks and limitations that need to be addressed. Knapsack is considered the best solution for unequal inputs/outputs CoinJoins, while equal-valued CoinJoins provide unlinked equal-valued outputs. Privacy concerns related to CoinJoin transactions still need to be addressed, and there are doubts about the proof and its applicability. Further exploration of design spaces and protocols is needed to improve privacy in CoinJoin transactions 2020-02-22T18:01:14+00:00 + In a recent email conversation between Ádám Ficsór and ZmnSCPxj, the topic of non-equal value CoinJoins and their privacy implications was discussed. The conversation focused on a paragraph from the CashFusion specification that claimed there is essentially no linkage with 10^92 possibilities. However, ZmnSCPxj argued that most users would not have the same output value of "around 1 BTC" in a real live mainnet scenario. He suggested that if the math requires equal-valued outputs per user, it would be more practical to use equal-valued CoinJoins. ZmnSCPxj also pointed out that change outputs in equal-valued CoinJoins have similar linkability to CashFusion outputs. The CashFusion research proposes a combinatorial approach to avoid amount linkages in non-equal value CoinJoins, but ZmnSCPxj argues that it is not as effective as equal-outputs transactions. The Knapsack paper in 2017 also had a similar idea, splitting original outputs into partitions that match selected groups of outputs. However, the simulation showed exponential growth in the number of valid transactions, making it impossible to determine the real ones. Additionally, there are concerns about the effectiveness and security of this mechanism. In contrast, Knapsack provides a general solution with good mathematical backing and has been backtested against historical data from Bitcoin's blockchain. Overall, Knapsack is currently considered the best solution for unequal inputs/outputs CoinJoins.The limitations of CoinJoin and ZeroLink protocols in terms of preventing linkage between pre- and post-mix coins were discussed in the email thread. The author proposed a new protocol that introduces chaumian reissuable/redenominatable tokens as an intermediary stage between input/output phases. This allows for unequal amounts while retaining the advantages of fixed denominations. The protocol includes several subtypes of mixing rounds and suggests subsidizing mining fees and batching to preserve exact denomination sizes. The author also mentions the possibility of keeping low hamming weight outputs virtual to make the approach size-efficient, but further exploration is needed.Another email conversation between Yuval and ZmnSCPxj focused on privacy issues related to CoinJoin transactions. They discussed broader criticisms of CoinJoin-based privacy and the assertion of 0 linkability. ZmnSCPxj expressed concern about perspectives that analyze linkability information in isolation, as the post/pre mix transaction graph presents a more complex problem. They mentioned ZeroLink protocol as a solution, but noted that it is not purely implemented in Wasabi and still has some privacy concerns. Equal-valued CoinJoins were suggested as a solution with a Chaumian bank constraining value transfers. CashFusion was also discussed, but there are doubts about its privacy guarantees and the involvement of a server.In an email exchange, Yuval Kogman made a mistake in his calculation regarding the number of inputs and indistinguishable outputs. He later corrected himself, stating that n is actually the smaller of the two numbers. While this correction did not affect his arguments, it was important to clarify the mistake.In a bitcoin-dev email thread, nopara73 responded to a document about CoinJoin-based privacy called "The Breaking of Mixing Secrets". They questioned the premises and implications of the document, highlighting the potential efficiency of computational strategies in deanonymization. Nopara73 also expressed concerns about analyzing linkability information in isolation and mentioned Cash Fusion's extension of obfuscation by allowing multiple inputs and outputs. They cautiously mentioned the potential of small popcounts/Hamming weights and the use of OP_CHECKTEMPLATEVERIFY and Taproot to mitigate overhead. Doubts were raised about the proof and its applicability due to trust in servers and a dubious hardness assumption.CashFusion is a privacy-enhancing technique developed by the Bitcoin Cash community. It claims that non-equal value CoinJoins can be relied on for privacy. The research highlights the large number of ways to partition inputs into sets, making it hard to track transactions. The Cash Fusion scheme allows players to bring many inputs and outputs, further extending obfuscation. However, equal-valued CoinJoins offer unlinked equal-valued outputs, making them a viable alternative if the math requires such outputs. CashFusion involves a single UTXO value, while equal-valued CoinJoin has zero linkability between inputs and outputs.In summary, CashFusion is a privacy-focused approach for Bitcoin Cash transactions that offers obfuscation through combinatorial techniques. However, there are potential attacks and limitations that need to be addressed. Knapsack is considered the best solution for unequal inputs/outputs CoinJoins, while equal-valued CoinJoins provide unlinked equal-valued outputs. Privacy concerns related to CoinJoin transactions still need to be addressed, and there are doubts about the proof and its applicability. Further exploration of design spaces and protocols is needed to improve privacy in CoinJoin transactions - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml b/static/bitcoin-dev/Feb_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml index 3a0ba17942..113c7c139e 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Nonce blinding protocol for hardware wallets and airgapped signers - 2023-08-02T01:53:12.423124+00:00 + 2025-09-26T15:51:09.317089+00:00 + python-feedgen Dustin Dettmer 2020-03-02 20:01:51+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Nonce blinding protocol for hardware wallets and airgapped signers - 2023-08-02T01:53:12.424131+00:00 + 2025-09-26T15:51:09.317226+00:00 - Stepan Snigirev has proposed a protocol for signing messages using an air-gapped computer or hardware wallet in the Bitcoin development mailing list. This comes in response to the acknowledgment that these devices can be compromised through supply chain attacks or malicious firmware updates. The proposed protocol aims to reduce the attack surface by involving additional entropy from the host. The protocol requires the host to pick a random number `n` and send its hash along with the message `m` to the signer. The signer calculates a nonce `k` and sends the corresponding point `R=kG` to the host, committing to the chosen nonce. The preimage `n` is then sent to the signer, who tweaks the nonce by this number and signs the message. The signed message is sent back to the host, who verifies that the public point in the signature is tweaked by `n`.Extensions to the protocol are also suggested by Snigirev. One extension involves the use of multiple hosts, where all hosts don't trust each other and the signer. In this case, hosts can concatenate hashes and preimages to add external entropy to the nonce. Another extension involves the use of a stateless random signer. If the signer wants to generate a nonce non-deterministically but doesn't have the ability to store it, they can send back meta-information to the host that would help regenerate the same nonce later.The proposed protocol can be implemented for PSBT using key-value pairs added to BIP-174. These include keys such as {PSBT_IN_EXT_NONCE_HASH}|{pubkey} for sha256(n1)|sha256(n2)|..., {PSBT_IN_NONCE_COMMITMENT}|{pubkey} for the 33-byte R point, {PSBT_IN_NONCE_SIGNER_METADATA}|{pubkey} for any value, and {PSBT_IN_EXT_NONCE_PREIMAGE}|{pubkey} for n1|n2|....Marko expresses gratitude for the implementation of a protocol for PSBT anti-nonce covert channel and backports the scheme to ECDSA in the secp256k1 library. He suggests using the generalized sign-to-contract scheme in PSBT, where the final nonce is computed as `k' = k + H(k*G, n)` instead of `k'=k+n`. Proprietary fields or key-value pairs can be added to BIP-174 depending on the interest of others. Careful verification against the state stored by the host for the PSBT is necessary to avoid implementation mistakes and private key leakage.The writer appreciates the initiative of implementing and releasing a protocol inspired by a blog post. The protocol was implemented in the secp256k1 library for Schnorr sigs and backported to ECDSA for current transactions. Proof of concepts were made to verify its effectiveness. The generalized sign-to-contract scheme was used in these implementations, with the final nonce computed as `k' = k + H(k*G, n)`. However, caution is advised when implementing the protocol with an air-gapped signer, as wrong implementation could lead to private key leaks. Guidelines and best practices to avoid pitfalls are requested.When generating a digital signature, it is unsafe to use only the message and private key. Instead, all data from the host should be used to create a nonce. Multiple blinding factors can also be used. If completely random nonces cannot be gathered due to insufficient entropy, any available source of entropy can be mixed into the nonce generation function. Glitch attacks, where two identical messages produce different signatures due to a flipped bit in the message, can be prevented by including a monotonic counter in the nonce generation function. The Yubikey had a problem with RNG initialization that caused private key leakage, so it's recommended to avoid pure RNG-generated nonces.The compromise of hardware wallets and air-gapped computers is discussed, highlighting the risks of supply chain attacks and malicious firmware updates. The proposed protocol aims to address these concerns by involving additional entropy from the host in the signing process. It is noted that using a deterministic scheme with only the message and privkey would be unsafe in certain scenarios. To prevent targeted attacks, it's recommended to derive the nonce from the message, `sha256(n)`, and the privkey mixed together using a suitable hashing function. While completely random nonces are ideal, resource limitations may prevent their use.Stepan Snigirev proposes a protocol to prevent the compromise of hardware wallets or air-gapped computers used for signing transactions. The protocol involves the host picking a random number and sending its hash along with the message to the signer, who computes a nonce and commits to it by sending the corresponding point to the host. The preimage is then sent back to the signer, who tweaks the nonce and signs the message. The host verifies that the public point in the signature is tweaked by the same amount. If the signer wants to generate a nonce non-determin 2020-03-02T20:01:51+00:00 + Stepan Snigirev has proposed a protocol for signing messages using an air-gapped computer or hardware wallet in the Bitcoin development mailing list. This comes in response to the acknowledgment that these devices can be compromised through supply chain attacks or malicious firmware updates. The proposed protocol aims to reduce the attack surface by involving additional entropy from the host. The protocol requires the host to pick a random number `n` and send its hash along with the message `m` to the signer. The signer calculates a nonce `k` and sends the corresponding point `R=kG` to the host, committing to the chosen nonce. The preimage `n` is then sent to the signer, who tweaks the nonce by this number and signs the message. The signed message is sent back to the host, who verifies that the public point in the signature is tweaked by `n`.Extensions to the protocol are also suggested by Snigirev. One extension involves the use of multiple hosts, where all hosts don't trust each other and the signer. In this case, hosts can concatenate hashes and preimages to add external entropy to the nonce. Another extension involves the use of a stateless random signer. If the signer wants to generate a nonce non-deterministically but doesn't have the ability to store it, they can send back meta-information to the host that would help regenerate the same nonce later.The proposed protocol can be implemented for PSBT using key-value pairs added to BIP-174. These include keys such as {PSBT_IN_EXT_NONCE_HASH}|{pubkey} for sha256(n1)|sha256(n2)|..., {PSBT_IN_NONCE_COMMITMENT}|{pubkey} for the 33-byte R point, {PSBT_IN_NONCE_SIGNER_METADATA}|{pubkey} for any value, and {PSBT_IN_EXT_NONCE_PREIMAGE}|{pubkey} for n1|n2|....Marko expresses gratitude for the implementation of a protocol for PSBT anti-nonce covert channel and backports the scheme to ECDSA in the secp256k1 library. He suggests using the generalized sign-to-contract scheme in PSBT, where the final nonce is computed as `k' = k + H(k*G, n)` instead of `k'=k+n`. Proprietary fields or key-value pairs can be added to BIP-174 depending on the interest of others. Careful verification against the state stored by the host for the PSBT is necessary to avoid implementation mistakes and private key leakage.The writer appreciates the initiative of implementing and releasing a protocol inspired by a blog post. The protocol was implemented in the secp256k1 library for Schnorr sigs and backported to ECDSA for current transactions. Proof of concepts were made to verify its effectiveness. The generalized sign-to-contract scheme was used in these implementations, with the final nonce computed as `k' = k + H(k*G, n)`. However, caution is advised when implementing the protocol with an air-gapped signer, as wrong implementation could lead to private key leaks. Guidelines and best practices to avoid pitfalls are requested.When generating a digital signature, it is unsafe to use only the message and private key. Instead, all data from the host should be used to create a nonce. Multiple blinding factors can also be used. If completely random nonces cannot be gathered due to insufficient entropy, any available source of entropy can be mixed into the nonce generation function. Glitch attacks, where two identical messages produce different signatures due to a flipped bit in the message, can be prevented by including a monotonic counter in the nonce generation function. The Yubikey had a problem with RNG initialization that caused private key leakage, so it's recommended to avoid pure RNG-generated nonces.The compromise of hardware wallets and air-gapped computers is discussed, highlighting the risks of supply chain attacks and malicious firmware updates. The proposed protocol aims to address these concerns by involving additional entropy from the host in the signing process. It is noted that using a deterministic scheme with only the message and privkey would be unsafe in certain scenarios. To prevent targeted attacks, it's recommended to derive the nonce from the message, `sha256(n)`, and the privkey mixed together using a suitable hashing function. While completely random nonces are ideal, resource limitations may prevent their use.Stepan Snigirev proposes a protocol to prevent the compromise of hardware wallets or air-gapped computers used for signing transactions. The protocol involves the host picking a random number and sending its hash along with the message to the signer, who computes a nonce and commits to it by sending the corresponding point to the host. The preimage is then sent back to the signer, who tweaks the nonce and signs the message. The host verifies that the public point in the signature is tweaked by the same amount. If the signer wants to generate a nonce non-determin - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Onchain-fee-insurance-mechanism.xml b/static/bitcoin-dev/Feb_2020/combined_Onchain-fee-insurance-mechanism.xml index 38a94bf149..bbdea2e4d5 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Onchain-fee-insurance-mechanism.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Onchain-fee-insurance-mechanism.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Onchain fee insurance mechanism - 2023-08-02T01:48:36.073775+00:00 - - ZmnSCPxj 2020-02-01 00:39:36+00:00 - - - David A. Harding 2020-01-31 21:01:29+00:00 - - - ZmnSCPxj 2020-01-31 03:42:08+00:00 - + 2025-09-26T15:51:32.389193+00:00 + python-feedgen + + + [bitcoin-dev] Onchain fee insurance mechanism ZmnSCPxj + 2020-01-31T03:42:00.000Z + + + David A. Harding + 2020-01-31T21:01:00.000Z + + + ZmnSCPxj + 2020-02-01T00:39:00.000Z + + - python-feedgen + 2 Combined summary - Onchain fee insurance mechanism - 2023-08-02T01:48:36.073775+00:00 + 2025-09-26T15:51:32.389777+00:00 - In an email conversation between ZmnSCPxj and David on Bitcoin development, a mechanism for feerate insurance against onchain feerate spikes is proposed. The proposal involves Alice and Ingrid arranging a series of transactions with a specific locktime and sequence. However, the plan has a flaw as Ingrid can rescind the pre-signed transactions before confirmation by double spending her UTXO via an RBF fee bump.To address this issue, a patch is suggested that allows the Ingrid-input to be under the control of both Ingrid and Alice using a 2-of-2 mechanism. However, this solution leads to new problems of denial of service. Another possible insurance policy is proposed for Lightning channel closures. In this scenario, Alice prepays Ingrid using a CoinJoined transaction for the combined premium plus Ingrid inputs value locked to Alice && Ingrid. At each commitment transaction signing, there is an additional unencumbered tiny output that Alice can claim immediately. To ensure flexibility in closing the channel, Ingrid and Alice create an insurance transaction with high feerate that spends the tiny output and the Alice&&Ingrid output. The fees are deducted from the Alice&&Ingrid output, and the remaining amount is returned to Ingrid. If fees are low at the time of unilateral close, Alice can claim the tiny output itself. However, if fees are high, Alice sacrifices the tiny output and attaches the insurance transaction with a high feerate.If Ingrid does not cooperate on a new commitment transaction, Alice can drop onchain and punish Ingrid by dropping the previous commitment and broadcasting the insurance transaction. The upper bound for what Alice will pay to ensure its channel is closeable at any time quickly is the entire point of this proposal.In a Bitcoin development discussion, ZmnSCPxj proposes a mechanism for feerate insurance against on-chain feerate spikes. The proposed mechanism involves a series of transactions with RBF enabled and no relative locktime at the current block height. Alice and Ingrid arrange inputs and outputs with Bob, Alice, and Ingrid as recipients. However, if Alice needs to trust Ingrid anyway, they might as well use an external accounting and payment mechanism.During LNConf 2019, Jack Mallers presented a proposal for creating a futures market on onchain feerates. This would create an insurance policy against increases in feerate by having miners take short positions on fees while users take long positions on fees. This mechanism is necessary to have a smooth experience interfacing between onchain and offchain transactions.Overall, the proposal aims to create a smoother experience when transferring funds between onchain and offchain, providing feerate insurance and addressing issues related to confirmation timings and fee spikes. 2020-02-01T00:39:36+00:00 + In an email conversation between ZmnSCPxj and David on Bitcoin development, a mechanism for feerate insurance against onchain feerate spikes is proposed. The proposal involves Alice and Ingrid arranging a series of transactions with a specific locktime and sequence. However, the plan has a flaw as Ingrid can rescind the pre-signed transactions before confirmation by double spending her UTXO via an RBF fee bump.To address this issue, a patch is suggested that allows the Ingrid-input to be under the control of both Ingrid and Alice using a 2-of-2 mechanism. However, this solution leads to new problems of denial of service. Another possible insurance policy is proposed for Lightning channel closures. In this scenario, Alice prepays Ingrid using a CoinJoined transaction for the combined premium plus Ingrid inputs value locked to Alice && Ingrid. At each commitment transaction signing, there is an additional unencumbered tiny output that Alice can claim immediately. To ensure flexibility in closing the channel, Ingrid and Alice create an insurance transaction with high feerate that spends the tiny output and the Alice&&Ingrid output. The fees are deducted from the Alice&&Ingrid output, and the remaining amount is returned to Ingrid. If fees are low at the time of unilateral close, Alice can claim the tiny output itself. However, if fees are high, Alice sacrifices the tiny output and attaches the insurance transaction with a high feerate.If Ingrid does not cooperate on a new commitment transaction, Alice can drop onchain and punish Ingrid by dropping the previous commitment and broadcasting the insurance transaction. The upper bound for what Alice will pay to ensure its channel is closeable at any time quickly is the entire point of this proposal.In a Bitcoin development discussion, ZmnSCPxj proposes a mechanism for feerate insurance against on-chain feerate spikes. The proposed mechanism involves a series of transactions with RBF enabled and no relative locktime at the current block height. Alice and Ingrid arrange inputs and outputs with Bob, Alice, and Ingrid as recipients. However, if Alice needs to trust Ingrid anyway, they might as well use an external accounting and payment mechanism.During LNConf 2019, Jack Mallers presented a proposal for creating a futures market on onchain feerates. This would create an insurance policy against increases in feerate by having miners take short positions on fees while users take long positions on fees. This mechanism is necessary to have a smooth experience interfacing between onchain and offchain transactions.Overall, the proposal aims to create a smoother experience when transferring funds between onchain and offchain, providing feerate insurance and addressing issues related to confirmation timings and fee spikes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Purge-attacks-spin-on-sabotage-attacks-.xml b/static/bitcoin-dev/Feb_2020/combined_Purge-attacks-spin-on-sabotage-attacks-.xml index caeea25859..348ee2992d 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Purge-attacks-spin-on-sabotage-attacks-.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Purge-attacks-spin-on-sabotage-attacks-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Purge attacks (spin on sabotage attacks) - 2023-08-02T01:49:03.631211+00:00 - - Mike Kelly 2020-02-10 15:28:20+00:00 - - - ZmnSCPxj 2020-02-09 23:59:56+00:00 - - - Mike Kelly 2020-02-09 10:15:18+00:00 - - - ZmnSCPxj 2020-02-09 00:00:41+00:00 - - - Mike Kelly 2020-02-08 08:11:17+00:00 - - - ZmnSCPxj 2020-02-08 02:15:32+00:00 - - - Mike Kelly 2020-02-07 13:55:29+00:00 - - - ha su 2020-01-31 13:38:22+00:00 - + 2025-09-26T15:51:19.804157+00:00 + python-feedgen + + + [bitcoin-dev] Purge attacks (spin on sabotage attacks) ha su + 2020-01-31T13:38:00.000Z + + + Mike Kelly + 2020-02-07T13:55:00.000Z + + + ZmnSCPxj + 2020-02-08T02:15:00.000Z + + + Mike Kelly + 2020-02-08T08:11:00.000Z + + + ZmnSCPxj + 2020-02-09T00:00:00.000Z + + + Mike Kelly + 2020-02-09T10:15:00.000Z + + + ZmnSCPxj + 2020-02-09T23:59:00.000Z + + + Mike Kelly + 2020-02-10T15:28:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Purge attacks (spin on sabotage attacks) - 2023-08-02T01:49:03.631211+00:00 + 2025-09-26T15:51:19.805192+00:00 - The conversation focuses on the concept of Purge attacks, a form of sabotage attack in Bitcoin. Purge attacks involve replacing recent blocks with empty blocks, causing previously confirmed transactions to return to the mempool. This allows individuals to double-spend their transactions back to themselves. The goal of this attack is to undermine trust in Bitcoin's assurances and disrupt coordination among users.ZmnSCPxj argues that violating the principle of Blockchain Self-Containment, which ensures consensus rules only check what is in the blockchain, can lead to persistent chainsplits, even with innocent miners finding blocks at the same time. M suggests discouraging miners from including conflicting transactions but acknowledges that it may require making consensus dependent on the state of the mempool, potentially leading to chainsplits.The conversation also touches on other topics such as defending against purge attacks by offering increased mining fees for censored transactions and the use of replace by fee (RBF) in opportunistic attacks. ZmnSCPxj warns that defending against RBF-based attacks is not a winning game. The discussion then shifts to the potential risks posed by G20 states seizing major mining operations and how limiting RBF options could force them to resort to denial-of-service (DoS) mode.Overall, the conversation highlights the potential consequences of Purge attacks and the challenges in preventing them. It emphasizes the need for coordination among users and the importance of maintaining the censorship-resistance and integrity of Bitcoin. The full report on mitigations against sabotage attacks can be found at https://blog.deribit.com/insights/destabilizing-bitcoin-consensus-with-purge-attacks/. Feedback on the issue is welcomed. 2020-02-10T15:28:20+00:00 + The conversation focuses on the concept of Purge attacks, a form of sabotage attack in Bitcoin. Purge attacks involve replacing recent blocks with empty blocks, causing previously confirmed transactions to return to the mempool. This allows individuals to double-spend their transactions back to themselves. The goal of this attack is to undermine trust in Bitcoin's assurances and disrupt coordination among users.ZmnSCPxj argues that violating the principle of Blockchain Self-Containment, which ensures consensus rules only check what is in the blockchain, can lead to persistent chainsplits, even with innocent miners finding blocks at the same time. M suggests discouraging miners from including conflicting transactions but acknowledges that it may require making consensus dependent on the state of the mempool, potentially leading to chainsplits.The conversation also touches on other topics such as defending against purge attacks by offering increased mining fees for censored transactions and the use of replace by fee (RBF) in opportunistic attacks. ZmnSCPxj warns that defending against RBF-based attacks is not a winning game. The discussion then shifts to the potential risks posed by G20 states seizing major mining operations and how limiting RBF options could force them to resort to denial-of-service (DoS) mode.Overall, the conversation highlights the potential consequences of Purge attacks and the challenges in preventing them. It emphasizes the need for coordination among users and the importance of maintaining the censorship-resistance and integrity of Bitcoin. The full report on mitigations against sabotage attacks can be found at https://blog.deribit.com/insights/destabilizing-bitcoin-consensus-with-purge-attacks/. Feedback on the issue is welcomed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Removing-Single-Point-of-Failure-with-Seed-Phrase-Storage.xml b/static/bitcoin-dev/Feb_2020/combined_Removing-Single-Point-of-Failure-with-Seed-Phrase-Storage.xml index 8f24739f91..275fa09e5a 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Removing-Single-Point-of-Failure-with-Seed-Phrase-Storage.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Removing-Single-Point-of-Failure-with-Seed-Phrase-Storage.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Removing Single Point of Failure with Seed Phrase Storage - 2023-08-02T01:52:24.038046+00:00 - - Russell O'Connor 2020-03-06 11:11:11+00:00 - - - ZmnSCPxj 2020-02-28 13:10:27+00:00 - - - Christopher Allen 2020-02-26 20:26:44+00:00 - - - Jeremy 2020-02-26 19:56:09+00:00 - - - Contact Team 2020-02-26 13:02:20+00:00 - + 2025-09-26T15:51:13.500848+00:00 + python-feedgen + + + [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage Contact Team + 2020-02-26T13:02:00.000Z + + + Jeremy + 2020-02-26T19:56:00.000Z + + + Christopher Allen + 2020-02-26T20:26:00.000Z + + + ZmnSCPxj + 2020-02-28T13:10:00.000Z + + + Russell O'Connor + 2020-03-06T11:11:00.000Z + + + [bitcoin-dev] On the compatibility of Bech32 and Shamir's Secret Sharing Russell O'Connor + 2020-08-03T22:49:00.000Z + + - python-feedgen + 2 Combined summary - Removing Single Point of Failure with Seed Phrase Storage - 2023-08-02T01:52:24.038046+00:00 + 2025-09-26T15:51:13.501576+00:00 - The email thread discusses the benefits and issues with using Shamir's Secret Sharing as a replacement for paper. A concept has been proposed for creating secret shares using paper computers, which splits a secret encoded in the Bech32 alphabet into 2-of-n shares. However, there are still more issues that need to be addressed before using it for valuable data. The proposed method is experimental and has only been tested with a 10-character "secret" data. It generates shares easily but recovering the secret data is more work. The error correcting code should contain an error correcting code for robust recovery. While this scheme may be workable for some, it requires manual computation, which may lead to errors.The limitations of Shamir split backups are discussed, mentioning that the key can exist plaintext on a device at some point. Non-interactive multisig is suggested as a better solution as it allows signing transactions without having keys in the same room/place/device ever. However, Shamir split backups still have a place in operational security scenarios. The best C-library for Shamir sharding of recovery seeds is available at the Blockchain Commons Github but needs refactoring to be a good standalone library. Air-gapped open-source open hardware for seed creations and Shamir restoration is also being worked on. Verifiable Secret Sharing (VSS) is considered better than Shamir Secret Sharing for seed sharding in the long-term. Bitcoin multisig transactions are recommended as the best solution for self-sovereign recovery of funds. The SmartCustody book offers current best practices for single seed recovery and is now working on v2 of the book, which will cover multisign and fiduciary scenarios.Seed phrase security is a topic of ongoing discussion, with different opinions and security models used by individuals. Paper or metal engraving options are commonly used but act as a single point of failure. Hardware wallets, even those using a secure element, can still be vulnerable to hacking. The Cypherock X1 Wallet offers a potential solution by using Shamir Secret Sharing to split the seed phrase into four different shares, each stored in a PIN-protected card with a secure element. Any two of these four cards are needed to recover the seed or make a transaction, reducing the risk of losing the seed phrase. The storage and computation aspects of this hardware wallet are decoupled, providing added security through distribution. However, Shamir's shares have the issue that the key does exist plaintext on a device at some point. Non-interactive multisig provides an alternative benefit by allowing transactions to be signed without having keys in the same room/place/device ever. Feedback from the community is welcomed regarding the Cypherock X1 Wallet. 2020-03-06T11:11:11+00:00 + The email thread discusses the benefits and issues with using Shamir's Secret Sharing as a replacement for paper. A concept has been proposed for creating secret shares using paper computers, which splits a secret encoded in the Bech32 alphabet into 2-of-n shares. However, there are still more issues that need to be addressed before using it for valuable data. The proposed method is experimental and has only been tested with a 10-character "secret" data. It generates shares easily but recovering the secret data is more work. The error correcting code should contain an error correcting code for robust recovery. While this scheme may be workable for some, it requires manual computation, which may lead to errors.The limitations of Shamir split backups are discussed, mentioning that the key can exist plaintext on a device at some point. Non-interactive multisig is suggested as a better solution as it allows signing transactions without having keys in the same room/place/device ever. However, Shamir split backups still have a place in operational security scenarios. The best C-library for Shamir sharding of recovery seeds is available at the Blockchain Commons Github but needs refactoring to be a good standalone library. Air-gapped open-source open hardware for seed creations and Shamir restoration is also being worked on. Verifiable Secret Sharing (VSS) is considered better than Shamir Secret Sharing for seed sharding in the long-term. Bitcoin multisig transactions are recommended as the best solution for self-sovereign recovery of funds. The SmartCustody book offers current best practices for single seed recovery and is now working on v2 of the book, which will cover multisign and fiduciary scenarios.Seed phrase security is a topic of ongoing discussion, with different opinions and security models used by individuals. Paper or metal engraving options are commonly used but act as a single point of failure. Hardware wallets, even those using a secure element, can still be vulnerable to hacking. The Cypherock X1 Wallet offers a potential solution by using Shamir Secret Sharing to split the seed phrase into four different shares, each stored in a PIN-protected card with a secure element. Any two of these four cards are needed to recover the seed or make a transaction, reducing the risk of losing the seed phrase. The storage and computation aspects of this hardware wallet are decoupled, providing added security through distribution. However, Shamir's shares have the issue that the key does exist plaintext on a device at some point. Non-interactive multisig provides an alternative benefit by allowing transactions to be signed without having keys in the same room/place/device ever. Feedback from the community is welcomed regarding the Cypherock X1 Wallet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity-reflowed-.xml b/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity-reflowed-.xml index 7497467847..901d4576a5 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity-reflowed-.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity-reflowed-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Taproot (and graftroot) complexity (reflowed) - 2023-08-02T01:51:20.884258+00:00 + 2025-09-26T15:51:34.508695+00:00 + python-feedgen Pieter Wuille 2020-02-18 23:29:21+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Taproot (and graftroot) complexity (reflowed) - 2023-08-02T01:51:20.884258+00:00 + 2025-09-26T15:51:34.508859+00:00 - Pieter Wuille emphasized the significance of Taproot in incentivizing protocols and implementations that utilize the key path, maximizing privacy and appealing to a broader range of users. He argued against having a separate MAST-no-Taproot spending type, as it would reduce incentives for those who don't prioritize spending policy privacy in building key-path-spendable protocols. Wuille also mentioned alternative options for cheap verification constructions but noted that they disregard incentives for privacy, which could negatively impact fungibility and overall system effectiveness.In a Bitcoin-dev thread, Jeremy questioned whether using Schnorr + Merkle Branch without Taproot optimization is equivalent. Dave responded that it is only true if all parties construct their merkle tree with a single `OP_CHECKSIG` as one of the top leaves. However, Taproot standardizes the position of the all-parties-agree condition, leading to a larger anonymity set and easier participation by pure single-sig users. Despite taproot scriptPubKeys being larger than P2WPKH scriptPubKeys, the witness data is considerably smaller, incentivizing receivers to demand P2TR payments even if spenders are reluctant to pay the extra 12 vbytes per output. Dave provided rough estimates for various PubKeys and witness data types. He concluded by stating that this branch of the discussion reiterates points covered two years ago.A group of anonymous developers expressed concerns about the development and deployment of Taproot, proposing an alternate path and suggesting modifications to its specification. They argue that Taproot is essentially the same as using Schnorr signatures separately, but combining them assumes specific use cases and probability distributions. The developers propose separate soft-forks for Merkle Branch Witnesses based on Taproot and Schnorr Signatures, followed by a separate soft-fork enabling Taproot and Graftroot. They believe this conservative approach allows for real-world protocol engineering experience to validate the Taproot frequency assumption. The group suggests modifying Taproot's specification by adding a rule for the Taproot Public NUMS Optimization, which includes attempting to hash the witness stack and using a NUMS point only when a single-use nonce can be sent. They advocate for careful consideration of Taproot's benefits compared to simpler alternatives and incremental improvements.Another group of anonymous developers raised concerns about the deployment of Taproot in Bitcoin and questioned its benefits over simpler alternatives. They discussed Taproot's efficiency, privacy implications, and the wisdom of including multiple features into Bitcoin simultaneously. They proposed an alternate deployment path involving separate soft-forks for Merkle Branch Witnesses based on Taproot and Schnorr Signatures, followed by a separate soft-fork enabling Taproot and Graftroot. The group also suggested modifications to Taproot's specification, such as allowing the witness type to be either a MAST hash or a Schnorr key, and evaluating delegated scripts using a P2SH-like semantic. They emphasized the importance of considering the actual use cases and probability distributions for Taproot's assumptions.In a recent bitcoin-dev discussion, it was confirmed that Taproot is more private than bare MAST and Schnorr when used separately. When combined with schnorr, Taproot enables various transaction types that represent a majority of spends seen on the blockchain throughout Bitcoin's history, optimizing them for anonymity set inclusion. While there is an overhead to the size of inputs, optimizations can allow for the creation of large anonymity sets. Encouraging script-path spenders to find mutually-agreed contract resolutions can further minimize blockchain use and increase the anonymity set. The discussion also highlighted the prevalence of single-sig, n-of-n, and k-of-n (for small n) transactions, supporting the assumption that Taproot with a key will be more common than script cases.A group of anonymous developers expressed concerns regarding the deployment of Taproot in Bitcoin, advocating for a careful evaluation of its benefits compared to simpler primitives. They proposed an alternative deployment path and modifications to Taproot's specification. Their concerns encompassed efficiency, privacy, and the need for incremental improvements that can work together. The group emphasized the importance of considering their suggestions and engaging in community dialogue. 2020-02-18T23:29:21+00:00 + Pieter Wuille emphasized the significance of Taproot in incentivizing protocols and implementations that utilize the key path, maximizing privacy and appealing to a broader range of users. He argued against having a separate MAST-no-Taproot spending type, as it would reduce incentives for those who don't prioritize spending policy privacy in building key-path-spendable protocols. Wuille also mentioned alternative options for cheap verification constructions but noted that they disregard incentives for privacy, which could negatively impact fungibility and overall system effectiveness.In a Bitcoin-dev thread, Jeremy questioned whether using Schnorr + Merkle Branch without Taproot optimization is equivalent. Dave responded that it is only true if all parties construct their merkle tree with a single `OP_CHECKSIG` as one of the top leaves. However, Taproot standardizes the position of the all-parties-agree condition, leading to a larger anonymity set and easier participation by pure single-sig users. Despite taproot scriptPubKeys being larger than P2WPKH scriptPubKeys, the witness data is considerably smaller, incentivizing receivers to demand P2TR payments even if spenders are reluctant to pay the extra 12 vbytes per output. Dave provided rough estimates for various PubKeys and witness data types. He concluded by stating that this branch of the discussion reiterates points covered two years ago.A group of anonymous developers expressed concerns about the development and deployment of Taproot, proposing an alternate path and suggesting modifications to its specification. They argue that Taproot is essentially the same as using Schnorr signatures separately, but combining them assumes specific use cases and probability distributions. The developers propose separate soft-forks for Merkle Branch Witnesses based on Taproot and Schnorr Signatures, followed by a separate soft-fork enabling Taproot and Graftroot. They believe this conservative approach allows for real-world protocol engineering experience to validate the Taproot frequency assumption. The group suggests modifying Taproot's specification by adding a rule for the Taproot Public NUMS Optimization, which includes attempting to hash the witness stack and using a NUMS point only when a single-use nonce can be sent. They advocate for careful consideration of Taproot's benefits compared to simpler alternatives and incremental improvements.Another group of anonymous developers raised concerns about the deployment of Taproot in Bitcoin and questioned its benefits over simpler alternatives. They discussed Taproot's efficiency, privacy implications, and the wisdom of including multiple features into Bitcoin simultaneously. They proposed an alternate deployment path involving separate soft-forks for Merkle Branch Witnesses based on Taproot and Schnorr Signatures, followed by a separate soft-fork enabling Taproot and Graftroot. The group also suggested modifications to Taproot's specification, such as allowing the witness type to be either a MAST hash or a Schnorr key, and evaluating delegated scripts using a P2SH-like semantic. They emphasized the importance of considering the actual use cases and probability distributions for Taproot's assumptions.In a recent bitcoin-dev discussion, it was confirmed that Taproot is more private than bare MAST and Schnorr when used separately. When combined with schnorr, Taproot enables various transaction types that represent a majority of spends seen on the blockchain throughout Bitcoin's history, optimizing them for anonymity set inclusion. While there is an overhead to the size of inputs, optimizations can allow for the creation of large anonymity sets. Encouraging script-path spenders to find mutually-agreed contract resolutions can further minimize blockchain use and increase the anonymity set. The discussion also highlighted the prevalence of single-sig, n-of-n, and k-of-n (for small n) transactions, supporting the assumption that Taproot with a key will be more common than script cases.A group of anonymous developers expressed concerns regarding the deployment of Taproot in Bitcoin, advocating for a careful evaluation of its benefits compared to simpler primitives. They proposed an alternative deployment path and modifications to Taproot's specification. Their concerns encompassed efficiency, privacy, and the need for incremental improvements that can work together. The group emphasized the importance of considering their suggestions and engaging in community dialogue. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity.xml b/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity.xml index 9a5f47c216..6da588e5c3 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity.xml @@ -1,35 +1,83 @@ - + 2 Combined summary - Taproot (and graftroot) complexity - 2023-08-02T01:50:21.179250+00:00 - - Lloyd Fournier 2020-09-20 03:23:28+00:00 - - - Jay Berg 2020-09-19 12:52:51+00:00 - - - Jay Berg 2020-09-19 08:46:12+00:00 - - - Jay Berg 2020-09-19 07:13:40+00:00 - - - ZmnSCPxj 2020-02-10 06:27:24+00:00 - - - Anthony Towns 2020-02-10 00:20:11+00:00 - - - Antoine Riard 2020-02-09 22:32:41+00:00 - - - Matt Corallo 2020-02-09 20:40:27+00:00 - - - Bryan Bishop 2020-02-09 20:19:55+00:00 - + 2025-09-26T15:51:28.209486+00:00 + python-feedgen + + + [bitcoin-dev] Taproot (and graftroot) complexity Bryan Bishop + 2020-02-09T20:19:00.000Z + + + [bitcoin-dev] An alternative deployment path for taproot technology (Re: Taproot (and graftroot) complexity) Bryan Bishop + 2020-02-09T20:22:00.000Z + + + [bitcoin-dev] Taproot public NUMS optimization " Bryan Bishop + 2020-02-09T20:24:00.000Z + + + [bitcoin-dev] Taproot (and graftroot) complexity Matt Corallo + 2020-02-09T20:40:00.000Z + + + [bitcoin-dev] Taproot (and graftroot) complexity (reflowed) Bryan Bishop + 2020-02-09T20:47:00.000Z + + + Antoine Riard + 2020-02-09T22:32:00.000Z + + + David A. Harding + 2020-02-10T00:15:00.000Z + + + [bitcoin-dev] Taproot (and graftroot) complexity Anthony Towns + 2020-02-10T00:20:00.000Z + + + ZmnSCPxj + 2020-02-10T06:27:00.000Z + + + Jonas Nick + 2020-02-10T16:28:00.000Z + + + Jeremy + 2020-02-14T20:07:00.000Z + + + Jeremy + 2020-02-14T21:21:00.000Z + + + David A. Harding + 2020-02-14T22:36:00.000Z + + + Pieter Wuille + 2020-02-18T23:29:00.000Z + + + Jay Berg + 2020-09-19T07:13:00.000Z + + + Jay Berg + 2020-09-19T08:46:00.000Z + + + Jay Berg + 2020-09-19T12:52:00.000Z + + + Lloyd Fournier + 2020-09-20T03:23:00.000Z + + @@ -39,13 +87,13 @@ - python-feedgen + 2 Combined summary - Taproot (and graftroot) complexity - 2023-08-02T01:50:21.179250+00:00 + 2025-09-26T15:51:28.211367+00:00 - In an email exchange within the bitcoin-dev community, LL and Jay Berg discussed the security and privacy implications of reusing keys in Taproot. LL stated that there is not much difference in security or privacy, and the advice to avoid key reuse remains the same. Jay Berg, new to bitcoin-dev, asked if reusing keys acts differently in Taproot compared to Pay-to-PubKey-Hash. The conversation referred to a thread about Taproot complexity started by Anthony Towns on February 10, 2020.The creation of UTXOs in Taproot allows for indistinguishable spends as long as keys are not reused. Reusing keys may have security and privacy implications, but it is unclear whether it has different implications in Taproot compared to Pay-to-PubKey-Hash. The use of the same public key to create the same address remains the same in both cases. The question raised is whether there are worse security and privacy implications when reusing public keys with Taproot.ZmnSCPxj presented an argument related to Taproot in a message to the group. He explained how most scripts in use have a pre-determined set of participants represented by pubkeys, and Taproot allows for the union of these participants as the keypath branch. This provides privacy and reduced onchain fees when all participants sign a transaction using the keypath spend. Taproot can be beneficial for complex contracts and protocols, offering privacy and transaction size benefits.The discussion on the bitcoin-dev mailing list focused on the development and benefits of Taproot. It allows wallets to change recovery options if a key is lost and offers advantages such as reduced onchain fees. Graftroot was also mentioned but not proposed due to incomplete documentation. The benefits of Taproot include preserving anonymity sets even after spending. However, concerns were raised about the merit of Taproot compared to alternatives and the development process.Privacy concerns regarding Taproot design were also discussed. It was suggested that users may care more about privacy when contesting a close of a channel, and timelocks were identified as a privacy leak. The optimization for the common case of N of N opt-out in the protocol was highlighted as beneficial for user privacy and advanced functionality.Bryan Bishop questioned the Taproot upgrade, specifically the assumption about the frequency and likelihood of the signature case over the script case. Matt Corallo clarified that optimization for the common N of N case encourages developers to make this possibility a reality, enhancing user privacy for advanced scripting systems.A group of anonymous developers expressed concerns about the Taproot upgrade and its development. They questioned the probability assumption of the N of N case and its comparison to script paths. Privacy concerns were raised, suggesting alternative designs with MAST that offer more privacy. The developers proposed solutions such as allowing the witness type to be either a MAST hash or a schnorr key and separate soft-forks for Merkle Branch Witnesses and Schnorr Signatures.The developers emphasized their duty to raise these concerns and suggestions for the benefit of the community. Despite concerns, Taproot is viewed as a good midway point to release the feature and move forward. 2020-09-20T03:23:28+00:00 + In an email exchange within the bitcoin-dev community, LL and Jay Berg discussed the security and privacy implications of reusing keys in Taproot. LL stated that there is not much difference in security or privacy, and the advice to avoid key reuse remains the same. Jay Berg, new to bitcoin-dev, asked if reusing keys acts differently in Taproot compared to Pay-to-PubKey-Hash. The conversation referred to a thread about Taproot complexity started by Anthony Towns on February 10, 2020.The creation of UTXOs in Taproot allows for indistinguishable spends as long as keys are not reused. Reusing keys may have security and privacy implications, but it is unclear whether it has different implications in Taproot compared to Pay-to-PubKey-Hash. The use of the same public key to create the same address remains the same in both cases. The question raised is whether there are worse security and privacy implications when reusing public keys with Taproot.ZmnSCPxj presented an argument related to Taproot in a message to the group. He explained how most scripts in use have a pre-determined set of participants represented by pubkeys, and Taproot allows for the union of these participants as the keypath branch. This provides privacy and reduced onchain fees when all participants sign a transaction using the keypath spend. Taproot can be beneficial for complex contracts and protocols, offering privacy and transaction size benefits.The discussion on the bitcoin-dev mailing list focused on the development and benefits of Taproot. It allows wallets to change recovery options if a key is lost and offers advantages such as reduced onchain fees. Graftroot was also mentioned but not proposed due to incomplete documentation. The benefits of Taproot include preserving anonymity sets even after spending. However, concerns were raised about the merit of Taproot compared to alternatives and the development process.Privacy concerns regarding Taproot design were also discussed. It was suggested that users may care more about privacy when contesting a close of a channel, and timelocks were identified as a privacy leak. The optimization for the common case of N of N opt-out in the protocol was highlighted as beneficial for user privacy and advanced functionality.Bryan Bishop questioned the Taproot upgrade, specifically the assumption about the frequency and likelihood of the signature case over the script case. Matt Corallo clarified that optimization for the common N of N case encourages developers to make this possibility a reality, enhancing user privacy for advanced scripting systems.A group of anonymous developers expressed concerns about the Taproot upgrade and its development. They questioned the probability assumption of the N of N case and its comparison to script paths. Privacy concerns were raised, suggesting alternative designs with MAST that offer more privacy. The developers proposed solutions such as allowing the witness type to be either a MAST hash or a schnorr key and separate soft-forks for Merkle Branch Witnesses and Schnorr Signatures.The developers emphasized their duty to raise these concerns and suggestions for the benefit of the community. Despite concerns, Taproot is viewed as a good midway point to release the feature and move forward. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2020/combined_Taproot-public-NUMS-optimization-Re-Taproot-and-graftroot-complexity-.xml b/static/bitcoin-dev/Feb_2020/combined_Taproot-public-NUMS-optimization-Re-Taproot-and-graftroot-complexity-.xml index 154e839697..612c3aaf17 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Taproot-public-NUMS-optimization-Re-Taproot-and-graftroot-complexity-.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Taproot-public-NUMS-optimization-Re-Taproot-and-graftroot-complexity-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity) - 2023-08-02T01:50:53.571727+00:00 + 2025-09-26T15:51:21.918210+00:00 + python-feedgen Jeremy 2020-02-14 21:21:15+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity) - 2023-08-02T01:50:53.571727+00:00 + 2025-09-26T15:51:21.918379+00:00 - A group of anonymous developers have proposed a modification to the Taproot specification in BIP-341 to optimize its public NUMS and enhance privacy. The proposal suggests removing the need for public NUMS and introducing bare MAST (Merkleized Abstract Syntax Trees) to prevent the leakage of metadata from different public NUMS. The use of a NUMS point in Taproot can still be maintained for greater anonymity, but it is recommended only when a single-use nonce can be sent. Private NUMS are noted to provide more privacy benefits with a minimal impact on the likelihood of losing funds.The proposal has garnered support as well as alternative responses from the developer community. Suggestions include implementing a discounting rule for the Public NUMS or modifying the leaf version portion of C[0] to denote Public NUMS and avoid including the point explicitly. These discussions are being conducted under pseudonyms to keep the focus on technical issues rather than personal politics.In addition to the proposed modification, the group of developers discusses the design merits of Taproot compared to simpler alternatives. They also propose an alternative path for deploying the technologies described in BIP-340, BIP-341, and BIP-342.It is highlighted that using a NUMS point in Taproot may decrease privacy if the points differ across applications, potentially allowing for wallet fingerprinting. Therefore, the recommendation is to use the NUMS point only when a single-use nonce can be sent, ensuring that it cannot be distinguished from a normal Taproot by third parties unaware of the setup.Overall, the goal of the anonymous developer group is to contribute to finding the best way forward with Taproot, without causing division within the community. 2020-02-14T21:21:15+00:00 + A group of anonymous developers have proposed a modification to the Taproot specification in BIP-341 to optimize its public NUMS and enhance privacy. The proposal suggests removing the need for public NUMS and introducing bare MAST (Merkleized Abstract Syntax Trees) to prevent the leakage of metadata from different public NUMS. The use of a NUMS point in Taproot can still be maintained for greater anonymity, but it is recommended only when a single-use nonce can be sent. Private NUMS are noted to provide more privacy benefits with a minimal impact on the likelihood of losing funds.The proposal has garnered support as well as alternative responses from the developer community. Suggestions include implementing a discounting rule for the Public NUMS or modifying the leaf version portion of C[0] to denote Public NUMS and avoid including the point explicitly. These discussions are being conducted under pseudonyms to keep the focus on technical issues rather than personal politics.In addition to the proposed modification, the group of developers discusses the design merits of Taproot compared to simpler alternatives. They also propose an alternative path for deploying the technologies described in BIP-340, BIP-341, and BIP-342.It is highlighted that using a NUMS point in Taproot may decrease privacy if the points differ across applications, potentially allowing for wallet fingerprinting. Therefore, the recommendation is to use the NUMS point only when a single-use nonce can be sent, ensuring that it cannot be distinguished from a normal Taproot by third parties unaware of the setup.Overall, the goal of the anonymous developer group is to contribute to finding the best way forward with Taproot, without causing division within the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_A-design-for-Probabilistic-Partial-Pruning.xml b/static/bitcoin-dev/Feb_2021/combined_A-design-for-Probabilistic-Partial-Pruning.xml index 0666f61cbd..7aea66df3e 100644 --- a/static/bitcoin-dev/Feb_2021/combined_A-design-for-Probabilistic-Partial-Pruning.xml +++ b/static/bitcoin-dev/Feb_2021/combined_A-design-for-Probabilistic-Partial-Pruning.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - A design for Probabilistic Partial Pruning - 2023-08-02T03:15:34.692962+00:00 - - Keagan McClelland 2021-03-01 20:55:10+00:00 - - - eric at voskuil.org 2021-03-01 09:37:06+00:00 - - - Craig Raw 2021-03-01 06:22:01+00:00 - - - Leo Wandersleb 2021-02-28 03:41:06+00:00 - - - David A. Harding 2021-02-27 23:37:52+00:00 - - - Yuval Kogman 2021-02-27 22:13:29+00:00 - - - Yuval Kogman 2021-02-27 22:09:48+00:00 - - - David A. Harding 2021-02-27 19:19:34+00:00 - - - Igor Cota 2021-02-27 07:10:39+00:00 - - - Keagan McClelland 2021-02-26 18:40:35+00:00 - + 2025-09-26T15:55:16.169634+00:00 + python-feedgen + + + [bitcoin-dev] A design for Probabilistic Partial Pruning Keagan McClelland + 2021-02-26T18:40:00.000Z + + + Igor Cota + 2021-02-27T07:10:00.000Z + + + David A. Harding + 2021-02-27T19:19:00.000Z + + + Yuval Kogman + 2021-02-27T22:09:00.000Z + + + Yuval Kogman + 2021-02-27T22:13:00.000Z + + + David A. Harding + 2021-02-27T23:37:00.000Z + + + Leo Wandersleb + 2021-02-28T03:41:00.000Z + + + Craig Raw + 2021-03-01T06:22:00.000Z + + + eric + 2021-03-01T09:37:00.000Z + + + Keagan McClelland + 2021-03-01T20:55:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - A design for Probabilistic Partial Pruning - 2023-08-02T03:15:34.692962+00:00 + 2025-09-26T15:55:16.170849+00:00 - The bitcoin-dev mailing list has been discussing a proposal to address the issue of ongoing storage costs for full nodes and pruned nodes. Currently, users have two options: either prune everything except the most recent blocks or keep everything since genesis. The proposed solution is to randomly prune some of the blocks from history based on a unique node seed and threshold expressed as a percentage of blocks. This would increase data redundancy and share the load across nodes more uniformly, reducing the pressure on full archive nodes during the initial block download (IBD) process.The discussion also explores the use of fountain codes to increase data redundancy and improve the distribution of blocks. Fountain codes create an infinite stream of codewords that can be XORed to recover the full message. This approach, known as SeF, retains a fixed number of codewords from the encoding concatenated blocks and serves them to compatible clients. It has been found to be more robust than retaining a random sample of blocks.The proposal suggests advertising the node's seed and threshold as a peer service once the IBD is complete. This would allow other nodes to determine which blocks each peer has. However, concerns about fingerprinting weaknesses have been raised, and it is noted that popular node software is unlikely to adopt this idea unless it solves an urgent problem.Another suggestion is to decide on a range of blocks to keep beforehand, rather than making the decision block-by-block. This could be computationally lighter and better serve other nodes due to the sequential nature of IBD. A paper proposing a distributed hash table (DHT) scheme by Ryosuke Abe is recommended for further reading.Overall, the proposal aims to provide a solution to the ongoing storage costs for full nodes and pruned nodes by randomly pruning blocks from history based on a unique node seed and threshold. Feedback is being sought on the protocol design and the barriers to implementing this functionality into Core. 2021-03-01T20:55:10+00:00 + The bitcoin-dev mailing list has been discussing a proposal to address the issue of ongoing storage costs for full nodes and pruned nodes. Currently, users have two options: either prune everything except the most recent blocks or keep everything since genesis. The proposed solution is to randomly prune some of the blocks from history based on a unique node seed and threshold expressed as a percentage of blocks. This would increase data redundancy and share the load across nodes more uniformly, reducing the pressure on full archive nodes during the initial block download (IBD) process.The discussion also explores the use of fountain codes to increase data redundancy and improve the distribution of blocks. Fountain codes create an infinite stream of codewords that can be XORed to recover the full message. This approach, known as SeF, retains a fixed number of codewords from the encoding concatenated blocks and serves them to compatible clients. It has been found to be more robust than retaining a random sample of blocks.The proposal suggests advertising the node's seed and threshold as a peer service once the IBD is complete. This would allow other nodes to determine which blocks each peer has. However, concerns about fingerprinting weaknesses have been raised, and it is noted that popular node software is unlikely to adopt this idea unless it solves an urgent problem.Another suggestion is to decide on a range of blocks to keep beforehand, rather than making the decision block-by-block. This could be computationally lighter and better serve other nodes due to the sequential nature of IBD. A paper proposing a distributed hash table (DHT) scheme by Ryosuke Abe is recommended for further reading.Overall, the proposal aims to provide a solution to the ongoing storage costs for full nodes and pruned nodes by randomly pruning blocks from history based on a unique node seed and threshold. Feedback is being sought on the protocol design and the barriers to implementing this functionality into Core. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_BIP32-43-based-standard-for-Schnorr-signatures-decentralized-identity.xml b/static/bitcoin-dev/Feb_2021/combined_BIP32-43-based-standard-for-Schnorr-signatures-decentralized-identity.xml index f8bfb152b4..fe64b50879 100644 --- a/static/bitcoin-dev/Feb_2021/combined_BIP32-43-based-standard-for-Schnorr-signatures-decentralized-identity.xml +++ b/static/bitcoin-dev/Feb_2021/combined_BIP32-43-based-standard-for-Schnorr-signatures-decentralized-identity.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - BIP32/43-based standard for Schnorr signatures & decentralized identity - 2023-08-02T03:04:31.097072+00:00 - - Dr Maxim Orlovsky 2021-02-18 18:58:54+00:00 - - - Dr Maxim Orlovsky 2021-02-18 18:52:12+00:00 - - - Pieter Wuille 2021-02-11 20:31:13+00:00 - - - Dr Maxim Orlovsky 2021-02-11 14:38:57+00:00 - - - Dr Maxim Orlovsky 2021-02-11 07:28:07+00:00 - - - Dr Maxim Orlovsky 2021-02-11 07:27:42+00:00 - - - Pieter Wuille 2021-02-06 01:15:12+00:00 - - - Christopher Allen 2021-02-05 22:37:01+00:00 - - - Dmitry Petukhov 2021-02-05 22:00:29+00:00 - - - Dr Maxim Orlovsky 2021-02-05 17:51:27+00:00 - + 2025-09-26T15:55:09.792132+00:00 + python-feedgen + + + [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity Dr Maxim Orlovsky + 2021-02-05T17:51:00.000Z + + + Dmitry Petukhov + 2021-02-05T22:00:00.000Z + + + Christopher Allen + 2021-02-05T22:37:00.000Z + + + Pieter Wuille + 2021-02-06T01:15:00.000Z + + + Dr Maxim Orlovsky + 2021-02-11T07:27:00.000Z + + + Dr Maxim Orlovsky + 2021-02-11T07:28:00.000Z + + + Dr Maxim Orlovsky + 2021-02-11T14:38:00.000Z + + + Pieter Wuille + 2021-02-11T20:31:00.000Z + + + Dr Maxim Orlovsky + 2021-02-18T18:52:00.000Z + + + Dr Maxim Orlovsky + 2021-02-18T18:58:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP32/43-based standard for Schnorr signatures & decentralized identity - 2023-08-02T03:04:31.097072+00:00 + 2025-09-26T15:55:09.793316+00:00 - In an email conversation, Dr. Maxim Orlovsky and Pieter Wuille discussed the need for a dedicated purpose, or BIP, for BIP340 signatures to avoid key reuse. This would be necessary for a specific way of using keys, such as single-key pay-to-taproot, and for multisig participation. Maxim proposed simplifying this by having a dedicated deterministically-derived hardened key for each use case under a single standard, which would simplify future wallet implementations. However, Pieter pointed out that this doesn't address the more general problem of preventing key reuse in multiple distinct groups of multisig sets. Maxim then proposed a new purpose field supporting all the above: hardened derivation that supports multisigs, single-sigs, etc. The proposal includes a section on how multisigs can be created in a simple and deterministic way without key reuse.Bitcoin Improvement Proposal (BIP) 43 defines a dedicated purpose field for each key derivation and address encoding, including separate purposes for pre-SegWit, SegWit, and multisigs. With the introduction of Schnorr sigs/Taproot outputs, a new purpose is needed. Maxim proposed a solution that supports all previous purposes, making them redundant and simplifying future wallets.During their discussion, Dr. Maxim Orlovsky and Peter Wuille discussed key derivations, security, and key tweaks in the context of Schnorr signatures and Taproot. They emphasized the need for a new BIP-43 based BIP with a new purpose field for keys used in Schnorr signatures. It was advised to never reuse keys for privacy and organizational reasons. Separate keys/derivation branches should be used for different uses to ensure privacy and provable security. Keys used for ECDSA and BIP340 should be separated by a hardened step.Christopher Allen, a co-author of the emerging W3C Decentralized Identifier standard and the BTCR DID method, expressed his interest in supporting the discussion and implementation of the topics discussed by Dr. Maxim Orlovsky and Peter Wuille. He mentioned that some patrons of Blockchain Commons may be willing to financially support reference code related to decentralized identifiers.In a separate email exchange, Dmitry and Maxim discussed the hardening of the testnet path for a proposed project. Dmitry argued against using unhardened paths as it could reduce robustness and add complexity to the test software. Maxim agreed with Dmitry's points but suggested changing the "purpose" part of the path instead of using unhardened paths. The need for private key access to hardened paths in test software was emphasized as expected behavior in production.A proposal emerged from the discussion between Peter Wuille and an unnamed author suggesting the need for a new BIP-43 based protocol with a new purpose field for keys used in Schnorr signatures. The proposal includes introducing a blockchain field to prevent key reuse across blockchains and simplify the use of custom xpub prefixes. The proposal also explores the concept of decentralized login strings as unique user logins or keys for searching user metadata. Multisig wallets creation, authentication, and identity revocations are also discussed in the proposal. Layer-2 and 3 solutions are mentioned to provide users with additional features related to identity meta-information. The proposal was prepared by Dr. Maxim Orlovsky, who is also the engineer behind RGB smart contracts. 2021-02-18T18:58:54+00:00 + In an email conversation, Dr. Maxim Orlovsky and Pieter Wuille discussed the need for a dedicated purpose, or BIP, for BIP340 signatures to avoid key reuse. This would be necessary for a specific way of using keys, such as single-key pay-to-taproot, and for multisig participation. Maxim proposed simplifying this by having a dedicated deterministically-derived hardened key for each use case under a single standard, which would simplify future wallet implementations. However, Pieter pointed out that this doesn't address the more general problem of preventing key reuse in multiple distinct groups of multisig sets. Maxim then proposed a new purpose field supporting all the above: hardened derivation that supports multisigs, single-sigs, etc. The proposal includes a section on how multisigs can be created in a simple and deterministic way without key reuse.Bitcoin Improvement Proposal (BIP) 43 defines a dedicated purpose field for each key derivation and address encoding, including separate purposes for pre-SegWit, SegWit, and multisigs. With the introduction of Schnorr sigs/Taproot outputs, a new purpose is needed. Maxim proposed a solution that supports all previous purposes, making them redundant and simplifying future wallets.During their discussion, Dr. Maxim Orlovsky and Peter Wuille discussed key derivations, security, and key tweaks in the context of Schnorr signatures and Taproot. They emphasized the need for a new BIP-43 based BIP with a new purpose field for keys used in Schnorr signatures. It was advised to never reuse keys for privacy and organizational reasons. Separate keys/derivation branches should be used for different uses to ensure privacy and provable security. Keys used for ECDSA and BIP340 should be separated by a hardened step.Christopher Allen, a co-author of the emerging W3C Decentralized Identifier standard and the BTCR DID method, expressed his interest in supporting the discussion and implementation of the topics discussed by Dr. Maxim Orlovsky and Peter Wuille. He mentioned that some patrons of Blockchain Commons may be willing to financially support reference code related to decentralized identifiers.In a separate email exchange, Dmitry and Maxim discussed the hardening of the testnet path for a proposed project. Dmitry argued against using unhardened paths as it could reduce robustness and add complexity to the test software. Maxim agreed with Dmitry's points but suggested changing the "purpose" part of the path instead of using unhardened paths. The need for private key access to hardened paths in test software was emphasized as expected behavior in production.A proposal emerged from the discussion between Peter Wuille and an unnamed author suggesting the need for a new BIP-43 based protocol with a new purpose field for keys used in Schnorr signatures. The proposal includes introducing a blockchain field to prevent key reuse across blockchains and simplify the use of custom xpub prefixes. The proposal also explores the concept of decentralized login strings as unique user logins or keys for searching user metadata. Multisig wallets creation, authentication, and identity revocations are also discussed in the proposal. Layer-2 and 3 solutions are mentioned to provide users with additional features related to identity meta-information. The proposal was prepared by Dr. Maxim Orlovsky, who is also the engineer behind RGB smart contracts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_BIP70-is-dead-What-now-.xml b/static/bitcoin-dev/Feb_2021/combined_BIP70-is-dead-What-now-.xml index 13fc0fa718..ad3c2ac0ed 100644 --- a/static/bitcoin-dev/Feb_2021/combined_BIP70-is-dead-What-now-.xml +++ b/static/bitcoin-dev/Feb_2021/combined_BIP70-is-dead-What-now-.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - BIP70 is dead. What now? - 2023-08-02T03:12:49.715839+00:00 - - P G 2021-03-04 15:56:10+00:00 - - - Eoin McQuinn 2021-02-20 15:53:57+00:00 - - - Andrew Kozlik 2021-02-19 13:34:16+00:00 - - - Charles Hill 2021-02-19 10:33:45+00:00 - - - Thomas Voegtlin 2021-02-19 09:14:39+00:00 - + 2025-09-26T15:55:07.563305+00:00 + python-feedgen + + + [bitcoin-dev] BIP70 is dead. What now? Thomas Voegtlin + 2021-02-19T09:14:00.000Z + + + Charles Hill + 2021-02-19T10:33:00.000Z + + + Andrew Kozlik + 2021-02-19T13:34:00.000Z + + + Eoin McQuinn + 2021-02-20T15:53:00.000Z + + + P G + 2021-03-04T15:56:00.000Z + + - python-feedgen + 2 Combined summary - BIP70 is dead. What now? - 2023-08-02T03:12:49.715839+00:00 + 2025-09-26T15:55:07.564040+00:00 - In a recent Bitcoin-dev mailing list, Thomas Voegtlin expressed his dislike of the BIP70 standard but found the feature of signed payment requests useful. He believes that receiving a signed request from an exchange would serve as proof that the exchange asked him to send coins to a specific address, especially important in case of exchange hijacking. However, no exchange has implemented this feature. Andrew Kozlik shared his experimental implementation of a new payment request format in Trezor T, similar to BIP-70 but with some differences. It does not rely on X.509 and instead uses mandatory signatures for protection against man-in-the-middle attacks. It also solves problems with coin exchange by ensuring correct BTC and LTC addresses. Charles Hill shared a URL signing scheme for LNURL, which could be modified to fit Thomas' use-case. Voegtlin suggested adopting a standard for signed requests, which could guide users' decisions on which exchange to use. He would remove BIP70 support from Electrum if a new standard was adopted. 2021-03-04T15:56:10+00:00 + In a recent Bitcoin-dev mailing list, Thomas Voegtlin expressed his dislike of the BIP70 standard but found the feature of signed payment requests useful. He believes that receiving a signed request from an exchange would serve as proof that the exchange asked him to send coins to a specific address, especially important in case of exchange hijacking. However, no exchange has implemented this feature. Andrew Kozlik shared his experimental implementation of a new payment request format in Trezor T, similar to BIP-70 but with some differences. It does not rely on X.509 and instead uses mandatory signatures for protection against man-in-the-middle attacks. It also solves problems with coin exchange by ensuring correct BTC and LTC addresses. Charles Hill shared a URL signing scheme for LNURL, which could be modified to fit Thomas' use-case. Voegtlin suggested adopting a standard for signed requests, which could guide users' decisions on which exchange to use. He would remove BIP70 support from Electrum if a new standard was adopted. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Exploring-alternative-activation-mechanisms-decreasing-threshold.xml b/static/bitcoin-dev/Feb_2021/combined_Exploring-alternative-activation-mechanisms-decreasing-threshold.xml index 810c0fc929..cf55fc7742 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Exploring-alternative-activation-mechanisms-decreasing-threshold.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Exploring-alternative-activation-mechanisms-decreasing-threshold.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Exploring alternative activation mechanisms: decreasing threshold - 2023-08-02T03:15:09.390974+00:00 - - Anthony Towns 2021-03-01 14:33:33+00:00 - - - Ryan Grant 2021-02-28 14:06:42+00:00 - - - Matt Corallo 2021-02-28 02:38:54+00:00 - - - Gregorio Guidi 2021-02-27 23:49:46+00:00 - - - Luke Dashjr 2021-02-27 17:55:00+00:00 - - - Ryan Grant 2021-02-26 17:48:33+00:00 - - - Gregorio Guidi 2021-02-25 22:33:25+00:00 - + 2025-09-26T15:54:54.712418+00:00 + python-feedgen + + + [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold Gregorio Guidi + 2021-02-25T22:33:00.000Z + + + Ryan Grant + 2021-02-26T17:48:00.000Z + + + Luke Dashjr + 2021-02-27T17:55:00.000Z + + + Gregorio Guidi + 2021-02-27T23:49:00.000Z + + + Matt Corallo + 2021-02-28T02:38:00.000Z + + + Ryan Grant + 2021-02-28T14:06:00.000Z + + + Anthony Towns + 2021-03-01T14:33:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Exploring alternative activation mechanisms: decreasing threshold - 2023-08-02T03:15:09.390974+00:00 + 2025-09-26T15:54:54.713348+00:00 - Bitcoin developer Luke Dashjr has expressed concerns about the potential chaos that could arise from non-signalled activation. He warns that anti-soft-fork and pro-SF nodes may end up on the same chain, following conflicting perceptions of the rules. This could result in a strong incentive not to rely on the rules if a resolution is not found.The author of the article discusses the potential risks and downsides of implementing soft forks in cryptocurrency. For instance, allowing miners to steal user funds goes against new rules, and enforcing new rules can lead to hard-fork events and the need for new software. To mitigate these risks, the author suggests delaying activation until all objections are resolved or committing to activation on-chain based on specific criteria.The author also provides examples of past controversial soft forks, including halting segwit deployment due to covert ASICBoost which could have prevented a hard forked chain split. However, the existing plan was followed, and BCH resulted.The author notes that small numbers of advocates running code to enforce a flag day could lead to failure, and that controversy may prevent adoption of certain soft forks. As a solution, the author suggests supporting "user-prohibited soft-forks" in a similar way to "user-activated soft-forks," moving action to whether users are required/prohibited from signaling.On February 27, 2021, Luke Dashjr, via bitcoin-dev expressed concern over the activation of softforks lacking signalling. According to him, this creates ambiguity as it is unclear if the softfork has been activated at all. However, he suggested that the ambiguity can be resolved by seeing one block in the heaviest valid chain.Gregorio Guidi proposed a new activation mechanism for soft forks called "decreasing threshold activation". This approach aims to overcome the limitations of the LOT=true/false dichotomy. It operates similarly to BIP8 but with a gradually reduced threshold that triggers the STARTED -> LOCKED_IN transition on each period in steps of 24 blocks (~1.2%). This approach is relatively conservative at the beginning, requiring a clear majority of signaling hashrate for activation to happen, indicating that the activation is relatively safe.The proposed method simplifies the activation mechanism and eliminates the need to work with different client releases and issues associated with deployed nodes with different consensus parameters. It also removes the motivation to create UASF clients that force activation and provides users and miners with time to safely fork themselves off from the chain followed by Core if they choose not to upgrade.The proposed method has received some pushback, but the hope is that it will be adopted as the default mechanism, requiring little discussion on how to activate future soft forks.Overall, the author emphasizes the need to carefully consider the implications and potential failure modes of implementing soft forks in cryptocurrency. The decreasing threshold activation proposal offers a potential solution to address some of the challenges and risks associated with soft forks. 2021-03-01T14:33:33+00:00 + Bitcoin developer Luke Dashjr has expressed concerns about the potential chaos that could arise from non-signalled activation. He warns that anti-soft-fork and pro-SF nodes may end up on the same chain, following conflicting perceptions of the rules. This could result in a strong incentive not to rely on the rules if a resolution is not found.The author of the article discusses the potential risks and downsides of implementing soft forks in cryptocurrency. For instance, allowing miners to steal user funds goes against new rules, and enforcing new rules can lead to hard-fork events and the need for new software. To mitigate these risks, the author suggests delaying activation until all objections are resolved or committing to activation on-chain based on specific criteria.The author also provides examples of past controversial soft forks, including halting segwit deployment due to covert ASICBoost which could have prevented a hard forked chain split. However, the existing plan was followed, and BCH resulted.The author notes that small numbers of advocates running code to enforce a flag day could lead to failure, and that controversy may prevent adoption of certain soft forks. As a solution, the author suggests supporting "user-prohibited soft-forks" in a similar way to "user-activated soft-forks," moving action to whether users are required/prohibited from signaling.On February 27, 2021, Luke Dashjr, via bitcoin-dev expressed concern over the activation of softforks lacking signalling. According to him, this creates ambiguity as it is unclear if the softfork has been activated at all. However, he suggested that the ambiguity can be resolved by seeing one block in the heaviest valid chain.Gregorio Guidi proposed a new activation mechanism for soft forks called "decreasing threshold activation". This approach aims to overcome the limitations of the LOT=true/false dichotomy. It operates similarly to BIP8 but with a gradually reduced threshold that triggers the STARTED -> LOCKED_IN transition on each period in steps of 24 blocks (~1.2%). This approach is relatively conservative at the beginning, requiring a clear majority of signaling hashrate for activation to happen, indicating that the activation is relatively safe.The proposed method simplifies the activation mechanism and eliminates the need to work with different client releases and issues associated with deployed nodes with different consensus parameters. It also removes the motivation to create UASF clients that force activation and provides users and miners with time to safely fork themselves off from the chain followed by Core if they choose not to upgrade.The proposed method has received some pushback, but the hope is that it will be adopted as the default mechanism, requiring little discussion on how to activate future soft forks.Overall, the author emphasizes the need to carefully consider the implications and potential failure modes of implementing soft forks in cryptocurrency. The decreasing threshold activation proposal offers a potential solution to address some of the challenges and risks associated with soft forks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_LOT-False-is-dangerous-and-shouldn-t-be-used.xml b/static/bitcoin-dev/Feb_2021/combined_LOT-False-is-dangerous-and-shouldn-t-be-used.xml index da91d803a3..76b4933634 100644 --- a/static/bitcoin-dev/Feb_2021/combined_LOT-False-is-dangerous-and-shouldn-t-be-used.xml +++ b/static/bitcoin-dev/Feb_2021/combined_LOT-False-is-dangerous-and-shouldn-t-be-used.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - LOT=False is dangerous and shouldn't be used - 2023-08-02T03:18:28.798769+00:00 - - yanmaani at cock.li 2021-03-03 22:58:10+00:00 - - - Emil Pfeffer 2021-03-03 16:27:24+00:00 - - - Eric Voskuil 2021-03-02 20:07:16+00:00 - - - Chris Belcher 2021-03-02 18:21:59+00:00 - - - Erik Aronesty 2021-03-02 06:11:17+00:00 - - - Emil Pfeffer 2021-03-01 17:52:54+00:00 - - - yanmaani at cock.li 2021-03-01 16:54:07+00:00 - - - Anthony Towns 2021-03-01 15:06:14+00:00 - - - Luke Dashjr 2021-02-28 19:33:30+00:00 - + 2025-09-26T15:54:48.324480+00:00 + python-feedgen + + + [bitcoin-dev] LOT=False is dangerous and shouldn't be used Luke Dashjr + 2021-02-28T19:33:00.000Z + + + Anthony Towns + 2021-03-01T15:06:00.000Z + + + yanmaani + 2021-03-01T16:54:00.000Z + + + Emil Pfeffer + 2021-03-01T17:52:00.000Z + + + Erik Aronesty + 2021-03-02T06:11:00.000Z + + + Chris Belcher + 2021-03-02T18:21:00.000Z + + + Eric Voskuil + 2021-03-02T20:07:00.000Z + + + Emil Pfeffer + 2021-03-03T16:27:00.000Z + + + yanmaani + 2021-03-03T22:58:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - LOT=False is dangerous and shouldn't be used - 2023-08-02T03:18:28.798769+00:00 + 2025-09-26T15:54:48.325597+00:00 - The email thread and discussion on the bitcoin-dev mailing list revolve around the activation mechanism for the Taproot soft fork in Bitcoin. The proposal of LOT=false, where Taproot will be activated if at least 95% of miners vote yes, is compared to the LOT=true proposal, where Taproot will be activated if at least 0% of miners vote yes. A declining percentage of signaling activation is suggested as a compromise, eventually becoming a LOT=true. It is argued that LOT=true holds all the benefits and satisfies arguments for LOT=false with the cooldown period.It is mentioned that old node software will continue to work in the case of a soft-fork, and users following bip8 with lockinontimeout=false will enforce taproot rules if activation occurs. The risk is said to be maximally reduced by deploying LOT=True as the only parameter, while introducing LOT=False would increase the probability and severity of risk.There is a debate over the use of miner signaling for activation, with one member arguing that it is not a bug but an inherent part of how Bitcoin works. The purpose of miner signaling is to avoid a chain split by countering majority hash power censorship. However, another member argues that using LOT=false reintroduces a bug by giving miners a veto and incentive to second-guess activation decisions. In contrast, LOT=true avoids regression on bugs and combines the certainty of a flag day with the speed improvement of a MASF.The discussion also covers concerns about chain splits and unreliable networks for users who do not enforce Taproot rules. It is pointed out that avoiding a reorg can be achieved through various means, such as running "invalidateblock" or examining block headers. However, there are differing opinions on the level of risk associated with LOT=False. Some argue that LOT=True should be the only deployed parameter to minimize risk, while others note that LOT=False is already the default behavior of existing node software.The conversation also touches on the potential for miners to veto a BIP 9 activation, with one member claiming that miners were unable to do so in 2017. However, there is disagreement on whether this is a valid argument.In conclusion, the debate revolves around the risks and benefits of using LOT=true or LOT=false for Taproot activation. Some argue that LOT=false puts users and the network at significant risk, while others believe that LOT=true minimizes risk for everyone. There is a call to remove LOT as an option entirely and deploy all soft forks with LOT=true, but there is no consensus on this issue yet. 2021-03-03T22:58:10+00:00 + The email thread and discussion on the bitcoin-dev mailing list revolve around the activation mechanism for the Taproot soft fork in Bitcoin. The proposal of LOT=false, where Taproot will be activated if at least 95% of miners vote yes, is compared to the LOT=true proposal, where Taproot will be activated if at least 0% of miners vote yes. A declining percentage of signaling activation is suggested as a compromise, eventually becoming a LOT=true. It is argued that LOT=true holds all the benefits and satisfies arguments for LOT=false with the cooldown period.It is mentioned that old node software will continue to work in the case of a soft-fork, and users following bip8 with lockinontimeout=false will enforce taproot rules if activation occurs. The risk is said to be maximally reduced by deploying LOT=True as the only parameter, while introducing LOT=False would increase the probability and severity of risk.There is a debate over the use of miner signaling for activation, with one member arguing that it is not a bug but an inherent part of how Bitcoin works. The purpose of miner signaling is to avoid a chain split by countering majority hash power censorship. However, another member argues that using LOT=false reintroduces a bug by giving miners a veto and incentive to second-guess activation decisions. In contrast, LOT=true avoids regression on bugs and combines the certainty of a flag day with the speed improvement of a MASF.The discussion also covers concerns about chain splits and unreliable networks for users who do not enforce Taproot rules. It is pointed out that avoiding a reorg can be achieved through various means, such as running "invalidateblock" or examining block headers. However, there are differing opinions on the level of risk associated with LOT=False. Some argue that LOT=True should be the only deployed parameter to minimize risk, while others note that LOT=False is already the default behavior of existing node software.The conversation also touches on the potential for miners to veto a BIP 9 activation, with one member claiming that miners were unable to do so in 2017. However, there is disagreement on whether this is a valid argument.In conclusion, the debate revolves around the risks and benefits of using LOT=true or LOT=false for Taproot activation. Some argue that LOT=false puts users and the network at significant risk, while others believe that LOT=true minimizes risk for everyone. There is a call to remove LOT as an option entirely and deploy all soft forks with LOT=true, but there is no consensus on this issue yet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Libre-Open-blockchain-cryptographic-ASICs.xml b/static/bitcoin-dev/Feb_2021/combined_Libre-Open-blockchain-cryptographic-ASICs.xml index 9dd93f3d96..5a775dd911 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Libre-Open-blockchain-cryptographic-ASICs.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Libre-Open-blockchain-cryptographic-ASICs.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Libre/Open blockchain / cryptographic ASICs - 2023-08-02T03:02:51.462708+00:00 - - ZmnSCPxj 2021-02-14 00:27:36+00:00 - - - Luke Kenneth Casson Leighton 2021-02-13 17:19:01+00:00 - - - Luke Kenneth Casson Leighton 2021-02-13 16:44:27+00:00 - - - Bryan Bishop 2021-02-13 14:59:29+00:00 - - - Luke Kenneth Casson Leighton 2021-02-13 09:29:38+00:00 - - - ZmnSCPxj 2021-02-13 06:10:08+00:00 - - - ZmnSCPxj 2021-02-11 08:20:54+00:00 - - - Luke Kenneth Casson Leighton 2021-02-03 14:07:24+00:00 - - - Luke Kenneth Casson Leighton 2021-02-03 13:24:13+00:00 - - - ZmnSCPxj 2021-02-03 03:17:48+00:00 - - - ZmnSCPxj 2021-02-03 02:06:46+00:00 - - - Pavol Rusnak 2021-01-26 10:47:50+00:00 - - - Luke Kenneth Casson Leighton 2021-01-25 18:00:35+00:00 - + 2025-09-26T15:55:11.941263+00:00 + python-feedgen + + + [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs Luke Kenneth Casson Leighton + 2021-01-25T18:00:00.000Z + + + Pavol Rusnak + 2021-01-26T10:47:00.000Z + + + ZmnSCPxj + 2021-02-03T02:06:00.000Z + + + ZmnSCPxj + 2021-02-03T03:17:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-03T13:24:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-03T14:07:00.000Z + + + ZmnSCPxj + 2021-02-11T08:20:00.000Z + + + ZmnSCPxj + 2021-02-13T06:10:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-13T09:29:00.000Z + + + Bryan Bishop + 2021-02-13T14:59:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-13T16:44:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-13T17:19:00.000Z + + + ZmnSCPxj + 2021-02-14T00:27:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Libre/Open blockchain / cryptographic ASICs - 2023-08-02T03:02:51.462708+00:00 + 2025-09-26T15:55:11.942732+00:00 - The discussion revolves around the vulnerability of ASICs in test modes, particularly when key material is loaded into registers or caches. The risk can be mitigated by designing state machines and using flash memory to reload flip-flops that hold settings periodically. However, the vulnerability remains, making excessive caution necessary for cryptographic chips.In an email thread on Bitcoin-dev, concerns are raised about the use of repeater-buffers in ASICs and the need for test modes in mass production. Open-sourcing hardware design also has its risks, as attackers can target specific chip areas for ESD pulse. The importance of transparency in wallet ASICs is emphasized.There is a conversation between two individuals regarding the content of emails. Bryan Bishop expresses confusion, and the other individual apologizes for any confusion caused. They also provide a link to the threads for the bitcoin-dev mailing list.Luke Kenneth Casson Leighton asks for moderated messages to be sent to a different email address. Bryan replies that he cannot see Luke's February emails in the archives. The thread for the bitcoin-dev mailing list can be found on the Linux Foundation website.ZmnSCPxj requests Luke to forward moderated messages to a different email address. ZmnSCPxj discusses the use of scan mode and proposes a masking technique. The importance of being paranoid about test modes in digital circuitry is discussed. Solutions to prevent devices from being forced into test mode are suggested.The conversation covers various topics related to digital circuitry, including inverting buffers, open-source software and hardware RTL designs, test modes, and the importance of being paranoid about them. Solutions to prevent devices from being forced into test mode are provided.The conversation discusses the impact of power efficiency on Bitcoin mining. Increasing power efficiency does not reduce the actual energy consumed by mining. The "arms race" in mining could lead to hardware backdoors. The cost of lower geometries is high, and increasing power efficiency may not benefit anyone.The challenges of designing digital ASICs are discussed, along with the importance of formal correctness proofs and simulation testing. Adding general-purpose instructions that simplify algorithms is explored. Tool licensing costs, working with foundries, and reducing risk are also mentioned.ZmnSCPxj explains that focusing on power efficiency will not reduce energy consumption in Bitcoin mining. The rational choice for miners is to buy more units instead of reducing watt consumption. ZmnSCPxj expresses interest in eco-conscious blockchain and crypto-currency products.The author has experience designing digital ASICs and suggests that smaller geometries are only necessary for specific requirements. The challenges of manual layout and tool licensing costs are discussed. The LibreSOC Project aims to create transparently-openly-developed ASICs. The cost of producing ASICs varies with geometries. The focus should be on power-efficiency.Luke asks what people would like to see happen in regards to delivering to the wider bitcoin user community. Pavol Rusnak from SatoshiLabs offers to exchange ideas and provides a link to Tropic Square's website.The author has been discussing a transparently-developed ASIC/SoC with Kanzure for some time. NLnet has obtained funding, and the author has applied for the "Assure" Programme. The goal is to create fully transparently-openly-developed ASICs for cryptographic tasks. The author is interested in bridging the funding gap and delivering to the bitcoin user community. 2021-02-14T00:27:36+00:00 + The discussion revolves around the vulnerability of ASICs in test modes, particularly when key material is loaded into registers or caches. The risk can be mitigated by designing state machines and using flash memory to reload flip-flops that hold settings periodically. However, the vulnerability remains, making excessive caution necessary for cryptographic chips.In an email thread on Bitcoin-dev, concerns are raised about the use of repeater-buffers in ASICs and the need for test modes in mass production. Open-sourcing hardware design also has its risks, as attackers can target specific chip areas for ESD pulse. The importance of transparency in wallet ASICs is emphasized.There is a conversation between two individuals regarding the content of emails. Bryan Bishop expresses confusion, and the other individual apologizes for any confusion caused. They also provide a link to the threads for the bitcoin-dev mailing list.Luke Kenneth Casson Leighton asks for moderated messages to be sent to a different email address. Bryan replies that he cannot see Luke's February emails in the archives. The thread for the bitcoin-dev mailing list can be found on the Linux Foundation website.ZmnSCPxj requests Luke to forward moderated messages to a different email address. ZmnSCPxj discusses the use of scan mode and proposes a masking technique. The importance of being paranoid about test modes in digital circuitry is discussed. Solutions to prevent devices from being forced into test mode are suggested.The conversation covers various topics related to digital circuitry, including inverting buffers, open-source software and hardware RTL designs, test modes, and the importance of being paranoid about them. Solutions to prevent devices from being forced into test mode are provided.The conversation discusses the impact of power efficiency on Bitcoin mining. Increasing power efficiency does not reduce the actual energy consumed by mining. The "arms race" in mining could lead to hardware backdoors. The cost of lower geometries is high, and increasing power efficiency may not benefit anyone.The challenges of designing digital ASICs are discussed, along with the importance of formal correctness proofs and simulation testing. Adding general-purpose instructions that simplify algorithms is explored. Tool licensing costs, working with foundries, and reducing risk are also mentioned.ZmnSCPxj explains that focusing on power efficiency will not reduce energy consumption in Bitcoin mining. The rational choice for miners is to buy more units instead of reducing watt consumption. ZmnSCPxj expresses interest in eco-conscious blockchain and crypto-currency products.The author has experience designing digital ASICs and suggests that smaller geometries are only necessary for specific requirements. The challenges of manual layout and tool licensing costs are discussed. The LibreSOC Project aims to create transparently-openly-developed ASICs. The cost of producing ASICs varies with geometries. The focus should be on power-efficiency.Luke asks what people would like to see happen in regards to delivering to the wider bitcoin user community. Pavol Rusnak from SatoshiLabs offers to exchange ideas and provides a link to Tropic Square's website.The author has been discussing a transparently-developed ASIC/SoC with Kanzure for some time. NLnet has obtained funding, and the author has applied for the "Assure" Programme. The goal is to create fully transparently-openly-developed ASICs for cryptographic tasks. The author is interested in bridging the funding gap and delivering to the bitcoin user community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Proposal-Bitcoin-Secure-Multisig-Setup.xml b/static/bitcoin-dev/Feb_2021/combined_Proposal-Bitcoin-Secure-Multisig-Setup.xml index e3847f199a..37eb6b33da 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Proposal-Bitcoin-Secure-Multisig-Setup.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Proposal-Bitcoin-Secure-Multisig-Setup.xml @@ -1,119 +1,159 @@ - + 2 Combined summary - Proposal: Bitcoin Secure Multisig Setup - 2023-08-02T03:06:18.370020+00:00 - - Robert Spigler 2021-04-12 20:43:39+00:00 - - - Christopher Allen 2021-04-12 18:45:27+00:00 - - - Hugo Nguyen 2021-04-12 17:55:36+00:00 - - - Salvatore Ingala 2021-04-12 15:03:12+00:00 - - - Hugo Nguyen 2021-04-11 16:45:00+00:00 - - - Michael.flaxman 2021-04-11 02:34:21+00:00 - - - Robert Spigler 2021-04-10 19:32:25+00:00 - - - Erik Aronesty 2021-04-10 13:53:20+00:00 - - - Sjors Provoost 2021-04-09 15:33:31+00:00 - - - Hugo Nguyen 2021-04-09 14:54:11+00:00 - - - Hugo Nguyen 2021-04-09 14:09:51+00:00 - - - Sjors Provoost 2021-04-09 12:07:05+00:00 - - - Hugo Nguyen 2021-04-05 07:02:45+00:00 - - - Hugo Nguyen 2021-02-15 16:45:10+00:00 - - - Hugo Nguyen 2021-02-15 14:19:14+00:00 - - - Craig Raw 2021-02-15 13:53:05+00:00 - - - Hugo Nguyen 2021-02-15 08:44:19+00:00 - - - Dmitry Petukhov 2021-02-14 11:28:58+00:00 - - - Dmitry Petukhov 2021-02-14 10:37:52+00:00 - - - Hugo Nguyen 2021-02-12 17:54:57+00:00 - - - Dmitry Petukhov 2021-02-12 17:48:09+00:00 - - - Dmitry Petukhov 2021-02-12 17:42:31+00:00 - - - Hugo Nguyen 2021-02-12 16:55:55+00:00 - - - Peter D. Gray 2021-02-12 13:48:16+00:00 - - - Hugo Nguyen 2021-02-12 12:31:24+00:00 - - - Christopher Allen 2021-02-11 22:29:46+00:00 - - - Hugo Nguyen 2021-02-11 19:11:45+00:00 - - - Hugo Nguyen 2021-02-11 19:11:11+00:00 - - - Dmitry Petukhov 2021-02-11 16:29:10+00:00 - - - Hugo Nguyen 2021-02-11 13:45:33+00:00 - - - Pavol Rusnak 2021-02-11 13:25:08+00:00 - - - Hugo Nguyen 2021-02-09 10:58:06+00:00 - - - Hugo Nguyen 2021-02-09 10:05:54+00:00 - - - Hugo Nguyen 2021-02-09 09:45:48+00:00 - - - Christopher Allen 2021-02-09 09:38:43+00:00 - - - Craig Raw 2021-02-09 09:33:38+00:00 - - - Hugo Nguyen 2021-02-08 23:14:17+00:00 - + 2025-09-26T15:55:01.178053+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup Hugo Nguyen + 2021-02-08T23:14:00.000Z + + + Craig Raw + 2021-02-09T09:33:00.000Z + + + Christopher Allen + 2021-02-09T09:38:00.000Z + + + Hugo Nguyen + 2021-02-09T09:45:00.000Z + + + Hugo Nguyen + 2021-02-09T10:05:00.000Z + + + Hugo Nguyen + 2021-02-09T10:58:00.000Z + + + Pavol Rusnak + 2021-02-11T13:25:00.000Z + + + Hugo Nguyen + 2021-02-11T13:45:00.000Z + + + Dmitry Petukhov + 2021-02-11T16:29:00.000Z + + + Hugo Nguyen + 2021-02-11T19:11:00.000Z + + + Hugo Nguyen + 2021-02-11T19:11:00.000Z + + + Christopher Allen + 2021-02-11T22:29:00.000Z + + + Hugo Nguyen + 2021-02-12T12:31:00.000Z + + + Peter D. Gray + 2021-02-12T13:48:00.000Z + + + Hugo Nguyen + 2021-02-12T16:55:00.000Z + + + Dmitry Petukhov + 2021-02-12T17:42:00.000Z + + + Dmitry Petukhov + 2021-02-12T17:48:00.000Z + + + Hugo Nguyen + 2021-02-12T17:54:00.000Z + + + Dmitry Petukhov + 2021-02-14T10:37:00.000Z + + + Dmitry Petukhov + 2021-02-14T11:28:00.000Z + + + Hugo Nguyen + 2021-02-15T08:44:00.000Z + + + Craig Raw + 2021-02-15T13:53:00.000Z + + + Hugo Nguyen + 2021-02-15T14:19:00.000Z + + + Hugo Nguyen + 2021-02-15T16:45:00.000Z + + + Hugo Nguyen + 2021-04-05T07:02:00.000Z + + + Sjors Provoost + 2021-04-09T12:07:00.000Z + + + Hugo Nguyen + 2021-04-09T14:09:00.000Z + + + Hugo Nguyen + 2021-04-09T14:54:00.000Z + + + Sjors Provoost + 2021-04-09T15:33:00.000Z + + + Erik Aronesty + 2021-04-10T13:53:00.000Z + + + Robert Spigler + 2021-04-10T19:32:00.000Z + + + Michael.flaxman + 2021-04-11T02:34:00.000Z + + + Hugo Nguyen + 2021-04-11T16:45:00.000Z + + + Salvatore Ingala + 2021-04-12T15:03:00.000Z + + + Hugo Nguyen + 2021-04-12T17:55:00.000Z + + + Christopher Allen + 2021-04-12T18:45:00.000Z + + + Robert Spigler + 2021-04-12T20:43:00.000Z + + @@ -151,13 +191,13 @@ - python-feedgen + 2 Combined summary - Proposal: Bitcoin Secure Multisig Setup - 2023-08-02T03:06:18.371020+00:00 + 2025-09-26T15:55:01.181765+00:00 - In a recent discussion on the bitcoin-dev mailing list, Christopher Allen proposed best practices for avoiding xpub reuse in multisig account creation. He recommends backing up multisig account maps and cosigner key material to enable fund recovery. It is suggested that transaction coordinators should send the cosigner "policy" and final "account map" to all cosigner wallets. These practices are possible with new generation multisig hardware and software wallets.Christopher Allen, a member of Blockchain Commons, has proposed measures to improve privacy in Bitcoin multisig accounts. He suggests that cosigner wallets and transaction coordinator services should not share the master xpub, and that the master xpub fingerprint should not be used due to privacy risks. Instead, a single parent fingerprint should be offered for each account. Transaction coordinators should also send the cosigner "policy" and final "account map" to all cosigner wallets.Salvatore Ingala and Hugo discuss the distinction between a "Signer" and a "Signing device" in a multisig setup. Salvatore proposes a wallet registration flow that allows a Signer to persist a multisig setup in its storage. Hugo emphasizes that signers must be stateful and highlights the problems with signing the descriptor record.Michael expresses concerns about the xpub validation problem and the risk of stateless hardware wallets having their xpubs swapped out. He suggests using a checksum with higher entropy to reduce xpub validation to O(n) and creating an unambiguous format for wallet ID. Hugo disagrees with going stateless and argues that signers must be stateful. Michael raises concerns about malicious receive addresses and the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP aims to set up multisig wallets securely. Michael raises concerns about the BIP's shortcomings in addressing verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption to improve privacy. The coordinator gathers key records from all participating signers and verifies their validity before generating a descriptor record. The descriptor record is encrypted and sent to all signers.In a conversation between Michael and Hugo, they discuss the issues with multisig in Bitcoin. Michael raises concerns about the xpub validation problem and the risk of compromised coordinators swapping out xpubs in stateless hardware wallets. Hugo disagrees with going stateless and highlights problems with signing the descriptor record. Michael also suggests avoiding the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP has been drafted to address concerns surrounding tampering during initial setup. Michael Flaxman expresses concerns about the BIP's failure to address verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption. The coordinator generates key records and a descriptor record, which are encrypted and sent to all signers.The context provided includes discussions on multisig setup context, the need for devices to persist the descriptor, and the redundancy of BIP48 with descriptors. It is suggested that Shamir Secret Sharing could be used for encryption convention and a preference for plain text over binary. Multisig setup context is considered important for developing multisig setups.Bitcoin Secure Multisig Setup (BSMS) proposal introduces a Coordinator and multiple Signers in the setup process. The Coordinator takes the lead in initiating the multisig setup, determining the type of multisig used, and gathering information from the signers to generate a descriptor record. Signers are responsible for providing their XPUB to the Coordinator, verifying its inclusion in the descriptor record, and persisting the record in their storage.The setup process involves two rounds of communication. In round one, the Coordinator creates a multisig wallet creation session, generates a secret token, and shares it securely with all participating signers. The signers then generate a key record by prompting the user for the token and a derivation path. In round two, the Coordinator gathers key records from all signers, decrypts them using an encryption key, verifies the included signatures, and generates a descriptor record. The descriptor record is encrypted and sent to all signers.To ensure security during setup, the proposal recommends using multi-round Distributed Key Generation (DKG) with appropriate commitments and verification of components. It also suggests using encryption conventions for the descriptor data, allowing decryption with any of the seeds to access the full setup. Additional suggestions include using magic bytes for file extensions and plaintext files for human readability.One concern raised is losing multisig setup context, which could result in lost coins. If one device is lost in a 2-of-3 setup without metadata, the coins will be lost. To address this, the proposal recommends an encryption convention that allows decryption of the full setup file with any of the seeds. It also suggests ways to communicate signers' capabilities and extend the specification with path restrictions.The document highlights the importance 2021-04-12T20:43:39+00:00 + In a recent discussion on the bitcoin-dev mailing list, Christopher Allen proposed best practices for avoiding xpub reuse in multisig account creation. He recommends backing up multisig account maps and cosigner key material to enable fund recovery. It is suggested that transaction coordinators should send the cosigner "policy" and final "account map" to all cosigner wallets. These practices are possible with new generation multisig hardware and software wallets.Christopher Allen, a member of Blockchain Commons, has proposed measures to improve privacy in Bitcoin multisig accounts. He suggests that cosigner wallets and transaction coordinator services should not share the master xpub, and that the master xpub fingerprint should not be used due to privacy risks. Instead, a single parent fingerprint should be offered for each account. Transaction coordinators should also send the cosigner "policy" and final "account map" to all cosigner wallets.Salvatore Ingala and Hugo discuss the distinction between a "Signer" and a "Signing device" in a multisig setup. Salvatore proposes a wallet registration flow that allows a Signer to persist a multisig setup in its storage. Hugo emphasizes that signers must be stateful and highlights the problems with signing the descriptor record.Michael expresses concerns about the xpub validation problem and the risk of stateless hardware wallets having their xpubs swapped out. He suggests using a checksum with higher entropy to reduce xpub validation to O(n) and creating an unambiguous format for wallet ID. Hugo disagrees with going stateless and argues that signers must be stateful. Michael raises concerns about malicious receive addresses and the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP aims to set up multisig wallets securely. Michael raises concerns about the BIP's shortcomings in addressing verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption to improve privacy. The coordinator gathers key records from all participating signers and verifies their validity before generating a descriptor record. The descriptor record is encrypted and sent to all signers.In a conversation between Michael and Hugo, they discuss the issues with multisig in Bitcoin. Michael raises concerns about the xpub validation problem and the risk of compromised coordinators swapping out xpubs in stateless hardware wallets. Hugo disagrees with going stateless and highlights problems with signing the descriptor record. Michael also suggests avoiding the use of BIP39 words for session tokens.A proposed Bitcoin Secure Multisig Setup (BSMS) BIP has been drafted to address concerns surrounding tampering during initial setup. Michael Flaxman expresses concerns about the BIP's failure to address verification of hardware wallets and risks for stateless hardware wallets. The proposal outlines the process for creating a multisig wallet using encryption. The coordinator generates key records and a descriptor record, which are encrypted and sent to all signers.The context provided includes discussions on multisig setup context, the need for devices to persist the descriptor, and the redundancy of BIP48 with descriptors. It is suggested that Shamir Secret Sharing could be used for encryption convention and a preference for plain text over binary. Multisig setup context is considered important for developing multisig setups.Bitcoin Secure Multisig Setup (BSMS) proposal introduces a Coordinator and multiple Signers in the setup process. The Coordinator takes the lead in initiating the multisig setup, determining the type of multisig used, and gathering information from the signers to generate a descriptor record. Signers are responsible for providing their XPUB to the Coordinator, verifying its inclusion in the descriptor record, and persisting the record in their storage.The setup process involves two rounds of communication. In round one, the Coordinator creates a multisig wallet creation session, generates a secret token, and shares it securely with all participating signers. The signers then generate a key record by prompting the user for the token and a derivation path. In round two, the Coordinator gathers key records from all signers, decrypts them using an encryption key, verifies the included signatures, and generates a descriptor record. The descriptor record is encrypted and sent to all signers.To ensure security during setup, the proposal recommends using multi-round Distributed Key Generation (DKG) with appropriate commitments and verification of components. It also suggests using encryption conventions for the descriptor data, allowing decryption with any of the seeds to access the full setup. Additional suggestions include using magic bytes for file extensions and plaintext files for human readability.One concern raised is losing multisig setup context, which could result in lost coins. If one device is lost in a 2-of-3 setup without metadata, the coins will be lost. To address this, the proposal recommends an encryption convention that allows decryption of the full setup file with any of the seeds. It also suggests ways to communicate signers' capabilities and extend the specification with path restrictions.The document highlights the importance - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Proposal-to-stop-processing-of-unrequested-transactions-in-Bitcoin-Core.xml b/static/bitcoin-dev/Feb_2021/combined_Proposal-to-stop-processing-of-unrequested-transactions-in-Bitcoin-Core.xml index f6c4f12b7c..e193b71363 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Proposal-to-stop-processing-of-unrequested-transactions-in-Bitcoin-Core.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Proposal-to-stop-processing-of-unrequested-transactions-in-Bitcoin-Core.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Proposal to stop processing of unrequested transactions in Bitcoin Core - 2023-08-02T03:08:43.541298+00:00 - - Antoine Riard 2021-02-12 11:49:42+00:00 - - - Pieter Wuille 2021-02-11 21:15:15+00:00 - - - Jeremy 2021-02-11 18:29:35+00:00 - - - Antoine Riard 2021-02-10 13:13:34+00:00 - + 2025-09-26T15:54:52.593091+00:00 + python-feedgen + + + [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core Antoine Riard + 2021-02-10T13:13:00.000Z + + + Jeremy + 2021-02-11T18:29:00.000Z + + + Pieter Wuille + 2021-02-11T21:15:00.000Z + + + Antoine Riard + 2021-02-12T11:49:00.000Z + + - python-feedgen + 2 Combined summary - Proposal to stop processing of unrequested transactions in Bitcoin Core - 2023-08-02T03:08:43.541298+00:00 + 2025-09-26T15:54:52.593763+00:00 - In an email exchange, Antoine and Pieter discuss the potential privacy implications of a proposed change regarding the discovery of a node's tx-relay topology. Antoine suggests that if an unrequested-tx peer is sending an attack, it likely learned the transaction from somewhere else, such as the tx owner. He also points out that the same outcome can already be achieved by sending an INV and observing if a GETDATA is replied back, which can help determine the presence of another peer with knowledge of the txid. Additionally, connecting to this other peer and waiting for an announcement can also provide insight. However, Pieter expresses concern about the privacy implications of the change and requests clarification on why it is not a concern.Antoine acknowledges the need for further study on the privacy properties of transaction announcements/requests, especially considering recent changes and upcoming Erlay changes. Despite this concern, Antoine fails to see how the proposed change would make it easier for attackers compared to the existing heuristics. The proposed change in Bitcoin Core 22.0+ involves stopping the processing of unrequested transactions at TX message reception. This change aims to reduce the CPU DoS surface of Bitcoin Core related to mempool acceptance. Currently, attackers can send expensive-to-validate junk transactions to a node through multiple inbound connections. The proposal would disrupt the tx-relay capabilities on the p2p network and require adaptation from certain Bitcoin clients who do not follow the INV/GETDATA sequence. However, a permissioned peer (PF_RELAY) would still be able to bypass these restrictions.An unrequested transaction refers to one for which a "getdata" message has not been previously issued by the node. Once the canonical INV/GETDATA sequence is enforced on the network, additional protection can be implemented, such as deprioritizing bandwidth and validation resources allocation or severing connections with DoSy peers. Some Bitcoin clients currently do not bother with the INV/GETDATA sequence, as raw TX message processing has always been tolerated by Core. Therefore, this change would impact their tx-relay capabilities on the p2p network and necessitate adaptation from them. Antoine hopes to gather feedback on this proposal and emphasizes the need for a sufficient window of time before the old tx-processing behavior becomes the minority. Feedback is particularly sought regarding whether this change is overly restrictive or implemented too quickly in Bitcoin software.Antoine's proposal aims to address the CPU DoS surface of Bitcoin Core by halting the processing of unrequested transactions at TX message reception. While privacy concerns are raised, Antoine believes that the proposed change does not make it easier for attackers compared to existing heuristics. The change would disrupt tx-relay capabilities on the p2p network and require adaptation from certain Bitcoin clients. Antoine welcomes feedback on the proposal's constraining nature and speed of implementation in Bitcoin software. 2021-02-12T11:49:42+00:00 + In an email exchange, Antoine and Pieter discuss the potential privacy implications of a proposed change regarding the discovery of a node's tx-relay topology. Antoine suggests that if an unrequested-tx peer is sending an attack, it likely learned the transaction from somewhere else, such as the tx owner. He also points out that the same outcome can already be achieved by sending an INV and observing if a GETDATA is replied back, which can help determine the presence of another peer with knowledge of the txid. Additionally, connecting to this other peer and waiting for an announcement can also provide insight. However, Pieter expresses concern about the privacy implications of the change and requests clarification on why it is not a concern.Antoine acknowledges the need for further study on the privacy properties of transaction announcements/requests, especially considering recent changes and upcoming Erlay changes. Despite this concern, Antoine fails to see how the proposed change would make it easier for attackers compared to the existing heuristics. The proposed change in Bitcoin Core 22.0+ involves stopping the processing of unrequested transactions at TX message reception. This change aims to reduce the CPU DoS surface of Bitcoin Core related to mempool acceptance. Currently, attackers can send expensive-to-validate junk transactions to a node through multiple inbound connections. The proposal would disrupt the tx-relay capabilities on the p2p network and require adaptation from certain Bitcoin clients who do not follow the INV/GETDATA sequence. However, a permissioned peer (PF_RELAY) would still be able to bypass these restrictions.An unrequested transaction refers to one for which a "getdata" message has not been previously issued by the node. Once the canonical INV/GETDATA sequence is enforced on the network, additional protection can be implemented, such as deprioritizing bandwidth and validation resources allocation or severing connections with DoSy peers. Some Bitcoin clients currently do not bother with the INV/GETDATA sequence, as raw TX message processing has always been tolerated by Core. Therefore, this change would impact their tx-relay capabilities on the p2p network and necessitate adaptation from them. Antoine hopes to gather feedback on this proposal and emphasizes the need for a sufficient window of time before the old tx-processing behavior becomes the minority. Feedback is particularly sought regarding whether this change is overly restrictive or implemented too quickly in Bitcoin software.Antoine's proposal aims to address the CPU DoS surface of Bitcoin Core by halting the processing of unrequested transactions at TX message reception. While privacy concerns are raised, Antoine believes that the proposed change does not make it easier for attackers compared to existing heuristics. The change would disrupt tx-relay capabilities on the p2p network and require adaptation from certain Bitcoin clients. Antoine welcomes feedback on the proposal's constraining nature and speed of implementation in Bitcoin software. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Straight-Flag-Day-Height-Taproot-Activation.xml b/static/bitcoin-dev/Feb_2021/combined_Straight-Flag-Day-Height-Taproot-Activation.xml index 777fcf3b1a..e6a2ce7488 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Straight-Flag-Day-Height-Taproot-Activation.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Straight-Flag-Day-Height-Taproot-Activation.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Straight Flag Day (Height) Taproot Activation - 2023-08-02T03:16:51.206553+00:00 - - eric at voskuil.org 2021-03-08 14:13:44+00:00 - - - Jorge Timón 2021-03-08 12:51:50+00:00 - - - Anthony Towns 2021-03-06 11:33:26+00:00 - - - Matt Corallo 2021-03-03 16:49:57+00:00 - - - Anthony Towns 2021-03-03 14:59:02+00:00 - - - Eric Voskuil 2021-02-28 20:38:13+00:00 - - - Matt Corallo 2021-02-28 20:25:15+00:00 - - - Matt Corallo 2021-02-28 20:20:56+00:00 - - - Eric Voskuil 2021-02-28 20:19:59+00:00 - - - Jeremy 2021-02-28 20:02:15+00:00 - - - Matt Corallo 2021-02-28 19:51:55+00:00 - - - Jeremy 2021-02-28 19:43:53+00:00 - - - Matt Corallo 2021-02-28 17:29:36+00:00 - - - Luke Dashjr 2021-02-28 17:20:05+00:00 - - - Matt Corallo 2021-02-28 16:45:22+00:00 - + 2025-09-26T15:54:50.475184+00:00 + python-feedgen + + + [bitcoin-dev] Straight Flag Day (Height) Taproot Activation Matt Corallo + 2021-02-28T16:45:00.000Z + + + Luke Dashjr + 2021-02-28T17:20:00.000Z + + + Matt Corallo + 2021-02-28T17:29:00.000Z + + + Jeremy + 2021-02-28T19:43:00.000Z + + + Matt Corallo + 2021-02-28T19:51:00.000Z + + + Jeremy + 2021-02-28T20:02:00.000Z + + + Eric Voskuil + 2021-02-28T20:19:00.000Z + + + Matt Corallo + 2021-02-28T20:20:00.000Z + + + Matt Corallo + 2021-02-28T20:25:00.000Z + + + Eric Voskuil + 2021-02-28T20:38:00.000Z + + + Anthony Towns + 2021-03-03T14:59:00.000Z + + + Matt Corallo + 2021-03-03T16:49:00.000Z + + + Anthony Towns + 2021-03-06T11:33:00.000Z + + + Jorge Timón + 2021-03-08T12:51:00.000Z + + + eric + 2021-03-08T14:13:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Straight Flag Day (Height) Taproot Activation - 2023-08-02T03:16:51.206553+00:00 + 2025-09-26T15:54:50.476859+00:00 - There is an ongoing debate among Bitcoin developers about the implementation of Taproot and how to activate it. One proposed solution is the "speedy trial" approach, which involves signaling before activation to establish community consensus. Another suggestion is to activate Taproot via a traditional flag day, allowing miners to signal uptake for taproot rules prior to activation. However, there are concerns about client compatibility and the potential for miners to generate invalid blocks. Discussions also revolve around the role of mandatory signaling versus a flag day and the need for careful planning and consideration when making changes to the Bitcoin network.The bitcoin-dev mailing list recently discussed the possibility of a mandatory signaling flag day for Taproot activation. Some members believe that a flag day would be simpler and easier to communicate than using activation parameters based on the percentage of upgraded nodes. However, there are concerns about network disruption and compatibility with early activation. The debate also touches on the BIP-8 protocol and whether early activation or a fixed activation date would be preferable.Despite these discussions, there is general agreement that a flag day might be the best option at this time. It is suggested that LOT=true could allow for compatibility with early activation if desired. Matt Corallo proposed a flag day activation for Taproot, but Luke Dashjr disagreed, emphasizing the importance of upgraded nodes across the network for successful activation. Dashjr also highlighted the risks of a LOT=False deployment and the complications it brings to the BIP 8 approach.Another proposal suggested activating Taproot through a traditional flag day with a set date in August 2022. However, Dashjr argued that this approach still has issues similar to BIP149, as it does not clearly indicate activation. He emphasized the need for high node-level adoption and warned against demanding alternative consensus rules or configuration flags.The ongoing debate and lack of consensus have likely delayed the release of Taproot activation. One suggestion to maintain consensus is to use a flag-day activation that meets certain criteria. The risk of hashpower loss can be mitigated by seeking commitment prior to release. Although a flag day activation has its own risks, it may be worth considering to avoid prolonged debate and delay.It is noted that Taproot activation has been in progress for a while, with no urgency until recently. Those seeking activation for market reasons should look forward to the event in 2022. Overall, the best course of action for Taproot activation is still under debate, considering factors such as network disruption, compatibility, and consensus among nodes. 2021-03-08T14:13:44+00:00 + There is an ongoing debate among Bitcoin developers about the implementation of Taproot and how to activate it. One proposed solution is the "speedy trial" approach, which involves signaling before activation to establish community consensus. Another suggestion is to activate Taproot via a traditional flag day, allowing miners to signal uptake for taproot rules prior to activation. However, there are concerns about client compatibility and the potential for miners to generate invalid blocks. Discussions also revolve around the role of mandatory signaling versus a flag day and the need for careful planning and consideration when making changes to the Bitcoin network.The bitcoin-dev mailing list recently discussed the possibility of a mandatory signaling flag day for Taproot activation. Some members believe that a flag day would be simpler and easier to communicate than using activation parameters based on the percentage of upgraded nodes. However, there are concerns about network disruption and compatibility with early activation. The debate also touches on the BIP-8 protocol and whether early activation or a fixed activation date would be preferable.Despite these discussions, there is general agreement that a flag day might be the best option at this time. It is suggested that LOT=true could allow for compatibility with early activation if desired. Matt Corallo proposed a flag day activation for Taproot, but Luke Dashjr disagreed, emphasizing the importance of upgraded nodes across the network for successful activation. Dashjr also highlighted the risks of a LOT=False deployment and the complications it brings to the BIP 8 approach.Another proposal suggested activating Taproot through a traditional flag day with a set date in August 2022. However, Dashjr argued that this approach still has issues similar to BIP149, as it does not clearly indicate activation. He emphasized the need for high node-level adoption and warned against demanding alternative consensus rules or configuration flags.The ongoing debate and lack of consensus have likely delayed the release of Taproot activation. One suggestion to maintain consensus is to use a flag-day activation that meets certain criteria. The risk of hashpower loss can be mitigated by seeking commitment prior to release. Although a flag day activation has its own risks, it may be worth considering to avoid prolonged debate and delay.It is noted that Taproot activation has been in progress for a while, with no urgency until recently. Those seeking activation for market reasons should look forward to the event in 2022. Overall, the best course of action for Taproot activation is still under debate, considering factors such as network disruption, compatibility, and consensus among nodes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Taproot-NACK.xml b/static/bitcoin-dev/Feb_2021/combined_Taproot-NACK.xml index 3a84b085c3..c4eebd6d2c 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Taproot-NACK.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Taproot-NACK.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Taproot NACK - 2023-08-02T03:14:03.702616+00:00 + 2025-09-26T15:54:56.864439+00:00 + python-feedgen DA Williamson 2021-03-18 01:10:38+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - Taproot NACK - 2023-08-02T03:14:03.702616+00:00 + 2025-09-26T15:54:56.864655+00:00 - The email thread on the bitcoin-dev mailing list revolves around discussions about privacy concerns related to Bitcoin transactions and the proposed Taproot protocol change. LORD HIS EXCELLENCY JAMES HRMH expresses concerns about increased privacy and potential obfuscation of transactions, which could lead to government bans. However, other members argue that Taproot does not increase privacy beyond current techniques like coinjoin, payjoin, and lightning. The importance of maintaining transparency in the blockchain while still allowing for privacy is emphasized.The conversation also touches on the affiliation of LORD HIS EXCELLENCY JAMES HRMH with a Bitcoin mixer service, raising questions about their motivations and potential conflicts of interest. The need for proper disclosure when discussing transaction privacy is highlighted.Another member named Damian A. James Williamson, associated with Willtech, shares contact information but does not provide specific advice or information about projects. The intention behind the email is unclear.The debate centers around striking a balance between privacy and security with transparency and accountability in Bitcoin transactions. Various perspectives are shared, including the value proposition of Bitcoin, the availability of privacy suitable for cash, and the implications of obfuscating transactions on government bans.Overall, the email thread covers topics such as consensus, censorship resistance, fraud prevention, privacy techniques, and the presence of a disruptive troll on the bitcoin-dev mailing list. It provides insights into various perspectives and approaches within the Bitcoin community. 2021-03-18T01:10:38+00:00 + The email thread on the bitcoin-dev mailing list revolves around discussions about privacy concerns related to Bitcoin transactions and the proposed Taproot protocol change. LORD HIS EXCELLENCY JAMES HRMH expresses concerns about increased privacy and potential obfuscation of transactions, which could lead to government bans. However, other members argue that Taproot does not increase privacy beyond current techniques like coinjoin, payjoin, and lightning. The importance of maintaining transparency in the blockchain while still allowing for privacy is emphasized.The conversation also touches on the affiliation of LORD HIS EXCELLENCY JAMES HRMH with a Bitcoin mixer service, raising questions about their motivations and potential conflicts of interest. The need for proper disclosure when discussing transaction privacy is highlighted.Another member named Damian A. James Williamson, associated with Willtech, shares contact information but does not provide specific advice or information about projects. The intention behind the email is unclear.The debate centers around striking a balance between privacy and security with transparency and accountability in Bitcoin transactions. Various perspectives are shared, including the value proposition of Bitcoin, the availability of privacy suitable for cash, and the implications of obfuscating transactions on government bans.Overall, the email thread covers topics such as consensus, censorship resistance, fraud prevention, privacy techniques, and the presence of a disruptive troll on the bitcoin-dev mailing list. It provides insights into various perspectives and approaches within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Taproot-activation-meeting-2-Tuesday-16th-February-19-00-UTC.xml b/static/bitcoin-dev/Feb_2021/combined_Taproot-activation-meeting-2-Tuesday-16th-February-19-00-UTC.xml index f531ae09c3..ef042eb2e4 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Taproot-activation-meeting-2-Tuesday-16th-February-19-00-UTC.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Taproot-activation-meeting-2-Tuesday-16th-February-19-00-UTC.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC - 2023-08-02T03:04:07.963790+00:00 - - Luke Dashjr 2021-02-28 19:45:23+00:00 - - - David A. Harding 2021-02-13 16:32:57+00:00 - - - Michael Folkson 2021-02-05 12:43:57+00:00 - + 2025-09-26T15:54:58.982944+00:00 + python-feedgen + + + [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC Michael Folkson + 2021-02-05T12:43:00.000Z + + + David A. Harding + 2021-02-13T16:32:00.000Z + + + Luke Dashjr + 2021-02-28T19:45:00.000Z + + - python-feedgen + 2 Combined summary - Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC - 2023-08-02T03:04:07.963790+00:00 + 2025-09-26T15:54:58.983499+00:00 - The ongoing debate on whether to activate Taproot with LOT (LockinOnTimeout) set to true or false has sparked arguments from both sides. Those against setting LOT=false argue that it poses a risk by forcing the community to place extra trust in miners, as there is a small probability that Taproot may not be activated by them. This could also set a precedent that miners cannot be relied upon to activate soft forks, even if there is overwhelming community consensus. The worst-case scenario would be waiting over a year for Taproot to be activated, but redeployment could lead to confusion among users who have already upgraded once.On the other hand, proponents of LOT=true argue that it sets clear expectations for miners and allows them to cooperate as they do day-to-day. They believe that claims of being "forced" to accept the soft fork are baseless, as BIP 8 provides an easy way for people to reject it if they don't like it. They emphasize that any deployment, including the status quo, can be spun negatively, so objective criteria should be considered. Additionally, they note that developers releasing software is not enough; the community must actively choose to run the software and accept the protocol change.In a recent discussion on Reddit, users raised points related to Taproot activation pools. One user argued that avoiding rules that harm users is more important than quickly deploying new useful rules. Another user highlighted the importance of defaulting to LOT=false, as it allows for non-activation even if people run the code provided by developers. This supports the decentralized ethos of Bitcoin and reduces the chance of unwanted changes being pressured onto developers. They also noted that Bitcoin Core being free software gives users the right to modify, run, and share additional copies, which demonstrates their ability to resist changes if necessary.The Taproot activation meeting took place on February 3rd, and another meeting has been scheduled for February 16th. The main topic of discussion is whether to set LOT to true or false in a Bitcoin Core release. Arguments for LOT=true include eliminating the risk of Taproot failing to activate within a year, avoiding confusion among users, and not forcing them to change LOT. Arguments for LOT=false highlight the small probability of non-activation by miners, the precedence it sets if miners fail to activate despite community consensus, and the importance of avoiding rules harmful to users. Other parameters, such as activation threshold and start time, will also be discussed. It is important to note that the discussion on LOT should not derail the overwhelming consensus that Taproot will be activated this year. 2021-02-28T19:45:23+00:00 + The ongoing debate on whether to activate Taproot with LOT (LockinOnTimeout) set to true or false has sparked arguments from both sides. Those against setting LOT=false argue that it poses a risk by forcing the community to place extra trust in miners, as there is a small probability that Taproot may not be activated by them. This could also set a precedent that miners cannot be relied upon to activate soft forks, even if there is overwhelming community consensus. The worst-case scenario would be waiting over a year for Taproot to be activated, but redeployment could lead to confusion among users who have already upgraded once.On the other hand, proponents of LOT=true argue that it sets clear expectations for miners and allows them to cooperate as they do day-to-day. They believe that claims of being "forced" to accept the soft fork are baseless, as BIP 8 provides an easy way for people to reject it if they don't like it. They emphasize that any deployment, including the status quo, can be spun negatively, so objective criteria should be considered. Additionally, they note that developers releasing software is not enough; the community must actively choose to run the software and accept the protocol change.In a recent discussion on Reddit, users raised points related to Taproot activation pools. One user argued that avoiding rules that harm users is more important than quickly deploying new useful rules. Another user highlighted the importance of defaulting to LOT=false, as it allows for non-activation even if people run the code provided by developers. This supports the decentralized ethos of Bitcoin and reduces the chance of unwanted changes being pressured onto developers. They also noted that Bitcoin Core being free software gives users the right to modify, run, and share additional copies, which demonstrates their ability to resist changes if necessary.The Taproot activation meeting took place on February 3rd, and another meeting has been scheduled for February 16th. The main topic of discussion is whether to set LOT to true or false in a Bitcoin Core release. Arguments for LOT=true include eliminating the risk of Taproot failing to activate within a year, avoiding confusion among users, and not forcing them to change LOT. Arguments for LOT=false highlight the small probability of non-activation by miners, the precedence it sets if miners fail to activate despite community consensus, and the importance of avoiding rules harmful to users. Other parameters, such as activation threshold and start time, will also be discussed. It is important to note that the discussion on LOT should not derail the overwhelming consensus that Taproot will be activated this year. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Teleport-Transactions-A-CoinSwap-implementation-for-Bitcoin.xml b/static/bitcoin-dev/Feb_2021/combined_Teleport-Transactions-A-CoinSwap-implementation-for-Bitcoin.xml index 64da66ce9f..cbd294ce9a 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Teleport-Transactions-A-CoinSwap-implementation-for-Bitcoin.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Teleport-Transactions-A-CoinSwap-implementation-for-Bitcoin.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Teleport Transactions: A CoinSwap implementation for Bitcoin - 2023-08-02T03:12:41.195522+00:00 - - Herman Puller 2021-02-21 23:28:44+00:00 - - - Chris Belcher 2021-02-17 22:27:28+00:00 - + 2025-09-26T15:55:14.056225+00:00 + python-feedgen + + + [bitcoin-dev] Teleport Transactions: A CoinSwap implementation for Bitcoin Chris Belcher + 2021-02-17T22:27:00.000Z + + + Herman Puller + 2021-02-21T23:28:00.000Z + + - python-feedgen + 2 Combined summary - Teleport Transactions: A CoinSwap implementation for Bitcoin - 2023-08-02T03:12:41.195522+00:00 + 2025-09-26T15:55:14.056713+00:00 - A new privacy improvement called CoinSwap has been developed for Bitcoin transactions. It allows users to create a special kind of transaction that appears completely normal with the coins seemingly going from one address to another, but in reality, they end up in an entirely unconnected address. This privacy improvement is incredibly valuable in a world where advertisers and social media companies want to collect user data.CoinSwap can be implemented as a standalone app or a library that existing wallets can adopt to send Bitcoin transactions with much greater privacy. The project can create multi-transaction CoinSwaps and multi-hop CoinSwaps to avoid amount correlation and prevent a single maker from being able to unmix a taker's CoinSwap.In this process, a user, called the taker, organizes the whole thing and decides what the CoinSwap amount should be, which makers to route over depending on their fees, how many transactions, and makers there would be. Makers follow the protocol and collect their CoinSwap fees without knowing their position in the route. The taker pays a fee to each maker to incentivize them to keep the software running.A passive observer of the blockchain cannot distinguish between a single-hop CoinSwap and a multi-hop CoinSwap, making it a more private alternative to CoinJoin. However, the project is still a work in progress, and all kinds of attacks are possible right now, so it shouldn't be used on mainnet with real money yet.The CoinSwap addresses created by the project appear as 2-of-2 multisignature addresses, but the plan is to use ECDSA-2P to make them look the same as regular single-signature addresses before improving privacy and fungibility massively. CoinSwap is considered the next generation of Bitcoin on-chain privacy tech, which not only improves privacy and increases fungibility but also uses less block space and is cheaper in miner fees. 2021-02-21T23:28:44+00:00 + A new privacy improvement called CoinSwap has been developed for Bitcoin transactions. It allows users to create a special kind of transaction that appears completely normal with the coins seemingly going from one address to another, but in reality, they end up in an entirely unconnected address. This privacy improvement is incredibly valuable in a world where advertisers and social media companies want to collect user data.CoinSwap can be implemented as a standalone app or a library that existing wallets can adopt to send Bitcoin transactions with much greater privacy. The project can create multi-transaction CoinSwaps and multi-hop CoinSwaps to avoid amount correlation and prevent a single maker from being able to unmix a taker's CoinSwap.In this process, a user, called the taker, organizes the whole thing and decides what the CoinSwap amount should be, which makers to route over depending on their fees, how many transactions, and makers there would be. Makers follow the protocol and collect their CoinSwap fees without knowing their position in the route. The taker pays a fee to each maker to incentivize them to keep the software running.A passive observer of the blockchain cannot distinguish between a single-hop CoinSwap and a multi-hop CoinSwap, making it a more private alternative to CoinJoin. However, the project is still a work in progress, and all kinds of attacks are possible right now, so it shouldn't be used on mainnet with real money yet.The CoinSwap addresses created by the project appear as 2-of-2 multisignature addresses, but the plan is to use ECDSA-2P to make them look the same as regular single-signature addresses before improving privacy and fungibility massively. CoinSwap is considered the next generation of Bitcoin on-chain privacy tech, which not only improves privacy and increases fungibility but also uses less block space and is cheaper in miner fees. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-IRC.xml b/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-IRC.xml index be0ea72d06..071f2569ac 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-IRC.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-IRC.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Yesterday's Taproot activation meeting on IRC - 2023-08-02T03:03:26.764149+00:00 - - Michael Folkson 2021-04-14 11:58:58+00:00 - - - Michael Folkson 2021-02-03 14:24:59+00:00 - + 2025-09-26T15:54:46.208437+00:00 + python-feedgen + + + Michael Folkson + 2021-02-03T14:24:00.000Z + + + [bitcoin-dev] Yesterday's Taproot activation meeting on IRC Michael Folkson + 2021-04-14T11:58:00.000Z + + - python-feedgen + 2 Combined summary - Yesterday's Taproot activation meeting on IRC - 2023-08-02T03:03:26.764149+00:00 + 2025-09-26T15:54:46.208908+00:00 - Yesterday, a Taproot activation meeting was held on the ##taproot-activation Freenode channel. The agenda for the meeting was posted in advance on the mailing list by BitcoinMechanic. The conversation log from the meeting is available on gnusha.org. During the meeting, participants discussed an alternative release to Bitcoin Core with Speedy Trial as the activation mechanism, followed by BIP 8. However, there were concerns raised about having "Bitcoin Core" in the name of the alternative release, as it could confuse users and make them think it was approved by Bitcoin Core maintainers.The draft release notes for this alternative release can be found on Google Docs, and the GitHub repository is available on BitcoinActivation's GitHub page. In comparison, Bitcoin Core is considering Core PR #21377 for merge, which proposes using Speedy Trial as the activation mechanism with a mix of block height and MTP. A BIP PR has also been opened for the Core release, suggesting finalized parameters. However, if these plans continue, Bitcoin Core and the alternative release may not be entirely compatible due to differences in startheight and timeout definitions.While both Bitcoin Core and the alternative release should activate at the same block height in most cases, there are potential edge cases where one activates and the other doesn't. The use of MTP in Speedy Trial for Bitcoin Core has been extensively discussed, and opinions from reviewers are summarized in a GitHub comment. It is worth noting that anyone can host a meeting on the ##taproot-activation channel by contacting Michael Folkson to book a time slot and posting an agenda in advance on the mailing list. The meeting host has the authority to issue warnings and, if necessary, remove disruptive participants who divert from the agenda.On February 2nd, an open meeting was held on IRC to discuss Taproot activation. This meeting was previously announced on a Linux Foundation mailing list. The conversation log from the meeting is available online for those who are interested. Rusty Russell provided his takeaways from the meeting, which included unanimous support for BIP 8 and overwhelming consensus that a one-year timeout is appropriate. While there was majority consensus for lockinontimeout false, some individuals, such as Luke Dashjr, opposed it. No decision was made regarding the start time.Following the meeting, two BIP 8 PRs were merged in response to an observation by Jonas Nick that without them, nodes could end up on the wrong chain. Bitcoin Core PR #19573 still requires further review before it can be considered for merging. A follow-up meeting will be organized in the format of John Newbery’s Bitcoin Core PR review club.In other news, Chun Wang, co-founder of F2Pool with approximately 16% of global hash rate, announced support for BIP 8 (false, 1 year) according to an update on taprootactivation.com by Alejandro De La Torre. 2021-04-14T11:58:58+00:00 + Yesterday, a Taproot activation meeting was held on the ##taproot-activation Freenode channel. The agenda for the meeting was posted in advance on the mailing list by BitcoinMechanic. The conversation log from the meeting is available on gnusha.org. During the meeting, participants discussed an alternative release to Bitcoin Core with Speedy Trial as the activation mechanism, followed by BIP 8. However, there were concerns raised about having "Bitcoin Core" in the name of the alternative release, as it could confuse users and make them think it was approved by Bitcoin Core maintainers.The draft release notes for this alternative release can be found on Google Docs, and the GitHub repository is available on BitcoinActivation's GitHub page. In comparison, Bitcoin Core is considering Core PR #21377 for merge, which proposes using Speedy Trial as the activation mechanism with a mix of block height and MTP. A BIP PR has also been opened for the Core release, suggesting finalized parameters. However, if these plans continue, Bitcoin Core and the alternative release may not be entirely compatible due to differences in startheight and timeout definitions.While both Bitcoin Core and the alternative release should activate at the same block height in most cases, there are potential edge cases where one activates and the other doesn't. The use of MTP in Speedy Trial for Bitcoin Core has been extensively discussed, and opinions from reviewers are summarized in a GitHub comment. It is worth noting that anyone can host a meeting on the ##taproot-activation channel by contacting Michael Folkson to book a time slot and posting an agenda in advance on the mailing list. The meeting host has the authority to issue warnings and, if necessary, remove disruptive participants who divert from the agenda.On February 2nd, an open meeting was held on IRC to discuss Taproot activation. This meeting was previously announced on a Linux Foundation mailing list. The conversation log from the meeting is available online for those who are interested. Rusty Russell provided his takeaways from the meeting, which included unanimous support for BIP 8 and overwhelming consensus that a one-year timeout is appropriate. While there was majority consensus for lockinontimeout false, some individuals, such as Luke Dashjr, opposed it. No decision was made regarding the start time.Following the meeting, two BIP 8 PRs were merged in response to an observation by Jonas Nick that without them, nodes could end up on the wrong chain. Bitcoin Core PR #19573 still requires further review before it can be considered for merging. A follow-up meeting will be organized in the format of John Newbery’s Bitcoin Core PR review club.In other news, Chun Wang, co-founder of F2Pool with approximately 16% of global hash rate, announced support for BIP 8 (false, 1 year) according to an update on taprootactivation.com by Alejandro De La Torre. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml b/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml index 79e0e1aa76..2d356a0699 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Yesterday's Taproot activation meeting on lockinontimeout (LOT) - 2023-08-02T03:10:33.543115+00:00 + 2025-09-26T15:55:03.334011+00:00 + python-feedgen Ariel Lorenzo-Luaces 2021-03-02 18:32:00+00:00 @@ -171,13 +172,13 @@ - python-feedgen + 2 Combined summary - Yesterday's Taproot activation meeting on lockinontimeout (LOT) - 2023-08-02T03:10:33.543115+00:00 + 2025-09-26T15:55:03.334231+00:00 - The Bitcoin community is currently engaged in discussions about the activation of Taproot, a proposed soft-fork upgrade for the network. The activation method itself has raised concerns about the risk of chain splits and the potential impact on consensus. One suggestion to minimize this risk is to release a version of Bitcoin Core that requires users to choose between activating Taproot with LOT=true or LOT=false. However, there are debates about whether giving miners too much control over consensus could set a problematic precedent.Bitcoin Core developer Matt Corallo emphasized the long-standing policy of not including options that could harm users, explaining that the role of Bitcoin Core developers is to recommend technically sound and consensus-supported courses of action. While users are free to run their own software, he doesn't anticipate that the minority advocating for certain options on platforms like Twitter will have sufficient influence to sustain their choices if they find themselves on a chain with no blocks.The ongoing debate on the activation mechanism for Taproot includes discussions about whether to set the lock-in on timeout (LOT) parameter to true or false. Various viewpoints have been expressed, with some participants arguing for LOT=true and others suggesting LOT=false. Michael Folkson, who summarized the outcomes of a Taproot activation meeting, concluded that there was no overwhelming consensus but noted stronger opposition to LOT=true from Bitcoin Core contributors and Lightning developers. Based on this, he recommended proposing LOT=false as the activation parameter.However, the decision-making process is still ongoing, and code review of the Bitcoin Core PR #19573 is scheduled for February 23rd. While there are diverging opinions on the best course of action, the goal remains to activate Taproot as early as possible while minimizing risks and ensuring broad consensus within the Bitcoin community.It's worth noting that an activation mechanism is a consensus change that can be contentious. Therefore, it's important to engage in open discussions and prepare for different scenarios without being antagonistic or destructive. The Bitcoin community aims to find a resolution that aligns with the collective interest and avoids detrimental outcomes.The activation of Taproot has sparked debates within the Bitcoin community. Some members suggest setting LOT=false to minimize the risk, while others propose allowing users to make the choice themselves. There is disagreement on which option is safer, with arguments made for both LOT=true and LOT=false.During a recent meeting on Taproot activation, there was majority support for LOT=false over LOT=true. However, concerns were raised about the representativeness of the meeting, as only around 100 people attended. Despite this, it is recommended to propose LOT=false in order to finalize Taproot activation parameters and propose them to the community.It is emphasized that users are not forced to upgrade to any particular software version, and there is a possibility that only a small number of people will run LOT=true while others delay their upgrade. The goal is to avoid a chain split and falling out of consensus.The Bitcoin community acknowledges the importance of open discussions and preparation for worst-case scenarios in order to build secure systems. A code review of Bitcoin Core PR #19573 is scheduled, and participants are thanked for engaging productively and in good faith.Overall, the Bitcoin community is actively discussing the activation of Taproot and considering the potential risks and benefits. The debate centers around whether to set LOT to true or false, with arguments made for both options. The community aims to reach a consensus and activate Taproot in a way that minimizes risks and ensures the long-term growth and security of the ecosystem.The ongoing debate on the activation of Taproot continues, with different perspectives on the implementation and consensus rules. Software complexity and infrastructure limitations have been raised as challenges. The proposal for a LOT=true option in Bitcoin Core has faced opposition, leading to the recommendation of proposing LOT=false. Communication, agreement, and avoiding forced-signaling via forks are emphasized. Multiple forks and alternative implementations are suggested to enhance decentralization. The aim is to activate Taproot as early as possible while considering consensus and technical soundness.In the recent meeting on Taproot activation, arguments for both LOT=true and LOT=false were discussed. While there was no overwhelming consensus, there was more opposition against LOT=true among Bitcoin Core contributors, Lightning developers, and other community members. Some mining pools expressed a preference for LOT=false. It was decided to propose LOT=false at this time, considering the aim of activating the Taproot soft fork as early as possible.Matt Corallo emphasized the importance of communication and agreement in the activation process. He suggested that if there is broad consensus for Taproot but some miners fail to upgrade, a flag day activation could be considered instead of a UASF/BIP8-style fork, which carries additional risks. The tradeoffs of a BIP8(false, ∞) option were also discussed, with suggestions for maintaining multiple forks of Bitcoin Core to enhance decentralization.The practicality of implementing a LOT=false option in Bitcoin Core was questioned due to the software complexity involved. Bitcoin Core's long-standing policy is not to ship options that 2021-03-02T18:32:00+00:00 + The Bitcoin community is currently engaged in discussions about the activation of Taproot, a proposed soft-fork upgrade for the network. The activation method itself has raised concerns about the risk of chain splits and the potential impact on consensus. One suggestion to minimize this risk is to release a version of Bitcoin Core that requires users to choose between activating Taproot with LOT=true or LOT=false. However, there are debates about whether giving miners too much control over consensus could set a problematic precedent.Bitcoin Core developer Matt Corallo emphasized the long-standing policy of not including options that could harm users, explaining that the role of Bitcoin Core developers is to recommend technically sound and consensus-supported courses of action. While users are free to run their own software, he doesn't anticipate that the minority advocating for certain options on platforms like Twitter will have sufficient influence to sustain their choices if they find themselves on a chain with no blocks.The ongoing debate on the activation mechanism for Taproot includes discussions about whether to set the lock-in on timeout (LOT) parameter to true or false. Various viewpoints have been expressed, with some participants arguing for LOT=true and others suggesting LOT=false. Michael Folkson, who summarized the outcomes of a Taproot activation meeting, concluded that there was no overwhelming consensus but noted stronger opposition to LOT=true from Bitcoin Core contributors and Lightning developers. Based on this, he recommended proposing LOT=false as the activation parameter.However, the decision-making process is still ongoing, and code review of the Bitcoin Core PR #19573 is scheduled for February 23rd. While there are diverging opinions on the best course of action, the goal remains to activate Taproot as early as possible while minimizing risks and ensuring broad consensus within the Bitcoin community.It's worth noting that an activation mechanism is a consensus change that can be contentious. Therefore, it's important to engage in open discussions and prepare for different scenarios without being antagonistic or destructive. The Bitcoin community aims to find a resolution that aligns with the collective interest and avoids detrimental outcomes.The activation of Taproot has sparked debates within the Bitcoin community. Some members suggest setting LOT=false to minimize the risk, while others propose allowing users to make the choice themselves. There is disagreement on which option is safer, with arguments made for both LOT=true and LOT=false.During a recent meeting on Taproot activation, there was majority support for LOT=false over LOT=true. However, concerns were raised about the representativeness of the meeting, as only around 100 people attended. Despite this, it is recommended to propose LOT=false in order to finalize Taproot activation parameters and propose them to the community.It is emphasized that users are not forced to upgrade to any particular software version, and there is a possibility that only a small number of people will run LOT=true while others delay their upgrade. The goal is to avoid a chain split and falling out of consensus.The Bitcoin community acknowledges the importance of open discussions and preparation for worst-case scenarios in order to build secure systems. A code review of Bitcoin Core PR #19573 is scheduled, and participants are thanked for engaging productively and in good faith.Overall, the Bitcoin community is actively discussing the activation of Taproot and considering the potential risks and benefits. The debate centers around whether to set LOT to true or false, with arguments made for both options. The community aims to reach a consensus and activate Taproot in a way that minimizes risks and ensures the long-term growth and security of the ecosystem.The ongoing debate on the activation of Taproot continues, with different perspectives on the implementation and consensus rules. Software complexity and infrastructure limitations have been raised as challenges. The proposal for a LOT=true option in Bitcoin Core has faced opposition, leading to the recommendation of proposing LOT=false. Communication, agreement, and avoiding forced-signaling via forks are emphasized. Multiple forks and alternative implementations are suggested to enhance decentralization. The aim is to activate Taproot as early as possible while considering consensus and technical soundness.In the recent meeting on Taproot activation, arguments for both LOT=true and LOT=false were discussed. While there was no overwhelming consensus, there was more opposition against LOT=true among Bitcoin Core contributors, Lightning developers, and other community members. Some mining pools expressed a preference for LOT=false. It was decided to propose LOT=false at this time, considering the aim of activating the Taproot soft fork as early as possible.Matt Corallo emphasized the importance of communication and agreement in the activation process. He suggested that if there is broad consensus for Taproot but some miners fail to upgrade, a flag day activation could be considered instead of a UASF/BIP8-style fork, which carries additional risks. The tradeoffs of a BIP8(false, ∞) option were also discussed, with suggestions for maintaining multiple forks of Bitcoin Core to enhance decentralization.The practicality of implementing a LOT=false option in Bitcoin Core was questioned due to the software complexity involved. Bitcoin Core's long-standing policy is not to ship options that - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2021/combined_bip48-proposal.xml b/static/bitcoin-dev/Feb_2021/combined_bip48-proposal.xml index 8efaeb1de9..8462bb99aa 100644 --- a/static/bitcoin-dev/Feb_2021/combined_bip48-proposal.xml +++ b/static/bitcoin-dev/Feb_2021/combined_bip48-proposal.xml @@ -1,38 +1,19 @@ - + 2 Combined summary - bip48 proposal - 2023-08-02T02:57:59.641543+00:00 - - Craig Raw 2021-02-25 10:23:59+00:00 - - - dentondevelopment 2021-02-24 14:02:00+00:00 - - - Luke Dashjr 2020-12-18 04:08:30+00:00 - - - dentondevelopment 2020-12-18 01:49:07+00:00 - - - dentondevelopment 2020-12-18 01:44:27+00:00 - - - Pavol Rusnak 2020-12-17 10:58:08+00:00 - - - Keagan McClelland 2020-12-16 18:48:30+00:00 - - - Luke Dashjr 2020-12-16 17:16:54+00:00 - - - dentondevelopment 2020-12-16 14:10:28+00:00 - - - dentondevelopment 2020-12-16 12:43:58+00:00 - + 2025-09-26T15:55:05.447969+00:00 + python-feedgen + + + dentondevelopment + 2021-02-24T14:02:00.000Z + + + Craig Raw + 2021-02-25T10:23:00.000Z + + @@ -43,13 +24,13 @@ - python-feedgen + 2 Combined summary - bip48 proposal - 2023-08-02T02:57:59.641543+00:00 + 2025-09-26T15:55:05.448472+00:00 - A proposal for a new Bitcoin Improvement Proposal (BIP) called bip48 has been put forward by Fontaine. The purpose of this BIP is to document modern multi-sig derivations and provide clarity on the usage of 48 paths. The proposal draws inspiration from bip44 and aims to define an already existing standard used in practice across multi-sig wallets. However, some key points have been raised during discussions, such as not defining a `script_type` as a path level and including a defined "wild card" in the script_type level to accommodate future address types.Fontaine has created a pull request (PR) for the proposed bip48, allowing anyone to easily comment and raise concerns. The community feedback has been positive, with other developers expressing support for the proposal. The proposal is still a work in progress, and Fontaine is incorporating feedback from Pavol Rusnak and others before sharing the next draft.In response to the proposal, Luke Dashjr reminded Fontaine not to self-assign BIP numbers and asked about compatibility with another pull request. Fontaine clarified that they had only received guidance from the README and suggested that bip48 would be fitting if it remained unused. The communication regarding the proposal took place through email, using ProtonMail for secure communication.Pavol Rusnak, co-founder and CTO of SatoshiLabs, commended Fontaine's effort in proposing bip48 and pointed out that their documentation of 48 path usage also includes script_type=0 for raw BIP-11 multisig. They suggested that this should be included in the proposed BIP as well. Fontaine expressed gratitude for the link provided by Pavol Rusnak and welcomed comments and input on the proposed bip48.The proposal and discussions surrounding bip48 were shared through email threads on the bitcoin-dev mailing list. The proposal was initially shared via a static link and later through a GitHub repository, where others could provide comments and suggestions. It should be noted that self-assigning BIP numbers is not allowed, and the compatibility of bip48 with another pull request remains unclear.In summary, Fontaine has proposed bip48 as a BIP to document modern multi-sig derivations. The proposal aims to define an existing standard used in multi-sig wallets, with a focus on p2sh-p2wsh and p2wsh derivations. Feedback and support from the community have been positive, and Fontaine is incorporating feedback before sharing the next draft. The proposal and discussions have taken place through email threads and a GitHub repository, ensuring secure communication. 2021-02-25T10:23:59+00:00 + A proposal for a new Bitcoin Improvement Proposal (BIP) called bip48 has been put forward by Fontaine. The purpose of this BIP is to document modern multi-sig derivations and provide clarity on the usage of 48 paths. The proposal draws inspiration from bip44 and aims to define an already existing standard used in practice across multi-sig wallets. However, some key points have been raised during discussions, such as not defining a `script_type` as a path level and including a defined "wild card" in the script_type level to accommodate future address types.Fontaine has created a pull request (PR) for the proposed bip48, allowing anyone to easily comment and raise concerns. The community feedback has been positive, with other developers expressing support for the proposal. The proposal is still a work in progress, and Fontaine is incorporating feedback from Pavol Rusnak and others before sharing the next draft.In response to the proposal, Luke Dashjr reminded Fontaine not to self-assign BIP numbers and asked about compatibility with another pull request. Fontaine clarified that they had only received guidance from the README and suggested that bip48 would be fitting if it remained unused. The communication regarding the proposal took place through email, using ProtonMail for secure communication.Pavol Rusnak, co-founder and CTO of SatoshiLabs, commended Fontaine's effort in proposing bip48 and pointed out that their documentation of 48 path usage also includes script_type=0 for raw BIP-11 multisig. They suggested that this should be included in the proposed BIP as well. Fontaine expressed gratitude for the link provided by Pavol Rusnak and welcomed comments and input on the proposed bip48.The proposal and discussions surrounding bip48 were shared through email threads on the bitcoin-dev mailing list. The proposal was initially shared via a static link and later through a GitHub repository, where others could provide comments and suggestions. It should be noted that self-assigning BIP numbers is not allowed, and the compatibility of bip48 with another pull request remains unclear.In summary, Fontaine has proposed bip48 as a BIP to document modern multi-sig derivations. The proposal aims to define an existing standard used in multi-sig wallets, with a focus on p2sh-p2wsh and p2wsh derivations. Feedback and support from the community have been positive, and Fontaine is incorporating feedback before sharing the next draft. The proposal and discussions have taken place through email threads and a GitHub repository, ensuring secure communication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml b/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml index fb66bb5e13..9de6d20b16 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml @@ -2,7 +2,7 @@ 2 Combined summary - Decentralized BIP 47 payment code directory - 2025-09-26T14:40:41.649915+00:00 + 2025-09-26T16:02:59.788263+00:00 python-feedgen Prayank 2022-03-02 04:45:58+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Decentralized BIP 47 payment code directory - 2025-09-26T14:40:41.650037+00:00 + 2025-09-26T16:02:59.788506+00:00 2022-03-02T04:45:58+00:00 In a conversation between Peter and Prayank, Prayank introduces a newer version (v3 and v4) of BIP47, which has been proposed on GitHub. This version aims to solve the toxic change issue and seems like an improvement. Prayank explains that using an xpub does not provide anonymity because anyone who has access to the xpub, including platforms or hackers, can identify one's payments. However, using a payment code allows for public association without revealing the payment identifier on the blockchain, making it difficult for others to determine if funds have been received. Prayank also suggests a rust library that can assist application developers in implementing BIP47 into different bitcoin projects.The OpenBitcoinPrivacyProject has proposed a newer version of BIP47, v3 and v4, which addresses certain issues present in the previous version. The new version eliminates the toxic change issue by modifying the notification from Alice to Bob as a transaction from Alice to herself, functioning as a bare 1 of 3 multisig. Two pubkeys represent Alice's payment code and Bob's payment identifier. This change incurs a one-time overhead of 64 bytes for the two pubkeys, which is spread out over the lifespan of the relationship between Alice and Bob. Additionally, the first economic payment from Alice to Bob can be included with the notification transaction. Payment codes can be recovered from the bip32 seed without requiring extra backups. The new version is already being used in production with Samourai wallet. BIP47 v3 enables Alice to receive Bob's address without exposing her IP/identity to Charlie. Charlie can observe Alice receiving the payment code material from Bob but cannot determine if Alice proceeded to make a payment to Bob. Unlike an xpub, this method ensures privacy even if the xpub is shared with a crowdfunding platform, as the platform or any potential hackers cannot identify the payments made by Alice. By using the payment code, individuals can publicly associate themselves with their payment code without revealing if they have received funds, as the payment code is not visible on the blockchain.Twitter has seen discussions about BIP47 and its potential to enhance privacy. However, some developers argue that it merely adds spam to the Bitcoin network without providing any actual improvements. Additionally, the only existing implementation of BIP47 is Paynym, a centralized payment code directory managed by Samourai wallet, raising concerns regarding privacy and security. To address these concerns, the author suggests utilizing TXT records and domains. They present a proof of concept using GNS (GNU Name Service) to create a payment code for Alice, adding it as a TXT record with an expiry date, and verifying it. The author also proposes using `gnunet-publish` as a replacement for notification transactions. These solutions could potentially help users avoid sharing their bitcoin addresses on social media platforms when receiving donations. In addition to these suggestions, the author provides links to related resources, including a Q&A on accepting donations correctly and a new proposal addressing privacy concerns. diff --git a/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml b/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml index 0e01bde80c..21960fb29b 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml @@ -2,7 +2,7 @@ 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2025-09-26T14:41:09.439178+00:00 + 2025-09-26T16:03:08.242841+00:00 python-feedgen Paul Sztorc 2022-03-04 20:06:50+00:00 @@ -93,10 +93,11 @@ + 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2025-09-26T14:41:09.439335+00:00 + 2025-09-26T16:03:08.243032+00:00 2022-03-04T20:06:50+00:00 In an email exchange on the bitcoin-dev mailing list, Billy Tetrud discusses sidechains and their potential to address the issue of a less-secure altcoin dominating Bitcoin. While he acknowledges some merits of sidechains in this scenario, Tetrud points out that they do not completely solve the problem. He raises concerns about a sidechain cutting off the main chain and whether it would be in the best interest of enough people. Tetrud also explores the benefits and drawbacks of largeblock sidechains compared to other payment systems like Visa and Lightning. Various tradeoffs, such as onboarding, payment speed, micropayments, fees, and contribution to layer 1 security budget, are considered. Tetrud concludes that if a layer 2 is harmless, its existence can be justified by one net benefit for some users.Another discussion revolves around the size of commitments needed for sidechains and channel factories. User ZmnSCPxj suggests a solution to reduce on-chain bytes by utilizing tweaks in the miner's key and unused TapScript. This eliminates the need for separate commitments and reduces data requirements. Additionally, sidechains can push zero bytes on-chain by using OP_RETURN inside TapScript for checking purposes.The conversation centers around the potential dominance of a sidechain over Bitcoin and how it could prevent an altcoin from dominating. The consensus is that having all chains, centralized and decentralized, in the same monetary unit ensures the decentralized chain always exists without interference from monetary network effects. However, it is argued that a sidechain cannot exist without its main chain, and if it becomes too popular, people may stop using the main chain altogether. The discussion also compares the benefits of a largeblock sidechain to Visa and Lightning and considers the burden on Bitcoin-only nodes. The potential advantages to users of a largeblock sidechain are discussed, including lower fees and more decentralization. The idea of sweeping fiat transactions into a largeblock sidechain is also explored.Another conversation between Billy Tetrud and Paul focuses on the use of sidechains in Bitcoin. Billy proposes that all chains, decentralized and centralized, being in the same monetary unit ensures the existence of the decentralized chain without interference from network effects. Paul disagrees, stating that sidechains cannot exist without their main chain and gives an example using a zcash sidechain. They also discuss the merits of largeblock sidechains and how they can allow users to easily sweep fiat transactions into the BTC universe. Paul believes that largeblock sidechains would not burden Bitcoin Core full nodes.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin scalability, sidechains, network effects, and the security of Lightning Network and Drivechains. Participants argue that sidechains are necessary to prevent people from switching entirely to altcoins, which could be heavily exploited by attackers. Another participant suggests that having all chains in the same monetary unit guarantees the existence of the decentralized chain. The discussion delves into the security risks of LN channel factories and compares the security of LN and Drivechains. The participants emphasize the importance of separating the onboarding rate from the payment rate for designing different structures.The email exchange on the bitcoin-dev mailing list centers around the use of recursive covenants and their potential impact on Bitcoin. The discussion explores implementing techniques like Drivechains using recursive covenants. While concerns about negative effects on Bitcoin or the user base are raised, it is suggested that separate soft forks can be used to add recursive covenants if consensus is reached. The rejection of Drivechains in Bitcoin is also discussed, with arguments made against their implementation due to their distinct security model and potential block size increase. However, proponents argue that Drivechains could have a positive impact and should be given a chance. The debate includes discussions on miner censorship, block size increase, and the need for consensus changes. Paul Sztorc responds to the rejection of Drivechains, stating that there is no strong incentive for mainchain miners and sidechain validators to merge their businesses. He refutes claims that Drivechains would degrade security and believes that Drivechain was ahead of its time and will eventually be adopted. Other discussions revolve around encumbrances and restrictions on spend from covenants, the potential harm to the fungibility of UTXOs, and the shift in risk models. Some argue that introducing different risk models can be damaging to fungibility, while others believe that being able to reject certain coins is at the heart of Bitcoin's security. The email exchanges highlight the ongoing debates and considerations surrounding recursive covenants, Drivechains, and their potential impact on Bitcoin.In a recent email to the Bitcoin-dev mailing list, Jeremy Rubin raises concerns about proposals enabling more "featureful" covenants by adding additional computation into bitcoin script. They emphasize the importance of limiting operations in bitcoin script to "verification" rather than "computation" whenever possible. The author expresses uncertainty about these proposals and fears that opcodes like OP_CAT and OP_TX introduce unnecessary complexity into the script. However, diff --git a/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml b/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml index 4eabd4a263..02788b7715 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml @@ -2,7 +2,7 @@ 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2025-09-26T14:40:56.663112+00:00 + 2025-09-26T16:03:06.128132+00:00 python-feedgen Billy Tetrud 2022-02-22 12:57:15+00:00 @@ -85,10 +85,11 @@ + 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2025-09-26T14:40:56.663278+00:00 + 2025-09-26T16:03:06.128321+00:00 2022-02-22T12:57:15+00:00 In a recent discussion about Bitcoin scaling, there was disagreement over whether it should be done rapidly or not. Some argue that scaling should not be delayed to keep fees high, suggesting that if higher fees are needed, the block size can be lowered or the default minimum relay fee rate increased. They also question the belief that the Lightning Network is the main cause of low fees and argue that delaying scaling would harm Bitcoin's growth.On the other hand, others argue that new use cases for on-chain transactions may compete with existing users for limited blockchain space. This situation has been compared to the saying "nobody goes there anymore, it's too crowded." The discussion also touched upon the issue of invoking Satoshi's opinions in present-day discussions. One participant objected to assumptions about the founder of Bitcoin, arguing that Satoshi is more than just a pseudonym and will live on forever. However, another participant objected to the invocation of Satoshi in general, suggesting that if he wants to participate in Bitcoin development today, he can speak for himself. They added that if Satoshi refuses to participate, his opinion is irrelevant. In an email exchange posted on a Bitcoin forum, Prayank objects to ZmnSCPxj's invocation of Satoshi, stating that he cares about Satoshi's opinions, especially regarding subsidies. ZmnSCPxj counters by arguing that if Satoshi refuses to participate in Bitcoin development today, it doesn't matter what his opinion is. He asserts that Satoshi is dead and Bitcoin lives on without him. Prayank objects to this assumption, insisting that Satoshi is more than just a pseudonym and will live on forever. Both parties acknowledge that they are considering the various arguments being presented.In another post, ZmnSCPxj mentions that improvements like the Taproot upgrade can reduce activity on the blockchain and increase functionality without requiring an increase in block size. The Taproot upgrade offers features such as Schnorr multisignatures, MAST, `SIGHASH_ANYPREVOUT`, and `OP_CTV`, which reduce block size usage for complex contracts, enable offchain updateable multiparty cryptocurrency systems, and allow transactional cut-through without immediate output publication. ZmnSCPxj believes that these upgrades enhance Bitcoin's functionality and provide opportunities to use the blockchain in a different way.There is also a discussion about the expansion of use-cases in Ethereum potentially harming Bitcoin by fueling future contentious blocksize debates due to high on-chain fees. However, the counterargument is that fees will be the incentives for miners as subsidy decreases, and it will depend on the demand for block space. Additionally, if this is the reason to stop or delay improvements in Bitcoin, it may apply to Taproot as well. A proposal for a lightning-compatible mimblewimble+dandelion on-chain soft fork is mentioned as a way to reduce transaction size, improve privacy, and move more small transactions off-chain. However, it is suggested that this should not be released for another two years as timing is crucial for Bitcoin innovation.Furthermore, there is a discussion about the lack of compelling use-cases beneficial to all users, with some shared use cases being considered too narrow. The Drivechains use-case is deemed harmful to the security of Bitcoin as a whole. It is argued that the new uses for on-chain transactions mentioned as a use-case could harm existing users by competing for limited blockchain space. As a result, it is concluded that any core consensus changes to the Bitcoin system must be carefully evaluated against the risks.In the Bitcoin developer community, there is a debate about the readiness and potential risks of implementing the proposed consensus change known as OP_CTV. Some developers argue for its activation in a few months, while others express skepticism and call for more testing and research. Other soft fork proposals, such as BIP 118 focusing on eltoo payment channels, are also discussed. Concerns are raised about rushing through consensus changes without thorough examination and community support. Skeptics emphasize the need for technical discussions and engagement to address potential issues. Despite differing opinions, there is a general agreement that implementing a soft fork within the next few months is feasible with proper precautions. The discussion highlights the importance of responsible decision-making and avoiding contentious activation attempts. IRC workshops on BIP 119 are mentioned as a resource for engaging with skeptics on technical concerns. diff --git a/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml b/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml index c912702571..912d231f5e 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml @@ -2,7 +2,7 @@ 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2025-09-26T14:40:50.176643+00:00 + 2025-09-26T16:03:04.014333+00:00 python-feedgen Anthony Towns 2022-02-03 06:17:14+00:00 @@ -77,10 +77,11 @@ + 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2025-09-26T14:40:50.176818+00:00 + 2025-09-26T16:03:04.014531+00:00 2022-02-03T06:17:14+00:00 In a recent discussion on the bitcoin-dev mailing list, the topic of enabling covenants in Bitcoin Script was explored. One suggestion involved using the "2 2 CHECKMULTISIG" multisig approach to enforce KYC by requiring funds to be deposited and signed with a government key. The idea of using recursive covenants to create non-terminating computations was also discussed. This concept was originally mentioned in a tweet by Ethan Heilman and later elaborated on in a post by Andrew Poelstra.The discussion also delved into the question of whether Turing completeness should be banned in Bitcoin Script. ZmnSCPxj argued for allowing total Turing-completeness but banning partial Turing-completeness. However, it was acknowledged that banning non-terminating computation for cross-transaction computations would be infeasible. Recursive covenants were identified as a way to write universal computations, and banning source code manipulation would essentially mean banning the manipulation of strings of bytes, which is fundamental to Bitcoin Script.ZmnSCPxj further explained the concept of substructural recursion rules and copattern matching in total functional languages, which ensure termination of recursion. They compared recursive covenants in Bitcoin to codata types in total functional languages, emphasizing the need for Bitcoin SCRIPT to be provably terminating.Jeremy Rubin raised concerns about the potential dangers of evil multisig covenants and the possibility of mining centralization leading to censorship. The discussion also touched on the usefulness of the CSFS opcode and the relationship between OP_CAT and covenants. It was suggested that more direct approaches like OP_TWEAK or UPDATETAPLEAF could be better for implementing covenants.The conversation also addressed the need for separate programs to operate ants and the encoding of state in other parts of the transaction. The idea of adding OP_TWEAK and convenience opcodes for building Taproot Merkle trees was proposed.The discussion on enabling covenants highlighted concerns about transaction and block validation for nodes, ensuring bounded resource requirements and clear evaluation costs. It was noted that while enabling covenants could allow for complex machines that manipulate funds on the blockchain, simple Script programs can be validated and scrutinized to mitigate potential risks. The addition of OP_CHECKSIGFROMSTACK opcode and upper bounds on recursions were suggested as possible solutions.Overall, the discussion emphasized the need for careful consideration of enabling covenants, balancing functionality with validation costs and ensuring the safety and integrity of the Bitcoin network.The ongoing discussion on enabling covenants in Bitcoin has seen arguments against them losing weight as more research is conducted. Multisig wallets alone can enable recursive covenants, such as when a government requires funds to be deposited into a multisig that can only be spent if certain conditions are met. This approach is already being used in permissioned systems like Liquid. While there are ways to escape from recursive covenants, they are not fundamentally different from consensus-enforced covenants. Therefore, multisig-based covenants should be considered in the ongoing discussions about enabling covenants in Bitcoin.Recent research has reduced the weight of arguments against covenants, as AJ's point has further weakened anti-covenant arguments. Multisig alone can enable recursive covenants, as a government can deposit funds into a multisig wallet that requires certain conditions to be met for spending. This process is more efficient than explicit covenants and is already being used in systems like Liquid. The difference between escaping from recursive covenants and consensus-enforced covenants seems to be in procedure and difficulty rather than a fundamental difference.The discussion around enabling covenants is centered on whether OP_CAT should be allowed or not. Multisig wallets can enable recursive covenants, as a government can require funds to be deposited into a multisig that follows certain rules. This approach is already used by Liquid and BTC-on-Ethereum tokens. Escaping from this type of recursive covenant would require a change in signing policy. However, escaping any consensus-enforced covenant would require a hard fork. This difference seems to be more procedural and difficulty-based.Russell O'Connor raised concerns about recursive covenants and the implications of enabling OP_CAT. He initially suggested that such worries should be left for OP_TWEAK, but later acknowledged that recursive covenants could still be created by sneaking state into UTXO amounts or sibling outputs accessed via txid. This highlights the importance of avoiding giving too much power. However, altcoins already exist and some are worse, making full EVM support possible.In an email thread, Russell O'Connor discussed the topic of enabling covenants, specifically recursive covenants that require OP_TWEAK. He expressed concern about simulating this operation with CHECKSIG(FROMSTACK), but later noted that recursive covenants could still be created using a fixed scriptpubkey by sneaking state into UTXO amounts or sibling outputs accessed via txid diff --git a/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml b/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml index 54e0b7dfc2..7a0a672ea3 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Why CTV, why now? - 2025-09-26T14:40:48.032467+00:00 + 2025-09-26T16:03:01.899312+00:00 python-feedgen Jeremy Rubin 2022-02-02 01:43:38+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Why CTV, why now? - 2025-09-26T14:40:48.032612+00:00 + 2025-09-26T16:03:01.899469+00:00 2022-02-02T01:43:38+00:00 Anthony Towns shared a script template on the Bitcoin-dev mailing list that can be used to simulate CTV (Covenants) on the Liquid blockchain using new element opcodes. Although this approach is less efficient than having a dedicated opcode, it can be effective for many useful applications. The script template involves several INSPECT and SHA256 opcodes, which are used to determine the spending transaction's txid.If the NUMINPUTS is greater than one, there is a need to limit the usage of other inputs, which would be specific to the application being developed. Anthony believes that this emulation might be compatible with confidential assets/values but is uncertain. He also suggests that a similar approach using CHECKSIGFROMSTACK instead of "EQUAL" could be used to construct APO-style signatures on elements/liquid. However, he advises wrapping the output inspection blocks with "INSPECTNUMOUTPUTS GREATERTHAN IF .. ENDIF" and starting with "PUSH[FakeAPOSig] SHA256 DUP SHA256INITIALIZE SHA256UPDATE" to avoid potential misuse in a different context.Anthony notes that the Liquid network, which currently has approximately $120M worth of BTC and $36M worth of USDT, is not congested and does not have many lightning channels built on top of it. As a result, the vaulting application appears to be the most interesting one to build on top of Liquid at present. This suggests that there may be a justification for exploring vault-related work on the Liquid blockchain. Real experience with CTV-like constructs is expected to provide valuable insights.On January 5th, Jeremy via bitcoin-dev proposed CTV as a simple covenant type with minimal validation burdens. It is designed to offer simplicity, flexibility, and power for building various useful applications. The new element opcodes make it possible to simulate CTV on the Liquid blockchain or liquid-testnet if fake money is preferred. While the script template provided in the context is not as efficient as a dedicated opcode, it can still be used when NUMINPUTS is one. In this case, the txid of the spending transaction is fixed due to taproot-only opcodes and the absence of scriptSig malleability. diff --git a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml index 8037d318e5..62deba5512 100644 --- a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml +++ b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP Draft] Allow zero value OP_RETURN in Payment Protocol - 2023-08-01T17:38:01.419169+00:00 + 2025-09-26T15:28:28.616491+00:00 + python-feedgen Toby Padilla 2016-02-02 19:22:10+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - [BIP Draft] Allow zero value OP_RETURN in Payment Protocol - 2023-08-01T17:38:01.419169+00:00 + 2025-09-26T15:28:28.616689+00:00 - In a discussion between Toby Padilla and Luke Dashjr, the use of OP_RETURN values in Bitcoin transactions is debated. Toby argues that PaymentRequests limit the use of OP_RETURN values, as they must be greater than zero, creating a pre-OP_RETURN environment. Luke counters, suggesting that coins should be burned instead of allowing zero value OP_RETURNs. However, Toby believes there is a better alternative.The conversation revolves around the limitations of PaymentRequests regarding OP_RETURN values. Toby explains that PaymentRequests allow for similar transactions as non-PaymentRequest based transactions, but with the limitation that OP_RETURN values must be greater than zero. In contrast, Luke believes that OP_RETURN can be used, but coins would need to be burned, and he sees no benefit in changing that.Toby clarifies his point by mentioning BIP70, where the key for redeeming inputs can be in the user's wallet, allowing transaction construction on another machine without needing a key. However, currently, transaction construction on another machine with zero value OP_RETURNs is not possible. Despite their disagreement, both parties acknowledge that a key is always necessary for redeeming inputs in Bitcoin transactions.On January 26, 2016, Toby sent a message to Luke discussing the encoding of data on the blockchain. Luke suggests that supporting OP_RETURN in PaymentRequests is unnecessary, but Toby argues that it is important because people may use worse methods for encoding data. Toby also mentions the difficulty of constructing a transaction with a zero value OP_RETURN without keys in an environment without keys. Luke does not understand Toby's statement.The discussion focuses on a draft proposal that has not been approved by the mailing list yet. The draft suggests accepting zero value OP_RETURN outputs in BIP70 payment requests, which were previously ignored. The author argues that this feature would be useful for encoding data on the blockchain using PaymentRequests. However, Luke strongly advises against publishing or implementing this BIP, as he sees no benefit to the network and believes it could encourage spam. He also argues that the proposed changes are detrimental and would make users unwilling participants in spam.The author responds by giving an example of how merchants can add the hash of a plain text invoice to the checkout transaction by constructing the PaymentRequest with the invoice hash in an OP_RETURN. Toby argues that merchants and Bitcoin application developers would benefit from this BIP because they can construct transactions with OP_RETURN data without needing keys. Prior to this BIP, such transactions needed to be executed within the same software. Luke questions the relevance to keys and argues that the proposed changes are not compatible with existing and future software. He concludes that implementing either BIP 70 or this draft would have severe consequences, emphasizing that losing burned bitcoins is better than having a way to avoid them.The author of a Bitcoin Improvement Proposal (BIP) warns against publishing or implementing it due to potential spam and user unwillingness. The BIP suggests allowing merchants to add plain text invoice hashes to checkout transactions using PaymentRequests with zero value OP_RETURN outputs. However, the proposal lacks wallet support for checking upfront, may encourage spam, and does not consider the relevance to keys. The proposed changes are also not backward nor forward compatible, resulting in severe consequences.The author has submitted a new BIP draft that alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. This allows wallets to participate in current and future use cases that benefit from metadata stored in OP_RETURN. Previously, OP_RETURN transactions required custom software, but now wallets can process PaymentRequests with OP_RETURN data, supporting sophisticated Bitcoin applications without prior knowledge. Merchants and Bitcoin application developers benefit from this BIP by being able to construct transactions with OP_RETURN data in a keyless environment. Without supporting this BIP, wallets that support BIP70 will allow wasteful data storage. 2016-02-02T19:22:10+00:00 + In a discussion between Toby Padilla and Luke Dashjr, the use of OP_RETURN values in Bitcoin transactions is debated. Toby argues that PaymentRequests limit the use of OP_RETURN values, as they must be greater than zero, creating a pre-OP_RETURN environment. Luke counters, suggesting that coins should be burned instead of allowing zero value OP_RETURNs. However, Toby believes there is a better alternative.The conversation revolves around the limitations of PaymentRequests regarding OP_RETURN values. Toby explains that PaymentRequests allow for similar transactions as non-PaymentRequest based transactions, but with the limitation that OP_RETURN values must be greater than zero. In contrast, Luke believes that OP_RETURN can be used, but coins would need to be burned, and he sees no benefit in changing that.Toby clarifies his point by mentioning BIP70, where the key for redeeming inputs can be in the user's wallet, allowing transaction construction on another machine without needing a key. However, currently, transaction construction on another machine with zero value OP_RETURNs is not possible. Despite their disagreement, both parties acknowledge that a key is always necessary for redeeming inputs in Bitcoin transactions.On January 26, 2016, Toby sent a message to Luke discussing the encoding of data on the blockchain. Luke suggests that supporting OP_RETURN in PaymentRequests is unnecessary, but Toby argues that it is important because people may use worse methods for encoding data. Toby also mentions the difficulty of constructing a transaction with a zero value OP_RETURN without keys in an environment without keys. Luke does not understand Toby's statement.The discussion focuses on a draft proposal that has not been approved by the mailing list yet. The draft suggests accepting zero value OP_RETURN outputs in BIP70 payment requests, which were previously ignored. The author argues that this feature would be useful for encoding data on the blockchain using PaymentRequests. However, Luke strongly advises against publishing or implementing this BIP, as he sees no benefit to the network and believes it could encourage spam. He also argues that the proposed changes are detrimental and would make users unwilling participants in spam.The author responds by giving an example of how merchants can add the hash of a plain text invoice to the checkout transaction by constructing the PaymentRequest with the invoice hash in an OP_RETURN. Toby argues that merchants and Bitcoin application developers would benefit from this BIP because they can construct transactions with OP_RETURN data without needing keys. Prior to this BIP, such transactions needed to be executed within the same software. Luke questions the relevance to keys and argues that the proposed changes are not compatible with existing and future software. He concludes that implementing either BIP 70 or this draft would have severe consequences, emphasizing that losing burned bitcoins is better than having a way to avoid them.The author of a Bitcoin Improvement Proposal (BIP) warns against publishing or implementing it due to potential spam and user unwillingness. The BIP suggests allowing merchants to add plain text invoice hashes to checkout transactions using PaymentRequests with zero value OP_RETURN outputs. However, the proposal lacks wallet support for checking upfront, may encourage spam, and does not consider the relevance to keys. The proposed changes are also not backward nor forward compatible, resulting in severe consequences.The author has submitted a new BIP draft that alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. This allows wallets to participate in current and future use cases that benefit from metadata stored in OP_RETURN. Previously, OP_RETURN transactions required custom software, but now wallets can process PaymentRequests with OP_RETURN data, supporting sophisticated Bitcoin applications without prior knowledge. Merchants and Bitcoin application developers benefit from this BIP by being able to construct transactions with OP_RETURN data in a keyless environment. Without supporting this BIP, wallets that support BIP70 will allow wasteful data storage. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-BIP-Acceptance-Process.xml b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-BIP-Acceptance-Process.xml index 1ccfc497f3..7f275c2efa 100644 --- a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-BIP-Acceptance-Process.xml +++ b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-BIP-Acceptance-Process.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP/Draft] BIP Acceptance Process - 2023-08-01T15:59:58.337872+00:00 + 2025-09-26T15:28:30.729074+00:00 + python-feedgen Dave Scotese 2016-01-19 06:07:52+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - [BIP/Draft] BIP Acceptance Process - 2023-08-01T15:59:58.337872+00:00 + 2025-09-26T15:28:30.729259+00:00 - The current process for Bitcoin Improvement Proposals (BIPs) lacks clarity and there is a proposal to improve it. One suggestion is to have committees that review and indicate acceptance of BIPs, but there are debates and concerns surrounding this idea. Luke Dashjr argues against the committee proposal and suggests a specification based on BIP 123 instead. He questions the requirement for 1% stake for each segment of the Bitcoin ecosystem, citing privacy violations and time consumption.The proposed process aims to include more voices and gain a clearer idea of acceptance than the current process allows. The committee structures would be fluid, allowing users to reorganize at any time. However, there are debates about how different groups would prove their stake and express their positions. There is also a discussion about the definition of "accepted" and whether it should be binding on client authors. It is suggested that a BIP could be "greenlighted" by the community, but it's unclear if this would guarantee implementation.Overall, there is a need to improve the BIP process to ensure clear and fair acceptance of proposals. Some aspects of the current process need polishing, especially around "workflow states," but introducing committees may not be the best solution. The goal is to develop a process that gathers meaningful information to guide decisions without forcing anything on implementors or users. Peer review and open discussions are seen as important filtering mechanisms for proposals.It is important to note that the BIP process is separate from the implementation and adoption of proposals in Bitcoin software such as Bitcoin Core. Consensus rule changes are usually documented as BIPs, but their adoption and implementation depend on the wider ecosystem.In conclusion, the discussion highlights the need for a better process to accept BIPs in Bitcoin. Various proposals and concerns have been raised, including the role of committees, proving stake, expressing positions, and defining acceptance. The aim is to ensure a fair and transparent process that includes diverse voices and avoids unnecessary bureaucracy. 2016-01-19T06:07:52+00:00 + The current process for Bitcoin Improvement Proposals (BIPs) lacks clarity and there is a proposal to improve it. One suggestion is to have committees that review and indicate acceptance of BIPs, but there are debates and concerns surrounding this idea. Luke Dashjr argues against the committee proposal and suggests a specification based on BIP 123 instead. He questions the requirement for 1% stake for each segment of the Bitcoin ecosystem, citing privacy violations and time consumption.The proposed process aims to include more voices and gain a clearer idea of acceptance than the current process allows. The committee structures would be fluid, allowing users to reorganize at any time. However, there are debates about how different groups would prove their stake and express their positions. There is also a discussion about the definition of "accepted" and whether it should be binding on client authors. It is suggested that a BIP could be "greenlighted" by the community, but it's unclear if this would guarantee implementation.Overall, there is a need to improve the BIP process to ensure clear and fair acceptance of proposals. Some aspects of the current process need polishing, especially around "workflow states," but introducing committees may not be the best solution. The goal is to develop a process that gathers meaningful information to guide decisions without forcing anything on implementors or users. Peer review and open discussions are seen as important filtering mechanisms for proposals.It is important to note that the BIP process is separate from the implementation and adoption of proposals in Bitcoin software such as Bitcoin Core. Consensus rule changes are usually documented as BIPs, but their adoption and implementation depend on the wider ecosystem.In conclusion, the discussion highlights the need for a better process to accept BIPs in Bitcoin. Various proposals and concerns have been raised, including the role of committees, proving stake, expressing positions, and defining acceptance. The aim is to ensure a fair and transparent process that includes diverse voices and avoids unnecessary bureaucracy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml index 88cd94840c..a71e3b0abf 100644 --- a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml +++ b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP Draft] Decentralized Improvement Proposals - 2023-08-01T17:20:15.539624+00:00 + 2025-09-26T15:28:24.389574+00:00 + python-feedgen Rusty Russell 2016-01-03 23:31:26+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - [BIP Draft] Decentralized Improvement Proposals - 2023-08-01T17:20:15.539624+00:00 + 2025-09-26T15:28:24.389734+00:00 - In a discussion on bitcoin-dev, Luke Dashjr and Tomas debated the efficiency of the specification for version bits. Tomas raised concerns about the unclear assignment of version bits in the specification, suggesting that any implementation proposing a change should be encouraged to choose a free version bit to use. Luke agreed that clarification was necessary in the BIP, or Bitcoin Improvement Proposal, and suggested that the BIP editor assign version bits like BIP numbers themselves. However, he also noted that since the number of deployed forks is low, it may not be necessary to have a more robust system. Rusty, another member of the discussion, offered to fill that role if needed.In an email exchange between Tomas and Luke on December 30, 2015, they discuss the efficiency and implementation of version bits in the context of proposing changes to the Bitcoin network. Tomas expresses concern over the inefficiency of the current system and suggests that clarification is needed for assigning version bits. Luke proposes that the BIP editor assign version bits similarly to BIP numbers. Tomas further suggests that his proposal addresses the danger of forward-incompatible changes and eliminates the possibility of a hard fork, but Luke disagrees. He points out that a hard fork can always occur as it is determined by the economy and not miners. Additionally, changes such as a PoW algorithm change could still lead to further rule changes.In a recent discussion, Tomas expressed his opinion on the inefficiency and bloatiness of a specification which appears to be a reinvention of version bits. The allocation of version bits was not clear from the specification, leading to confusion regarding the implementation of proposed changes. Tomas also addressed the issue of forward-incompatible changes by proposing a solution that prevents hard-forks from occurring, ensuring that every implementation agrees on the active set of rules even if it has not implemented them. This crucial aspect seems to be missing in the version bits proposal.In December 2015, Tomas proposed a BIP (Bitcoin Improvement Proposal) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. However, Luke criticized the motivation behind this proposal stating that BIPs are required to have a reference implementation, but it need not necessarily be for Bitcoin Core specifically. He also commented on the specification, saying that it looked like an inefficient and bloaty reinvention of version bits.Tomas van der Wansem has drafted a Bitcoin Improvement Proposal (BIP) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. The BIP can be found on GitHub. He believes that the proposal can help in decentralizing the development of the protocol and mitigate the risk of forks. He is requesting a BIP-number if the proposal is considered worthy of discussion. 2016-01-03T23:31:26+00:00 + In a discussion on bitcoin-dev, Luke Dashjr and Tomas debated the efficiency of the specification for version bits. Tomas raised concerns about the unclear assignment of version bits in the specification, suggesting that any implementation proposing a change should be encouraged to choose a free version bit to use. Luke agreed that clarification was necessary in the BIP, or Bitcoin Improvement Proposal, and suggested that the BIP editor assign version bits like BIP numbers themselves. However, he also noted that since the number of deployed forks is low, it may not be necessary to have a more robust system. Rusty, another member of the discussion, offered to fill that role if needed.In an email exchange between Tomas and Luke on December 30, 2015, they discuss the efficiency and implementation of version bits in the context of proposing changes to the Bitcoin network. Tomas expresses concern over the inefficiency of the current system and suggests that clarification is needed for assigning version bits. Luke proposes that the BIP editor assign version bits similarly to BIP numbers. Tomas further suggests that his proposal addresses the danger of forward-incompatible changes and eliminates the possibility of a hard fork, but Luke disagrees. He points out that a hard fork can always occur as it is determined by the economy and not miners. Additionally, changes such as a PoW algorithm change could still lead to further rule changes.In a recent discussion, Tomas expressed his opinion on the inefficiency and bloatiness of a specification which appears to be a reinvention of version bits. The allocation of version bits was not clear from the specification, leading to confusion regarding the implementation of proposed changes. Tomas also addressed the issue of forward-incompatible changes by proposing a solution that prevents hard-forks from occurring, ensuring that every implementation agrees on the active set of rules even if it has not implemented them. This crucial aspect seems to be missing in the version bits proposal.In December 2015, Tomas proposed a BIP (Bitcoin Improvement Proposal) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. However, Luke criticized the motivation behind this proposal stating that BIPs are required to have a reference implementation, but it need not necessarily be for Bitcoin Core specifically. He also commented on the specification, saying that it looked like an inefficient and bloaty reinvention of version bits.Tomas van der Wansem has drafted a Bitcoin Improvement Proposal (BIP) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. The BIP can be found on GitHub. He believes that the proposal can help in decentralizing the development of the protocol and mitigate the risk of forks. He is requesting a BIP-number if the proposal is considered worthy of discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_An-implementation-of-BIP102-as-a-softfork-.xml b/static/bitcoin-dev/Jan_2016/combined_An-implementation-of-BIP102-as-a-softfork-.xml index dad82db37d..2175b2fda5 100644 --- a/static/bitcoin-dev/Jan_2016/combined_An-implementation-of-BIP102-as-a-softfork-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_An-implementation-of-BIP102-as-a-softfork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - An implementation of BIP102 as a softfork. - 2023-08-01T17:19:26.356499+00:00 + 2025-09-26T15:28:26.505540+00:00 + python-feedgen joe2015 at openmailbox.org 2016-01-12 03:58:13+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - An implementation of BIP102 as a softfork. - 2023-08-01T17:19:26.357464+00:00 + 2025-09-26T15:28:26.505722+00:00 - In a Bitcoin-dev mailing list, Joe2015 responded to Nick ODell's query about fee collection from transactions in the block. Joe suggested mapping the new-rules coinbase transaction into an old-rules legacy coinbase transaction, but emphasized the need for careful consideration to ensure the mapping is irreversible. Joe has redesigned the implementation and provided GitHub links for reference. The new version maps the Merkle root onto a 'legacy' coinbase transaction, effectively solving the problem with fees.The conversation on the Bitcoin-dev mailing list revolves around Joe's proposal for a "generalized soft fork." Marco Falke expresses doubts about the proposal, arguing that it contradicts the definition of a soft fork as it requires nodes to upgrade. Joe clarifies that while it may not technically be a soft fork, it possesses similar properties except for meaningful backwards compatibility for non-upgraded clients. Marco raises concerns about how non-updated nodes would verify collected fees without actual transactions at hand and suggests a hard fork as a cleaner solution. Joe acknowledges that hard forks can be cleaner but highlights the risk of network splitting between upgraded and non-upgraded clients. He argues that a "firm soft fork" could be a better option. However, Joe realizes an oversight in his proof-of-concept implementation where all transactions would have to be zero-fee due to missing fees from non-updated nodes. He suggests implicitly adding the fees or finding other solutions.Marco Falke and Joe discuss the concept of a "generalized" soft fork. Falke questions the property of a true soft fork as it requires nodes to upgrade, leaving non-upgraded nodes vulnerable to double spends. Joe suggests allowing the new rules to add fees implicitly as a solution. When Falke questions the benefits of a "generalized" soft fork over a hard fork, Joe emphasizes the risk of a network split between upgraded and non-upgraded clients and argues that a "firm" soft fork is a better option in such cases.The Bitcoin developer community is discussing a proposal called the "forced soft-fork," which would require all nodes on the network to upgrade to the latest software version. The proposal has received mixed reactions, with some considering it "crufty and hackish" while others argue that the fear of recursion is misplaced. The forced soft-fork involves a multi-levels-deep block-within-a-block approach, but proponents claim that careful planning can simplify it. While the forced soft-fork could make it easier for developers to implement new features and upgrades, concerns about its impact on the security and stability of the Bitcoin network remain.In a discussion on the bitcoin-dev mailing list, Martijn Meijering expresses concerns about blocking old clients from seeing transactions. Peter Todd warns against sending multiple transactions without knowing if the longest blockchain is being seen and suggests designing software with fee-bumping to avoid mistakes. Increasing the tx version number could potentially disrupt pre-signed transactions.Jonathan Toomim voices his opinion against a proposed approach involving multi-levels-deep block structures for generalized softforks, deeming it interesting but hackish and not deployable. Another participant suggests incorporating the forced fork concept into Bitcoin by committing to H(version + digest) in block headers. This approach would provide safety advantages over hard forks and relatively simple implementation, though it may institutionalize 51% attacks and give miners more political control.A proposal for a softfork implementation of BIP102, normally a hardfork, has been shared on the bitcoin-dev mailing list. The implementation uses a strategy pattern to address concerns with deploying a block-size increase through a hardfork. Post-fork blocks are constructed to be mapped to valid blocks under pre-fork rules, allowing post-fork miners to create a valid chain indirectly. For non-upgraded clients, the block-size limit is circumvented by moving transaction validation data "outside" of the block, while upgraded clients see an unchanged block layout with a larger block-size limit and a new interpretation of the header Merkle root encoded in the coinbase. This implementation reduces fraud risk and requires miner majority to force miner consensus.A concern has been raised about the safety of old clients not being able to see transactions due to a new transaction blocking feature. It is suggested that increasing the tx version number could prevent transactions sent from old clients from confirming. The inclusion of this idea in the code remains uncertain.Marco questions whether a proposed approach is actually a soft fork, as it requires nodes to upgrade. He argues that true soft forks don't require any node upgrades and expresses concerns about missing transactions and vulnerability to double spends for non-upgraded nodes. Marco asks if there is something he is missing about the proposal.A proof-of-concept implementation of BIP102 as a softfork has been developed under the unofficial codename BIP102s. It constructs post-fork blocks that can be mapped to valid blocks under pre-fork rules, enabling post-fork miners to create a valid chain indirectly. Non-upgraded clients see the circumvention of 2016-01-12T03:58:13+00:00 + In a Bitcoin-dev mailing list, Joe2015 responded to Nick ODell's query about fee collection from transactions in the block. Joe suggested mapping the new-rules coinbase transaction into an old-rules legacy coinbase transaction, but emphasized the need for careful consideration to ensure the mapping is irreversible. Joe has redesigned the implementation and provided GitHub links for reference. The new version maps the Merkle root onto a 'legacy' coinbase transaction, effectively solving the problem with fees.The conversation on the Bitcoin-dev mailing list revolves around Joe's proposal for a "generalized soft fork." Marco Falke expresses doubts about the proposal, arguing that it contradicts the definition of a soft fork as it requires nodes to upgrade. Joe clarifies that while it may not technically be a soft fork, it possesses similar properties except for meaningful backwards compatibility for non-upgraded clients. Marco raises concerns about how non-updated nodes would verify collected fees without actual transactions at hand and suggests a hard fork as a cleaner solution. Joe acknowledges that hard forks can be cleaner but highlights the risk of network splitting between upgraded and non-upgraded clients. He argues that a "firm soft fork" could be a better option. However, Joe realizes an oversight in his proof-of-concept implementation where all transactions would have to be zero-fee due to missing fees from non-updated nodes. He suggests implicitly adding the fees or finding other solutions.Marco Falke and Joe discuss the concept of a "generalized" soft fork. Falke questions the property of a true soft fork as it requires nodes to upgrade, leaving non-upgraded nodes vulnerable to double spends. Joe suggests allowing the new rules to add fees implicitly as a solution. When Falke questions the benefits of a "generalized" soft fork over a hard fork, Joe emphasizes the risk of a network split between upgraded and non-upgraded clients and argues that a "firm" soft fork is a better option in such cases.The Bitcoin developer community is discussing a proposal called the "forced soft-fork," which would require all nodes on the network to upgrade to the latest software version. The proposal has received mixed reactions, with some considering it "crufty and hackish" while others argue that the fear of recursion is misplaced. The forced soft-fork involves a multi-levels-deep block-within-a-block approach, but proponents claim that careful planning can simplify it. While the forced soft-fork could make it easier for developers to implement new features and upgrades, concerns about its impact on the security and stability of the Bitcoin network remain.In a discussion on the bitcoin-dev mailing list, Martijn Meijering expresses concerns about blocking old clients from seeing transactions. Peter Todd warns against sending multiple transactions without knowing if the longest blockchain is being seen and suggests designing software with fee-bumping to avoid mistakes. Increasing the tx version number could potentially disrupt pre-signed transactions.Jonathan Toomim voices his opinion against a proposed approach involving multi-levels-deep block structures for generalized softforks, deeming it interesting but hackish and not deployable. Another participant suggests incorporating the forced fork concept into Bitcoin by committing to H(version + digest) in block headers. This approach would provide safety advantages over hard forks and relatively simple implementation, though it may institutionalize 51% attacks and give miners more political control.A proposal for a softfork implementation of BIP102, normally a hardfork, has been shared on the bitcoin-dev mailing list. The implementation uses a strategy pattern to address concerns with deploying a block-size increase through a hardfork. Post-fork blocks are constructed to be mapped to valid blocks under pre-fork rules, allowing post-fork miners to create a valid chain indirectly. For non-upgraded clients, the block-size limit is circumvented by moving transaction validation data "outside" of the block, while upgraded clients see an unchanged block layout with a larger block-size limit and a new interpretation of the header Merkle root encoded in the coinbase. This implementation reduces fraud risk and requires miner majority to force miner consensus.A concern has been raised about the safety of old clients not being able to see transactions due to a new transaction blocking feature. It is suggested that increasing the tx version number could prevent transactions sent from old clients from confirming. The inclusion of this idea in the code remains uncertain.Marco questions whether a proposed approach is actually a soft fork, as it requires nodes to upgrade. He argues that true soft forks don't require any node upgrades and expresses concerns about missing transactions and vulnerability to double spends for non-upgraded nodes. Marco asks if there is something he is missing about the proposal.A proof-of-concept implementation of BIP102 as a softfork has been developed under the unofficial codename BIP102s. It constructs post-fork blocks that can be mapped to valid blocks under pre-fork rules, enabling post-fork miners to create a valid chain indirectly. Non-upgraded clients see the circumvention of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_BIP-Classification-Process.xml b/static/bitcoin-dev/Jan_2016/combined_BIP-Classification-Process.xml index 4557573d94..f8eadd4d66 100644 --- a/static/bitcoin-dev/Jan_2016/combined_BIP-Classification-Process.xml +++ b/static/bitcoin-dev/Jan_2016/combined_BIP-Classification-Process.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Classification Process - 2023-08-01T17:40:29.651438+00:00 + 2025-09-26T15:28:18.043226+00:00 + python-feedgen Eric Lombrozo 2016-01-29 07:57:00+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP Classification Process - 2023-08-01T17:40:29.651438+00:00 + 2025-09-26T15:28:18.043394+00:00 - According to Btc Drak, the bitter resentment over the need for consensus on non-consensus features in codebase forks is a problem. He believes that forks with non-consensus features are acceptable and desirable because they allow for more freedom in upper layers. Eric Lombrozo, a Bitcoin developer, agrees with this perspective and suggests that a better process is needed to distinguish between different layers for bitcoin modification proposals.Lombrozo gives an example of BIP64 proposed by Mike Hearn, which did not affect the consensus layer at all. Despite being disliked by many Core developers, having nodes that support BIP64 would not fundamentally break the Bitcoin network. However, the pushback from Core developers led Mike to break off from Core and create XT as his applications required BIP64 to work. Lombrozo emphasizes the importance of a process that clearly distinguishes these different layers and allows more freedom in the upper layers while requiring agreement at the consensus layer.To address this issue, Lombrozo has submitted a BIP - BIP123 - that includes all currently proposed and accepted BIPs. He urges everyone to seriously consider getting this BIP accepted as a top priority before more projects attempt to make modifications without understanding these critical distinctions. However, it is pointed out that Eric's proposal does not solve the issue related to Mike creating his own fork, as he had a non-consensus feature set that Bitcoin Core disagreed with. The creation of individual forks with different features is encouraged if there is a strong differing of technical opinions and node security concerns.In summary, the current situation with forks in the Bitcoin network could have been avoided with a better process to distinguish between different layers for bitcoin modification proposals. The example of BIP64 and Mike Hearn's creation of XT highlights the need for a clear distinction between consensus and non-consensus features. Lombrozo's BIP123 proposal aims to address this issue and includes all currently proposed and accepted BIPs. It is crucial to prioritize the acceptance of this BIP to prevent further projects from making modifications without understanding these critical distinctions. 2016-01-29T07:57:00+00:00 + According to Btc Drak, the bitter resentment over the need for consensus on non-consensus features in codebase forks is a problem. He believes that forks with non-consensus features are acceptable and desirable because they allow for more freedom in upper layers. Eric Lombrozo, a Bitcoin developer, agrees with this perspective and suggests that a better process is needed to distinguish between different layers for bitcoin modification proposals.Lombrozo gives an example of BIP64 proposed by Mike Hearn, which did not affect the consensus layer at all. Despite being disliked by many Core developers, having nodes that support BIP64 would not fundamentally break the Bitcoin network. However, the pushback from Core developers led Mike to break off from Core and create XT as his applications required BIP64 to work. Lombrozo emphasizes the importance of a process that clearly distinguishes these different layers and allows more freedom in the upper layers while requiring agreement at the consensus layer.To address this issue, Lombrozo has submitted a BIP - BIP123 - that includes all currently proposed and accepted BIPs. He urges everyone to seriously consider getting this BIP accepted as a top priority before more projects attempt to make modifications without understanding these critical distinctions. However, it is pointed out that Eric's proposal does not solve the issue related to Mike creating his own fork, as he had a non-consensus feature set that Bitcoin Core disagreed with. The creation of individual forks with different features is encouraged if there is a strong differing of technical opinions and node security concerns.In summary, the current situation with forks in the Bitcoin network could have been avoided with a better process to distinguish between different layers for bitcoin modification proposals. The example of BIP64 and Mike Hearn's creation of XT highlights the need for a clear distinction between consensus and non-consensus features. Lombrozo's BIP123 proposal aims to address this issue and includes all currently proposed and accepted BIPs. It is crucial to prioritize the acceptance of this BIP to prevent further projects from making modifications without understanding these critical distinctions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Best-block-nr-2016-for-hard-fork-activation-.xml b/static/bitcoin-dev/Jan_2016/combined_Best-block-nr-2016-for-hard-fork-activation-.xml index ef131e4dc7..b1846eee54 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Best-block-nr-2016-for-hard-fork-activation-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Best-block-nr-2016-for-hard-fork-activation-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Best (block nr % 2016) for hard fork activation? - 2023-08-01T17:40:54.328255+00:00 + 2025-09-26T15:28:47.647332+00:00 + python-feedgen Peter Todd 2016-01-29 19:11:52+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Best (block nr % 2016) for hard fork activation? - 2023-08-01T17:40:54.328255+00:00 + 2025-09-26T15:28:47.647484+00:00 - In a discussion on the Bitcoin-dev mailing list, Jannes Faber raised concerns about the impact of a non-contentious hard fork on the remaining 1% chain. Peter Todd responded by discussing the risks of hard forks and suggested that activation thresholds for hard forks should be above 99%, measured over a multi-week timespan. He also mentioned that high activation thresholds could be soft-forked down later and that delaying the fork by two or three months if stragglers won't upgrade would not cause much harm. Todd emphasized that hard forks should not be controversial for social/political reasons, except in rare cases like security issues. He referred to his previous post on the technical risks of non-controversial forks.The email thread from January 29, 2016, focused on the impact of a fork during the difficulty period. The BIP9 optimization checks for new activations only during difficulty retargettings. However, it is not assumed that all implementations will follow this approach. BIP99 proposes a 95% activation threshold for uncontroversial rule changes and no miner signaling for controversial hard forks. The proposal includes simple fixes like the timewarp fix forward-ported from Freicoin 0.8. There has been limited interest in expanding the list of easy-to-implement changes. BIP99 has not faced opposition as a hardfork proposal, but it is not currently a priority. It may be classified as a BIP without code, and the hardfork proposal itself should have been separate.In another bitcoin-dev mailing list discussion, Jannes Faber expressed concerns about the effects of a hard or soft fork on non-upgraded clients, specifically regarding the 2016 blocks recalibration window. Gavin Andresen responded by stating that the timing of the fork within the difficulty period does not matter significantly. If the fork happens in the middle, the lower-power fork's difficulty will adjust slightly quicker. However, Andresen acknowledged that this scenario is unrealistic, as minority forks with single-digit percentages of hash power would cause significant delays and difficulty adjustments lasting months before normal block times are resumed. He referred to his blog post on minority branches, explaining why miners have little incentive to mine on a minority fork.The writer of the email seeks clarification on the effects of hard or soft forks, particularly related to the timing of implementing new rules and their impact on non-upgraded clients. They present four options for when to apply new rules, all related to the 2016 blocks recalibration window. The writer discusses the potential consequences of each option, particularly in the case of a contentious 75-25 hard fork, where option 4 would be best for the conservative chain. They also consider scenarios where it may be beneficial for the remaining 1% chain to never reach 2016 blocks again. The writer questions whether all possible scenarios have been considered and suggests that defining the best choice should be mandatory for any hard fork proposal, possibly through BIP9. Additionally, the writer acknowledges that the first few blocks mined after implementing new rules may not immediately adhere to the new guidelines. 2016-01-29T19:11:52+00:00 + In a discussion on the Bitcoin-dev mailing list, Jannes Faber raised concerns about the impact of a non-contentious hard fork on the remaining 1% chain. Peter Todd responded by discussing the risks of hard forks and suggested that activation thresholds for hard forks should be above 99%, measured over a multi-week timespan. He also mentioned that high activation thresholds could be soft-forked down later and that delaying the fork by two or three months if stragglers won't upgrade would not cause much harm. Todd emphasized that hard forks should not be controversial for social/political reasons, except in rare cases like security issues. He referred to his previous post on the technical risks of non-controversial forks.The email thread from January 29, 2016, focused on the impact of a fork during the difficulty period. The BIP9 optimization checks for new activations only during difficulty retargettings. However, it is not assumed that all implementations will follow this approach. BIP99 proposes a 95% activation threshold for uncontroversial rule changes and no miner signaling for controversial hard forks. The proposal includes simple fixes like the timewarp fix forward-ported from Freicoin 0.8. There has been limited interest in expanding the list of easy-to-implement changes. BIP99 has not faced opposition as a hardfork proposal, but it is not currently a priority. It may be classified as a BIP without code, and the hardfork proposal itself should have been separate.In another bitcoin-dev mailing list discussion, Jannes Faber expressed concerns about the effects of a hard or soft fork on non-upgraded clients, specifically regarding the 2016 blocks recalibration window. Gavin Andresen responded by stating that the timing of the fork within the difficulty period does not matter significantly. If the fork happens in the middle, the lower-power fork's difficulty will adjust slightly quicker. However, Andresen acknowledged that this scenario is unrealistic, as minority forks with single-digit percentages of hash power would cause significant delays and difficulty adjustments lasting months before normal block times are resumed. He referred to his blog post on minority branches, explaining why miners have little incentive to mine on a minority fork.The writer of the email seeks clarification on the effects of hard or soft forks, particularly related to the timing of implementing new rules and their impact on non-upgraded clients. They present four options for when to apply new rules, all related to the 2016 blocks recalibration window. The writer discusses the potential consequences of each option, particularly in the case of a contentious 75-25 hard fork, where option 4 would be best for the conservative chain. They also consider scenarios where it may be beneficial for the remaining 1% chain to never reach 2016 blocks again. The writer questions whether all possible scenarios have been considered and suggests that defining the best choice should be mandatory for any hard fork proposal, possibly through BIP9. Additionally, the writer acknowledges that the first few blocks mined after implementing new rules may not immediately adhere to the new guidelines. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Bitcoin-Core-0-12-0-release-candidate-1-available.xml b/static/bitcoin-dev/Jan_2016/combined_Bitcoin-Core-0-12-0-release-candidate-1-available.xml index 06c8b6df60..e6e58eb576 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Bitcoin-Core-0-12-0-release-candidate-1-available.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Bitcoin-Core-0-12-0-release-candidate-1-available.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.12.0 release candidate 1 available - 2023-08-01T17:35:14.547503+00:00 + 2025-09-26T15:28:39.189412+00:00 + python-feedgen xor at freenetproject.org 2016-01-25 17:33:09+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.12.0 release candidate 1 available - 2023-08-01T17:35:14.547503+00:00 + 2025-09-26T15:28:39.189591+00:00 - On January 25, 2016, Wladimir J. van der Laan requested assistance with the release notes for Bitcoin on Github. Another user submitted a pull request to resolve the issue, including a digitally signed signature. The context discusses the minimum storage quota of 550 MiB required for pruning nodes in Bitcoin. The reason for this minimum storage quota is to allow reorgs up to 288 blocks deep even when pruning. The PGP signature at the end of the message indicates that the message has not been tampered with and was signed by the sender using their private key.The concept of pruning in the Bitcoin ecosystem is often misunderstood. Satoshi's paper refers to UTXO pruning, while Pieter Wuille's "ultraprune" has been part of Bitcoin Core for more than three years. Block pruning is not mentioned in Satoshi's paper because nodes store historical blocks merely for administrative purposes. Pruning nodes don't serve block data at all unless there is a change to the P2P protocol. To enable block pruning, a number of megabytes "to allot for raw block & undo data" must be given, with any value being intended to be safe. Very low values could delete undo data that may be necessary in a reorganization, but this is prohibited by argument checks. It is important to note that the minimum storage quota of 550 MiB is necessary for pruning nodes even if the block data is not served to other nodes.The Bitcoin Core has already implemented the pruning feature, which stores the chainstate of about 2 GB regardless of what is set for prune. The minimum theoretical value of the prune target is zero, but in practice, it is 510, so small rescans and reorgs are still possible. Clients will not let you set below the minimum of 550 MB. Pruning deletes old transaction data that moves coins around and stores only the origin and current location of unspent transactions. There is a "natural" amount of megabytes for a fully pruned blockchain, which should be defined by the final amount of unspent coins. However, the number of megabytes to allot for raw block and undo data can be configured.In a discussion regarding block pruning in Bitcoin, Wladimir J. van der Laan suggested advertising the feature in the new release notes, which was added by Marco Falke. The RC2 changelog now includes instructions on enabling block pruning by setting prune= on the command line or in bitcoin.conf, with N representing the number of MiB allotted for raw block and undo data. A user expressed confusion over the need to specify a value for N, as they believed pruning should be a boolean on/off flag that automatically computes the natural size of the dataset based on the final amount of unspent coins. They requested further explanation in the release notes, including why N must be given, a "safe" value for N, and whether there is an "auto" setting for N.On January 18, 2016, Wladimir J. van der Laan announced the first binary release that contained block pruning functionality, which had been tested in git for almost half a year. He advised users to backup their wallets regardless. The previous v0.11.0 release notes stated that block pruning was incompatible with running a wallet because block data was used for rescanning the wallet and importing keys or addresses, but this limitation was expected to be lifted in the near future. A user inquired about whether the limitation had been lifted and if the feature was considered complete, stating that the disk space reduction was a significant benefit.A user on the Bitcoin-dev mailing list inquired about the status of pruning in the upcoming release of Bitcoin Core version 0.12. Wladimir J. van der Laan confirmed that pruning has been tested for almost half a year and will be included in this release. However, he also noted that users should still backup their wallets as there is always a possibility of issues with syncing between the wallet and blockchain.On January 17, 2016, a preliminary release note for Bitcoin Core version 0.12 was posted on the Bitcoin-dev mailing list. While the main part of the release notes did not mention the re-enabling of the wallet in autoprune feature, one of the pull requests noted that it had been re-enabled. A user on the mailing list asked if pruning was now finished and if it could be safely used as an end-user. They believed that this feature would be one of the most interesting ones for users since it could help fix the issue of taking up too much disk space. The user requested that if pruning was finished, the release notes should mention that and how to enable it.Bitcoin Core version 0.12.0rc1 binaries are now available on the official website of Bitcoin. This is a release candidate for a new major version release that brings new features, bug fixes, and other improvements. The preliminary 2016-01-25T17:33:09+00:00 + On January 25, 2016, Wladimir J. van der Laan requested assistance with the release notes for Bitcoin on Github. Another user submitted a pull request to resolve the issue, including a digitally signed signature. The context discusses the minimum storage quota of 550 MiB required for pruning nodes in Bitcoin. The reason for this minimum storage quota is to allow reorgs up to 288 blocks deep even when pruning. The PGP signature at the end of the message indicates that the message has not been tampered with and was signed by the sender using their private key.The concept of pruning in the Bitcoin ecosystem is often misunderstood. Satoshi's paper refers to UTXO pruning, while Pieter Wuille's "ultraprune" has been part of Bitcoin Core for more than three years. Block pruning is not mentioned in Satoshi's paper because nodes store historical blocks merely for administrative purposes. Pruning nodes don't serve block data at all unless there is a change to the P2P protocol. To enable block pruning, a number of megabytes "to allot for raw block & undo data" must be given, with any value being intended to be safe. Very low values could delete undo data that may be necessary in a reorganization, but this is prohibited by argument checks. It is important to note that the minimum storage quota of 550 MiB is necessary for pruning nodes even if the block data is not served to other nodes.The Bitcoin Core has already implemented the pruning feature, which stores the chainstate of about 2 GB regardless of what is set for prune. The minimum theoretical value of the prune target is zero, but in practice, it is 510, so small rescans and reorgs are still possible. Clients will not let you set below the minimum of 550 MB. Pruning deletes old transaction data that moves coins around and stores only the origin and current location of unspent transactions. There is a "natural" amount of megabytes for a fully pruned blockchain, which should be defined by the final amount of unspent coins. However, the number of megabytes to allot for raw block and undo data can be configured.In a discussion regarding block pruning in Bitcoin, Wladimir J. van der Laan suggested advertising the feature in the new release notes, which was added by Marco Falke. The RC2 changelog now includes instructions on enabling block pruning by setting prune= on the command line or in bitcoin.conf, with N representing the number of MiB allotted for raw block and undo data. A user expressed confusion over the need to specify a value for N, as they believed pruning should be a boolean on/off flag that automatically computes the natural size of the dataset based on the final amount of unspent coins. They requested further explanation in the release notes, including why N must be given, a "safe" value for N, and whether there is an "auto" setting for N.On January 18, 2016, Wladimir J. van der Laan announced the first binary release that contained block pruning functionality, which had been tested in git for almost half a year. He advised users to backup their wallets regardless. The previous v0.11.0 release notes stated that block pruning was incompatible with running a wallet because block data was used for rescanning the wallet and importing keys or addresses, but this limitation was expected to be lifted in the near future. A user inquired about whether the limitation had been lifted and if the feature was considered complete, stating that the disk space reduction was a significant benefit.A user on the Bitcoin-dev mailing list inquired about the status of pruning in the upcoming release of Bitcoin Core version 0.12. Wladimir J. van der Laan confirmed that pruning has been tested for almost half a year and will be included in this release. However, he also noted that users should still backup their wallets as there is always a possibility of issues with syncing between the wallet and blockchain.On January 17, 2016, a preliminary release note for Bitcoin Core version 0.12 was posted on the Bitcoin-dev mailing list. While the main part of the release notes did not mention the re-enabling of the wallet in autoprune feature, one of the pull requests noted that it had been re-enabled. A user on the mailing list asked if pruning was now finished and if it could be safely used as an end-user. They believed that this feature would be one of the most interesting ones for users since it could help fix the issue of taking up too much disk space. The user requested that if pruning was finished, the release notes should mention that and how to enable it.Bitcoin Core version 0.12.0rc1 binaries are now available on the official website of Bitcoin. This is a release candidate for a new major version release that brings new features, bug fixes, and other improvements. The preliminary - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Capacity-increases-for-the-Bitcoin-system-.xml b/static/bitcoin-dev/Jan_2016/combined_Capacity-increases-for-the-Bitcoin-system-.xml index 30a5bc4b08..794c4be9b5 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Capacity-increases-for-the-Bitcoin-system-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Capacity-increases-for-the-Bitcoin-system-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Capacity increases for the Bitcoin system. - 2023-08-01T17:02:46.399474+00:00 + 2025-09-26T15:29:04.554616+00:00 + python-feedgen Anthony Towns 2016-01-22 09:46:18+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 Combined summary - Capacity increases for the Bitcoin system. - 2023-08-01T17:02:46.401474+00:00 + 2025-09-26T15:29:04.554862+00:00 - Recent discussions among Bitcoin developers have centered around the implementation of Segregated Witness (SegWit) in Bitcoin transactions. The focus is on increasing efficiency for pay-to-public-key-hash (p2pkh) transactions. The latest segwit code utilizes "OP_0 [hash]" to push the version and hash separately, resulting in a reduction of 5 bytes per output for p2pkh transactions. This improvement is expected to lead to an increase in p2pkh and multisig transactions.Implementing SegWit would come at a cost, with the scaling factors estimated to be 170% for p2pkh transactions and 250%-300% for multisig transactions. The effective block size for p2pkh with SegWit is estimated to be 1.7MB, while for 2/2 multisig it is 2MB. Additionally, there are two potential soft-fork improvements that could make p2pkh and multisig more space efficient: ECDSA public key recovery and Schnorr signatures.The deployment of SegWit as a hardfork is supported by some defenders as it would solve scalability problems and make Bitcoin more stable. However, they also support the softfork version of SegWit, which is currently available. The plan is to do a softfork first and then a hardfork to move the witness tree outside of the coinbase. This approach is seen as exciting and believed to accelerate the deployment of SegWit.There is a proposal called "Capacity Increases for the Bitcoin System" that aims to solve scalability issues and make Bitcoin more stable. It suggests implementing a soft-fork SegWit 4MB block, which would increase capacity and scalability. Pieter Wuille supports this plan and believes it will improve productivity and the health of the community.Discussions also took place regarding the impact of segwit-spending inputs on block size. Different scenarios were explored, and optimizations were suggested to prevent abuse. There were also discussions on various topics related to Bitcoin development, including modifications to a struct for forward compatibility and moving the height to a more accessible place.The deployment of Segregated Witness (SegWit) via soft fork or hard fork was debated, with differing opinions on the best approach. Some argued that a hard fork would simplify merge-mining and reduce the size of fraud proofs, while others had concerns about security assumptions for non-upgraded clients. The question of whether the current state of affairs is acceptable to heavy users of the Bitcoin network was also raised.Overall, these discussions focused on the potential benefits and implementation of SegWit in Bitcoin transactions. There were debates on the placement of the segwit merkle root and whether a soft fork or hard fork would be more beneficial. The community continues to work towards finding solutions to scale Bitcoin and increase its capacity.In order to increase scalability and capacity, a proposal has been made to implement a soft-fork to Bitcoin. This proposal involves separating signatures from the main block, which would bypass the current blocksize limit and offer other benefits such as enhanced safety and elimination of signature malleability problems. The implementation of this proposal could lead to a 2x capacity increase and make future capacity expansions safer and more efficient.A working implementation of this proposal can be found at https://github.com/sipa/bitcoin/commits/segwit. Additionally, efforts are being made to develop more efficient block relay techniques that would reduce propagation latency. The author also emphasizes the significance of non-bandwidth scaling mechanisms, such as transaction cut-through and bidirectional payment channels, which utilize smart contracts to increase capacity and speed. These approaches have the potential for high capacity and decentralization.There are other proposals being explored, such as flexible caps or incentive-aligned dynamic block size controls, to maintain the alignment of incentives between miners and node operators. The author also highlights the importance of being prepared to implement moderate block size increases when improvements and understanding make their risks widely acceptable compared to the risks of not deploying them.Overall, the author believes that recent progress has positioned the Bitcoin ecosystem well to address its current capacity needs while setting the stage for further improvement and evolution. 2016-01-22T09:46:18+00:00 + Recent discussions among Bitcoin developers have centered around the implementation of Segregated Witness (SegWit) in Bitcoin transactions. The focus is on increasing efficiency for pay-to-public-key-hash (p2pkh) transactions. The latest segwit code utilizes "OP_0 [hash]" to push the version and hash separately, resulting in a reduction of 5 bytes per output for p2pkh transactions. This improvement is expected to lead to an increase in p2pkh and multisig transactions.Implementing SegWit would come at a cost, with the scaling factors estimated to be 170% for p2pkh transactions and 250%-300% for multisig transactions. The effective block size for p2pkh with SegWit is estimated to be 1.7MB, while for 2/2 multisig it is 2MB. Additionally, there are two potential soft-fork improvements that could make p2pkh and multisig more space efficient: ECDSA public key recovery and Schnorr signatures.The deployment of SegWit as a hardfork is supported by some defenders as it would solve scalability problems and make Bitcoin more stable. However, they also support the softfork version of SegWit, which is currently available. The plan is to do a softfork first and then a hardfork to move the witness tree outside of the coinbase. This approach is seen as exciting and believed to accelerate the deployment of SegWit.There is a proposal called "Capacity Increases for the Bitcoin System" that aims to solve scalability issues and make Bitcoin more stable. It suggests implementing a soft-fork SegWit 4MB block, which would increase capacity and scalability. Pieter Wuille supports this plan and believes it will improve productivity and the health of the community.Discussions also took place regarding the impact of segwit-spending inputs on block size. Different scenarios were explored, and optimizations were suggested to prevent abuse. There were also discussions on various topics related to Bitcoin development, including modifications to a struct for forward compatibility and moving the height to a more accessible place.The deployment of Segregated Witness (SegWit) via soft fork or hard fork was debated, with differing opinions on the best approach. Some argued that a hard fork would simplify merge-mining and reduce the size of fraud proofs, while others had concerns about security assumptions for non-upgraded clients. The question of whether the current state of affairs is acceptable to heavy users of the Bitcoin network was also raised.Overall, these discussions focused on the potential benefits and implementation of SegWit in Bitcoin transactions. There were debates on the placement of the segwit merkle root and whether a soft fork or hard fork would be more beneficial. The community continues to work towards finding solutions to scale Bitcoin and increase its capacity.In order to increase scalability and capacity, a proposal has been made to implement a soft-fork to Bitcoin. This proposal involves separating signatures from the main block, which would bypass the current blocksize limit and offer other benefits such as enhanced safety and elimination of signature malleability problems. The implementation of this proposal could lead to a 2x capacity increase and make future capacity expansions safer and more efficient.A working implementation of this proposal can be found at https://github.com/sipa/bitcoin/commits/segwit. Additionally, efforts are being made to develop more efficient block relay techniques that would reduce propagation latency. The author also emphasizes the significance of non-bandwidth scaling mechanisms, such as transaction cut-through and bidirectional payment channels, which utilize smart contracts to increase capacity and speed. These approaches have the potential for high capacity and decentralization.There are other proposals being explored, such as flexible caps or incentive-aligned dynamic block size controls, to maintain the alignment of incentives between miners and node operators. The author also highlights the importance of being prepared to implement moderate block size increases when improvements and understanding make their risks widely acceptable compared to the risks of not deploying them.Overall, the author believes that recent progress has positioned the Bitcoin ecosystem well to address its current capacity needs while setting the stage for further improvement and evolution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Fee-smoothing.xml b/static/bitcoin-dev/Jan_2016/combined_Fee-smoothing.xml index 76d23c714a..b0a76c0c84 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Fee-smoothing.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Fee-smoothing.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fee smoothing - 2023-08-01T17:39:25.726712+00:00 + 2025-09-26T15:28:22.270068+00:00 + python-feedgen Luzius Meisser 2016-01-28 20:16:41+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Fee smoothing - 2023-08-01T17:39:25.726712+00:00 + 2025-09-26T15:28:22.270246+00:00 - The ongoing debate around Bitcoin block size has sparked discussions among developers about proposed solutions. One developer, Warren Togami Jr., argues against a proposal like BIP100, which allows miners to vote on the block size, stating that it does not align with the marginal cost of the entire network. Instead, he suggests a flex cap mechanism that allows for block size to grow with actual demand and be based on the actual costs of miners. This mechanism can either ensure supply is based on the actual costs of miners or replace the current constant cap with a centrally planned supply curve. Togami believes the former option would lead to a competitive equilibrium with free market prices.Luzius Meisser proposes an idea where only 10% of the collected fees in a block are paid out to the miner, with the remaining 90% added to the collected fees of the next block. This creates a rolling average of collected fees from current and past blocks. However, Togami argues against mandatory sharing, as miners could take payment out-of-band and confirm transactions with little or no visible fees in the block. Meisser also suggests a flex cap solution where miners can buy additional space for an exponentially increasing fee, with the price subtracted from the collected fees and added to the reward of the next block. The amount spent by miners on additional space allows for the calculation of their marginal costs per transaction. Every 1000 blocks, the basic cap is adjusted based on whether the average fees per KB were above or below the global cost estimate.Togami suggests allowing miners to vote on block size, but warns that this could lead to a cartel among miners charging monopoly prices instead of competitive ones. He argues that the transaction fees under BIP100 would be higher than those under a flex cap mechanism based on total marginal costs of miners. He believes a holistic analysis is necessary to understand the benefits of running a full node, and increasing block sizes can make it more attractive to run a full node depending on the circumstances.In an email exchange between Luzius Meisser and Warren, the two discuss the viability of the Flex Cap approach to block size scaling in Bitcoin. Meisser agrees with the approach but emphasizes that it should not rely on significant block subsidies for long-term sustainability. Warren proposes an alternative variant of the approach, allowing miners to pay with a higher difficulty target instead of deferring subsidy to later blocks. The discussion then shifts to the suboptimality of proposals like BIP100, where the block size is subject to a vote by miners. Warren argues that this type of vote only aligns with the miner's marginal cost, rather than the marginal cost to the entire network. He believes the Flex Cap approach is superior because it has an actual cost associated with it and allows block size to grow with actual demand.The proposal of only paying out 10% of collected fees to the miner who mined the block and adding the remaining 90% to the next block's fees is debated. Concerns are raised about miners taking payment out-of-band and creating rules for transactions included in a block. The ongoing research on the Flex Cap approach could provide a viable solution to aligning miner's supply incentives with global marginal costs. Under this approach, block size can burst higher on a per-block basis if the miner is willing to defer a portion of the current block subsidy to later blocks. The proposed flex cap scheme involves miners buying additional space at an exponentially increasing fee, with the price subtracted from collected fees and added to the reward of the next block. The basic cap is adjusted every 1000 blocks based on average fees per KB compared to the global cost estimate.Another proposal to smooth the payout of fees across blocks is discussed among members of the bitcoin-dev community. The idea suggests paying out only 10% of collected fees in a block to the miner and adding the remaining 90% to the collected fees of the next block, creating a rolling average of fees. This proposal aims to reduce the marginal benefit of including additional transactions in a block, aligning incentives of individual miners with the whole network and reducing the disadvantage of mining with a slow connection. However, concerns are raised about increased orphan risk, reduced rewards, and potential incentive problems such as mining empty blocks to minimize the chance of losing fees from previous blocks. One member suggests smoothing fees between the current and subsequent 5 blocks to reduce the incentive for replacing the current tip and conducting out-of-band payments. The Flex Cap approach is also mentioned as a way to align miner's supply incentives with global marginal costs.The author proposes to smooth the payout of fees across blocks, incentivizing decentralization and supporting the establishment of a fee market. This proposal reduces the marginal benefit of including additional transactions in a block, aligns incentives of miners with the whole network, and reduces the disadvantage of mining with a slow connection. It is a step towards a free fee market where prices approach the marginal costs of transactions. However, implementing this proposal may require a hard fork 2016-01-28T20:16:41+00:00 + The ongoing debate around Bitcoin block size has sparked discussions among developers about proposed solutions. One developer, Warren Togami Jr., argues against a proposal like BIP100, which allows miners to vote on the block size, stating that it does not align with the marginal cost of the entire network. Instead, he suggests a flex cap mechanism that allows for block size to grow with actual demand and be based on the actual costs of miners. This mechanism can either ensure supply is based on the actual costs of miners or replace the current constant cap with a centrally planned supply curve. Togami believes the former option would lead to a competitive equilibrium with free market prices.Luzius Meisser proposes an idea where only 10% of the collected fees in a block are paid out to the miner, with the remaining 90% added to the collected fees of the next block. This creates a rolling average of collected fees from current and past blocks. However, Togami argues against mandatory sharing, as miners could take payment out-of-band and confirm transactions with little or no visible fees in the block. Meisser also suggests a flex cap solution where miners can buy additional space for an exponentially increasing fee, with the price subtracted from the collected fees and added to the reward of the next block. The amount spent by miners on additional space allows for the calculation of their marginal costs per transaction. Every 1000 blocks, the basic cap is adjusted based on whether the average fees per KB were above or below the global cost estimate.Togami suggests allowing miners to vote on block size, but warns that this could lead to a cartel among miners charging monopoly prices instead of competitive ones. He argues that the transaction fees under BIP100 would be higher than those under a flex cap mechanism based on total marginal costs of miners. He believes a holistic analysis is necessary to understand the benefits of running a full node, and increasing block sizes can make it more attractive to run a full node depending on the circumstances.In an email exchange between Luzius Meisser and Warren, the two discuss the viability of the Flex Cap approach to block size scaling in Bitcoin. Meisser agrees with the approach but emphasizes that it should not rely on significant block subsidies for long-term sustainability. Warren proposes an alternative variant of the approach, allowing miners to pay with a higher difficulty target instead of deferring subsidy to later blocks. The discussion then shifts to the suboptimality of proposals like BIP100, where the block size is subject to a vote by miners. Warren argues that this type of vote only aligns with the miner's marginal cost, rather than the marginal cost to the entire network. He believes the Flex Cap approach is superior because it has an actual cost associated with it and allows block size to grow with actual demand.The proposal of only paying out 10% of collected fees to the miner who mined the block and adding the remaining 90% to the next block's fees is debated. Concerns are raised about miners taking payment out-of-band and creating rules for transactions included in a block. The ongoing research on the Flex Cap approach could provide a viable solution to aligning miner's supply incentives with global marginal costs. Under this approach, block size can burst higher on a per-block basis if the miner is willing to defer a portion of the current block subsidy to later blocks. The proposed flex cap scheme involves miners buying additional space at an exponentially increasing fee, with the price subtracted from collected fees and added to the reward of the next block. The basic cap is adjusted every 1000 blocks based on average fees per KB compared to the global cost estimate.Another proposal to smooth the payout of fees across blocks is discussed among members of the bitcoin-dev community. The idea suggests paying out only 10% of collected fees in a block to the miner and adding the remaining 90% to the collected fees of the next block, creating a rolling average of fees. This proposal aims to reduce the marginal benefit of including additional transactions in a block, aligning incentives of individual miners with the whole network and reducing the disadvantage of mining with a slow connection. However, concerns are raised about increased orphan risk, reduced rewards, and potential incentive problems such as mining empty blocks to minimize the chance of losing fees from previous blocks. One member suggests smoothing fees between the current and subsequent 5 blocks to reduce the incentive for replacing the current tip and conducting out-of-band payments. The Flex Cap approach is also mentioned as a way to align miner's supply incentives with global marginal costs.The author proposes to smooth the payout of fees across blocks, incentivizing decentralization and supporting the establishment of a fee market. This proposal reduces the marginal benefit of including additional transactions in a block, aligns incentives of miners with the whole network, and reduces the disadvantage of mining with a slow connection. It is a step towards a free fee market where prices approach the marginal costs of transactions. However, implementing this proposal may require a hard fork - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml b/static/bitcoin-dev/Jan_2016/combined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml index 4b005191fc..c3fc088afd 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Wallet Lock, Unlock BIP idea - 2023-08-01T17:34:33.505214+00:00 + 2025-09-26T15:28:45.532338+00:00 + python-feedgen Scott Morgan 2016-01-14 18:26:57+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Fwd: Wallet Lock, Unlock BIP idea - 2023-08-01T17:34:33.505214+00:00 + 2025-09-26T15:28:45.532489+00:00 - The writer discusses the importance of wallet encryption and suggests using third-party tools if the encryptwallet feature is not available. They acknowledge that any encryption can be broken but may not be profitable for intruders. The writer also addresses a concern about privacy ethics and proposes obfuscating information through one-way encryption in order to check if a wallet is locked without revealing a list of locked or unlocking wallets easily.The wallet provides encryption support through RPC calls like 'encryptwallet', 'walletpassphrase', and 'walletlock' to ensure that stolen wallet.dat files cannot be accessed without a passphrase. Scott Morgan has proposed a BIP to lock and unlock wallets in Bitcoin, suggesting that users could add an unlock period to their wallet, which would be confirmed like other transactions. Locked wallet transactions would not be confirmed during mining, and users would specify a wallet as unlocking by adding an unlocking date time in the blocks. This proposal differs from bip-0065, which adds a lock time to transactions that recipients must wait for before spending coins.Locking entire wallet addresses indefinitely with a specified unlock period is technically feasible but would have significant implications for the Bitcoin ecosystem. The proposed BIP aims to reduce theft by providing a method to lock and unlock wallets, although it may incur fees and slow down transaction creation and mining. Checking transactions to locked wallets could affect the price of BTC in fiat as the supply changes. Scott Morgan, a Privacy and Java evangelist, does not plan to work on the main bitcoin core but is mining to fund his company's open-source Java projects.Overall, wallet encryption is crucial for protecting wallet.dat files, and the proposed BIP offers a method to lock and unlock wallets, potentially reducing theft. However, implementing this proposal would have significant implications for the Bitcoin ecosystem. 2016-01-14T18:26:57+00:00 + The writer discusses the importance of wallet encryption and suggests using third-party tools if the encryptwallet feature is not available. They acknowledge that any encryption can be broken but may not be profitable for intruders. The writer also addresses a concern about privacy ethics and proposes obfuscating information through one-way encryption in order to check if a wallet is locked without revealing a list of locked or unlocking wallets easily.The wallet provides encryption support through RPC calls like 'encryptwallet', 'walletpassphrase', and 'walletlock' to ensure that stolen wallet.dat files cannot be accessed without a passphrase. Scott Morgan has proposed a BIP to lock and unlock wallets in Bitcoin, suggesting that users could add an unlock period to their wallet, which would be confirmed like other transactions. Locked wallet transactions would not be confirmed during mining, and users would specify a wallet as unlocking by adding an unlocking date time in the blocks. This proposal differs from bip-0065, which adds a lock time to transactions that recipients must wait for before spending coins.Locking entire wallet addresses indefinitely with a specified unlock period is technically feasible but would have significant implications for the Bitcoin ecosystem. The proposed BIP aims to reduce theft by providing a method to lock and unlock wallets, although it may incur fees and slow down transaction creation and mining. Checking transactions to locked wallets could affect the price of BTC in fiat as the supply changes. Scott Morgan, a Privacy and Java evangelist, does not plan to work on the main bitcoin core but is mining to fund his company's open-source Java projects.Overall, wallet encryption is crucial for protecting wallet.dat files, and the proposed BIP offers a method to lock and unlock wallets, potentially reducing theft. However, implementing this proposal would have significant implications for the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml b/static/bitcoin-dev/Jan_2016/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml index 3d27f0b2ca..838132398a 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Increasing the blocksize as a (generalized) softfork. - 2023-08-01T17:15:37.711773+00:00 + 2025-09-26T15:29:02.440259+00:00 + python-feedgen Luke Dashjr 2016-01-04 21:53:36+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Increasing the blocksize as a (generalized) softfork. - 2023-08-01T17:15:37.713836+00:00 + 2025-09-26T15:29:02.440434+00:00 - The email thread discussed the proposal of using a generalized softfork as an alternative to hard forks. Joe2015 proposed the idea, challenging the assumption that increasing the blocksize limit requires a hardfork. He introduced the concept of standard softforks, where after the fork, two potential chains exist - one valid under the new rules and old rules, and one valid under the old rules only. However, if more than 50% of the hashpower follows the new rules, the old chain is destined to be orphaned.Joe2015 then introduced the idea of a generalized softfork, which involves a transform function f(B)=B' that maps a block valid under the new rules to a block valid under the old rules. In this scenario, three chains may exist - the new chain valid under the new rules only, the mapped chain f(B3), f(B4), f(B5), and the old chain B3', B4', B5', valid under the old rules only. The Segregated Witness was given as an example of a generalized softfork, where the new block format combines the old block and witness data, and the function f() simply removes the witness data to create a valid block under the old rules.The paper then explained how to achieve arbitrary block-size increases through a generalized softfork. This proposal consisted of defining new rules for valid blocks and a transformation function f(). The new block rules were similar to the old rules but with some small changes. The function f() truncated the block so that it contained only the coinbase transaction. By combining these new rules and the transformation function, a generalized softfork could be implemented. This resulted in a new chain under the new rules, including an increased blocksize limit, which could be mapped to a valid chain under the old rules.It was noted that since all mapped blocks were empty, old clients would never see transactions confirming. The paper concluded by highlighting that increasing the blocksize limit is commonly believed to require a hardfork, but this draft demonstrated that it could be achieved using a generalized softfork. The author suggested further exploration of other types of hardforks that can be implemented as generalized softforks and the security implications that come with them. 2016-01-04T21:53:36+00:00 + The email thread discussed the proposal of using a generalized softfork as an alternative to hard forks. Joe2015 proposed the idea, challenging the assumption that increasing the blocksize limit requires a hardfork. He introduced the concept of standard softforks, where after the fork, two potential chains exist - one valid under the new rules and old rules, and one valid under the old rules only. However, if more than 50% of the hashpower follows the new rules, the old chain is destined to be orphaned.Joe2015 then introduced the idea of a generalized softfork, which involves a transform function f(B)=B' that maps a block valid under the new rules to a block valid under the old rules. In this scenario, three chains may exist - the new chain valid under the new rules only, the mapped chain f(B3), f(B4), f(B5), and the old chain B3', B4', B5', valid under the old rules only. The Segregated Witness was given as an example of a generalized softfork, where the new block format combines the old block and witness data, and the function f() simply removes the witness data to create a valid block under the old rules.The paper then explained how to achieve arbitrary block-size increases through a generalized softfork. This proposal consisted of defining new rules for valid blocks and a transformation function f(). The new block rules were similar to the old rules but with some small changes. The function f() truncated the block so that it contained only the coinbase transaction. By combining these new rules and the transformation function, a generalized softfork could be implemented. This resulted in a new chain under the new rules, including an increased blocksize limit, which could be mapped to a valid chain under the old rules.It was noted that since all mapped blocks were empty, old clients would never see transactions confirming. The paper concluded by highlighting that increasing the blocksize limit is commonly believed to require a hardfork, but this draft demonstrated that it could be achieved using a generalized softfork. The author suggested further exploration of other types of hardforks that can be implemented as generalized softforks and the security implications that come with them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Libconsensus-phase-2.xml b/static/bitcoin-dev/Jan_2016/combined_Libconsensus-phase-2.xml index acd0e43900..ae4e00dbd4 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Libconsensus-phase-2.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Libconsensus-phase-2.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Libconsensus phase 2 - 2023-08-01T17:34:18.183186+00:00 + 2025-09-26T15:28:56.098963+00:00 + python-feedgen Eric Voskuil 2016-01-13 22:47:44+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Libconsensus phase 2 - 2023-08-01T17:34:18.183186+00:00 + 2025-09-26T15:28:56.099126+00:00 - In an email conversation between Eric Voskuil and Jorge Timón, they discussed the development phases for a public blockchain interface. Timón plans to create a C++ interface that aligns better with Bitcoin Core internals. In the third phase, he aims to refine the storage interface by defining C interfaces using structs of function pointers instead of classes. The goal is to separate the consensus code from chain.o and coins.o so that they are not part of the consensus building package used for libbitcoinconsensus and Bitcoin Core.There was a disagreement between Timón and Luke Dashjr regarding the implementation of libbitcoinconsensus. Dashjr advocated for a storage-dependent version, while Timón believed in implementing both versions - one with a common store implementation and another allowing alternative implementations with custom storage. Timón was concerned that forcing users into a specific uniform storage would limit adoption.In a recent update, Timón shared that the goal for phase 2 of libconsensus encapsulation planning has changed. Instead of exposing only VerifyHeader(), the plan now is to build all the consensus critical code within the existing libconsensus library. This adjustment aims to make the project more feasible for a single Bitcoin Core release cycle. Timón also provided an outline for the upcoming phases, including refining the storage interfaces, renaming files, and making Bitcoin Core use libbitcoinconsensus through its generic C API.Timón discussed how exposing VerifyScript() through a C API solidified dependencies outside of the existing libbitcoinconsensus library. The plan is to gradually move all the necessary files listed in a Github pull request, and Timón encouraged others to get involved in this process.In a mailing list post, Timón further elaborated on the plan to decouple libconsensus from Bitcoin Core. The change in strategy involves building all the consensus critical code within the existing libconsensus library in phase 2. This will simplify the future exposure of VerifyHeader(), VerifyTx(), and VerifyBlock(). The subsequent phases include refining storage interfaces, renaming files, and using libbitcoinconsensus solely through its generic C API in Bitcoin Core.The work in progress branch for the project can be found on GitHub, and Timón intends to create an issue to move the necessary files one by one. They encouraged others to participate in this straightforward task that can be easily executed correctly. 2016-01-13T22:47:44+00:00 + In an email conversation between Eric Voskuil and Jorge Timón, they discussed the development phases for a public blockchain interface. Timón plans to create a C++ interface that aligns better with Bitcoin Core internals. In the third phase, he aims to refine the storage interface by defining C interfaces using structs of function pointers instead of classes. The goal is to separate the consensus code from chain.o and coins.o so that they are not part of the consensus building package used for libbitcoinconsensus and Bitcoin Core.There was a disagreement between Timón and Luke Dashjr regarding the implementation of libbitcoinconsensus. Dashjr advocated for a storage-dependent version, while Timón believed in implementing both versions - one with a common store implementation and another allowing alternative implementations with custom storage. Timón was concerned that forcing users into a specific uniform storage would limit adoption.In a recent update, Timón shared that the goal for phase 2 of libconsensus encapsulation planning has changed. Instead of exposing only VerifyHeader(), the plan now is to build all the consensus critical code within the existing libconsensus library. This adjustment aims to make the project more feasible for a single Bitcoin Core release cycle. Timón also provided an outline for the upcoming phases, including refining the storage interfaces, renaming files, and making Bitcoin Core use libbitcoinconsensus through its generic C API.Timón discussed how exposing VerifyScript() through a C API solidified dependencies outside of the existing libbitcoinconsensus library. The plan is to gradually move all the necessary files listed in a Github pull request, and Timón encouraged others to get involved in this process.In a mailing list post, Timón further elaborated on the plan to decouple libconsensus from Bitcoin Core. The change in strategy involves building all the consensus critical code within the existing libconsensus library in phase 2. This will simplify the future exposure of VerifyHeader(), VerifyTx(), and VerifyBlock(). The subsequent phases include refining storage interfaces, renaming files, and using libbitcoinconsensus solely through its generic C API in Bitcoin Core.The work in progress branch for the project can be found on GitHub, and Timón intends to create an issue to move the necessary files one by one. They encouraged others to participate in this straightforward task that can be easily executed correctly. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_New-BIP-editor-and-request-for-information.xml b/static/bitcoin-dev/Jan_2016/combined_New-BIP-editor-and-request-for-information.xml index 5415365c30..3d952f345d 100644 --- a/static/bitcoin-dev/Jan_2016/combined_New-BIP-editor-and-request-for-information.xml +++ b/static/bitcoin-dev/Jan_2016/combined_New-BIP-editor-and-request-for-information.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP editor, and request for information - 2023-08-01T17:32:09.265757+00:00 + 2025-09-26T15:28:51.872724+00:00 + python-feedgen Tier Nolan 2016-01-12 00:09:46+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - New BIP editor, and request for information - 2023-08-01T17:32:09.265757+00:00 + 2025-09-26T15:28:51.872920+00:00 - In an email exchange regarding Bitcoin Improvement Proposal (BIP) 46, Luke Dashjr noticed that it was missing from the repository but had apparently been self-assigned by Tier Nolan in a previous email. Dashjr suggested that if the proposal had been officially assigned or if Nolan was still interested in pursuing it, it would make sense to keep it at BIP 46. However, Nolan responded saying that he was never officially assigned any number for the proposal and subsequent changes made the BIP obsolete.Dashjr then recommended marking the number as nonassignable to prevent confusion with archive searches, assuming that new BIP numbers would be greater than 100 anyway. He also acknowledged that he should not have used a number in the original git branch before being officially assigned it.Luke has been asked to take over as the BIP editor responsible for assigning BIP numbers. Before starting his work, he wants to ensure that there is no overlapping in the assignment of BIPs. He has requested anyone who has been assigned a BIP number or has any relevant information to respond within 24 hours if possible.Luke provided specific details about missing and soft-assigned BIPs. BIP 46 is missing from the repository but was self-soft-assigned by Tier Nolan. It seems logical to keep it at BIP 46. BIPs 80 and 81 are part of an open pull request, and it's unclear whether they were formally assigned or not. BIP 82 is officially assigned and pending, but it falls outside the scope of BIPs since it does not deal with Bitcoin. Luke suggests Justus to move it to the SLIP standard, but he will honor this assignment unless informed otherwise.BIP 100 is missing from the repository, and Luke is unsure if it was ever properly assigned. Considering that the 10x block has mostly been used for similar proposals and BIP 100 is well-established as "BIP 100," it seems logical to make this its official assignment. BIP 104 is missing from the repository, and Luke is unsure about its status. There is no actual specification in the PDF.BIP 109 was soft-assigned, but it does not fit with the rest of 10x. Luke is inclined to give it a new number outside that range unless there are objections. BIP 122 is missing from the repository, and it was self-soft-assigned by Chris Priest for "ScaleNet." There are concerns about whether testnets are appropriate for standardization, but it seems reasonable to assign it a BIP number if Chris wishes to further pursue the idea and add an actual specification to the draft.Luke has requested anyone aware of any other BIP assignments, except for BIPs 82 and 109, and those appearing in the https://github.com/bitcoin/bips repository at present, to reply to his message indicating the status of such BIPs and their assigned numbers. 2016-01-12T00:09:46+00:00 + In an email exchange regarding Bitcoin Improvement Proposal (BIP) 46, Luke Dashjr noticed that it was missing from the repository but had apparently been self-assigned by Tier Nolan in a previous email. Dashjr suggested that if the proposal had been officially assigned or if Nolan was still interested in pursuing it, it would make sense to keep it at BIP 46. However, Nolan responded saying that he was never officially assigned any number for the proposal and subsequent changes made the BIP obsolete.Dashjr then recommended marking the number as nonassignable to prevent confusion with archive searches, assuming that new BIP numbers would be greater than 100 anyway. He also acknowledged that he should not have used a number in the original git branch before being officially assigned it.Luke has been asked to take over as the BIP editor responsible for assigning BIP numbers. Before starting his work, he wants to ensure that there is no overlapping in the assignment of BIPs. He has requested anyone who has been assigned a BIP number or has any relevant information to respond within 24 hours if possible.Luke provided specific details about missing and soft-assigned BIPs. BIP 46 is missing from the repository but was self-soft-assigned by Tier Nolan. It seems logical to keep it at BIP 46. BIPs 80 and 81 are part of an open pull request, and it's unclear whether they were formally assigned or not. BIP 82 is officially assigned and pending, but it falls outside the scope of BIPs since it does not deal with Bitcoin. Luke suggests Justus to move it to the SLIP standard, but he will honor this assignment unless informed otherwise.BIP 100 is missing from the repository, and Luke is unsure if it was ever properly assigned. Considering that the 10x block has mostly been used for similar proposals and BIP 100 is well-established as "BIP 100," it seems logical to make this its official assignment. BIP 104 is missing from the repository, and Luke is unsure about its status. There is no actual specification in the PDF.BIP 109 was soft-assigned, but it does not fit with the rest of 10x. Luke is inclined to give it a new number outside that range unless there are objections. BIP 122 is missing from the repository, and it was self-soft-assigned by Chris Priest for "ScaleNet." There are concerns about whether testnets are appropriate for standardization, but it seems reasonable to assign it a BIP number if Chris wishes to further pursue the idea and add an actual specification to the draft.Luke has requested anyone aware of any other BIP assignments, except for BIPs 82 and 109, and those appearing in the https://github.com/bitcoin/bips repository at present, to reply to his message indicating the status of such BIPs and their assigned numbers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_SegWit-GBT-updates.xml b/static/bitcoin-dev/Jan_2016/combined_SegWit-GBT-updates.xml index 6881d38b9b..d68f29722f 100644 --- a/static/bitcoin-dev/Jan_2016/combined_SegWit-GBT-updates.xml +++ b/static/bitcoin-dev/Jan_2016/combined_SegWit-GBT-updates.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SegWit GBT updates - 2023-08-01T17:41:26.093139+00:00 + 2025-09-26T15:28:37.069919+00:00 + python-feedgen Luke Dashjr 2016-02-02 02:30:55+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - SegWit GBT updates - 2023-08-01T17:41:26.093139+00:00 + 2025-09-26T15:28:37.070061+00:00 - The discussion revolves around the inclusion of the "default_witness_commitment" in the standard protocol. One argument against including it is that it may lead to centralization of mining pools and make server-side implementation more susceptible to DoS attacks. However, there is also an argument for including it to simplify initial adoption and have a known-correct value to use. It is mentioned that libblkmaker can handle the heavy lifting for mining software. Ultimately, the decision to include or exclude "default_witness_commitment" depends on the specific implementation and goals.In the email exchange between Luke Dashjr and Cory Fields, they discuss the default witness commitment for GBT (GetBlockTemplate) protocol. Dashjr argues that including it could enable centralization, while Fields suggests that providing a known-working commitment would be beneficial for adoption. Dashjr expresses concerns about security and suggests leaving out the default witness commitment from the standard protocol. Fields seeks clarification on potential DoS vectors and the use of libblkmaker. Dashjr reassures that the burden on mining software is not significant and that libblkmaker can handle the heavy lifting. He also mentions the need to consider the sign bit when serializing heights and the risk of introducing bugs into working code.The conversation on February 1, 2016, between Cory Fields and Luke Dashjr delves into the use of "default_witness_commitment" within the GBT protocol. Dashjr argues against including it in the standard protocol, as it contradicts GBT's design principles by enabling and encouraging centralization. Fields raises the point that providing a known-working commitment can simplify the process. Dashjr acknowledges this but emphasizes the potential for bugs. They also discuss a bug introduced by ckpool, where a positive number was serialized as a signed one.Another discussion between Luke Dashjr and Cory Fields focuses on the omission of the "default_witness_commitment" key in the Bitcoin protocol. Fields believes that omitting it would encourage pools to build their own commitment, while Dashjr argues that it could increase vulnerability to DoS attacks. Dashjr suggests leaving it as a bitcoind-specific extension to promote adoption but recommends keeping it out of the standard protocol for now. Fields expresses concerns about the burden on mining software and the risk of bugs, but Dashjr highlights the capability of libblkmaker to handle the heavy lifting. Fields mentions fixing serialization or commitment creation bugs in mining/pool software.The email conversation discusses the absence of the "default_witness_commitment" key in the current reference implementation. The omission allows clients to create the commitment themselves instead of having it provided. However, this simplicity can encourage laziness and complicate server-side implementation, making it more vulnerable to DoS attacks. The burden on mining software increases, raising the odds of bugs. It is mentioned that serialization or commitment creation bugs related to mining/pool software have already been fixed in SegWit.Luke Dashjr has drafted a BIP for updating getblocktemplate for segregated witness. The draft does not include the "default_witness_commitment" key present in the current reference implementation. This omission allows clients to create their commitment instead of relying on provided values. However, excluding the key increases the burden on mining software and the likelihood of bugs. Cory supports this argument and plans to submit the change to the BIP, enabling mining software to handle more serialization and complex structure calculations. Links to related sources are provided.Luke-jr has announced the creation of an initial draft for a BIP regarding getblocktemplate for segregated witness. The draft is available on GitHub, and Luke-jr invites others to review and comment on the changes made, particularly with regard to sigoplimits handling. However, he notes that libblkmaker's reference implementation is currently incompatible with the "last output" rule in this BIP. Luke-jr expresses gratitude in advance for any feedback received. 2016-02-02T02:30:55+00:00 + The discussion revolves around the inclusion of the "default_witness_commitment" in the standard protocol. One argument against including it is that it may lead to centralization of mining pools and make server-side implementation more susceptible to DoS attacks. However, there is also an argument for including it to simplify initial adoption and have a known-correct value to use. It is mentioned that libblkmaker can handle the heavy lifting for mining software. Ultimately, the decision to include or exclude "default_witness_commitment" depends on the specific implementation and goals.In the email exchange between Luke Dashjr and Cory Fields, they discuss the default witness commitment for GBT (GetBlockTemplate) protocol. Dashjr argues that including it could enable centralization, while Fields suggests that providing a known-working commitment would be beneficial for adoption. Dashjr expresses concerns about security and suggests leaving out the default witness commitment from the standard protocol. Fields seeks clarification on potential DoS vectors and the use of libblkmaker. Dashjr reassures that the burden on mining software is not significant and that libblkmaker can handle the heavy lifting. He also mentions the need to consider the sign bit when serializing heights and the risk of introducing bugs into working code.The conversation on February 1, 2016, between Cory Fields and Luke Dashjr delves into the use of "default_witness_commitment" within the GBT protocol. Dashjr argues against including it in the standard protocol, as it contradicts GBT's design principles by enabling and encouraging centralization. Fields raises the point that providing a known-working commitment can simplify the process. Dashjr acknowledges this but emphasizes the potential for bugs. They also discuss a bug introduced by ckpool, where a positive number was serialized as a signed one.Another discussion between Luke Dashjr and Cory Fields focuses on the omission of the "default_witness_commitment" key in the Bitcoin protocol. Fields believes that omitting it would encourage pools to build their own commitment, while Dashjr argues that it could increase vulnerability to DoS attacks. Dashjr suggests leaving it as a bitcoind-specific extension to promote adoption but recommends keeping it out of the standard protocol for now. Fields expresses concerns about the burden on mining software and the risk of bugs, but Dashjr highlights the capability of libblkmaker to handle the heavy lifting. Fields mentions fixing serialization or commitment creation bugs in mining/pool software.The email conversation discusses the absence of the "default_witness_commitment" key in the current reference implementation. The omission allows clients to create the commitment themselves instead of having it provided. However, this simplicity can encourage laziness and complicate server-side implementation, making it more vulnerable to DoS attacks. The burden on mining software increases, raising the odds of bugs. It is mentioned that serialization or commitment creation bugs related to mining/pool software have already been fixed in SegWit.Luke Dashjr has drafted a BIP for updating getblocktemplate for segregated witness. The draft does not include the "default_witness_commitment" key present in the current reference implementation. This omission allows clients to create their commitment instead of relying on provided values. However, excluding the key increases the burden on mining software and the likelihood of bugs. Cory supports this argument and plans to submit the change to the BIP, enabling mining software to handle more serialization and complex structure calculations. Links to related sources are provided.Luke-jr has announced the creation of an initial draft for a BIP regarding getblocktemplate for segregated witness. The draft is available on GitHub, and Luke-jr invites others to review and comment on the changes made, particularly with regard to sigoplimits handling. However, he notes that libblkmaker's reference implementation is currently incompatible with the "last output" rule in this BIP. Luke-jr expresses gratitude in advance for any feedback received. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_SegWit-testnet-is-live.xml b/static/bitcoin-dev/Jan_2016/combined_SegWit-testnet-is-live.xml index 153510b179..8ecec44480 100644 --- a/static/bitcoin-dev/Jan_2016/combined_SegWit-testnet-is-live.xml +++ b/static/bitcoin-dev/Jan_2016/combined_SegWit-testnet-is-live.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SegWit testnet is live - 2023-08-01T17:31:45.065784+00:00 + 2025-09-26T15:28:20.156804+00:00 + python-feedgen Jameson Lopp 2016-01-08 15:35:27+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - SegWit testnet is live - 2023-08-01T17:31:45.065784+00:00 + 2025-09-26T15:28:20.156936+00:00 - BitGo, a digital asset security platform, has successfully implemented Segregated Witness (SegWit) transactions for Bitcoin. They are now waiting for the activation of SegWit on the Bitcoin network before offering support to their customers. Other companies such as BlockCypher and Breadwallet have also committed to supporting SegWit transactions in the near future. SegWit is expected to bring several benefits to the Bitcoin network, including increased capacity and improved transaction malleability.In December 2015, Eric Lombrozo announced the successful running of a segregated witness testnet called segnet. This testnet has rudimentary wallets with support already implemented. Several wallets, including mSIGNA, GreenAddress, GreenBits, Blocktrail, and NBitcoin, have committed to supporting SegWit. Breadwallet has also joined in supporting segwit. More wallets are expected to add their support soon.Interested wallet developers can contact Eric Lombrozo for development and testing on segnet. The source code for segnet can be found at sipa's Github repository, and an example signing code is available at Eric's Github repository. SegWit is expected to enable fundamental improvements to bitcoin, and its implementation is on schedule. 2016-01-08T15:35:27+00:00 + BitGo, a digital asset security platform, has successfully implemented Segregated Witness (SegWit) transactions for Bitcoin. They are now waiting for the activation of SegWit on the Bitcoin network before offering support to their customers. Other companies such as BlockCypher and Breadwallet have also committed to supporting SegWit transactions in the near future. SegWit is expected to bring several benefits to the Bitcoin network, including increased capacity and improved transaction malleability.In December 2015, Eric Lombrozo announced the successful running of a segregated witness testnet called segnet. This testnet has rudimentary wallets with support already implemented. Several wallets, including mSIGNA, GreenAddress, GreenBits, Blocktrail, and NBitcoin, have committed to supporting SegWit. Breadwallet has also joined in supporting segwit. More wallets are expected to add their support soon.Interested wallet developers can contact Eric Lombrozo for development and testing on segnet. The source code for segnet can be found at sipa's Github repository, and an example signing code is available at Eric's Github repository. SegWit is expected to enable fundamental improvements to bitcoin, and its implementation is on schedule. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-App-Development.xml b/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-App-Development.xml index 8a99ce77ec..c173e2e2c1 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-App-Development.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-App-Development.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segregated Witness App Development - 2023-08-01T17:35:48.417599+00:00 + 2025-09-26T15:28:41.303195+00:00 + python-feedgen Bryan Bishop 2016-01-19 16:31:17+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Segregated Witness App Development - 2023-08-01T17:35:48.417599+00:00 + 2025-09-26T15:28:41.303367+00:00 - During a discussion on the Bitcoin-dev mailing list, Mark Friedenbach suggested that the discussion about SegWit should be kept within the #bitcoin-dev channel to avoid fragmentation of communication channels. Bryan agreed, stating that although it may be necessary to create a new channel if the discussion becomes overwhelming, it would be preferable to keep it within the existing venue.In response to this, Eric Lombrozo has created a new IRC channel called #segwit-dev. This channel is specifically dedicated to integrating and supporting segregated witness transactions in wallets, as well as providing a platform for comments and suggestions to improve the spec. Eric extended an invitation to all members of the bitcoin-dev community who share the objective of this channel.However, some members expressed concerns about fragmenting the communication channels and associated infrastructure, such as logs and bots. They argued that discussions related to SegWit should take place in the #bitcoin-dev channel instead. Eric has informed the community about the creation of the new IRC channel, #segwit-dev, emphasizing its purpose of discussing segregated witness transactions and soliciting feedback on the spec. He encourages everyone to join the channel and actively participate in the discussions. 2016-01-19T16:31:17+00:00 + During a discussion on the Bitcoin-dev mailing list, Mark Friedenbach suggested that the discussion about SegWit should be kept within the #bitcoin-dev channel to avoid fragmentation of communication channels. Bryan agreed, stating that although it may be necessary to create a new channel if the discussion becomes overwhelming, it would be preferable to keep it within the existing venue.In response to this, Eric Lombrozo has created a new IRC channel called #segwit-dev. This channel is specifically dedicated to integrating and supporting segregated witness transactions in wallets, as well as providing a platform for comments and suggestions to improve the spec. Eric extended an invitation to all members of the bitcoin-dev community who share the objective of this channel.However, some members expressed concerns about fragmenting the communication channels and associated infrastructure, such as logs and bots. They argued that discussions related to SegWit should take place in the #bitcoin-dev channel instead. Eric has informed the community about the creation of the new IRC channel, #segwit-dev, emphasizing its purpose of discussing segregated witness transactions and soliciting feedback on the spec. He encourages everyone to join the channel and actively participate in the discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-BIPs.xml b/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-BIPs.xml index 7e8f5e01d1..a81185f5d5 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-BIPs.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-BIPs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segregated Witness BIPs - 2023-08-01T17:18:20.571872+00:00 + 2025-09-26T15:28:32.842024+00:00 + python-feedgen jl2012 2016-01-05 05:43:41+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Segregated Witness BIPs - 2023-08-01T17:18:20.571872+00:00 + 2025-09-26T15:28:32.842196+00:00 - The Bitcoin Improvement Proposal (BIP) process allows for changes to be suggested and implemented in the Bitcoin protocol. A new BIP has been proposed as part of the Segregated Witness (SegWit) soft fork, specifically addressing a new transaction digest algorithm for signature verification. The goal of this proposal is to minimize redundant data hashing and cover the input value by the signature.In addition to this proposal, a new BIP draft for a SW payment address format has been prepared and is awaiting BIP number assignment. This is the third BIP for SegWit, with another one being prepared by Eric Lombrozo for Peer Services. Eric Lombrozo and jl2012 have been working on these BIPs based on earlier discussions from Pieter Wuille's implementation.There are three separate BIPs being considered: Consensus BIP, Peer Services BIP, and Applications BIP. The Consensus BIP has already been submitted as a draft and covers witness structures, cost metrics and limits, scripting system (witness programs), and the soft fork mechanism. On the other hand, the Peer Services BIP will focus on relay message structures, witnesstx serialization, and other issues related to the p2p protocol such as IBD, synchronization, tx and block propagation. Lastly, the Applications BIP will address scriptPubKey encoding formats and other concerns regarding wallet interoperability.Overall, the development team is actively working on multiple BIPs related to the SegWit implementation, aiming to improve various aspects of the Bitcoin protocol. 2016-01-05T05:43:41+00:00 + The Bitcoin Improvement Proposal (BIP) process allows for changes to be suggested and implemented in the Bitcoin protocol. A new BIP has been proposed as part of the Segregated Witness (SegWit) soft fork, specifically addressing a new transaction digest algorithm for signature verification. The goal of this proposal is to minimize redundant data hashing and cover the input value by the signature.In addition to this proposal, a new BIP draft for a SW payment address format has been prepared and is awaiting BIP number assignment. This is the third BIP for SegWit, with another one being prepared by Eric Lombrozo for Peer Services. Eric Lombrozo and jl2012 have been working on these BIPs based on earlier discussions from Pieter Wuille's implementation.There are three separate BIPs being considered: Consensus BIP, Peer Services BIP, and Applications BIP. The Consensus BIP has already been submitted as a draft and covers witness structures, cost metrics and limits, scripting system (witness programs), and the soft fork mechanism. On the other hand, the Peer Services BIP will focus on relay message structures, witnesstx serialization, and other issues related to the p2p protocol such as IBD, synchronization, tx and block propagation. Lastly, the Applications BIP will address scriptPubKey encoding formats and other concerns regarding wallet interoperability.Overall, the development team is actively working on multiple BIPs related to the SegWit implementation, aiming to improve various aspects of the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Segregated-witnesses-and-validationless-mining.xml b/static/bitcoin-dev/Jan_2016/combined_Segregated-witnesses-and-validationless-mining.xml index 4c221759e1..d15fd1ca79 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Segregated-witnesses-and-validationless-mining.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Segregated-witnesses-and-validationless-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segregated witnesses and validationless mining - 2023-08-01T17:17:47.312812+00:00 + 2025-09-26T15:29:00.327468+00:00 + python-feedgen Bryan Bishop 2016-01-02 16:54:43+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Segregated witnesses and validationless mining - 2023-08-01T17:17:47.312812+00:00 + 2025-09-26T15:29:00.327632+00:00 - On December 28th, 2015, an IRC discussion took place regarding various updates related to Bitcoin. The discussion covered topics such as prior-block possession proofs, fraud proofs, non-fraud correctness proofs, commitments, and segwit. Jorge Timón requested a link to the IRC discussion in an email sent on January 2nd, 2016 at 10:37 AM. The email signature included Bryan's personal website and phone number. Peter Todd, a member of the Bitcoin-dev community, posted on January 1, 2016, asking for a link to the IRC discussion. He had previously provided updates from the same discussion in a post on December 22, 2015, but did not include any details about the discussion itself.In the IRC discussion, there was a debate about what should be required from the current block to calculate the previous block possession proof. It was suggested that the nonce could be picked arbitrarily, allowing for future soft-forks to add commitments to the current block contents. Fraud proofs were also discussed, with Pieter Wuille bringing up the idea of structuring the possession proof as a merkle tree to easily prove fraud using a merkle path.Bitcoin developer Peter Todd proposed a solution to return segregated witnesses to the status quo. This solution involves making the previous block's witness data a precondition for creating a block with transactions. This can be achieved by including the previous witness data, hashed with a different hash function than the commitment in the previous block, in the current block's coinbase txouts calculation. However, this solution may face resistance from miners currently using validationless mining techniques. To retain the possibility of validationless mining, empty blocks can be created if the previous witness data proof is omitted.Segregated witnesses separate transaction information from the information proving their legitimacy, making validationless mining more profitable. To address this issue, the protocol can be changed to require a copy of the previous block's witness data as a precondition for creating a block. This soft-fork solution aims to prevent the main code path from creating blocks without any validation. Additionally, it is proposed that adding a random selection of previous blocks to the previous witness data proof solution could address concerns about miner theft and currency inflation.In conclusion, the IRC discussion covered various topics related to Bitcoin, including possession proofs, fraud proofs, commitments, and segwit. Peter Todd proposed a solution to bring segregated witnesses back to the status quo by making the previous block's witness data a precondition for block creation. This solution may face pushback from miners using validationless mining techniques. To address this, empty blocks can be created if the previous witness data proof is omitted. The discussion also explored the potential benefits of validationless mining and solutions to address concerns about miner theft and currency inflation. 2016-01-02T16:54:43+00:00 + On December 28th, 2015, an IRC discussion took place regarding various updates related to Bitcoin. The discussion covered topics such as prior-block possession proofs, fraud proofs, non-fraud correctness proofs, commitments, and segwit. Jorge Timón requested a link to the IRC discussion in an email sent on January 2nd, 2016 at 10:37 AM. The email signature included Bryan's personal website and phone number. Peter Todd, a member of the Bitcoin-dev community, posted on January 1, 2016, asking for a link to the IRC discussion. He had previously provided updates from the same discussion in a post on December 22, 2015, but did not include any details about the discussion itself.In the IRC discussion, there was a debate about what should be required from the current block to calculate the previous block possession proof. It was suggested that the nonce could be picked arbitrarily, allowing for future soft-forks to add commitments to the current block contents. Fraud proofs were also discussed, with Pieter Wuille bringing up the idea of structuring the possession proof as a merkle tree to easily prove fraud using a merkle path.Bitcoin developer Peter Todd proposed a solution to return segregated witnesses to the status quo. This solution involves making the previous block's witness data a precondition for creating a block with transactions. This can be achieved by including the previous witness data, hashed with a different hash function than the commitment in the previous block, in the current block's coinbase txouts calculation. However, this solution may face resistance from miners currently using validationless mining techniques. To retain the possibility of validationless mining, empty blocks can be created if the previous witness data proof is omitted.Segregated witnesses separate transaction information from the information proving their legitimacy, making validationless mining more profitable. To address this issue, the protocol can be changed to require a copy of the previous block's witness data as a precondition for creating a block. This soft-fork solution aims to prevent the main code path from creating blocks without any validation. Additionally, it is proposed that adding a random selection of previous blocks to the previous witness data proof solution could address concerns about miner theft and currency inflation.In conclusion, the IRC discussion covered various topics related to Bitcoin, including possession proofs, fraud proofs, commitments, and segwit. Peter Todd proposed a solution to bring segregated witnesses back to the status quo by making the previous block's witness data a precondition for block creation. This solution may face pushback from miners using validationless mining techniques. To address this, empty blocks can be created if the previous witness data proof is omitted. The discussion also explored the potential benefits of validationless mining and solutions to address concerns about miner theft and currency inflation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml b/static/bitcoin-dev/Jan_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml index 9ee7fb5a28..5c2d86666e 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segwit Upgrade Procedures & Block Extension Data - 2023-08-01T17:39:45.031342+00:00 + 2025-09-26T15:28:43.416465+00:00 + python-feedgen Tier Nolan 2016-02-01 19:29:32+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Segwit Upgrade Procedures & Block Extension Data - 2023-08-01T17:39:45.031342+00:00 + 2025-09-26T15:28:43.416608+00:00 - On February 1, 2016, Pieter Wuille proposed a second number push in the coinbase scriptSig, which would point to a 32-byte hash H. This push was accepted as it provided a more flexible and compact system than the current one. Concerns were raised about adding arbitrary data, so it was suggested that the data in the coinbase witness stack have a fixed number of entries depending on the block version number. This would allow for soft-forks to add new entries in the stack.Peter Todd discussed upgrade procedures related to segregated witnesses, suggesting the addition of a new service bit or bumping the protocol version. However, this solution did not address the issue of relaying more block data in the future, requiring another soft-fork upgrade. To solve this problem, Todd proposed making the witness data more extensible by using unvalidated block extension data. This involved a backward-incompatible change to the current segwit change, where the coinbase scriptSig would receive a second number push pointing to a 32-byte hash H. Todd also addressed concerns about miners using arbitrary data by suggesting a merkelized key:value mapping with collision-resistant IDs as keys.Pieter Wuille's segwit branch was discussed on the Bitcoin developers mailing list. It was suggested to add a new service bit or bump up the protocol version to only connect to peers with segwit support. The branch had a fHaveWitness flag for each connection, but BIP144 proposed changing this to a service bit. A pull request to change this to a NODE_WITNESS service bit has been made on GitHub.Peter Todd suggested adding a new service bit, NODE_SEGWIT, and/or bumping the protocol version to ensure outgoing peers only connect to peers with segwit support. He also proposed solutions for future upgrades adding new block data, such as removing the restriction on the coinbase witness containing exactly one 32-byte value. Another proposal involved hashing the contents of the coinbase witness as a merkle tree and committing them in place of the current nonce commitment. These proposals were discussed in a pull request on the segwit branch, including the idea of including the merkle path to the segwit data in the coinbase witness.The deployment of segregated witness poses a problem as nodes need witness data to function after activation. If full node adoption lags behind miner adoption, the segwit-supporting P2P network may partition and lose consensus. The issue is not yet fixed in Pieter Wuille's segwit branch, but one solution is to add a new service bit or bump the protocol version to only connect to peers with segwit support. However, if full node operators do not widely adopt segwit, the network could become more vulnerable. Future upgrades will require the relay network to upgrade, and BIP141 suggests an Extensible Commitment Structure to address this. This structure consists of a hashed linked list of consensus-critical commitments, with a redefinable nonce for future soft-forks. To allow for additional data in future soft-forks, the proposal is to remove the restriction on the coinbase witness, hash its contents as a merkle tree, and include that data in the blocksize limit. This allows all nodes to validate the data came from the miner and propagate it without risk of attack. This method is efficient as most future upgrades are expected to be additional commitments, and the additional data for each commitment is just 32 bytes. 2016-02-01T19:29:32+00:00 + On February 1, 2016, Pieter Wuille proposed a second number push in the coinbase scriptSig, which would point to a 32-byte hash H. This push was accepted as it provided a more flexible and compact system than the current one. Concerns were raised about adding arbitrary data, so it was suggested that the data in the coinbase witness stack have a fixed number of entries depending on the block version number. This would allow for soft-forks to add new entries in the stack.Peter Todd discussed upgrade procedures related to segregated witnesses, suggesting the addition of a new service bit or bumping the protocol version. However, this solution did not address the issue of relaying more block data in the future, requiring another soft-fork upgrade. To solve this problem, Todd proposed making the witness data more extensible by using unvalidated block extension data. This involved a backward-incompatible change to the current segwit change, where the coinbase scriptSig would receive a second number push pointing to a 32-byte hash H. Todd also addressed concerns about miners using arbitrary data by suggesting a merkelized key:value mapping with collision-resistant IDs as keys.Pieter Wuille's segwit branch was discussed on the Bitcoin developers mailing list. It was suggested to add a new service bit or bump up the protocol version to only connect to peers with segwit support. The branch had a fHaveWitness flag for each connection, but BIP144 proposed changing this to a service bit. A pull request to change this to a NODE_WITNESS service bit has been made on GitHub.Peter Todd suggested adding a new service bit, NODE_SEGWIT, and/or bumping the protocol version to ensure outgoing peers only connect to peers with segwit support. He also proposed solutions for future upgrades adding new block data, such as removing the restriction on the coinbase witness containing exactly one 32-byte value. Another proposal involved hashing the contents of the coinbase witness as a merkle tree and committing them in place of the current nonce commitment. These proposals were discussed in a pull request on the segwit branch, including the idea of including the merkle path to the segwit data in the coinbase witness.The deployment of segregated witness poses a problem as nodes need witness data to function after activation. If full node adoption lags behind miner adoption, the segwit-supporting P2P network may partition and lose consensus. The issue is not yet fixed in Pieter Wuille's segwit branch, but one solution is to add a new service bit or bump the protocol version to only connect to peers with segwit support. However, if full node operators do not widely adopt segwit, the network could become more vulnerable. Future upgrades will require the relay network to upgrade, and BIP141 suggests an Extensible Commitment Structure to address this. This structure consists of a hashed linked list of consensus-critical commitments, with a redefinable nonce for future soft-forks. To allow for additional data in future soft-forks, the proposal is to remove the restriction on the coinbase witness, hash its contents as a merkle tree, and include that data in the blocksize limit. This allows all nodes to validate the data came from the miner and propagate it without risk of attack. This method is efficient as most future upgrades are expected to be additional commitments, and the additional data for each commitment is just 32 bytes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml b/static/bitcoin-dev/Jan_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml index 9f3e6a8613..1dd7aba418 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Three Month bitcoin-dev Moderation Review - 2023-08-01T17:36:07.470670+00:00 + 2025-09-26T15:28:34.955905+00:00 + python-feedgen David Vorick 2016-02-09 23:24:28+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Three Month bitcoin-dev Moderation Review - 2023-08-01T17:36:07.471670+00:00 + 2025-09-26T15:28:34.956074+00:00 - The Bitcoin-dev mailing list recently discussed the importance of providing unique and valuable contributions to conversations. Contributors emphasized that comments should contribute to the discussion with technical details or additional relevant data, rather than simply stating agreement with a proposal. The sentiment expressed was that evidence trumps votes, and comments should provide readers with another thing to consider in favor of something beyond just the number of people who support it.In this context, various members of the mailing list shared their opinions. Dave Scotese suggested that contributors should provide additional evidence in favor of something, while Gavin offered his services as a techie and shared information about his projects Litmocracy and Meme Racing. Peter Todd and another member stressed that comments should contribute uniquely to the discussion and not simply repeat what has already been said. They proposed using a "+1" vote with an explanation that provides unique insights to the conversation.Another member, Xor, suggested allowing "+1" votes as long as a technical explanation is provided for why the person agrees. However, Peter Todd disagreed, stating that the explanation should also contribute uniquely to the conversation. Rusty Russell expressed his view that "+1s" on a list are not useful unless they carry additional information. He recommended amending the rules to clarify that "+1s" are not allowed without an explanation.In addition to discussing comments, the mailing list also addressed other issues. Dave Scotese expressed disappointment at the difficulty in accessing moderated messages and suggested having a downloadable version of these messages on the ozlabs website. Rusty Russell explained that the difficulty arises because the messages are forwarded to the bitcoin-dev-moderation mailing list, which strips them out as attachments. Rusty called for volunteers to help develop a filter to address this issue.Furthermore, Rusty Russell raised the question of what moderation should look like going forward. Xor pointed out that the original announcement of moderation had discouraged the use of "+1s" without additional information. Rusty clarified that statements like "I prefer proposal X over Y because..." or "I dislike X because..." carry more weight than simply saying "+1." The discussion highlighted the need for moderation to be information-rich and not solely focused on managing a process of indicating agreement or disagreement.Overall, the Bitcoin-dev mailing list engaged in a thoughtful discussion about the value of comments, the importance of providing unique contributions, and potential improvements to the moderation system. 2016-02-09T23:24:28+00:00 + The Bitcoin-dev mailing list recently discussed the importance of providing unique and valuable contributions to conversations. Contributors emphasized that comments should contribute to the discussion with technical details or additional relevant data, rather than simply stating agreement with a proposal. The sentiment expressed was that evidence trumps votes, and comments should provide readers with another thing to consider in favor of something beyond just the number of people who support it.In this context, various members of the mailing list shared their opinions. Dave Scotese suggested that contributors should provide additional evidence in favor of something, while Gavin offered his services as a techie and shared information about his projects Litmocracy and Meme Racing. Peter Todd and another member stressed that comments should contribute uniquely to the discussion and not simply repeat what has already been said. They proposed using a "+1" vote with an explanation that provides unique insights to the conversation.Another member, Xor, suggested allowing "+1" votes as long as a technical explanation is provided for why the person agrees. However, Peter Todd disagreed, stating that the explanation should also contribute uniquely to the conversation. Rusty Russell expressed his view that "+1s" on a list are not useful unless they carry additional information. He recommended amending the rules to clarify that "+1s" are not allowed without an explanation.In addition to discussing comments, the mailing list also addressed other issues. Dave Scotese expressed disappointment at the difficulty in accessing moderated messages and suggested having a downloadable version of these messages on the ozlabs website. Rusty Russell explained that the difficulty arises because the messages are forwarded to the bitcoin-dev-moderation mailing list, which strips them out as attachments. Rusty called for volunteers to help develop a filter to address this issue.Furthermore, Rusty Russell raised the question of what moderation should look like going forward. Xor pointed out that the original announcement of moderation had discouraged the use of "+1s" without additional information. Rusty clarified that statements like "I prefer proposal X over Y because..." or "I dislike X because..." carry more weight than simply saying "+1." The discussion highlighted the need for moderation to be information-rich and not solely focused on managing a process of indicating agreement or disagreement.Overall, the Bitcoin-dev mailing list engaged in a thoughtful discussion about the value of comments, the importance of providing unique contributions, and potential improvements to the moderation system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_Time-to-worry-about-80-bit-collision-attacks-or-not-.xml b/static/bitcoin-dev/Jan_2016/combined_Time-to-worry-about-80-bit-collision-attacks-or-not-.xml index 31e3a0df6a..c850892fa2 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Time-to-worry-about-80-bit-collision-attacks-or-not-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Time-to-worry-about-80-bit-collision-attacks-or-not-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Time to worry about 80-bit collision attacks or not? - 2023-08-01T17:33:58.387963+00:00 + 2025-09-26T15:28:58.212997+00:00 + python-feedgen Zooko Wilcox-O'Hearn 2016-01-12 23:22:17+00:00 @@ -115,13 +116,13 @@ - python-feedgen + 2 Combined summary - Time to worry about 80-bit collision attacks or not? - 2023-08-01T17:33:58.388963+00:00 + 2025-09-26T15:28:58.213185+00:00 - Zooko, a contributor to the Bitcoin development mailing list, suggests that the thread is omitting consideration of multi-target attacks. He explains that if an attacker is happy to find a collision with any one out of a large number of potential victims, they get an advantage proportional to the number of potential victims. Therefore, it would be wise to estimate how many public keys will eventually be in use. Zooko recommends a recent blog post by DJB for more information about the "Attacker Economist" approach.It is advised to worry about 80-bit collision attacks as they are likely to cost less than $1 million in the next ten to twenty years. If one agrees to lock up funds with someone else and they control the public key, they become susceptible to these attacks. It is suggested to avoid pay-to-script-hash addresses and instead use payment protocol and "raw" multisig outputs when dealing with significant amounts of money. Alternatively, one can ask for a hierarchical deterministic (BIP32) seed and derive a public key for them to use. To ensure maximum security, one should follow security in depth and validate all input secure coding principles.In an email conversation on January 11, 2016 at 11:57 PM, Tier Nolan corrected an error in a code block on the Bitcoin development mailing list. The original script had a syntax error in the order of the parameters for CHECKSIG and OP_DROP, and Tier Nolan swapped the positions of const_pub_key and prev_hash in the script to correct it.In a discussion on the bitcoin-dev mailing list, Gavin Andresen asked about how long it would take for a 2^84 attack where the work is an ECDSA private to public key derivation. However, another participant in the discussion suggested that the EC multiply may not actually be necessary and proposed using compressed public keys and a sha256 call instead. Gavin Andresen defended the choice of SHA256D over RipeMD160 for an update to the digital currency's software in a Bitcoin developer email thread. He argued that the tradeoff between crypto strength and code complexity is important and that "the strength of the crypto is all that matters" was not security-first. Another developer disagreed and stated that code complexity shouldn't be a concern, but rather the security versus space tradeoff.Peter Todd shared his experience of raising an issue with segregated witnesses on the BIP process in response to a comment by Gavin Andresen. Todd expressed concerns that it could make validationless mining easier and more profitable. The issue was discussed on IRC, and Todd plans to write the code to implement a fix and submit it as a pull-req against the segwit branch.Gavin Andresen proposed eliminating the risk of a potential attack by having only one witness program version in a Bitcoin-dev email thread in 2016. Pieter Wuille disagreed with this suggestion and argued for maintaining Bitcoin's 128-bit security target for witness scripts. The proposal remains under discussion.In an email exchange on January 8, 2016, Gavin Andresen asked if there was a similar attack scheme possible if the network had switched to Schnorr 2-of-2 signatures. However, he quickly corrected himself and acknowledged that the scheme would still work with Schnorr.Gavin Andresen discussed the tradeoff between crypto strength and code complexity in relation to segwitness in an email thread dated January 8, 2016. He highlighted two ways of stuffing the segwitness hash into the scriptPubKey but suggested keeping the design as simple as possible. He admitted that using a 32-byte hash could compromise short-term scalability but believed it was a no-brainer.In a forum thread, Gavin Andresen responded to concerns about the security of Bitcoin's code complexity. He acknowledged the importance of a "security first" mindset but pointed out the tradeoff between crypto strength and code complexity. The message suggests ongoing discussions around the topic of Bitcoin security.Gavin Andresen asked about the timeline for a 2^84 attack on ECDSA private to public key derivation in a message. He also asked about a similar attack scheme assuming the switch to Schnorr 2-of-2 signatures.In an email exchange on the bitcoin-dev mailing list, Gavin Andresen and Pieter Wuille discuss the use of cryptography in Bitcoin. Pieter argues for using better cryptography that is up to par with security standards, while Gavin emphasizes the importance of simplicity and points out the potential vulnerabilities in the scripting language. They also discuss the security of SHA256(SHA256) over RIPEMD160(SHA256) and the implementation of segwit. The discussion revolves around collision attacks and the need for collision security to protect against such attacks. There are concerns about the vulnerability of nested hash construction RIPEMD160(SHA256()) and length extension attacks. Ethan Heilman provides an algorithm that can find targeted substrings and raises concerns about cascading the same hash function twice. The participants also discuss the security 2016-01-12T23:22:17+00:00 + Zooko, a contributor to the Bitcoin development mailing list, suggests that the thread is omitting consideration of multi-target attacks. He explains that if an attacker is happy to find a collision with any one out of a large number of potential victims, they get an advantage proportional to the number of potential victims. Therefore, it would be wise to estimate how many public keys will eventually be in use. Zooko recommends a recent blog post by DJB for more information about the "Attacker Economist" approach.It is advised to worry about 80-bit collision attacks as they are likely to cost less than $1 million in the next ten to twenty years. If one agrees to lock up funds with someone else and they control the public key, they become susceptible to these attacks. It is suggested to avoid pay-to-script-hash addresses and instead use payment protocol and "raw" multisig outputs when dealing with significant amounts of money. Alternatively, one can ask for a hierarchical deterministic (BIP32) seed and derive a public key for them to use. To ensure maximum security, one should follow security in depth and validate all input secure coding principles.In an email conversation on January 11, 2016 at 11:57 PM, Tier Nolan corrected an error in a code block on the Bitcoin development mailing list. The original script had a syntax error in the order of the parameters for CHECKSIG and OP_DROP, and Tier Nolan swapped the positions of const_pub_key and prev_hash in the script to correct it.In a discussion on the bitcoin-dev mailing list, Gavin Andresen asked about how long it would take for a 2^84 attack where the work is an ECDSA private to public key derivation. However, another participant in the discussion suggested that the EC multiply may not actually be necessary and proposed using compressed public keys and a sha256 call instead. Gavin Andresen defended the choice of SHA256D over RipeMD160 for an update to the digital currency's software in a Bitcoin developer email thread. He argued that the tradeoff between crypto strength and code complexity is important and that "the strength of the crypto is all that matters" was not security-first. Another developer disagreed and stated that code complexity shouldn't be a concern, but rather the security versus space tradeoff.Peter Todd shared his experience of raising an issue with segregated witnesses on the BIP process in response to a comment by Gavin Andresen. Todd expressed concerns that it could make validationless mining easier and more profitable. The issue was discussed on IRC, and Todd plans to write the code to implement a fix and submit it as a pull-req against the segwit branch.Gavin Andresen proposed eliminating the risk of a potential attack by having only one witness program version in a Bitcoin-dev email thread in 2016. Pieter Wuille disagreed with this suggestion and argued for maintaining Bitcoin's 128-bit security target for witness scripts. The proposal remains under discussion.In an email exchange on January 8, 2016, Gavin Andresen asked if there was a similar attack scheme possible if the network had switched to Schnorr 2-of-2 signatures. However, he quickly corrected himself and acknowledged that the scheme would still work with Schnorr.Gavin Andresen discussed the tradeoff between crypto strength and code complexity in relation to segwitness in an email thread dated January 8, 2016. He highlighted two ways of stuffing the segwitness hash into the scriptPubKey but suggested keeping the design as simple as possible. He admitted that using a 32-byte hash could compromise short-term scalability but believed it was a no-brainer.In a forum thread, Gavin Andresen responded to concerns about the security of Bitcoin's code complexity. He acknowledged the importance of a "security first" mindset but pointed out the tradeoff between crypto strength and code complexity. The message suggests ongoing discussions around the topic of Bitcoin security.Gavin Andresen asked about the timeline for a 2^84 attack on ECDSA private to public key derivation in a message. He also asked about a similar attack scheme assuming the switch to Schnorr 2-of-2 signatures.In an email exchange on the bitcoin-dev mailing list, Gavin Andresen and Pieter Wuille discuss the use of cryptography in Bitcoin. Pieter argues for using better cryptography that is up to par with security standards, while Gavin emphasizes the importance of simplicity and points out the potential vulnerabilities in the scripting language. They also discuss the security of SHA256(SHA256) over RIPEMD160(SHA256) and the implementation of segwit. The discussion revolves around collision attacks and the need for collision security to protect against such attacks. There are concerns about the vulnerability of nested hash construction RIPEMD160(SHA256()) and length extension attacks. Ethan Heilman provides an algorithm that can find targeted substrings and raises concerns about cascading the same hash function twice. The participants also discuss the security - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_What-is-OpenSSL-still-used-for-.xml b/static/bitcoin-dev/Jan_2016/combined_What-is-OpenSSL-still-used-for-.xml index 0255e63fca..c49a8576ce 100644 --- a/static/bitcoin-dev/Jan_2016/combined_What-is-OpenSSL-still-used-for-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_What-is-OpenSSL-still-used-for-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - What is OpenSSL still used for? - 2023-08-01T17:35:36.978170+00:00 + 2025-09-26T15:28:49.757801+00:00 + python-feedgen Wladimir J. van der Laan 2016-01-25 11:58:29+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - What is OpenSSL still used for? - 2023-08-01T17:35:36.978170+00:00 + 2025-09-26T15:28:49.757968+00:00 - In version 0.12 of Bitcoin, the dependency on OpenSSL for signature validation has been replaced with libsecp256k1. However, OpenSSL is still being used for various other purposes such as random number generation and AES256 encryption of private keys. There are outdated pull requests to remove the OpenSSL dependency for these purposes. It is suggested that OpenSSL be kept as a dependency for SSL/X.509 in the BIP70 payment protocol. The plan is to make OpenSSL a dependency only if the GUI is enabled in the future, with most of the work already done but requiring careful testing and integration.In response to a question from Andrew about why OpenSSL is still being used, the author explains that while OpenSSL has been dropped for ECC signature validation, it is still being used for other crypto functions. Specifically, it is used for getting random numbers to randomize the ECC signing context, AES256 encryption of private keys for wallets, and SSL/X.509 for the BIP70 payment protocol for the GUI. The author suggests that the OpenSSL dependency could be removed for the first two purposes but makes sense to keep it for the BIP70 payment protocol. The author provides links to relevant pull requests related to entropy and AES. The message ends with a PGP signature.In another post on the Bitcoin-dev mailing list, Ethan Heilman asks whether libsecp256k1 is used for all cryptographic functions in Bitcoin. Douglas Roark replies that while libsecp256k1 performs the required elliptic curve operations, OpenSSL is still used for other crypto functions. Roark mentions that libsecp256k1 currently relies on an implementation of RFC 6979 instead of a PRNG, possibly for portability reasons. However, there are still some crypto functions not covered by libsecp256k1 at the API level, and for consensus-critical functionality, OpenSSL will be replaced with libsecp256k1 in the upcoming version 0.12 of Bitcoin.A discussion on the use of libsecp256k1 and OpenSSL in Bitcoin is taking place on the bitcoin-dev mailing list. It is noted that libsecp256k1 is only used for elliptic curve operations required by Bitcoin, while OpenSSL is used for all other cryptography. The use of OpenSSL's PRNG can be seen in the random.h file in the Bitcoin source code. The question arises regarding what other purposes OpenSSL serves if signature validation has been moved to libsecp256k1 in the 0.12 release notes. However, it is not clear from the given context whether a response was provided or not. 2016-01-25T11:58:29+00:00 + In version 0.12 of Bitcoin, the dependency on OpenSSL for signature validation has been replaced with libsecp256k1. However, OpenSSL is still being used for various other purposes such as random number generation and AES256 encryption of private keys. There are outdated pull requests to remove the OpenSSL dependency for these purposes. It is suggested that OpenSSL be kept as a dependency for SSL/X.509 in the BIP70 payment protocol. The plan is to make OpenSSL a dependency only if the GUI is enabled in the future, with most of the work already done but requiring careful testing and integration.In response to a question from Andrew about why OpenSSL is still being used, the author explains that while OpenSSL has been dropped for ECC signature validation, it is still being used for other crypto functions. Specifically, it is used for getting random numbers to randomize the ECC signing context, AES256 encryption of private keys for wallets, and SSL/X.509 for the BIP70 payment protocol for the GUI. The author suggests that the OpenSSL dependency could be removed for the first two purposes but makes sense to keep it for the BIP70 payment protocol. The author provides links to relevant pull requests related to entropy and AES. The message ends with a PGP signature.In another post on the Bitcoin-dev mailing list, Ethan Heilman asks whether libsecp256k1 is used for all cryptographic functions in Bitcoin. Douglas Roark replies that while libsecp256k1 performs the required elliptic curve operations, OpenSSL is still used for other crypto functions. Roark mentions that libsecp256k1 currently relies on an implementation of RFC 6979 instead of a PRNG, possibly for portability reasons. However, there are still some crypto functions not covered by libsecp256k1 at the API level, and for consensus-critical functionality, OpenSSL will be replaced with libsecp256k1 in the upcoming version 0.12 of Bitcoin.A discussion on the use of libsecp256k1 and OpenSSL in Bitcoin is taking place on the bitcoin-dev mailing list. It is noted that libsecp256k1 is only used for elliptic curve operations required by Bitcoin, while OpenSSL is used for all other cryptography. The use of OpenSSL's PRNG can be seen in the random.h file in the Bitcoin source code. The question arises regarding what other purposes OpenSSL serves if signature validation has been moved to libsecp256k1 in the 0.12 release notes. However, it is not clear from the given context whether a response was provided or not. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_nSequence-multiple-uses.xml b/static/bitcoin-dev/Jan_2016/combined_nSequence-multiple-uses.xml index d7bbff9f09..99b69bb573 100644 --- a/static/bitcoin-dev/Jan_2016/combined_nSequence-multiple-uses.xml +++ b/static/bitcoin-dev/Jan_2016/combined_nSequence-multiple-uses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - nSequence multiple uses - 2023-08-01T17:36:54.872168+00:00 + 2025-09-26T15:28:53.987925+00:00 + python-feedgen Andrew C 2016-01-23 04:41:55+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - nSequence multiple uses - 2023-08-01T17:36:54.872168+00:00 + 2025-09-26T15:28:53.988082+00:00 - During a Bitcoin-development discussion, Andrew C brought up the topic of using nSequence in Bitcoin transactions for both locktime and opt-in Replace-by-Fee (RBF) signaling. However, he realized that there is currently no way to differentiate between these two uses. In response, Dave explained that while setting nSequence to less than MAX_INT enables locktime enforcement, opting into RBF requires setting it to less than MAX-1. To provide further information, Dave shared a link to Bitcoin Improvement Proposal 125 (BIP125).Andrew then sought clarification on whether there were any plans to change nSequence to allow for distinguishing between the different features of a transaction. He suggested utilizing version bits as a potential solution. 2016-01-23T04:41:55+00:00 + During a Bitcoin-development discussion, Andrew C brought up the topic of using nSequence in Bitcoin transactions for both locktime and opt-in Replace-by-Fee (RBF) signaling. However, he realized that there is currently no way to differentiate between these two uses. In response, Dave explained that while setting nSequence to less than MAX_INT enables locktime enforcement, opting into RBF requires setting it to less than MAX-1. To provide further information, Dave shared a link to Bitcoin Improvement Proposal 125 (BIP125).Andrew then sought clarification on whether there were any plans to change nSequence to allow for distinguishing between the different features of a transaction. He suggested utilizing version bits as a potential solution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_A-BIP-for-partially-signed-not-signed-raw-transaction-serialization-would-it-be-useful-.xml b/static/bitcoin-dev/Jan_2017/combined_A-BIP-for-partially-signed-not-signed-raw-transaction-serialization-would-it-be-useful-.xml index 6e2612f4a7..e2ce1f1bc1 100644 --- a/static/bitcoin-dev/Jan_2017/combined_A-BIP-for-partially-signed-not-signed-raw-transaction-serialization-would-it-be-useful-.xml +++ b/static/bitcoin-dev/Jan_2017/combined_A-BIP-for-partially-signed-not-signed-raw-transaction-serialization-would-it-be-useful-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A BIP for partially-signed/not-signed raw transaction serialization; would it be useful? - 2023-08-01T19:24:32.481303+00:00 + 2025-09-26T16:04:24.262957+00:00 + python-feedgen 木ノ下じょな 2017-01-10 12:35:07+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - A BIP for partially-signed/not-signed raw transaction serialization; would it be useful? - 2023-08-01T19:24:32.481303+00:00 + 2025-09-26T16:04:24.263084+00:00 - In January 2017, Jon proposed gathering opinions before submitting a Bitcoin Improvement Proposal (BIP) to address the issue of different methodologies used for serializing partially signed multisig raw transactions. This problem was observed in projects like Electrum, Copay, Coinb.in, and Bitcoin Core. Thomas Kerin recommended that Jon should consider his previous work on a similar BIP for hardware signing and suggested using a protocol for requesting signatures, particularly suitable for BitGo and GreenAddress wallets.The context provided is a PGP public key block, which contains a long string of characters representing the actual public key and metadata about the key. This metadata includes the associated email address, creation date, and algorithm used to generate the key. PGP, or Pretty Good Privacy, is an encryption tool used for secure messaging over the internet. It requires users to generate a key pair consisting of a public and private key. The public key can be shared, while the private key must be kept secret. Messages can be encrypted using the recipient's public key, ensuring only the intended recipient can decrypt and read them.The need for a standardized specification for unsigned transactions arises from the different serialization methodologies used in partially signed multisig raw transactions and not-signed raw transactions across various projects. Jon, known as 木ノ下じょな on bitcoin-dev, has encountered similar issues with multisig support. To eliminate friction caused by these differences, a standardized specification is proposed to ensure consistent serialization of unsigned transactions. The signature section of the transaction should contain all necessary information for making the signature. The proposal aims to have all unsigned transactions follow the same form and be encoded in a way that signing applications can recognize them as unsigned.Prior to proposing a BIP, Jon sought opinions to assess the need for a standardized specification. 2017-01-10T12:35:07+00:00 + In January 2017, Jon proposed gathering opinions before submitting a Bitcoin Improvement Proposal (BIP) to address the issue of different methodologies used for serializing partially signed multisig raw transactions. This problem was observed in projects like Electrum, Copay, Coinb.in, and Bitcoin Core. Thomas Kerin recommended that Jon should consider his previous work on a similar BIP for hardware signing and suggested using a protocol for requesting signatures, particularly suitable for BitGo and GreenAddress wallets.The context provided is a PGP public key block, which contains a long string of characters representing the actual public key and metadata about the key. This metadata includes the associated email address, creation date, and algorithm used to generate the key. PGP, or Pretty Good Privacy, is an encryption tool used for secure messaging over the internet. It requires users to generate a key pair consisting of a public and private key. The public key can be shared, while the private key must be kept secret. Messages can be encrypted using the recipient's public key, ensuring only the intended recipient can decrypt and read them.The need for a standardized specification for unsigned transactions arises from the different serialization methodologies used in partially signed multisig raw transactions and not-signed raw transactions across various projects. Jon, known as 木ノ下じょな on bitcoin-dev, has encountered similar issues with multisig support. To eliminate friction caused by these differences, a standardized specification is proposed to ensure consistent serialization of unsigned transactions. The signature section of the transaction should contain all necessary information for making the signature. The proposal aims to have all unsigned transactions follow the same form and be encoded in a way that signing applications can recognize them as unsigned.Prior to proposing a BIP, Jon sought opinions to assess the need for a standardized specification. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Anti-transaction-replay-in-a-hardfork.xml b/static/bitcoin-dev/Jan_2017/combined_Anti-transaction-replay-in-a-hardfork.xml index b4643860c8..d5e0603b34 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Anti-transaction-replay-in-a-hardfork.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Anti-transaction-replay-in-a-hardfork.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Anti-transaction replay in a hardfork - 2023-08-01T19:26:39.921705+00:00 + 2025-09-26T16:04:43.264909+00:00 + python-feedgen Tom Harding 2017-01-27 22:11:02+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Anti-transaction replay in a hardfork - 2023-08-01T19:26:39.921705+00:00 + 2025-09-26T16:04:43.265094+00:00 - The proposal discussed in the given context aims to address the issue of replay attacks during a blockchain split. A replay attack occurs when a transaction is replayed on another network, potentially causing unintended consequences. To prevent this, the proposal suggests implementing anti-replay protection as an optional feature for users on both the existing and new forks.Transactions created before the proposal was made are not protected from anti-replay, as there is no guarantee that the existing fork will survive or retain any value. However, the new fork must accept these transactions. The proposal does not require any consensus changes in the existing network to avoid unnecessary debates.In addition to preventing replay attacks, the proposal also offers a beneficial side effect of fixing a signature checking bug for non-segregated witness inputs. The rules outlined in the proposal ensure that transactions with only the existing network characteristic bit set are invalid in the new network. Time-locked transactions made before the proposal are considered valid in the new network. Conversely, transactions specifically created for the new network are invalid in the existing network.To avoid a replay of such transactions, users should first spend at least one relevant UTXO on the new network, which would invalidate the replay transaction. It is ultimately up to the designer of a hardfork to decide whether or not to implement this proposal.The size of the network characteristic byte is limited to 8 bits, but if certain networks are completely abandoned, the bits may be reused. A demo of the proposal can be found in the forcenet2 branch on GitHub. The proposal should be taken into account when creating hardfork proposals, except for trivial and uncontroversial ones.In an email exchange, Johnson Lau pointed out the difference between an opt-out system and an opt-in system. He argues that an opt-in system would require unmodified yet compatible systems to change in order to support the new network, which is self-defeating. Lau suggests that an opt-out system would make more sense for everyone involved.In another email exchange, the question of whether Alice is protected in a hardfork scenario is discussed. Lau proposes a scenario where Alice pays Bob with an old-style time-locked transaction, and after the hardfork, Bob can confirm the transaction on both networks. However, if Alice has full control, she is already protected by a proposal that does not require any protecting child transactions. If the time-locked transaction is unprotected in a 2-of-2 multisig where Bob receives the payment, Bob will receive all the money from both forks without renegotiation with Alice.In a different email discussion, Lau questions a proposal regarding the replay protection of Bitcoin transactions after a hardfork. He argues that Alice would not hold onto an old-style time-locked transaction if she doesn't control any of the UTXOs and cannot substitute the transaction for one where she does have control. Lau suggests that Bob could still confirm the time-locked transaction on both networks after the hardfork by sending the outputs to himself again with a different transaction format, making it a successful replay.In a separate conversation between Tom Harding and Johnson Lau, they discuss proposals to prevent transaction replay attacks in the event of a chain split. Lau's proposal is an opt-in approach, while Harding suggests a soft fork that supports its own hard-fork opt-out bit. They also discuss the specific changes suggested by Lau's BIP and the need for consensus changes in the existing network. They agree that their proposals are similar but differ in their approach.Overall, the proposal aims to resolve the issue of replay attacks during a blockchain split by implementing optional anti-replay protection and introducing rules for both the existing and new networks. It is important to consider this proposal when creating hardfork proposals to ensure the safety and integrity of transactions. 2017-01-27T22:11:02+00:00 + The proposal discussed in the given context aims to address the issue of replay attacks during a blockchain split. A replay attack occurs when a transaction is replayed on another network, potentially causing unintended consequences. To prevent this, the proposal suggests implementing anti-replay protection as an optional feature for users on both the existing and new forks.Transactions created before the proposal was made are not protected from anti-replay, as there is no guarantee that the existing fork will survive or retain any value. However, the new fork must accept these transactions. The proposal does not require any consensus changes in the existing network to avoid unnecessary debates.In addition to preventing replay attacks, the proposal also offers a beneficial side effect of fixing a signature checking bug for non-segregated witness inputs. The rules outlined in the proposal ensure that transactions with only the existing network characteristic bit set are invalid in the new network. Time-locked transactions made before the proposal are considered valid in the new network. Conversely, transactions specifically created for the new network are invalid in the existing network.To avoid a replay of such transactions, users should first spend at least one relevant UTXO on the new network, which would invalidate the replay transaction. It is ultimately up to the designer of a hardfork to decide whether or not to implement this proposal.The size of the network characteristic byte is limited to 8 bits, but if certain networks are completely abandoned, the bits may be reused. A demo of the proposal can be found in the forcenet2 branch on GitHub. The proposal should be taken into account when creating hardfork proposals, except for trivial and uncontroversial ones.In an email exchange, Johnson Lau pointed out the difference between an opt-out system and an opt-in system. He argues that an opt-in system would require unmodified yet compatible systems to change in order to support the new network, which is self-defeating. Lau suggests that an opt-out system would make more sense for everyone involved.In another email exchange, the question of whether Alice is protected in a hardfork scenario is discussed. Lau proposes a scenario where Alice pays Bob with an old-style time-locked transaction, and after the hardfork, Bob can confirm the transaction on both networks. However, if Alice has full control, she is already protected by a proposal that does not require any protecting child transactions. If the time-locked transaction is unprotected in a 2-of-2 multisig where Bob receives the payment, Bob will receive all the money from both forks without renegotiation with Alice.In a different email discussion, Lau questions a proposal regarding the replay protection of Bitcoin transactions after a hardfork. He argues that Alice would not hold onto an old-style time-locked transaction if she doesn't control any of the UTXOs and cannot substitute the transaction for one where she does have control. Lau suggests that Bob could still confirm the time-locked transaction on both networks after the hardfork by sending the outputs to himself again with a different transaction format, making it a successful replay.In a separate conversation between Tom Harding and Johnson Lau, they discuss proposals to prevent transaction replay attacks in the event of a chain split. Lau's proposal is an opt-in approach, while Harding suggests a soft fork that supports its own hard-fork opt-out bit. They also discuss the specific changes suggested by Lau's BIP and the need for consensus changes in the existing network. They agree that their proposals are similar but differ in their approach.Overall, the proposal aims to resolve the issue of replay attacks during a blockchain split by implementing optional anti-replay protection and introducing rules for both the existing and new networks. It is important to consider this proposal when creating hardfork proposals to ensure the safety and integrity of transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-Historical-and-future-projections-t-khan-.xml b/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-Historical-and-future-projections-t-khan-.xml index 0d25ed5146..4c8a42edb6 100644 --- a/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-Historical-and-future-projections-t-khan-.xml +++ b/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-Historical-and-future-projections-t-khan-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP - Block75 - Historical and future projections (t. khan) - 2023-08-01T19:24:49.071312+00:00 + 2025-09-26T16:04:26.372883+00:00 + python-feedgen t. khan 2017-01-10 19:09:42+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP - Block75 - Historical and future projections (t. khan) - 2023-08-01T19:24:49.071312+00:00 + 2025-09-26T16:04:26.373012+00:00 - Recently, there has been a discussion on the bitcoin-discuss mailing list regarding the concept of an adaptive or automatic block size. Ryan J Martin expressed concerns about this approach, stating that it may not consider the optimal economic equilibrium for transaction fees and size. He highlighted the potential negative impact on miners and users if an auto-adjusting size limit is implemented without solid code and a social benefit model in place.In response to this discussion, t.k. proposed a BIP called Block75, which aims to maintain blocks at 75% full. They used the daily average block size over the past year to estimate how Block75 would have altered the maximum block sizes. According to their estimates, if Block75 were activated today, the max block size one year from now would be 2,064KB. However, they acknowledged that this is only an estimate and welcomed alternative ways to model future behavior through the Block75 algorithm.Concerns have been raised that an auto-adjusting size limit could create unforeseen externalities for miners and users. Miners might decide to mine very small blocks to constrict supply and increase marginal fees, while users could push blocks to larger sizes, resulting in higher latency and network issues. To address these concerns, an auto-adjusting limit would require solid code with a social benefit model built-in. This model would aim to adjust to an equilibrium that maximizes benefits and minimizes costs for both miners and users, using a Marshallian surplus model.Meanwhile, the Block75 proposal suggests adjusting the maximum block size based on the average percentage fullness of the last 2016 blocks. This approach aims to keep blocks as small as possible, allow for growth, and maintain transaction fees at a level similar to May/June 2016. The proposal takes into account the substantial increase in transactions expected in the last quarter of 2017 and the changes brought about by SegWit. However, it is important to note that the max block size projections provided by Block75 are estimates, and alternative ways to model future behavior are encouraged to be tested through the Block75 algorithm. 2017-01-10T19:09:42+00:00 + Recently, there has been a discussion on the bitcoin-discuss mailing list regarding the concept of an adaptive or automatic block size. Ryan J Martin expressed concerns about this approach, stating that it may not consider the optimal economic equilibrium for transaction fees and size. He highlighted the potential negative impact on miners and users if an auto-adjusting size limit is implemented without solid code and a social benefit model in place.In response to this discussion, t.k. proposed a BIP called Block75, which aims to maintain blocks at 75% full. They used the daily average block size over the past year to estimate how Block75 would have altered the maximum block sizes. According to their estimates, if Block75 were activated today, the max block size one year from now would be 2,064KB. However, they acknowledged that this is only an estimate and welcomed alternative ways to model future behavior through the Block75 algorithm.Concerns have been raised that an auto-adjusting size limit could create unforeseen externalities for miners and users. Miners might decide to mine very small blocks to constrict supply and increase marginal fees, while users could push blocks to larger sizes, resulting in higher latency and network issues. To address these concerns, an auto-adjusting limit would require solid code with a social benefit model built-in. This model would aim to adjust to an equilibrium that maximizes benefits and minimizes costs for both miners and users, using a Marshallian surplus model.Meanwhile, the Block75 proposal suggests adjusting the maximum block size based on the average percentage fullness of the last 2016 blocks. This approach aims to keep blocks as small as possible, allow for growth, and maintain transaction fees at a level similar to May/June 2016. The proposal takes into account the substantial increase in transactions expected in the last quarter of 2017 and the changes brought about by SegWit. However, it is important to note that the max block size projections provided by Block75 are estimates, and alternative ways to model future behavior are encouraged to be tested through the Block75 algorithm. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-New-algorithm.xml b/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-New-algorithm.xml index b3bf10a403..14c572573f 100644 --- a/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-New-algorithm.xml +++ b/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-New-algorithm.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - BIP - 'Block75' - New algorithm - 2023-08-01T19:22:01.373245+00:00 - - Hampus Sjöberg 2017-02-13 11:21:44+00:00 - - - t. khan 2017-01-03 14:28:27+00:00 - - - Tom Zander 2017-01-02 22:33:16+00:00 - - - Tom Zander 2017-01-02 22:01:08+00:00 - - - Luke Dashjr 2017-01-02 21:19:10+00:00 - - - t. khan 2017-01-02 21:05:58+00:00 - - - t. khan 2017-01-02 20:41:42+00:00 - - - Tom Zander 2017-01-02 20:35:40+00:00 - - - Luke Dashjr 2017-01-02 20:04:56+00:00 - - - t. khan 2017-01-02 19:32:24+00:00 - - - Tom Zander 2017-01-02 19:01:11+00:00 - - - t. khan 2017-01-02 18:04:37+00:00 - + 2025-09-26T16:04:34.800782+00:00 + python-feedgen + + + [bitcoin-dev] BIP - 'Block75' - New algorithm t. khan + 2017-01-02T18:04:00.000Z + + + Tom Zander + 2017-01-02T19:01:00.000Z + + + t. khan + 2017-01-02T19:32:00.000Z + + + Luke Dashjr + 2017-01-02T20:04:00.000Z + + + Tom Zander + 2017-01-02T20:35:00.000Z + + + t. khan + 2017-01-02T20:41:00.000Z + + + t. khan + 2017-01-02T21:05:00.000Z + + + Luke Dashjr + 2017-01-02T21:19:00.000Z + + + Tom Zander + 2017-01-02T22:01:00.000Z + + + Tom Zander + 2017-01-02T22:33:00.000Z + + + t. khan + 2017-01-03T14:28:00.000Z + + + Hampus Sjöberg + 2017-02-13T11:21:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - BIP - 'Block75' - New algorithm - 2023-08-01T19:22:01.373245+00:00 + 2025-09-26T16:04:34.802164+00:00 - The discussion revolves around the control of miners over the block size limit in Bitcoin. The proposal of Block75 algorithm is analyzed, which aims to manage the maximum block size without human intervention. However, concerns are raised about the potential centralization and loss of transaction fees that may arise from increasing the block size. The debate also delves into the definition of "miner spam" and the need for evidence to support this claim. The importance of miners in determining the block size limit is emphasized, as they have a financial incentive to produce bigger blocks but also face the risk of orphaned blocks. A discussion on the bitcoin-dev mailing list focuses on whether the maximum block size limit should be part of the protocol or set by node operators as a policy. It is argued that rejecting a block based on a condition falls under the consensus protocol, while policies can vary between nodes without affecting block validity. The proposal of Block75 is criticized for giving miners complete control over the limit, contradicting the purpose of the block size limit to restrict miners and prevent spam. Another email exchange highlights the question of whether math or humans created Bitcoin. The writer argues that everything in Bitcoin is math except for the block size limit, which was a temporary solution at the time. The suggestion of a simple policy set by node operators is deemed unfeasible due to differing opinions and potential disasters. The role of miners in deciding the block size is discussed, as they earn more fee-based income with bigger blocks but also take on more risks.In a bitcoin-dev thread, a user proposes Block75 as a means to manage the maximum block size without human intervention. Some users express doubts about the proposal, stating that it gives miners control over the limit, which goes against the purpose of restricting miners. The importance of preventing a single nefarious miner from creating an overly large block is emphasized.The Block75 algorithm has undergone updates based on community feedback and simulations. The new algorithm aims to keep blocks 75% full by adjusting the maximum block size every 2016 blocks. The activation of the algorithm would require support from the majority of the last 1,000 blocks mined. The goal is to prevent a small mining pool from blocking the adoption of Block75 and mitigate risks associated with a hard fork. Questions are raised regarding compatibility with SegWit and the need for a minimum maximum block size. The community is encouraged to provide input on how the algorithm would behave in practice. The hope is that 2017 will mark the end of the block size debate. 2017-02-13T11:21:44+00:00 + The discussion revolves around the control of miners over the block size limit in Bitcoin. The proposal of Block75 algorithm is analyzed, which aims to manage the maximum block size without human intervention. However, concerns are raised about the potential centralization and loss of transaction fees that may arise from increasing the block size. The debate also delves into the definition of "miner spam" and the need for evidence to support this claim. The importance of miners in determining the block size limit is emphasized, as they have a financial incentive to produce bigger blocks but also face the risk of orphaned blocks. A discussion on the bitcoin-dev mailing list focuses on whether the maximum block size limit should be part of the protocol or set by node operators as a policy. It is argued that rejecting a block based on a condition falls under the consensus protocol, while policies can vary between nodes without affecting block validity. The proposal of Block75 is criticized for giving miners complete control over the limit, contradicting the purpose of the block size limit to restrict miners and prevent spam. Another email exchange highlights the question of whether math or humans created Bitcoin. The writer argues that everything in Bitcoin is math except for the block size limit, which was a temporary solution at the time. The suggestion of a simple policy set by node operators is deemed unfeasible due to differing opinions and potential disasters. The role of miners in deciding the block size is discussed, as they earn more fee-based income with bigger blocks but also take on more risks.In a bitcoin-dev thread, a user proposes Block75 as a means to manage the maximum block size without human intervention. Some users express doubts about the proposal, stating that it gives miners control over the limit, which goes against the purpose of restricting miners. The importance of preventing a single nefarious miner from creating an overly large block is emphasized.The Block75 algorithm has undergone updates based on community feedback and simulations. The new algorithm aims to keep blocks 75% full by adjusting the maximum block size every 2016 blocks. The activation of the algorithm would require support from the majority of the last 1,000 blocks mined. The goal is to prevent a small mining pool from blocking the adoption of Block75 and mitigate risks associated with a hard fork. Questions are raised regarding compatibility with SegWit and the need for a minimum maximum block size. The community is encouraged to provide input on how the algorithm would behave in practice. The hope is that 2017 will mark the end of the block size debate. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Bitcoin-Classic-1-2-0-released.xml b/static/bitcoin-dev/Jan_2017/combined_Bitcoin-Classic-1-2-0-released.xml index d5a10dbff1..346b45f46c 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Bitcoin-Classic-1-2-0-released.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Bitcoin-Classic-1-2-0-released.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Classic 1.2.0 released - 2023-08-01T19:24:04.901288+00:00 + 2025-09-26T16:04:36.918269+00:00 + python-feedgen Chris Priest 2017-01-08 01:58:27+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Classic 1.2.0 released - 2023-08-01T19:24:04.901288+00:00 + 2025-09-26T16:04:36.918479+00:00 - In leaked email conversations from January 7, 2017, members of the bitcoin-dev mailing list discussed concerns about the number of full nodes and the potential control of a majority of them. Eric Lombrozo reminded the group that the mailing list is for discussing new proposals and ideas, not rehashing old discussions. In July 2017, Eric Lombrozo criticized the release announcement of Bitcoin Classic version 1.2.0 for being incompatible with the current Bitcoin network and its consensus rules. He argued that it constituted a hard fork without safe activation and lacked evidence of community-wide consensus. Some members pointed out that Bitcoin Core had also implemented hard forks without activation or public debate.The discussion on the bitcoin-dev mailing list continued with concerns about the control of a majority of full nodes. Eric Voskuil argued that control over a majority of nodes is irrelevant because someone could easily spin up more nodes at a trivial cost. The discussion was redirected to focus on new ideas and proposals.In another email thread, Chris Priest argued that Bitcoin Classic's block format change only affects miners, not nodes or wallets. Others disagreed, stating that a decentralized system should affect everyone. The debate also touched on the potential weakness of the system if a few people control the majority of hashpower.Tom Zander sent an email stating that there is no formal activation threshold in Bitcoin Classic, but some argued that there exists an informal and practical threshold. Zander viewed Bitcoin Classic as a tool for achieving specific ends rather than a solution itself.Bitcoin Classic released version 1.2.0, which included bug fixes, performance improvements, and a decentralized block size solution. However, concerns were raised about the lack of community-wide consensus and clear labeling as a hard fork on mainnet with no safe activation. The release notes and changelog were also lacking in detail.Chris Priest stated that the fact that a few people control 75% of hashpower is a bug, not a feature.The ongoing debate between Bitcoin Classic and SegWit focused on the different approaches to block format changes. Bitcoin Classic required 75% miner adoption for activation, while Eric Lombrozo criticized its lack of compatibility with the current network and consensus rules. Tom Zander announced Bitcoin Classic version 1.2.0, highlighting the decentralized block size solution. Concerns were raised about the lack of community-wide consensus and clear labeling as a hard fork.Eric Lombrozo expressed concern over the clarity and safety of Bitcoin Classic's latest release. The release notes lacked detail, making it difficult for users to understand the changes. Tom Zander responded by stating that Bitcoin Classic is compatible with the current network and consensus rules. However, concerns remained about the lack of transparency and evidence of community-wide consensus for the hard fork.Bitcoin Classic version 1.2.0 was released with new features, bug fixes, and performance improvements. The release aimed to provide a high-quality validating node for various use cases. However, concerns were raised about the lack of community-wide consensus, clear labeling as a hard fork, and the absence of release notes and changelog in the GitHub repository.Members of the mailing list warned against posting release announcements for software that is incompatible with the current Bitcoin consensus rules. Despite this, Bitcoin Classic version 1.2.0 was released, marking a change in strategy for the company. The release included various bug fixes and performance improvements, as well as a decentralized block size solution. Bitcoin Classic aimed to provide users with a high-quality validating node and offered various projects with the beta label. More information about the release and Bitcoin Classic can be found on their GitHub page.In summary, the leaked email conversations highlighted debates about the number of full nodes and control over them. There were criticisms of Bitcoin Classic's release announcement for being incompatible with the current network and lacking community-wide consensus. Concerns were raised about the lack of transparency, clear labeling, and documentation for Bitcoin Classic's hard fork. The ongoing debate between Bitcoin Classic and SegWit centered around different approaches to block format changes. Overall, the cryptocurrency community continues to discuss these issues and the implications for the Bitcoin network.In the latest release, v1.2.0.Classic, Bitcoin users can expect a range of high-quality processes to enhance their experience. This update is designed to provide support and assistance to anyone utilizing Bitcoin. For further insight into this release and the Classic platform, a detailed video can be accessed at the following link: https://vimeo.com/192789752.The v1.2.0.Classic release aims to offer top-notch quality processes that will benefit all Bitcoin users. By implementing these improvements, the developers of Classic seek to provide enhanced functionality and efficiency for individuals involved in Bitcoin transactions. The release focuses on refining existing features and introducing new capabilities to ensure a seamless user experience.To gain a better understanding of the developments within this release, it is recommended to watch the informative video available at the provided link. This video offers 2017-01-08T01:58:27+00:00 + In leaked email conversations from January 7, 2017, members of the bitcoin-dev mailing list discussed concerns about the number of full nodes and the potential control of a majority of them. Eric Lombrozo reminded the group that the mailing list is for discussing new proposals and ideas, not rehashing old discussions. In July 2017, Eric Lombrozo criticized the release announcement of Bitcoin Classic version 1.2.0 for being incompatible with the current Bitcoin network and its consensus rules. He argued that it constituted a hard fork without safe activation and lacked evidence of community-wide consensus. Some members pointed out that Bitcoin Core had also implemented hard forks without activation or public debate.The discussion on the bitcoin-dev mailing list continued with concerns about the control of a majority of full nodes. Eric Voskuil argued that control over a majority of nodes is irrelevant because someone could easily spin up more nodes at a trivial cost. The discussion was redirected to focus on new ideas and proposals.In another email thread, Chris Priest argued that Bitcoin Classic's block format change only affects miners, not nodes or wallets. Others disagreed, stating that a decentralized system should affect everyone. The debate also touched on the potential weakness of the system if a few people control the majority of hashpower.Tom Zander sent an email stating that there is no formal activation threshold in Bitcoin Classic, but some argued that there exists an informal and practical threshold. Zander viewed Bitcoin Classic as a tool for achieving specific ends rather than a solution itself.Bitcoin Classic released version 1.2.0, which included bug fixes, performance improvements, and a decentralized block size solution. However, concerns were raised about the lack of community-wide consensus and clear labeling as a hard fork on mainnet with no safe activation. The release notes and changelog were also lacking in detail.Chris Priest stated that the fact that a few people control 75% of hashpower is a bug, not a feature.The ongoing debate between Bitcoin Classic and SegWit focused on the different approaches to block format changes. Bitcoin Classic required 75% miner adoption for activation, while Eric Lombrozo criticized its lack of compatibility with the current network and consensus rules. Tom Zander announced Bitcoin Classic version 1.2.0, highlighting the decentralized block size solution. Concerns were raised about the lack of community-wide consensus and clear labeling as a hard fork.Eric Lombrozo expressed concern over the clarity and safety of Bitcoin Classic's latest release. The release notes lacked detail, making it difficult for users to understand the changes. Tom Zander responded by stating that Bitcoin Classic is compatible with the current network and consensus rules. However, concerns remained about the lack of transparency and evidence of community-wide consensus for the hard fork.Bitcoin Classic version 1.2.0 was released with new features, bug fixes, and performance improvements. The release aimed to provide a high-quality validating node for various use cases. However, concerns were raised about the lack of community-wide consensus, clear labeling as a hard fork, and the absence of release notes and changelog in the GitHub repository.Members of the mailing list warned against posting release announcements for software that is incompatible with the current Bitcoin consensus rules. Despite this, Bitcoin Classic version 1.2.0 was released, marking a change in strategy for the company. The release included various bug fixes and performance improvements, as well as a decentralized block size solution. Bitcoin Classic aimed to provide users with a high-quality validating node and offered various projects with the beta label. More information about the release and Bitcoin Classic can be found on their GitHub page.In summary, the leaked email conversations highlighted debates about the number of full nodes and control over them. There were criticisms of Bitcoin Classic's release announcement for being incompatible with the current network and lacking community-wide consensus. Concerns were raised about the lack of transparency, clear labeling, and documentation for Bitcoin Classic's hard fork. The ongoing debate between Bitcoin Classic and SegWit centered around different approaches to block format changes. Overall, the cryptocurrency community continues to discuss these issues and the implications for the Bitcoin network.In the latest release, v1.2.0.Classic, Bitcoin users can expect a range of high-quality processes to enhance their experience. This update is designed to provide support and assistance to anyone utilizing Bitcoin. For further insight into this release and the Classic platform, a detailed video can be accessed at the following link: https://vimeo.com/192789752.The v1.2.0.Classic release aims to offer top-notch quality processes that will benefit all Bitcoin users. By implementing these improvements, the developers of Classic seek to provide enhanced functionality and efficiency for individuals involved in Bitcoin transactions. The release focuses on refining existing features and introducing new capabilities to ensure a seamless user experience.To gain a better understanding of the developments within this release, it is recommended to watch the informative video available at the provided link. This video offers - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Changing-the-transaction-version-number-to-be-varint.xml b/static/bitcoin-dev/Jan_2017/combined_Changing-the-transaction-version-number-to-be-varint.xml index c502705885..8fc1f6ebaa 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Changing-the-transaction-version-number-to-be-varint.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Changing-the-transaction-version-number-to-be-varint.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Changing the transaction version number to be varint - 2023-08-01T19:25:33.384629+00:00 + 2025-09-26T16:04:32.710598+00:00 + python-feedgen Johnson Lau 2017-01-26 12:57:32+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Changing the transaction version number to be varint - 2023-08-01T19:25:33.384629+00:00 + 2025-09-26T16:04:32.710746+00:00 - In January 2017, Tom Zander put forward a proposal to introduce a new transaction format for Bitcoin. The proposal suggested labeling bytes 2, 3, and 4 of the current transaction format as unused from a specific block height. It also recommended interpreting the first byte as varint, and only allowing transactions with a version number of 1 to be valid. However, there were some concerns raised about this proposal.One major issue was that implementing this change would require a hardfork, as existing nodes would not be able to deserialize the transaction. Additionally, it was pointed out that non-version 1 transactions have been permitted since v0.1, and version 2 transactions are already in use due to BIP68. Furthermore, if the proposal only affects network transfer, it would be considered a p2p protocol upgrade rather than a softfork or hardfork.The author of the proposal discusses three ways to introduce new transaction formats: through a softfork, which makes old clients unaware of the new format; through a hardfork, which requires new clients to understand the new format and leaves old clients behind; or p2p only, which has no impact on consensus. Regardless of the chosen method, the proposal states that one can introduce any new format they desire.The author also addresses the current structure of transactions, noting that the version field is always 4 bytes while the rest of the integer encoding is variable-sized. This means that bytes 2, 3, and 4 are typically set to zero. By changing the serialization of the version number to varint, each transaction would save three bytes. These bytes could then be used differently in version 1 transactions or may not be needed at all for newer formats. Another benefit of this change is that all integers in the transaction would follow the same var-int encoding, at least for FlexTrans.At present, there is no consensus rule that rejects transactions which provide false information about their version. Therefore, the proposed rule could only be implemented from a certain block height and would not apply retroactively. The suggested implementation involves labeling bytes 2, 3, and 4 as unused from the specified block height, while interpreting the first byte as varint. Additionally, a new rule would be added to only accept transactions with a version number of 1. This change could be made as a softfork.The author seeks feedback on any potential issues with this proposal. It is also worth noting that although most transactions have bytes 2, 3, and 4 set to zero, there is no transaction version defined that sets them to non-zero. For more details on the proposal, links to the Bitcoin Classic website and the author's blog and vlog are provided at the end of the context.Bitcoin Classic website: [link]Author's blog: [link]Author's vlog: [link] 2017-01-26T12:57:32+00:00 + In January 2017, Tom Zander put forward a proposal to introduce a new transaction format for Bitcoin. The proposal suggested labeling bytes 2, 3, and 4 of the current transaction format as unused from a specific block height. It also recommended interpreting the first byte as varint, and only allowing transactions with a version number of 1 to be valid. However, there were some concerns raised about this proposal.One major issue was that implementing this change would require a hardfork, as existing nodes would not be able to deserialize the transaction. Additionally, it was pointed out that non-version 1 transactions have been permitted since v0.1, and version 2 transactions are already in use due to BIP68. Furthermore, if the proposal only affects network transfer, it would be considered a p2p protocol upgrade rather than a softfork or hardfork.The author of the proposal discusses three ways to introduce new transaction formats: through a softfork, which makes old clients unaware of the new format; through a hardfork, which requires new clients to understand the new format and leaves old clients behind; or p2p only, which has no impact on consensus. Regardless of the chosen method, the proposal states that one can introduce any new format they desire.The author also addresses the current structure of transactions, noting that the version field is always 4 bytes while the rest of the integer encoding is variable-sized. This means that bytes 2, 3, and 4 are typically set to zero. By changing the serialization of the version number to varint, each transaction would save three bytes. These bytes could then be used differently in version 1 transactions or may not be needed at all for newer formats. Another benefit of this change is that all integers in the transaction would follow the same var-int encoding, at least for FlexTrans.At present, there is no consensus rule that rejects transactions which provide false information about their version. Therefore, the proposed rule could only be implemented from a certain block height and would not apply retroactively. The suggested implementation involves labeling bytes 2, 3, and 4 as unused from the specified block height, while interpreting the first byte as varint. Additionally, a new rule would be added to only accept transactions with a version number of 1. This change could be made as a softfork.The author seeks feedback on any potential issues with this proposal. It is also worth noting that although most transactions have bytes 2, 3, and 4 set to zero, there is no transaction version defined that sets them to non-zero. For more details on the proposal, links to the Bitcoin Classic website and the author's blog and vlog are provided at the end of the context.Bitcoin Classic website: [link]Author's blog: [link]Author's vlog: [link] - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml b/static/bitcoin-dev/Jan_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml index f4364d22b6..1797d15a3a 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml @@ -1,113 +1,147 @@ - + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 - - bfd at cock.lu 2017-04-01 23:49:03+00:00 - - - Tom Harding 2017-03-16 15:05:11+00:00 - - - bfd at cock.lu 2017-03-16 00:25:01+00:00 - - - Tom Harding 2017-03-15 22:36:09+00:00 - - - Chris Belcher 2017-02-17 00:28:59+00:00 - - - Erik Aronesty 2017-01-06 22:07:36+00:00 - - - Eric Voskuil 2017-01-06 21:50:47+00:00 - - - James MacWhyte 2017-01-06 21:35:58+00:00 - - - Chris Priest 2017-01-06 20:15:46+00:00 - - - Aaron Voisine 2017-01-06 07:07:34+00:00 - - - bfd at cock.lu 2017-01-06 02:15:26+00:00 - - - bfd at cock.lu 2017-01-06 02:04:22+00:00 - - - Christian Decker 2017-01-05 14:48:33+00:00 - - - Eric Voskuil 2017-01-05 07:45:18+00:00 - - - Chris Priest 2017-01-05 07:06:36+00:00 - - - Leo Wandersleb 2017-01-04 16:13:41+00:00 - - - Adam Back 2017-01-04 11:00:55+00:00 - - - Jorge Timón 2017-01-04 10:13:02+00:00 - - - Aaron Voisine 2017-01-04 08:56:21+00:00 - - - Jonas Schnelli 2017-01-04 07:47:10+00:00 - - - Eric Voskuil 2017-01-04 06:06:31+00:00 - - - Aaron Voisine 2017-01-04 00:36:34+00:00 - - - bfd at cock.lu 2017-01-04 00:10:14+00:00 - - - Aaron Voisine 2017-01-03 23:46:00+00:00 - - - adiabat 2017-01-03 23:06:26+00:00 - - - bfd at cock.lu 2017-01-03 22:28:56+00:00 - - - Aaron Voisine 2017-01-03 22:18:21+00:00 - - - bfd at cock.lu 2017-01-03 20:24:35+00:00 - - - bfd at cock.lu 2017-01-03 20:18:59+00:00 - - - Jonas Schnelli 2017-01-01 21:01:23+00:00 - - - Leo Wandersleb 2016-07-28 21:07:29+00:00 - - - Bob McElrath 2016-05-11 20:29:33+00:00 - - - Bob McElrath 2016-05-11 20:06:48+00:00 - - - Gregory Maxwell 2016-05-09 08:57:08+00:00 - - - bfd at cock.lu 2016-05-09 08:26:06+00:00 - + 2025-09-26T16:04:47.498339+00:00 + python-feedgen + + + [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd + 2016-05-09T08:26:00.000Z + + + Gregory Maxwell + 2016-05-09T08:57:00.000Z + + + Bob McElrath + 2016-05-11T20:06:00.000Z + + + Bob McElrath + 2016-05-11T20:29:00.000Z + + + Leo Wandersleb + 2016-07-28T21:07:00.000Z + + + bfd + 2017-01-03T20:18:00.000Z + + + bfd + 2017-01-03T20:24:00.000Z + + + Aaron Voisine + 2017-01-03T22:18:00.000Z + + + bfd + 2017-01-03T22:28:00.000Z + + + adiabat + 2017-01-03T23:06:00.000Z + + + Aaron Voisine + 2017-01-03T23:46:00.000Z + + + bfd + 2017-01-04T00:10:00.000Z + + + Aaron Voisine + 2017-01-04T00:36:00.000Z + + + Eric Voskuil + 2017-01-04T06:06:00.000Z + + + Jonas Schnelli + 2017-01-04T07:47:00.000Z + + + Aaron Voisine + 2017-01-04T08:56:00.000Z + + + Jorge Timón + 2017-01-04T10:13:00.000Z + + + Adam Back + 2017-01-04T11:00:00.000Z + + + Leo Wandersleb + 2017-01-04T16:13:00.000Z + + + Chris Priest + 2017-01-05T07:06:00.000Z + + + Eric Voskuil + 2017-01-05T07:45:00.000Z + + + Christian Decker + 2017-01-05T14:48:00.000Z + + + bfd + 2017-01-06T02:04:00.000Z + + + bfd + 2017-01-06T02:15:00.000Z + + + Aaron Voisine + 2017-01-06T07:07:00.000Z + + + Chris Priest + 2017-01-06T20:15:00.000Z + + + James MacWhyte + 2017-01-06T21:35:00.000Z + + + Eric Voskuil + 2017-01-06T21:50:00.000Z + + + Erik Aronesty + 2017-01-06T22:07:00.000Z + + + Chris Belcher + 2017-02-17T00:28:00.000Z + + + Tom Harding + 2017-03-15T22:36:00.000Z + + + bfd + 2017-03-16T00:25:00.000Z + + + Tom Harding + 2017-03-16T15:05:00.000Z + + + bfd + 2017-04-01T23:49:00.000Z + + @@ -143,13 +177,13 @@ - python-feedgen + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 + 2025-09-26T16:04:47.502105+00:00 - In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On 2017-04-01T23:49:03+00:00 + In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Extension-block-softfork-proposal.xml b/static/bitcoin-dev/Jan_2017/combined_Extension-block-softfork-proposal.xml index 817f4496e8..52403763a5 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Extension-block-softfork-proposal.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Extension-block-softfork-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Extension block softfork proposal - 2023-08-01T19:26:58.898298+00:00 + 2025-09-26T16:04:30.600583+00:00 + python-feedgen Matt Corallo 2017-01-28 00:35:55+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Extension block softfork proposal - 2023-08-01T19:26:58.898298+00:00 + 2025-09-26T16:04:30.600718+00:00 - The email discusses the controversial idea of an extension block, which would allow for more block space through a soft fork. The extension block proposal is seen as coercive because it allows transactions to occur in data that those who choose not to enforce the soft fork's rules have decided to ignore. This makes it difficult to track transaction history and identify risks based on potential censorship-enforced transactions. It also forces the entire network to trust the extension block instead of opting into a soft fork's security.The email argues that this sets a dangerous precedent, as miners may start soft-forking in sidechains, posing a significant risk. Additionally, there is a social cost associated with implementing an extension block. On a different note, the proposal describes a method for sending bitcoins from the main UTXO to an xUTXO, where people can trade inside the xblock just like in the main block.The integration of UTXO and transaction is explained in detail, including special bridging witness programs for returning transactions and fees collection in the xblock. However, sending money back from the xblock to the main block requires 100-block maturity for the returning UTXO, significantly changing the user experience.The proposal raises questions about simplifying the design without compromising security, eliminating the 100-block maturity requirement, and reducing the maturity time. To ensure that the recipient won't be paid with a returning transaction unless explicitly requested, the direction flag is suggested, which may be combined with the serialized witness version to save one byte.Overall, the proposal is presented for discussion on the bitcoin-dev mailing list. It aims to implement extra block space through a soft fork while maintaining existing security assumptions and being transparent to existing wallets. However, new wallets taking advantage of the extra block space will have a different user experience. The proposal defines terminology such as main block/tx/UTXO, extension transaction/block/UTXO, bridging witness program, integrating UTXO/transaction, returning transaction, fees collection in xblock, and xblock commitment.The proposal also acknowledges the challenge of sending money from the side chain to the main chain, but presents solutions to overcome this challenge. It raises questions about simplifying the design, eliminating the 100-block maturity requirement, and reducing the 100-block overkill. 2017-01-28T00:35:55+00:00 + The email discusses the controversial idea of an extension block, which would allow for more block space through a soft fork. The extension block proposal is seen as coercive because it allows transactions to occur in data that those who choose not to enforce the soft fork's rules have decided to ignore. This makes it difficult to track transaction history and identify risks based on potential censorship-enforced transactions. It also forces the entire network to trust the extension block instead of opting into a soft fork's security.The email argues that this sets a dangerous precedent, as miners may start soft-forking in sidechains, posing a significant risk. Additionally, there is a social cost associated with implementing an extension block. On a different note, the proposal describes a method for sending bitcoins from the main UTXO to an xUTXO, where people can trade inside the xblock just like in the main block.The integration of UTXO and transaction is explained in detail, including special bridging witness programs for returning transactions and fees collection in the xblock. However, sending money back from the xblock to the main block requires 100-block maturity for the returning UTXO, significantly changing the user experience.The proposal raises questions about simplifying the design without compromising security, eliminating the 100-block maturity requirement, and reducing the maturity time. To ensure that the recipient won't be paid with a returning transaction unless explicitly requested, the direction flag is suggested, which may be combined with the serialized witness version to save one byte.Overall, the proposal is presented for discussion on the bitcoin-dev mailing list. It aims to implement extra block space through a soft fork while maintaining existing security assumptions and being transparent to existing wallets. However, new wallets taking advantage of the extra block space will have a different user experience. The proposal defines terminology such as main block/tx/UTXO, extension transaction/block/UTXO, bridging witness program, integrating UTXO/transaction, returning transaction, fees collection in xblock, and xblock commitment.The proposal also acknowledges the challenge of sending money from the side chain to the main chain, but presents solutions to overcome this challenge. It raises questions about simplifying the design, eliminating the 100-block maturity requirement, and reducing the 100-block overkill. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml b/static/bitcoin-dev/Jan_2017/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml index f291629158..78778790b7 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Forcenet: an experimental network with a new header format - 2023-08-01T19:17:12.881545+00:00 + 2025-09-26T16:04:45.377016+00:00 + python-feedgen Matt Corallo 2017-01-28 17:14:02+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Forcenet: an experimental network with a new header format - 2023-08-01T19:17:12.882543+00:00 + 2025-09-26T16:04:45.377203+00:00 - The Bitcoin-dev mailing list has been discussing proposals for changes to the Bitcoin protocol. Some of the proposed changes include removing the block size limit, limiting the creation of unspent transaction outputs (UTXOs) and encouraging their spending, and implementing a smoother halving cycle for block rewards. There are also proposals for a new coinbase transaction format and a Merkle sum tree for fraud-proofing.Matt Corallo suggests minimizing header size, having only one merkle tree for transactions, and avoiding variable-length header fields. He also discusses light wallet functionality without an upgrade and the Stratum protocol. Another proposal titled "Client Side Block Filtering" suggests an alternative method of block downloading that allows clients to filter blocks based on specific criteria.Johnson Lau introduces a second version of forcenet with experimental features, including anti-tx-replay and block sighashlimit. The author of the context also creates a second version of forcenet with new experimental features, such as a new header format and anti-tx-replay. There is a discussion about the concept of a sum tree and softfork in Bitcoin, as well as the issue with redefining nSigOp in a sum tree and the proposal to combine the two costs into a unified cost.In December 2016, a discussion took place regarding the use of a timestamp beyond 4 bytes. Luke Dashjr proposed stealing a few bits from the tx nVersion through a softfork as a solution. There were also discussions about the implementation of a new merkle algorithm using a sum tree, communication with legacy nodes, and the possibility of enabling easier soft forks through a bridge node. Suggestions were made to keep hashing to a minimum and to consider an 8-byte timestamp due to the approaching year 2106.Overall, the Bitcoin-dev mailing list concludes that some proposals may not be essential for the hard fork and could be added later through a soft fork. Forcenet, an experimental network, was created to demonstrate a new header format, but some aspects have not yet been implemented. Codes for testing can be found on Github, and joining the network is possible by running "bitcoind --forcenet" and connecting to the node running at 8333.info with the default port. 2017-01-28T17:14:02+00:00 + The Bitcoin-dev mailing list has been discussing proposals for changes to the Bitcoin protocol. Some of the proposed changes include removing the block size limit, limiting the creation of unspent transaction outputs (UTXOs) and encouraging their spending, and implementing a smoother halving cycle for block rewards. There are also proposals for a new coinbase transaction format and a Merkle sum tree for fraud-proofing.Matt Corallo suggests minimizing header size, having only one merkle tree for transactions, and avoiding variable-length header fields. He also discusses light wallet functionality without an upgrade and the Stratum protocol. Another proposal titled "Client Side Block Filtering" suggests an alternative method of block downloading that allows clients to filter blocks based on specific criteria.Johnson Lau introduces a second version of forcenet with experimental features, including anti-tx-replay and block sighashlimit. The author of the context also creates a second version of forcenet with new experimental features, such as a new header format and anti-tx-replay. There is a discussion about the concept of a sum tree and softfork in Bitcoin, as well as the issue with redefining nSigOp in a sum tree and the proposal to combine the two costs into a unified cost.In December 2016, a discussion took place regarding the use of a timestamp beyond 4 bytes. Luke Dashjr proposed stealing a few bits from the tx nVersion through a softfork as a solution. There were also discussions about the implementation of a new merkle algorithm using a sum tree, communication with legacy nodes, and the possibility of enabling easier soft forks through a bridge node. Suggestions were made to keep hashing to a minimum and to consider an 8-byte timestamp due to the approaching year 2106.Overall, the Bitcoin-dev mailing list concludes that some proposals may not be essential for the hard fork and could be added later through a soft fork. Forcenet, an experimental network, was created to demonstrate a new header format, but some aspects have not yet been implemented. Codes for testing can be found on Github, and joining the network is possible by running "bitcoind --forcenet" and connecting to the node running at 8333.info with the default port. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Mutli-push-op-return.xml b/static/bitcoin-dev/Jan_2017/combined_Mutli-push-op-return.xml index 0c3c4a4528..c470bd630b 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Mutli-push-op-return.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Mutli-push-op-return.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mutli-push op_return - 2023-08-01T19:24:16.794866+00:00 + 2025-09-26T16:04:41.147791+00:00 + python-feedgen Chris 2017-01-09 04:32:53+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Mutli-push op_return - 2023-08-01T19:24:16.794866+00:00 + 2025-09-26T16:04:41.147917+00:00 - The author of a script wiki is questioning whether multiple pushdatas in op_return would be considered standard. Although the code does not explicitly state that only one pushdata is allowed, the script wiki may not be up to date. The policy.cpp file on Github does not seem to limit the number of pushdatas allowed in op_return. A user named Chris asked if there would be any objections to making op_return outputs with two pushdatas standard, with the same maximum data size. In response, Luke Dashjr stated that standards (BIPs) should describe a specific use case and protocol for implementing such outputs. He also mentioned that most nodes have a default policy that allows them.On January 9, 2017, Chris proposed a question about standardizing op_return outputs with two pushdatas. Luke responded that BIPs should provide a specific use case and protocol for implementation, and most nodes already allow such outputs by default.The proposal aims to make op_return outputs with two pushdatas standard, with the same maximum data size. This is intended to facilitate tagging transactions so they can be returned by bloom filtering nodes. By using the op_return output script, transactions can be easily fetched if their tag matches a specific pattern. It seems that a significant number of nodes and miners already accept such transactions, as the first block was mined using this method. 2017-01-09T04:32:53+00:00 + The author of a script wiki is questioning whether multiple pushdatas in op_return would be considered standard. Although the code does not explicitly state that only one pushdata is allowed, the script wiki may not be up to date. The policy.cpp file on Github does not seem to limit the number of pushdatas allowed in op_return. A user named Chris asked if there would be any objections to making op_return outputs with two pushdatas standard, with the same maximum data size. In response, Luke Dashjr stated that standards (BIPs) should describe a specific use case and protocol for implementing such outputs. He also mentioned that most nodes have a default policy that allows them.On January 9, 2017, Chris proposed a question about standardizing op_return outputs with two pushdatas. Luke responded that BIPs should provide a specific use case and protocol for implementation, and most nodes already allow such outputs by default.The proposal aims to make op_return outputs with two pushdatas standard, with the same maximum data size. This is intended to facilitate tagging transactions so they can be returned by bloom filtering nodes. By using the op_return output script, transactions can be easily fetched if their tag matches a specific pattern. It seems that a significant number of nodes and miners already accept such transactions, as the first block was mined using this method. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Script-Abuse-Potential-.xml b/static/bitcoin-dev/Jan_2017/combined_Script-Abuse-Potential-.xml index cf539c3ac9..85577e9e4b 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Script-Abuse-Potential-.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Script-Abuse-Potential-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Script Abuse Potential? - 2023-08-01T19:22:42.597136+00:00 + 2025-09-26T16:04:39.030411+00:00 + python-feedgen Jeremy 2017-01-05 16:22:34+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Script Abuse Potential? - 2023-08-01T19:22:42.598136+00:00 + 2025-09-26T16:04:39.030608+00:00 - The bitcoin-dev mailing list is currently engaged in a discussion regarding the controversial opcode OP_CAT. Some members are advocating for a direct limit on OP_CAT, while others prefer a general memory limit. Previously, OP_CAT had a limit of 5000 bytes, but it was disabled by Satoshi on August 15, 2010, and replaced with a limit of 520 bytes. There are concerns that enabling OP_CAT could potentially enable covenants, but some argue that a script with a large number of OP_2DUPs would be more concerning. The MAX_SCRIPT_ELEMENT_SIZE is set at 520 bytes, so the worst-case scenario for a script using OP_CAT would be around 10 MB. The discussion also delves into the memory usage cost of each instruction and the need to reasonably bound it. While there is debate about implementing a general memory limit, some participants argue that it is challenging to create a non-implementation dependent memory limit. The group is striving to find the best approach to prevent future memory-risky opcodes from causing issues.On January 2, 2017, a user named Steve Davis posted a question on the bitcoin-dev mailing list regarding a potential attack vector involving a specific pk_script. Jeremy Rubin responded, stating that the script would not pose a significant threat and the worst it could do is consume approximately 10 MB of memory. Johnson Lau added that a script can only contain up to 201 opcodes, and the maximum size for OP_CAT is set at 520 bytes. On January 3, 2017, Rubin reiterated his view that the elements alpha proposal to reintroduce a limited OP_CAT to 520 bytes sparked controversy. Russell O'Connor further clarified that Satoshi had implemented the OP_CAT limit of 520 bytes on August 15, 2010, when disabling OP_CAT, as the previous limit was 5000 bytes.In summary, the bitcoin-dev mailing list is currently engaged in a discussion about the opcode OP_CAT. The debate revolves around implementing a direct limit or a general memory limit for OP_CAT. Concerns exist regarding the potential enabling of covenants if OP_CAT is enabled. However, some argue that a script with numerous OP_2DUPs poses a more significant concern. The MAX_SCRIPT_ELEMENT_SIZE is set at 520 bytes, limiting the worst-case scenario to approximately 10 MB for a script utilizing OP_CAT. The discussion also touches on the memory usage cost of each instruction and the challenges of establishing a non-implementation dependent memory limit. On January 2, 2017, a user raised a question about a potential attack vector involving a specific pk_script, which Jeremy Rubin and Johnson Lau responded to. Rubin mentioned the controversy surrounding the elements alpha proposal to reintroduce a limited OP_CAT to 520 bytes, while Russell O'Connor clarified Satoshi's implementation of the 520-byte limit when disabling OP_CAT on August 15, 2010. 2017-01-05T16:22:34+00:00 + The bitcoin-dev mailing list is currently engaged in a discussion regarding the controversial opcode OP_CAT. Some members are advocating for a direct limit on OP_CAT, while others prefer a general memory limit. Previously, OP_CAT had a limit of 5000 bytes, but it was disabled by Satoshi on August 15, 2010, and replaced with a limit of 520 bytes. There are concerns that enabling OP_CAT could potentially enable covenants, but some argue that a script with a large number of OP_2DUPs would be more concerning. The MAX_SCRIPT_ELEMENT_SIZE is set at 520 bytes, so the worst-case scenario for a script using OP_CAT would be around 10 MB. The discussion also delves into the memory usage cost of each instruction and the need to reasonably bound it. While there is debate about implementing a general memory limit, some participants argue that it is challenging to create a non-implementation dependent memory limit. The group is striving to find the best approach to prevent future memory-risky opcodes from causing issues.On January 2, 2017, a user named Steve Davis posted a question on the bitcoin-dev mailing list regarding a potential attack vector involving a specific pk_script. Jeremy Rubin responded, stating that the script would not pose a significant threat and the worst it could do is consume approximately 10 MB of memory. Johnson Lau added that a script can only contain up to 201 opcodes, and the maximum size for OP_CAT is set at 520 bytes. On January 3, 2017, Rubin reiterated his view that the elements alpha proposal to reintroduce a limited OP_CAT to 520 bytes sparked controversy. Russell O'Connor further clarified that Satoshi had implemented the OP_CAT limit of 520 bytes on August 15, 2010, when disabling OP_CAT, as the previous limit was 5000 bytes.In summary, the bitcoin-dev mailing list is currently engaged in a discussion about the opcode OP_CAT. The debate revolves around implementing a direct limit or a general memory limit for OP_CAT. Concerns exist regarding the potential enabling of covenants if OP_CAT is enabled. However, some argue that a script with numerous OP_2DUPs poses a more significant concern. The MAX_SCRIPT_ELEMENT_SIZE is set at 520 bytes, limiting the worst-case scenario to approximately 10 MB for a script utilizing OP_CAT. The discussion also touches on the memory usage cost of each instruction and the challenges of establishing a non-implementation dependent memory limit. On January 2, 2017, a user raised a question about a potential attack vector involving a specific pk_script, which Jeremy Rubin and Johnson Lau responded to. Rubin mentioned the controversy surrounding the elements alpha proposal to reintroduce a limited OP_CAT to 520 bytes, while Russell O'Connor clarified Satoshi's implementation of the 520-byte limit when disabling OP_CAT on August 15, 2010. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Three-hardfork-related-BIPs.xml b/static/bitcoin-dev/Jan_2017/combined_Three-hardfork-related-BIPs.xml index f41157249a..2f85664d07 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Three-hardfork-related-BIPs.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Three-hardfork-related-BIPs.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Three hardfork-related BIPs - 2023-08-01T19:28:00.093200+00:00 - - Staf Verhaegen 2017-02-11 15:26:33+00:00 - - - Eric Voskuil 2017-02-07 20:32:46+00:00 - - - mbtc-dev at xe0.me 2017-02-06 16:24:10+00:00 - - - David Vorick 2017-01-29 19:39:46+00:00 - - - Eric Voskuil 2017-01-29 19:37:07+00:00 - - - Tom Harding 2017-01-29 19:15:38+00:00 - - - Peter Todd 2017-01-28 21:54:00+00:00 - - - Luke Dashjr 2017-01-28 19:43:48+00:00 - - - Peter Todd 2017-01-28 18:29:32+00:00 - - - Peter Todd 2017-01-28 18:22:25+00:00 - - - Natanael 2017-01-28 10:36:16+00:00 - - - Luke Dashjr 2017-01-28 04:03:03+00:00 - - - Andrew Johnson 2017-01-27 23:53:02+00:00 - - - Christian Decker 2017-01-27 21:28:10+00:00 - - - Greg Sanders 2017-01-27 20:47:20+00:00 - - - Russell O'Connor 2017-01-27 20:34:13+00:00 - - - t. khan 2017-01-27 18:54:26+00:00 - - - Daniele Pinna 2017-01-27 12:12:57+00:00 - - - Andrew Johnson 2017-01-27 06:13:34+00:00 - - - Johnson Lau 2017-01-27 04:21:21+00:00 - - - Luke Dashjr 2017-01-27 04:14:16+00:00 - - - Andrew Johnson 2017-01-27 03:04:50+00:00 - - - Luke Dashjr 2017-01-27 01:06:59+00:00 - + 2025-09-26T16:04:49.622568+00:00 + python-feedgen + + + [bitcoin-dev] Three hardfork-related BIPs Luke Dashjr + 2017-01-27T01:06:00.000Z + + + Andrew Johnson + 2017-01-27T03:04:00.000Z + + + Luke Dashjr + 2017-01-27T04:14:00.000Z + + + Johnson Lau + 2017-01-27T04:21:00.000Z + + + Andrew Johnson + 2017-01-27T06:13:00.000Z + + + Daniele Pinna + 2017-01-27T12:12:00.000Z + + + t. khan + 2017-01-27T18:54:00.000Z + + + Russell O'Connor + 2017-01-27T20:34:00.000Z + + + Greg Sanders + 2017-01-27T20:47:00.000Z + + + Christian Decker + 2017-01-27T21:28:00.000Z + + + Andrew Johnson + 2017-01-27T23:53:00.000Z + + + Luke Dashjr + 2017-01-28T04:03:00.000Z + + + Natanael + 2017-01-28T10:36:00.000Z + + + Peter Todd + 2017-01-28T18:22:00.000Z + + + Peter Todd + 2017-01-28T18:29:00.000Z + + + Luke Dashjr + 2017-01-28T19:43:00.000Z + + + Peter Todd + 2017-01-28T21:54:00.000Z + + + Tom Harding + 2017-01-29T19:15:00.000Z + + + Eric Voskuil + 2017-01-29T19:37:00.000Z + + + David Vorick + 2017-01-29T19:39:00.000Z + + + mbtc-dev + 2017-02-06T16:24:00.000Z + + + Eric Voskuil + 2017-02-07T20:32:00.000Z + + + Staf Verhaegen + 2017-02-11T15:26:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - Three hardfork-related BIPs - 2023-08-01T19:28:00.093200+00:00 + 2025-09-26T16:04:49.625042+00:00 - A recent research paper has established that the maximum block size that the Bitcoin network can handle safely is conservatively no more than 4MB. However, this conclusion only takes into account a subset of possible metrics and may be viewed as an upper bound. The paper does not discuss mining centralization pressure or DoS attacks, which are important factors to consider when determining the safe block size limit.There has been disagreement over a hardfork proposal submitted by Luke Dashjr to gradually increase the block size limit to 31MB while extending witness discount to non-segwit transactions. Critics argue that this proposal may alienate miners, assumes the current 1MB limit is already at its upper limit, and lacks incentives for individuals to run full nodes. They believe that the proposal would hinder Bitcoin Core and drive miners towards using Unlimited instead.Luke Dashjr has proposed three hardfork-related BIPs to address the block size issue. The first proposal suggests reducing the block size limit initially to a more sustainable size and gradually increasing it to 31 MB over time. The second proposal allows certain hardforks to be transformed into softforks in the future. The third proposal aims to prevent replay attacks induced by a hardfork-related chain split or in ordinary operation. Dashjr recommends immediate adoption of the first proposal but welcomes review and suggested changes.In response to criticism, Luke Dashjr clarified that his proposal to reduce the block size limit to 300KB would only occur if it activates before April 2017. He believes that such a reduction would be beneficial for the network in the long-term by squeezing out spam and unsustainable microtransaction use. Dashjr disagrees with claims that the network is already at capacity and argues that a reduction in block size could address these concerns.The current block size limit of 1MB is a point of contention, with some arguing it is too small and others arguing it is too big. However, alternatives to reducing the block size exist, such as blockchain pruning and limiting UTXO size. Luke Dashjr's proposals provide potential solutions to the block size issue, but further review and feedback are needed.Overall, the block size debate in the Bitcoin community continues, with different proposals and viewpoints being discussed. 2017-02-11T15:26:33+00:00 + A recent research paper has established that the maximum block size that the Bitcoin network can handle safely is conservatively no more than 4MB. However, this conclusion only takes into account a subset of possible metrics and may be viewed as an upper bound. The paper does not discuss mining centralization pressure or DoS attacks, which are important factors to consider when determining the safe block size limit.There has been disagreement over a hardfork proposal submitted by Luke Dashjr to gradually increase the block size limit to 31MB while extending witness discount to non-segwit transactions. Critics argue that this proposal may alienate miners, assumes the current 1MB limit is already at its upper limit, and lacks incentives for individuals to run full nodes. They believe that the proposal would hinder Bitcoin Core and drive miners towards using Unlimited instead.Luke Dashjr has proposed three hardfork-related BIPs to address the block size issue. The first proposal suggests reducing the block size limit initially to a more sustainable size and gradually increasing it to 31 MB over time. The second proposal allows certain hardforks to be transformed into softforks in the future. The third proposal aims to prevent replay attacks induced by a hardfork-related chain split or in ordinary operation. Dashjr recommends immediate adoption of the first proposal but welcomes review and suggested changes.In response to criticism, Luke Dashjr clarified that his proposal to reduce the block size limit to 300KB would only occur if it activates before April 2017. He believes that such a reduction would be beneficial for the network in the long-term by squeezing out spam and unsustainable microtransaction use. Dashjr disagrees with claims that the network is already at capacity and argues that a reduction in block size could address these concerns.The current block size limit of 1MB is a point of contention, with some arguing it is too small and others arguing it is too big. However, alternatives to reducing the block size exist, such as blockchain pruning and limiting UTXO size. Luke Dashjr's proposals provide potential solutions to the block size issue, but further review and feedback are needed.Overall, the block size debate in the Bitcoin community continues, with different proposals and viewpoints being discussed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2017/combined_Transaction-Replacement-by-Fee.xml b/static/bitcoin-dev/Jan_2017/combined_Transaction-Replacement-by-Fee.xml index 155b41d3f0..7765f85a2f 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Transaction-Replacement-by-Fee.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Transaction-Replacement-by-Fee.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Transaction Replacement by Fee - 2023-08-01T19:25:09.374497+00:00 + 2025-09-26T16:04:28.488939+00:00 + python-feedgen Andrew 2017-01-28 18:34:58+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Transaction Replacement by Fee - 2023-08-01T19:25:09.374497+00:00 + 2025-09-26T16:04:28.489100+00:00 - The user in this context is attempting to get RBF (Replace-By-Fee) working on a multisig input. They set the nSequence to 0, but encountered a failure when using python-bitcoinlib to verify the script. The user is using the SignatureHash(...) method for signing instead of rpc.signrawtransaction(...). BIP125 (Bitcoin Improvement Proposal) is mentioned as the standard way to signal and a link to BIP125 is provided for further information. It is noted that some miners mine full replace-by-fee without limitations on nSequence.Peter Todd's implementation of full RBF for v0.13.2 can be found on his Github page. This implementation is identical to Bitcoin Core with the exception of removing nSequence and adding a special service bit to allow full-RBF nodes to preferentially peer with each other for propagation of replacement transactions. While it is faster to use the nSequence signaling specified in BIP-125, it is not mandatory as long as the replacement transaction can reach a full-RBF node. Contact information for Peter Todd is also provided.In a post to the bitcoin-dev mailing list, Greg Sanders explains that BIP125 is the standard way to signal for transaction replacement. The GitHub link provided contains all the necessary information to understand BIP125. Some miners mine full replace-by-fee without limitations on nSequence. Peter Todd's implementation of this feature for v0.13.2 can be found on his GitHub page, which is similar to Bitcoin Core but with the removal of nSequence and the addition of a special service bit for full-RBF node peering. Although using the nSequence signaling in BIP-125 is faster, it is not mandatory if the replacement transaction reaches a full-RBF node.An email thread on the bitcoin-dev mailing list from January 12, 2017, discusses the rules for transaction replacement in Bitcoin. The sender, Police Terror, seeks clarification on the valid ranges for sequence values in transaction inputs and whether it is possible to change outputs or add additional inputs to pay higher fees. The response suggests referencing BIP125 as the standard way to signal for transaction replacement. A GitHub link is provided for further information on BIP125. This email thread serves as a resource for individuals seeking guidance on Bitcoin transaction replacement.The sender of the message is seeking information on transaction replacement rules in Bitcoin. They specifically want to know the valid ranges for sequence values in transaction inputs and if it is possible to change outputs or add more inputs to pay a higher fee. The sender typically sets the sequence value to MAX_UINT32 and locktime to 0. They are looking for clarity on these aspects of Bitcoin and would appreciate any available resources. 2017-01-28T18:34:58+00:00 + The user in this context is attempting to get RBF (Replace-By-Fee) working on a multisig input. They set the nSequence to 0, but encountered a failure when using python-bitcoinlib to verify the script. The user is using the SignatureHash(...) method for signing instead of rpc.signrawtransaction(...). BIP125 (Bitcoin Improvement Proposal) is mentioned as the standard way to signal and a link to BIP125 is provided for further information. It is noted that some miners mine full replace-by-fee without limitations on nSequence.Peter Todd's implementation of full RBF for v0.13.2 can be found on his Github page. This implementation is identical to Bitcoin Core with the exception of removing nSequence and adding a special service bit to allow full-RBF nodes to preferentially peer with each other for propagation of replacement transactions. While it is faster to use the nSequence signaling specified in BIP-125, it is not mandatory as long as the replacement transaction can reach a full-RBF node. Contact information for Peter Todd is also provided.In a post to the bitcoin-dev mailing list, Greg Sanders explains that BIP125 is the standard way to signal for transaction replacement. The GitHub link provided contains all the necessary information to understand BIP125. Some miners mine full replace-by-fee without limitations on nSequence. Peter Todd's implementation of this feature for v0.13.2 can be found on his GitHub page, which is similar to Bitcoin Core but with the removal of nSequence and the addition of a special service bit for full-RBF node peering. Although using the nSequence signaling in BIP-125 is faster, it is not mandatory if the replacement transaction reaches a full-RBF node.An email thread on the bitcoin-dev mailing list from January 12, 2017, discusses the rules for transaction replacement in Bitcoin. The sender, Police Terror, seeks clarification on the valid ranges for sequence values in transaction inputs and whether it is possible to change outputs or add additional inputs to pay higher fees. The response suggests referencing BIP125 as the standard way to signal for transaction replacement. A GitHub link is provided for further information on BIP125. This email thread serves as a resource for individuals seeking guidance on Bitcoin transaction replacement.The sender of the message is seeking information on transaction replacement rules in Bitcoin. They specifically want to know the valid ranges for sequence values in transaction inputs and if it is possible to change outputs or add more inputs to pay a higher fee. The sender typically sets the sequence value to MAX_UINT32 and locktime to 0. They are looking for clarity on these aspects of Bitcoin and would appreciate any available resources. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_2-step-confirmation-system.xml b/static/bitcoin-dev/Jan_2018/combined_2-step-confirmation-system.xml index 60f0ad52f8..6d5df81c29 100644 --- a/static/bitcoin-dev/Jan_2018/combined_2-step-confirmation-system.xml +++ b/static/bitcoin-dev/Jan_2018/combined_2-step-confirmation-system.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 2 step confirmation system - 2023-08-01T22:33:11.929457+00:00 + 2025-09-26T15:43:47.344324+00:00 + python-feedgen Weiwu Zhang 2018-01-30 01:23:13+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - 2 step confirmation system - 2023-08-01T22:33:11.929457+00:00 + 2025-09-26T15:43:47.344508+00:00 - The email thread addresses two major concerns surrounding Bitcoin. The first concern revolves around the fear of losing Bitcoin due to a mistake while entering the recipient's address. To tackle this issue, the suggestion is to have the beneficiary's wallet generate a signed payment request instead of just an address. By doing so, the sender would not be able to generate a payment request for the merchant as they lack the merchant's key. Additionally, another proposed solution involves sending the transaction to the beneficiary through a private channel instead of broadcasting it. In this case, the beneficiary would refrain from broadcasting the transaction if they do not receive the expected payment or if the transaction was not properly constructed according to their preferences. This method also caters to deniable payments. The second concern raised is the desire for a 2-step confirmation system when engaging with unfamiliar individuals. To address this concern, the suggestion is to utilize an escrow system with or without an arbitrator. Without an arbitrator, the resolution of the transaction typically depends on time or revealing a known hash value. With an arbitrator, a secure model can be implemented where a compromised arbitrator is only able to revert transactions and not steal funds. Importantly, none of the proposed methods require any changes to the Bitcoin network or blockchain. Wallet developers have the ability to implement these approaches independently without needing to negotiate with Bitcoin developers.While Bitcoin addresses already have a checksum to minimize input errors, there is still a risk of malware replacing the intended address with one controlled by the malware author. Therefore, verifying the correct address remains a concern. The mention of "bitcoin multisig" and "bitcoin escrow" in a Google search highlights support for these concepts within the core Bitcoin protocol. The individual expressing their concerns suggests that for deals involving less than 100 Bitcoin, it is simpler to use a trusted single-party escrow rather than dealing with the complexities of "2 of 3 multisig". In conversations with non-Bitcoin users, two primary concerns often arise. Firstly, there is a fear of losing Bitcoin if an incorrect address is entered. Secondly, there is a desire for a two-step confirmation system when engaging with unknown parties. The proposed solution involves implementing a two-step system that acts as an escrow, allowing both parties to provide final approval within a specified timeframe. This system could potentially alleviate anxiety surrounding Bitcoin transactions. The author acknowledges that the current forum may not be the ideal platform for discussing these ideas but expresses gratitude for the reader's time. 2018-01-30T01:23:13+00:00 + The email thread addresses two major concerns surrounding Bitcoin. The first concern revolves around the fear of losing Bitcoin due to a mistake while entering the recipient's address. To tackle this issue, the suggestion is to have the beneficiary's wallet generate a signed payment request instead of just an address. By doing so, the sender would not be able to generate a payment request for the merchant as they lack the merchant's key. Additionally, another proposed solution involves sending the transaction to the beneficiary through a private channel instead of broadcasting it. In this case, the beneficiary would refrain from broadcasting the transaction if they do not receive the expected payment or if the transaction was not properly constructed according to their preferences. This method also caters to deniable payments. The second concern raised is the desire for a 2-step confirmation system when engaging with unfamiliar individuals. To address this concern, the suggestion is to utilize an escrow system with or without an arbitrator. Without an arbitrator, the resolution of the transaction typically depends on time or revealing a known hash value. With an arbitrator, a secure model can be implemented where a compromised arbitrator is only able to revert transactions and not steal funds. Importantly, none of the proposed methods require any changes to the Bitcoin network or blockchain. Wallet developers have the ability to implement these approaches independently without needing to negotiate with Bitcoin developers.While Bitcoin addresses already have a checksum to minimize input errors, there is still a risk of malware replacing the intended address with one controlled by the malware author. Therefore, verifying the correct address remains a concern. The mention of "bitcoin multisig" and "bitcoin escrow" in a Google search highlights support for these concepts within the core Bitcoin protocol. The individual expressing their concerns suggests that for deals involving less than 100 Bitcoin, it is simpler to use a trusted single-party escrow rather than dealing with the complexities of "2 of 3 multisig". In conversations with non-Bitcoin users, two primary concerns often arise. Firstly, there is a fear of losing Bitcoin if an incorrect address is entered. Secondly, there is a desire for a two-step confirmation system when engaging with unknown parties. The proposed solution involves implementing a two-step system that acts as an escrow, allowing both parties to provide final approval within a specified timeframe. This system could potentially alleviate anxiety surrounding Bitcoin transactions. The author acknowledges that the current forum may not be the ideal platform for discussing these ideas but expresses gratitude for the reader's time. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_BIP-117-Feedback.xml b/static/bitcoin-dev/Jan_2018/combined_BIP-117-Feedback.xml index 195073312f..418c731fbd 100644 --- a/static/bitcoin-dev/Jan_2018/combined_BIP-117-Feedback.xml +++ b/static/bitcoin-dev/Jan_2018/combined_BIP-117-Feedback.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - BIP 117 Feedback - 2023-08-01T22:27:01.437678+00:00 - - Johnson Lau 2018-03-05 15:28:20+00:00 - - - Russell O'Connor 2018-01-16 08:39:28+00:00 - - - Luke Dashjr 2018-01-16 04:15:54+00:00 - - - Gregory Maxwell 2018-01-16 03:27:26+00:00 - - - Rusty Russell 2018-01-16 01:06:14+00:00 - - - Russell O'Connor 2018-01-12 10:48:33+00:00 - - - Mark Friedenbach 2018-01-09 22:57:34+00:00 - - - Pieter Wuille 2018-01-09 14:21:08+00:00 - - - Mark Friedenbach 2018-01-09 12:40:30+00:00 - - - Rusty Russell 2018-01-09 11:22:18+00:00 - + 2025-09-26T15:43:41.030163+00:00 + python-feedgen + + + [bitcoin-dev] BIP 117 Feedback Rusty Russell + 2018-01-09T11:22:00.000Z + + + Mark Friedenbach + 2018-01-09T12:40:00.000Z + + + Pieter Wuille + 2018-01-09T14:21:00.000Z + + + Mark Friedenbach + 2018-01-09T22:57:00.000Z + + + Russell O'Connor + 2018-01-12T10:48:00.000Z + + + Rusty Russell + 2018-01-16T01:06:00.000Z + + + Gregory Maxwell + 2018-01-16T03:27:00.000Z + + + Luke Dashjr + 2018-01-16T04:15:00.000Z + + + Russell O'Connor + 2018-01-16T08:39:00.000Z + + + Johnson Lau + 2018-03-05T15:28:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP 117 Feedback - 2023-08-01T22:27:01.437678+00:00 + 2025-09-26T15:43:41.031399+00:00 - Rusty Russell has raised concerns about the flexibility of BIP 117 in a post on the bitcoin-dev mailing list. He believes that BIP 117 is trying to do too much and finds the use of altstack awkward. Instead, he suggests implementing a simpler form of tail recursion by having a single blob. He also expresses concern over the dropping of SIGOP and opcode limits in BIP 117 and calls for more justification, including measurements and bounds on execution times.Rusty proposes restoring statically analyzability by limiting rules to version 3 segwit transactions, counting only the top element of the stack, and requiring the popped-off blob for tail recursion to be identical to that top element of the stack.Regarding the use of altstack, Rusty suggests leaving it untouched in v0 P2WSH. He points out that if anyone is already using altstack, BIP 117 could potentially confiscate those UTXOs as the altstack would likely be non-executable. Even in v1 witness, Rusty believes altstack should remain temporary data storage.Rusty also highlights the security vulnerability in BIP 117, where concatenated scripts can be skipped by using an invalid push operation in the scriptSig, making the whole concatenated script a simple push.Luke Dashjr also contributes to the discussion, shifting the conversation to the added requirement that some pubkeys in a multisig must be parsable. He mentions that people have reported difficulty retrieving their funds due to this change, but clarifies that it is only a change to the standardness rules, not a consensus change. He assures that these funds are not permanently lost and can be retrieved with miner help.The discussion on the bitcoin-dev mailing list further explores the situation for BIP 117 and BIP-141. It is noted that BIP-141 requires a script to result in exactly a single TRUE on the stack, while P2SH scripts have not followed this rule. However, this does not affect the altstack, which is a separate stack. The principle of "standard transactions must still work" was violated with low-S, but it was considered trivial due to specific mitigating factors.The viability of BIP 117 as a soft fork for Script is also discussed, comparing it to past soft forks. BIP 117 introduces new rules that could render existing commitments unspendable and remove ownership of funds. It is argued that new consensus features should follow the UNIX philosophy of being small, modular, and incremental changes to enable unrestricted innovation.Mark Friedenbach discusses the use of the alt stack as a hack for segwit script version 0 and proposes future improvements to switch to a witness script version and a new segwit output version that supports native MAST. The author argues against removing SIGOP and opcode limits entirely and suggests limiting per-script execution proportional to the script size.Overall, there are concerns about the flexibility, security, and potential loss of funds associated with BIP 117. Various suggestions and proposals are made to address these concerns and improve the implementation of Segregated Witness in Bitcoin. 2018-03-05T15:28:20+00:00 + Rusty Russell has raised concerns about the flexibility of BIP 117 in a post on the bitcoin-dev mailing list. He believes that BIP 117 is trying to do too much and finds the use of altstack awkward. Instead, he suggests implementing a simpler form of tail recursion by having a single blob. He also expresses concern over the dropping of SIGOP and opcode limits in BIP 117 and calls for more justification, including measurements and bounds on execution times.Rusty proposes restoring statically analyzability by limiting rules to version 3 segwit transactions, counting only the top element of the stack, and requiring the popped-off blob for tail recursion to be identical to that top element of the stack.Regarding the use of altstack, Rusty suggests leaving it untouched in v0 P2WSH. He points out that if anyone is already using altstack, BIP 117 could potentially confiscate those UTXOs as the altstack would likely be non-executable. Even in v1 witness, Rusty believes altstack should remain temporary data storage.Rusty also highlights the security vulnerability in BIP 117, where concatenated scripts can be skipped by using an invalid push operation in the scriptSig, making the whole concatenated script a simple push.Luke Dashjr also contributes to the discussion, shifting the conversation to the added requirement that some pubkeys in a multisig must be parsable. He mentions that people have reported difficulty retrieving their funds due to this change, but clarifies that it is only a change to the standardness rules, not a consensus change. He assures that these funds are not permanently lost and can be retrieved with miner help.The discussion on the bitcoin-dev mailing list further explores the situation for BIP 117 and BIP-141. It is noted that BIP-141 requires a script to result in exactly a single TRUE on the stack, while P2SH scripts have not followed this rule. However, this does not affect the altstack, which is a separate stack. The principle of "standard transactions must still work" was violated with low-S, but it was considered trivial due to specific mitigating factors.The viability of BIP 117 as a soft fork for Script is also discussed, comparing it to past soft forks. BIP 117 introduces new rules that could render existing commitments unspendable and remove ownership of funds. It is argued that new consensus features should follow the UNIX philosophy of being small, modular, and incremental changes to enable unrestricted innovation.Mark Friedenbach discusses the use of the alt stack as a hack for segwit script version 0 and proposes future improvements to switch to a witness script version and a new segwit output version that supports native MAST. The author argues against removing SIGOP and opcode limits entirely and suggests limiting per-script execution proportional to the script size.Overall, there are concerns about the flexibility, security, and potential loss of funds associated with BIP 117. Various suggestions and proposals are made to address these concerns and improve the implementation of Segregated Witness in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_BIP-39-Add-language-identifier-strings-for-wordlists.xml b/static/bitcoin-dev/Jan_2018/combined_BIP-39-Add-language-identifier-strings-for-wordlists.xml index ab5d6035b2..538ff5b188 100644 --- a/static/bitcoin-dev/Jan_2018/combined_BIP-39-Add-language-identifier-strings-for-wordlists.xml +++ b/static/bitcoin-dev/Jan_2018/combined_BIP-39-Add-language-identifier-strings-for-wordlists.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - BIP 39: Add language identifier strings for wordlists - 2023-08-01T22:24:59.011596+00:00 - - Aymeric Vitte 2018-01-08 16:02:02+00:00 - - - Greg Sanders 2018-01-08 15:32:58+00:00 - - - AJ West 2018-01-08 15:26:38+00:00 - - - Matias Alejo Garcia 2018-01-08 15:23:53+00:00 - - - Greg Sanders 2018-01-08 14:54:38+00:00 - - - Matias Alejo Garcia 2018-01-08 14:52:20+00:00 - - - Greg Sanders 2018-01-08 14:34:39+00:00 - - - nullius 2018-01-08 11:13:28+00:00 - - - 木ノ下じょな 2018-01-08 07:35:52+00:00 - - - Pavol Rusnak 2018-01-07 15:16:47+00:00 - - - Aymeric Vitte 2018-01-06 19:46:43+00:00 - - - Aymeric Vitte 2018-01-06 17:40:40+00:00 - - - Aymeric Vitte 2018-01-05 19:56:19+00:00 - - - nullius 2018-01-05 18:08:50+00:00 - - - Aymeric Vitte 2018-01-05 18:08:29+00:00 - - - Sjors Provoost 2018-01-05 17:13:23+00:00 - - - Sjors Provoost 2018-01-05 16:04:10+00:00 - - - nullius 2018-01-05 13:58:37+00:00 - + 2025-09-26T15:43:53.710368+00:00 + python-feedgen + + + [bitcoin-dev] BIP 39: Add language identifier strings for wordlists nullius + 2018-01-05T13:58:00.000Z + + + Sjors Provoost + 2018-01-05T16:04:00.000Z + + + Sjors Provoost + 2018-01-05T17:13:00.000Z + + + Aymeric Vitte + 2018-01-05T18:08:00.000Z + + + nullius + 2018-01-05T18:08:00.000Z + + + Aymeric Vitte + 2018-01-05T19:56:00.000Z + + + Aymeric Vitte + 2018-01-06T17:40:00.000Z + + + Aymeric Vitte + 2018-01-06T19:46:00.000Z + + + Pavol Rusnak + 2018-01-07T15:16:00.000Z + + + 木ノ下じょな + 2018-01-08T07:35:00.000Z + + + nullius + 2018-01-08T11:13:00.000Z + + + Greg Sanders + 2018-01-08T14:34:00.000Z + + + Matias Alejo Garcia + 2018-01-08T14:52:00.000Z + + + Greg Sanders + 2018-01-08T14:54:00.000Z + + + Matias Alejo Garcia + 2018-01-08T15:23:00.000Z + + + AJ West + 2018-01-08T15:26:00.000Z + + + Greg Sanders + 2018-01-08T15:32:00.000Z + + + Aymeric Vitte + 2018-01-08T16:02:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - BIP 39: Add language identifier strings for wordlists - 2023-08-01T22:24:59.012591+00:00 + 2025-09-26T15:43:53.712345+00:00 - The discussion revolves around the use of BIP39 and subsequent BIPs, which are often used incorrectly and can mislead people. Some wallets have limitations when it comes to validating English words or typing characters. There is a proposal to enhance the BIP39 wordlist set by specifying canonical native language strings to identify each wordlist, as well as short ASCII language codes. This would facilitate language identification in user interface options or menus and promote interface consistency between implementations.Sjors Provoost disagrees with the inclusion of language-specific word lists in the current BIP39 standard due to concerns about supporting multiple languages and vendor lock-in. He suggests creating a new standard where words are mapped to integers rather than literal strings, with a mapping from original language words to matching English words. This would allow users to enter a mnemonic into a hardware wallet that only supports English.There are also discussions about the need for a better English dictionary in the replacement for BIP39, with suggestions such as all words being 4-8 characters and having unique 4-character prefixes. Wallets would need to distinguish between the old and new standards, and un-upgraded BIP39 wallets should consider all new mnemonics invalid.Additionally, there is a suggestion to add canonical native language strings to identify each wordlist set in the BIP39 specification. This would help with language identification in user interfaces and promote consistency between implementations. The author also notes the absence of a Dutch word list in the BIP repository and expresses interest in adding more word lists.The conversation highlighted the limited support for non-English languages in current wallets, which can lead to vendor lock-in and potential loss of funds if a non-English wallet becomes unavailable. It was suggested that wallets should be able to distinguish between the old and new standard, considering all new mnemonics invalid for un-upgraded BIP39 wallets.In conclusion, the discussion emphasized the importance of considering the needs of non-English speaking users when designing standards for cryptocurrency wallets. The issues raised included the difficulties faced by Japanese users with English words, the potential risks of using mnemonics, and the need for multi-language support. There were various proposals put forward, including mapping words to integers, enhancing wordlists with additional information, and improving language identification strings. Overall, the conversation called for a more inclusive and accessible approach to securing coins.The context also provides links related to passwords, anti-spying, private torrents, blocklists, and different wallets, including options for simplifying Bitcoin transactions and wallets, as well as tools for encrypting and protecting data. 2018-01-08T16:02:02+00:00 + The discussion revolves around the use of BIP39 and subsequent BIPs, which are often used incorrectly and can mislead people. Some wallets have limitations when it comes to validating English words or typing characters. There is a proposal to enhance the BIP39 wordlist set by specifying canonical native language strings to identify each wordlist, as well as short ASCII language codes. This would facilitate language identification in user interface options or menus and promote interface consistency between implementations.Sjors Provoost disagrees with the inclusion of language-specific word lists in the current BIP39 standard due to concerns about supporting multiple languages and vendor lock-in. He suggests creating a new standard where words are mapped to integers rather than literal strings, with a mapping from original language words to matching English words. This would allow users to enter a mnemonic into a hardware wallet that only supports English.There are also discussions about the need for a better English dictionary in the replacement for BIP39, with suggestions such as all words being 4-8 characters and having unique 4-character prefixes. Wallets would need to distinguish between the old and new standards, and un-upgraded BIP39 wallets should consider all new mnemonics invalid.Additionally, there is a suggestion to add canonical native language strings to identify each wordlist set in the BIP39 specification. This would help with language identification in user interfaces and promote consistency between implementations. The author also notes the absence of a Dutch word list in the BIP repository and expresses interest in adding more word lists.The conversation highlighted the limited support for non-English languages in current wallets, which can lead to vendor lock-in and potential loss of funds if a non-English wallet becomes unavailable. It was suggested that wallets should be able to distinguish between the old and new standard, considering all new mnemonics invalid for un-upgraded BIP39 wallets.In conclusion, the discussion emphasized the importance of considering the needs of non-English speaking users when designing standards for cryptocurrency wallets. The issues raised included the difficulties faced by Japanese users with English words, the potential risks of using mnemonics, and the need for multi-language support. There were various proposals put forward, including mapping words to integers, enhancing wordlists with additional information, and improving language identification strings. Overall, the conversation called for a more inclusive and accessible approach to securing coins.The context also provides links related to passwords, anti-spying, private torrents, blocklists, and different wallets, including options for simplifying Bitcoin transactions and wallets, as well as tools for encrypting and protecting data. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_BIP-Proposal-Revised-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml b/static/bitcoin-dev/Jan_2018/combined_BIP-Proposal-Revised-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml index 38d03e0492..f47d3d0dfe 100644 --- a/static/bitcoin-dev/Jan_2018/combined_BIP-Proposal-Revised-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml +++ b/static/bitcoin-dev/Jan_2018/combined_BIP-Proposal-Revised-UTPFOTIB-Use-Transaction-Priority-For-Ordering-Transactions-In-Blocks.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks - 2023-08-01T22:17:41.455084+00:00 - - Damian Williamson 2018-01-21 05:49:25+00:00 - - - Alan Evans 2018-01-20 14:46:41+00:00 - - - Damian Williamson 2018-01-20 12:04:20+00:00 - - - Damian Williamson 2018-01-19 23:25:43+00:00 - - - Damian Williamson 2018-01-04 09:01:10+00:00 - - - Damian Williamson 2018-01-01 11:04:57+00:00 - - - Damian Williamson 2017-12-27 12:29:41+00:00 - - - ZmnSCPxj 2017-12-27 03:55:43+00:00 - - - Damian Williamson 2017-12-26 05:14:14+00:00 - - - Spartacus Rex 2017-12-24 09:02:09+00:00 - - - Damian Williamson 2017-12-24 03:44:26+00:00 - - - Damian Williamson 2017-12-23 01:24:28+00:00 - - - Spartacus Rex 2017-12-22 18:07:49+00:00 - - - Damian Williamson 2017-12-22 06:22:40+00:00 - - - Damian Williamson 2017-12-19 07:51:39+00:00 - - - Damian Williamson 2017-12-19 07:48:37+00:00 - - - Chris Riley 2017-12-18 12:09:34+00:00 - - - Damian Williamson 2017-12-17 04:14:39+00:00 - - - Damian Williamson 2017-12-15 20:59:51+00:00 - - - Rhavar 2017-12-15 16:38:46+00:00 - - - Damian Williamson 2017-12-15 09:42:42+00:00 - - - Damian Williamson 2017-12-07 21:01:43+00:00 - + 2025-09-26T15:43:51.590210+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks Damian Williamson + 2017-12-07T21:01:00.000Z + + + Damian Williamson + 2017-12-15T09:42:00.000Z + + + Rhavar + 2017-12-15T16:38:00.000Z + + + Damian Williamson + 2017-12-15T20:59:00.000Z + + + Damian Williamson + 2017-12-17T04:14:00.000Z + + + Chris Riley + 2017-12-18T12:09:00.000Z + + + Damian Williamson + 2017-12-19T07:48:00.000Z + + + Damian Williamson + 2017-12-19T07:51:00.000Z + + + Damian Williamson + 2017-12-22T06:22:00.000Z + + + Spartacus Rex + 2017-12-22T18:07:00.000Z + + + Damian Williamson + 2017-12-23T01:24:00.000Z + + + Damian Williamson + 2017-12-24T03:44:00.000Z + + + Spartacus Rex + 2017-12-24T09:02:00.000Z + + + Damian Williamson + 2017-12-26T05:14:00.000Z + + + ZmnSCPxj + 2017-12-27T03:55:00.000Z + + + Damian Williamson + 2017-12-27T12:29:00.000Z + + + [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks Damian Williamson + 2018-01-01T11:04:00.000Z + + + Damian Williamson + 2018-01-04T09:01:00.000Z + + + Damian Williamson + 2018-01-19T23:25:00.000Z + + + Damian Williamson + 2018-01-20T12:04:00.000Z + + + Alan Evans + 2018-01-20T14:46:00.000Z + + + Damian Williamson + 2018-01-21T05:49:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks - 2023-08-01T22:17:41.456084+00:00 + 2025-09-26T15:43:51.593190+00:00 - Damian Williamson has proposed a Bitcoin Improvement Proposal (BIP) called UTPFOTIB (Use Transaction Priority For Ordering Transactions In Blocks) to address the limitations and inconsistencies with Bitcoin's transaction bandwidth. The proposal aims to improve transaction reliability and scalability, which are crucial for the success and uptake of Bitcoin as a payment system.Currently, transactions with lower fees are being overshadowed by those with higher fees, leading to a large number of valid transactions never confirming. This unreliable payment system undermines consumer confidence and threatens the value of Bitcoin. Williamson's proposal suggests assigning each transaction an individual priority based on the fee paid and time waiting in the transaction pool. This priority would determine the likelihood of inclusion in a block.By prioritizing transactions based on these factors rather than using an auction model, the proposal aims to provide full transaction confirmation for every valid transaction. This approach also maximizes transaction reliability and increases the potential for consumer and business uptake.To implement this proposal, the target block size would be determined based on the number of transactions in the pool. The priority of each transaction would influence its probability of being included in the block. The revised BIP aims to maximize transaction reliability, scalability, and total fees paid per block without compromising reliability.However, there are some drawbacks to consider. Initially, this approach may lower total transaction fees per block. Additionally, programming is required to implement the proposal, and a mathematician would need to verify if blocks conform to the proposed method.In conclusion, Damian Williamson's proposed BIP seeks to address the current limitations of Bitcoin's transaction bandwidth. By utilizing transaction priority to order transactions in blocks, the proposal aims to enhance transaction reliability, scalability, and overall fees paid per block. While there are potential downsides such as initial reduction in total transaction fees and the need for programming, Williamson emphasizes the importance of validating full transaction reliability and enabling scalability of block sizes. Collaboration and feedback from the Bitcoin developer community are encouraged to further refine and implement the proposal. 2018-01-21T05:49:25+00:00 + Damian Williamson has proposed a Bitcoin Improvement Proposal (BIP) called UTPFOTIB (Use Transaction Priority For Ordering Transactions In Blocks) to address the limitations and inconsistencies with Bitcoin's transaction bandwidth. The proposal aims to improve transaction reliability and scalability, which are crucial for the success and uptake of Bitcoin as a payment system.Currently, transactions with lower fees are being overshadowed by those with higher fees, leading to a large number of valid transactions never confirming. This unreliable payment system undermines consumer confidence and threatens the value of Bitcoin. Williamson's proposal suggests assigning each transaction an individual priority based on the fee paid and time waiting in the transaction pool. This priority would determine the likelihood of inclusion in a block.By prioritizing transactions based on these factors rather than using an auction model, the proposal aims to provide full transaction confirmation for every valid transaction. This approach also maximizes transaction reliability and increases the potential for consumer and business uptake.To implement this proposal, the target block size would be determined based on the number of transactions in the pool. The priority of each transaction would influence its probability of being included in the block. The revised BIP aims to maximize transaction reliability, scalability, and total fees paid per block without compromising reliability.However, there are some drawbacks to consider. Initially, this approach may lower total transaction fees per block. Additionally, programming is required to implement the proposal, and a mathematician would need to verify if blocks conform to the proposed method.In conclusion, Damian Williamson's proposed BIP seeks to address the current limitations of Bitcoin's transaction bandwidth. By utilizing transaction priority to order transactions in blocks, the proposal aims to enhance transaction reliability, scalability, and overall fees paid per block. While there are potential downsides such as initial reduction in total transaction fees and the need for programming, Williamson emphasizes the importance of validating full transaction reliability and enabling scalability of block sizes. Collaboration and feedback from the Bitcoin developer community are encouraged to further refine and implement the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Bech32-and-P2SH-.xml b/static/bitcoin-dev/Jan_2018/combined_Bech32-and-P2SH-.xml index 2cd0d03030..242d242c50 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Bech32-and-P2SH-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Bech32-and-P2SH-.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Bech32 and P2SH² - 2023-08-01T22:24:11.257718+00:00 - - Adam Ritter 2018-01-06 10:05:11+00:00 - - - Gregory Maxwell 2018-01-06 00:44:20+00:00 - - - Luke Dashjr 2018-01-06 00:26:51+00:00 - - - Luke Dashjr 2018-01-04 14:23:05+00:00 - + 2025-09-26T15:43:36.823939+00:00 + python-feedgen + + + [bitcoin-dev] Bech32 and P2SH² Luke Dashjr + 2018-01-04T14:23:00.000Z + + + Luke Dashjr + 2018-01-06T00:26:00.000Z + + + Gregory Maxwell + 2018-01-06T00:44:00.000Z + + + Adam Ritter + 2018-01-06T10:05:00.000Z + + - python-feedgen + 2 Combined summary - Bech32 and P2SH² - 2023-08-01T22:24:11.257718+00:00 + 2025-09-26T15:43:36.824616+00:00 - In a discussion thread on the Bitcoin development mailing list, a user raised a question about why the BIP39 mnemonic format is not used for addresses. They pointed out that it is more difficult to copy random letters and numbers compared to simple words, which can lead to mistakes when copying addresses and private keys by hand. The user suggested that using the BIP39 seeds, which have a lower chance of errors, would be a better option. Another user responded by explaining that while the Bech32 proposal involved a lot of math, there was not as much user experience testing. Another user in the thread introduced the idea of P2SH², which involves including the single SHA256 hash of the public key or script in the address instead of RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). This would allow for relaying the "middle-hash" as a way to prove that the final hash is indeed a hash itself and not embedded data spam. However, another user mentioned that the Bech32 proposal had already been rushed to market without much public review, so adding more address diversity at this time may not be beneficial for the ecosystem. Instead, they suggested considering an address-next proposal with features like coded expiration times and the ability to have amounts under checksum.Bitcoin Core developer Luke Dashjr recently sent an email to the bitcoin-dev mailing list, bringing up the previously discussed P2SH² improvements and questioning why they were not included in Bech32. P2SH² involves including the single SHA256 hash of the public key or script in the address. Luke Dashjr clarified that P2SH² was not a serious proposal but rather a thought experiment. He believed that it did not offer much value for Bitcoin today, especially considering the cost of output space and non-negligible fees. Additionally, Bech32 was rushed to market without substantial public review.Luke Dashjr suggested that instead of adding more address diversity at this time, it would be better to work on an address-next proposal with a specific timeframe in the future. He emphasized the importance of not deploying this proposal loudly. While layered hashing is considered a minor feature, other features like coded expiration times and the ability to have amounts under checksum might be more worthy of consideration.In light of these discussions, Luke Dashjr proposed adding "P2SH² improvements" to the Bech32 format. He shared an initial draft of the proposal on Github. The idea is to include the single SHA256 hash of the public key or script in the address instead of RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). This would enable relaying the middle-hash as a way to prove that the final hash is indeed a hash itself and not embedded data spam. Since the deployment of Bech32 is not yet widespread, Luke Dashjr believes it may be worth revising it to incorporate this improvement. Bech32 is seen as a missed opportunity to include these improvements, considering that most users will likely upgrade to it in the future. 2018-01-06T10:05:11+00:00 + In a discussion thread on the Bitcoin development mailing list, a user raised a question about why the BIP39 mnemonic format is not used for addresses. They pointed out that it is more difficult to copy random letters and numbers compared to simple words, which can lead to mistakes when copying addresses and private keys by hand. The user suggested that using the BIP39 seeds, which have a lower chance of errors, would be a better option. Another user responded by explaining that while the Bech32 proposal involved a lot of math, there was not as much user experience testing. Another user in the thread introduced the idea of P2SH², which involves including the single SHA256 hash of the public key or script in the address instead of RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). This would allow for relaying the "middle-hash" as a way to prove that the final hash is indeed a hash itself and not embedded data spam. However, another user mentioned that the Bech32 proposal had already been rushed to market without much public review, so adding more address diversity at this time may not be beneficial for the ecosystem. Instead, they suggested considering an address-next proposal with features like coded expiration times and the ability to have amounts under checksum.Bitcoin Core developer Luke Dashjr recently sent an email to the bitcoin-dev mailing list, bringing up the previously discussed P2SH² improvements and questioning why they were not included in Bech32. P2SH² involves including the single SHA256 hash of the public key or script in the address. Luke Dashjr clarified that P2SH² was not a serious proposal but rather a thought experiment. He believed that it did not offer much value for Bitcoin today, especially considering the cost of output space and non-negligible fees. Additionally, Bech32 was rushed to market without substantial public review.Luke Dashjr suggested that instead of adding more address diversity at this time, it would be better to work on an address-next proposal with a specific timeframe in the future. He emphasized the importance of not deploying this proposal loudly. While layered hashing is considered a minor feature, other features like coded expiration times and the ability to have amounts under checksum might be more worthy of consideration.In light of these discussions, Luke Dashjr proposed adding "P2SH² improvements" to the Bech32 format. He shared an initial draft of the proposal on Github. The idea is to include the single SHA256 hash of the public key or script in the address instead of RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). This would enable relaying the middle-hash as a way to prove that the final hash is indeed a hash itself and not embedded data spam. Since the deployment of Bech32 is not yet widespread, Luke Dashjr believes it may be worth revising it to incorporate this improvement. Bech32 is seen as a missed opportunity to include these improvements, considering that most users will likely upgrade to it in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal-Chaofan-Li-.xml b/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal-Chaofan-Li-.xml index aa942437bc..ad4b194c70 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal-Chaofan-Li-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal-Chaofan-Li-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Blockchain Voluntary Fork (Split) Proposal (Chaofan Li) - 2023-08-01T22:31:07.089707+00:00 + 2025-09-26T15:43:45.231497+00:00 + python-feedgen Chaofan Li 2018-01-30 06:20:35+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Blockchain Voluntary Fork (Split) Proposal (Chaofan Li) - 2023-08-01T22:31:07.089707+00:00 + 2025-09-26T15:43:45.231661+00:00 - The conversation between ZmnSCPxj and Chaofan centers around the concept of fungibility in paper money and Bitcoin. They discuss how fungibility allows for the exchange of paper money with different denominations, and question whether the same principle applies to bitcoins generated from different blocks. They also ponder if bitcoins from the early blocks mined by Satoshi would have higher value if released. The idea of fungibility having a measurable value is suggested.Fungibility is explained as the principle that ensures indistinguishability in paper money, where a $10 bill is equivalent to ten $1 coins. This principle also applies to cryptocurrencies like bitcoin, thanks to mechanisms such as sidechains, SPV proof-of-work, and drivechain proof-of-voting. However, it is emphasized that proposals need to differentiate themselves from previous ones to avoid confusion.The possibility of eliminating human perception differences in money is discussed. The suggestion is made that wallets and exchanges should only display the total amount of bitcoin, rather than separating them into different types. It is explained that one valid address is automatically valid on both chains, allowing money to be sent through either chain as long as the private key is available. This means there would be no difference in the number of merchants, and exchange costs would be trivial.The conflation of mining difficulty with profitability is highlighted as erroneous. It is argued that profitability is controlled by competition, not difficulty. While the idea of equilibrium is mentioned, it is stated that even a small change in the number of merchants or human perception of money can lead to the elimination of one currency in favor of the other. The exchange cost between two currencies is seen as a disadvantage, making one currency inherently better than two.The discussion on the bitcoin-dev mailing list revolves around the distribution of miners between two similar chains. The argument that miners will be equally distributed based on mining difficulty is criticized. It is explained that mining difficulty only controls block period, not miner return on capital. Profitability is determined by competition, and miners seek the same level of profitability regardless of difficulty. The assumption that both chains have the same initial or final value is deemed unrealistic, as even the smallest change in number of merchants or human perception can lead to one chain being slightly better and gaining dominance.To achieve equilibrium, it is suggested that two chains must have comparable chain generation rates, length, and difficulty. If these conditions are not met, miners will be attracted more easily to the chain that is easier to mine, resulting in a higher chain generation rate. Eventually, equilibrium will be reached.The value of block space in Bitcoin is discussed, with emphasis on miners investing capital based on anticipation of future returns. The relationship between mining power and cryptocurrency value is debated. While one member asserts that the chain with the most mining power will have more value, another member disagrees and suggests that tokens with higher value attract more mining hash rate. This highlights the complex interplay between mining power and cryptocurrency value, which depends on various factors.The conversation also touches upon the question of how to handle mining on each chain. It is mentioned that the chain with more mining power will have greater value. Additionally, the speed and value of a chain will depend on its length, with one chain likely to be longer and faster. The proposal being discussed appears to involve a sidechain with the same protocol. 2018-01-30T06:20:35+00:00 + The conversation between ZmnSCPxj and Chaofan centers around the concept of fungibility in paper money and Bitcoin. They discuss how fungibility allows for the exchange of paper money with different denominations, and question whether the same principle applies to bitcoins generated from different blocks. They also ponder if bitcoins from the early blocks mined by Satoshi would have higher value if released. The idea of fungibility having a measurable value is suggested.Fungibility is explained as the principle that ensures indistinguishability in paper money, where a $10 bill is equivalent to ten $1 coins. This principle also applies to cryptocurrencies like bitcoin, thanks to mechanisms such as sidechains, SPV proof-of-work, and drivechain proof-of-voting. However, it is emphasized that proposals need to differentiate themselves from previous ones to avoid confusion.The possibility of eliminating human perception differences in money is discussed. The suggestion is made that wallets and exchanges should only display the total amount of bitcoin, rather than separating them into different types. It is explained that one valid address is automatically valid on both chains, allowing money to be sent through either chain as long as the private key is available. This means there would be no difference in the number of merchants, and exchange costs would be trivial.The conflation of mining difficulty with profitability is highlighted as erroneous. It is argued that profitability is controlled by competition, not difficulty. While the idea of equilibrium is mentioned, it is stated that even a small change in the number of merchants or human perception of money can lead to the elimination of one currency in favor of the other. The exchange cost between two currencies is seen as a disadvantage, making one currency inherently better than two.The discussion on the bitcoin-dev mailing list revolves around the distribution of miners between two similar chains. The argument that miners will be equally distributed based on mining difficulty is criticized. It is explained that mining difficulty only controls block period, not miner return on capital. Profitability is determined by competition, and miners seek the same level of profitability regardless of difficulty. The assumption that both chains have the same initial or final value is deemed unrealistic, as even the smallest change in number of merchants or human perception can lead to one chain being slightly better and gaining dominance.To achieve equilibrium, it is suggested that two chains must have comparable chain generation rates, length, and difficulty. If these conditions are not met, miners will be attracted more easily to the chain that is easier to mine, resulting in a higher chain generation rate. Eventually, equilibrium will be reached.The value of block space in Bitcoin is discussed, with emphasis on miners investing capital based on anticipation of future returns. The relationship between mining power and cryptocurrency value is debated. While one member asserts that the chain with the most mining power will have more value, another member disagrees and suggests that tokens with higher value attract more mining hash rate. This highlights the complex interplay between mining power and cryptocurrency value, which depends on various factors.The conversation also touches upon the question of how to handle mining on each chain. It is mentioned that the chain with more mining power will have greater value. Additionally, the speed and value of a chain will depend on its length, with one chain likely to be longer and faster. The proposal being discussed appears to involve a sidechain with the same protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal.xml b/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal.xml index ca40a5df49..995076d890 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Blockchain Voluntary Fork (Split) Proposal - 2023-08-01T22:29:15.104665+00:00 - - Eric Voskuil 2018-01-22 22:43:22+00:00 - - - Erik Aronesty 2018-01-22 20:40:58+00:00 - - - Chaofan Li 2018-01-22 18:46:06+00:00 - - - ZmnSCPxj 2018-01-22 11:12:51+00:00 - - - Chaofan Li 2018-01-17 07:55:54+00:00 - + 2025-09-26T15:43:34.734328+00:00 + python-feedgen + + + [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal Chaofan Li + 2018-01-17T07:55:00.000Z + + + ZmnSCPxj + 2018-01-22T11:12:00.000Z + + + Chaofan Li + 2018-01-22T18:46:00.000Z + + + Erik Aronesty + 2018-01-22T20:40:00.000Z + + + Eric Voskuil + 2018-01-22T22:43:00.000Z + + - python-feedgen + 2 Combined summary - Blockchain Voluntary Fork (Split) Proposal - 2023-08-01T22:29:15.104665+00:00 + 2025-09-26T15:43:34.735049+00:00 - The proposal to solve the scalability issue of blockchain involves a voluntary split, where the blockchain is divided into two or more blockchains. Each blockchain has its own coins that cannot be sent to the other blockchain. This solution aims to double the capacity of the original blockchain. When sending coins, the wallet randomly selects one blockchain and sends through only that one.This method is inspired by stock splits, where the price halves but the market capitalization remains the same. It ensures that there is no dilution of anyone's bitcoin assets. The total coin supply should not change, as increasing the supply would dilute the value of each coin. With the voluntary split of bitcoin, this dilution is avoided.There are discussions on what enforces the equal worth of Bitcoin A and Bitcoin B. Chaofan Li argues that if the algorithms of the two chains are the same, except for some identifiers, they should have the same value. The market will adjust their values accordingly. Additionally, the proposal is backward compatible with old version transactions and creates a blocktree as new blocks are added, providing even more capacity.In an email exchange, ZmnSCPxj raises questions about the worth of Bitcoin A and Bitcoin B and whether they can diverge in price. Li believes that voluntary split of bitcoin will prevent the dilution of anyone's bitcoin assets. The proposed solution is seen more as a financial trick than a technical solution to address scalability issues. While bitcoin emphasizes maintaining the total coin supply, this solution prevents dilution of each unit's value, similar to the problem with inflation of fiat money.Overall, the voluntary split of bitcoin presents a potential solution to the scalability issue of blockchain by creating multiple blockchains with their own coins. It aims to double the capacity of the original blockchain without diluting the value of bitcoin assets. The proposal is inspired by stock splits and is considered backward compatible with old version transactions. Discussions continue regarding the worth and potential divergence of Bitcoin A and Bitcoin B. 2018-01-22T22:43:22+00:00 + The proposal to solve the scalability issue of blockchain involves a voluntary split, where the blockchain is divided into two or more blockchains. Each blockchain has its own coins that cannot be sent to the other blockchain. This solution aims to double the capacity of the original blockchain. When sending coins, the wallet randomly selects one blockchain and sends through only that one.This method is inspired by stock splits, where the price halves but the market capitalization remains the same. It ensures that there is no dilution of anyone's bitcoin assets. The total coin supply should not change, as increasing the supply would dilute the value of each coin. With the voluntary split of bitcoin, this dilution is avoided.There are discussions on what enforces the equal worth of Bitcoin A and Bitcoin B. Chaofan Li argues that if the algorithms of the two chains are the same, except for some identifiers, they should have the same value. The market will adjust their values accordingly. Additionally, the proposal is backward compatible with old version transactions and creates a blocktree as new blocks are added, providing even more capacity.In an email exchange, ZmnSCPxj raises questions about the worth of Bitcoin A and Bitcoin B and whether they can diverge in price. Li believes that voluntary split of bitcoin will prevent the dilution of anyone's bitcoin assets. The proposed solution is seen more as a financial trick than a technical solution to address scalability issues. While bitcoin emphasizes maintaining the total coin supply, this solution prevents dilution of each unit's value, similar to the problem with inflation of fiat money.Overall, the voluntary split of bitcoin presents a potential solution to the scalability issue of blockchain by creating multiple blockchains with their own coins. It aims to double the capacity of the original blockchain without diluting the value of bitcoin assets. The proposal is inspired by stock splits and is considered backward compatible with old version transactions. Discussions continue regarding the worth and potential divergence of Bitcoin A and Bitcoin B. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Decoupling-BIP70-Payment-Protocol-from-Wallets.xml b/static/bitcoin-dev/Jan_2018/combined_Decoupling-BIP70-Payment-Protocol-from-Wallets.xml index 8944ec0b2c..6a7aea83db 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Decoupling-BIP70-Payment-Protocol-from-Wallets.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Decoupling-BIP70-Payment-Protocol-from-Wallets.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Decoupling BIP70 Payment Protocol from Wallets - 2023-08-01T22:23:23.951218+00:00 - - Ryan Grant 2018-01-02 11:31:51+00:00 - - - James Hilliard 2018-01-01 18:50:04+00:00 - + 2025-09-26T15:43:05.412934+00:00 + python-feedgen + + + [bitcoin-dev] Decoupling BIP70 Payment Protocol from Wallets James Hilliard + 2018-01-01T18:50:00.000Z + + + Ryan Grant + 2018-01-02T11:31:00.000Z + + - python-feedgen + 2 Combined summary - Decoupling BIP70 Payment Protocol from Wallets - 2023-08-01T22:23:23.951218+00:00 + 2025-09-26T15:43:05.413465+00:00 - James Hilliard has proposed a solution to address the issues with BIP70, a protocol for payment requests. Currently, many wallets do not support BIP70 and have no plans to do so in the near future. BIP70 requires complex PKI dependencies like X.509 and TLS support, which have a history of vulnerabilities. Additionally, sending payments to a BIP70 compatible wallet before sending them to a merchant increases fees and block space usage.To overcome these challenges, Hilliard suggests moving the BIP70 protocol implementation into a browser extension that can communicate with wallets through an IPC (Inter-Process Communication) mechanism. This browser extension would act as a translation layer, converting BIP70 URLs into standard BIP21 URIs for wallets that do not support BIP70 or other custom schemes. The extension would also remove complex and risky dependencies from wallets and shift them to the browser, which already implements full PKI support.Implementing the BIP70 protocol in a browser extension offers several benefits. Firstly, it enables payment support for wallets that only support BIP21/normal addresses, ensuring compatibility with a wider range of wallets. Secondly, it simplifies the use of offline or custom signing schemes with BIP70, making it easier for users to securely sign transactions. Lastly, it eliminates the need for manual and non-user-friendly workarounds when paying a BIP70 invoice with an incompatible wallet.Although some may feel it is premature to consider integrating with the W3C Payments API, choosing the right architecture is crucial given the ongoing development in major browsers. Development can proceed even in browsers that have not yet implemented the API, thanks to an HTML5 JavaScript polyfill. Hilliard believes that this approach does not hinder the workflow of Bitcoin transactions, whether on-chain or using the Lightning Network. It even allows sellers to offer discounts on certain payment methods.In conclusion, the proposal to move the BIP70 protocol implementation into a browser extension offers a solution to the limitations and challenges associated with BIP70. By leveraging the existing capabilities of browsers and simplifying the integration process for wallets, this approach aims to enhance payment support and improve user experience in Bitcoin transactions. 2018-01-02T11:31:51+00:00 + James Hilliard has proposed a solution to address the issues with BIP70, a protocol for payment requests. Currently, many wallets do not support BIP70 and have no plans to do so in the near future. BIP70 requires complex PKI dependencies like X.509 and TLS support, which have a history of vulnerabilities. Additionally, sending payments to a BIP70 compatible wallet before sending them to a merchant increases fees and block space usage.To overcome these challenges, Hilliard suggests moving the BIP70 protocol implementation into a browser extension that can communicate with wallets through an IPC (Inter-Process Communication) mechanism. This browser extension would act as a translation layer, converting BIP70 URLs into standard BIP21 URIs for wallets that do not support BIP70 or other custom schemes. The extension would also remove complex and risky dependencies from wallets and shift them to the browser, which already implements full PKI support.Implementing the BIP70 protocol in a browser extension offers several benefits. Firstly, it enables payment support for wallets that only support BIP21/normal addresses, ensuring compatibility with a wider range of wallets. Secondly, it simplifies the use of offline or custom signing schemes with BIP70, making it easier for users to securely sign transactions. Lastly, it eliminates the need for manual and non-user-friendly workarounds when paying a BIP70 invoice with an incompatible wallet.Although some may feel it is premature to consider integrating with the W3C Payments API, choosing the right architecture is crucial given the ongoing development in major browsers. Development can proceed even in browsers that have not yet implemented the API, thanks to an HTML5 JavaScript polyfill. Hilliard believes that this approach does not hinder the workflow of Bitcoin transactions, whether on-chain or using the Lightning Network. It even allows sellers to offer discounts on certain payment methods.In conclusion, the proposal to move the BIP70 protocol implementation into a browser extension offers a solution to the limitations and challenges associated with BIP70. By leveraging the existing capabilities of browsers and simplifying the integration process for wallets, this approach aims to enhance payment support and improve user experience in Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Design-approaches-for-Signature-Aggregation.xml b/static/bitcoin-dev/Jan_2018/combined_Design-approaches-for-Signature-Aggregation.xml index 704bfdad6e..400de2a163 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Design-approaches-for-Signature-Aggregation.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Design-approaches-for-Signature-Aggregation.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Design approaches for Signature Aggregation - 2023-08-01T22:35:40.724251+00:00 - - Russell O'Connor 2018-01-30 23:25:55+00:00 - - - Russell O'Connor 2018-01-30 19:12:31+00:00 - + 2025-09-26T15:43:07.502728+00:00 + python-feedgen + + + [bitcoin-dev] Design approaches for Signature Aggregation Russell O'Connor + 2018-01-30T19:12:00.000Z + + + Russell O'Connor + 2018-01-30T23:25:00.000Z + + - python-feedgen + 2 Combined summary - Design approaches for Signature Aggregation - 2023-08-01T22:35:40.724251+00:00 + 2025-09-26T15:43:07.503116+00:00 - In an email exchange, Russell O'Connor discussed the different designs for signature aggregation beyond the two he was discussing. Pieter suggested putting the aggregate signature data into the top of the first segwit v1+ input witness regardless of whether or not that input is participating in the aggregation. This canonical choice of position would be independent of the runtime behaviour of other scripts and also prevent the script from accessing the aggregate signature data itself while still fitting it into the existing witness data structure. However, this design does not allow for toying with the weights of aggregated signature. Despite this, people are still motivated to use taproot solely over P2WPKH based on having the option to perform aggregation.In an email discussion, Bitcoin Core developer Russell O'Connor argues against the expedient approach to cross-input signature aggregation proposed by Matt Corallo. The main issue with the expedient proposal is the arbitrary choice of which input witness will be the canonical choice for holding the aggregated signature. This complicates the specification and makes the implementation somewhat error-prone.On the other hand, the extended-transaction approach supports a clean model of script semantics whereby the signature aggregation is supported via a new writer (aka logging) side-effect for Script. In this model, rather than the semantics of Script returning only failure or success, Script instead results in either failure or conditional success plus a log of additional constraints that need to be satisfied for the transaction to be valid. The aggregated signature in the extension of the transaction provides a witness that demonstrates all the constraints emitted by all the scripts are satisfied.However, even in the extended-transaction approach, supporting future extensions of new script versions or new opcodes that may want to participate in signature aggregation is going to be very difficult. Russell has some half-baked ideas on how we could support new script versions and new opcodes based on this idea of a writer side-effect model of Script semantics. He thinks that the cleaner semantic model of the extended-transaction approach is by itself enough reason to prefer it over the expedient approach, but reasonable people can disagree about this.There are larger issues lurking which appear when we start looking for unintended semantic consequences of the expedient design. Russell believes that the expedient proposal has a host of unintended semantic consequences and the above list is only the ones that he can think of off the top of his head. He does not even know the full extent of what they will be enabling with this design but it seems to include adding a subversive unidirectional cross-input communication channel for Script. He thinks that the extended-transaction design is the conservative design. If this conjecture holds, it means that we can prove that the extended-transaction design is only an optimization and doesn't have any further unintended semantic consequences.In conclusion, Russell argues against the expedient approach to signature aggregation and believes that there are probably other designs for signature aggregation beyond the two designs discussed in the email. 2018-01-30T23:25:55+00:00 + In an email exchange, Russell O'Connor discussed the different designs for signature aggregation beyond the two he was discussing. Pieter suggested putting the aggregate signature data into the top of the first segwit v1+ input witness regardless of whether or not that input is participating in the aggregation. This canonical choice of position would be independent of the runtime behaviour of other scripts and also prevent the script from accessing the aggregate signature data itself while still fitting it into the existing witness data structure. However, this design does not allow for toying with the weights of aggregated signature. Despite this, people are still motivated to use taproot solely over P2WPKH based on having the option to perform aggregation.In an email discussion, Bitcoin Core developer Russell O'Connor argues against the expedient approach to cross-input signature aggregation proposed by Matt Corallo. The main issue with the expedient proposal is the arbitrary choice of which input witness will be the canonical choice for holding the aggregated signature. This complicates the specification and makes the implementation somewhat error-prone.On the other hand, the extended-transaction approach supports a clean model of script semantics whereby the signature aggregation is supported via a new writer (aka logging) side-effect for Script. In this model, rather than the semantics of Script returning only failure or success, Script instead results in either failure or conditional success plus a log of additional constraints that need to be satisfied for the transaction to be valid. The aggregated signature in the extension of the transaction provides a witness that demonstrates all the constraints emitted by all the scripts are satisfied.However, even in the extended-transaction approach, supporting future extensions of new script versions or new opcodes that may want to participate in signature aggregation is going to be very difficult. Russell has some half-baked ideas on how we could support new script versions and new opcodes based on this idea of a writer side-effect model of Script semantics. He thinks that the cleaner semantic model of the extended-transaction approach is by itself enough reason to prefer it over the expedient approach, but reasonable people can disagree about this.There are larger issues lurking which appear when we start looking for unintended semantic consequences of the expedient design. Russell believes that the expedient proposal has a host of unintended semantic consequences and the above list is only the ones that he can think of off the top of his head. He does not even know the full extent of what they will be enabling with this design but it seems to include adding a subversive unidirectional cross-input communication channel for Script. He thinks that the extended-transaction design is the conservative design. If this conjecture holds, it means that we can prove that the extended-transaction design is only an optimization and doesn't have any further unintended semantic consequences.In conclusion, Russell argues against the expedient approach to signature aggregation and believes that there are probably other designs for signature aggregation beyond the two designs discussed in the email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_How-accurate-are-the-Bitcoin-timestamps-.xml b/static/bitcoin-dev/Jan_2018/combined_How-accurate-are-the-Bitcoin-timestamps-.xml index b03b9c60e3..ab107fcf36 100644 --- a/static/bitcoin-dev/Jan_2018/combined_How-accurate-are-the-Bitcoin-timestamps-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_How-accurate-are-the-Bitcoin-timestamps-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - How accurate are the Bitcoin timestamps? - 2023-08-01T22:35:19.043009+00:00 - - Neiman 2018-01-30 10:53:41+00:00 - - - Neiman 2018-01-30 10:52:21+00:00 - - - Peter Todd 2018-01-30 07:27:16+00:00 - - - Bryan Bishop 2018-01-29 22:23:46+00:00 - - - Gregory Maxwell 2018-01-29 21:54:23+00:00 - - - George Balch 2018-01-29 21:53:06+00:00 - - - Tier Nolan 2018-01-29 21:40:44+00:00 - - - Neiman 2018-01-29 13:34:20+00:00 - + 2025-09-26T15:43:24.245068+00:00 + python-feedgen + + + [bitcoin-dev] How accurate are the Bitcoin timestamps? Neiman + 2018-01-29T13:34:00.000Z + + + Tier Nolan + 2018-01-29T21:40:00.000Z + + + George Balch + 2018-01-29T21:53:00.000Z + + + Gregory Maxwell + 2018-01-29T21:54:00.000Z + + + Bryan Bishop + 2018-01-29T22:23:00.000Z + + + Peter Todd + 2018-01-30T07:27:00.000Z + + + Neiman + 2018-01-30T10:52:00.000Z + + + Neiman + 2018-01-30T10:53:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - How accurate are the Bitcoin timestamps? - 2023-08-01T22:35:19.043009+00:00 + 2025-09-26T15:43:24.246150+00:00 - In a recent email thread on the bitcoin-dev mailing list, concerns were raised about the use of NTP (Network Time Protocol) for time synchronization in the Bitcoin protocol. The decentralized nature of Bitcoin mining requires accurate time synchronization to ensure the integrity of the blockchain. However, NTP has been found to have security vulnerabilities, such as being susceptible to man-in-the-middle attacks and distributed denial-of-service (DDoS) attacks.Alternative protocols, like Network Time Security (NTS), offer better security for time synchronization by using encryption and authentication measures. It is advisable for Bitcoin miners to consider adopting more secure time synchronization methods to protect the security and integrity of the blockchain.The discussion also revolves around the assumption that a majority of miners are honest, which is crucial for the functioning of Bitcoin. Tier Nolan questions this assumption specifically regarding timestamp manipulation. Dishonest miners could manipulate timestamps to their advantage, potentially causing harm to the network stability. One suggested improvement is to exchange the average with standard deviation in the difficulty adjustment formula, which would prevent timestamp manipulation without affecting the difficulty. However, these improvements rely on the assumption that most miners are honest.Gregory Maxwell proposed changing the design of Bitcoin to maintain accurate timestamps. Open-timestamp calendar servers were mentioned as providing more precise time-stamping, but they require trust in the server's behavior. Trusted timestamping schemes using disposable keys may be developed in the future.A researcher analyzed the accuracy of Bitcoin timestamps and suggested ways to improve them. Timestamps are used to adjust the difficulty of Proof of Work (PoW) and ensure node synchronization. The researcher suggests exchanging the average with standard deviation in the difficulty adjustment formula to better align with changes in hash power and prevent timestamp manipulation. However, this change would require a hardfork and is not expected to happen soon. The median of the last 11 blocks is currently used as an improved indicator of real-time for check locktime, assuming the majority of miners are honest.The author of a research project on blockchain timestamping questions the accuracy of Bitcoin timestamps and proposes using the block timestamp as proof of data existence at a specific time. They suggest improvements to the difficulty adjustment formula and highlight the control mechanisms provided by the PoW algorithm. However, they acknowledge that implementing these changes would require a hardfork and is unlikely to occur in the near future. 2018-01-30T10:53:41+00:00 + In a recent email thread on the bitcoin-dev mailing list, concerns were raised about the use of NTP (Network Time Protocol) for time synchronization in the Bitcoin protocol. The decentralized nature of Bitcoin mining requires accurate time synchronization to ensure the integrity of the blockchain. However, NTP has been found to have security vulnerabilities, such as being susceptible to man-in-the-middle attacks and distributed denial-of-service (DDoS) attacks.Alternative protocols, like Network Time Security (NTS), offer better security for time synchronization by using encryption and authentication measures. It is advisable for Bitcoin miners to consider adopting more secure time synchronization methods to protect the security and integrity of the blockchain.The discussion also revolves around the assumption that a majority of miners are honest, which is crucial for the functioning of Bitcoin. Tier Nolan questions this assumption specifically regarding timestamp manipulation. Dishonest miners could manipulate timestamps to their advantage, potentially causing harm to the network stability. One suggested improvement is to exchange the average with standard deviation in the difficulty adjustment formula, which would prevent timestamp manipulation without affecting the difficulty. However, these improvements rely on the assumption that most miners are honest.Gregory Maxwell proposed changing the design of Bitcoin to maintain accurate timestamps. Open-timestamp calendar servers were mentioned as providing more precise time-stamping, but they require trust in the server's behavior. Trusted timestamping schemes using disposable keys may be developed in the future.A researcher analyzed the accuracy of Bitcoin timestamps and suggested ways to improve them. Timestamps are used to adjust the difficulty of Proof of Work (PoW) and ensure node synchronization. The researcher suggests exchanging the average with standard deviation in the difficulty adjustment formula to better align with changes in hash power and prevent timestamp manipulation. However, this change would require a hardfork and is not expected to happen soon. The median of the last 11 blocks is currently used as an improved indicator of real-time for check locktime, assuming the majority of miners are honest.The author of a research project on blockchain timestamping questions the accuracy of Bitcoin timestamps and proposes using the block timestamp as proof of data existence at a specific time. They suggest improvements to the difficulty adjustment formula and highlight the control mechanisms provided by the PoW algorithm. However, they acknowledge that implementing these changes would require a hardfork and is unlikely to occur in the near future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Ivy-a-higher-level-language-targeting-Bitcoin-Script.xml b/static/bitcoin-dev/Jan_2018/combined_Ivy-a-higher-level-language-targeting-Bitcoin-Script.xml index 68ef83c108..391fb6250e 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Ivy-a-higher-level-language-targeting-Bitcoin-Script.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Ivy-a-higher-level-language-targeting-Bitcoin-Script.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Ivy: a higher-level language targeting Bitcoin Script - 2023-08-01T22:20:46.287366+00:00 - - Daniel Robinson 2018-01-15 22:39:05+00:00 - - - Matt Corallo 2018-01-14 22:41:55+00:00 - - - Daniel Robinson 2017-12-18 20:32:17+00:00 - + 2025-09-26T15:43:09.591080+00:00 + python-feedgen + + + [bitcoin-dev] Ivy: a higher-level language targeting Bitcoin Script Daniel Robinson + 2017-12-18T20:32:00.000Z + + + Matt Corallo + 2018-01-14T22:41:00.000Z + + + Daniel Robinson + 2018-01-15T22:39:00.000Z + + - python-feedgen + 2 Combined summary - Ivy: a higher-level language targeting Bitcoin Script - 2023-08-01T22:20:46.287366+00:00 + 2025-09-26T15:43:09.591640+00:00 - The Ivy team has released a prototype higher-level language and development environment called Ivy for creating custom Bitcoin Script programs. Ivy aims to improve the usability of Bitcoin Script by adding features like named variables and clauses, static types, and a familiar syntax for function calls. It is a simple smart contract language that can compile to Bitcoin Script. However, there was an issue with how the compiler was handling clause selection that led to a minor witness malleability problem. This problem has been fixed in version 0.0.7 of the compiler. To prevent witness malleability, a user suggested adding some form of compiler-time enforcement, but the team believes it would be easier to build a static analyzer for low-level Bitcoin Script.Ivy is currently a prototype software intended for educational and research purposes only. It should not be used to control real or testnet Bitcoins. The Ivy Playground for Bitcoin allows users to create and test simulated contracts in a sandboxed environment. By providing a higher-level language and development environment, Ivy offers a more user-friendly approach to writing Bitcoin scripts and potentially resolving witness malleability issues. 2018-01-15T22:39:05+00:00 + The Ivy team has released a prototype higher-level language and development environment called Ivy for creating custom Bitcoin Script programs. Ivy aims to improve the usability of Bitcoin Script by adding features like named variables and clauses, static types, and a familiar syntax for function calls. It is a simple smart contract language that can compile to Bitcoin Script. However, there was an issue with how the compiler was handling clause selection that led to a minor witness malleability problem. This problem has been fixed in version 0.0.7 of the compiler. To prevent witness malleability, a user suggested adding some form of compiler-time enforcement, but the team believes it would be easier to build a static analyzer for low-level Bitcoin Script.Ivy is currently a prototype software intended for educational and research purposes only. It should not be used to control real or testnet Bitcoins. The Ivy Playground for Bitcoin allows users to create and test simulated contracts in a sandboxed environment. By providing a higher-level language and development environment, Ivy offers a more user-friendly approach to writing Bitcoin scripts and potentially resolving witness malleability issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Merge-of-protocol.xml b/static/bitcoin-dev/Jan_2018/combined_Merge-of-protocol.xml index ff726d4976..9463e20ea9 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Merge-of-protocol.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Merge-of-protocol.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Merge of protocol - 2023-08-01T22:33:37.638506+00:00 - - Tier Nolan 2018-01-24 15:02:38+00:00 - - - Ilan Oh 2018-01-24 11:56:04+00:00 - + 2025-09-26T15:43:15.859558+00:00 + python-feedgen + + + [bitcoin-dev] Merge of protocol Ilan Oh + 2018-01-24T11:56:00.000Z + + + Tier Nolan + 2018-01-24T15:02:00.000Z + + - python-feedgen + 2 Combined summary - Merge of protocol - 2023-08-01T22:33:37.638506+00:00 + 2025-09-26T15:43:15.860053+00:00 - The discussion on the bitcoin-dev mailing list revolved around the technical feasibility of merging two blockchain protocols to create a new coin that combines the strengths of both. While it is technically possible for communities behind two coins to merge, the process is challenging and risky, requiring agreement from each coin's community as well as between the two communities. This would involve creating a merge block with two parents, resulting in a hard fork on both chains.2017 witnessed numerous forks in the cryptocurrency world, making the idea of merging altcoins with bitcoin or with each other more prominent. The ongoing development of the Lightning Network also played a role in prompting altcoin communities to consider merging with bitcoin. However, despite the interest and potential benefits, the initial post did not provide any concrete resources or ideas on how to proceed with such mergers.Overall, the discussion highlighted the technical possibilities and challenges associated with merging different blockchain protocols to create new coins with enhanced capabilities. 2018-01-24T15:02:38+00:00 + The discussion on the bitcoin-dev mailing list revolved around the technical feasibility of merging two blockchain protocols to create a new coin that combines the strengths of both. While it is technically possible for communities behind two coins to merge, the process is challenging and risky, requiring agreement from each coin's community as well as between the two communities. This would involve creating a merge block with two parents, resulting in a hard fork on both chains.2017 witnessed numerous forks in the cryptocurrency world, making the idea of merging altcoins with bitcoin or with each other more prominent. The ongoing development of the Lightning Network also played a role in prompting altcoin communities to consider merging with bitcoin. However, despite the interest and potential benefits, the initial post did not provide any concrete resources or ideas on how to proceed with such mergers.Overall, the discussion highlighted the technical possibilities and challenges associated with merging different blockchain protocols to create new coins with enhanced capabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_NIST-8202-Blockchain-Technology-Overview.xml b/static/bitcoin-dev/Jan_2018/combined_NIST-8202-Blockchain-Technology-Overview.xml index 578ab7927f..f6b4d67ace 100644 --- a/static/bitcoin-dev/Jan_2018/combined_NIST-8202-Blockchain-Technology-Overview.xml +++ b/static/bitcoin-dev/Jan_2018/combined_NIST-8202-Blockchain-Technology-Overview.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - NIST 8202 Blockchain Technology Overview - 2023-08-01T22:34:39.673001+00:00 - - CANNON 2018-02-18 16:20:13+00:00 - - - Damian Williamson 2018-02-06 07:07:26+00:00 - - - CANNON 2018-02-06 02:08:24+00:00 - - - Peter Todd 2018-01-30 07:22:55+00:00 - - - CANNON 2018-01-30 03:30:21+00:00 - - - CANNON 2018-01-30 01:43:22+00:00 - - - CANNON 2018-01-29 01:08:24+00:00 - - - CANNON 2018-01-29 00:40:32+00:00 - + 2025-09-26T15:43:13.767882+00:00 + python-feedgen + + + [bitcoin-dev] NIST 8202 Blockchain Technology Overview CANNON + 2018-01-29T00:40:00.000Z + + + CANNON + 2018-01-29T01:08:00.000Z + + + CANNON + 2018-01-30T01:43:00.000Z + + + CANNON + 2018-01-30T03:30:00.000Z + + + Peter Todd + 2018-01-30T07:22:00.000Z + + + CANNON + 2018-02-06T02:08:00.000Z + + + Damian Williamson + 2018-02-06T07:07:00.000Z + + + CANNON + 2018-02-18T16:20:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - NIST 8202 Blockchain Technology Overview - 2023-08-01T22:34:39.673001+00:00 + 2025-09-26T15:43:13.768963+00:00 - In an email conversation between Damian Williamson and CANNON, disagreements arise regarding the implementation of SegWit changes and the increase in blocksize by Bitcoin Cash. Williamson suggests that Bitcoin Cash developers decided to increase the blocksize in addition to implementing SegWit changes, whereas CANNON points out that Bitcoin Cash has yet to implement these improvements. SegWit, a softfork, enables advanced smart contracts, micropayment networks, and increases signature security. The conversation also includes a PGP signed message.Another email conversation between Damian Williamson and an anonymous individual revolves around the method used by Bitcoin Cash developers to improve the cryptocurrency's capabilities. Williamson argues that the statement implying Bitcoin Cash chose to increase blocksize over implementing SegWit is incorrect because the developers wanted to implement other improvements as well. However, the anonymous individual counters by stating that SegWit includes features beyond scaling and Bitcoin Cash has yet to implement them. The wording used by Williamson suggests that Bitcoin Cash has implemented SegWit, which is not the case.A forwarded email sent to the bitcoin-dev mailing list discusses concerns about section 8.1.2 of the NIST 8202 Blockchain Technology Overview. Dylan Yaga from Fed revises the section and sends it to CANNON for further comment and transparency. Section 8.1.2 covers Bitcoin Cash (BCH), which resulted from a hard fork of the Bitcoin blockchain. Instead of implementing SegWit changes, Bitcoin Cash developers increased the blocksize, allowing people to have access to the same amount of coins on both Bitcoin and Bitcoin Cash. A question arises about whether transactions are more compact due to SegWit, with the answer being that they appear more compact to un-upgraded nodes but are not actually more compact.Dylan Yaga of the Federal government responds to feedback on section 8.1.2 of the NIST 8202 Blockchain Technology Overview. Bitcoin Cash (BCH), a hard fork of the Bitcoin blockchain in 2017, opted for an increased blocksize instead of implementing SegWit changes. This resulted in users having access to the same amount of coins on both Bitcoin and Bitcoin Cash. The revised section is sent for further comment to ensure transparency.The context also includes a correction to an email that was previously sent with an incorrect date. The original email titled "NIST 8202 Blockchain Technology Overview" had the wrong date in the header, which is corrected to Jan 28th. The corrected date can be verified through the email signature. The sender also sends an email with the corrected date to the NIST comments email address. The message is signed with PGP and includes a SHA512 hash. The author's identity is not mentioned.The author of the message comments on Draft NISTIR 8202 Blockchain Technology Overview, expressing their belief that the paper contains false information and is technologically invalid. Specifically, they point out errors in the section about "Bitcoin Cash (BCC)" and provide four corrections. They clarify that Bitcoin Cash uses the ticker BCH, not BCC, emphasize that SegWit was a softfork, highlight that the original bitcoin blockchain is still called Bitcoin, and note that Bitcoin Cash is a forked altcoin, not the original chain. The author hopes that their comments will contribute to improving the paper and suggests that better research could have prevented these errors. 2018-02-18T16:20:13+00:00 + In an email conversation between Damian Williamson and CANNON, disagreements arise regarding the implementation of SegWit changes and the increase in blocksize by Bitcoin Cash. Williamson suggests that Bitcoin Cash developers decided to increase the blocksize in addition to implementing SegWit changes, whereas CANNON points out that Bitcoin Cash has yet to implement these improvements. SegWit, a softfork, enables advanced smart contracts, micropayment networks, and increases signature security. The conversation also includes a PGP signed message.Another email conversation between Damian Williamson and an anonymous individual revolves around the method used by Bitcoin Cash developers to improve the cryptocurrency's capabilities. Williamson argues that the statement implying Bitcoin Cash chose to increase blocksize over implementing SegWit is incorrect because the developers wanted to implement other improvements as well. However, the anonymous individual counters by stating that SegWit includes features beyond scaling and Bitcoin Cash has yet to implement them. The wording used by Williamson suggests that Bitcoin Cash has implemented SegWit, which is not the case.A forwarded email sent to the bitcoin-dev mailing list discusses concerns about section 8.1.2 of the NIST 8202 Blockchain Technology Overview. Dylan Yaga from Fed revises the section and sends it to CANNON for further comment and transparency. Section 8.1.2 covers Bitcoin Cash (BCH), which resulted from a hard fork of the Bitcoin blockchain. Instead of implementing SegWit changes, Bitcoin Cash developers increased the blocksize, allowing people to have access to the same amount of coins on both Bitcoin and Bitcoin Cash. A question arises about whether transactions are more compact due to SegWit, with the answer being that they appear more compact to un-upgraded nodes but are not actually more compact.Dylan Yaga of the Federal government responds to feedback on section 8.1.2 of the NIST 8202 Blockchain Technology Overview. Bitcoin Cash (BCH), a hard fork of the Bitcoin blockchain in 2017, opted for an increased blocksize instead of implementing SegWit changes. This resulted in users having access to the same amount of coins on both Bitcoin and Bitcoin Cash. The revised section is sent for further comment to ensure transparency.The context also includes a correction to an email that was previously sent with an incorrect date. The original email titled "NIST 8202 Blockchain Technology Overview" had the wrong date in the header, which is corrected to Jan 28th. The corrected date can be verified through the email signature. The sender also sends an email with the corrected date to the NIST comments email address. The message is signed with PGP and includes a SHA512 hash. The author's identity is not mentioned.The author of the message comments on Draft NISTIR 8202 Blockchain Technology Overview, expressing their belief that the paper contains false information and is technologically invalid. Specifically, they point out errors in the section about "Bitcoin Cash (BCC)" and provide four corrections. They clarify that Bitcoin Cash uses the ticker BCH, not BCC, emphasize that SegWit was a softfork, highlight that the original bitcoin blockchain is still called Bitcoin, and note that Bitcoin Cash is a forked altcoin, not the original chain. The author hopes that their comments will contribute to improving the paper and suggests that better research could have prevented these errors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_New-Bitcoin-Core-macOS-signing-key.xml b/static/bitcoin-dev/Jan_2018/combined_New-Bitcoin-Core-macOS-signing-key.xml index 50db9e4745..59969278c1 100644 --- a/static/bitcoin-dev/Jan_2018/combined_New-Bitcoin-Core-macOS-signing-key.xml +++ b/static/bitcoin-dev/Jan_2018/combined_New-Bitcoin-Core-macOS-signing-key.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - New Bitcoin Core macOS signing key - 2023-08-01T22:27:54.667619+00:00 - - Cory Fields 2018-02-01 01:14:45+00:00 - - - nullius 2018-01-12 10:14:11+00:00 - - - Peter Todd 2018-01-12 08:54:12+00:00 - - - Cory Fields 2018-01-12 05:04:44+00:00 - + 2025-09-26T15:43:38.937004+00:00 + python-feedgen + + + [bitcoin-dev] New Bitcoin Core macOS signing key Cory Fields + 2018-01-12T05:04:00.000Z + + + Peter Todd + 2018-01-12T08:54:00.000Z + + + nullius + 2018-01-12T10:14:00.000Z + + + Cory Fields + 2018-02-01T01:14:00.000Z + + - python-feedgen + 2 Combined summary - New Bitcoin Core macOS signing key - 2023-08-01T22:27:54.667619+00:00 + 2025-09-26T15:43:38.937382+00:00 - A new public key has been generated for Bitcoin Core releases starting with 0.16.0rc1 due to an error in the previously published key that was created for iPhone OS instead of macOS. The purpose of the new key is to sign future macOS releases, and it can be verified using openssl smime -verify -noverify -in msg.pem. This announcement apologizes for the confusion caused by the noise, and the previous email contains the original pubkey that is no longer valid.Meanwhile, Bitcoin Core developer Peter Todd discussed how OpenTimestamps (OTS) provided little proof when verifying an important certificate in the Bitcoin software. While OTS extracted a timestamped proof of existence for the BitcoinFoundation_Apple_Cert.pem file within the repo, it failed to prove who had put it there. Todd explained that if someone could create a collision between the real certificate and one for which they had the private key, they could switch them at a later date. Furthermore, Todd found a security hole related to clearsigned PGP recently. He suggests using a detached signature or piping gpg --verify -o - to grep instead of separating verification from use of data.In another post on the bitcoin-dev mailing list, Todd described how to use the `-signer` option in OpenSSL to write the signer's certificate to a file, which can then be compared to the one from the repository. He also noted that OpenTimestamps has git integration, allowing the extraction of an OTS proof generated as of Oct 13, 2016 for the certificate from the repo. However, he questioned if the proof generated by those three commands are crypto snakeoil that proved little since there was no proof of who put it there. Additionally, with the breaking of SHA-1, there may be scenarios involving two different PEMs with the same hash but different public keys. Todd discussed potential solutions using PGP, such as not using clearsigning, using a detached signature, or having shell scripts written by someone knowledgeable about security.The email conversation on the bitcoin-dev mailing list suggested using openssl smime to verify the certificate used to sign Bitcoin Core binaries. The -ignore_critical flag is required to ignore Apple specific critical extensions that OpenSSL doesn't understand, and the -purpose any allows skipping the purpose == smimesign check since the certificate is only authorized to sign code, not arbitrary messages. However, it is noted that the signature will fail to validate as the certificate has expired. If openssl doesn't have the Apple Certificate Authority in its CA list, -noverify needs to be added. To compare the signer's certificate to the one from the repo, the -signer option can be used to write the signer's certificate to a file. OpenTimestamps has git integration, which allows the extraction of an OTS proof from 2016 for that certificate from the repo. The signed message was timestamped on the Bitcoin blockchain using OpenTimestamps. The issue is that asking the user to cut-n-paste that PKCS7-encoded message is problematic, as differences in whitespace and line endings will make the verification fail. Bitcoin Core's contrib/verifybinaries/verify.sh isn't vulnerable to this mistake.Bitcoin Core's macOS code signing certificate has expired, and a new threshold signing scheme is being established to handle code signing without any single point of failure. Until then, releases will be signed as before, just with a new certificate. The old code-signing key/certificate was used to sign a message containing the pubkey that matches the new key/certificate for record purposes. The attached pkcs7 format contains the current signing certificate to make verification easier. Verification can be done using openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose any command. The signature will probably fail to validate now because the certificate has expired. To timestamp the signed message on the Bitcoin blockchain, OpenTimestamps was used. An ots file containing the timestamp proof is attached.The context also includes a PKCS7 encoded file with the encryption key MCVVMCCCdK9a7psn2QMAkGBSsOAwIaBQCggbEw and a signature in OpenDocument format named expire.txt.sig.ots. However, the URL for the attachment is not provided in the context. 2018-02-01T01:14:45+00:00 + A new public key has been generated for Bitcoin Core releases starting with 0.16.0rc1 due to an error in the previously published key that was created for iPhone OS instead of macOS. The purpose of the new key is to sign future macOS releases, and it can be verified using openssl smime -verify -noverify -in msg.pem. This announcement apologizes for the confusion caused by the noise, and the previous email contains the original pubkey that is no longer valid.Meanwhile, Bitcoin Core developer Peter Todd discussed how OpenTimestamps (OTS) provided little proof when verifying an important certificate in the Bitcoin software. While OTS extracted a timestamped proof of existence for the BitcoinFoundation_Apple_Cert.pem file within the repo, it failed to prove who had put it there. Todd explained that if someone could create a collision between the real certificate and one for which they had the private key, they could switch them at a later date. Furthermore, Todd found a security hole related to clearsigned PGP recently. He suggests using a detached signature or piping gpg --verify -o - to grep instead of separating verification from use of data.In another post on the bitcoin-dev mailing list, Todd described how to use the `-signer` option in OpenSSL to write the signer's certificate to a file, which can then be compared to the one from the repository. He also noted that OpenTimestamps has git integration, allowing the extraction of an OTS proof generated as of Oct 13, 2016 for the certificate from the repo. However, he questioned if the proof generated by those three commands are crypto snakeoil that proved little since there was no proof of who put it there. Additionally, with the breaking of SHA-1, there may be scenarios involving two different PEMs with the same hash but different public keys. Todd discussed potential solutions using PGP, such as not using clearsigning, using a detached signature, or having shell scripts written by someone knowledgeable about security.The email conversation on the bitcoin-dev mailing list suggested using openssl smime to verify the certificate used to sign Bitcoin Core binaries. The -ignore_critical flag is required to ignore Apple specific critical extensions that OpenSSL doesn't understand, and the -purpose any allows skipping the purpose == smimesign check since the certificate is only authorized to sign code, not arbitrary messages. However, it is noted that the signature will fail to validate as the certificate has expired. If openssl doesn't have the Apple Certificate Authority in its CA list, -noverify needs to be added. To compare the signer's certificate to the one from the repo, the -signer option can be used to write the signer's certificate to a file. OpenTimestamps has git integration, which allows the extraction of an OTS proof from 2016 for that certificate from the repo. The signed message was timestamped on the Bitcoin blockchain using OpenTimestamps. The issue is that asking the user to cut-n-paste that PKCS7-encoded message is problematic, as differences in whitespace and line endings will make the verification fail. Bitcoin Core's contrib/verifybinaries/verify.sh isn't vulnerable to this mistake.Bitcoin Core's macOS code signing certificate has expired, and a new threshold signing scheme is being established to handle code signing without any single point of failure. Until then, releases will be signed as before, just with a new certificate. The old code-signing key/certificate was used to sign a message containing the pubkey that matches the new key/certificate for record purposes. The attached pkcs7 format contains the current signing certificate to make verification easier. Verification can be done using openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose any command. The signature will probably fail to validate now because the certificate has expired. To timestamp the signed message on the Bitcoin blockchain, OpenTimestamps was used. An ots file containing the timestamp proof is attached.The context also includes a PKCS7 encoded file with the encryption key MCVVMCCCdK9a7psn2QMAkGBSsOAwIaBQCggbEw and a signature in OpenDocument format named expire.txt.sig.ots. However, the URL for the attachment is not provided in the context. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Plausible-Deniability-Re-Satoshilabs-secret-shared-private-key-scheme-.xml b/static/bitcoin-dev/Jan_2018/combined_Plausible-Deniability-Re-Satoshilabs-secret-shared-private-key-scheme-.xml index 5324ace8c6..cf00616e21 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Plausible-Deniability-Re-Satoshilabs-secret-shared-private-key-scheme-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Plausible-Deniability-Re-Satoshilabs-secret-shared-private-key-scheme-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Plausible Deniability (Re: Satoshilabs secret shared private key scheme) - 2023-08-01T22:28:47.059721+00:00 + 2025-09-26T15:43:22.154976+00:00 + python-feedgen Peter Todd 2018-01-13 06:11:12+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Plausible Deniability (Re: Satoshilabs secret shared private key scheme) - 2023-08-01T22:28:47.059721+00:00 + 2025-09-26T15:43:22.155118+00:00 - A member of the Bitcoin development community has suggested that encryption headers for LUKS should be written onto disks, even if they are not used. This suggestion came as part of a challenge to "plausible deniability" designers, with the aim of encrypting a 6 TB disk with pseudorandom bytes and testing what happens when the data is searched at US borders.The challenge is based on the belief that a disk filled with pseudorandom data is not inherently suspicious. Encrypted partitions that are filled and later reformatted will contain random bytes, and modern drives often implement fast secure erasure with encryption, resulting in wiped data becoming random noise. Similarly, software disk encryption schemes fill drives with random noise upon reformatting.The author of the article shares their own practice of immediately 'dd' any new hard disk or decommissioned old one with a pseudorandom byte stream, making it indistinguishable from a disk encryption setup. They challenge plausible deniability designers to 'dd' a 6TB disk with pseudorandom bytes and attempt to walk it across the US border until it gets searched.In response to a comment, the author emphasizes the importance of developing appropriate threat models, keeping security systems confidential, and increasing the popularity of network security systems to reduce suspicion. The only shield against plausibility, according to the author, is not seeming like someone who is likely to have much. Plausible deniability is seen as ineffective against sophisticated adversaries possessing both intelligence and patience.The concept of "plausible deniability" is questioned in relation to devices like Trezor. While the objective of plausible deniability is to present an acceptable alternative while hiding the actual, it can backfire by serving as evidence against the user. In legal scenarios where authorities suspect a user of having more cryptocurrency than disclosed, relying on plausible deniability may result in the user being jailed until they reveal the real password.Information does not exist in isolation, and it is crucial to have a privacy practice that leaves no suspicion of owning any Bitcoin. If a user is known or believed to own large amounts of BTC, their "decoy" wallet may provoke a realistic threat response from adversaries. Plausible deniability schemes can lead to serious consequences, as they may expose traces of other wallets on the computer, and network data could tie one's identity to their wallet.The use of "plausible deniability" is also discussed in the context of Trezor's scheme. Users could face jail time for lying to border security if their alternate passwords based on seeds are brute-forced. While passphrases can be long, most users may not fully grasp the risks involved. Instead of relying on plausible deniability, it is suggested to obviate the need for denial altogether. The post highlights that customs agents have access to cross-correlated analysis data, which could result in prolonged detention while hard drives are examined for evidence linking Trezor apps to known addresses. 2018-01-13T06:11:12+00:00 + A member of the Bitcoin development community has suggested that encryption headers for LUKS should be written onto disks, even if they are not used. This suggestion came as part of a challenge to "plausible deniability" designers, with the aim of encrypting a 6 TB disk with pseudorandom bytes and testing what happens when the data is searched at US borders.The challenge is based on the belief that a disk filled with pseudorandom data is not inherently suspicious. Encrypted partitions that are filled and later reformatted will contain random bytes, and modern drives often implement fast secure erasure with encryption, resulting in wiped data becoming random noise. Similarly, software disk encryption schemes fill drives with random noise upon reformatting.The author of the article shares their own practice of immediately 'dd' any new hard disk or decommissioned old one with a pseudorandom byte stream, making it indistinguishable from a disk encryption setup. They challenge plausible deniability designers to 'dd' a 6TB disk with pseudorandom bytes and attempt to walk it across the US border until it gets searched.In response to a comment, the author emphasizes the importance of developing appropriate threat models, keeping security systems confidential, and increasing the popularity of network security systems to reduce suspicion. The only shield against plausibility, according to the author, is not seeming like someone who is likely to have much. Plausible deniability is seen as ineffective against sophisticated adversaries possessing both intelligence and patience.The concept of "plausible deniability" is questioned in relation to devices like Trezor. While the objective of plausible deniability is to present an acceptable alternative while hiding the actual, it can backfire by serving as evidence against the user. In legal scenarios where authorities suspect a user of having more cryptocurrency than disclosed, relying on plausible deniability may result in the user being jailed until they reveal the real password.Information does not exist in isolation, and it is crucial to have a privacy practice that leaves no suspicion of owning any Bitcoin. If a user is known or believed to own large amounts of BTC, their "decoy" wallet may provoke a realistic threat response from adversaries. Plausible deniability schemes can lead to serious consequences, as they may expose traces of other wallets on the computer, and network data could tie one's identity to their wallet.The use of "plausible deniability" is also discussed in the context of Trezor's scheme. Users could face jail time for lying to border security if their alternate passwords based on seeds are brute-forced. While passphrases can be long, most users may not fully grasp the risks involved. Instead of relying on plausible deniability, it is suggested to obviate the need for denial altogether. The post highlights that customs agents have access to cross-correlated analysis data, which could result in prolonged detention while hard drives are examined for evidence linking Trezor apps to known addresses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Proof-of-Loss.xml b/static/bitcoin-dev/Jan_2018/combined_Proof-of-Loss.xml index 6ca12514e2..70f79e670f 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Proof-of-Loss.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Proof-of-Loss.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Proof-of-Loss - 2023-08-01T19:30:46.090435+00:00 - - Mirelo 2018-01-04 10:54:31+00:00 - - - Mirelo 2017-04-06 05:47:17+00:00 - - - Erik Aronesty 2017-04-06 02:43:18+00:00 - - - Mirelo 2017-04-05 19:12:20+00:00 - - - Mirelo 2017-02-04 12:39:45+00:00 - + 2025-09-26T15:43:28.419947+00:00 + python-feedgen + + + [bitcoin-dev] Proof-of-Loss Mirelo + 2017-02-04T12:39:00.000Z + + + Mirelo + 2017-04-05T19:12:00.000Z + + + Erik Aronesty + 2017-04-06T02:43:00.000Z + + + Mirelo + 2017-04-06T05:47:00.000Z + + + [bitcoin-dev] Proof-of-Loss Mirelo + 2018-01-04T10:54:00.000Z + + - python-feedgen + 2 Combined summary - Proof-of-Loss - 2023-08-01T19:30:46.091448+00:00 + 2025-09-26T15:43:28.420755+00:00 - Mirelo, the creator of Proof-of-Loss, has made revisions to the algorithm and is seeking feedback. The updated version includes a more explicit definition of transaction rights, an overview of how the algorithm works, and the incorporation of the current block height in the proof-of-loss data. Mirelo has requested feedback through his email or the links provided on the Proof-of-Loss homepage. The revised algorithm also corrects transaction prioritization and inactivity fees, as well as revises the design. Proof-of-Loss is an alternative consensus algorithm that aims to address the deficiencies of both proof-of-work and proof-of-stake. It tackles issues such as mining centralization and the "nothing at stake" problem. In an email to bitcoin-dev, Mirelo acknowledges that previous feedback indicated the article was difficult to comprehend, prompting him to make revisions. The new version clarifies transaction rights and provides an overview of the algorithm's functioning. Additionally, the inclusion of the current block height in the proof-of-loss data simplifies the enforcement of serial chaining without requiring additional block height information. The updated version can be accessed at https://proof-of-loss.money/. The revised Proof-of-Loss algorithm incorporates suggestions received from feedback. It addresses the need for a clearer definition of transaction rights and a comprehensive explanation of the algorithm's operation. The updated version also facilitates serial chaining through the integration of the current block height in the proof-of-loss data. Furthermore, it rectifies transaction prioritization by utilizing fees rather than rights, and includes adjustments to inactivity fees. The new version of the algorithm is available at https://proof-of-loss.money/. Proof-of-Loss presents a novel consensus algorithm that seeks to overcome the limitations of both proof-of-work and proof-of-stake. Its objective is to resolve issues such as the absence of an organic block size limit, risks associated with mining centralization, and the "nothing at stake" problem. A detailed explanation of the algorithm can be found on the proof-of-loss.money website. 2018-01-04T10:54:31+00:00 + Mirelo, the creator of Proof-of-Loss, has made revisions to the algorithm and is seeking feedback. The updated version includes a more explicit definition of transaction rights, an overview of how the algorithm works, and the incorporation of the current block height in the proof-of-loss data. Mirelo has requested feedback through his email or the links provided on the Proof-of-Loss homepage. The revised algorithm also corrects transaction prioritization and inactivity fees, as well as revises the design. Proof-of-Loss is an alternative consensus algorithm that aims to address the deficiencies of both proof-of-work and proof-of-stake. It tackles issues such as mining centralization and the "nothing at stake" problem. In an email to bitcoin-dev, Mirelo acknowledges that previous feedback indicated the article was difficult to comprehend, prompting him to make revisions. The new version clarifies transaction rights and provides an overview of the algorithm's functioning. Additionally, the inclusion of the current block height in the proof-of-loss data simplifies the enforcement of serial chaining without requiring additional block height information. The updated version can be accessed at https://proof-of-loss.money/. The revised Proof-of-Loss algorithm incorporates suggestions received from feedback. It addresses the need for a clearer definition of transaction rights and a comprehensive explanation of the algorithm's operation. The updated version also facilitates serial chaining through the integration of the current block height in the proof-of-loss data. Furthermore, it rectifies transaction prioritization by utilizing fees rather than rights, and includes adjustments to inactivity fees. The new version of the algorithm is available at https://proof-of-loss.money/. Proof-of-Loss presents a novel consensus algorithm that seeks to overcome the limitations of both proof-of-work and proof-of-stake. Its objective is to resolve issues such as the absence of an organic block size limit, risks associated with mining centralization, and the "nothing at stake" problem. A detailed explanation of the algorithm can be found on the proof-of-loss.money website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Proposal-rewarding-fees-to-next-block-miner.xml b/static/bitcoin-dev/Jan_2018/combined_Proposal-rewarding-fees-to-next-block-miner.xml index dfa25dcbee..3917090953 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Proposal-rewarding-fees-to-next-block-miner.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Proposal-rewarding-fees-to-next-block-miner.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - Proposal: rewarding fees to next block miner - 2023-08-01T22:34:14.759912+00:00 - - Eric Voskuil 2018-01-30 03:52:21+00:00 - - - Gregory Maxwell 2018-01-30 01:59:48+00:00 - - - Eric Voskuil 2018-01-29 23:21:48+00:00 - - - Gregory Maxwell 2018-01-29 21:22:25+00:00 - - - Eric Voskuil 2018-01-29 04:49:10+00:00 - - - George Balch 2018-01-29 01:44:08+00:00 - - - Eric Voskuil 2018-01-29 00:46:51+00:00 - - - Lucas Clemente Vella 2018-01-28 16:54:36+00:00 - - - Eric Voskuil 2018-01-27 23:48:10+00:00 - - - Gregory Maxwell 2018-01-27 19:06:41+00:00 - - - Nathan Parker 2018-01-27 08:45:10+00:00 - + 2025-09-26T15:43:49.435189+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: rewarding fees to next block miner Nathan Parker + 2018-01-27T08:45:00.000Z + + + Gregory Maxwell + 2018-01-27T19:06:00.000Z + + + Eric Voskuil + 2018-01-27T23:48:00.000Z + + + Lucas Clemente Vella + 2018-01-28T16:54:00.000Z + + + Eric Voskuil + 2018-01-29T00:46:00.000Z + + + George Balch + 2018-01-29T01:44:00.000Z + + + Eric Voskuil + 2018-01-29T04:49:00.000Z + + + Gregory Maxwell + 2018-01-29T21:22:00.000Z + + + Eric Voskuil + 2018-01-29T23:21:00.000Z + + + Gregory Maxwell + 2018-01-30T01:59:00.000Z + + + Eric Voskuil + 2018-01-30T03:52:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - Proposal: rewarding fees to next block miner - 2023-08-01T22:34:14.759912+00:00 + 2025-09-26T15:43:49.436377+00:00 - In an email exchange, Gregory Maxwell and Eric Voskuil discussed the concept of block space ownership in Bitcoin. Voskuil argued that miners have the right to sell or not sell block space since it belongs to them. However, Maxwell pointed out that as users of Bitcoin, they collectively pay miners around $130k USD per block in the form of inflation for the job of complying with the Bitcoin protocol. While there is subsidy involved, miners still accept a net loss by purchasing space for themselves if they do not accept the highest fee transactions. Maxwell also dispelled the idea of "retaliation" against miners who purchase block space, stating that it is not possible or desirable to detect the source of transactions in a system without identity. He further explained that reducing returns to miners would simply result in a reduction of hash power and not a decrease in transaction costs.In an email conversation on January 29, 2018, Eric Voskuil argued that block space created by a miner is the property of the miner, which can be sold or not sold. However, this argument is weak given that Bitcoin users collectively pay miners around $130k USD per block as inflation for complying with the Bitcoin protocol. It is unclear whether miners have more right to this payment than Bitcoin users have to run software that invalidates the coinbase outputs of miners who do not comply with the protocol. Such retaliation could be targeted against non-compliant miners.In a discussion on the bitcoin-dev mailing list, Gregory Maxwell and Eric Voskuil debated the idea that miners gain an advantage by mining empty blocks or rejecting higher-fee transactions. While Voskuil argued that this was a myth, Maxwell suggested that there might be some truth to it, given that empty blocks are more conspicuous and could invite retaliation, especially with high levels of mining centralization. However, he also noted that dummy transactions are just as conspicuous, and underfilled blocks are produced without any apparent retaliation. Maxwell further argued that since block space created by a miner is the miner's property, it can be sold or not sold, without any harm to others.In a recent bitcoin-dev email thread, Eric Voskuil and an unknown source debunked the myth that miners have an advantage over those buying block space. Voskuil believes this idea is complete nonsense and even steel-manned it by arguing that empty blocks could invite retaliation due to high levels of mining centralization creating retaliation exposure. However, he points out that dummy transactions are hardly less conspicuous and many nodes log when blocks show up containing transactions they've never seen before. Furthermore, underfilled blocks are produced by Bitmain's Antpool without any retaliation forthcoming.The context involves a discussion among members of the bitcoin-dev mailing list regarding whether or not miners incur a cost by leaving transactions out of a block. Some members argue that miners do pay a cost by not being rewarded those fees, while others argue that this is not a question of cost but rather incentive compatibility. Additionally, there is debate about whether miners fill their blocks with transactions paying very high fees at no cost because they get the fees back themselves, and if so, how to discourage this behavior. One proposed solution is to reward the fees of the current block to the miner of the next block (or X blocks after the current one), which would discourage flooding blocks with fake transactions. However, there are concerns about the possible downside of this solution, such as a temporary drop in hashrate if miners power off their equipment during the period without rewards. Overall, the discussion revolves around the incentives and costs for miners in the bitcoin network.Miners are not rewarded with fees if they leave transactions out of a block. If they include their own spam transactions, they gain nothing and incur a cost. However, since blocks can have fees resulting in hundreds of thousands of dollars, it would seem unlikely that miners incur a huge cost for not including transactions. A proposal was made by Nathan Parker to reward the fees of the current block to the miner of the next block (or X blocks after the current one) to discourage miners from flooding their own blocks with very high fee transactions. The solution would be implemented in a backwards-compatible fashion by enforcing miners to set an anyone-can-spend output in the coinbase transaction of the block. The miner of 100 blocks after the current one can add a secondary transaction spending this block's anyone-can-spend coinbase transaction and thus claim the funds. This way, the block reward of a block X is always transferred to the miner of block X+100. Implementing this would require a soft-fork. When the fork is activated, miners wouldn’t get any reward for mining blocks for a period of 100 blocks, which could cause the hashrate to drop temporarily. However, if the hashrate drops too much, blocks would take much longer to mine, and miners wouldn’t want that either since they want to go through those 100 reward-less blocks 2018-01-30T03:52:21+00:00 + In an email exchange, Gregory Maxwell and Eric Voskuil discussed the concept of block space ownership in Bitcoin. Voskuil argued that miners have the right to sell or not sell block space since it belongs to them. However, Maxwell pointed out that as users of Bitcoin, they collectively pay miners around $130k USD per block in the form of inflation for the job of complying with the Bitcoin protocol. While there is subsidy involved, miners still accept a net loss by purchasing space for themselves if they do not accept the highest fee transactions. Maxwell also dispelled the idea of "retaliation" against miners who purchase block space, stating that it is not possible or desirable to detect the source of transactions in a system without identity. He further explained that reducing returns to miners would simply result in a reduction of hash power and not a decrease in transaction costs.In an email conversation on January 29, 2018, Eric Voskuil argued that block space created by a miner is the property of the miner, which can be sold or not sold. However, this argument is weak given that Bitcoin users collectively pay miners around $130k USD per block as inflation for complying with the Bitcoin protocol. It is unclear whether miners have more right to this payment than Bitcoin users have to run software that invalidates the coinbase outputs of miners who do not comply with the protocol. Such retaliation could be targeted against non-compliant miners.In a discussion on the bitcoin-dev mailing list, Gregory Maxwell and Eric Voskuil debated the idea that miners gain an advantage by mining empty blocks or rejecting higher-fee transactions. While Voskuil argued that this was a myth, Maxwell suggested that there might be some truth to it, given that empty blocks are more conspicuous and could invite retaliation, especially with high levels of mining centralization. However, he also noted that dummy transactions are just as conspicuous, and underfilled blocks are produced without any apparent retaliation. Maxwell further argued that since block space created by a miner is the miner's property, it can be sold or not sold, without any harm to others.In a recent bitcoin-dev email thread, Eric Voskuil and an unknown source debunked the myth that miners have an advantage over those buying block space. Voskuil believes this idea is complete nonsense and even steel-manned it by arguing that empty blocks could invite retaliation due to high levels of mining centralization creating retaliation exposure. However, he points out that dummy transactions are hardly less conspicuous and many nodes log when blocks show up containing transactions they've never seen before. Furthermore, underfilled blocks are produced by Bitmain's Antpool without any retaliation forthcoming.The context involves a discussion among members of the bitcoin-dev mailing list regarding whether or not miners incur a cost by leaving transactions out of a block. Some members argue that miners do pay a cost by not being rewarded those fees, while others argue that this is not a question of cost but rather incentive compatibility. Additionally, there is debate about whether miners fill their blocks with transactions paying very high fees at no cost because they get the fees back themselves, and if so, how to discourage this behavior. One proposed solution is to reward the fees of the current block to the miner of the next block (or X blocks after the current one), which would discourage flooding blocks with fake transactions. However, there are concerns about the possible downside of this solution, such as a temporary drop in hashrate if miners power off their equipment during the period without rewards. Overall, the discussion revolves around the incentives and costs for miners in the bitcoin network.Miners are not rewarded with fees if they leave transactions out of a block. If they include their own spam transactions, they gain nothing and incur a cost. However, since blocks can have fees resulting in hundreds of thousands of dollars, it would seem unlikely that miners incur a huge cost for not including transactions. A proposal was made by Nathan Parker to reward the fees of the current block to the miner of the next block (or X blocks after the current one) to discourage miners from flooding their own blocks with very high fee transactions. The solution would be implemented in a backwards-compatible fashion by enforcing miners to set an anyone-can-spend output in the coinbase transaction of the block. The miner of 100 blocks after the current one can add a secondary transaction spending this block's anyone-can-spend coinbase transaction and thus claim the funds. This way, the block reward of a block X is always transferred to the miner of block X+100. Implementing this would require a soft-fork. When the fork is activated, miners wouldn’t get any reward for mining blocks for a period of 100 blocks, which could cause the hashrate to drop temporarily. However, if the hashrate drops too much, blocks would take much longer to mine, and miners wouldn’t want that either since they want to go through those 100 reward-less blocks - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Proposal-to-reduce-mining-power-bill.xml b/static/bitcoin-dev/Jan_2018/combined_Proposal-to-reduce-mining-power-bill.xml index 46b8b8e385..096a78f637 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Proposal-to-reduce-mining-power-bill.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Proposal-to-reduce-mining-power-bill.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Proposal to reduce mining power bill - 2023-08-01T22:28:59.921514+00:00 - - Natanael 2018-01-18 16:25:16+00:00 - - - Damian Williamson 2018-01-18 08:24:40+00:00 - - - Eric Voskuil 2018-01-18 05:22:47+00:00 - - - Enrique Arizón Benito 2018-01-17 22:34:11+00:00 - - - nullius 2018-01-16 00:10:38+00:00 - - - Enrique Arizón Benito 2018-01-15 22:47:54+00:00 - + 2025-09-26T15:43:55.805883+00:00 + python-feedgen + + + [bitcoin-dev] Proposal to reduce mining power bill Enrique Arizón Benito + 2018-01-15T22:47:00.000Z + + + nullius + 2018-01-16T00:10:00.000Z + + + Enrique Arizón Benito + 2018-01-17T22:34:00.000Z + + + Eric Voskuil + 2018-01-18T05:22:00.000Z + + + Damian Williamson + 2018-01-18T08:24:00.000Z + + + Natanael + 2018-01-18T16:25:00.000Z + + - python-feedgen + 2 Combined summary - Proposal to reduce mining power bill - 2023-08-01T22:28:59.921514+00:00 + 2025-09-26T15:43:55.806656+00:00 - The proposal aims to reduce the electricity cost of mining Bitcoin by introducing the concept of "next-coinbase" addresses and an algorithm that restricts the number of miners allowed to mine each block based on the availability of unspent next-coinbase addresses. The algorithm reduces the difficulty/power-bill by 1/2^N for each round, potentially reducing energy costs. However, concerns were raised about its potential impact on transaction-ordering security and susceptibility to attacks by large miners.The proposal suggests using a thread expiration system to prevent large miners from monopolizing the network. It also raises questions about N (the number of bits used to match next-coinbase addresses), how reorgs are handled, and how miner anonymity can be preserved. While the proposal may increase upfront investment for new miners, it could still lead to a reduction in energy costs.In addition to the proposal, there is a quote challenging the notion that "If you're not doing anything wrong, you have nothing to hide," stating that just because one has nothing to hide does not mean they should have to show everything. The context also includes a Segwit nested address and a PGP RSA key.The email thread discusses the proposed algorithm in detail. It introduces the concept of "spent" and "un-spent" next-coinbase addresses and proposes an expiring thread model to address issues with large miners raising the difficulty target. Discussions cover topics such as how N is determined, how reorgs are handled, how difficulty interacts with the algorithm, and how miner anonymity is preserved. Concerns are raised about potential mining centralization and the increased upfront investment required for new miners.Overall, the proposal aims to reduce power consumption in Bitcoin mining while ensuring network security and cooperation among miners. However, further investigation is needed to address the questions and concerns raised before implementation. 2018-01-18T16:25:16+00:00 + The proposal aims to reduce the electricity cost of mining Bitcoin by introducing the concept of "next-coinbase" addresses and an algorithm that restricts the number of miners allowed to mine each block based on the availability of unspent next-coinbase addresses. The algorithm reduces the difficulty/power-bill by 1/2^N for each round, potentially reducing energy costs. However, concerns were raised about its potential impact on transaction-ordering security and susceptibility to attacks by large miners.The proposal suggests using a thread expiration system to prevent large miners from monopolizing the network. It also raises questions about N (the number of bits used to match next-coinbase addresses), how reorgs are handled, and how miner anonymity can be preserved. While the proposal may increase upfront investment for new miners, it could still lead to a reduction in energy costs.In addition to the proposal, there is a quote challenging the notion that "If you're not doing anything wrong, you have nothing to hide," stating that just because one has nothing to hide does not mean they should have to show everything. The context also includes a Segwit nested address and a PGP RSA key.The email thread discusses the proposed algorithm in detail. It introduces the concept of "spent" and "un-spent" next-coinbase addresses and proposes an expiring thread model to address issues with large miners raising the difficulty target. Discussions cover topics such as how N is determined, how reorgs are handled, how difficulty interacts with the algorithm, and how miner anonymity is preserved. Concerns are raised about potential mining centralization and the increased upfront investment required for new miners.Overall, the proposal aims to reduce power consumption in Bitcoin mining while ensuring network security and cooperation among miners. However, further investigation is needed to address the questions and concerns raised before implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Raise-default-datacarriersize-to-220-byte-or-higher.xml b/static/bitcoin-dev/Jan_2018/combined_Raise-default-datacarriersize-to-220-byte-or-higher.xml index 42c94af922..226fa40222 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Raise-default-datacarriersize-to-220-byte-or-higher.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Raise-default-datacarriersize-to-220-byte-or-higher.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Raise default datacarriersize to 220 byte or higher - 2023-08-01T22:23:36.404755+00:00 - - mbde at bitwatch.co 2018-01-04 19:38:23+00:00 - - - mbde at bitwatch.co 2018-01-04 09:37:42+00:00 - + 2025-09-26T15:43:26.334614+00:00 + python-feedgen + + + [bitcoin-dev] Raise default datacarriersize to 220 byte or higher mbde + 2018-01-04T09:37:00.000Z + + + mbde + 2018-01-04T19:38:00.000Z + + - python-feedgen + 2 Combined summary - Raise default datacarriersize to 220 byte or higher - 2023-08-01T22:23:36.404755+00:00 + 2025-09-26T15:43:26.335070+00:00 - In a mailing list post, dexx suggests raising the default datacarriersize to 220 bytes or higher as a means to discourage the use of harmful methods for embedding data into the blockchain. Currently, methods such as P2SH and bare-multisig can be cheaper in terms of effective transaction size compared to using OP_RETURN scripts, which are the most common way of embedding data. However, both Omni and Counterparty, two major meta-protocols on top of Bitcoin, have already transitioned to using OP_RETURN for data embedding.Although token sends are typically done one by one with a single transaction, this places a heavy burden on the network when exchanges send out withdrawals. While there are solutions available for "multi-sends with multi-inputs," they require more space. To address this issue, dexx proposes raising the default datacarriersize to 220 bytes or higher. This would make OP_RETURN scripts the cheapest method for data embedding, potentially incentivizing their use and reducing the load on the network.During December 2017, there were approximately 210,000 Omni Layer transactions, with over 12,000 transactions occurring on peak days. It is assumed that Counterparty transactions have similar numbers. With these statistics in mind, it is likely that both protocols would benefit from additional payload space provided by an increase in the default datacarriersize.Dexx expresses their willingness to provide a pull request if there is positive feedback regarding the proposal. This indicates their commitment to implementing the suggested change if it is deemed favorable by the community. 2018-01-04T19:38:23+00:00 + In a mailing list post, dexx suggests raising the default datacarriersize to 220 bytes or higher as a means to discourage the use of harmful methods for embedding data into the blockchain. Currently, methods such as P2SH and bare-multisig can be cheaper in terms of effective transaction size compared to using OP_RETURN scripts, which are the most common way of embedding data. However, both Omni and Counterparty, two major meta-protocols on top of Bitcoin, have already transitioned to using OP_RETURN for data embedding.Although token sends are typically done one by one with a single transaction, this places a heavy burden on the network when exchanges send out withdrawals. While there are solutions available for "multi-sends with multi-inputs," they require more space. To address this issue, dexx proposes raising the default datacarriersize to 220 bytes or higher. This would make OP_RETURN scripts the cheapest method for data embedding, potentially incentivizing their use and reducing the load on the network.During December 2017, there were approximately 210,000 Omni Layer transactions, with over 12,000 transactions occurring on peak days. It is assumed that Counterparty transactions have similar numbers. With these statistics in mind, it is likely that both protocols would benefit from additional payload space provided by an increase in the default datacarriersize.Dexx expresses their willingness to provide a pull request if there is positive feedback regarding the proposal. This indicates their commitment to implementing the suggested change if it is deemed favorable by the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Satoshilabs-secret-shared-private-key-scheme.xml b/static/bitcoin-dev/Jan_2018/combined_Satoshilabs-secret-shared-private-key-scheme.xml index 41c9fadbd3..520e7c3d91 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Satoshilabs-secret-shared-private-key-scheme.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Satoshilabs-secret-shared-private-key-scheme.xml @@ -1,104 +1,155 @@ - + 2 Combined summary - Satoshilabs secret shared private key scheme - 2023-08-01T22:26:10.438341+00:00 - - Adam Back 2018-01-23 14:16:22+00:00 - - - Ondřej Vejpustek 2018-01-23 13:54:48+00:00 - - - Gregory Maxwell 2018-01-23 01:05:44+00:00 - - - Russell O'Connor 2018-01-22 19:21:14+00:00 - - - Ondřej Vejpustek 2018-01-22 15:00:25+00:00 - - - Gregory Maxwell 2018-01-18 18:58:14+00:00 - - - Ondřej Vejpustek 2018-01-18 16:59:09+00:00 - - - Gregory Maxwell 2018-01-18 14:34:24+00:00 - - - Ondřej Vejpustek 2018-01-18 13:50:41+00:00 - - - Matt Corallo 2018-01-18 05:00:28+00:00 - - - Gregory Maxwell 2018-01-17 15:36:25+00:00 - - - Gregory Maxwell 2018-01-17 15:31:44+00:00 - - - Russell O'Connor 2018-01-17 15:28:15+00:00 - - - Ondřej Vejpustek 2018-01-17 11:39:42+00:00 - - - Peter Todd 2018-01-12 09:50:58+00:00 - - - Pavol Rusnak 2018-01-11 09:55:08+00:00 - - - Gregory Maxwell 2018-01-10 23:47:23+00:00 - - - Pavol Rusnak 2018-01-10 20:28:10+00:00 - - - Russell O'Connor 2018-01-09 16:20:20+00:00 - - - Pavol Rusnak 2018-01-09 15:12:58+00:00 - - - jens 2018-01-09 12:44:56+00:00 - - - Peter Todd 2018-01-09 01:13:35+00:00 - - - Rhavar 2018-01-09 00:40:38+00:00 - - - Peter Todd 2018-01-09 00:37:25+00:00 - - - Gregory Maxwell 2018-01-08 23:47:02+00:00 - - - Ben Kloester 2018-01-08 22:26:17+00:00 - - - Peter Todd 2018-01-08 19:37:14+00:00 - - - Pavol Rusnak 2018-01-08 13:00:17+00:00 - - - Peter Todd 2018-01-08 12:45:06+00:00 - - - Pavol Rusnak 2018-01-08 12:39:20+00:00 - - - nullius 2018-01-08 06:33:44+00:00 - - - Gregory Maxwell 2018-01-08 04:22:43+00:00 - + 2025-09-26T15:43:03.317554+00:00 + python-feedgen + + + Gregory Maxwell + 2018-01-08T04:22:00.000Z + + + nullius + 2018-01-08T06:33:00.000Z + + + Pavol Rusnak + 2018-01-08T12:39:00.000Z + + + Peter Todd + 2018-01-08T12:45:00.000Z + + + Pavol Rusnak + 2018-01-08T13:00:00.000Z + + + Peter Todd + 2018-01-08T19:37:00.000Z + + + Ben Kloester + 2018-01-08T22:26:00.000Z + + + Gregory Maxwell + 2018-01-08T23:47:00.000Z + + + Peter Todd + 2018-01-09T00:37:00.000Z + + + Rhavar + 2018-01-09T00:40:00.000Z + + + Peter Todd + 2018-01-09T01:13:00.000Z + + + jens + 2018-01-09T12:44:00.000Z + + + Pavol Rusnak + 2018-01-09T15:12:00.000Z + + + Russell O'Connor + 2018-01-09T16:20:00.000Z + + + Pavol Rusnak + 2018-01-10T20:28:00.000Z + + + Gregory Maxwell + 2018-01-10T23:47:00.000Z + + + Pavol Rusnak + 2018-01-11T09:55:00.000Z + + + Peter Todd + 2018-01-12T09:50:00.000Z + + + [bitcoin-dev] Plausible Deniability (Re: Satoshilabs secret shared private key scheme) nullius + 2018-01-12T11:06:00.000Z + + + Damian Williamson + 2018-01-13T02:11:00.000Z + + + nullius + 2018-01-13T03:44:00.000Z + + + Peter Todd + 2018-01-13T06:11:00.000Z + + + [bitcoin-dev] Satoshilabs secret shared private key scheme Ondřej Vejpustek + 2018-01-17T11:39:00.000Z + + + Russell O'Connor + 2018-01-17T15:28:00.000Z + + + Gregory Maxwell + 2018-01-17T15:31:00.000Z + + + Gregory Maxwell + 2018-01-17T15:36:00.000Z + + + Matt Corallo + 2018-01-18T05:00:00.000Z + + + Ondřej Vejpustek + 2018-01-18T13:50:00.000Z + + + Gregory Maxwell + 2018-01-18T14:34:00.000Z + + + Ondřej Vejpustek + 2018-01-18T16:59:00.000Z + + + Gregory Maxwell + 2018-01-18T18:58:00.000Z + + + Ondřej Vejpustek + 2018-01-22T15:00:00.000Z + + + Russell O'Connor + 2018-01-22T19:21:00.000Z + + + Gregory Maxwell + 2018-01-23T01:05:00.000Z + + + Ondřej Vejpustek + 2018-01-23T13:54:00.000Z + + + Adam Back + 2018-01-23T14:16:00.000Z + + @@ -131,13 +182,13 @@ - python-feedgen + 2 Combined summary - Satoshilabs secret shared private key scheme - 2023-08-01T22:26:10.439332+00:00 + 2025-09-26T15:43:03.321404+00:00 - In the provided context, there are multiple discussions and email exchanges covering various cryptographic schemes and their security. The first discussion revolves around a scheme shared on the bitcointalk forum, comparing it to the Makwa hashing function and highlighting the drawbacks of both schemes. Another discussion focuses on using Galois Field multiplication to improve Bitcoin's signature scheme, raising concerns about security against partial share leakage attacks. The use of diffusion layers and Key Derivation Functions (KDFs) is debated in another conversation.The security of Shamir Secret Sharing (SSS) is discussed, emphasizing the importance of verifying the integrity of the scheme before relying on its security. There is also a conversation about generalizing a GF(256) sharing scheme and creating a test utility to determine its security. The similarity between SSS and RSA is debated, along with the use of CRCs and error-correcting codes in relation to redundancy and protection of shares.Another email conversation addresses the entropy argument and the precautionary principle based on Shannon's information theory. It highlights that low redundancy doesn't necessarily make plaintext more secure and discusses the advantages of error-correcting codes over hash functions.Additionally, concerns are raised about Trezor's "plausible deniability" scheme, pointing out potential issues with passphrases being used as evidence. The discussion on blind host-delegated KDFs for hardware wallets raises concerns about the inability to verify valid results. There are debates about using a 16-bit checksum based on sha2 and suggestions to use a 20-bit code instead. The weakness of the key derivation function in Trezor's plausible deniability feature is also discussed.The SLIP39 scheme is criticized for the possibility of an attacker reconstructing the seed and the lack of versioning in the specification. Concerns are also raised about the new standard for Shamir Secret Scheme Splitting, including interoperability, weak key derivation functions, and the checksum algorithm.Lastly, Gregory Maxwell expresses satisfaction with BIP 39 as a security measure for brainwallets and mentions working on a BIP 39 tool. However, concerns are raised about interoperability and versioning issues with the new standard for Shamir Secret Scheme Splitting, weak key derivation functions, and problematic checksum algorithms.It is important to note that despite these concerns, the scheme in question cannot be used as a brainwallet scheme. These discussions highlight the need for further research and development in cryptocurrency security. 2018-01-23T14:16:22+00:00 + In the provided context, there are multiple discussions and email exchanges covering various cryptographic schemes and their security. The first discussion revolves around a scheme shared on the bitcointalk forum, comparing it to the Makwa hashing function and highlighting the drawbacks of both schemes. Another discussion focuses on using Galois Field multiplication to improve Bitcoin's signature scheme, raising concerns about security against partial share leakage attacks. The use of diffusion layers and Key Derivation Functions (KDFs) is debated in another conversation.The security of Shamir Secret Sharing (SSS) is discussed, emphasizing the importance of verifying the integrity of the scheme before relying on its security. There is also a conversation about generalizing a GF(256) sharing scheme and creating a test utility to determine its security. The similarity between SSS and RSA is debated, along with the use of CRCs and error-correcting codes in relation to redundancy and protection of shares.Another email conversation addresses the entropy argument and the precautionary principle based on Shannon's information theory. It highlights that low redundancy doesn't necessarily make plaintext more secure and discusses the advantages of error-correcting codes over hash functions.Additionally, concerns are raised about Trezor's "plausible deniability" scheme, pointing out potential issues with passphrases being used as evidence. The discussion on blind host-delegated KDFs for hardware wallets raises concerns about the inability to verify valid results. There are debates about using a 16-bit checksum based on sha2 and suggestions to use a 20-bit code instead. The weakness of the key derivation function in Trezor's plausible deniability feature is also discussed.The SLIP39 scheme is criticized for the possibility of an attacker reconstructing the seed and the lack of versioning in the specification. Concerns are also raised about the new standard for Shamir Secret Scheme Splitting, including interoperability, weak key derivation functions, and the checksum algorithm.Lastly, Gregory Maxwell expresses satisfaction with BIP 39 as a security measure for brainwallets and mentions working on a BIP 39 tool. However, concerns are raised about interoperability and versioning issues with the new standard for Shamir Secret Scheme Splitting, weak key derivation functions, and problematic checksum algorithms.It is important to note that despite these concerns, the scheme in question cannot be used as a brainwallet scheme. These discussions highlight the need for further research and development in cryptocurrency security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_ScriptPubkey-consensus-translation.xml b/static/bitcoin-dev/Jan_2018/combined_ScriptPubkey-consensus-translation.xml index 9457a81628..e0177aba75 100644 --- a/static/bitcoin-dev/Jan_2018/combined_ScriptPubkey-consensus-translation.xml +++ b/static/bitcoin-dev/Jan_2018/combined_ScriptPubkey-consensus-translation.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - ScriptPubkey consensus translation - 2023-08-01T22:29:53.403462+00:00 - - Mark Friedenbach 2018-01-18 21:00:03+00:00 - - - CryptAxe 2018-01-18 19:56:41+00:00 - - - Gregory Maxwell 2018-01-18 19:30:09+00:00 - + 2025-09-26T15:43:11.680236+00:00 + python-feedgen + + + [bitcoin-dev] ScriptPubkey consensus translation Gregory Maxwell + 2018-01-18T19:30:00.000Z + + + CryptAxe + 2018-01-18T19:56:00.000Z + + + Mark Friedenbach + 2018-01-18T21:00:00.000Z + + - python-feedgen + 2 Combined summary - ScriptPubkey consensus translation - 2023-08-01T22:29:53.403462+00:00 + 2025-09-26T15:43:11.680771+00:00 - In a discussion about newer and more efficient pubkey types, Gregory Maxwell raises the question of whether these changes would make spending already existing outputs more efficient. He explains that the redemption instructions for existing outputs have already been set and don't incorporate these new features, so people are not forced to expose their funds to new cryptosystems whose security they may not trust. However, if a more efficient system were widely used and universally accepted, it might be plausible to include in a hardfork a consensus rule that lets someone spend scriptPubkey's matching specific templates as though they were an alternative template.The main limitation is that there is some risk of breaking the security assumptions of some complicated external protocol, but this concern can largely be addressed by ample communication in advance. Overall, people should be allowed to opt-in to systems and big changes like that, rather than having developers change what their outputs mean or open them up to new security risks on their behalf.When discussing newer and more efficient pubkey types, the question arises whether they will make the spending of already existing outputs more efficient. Unfortunately, the answer is no because the redemption instructions for existing outputs have already been set and don't incorporate these new features. However, this is good news as it means that no one is forced to expose their own funds to new cryptosystems whose security they may not trust.If sigagg is deployed, any cryptographic risk in it is borne by people who opted into using it. In the case where segwit-with-sigagg has been long deployed, widely used, and is more or less universally accepted as at least as good as an old P2PKH, it might be plausible to include in a hardfork a consensus rule that lets someone spend scriptPubkey's matching specific templates as though they were an alternative template.In other words, an idiomatic P2PKH or perhaps even a P2SH-multisig could be spent as though it used the analogous p2w-sigagg script. The main limitation is that there is some risk of breaking the security assumptions of some complicated external protocol, such as assuming that having a schnorr oracle for a key wouldn't let you spend coins connected to that key.However, this concern seems contrived, and it can largely be addressed by ample communication in advance. For instance, discouraging the creation of excessively fragile things like that, and finding out if any exist so they can be worked around. Overall, it appears that there are no other arguments missing from this discussion. 2018-01-18T21:00:03+00:00 + In a discussion about newer and more efficient pubkey types, Gregory Maxwell raises the question of whether these changes would make spending already existing outputs more efficient. He explains that the redemption instructions for existing outputs have already been set and don't incorporate these new features, so people are not forced to expose their funds to new cryptosystems whose security they may not trust. However, if a more efficient system were widely used and universally accepted, it might be plausible to include in a hardfork a consensus rule that lets someone spend scriptPubkey's matching specific templates as though they were an alternative template.The main limitation is that there is some risk of breaking the security assumptions of some complicated external protocol, but this concern can largely be addressed by ample communication in advance. Overall, people should be allowed to opt-in to systems and big changes like that, rather than having developers change what their outputs mean or open them up to new security risks on their behalf.When discussing newer and more efficient pubkey types, the question arises whether they will make the spending of already existing outputs more efficient. Unfortunately, the answer is no because the redemption instructions for existing outputs have already been set and don't incorporate these new features. However, this is good news as it means that no one is forced to expose their own funds to new cryptosystems whose security they may not trust.If sigagg is deployed, any cryptographic risk in it is borne by people who opted into using it. In the case where segwit-with-sigagg has been long deployed, widely used, and is more or less universally accepted as at least as good as an old P2PKH, it might be plausible to include in a hardfork a consensus rule that lets someone spend scriptPubkey's matching specific templates as though they were an alternative template.In other words, an idiomatic P2PKH or perhaps even a P2SH-multisig could be spent as though it used the analogous p2w-sigagg script. The main limitation is that there is some risk of breaking the security assumptions of some complicated external protocol, such as assuming that having a schnorr oracle for a key wouldn't let you spend coins connected to that key.However, this concern seems contrived, and it can largely be addressed by ample communication in advance. For instance, discouraging the creation of excessively fragile things like that, and finding out if any exist so they can be worked around. Overall, it appears that there are no other arguments missing from this discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Suggestion-to-remove-word-from-BIP39-English-wordlist.xml b/static/bitcoin-dev/Jan_2018/combined_Suggestion-to-remove-word-from-BIP39-English-wordlist.xml index bb4f0c8497..cd1d92892a 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Suggestion-to-remove-word-from-BIP39-English-wordlist.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Suggestion-to-remove-word-from-BIP39-English-wordlist.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Suggestion to remove word from BIP39 English wordlist - 2023-08-01T22:26:37.151195+00:00 + 2025-09-26T15:43:30.530757+00:00 + python-feedgen Alan Evans 2018-01-18 21:29:27+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Suggestion to remove word from BIP39 English wordlist - 2023-08-01T22:26:37.152195+00:00 + 2025-09-26T15:43:30.530918+00:00 - In a recent email exchange, Matthew Clancy disagreed with the notion that changing or removing a word in a mnemonic phrase is impossible. The argument against it is that the verification of an existing mnemonic requires the list, and altering one word would necessitate an alternative to BIP0039 or a complete change to a new set of 2048 English words. However, Clancy proposed a simple solution: selecting another word not on the 2048 list and agreeing by convention that it represents the same number as 'satoshi' or the original word. This alternative implementation seems feasible.The discussion on the Bitcoin development mailing list revolved around a suggestion to eliminate the word "satoshi" from the BIP39 English wordlist. The concern was that if a malicious third party discovers a word list resembling a seed, they could test every occurrence of "satoshi" to find a lead to a seed. Opponents argued that changing a word or list is impossible since the verification of an existing mnemonic relies on the list. To alter one word, an alternative to BIP0039 or a complete replacement of all the words with a new set of 2048 English words would be needed. One proposal was to use only the most common words that meet the necessary criteria.The suggestion to remove the word "satoshi" from the BIP39 English wordlist stems from the concern that it poses an unnecessary security risk. Malicious third parties could index any discovered word list and test each occurrence of "satoshi" to identify a bitcoin seed, making it easier to exploit. Some argue that the inclusion of the word does not necessarily increase the security threat, as any word list resembling a seed would be tested regardless. Nonetheless, there are supporters who believe removing "satoshi" would be a reasonable improvement. The linked wordlist provides further context.Responding to Ronald van der Meer's suggestion to remove "satoshi" from the BIP39 English wordlist, Weiwu Zhang states that the word's presence does not significantly impact the security threat. If a malicious third party finds a wordlist resembling a seed, they would test it as a bitcoin seed regardless of whether it contains "satoshi". Zhang highlights the risk lies in indexing and testing every occurrence of "satoshi" for a lead to a seed, which can be done by recycling services or through hacked accounts. Consequently, Zhang views the removal of "satoshi" from the wordlist as a reasonable improvement.A Bitcoin developer has proposed removing the word "satoshi" from the BIP39 English wordlist used for generating bitcoin wallet seeds. The suggestion arises from concerns that malicious third parties could exploit the inclusion of "satoshi" to identify a bitcoin seed. However, some argue that the security threat is minimal since determined attackers would attempt to use any word list as a seed, regardless of the presence of "satoshi". The real risk lies in attackers indexing and testing each occurrence of the word to gain access to a bitcoin wallet.Ronald van der Meer, an individual reviewing Bitcoin Improvement Proposals, has recommended removing the word "satoshi" from the BIP39 English wordlist. The objective is to make it less apparent that the phrase represents a bitcoin seed when discovered by malicious third parties. Ronald provides his email, website, Twitter account, and GPG key for secure communication. 2018-01-18T21:29:27+00:00 + In a recent email exchange, Matthew Clancy disagreed with the notion that changing or removing a word in a mnemonic phrase is impossible. The argument against it is that the verification of an existing mnemonic requires the list, and altering one word would necessitate an alternative to BIP0039 or a complete change to a new set of 2048 English words. However, Clancy proposed a simple solution: selecting another word not on the 2048 list and agreeing by convention that it represents the same number as 'satoshi' or the original word. This alternative implementation seems feasible.The discussion on the Bitcoin development mailing list revolved around a suggestion to eliminate the word "satoshi" from the BIP39 English wordlist. The concern was that if a malicious third party discovers a word list resembling a seed, they could test every occurrence of "satoshi" to find a lead to a seed. Opponents argued that changing a word or list is impossible since the verification of an existing mnemonic relies on the list. To alter one word, an alternative to BIP0039 or a complete replacement of all the words with a new set of 2048 English words would be needed. One proposal was to use only the most common words that meet the necessary criteria.The suggestion to remove the word "satoshi" from the BIP39 English wordlist stems from the concern that it poses an unnecessary security risk. Malicious third parties could index any discovered word list and test each occurrence of "satoshi" to identify a bitcoin seed, making it easier to exploit. Some argue that the inclusion of the word does not necessarily increase the security threat, as any word list resembling a seed would be tested regardless. Nonetheless, there are supporters who believe removing "satoshi" would be a reasonable improvement. The linked wordlist provides further context.Responding to Ronald van der Meer's suggestion to remove "satoshi" from the BIP39 English wordlist, Weiwu Zhang states that the word's presence does not significantly impact the security threat. If a malicious third party finds a wordlist resembling a seed, they would test it as a bitcoin seed regardless of whether it contains "satoshi". Zhang highlights the risk lies in indexing and testing every occurrence of "satoshi" for a lead to a seed, which can be done by recycling services or through hacked accounts. Consequently, Zhang views the removal of "satoshi" from the wordlist as a reasonable improvement.A Bitcoin developer has proposed removing the word "satoshi" from the BIP39 English wordlist used for generating bitcoin wallet seeds. The suggestion arises from concerns that malicious third parties could exploit the inclusion of "satoshi" to identify a bitcoin seed. However, some argue that the security threat is minimal since determined attackers would attempt to use any word list as a seed, regardless of the presence of "satoshi". The real risk lies in attackers indexing and testing each occurrence of the word to gain access to a bitcoin wallet.Ronald van der Meer, an individual reviewing Bitcoin Improvement Proposals, has recommended removing the word "satoshi" from the BIP39 English wordlist. The objective is to make it less apparent that the phrase represents a bitcoin seed when discovered by malicious third parties. Ronald provides his email, website, Twitter account, and GPG key for secure communication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Taproot-Privacy-preserving-switchable-scripting.xml b/static/bitcoin-dev/Jan_2018/combined_Taproot-Privacy-preserving-switchable-scripting.xml index bf7c677148..3731a4beb5 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Taproot-Privacy-preserving-switchable-scripting.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Taproot-Privacy-preserving-switchable-scripting.xml @@ -1,74 +1,111 @@ - + 2 Combined summary - Taproot: Privacy preserving switchable scripting - 2023-08-01T22:32:02.453935+00:00 - - ZmnSCPxj 2018-02-05 09:27:07+00:00 - - - Matt Corallo 2018-01-27 17:23:12+00:00 - - - Russell O'Connor 2018-01-27 17:07:25+00:00 - - - Gregory Maxwell 2018-01-26 21:34:39+00:00 - - - Natanael 2018-01-25 00:09:31+00:00 - - - Tim Ruffing 2018-01-24 23:22:05+00:00 - - - Natanael 2018-01-24 18:51:27+00:00 - - - Tim Ruffing 2018-01-24 15:38:11+00:00 - - - Natanael 2018-01-24 12:51:45+00:00 - - - Tim Ruffing 2018-01-24 09:28:20+00:00 - - - Andrew Poelstra 2018-01-24 01:52:57+00:00 - - - Gregory Maxwell 2018-01-23 22:45:06+00:00 - - - Anthony Towns 2018-01-23 22:22:29+00:00 - - - Gregory Maxwell 2018-01-23 21:38:13+00:00 - - - Matt Corallo 2018-01-23 21:23:21+00:00 - - - Greg Sanders 2018-01-23 15:43:59+00:00 - - - Mark Friedenbach 2018-01-23 14:39:37+00:00 - - - Gregory Maxwell 2018-01-23 13:15:38+00:00 - - - Anthony Towns 2018-01-23 06:44:19+00:00 - - - Matt Corallo 2018-01-23 02:51:51+00:00 - - - Chris Belcher 2018-01-23 01:55:07+00:00 - - - Gregory Maxwell 2018-01-23 00:30:06+00:00 - + 2025-09-26T15:43:57.928064+00:00 + python-feedgen + + + [bitcoin-dev] Taproot: Privacy preserving switchable scripting Gregory Maxwell + 2018-01-23T00:30:00.000Z + + + Chris Belcher + 2018-01-23T01:55:00.000Z + + + Matt Corallo + 2018-01-23T02:51:00.000Z + + + Anthony Towns + 2018-01-23T06:44:00.000Z + + + Gregory Maxwell + 2018-01-23T13:15:00.000Z + + + Mark Friedenbach + 2018-01-23T14:39:00.000Z + + + Greg Sanders + 2018-01-23T15:43:00.000Z + + + Matt Corallo + 2018-01-23T21:23:00.000Z + + + Gregory Maxwell + 2018-01-23T21:38:00.000Z + + + Anthony Towns + 2018-01-23T22:22:00.000Z + + + Gregory Maxwell + 2018-01-23T22:45:00.000Z + + + Andrew Poelstra + 2018-01-24T01:52:00.000Z + + + Tim Ruffing + 2018-01-24T09:28:00.000Z + + + Natanael + 2018-01-24T12:51:00.000Z + + + Tim Ruffing + 2018-01-24T15:38:00.000Z + + + Natanael + 2018-01-24T18:51:00.000Z + + + Tim Ruffing + 2018-01-24T23:22:00.000Z + + + Natanael + 2018-01-25T00:09:00.000Z + + + [bitcoin-dev] Recovery of old UTXOs in a post-quantum world Tim Ruffing + 2018-01-26T13:14:00.000Z + + + Gregory Maxwell + 2018-01-26T21:34:00.000Z + + + [bitcoin-dev] Taproot: Privacy preserving switchable scripting Russell O'Connor + 2018-01-27T17:07:00.000Z + + + Matt Corallo + 2018-01-27T17:23:00.000Z + + + [bitcoin-dev] Taproot: Privacy preserving switchable scripting ZmnSCPxj + 2018-02-05T09:27:00.000Z + + + [bitcoin-dev] Generalised taproot Anthony Towns + 2018-07-13T01:51:00.000Z + + + Pieter Wuille + 2018-10-24T02:22:00.000Z + + @@ -91,13 +128,13 @@ - python-feedgen + 2 Combined summary - Taproot: Privacy preserving switchable scripting - 2023-08-01T22:32:02.454936+00:00 + 2025-09-26T15:43:57.930886+00:00 - The bitcoin community is currently discussing the adoption of Taproot, a privacy-enhancing upgrade proposed by Gregory Maxwell. Taproot aims to make complex smart contract conditions indistinguishable from normal payments, increasing the anonymity set of smart contract users. Some members of the community argue that while Taproot may offer benefits, it is not optimal and suggest enabling features in a generic way first before creating specialized templates.The use of merkelized abstract syntax trees (MAST) in Bitcoin is also being discussed, with MAST providing efficiency and privacy benefits. Matt Corallo expresses concerns about the adoption of Taproot without support for a privacy-encouraging wrapper, emphasizing the importance of privacy in Bitcoin transactions.Anthony Towns questions whether paying directly to a pubkey instead of a pubkey hash is a step backwards in terms of resistance to quantum attacks against ECC. However, using hashing for quantum resistance may not be as effective as previously thought.The proposal for Taproot is generally well-received, as it allows for greater privacy and efficiency in smart contracts. It makes special cases indistinguishable from normal payments and supports any number of participants. Taproot enables the largest possible anonymity set for fixed-party smart contracts without requiring impractical techniques or extra rounds of interaction between participants. Merkelized ScriptPubKeys (MAST) are also gaining popularity due to their efficiency and privacy benefits. The use of a delegating CHECKSIG called Taproot allows for the creation of smart contracts that look like simple payments, without any overhead.Overall, the adoption of Taproot and MAST in Bitcoin has the potential to enhance privacy and efficiency in smart contract transactions. 2018-02-05T09:27:07+00:00 + The bitcoin community is currently discussing the adoption of Taproot, a privacy-enhancing upgrade proposed by Gregory Maxwell. Taproot aims to make complex smart contract conditions indistinguishable from normal payments, increasing the anonymity set of smart contract users. Some members of the community argue that while Taproot may offer benefits, it is not optimal and suggest enabling features in a generic way first before creating specialized templates.The use of merkelized abstract syntax trees (MAST) in Bitcoin is also being discussed, with MAST providing efficiency and privacy benefits. Matt Corallo expresses concerns about the adoption of Taproot without support for a privacy-encouraging wrapper, emphasizing the importance of privacy in Bitcoin transactions.Anthony Towns questions whether paying directly to a pubkey instead of a pubkey hash is a step backwards in terms of resistance to quantum attacks against ECC. However, using hashing for quantum resistance may not be as effective as previously thought.The proposal for Taproot is generally well-received, as it allows for greater privacy and efficiency in smart contracts. It makes special cases indistinguishable from normal payments and supports any number of participants. Taproot enables the largest possible anonymity set for fixed-party smart contracts without requiring impractical techniques or extra rounds of interaction between participants. Merkelized ScriptPubKeys (MAST) are also gaining popularity due to their efficiency and privacy benefits. The use of a delegating CHECKSIG called Taproot allows for the creation of smart contracts that look like simple payments, without any overhead.Overall, the adoption of Taproot and MAST in Bitcoin has the potential to enhance privacy and efficiency in smart contract transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Transaction-Merging-bip125-relaxation-.xml b/static/bitcoin-dev/Jan_2018/combined_Transaction-Merging-bip125-relaxation-.xml index b13ea9aad6..7aad9e7e3d 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Transaction-Merging-bip125-relaxation-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Transaction-Merging-bip125-relaxation-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Transaction Merging (bip125 relaxation) - 2023-08-01T22:30:43.321537+00:00 + 2025-09-26T15:43:32.644387+00:00 + python-feedgen Moral Agent 2018-01-28 18:08:33+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Transaction Merging (bip125 relaxation) - 2023-08-01T22:30:43.321537+00:00 + 2025-09-26T15:43:32.644563+00:00 - The Bitcoin-dev mailing list has been discussing the possibility of merging multiple unconfirmed transactions. The main objective is to combine these transactions into one, removing unnecessary inputs and change, while ensuring that the merged transaction pays an equal or higher fee compared to the original transactions. However, this is currently not feasible due to the bip125 rule, which requires a significant increase in the feerate for replacement transactions. Some participants in the discussion propose modifying this rule to allow retroactive transaction merging, as it is seen as more practical than appending existing transactions.One concern raised during the discussion is the potential for relay spam and the risk of pushing other users' transactions out of the mempool if transaction merging is allowed. To address this, some suggest that wallets and exchange APIs could collaborate to consolidate in-mempool transactions. Additionally, the complexity involved in implementing smarter types of merging is discussed, along with the need to relax the rules of BIP125 to support this approach if it can be done without introducing risks.The conversation also explores the difficulty of achieving no change when using an intelligent coin selection algorithm to pay for outputs. It is noted that most transactions involve change because inputs rarely match the exact payment amount requested. However, there are ways to optimize coin selection to avoid generating change. Developers Achow101 and Murch have created code for Bitcoin Core that implements an efficient algorithm for finding solutions in these cases.Another point of discussion is the incentive compatibility of BIP125. Some argue that accepting a replacement transaction with a lower fee rate in a competitive mempool may not be rational. Originally, Peter Todd proposed requiring only an increase in fee rate for replacement transactions, but later decided on both a feerate and absolute fee increase criteria for simplicity. Gregory Maxwell clarifies that BIP125 replacement does indeed require an increase in the fee rate, and the confusion arises from the use of the term "original transactions" when there should only be one transaction in the mempool at a time.Overall, the discussion highlights the challenges and feasibility of transaction merging in the mempool. There are varying opinions on modifying the rules of BIP125 to allow for retroactive transaction merging, with concerns about potential DoS vectors and the displacement of other transactions in the mempool. The difficulty of achieving no change with intelligent coin selection algorithms is also discussed, along with the need for a clear understanding of the incentive compatibility of BIP125 replacement. Currently, there is no direct method to track merged transactions when a replaced transaction gets confirmed after a new one has been created to achieve the same goal. Although merging multiple unconfirmed transactions could result in significant savings, finding a viable solution remains an ongoing challenge. 2018-01-28T18:08:33+00:00 + The Bitcoin-dev mailing list has been discussing the possibility of merging multiple unconfirmed transactions. The main objective is to combine these transactions into one, removing unnecessary inputs and change, while ensuring that the merged transaction pays an equal or higher fee compared to the original transactions. However, this is currently not feasible due to the bip125 rule, which requires a significant increase in the feerate for replacement transactions. Some participants in the discussion propose modifying this rule to allow retroactive transaction merging, as it is seen as more practical than appending existing transactions.One concern raised during the discussion is the potential for relay spam and the risk of pushing other users' transactions out of the mempool if transaction merging is allowed. To address this, some suggest that wallets and exchange APIs could collaborate to consolidate in-mempool transactions. Additionally, the complexity involved in implementing smarter types of merging is discussed, along with the need to relax the rules of BIP125 to support this approach if it can be done without introducing risks.The conversation also explores the difficulty of achieving no change when using an intelligent coin selection algorithm to pay for outputs. It is noted that most transactions involve change because inputs rarely match the exact payment amount requested. However, there are ways to optimize coin selection to avoid generating change. Developers Achow101 and Murch have created code for Bitcoin Core that implements an efficient algorithm for finding solutions in these cases.Another point of discussion is the incentive compatibility of BIP125. Some argue that accepting a replacement transaction with a lower fee rate in a competitive mempool may not be rational. Originally, Peter Todd proposed requiring only an increase in fee rate for replacement transactions, but later decided on both a feerate and absolute fee increase criteria for simplicity. Gregory Maxwell clarifies that BIP125 replacement does indeed require an increase in the fee rate, and the confusion arises from the use of the term "original transactions" when there should only be one transaction in the mempool at a time.Overall, the discussion highlights the challenges and feasibility of transaction merging in the mempool. There are varying opinions on modifying the rules of BIP125 to allow for retroactive transaction merging, with concerns about potential DoS vectors and the displacement of other transactions in the mempool. The difficulty of achieving no change with intelligent coin selection algorithms is also discussed, along with the need for a clear understanding of the incentive compatibility of BIP125 replacement. Currently, there is no direct method to track merged transactions when a replaced transaction gets confirmed after a new one has been created to achieve the same goal. Although merging multiple unconfirmed transactions could result in significant savings, finding a viable solution remains an ongoing challenge. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Update-links-use-ssl-variant-to-opensource-org-x-MIT-.xml b/static/bitcoin-dev/Jan_2018/combined_Update-links-use-ssl-variant-to-opensource-org-x-MIT-.xml index f952883349..eaf5aa9e2b 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Update-links-use-ssl-variant-to-opensource-org-x-MIT-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Update-links-use-ssl-variant-to-opensource-org-x-MIT-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Update links (use ssl-variant) to opensource.org/[..x..]MIT ? - 2023-08-01T22:23:48.284692+00:00 - - Felix Wolfsteller 2018-01-15 14:33:28+00:00 - - - Felix Wolfsteller 2018-01-04 10:08:08+00:00 - + 2025-09-26T15:43:43.118139+00:00 + python-feedgen + + + [bitcoin-dev] Update links (use ssl-variant) to opensource.org/[..x..]MIT ? Felix Wolfsteller + 2018-01-04T10:08:00.000Z + + + Felix Wolfsteller + 2018-01-15T14:33:00.000Z + + - python-feedgen + 2 Combined summary - Update links (use ssl-variant) to opensource.org/[..x..]MIT ? - 2023-08-01T22:23:48.285694+00:00 + 2025-09-26T15:43:43.118590+00:00 - Felix Wolfsteller expressed disappointment with the feedback he received off-list, acknowledging that the mailing list is intended for protocol-only discussions. He provided a link to track the progress of his proposal, which aims to update the copyright-header in source files by replacing HTTP with HTTPS where possible. To address this issue, he suggested creating an issue on Github, using the command 'sed -i' to modify relevant links, creating a pull request on Github, and then returning to the mailing list.The proposed change would impact several hundred files, potentially requiring an extension of the copyright year to 2018. Currently, most of the source files have a "default" copyright header that indicates the location of the MIT license. However, the provided link uses HTTP instead of HTTPS, resulting in a redirect to https://opensource.org/licenses/mit-license.php. The proposer believes that creating an issue on GitHub, using `sed -i` to update the links, creating a pull request, and seeking feedback from the mailing list would be the appropriate approach.To provide an example, Felix shared a header from a file in the Bitcoin codebase. This example can be viewed at https://github.com/bitcoin/bitcoin/blob/a9a49e6e7e8df13d80a6dc3245ce7ef041942e9b/src/consensus/merkle.cpp#L3. Although the proposer seeks prompt feedback, they express uncertainty about the cultural norms surrounding this process. 2018-01-15T14:33:28+00:00 + Felix Wolfsteller expressed disappointment with the feedback he received off-list, acknowledging that the mailing list is intended for protocol-only discussions. He provided a link to track the progress of his proposal, which aims to update the copyright-header in source files by replacing HTTP with HTTPS where possible. To address this issue, he suggested creating an issue on Github, using the command 'sed -i' to modify relevant links, creating a pull request on Github, and then returning to the mailing list.The proposed change would impact several hundred files, potentially requiring an extension of the copyright year to 2018. Currently, most of the source files have a "default" copyright header that indicates the location of the MIT license. However, the provided link uses HTTP instead of HTTPS, resulting in a redirect to https://opensource.org/licenses/mit-license.php. The proposer believes that creating an issue on GitHub, using `sed -i` to update the links, creating a pull request, and seeking feedback from the mailing list would be the appropriate approach.To provide an example, Felix shared a header from a file in the Bitcoin codebase. This example can be viewed at https://github.com/bitcoin/bitcoin/blob/a9a49e6e7e8df13d80a6dc3245ce7ef041942e9b/src/consensus/merkle.cpp#L3. Although the proposer seeks prompt feedback, they express uncertainty about the cultural norms surrounding this process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Upgrading-PoW-algorithm.xml b/static/bitcoin-dev/Jan_2018/combined_Upgrading-PoW-algorithm.xml index ce6a0c8432..3af6c3f688 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Upgrading-PoW-algorithm.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Upgrading-PoW-algorithm.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Upgrading PoW algorithm - 2023-08-01T22:29:34.336218+00:00 - - Glen Peterson 2018-01-21 15:29:26+00:00 - - - Melvin Carvalho 2018-01-20 18:36:09+00:00 - - - nullius 2018-01-20 06:30:37+00:00 - - - Jefferson Carpenter 2018-01-19 20:54:52+00:00 - - - Peter Todd 2018-01-18 16:36:44+00:00 - - - Jefferson Carpenter 2018-01-17 22:31:52+00:00 - + 2025-09-26T15:43:20.041608+00:00 + python-feedgen + + + [bitcoin-dev] Upgrading PoW algorithm Jefferson Carpenter + 2018-01-17T22:31:00.000Z + + + Peter Todd + 2018-01-18T16:36:00.000Z + + + Jefferson Carpenter + 2018-01-19T20:54:00.000Z + + + nullius + 2018-01-20T06:30:00.000Z + + + Melvin Carvalho + 2018-01-20T18:36:00.000Z + + + Glen Peterson + 2018-01-21T15:29:00.000Z + + - python-feedgen + 2 Combined summary - Upgrading PoW algorithm - 2023-08-01T22:29:34.336218+00:00 + 2025-09-26T15:43:20.042488+00:00 - Popular hashing algorithms typically last around 10-15 years before flaws are found, and SHA-256 is currently showing signs of aging. As cryptocurrencies and blockchains require cryptography updates every decade or so to maintain security, planning for future algorithm updates is crucial.A recent email exchange on the bitcoin-dev mailing list discussed Bitcoin's maximum difficulty, which according to Moore's law would be reached in about 400 years. This means that block time will decrease, causing blocks to be mined faster than photons can travel across the planet. This raises concerns about the future dominance of Bitcoin and the need to prepare for potential shifts towards other cryptocurrencies.To address this issue, the development team must evaluate trade-offs between algorithms and come to a consensus on the optimal solution. This involves examining working solutions, transferring them to BIPs (Bitcoin Improvement Proposals), creating code, testing it, and achieving consensus. The field of cryptocurrency is still relatively young, with ongoing research and development in areas such as migrating to a proof-of-work system supporting even higher difficulty levels.However, there are differing opinions on whether reaching Bitcoin's maximum difficulty within 400 years is scientifically possible. While some argue that Moore's law predicts this scenario, others point out that it would require computational power beyond human capabilities. Mathematical breakthroughs might improve preimage attacks on the SHA-256 algorithm, but performing such work is currently impossible for humans.One proposal to address Bitcoin's maximum difficulty is to fork off a blockchain that accepts blocks with less than max difficulty, creating a soft fork. Additionally, the difficulty field could be extended to represent a higher max difficulty under a different hashing function like SHA512, resulting in a hard fork. This blockchain would remain identical to Bitcoin until the difficulty becomes too high, at which point it diverges.Peter Todd, a member of the bitcoin-dev mailing list, disputed the notion of Bitcoin's difficulty being maxed out by Moore's Law within 400 years. He argued that if Moore's Law were to last that long, mining Bitcoin blocks would require unimaginable energy levels. Todd also highlighted the problem of the speed of light, stating that we would run out of energy in our 10-minute light radius. He considered this matter to be more suited for science fiction writers than the bitcoin-dev community.In conclusion, according to Moore's law, Bitcoin's difficulty is predicted to reach its maximum within 400 years. This raises concerns about block time decreasing and potential shifts in cryptocurrency dominance. While there are currently no distinct plans for migrating to a proof-of-work system supporting even higher difficulty levels, it is important to evaluate trade-offs and plan for the future to mitigate potential losses. 2018-01-21T15:29:26+00:00 + Popular hashing algorithms typically last around 10-15 years before flaws are found, and SHA-256 is currently showing signs of aging. As cryptocurrencies and blockchains require cryptography updates every decade or so to maintain security, planning for future algorithm updates is crucial.A recent email exchange on the bitcoin-dev mailing list discussed Bitcoin's maximum difficulty, which according to Moore's law would be reached in about 400 years. This means that block time will decrease, causing blocks to be mined faster than photons can travel across the planet. This raises concerns about the future dominance of Bitcoin and the need to prepare for potential shifts towards other cryptocurrencies.To address this issue, the development team must evaluate trade-offs between algorithms and come to a consensus on the optimal solution. This involves examining working solutions, transferring them to BIPs (Bitcoin Improvement Proposals), creating code, testing it, and achieving consensus. The field of cryptocurrency is still relatively young, with ongoing research and development in areas such as migrating to a proof-of-work system supporting even higher difficulty levels.However, there are differing opinions on whether reaching Bitcoin's maximum difficulty within 400 years is scientifically possible. While some argue that Moore's law predicts this scenario, others point out that it would require computational power beyond human capabilities. Mathematical breakthroughs might improve preimage attacks on the SHA-256 algorithm, but performing such work is currently impossible for humans.One proposal to address Bitcoin's maximum difficulty is to fork off a blockchain that accepts blocks with less than max difficulty, creating a soft fork. Additionally, the difficulty field could be extended to represent a higher max difficulty under a different hashing function like SHA512, resulting in a hard fork. This blockchain would remain identical to Bitcoin until the difficulty becomes too high, at which point it diverges.Peter Todd, a member of the bitcoin-dev mailing list, disputed the notion of Bitcoin's difficulty being maxed out by Moore's Law within 400 years. He argued that if Moore's Law were to last that long, mining Bitcoin blocks would require unimaginable energy levels. Todd also highlighted the problem of the speed of light, stating that we would run out of energy in our 10-minute light radius. He considered this matter to be more suited for science fiction writers than the bitcoin-dev community.In conclusion, according to Moore's law, Bitcoin's difficulty is predicted to reach its maximum within 400 years. This raises concerns about block time decreasing and potential shifts in cryptocurrency dominance. While there are currently no distinct plans for migrating to a proof-of-work system supporting even higher difficulty levels, it is important to evaluate trade-offs and plan for the future to mitigate potential losses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2018/combined_Why-is-deriving-public-key-from-the-signature-not-used-in-Segwit-.xml b/static/bitcoin-dev/Jan_2018/combined_Why-is-deriving-public-key-from-the-signature-not-used-in-Segwit-.xml index b285107c64..3e4ee764bb 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Why-is-deriving-public-key-from-the-signature-not-used-in-Segwit-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Why-is-deriving-public-key-from-the-signature-not-used-in-Segwit-.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Why is deriving public key from the signature not used in Segwit? - 2023-08-01T22:33:29.469748+00:00 - - Aymeric Vitte 2018-01-24 12:03:55+00:00 - - - Gregory Maxwell 2018-01-24 11:35:49+00:00 - - - Aymeric Vitte 2018-01-24 11:16:30+00:00 - - - Gregory Maxwell 2018-01-24 10:31:35+00:00 - - - Aymeric Vitte 2018-01-24 10:24:55+00:00 - - - Gregory Maxwell 2018-01-24 04:25:28+00:00 - - - Артём Литвинович 2018-01-24 03:50:10+00:00 - + 2025-09-26T15:43:17.950351+00:00 + python-feedgen + + + [bitcoin-dev] Why is deriving public key from the signature not used in Segwit? Артём Литвинович + 2018-01-24T03:50:00.000Z + + + Gregory Maxwell + 2018-01-24T04:25:00.000Z + + + Aymeric Vitte + 2018-01-24T10:24:00.000Z + + + Gregory Maxwell + 2018-01-24T10:31:00.000Z + + + Aymeric Vitte + 2018-01-24T11:16:00.000Z + + + Gregory Maxwell + 2018-01-24T11:35:00.000Z + + + Aymeric Vitte + 2018-01-24T12:03:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Why is deriving public key from the signature not used in Segwit? - 2023-08-01T22:33:29.469748+00:00 + 2025-09-26T15:43:17.951427+00:00 - In a conversation on January 24, 2018, Gregory Maxwell and Aymeric Vitte discussed the absence of a pubkey in a specific transaction on blockchain.info. Vitte had provided a link to the transaction's scriptsig, which lacked any pubkey. Maxwell explained that the pubkey is actually present in the scriptPubKey of vout 0 of another transaction that is being spent by the current transaction.Vitte then asked about the presence of pubkeys in standard p2pkh transactions, noting that this was not the case previously. However, there was no response to his question regarding the reason behind this change and when it was implemented. Maxwell responded by stating that such behavior never existed and suggested that Vitte might be mistaken.In another email discussion, a member of the bitcoin-dev mailing list questioned why public keys are still included in SegWit witnesses, even though they can be derived from signatures. Another member responded that leaving out public keys would slow down verification, be incompatible with batch validation, not save space if hashing isn't used, and could potentially be patent-encumbered. However, it was pointed out that public keys are now included in standard P2PKH transactions as well, whereas previously they were not. The original questioner asked for more information about what motivated this change and when it occurred.Артём Литвинович also questioned the rationale behind having both public keys and signatures in SegWit witness. They suggested that leaving out the public key would have saved 33 bytes per signature, as the public key can be derived from the signature and a quadrant byte. However, it was noted that this method is slow to verify and incompatible with batch validation. Additionally, it doesn't save space if hashing isn't used and could potentially be patent-encumbered.Overall, it appears that there are valid security, performance, and patent-related reasons for including both public keys and signatures in SegWit witness, although the specific rationale behind this decision is not explicitly stated in the provided context. 2018-01-24T12:03:55+00:00 + In a conversation on January 24, 2018, Gregory Maxwell and Aymeric Vitte discussed the absence of a pubkey in a specific transaction on blockchain.info. Vitte had provided a link to the transaction's scriptsig, which lacked any pubkey. Maxwell explained that the pubkey is actually present in the scriptPubKey of vout 0 of another transaction that is being spent by the current transaction.Vitte then asked about the presence of pubkeys in standard p2pkh transactions, noting that this was not the case previously. However, there was no response to his question regarding the reason behind this change and when it was implemented. Maxwell responded by stating that such behavior never existed and suggested that Vitte might be mistaken.In another email discussion, a member of the bitcoin-dev mailing list questioned why public keys are still included in SegWit witnesses, even though they can be derived from signatures. Another member responded that leaving out public keys would slow down verification, be incompatible with batch validation, not save space if hashing isn't used, and could potentially be patent-encumbered. However, it was pointed out that public keys are now included in standard P2PKH transactions as well, whereas previously they were not. The original questioner asked for more information about what motivated this change and when it occurred.Артём Литвинович also questioned the rationale behind having both public keys and signatures in SegWit witness. They suggested that leaving out the public key would have saved 33 bytes per signature, as the public key can be derived from the signature and a quadrant byte. However, it was noted that this method is slow to verify and incompatible with batch validation. Additionally, it doesn't save space if hashing isn't used and could potentially be patent-encumbered.Overall, it appears that there are valid security, performance, and patent-related reasons for including both public keys and signatures in SegWit witness, although the specific rationale behind this decision is not explicitly stated in the provided context. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_-BIP-Proposal-Simple-Proof-of-Reserves-Transactions.xml b/static/bitcoin-dev/Jan_2019/combined_-BIP-Proposal-Simple-Proof-of-Reserves-Transactions.xml index 040fbff84e..8814a1875e 100644 --- a/static/bitcoin-dev/Jan_2019/combined_-BIP-Proposal-Simple-Proof-of-Reserves-Transactions.xml +++ b/static/bitcoin-dev/Jan_2019/combined_-BIP-Proposal-Simple-Proof-of-Reserves-Transactions.xml @@ -1,23 +1,36 @@ - + 2 Combined summary - [BIP Proposal] Simple Proof-of-Reserves Transactions - 2023-08-02T00:26:06.910385+00:00 - - Luke Dashjr 2019-02-15 15:18:18+00:00 - - - Steven Roose 2019-01-29 22:03:04+00:00 - + 2025-09-26T15:42:12.777745+00:00 + python-feedgen + + + [bitcoin-dev] [BIP Proposal] Simple Proof-of-Reserves Transactions Steven Roose + 2019-01-29T22:03:00.000Z + + + Luke Dashjr + 2019-02-15T15:18:00.000Z + + + [bitcoin-dev] NIH warning (was Re: [BIP Proposal] Simple Proof-of-Reserves Transactions) Pavol Rusnak + 2019-02-16T16:49:00.000Z + + + William Casarin + 2019-02-17T18:00:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Simple Proof-of-Reserves Transactions - 2023-08-02T00:26:06.910385+00:00 + 2025-09-26T15:42:12.778365+00:00 - Recently, there was a discussion on the Bitcoin-developer mailing list regarding a proposed proof format that aims to combine multiple proofs and associated metadata in a standardized way. The format, specified in the Protocol Buffers format, is designed to ensure easy verification of proofs even when some of the UTXOs used in the proof are no longer unspent.However, one participant expressed concerns about the format's content, citing previous controversies surrounding its use in BIP70, which might hinder its adoption. Another participant highlighted the lack of sufficient information in the format and suggested the inclusion of a merkle proof.In a related development, a draft of a new Bitcoin Improvement Proposal (BIP) has been introduced, outlining a proposal for constructing proof-of-reserves transactions. The BIP seeks to establish a standard format for creating proofs, enabling the development of general proof-verification software and facilitating integration with existing wallet infrastructure.The motivation behind this proposal is to provide companies managing significant amounts of Bitcoin with a means to prove ownership over their funds without disclosing events publicly, thereby preventing substantial losses. The proposed proof format is designed to be flexible and compatible with existing systems, resembling regular Bitcoin transactions with slight adaptations.To package multiple proofs and relevant metadata, the proposal includes a file format based on Protocol Buffers. Additionally, an extension to BIP 174 PSBT format is suggested to aid signing devices in recognizing proof-of-reserve transactions. Interested individuals can find a proof-of-concept implementation of the PSBT extension in the rust-bitcoin project, along with a work-in-progress implementation for producing and verifying proofs in the described format. It's worth noting that although an invalid transaction cannot be proven by nodes, it may still be cached as a "transaction," occupying memory resources. 2019-02-15T15:18:18+00:00 + Recently, there was a discussion on the Bitcoin-developer mailing list regarding a proposed proof format that aims to combine multiple proofs and associated metadata in a standardized way. The format, specified in the Protocol Buffers format, is designed to ensure easy verification of proofs even when some of the UTXOs used in the proof are no longer unspent.However, one participant expressed concerns about the format's content, citing previous controversies surrounding its use in BIP70, which might hinder its adoption. Another participant highlighted the lack of sufficient information in the format and suggested the inclusion of a merkle proof.In a related development, a draft of a new Bitcoin Improvement Proposal (BIP) has been introduced, outlining a proposal for constructing proof-of-reserves transactions. The BIP seeks to establish a standard format for creating proofs, enabling the development of general proof-verification software and facilitating integration with existing wallet infrastructure.The motivation behind this proposal is to provide companies managing significant amounts of Bitcoin with a means to prove ownership over their funds without disclosing events publicly, thereby preventing substantial losses. The proposed proof format is designed to be flexible and compatible with existing systems, resembling regular Bitcoin transactions with slight adaptations.To package multiple proofs and relevant metadata, the proposal includes a file format based on Protocol Buffers. Additionally, an extension to BIP 174 PSBT format is suggested to aid signing devices in recognizing proof-of-reserve transactions. Interested individuals can find a proof-of-concept implementation of the PSBT extension in the rust-bitcoin project, along with a work-in-progress implementation for producing and verifying proofs in the described format. It's worth noting that although an invalid transaction cannot be proven by nodes, it may still be cached as a "transaction," occupying memory resources. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_BIP39-seeds.xml b/static/bitcoin-dev/Jan_2019/combined_BIP39-seeds.xml index d9e45be5a4..975b7b0c73 100644 --- a/static/bitcoin-dev/Jan_2019/combined_BIP39-seeds.xml +++ b/static/bitcoin-dev/Jan_2019/combined_BIP39-seeds.xml @@ -1,50 +1,23 @@ - + 2 Combined summary - BIP39 seeds - 2023-08-02T00:22:41.587136+00:00 - - Aymeric Vitte 2019-01-04 00:02:35+00:00 - - - James MacWhyte 2019-01-02 18:06:08+00:00 - - - Aymeric Vitte 2019-01-01 19:44:57+00:00 - - - Alan Evans 2018-12-31 16:52:24+00:00 - - - Aymeric Vitte 2018-12-27 11:04:18+00:00 - - - James MacWhyte 2018-12-26 18:54:25+00:00 - - - Aymeric Vitte 2018-12-26 11:33:27+00:00 - - - James MacWhyte 2018-12-25 00:30:26+00:00 - - - Tiago Romagnani Silveira 2018-12-24 14:58:43+00:00 - - - Aymeric Vitte 2018-12-23 22:41:00+00:00 - - - Jameson Lopp 2018-12-23 21:08:13+00:00 - - - Eric Scrivner 2018-12-23 20:55:31+00:00 - - - Pavol Rusnak 2018-12-23 18:46:12+00:00 - - - Aymeric Vitte 2018-12-21 23:58:04+00:00 - + 2025-09-26T15:42:08.563945+00:00 + python-feedgen + + + Aymeric Vitte + 2019-01-01T19:44:00.000Z + + + James MacWhyte + 2019-01-02T18:06:00.000Z + + + Aymeric Vitte + 2019-01-04T00:02:00.000Z + + @@ -59,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP39 seeds - 2023-08-02T00:22:41.587136+00:00 + 2025-09-26T15:42:08.564463+00:00 - In a recent online forum post, an individual raised an intriguing question regarding the probability of obtaining a "valid" BIP39 seed from randomly selected words from a 2048 word dictionary. The author expresses surprise at the results and speculates about potential use cases for this information. Curious to know if this topic has been discussed before, they reach out to the community for insights.To support their query, the author includes several links to relevant websites related to Bitcoin and Zcash wallets. These websites offer valuable resources for managing transactions and ensuring privacy. Furthermore, the author shares links to GitHub repositories for various projects such as node-Tor, torrent-live, and dynamic blocklists. These repositories likely provide useful tools and software related to the aforementioned cryptocurrencies.By including these links, the author seeks to foster a comprehensive discussion around the probability of generating a valid BIP39 seed and potential applications for this knowledge. This demonstrates their eagerness to engage with the community and further explore this intriguing subject matter. 2019-01-04T00:02:35+00:00 + In a recent online forum post, an individual raised an intriguing question regarding the probability of obtaining a "valid" BIP39 seed from randomly selected words from a 2048 word dictionary. The author expresses surprise at the results and speculates about potential use cases for this information. Curious to know if this topic has been discussed before, they reach out to the community for insights.To support their query, the author includes several links to relevant websites related to Bitcoin and Zcash wallets. These websites offer valuable resources for managing transactions and ensuring privacy. Furthermore, the author shares links to GitHub repositories for various projects such as node-Tor, torrent-live, and dynamic blocklists. These repositories likely provide useful tools and software related to the aforementioned cryptocurrencies.By including these links, the author seeks to foster a comprehensive discussion around the probability of generating a valid BIP39 seed and potential applications for this knowledge. This demonstrates their eagerness to engage with the community and further explore this intriguing subject matter. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml b/static/bitcoin-dev/Jan_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml index ba0ee494d2..d6b950a938 100644 --- a/static/bitcoin-dev/Jan_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml +++ b/static/bitcoin-dev/Jan_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml @@ -1,65 +1,63 @@ - + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 - - Johan Torås Halseth 2019-10-30 07:22:53+00:00 - - - David A. Harding 2019-10-28 17:14:38+00:00 - - - Johan Torås Halseth 2019-10-28 09:45:39+00:00 - - - David A. Harding 2019-10-27 22:54:02+00:00 - - - Jeremy 2019-10-27 19:13:09+00:00 - - - Matt Corallo 2019-10-25 17:30:41+00:00 - - - Johan Torås Halseth 2019-10-25 07:05:15+00:00 - - - Matt Corallo 2019-10-24 21:25:14+00:00 - - - Johan Torås Halseth 2019-10-24 13:49:09+00:00 - - - Rusty Russell 2019-02-13 04:22:39+00:00 - - - Matt Corallo 2019-01-08 14:46:45+00:00 - - - Rusty Russell 2019-01-08 05:50:20+00:00 - - - Matt Corallo 2019-01-07 15:18:52+00:00 - - - Rusty Russell 2018-12-04 03:33:53+00:00 - - - ZmnSCPxj 2018-12-03 04:16:10+00:00 - - - Bob McElrath 2018-12-02 15:08:39+00:00 - - - Matt Corallo 2018-11-30 19:33:56+00:00 - - - Russell O'Connor 2018-11-30 17:38:04+00:00 - - - Matt Corallo 2018-11-29 19:37:54+00:00 - + 2025-09-26T15:42:04.351246+00:00 + python-feedgen + + + Matt Corallo + 2019-01-07T15:18:00.000Z + + + Rusty Russell + 2019-01-08T05:50:00.000Z + + + Matt Corallo + 2019-01-08T14:46:00.000Z + + + Rusty Russell + 2019-02-13T04:22:00.000Z + + + Johan Torås Halseth + 2019-10-24T13:49:00.000Z + + + Matt Corallo + 2019-10-24T21:25:00.000Z + + + Johan Torås Halseth + 2019-10-25T07:05:00.000Z + + + Matt Corallo + 2019-10-25T17:30:00.000Z + + + Jeremy + 2019-10-27T19:13:00.000Z + + + David A. Harding + 2019-10-27T22:54:00.000Z + + + Johan Torås Halseth + 2019-10-28T09:45:00.000Z + + + David A. Harding + 2019-10-28T17:14:00.000Z + + + Johan Torås Halseth + 2019-10-30T07:22:00.000Z + + @@ -79,13 +77,13 @@ - python-feedgen + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 + 2025-09-26T15:42:04.352736+00:00 - In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly 2019-10-30T07:22:53+00:00 + In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_Contribution.xml b/static/bitcoin-dev/Jan_2019/combined_Contribution.xml index 0b147f9d9c..57f76b9f36 100644 --- a/static/bitcoin-dev/Jan_2019/combined_Contribution.xml +++ b/static/bitcoin-dev/Jan_2019/combined_Contribution.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Contribution - 2023-08-02T00:26:28.110022+00:00 - - Marco Falke 2019-01-30 16:29:05+00:00 - - - Antoniy Shumanov 2019-01-30 14:24:21+00:00 - + 2025-09-26T15:42:19.052660+00:00 + python-feedgen + + + [bitcoin-dev] Contribution Antoniy Shumanov + 2019-01-30T14:24:00.000Z + + + Marco Falke + 2019-01-30T16:29:00.000Z + + - python-feedgen + 2 Combined summary - Contribution - 2023-08-02T00:26:28.110022+00:00 + 2025-09-26T15:42:19.053051+00:00 - The Bitcoin protocol development mailing list is specifically intended for discussions related to the development of the Bitcoin protocol. Interested individuals can subscribe to this mailing list through the Linux Foundation website. For those interested in discussing code changes to Bitcoin Core, there is a separate mailing list dedicated to that purpose. Additionally, individuals can directly submit their changes to the Bitcoin repository on GitHub.In the context provided, the person submitting the information is an employee of lbry.io and is interested in contributing to Bitcoin's core. They are seeking the opinions of the Bitcoin development team regarding the implementation of base_blob and/or base_uint derived from std::array. This implementation would enable move semantics. The individual also mentions concerns with acquiring and releasing recursive mutex in a loop, as illustrated in minig.cpp. The code snippet demonstrates a loop that creates a new block and subsequently processes it. 2019-01-30T16:29:05+00:00 + The Bitcoin protocol development mailing list is specifically intended for discussions related to the development of the Bitcoin protocol. Interested individuals can subscribe to this mailing list through the Linux Foundation website. For those interested in discussing code changes to Bitcoin Core, there is a separate mailing list dedicated to that purpose. Additionally, individuals can directly submit their changes to the Bitcoin repository on GitHub.In the context provided, the person submitting the information is an employee of lbry.io and is interested in contributing to Bitcoin's core. They are seeking the opinions of the Bitcoin development team regarding the implementation of base_blob and/or base_uint derived from std::array. This implementation would enable move semantics. The individual also mentions concerns with acquiring and releasing recursive mutex in a loop, as illustrated in minig.cpp. The code snippet demonstrates a loop that creates a new block and subsequently processes it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_Create-a-BIP-to-implement-Confidential-Transactions-in-Bitcoin-Core.xml b/static/bitcoin-dev/Jan_2019/combined_Create-a-BIP-to-implement-Confidential-Transactions-in-Bitcoin-Core.xml index 75d7ccc2c3..66275fe901 100644 --- a/static/bitcoin-dev/Jan_2019/combined_Create-a-BIP-to-implement-Confidential-Transactions-in-Bitcoin-Core.xml +++ b/static/bitcoin-dev/Jan_2019/combined_Create-a-BIP-to-implement-Confidential-Transactions-in-Bitcoin-Core.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Create a BIP to implement Confidential Transactions in Bitcoin Core - 2023-08-02T00:23:44.403047+00:00 - - ZmnSCPxj 2019-01-02 13:39:57+00:00 - - - Kenshiro [] 2018-12-29 11:56:08+00:00 - - - SomberNight 2018-12-28 21:41:51+00:00 - - - Kenshiro [] 2018-12-27 20:15:19+00:00 - + 2025-09-26T15:42:21.145415+00:00 + python-feedgen + + + [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core Kenshiro [] + 2018-12-27T20:15:00.000Z + + + SomberNight + 2018-12-28T21:41:00.000Z + + + Kenshiro [] + 2018-12-29T11:56:00.000Z + + + ZmnSCPxj + 2019-01-02T13:39:00.000Z + + - python-feedgen + 2 Combined summary - Create a BIP to implement Confidential Transactions in Bitcoin Core - 2023-08-02T00:23:44.403047+00:00 + 2025-09-26T15:42:21.146066+00:00 - In an email to the bitcoin-dev mailing list, a user named Kenshiro has requested the creation of a Bitcoin Improvement Proposal (BIP) to implement Confidential Transactions (CT) in Bitcoin Core. Kenshiro believes that CT would provide privacy and fungibility for normal users. They suggest that if the CT transaction size is three times larger than a regular transaction, the block size could also be increased by three times or keep the current block size and make CT transactions optional.However, a recipient of the email, known as SomberNight, disagrees with the idea of requesting the creation of a BIP to implement CT in Bitcoin Core. SomberNight explains that instead of making a request, one should directly create a BIP proposal. They express doubts about achieving consensus for CT implementation in Bitcoin, citing concerns about computational binding and the potential for undetectable inflation. SomberNight references section 4.6 of the Bulletproofs paper, which states that breaking the binding property of the commitment scheme or soundness of the proof system could lead to the generation of coins out of thin air, rendering the currency useless. They also mention the uncertainty surrounding the existence of quantum computers and their potential impact on range proofs for confidential transactions. SomberNight provides a link to the Bulletproofs paper for further reference.The user who suggested CT implementation highlights its successful implementation in Grin and Monero, indicating its maturity for adoption in Bitcoin. They argue that increasing privacy for normal users and ensuring fungibility are key advantages of CT. However, there is no mention of whether the user agrees or disagrees with SomberNight's concerns about computational binding and undetectable inflation. The user proposes either increasing the block size by three times if the CT transaction size is three times larger or keeping the current block size and making CT transactions optional.Overall, there seems to be a difference of opinion regarding the implementation of Confidential Transactions in Bitcoin Core, with one party requesting the creation of a BIP while the other expresses doubts about achieving consensus and raises concerns about potential vulnerabilities. 2019-01-02T13:39:57+00:00 + In an email to the bitcoin-dev mailing list, a user named Kenshiro has requested the creation of a Bitcoin Improvement Proposal (BIP) to implement Confidential Transactions (CT) in Bitcoin Core. Kenshiro believes that CT would provide privacy and fungibility for normal users. They suggest that if the CT transaction size is three times larger than a regular transaction, the block size could also be increased by three times or keep the current block size and make CT transactions optional.However, a recipient of the email, known as SomberNight, disagrees with the idea of requesting the creation of a BIP to implement CT in Bitcoin Core. SomberNight explains that instead of making a request, one should directly create a BIP proposal. They express doubts about achieving consensus for CT implementation in Bitcoin, citing concerns about computational binding and the potential for undetectable inflation. SomberNight references section 4.6 of the Bulletproofs paper, which states that breaking the binding property of the commitment scheme or soundness of the proof system could lead to the generation of coins out of thin air, rendering the currency useless. They also mention the uncertainty surrounding the existence of quantum computers and their potential impact on range proofs for confidential transactions. SomberNight provides a link to the Bulletproofs paper for further reference.The user who suggested CT implementation highlights its successful implementation in Grin and Monero, indicating its maturity for adoption in Bitcoin. They argue that increasing privacy for normal users and ensuring fungibility are key advantages of CT. However, there is no mention of whether the user agrees or disagrees with SomberNight's concerns about computational binding and undetectable inflation. The user proposes either increasing the block size by three times if the CT transaction size is three times larger or keeping the current block size and making CT transactions optional.Overall, there seems to be a difference of opinion regarding the implementation of Confidential Transactions in Bitcoin Core, with one party requesting the creation of a BIP while the other expresses doubts about achieving consensus and raises concerns about potential vulnerabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_Predicate-Tree-in-ZkVM-a-variant-of-Taproot-G-root.xml b/static/bitcoin-dev/Jan_2019/combined_Predicate-Tree-in-ZkVM-a-variant-of-Taproot-G-root.xml index 5776f29d3b..5fe1677592 100644 --- a/static/bitcoin-dev/Jan_2019/combined_Predicate-Tree-in-ZkVM-a-variant-of-Taproot-G-root.xml +++ b/static/bitcoin-dev/Jan_2019/combined_Predicate-Tree-in-ZkVM-a-variant-of-Taproot-G-root.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Predicate Tree in ZkVM: a variant of Taproot/G'root - 2023-08-02T00:26:42.501283+00:00 - - Oleg Andreev 2019-02-01 17:56:49+00:00 - - - Oleg Andreev 2019-01-31 23:44:43+00:00 - + 2025-09-26T15:42:16.962690+00:00 + python-feedgen + + + [bitcoin-dev] Predicate Tree in ZkVM: a variant of Taproot/G'root Oleg Andreev + 2019-01-31T23:44:00.000Z + + + Oleg Andreev + 2019-02-01T17:56:00.000Z + + - python-feedgen + 2 Combined summary - Predicate Tree in ZkVM: a variant of Taproot/G'root - 2023-08-02T00:26:42.501283+00:00 + 2025-09-26T15:42:16.963114+00:00 - ZkVM is a blockchain virtual machine that offers multi-asset transfers and zero-knowledge programmable constraints. It introduces the concept of Predicate Trees, which are a variant of Taproot and G'root. The Predicate Tree is represented by a single group element and can be satisfied in multiple ways, unlocking its contents. ZkVM provides four instructions to use the predicate trees: signtx, call, left/right, and delegate.The signtx instruction verifies the signature over the transaction ID, treating the predicate as a public key. The call instruction reveals and executes a pre-arranged program, while the delegate instruction allows choosing the program later, which can be signed with a pre-arranged public key. The left and right instructions replace the contract's predicate with one of the sub-predicates in a disjunction.To optimize performance, ZkVM defers all point operations, including signature checks, disjunction proofs, and program commitment proofs. These deferred operations are verified in a batch after the VM execution is complete, resulting in significant savings. Additionally, ZkVM uses a single aggregated signature for the entire transaction instead of accepting individual signatures.One notable feature of ZkVM is the absence of dynamic branching based on expensive operation outcomes. Signature checks and predicate tree traversals must unconditionally succeed, making program execution (excluding ECC ops) fast and proportional to the program length. This approach provides an accurate measurement of the validation cost based on the collected ECC ops and the constraint system proof blob included with the transaction.It's worth mentioning that the upstream protocol, also known as "blockchain rules," can impose soft or hard caps on program length and the number of ECC operations. This limitation is similar to the restriction on signature checks per block in Bitcoin. Overall, ZkVM offers a powerful and efficient solution for executing transactions with programmable constraints in a blockchain environment. 2019-02-01T17:56:49+00:00 + ZkVM is a blockchain virtual machine that offers multi-asset transfers and zero-knowledge programmable constraints. It introduces the concept of Predicate Trees, which are a variant of Taproot and G'root. The Predicate Tree is represented by a single group element and can be satisfied in multiple ways, unlocking its contents. ZkVM provides four instructions to use the predicate trees: signtx, call, left/right, and delegate.The signtx instruction verifies the signature over the transaction ID, treating the predicate as a public key. The call instruction reveals and executes a pre-arranged program, while the delegate instruction allows choosing the program later, which can be signed with a pre-arranged public key. The left and right instructions replace the contract's predicate with one of the sub-predicates in a disjunction.To optimize performance, ZkVM defers all point operations, including signature checks, disjunction proofs, and program commitment proofs. These deferred operations are verified in a batch after the VM execution is complete, resulting in significant savings. Additionally, ZkVM uses a single aggregated signature for the entire transaction instead of accepting individual signatures.One notable feature of ZkVM is the absence of dynamic branching based on expensive operation outcomes. Signature checks and predicate tree traversals must unconditionally succeed, making program execution (excluding ECC ops) fast and proportional to the program length. This approach provides an accurate measurement of the validation cost based on the collected ECC ops and the constraint system proof blob included with the transaction.It's worth mentioning that the upstream protocol, also known as "blockchain rules," can impose soft or hard caps on program length and the number of ECC operations. This limitation is similar to the restriction on signature checks per block in Bitcoin. Overall, ZkVM offers a powerful and efficient solution for executing transactions with programmable constraints in a blockchain environment. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_Proof-of-Stake-Bitcoin-Sidechains.xml b/static/bitcoin-dev/Jan_2019/combined_Proof-of-Stake-Bitcoin-Sidechains.xml index a93d4ee682..db9408e2b5 100644 --- a/static/bitcoin-dev/Jan_2019/combined_Proof-of-Stake-Bitcoin-Sidechains.xml +++ b/static/bitcoin-dev/Jan_2019/combined_Proof-of-Stake-Bitcoin-Sidechains.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Proof-of-Stake Bitcoin Sidechains - 2023-08-02T00:24:58.034506+00:00 - - ZmnSCPxj 2019-02-01 09:19:00+00:00 - - - ZmnSCPxj 2019-01-25 05:33:37+00:00 - - - Peter Todd 2019-01-25 00:16:30+00:00 - - - Matt Bell 2019-01-24 18:46:11+00:00 - - - ZmnSCPxj 2019-01-24 10:03:25+00:00 - - - Dr Adam Back 2019-01-22 20:22:36+00:00 - - - Dustin Dettmer 2019-01-22 20:03:06+00:00 - - - Dustin Dettmer 2019-01-22 16:33:23+00:00 - - - Satoshin 2019-01-22 14:58:25+00:00 - - - ZmnSCPxj 2019-01-22 09:19:27+00:00 - - - Matt Bell 2019-01-21 18:47:13+00:00 - - - ZmnSCPxj 2019-01-20 02:06:08+00:00 - - - Matt Bell 2019-01-19 05:35:43+00:00 - - - ZmnSCPxj 2019-01-19 01:42:47+00:00 - - - Matt Bell 2019-01-18 22:59:35+00:00 - + 2025-09-26T15:42:14.870877+00:00 + python-feedgen + + + [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains Matt Bell + 2019-01-18T22:59:00.000Z + + + ZmnSCPxj + 2019-01-19T01:42:00.000Z + + + Matt Bell + 2019-01-19T05:35:00.000Z + + + ZmnSCPxj + 2019-01-20T02:06:00.000Z + + + Matt Bell + 2019-01-21T18:47:00.000Z + + + ZmnSCPxj + 2019-01-22T09:19:00.000Z + + + Satoshin + 2019-01-22T14:58:00.000Z + + + Dustin Dettmer + 2019-01-22T16:33:00.000Z + + + Dustin Dettmer + 2019-01-22T20:03:00.000Z + + + Dr Adam Back + 2019-01-22T20:22:00.000Z + + + ZmnSCPxj + 2019-01-24T10:03:00.000Z + + + Matt Bell + 2019-01-24T18:46:00.000Z + + + Peter Todd + 2019-01-25T00:16:00.000Z + + + ZmnSCPxj + 2019-01-25T05:33:00.000Z + + + ZmnSCPxj + 2019-02-01T09:19:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Proof-of-Stake Bitcoin Sidechains - 2023-08-02T00:24:58.034506+00:00 + 2025-09-26T15:42:14.872575+00:00 - In a recent discussion on the bitcoin-dev mailing list, ZmnSCPxj proposed a design for a proof-of-mainstake sidechain without any modifications to the Bitcoin mainchain. The writer suggests embedding sidechain block headers on the mainchain by spending the previous transaction, requiring authorization from the sufficient signatory set of stakers. Mainchain-to-sidechain requests are defined as indications that a mainchain coin owner wants to stake or transfer coins to the sidechain. The sidechain-to-mainchain withdrawals are left up to the sidechain to define.The writer also discusses the possibility of a revealed private key for time-locked funds creating a race to spend and suggests that races could be won by bidding up fees if Bitcoin had implemented RBF properly. The context further explores the security features of staking in sidechains, where miners can claim the stake themselves due to the public knowledge of the private key. However, it becomes unlikely for the staker to win unless they possess significant mining hash power. The integrity of the sidechain is proportional to the attacker's share of the Bitcoin hashrate. The storage of Bitcoin moved to the sidechain can be stolen if 67% of the stakers collude.A discussion on the bitcoin-dev mailing list suggests using fixed R values derived through standard hierarchical derivation to prevent multiple signatures in Bitcoin sidechains. The staking pubkey would be revealed as `staking_pubkey = P + hash(P || parent_R) * G`, with the specific R value obtained from hierarchical derivation using parent_R and the blockheight as an index. The potential downsides and impact on blockweight are still unclear.In a separate thread, the discussion focuses on Matt Bell's design for Bitcoin sidechains using the Tendermint BFT consensus protocol. The design is similar to Blockstream's Liquid sidechain and seeks feedback from the community. The source of voting power for the sidechain network is a topic of debate, with suggestions including time-locked Bitcoin and UTXOs on the Bitcoin blockchain. ZmnSCPxj proposes using fixed R values to prevent multiple signatures and introduces the concept of "mainstake," where UTXOs on the Bitcoin blockchain are used as the source of stake for voting power.In an email sent to Matt Bell via Bitcoin-dev, ZmnSCPxj proposed an idea called "mainstake," which involves using UTXOs on the Bitcoin blockchain as stakes for voting power. This approach is seen as more secure than having a blockchain with its own token that is self-attesting. The same script proposed by Bell for sidechains could be used for mainstake. Bell, who has been working on a design for Bitcoin sidechains using the Tendermint BFT consensus protocol, welcomes feedback about improvements or critical flaws in his design. The Tendermint consensus is commonly used to build proof-of-stake networks and is similar to Blockstream's Liquid sidechain, known for its "strong federation" consensus.The sidechain network may accept potential stakers on the mainchain if they prove the existence of a mainchain transaction. The value of this output would then be used as the weight of the vote of that stake. The designer acknowledges that there may be an issue with the fact that the Bitcoin itself is not slashable, but their voting power is. However, their UTXO can be blacklisted, making their attack costly as they lose out on the time-value of their stake.While the current thinking for the source of stake is to pay out stake to Bitcoin merged-miners, the designer is interested in exploring the idea of using time-locked Bitcoin as stake. The GitHub repository contains a simplified implementation of this sidechain design. For further details and a comprehensive understanding of the design, please refer to the design document available at https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md. 2019-02-01T09:19:00+00:00 + In a recent discussion on the bitcoin-dev mailing list, ZmnSCPxj proposed a design for a proof-of-mainstake sidechain without any modifications to the Bitcoin mainchain. The writer suggests embedding sidechain block headers on the mainchain by spending the previous transaction, requiring authorization from the sufficient signatory set of stakers. Mainchain-to-sidechain requests are defined as indications that a mainchain coin owner wants to stake or transfer coins to the sidechain. The sidechain-to-mainchain withdrawals are left up to the sidechain to define.The writer also discusses the possibility of a revealed private key for time-locked funds creating a race to spend and suggests that races could be won by bidding up fees if Bitcoin had implemented RBF properly. The context further explores the security features of staking in sidechains, where miners can claim the stake themselves due to the public knowledge of the private key. However, it becomes unlikely for the staker to win unless they possess significant mining hash power. The integrity of the sidechain is proportional to the attacker's share of the Bitcoin hashrate. The storage of Bitcoin moved to the sidechain can be stolen if 67% of the stakers collude.A discussion on the bitcoin-dev mailing list suggests using fixed R values derived through standard hierarchical derivation to prevent multiple signatures in Bitcoin sidechains. The staking pubkey would be revealed as `staking_pubkey = P + hash(P || parent_R) * G`, with the specific R value obtained from hierarchical derivation using parent_R and the blockheight as an index. The potential downsides and impact on blockweight are still unclear.In a separate thread, the discussion focuses on Matt Bell's design for Bitcoin sidechains using the Tendermint BFT consensus protocol. The design is similar to Blockstream's Liquid sidechain and seeks feedback from the community. The source of voting power for the sidechain network is a topic of debate, with suggestions including time-locked Bitcoin and UTXOs on the Bitcoin blockchain. ZmnSCPxj proposes using fixed R values to prevent multiple signatures and introduces the concept of "mainstake," where UTXOs on the Bitcoin blockchain are used as the source of stake for voting power.In an email sent to Matt Bell via Bitcoin-dev, ZmnSCPxj proposed an idea called "mainstake," which involves using UTXOs on the Bitcoin blockchain as stakes for voting power. This approach is seen as more secure than having a blockchain with its own token that is self-attesting. The same script proposed by Bell for sidechains could be used for mainstake. Bell, who has been working on a design for Bitcoin sidechains using the Tendermint BFT consensus protocol, welcomes feedback about improvements or critical flaws in his design. The Tendermint consensus is commonly used to build proof-of-stake networks and is similar to Blockstream's Liquid sidechain, known for its "strong federation" consensus.The sidechain network may accept potential stakers on the mainchain if they prove the existence of a mainchain transaction. The value of this output would then be used as the weight of the vote of that stake. The designer acknowledges that there may be an issue with the fact that the Bitcoin itself is not slashable, but their voting power is. However, their UTXO can be blacklisted, making their attack costly as they lose out on the time-value of their stake.While the current thinking for the source of stake is to pay out stake to Bitcoin merged-miners, the designer is interested in exploring the idea of using time-locked Bitcoin as stake. The GitHub repository contains a simplified implementation of this sidechain design. For further details and a comprehensive understanding of the design, please refer to the design document available at https://github.com/mappum/bitcoin-peg/blob/master/bitcoinPeg.md. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_Safer-NOINPUT-with-output-tagging.xml b/static/bitcoin-dev/Jan_2019/combined_Safer-NOINPUT-with-output-tagging.xml index f1057895fd..62adf1790d 100644 --- a/static/bitcoin-dev/Jan_2019/combined_Safer-NOINPUT-with-output-tagging.xml +++ b/static/bitcoin-dev/Jan_2019/combined_Safer-NOINPUT-with-output-tagging.xml @@ -1,95 +1,67 @@ - + 2 Combined summary - Safer NOINPUT with output tagging - 2023-08-02T00:18:41.848463+00:00 - - Johnson Lau 2019-02-19 20:36:51+00:00 - - - Luke Dashjr 2019-02-19 20:24:12+00:00 - - - Johnson Lau 2019-02-19 19:22:07+00:00 - - - Luke Dashjr 2019-02-19 19:04:03+00:00 - - - Anthony Towns 2019-02-10 04:46:30+00:00 - - - Johnson Lau 2019-02-09 17:43:50+00:00 - - - Jonas Nick 2019-02-09 16:54:09+00:00 - - - Jonas Nick 2019-02-09 16:52:07+00:00 - - - Johnson Lau 2019-02-09 16:48:40+00:00 - - - Johnson Lau 2019-02-09 10:15:17+00:00 - - - Alejandro Ranchal Pedrosa 2019-02-09 10:01:20+00:00 - - - Jonas Nick 2019-02-08 19:01:40+00:00 - - - ZmnSCPxj 2019-02-01 09:36:50+00:00 - - - Anthony Towns 2019-01-31 06:04:05+00:00 - - - ZmnSCPxj 2018-12-24 11:47:38+00:00 - - - Johnson Lau 2018-12-22 16:56:29+00:00 - - - ZmnSCPxj 2018-12-22 14:25:16+00:00 - - - Johnson Lau 2018-12-21 16:21:42+00:00 - - - Johnson Lau 2018-12-21 15:37:05+00:00 - - - ZmnSCPxj 2018-12-21 11:40:06+00:00 - - - Christian Decker 2018-12-21 11:15:37+00:00 - - - Johnson Lau 2018-12-20 18:04:37+00:00 - - - Christian Decker 2018-12-20 17:20:54+00:00 - - - Johnson Lau 2018-12-20 11:00:53+00:00 - - - Christian Decker 2018-12-19 22:09:50+00:00 - - - Johnson Lau 2018-12-18 10:48:40+00:00 - - - Johnson Lau 2018-12-17 20:08:55+00:00 - - - Ruben Somsen 2018-12-17 15:48:15+00:00 - - - Johnson Lau 2018-12-13 12:32:44+00:00 - + 2025-09-26T15:42:06.471851+00:00 + python-feedgen + + + Anthony Towns + 2019-01-31T06:04:00.000Z + + + ZmnSCPxj + 2019-02-01T09:36:00.000Z + + + Jonas Nick + 2019-02-08T19:01:00.000Z + + + Alejandro Ranchal Pedrosa + 2019-02-09T10:01:00.000Z + + + Johnson Lau + 2019-02-09T10:15:00.000Z + + + Johnson Lau + 2019-02-09T16:48:00.000Z + + + Jonas Nick + 2019-02-09T16:52:00.000Z + + + Jonas Nick + 2019-02-09T16:54:00.000Z + + + Johnson Lau + 2019-02-09T17:43:00.000Z + + + Anthony Towns + 2019-02-10T04:46:00.000Z + + + Luke Dashjr + 2019-02-19T19:04:00.000Z + + + Johnson Lau + 2019-02-19T19:22:00.000Z + + + Luke Dashjr + 2019-02-19T20:24:00.000Z + + + Johnson Lau + 2019-02-19T20:36:00.000Z + + @@ -119,13 +91,13 @@ - python-feedgen + 2 Combined summary - Safer NOINPUT with output tagging - 2023-08-02T00:18:41.848463+00:00 + 2025-09-26T15:42:06.473439+00:00 - The discussion on the bitcoin-dev mailing list revolves around various aspects of implementing a wallet that prevents address reuse and the compatibility of such a feature with NOINPUT. Johnson Lau suggests that addressing address reuse should be a social agreement between the payer and the payee, as it cannot be banned at the protocol level. He proposes publishing the key after a coin is confirmed as a stronger way to prevent address reuse. Luke Dashjr argues against implementing a nanny in the protocol, stating that it limits developers who want certain features. He also highlights the issue of address reuse rejection when using NOINPUT for everything.The acceptability of address reuse in Bitcoin transactions depends on the contract between the payer and payee and cannot be banned at the protocol level. NOINPUT, which allows multiple transactions to spend the same output, has limitations and risks associated with it. To prevent accidental double payments, Lau suggests tagging outputs to make them spendable with NOINPUT. Two possible ways to tag are discussed: setting a certain bit in the tx version or scriptPubKey. Each method has its advantages and disadvantages. The tradeoff between smart contracts and dumb contracts is also mentioned, with the aim of finding a design that enables desired smart contracts while minimizing misuse risks.The discussion also delves into the compatibility of tagging with multiparty eltoo channels, settlement transactions, and various attack scenarios. Alejandro Ranchal Pedrosa proposes Transaction Fragments as a solution to an eltoo-like protocol that works without going on-chain when participants' actions cannot be predicted in advance. Signature replay risks associated with NOINPUT are addressed, and Lau suggests extending version tagging to enhance NOINPUT safety.Another topic of discussion is the potential impact of tagging on fungibility in multiparty eltoo channels. A solution is proposed where settlement transactions are created with different locktimes, and the branch channel is opened on a tagged output. If cooperative channel closing is desired, it can be done on an untagged output without using NOINPUT to avoid fungibility loss.The bitcoin-dev community plays a vital role in identifying and addressing potential issues related to proposals like NOINPUT and ensuring compatibility between various proposals. The aim is to maintain the stability and security of the Bitcoin network while enabling desired smart contracts and minimizing risks.In a recent email exchange between Christian Decker and Johnson Lau, they discussed the use of OP_CSV (BIP112) in a 2-of-2 branch. It was argued that BIP68 relative locktime is not necessary since both parties need to agree on it. However, with taproot, the use of BIP68 actually saves more than just a few bytes. The conversation also discussed the idea of tagging an output to make it spendable with NOINPUT, which is compatible with eltoo. This would allow for walletless offchain software, where on-chain wallets can directly put their funds into an off-chain system without requiring an on-chain transfer. However, there are concerns regarding address reuse, dual-funding, and the need for a standard way of signing transactions without broadcasting them.The discussion also delved into the process of setting up, updating, and closing a Lightning Network channel using eltoo. This involves creating a setup transaction, followed by update transactions and a settlement transaction. Collaborative close and unilateral close were explained as different scenarios depending on the agreement between parties. The number of transactions involved depends on whether cheating occurs.Johnson Lau further explained the process of setting up and closing a payment channel between two parties using Bitcoin. This involves multiple steps, including creating setup, update, and settlement transactions. The concept of collaborative close and unilateral close was explained, along with the number of transactions involved depending on the scenario.The bitcoin-dev mailing list also discussed the design considerations of a channel setup using BIP118, 143, and 141-P2WSH without taproot. The compatibility of this setup with Statechains was explored, as well as the impact on fungibility if taproot was added. It was clarified that combining the trigger and setup transactions is not currently possible, and the purpose of having separate timeouts would be defeated if they were combined.Concerns were raised about the compatibility of NOINPUT with proposals such as Graftroot and Statechains, as well as the impact on fungibility if Taproot was added to Eltoo. The discussion also explored the use of output tagging and NOINPUT in the context of Eltoo and Statechains. The tradeoff between privacy, complexity, and fungibility was considered.In another email exchange, Johnson Lau discussed the risks of signature replay associated with NOINPUT and proposed a solution of "tagging" outputs that are spendable with NOINPUT. Two possible ways of tagging outputs were mentioned, either by setting a certain bit in the tx version or scriptPubKey. The implications of tagging for fungibility were discussed, along with the advantages and limitations of each tagging method. The philosophy behind output tagging was to avoid using NOINPUT unless absolutely necessary.Overall, the discussions focused on the 2019-02-19T20:36:51+00:00 + The discussion on the bitcoin-dev mailing list revolves around various aspects of implementing a wallet that prevents address reuse and the compatibility of such a feature with NOINPUT. Johnson Lau suggests that addressing address reuse should be a social agreement between the payer and the payee, as it cannot be banned at the protocol level. He proposes publishing the key after a coin is confirmed as a stronger way to prevent address reuse. Luke Dashjr argues against implementing a nanny in the protocol, stating that it limits developers who want certain features. He also highlights the issue of address reuse rejection when using NOINPUT for everything.The acceptability of address reuse in Bitcoin transactions depends on the contract between the payer and payee and cannot be banned at the protocol level. NOINPUT, which allows multiple transactions to spend the same output, has limitations and risks associated with it. To prevent accidental double payments, Lau suggests tagging outputs to make them spendable with NOINPUT. Two possible ways to tag are discussed: setting a certain bit in the tx version or scriptPubKey. Each method has its advantages and disadvantages. The tradeoff between smart contracts and dumb contracts is also mentioned, with the aim of finding a design that enables desired smart contracts while minimizing misuse risks.The discussion also delves into the compatibility of tagging with multiparty eltoo channels, settlement transactions, and various attack scenarios. Alejandro Ranchal Pedrosa proposes Transaction Fragments as a solution to an eltoo-like protocol that works without going on-chain when participants' actions cannot be predicted in advance. Signature replay risks associated with NOINPUT are addressed, and Lau suggests extending version tagging to enhance NOINPUT safety.Another topic of discussion is the potential impact of tagging on fungibility in multiparty eltoo channels. A solution is proposed where settlement transactions are created with different locktimes, and the branch channel is opened on a tagged output. If cooperative channel closing is desired, it can be done on an untagged output without using NOINPUT to avoid fungibility loss.The bitcoin-dev community plays a vital role in identifying and addressing potential issues related to proposals like NOINPUT and ensuring compatibility between various proposals. The aim is to maintain the stability and security of the Bitcoin network while enabling desired smart contracts and minimizing risks.In a recent email exchange between Christian Decker and Johnson Lau, they discussed the use of OP_CSV (BIP112) in a 2-of-2 branch. It was argued that BIP68 relative locktime is not necessary since both parties need to agree on it. However, with taproot, the use of BIP68 actually saves more than just a few bytes. The conversation also discussed the idea of tagging an output to make it spendable with NOINPUT, which is compatible with eltoo. This would allow for walletless offchain software, where on-chain wallets can directly put their funds into an off-chain system without requiring an on-chain transfer. However, there are concerns regarding address reuse, dual-funding, and the need for a standard way of signing transactions without broadcasting them.The discussion also delved into the process of setting up, updating, and closing a Lightning Network channel using eltoo. This involves creating a setup transaction, followed by update transactions and a settlement transaction. Collaborative close and unilateral close were explained as different scenarios depending on the agreement between parties. The number of transactions involved depends on whether cheating occurs.Johnson Lau further explained the process of setting up and closing a payment channel between two parties using Bitcoin. This involves multiple steps, including creating setup, update, and settlement transactions. The concept of collaborative close and unilateral close was explained, along with the number of transactions involved depending on the scenario.The bitcoin-dev mailing list also discussed the design considerations of a channel setup using BIP118, 143, and 141-P2WSH without taproot. The compatibility of this setup with Statechains was explored, as well as the impact on fungibility if taproot was added. It was clarified that combining the trigger and setup transactions is not currently possible, and the purpose of having separate timeouts would be defeated if they were combined.Concerns were raised about the compatibility of NOINPUT with proposals such as Graftroot and Statechains, as well as the impact on fungibility if Taproot was added to Eltoo. The discussion also explored the use of output tagging and NOINPUT in the context of Eltoo and Statechains. The tradeoff between privacy, complexity, and fungibility was considered.In another email exchange, Johnson Lau discussed the risks of signature replay associated with NOINPUT and proposed a solution of "tagging" outputs that are spendable with NOINPUT. Two possible ways of tagging outputs were mentioned, either by setting a certain bit in the tx version or scriptPubKey. The implications of tagging for fungibility were discussed, along with the advantages and limitations of each tagging method. The philosophy behind output tagging was to avoid using NOINPUT unless absolutely necessary.Overall, the discussions focused on the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2019/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml b/static/bitcoin-dev/Jan_2019/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml index c1019a1c72..1d4965e984 100644 --- a/static/bitcoin-dev/Jan_2019/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml +++ b/static/bitcoin-dev/Jan_2019/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - bustapay BIP :: a practical sender/receiver coinjoin protocol - 2023-08-01T23:47:19.394119+00:00 - - James MacWhyte 2019-01-30 20:58:03+00:00 - - - ZmnSCPxj 2019-01-30 08:34:46+00:00 - - - rhavar at protonmail.com 2019-01-30 02:46:47+00:00 - - - James MacWhyte 2019-01-30 02:06:30+00:00 - - - Adam Gibson 2019-01-28 13:19:09+00:00 - - - ZmnSCPxj 2019-01-28 04:14:41+00:00 - - - rhavar at protonmail.com 2019-01-27 22:11:47+00:00 - - - James MacWhyte 2019-01-27 19:42:03+00:00 - - - rhavar at protonmail.com 2019-01-27 19:24:11+00:00 - - - Adam Gibson 2019-01-27 12:20:54+00:00 - - - rhavar at protonmail.com 2019-01-27 07:36:59+00:00 - - - Adam Gibson 2019-01-25 14:47:34+00:00 - - - rhavar at protonmail.com 2018-09-10 15:49:29+00:00 - - - Sjors Provoost 2018-09-10 12:30:46+00:00 - - - rhavar at protonmail.com 2018-08-30 20:24:58+00:00 - + 2025-09-26T15:42:10.685333+00:00 + python-feedgen + + + [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol rhavar + 2018-08-30T20:24:00.000Z + + + Sjors Provoost + 2018-09-10T12:30:00.000Z + + + rhavar + 2018-09-10T15:49:00.000Z + + + Adam Gibson + 2019-01-25T14:47:00.000Z + + + rhavar + 2019-01-27T07:36:00.000Z + + + Adam Gibson + 2019-01-27T12:20:00.000Z + + + rhavar + 2019-01-27T19:24:00.000Z + + + James MacWhyte + 2019-01-27T19:42:00.000Z + + + rhavar + 2019-01-27T22:11:00.000Z + + + ZmnSCPxj + 2019-01-28T04:14:00.000Z + + + Adam Gibson + 2019-01-28T13:19:00.000Z + + + James MacWhyte + 2019-01-30T02:06:00.000Z + + + rhavar + 2019-01-30T02:46:00.000Z + + + ZmnSCPxj + 2019-01-30T08:34:00.000Z + + + James MacWhyte + 2019-01-30T20:58:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - bustapay BIP :: a practical sender/receiver coinjoin protocol - 2023-08-01T23:47:19.395084+00:00 + 2025-09-26T15:42:10.687270+00:00 - The conversation revolves around the potential attack on a transaction template and the weaknesses identified in the proposed protocol. The sender suggests that refusing to sign the final transaction can still propagate the template transaction, but the real attack would be if the sender double-spends it before propagation. The receiver acknowledges the weaknesses and agrees that there may not be a better solution. They also understand that implementers unable to integrate signing and UTXO validation are unlikely to implement this feature.Another discussion focuses on the issues faced by a "PayJoin-only" merchant who repeatedly uses a single UTXO. This could lead to an imbalance of funds violating UIH2. To avoid this, it is suggested to have a mix of PayJoin and non-PayJoin transactions. The concept of Bustapay is introduced, which allows for PayJoin transactions with a single UTXO. However, repeated use of the same UTXO can still suggest a naive approach. A heuristic is proposed to randomly flip coins for each UTXO owned to determine when to use PayJoin or not, although no formal analysis has been conducted.James MacWhyte expresses concerns about the complexity of the Bustapay spec and questions the effectiveness of the anti-spy feature. He suggests simplifying the protocol by dropping the signing requirement in the first step. However, he acknowledges the transaction malleability issues that may arise. MacWhyte concludes that the only viable way to use Bustapay with increased privacy would be to pay the first part of the invoice in lightning and then pay the rest with Bustapay, but admits that this approach has too many moving parts and implementation difficulties.ZmnSCPxj proposes solutions to address the UIH2 issue, suggesting standard coin selection algorithms and the inclusion of contributed inputs. AdamISZ raises concerns about mismatched input sizes and the concentration of funds in a single UTXO. Belcher suggests having a mix of PayJoin and non-PayJoin transactions to avoid violating UIH2.The conversation also discusses the steganographic hiding of transaction ownership and the adoption of the PayJoin protocol. Members debate the practicality and complexity of the protocol, as well as the need for versioning and inclusion of PSBT/BIP174. The importance of explicit transaction details like version and locktime is also debated.The implementation of Bustapay is discussed, including its integration into BtcPayServer and the need for a standardized format for moving UTXOs between wallets. Concerns are raised about wallets violating standards and the need for uniformity in Bitcoin transactions.Ryan Havar acknowledges mistakes in his recent BIP 0079 proposal and agrees with Adam Gibson's opinion on steganographic hiding of transaction inputs. He suggests better support for moving UTXOs between wallets through a standardized format. Adam emphasizes the need for consensus on protocols, versioning, and the inclusion of PSBT/BIP174. He suggests avoiding unnecessary inputs and making the payjoin transaction appear as an ordinary payment. Adam also highlights the value of being explicit about simple things like transaction version and locktime.In conclusion, the discussions revolve around the potential attacks, weaknesses, and proposed solutions in the Bustapay protocol. There are debates on issues such as the concentration of funds, UIH2, steganographic hiding, standardization, and protocol versioning. The importance of simplifying the process, ensuring privacy, and protecting both senders and receivers is emphasized.Ryan and Adam Gibson discussed the standardization of PayJoin as a transaction that breaks the assumption of common ownership of transaction inputs. They talked about various aspects such as protocol versioning, using PSBT/BIP174, version/locktime, and avoiding non-payment "Unnecessary Input Heuristic."The proposal, known as Bustapay, aims to address fungibility concerns and blockchain analysis by creating indistinguishable Bitcoin transactions. The sender creates a fully valid, signed "template transaction" and gives it to the receiver through an HTTP POST request. The receiver adds their own input and increases the output that pays themselves by the contributed input amount. The partial transaction is then sent back to the sender to sign and propagated on the Bitcoin network by the receiver.Implementing Bustapay payments requires receivers to be aware of implementation notes, including checking if the transaction is suitable for the mempool with testmempoolaccept in Bitcoin Core 0.17. Sending applications should validate the HTTP response to ensure no unexpected changes have been made to the transaction.A proposal has been suggested to standardize the Bustapay protocol, which allows for hiding transaction information and increasing privacy. Steganographic hiding is considered worth pursuing, as Joinmarket and Samourai have already begun implementing the protocol. The aim is to create a cross-wallet standard that can be included in projects like BTCPayServer. Generic comments on protocol versioning, naming conventions, and the need for x-wallet compatibility standards are discussed.The Bustapay payment system involves several steps 2019-01-30T20:58:03+00:00 + The conversation revolves around the potential attack on a transaction template and the weaknesses identified in the proposed protocol. The sender suggests that refusing to sign the final transaction can still propagate the template transaction, but the real attack would be if the sender double-spends it before propagation. The receiver acknowledges the weaknesses and agrees that there may not be a better solution. They also understand that implementers unable to integrate signing and UTXO validation are unlikely to implement this feature.Another discussion focuses on the issues faced by a "PayJoin-only" merchant who repeatedly uses a single UTXO. This could lead to an imbalance of funds violating UIH2. To avoid this, it is suggested to have a mix of PayJoin and non-PayJoin transactions. The concept of Bustapay is introduced, which allows for PayJoin transactions with a single UTXO. However, repeated use of the same UTXO can still suggest a naive approach. A heuristic is proposed to randomly flip coins for each UTXO owned to determine when to use PayJoin or not, although no formal analysis has been conducted.James MacWhyte expresses concerns about the complexity of the Bustapay spec and questions the effectiveness of the anti-spy feature. He suggests simplifying the protocol by dropping the signing requirement in the first step. However, he acknowledges the transaction malleability issues that may arise. MacWhyte concludes that the only viable way to use Bustapay with increased privacy would be to pay the first part of the invoice in lightning and then pay the rest with Bustapay, but admits that this approach has too many moving parts and implementation difficulties.ZmnSCPxj proposes solutions to address the UIH2 issue, suggesting standard coin selection algorithms and the inclusion of contributed inputs. AdamISZ raises concerns about mismatched input sizes and the concentration of funds in a single UTXO. Belcher suggests having a mix of PayJoin and non-PayJoin transactions to avoid violating UIH2.The conversation also discusses the steganographic hiding of transaction ownership and the adoption of the PayJoin protocol. Members debate the practicality and complexity of the protocol, as well as the need for versioning and inclusion of PSBT/BIP174. The importance of explicit transaction details like version and locktime is also debated.The implementation of Bustapay is discussed, including its integration into BtcPayServer and the need for a standardized format for moving UTXOs between wallets. Concerns are raised about wallets violating standards and the need for uniformity in Bitcoin transactions.Ryan Havar acknowledges mistakes in his recent BIP 0079 proposal and agrees with Adam Gibson's opinion on steganographic hiding of transaction inputs. He suggests better support for moving UTXOs between wallets through a standardized format. Adam emphasizes the need for consensus on protocols, versioning, and the inclusion of PSBT/BIP174. He suggests avoiding unnecessary inputs and making the payjoin transaction appear as an ordinary payment. Adam also highlights the value of being explicit about simple things like transaction version and locktime.In conclusion, the discussions revolve around the potential attacks, weaknesses, and proposed solutions in the Bustapay protocol. There are debates on issues such as the concentration of funds, UIH2, steganographic hiding, standardization, and protocol versioning. The importance of simplifying the process, ensuring privacy, and protecting both senders and receivers is emphasized.Ryan and Adam Gibson discussed the standardization of PayJoin as a transaction that breaks the assumption of common ownership of transaction inputs. They talked about various aspects such as protocol versioning, using PSBT/BIP174, version/locktime, and avoiding non-payment "Unnecessary Input Heuristic."The proposal, known as Bustapay, aims to address fungibility concerns and blockchain analysis by creating indistinguishable Bitcoin transactions. The sender creates a fully valid, signed "template transaction" and gives it to the receiver through an HTTP POST request. The receiver adds their own input and increases the output that pays themselves by the contributed input amount. The partial transaction is then sent back to the sender to sign and propagated on the Bitcoin network by the receiver.Implementing Bustapay payments requires receivers to be aware of implementation notes, including checking if the transaction is suitable for the mempool with testmempoolaccept in Bitcoin Core 0.17. Sending applications should validate the HTTP response to ensure no unexpected changes have been made to the transaction.A proposal has been suggested to standardize the Bustapay protocol, which allows for hiding transaction information and increasing privacy. Steganographic hiding is considered worth pursuing, as Joinmarket and Samourai have already begun implementing the protocol. The aim is to create a cross-wallet standard that can be included in projects like BTCPayServer. Generic comments on protocol versioning, naming conventions, and the need for x-wallet compatibility standards are discussed.The Bustapay payment system involves several steps - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_-Annoucement-Discreet-Log-Contract-Protocol-Specification.xml b/static/bitcoin-dev/Jan_2020/combined_-Annoucement-Discreet-Log-Contract-Protocol-Specification.xml index 87a47fb95f..f600f890d8 100644 --- a/static/bitcoin-dev/Jan_2020/combined_-Annoucement-Discreet-Log-Contract-Protocol-Specification.xml +++ b/static/bitcoin-dev/Jan_2020/combined_-Annoucement-Discreet-Log-Contract-Protocol-Specification.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - [Annoucement] Discreet Log Contract Protocol Specification - 2023-08-02T01:47:22.313644+00:00 - - Nadav Kohen 2020-02-27 16:17:47+00:00 - - - Lloyd Fournier 2020-01-28 09:28:27+00:00 - - - Chris Stewart 2020-01-13 12:27:34+00:00 - + 2025-09-26T15:50:54.552251+00:00 + python-feedgen + + + [bitcoin-dev] [Annoucement] Discreet Log Contract Protocol Specification Chris Stewart + 2020-01-13T12:27:00.000Z + + + Lloyd Fournier + 2020-01-28T09:28:00.000Z + + + Nadav Kohen + 2020-02-27T16:17:00.000Z + + - python-feedgen + 2 Combined summary - [Annoucement] Discreet Log Contract Protocol Specification - 2023-08-02T01:47:22.313644+00:00 + 2025-09-26T15:50:54.552803+00:00 - Additionally, Suredbits and Crypto Garage have released working code for executing 2-outcome Discreet Log Contracts and provided documentation on how to use it. They have also shared a short blog post containing a video demo of an execution. The team encourages interested individuals to review and contribute to the work-in-progress specification.The team's secondary goal is to ensure that DLCs become widely accepted and standardized tools in the Bitcoin ecosystem. They want to establish DLCs as a commonly used technology by creating a set of agreed-upon standards for funding transactions and closing transactions. This will allow every future Bitcoin-related protocol to have access to a toolbox of standards, making software integration more streamlined and efficient.For those interested in learning more about DLCs, there are several resources available. These include a whitepaper, articles, and research papers that provide in-depth information on the topic. By making DLCs easily accessible through comprehensive resources, the team hopes to foster widespread understanding and adoption of this technology within the Bitcoin community.Overall, Suredbits and Crypto Garage are determined to develop a robust protocol specification for using DLCs in a safe, private, and interoperable manner. They aim to create a common standard for using Bitcoin oracles, while remaining compatible with existing Bitcoin-related protocols. Through their efforts, they hope to establish DLCs as widely accepted and standardized tools in the Bitcoin ecosystem, benefiting developers and users alike. 2020-02-27T16:17:47+00:00 + Additionally, Suredbits and Crypto Garage have released working code for executing 2-outcome Discreet Log Contracts and provided documentation on how to use it. They have also shared a short blog post containing a video demo of an execution. The team encourages interested individuals to review and contribute to the work-in-progress specification.The team's secondary goal is to ensure that DLCs become widely accepted and standardized tools in the Bitcoin ecosystem. They want to establish DLCs as a commonly used technology by creating a set of agreed-upon standards for funding transactions and closing transactions. This will allow every future Bitcoin-related protocol to have access to a toolbox of standards, making software integration more streamlined and efficient.For those interested in learning more about DLCs, there are several resources available. These include a whitepaper, articles, and research papers that provide in-depth information on the topic. By making DLCs easily accessible through comprehensive resources, the team hopes to foster widespread understanding and adoption of this technology within the Bitcoin community.Overall, Suredbits and Crypto Garage are determined to develop a robust protocol specification for using DLCs in a safe, private, and interoperable manner. They aim to create a common standard for using Bitcoin oracles, while remaining compatible with existing Bitcoin-related protocols. Through their efforts, they hope to establish DLCs as widely accepted and standardized tools in the Bitcoin ecosystem, benefiting developers and users alike. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_-UNCHECKED-Wormhole-Sending-and-receiving-bitcoin-anonymously.xml b/static/bitcoin-dev/Jan_2020/combined_-UNCHECKED-Wormhole-Sending-and-receiving-bitcoin-anonymously.xml index 464119a22c..3ab6927fea 100644 --- a/static/bitcoin-dev/Jan_2020/combined_-UNCHECKED-Wormhole-Sending-and-receiving-bitcoin-anonymously.xml +++ b/static/bitcoin-dev/Jan_2020/combined_-UNCHECKED-Wormhole-Sending-and-receiving-bitcoin-anonymously.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - ***UNCHECKED*** Wormhole: Sending and receiving bitcoin anonymously - 2023-08-02T01:47:48.158105+00:00 - - ZmnSCPxj 2020-01-16 02:11:44+00:00 - - - Max Hillebrand 2020-01-15 21:23:15+00:00 - + 2025-09-26T15:50:44.043063+00:00 + python-feedgen + + + [bitcoin-dev] ***UNCHECKED*** Wormhole: Sending and receiving bitcoin anonymously Max Hillebrand + 2020-01-15T21:23:00.000Z + + + ZmnSCPxj + 2020-01-16T02:11:00.000Z + + - python-feedgen + 2 Combined summary - ***UNCHECKED*** Wormhole: Sending and receiving bitcoin anonymously - 2023-08-02T01:47:48.158105+00:00 + 2025-09-26T15:50:44.043585+00:00 - A proposed protocol called Wormhole aims to enhance the privacy of Bitcoin transactions. It builds upon the ZeroLink CoinJoin protocol and introduces minor modifications to ensure that neither the sender nor the receiver gain knowledge of each other's inputs and outputs. This is achieved through the use of Schnorr blind signatures, which obscure the link between inputs and equal value outputs during the transaction process.The Wormhole protocol employs a centralized coordinator who is unable to steal or spy on the transaction. The coordinator remains unaware that Wormhole is being utilized. The outcome of the protocol is that the sender (A) possesses a 4 bitcoin UTXO with an anonset of 100, as well as a 0.5 bitcoin UTXO with an anonset of 1. On the other hand, the receiver (B) holds a 1 bitcoin UTXO with an anonset of 100. While the coordinator (W) is aware of A's input and change, they do not know which equal value output belongs to whom, nor are they aware that B has no inputs.Communication between A and B can take place through any private channel such as Tor, QR codes, SD cards, or carrier pigeons. The communication between A/B and W follows the same method used in the regular ZeroLink implementation, most likely involving Tor. The anonymity set of the equal value zero link outputs from A and B is determined by the total number of such outputs in the same transaction.Wormhole challenges the assumption that zero links are solely a consolidation within the same wallet. It is an interactive protocol that involves multiple rounds of communication, requiring all participants (A, B, and W) to be online. Additionally, the protocol can be combined with Pay to Endpoint or Knapsack to enable A to send a specific amount to B, with part of the transaction being the equal value zero link output and part being the P2EP change or Knapsack sub-transaction. There is also the possibility of integrating atomic coinswaps with Schnorr adaptor signatures, where A's input in CJTX1 "pays" B's output in CJTX2, although this may require B to know the signature (and thus the input) of A. 2020-01-16T02:11:44+00:00 + A proposed protocol called Wormhole aims to enhance the privacy of Bitcoin transactions. It builds upon the ZeroLink CoinJoin protocol and introduces minor modifications to ensure that neither the sender nor the receiver gain knowledge of each other's inputs and outputs. This is achieved through the use of Schnorr blind signatures, which obscure the link between inputs and equal value outputs during the transaction process.The Wormhole protocol employs a centralized coordinator who is unable to steal or spy on the transaction. The coordinator remains unaware that Wormhole is being utilized. The outcome of the protocol is that the sender (A) possesses a 4 bitcoin UTXO with an anonset of 100, as well as a 0.5 bitcoin UTXO with an anonset of 1. On the other hand, the receiver (B) holds a 1 bitcoin UTXO with an anonset of 100. While the coordinator (W) is aware of A's input and change, they do not know which equal value output belongs to whom, nor are they aware that B has no inputs.Communication between A and B can take place through any private channel such as Tor, QR codes, SD cards, or carrier pigeons. The communication between A/B and W follows the same method used in the regular ZeroLink implementation, most likely involving Tor. The anonymity set of the equal value zero link outputs from A and B is determined by the total number of such outputs in the same transaction.Wormhole challenges the assumption that zero links are solely a consolidation within the same wallet. It is an interactive protocol that involves multiple rounds of communication, requiring all participants (A, B, and W) to be online. Additionally, the protocol can be combined with Pay to Endpoint or Knapsack to enable A to send a specific amount to B, with part of the transaction being the equal value zero link output and part being the P2EP change or Knapsack sub-transaction. There is also the possibility of integrating atomic coinswaps with Schnorr adaptor signatures, where A's input in CJTX1 "pays" B's output in CJTX2, although this may require B to know the signature (and thus the input) of A. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_Characterizing-orphan-transaction-in-the-Bitcoin-network.xml b/static/bitcoin-dev/Jan_2020/combined_Characterizing-orphan-transaction-in-the-Bitcoin-network.xml index f9bfef031f..3777ca5982 100644 --- a/static/bitcoin-dev/Jan_2020/combined_Characterizing-orphan-transaction-in-the-Bitcoin-network.xml +++ b/static/bitcoin-dev/Jan_2020/combined_Characterizing-orphan-transaction-in-the-Bitcoin-network.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Characterizing orphan transaction in the Bitcoin network - 2023-08-02T01:49:23.060727+00:00 - - Matt Corallo 2020-02-03 03:41:21+00:00 - - - Anas 2020-01-31 23:07:26+00:00 - + 2025-09-26T15:51:00.847855+00:00 + python-feedgen + + + [bitcoin-dev] Characterizing orphan transaction in the Bitcoin network Anas + 2020-01-31T23:07:00.000Z + + + Matt Corallo + 2020-02-03T03:41:00.000Z + + - python-feedgen + 2 Combined summary - Characterizing orphan transaction in the Bitcoin network - 2023-08-02T01:49:23.060727+00:00 + 2025-09-26T15:51:00.848284+00:00 - The paper's findings highlight the importance of understanding and reducing the impact of orphan transactions on network throughput. It suggests that increasing the size of the orphan pool can reduce network overhead without adding much performance overhead. This is because orphan transactions tend to have fewer parents with lower fees and larger sizes compared to non-orphan transactions, resulting in a lower transaction fee per byte. The study also notes that the network overhead caused by orphan transactions can be significant, reaching up to 17% when using the default orphan memory pool size. However, this overhead can be made negligible by increasing the pool size to 1000 transactions, without requiring significant computational or memory resources. The email discussing this paper suggests that further discussion on the software-level aspects of Bitcoin Core should take place on Github rather than the current forum. Overall, the discussion sheds light on the characteristics of orphan transactions and emphasizes the need to minimize their impact on network throughput. 2020-02-03T03:41:21+00:00 + The paper's findings highlight the importance of understanding and reducing the impact of orphan transactions on network throughput. It suggests that increasing the size of the orphan pool can reduce network overhead without adding much performance overhead. This is because orphan transactions tend to have fewer parents with lower fees and larger sizes compared to non-orphan transactions, resulting in a lower transaction fee per byte. The study also notes that the network overhead caused by orphan transactions can be significant, reaching up to 17% when using the default orphan memory pool size. However, this overhead can be made negligible by increasing the pool size to 1000 transactions, without requiring significant computational or memory resources. The email discussing this paper suggests that further discussion on the software-level aspects of Bitcoin Core should take place on Github rather than the current forum. Overall, the discussion sheds light on the characteristics of orphan transactions and emphasizes the need to minimize their impact on network throughput. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_Coins-A-trustless-sidechain-protocol.xml b/static/bitcoin-dev/Jan_2020/combined_Coins-A-trustless-sidechain-protocol.xml index 5464525b06..6a230d413e 100644 --- a/static/bitcoin-dev/Jan_2020/combined_Coins-A-trustless-sidechain-protocol.xml +++ b/static/bitcoin-dev/Jan_2020/combined_Coins-A-trustless-sidechain-protocol.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Coins: A trustless sidechain protocol - 2023-08-02T01:47:11.745762+00:00 - - Robin Linus 2020-01-18 08:21:36+00:00 - - - ZmnSCPxj 2020-01-17 13:54:50+00:00 - - - Robin Linus 2020-01-17 04:17:56+00:00 - - - Angel Leon 2020-01-16 01:21:52+00:00 - - - ZmnSCPxj 2020-01-15 05:46:04+00:00 - - - Robin Linus 2020-01-15 01:43:06+00:00 - - - ZmnSCPxj 2020-01-14 15:26:18+00:00 - - - Joachim Strömbergson 2020-01-14 15:06:32+00:00 - - - Robin Linus 2020-01-14 04:12:56+00:00 - - - ZmnSCPxj 2020-01-14 02:59:25+00:00 - - - Robin Linus 2020-01-14 02:19:55+00:00 - - - ZmnSCPxj 2020-01-14 00:53:24+00:00 - - - Robin Linus 2020-01-13 22:22:43+00:00 - - - Jeremy 2020-01-13 22:05:21+00:00 - - - Joachim Strömbergson 2020-01-13 20:49:51+00:00 - - - Robin Linus 2020-01-13 19:47:23+00:00 - - - Joachim Strömbergson 2020-01-13 18:06:17+00:00 - - - Joachim Strömbergson 2020-01-13 17:34:17+00:00 - - - ZmnSCPxj 2020-01-13 02:33:21+00:00 - - - Robin Linus 2020-01-13 02:02:53+00:00 - - - ZmnSCPxj 2020-01-13 00:21:42+00:00 - - - Robin Linus 2020-01-12 18:54:57+00:00 - + 2025-09-26T15:50:58.756467+00:00 + python-feedgen + + + [bitcoin-dev] Coins: A trustless sidechain protocol Robin Linus + 2020-01-12T18:54:00.000Z + + + ZmnSCPxj + 2020-01-13T00:21:00.000Z + + + Robin Linus + 2020-01-13T02:02:00.000Z + + + ZmnSCPxj + 2020-01-13T02:33:00.000Z + + + Joachim Strömbergson + 2020-01-13T17:34:00.000Z + + + Joachim Strömbergson + 2020-01-13T18:06:00.000Z + + + Robin Linus + 2020-01-13T19:47:00.000Z + + + Joachim Strömbergson + 2020-01-13T20:49:00.000Z + + + Jeremy + 2020-01-13T22:05:00.000Z + + + Robin Linus + 2020-01-13T22:22:00.000Z + + + ZmnSCPxj + 2020-01-14T00:53:00.000Z + + + Robin Linus + 2020-01-14T02:19:00.000Z + + + ZmnSCPxj + 2020-01-14T02:59:00.000Z + + + Robin Linus + 2020-01-14T04:12:00.000Z + + + Joachim Strömbergson + 2020-01-14T15:06:00.000Z + + + ZmnSCPxj + 2020-01-14T15:26:00.000Z + + + Robin Linus + 2020-01-15T01:43:00.000Z + + + ZmnSCPxj + 2020-01-15T05:46:00.000Z + + + Angel Leon + 2020-01-16T01:21:00.000Z + + + Robin Linus + 2020-01-17T04:17:00.000Z + + + ZmnSCPxj + 2020-01-17T13:54:00.000Z + + + Robin Linus + 2020-01-18T08:21:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Coins: A trustless sidechain protocol - 2023-08-02T01:47:11.745762+00:00 + 2025-09-26T15:50:58.758929+00:00 - In this discussion, the concept of sidechains and their relation to altcoins and Bitcoin is explored. Sidechains are described as issuing their own coins but not being independent altcoins, as Bitcoin remains the unit of account. The security of sidechains is compared to Proof of Work (PoW) and bitcoin-backed Proof of Stake (PoS), with the author suggesting that they offer the same level of security assuming equal rewards. It is noted that the real-world value of total block rewards for an altcoin must match that of Bitcoin to approach its level of security. Additionally, sidechains require a sufficient user base despite not needing to be as secure as Bitcoin in theory.The author argues against the notion that halting a healthy chain with a tiny investment is possible, stating that the invested time value per block of all honest stakeholders converges against the block reward. The security of bitcoin-backed PoS is deemed as strong as PoW because their security is proportional to the dollar value of their block reward. However, for a sidechain to be as secure as Bitcoin, it requires more users or higher fees. If the consumed resource does not match what is consumed under PoW, the sidechain is not much better than a low-PoW altcoin and can be easily attacked unless centralized around developers.A proposed bitcoin-backed PoS sidechain protocol by Robin Linus is mentioned, which utilizes one-time signatures and bitcoin-backed proof-of-burn to address the double-spending problem. Concerns are raised by Joachim Strömbergson about the introduction of new tokens for each sidechain and the fragility of the proposed system's security. Robin Linus responds by explaining the convergence of honest stakeholders' invested time value per block against the block reward, making halting a healthy chain costly. The debate between Lightning Network and sidechains is discussed, with the advantages of using independent sidechains for global scalability highlighted. Various off-chain updateable cryptocurrency systems are also mentioned as potential alternatives to sidechains.ZmnSCPxj discusses scalability issues in the blockchain space and proposes proof-of-burn (PoB) as a secure mechanism for sidechains. The importance of liquidity for atomic swaps to pay Lightning Network invoices denominated in BTC is emphasized. The idea of pegging sidecoins to BTC is considered essential for network effects. A project combining mainchain-staking with 2-way pegs to increase security in federated sidechains is outlined, although the preference for Lightning Network over sidechains is expressed.An email thread between Robin Linus and Joachim Strömbergson reveals differing opinions on Linus's proposal for a Bitcoin sidechain. Strömbergson argues against the introduction of new tokens for sidechains and questions the security of PoS sidechains. Linus defends the proposal by asserting the impossibility of double-spending and the stronger security enforced by stakeholders having to stake per chain. The disagreement continues regarding the viability of different sidechain models.In another email exchange, Robin Linus proposes a solution for Bitcoin's scalability issue using Bitcoin-backed PoS sidechains. The Coins protocol is introduced, which aims to solve the double-spending problem through one-time signatures and collateral destruction for conflicting histories. Concerns are raised about the introduction of new tokens and the security of the proposed system, with disagreements over the potential benefits of the proposal.The conversation between ZmnSCPxj and Robin focuses on the scalability and security of Bitcoin and potential solutions. The use of bitcoin-backed PoS sidechains is suggested as a solution that offers better security and public auditability while meeting the requirements of average users. Concerns are raised about the fragmentation of the community within a sidechain and the efficient use of resources.The security, integrity, and censorship-resistance of Bitcoin are discussed, with the reliance on sophisticated actors who run full nodes and provide hash power highlighted. Bitcoin-backed PoS sidechains are suggested as a solution that offers better security and simplicity for end-users compared to the Lightning Network. The limitations of custodial solutions and the need for scalability are addressed.In summary, the discussion explores various aspects of sidechains, including their relation to altcoins and Bitcoin, their security compared to PoW and bitcoin-backed PoS, and the requirements for their security and user base. Proposed solutions, such as Robin Linus's bitcoin-backed PoS sidechain protocol and ZmnSCPxj's proof-of-burn mechanism, are discussed along with concerns and debates surrounding them. The advantages of sidechains over the Lightning Network, scalability issues, and the importance of security and decentralization are also explored.The author of the message discusses the advantages of using independent sidechains for scalability in the context of the Lightning Network (LN). By utilizing sidechains, end users can "live" in these separate chains instead of directly on the LN, which offers benefits such as not requiring bitcoin blockspace for new user onboarding and eliminating the need to lock funds for inbound capacity. The author also mentions the use 2020-01-18T08:21:36+00:00 + In this discussion, the concept of sidechains and their relation to altcoins and Bitcoin is explored. Sidechains are described as issuing their own coins but not being independent altcoins, as Bitcoin remains the unit of account. The security of sidechains is compared to Proof of Work (PoW) and bitcoin-backed Proof of Stake (PoS), with the author suggesting that they offer the same level of security assuming equal rewards. It is noted that the real-world value of total block rewards for an altcoin must match that of Bitcoin to approach its level of security. Additionally, sidechains require a sufficient user base despite not needing to be as secure as Bitcoin in theory.The author argues against the notion that halting a healthy chain with a tiny investment is possible, stating that the invested time value per block of all honest stakeholders converges against the block reward. The security of bitcoin-backed PoS is deemed as strong as PoW because their security is proportional to the dollar value of their block reward. However, for a sidechain to be as secure as Bitcoin, it requires more users or higher fees. If the consumed resource does not match what is consumed under PoW, the sidechain is not much better than a low-PoW altcoin and can be easily attacked unless centralized around developers.A proposed bitcoin-backed PoS sidechain protocol by Robin Linus is mentioned, which utilizes one-time signatures and bitcoin-backed proof-of-burn to address the double-spending problem. Concerns are raised by Joachim Strömbergson about the introduction of new tokens for each sidechain and the fragility of the proposed system's security. Robin Linus responds by explaining the convergence of honest stakeholders' invested time value per block against the block reward, making halting a healthy chain costly. The debate between Lightning Network and sidechains is discussed, with the advantages of using independent sidechains for global scalability highlighted. Various off-chain updateable cryptocurrency systems are also mentioned as potential alternatives to sidechains.ZmnSCPxj discusses scalability issues in the blockchain space and proposes proof-of-burn (PoB) as a secure mechanism for sidechains. The importance of liquidity for atomic swaps to pay Lightning Network invoices denominated in BTC is emphasized. The idea of pegging sidecoins to BTC is considered essential for network effects. A project combining mainchain-staking with 2-way pegs to increase security in federated sidechains is outlined, although the preference for Lightning Network over sidechains is expressed.An email thread between Robin Linus and Joachim Strömbergson reveals differing opinions on Linus's proposal for a Bitcoin sidechain. Strömbergson argues against the introduction of new tokens for sidechains and questions the security of PoS sidechains. Linus defends the proposal by asserting the impossibility of double-spending and the stronger security enforced by stakeholders having to stake per chain. The disagreement continues regarding the viability of different sidechain models.In another email exchange, Robin Linus proposes a solution for Bitcoin's scalability issue using Bitcoin-backed PoS sidechains. The Coins protocol is introduced, which aims to solve the double-spending problem through one-time signatures and collateral destruction for conflicting histories. Concerns are raised about the introduction of new tokens and the security of the proposed system, with disagreements over the potential benefits of the proposal.The conversation between ZmnSCPxj and Robin focuses on the scalability and security of Bitcoin and potential solutions. The use of bitcoin-backed PoS sidechains is suggested as a solution that offers better security and public auditability while meeting the requirements of average users. Concerns are raised about the fragmentation of the community within a sidechain and the efficient use of resources.The security, integrity, and censorship-resistance of Bitcoin are discussed, with the reliance on sophisticated actors who run full nodes and provide hash power highlighted. Bitcoin-backed PoS sidechains are suggested as a solution that offers better security and simplicity for end-users compared to the Lightning Network. The limitations of custodial solutions and the need for scalability are addressed.In summary, the discussion explores various aspects of sidechains, including their relation to altcoins and Bitcoin, their security compared to PoW and bitcoin-backed PoS, and the requirements for their security and user base. Proposed solutions, such as Robin Linus's bitcoin-backed PoS sidechain protocol and ZmnSCPxj's proof-of-burn mechanism, are discussed along with concerns and debates surrounding them. The advantages of sidechains over the Lightning Network, scalability issues, and the importance of security and decentralization are also explored.The author of the message discusses the advantages of using independent sidechains for scalability in the context of the Lightning Network (LN). By utilizing sidechains, end users can "live" in these separate chains instead of directly on the LN, which offers benefits such as not requiring bitcoin blockspace for new user onboarding and eliminating the need to lock funds for inbound capacity. The author also mentions the use - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_I-want-to-rebuild-the-GUI-in-JavaScript.xml b/static/bitcoin-dev/Jan_2020/combined_I-want-to-rebuild-the-GUI-in-JavaScript.xml index 435356f4a8..a0d0d9f7c9 100644 --- a/static/bitcoin-dev/Jan_2020/combined_I-want-to-rebuild-the-GUI-in-JavaScript.xml +++ b/static/bitcoin-dev/Jan_2020/combined_I-want-to-rebuild-the-GUI-in-JavaScript.xml @@ -1,35 +1,27 @@ - + 2 Combined summary - I want to rebuild the GUI in JavaScript - 2023-08-02T01:33:31.357353+00:00 - - M.K. Safi 2020-01-16 18:30:24+00:00 - - - Daniel Edgecumbe 2019-11-23 20:07:17+00:00 - - - Jonas Schnelli 2019-11-23 18:27:47+00:00 - - - Oscar Lafarga 2019-11-23 16:49:18+00:00 - - - M.K. Safi 2019-11-23 06:45:02+00:00 - + 2025-09-26T15:50:41.956059+00:00 + python-feedgen + + + M.K. Safi + 2020-01-16T18:30:00.000Z + + - python-feedgen + 2 Combined summary - I want to rebuild the GUI in JavaScript - 2023-08-02T01:33:31.357353+00:00 + 2025-09-26T15:50:41.956399+00:00 - In an email thread, the original sender thanks Jonas for his feedback and removes the topic from discussion on the Bitcoin Core Github issue. However, he mentions that he has been working on a proof-of-concept over the past month and has published it on GitHub for those interested in following the progress. He encourages contributions to the project and provides information on how to get involved. Jonas responds to the original sender's email, stating that the topic of rebuilding Bitcoin Core GUI using the JavaScript Electron framework is not appropriate for discussion on the Bitcoin Core Github issue. He suggests that if the original sender wants to pursue this idea, they should work on a third-party project where their Electron UI can connect to Bitcoin Core over RPC. Jonas also explains that adding an Electron/JavaScript UI to the Bitcoin Core repository is unlikely to happen due to concerns raised by Bitcoin Core contributors and users who are opposed to using a browser and JavaScript for a relatively simple user interface. He provides links to relevant Github issues for further reference.The email thread also mentions a front-end for Bitcoin available at bitcoin.electronrelocation.com, but development has been halted due to time constraints. The live demo of this front-end accepts payments and sends them via QR codes. The source code is available on git.esotericnonsense.com.A discussion on rebuilding Bitcoin Core GUI using the JavaScript Electron framework took place on the bitcoin-dev mailing list. One suggestion was to have Electron drive the UI by running bitcoind and communicating with it through RPC. However, there are concerns about achieving feature-parity with the existing Qt implementation and the need for a secure dependency management solution. The possibility of the Electron UI existing as an independent client rather than replacing the Qt UI is also discussed.In a forum post, a user expresses their desire to rebuild Bitcoin Core GUI using the Electron framework and seeks insights into the pros and cons of transitioning from Qt to Electron. However, many Bitcoin Core contributors and users are opposed to using a browser and JavaScript for a UI with simple user-stories. The user is advised to work on a third-party project where their Electron UI can connect to Bitcoin Core over RPC or contribute to incorporating long polling into Bitcoin Core. It is unlikely that an Electron/JavaScript UI will be added to the Bitcoin Core repository. Two relevant links are provided for further reading.The author of the email expresses their interest in rebuilding Bitcoin Core GUI using the Electron framework and asks if there have been any previous attempts or ongoing efforts in this direction. They propose having Electron drive the UI by running bitcoind and communicating with it through RPC but question whether this approach can achieve feature-parity with the Qt implementation, which has direct access to Bitcoin Core code. Another member of the mailing list highlights the need for secure dependency management due to the security-focused nature of Bitcoin Core software and the potential vulnerabilities in the way NPM handles Electron app dependencies. The discussion explores the possibility of the Electron UI existing as an independent client and debates whether it could replace the Qt UI. The topic of rebuilding Bitcoin Core GUI using the Electron framework is being explored with considerations for security and feature parity with the current Qt implementation. 2020-01-16T18:30:24+00:00 + In an email thread, the original sender thanks Jonas for his feedback and removes the topic from discussion on the Bitcoin Core Github issue. However, he mentions that he has been working on a proof-of-concept over the past month and has published it on GitHub for those interested in following the progress. He encourages contributions to the project and provides information on how to get involved. Jonas responds to the original sender's email, stating that the topic of rebuilding Bitcoin Core GUI using the JavaScript Electron framework is not appropriate for discussion on the Bitcoin Core Github issue. He suggests that if the original sender wants to pursue this idea, they should work on a third-party project where their Electron UI can connect to Bitcoin Core over RPC. Jonas also explains that adding an Electron/JavaScript UI to the Bitcoin Core repository is unlikely to happen due to concerns raised by Bitcoin Core contributors and users who are opposed to using a browser and JavaScript for a relatively simple user interface. He provides links to relevant Github issues for further reference.The email thread also mentions a front-end for Bitcoin available at bitcoin.electronrelocation.com, but development has been halted due to time constraints. The live demo of this front-end accepts payments and sends them via QR codes. The source code is available on git.esotericnonsense.com.A discussion on rebuilding Bitcoin Core GUI using the JavaScript Electron framework took place on the bitcoin-dev mailing list. One suggestion was to have Electron drive the UI by running bitcoind and communicating with it through RPC. However, there are concerns about achieving feature-parity with the existing Qt implementation and the need for a secure dependency management solution. The possibility of the Electron UI existing as an independent client rather than replacing the Qt UI is also discussed.In a forum post, a user expresses their desire to rebuild Bitcoin Core GUI using the Electron framework and seeks insights into the pros and cons of transitioning from Qt to Electron. However, many Bitcoin Core contributors and users are opposed to using a browser and JavaScript for a UI with simple user-stories. The user is advised to work on a third-party project where their Electron UI can connect to Bitcoin Core over RPC or contribute to incorporating long polling into Bitcoin Core. It is unlikely that an Electron/JavaScript UI will be added to the Bitcoin Core repository. Two relevant links are provided for further reading.The author of the email expresses their interest in rebuilding Bitcoin Core GUI using the Electron framework and asks if there have been any previous attempts or ongoing efforts in this direction. They propose having Electron drive the UI by running bitcoind and communicating with it through RPC but question whether this approach can achieve feature-parity with the Qt implementation, which has direct access to Bitcoin Core code. Another member of the mailing list highlights the need for secure dependency management due to the security-focused nature of Bitcoin Core software and the potential vulnerabilities in the way NPM handles Electron app dependencies. The discussion explores the possibility of the Electron UI existing as an independent client and debates whether it could replace the Qt UI. The topic of rebuilding Bitcoin Core GUI using the Electron framework is being explored with considerations for security and feature parity with the current Qt implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_Modern-Soft-Fork-Activation.xml b/static/bitcoin-dev/Jan_2020/combined_Modern-Soft-Fork-Activation.xml index 5f6ece8978..5793023daf 100644 --- a/static/bitcoin-dev/Jan_2020/combined_Modern-Soft-Fork-Activation.xml +++ b/static/bitcoin-dev/Jan_2020/combined_Modern-Soft-Fork-Activation.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Modern Soft Fork Activation - 2023-08-02T01:45:10.795578+00:00 - - Anthony Towns 2020-01-16 03:46:17+00:00 - - - Matt Corallo 2020-01-14 19:42:07+00:00 - - - Matt Corallo 2020-01-14 19:22:47+00:00 - - - Anthony Towns 2020-01-14 03:20:26+00:00 - - - Yosef 2020-01-13 08:34:24+00:00 - - - Luke Dashjr 2020-01-12 05:58:33+00:00 - - - Anthony Towns 2020-01-11 14:42:07+00:00 - - - Jeremy 2020-01-11 00:54:06+00:00 - - - Luke Dashjr 2020-01-10 23:37:49+00:00 - - - Jorge Timón 2020-01-10 23:07:00+00:00 - - - Matt Corallo 2020-01-10 22:43:35+00:00 - - - Jorge Timón 2020-01-10 22:21:51+00:00 - - - Matt Corallo 2020-01-10 21:30:09+00:00 - + 2025-09-26T15:50:48.263886+00:00 + python-feedgen + + + Matt Corallo + 2020-01-10T21:30:00.000Z + + + Jorge Timón + 2020-01-10T22:21:00.000Z + + + Matt Corallo + 2020-01-10T22:43:00.000Z + + + Jorge Timón + 2020-01-10T23:07:00.000Z + + + Luke Dashjr + 2020-01-10T23:37:00.000Z + + + Jeremy + 2020-01-11T00:54:00.000Z + + + Anthony Towns + 2020-01-11T14:42:00.000Z + + + Luke Dashjr + 2020-01-12T05:58:00.000Z + + + [bitcoin-dev] Modern Soft Fork Activation Yosef + 2020-01-13T08:34:00.000Z + + + Anthony Towns + 2020-01-14T03:20:00.000Z + + + Matt Corallo + 2020-01-14T19:22:00.000Z + + + Matt Corallo + 2020-01-14T19:42:00.000Z + + + Anthony Towns + 2020-01-16T03:46:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Modern Soft Fork Activation - 2023-08-02T01:45:10.795578+00:00 + 2025-09-26T15:50:48.265421+00:00 - The recent discussion on the activation of soft forks in Bitcoin has brought up various proposals and concerns. Matt Corallo suggested using a BIP 9 process to allow for observation and discussion time before activation, but concerns were raised about the timeline for observation. To address this, it was suggested to delay signaling until a later point release, giving miners extra time while still creating pressure to look at the changes. Another suggestion was to move signaling into the coinbase to strengthen the link between signaling and software update. The main focus of the conversation was implementing consensus changes in a way that benefits Bitcoin users without negatively impacting anyone.The ideal percentage of miners needed to upgrade to new rules was also discussed. While a higher percentage reduces the likelihood of long chains of invalid blocks, achieving a 95% threshold can be challenging. The discussion highlighted the timeline of the segwit process and its mistakes, with the belief that Matt's approach can fix many of these issues. Luke Dashjr argued that BIP 9 has flaws and proposed revising BIP 8 with a mandatory signal after the softfork period. This would address concerns about ambiguity and intentional rejection of the softfork, improving the long-term security of the network hashrate. Although the revision of BIP 8 was temporarily abandoned, it should be resumed now.The conversation also touched on the Taproot process and concerns about potential delays if the 95% readiness threshold for activation is not met. Matt suggested decreasing the threshold to around 80% to prevent malicious attempts to delay activation. Discussions about UASF approaches and potential technical problems were also held. It was clarified that long reorgs were only a possibility for old nodes and not necessarily a problem. Issues regarding p2p network splits were resolved well before activation. The community support for BIP148 and Segwit was similar months before BIP148's activation, and excluding BIP148 as an option based on developer opinions was deemed improper.Matt Corallo proposed a new activation strategy for Bitcoin consensus changes, focusing on decentralization and technicality. The proposal includes a standard BIP 9 deployment with a one-year time horizon for activation and a six-month quieting period for analysis and discussion. Users can opt into a BIP 8 deployment with a 24-month time-horizon for flag-day activation using a command-line/bitcoin.conf parameter. The goal is to ensure the Bitcoin network stays in consensus rather than relying on popularity or voting.Jeremy Rubin proposed a spork protocol upgrade model with certain properties, including avoiding activation in the face of reasonable objections, ensuring high node-level adoption, not losing hashpower to un-upgraded miners, using hashpower enforcement to de-risk upgrades, and following the will of the community without overruling reasonable objections.The activation methods for soft forks have been discussed, and it is necessary to revisit the goals and methods for activation. The requirements are to avoid activation in the face of significant objections, ensure high node-level adoption, avoid losing hashpower, use hashpower enforcement, and follow the will of the community while considering reasonable objections.In summary, the discussion on activation methods for soft forks in Bitcoin has been reopened, with a focus on avoiding activation in the face of significant, reasonable objections. The proposed solution involves a BIP 9 deployment with a one-year time horizon for activation and 95% miner readiness. If no activation occurs within a year, there will be a six-month quieting period for analysis and discussion. Users can then opt into a BIP 8 deployment with a 24-month time horizon for flag-day activation. This approach aims to balance community engagement, miner readiness, and avoiding activation within an inadequate timeframe. Furthermore, the proposal addresses the need to prevent hashpower loss from un-upgraded miners and use hashpower enforcement to de-risk the upgrade process. It emphasizes following the will of the community without overruling any reasonable objections. Overall, the discussion highlights the importance of considering the goals of soft fork activation methods and finding a balance between them to ensure a smooth transition while respecting the will of the community. 2020-01-16T03:46:17+00:00 + The recent discussion on the activation of soft forks in Bitcoin has brought up various proposals and concerns. Matt Corallo suggested using a BIP 9 process to allow for observation and discussion time before activation, but concerns were raised about the timeline for observation. To address this, it was suggested to delay signaling until a later point release, giving miners extra time while still creating pressure to look at the changes. Another suggestion was to move signaling into the coinbase to strengthen the link between signaling and software update. The main focus of the conversation was implementing consensus changes in a way that benefits Bitcoin users without negatively impacting anyone.The ideal percentage of miners needed to upgrade to new rules was also discussed. While a higher percentage reduces the likelihood of long chains of invalid blocks, achieving a 95% threshold can be challenging. The discussion highlighted the timeline of the segwit process and its mistakes, with the belief that Matt's approach can fix many of these issues. Luke Dashjr argued that BIP 9 has flaws and proposed revising BIP 8 with a mandatory signal after the softfork period. This would address concerns about ambiguity and intentional rejection of the softfork, improving the long-term security of the network hashrate. Although the revision of BIP 8 was temporarily abandoned, it should be resumed now.The conversation also touched on the Taproot process and concerns about potential delays if the 95% readiness threshold for activation is not met. Matt suggested decreasing the threshold to around 80% to prevent malicious attempts to delay activation. Discussions about UASF approaches and potential technical problems were also held. It was clarified that long reorgs were only a possibility for old nodes and not necessarily a problem. Issues regarding p2p network splits were resolved well before activation. The community support for BIP148 and Segwit was similar months before BIP148's activation, and excluding BIP148 as an option based on developer opinions was deemed improper.Matt Corallo proposed a new activation strategy for Bitcoin consensus changes, focusing on decentralization and technicality. The proposal includes a standard BIP 9 deployment with a one-year time horizon for activation and a six-month quieting period for analysis and discussion. Users can opt into a BIP 8 deployment with a 24-month time-horizon for flag-day activation using a command-line/bitcoin.conf parameter. The goal is to ensure the Bitcoin network stays in consensus rather than relying on popularity or voting.Jeremy Rubin proposed a spork protocol upgrade model with certain properties, including avoiding activation in the face of reasonable objections, ensuring high node-level adoption, not losing hashpower to un-upgraded miners, using hashpower enforcement to de-risk upgrades, and following the will of the community without overruling reasonable objections.The activation methods for soft forks have been discussed, and it is necessary to revisit the goals and methods for activation. The requirements are to avoid activation in the face of significant objections, ensure high node-level adoption, avoid losing hashpower, use hashpower enforcement, and follow the will of the community while considering reasonable objections.In summary, the discussion on activation methods for soft forks in Bitcoin has been reopened, with a focus on avoiding activation in the face of significant, reasonable objections. The proposed solution involves a BIP 9 deployment with a one-year time horizon for activation and 95% miner readiness. If no activation occurs within a year, there will be a six-month quieting period for analysis and discussion. Users can then opt into a BIP 8 deployment with a 24-month time horizon for flag-day activation. This approach aims to balance community engagement, miner readiness, and avoiding activation within an inadequate timeframe. Furthermore, the proposal addresses the need to prevent hashpower loss from un-upgraded miners and use hashpower enforcement to de-risk the upgrade process. It emphasizes following the will of the community without overruling any reasonable objections. Overall, the discussion highlights the importance of considering the goals of soft fork activation methods and finding a balance between them to ensure a smooth transition while respecting the will of the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_OP-CTV-Workshop-CFP-February-1st-2020.xml b/static/bitcoin-dev/Jan_2020/combined_OP-CTV-Workshop-CFP-February-1st-2020.xml index 81eb130977..de393066c5 100644 --- a/static/bitcoin-dev/Jan_2020/combined_OP-CTV-Workshop-CFP-February-1st-2020.xml +++ b/static/bitcoin-dev/Jan_2020/combined_OP-CTV-Workshop-CFP-February-1st-2020.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - OP_CTV Workshop & CFP February 1st, 2020 - 2023-08-02T01:44:14.067626+00:00 - - Jeremy 2020-01-18 03:58:27+00:00 - - - Jeremy 2020-01-05 01:58:00+00:00 - + 2025-09-26T15:50:37.775517+00:00 + python-feedgen + + + [bitcoin-dev] OP_CTV Workshop & CFP February 1st, 2020 Jeremy + 2020-01-05T01:58:00.000Z + + + Jeremy + 2020-01-18T03:58:00.000Z + + - python-feedgen + 2 Combined summary - OP_CTV Workshop & CFP February 1st, 2020 - 2023-08-02T01:44:14.067626+00:00 + 2025-09-26T15:50:37.776040+00:00 - Jeremy Rubin, a Bitcoin developer, is organizing a workshop on February 1st, 2020 in San Francisco to advance the development of OP_CHECKTEMPLATEVERIFY (OP_CTV). The workshop, which will take place from 10am-5pm, is primarily targeted towards Bitcoin developers, ecosystem engineers, and researchers. To attend the workshop, interested participants must complete an application form by January 15th. Additionally, the form allows individuals to indicate if they require travel sponsorship.The workshop schedule encompasses various sessions, including a BIP session, implementation session, deployment session, ecosystem support session, demo session & application talks, and a wrap-up. Coffee and registration will be available at 10:00 AM, with dinner and drinks served from 5:00 PM - 7:00 PM. Jeremy Rubin may offer travel sponsorship for a limited number of developers who would otherwise be unable to participate.For those unable to attend in person, materials from the event will be made accessible online. Participants are encouraged to share the workshop details with individuals they believe should attend but may not be aware of the event. Furthermore, there is a dedicated channel called ##ctv-bip-review for general discussions about OP_CTV. 2020-01-18T03:58:27+00:00 + Jeremy Rubin, a Bitcoin developer, is organizing a workshop on February 1st, 2020 in San Francisco to advance the development of OP_CHECKTEMPLATEVERIFY (OP_CTV). The workshop, which will take place from 10am-5pm, is primarily targeted towards Bitcoin developers, ecosystem engineers, and researchers. To attend the workshop, interested participants must complete an application form by January 15th. Additionally, the form allows individuals to indicate if they require travel sponsorship.The workshop schedule encompasses various sessions, including a BIP session, implementation session, deployment session, ecosystem support session, demo session & application talks, and a wrap-up. Coffee and registration will be available at 10:00 AM, with dinner and drinks served from 5:00 PM - 7:00 PM. Jeremy Rubin may offer travel sponsorship for a limited number of developers who would otherwise be unable to participate.For those unable to attend in person, materials from the event will be made accessible online. Participants are encouraged to share the workshop details with individuals they believe should attend but may not be aware of the event. Furthermore, there is a dedicated channel called ##ctv-bip-review for general discussions about OP_CTV. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_Onchain-fee-insurance-mechanism.xml b/static/bitcoin-dev/Jan_2020/combined_Onchain-fee-insurance-mechanism.xml index 62f25fe6cb..9391a2d45d 100644 --- a/static/bitcoin-dev/Jan_2020/combined_Onchain-fee-insurance-mechanism.xml +++ b/static/bitcoin-dev/Jan_2020/combined_Onchain-fee-insurance-mechanism.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Onchain fee insurance mechanism - 2023-08-02T01:48:36.073775+00:00 - - ZmnSCPxj 2020-02-01 00:39:36+00:00 - - - David A. Harding 2020-01-31 21:01:29+00:00 - - - ZmnSCPxj 2020-01-31 03:42:08+00:00 - + 2025-09-26T15:50:56.642365+00:00 + python-feedgen + + + [bitcoin-dev] Onchain fee insurance mechanism ZmnSCPxj + 2020-01-31T03:42:00.000Z + + + David A. Harding + 2020-01-31T21:01:00.000Z + + + ZmnSCPxj + 2020-02-01T00:39:00.000Z + + - python-feedgen + 2 Combined summary - Onchain fee insurance mechanism - 2023-08-02T01:48:36.073775+00:00 + 2025-09-26T15:50:56.642909+00:00 - In an email conversation between ZmnSCPxj and David on Bitcoin development, a mechanism for feerate insurance against onchain feerate spikes is proposed. The proposal involves Alice and Ingrid arranging a series of transactions with a specific locktime and sequence. However, the plan has a flaw as Ingrid can rescind the pre-signed transactions before confirmation by double spending her UTXO via an RBF fee bump.To address this issue, a patch is suggested that allows the Ingrid-input to be under the control of both Ingrid and Alice using a 2-of-2 mechanism. However, this solution leads to new problems of denial of service. Another possible insurance policy is proposed for Lightning channel closures. In this scenario, Alice prepays Ingrid using a CoinJoined transaction for the combined premium plus Ingrid inputs value locked to Alice && Ingrid. At each commitment transaction signing, there is an additional unencumbered tiny output that Alice can claim immediately. To ensure flexibility in closing the channel, Ingrid and Alice create an insurance transaction with high feerate that spends the tiny output and the Alice&&Ingrid output. The fees are deducted from the Alice&&Ingrid output, and the remaining amount is returned to Ingrid. If fees are low at the time of unilateral close, Alice can claim the tiny output itself. However, if fees are high, Alice sacrifices the tiny output and attaches the insurance transaction with a high feerate.If Ingrid does not cooperate on a new commitment transaction, Alice can drop onchain and punish Ingrid by dropping the previous commitment and broadcasting the insurance transaction. The upper bound for what Alice will pay to ensure its channel is closeable at any time quickly is the entire point of this proposal.In a Bitcoin development discussion, ZmnSCPxj proposes a mechanism for feerate insurance against on-chain feerate spikes. The proposed mechanism involves a series of transactions with RBF enabled and no relative locktime at the current block height. Alice and Ingrid arrange inputs and outputs with Bob, Alice, and Ingrid as recipients. However, if Alice needs to trust Ingrid anyway, they might as well use an external accounting and payment mechanism.During LNConf 2019, Jack Mallers presented a proposal for creating a futures market on onchain feerates. This would create an insurance policy against increases in feerate by having miners take short positions on fees while users take long positions on fees. This mechanism is necessary to have a smooth experience interfacing between onchain and offchain transactions.Overall, the proposal aims to create a smoother experience when transferring funds between onchain and offchain, providing feerate insurance and addressing issues related to confirmation timings and fee spikes. 2020-02-01T00:39:36+00:00 + In an email conversation between ZmnSCPxj and David on Bitcoin development, a mechanism for feerate insurance against onchain feerate spikes is proposed. The proposal involves Alice and Ingrid arranging a series of transactions with a specific locktime and sequence. However, the plan has a flaw as Ingrid can rescind the pre-signed transactions before confirmation by double spending her UTXO via an RBF fee bump.To address this issue, a patch is suggested that allows the Ingrid-input to be under the control of both Ingrid and Alice using a 2-of-2 mechanism. However, this solution leads to new problems of denial of service. Another possible insurance policy is proposed for Lightning channel closures. In this scenario, Alice prepays Ingrid using a CoinJoined transaction for the combined premium plus Ingrid inputs value locked to Alice && Ingrid. At each commitment transaction signing, there is an additional unencumbered tiny output that Alice can claim immediately. To ensure flexibility in closing the channel, Ingrid and Alice create an insurance transaction with high feerate that spends the tiny output and the Alice&&Ingrid output. The fees are deducted from the Alice&&Ingrid output, and the remaining amount is returned to Ingrid. If fees are low at the time of unilateral close, Alice can claim the tiny output itself. However, if fees are high, Alice sacrifices the tiny output and attaches the insurance transaction with a high feerate.If Ingrid does not cooperate on a new commitment transaction, Alice can drop onchain and punish Ingrid by dropping the previous commitment and broadcasting the insurance transaction. The upper bound for what Alice will pay to ensure its channel is closeable at any time quickly is the entire point of this proposal.In a Bitcoin development discussion, ZmnSCPxj proposes a mechanism for feerate insurance against on-chain feerate spikes. The proposed mechanism involves a series of transactions with RBF enabled and no relative locktime at the current block height. Alice and Ingrid arrange inputs and outputs with Bob, Alice, and Ingrid as recipients. However, if Alice needs to trust Ingrid anyway, they might as well use an external accounting and payment mechanism.During LNConf 2019, Jack Mallers presented a proposal for creating a futures market on onchain feerates. This would create an insurance policy against increases in feerate by having miners take short positions on fees while users take long positions on fees. This mechanism is necessary to have a smooth experience interfacing between onchain and offchain transactions.Overall, the proposal aims to create a smoother experience when transferring funds between onchain and offchain, providing feerate insurance and addressing issues related to confirmation timings and fee spikes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_PSBT-Addition-BIP-174-for-authenticating-source-output-PSBT-files.xml b/static/bitcoin-dev/Jan_2020/combined_PSBT-Addition-BIP-174-for-authenticating-source-output-PSBT-files.xml index 1b364a807b..eaf641811f 100644 --- a/static/bitcoin-dev/Jan_2020/combined_PSBT-Addition-BIP-174-for-authenticating-source-output-PSBT-files.xml +++ b/static/bitcoin-dev/Jan_2020/combined_PSBT-Addition-BIP-174-for-authenticating-source-output-PSBT-files.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - PSBT Addition (BIP 174) for authenticating source/output PSBT files - 2023-08-02T01:45:43.773454+00:00 - - Andrew Chow 2020-01-13 23:18:34+00:00 - - - Peter D. Gray 2020-01-13 20:29:11+00:00 - - - Andrew Chow 2020-01-13 17:05:10+00:00 - - - Peter D. Gray 2020-01-13 14:28:17+00:00 - - - Andrew Chow 2020-01-13 06:39:28+00:00 - - - Dmitry Petukhov 2020-01-11 20:17:05+00:00 - - - Peter D. Gray 2020-01-11 17:29:06+00:00 - + 2025-09-26T15:50:50.377815+00:00 + python-feedgen + + + [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files Peter D. Gray + 2020-01-11T17:29:00.000Z + + + Dmitry Petukhov + 2020-01-11T20:17:00.000Z + + + Andrew Chow + 2020-01-13T06:39:00.000Z + + + Peter D. Gray + 2020-01-13T14:28:00.000Z + + + Andrew Chow + 2020-01-13T17:05:00.000Z + + + Peter D. Gray + 2020-01-13T20:29:00.000Z + + + Andrew Chow + 2020-01-13T23:18:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - PSBT Addition (BIP 174) for authenticating source/output PSBT files - 2023-08-02T01:45:43.773454+00:00 + 2025-09-26T15:50:50.378734+00:00 - The Bitcoin-dev mailing list recently had a discussion on how to protect against man-in-the-middle (MiTM) attacks in partially-signed bitcoin transactions (PSBTs). One proposal was to add authentication signatures to the PSBT structure, with one signature over the source PSBT file and another over all the bytes of the resulting signed PSBT up to that point. However, some participants argued that this would add unnecessary complexity to the PSBT structure and suggested using out-of-band communication for MiTM protection instead. They also noted that if participants received the same PSBT at the start, they could check the signature by an authority on the 'correctness' of the original PSBT.During the discussion, Peter D. Gray proposed adding signatures in fixed-width without DER-encoding as a way to detect errors or attacks in PSBTs. He suggested putting signatures at the end of the file with fixed byte offset, which would allow for a conservative PSBT parser to verify the signature before parsing the rest of the file. Andrew Chow raised concerns about the threat model and what was being protected, questioning how useful the signature would be if the signer had bugs and parsing issues. He also pointed out that Gray's proposal only protects against specific legs of the entire protocol, and not every MiTM.Another suggestion was to separate the signature from the PSBT and send it along with the PSBT as part of the transport protocol. The proposal aimed to protect against PSBT parsing bugs by using byte-level signatures on the complete file content. It was suggested that pre-sharing a public key with the signer could help authenticate incoming PSBTs. Some participants suggested implementing the scheme with proprietary keys, while others recommended waiting for officially-assigned key numbers.The discussion also covered issues related to deserialization bugs and reconstruction of original fields in the PSBT. Finally, it was acknowledged that if an attacker controlled both directions of the PSBT, then the proposed solutions could not prevent the intended harm.In summary, the Bitcoin-dev mailing list discussed adding signature fields to partially signed Bitcoin transactions (PSBTs) to protect against man-in-the-middle attacks. Participants expressed concerns about bugs in PSBT signers that could reveal private keys or corrupt the transaction display while also noting that currently, it is challenging to determine what is signed without a complete understanding of the transaction, input UTXO, and PSBT file contents. One proposed solution is to add byte-level signatures on the whole file content to safeguard against PSBT parsing bugs. Another suggestion was to pre-share a public key with the signer to reduce the chance of MiTM attacks. However, critics argue that a signature separate from the PSBT could be used for MiTM protection, making additional fields unnecessary. The discussion focused on adding two signatures to PSBT for MiTM protection. One signature would cover all the bytes of the original PSBT file in the PSBT globals section, while the second would be added to the last key/value pair in the output section. However, some participants proposed placing these signatures in a container separate from the PSBT itself. There are concerns about adding complexity to the basic level of PSBT and increasing the chance of bugs. Additionally, if there is a MiTM who can modify the PSBT, they can modify the result of the signed PSBT to drop the auth signatures. Therefore, one should already have a signature covering everything one's auth signature would cover when processing a PSBT. Participants agreed that verification of these signatures is crucial. Lastly, some suggested doing the protection via out-of-band communication such as PGP signing the PSBT or sending the signature separately. The participants discussed the pros and cons of adding signatures to PSBT for MiTM protection, highlighting different perspectives.In a bitcoin-dev thread, Peter D. Gray suggested adding signatures to the Partially Signed Bitcoin Transactions (PSBT) to detect and mitigate some broad "bug-classes." However, in a Bitcoin mailing list, Andrew Chow disagreed with Gray's proposal to add man-in-the-middle (MiTM) protection within the PSBT structure itself. He argued that it is largely unnecessary to add new fields and recommended verifying the signatures of each participant in the transaction. Chow also suggested PGP signing the PSBT as a means of MiTM protection.Dmitry Petukhov expressed skepticism about Gray's proposal, arguing that authenticating the contents of the PSBT is independent of the signing action and that participants should check the signature by an authority who created the PSBT. Petukhov believed that adding additional ordering or other structural requirements over a simple key-value structure would add complexity to PSBT processing, increasing the chance of bugs. However, he acknowledged that if Gray's scheme shows its usefulness, it could become a de-facto standard with proprietary keys.Gray's proposal is byte-level on the whole file contents, not based on sub-sections or fields inside the file. He wants these signatures to protect against PSBT parsing bugs, but there are non-linear 2020-01-13T23:18:34+00:00 + The Bitcoin-dev mailing list recently had a discussion on how to protect against man-in-the-middle (MiTM) attacks in partially-signed bitcoin transactions (PSBTs). One proposal was to add authentication signatures to the PSBT structure, with one signature over the source PSBT file and another over all the bytes of the resulting signed PSBT up to that point. However, some participants argued that this would add unnecessary complexity to the PSBT structure and suggested using out-of-band communication for MiTM protection instead. They also noted that if participants received the same PSBT at the start, they could check the signature by an authority on the 'correctness' of the original PSBT.During the discussion, Peter D. Gray proposed adding signatures in fixed-width without DER-encoding as a way to detect errors or attacks in PSBTs. He suggested putting signatures at the end of the file with fixed byte offset, which would allow for a conservative PSBT parser to verify the signature before parsing the rest of the file. Andrew Chow raised concerns about the threat model and what was being protected, questioning how useful the signature would be if the signer had bugs and parsing issues. He also pointed out that Gray's proposal only protects against specific legs of the entire protocol, and not every MiTM.Another suggestion was to separate the signature from the PSBT and send it along with the PSBT as part of the transport protocol. The proposal aimed to protect against PSBT parsing bugs by using byte-level signatures on the complete file content. It was suggested that pre-sharing a public key with the signer could help authenticate incoming PSBTs. Some participants suggested implementing the scheme with proprietary keys, while others recommended waiting for officially-assigned key numbers.The discussion also covered issues related to deserialization bugs and reconstruction of original fields in the PSBT. Finally, it was acknowledged that if an attacker controlled both directions of the PSBT, then the proposed solutions could not prevent the intended harm.In summary, the Bitcoin-dev mailing list discussed adding signature fields to partially signed Bitcoin transactions (PSBTs) to protect against man-in-the-middle attacks. Participants expressed concerns about bugs in PSBT signers that could reveal private keys or corrupt the transaction display while also noting that currently, it is challenging to determine what is signed without a complete understanding of the transaction, input UTXO, and PSBT file contents. One proposed solution is to add byte-level signatures on the whole file content to safeguard against PSBT parsing bugs. Another suggestion was to pre-share a public key with the signer to reduce the chance of MiTM attacks. However, critics argue that a signature separate from the PSBT could be used for MiTM protection, making additional fields unnecessary. The discussion focused on adding two signatures to PSBT for MiTM protection. One signature would cover all the bytes of the original PSBT file in the PSBT globals section, while the second would be added to the last key/value pair in the output section. However, some participants proposed placing these signatures in a container separate from the PSBT itself. There are concerns about adding complexity to the basic level of PSBT and increasing the chance of bugs. Additionally, if there is a MiTM who can modify the PSBT, they can modify the result of the signed PSBT to drop the auth signatures. Therefore, one should already have a signature covering everything one's auth signature would cover when processing a PSBT. Participants agreed that verification of these signatures is crucial. Lastly, some suggested doing the protection via out-of-band communication such as PGP signing the PSBT or sending the signature separately. The participants discussed the pros and cons of adding signatures to PSBT for MiTM protection, highlighting different perspectives.In a bitcoin-dev thread, Peter D. Gray suggested adding signatures to the Partially Signed Bitcoin Transactions (PSBT) to detect and mitigate some broad "bug-classes." However, in a Bitcoin mailing list, Andrew Chow disagreed with Gray's proposal to add man-in-the-middle (MiTM) protection within the PSBT structure itself. He argued that it is largely unnecessary to add new fields and recommended verifying the signatures of each participant in the transaction. Chow also suggested PGP signing the PSBT as a means of MiTM protection.Dmitry Petukhov expressed skepticism about Gray's proposal, arguing that authenticating the contents of the PSBT is independent of the signing action and that participants should check the signature by an authority who created the PSBT. Petukhov believed that adding additional ordering or other structural requirements over a simple key-value structure would add complexity to PSBT processing, increasing the chance of bugs. However, he acknowledged that if Gray's scheme shows its usefulness, it could become a de-facto standard with proprietary keys.Gray's proposal is byte-level on the whole file contents, not based on sub-sections or fields inside the file. He wants these signatures to protect against PSBT parsing bugs, but there are non-linear - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_Payswap.xml b/static/bitcoin-dev/Jan_2020/combined_Payswap.xml index 6d75116556..71b3c3dcef 100644 --- a/static/bitcoin-dev/Jan_2020/combined_Payswap.xml +++ b/static/bitcoin-dev/Jan_2020/combined_Payswap.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Payswap - 2023-08-02T01:48:05.384520+00:00 - - ZmnSCPxj 2020-01-24 10:11:55+00:00 - - - ZmnSCPxj 2020-01-21 04:38:07+00:00 - + 2025-09-26T15:50:52.464635+00:00 + python-feedgen + + + [bitcoin-dev] Payswap ZmnSCPxj + 2020-01-21T04:38:00.000Z + + + ZmnSCPxj + 2020-01-24T10:11:00.000Z + + - python-feedgen + 2 Combined summary - Payswap - 2023-08-02T01:48:05.384520+00:00 + 2025-09-26T15:50:52.465080+00:00 - ZmnSCPxj, a contributor on the lightning-dev forum, has proposed a circular self-payment mechanism for hiding payment direction from third-party nodes. The mechanism involves the source paying a larger amount to the destination and the destination returning the difference. This can be achieved using CoinSwap, which misleads onchain analysis.To implement this mechanism, the Payswap payment flow is used. The sender locates UTXOs totaling an amount equal to or greater than the payment amount and reveals this sum to the destination. The destination then locates UTXOs totaling an amount equal to or greater than the difference between the sender's total and the payment amount. A setup is created where the destination receives all the sender's coins and the sender receives the difference as change. This setup is executed through a CoinSwap transaction, completing the payment protocol. However, this approach requires more transactions than Payjoin, making it more expensive in terms of blockspace.It should be noted that the protocol can be aborted by one participant, resulting in spending onchain fees to back out of the protocol. Additionally, the CoinSwap overhead is comparable to setting up a temporary Lightning Network channel. As a result, it might be more efficient to implement all CoinSwap protocols over Lightning.ZmnSCPxj suggests that the correct order for this mechanism would be for the payer to initiate the Scriptless Script payment to the payee first, followed by the payee instantiating the change back to the payer. By using some form of Scriptless Script, it is possible to implement a proof-of-payment system similar to Lightning. This system could be useful for proving to an auditor that a payment has been made without revealing this information to anyone other than the auditor.Both the payer and payee can generate a scalar, with the payee providing a signed invoice (using the Lightning BOLT11 invoice format) attesting to the payment point. The payment point is calculated as the generator point multiplied by the payee scalar. The payer then instantiates the Scriptless Script PTLC, requiring knowledge of both the payee and payer scalars. The payee subsequently instantiates the change Scriptless Script PTLC, requiring knowledge of the payer scalar.Finally, the payee claims the change, allowing the payer to claim the full transfer while revealing the payee scalar as a proof-of-payment. This proposal is currently being considered by the community as a way to enhance privacy and security in transactions. 2020-01-24T10:11:55+00:00 + ZmnSCPxj, a contributor on the lightning-dev forum, has proposed a circular self-payment mechanism for hiding payment direction from third-party nodes. The mechanism involves the source paying a larger amount to the destination and the destination returning the difference. This can be achieved using CoinSwap, which misleads onchain analysis.To implement this mechanism, the Payswap payment flow is used. The sender locates UTXOs totaling an amount equal to or greater than the payment amount and reveals this sum to the destination. The destination then locates UTXOs totaling an amount equal to or greater than the difference between the sender's total and the payment amount. A setup is created where the destination receives all the sender's coins and the sender receives the difference as change. This setup is executed through a CoinSwap transaction, completing the payment protocol. However, this approach requires more transactions than Payjoin, making it more expensive in terms of blockspace.It should be noted that the protocol can be aborted by one participant, resulting in spending onchain fees to back out of the protocol. Additionally, the CoinSwap overhead is comparable to setting up a temporary Lightning Network channel. As a result, it might be more efficient to implement all CoinSwap protocols over Lightning.ZmnSCPxj suggests that the correct order for this mechanism would be for the payer to initiate the Scriptless Script payment to the payee first, followed by the payee instantiating the change back to the payer. By using some form of Scriptless Script, it is possible to implement a proof-of-payment system similar to Lightning. This system could be useful for proving to an auditor that a payment has been made without revealing this information to anyone other than the auditor.Both the payer and payee can generate a scalar, with the payee providing a signed invoice (using the Lightning BOLT11 invoice format) attesting to the payment point. The payment point is calculated as the generator point multiplied by the payee scalar. The payer then instantiates the Scriptless Script PTLC, requiring knowledge of both the payee and payer scalars. The payee subsequently instantiates the change Scriptless Script PTLC, requiring knowledge of the payer scalar.Finally, the payee claims the change, allowing the payer to claim the full transfer while revealing the payee scalar as a proof-of-payment. This proposal is currently being considered by the community as a way to enhance privacy and security in transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_Purge-attacks-spin-on-sabotage-attacks-.xml b/static/bitcoin-dev/Jan_2020/combined_Purge-attacks-spin-on-sabotage-attacks-.xml index ff97085d44..0af56e64dc 100644 --- a/static/bitcoin-dev/Jan_2020/combined_Purge-attacks-spin-on-sabotage-attacks-.xml +++ b/static/bitcoin-dev/Jan_2020/combined_Purge-attacks-spin-on-sabotage-attacks-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Purge attacks (spin on sabotage attacks) - 2023-08-02T01:49:03.631211+00:00 - - Mike Kelly 2020-02-10 15:28:20+00:00 - - - ZmnSCPxj 2020-02-09 23:59:56+00:00 - - - Mike Kelly 2020-02-09 10:15:18+00:00 - - - ZmnSCPxj 2020-02-09 00:00:41+00:00 - - - Mike Kelly 2020-02-08 08:11:17+00:00 - - - ZmnSCPxj 2020-02-08 02:15:32+00:00 - - - Mike Kelly 2020-02-07 13:55:29+00:00 - - - ha su 2020-01-31 13:38:22+00:00 - + 2025-09-26T15:50:39.867038+00:00 + python-feedgen + + + [bitcoin-dev] Purge attacks (spin on sabotage attacks) ha su + 2020-01-31T13:38:00.000Z + + + Mike Kelly + 2020-02-07T13:55:00.000Z + + + ZmnSCPxj + 2020-02-08T02:15:00.000Z + + + Mike Kelly + 2020-02-08T08:11:00.000Z + + + ZmnSCPxj + 2020-02-09T00:00:00.000Z + + + Mike Kelly + 2020-02-09T10:15:00.000Z + + + ZmnSCPxj + 2020-02-09T23:59:00.000Z + + + Mike Kelly + 2020-02-10T15:28:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Purge attacks (spin on sabotage attacks) - 2023-08-02T01:49:03.631211+00:00 + 2025-09-26T15:50:39.868046+00:00 - The conversation focuses on the concept of Purge attacks, a form of sabotage attack in Bitcoin. Purge attacks involve replacing recent blocks with empty blocks, causing previously confirmed transactions to return to the mempool. This allows individuals to double-spend their transactions back to themselves. The goal of this attack is to undermine trust in Bitcoin's assurances and disrupt coordination among users.ZmnSCPxj argues that violating the principle of Blockchain Self-Containment, which ensures consensus rules only check what is in the blockchain, can lead to persistent chainsplits, even with innocent miners finding blocks at the same time. M suggests discouraging miners from including conflicting transactions but acknowledges that it may require making consensus dependent on the state of the mempool, potentially leading to chainsplits.The conversation also touches on other topics such as defending against purge attacks by offering increased mining fees for censored transactions and the use of replace by fee (RBF) in opportunistic attacks. ZmnSCPxj warns that defending against RBF-based attacks is not a winning game. The discussion then shifts to the potential risks posed by G20 states seizing major mining operations and how limiting RBF options could force them to resort to denial-of-service (DoS) mode.Overall, the conversation highlights the potential consequences of Purge attacks and the challenges in preventing them. It emphasizes the need for coordination among users and the importance of maintaining the censorship-resistance and integrity of Bitcoin. The full report on mitigations against sabotage attacks can be found at https://blog.deribit.com/insights/destabilizing-bitcoin-consensus-with-purge-attacks/. Feedback on the issue is welcomed. 2020-02-10T15:28:20+00:00 + The conversation focuses on the concept of Purge attacks, a form of sabotage attack in Bitcoin. Purge attacks involve replacing recent blocks with empty blocks, causing previously confirmed transactions to return to the mempool. This allows individuals to double-spend their transactions back to themselves. The goal of this attack is to undermine trust in Bitcoin's assurances and disrupt coordination among users.ZmnSCPxj argues that violating the principle of Blockchain Self-Containment, which ensures consensus rules only check what is in the blockchain, can lead to persistent chainsplits, even with innocent miners finding blocks at the same time. M suggests discouraging miners from including conflicting transactions but acknowledges that it may require making consensus dependent on the state of the mempool, potentially leading to chainsplits.The conversation also touches on other topics such as defending against purge attacks by offering increased mining fees for censored transactions and the use of replace by fee (RBF) in opportunistic attacks. ZmnSCPxj warns that defending against RBF-based attacks is not a winning game. The discussion then shifts to the potential risks posed by G20 states seizing major mining operations and how limiting RBF options could force them to resort to denial-of-service (DoS) mode.Overall, the conversation highlights the potential consequences of Purge attacks and the challenges in preventing them. It emphasizes the need for coordination among users and the importance of maintaining the censorship-resistance and integrity of Bitcoin. The full report on mitigations against sabotage attacks can be found at https://blog.deribit.com/insights/destabilizing-bitcoin-consensus-with-purge-attacks/. Feedback on the issue is welcomed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2020/combined_op-checktemplateverify-and-number-of-inputs.xml b/static/bitcoin-dev/Jan_2020/combined_op-checktemplateverify-and-number-of-inputs.xml index a29f08d001..753b7a90cb 100644 --- a/static/bitcoin-dev/Jan_2020/combined_op-checktemplateverify-and-number-of-inputs.xml +++ b/static/bitcoin-dev/Jan_2020/combined_op-checktemplateverify-and-number-of-inputs.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - op_checktemplateverify and number of inputs - 2023-08-02T01:48:17.183514+00:00 - - Jeremy 2020-01-26 17:23:57+00:00 - - - Billy 2020-01-25 01:50:49+00:00 - + 2025-09-26T15:50:46.151356+00:00 + python-feedgen + + + [bitcoin-dev] op_checktemplateverify and number of inputs Billy + 2020-01-25T01:50:00.000Z + + + Jeremy + 2020-01-26T17:23:00.000Z + + - python-feedgen + 2 Combined summary - op_checktemplateverify and number of inputs - 2023-08-02T01:48:17.183514+00:00 + 2025-09-26T15:50:46.151827+00:00 - In an email exchange between Billy and Jeremy Rubin, the two delve into a discussion regarding the necessity of restricting the number of inputs in order to prevent TXID malleability. It is established that committing to all required information entails committing to the number of inputs in a transaction, which enables non-interactive layer 2 protocols that rely on TXID non-malleability.Billy raises the point that allowing any number of inputs could be advantageous. However, Jeremy suggests that the flexibility should be kept separate from the OP directly. He proposes using something like OP_CAT, where users can utilize an any number of inputs template by passing in the # of inputs and sequences hash as arguments to the function. Furthermore, Jeremy offers to address Billy's post on bitcointalk.org separately as it raises a different set of questions.The crux of the issue revolves around the op_ctv Bitcoin script code and the requirement to specify a number of inputs. The poster expresses skepticism regarding the need for this requirement and questions why it is being enforced. While they acknowledge the potential benefits of specifying a number of inputs, they fail to comprehend why it should be mandatory for users of the op. They propose that if the op allowed for both cases, allowing users to specify a number of inputs or allow any number, it would offer the best of both worlds.To facilitate further discussion on this matter, the poster initiates a conversation on bitcointalk.org and provides a link to the forum. Although the specific outcome they hope to achieve through this discussion remains unclear, their intention is to explore the topic in greater depth and foster dialogue among the community. 2020-01-26T17:23:57+00:00 + In an email exchange between Billy and Jeremy Rubin, the two delve into a discussion regarding the necessity of restricting the number of inputs in order to prevent TXID malleability. It is established that committing to all required information entails committing to the number of inputs in a transaction, which enables non-interactive layer 2 protocols that rely on TXID non-malleability.Billy raises the point that allowing any number of inputs could be advantageous. However, Jeremy suggests that the flexibility should be kept separate from the OP directly. He proposes using something like OP_CAT, where users can utilize an any number of inputs template by passing in the # of inputs and sequences hash as arguments to the function. Furthermore, Jeremy offers to address Billy's post on bitcointalk.org separately as it raises a different set of questions.The crux of the issue revolves around the op_ctv Bitcoin script code and the requirement to specify a number of inputs. The poster expresses skepticism regarding the need for this requirement and questions why it is being enforced. While they acknowledge the potential benefits of specifying a number of inputs, they fail to comprehend why it should be mandatory for users of the op. They propose that if the op allowed for both cases, allowing users to specify a number of inputs or allow any number, it would offer the best of both worlds.To facilitate further discussion on this matter, the poster initiates a conversation on bitcointalk.org and provides a link to the forum. Although the specific outcome they hope to achieve through this discussion remains unclear, their intention is to explore the topic in greater depth and foster dialogue among the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2021/combined_Bech32m-BIP-new-checksum-and-usage-for-segwit-address.xml b/static/bitcoin-dev/Jan_2021/combined_Bech32m-BIP-new-checksum-and-usage-for-segwit-address.xml index 8bba50a046..650af02695 100644 --- a/static/bitcoin-dev/Jan_2021/combined_Bech32m-BIP-new-checksum-and-usage-for-segwit-address.xml +++ b/static/bitcoin-dev/Jan_2021/combined_Bech32m-BIP-new-checksum-and-usage-for-segwit-address.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Bech32m BIP: new checksum, and usage for segwit address - 2023-08-02T02:59:37.533012+00:00 - - Pieter Wuille 2021-01-20 00:29:36+00:00 - - - Pieter Wuille 2021-01-19 17:57:08+00:00 - - - nakagat 2021-01-18 05:59:05+00:00 - - - Pieter Wuille 2021-01-18 04:15:49+00:00 - - - nakagat 2021-01-15 08:01:24+00:00 - - - Rusty Russell 2021-01-09 05:00:24+00:00 - - - Pieter Wuille 2021-01-05 01:25:29+00:00 - - - Pieter Wuille 2021-01-05 00:14:12+00:00 - + 2025-09-26T15:59:29.947702+00:00 + python-feedgen + + + [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address Pieter Wuille + 2021-01-05T00:14:00.000Z + + + Pieter Wuille + 2021-01-05T01:25:00.000Z + + + Rusty Russell + 2021-01-09T05:00:00.000Z + + + nakagat + 2021-01-15T08:01:00.000Z + + + Pieter Wuille + 2021-01-18T04:15:00.000Z + + + nakagat + 2021-01-18T05:59:00.000Z + + + Pieter Wuille + 2021-01-19T17:57:00.000Z + + + Pieter Wuille + 2021-01-20T00:29:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Bech32m BIP: new checksum, and usage for segwit address - 2023-08-02T02:59:37.533012+00:00 + 2025-09-26T15:59:29.948714+00:00 - In an email exchange, nakagat and Pieter discussed the differences between "checksum = hash (hrp, data)" and the BCH-based checksum used in Bech32. Pieter explained that while they have error-detection properties, the Bech32 checksum is better at detecting certain subsets of errors. He clarified that the goal of Bech32/Bech32m is not to have error detection properties equivalent to a hash.Nakagat proposed creating BECH32M_CONST from hrp and data instead of constants to maintain the same error position as Bech32. Pieter explained that the polymod function as a checksum detects some kinds of errors better than others, and non-uniformity is needed in this case.Pieter Wuille updated several reference implementations to support Bech32m and made updates to the BIP draft. He also opened a pull request on Bitcoin Core and added links for more reference implementations. Nakagawa implemented Bech32m in Go and asked if the Checksum had to be fixed, to which Pieter provided three possible interpretations.Pieter Wuille proposed changes to the checksum in native segwit addresses for v1 and higher in a BIP draft. He introduced Bech32m as a tweaked variant of Bech32 and replaced the corresponding section in BIP173. The proposal prescribes using Bech32 for v0 witness addresses and Bech32m for other versions.The BIP draft for changing the checksum in native segwit addresses for v1 and higher was created following discussions on the Bitcoin-Dev mailing list. Pieter invited comments, suggestions, and ideas on the proposal and provided a link to the Github repository containing the BIP draft. 2021-01-20T00:29:36+00:00 + In an email exchange, nakagat and Pieter discussed the differences between "checksum = hash (hrp, data)" and the BCH-based checksum used in Bech32. Pieter explained that while they have error-detection properties, the Bech32 checksum is better at detecting certain subsets of errors. He clarified that the goal of Bech32/Bech32m is not to have error detection properties equivalent to a hash.Nakagat proposed creating BECH32M_CONST from hrp and data instead of constants to maintain the same error position as Bech32. Pieter explained that the polymod function as a checksum detects some kinds of errors better than others, and non-uniformity is needed in this case.Pieter Wuille updated several reference implementations to support Bech32m and made updates to the BIP draft. He also opened a pull request on Bitcoin Core and added links for more reference implementations. Nakagawa implemented Bech32m in Go and asked if the Checksum had to be fixed, to which Pieter provided three possible interpretations.Pieter Wuille proposed changes to the checksum in native segwit addresses for v1 and higher in a BIP draft. He introduced Bech32m as a tweaked variant of Bech32 and replaced the corresponding section in BIP173. The proposal prescribes using Bech32 for v0 witness addresses and Bech32m for other versions.The BIP draft for changing the checksum in native segwit addresses for v1 and higher was created following discussions on the Bitcoin-Dev mailing list. Pieter invited comments, suggestions, and ideas on the proposal and provided a link to the Github repository containing the BIP draft. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2021/combined_Hardware-wallets-and-advanced-Bitcoin-features.xml b/static/bitcoin-dev/Jan_2021/combined_Hardware-wallets-and-advanced-Bitcoin-features.xml index 495dba10d4..a7a22ea816 100644 --- a/static/bitcoin-dev/Jan_2021/combined_Hardware-wallets-and-advanced-Bitcoin-features.xml +++ b/static/bitcoin-dev/Jan_2021/combined_Hardware-wallets-and-advanced-Bitcoin-features.xml @@ -1,35 +1,43 @@ - + 2 - Combined summary - Hardware wallets and "advanced" Bitcoin features - 2023-08-02T03:02:18.094108+00:00 - - darosior 2021-01-17 10:02:32+00:00 - - - Devrandom 2021-01-17 02:40:44+00:00 - - - Antoine Riard 2021-01-17 01:31:07+00:00 - - - ZmnSCPxj 2021-01-15 00:28:21+00:00 - - - Kevin Loaec 2021-01-14 18:17:09+00:00 - + Combined summary - Hardware wallets and "advanced" Bitcoin features + 2025-09-26T15:59:34.184210+00:00 + python-feedgen + + + [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features Kevin Loaec + 2021-01-14T18:17:00.000Z + + + ZmnSCPxj + 2021-01-15T00:28:00.000Z + + + Antoine Riard + 2021-01-17T01:31:00.000Z + + + Devrandom + 2021-01-17T02:40:00.000Z + + + darosior + 2021-01-17T10:02:00.000Z + + - python-feedgen + 2 - Combined summary - Hardware wallets and "advanced" Bitcoin features - 2023-08-02T03:02:18.094108+00:00 + Combined summary - Hardware wallets and "advanced" Bitcoin features + 2025-09-26T15:59:34.184964+00:00 - Hardware wallets (HW) are an essential tool in protecting private keys and safeguarding user devices. The purpose of this email is to initiate a discussion on improving HW for all bitcoiners, with a particular focus on addressing concerns relevant to the development of Revault, a vault protocol. The proposed improvements encompass various aspects such as displaying the Bitcoin Script itself, recognizing pubkeys or xpubs not associated with private keys, enhancing Bitcoin compatibility, monitoring signed inputs, and implementing a mechanism to verify "clawback" signatures. These enhancements are crucial for ensuring robust security, especially in situations where the transaction crafting computer may be compromised. It should be noted that Revault does not intend to manufacture hardware wallets but hopes that existing and future manufacturers will prioritize the implementation of strong security measures for their users.The primary obstacle faced by hardware wallets is their lack of internet access. This limitation becomes problematic when broadcasting clawback transactions at specific block heights. Without online connectivity, the hardware wallet cannot determine the current block height, necessitating trust in the software to execute the clawback. However, devrandom believes it is possible to achieve the desired level of "liveness" without compromising the air-gap too much. This objective can be accomplished through UTXO oracles, which attest to the UTXO set, along with a narrow optical or serial protocol for the air-gap connection between node software and signer. Operators capable of responding to liveness issues further contribute to maintaining security. Optionally, clock oracles utilizing the roughtime protocol can provide attestation to the current time. The Signer periodically performs several actions, including checking if the funding UTXO has been spent, verifying that the spending transaction is provided by the node, and signing a heartbeat message containing the current time if a reaction is required. The node software then relays the signed heartbeat message to the operators, who manually intervene if a heartbeat is not detected. This setup is deemed as secure as USB hardware wallets connected to online machines and can accommodate intermittently connected signers within slow-moving channels or those operating behind Tor. However, it is important to note that Lightning paper wallets are not viable due to the network's requirement for online participation.The email emphasizes that the proposed improvements would benefit all bitcoin users while also catering to "layer 2" or pre-signed transaction protocols. The aim is to encourage discussions and iterate towards a more secure and user-friendly hardware ecosystem for the entire bitcoin community. The suggested enhancements include displaying the Bitcoin Script itself, including unlock conditions, whenever possible, as well as recognizing pubkeys or xpubs that do not possess private keys and labeling them accordingly. Furthermore, ensuring compatibility with advanced Bitcoin features, tracking previously signed inputs for protocols that necessitate it, and implementing a means to verify that a "clawback" has been signed before using the same input are considered essential for robust security. Revault clarifies that its focus lies in vault protocol development rather than hardware wallet production, expressing hope that manufacturers will adopt stronger security measures that can benefit Revault protocol users.A significant concern raised in the email pertains to the risk of poisoned inputs in hardware wallets and pre-signed transaction protocols. The spending of any input within a (pre-signed) transaction renders the entire transaction invalid, thereby compromising the entire defense mechanism. To address this issue, it is proposed to keep track of inputs that have already been signed once. As most protocols require a specific signing order, incorporating a check to ensure that a "clawback" has been signed first with the same input would be highly beneficial. However, maintaining state within the hardware device necessitates a Merklized persistent data structure, storing the majority of storage within trust-minimized software. The primary challenge arises from the assumption that hardware wallets cannot have internet access, as clawback transactions often rely on specific block heights for broadcasting. If the hardware wallet cannot connect online, it remains unaware of the current block height required for timely clawback transaction broadcasting. Delayed clawbacks can provide an advantage to counterparties, enabling potential theft. Going online introduces an increased attack surface to the blockchain, which serves as proof of time passing. Consequently, active online engagement is necessary to obtain this proof through searching for the block tip.In summary, the email initiates a discussion on improving hardware wallets for bitcoin users, beginning with the requirements of the Revault vault protocol. It highlights the importance of hardware wallets in mitigating device compromises and provides links to previous work on related issues. The proposed improvements encompass various areas, including output script parsing, pubkey interpretation, Bitcoin compatibility, tracking signed inputs, and verifying "clawback" signatures. While acknowledging the challenges presented by limited memory and computational power of secure elements, the author argues that these enhancements are crucial for ensuring decent security. The email concludes by reiterating that Revault does not plan to manufacture hardware wallets but hopes that manufacturers will adopt stronger security measures to benefit all bitcoin users. 2021-01-17T10:02:32+00:00 + Hardware wallets (HW) are an essential tool in protecting private keys and safeguarding user devices. The purpose of this email is to initiate a discussion on improving HW for all bitcoiners, with a particular focus on addressing concerns relevant to the development of Revault, a vault protocol. The proposed improvements encompass various aspects such as displaying the Bitcoin Script itself, recognizing pubkeys or xpubs not associated with private keys, enhancing Bitcoin compatibility, monitoring signed inputs, and implementing a mechanism to verify "clawback" signatures. These enhancements are crucial for ensuring robust security, especially in situations where the transaction crafting computer may be compromised. It should be noted that Revault does not intend to manufacture hardware wallets but hopes that existing and future manufacturers will prioritize the implementation of strong security measures for their users.The primary obstacle faced by hardware wallets is their lack of internet access. This limitation becomes problematic when broadcasting clawback transactions at specific block heights. Without online connectivity, the hardware wallet cannot determine the current block height, necessitating trust in the software to execute the clawback. However, devrandom believes it is possible to achieve the desired level of "liveness" without compromising the air-gap too much. This objective can be accomplished through UTXO oracles, which attest to the UTXO set, along with a narrow optical or serial protocol for the air-gap connection between node software and signer. Operators capable of responding to liveness issues further contribute to maintaining security. Optionally, clock oracles utilizing the roughtime protocol can provide attestation to the current time. The Signer periodically performs several actions, including checking if the funding UTXO has been spent, verifying that the spending transaction is provided by the node, and signing a heartbeat message containing the current time if a reaction is required. The node software then relays the signed heartbeat message to the operators, who manually intervene if a heartbeat is not detected. This setup is deemed as secure as USB hardware wallets connected to online machines and can accommodate intermittently connected signers within slow-moving channels or those operating behind Tor. However, it is important to note that Lightning paper wallets are not viable due to the network's requirement for online participation.The email emphasizes that the proposed improvements would benefit all bitcoin users while also catering to "layer 2" or pre-signed transaction protocols. The aim is to encourage discussions and iterate towards a more secure and user-friendly hardware ecosystem for the entire bitcoin community. The suggested enhancements include displaying the Bitcoin Script itself, including unlock conditions, whenever possible, as well as recognizing pubkeys or xpubs that do not possess private keys and labeling them accordingly. Furthermore, ensuring compatibility with advanced Bitcoin features, tracking previously signed inputs for protocols that necessitate it, and implementing a means to verify that a "clawback" has been signed before using the same input are considered essential for robust security. Revault clarifies that its focus lies in vault protocol development rather than hardware wallet production, expressing hope that manufacturers will adopt stronger security measures that can benefit Revault protocol users.A significant concern raised in the email pertains to the risk of poisoned inputs in hardware wallets and pre-signed transaction protocols. The spending of any input within a (pre-signed) transaction renders the entire transaction invalid, thereby compromising the entire defense mechanism. To address this issue, it is proposed to keep track of inputs that have already been signed once. As most protocols require a specific signing order, incorporating a check to ensure that a "clawback" has been signed first with the same input would be highly beneficial. However, maintaining state within the hardware device necessitates a Merklized persistent data structure, storing the majority of storage within trust-minimized software. The primary challenge arises from the assumption that hardware wallets cannot have internet access, as clawback transactions often rely on specific block heights for broadcasting. If the hardware wallet cannot connect online, it remains unaware of the current block height required for timely clawback transaction broadcasting. Delayed clawbacks can provide an advantage to counterparties, enabling potential theft. Going online introduces an increased attack surface to the blockchain, which serves as proof of time passing. Consequently, active online engagement is necessary to obtain this proof through searching for the block tip.In summary, the email initiates a discussion on improving hardware wallets for bitcoin users, beginning with the requirements of the Revault vault protocol. It highlights the importance of hardware wallets in mitigating device compromises and provides links to previous work on related issues. The proposed improvements encompass various areas, including output script parsing, pubkey interpretation, Bitcoin compatibility, tracking signed inputs, and verifying "clawback" signatures. While acknowledging the challenges presented by limited memory and computational power of secure elements, the author argues that these enhancements are crucial for ensuring decent security. The email concludes by reiterating that Revault does not plan to manufacture hardware wallets but hopes that manufacturers will adopt stronger security measures to benefit all bitcoin users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2021/combined_Libre-Open-blockchain-cryptographic-ASICs.xml b/static/bitcoin-dev/Jan_2021/combined_Libre-Open-blockchain-cryptographic-ASICs.xml index f47691c5d3..674cc3d588 100644 --- a/static/bitcoin-dev/Jan_2021/combined_Libre-Open-blockchain-cryptographic-ASICs.xml +++ b/static/bitcoin-dev/Jan_2021/combined_Libre-Open-blockchain-cryptographic-ASICs.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Libre/Open blockchain / cryptographic ASICs - 2023-08-02T03:02:51.462708+00:00 - - ZmnSCPxj 2021-02-14 00:27:36+00:00 - - - Luke Kenneth Casson Leighton 2021-02-13 17:19:01+00:00 - - - Luke Kenneth Casson Leighton 2021-02-13 16:44:27+00:00 - - - Bryan Bishop 2021-02-13 14:59:29+00:00 - - - Luke Kenneth Casson Leighton 2021-02-13 09:29:38+00:00 - - - ZmnSCPxj 2021-02-13 06:10:08+00:00 - - - ZmnSCPxj 2021-02-11 08:20:54+00:00 - - - Luke Kenneth Casson Leighton 2021-02-03 14:07:24+00:00 - - - Luke Kenneth Casson Leighton 2021-02-03 13:24:13+00:00 - - - ZmnSCPxj 2021-02-03 03:17:48+00:00 - - - ZmnSCPxj 2021-02-03 02:06:46+00:00 - - - Pavol Rusnak 2021-01-26 10:47:50+00:00 - - - Luke Kenneth Casson Leighton 2021-01-25 18:00:35+00:00 - + 2025-09-26T15:59:42.766908+00:00 + python-feedgen + + + [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs Luke Kenneth Casson Leighton + 2021-01-25T18:00:00.000Z + + + Pavol Rusnak + 2021-01-26T10:47:00.000Z + + + ZmnSCPxj + 2021-02-03T02:06:00.000Z + + + ZmnSCPxj + 2021-02-03T03:17:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-03T13:24:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-03T14:07:00.000Z + + + ZmnSCPxj + 2021-02-11T08:20:00.000Z + + + ZmnSCPxj + 2021-02-13T06:10:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-13T09:29:00.000Z + + + Bryan Bishop + 2021-02-13T14:59:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-13T16:44:00.000Z + + + Luke Kenneth Casson Leighton + 2021-02-13T17:19:00.000Z + + + ZmnSCPxj + 2021-02-14T00:27:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Libre/Open blockchain / cryptographic ASICs - 2023-08-02T03:02:51.462708+00:00 + 2025-09-26T15:59:42.768391+00:00 - The discussion revolves around the vulnerability of ASICs in test modes, particularly when key material is loaded into registers or caches. The risk can be mitigated by designing state machines and using flash memory to reload flip-flops that hold settings periodically. However, the vulnerability remains, making excessive caution necessary for cryptographic chips.In an email thread on Bitcoin-dev, concerns are raised about the use of repeater-buffers in ASICs and the need for test modes in mass production. Open-sourcing hardware design also has its risks, as attackers can target specific chip areas for ESD pulse. The importance of transparency in wallet ASICs is emphasized.There is a conversation between two individuals regarding the content of emails. Bryan Bishop expresses confusion, and the other individual apologizes for any confusion caused. They also provide a link to the threads for the bitcoin-dev mailing list.Luke Kenneth Casson Leighton asks for moderated messages to be sent to a different email address. Bryan replies that he cannot see Luke's February emails in the archives. The thread for the bitcoin-dev mailing list can be found on the Linux Foundation website.ZmnSCPxj requests Luke to forward moderated messages to a different email address. ZmnSCPxj discusses the use of scan mode and proposes a masking technique. The importance of being paranoid about test modes in digital circuitry is discussed. Solutions to prevent devices from being forced into test mode are suggested.The conversation covers various topics related to digital circuitry, including inverting buffers, open-source software and hardware RTL designs, test modes, and the importance of being paranoid about them. Solutions to prevent devices from being forced into test mode are provided.The conversation discusses the impact of power efficiency on Bitcoin mining. Increasing power efficiency does not reduce the actual energy consumed by mining. The "arms race" in mining could lead to hardware backdoors. The cost of lower geometries is high, and increasing power efficiency may not benefit anyone.The challenges of designing digital ASICs are discussed, along with the importance of formal correctness proofs and simulation testing. Adding general-purpose instructions that simplify algorithms is explored. Tool licensing costs, working with foundries, and reducing risk are also mentioned.ZmnSCPxj explains that focusing on power efficiency will not reduce energy consumption in Bitcoin mining. The rational choice for miners is to buy more units instead of reducing watt consumption. ZmnSCPxj expresses interest in eco-conscious blockchain and crypto-currency products.The author has experience designing digital ASICs and suggests that smaller geometries are only necessary for specific requirements. The challenges of manual layout and tool licensing costs are discussed. The LibreSOC Project aims to create transparently-openly-developed ASICs. The cost of producing ASICs varies with geometries. The focus should be on power-efficiency.Luke asks what people would like to see happen in regards to delivering to the wider bitcoin user community. Pavol Rusnak from SatoshiLabs offers to exchange ideas and provides a link to Tropic Square's website.The author has been discussing a transparently-developed ASIC/SoC with Kanzure for some time. NLnet has obtained funding, and the author has applied for the "Assure" Programme. The goal is to create fully transparently-openly-developed ASICs for cryptographic tasks. The author is interested in bridging the funding gap and delivering to the bitcoin user community. 2021-02-14T00:27:36+00:00 + The discussion revolves around the vulnerability of ASICs in test modes, particularly when key material is loaded into registers or caches. The risk can be mitigated by designing state machines and using flash memory to reload flip-flops that hold settings periodically. However, the vulnerability remains, making excessive caution necessary for cryptographic chips.In an email thread on Bitcoin-dev, concerns are raised about the use of repeater-buffers in ASICs and the need for test modes in mass production. Open-sourcing hardware design also has its risks, as attackers can target specific chip areas for ESD pulse. The importance of transparency in wallet ASICs is emphasized.There is a conversation between two individuals regarding the content of emails. Bryan Bishop expresses confusion, and the other individual apologizes for any confusion caused. They also provide a link to the threads for the bitcoin-dev mailing list.Luke Kenneth Casson Leighton asks for moderated messages to be sent to a different email address. Bryan replies that he cannot see Luke's February emails in the archives. The thread for the bitcoin-dev mailing list can be found on the Linux Foundation website.ZmnSCPxj requests Luke to forward moderated messages to a different email address. ZmnSCPxj discusses the use of scan mode and proposes a masking technique. The importance of being paranoid about test modes in digital circuitry is discussed. Solutions to prevent devices from being forced into test mode are suggested.The conversation covers various topics related to digital circuitry, including inverting buffers, open-source software and hardware RTL designs, test modes, and the importance of being paranoid about them. Solutions to prevent devices from being forced into test mode are provided.The conversation discusses the impact of power efficiency on Bitcoin mining. Increasing power efficiency does not reduce the actual energy consumed by mining. The "arms race" in mining could lead to hardware backdoors. The cost of lower geometries is high, and increasing power efficiency may not benefit anyone.The challenges of designing digital ASICs are discussed, along with the importance of formal correctness proofs and simulation testing. Adding general-purpose instructions that simplify algorithms is explored. Tool licensing costs, working with foundries, and reducing risk are also mentioned.ZmnSCPxj explains that focusing on power efficiency will not reduce energy consumption in Bitcoin mining. The rational choice for miners is to buy more units instead of reducing watt consumption. ZmnSCPxj expresses interest in eco-conscious blockchain and crypto-currency products.The author has experience designing digital ASICs and suggests that smaller geometries are only necessary for specific requirements. The challenges of manual layout and tool licensing costs are discussed. The LibreSOC Project aims to create transparently-openly-developed ASICs. The cost of producing ASICs varies with geometries. The focus should be on power-efficiency.Luke asks what people would like to see happen in regards to delivering to the wider bitcoin user community. Pavol Rusnak from SatoshiLabs offers to exchange ideas and provides a link to Tropic Square's website.The author has been discussing a transparently-developed ASIC/SoC with Kanzure for some time. NLnet has obtained funding, and the author has applied for the "Assure" Programme. The goal is to create fully transparently-openly-developed ASICs for cryptographic tasks. The author is interested in bridging the funding gap and delivering to the bitcoin user community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2021/combined_New-PSBT-version-proposal.xml b/static/bitcoin-dev/Jan_2021/combined_New-PSBT-version-proposal.xml index cf4fd98ec8..707f1789de 100644 --- a/static/bitcoin-dev/Jan_2021/combined_New-PSBT-version-proposal.xml +++ b/static/bitcoin-dev/Jan_2021/combined_New-PSBT-version-proposal.xml @@ -1,59 +1,47 @@ - + 2 Combined summary - New PSBT version proposal - 2023-08-02T02:54:05.328979+00:00 - - Lloyd Fournier 2021-04-05 00:35:14+00:00 - - - Lloyd Fournier 2021-03-10 00:20:58+00:00 - - - Andrew Chow 2021-01-21 19:50:45+00:00 - - - Andrew Chow 2021-01-15 17:28:09+00:00 - - - Andrew Chow 2021-01-14 17:07:44+00:00 - - - Rusty Russell 2021-01-08 00:40:06+00:00 - - - Andrew Chow 2021-01-06 23:48:31+00:00 - - - Rusty Russell 2021-01-06 23:26:25+00:00 - - - Jeremy 2021-01-02 06:34:00+00:00 - - - Andrew Chow 2020-12-23 21:32:33+00:00 - - - Andrew Chow 2020-12-23 21:30:04+00:00 - - - Andrew Poelstra 2020-12-23 15:22:01+00:00 - - - fiatjaf 2020-12-23 03:30:20+00:00 - - - Andrew Chow 2020-12-22 20:12:22+00:00 - - - Andrew Poelstra 2020-12-16 17:44:11+00:00 - - - Sanket Kanjalkar 2020-12-10 11:28:23+00:00 - - - Andrew Chow 2020-12-09 22:25:37+00:00 - + 2025-09-26T15:59:36.336405+00:00 + python-feedgen + + + Jeremy + 2021-01-02T06:34:00.000Z + + + Rusty Russell + 2021-01-06T23:26:00.000Z + + + Andrew Chow + 2021-01-06T23:48:00.000Z + + + Rusty Russell + 2021-01-08T00:40:00.000Z + + + Andrew Chow + 2021-01-14T17:07:00.000Z + + + Andrew Chow + 2021-01-15T17:28:00.000Z + + + Andrew Chow + 2021-01-21T19:50:00.000Z + + + Lloyd Fournier + 2021-03-10T00:20:00.000Z + + + Lloyd Fournier + 2021-04-05T00:35:00.000Z + + @@ -71,13 +59,13 @@ - python-feedgen + 2 Combined summary - New PSBT version proposal - 2023-08-02T02:54:05.328979+00:00 + 2025-09-26T15:59:36.337574+00:00 - A proposal has been made to introduce a new version of Partially Signed Bitcoin Transactions (PSBTs) called PSBT v1. This new version addresses deficiencies in the current PSBT v0 and allows for inputs and outputs to be added to the transaction after its creation. The primary change is that all input and output data will be contained in their respective maps, eliminating the need to parse an unsigned transaction. Several new fields will be added to support this change, including PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, and PSBT_GLOBAL_UNDER_CONSTRUCTION.Andrew Chow has also proposed another version called PSBTv2, which is a backward-incompatible update to the PSBT protocol. It introduces fields like Transaction Version, Fallback Locktime, Input Count, Output Count, and Transaction Modifiable Flags. Additionally, the process of determining the nLockTime field of a transaction is explained in detail.Rusty Russell and Andrew Chow discuss the addition of a new global field called PSBT_GLOBAL_UNDER_CONSTRUCTION in an email exchange. This field is used to signal whether inputs and outputs can be added to the PSBT. Rusty suggests flagging this by omitting redundant fields, but Andrew explains that those fields are necessary to determine the number of input and output maps. They also discuss the possibility of signed inputs being added to transactions and the complexity of allowing modification of inputs and outputs after the Creator role is done.Overall, these proposed changes aim to improve the usability and functionality of the PSBT format, allowing for easier construction of transactions and the addition of inputs and outputs as needed.Andrew Chow has proposed a new version of Partially Signed Bitcoin Transactions (PSBT), called PSBT v1, to address the deficiencies in the current PSBT v0. The primary change in the new version is to have all input and output data for each contained within their respective maps, disallowing PSBT_GLOBAL_UNSIGNED_TX. Several new fields are added for Global, Input, and Output, including PSBT_GLOBAL_TX_VERSION, PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, PSBT_GLOBAL_OUTPUT_COUNT, PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE, PSBT_IN_REQUIRED_LOCKTIME, PSBT_OUT_VALUE, and PSBT_OUT_OUTPUT_SCRIPT.These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, care must be taken to ensure that adding additional inputs and outputs will not invalidate existing signatures. Finalizers must choose the maximum of all the *_LOCKTIME fields to choose the locktime for the transaction.PSBT v1 also introduces two lock time fields - one for a time-based lock time and the other for a height-based lock time. This is necessary because all inputs must use the same type of lock time (height or time). Additionally, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, is added to signal whether inputs and outputs can be added to the PSBT. Rules must be followed to ensure that adding new inputs and outputs does not invalidate existing signatures.To uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. Combiners can create an unsigned transaction given the transaction version, input prevouts, outputs, and computed locktime, which can then be used as a way to identify PSBTs.As the changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1 needs a version number bump to enforce backward incompatibility. However, once the inputs and outputs are decided, a PSBT can be downgraded back to v0 by creating an unsigned transaction from the fields mentioned above and dropping these new fields.Andrew Chow has proposed these changes in BIP 174 and is willing to write a pull request to modify it if the changes are deemed reasonable.A new version of Partially Signed Bitcoin Transaction (PSBT) has been proposed to address the deficiencies in the current PSBT v0. The main change in this proposal is to store all input and output data for each in their respective maps, eliminating the need to parse an unsigned transaction and perform a lookup for data. This change would disallow the use of the PSBT_GLOBAL_UNSIGNED_TX field in the new version.To implement these changes, several fields are suggested to be added to both the Global and Input/Output sections of PSBT. One notable addition is the PSBT_GLOBAL_PREFERRED_LOCKTIME, which specifies the locktime to use if no inputs require a specific locktime. Another important field is the PSBT_IN_REQUIRED_LOCKTIME, which is necessary for inputs involving OP_CHECKLOCKTIMEVERIFY. This field allows finalizers to choose a locktime that meets the minimum requirement without needing to understand the scripts involved.It is worth mentioning that a Bitcoin transaction only has a single locktime, while a PSBT may have multiple locktimes. Therefore, finalizers must select 2021-04-05T00:35:14+00:00 + A proposal has been made to introduce a new version of Partially Signed Bitcoin Transactions (PSBTs) called PSBT v1. This new version addresses deficiencies in the current PSBT v0 and allows for inputs and outputs to be added to the transaction after its creation. The primary change is that all input and output data will be contained in their respective maps, eliminating the need to parse an unsigned transaction. Several new fields will be added to support this change, including PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, and PSBT_GLOBAL_UNDER_CONSTRUCTION.Andrew Chow has also proposed another version called PSBTv2, which is a backward-incompatible update to the PSBT protocol. It introduces fields like Transaction Version, Fallback Locktime, Input Count, Output Count, and Transaction Modifiable Flags. Additionally, the process of determining the nLockTime field of a transaction is explained in detail.Rusty Russell and Andrew Chow discuss the addition of a new global field called PSBT_GLOBAL_UNDER_CONSTRUCTION in an email exchange. This field is used to signal whether inputs and outputs can be added to the PSBT. Rusty suggests flagging this by omitting redundant fields, but Andrew explains that those fields are necessary to determine the number of input and output maps. They also discuss the possibility of signed inputs being added to transactions and the complexity of allowing modification of inputs and outputs after the Creator role is done.Overall, these proposed changes aim to improve the usability and functionality of the PSBT format, allowing for easier construction of transactions and the addition of inputs and outputs as needed.Andrew Chow has proposed a new version of Partially Signed Bitcoin Transactions (PSBT), called PSBT v1, to address the deficiencies in the current PSBT v0. The primary change in the new version is to have all input and output data for each contained within their respective maps, disallowing PSBT_GLOBAL_UNSIGNED_TX. Several new fields are added for Global, Input, and Output, including PSBT_GLOBAL_TX_VERSION, PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, PSBT_GLOBAL_OUTPUT_COUNT, PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE, PSBT_IN_REQUIRED_LOCKTIME, PSBT_OUT_VALUE, and PSBT_OUT_OUTPUT_SCRIPT.These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, care must be taken to ensure that adding additional inputs and outputs will not invalidate existing signatures. Finalizers must choose the maximum of all the *_LOCKTIME fields to choose the locktime for the transaction.PSBT v1 also introduces two lock time fields - one for a time-based lock time and the other for a height-based lock time. This is necessary because all inputs must use the same type of lock time (height or time). Additionally, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, is added to signal whether inputs and outputs can be added to the PSBT. Rules must be followed to ensure that adding new inputs and outputs does not invalidate existing signatures.To uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. Combiners can create an unsigned transaction given the transaction version, input prevouts, outputs, and computed locktime, which can then be used as a way to identify PSBTs.As the changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1 needs a version number bump to enforce backward incompatibility. However, once the inputs and outputs are decided, a PSBT can be downgraded back to v0 by creating an unsigned transaction from the fields mentioned above and dropping these new fields.Andrew Chow has proposed these changes in BIP 174 and is willing to write a pull request to modify it if the changes are deemed reasonable.A new version of Partially Signed Bitcoin Transaction (PSBT) has been proposed to address the deficiencies in the current PSBT v0. The main change in this proposal is to store all input and output data for each in their respective maps, eliminating the need to parse an unsigned transaction and perform a lookup for data. This change would disallow the use of the PSBT_GLOBAL_UNSIGNED_TX field in the new version.To implement these changes, several fields are suggested to be added to both the Global and Input/Output sections of PSBT. One notable addition is the PSBT_GLOBAL_PREFERRED_LOCKTIME, which specifies the locktime to use if no inputs require a specific locktime. Another important field is the PSBT_IN_REQUIRED_LOCKTIME, which is necessary for inputs involving OP_CHECKLOCKTIMEVERIFY. This field allows finalizers to choose a locktime that meets the minimum requirement without needing to understand the scripts involved.It is worth mentioning that a Bitcoin transaction only has a single locktime, while a PSBT may have multiple locktimes. Therefore, finalizers must select - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2021/combined_PayJoin-adoption.xml b/static/bitcoin-dev/Jan_2021/combined_PayJoin-adoption.xml index 7995471733..b6709ceacf 100644 --- a/static/bitcoin-dev/Jan_2021/combined_PayJoin-adoption.xml +++ b/static/bitcoin-dev/Jan_2021/combined_PayJoin-adoption.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - PayJoin adoption - 2023-08-02T03:02:31.999204+00:00 - - Chris Belcher 2021-01-19 15:44:11+00:00 - - - Lucas Ontivero 2021-01-18 20:38:51+00:00 - - - Craig Raw 2021-01-16 06:15:27+00:00 - - - dev_f 2021-01-16 02:52:34+00:00 - - - Chris Belcher 2021-01-16 00:07:08+00:00 - + 2025-09-26T15:59:38.454724+00:00 + python-feedgen + + + [bitcoin-dev] PayJoin adoption Chris Belcher + 2021-01-16T00:07:00.000Z + + + dev_f + 2021-01-16T02:52:00.000Z + + + Craig Raw + 2021-01-16T06:15:00.000Z + + + Lucas Ontivero + 2021-01-18T20:38:00.000Z + + + Chris Belcher + 2021-01-19T15:44:00.000Z + + - python-feedgen + 2 Combined summary - PayJoin adoption - 2023-08-02T03:02:31.999204+00:00 + 2025-09-26T15:59:38.455519+00:00 - PayJoin, a privacy technology for Bitcoin, has the potential to disrupt blockchain surveillance and preserve Bitcoin's fungibility. Several projects, including BTCPayServer, Wasabi Wallet, JoinMarket, and BlueWallet, have already implemented the PayJoin protocol standard. The adoption of PayJoin is being monitored on a dedicated wiki page, similar to the Bech32 adoption page.While PayJoin offers significant privacy benefits for the global transactions graph, its adoption faces challenges. The economic incentives for using PayJoin are not as significant compared to the privacy advantages. P2P exchanges are expected to be early adopters of this technology. However, the user experience of PayJoin is currently not optimal, primarily due to users' unfamiliarity with bip21 uris.To encourage wider adoption, it is suggested that wallets' developers make PayJoin payments the default option, without any additional cost or effort required from users. This would require wallets to communicate and interact seamlessly, allowing users to select contacts from their address book and make payments without realizing they are using PayJoin. This approach aims to combat surveillance efforts targeting Bitcoin users and enhance Bitcoin's fungibility.The recent shutdown of a UK Bitcoin exchange due to new regulations highlights the urgency of increasing PayJoin adoption. The exchange owner emphasized that using marketplaces instead of exchanges and engaging in Coinjoin activities are viewed as high-risk behaviors. As risk scores increase, users may encounter difficulties depositing funds, supplying documents, or even losing their coins without understanding the reasons.To prevent Bitcoin from becoming a permissioned money system akin to traditional bank accounts, greater efforts must be made to promote PayJoin adoption. Craig, a participant in the bitcoin-dev mailing list, proposed eliminating the need for a server endpoint on the receiving side to facilitate easier PayJoin transactions between wallets. This approach would require a different mechanism to exchange payment information but would not require any specification amendments.Increasing the visibility of PayJoin and integrating it into popular software like BTCPayServer could greatly contribute to its adoption. By making PayJoin the default option, users would be able to enjoy the privacy benefits without any extra steps or inconveniences. Ultimately, widespread adoption of PayJoin is essential to fulfill Bitcoin's vision of being permissionless money for the internet. 2021-01-19T15:44:11+00:00 + PayJoin, a privacy technology for Bitcoin, has the potential to disrupt blockchain surveillance and preserve Bitcoin's fungibility. Several projects, including BTCPayServer, Wasabi Wallet, JoinMarket, and BlueWallet, have already implemented the PayJoin protocol standard. The adoption of PayJoin is being monitored on a dedicated wiki page, similar to the Bech32 adoption page.While PayJoin offers significant privacy benefits for the global transactions graph, its adoption faces challenges. The economic incentives for using PayJoin are not as significant compared to the privacy advantages. P2P exchanges are expected to be early adopters of this technology. However, the user experience of PayJoin is currently not optimal, primarily due to users' unfamiliarity with bip21 uris.To encourage wider adoption, it is suggested that wallets' developers make PayJoin payments the default option, without any additional cost or effort required from users. This would require wallets to communicate and interact seamlessly, allowing users to select contacts from their address book and make payments without realizing they are using PayJoin. This approach aims to combat surveillance efforts targeting Bitcoin users and enhance Bitcoin's fungibility.The recent shutdown of a UK Bitcoin exchange due to new regulations highlights the urgency of increasing PayJoin adoption. The exchange owner emphasized that using marketplaces instead of exchanges and engaging in Coinjoin activities are viewed as high-risk behaviors. As risk scores increase, users may encounter difficulties depositing funds, supplying documents, or even losing their coins without understanding the reasons.To prevent Bitcoin from becoming a permissioned money system akin to traditional bank accounts, greater efforts must be made to promote PayJoin adoption. Craig, a participant in the bitcoin-dev mailing list, proposed eliminating the need for a server endpoint on the receiving side to facilitate easier PayJoin transactions between wallets. This approach would require a different mechanism to exchange payment information but would not require any specification amendments.Increasing the visibility of PayJoin and integrating it into popular software like BTCPayServer could greatly contribute to its adoption. By making PayJoin the default option, users would be able to enjoy the privacy benefits without any extra steps or inconveniences. Ultimately, widespread adoption of PayJoin is essential to fulfill Bitcoin's vision of being permissionless money for the internet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2021/combined_Proposal-for-new-disabletx-p2p-message.xml b/static/bitcoin-dev/Jan_2021/combined_Proposal-for-new-disabletx-p2p-message.xml index b5a15cd3fc..04188e5b0e 100644 --- a/static/bitcoin-dev/Jan_2021/combined_Proposal-for-new-disabletx-p2p-message.xml +++ b/static/bitcoin-dev/Jan_2021/combined_Proposal-for-new-disabletx-p2p-message.xml @@ -1,41 +1,55 @@ - + 2 - Combined summary - Proposal for new "disabletx" p2p message - 2023-08-02T03:00:35.927900+00:00 - - Antoine Riard 2021-03-02 22:42:14+00:00 - - - Anthony Towns 2021-03-02 16:31:27+00:00 - - - John Newbery 2021-03-02 12:11:23+00:00 - - - Antoine Riard 2021-03-01 23:11:51+00:00 - - - John Newbery 2021-03-01 20:58:46+00:00 - - - Suhas Daftuar 2021-01-19 19:19:12+00:00 - - - Anthony Towns 2021-01-14 06:46:00+00:00 - - - Matt Corallo 2021-01-14 05:39:16+00:00 - - - Anthony Towns 2021-01-14 05:32:57+00:00 - - - Matt Corallo 2021-01-13 06:40:03+00:00 - - - Suhas Daftuar 2021-01-06 16:35:11+00:00 - + Combined summary - Proposal for new "disabletx" p2p message + 2025-09-26T15:59:40.611489+00:00 + python-feedgen + + + [bitcoin-dev] Proposal for new "disabletx" p2p message Suhas Daftuar + 2021-01-06T16:35:00.000Z + + + Matt Corallo + 2021-01-13T06:40:00.000Z + + + Anthony Towns + 2021-01-14T05:32:00.000Z + + + Matt Corallo + 2021-01-14T05:39:00.000Z + + + Anthony Towns + 2021-01-14T06:46:00.000Z + + + Suhas Daftuar + 2021-01-19T19:19:00.000Z + + + John Newbery + 2021-03-01T20:58:00.000Z + + + Antoine Riard + 2021-03-01T23:11:00.000Z + + + John Newbery + 2021-03-02T12:11:00.000Z + + + Anthony Towns + 2021-03-02T16:31:00.000Z + + + Antoine Riard + 2021-03-02T22:42:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 - Combined summary - Proposal for new "disabletx" p2p message - 2023-08-02T03:00:35.927900+00:00 + Combined summary - Proposal for new "disabletx" p2p message + 2025-09-26T15:59:40.612783+00:00 - In a Bitcoin development mailing list, there is a proposal to increase the number of block-relay-only connections and improve addr record propagation without making changes to the p2p protocol. The proposal suggests using the fRelay field in the version message to indicate no transaction relay. However, there are concerns about this approach, and it is recommended to have a well-defined standard with a clean negotiation mechanism.To prevent addr black holes, it is suggested that Bitcoin Core should only relay addr records to an inbound peer if it has previously received an addr or addrv2 message from that peer. This approach will improve addr propagation immediately and prevent sending addr records to all addr black holes.A new p2p message called "disabletx" is proposed to allow peers to communicate that they do not want to send or receive loose transactions for the lifetime of a connection. This message aims to create low-resource connections that protect against partition attacks on the network. Nodes implementing this BIP must set the protocol version to 70017 or higher.The proposed changes aim to increase the number of inbound block-relay-only peers while minimizing resource requirements and improving addr record propagation. This would be achieved by initializing transaction relay data structures after the version message is received and only if certain conditions are met. Additionally, a new p2p message, "disabletx," would be added to facilitate connections over which only block-related data are relayed.However, there are disagreements regarding the use of fRelay and the need for a clear negotiation mechanism. Some argue that reusing fRelay for a different purpose is not ideal and suggest having a well-defined standard instead. They also propose explicitly negotiating addr relay for more flexibility.Overall, the proposed changes aim to enhance the efficiency and security of peer connections in the Bitcoin network, specifically focusing on block propagation and addr record propagation. These changes would help protect against network attacks and improve the overall performance of the network. Bitcoin Core has already implemented some of these functionalities in previous versions, demonstrating the feasibility and potential benefits of these proposals.In a recent email thread, Bitcoin developer Suhas Daftuar has proposed the addition of a new optional peer-to-peer (p2p) message called "disabletx" to the Bitcoin protocol. This message would allow peers to communicate that they do not want to send or receive loose transactions during their connection. The purpose of this message is to facilitate low-resource connections on the network, where only block-related data are relayed, in order to strengthen network security against partition attacks.Currently, software has been deployed that initiates connections on the Bitcoin network and sets the transaction relay field to false, preventing transaction relay from occurring on the connection. These connections serve two purposes: enhancing the robustness of a node to network partitioning attacks and reducing an adversary's ability to learn the complete network graph. However, there is a need for a more standardized approach to indicate that loose transactions will not be sent or received for the entire lifetime of a connection.The proposal suggests adding the "disabletx" message as a new p2p message to address this need. It also recommends using the existing "fRelay" field in the version message to indicate that no transaction relay can happen for the entire lifetime of the connection. By postponing resource allocation for transaction relay data structures until after the version message has been received, the proposal aims to minimize resource usage for incoming block-relay-only connections.Additionally, the proposal suggests updating the inbound eviction logic to protect more inbound peers that do not have transaction relay data structures. It recommends initializing address data structures for inbound connections only when specific messages related to addresses are received on the connection. Furthermore, it proposes modestly increasing the number of outbound block-relay-only connections.The Bitcoin Improvement Proposal (BIP) 324 also suggests disabling address relay between peers to prevent network analysis attacks. While the proposal does not require software to relay addresses, it allows for future protocol extensions that might specify how address relay should be negotiated.The proposed changes aim to strengthen network security against partition attacks and network analysis attacks while minimizing resource usage for incoming block-relay-only connections. The full details of the proposals, including compatibility information, can be found in the respective BIPs. 2021-03-02T22:42:14+00:00 + In a Bitcoin development mailing list, there is a proposal to increase the number of block-relay-only connections and improve addr record propagation without making changes to the p2p protocol. The proposal suggests using the fRelay field in the version message to indicate no transaction relay. However, there are concerns about this approach, and it is recommended to have a well-defined standard with a clean negotiation mechanism.To prevent addr black holes, it is suggested that Bitcoin Core should only relay addr records to an inbound peer if it has previously received an addr or addrv2 message from that peer. This approach will improve addr propagation immediately and prevent sending addr records to all addr black holes.A new p2p message called "disabletx" is proposed to allow peers to communicate that they do not want to send or receive loose transactions for the lifetime of a connection. This message aims to create low-resource connections that protect against partition attacks on the network. Nodes implementing this BIP must set the protocol version to 70017 or higher.The proposed changes aim to increase the number of inbound block-relay-only peers while minimizing resource requirements and improving addr record propagation. This would be achieved by initializing transaction relay data structures after the version message is received and only if certain conditions are met. Additionally, a new p2p message, "disabletx," would be added to facilitate connections over which only block-related data are relayed.However, there are disagreements regarding the use of fRelay and the need for a clear negotiation mechanism. Some argue that reusing fRelay for a different purpose is not ideal and suggest having a well-defined standard instead. They also propose explicitly negotiating addr relay for more flexibility.Overall, the proposed changes aim to enhance the efficiency and security of peer connections in the Bitcoin network, specifically focusing on block propagation and addr record propagation. These changes would help protect against network attacks and improve the overall performance of the network. Bitcoin Core has already implemented some of these functionalities in previous versions, demonstrating the feasibility and potential benefits of these proposals.In a recent email thread, Bitcoin developer Suhas Daftuar has proposed the addition of a new optional peer-to-peer (p2p) message called "disabletx" to the Bitcoin protocol. This message would allow peers to communicate that they do not want to send or receive loose transactions during their connection. The purpose of this message is to facilitate low-resource connections on the network, where only block-related data are relayed, in order to strengthen network security against partition attacks.Currently, software has been deployed that initiates connections on the Bitcoin network and sets the transaction relay field to false, preventing transaction relay from occurring on the connection. These connections serve two purposes: enhancing the robustness of a node to network partitioning attacks and reducing an adversary's ability to learn the complete network graph. However, there is a need for a more standardized approach to indicate that loose transactions will not be sent or received for the entire lifetime of a connection.The proposal suggests adding the "disabletx" message as a new p2p message to address this need. It also recommends using the existing "fRelay" field in the version message to indicate that no transaction relay can happen for the entire lifetime of the connection. By postponing resource allocation for transaction relay data structures until after the version message has been received, the proposal aims to minimize resource usage for incoming block-relay-only connections.Additionally, the proposal suggests updating the inbound eviction logic to protect more inbound peers that do not have transaction relay data structures. It recommends initializing address data structures for inbound connections only when specific messages related to addresses are received on the connection. Furthermore, it proposes modestly increasing the number of outbound block-relay-only connections.The Bitcoin Improvement Proposal (BIP) 324 also suggests disabling address relay between peers to prevent network analysis attacks. While the proposal does not require software to relay addresses, it allows for future protocol extensions that might specify how address relay should be negotiated.The proposed changes aim to strengthen network security against partition attacks and network analysis attacks while minimizing resource usage for incoming block-relay-only connections. The full details of the proposals, including compatibility information, can be found in the respective BIPs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2021/combined_Softchains-Sidechains-as-a-Soft-Fork-via-Proof-of-Work-Fraud-Proofs.xml b/static/bitcoin-dev/Jan_2021/combined_Softchains-Sidechains-as-a-Soft-Fork-via-Proof-of-Work-Fraud-Proofs.xml index eb71bb3e07..5aa1a2212b 100644 --- a/static/bitcoin-dev/Jan_2021/combined_Softchains-Sidechains-as-a-Soft-Fork-via-Proof-of-Work-Fraud-Proofs.xml +++ b/static/bitcoin-dev/Jan_2021/combined_Softchains-Sidechains-as-a-Soft-Fork-via-Proof-of-Work-Fraud-Proofs.xml @@ -1,35 +1,27 @@ - + 2 Combined summary - Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs - 2023-08-02T02:59:13.920871+00:00 - - Ruben Somsen 2021-01-01 00:05:59+00:00 - - - Ruben Somsen 2020-12-31 23:39:10+00:00 - - - Sergio Demian Lerner 2020-12-31 23:37:58+00:00 - - - ZmnSCPxj 2020-12-31 23:26:24+00:00 - - - Ruben Somsen 2020-12-31 22:00:17+00:00 - + 2025-09-26T15:59:32.065803+00:00 + python-feedgen + + + Ruben Somsen + 2021-01-01T00:05:00.000Z + + - python-feedgen + 2 Combined summary - Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs - 2023-08-02T02:59:13.920871+00:00 + 2025-09-26T15:59:32.066204+00:00 - Ruben Somsen has proposed a fully decentralized two-way peg sidechain design called Softchains. This design requires a soft fork to activate new sidechains and utilizes Proof-of-Work Fraud Proofs (PoW FP) as the consensus mechanism for validating disputed blocks. All Softchains are validated by everyone through PoW FP consensus. If a user wants to directly use a specific Softchain, they need to run it as a full node to achieve fast consensus.Peg-ins occur by freezing coins on the mainchain and assigning them to a Softchain, while peg-outs involve creating a mainchain transaction that points to a peg-out transaction on a Softchain and waiting for enough mainchain confirmations. However, Softchain consensus still requires validation from mainchain users, and consensus bugs can have negative consequences. These bugs could potentially cause a chain split in mainchain consensus or invalidate a peg-out right after it becomes accepted on the mainchain, thus splitting consensus.There are potential risks associated with Softchains, such as non-deterministic consensus bugs and major reorgs. To mitigate these risks, Ruben suggests basing Softchain designs on Bitcoin Core and implementing a rule disallowing reorgs larger than half the peg-out time. It is important for each Softchain to produce a significant amount of PoW to ensure security and prevent cost reductions in creating forks. Merged mining could aid in maintaining security, but it would place an additional burden on miners for validation.In conclusion, the Softchains proposal offers the potential for more opt-in block space and the ability to introduce chains with different consensus rules. However, there are significant risks involved, and Ruben welcomes feedback and ideas on how to address these issues and ensure maximum safety. 2021-01-01T00:05:59+00:00 + Ruben Somsen has proposed a fully decentralized two-way peg sidechain design called Softchains. This design requires a soft fork to activate new sidechains and utilizes Proof-of-Work Fraud Proofs (PoW FP) as the consensus mechanism for validating disputed blocks. All Softchains are validated by everyone through PoW FP consensus. If a user wants to directly use a specific Softchain, they need to run it as a full node to achieve fast consensus.Peg-ins occur by freezing coins on the mainchain and assigning them to a Softchain, while peg-outs involve creating a mainchain transaction that points to a peg-out transaction on a Softchain and waiting for enough mainchain confirmations. However, Softchain consensus still requires validation from mainchain users, and consensus bugs can have negative consequences. These bugs could potentially cause a chain split in mainchain consensus or invalidate a peg-out right after it becomes accepted on the mainchain, thus splitting consensus.There are potential risks associated with Softchains, such as non-deterministic consensus bugs and major reorgs. To mitigate these risks, Ruben suggests basing Softchain designs on Bitcoin Core and implementing a rule disallowing reorgs larger than half the peg-out time. It is important for each Softchain to produce a significant amount of PoW to ensure security and prevent cost reductions in creating forks. Merged mining could aid in maintaining security, but it would place an additional burden on miners for validation.In conclusion, the Softchains proposal offers the potential for more opt-in block space and the ability to introduce chains with different consensus rules. However, there are significant risks involved, and Ruben welcomes feedback and ideas on how to address these issues and ensure maximum safety. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml b/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml index 658199a95c..17e8565650 100644 --- a/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml +++ b/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml @@ -2,7 +2,7 @@ 2 Combined summary - [dlc-dev] CTV dramatically improves DLCs - 2025-09-26T14:40:00.997082+00:00 + 2025-09-26T16:02:53.432662+00:00 python-feedgen Jeremy 2022-01-28 16:53:40+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - [dlc-dev] CTV dramatically improves DLCs - 2025-09-26T14:40:00.997278+00:00 + 2025-09-26T16:02:53.432791+00:00 2022-01-28T16:53:40+00:00 In an email thread on the Bitcoin-dev mailing list, Thibaut Le Guilly responds to Lloyd Fournier regarding the use of CTV in the Discreet Log Contract (DLC) protocol. Thibaut agrees that CTV could simplify the protocol but raises the possibility of using the CHECKSIGFROMSTACK opcode instead. He suggests that this opcode would allow for requiring an oracle signature over the outcome without any special tricks or the need for the oracle to release a nonce in advance. However, he admits that he hasn't thoroughly studied covenant opcodes yet.Jeremy, another participant in the discussion, replies to Thibaut's message. He acknowledges that CSFS might have independent benefits in general but points out that in this specific case, CTV is only being used in the user-generated mapping of Oracle result to Transaction Outcome. Jeremy adds that if Thibaut comes up with something CSFS-based for the Oracles, it would be complimentary to the current usage of CTV.Jonas Nick chimes in by thanking Thibaut for proposing the interesting application of OP_CTV. However, Jonas mentions that this particular use case doesn't necessarily require OP_CTV and can also be achieved through other covenant constructions such as ANYPREVOUT-based covenants. These alternative constructions offer similar benefits. Specifically, the script of the Taproot leaves can be set to CHECKSIGVERIFY CHECKSIGVERIFY, where the creation of signatures has minimal computational cost. The downside of this approach is the additional overhead of 64 witness bytes compared to CTV.Overall, the email thread discusses the potential use of OP_CTV and alternative covenant constructions for DLCs. It explores the advantages and considerations of each approach, highlighting the potential benefits and trade-offs associated with different opcode choices. diff --git a/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml b/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml index b594256efc..6f979c4051 100644 --- a/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml +++ b/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml @@ -2,7 +2,7 @@ 2 Combined summary - CTV BIP review - 2025-09-26T14:40:13.877590+00:00 + 2025-09-26T16:02:55.549094+00:00 python-feedgen Billy Tetrud 2022-01-21 17:36:13+00:00 @@ -53,10 +53,11 @@ + 2 Combined summary - CTV BIP review - 2025-09-26T14:40:13.877760+00:00 + 2025-09-26T16:02:55.549266+00:00 2022-01-21T17:36:13+00:00 In a recent discussion about the activation method for Bitcoin Improvement Proposal (BIP) 8 and BIP 9/ST, there was disagreement over how these proposals should be characterized. The main point of contention was whether activation required majority hash power support or not. BIP9/ST requires this support, while BIP8 does not. Billy Tetrud pointed out factual errors in LukeJr's statements about BIP8 and agreed with Michael that the discussion should be kept separate from the BIPs themselves. Tetrud suggested that BIPs should only mention what types of activation methods are possible, without advocating for any specific method.Billy Tetrud thanked Eric Lombrozo for correcting the factual errors regarding BIP8 and ST activation methods in an email exchange. While characterizing BIP8 and ST as BIP9-based or not is subjective, the central issue remains whether activation requires majority hash power support or not. The conversation on activation methods should be separate from advocating for specific methods in BIPs to reduce noise in conversations.The Bitcoin-dev mailing list had a discussion about the legal definition of covenant, which led to Jeremy expressing annoyance. In response, aj proposed a more useful definition of covenant within the context of Bitcoin. According to aj, a covenant is when the scriptPubKey of an unspent transaction output (utxo) restricts the scriptPubKey in the outputs of a transaction that spends that utxo. aj clarified that CTV and TLUV have this type of restriction, while CSV and CLTV do not. They also mentioned that "checksig" could potentially be considered a covenant if the signature used in checksig is in the scriptPubKey. The discussion also covered several topics related to BIPs and their implementation, including the burden placed on full BIP implementation, the use of Eltoo-like protocols, implementing OP_CAT or OP_SHA256STREAM in Bitcoin, language cleanups, and the review of CTV BIP.In an email thread regarding the review of CTV BIP, Michael Folkson requested Eric and Luke to refrain from discussing activation methods for future soft forks on a thread for CTV BIP review. He explained that the discussion for Taproot activation was kept separate until there was overwhelming community consensus. Eric and Luke disagreed with Michael's statements about backward compatibility of unenforced soft forks and chain splits. They argued that soft forks do not produce a chain split themselves but can disrupt if miners cause a split. However, Michael maintained that without majority hash power enforcement, soft forks are not backward compatible. There was also a disagreement between Eric and Luke about the definition of backward compatibility and the use of BIP8 for Taproot activation.In another discussion on the Bitcoin-dev mailing list, Jeremy Rubin expressed skepticism about using BIPs for specific use cases for CTV. Alex suggested having explicit application notes to provide details on how CTV can be used in specific applications while making it clear that they are not part of CTV itself. Luke Dashjr provided a detailed review of the CTV BIP, expressing concerns about its readiness and suggesting alternative approaches for certain use cases.Jeremy Rubin thanked Luke Dashjr for his review of CTV and mentioned plans for language cleanups. While he agreed with the need for BIPs for specific use cases, he was skeptical about the overall approach and suggested reviewing application-focused posts and creating a BIP describing how to build something similar to Sapio to help users think through compiling to CTV contracts. Luke Dashjr disagreed with Rubin's viewpoint, stating that CTV is not yet ready and that BIP 9 has known flaws. He questioned why congestion-controlled transactions had not been considered and suggested using Speedy Trial instead of BIP 9 for future deployments. He also discussed limitations of CHECKTEMPLATEVERIFY and proposed alternatives.Luke Dashjr and Eric Voskuil had a discussion about the compatibility of soft forks with the Bitcoin consensus protocol. Dashjr argued that soft forks are not backward compatible without hash power enforcement, while Voskuil disagreed, stating that enforcement is by users, not miners. There was a disagreement about BIP8 achieving consensus for Taproot activation, with Michael Folkson calling it a misleading statement and accusing Eric of deception.The email thread discussed the review of CTV, focusing on technical aspects. The author emphasized that personal or legal attacks on developers would not sway their opinion. They agreed with some nitpicks mentioned in the email and expressed a desire to see fully implemented BIPs before activation. They strongly opposed using BIP9, believing it to be flawed and representing an attempt to impose developer will over community consensus. The author suggested directing other technical comments to Jeremy or someone else as their research was ongoing. The email ended with the author's contact information.Eric at voskuil.org stated that the only significant difference between BIP9 and BIP8 is whether activation requires majority hash power support or not. Soft forks are diff --git a/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml b/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml index 01ae2ec796..413e8a2ca4 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml @@ -2,7 +2,7 @@ 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2025-09-26T14:40:18.133622+00:00 + 2025-09-26T16:02:57.671138+00:00 python-feedgen Billy Tetrud 2022-02-22 12:57:15+00:00 @@ -85,10 +85,11 @@ + 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2025-09-26T14:40:18.133807+00:00 + 2025-09-26T16:02:57.671335+00:00 2022-02-22T12:57:15+00:00 In a recent discussion about Bitcoin scaling, there was disagreement over whether it should be done rapidly or not. Some argue that scaling should not be delayed to keep fees high, suggesting that if higher fees are needed, the block size can be lowered or the default minimum relay fee rate increased. They also question the belief that the Lightning Network is the main cause of low fees and argue that delaying scaling would harm Bitcoin's growth.On the other hand, others argue that new use cases for on-chain transactions may compete with existing users for limited blockchain space. This situation has been compared to the saying "nobody goes there anymore, it's too crowded." The discussion also touched upon the issue of invoking Satoshi's opinions in present-day discussions. One participant objected to assumptions about the founder of Bitcoin, arguing that Satoshi is more than just a pseudonym and will live on forever. However, another participant objected to the invocation of Satoshi in general, suggesting that if he wants to participate in Bitcoin development today, he can speak for himself. They added that if Satoshi refuses to participate, his opinion is irrelevant. In an email exchange posted on a Bitcoin forum, Prayank objects to ZmnSCPxj's invocation of Satoshi, stating that he cares about Satoshi's opinions, especially regarding subsidies. ZmnSCPxj counters by arguing that if Satoshi refuses to participate in Bitcoin development today, it doesn't matter what his opinion is. He asserts that Satoshi is dead and Bitcoin lives on without him. Prayank objects to this assumption, insisting that Satoshi is more than just a pseudonym and will live on forever. Both parties acknowledge that they are considering the various arguments being presented.In another post, ZmnSCPxj mentions that improvements like the Taproot upgrade can reduce activity on the blockchain and increase functionality without requiring an increase in block size. The Taproot upgrade offers features such as Schnorr multisignatures, MAST, `SIGHASH_ANYPREVOUT`, and `OP_CTV`, which reduce block size usage for complex contracts, enable offchain updateable multiparty cryptocurrency systems, and allow transactional cut-through without immediate output publication. ZmnSCPxj believes that these upgrades enhance Bitcoin's functionality and provide opportunities to use the blockchain in a different way.There is also a discussion about the expansion of use-cases in Ethereum potentially harming Bitcoin by fueling future contentious blocksize debates due to high on-chain fees. However, the counterargument is that fees will be the incentives for miners as subsidy decreases, and it will depend on the demand for block space. Additionally, if this is the reason to stop or delay improvements in Bitcoin, it may apply to Taproot as well. A proposal for a lightning-compatible mimblewimble+dandelion on-chain soft fork is mentioned as a way to reduce transaction size, improve privacy, and move more small transactions off-chain. However, it is suggested that this should not be released for another two years as timing is crucial for Bitcoin innovation.Furthermore, there is a discussion about the lack of compelling use-cases beneficial to all users, with some shared use cases being considered too narrow. The Drivechains use-case is deemed harmful to the security of Bitcoin as a whole. It is argued that the new uses for on-chain transactions mentioned as a use-case could harm existing users by competing for limited blockchain space. As a result, it is concluded that any core consensus changes to the Bitcoin system must be carefully evaluated against the risks.In the Bitcoin developer community, there is a debate about the readiness and potential risks of implementing the proposed consensus change known as OP_CTV. Some developers argue for its activation in a few months, while others express skepticism and call for more testing and research. Other soft fork proposals, such as BIP 118 focusing on eltoo payment channels, are also discussed. Concerns are raised about rushing through consensus changes without thorough examination and community support. Skeptics emphasize the need for technical discussions and engagement to address potential issues. Despite differing opinions, there is a general agreement that implementing a soft fork within the next few months is feasible with proper precautions. The discussion highlights the importance of responsible decision-making and avoiding contentious activation attempts. IRC workshops on BIP 119 are mentioned as a resource for engaging with skeptics on technical concerns. diff --git a/static/bitcoin-dev/July_2016/combined_BIP-151-use-of-HMAC-SHA512.xml b/static/bitcoin-dev/July_2016/combined_BIP-151-use-of-HMAC-SHA512.xml index 98001c3727..52811cc2d0 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-151-use-of-HMAC-SHA512.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-151-use-of-HMAC-SHA512.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 151 use of HMAC_SHA512 - 2023-08-01T18:30:51.865845+00:00 + 2025-09-26T15:29:19.342056+00:00 + python-feedgen Jonas Schnelli 2016-07-04 06:47:05+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - BIP 151 use of HMAC_SHA512 - 2023-08-01T18:30:51.865845+00:00 + 2025-09-26T15:29:19.342244+00:00 - Zooko Wilcox, in a discussion on the bitcoin-dev mailing list, suggests using the well-studied open standard of HKDF (HMAC-based Extract-and-Expand Key Derivation Function) instead of re-inventing it. He emphasizes the importance of using open standards in cryptography to reduce the risk of errors. Arthur Chen agrees with this recommendation and highlights the significance of following well-studied open standards in the realm of cryptocurrency.The discussion also touches upon the use of HMAC vs SHA256 for a Message Authentication Code (MAC). It is explained that SHA256 is insecure for a MAC due to its length extension property. Even though SHA256 appends the bitlength, making it more difficult to generate a new value, it is not being used as a MAC in BIP151. Arthur Chen explains the proven security properties of HMAC, even when the underlying crypto hashing function has weaknesses. He emphasizes the importance of using HMAC for MACs rather than custom constructions.There is a debate about using SHA512_HMAC instead of SHA256_HMAC for key derivation. Jonas Schnelli suggests using SHA512_HMAC, citing its usage in BIP32 and its cost-effectiveness compared to two SHA256_HMAC operations. However, Rusty Russell argues that introducing another hash algorithm would be unnecessarily painful and questions the use of HMAC over just SHA256. The discussion concludes without clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In another discussion, the importance of including the cipher-type in the symmetric cipher key is emphasized to avoid weak-cipher attacks. It is noted that although BIP151 currently specifies chacha20-poly1305 at openssh.com, it is possible for someone to add another symmetric cipher type after deployment which may have weaker security properties. Therefore, the inclusion of the ciphersuite-type in the key derivation HMAC is crucial to prevent potential attacks.Based on previous crypto analysis, it is stated that the security of SHA512 is not significantly higher than SHA256. There have been discussions about considering SHA3 as a potential alternative. However, there are no clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In summary, the context revolves around the importance of using well-studied open standards in cryptography. It emphasizes the use of HKDF instead of reinventing it and the utilization of HMAC for MACs to ensure security. There are debates regarding the use of SHA512_HMAC vs SHA256_HMAC for key derivation, with different perspectives provided. The inclusion of the cipher-type in the symmetric cipher key is highlighted to avoid weak-cipher attacks. Overall, the discussions aim to enhance the security and reliability of cryptographic systems in the realm of cryptocurrency. 2016-07-04T06:47:05+00:00 + Zooko Wilcox, in a discussion on the bitcoin-dev mailing list, suggests using the well-studied open standard of HKDF (HMAC-based Extract-and-Expand Key Derivation Function) instead of re-inventing it. He emphasizes the importance of using open standards in cryptography to reduce the risk of errors. Arthur Chen agrees with this recommendation and highlights the significance of following well-studied open standards in the realm of cryptocurrency.The discussion also touches upon the use of HMAC vs SHA256 for a Message Authentication Code (MAC). It is explained that SHA256 is insecure for a MAC due to its length extension property. Even though SHA256 appends the bitlength, making it more difficult to generate a new value, it is not being used as a MAC in BIP151. Arthur Chen explains the proven security properties of HMAC, even when the underlying crypto hashing function has weaknesses. He emphasizes the importance of using HMAC for MACs rather than custom constructions.There is a debate about using SHA512_HMAC instead of SHA256_HMAC for key derivation. Jonas Schnelli suggests using SHA512_HMAC, citing its usage in BIP32 and its cost-effectiveness compared to two SHA256_HMAC operations. However, Rusty Russell argues that introducing another hash algorithm would be unnecessarily painful and questions the use of HMAC over just SHA256. The discussion concludes without clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In another discussion, the importance of including the cipher-type in the symmetric cipher key is emphasized to avoid weak-cipher attacks. It is noted that although BIP151 currently specifies chacha20-poly1305 at openssh.com, it is possible for someone to add another symmetric cipher type after deployment which may have weaker security properties. Therefore, the inclusion of the ciphersuite-type in the key derivation HMAC is crucial to prevent potential attacks.Based on previous crypto analysis, it is stated that the security of SHA512 is not significantly higher than SHA256. There have been discussions about considering SHA3 as a potential alternative. However, there are no clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In summary, the context revolves around the importance of using well-studied open standards in cryptography. It emphasizes the use of HKDF instead of reinventing it and the utilization of HMAC for MACs to ensure security. There are debates regarding the use of SHA512_HMAC vs SHA256_HMAC for key derivation, with different perspectives provided. The inclusion of the cipher-type in the symmetric cipher key is highlighted to avoid weak-cipher attacks. Overall, the discussions aim to enhance the security and reliability of cryptographic systems in the realm of cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_BIP-151.xml b/static/bitcoin-dev/July_2016/combined_BIP-151.xml index 325b9b855d..62b711ad57 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-151.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-151.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 151 - 2023-08-01T18:42:21.264751+00:00 + 2025-09-26T15:29:17.227063+00:00 + python-feedgen Pieter Wuille 2016-08-31 14:29:53+00:00 @@ -167,13 +168,13 @@ - python-feedgen + 2 Combined summary - BIP 151 - 2023-08-01T18:42:21.264751+00:00 + 2025-09-26T15:29:17.227293+00:00 - In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. 2016-08-31T14:29:53+00:00 + In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_BIP-Number-Request-Open-Asset.xml b/static/bitcoin-dev/July_2016/combined_BIP-Number-Request-Open-Asset.xml index 7b3ca6d33f..085e800499 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-Number-Request-Open-Asset.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-Number-Request-Open-Asset.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Number Request: Open Asset - 2023-08-01T18:24:14.439237+00:00 + 2025-09-26T15:29:21.455432+00:00 + python-feedgen Nicolas Dorier 2016-08-13 02:25:04+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - BIP Number Request: Open Asset - 2023-08-01T18:24:14.439237+00:00 + 2025-09-26T15:29:21.455637+00:00 - The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it 2016-08-13T02:25:04+00:00 + The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_BIP-draft-HTLC-transactions.xml b/static/bitcoin-dev/July_2016/combined_BIP-draft-HTLC-transactions.xml index 220ca14ace..267a826556 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-draft-HTLC-transactions.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-draft-HTLC-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft: HTLC transactions - 2023-08-01T18:46:03.562680+00:00 + 2025-09-26T15:29:25.717578+00:00 + python-feedgen Johnson Lau 2016-08-17 10:00:37+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP draft: HTLC transactions - 2023-08-01T18:46:03.562680+00:00 + 2025-09-26T15:29:25.717735+00:00 - On July 20, 2016, a discussion took place on the bitcoin-dev mailing list regarding Hash Time-Locked Contract (HTLC) transactions in Bitcoin. Sean Bowe requested feedback on these transactions which allow payment for the preimage of a hash, with CSV/CLTV used to recover funds if the other party is uncooperative. Luke Dashjr proposed using OP_SIZE to address the malleability issue caused by hashing the top item on the stack, and Peter Todd praised this idea.The HTLC scripts have a specific structure, starting with [HASHOP] OP_EQUAL followed by an OP_IF and an OP_ELSE, with a [TIMEOUTOP] OP_DROP in between. The script concludes with an OP_CHECKSIG. However, this design makes the scripts malleable as the top stack item can be modified without invalidating the scriptSig. Todd suggests using the OP_SIZE opcode to make it more difficult for attackers to manipulate transactions. This additional requirement involves adding OP_SIZE OP_2 OP_PICK OP_HASH160 [PUBKEYHASH] OP_EQUALVERIFY to the script.Todd also emphasizes the importance of considering different scenarios, such as malicious parties attempting double-spend attacks. The discussion delves into the vulnerabilities of HTLC transactions and provides suggestions for enhancing their security.In addition to the discussion, Sean Bowe shares his draft BIP for HTLC transactions on GitHub. Members of the community express interest in submitting a BIP to support these transactions in wallets with modifications to Bitcoin Core. An implementation of Bowe's draft BIP is currently under development. The HTLC scripts are seen as valuable for applications like the Lightning network and zero-knowledge contingent payments, as demonstrated by the author's 'pay-to-sudoku' ZKCP demo earlier in the year, which utilized the same script implemented with CLTV and SHA256. 2016-08-17T10:00:37+00:00 + On July 20, 2016, a discussion took place on the bitcoin-dev mailing list regarding Hash Time-Locked Contract (HTLC) transactions in Bitcoin. Sean Bowe requested feedback on these transactions which allow payment for the preimage of a hash, with CSV/CLTV used to recover funds if the other party is uncooperative. Luke Dashjr proposed using OP_SIZE to address the malleability issue caused by hashing the top item on the stack, and Peter Todd praised this idea.The HTLC scripts have a specific structure, starting with [HASHOP] OP_EQUAL followed by an OP_IF and an OP_ELSE, with a [TIMEOUTOP] OP_DROP in between. The script concludes with an OP_CHECKSIG. However, this design makes the scripts malleable as the top stack item can be modified without invalidating the scriptSig. Todd suggests using the OP_SIZE opcode to make it more difficult for attackers to manipulate transactions. This additional requirement involves adding OP_SIZE OP_2 OP_PICK OP_HASH160 [PUBKEYHASH] OP_EQUALVERIFY to the script.Todd also emphasizes the importance of considering different scenarios, such as malicious parties attempting double-spend attacks. The discussion delves into the vulnerabilities of HTLC transactions and provides suggestions for enhancing their security.In addition to the discussion, Sean Bowe shares his draft BIP for HTLC transactions on GitHub. Members of the community express interest in submitting a BIP to support these transactions in wallets with modifications to Bitcoin Core. An implementation of Bowe's draft BIP is currently under development. The HTLC scripts are seen as valuable for applications like the Lightning network and zero-knowledge contingent payments, as demonstrated by the author's 'pay-to-sudoku' ZKCP demo earlier in the year, which utilized the same script implemented with CLTV and SHA256. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_BIP-proposal-derived-mnemonics.xml b/static/bitcoin-dev/July_2016/combined_BIP-proposal-derived-mnemonics.xml index 40f1082752..954a3e7ea6 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-proposal-derived-mnemonics.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-proposal-derived-mnemonics.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP proposal: derived mnemonics - 2023-08-01T18:47:37.563336+00:00 + 2025-09-26T15:29:23.577648+00:00 + python-feedgen Gregory Maxwell 2016-07-27 20:59:54+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: derived mnemonics - 2023-08-01T18:47:37.563336+00:00 + 2025-09-26T15:29:23.577778+00:00 - In a bitcoin-dev discussion, concerns were raised about the security of Bip39's use of PBKDF2 with 2048 iterations to protect large amounts of funds. Alternative methods of protection were proposed, including the use of a scheme that supports delegatable hardening or eschewing pretextual 'hardening'. However, these alternatives were rejected by the authors of the Bip39 spec. It was pointed out that Bip39 is not a brainwallet solely protected by the passphrase. The Digital Bitbox team uses PBKDF2 with over 20,000 iterations on the computer and an additional 2048 rounds on-chip to secure user-entered passphrases for their hardware wallet. Adding two random lowercase letters to the passphrase can increase security, but relying solely on a strong passphrase is not recommended. It is important to choose a good passphrase and take measures to ensure the seed is not stolen.Jonas Schnelli expressed concerns over the use of PBKDF2 with 2048 iterations in Bip39, suggesting it is not sufficient to protect large amounts of funds. He questioned alternative methods, such as using an expensive processor and memory in every hardware wallet or waiting ten minutes after entering a passphrase with a million iterations. The idea of adding two random lowercase letters to a passphrase with 2048 iterations was considered to potentially provide better protection. Schnelli advised users to choose a good passphrase or ensure their seed is not stolen.The article explains how a master mnemonic is generated from a standard mnemonic according to BIP39. A new string is created using Count and Strength, where Count represents different derived mnemonics of a given strength, and Strength is calculated based on the desired number of words for the derived mnemonic. The string is then hashed using sha512. The author suggests using sha512_hmac with a passphrase and salt instead of a checksum based on a predetermined wordlist, highlighting security downsides. An alternative idea of deriving a child key after bip32 and using the derived 256bits to encode the mnemonic is proposed. Concerns are raised about users only storing and backing up the bip39 mnemonic, as reconstructing funds from a seed can be difficult without access to a trusted TX-indexed full node. Novice users might underestimate the risk of losing metadata coupled with their transactions when they only store the wallet seed.The author has submitted a draft BIP proposal for derived mnemonics from a master mnemonic, aiming to make it easier to split funds into smaller fractions and use them in an HD-wallet without putting the master mnemonic at risk on an online computer. The master mnemonic is generated offline, and multiple derived mnemonics are generated deterministically offline for online use. The proposed method uses sha512 hashing to generate byte arrays to create new mnemonics. A reference implementation for a 24-word master mnemonic based on BIP44 is available on the provided website. Use cases include splitting funds into fractions, sending them to multiple addresses, giving derived mnemonics to family members with bitcoin, and memorizing only a 12-word seed. 2016-07-27T20:59:54+00:00 + In a bitcoin-dev discussion, concerns were raised about the security of Bip39's use of PBKDF2 with 2048 iterations to protect large amounts of funds. Alternative methods of protection were proposed, including the use of a scheme that supports delegatable hardening or eschewing pretextual 'hardening'. However, these alternatives were rejected by the authors of the Bip39 spec. It was pointed out that Bip39 is not a brainwallet solely protected by the passphrase. The Digital Bitbox team uses PBKDF2 with over 20,000 iterations on the computer and an additional 2048 rounds on-chip to secure user-entered passphrases for their hardware wallet. Adding two random lowercase letters to the passphrase can increase security, but relying solely on a strong passphrase is not recommended. It is important to choose a good passphrase and take measures to ensure the seed is not stolen.Jonas Schnelli expressed concerns over the use of PBKDF2 with 2048 iterations in Bip39, suggesting it is not sufficient to protect large amounts of funds. He questioned alternative methods, such as using an expensive processor and memory in every hardware wallet or waiting ten minutes after entering a passphrase with a million iterations. The idea of adding two random lowercase letters to a passphrase with 2048 iterations was considered to potentially provide better protection. Schnelli advised users to choose a good passphrase or ensure their seed is not stolen.The article explains how a master mnemonic is generated from a standard mnemonic according to BIP39. A new string is created using Count and Strength, where Count represents different derived mnemonics of a given strength, and Strength is calculated based on the desired number of words for the derived mnemonic. The string is then hashed using sha512. The author suggests using sha512_hmac with a passphrase and salt instead of a checksum based on a predetermined wordlist, highlighting security downsides. An alternative idea of deriving a child key after bip32 and using the derived 256bits to encode the mnemonic is proposed. Concerns are raised about users only storing and backing up the bip39 mnemonic, as reconstructing funds from a seed can be difficult without access to a trusted TX-indexed full node. Novice users might underestimate the risk of losing metadata coupled with their transactions when they only store the wallet seed.The author has submitted a draft BIP proposal for derived mnemonics from a master mnemonic, aiming to make it easier to split funds into smaller fractions and use them in an HD-wallet without putting the master mnemonic at risk on an online computer. The master mnemonic is generated offline, and multiple derived mnemonics are generated deterministically offline for online use. The proposed method uses sha512 hashing to generate byte arrays to create new mnemonics. A reference implementation for a 24-word master mnemonic based on BIP44 is available on the provided website. Use cases include splitting funds into fractions, sending them to multiple addresses, giving derived mnemonics to family members with bitcoin, and memorizing only a 12-word seed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml b/static/bitcoin-dev/July_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml index 244223df81..c372eb9203 100644 --- a/static/bitcoin-dev/July_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml +++ b/static/bitcoin-dev/July_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Code Review: The Consensus Critical Parts of Segwit by Peter Todd - 2023-08-01T18:44:26.625038+00:00 + 2025-09-26T15:29:13.004076+00:00 + python-feedgen Peter Todd 2016-07-04 23:27:15+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Code Review: The Consensus Critical Parts of Segwit by Peter Todd - 2023-08-01T18:44:26.625038+00:00 + 2025-09-26T15:29:13.004231+00:00 - In a discussion about the implementation of Segregated Witness (SegWit) on the Bitcoin network, one issue raised is the odd result that occurs when a transaction spends a witness output with an unknown version. Surprisingly, this transaction is valid even if it doesn't have any witnesses. One suggestion is to leave these unknown witness programs as any-one-can-spend without looking at the witness. However, this creates a special case in the code, allowing spending of a witness output without a witness.There is a debate about whether to allow the use of 160-bit commitments for multisig transactions, which may require 256-bit security. The argument is that using shorter hash and pubkey for storing a small amount of Bitcoin could save bytes. However, concerns are raised about potential hash collisions and the reuse of signatures for different signature hashes. To address this, tagged hashing is proposed as a way to ensure that signatures cannot be reused in different contexts. XORing the magic tag prior to its use is suggested as sufficient for signature applications.Unfortunately, this method is not compatible with timestamping schemes like OpenTimestamps, which rely on all operations being cryptographically secure. Another concern is the difficulty of adding new commitments with soft forks. It is pointed out that anything after 38 bytes in the reserve value of a 32-byte hash has no consensus meaning, making it inefficient to add new commitments with softforks.In an email exchange between Johnson Lau and Bitcoin developer Peter Todd, various issues related to SegWit implementation are discussed. They discuss the possibility of allowing users to choose a less secure 160-bit commitment if their use-case doesn't require the full 256-bit security level. Additionally, the maximum size of serialized witness scripts is debated, with the constraint being set at 520 bytes. Lastly, there is a mention of concern about hash collision, although it is unclear how it could be possible.Overall, the discussion revolves around the complexities and potential vulnerabilities of implementing Segregated Witness on the Bitcoin network, with various suggestions and concerns being raised by different participants. The goal is to find solutions that ensure the security and efficiency of transactions while avoiding any potential issues or conflicts. 2016-07-04T23:27:15+00:00 + In a discussion about the implementation of Segregated Witness (SegWit) on the Bitcoin network, one issue raised is the odd result that occurs when a transaction spends a witness output with an unknown version. Surprisingly, this transaction is valid even if it doesn't have any witnesses. One suggestion is to leave these unknown witness programs as any-one-can-spend without looking at the witness. However, this creates a special case in the code, allowing spending of a witness output without a witness.There is a debate about whether to allow the use of 160-bit commitments for multisig transactions, which may require 256-bit security. The argument is that using shorter hash and pubkey for storing a small amount of Bitcoin could save bytes. However, concerns are raised about potential hash collisions and the reuse of signatures for different signature hashes. To address this, tagged hashing is proposed as a way to ensure that signatures cannot be reused in different contexts. XORing the magic tag prior to its use is suggested as sufficient for signature applications.Unfortunately, this method is not compatible with timestamping schemes like OpenTimestamps, which rely on all operations being cryptographically secure. Another concern is the difficulty of adding new commitments with soft forks. It is pointed out that anything after 38 bytes in the reserve value of a 32-byte hash has no consensus meaning, making it inefficient to add new commitments with softforks.In an email exchange between Johnson Lau and Bitcoin developer Peter Todd, various issues related to SegWit implementation are discussed. They discuss the possibility of allowing users to choose a less secure 160-bit commitment if their use-case doesn't require the full 256-bit security level. Additionally, the maximum size of serialized witness scripts is debated, with the constraint being set at 520 bytes. Lastly, there is a mention of concern about hash collision, although it is unclear how it could be possible.Overall, the discussion revolves around the complexities and potential vulnerabilities of implementing Segregated Witness on the Bitcoin network, with various suggestions and concerns being raised by different participants. The goal is to find solutions that ensure the security and efficiency of transactions while avoiding any potential issues or conflicts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml b/static/bitcoin-dev/July_2016/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml index f4364d22b6..49c632b8e7 100644 --- a/static/bitcoin-dev/July_2016/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml +++ b/static/bitcoin-dev/July_2016/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml @@ -1,113 +1,147 @@ - + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 - - bfd at cock.lu 2017-04-01 23:49:03+00:00 - - - Tom Harding 2017-03-16 15:05:11+00:00 - - - bfd at cock.lu 2017-03-16 00:25:01+00:00 - - - Tom Harding 2017-03-15 22:36:09+00:00 - - - Chris Belcher 2017-02-17 00:28:59+00:00 - - - Erik Aronesty 2017-01-06 22:07:36+00:00 - - - Eric Voskuil 2017-01-06 21:50:47+00:00 - - - James MacWhyte 2017-01-06 21:35:58+00:00 - - - Chris Priest 2017-01-06 20:15:46+00:00 - - - Aaron Voisine 2017-01-06 07:07:34+00:00 - - - bfd at cock.lu 2017-01-06 02:15:26+00:00 - - - bfd at cock.lu 2017-01-06 02:04:22+00:00 - - - Christian Decker 2017-01-05 14:48:33+00:00 - - - Eric Voskuil 2017-01-05 07:45:18+00:00 - - - Chris Priest 2017-01-05 07:06:36+00:00 - - - Leo Wandersleb 2017-01-04 16:13:41+00:00 - - - Adam Back 2017-01-04 11:00:55+00:00 - - - Jorge Timón 2017-01-04 10:13:02+00:00 - - - Aaron Voisine 2017-01-04 08:56:21+00:00 - - - Jonas Schnelli 2017-01-04 07:47:10+00:00 - - - Eric Voskuil 2017-01-04 06:06:31+00:00 - - - Aaron Voisine 2017-01-04 00:36:34+00:00 - - - bfd at cock.lu 2017-01-04 00:10:14+00:00 - - - Aaron Voisine 2017-01-03 23:46:00+00:00 - - - adiabat 2017-01-03 23:06:26+00:00 - - - bfd at cock.lu 2017-01-03 22:28:56+00:00 - - - Aaron Voisine 2017-01-03 22:18:21+00:00 - - - bfd at cock.lu 2017-01-03 20:24:35+00:00 - - - bfd at cock.lu 2017-01-03 20:18:59+00:00 - - - Jonas Schnelli 2017-01-01 21:01:23+00:00 - - - Leo Wandersleb 2016-07-28 21:07:29+00:00 - - - Bob McElrath 2016-05-11 20:29:33+00:00 - - - Bob McElrath 2016-05-11 20:06:48+00:00 - - - Gregory Maxwell 2016-05-09 08:57:08+00:00 - - - bfd at cock.lu 2016-05-09 08:26:06+00:00 - + 2025-09-26T15:29:27.834442+00:00 + python-feedgen + + + [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd + 2016-05-09T08:26:00.000Z + + + Gregory Maxwell + 2016-05-09T08:57:00.000Z + + + Bob McElrath + 2016-05-11T20:06:00.000Z + + + Bob McElrath + 2016-05-11T20:29:00.000Z + + + Leo Wandersleb + 2016-07-28T21:07:00.000Z + + + bfd + 2017-01-03T20:18:00.000Z + + + bfd + 2017-01-03T20:24:00.000Z + + + Aaron Voisine + 2017-01-03T22:18:00.000Z + + + bfd + 2017-01-03T22:28:00.000Z + + + adiabat + 2017-01-03T23:06:00.000Z + + + Aaron Voisine + 2017-01-03T23:46:00.000Z + + + bfd + 2017-01-04T00:10:00.000Z + + + Aaron Voisine + 2017-01-04T00:36:00.000Z + + + Eric Voskuil + 2017-01-04T06:06:00.000Z + + + Jonas Schnelli + 2017-01-04T07:47:00.000Z + + + Aaron Voisine + 2017-01-04T08:56:00.000Z + + + Jorge Timón + 2017-01-04T10:13:00.000Z + + + Adam Back + 2017-01-04T11:00:00.000Z + + + Leo Wandersleb + 2017-01-04T16:13:00.000Z + + + Chris Priest + 2017-01-05T07:06:00.000Z + + + Eric Voskuil + 2017-01-05T07:45:00.000Z + + + Christian Decker + 2017-01-05T14:48:00.000Z + + + bfd + 2017-01-06T02:04:00.000Z + + + bfd + 2017-01-06T02:15:00.000Z + + + Aaron Voisine + 2017-01-06T07:07:00.000Z + + + Chris Priest + 2017-01-06T20:15:00.000Z + + + James MacWhyte + 2017-01-06T21:35:00.000Z + + + Eric Voskuil + 2017-01-06T21:50:00.000Z + + + Erik Aronesty + 2017-01-06T22:07:00.000Z + + + Chris Belcher + 2017-02-17T00:28:00.000Z + + + Tom Harding + 2017-03-15T22:36:00.000Z + + + bfd + 2017-03-16T00:25:00.000Z + + + Tom Harding + 2017-03-16T15:05:00.000Z + + + bfd + 2017-04-01T23:49:00.000Z + + @@ -143,13 +177,13 @@ - python-feedgen + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 + 2025-09-26T15:29:27.838181+00:00 - In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On 2017-04-01T23:49:03+00:00 + In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_Holdup-on-Block-Alerts-Fraud-Proofs-.xml b/static/bitcoin-dev/July_2016/combined_Holdup-on-Block-Alerts-Fraud-Proofs-.xml index 97659dac30..75814e5aad 100644 --- a/static/bitcoin-dev/July_2016/combined_Holdup-on-Block-Alerts-Fraud-Proofs-.xml +++ b/static/bitcoin-dev/July_2016/combined_Holdup-on-Block-Alerts-Fraud-Proofs-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Holdup on Block Alerts / Fraud Proofs ? - 2023-08-01T18:47:59.873532+00:00 + 2025-09-26T15:29:06.669531+00:00 + python-feedgen Luke Dashjr 2016-07-31 05:18:18+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Holdup on Block Alerts / Fraud Proofs ? - 2023-08-01T18:47:59.873532+00:00 + 2025-09-26T15:29:06.669690+00:00 - In a Bitcoin developers' mailing list discussion, Paul Sztorc proposed the implementation of "alerts" to address the problem of transactions referencing block content on a "pretender block." However, there is still an issue with constructing a block that cannot be proven invalid. While it is possible to prove the invalidity of a transaction within a well-formed block, there is no way to prove that a block is not well-formed. This could result in a valid block with some transactions being withheld until it becomes stale, making it impossible for full nodes and miners to accept it without knowing all the transactions in the block.The proposed solution to this problem is for users to demand the full block from attackers. However, this opens up the possibility of attackers launching denial-of-service attacks by providing bogus incomplete-block claims. This is particularly problematic for users who rely on Simplified Payment Verification (SPV) and do not have the bandwidth to run a full node.In another discussion on the bitcoin-dev mailing list, Paul Sztorc expressed confusion about how segwit (Segregated Witness) would help in this context. Another member of the community, Bryan, shared a link to discussions on the topic that took place on the bitcoin-core-dev chat channel in December 2015. Although the link is currently unavailable, it may have contained useful information regarding the potential benefits of segwit.The idea of incentivizing users to provide proof of invalid block content dates back to Satoshi's whitepaper. This concept would be particularly valuable for Alice, who is running an SPV client. Paul Sztorc suggests that implementing "alerts" would be relatively straightforward and offers details on how this could be achieved using a new OP code. He also acknowledges that implementing "fraud proofs" (as they are now called) would require significant engineering work and asks if anyone can direct him to the problems associated with this approach.Sztorc outlines a proposed solution involving the creation of an OP Code called "OP FraudProof." This OP Code would include arguments such as a block number, block header, and merkle path from the header to an invalid transaction. In practice, this OP Code can be used in a transaction where Alice provides 1 BTC and X provides 0.2 BTC. If X signs the transaction, Alice assumes the block is invalid and stops offering to buy fraud proofs for it. If X does not sign, Alice gets her money back plus 0.2 BTC from Eric for wasting her time. Sztorc notes that the definition of an "invalid transaction" could refer to either a script that fails or a double-spend.While acknowledging that implementing this solution is not a simple task, Sztorc does not consider it to be a significant engineering overhaul. He also mentions that segwit may have a role in supporting this solution, although he does not fully understand why. 2016-07-31T05:18:18+00:00 + In a Bitcoin developers' mailing list discussion, Paul Sztorc proposed the implementation of "alerts" to address the problem of transactions referencing block content on a "pretender block." However, there is still an issue with constructing a block that cannot be proven invalid. While it is possible to prove the invalidity of a transaction within a well-formed block, there is no way to prove that a block is not well-formed. This could result in a valid block with some transactions being withheld until it becomes stale, making it impossible for full nodes and miners to accept it without knowing all the transactions in the block.The proposed solution to this problem is for users to demand the full block from attackers. However, this opens up the possibility of attackers launching denial-of-service attacks by providing bogus incomplete-block claims. This is particularly problematic for users who rely on Simplified Payment Verification (SPV) and do not have the bandwidth to run a full node.In another discussion on the bitcoin-dev mailing list, Paul Sztorc expressed confusion about how segwit (Segregated Witness) would help in this context. Another member of the community, Bryan, shared a link to discussions on the topic that took place on the bitcoin-core-dev chat channel in December 2015. Although the link is currently unavailable, it may have contained useful information regarding the potential benefits of segwit.The idea of incentivizing users to provide proof of invalid block content dates back to Satoshi's whitepaper. This concept would be particularly valuable for Alice, who is running an SPV client. Paul Sztorc suggests that implementing "alerts" would be relatively straightforward and offers details on how this could be achieved using a new OP code. He also acknowledges that implementing "fraud proofs" (as they are now called) would require significant engineering work and asks if anyone can direct him to the problems associated with this approach.Sztorc outlines a proposed solution involving the creation of an OP Code called "OP FraudProof." This OP Code would include arguments such as a block number, block header, and merkle path from the header to an invalid transaction. In practice, this OP Code can be used in a transaction where Alice provides 1 BTC and X provides 0.2 BTC. If X signs the transaction, Alice assumes the block is invalid and stops offering to buy fraud proofs for it. If X does not sign, Alice gets her money back plus 0.2 BTC from Eric for wasting her time. Sztorc notes that the definition of an "invalid transaction" could refer to either a script that fails or a double-spend.While acknowledging that implementing this solution is not a simple task, Sztorc does not consider it to be a significant engineering overhaul. He also mentions that segwit may have a role in supporting this solution, although he does not fully understand why. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_Merkle-trees-and-mountain-ranges.xml b/static/bitcoin-dev/July_2016/combined_Merkle-trees-and-mountain-ranges.xml index 29b634d0ed..caffb7a7f4 100644 --- a/static/bitcoin-dev/July_2016/combined_Merkle-trees-and-mountain-ranges.xml +++ b/static/bitcoin-dev/July_2016/combined_Merkle-trees-and-mountain-ranges.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Merkle trees and mountain ranges - 2023-08-01T18:27:34.546121+00:00 + 2025-09-26T15:29:08.782381+00:00 + python-feedgen Bram Cohen 2016-07-15 23:00:57+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Merkle trees and mountain ranges - 2023-08-01T18:27:34.546121+00:00 + 2025-09-26T15:29:08.782581+00:00 - In an email exchange between Peter Todd and Bram Cohen, the topic of discussion revolves around various aspects of UTXO commitments, merkle trees, and optimizations. Todd suggests using BLAKE2b for internal hashing due to its efficiency in omitting padding when the data is exactly one block in size. The implementation of a root branch block with nodes arranged in fixed positions and terminals having outpointers to other blocks is also discussed. The conversation also delves into the efficiency of their implementation when stored on a spinning hard drive. It is estimated that even an underpowered node could keep up with the blockchain if it is full of simple transactions. Validating an entire blockchain history might take a few days, but if some layers are kept in regular memory, validating a whole year of history might only take a few hours. The complexity of the MMR proposal's data structures is acknowledged, and it is suggested that specifying storage media and latency expectations would clarify the reasoning significantly.Cohen considers committing to the prefix as a way of handling cases where multiple keys share parts of the same prefix, but concludes that it would only save about 10% of memory in his implementation. Todd explains that committing to the prefix is a simple but possibly not-optimal way of committing to what data should be accessible under a given node. They discuss the depths of merkbiner trees in proportion to log2(n) against attackers who are choosing keys by grinding hashes. The optimization of hashing time is also explored, with the mention of the efficiency of BLAKE2 compared to SHA256.The conversation then moves on to the implementation of merkle trees and how each node contains metadata byte followed by fixed-size secure hashes and pointers to the children. The structure of branch blocks, terminals, and leaf blocks is explained, along with the overflow mechanism when a leaf block exceeds its capacity. The idea of achieving practical Bitcoin updates with minimal cache misses is discussed, with Cohen explaining the clever placement of nodes in memory to minimize cache misses.Another aspect of the conversation revolves around adding latency to UTXO commitments. It is agreed that adding latency can work in principle but should only be used as a last resort technique when optimization fails. The addition of roots of what's added and deleted in each block allows for proofs of inclusion and exclusion without significant latency. However, it adds complexity and should only be done when necessary for fast validation before block propagation.The discussion also touches upon the indexing of the UTXO set, the possibility of introducing incentives for collecting dust, and the use of variable-sized commitments instead of hash digests for improved efficiency. There is a debate about whether validation before block propagation needs to be done at all, with Todd suggesting that it's reasonable to propagate blocks that have not been fully validated beyond checking PoW. The importance of minimizing the time it takes miners to start mining the next block and collecting fees is emphasized.There are additional conversations discussing the technicalities of TXO commitments, the differences between merkle trees and patricia tries, and the performance and optimization considerations of implementing UTXO, STXO, and TXO commitments. The use of mountain ranges for merkle trees is debated, with suggestions for alternative approaches such as raw merkle trees.In conclusion, the email exchanges provide detailed insights into the discussions surrounding UTXO commitments, merkle trees, optimizations, latency issues, and various implementation considerations within the Bitcoin community. The conversations highlight the complexities and trade-offs involved in designing efficient and secure blockchain data structures. 2016-07-15T23:00:57+00:00 + In an email exchange between Peter Todd and Bram Cohen, the topic of discussion revolves around various aspects of UTXO commitments, merkle trees, and optimizations. Todd suggests using BLAKE2b for internal hashing due to its efficiency in omitting padding when the data is exactly one block in size. The implementation of a root branch block with nodes arranged in fixed positions and terminals having outpointers to other blocks is also discussed. The conversation also delves into the efficiency of their implementation when stored on a spinning hard drive. It is estimated that even an underpowered node could keep up with the blockchain if it is full of simple transactions. Validating an entire blockchain history might take a few days, but if some layers are kept in regular memory, validating a whole year of history might only take a few hours. The complexity of the MMR proposal's data structures is acknowledged, and it is suggested that specifying storage media and latency expectations would clarify the reasoning significantly.Cohen considers committing to the prefix as a way of handling cases where multiple keys share parts of the same prefix, but concludes that it would only save about 10% of memory in his implementation. Todd explains that committing to the prefix is a simple but possibly not-optimal way of committing to what data should be accessible under a given node. They discuss the depths of merkbiner trees in proportion to log2(n) against attackers who are choosing keys by grinding hashes. The optimization of hashing time is also explored, with the mention of the efficiency of BLAKE2 compared to SHA256.The conversation then moves on to the implementation of merkle trees and how each node contains metadata byte followed by fixed-size secure hashes and pointers to the children. The structure of branch blocks, terminals, and leaf blocks is explained, along with the overflow mechanism when a leaf block exceeds its capacity. The idea of achieving practical Bitcoin updates with minimal cache misses is discussed, with Cohen explaining the clever placement of nodes in memory to minimize cache misses.Another aspect of the conversation revolves around adding latency to UTXO commitments. It is agreed that adding latency can work in principle but should only be used as a last resort technique when optimization fails. The addition of roots of what's added and deleted in each block allows for proofs of inclusion and exclusion without significant latency. However, it adds complexity and should only be done when necessary for fast validation before block propagation.The discussion also touches upon the indexing of the UTXO set, the possibility of introducing incentives for collecting dust, and the use of variable-sized commitments instead of hash digests for improved efficiency. There is a debate about whether validation before block propagation needs to be done at all, with Todd suggesting that it's reasonable to propagate blocks that have not been fully validated beyond checking PoW. The importance of minimizing the time it takes miners to start mining the next block and collecting fees is emphasized.There are additional conversations discussing the technicalities of TXO commitments, the differences between merkle trees and patricia tries, and the performance and optimization considerations of implementing UTXO, STXO, and TXO commitments. The use of mountain ranges for merkle trees is debated, with suggestions for alternative approaches such as raw merkle trees.In conclusion, the email exchanges provide detailed insights into the discussions surrounding UTXO commitments, merkle trees, optimizations, latency issues, and various implementation considerations within the Bitcoin community. The conversations highlight the complexities and trade-offs involved in designing efficient and secure blockchain data structures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_Reasons-to-add-sync-flags-to-Bitcoin.xml b/static/bitcoin-dev/July_2016/combined_Reasons-to-add-sync-flags-to-Bitcoin.xml index 29930f3c44..d0d23e1e1b 100644 --- a/static/bitcoin-dev/July_2016/combined_Reasons-to-add-sync-flags-to-Bitcoin.xml +++ b/static/bitcoin-dev/July_2016/combined_Reasons-to-add-sync-flags-to-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reasons to add sync flags to Bitcoin - 2023-08-01T18:47:12.174319+00:00 + 2025-09-26T15:29:15.114081+00:00 + python-feedgen Moral Agent 2016-07-28 16:41:48+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Reasons to add sync flags to Bitcoin - 2023-08-01T18:47:12.174319+00:00 + 2025-09-26T15:29:15.114214+00:00 - A proposed strategy to mitigate the impact of a block-with-valid-header-but-invalid-transactions-spam-attack involves the use of sync flags. The key aspect of this strategy is relaxing the requirement for a flag to commit to a completely valid block, instead only requiring a valid block header. Miners can start mining a flag as soon as they have a valid block header and can choose to continue or abandon mining the flag if spam is detected. The distribution of hashpower between the flag and mining for a valid block should reflect miners' estimation of the cost of negative outcomes. This approach effectively neutralizes the harm caused by the attack and incorporates the work done to produce the spam into the blockchain's cumulative Proof of Work, without rewarding the spammer.The author of the proposal has created a repository for sync_flags and made some changes to it, which can be found in the repo. The author's main idea is to enhance mining decentralization by having all miners start hashing the next block simultaneously. This synchronization can be achieved through the use of sync flags, which are messages consisting of a hash of the previous block, a bitcoin address, and a nonce. Miners wait for the flag, and when it spreads through the network, they can begin hashing the next block together. To fund this proof of work, the protocol is modified to require that the block produced 10 blocks after the sync flag allocate 25% of the block reward to the address specified by the flag. Sync flags offer several advantages over optimistic mining. They reduce variance in mining profitability, eliminate SPV mined blocks and empty blocks, smooth out resource usage, alleviate the latency bottleneck on throughput, make transaction stuffing by miners either obvious or costly, and give miners a task while waiting for attractive transactions. The author addresses concerns about selfish mining, invalid block spam, payout compatibility with certain mining pools, and the impact of mandatory empty blocks on sync flags. By mining a sync flag instead, the use of Bitcoin miners for destabilizing purposes can be avoided. This approach would put miners to profitable work while they wait and create a more efficient price discovery mechanism for transactions. Transactions with high fees would have time to enter the marketplace, rather than being taken quickly because all the desirable transactions were included in the previous block. Implementing sync flags through a soft fork is feasible, although a hard fork would be more efficient. The proposed implementation requires that every block includes a transaction allocating 25% of the block reward to the address provided by the 10th previous sync flag and commits to the hash of the 1st previous sync flag.Moral Agent proposed a solution to enhance mining decentralization and reduce variance in mining profitability. The idea involves using a sync flag as a message that propagates at maximum speed through the network, triggering all miners to simultaneously start hashing the next block. The sync flag is composed of the hash of the previous block, a Bitcoin address, and a nonce. To ensure the implementation of this idea, the protocol is adjusted to mandate that the block produced 10 blocks after the sync flag allocates 25% of the block reward to the address specified by the flag. This proposal brings various benefits such as eliminating SPV mined blocks and empty blocks, reducing latency bottlenecks, making transaction stuffing costly or obvious, and providing miners with an activity while waiting for attractive transactions. A soft fork can easily implement sync flags. However, the current payout structure of non hot-wallet pools and decentralized pools may not be compatible with mining the sync flag. Instead of specifying an address for funds, including the hash of the transaction allowed to spend the sync flag output could be an alternative.In a bitcoin-dev mailing list discussion, Martijn Meijering questioned whether selfish mining of sync flags would be more likely compared to ordinary blocks. A proposal was suggested to achieve the same result as adding mandatory empty blocks by targeting Proof-of-Work (PoW) at 2 minutes to produce a flag every 2 minutes and a block every 8 minutes. The conversion rate from hashing power to reward would be the same for both flags and blocks. However, a soft fork implementing this rule would divert 20% of its hashing power to flag blocks, which legacy nodes would ignore. To win the race, the soft fork would require 55% of the hashing power. Consequently, headers-first clients would need to download more information to verify the longest chain as they would miss 20% of the PoW if they only downloaded headers.The concept of selfish mining of sync flags is introduced, where miners may selfishly mine flags and withhold them until the benefit gained from withholding is less than the mining reward. This practice could undermine decentralization, favoring only big miners capable of engaging in selfish mining. It may also encourage collusion among miners, resulting in flags being shipped only to miners with established business relationships, thereby reducing flag revenue and providing an advantage to in-group miners in main-chain mining.The idea of using a sync flag to ensure 2016-07-28T16:41:48+00:00 + A proposed strategy to mitigate the impact of a block-with-valid-header-but-invalid-transactions-spam-attack involves the use of sync flags. The key aspect of this strategy is relaxing the requirement for a flag to commit to a completely valid block, instead only requiring a valid block header. Miners can start mining a flag as soon as they have a valid block header and can choose to continue or abandon mining the flag if spam is detected. The distribution of hashpower between the flag and mining for a valid block should reflect miners' estimation of the cost of negative outcomes. This approach effectively neutralizes the harm caused by the attack and incorporates the work done to produce the spam into the blockchain's cumulative Proof of Work, without rewarding the spammer.The author of the proposal has created a repository for sync_flags and made some changes to it, which can be found in the repo. The author's main idea is to enhance mining decentralization by having all miners start hashing the next block simultaneously. This synchronization can be achieved through the use of sync flags, which are messages consisting of a hash of the previous block, a bitcoin address, and a nonce. Miners wait for the flag, and when it spreads through the network, they can begin hashing the next block together. To fund this proof of work, the protocol is modified to require that the block produced 10 blocks after the sync flag allocate 25% of the block reward to the address specified by the flag. Sync flags offer several advantages over optimistic mining. They reduce variance in mining profitability, eliminate SPV mined blocks and empty blocks, smooth out resource usage, alleviate the latency bottleneck on throughput, make transaction stuffing by miners either obvious or costly, and give miners a task while waiting for attractive transactions. The author addresses concerns about selfish mining, invalid block spam, payout compatibility with certain mining pools, and the impact of mandatory empty blocks on sync flags. By mining a sync flag instead, the use of Bitcoin miners for destabilizing purposes can be avoided. This approach would put miners to profitable work while they wait and create a more efficient price discovery mechanism for transactions. Transactions with high fees would have time to enter the marketplace, rather than being taken quickly because all the desirable transactions were included in the previous block. Implementing sync flags through a soft fork is feasible, although a hard fork would be more efficient. The proposed implementation requires that every block includes a transaction allocating 25% of the block reward to the address provided by the 10th previous sync flag and commits to the hash of the 1st previous sync flag.Moral Agent proposed a solution to enhance mining decentralization and reduce variance in mining profitability. The idea involves using a sync flag as a message that propagates at maximum speed through the network, triggering all miners to simultaneously start hashing the next block. The sync flag is composed of the hash of the previous block, a Bitcoin address, and a nonce. To ensure the implementation of this idea, the protocol is adjusted to mandate that the block produced 10 blocks after the sync flag allocates 25% of the block reward to the address specified by the flag. This proposal brings various benefits such as eliminating SPV mined blocks and empty blocks, reducing latency bottlenecks, making transaction stuffing costly or obvious, and providing miners with an activity while waiting for attractive transactions. A soft fork can easily implement sync flags. However, the current payout structure of non hot-wallet pools and decentralized pools may not be compatible with mining the sync flag. Instead of specifying an address for funds, including the hash of the transaction allowed to spend the sync flag output could be an alternative.In a bitcoin-dev mailing list discussion, Martijn Meijering questioned whether selfish mining of sync flags would be more likely compared to ordinary blocks. A proposal was suggested to achieve the same result as adding mandatory empty blocks by targeting Proof-of-Work (PoW) at 2 minutes to produce a flag every 2 minutes and a block every 8 minutes. The conversion rate from hashing power to reward would be the same for both flags and blocks. However, a soft fork implementing this rule would divert 20% of its hashing power to flag blocks, which legacy nodes would ignore. To win the race, the soft fork would require 55% of the hashing power. Consequently, headers-first clients would need to download more information to verify the longest chain as they would miss 20% of the PoW if they only downloaded headers.The concept of selfish mining of sync flags is introduced, where miners may selfishly mine flags and withhold them until the benefit gained from withholding is less than the mining reward. This practice could undermine decentralization, favoring only big miners capable of engaging in selfish mining. It may also encourage collusion among miners, resulting in flags being shipped only to miners with established business relationships, thereby reducing flag revenue and providing an advantage to in-group miners in main-chain mining.The idea of using a sync flag to ensure - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml b/static/bitcoin-dev/July_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml index 1370e6f4c1..e1f1051cff 100644 --- a/static/bitcoin-dev/July_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml +++ b/static/bitcoin-dev/July_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Status updates for BIP 9, 68, 112, and 113 - 2023-08-01T18:45:24.408771+00:00 + 2025-09-26T15:29:10.893300+00:00 + python-feedgen Btc Drak 2016-08-18 23:05:59+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Status updates for BIP 9, 68, 112, and 113 - 2023-08-01T18:45:24.408771+00:00 + 2025-09-26T15:29:10.893475+00:00 - Luke Dashjr, a Bitcoin Core developer, has announced his plans to update the status of BIPs 9, 68, 112, and 113 to Final in one month. Previously, there was confusion surrounding the classification of BIP 9, as it was unclear whether it fell under the Draft/Accepted/Final or Draft/Active classification. However, Dashjr believes that since BIPs 68, 112, and 113 have already been successfully deployed, BIP 9 should now be considered an informational BIP falling under the Draft/Accepted/Final class. In order to proceed with this update, Dashjr requires at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage.The discussion surrounding BIP 9 centers around its classification as just an "Informational" BIP, despite its importance in the consensus logic. Luke Jr. argues that BIP 9 is merely informational in advising how other BIPs should deploy themselves, making it a grey area. Wladimir J. van der Laan raises concerns over such an important deployment mechanism being classified solely as an informational BIP. However, none of the authors have commented on changing the type of BIP 9, even after a month of discussion. Thus, Luke asks if anyone objects to him updating BIP 9 to Final status.Dashjr suggests that BIP 9 should be reclassified as a "Standard BIP" rather than just an informational one, as it is included as part of the BIP 68 standard. He further explains that any modifications to BIP 9 would likely require a new BIP, and soft-forks utilizing the new standard would refer to the new BIP number. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be considered as part of the Draft/Accepted/Final classification. Additionally, he highlights that BIPs 68, 112, and 113 have already been successfully deployed to the network, satisfying the requirements for both Accepted and Final status. Consequently, Dashjr proposes that all four BIPs (BIPs 9, 68, 112, and 113) should be updated to Final status within one month.To proceed with this update, Dashjr needs at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage. Peter Todd, a developer at Bitcoin, has responded with an ACK in support of the "Final" status. The discussion regarding these updates can be found on the Github BIPs repository. However, it is recommended to continue the discussion via email.In summary, Luke Dashjr plans to update the status of BIPs 9, 68, 112, and 113 to Final within one month. There is a debate surrounding the classification of BIP 9, with Dashjr suggesting it should be considered a "Standard BIP" rather than just informational. He argues that BIP 9 is included as part of the BIP 68 standard and that any modifications would likely require a new BIP. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be classified under the Draft/Accepted/Final category. To proceed with the updates, Dashjr needs sign-offs from authors of each BIP. The discussion took place on the Github BIPs repository, but further communication is recommended via email. 2016-08-18T23:05:59+00:00 + Luke Dashjr, a Bitcoin Core developer, has announced his plans to update the status of BIPs 9, 68, 112, and 113 to Final in one month. Previously, there was confusion surrounding the classification of BIP 9, as it was unclear whether it fell under the Draft/Accepted/Final or Draft/Active classification. However, Dashjr believes that since BIPs 68, 112, and 113 have already been successfully deployed, BIP 9 should now be considered an informational BIP falling under the Draft/Accepted/Final class. In order to proceed with this update, Dashjr requires at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage.The discussion surrounding BIP 9 centers around its classification as just an "Informational" BIP, despite its importance in the consensus logic. Luke Jr. argues that BIP 9 is merely informational in advising how other BIPs should deploy themselves, making it a grey area. Wladimir J. van der Laan raises concerns over such an important deployment mechanism being classified solely as an informational BIP. However, none of the authors have commented on changing the type of BIP 9, even after a month of discussion. Thus, Luke asks if anyone objects to him updating BIP 9 to Final status.Dashjr suggests that BIP 9 should be reclassified as a "Standard BIP" rather than just an informational one, as it is included as part of the BIP 68 standard. He further explains that any modifications to BIP 9 would likely require a new BIP, and soft-forks utilizing the new standard would refer to the new BIP number. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be considered as part of the Draft/Accepted/Final classification. Additionally, he highlights that BIPs 68, 112, and 113 have already been successfully deployed to the network, satisfying the requirements for both Accepted and Final status. Consequently, Dashjr proposes that all four BIPs (BIPs 9, 68, 112, and 113) should be updated to Final status within one month.To proceed with this update, Dashjr needs at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage. Peter Todd, a developer at Bitcoin, has responded with an ACK in support of the "Final" status. The discussion regarding these updates can be found on the Github BIPs repository. However, it is recommended to continue the discussion via email.In summary, Luke Dashjr plans to update the status of BIPs 9, 68, 112, and 113 to Final within one month. There is a debate surrounding the classification of BIP 9, with Dashjr suggesting it should be considered a "Standard BIP" rather than just informational. He argues that BIP 9 is included as part of the BIP 68 standard and that any modifications would likely require a new BIP. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be classified under the Draft/Accepted/Final category. To proceed with the updates, Dashjr needs sign-offs from authors of each BIP. The discussion took place on the Github BIPs repository, but further communication is recommended via email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_-BIP-Proposal-Standard-address-format-for-timelocked-funds.xml b/static/bitcoin-dev/July_2017/combined_-BIP-Proposal-Standard-address-format-for-timelocked-funds.xml index 05412e3e09..6e85a76adf 100644 --- a/static/bitcoin-dev/July_2017/combined_-BIP-Proposal-Standard-address-format-for-timelocked-funds.xml +++ b/static/bitcoin-dev/July_2017/combined_-BIP-Proposal-Standard-address-format-for-timelocked-funds.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - [BIP Proposal] Standard address format for timelocked funds - 2023-08-01T21:18:30.867973+00:00 - - Federico Tenga 2017-07-27 16:52:52+00:00 - - - ZmnSCPxj 2017-07-12 08:30:31+00:00 - - - ZmnSCPxj 2017-07-08 01:13:01+00:00 - + 2025-09-26T15:30:22.816848+00:00 + python-feedgen + + + [bitcoin-dev] [BIP Proposal] Standard address format for timelocked funds ZmnSCPxj + 2017-07-08T01:13:00.000Z + + + ZmnSCPxj + 2017-07-12T08:30:00.000Z + + + Federico Tenga + 2017-07-27T16:52:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Standard address format for timelocked funds - 2023-08-01T21:18:30.867973+00:00 + 2025-09-26T15:30:22.817366+00:00 - Bitcoin developers have proposed a standard for timelocked funds that can be used across multiple Bitcoin wallet implementations. This proposal allows users to voluntarily lock their funds for a specified period of time and creates timelocked addresses redeemable at set dates each month. The proposal ensures that the redemption codes for these funds will still be usable even if the software or service is no longer available in the future.The proposed standard outlines formats for specifying an address that locks funds until a specified date and a redemption code that allows the funds to be swept on or after the specified date. Both addresses use the characters 'hodl' followed by a date in YYYYMMDD form, and a network code of either tb for testnet or bc for Bitcoin mainnet. The lock time is calculated based on the day before the lock date and the time 1000h of that date.To ensure backwards compatibility with wallets that do not support this proposal, a simple service can translate from a public timelocked address to a P2SH address. The proposal also recommends that wallets supporting payment to various Bitcoin address types should reuse the same interface for paying into timelocked addresses.The public address format starts with "hodl" while the private key (redemption code) uses "hedl". This provides a mnemonic for users: "Pay into the hodl code to hold your coins until the given date. After you've held the coins (on or after the given date) use the hedl code to redeem the coins." The misspelling of "hodl" is a homage to a common meme within the Bitcoin community.The proposal includes a version quintet in case of future changes that affect the interpretation of dates or scripting. It also offers three options for indicating the timezone: using the earliest timezone (UTC+14 0000h), using the standard timezone (UTC+0 0000h), or allowing users to indicate their local timezone. The bech32 separator digit of 1 can be used to compare different versions of a Bitcoin address.The BIP proposal aims to provide a standard address format for timelocked funds using the OP_CHECKLOCKTIMEVERIFY opcode. This will benefit long-term investors who want to lock their funds until a specific date. The proposal specifies formats for timelocked addresses and redemption codes, and provides instructions for providing funds to a timelocked address and sweeping a timelocked redemption code.The proposal outlines several expected use cases for timelocked funds, including waiting before cashing out, gifting Bitcoin to minors, providing monthly subsidies or allowances, and protecting against future duress or ransom. It also emphasizes the importance of having a shared standard for timelocked funds among multiple wallet implementations to ensure usability over time.Overall, this proposal offers a comprehensive approach to timelocked funds in Bitcoin, with detailed specifications for address formats, redemption codes, lock time computation, and backward compatibility. If implemented, this standard could provide valuable options for users looking to secure and manage their funds for specific periods of time. 2017-07-27T16:52:52+00:00 + Bitcoin developers have proposed a standard for timelocked funds that can be used across multiple Bitcoin wallet implementations. This proposal allows users to voluntarily lock their funds for a specified period of time and creates timelocked addresses redeemable at set dates each month. The proposal ensures that the redemption codes for these funds will still be usable even if the software or service is no longer available in the future.The proposed standard outlines formats for specifying an address that locks funds until a specified date and a redemption code that allows the funds to be swept on or after the specified date. Both addresses use the characters 'hodl' followed by a date in YYYYMMDD form, and a network code of either tb for testnet or bc for Bitcoin mainnet. The lock time is calculated based on the day before the lock date and the time 1000h of that date.To ensure backwards compatibility with wallets that do not support this proposal, a simple service can translate from a public timelocked address to a P2SH address. The proposal also recommends that wallets supporting payment to various Bitcoin address types should reuse the same interface for paying into timelocked addresses.The public address format starts with "hodl" while the private key (redemption code) uses "hedl". This provides a mnemonic for users: "Pay into the hodl code to hold your coins until the given date. After you've held the coins (on or after the given date) use the hedl code to redeem the coins." The misspelling of "hodl" is a homage to a common meme within the Bitcoin community.The proposal includes a version quintet in case of future changes that affect the interpretation of dates or scripting. It also offers three options for indicating the timezone: using the earliest timezone (UTC+14 0000h), using the standard timezone (UTC+0 0000h), or allowing users to indicate their local timezone. The bech32 separator digit of 1 can be used to compare different versions of a Bitcoin address.The BIP proposal aims to provide a standard address format for timelocked funds using the OP_CHECKLOCKTIMEVERIFY opcode. This will benefit long-term investors who want to lock their funds until a specific date. The proposal specifies formats for timelocked addresses and redemption codes, and provides instructions for providing funds to a timelocked address and sweeping a timelocked redemption code.The proposal outlines several expected use cases for timelocked funds, including waiting before cashing out, gifting Bitcoin to minors, providing monthly subsidies or allowances, and protecting against future duress or ransom. It also emphasizes the importance of having a shared standard for timelocked funds among multiple wallet implementations to ensure usability over time.Overall, this proposal offers a comprehensive approach to timelocked funds in Bitcoin, with detailed specifications for address formats, redemption codes, lock time computation, and backward compatibility. If implemented, this standard could provide valuable options for users looking to secure and manage their funds for specific periods of time. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_A-BIP-proposal-for-conveniently-referring-to-confirmed-transactions.xml b/static/bitcoin-dev/July_2017/combined_A-BIP-proposal-for-conveniently-referring-to-confirmed-transactions.xml index 25e573caca..411b17800c 100644 --- a/static/bitcoin-dev/July_2017/combined_A-BIP-proposal-for-conveniently-referring-to-confirmed-transactions.xml +++ b/static/bitcoin-dev/July_2017/combined_A-BIP-proposal-for-conveniently-referring-to-confirmed-transactions.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - A BIP proposal for conveniently referring to confirmed transactions - 2023-08-01T20:44:09.769883+00:00 - - Tom Zander 2017-07-17 13:40:29+00:00 - - - Велеслав 2017-07-15 05:00:18+00:00 - - - Clark Moody 2017-07-14 18:43:37+00:00 - - - Велеслав 2017-05-23 15:30:58+00:00 - + 2025-09-26T15:30:27.026066+00:00 + python-feedgen + + + [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions Велеслав + 2017-05-23T15:30:00.000Z + + + Clark Moody + 2017-07-14T18:43:00.000Z + + + Велеслав + 2017-07-15T05:00:00.000Z + + + Tom Zander + 2017-07-17T13:40:00.000Z + + - python-feedgen + 2 Combined summary - A BIP proposal for conveniently referring to confirmed transactions - 2023-08-01T20:44:09.769883+00:00 + 2025-09-26T15:30:27.026752+00:00 - In a bitcoin-dev discussion, Clark Moody expressed understanding for keeping all reference strings to the 14-character version by keeping the data payload to 40 bits. However, he questioned the point of having a user-readable tx-reference. He argued that in the actual blockchain, the txid would still be used and a less readable but more compact format is useful because space optimization is prioritized over human comprehension. Moody suggested that one possible use case could be wanting to spend a specific output or reporting a specific transaction as proof to a merchant or tax office. However, for any such use cases, an individual would still need to provide a proof of holding the private keys. Therefore, using a human-readable format does not make much sense since a cryptographic proof of ownership cannot be read no matter how hard one tries.Tom Zander asked for one or two use cases where human-readable formats might be useful. The message is a response to a review of a proposal by Clark Moody. The proposal involves conveniently referring to confirmed transactions. The pull request can be found at https://github.com/bitcoin/bips/pull/555 while the proposed specification is at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Position_References.mediawiki.The author of the message notes that various variable length encodings were considered and found to have too high an overhead. Instead, the concept of "Display Formats" was proposed. These formats are tailored to specific purposes and can be optimized to a much greater extent. In case there is a hard fork extending Bitcoin's block transaction capacity beyond 8191 transactions, a "Bitcoin Display Format 1" will be defined. In case of a Drive-Chain style extension or other indirect extension to Bitcoin's transactional capacity, a new magic value will be created to define a tailored Display Format for the new system. The author believes that it makes no sense to define an undefined format now. A new format can be defined in the future when the needs of Bitcoin users can be better understood.Clark Moody suggests that the proposal places artificial limitations on the format. The author responds that a variable-length encoding similar to Bitcoin's variable ints could be used. Bit-packing to the 40 bits might also be overkill as one bit-packed byte could suffice. The protocol version would occupy the first two bits, supporting values 0-3.In a GitHub discussion, users expressed concern over the limitations of the current format for reference strings. The 14-character version is desirable, but it restricts the data payload to 40 bits, limiting the format to year 2048 and 8191 transactions. While Version 1 encoding may address this issue, current blocks are still approaching the transaction limit.A suggestion was made to use variable-length encoding similar to Bitcoin's variable ints, which would allow for a format that can handle very large blocks and future growth. Additionally, it was noted that Bech32 reference libraries can encode from byte arrays into the base-5 arrays native to Bech32, making bit-packing to the 40 bits unnecessary. Instead, one bit-packed byte could be used to start, with the first two bits indicating the protocol version (0-3). Overall, there are concerns about the artificial limitations of the current format and potential solutions to address them.The author has proposed a BIP that suggests a way to reference transactions that have been successfully inserted into the blockchain. The format of the proposal utilizes Bech32 encoding and is designed to be both short and useful for human usage. The draft also includes a C reference implementation. The author has taken special care to ensure that this BIP can be extended naturally to support future upgrades to Bitcoin, Bitcoin Sidechains, or even other blockchain projects. However, the current draft only specifies support for the Bitcoin Main Chain and the Test Network. The author hopes that the bitcoin-development mailing list participants find this draft BIP interesting and useful. The BIP can be read in full at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Postion_References.mediawiki. If assigned with a BIP number, some small updates to the specification will be made in accommodation. 2017-07-17T13:40:29+00:00 + In a bitcoin-dev discussion, Clark Moody expressed understanding for keeping all reference strings to the 14-character version by keeping the data payload to 40 bits. However, he questioned the point of having a user-readable tx-reference. He argued that in the actual blockchain, the txid would still be used and a less readable but more compact format is useful because space optimization is prioritized over human comprehension. Moody suggested that one possible use case could be wanting to spend a specific output or reporting a specific transaction as proof to a merchant or tax office. However, for any such use cases, an individual would still need to provide a proof of holding the private keys. Therefore, using a human-readable format does not make much sense since a cryptographic proof of ownership cannot be read no matter how hard one tries.Tom Zander asked for one or two use cases where human-readable formats might be useful. The message is a response to a review of a proposal by Clark Moody. The proposal involves conveniently referring to confirmed transactions. The pull request can be found at https://github.com/bitcoin/bips/pull/555 while the proposed specification is at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Position_References.mediawiki.The author of the message notes that various variable length encodings were considered and found to have too high an overhead. Instead, the concept of "Display Formats" was proposed. These formats are tailored to specific purposes and can be optimized to a much greater extent. In case there is a hard fork extending Bitcoin's block transaction capacity beyond 8191 transactions, a "Bitcoin Display Format 1" will be defined. In case of a Drive-Chain style extension or other indirect extension to Bitcoin's transactional capacity, a new magic value will be created to define a tailored Display Format for the new system. The author believes that it makes no sense to define an undefined format now. A new format can be defined in the future when the needs of Bitcoin users can be better understood.Clark Moody suggests that the proposal places artificial limitations on the format. The author responds that a variable-length encoding similar to Bitcoin's variable ints could be used. Bit-packing to the 40 bits might also be overkill as one bit-packed byte could suffice. The protocol version would occupy the first two bits, supporting values 0-3.In a GitHub discussion, users expressed concern over the limitations of the current format for reference strings. The 14-character version is desirable, but it restricts the data payload to 40 bits, limiting the format to year 2048 and 8191 transactions. While Version 1 encoding may address this issue, current blocks are still approaching the transaction limit.A suggestion was made to use variable-length encoding similar to Bitcoin's variable ints, which would allow for a format that can handle very large blocks and future growth. Additionally, it was noted that Bech32 reference libraries can encode from byte arrays into the base-5 arrays native to Bech32, making bit-packing to the 40 bits unnecessary. Instead, one bit-packed byte could be used to start, with the first two bits indicating the protocol version (0-3). Overall, there are concerns about the artificial limitations of the current format and potential solutions to address them.The author has proposed a BIP that suggests a way to reference transactions that have been successfully inserted into the blockchain. The format of the proposal utilizes Bech32 encoding and is designed to be both short and useful for human usage. The draft also includes a C reference implementation. The author has taken special care to ensure that this BIP can be extended naturally to support future upgrades to Bitcoin, Bitcoin Sidechains, or even other blockchain projects. However, the current draft only specifies support for the Bitcoin Main Chain and the Test Network. The author hopes that the bitcoin-development mailing list participants find this draft BIP interesting and useful. The BIP can be read in full at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Postion_References.mediawiki. If assigned with a BIP number, some small updates to the specification will be made in accommodation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_A-Segwit2x-BIP.xml b/static/bitcoin-dev/July_2017/combined_A-Segwit2x-BIP.xml index 43893b861c..015770df58 100644 --- a/static/bitcoin-dev/July_2017/combined_A-Segwit2x-BIP.xml +++ b/static/bitcoin-dev/July_2017/combined_A-Segwit2x-BIP.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - A Segwit2x BIP - 2023-08-01T21:18:05.782681+00:00 - - Erik Aronesty 2017-07-14 13:50:14+00:00 - - - Charlie 'Charles' Shrem 2017-07-13 21:18:58+00:00 - - - Andrew Chow 2017-07-13 19:48:52+00:00 - - - Sergio Demian Lerner 2017-07-13 19:19:35+00:00 - - - Sergio Demian Lerner 2017-07-13 03:19:28+00:00 - - - Sergio Demian Lerner 2017-07-13 03:10:55+00:00 - - - Jorge Timón 2017-07-12 17:38:58+00:00 - - - Aymeric Vitte 2017-07-12 15:41:15+00:00 - - - Jonas Schnelli 2017-07-12 12:38:33+00:00 - - - Tom Zander 2017-07-12 08:15:50+00:00 - - - Luke Dashjr 2017-07-12 01:06:14+00:00 - - - Jorge Timón 2017-07-10 18:38:08+00:00 - - - Sergio Demian Lerner 2017-07-10 11:50:33+00:00 - - - Btc Drak 2017-07-08 13:28:11+00:00 - - - Erik Aronesty 2017-07-08 06:30:03+00:00 - - - Gregory Maxwell 2017-07-07 23:38:06+00:00 - - - Luke Dashjr 2017-07-07 23:27:14+00:00 - - - Gregory Maxwell 2017-07-07 23:25:32+00:00 - - - Gregory Maxwell 2017-07-07 23:22:38+00:00 - - - Matt Corallo 2017-07-07 22:44:21+00:00 - - - Sergio Demian Lerner 2017-07-07 22:25:12+00:00 - + 2025-09-26T15:30:31.248573+00:00 + python-feedgen + + + [bitcoin-dev] A Segwit2x BIP Sergio Demian Lerner + 2017-07-07T22:25:00.000Z + + + Matt Corallo + 2017-07-07T22:44:00.000Z + + + Gregory Maxwell + 2017-07-07T23:22:00.000Z + + + Gregory Maxwell + 2017-07-07T23:25:00.000Z + + + Luke Dashjr + 2017-07-07T23:27:00.000Z + + + Gregory Maxwell + 2017-07-07T23:38:00.000Z + + + Erik Aronesty + 2017-07-08T06:30:00.000Z + + + Btc Drak + 2017-07-08T13:28:00.000Z + + + Sergio Demian Lerner + 2017-07-10T11:50:00.000Z + + + Jorge Timón + 2017-07-10T18:38:00.000Z + + + Luke Dashjr + 2017-07-12T01:06:00.000Z + + + Tom Zander + 2017-07-12T08:15:00.000Z + + + Jonas Schnelli + 2017-07-12T12:38:00.000Z + + + Aymeric Vitte + 2017-07-12T15:41:00.000Z + + + Jorge Timón + 2017-07-12T17:38:00.000Z + + + Sergio Demian Lerner + 2017-07-13T03:10:00.000Z + + + Sergio Demian Lerner + 2017-07-13T03:19:00.000Z + + + Sergio Demian Lerner + 2017-07-13T19:19:00.000Z + + + Andrew Chow + 2017-07-13T19:48:00.000Z + + + Charlie 'Charles' Shrem + 2017-07-13T21:18:00.000Z + + + Erik Aronesty + 2017-07-14T13:50:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - A Segwit2x BIP - 2023-08-01T21:18:05.783681+00:00 + 2025-09-26T15:30:31.250788+00:00 - Recently in the Bitcoin community, concerns have been raised about the urgency of a consensus change and the reasons for not delaying it until a better-engineered solution can be deployed. Sergio Demian Lerner from the bitcoin-dev team has updated the technical specifications of the Bitcoin Improvement Proposal (BIP), specifying the block size increase in terms of weight and documenting the maximum block sigops after the hard fork. He urges users to start signaling something before block 475776. There is a discussion on the mailing list about the code to support the hard fork, with some members claiming it has been tested for much longer than a year, while others argue that it has not been properly tested yet.Block 475776 is mentioned as an important milestone before August 1st, and Sergio Demian Lerner emphasizes the need to start signaling before this block. The email exchange also includes a debate between Jorge Timón and Tom Zander about the testing of the code to support the hard fork. Timón believes that any hard fork should wait at least a year after the release of tested code, while Zander claims that the code has been tested for much longer than that. However, Zander clarifies that the code is different on top of segwit and that the first attempt did not even increase the size.The discussion also touches on the issue of the N² hashing problem and proposes soft-forking solutions to address it. The suggested maximum transaction size limit is not considered ideal but is seen as a good starting point. A worst-case scenario for block size is mentioned, and the blame is placed on the Segwit discount factor. The proposed solution is to remove the discount factor altogether and add a fixed discount for each input with respect to outputs. The email thread also mentions the need to redefine the signal "segsignal" in the modified BIP91 proposal.Another email exchange focuses on the responsibility of implementing a hard fork without sufficient testing. Jorge Timón argues that any hard fork should wait at least a year after the release of tested code, while Tom Zander claims that the code to support the hard fork has been tested for much longer than that. However, Zander admits that the code is different on top of segwit and has not been properly tested yet.Luke Dashjr expresses his belief that a hard fork attempt for Bitcoin would fail even with Core's support. He questions the accuracy of claims that more than 80% of miners and users are willing to go in the Segwit2x direction. Dashjr also discusses the issue of a temporary split without Core and expresses his disagreement with Sergio Demian Lerner's approach. He suggests that the only way to achieve a united Bitcoin today would be through Segwit+Drivechain, not Segwit+Hardfork.There is also discussion about the proposed Bitcoin Improvement Proposal (BIP) that matches the reference code published by the Segwit2x group. The timeline and political aspects of the proposal are debated, including concerns about hard forks requiring consensus from the entire ecosystem and the potential for confusion, harm, and fund loss. The email thread includes opposition to the proposal due to its short timeline and lack of detail. Strong opposition is expressed towards the draft proposal for a Bitcoin hard fork, citing concerns about technical, ethical, and process-related issues. The rushed timeline, lack of consensus, and insufficient detail in the draft BIP are criticized. The author suggests that coercion has been used behind closed doors to gain support for the proposal and believes the best outcome is for it to be ignored.In summary, there are ongoing discussions in the Bitcoin community regarding the urgency of a consensus change and the need for proper testing before implementing a hard fork. There are debates about the code to support the hard fork, the responsible timeline for a hard fork, and the potential risks and consequences of such a fork. The email exchanges also touch on issues related to the N² hashing problem and propose solutions to address it. Overall, there are differing opinions and concerns within the community regarding the proposed changes.Luke Dashjr, a Bitcoin developer, believes that larger block sizes will not have a significant impact on fee pressure. However, another individual disagrees, stating that larger block sizes will affect fees in the short term. The maximum transaction size has been increased by approximately 81 bytes, allowing for nearly four MB transactions with Segwit transactions not counting witness data. A modified BIP91 is being deployed to activate Segwit, replacing 'segsignal' with 'segwit2x.' If segwit2x activates at block N, then block N+12960 will activate a new weight limit of 8M. Any transaction with a non-witness serialized size exceeding 1,000,000 is considered invalid.Matt Corallo clarifies via email that adding a new limit is a soft fork and not a hard fork. He also points out that the btc1 branch code was adjusted at the last minute to increase block size, but there are no tests implemented for 2017-07-14T13:50:14+00:00 + Recently in the Bitcoin community, concerns have been raised about the urgency of a consensus change and the reasons for not delaying it until a better-engineered solution can be deployed. Sergio Demian Lerner from the bitcoin-dev team has updated the technical specifications of the Bitcoin Improvement Proposal (BIP), specifying the block size increase in terms of weight and documenting the maximum block sigops after the hard fork. He urges users to start signaling something before block 475776. There is a discussion on the mailing list about the code to support the hard fork, with some members claiming it has been tested for much longer than a year, while others argue that it has not been properly tested yet.Block 475776 is mentioned as an important milestone before August 1st, and Sergio Demian Lerner emphasizes the need to start signaling before this block. The email exchange also includes a debate between Jorge Timón and Tom Zander about the testing of the code to support the hard fork. Timón believes that any hard fork should wait at least a year after the release of tested code, while Zander claims that the code has been tested for much longer than that. However, Zander clarifies that the code is different on top of segwit and that the first attempt did not even increase the size.The discussion also touches on the issue of the N² hashing problem and proposes soft-forking solutions to address it. The suggested maximum transaction size limit is not considered ideal but is seen as a good starting point. A worst-case scenario for block size is mentioned, and the blame is placed on the Segwit discount factor. The proposed solution is to remove the discount factor altogether and add a fixed discount for each input with respect to outputs. The email thread also mentions the need to redefine the signal "segsignal" in the modified BIP91 proposal.Another email exchange focuses on the responsibility of implementing a hard fork without sufficient testing. Jorge Timón argues that any hard fork should wait at least a year after the release of tested code, while Tom Zander claims that the code to support the hard fork has been tested for much longer than that. However, Zander admits that the code is different on top of segwit and has not been properly tested yet.Luke Dashjr expresses his belief that a hard fork attempt for Bitcoin would fail even with Core's support. He questions the accuracy of claims that more than 80% of miners and users are willing to go in the Segwit2x direction. Dashjr also discusses the issue of a temporary split without Core and expresses his disagreement with Sergio Demian Lerner's approach. He suggests that the only way to achieve a united Bitcoin today would be through Segwit+Drivechain, not Segwit+Hardfork.There is also discussion about the proposed Bitcoin Improvement Proposal (BIP) that matches the reference code published by the Segwit2x group. The timeline and political aspects of the proposal are debated, including concerns about hard forks requiring consensus from the entire ecosystem and the potential for confusion, harm, and fund loss. The email thread includes opposition to the proposal due to its short timeline and lack of detail. Strong opposition is expressed towards the draft proposal for a Bitcoin hard fork, citing concerns about technical, ethical, and process-related issues. The rushed timeline, lack of consensus, and insufficient detail in the draft BIP are criticized. The author suggests that coercion has been used behind closed doors to gain support for the proposal and believes the best outcome is for it to be ignored.In summary, there are ongoing discussions in the Bitcoin community regarding the urgency of a consensus change and the need for proper testing before implementing a hard fork. There are debates about the code to support the hard fork, the responsible timeline for a hard fork, and the potential risks and consequences of such a fork. The email exchanges also touch on issues related to the N² hashing problem and propose solutions to address it. Overall, there are differing opinions and concerns within the community regarding the proposed changes.Luke Dashjr, a Bitcoin developer, believes that larger block sizes will not have a significant impact on fee pressure. However, another individual disagrees, stating that larger block sizes will affect fees in the short term. The maximum transaction size has been increased by approximately 81 bytes, allowing for nearly four MB transactions with Segwit transactions not counting witness data. A modified BIP91 is being deployed to activate Segwit, replacing 'segsignal' with 'segwit2x.' If segwit2x activates at block N, then block N+12960 will activate a new weight limit of 8M. Any transaction with a non-witness serialized size exceeding 1,000,000 is considered invalid.Matt Corallo clarifies via email that adding a new limit is a soft fork and not a hard fork. He also points out that the btc1 branch code was adjusted at the last minute to increase block size, but there are no tests implemented for - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_BIP-OP-BRIBVERIFY-the-op-code-needed-for-Blind-Merge-Mined-drivechains.xml b/static/bitcoin-dev/July_2017/combined_BIP-OP-BRIBVERIFY-the-op-code-needed-for-Blind-Merge-Mined-drivechains.xml index a62f448702..ef16b56cf6 100644 --- a/static/bitcoin-dev/July_2017/combined_BIP-OP-BRIBVERIFY-the-op-code-needed-for-Blind-Merge-Mined-drivechains.xml +++ b/static/bitcoin-dev/July_2017/combined_BIP-OP-BRIBVERIFY-the-op-code-needed-for-Blind-Merge-Mined-drivechains.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains - 2023-08-01T21:12:55.577190+00:00 - - Paul Sztorc 2017-07-13 20:45:13+00:00 - - - Chris Stewart 2017-07-13 20:22:02+00:00 - - - Paul Sztorc 2017-07-13 00:00:29+00:00 - - - CryptAxe 2017-07-12 23:58:07+00:00 - - - Paul Sztorc 2017-07-12 23:31:18+00:00 - - - Chris Stewart 2017-07-12 18:02:30+00:00 - - - Russell O'Connor 2017-07-12 13:39:17+00:00 - - - ZmnSCPxj 2017-07-12 08:50:52+00:00 - - - Chris Stewart 2017-07-04 15:06:06+00:00 - - - ZmnSCPxj 2017-07-04 07:21:23+00:00 - - - Paul Sztorc 2017-07-02 21:32:50+00:00 - - - CryptAxe 2017-06-30 16:51:34+00:00 - - - Chris Stewart 2017-06-30 14:12:30+00:00 - - - ZmnSCPxj 2017-06-30 04:00:27+00:00 - - - Russell O'Connor 2017-06-29 01:09:27+00:00 - - - Chris Stewart 2017-06-28 23:47:57+00:00 - - - Russell O'Connor 2017-06-28 22:49:54+00:00 - - - Paul Sztorc 2017-06-28 22:20:35+00:00 - - - Paul Sztorc 2017-06-28 16:43:22+00:00 - - - Paul Sztorc 2017-06-28 16:35:32+00:00 - - - ZmnSCPxj 2017-06-28 08:26:37+00:00 - - - Adam Back 2017-06-28 05:28:31+00:00 - - - Luke Dashjr 2017-06-28 05:20:27+00:00 - - - Gregory Maxwell 2017-06-28 04:07:43+00:00 - - - Chris Stewart 2017-06-28 00:37:13+00:00 - + 2025-09-26T15:30:46.022077+00:00 + python-feedgen + + + [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains Chris Stewart + 2017-06-28T00:37:00.000Z + + + Gregory Maxwell + 2017-06-28T04:07:00.000Z + + + Luke Dashjr + 2017-06-28T05:20:00.000Z + + + Adam Back + 2017-06-28T05:28:00.000Z + + + ZmnSCPxj + 2017-06-28T08:26:00.000Z + + + Paul Sztorc + 2017-06-28T16:35:00.000Z + + + Paul Sztorc + 2017-06-28T16:43:00.000Z + + + Paul Sztorc + 2017-06-28T22:20:00.000Z + + + Russell O'Connor + 2017-06-28T22:49:00.000Z + + + Chris Stewart + 2017-06-28T23:47:00.000Z + + + Russell O'Connor + 2017-06-29T01:09:00.000Z + + + ZmnSCPxj + 2017-06-30T04:00:00.000Z + + + Chris Stewart + 2017-06-30T14:12:00.000Z + + + CryptAxe + 2017-06-30T16:51:00.000Z + + + Paul Sztorc + 2017-07-02T21:32:00.000Z + + + ZmnSCPxj + 2017-07-04T07:21:00.000Z + + + Chris Stewart + 2017-07-04T15:06:00.000Z + + + ZmnSCPxj + 2017-07-12T08:50:00.000Z + + + Russell O'Connor + 2017-07-12T13:39:00.000Z + + + Chris Stewart + 2017-07-12T18:02:00.000Z + + + Paul Sztorc + 2017-07-12T23:31:00.000Z + + + CryptAxe + 2017-07-12T23:58:00.000Z + + + Paul Sztorc + 2017-07-13T00:00:00.000Z + + + Chris Stewart + 2017-07-13T20:22:00.000Z + + + Paul Sztorc + 2017-07-13T20:45:00.000Z + + @@ -103,13 +131,13 @@ - python-feedgen + 2 Combined summary - BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains - 2023-08-01T21:12:55.578190+00:00 + 2025-09-26T15:30:46.024629+00:00 - In a Bitcoin development mailing list conversation, Chris Stewart asked for clarification on the purpose of 'Ratchet' in BMM (blind merge mining). Paul explained that BMM aims to validate sidechains with minimal validation on the mainchain. They introduced a new rule that requires h* to be accompanied by the modulus of its sidechain block number (BlockMod) to ensure accurate validation. The mainchain also has a rule that restricts the new BlockMod to a specific range relative to the old BlockMod. Additionally, BMM implemented a rule that prevents payment of bribes unless the sidechain block has been buried by a certain number of sidechain blocks to prevent orphaning.The discussion continued with Chris seeking opinions on Lightning bribes. Paul argued that in equilibrium, the coinbase version may be more efficient than the OP_RETURN version. A miner can redeem an OP Bribe through the Lightning Network. Sidechains running in SPV mode know where to find the necessary information to discover the longest chain. However, the OP_RETURN version requires a spend in the UTXO set and additional data storage.The conversation then shifted to the efficiency of Bitcoin in equilibrium, including Lightning Network or similar solutions. Two versions of sidechains were discussed: coinbase and OP_RETURN. The coinbase version involves a single event per N, with hash commitments and ratchet's block counter instances per block. The OP Bribe can be negotiated through the Lightning Network. In the OP_RETURN version, there are also hash commitments per block, but it requires a spend in the UTXO set and extra data storage to locate the necessary information.The email thread also included discussions on the implementation of sidechains and blind merge mining. The sender argued that a block list node is valid only if its block is valid, which seemed to contradict the "blind" aspect of blind merge mining. However, they explained their scheme, which includes storing sidechain block headers on the mainchain using OP_RETURN data. The sidechain block headers are reduced to only the previous-block-header commitment and the current-block-data commitment. If the current-block-data is invalid, another sidechain block header based on the previous block header will be searched for.Another topic discussed was the issue of replaceability of bribe transactions. Several proposals were made, including having the amount in the output instead of the fee and replacing the bribe transaction with a double spend transaction. There were also suggestions to remove the necessity of coinbase commitments and use a special OP_RETURN output or include the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The conversation also touched upon blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIBEVERIFY proposal by removing the necessity of coinbase commitments and using the hash of the sidechain's name or genesis block to identify them instead of numbering them. It was suggested that miners could maximize their fee income by imposing a blocksize limit on themselves and orphaning non-compliant blocks.In another discussion, the sender proposed improvements to the OP_BRIBEVERIFY proposal. They suggested removing the need for coinbase commitments and having the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY. Another improvement was to keep a set of sidechain IDs when verifying a block and fail the script processing if an OP_BRIBEVERIFY already exists for that specific sidechain ID. There was also a suggestion to eliminate the use of scripting altogether and use a special non-standard OP_RETURN output to hold the sidechain ID and h*. A soft fork rule could be implemented to limit this output to one per block per sidechain ID.The email thread discussed the challenges of blind merge mining and ensuring the validity of sidechain blocks. The sender argued that a block list node is only valid if its block is valid, which seemed contradictory to the blind merge mining concept. However, they explained their scheme, which involves storing the OP_RETURN data representing sidechain block headers on the mainchain. The sender also proposed the use of a ratchet system to link h* data from bribes to sidechain blocks.In a conversation between Chris Stewart, Russell O'Connor, and ZmnSCPxj, they discussed the issue of replaceability of bribe transactions. They proposed different solutions, such as having the amount in the output instead of the fee or using a double spend transaction to replace the bribe. They also discussed the issue of coinbase commitments and searching for drivechain commitments in the Bitcoin blockchain. Suggestions were made to remove the necessity of coinbase commitments and have the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The discussion also covered blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIB 2017-07-13T20:45:13+00:00 + In a Bitcoin development mailing list conversation, Chris Stewart asked for clarification on the purpose of 'Ratchet' in BMM (blind merge mining). Paul explained that BMM aims to validate sidechains with minimal validation on the mainchain. They introduced a new rule that requires h* to be accompanied by the modulus of its sidechain block number (BlockMod) to ensure accurate validation. The mainchain also has a rule that restricts the new BlockMod to a specific range relative to the old BlockMod. Additionally, BMM implemented a rule that prevents payment of bribes unless the sidechain block has been buried by a certain number of sidechain blocks to prevent orphaning.The discussion continued with Chris seeking opinions on Lightning bribes. Paul argued that in equilibrium, the coinbase version may be more efficient than the OP_RETURN version. A miner can redeem an OP Bribe through the Lightning Network. Sidechains running in SPV mode know where to find the necessary information to discover the longest chain. However, the OP_RETURN version requires a spend in the UTXO set and additional data storage.The conversation then shifted to the efficiency of Bitcoin in equilibrium, including Lightning Network or similar solutions. Two versions of sidechains were discussed: coinbase and OP_RETURN. The coinbase version involves a single event per N, with hash commitments and ratchet's block counter instances per block. The OP Bribe can be negotiated through the Lightning Network. In the OP_RETURN version, there are also hash commitments per block, but it requires a spend in the UTXO set and extra data storage to locate the necessary information.The email thread also included discussions on the implementation of sidechains and blind merge mining. The sender argued that a block list node is valid only if its block is valid, which seemed to contradict the "blind" aspect of blind merge mining. However, they explained their scheme, which includes storing sidechain block headers on the mainchain using OP_RETURN data. The sidechain block headers are reduced to only the previous-block-header commitment and the current-block-data commitment. If the current-block-data is invalid, another sidechain block header based on the previous block header will be searched for.Another topic discussed was the issue of replaceability of bribe transactions. Several proposals were made, including having the amount in the output instead of the fee and replacing the bribe transaction with a double spend transaction. There were also suggestions to remove the necessity of coinbase commitments and use a special OP_RETURN output or include the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The conversation also touched upon blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIBEVERIFY proposal by removing the necessity of coinbase commitments and using the hash of the sidechain's name or genesis block to identify them instead of numbering them. It was suggested that miners could maximize their fee income by imposing a blocksize limit on themselves and orphaning non-compliant blocks.In another discussion, the sender proposed improvements to the OP_BRIBEVERIFY proposal. They suggested removing the need for coinbase commitments and having the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY. Another improvement was to keep a set of sidechain IDs when verifying a block and fail the script processing if an OP_BRIBEVERIFY already exists for that specific sidechain ID. There was also a suggestion to eliminate the use of scripting altogether and use a special non-standard OP_RETURN output to hold the sidechain ID and h*. A soft fork rule could be implemented to limit this output to one per block per sidechain ID.The email thread discussed the challenges of blind merge mining and ensuring the validity of sidechain blocks. The sender argued that a block list node is only valid if its block is valid, which seemed contradictory to the blind merge mining concept. However, they explained their scheme, which involves storing the OP_RETURN data representing sidechain block headers on the mainchain. The sender also proposed the use of a ratchet system to link h* data from bribes to sidechain blocks.In a conversation between Chris Stewart, Russell O'Connor, and ZmnSCPxj, they discussed the issue of replaceability of bribe transactions. They proposed different solutions, such as having the amount in the output instead of the fee or using a double spend transaction to replace the bribe. They also discussed the issue of coinbase commitments and searching for drivechain commitments in the Bitcoin blockchain. Suggestions were made to remove the necessity of coinbase commitments and have the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The discussion also covered blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIB - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_BIP-proposal-No-chaining-off-replaceable-transactions.xml b/static/bitcoin-dev/July_2017/combined_BIP-proposal-No-chaining-off-replaceable-transactions.xml index ffe5b29109..e486a66637 100644 --- a/static/bitcoin-dev/July_2017/combined_BIP-proposal-No-chaining-off-replaceable-transactions.xml +++ b/static/bitcoin-dev/July_2017/combined_BIP-proposal-No-chaining-off-replaceable-transactions.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - BIP proposal: No chaining off replaceable transactions - 2023-08-01T21:15:13.951172+00:00 - - Rhavar 2017-07-05 13:52:53+00:00 - - - Andreas Schildbach 2017-07-04 11:50:30+00:00 - - - Rhavar 2017-07-03 16:25:33+00:00 - - - James Hilliard 2017-07-03 04:17:08+00:00 - - - Rhavar 2017-07-03 03:02:44+00:00 - - - Gregory Maxwell 2017-07-03 02:28:34+00:00 - - - Luke Dashjr 2017-07-02 21:10:19+00:00 - - - Rhavar 2017-07-02 21:01:19+00:00 - - - Gregory Maxwell 2017-07-02 20:56:07+00:00 - - - Rhavar 2017-07-02 20:35:22+00:00 - + 2025-09-26T15:30:43.897385+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: No chaining off replaceable transactions Rhavar + 2017-07-02T20:35:00.000Z + + + Gregory Maxwell + 2017-07-02T20:56:00.000Z + + + Rhavar + 2017-07-02T21:01:00.000Z + + + Luke Dashjr + 2017-07-02T21:10:00.000Z + + + Gregory Maxwell + 2017-07-03T02:28:00.000Z + + + Rhavar + 2017-07-03T03:02:00.000Z + + + James Hilliard + 2017-07-03T04:17:00.000Z + + + Rhavar + 2017-07-03T16:25:00.000Z + + + Andreas Schildbach + 2017-07-04T11:50:00.000Z + + + Rhavar + 2017-07-05T13:52:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: No chaining off replaceable transactions - 2023-08-01T21:15:13.951172+00:00 + 2025-09-26T15:30:43.898602+00:00 - The email thread discusses a proposal for BIP125 transactions, which allow users to increase fees of unconfirmed transactions. However, the issue arises when the receiver spends from the unconfirmed output, exposing the sender to potential high costs or no fee bump at all. This is especially problematic for batched sends with multiple receivers. To address this, the proposal suggests making transactions that spend an unconfirmed BIP125 output non-standard by specifying a max chain depth of 1. This means receivers will need to wait until the transaction confirms before spending from it.Rhavar has proposed a BIP to prevent the chaining off of replaceable transactions, aiming to simplify fee bump logic and make fee bumps more predictable. Some critics argue that the proposal is paternalistic and contrary to miner income. Rhavar counters this by stating that the proposal is no more paternalistic than non-BIP125 transactions and that miners opting into the policy would actually make more money. He believes the proposal would create a more stable fee market with little to no disadvantages. Rhavar also asks if anyone can think of a legitimate use case for spending unconfirmed BIP125 transactions.A proposal to modify the RBF eviction policy was suggested in a bitcoin-dev discussion. The change would allow for feerate separation between transactions in the mempool and better management of replacements. The discussion also touches on the BIP125 rules and the challenges of low-fee sweeps. The proposal aims to create a stable fee market and help services increase fees sanely when dealing with withdrawals.The email conversation highlights the problems faced by low-fee transactions, particularly when wanting to replace them with higher fee transactions. The cost of invalidating descendant transactions can be significant. The proposal suggests allowing users to dynamically increase their fees when dealing with withdrawals to avoid such issues and promote a stable fee market.A discussion between Rhavar and another individual focuses on replacing unconfirmed transactions. Rhavar mentions the cost of replacing a transaction that includes unconfirmed inputs, which can be expensive. The other person suggests that if the receiver pays a higher feerate, their transaction will get confirmed faster than the sender's replacement.Overall, the proposal for BIP125 aims to increase the efficiency of the fee marketplace by allowing users to increase fees of unconfirmed transactions. However, there are concerns and alternative suggestions regarding the practicality and impact of the proposal. 2017-07-05T13:52:53+00:00 + The email thread discusses a proposal for BIP125 transactions, which allow users to increase fees of unconfirmed transactions. However, the issue arises when the receiver spends from the unconfirmed output, exposing the sender to potential high costs or no fee bump at all. This is especially problematic for batched sends with multiple receivers. To address this, the proposal suggests making transactions that spend an unconfirmed BIP125 output non-standard by specifying a max chain depth of 1. This means receivers will need to wait until the transaction confirms before spending from it.Rhavar has proposed a BIP to prevent the chaining off of replaceable transactions, aiming to simplify fee bump logic and make fee bumps more predictable. Some critics argue that the proposal is paternalistic and contrary to miner income. Rhavar counters this by stating that the proposal is no more paternalistic than non-BIP125 transactions and that miners opting into the policy would actually make more money. He believes the proposal would create a more stable fee market with little to no disadvantages. Rhavar also asks if anyone can think of a legitimate use case for spending unconfirmed BIP125 transactions.A proposal to modify the RBF eviction policy was suggested in a bitcoin-dev discussion. The change would allow for feerate separation between transactions in the mempool and better management of replacements. The discussion also touches on the BIP125 rules and the challenges of low-fee sweeps. The proposal aims to create a stable fee market and help services increase fees sanely when dealing with withdrawals.The email conversation highlights the problems faced by low-fee transactions, particularly when wanting to replace them with higher fee transactions. The cost of invalidating descendant transactions can be significant. The proposal suggests allowing users to dynamically increase their fees when dealing with withdrawals to avoid such issues and promote a stable fee market.A discussion between Rhavar and another individual focuses on replacing unconfirmed transactions. Rhavar mentions the cost of replacing a transaction that includes unconfirmed inputs, which can be expensive. The other person suggests that if the receiver pays a higher feerate, their transaction will get confirmed faster than the sender's replacement.Overall, the proposal for BIP125 aims to increase the efficiency of the fee marketplace by allowing users to increase fees of unconfirmed transactions. However, there are concerns and alternative suggestions regarding the practicality and impact of the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_Drivechain-RfD-Follow-Up.xml b/static/bitcoin-dev/July_2017/combined_Drivechain-RfD-Follow-Up.xml index 9badccfa1a..d6dcc773cd 100644 --- a/static/bitcoin-dev/July_2017/combined_Drivechain-RfD-Follow-Up.xml +++ b/static/bitcoin-dev/July_2017/combined_Drivechain-RfD-Follow-Up.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Drivechain RfD -- Follow Up - 2023-08-01T20:58:13.725682+00:00 + 2025-09-26T15:30:29.137273+00:00 + python-feedgen Paul Sztorc 2017-07-13 17:04:01+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Drivechain RfD -- Follow Up - 2023-08-01T20:58:13.725682+00:00 + 2025-09-26T15:30:29.137485+00:00 - The discussion in the provided context revolves around the security and implementation of drivechains, softforks, and P2SH transactions. Hampus Sjöberg argues that for softforks, 100% of nodes and miners need to upgrade to new rules to prevent chain splits, while for drivechains, only interested nodes validate the other chain. Paul Sztorc agrees but points out that even if some percentage of the network is validating both chains in drivechains, there will be no chain split if miners improperly withdraw from a sidechain. However, he expresses concern about the possibility of sidechain theft turning into a campaign.Greg raises concerns about theft in drivechains and discusses two different usages of the word "theft." He also questions whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes. Experts suggest that delayed withdrawal techniques in drivechains can mitigate the threat of theft_2. The email thread further delves into the security of WT^ transactions compared to P2SH and SegWit transactions. The author expresses doubt that the security of WT^ transactions can match that of P2SH and SegWit transactions.The discussion also highlights the different modes of use for drivechains, ranging from not upgrading Bitcoin software to actively using sidechains. It is emphasized that miners cannot steal funds in drivechains due to automatic enforcement policies enforced by full nodes. Another email exchange between Greg Slepak and Paul Sztorc explores the Drivechain project and its comparison with P2SH. The conversation clarifies four different modes of use for drivechains and addresses the issue of theft in drivechains. It is noted that the security of WT^ transactions can be brought up to the same level as P2SH and SegWit transactions.The conversation also touches upon the feasibility of using a proof-of-burn sidechain as an alternative to merged mining for increased security. Erik Aronesty suggests users would tolerate depreciation due to cheap and secure transactions, but Paul Sztorc counters that this scheme would be more expensive and relatively less secure. The discussion also covers the role of UTXO commitments for sidechains and the potential impact on the main chain's incentive structure. The lightning model is mentioned as a way to prevent further centralization.Overall, the email exchanges provide insights into the technical details, security models, and potential implications of drivechains, softforks, and P2SH transactions. The discussions highlight different perspectives on the security and implementation of these concepts, as well as potential challenges and alternative approaches.In addition to the above context, there is a discussion about the concept of a proof-of-burn sidechain, which requires burning Bitcoin or side-chain tokens to mine the side chain. The size of the burn determines the degree of security. Users can have a secure sidechain that issues a mining reward in sidechain tokens, which can be aggregated and redeemed for Bitcoins. However, any Bitcoins held in the sidechain depreciate in value at a rate of X% per year, which pays for increased security. This functions like an altcoin with high inflation and cheap transactions but is pegged to Bitcoin's price due to the pool of unredeemed Bitcoins held within the side chain.Drivechain is another sidechain enabling technology that seeks to plug many blockchains into the main chain, removing the blocksize limit and addressing scalability concerns. However, there are concerns about centralization and user choice of custodians. The discussion also raises questions about the potential impact on user control over their Bitcoins, as well as the correlation between network security and economic value.There is a debate around whether merged mining or proof-of-burn is a better solution for sidechain security. Some argue that proof-of-burn may result in users avoiding the sidechain due to the depreciation of their Bitcoins, while others believe merged mining would be more competitive. UTXO commitments are also suggested as a way to enhance the security of sidechains.The conversation explores various scenarios and considerations related to implementing Drivechain, including miner control, theft, antifragility, and the ecological impact. The participants recognize the need to balance innovation and security, ensuring that any changes made to the Bitcoin network do not compromise its integrity.Overall, the context provides insights into different perspectives on sidechain technologies and their implications for the Bitcoin ecosystem. It highlights the ongoing discussions and debates within the Bitcoin community regarding scalability, security, centralization, and user control.Furthermore, in the provided context, it is mentioned that there is an 8 MB maxblocksize, which doubles every two years. This implies that the maximum block size in a certain system is initially set at 8 MB, and then it will double in size every two years. The doubling of the maxblocksize every two years suggests a potential increase in the system's capacity to handle larger amounts of data. This can be seen as a measure to accommodate the growing demand for storage space and processing power in various applications 2017-07-13T17:04:01+00:00 + The discussion in the provided context revolves around the security and implementation of drivechains, softforks, and P2SH transactions. Hampus Sjöberg argues that for softforks, 100% of nodes and miners need to upgrade to new rules to prevent chain splits, while for drivechains, only interested nodes validate the other chain. Paul Sztorc agrees but points out that even if some percentage of the network is validating both chains in drivechains, there will be no chain split if miners improperly withdraw from a sidechain. However, he expresses concern about the possibility of sidechain theft turning into a campaign.Greg raises concerns about theft in drivechains and discusses two different usages of the word "theft." He also questions whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes. Experts suggest that delayed withdrawal techniques in drivechains can mitigate the threat of theft_2. The email thread further delves into the security of WT^ transactions compared to P2SH and SegWit transactions. The author expresses doubt that the security of WT^ transactions can match that of P2SH and SegWit transactions.The discussion also highlights the different modes of use for drivechains, ranging from not upgrading Bitcoin software to actively using sidechains. It is emphasized that miners cannot steal funds in drivechains due to automatic enforcement policies enforced by full nodes. Another email exchange between Greg Slepak and Paul Sztorc explores the Drivechain project and its comparison with P2SH. The conversation clarifies four different modes of use for drivechains and addresses the issue of theft in drivechains. It is noted that the security of WT^ transactions can be brought up to the same level as P2SH and SegWit transactions.The conversation also touches upon the feasibility of using a proof-of-burn sidechain as an alternative to merged mining for increased security. Erik Aronesty suggests users would tolerate depreciation due to cheap and secure transactions, but Paul Sztorc counters that this scheme would be more expensive and relatively less secure. The discussion also covers the role of UTXO commitments for sidechains and the potential impact on the main chain's incentive structure. The lightning model is mentioned as a way to prevent further centralization.Overall, the email exchanges provide insights into the technical details, security models, and potential implications of drivechains, softforks, and P2SH transactions. The discussions highlight different perspectives on the security and implementation of these concepts, as well as potential challenges and alternative approaches.In addition to the above context, there is a discussion about the concept of a proof-of-burn sidechain, which requires burning Bitcoin or side-chain tokens to mine the side chain. The size of the burn determines the degree of security. Users can have a secure sidechain that issues a mining reward in sidechain tokens, which can be aggregated and redeemed for Bitcoins. However, any Bitcoins held in the sidechain depreciate in value at a rate of X% per year, which pays for increased security. This functions like an altcoin with high inflation and cheap transactions but is pegged to Bitcoin's price due to the pool of unredeemed Bitcoins held within the side chain.Drivechain is another sidechain enabling technology that seeks to plug many blockchains into the main chain, removing the blocksize limit and addressing scalability concerns. However, there are concerns about centralization and user choice of custodians. The discussion also raises questions about the potential impact on user control over their Bitcoins, as well as the correlation between network security and economic value.There is a debate around whether merged mining or proof-of-burn is a better solution for sidechain security. Some argue that proof-of-burn may result in users avoiding the sidechain due to the depreciation of their Bitcoins, while others believe merged mining would be more competitive. UTXO commitments are also suggested as a way to enhance the security of sidechains.The conversation explores various scenarios and considerations related to implementing Drivechain, including miner control, theft, antifragility, and the ecological impact. The participants recognize the need to balance innovation and security, ensuring that any changes made to the Bitcoin network do not compromise its integrity.Overall, the context provides insights into different perspectives on sidechain technologies and their implications for the Bitcoin ecosystem. It highlights the ongoing discussions and debates within the Bitcoin community regarding scalability, security, centralization, and user control.Furthermore, in the provided context, it is mentioned that there is an 8 MB maxblocksize, which doubles every two years. This implies that the maximum block size in a certain system is initially set at 8 MB, and then it will double in size every two years. The doubling of the maxblocksize every two years suggests a potential increase in the system's capacity to handle larger amounts of data. This can be seen as a measure to accommodate the growing demand for storage space and processing power in various applications - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_Height-based-vs-block-time-based-thresholds.xml b/static/bitcoin-dev/July_2017/combined_Height-based-vs-block-time-based-thresholds.xml index d5ee530182..bc9a1b3de2 100644 --- a/static/bitcoin-dev/July_2017/combined_Height-based-vs-block-time-based-thresholds.xml +++ b/static/bitcoin-dev/July_2017/combined_Height-based-vs-block-time-based-thresholds.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Height based vs block time based thresholds - 2023-08-01T21:16:31.496877+00:00 - - Jorge Timón 2017-07-07 09:51:16+00:00 - - - shaolinfry 2017-07-07 05:52:13+00:00 - - - Luke Dashjr 2017-07-06 20:43:28+00:00 - - - Eric Voskuil 2017-07-06 17:41:52+00:00 - - - Jorge Timón 2017-07-06 17:20:47+00:00 - - - Hampus Sjöberg 2017-07-05 19:44:27+00:00 - - - Kekcoin 2017-07-05 08:54:40+00:00 - - - Gregory Maxwell 2017-07-05 08:06:33+00:00 - - - Luke Dashjr 2017-07-05 04:10:43+00:00 - - - shaolinfry 2017-07-05 04:00:38+00:00 - - - Luke Dashjr 2017-07-05 03:50:51+00:00 - - - Bram Cohen 2017-07-05 03:39:09+00:00 - - - Troy Benjegerdes 2017-07-05 02:25:33+00:00 - - - shaolinfry 2017-07-05 01:30:26+00:00 - + 2025-09-26T15:30:39.721341+00:00 + python-feedgen + + + [bitcoin-dev] Height based vs block time based thresholds shaolinfry + 2017-07-05T01:30:00.000Z + + + Troy Benjegerdes + 2017-07-05T02:25:00.000Z + + + Bram Cohen + 2017-07-05T03:39:00.000Z + + + Luke Dashjr + 2017-07-05T03:50:00.000Z + + + shaolinfry + 2017-07-05T04:00:00.000Z + + + Luke Dashjr + 2017-07-05T04:10:00.000Z + + + Gregory Maxwell + 2017-07-05T08:06:00.000Z + + + Kekcoin + 2017-07-05T08:54:00.000Z + + + Hampus Sjöberg + 2017-07-05T19:44:00.000Z + + + Jorge Timón + 2017-07-06T17:20:00.000Z + + + Eric Voskuil + 2017-07-06T17:41:00.000Z + + + Luke Dashjr + 2017-07-06T20:43:00.000Z + + + shaolinfry + 2017-07-07T05:52:00.000Z + + + Jorge Timón + 2017-07-07T09:51:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Height based vs block time based thresholds - 2023-08-01T21:16:31.496877+00:00 + 2025-09-26T15:30:39.722879+00:00 - Shaolinfry's proposal for BIP8 aims to address the criticisms of BIP9's blocktime-based thresholds. These thresholds have been criticized for being confusing and vulnerable to miners manipulating timestamps. To solve this issue, Shaolinfry proposes using height-based thresholds instead. This would provide certainty at a given block height and be easier to monitor. The code and updated BIP text for BIP8 can be found on GitHub. Shaolinfry is open to amending BIP8 to be height-based if there is enough interest.In response to the proposal for gratuitous orphaning, Gregory Maxwell argues that it is reckless and coercive. He believes that changes in Bitcoin's design are necessary to ensure network security and reduce harm. However, he opposes character assassination and criticizes these changes. Maxwell suggests waiting until after BIP148 to continue the discussion, as more real-world information will be available. In response to Maxwell's objections, a new pull request has been opened with the parts he objects to removed. It remains to be seen if this version will be satisfactory.Jorge Timon expresses his preference for using height instead of time in BIP9 and suggests a simpler way to issue a warning to nodes that don't know an activated deployment. His proposal involves using a special bit in versionbits, which does not require adding consensus rules. Shaolinfry initially had concerns about the proposal but they were addressed by Timon. Luke Dashjr supports the idea of a mandatory signal before activation, as it serves as a wake-up call for miners who have not upgraded yet. He also states that it enables deploying softforks as a MASF and only upgrading them to UASF on an as-needed basis. On the other hand, Shaolinfry expresses skepticism towards requiring signaling before activation, as it could lead to gratuitous orphaning.Hampus questions the amendments to BIP8 and suggests making it into its own BIP or allowing for more flexibility in the LOCKED_IN state. Luke Dashjr explains that the mandatory signal is not pointless but serves as a wake-up call for miners who are not upgraded yet. He also believes that not having a mandatory signal was a serious bug in BIP9, which is fixed in BIP148. Shaolinfry proposes amending BIP8 to be height-based instead of block time-based. While height-based thresholds are hard to predict due to difficulty fluctuations, they provide certainty at a given block height and are easy to monitor. Luke Dashjr has already opened a pull request to fix issues with BIP9 and merge it with BIP8, awaiting shaolinfry's approval.Luke Dashjr proposes changes to BIP8 to address regression compared to BIP9 and to avoid activating suboptimal or flawed soft forks without hard forking. However, there are concerns about when this mechanism would be beneficial versus when it could cause harm. There is opposition to making a mandatory signal due to fears of monetary losses and network instability resulting from the resulting disruption. A proposal has been made to fix issues with BIP9, but there are concerns about proposals involving gratuitous orphaning being reckless and coercive.In a conversation between shaolinfry and Luke Dashjr, they discuss the use of signaling for activation in BIP9. Shaolinfry suggests an extra state to require signaling before activation, but Luke argues that miners can simply fake signal, making it pointless. However, Luke believes that not having a mandatory signal is a serious bug in BIP9, fixed in BIP148. He explains that the absence of a mandatory signal makes the activation decisive and unambiguous, and it enables deploying softforks as a MASF, upgrading them to UASF on an as-needed basis. Luke has opened a pull request to fix issues in BIP9 and merge it with BIP8, awaiting shaolinfry's approval. Additionally, shaolinfry proposes amending BIP8 to be height-based instead of block time-based if there is sufficient interest.Overall, there are ongoing discussions and proposals to address the criticisms of BIP9 and improve the activation thresholds for soft forks in Bitcoin. The focus is on finding a more reliable and transparent method that minimizes manipulation and confusion while ensuring network security. 2017-07-07T09:51:16+00:00 + Shaolinfry's proposal for BIP8 aims to address the criticisms of BIP9's blocktime-based thresholds. These thresholds have been criticized for being confusing and vulnerable to miners manipulating timestamps. To solve this issue, Shaolinfry proposes using height-based thresholds instead. This would provide certainty at a given block height and be easier to monitor. The code and updated BIP text for BIP8 can be found on GitHub. Shaolinfry is open to amending BIP8 to be height-based if there is enough interest.In response to the proposal for gratuitous orphaning, Gregory Maxwell argues that it is reckless and coercive. He believes that changes in Bitcoin's design are necessary to ensure network security and reduce harm. However, he opposes character assassination and criticizes these changes. Maxwell suggests waiting until after BIP148 to continue the discussion, as more real-world information will be available. In response to Maxwell's objections, a new pull request has been opened with the parts he objects to removed. It remains to be seen if this version will be satisfactory.Jorge Timon expresses his preference for using height instead of time in BIP9 and suggests a simpler way to issue a warning to nodes that don't know an activated deployment. His proposal involves using a special bit in versionbits, which does not require adding consensus rules. Shaolinfry initially had concerns about the proposal but they were addressed by Timon. Luke Dashjr supports the idea of a mandatory signal before activation, as it serves as a wake-up call for miners who have not upgraded yet. He also states that it enables deploying softforks as a MASF and only upgrading them to UASF on an as-needed basis. On the other hand, Shaolinfry expresses skepticism towards requiring signaling before activation, as it could lead to gratuitous orphaning.Hampus questions the amendments to BIP8 and suggests making it into its own BIP or allowing for more flexibility in the LOCKED_IN state. Luke Dashjr explains that the mandatory signal is not pointless but serves as a wake-up call for miners who are not upgraded yet. He also believes that not having a mandatory signal was a serious bug in BIP9, which is fixed in BIP148. Shaolinfry proposes amending BIP8 to be height-based instead of block time-based. While height-based thresholds are hard to predict due to difficulty fluctuations, they provide certainty at a given block height and are easy to monitor. Luke Dashjr has already opened a pull request to fix issues with BIP9 and merge it with BIP8, awaiting shaolinfry's approval.Luke Dashjr proposes changes to BIP8 to address regression compared to BIP9 and to avoid activating suboptimal or flawed soft forks without hard forking. However, there are concerns about when this mechanism would be beneficial versus when it could cause harm. There is opposition to making a mandatory signal due to fears of monetary losses and network instability resulting from the resulting disruption. A proposal has been made to fix issues with BIP9, but there are concerns about proposals involving gratuitous orphaning being reckless and coercive.In a conversation between shaolinfry and Luke Dashjr, they discuss the use of signaling for activation in BIP9. Shaolinfry suggests an extra state to require signaling before activation, but Luke argues that miners can simply fake signal, making it pointless. However, Luke believes that not having a mandatory signal is a serious bug in BIP9, fixed in BIP148. He explains that the absence of a mandatory signal makes the activation decisive and unambiguous, and it enables deploying softforks as a MASF, upgrading them to UASF on an as-needed basis. Luke has opened a pull request to fix issues in BIP9 and merge it with BIP8, awaiting shaolinfry's approval. Additionally, shaolinfry proposes amending BIP8 to be height-based instead of block time-based if there is sufficient interest.Overall, there are ongoing discussions and proposals to address the criticisms of BIP9 and improve the activation thresholds for soft forks in Bitcoin. The focus is on finding a more reliable and transparent method that minimizes manipulation and confusion while ensuring network security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_Proposal-Demonstration-of-Phase-in-Full-Network-Upgrade-Activated-by-Miners.xml b/static/bitcoin-dev/July_2017/combined_Proposal-Demonstration-of-Phase-in-Full-Network-Upgrade-Activated-by-Miners.xml index ec23c52829..11643f701b 100644 --- a/static/bitcoin-dev/July_2017/combined_Proposal-Demonstration-of-Phase-in-Full-Network-Upgrade-Activated-by-Miners.xml +++ b/static/bitcoin-dev/July_2017/combined_Proposal-Demonstration-of-Phase-in-Full-Network-Upgrade-Activated-by-Miners.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners - 2023-08-01T21:07:40.604251+00:00 - - Zheming Lin 2017-07-22 03:58:21+00:00 - - - Zheming Lin 2017-06-16 14:39:26+00:00 - - - Eric Voskuil 2017-06-16 03:09:33+00:00 - - - Erik Aronesty 2017-06-15 18:38:57+00:00 - - - Eric Voskuil 2017-06-15 05:04:30+00:00 - - - Jameson Lopp 2017-06-14 20:11:07+00:00 - - - Zheming Lin 2017-06-14 19:04:21+00:00 - - - Jameson Lopp 2017-06-14 18:55:04+00:00 - - - Zheming Lin 2017-06-14 18:30:32+00:00 - - - Zheming Lin 2017-06-14 18:29:35+00:00 - - - Jameson Lopp 2017-06-14 17:20:32+00:00 - - - Zheming Lin 2017-06-14 16:39:42+00:00 - - - Jared Lee Richardson 2017-06-14 01:08:49+00:00 - - - James Hilliard 2017-06-14 00:23:06+00:00 - - - Jared Lee Richardson 2017-06-13 19:35:13+00:00 - - - Gregory Maxwell 2017-06-13 18:11:39+00:00 - - - James Hilliard 2017-06-13 10:20:11+00:00 - - - James Hilliard 2017-06-13 08:37:43+00:00 - - - Zheming Lin 2017-06-13 08:24:41+00:00 - - - Zheming Lin 2017-06-13 08:13:58+00:00 - - - James Hilliard 2017-06-13 07:19:24+00:00 - - - Zheming Lin 2017-06-13 06:50:26+00:00 - - - James Hilliard 2017-06-13 05:44:23+00:00 - - - Zheming Lin 2017-06-13 02:23:41+00:00 - + 2025-09-26T15:30:35.509939+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners Zheming Lin + 2017-06-13T02:23:00.000Z + + + James Hilliard + 2017-06-13T05:44:00.000Z + + + Zheming Lin + 2017-06-13T06:50:00.000Z + + + James Hilliard + 2017-06-13T07:19:00.000Z + + + Zheming Lin + 2017-06-13T08:13:00.000Z + + + Zheming Lin + 2017-06-13T08:24:00.000Z + + + James Hilliard + 2017-06-13T08:37:00.000Z + + + James Hilliard + 2017-06-13T10:20:00.000Z + + + Gregory Maxwell + 2017-06-13T18:11:00.000Z + + + Jared Lee Richardson + 2017-06-13T19:35:00.000Z + + + James Hilliard + 2017-06-14T00:23:00.000Z + + + Jared Lee Richardson + 2017-06-14T01:08:00.000Z + + + Zheming Lin + 2017-06-14T16:39:00.000Z + + + Jameson Lopp + 2017-06-14T17:20:00.000Z + + + Zheming Lin + 2017-06-14T18:29:00.000Z + + + Zheming Lin + 2017-06-14T18:30:00.000Z + + + Jameson Lopp + 2017-06-14T18:55:00.000Z + + + Zheming Lin + 2017-06-14T19:04:00.000Z + + + Jameson Lopp + 2017-06-14T20:11:00.000Z + + + Eric Voskuil + 2017-06-15T05:04:00.000Z + + + Erik Aronesty + 2017-06-15T18:38:00.000Z + + + Eric Voskuil + 2017-06-16T03:09:00.000Z + + + Zheming Lin + 2017-06-16T14:39:00.000Z + + + Zheming Lin + 2017-07-22T03:58:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners - 2023-08-01T21:07:40.604251+00:00 + 2025-09-26T15:30:35.512373+00:00 - In an email conversation among bitcoin developers, the topic of upgrading consensus rules was discussed. It was noted that if miners are passive or veto the activation of new rules, users have the option to refuse blocks that don't show readiness for enforcing the new rules. The discussion also touched on the issue of user choice and whether users should trust the majority of miners or not. It was emphasized that Bitcoin is a market, and users can choose to follow the miners or fork away if they don't trust them. The importance of not relying solely on miners when it comes to choosing consensus rules was highlighted.The proposed protocol upgrade involves using versionbits to define support signals for mining nodes, with tx version used to define current transactions. The deployment will occur in three stages, with an optional fourth stage for integrating codes of the protocol upgrade. Once activated by majority miner signal, mining nodes will orphan blocks with old versionbits and only new versionbit transactions will be allowed after two grace periods. Non-mining nodes have time to upgrade their software during the first two grace periods. The ledger in non-mining wallet nodes is honored and reserved, but users of off-chain wallet services can decide whether or not to follow service providers after receiving notification. Future protocol upgrades can be bonded with node upgrades and activated through miner votes.A new method for activating soft forks called "false signalling" has been proposed by the Bitcoin development team. This method suggests that non-mining nodes should upgrade their software assuming all signals are true. However, it may not be viable for controversial changes. Users will consider market factors when deciding what to do, and the total number of nodes does not necessarily indicate economic and user support.The benefits of the proposed protocol upgrade include incentivizing miners and non-mining nodes to upgrade, ensuring asset security for wallet nodes, and phasing in upgrades under the Nakamoto Consensus. However, there are risks associated with validationless mining, false signaling from miners, and collusion between miners and non-mining nodes. The implementation details of the proposed method are yet to be determined.Overall, the proposed protocol upgrade process aims to ensure that all miners and non-mining nodes upgrade by implementing a phased approach and utilizing majority miner signal. It provides incentives for upgrading, protects asset security, and minimizes the risk of delaying network upgrades. However, there are still challenges and risks that need to be addressed in the implementation.Nodes in the SPY network have the opportunity to upgrade their software as versionbits in the block header do not affect mining. However, after two grace periods, all nodes must be upgraded in order to send transactions and receive confirmations. This requirement is no worse than before and ensures that the ledger in non-mining wallet nodes is respected. Users of off-chain wallet services can choose whether or not to follow the service providers after receiving public notification. Future protocol upgrades can be linked with node upgrades, allowing for sufficient time for nodes to support new protocols. Even if there is a failure in miner activation, the situation will not worsen and the current state will remain stable.The fluctuation of hashing power can impact the longest chain, so having higher activation requirements reduces the risk of temporary forks. It is possible for miners to falsely signal to avoid being orphaned, but non-mining wallet nodes are unable to distinguish between true and false signals. Therefore, non-mining wallet nodes should upgrade assuming all signals are true, and miners signaling false signals should follow suit once all non-mining nodes have upgraded. Non-mining wallet nodes also have the ability to falsely signal without supporting the new protocol. However, genuine nodes should follow the result provided by miners' votes. While it is possible for miners and non-mining nodes to conspire to fork using the old protocol consensus, this possibility cannot be eliminated. Upgrading most passive non-mining nodes reduces their benefit in such scenarios.Transactions from non-mining nodes will not be affected, and there will be ample time for them to upgrade their wallet software. Future protocol upgrades can be independently activated by merging protocol upgrade codes with the upgraded client version and conducting a separate activation vote. This approach ensures that enough time is given for nodes to upgrade their software and support the new protocol, even if the miner vote fails to activate it. 2017-07-22T03:58:21+00:00 + In an email conversation among bitcoin developers, the topic of upgrading consensus rules was discussed. It was noted that if miners are passive or veto the activation of new rules, users have the option to refuse blocks that don't show readiness for enforcing the new rules. The discussion also touched on the issue of user choice and whether users should trust the majority of miners or not. It was emphasized that Bitcoin is a market, and users can choose to follow the miners or fork away if they don't trust them. The importance of not relying solely on miners when it comes to choosing consensus rules was highlighted.The proposed protocol upgrade involves using versionbits to define support signals for mining nodes, with tx version used to define current transactions. The deployment will occur in three stages, with an optional fourth stage for integrating codes of the protocol upgrade. Once activated by majority miner signal, mining nodes will orphan blocks with old versionbits and only new versionbit transactions will be allowed after two grace periods. Non-mining nodes have time to upgrade their software during the first two grace periods. The ledger in non-mining wallet nodes is honored and reserved, but users of off-chain wallet services can decide whether or not to follow service providers after receiving notification. Future protocol upgrades can be bonded with node upgrades and activated through miner votes.A new method for activating soft forks called "false signalling" has been proposed by the Bitcoin development team. This method suggests that non-mining nodes should upgrade their software assuming all signals are true. However, it may not be viable for controversial changes. Users will consider market factors when deciding what to do, and the total number of nodes does not necessarily indicate economic and user support.The benefits of the proposed protocol upgrade include incentivizing miners and non-mining nodes to upgrade, ensuring asset security for wallet nodes, and phasing in upgrades under the Nakamoto Consensus. However, there are risks associated with validationless mining, false signaling from miners, and collusion between miners and non-mining nodes. The implementation details of the proposed method are yet to be determined.Overall, the proposed protocol upgrade process aims to ensure that all miners and non-mining nodes upgrade by implementing a phased approach and utilizing majority miner signal. It provides incentives for upgrading, protects asset security, and minimizes the risk of delaying network upgrades. However, there are still challenges and risks that need to be addressed in the implementation.Nodes in the SPY network have the opportunity to upgrade their software as versionbits in the block header do not affect mining. However, after two grace periods, all nodes must be upgraded in order to send transactions and receive confirmations. This requirement is no worse than before and ensures that the ledger in non-mining wallet nodes is respected. Users of off-chain wallet services can choose whether or not to follow the service providers after receiving public notification. Future protocol upgrades can be linked with node upgrades, allowing for sufficient time for nodes to support new protocols. Even if there is a failure in miner activation, the situation will not worsen and the current state will remain stable.The fluctuation of hashing power can impact the longest chain, so having higher activation requirements reduces the risk of temporary forks. It is possible for miners to falsely signal to avoid being orphaned, but non-mining wallet nodes are unable to distinguish between true and false signals. Therefore, non-mining wallet nodes should upgrade assuming all signals are true, and miners signaling false signals should follow suit once all non-mining nodes have upgraded. Non-mining wallet nodes also have the ability to falsely signal without supporting the new protocol. However, genuine nodes should follow the result provided by miners' votes. While it is possible for miners and non-mining nodes to conspire to fork using the old protocol consensus, this possibility cannot be eliminated. Upgrading most passive non-mining nodes reduces their benefit in such scenarios.Transactions from non-mining nodes will not be affected, and there will be ample time for them to upgrade their wallet software. Future protocol upgrades can be independently activated by merging protocol upgrade codes with the upgraded client version and conducting a separate activation vote. This approach ensures that enough time is given for nodes to upgrade their software and support the new protocol, even if the miner vote fails to activate it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_The-Nuclear-Option-BIP148-MR-POWA.xml b/static/bitcoin-dev/July_2017/combined_The-Nuclear-Option-BIP148-MR-POWA.xml index bd0bf6c643..d10dd4958a 100644 --- a/static/bitcoin-dev/July_2017/combined_The-Nuclear-Option-BIP148-MR-POWA.xml +++ b/static/bitcoin-dev/July_2017/combined_The-Nuclear-Option-BIP148-MR-POWA.xml @@ -1,23 +1,32 @@ - + 2 Combined summary - The Nuclear Option: BIP148 + MR POWA - 2023-08-01T21:16:45.581024+00:00 - - Troy Benjegerdes 2017-07-05 14:02:08+00:00 - - - John Hardy 2017-07-05 09:18:36+00:00 - + 2025-09-26T15:30:41.811496+00:00 + python-feedgen + + + [bitcoin-dev] The Nuclear Option: BIP148 + MR POWA John Hardy + 2017-07-05T09:18:00.000Z + + + Troy Benjegerdes + 2017-07-05T14:02:00.000Z + + + [bitcoin-dev] difficulty adjustment (was: The Nuclear Option: BIP148 + MR POWA) Henning Kopp + 2017-07-05T14:26:00.000Z + + - python-feedgen + 2 Combined summary - The Nuclear Option: BIP148 + MR POWA - 2023-08-01T21:16:45.581024+00:00 + 2025-09-26T15:30:41.812022+00:00 - The proposal to split the Bitcoin network into two or three blockchains in order to increase its capacity has sparked controversy and is seen as risky, according to John Hardy's post on the bitcoin-dev mailing list. Hardy suggests that this may be an exercise in game theory to test theories. He also recommends finding a simple and robust difficulty adjustment that occurs every block, rather than the current system of every 2016 blocks.Hardy introduces Mining Reactive Proof of Work Addition (MR POWA) as a method to respond to mining behavior on a blockchain. In the case of BIP148, the activation criterion would be when a non-BIP148 compliant chain is detected 144 blocks ahead of a BIP148 compliant chain. This would trigger a change in consensus rules, resulting in a hard fork to lower the difficulty for the existing proof of work method and introduce a second proof of work method such as Scrypt or Ethash. The goal is to ensure SegWit activation and put more pressure on miners to follow the BIP148 chain.However, there is a potential downside to this approach as it could permanently split the network. On the upside, BIP148 miners would no longer need to "hold their nerve" as they would have a guaranteed viable chain and be rewarded for their early support. To counter attacks from the other chain, the MR POWA method would require alternating proof of work methods.This idea is highly contentious and would ideally be implemented through a grassroots movement similar to BIP148. Those already running a BIP148 node could easily run a BIP148 + MR POWA node. The hope is that this would force miners to follow the BIP148 chain, rendering the additional code unnecessary. However, careful evaluation and consideration of potential outcomes are crucial before implementing this plan, as it is based on pure game theory. 2017-07-05T14:02:08+00:00 + The proposal to split the Bitcoin network into two or three blockchains in order to increase its capacity has sparked controversy and is seen as risky, according to John Hardy's post on the bitcoin-dev mailing list. Hardy suggests that this may be an exercise in game theory to test theories. He also recommends finding a simple and robust difficulty adjustment that occurs every block, rather than the current system of every 2016 blocks.Hardy introduces Mining Reactive Proof of Work Addition (MR POWA) as a method to respond to mining behavior on a blockchain. In the case of BIP148, the activation criterion would be when a non-BIP148 compliant chain is detected 144 blocks ahead of a BIP148 compliant chain. This would trigger a change in consensus rules, resulting in a hard fork to lower the difficulty for the existing proof of work method and introduce a second proof of work method such as Scrypt or Ethash. The goal is to ensure SegWit activation and put more pressure on miners to follow the BIP148 chain.However, there is a potential downside to this approach as it could permanently split the network. On the upside, BIP148 miners would no longer need to "hold their nerve" as they would have a guaranteed viable chain and be rewarded for their early support. To counter attacks from the other chain, the MR POWA method would require alternating proof of work methods.This idea is highly contentious and would ideally be implemented through a grassroots movement similar to BIP148. Those already running a BIP148 node could easily run a BIP148 + MR POWA node. The hope is that this would force miners to follow the BIP148 chain, rendering the additional code unnecessary. However, careful evaluation and consideration of potential outcomes are crucial before implementing this plan, as it is based on pure game theory. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_UTXO-growth-scaling-solution-proposal.xml b/static/bitcoin-dev/July_2017/combined_UTXO-growth-scaling-solution-proposal.xml index 27d181fa4d..00473762bc 100644 --- a/static/bitcoin-dev/July_2017/combined_UTXO-growth-scaling-solution-proposal.xml +++ b/static/bitcoin-dev/July_2017/combined_UTXO-growth-scaling-solution-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - UTXO growth scaling solution proposal - 2023-08-01T21:23:22.653747+00:00 + 2025-09-26T15:30:37.629051+00:00 + python-feedgen Mark Friedenbach 2017-08-23 03:26:19+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - UTXO growth scaling solution proposal - 2023-08-01T21:23:22.653747+00:00 + 2025-09-26T15:30:37.629241+00:00 - Bitcoin developers are engaged in discussions about implementing features that could change the operation of Bitcoin. One proposal suggests making coins "expire" after a certain period of time, while another proposes creating a "never expire" transaction output. The potential security risks and the need for transparency and warning are also emphasized. Additionally, there is debate about implementing free transactions based on old priority rules, with suggestions including requiring the inclusion of free transactions in each block or a two-step transaction with a fee to register a UTXO refresh. However, there is no consensus on how to implement these proposals without burdening consensus rules.The threat of quantum computing to Bitcoin's security is also discussed, with suggestions for new proof-of-work algorithms, address formats, and signing protocols. Removing stale coins to prevent hacking is proposed, but there are differing opinions on whether this aligns with the principles of Bitcoin. The conversation highlights the challenges of implementing significant changes to Bitcoin, touching on issues of transparency, security, taxation, and adapting to technological advancements.Bitcoin developers are exploring solutions to address unbounded UTXO growth and ensure scalability. Proposals include burning inactive coins, implementing a minimum mining fee based on input age, and returning lost coins to miners as a fee. Limiting UTXO age in block count and invalidating UTXOs after a certain number of generations are also suggested. Some argue that limiting UTXO growth does not improve scalability, while others believe it is necessary for Bitcoin's longevity. The issue of UTXO size being critical because it cannot currently be pruned is acknowledged.A proposed solution involves using a soft fork to limit the maximum size of the UTXO set, with concerns raised about "lost" bitcoins that have not been spent for a long time. To address this, a mechanism called "luster" is suggested, where UTXOs lose value as they age. Coins continuously used in the Bitcoin economy retain value, while old coins lose value until they become valueless or reenter circulation. The proposal suggests storing the last 150 years of history in the blockchain. These proposals show promise in resolving the UTXO growth problem and scalability concerns but require considerations such as wallet software compatibility and sidechain implementation.Sidechains offer solutions to interoperability and scalability challenges in the blockchain ecosystem. They operate as separate blockchains pegged to the main blockchain, enabling asset transfer between chains and providing flexibility. Sidechains mitigate scalability issues by reducing the size of the main blockchain. However, implementing sidechains requires careful consideration of wallet software functionality and communication protocols between the main chain and sidechains. Collaboration and standardization within the blockchain community are necessary for successful integration. Sidechains have the potential to enhance blockchain functionality and address scalability concerns with the right development efforts. 2017-08-23T03:26:19+00:00 + Bitcoin developers are engaged in discussions about implementing features that could change the operation of Bitcoin. One proposal suggests making coins "expire" after a certain period of time, while another proposes creating a "never expire" transaction output. The potential security risks and the need for transparency and warning are also emphasized. Additionally, there is debate about implementing free transactions based on old priority rules, with suggestions including requiring the inclusion of free transactions in each block or a two-step transaction with a fee to register a UTXO refresh. However, there is no consensus on how to implement these proposals without burdening consensus rules.The threat of quantum computing to Bitcoin's security is also discussed, with suggestions for new proof-of-work algorithms, address formats, and signing protocols. Removing stale coins to prevent hacking is proposed, but there are differing opinions on whether this aligns with the principles of Bitcoin. The conversation highlights the challenges of implementing significant changes to Bitcoin, touching on issues of transparency, security, taxation, and adapting to technological advancements.Bitcoin developers are exploring solutions to address unbounded UTXO growth and ensure scalability. Proposals include burning inactive coins, implementing a minimum mining fee based on input age, and returning lost coins to miners as a fee. Limiting UTXO age in block count and invalidating UTXOs after a certain number of generations are also suggested. Some argue that limiting UTXO growth does not improve scalability, while others believe it is necessary for Bitcoin's longevity. The issue of UTXO size being critical because it cannot currently be pruned is acknowledged.A proposed solution involves using a soft fork to limit the maximum size of the UTXO set, with concerns raised about "lost" bitcoins that have not been spent for a long time. To address this, a mechanism called "luster" is suggested, where UTXOs lose value as they age. Coins continuously used in the Bitcoin economy retain value, while old coins lose value until they become valueless or reenter circulation. The proposal suggests storing the last 150 years of history in the blockchain. These proposals show promise in resolving the UTXO growth problem and scalability concerns but require considerations such as wallet software compatibility and sidechain implementation.Sidechains offer solutions to interoperability and scalability challenges in the blockchain ecosystem. They operate as separate blockchains pegged to the main blockchain, enabling asset transfer between chains and providing flexibility. Sidechains mitigate scalability issues by reducing the size of the main blockchain. However, implementing sidechains requires careful consideration of wallet software functionality and communication protocols between the main chain and sidechains. Collaboration and standardization within the blockchain community are necessary for successful integration. Sidechains have the potential to enhance blockchain functionality and address scalability concerns with the right development efforts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap-Update-.xml b/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap-Update-.xml index 28ba0c5c7c..9e15c8761f 100644 --- a/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap-Update-.xml +++ b/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap-Update-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Updating the Scaling Roadmap [Update] - 2023-08-01T21:22:14.169550+00:00 + 2025-09-26T15:30:24.937011+00:00 + python-feedgen Paul Sztorc 2017-07-17 22:04:49+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Updating the Scaling Roadmap [Update] - 2023-08-01T21:22:14.169550+00:00 + 2025-09-26T15:30:24.937169+00:00 - In a recent email exchange between David A. Harding and Paul Sztorc, the possibility of a document gaining traction on BitcoinCore.org was discussed. Paul expressed that without interest from the maintainers of bitcoincore.org, the document will probably be unable to gain traction. David responded by stating that if Paul wants his document to appear on the website, he should open a PR and offered to help format the document for the website. The maintainers of BitcoinCore.org ultimately decide if the standard has been met. Paul appreciated David's response and stated that he would make opening a PR to BitcoinCore.org with David's statement a priority so that future confusion can be avoided.In another discussion about adding new ideas to the Bitcoin roadmap, Alex Morcos and Peter Todd agreed that caution is necessary. Todd used his own Treechains work as an example of an idea that generated excitement but proved more difficult to implement than anticipated. He emphasized the importance of proper security peer review. Paul Sztorc proposed updating the existing Core Scalability Roadmap created in December 2015. The roadmap succeeded in synchronizing the entire Bitcoin community and getting everyone back to work. However, since the roadmap is now 19 months old, it is quite obsolete and needs to be replaced. The new roadmap would remove what has been accomplished, introduce new innovations and approaches, and update deadlines and projections. It includes technologies that increase Bitcoin's maximum tps rate or make it easier to process a higher volume of transactions.The technical community has completed a number of items on the Dec 2015 roadmap such as VersionBits (BIP 9), Compact Blocks (BIP 152), and Check Sequence Verify (BIP 112). Segregated Witness (BIP 141) and Lightning Network have been completed and await activation. Schnorr Signature Aggregation has been implemented in draft form in libsecp256k1, and drivechain is currently under peer review and may be usable by the end of 2017. Alex Morcos expressed concern about adding relatively new/untested ideas like Drivechain to the roadmap. Paul updated the roadmap to a "forecast" and edited the drivechain part to emphasize mainchain space being freed as defectors leave for an alt-chain.The Bitcoin community is exploring various scaling technologies including Segregated Witness, Lightning Network, Schnorr signature aggregation, MimbleWimble's shrinking block history, and drivechains. However, these technologies may not be sufficient to solve Bitcoin's scalability problem, and a hard fork to increase block size may be necessary. The proposed roadmap is still in draft form and feedback from the community is requested. A Google Doc link is available for those interested.In July 2017, Paul Sztorc proposed updating the Core Scalability Roadmap. The older statement from Dec 2015 endorsed a belief that "the community is ready to deliver on its shared vision that addresses the needs of the system while upholding its values". However, the shared vision has grown sharper over the last 18 months. According to Paul, it's necessary to revise it: remove what has been accomplished, introduce new innovations and approaches, and update deadlines and projections. The roadmap helped synchronize the entire Bitcoin community, bringing finality to the conversations of that time and getting everyone back to work. However, the Dec 2015 roadmap is now 19 months old and needs to be replaced.The new roadmap includes technologies that increase Bitcoin's maximum tps rate or make it easier to process a higher volume of transactions. Several items on the Dec 2015 roadmap have been completed, such as VersionBits (BIP 9), Compact Blocks (BIP 152), and Check Sequence Verify (BIP 112). Segregated Witness (BIP 141) and Lightning Network are complete and await activation. Schnorr Signature Aggregation has been implemented in draft form and drivechain is currently under peer review. If the capacity improvements outlined are insufficient, a hard fork may be necessary to increase block size. The document has been uploaded to GitHub for comments and expressions of interest.Paul Sztorc suggested updating the Core Scalability Roadmap. Greg Maxwell, the author of the original roadmap, has expressed regret and NACK'ed the concept. Tom Zander also did not ACK it due to its labeling as a "Bitcoin" document instead of a specific project document. The draft has been uploaded to GitHub and updated based on feedback received. However, without interest from the maintainers of bitcoincore.org, the document will probably be unable to gain traction.Paul Sztorc provided his reasons for updating the roadmap, stating that it synchronized the entire Bitcoin community and brought finality to the conversations of that time, getting everyone back to work. He emphasized the fatal scaling problem of the scaling conversation itself. The new roadmap updates the previous roadmap, includes technologies to increase capacity and scalability, and emphasizes concrete numbers and dates. Paul welcomes edits and feedback from the community.The technologies 2017-07-17T22:04:49+00:00 + In a recent email exchange between David A. Harding and Paul Sztorc, the possibility of a document gaining traction on BitcoinCore.org was discussed. Paul expressed that without interest from the maintainers of bitcoincore.org, the document will probably be unable to gain traction. David responded by stating that if Paul wants his document to appear on the website, he should open a PR and offered to help format the document for the website. The maintainers of BitcoinCore.org ultimately decide if the standard has been met. Paul appreciated David's response and stated that he would make opening a PR to BitcoinCore.org with David's statement a priority so that future confusion can be avoided.In another discussion about adding new ideas to the Bitcoin roadmap, Alex Morcos and Peter Todd agreed that caution is necessary. Todd used his own Treechains work as an example of an idea that generated excitement but proved more difficult to implement than anticipated. He emphasized the importance of proper security peer review. Paul Sztorc proposed updating the existing Core Scalability Roadmap created in December 2015. The roadmap succeeded in synchronizing the entire Bitcoin community and getting everyone back to work. However, since the roadmap is now 19 months old, it is quite obsolete and needs to be replaced. The new roadmap would remove what has been accomplished, introduce new innovations and approaches, and update deadlines and projections. It includes technologies that increase Bitcoin's maximum tps rate or make it easier to process a higher volume of transactions.The technical community has completed a number of items on the Dec 2015 roadmap such as VersionBits (BIP 9), Compact Blocks (BIP 152), and Check Sequence Verify (BIP 112). Segregated Witness (BIP 141) and Lightning Network have been completed and await activation. Schnorr Signature Aggregation has been implemented in draft form in libsecp256k1, and drivechain is currently under peer review and may be usable by the end of 2017. Alex Morcos expressed concern about adding relatively new/untested ideas like Drivechain to the roadmap. Paul updated the roadmap to a "forecast" and edited the drivechain part to emphasize mainchain space being freed as defectors leave for an alt-chain.The Bitcoin community is exploring various scaling technologies including Segregated Witness, Lightning Network, Schnorr signature aggregation, MimbleWimble's shrinking block history, and drivechains. However, these technologies may not be sufficient to solve Bitcoin's scalability problem, and a hard fork to increase block size may be necessary. The proposed roadmap is still in draft form and feedback from the community is requested. A Google Doc link is available for those interested.In July 2017, Paul Sztorc proposed updating the Core Scalability Roadmap. The older statement from Dec 2015 endorsed a belief that "the community is ready to deliver on its shared vision that addresses the needs of the system while upholding its values". However, the shared vision has grown sharper over the last 18 months. According to Paul, it's necessary to revise it: remove what has been accomplished, introduce new innovations and approaches, and update deadlines and projections. The roadmap helped synchronize the entire Bitcoin community, bringing finality to the conversations of that time and getting everyone back to work. However, the Dec 2015 roadmap is now 19 months old and needs to be replaced.The new roadmap includes technologies that increase Bitcoin's maximum tps rate or make it easier to process a higher volume of transactions. Several items on the Dec 2015 roadmap have been completed, such as VersionBits (BIP 9), Compact Blocks (BIP 152), and Check Sequence Verify (BIP 112). Segregated Witness (BIP 141) and Lightning Network are complete and await activation. Schnorr Signature Aggregation has been implemented in draft form and drivechain is currently under peer review. If the capacity improvements outlined are insufficient, a hard fork may be necessary to increase block size. The document has been uploaded to GitHub for comments and expressions of interest.Paul Sztorc suggested updating the Core Scalability Roadmap. Greg Maxwell, the author of the original roadmap, has expressed regret and NACK'ed the concept. Tom Zander also did not ACK it due to its labeling as a "Bitcoin" document instead of a specific project document. The draft has been uploaded to GitHub and updated based on feedback received. However, without interest from the maintainers of bitcoincore.org, the document will probably be unable to gain traction.Paul Sztorc provided his reasons for updating the roadmap, stating that it synchronized the entire Bitcoin community and brought finality to the conversations of that time, getting everyone back to work. He emphasized the fatal scaling problem of the scaling conversation itself. The new roadmap updates the previous roadmap, includes technologies to increase capacity and scalability, and emphasizes concrete numbers and dates. Paul welcomes edits and feedback from the community.The technologies - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap.xml b/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap.xml index 895874395b..b4d62e1bf7 100644 --- a/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap.xml +++ b/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap.xml @@ -1,116 +1,95 @@ - + 2 Combined summary - Updating the Scaling Roadmap - 2023-08-01T21:20:23.751052+00:00 - - CryptAxe 2017-07-12 22:07:47+00:00 - - - Tao Effect 2017-07-12 21:55:39+00:00 - - - CryptAxe 2017-07-12 19:54:48+00:00 - - - Tao Effect 2017-07-12 19:42:49+00:00 - - - Chris Stewart 2017-07-12 19:34:54+00:00 - - - Tao Effect 2017-07-12 19:24:28+00:00 - - - Chris Stewart 2017-07-12 19:19:03+00:00 - - - Tom Zander 2017-07-12 09:37:32+00:00 - - - Tom Zander 2017-07-12 09:02:51+00:00 - - - Jacob Eliosoff 2017-07-12 07:27:32+00:00 - - - Gregory Maxwell 2017-07-12 03:33:47+00:00 - - - Bryan Bishop 2017-07-12 02:48:38+00:00 - - - Paul Sztorc 2017-07-12 01:40:32+00:00 - - - Karl Johan Alm 2017-07-12 01:22:59+00:00 - - - Paul Sztorc 2017-07-12 00:21:09+00:00 - - - Gregory Maxwell 2017-07-12 00:07:51+00:00 - - - Bryan Bishop 2017-07-11 23:36:12+00:00 - - - Anthony Towns 2017-07-11 23:28:39+00:00 - - - Tao Effect 2017-07-11 23:12:03+00:00 - - - Paul Sztorc 2017-07-11 22:57:12+00:00 - - - Paul Sztorc 2017-07-11 22:49:19+00:00 - - - Tao Effect 2017-07-11 22:41:18+00:00 - - - Paul Sztorc 2017-07-11 22:27:56+00:00 - - - Steve Davis 2017-07-11 22:26:38+00:00 - - - Paul Sztorc 2017-07-11 22:17:19+00:00 - - - Pieter Wuille 2017-07-11 21:40:36+00:00 - - - Gregory Maxwell 2017-07-11 21:40:28+00:00 - - - Gregory Maxwell 2017-07-11 21:31:29+00:00 - - - CryptAxe 2017-07-11 21:16:52+00:00 - - - Gregory Maxwell 2017-07-11 21:11:38+00:00 - - - Paul Sztorc 2017-07-11 20:36:36+00:00 - - - Paul Sztorc 2017-07-11 20:18:04+00:00 - - - Pieter Wuille 2017-07-11 20:01:10+00:00 - - - Adam Back 2017-07-11 16:49:57+00:00 - - - Chris Stewart 2017-07-11 16:03:45+00:00 - - - Paul Sztorc 2017-07-10 16:50:21+00:00 - + 2025-09-26T15:30:48.148085+00:00 + python-feedgen + + + [bitcoin-dev] how to disable segwit in my build? Dan Libby + 2017-07-12T06:17:00.000Z + + + Gregory Maxwell + 2017-07-13T01:04:00.000Z + + + Anthony Towns + 2017-07-13T01:48:00.000Z + + + Federico Tenga + 2017-07-13T13:11:00.000Z + + + Hampus Sjöberg + 2017-07-13T13:39:00.000Z + + + Dan Libby + 2017-07-13T16:05:00.000Z + + + Dan Libby + 2017-07-13T16:13:00.000Z + + + Dan Libby + 2017-07-13T16:19:00.000Z + + + Jameson Lopp + 2017-07-13T16:35:00.000Z + + + Dan Libby + 2017-07-13T21:58:00.000Z + + + Hampus Sjöberg + 2017-07-13T22:50:00.000Z + + + Lucas Clemente Vella + 2017-07-13T23:19:00.000Z + + + Dan Libby + 2017-07-13T23:20:00.000Z + + + Hampus Sjöberg + 2017-07-14T08:52:00.000Z + + + Tier Nolan + 2017-07-14T09:03:00.000Z + + + Troy Benjegerdes + 2017-07-14T21:11:00.000Z + + + [bitcoin-dev] Updating the Scaling Roadmap [Update] Paul Sztorc + 2017-07-17T17:13:00.000Z + + + Alex Morcos + 2017-07-17T18:49:00.000Z + + + Paul Sztorc + 2017-07-17T20:13:00.000Z + + + Peter Todd + 2017-07-17T21:50:00.000Z + + + Paul Sztorc + 2017-07-17T22:04:00.000Z + + @@ -147,13 +126,13 @@ - python-feedgen + 2 Combined summary - Updating the Scaling Roadmap - 2023-08-01T21:20:23.752051+00:00 + 2025-09-26T15:30:48.150564+00:00 - In a discussion on the bitcoin-dev mailing list, there was a debate about the security model of adding consensus rules via softfork in Drivechain. CryptAxe disagreed that it would encourage more risky behavior and explained that the risks associated with drivechains were not due to how new consensus rules would be added, but rather were similar to the risk associated with the P2SH softfork. Tao Effect questioned whether full nodes validate the script in P2SH and SegWit, while CryptAxe argued that anyone-can-spend outputs are used by less than 0.1% of users and most software doesn't even allow for the possibility. Luke-Jr and Lopp were cited as sources who had done research on the cost of stealing these outputs.Greg questioned Pieter's objection to Drivechain's security model and whether miners have complete control over the coins. The usage of anyone-can-spend outputs in Drivechain was discussed, with concerns about its impact on Bitcoin's security. Proponents argued that Drivechain has a different security model and most users will not have to go through the Drivechain withdrawal process. There are ongoing discussions about better options for sidechains.Paul Sztorc defended Drivechain and argued that it is unfair to characterize it as an unmistakable weakening of Bitcoin's security guarantees. He admitted that Drivechain outputs have a different security model than other contracts, as they are controlled by miners. Tao Effect raised concerns about the security of sidechains allowing miners to steal bitcoins. Greg Slepak criticized the adoption of Drivechain and expressed concerns about compromising Bitcoin's security.Karl Johan Alm suggested that Bitcoin development differs from Linux kernel development and recommended having a roadmap to give users insights into what is being planned for Bitcoin. Tom Zander agreed with the suggestion and emphasized the importance of individual groups proposing solutions and letting the market decide. There were discussions about roadmaps for Bitcoin development. Gregory Maxwell suggested focusing on finalization and release processes rather than creating roadmaps. Paul Sztorc advocated for an updated roadmap to clarify priorities, but also acknowledged the challenges of setting specific deadlines. The discussions also touched on transparency, communication, and potential influences on Bitcoin's direction.In an email exchange, objections to Drivechain's security model were discussed. Concerns were raised about miners having the ability to steal bitcoins through sidechains. The conversation also explored the topic of roadmaps and their effectiveness in communicating development plans. Disagreements arose regarding research, input from contributors, and reliable communication channels within the Bitcoin industry.A person noticed that an email sent by Gregory Maxwell was actually written in 2016, causing confusion. The email included information on Bitcoin, including a section on roadmaps. Paul Sztorc responded to the email, criticizing the latest proposal for scaling Bitcoin and expressing concerns about control versus collaboration.Overall, the discussions revolved around the security model of Drivechain, concerns about compromising Bitcoin's security, the usage of anyone-can-spend outputs, the need for roadmaps, and challenges in communication and coordination within the Bitcoin industry.Bitcoin developer Paul Sztorc has proposed that the 2015 scaling roadmap for Bitcoin is outdated and in need of revision. The previous roadmap had successfully brought the Bitcoin community together to address scalability issues, but given that it is now almost 19 months old, Sztorc argues that it should be updated. His suggestion is to remove what has already been accomplished, introduce new innovations and approaches, and update deadlines and projections.Sztorc's draft of the new roadmap includes completed items such as VersionBits (BIP9), Compact Blocks (BIP152), Check Sequence Verify (BIP112), and Segregated Witness (BIP141), which is estimated to increase capacity by a factor of 2.2 once activated. The Lightning Network, a technology that allows for off-chain transactions, is also complete and awaiting the activation of SegWit. Other upcoming improvements mentioned in the draft are Transaction Compression, which could improve scalability by around 20%, and Schnorr Signature Aggregation, expected to be ready by Q4 of 2016 and resulting in storage and bandwidth savings of at least 25%.In terms of increasing capacity further, Sztorc suggests the implementation of Drivechain, which allows bitcoins to be temporarily moved to "alternative" blockchain networks, albeit with less decentralization. If these improvements prove insufficient, a hard fork may be necessary to increase the block size. Spoonnet is currently seen as the most attractive option for such a hard fork. However, safe deployment methods for any changes are also being considered.While acknowledging the success of the previous scaling roadmap, Sztorc believes it is time for an update to reflect new advancements and developments. He welcomes feedback on his draft and encourages edits to be made. Additionally, Sztorc emphasizes the value of an updated roadmap even for those who choose not to sign it, as their refusal would still provide valuable information. 2017-07-12T22:07:47+00:00 + In a discussion on the bitcoin-dev mailing list, there was a debate about the security model of adding consensus rules via softfork in Drivechain. CryptAxe disagreed that it would encourage more risky behavior and explained that the risks associated with drivechains were not due to how new consensus rules would be added, but rather were similar to the risk associated with the P2SH softfork. Tao Effect questioned whether full nodes validate the script in P2SH and SegWit, while CryptAxe argued that anyone-can-spend outputs are used by less than 0.1% of users and most software doesn't even allow for the possibility. Luke-Jr and Lopp were cited as sources who had done research on the cost of stealing these outputs.Greg questioned Pieter's objection to Drivechain's security model and whether miners have complete control over the coins. The usage of anyone-can-spend outputs in Drivechain was discussed, with concerns about its impact on Bitcoin's security. Proponents argued that Drivechain has a different security model and most users will not have to go through the Drivechain withdrawal process. There are ongoing discussions about better options for sidechains.Paul Sztorc defended Drivechain and argued that it is unfair to characterize it as an unmistakable weakening of Bitcoin's security guarantees. He admitted that Drivechain outputs have a different security model than other contracts, as they are controlled by miners. Tao Effect raised concerns about the security of sidechains allowing miners to steal bitcoins. Greg Slepak criticized the adoption of Drivechain and expressed concerns about compromising Bitcoin's security.Karl Johan Alm suggested that Bitcoin development differs from Linux kernel development and recommended having a roadmap to give users insights into what is being planned for Bitcoin. Tom Zander agreed with the suggestion and emphasized the importance of individual groups proposing solutions and letting the market decide. There were discussions about roadmaps for Bitcoin development. Gregory Maxwell suggested focusing on finalization and release processes rather than creating roadmaps. Paul Sztorc advocated for an updated roadmap to clarify priorities, but also acknowledged the challenges of setting specific deadlines. The discussions also touched on transparency, communication, and potential influences on Bitcoin's direction.In an email exchange, objections to Drivechain's security model were discussed. Concerns were raised about miners having the ability to steal bitcoins through sidechains. The conversation also explored the topic of roadmaps and their effectiveness in communicating development plans. Disagreements arose regarding research, input from contributors, and reliable communication channels within the Bitcoin industry.A person noticed that an email sent by Gregory Maxwell was actually written in 2016, causing confusion. The email included information on Bitcoin, including a section on roadmaps. Paul Sztorc responded to the email, criticizing the latest proposal for scaling Bitcoin and expressing concerns about control versus collaboration.Overall, the discussions revolved around the security model of Drivechain, concerns about compromising Bitcoin's security, the usage of anyone-can-spend outputs, the need for roadmaps, and challenges in communication and coordination within the Bitcoin industry.Bitcoin developer Paul Sztorc has proposed that the 2015 scaling roadmap for Bitcoin is outdated and in need of revision. The previous roadmap had successfully brought the Bitcoin community together to address scalability issues, but given that it is now almost 19 months old, Sztorc argues that it should be updated. His suggestion is to remove what has already been accomplished, introduce new innovations and approaches, and update deadlines and projections.Sztorc's draft of the new roadmap includes completed items such as VersionBits (BIP9), Compact Blocks (BIP152), Check Sequence Verify (BIP112), and Segregated Witness (BIP141), which is estimated to increase capacity by a factor of 2.2 once activated. The Lightning Network, a technology that allows for off-chain transactions, is also complete and awaiting the activation of SegWit. Other upcoming improvements mentioned in the draft are Transaction Compression, which could improve scalability by around 20%, and Schnorr Signature Aggregation, expected to be ready by Q4 of 2016 and resulting in storage and bandwidth savings of at least 25%.In terms of increasing capacity further, Sztorc suggests the implementation of Drivechain, which allows bitcoins to be temporarily moved to "alternative" blockchain networks, albeit with less decentralization. If these improvements prove insufficient, a hard fork may be necessary to increase the block size. Spoonnet is currently seen as the most attractive option for such a hard fork. However, safe deployment methods for any changes are also being considered.While acknowledging the success of the previous scaling roadmap, Sztorc believes it is time for an update to reflect new advancements and developments. He welcomes feedback on his draft and encourages edits to be made. Additionally, Sztorc emphasizes the value of an updated roadmap even for those who choose not to sign it, as their refusal would still provide valuable information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2017/combined_how-to-disable-segwit-in-my-build-.xml b/static/bitcoin-dev/July_2017/combined_how-to-disable-segwit-in-my-build-.xml index 83b2c9c5ce..30121c2690 100644 --- a/static/bitcoin-dev/July_2017/combined_how-to-disable-segwit-in-my-build-.xml +++ b/static/bitcoin-dev/July_2017/combined_how-to-disable-segwit-in-my-build-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - how to disable segwit in my build? - 2023-08-01T21:21:38.347917+00:00 + 2025-09-26T15:30:33.361683+00:00 + python-feedgen Troy Benjegerdes 2017-07-14 21:11:07+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - how to disable segwit in my build? - 2023-08-01T21:21:38.348919+00:00 + 2025-09-26T15:30:33.361857+00:00 - A discussion on the bitcoin-dev mailing list revolved around the issue of disabling segwit activation in Bitcoin Core releases prior to 0.13.1. The conversation began with a user named Dan Libby expressing his desire to avoid segwit activation until he felt comfortable with it. However, Gregory Maxwell pointed out that disabling segwit activation is not a simple task and is also an unsupported configuration. Another respondent criticized Maxwell's attitude, warning that it could lead to Bitcoin Core being dropped and multiple competing implementations emerging.One of the concerns raised by Libby was the difficulty in maintaining and reading the consensus-critical code with segwit, as less than one third of it is visible on-screen. He suggested that users should have the ability to firewall off the code to ensure they are not running segwit. Another issue discussed was the risk for those using legacy clients, as segwit transactions can appear as "anyone-can-spend" outputs from their perspective. This vulnerability creates a risk for "zero confirm" transactions. One proposed solution was to avoid any transaction chain that contains a segwit transaction, but this would require everyone they transact with to follow the same rule.The conversation then shifted to the topic of achieving full security in bitcoin transactions. The recipient expressed uncertainty about how to achieve this, given that anyone they have transacted with can send them coins at any time. One option suggested was to run a node that has never published an address to a third party. Another option was to modify their own node to reject segwit transactions, but this would hardfork the network. It was also mentioned that it may be possible to construct a "certain balance" and an "uncertain balance" without modifying any rules.Hampus Sjöberg provided further clarification, explaining that there are two ways to be fully secure regarding chain transactions. The first option is to validate using the new rules of the network by running a segwit node. The second option is to avoid any transaction chain that contains a segwit transaction. He explained that the witness program in segwit transactions is encoded in a new format that old nodes do not understand, so for old nodes, a number greater than zero will be counted as a valid spend.The implications of not upgrading to a segwit compliant node were discussed. It was noted that if the majority of the network adopts segwit, non-segwit nodes would be downgraded to near-SPV node validation and may not be able to fully verify the ownership of bitcoins. It was also mentioned that even if one does not upgrade to segwit, they cannot avoid receiving UTXOs that were previously encumbered by a segwit output. However, it was suggested that continuing with a lower bandwidth cap and keeping coins "untainted" could be an experiment worth considering.Another point raised in the discussion was the desire to disable enforcement of segwit rules. It was explained that individuals cannot control the collective action of the bitcoin ecosystem to start enforcing the rules after a sufficient number of miners signal support. Disabling segwit enforcement could result in accepting blocks that nobody else in the network would accept, leading to a higher risk of double spends.The reasons for not wanting to run a segwit compliant node were also discussed. One reason mentioned was the potential increase in bandwidth requirements for segwit transactions. It was suggested that those not interested in segwit transactions may prefer to keep their node lower-cost by running a non-segwit node. However, it was noted that if the majority of the network adopts segwit, it would be in their best interest to validate those transactions.In summary, the conversation on the bitcoin-dev mailing list revolved around the issue of disabling segwit activation and the implications of not upgrading to a segwit compliant node. Various concerns and suggestions were raised regarding security, validation, bandwidth requirements, and maintaining backward compatibility. The discussion provided different perspectives and considerations for users who may be interested in or hesitant about adopting segwit. 2017-07-14T21:11:07+00:00 + A discussion on the bitcoin-dev mailing list revolved around the issue of disabling segwit activation in Bitcoin Core releases prior to 0.13.1. The conversation began with a user named Dan Libby expressing his desire to avoid segwit activation until he felt comfortable with it. However, Gregory Maxwell pointed out that disabling segwit activation is not a simple task and is also an unsupported configuration. Another respondent criticized Maxwell's attitude, warning that it could lead to Bitcoin Core being dropped and multiple competing implementations emerging.One of the concerns raised by Libby was the difficulty in maintaining and reading the consensus-critical code with segwit, as less than one third of it is visible on-screen. He suggested that users should have the ability to firewall off the code to ensure they are not running segwit. Another issue discussed was the risk for those using legacy clients, as segwit transactions can appear as "anyone-can-spend" outputs from their perspective. This vulnerability creates a risk for "zero confirm" transactions. One proposed solution was to avoid any transaction chain that contains a segwit transaction, but this would require everyone they transact with to follow the same rule.The conversation then shifted to the topic of achieving full security in bitcoin transactions. The recipient expressed uncertainty about how to achieve this, given that anyone they have transacted with can send them coins at any time. One option suggested was to run a node that has never published an address to a third party. Another option was to modify their own node to reject segwit transactions, but this would hardfork the network. It was also mentioned that it may be possible to construct a "certain balance" and an "uncertain balance" without modifying any rules.Hampus Sjöberg provided further clarification, explaining that there are two ways to be fully secure regarding chain transactions. The first option is to validate using the new rules of the network by running a segwit node. The second option is to avoid any transaction chain that contains a segwit transaction. He explained that the witness program in segwit transactions is encoded in a new format that old nodes do not understand, so for old nodes, a number greater than zero will be counted as a valid spend.The implications of not upgrading to a segwit compliant node were discussed. It was noted that if the majority of the network adopts segwit, non-segwit nodes would be downgraded to near-SPV node validation and may not be able to fully verify the ownership of bitcoins. It was also mentioned that even if one does not upgrade to segwit, they cannot avoid receiving UTXOs that were previously encumbered by a segwit output. However, it was suggested that continuing with a lower bandwidth cap and keeping coins "untainted" could be an experiment worth considering.Another point raised in the discussion was the desire to disable enforcement of segwit rules. It was explained that individuals cannot control the collective action of the bitcoin ecosystem to start enforcing the rules after a sufficient number of miners signal support. Disabling segwit enforcement could result in accepting blocks that nobody else in the network would accept, leading to a higher risk of double spends.The reasons for not wanting to run a segwit compliant node were also discussed. One reason mentioned was the potential increase in bandwidth requirements for segwit transactions. It was suggested that those not interested in segwit transactions may prefer to keep their node lower-cost by running a non-segwit node. However, it was noted that if the majority of the network adopts segwit, it would be in their best interest to validate those transactions.In summary, the conversation on the bitcoin-dev mailing list revolved around the issue of disabling segwit activation and the implications of not upgrading to a segwit compliant node. Various concerns and suggestions were raised regarding security, validation, bandwidth requirements, and maintaining backward compatibility. The discussion provided different perspectives and considerations for users who may be interested in or hesitant about adopting segwit. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_A-BIP-proposal-for-segwit-addresses.xml b/static/bitcoin-dev/July_2018/combined_A-BIP-proposal-for-segwit-addresses.xml index a4586bc3d9..391992edb1 100644 --- a/static/bitcoin-dev/July_2018/combined_A-BIP-proposal-for-segwit-addresses.xml +++ b/static/bitcoin-dev/July_2018/combined_A-BIP-proposal-for-segwit-addresses.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - A BIP proposal for segwit addresses - 2023-08-01T19:50:37.233258+00:00 - - Russell O'Connor 2018-07-26 14:31:30+00:00 - - - Russell O'Connor 2018-07-26 13:43:19+00:00 - - - Pieter Wuille 2017-05-20 20:13:13+00:00 - - - Peter Todd 2017-05-07 22:34:29+00:00 - - - Pieter Wuille 2017-05-07 21:39:14+00:00 - - - Lucas Ontivero 2017-03-30 04:50:54+00:00 - - - Andreas Schildbach 2017-03-29 10:07:40+00:00 - - - Peter Todd 2017-03-21 19:14:54+00:00 - - - Andreas Schildbach 2017-03-21 16:16:30+00:00 - - - Pieter Wuille 2017-03-20 21:35:08+00:00 - + 2025-09-26T15:49:38.881599+00:00 + python-feedgen + + + [bitcoin-dev] A BIP proposal for segwit addresses Pieter Wuille + 2017-03-20T21:35:00.000Z + + + Andreas Schildbach + 2017-03-21T16:16:00.000Z + + + Peter Todd + 2017-03-21T19:14:00.000Z + + + Andreas Schildbach + 2017-03-29T10:07:00.000Z + + + Lucas Ontivero + 2017-03-30T04:50:00.000Z + + + Pieter Wuille + 2017-05-07T21:39:00.000Z + + + Peter Todd + 2017-05-07T22:34:00.000Z + + + Pieter Wuille + 2017-05-20T20:13:00.000Z + + + Russell O'Connor + 2018-07-26T13:43:00.000Z + + + Russell O'Connor + 2018-07-26T14:31:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - A BIP proposal for segwit addresses - 2023-08-01T19:50:37.233258+00:00 + 2025-09-26T15:49:38.882833+00:00 - In an email exchange, Russell O'Connor suggested adding a note to the BIP (Bitcoin Improvement Proposal) stating that the Human Readable Part (HRP) should be specified in lowercase or at least mentioning that uppercase and lowercase HRPs are considered equivalent and will be converted to lowercase during validation. The HRP is required to contain 1 to 83 US-ASCII characters, with each character having a value in the range of 33-126, and its validity may be further restricted by specific applications. Bech32, which is used for encoding BTC addresses, forbids mixed-case and converts everything to lowercase, so it is advisable to warn against using uppercase in the HRP. This change would not be normative.Pieter Wuille has requested a BIP number assignment for his proposal, which is available on GitHub under the name BIP173. The proposal aims to introduce a commonly recognizable format for BTC addresses that has good properties for all use cases. It emphasizes the importance of addressing all places where humans interact with addresses, including voice transmission and QR codes. However, compactness is not the primary goal of the BIP.The discussion on the Bitcoin-dev mailing list centered around the ability of non-native English speakers to communicate BTC addresses with English speakers. Peter Todd explained that it is not a binary issue as some non-native speakers may know how to pronounce numbers or alphabetical characters but not special characters. Two new reference implementations (Haskell and Rust) have been contributed recently, and C++ and Go implementations are in progress. Peter Todd also shared his experience of implementing Bech32 encoding for a non-BTC use-case and found it straightforward.The writer is considering whether to respond to a mail list or make a comment in a commit file. They discuss the motivation behind this, which is the lack of support for big numbers in most programming languages when performing mathematical operations required by BIP58. The writer also questions the need for a new encoding format and raises concerns about potential confusion. They note that if a new type of address can be encoded with Bech32 in the future, a new address type may be needed regardless. They argue against using non-alphanumeric characters in addresses for certain contexts, such as filenames, and suggest using something like "Base 64url" or ideally Base 94 for shorter QR codes.In a recent discussion on the Bitcoin-dev mailing list, Andreas Schildbach suggested using Base 43 for QR code encoding in Bitcoin Wallet to make addresses shorter. However, Peter Todd responded with concerns about the downsides of using non-alphanumeric characters in addresses, such as making them difficult to use in various contexts and not being familiar to non-English speaking users. He also questioned the need for transmitting addresses via voice communication. Todd further explained that when used for URLs, Base 32 (as well as Base 43) actually makes QR codes bigger due to the characters used for URL parameters. To make them shorter, he suggested using something like "Base 64url" or preferably Base 94 which includes all printable ASCII characters.Andreas Schildbach's suggestion of using Base 43 for QR code encoding in Bitcoin Wallet to shorten addresses may not be efficient due to the downsides associated with non-alphanumeric characters. These characters can complicate usage in different contexts and may not be familiar to non-English-speaking users. The suggestion was made as an alternative to using Base 32, which is seen as less efficient than the QR code alphanumeric mode that accommodates 44 characters. Peter Todd advises reviewing the "Rational" section of the BIP for more details.Pieter Wuille proposed a new BIP for native SegWit addresses to replace BIP 142 on March 20, 2017. These addresses are optional but offer better efficiency, flexibility, and user-friendliness. The format uses a simple checksum algorithm with strong error detection properties and is based on Base 32 encoding. Reference code in several languages, as well as a website demonstrating it, are included. The text of the proposal can be found on GitHub.Pieter's proposal for native SegWit addresses aims to replace the current BIP 142. These addresses, while not required for SegWit, provide improved efficiency, flexibility, and user-friendliness. They utilize a base 32 encoding format with a simple checksum algorithm that ensures strong error detection. The proposal includes reference code in multiple programming languages and a website for demonstration purposes. The full text of the proposal can be accessed on GitHub. 2018-07-26T14:31:30+00:00 + In an email exchange, Russell O'Connor suggested adding a note to the BIP (Bitcoin Improvement Proposal) stating that the Human Readable Part (HRP) should be specified in lowercase or at least mentioning that uppercase and lowercase HRPs are considered equivalent and will be converted to lowercase during validation. The HRP is required to contain 1 to 83 US-ASCII characters, with each character having a value in the range of 33-126, and its validity may be further restricted by specific applications. Bech32, which is used for encoding BTC addresses, forbids mixed-case and converts everything to lowercase, so it is advisable to warn against using uppercase in the HRP. This change would not be normative.Pieter Wuille has requested a BIP number assignment for his proposal, which is available on GitHub under the name BIP173. The proposal aims to introduce a commonly recognizable format for BTC addresses that has good properties for all use cases. It emphasizes the importance of addressing all places where humans interact with addresses, including voice transmission and QR codes. However, compactness is not the primary goal of the BIP.The discussion on the Bitcoin-dev mailing list centered around the ability of non-native English speakers to communicate BTC addresses with English speakers. Peter Todd explained that it is not a binary issue as some non-native speakers may know how to pronounce numbers or alphabetical characters but not special characters. Two new reference implementations (Haskell and Rust) have been contributed recently, and C++ and Go implementations are in progress. Peter Todd also shared his experience of implementing Bech32 encoding for a non-BTC use-case and found it straightforward.The writer is considering whether to respond to a mail list or make a comment in a commit file. They discuss the motivation behind this, which is the lack of support for big numbers in most programming languages when performing mathematical operations required by BIP58. The writer also questions the need for a new encoding format and raises concerns about potential confusion. They note that if a new type of address can be encoded with Bech32 in the future, a new address type may be needed regardless. They argue against using non-alphanumeric characters in addresses for certain contexts, such as filenames, and suggest using something like "Base 64url" or ideally Base 94 for shorter QR codes.In a recent discussion on the Bitcoin-dev mailing list, Andreas Schildbach suggested using Base 43 for QR code encoding in Bitcoin Wallet to make addresses shorter. However, Peter Todd responded with concerns about the downsides of using non-alphanumeric characters in addresses, such as making them difficult to use in various contexts and not being familiar to non-English speaking users. He also questioned the need for transmitting addresses via voice communication. Todd further explained that when used for URLs, Base 32 (as well as Base 43) actually makes QR codes bigger due to the characters used for URL parameters. To make them shorter, he suggested using something like "Base 64url" or preferably Base 94 which includes all printable ASCII characters.Andreas Schildbach's suggestion of using Base 43 for QR code encoding in Bitcoin Wallet to shorten addresses may not be efficient due to the downsides associated with non-alphanumeric characters. These characters can complicate usage in different contexts and may not be familiar to non-English-speaking users. The suggestion was made as an alternative to using Base 32, which is seen as less efficient than the QR code alphanumeric mode that accommodates 44 characters. Peter Todd advises reviewing the "Rational" section of the BIP for more details.Pieter Wuille proposed a new BIP for native SegWit addresses to replace BIP 142 on March 20, 2017. These addresses are optional but offer better efficiency, flexibility, and user-friendliness. The format uses a simple checksum algorithm with strong error detection properties and is based on Base 32 encoding. Reference code in several languages, as well as a website demonstrating it, are included. The text of the proposal can be found on GitHub.Pieter's proposal for native SegWit addresses aims to replace the current BIP 142. These addresses, while not required for SegWit, provide improved efficiency, flexibility, and user-friendliness. They utilize a base 32 encoding format with a simple checksum algorithm that ensures strong error detection. The proposal includes reference code in multiple programming languages and a website for demonstration purposes. The full text of the proposal can be accessed on GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_An-efficient-re-implementation-of-Electrum-Server-in-Rust.xml b/static/bitcoin-dev/July_2018/combined_An-efficient-re-implementation-of-Electrum-Server-in-Rust.xml index f19e660be7..e5de4f58d5 100644 --- a/static/bitcoin-dev/July_2018/combined_An-efficient-re-implementation-of-Electrum-Server-in-Rust.xml +++ b/static/bitcoin-dev/July_2018/combined_An-efficient-re-implementation-of-Electrum-Server-in-Rust.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - An efficient re-implementation of Electrum Server in Rust - 2023-08-01T23:32:52.402780+00:00 - - Jim Posen 2018-07-05 21:35:39+00:00 - - - Roman Zeyde 2018-07-02 20:03:01+00:00 - + 2025-09-26T15:49:47.302951+00:00 + python-feedgen + + + [bitcoin-dev] An efficient re-implementation of Electrum Server in Rust Roman Zeyde + 2018-07-02T20:03:00.000Z + + + Jim Posen + 2018-07-05T21:35:00.000Z + + - python-feedgen + 2 Combined summary - An efficient re-implementation of Electrum Server in Rust - 2023-08-01T23:32:52.403780+00:00 + 2025-09-26T15:49:47.303399+00:00 - A new project developed by Roman Zeyde allows users to run their own Electrum server with minimal hardware resources, enabling them to keep track of their balances and transaction history in real-time. By running the server on the user's machine, there is no need for the wallet to communicate with external Electrum servers, ensuring the privacy of the user's addresses and balances. The project supports the latest Electrum protocol and indexes the entire Bitcoin blockchain, allowing for fast queries for any given user wallet. The project boasts several features that make it efficient and user-friendly. It maintains an index of transaction inputs and outputs, enabling fast balance queries. It also offers a fast synchronization of the Bitcoin blockchain on modest hardware, low CPU and memory usage, as well as an efficient mempool tracker for better fee estimation. It does not require the `-txindex` option for the Bitcoin node and uses a single RocksDB database for improved consistency and crash recovery.The code and usage instructions for the project can be found on GitHub, where users can also find links to similar projects such as ElectrumX, Electrum Personal Server, and bitcoincore-indexd. The project encourages pull requests, suggestions, and questions from the community, indicating a commitment to ongoing development and improvement.Overall, this project provides a valuable solution for individuals seeking to maintain their privacy while monitoring their Bitcoin transactions. 2018-07-05T21:35:39+00:00 + A new project developed by Roman Zeyde allows users to run their own Electrum server with minimal hardware resources, enabling them to keep track of their balances and transaction history in real-time. By running the server on the user's machine, there is no need for the wallet to communicate with external Electrum servers, ensuring the privacy of the user's addresses and balances. The project supports the latest Electrum protocol and indexes the entire Bitcoin blockchain, allowing for fast queries for any given user wallet. The project boasts several features that make it efficient and user-friendly. It maintains an index of transaction inputs and outputs, enabling fast balance queries. It also offers a fast synchronization of the Bitcoin blockchain on modest hardware, low CPU and memory usage, as well as an efficient mempool tracker for better fee estimation. It does not require the `-txindex` option for the Bitcoin node and uses a single RocksDB database for improved consistency and crash recovery.The code and usage instructions for the project can be found on GitHub, where users can also find links to similar projects such as ElectrumX, Electrum Personal Server, and bitcoincore-indexd. The project encourages pull requests, suggestions, and questions from the community, indicating a commitment to ongoing development and improvement.Overall, this project provides a valuable solution for individuals seeking to maintain their privacy while monitoring their Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_BIP-174-thoughts.xml b/static/bitcoin-dev/July_2018/combined_BIP-174-thoughts.xml index 17c311b08d..eb576655d0 100644 --- a/static/bitcoin-dev/July_2018/combined_BIP-174-thoughts.xml +++ b/static/bitcoin-dev/July_2018/combined_BIP-174-thoughts.xml @@ -1,170 +1,231 @@ - + 2 Combined summary - BIP 174 thoughts - 2023-08-01T23:28:42.591997+00:00 - - Gregory Maxwell 2018-07-11 20:05:32+00:00 - - - Pieter Wuille 2018-07-11 18:27:11+00:00 - - - matejcik 2018-07-10 12:10:10+00:00 - - - Achow101 2018-07-06 18:59:50+00:00 - - - Pieter Wuille 2018-07-05 22:06:53+00:00 - - - William Casarin 2018-07-05 19:20:32+00:00 - - - Jason Les 2018-07-05 17:23:51+00:00 - - - matejcik 2018-07-05 11:52:02+00:00 - - - Pieter Wuille 2018-07-04 19:09:29+00:00 - - - Achow101 2018-07-04 18:35:16+00:00 - - - matejcik 2018-07-04 13:19:11+00:00 - - - Peter D. Gray 2018-06-29 20:31:21+00:00 - - - Achow101 2018-06-29 19:12:27+00:00 - - - matejcik 2018-06-29 09:53:34+00:00 - - - Rodolfo Novak 2018-06-28 20:42:09+00:00 - - - Achow101 2018-06-27 17:55:59+00:00 - - - Pieter Wuille 2018-06-27 15:06:39+00:00 - - - matejcik 2018-06-27 14:11:49+00:00 - - - matejcik 2018-06-27 14:04:06+00:00 - - - Andrea 2018-06-27 13:39:02+00:00 - - - William Casarin 2018-06-27 06:09:09+00:00 - - - Achow101 2018-06-26 21:56:26+00:00 - - - Pieter Wuille 2018-06-26 20:30:04+00:00 - - - Marek Palatinus 2018-06-26 17:11:05+00:00 - - - William Casarin 2018-06-26 16:58:18+00:00 - - - matejcik 2018-06-26 15:33:14+00:00 - - - Achow101 2018-06-25 20:30:28+00:00 - - - Jonas Schnelli 2018-06-25 20:10:12+00:00 - - - Tomas Susanka 2018-06-25 19:47:59+00:00 - - - Andrea 2018-06-24 09:00:53+00:00 - - - Andrew Chow 2018-06-24 08:28:26+00:00 - - - Andrea 2018-06-24 08:19:00+00:00 - - - Andrew Chow 2018-06-23 20:33:11+00:00 - - - Peter D. Gray 2018-06-23 18:27:15+00:00 - - - William Casarin 2018-06-23 17:00:18+00:00 - - - Achow101 2018-06-22 22:28:33+00:00 - - - Pieter Wuille 2018-06-22 19:10:15+00:00 - - - Gregory Maxwell 2018-06-21 21:39:20+00:00 - - - Peter D. Gray 2018-06-21 20:28:15+00:00 - - - Peter D. Gray 2018-06-21 19:56:54+00:00 - - - Pieter Wuille 2018-06-21 17:39:57+00:00 - - - Greg Sanders 2018-06-21 15:40:04+00:00 - - - Tomas Susanka 2018-06-21 14:32:07+00:00 - - - Tomas Susanka 2018-06-21 11:44:37+00:00 - - - matejcik 2018-06-21 11:29:44+00:00 - - - Achow101 2018-06-21 00:39:05+00:00 - - - Jason Les 2018-06-20 00:39:46+00:00 - - - Pieter Wuille 2018-06-19 17:16:51+00:00 - - - Jonas Schnelli 2018-06-19 15:20:34+00:00 - - - matejcik 2018-06-19 14:22:30+00:00 - - - matejcik 2018-06-19 14:20:03+00:00 - - - Jonas Schnelli 2018-06-19 09:38:24+00:00 - - - Peter D. Gray 2018-06-16 15:00:40+00:00 - - - Pieter Wuille 2018-06-15 23:34:40+00:00 - + 2025-09-26T15:49:59.981601+00:00 + python-feedgen + + + [bitcoin-dev] BIP 174 thoughts Pieter Wuille + 2018-06-15T23:34:00.000Z + + + Peter D. Gray + 2018-06-16T15:00:00.000Z + + + Jonas Schnelli + 2018-06-19T09:38:00.000Z + + + matejcik + 2018-06-19T14:20:00.000Z + + + matejcik + 2018-06-19T14:22:00.000Z + + + Jonas Schnelli + 2018-06-19T15:20:00.000Z + + + Pieter Wuille + 2018-06-19T17:16:00.000Z + + + Jason Les + 2018-06-20T00:39:00.000Z + + + Achow101 + 2018-06-21T00:39:00.000Z + + + matejcik + 2018-06-21T11:29:00.000Z + + + Tomas Susanka + 2018-06-21T11:44:00.000Z + + + Tomas Susanka + 2018-06-21T14:32:00.000Z + + + Greg Sanders + 2018-06-21T15:40:00.000Z + + + Pieter Wuille + 2018-06-21T17:39:00.000Z + + + Peter D. Gray + 2018-06-21T19:56:00.000Z + + + Peter D. Gray + 2018-06-21T20:28:00.000Z + + + Gregory Maxwell + 2018-06-21T21:39:00.000Z + + + Pieter Wuille + 2018-06-22T19:10:00.000Z + + + Achow101 + 2018-06-22T22:28:00.000Z + + + William Casarin + 2018-06-23T17:00:00.000Z + + + Peter D. Gray + 2018-06-23T18:27:00.000Z + + + Andrew Chow + 2018-06-23T20:33:00.000Z + + + Andrea + 2018-06-24T08:19:00.000Z + + + Andrew Chow + 2018-06-24T08:28:00.000Z + + + Andrea + 2018-06-24T09:00:00.000Z + + + Tomas Susanka + 2018-06-25T19:47:00.000Z + + + Jonas Schnelli + 2018-06-25T20:10:00.000Z + + + Achow101 + 2018-06-25T20:30:00.000Z + + + matejcik + 2018-06-26T15:33:00.000Z + + + William Casarin + 2018-06-26T16:58:00.000Z + + + Marek Palatinus + 2018-06-26T17:11:00.000Z + + + Pieter Wuille + 2018-06-26T20:30:00.000Z + + + [bitcoin-dev] BIP 174 thoughts Achow101 + 2018-06-26T21:56:00.000Z + + + William Casarin + 2018-06-27T06:09:00.000Z + + + Andrea + 2018-06-27T13:39:00.000Z + + + matejcik + 2018-06-27T14:04:00.000Z + + + matejcik + 2018-06-27T14:11:00.000Z + + + Pieter Wuille + 2018-06-27T15:06:00.000Z + + + Achow101 + 2018-06-27T17:55:00.000Z + + + Rodolfo Novak + 2018-06-28T20:42:00.000Z + + + matejcik + 2018-06-29T09:53:00.000Z + + + Achow101 + 2018-06-29T19:12:00.000Z + + + Peter D. Gray + 2018-06-29T20:31:00.000Z + + + matejcik + 2018-07-04T13:19:00.000Z + + + Achow101 + 2018-07-04T18:35:00.000Z + + + Pieter Wuille + 2018-07-04T19:09:00.000Z + + + matejcik + 2018-07-05T11:52:00.000Z + + + Jason Les + 2018-07-05T17:23:00.000Z + + + William Casarin + 2018-07-05T19:20:00.000Z + + + Pieter Wuille + 2018-07-05T22:06:00.000Z + + + Achow101 + 2018-07-06T18:59:00.000Z + + + matejcik + 2018-07-10T12:10:00.000Z + + + Pieter Wuille + 2018-07-11T18:27:00.000Z + + + Gregory Maxwell + 2018-07-11T20:05:00.000Z + + + [bitcoin-dev] BIP 174 thoughts on graphics vv01f + 2018-07-11T20:54:00.000Z + + @@ -219,13 +280,13 @@ - python-feedgen + 2 Combined summary - BIP 174 thoughts - 2023-08-01T23:28:42.592994+00:00 + 2025-09-26T15:49:59.986980+00:00 - The discussion among Bitcoin developers regarding the policy for signing Bitcoin transactions with extra metadata has raised concerns about the potential difficulty of implementing new features that require extra data. The fear is that if signers are allowed to refuse to sign because of extra fields, it would create pressure to find places to stuff the extra data where it won't interfere with already deployed signers. This would be unfortunate as PSBT was created specifically to avoid field stuffing.In a recent email exchange among developers, it was suggested to add a statement to the Partially Signed Bitcoin Transaction (PSBT) specification to explain that the result of combining two PSBTs from independent participants should be functionally equivalent to processing the original PSBT by A and then B in a sequence. The rationale behind this is that Combiners can always be replaced with just a different topology of data flow. In terms of conflicts between values, the Combiner which picks arbitrarily will not end up with something worse than what is already needed to deal with.The discussion revolves around the possibility of malicious conflicting values in a scenario where one signer produces an invalid signature or modifies any of the other fields already present in the PSBT for consumption by others. It is believed that combiners can always be replaced with just a different topology of data flow since it does not make a difference. The Combiner, which picks arbitrarily in case of conflicts, will never end up with something worse than what one already needs to deal with.In an email thread between Andrew, William Casarin and Jason Les, William expressed concern about the format of parsing key-value maps arrays. He stated that "you can only parse the format properly by first deserializing the transaction. Since there is no 'length' field for the key-value map arrays, you must count the number of transaction input/outputs and use that as the number of kv maps to parse." However, Andrew disagreed and stated that this was not a problem since almost all roles have to deserialize the unsigned tx before they can do anything.The conversation revolves around the safety concerns of allowing combiners to arbitrarily choose a value. It is stated that conflicts in UTXOs, sighash type, redeem/witness scripts, derivation paths, etc. can cause recoverable or unrecoverable errors and sometimes indicate malicious activity. The safest option is to reject conflicts but allow intelligent processing by combiners if they understand the relevant fields.The concern raised in this context is regarding the format of PSBT (partially signed Bitcoin transaction). The writer points out that the format is confusing and can only be parsed by deserializing the transaction. They explain that there is no "length" field for the key-value map arrays, which means that the number of kv maps to parse must be counted based on the number of transaction input/outputs. This process is brittle because if a Combiner writes the wrong number of key-value maps that do not align with the number of inputs and outputs in the transaction, then the PSBT will not be able to be deserialized properly, but it will still be a valid PSBT.There has been a suggestion to standardize file names used when creating .psbt files to ensure reliability and avoid collisions. This would involve using an 8 character trim of the hash of the unsigned transaction, followed by the role that created the file (such as 'Signer'), and then a 4 character trim of the hash of data unique to that role (such as 'partial sig').In a discussion surrounding the Bitcoin wallet standard, Partially Signed Bitcoin Transactions (PSBT), contributors debated whether or not to allow combiners to choose any value in cases of conflicts within the transaction. Concerns were raised that conflicts in certain fields could be at best a recoverable error and at worst malicious activity, making it generally safer to default to rejecting conflicts, and explicitly allowing the Combiner to process them intelligently if it understands the relevant fields.In an email conversation, some concerns have been raised about the strictness and security properties of BIP. The first issue is regarding choosing from duplicate keys when combining. The proposal is to either change the resolution strategy or explain why picking at random is safe. However, outlawing conflicting values would force all signers to implement fixed deterministic nonce generation, which may result in PSBTs that got copied and signed and combined again failing. So, a better approach would be to choose the keys in such a way that picking arbitrarily is safe. Another issue is regarding signing records with unknown keys. It is suggested to codify the behavior in the standard or mark a field as "optional" so that strict signers know they can safely ignore the unknown field. However, there may not be a situation where this is needed, and signers generally inspect transactions they're signing.The email author expresses concerns about the strictness and security properties of Bitcoin Improvement Proposal (BIP). They suggest changing the strategy for choosing from duplicate keys when combining or providing a detailed explanation 2018-07-11T20:05:32+00:00 + The discussion among Bitcoin developers regarding the policy for signing Bitcoin transactions with extra metadata has raised concerns about the potential difficulty of implementing new features that require extra data. The fear is that if signers are allowed to refuse to sign because of extra fields, it would create pressure to find places to stuff the extra data where it won't interfere with already deployed signers. This would be unfortunate as PSBT was created specifically to avoid field stuffing.In a recent email exchange among developers, it was suggested to add a statement to the Partially Signed Bitcoin Transaction (PSBT) specification to explain that the result of combining two PSBTs from independent participants should be functionally equivalent to processing the original PSBT by A and then B in a sequence. The rationale behind this is that Combiners can always be replaced with just a different topology of data flow. In terms of conflicts between values, the Combiner which picks arbitrarily will not end up with something worse than what is already needed to deal with.The discussion revolves around the possibility of malicious conflicting values in a scenario where one signer produces an invalid signature or modifies any of the other fields already present in the PSBT for consumption by others. It is believed that combiners can always be replaced with just a different topology of data flow since it does not make a difference. The Combiner, which picks arbitrarily in case of conflicts, will never end up with something worse than what one already needs to deal with.In an email thread between Andrew, William Casarin and Jason Les, William expressed concern about the format of parsing key-value maps arrays. He stated that "you can only parse the format properly by first deserializing the transaction. Since there is no 'length' field for the key-value map arrays, you must count the number of transaction input/outputs and use that as the number of kv maps to parse." However, Andrew disagreed and stated that this was not a problem since almost all roles have to deserialize the unsigned tx before they can do anything.The conversation revolves around the safety concerns of allowing combiners to arbitrarily choose a value. It is stated that conflicts in UTXOs, sighash type, redeem/witness scripts, derivation paths, etc. can cause recoverable or unrecoverable errors and sometimes indicate malicious activity. The safest option is to reject conflicts but allow intelligent processing by combiners if they understand the relevant fields.The concern raised in this context is regarding the format of PSBT (partially signed Bitcoin transaction). The writer points out that the format is confusing and can only be parsed by deserializing the transaction. They explain that there is no "length" field for the key-value map arrays, which means that the number of kv maps to parse must be counted based on the number of transaction input/outputs. This process is brittle because if a Combiner writes the wrong number of key-value maps that do not align with the number of inputs and outputs in the transaction, then the PSBT will not be able to be deserialized properly, but it will still be a valid PSBT.There has been a suggestion to standardize file names used when creating .psbt files to ensure reliability and avoid collisions. This would involve using an 8 character trim of the hash of the unsigned transaction, followed by the role that created the file (such as 'Signer'), and then a 4 character trim of the hash of data unique to that role (such as 'partial sig').In a discussion surrounding the Bitcoin wallet standard, Partially Signed Bitcoin Transactions (PSBT), contributors debated whether or not to allow combiners to choose any value in cases of conflicts within the transaction. Concerns were raised that conflicts in certain fields could be at best a recoverable error and at worst malicious activity, making it generally safer to default to rejecting conflicts, and explicitly allowing the Combiner to process them intelligently if it understands the relevant fields.In an email conversation, some concerns have been raised about the strictness and security properties of BIP. The first issue is regarding choosing from duplicate keys when combining. The proposal is to either change the resolution strategy or explain why picking at random is safe. However, outlawing conflicting values would force all signers to implement fixed deterministic nonce generation, which may result in PSBTs that got copied and signed and combined again failing. So, a better approach would be to choose the keys in such a way that picking arbitrarily is safe. Another issue is regarding signing records with unknown keys. It is suggested to codify the behavior in the standard or mark a field as "optional" so that strict signers know they can safely ignore the unknown field. However, there may not be a situation where this is needed, and signers generally inspect transactions they're signing.The email author expresses concerns about the strictness and security properties of Bitcoin Improvement Proposal (BIP). They suggest changing the strategy for choosing from duplicate keys when combining or providing a detailed explanation - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml b/static/bitcoin-dev/July_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml index ae34a4ef91..39680f922e 100644 --- a/static/bitcoin-dev/July_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml +++ b/static/bitcoin-dev/July_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml @@ -1,41 +1,47 @@ - + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 - - Giulia Fanti 2018-07-08 12:50:43+00:00 - - - Gregory Maxwell 2018-06-26 05:20:02+00:00 - - - Bradley Denby 2018-06-26 00:12:02+00:00 - - - Pieter Wuille 2018-06-12 01:05:14+00:00 - - - Bradley Denby 2018-06-11 14:31:09+00:00 - - - Pieter Wuille 2018-06-06 04:01:00+00:00 - - - Bradley Denby 2018-06-04 20:29:50+00:00 - - - Bradley Denby 2018-05-10 12:59:12+00:00 - - - Giulia Fanti 2017-09-21 02:10:29+00:00 - - - Gregory Maxwell 2017-06-13 01:00:50+00:00 - - - Andrew Miller 2017-06-12 14:46:23+00:00 - + 2025-09-26T15:49:41.037329+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation Bradley Denby + 2018-05-10T12:59:00.000Z + + + Bradley Denby + 2018-06-04T20:29:00.000Z + + + Pieter Wuille + 2018-06-06T04:01:00.000Z + + + Bradley Denby + 2018-06-11T14:31:00.000Z + + + Pieter Wuille + 2018-06-12T01:05:00.000Z + + + Bradley Denby + 2018-06-26T00:12:00.000Z + + + Gregory Maxwell + 2018-06-26T05:20:00.000Z + + + Neudecker, Till (TM) + 2018-07-05T14:50:00.000Z + + + Giulia Fanti + 2018-07-08T12:50:00.000Z + + @@ -47,13 +53,13 @@ - python-feedgen + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 + 2025-09-26T15:49:41.038414+00:00 - The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality 2018-07-08T12:50:43+00:00 + The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_BIP-sighash-noinput.xml b/static/bitcoin-dev/July_2018/combined_BIP-sighash-noinput.xml index 43f6d8d1b4..5f4277e1cf 100644 --- a/static/bitcoin-dev/July_2018/combined_BIP-sighash-noinput.xml +++ b/static/bitcoin-dev/July_2018/combined_BIP-sighash-noinput.xml @@ -1,110 +1,147 @@ - + 2 Combined summary - BIP sighash_noinput - 2023-08-01T22:58:34.573011+00:00 - - Jonas Nick 2018-09-26 20:40:02+00:00 - - - Johnson Lau 2018-09-26 19:45:49+00:00 - - - Jonas Nick 2018-09-26 09:36:57+00:00 - - - Christian Decker 2018-07-13 11:07:48+00:00 - - - fred savage 2018-07-13 09:50:47+00:00 - - - Rusty Russell 2018-07-13 00:04:14+00:00 - - - ZmnSCPxj 2018-07-11 07:43:49+00:00 - - - Peter Todd 2018-07-09 09:41:39+00:00 - - - vv01f 2018-07-05 08:18:44+00:00 - - - fred savage 2018-07-04 18:08:43+00:00 - - - Gregory Maxwell 2018-07-03 23:45:22+00:00 - - - Luke Dashjr 2018-07-03 12:13:44+00:00 - - - Christian Decker 2018-07-03 12:05:09+00:00 - - - William Casarin 2018-07-03 11:54:37+00:00 - - - ZmnSCPxj 2018-07-03 06:58:36+00:00 - - - Peter Todd 2018-07-03 05:21:00+00:00 - - - Rusty Russell 2018-07-03 04:56:53+00:00 - - - Gregory Maxwell 2018-07-02 18:11:54+00:00 - - - Christian Decker 2018-05-15 14:28:22+00:00 - - - Anthony Towns 2018-05-14 09:23:29+00:00 - - - Christian Decker 2018-05-10 14:12:21+00:00 - - - Rusty Russell 2018-05-09 23:04:58+00:00 - - - Olaoluwa Osuntokun 2018-05-09 23:01:39+00:00 - - - Anthony Towns 2018-05-08 14:40:21+00:00 - - - Olaoluwa Osuntokun 2018-05-07 23:47:23+00:00 - - - Bram Cohen 2018-05-07 20:51:11+00:00 - - - Christian Decker 2018-05-07 19:40:46+00:00 - - - ZmnSCPxj 2018-05-04 14:25:46+00:00 - - - Christian Decker 2018-05-04 11:09:09+00:00 - - - ZmnSCPxj 2018-05-04 09:15:41+00:00 - - - Christian Decker 2018-05-01 17:32:32+00:00 - - - Russell O'Connor 2018-05-01 16:58:37+00:00 - - - Dario Sneidermanis 2018-04-30 18:25:42+00:00 - - - Christian Decker 2018-04-30 16:29:53+00:00 - + 2025-09-26T15:49:36.785117+00:00 + python-feedgen + + + [bitcoin-dev] BIP sighash_noinput Christian Decker + 2018-04-30T16:29:00.000Z + + + Dario Sneidermanis + 2018-04-30T18:25:00.000Z + + + Russell O'Connor + 2018-05-01T16:58:00.000Z + + + Christian Decker + 2018-05-01T17:32:00.000Z + + + ZmnSCPxj + 2018-05-04T09:15:00.000Z + + + Christian Decker + 2018-05-04T11:09:00.000Z + + + ZmnSCPxj + 2018-05-04T14:25:00.000Z + + + Christian Decker + 2018-05-07T19:40:00.000Z + + + Bram Cohen + 2018-05-07T20:51:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2018-05-07T23:47:00.000Z + + + [bitcoin-dev] " Anthony Towns + 2018-05-08T14:40:00.000Z + + + Olaoluwa Osuntokun + 2018-05-09T23:01:00.000Z + + + Rusty Russell + 2018-05-09T23:04:00.000Z + + + Christian Decker + 2018-05-10T14:12:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2018-05-14T09:23:00.000Z + + + Christian Decker + 2018-05-15T14:28:00.000Z + + + Gregory Maxwell + 2018-07-02T18:11:00.000Z + + + Rusty Russell + 2018-07-03T04:56:00.000Z + + + Peter Todd + 2018-07-03T05:21:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2018-07-03T06:58:00.000Z + + + William Casarin + 2018-07-03T11:54:00.000Z + + + Christian Decker + 2018-07-03T12:05:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Luke Dashjr + 2018-07-03T12:13:00.000Z + + + Gregory Maxwell + 2018-07-03T23:45:00.000Z + + + fred savage + 2018-07-04T18:08:00.000Z + + + vv01f + 2018-07-05T08:18:00.000Z + + + Peter Todd + 2018-07-09T09:41:00.000Z + + + ZmnSCPxj + 2018-07-11T07:43:00.000Z + + + Rusty Russell + 2018-07-13T00:04:00.000Z + + + fred savage + 2018-07-13T09:50:00.000Z + + + Christian Decker + 2018-07-13T11:07:00.000Z + + + Jonas Nick + 2018-09-26T09:36:00.000Z + + + Johnson Lau + 2018-09-26T19:45:00.000Z + + + Jonas Nick + 2018-09-26T20:40:00.000Z + + @@ -139,13 +176,13 @@ - python-feedgen + 2 Combined summary - BIP sighash_noinput - 2023-08-01T22:58:34.573011+00:00 + 2025-09-26T15:49:36.788484+00:00 - The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions. Laolu emphasizes the importance of making the proposal small 2018-09-26T20:40:02+00:00 + The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions. Laolu emphasizes the importance of making the proposal small - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_Generalised-taproot.xml b/static/bitcoin-dev/July_2018/combined_Generalised-taproot.xml index fa6758b270..19c39e6017 100644 --- a/static/bitcoin-dev/July_2018/combined_Generalised-taproot.xml +++ b/static/bitcoin-dev/July_2018/combined_Generalised-taproot.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Generalised taproot - 2023-08-01T23:40:05.077900+00:00 + 2025-09-26T15:49:57.830652+00:00 + python-feedgen Pieter Wuille 2018-10-24 02:22:24+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Generalised taproot - 2023-08-01T23:40:05.077900+00:00 + 2025-09-26T15:49:57.830799+00:00 - Pieter Wuille, a Bitcoin Core developer, has introduced a new construction called "g'root" to address the issue of recursive-taproot-without-revealing-intermediary-scripts. This structure combines the concepts of Pedersen Commitments and taproot, resulting in an equation that combines private keys, hashes of additional conditions, and alternative spending methods.The g'root construction eliminates the distinction between pay-to-pubkey and pay-to-script constructions, providing an easy way to create a softfork-safe cross-input aggregation system. It also ensures that any future cross-input signature aggregation system only applies to companion keys that are not susceptible to potential changes in the scripting language.Wuille suggests deploying schnorr/taproot/mast initially, followed by the addition of graftroot/aggregation. Finally, the deployment of generalised taproot alongside graftroot/aggregation is recommended.In addition to this proposal, there is another suggestion for recursive taproot that utilizes Pedersen Commitments. By combining the taproot structure with a second generator in the curve, it becomes possible to create a pubkey point that can be spent either through direct signing or by revealing additional conditions.To maintain secrecy, the proposal allows users to hide whether there are any lower layers until the merkle-tree of scripts is reached. Furthermore, it enables the non-disclosure of conditions corresponding to any keys other than the one being spent with.This proposal is as space-efficient as basic taproot and potentially more efficient than using a merkle tree with taproot when there are three spending paths.To summarize, Pieter Wuille's "g'root" construction and the proposal for recursive taproot with Pedersen Commitments aim to enhance the functionality and efficiency of Bitcoin transactions. These proposals suggest deploying different components such as schnorr/taproot/mast and graftroot/aggregation in a phased manner to ensure a smooth transition. 2018-10-24T02:22:24+00:00 + Pieter Wuille, a Bitcoin Core developer, has introduced a new construction called "g'root" to address the issue of recursive-taproot-without-revealing-intermediary-scripts. This structure combines the concepts of Pedersen Commitments and taproot, resulting in an equation that combines private keys, hashes of additional conditions, and alternative spending methods.The g'root construction eliminates the distinction between pay-to-pubkey and pay-to-script constructions, providing an easy way to create a softfork-safe cross-input aggregation system. It also ensures that any future cross-input signature aggregation system only applies to companion keys that are not susceptible to potential changes in the scripting language.Wuille suggests deploying schnorr/taproot/mast initially, followed by the addition of graftroot/aggregation. Finally, the deployment of generalised taproot alongside graftroot/aggregation is recommended.In addition to this proposal, there is another suggestion for recursive taproot that utilizes Pedersen Commitments. By combining the taproot structure with a second generator in the curve, it becomes possible to create a pubkey point that can be spent either through direct signing or by revealing additional conditions.To maintain secrecy, the proposal allows users to hide whether there are any lower layers until the merkle-tree of scripts is reached. Furthermore, it enables the non-disclosure of conditions corresponding to any keys other than the one being spent with.This proposal is as space-efficient as basic taproot and potentially more efficient than using a merkle tree with taproot when there are three spending paths.To summarize, Pieter Wuille's "g'root" construction and the proposal for recursive taproot with Pedersen Commitments aim to enhance the functionality and efficiency of Bitcoin transactions. These proposals suggest deploying different components such as schnorr/taproot/mast and graftroot/aggregation in a phased manner to ensure a smooth transition. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_Multiparty-signatures.xml b/static/bitcoin-dev/July_2018/combined_Multiparty-signatures.xml index a2483a98bb..e5c762b34d 100644 --- a/static/bitcoin-dev/July_2018/combined_Multiparty-signatures.xml +++ b/static/bitcoin-dev/July_2018/combined_Multiparty-signatures.xml @@ -1,86 +1,115 @@ - + 2 Combined summary - Multiparty signatures - 2023-08-01T23:39:16.191213+00:00 - - Erik Aronesty 2018-07-26 02:05:05+00:00 - - - Erik Aronesty 2018-07-20 20:18:47+00:00 - - - Erik Aronesty 2018-07-20 17:34:29+00:00 - - - Erik Aronesty 2018-07-20 16:25:34+00:00 - - - Russell O'Connor 2018-07-19 13:11:28+00:00 - - - Erik Aronesty 2018-07-19 12:24:39+00:00 - - - Erik Aronesty 2018-07-19 12:16:04+00:00 - - - Erik Aronesty 2018-07-11 14:45:58+00:00 - - - Adam Back 2018-07-11 10:35:08+00:00 - - - Erik Aronesty 2018-07-10 11:46:17+00:00 - - - Erik Aronesty 2018-07-09 17:59:23+00:00 - - - Gregory Maxwell 2018-07-09 16:58:38+00:00 - - - Erik Aronesty 2018-07-09 16:33:01+00:00 - - - Gregory Maxwell 2018-07-09 16:21:59+00:00 - - - Gregory Maxwell 2018-07-09 15:59:28+00:00 - - - Dan Robinson 2018-07-09 15:57:07+00:00 - - - Erik Aronesty 2018-07-09 15:02:30+00:00 - - - Pieter Wuille 2018-07-09 04:39:56+00:00 - - - Erik Aronesty 2018-07-09 04:29:02+00:00 - - - Pieter Wuille 2018-07-09 02:33:06+00:00 - - - Pieter Wuille 2018-07-09 02:29:19+00:00 - - - Erik Aronesty 2018-07-09 00:27:53+00:00 - - - Gregory Maxwell 2018-07-08 21:01:36+00:00 - - - Erik Aronesty 2018-07-08 18:23:45+00:00 - - - Tim Ruffing 2018-07-08 15:16:34+00:00 - - - Erik Aronesty 2018-07-08 14:19:52+00:00 - + 2025-09-26T15:49:49.419874+00:00 + python-feedgen + + + [bitcoin-dev] Multiparty signatures Erik Aronesty + 2018-07-08T14:19:00.000Z + + + Tim Ruffing + 2018-07-08T15:16:00.000Z + + + Erik Aronesty + 2018-07-08T18:23:00.000Z + + + Gregory Maxwell + 2018-07-08T21:01:00.000Z + + + Erik Aronesty + 2018-07-09T00:27:00.000Z + + + Pieter Wuille + 2018-07-09T02:29:00.000Z + + + Pieter Wuille + 2018-07-09T02:33:00.000Z + + + Erik Aronesty + 2018-07-09T04:29:00.000Z + + + Pieter Wuille + 2018-07-09T04:39:00.000Z + + + Erik Aronesty + 2018-07-09T15:02:00.000Z + + + Dan Robinson + 2018-07-09T15:57:00.000Z + + + Gregory Maxwell + 2018-07-09T15:59:00.000Z + + + Gregory Maxwell + 2018-07-09T16:21:00.000Z + + + Erik Aronesty + 2018-07-09T16:33:00.000Z + + + Gregory Maxwell + 2018-07-09T16:58:00.000Z + + + Erik Aronesty + 2018-07-09T17:59:00.000Z + + + Erik Aronesty + 2018-07-10T11:46:00.000Z + + + Adam Back + 2018-07-11T10:35:00.000Z + + + Erik Aronesty + 2018-07-11T14:45:00.000Z + + + Erik Aronesty + 2018-07-19T12:16:00.000Z + + + Erik Aronesty + 2018-07-19T12:24:00.000Z + + + Russell O'Connor + 2018-07-19T13:11:00.000Z + + + Erik Aronesty + 2018-07-20T16:25:00.000Z + + + Erik Aronesty + 2018-07-20T17:34:00.000Z + + + Erik Aronesty + 2018-07-20T20:18:00.000Z + + + Erik Aronesty + 2018-07-26T02:05:00.000Z + + @@ -107,13 +136,13 @@ - python-feedgen + 2 Combined summary - Multiparty signatures - 2023-08-01T23:39:16.192221+00:00 + 2025-09-26T15:49:49.422378+00:00 - The email conversation discusses the implementation of an M-of-N "single sig" extension of MuSig without the need for new opcodes. The solution involves using MuSig's blinding factor solution and interpolation to achieve M-of-N instead of M-of-M.Each party publishes a public key and a random nonce. The x coordinate is used for interpolation purposes, while R is derived from the interpolation of G*k1, G*k2... L is obtained from H(X1,X2,...), and X is the sum of all H(L,Xi)Xi. E (a blinding factor) is computed as H(R | M | X), with si being a share of the signature and xi being the private data. (si, e) are then published as the share signature. To prevent a birthday attack on k, e2 is introduced as a second blinding factor, and (si, e, e2) is published as the share signature. Finally, any party can derive s from m of n shares by interpolating, not adding.The author of the message expresses gratitude for assistance and provides a summary of the solution arrived at for an M of N "single sig" extension of MuSig, which involves using MuSig's blinding solution to solve the Wagner attack and interpolation to enhance MuSig to be M of N instead of M of M. The process involves each party publishing public key G*xi, computing Xi and r, and deriving e and si for each participant. Any party can derive s from m of n shares by interpolating rather than adding. The references used include MuSig and HomPrf.The conversation is discussing the musig construction and how it can be used in m of n multisig. The musig construction involves hashing all keys and summing the multiples to compute the shared blinding factor, which improves the system. This results in a nice Shamir m of n multisig with a single signature and all the same properties otherwise. In response to this, Russell O'Connor raises a concern about multiparty signature attacks where an attacker can modify more than one variable. In a coin-join protocol where every other participant could be the same attacker representing themselves as multiple participants, the attacker can get their hands on multiple variables.In a discussion on bitcoin-dev mailing list, Erik Aronesty raised the question of whether or not it is possible to use the birthday attack where there is only one variable to modify. He argued that in a multiparty signature, an attacker can have more than one variable to modify. In such cases, the attacker could be representing themselves as multiple participants and thus have access to multiple variables. This scenario can arise in coin-join protocols where every other participant in the multi-party signature might actually be the same single attacker.The context describes a discussion between individuals regarding the security of a bitcoin private key. The conversation revolves around the idea of a secure multiparty computation (SMC) of a signature being more secure overall than other methods. However, there is some uncertainty about how to do it offline and all parties need to agree on the blinding factor. The conversation then shifts towards the applicability of Wagner's algorithm in this scenario. It is mentioned that adaptively chosen public keys can be dangerous and easily exploited, but using hash(pub) as X prevents this attack. Ultimately, the discussion centers around the security of Shamir secret sharing interpolation and how it prevents attacks on the multisig construction.The discussion revolves around the security of Shamir secret sharing and the adaptability of Wagner's algorithm in the multisig construction. The writer argues that Wagner's algorithm is not applicable due to the inability to birthday attack something where there is only a single variable that can be modified. Additionally, with an additive construction adaptive attacks are possible, but there is no mechanism for a birthday attack on k in this revised solution.A new threshold multi-signature scheme has been proposed that offers a simpler mechanism compared to musig and aligns more closely with the original Schnorr construction. In this scheme, each party has a public key g*x', where x' is their private key, and rolls a random k' to compute r' = g*k'. The share of r' is broadcasted, and lagrange interpolation is used to compute g*k across shares. Verification follows the same process as Schnorr, but interpolation is used to obtain the necessary components (s, e, g*x') from shares of s', e', and g*x'. The security assumptions are based on Shamir + discrete log.The proposed construction allows for offline production of multisig signatures, with each device generating its own k-share and x-share. Only the interpolation of M out of n shares is required, eliminating the need for round trips. It is important to prove that H(M) * r does not reveal any information about k, relying on the same discrete logarithm assumptions as Bitcoin itself. This construction has fewer moving parts than musig and potentially a smaller 2018-07-26T02:05:05+00:00 + The email conversation discusses the implementation of an M-of-N "single sig" extension of MuSig without the need for new opcodes. The solution involves using MuSig's blinding factor solution and interpolation to achieve M-of-N instead of M-of-M.Each party publishes a public key and a random nonce. The x coordinate is used for interpolation purposes, while R is derived from the interpolation of G*k1, G*k2... L is obtained from H(X1,X2,...), and X is the sum of all H(L,Xi)Xi. E (a blinding factor) is computed as H(R | M | X), with si being a share of the signature and xi being the private data. (si, e) are then published as the share signature. To prevent a birthday attack on k, e2 is introduced as a second blinding factor, and (si, e, e2) is published as the share signature. Finally, any party can derive s from m of n shares by interpolating, not adding.The author of the message expresses gratitude for assistance and provides a summary of the solution arrived at for an M of N "single sig" extension of MuSig, which involves using MuSig's blinding solution to solve the Wagner attack and interpolation to enhance MuSig to be M of N instead of M of M. The process involves each party publishing public key G*xi, computing Xi and r, and deriving e and si for each participant. Any party can derive s from m of n shares by interpolating rather than adding. The references used include MuSig and HomPrf.The conversation is discussing the musig construction and how it can be used in m of n multisig. The musig construction involves hashing all keys and summing the multiples to compute the shared blinding factor, which improves the system. This results in a nice Shamir m of n multisig with a single signature and all the same properties otherwise. In response to this, Russell O'Connor raises a concern about multiparty signature attacks where an attacker can modify more than one variable. In a coin-join protocol where every other participant could be the same attacker representing themselves as multiple participants, the attacker can get their hands on multiple variables.In a discussion on bitcoin-dev mailing list, Erik Aronesty raised the question of whether or not it is possible to use the birthday attack where there is only one variable to modify. He argued that in a multiparty signature, an attacker can have more than one variable to modify. In such cases, the attacker could be representing themselves as multiple participants and thus have access to multiple variables. This scenario can arise in coin-join protocols where every other participant in the multi-party signature might actually be the same single attacker.The context describes a discussion between individuals regarding the security of a bitcoin private key. The conversation revolves around the idea of a secure multiparty computation (SMC) of a signature being more secure overall than other methods. However, there is some uncertainty about how to do it offline and all parties need to agree on the blinding factor. The conversation then shifts towards the applicability of Wagner's algorithm in this scenario. It is mentioned that adaptively chosen public keys can be dangerous and easily exploited, but using hash(pub) as X prevents this attack. Ultimately, the discussion centers around the security of Shamir secret sharing interpolation and how it prevents attacks on the multisig construction.The discussion revolves around the security of Shamir secret sharing and the adaptability of Wagner's algorithm in the multisig construction. The writer argues that Wagner's algorithm is not applicable due to the inability to birthday attack something where there is only a single variable that can be modified. Additionally, with an additive construction adaptive attacks are possible, but there is no mechanism for a birthday attack on k in this revised solution.A new threshold multi-signature scheme has been proposed that offers a simpler mechanism compared to musig and aligns more closely with the original Schnorr construction. In this scheme, each party has a public key g*x', where x' is their private key, and rolls a random k' to compute r' = g*k'. The share of r' is broadcasted, and lagrange interpolation is used to compute g*k across shares. Verification follows the same process as Schnorr, but interpolation is used to obtain the necessary components (s, e, g*x') from shares of s', e', and g*x'. The security assumptions are based on Shamir + discrete log.The proposed construction allows for offline production of multisig signatures, with each device generating its own k-share and x-share. Only the interpolation of M out of n shares is required, eliminating the need for round trips. It is important to prove that H(M) * r does not reveal any information about k, relying on the same discrete logarithm assumptions as Bitcoin itself. This construction has fewer moving parts than musig and potentially a smaller - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_SIGHASH2-for-version-1-witness-programme.xml b/static/bitcoin-dev/July_2018/combined_SIGHASH2-for-version-1-witness-programme.xml index c9d7619994..35b5125342 100644 --- a/static/bitcoin-dev/July_2018/combined_SIGHASH2-for-version-1-witness-programme.xml +++ b/static/bitcoin-dev/July_2018/combined_SIGHASH2-for-version-1-witness-programme.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 - - Christian Decker 2018-09-03 13:53:33+00:00 - - - Johnson Lau 2018-08-31 07:42:07+00:00 - - - Christian Decker 2018-08-30 20:51:15+00:00 - - - Johnson Lau 2018-08-30 20:38:06+00:00 - - - Gregory Maxwell 2018-07-02 18:23:48+00:00 - - - Johnson Lau 2018-06-01 18:45:57+00:00 - - - Russell O'Connor 2018-06-01 18:15:32+00:00 - - - Johnson Lau 2018-06-01 17:03:05+00:00 - - - Russell O'Connor 2018-06-01 15:03:46+00:00 - - - Johnson Lau 2018-05-31 18:35:41+00:00 - + 2025-09-26T15:49:55.714351+00:00 + python-feedgen + + + [bitcoin-dev] SIGHASH2 for version 1 witness programme Johnson Lau + 2018-05-31T18:35:00.000Z + + + Russell O'Connor + 2018-06-01T15:03:00.000Z + + + Johnson Lau + 2018-06-01T17:03:00.000Z + + + Russell O'Connor + 2018-06-01T18:15:00.000Z + + + Johnson Lau + 2018-06-01T18:45:00.000Z + + + Gregory Maxwell + 2018-07-02T18:23:00.000Z + + + Johnson Lau + 2018-08-30T20:38:00.000Z + + + Christian Decker + 2018-08-30T20:51:00.000Z + + + Johnson Lau + 2018-08-31T07:42:00.000Z + + + Christian Decker + 2018-09-03T13:53:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 + 2025-09-26T15:49:55.715603+00:00 - A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. 2018-09-03T13:53:33+00:00 + A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_Schnorr-signatures-BIP.xml b/static/bitcoin-dev/July_2018/combined_Schnorr-signatures-BIP.xml index 8ed1930c84..98f0b5d4ce 100644 --- a/static/bitcoin-dev/July_2018/combined_Schnorr-signatures-BIP.xml +++ b/static/bitcoin-dev/July_2018/combined_Schnorr-signatures-BIP.xml @@ -1,101 +1,135 @@ - + 2 Combined summary - Schnorr signatures BIP - 2023-08-01T23:34:39.972386+00:00 - - Russell O'Connor 2018-09-20 21:12:42+00:00 - - - Andrew Poelstra 2018-09-14 14:38:02+00:00 - - - Erik Aronesty 2018-09-13 20:20:36+00:00 - - - Andrew Poelstra 2018-09-13 18:46:50+00:00 - - - Erik Aronesty 2018-09-11 18:30:13+00:00 - - - Gregory Maxwell 2018-09-11 17:51:01+00:00 - - - Erik Aronesty 2018-09-11 17:37:59+00:00 - - - Gregory Maxwell 2018-09-11 17:27:09+00:00 - - - Erik Aronesty 2018-09-11 17:20:01+00:00 - - - Gregory Maxwell 2018-09-11 17:00:25+00:00 - - - Erik Aronesty 2018-09-11 16:34:11+00:00 - - - Gregory Maxwell 2018-09-05 15:35:14+00:00 - - - Erik Aronesty 2018-09-05 13:14:55+00:00 - - - Andrew Poelstra 2018-09-05 13:05:59+00:00 - - - Erik Aronesty 2018-09-05 12:26:14+00:00 - - - Andrew Poelstra 2018-09-03 00:05:18+00:00 - - - Erik Aronesty 2018-08-29 12:09:36+00:00 - - - Andrew Poelstra 2018-08-12 16:37:35+00:00 - - - Tim Ruffing 2018-08-06 21:12:48+00:00 - - - Russell O'Connor 2018-08-06 14:00:59+00:00 - - - Anthony Towns 2018-08-06 08:39:25+00:00 - - - Russell O'Connor 2018-08-05 14:33:52+00:00 - - - Russell O'Connor 2018-08-04 12:22:28+00:00 - - - Pieter Wuille 2018-07-14 21:20:48+00:00 - - - Sjors Provoost 2018-07-14 15:42:58+00:00 - - - Russell O'Connor 2018-07-08 14:36:16+00:00 - - - Артём Литвинович 2018-07-07 02:47:40+00:00 - - - Gregory Maxwell 2018-07-06 22:01:32+00:00 - - - Gregory Maxwell 2018-07-06 22:00:28+00:00 - - - Russell O'Connor 2018-07-06 21:05:03+00:00 - - - Pieter Wuille 2018-07-06 18:08:34+00:00 - + 2025-09-26T15:49:34.645830+00:00 + python-feedgen + + + [bitcoin-dev] Schnorr signatures BIP Pieter Wuille + 2018-07-06T18:08:00.000Z + + + Russell O'Connor + 2018-07-06T21:05:00.000Z + + + Gregory Maxwell + 2018-07-06T22:00:00.000Z + + + Gregory Maxwell + 2018-07-06T22:01:00.000Z + + + Артём Литвинович + 2018-07-07T02:47:00.000Z + + + Russell O'Connor + 2018-07-08T14:36:00.000Z + + + Sjors Provoost + 2018-07-14T15:42:00.000Z + + + Pieter Wuille + 2018-07-14T21:20:00.000Z + + + Russell O'Connor + 2018-08-04T12:22:00.000Z + + + Russell O'Connor + 2018-08-05T14:33:00.000Z + + + Anthony Towns + 2018-08-06T08:39:00.000Z + + + Russell O'Connor + 2018-08-06T14:00:00.000Z + + + Tim Ruffing + 2018-08-06T21:12:00.000Z + + + Andrew Poelstra + 2018-08-12T16:37:00.000Z + + + Erik Aronesty + 2018-08-29T12:09:00.000Z + + + Andrew Poelstra + 2018-09-03T00:05:00.000Z + + + Erik Aronesty + 2018-09-05T12:26:00.000Z + + + Andrew Poelstra + 2018-09-05T13:05:00.000Z + + + Erik Aronesty + 2018-09-05T13:14:00.000Z + + + Gregory Maxwell + 2018-09-05T15:35:00.000Z + + + Erik Aronesty + 2018-09-11T16:34:00.000Z + + + Gregory Maxwell + 2018-09-11T17:00:00.000Z + + + Erik Aronesty + 2018-09-11T17:20:00.000Z + + + Gregory Maxwell + 2018-09-11T17:27:00.000Z + + + Erik Aronesty + 2018-09-11T17:37:00.000Z + + + Gregory Maxwell + 2018-09-11T17:51:00.000Z + + + Erik Aronesty + 2018-09-11T18:30:00.000Z + + + Andrew Poelstra + 2018-09-13T18:46:00.000Z + + + Erik Aronesty + 2018-09-13T20:20:00.000Z + + + Andrew Poelstra + 2018-09-14T14:38:00.000Z + + + Russell O'Connor + 2018-09-20T21:12:00.000Z + + @@ -127,13 +161,13 @@ - python-feedgen + 2 Combined summary - Schnorr signatures BIP - 2023-08-01T23:34:39.972386+00:00 + 2025-09-26T15:49:34.649003+00:00 - Pieter Wuille's proposal for a BIP (Bitcoin Improvement Proposal) aims to introduce 64-byte elliptic curve Schnorr signatures into the Bitcoin development community. This draft specification is an important step towards standardizing the signature scheme, although it does not directly address consensus rules or aggregation. Wuille plans to collaborate with others to create production-ready reference implementations and conduct tests using the proposed scheme. It is also noted that this signature scheme may have applications beyond the scope of Bitcoin.In the discussion surrounding the proposal, Andrew Poelstra clarifies that M-of-N threshold MuSig signatures can be created for any values of M and N. By combining Schnorr signatures with Pedersen Secret Sharing, a secure interactive threshold signature scheme can be achieved, ensuring that signatures can only be produced by predetermined sets of signers. Poelstra also mentions that he has implemented the combination of MuSig and VSS (Verifiable Secret Sharing) in his code. However, there are unanswered questions raised by Erik Aronesty regarding building up threshold signatures via concatenation.The discussion further explores the topic of threshold signatures in the context of Bitcoin. The paper suggests using M-of-N signatures to validate one of the permutations of M that signed. It acknowledges that Musig, which is M-of-M, is prone to loss if a key is lost or a participant aborts during signing. However, it is possible to create M-of-N threshold MuSig signatures for any M and N, as demonstrated in an implementation shared on GitHub. Erik Aronesty raises concerns about Bitcoin releasing a multisig scheme that encourages loss, but it is clarified that there is currently no proposal for a non-redistributable multisig solution.Erik Aronesty discusses the security advantages of a redistributable threshold system and raises concerns about an M-1 rogue-key attack. Gregory Maxwell responds by explaining the possibility of constructing a 2-of-2 signature by adding keys and carrying out an attack using interpolation. The Musig paper describes a delinearization technique to prevent such attacks, but Erik Aronesty has not tested whether the R,s version is susceptible to these attacks.The author of a Medium article responds to feedback from Gregory Maxwell and clarifies that they switched to the Medium platform to edit and improve their work. They mention that no research has been done on the R,s version and explain that an M-1 rogue-key attack would require attacking either the hash function or the Discrete Logarithm Problem (DLP), neither of which gives an advantage to someone with M-1 keys. However, Gregory Maxwell suggests that the author may be ignoring unfavorable feedback.In another instance, Erik Aronesty reposts a broken scheme on Bitcointalk, but there is no response to the original post. This scheme raises concerns about security and functionality. In contrast, Musig is presented as a secure and functional multisig solution. Pieter Wuille suggests implementing a CAS (Compare and Swap) mechanism for precise communication in both directions.The discussion revolves around an M-of-N Bitcoin multisig scheme, with some questioning why there is so much debate around it. Others point out flaws in the scheme and express confusion caused by the person promoting it.In an email exchange, Erik Aronesty asks why his M-of-N Bitcoin multisig scheme is referred to as FUD (Fear, Uncertainty, and Doubt). Andrew Poelstra explains that Aronesty's scheme doesn't work, despite being repeatedly told so, and that Aronesty continues to post incomplete and incoherent versions of it. Poelstra states that Aronesty's scheme is broken.The FUD surrounding a specific Bitcoin multisig scheme is deemed unnecessary. The M-of-N shared public key is generated in advance, and signature fragments can be generated offline without communication between participants. Andrew Poelstra clarifies that there are no non-interactive Schnorr signatures.In the same email exchange, Erik Aronesty notes that his spec cannot be used directly with a Shamir scheme for single-round threshold multisigs. Andrew Poelstra clarifies that (R,s) schemes can still be used online if participants publish the R(share).In various discussions and exchanges, questions are raised regarding the implementation and encoding of public and private keys in the proposed Schnorr signature scheme. Various suggestions and clarifications are provided to address these concerns.There is also a discussion about the optimal order of inputs for hashing in ECDSA signatures, with arguments for both nonce-first and message-first approaches. The debate touches on security benefits, standard hash function design, and optimization techniques.Overall, the context encompasses proposals, discussions, clarifications, and concerns related to implementing 64-byte elliptic curve Schnorr signatures in Bitcoin, including threshold signatures and multisig schemes. 2018-09-20T21:12:42+00:00 + Pieter Wuille's proposal for a BIP (Bitcoin Improvement Proposal) aims to introduce 64-byte elliptic curve Schnorr signatures into the Bitcoin development community. This draft specification is an important step towards standardizing the signature scheme, although it does not directly address consensus rules or aggregation. Wuille plans to collaborate with others to create production-ready reference implementations and conduct tests using the proposed scheme. It is also noted that this signature scheme may have applications beyond the scope of Bitcoin.In the discussion surrounding the proposal, Andrew Poelstra clarifies that M-of-N threshold MuSig signatures can be created for any values of M and N. By combining Schnorr signatures with Pedersen Secret Sharing, a secure interactive threshold signature scheme can be achieved, ensuring that signatures can only be produced by predetermined sets of signers. Poelstra also mentions that he has implemented the combination of MuSig and VSS (Verifiable Secret Sharing) in his code. However, there are unanswered questions raised by Erik Aronesty regarding building up threshold signatures via concatenation.The discussion further explores the topic of threshold signatures in the context of Bitcoin. The paper suggests using M-of-N signatures to validate one of the permutations of M that signed. It acknowledges that Musig, which is M-of-M, is prone to loss if a key is lost or a participant aborts during signing. However, it is possible to create M-of-N threshold MuSig signatures for any M and N, as demonstrated in an implementation shared on GitHub. Erik Aronesty raises concerns about Bitcoin releasing a multisig scheme that encourages loss, but it is clarified that there is currently no proposal for a non-redistributable multisig solution.Erik Aronesty discusses the security advantages of a redistributable threshold system and raises concerns about an M-1 rogue-key attack. Gregory Maxwell responds by explaining the possibility of constructing a 2-of-2 signature by adding keys and carrying out an attack using interpolation. The Musig paper describes a delinearization technique to prevent such attacks, but Erik Aronesty has not tested whether the R,s version is susceptible to these attacks.The author of a Medium article responds to feedback from Gregory Maxwell and clarifies that they switched to the Medium platform to edit and improve their work. They mention that no research has been done on the R,s version and explain that an M-1 rogue-key attack would require attacking either the hash function or the Discrete Logarithm Problem (DLP), neither of which gives an advantage to someone with M-1 keys. However, Gregory Maxwell suggests that the author may be ignoring unfavorable feedback.In another instance, Erik Aronesty reposts a broken scheme on Bitcointalk, but there is no response to the original post. This scheme raises concerns about security and functionality. In contrast, Musig is presented as a secure and functional multisig solution. Pieter Wuille suggests implementing a CAS (Compare and Swap) mechanism for precise communication in both directions.The discussion revolves around an M-of-N Bitcoin multisig scheme, with some questioning why there is so much debate around it. Others point out flaws in the scheme and express confusion caused by the person promoting it.In an email exchange, Erik Aronesty asks why his M-of-N Bitcoin multisig scheme is referred to as FUD (Fear, Uncertainty, and Doubt). Andrew Poelstra explains that Aronesty's scheme doesn't work, despite being repeatedly told so, and that Aronesty continues to post incomplete and incoherent versions of it. Poelstra states that Aronesty's scheme is broken.The FUD surrounding a specific Bitcoin multisig scheme is deemed unnecessary. The M-of-N shared public key is generated in advance, and signature fragments can be generated offline without communication between participants. Andrew Poelstra clarifies that there are no non-interactive Schnorr signatures.In the same email exchange, Erik Aronesty notes that his spec cannot be used directly with a Shamir scheme for single-round threshold multisigs. Andrew Poelstra clarifies that (R,s) schemes can still be used online if participants publish the R(share).In various discussions and exchanges, questions are raised regarding the implementation and encoding of public and private keys in the proposed Schnorr signature scheme. Various suggestions and clarifications are provided to address these concerns.There is also a discussion about the optimal order of inputs for hashing in ECDSA signatures, with arguments for both nonce-first and message-first approaches. The debate touches on security benefits, standard hash function design, and optimization techniques.Overall, the context encompasses proposals, discussions, clarifications, and concerns related to implementing 64-byte elliptic curve Schnorr signatures in Bitcoin, including threshold signatures and multisig schemes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_Transaction-Coins.xml b/static/bitcoin-dev/July_2018/combined_Transaction-Coins.xml index f1d7770148..770fcd45f1 100644 --- a/static/bitcoin-dev/July_2018/combined_Transaction-Coins.xml +++ b/static/bitcoin-dev/July_2018/combined_Transaction-Coins.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Transaction Coins - 2023-08-01T23:39:50.159108+00:00 - - PJ Fitzpatrick 2018-07-13 10:11:27+00:00 - - - Jakub Trnka 2018-07-13 00:27:31+00:00 - - - PJ Fitzpatrick 2018-07-12 08:05:42+00:00 - + 2025-09-26T15:49:51.512633+00:00 + python-feedgen + + + [bitcoin-dev] Transaction Coins PJ Fitzpatrick + 2018-07-12T08:05:00.000Z + + + Jakub Trnka + 2018-07-13T00:27:00.000Z + + + PJ Fitzpatrick + 2018-07-13T10:11:00.000Z + + - python-feedgen + 2 Combined summary - Transaction Coins - 2023-08-01T23:39:50.159108+00:00 + 2025-09-26T15:49:51.513173+00:00 - PJ Fitzpatrick has proposed a method to establish digital scarcity from bitcoin transactions. The concept involves creating coins from transactions if their hash is among the closest n to the non-zero portion of the block hash. Regardless of the size of the transaction, only one coin is generated per transaction, resulting in n coins being produced per block. The initial coin supply and addresses can be determined entirely by the existing blockchain, making the coins scarce as they can only be created through transactions.The goal of this approach is to incentivize more transactions by building overlay scarcity and value on top of the bitcoin blockchain. By finding an equilibrium between paying transaction fees and mining new coins, it is believed that congestion on the bitcoin network can be created, motivating individuals to borrow scarcity from bitcoin in a sidechain. This borrowing of scarcity would effectively result in overlaying scarcity and value on top of the bitcoin blockchain, encouraging more frequent transactions.Jakub Trnka supports the idea of overlaying scarcity and value on top of the bitcoin blockchain to encourage increased transaction activity. He suggests that by establishing a balance between transaction fees and mining new coins, congestion on the bitcoin network can be stimulated. This congestion, in turn, would motivate individuals to utilize a sidechain and borrow scarcity from bitcoin. Trnka also mentions that there are other variations of this approach, such as generating computation puzzles from the previous block.In seeking feedback on this proposal, Fitzpatrick plans to initiate a discussion on bitcointalk. He is interested in hearing whether others have encountered a similar method or have any insights to offer. 2018-07-13T10:11:27+00:00 + PJ Fitzpatrick has proposed a method to establish digital scarcity from bitcoin transactions. The concept involves creating coins from transactions if their hash is among the closest n to the non-zero portion of the block hash. Regardless of the size of the transaction, only one coin is generated per transaction, resulting in n coins being produced per block. The initial coin supply and addresses can be determined entirely by the existing blockchain, making the coins scarce as they can only be created through transactions.The goal of this approach is to incentivize more transactions by building overlay scarcity and value on top of the bitcoin blockchain. By finding an equilibrium between paying transaction fees and mining new coins, it is believed that congestion on the bitcoin network can be created, motivating individuals to borrow scarcity from bitcoin in a sidechain. This borrowing of scarcity would effectively result in overlaying scarcity and value on top of the bitcoin blockchain, encouraging more frequent transactions.Jakub Trnka supports the idea of overlaying scarcity and value on top of the bitcoin blockchain to encourage increased transaction activity. He suggests that by establishing a balance between transaction fees and mining new coins, congestion on the bitcoin network can be stimulated. This congestion, in turn, would motivate individuals to utilize a sidechain and borrow scarcity from bitcoin. Trnka also mentions that there are other variations of this approach, such as generating computation puzzles from the previous block.In seeking feedback on this proposal, Fitzpatrick plans to initiate a discussion on bitcointalk. He is interested in hearing whether others have encountered a similar method or have any insights to offer. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_URI-scheme-with-optional-bech32-address.xml b/static/bitcoin-dev/July_2018/combined_URI-scheme-with-optional-bech32-address.xml index 6de36421b7..6132492c50 100644 --- a/static/bitcoin-dev/July_2018/combined_URI-scheme-with-optional-bech32-address.xml +++ b/static/bitcoin-dev/July_2018/combined_URI-scheme-with-optional-bech32-address.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - URI scheme with optional bech32 address - 2023-08-01T23:40:49.773167+00:00 + 2025-09-26T15:49:32.526063+00:00 + python-feedgen shiva sitamraju 2018-09-25 06:59:48+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - URI scheme with optional bech32 address - 2023-08-01T23:40:49.773167+00:00 + 2025-09-26T15:49:32.526226+00:00 - A proposal has been shared on Reddit regarding the adoption of bech32 QR codes in the Bitcoin network. While QR code adoption is considered important, bech32 QR codes are not backward compatible, leading many merchants and exchanges to opt for P2SH address QR codes instead. The proposed solution suggests using a URI format that includes both bech32 and P2SH address options. This would allow wallets to autopay using the lower transaction fee associated with bech32 addresses.The rationale behind this proposal is to increase the usage of bech32, which would create a network effect and potentially lead to widespread adoption of bech32 QR codes. To implement this solution, a team of developers is working on a walleting application capable of generating bech32 and P2WPKH-nested-in-P2SH addresses.One challenge faced by the team is that the payee cannot know in advance the technological capabilities of the payer. To address this, the proposal suggests encoding both bech32 and P2SH addresses in a Bitcoin URI. Legacy wallets would only see the P2SH address, while new wallets would be able to see and use the bech32 address for transactions.To maintain compatibility with BIP21, the 'path' field of the URI can be used for the P2WPKH-nested-in-P2SH address, while a new field (e.g., 'bech32') can be introduced for the bech32 address. It is assumed that wallets utilizing this scheme would monitor incoming transactions on both addresses. The order of attributes in the URI should not matter, as clients would check all attributes with the same name. However, it remains unclear if there are any precedents for the multiple use of an attribute in URI schemes.The team acknowledges that their proposal may not be entirely novel and asks if anyone has already proposed something similar. They also seek feedback on any major drawbacks to their proposal. 2018-09-25T06:59:48+00:00 + A proposal has been shared on Reddit regarding the adoption of bech32 QR codes in the Bitcoin network. While QR code adoption is considered important, bech32 QR codes are not backward compatible, leading many merchants and exchanges to opt for P2SH address QR codes instead. The proposed solution suggests using a URI format that includes both bech32 and P2SH address options. This would allow wallets to autopay using the lower transaction fee associated with bech32 addresses.The rationale behind this proposal is to increase the usage of bech32, which would create a network effect and potentially lead to widespread adoption of bech32 QR codes. To implement this solution, a team of developers is working on a walleting application capable of generating bech32 and P2WPKH-nested-in-P2SH addresses.One challenge faced by the team is that the payee cannot know in advance the technological capabilities of the payer. To address this, the proposal suggests encoding both bech32 and P2SH addresses in a Bitcoin URI. Legacy wallets would only see the P2SH address, while new wallets would be able to see and use the bech32 address for transactions.To maintain compatibility with BIP21, the 'path' field of the URI can be used for the P2WPKH-nested-in-P2SH address, while a new field (e.g., 'bech32') can be introduced for the bech32 address. It is assumed that wallets utilizing this scheme would monitor incoming transactions on both addresses. The order of attributes in the URI should not matter, as clients would check all attributes with the same name. However, it remains unclear if there are any precedents for the multiple use of an attribute in URI schemes.The team acknowledges that their proposal may not be entirely novel and asks if anyone has already proposed something similar. They also seek feedback on any major drawbacks to their proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_Weekly-IRC-Meeting-Time-Poll.xml b/static/bitcoin-dev/July_2018/combined_Weekly-IRC-Meeting-Time-Poll.xml index b381b4704b..c39b579f8a 100644 --- a/static/bitcoin-dev/July_2018/combined_Weekly-IRC-Meeting-Time-Poll.xml +++ b/static/bitcoin-dev/July_2018/combined_Weekly-IRC-Meeting-Time-Poll.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Weekly IRC Meeting Time Poll - 2023-08-01T23:39:37.793481+00:00 - - Cory Fields 2018-07-11 22:15:19+00:00 - - - mark M 2018-07-11 01:35:32+00:00 - - - Simon Selitsky 2018-07-10 23:17:56+00:00 - - - Cory Fields 2018-07-10 20:24:15+00:00 - + 2025-09-26T15:49:53.597754+00:00 + python-feedgen + + + [bitcoin-dev] Weekly IRC Meeting Time Poll Cory Fields + 2018-07-10T20:24:00.000Z + + + Simon Selitsky + 2018-07-10T23:17:00.000Z + + + mark M + 2018-07-11T01:35:00.000Z + + + Cory Fields + 2018-07-11T22:15:00.000Z + + - python-feedgen + 2 Combined summary - Weekly IRC Meeting Time Poll - 2023-08-01T23:39:37.793481+00:00 + 2025-09-26T15:49:53.598378+00:00 - On July 10, 2018, Cory Fields initiated a poll for Bitcoin Core contributors to determine their availability for online meetings. The purpose of the poll is to schedule the weekly IRC meetings at a time that would accommodate more participants. While the meetings themselves are unrelated to Bitcoin research and discussion, they are open to all. Initially, the list of voters was based on previous meeting participation. However, if someone regularly attends the meetings or cannot attend at the current time, they were encouraged to contact Cory on IRC to be added to the list.Cory sent an email to the bitcoin-dev mailing list, requesting input on the best times for developers to meet online. He created a poll to gather votes for the most suitable time for the weekly IRC meetings, which are currently fixed on Thursdays. The initial list of voters was compiled based on previous meeting attendance. If any regular attendees did not receive a link to vote, they were requested to reply to the email or ping Cory on IRC to be included. The polling will conclude at the end of the scheduled IRC meeting on July 19th. The email provided links to the mailing list and the poll.In July 2018, Cory Fields sent an email to the bitcoin-dev mailing list, discussing a poll he had created to determine the availability of developers for online meetings. Although this topic was considered off-topic for the mailing list, it was relevant to many core developers who were subscribed. The purpose of the poll was to collect data on the best times for weekly IRC meetings in order to minimize exclusions. The polling process began with an initial list of voters based on previous meeting participation and will end with the conclusion of the scheduled IRC meeting on July 19th. Attendees who regularly participate in the meetings or those who could attend at a different time but did not receive a voting link were requested to reply or contact Cory on IRC to be included.A recent email from Cory Fields was shared on the bitcoin-dev mailing list, where he requested participants to take part in a poll determining their availability for online meetings. The objective of the poll is to potentially reschedule the weekly IRC meetings to a time that would accommodate more people, as discussed during the previous week's meeting. The voting link will be sent via civs at cs.cornell.edu, and currently, the meetings are fixed for Thursdays. Initially, the list of voters was based on previous meeting attendance. However, if regular attendees did not receive a link within an hour, they were advised to reply to the post or contact Cory on IRC. The polling process will conclude at the end of the scheduled IRC meeting on July 19th. 2018-07-11T22:15:19+00:00 + On July 10, 2018, Cory Fields initiated a poll for Bitcoin Core contributors to determine their availability for online meetings. The purpose of the poll is to schedule the weekly IRC meetings at a time that would accommodate more participants. While the meetings themselves are unrelated to Bitcoin research and discussion, they are open to all. Initially, the list of voters was based on previous meeting participation. However, if someone regularly attends the meetings or cannot attend at the current time, they were encouraged to contact Cory on IRC to be added to the list.Cory sent an email to the bitcoin-dev mailing list, requesting input on the best times for developers to meet online. He created a poll to gather votes for the most suitable time for the weekly IRC meetings, which are currently fixed on Thursdays. The initial list of voters was compiled based on previous meeting attendance. If any regular attendees did not receive a link to vote, they were requested to reply to the email or ping Cory on IRC to be included. The polling will conclude at the end of the scheduled IRC meeting on July 19th. The email provided links to the mailing list and the poll.In July 2018, Cory Fields sent an email to the bitcoin-dev mailing list, discussing a poll he had created to determine the availability of developers for online meetings. Although this topic was considered off-topic for the mailing list, it was relevant to many core developers who were subscribed. The purpose of the poll was to collect data on the best times for weekly IRC meetings in order to minimize exclusions. The polling process began with an initial list of voters based on previous meeting participation and will end with the conclusion of the scheduled IRC meeting on July 19th. Attendees who regularly participate in the meetings or those who could attend at a different time but did not receive a voting link were requested to reply or contact Cory on IRC to be included.A recent email from Cory Fields was shared on the bitcoin-dev mailing list, where he requested participants to take part in a poll determining their availability for online meetings. The objective of the poll is to potentially reschedule the weekly IRC meetings to a time that would accommodate more people, as discussed during the previous week's meeting. The voting link will be sent via civs at cs.cornell.edu, and currently, the meetings are fixed for Thursdays. Initially, the list of voters was based on previous meeting attendance. However, if regular attendees did not receive a link within an hour, they were advised to reply to the post or contact Cory on IRC. The polling process will conclude at the end of the scheduled IRC meeting on July 19th. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_bitcoin-transactions.xml b/static/bitcoin-dev/July_2018/combined_bitcoin-transactions.xml index 822a99cc84..84d9b727ab 100644 --- a/static/bitcoin-dev/July_2018/combined_bitcoin-transactions.xml +++ b/static/bitcoin-dev/July_2018/combined_bitcoin-transactions.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - bitcoin-transactions - 2023-08-01T23:41:18.312752+00:00 - - hth lipsch 2018-08-09 08:38:09+00:00 - - - Aymeric Vitte 2018-08-01 09:58:43+00:00 - - - Marcel Jamin 2018-08-01 05:45:54+00:00 - - - Aymeric Vitte 2018-07-31 11:25:48+00:00 - + 2025-09-26T15:49:45.213517+00:00 + python-feedgen + + + [bitcoin-dev] bitcoin-transactions Aymeric Vitte + 2018-07-31T11:25:00.000Z + + + Marcel Jamin + 2018-08-01T05:45:00.000Z + + + Aymeric Vitte + 2018-08-01T09:58:00.000Z + + + hth lipsch + 2018-08-09T08:38:00.000Z + + - python-feedgen + 2 Combined summary - bitcoin-transactions - 2023-08-01T23:41:18.312752+00:00 + 2025-09-26T15:49:45.214133+00:00 - The email thread between Aymeric Vitte and Marcel Jamin discusses the issue of online services that ask for private keys and seeds in exchange for "free" coins. Jamin strongly advises against publishing a service that requires users to provide their private keys, as it poses a significant security risk if the server gets compromised. He also argues that moving coins by oneself is not the correct approach if the server is involved. In response, Vitte warns that people cannot resist the temptation of obtaining "free" coins by giving away their private keys. He mentions his web interface tool for bitcoin-transactions, which allows users to move their coins without any fees. However, he acknowledges that it is currently not advisable to use private keys on this tool. He suggests that an offline tool would be ideal if there is some incentive to do so. Vitte claims that his web interface tool, located at https://peersm.com/wallet, is the only online tool that can convert bech32 addresses, decode redeem scripts, and create transactions on its own. He emphasizes that using private keys on this platform is not recommended until it becomes an offline tool. The discussion also touches upon the issue of invalid bech32 addresses from Electrum wallets after segwit, which has caused confusion among users. Overall, Vitte believes that a safe and secure tool like his web interface would be a positive step forward for mainstream bitcoin users who value efficiency and simplicity. In addition, he provides links to various projects he is involved in on GitHub, including Bitcoin wallets made simple, Zcash wallets made simple, Peersm, torrent-live, node-Tor, and GitHub. 2018-08-09T08:38:09+00:00 + The email thread between Aymeric Vitte and Marcel Jamin discusses the issue of online services that ask for private keys and seeds in exchange for "free" coins. Jamin strongly advises against publishing a service that requires users to provide their private keys, as it poses a significant security risk if the server gets compromised. He also argues that moving coins by oneself is not the correct approach if the server is involved. In response, Vitte warns that people cannot resist the temptation of obtaining "free" coins by giving away their private keys. He mentions his web interface tool for bitcoin-transactions, which allows users to move their coins without any fees. However, he acknowledges that it is currently not advisable to use private keys on this tool. He suggests that an offline tool would be ideal if there is some incentive to do so. Vitte claims that his web interface tool, located at https://peersm.com/wallet, is the only online tool that can convert bech32 addresses, decode redeem scripts, and create transactions on its own. He emphasizes that using private keys on this platform is not recommended until it becomes an offline tool. The discussion also touches upon the issue of invalid bech32 addresses from Electrum wallets after segwit, which has caused confusion among users. Overall, Vitte believes that a safe and secure tool like his web interface would be a positive step forward for mainstream bitcoin users who value efficiency and simplicity. In addition, he provides links to various projects he is involved in on GitHub, including Bitcoin wallets made simple, Zcash wallets made simple, Peersm, torrent-live, node-Tor, and GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2018/combined_v0-16-1-test-bitcoin-fails-on-Deian-9.xml b/static/bitcoin-dev/July_2018/combined_v0-16-1-test-bitcoin-fails-on-Deian-9.xml index c2b02fbd75..b3697bfb6e 100644 --- a/static/bitcoin-dev/July_2018/combined_v0-16-1-test-bitcoin-fails-on-Deian-9.xml +++ b/static/bitcoin-dev/July_2018/combined_v0-16-1-test-bitcoin-fails-on-Deian-9.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - v0.16.1 test_bitcoin fails on Deian 9 - 2023-08-01T23:40:35.089532+00:00 - - Shigeya Suzuki 2018-07-14 15:35:00+00:00 - - - Marco Falke 2018-07-14 15:23:43+00:00 - - - Shigeya Suzuki 2018-07-14 13:48:59+00:00 - + 2025-09-26T15:49:43.127516+00:00 + python-feedgen + + + [bitcoin-dev] v0.16.1 test_bitcoin fails on Deian 9 Shigeya Suzuki + 2018-07-14T13:48:00.000Z + + + Marco Falke + 2018-07-14T15:23:00.000Z + + + Shigeya Suzuki + 2018-07-14T15:35:00.000Z + + - python-feedgen + 2 Combined summary - v0.16.1 test_bitcoin fails on Deian 9 - 2023-08-01T23:40:35.089532+00:00 + 2025-09-26T15:49:43.128040+00:00 - Shigeya Suzuki encountered an issue while running the src/test/test_bitcoin test on Debian 9. This problem was not observed when running the test on OS X High Sierra 10.13.6 or Ubuntu 16.04. The issue occurred specifically when using Configuration 2, resulting in a core dump during the execution of 264 test cases.Marco Falke from bitcoin-dev acknowledged that this issue was already known and is related to the test code, which is compiled only when debugging. He assured that the problem would be addressed in the upcoming releases, specifically in versions 0.16.2 and 0.17.0.To keep track of technical issues related to the Bitcoin Core code base, there is an issue tracker available. Shigeya Suzuki expressed doubts about whether the issue was due to differences in the toolchain used.In summary, Shigeya Suzuki reported encountering a strange result when running the src/test/test_bitcoin test on Debian 9. The issue was specific to Configuration 2 and resulted in a core dump during the execution of 264 test cases. Marco Falke acknowledged the problem and assured that it would be fixed in the upcoming releases. There is an issue tracker available for tracking technical issues related to the Bitcoin Core code base. 2018-07-14T15:35:00+00:00 + Shigeya Suzuki encountered an issue while running the src/test/test_bitcoin test on Debian 9. This problem was not observed when running the test on OS X High Sierra 10.13.6 or Ubuntu 16.04. The issue occurred specifically when using Configuration 2, resulting in a core dump during the execution of 264 test cases.Marco Falke from bitcoin-dev acknowledged that this issue was already known and is related to the test code, which is compiled only when debugging. He assured that the problem would be addressed in the upcoming releases, specifically in versions 0.16.2 and 0.17.0.To keep track of technical issues related to the Bitcoin Core code base, there is an issue tracker available. Shigeya Suzuki expressed doubts about whether the issue was due to differences in the toolchain used.In summary, Shigeya Suzuki reported encountering a strange result when running the src/test/test_bitcoin test on Debian 9. The issue was specific to Configuration 2 and resulted in a core dump during the execution of 264 test cases. Marco Falke acknowledged the problem and assured that it would be fixed in the upcoming releases. There is an issue tracker available for tracking technical issues related to the Bitcoin Core code base. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_Absent-authors-and-BIP-updates.xml b/static/bitcoin-dev/July_2019/combined_Absent-authors-and-BIP-updates.xml index ad2d4522fe..4275648632 100644 --- a/static/bitcoin-dev/July_2019/combined_Absent-authors-and-BIP-updates.xml +++ b/static/bitcoin-dev/July_2019/combined_Absent-authors-and-BIP-updates.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Absent authors and BIP updates - 2023-08-02T01:09:03.791840+00:00 - - Luke Dashjr 2019-07-25 03:06:24+00:00 - - - Karl-Johan Alm 2019-07-23 15:09:02+00:00 - + 2025-09-26T15:27:59.002589+00:00 + python-feedgen + + + [bitcoin-dev] Absent authors and BIP updates Karl-Johan Alm + 2019-07-23T15:09:00.000Z + + + Luke Dashjr + 2019-07-25T03:06:00.000Z + + - python-feedgen + 2 Combined summary - Absent authors and BIP updates - 2023-08-02T01:09:03.791840+00:00 + 2025-09-26T15:27:59.003018+00:00 - Karl-Johan Alm recently expressed concern on the bitcoin-dev mailing list regarding the issue of Bitcoin Improvement Proposal (BIP) authors who permanently leave and fail to respond to requests for changes to their BIPs. This creates a problem for the community as they are unable to make necessary updates or modifications to the BIPs. However, there is a solution provided by BIP 2, which allows for the assignment of a new champion to take over ownership of the proposal.The process outlined in BIP 2 involves submitting an email to the bitcoin-dev mailing list and making a formal announcement on the BIP repository on GitHub. By following this process, the BIP can remain current and relevant even if the original author is no longer involved.The BIP process has faced challenges when authors leave the project, making it difficult to modify existing BIPs. BIP-2 does provide a mechanism to request a change of a draft or proposed BIP to "rejected" status after three years of inactivity. However, this does not address the issue when an author leaves after their BIP has been accepted.To tackle this problem, four potential solutions have been proposed. The first solution suggests allowing anyone to request a change of a draft or proposed BIP to "accepted" at any time, as long as they can prove that it meets the criteria outlined in BIP-2, without needing approval from the original author.The second solution proposes allowing BIPs to expire after three years, giving the BIP repository maintainer the authority to assign a new champion if one emerges. This would ensure that the BIP remains active and can be updated even if the original author is absent.The third solution suggests creating new BIPs with new assignations that supersede the old BIP, similar to how BIP 2 supersedes BIP 1. However, this approach may not be easily noticeable as the original BIP cannot be modified.Lastly, there is the option of accepting the current process as it is and not making any changes. This would mean that the community would have to find alternative ways to address the challenges posed by authors who leave the project.Overall, the issue of authors leaving the Bitcoin Improvement Proposal process has sparked discussions on potential solutions. By implementing one of the proposed solutions or sticking with the current process, the Bitcoin community can ensure that BIPs remain up-to-date and relevant for future developments in the cryptocurrency space. 2019-07-25T03:06:24+00:00 + Karl-Johan Alm recently expressed concern on the bitcoin-dev mailing list regarding the issue of Bitcoin Improvement Proposal (BIP) authors who permanently leave and fail to respond to requests for changes to their BIPs. This creates a problem for the community as they are unable to make necessary updates or modifications to the BIPs. However, there is a solution provided by BIP 2, which allows for the assignment of a new champion to take over ownership of the proposal.The process outlined in BIP 2 involves submitting an email to the bitcoin-dev mailing list and making a formal announcement on the BIP repository on GitHub. By following this process, the BIP can remain current and relevant even if the original author is no longer involved.The BIP process has faced challenges when authors leave the project, making it difficult to modify existing BIPs. BIP-2 does provide a mechanism to request a change of a draft or proposed BIP to "rejected" status after three years of inactivity. However, this does not address the issue when an author leaves after their BIP has been accepted.To tackle this problem, four potential solutions have been proposed. The first solution suggests allowing anyone to request a change of a draft or proposed BIP to "accepted" at any time, as long as they can prove that it meets the criteria outlined in BIP-2, without needing approval from the original author.The second solution proposes allowing BIPs to expire after three years, giving the BIP repository maintainer the authority to assign a new champion if one emerges. This would ensure that the BIP remains active and can be updated even if the original author is absent.The third solution suggests creating new BIPs with new assignations that supersede the old BIP, similar to how BIP 2 supersedes BIP 1. However, this approach may not be easily noticeable as the original BIP cannot be modified.Lastly, there is the option of accepting the current process as it is and not making any changes. This would mean that the community would have to find alternative ways to address the challenges posed by authors who leave the project.Overall, the issue of authors leaving the Bitcoin Improvement Proposal process has sparked discussions on potential solutions. By implementing one of the proposed solutions or sticking with the current process, the Bitcoin community can ensure that BIPs remain up-to-date and relevant for future developments in the cryptocurrency space. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_Add-a-moving-checkpoint-to-the-Bitcoin-protocol.xml b/static/bitcoin-dev/July_2019/combined_Add-a-moving-checkpoint-to-the-Bitcoin-protocol.xml index 2a4604811a..52730110aa 100644 --- a/static/bitcoin-dev/July_2019/combined_Add-a-moving-checkpoint-to-the-Bitcoin-protocol.xml +++ b/static/bitcoin-dev/July_2019/combined_Add-a-moving-checkpoint-to-the-Bitcoin-protocol.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Add a moving checkpoint to the Bitcoin protocol - 2023-08-02T01:14:06.767072+00:00 - - Kenshiro [] 2019-08-03 10:35:51+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2019-08-03 00:51:12+00:00 - - - Kenshiro [] 2019-08-02 13:08:44+00:00 - - - Ethan Heilman 2019-08-02 12:19:03+00:00 - - - Kenshiro [] 2019-08-01 10:17:56+00:00 - - - Alistair Mann 2019-07-31 23:28:56+00:00 - - - Kenshiro [] 2019-07-31 14:53:25+00:00 - - - Kenshiro [] 2019-07-31 14:40:50+00:00 - - - Alistair Mann 2019-07-31 13:59:33+00:00 - - - Kenshiro [] 2019-07-31 12:28:58+00:00 - + 2025-09-26T15:28:15.930679+00:00 + python-feedgen + + + [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Kenshiro [] + 2019-07-31T12:28:00.000Z + + + Alistair Mann + 2019-07-31T13:59:00.000Z + + + Kenshiro [] + 2019-07-31T14:40:00.000Z + + + Kenshiro [] + 2019-07-31T14:53:00.000Z + + + Alistair Mann + 2019-07-31T23:28:00.000Z + + + Kenshiro [] + 2019-08-01T10:17:00.000Z + + + Ethan Heilman + 2019-08-02T12:19:00.000Z + + + Kenshiro [] + 2019-08-02T13:08:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2019-08-03T00:51:00.000Z + + + Kenshiro [] + 2019-08-03T10:35:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Add a moving checkpoint to the Bitcoin protocol - 2023-08-02T01:14:06.767072+00:00 + 2025-09-26T15:28:15.931854+00:00 - A proposal has been made to add a "moving checkpoint" to the Bitcoin protocol, similar to the one implemented in NXT coin. The rule would make the blockchain truly immutable after a certain number of blocks, even during a 51% attack. However, concerns have been raised about how this rule would handle a potential state-sponsored network split lasting longer than the specified block limit.To address these concerns, an additional rule has been suggested. If a node detects a fork with both sides having a length greater than 144 blocks, it would halt and request user intervention to determine which chain to follow. This is seen as a safer way to handle long network splits.However, critics argue that this rule could make Bitcoin more vulnerable to 51% attacks. To mitigate this vulnerability, a limit of X blocks has been proposed. The length of X blocks could be measured as the number of blocks multiplied by the average block difficulty, taking into account any difficulty adjustment that occurs over time.Under this proposed rule, the moving checkpoint would only be valid if the difference in blocks between the main chain and the new fork is smaller than X blocks, such as the blocks generated in 3 days. If a node sees a fork longer than its main chain, and the fork has at least X blocks more than the main chain, the node would ignore the moving checkpoint and follow the longest chain.Two possible scenarios are considered: a 51% attack where older blocks are protected against history rewrites for at least 3 days, allowing developers to release an emergency update with a different mining algorithm to counter the attack; and a network split where if the split is older than a certain number of blocks, there would be two permanent forks, but in 3 days or more, the blockchain heights would differ by more than X blocks, resulting in the abandonment of the losing chain.The discussion also addresses concerns about how a netsplit lasting longer than the block limit would be handled. It is suggested that the community would detect it before reaching the limit, allowing nodes to stop until the netsplit is fixed. In extreme cases where no one notices the split for more than the block limit and there are two permanent forks longer than the limit, nodes from one branch could delete their local history to join the other branch.However, critics argue that implementing a moving checkpoint rule as described could make Bitcoin more vulnerable to 51% attacks. They believe that the security of the rule could be further improved by making the number of blocks a fork must reach to halt the network proportional to the difference in time between the timestamp prior to the fork and the current time. Despite these discussions, it should be noted that the proposal is still under consideration and not yet adopted by the Bitcoin protocol.Overall, the proposal for a "moving checkpoint" in the Bitcoin protocol aims to improve security and address concerns regarding network splits and 51% attacks. However, there are ongoing debates about its effectiveness and potential vulnerabilities, and further discussions and analysis are needed before any implementation decisions are made. 2019-08-03T10:35:51+00:00 + A proposal has been made to add a "moving checkpoint" to the Bitcoin protocol, similar to the one implemented in NXT coin. The rule would make the blockchain truly immutable after a certain number of blocks, even during a 51% attack. However, concerns have been raised about how this rule would handle a potential state-sponsored network split lasting longer than the specified block limit.To address these concerns, an additional rule has been suggested. If a node detects a fork with both sides having a length greater than 144 blocks, it would halt and request user intervention to determine which chain to follow. This is seen as a safer way to handle long network splits.However, critics argue that this rule could make Bitcoin more vulnerable to 51% attacks. To mitigate this vulnerability, a limit of X blocks has been proposed. The length of X blocks could be measured as the number of blocks multiplied by the average block difficulty, taking into account any difficulty adjustment that occurs over time.Under this proposed rule, the moving checkpoint would only be valid if the difference in blocks between the main chain and the new fork is smaller than X blocks, such as the blocks generated in 3 days. If a node sees a fork longer than its main chain, and the fork has at least X blocks more than the main chain, the node would ignore the moving checkpoint and follow the longest chain.Two possible scenarios are considered: a 51% attack where older blocks are protected against history rewrites for at least 3 days, allowing developers to release an emergency update with a different mining algorithm to counter the attack; and a network split where if the split is older than a certain number of blocks, there would be two permanent forks, but in 3 days or more, the blockchain heights would differ by more than X blocks, resulting in the abandonment of the losing chain.The discussion also addresses concerns about how a netsplit lasting longer than the block limit would be handled. It is suggested that the community would detect it before reaching the limit, allowing nodes to stop until the netsplit is fixed. In extreme cases where no one notices the split for more than the block limit and there are two permanent forks longer than the limit, nodes from one branch could delete their local history to join the other branch.However, critics argue that implementing a moving checkpoint rule as described could make Bitcoin more vulnerable to 51% attacks. They believe that the security of the rule could be further improved by making the number of blocks a fork must reach to halt the network proportional to the difference in time between the timestamp prior to the fork and the current time. Despite these discussions, it should be noted that the proposal is still under consideration and not yet adopted by the Bitcoin protocol.Overall, the proposal for a "moving checkpoint" in the Bitcoin protocol aims to improve security and address concerns regarding network splits and 51% attacks. However, there are ongoing debates about its effectiveness and potential vulnerabilities, and further discussions and analysis are needed before any implementation decisions are made. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_BIP174-amendment-proposal-Important-Signer-Check-should-be-mentioned-.xml b/static/bitcoin-dev/July_2019/combined_BIP174-amendment-proposal-Important-Signer-Check-should-be-mentioned-.xml index 6f3b140380..e933b783f7 100644 --- a/static/bitcoin-dev/July_2019/combined_BIP174-amendment-proposal-Important-Signer-Check-should-be-mentioned-.xml +++ b/static/bitcoin-dev/July_2019/combined_BIP174-amendment-proposal-Important-Signer-Check-should-be-mentioned-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP174 amendment proposal (Important Signer Check should be mentioned) - 2023-08-02T01:05:47.574840+00:00 - - Jonathan Underwood 2019-07-09 22:21:25+00:00 - - - Andrew Chow 2019-07-09 20:26:45+00:00 - - - Jonathan Underwood 2019-07-09 15:58:56+00:00 - + 2025-09-26T15:28:11.744954+00:00 + python-feedgen + + + [bitcoin-dev] BIP174 amendment proposal (Important Signer Check should be mentioned) Jonathan Underwood + 2019-07-09T15:58:00.000Z + + + Andrew Chow + 2019-07-09T20:26:00.000Z + + + Jonathan Underwood + 2019-07-09T22:21:00.000Z + + - python-feedgen + 2 Combined summary - BIP174 amendment proposal (Important Signer Check should be mentioned) - 2023-08-02T01:05:47.575835+00:00 + 2025-09-26T15:28:11.745529+00:00 - On the Bitcoin-dev mailing list, Jonathan Underwood proposed a change to the bullet list for signers to ensure that the sighash type provided is acceptable to them. He gave an attack scenario where a signer's UTXO was stolen by a hacker who changed the PSBT input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the fact, changed the outputs to send to themselves and added an input they signed with SIGHASH_ALL.Andrew Chow responded, explaining that this attack scenario aligns with the original intent of the sighash field. The signer must determine if the provided sighash type is acceptable, and if not, they should not sign at all. Jonathan agreed with Andrew's explanation and stated that he would write the amendment and make a pull request (PR).On July 9th, 2019, Jonathan Underwood proposed a wording change to the Bitcoin Improvement Proposal (BIP) for the sighash field. This field contains information about how a transaction should be signed. Underwood presented an attack scenario where a hacker modifies the sighashtype of a partially signed Bitcoin transaction (PSBT) to SIGHASH_ANYONECANPAY | SIGHASH_NONE and then adds inputs and outputs to send BTC to themselves.Underwood suggests adding a check for signers to ensure that the sighash type provided is acceptable to them. If it is not acceptable, signing should fail. In cases where no sighash type is provided, signers should default to using SIGHASH_ALL but are allowed to sign with any sighash type they prefer.In his message, Jonathan Underwood describes an attack scenario in which a hacker steals BTC from a signer. The attack involves changing the sighashtype of the input to SIGHASH_ANYONECANPAY | SIGHASH_NONE, modifying the outputs to send BTC to the hacker's address, and adding an input that the hacker signed with SIGHASH_ALL. This results in the loss of BTC for the signer.To address this vulnerability, Underwood proposes additional checks for signers. They should verify if the provided sighash type is acceptable and refuse to sign if it is not. If no sighash type is provided, signers should use SIGHASH_ALL as the default but have the flexibility to sign with any sighash type they choose. 2019-07-09T22:21:25+00:00 + On the Bitcoin-dev mailing list, Jonathan Underwood proposed a change to the bullet list for signers to ensure that the sighash type provided is acceptable to them. He gave an attack scenario where a signer's UTXO was stolen by a hacker who changed the PSBT input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the fact, changed the outputs to send to themselves and added an input they signed with SIGHASH_ALL.Andrew Chow responded, explaining that this attack scenario aligns with the original intent of the sighash field. The signer must determine if the provided sighash type is acceptable, and if not, they should not sign at all. Jonathan agreed with Andrew's explanation and stated that he would write the amendment and make a pull request (PR).On July 9th, 2019, Jonathan Underwood proposed a wording change to the Bitcoin Improvement Proposal (BIP) for the sighash field. This field contains information about how a transaction should be signed. Underwood presented an attack scenario where a hacker modifies the sighashtype of a partially signed Bitcoin transaction (PSBT) to SIGHASH_ANYONECANPAY | SIGHASH_NONE and then adds inputs and outputs to send BTC to themselves.Underwood suggests adding a check for signers to ensure that the sighash type provided is acceptable to them. If it is not acceptable, signing should fail. In cases where no sighash type is provided, signers should default to using SIGHASH_ALL but are allowed to sign with any sighash type they prefer.In his message, Jonathan Underwood describes an attack scenario in which a hacker steals BTC from a signer. The attack involves changing the sighashtype of the input to SIGHASH_ANYONECANPAY | SIGHASH_NONE, modifying the outputs to send BTC to the hacker's address, and adding an input that the hacker signed with SIGHASH_ALL. This results in the loss of BTC for the signer.To address this vulnerability, Underwood proposes additional checks for signers. They should verify if the provided sighash type is acceptable and refuse to sign if it is not. If no sighash type is provided, signers should use SIGHASH_ALL as the default but have the flexibility to sign with any sighash type they choose. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_BIP174-extension-proposal-Global-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml b/static/bitcoin-dev/July_2019/combined_BIP174-extension-proposal-Global-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml index c2186d2c9e..e1b6f58ac5 100644 --- a/static/bitcoin-dev/July_2019/combined_BIP174-extension-proposal-Global-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml +++ b/static/bitcoin-dev/July_2019/combined_BIP174-extension-proposal-Global-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE) - 2023-08-02T01:01:27.845359+00:00 - - Jonathan Underwood 2019-07-23 05:03:32+00:00 - - - Jonathan Underwood 2019-06-29 08:11:56+00:00 - - - Dmitry Petukhov 2019-06-29 04:46:23+00:00 - - - Dmitry Petukhov 2019-06-29 04:31:04+00:00 - - - Jonathan Underwood 2019-06-29 00:19:41+00:00 - - - Dmitry Petukhov 2019-06-28 21:48:16+00:00 - - - Jonathan Underwood 2019-06-28 15:00:22+00:00 - - - Peter D. Gray 2019-06-28 14:37:55+00:00 - - - Jonathan Underwood 2019-06-28 02:44:15+00:00 - - - Dmitry Petukhov 2019-06-27 15:29:32+00:00 - - - Peter D. Gray 2019-06-27 15:07:45+00:00 - - - Jonathan Underwood 2019-06-27 09:52:28+00:00 - - - Jonathan Underwood 2019-06-27 09:32:46+00:00 - - - Jonathan Underwood 2019-06-27 08:59:44+00:00 - - - Jonathan Underwood 2019-06-27 08:16:14+00:00 - - - Jonathan Underwood 2019-06-27 05:07:47+00:00 - - - Jonathan Underwood 2019-06-27 02:11:23+00:00 - + 2025-09-26T15:27:54.720271+00:00 + python-feedgen + + + [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE) Jonathan Underwood + 2019-06-27T02:11:00.000Z + + + Jonathan Underwood + 2019-06-27T05:07:00.000Z + + + Jonathan Underwood + 2019-06-27T08:16:00.000Z + + + Jonathan Underwood + 2019-06-27T08:59:00.000Z + + + Jonathan Underwood + 2019-06-27T09:32:00.000Z + + + Jonathan Underwood + 2019-06-27T09:52:00.000Z + + + Peter D. Gray + 2019-06-27T15:07:00.000Z + + + Dmitry Petukhov + 2019-06-27T15:29:00.000Z + + + Jonathan Underwood + 2019-06-28T02:44:00.000Z + + + Peter D. Gray + 2019-06-28T14:37:00.000Z + + + Jonathan Underwood + 2019-06-28T15:00:00.000Z + + + Dmitry Petukhov + 2019-06-28T21:48:00.000Z + + + Jonathan Underwood + 2019-06-29T00:19:00.000Z + + + Dmitry Petukhov + 2019-06-29T04:31:00.000Z + + + Dmitry Petukhov + 2019-06-29T04:46:00.000Z + + + Jonathan Underwood + 2019-06-29T08:11:00.000Z + + + Jonathan Underwood + 2019-07-23T05:03:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE) - 2023-08-02T01:01:27.845359+00:00 + 2025-09-26T15:27:54.721990+00:00 - Jonathan Underwood, the Chief Bitcoin Officer at Bitbank Co., Ltd., has initiated a discussion on GitHub regarding the security of signed data in one-of-one multisig systems. He argues that explicitly signing the data is more secure, even if the difference is apparent outside the signed data. Dmitry Petukhov suggests using 0 as an indicator for serial numbers and requiring m=1 for single-sig cases. Jonathan mentions that 0x00 represents single sig and 0x01 represents multisig. The discussion also touches upon the use of redeem/witness scripts to differentiate between multisig and single-sig. The conversation also explores the revocation of signatures and the storage of whitelist pubkeys. It is suggested that a hardware wallet could store at least one counter and have rich state stored externally. However, storing a large enough state in the RAM of a resource-constrained device may present a problem. Another idea proposed is to add a serial to xpub-package, which would allow for revoking previously signed packages with compromised keys. In the discussion on the proposed field key format for PSBT, Dmitry Petukhov suggests replacing the signing public key with just a fingerprint of the master key to save bytes. However, it is pointed out that someone other than the signer would need to know the signing_pubkey beforehand for verification purposes. It is decided to use the first 4 bytes of the hash160 of the pubkey as the fingerprint. There is also a suggestion to add a serial number to the xpub package for revoking previously signed packages with compromised keys, but this may require a separate BIP.Jonathan Underwood proposes a solution for verifying change with multisig using the 0x01 global type proposed by Andrew Chow. The proposal involves signing each other's xpubs and creating a wallet that requires the other pubkeys to have signatures via his 0x02 proposal. However, the drawback is having to include n! (of m-of-n) signatures in every PSBT. A proposal is made to extend PSBT to allow for verifying that the destination address in a transaction has not been compromised. It is suggested that this issue be dealt with outside of PSBT to avoid making the core specification too large.A proposal has been made to extend Partially Signed Bitcoin Transactions (PSBT) to include a key value specification that would help verify the address a transaction is being sent to. The proposed scheme involves signing each other's extended public keys (xpubs) by all signers of a transaction, which can then be used to verify the destination address. Concerns were raised about its use in multisig wallets where some keys may be compromised. To prevent compromised keys from invalidating transactions, hardware wallets could be shown a specific 'epoch' word or serial number for xpub packages. These schemes could be included in PSBT as 'meta-information' or 'vendor-specific' fields.The proposed key value specification aims to address the issue of verifying addresses when transferring funds between cold and warm/hot wallets. While BIP32_DERIVATION can verify an address from a specific XPUB, it cannot verify its signature. The solution involves securely verifying the xpub of the warm/hot wallet using an airgap signing tool, uploading the signature/xpub pairs to the online unsigned transaction generator, and including one keyval pair per coldkey/xpub pairing. To avoid complicating the core PSBT specification, it is suggested that the various schemes should be dealt with outside of PSBT as 'PSBT metainformation' or using vendor-specific fields.The proposal also discusses the implementation of multisig wallet security with PSBT by signing all xpubs for a multisig wallet and including them in each transaction. This ensures that all signers are aware of every key involved in the transaction, increasing security for HD wallets. However, concerns were raised about the possibility of partial compromise, where one of the keys is stolen. The need for proper key revocation mechanisms is highlighted to ensure that signed packages cannot be used by attackers.Overall, the proposed extension of PSBT aims to improve the verification process and increase security for HD wallets. Feedback and suggestions for improvement have been invited by Jonathan Underwood. 2019-07-23T05:03:32+00:00 + Jonathan Underwood, the Chief Bitcoin Officer at Bitbank Co., Ltd., has initiated a discussion on GitHub regarding the security of signed data in one-of-one multisig systems. He argues that explicitly signing the data is more secure, even if the difference is apparent outside the signed data. Dmitry Petukhov suggests using 0 as an indicator for serial numbers and requiring m=1 for single-sig cases. Jonathan mentions that 0x00 represents single sig and 0x01 represents multisig. The discussion also touches upon the use of redeem/witness scripts to differentiate between multisig and single-sig. The conversation also explores the revocation of signatures and the storage of whitelist pubkeys. It is suggested that a hardware wallet could store at least one counter and have rich state stored externally. However, storing a large enough state in the RAM of a resource-constrained device may present a problem. Another idea proposed is to add a serial to xpub-package, which would allow for revoking previously signed packages with compromised keys. In the discussion on the proposed field key format for PSBT, Dmitry Petukhov suggests replacing the signing public key with just a fingerprint of the master key to save bytes. However, it is pointed out that someone other than the signer would need to know the signing_pubkey beforehand for verification purposes. It is decided to use the first 4 bytes of the hash160 of the pubkey as the fingerprint. There is also a suggestion to add a serial number to the xpub package for revoking previously signed packages with compromised keys, but this may require a separate BIP.Jonathan Underwood proposes a solution for verifying change with multisig using the 0x01 global type proposed by Andrew Chow. The proposal involves signing each other's xpubs and creating a wallet that requires the other pubkeys to have signatures via his 0x02 proposal. However, the drawback is having to include n! (of m-of-n) signatures in every PSBT. A proposal is made to extend PSBT to allow for verifying that the destination address in a transaction has not been compromised. It is suggested that this issue be dealt with outside of PSBT to avoid making the core specification too large.A proposal has been made to extend Partially Signed Bitcoin Transactions (PSBT) to include a key value specification that would help verify the address a transaction is being sent to. The proposed scheme involves signing each other's extended public keys (xpubs) by all signers of a transaction, which can then be used to verify the destination address. Concerns were raised about its use in multisig wallets where some keys may be compromised. To prevent compromised keys from invalidating transactions, hardware wallets could be shown a specific 'epoch' word or serial number for xpub packages. These schemes could be included in PSBT as 'meta-information' or 'vendor-specific' fields.The proposed key value specification aims to address the issue of verifying addresses when transferring funds between cold and warm/hot wallets. While BIP32_DERIVATION can verify an address from a specific XPUB, it cannot verify its signature. The solution involves securely verifying the xpub of the warm/hot wallet using an airgap signing tool, uploading the signature/xpub pairs to the online unsigned transaction generator, and including one keyval pair per coldkey/xpub pairing. To avoid complicating the core PSBT specification, it is suggested that the various schemes should be dealt with outside of PSBT as 'PSBT metainformation' or using vendor-specific fields.The proposal also discusses the implementation of multisig wallet security with PSBT by signing all xpubs for a multisig wallet and including them in each transaction. This ensures that all signers are aware of every key involved in the transaction, increasing security for HD wallets. However, concerns were raised about the possibility of partial compromise, where one of the keys is stolen. The need for proper key revocation mechanisms is highlighted to ensure that signed packages cannot be used by attackers.Overall, the proposed extension of PSBT aims to improve the verification process and increase security for HD wallets. Feedback and suggestions for improvement have been invited by Jonathan Underwood. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_Bitcoin-Core-to-disable-Bloom-based-Filtering-by-default.xml b/static/bitcoin-dev/July_2019/combined_Bitcoin-Core-to-disable-Bloom-based-Filtering-by-default.xml index f04eeff148..fd3fe02f40 100644 --- a/static/bitcoin-dev/July_2019/combined_Bitcoin-Core-to-disable-Bloom-based-Filtering-by-default.xml +++ b/static/bitcoin-dev/July_2019/combined_Bitcoin-Core-to-disable-Bloom-based-Filtering-by-default.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Bitcoin Core to disable Bloom-based Filtering by default - 2023-08-02T01:07:45.944093+00:00 - - Matt Corallo 2019-08-14 15:07:19+00:00 - - - Luke Dashjr 2019-07-27 19:19:49+00:00 - - - Matt Corallo 2019-07-27 16:10:03+00:00 - - - Chris 2019-07-26 16:48:36+00:00 - - - Jonas Schnelli 2019-07-26 10:04:32+00:00 - - - Tamas Blummer 2019-07-26 07:45:19+00:00 - - - Luke Dashjr 2019-07-25 03:04:25+00:00 - - - Justus Ranvier 2019-07-24 13:11:28+00:00 - - - Peter Todd 2019-07-23 20:36:50+00:00 - - - Andreas Schildbach 2019-07-23 14:47:18+00:00 - - - Luke Dashjr 2019-07-22 21:17:29+00:00 - - - Greg Sanders 2019-07-22 20:42:50+00:00 - - - Peter 2019-07-22 18:52:10+00:00 - - - Luke Dashjr 2019-07-22 17:26:56+00:00 - - - Luke Dashjr 2019-07-22 17:17:28+00:00 - - - Justus Ranvier 2019-07-22 15:58:49+00:00 - - - Dustin Dettmer 2019-07-22 15:15:49+00:00 - - - Tom Harding 2019-07-22 15:04:16+00:00 - - - Jonas Schnelli 2019-07-22 13:25:25+00:00 - - - Peter Todd 2019-07-22 08:32:15+00:00 - - - Matt Corallo 2019-07-22 05:01:58+00:00 - - - Andreas Schildbach 2019-07-21 22:56:33+00:00 - - - Matt Corallo 2019-07-20 17:46:52+00:00 - + 2025-09-26T15:28:07.528756+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default Matt Corallo + 2019-07-20T17:46:00.000Z + + + Andreas Schildbach + 2019-07-21T22:56:00.000Z + + + Matt Corallo + 2019-07-22T05:01:00.000Z + + + Peter Todd + 2019-07-22T08:32:00.000Z + + + Jonas Schnelli + 2019-07-22T13:25:00.000Z + + + Tom Harding + 2019-07-22T15:04:00.000Z + + + Dustin Dettmer + 2019-07-22T15:15:00.000Z + + + Justus Ranvier + 2019-07-22T15:58:00.000Z + + + Luke Dashjr + 2019-07-22T17:17:00.000Z + + + Luke Dashjr + 2019-07-22T17:26:00.000Z + + + Peter + 2019-07-22T18:52:00.000Z + + + Greg Sanders + 2019-07-22T20:42:00.000Z + + + Luke Dashjr + 2019-07-22T21:17:00.000Z + + + Andreas Schildbach + 2019-07-23T14:47:00.000Z + + + Peter Todd + 2019-07-23T20:36:00.000Z + + + Justus Ranvier + 2019-07-24T13:11:00.000Z + + + Luke Dashjr + 2019-07-25T03:04:00.000Z + + + Tamas Blummer + 2019-07-26T07:45:00.000Z + + + Jonas Schnelli + 2019-07-26T10:04:00.000Z + + + Chris + 2019-07-26T16:48:00.000Z + + + Matt Corallo + 2019-07-27T16:10:00.000Z + + + Luke Dashjr + 2019-07-27T19:19:00.000Z + + + Matt Corallo + 2019-08-14T15:07:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core to disable Bloom-based Filtering by default - 2023-08-02T01:07:45.944093+00:00 + 2025-09-26T15:28:07.531463+00:00 - In a recent announcement on the bitcoin-dev mailing list, it was revealed that bloom filter serving will be turned off by default in the next Bitcoin Core release. This decision comes as bloom filter serving has been a known DoS vector for some time and closing this vulnerability is seen as low-hanging fruit. While some users have expressed concerns about the impact on SPV implementations and centralization, it is expected that there will still be a sufficient number of NODE_BLOOM-enabled nodes available. Clients relying on NODE_BLOOM-supporting nodes are encouraged to consider migrating to alternative options in the coming years.Another discussion on the mailing list focused on the BIP158 compact block filter implemented in Bitcoin Core 0.19. Concerns were raised about address re-use and how the server determines the filter and false positive rate. It was suggested that the hardcoded filter may lead to wallets with many addresses having to wrap their key chains back to the beginning. However, it was clarified that wallets only need to match outstanding addresses that haven't been paid, rather than every single address used. This provides clarity on the potential issue of address re-use and its impact on wallet functionality.The conversation also touched upon the use of NODE_BLOOM peers and BIP 37 wallets. The change in defaults to serve BIP 37 peers does not imply the removal of the code for those who still wish to use it. Historical upgrade cycles suggest that many nodes will continue to serve NODE_BLOOM for years. However, there is an argument that BIP 158 offers better privacy and DoS protection, although it may result in increased traffic. The discussion emphasizes the importance of developers being transparent about the implications of different filtering options and providing users with choices based on their needs.In regards to BIP 157/158, it was noted that these are not alternatives to BIP 37 but rather complementary to it. Both can be used by wallets to save deterministic GCS filters, allowing offline re-scanning if necessary. While BIP 158 may cause more traffic, it provides the ability to filter blocks without relying on serving peers that could compromise financial privacy.The discussions also touched upon other topics such as the Rust implementation of BIP 158 and the potential use of DNS seed infrastructure to direct wallets to specific nodes. The ongoing debates within the Bitcoin community regarding security, scalability, and decentralization were also highlighted.In conclusion, the recent discussions on the bitcoin-dev mailing list have shed light on various aspects of Bitcoin Core, including the decision to turn off bloom filter serving by default, concerns about the BIP 158 compact block filter, and debates surrounding the use of NODE_BLOOM peers and BIP 37 wallets. Developers are encouraged to be transparent about the implications of different filtering options and provide users with choices based on their needs for privacy and bandwidth availability.The Bitcoin-dev mailing list recently discussed the potential removal of the NODE_BLOOM feature from the Bitcoin network. Developers expressed concern about the impact on over 10 million wallets that rely on this feature for updates. While alternatives like Electrum's JSON-based protocol and Stratum have been suggested, there is a consensus that BIP37 (public server-based tx filtering) was a conceptual mistake and should not be extended. The Neutrino protocol was also deemed controversial and less trustworthy. Matt Corallo raised concerns about privacy-violating alternatives to Bitcoin and pointed out that mitigations for these issues have been presented in a paper that requires further exploration.Andreas Schildbach argued against disabling the NODE_BLOOM feature, citing its importance to millions of wallets and the lack of a suitable alternative. He highlighted the potential risk of denial-of-service attacks but clarified that the myth surrounding them has been debunked. Andreas recommended improving the current filtering for segwit and urged developers to postpone the removal until a viable alternative exists. It was noted that NODE_BLOOM was added in Core 0.12 and BIP111 in 2015, indicating that this change was anticipated by most developers.The discussion also touched on the bandwidth usage of Compact Filters (CFB) compared to bloom filters, raising concerns about accessibility in impoverished countries where data rates are expensive. The plan is for such users to rely on custodial services, but questions were raised about the exact increase in bandwidth required by CFB. The conventional wisdom regarding CFB as privacy-violating was established by a paper that proposed mitigations but received little exploration. Despite these concerns, there has been a push towards custodial solutions, including custodial Lightning Network and L-BTC altcoin.Overall, the debate revolves around the potential impact on network security, privacy, and trust in Bitcoin. Developers are examining alternatives and calling for careful consideration before implementing any changes. 2019-08-14T15:07:19+00:00 + In a recent announcement on the bitcoin-dev mailing list, it was revealed that bloom filter serving will be turned off by default in the next Bitcoin Core release. This decision comes as bloom filter serving has been a known DoS vector for some time and closing this vulnerability is seen as low-hanging fruit. While some users have expressed concerns about the impact on SPV implementations and centralization, it is expected that there will still be a sufficient number of NODE_BLOOM-enabled nodes available. Clients relying on NODE_BLOOM-supporting nodes are encouraged to consider migrating to alternative options in the coming years.Another discussion on the mailing list focused on the BIP158 compact block filter implemented in Bitcoin Core 0.19. Concerns were raised about address re-use and how the server determines the filter and false positive rate. It was suggested that the hardcoded filter may lead to wallets with many addresses having to wrap their key chains back to the beginning. However, it was clarified that wallets only need to match outstanding addresses that haven't been paid, rather than every single address used. This provides clarity on the potential issue of address re-use and its impact on wallet functionality.The conversation also touched upon the use of NODE_BLOOM peers and BIP 37 wallets. The change in defaults to serve BIP 37 peers does not imply the removal of the code for those who still wish to use it. Historical upgrade cycles suggest that many nodes will continue to serve NODE_BLOOM for years. However, there is an argument that BIP 158 offers better privacy and DoS protection, although it may result in increased traffic. The discussion emphasizes the importance of developers being transparent about the implications of different filtering options and providing users with choices based on their needs.In regards to BIP 157/158, it was noted that these are not alternatives to BIP 37 but rather complementary to it. Both can be used by wallets to save deterministic GCS filters, allowing offline re-scanning if necessary. While BIP 158 may cause more traffic, it provides the ability to filter blocks without relying on serving peers that could compromise financial privacy.The discussions also touched upon other topics such as the Rust implementation of BIP 158 and the potential use of DNS seed infrastructure to direct wallets to specific nodes. The ongoing debates within the Bitcoin community regarding security, scalability, and decentralization were also highlighted.In conclusion, the recent discussions on the bitcoin-dev mailing list have shed light on various aspects of Bitcoin Core, including the decision to turn off bloom filter serving by default, concerns about the BIP 158 compact block filter, and debates surrounding the use of NODE_BLOOM peers and BIP 37 wallets. Developers are encouraged to be transparent about the implications of different filtering options and provide users with choices based on their needs for privacy and bandwidth availability.The Bitcoin-dev mailing list recently discussed the potential removal of the NODE_BLOOM feature from the Bitcoin network. Developers expressed concern about the impact on over 10 million wallets that rely on this feature for updates. While alternatives like Electrum's JSON-based protocol and Stratum have been suggested, there is a consensus that BIP37 (public server-based tx filtering) was a conceptual mistake and should not be extended. The Neutrino protocol was also deemed controversial and less trustworthy. Matt Corallo raised concerns about privacy-violating alternatives to Bitcoin and pointed out that mitigations for these issues have been presented in a paper that requires further exploration.Andreas Schildbach argued against disabling the NODE_BLOOM feature, citing its importance to millions of wallets and the lack of a suitable alternative. He highlighted the potential risk of denial-of-service attacks but clarified that the myth surrounding them has been debunked. Andreas recommended improving the current filtering for segwit and urged developers to postpone the removal until a viable alternative exists. It was noted that NODE_BLOOM was added in Core 0.12 and BIP111 in 2015, indicating that this change was anticipated by most developers.The discussion also touched on the bandwidth usage of Compact Filters (CFB) compared to bloom filters, raising concerns about accessibility in impoverished countries where data rates are expensive. The plan is for such users to rely on custodial services, but questions were raised about the exact increase in bandwidth required by CFB. The conventional wisdom regarding CFB as privacy-violating was established by a paper that proposed mitigations but received little exploration. Despite these concerns, there has been a push towards custodial solutions, including custodial Lightning Network and L-BTC altcoin.Overall, the debate revolves around the potential impact on network security, privacy, and trust in Bitcoin. Developers are examining alternatives and calling for careful consideration before implementing any changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_Generalized-covenants-with-taproot-enable-riskless-or-risky-lending-prevent-credit-inflation-through-fractional-reserve.xml b/static/bitcoin-dev/July_2019/combined_Generalized-covenants-with-taproot-enable-riskless-or-risky-lending-prevent-credit-inflation-through-fractional-reserve.xml index a3741e0c3b..2a3381eb9f 100644 --- a/static/bitcoin-dev/July_2019/combined_Generalized-covenants-with-taproot-enable-riskless-or-risky-lending-prevent-credit-inflation-through-fractional-reserve.xml +++ b/static/bitcoin-dev/July_2019/combined_Generalized-covenants-with-taproot-enable-riskless-or-risky-lending-prevent-credit-inflation-through-fractional-reserve.xml @@ -1,62 +1,187 @@ - + 2 Combined summary - Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve - 2023-08-02T01:04:01.587059+00:00 - - Tamas Blummer 2019-07-09 20:32:53+00:00 - - - Tamas Blummer 2019-07-07 09:18:04+00:00 - - - Tamas Blummer 2019-07-06 13:34:31+00:00 - - - Tamas Blummer 2019-07-06 10:12:44+00:00 - - - Tamas Blummer 2019-07-04 17:10:31+00:00 - - - Tamas Blummer 2019-07-02 12:51:31+00:00 - - - Tamas Blummer 2019-07-02 10:14:32+00:00 - - - Tamas Blummer 2019-07-02 09:47:09+00:00 - - - Tamas Blummer 2019-07-02 09:30:31+00:00 - - - Tamas Blummer 2019-07-02 06:38:55+00:00 - - - Tamas Blummer 2019-07-02 05:08:53+00:00 - - - Tamas Blummer 2019-06-30 20:26:29+00:00 - - - Tamas Blummer 2019-06-30 19:55:41+00:00 - - - Tamas Blummer 2019-06-30 18:35:33+00:00 - - - Tamas Blummer 2019-06-30 10:56:46+00:00 - - - David A. Harding 2019-06-29 18:21:03+00:00 - - - Tamas Blummer 2019-06-28 19:21:56+00:00 - - - Tamas Blummer 2019-06-28 08:27:16+00:00 - + 2025-09-26T15:28:03.280637+00:00 + python-feedgen + + + [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve Tamas Blummer + 2019-06-28T08:27:00.000Z + + + Eric Voskuil + 2019-06-28T17:25:00.000Z + + + Tamas Blummer + 2019-06-28T19:21:00.000Z + + + David A. Harding + 2019-06-29T18:21:00.000Z + + + Eric Voskuil + 2019-06-29T21:21:00.000Z + + + Tamas Blummer + 2019-06-30T10:56:00.000Z + + + Eric Voskuil + 2019-06-30T17:41:00.000Z + + + Tamas Blummer + 2019-06-30T18:35:00.000Z + + + Eric Voskuil + 2019-06-30T18:54:00.000Z + + + Tamas Blummer + 2019-06-30T19:55:00.000Z + + + Eric Voskuil + 2019-06-30T20:13:00.000Z + + + Tamas Blummer + 2019-06-30T20:26:00.000Z + + + Eric Voskuil + 2019-07-01T18:52:00.000Z + + + ZmnSCPxj + 2019-07-02T03:45:00.000Z + + + Tamas Blummer + 2019-07-02T05:08:00.000Z + + + Tamas Blummer + 2019-07-02T06:38:00.000Z + + + ZmnSCPxj + 2019-07-02T08:12:00.000Z + + + Tamas Blummer + 2019-07-02T09:30:00.000Z + + + Tamas Blummer + 2019-07-02T09:47:00.000Z + + + Tamas Blummer + 2019-07-02T10:14:00.000Z + + + ZmnSCPxj + 2019-07-02T10:33:00.000Z + + + Tamas Blummer + 2019-07-02T12:51:00.000Z + + + Eric Voskuil + 2019-07-03T22:30:00.000Z + + + ZmnSCPxj + 2019-07-04T04:57:00.000Z + + + Eric Voskuil + 2019-07-04T16:43:00.000Z + + + Tamas Blummer + 2019-07-04T17:10:00.000Z + + + Eric Voskuil + 2019-07-04T18:31:00.000Z + + + Eric Voskuil + 2019-07-04T19:31:00.000Z + + + ZmnSCPxj + 2019-07-05T04:05:00.000Z + + + Eric Voskuil + 2019-07-05T19:27:00.000Z + + + ZmnSCPxj + 2019-07-05T23:16:00.000Z + + + Eric Voskuil + 2019-07-05T23:20:00.000Z + + + Eric Voskuil + 2019-07-05T23:44:00.000Z + + + ZmnSCPxj + 2019-07-06T00:17:00.000Z + + + Eric Voskuil + 2019-07-06T01:28:00.000Z + + + Eric Voskuil + 2019-07-06T01:46:00.000Z + + + Tamas Blummer + 2019-07-06T10:12:00.000Z + + + Tamas Blummer + 2019-07-06T13:34:00.000Z + + + Eric Voskuil + 2019-07-06T22:21:00.000Z + + + Eric Voskuil + 2019-07-06T22:37:00.000Z + + + Eric Voskuil + 2019-07-07T01:30:00.000Z + + + Tamas Blummer + 2019-07-07T09:18:00.000Z + + + ZmnSCPxj + 2019-07-09T10:31:00.000Z + + + Tamas Blummer + 2019-07-09T20:32:00.000Z + + @@ -75,13 +200,13 @@ - python-feedgen + 2 Combined summary - Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve - 2023-08-02T01:04:01.587059+00:00 + 2025-09-26T15:28:03.285164+00:00 - The email thread revolves around the concept of a "Bitcoin Classified Ads Network" (BCAN) and its potential to create censorship-resistant networks that provide riskless interest on Bitcoin. In BCAN, nodes share advertisements referring to unspent transaction outputs (UTXOs) at the chain tip. Advertisements have a size limit and include a commitment to the text. If nodes exceed this limit, they sort advertisements by value-rate and remove low-value ones. Sellers aim to minimize the value in UTXOs backing their ads. Rent for advertisements is paid to joinmarket makers and LN forwarding nodes. Users can query their own BCAN node for specific advertisements without compromising privacy.The author criticizes Eric's cryproeconomic theories, stating that they accurately describe Bitcoin as money but fail to consider reliable memory for other uses. They argue that if memory had more uses, even temporarily, it would have utility and value. However, Bitcoin lacks consensus rules to enable reliable alternate uses. The finite supply of coins implies a finite memory capacity, making units temporarily un-fungible. This leads to competition for memory units and a price paid to enable alternate use. Giving up temporary control has a positive price, and return of control is certain, resulting in riskless interest. The author suggests designing systems to sustain Bitcoin while avoiding burning for unlimited uses.The conversation between Eric Voskuil and ZmnSCPxj focuses on encumbering UTXOs in an ad market and its relationship to opportunity cost. ZmnSCPxj argues that early recovery of UTXOs eliminates time lock costs, but Eric asserts that he is discussing cryptoeconomic principles, not implementation details. Eric claims that multisig unlock reduces UTXOs to just UTXOs, removing actual encumbrance. Any UTXO can prove ownership in the ad network, but higher-value UTXOs may be prioritized by limited-bandwidth services. Tamas Blummer concludes the email chain.Another email exchange between ZmnSCPxj and Eric Voskuil discusses using the unspentness-time of a UTXO for advertising services or producers. This allows merchants to recover locked funds by spending the advertising UTXO once the stock is sold. The proposal separates fund owners from users, enabling dynamic maturity. Burning is considered unsustainable, so the covenant enables temporary use of UTXOs for something other than money. The current owner of a UTXO will be paid for temporarily giving up control, representing interest.Tamas Blummer and Eric Voskuil discuss imposing costs on use without direct billing. Methods include burning Bitcoins, paying high fees in self-dealing transactions, time-locking own Bitcoins, paying someone else to time-lock, and transferable borrowed Bitcoin. Eric suggests that community hashcash spam protection can raise encumbered coin requirement for advertising threshold price. They also discuss "renting a UTXO of substantial value" and its viability. However, Eric is not fully supportive of generalized covenants as he believes the use-case already exists. ZmnSCPxj presents another use case involving a "Bitcoin Classified Ads Network," where nodes preferentially keep higher-value backed advertisements.Tamas Blummer and ZmnSCPxj discuss the use of temporary control UTXOs for services that require it. If there is demand, users pay fees to the service provider and cover opportunity cost paid to the original holder. Temporary access to significant-value UTXOs induces opportunity cost for users, while burning ordinary UTXOs is seen as unsustainable. Temporary access UTXOs with covenants can build spam-limited public services without an operator and offer HODLers riskless interest.The value of an encumbered UTXO is reduced due to governance by different rules in a de-facto side chain. Renting an encumbered UTXO is only valuable for the advertisement, not opportunity cost. Temporary access through covenants allows anyone with control to recover the cost by sub-renting. Committing to a public key instead of advertisements is suggested, but it risks the HODLer's funds if the advertiser misbehaves.Tamas Blummer and ZmnSCPxj discuss solving problems using covenants. Consensus support is necessary only if an unchained setup is closed uncooperatively. An advertising scheme involving committing a public key on the UTXO is proposed, but it requires trusting the advertising service, which goes against the trustless separation provided by covenants.ZmnSCPxj suggests the Graftroot idea, committing a public key on the UTXO and using a SCRIPT signed by the public key to unlock it. Tamas Blummer points out that this puts HODLer's funds at risk and negates the trustless separation achieved by covenants.The email exchange discusses a "Bitcoin Classified Ads Network" where P2PKH UTXOs embed commitments to advertisements, transmitted via a secondary 2019-07-09T20:32:53+00:00 + The email thread revolves around the concept of a "Bitcoin Classified Ads Network" (BCAN) and its potential to create censorship-resistant networks that provide riskless interest on Bitcoin. In BCAN, nodes share advertisements referring to unspent transaction outputs (UTXOs) at the chain tip. Advertisements have a size limit and include a commitment to the text. If nodes exceed this limit, they sort advertisements by value-rate and remove low-value ones. Sellers aim to minimize the value in UTXOs backing their ads. Rent for advertisements is paid to joinmarket makers and LN forwarding nodes. Users can query their own BCAN node for specific advertisements without compromising privacy.The author criticizes Eric's cryproeconomic theories, stating that they accurately describe Bitcoin as money but fail to consider reliable memory for other uses. They argue that if memory had more uses, even temporarily, it would have utility and value. However, Bitcoin lacks consensus rules to enable reliable alternate uses. The finite supply of coins implies a finite memory capacity, making units temporarily un-fungible. This leads to competition for memory units and a price paid to enable alternate use. Giving up temporary control has a positive price, and return of control is certain, resulting in riskless interest. The author suggests designing systems to sustain Bitcoin while avoiding burning for unlimited uses.The conversation between Eric Voskuil and ZmnSCPxj focuses on encumbering UTXOs in an ad market and its relationship to opportunity cost. ZmnSCPxj argues that early recovery of UTXOs eliminates time lock costs, but Eric asserts that he is discussing cryptoeconomic principles, not implementation details. Eric claims that multisig unlock reduces UTXOs to just UTXOs, removing actual encumbrance. Any UTXO can prove ownership in the ad network, but higher-value UTXOs may be prioritized by limited-bandwidth services. Tamas Blummer concludes the email chain.Another email exchange between ZmnSCPxj and Eric Voskuil discusses using the unspentness-time of a UTXO for advertising services or producers. This allows merchants to recover locked funds by spending the advertising UTXO once the stock is sold. The proposal separates fund owners from users, enabling dynamic maturity. Burning is considered unsustainable, so the covenant enables temporary use of UTXOs for something other than money. The current owner of a UTXO will be paid for temporarily giving up control, representing interest.Tamas Blummer and Eric Voskuil discuss imposing costs on use without direct billing. Methods include burning Bitcoins, paying high fees in self-dealing transactions, time-locking own Bitcoins, paying someone else to time-lock, and transferable borrowed Bitcoin. Eric suggests that community hashcash spam protection can raise encumbered coin requirement for advertising threshold price. They also discuss "renting a UTXO of substantial value" and its viability. However, Eric is not fully supportive of generalized covenants as he believes the use-case already exists. ZmnSCPxj presents another use case involving a "Bitcoin Classified Ads Network," where nodes preferentially keep higher-value backed advertisements.Tamas Blummer and ZmnSCPxj discuss the use of temporary control UTXOs for services that require it. If there is demand, users pay fees to the service provider and cover opportunity cost paid to the original holder. Temporary access to significant-value UTXOs induces opportunity cost for users, while burning ordinary UTXOs is seen as unsustainable. Temporary access UTXOs with covenants can build spam-limited public services without an operator and offer HODLers riskless interest.The value of an encumbered UTXO is reduced due to governance by different rules in a de-facto side chain. Renting an encumbered UTXO is only valuable for the advertisement, not opportunity cost. Temporary access through covenants allows anyone with control to recover the cost by sub-renting. Committing to a public key instead of advertisements is suggested, but it risks the HODLer's funds if the advertiser misbehaves.Tamas Blummer and ZmnSCPxj discuss solving problems using covenants. Consensus support is necessary only if an unchained setup is closed uncooperatively. An advertising scheme involving committing a public key on the UTXO is proposed, but it requires trusting the advertising service, which goes against the trustless separation provided by covenants.ZmnSCPxj suggests the Graftroot idea, committing a public key on the UTXO and using a SCRIPT signed by the public key to unlock it. Tamas Blummer points out that this puts HODLer's funds at risk and negates the trustless separation achieved by covenants.The email exchange discusses a "Bitcoin Classified Ads Network" where P2PKH UTXOs embed commitments to advertisements, transmitted via a secondary - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_Improving-JoinMarket-s-resistance-to-sybil-attacks-using-fidelity-bonds.xml b/static/bitcoin-dev/July_2019/combined_Improving-JoinMarket-s-resistance-to-sybil-attacks-using-fidelity-bonds.xml index 4cfe1085c8..43c8704d6f 100644 --- a/static/bitcoin-dev/July_2019/combined_Improving-JoinMarket-s-resistance-to-sybil-attacks-using-fidelity-bonds.xml +++ b/static/bitcoin-dev/July_2019/combined_Improving-JoinMarket-s-resistance-to-sybil-attacks-using-fidelity-bonds.xml @@ -1,101 +1,135 @@ - + 2 Combined summary - Improving JoinMarket's resistance to sybil attacks using fidelity bonds - 2023-08-02T01:11:05.109132+00:00 - - Chris Belcher 2019-08-08 20:06:07+00:00 - - - ZmnSCPxj 2019-08-08 13:59:13+00:00 - - - Dmitry Petukhov 2019-08-08 12:05:05+00:00 - - - Dmitry Petukhov 2019-08-08 11:37:50+00:00 - - - ZmnSCPxj 2019-08-08 09:35:24+00:00 - - - ZmnSCPxj 2019-08-08 00:09:11+00:00 - - - Dmitry Petukhov 2019-08-07 15:10:17+00:00 - - - ZmnSCPxj 2019-08-07 11:35:34+00:00 - - - ZmnSCPxj 2019-08-07 11:20:38+00:00 - - - Chris Belcher 2019-08-07 10:05:41+00:00 - - - Chris Belcher 2019-08-07 09:38:43+00:00 - - - ZmnSCPxj 2019-08-06 23:33:19+00:00 - - - Dmitry Petukhov 2019-08-06 21:37:42+00:00 - - - Dmitry Petukhov 2019-08-06 20:55:41+00:00 - - - Leo Wandersleb 2019-08-06 13:07:19+00:00 - - - Chris Belcher 2019-08-06 10:27:17+00:00 - - - ZmnSCPxj 2019-08-06 02:54:14+00:00 - - - Leo Wandersleb 2019-08-06 01:51:02+00:00 - - - Chris Belcher 2019-08-05 19:04:26+00:00 - - - Adam Gibson 2019-08-02 14:24:11+00:00 - - - Chris Belcher 2019-08-02 09:21:57+00:00 - - - David A. Harding 2019-07-31 17:59:40+00:00 - - - Dmitry Petukhov 2019-07-31 15:50:18+00:00 - - - Chris Belcher 2019-07-30 21:39:14+00:00 - - - Chris Belcher 2019-07-30 21:27:17+00:00 - - - Tamas Blummer 2019-07-28 18:29:34+00:00 - - - Tamas Blummer 2019-07-28 14:17:35+00:00 - - - David A. Harding 2019-07-27 19:34:17+00:00 - - - Dmitry Petukhov 2019-07-26 09:38:38+00:00 - - - Tamas Blummer 2019-07-26 08:10:15+00:00 - - - Chris Belcher 2019-07-25 11:47:54+00:00 - + 2025-09-26T15:27:56.882815+00:00 + python-feedgen + + + [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds Chris Belcher + 2019-07-25T11:47:00.000Z + + + Tamas Blummer + 2019-07-26T08:10:00.000Z + + + Dmitry Petukhov + 2019-07-26T09:38:00.000Z + + + David A. Harding + 2019-07-27T19:34:00.000Z + + + Tamas Blummer + 2019-07-28T14:17:00.000Z + + + Tamas Blummer + 2019-07-28T18:29:00.000Z + + + Chris Belcher + 2019-07-30T21:27:00.000Z + + + Chris Belcher + 2019-07-30T21:39:00.000Z + + + Dmitry Petukhov + 2019-07-31T15:50:00.000Z + + + David A. Harding + 2019-07-31T17:59:00.000Z + + + Chris Belcher + 2019-08-02T09:21:00.000Z + + + Adam Gibson + 2019-08-02T14:24:00.000Z + + + Chris Belcher + 2019-08-05T19:04:00.000Z + + + Leo Wandersleb + 2019-08-06T01:51:00.000Z + + + ZmnSCPxj + 2019-08-06T02:54:00.000Z + + + Chris Belcher + 2019-08-06T10:27:00.000Z + + + Leo Wandersleb + 2019-08-06T13:07:00.000Z + + + Dmitry Petukhov + 2019-08-06T20:55:00.000Z + + + Dmitry Petukhov + 2019-08-06T21:37:00.000Z + + + ZmnSCPxj + 2019-08-06T23:33:00.000Z + + + Chris Belcher + 2019-08-07T09:38:00.000Z + + + Chris Belcher + 2019-08-07T10:05:00.000Z + + + ZmnSCPxj + 2019-08-07T11:20:00.000Z + + + ZmnSCPxj + 2019-08-07T11:35:00.000Z + + + Dmitry Petukhov + 2019-08-07T15:10:00.000Z + + + ZmnSCPxj + 2019-08-08T00:09:00.000Z + + + ZmnSCPxj + 2019-08-08T09:35:00.000Z + + + Dmitry Petukhov + 2019-08-08T11:37:00.000Z + + + Dmitry Petukhov + 2019-08-08T12:05:00.000Z + + + ZmnSCPxj + 2019-08-08T13:59:00.000Z + + + Chris Belcher + 2019-08-08T20:06:00.000Z + + @@ -127,13 +161,13 @@ - python-feedgen + 2 Combined summary - Improving JoinMarket's resistance to sybil attacks using fidelity bonds - 2023-08-02T01:11:05.109132+00:00 + 2025-09-26T15:27:56.885992+00:00 - In a recent email exchange, the writer discusses the importance of the V^2 term in providing Sybil protection in JoinMarket coinjoin. They argue that consolidation into fewer makers is not as bad as having no Sybil protection, and the V^2 term penalizes sybil attacks and does more good than harm. The writer also addresses concerns about exchanges running makers and explains that the proposed fidelity bond scheme doesn't make it worse.The email exchange between Dmitry Petukhov and ZmnSCPxj discusses the anti-snitch protection of OP_CHECKSIGVERIFY and OP_CHECKSIG. It is suggested to change the MuSig(all_except_snitch) scheme to 1-of-n multisig construction to prevent issues with multiple snitches. Consolidation can be subsidized by paying rent to consolidators, and the lessee adds its rent payment in the same transaction that atomically instantiates the fidelity bond. Protection from multiple snitches is achieved by using a multitude of taproot leaves.In a recent Bitcoin-dev post, Dmitry Petukhov describes a shared ownership rent scheme where the 'TXO rentier' has a signed timelocked 'backout' transaction that spends the locked TXO and assigns the reward to the rentier. Any transaction that spends any TXO in the bond invalidates the bond when presented to takers. Takers can verify the transaction validity and mark the entire bond as revoked. Verification rules may need to be relaxed or dependent transactions checked to account for backout transactions that are not timelocked themselves.ZmnSCPxj raises concerns about the anti-snitch protection scheme in consolidated bonds in a recent discussion on Bitcoin's mailing list. The current scheme won't work if there are two snitches, and it is proposed to change it to 1-of-n multisig construction. The discussion also highlights the possibility of aggregation by off-blockchain agreements, which could be problematic for the system. Centralized exchanges and custodial services already control TXOs of their customers, which they can use to create fidelity bonds without consent. They may be willing to participate in deanonymization efforts to explain their participation in coinjoins to regulators.ZmnSCPxj proposes a solution to identify and punish snitches who report the consolidation scheme to takers. The participants in the consolidation scheme put up a fraction of the value into revocable bonds, and a punishment transaction divides it equally among the other participants. Participants provide adaptor signatures to their own participant_snitch_key, and if a participant snitches, their previously-shown adaptor signature can be used to reveal the private key behind their participant_snitch_key.The email discusses the problem of fidelity bonds, which are used to ensure makers on Lightning Network remain honest. Several schemes are proposed, including revocation of the whole bond by controlling even a single TXO, shared ownership rent schemes, and encryption with sequential operations. Aggregation is still possible through off-blockchain agreements, which could give entities like exchanges an undeservedly large weight in the fidelity bond system.Chris Belcher has discussed two schemes to prevent easy mindless renting of TXOs. One scheme allows revocation of the whole bond by controlling even a single TXO, while the other requires all locked TXOs to be spendable by any key that controls any TXO in the bond. However, both schemes have limitations and increase risk for the renter and co-rentiers.The email is a response to Chris Belcher's post on bitcoin-dev about the proposed JoinMarket fidelity bonds. ZmnSCPxj discusses the potential weaknesses of the V^2 proposal and suggests an alternative scheme using V^0.999. They also mention ongoing efforts to expand ECDSA to more than two-party n-of-n "true" multisignatures. The risks associated with custodial solutions and non-custodial renting of TXO signatures are also highlighted. The consolidation of makers due to renting TXOs is compared to sybil attacks, and the writer suggests that consolidation may be a lesser evil in terms of privacy-relevant information sharing.In a Bitcoin-dev mailing list, ZmnSCPxj warns about the pooling pressure to proof-of-work caused by tiny non-linearities in fidelity bond schemes. They suggest that any non-linearity exerts the same pooling pressure and propose using V^0.999 instead of V^2. The complexity of 2P-ECDSA is also mentioned, as well as the possibility of using transaction malleability as protection in bond transactions. The concept of "contract law" in the real world is explored as a form of smart contracts.Efforts are being made to expand ECDSA to enable more than two-party n-of-n "true" multisignatures. However, simply banning muSig or using transaction malleability as protection may not be sufficient. Contract law in the real world, which is a half-baked implementation of Bitcoin cryptographic smart contracts, already exists and allows for the acceptance of money with 2019-08-08T20:06:07+00:00 + In a recent email exchange, the writer discusses the importance of the V^2 term in providing Sybil protection in JoinMarket coinjoin. They argue that consolidation into fewer makers is not as bad as having no Sybil protection, and the V^2 term penalizes sybil attacks and does more good than harm. The writer also addresses concerns about exchanges running makers and explains that the proposed fidelity bond scheme doesn't make it worse.The email exchange between Dmitry Petukhov and ZmnSCPxj discusses the anti-snitch protection of OP_CHECKSIGVERIFY and OP_CHECKSIG. It is suggested to change the MuSig(all_except_snitch) scheme to 1-of-n multisig construction to prevent issues with multiple snitches. Consolidation can be subsidized by paying rent to consolidators, and the lessee adds its rent payment in the same transaction that atomically instantiates the fidelity bond. Protection from multiple snitches is achieved by using a multitude of taproot leaves.In a recent Bitcoin-dev post, Dmitry Petukhov describes a shared ownership rent scheme where the 'TXO rentier' has a signed timelocked 'backout' transaction that spends the locked TXO and assigns the reward to the rentier. Any transaction that spends any TXO in the bond invalidates the bond when presented to takers. Takers can verify the transaction validity and mark the entire bond as revoked. Verification rules may need to be relaxed or dependent transactions checked to account for backout transactions that are not timelocked themselves.ZmnSCPxj raises concerns about the anti-snitch protection scheme in consolidated bonds in a recent discussion on Bitcoin's mailing list. The current scheme won't work if there are two snitches, and it is proposed to change it to 1-of-n multisig construction. The discussion also highlights the possibility of aggregation by off-blockchain agreements, which could be problematic for the system. Centralized exchanges and custodial services already control TXOs of their customers, which they can use to create fidelity bonds without consent. They may be willing to participate in deanonymization efforts to explain their participation in coinjoins to regulators.ZmnSCPxj proposes a solution to identify and punish snitches who report the consolidation scheme to takers. The participants in the consolidation scheme put up a fraction of the value into revocable bonds, and a punishment transaction divides it equally among the other participants. Participants provide adaptor signatures to their own participant_snitch_key, and if a participant snitches, their previously-shown adaptor signature can be used to reveal the private key behind their participant_snitch_key.The email discusses the problem of fidelity bonds, which are used to ensure makers on Lightning Network remain honest. Several schemes are proposed, including revocation of the whole bond by controlling even a single TXO, shared ownership rent schemes, and encryption with sequential operations. Aggregation is still possible through off-blockchain agreements, which could give entities like exchanges an undeservedly large weight in the fidelity bond system.Chris Belcher has discussed two schemes to prevent easy mindless renting of TXOs. One scheme allows revocation of the whole bond by controlling even a single TXO, while the other requires all locked TXOs to be spendable by any key that controls any TXO in the bond. However, both schemes have limitations and increase risk for the renter and co-rentiers.The email is a response to Chris Belcher's post on bitcoin-dev about the proposed JoinMarket fidelity bonds. ZmnSCPxj discusses the potential weaknesses of the V^2 proposal and suggests an alternative scheme using V^0.999. They also mention ongoing efforts to expand ECDSA to more than two-party n-of-n "true" multisignatures. The risks associated with custodial solutions and non-custodial renting of TXO signatures are also highlighted. The consolidation of makers due to renting TXOs is compared to sybil attacks, and the writer suggests that consolidation may be a lesser evil in terms of privacy-relevant information sharing.In a Bitcoin-dev mailing list, ZmnSCPxj warns about the pooling pressure to proof-of-work caused by tiny non-linearities in fidelity bond schemes. They suggest that any non-linearity exerts the same pooling pressure and propose using V^0.999 instead of V^2. The complexity of 2P-ECDSA is also mentioned, as well as the possibility of using transaction malleability as protection in bond transactions. The concept of "contract law" in the real world is explored as a form of smart contracts.Efforts are being made to expand ECDSA to enable more than two-party n-of-n "true" multisignatures. However, simply banning muSig or using transaction malleability as protection may not be sufficient. Contract law in the real world, which is a half-baked implementation of Bitcoin cryptographic smart contracts, already exists and allows for the acceptance of money with - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml b/static/bitcoin-dev/July_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml index 33059efccc..580d89e99d 100644 --- a/static/bitcoin-dev/July_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml +++ b/static/bitcoin-dev/July_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) - 2023-08-02T00:56:33.739774+00:00 - - Jeremy 2019-10-03 23:22:47+00:00 - - - Dmitry Petukhov 2019-07-08 10:26:24+00:00 - - - Russell O'Connor 2019-06-25 17:05:39+00:00 - - - Jeremy 2019-06-24 22:47:44+00:00 - - - Russell O'Connor 2019-06-24 18:48:51+00:00 - - - Jeremy 2019-06-24 18:07:20+00:00 - - - Russell O'Connor 2019-06-24 14:34:54+00:00 - - - ZmnSCPxj 2019-06-23 13:11:03+00:00 - - - Jeremy 2019-06-23 06:43:22+00:00 - - - Anthony Towns 2019-06-20 22:05:52+00:00 - - - Russell O'Connor 2019-06-18 20:57:34+00:00 - - - ZmnSCPxj 2019-06-06 07:30:13+00:00 - - - Anthony Towns 2019-06-05 09:30:39+00:00 - - - Jeremy 2019-06-02 21:32:20+00:00 - - - Russell O'Connor 2019-06-02 14:32:33+00:00 - - - ZmnSCPxj 2019-06-02 05:35:43+00:00 - - - Jeremy 2019-06-01 05:35:45+00:00 - + 2025-09-26T15:28:09.653057+00:00 + python-feedgen + + + [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) Jeremy + 2019-06-01T05:35:00.000Z + + + ZmnSCPxj + 2019-06-02T05:35:00.000Z + + + Russell O'Connor + 2019-06-02T14:32:00.000Z + + + Jeremy + 2019-06-02T21:32:00.000Z + + + Anthony Towns + 2019-06-05T09:30:00.000Z + + + ZmnSCPxj + 2019-06-06T07:30:00.000Z + + + Russell O'Connor + 2019-06-18T20:57:00.000Z + + + Anthony Towns + 2019-06-20T22:05:00.000Z + + + Jeremy + 2019-06-23T06:43:00.000Z + + + ZmnSCPxj + 2019-06-23T13:11:00.000Z + + + Russell O'Connor + 2019-06-24T14:34:00.000Z + + + Jeremy + 2019-06-24T18:07:00.000Z + + + Russell O'Connor + 2019-06-24T18:48:00.000Z + + + Jeremy + 2019-06-24T22:47:00.000Z + + + Russell O'Connor + 2019-06-25T17:05:00.000Z + + + Dmitry Petukhov + 2019-07-08T10:26:00.000Z + + + Jeremy + 2019-10-03T23:22:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) - 2023-08-02T00:56:33.739774+00:00 + 2025-09-26T15:28:09.654940+00:00 - Jeremy Rubin has proposed an update to the Bitcoin Improvement Proposal (BIP) that replaces Taproot with an OP_NOP upgrade. The BIP introduces OP_NOP4, which enables the OP_SECURETHEBAG feature for segwit and bare script, but not P2SH. Dmitry Petukhov suggests using a control-sig to restrict spending conditions and proposes additional flags for sighash. Anthony Towns suggests simulating OP_SECURETHEBAG with an ANYPREVOUT sighash. The bitcoin-dev mailing list discusses eliminating malleability in UTXOs using the ANYPREVOUTANYSCRIPT signature and the need for improvements in tapscript implementation. There are suggestions to improve script parsing, versioning techniques, and compatibility with templated scripts. The author of the context argues against the use of OP_IF and proposes upgrading the script parser with a new interpreter for Tapscript. They also discuss the introduction of Turing-completeness in Bitcoin SCRIPT and the potential for creating covenants using OP_TWEEKPUBKEY.The debate revolves around the complexity of changes to Bitcoin Core and the need to ensure script semantics are easily understandable. There is a proposal to add the OP_SECURETHEBAG opcode to modify public keys in Bitcoin script, but concerns are raised about its impact on script composability. The commitment of the script itself is questioned, and suggestions are made to include it in the opcode or use an OP_TWEEKPUBKEY operation. Additionally, the possibility of enabling recursive covenants and making Bitcoin SCRIPT Turing-complete is discussed.An alternative approach using an ANYPREVOUT sighash to simulate OP_SECURETHEBAG is suggested. This involves calculating a signature for a pubkey and using "CHECKSIG" in the script. Issues regarding commitment to inputs and the size of the script are raised. Another proposal for an opcode called OP_CHECKTXDIGESTVERIFY is discussed, which could enable covenants and Turing-complete smart contracts. The debate centers around the need to precommit the digest as part of the opcode.In conclusion, the bitcoin-dev mailing list discusses various proposals and improvements related to script semantics, malleability in UTXOs, and the introduction of new opcodes. The focus is on enhancing tapscript implementation, enabling covenants, and exploring the potential for Turing-completeness in Bitcoin SCRIPT.On May 31, 2019, Jeremy Rubin announced the retraction of the proposed opcode 'OP_CHECKOUTPUTSHASHVERIFY' in favor of a new opcode called 'OP_SECURETHEBAG'. The new opcode aims to fix malleability issues and lift the single output restriction to a known number of inputs restriction. It allows for more flexibility while still keeping the ease of use. The proposed change involves pulling a 33-byte value from the stack, consisting of a sha256 hash and a sighash-byte, and adding a new sighash value corresponding to the set of information to include in the hash.The author acknowledges receiving a response from someone named Russell and admits to having missed some points of concern related to malleability. They provide a code snippet showing how TXID is computed and mention that it can be modified in certain cases, leading to potential security issues. However, the author mentions that they have revisited their work and believe they have addressed all the concerns related to malleability. They express hope that their changes will fully address the issue.The new opcode, OP_SECURETHEBAG, commits to both version and locktime, which was not possible with the previous opcode. It also lifts the restriction on the number of inputs needed, allowing for more flexibility. However, this feature requires special design to be safe, and a backout transaction is required before the funding transaction output is committed onchain. For Poon-Dryja channels, the initial commitment transaction is used as the backout transaction. The continued operation of the protocol requires the initial commitment to be revoked at the next update. A plausible backout for the receiver is needed for this purpose. To do so, the funding transaction address is made a Taproot with an internal pubkey 2-of-2 of the receiver and its channel counterparty.The proposed OP_CHECKOUTPUTSHASHVERIFY has been retracted in favor of the new proposal, OP_SECURETHEBAG. The new proposal fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. The previous proposal had some issues with malleability of version and locktime. OP_SECURETHEBAG commits to both of these values and also lifts the restriction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, and instead just commits to the number of inputs. This allows for more flexibility but keeps it easy to get the same single output restriction.A BIP is available at https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki and the implementation can be found at 2019-10-03T23:22:47+00:00 + Jeremy Rubin has proposed an update to the Bitcoin Improvement Proposal (BIP) that replaces Taproot with an OP_NOP upgrade. The BIP introduces OP_NOP4, which enables the OP_SECURETHEBAG feature for segwit and bare script, but not P2SH. Dmitry Petukhov suggests using a control-sig to restrict spending conditions and proposes additional flags for sighash. Anthony Towns suggests simulating OP_SECURETHEBAG with an ANYPREVOUT sighash. The bitcoin-dev mailing list discusses eliminating malleability in UTXOs using the ANYPREVOUTANYSCRIPT signature and the need for improvements in tapscript implementation. There are suggestions to improve script parsing, versioning techniques, and compatibility with templated scripts. The author of the context argues against the use of OP_IF and proposes upgrading the script parser with a new interpreter for Tapscript. They also discuss the introduction of Turing-completeness in Bitcoin SCRIPT and the potential for creating covenants using OP_TWEEKPUBKEY.The debate revolves around the complexity of changes to Bitcoin Core and the need to ensure script semantics are easily understandable. There is a proposal to add the OP_SECURETHEBAG opcode to modify public keys in Bitcoin script, but concerns are raised about its impact on script composability. The commitment of the script itself is questioned, and suggestions are made to include it in the opcode or use an OP_TWEEKPUBKEY operation. Additionally, the possibility of enabling recursive covenants and making Bitcoin SCRIPT Turing-complete is discussed.An alternative approach using an ANYPREVOUT sighash to simulate OP_SECURETHEBAG is suggested. This involves calculating a signature for a pubkey and using "CHECKSIG" in the script. Issues regarding commitment to inputs and the size of the script are raised. Another proposal for an opcode called OP_CHECKTXDIGESTVERIFY is discussed, which could enable covenants and Turing-complete smart contracts. The debate centers around the need to precommit the digest as part of the opcode.In conclusion, the bitcoin-dev mailing list discusses various proposals and improvements related to script semantics, malleability in UTXOs, and the introduction of new opcodes. The focus is on enhancing tapscript implementation, enabling covenants, and exploring the potential for Turing-completeness in Bitcoin SCRIPT.On May 31, 2019, Jeremy Rubin announced the retraction of the proposed opcode 'OP_CHECKOUTPUTSHASHVERIFY' in favor of a new opcode called 'OP_SECURETHEBAG'. The new opcode aims to fix malleability issues and lift the single output restriction to a known number of inputs restriction. It allows for more flexibility while still keeping the ease of use. The proposed change involves pulling a 33-byte value from the stack, consisting of a sha256 hash and a sighash-byte, and adding a new sighash value corresponding to the set of information to include in the hash.The author acknowledges receiving a response from someone named Russell and admits to having missed some points of concern related to malleability. They provide a code snippet showing how TXID is computed and mention that it can be modified in certain cases, leading to potential security issues. However, the author mentions that they have revisited their work and believe they have addressed all the concerns related to malleability. They express hope that their changes will fully address the issue.The new opcode, OP_SECURETHEBAG, commits to both version and locktime, which was not possible with the previous opcode. It also lifts the restriction on the number of inputs needed, allowing for more flexibility. However, this feature requires special design to be safe, and a backout transaction is required before the funding transaction output is committed onchain. For Poon-Dryja channels, the initial commitment transaction is used as the backout transaction. The continued operation of the protocol requires the initial commitment to be revoked at the next update. A plausible backout for the receiver is needed for this purpose. To do so, the funding transaction address is made a Taproot with an internal pubkey 2-of-2 of the receiver and its channel counterparty.The proposed OP_CHECKOUTPUTSHASHVERIFY has been retracted in favor of the new proposal, OP_SECURETHEBAG. The new proposal fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. The previous proposal had some issues with malleability of version and locktime. OP_SECURETHEBAG commits to both of these values and also lifts the restriction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, and instead just commits to the number of inputs. This allows for more flexibility but keeps it easy to get the same single output restriction.A BIP is available at https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki and the implementation can be found at - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_Proposed-Extensions-to-BIP-174-for-Future-Extensibility.xml b/static/bitcoin-dev/July_2019/combined_Proposed-Extensions-to-BIP-174-for-Future-Extensibility.xml index 3ff0acd039..c383501570 100644 --- a/static/bitcoin-dev/July_2019/combined_Proposed-Extensions-to-BIP-174-for-Future-Extensibility.xml +++ b/static/bitcoin-dev/July_2019/combined_Proposed-Extensions-to-BIP-174-for-Future-Extensibility.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Proposed Extensions to BIP 174 for Future Extensibility - 2023-08-02T01:13:15.378026+00:00 - - Jonathan Underwood 2019-08-04 00:15:17+00:00 - - - Dmitry Petukhov 2019-08-02 09:18:36+00:00 - - - Andrew Chow 2019-08-01 19:01:06+00:00 - - - Andrew Chow 2019-08-01 17:57:26+00:00 - - - Stepan Snigirev 2019-08-01 13:50:47+00:00 - - - Andrew Chow 2019-07-31 19:16:36+00:00 - - - Dmitry Petukhov 2019-07-31 16:19:48+00:00 - - - jan matejek 2019-07-31 14:32:00+00:00 - - - Andrew Chow 2019-07-31 01:13:46+00:00 - + 2025-09-26T15:28:13.842133+00:00 + python-feedgen + + + [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility Andrew Chow + 2019-07-31T01:13:00.000Z + + + jan matejek + 2019-07-31T14:32:00.000Z + + + Dmitry Petukhov + 2019-07-31T16:19:00.000Z + + + Andrew Chow + 2019-07-31T19:16:00.000Z + + + Stepan Snigirev + 2019-08-01T13:50:00.000Z + + + Andrew Chow + 2019-08-01T17:57:00.000Z + + + Andrew Chow + 2019-08-01T19:01:00.000Z + + + Dmitry Petukhov + 2019-08-02T09:18:00.000Z + + + Jonathan Underwood + 2019-08-04T00:15:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Proposed Extensions to BIP 174 for Future Extensibility - 2023-08-02T01:13:15.378026+00:00 + 2025-09-26T15:28:13.843250+00:00 - The email thread discusses the idea of having a prefix string in BIP174 and how it adds complexity to parser code. Some people are against the idea, while others argue that the benefit for the whole industry is greater if there is a conflict-avoidance prefix. The author suggests using a specific type for all (global, input, and output) in BIP174, which means "see the BIP numbered in the next byte." This would allow for a BIP43-ish system for BIP174. The author also mentions that POR COMMITMENT and their current signature protocol proposal should go in there. They will keep an eye on the bips repo and implement it if someone pings them once things settle down.In a discussion about implementing a prefix string for private types, Andrew Chow spoke to some individuals who didn't like the idea because they had already created proprietary types without a prefix. This would add additional complexity to the parser code. However, others suggested that those who didn't want the added complexity could simply ignore it altogether. Since this is a private construction, and their private format specifies 'no prefix,' they can just disregard everything that doesn't start with "{0xFC}|{0x00}". The only added complexity would be one condition check. Others argued that having a conflict-avoidance prefix as the first thing after 0xFC would benefit more people in the industry than those who have already implemented proprietary types. Those who don't want to use the prefix can set it to 0x00, and the set of possible conflicting types are limited only to those entities that made this explicit decision. As for those who have already created squatted types, it only matters if they squatted on the 0xFC type in particular. In other cases, they will need to implement changes anyway to be compatible with the BIP. It was suggested that they consider the small burden of one additional condition check for the benefit of reducing interoperability problems between future PSBT/private types implementers.After speaking to some individuals, Andrew Chow has decided to simplify the implementation of proprietary types in Bitcoin by not using a prefix string. Instead, he suggests using {0xFC}|{private_type} with an optional prefix string that is strongly recommended. The concern was that people would use unused type values instead of following the specification for proprietary types, which would add complexity to the parser code. Since public parsers will not be enforcing the rules for proprietary types, it does not make sense to specify and enforce how they should be. The key is just an opaque data blob. Andrew also confirms that Compact Size Unsigned Integers will be used for the field types and will be minimally encoded CSUints. For proprietary types, there will only be one proprietary type, 0xFC, followed by a variable length string that serves as a unique identifier to prevent usage of proprietary types outside of private contexts. The actual type for data will then follow, defined by the user of the proprietary type. The prefix will just be a string, prefixed with a compact size unsigned integer. If no prefix is wanted, a single 0x00 byte can be used. It's important to note that for public software, these proprietary types don't need to be handled at all. Therefore, they do not need to check the string or the data type. Although it is not necessary to enforce the above rules about proprietary types, it is necessary to use the proprietary type value.It has been decided that Compact Size Unsigned Integers will be used for field types in an upcoming project. For proprietary types, one suggestion is to use a unique identifier, in the form of a variable length string prefixed with a compact size unsigned integer, followed by the actual type for the data as defined by the user. This will help prevent usage of proprietary types outside of private contexts. A single 0x00 byte can be used if no prefix is wanted. Public software does not need to handle these proprietary types and does not need to enforce the above rules except for the use of the proprietary type value.The suggestion has been made to use Bitcoin compact uint, which is already implemented in all bitcoin applications, wallets and libraries. This would be a logical choice for PSBT consumers. For certain proprietary applications, multi-byte keys could also be used where the first byte defines the application type and the next bytes define application-specific fields. It is recommended to set proprietary bytes to 0xF0-0xFC or 0xE0-0xEF, possibly using E for Enterprise.In a Bitcoin Development email thread, Dmitry Petukhov suggested that private formats should have at least a basic format with a prefix to distinguish different private formats and avoid unintentional confusion. He proposed that private types can start with the size of the prefix, allowing organizations to choose any prefix they like or no prefix if they are fine with possible conflicts with other empty-prefix private types. However, Andrew disagreed that this should be required and suggested it could be strongly recommended 2019-08-04T00:15:17+00:00 + The email thread discusses the idea of having a prefix string in BIP174 and how it adds complexity to parser code. Some people are against the idea, while others argue that the benefit for the whole industry is greater if there is a conflict-avoidance prefix. The author suggests using a specific type for all (global, input, and output) in BIP174, which means "see the BIP numbered in the next byte." This would allow for a BIP43-ish system for BIP174. The author also mentions that POR COMMITMENT and their current signature protocol proposal should go in there. They will keep an eye on the bips repo and implement it if someone pings them once things settle down.In a discussion about implementing a prefix string for private types, Andrew Chow spoke to some individuals who didn't like the idea because they had already created proprietary types without a prefix. This would add additional complexity to the parser code. However, others suggested that those who didn't want the added complexity could simply ignore it altogether. Since this is a private construction, and their private format specifies 'no prefix,' they can just disregard everything that doesn't start with "{0xFC}|{0x00}". The only added complexity would be one condition check. Others argued that having a conflict-avoidance prefix as the first thing after 0xFC would benefit more people in the industry than those who have already implemented proprietary types. Those who don't want to use the prefix can set it to 0x00, and the set of possible conflicting types are limited only to those entities that made this explicit decision. As for those who have already created squatted types, it only matters if they squatted on the 0xFC type in particular. In other cases, they will need to implement changes anyway to be compatible with the BIP. It was suggested that they consider the small burden of one additional condition check for the benefit of reducing interoperability problems between future PSBT/private types implementers.After speaking to some individuals, Andrew Chow has decided to simplify the implementation of proprietary types in Bitcoin by not using a prefix string. Instead, he suggests using {0xFC}|{private_type} with an optional prefix string that is strongly recommended. The concern was that people would use unused type values instead of following the specification for proprietary types, which would add complexity to the parser code. Since public parsers will not be enforcing the rules for proprietary types, it does not make sense to specify and enforce how they should be. The key is just an opaque data blob. Andrew also confirms that Compact Size Unsigned Integers will be used for the field types and will be minimally encoded CSUints. For proprietary types, there will only be one proprietary type, 0xFC, followed by a variable length string that serves as a unique identifier to prevent usage of proprietary types outside of private contexts. The actual type for data will then follow, defined by the user of the proprietary type. The prefix will just be a string, prefixed with a compact size unsigned integer. If no prefix is wanted, a single 0x00 byte can be used. It's important to note that for public software, these proprietary types don't need to be handled at all. Therefore, they do not need to check the string or the data type. Although it is not necessary to enforce the above rules about proprietary types, it is necessary to use the proprietary type value.It has been decided that Compact Size Unsigned Integers will be used for field types in an upcoming project. For proprietary types, one suggestion is to use a unique identifier, in the form of a variable length string prefixed with a compact size unsigned integer, followed by the actual type for the data as defined by the user. This will help prevent usage of proprietary types outside of private contexts. A single 0x00 byte can be used if no prefix is wanted. Public software does not need to handle these proprietary types and does not need to enforce the above rules except for the use of the proprietary type value.The suggestion has been made to use Bitcoin compact uint, which is already implemented in all bitcoin applications, wallets and libraries. This would be a logical choice for PSBT consumers. For certain proprietary applications, multi-byte keys could also be used where the first byte defines the application type and the next bytes define application-specific fields. It is recommended to set proprietary bytes to 0xF0-0xFC or 0xE0-0xEF, possibly using E for Enterprise.In a Bitcoin Development email thread, Dmitry Petukhov suggested that private formats should have at least a basic format with a prefix to distinguish different private formats and avoid unintentional confusion. He proposed that private types can start with the size of the prefix, allowing organizations to choose any prefix they like or no prefix if they are fine with possible conflicts with other empty-prefix private types. However, Andrew disagreed that this should be required and suggested it could be strongly recommended - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_PubRef-Script-OP-Code-For-Public-Data-References.xml b/static/bitcoin-dev/July_2019/combined_PubRef-Script-OP-Code-For-Public-Data-References.xml index 65424ac1d8..de9ca1ab5b 100644 --- a/static/bitcoin-dev/July_2019/combined_PubRef-Script-OP-Code-For-Public-Data-References.xml +++ b/static/bitcoin-dev/July_2019/combined_PubRef-Script-OP-Code-For-Public-Data-References.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - PubRef - Script OP Code For Public Data References - 2023-08-02T01:06:50.402358+00:00 - - ZmnSCPxj 2019-07-29 03:39:15+00:00 - - - Mike Brooks 2019-07-29 03:07:01+00:00 - - - ZmnSCPxj 2019-07-29 02:49:04+00:00 - - - Mike Brooks 2019-07-29 02:19:55+00:00 - - - ZmnSCPxj 2019-07-29 01:46:40+00:00 - - - Mike Brooks 2019-07-27 20:03:39+00:00 - - - Mike Brooks 2019-07-24 19:49:05+00:00 - - - Yuval Kogman 2019-07-19 22:48:43+00:00 - - - Pieter Wuille 2019-07-19 19:17:38+00:00 - - - ZmnSCPxj 2019-07-19 18:07:56+00:00 - - - Yuval Kogman 2019-07-19 17:45:17+00:00 - - - William Casarin 2019-07-19 15:17:22+00:00 - - - Mike Brooks 2019-07-19 06:05:42+00:00 - + 2025-09-26T15:28:05.407302+00:00 + python-feedgen + + + [bitcoin-dev] PubRef - Script OP Code For Public Data References Mike Brooks + 2019-07-19T06:05:00.000Z + + + William Casarin + 2019-07-19T15:17:00.000Z + + + Yuval Kogman + 2019-07-19T17:45:00.000Z + + + ZmnSCPxj + 2019-07-19T18:07:00.000Z + + + Pieter Wuille + 2019-07-19T19:17:00.000Z + + + Yuval Kogman + 2019-07-19T22:48:00.000Z + + + Mike Brooks + 2019-07-24T19:49:00.000Z + + + Mike Brooks + 2019-07-27T20:03:00.000Z + + + ZmnSCPxj + 2019-07-29T01:46:00.000Z + + + Mike Brooks + 2019-07-29T02:19:00.000Z + + + ZmnSCPxj + 2019-07-29T02:49:00.000Z + + + Mike Brooks + 2019-07-29T03:07:00.000Z + + + ZmnSCPxj + 2019-07-29T03:39:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - PubRef - Script OP Code For Public Data References - 2023-08-02T01:06:50.403273+00:00 + 2025-09-26T15:28:05.408800+00:00 - In a recent conversation between Mike and ZmnSCPxj, the topic of transaction pruning in Bitcoin Core was discussed. Pruning involves discarding transaction data after validation while keeping only the UTXO set. However, ZmnSCPxj raised concerns about the future use of pruned data in a potential `OP_PUBREF` referencing pruned blocks. They suggested that a consensus rule should be established to determine how pruned validators can access necessary data. ZmnSCPxj and Mike also discussed the potential implications of using `OP_PUBREF` on the blockchain. They noted that current applications using txids to refer to previous transactions would not be affected by short-ranged history rewrites. However, there is a potential for a targeted attack where a large payout going to a `scriptPubKey` that uses `OP_PUBREF` on a recently-confirmed transaction is replaced with one that pays to a different public key through a history-rewrite attack. The suggestion was made to consider a "deeply-confirmed" point, such as 100 blocks, to mitigate this risk. The conversation also touched on the challenge of dealing with large data sets and the need to account for real-world limits on computability. Projects like Apache HTTPD's Bucket-Brigade and leveldb have addressed these challenges. Pruning was seen as an asset for PubRef but posed a problem if necessary data from pruned transactions is needed in the future.The discussion between Mike and ZmnSCPxj highlighted the potential attacks on the blockchain due to the use of `OP_PUBREF`. It was suggested that 100 blocks might be an acceptable time frame for such attacks, similar to the acceptance of miner coinbase maturity. There were concerns about the size of the data set required for validating scripts and the need for pruning to address this. However, it was noted that current pruned nodes did not retain the necessary data and would need to re-download the entire blockchain.In the email exchange, Mike and ZmnSCPxj discussed the potential benefits and drawbacks of adding `OP_PUBREF` to the SCRIPT language used in Bitcoin transactions. They explored the possibility of compressing SegWit transactions and reducing costs without compromising privacy. However, concerns were raised about address reuse and the limited access to transaction data within a SCRIPT. The computational effort required to maintain a database resolving public references was also noted. It was suggested that the validity of a PUBREF index should be re-evaluated during chain tip reorganizations unless a certain number of blocks have confirmed the data.The conversation between Mike Brooks and ZmnSCPxj delved into the potential adoption of a new opcode that would allow scripts to refer to data on the blockchain. While this could reduce transaction sizes and save costs, there were concerns about address reuse and the increased validation costs and storage requirements. Other proposals like batching, lightning, MAST, Schnorr signatures, and taproot/graftroot were mentioned as alternatives to address these issues.The idea of introducing an opcode to allow scripts to refer to blockchain data was discussed in the bitcoin-dev mailing list. Mike Brooks proposed this feature to reduce transaction sizes, but concerns were raised about incentivizing address reuse and increasing storage requirements for validation. Alternative approaches were suggested, such as optional functionality in the p2p layer and encoding transaction IDs differently to save space.The accuracy of the statement that PubRef is not susceptible to malleability attacks due to the immutability of the blockchain was questioned. It was pointed out that chain tips are not immutable and can be replaced, so data referenced using PubRef can only be accessed if buried under 100 blocks. Concerns about pubkey reuse and the need for additional databases and computational effort to resolve PubRef indices were also raised.In the bitcoin-dev mailing list discussion, Mike Brooks proposed giving scripts the ability to refer to data on the blockchain. However, another participant named Yuval expressed skepticism about the actual utilization of this feature and raised concerns about address reuse, validation costs, and storage requirements. Alternative approaches, such as incorporating the functionality in the p2p layer, were suggested.The proposal to introduce an opcode allowing scripts to reference data on the blockchain was discussed in the bitcoin-dev community. The aim was to reduce transaction sizes and enable miners to include more transactions in blocks. However, concerns were raised about incentivizing address re-use and the impact on fungibility. The proposal also faced challenges in terms of increased validation costs and storage requirements for historical data.In the discussion on the bitcoin-dev mailing list, a proposal was made to give scripts the ability to refer to data on the blockchain, which could reduce transaction sizes and improve block space efficiency. However, concerns were raised about the potential for address re-use and the storage requirements for validating nodes. Alternative approaches, such as optional functionality in the p2p layer, were suggested to address these concerns.The proposal to allow scripts to reference data on the 2019-07-29T03:39:15+00:00 + In a recent conversation between Mike and ZmnSCPxj, the topic of transaction pruning in Bitcoin Core was discussed. Pruning involves discarding transaction data after validation while keeping only the UTXO set. However, ZmnSCPxj raised concerns about the future use of pruned data in a potential `OP_PUBREF` referencing pruned blocks. They suggested that a consensus rule should be established to determine how pruned validators can access necessary data. ZmnSCPxj and Mike also discussed the potential implications of using `OP_PUBREF` on the blockchain. They noted that current applications using txids to refer to previous transactions would not be affected by short-ranged history rewrites. However, there is a potential for a targeted attack where a large payout going to a `scriptPubKey` that uses `OP_PUBREF` on a recently-confirmed transaction is replaced with one that pays to a different public key through a history-rewrite attack. The suggestion was made to consider a "deeply-confirmed" point, such as 100 blocks, to mitigate this risk. The conversation also touched on the challenge of dealing with large data sets and the need to account for real-world limits on computability. Projects like Apache HTTPD's Bucket-Brigade and leveldb have addressed these challenges. Pruning was seen as an asset for PubRef but posed a problem if necessary data from pruned transactions is needed in the future.The discussion between Mike and ZmnSCPxj highlighted the potential attacks on the blockchain due to the use of `OP_PUBREF`. It was suggested that 100 blocks might be an acceptable time frame for such attacks, similar to the acceptance of miner coinbase maturity. There were concerns about the size of the data set required for validating scripts and the need for pruning to address this. However, it was noted that current pruned nodes did not retain the necessary data and would need to re-download the entire blockchain.In the email exchange, Mike and ZmnSCPxj discussed the potential benefits and drawbacks of adding `OP_PUBREF` to the SCRIPT language used in Bitcoin transactions. They explored the possibility of compressing SegWit transactions and reducing costs without compromising privacy. However, concerns were raised about address reuse and the limited access to transaction data within a SCRIPT. The computational effort required to maintain a database resolving public references was also noted. It was suggested that the validity of a PUBREF index should be re-evaluated during chain tip reorganizations unless a certain number of blocks have confirmed the data.The conversation between Mike Brooks and ZmnSCPxj delved into the potential adoption of a new opcode that would allow scripts to refer to data on the blockchain. While this could reduce transaction sizes and save costs, there were concerns about address reuse and the increased validation costs and storage requirements. Other proposals like batching, lightning, MAST, Schnorr signatures, and taproot/graftroot were mentioned as alternatives to address these issues.The idea of introducing an opcode to allow scripts to refer to blockchain data was discussed in the bitcoin-dev mailing list. Mike Brooks proposed this feature to reduce transaction sizes, but concerns were raised about incentivizing address reuse and increasing storage requirements for validation. Alternative approaches were suggested, such as optional functionality in the p2p layer and encoding transaction IDs differently to save space.The accuracy of the statement that PubRef is not susceptible to malleability attacks due to the immutability of the blockchain was questioned. It was pointed out that chain tips are not immutable and can be replaced, so data referenced using PubRef can only be accessed if buried under 100 blocks. Concerns about pubkey reuse and the need for additional databases and computational effort to resolve PubRef indices were also raised.In the bitcoin-dev mailing list discussion, Mike Brooks proposed giving scripts the ability to refer to data on the blockchain. However, another participant named Yuval expressed skepticism about the actual utilization of this feature and raised concerns about address reuse, validation costs, and storage requirements. Alternative approaches, such as incorporating the functionality in the p2p layer, were suggested.The proposal to introduce an opcode allowing scripts to reference data on the blockchain was discussed in the bitcoin-dev community. The aim was to reduce transaction sizes and enable miners to include more transactions in blocks. However, concerns were raised about incentivizing address re-use and the impact on fungibility. The proposal also faced challenges in terms of increased validation costs and storage requirements for historical data.In the discussion on the bitcoin-dev mailing list, a proposal was made to give scripts the ability to refer to data on the blockchain, which could reduce transaction sizes and improve block space efficiency. However, concerns were raised about the potential for address re-use and the storage requirements for validating nodes. Alternative approaches, such as optional functionality in the p2p layer, were suggested to address these concerns.The proposal to allow scripts to reference data on the - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2019/combined_Secure-Proof-Of-Stake-implementation-on-Bitcoin.xml b/static/bitcoin-dev/July_2019/combined_Secure-Proof-Of-Stake-implementation-on-Bitcoin.xml index 4bd970af77..7e3686b5e1 100644 --- a/static/bitcoin-dev/July_2019/combined_Secure-Proof-Of-Stake-implementation-on-Bitcoin.xml +++ b/static/bitcoin-dev/July_2019/combined_Secure-Proof-Of-Stake-implementation-on-Bitcoin.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Secure Proof Of Stake implementation on Bitcoin - 2023-08-02T01:06:23.028850+00:00 - - Kenshiro [] 2019-07-24 09:30:46+00:00 - - - ZmnSCPxj 2019-07-24 04:14:38+00:00 - - - Kenshiro [] 2019-07-20 13:00:51+00:00 - - - ZmnSCPxj 2019-07-20 11:07:14+00:00 - - - Kenshiro [] 2019-07-20 10:37:17+00:00 - - - ZmnSCPxj 2019-07-20 00:45:32+00:00 - - - Kenshiro [] 2019-07-19 10:24:59+00:00 - - - Kenshiro [] 2019-07-19 09:48:26+00:00 - - - Eric Voskuil 2019-07-19 05:10:30+00:00 - - - ZmnSCPxj 2019-07-19 03:45:03+00:00 - - - Kenshiro [] 2019-07-18 15:50:35+00:00 - - - ZmnSCPxj 2019-07-18 14:15:05+00:00 - - - Kenshiro [] 2019-07-18 09:58:59+00:00 - - - ZmnSCPxj 2019-07-18 01:13:27+00:00 - - - Eric Voskuil 2019-07-17 12:02:29+00:00 - - - Kenshiro [] 2019-07-17 10:10:23+00:00 - - - ZmnSCPxj 2019-07-17 08:11:26+00:00 - - - ZmnSCPxj 2019-07-16 23:00:02+00:00 - - - Kenshiro [] 2019-07-16 21:28:01+00:00 - - - Oscar Lafarga 2019-07-16 20:35:21+00:00 - - - Kenshiro [] 2019-07-11 15:16:40+00:00 - + 2025-09-26T15:28:01.123808+00:00 + python-feedgen + + + [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Kenshiro [] + 2019-07-11T15:16:00.000Z + + + Oscar Lafarga + 2019-07-16T20:35:00.000Z + + + Kenshiro [] + 2019-07-16T21:28:00.000Z + + + ZmnSCPxj + 2019-07-16T23:00:00.000Z + + + ZmnSCPxj + 2019-07-17T08:11:00.000Z + + + Kenshiro [] + 2019-07-17T10:10:00.000Z + + + Eric Voskuil + 2019-07-17T12:02:00.000Z + + + ZmnSCPxj + 2019-07-18T01:13:00.000Z + + + Kenshiro [] + 2019-07-18T09:58:00.000Z + + + ZmnSCPxj + 2019-07-18T14:15:00.000Z + + + Kenshiro [] + 2019-07-18T15:50:00.000Z + + + ZmnSCPxj + 2019-07-19T03:45:00.000Z + + + Eric Voskuil + 2019-07-19T05:10:00.000Z + + + Kenshiro [] + 2019-07-19T09:48:00.000Z + + + Kenshiro [] + 2019-07-19T10:24:00.000Z + + + ZmnSCPxj + 2019-07-20T00:45:00.000Z + + + Kenshiro [] + 2019-07-20T10:37:00.000Z + + + ZmnSCPxj + 2019-07-20T11:07:00.000Z + + + Kenshiro [] + 2019-07-20T13:00:00.000Z + + + ZmnSCPxj + 2019-07-24T04:14:00.000Z + + + Kenshiro [] + 2019-07-24T09:30:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Secure Proof Of Stake implementation on Bitcoin - 2023-08-02T01:06:23.028850+00:00 + 2025-09-26T15:28:01.126032+00:00 - The email thread discusses the implementation of Proof of Stake (PoS) in Bitcoin and its advantages and drawbacks compared to Proof of Work (PoW). Kenshiro suggests using PoS v3.0 with additional improvements such as hardcoded checkpoints and the ability to detect transaction censorship. However, ZmnSCPxj argues that PoW is more efficient and secure due to the trust-minimization and uncensorability requirements of Bitcoin. ZmnSCPxj also points out flaws in Kenshiro's proposed improvements, including the need to trust developers and vulnerability to censorship attacks.The discussion highlights potential risks of PoS, including stake-grinding attacks and the possibility of a single entity controlling more than 51% of stakeable coins. The email thread emphasizes the trade-offs between PoW and PoS and the challenges of achieving a secure and decentralized consensus algorithm.The writer of the original email suggests that PoS could be a secure and eco-friendly alternative to PoW. They propose using PoS v3.0 with hardcoded checkpoints and a block explorer or trusted source to verify the hash of the current block height. However, ZmnSCPxj argues that PoW is more efficient and provides uncensorability. They also highlight the difficulty of detecting if a single entity controls more than 51% of stakeable coins under PoS, making it vulnerable to censorship attacks.In another email conversation, Kenshiro proposes a full change to the PoS protocol to prevent energy waste and 51% history rewrite attacks. Kenshiro suggests implementing hardcoded checkpoints and allowing only one staker to create a block in each block, preventing spamming by other stakers. However, Oscar Lafarga raises concerns about the security risk introduced by block explorers and the Bitcoin Core release dispatch system. Lafarga questions the usefulness of similar checkpointing schemes in improving the Bitcoin network.Lafarga notes that the proposed PoS implementation would operate as an addition to the current PoW consensus code. They caution against introducing block explorers and dispatch systems, which could reduce the trustlessness of the network. Lafarga also highlights past cases where similar checkpointing schemes weakened consensus without improving the network.The writer suggests that correctly implemented PoS could be secure against 51% history rewrite attacks. They propose hardcoded checkpoints and moving checkpoints as improvements to protect the blockchain and prevent long-range attacks. Nodes would only allow chain reorganizations not deeper than a certain number of blocks. The writer concludes that even with a large majority of coins, an attacker would be unable to perform a history rewrite attack, only slowing down the network or censoring transactions in their own blocks. 2019-07-24T09:30:46+00:00 + The email thread discusses the implementation of Proof of Stake (PoS) in Bitcoin and its advantages and drawbacks compared to Proof of Work (PoW). Kenshiro suggests using PoS v3.0 with additional improvements such as hardcoded checkpoints and the ability to detect transaction censorship. However, ZmnSCPxj argues that PoW is more efficient and secure due to the trust-minimization and uncensorability requirements of Bitcoin. ZmnSCPxj also points out flaws in Kenshiro's proposed improvements, including the need to trust developers and vulnerability to censorship attacks.The discussion highlights potential risks of PoS, including stake-grinding attacks and the possibility of a single entity controlling more than 51% of stakeable coins. The email thread emphasizes the trade-offs between PoW and PoS and the challenges of achieving a secure and decentralized consensus algorithm.The writer of the original email suggests that PoS could be a secure and eco-friendly alternative to PoW. They propose using PoS v3.0 with hardcoded checkpoints and a block explorer or trusted source to verify the hash of the current block height. However, ZmnSCPxj argues that PoW is more efficient and provides uncensorability. They also highlight the difficulty of detecting if a single entity controls more than 51% of stakeable coins under PoS, making it vulnerable to censorship attacks.In another email conversation, Kenshiro proposes a full change to the PoS protocol to prevent energy waste and 51% history rewrite attacks. Kenshiro suggests implementing hardcoded checkpoints and allowing only one staker to create a block in each block, preventing spamming by other stakers. However, Oscar Lafarga raises concerns about the security risk introduced by block explorers and the Bitcoin Core release dispatch system. Lafarga questions the usefulness of similar checkpointing schemes in improving the Bitcoin network.Lafarga notes that the proposed PoS implementation would operate as an addition to the current PoW consensus code. They caution against introducing block explorers and dispatch systems, which could reduce the trustlessness of the network. Lafarga also highlights past cases where similar checkpointing schemes weakened consensus without improving the network.The writer suggests that correctly implemented PoS could be secure against 51% history rewrite attacks. They propose hardcoded checkpoints and moving checkpoints as improvements to protect the blockchain and prevent long-range attacks. Nodes would only allow chain reorganizations not deeper than a certain number of blocks. The writer concludes that even with a large majority of coins, an attacker would be unable to perform a history rewrite attack, only slowing down the network or censoring transactions in their own blocks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_BIP-118-and-SIGHASH-ANYPREVOUT.xml b/static/bitcoin-dev/July_2020/combined_BIP-118-and-SIGHASH-ANYPREVOUT.xml index 5343115693..588f68ef0c 100644 --- a/static/bitcoin-dev/July_2020/combined_BIP-118-and-SIGHASH-ANYPREVOUT.xml +++ b/static/bitcoin-dev/July_2020/combined_BIP-118-and-SIGHASH-ANYPREVOUT.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - BIP 118 and SIGHASH_ANYPREVOUT - 2023-08-02T02:29:39.241532+00:00 - - Matt Corallo 2020-08-11 00:14:29+00:00 - - - Richard Myers 2020-08-07 15:34:43+00:00 - - - Matt Corallo 2020-08-06 15:58:53+00:00 - - - ZmnSCPxj 2020-08-04 14:59:52+00:00 - - - Matt Corallo 2020-08-04 13:10:02+00:00 - - - Christian Decker 2020-08-04 10:38:20+00:00 - - - ZmnSCPxj 2020-08-04 04:23:03+00:00 - - - lf-lists at mattcorallo.com 2020-08-04 04:02:21+00:00 - - - ZmnSCPxj 2020-08-04 01:38:55+00:00 - - - Richard Myers 2020-08-03 19:27:13+00:00 - - - Christian Decker 2020-07-10 07:46:54+00:00 - - - ZmnSCPxj 2020-07-10 03:29:39+00:00 - - - Anthony Towns 2020-07-09 22:30:50+00:00 - - - Anthony Towns 2020-07-09 21:40:48+00:00 - + 2025-09-26T15:53:32.103072+00:00 + python-feedgen + + + [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns + 2020-07-09T21:40:00.000Z + + + Anthony Towns + 2020-07-09T22:30:00.000Z + + + ZmnSCPxj + 2020-07-10T03:29:00.000Z + + + Christian Decker + 2020-07-10T07:46:00.000Z + + + Richard Myers + 2020-08-03T19:27:00.000Z + + + ZmnSCPxj + 2020-08-04T01:38:00.000Z + + + lf-lists + 2020-08-04T04:02:00.000Z + + + ZmnSCPxj + 2020-08-04T04:23:00.000Z + + + Christian Decker + 2020-08-04T10:38:00.000Z + + + Matt Corallo + 2020-08-04T13:10:00.000Z + + + ZmnSCPxj + 2020-08-04T14:59:00.000Z + + + Matt Corallo + 2020-08-06T15:58:00.000Z + + + Richard Myers + 2020-08-07T15:34:00.000Z + + + Matt Corallo + 2020-08-11T00:14:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - BIP 118 and SIGHASH_ANYPREVOUT - 2023-08-02T02:29:39.241532+00:00 + 2025-09-26T15:53:32.104618+00:00 - In a recent conversation on the Bitcoin-dev mailing list, Matt Corallo discussed the potential of a relay network that could handle transactions with SIGHASH_ANYPREVOUT. This network would need to rewrite transactions before passing them on to a local bitcoind. The idea is that a sender could relay a transaction with one input that is valid for any output index 0 in a transaction spending output B. The receiver would then look up which transaction spends output B and fill in the input with that outpoint.Richard Myers asked if such a relay network could be more "smart about replacement" in the context of ANYPREVOUT by RBF-ing parts of a package. Matt responded that SIGHASH_NOINPUT would simplify these issues if nodes could be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. However, shoving this complexity into the Bitcoin P2P network may not be feasible. Instead, a relay network of lightning nodes could potentially handle the calculation and pass the transactions to their local full nodes.In the context of ANYPREVOUT*, a special relay network could be more intelligent about replacement. This would involve relaying only the higher up-front fee-rate transactions from a lower total fee package (Package B) which get spent by the high absolute fee child transactions from a higher total fee package (Package A). The result is Package A', which includes the higher fee rate versions of the ANYPREVOUT* transactions from Package B, but with an overall lower total fee. However, implementing this solution requires nodes to be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else in the mempool already spends.The conversation between Matt and ZmnSCPxj revolves around a relay-based attack that can compromise HTLC security in the Lightning Network. The attacker connects twice to the LN - once to any node near the victim and once to the victim. The attacker arranges for the victim-attacker channel to have most funds on the victim's side and routes a circular payment terminating in the victim-attacker channel. The attacker broadcasts a very low-fee old-state transaction of the victim-attacker channel just before the HTLC timeout, forcing the victim to broadcast a unilateral close attempt for the victim-attacker channel to enforce the HTLC on-chain. However, relay shenanigans prevent the latest commitment from being broadcast, leaving the victim at risk.ZmnSCPxj suggests that forwarding nodes drop channels on-chain "early" if the HTLC will time out soon. Matt notes that SIGHASH_NOINPUT makes these issues much simpler to address if nodes can be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. They also discuss the possibility of an overlay relay network of lightning nodes that do calculation and pass transactions to their local full nodes.Christian discusses a feasible attack that can be executed without the victim's knowledge in a Lightning universe primarily utilizing SIGHASH_NOINPUT-based mechanisms. He suggests monitoring on-chain events and ignoring mempool events to react to confirmed transactions. To ensure security, deep timeouts for mechanisms are necessary so that a SIGHASH_NOINPUT signature can be "locked" to a confirmed txid, unless a reorg unconfirms the transaction. Additionally, implementing scorch-the-earth, keep-bumping-the-fee strategies can help keep rebroadcasting new versions of the spending transaction.In the context of recent relay-based attacks, there have been concerns about the security of Hash Time-Locked Contract (HTLC) transactions. ZmnSCPxj raises a design consideration for the p2p protocol layer that would allow relaying a transaction to a full node without knowing which input transaction that full node has in its mempool or active chain. This is important for systems like lighting where you may not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending them nonetheless.Richard expresses his interest in implementing a Taproot version of Decker-Russell-Osuntokun (eltoo) and discusses the differences between ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and their exploitation. ZmnSCPxj provides clarifications on key-path spending, reducing the round trips for MuSig signing sessions, and the security implications of chaperone signatures for SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT. They also discuss the implementation of scorch-the-earth, keep-bumping-the-fee strategies.In another email thread, Anthony Towns opens a draft pull request to update BIP 118 with the ANYPREVOUT bip, including significant changes since previous discussions. The complete lack of chaperone signatures in the new BIP text is noted.Overall, 2020-08-11T00:14:29+00:00 + In a recent conversation on the Bitcoin-dev mailing list, Matt Corallo discussed the potential of a relay network that could handle transactions with SIGHASH_ANYPREVOUT. This network would need to rewrite transactions before passing them on to a local bitcoind. The idea is that a sender could relay a transaction with one input that is valid for any output index 0 in a transaction spending output B. The receiver would then look up which transaction spends output B and fill in the input with that outpoint.Richard Myers asked if such a relay network could be more "smart about replacement" in the context of ANYPREVOUT by RBF-ing parts of a package. Matt responded that SIGHASH_NOINPUT would simplify these issues if nodes could be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. However, shoving this complexity into the Bitcoin P2P network may not be feasible. Instead, a relay network of lightning nodes could potentially handle the calculation and pass the transactions to their local full nodes.In the context of ANYPREVOUT*, a special relay network could be more intelligent about replacement. This would involve relaying only the higher up-front fee-rate transactions from a lower total fee package (Package B) which get spent by the high absolute fee child transactions from a higher total fee package (Package A). The result is Package A', which includes the higher fee rate versions of the ANYPREVOUT* transactions from Package B, but with an overall lower total fee. However, implementing this solution requires nodes to be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else in the mempool already spends.The conversation between Matt and ZmnSCPxj revolves around a relay-based attack that can compromise HTLC security in the Lightning Network. The attacker connects twice to the LN - once to any node near the victim and once to the victim. The attacker arranges for the victim-attacker channel to have most funds on the victim's side and routes a circular payment terminating in the victim-attacker channel. The attacker broadcasts a very low-fee old-state transaction of the victim-attacker channel just before the HTLC timeout, forcing the victim to broadcast a unilateral close attempt for the victim-attacker channel to enforce the HTLC on-chain. However, relay shenanigans prevent the latest commitment from being broadcast, leaving the victim at risk.ZmnSCPxj suggests that forwarding nodes drop channels on-chain "early" if the HTLC will time out soon. Matt notes that SIGHASH_NOINPUT makes these issues much simpler to address if nodes can be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. They also discuss the possibility of an overlay relay network of lightning nodes that do calculation and pass transactions to their local full nodes.Christian discusses a feasible attack that can be executed without the victim's knowledge in a Lightning universe primarily utilizing SIGHASH_NOINPUT-based mechanisms. He suggests monitoring on-chain events and ignoring mempool events to react to confirmed transactions. To ensure security, deep timeouts for mechanisms are necessary so that a SIGHASH_NOINPUT signature can be "locked" to a confirmed txid, unless a reorg unconfirms the transaction. Additionally, implementing scorch-the-earth, keep-bumping-the-fee strategies can help keep rebroadcasting new versions of the spending transaction.In the context of recent relay-based attacks, there have been concerns about the security of Hash Time-Locked Contract (HTLC) transactions. ZmnSCPxj raises a design consideration for the p2p protocol layer that would allow relaying a transaction to a full node without knowing which input transaction that full node has in its mempool or active chain. This is important for systems like lighting where you may not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending them nonetheless.Richard expresses his interest in implementing a Taproot version of Decker-Russell-Osuntokun (eltoo) and discusses the differences between ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and their exploitation. ZmnSCPxj provides clarifications on key-path spending, reducing the round trips for MuSig signing sessions, and the security implications of chaperone signatures for SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT. They also discuss the implementation of scorch-the-earth, keep-bumping-the-fee strategies.In another email thread, Anthony Towns opens a draft pull request to update BIP 118 with the ANYPREVOUT bip, including significant changes since previous discussions. The complete lack of chaperone signatures in the new BIP text is noted.Overall, - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_BIP-draft-BIP32-Path-Templates.xml b/static/bitcoin-dev/July_2020/combined_BIP-draft-BIP32-Path-Templates.xml index 9104604dbf..b867f1c7fe 100644 --- a/static/bitcoin-dev/July_2020/combined_BIP-draft-BIP32-Path-Templates.xml +++ b/static/bitcoin-dev/July_2020/combined_BIP-draft-BIP32-Path-Templates.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - BIP draft: BIP32 Path Templates - 2023-08-02T02:27:58.765588+00:00 - - Dmitry Petukhov 2020-10-26 13:04:56+00:00 - - - Dmitry Petukhov 2020-07-06 15:24:27+00:00 - - - Dmitry Petukhov 2020-07-03 19:10:50+00:00 - - - Dmitry Petukhov 2020-07-03 16:53:44+00:00 - - - David A. Harding 2020-07-03 14:39:45+00:00 - - - Dmitry Petukhov 2020-07-02 16:28:39+00:00 - + 2025-09-26T15:53:21.663349+00:00 + python-feedgen + + + [bitcoin-dev] BIP draft: BIP32 Path Templates Dmitry Petukhov + 2020-07-02T16:28:00.000Z + + + David A. Harding + 2020-07-03T14:39:00.000Z + + + Dmitry Petukhov + 2020-07-03T16:53:00.000Z + + + Dmitry Petukhov + 2020-07-03T19:10:00.000Z + + + Dmitry Petukhov + 2020-07-06T15:24:00.000Z + + + Dmitry Petukhov + 2020-10-26T13:04:00.000Z + + - python-feedgen + 2 Combined summary - BIP draft: BIP32 Path Templates - 2023-08-02T02:27:58.765588+00:00 + 2025-09-26T15:53:21.664225+00:00 - The author of a Bitcoin Improvement Proposal (BIP) has introduced a Python reference implementation of BIP32 path templates compatible with micropython. The FSM formal spec has been corrected and thoroughly tested in both C and Python implementations. The author has submitted a PR to the bips repo and is open to feedback. However, no information is provided about a non-text attachment included.In July 2020, Dmitry Petukhov suggested that having clear specifications and licensed quality implementations would facilitate the adoption of a specific format. He shared a C implementation on GitHub with an MIT license, but no further details are given.The BIP draft aims to establish a format for path templates that enables interoperability among software and hardware vendors by specifying derivation path restrictions. This allows software vendors to create profiles containing constraints on the paths used in their custom derivation schemes. Users can then install these profiles into hardware wallets that support path templates. By enforcing the specified constraints, the device ensures that the software solution functions as intended.Path templates provide a standardized way to describe constraints for BIP32 paths. They allow for application-specific restrictions and identification of multiple chains of addresses. For example, a signing scheme may require only certain whitelisted derivation paths to be used during HD derivation when signing inputs or checking if an output is the change output. By placing the constraints in the signer's configuration, this approach accommodates different vendor-developed schemes and prevents conflicts with custom software solutions.The proposed format for path templates serves as a building block for interoperability between hardware and software vendors. It offers a flexible alternative to rigid sets of "well-known" paths by adopting a common format for specifying restrictions. The hope is that vendors will find it easier to adopt this format with the availability of clear specifications and permissibly licensed quality implementations.In a Bitcoin development mailing list, Dmitry Petukhov suggested creating a BIP draft for path templates. Dave Harding requested clarification on how these templates compare to key origin identification and examples of their usage. He also questioned whether they are intended for backups, multisig wallet coordination, or managing data between software transaction construction and hardware device signing.The author's proposal for a standard format aims to describe constraints on BIP32 paths. The BIP draft specifies "path templates" that facilitate the distinction between valid and invalid paths based on defined constraints. It includes examples of templates and a formal specification of a finite state machine for parsing. A Python implementation for template parsing and matching already exists.While the BIP32 derivation path format allows for custom schemes, unrestricted usage can be unsafe in certain contexts. Hard-coding checks for well-known paths into software and firmware reduces interoperability. To address this, the author proposes a flexible approach that defines a standard notation for "BIP32 path templates" to succinctly describe constraints on the derivation path.Support for these path templates will enhance interoperability and flexibility, enabling vendors and developers to easily define their own custom restrictions. Having standardized formats for custom path templates encourages the development of a common approach to enforce application-specific path restrictions in devices and applications. For example, devices could allow the installation of application-specific profiles with path templates and custom parameters. However, precautions must be taken to prevent the accidental installation of malicious or incorrect profiles. 2020-10-26T13:04:56+00:00 + The author of a Bitcoin Improvement Proposal (BIP) has introduced a Python reference implementation of BIP32 path templates compatible with micropython. The FSM formal spec has been corrected and thoroughly tested in both C and Python implementations. The author has submitted a PR to the bips repo and is open to feedback. However, no information is provided about a non-text attachment included.In July 2020, Dmitry Petukhov suggested that having clear specifications and licensed quality implementations would facilitate the adoption of a specific format. He shared a C implementation on GitHub with an MIT license, but no further details are given.The BIP draft aims to establish a format for path templates that enables interoperability among software and hardware vendors by specifying derivation path restrictions. This allows software vendors to create profiles containing constraints on the paths used in their custom derivation schemes. Users can then install these profiles into hardware wallets that support path templates. By enforcing the specified constraints, the device ensures that the software solution functions as intended.Path templates provide a standardized way to describe constraints for BIP32 paths. They allow for application-specific restrictions and identification of multiple chains of addresses. For example, a signing scheme may require only certain whitelisted derivation paths to be used during HD derivation when signing inputs or checking if an output is the change output. By placing the constraints in the signer's configuration, this approach accommodates different vendor-developed schemes and prevents conflicts with custom software solutions.The proposed format for path templates serves as a building block for interoperability between hardware and software vendors. It offers a flexible alternative to rigid sets of "well-known" paths by adopting a common format for specifying restrictions. The hope is that vendors will find it easier to adopt this format with the availability of clear specifications and permissibly licensed quality implementations.In a Bitcoin development mailing list, Dmitry Petukhov suggested creating a BIP draft for path templates. Dave Harding requested clarification on how these templates compare to key origin identification and examples of their usage. He also questioned whether they are intended for backups, multisig wallet coordination, or managing data between software transaction construction and hardware device signing.The author's proposal for a standard format aims to describe constraints on BIP32 paths. The BIP draft specifies "path templates" that facilitate the distinction between valid and invalid paths based on defined constraints. It includes examples of templates and a formal specification of a finite state machine for parsing. A Python implementation for template parsing and matching already exists.While the BIP32 derivation path format allows for custom schemes, unrestricted usage can be unsafe in certain contexts. Hard-coding checks for well-known paths into software and firmware reduces interoperability. To address this, the author proposes a flexible approach that defines a standard notation for "BIP32 path templates" to succinctly describe constraints on the derivation path.Support for these path templates will enhance interoperability and flexibility, enabling vendors and developers to easily define their own custom restrictions. Having standardized formats for custom path templates encourages the development of a common approach to enforce application-specific path restrictions in devices and applications. For example, devices could allow the installation of application-specific profiles with path templates and custom parameters. However, precautions must be taken to prevent the accidental installation of malicious or incorrect profiles. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_Bech32-weakness-and-impact-on-bip-taproot-addresses.xml b/static/bitcoin-dev/July_2020/combined_Bech32-weakness-and-impact-on-bip-taproot-addresses.xml index aae6ba86d4..e27403360b 100644 --- a/static/bitcoin-dev/July_2020/combined_Bech32-weakness-and-impact-on-bip-taproot-addresses.xml +++ b/static/bitcoin-dev/July_2020/combined_Bech32-weakness-and-impact-on-bip-taproot-addresses.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Bech32 weakness and impact on bip-taproot addresses - 2023-08-02T01:30:47.272776+00:00 - - Russell O'Connor 2020-07-15 21:11:11+00:00 - - - Greg Sanders 2020-07-15 21:05:22+00:00 - - - Russell O'Connor 2020-07-15 20:56:12+00:00 - - - Pieter Wuille 2019-11-13 06:30:18+00:00 - - - ZmnSCPxj 2019-11-13 05:32:32+00:00 - - - Clark Moody 2019-11-13 02:56:54+00:00 - - - Matt Corallo 2019-11-11 01:02:15+00:00 - - - Pieter Wuille 2019-11-10 21:51:48+00:00 - - - Damian Mee 2019-11-08 13:42:13+00:00 - - - Russell O'Connor 2019-11-08 13:03:52+00:00 - - - ZmnSCPxj 2019-11-08 05:11:53+00:00 - - - Eric Voskuil 2019-11-08 03:15:53+00:00 - - - David A. Harding 2019-11-08 02:15:41+00:00 - - - Matt Corallo 2019-11-08 00:41:54+00:00 - - - Greg Sanders 2019-11-07 22:45:02+00:00 - - - Pieter Wuille 2019-11-07 22:35:42+00:00 - + 2025-09-26T15:53:34.191884+00:00 + python-feedgen + + + [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses Pieter Wuille + 2019-11-07T22:35:00.000Z + + + Greg Sanders + 2019-11-07T22:45:00.000Z + + + Matt Corallo + 2019-11-08T00:41:00.000Z + + + David A. Harding + 2019-11-08T02:15:00.000Z + + + Eric Voskuil + 2019-11-08T03:15:00.000Z + + + ZmnSCPxj + 2019-11-08T05:11:00.000Z + + + Russell O'Connor + 2019-11-08T13:03:00.000Z + + + Damian Mee + 2019-11-08T13:42:00.000Z + + + Pieter Wuille + 2019-11-10T21:51:00.000Z + + + Matt Corallo + 2019-11-11T01:02:00.000Z + + + Clark Moody + 2019-11-13T02:56:00.000Z + + + ZmnSCPxj + 2019-11-13T05:32:00.000Z + + + Pieter Wuille + 2019-11-13T06:30:00.000Z + + + Russell O'Connor + 2020-07-15T20:56:00.000Z + + + Greg Sanders + 2020-07-15T21:05:00.000Z + + + Russell O'Connor + 2020-07-15T21:11:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - Bech32 weakness and impact on bip-taproot addresses - 2023-08-02T01:30:47.272776+00:00 + 2025-09-26T15:53:34.193679+00:00 - The Bitcoin development community is engaged in discussions regarding potential amendments to BIP173, specifically related to the "bc" and "tb" segwit address formats. Russell O'Connor has proposed restricting these formats to specific witness program sizes, ranging from 20 to 40 bytes. The aim is to enhance security by excluding shorter witness program sizes with insufficient entropy. This proposal comes as a response to Pieter Wuille's suggestion that such restrictions are unnecessary. Greg Sanders seeks clarification on the significance of bold vs not-bold numbers in relation to witness and address lengths.Another proposal by Russell O'Connor suggests length-prefixing the witness program to address the unused characters in the bech32 alphabet. He proposes creating a new human-readable prefix, potentially "btc1," for length-prefixed bitcoin witness programs. However, ZmnSCPxj's proposal to modify the Bech32 SegWit address format was considered impractical.The discussion also includes considerations for accommodating the taproot program, which corresponds to a witness program length of 32 bytes. The use of alternate checksums for Segwit outputs of various lengths is another topic under discussion. Two options have been presented: implementing a consensus or standardness rule to enforce library upgrades, or addressing the issue within the bech32 algorithm itself. David A. Harding advocates for addressing the issue within the bech32 algorithm, despite potential disruptions to batched transactions.In the context of these discussions, Pieter Wuille proposes amending BIP173 to limit witness programs to lengths of 20 or 32, while still allowing other versions besides 0. The idea is to modify the XOR constant in the checksum encoding process to handle various program lengths without creating a new address format or increasing cognitive load for users.Overall, the Bitcoin development community is focused on exploring amendments and improvements to address formats, witness program lengths, and checksums. The goal is to enhance security, prevent unintended spending, and accommodate future developments while minimizing disruption to existing infrastructure.On the Bitcoin-dev mailing list, a discussion has been initiated regarding the implementation of a rule to prevent witness v1 outputs of length other than 32. Currently, these outputs remain unencumbered, allowing anyone to spend them. One option is to outlaw v1 witness outputs of length 31 and 33, but this would require library upgrades for users of v1+ segwit. This issue was previously addressed in problem #15846, and there are two potential ways to address it: implementing a consensus rule or a standardness rule.A vulnerability has been discovered in the bech32 address format where inserting or erasing "q"s before a final "p" does not invalidate it. While this issue may influence design decisions around bip-taproot, it has little effect on the security of P2WPKH/P2WSH addresses as they are only valid for specific lengths. Outlawing unencumbered witness v1 outputs of length other than 32 could prevent such an insertion or erasure from resulting in an output that can be spent by anyone. However, instead of implementing a consensus/standardness fix, it is suggested to redefine bech32 to disallow such addresses.Pieter Wuille, a developer of bitcoin, posted about a mutation weakness in bech32 on the Bitcoin-dev mailing list. Inserting or erasing "q"s before the final "p" in a bech32 string does not invalidate it due to an oversight in the original design. This mutation weakness has little effect on the security of P2WPKH/P2WSH addresses but may impact design decisions around bip-taproot. In the current draft of bip-taproot, witness v1 outputs of length other than 32 remain unencumbered, allowing anyone to spend them. To prevent this, one option is to outlaw v1 witness outputs of length 31 and 33. Pieter apologizes for not catching this issue earlier and seeks thoughts from the community on preventing similar issues in the future. 2020-07-15T21:11:11+00:00 + The Bitcoin development community is engaged in discussions regarding potential amendments to BIP173, specifically related to the "bc" and "tb" segwit address formats. Russell O'Connor has proposed restricting these formats to specific witness program sizes, ranging from 20 to 40 bytes. The aim is to enhance security by excluding shorter witness program sizes with insufficient entropy. This proposal comes as a response to Pieter Wuille's suggestion that such restrictions are unnecessary. Greg Sanders seeks clarification on the significance of bold vs not-bold numbers in relation to witness and address lengths.Another proposal by Russell O'Connor suggests length-prefixing the witness program to address the unused characters in the bech32 alphabet. He proposes creating a new human-readable prefix, potentially "btc1," for length-prefixed bitcoin witness programs. However, ZmnSCPxj's proposal to modify the Bech32 SegWit address format was considered impractical.The discussion also includes considerations for accommodating the taproot program, which corresponds to a witness program length of 32 bytes. The use of alternate checksums for Segwit outputs of various lengths is another topic under discussion. Two options have been presented: implementing a consensus or standardness rule to enforce library upgrades, or addressing the issue within the bech32 algorithm itself. David A. Harding advocates for addressing the issue within the bech32 algorithm, despite potential disruptions to batched transactions.In the context of these discussions, Pieter Wuille proposes amending BIP173 to limit witness programs to lengths of 20 or 32, while still allowing other versions besides 0. The idea is to modify the XOR constant in the checksum encoding process to handle various program lengths without creating a new address format or increasing cognitive load for users.Overall, the Bitcoin development community is focused on exploring amendments and improvements to address formats, witness program lengths, and checksums. The goal is to enhance security, prevent unintended spending, and accommodate future developments while minimizing disruption to existing infrastructure.On the Bitcoin-dev mailing list, a discussion has been initiated regarding the implementation of a rule to prevent witness v1 outputs of length other than 32. Currently, these outputs remain unencumbered, allowing anyone to spend them. One option is to outlaw v1 witness outputs of length 31 and 33, but this would require library upgrades for users of v1+ segwit. This issue was previously addressed in problem #15846, and there are two potential ways to address it: implementing a consensus rule or a standardness rule.A vulnerability has been discovered in the bech32 address format where inserting or erasing "q"s before a final "p" does not invalidate it. While this issue may influence design decisions around bip-taproot, it has little effect on the security of P2WPKH/P2WSH addresses as they are only valid for specific lengths. Outlawing unencumbered witness v1 outputs of length other than 32 could prevent such an insertion or erasure from resulting in an output that can be spent by anyone. However, instead of implementing a consensus/standardness fix, it is suggested to redefine bech32 to disallow such addresses.Pieter Wuille, a developer of bitcoin, posted about a mutation weakness in bech32 on the Bitcoin-dev mailing list. Inserting or erasing "q"s before the final "p" in a bech32 string does not invalidate it due to an oversight in the original design. This mutation weakness has little effect on the security of P2WPKH/P2WSH addresses but may impact design decisions around bip-taproot. In the current draft of bip-taproot, witness v1 outputs of length other than 32 remain unencumbered, allowing anyone to spend them. To prevent this, one option is to outlaw v1 witness outputs of length 31 and 33. Pieter apologizes for not catching this issue earlier and seeks thoughts from the community on preventing similar issues in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_Hiding-CoinSwap-Makers-Among-Custodial-Services.xml b/static/bitcoin-dev/July_2020/combined_Hiding-CoinSwap-Makers-Among-Custodial-Services.xml index 0ea9c9ebbc..020b37f140 100644 --- a/static/bitcoin-dev/July_2020/combined_Hiding-CoinSwap-Makers-Among-Custodial-Services.xml +++ b/static/bitcoin-dev/July_2020/combined_Hiding-CoinSwap-Makers-Among-Custodial-Services.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Hiding CoinSwap Makers Among Custodial Services - 2023-08-02T02:23:04.645435+00:00 - - ZmnSCPxj 2020-07-17 06:02:03+00:00 - - - Chris Belcher 2020-06-13 23:25:00+00:00 - - - ZmnSCPxj 2020-06-13 14:06:05+00:00 - - - Chris Belcher 2020-06-13 13:38:35+00:00 - - - ZmnSCPxj 2020-06-11 11:51:03+00:00 - + 2025-09-26T15:53:30.015606+00:00 + python-feedgen + + + [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services ZmnSCPxj + 2020-06-11T11:51:00.000Z + + + Chris Belcher + 2020-06-13T13:38:00.000Z + + + ZmnSCPxj + 2020-06-13T14:06:00.000Z + + + Chris Belcher + 2020-06-13T23:25:00.000Z + + + ZmnSCPxj + 2020-07-17T06:02:00.000Z + + - python-feedgen + 2 Combined summary - Hiding CoinSwap Makers Among Custodial Services - 2023-08-02T02:23:04.645435+00:00 + 2025-09-26T15:53:30.016352+00:00 - In a recent email exchange, ZmnSCPxj and Chris discuss the potential benefits of using batching in CoinSwap operations. By slowing down the process, CoinSwappers can pretend to be a service provider and improve privacy. This would also allow makers to use batching and potentially save on fees. However, ZmnSCPxj later realizes that the same kind of batching can also be done by the taker. By contacting two makers in parallel, each CoinSwap operation would look like an ordinary pay-to-someone-and-get-back-change transaction. This method could potentially provide extra privacy and reduced cost for the taker, but its effectiveness is uncertain.The conversation between ZmnSCPxj and Chris revolves around the idea of CoinSwappers slowing down the CoinSwap process to enable makers to use batching. This strategy not only improves privacy by pretending to be a service provider using batching but also offers practical benefits for CoinSwap takers who want greater privacy. By being willing to wait longer, takers can save on miner fees as well.The email exchange briefly discusses the idea of CoinSwappers slowing down the CoinSwap process to allow makers to utilize batching. It seems that CoinSwappers act as intermediaries in the CoinSwap process. Slowing down the process gives makers more time to batch their transactions and potentially save on fees. The email exchange acknowledges that there are important links provided in the email to provide more context for those unfamiliar with the terms used. CoinSwap refers to a specific type of transaction that allows users to swap cryptocurrencies without revealing their identities, while batching is a technique that combines multiple transactions into a single one to save on network fees.ZmnSCPxj, a Bitcoin developer, proposes a technique to enhance CoinSwap user privacy. The approach involves makers operating in rounds and using transaction batching to serve multiple clients with a single transaction. This not only addresses blockchain size issues but also incentivizes makers to adopt the technique by reducing their overall transaction costs. By spreading taint and increasing the effort required for chain analysis, this method can slow down the CoinSwap process and enable makers to utilize batching for improved user privacy.In a post on the bitcoin-dev mailing list, ZmnSCPxj suggests a method to enhance the privacy of SwapMarket customers. This proposal entails makers operating in rounds and using batching to combine multiple client transactions into a single one. By doing so, makers can mitigate blockchain size issues associated with CoinSwap. Although this increases the effort required for chain analysis and spreads taint, makers are incentivized to adopt this technique due to reduced transaction costs and increased profitability. 2020-07-17T06:02:03+00:00 + In a recent email exchange, ZmnSCPxj and Chris discuss the potential benefits of using batching in CoinSwap operations. By slowing down the process, CoinSwappers can pretend to be a service provider and improve privacy. This would also allow makers to use batching and potentially save on fees. However, ZmnSCPxj later realizes that the same kind of batching can also be done by the taker. By contacting two makers in parallel, each CoinSwap operation would look like an ordinary pay-to-someone-and-get-back-change transaction. This method could potentially provide extra privacy and reduced cost for the taker, but its effectiveness is uncertain.The conversation between ZmnSCPxj and Chris revolves around the idea of CoinSwappers slowing down the CoinSwap process to enable makers to use batching. This strategy not only improves privacy by pretending to be a service provider using batching but also offers practical benefits for CoinSwap takers who want greater privacy. By being willing to wait longer, takers can save on miner fees as well.The email exchange briefly discusses the idea of CoinSwappers slowing down the CoinSwap process to allow makers to utilize batching. It seems that CoinSwappers act as intermediaries in the CoinSwap process. Slowing down the process gives makers more time to batch their transactions and potentially save on fees. The email exchange acknowledges that there are important links provided in the email to provide more context for those unfamiliar with the terms used. CoinSwap refers to a specific type of transaction that allows users to swap cryptocurrencies without revealing their identities, while batching is a technique that combines multiple transactions into a single one to save on network fees.ZmnSCPxj, a Bitcoin developer, proposes a technique to enhance CoinSwap user privacy. The approach involves makers operating in rounds and using transaction batching to serve multiple clients with a single transaction. This not only addresses blockchain size issues but also incentivizes makers to adopt the technique by reducing their overall transaction costs. By spreading taint and increasing the effort required for chain analysis, this method can slow down the CoinSwap process and enable makers to utilize batching for improved user privacy.In a post on the bitcoin-dev mailing list, ZmnSCPxj suggests a method to enhance the privacy of SwapMarket customers. This proposal entails makers operating in rounds and using batching to combine multiple client transactions into a single one. By doing so, makers can mitigate blockchain size issues associated with CoinSwap. Although this increases the effort required for chain analysis and spreads taint, makers are incentivized to adopt this technique due to reduced transaction costs and increased profitability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_Implementing-Investment-Aggregation.xml b/static/bitcoin-dev/July_2020/combined_Implementing-Investment-Aggregation.xml index 9c62c5544d..e8890bb850 100644 --- a/static/bitcoin-dev/July_2020/combined_Implementing-Investment-Aggregation.xml +++ b/static/bitcoin-dev/July_2020/combined_Implementing-Investment-Aggregation.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Implementing Investment Aggregation - 2023-08-02T02:31:53.579200+00:00 - - ZmnSCPxj 2020-07-21 16:28:03+00:00 - - - esnierde 2020-07-21 05:23:00+00:00 - - - ZmnSCPxj 2020-07-21 03:40:07+00:00 - + 2025-09-26T15:53:25.843575+00:00 + python-feedgen + + + [bitcoin-dev] Implementing Investment Aggregation ZmnSCPxj + 2020-07-21T03:40:00.000Z + + + esnierde + 2020-07-21T05:23:00.000Z + + + ZmnSCPxj + 2020-07-21T16:28:00.000Z + + - python-feedgen + 2 Combined summary - Implementing Investment Aggregation - 2023-08-02T02:31:53.579200+00:00 + 2025-09-26T15:53:25.844197+00:00 - The email thread discusses a proposal for non-custodial coordination of small investors in lending money to businesses. The traditional banking system provides more than just custodial holding of funds, including matching long-term investments with short or variable term deposits and sophisticated risk analysis systems. The proposal suggests using features that allow for a non-custodial coordinator of multiple small investors who remain in control of their funds until transferred to the lendee.The coordinator takes on the risk of default, reducing the risk relative to a centralized custodial solution. Investors need to trust some bank in addition to trusting the businesses taking on loans to start/expand their business, but this proposal removes the necessity for custodial holding of funds. Prior to investors signing the loan-out transaction, they prepare a loan-payback transaction, which is signed with a SIGHASH_ANYPREVOUT signature. If the business is actually able to pay back its loan, the coordinator is never in custodial possession of funds. Investors may prefer to spread their risk by investing sub-sections of their savings into multiple different businesses, and each business can be given a loan-payback address controlled by the investors that extended their loans.The proposal also mentions collateralized loans, where a Cryptographic Relay would allow multiple small investors to act as the "loan shark" in the example. Ownership remains controlled by individual investors, eliminating any custodial issues. However, coordinating the sale of collateral amongst multiple small investors in case of default may be harder. An additional service may be willing to pre-allocate Bitcoin funds into a timelocked contract, earning by arbitraging time preference.Overall, the idea removes the necessity for custodial holding of funds, in the way traditional banks do. In a capitalist economic system, lending money is allowed as long as both parties agree upon the conditions of the loan. However, as the required capital to create new businesses or expand existing ones has grown much larger than most single individuals can invest in, coordinators that aggregate the savings of multiple individuals and lend them out for interest have arisen. These coordinators are traditionally called banks.However, this typically involves delegating the work of judging whether a business proposal is likely to give a return on investment to the coordinator itself, adding the risk of custodial default to small-time investors in addition to loan default. This write-up proposes the use of non-custodial coordinators of multiple small investors to reduce the risk relative to a centralized custodial solution. The coordinator need only find a sufficiently large set of entities that are willing to indicate their Bitcoin UTXOs as being earmarked for investment in a particular business.The coordinator for its services may extract a fee from the loan-payback transaction that all investors can agree to. Thus, it takes on the risk of default by the business, which seems appropriate if it also serves as a basic filter against bad business investments. By working in Bitcoin, it cannot have a lender of last resort, and thus must evaluate possible business investments as accurately as possible (as default risks its fee earnings).The investors would prefer to spread their risk by investing sub-sections of their savings into multiple different businesses. This gives somewhat lower expected returns but gives some protection against complete loss, allowing individual investors to adjust their risk exposure and their desired expected returns. The batch transaction that aggregates the allocated UTXOs of the investors can pay out to multiple borrowing businesses. And each business can be given a loan-payback address, which is controlled by the investors that extended their loans. Investors generate an aggregate loan-payback transaction and signature for each business they invest in.As observed in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018053.html, a Cryptographic Relay would allow collateralized loans. Nothing prevents the "loan shark" in the collateralized loan example from being a MuSig of multiple small investors. Practically, a coordinator would help facilitate construction of the necessary transactions and interaction with the loanee. An additional service may be willing to pre-allocate Bitcoin funds into a timelocked contract.In case of default, the investors would prefer to recoup their financial losses quickly, while the service is now in possession of the collateral that it can resell later at a higher rate. Note that these are all operations that traditional banks perform. This idea simply removes the necessity for custodial holding of funds, in the way traditional banks do. 2020-07-21T16:28:03+00:00 + The email thread discusses a proposal for non-custodial coordination of small investors in lending money to businesses. The traditional banking system provides more than just custodial holding of funds, including matching long-term investments with short or variable term deposits and sophisticated risk analysis systems. The proposal suggests using features that allow for a non-custodial coordinator of multiple small investors who remain in control of their funds until transferred to the lendee.The coordinator takes on the risk of default, reducing the risk relative to a centralized custodial solution. Investors need to trust some bank in addition to trusting the businesses taking on loans to start/expand their business, but this proposal removes the necessity for custodial holding of funds. Prior to investors signing the loan-out transaction, they prepare a loan-payback transaction, which is signed with a SIGHASH_ANYPREVOUT signature. If the business is actually able to pay back its loan, the coordinator is never in custodial possession of funds. Investors may prefer to spread their risk by investing sub-sections of their savings into multiple different businesses, and each business can be given a loan-payback address controlled by the investors that extended their loans.The proposal also mentions collateralized loans, where a Cryptographic Relay would allow multiple small investors to act as the "loan shark" in the example. Ownership remains controlled by individual investors, eliminating any custodial issues. However, coordinating the sale of collateral amongst multiple small investors in case of default may be harder. An additional service may be willing to pre-allocate Bitcoin funds into a timelocked contract, earning by arbitraging time preference.Overall, the idea removes the necessity for custodial holding of funds, in the way traditional banks do. In a capitalist economic system, lending money is allowed as long as both parties agree upon the conditions of the loan. However, as the required capital to create new businesses or expand existing ones has grown much larger than most single individuals can invest in, coordinators that aggregate the savings of multiple individuals and lend them out for interest have arisen. These coordinators are traditionally called banks.However, this typically involves delegating the work of judging whether a business proposal is likely to give a return on investment to the coordinator itself, adding the risk of custodial default to small-time investors in addition to loan default. This write-up proposes the use of non-custodial coordinators of multiple small investors to reduce the risk relative to a centralized custodial solution. The coordinator need only find a sufficiently large set of entities that are willing to indicate their Bitcoin UTXOs as being earmarked for investment in a particular business.The coordinator for its services may extract a fee from the loan-payback transaction that all investors can agree to. Thus, it takes on the risk of default by the business, which seems appropriate if it also serves as a basic filter against bad business investments. By working in Bitcoin, it cannot have a lender of last resort, and thus must evaluate possible business investments as accurately as possible (as default risks its fee earnings).The investors would prefer to spread their risk by investing sub-sections of their savings into multiple different businesses. This gives somewhat lower expected returns but gives some protection against complete loss, allowing individual investors to adjust their risk exposure and their desired expected returns. The batch transaction that aggregates the allocated UTXOs of the investors can pay out to multiple borrowing businesses. And each business can be given a loan-payback address, which is controlled by the investors that extended their loans. Investors generate an aggregate loan-payback transaction and signature for each business they invest in.As observed in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018053.html, a Cryptographic Relay would allow collateralized loans. Nothing prevents the "loan shark" in the collateralized loan example from being a MuSig of multiple small investors. Practically, a coordinator would help facilitate construction of the necessary transactions and interaction with the loanee. An additional service may be willing to pre-allocate Bitcoin funds into a timelocked contract.In case of default, the investors would prefer to recoup their financial losses quickly, while the service is now in possession of the collateral that it can resell later at a higher rate. Note that these are all operations that traditional banks perform. This idea simply removes the necessity for custodial holding of funds, in the way traditional banks do. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_Is-Bitcoin-mempool-synchronized-.xml b/static/bitcoin-dev/July_2020/combined_Is-Bitcoin-mempool-synchronized-.xml index 1b9fe1122d..bf4e4ed3b8 100644 --- a/static/bitcoin-dev/July_2020/combined_Is-Bitcoin-mempool-synchronized-.xml +++ b/static/bitcoin-dev/July_2020/combined_Is-Bitcoin-mempool-synchronized-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Is Bitcoin mempool synchronized? - 2023-08-02T02:27:26.764047+00:00 - - ZmnSCPxj 2020-07-01 00:53:46+00:00 - - - Hilda 2020-06-30 19:01:30+00:00 - + 2025-09-26T15:53:27.928856+00:00 + python-feedgen + + + [bitcoin-dev] Is Bitcoin mempool synchronized? Hilda + 2020-06-30T19:01:00.000Z + + + ZmnSCPxj + 2020-07-01T00:53:00.000Z + + - python-feedgen + 2 Combined summary - Is Bitcoin mempool synchronized? - 2023-08-02T02:27:26.764047+00:00 + 2025-09-26T15:53:27.929297+00:00 - Hilda recently raised a question about the synchronization of the Bitcoin system, particularly regarding mempools. Mempools are essentially pools of unconfirmed transactions waiting to be included in the blockchain. While there is no direct way to limit the number of transactions someone can push onto your mempool, certain heuristics can assist in managing this issue.However, it's worth noting that these heuristics can sometimes create desynchronization between different mempools, which can potentially lead to problems. This means that the contents of one node's mempool may not match those of another node, causing discrepancies in transaction data.Fortunately, the blockchain itself serves as the main source of synchronization. The blockchain is a public ledger where all confirmed transactions are recorded in a sequential and synchronized manner. It ensures that transactions are legitimate by requiring miners to perform computationally intensive work towards achieving a difficulty target before they can add a block to the chain. As a result, it becomes practically impossible for someone to spam blocks without putting in considerable effort.It is important to highlight that consensus rules should primarily focus on data contained within blocks, rather than relying on information from mempools. Mempools are ephemeral and not synchronized across all nodes. Therefore, referring to mempool data for verifying the state of the entire Bitcoin system would require checking with every miner continuously, which is impractical.In conclusion, Hilda's query revolves around the verification of synchronization within the Bitcoin system, specifically concerning mempools. While heuristics can help manage the influx of transactions, they can also cause desynchronization between mempools. However, since the blockchain itself is the foundation of synchronization, attempting to spam blocks without performing the necessary computational work is virtually impossible. Consensus rules should prioritize data within blocks rather than relying on ephemeral and unsynchronized mempools. 2020-07-01T00:53:46+00:00 + Hilda recently raised a question about the synchronization of the Bitcoin system, particularly regarding mempools. Mempools are essentially pools of unconfirmed transactions waiting to be included in the blockchain. While there is no direct way to limit the number of transactions someone can push onto your mempool, certain heuristics can assist in managing this issue.However, it's worth noting that these heuristics can sometimes create desynchronization between different mempools, which can potentially lead to problems. This means that the contents of one node's mempool may not match those of another node, causing discrepancies in transaction data.Fortunately, the blockchain itself serves as the main source of synchronization. The blockchain is a public ledger where all confirmed transactions are recorded in a sequential and synchronized manner. It ensures that transactions are legitimate by requiring miners to perform computationally intensive work towards achieving a difficulty target before they can add a block to the chain. As a result, it becomes practically impossible for someone to spam blocks without putting in considerable effort.It is important to highlight that consensus rules should primarily focus on data contained within blocks, rather than relying on information from mempools. Mempools are ephemeral and not synchronized across all nodes. Therefore, referring to mempool data for verifying the state of the entire Bitcoin system would require checking with every miner continuously, which is impractical.In conclusion, Hilda's query revolves around the verification of synchronization within the Bitcoin system, specifically concerning mempools. While heuristics can help manage the influx of transactions, they can also cause desynchronization between mempools. However, since the blockchain itself is the foundation of synchronization, attempting to spam blocks without performing the necessary computational work is virtually impossible. Consensus rules should prioritize data within blocks rather than relying on ephemeral and unsynchronized mempools. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_Lightning-Is-HTLC-vulnerable-And-mention-of-Channel-Factories.xml b/static/bitcoin-dev/July_2020/combined_Lightning-Is-HTLC-vulnerable-And-mention-of-Channel-Factories.xml index d65314fd10..e41979ef48 100644 --- a/static/bitcoin-dev/July_2020/combined_Lightning-Is-HTLC-vulnerable-And-mention-of-Channel-Factories.xml +++ b/static/bitcoin-dev/July_2020/combined_Lightning-Is-HTLC-vulnerable-And-mention-of-Channel-Factories.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Lightning - Is HTLC vulnerable? And mention of Channel Factories - 2023-08-02T02:30:44.138478+00:00 - - Jochen Hoenicke 2020-07-15 15:23:24+00:00 - - - ZmnSCPxj 2020-07-14 14:42:21+00:00 - - - Mr. Lee Chiffre 2020-07-14 02:58:10+00:00 - + 2025-09-26T15:53:17.450150+00:00 + python-feedgen + + + [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories Mr. Lee Chiffre + 2020-07-14T02:58:00.000Z + + + ZmnSCPxj + 2020-07-14T14:42:00.000Z + + + Jochen Hoenicke + 2020-07-15T15:23:00.000Z + + - python-feedgen + 2 Combined summary - Lightning - Is HTLC vulnerable? And mention of Channel Factories - 2023-08-02T02:30:44.138478+00:00 + 2025-09-26T15:53:17.450742+00:00 - In a Bitcoin development discussion on July 14th, a user raised concerns about potential economic loss if their HTLC (Hash Time-Locked Contract) does not get confirmed in time or if an older HTLC gets confirmed first. In response, it was explained that the Lightning Network aims to reduce pressure on the blockchain by moving transactions off-chain, thereby lowering the risk of delay-induced economic loss. This approach improves settlement speed for both off-chain and on-chain transactions.The user also mentioned an attack technique called "flood and loot" where numerous uneconomically small HTLCs are sent to a victim forwarding node, with the attacker refusing to claim them when sent back. By doing so, the attacker can claim all funds on their receiving channel, putting the victim at a disadvantage. To address this issue, the Lightning Network is developing anchor commitments to mitigate the effects of such attacks on on-chain fees.An email exchange between Mr. Lee and ZmnSCPxj further discussed the risks associated with the Lightning Network. ZmnSCPxj emphasized the benefits of moving transactions off-chain to reduce the risk of economic loss due to delays in on-chain settlements. They refuted the possibility of conflicting HTLCs and highlighted the risk of denial of service attacks. While acknowledging that the Lightning Network is susceptible to such attacks, efforts are being made to address them through anchor commitments.The author of the email sent to the lightning-dev mailing list expressed apologies if their questions had already been answered. They sought clarification on how the Lightning Network operates regarding HTLCs and settlements on the blockchain. Specifically, they were concerned about the potential loss of money if their HTLC did not get confirmed or if an older HTLC got confirmed first. They outlined three scenarios where this could occur: a saturated blockchain, competition from conflicting HTLCs, or a denial of service attack on the lightning router preventing settlement HTLCs from being sent. They also mentioned the "flood and loot" attack technique, which resembled their concerns.Acknowledging their limited understanding of the Lightning Network, the author requested clarification on whether channel factories would be a better solution to address their concerns. However, they noted that they were unable to access lightning-dev emails due to Google Recaptcha blocking their subscription. Therefore, they requested that anyone replying to their email CC them so they could read it. 2020-07-15T15:23:24+00:00 + In a Bitcoin development discussion on July 14th, a user raised concerns about potential economic loss if their HTLC (Hash Time-Locked Contract) does not get confirmed in time or if an older HTLC gets confirmed first. In response, it was explained that the Lightning Network aims to reduce pressure on the blockchain by moving transactions off-chain, thereby lowering the risk of delay-induced economic loss. This approach improves settlement speed for both off-chain and on-chain transactions.The user also mentioned an attack technique called "flood and loot" where numerous uneconomically small HTLCs are sent to a victim forwarding node, with the attacker refusing to claim them when sent back. By doing so, the attacker can claim all funds on their receiving channel, putting the victim at a disadvantage. To address this issue, the Lightning Network is developing anchor commitments to mitigate the effects of such attacks on on-chain fees.An email exchange between Mr. Lee and ZmnSCPxj further discussed the risks associated with the Lightning Network. ZmnSCPxj emphasized the benefits of moving transactions off-chain to reduce the risk of economic loss due to delays in on-chain settlements. They refuted the possibility of conflicting HTLCs and highlighted the risk of denial of service attacks. While acknowledging that the Lightning Network is susceptible to such attacks, efforts are being made to address them through anchor commitments.The author of the email sent to the lightning-dev mailing list expressed apologies if their questions had already been answered. They sought clarification on how the Lightning Network operates regarding HTLCs and settlements on the blockchain. Specifically, they were concerned about the potential loss of money if their HTLC did not get confirmed or if an older HTLC got confirmed first. They outlined three scenarios where this could occur: a saturated blockchain, competition from conflicting HTLCs, or a denial of service attack on the lightning router preventing settlement HTLCs from being sent. They also mentioned the "flood and loot" attack technique, which resembled their concerns.Acknowledging their limited understanding of the Lightning Network, the author requested clarification on whether channel factories would be a better solution to address their concerns. However, they noted that they were unable to access lightning-dev emails due to Google Recaptcha blocking their subscription. Therefore, they requested that anyone replying to their email CC them so they could read it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_MAD-HTLC.xml b/static/bitcoin-dev/July_2020/combined_MAD-HTLC.xml index 0ae82b167c..81903d51bd 100644 --- a/static/bitcoin-dev/July_2020/combined_MAD-HTLC.xml +++ b/static/bitcoin-dev/July_2020/combined_MAD-HTLC.xml @@ -1,89 +1,119 @@ - + 2 Combined summary - MAD-HTLC - 2023-08-02T02:25:21.896054+00:00 - - Tejaswi Nadahalli 2020-07-06 11:13:47+00:00 - - - Stanga 2020-07-05 09:03:14+00:00 - - - ZmnSCPxj 2020-07-04 21:05:34+00:00 - - - ZmnSCPxj 2020-07-04 20:58:57+00:00 - - - ZmnSCPxj 2020-07-03 12:38:37+00:00 - - - Tejaswi Nadahalli 2020-07-03 10:44:59+00:00 - - - ZmnSCPxj 2020-07-03 10:16:55+00:00 - - - Tejaswi Nadahalli 2020-07-03 09:43:37+00:00 - - - ZmnSCPxj 2020-07-02 16:06:04+00:00 - - - Tejaswi Nadahalli 2020-07-02 12:39:35+00:00 - - - Tejaswi Nadahalli 2020-07-02 12:22:51+00:00 - - - ZmnSCPxj 2020-07-01 16:58:24+00:00 - - - Tejaswi Nadahalli 2020-06-30 06:45:09+00:00 - - - Stanga 2020-06-30 06:28:58+00:00 - - - ZmnSCPxj 2020-06-29 18:05:10+00:00 - - - Tejaswi Nadahalli 2020-06-29 11:57:52+00:00 - - - David A. Harding 2020-06-28 16:41:32+00:00 - - - David A. Harding 2020-06-28 12:15:17+00:00 - - - Bastien TEINTURIER 2020-06-25 13:12:56+00:00 - - - Nadav Ivgi 2020-06-25 04:35:51+00:00 - - - ZmnSCPxj 2020-06-25 04:04:09+00:00 - - - Nadav Ivgi 2020-06-25 03:26:41+00:00 - - - ZmnSCPxj 2020-06-25 01:38:17+00:00 - - - Stanga 2020-06-23 13:18:35+00:00 - - - Stanga 2020-06-23 12:47:56+00:00 - - - ZmnSCPxj 2020-06-23 09:48:27+00:00 - - - Stanga 2020-06-23 06:41:56+00:00 - + 2025-09-26T15:53:19.571320+00:00 + python-feedgen + + + [bitcoin-dev] MAD-HTLC Stanga + 2020-06-23T06:41:00.000Z + + + ZmnSCPxj + 2020-06-23T09:48:00.000Z + + + Stanga + 2020-06-23T12:47:00.000Z + + + Stanga + 2020-06-23T13:18:00.000Z + + + ZmnSCPxj + 2020-06-25T01:38:00.000Z + + + Nadav Ivgi + 2020-06-25T03:26:00.000Z + + + ZmnSCPxj + 2020-06-25T04:04:00.000Z + + + Nadav Ivgi + 2020-06-25T04:35:00.000Z + + + Bastien TEINTURIER + 2020-06-25T13:12:00.000Z + + + David A. Harding + 2020-06-28T12:15:00.000Z + + + David A. Harding + 2020-06-28T16:41:00.000Z + + + Tejaswi Nadahalli + 2020-06-29T11:57:00.000Z + + + ZmnSCPxj + 2020-06-29T18:05:00.000Z + + + Stanga + 2020-06-30T06:28:00.000Z + + + Tejaswi Nadahalli + 2020-06-30T06:45:00.000Z + + + ZmnSCPxj + 2020-07-01T16:58:00.000Z + + + Tejaswi Nadahalli + 2020-07-02T12:22:00.000Z + + + Tejaswi Nadahalli + 2020-07-02T12:39:00.000Z + + + ZmnSCPxj + 2020-07-02T16:06:00.000Z + + + Tejaswi Nadahalli + 2020-07-03T09:43:00.000Z + + + ZmnSCPxj + 2020-07-03T10:16:00.000Z + + + Tejaswi Nadahalli + 2020-07-03T10:44:00.000Z + + + ZmnSCPxj + 2020-07-03T12:38:00.000Z + + + ZmnSCPxj + 2020-07-04T20:58:00.000Z + + + ZmnSCPxj + 2020-07-04T21:05:00.000Z + + + Stanga + 2020-07-05T09:03:00.000Z + + + Tejaswi Nadahalli + 2020-07-06T11:13:00.000Z + + @@ -111,13 +141,13 @@ - python-feedgen + 2 Combined summary - MAD-HTLC - 2023-08-02T02:25:21.896054+00:00 + 2025-09-26T15:53:19.574128+00:00 - In a recent email conversation, Itay Tsabary discussed the token amount required for the collateral contract in a collateralized contract. He mentioned that the required token amount is low and independent of the deposit tokens. He argued that a relatively small incentive is enough to encourage honest behavior from participants. However, this does result in slightly larger transactions with another UTXO. The recipient of the email questioned whether the collateral had to be at least the same size as the deposit, expressing concerns about the potential for bribery attacks. The discussion between Ittay and ZmnSCPxj on the Bitcoin-dev mailing list focused on myopic and non-myopic miners. Non-myopic miners optimize transaction selection for multiple future blocks, while myopic miners only optimize for the next block. The term "dominates" refers to a strategy in game theory that consistently outperforms another strategy. Myopic strategies tend to beat non-myopic strategies because they impose costs on non-myopic miners. Currently, no miner is non-myopic, but it is possible to implement non-myopia in Bitcoin Core. However, implementing non-myopia is considered pointless since myopic strategies dominate over non-myopic strategies. The MAD-HTLC (Miner-Activated Delayed Hash Time-Locked Contract) consists of two contracts: Deposit and Collateral. The Deposit has three redeem paths, while the Collateral serves as a fidelity bond and has two redeem paths. The MAD-HTLC has three cases, each determining the distribution of BTC based on specific conditions. However, these contracts may not be safe if the counterparty is a miner, as it could incentivize competing miners to reorganize the chain and redirect funds. The analysis of the MAD-HTLC paper shows that, in a scenario where all players are rational, the dominant strategy is to support an attack. This situation can be compared to the Prisoner's Dilemma game. One way to address this is through Iterated Prisoner's Dilemma, but it requires miners to identify each other and act accordingly. Another approach is to have a higher system that enforces a specific strategy and punishes deviations. However, this would lead to a centralized cartel, which would be detrimental to Bitcoin.In another email thread, ZmnSCPxj responded to a post about myopic and non-myopic miners in a mixed population. They argued that myopic strategies dominate over non-myopic ones because myopic miners deduct fees from non-myopic miners by preventing certain transactions from being confirmed. The probability of a bribery attack failing decreases exponentially based on the number of blocks until timeout and the percentage of hashrate controlled by myopic miners. Even with a small amount of myopic hashrate and long timeouts or modest amounts of hashrate and short timeouts, the attack is unlikely to succeed. The discussion also touched on the safety of MAD-HTLC and potential vulnerabilities in the Lightning Network. Concerns were raised about the assumption that the mempool is a shared resource and the possibility of double-spending attacks. Various disincentives for attackers were proposed to mitigate these risks. The overall discussions revolved around the dominance of myopic miners, the likelihood of bribery attacks succeeding, and potential vulnerabilities in different contract models. 2020-07-06T11:13:47+00:00 + In a recent email conversation, Itay Tsabary discussed the token amount required for the collateral contract in a collateralized contract. He mentioned that the required token amount is low and independent of the deposit tokens. He argued that a relatively small incentive is enough to encourage honest behavior from participants. However, this does result in slightly larger transactions with another UTXO. The recipient of the email questioned whether the collateral had to be at least the same size as the deposit, expressing concerns about the potential for bribery attacks. The discussion between Ittay and ZmnSCPxj on the Bitcoin-dev mailing list focused on myopic and non-myopic miners. Non-myopic miners optimize transaction selection for multiple future blocks, while myopic miners only optimize for the next block. The term "dominates" refers to a strategy in game theory that consistently outperforms another strategy. Myopic strategies tend to beat non-myopic strategies because they impose costs on non-myopic miners. Currently, no miner is non-myopic, but it is possible to implement non-myopia in Bitcoin Core. However, implementing non-myopia is considered pointless since myopic strategies dominate over non-myopic strategies. The MAD-HTLC (Miner-Activated Delayed Hash Time-Locked Contract) consists of two contracts: Deposit and Collateral. The Deposit has three redeem paths, while the Collateral serves as a fidelity bond and has two redeem paths. The MAD-HTLC has three cases, each determining the distribution of BTC based on specific conditions. However, these contracts may not be safe if the counterparty is a miner, as it could incentivize competing miners to reorganize the chain and redirect funds. The analysis of the MAD-HTLC paper shows that, in a scenario where all players are rational, the dominant strategy is to support an attack. This situation can be compared to the Prisoner's Dilemma game. One way to address this is through Iterated Prisoner's Dilemma, but it requires miners to identify each other and act accordingly. Another approach is to have a higher system that enforces a specific strategy and punishes deviations. However, this would lead to a centralized cartel, which would be detrimental to Bitcoin.In another email thread, ZmnSCPxj responded to a post about myopic and non-myopic miners in a mixed population. They argued that myopic strategies dominate over non-myopic ones because myopic miners deduct fees from non-myopic miners by preventing certain transactions from being confirmed. The probability of a bribery attack failing decreases exponentially based on the number of blocks until timeout and the percentage of hashrate controlled by myopic miners. Even with a small amount of myopic hashrate and long timeouts or modest amounts of hashrate and short timeouts, the attack is unlikely to succeed. The discussion also touched on the safety of MAD-HTLC and potential vulnerabilities in the Lightning Network. Concerns were raised about the assumption that the mempool is a shared resource and the possibility of double-spending attacks. Various disincentives for attackers were proposed to mitigate these risks. The overall discussions revolved around the dominance of myopic miners, the likelihood of bribery attacks succeeding, and potential vulnerabilities in different contract models. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_The-Cryptographic-Relay-An-Electrical-Device-For-Smart-Transferable-Hardware.xml b/static/bitcoin-dev/July_2020/combined_The-Cryptographic-Relay-An-Electrical-Device-For-Smart-Transferable-Hardware.xml index f31d4653be..9eeed2fff3 100644 --- a/static/bitcoin-dev/July_2020/combined_The-Cryptographic-Relay-An-Electrical-Device-For-Smart-Transferable-Hardware.xml +++ b/static/bitcoin-dev/July_2020/combined_The-Cryptographic-Relay-An-Electrical-Device-For-Smart-Transferable-Hardware.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware - 2023-08-02T02:31:25.389404+00:00 - - ZmnSCPxj 2020-07-21 09:19:17+00:00 - - - Andy Schroder 2020-07-21 05:25:44+00:00 - - - ZmnSCPxj 2020-07-21 01:27:27+00:00 - - - ZmnSCPxj 2020-07-20 14:18:10+00:00 - + 2025-09-26T15:53:15.361430+00:00 + python-feedgen + + + [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware ZmnSCPxj + 2020-07-20T14:18:00.000Z + + + ZmnSCPxj + 2020-07-21T01:27:00.000Z + + + Andy Schroder + 2020-07-21T05:25:00.000Z + + + ZmnSCPxj + 2020-07-21T09:19:00.000Z + + - python-feedgen + 2 Combined summary - The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware - 2023-08-02T02:31:25.389404+00:00 + 2025-09-26T15:53:15.362146+00:00 - The concept of time plays a significant role in the world of cryptocurrencies, as explored in the first article. Miners of Bitcoin act similarly to Maxwell's Demon by only accepting and broadcasting "cold" block headers over the blockchain. The article proposes the use of Cryptographic Relays as a means to implement an unforgeable proof-of-time-passing, advocating for standardization and encouraging multiple manufacturers to follow the same standard. This would eliminate the need for blockchain proliferation and reduce bandwidth consumption. The practical deployment of Cryptographic Relays is also discussed, particularly for smart devices that can recognize their owner and be used only by authorized operators.However, it is important to note that engaging in illegal activities such as stealing and hotwiring electric cars, as mentioned in the second context, should not be encouraged. The author explains how one can easily hotwire a car and splice wires across the cryptographic relays of other components. Ethical and legal practices should always be followed when dealing with vehicles.The article delves into the concept of a Cryptographic Relay, which is an electrical component that enables control of an electrical circuit using a public key. It can be used in Succinct Atomic Swaps, allowing for atomic swaps between assets that do not exist in a single asset-assignment system. However, transporting this construction over the Lightning Network poses challenges due to different timeouts at each forwarding hop. To address this, the article suggests giving the Cryptographic Relay a notion of time that makes it compatible with PTLCs routed over Lightning. This can be achieved using block header hashes as a low-entropy measure of time passing.The article also discusses the concept of Maxwell's Demon, which guards a hole between two containers and allows high-temperature molecules to pass from one side to another. The use of Cryptographic Relays allows lenders to verify ownership of a car without the need for a centralized third party. It also proposes a simple and secure ownership transfer and delegation of operators, making it suitable for use in smart devices. The potential application of Cryptographic Relays in collateralized loans on cryptographic cars is explored, highlighting the use of SIGHASH_ANYPREVOUT and Taproot.ZmnSCPxj shares a rentable charging station project for electric cars, envisioning the implementation of a rentable Cryptographic Relay device with support for MuSig, Timelocks, and Delegated operators. The article explains the rental contract process using fresh keypairs, rent-transfer commands, and rental-end commands to transfer ownership between parties. Bitcoin-side payments via Lightning-with-PTLC are also discussed, requiring Taproot but not SIGHASH_ANYPREVOUT. The scenarios of early returns or renting in smaller time units are considered.Furthermore, ZmnSCPxj discusses the possibility of renting out smart domiciles that can be locked/unlocked by the owner/operator of a Cryptographic Relay. A deposit is involved, and the construction of a rent-with-deposit contract is similar to the construction of collateralized loans with PTLCs. The article suggests that smart contract languages should have PTLCs and partial signatures as primitives and be written in a compositional/declarative style.In summary, Cryptographic Relays are electrical components that enable control of electrical circuits using public keys. They can be used in Succinct Atomic Swaps and have applications in various scenarios such as verifying ownership, collateralized loans, and rental contracts. The notion of time plays a crucial role in implementing these concepts, and the use of block header hashes allows for compatibility with Lightning and PTLCs. However, it is important to emphasize that engaging in illegal activities, such as stealing and hotwiring cars, should be avoided, and ethical practices should be followed at all times. 2020-07-21T09:19:17+00:00 + The concept of time plays a significant role in the world of cryptocurrencies, as explored in the first article. Miners of Bitcoin act similarly to Maxwell's Demon by only accepting and broadcasting "cold" block headers over the blockchain. The article proposes the use of Cryptographic Relays as a means to implement an unforgeable proof-of-time-passing, advocating for standardization and encouraging multiple manufacturers to follow the same standard. This would eliminate the need for blockchain proliferation and reduce bandwidth consumption. The practical deployment of Cryptographic Relays is also discussed, particularly for smart devices that can recognize their owner and be used only by authorized operators.However, it is important to note that engaging in illegal activities such as stealing and hotwiring electric cars, as mentioned in the second context, should not be encouraged. The author explains how one can easily hotwire a car and splice wires across the cryptographic relays of other components. Ethical and legal practices should always be followed when dealing with vehicles.The article delves into the concept of a Cryptographic Relay, which is an electrical component that enables control of an electrical circuit using a public key. It can be used in Succinct Atomic Swaps, allowing for atomic swaps between assets that do not exist in a single asset-assignment system. However, transporting this construction over the Lightning Network poses challenges due to different timeouts at each forwarding hop. To address this, the article suggests giving the Cryptographic Relay a notion of time that makes it compatible with PTLCs routed over Lightning. This can be achieved using block header hashes as a low-entropy measure of time passing.The article also discusses the concept of Maxwell's Demon, which guards a hole between two containers and allows high-temperature molecules to pass from one side to another. The use of Cryptographic Relays allows lenders to verify ownership of a car without the need for a centralized third party. It also proposes a simple and secure ownership transfer and delegation of operators, making it suitable for use in smart devices. The potential application of Cryptographic Relays in collateralized loans on cryptographic cars is explored, highlighting the use of SIGHASH_ANYPREVOUT and Taproot.ZmnSCPxj shares a rentable charging station project for electric cars, envisioning the implementation of a rentable Cryptographic Relay device with support for MuSig, Timelocks, and Delegated operators. The article explains the rental contract process using fresh keypairs, rent-transfer commands, and rental-end commands to transfer ownership between parties. Bitcoin-side payments via Lightning-with-PTLC are also discussed, requiring Taproot but not SIGHASH_ANYPREVOUT. The scenarios of early returns or renting in smaller time units are considered.Furthermore, ZmnSCPxj discusses the possibility of renting out smart domiciles that can be locked/unlocked by the owner/operator of a Cryptographic Relay. A deposit is involved, and the construction of a rent-with-deposit contract is similar to the construction of collateralized loans with PTLCs. The article suggests that smart contract languages should have PTLCs and partial signatures as primitives and be written in a compositional/declarative style.In summary, Cryptographic Relays are electrical components that enable control of electrical circuits using public keys. They can be used in Succinct Atomic Swaps and have applications in various scenarios such as verifying ownership, collateralized loans, and rental contracts. The notion of time plays a crucial role in implementing these concepts, and the use of block header hashes allows for compatibility with Lightning and PTLCs. However, it is important to emphasize that engaging in illegal activities, such as stealing and hotwiring cars, should be avoided, and ethical practices should be followed at all times. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2020/combined_Thoughts-on-soft-fork-activation.xml b/static/bitcoin-dev/July_2020/combined_Thoughts-on-soft-fork-activation.xml index 43353f1f21..35b2c5acc3 100644 --- a/static/bitcoin-dev/July_2020/combined_Thoughts-on-soft-fork-activation.xml +++ b/static/bitcoin-dev/July_2020/combined_Thoughts-on-soft-fork-activation.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Thoughts on soft-fork activation - 2023-08-02T02:30:57.873452+00:00 - - ZmnSCPxj 2020-07-17 02:58:46+00:00 - - - Matt Corallo 2020-07-14 20:46:06+00:00 - - - Anthony Towns 2020-07-14 09:37:30+00:00 - + 2025-09-26T15:53:23.753752+00:00 + python-feedgen + + + [bitcoin-dev] Thoughts on soft-fork activation Anthony Towns + 2020-07-14T09:37:00.000Z + + + Matt Corallo + 2020-07-14T20:46:00.000Z + + + ZmnSCPxj + 2020-07-17T02:58:00.000Z + + - python-feedgen + 2 Combined summary - Thoughts on soft-fork activation - 2023-08-02T02:30:57.873452+00:00 + 2025-09-26T15:53:23.754298+00:00 - Bitcoin developers are currently discussing the best approach to activate soft forks in the future. Two proposals have emerged as plausible options. The first proposal is a recent update to BIP 8 by Luke, while the second proposal is based on a more complicated and slower method described by Matt earlier this year. The main difference between the two proposals lies in the time frame for users to upgrade if mandatory activation is desired without a supermajority of hashpower enforcing the rules. The BIP 8 approach offers a relatively short time frame, while the "decreasing threshold" approach provides a longer timeline. Developers have established several design constraints for the activation process. They aim for quick activation if everyone cooperates and there are no obvious exploits. Additionally, they want to have plausible contingency plans in place to discourage people from using the attempt to deploy a new soft fork as a way of attacking bitcoin. It is crucial for the developers to avoid shipping code that causes people to fall out of consensus in case things do not go smoothly. Currently, developers are leaning towards using BIP 8 with mandatory activation disabled in bitcoin core. However, they are prepared to update the BIP 8 parameters to allow mandatory activation in bitcoin core if there are no reasonable objections and strong support for activation after nine months. Furthermore, they plan to change the decreasing threshold proposal to be compatible with BIP 8 and maintain it as an extra contingency plan. In addition, developers will support miners coordinating via BIP 91 to bring activation forward or de-risk BIP 8 mandatory activation as an alternative contingency plan. The overall goal is to ensure a smooth activation of Taproot, although developers acknowledge that there is no guarantee of a seamless process. Therefore, starting with a simple approach and being ready to adapt if things start to go wrong is seen as a prudent strategy. Ultimately, coordination and communication among developers and stakeholders will be key to successfully activating Taproot. 2020-07-17T02:58:46+00:00 + Bitcoin developers are currently discussing the best approach to activate soft forks in the future. Two proposals have emerged as plausible options. The first proposal is a recent update to BIP 8 by Luke, while the second proposal is based on a more complicated and slower method described by Matt earlier this year. The main difference between the two proposals lies in the time frame for users to upgrade if mandatory activation is desired without a supermajority of hashpower enforcing the rules. The BIP 8 approach offers a relatively short time frame, while the "decreasing threshold" approach provides a longer timeline. Developers have established several design constraints for the activation process. They aim for quick activation if everyone cooperates and there are no obvious exploits. Additionally, they want to have plausible contingency plans in place to discourage people from using the attempt to deploy a new soft fork as a way of attacking bitcoin. It is crucial for the developers to avoid shipping code that causes people to fall out of consensus in case things do not go smoothly. Currently, developers are leaning towards using BIP 8 with mandatory activation disabled in bitcoin core. However, they are prepared to update the BIP 8 parameters to allow mandatory activation in bitcoin core if there are no reasonable objections and strong support for activation after nine months. Furthermore, they plan to change the decreasing threshold proposal to be compatible with BIP 8 and maintain it as an extra contingency plan. In addition, developers will support miners coordinating via BIP 91 to bring activation forward or de-risk BIP 8 mandatory activation as an alternative contingency plan. The overall goal is to ensure a smooth activation of Taproot, although developers acknowledge that there is no guarantee of a seamless process. Therefore, starting with a simple approach and being ready to adapt if things start to go wrong is seen as a prudent strategy. Ultimately, coordination and communication among developers and stakeholders will be key to successfully activating Taproot. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml b/static/bitcoin-dev/July_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml index 4ff223f3d4..5cae0579e0 100644 --- a/static/bitcoin-dev/July_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml +++ b/static/bitcoin-dev/July_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent - 2023-08-02T03:56:08.130121+00:00 - - Antoine Riard 2021-07-12 00:02:12+00:00 - - - Anthony Towns 2021-07-10 01:47:32+00:00 - - - Antoine Riard 2021-07-09 13:19:45+00:00 - - - Anthony Towns 2021-07-08 11:17:16+00:00 - - - Lloyd Fournier 2021-06-15 03:08:37+00:00 - - - Lloyd Fournier 2021-06-15 00:59:12+00:00 - - - Antoine Riard 2021-06-14 17:18:38+00:00 - - - Antoine Riard 2021-06-14 16:46:56+00:00 - - - Jeremy 2021-06-13 14:16:24+00:00 - - - Lloyd Fournier 2021-06-13 05:56:43+00:00 - - - darosior 2021-06-10 22:47:04+00:00 - - - Antoine Riard 2021-06-10 21:45:04+00:00 - - - Antoine Riard 2021-06-10 21:16:43+00:00 - - - darosior 2021-06-10 13:18:53+00:00 - - - Lloyd Fournier 2021-06-07 02:27:36+00:00 - - - darosior 2021-05-28 22:25:16+00:00 - - - Antoine Riard 2021-05-28 04:13:44+00:00 - - - darosior 2021-05-27 21:45:35+00:00 - - - Antoine Riard 2021-05-27 20:14:13+00:00 - + 2025-09-26T15:42:50.711677+00:00 + python-feedgen + + + [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent Antoine Riard + 2021-05-27T20:14:00.000Z + + + darosior + 2021-05-27T21:45:00.000Z + + + Antoine Riard + 2021-05-28T04:13:00.000Z + + + darosior + 2021-05-28T22:25:00.000Z + + + Lloyd Fournier + 2021-06-07T02:27:00.000Z + + + darosior + 2021-06-10T13:18:00.000Z + + + Antoine Riard + 2021-06-10T21:16:00.000Z + + + Antoine Riard + 2021-06-10T21:45:00.000Z + + + darosior + 2021-06-10T22:47:00.000Z + + + Lloyd Fournier + 2021-06-13T05:56:00.000Z + + + Jeremy + 2021-06-13T14:16:00.000Z + + + Antoine Riard + 2021-06-14T16:46:00.000Z + + + Antoine Riard + 2021-06-14T17:18:00.000Z + + + Lloyd Fournier + 2021-06-15T00:59:00.000Z + + + Lloyd Fournier + 2021-06-15T03:08:00.000Z + + + Anthony Towns + 2021-07-08T11:17:00.000Z + + + Antoine Riard + 2021-07-09T13:19:00.000Z + + + Anthony Towns + 2021-07-10T01:47:00.000Z + + + Antoine Riard + 2021-07-12T00:02:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent - 2023-08-02T03:56:08.130121+00:00 + 2025-09-26T15:42:50.713897+00:00 - In a recent Bitcoin-dev mailing list discussion, there was a proposal to introduce a new SIGHASH_GROUP flag to improve transaction processing efficiency and avoid O(n^2) behavior. The proposal suggests grouping transactions together using the annex field "sig_group_count" and hashing only the relevant outputs when evaluating an input. This optimization aims to reduce overhead and improve transaction signing. The proposal provides an example of combining transactions in the Lightning network to illustrate how the SIGHASH_GROUP flag would work. However, it notes that there may be limitations when certain outputs collide on the absolute output position.Another topic discussed in the email thread is the possibility of introducing more advanced sighash malleability flags, such as SIGHASH_IOMAP, which would allow transaction signers to commit to a map of inputs and outputs. However, concerns were raised about theft possibilities, heaviness of range specification, and quadratic behavior.The discussion also explores a single-party managed fee-bumping system that could solve fee-bumping requirements in the Lightning network without external utxos or additional interaction between parties. This system would allow for fee adjustment by reducing the balance of a transaction or draining an output with HTLC or PTLC. The proposal suggests that this idea could be applied to all Bitcoin transactions, enabling efficient fee adjustments in various scenarios. The benefits and drawbacks of a sponsor-like mechanism for fee-bumping are also discussed.The conversation touches on fee-bumping techniques for second-layer protocols and proposes solutions such as the SIGHASH_ANYPREVOUT softfork proposal or tx mutation schemes. These approaches aim to address security issues and optimize fee-bumping in contract protocols with distrusting counterparties.Overall, the discussions revolve around proposals and ideas to improve transaction processing efficiency, optimize fee-bumping mechanisms, and address security concerns in various Bitcoin-related contexts, including Lightning network transactions and second-layer protocols.Another aspect discussed is input-based fee-bumping as a primitive for Layer 2 solutions. The use of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags is one variant of input-based fee-bumping, but ACP | SINGLE is easily pinable, so ACP | ALL is used for Revault. This requires a pool of fee-bumping UTXOs to be consumed entirely. The author suggests broadcasting a single fan-out transaction creating the entire UTXO pool in advance to overcome this limitation. However, sometimes the cost of many small additional inputs must be incurred. The discussion also explores the possibility of attaching the bumping input at the tail of the chain rather than targeting the root and suggests using smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP or blinded CPFP.The post compares input-based fee-bumping and CPFP techniques for second-layer protocols in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching opportunity, and mempool flexibility. CPFP requires one anchor output per participant, while input-based fee-bumping only requires one input if the bumping utxo offers an adequate feerate point. If a preliminary fan-out transaction must be broadcasted first, one input and two outputs more must be accounted for. CPFP's efficiency in tx-relay bandwidth rebroadcast relies on the assumption of bounded rationality of the participants, while input-based fee-bumping (today) breaks the chain validity and requires updating and rebroadcasting the remaining transactions beyond the updated root. However, input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP doesn't break the chain validity and could preserve the rest of the chain. For fee-bumping batching, CPFP requires one input/one output per aggregated chain, even if the child transaction fields can be shared. Input-based fee-bumping (today) requires one bumping input per chain, but transaction fields can be shared if a preliminary fan-out transaction is used. Input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP can attach one bumping input and outgoing output to the aggregated root. Regarding fee-bumping mempool flexibility, CPFP has limitations and doesn't scale beyond two contract participants, while input-based fee-bumping's acceptance is not restrained by package limits.The post concludes by mentioning future soft forks that allow significant onchain footprint savings, especially in batching, and future package relay bandwidth efficiency that should consider the rebroadcast frequency of CPFPing multi-party protocols.Overall, the conversation delves into various fee-bumping techniques, their advantages, limitations, and potential future improvements. It provides insights into the complexities and trade-offs involved in securing transactions in multi-party protocols. 2021-07-12T00:02:12+00:00 + In a recent Bitcoin-dev mailing list discussion, there was a proposal to introduce a new SIGHASH_GROUP flag to improve transaction processing efficiency and avoid O(n^2) behavior. The proposal suggests grouping transactions together using the annex field "sig_group_count" and hashing only the relevant outputs when evaluating an input. This optimization aims to reduce overhead and improve transaction signing. The proposal provides an example of combining transactions in the Lightning network to illustrate how the SIGHASH_GROUP flag would work. However, it notes that there may be limitations when certain outputs collide on the absolute output position.Another topic discussed in the email thread is the possibility of introducing more advanced sighash malleability flags, such as SIGHASH_IOMAP, which would allow transaction signers to commit to a map of inputs and outputs. However, concerns were raised about theft possibilities, heaviness of range specification, and quadratic behavior.The discussion also explores a single-party managed fee-bumping system that could solve fee-bumping requirements in the Lightning network without external utxos or additional interaction between parties. This system would allow for fee adjustment by reducing the balance of a transaction or draining an output with HTLC or PTLC. The proposal suggests that this idea could be applied to all Bitcoin transactions, enabling efficient fee adjustments in various scenarios. The benefits and drawbacks of a sponsor-like mechanism for fee-bumping are also discussed.The conversation touches on fee-bumping techniques for second-layer protocols and proposes solutions such as the SIGHASH_ANYPREVOUT softfork proposal or tx mutation schemes. These approaches aim to address security issues and optimize fee-bumping in contract protocols with distrusting counterparties.Overall, the discussions revolve around proposals and ideas to improve transaction processing efficiency, optimize fee-bumping mechanisms, and address security concerns in various Bitcoin-related contexts, including Lightning network transactions and second-layer protocols.Another aspect discussed is input-based fee-bumping as a primitive for Layer 2 solutions. The use of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags is one variant of input-based fee-bumping, but ACP | SINGLE is easily pinable, so ACP | ALL is used for Revault. This requires a pool of fee-bumping UTXOs to be consumed entirely. The author suggests broadcasting a single fan-out transaction creating the entire UTXO pool in advance to overcome this limitation. However, sometimes the cost of many small additional inputs must be incurred. The discussion also explores the possibility of attaching the bumping input at the tail of the chain rather than targeting the root and suggests using smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP or blinded CPFP.The post compares input-based fee-bumping and CPFP techniques for second-layer protocols in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching opportunity, and mempool flexibility. CPFP requires one anchor output per participant, while input-based fee-bumping only requires one input if the bumping utxo offers an adequate feerate point. If a preliminary fan-out transaction must be broadcasted first, one input and two outputs more must be accounted for. CPFP's efficiency in tx-relay bandwidth rebroadcast relies on the assumption of bounded rationality of the participants, while input-based fee-bumping (today) breaks the chain validity and requires updating and rebroadcasting the remaining transactions beyond the updated root. However, input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP doesn't break the chain validity and could preserve the rest of the chain. For fee-bumping batching, CPFP requires one input/one output per aggregated chain, even if the child transaction fields can be shared. Input-based fee-bumping (today) requires one bumping input per chain, but transaction fields can be shared if a preliminary fan-out transaction is used. Input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP can attach one bumping input and outgoing output to the aggregated root. Regarding fee-bumping mempool flexibility, CPFP has limitations and doesn't scale beyond two contract participants, while input-based fee-bumping's acceptance is not restrained by package limits.The post concludes by mentioning future soft forks that allow significant onchain footprint savings, especially in batching, and future package relay bandwidth efficiency that should consider the rebroadcast frequency of CPFPing multi-party protocols.Overall, the conversation delves into various fee-bumping techniques, their advantages, limitations, and potential future improvements. It provides insights into the complexities and trade-offs involved in securing transactions in multi-party protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_An-idea-to-block-invalid-addresses-from-reaching-the-peers-dat-buckets.xml b/static/bitcoin-dev/July_2021/combined_An-idea-to-block-invalid-addresses-from-reaching-the-peers-dat-buckets.xml index af144887b1..e2626f0264 100644 --- a/static/bitcoin-dev/July_2021/combined_An-idea-to-block-invalid-addresses-from-reaching-the-peers-dat-buckets.xml +++ b/static/bitcoin-dev/July_2021/combined_An-idea-to-block-invalid-addresses-from-reaching-the-peers-dat-buckets.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - An idea to block invalid addresses from reaching the peers.dat buckets - 2023-08-02T04:23:06.679316+00:00 - - Pieter Wuille 2021-07-13 00:54:29+00:00 - - - Ali Sherief 2021-07-12 23:33:16+00:00 - + 2025-09-26T15:42:59.107585+00:00 + python-feedgen + + + [bitcoin-dev] An idea to block invalid addresses from reaching the peers.dat buckets Ali Sherief + 2021-07-12T23:33:00.000Z + + + Pieter Wuille + 2021-07-13T00:54:00.000Z + + - python-feedgen + 2 Combined summary - An idea to block invalid addresses from reaching the peers.dat buckets - 2023-08-02T04:23:06.679316+00:00 + 2025-09-26T15:42:59.108093+00:00 - According to a post on BitcoinTalk by Ali Sherief, the bitcoin network is being spammed with an addr message that points to invalid addresses and ports. This is causing problems with the peers.dat file and its corresponding memory structure. The custom record type used in the peers.dat file makes it difficult to parse and determine specific IP addresses listed in there. To address this issue, Sherief suggests implementing changes to prevent this type of attack from happening again. One solution proposed is to modify the AddrDb updating functionality so that it does not add nodes that are unreachable due to "connection refused" errors. These unreachable addresses can be stored in a new, separate database-like file or augmented in the peers.dat file under a new entry type. By immediately flushing invalid nodes from memory, unnecessary processing can be avoided.To facilitate the identification of blocked nodes, Sherief proposes creating a new ZMQ message that sends the node's list of ignored addresses. This will help other nodes discover and handle blocked nodes more effectively. Additionally, Sherief suggests introducing a new file or command-line/config option called "ignorelist" that contains a list of subnets that should never be read into the AddrDB buckets. This would work differently from the banlist, which is currently used to block peers that send invalid messages, not those that are simply unreachable.While it may not be feasible to completely avoid adding untried addresses, the existing structure should reasonably protect against database poisoning caused by spam. However, there is a processing cost associated with this protection. It remains unclear how easy or difficult it will be to implement these proposed changes to improve the situation. 2021-07-13T00:54:29+00:00 + According to a post on BitcoinTalk by Ali Sherief, the bitcoin network is being spammed with an addr message that points to invalid addresses and ports. This is causing problems with the peers.dat file and its corresponding memory structure. The custom record type used in the peers.dat file makes it difficult to parse and determine specific IP addresses listed in there. To address this issue, Sherief suggests implementing changes to prevent this type of attack from happening again. One solution proposed is to modify the AddrDb updating functionality so that it does not add nodes that are unreachable due to "connection refused" errors. These unreachable addresses can be stored in a new, separate database-like file or augmented in the peers.dat file under a new entry type. By immediately flushing invalid nodes from memory, unnecessary processing can be avoided.To facilitate the identification of blocked nodes, Sherief proposes creating a new ZMQ message that sends the node's list of ignored addresses. This will help other nodes discover and handle blocked nodes more effectively. Additionally, Sherief suggests introducing a new file or command-line/config option called "ignorelist" that contains a list of subnets that should never be read into the AddrDB buckets. This would work differently from the banlist, which is currently used to block peers that send invalid messages, not those that are simply unreachable.While it may not be feasible to completely avoid adding untried addresses, the existing structure should reasonably protect against database poisoning caused by spam. However, there is a processing cost associated with this protection. It remains unclear how easy or difficult it will be to implement these proposed changes to improve the situation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml b/static/bitcoin-dev/July_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml index 08b17b37d1..098d10a2c3 100644 --- a/static/bitcoin-dev/July_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml +++ b/static/bitcoin-dev/July_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - BIP Proposals for Output Script Descriptors - 2023-08-02T04:16:38.460464+00:00 - - Christopher Allen 2021-08-05 20:49:43+00:00 - - - Sjors Provoost 2021-08-05 14:27:12+00:00 - - - Daniel Bayerdorffer 2021-07-04 17:56:28+00:00 - - - Craig Raw 2021-07-03 14:00:51+00:00 - - - David A. Harding 2021-07-03 10:05:40+00:00 - - - Craig Raw 2021-07-03 08:35:48+00:00 - - - Andrew Chow 2021-07-03 05:12:35+00:00 - - - David A. Harding 2021-07-03 03:24:05+00:00 - - - Andrew Chow 2021-07-02 20:05:45+00:00 - - - Andrew Chow 2021-06-29 22:35:49+00:00 - - - Christopher Allen 2021-06-29 22:22:39+00:00 - - - Andrew Chow 2021-06-29 21:14:39+00:00 - + 2025-09-26T15:42:31.744976+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposals for Output Script Descriptors Andrew Chow + 2021-06-29T21:14:00.000Z + + + Christopher Allen + 2021-06-29T22:22:00.000Z + + + Andrew Chow + 2021-06-29T22:35:00.000Z + + + Andrew Chow + 2021-07-02T20:05:00.000Z + + + David A. Harding + 2021-07-03T03:24:00.000Z + + + Andrew Chow + 2021-07-03T05:12:00.000Z + + + Craig Raw + 2021-07-03T08:35:00.000Z + + + David A. Harding + 2021-07-03T10:05:00.000Z + + + Craig Raw + 2021-07-03T14:00:00.000Z + + + Daniel Bayerdorffer + 2021-07-04T17:56:00.000Z + + + Sjors Provoost + 2021-08-05T14:27:00.000Z + + + Christopher Allen + 2021-08-05T20:49:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - BIP Proposals for Output Script Descriptors - 2023-08-02T04:16:38.461465+00:00 + 2025-09-26T15:42:31.746479+00:00 - In a discussion on the bitcoin-dev mailing list, Sjors Provoost proposed adding a birth date or minimum block height to the BIP 32 and BIP 88 standards for Hierarchical Deterministic Path Templates. He suggested using a metadata format to track this information alongside descriptors.The Airgap Wallet Community supports metadata in their UR standards, which use CBOR's tagging capability. The UR standards also provide efficient transport via QR codes or URLs. Interested parties can learn more about these standards by watching a video on Blockchain Commons Technology Overview or reading articles on URs, including guides for key material and SSKRs, as well as UR Request & Response. Additionally, there are specs available on Uniform Resources (UR) and HD Keys. For further questions, individuals can visit the Airgapped Wallet Community on GitHub.Bitcoin Core developer Andrew Chow has proposed formalizing the Output Script Descriptors in a set of 7 BIPs. These descriptors are used to describe collections of output scripts and offer a generic solution to issues with wallet backups and exports. The 7 BIPs specify various descriptors such as non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo descriptor, and opaque descriptors (raw, addr). The proposal also suggests including a birth date and metadata format to track birth data, gap limits, and other necessary information for future wallets. Another document outlines specifications for Bitcoin output script descriptors, specifically for P2WPKH and P2WSH formats (wpkh() and wsh() expressions), as well as P2PK, P2PKH, and P2SH formats (pk(), pkh(), and sh() expressions).There has been a debate on whether to use an apostrophe or 'h' in Bitcoin output script descriptors. Craig Raw argued that using an apostrophe allows for more whitespace and easier visual parsing, while David A. Harding countered that the difference in space usage is negligible and that using 'h' or 'H' avoids potential errors in shell-quoting and is more efficient for metal backups. Daniel Bayerdorffer of Numberall Stamp & Tool Co., Inc. recommended the Bitcoin Recovery Tag as a metal backup option that supports both apostrophes and 'h'. The discussion highlights the importance of considering user experience and practical considerations in the design of Bitcoin-related tools and protocols.The debate over using 'h' or an apostrophe in Bitcoin descriptors continued, with David A. Harding expressing concerns about using 'h' as it takes up more space and makes derivation paths and descriptors more difficult to read. However, Andrew Chow pointed out that the difference in space is only 0.7% and there are no issues with readability or transcription errors due to the use of a fixed character width font and checksums. Additionally, he mentioned that using apostrophes actually provides more whitespace and makes the path easier to parse visually. The real concern lies in using "-containing descriptors in a bourne-style shell, which can lead to loss of money. Ultimately, Raw agreed with Harding's points.David A. Harding proposed making "h"/"H" the preferred aliases instead of "'" in Bitcoin descriptors to improve user experience. However, Andrew Chow raised concerns about increased space usage and difficulty in reading descriptors and derivation paths. David suggested alternative options like completely eliminating "'", but it was not feasible due to widespread use of descriptors, or calculating the checksum over s/(h|H)/', which had been discussed before but not implemented due to the need for dumb checksum checkers that don't have to parse descriptors. In conclusion, the text was updated to use "h", but alternatives were still being considered.Andrew Chow has submitted a pull request to formalize Bitcoin Core's Output Script Descriptors into BIPs. The specifications are split into seven BIPs, with the first one providing general information and the rest specifying different descriptors. These descriptors offer a generic solution to issues with wallet backups by explicitly specifying script types and key derivation paths. They include non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), taproot descriptor (tr), combo descriptor, and opaque descriptors (raw, addr). Jeremy Rubin suggested collecting feedback through WIP PRs. Bitcoin Core has implemented pk(), pkh(), sh(), and tr() descriptors since version 0.17 and version 22.0.In an email exchange between Christopher Allen and Andrew Poelstra, the possibility of supporting time locks in descriptors other than 'raw' was discussed. Andrew mentioned that he expects miniscript to be a follow-up BIP that extends these descriptors and includes timelock functionality. Christopher shared a link to a document titled "Designing Multisig for Independence & Resilience" on Github, which discusses scenarios 2021-08-05T20:49:43+00:00 + In a discussion on the bitcoin-dev mailing list, Sjors Provoost proposed adding a birth date or minimum block height to the BIP 32 and BIP 88 standards for Hierarchical Deterministic Path Templates. He suggested using a metadata format to track this information alongside descriptors.The Airgap Wallet Community supports metadata in their UR standards, which use CBOR's tagging capability. The UR standards also provide efficient transport via QR codes or URLs. Interested parties can learn more about these standards by watching a video on Blockchain Commons Technology Overview or reading articles on URs, including guides for key material and SSKRs, as well as UR Request & Response. Additionally, there are specs available on Uniform Resources (UR) and HD Keys. For further questions, individuals can visit the Airgapped Wallet Community on GitHub.Bitcoin Core developer Andrew Chow has proposed formalizing the Output Script Descriptors in a set of 7 BIPs. These descriptors are used to describe collections of output scripts and offer a generic solution to issues with wallet backups and exports. The 7 BIPs specify various descriptors such as non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo descriptor, and opaque descriptors (raw, addr). The proposal also suggests including a birth date and metadata format to track birth data, gap limits, and other necessary information for future wallets. Another document outlines specifications for Bitcoin output script descriptors, specifically for P2WPKH and P2WSH formats (wpkh() and wsh() expressions), as well as P2PK, P2PKH, and P2SH formats (pk(), pkh(), and sh() expressions).There has been a debate on whether to use an apostrophe or 'h' in Bitcoin output script descriptors. Craig Raw argued that using an apostrophe allows for more whitespace and easier visual parsing, while David A. Harding countered that the difference in space usage is negligible and that using 'h' or 'H' avoids potential errors in shell-quoting and is more efficient for metal backups. Daniel Bayerdorffer of Numberall Stamp & Tool Co., Inc. recommended the Bitcoin Recovery Tag as a metal backup option that supports both apostrophes and 'h'. The discussion highlights the importance of considering user experience and practical considerations in the design of Bitcoin-related tools and protocols.The debate over using 'h' or an apostrophe in Bitcoin descriptors continued, with David A. Harding expressing concerns about using 'h' as it takes up more space and makes derivation paths and descriptors more difficult to read. However, Andrew Chow pointed out that the difference in space is only 0.7% and there are no issues with readability or transcription errors due to the use of a fixed character width font and checksums. Additionally, he mentioned that using apostrophes actually provides more whitespace and makes the path easier to parse visually. The real concern lies in using "-containing descriptors in a bourne-style shell, which can lead to loss of money. Ultimately, Raw agreed with Harding's points.David A. Harding proposed making "h"/"H" the preferred aliases instead of "'" in Bitcoin descriptors to improve user experience. However, Andrew Chow raised concerns about increased space usage and difficulty in reading descriptors and derivation paths. David suggested alternative options like completely eliminating "'", but it was not feasible due to widespread use of descriptors, or calculating the checksum over s/(h|H)/', which had been discussed before but not implemented due to the need for dumb checksum checkers that don't have to parse descriptors. In conclusion, the text was updated to use "h", but alternatives were still being considered.Andrew Chow has submitted a pull request to formalize Bitcoin Core's Output Script Descriptors into BIPs. The specifications are split into seven BIPs, with the first one providing general information and the rest specifying different descriptors. These descriptors offer a generic solution to issues with wallet backups by explicitly specifying script types and key derivation paths. They include non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), taproot descriptor (tr), combo descriptor, and opaque descriptors (raw, addr). Jeremy Rubin suggested collecting feedback through WIP PRs. Bitcoin Core has implemented pk(), pkh(), sh(), and tr() descriptors since version 0.17 and version 22.0.In an email exchange between Christopher Allen and Andrew Poelstra, the possibility of supporting time locks in descriptors other than 'raw' was discussed. Andrew mentioned that he expects miniscript to be a follow-up BIP that extends these descriptors and includes timelock functionality. Christopher shared a link to a document titled "Designing Multisig for Independence & Resilience" on Github, which discusses scenarios - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_BIP-proposal-Anti-fee-sniping-protection-with-nSequence-in-taproot-transactions-to-improve-privacy-for-off-chain-protocols.xml b/static/bitcoin-dev/July_2021/combined_BIP-proposal-Anti-fee-sniping-protection-with-nSequence-in-taproot-transactions-to-improve-privacy-for-off-chain-protocols.xml index 2aeb84a01a..89a5ea8d50 100644 --- a/static/bitcoin-dev/July_2021/combined_BIP-proposal-Anti-fee-sniping-protection-with-nSequence-in-taproot-transactions-to-improve-privacy-for-off-chain-protocols.xml +++ b/static/bitcoin-dev/July_2021/combined_BIP-proposal-Anti-fee-sniping-protection-with-nSequence-in-taproot-transactions-to-improve-privacy-for-off-chain-protocols.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols - 2023-08-02T03:59:33.810647+00:00 - - Chris Belcher 2021-07-22 14:44:11+00:00 - - - Chris Belcher 2021-06-29 09:25:52+00:00 - - - Ben Carman 2021-06-28 10:55:30+00:00 - - - Chris Belcher 2021-06-10 12:56:46+00:00 - + 2025-09-26T15:43:01.197115+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols Chris Belcher + 2021-06-10T12:56:00.000Z + + + Ben Carman + 2021-06-28T10:55:00.000Z + + + Chris Belcher + 2021-06-29T09:25:00.000Z + + + Chris Belcher + 2021-07-22T14:44:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols - 2023-08-02T03:59:33.810647+00:00 + 2025-09-26T15:43:01.197880+00:00 - The author of the taproot privacy BIP proposal has created python-like pseudocode to clarify the specification based on feedback. The pseudocode incorporates the suggestion of selecting a random input instead of the first one. It is important for wallet developers to include this BIP in their implementations as it will enhance the privacy and fungibility of off-chain protocols. Additionally, it will improve incentives for miners in Bitcoin's low-inflation future. The provided pseudocode includes a function called "apply_anti_fee_sniping_fields" which sets the transaction version to 2 in accordance with bip68. If any of the transaction inputs have more than 65535 confirmations or are taproot inputs, the function sets nlocktime. Otherwise, there is a 50% chance that either nlocktime or nsequence will be chosen. If a specific condition is met and randint(10) == 0, the function sets transaction.nlocktime to max(0, transaction.nlocktime - randint(0, 99)). If not, it randomly selects an input index and sets transaction.inputs[input_index].nsequence to transaction.inputs[input_index].confirmations(). Similarly, if the condition is met and randint(10) == 0, the function sets transaction.inputs[input_index].nsequence to max(0, transaction.inputs[input_index].nsequence - randint(0, 99)).The bitcoin-dev mailing list recently discussed potential amendments to BIP68, which focuses on the use of nSequence in transaction inputs. The current proposal states that nSequence should only apply to the first input when multiple inputs are present. However, participants in the discussion highlighted complications that could arise for protocols like DLC and dual funded lightning, where input ordering is unknown until both parties reveal their inputs. To address these concerns, it was suggested that the BIP be revised to state that "at least one of the inputs of the transaction" should have nSequence applied, and on-chain wallets should randomly select an input when applying nSequence. These changes would also impact CoinJoins and transactions involving multiple parties contributing inputs.The article emphasizes the potential complications that could arise from limiting nSequence to the first input of a transaction with multiple inputs. This issue could affect protocols like DLC and dual funded lightning, where input ordering is not known until all inputs are revealed. To ensure compatibility with these protocols, it is proposed that nSequence should apply to "at least one of the inputs of the transaction" instead of just the first input.The proposal introduces a new type of wallet behavior using BIP341 taproot, which enhances anonymity for off-chain protocols utilizing point-time-locked contracts (PTLCs) such as CoinSwap, Lightning, and Discrete Log Contracts. By incorporating nSequence in taproot transactions, on-chain wallets like Bitcoin Core can improve the privacy and fungibility of bitcoin. The proposal suggests using nSequence instead of nLockTime anti-fee-sniping protection, as nSequence values are currently uncommon and would designate off-chain settlement transactions as ordinary spend transactions. It is crucial for the community and wallet developers to implement this proposal to build up the anonymity set of nSequence transactions alongside the adoption of taproot by wallets. Fee sniping poses hypothetical challenges to Bitcoin mining in a low-inflation future, and anti-fee-sniping protection using nLockTime or nSequence contributes to pushing the blockchain forward. While nLockTime is currently used, it presents absolute lock time, whereas many off-chain protocols employ relative lock times. Hence, both nLockTime and nSequence should be utilized, with wallets choosing either an nLockTime value or nSequence values to discourage fee sniping. When creating transactions involving UTXOs protected by BIP341 taproot, wallets should also include a second random branch that sets the nLockTime or nSequence value further back. This enhances privacy for transactions that are delayed after signing due to factors like high-latency mix networks. If the UTXOs being spent have more than 65535 confirmations, wallets should use nLockTime instead of nSequence. It is important to note that this proposal does not require consensus changes and can be adopted gradually by wallets. However, for greater privacy, it is recommended for software to adopt it as soon as possible during the implementation of taproot wallets. By doing so, taproot adoption will already incorporate the nSequence code. More information on this proposal can be found in the provided references. 2021-07-22T14:44:11+00:00 + The author of the taproot privacy BIP proposal has created python-like pseudocode to clarify the specification based on feedback. The pseudocode incorporates the suggestion of selecting a random input instead of the first one. It is important for wallet developers to include this BIP in their implementations as it will enhance the privacy and fungibility of off-chain protocols. Additionally, it will improve incentives for miners in Bitcoin's low-inflation future. The provided pseudocode includes a function called "apply_anti_fee_sniping_fields" which sets the transaction version to 2 in accordance with bip68. If any of the transaction inputs have more than 65535 confirmations or are taproot inputs, the function sets nlocktime. Otherwise, there is a 50% chance that either nlocktime or nsequence will be chosen. If a specific condition is met and randint(10) == 0, the function sets transaction.nlocktime to max(0, transaction.nlocktime - randint(0, 99)). If not, it randomly selects an input index and sets transaction.inputs[input_index].nsequence to transaction.inputs[input_index].confirmations(). Similarly, if the condition is met and randint(10) == 0, the function sets transaction.inputs[input_index].nsequence to max(0, transaction.inputs[input_index].nsequence - randint(0, 99)).The bitcoin-dev mailing list recently discussed potential amendments to BIP68, which focuses on the use of nSequence in transaction inputs. The current proposal states that nSequence should only apply to the first input when multiple inputs are present. However, participants in the discussion highlighted complications that could arise for protocols like DLC and dual funded lightning, where input ordering is unknown until both parties reveal their inputs. To address these concerns, it was suggested that the BIP be revised to state that "at least one of the inputs of the transaction" should have nSequence applied, and on-chain wallets should randomly select an input when applying nSequence. These changes would also impact CoinJoins and transactions involving multiple parties contributing inputs.The article emphasizes the potential complications that could arise from limiting nSequence to the first input of a transaction with multiple inputs. This issue could affect protocols like DLC and dual funded lightning, where input ordering is not known until all inputs are revealed. To ensure compatibility with these protocols, it is proposed that nSequence should apply to "at least one of the inputs of the transaction" instead of just the first input.The proposal introduces a new type of wallet behavior using BIP341 taproot, which enhances anonymity for off-chain protocols utilizing point-time-locked contracts (PTLCs) such as CoinSwap, Lightning, and Discrete Log Contracts. By incorporating nSequence in taproot transactions, on-chain wallets like Bitcoin Core can improve the privacy and fungibility of bitcoin. The proposal suggests using nSequence instead of nLockTime anti-fee-sniping protection, as nSequence values are currently uncommon and would designate off-chain settlement transactions as ordinary spend transactions. It is crucial for the community and wallet developers to implement this proposal to build up the anonymity set of nSequence transactions alongside the adoption of taproot by wallets. Fee sniping poses hypothetical challenges to Bitcoin mining in a low-inflation future, and anti-fee-sniping protection using nLockTime or nSequence contributes to pushing the blockchain forward. While nLockTime is currently used, it presents absolute lock time, whereas many off-chain protocols employ relative lock times. Hence, both nLockTime and nSequence should be utilized, with wallets choosing either an nLockTime value or nSequence values to discourage fee sniping. When creating transactions involving UTXOs protected by BIP341 taproot, wallets should also include a second random branch that sets the nLockTime or nSequence value further back. This enhances privacy for transactions that are delayed after signing due to factors like high-latency mix networks. If the UTXOs being spent have more than 65535 confirmations, wallets should use nLockTime instead of nSequence. It is important to note that this proposal does not require consensus changes and can be adopted gradually by wallets. However, for greater privacy, it is recommended for software to adopt it as soon as possible during the implementation of taproot wallets. By doing so, taproot adoption will already incorporate the nSequence code. More information on this proposal can be found in the provided references. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml b/static/bitcoin-dev/July_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml index 1c91c16afb..fb8462aa68 100644 --- a/static/bitcoin-dev/July_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml +++ b/static/bitcoin-dev/July_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml @@ -1,131 +1,175 @@ - + 2 Combined summary - Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy - 2023-08-02T04:05:11.326798+00:00 - - Erik Aronesty 2022-11-02 17:30:13+00:00 - - - raymo at riseup.net 2021-08-09 20:22:57+00:00 - - - raymo at riseup.net 2021-08-09 16:22:29+00:00 - - - s7r 2021-08-09 00:03:31+00:00 - - - raymo at riseup.net 2021-08-08 09:11:42+00:00 - - - Tao Effect 2021-07-17 18:54:22+00:00 - - - raymo at riseup.net 2021-07-17 15:50:30+00:00 - - - Billy Tetrud 2021-07-07 03:20:38+00:00 - - - raymo at riseup.net 2021-07-03 08:02:09+00:00 - - - Billy Tetrud 2021-07-02 17:57:54+00:00 - - - raymo at riseup.net 2021-07-01 22:15:13+00:00 - - - Erik Aronesty 2021-07-01 20:49:16+00:00 - - - raymo at riseup.net 2021-07-01 20:11:10+00:00 - - - raymo at riseup.net 2021-06-30 12:21:27+00:00 - - - ZmnSCPxj 2021-06-29 21:42:26+00:00 - - - raymo at riseup.net 2021-06-28 19:07:40+00:00 - - - Ricardo Filipe 2021-06-28 18:05:46+00:00 - - - Alex Schoof 2021-06-28 17:58:47+00:00 - - - raymo at riseup.net 2021-06-28 17:38:10+00:00 - - - Tao Effect 2021-06-28 17:29:40+00:00 - - - raymo at riseup.net 2021-06-28 16:58:37+00:00 - - - raymo at riseup.net 2021-06-28 16:33:24+00:00 - - - ZmnSCPxj 2021-06-28 15:28:44+00:00 - - - James Hilliard 2021-06-28 11:28:13+00:00 - - - raymo at riseup.net 2021-06-28 09:52:38+00:00 - - - James Hilliard 2021-06-28 08:23:00+00:00 - - - raymo at riseup.net 2021-06-28 06:29:59+00:00 - - - ZmnSCPxj 2021-06-28 05:20:08+00:00 - - - raymo at riseup.net 2021-06-27 11:05:04+00:00 - - - ZmnSCPxj 2021-06-27 04:53:52+00:00 - - - raymo at riseup.net 2021-06-26 21:54:26+00:00 - - - Billy Tetrud 2021-06-22 18:20:51+00:00 - - - James Hilliard 2021-06-20 01:59:54+00:00 - - - ZmnSCPxj 2021-06-20 00:53:58+00:00 - - - Erik Aronesty 2021-06-19 21:14:08+00:00 - - - raymo at riseup.net 2021-06-18 20:22:08+00:00 - - - raymo at riseup.net 2021-06-18 20:00:12+00:00 - - - Alex Schoof 2021-06-18 13:44:17+00:00 - - - Erik Aronesty 2021-06-18 13:37:54+00:00 - - - Erik Aronesty 2021-06-18 01:42:39+00:00 - - - raymo at riseup.net 2021-06-16 13:44:24+00:00 - + 2025-09-26T15:42:25.414690+00:00 + python-feedgen + + + [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo + 2021-06-16T13:44:00.000Z + + + Erik Aronesty + 2021-06-18T01:42:00.000Z + + + Erik Aronesty + 2021-06-18T13:37:00.000Z + + + Alex Schoof + 2021-06-18T13:44:00.000Z + + + raymo + 2021-06-18T20:00:00.000Z + + + raymo + 2021-06-18T20:22:00.000Z + + + Erik Aronesty + 2021-06-19T21:14:00.000Z + + + ZmnSCPxj + 2021-06-20T00:53:00.000Z + + + James Hilliard + 2021-06-20T01:59:00.000Z + + + Billy Tetrud + 2021-06-22T18:20:00.000Z + + + raymo + 2021-06-26T21:54:00.000Z + + + ZmnSCPxj + 2021-06-27T04:53:00.000Z + + + raymo + 2021-06-27T11:05:00.000Z + + + ZmnSCPxj + 2021-06-28T05:20:00.000Z + + + raymo + 2021-06-28T06:29:00.000Z + + + James Hilliard + 2021-06-28T08:23:00.000Z + + + raymo + 2021-06-28T09:52:00.000Z + + + James Hilliard + 2021-06-28T11:28:00.000Z + + + ZmnSCPxj + 2021-06-28T15:28:00.000Z + + + raymo + 2021-06-28T16:33:00.000Z + + + raymo + 2021-06-28T16:58:00.000Z + + + Tao Effect + 2021-06-28T17:29:00.000Z + + + raymo + 2021-06-28T17:38:00.000Z + + + Alex Schoof + 2021-06-28T17:58:00.000Z + + + Ricardo Filipe + 2021-06-28T18:05:00.000Z + + + raymo + 2021-06-28T19:07:00.000Z + + + ZmnSCPxj + 2021-06-29T21:42:00.000Z + + + raymo + 2021-06-30T12:21:00.000Z + + + raymo + 2021-07-01T20:11:00.000Z + + + Erik Aronesty + 2021-07-01T20:49:00.000Z + + + raymo + 2021-07-01T22:15:00.000Z + + + Billy Tetrud + 2021-07-02T17:57:00.000Z + + + raymo + 2021-07-03T08:02:00.000Z + + + Billy Tetrud + 2021-07-07T03:20:00.000Z + + + raymo + 2021-07-17T15:50:00.000Z + + + Tao Effect + 2021-07-17T18:54:00.000Z + + + raymo + 2021-08-08T09:11:00.000Z + + + s7r + 2021-08-09T00:03:00.000Z + + + raymo + 2021-08-09T16:22:00.000Z + + + raymo + 2021-08-09T20:22:00.000Z + + + Erik Aronesty + 2022-11-02T17:30:00.000Z + + @@ -167,13 +211,13 @@ - python-feedgen + 2 Combined summary - Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy - 2023-08-02T04:05:11.326798+00:00 + 2025-09-26T15:42:25.419074+00:00 - Full Replace-By-Fee (RBF) is becoming the norm in the Sabu protocol, and transactions without it can be rejected. Watchtowers can prevent attacks in progress by offering an always-on watchtower service for a small fee. The Sabu state functions as another mempool, so it's important for all parties to maintain it.An email exchange between Raymo and Chris Riley discusses the uncertainty surrounding potential revenue increases under the Sabu protocol. While upgrading the Bitcoin protocol wouldn't be technically difficult, consensus on implementation changes is required. If there are difficulties with implementing changes to the Bitcoin core protocol, the Stratum protocol could be changed instead.Miners have the incentive to accept the highest fee transaction, but there is no guarantee due to the untrusted nature of the network. It is still uncertain whether miners will prefer the highest fee transaction or keep the first transaction received and drop subsequent ones.The Guarantee Transaction is created based on the Main Transaction but has no direct relation to it. Miners choose the Guarantee Transaction over other transactions spending the same UTXO(s) because it offers a notably higher fee. Bob must be online 24/7 to prevent Alice's attack from succeeding completely.The email thread also discusses a hypothetical fraudulent attack on Bitcoin's Lightning Network. This attack involves a malicious actor using already-spent inputs to defraud a creditor. Despite a higher fee in the Guarantee transaction, miners are unlikely to drop the Sabu-Killing-transaction and consider only the Guarantee transaction. The attack has a 99% chance of success, and Bob needs to be online continuously to prevent it.The email raises a question about how Bob can spend the coins he received and become an issuer in relation to another creditor, Dave. If Alice tries to defraud Bob after he spent his Sabu credit to Dave, Dave would need to hold all parent "guarantee transactions" and watch for potential fraudulent transactions.Raymo, the creator of Sabu, suggests penalties for issuers, creditors, and miners instead of a claw-back mechanism. He is actively working on realizing the Sabu protocol and Gazin wallet. The proposal is open for review and feedback on various platforms.The Sabu protocol aims to improve Bitcoin circulation, transaction processing speed (TPS), and privacy. It allows users to send and receive Bitcoin without opening channels or paying transaction fees. Transactions are recorded on the Bitcoin blockchain only in case of fraudulent activity. The protocol involves issuers who own Bitcoin and creditors who receive it in exchange for goods or services.The security model of Sabu relies on guarantee transactions to ensure creditors receive payment even in case of fraud. The protocol offers self-sovereignty and decentralized communication, with PGP encryption ensuring privacy. Wallets can add friends using email addresses or scanned public keys. Each transaction is a small money transfer with specific inputs and outputs, and creditors pay a Sabu-transaction-fee to issuers.Despite concerns about the assumptions made in the proposal and the use of email for user identification and communication, the Sabu protocol offers a promising solution to improve Bitcoin circulation, TPS, and privacy. It provides an alternative to the Lightning Network and traditional custodial solutions.In conclusion, the Sabu protocol proposes a peer-to-peer network architecture that allows for improved Bitcoin trading with enhanced privacy and self-sovereignty. It addresses concerns about cheating through guarantee transactions and offers an alternative approach to transaction processing speed. However, further evaluation and addressing of concerns are necessary for successful implementation.The author of the article suggests using email as the primary communication method for transactions, despite potential privacy concerns. They argue that email is the most neutral, free, and globally accessible option. However, this protocol does not address the issue of preventing fraud proofs. As alternatives, QR codes and device-to-device linking are proposed for adding contacts to the contact list.To improve Bitcoin's transaction per second (TPS) and privacy, a proposal has been made to create a new cryptocurrency called IOUs that would run on top of Bitcoin. However, there are concerns about preventing double-spending, network latency, and spam filters when using email as the remote procedure call mechanism. Consensus among nodes is necessary to avoid conflicts regarding the correct set of "sent notes".Another plan to enhance Bitcoin's TPS and privacy involves implementing an off-chain transaction network, as suggested by Raymo. This system guarantees security through relative fees and the cost-of-theft. It is recommended for small transactions similar to Lightning but without limits or routing protocols. More details can be found in Raymo's Medium post and Bitcointalk forum, where the community is invited to provide feedback and thoughts.In summary, various discussions have taken place regarding mining behavior, high transaction fees, and latency issues in the Bitcoin network. The vulnerability of sybil attacks and proxy attacks has also been addressed, along with suggestions for defense mechanisms. Both the Sabu protocol and Raymo's proposal aim to improve Bitcoin's TPS and 2022-11-02T17:30:13+00:00 + Full Replace-By-Fee (RBF) is becoming the norm in the Sabu protocol, and transactions without it can be rejected. Watchtowers can prevent attacks in progress by offering an always-on watchtower service for a small fee. The Sabu state functions as another mempool, so it's important for all parties to maintain it.An email exchange between Raymo and Chris Riley discusses the uncertainty surrounding potential revenue increases under the Sabu protocol. While upgrading the Bitcoin protocol wouldn't be technically difficult, consensus on implementation changes is required. If there are difficulties with implementing changes to the Bitcoin core protocol, the Stratum protocol could be changed instead.Miners have the incentive to accept the highest fee transaction, but there is no guarantee due to the untrusted nature of the network. It is still uncertain whether miners will prefer the highest fee transaction or keep the first transaction received and drop subsequent ones.The Guarantee Transaction is created based on the Main Transaction but has no direct relation to it. Miners choose the Guarantee Transaction over other transactions spending the same UTXO(s) because it offers a notably higher fee. Bob must be online 24/7 to prevent Alice's attack from succeeding completely.The email thread also discusses a hypothetical fraudulent attack on Bitcoin's Lightning Network. This attack involves a malicious actor using already-spent inputs to defraud a creditor. Despite a higher fee in the Guarantee transaction, miners are unlikely to drop the Sabu-Killing-transaction and consider only the Guarantee transaction. The attack has a 99% chance of success, and Bob needs to be online continuously to prevent it.The email raises a question about how Bob can spend the coins he received and become an issuer in relation to another creditor, Dave. If Alice tries to defraud Bob after he spent his Sabu credit to Dave, Dave would need to hold all parent "guarantee transactions" and watch for potential fraudulent transactions.Raymo, the creator of Sabu, suggests penalties for issuers, creditors, and miners instead of a claw-back mechanism. He is actively working on realizing the Sabu protocol and Gazin wallet. The proposal is open for review and feedback on various platforms.The Sabu protocol aims to improve Bitcoin circulation, transaction processing speed (TPS), and privacy. It allows users to send and receive Bitcoin without opening channels or paying transaction fees. Transactions are recorded on the Bitcoin blockchain only in case of fraudulent activity. The protocol involves issuers who own Bitcoin and creditors who receive it in exchange for goods or services.The security model of Sabu relies on guarantee transactions to ensure creditors receive payment even in case of fraud. The protocol offers self-sovereignty and decentralized communication, with PGP encryption ensuring privacy. Wallets can add friends using email addresses or scanned public keys. Each transaction is a small money transfer with specific inputs and outputs, and creditors pay a Sabu-transaction-fee to issuers.Despite concerns about the assumptions made in the proposal and the use of email for user identification and communication, the Sabu protocol offers a promising solution to improve Bitcoin circulation, TPS, and privacy. It provides an alternative to the Lightning Network and traditional custodial solutions.In conclusion, the Sabu protocol proposes a peer-to-peer network architecture that allows for improved Bitcoin trading with enhanced privacy and self-sovereignty. It addresses concerns about cheating through guarantee transactions and offers an alternative approach to transaction processing speed. However, further evaluation and addressing of concerns are necessary for successful implementation.The author of the article suggests using email as the primary communication method for transactions, despite potential privacy concerns. They argue that email is the most neutral, free, and globally accessible option. However, this protocol does not address the issue of preventing fraud proofs. As alternatives, QR codes and device-to-device linking are proposed for adding contacts to the contact list.To improve Bitcoin's transaction per second (TPS) and privacy, a proposal has been made to create a new cryptocurrency called IOUs that would run on top of Bitcoin. However, there are concerns about preventing double-spending, network latency, and spam filters when using email as the remote procedure call mechanism. Consensus among nodes is necessary to avoid conflicts regarding the correct set of "sent notes".Another plan to enhance Bitcoin's TPS and privacy involves implementing an off-chain transaction network, as suggested by Raymo. This system guarantees security through relative fees and the cost-of-theft. It is recommended for small transactions similar to Lightning but without limits or routing protocols. More details can be found in Raymo's Medium post and Bitcointalk forum, where the community is invited to provide feedback and thoughts.In summary, various discussions have taken place regarding mining behavior, high transaction fees, and latency issues in the Bitcoin network. The vulnerability of sybil attacks and proxy attacks has also been addressed, along with suggestions for defense mechanisms. Both the Sabu protocol and Raymo's proposal aim to improve Bitcoin's TPS and - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml b/static/bitcoin-dev/July_2021/combined_CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml index 4bbe1ce3db..1c5a14b030 100644 --- a/static/bitcoin-dev/July_2021/combined_CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml +++ b/static/bitcoin-dev/July_2021/combined_CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml @@ -1,41 +1,135 @@ - + 2 Combined summary - CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2023-08-02T04:19:47.628039+00:00 - - Jeremy 2021-07-06 18:53:32+00:00 - - - Russell O'Connor 2021-07-06 18:21:33+00:00 - - - Jeremy 2021-07-06 17:54:57+00:00 - - - Russell O'Connor 2021-07-04 19:03:40+00:00 - - - Jeremy 2021-07-04 18:39:44+00:00 - - - Jeremy 2021-07-04 17:30:18+00:00 - - - David A. Harding 2021-07-04 01:13:41+00:00 - - - Russell O'Connor 2021-07-03 20:12:51+00:00 - - - Jeremy 2021-07-03 18:30:45+00:00 - - - Russell O'Connor 2021-07-03 17:50:21+00:00 - - - Jeremy 2021-07-03 16:31:57+00:00 - + 2025-09-26T15:42:40.198573+00:00 + python-feedgen + + + [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin Jeremy + 2021-07-03T16:31:00.000Z + + + Russell O'Connor + 2021-07-03T17:50:00.000Z + + + Jeremy + 2021-07-03T18:30:00.000Z + + + Russell O'Connor + 2021-07-03T20:12:00.000Z + + + David A. Harding + 2021-07-04T01:13:00.000Z + + + Jeremy + 2021-07-04T17:30:00.000Z + + + Jeremy + 2021-07-04T18:39:00.000Z + + + Russell O'Connor + 2021-07-04T19:03:00.000Z + + + [bitcoin-dev] Unlimited covenants, was " David A. Harding + 2021-07-04T20:32:00.000Z + + + Billy Tetrud + 2021-07-04T20:50:00.000Z + + + ZmnSCPxj + 2021-07-05T00:50:00.000Z + + + Russell O'Connor + 2021-07-05T01:02:00.000Z + + + Russell O'Connor + 2021-07-05T02:10:00.000Z + + + ZmnSCPxj + 2021-07-05T02:39:00.000Z + + + Anthony Towns + 2021-07-05T05:04:00.000Z + + + Matt Corallo + 2021-07-05T13:46:00.000Z + + + Greg Sanders + 2021-07-05T13:51:00.000Z + + + Russell O'Connor + 2021-07-05T17:20:00.000Z + + + Billy Tetrud + 2021-07-06T06:25:00.000Z + + + Sanket Kanjalkar + 2021-07-06T10:20:00.000Z + + + Russell O'Connor + 2021-07-06T11:26:00.000Z + + + Jeremy + 2021-07-06T17:54:00.000Z + + + Russell O'Connor + 2021-07-06T18:21:00.000Z + + + Jeremy + 2021-07-06T18:36:00.000Z + + + Jeremy + 2021-07-06T18:53:00.000Z + + + ZmnSCPxj + 2021-07-07T04:26:00.000Z + + + Billy Tetrud + 2021-07-07T06:12:00.000Z + + + Russell O'Connor + 2021-07-07T13:12:00.000Z + + + Russell O'Connor + 2021-07-07T14:24:00.000Z + + + Jeremy + 2021-07-07T17:26:00.000Z + + + Anthony Towns + 2022-02-03T06:17:00.000Z + + @@ -47,13 +141,13 @@ - python-feedgen + 2 Combined summary - CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2023-08-02T04:19:47.628039+00:00 + 2025-09-26T15:42:40.202000+00:00 - The conversation revolves around the implementation of the `OP_CHECKSIGFROMSTACK` opcode and the different options available to split R and S values or variable-length messages. The four options discussed are making a new 64 byte PK standard, splitting (R,S), using different opcodes, and CAT. Each option has its own drawbacks, such as being designed for specific use cases, requiring an extra push byte for every use, or wasting opcodes.In regards to the usefulness of `CHECKSIGFROMSTACKADD`, Pieter Wuille suggests that it could be useful for doing a 2-of-3 between Alice, Bob, and an Oracle signed value. However, he suggests leaving it out until there is a specific use case for it. He also explains the benefits of using the non-prehashed argument in `CHECKSIGFROMSTACK`, such as faster signing oracles and improved privacy.Jeremy Rubin expresses his thoughts on sophisticated covenants and the need to ensure that enabling them does not require jumping through too many hoops. He believes that validation costs can be kept in check and individuals should have the freedom to burn their coins if they choose. He emphasizes the importance of specific additions not introducing unintended consequences.The Elements Project is working on updating the OP_CHECKSIGFROMSTACK implementation for tapscript on Elements. This new implementation would use BIP-0340 schnorr signatures, which support variable-length messages and batch verification. Jeremy requests links to the updated spec and Russell O'Connor provides details about the plan and implementation. It is believed that this design would be suitable for Bitcoin as well.There is a discussion about adapting the "CheckDataSig" specification for a BIP in Bitcoin using 2 OP_SUCCESSX opcodes. The email reproduces the Bitcoin Cash specification and lists design questions worth considering for modifications. The proposal aims to introduce more complex smart contract functionality on the Bitcoin Cash network.Overall, the conversation covers various aspects of implementing OP_CHECKSIGFROMSTACK and its potential applications, the usefulness of CHECKSIGFROMSTACKADD, the benefits of variable-length messages in BIP-0340 schnorr signatures, and the adaptation of the "CheckDataSig" specification for Bitcoin.The activation of the protocol upgrade and the presence of at least three items on the stack are essential for the successful execution of OP_CHECKDATASIGVERIFY. Additionally, the public key and signature must be validly encoded, and the signature must pass the Low S check and signature validation.If a transaction containing OP_CHECKDATASIGVERIFY is included in a block where the median timestamp of the previous 11 blocks is less than 1542300000, it will be invalidated unless it occurs within an unexecuted OP_IF branch.The specification for OP_CHECKDATASIGVERIFY is based on Andrew Stone's OP_DATASIGVERIFY proposal. However, it has been modified through peer-review and feedback to ensure its effectiveness.For those interested in further understanding, a C++ implementation of OP_CHECKDATASIGVERIFY is provided by Bitcoin ABC. References to related concepts and proposals like OP_CHECKSIG, Strict DER Encoding, Low-S and Nullfail Specification, as well as Andrew Stone's article on Scripting, are also available for additional information and context.Overall, the proper activation of the protocol upgrade, the validity of the public key and signature, and adherence to specific conditions during block inclusion are crucial for the successful execution and validation of transactions involving OP_CHECKDATASIGVERIFY. 2021-07-06T18:53:32+00:00 + The conversation revolves around the implementation of the `OP_CHECKSIGFROMSTACK` opcode and the different options available to split R and S values or variable-length messages. The four options discussed are making a new 64 byte PK standard, splitting (R,S), using different opcodes, and CAT. Each option has its own drawbacks, such as being designed for specific use cases, requiring an extra push byte for every use, or wasting opcodes.In regards to the usefulness of `CHECKSIGFROMSTACKADD`, Pieter Wuille suggests that it could be useful for doing a 2-of-3 between Alice, Bob, and an Oracle signed value. However, he suggests leaving it out until there is a specific use case for it. He also explains the benefits of using the non-prehashed argument in `CHECKSIGFROMSTACK`, such as faster signing oracles and improved privacy.Jeremy Rubin expresses his thoughts on sophisticated covenants and the need to ensure that enabling them does not require jumping through too many hoops. He believes that validation costs can be kept in check and individuals should have the freedom to burn their coins if they choose. He emphasizes the importance of specific additions not introducing unintended consequences.The Elements Project is working on updating the OP_CHECKSIGFROMSTACK implementation for tapscript on Elements. This new implementation would use BIP-0340 schnorr signatures, which support variable-length messages and batch verification. Jeremy requests links to the updated spec and Russell O'Connor provides details about the plan and implementation. It is believed that this design would be suitable for Bitcoin as well.There is a discussion about adapting the "CheckDataSig" specification for a BIP in Bitcoin using 2 OP_SUCCESSX opcodes. The email reproduces the Bitcoin Cash specification and lists design questions worth considering for modifications. The proposal aims to introduce more complex smart contract functionality on the Bitcoin Cash network.Overall, the conversation covers various aspects of implementing OP_CHECKSIGFROMSTACK and its potential applications, the usefulness of CHECKSIGFROMSTACKADD, the benefits of variable-length messages in BIP-0340 schnorr signatures, and the adaptation of the "CheckDataSig" specification for Bitcoin.The activation of the protocol upgrade and the presence of at least three items on the stack are essential for the successful execution of OP_CHECKDATASIGVERIFY. Additionally, the public key and signature must be validly encoded, and the signature must pass the Low S check and signature validation.If a transaction containing OP_CHECKDATASIGVERIFY is included in a block where the median timestamp of the previous 11 blocks is less than 1542300000, it will be invalidated unless it occurs within an unexecuted OP_IF branch.The specification for OP_CHECKDATASIGVERIFY is based on Andrew Stone's OP_DATASIGVERIFY proposal. However, it has been modified through peer-review and feedback to ensure its effectiveness.For those interested in further understanding, a C++ implementation of OP_CHECKDATASIGVERIFY is provided by Bitcoin ABC. References to related concepts and proposals like OP_CHECKSIG, Strict DER Encoding, Low-S and Nullfail Specification, as well as Andrew Stone's article on Scripting, are also available for additional information and context.Overall, the proper activation of the protocol upgrade, the validity of the public key and signature, and adherence to specific conditions during block inclusion are crucial for the successful execution and validation of transactions involving OP_CHECKDATASIGVERIFY. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_CheckSigFromStack-for-Arithmetic-Values.xml b/static/bitcoin-dev/July_2021/combined_CheckSigFromStack-for-Arithmetic-Values.xml index dee2766297..36503d03ce 100644 --- a/static/bitcoin-dev/July_2021/combined_CheckSigFromStack-for-Arithmetic-Values.xml +++ b/static/bitcoin-dev/July_2021/combined_CheckSigFromStack-for-Arithmetic-Values.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - CheckSigFromStack for Arithmetic Values - 2023-08-02T04:19:06.621353+00:00 - - ZmnSCPxj 2021-07-04 13:10:36+00:00 - - - ZmnSCPxj 2021-07-04 00:22:18+00:00 - - - Erik Aronesty 2021-07-03 11:31:04+00:00 - - - Jeremy 2021-07-03 04:01:01+00:00 - - - ZmnSCPxj 2021-07-02 23:58:14+00:00 - - - Jeremy 2021-07-02 22:20:16+00:00 - + 2025-09-26T15:42:46.499986+00:00 + python-feedgen + + + [bitcoin-dev] CheckSigFromStack for Arithmetic Values Jeremy + 2021-07-02T22:20:00.000Z + + + ZmnSCPxj + 2021-07-02T23:58:00.000Z + + + Jeremy + 2021-07-03T04:01:00.000Z + + + Erik Aronesty + 2021-07-03T11:31:00.000Z + + + ZmnSCPxj + 2021-07-04T00:22:00.000Z + + + ZmnSCPxj + 2021-07-04T13:10:00.000Z + + - python-feedgen + 2 Combined summary - CheckSigFromStack for Arithmetic Values - 2023-08-02T04:19:06.621353+00:00 + 2025-09-26T15:42:46.500812+00:00 - ZmnSCPxj wrote an email discussing the cleverness of using `OP_ADD` for implementing `OP_CHECKSIGFROMSTACK`, but mentioned that enabling `OP_ADD` is more of an argument against it. Despite this, `OP_ADD` is still enabled in Bitcoin, limited to 32 bits. He also discussed the possibility of implementing the "Lamport-sign the EC sig" idea, which would mean Bitcoin is already quantum-safe, but it has a lousy quantum-safe signing scheme.Jeremy proposed using arithmetic operations with Lamport signatures to enable signing operations. This implementation uses a bitwise expansion of a number and a Lamport signature for arbitrary values representable in small binary numbers. However, ZmnSCPxj noted that enabling `OP_ADD` could lead to single-use-only signatures and discouraged pubkey reuse.A member of the Bitcoin Development mailing list asked about using Schnorr signatures for complex arithmetic operations without involving the network or nodes. Another member confirmed it was possible and suggested signing the signature made with checksig with the Lamport, but there are some crypto assumption gotchas. They also discussed implementing Lamport signatures for arbitrary values representable in small binary numbers, showing a concrete example of a 16-bit sequence lock. They noted that Merkle signatures would be smaller for the pubkey, but much larger for the signature, making the script more complicated and expensive.Jeremy Rubin proposed using Lamport signatures in script for arithmetic values by using a binary expanded representation. He explained the approach through Python code and translated it into bitcoin script. The signer generates a key as a list of pairs of hash images, and the validation checks for no left-out values. A concrete use case is post-hoc signing a sequence lock. ZmnSCPxj expressed confusion over the syntax used in Rubin's code and suggested replacing the ` operator with actual numbers. He also mentioned that enabling OP_ADD can implement Lamport signatures for arbitrary values representable in small binary numbers, but Merkle signatures would have a larger signature size.Rubin proposed using Lamport signatures in script for arithmetic values by using a binary expanded representation. He explained the process through Python code and translated it into bitcoin script. A concrete use case is provided for post-hoc signing a sequence lock. The approach allows Lamport signatures for arbitrary values representable in small binary numbers. Merkle signatures were considered as an alternative, but the simplicity of the SCRIPT and no advantage in pushing the size towards the signature rather than the pubkey made the proposed approach preferred.Jeremy Rubin shared a technique for doing a Lamport signature in script for arithmetic values using a binary expanded representation. He posted about it in his blog, providing Python code and a bitcoin script translation. The technique involves expanding a number into its bitwise representation and using a Lamport signature. It can be used for certain applications like bonding contracts, but it can be bulky and expensive. Keys can be reused across scripts, but signatures may only be constructed one time to prevent unintended values. 2021-07-04T13:10:36+00:00 + ZmnSCPxj wrote an email discussing the cleverness of using `OP_ADD` for implementing `OP_CHECKSIGFROMSTACK`, but mentioned that enabling `OP_ADD` is more of an argument against it. Despite this, `OP_ADD` is still enabled in Bitcoin, limited to 32 bits. He also discussed the possibility of implementing the "Lamport-sign the EC sig" idea, which would mean Bitcoin is already quantum-safe, but it has a lousy quantum-safe signing scheme.Jeremy proposed using arithmetic operations with Lamport signatures to enable signing operations. This implementation uses a bitwise expansion of a number and a Lamport signature for arbitrary values representable in small binary numbers. However, ZmnSCPxj noted that enabling `OP_ADD` could lead to single-use-only signatures and discouraged pubkey reuse.A member of the Bitcoin Development mailing list asked about using Schnorr signatures for complex arithmetic operations without involving the network or nodes. Another member confirmed it was possible and suggested signing the signature made with checksig with the Lamport, but there are some crypto assumption gotchas. They also discussed implementing Lamport signatures for arbitrary values representable in small binary numbers, showing a concrete example of a 16-bit sequence lock. They noted that Merkle signatures would be smaller for the pubkey, but much larger for the signature, making the script more complicated and expensive.Jeremy Rubin proposed using Lamport signatures in script for arithmetic values by using a binary expanded representation. He explained the approach through Python code and translated it into bitcoin script. The signer generates a key as a list of pairs of hash images, and the validation checks for no left-out values. A concrete use case is post-hoc signing a sequence lock. ZmnSCPxj expressed confusion over the syntax used in Rubin's code and suggested replacing the ` operator with actual numbers. He also mentioned that enabling OP_ADD can implement Lamport signatures for arbitrary values representable in small binary numbers, but Merkle signatures would have a larger signature size.Rubin proposed using Lamport signatures in script for arithmetic values by using a binary expanded representation. He explained the process through Python code and translated it into bitcoin script. A concrete use case is provided for post-hoc signing a sequence lock. The approach allows Lamport signatures for arbitrary values representable in small binary numbers. Merkle signatures were considered as an alternative, but the simplicity of the SCRIPT and no advantage in pushing the size towards the signature rather than the pubkey made the proposed approach preferred.Jeremy Rubin shared a technique for doing a Lamport signature in script for arithmetic values using a binary expanded representation. He posted about it in his blog, providing Python code and a bitcoin script translation. The technique involves expanding a number into its bitwise representation and using a Lamport signature. It can be used for certain applications like bonding contracts, but it can be bulky and expensive. Keys can be reused across scripts, but signatures may only be constructed one time to prevent unintended values. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Covenant-opcode-proposal-OP-CONSTRAINDESTINATION-an-alternative-to-OP-CTV-.xml b/static/bitcoin-dev/July_2021/combined_Covenant-opcode-proposal-OP-CONSTRAINDESTINATION-an-alternative-to-OP-CTV-.xml index a4a8497a58..9b6179a2e0 100644 --- a/static/bitcoin-dev/July_2021/combined_Covenant-opcode-proposal-OP-CONSTRAINDESTINATION-an-alternative-to-OP-CTV-.xml +++ b/static/bitcoin-dev/July_2021/combined_Covenant-opcode-proposal-OP-CONSTRAINDESTINATION-an-alternative-to-OP-CTV-.xml @@ -1,50 +1,115 @@ - + 2 Combined summary - Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) - 2023-08-02T04:24:39.456958+00:00 - - Billy Tetrud 2021-11-01 01:19:42+00:00 - - - Billy Tetrud 2021-07-30 18:42:23+00:00 - - - Jeremy 2021-07-28 22:30:19+00:00 - - - Billy Tetrud 2021-07-28 17:57:09+00:00 - - - Zac Greenwood 2021-07-28 04:57:33+00:00 - - - Billy Tetrud 2021-07-27 17:21:11+00:00 - - - Zac Greenwood 2021-07-27 11:18:11+00:00 - - - Billy Tetrud 2021-07-27 00:41:29+00:00 - - - James MacWhyte 2021-07-26 21:08:09+00:00 - - - Billy Tetrud 2021-07-26 20:18:35+00:00 - - - David A. Harding 2021-07-26 00:05:53+00:00 - - - Billy Tetrud 2021-07-25 19:49:38+00:00 - - - David A. Harding 2021-07-25 05:38:03+00:00 - - - Billy Tetrud 2021-07-21 05:56:10+00:00 - + 2025-09-26T15:42:35.960361+00:00 + python-feedgen + + + [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud + 2021-07-21T05:56:00.000Z + + + David A. Harding + 2021-07-25T05:38:00.000Z + + + Billy Tetrud + 2021-07-25T19:49:00.000Z + + + David A. Harding + 2021-07-26T00:05:00.000Z + + + Billy Tetrud + 2021-07-26T20:18:00.000Z + + + James MacWhyte + 2021-07-26T21:08:00.000Z + + + Billy Tetrud + 2021-07-27T00:41:00.000Z + + + Zac Greenwood + 2021-07-27T11:18:00.000Z + + + Billy Tetrud + 2021-07-27T17:21:00.000Z + + + Zac Greenwood + 2021-07-28T04:57:00.000Z + + + Billy Tetrud + 2021-07-28T17:57:00.000Z + + + Jeremy + 2021-07-28T22:30:00.000Z + + + Billy Tetrud + 2021-07-30T18:42:00.000Z + + + [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood + 2021-07-31T20:01:00.000Z + + + Billy Tetrud + 2021-08-02T04:40:00.000Z + + + ZmnSCPxj + 2021-08-10T02:17:00.000Z + + + Zac Greenwood + 2021-08-13T11:02:00.000Z + + + ZmnSCPxj + 2021-08-14T01:50:00.000Z + + + Zac Greenwood + 2021-08-16T11:17:00.000Z + + + ZmnSCPxj + 2021-08-16T11:48:00.000Z + + + Zac Greenwood + 2021-08-30T14:43:00.000Z + + + ZmnSCPxj + 2021-08-31T09:00:00.000Z + + + Zac Greenwood + 2021-08-31T14:09:00.000Z + + + ZmnSCPxj + 2021-08-31T14:22:00.000Z + + + Zac Greenwood + 2021-09-01T15:15:00.000Z + + + Billy Tetrud + 2021-11-01T01:19:00.000Z + + @@ -59,13 +124,13 @@ - python-feedgen + 2 Combined summary - Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) - 2023-08-02T04:24:39.456958+00:00 + 2025-09-26T15:42:35.963075+00:00 - The conversation begins with Billy explaining the benefits of a 2-key wallet vault using OP_CD over a normal 2-of-2 multisig wallet. He highlights that with a wallet vault, only one key is needed to spend funds, but an attacker would need to steal two or more keys. This provides better redundancy and security. Billy also shares a link to a wallet vault design that utilizes OP_CD and discusses his vision for creating highly secure wallets.The discussion then shifts to implementing a mechanism to limit the maximum amount that can be sent from an address. Billy suggests designing a system where coins are combined in a single output and encumbered with a script that allows a limited amount to be sent while requiring the remaining bitcoins to be returned to the sender. He emphasizes the effectiveness of such a system in preventing theft. Zac further elaborates on how this mechanism might work in a typical use case scenario and proposes rate-limiting parameters that could be implemented.Next, the optimization of Bitcoin transactions is discussed. Jeremy suggests splitting up the fee limiting functionality from OP_CD into a separate opcode called OP_LIMITFEECONTRIBUTION. Billy acknowledges the considerations involved in this approach, including evaluating input addresses without knowing their contribution amounts. He also suggests allowing the omission of an output value in cases where the entire output amount is contributed by that input to reduce transaction size.The conversations highlight the benefits, limitations, and considerations related to optimizing Bitcoin transactions, implementing mechanisms to limit the maximum amount sent from an address, and creating secure wallet vaults using covenant opcodes like OP_CD. They also discuss the potential impact on transaction size, security, and user experience.Another topic of discussion is the manipulation of fee rates in Bitcoin transactions by miners. It is estimated that filling 15% of each block with self-pay transactions could raise median fees by approximately 5%. However, this type of attack may not be profitable for dishonest miners due to the large number of transactions needed. The proposed use case for wallet vaults is also discussed, aiming to limit the amount that can be stolen through fees by attackers. Concerns are raised about miners abusing the fee limit mechanism in multi-party scenarios.In an email exchange, Billy suggests calculating the median fee rate for each block and taking the average of those stored per-block median numbers. However, Dave disagrees and believes that miners may have the opportunity to raise the fee rate in certain situations. It is emphasized that every miner is also a user of Bitcoin, and every Bitcoin user may eventually become a miner. Dave provides an example where an attacker could work with a cartel of miners to raise the median fee rate and take all of someone's coins in fees.The proposal being discussed involves constraining the amount of fee that an output can contribute. MedianFeeRate and maxFeeContribution are defined as mechanisms to calculate and limit fees. Storing the feerate for every transaction in a 3,000 block window is considered impractical, so it is suggested to find the median fee-rate for each block instead. Concerns are expressed regarding the effect of this proposal on miner incentives and the redundancy of the fee mechanism.Finally, the OP_CONSTRAINDESTINATION opcode is proposed as a solution to restrict the destination address that an output's coins can be directed to. This opcode allows for step-wise covenant scripts and aims to create more flexible wallet vaults compared to OP_CHECKTEMPLATEVERIFY. The proposal can be found on Github, and feedback is welcomed to improve its presentation or identify any issues. 2021-11-01T01:19:42+00:00 + The conversation begins with Billy explaining the benefits of a 2-key wallet vault using OP_CD over a normal 2-of-2 multisig wallet. He highlights that with a wallet vault, only one key is needed to spend funds, but an attacker would need to steal two or more keys. This provides better redundancy and security. Billy also shares a link to a wallet vault design that utilizes OP_CD and discusses his vision for creating highly secure wallets.The discussion then shifts to implementing a mechanism to limit the maximum amount that can be sent from an address. Billy suggests designing a system where coins are combined in a single output and encumbered with a script that allows a limited amount to be sent while requiring the remaining bitcoins to be returned to the sender. He emphasizes the effectiveness of such a system in preventing theft. Zac further elaborates on how this mechanism might work in a typical use case scenario and proposes rate-limiting parameters that could be implemented.Next, the optimization of Bitcoin transactions is discussed. Jeremy suggests splitting up the fee limiting functionality from OP_CD into a separate opcode called OP_LIMITFEECONTRIBUTION. Billy acknowledges the considerations involved in this approach, including evaluating input addresses without knowing their contribution amounts. He also suggests allowing the omission of an output value in cases where the entire output amount is contributed by that input to reduce transaction size.The conversations highlight the benefits, limitations, and considerations related to optimizing Bitcoin transactions, implementing mechanisms to limit the maximum amount sent from an address, and creating secure wallet vaults using covenant opcodes like OP_CD. They also discuss the potential impact on transaction size, security, and user experience.Another topic of discussion is the manipulation of fee rates in Bitcoin transactions by miners. It is estimated that filling 15% of each block with self-pay transactions could raise median fees by approximately 5%. However, this type of attack may not be profitable for dishonest miners due to the large number of transactions needed. The proposed use case for wallet vaults is also discussed, aiming to limit the amount that can be stolen through fees by attackers. Concerns are raised about miners abusing the fee limit mechanism in multi-party scenarios.In an email exchange, Billy suggests calculating the median fee rate for each block and taking the average of those stored per-block median numbers. However, Dave disagrees and believes that miners may have the opportunity to raise the fee rate in certain situations. It is emphasized that every miner is also a user of Bitcoin, and every Bitcoin user may eventually become a miner. Dave provides an example where an attacker could work with a cartel of miners to raise the median fee rate and take all of someone's coins in fees.The proposal being discussed involves constraining the amount of fee that an output can contribute. MedianFeeRate and maxFeeContribution are defined as mechanisms to calculate and limit fees. Storing the feerate for every transaction in a 3,000 block window is considered impractical, so it is suggested to find the median fee-rate for each block instead. Concerns are expressed regarding the effect of this proposal on miner incentives and the redundancy of the fee mechanism.Finally, the OP_CONSTRAINDESTINATION opcode is proposed as a solution to restrict the destination address that an output's coins can be directed to. This opcode allows for step-wise covenant scripts and aims to create more flexible wallet vaults compared to OP_CHECKTEMPLATEVERIFY. The proposal can be found on Github, and feedback is welcomed to improve its presentation or identify any issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Derivation-Paths-for-Single-Key-Taproot-Scripts.xml b/static/bitcoin-dev/July_2021/combined_Derivation-Paths-for-Single-Key-Taproot-Scripts.xml index 6c40bc347e..bdaf61d660 100644 --- a/static/bitcoin-dev/July_2021/combined_Derivation-Paths-for-Single-Key-Taproot-Scripts.xml +++ b/static/bitcoin-dev/July_2021/combined_Derivation-Paths-for-Single-Key-Taproot-Scripts.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Derivation Paths for Single Key Taproot Scripts - 2023-08-02T04:13:39.214209+00:00 - - Andrew Chow 2021-07-02 20:03:20+00:00 - - - Pavol Rusnak 2021-06-30 11:07:43+00:00 - - - Craig Raw 2021-06-23 08:22:48+00:00 - - - Andrew Chow 2021-06-23 01:17:01+00:00 - + 2025-09-26T15:42:23.235725+00:00 + python-feedgen + + + [bitcoin-dev] Derivation Paths for Single Key Taproot Scripts Andrew Chow + 2021-06-23T01:17:00.000Z + + + Craig Raw + 2021-06-23T08:22:00.000Z + + + Pavol Rusnak + 2021-06-30T11:07:00.000Z + + + Andrew Chow + 2021-07-02T20:03:00.000Z + + - python-feedgen + 2 Combined summary - Derivation Paths for Single Key Taproot Scripts - 2023-08-02T04:13:39.214209+00:00 + 2025-09-26T15:42:23.236266+00:00 - Andrew Chow has proposed a derivation path scheme for keys used in Taproot scripts, which is based on BIP 44 and will have the purpose level path m/86'. The derived keys should be for the Taproot internal key and then tweaked with the hash of itself as recommended by BIP 341. These keys should not be used directly as the Taproot output pubkey, and no new version bytes for extended key serialization are specified in this BIP since descriptors eliminate the need for it. Although Andrew feels that this BIP is somewhat unnecessary, it seems like it will be needed to drive adoption and implementation of Taproot into software and hardware wallets.The proposed derivation scheme aims to provide HD wallets with a common scheme to recover single key Taproot outputs. It consists of two steps to derive multiple deterministic addresses based on a BIP 32 master private key. The first step uses the same account-structure as defined in BIPs 44, 49, and 84 but with a different purpose value for the script type. The second step derives the output key used in the P2TR script from the derived public key using the method recommended in BIP 341.This BIP is not backwards compatible by design. An incompatible wallet will not discover these accounts at all, and the user will notice that something is wrong. However, since the proposed method is similar to the one used in BIPs 44, 49, and 84, it should not be difficult to implement.The document includes references to BIPs 32, 43, 44, 49, 84, and 341. The BIP is licensed under the 2-clause BSD license, and the text can be viewed on GitHub.In addition, Pavol Rusnak, the co-founder and CTO of SatoshiLabs, has proposed a new Bitcoin Improvement Proposal (BIP) that follows the pattern of his previous successful proposals, BIP43, BIP44, and BIP84. The details of the proposal have not been disclosed yet.Overall, the proposed derivation scheme for keys used in Taproot scripts aims to provide HD wallets with a common scheme to recover single key Taproot outputs. It is based on BIP 44 and is identical to BIPs 49 and 84. The purpose level path will be set to the BIP number once assigned. The derived keys should be tweaked with the hash of itself as recommended by BIP 341 and should not be used directly as the Taproot output pubkey. This BIP does not specify new version bytes for extended key serialization due to the availability of descriptors. The proposed scheme will make it easier for HD wallets to recover single key Taproot outputs and drive adoption of Taproot into software and hardware wallets. 2021-07-02T20:03:20+00:00 + Andrew Chow has proposed a derivation path scheme for keys used in Taproot scripts, which is based on BIP 44 and will have the purpose level path m/86'. The derived keys should be for the Taproot internal key and then tweaked with the hash of itself as recommended by BIP 341. These keys should not be used directly as the Taproot output pubkey, and no new version bytes for extended key serialization are specified in this BIP since descriptors eliminate the need for it. Although Andrew feels that this BIP is somewhat unnecessary, it seems like it will be needed to drive adoption and implementation of Taproot into software and hardware wallets.The proposed derivation scheme aims to provide HD wallets with a common scheme to recover single key Taproot outputs. It consists of two steps to derive multiple deterministic addresses based on a BIP 32 master private key. The first step uses the same account-structure as defined in BIPs 44, 49, and 84 but with a different purpose value for the script type. The second step derives the output key used in the P2TR script from the derived public key using the method recommended in BIP 341.This BIP is not backwards compatible by design. An incompatible wallet will not discover these accounts at all, and the user will notice that something is wrong. However, since the proposed method is similar to the one used in BIPs 44, 49, and 84, it should not be difficult to implement.The document includes references to BIPs 32, 43, 44, 49, 84, and 341. The BIP is licensed under the 2-clause BSD license, and the text can be viewed on GitHub.In addition, Pavol Rusnak, the co-founder and CTO of SatoshiLabs, has proposed a new Bitcoin Improvement Proposal (BIP) that follows the pattern of his previous successful proposals, BIP43, BIP44, and BIP84. The details of the proposal have not been disclosed yet.Overall, the proposed derivation scheme for keys used in Taproot scripts aims to provide HD wallets with a common scheme to recover single key Taproot outputs. It is based on BIP 44 and is identical to BIPs 49 and 84. The purpose level path will be set to the BIP number once assigned. The derived keys should be tweaked with the hash of itself as recommended by BIP 341 and should not be used directly as the Taproot output pubkey. This BIP does not specify new version bytes for extended key serialization due to the availability of descriptors. The proposed scheme will make it easier for HD wallets to recover single key Taproot outputs and drive adoption of Taproot into software and hardware wallets. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Eltoo-Anyprevout-Baked-in-Sequences.xml b/static/bitcoin-dev/July_2021/combined_Eltoo-Anyprevout-Baked-in-Sequences.xml index e081c2a39f..444d9ff578 100644 --- a/static/bitcoin-dev/July_2021/combined_Eltoo-Anyprevout-Baked-in-Sequences.xml +++ b/static/bitcoin-dev/July_2021/combined_Eltoo-Anyprevout-Baked-in-Sequences.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Eltoo / Anyprevout & Baked in Sequences - 2023-08-02T04:22:56.125373+00:00 - - Anthony Towns 2021-07-14 03:32:00+00:00 - - - Jeremy 2021-07-12 22:07:29+00:00 - - - Anthony Towns 2021-07-12 05:01:15+00:00 - - - Jeremy 2021-07-08 15:48:14+00:00 - - - Anthony Towns 2021-07-08 08:44:16+00:00 - - - Jeremy 2021-07-08 01:00:20+00:00 - + 2025-09-26T15:42:52.803801+00:00 + python-feedgen + + + [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences Jeremy + 2021-07-08T01:00:00.000Z + + + Anthony Towns + 2021-07-08T08:44:00.000Z + + + Jeremy + 2021-07-08T15:48:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2021-07-12T05:01:00.000Z + + + Jeremy + 2021-07-12T22:07:00.000Z + + + Anthony Towns + 2021-07-14T03:32:00.000Z + + - python-feedgen + 2 Combined summary - Eltoo / Anyprevout & Baked in Sequences - 2023-08-02T04:22:56.125373+00:00 + 2025-09-26T15:42:52.804683+00:00 - In a recent email exchange, Jeremy suggested that evaluating a script should only return one piece of information: "bool tx_is_invalid_script_failed." He argued that all other information, such as transaction fees, finality, and chain fork validity, should be obvious from parsing the transaction. However, he admitted that Bitcoin currently doesn't have this property. Jeremy provided an example of a transaction that will never be valid because it fails a specific rule from BIP 112. He also mentioned that transactions with timelocks can transition from invalid to valid once they pass a certain block height, but once they become invalid, they cannot become valid again for a given UTXO.The email exchange between Anthony Towns and Jeremy discussed the use of relative locktime and absolute locktime for the same input. Jeremy suggested disallowing this, but Anthony pointed out that overloading nSequence for per-input absolute locktime would prevent reusing it for per-input relative locktime. However, Anthony later mentioned a use case for this scenario in cut-through of PTLC refunds. The conversation then shifted to sequencing restrictions and evaluating scripts. Anthony proposed that sequencing restrictions should be evident from a combination of nlocktime, nsequence, and annex, without needing to evaluate scripts or signatures to determine transaction finality. He suggested that evaluating a script should only return one bit of information, while other information like fee calculations and chain fork validity should be apparent from simple parsing of the transaction. Jeremy raised concerns about not having this property currently, but acknowledged its usefulness. They also briefly discussed sequence tagged keys, which have the property of a transaction being either valid or invalid without external information.In another email exchange, Jeremy suggested disallowing the use of both relative locktime and absolute locktime for the same input. However, AJ disagreed, considering ruling it out completely suboptimal. AJ explained that if nSequence is overloaded for per-input absolute locktime, it cannot be reused for per-input relative locktime. AJ also mentioned a use case for this scenario in cut-through of PTLC refunds when the timeout expires after the channel settlement delay. Jeremy asked about sequence tagged keys, and AJ responded that sequencing restrictions should be evident from a combination of nlocktime, nsequence, and annex. AJ proposed that evaluating a script should only return one bit of information, while other information should already be obvious from simple parsing of the transaction.The discussion seems to focus on disallowing the use of both relative locktime and absolute locktime for the same input. However, it is considered suboptimal to completely rule it out. The conversation also touches on sequence tagged keys and seeks opinions on them.In a recent Bitcoin-dev discussion, it was noted that overloading the CLTV clause makes it impossible to use Eltoo and an absolute lock time. It is also not possible to spend two inputs simultaneously if one requires a locktime specified by mediantime and the other by block height. A potential solution suggested was defining a new CSV type, but this would disallow using both relative locktime and absolute locktime for the same input. Instead, adding a per-input absolute locktime to the annex was proposed, which could also be used to add a commitment to a historical block hash to determine valid branches of chain splits or reorgs. Overall, there seems to be agreement that per-input locktimes would be beneficial and address multiple concerns.In a comment on Github, the author discussed the appropriateness of using anyprevout. They noted limitations and overloading issues when using it for eltoo. The author suggested options, including defining a new CSV type and creating a sequenced signature, to better support the eltoo use case. They also considered defining a new generic place for lock times in the annex. The author favored option 3 as it seemed closest to supporting Eltoo more effectively. 2021-07-14T03:32:00+00:00 + In a recent email exchange, Jeremy suggested that evaluating a script should only return one piece of information: "bool tx_is_invalid_script_failed." He argued that all other information, such as transaction fees, finality, and chain fork validity, should be obvious from parsing the transaction. However, he admitted that Bitcoin currently doesn't have this property. Jeremy provided an example of a transaction that will never be valid because it fails a specific rule from BIP 112. He also mentioned that transactions with timelocks can transition from invalid to valid once they pass a certain block height, but once they become invalid, they cannot become valid again for a given UTXO.The email exchange between Anthony Towns and Jeremy discussed the use of relative locktime and absolute locktime for the same input. Jeremy suggested disallowing this, but Anthony pointed out that overloading nSequence for per-input absolute locktime would prevent reusing it for per-input relative locktime. However, Anthony later mentioned a use case for this scenario in cut-through of PTLC refunds. The conversation then shifted to sequencing restrictions and evaluating scripts. Anthony proposed that sequencing restrictions should be evident from a combination of nlocktime, nsequence, and annex, without needing to evaluate scripts or signatures to determine transaction finality. He suggested that evaluating a script should only return one bit of information, while other information like fee calculations and chain fork validity should be apparent from simple parsing of the transaction. Jeremy raised concerns about not having this property currently, but acknowledged its usefulness. They also briefly discussed sequence tagged keys, which have the property of a transaction being either valid or invalid without external information.In another email exchange, Jeremy suggested disallowing the use of both relative locktime and absolute locktime for the same input. However, AJ disagreed, considering ruling it out completely suboptimal. AJ explained that if nSequence is overloaded for per-input absolute locktime, it cannot be reused for per-input relative locktime. AJ also mentioned a use case for this scenario in cut-through of PTLC refunds when the timeout expires after the channel settlement delay. Jeremy asked about sequence tagged keys, and AJ responded that sequencing restrictions should be evident from a combination of nlocktime, nsequence, and annex. AJ proposed that evaluating a script should only return one bit of information, while other information should already be obvious from simple parsing of the transaction.The discussion seems to focus on disallowing the use of both relative locktime and absolute locktime for the same input. However, it is considered suboptimal to completely rule it out. The conversation also touches on sequence tagged keys and seeks opinions on them.In a recent Bitcoin-dev discussion, it was noted that overloading the CLTV clause makes it impossible to use Eltoo and an absolute lock time. It is also not possible to spend two inputs simultaneously if one requires a locktime specified by mediantime and the other by block height. A potential solution suggested was defining a new CSV type, but this would disallow using both relative locktime and absolute locktime for the same input. Instead, adding a per-input absolute locktime to the annex was proposed, which could also be used to add a commitment to a historical block hash to determine valid branches of chain splits or reorgs. Overall, there seems to be agreement that per-input locktimes would be beneficial and address multiple concerns.In a comment on Github, the author discussed the appropriateness of using anyprevout. They noted limitations and overloading issues when using it for eltoo. The author suggested options, including defining a new CSV type and creating a sequenced signature, to better support the eltoo use case. They also considered defining a new generic place for lock times in the annex. The author favored option 3 as it seemed closest to supporting Eltoo more effectively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml b/static/bitcoin-dev/July_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml index bcab1dff83..0bc19be8b6 100644 --- a/static/bitcoin-dev/July_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml +++ b/static/bitcoin-dev/July_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml @@ -1,65 +1,39 @@ - + 2 Combined summary - Exploring: limiting transaction output amount as a function of total input value - 2023-08-02T04:27:02.335436+00:00 - - Zac Greenwood 2021-09-01 15:15:30+00:00 - - - ZmnSCPxj 2021-08-31 14:22:29+00:00 - - - Zac Greenwood 2021-08-31 14:09:04+00:00 - - - ZmnSCPxj 2021-08-31 09:00:15+00:00 - - - Zac Greenwood 2021-08-30 14:43:30+00:00 - - - ZmnSCPxj 2021-08-16 11:48:43+00:00 - - - Zac Greenwood 2021-08-16 11:17:19+00:00 - - - ZmnSCPxj 2021-08-14 01:50:45+00:00 - - - Zac Greenwood 2021-08-13 11:02:14+00:00 - - - ZmnSCPxj 2021-08-10 02:17:47+00:00 - - - Billy Tetrud 2021-08-10 00:41:12+00:00 - - - Zac Greenwood 2021-08-05 14:22:12+00:00 - - - Billy Tetrud 2021-08-05 06:39:34+00:00 - - - Zac Greenwood 2021-08-04 10:48:44+00:00 - - - Billy Tetrud 2021-08-03 18:12:28+00:00 - - - Zac Greenwood 2021-08-02 09:32:36+00:00 - - - Billy Tetrud 2021-08-02 04:40:47+00:00 - - - Zac Greenwood 2021-08-01 08:09:26+00:00 - - - Zac Greenwood 2021-07-31 20:01:49+00:00 - + 2025-09-26T15:42:42.319866+00:00 + python-feedgen + + + [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood + 2021-08-01T08:09:00.000Z + + + Zac Greenwood + 2021-08-02T09:32:00.000Z + + + Billy Tetrud + 2021-08-03T18:12:00.000Z + + + Zac Greenwood + 2021-08-04T10:48:00.000Z + + + Billy Tetrud + 2021-08-05T06:39:00.000Z + + + Zac Greenwood + 2021-08-05T14:22:00.000Z + + + Billy Tetrud + 2021-08-10T00:41:00.000Z + + @@ -79,13 +53,13 @@ - python-feedgen + 2 Combined summary - Exploring: limiting transaction output amount as a function of total input value - 2023-08-02T04:27:02.335436+00:00 + 2025-09-26T15:42:42.320815+00:00 - The email thread discusses the implementation of a rate-limiting algorithm in a privacy-preserving manner. The proposed algorithm involves creating an output at a specific block height [h0] that serves as input and limits the maximum amount that can be sent. This rule is permanent and always copied over to a change output. At another block height [h1], a transaction occurs, spending a certain amount [h1_spent]. The payment output created at [h1] is not restricted, while the change output must be encumbered with a second transaction occurring at another block height [h2], spending a certain amount [h2_spent]. However, implementing this algorithm in a privacy-preserving way poses challenges, as it reduces the anonymity set for everyone and makes the payment and change outputs identifiable on-chain. The author suggests using clever MAST-fu in covenant schemes to address these challenges. Several proposals for such covenant schemes exist, but none have gained significant traction.In their email exchange, Zac and ZmnSCPxj discuss the potential reduction of privacy in a proposal due to the introduction of a new type of transaction. This would decrease the anonymity set for everyone and result in identifiable payment and change outputs. Zac proposes using clever MAST-fu to resolve these issues but lacks the technical skills to determine if it's possible. ZmnSCPxj directs Zac towards covenant efforts with MAST-integration developed by aj and RubenSomsen. While various proposals exist, ZmnSCPxj cannot pinpoint one that seems likely to gain significant traction.Zac expresses concerns about the privacy implications of a proposed algorithm that requires a new type of transaction and encumbered change outputs. ZmnSCPxj explains that this proposal would reduce privacy by decreasing the anonymity set for everyone, making payment and change outputs identifiable, and requiring visible on-chain specifics regarding how the output is encumbered. Zac believes that the functionality should not justify the privacy reductions unless these concerns can be addressed. ZmnSCPxj provides further details about the challenges involved in implementing the proposal, including explicit flagging and data storage requirements for each output. These challenges make implementation without consensus code changes difficult, but dropping the "change outputs must also be rate-limited" requirement could improve privacy and ease implementation.ZmnSCPxj's email discusses the potential costs and benefits of implementing a proposal. One issue is the need for explicit visibility to implement the "change outputs must also be rate-limited" requirement. Two options, allocating new SegWit versions or using anyone-can-spend `scriptPubKey` templates, have drawbacks related to privacy concerns. Another challenge is storing data with each output, which increases the size of stored outputs. Ideally, outputs should only contain commitments rather than actual data. However, explicit tagging is necessary to ensure rate-limiting of change outputs, which adds to the amount of data required. The residual limit also needs to be kept with the output. Dropping the "change outputs must also be rate-limited" requirement would address some gaps in the proposal but reduce privacy. Overall, the email highlights various challenges and considerations for implementing this proposal.Zac and ZmnSCPxj discuss the functionality of limiting the amount spent from an address within a certain timeframe. Zac proposes implementing consensus changes to support this functionality, while ZmnSCPxj suggests using covenant opcodes instead. However, there are multiple proposals with overlapping abilities and tradeoffs, potentially leading to disagreements. Zac requests more information on what is needed to implement his unmodified proposal so that the community can assess the cost versus the benefits. He acknowledges that consensus changes take years but believes it is essential to explore the appetite for the proposed functionality and possible technical solutions.Zac and ZmnSCPxj agree on the importance of determining whether the proposed functionality can be implemented without consensus changes. ZmnSCPxj presents a technical counterproposal that explores an implementation on top of the existing Bitcoin system. They discuss the differences between the proposals, highlighting significant gaps. Zac believes that the counterproposal does not meet the basic requirements of the original proposal and prefers implementing consensus changes to support the functionality. They suggest looking into covenant opcodes as an alternative to the counterproposal, as they closely align with one of the motivating examples for covenants. The conversation emphasizes the need to address the gaps between the proposals.In their conversation, Zac proposes functionality that allows control of a coin using two private keys, with spending limited over time for one key and unrestricted for the other. ZmnSCPxj presents a counterproposal using `nSequence` in relative-locktime mode but acknowledges its disadvantages, including obviousness and limits on the number of windows. Zac argues that implementing consensus changes to support the proposed functionality would be preferable over the counterproposal. However, ZmnSCPxj contends that the functionality can be implemented using `nSequence`-in-relative-locktime-mode without any consensus changes. They agree that the functionality is 2021-09-01T15:15:30+00:00 + The email thread discusses the implementation of a rate-limiting algorithm in a privacy-preserving manner. The proposed algorithm involves creating an output at a specific block height [h0] that serves as input and limits the maximum amount that can be sent. This rule is permanent and always copied over to a change output. At another block height [h1], a transaction occurs, spending a certain amount [h1_spent]. The payment output created at [h1] is not restricted, while the change output must be encumbered with a second transaction occurring at another block height [h2], spending a certain amount [h2_spent]. However, implementing this algorithm in a privacy-preserving way poses challenges, as it reduces the anonymity set for everyone and makes the payment and change outputs identifiable on-chain. The author suggests using clever MAST-fu in covenant schemes to address these challenges. Several proposals for such covenant schemes exist, but none have gained significant traction.In their email exchange, Zac and ZmnSCPxj discuss the potential reduction of privacy in a proposal due to the introduction of a new type of transaction. This would decrease the anonymity set for everyone and result in identifiable payment and change outputs. Zac proposes using clever MAST-fu to resolve these issues but lacks the technical skills to determine if it's possible. ZmnSCPxj directs Zac towards covenant efforts with MAST-integration developed by aj and RubenSomsen. While various proposals exist, ZmnSCPxj cannot pinpoint one that seems likely to gain significant traction.Zac expresses concerns about the privacy implications of a proposed algorithm that requires a new type of transaction and encumbered change outputs. ZmnSCPxj explains that this proposal would reduce privacy by decreasing the anonymity set for everyone, making payment and change outputs identifiable, and requiring visible on-chain specifics regarding how the output is encumbered. Zac believes that the functionality should not justify the privacy reductions unless these concerns can be addressed. ZmnSCPxj provides further details about the challenges involved in implementing the proposal, including explicit flagging and data storage requirements for each output. These challenges make implementation without consensus code changes difficult, but dropping the "change outputs must also be rate-limited" requirement could improve privacy and ease implementation.ZmnSCPxj's email discusses the potential costs and benefits of implementing a proposal. One issue is the need for explicit visibility to implement the "change outputs must also be rate-limited" requirement. Two options, allocating new SegWit versions or using anyone-can-spend `scriptPubKey` templates, have drawbacks related to privacy concerns. Another challenge is storing data with each output, which increases the size of stored outputs. Ideally, outputs should only contain commitments rather than actual data. However, explicit tagging is necessary to ensure rate-limiting of change outputs, which adds to the amount of data required. The residual limit also needs to be kept with the output. Dropping the "change outputs must also be rate-limited" requirement would address some gaps in the proposal but reduce privacy. Overall, the email highlights various challenges and considerations for implementing this proposal.Zac and ZmnSCPxj discuss the functionality of limiting the amount spent from an address within a certain timeframe. Zac proposes implementing consensus changes to support this functionality, while ZmnSCPxj suggests using covenant opcodes instead. However, there are multiple proposals with overlapping abilities and tradeoffs, potentially leading to disagreements. Zac requests more information on what is needed to implement his unmodified proposal so that the community can assess the cost versus the benefits. He acknowledges that consensus changes take years but believes it is essential to explore the appetite for the proposed functionality and possible technical solutions.Zac and ZmnSCPxj agree on the importance of determining whether the proposed functionality can be implemented without consensus changes. ZmnSCPxj presents a technical counterproposal that explores an implementation on top of the existing Bitcoin system. They discuss the differences between the proposals, highlighting significant gaps. Zac believes that the counterproposal does not meet the basic requirements of the original proposal and prefers implementing consensus changes to support the functionality. They suggest looking into covenant opcodes as an alternative to the counterproposal, as they closely align with one of the motivating examples for covenants. The conversation emphasizes the need to address the gaps between the proposals.In their conversation, Zac proposes functionality that allows control of a coin using two private keys, with spending limited over time for one key and unrestricted for the other. ZmnSCPxj presents a counterproposal using `nSequence` in relative-locktime mode but acknowledges its disadvantages, including obviousness and limits on the number of windows. Zac argues that implementing consensus changes to support the proposed functionality would be preferable over the counterproposal. However, ZmnSCPxj contends that the functionality can be implemented using `nSequence`-in-relative-locktime-mode without any consensus changes. They agree that the functionality is - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Last-week-s-second-IRC-workshop-on-L2-onchain-support-and-wrap-up.xml b/static/bitcoin-dev/July_2021/combined_Last-week-s-second-IRC-workshop-on-L2-onchain-support-and-wrap-up.xml index 65db18a9cc..66642e85fc 100644 --- a/static/bitcoin-dev/July_2021/combined_Last-week-s-second-IRC-workshop-on-L2-onchain-support-and-wrap-up.xml +++ b/static/bitcoin-dev/July_2021/combined_Last-week-s-second-IRC-workshop-on-L2-onchain-support-and-wrap-up.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Last week's second IRC workshop on L2 onchain support and wrap up - 2023-08-02T04:15:19.233258+00:00 - - Michael Folkson 2021-07-29 11:36:25+00:00 - - - Michael Folkson 2021-06-29 09:44:11+00:00 - + 2025-09-26T15:42:44.408268+00:00 + python-feedgen + + + [bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up Michael Folkson + 2021-06-29T09:44:00.000Z + + + Michael Folkson + 2021-07-29T11:36:00.000Z + + - python-feedgen + 2 Combined summary - Last week's second IRC workshop on L2 onchain support and wrap up - 2023-08-02T04:15:19.233258+00:00 + 2025-09-26T15:42:44.408848+00:00 - The recent online Sydney Socratic Seminar focused on L2 onchain support and discussed various aspects of Bitcoin Improvement Proposal (BIP) 125 RBF. The attendees explored ideas such as SIGHASH_IOMAP, fee sponsorship, and transaction mutation. They also delved into the topics of fee bumping and package relay, with a consensus that enabling two transaction packages would suffice for Lightning and DLCs. The potential benefits of package relay for L2 protocols in addressing future fee unpredictability were highlighted, with previous work by Suhas Daftuar being mentioned.Taproot and witness replacement were also discussed during the seminar. Participants noted that miniscript could assess the transaction pinning risk of a bloated witness. They further suggested that a future soft fork could utilize the annex in Taproot to inflate the fee rate of a witness. In another workshop specifically dedicated to Bitcoin package relay and fee bumping, attendees emphasized the usefulness of package relay for Layer 2 protocols. This approach can help tackle the uncertainty surrounding future fees. Previous works by Suhas Daftuar and Gloria Zhao were acknowledged in this area. The participants agreed that enabling two transaction packages would be adequate for Lightning and DLCs, although concerns were raised about the potential complexity associated with larger package sizes.The workshop also explored the option of utilizing two packages, A and B, or B and C, if supporting three transaction packages proved challenging. Furthermore, attendees suggested communicating only hints, such as fee rate hints, instead of relaying entire transactions. Witness replacement and Taproot were additional topics of discussion. It was proposed that replacing a larger witness with a smaller one could reduce transaction fees. A future soft fork could give significance to the annex in Taproot, allowing for the inflation of a witness's fee rate.To conclude the workshop, the attendees agreed that two transaction packages would adequately support currently deployed L2 protocols. Ongoing discussions are taking place regarding the deprecation of opt-in RBF and the implementation of full RBF. The participants also addressed the need for a status quo and ad hoc security incident response policy in case of cross-layer security issues. Additionally, they advised L2 protocol designers to minimize assumptions on the base layer. 2021-07-29T11:36:25+00:00 + The recent online Sydney Socratic Seminar focused on L2 onchain support and discussed various aspects of Bitcoin Improvement Proposal (BIP) 125 RBF. The attendees explored ideas such as SIGHASH_IOMAP, fee sponsorship, and transaction mutation. They also delved into the topics of fee bumping and package relay, with a consensus that enabling two transaction packages would suffice for Lightning and DLCs. The potential benefits of package relay for L2 protocols in addressing future fee unpredictability were highlighted, with previous work by Suhas Daftuar being mentioned.Taproot and witness replacement were also discussed during the seminar. Participants noted that miniscript could assess the transaction pinning risk of a bloated witness. They further suggested that a future soft fork could utilize the annex in Taproot to inflate the fee rate of a witness. In another workshop specifically dedicated to Bitcoin package relay and fee bumping, attendees emphasized the usefulness of package relay for Layer 2 protocols. This approach can help tackle the uncertainty surrounding future fees. Previous works by Suhas Daftuar and Gloria Zhao were acknowledged in this area. The participants agreed that enabling two transaction packages would be adequate for Lightning and DLCs, although concerns were raised about the potential complexity associated with larger package sizes.The workshop also explored the option of utilizing two packages, A and B, or B and C, if supporting three transaction packages proved challenging. Furthermore, attendees suggested communicating only hints, such as fee rate hints, instead of relaying entire transactions. Witness replacement and Taproot were additional topics of discussion. It was proposed that replacing a larger witness with a smaller one could reduce transaction fees. A future soft fork could give significance to the annex in Taproot, allowing for the inflation of a witness's fee rate.To conclude the workshop, the attendees agreed that two transaction packages would adequately support currently deployed L2 protocols. Ongoing discussions are taking place regarding the deprecation of opt-in RBF and the implementation of full RBF. The participants also addressed the need for a status quo and ad hoc security incident response policy in case of cross-layer security issues. Additionally, they advised L2 protocol designers to minimize assumptions on the base layer. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Multisig-Enhanced-Privacy-Scheme.xml b/static/bitcoin-dev/July_2021/combined_Multisig-Enhanced-Privacy-Scheme.xml index 2560265595..1be6afe61a 100644 --- a/static/bitcoin-dev/July_2021/combined_Multisig-Enhanced-Privacy-Scheme.xml +++ b/static/bitcoin-dev/July_2021/combined_Multisig-Enhanced-Privacy-Scheme.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Multisig Enhanced Privacy Scheme - 2023-08-02T04:23:46.112777+00:00 - - David A. Harding 2021-07-25 04:49:24+00:00 - - - Michael Flaxman 2021-07-20 19:44:19+00:00 - + 2025-09-26T15:42:38.053228+00:00 + python-feedgen + + + [bitcoin-dev] Multisig Enhanced Privacy Scheme Michael Flaxman + 2021-07-20T19:44:00.000Z + + + David A. Harding + 2021-07-25T04:49:00.000Z + + - python-feedgen + 2 Combined summary - Multisig Enhanced Privacy Scheme - 2023-08-02T04:23:46.112777+00:00 + 2025-09-26T15:42:38.053701+00:00 - A member of the Bitcoin development community, Michael Flaxman, has proposed a method for preventing privacy leaks in multisig quorums by using BIP32 paths. The scheme, which can be found on GitHub, aims to address the issue of attackers obtaining a private BIP32 seed along with knowledge of the HD paths being used. It is assumed that most people store their descriptors alongside their seeds for robust recovery.To solve this problem, the use of taproot with multisignatures and threshold signatures is suggested. This approach would prevent privacy leaks as long as participants do not reuse the same keys in different contexts. As a result, wallet authors are encouraged to focus on implementing support for taproot and MuSig or MuSig2 instead of the proposed scheme.The new method offers several benefits. It prevents unauthorized parties from accessing the BIP39 seed phrase and gaining information about transactions in any multisig quorum that seed participates in. Additionally, trusted-minimized third parties can hold an emergency recovery key in a multisig quorum without knowing what that key protects. This scheme has already been active on mainnet for some time and has gained support from various Coordinators and Signers. Currently, large sums of bitcoin are held using this method.The publication of this method aims to encourage more interoperable hardware wallet/coordinator software support, which would enhance privacy and improve user experience. Feedback on the proposed scheme is welcomed as the community continues to work towards these goals. 2021-07-25T04:49:24+00:00 + A member of the Bitcoin development community, Michael Flaxman, has proposed a method for preventing privacy leaks in multisig quorums by using BIP32 paths. The scheme, which can be found on GitHub, aims to address the issue of attackers obtaining a private BIP32 seed along with knowledge of the HD paths being used. It is assumed that most people store their descriptors alongside their seeds for robust recovery.To solve this problem, the use of taproot with multisignatures and threshold signatures is suggested. This approach would prevent privacy leaks as long as participants do not reuse the same keys in different contexts. As a result, wallet authors are encouraged to focus on implementing support for taproot and MuSig or MuSig2 instead of the proposed scheme.The new method offers several benefits. It prevents unauthorized parties from accessing the BIP39 seed phrase and gaining information about transactions in any multisig quorum that seed participates in. Additionally, trusted-minimized third parties can hold an emergency recovery key in a multisig quorum without knowing what that key protects. This scheme has already been active on mainnet for some time and has gained support from various Coordinators and Signers. Currently, large sums of bitcoin are held using this method.The publication of this method aims to encourage more interoperable hardware wallet/coordinator software support, which would enhance privacy and improve user experience. Feedback on the proposed scheme is welcomed as the community continues to work towards these goals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_OP-CAT-Makes-Bitcoin-Quantum-Secure-was-CheckSigFromStack-for-Arithmetic-Values-.xml b/static/bitcoin-dev/July_2021/combined_OP-CAT-Makes-Bitcoin-Quantum-Secure-was-CheckSigFromStack-for-Arithmetic-Values-.xml index c95ac968a1..a200b8a8c0 100644 --- a/static/bitcoin-dev/July_2021/combined_OP-CAT-Makes-Bitcoin-Quantum-Secure-was-CheckSigFromStack-for-Arithmetic-Values-.xml +++ b/static/bitcoin-dev/July_2021/combined_OP-CAT-Makes-Bitcoin-Quantum-Secure-was-CheckSigFromStack-for-Arithmetic-Values-.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values] - 2023-08-02T04:22:34.747297+00:00 - - Ethan Heilman 2021-07-09 23:25:06+00:00 - - - Jeremy 2021-07-09 22:52:56+00:00 - - - ZmnSCPxj 2021-07-09 22:38:18+00:00 - - - Ethan Heilman 2021-07-09 19:02:15+00:00 - - - ZmnSCPxj 2021-07-08 08:12:01+00:00 - - - Jeremy 2021-07-07 05:58:15+00:00 - + 2025-09-26T15:42:29.623912+00:00 + python-feedgen + + + [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values] Jeremy + 2021-07-07T05:58:00.000Z + + + ZmnSCPxj + 2021-07-08T08:12:00.000Z + + + Ethan Heilman + 2021-07-09T19:02:00.000Z + + + ZmnSCPxj + 2021-07-09T22:38:00.000Z + + + Jeremy + 2021-07-09T22:52:00.000Z + + + Ethan Heilman + 2021-07-09T23:25:00.000Z + + - python-feedgen + 2 Combined summary - OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values] - 2023-08-02T04:22:34.747297+00:00 + 2025-09-26T15:42:29.624870+00:00 - The implementation of Winternitz signatures in Bitcoin is not straightforward due to the lack of a limited-repeat construct in SCRIPT. However, it can be emulated using `OP_IF` and brute force, although this would result in a more complex and longer SCRIPT. Winternitz signatures offer smaller signature sizes but require more instructions in SCRIPT. Merkle signatures, on the other hand, trade shorter pubkeys for longer signatures, which is not advantageous in the post-SegWit Bitcoin context where both pubkeys and signatures are stored in the witness area.Jeremy Rubin proposed using OP_CAT or a similar operation to make Bitcoin "quantum safe" by signing an EC signature. This scheme uses Lamport signatures, which are quantum secure but require at least 20 contiguous bytes. To implement Winternitz, a limited-repeat construct is needed, but it is not available in SCRIPT. The commitment scheme in Taproot allows secure opening of the commitment to a message even with a quantum computer. Additionally, Schnorr signatures have a stronger non-malleability property than ECDSA, making them binding to the approved transaction. Once Lamport signed in Schnorr, even a quantum computer cannot steal the funds.Ethan Heilman suggested using Winternitz one-time signatures or OP_CAT to compress Lamport signatures and make Bitcoin "quantum safe". Jeremy Rubin explored using OP_CAT for signing EC signatures in Segwit V0 and Tapscript. Rubin's proposal involves signing a HASH160 digest of the signature, which is resistant to quantum computers even if they crack ECDSA keys. The script required for this approach is long but fits within the program space and stack size limits for Bitcoin scripts. Rubin suggests that expanding to a ternary representation could further reduce the cost.ZmnSCPxj responded to Rubin's proposal, noting that while Lamport signatures are resistant to quantum computing, they are large in size. ZmnSCPxj suggested using Winternitz OTS instead, but it requires a limited-repeat construct not available in SCRIPT. Merkle signatures trade shorter pubkeys for longer signatures, which is a loss compared to Lamport in the post-SegWit Bitcoin context. ZmnSCPxj also pointed out that OP_CAT cannot be directly soft-forked to Segwit V0 because it modifies the stack, requiring a new opcode. Taproot and Schnorr signatures are mentioned as potential options for making Bitcoin quantum-proof.A proposal has been made to use Lamport signatures to sign longer messages in Bitcoin script arithmetic and make it quantum-proof. However, Lamport signatures are too large for the current block size limit. It may be possible to compress them using Winternitz OTS or OP_CAT to build a merkle tree and derive the full signature during script execution from shorter seed values. Rubin's construction uses an OP_CAT-like operation to sign up to 20 bytes, combined with the HASH160 digest, to create a "quantum safe" signature algorithm. The commitment scheme in Taproot can nest this script inside a Tapscript path, adding more security. More analysis is needed to ensure the security against quantum computers before using it in production.Jeremy Rubin proposed using an OP_CAT operation to sign an EC signature and make Bitcoin "quantum safe". The construction uses Lamport signatures, which are quantum secure but require at least 20 contiguous bytes. The commitment scheme can nest inside a Tapscript path, providing additional security. Schnorr signatures are mentioned as having a stronger non-malleability property than ECDSA. The large size of Lamport signatures raises questions about their implementation.In his blog post, Jeremy Rubin explains how OP_CAT or a similar operation can be used to make Bitcoin "quantum safe" by signing an EC signature. This approach works in both Segwit V0 and Tapscript. By signing the HASH160 digest of the signature, even if a quantum computer cracks ECDSA, it cannot malleate the content of what was signed. Lamport signatures are mentioned as a 5-byte signing scheme that is quantum secure but requires at least 20 contiguous bytes. Rubin suggests using a new opcode, OP_SUBSTRINGEQUALVERIFY, to check a splice of a string for equality. The script fits within the limits, and expanding to a ternary representation could make it more efficient. The commitment scheme in Taproot can be securely opened to a message even with a quantum computer. Additionally, Schnorr signatures have a stronger non-malleability property than ECDSA, making them binding to the approved transaction. Many Lamport keys can be committed inside a taproot tree to make keys reusable.In summary, there have been proposals to use Winternitz signatures, OP_CAT, and other methods to make Bitcoin quantum-proof. These approaches aim to enhance security against quantum computers by using quantum-secure signatures and alternative operations. However, there are challenges such as limited-repeat constructs, size limitations, and the need for further analysis. Taproot and Schnorr signatures are also mentioned as potential 2021-07-09T23:25:06+00:00 + The implementation of Winternitz signatures in Bitcoin is not straightforward due to the lack of a limited-repeat construct in SCRIPT. However, it can be emulated using `OP_IF` and brute force, although this would result in a more complex and longer SCRIPT. Winternitz signatures offer smaller signature sizes but require more instructions in SCRIPT. Merkle signatures, on the other hand, trade shorter pubkeys for longer signatures, which is not advantageous in the post-SegWit Bitcoin context where both pubkeys and signatures are stored in the witness area.Jeremy Rubin proposed using OP_CAT or a similar operation to make Bitcoin "quantum safe" by signing an EC signature. This scheme uses Lamport signatures, which are quantum secure but require at least 20 contiguous bytes. To implement Winternitz, a limited-repeat construct is needed, but it is not available in SCRIPT. The commitment scheme in Taproot allows secure opening of the commitment to a message even with a quantum computer. Additionally, Schnorr signatures have a stronger non-malleability property than ECDSA, making them binding to the approved transaction. Once Lamport signed in Schnorr, even a quantum computer cannot steal the funds.Ethan Heilman suggested using Winternitz one-time signatures or OP_CAT to compress Lamport signatures and make Bitcoin "quantum safe". Jeremy Rubin explored using OP_CAT for signing EC signatures in Segwit V0 and Tapscript. Rubin's proposal involves signing a HASH160 digest of the signature, which is resistant to quantum computers even if they crack ECDSA keys. The script required for this approach is long but fits within the program space and stack size limits for Bitcoin scripts. Rubin suggests that expanding to a ternary representation could further reduce the cost.ZmnSCPxj responded to Rubin's proposal, noting that while Lamport signatures are resistant to quantum computing, they are large in size. ZmnSCPxj suggested using Winternitz OTS instead, but it requires a limited-repeat construct not available in SCRIPT. Merkle signatures trade shorter pubkeys for longer signatures, which is a loss compared to Lamport in the post-SegWit Bitcoin context. ZmnSCPxj also pointed out that OP_CAT cannot be directly soft-forked to Segwit V0 because it modifies the stack, requiring a new opcode. Taproot and Schnorr signatures are mentioned as potential options for making Bitcoin quantum-proof.A proposal has been made to use Lamport signatures to sign longer messages in Bitcoin script arithmetic and make it quantum-proof. However, Lamport signatures are too large for the current block size limit. It may be possible to compress them using Winternitz OTS or OP_CAT to build a merkle tree and derive the full signature during script execution from shorter seed values. Rubin's construction uses an OP_CAT-like operation to sign up to 20 bytes, combined with the HASH160 digest, to create a "quantum safe" signature algorithm. The commitment scheme in Taproot can nest this script inside a Tapscript path, adding more security. More analysis is needed to ensure the security against quantum computers before using it in production.Jeremy Rubin proposed using an OP_CAT operation to sign an EC signature and make Bitcoin "quantum safe". The construction uses Lamport signatures, which are quantum secure but require at least 20 contiguous bytes. The commitment scheme can nest inside a Tapscript path, providing additional security. Schnorr signatures are mentioned as having a stronger non-malleability property than ECDSA. The large size of Lamport signatures raises questions about their implementation.In his blog post, Jeremy Rubin explains how OP_CAT or a similar operation can be used to make Bitcoin "quantum safe" by signing an EC signature. This approach works in both Segwit V0 and Tapscript. By signing the HASH160 digest of the signature, even if a quantum computer cracks ECDSA, it cannot malleate the content of what was signed. Lamport signatures are mentioned as a 5-byte signing scheme that is quantum secure but requires at least 20 contiguous bytes. Rubin suggests using a new opcode, OP_SUBSTRINGEQUALVERIFY, to check a splice of a string for equality. The script fits within the limits, and expanding to a ternary representation could make it more efficient. The commitment scheme in Taproot can be securely opened to a message even with a quantum computer. Additionally, Schnorr signatures have a stronger non-malleability property than ECDSA, making them binding to the approved transaction. Many Lamport keys can be committed inside a taproot tree to make keys reusable.In summary, there have been proposals to use Winternitz signatures, OP_CAT, and other methods to make Bitcoin quantum-proof. These approaches aim to enhance security against quantum computers by using quantum-secure signatures and alternative operations. However, there are challenges such as limited-repeat constructs, size limitations, and the need for further analysis. Taproot and Schnorr signatures are also mentioned as potential - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Online-discussion-on-Taproot-roll-out-Tuesday-July-20th-17-15-UTC.xml b/static/bitcoin-dev/July_2021/combined_Online-discussion-on-Taproot-roll-out-Tuesday-July-20th-17-15-UTC.xml index ab89d77de9..fa7f62f34a 100644 --- a/static/bitcoin-dev/July_2021/combined_Online-discussion-on-Taproot-roll-out-Tuesday-July-20th-17-15-UTC.xml +++ b/static/bitcoin-dev/July_2021/combined_Online-discussion-on-Taproot-roll-out-Tuesday-July-20th-17-15-UTC.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC - 2023-08-02T04:23:27.411386+00:00 - - Michael Folkson 2021-08-03 09:59:25+00:00 - - - Michael Folkson 2021-07-17 13:16:19+00:00 - + 2025-09-26T15:42:54.892610+00:00 + python-feedgen + + + [bitcoin-dev] Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC Michael Folkson + 2021-07-17T13:16:00.000Z + + + Michael Folkson + 2021-08-03T09:59:00.000Z + + - python-feedgen + 2 Combined summary - Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC - 2023-08-02T04:23:27.411386+00:00 + 2025-09-26T15:42:54.893064+00:00 - On July 20th, there was an online Zoom call held to discuss the Taproot roll out post activation in November. The focus of the discussion was on developers and the event was livestreamed on YouTube, allowing anyone to attend or watch. Murch, a participant in the call, has created a wiki page that tracks planned ecosystem support of P2TR addresses. The organizers of the event encouraged projects and businesses with Taproot support on their development roadmaps to contribute to the discussion. The meetup link, where the Zoom link was announced, was shared for participants to access. Prior to the call, draft pre-reading links were provided, which were expected to be finalized before Tuesday. These links can be found on https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254.In summary, the online discussion on Taproot roll out took place on July 20th. It was primarily focused on developers but open to everyone. Murch's wiki page monitoring planned ecosystem support of P2TR addresses was highlighted, and participants were encouraged to share their Taproot support plans. The meetup link and draft pre-reading links were also shared for participants' convenience. 2021-08-03T09:59:25+00:00 + On July 20th, there was an online Zoom call held to discuss the Taproot roll out post activation in November. The focus of the discussion was on developers and the event was livestreamed on YouTube, allowing anyone to attend or watch. Murch, a participant in the call, has created a wiki page that tracks planned ecosystem support of P2TR addresses. The organizers of the event encouraged projects and businesses with Taproot support on their development roadmaps to contribute to the discussion. The meetup link, where the Zoom link was announced, was shared for participants to access. Prior to the call, draft pre-reading links were provided, which were expected to be finalized before Tuesday. These links can be found on https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254.In summary, the online discussion on Taproot roll out took place on July 20th. It was primarily focused on developers but open to everyone. Murch's wiki page monitoring planned ecosystem support of P2TR addresses was highlighted, and participants were encouraged to share their Taproot support plans. The meetup link and draft pre-reading links were also shared for participants' convenience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Proof-of-reserves-recording.xml b/static/bitcoin-dev/July_2021/combined_Proof-of-reserves-recording.xml index 1fdeef21ee..234870b005 100644 --- a/static/bitcoin-dev/July_2021/combined_Proof-of-reserves-recording.xml +++ b/static/bitcoin-dev/July_2021/combined_Proof-of-reserves-recording.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Proof of reserves - recording - 2023-08-02T04:22:07.715686+00:00 - - eric at voskuil.org 2021-07-10 01:49:37+00:00 - - - ZmnSCPxj 2021-07-10 01:26:14+00:00 - - - eric at voskuil.org 2021-07-10 00:49:52+00:00 - - - ZmnSCPxj 2021-07-09 23:50:45+00:00 - - - Eric Voskuil 2021-07-09 23:18:26+00:00 - - - Billy Tetrud 2021-07-09 22:02:23+00:00 - - - Eric Voskuil 2021-07-09 18:32:12+00:00 - - - Billy Tetrud 2021-07-09 17:43:47+00:00 - - - Eric Voskuil 2021-07-09 14:55:14+00:00 - - - Billy Tetrud 2021-07-07 06:18:58+00:00 - - - eric at voskuil.org 2021-07-06 18:40:35+00:00 - - - Erik Aronesty 2021-07-06 16:39:36+00:00 - - - Eric Voskuil 2021-07-06 07:37:07+00:00 - - - Billy Tetrud 2021-07-06 06:02:45+00:00 - - - Eric Voskuil 2021-07-06 05:09:59+00:00 - - - ZmnSCPxj 2021-07-06 04:54:11+00:00 - - - Billy Tetrud 2021-07-06 01:34:53+00:00 - - - ZmnSCPxj 2021-07-06 00:09:25+00:00 - - - Eric Voskuil 2021-07-05 23:32:04+00:00 - - - ZmnSCPxj 2021-07-05 23:26:23+00:00 - - - Billy Tetrud 2021-07-05 18:24:36+00:00 - + 2025-09-26T15:42:57.015386+00:00 + python-feedgen + + + [bitcoin-dev] Proof of reserves - recording Billy Tetrud + 2021-07-05T18:24:00.000Z + + + ZmnSCPxj + 2021-07-05T23:26:00.000Z + + + Eric Voskuil + 2021-07-05T23:32:00.000Z + + + ZmnSCPxj + 2021-07-06T00:09:00.000Z + + + Billy Tetrud + 2021-07-06T01:34:00.000Z + + + ZmnSCPxj + 2021-07-06T04:54:00.000Z + + + Eric Voskuil + 2021-07-06T05:09:00.000Z + + + Billy Tetrud + 2021-07-06T06:02:00.000Z + + + Eric Voskuil + 2021-07-06T07:37:00.000Z + + + Erik Aronesty + 2021-07-06T16:39:00.000Z + + + eric + 2021-07-06T18:40:00.000Z + + + Billy Tetrud + 2021-07-07T06:18:00.000Z + + + Eric Voskuil + 2021-07-09T14:55:00.000Z + + + Billy Tetrud + 2021-07-09T17:43:00.000Z + + + Eric Voskuil + 2021-07-09T18:32:00.000Z + + + Billy Tetrud + 2021-07-09T22:02:00.000Z + + + Eric Voskuil + 2021-07-09T23:18:00.000Z + + + ZmnSCPxj + 2021-07-09T23:50:00.000Z + + + eric + 2021-07-10T00:49:00.000Z + + + ZmnSCPxj + 2021-07-10T01:26:00.000Z + + + eric + 2021-07-10T01:49:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Proof of reserves - recording - 2023-08-02T04:22:07.715686+00:00 + 2025-09-26T15:42:57.017794+00:00 - A new approach to proof of reserves has been proposed in the bitcoin-dev mailing list. The idea is for users to create private keys using a seed, generate a public key to represent their account, and give it to the custodian to record in a public record of account balances. The custodian would update a map of addresses to balances and store funds on HD wallets, creating a proof that they own each wallet. These structures would be combined and hashed, with the hash published on-chain daily. Software for each user could continuously validate their balance and verify that owned addresses have sufficient funds. A receipt system could also be added for balance updates.The proposal aims to provide a clear record of reserves that can be verified by anyone, preventing custodians from changing history. However, it does not prevent smash-and-grab attacks. The proposal also introduces people to self-custody of keys in a lightweight way, reducing the responsibility on the user. The community has been invited to provide feedback on similar systems.The discussion highlights the fallacy of auditability and the challenges in solvency audits. Trust becomes a factor as perfect accuracy is not possible. Users can publicly share their individual and temporary audits to estimate solvency. Insolvency is difficult to prevent, but proof of reserves (PoR) can help detect it. However, PoR does not insure investments against reckless behavior. Ownership of funds is conditional on knowledge of keys, which can be easily copied. Custodian proof-of-reserves only proves ownership at a specific snapshot, without guaranteeing future control. Lightning channel states change quickly, making it challenging for custodian lightning nodes to freeze a snapshot.The conversation on the GitHub page for libbitcoin-system addresses the issue of custodian proof-of-reserves. It is explained that attestation of balances in Lightning channels is valid only at the time it is taken and cannot verify ownership in the next second. Knowledge of keys is easily copyable, potentially allowing others to move funds outside the custodian's control. There is no way to prove the absence of alternate copies of private keys. Lightning channel states change quickly, creating race conditions for custodian Lightning nodes to freeze a snapshot. Despite these limitations, PoR is still worth considering.Further discussions on the bitcoin-dev mailing list explore the possibility of proving balances held on the Lightning Network. Anchoring channels on-chain serves as proof of their existence and size. Participants can sign plaintext with node pubkeys and ownership amounts. Custodian proof-of-reserves is not popular due to its limited scope and inability to prevent key loss. Lightning channel states change rapidly, posing challenges for atomic proof-of-reserves. Possible race conditions and network latency make freezing snapshots difficult.In conclusion, while there are proposals for proof of reserves in both Bitcoin and Lightning Network contexts, there are limitations and challenges to overcome. The discussions highlight the difficulties in achieving perfect accuracy and preventing insolvency. The issue of ownership based on knowledge of keys and the rapid changes in Lightning channel states add further complexity. However, the community continues to explore and discuss solutions to improve transparency and trust in the cryptocurrency ecosystem.In a recent article, the author discusses the challenge of providing proof-of-reserves for custodians in the Lightning network. The author highlights that there is a disincentive to underreport, but the dynamic nature of Lightning channel states and network latency can create race conditions that make it difficult for custodians to provide an atomic proof-of-reserves.To address this issue, the author proposes a solution involving the creation of private keys by users using a seed, which generates a public key. This public key is then provided to the custodian, representing the user's account in a public record of account balances. The custodian would update a map of addresses to balances and store funds on HD wallets. They would create a proof of ownership using the xpub for the wallet.To ensure ongoing verification of sufficient reserves, the author suggests combining and hashing these structures, with the resulting hash published in an on-chain transaction daily. This approach allows users to continuously validate their account balance and verify that owned addresses have sufficient funds. Additionally, users can request receipts for any balance updates.Recording this information on-chain serves multiple purposes. It prevents custodians from changing their history and enables cross-verification among custodians. Even if users lose their keys, they can easily create a new seed and provide a new public key to the custodian.Furthermore, having a daily record reduces the possibility of short-term loans of large cryptocurrency amounts, adding another layer of security to the system.Overall, this proposal provides a potential solution to the challenge of proving reserves in the Lightning network. By combining private and public keys, hashing structures, and recording information on-chain, custodians can offer ongoing verification of sufficient reserves while minimizing the risks associated with network dynamics and latency. 2021-07-10T01:49:37+00:00 + A new approach to proof of reserves has been proposed in the bitcoin-dev mailing list. The idea is for users to create private keys using a seed, generate a public key to represent their account, and give it to the custodian to record in a public record of account balances. The custodian would update a map of addresses to balances and store funds on HD wallets, creating a proof that they own each wallet. These structures would be combined and hashed, with the hash published on-chain daily. Software for each user could continuously validate their balance and verify that owned addresses have sufficient funds. A receipt system could also be added for balance updates.The proposal aims to provide a clear record of reserves that can be verified by anyone, preventing custodians from changing history. However, it does not prevent smash-and-grab attacks. The proposal also introduces people to self-custody of keys in a lightweight way, reducing the responsibility on the user. The community has been invited to provide feedback on similar systems.The discussion highlights the fallacy of auditability and the challenges in solvency audits. Trust becomes a factor as perfect accuracy is not possible. Users can publicly share their individual and temporary audits to estimate solvency. Insolvency is difficult to prevent, but proof of reserves (PoR) can help detect it. However, PoR does not insure investments against reckless behavior. Ownership of funds is conditional on knowledge of keys, which can be easily copied. Custodian proof-of-reserves only proves ownership at a specific snapshot, without guaranteeing future control. Lightning channel states change quickly, making it challenging for custodian lightning nodes to freeze a snapshot.The conversation on the GitHub page for libbitcoin-system addresses the issue of custodian proof-of-reserves. It is explained that attestation of balances in Lightning channels is valid only at the time it is taken and cannot verify ownership in the next second. Knowledge of keys is easily copyable, potentially allowing others to move funds outside the custodian's control. There is no way to prove the absence of alternate copies of private keys. Lightning channel states change quickly, creating race conditions for custodian Lightning nodes to freeze a snapshot. Despite these limitations, PoR is still worth considering.Further discussions on the bitcoin-dev mailing list explore the possibility of proving balances held on the Lightning Network. Anchoring channels on-chain serves as proof of their existence and size. Participants can sign plaintext with node pubkeys and ownership amounts. Custodian proof-of-reserves is not popular due to its limited scope and inability to prevent key loss. Lightning channel states change rapidly, posing challenges for atomic proof-of-reserves. Possible race conditions and network latency make freezing snapshots difficult.In conclusion, while there are proposals for proof of reserves in both Bitcoin and Lightning Network contexts, there are limitations and challenges to overcome. The discussions highlight the difficulties in achieving perfect accuracy and preventing insolvency. The issue of ownership based on knowledge of keys and the rapid changes in Lightning channel states add further complexity. However, the community continues to explore and discuss solutions to improve transparency and trust in the cryptocurrency ecosystem.In a recent article, the author discusses the challenge of providing proof-of-reserves for custodians in the Lightning network. The author highlights that there is a disincentive to underreport, but the dynamic nature of Lightning channel states and network latency can create race conditions that make it difficult for custodians to provide an atomic proof-of-reserves.To address this issue, the author proposes a solution involving the creation of private keys by users using a seed, which generates a public key. This public key is then provided to the custodian, representing the user's account in a public record of account balances. The custodian would update a map of addresses to balances and store funds on HD wallets. They would create a proof of ownership using the xpub for the wallet.To ensure ongoing verification of sufficient reserves, the author suggests combining and hashing these structures, with the resulting hash published in an on-chain transaction daily. This approach allows users to continuously validate their account balance and verify that owned addresses have sufficient funds. Additionally, users can request receipts for any balance updates.Recording this information on-chain serves multiple purposes. It prevents custodians from changing their history and enables cross-verification among custodians. Even if users lose their keys, they can easily create a new seed and provide a new public key to the custodian.Furthermore, having a daily record reduces the possibility of short-term loans of large cryptocurrency amounts, adding another layer of security to the system.Overall, this proposal provides a potential solution to the challenge of proving reserves in the Lightning network. By combining private and public keys, hashing structures, and recording information on-chain, custodians can offer ongoing verification of sufficient reserves while minimizing the risks associated with network dynamics and latency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Taproot-Fields-for-PSBT.xml b/static/bitcoin-dev/July_2021/combined_Taproot-Fields-for-PSBT.xml index 0edbc8e4bd..dfd2e79717 100644 --- a/static/bitcoin-dev/July_2021/combined_Taproot-Fields-for-PSBT.xml +++ b/static/bitcoin-dev/July_2021/combined_Taproot-Fields-for-PSBT.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Taproot Fields for PSBT - 2023-08-02T04:12:43.924281+00:00 - - Pieter Wuille 2021-11-24 16:08:18+00:00 - - - Greg Sanders 2021-11-24 16:00:42+00:00 - - - Sjors Provoost 2021-11-24 12:44:46+00:00 - - - Jeremy 2021-07-08 20:06:08+00:00 - - - Salvatore Ingala 2021-06-28 19:56:37+00:00 - - - Andrew Chow 2021-06-28 16:04:19+00:00 - - - Salvatore Ingala 2021-06-28 10:03:42+00:00 - - - Andrew Chow 2021-06-22 21:22:28+00:00 - + 2025-09-26T15:42:33.837860+00:00 + python-feedgen + + + [bitcoin-dev] Taproot Fields for PSBT Andrew Chow + 2021-06-22T21:22:00.000Z + + + Salvatore Ingala + 2021-06-28T10:03:00.000Z + + + Andrew Chow + 2021-06-28T16:04:00.000Z + + + Salvatore Ingala + 2021-06-28T19:56:00.000Z + + + Jeremy + 2021-07-08T20:06:00.000Z + + + Sjors Provoost + 2021-11-24T12:44:00.000Z + + + Greg Sanders + 2021-11-24T16:00:00.000Z + + + Pieter Wuille + 2021-11-24T16:08:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Taproot Fields for PSBT - 2023-08-02T04:12:43.924281+00:00 + 2025-09-26T15:42:33.839004+00:00 - In a recent email exchange on the bitcoin-dev mailing list, Sjors Provoost expressed confusion regarding the inclusion of the tapleaf merkle path in the PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION fields. Pieter Wuille responded by explaining that these additional fields are necessary for signers who may not have prior knowledge of the script being signed. The inclusion of the derivation path and tapleaf merkle path allows signers to sign without fully understanding the script or needing to parse it. However, the actual script information is still included for those who wish to analyze or factor it into their decision whether to sign.The confusion arose from Andrew Chow's proposal of a BIP that defines new fields for Taproot support in PSBT. These fields include the Taproot Key BIP32 Derivation Path for both PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION. The fields contain the 32-byte X-only public key, a compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, and then the master key fingerprint concatenated with the derivation path of the public key. These fields provide the necessary information about which keys are present in which leaves and how those keys are derived for signers to sign the transaction.Furthermore, Jeremy Rubin has suggested allowing different keys to specify different sighash flags, which would provide greater flexibility in specifying signature requirements. This would allow for more specific and granular signature requirements, such as chaperone signatures with anyprevout. Currently, the sighashtype key is per-input, and if a sighash type is not provided, the signer should sign using SIGHASH_ALL but may use any sighash type they wish. Rubin has requested this change to be implemented in order to enhance flexibility.Salvatore Ingala thanked Andrew for clarifying that more than one leaf can be added to the Partially Signed Bitcoin Transaction (PSBT). Additionally, Ingala suggested labeling key types that are present multiple times with different keydata in order to assist less experienced readers.Ingala also proposed a change regarding the Taproot Leaf Script as specified in BIP 341. The current control block for this leaf can be up to 4129 bytes long, which is larger than other defined PSBT types. Ingala suggested splitting it into two PSBT types, PSBT_IN_TAP_LEAF_SCRIPT and PSBT_IN_TAP_LEAF_CONTROL_BLOCK, both with no keydata. However, Andrew Chow pointed out that a taproot tree can have multiple leaf scripts and the actual script to be used may not be known at the time of adding them to the PSBT. Therefore, using only two fields with no keydata would not allow for the specification of multiple leaf scripts. Furthermore, the same leaf script can appear multiple times in the tree, so using the leaf hash as keydata would not be sufficient. To enable multiple different leaf scripts and the same leaf script to appear multiple times, the control block itself needs to be used as keydata.The proposal for Taproot support in PSBT introduces several new fields, including Taproot Key Spend Signature, Taproot Script Spend Signature, Taproot Leaf Script, Taproot Key BIP 32 Derivation Path, Taproot Internal Key, and Taproot Merkle Root. These fields are necessary to carry the information required for signing Taproot inputs. The proposal also recommends using PSBT_IN_WITNESS_UTXO for Taproot inputs instead of PSBT_IN_NON_WITNESS_UTXO to prevent potential attacks involving an updater lying about the amounts in an output. The proposal is designed to be compatible with the existing PSBT format, ensuring that old software will ignore the new fields. Test vectors are yet to be determined. 2021-11-24T16:08:18+00:00 + In a recent email exchange on the bitcoin-dev mailing list, Sjors Provoost expressed confusion regarding the inclusion of the tapleaf merkle path in the PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION fields. Pieter Wuille responded by explaining that these additional fields are necessary for signers who may not have prior knowledge of the script being signed. The inclusion of the derivation path and tapleaf merkle path allows signers to sign without fully understanding the script or needing to parse it. However, the actual script information is still included for those who wish to analyze or factor it into their decision whether to sign.The confusion arose from Andrew Chow's proposal of a BIP that defines new fields for Taproot support in PSBT. These fields include the Taproot Key BIP32 Derivation Path for both PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION. The fields contain the 32-byte X-only public key, a compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, and then the master key fingerprint concatenated with the derivation path of the public key. These fields provide the necessary information about which keys are present in which leaves and how those keys are derived for signers to sign the transaction.Furthermore, Jeremy Rubin has suggested allowing different keys to specify different sighash flags, which would provide greater flexibility in specifying signature requirements. This would allow for more specific and granular signature requirements, such as chaperone signatures with anyprevout. Currently, the sighashtype key is per-input, and if a sighash type is not provided, the signer should sign using SIGHASH_ALL but may use any sighash type they wish. Rubin has requested this change to be implemented in order to enhance flexibility.Salvatore Ingala thanked Andrew for clarifying that more than one leaf can be added to the Partially Signed Bitcoin Transaction (PSBT). Additionally, Ingala suggested labeling key types that are present multiple times with different keydata in order to assist less experienced readers.Ingala also proposed a change regarding the Taproot Leaf Script as specified in BIP 341. The current control block for this leaf can be up to 4129 bytes long, which is larger than other defined PSBT types. Ingala suggested splitting it into two PSBT types, PSBT_IN_TAP_LEAF_SCRIPT and PSBT_IN_TAP_LEAF_CONTROL_BLOCK, both with no keydata. However, Andrew Chow pointed out that a taproot tree can have multiple leaf scripts and the actual script to be used may not be known at the time of adding them to the PSBT. Therefore, using only two fields with no keydata would not allow for the specification of multiple leaf scripts. Furthermore, the same leaf script can appear multiple times in the tree, so using the leaf hash as keydata would not be sufficient. To enable multiple different leaf scripts and the same leaf script to appear multiple times, the control block itself needs to be used as keydata.The proposal for Taproot support in PSBT introduces several new fields, including Taproot Key Spend Signature, Taproot Script Spend Signature, Taproot Leaf Script, Taproot Key BIP 32 Derivation Path, Taproot Internal Key, and Taproot Merkle Root. These fields are necessary to carry the information required for signing Taproot inputs. The proposal also recommends using PSBT_IN_WITNESS_UTXO for Taproot inputs instead of PSBT_IN_NON_WITNESS_UTXO to prevent potential attacks involving an updater lying about the amounts in an output. The proposal is designed to be compatible with the existing PSBT format, ensuring that old software will ignore the new fields. Test vectors are yet to be determined. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Travel-rule-VASP-UID-and-bitcoin-URI-A-new-BIP.xml b/static/bitcoin-dev/July_2021/combined_Travel-rule-VASP-UID-and-bitcoin-URI-A-new-BIP.xml index afa9d39f39..732d55d095 100644 --- a/static/bitcoin-dev/July_2021/combined_Travel-rule-VASP-UID-and-bitcoin-URI-A-new-BIP.xml +++ b/static/bitcoin-dev/July_2021/combined_Travel-rule-VASP-UID-and-bitcoin-URI-A-new-BIP.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Travel rule, VASP UID and bitcoin URI - A new BIP - 2023-08-02T04:23:18.486479+00:00 - - David A. Harding 2021-07-16 21:42:16+00:00 - - - Karel Kyovsky 2021-07-16 14:35:21+00:00 - + 2025-09-26T15:42:48.591767+00:00 + python-feedgen + + + [bitcoin-dev] Travel rule, VASP UID and bitcoin URI - A new BIP Karel Kyovsky + 2021-07-16T14:35:00.000Z + + + David A. Harding + 2021-07-16T21:42:00.000Z + + - python-feedgen + 2 Combined summary - Travel rule, VASP UID and bitcoin URI - A new BIP - 2023-08-02T04:23:18.486479+00:00 + 2025-09-26T15:42:48.592206+00:00 - In a message to the bitcoin-dev mailing list, Karel Kyovsky has proposed standardizing a new bitcoin URI parameter name. The purpose of this proposal is to integrate the travel rule for Bitcoin ATMs, where the operator must make an effort to identify the Virtual Asset Service Provider (VASP) hosting the user's wallet and send customer identity data. Currently, when using a Bitcoin ATM, users show a QR code containing their wallet address, insert cash, and receive BTC in their wallet. The ATM operator has various options to find out the VASP, such as contacting known VASPs or using blockchain analytics tools, but these methods are not ideal. To address this issue, the author suggests enabling VASP UID in the settings of mobile wallets. This would allow the Bitcoin ATM operator to immediately communicate with the VASP after scanning the QR code, without having to search for the VASP manually. By standardizing the parameter name in the bitcoin URI, all wallet providers would use the same name, ensuring compatibility. The VASP UID could also be used as a public key to encrypt the customer's identity information before sending it to the VASP from the Bitcoin ATM.It is important to note that the directory of VASP UIDs, how VASPs can be contacted, and the method of transfer when knowing the VASP UID are not within the scope of this proposal. The author expects these aspects to be covered by third-party tools, platforms, or regulators. Compliance with US regulations is crucial for Bitcoin ATM operators and custodian wallet service providers in the US. Therefore, most custodian wallets offered on Appstore/Google Play in the US would provide their VASP UID in the bitcoin URI as a new default, with an option for users to turn it off. However, it is worth mentioning that the Travel Rule does not apply to unhosted (non-custodian) wallets. 2021-07-16T21:42:16+00:00 + In a message to the bitcoin-dev mailing list, Karel Kyovsky has proposed standardizing a new bitcoin URI parameter name. The purpose of this proposal is to integrate the travel rule for Bitcoin ATMs, where the operator must make an effort to identify the Virtual Asset Service Provider (VASP) hosting the user's wallet and send customer identity data. Currently, when using a Bitcoin ATM, users show a QR code containing their wallet address, insert cash, and receive BTC in their wallet. The ATM operator has various options to find out the VASP, such as contacting known VASPs or using blockchain analytics tools, but these methods are not ideal. To address this issue, the author suggests enabling VASP UID in the settings of mobile wallets. This would allow the Bitcoin ATM operator to immediately communicate with the VASP after scanning the QR code, without having to search for the VASP manually. By standardizing the parameter name in the bitcoin URI, all wallet providers would use the same name, ensuring compatibility. The VASP UID could also be used as a public key to encrypt the customer's identity information before sending it to the VASP from the Bitcoin ATM.It is important to note that the directory of VASP UIDs, how VASPs can be contacted, and the method of transfer when knowing the VASP UID are not within the scope of this proposal. The author expects these aspects to be covered by third-party tools, platforms, or regulators. Compliance with US regulations is crucial for Bitcoin ATM operators and custodian wallet service providers in the US. Therefore, most custodian wallets offered on Appstore/Google Play in the US would provide their VASP UID in the bitcoin URI as a new default, with an option for users to turn it off. However, it is worth mentioning that the Travel Rule does not apply to unhosted (non-custodian) wallets. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2021/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml b/static/bitcoin-dev/July_2021/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml index 639dd3c2fa..2f1ff44f7b 100644 --- a/static/bitcoin-dev/July_2021/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml +++ b/static/bitcoin-dev/July_2021/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2023-08-02T04:19:59.072454+00:00 + 2025-09-26T15:42:27.533629+00:00 + python-feedgen ZmnSCPxj 2021-07-05 00:50:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2023-08-02T04:19:59.072454+00:00 + 2025-09-26T15:42:27.533825+00:00 - In a response to Jeremy's concerns about arbitrary covenants in the Bitcoin community, ZmnSCPxj highlights the importance of respecting the concerns of others while still allowing for useful tools. ZmnSCPxj counters Shinobi's worries about covenants by stating that altcoins already have similar issues, and recursive covenants would not exacerbate these problems. ZmnSCPxj argues that an "inescapable" covenant is comparable to a `while (true);` loop, essentially making covenants Turing-complete. However, he suggests that placing an upper bound on the number of recursions could prevent full Turing-completeness while still accommodating a wide range of use-cases. Moving to an email thread, Jeremy expresses concern over the Bitcoin community's reluctance to embrace arbitrary covenants, fearing potential unforeseen consequences. In response, Dave proposes an alternative approach to addressing concerns, suggesting that proving their unfounded or lesser severity rather than limiting useful tools may be more effective in fostering mutual respect. He also points out that some of the concerns raised by Shinobi are already present in altcoins and recursive covenants might not necessarily worsen these issues. Dave believes that imposing restrictions on Bitcoin's flexibility to avoid certain problems is unnecessary when unlimited covenants could potentially offer interesting and valuable features to the community. 2021-07-05T00:50:50+00:00 + In a response to Jeremy's concerns about arbitrary covenants in the Bitcoin community, ZmnSCPxj highlights the importance of respecting the concerns of others while still allowing for useful tools. ZmnSCPxj counters Shinobi's worries about covenants by stating that altcoins already have similar issues, and recursive covenants would not exacerbate these problems. ZmnSCPxj argues that an "inescapable" covenant is comparable to a `while (true);` loop, essentially making covenants Turing-complete. However, he suggests that placing an upper bound on the number of recursions could prevent full Turing-completeness while still accommodating a wide range of use-cases. Moving to an email thread, Jeremy expresses concern over the Bitcoin community's reluctance to embrace arbitrary covenants, fearing potential unforeseen consequences. In response, Dave proposes an alternative approach to addressing concerns, suggesting that proving their unfounded or lesser severity rather than limiting useful tools may be more effective in fostering mutual respect. He also points out that some of the concerns raised by Shinobi are already present in altcoins and recursive covenants might not necessarily worsen these issues. Dave believes that imposing restrictions on Bitcoin's flexibility to avoid certain problems is unnecessary when unlimited covenants could potentially offer interesting and valuable features to the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml b/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml index 5757df4165..3db8b69438 100644 --- a/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml +++ b/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2025-09-26T14:24:36.235325+00:00 + 2025-09-26T15:34:33.325055+00:00 python-feedgen Dmitry Petukhov 2022-08-04 07:09:33+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2025-09-26T14:24:36.235467+00:00 + 2025-09-26T15:34:33.325202+00:00 2022-08-04T07:09:33+00:00 A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. The proposal uses tuples of diff --git a/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 8d0ee1785c..fba6525d9f 100644 --- a/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -2,7 +2,7 @@ 2 Combined summary - On a new community process to specify covenants - 2025-09-26T14:24:14.910744+00:00 + 2025-09-26T15:34:29.100860+00:00 python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -105,10 +105,11 @@ + 2 Combined summary - On a new community process to specify covenants - 2025-09-26T14:24:14.910955+00:00 + 2025-09-26T15:34:29.101029+00:00 2022-10-07T15:33:12+00:00 The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest diff --git a/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml b/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml index cb933636f9..6869b4fa15 100644 --- a/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml +++ b/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml @@ -2,7 +2,7 @@ 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2025-09-26T14:24:29.854293+00:00 + 2025-09-26T15:34:31.213515+00:00 python-feedgen Billy Tetrud 2022-08-20 15:30:26+00:00 @@ -229,10 +229,11 @@ + 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2025-09-26T14:24:29.854525+00:00 + 2025-09-26T15:34:31.213743+00:00 2022-08-20T15:30:26+00:00 The context discusses various discussions and debates related to the functioning and security of the Bitcoin network. One aspect discussed is the concept of "free lunches" in the network, where some users benefit without contributing, while others bear the costs. It is argued that this is an unhealthy state for the financial system and may not be sustainable in the long term.One suggestion to address this issue is to remove halvings, which are events that reduce the block reward for miners, if they become destructive to the network's security. It is also mentioned that a balanced system with a low annual inflation rate is preferable to any fiat system. While widespread consensus would be ideal, it is acknowledged that a hard fork may be necessary to implement necessary changes.The feasibility of large Bitcoin holders running ASICs to secure their holdings is also discussed. The assumption is made that fees alone may not compensate for low block rewards, and therefore, large holders may mine at a loss to preserve the value of their holdings. However, it is acknowledged that this approach may not work in practice due to trust issues and the potential for betrayal.The concept of the Prisoner's Dilemma is mentioned in relation to cooperation between Bitcoin users. It is highlighted that even though cooperation may be in the best interest of both parties, mistrust and self-interest can lead to suboptimal outcomes.The importance of transaction fees in providing censorship resistance and incentivizing miners to keep the network secure is emphasized. The discussion explores different approaches, such as tying miner revenue to the total value of Bitcoin or relying solely on transaction fees.There are debates about the business model of miners who intend to censor transactions when there is no block reward. It is argued that transaction fees provide censorship resistance, and miners may prioritize high fee transactions to maximize their earnings.The role of the block reward in the functioning of the Bitcoin network is highlighted. The question is raised about whether a perpetual block subsidy should be tied to the total value of Bitcoin or if other methods should be considered to incentivize miners.The assumption of a constant rate for losses in Bitcoin is challenged, and it is argued that losses can occur at a predictable rate. The potential impact of lost coins on the overall value of Bitcoin is discussed.There are also discussions about the subjective nature of defining Bitcoin and the role of leading bodies versus individual autonomy. The importance of the capped supply and predictable issuance curve is mentioned, and tinkering with the protocol is seen as potentially inviting further subversion.The discussion revolves around the predictability of losses in tail emission. While Peter assumes that there is a rate, it is possible for losses to be at a different predictable rate. However, if there exists any fixed central tendency for the rate, tail emission will eventually become non-inflationary. There are two other factors to consider: firstly, if people improve custody faster than 1/(N(t)*P), tail emission can still be inflationary, although this seems unlikely. Secondly, the rate is somewhat stochastic, with "black swan events" like popular wallet losing keys in coding error being possible but not relevant to tail-emission being non-inflationary. However, even such events can be factored into a fixed central tendency over a long enough time period.In the discussion on whether or not to extend block rewards after the current deadline, it is noted that this is only relevant if the community agrees that it is necessary to maintain network security. It is worth noting that a mild inflation can sometimes be compensated by coin loss, which is like a bonus. The assumption of a constant coin loss rate seems unreasonable as people improve their key storage habits over time, leading to a decrease in the rate of coin loss. Additionally, there may be common causes for coin losses that result in heavily correlated losses rather than independent ones.The conversation further explores the potential implications of tail emission on the ability of individuals to access their coins. Todd clarifies that his proposal does not involve re-assigning ownership of coins and therefore does not take away anyone's ability to access their coins. The concern raised by naman naman about the ability to move coins after a long period of inactivity is addressed, with Todd stating that his article on tail emission is focused on maintaining blockchain security without causing inflation.The latest blog post by Peter Todd titled "Surprisingly, Tail Emission Is Not Inflationary" explores the concept of tail emission and its impact on the supply of Bitcoin. Todd argues that tail emission, which is a fixed reward per block that continues indefinitely, can result in a stable monetary supply rather than a monetarily inflationary one. He explains that lost coins contribute to this stability, as they are constantly being lost due to various factors such as deaths, forgotten passphrases, and accidents.The article also discusses the feasibility of implementing tail emission in Bitcoin. While other currencies like Monero have successfully implemented it, adding tail emission to Bitcoin would require convincing a substantial fraction of the Bitcoin community to support the idea. Todd suggests that diff --git a/static/bitcoin-dev/June_2016/combined_BIP-151-MITM.xml b/static/bitcoin-dev/June_2016/combined_BIP-151-MITM.xml index edd63a3949..c600efca02 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP-151-MITM.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP-151-MITM.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 151 MITM - 2023-08-01T18:26:37.232245+00:00 + 2025-09-26T15:32:16.516745+00:00 + python-feedgen Alfie John 2016-06-09 07:00:51+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP 151 MITM - 2023-08-01T18:26:37.232245+00:00 + 2025-09-26T15:32:16.516893+00:00 - In a recent bitcoin-dev mailing list discussion, Jonas Schnelli announced that he is currently working on an Auth-BIP, which is not yet ready for review. However, he kindly provided a link to his work on Github for those interested in taking a look. He also shared the most recent MITM/auth discussion that took place on IRC. Another member of the group, Alfie John, expressed gratitude towards Jonas for sharing the links.The conversation revolved around concerns raised by Gregory Maxwell regarding plaintext attacks. He stated that active attackers find plaintext reduction uninteresting, as they can easily impersonate the remote side. To address this issue, authentication is mentioned as a separate specification that builds upon the ongoing work. This leads to Alfie John's query about how authentication can be achieved. In response, Jonas Schnelli suggests reviewing his current work on Auth-BIP and provides a link to both his Github repository and the most recent MITM/auth discussion.In a discussion thread from June 9, 2016, Gregory Maxwell discussed the lack of interest in plaintext attacks for active attackers, who can instead impersonate the remote side. The solution to this concern is authentication, which is addressed through a separate specification building on the ongoing work. Alfie John, a participant in the discussion, requested links to further discussions on authentication methods.During the discussion, Alfie John raised concerns about the potential manipulation of the initial 'encinit' message during negotiation in BIP 151. This manipulation could lead to both peers falling back to plaintext. While some argue that reducing to plaintext is not a significant attack vector for active attackers, as they can simply impersonate the remote side, authentication is seen as the solution. However, without authentication, the protection provided only defends against passive attackers. The suggestion is made that peers should negotiate a secure channel from the beginning or entirely back out, with no option of falling back. Additionally, it is proposed that the daemon listening on a completely new port can loudly indicate this. The message is signed by Alfie John and includes a link to their personal website, https://www.alfie.wtf. 2016-06-09T07:00:51+00:00 + In a recent bitcoin-dev mailing list discussion, Jonas Schnelli announced that he is currently working on an Auth-BIP, which is not yet ready for review. However, he kindly provided a link to his work on Github for those interested in taking a look. He also shared the most recent MITM/auth discussion that took place on IRC. Another member of the group, Alfie John, expressed gratitude towards Jonas for sharing the links.The conversation revolved around concerns raised by Gregory Maxwell regarding plaintext attacks. He stated that active attackers find plaintext reduction uninteresting, as they can easily impersonate the remote side. To address this issue, authentication is mentioned as a separate specification that builds upon the ongoing work. This leads to Alfie John's query about how authentication can be achieved. In response, Jonas Schnelli suggests reviewing his current work on Auth-BIP and provides a link to both his Github repository and the most recent MITM/auth discussion.In a discussion thread from June 9, 2016, Gregory Maxwell discussed the lack of interest in plaintext attacks for active attackers, who can instead impersonate the remote side. The solution to this concern is authentication, which is addressed through a separate specification building on the ongoing work. Alfie John, a participant in the discussion, requested links to further discussions on authentication methods.During the discussion, Alfie John raised concerns about the potential manipulation of the initial 'encinit' message during negotiation in BIP 151. This manipulation could lead to both peers falling back to plaintext. While some argue that reducing to plaintext is not a significant attack vector for active attackers, as they can simply impersonate the remote side, authentication is seen as the solution. However, without authentication, the protection provided only defends against passive attackers. The suggestion is made that peers should negotiate a secure channel from the beginning or entirely back out, with no option of falling back. Additionally, it is proposed that the daemon listening on a completely new port can loudly indicate this. The message is signed by Alfie John and includes a link to their personal website, https://www.alfie.wtf. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_BIP-151-use-of-HMAC-SHA512.xml b/static/bitcoin-dev/June_2016/combined_BIP-151-use-of-HMAC-SHA512.xml index b23bf00c43..4c36fc57e3 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP-151-use-of-HMAC-SHA512.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP-151-use-of-HMAC-SHA512.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 151 use of HMAC_SHA512 - 2023-08-01T18:30:51.865845+00:00 + 2025-09-26T15:32:22.858891+00:00 + python-feedgen Jonas Schnelli 2016-07-04 06:47:05+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - BIP 151 use of HMAC_SHA512 - 2023-08-01T18:30:51.865845+00:00 + 2025-09-26T15:32:22.859089+00:00 - Zooko Wilcox, in a discussion on the bitcoin-dev mailing list, suggests using the well-studied open standard of HKDF (HMAC-based Extract-and-Expand Key Derivation Function) instead of re-inventing it. He emphasizes the importance of using open standards in cryptography to reduce the risk of errors. Arthur Chen agrees with this recommendation and highlights the significance of following well-studied open standards in the realm of cryptocurrency.The discussion also touches upon the use of HMAC vs SHA256 for a Message Authentication Code (MAC). It is explained that SHA256 is insecure for a MAC due to its length extension property. Even though SHA256 appends the bitlength, making it more difficult to generate a new value, it is not being used as a MAC in BIP151. Arthur Chen explains the proven security properties of HMAC, even when the underlying crypto hashing function has weaknesses. He emphasizes the importance of using HMAC for MACs rather than custom constructions.There is a debate about using SHA512_HMAC instead of SHA256_HMAC for key derivation. Jonas Schnelli suggests using SHA512_HMAC, citing its usage in BIP32 and its cost-effectiveness compared to two SHA256_HMAC operations. However, Rusty Russell argues that introducing another hash algorithm would be unnecessarily painful and questions the use of HMAC over just SHA256. The discussion concludes without clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In another discussion, the importance of including the cipher-type in the symmetric cipher key is emphasized to avoid weak-cipher attacks. It is noted that although BIP151 currently specifies chacha20-poly1305 at openssh.com, it is possible for someone to add another symmetric cipher type after deployment which may have weaker security properties. Therefore, the inclusion of the ciphersuite-type in the key derivation HMAC is crucial to prevent potential attacks.Based on previous crypto analysis, it is stated that the security of SHA512 is not significantly higher than SHA256. There have been discussions about considering SHA3 as a potential alternative. However, there are no clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In summary, the context revolves around the importance of using well-studied open standards in cryptography. It emphasizes the use of HKDF instead of reinventing it and the utilization of HMAC for MACs to ensure security. There are debates regarding the use of SHA512_HMAC vs SHA256_HMAC for key derivation, with different perspectives provided. The inclusion of the cipher-type in the symmetric cipher key is highlighted to avoid weak-cipher attacks. Overall, the discussions aim to enhance the security and reliability of cryptographic systems in the realm of cryptocurrency. 2016-07-04T06:47:05+00:00 + Zooko Wilcox, in a discussion on the bitcoin-dev mailing list, suggests using the well-studied open standard of HKDF (HMAC-based Extract-and-Expand Key Derivation Function) instead of re-inventing it. He emphasizes the importance of using open standards in cryptography to reduce the risk of errors. Arthur Chen agrees with this recommendation and highlights the significance of following well-studied open standards in the realm of cryptocurrency.The discussion also touches upon the use of HMAC vs SHA256 for a Message Authentication Code (MAC). It is explained that SHA256 is insecure for a MAC due to its length extension property. Even though SHA256 appends the bitlength, making it more difficult to generate a new value, it is not being used as a MAC in BIP151. Arthur Chen explains the proven security properties of HMAC, even when the underlying crypto hashing function has weaknesses. He emphasizes the importance of using HMAC for MACs rather than custom constructions.There is a debate about using SHA512_HMAC instead of SHA256_HMAC for key derivation. Jonas Schnelli suggests using SHA512_HMAC, citing its usage in BIP32 and its cost-effectiveness compared to two SHA256_HMAC operations. However, Rusty Russell argues that introducing another hash algorithm would be unnecessarily painful and questions the use of HMAC over just SHA256. The discussion concludes without clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In another discussion, the importance of including the cipher-type in the symmetric cipher key is emphasized to avoid weak-cipher attacks. It is noted that although BIP151 currently specifies chacha20-poly1305 at openssh.com, it is possible for someone to add another symmetric cipher type after deployment which may have weaker security properties. Therefore, the inclusion of the ciphersuite-type in the key derivation HMAC is crucial to prevent potential attacks.Based on previous crypto analysis, it is stated that the security of SHA512 is not significantly higher than SHA256. There have been discussions about considering SHA3 as a potential alternative. However, there are no clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In summary, the context revolves around the importance of using well-studied open standards in cryptography. It emphasizes the use of HKDF instead of reinventing it and the utilization of HMAC for MACs to ensure security. There are debates regarding the use of SHA512_HMAC vs SHA256_HMAC for key derivation, with different perspectives provided. The inclusion of the cipher-type in the symmetric cipher key is highlighted to avoid weak-cipher attacks. Overall, the discussions aim to enhance the security and reliability of cryptographic systems in the realm of cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_BIP-151.xml b/static/bitcoin-dev/June_2016/combined_BIP-151.xml index 554f872ccb..f5b881dac2 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP-151.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP-151.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 151 - 2023-08-01T18:42:21.264751+00:00 + 2025-09-26T15:32:18.632550+00:00 + python-feedgen Pieter Wuille 2016-08-31 14:29:53+00:00 @@ -167,13 +168,13 @@ - python-feedgen + 2 Combined summary - BIP 151 - 2023-08-01T18:42:21.264751+00:00 + 2025-09-26T15:32:18.632737+00:00 - In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. 2016-08-31T14:29:53+00:00 + In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_BIP-draft-Memo-server.xml b/static/bitcoin-dev/June_2016/combined_BIP-draft-Memo-server.xml index 7e07b2d996..ca2056c25c 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP-draft-Memo-server.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP-draft-Memo-server.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft: Memo server - 2023-08-01T18:25:51.729004+00:00 + 2025-09-26T15:32:14.403238+00:00 + python-feedgen Luke Dashjr 2016-06-02 00:41:27+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP draft: Memo server - 2023-08-01T18:25:51.729004+00:00 + 2025-09-26T15:32:14.403391+00:00 - Chris Priest, a developer, is creating a standalone system to archive and serve memos for Bitcoin wallets. The purpose of this system is to allow wallet users to switch from one wallet to another without losing their memos. These memos will be encrypted and stored on memo servers. The public key will be propagated so that the memos can be shared among different servers. The specific encryption method for the memos has not been finalized yet, but it is crucial that they are strongly encrypted. Additionally, the memos should support various types of data, and the memo server should not be tied to a specific wallet schema.To access the memo server, users will only need to provide their memo-specific identifier, which may not be related to any part of their wallet. Multiple memo servers will be available, giving users the option to choose which ones they trust with their data. The writer of the context is developing a wallet called multiexplorer, which supports all BIPs (Bitcoin Improvement Proposals), including those that enable exporting and importing based on a 12-word mnemonic. However, when exporting and importing into another wallet, the memos added to each transaction are lost because the mnemonic cannot encode this data. To address this issue, the writer plans to create a separate system for archiving and serving these memos. Once implemented, every wallet will support this system, allowing users to seamlessly move between wallets by copying and pasting the mnemonic without losing their memos.The system works by encrypting and sending the memos to multiple memo servers operated by different individuals. These memo servers synchronize data amongst themselves. The exact encryption scheme for the memos is yet to be determined, and it is essential to choose a strong encryption method since the memos will be publicly propagated.This system aims to facilitate the transition from older, potentially less secure wallets to modern wallets with enhanced security features. It also aims to reduce lock-in by providing a solution to preserve memos when switching wallets. Detailed information about how the system will work can be found at the provided GitHub link: https://github.com/priestc/bips/blob/master/memo-server.mediawiki. 2016-06-02T00:41:27+00:00 + Chris Priest, a developer, is creating a standalone system to archive and serve memos for Bitcoin wallets. The purpose of this system is to allow wallet users to switch from one wallet to another without losing their memos. These memos will be encrypted and stored on memo servers. The public key will be propagated so that the memos can be shared among different servers. The specific encryption method for the memos has not been finalized yet, but it is crucial that they are strongly encrypted. Additionally, the memos should support various types of data, and the memo server should not be tied to a specific wallet schema.To access the memo server, users will only need to provide their memo-specific identifier, which may not be related to any part of their wallet. Multiple memo servers will be available, giving users the option to choose which ones they trust with their data. The writer of the context is developing a wallet called multiexplorer, which supports all BIPs (Bitcoin Improvement Proposals), including those that enable exporting and importing based on a 12-word mnemonic. However, when exporting and importing into another wallet, the memos added to each transaction are lost because the mnemonic cannot encode this data. To address this issue, the writer plans to create a separate system for archiving and serving these memos. Once implemented, every wallet will support this system, allowing users to seamlessly move between wallets by copying and pasting the mnemonic without losing their memos.The system works by encrypting and sending the memos to multiple memo servers operated by different individuals. These memo servers synchronize data amongst themselves. The exact encryption scheme for the memos is yet to be determined, and it is essential to choose a strong encryption method since the memos will be publicly propagated.This system aims to facilitate the transition from older, potentially less secure wallets to modern wallets with enhanced security features. It also aims to reduce lock-in by providing a solution to preserve memos when switching wallets. Detailed information about how the system will work can be found at the provided GitHub link: https://github.com/priestc/bips/blob/master/memo-server.mediawiki. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_BIP141-segwit-consensus-rule-update-extension-of-witness-program-definition.xml b/static/bitcoin-dev/June_2016/combined_BIP141-segwit-consensus-rule-update-extension-of-witness-program-definition.xml index 536aa60486..21bd1a3d77 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP141-segwit-consensus-rule-update-extension-of-witness-program-definition.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP141-segwit-consensus-rule-update-extension-of-witness-program-definition.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP141 segwit consensus rule update: extension of witness program definition - 2023-08-01T18:26:18.831867+00:00 + 2025-09-26T15:32:20.745805+00:00 + python-feedgen Pieter Wuille 2016-06-12 14:40:17+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP141 segwit consensus rule update: extension of witness program definition - 2023-08-01T18:26:18.831867+00:00 + 2025-09-26T15:32:20.745960+00:00 - In a Bitcoin-dev mailing list discussion, Luke Dashjr expressed his opinion on the safety and size limitations of the 32 bytes hash. He argued that a witness program larger than 40 bytes would be unnecessary and expensive, taking up more UTXO space. However, he acknowledged the downside of being too strict, which limits the ability to do soft fork upgrades in the future. As a compromise, he suggested raising the limit to 75 bytes.Pieter, who initiated the discussion, disagreed with the need for any changes. He believed that any data that needs to be encoded can be moved to the witness at a cheaper cost and replaced by a 256-bit hash. The only thing not allowed in the hash is metadata to indicate the hashing/rule scheme used, which Pieter thought could be represented by 68 bits (OP_n + 8 bytes).Johnson Lau also expressed concerns about the safety of the 32 bytes hash and its potential impact on the safety of txid. He suggested that if the 32 bytes hash is deemed unsafe in the future, a hard fork might be needed. Additionally, he questioned the usefulness of a witness program larger than 40 bytes, as it would be more expensive and take up more UTXO space.Luke Dashjr and Johnson Lau discussed the possibility of extending the definition for scripts with a 1-byte push followed by a push of 40 bytes. Lau suggested making it even bigger, up to 75 bytes, but Dashjr did not see this as a sufficient answer. However, Pieter explained that a softfork to redefine such scripts would be complicated due to the current limit preventing the use of the witness field.On June 8, 2016, Johnson Lau proposed increasing the size of transaction scripts to 75 bytes. Pieter explained why a size larger than 75 would be inconvenient, but did not provide a satisfactory response to the proposed increase. Luke Dashjr pointed out that scripts with a 1-byte push followed by a push of over 40 bytes remain anyone-can-spend, so they could be redefined with a softfork. However, this would prevent the use of the witness field for such scripts, requiring two different witness commitments or disabling the previous witness transaction format.The segregated witness (BIP141) consensus rule has been updated to extend the definition of a witness program, allowing it to consist of a data push between 2 to 40 bytes, instead of the previous limit of 2 to 32 bytes. This update was necessary as BIP141 only defined version 0 witness programs for P2WPKH and P2WSH, leaving versions 1 to 16 undefined and considered anyone-can-spend scripts. By extending the maximum length by 8 bytes, up to 16 * 2^64 versions are now available for future upgrades. A witness program of 40 bytes allows a 32-byte hash with 8-byte metadata, and any scripts larger than 32 bytes should be recorded in the witness field to reduce transaction cost and impact on the UTXO set.It is unlikely that a larger witness program would be required without a major revamp of the Bitcoin protocol since SHA256 is widely used. Previously, a script with a 1-byte push followed by a data push of 33-40 bytes did not allow witness data, but this is now allowed. Users running segnet nodes or testnet nodes with segwit code are advised to upgrade to the latest version at https://github.com/bitcoin/bitcoin/pull/7910. Alternative implementations should also ensure their consensus code is updated accordingly to avoid forking off the network. 2016-06-12T14:40:17+00:00 + In a Bitcoin-dev mailing list discussion, Luke Dashjr expressed his opinion on the safety and size limitations of the 32 bytes hash. He argued that a witness program larger than 40 bytes would be unnecessary and expensive, taking up more UTXO space. However, he acknowledged the downside of being too strict, which limits the ability to do soft fork upgrades in the future. As a compromise, he suggested raising the limit to 75 bytes.Pieter, who initiated the discussion, disagreed with the need for any changes. He believed that any data that needs to be encoded can be moved to the witness at a cheaper cost and replaced by a 256-bit hash. The only thing not allowed in the hash is metadata to indicate the hashing/rule scheme used, which Pieter thought could be represented by 68 bits (OP_n + 8 bytes).Johnson Lau also expressed concerns about the safety of the 32 bytes hash and its potential impact on the safety of txid. He suggested that if the 32 bytes hash is deemed unsafe in the future, a hard fork might be needed. Additionally, he questioned the usefulness of a witness program larger than 40 bytes, as it would be more expensive and take up more UTXO space.Luke Dashjr and Johnson Lau discussed the possibility of extending the definition for scripts with a 1-byte push followed by a push of 40 bytes. Lau suggested making it even bigger, up to 75 bytes, but Dashjr did not see this as a sufficient answer. However, Pieter explained that a softfork to redefine such scripts would be complicated due to the current limit preventing the use of the witness field.On June 8, 2016, Johnson Lau proposed increasing the size of transaction scripts to 75 bytes. Pieter explained why a size larger than 75 would be inconvenient, but did not provide a satisfactory response to the proposed increase. Luke Dashjr pointed out that scripts with a 1-byte push followed by a push of over 40 bytes remain anyone-can-spend, so they could be redefined with a softfork. However, this would prevent the use of the witness field for such scripts, requiring two different witness commitments or disabling the previous witness transaction format.The segregated witness (BIP141) consensus rule has been updated to extend the definition of a witness program, allowing it to consist of a data push between 2 to 40 bytes, instead of the previous limit of 2 to 32 bytes. This update was necessary as BIP141 only defined version 0 witness programs for P2WPKH and P2WSH, leaving versions 1 to 16 undefined and considered anyone-can-spend scripts. By extending the maximum length by 8 bytes, up to 16 * 2^64 versions are now available for future upgrades. A witness program of 40 bytes allows a 32-byte hash with 8-byte metadata, and any scripts larger than 32 bytes should be recorded in the witness field to reduce transaction cost and impact on the UTXO set.It is unlikely that a larger witness program would be required without a major revamp of the Bitcoin protocol since SHA256 is widely used. Previously, a script with a 1-byte push followed by a data push of 33-40 bytes did not allow witness data, but this is now allowed. Users running segnet nodes or testnet nodes with segwit code are advised to upgrade to the latest version at https://github.com/bitcoin/bitcoin/pull/7910. Alternative implementations should also ensure their consensus code is updated accordingly to avoid forking off the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_Building-Blocks-of-the-State-Machine-Approach-to-Consensus.xml b/static/bitcoin-dev/June_2016/combined_Building-Blocks-of-the-State-Machine-Approach-to-Consensus.xml index d380a94b4b..455a882143 100644 --- a/static/bitcoin-dev/June_2016/combined_Building-Blocks-of-the-State-Machine-Approach-to-Consensus.xml +++ b/static/bitcoin-dev/June_2016/combined_Building-Blocks-of-the-State-Machine-Approach-to-Consensus.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Building Blocks of the State Machine Approach to Consensus - 2023-08-01T18:28:59.773764+00:00 + 2025-09-26T15:32:24.979248+00:00 + python-feedgen Peter Todd 2016-06-24 22:23:16+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Building Blocks of the State Machine Approach to Consensus - 2023-08-01T18:28:59.773764+00:00 + 2025-09-26T15:32:24.979412+00:00 - In the realm of blockchain technology, various implementations have been developed to ensure the integrity and security of transactions. These implementations include decentralized blockchains, centralized public logs, and receipt oracles. Each approach offers a unique way to attest to the validity of transactions and handle potential fraudulent activities.One key concept in this field is the use of validity oracles. These oracles serve as trusted entities that can verify the accuracy and legitimacy of transactions. By attesting to the validity of transactions, these oracles enable the removal of historical data prior to the verified transactions, helping to streamline and optimize the blockchain.Another important tool in combatting fraud within the system is the use of fraud proofs. These proofs are designed to expose any invalid states or fraudulent proof within the blockchain. By leveraging fraud proofs, developers can ensure that the information stored within the system is accurate and reliable.To efficiently manage the blockchain's data, pruning techniques can be implemented. Pruning involves automatically keeping track of only the necessary data while serializing the proof. This helps to reduce the storage requirements and enhance the overall scalability of the blockchain, making it more efficient and accessible.Additionally, probabilistic validation techniques play a crucial role in detecting undetected fraud within the system. These techniques employ statistical methods to verify that the percentage of undetected fraud falls below a predetermined threshold with a specified probability. By utilizing probabilistic validation techniques, developers can add an extra layer of security to the blockchain, ensuring its reliability and trustworthiness.In summary, the diverse range of implementations for blockchain technology includes decentralized blockchains, centralized public logs, and receipt oracles. Validity oracles, fraud proofs, pruning techniques, and probabilistic validation techniques all contribute to the integrity and security of transactions within the blockchain ecosystem. These tools and approaches collectively work towards creating a robust and trustworthy system for handling digital transactions. 2016-06-24T22:23:16+00:00 + In the realm of blockchain technology, various implementations have been developed to ensure the integrity and security of transactions. These implementations include decentralized blockchains, centralized public logs, and receipt oracles. Each approach offers a unique way to attest to the validity of transactions and handle potential fraudulent activities.One key concept in this field is the use of validity oracles. These oracles serve as trusted entities that can verify the accuracy and legitimacy of transactions. By attesting to the validity of transactions, these oracles enable the removal of historical data prior to the verified transactions, helping to streamline and optimize the blockchain.Another important tool in combatting fraud within the system is the use of fraud proofs. These proofs are designed to expose any invalid states or fraudulent proof within the blockchain. By leveraging fraud proofs, developers can ensure that the information stored within the system is accurate and reliable.To efficiently manage the blockchain's data, pruning techniques can be implemented. Pruning involves automatically keeping track of only the necessary data while serializing the proof. This helps to reduce the storage requirements and enhance the overall scalability of the blockchain, making it more efficient and accessible.Additionally, probabilistic validation techniques play a crucial role in detecting undetected fraud within the system. These techniques employ statistical methods to verify that the percentage of undetected fraud falls below a predetermined threshold with a specified probability. By utilizing probabilistic validation techniques, developers can add an extra layer of security to the blockchain, ensuring its reliability and trustworthiness.In summary, the diverse range of implementations for blockchain technology includes decentralized blockchains, centralized public logs, and receipt oracles. Validity oracles, fraud proofs, pruning techniques, and probabilistic validation techniques all contribute to the integrity and security of transactions within the blockchain ecosystem. These tools and approaches collectively work towards creating a robust and trustworthy system for handling digital transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml b/static/bitcoin-dev/June_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml index ea9cedec01..61f8d9a363 100644 --- a/static/bitcoin-dev/June_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml +++ b/static/bitcoin-dev/June_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Code Review: The Consensus Critical Parts of Segwit by Peter Todd - 2023-08-01T18:44:26.625038+00:00 + 2025-09-26T15:32:10.178154+00:00 + python-feedgen Peter Todd 2016-07-04 23:27:15+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Code Review: The Consensus Critical Parts of Segwit by Peter Todd - 2023-08-01T18:44:26.625038+00:00 + 2025-09-26T15:32:10.178320+00:00 - In a discussion about the implementation of Segregated Witness (SegWit) on the Bitcoin network, one issue raised is the odd result that occurs when a transaction spends a witness output with an unknown version. Surprisingly, this transaction is valid even if it doesn't have any witnesses. One suggestion is to leave these unknown witness programs as any-one-can-spend without looking at the witness. However, this creates a special case in the code, allowing spending of a witness output without a witness.There is a debate about whether to allow the use of 160-bit commitments for multisig transactions, which may require 256-bit security. The argument is that using shorter hash and pubkey for storing a small amount of Bitcoin could save bytes. However, concerns are raised about potential hash collisions and the reuse of signatures for different signature hashes. To address this, tagged hashing is proposed as a way to ensure that signatures cannot be reused in different contexts. XORing the magic tag prior to its use is suggested as sufficient for signature applications.Unfortunately, this method is not compatible with timestamping schemes like OpenTimestamps, which rely on all operations being cryptographically secure. Another concern is the difficulty of adding new commitments with soft forks. It is pointed out that anything after 38 bytes in the reserve value of a 32-byte hash has no consensus meaning, making it inefficient to add new commitments with softforks.In an email exchange between Johnson Lau and Bitcoin developer Peter Todd, various issues related to SegWit implementation are discussed. They discuss the possibility of allowing users to choose a less secure 160-bit commitment if their use-case doesn't require the full 256-bit security level. Additionally, the maximum size of serialized witness scripts is debated, with the constraint being set at 520 bytes. Lastly, there is a mention of concern about hash collision, although it is unclear how it could be possible.Overall, the discussion revolves around the complexities and potential vulnerabilities of implementing Segregated Witness on the Bitcoin network, with various suggestions and concerns being raised by different participants. The goal is to find solutions that ensure the security and efficiency of transactions while avoiding any potential issues or conflicts. 2016-07-04T23:27:15+00:00 + In a discussion about the implementation of Segregated Witness (SegWit) on the Bitcoin network, one issue raised is the odd result that occurs when a transaction spends a witness output with an unknown version. Surprisingly, this transaction is valid even if it doesn't have any witnesses. One suggestion is to leave these unknown witness programs as any-one-can-spend without looking at the witness. However, this creates a special case in the code, allowing spending of a witness output without a witness.There is a debate about whether to allow the use of 160-bit commitments for multisig transactions, which may require 256-bit security. The argument is that using shorter hash and pubkey for storing a small amount of Bitcoin could save bytes. However, concerns are raised about potential hash collisions and the reuse of signatures for different signature hashes. To address this, tagged hashing is proposed as a way to ensure that signatures cannot be reused in different contexts. XORing the magic tag prior to its use is suggested as sufficient for signature applications.Unfortunately, this method is not compatible with timestamping schemes like OpenTimestamps, which rely on all operations being cryptographically secure. Another concern is the difficulty of adding new commitments with soft forks. It is pointed out that anything after 38 bytes in the reserve value of a 32-byte hash has no consensus meaning, making it inefficient to add new commitments with softforks.In an email exchange between Johnson Lau and Bitcoin developer Peter Todd, various issues related to SegWit implementation are discussed. They discuss the possibility of allowing users to choose a less secure 160-bit commitment if their use-case doesn't require the full 256-bit security level. Additionally, the maximum size of serialized witness scripts is debated, with the constraint being set at 520 bytes. Lastly, there is a mention of concern about hash collision, although it is unclear how it could be possible.Overall, the discussion revolves around the complexities and potential vulnerabilities of implementing Segregated Witness on the Bitcoin network, with various suggestions and concerns being raised by different participants. The goal is to find solutions that ensure the security and efficiency of transactions while avoiding any potential issues or conflicts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_Even-more-proposed-BIP-extensions-to-BIP-0070.xml b/static/bitcoin-dev/June_2016/combined_Even-more-proposed-BIP-extensions-to-BIP-0070.xml index 838e5d658e..4e35fd3c75 100644 --- a/static/bitcoin-dev/June_2016/combined_Even-more-proposed-BIP-extensions-to-BIP-0070.xml +++ b/static/bitcoin-dev/June_2016/combined_Even-more-proposed-BIP-extensions-to-BIP-0070.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Even more proposed BIP extensions to BIP 0070 - 2023-08-01T18:30:27.918670+00:00 + 2025-09-26T15:32:12.291868+00:00 + python-feedgen James MacWhyte 2016-06-24 05:27:36+00:00 @@ -159,13 +160,13 @@ - python-feedgen + 2 Combined summary - Even more proposed BIP extensions to BIP 0070 - 2023-08-01T18:30:27.918670+00:00 + 2025-09-26T15:32:12.292093+00:00 - BIP0075 is an encrypted/encapsulated version of BIP70 that ensures the safe exchange of BIP70 messages through an intermediary. However, it has sparked a debate about user-friendliness and privacy in Bitcoin. Justin Newton suggests using software wallets like breadwallet to keep information private, as BIP75 allows direct exchange of identity information between peers without involving the blockchain or network. There are concerns about UK legislation compelling service providers to hand over data, but BIP75 and software wallets can help protect user privacy as the information is not stored on the blockchain. However, some people may need transactional identity for fraud reduction and regulatory reasons.The bitcoin-dev community is against implementing built-in anti-money laundering (AML) or know-your-customer (KYC) tools in Bitcoin, as it could draw expectations from all users to authorities. BIP75 allows voluntary identity exchange at the application level, without passing through or storing the blockchain. Peter Todd argues against participating in AML/KYC practices and suggests removing BIP75 from the bips repository and boycotting wallets that implement it. Pieter Wuille disagrees, stating that censorship based on personal opinion is not appropriate and that editorial control should be based on objective processes.The practicality of maintaining infrastructure for payment protocol is discussed, with some participants noting that it may be impractical for end users. There is also mention of an unencrypted version of BIP70 available via Bluetooth for face-to-face transfers.In terms of editorial control over BIPs, Pieter Wuille believes that some degree of editorial control is inevitable but should be restricted to objective processes. Peter Todd suggests rejecting BIP75 on ethical and strategic grounds, but Wuille disagrees and calls it ridiculous. The conversation then shifts to the acceptance of future BIPs related to AML/KYC support.The discussion also highlights the importance of incorporating subscriptions into the protocol to facilitate Bitcoin's use as a real payment system. It is suggested that subscription information should be stored in the customer's wallet, and wallets should be responsible for initiating subscriptions on behalf of users. Expanding Bitcoin URIs to include signatures is also recommended.The discussion on improving BIP0070 explores using JSON messages instead of Protocol Buffers, alternative schemes for merchant identification, and improving subscription support. There are debates over the efficiency and potential bugs of JSON and whether existing solutions like HTTPS or Keybase are sufficient. The debate between using Protocol Buffers or JSON for the protocol itself is also discussed, with considerations for efficiency, ease of use, and security. The need for additional PKI types and identity methods is addressed, along with suggestions to expand the pki_data slot in BIP0070. The BIP75 protocol is mentioned as a way to share identity information out-of-band, independently of any name resolution system. Suggestions are made to expand the pki_data slot in BIP75 to accommodate new identity types.Overall, the discussions emphasize the desire for improvements in the BIP0070 protocol, including the use of JSON messages, alternative merchant identification schemes, enhanced subscription support, and multi-mode identity mechanisms. Different opinions are presented regarding the best approach, considering factors such as user-friendliness, efficiency, extensibility, and privacy. 2016-06-24T05:27:36+00:00 + BIP0075 is an encrypted/encapsulated version of BIP70 that ensures the safe exchange of BIP70 messages through an intermediary. However, it has sparked a debate about user-friendliness and privacy in Bitcoin. Justin Newton suggests using software wallets like breadwallet to keep information private, as BIP75 allows direct exchange of identity information between peers without involving the blockchain or network. There are concerns about UK legislation compelling service providers to hand over data, but BIP75 and software wallets can help protect user privacy as the information is not stored on the blockchain. However, some people may need transactional identity for fraud reduction and regulatory reasons.The bitcoin-dev community is against implementing built-in anti-money laundering (AML) or know-your-customer (KYC) tools in Bitcoin, as it could draw expectations from all users to authorities. BIP75 allows voluntary identity exchange at the application level, without passing through or storing the blockchain. Peter Todd argues against participating in AML/KYC practices and suggests removing BIP75 from the bips repository and boycotting wallets that implement it. Pieter Wuille disagrees, stating that censorship based on personal opinion is not appropriate and that editorial control should be based on objective processes.The practicality of maintaining infrastructure for payment protocol is discussed, with some participants noting that it may be impractical for end users. There is also mention of an unencrypted version of BIP70 available via Bluetooth for face-to-face transfers.In terms of editorial control over BIPs, Pieter Wuille believes that some degree of editorial control is inevitable but should be restricted to objective processes. Peter Todd suggests rejecting BIP75 on ethical and strategic grounds, but Wuille disagrees and calls it ridiculous. The conversation then shifts to the acceptance of future BIPs related to AML/KYC support.The discussion also highlights the importance of incorporating subscriptions into the protocol to facilitate Bitcoin's use as a real payment system. It is suggested that subscription information should be stored in the customer's wallet, and wallets should be responsible for initiating subscriptions on behalf of users. Expanding Bitcoin URIs to include signatures is also recommended.The discussion on improving BIP0070 explores using JSON messages instead of Protocol Buffers, alternative schemes for merchant identification, and improving subscription support. There are debates over the efficiency and potential bugs of JSON and whether existing solutions like HTTPS or Keybase are sufficient. The debate between using Protocol Buffers or JSON for the protocol itself is also discussed, with considerations for efficiency, ease of use, and security. The need for additional PKI types and identity methods is addressed, along with suggestions to expand the pki_data slot in BIP0070. The BIP75 protocol is mentioned as a way to share identity information out-of-band, independently of any name resolution system. Suggestions are made to expand the pki_data slot in BIP75 to accommodate new identity types.Overall, the discussions emphasize the desire for improvements in the BIP0070 protocol, including the use of JSON messages, alternative merchant identification schemes, enhanced subscription support, and multi-mode identity mechanisms. Different opinions are presented regarding the best approach, considering factors such as user-friendliness, efficiency, extensibility, and privacy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_Merkle-trees-and-mountain-ranges.xml b/static/bitcoin-dev/June_2016/combined_Merkle-trees-and-mountain-ranges.xml index c959f9cc2c..fb36a8b9c1 100644 --- a/static/bitcoin-dev/June_2016/combined_Merkle-trees-and-mountain-ranges.xml +++ b/static/bitcoin-dev/June_2016/combined_Merkle-trees-and-mountain-ranges.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Merkle trees and mountain ranges - 2023-08-01T18:27:34.546121+00:00 + 2025-09-26T15:32:08.064394+00:00 + python-feedgen Bram Cohen 2016-07-15 23:00:57+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Merkle trees and mountain ranges - 2023-08-01T18:27:34.546121+00:00 + 2025-09-26T15:32:08.064609+00:00 - In an email exchange between Peter Todd and Bram Cohen, the topic of discussion revolves around various aspects of UTXO commitments, merkle trees, and optimizations. Todd suggests using BLAKE2b for internal hashing due to its efficiency in omitting padding when the data is exactly one block in size. The implementation of a root branch block with nodes arranged in fixed positions and terminals having outpointers to other blocks is also discussed. The conversation also delves into the efficiency of their implementation when stored on a spinning hard drive. It is estimated that even an underpowered node could keep up with the blockchain if it is full of simple transactions. Validating an entire blockchain history might take a few days, but if some layers are kept in regular memory, validating a whole year of history might only take a few hours. The complexity of the MMR proposal's data structures is acknowledged, and it is suggested that specifying storage media and latency expectations would clarify the reasoning significantly.Cohen considers committing to the prefix as a way of handling cases where multiple keys share parts of the same prefix, but concludes that it would only save about 10% of memory in his implementation. Todd explains that committing to the prefix is a simple but possibly not-optimal way of committing to what data should be accessible under a given node. They discuss the depths of merkbiner trees in proportion to log2(n) against attackers who are choosing keys by grinding hashes. The optimization of hashing time is also explored, with the mention of the efficiency of BLAKE2 compared to SHA256.The conversation then moves on to the implementation of merkle trees and how each node contains metadata byte followed by fixed-size secure hashes and pointers to the children. The structure of branch blocks, terminals, and leaf blocks is explained, along with the overflow mechanism when a leaf block exceeds its capacity. The idea of achieving practical Bitcoin updates with minimal cache misses is discussed, with Cohen explaining the clever placement of nodes in memory to minimize cache misses.Another aspect of the conversation revolves around adding latency to UTXO commitments. It is agreed that adding latency can work in principle but should only be used as a last resort technique when optimization fails. The addition of roots of what's added and deleted in each block allows for proofs of inclusion and exclusion without significant latency. However, it adds complexity and should only be done when necessary for fast validation before block propagation.The discussion also touches upon the indexing of the UTXO set, the possibility of introducing incentives for collecting dust, and the use of variable-sized commitments instead of hash digests for improved efficiency. There is a debate about whether validation before block propagation needs to be done at all, with Todd suggesting that it's reasonable to propagate blocks that have not been fully validated beyond checking PoW. The importance of minimizing the time it takes miners to start mining the next block and collecting fees is emphasized.There are additional conversations discussing the technicalities of TXO commitments, the differences between merkle trees and patricia tries, and the performance and optimization considerations of implementing UTXO, STXO, and TXO commitments. The use of mountain ranges for merkle trees is debated, with suggestions for alternative approaches such as raw merkle trees.In conclusion, the email exchanges provide detailed insights into the discussions surrounding UTXO commitments, merkle trees, optimizations, latency issues, and various implementation considerations within the Bitcoin community. The conversations highlight the complexities and trade-offs involved in designing efficient and secure blockchain data structures. 2016-07-15T23:00:57+00:00 + In an email exchange between Peter Todd and Bram Cohen, the topic of discussion revolves around various aspects of UTXO commitments, merkle trees, and optimizations. Todd suggests using BLAKE2b for internal hashing due to its efficiency in omitting padding when the data is exactly one block in size. The implementation of a root branch block with nodes arranged in fixed positions and terminals having outpointers to other blocks is also discussed. The conversation also delves into the efficiency of their implementation when stored on a spinning hard drive. It is estimated that even an underpowered node could keep up with the blockchain if it is full of simple transactions. Validating an entire blockchain history might take a few days, but if some layers are kept in regular memory, validating a whole year of history might only take a few hours. The complexity of the MMR proposal's data structures is acknowledged, and it is suggested that specifying storage media and latency expectations would clarify the reasoning significantly.Cohen considers committing to the prefix as a way of handling cases where multiple keys share parts of the same prefix, but concludes that it would only save about 10% of memory in his implementation. Todd explains that committing to the prefix is a simple but possibly not-optimal way of committing to what data should be accessible under a given node. They discuss the depths of merkbiner trees in proportion to log2(n) against attackers who are choosing keys by grinding hashes. The optimization of hashing time is also explored, with the mention of the efficiency of BLAKE2 compared to SHA256.The conversation then moves on to the implementation of merkle trees and how each node contains metadata byte followed by fixed-size secure hashes and pointers to the children. The structure of branch blocks, terminals, and leaf blocks is explained, along with the overflow mechanism when a leaf block exceeds its capacity. The idea of achieving practical Bitcoin updates with minimal cache misses is discussed, with Cohen explaining the clever placement of nodes in memory to minimize cache misses.Another aspect of the conversation revolves around adding latency to UTXO commitments. It is agreed that adding latency can work in principle but should only be used as a last resort technique when optimization fails. The addition of roots of what's added and deleted in each block allows for proofs of inclusion and exclusion without significant latency. However, it adds complexity and should only be done when necessary for fast validation before block propagation.The discussion also touches upon the indexing of the UTXO set, the possibility of introducing incentives for collecting dust, and the use of variable-sized commitments instead of hash digests for improved efficiency. There is a debate about whether validation before block propagation needs to be done at all, with Todd suggesting that it's reasonable to propagate blocks that have not been fully validated beyond checking PoW. The importance of minimizing the time it takes miners to start mining the next block and collecting fees is emphasized.There are additional conversations discussing the technicalities of TXO commitments, the differences between merkle trees and patricia tries, and the performance and optimization considerations of implementing UTXO, STXO, and TXO commitments. The use of mountain ranges for merkle trees is debated, with suggestions for alternative approaches such as raw merkle trees.In conclusion, the email exchanges provide detailed insights into the discussions surrounding UTXO commitments, merkle trees, optimizations, latency issues, and various implementation considerations within the Bitcoin community. The conversations highlight the complexities and trade-offs involved in designing efficient and secure blockchain data structures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_RFC-for-BIP-Derivation-scheme-for-P2WPKH-nested-in-P2SH-based-accounts.xml b/static/bitcoin-dev/June_2016/combined_RFC-for-BIP-Derivation-scheme-for-P2WPKH-nested-in-P2SH-based-accounts.xml index 7227d42fab..bd96cc90e4 100644 --- a/static/bitcoin-dev/June_2016/combined_RFC-for-BIP-Derivation-scheme-for-P2WPKH-nested-in-P2SH-based-accounts.xml +++ b/static/bitcoin-dev/June_2016/combined_RFC-for-BIP-Derivation-scheme-for-P2WPKH-nested-in-P2SH-based-accounts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts - 2023-08-01T18:27:06.823594+00:00 + 2025-09-26T15:32:05.950356+00:00 + python-feedgen Aaron Voisine 2016-06-18 06:07:48+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts - 2023-08-01T18:27:06.823594+00:00 + 2025-09-26T15:32:05.950546+00:00 - On June 14, 2016, Daniel Weigl proposed a BIP for a P2SH accounts protocol on Github and sought feedback from the community. Aaron Voisine, co-founder and CEO of breadwallet, raised questions about the upcoming implementation of segwit version 2 with schnorr signatures and the possibility of supporting it without a third derivation path. However, no further information is provided regarding these questions.The discussion on the bitcoin-dev mailing list revolved around privacy concerns related to change outputs in transactions. One suggestion was to always use the same output type for change output if the wallet can recognize it. However, this method may still result in a privacy leak if there is only one P2PKH output and someone knows the algorithm being used. Another suggestion was to randomly select a change output that mimics one of the sending outputs to increase privacy. Additionally, to enhance privacy further, the redeemscript/witnessscript template should also be matched.Another discussion on the bitcoin-dev mailing list expressed concern about the privacy implications of using different output types for change outputs in transactions. It was suggested that "normal" send-to-single-address transactions should always use the same output type for the change output. To further enhance privacy, it was recommended to mimic one of the sending outputs by picking one at random if there are multiple "sending" outputs. The proposal also suggests matching the template of the redeemscript/witnessscript to maintain privacy even after the sends are spent.A proposal has been made to include both "native" P2WPKH addresses and P2WPKH over P2SH addresses in compatible wallets. The proposal suggests that every fully BIP-compatible wallet must support both address types. Different chain IDs could be used to differentiate between the address types, with 0 and 1 for P2WPKH over P2SH and 2 and 3 for native P2WPKH. Using P2WPKH over P2SH for change addresses instead of native P2WPKH is believed to potentially lead to a privacy leak. Therefore, it is recommended to always use the same output type for the change output in "normal" send-to-single-address transactions if the wallet can recognize it. However, there is no final decision yet on how the address encoding for P2WPKH public keys should look like as Bip141 is deferred.Daniel Weigl has proposed a BIP for P2SH accounts on the Bitcoin-dev mailing list and has requested comments and feedback from the community. He also asked if anyone is implementing something different for BIP44 compliant wallets. The question of whether to keep the discussion on the mailing list or move it to GitHub was raised. Jochen suggested considering not only P2WPKH over P2SH addresses but also "native" P2WPKH addresses and recommended that every fully BIP-compatible wallet should support both types of segwit addresses. Aaron Voisine's suggestion to use different chain IDs to distinguish between address types was also supported by Jochen.In summary, Daniel Weigl has prepared a proposal for a BIP related to a BIP44-compliant wallet and has sought feedback from the community. The discussion on the bitcoin-dev mailing list focused on privacy concerns related to change outputs and the inclusion of both P2WPKH over P2SH and "native" P2WPKH addresses in compatible wallets. Suggestions were made to enhance privacy by selecting the same output type for change outputs in "normal" send-to-single-address transactions and mimicking one of the sending outputs. The use of different chain IDs to differentiate between address types was also proposed. 2016-06-18T06:07:48+00:00 + On June 14, 2016, Daniel Weigl proposed a BIP for a P2SH accounts protocol on Github and sought feedback from the community. Aaron Voisine, co-founder and CEO of breadwallet, raised questions about the upcoming implementation of segwit version 2 with schnorr signatures and the possibility of supporting it without a third derivation path. However, no further information is provided regarding these questions.The discussion on the bitcoin-dev mailing list revolved around privacy concerns related to change outputs in transactions. One suggestion was to always use the same output type for change output if the wallet can recognize it. However, this method may still result in a privacy leak if there is only one P2PKH output and someone knows the algorithm being used. Another suggestion was to randomly select a change output that mimics one of the sending outputs to increase privacy. Additionally, to enhance privacy further, the redeemscript/witnessscript template should also be matched.Another discussion on the bitcoin-dev mailing list expressed concern about the privacy implications of using different output types for change outputs in transactions. It was suggested that "normal" send-to-single-address transactions should always use the same output type for the change output. To further enhance privacy, it was recommended to mimic one of the sending outputs by picking one at random if there are multiple "sending" outputs. The proposal also suggests matching the template of the redeemscript/witnessscript to maintain privacy even after the sends are spent.A proposal has been made to include both "native" P2WPKH addresses and P2WPKH over P2SH addresses in compatible wallets. The proposal suggests that every fully BIP-compatible wallet must support both address types. Different chain IDs could be used to differentiate between the address types, with 0 and 1 for P2WPKH over P2SH and 2 and 3 for native P2WPKH. Using P2WPKH over P2SH for change addresses instead of native P2WPKH is believed to potentially lead to a privacy leak. Therefore, it is recommended to always use the same output type for the change output in "normal" send-to-single-address transactions if the wallet can recognize it. However, there is no final decision yet on how the address encoding for P2WPKH public keys should look like as Bip141 is deferred.Daniel Weigl has proposed a BIP for P2SH accounts on the Bitcoin-dev mailing list and has requested comments and feedback from the community. He also asked if anyone is implementing something different for BIP44 compliant wallets. The question of whether to keep the discussion on the mailing list or move it to GitHub was raised. Jochen suggested considering not only P2WPKH over P2SH addresses but also "native" P2WPKH addresses and recommended that every fully BIP-compatible wallet should support both types of segwit addresses. Aaron Voisine's suggestion to use different chain IDs to distinguish between address types was also supported by Jochen.In summary, Daniel Weigl has prepared a proposal for a BIP related to a BIP44-compliant wallet and has sought feedback from the community. The discussion on the bitcoin-dev mailing list focused on privacy concerns related to change outputs and the inclusion of both P2WPKH over P2SH and "native" P2WPKH addresses in compatible wallets. Suggestions were made to enhance privacy by selecting the same output type for change outputs in "normal" send-to-single-address transactions and mimicking one of the sending outputs. The use of different chain IDs to differentiate between address types was also proposed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_-RFC-Lightning-invoice-payment-format-draft.xml b/static/bitcoin-dev/June_2017/combined_-RFC-Lightning-invoice-payment-format-draft.xml index cd5b7e09ec..b34a3a2148 100644 --- a/static/bitcoin-dev/June_2017/combined_-RFC-Lightning-invoice-payment-format-draft.xml +++ b/static/bitcoin-dev/June_2017/combined_-RFC-Lightning-invoice-payment-format-draft.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - [RFC] Lightning invoice/payment format draft - 2023-08-01T20:49:13.414346+00:00 - - Andreas Schildbach 2017-06-01 05:54:37+00:00 - - - ZmnSCPxj 2017-06-01 03:48:46+00:00 - - - ZmnSCPxj 2017-06-01 03:42:21+00:00 - - - Rusty Russell 2017-06-01 01:28:20+00:00 - + 2025-09-26T15:56:32.919351+00:00 + python-feedgen + + + [bitcoin-dev] [RFC] Lightning invoice/payment format draft Rusty Russell + 2017-06-01T01:28:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2017-06-01T03:42:00.000Z + + + ZmnSCPxj + 2017-06-01T03:48:00.000Z + + + [bitcoin-dev] " Andreas Schildbach + 2017-06-01T05:54:00.000Z + + - python-feedgen + 2 Combined summary - [RFC] Lightning invoice/payment format draft - 2023-08-01T20:49:13.414346+00:00 + 2025-09-26T15:56:32.919988+00:00 - Rusty Russell has submitted a pull request on GitHub for review of a lightning payment format. The format is bech32 encoded and includes optional parts tagged with a URI scheme, similar to the existing "bitcoin:" scheme. This proposed format also includes a MIME type for usage in NFC NDEF messages or emails. The author has provided an example payment in the pull request, demonstrating how to send 2500 microbitcoin using a specific payment hash to a specific recipient within a specific time frame. Rusty has requested wider review on the pull request.ZmnSCPxj corrects their understanding of the bech32 specification in a message. They clarify that the character "1" is not allowed in the data part, as previously thought. The last "1" digit in the bech32 string serves as a separator between the human-readable and data parts. ZmnSCPxj apologizes for any confusion caused by their previous statement.Rusty and ZmnSCPxj discuss potential issues with parsing optional amounts in bech32 in an email exchange. They note that the separator character between the human-readable and data parts is the character "1", which may cause problems when upgrading versions. Currently, version 0 translates to the character "q" appearing after "1", indicating that 1q is not an amount and starts the data part. However, if version 1 is available, a payment starting with lnbc1p could indicate a 1 pico-bitcoin payment or an arbitrary payment to a version-1 data part. ZmnSCPxj questions the necessity of limiting the use of the character "1" for the amount and suggests fixing the first 5 bits to be 0 as an unambiguous separator. They also discuss the assertion that lightning invoices are less prone to human error compared to QR reader errors due to their length.In summary, Rusty Russell has made a pull request for review of a lightning payment format that is bech32 encoded with optional parts tagged. ZmnSCPxj corrects their understanding of the bech32 specification, clarifying that the character "1" is not allowed in the data part. Rusty and ZmnSCPxj discuss potential issues with parsing optional amounts in bech32, including the use of the character "1" as a separator between human-readable and data parts. The author has requested wider review on the pull request, which includes an example payment. 2017-06-01T05:54:37+00:00 + Rusty Russell has submitted a pull request on GitHub for review of a lightning payment format. The format is bech32 encoded and includes optional parts tagged with a URI scheme, similar to the existing "bitcoin:" scheme. This proposed format also includes a MIME type for usage in NFC NDEF messages or emails. The author has provided an example payment in the pull request, demonstrating how to send 2500 microbitcoin using a specific payment hash to a specific recipient within a specific time frame. Rusty has requested wider review on the pull request.ZmnSCPxj corrects their understanding of the bech32 specification in a message. They clarify that the character "1" is not allowed in the data part, as previously thought. The last "1" digit in the bech32 string serves as a separator between the human-readable and data parts. ZmnSCPxj apologizes for any confusion caused by their previous statement.Rusty and ZmnSCPxj discuss potential issues with parsing optional amounts in bech32 in an email exchange. They note that the separator character between the human-readable and data parts is the character "1", which may cause problems when upgrading versions. Currently, version 0 translates to the character "q" appearing after "1", indicating that 1q is not an amount and starts the data part. However, if version 1 is available, a payment starting with lnbc1p could indicate a 1 pico-bitcoin payment or an arbitrary payment to a version-1 data part. ZmnSCPxj questions the necessity of limiting the use of the character "1" for the amount and suggests fixing the first 5 bits to be 0 as an unambiguous separator. They also discuss the assertion that lightning invoices are less prone to human error compared to QR reader errors due to their length.In summary, Rusty Russell has made a pull request for review of a lightning payment format that is bech32 encoded with optional parts tagged. ZmnSCPxj corrects their understanding of the bech32 specification, clarifying that the character "1" is not allowed in the data part. Rusty and ZmnSCPxj discuss potential issues with parsing optional amounts in bech32, including the use of the character "1" as a separator between human-readable and data parts. The author has requested wider review on the pull request, which includes an example payment. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_A-Method-for-Computing-Merkle-Roots-of-Annotated-Binary-Trees.xml b/static/bitcoin-dev/June_2017/combined_A-Method-for-Computing-Merkle-Roots-of-Annotated-Binary-Trees.xml index f99905078a..3b739c78bd 100644 --- a/static/bitcoin-dev/June_2017/combined_A-Method-for-Computing-Merkle-Roots-of-Annotated-Binary-Trees.xml +++ b/static/bitcoin-dev/June_2017/combined_A-Method-for-Computing-Merkle-Roots-of-Annotated-Binary-Trees.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - A Method for Computing Merkle Roots of Annotated Binary Trees - 2023-08-01T20:42:00.085812+00:00 - - Peter Todd 2017-06-27 04:13:08+00:00 - - - Russell O'Connor 2017-06-01 15:10:56+00:00 - - - Peter Todd 2017-05-29 16:10:59+00:00 - - - Russell O'Connor 2017-05-29 14:55:37+00:00 - - - Peter Todd 2017-05-28 08:26:24+00:00 - - - Russell O'Connor 2017-05-27 22:07:07+00:00 - - - Peter Todd 2017-05-27 17:41:38+00:00 - - - Bram Cohen 2017-05-23 06:06:07+00:00 - - - Russell O'Connor 2017-05-22 22:32:38+00:00 - - - Peter Todd 2017-05-22 14:05:48+00:00 - - - Russell O'Connor 2017-05-22 07:05:49+00:00 - + 2025-09-26T15:57:03.049688+00:00 + python-feedgen + + + [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees Russell O'Connor + 2017-05-22T07:05:00.000Z + + + Peter Todd + 2017-05-22T14:05:00.000Z + + + Russell O'Connor + 2017-05-22T22:32:00.000Z + + + Bram Cohen + 2017-05-23T06:06:00.000Z + + + Peter Todd + 2017-05-27T17:41:00.000Z + + + Russell O'Connor + 2017-05-27T22:07:00.000Z + + + Peter Todd + 2017-05-28T08:26:00.000Z + + + Russell O'Connor + 2017-05-29T14:55:00.000Z + + + Peter Todd + 2017-05-29T16:10:00.000Z + + + Russell O'Connor + 2017-06-01T15:10:00.000Z + + + Peter Todd + 2017-06-27T04:13:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - A Method for Computing Merkle Roots of Annotated Binary Trees - 2023-08-01T20:42:00.086817+00:00 + 2025-09-26T15:57:03.051048+00:00 - In a series of email exchanges between Russell O'Connor and Peter Todd, concerns were raised about the security of the SHA-256 compression function with chosen initial values in relation to pruned trees. Todd acknowledged these concerns and stated that there is no reason to believe that the compression function will be secure under such circumstances. It was also mentioned that fixed points can be found for the SHA256 compression function if the attacker can control the initial value.The discussion also involved a proposal for the Merkle tree data structure. O'Connor suggested using the hash of tags in the first argument of the Sha256Compress function as a way to avoid the need for SHA256's padding while still maintaining the Merkle-Damgård property. However, Todd pointed out that this approach is similar to using SHA256 directly and proposed computing the midstate sha256Compress(IV, t) instead of sha256(t). They also discussed the idea of using safe tags to prevent collisions between the Sha256 and MerkleRoot functions, but Todd argued against depending on tag uniqueness as it could lead to unintended collisions. Ultimately, Todd concluded that if a system is designed where collisions don't matter, then collisions between the sha256 and merkleroot functions won't matter either.Another point of discussion involved the security of the SHA-256 compression function with chosen initial values in pruned trees. O'Connor proposed a solution involving putting the hash of the tags into Sha256Compress's first argument, which would hold the Merkle-Damgard property under certain conditions but would lose the ability to avoid collisions between the Sha256 and MerkleRoot functions using safe tags. Todd noted that this issue arises because in pruned trees, the left merkleRoot cannot be guaranteed to be a midstate of a genuine SHA256 hash.In another email conversation, O'Connor and Todd discussed the math operations used in creating a Merkle Root. O'Connor used the symbol "⋅" to represent concatenation and "×" to represent the Cartesian product. Todd asked for clarification on the specific meaning of the Cartesian product, to which O'Connor defined it as pairs of A and B in the sense of type theory used in languages like Standard ML or Haskell. They also discussed the sha256Compress function, its arguments, and its return value.In a discussion on the Bitcoin development mailing list, O'Connor described the SHA256 compression function used in creating Merkle Tries. He suggested a construction where values are already hashed down to 256 bits before being passed in, and tags are used to determine the type of node. This approach improves performance by skipping unary hashes, and there seems to be no downside as long as tags are inexpensive.The email exchanges between O'Connor and Todd revolved around the technical details of Bitcoin's cryptography, particularly regarding the math operations and functions used in the computation of MerkleRoot.In summary, the discussions focused on concerns about the security of the SHA-256 compression function with chosen initial values in pruned trees and proposed solutions involving the use of hash tags and different math operations. The conversations also delved into the specifics of the sha256Compress function and its arguments, as well as the Merkle-Damgård property and the use of safe tags to prevent collisions. Overall, the emails provided detailed insights into the complexities of Bitcoin's cryptography and its Merkle tree data structure. 2017-06-27T04:13:08+00:00 + In a series of email exchanges between Russell O'Connor and Peter Todd, concerns were raised about the security of the SHA-256 compression function with chosen initial values in relation to pruned trees. Todd acknowledged these concerns and stated that there is no reason to believe that the compression function will be secure under such circumstances. It was also mentioned that fixed points can be found for the SHA256 compression function if the attacker can control the initial value.The discussion also involved a proposal for the Merkle tree data structure. O'Connor suggested using the hash of tags in the first argument of the Sha256Compress function as a way to avoid the need for SHA256's padding while still maintaining the Merkle-Damgård property. However, Todd pointed out that this approach is similar to using SHA256 directly and proposed computing the midstate sha256Compress(IV, t) instead of sha256(t). They also discussed the idea of using safe tags to prevent collisions between the Sha256 and MerkleRoot functions, but Todd argued against depending on tag uniqueness as it could lead to unintended collisions. Ultimately, Todd concluded that if a system is designed where collisions don't matter, then collisions between the sha256 and merkleroot functions won't matter either.Another point of discussion involved the security of the SHA-256 compression function with chosen initial values in pruned trees. O'Connor proposed a solution involving putting the hash of the tags into Sha256Compress's first argument, which would hold the Merkle-Damgard property under certain conditions but would lose the ability to avoid collisions between the Sha256 and MerkleRoot functions using safe tags. Todd noted that this issue arises because in pruned trees, the left merkleRoot cannot be guaranteed to be a midstate of a genuine SHA256 hash.In another email conversation, O'Connor and Todd discussed the math operations used in creating a Merkle Root. O'Connor used the symbol "⋅" to represent concatenation and "×" to represent the Cartesian product. Todd asked for clarification on the specific meaning of the Cartesian product, to which O'Connor defined it as pairs of A and B in the sense of type theory used in languages like Standard ML or Haskell. They also discussed the sha256Compress function, its arguments, and its return value.In a discussion on the Bitcoin development mailing list, O'Connor described the SHA256 compression function used in creating Merkle Tries. He suggested a construction where values are already hashed down to 256 bits before being passed in, and tags are used to determine the type of node. This approach improves performance by skipping unary hashes, and there seems to be no downside as long as tags are inexpensive.The email exchanges between O'Connor and Todd revolved around the technical details of Bitcoin's cryptography, particularly regarding the math operations and functions used in the computation of MerkleRoot.In summary, the discussions focused on concerns about the security of the SHA-256 compression function with chosen initial values in pruned trees and proposed solutions involving the use of hash tags and different math operations. The conversations also delved into the specifics of the sha256Compress function and its arguments, as well as the Merkle-Damgård property and the use of safe tags to prevent collisions. Overall, the emails provided detailed insights into the complexities of Bitcoin's cryptography and its Merkle tree data structure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_An-alternative-way-to-protect-the-network-from-51-attacks-threat.xml b/static/bitcoin-dev/June_2017/combined_An-alternative-way-to-protect-the-network-from-51-attacks-threat.xml index ec1d09848e..cb5f5613b5 100644 --- a/static/bitcoin-dev/June_2017/combined_An-alternative-way-to-protect-the-network-from-51-attacks-threat.xml +++ b/static/bitcoin-dev/June_2017/combined_An-alternative-way-to-protect-the-network-from-51-attacks-threat.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - An alternative way to protect the network from 51% attacks threat - 2023-08-01T21:09:42.333695+00:00 - - Moral Agent 2017-06-19 20:32:23+00:00 - - - Peter Todd 2017-06-19 18:31:54+00:00 - - - Wang Chun 2017-06-19 18:01:45+00:00 - + 2025-09-26T15:57:13.766508+00:00 + python-feedgen + + + [bitcoin-dev] An alternative way to protect the network from 51% attacks threat Wang Chun + 2017-06-19T18:01:00.000Z + + + Peter Todd + 2017-06-19T18:31:00.000Z + + + Moral Agent + 2017-06-19T20:32:00.000Z + + - python-feedgen + 2 Combined summary - An alternative way to protect the network from 51% attacks threat - 2023-08-01T21:09:42.334699+00:00 + 2025-09-26T15:57:13.767139+00:00 - In a Reddit post from February 2017, an idea was proposed to create a sidechain for Bitcoin that would be secured with Proof of Stake (POS) instead of the traditional Proof of Work (POW). This approach aims to reduce the incentive for delaying the broadcast of solved blocks. The suggested steps include soft forking Bitcoin to enable side chains, creating a side chain that mints one POS-block after each POW-block on the main chain, and penalizing POW-blocks that do not point to the prior POS-block by doubling their required difficulty. The advantages of this approach are significant. It allows individuals who do not control ASICs to influence which transactions occur and which chain gets extended. It also reduces the incentive for selfish mining and addresses issues such as stale blocks, empty blocks, and SPV mining. Importantly, it offers the same security characteristics as the main chain while reducing the effective block interval. Users have the option to opt into the POS sidechain, and it can prove itself in production before any attempt is made to anchor the main chain back to it. Notably, this proposal does not require a hard fork and can be deployed even without miner consent. The recommendation is for a hybrid POS system rather than simply changing POW algorithms to combat potential abuse by miners. Additionally, the existence of such a sidechain could discourage undesirable behavior from POW miners, as it may lead the community to take action against them.Another proposal has been put forward to address potential 51% attacks from malicious miners during a fork. Instead of changing the PoW system, it suggests combining PoW with Proof of Stake (PoS) features to create a PoW+PoS system. This solution safeguards existing investments in ASICs, prevents malicious attacks, resolves long confirmation times, scaling issues, and maintains the 21M cap on transaction fees. While pure PoS schemes may not be suitable as an add-on, careful design and the inclusion of PoS block approval mechanisms could help mitigate its problems when combined with PoW. Discussions on this approach have been ongoing since around 2014 on the #bitcoin-wizards IRC channels.The suggested PoW+PoS system offers several advantages. It protects the investments made by innocent mining users, prevents attacks from malicious miners with majority hashrate, and reduces the block time span to two minutes by inserting four PoS blocks between two PoW blocks. This solution also increases the block space by five times, effectively addressing scaling issues. Importantly, the PoS blocks only mine transaction fees, ensuring that the 21M cap remains intact. With careful design, this PoW+PoS transition could potentially be deployed through a soft fork. Overall, this proposal presents a viable solution for combating potential 51% attacks while safeguarding innocent mining users and the economy at large. 2017-06-19T20:32:23+00:00 + In a Reddit post from February 2017, an idea was proposed to create a sidechain for Bitcoin that would be secured with Proof of Stake (POS) instead of the traditional Proof of Work (POW). This approach aims to reduce the incentive for delaying the broadcast of solved blocks. The suggested steps include soft forking Bitcoin to enable side chains, creating a side chain that mints one POS-block after each POW-block on the main chain, and penalizing POW-blocks that do not point to the prior POS-block by doubling their required difficulty. The advantages of this approach are significant. It allows individuals who do not control ASICs to influence which transactions occur and which chain gets extended. It also reduces the incentive for selfish mining and addresses issues such as stale blocks, empty blocks, and SPV mining. Importantly, it offers the same security characteristics as the main chain while reducing the effective block interval. Users have the option to opt into the POS sidechain, and it can prove itself in production before any attempt is made to anchor the main chain back to it. Notably, this proposal does not require a hard fork and can be deployed even without miner consent. The recommendation is for a hybrid POS system rather than simply changing POW algorithms to combat potential abuse by miners. Additionally, the existence of such a sidechain could discourage undesirable behavior from POW miners, as it may lead the community to take action against them.Another proposal has been put forward to address potential 51% attacks from malicious miners during a fork. Instead of changing the PoW system, it suggests combining PoW with Proof of Stake (PoS) features to create a PoW+PoS system. This solution safeguards existing investments in ASICs, prevents malicious attacks, resolves long confirmation times, scaling issues, and maintains the 21M cap on transaction fees. While pure PoS schemes may not be suitable as an add-on, careful design and the inclusion of PoS block approval mechanisms could help mitigate its problems when combined with PoW. Discussions on this approach have been ongoing since around 2014 on the #bitcoin-wizards IRC channels.The suggested PoW+PoS system offers several advantages. It protects the investments made by innocent mining users, prevents attacks from malicious miners with majority hashrate, and reduces the block time span to two minutes by inserting four PoS blocks between two PoW blocks. This solution also increases the block space by five times, effectively addressing scaling issues. Importantly, the PoS blocks only mine transaction fees, ensuring that the 21M cap remains intact. With careful design, this PoW+PoS transition could potentially be deployed through a soft fork. Overall, this proposal presents a viable solution for combating potential 51% attacks while safeguarding innocent mining users and the economy at large. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_BIP-Idea-DDoS-resistance-via-decentrilized-proof-of-work.xml b/static/bitcoin-dev/June_2017/combined_BIP-Idea-DDoS-resistance-via-decentrilized-proof-of-work.xml index 90fd7d2107..55e02e7dd0 100644 --- a/static/bitcoin-dev/June_2017/combined_BIP-Idea-DDoS-resistance-via-decentrilized-proof-of-work.xml +++ b/static/bitcoin-dev/June_2017/combined_BIP-Idea-DDoS-resistance-via-decentrilized-proof-of-work.xml @@ -1,31 +1,42 @@ - + 2 Combined summary - BIP Idea : DDoS resistance via decentrilized proof-of-work - 2023-08-01T21:11:08.516084+00:00 - - Ilya Eriklintsev 2017-06-22 14:18:40+00:00 - - - Ilya Eriklintsev 2017-06-22 13:41:55+00:00 - - - Conrad Burchert 2017-06-22 12:02:45+00:00 - - - Ilya Eriklintsev 2017-06-21 09:55:22+00:00 - + 2025-09-26T15:57:05.181025+00:00 + python-feedgen + + + [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized proof-of-work Ilya Eriklintsev + 2017-06-21T09:55:00.000Z + + + Conrad Burchert + 2017-06-22T12:02:00.000Z + + + Ilya Eriklintsev + 2017-06-22T13:41:00.000Z + + + John Hardy + 2017-06-22T13:47:00.000Z + + + Ilya Eriklintsev + 2017-06-22T14:18:00.000Z + + - python-feedgen + 2 Combined summary - BIP Idea : DDoS resistance via decentrilized proof-of-work - 2023-08-01T21:11:08.516084+00:00 + 2025-09-26T15:57:05.181784+00:00 - Ilya Eriklintsev has proposed a decentralized proof-of-work (PoW) solution to improve the Bitcoin network. By modifying the simple PoW puzzle, user transactions could be hardened with the same PoW algorithm, incentivizing all miners to include that particular transaction in the next block. This would give a handicap to every miner who includes "mined" transactions into the next block, increasing their chances of receiving a block reward. The aim is to prevent continuous DDoS attacks targeting the Bitcoin network.The current system relies on miners deciding which transactions to include in blocks, with the only incentive for users being the transaction fee going directly to the miner. However, this fee market deviates significantly from a free-market premise. Additionally, small value transactions can impair the system's ability to transfer value for everyone. The proposed solution extends the concept of proof-of-work so that including a transaction in a block would reduce the effort requirements for the miner to produce a valid block. This modified proof-of-work concept is mining agnostic and could be implemented as a user-activated soft-fork. By implementing this solution, both miners and users would benefit. Miners would have direct incentives to include important transactions, while users would have increased assurance that their transactions would be included in the next block.Before any protocol change can be considered by the community, an investigation into the probable consequences and stability of the implied economic equilibrium is required. An adequate game theoretical model and numerical simulation results should be obtained and studied before proceeding with any changes. Overall, the proposed solution aims to make the Bitcoin network more secure, decentralized, and resistant to DDoS attacks, benefiting users and miners alike. 2017-06-22T14:18:40+00:00 + Ilya Eriklintsev has proposed a decentralized proof-of-work (PoW) solution to improve the Bitcoin network. By modifying the simple PoW puzzle, user transactions could be hardened with the same PoW algorithm, incentivizing all miners to include that particular transaction in the next block. This would give a handicap to every miner who includes "mined" transactions into the next block, increasing their chances of receiving a block reward. The aim is to prevent continuous DDoS attacks targeting the Bitcoin network.The current system relies on miners deciding which transactions to include in blocks, with the only incentive for users being the transaction fee going directly to the miner. However, this fee market deviates significantly from a free-market premise. Additionally, small value transactions can impair the system's ability to transfer value for everyone. The proposed solution extends the concept of proof-of-work so that including a transaction in a block would reduce the effort requirements for the miner to produce a valid block. This modified proof-of-work concept is mining agnostic and could be implemented as a user-activated soft-fork. By implementing this solution, both miners and users would benefit. Miners would have direct incentives to include important transactions, while users would have increased assurance that their transactions would be included in the next block.Before any protocol change can be considered by the community, an investigation into the probable consequences and stability of the implied economic equilibrium is required. An adequate game theoretical model and numerical simulation results should be obtained and studied before proceeding with any changes. Overall, the proposed solution aims to make the Bitcoin network more secure, decentralized, and resistant to DDoS attacks, benefiting users and miners alike. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_BIP-OP-BRIBVERIFY-the-op-code-needed-for-Blind-Merge-Mined-drivechains.xml b/static/bitcoin-dev/June_2017/combined_BIP-OP-BRIBVERIFY-the-op-code-needed-for-Blind-Merge-Mined-drivechains.xml index db9bbffc7f..9679b27423 100644 --- a/static/bitcoin-dev/June_2017/combined_BIP-OP-BRIBVERIFY-the-op-code-needed-for-Blind-Merge-Mined-drivechains.xml +++ b/static/bitcoin-dev/June_2017/combined_BIP-OP-BRIBVERIFY-the-op-code-needed-for-Blind-Merge-Mined-drivechains.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains - 2023-08-01T21:12:55.577190+00:00 - - Paul Sztorc 2017-07-13 20:45:13+00:00 - - - Chris Stewart 2017-07-13 20:22:02+00:00 - - - Paul Sztorc 2017-07-13 00:00:29+00:00 - - - CryptAxe 2017-07-12 23:58:07+00:00 - - - Paul Sztorc 2017-07-12 23:31:18+00:00 - - - Chris Stewart 2017-07-12 18:02:30+00:00 - - - Russell O'Connor 2017-07-12 13:39:17+00:00 - - - ZmnSCPxj 2017-07-12 08:50:52+00:00 - - - Chris Stewart 2017-07-04 15:06:06+00:00 - - - ZmnSCPxj 2017-07-04 07:21:23+00:00 - - - Paul Sztorc 2017-07-02 21:32:50+00:00 - - - CryptAxe 2017-06-30 16:51:34+00:00 - - - Chris Stewart 2017-06-30 14:12:30+00:00 - - - ZmnSCPxj 2017-06-30 04:00:27+00:00 - - - Russell O'Connor 2017-06-29 01:09:27+00:00 - - - Chris Stewart 2017-06-28 23:47:57+00:00 - - - Russell O'Connor 2017-06-28 22:49:54+00:00 - - - Paul Sztorc 2017-06-28 22:20:35+00:00 - - - Paul Sztorc 2017-06-28 16:43:22+00:00 - - - Paul Sztorc 2017-06-28 16:35:32+00:00 - - - ZmnSCPxj 2017-06-28 08:26:37+00:00 - - - Adam Back 2017-06-28 05:28:31+00:00 - - - Luke Dashjr 2017-06-28 05:20:27+00:00 - - - Gregory Maxwell 2017-06-28 04:07:43+00:00 - - - Chris Stewart 2017-06-28 00:37:13+00:00 - + 2025-09-26T15:57:00.925725+00:00 + python-feedgen + + + [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains Chris Stewart + 2017-06-28T00:37:00.000Z + + + Gregory Maxwell + 2017-06-28T04:07:00.000Z + + + Luke Dashjr + 2017-06-28T05:20:00.000Z + + + Adam Back + 2017-06-28T05:28:00.000Z + + + ZmnSCPxj + 2017-06-28T08:26:00.000Z + + + Paul Sztorc + 2017-06-28T16:35:00.000Z + + + Paul Sztorc + 2017-06-28T16:43:00.000Z + + + Paul Sztorc + 2017-06-28T22:20:00.000Z + + + Russell O'Connor + 2017-06-28T22:49:00.000Z + + + Chris Stewart + 2017-06-28T23:47:00.000Z + + + Russell O'Connor + 2017-06-29T01:09:00.000Z + + + ZmnSCPxj + 2017-06-30T04:00:00.000Z + + + Chris Stewart + 2017-06-30T14:12:00.000Z + + + CryptAxe + 2017-06-30T16:51:00.000Z + + + Paul Sztorc + 2017-07-02T21:32:00.000Z + + + ZmnSCPxj + 2017-07-04T07:21:00.000Z + + + Chris Stewart + 2017-07-04T15:06:00.000Z + + + ZmnSCPxj + 2017-07-12T08:50:00.000Z + + + Russell O'Connor + 2017-07-12T13:39:00.000Z + + + Chris Stewart + 2017-07-12T18:02:00.000Z + + + Paul Sztorc + 2017-07-12T23:31:00.000Z + + + CryptAxe + 2017-07-12T23:58:00.000Z + + + Paul Sztorc + 2017-07-13T00:00:00.000Z + + + Chris Stewart + 2017-07-13T20:22:00.000Z + + + Paul Sztorc + 2017-07-13T20:45:00.000Z + + @@ -103,13 +131,13 @@ - python-feedgen + 2 Combined summary - BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains - 2023-08-01T21:12:55.578190+00:00 + 2025-09-26T15:57:00.928284+00:00 - In a Bitcoin development mailing list conversation, Chris Stewart asked for clarification on the purpose of 'Ratchet' in BMM (blind merge mining). Paul explained that BMM aims to validate sidechains with minimal validation on the mainchain. They introduced a new rule that requires h* to be accompanied by the modulus of its sidechain block number (BlockMod) to ensure accurate validation. The mainchain also has a rule that restricts the new BlockMod to a specific range relative to the old BlockMod. Additionally, BMM implemented a rule that prevents payment of bribes unless the sidechain block has been buried by a certain number of sidechain blocks to prevent orphaning.The discussion continued with Chris seeking opinions on Lightning bribes. Paul argued that in equilibrium, the coinbase version may be more efficient than the OP_RETURN version. A miner can redeem an OP Bribe through the Lightning Network. Sidechains running in SPV mode know where to find the necessary information to discover the longest chain. However, the OP_RETURN version requires a spend in the UTXO set and additional data storage.The conversation then shifted to the efficiency of Bitcoin in equilibrium, including Lightning Network or similar solutions. Two versions of sidechains were discussed: coinbase and OP_RETURN. The coinbase version involves a single event per N, with hash commitments and ratchet's block counter instances per block. The OP Bribe can be negotiated through the Lightning Network. In the OP_RETURN version, there are also hash commitments per block, but it requires a spend in the UTXO set and extra data storage to locate the necessary information.The email thread also included discussions on the implementation of sidechains and blind merge mining. The sender argued that a block list node is valid only if its block is valid, which seemed to contradict the "blind" aspect of blind merge mining. However, they explained their scheme, which includes storing sidechain block headers on the mainchain using OP_RETURN data. The sidechain block headers are reduced to only the previous-block-header commitment and the current-block-data commitment. If the current-block-data is invalid, another sidechain block header based on the previous block header will be searched for.Another topic discussed was the issue of replaceability of bribe transactions. Several proposals were made, including having the amount in the output instead of the fee and replacing the bribe transaction with a double spend transaction. There were also suggestions to remove the necessity of coinbase commitments and use a special OP_RETURN output or include the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The conversation also touched upon blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIBEVERIFY proposal by removing the necessity of coinbase commitments and using the hash of the sidechain's name or genesis block to identify them instead of numbering them. It was suggested that miners could maximize their fee income by imposing a blocksize limit on themselves and orphaning non-compliant blocks.In another discussion, the sender proposed improvements to the OP_BRIBEVERIFY proposal. They suggested removing the need for coinbase commitments and having the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY. Another improvement was to keep a set of sidechain IDs when verifying a block and fail the script processing if an OP_BRIBEVERIFY already exists for that specific sidechain ID. There was also a suggestion to eliminate the use of scripting altogether and use a special non-standard OP_RETURN output to hold the sidechain ID and h*. A soft fork rule could be implemented to limit this output to one per block per sidechain ID.The email thread discussed the challenges of blind merge mining and ensuring the validity of sidechain blocks. The sender argued that a block list node is only valid if its block is valid, which seemed contradictory to the blind merge mining concept. However, they explained their scheme, which involves storing the OP_RETURN data representing sidechain block headers on the mainchain. The sender also proposed the use of a ratchet system to link h* data from bribes to sidechain blocks.In a conversation between Chris Stewart, Russell O'Connor, and ZmnSCPxj, they discussed the issue of replaceability of bribe transactions. They proposed different solutions, such as having the amount in the output instead of the fee or using a double spend transaction to replace the bribe. They also discussed the issue of coinbase commitments and searching for drivechain commitments in the Bitcoin blockchain. Suggestions were made to remove the necessity of coinbase commitments and have the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The discussion also covered blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIB 2017-07-13T20:45:13+00:00 + In a Bitcoin development mailing list conversation, Chris Stewart asked for clarification on the purpose of 'Ratchet' in BMM (blind merge mining). Paul explained that BMM aims to validate sidechains with minimal validation on the mainchain. They introduced a new rule that requires h* to be accompanied by the modulus of its sidechain block number (BlockMod) to ensure accurate validation. The mainchain also has a rule that restricts the new BlockMod to a specific range relative to the old BlockMod. Additionally, BMM implemented a rule that prevents payment of bribes unless the sidechain block has been buried by a certain number of sidechain blocks to prevent orphaning.The discussion continued with Chris seeking opinions on Lightning bribes. Paul argued that in equilibrium, the coinbase version may be more efficient than the OP_RETURN version. A miner can redeem an OP Bribe through the Lightning Network. Sidechains running in SPV mode know where to find the necessary information to discover the longest chain. However, the OP_RETURN version requires a spend in the UTXO set and additional data storage.The conversation then shifted to the efficiency of Bitcoin in equilibrium, including Lightning Network or similar solutions. Two versions of sidechains were discussed: coinbase and OP_RETURN. The coinbase version involves a single event per N, with hash commitments and ratchet's block counter instances per block. The OP Bribe can be negotiated through the Lightning Network. In the OP_RETURN version, there are also hash commitments per block, but it requires a spend in the UTXO set and extra data storage to locate the necessary information.The email thread also included discussions on the implementation of sidechains and blind merge mining. The sender argued that a block list node is valid only if its block is valid, which seemed to contradict the "blind" aspect of blind merge mining. However, they explained their scheme, which includes storing sidechain block headers on the mainchain using OP_RETURN data. The sidechain block headers are reduced to only the previous-block-header commitment and the current-block-data commitment. If the current-block-data is invalid, another sidechain block header based on the previous block header will be searched for.Another topic discussed was the issue of replaceability of bribe transactions. Several proposals were made, including having the amount in the output instead of the fee and replacing the bribe transaction with a double spend transaction. There were also suggestions to remove the necessity of coinbase commitments and use a special OP_RETURN output or include the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The conversation also touched upon blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIBEVERIFY proposal by removing the necessity of coinbase commitments and using the hash of the sidechain's name or genesis block to identify them instead of numbering them. It was suggested that miners could maximize their fee income by imposing a blocksize limit on themselves and orphaning non-compliant blocks.In another discussion, the sender proposed improvements to the OP_BRIBEVERIFY proposal. They suggested removing the need for coinbase commitments and having the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY. Another improvement was to keep a set of sidechain IDs when verifying a block and fail the script processing if an OP_BRIBEVERIFY already exists for that specific sidechain ID. There was also a suggestion to eliminate the use of scripting altogether and use a special non-standard OP_RETURN output to hold the sidechain ID and h*. A soft fork rule could be implemented to limit this output to one per block per sidechain ID.The email thread discussed the challenges of blind merge mining and ensuring the validity of sidechain blocks. The sender argued that a block list node is only valid if its block is valid, which seemed contradictory to the blind merge mining concept. However, they explained their scheme, which involves storing the OP_RETURN data representing sidechain block headers on the mainchain. The sender also proposed the use of a ratchet system to link h* data from bribes to sidechain blocks.In a conversation between Chris Stewart, Russell O'Connor, and ZmnSCPxj, they discussed the issue of replaceability of bribe transactions. They proposed different solutions, such as having the amount in the output instead of the fee or using a double spend transaction to replace the bribe. They also discussed the issue of coinbase commitments and searching for drivechain commitments in the Bitcoin blockchain. Suggestions were made to remove the necessity of coinbase commitments and have the miner commit to the sidechain ID and h* in the transaction that pays the OP_BRIBEVERIFY.The discussion also covered blind merge mining and the need to ensure that a sidechain cannot be reorged without the mainchain. Proposals were made to improve the OP_BRIB - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_BIP-Proposal-Compact-Client-Side-Filtering-for-Light-Clients.xml b/static/bitcoin-dev/June_2017/combined_BIP-Proposal-Compact-Client-Side-Filtering-for-Light-Clients.xml index 8590c8b449..095f9c8ca9 100644 --- a/static/bitcoin-dev/June_2017/combined_BIP-Proposal-Compact-Client-Side-Filtering-for-Light-Clients.xml +++ b/static/bitcoin-dev/June_2017/combined_BIP-Proposal-Compact-Client-Side-Filtering-for-Light-Clients.xml @@ -1,122 +1,167 @@ - + 2 Combined summary - BIP Proposal: Compact Client Side Filtering for Light Clients - 2023-08-01T20:51:02.028155+00:00 - - Olaoluwa Osuntokun 2017-11-09 23:44:07+00:00 - - - Adam Back 2017-06-20 17:20:53+00:00 - - - bfd at cock.lu 2017-06-20 13:08:03+00:00 - - - Tom Zander 2017-06-20 09:52:00+00:00 - - - Eric Voskuil 2017-06-20 07:03:43+00:00 - - - Gregory Maxwell 2017-06-19 22:41:49+00:00 - - - Andreas Schildbach 2017-06-19 20:49:17+00:00 - - - Tom Zander 2017-06-19 16:38:55+00:00 - - - adiabat 2017-06-19 16:36:41+00:00 - - - Jonas Schnelli 2017-06-19 16:30:18+00:00 - - - Jonas Schnelli 2017-06-19 16:22:03+00:00 - - - Jonas Schnelli 2017-06-19 16:10:13+00:00 - - - Tom Zander 2017-06-19 16:07:45+00:00 - - - Andreas Schildbach 2017-06-19 15:59:57+00:00 - - - Jonas Schnelli 2017-06-19 15:49:59+00:00 - - - Andreas Schildbach 2017-06-19 15:43:14+00:00 - - - Tom Zander 2017-06-19 15:15:10+00:00 - - - bfd at cock.lu 2017-06-19 12:26:46+00:00 - - - Andreas Schildbach 2017-06-19 11:58:18+00:00 - - - Tomas 2017-06-09 08:26:52+00:00 - - - Olaoluwa Osuntokun 2017-06-09 04:47:19+00:00 - - - Olaoluwa Osuntokun 2017-06-09 03:59:17+00:00 - - - Olaoluwa Osuntokun 2017-06-09 03:50:37+00:00 - - - Olaoluwa Osuntokun 2017-06-09 03:42:58+00:00 - - - Olaoluwa Osuntokun 2017-06-09 03:03:51+00:00 - - - Tomas 2017-06-08 09:50:08+00:00 - - - Gregory Maxwell 2017-06-07 21:41:36+00:00 - - - Karl Johan Alm 2017-06-05 02:06:32+00:00 - - - Alex Akselrod 2017-06-02 17:55:31+00:00 - - - Chris Pacia 2017-06-02 16:07:17+00:00 - - - Karl Johan Alm 2017-06-02 06:00:30+00:00 - - - Olaoluwa Osuntokun 2017-06-02 04:49:16+00:00 - - - Alex Akselrod 2017-06-02 03:35:29+00:00 - - - Gregory Maxwell 2017-06-02 02:28:54+00:00 - - - Chris 2017-06-02 02:15:16+00:00 - - - Olaoluwa Osuntokun 2017-06-01 22:10:34+00:00 - - - Eric Lombrozo 2017-06-01 21:00:02+00:00 - - - Olaoluwa Osuntokun 2017-06-01 19:01:14+00:00 - + 2025-09-26T15:56:48.044198+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients Olaoluwa Osuntokun + 2017-06-01T19:01:00.000Z + + + Eric Lombrozo + 2017-06-01T21:00:00.000Z + + + Matt Corallo + 2017-06-01T21:33:00.000Z + + + Olaoluwa Osuntokun + 2017-06-01T22:10:00.000Z + + + Chris + 2017-06-02T02:15:00.000Z + + + Gregory Maxwell + 2017-06-02T02:28:00.000Z + + + Alex Akselrod + 2017-06-02T03:35:00.000Z + + + Olaoluwa Osuntokun + 2017-06-02T04:49:00.000Z + + + Karl Johan Alm + 2017-06-02T06:00:00.000Z + + + Chris Pacia + 2017-06-02T16:07:00.000Z + + + Alex Akselrod + 2017-06-02T17:55:00.000Z + + + Karl Johan Alm + 2017-06-05T02:06:00.000Z + + + Gregory Maxwell + 2017-06-07T21:41:00.000Z + + + Tomas + 2017-06-08T09:50:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T03:03:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T03:42:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T03:50:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T03:59:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T04:47:00.000Z + + + Tomas + 2017-06-09T08:26:00.000Z + + + Andreas Schildbach + 2017-06-19T11:58:00.000Z + + + bfd + 2017-06-19T12:26:00.000Z + + + Tom Zander + 2017-06-19T15:15:00.000Z + + + Andreas Schildbach + 2017-06-19T15:43:00.000Z + + + Jonas Schnelli + 2017-06-19T15:49:00.000Z + + + Andreas Schildbach + 2017-06-19T15:59:00.000Z + + + Tom Zander + 2017-06-19T16:07:00.000Z + + + Jonas Schnelli + 2017-06-19T16:10:00.000Z + + + Jonas Schnelli + 2017-06-19T16:22:00.000Z + + + Jonas Schnelli + 2017-06-19T16:30:00.000Z + + + adiabat + 2017-06-19T16:36:00.000Z + + + Tom Zander + 2017-06-19T16:38:00.000Z + + + Andreas Schildbach + 2017-06-19T20:49:00.000Z + + + Gregory Maxwell + 2017-06-19T22:41:00.000Z + + + Eric Voskuil + 2017-06-20T07:03:00.000Z + + + Tom Zander + 2017-06-20T09:52:00.000Z + + + bfd + 2017-06-20T13:08:00.000Z + + + Adam Back + 2017-06-20T17:20:00.000Z + + + Olaoluwa Osuntokun + 2017-11-09T23:44:00.000Z + + @@ -155,13 +200,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Compact Client Side Filtering for Light Clients - 2023-08-01T20:51:02.029154+00:00 + 2025-09-26T15:56:48.048053+00:00 - There have been ongoing discussions and debates within the Bitcoin community regarding the necessity of filtering unconfirmed transactions. One of the main points of contention is the trade-off between privacy and transaction notification in Bitcoin wallets.The current method of filtering unconfirmed transactions, known as BIP37, has been criticized for its resource consumption and lack of long-term value for Bitcoin. Some argue that relying solely on BIP37 availability is fragile and exploring alternative methods is reasonable.In a discussion thread on the bitcoin-dev forum, it was suggested that users may be willing to sacrifice privacy by using client-side filtering in exchange for not having an "incoming transaction" feature or fetching all received transactions only when they need 0-conf. However, others argue that immediate feedback on transactions being broadcasted is necessary for basic usability.It has been noted that there are privacy issues associated with BIP37, but they are not a significant concern for most regular users. On the other hand, delayed or missing transactions are a much more common issue faced by Bitcoin wallet users.The concept of Simplified Payment Verification (SPV) was brought up in the discussion, with the reminder that it is not applicable to unconfirmed transactions. SPV relies on miners committing to a transaction through work to provide assurance to the user that the transaction is valid. However, unconfirmed transactions can be easily forged by anyone, including the user's ISP.The debate also touched on the use of mempool filtering, which gives users false assurance that there is a valid but yet-to-be-confirmed transaction sending them money. It was pointed out that unconfirmed transactions are not final and can still be rejected by the network.In addition to the discussion on filtering unconfirmed transactions, there have been proposals for new light client Bitcoin Improvement Proposals (BIPs) that aim to improve the usability and efficiency of Bitcoin wallets. These proposals include suggestions for different types of light clients and potential solutions to address issues in the construction and lookup of filters.Overall, there is ongoing dialogue within the Bitcoin community about the balance between privacy and transaction notification in Bitcoin wallets. Various proposals and ideas are being discussed to improve the usability and efficiency of Bitcoin wallets while considering the trade-offs involved. Feedback from users and developers is being sought to further refine these proposals. 2017-11-09T23:44:07+00:00 + There have been ongoing discussions and debates within the Bitcoin community regarding the necessity of filtering unconfirmed transactions. One of the main points of contention is the trade-off between privacy and transaction notification in Bitcoin wallets.The current method of filtering unconfirmed transactions, known as BIP37, has been criticized for its resource consumption and lack of long-term value for Bitcoin. Some argue that relying solely on BIP37 availability is fragile and exploring alternative methods is reasonable.In a discussion thread on the bitcoin-dev forum, it was suggested that users may be willing to sacrifice privacy by using client-side filtering in exchange for not having an "incoming transaction" feature or fetching all received transactions only when they need 0-conf. However, others argue that immediate feedback on transactions being broadcasted is necessary for basic usability.It has been noted that there are privacy issues associated with BIP37, but they are not a significant concern for most regular users. On the other hand, delayed or missing transactions are a much more common issue faced by Bitcoin wallet users.The concept of Simplified Payment Verification (SPV) was brought up in the discussion, with the reminder that it is not applicable to unconfirmed transactions. SPV relies on miners committing to a transaction through work to provide assurance to the user that the transaction is valid. However, unconfirmed transactions can be easily forged by anyone, including the user's ISP.The debate also touched on the use of mempool filtering, which gives users false assurance that there is a valid but yet-to-be-confirmed transaction sending them money. It was pointed out that unconfirmed transactions are not final and can still be rejected by the network.In addition to the discussion on filtering unconfirmed transactions, there have been proposals for new light client Bitcoin Improvement Proposals (BIPs) that aim to improve the usability and efficiency of Bitcoin wallets. These proposals include suggestions for different types of light clients and potential solutions to address issues in the construction and lookup of filters.Overall, there is ongoing dialogue within the Bitcoin community about the balance between privacy and transaction notification in Bitcoin wallets. Various proposals and ideas are being discussed to improve the usability and efficiency of Bitcoin wallets while considering the trade-offs involved. Feedback from users and developers is being sought to further refine these proposals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml b/static/bitcoin-dev/June_2017/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml index ae34a4ef91..797d2a3442 100644 --- a/static/bitcoin-dev/June_2017/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml +++ b/static/bitcoin-dev/June_2017/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml @@ -1,41 +1,47 @@ - + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 - - Giulia Fanti 2018-07-08 12:50:43+00:00 - - - Gregory Maxwell 2018-06-26 05:20:02+00:00 - - - Bradley Denby 2018-06-26 00:12:02+00:00 - - - Pieter Wuille 2018-06-12 01:05:14+00:00 - - - Bradley Denby 2018-06-11 14:31:09+00:00 - - - Pieter Wuille 2018-06-06 04:01:00+00:00 - - - Bradley Denby 2018-06-04 20:29:50+00:00 - - - Bradley Denby 2018-05-10 12:59:12+00:00 - - - Giulia Fanti 2017-09-21 02:10:29+00:00 - - - Gregory Maxwell 2017-06-13 01:00:50+00:00 - - - Andrew Miller 2017-06-12 14:46:23+00:00 - + 2025-09-26T15:56:50.199329+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation Bradley Denby + 2018-05-10T12:59:00.000Z + + + Bradley Denby + 2018-06-04T20:29:00.000Z + + + Pieter Wuille + 2018-06-06T04:01:00.000Z + + + Bradley Denby + 2018-06-11T14:31:00.000Z + + + Pieter Wuille + 2018-06-12T01:05:00.000Z + + + Bradley Denby + 2018-06-26T00:12:00.000Z + + + Gregory Maxwell + 2018-06-26T05:20:00.000Z + + + Neudecker, Till (TM) + 2018-07-05T14:50:00.000Z + + + Giulia Fanti + 2018-07-08T12:50:00.000Z + + @@ -47,13 +53,13 @@ - python-feedgen + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 + 2025-09-26T15:56:50.200471+00:00 - The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality 2018-07-08T12:50:43+00:00 + The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_BIP148-temporary-service-bit-1-27-.xml b/static/bitcoin-dev/June_2017/combined_BIP148-temporary-service-bit-1-27-.xml index feea414ca0..595457bb5a 100644 --- a/static/bitcoin-dev/June_2017/combined_BIP148-temporary-service-bit-1-27-.xml +++ b/static/bitcoin-dev/June_2017/combined_BIP148-temporary-service-bit-1-27-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP148 temporary service bit (1 << 27) - 2023-08-01T21:10:02.751555+00:00 - - Mark Friedenbach 2017-06-19 20:24:25+00:00 - - - Tom Zander 2017-06-19 19:46:57+00:00 - - - Luke Dashjr 2017-06-19 19:26:22+00:00 - + 2025-09-26T15:56:56.639048+00:00 + python-feedgen + + + [bitcoin-dev] BIP148 temporary service bit (1 << 27) Luke Dashjr + 2017-06-19T19:26:00.000Z + + + Tom Zander + 2017-06-19T19:46:00.000Z + + + Mark Friedenbach + 2017-06-19T20:24:00.000Z + + - python-feedgen + 2 Combined summary - BIP148 temporary service bit (1 << 27) - 2023-08-01T21:10:02.751555+00:00 + 2025-09-26T15:56:56.639597+00:00 - In order to prevent a network partition on August 1st, it is crucial for BIP-148 nodes to connect with at least two other BIP-148 nodes. To facilitate this, a temporary service bit (1) has been introduced to allow these nodes to detect each other and ease the transition to BIP148 while minimizing risks in case miners choose to perform a chain split attack. Bitcoin Knots, a Bitcoin software implementation, will be using this service bit, and other software implementing BIP148 are encouraged to do the same. Once the transition is complete, returning the bit for reuse will no longer be necessary.Luke Dashjr, a developer of Bitcoin Knots, has recommended that other software implementing BIP148 should set and use the service bit (1) to avoid network partitioning risks. This recommendation aims to ease the transition to BIP148 and minimize risks in the event of a chain split attack. The temporary service bit will be used until the transition is complete, after which it will be manually returned for reuse. Tom Zander, another developer, inquired about what action can be taken when encountering a peer with or without the set bit and requested the Github commit link where the implementation was done. The discussion regarding this matter took place on the bitcoin-dev mailing list.Bitcoin Knots' decision to utilize the temporary service bit (1) is part of their efforts to facilitate the transition to BIP148 and minimize the potential risks associated with a chain split attack by signaling readiness for Segregated Witness (SegWit). SegWit is a proposed protocol upgrade aimed at increasing Bitcoin's block size limit. By using the service bit (1), Bitcoin Knots nodes running version 0.14.2 or later will only accept blocks that signal readiness for SegWit. This measure helps ensure that the network remains unified and does not split into separate chains.The introduction of SegWit has sparked controversy within the Bitcoin community, with some supporting it as a necessary step for scalability, while others have concerns about centralization and the potential impact on network decentralization. Despite this, many Bitcoin businesses and users have shown their support for SegWit by activating the BIP91 proposal, which provides a way for miners to activate SegWit without causing a chain split.Bitcoin Knots' decision to use the service bit (1) to signal readiness for SegWit is seen as a positive step in ensuring a smooth transition to the proposed protocol upgrade. It also serves as a reminder to other Bitcoin software implementations to take similar measures to prevent a chain split and maintain the integrity of the Bitcoin network. By adopting these precautions, the Bitcoin community aims to minimize risks and ensure the successful implementation of BIP148 and SegWit. 2017-06-19T20:24:25+00:00 + In order to prevent a network partition on August 1st, it is crucial for BIP-148 nodes to connect with at least two other BIP-148 nodes. To facilitate this, a temporary service bit (1) has been introduced to allow these nodes to detect each other and ease the transition to BIP148 while minimizing risks in case miners choose to perform a chain split attack. Bitcoin Knots, a Bitcoin software implementation, will be using this service bit, and other software implementing BIP148 are encouraged to do the same. Once the transition is complete, returning the bit for reuse will no longer be necessary.Luke Dashjr, a developer of Bitcoin Knots, has recommended that other software implementing BIP148 should set and use the service bit (1) to avoid network partitioning risks. This recommendation aims to ease the transition to BIP148 and minimize risks in the event of a chain split attack. The temporary service bit will be used until the transition is complete, after which it will be manually returned for reuse. Tom Zander, another developer, inquired about what action can be taken when encountering a peer with or without the set bit and requested the Github commit link where the implementation was done. The discussion regarding this matter took place on the bitcoin-dev mailing list.Bitcoin Knots' decision to utilize the temporary service bit (1) is part of their efforts to facilitate the transition to BIP148 and minimize the potential risks associated with a chain split attack by signaling readiness for Segregated Witness (SegWit). SegWit is a proposed protocol upgrade aimed at increasing Bitcoin's block size limit. By using the service bit (1), Bitcoin Knots nodes running version 0.14.2 or later will only accept blocks that signal readiness for SegWit. This measure helps ensure that the network remains unified and does not split into separate chains.The introduction of SegWit has sparked controversy within the Bitcoin community, with some supporting it as a necessary step for scalability, while others have concerns about centralization and the potential impact on network decentralization. Despite this, many Bitcoin businesses and users have shown their support for SegWit by activating the BIP91 proposal, which provides a way for miners to activate SegWit without causing a chain split.Bitcoin Knots' decision to use the service bit (1) to signal readiness for SegWit is seen as a positive step in ensuring a smooth transition to the proposed protocol upgrade. It also serves as a reminder to other Bitcoin software implementations to take similar measures to prevent a chain split and maintain the integrity of the Bitcoin network. By adopting these precautions, the Bitcoin community aims to minimize risks and ensure the successful implementation of BIP148 and SegWit. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_BIP149-timeout-why-so-far-in-the-future-.xml b/static/bitcoin-dev/June_2017/combined_BIP149-timeout-why-so-far-in-the-future-.xml index 183279ba3b..7603cc59d9 100644 --- a/static/bitcoin-dev/June_2017/combined_BIP149-timeout-why-so-far-in-the-future-.xml +++ b/static/bitcoin-dev/June_2017/combined_BIP149-timeout-why-so-far-in-the-future-.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP149 timeout-- why so far in the future? - 2023-08-01T20:45:02.556824+00:00 - - Jorge Timón 2017-06-11 14:29:08+00:00 - - - Martijn Meijering 2017-06-11 13:44:17+00:00 - - - Jorge Timón 2017-06-11 13:17:43+00:00 - - - Ryan Grant 2017-06-11 05:48:39+00:00 - - - Rusty Russell 2017-05-27 01:19:33+00:00 - - - Matt Corallo 2017-05-26 20:04:58+00:00 - - - shaolinfry 2017-05-26 07:28:09+00:00 - - - Rusty Russell 2017-05-24 04:26:56+00:00 - - - Gregory Maxwell 2017-05-23 17:50:12+00:00 - + 2025-09-26T15:56:30.804118+00:00 + python-feedgen + + + [bitcoin-dev] BIP149 timeout-- why so far in the future? Gregory Maxwell + 2017-05-23T17:50:00.000Z + + + Rusty Russell + 2017-05-24T04:26:00.000Z + + + shaolinfry + 2017-05-26T07:28:00.000Z + + + Matt Corallo + 2017-05-26T20:04:00.000Z + + + Rusty Russell + 2017-05-27T01:19:00.000Z + + + Ryan Grant + 2017-06-11T05:48:00.000Z + + + Jorge Timón + 2017-06-11T13:17:00.000Z + + + Martijn Meijering + 2017-06-11T13:44:00.000Z + + + Jorge Timón + 2017-06-11T14:29:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - BIP149 timeout-- why so far in the future? - 2023-08-01T20:45:02.557826+00:00 + 2025-09-26T15:56:30.805244+00:00 - In a recent discussion on the bitcoin-dev mailing list, Jorge Timón proposed that BIP 149 should only activate if BIP 141 has expired unsuccessfully. This would be done by not removing the BIP 141 deployment with bip9. If SegWit activates before November 15th, BIP 149 nodes can detect and interpret it correctly. However, if it activates after November 15th, a separate service bit in the p2p network will be needed for pre-BIP 149 nodes to know whether SegWit has activated or not. Timón's proposal has raised concerns about the testing requirements of BIP 149.Some individuals argue that BIP 149 should be merged and released immediately, while others believe that more testing is necessary. The concern is that if BIP 149 is deployed before the activation of SegWit pre-November 15th, then BIP 149 nodes would use the old service bit for SegWit instead of the new one. There has been some work done to modify the code to account for this scenario, but there seems to be little interest in releasing BIP 149 before November 15th. A query was raised about whether there would be any problem with activating BIP 149 on November 16th.The activation of BIP 149 on November 16th could potentially cause problems for some users of Bitcoin. While the activation would improve the scalability and security of the network, it could also lead to compatibility issues for wallets and exchanges that are not prepared for SegWit addresses. Additionally, users who have not upgraded their nodes to support SegWit may find themselves unable to validate transactions or participate in the network after the activation. It is recommended that users ensure their wallets and exchanges are compatible with SegWit and upgrade their nodes as soon as possible to avoid any potential issues.There is ongoing debate within the Bitcoin community about the best way to activate SegWit, with some advocating for BIP 148 as an alternative proposal. However, BIP 149 has gained significant support and is expected to proceed as planned.In an email conversation between Rusty Russell and Matt Corallo, they discuss the timing of releasing code related to SegWit. Corallo emphasizes that the timeout for SegWit is not as important as when the code can be released, which he predicts will take several months after the current timeout. Russell had assumed that the code would be included in the next point release.A discussion on the bitcoin-dev mailing list focused on the timeout and release of code for SegWit. Gregory Maxwell suggested that the BIP 149 timeout was set too far in the future and that it could take up to six months after release for a stable transition. Rusty Russell agreed and proposed a deadline of December 16th, 2017, or January 16th, 2018, to avoid interference from the end-of-year holidays. This delay has set back SegWit by one to two months beyond what would have been experienced with BIP 8. It is expected that the release of the code will take several months after the current timeout.In another email exchange on the bitcoin-dev mailing list, a Bitcoin developer suggested bringing forward the BIP 149 activation date. Originally set far out enough to avoid focusing on the date rather than the proposal itself, the activation date could potentially be reduced to six months or less from November 2017. The developer argued that the community's eagerness for SegWit, as evidenced by the quick upgrade to BIP 141, suggests that they will also upgrade quickly to BIP 149. Gregory Maxwell questioned the timeline based on the observed adoption rates of SegWit, suggesting that it could take up to six months after release for a stable transition. Rusty Russell agreed and recommended a December 16th, 2017 deadline (or January 16th during EOY holidays). This delay pushes back SegWit by one to two months beyond what would have happened with BIP 8.The speed of SegWit adoption has led to concerns about the distant future of the BIP 149 timeout. It is believed that it could take up to six months after release for the required density for a stable transition. However, this timeline may not be applicable if it were a different proposal and not SegWit, where network penetration has already been observed. 2017-06-11T14:29:08+00:00 + In a recent discussion on the bitcoin-dev mailing list, Jorge Timón proposed that BIP 149 should only activate if BIP 141 has expired unsuccessfully. This would be done by not removing the BIP 141 deployment with bip9. If SegWit activates before November 15th, BIP 149 nodes can detect and interpret it correctly. However, if it activates after November 15th, a separate service bit in the p2p network will be needed for pre-BIP 149 nodes to know whether SegWit has activated or not. Timón's proposal has raised concerns about the testing requirements of BIP 149.Some individuals argue that BIP 149 should be merged and released immediately, while others believe that more testing is necessary. The concern is that if BIP 149 is deployed before the activation of SegWit pre-November 15th, then BIP 149 nodes would use the old service bit for SegWit instead of the new one. There has been some work done to modify the code to account for this scenario, but there seems to be little interest in releasing BIP 149 before November 15th. A query was raised about whether there would be any problem with activating BIP 149 on November 16th.The activation of BIP 149 on November 16th could potentially cause problems for some users of Bitcoin. While the activation would improve the scalability and security of the network, it could also lead to compatibility issues for wallets and exchanges that are not prepared for SegWit addresses. Additionally, users who have not upgraded their nodes to support SegWit may find themselves unable to validate transactions or participate in the network after the activation. It is recommended that users ensure their wallets and exchanges are compatible with SegWit and upgrade their nodes as soon as possible to avoid any potential issues.There is ongoing debate within the Bitcoin community about the best way to activate SegWit, with some advocating for BIP 148 as an alternative proposal. However, BIP 149 has gained significant support and is expected to proceed as planned.In an email conversation between Rusty Russell and Matt Corallo, they discuss the timing of releasing code related to SegWit. Corallo emphasizes that the timeout for SegWit is not as important as when the code can be released, which he predicts will take several months after the current timeout. Russell had assumed that the code would be included in the next point release.A discussion on the bitcoin-dev mailing list focused on the timeout and release of code for SegWit. Gregory Maxwell suggested that the BIP 149 timeout was set too far in the future and that it could take up to six months after release for a stable transition. Rusty Russell agreed and proposed a deadline of December 16th, 2017, or January 16th, 2018, to avoid interference from the end-of-year holidays. This delay has set back SegWit by one to two months beyond what would have been experienced with BIP 8. It is expected that the release of the code will take several months after the current timeout.In another email exchange on the bitcoin-dev mailing list, a Bitcoin developer suggested bringing forward the BIP 149 activation date. Originally set far out enough to avoid focusing on the date rather than the proposal itself, the activation date could potentially be reduced to six months or less from November 2017. The developer argued that the community's eagerness for SegWit, as evidenced by the quick upgrade to BIP 141, suggests that they will also upgrade quickly to BIP 149. Gregory Maxwell questioned the timeline based on the observed adoption rates of SegWit, suggesting that it could take up to six months after release for a stable transition. Rusty Russell agreed and recommended a December 16th, 2017 deadline (or January 16th during EOY holidays). This delay pushes back SegWit by one to two months beyond what would have happened with BIP 8.The speed of SegWit adoption has led to concerns about the distant future of the BIP 149 timeout. It is believed that it could take up to six months after release for the required density for a stable transition. However, this timeline may not be applicable if it were a different proposal and not SegWit, where network penetration has already been observed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Bitcoin-pointers.xml b/static/bitcoin-dev/June_2017/combined_Bitcoin-pointers.xml index 8ee418ac24..74ffaab3c3 100644 --- a/static/bitcoin-dev/June_2017/combined_Bitcoin-pointers.xml +++ b/static/bitcoin-dev/June_2017/combined_Bitcoin-pointers.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Bitcoin pointers - 2023-08-01T20:59:49.111718+00:00 - - Jonas Schnelli 2017-06-11 20:19:20+00:00 - - - JOSE FEMENIAS CAÑUELO 2017-06-11 20:05:24+00:00 - + 2025-09-26T15:56:52.317353+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin pointers JOSE FEMENIAS CAÑUELO + 2017-06-11T20:05:00.000Z + + + Jonas Schnelli + 2017-06-11T20:19:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin pointers - 2023-08-01T20:59:49.111718+00:00 + 2025-09-26T15:56:52.317850+00:00 - José Femenías Cañuelo has been working on a specification for Bitcoin pointers, allowing users to point to transactions, inputs, outputs, or internal items within them. He proposes three different types of pointers, each building upon the previous one. The first proposal is Canonical Pointers, which are represented as "btc at 170.1/179-631-520". To provide more information about this proposal, Jonas, the author of the email, includes a link to a Google Docs document.The second proposal is Mnemonic Pointers, which replaces the numerical representation of Canonical Pointers with words from the BIP39 dictionary. For example, "best.ability /biology-exclude-donate" becomes the new pointer. This alternative aims to make the pointers more user-friendly and memorable.Lastly, the third proposal is Domain Pointers, which utilizes the Domain Name Registration system. It encodes a pointer to a Canonical Pointer using the format "btc at example.com". This approach leverages existing domain registration infrastructure to create easily recognizable and accessible pointers.José Femenías Cañuelo welcomes feedback from the community on these proposals, as they have not yet undergone peer review. In order to facilitate error detection and correction, the Bech32 encoded transaction position reference is mentioned. This method allows for efficient error handling with just 14 characters.To conclude the email, Jonas attaches a signature in the form of a PGP-signed message. This ensures the authenticity and integrity of the email's content. 2017-06-11T20:19:20+00:00 + José Femenías Cañuelo has been working on a specification for Bitcoin pointers, allowing users to point to transactions, inputs, outputs, or internal items within them. He proposes three different types of pointers, each building upon the previous one. The first proposal is Canonical Pointers, which are represented as "btc at 170.1/179-631-520". To provide more information about this proposal, Jonas, the author of the email, includes a link to a Google Docs document.The second proposal is Mnemonic Pointers, which replaces the numerical representation of Canonical Pointers with words from the BIP39 dictionary. For example, "best.ability /biology-exclude-donate" becomes the new pointer. This alternative aims to make the pointers more user-friendly and memorable.Lastly, the third proposal is Domain Pointers, which utilizes the Domain Name Registration system. It encodes a pointer to a Canonical Pointer using the format "btc at example.com". This approach leverages existing domain registration infrastructure to create easily recognizable and accessible pointers.José Femenías Cañuelo welcomes feedback from the community on these proposals, as they have not yet undergone peer review. In order to facilitate error detection and correction, the Bech32 encoded transaction position reference is mentioned. This method allows for efficient error handling with just 14 characters.To conclude the email, Jonas attaches a signature in the form of a PGP-signed message. This ensures the authenticity and integrity of the email's content. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Compatibility-Oriented-Omnibus-Proposal.xml b/static/bitcoin-dev/June_2017/combined_Compatibility-Oriented-Omnibus-Proposal.xml index fad8d5af9d..df3156d3e8 100644 --- a/static/bitcoin-dev/June_2017/combined_Compatibility-Oriented-Omnibus-Proposal.xml +++ b/static/bitcoin-dev/June_2017/combined_Compatibility-Oriented-Omnibus-Proposal.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Compatibility-Oriented Omnibus Proposal - 2023-08-01T20:48:08.740175+00:00 - - Sergio Demian Lerner 2017-06-02 21:57:12+00:00 - - - Jared Lee Richardson 2017-06-02 20:13:58+00:00 - - - CalvinRechner 2017-05-30 22:20:25+00:00 - - - Erik Aronesty 2017-05-30 15:51:17+00:00 - - - Oliver Petruzel 2017-05-29 23:49:59+00:00 - - - Erik Aronesty 2017-05-29 22:52:36+00:00 - - - James Hilliard 2017-05-29 10:19:18+00:00 - - - CalvinRechner 2017-05-29 01:18:13+00:00 - + 2025-09-26T15:56:41.569665+00:00 + python-feedgen + + + [bitcoin-dev] Compatibility-Oriented Omnibus Proposal CalvinRechner + 2017-05-29T01:18:00.000Z + + + James Hilliard + 2017-05-29T10:19:00.000Z + + + Erik Aronesty + 2017-05-29T22:52:00.000Z + + + Oliver Petruzel + 2017-05-29T23:49:00.000Z + + + Erik Aronesty + 2017-05-30T15:51:00.000Z + + + CalvinRechner + 2017-05-30T22:20:00.000Z + + + Jared Lee Richardson + 2017-06-02T20:13:00.000Z + + + Sergio Demian Lerner + 2017-06-02T21:57:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Compatibility-Oriented Omnibus Proposal - 2023-08-01T20:48:08.741173+00:00 + 2025-09-26T15:56:41.570625+00:00 - In a Bitcoin-dev email thread, concerns were raised about the compatibility of LukeJr's suggested 2MB cap with the NY agreement. Users questioned the reasoning behind this decision and suggested incorporating a gradual blocksize increase beyond the initial 2MB cap to satisfy the conditions of the Scaling Agreement. The purpose of the Omnibus Proposal is to achieve the goals of the Consensus 2017 Scaling Agreement while preventing chain-split risks. The proposal sets automatic hard fork rules once SegWit is activated and calls upon the developers of the Segwit2x Team to consider and honor the Omnibus Proposal.There is controversy over including a secondary limit on the block size increase in the segwit + 2mb agreement. Users expect a linear increase in block size when the Base Size is increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. Jared suggests that hard data is needed to justify the secondary limitation or it should be left out in favor of a transaction size limit. Shaolin Fry's "Mandatory activation of segwit deployment" is included to cause the existing "segwit" deployment to activate without needing to release a new deployment. However, this may cause more controversy due to tight timelines and specific signaling requirements.Calvin Rechner believes that incorporating Luke-Jr's 2MB limit and discount-rebalancing would satisfy the conditions of the Scaling Agreement while ensuring maximum safety, minimum code discrepancies, and minimum controversy among the community. He suggests a gradual increase to a larger size cap to achieve cooperation between the community, industry, and developers. The Omnibus Proposal guarantees a successful SegWit activation followed by a hard fork and represents compatibility with existing deployment approaches.The Compatibility-Oriented Omnibus Proposal aims to achieve the goals of the Consensus 2017 Scaling Agreement by minimizing disruption and loss potential. It suggests phasing in a gradual blocksize increase beyond the initial 2MB cap and committing to unity to prevent chain-split risks. The proposal ensures a successful SegWit activation followed by a hard fork, enforcing legacy consensus compatibility until the specified block height. It is designed to serve as a template for achieving true consensus in the Bitcoin community.The current situation in the Bitcoin community involves multiple proposals and potential hard forks. The xkcd comic "Standards" illustrates the problem with having too many competing standards. One potential fork, a rapid 2MB+Segwit hard fork coin, has the potential to fragment the network if not enacted unanimously. BIP148 in Core seems necessary to defend against attacks. LukeJr's proposed 2MB block size hardfork may also become controversial. Oliver Petruzel seeks an explanation for this unexpected outcome.There is a proposal for a 2MB block size hardfork in the Bitcoin community. Experts suggest it as the best way to implement this change, as long as it is adopted unanimously. A block size limit will need to be imposed to enforce the new block size and ensure smooth network operation. The proposal aims to fulfill the commitments of the Consensus 2017 Scaling Agreement.The proposal suggests combining several constituent proposals into a single omnibus proposal and patch set. It plans to activate SegWit at an 80% signaling threshold while also activating a 2MB hard fork within six months. It incorporates protectionary measures to ensure a safe fork activation. The proposal assumes genuine commitment from the signatories of the Scaling Agreement and aims to remain compatible with future network updates.The Compatibility-oriented Omnibus Proposal is an attempt to combine multiple proposals and achieve the goals of the Consensus 2017 Scaling Agreement. It includes various activation options to prevent delays and maximize compatibility. The proposal links the activation of SegWit with a later hard fork block size increase. It imposes a legacy witness discount and a 2MB blocksize limit to ensure a safe fork activation. It is designed to unite the Bitcoin community under a common front.The proposal aims to fulfill the commitments of the Consensus 2017 Scaling Agreement by combining several proposals into a single patch set. It includes activation options and protectionary measures to ensure safe fork activation. Although not likely to be merged into Bitcoin Core immediately, it is written with compatibility in mind. The proposal assumes commitment from the signatories of the agreement and aims to achieve true consensus.Overall, the Bitcoin development community is active and engaged, with various platforms for discussion and collaboration. The proposal provides an opportunity for cooperation and unity while minimizing risks. The availability of resources such as mailing lists and public forums contributes to ongoing innovation in the field of cryptocurrency. 2017-06-02T21:57:12+00:00 + In a Bitcoin-dev email thread, concerns were raised about the compatibility of LukeJr's suggested 2MB cap with the NY agreement. Users questioned the reasoning behind this decision and suggested incorporating a gradual blocksize increase beyond the initial 2MB cap to satisfy the conditions of the Scaling Agreement. The purpose of the Omnibus Proposal is to achieve the goals of the Consensus 2017 Scaling Agreement while preventing chain-split risks. The proposal sets automatic hard fork rules once SegWit is activated and calls upon the developers of the Segwit2x Team to consider and honor the Omnibus Proposal.There is controversy over including a secondary limit on the block size increase in the segwit + 2mb agreement. Users expect a linear increase in block size when the Base Size is increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. Jared suggests that hard data is needed to justify the secondary limitation or it should be left out in favor of a transaction size limit. Shaolin Fry's "Mandatory activation of segwit deployment" is included to cause the existing "segwit" deployment to activate without needing to release a new deployment. However, this may cause more controversy due to tight timelines and specific signaling requirements.Calvin Rechner believes that incorporating Luke-Jr's 2MB limit and discount-rebalancing would satisfy the conditions of the Scaling Agreement while ensuring maximum safety, minimum code discrepancies, and minimum controversy among the community. He suggests a gradual increase to a larger size cap to achieve cooperation between the community, industry, and developers. The Omnibus Proposal guarantees a successful SegWit activation followed by a hard fork and represents compatibility with existing deployment approaches.The Compatibility-Oriented Omnibus Proposal aims to achieve the goals of the Consensus 2017 Scaling Agreement by minimizing disruption and loss potential. It suggests phasing in a gradual blocksize increase beyond the initial 2MB cap and committing to unity to prevent chain-split risks. The proposal ensures a successful SegWit activation followed by a hard fork, enforcing legacy consensus compatibility until the specified block height. It is designed to serve as a template for achieving true consensus in the Bitcoin community.The current situation in the Bitcoin community involves multiple proposals and potential hard forks. The xkcd comic "Standards" illustrates the problem with having too many competing standards. One potential fork, a rapid 2MB+Segwit hard fork coin, has the potential to fragment the network if not enacted unanimously. BIP148 in Core seems necessary to defend against attacks. LukeJr's proposed 2MB block size hardfork may also become controversial. Oliver Petruzel seeks an explanation for this unexpected outcome.There is a proposal for a 2MB block size hardfork in the Bitcoin community. Experts suggest it as the best way to implement this change, as long as it is adopted unanimously. A block size limit will need to be imposed to enforce the new block size and ensure smooth network operation. The proposal aims to fulfill the commitments of the Consensus 2017 Scaling Agreement.The proposal suggests combining several constituent proposals into a single omnibus proposal and patch set. It plans to activate SegWit at an 80% signaling threshold while also activating a 2MB hard fork within six months. It incorporates protectionary measures to ensure a safe fork activation. The proposal assumes genuine commitment from the signatories of the Scaling Agreement and aims to remain compatible with future network updates.The Compatibility-oriented Omnibus Proposal is an attempt to combine multiple proposals and achieve the goals of the Consensus 2017 Scaling Agreement. It includes various activation options to prevent delays and maximize compatibility. The proposal links the activation of SegWit with a later hard fork block size increase. It imposes a legacy witness discount and a 2MB blocksize limit to ensure a safe fork activation. It is designed to unite the Bitcoin community under a common front.The proposal aims to fulfill the commitments of the Consensus 2017 Scaling Agreement by combining several proposals into a single patch set. It includes activation options and protectionary measures to ensure safe fork activation. Although not likely to be merged into Bitcoin Core immediately, it is written with compatibility in mind. The proposal assumes commitment from the signatories of the agreement and aims to achieve true consensus.Overall, the Bitcoin development community is active and engaged, with various platforms for discussion and collaboration. The proposal provides an opportunity for cooperation and unity while minimizing risks. The availability of resources such as mailing lists and public forums contributes to ongoing innovation in the field of cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Drivechain-Request-for-Discussion.xml b/static/bitcoin-dev/June_2017/combined_Drivechain-Request-for-Discussion.xml index 4eea5ad9ba..d17e66fe97 100644 --- a/static/bitcoin-dev/June_2017/combined_Drivechain-Request-for-Discussion.xml +++ b/static/bitcoin-dev/June_2017/combined_Drivechain-Request-for-Discussion.xml @@ -1,80 +1,183 @@ - + 2 Combined summary - Drivechain -- Request for Discussion - 2023-08-01T20:40:46.011696+00:00 - - Chris Stewart 2017-06-19 15:41:01+00:00 - - - CryptAxe 2017-06-18 21:27:52+00:00 - - - Chris Stewart 2017-06-18 14:36:24+00:00 - - - Paul Sztorc 2017-06-10 16:28:09+00:00 - - - Sergio Demian Lerner 2017-06-09 21:54:00+00:00 - - - Paul Sztorc 2017-05-30 05:11:51+00:00 - - - Erik Aronesty 2017-05-29 05:54:34+00:00 - - - Peter Todd 2017-05-28 21:07:57+00:00 - - - Tier Nolan 2017-05-25 22:08:00+00:00 - - - CryptAxe 2017-05-24 17:32:22+00:00 - - - Tier Nolan 2017-05-24 10:05:38+00:00 - - - Tier Nolan 2017-05-24 08:50:22+00:00 - - - ZmnSCPxj 2017-05-23 23:26:52+00:00 - - - Paul Sztorc 2017-05-23 14:22:43+00:00 - - - Paul Sztorc 2017-05-23 14:12:24+00:00 - - - Tier Nolan 2017-05-23 09:51:26+00:00 - - - ZmnSCPxj 2017-05-23 00:13:55+00:00 - - - Paul Sztorc 2017-05-22 20:00:19+00:00 - - - Tier Nolan 2017-05-22 19:12:54+00:00 - - - Paul Sztorc 2017-05-22 16:19:14+00:00 - - - Paul Sztorc 2017-05-22 15:30:46+00:00 - - - ZmnSCPxj 2017-05-22 14:39:19+00:00 - - - Peter Todd 2017-05-22 13:33:35+00:00 - - - Paul Sztorc 2017-05-22 06:17:07+00:00 - + 2025-09-26T15:56:54.513411+00:00 + python-feedgen + + + [bitcoin-dev] Drivechain -- Request for Discussion Paul Sztorc + 2017-05-22T06:17:00.000Z + + + Peter Todd + 2017-05-22T13:33:00.000Z + + + ZmnSCPxj + 2017-05-22T14:39:00.000Z + + + Paul Sztorc + 2017-05-22T15:30:00.000Z + + + Paul Sztorc + 2017-05-22T16:19:00.000Z + + + Tier Nolan + 2017-05-22T19:12:00.000Z + + + Paul Sztorc + 2017-05-22T20:00:00.000Z + + + ZmnSCPxj + 2017-05-23T00:13:00.000Z + + + Tier Nolan + 2017-05-23T09:51:00.000Z + + + Paul Sztorc + 2017-05-23T14:12:00.000Z + + + Paul Sztorc + 2017-05-23T14:22:00.000Z + + + ZmnSCPxj + 2017-05-23T23:26:00.000Z + + + Tier Nolan + 2017-05-24T08:50:00.000Z + + + Tier Nolan + 2017-05-24T10:05:00.000Z + + + CryptAxe + 2017-05-24T17:32:00.000Z + + + Tier Nolan + 2017-05-25T22:08:00.000Z + + + Peter Todd + 2017-05-28T21:07:00.000Z + + + Erik Aronesty + 2017-05-29T05:54:00.000Z + + + Paul Sztorc + 2017-05-30T05:11:00.000Z + + + Sergio Demian Lerner + 2017-06-09T21:54:00.000Z + + + Paul Sztorc + 2017-06-10T16:28:00.000Z + + + [bitcoin-dev] Drivechain RfD -- Follow Up Paul Sztorc + 2017-06-10T17:04:00.000Z + + + Chris Stewart + 2017-06-18T14:36:00.000Z + + + CryptAxe + 2017-06-18T21:27:00.000Z + + + Tao Effect + 2017-06-18T21:30:00.000Z + + + Chris Stewart + 2017-06-19T15:41:00.000Z + + + Paul Sztorc + 2017-06-19T16:04:00.000Z + + + Paul Sztorc + 2017-06-20T11:54:00.000Z + + + Erik Aronesty + 2017-06-20T13:38:00.000Z + + + Paul Sztorc + 2017-06-22T13:27:00.000Z + + + Erik Aronesty + 2017-06-22T13:45:00.000Z + + + Paul Sztorc + 2017-06-22T20:30:00.000Z + + + Erik Aronesty + 2017-06-23T14:19:00.000Z + + + Moral Agent + 2017-06-23T14:51:00.000Z + + + Paul Sztorc + 2017-06-23T18:11:00.000Z + + + Tao Effect + 2017-07-12T22:43:00.000Z + + + Paul Sztorc + 2017-07-13T00:26:00.000Z + + + Tao Effect + 2017-07-13T01:15:00.000Z + + + Paul Sztorc + 2017-07-13T02:58:00.000Z + + + Tao Effect + 2017-07-13T03:24:00.000Z + + + Hampus Sjöberg + 2017-07-13T13:17:00.000Z + + + Paul Sztorc + 2017-07-13T15:39:00.000Z + + + Paul Sztorc + 2017-07-13T17:04:00.000Z + + @@ -99,13 +202,13 @@ - python-feedgen + 2 Combined summary - Drivechain -- Request for Discussion - 2023-08-01T20:40:46.011696+00:00 + 2025-09-26T15:56:54.517674+00:00 - In a Bitcoin-Dev mailing list, Paul Sztorc introduced the concept of "Blind Merged Mining" (BMM) as part of his work on "drivechain," a sidechain enabling technology. BMM allows SHA256^2 miners to merge-mine drivechains without running the actual sidechain software, ensuring that sidechains do not affect the fairness of mining. While not necessary for drivechain, BMM addresses some remaining concerns.However, Peter Todd raised concerns about the security properties of BMM, stating that it is weaker than his proposed solution in ZooKeyv. Todd explained that if miners do not validate sidechains, someone could bid the most for the chain and spam invalid headers for months, then withdraw all the coins deposited to the sidechain. Additionally, blind mining prevents miners from determining who should receive the funds. Todd also questioned the incentive for miners to upgrade to full nodes, considering the expenses and time involved.Sztorc has been working on drivechain for some time and provided technical information, changes to Bitcoin related to drivechain, and a blank sidechain template in the email. He has sought feedback at conferences and meetups, such as Scaling Milan, and plans to seek further input at Consensus2017 in New York City.The drivechain upgrade would remove the blocksize limit from the Bitcoin system by adding sidechains through a soft fork. Users who want a larger block Bitcoin can move their BTC to such a network, freeing up space in Bitcoin Core. This upgrade has significant scaling implications and may resolve the scalability debate by allowing users to scale as much as they want through sidechains.Sztorc's proposal includes Blind Merged Mining, which enables SHA256^2 miners to merge-mine drivechains without running the sidechain software. While not mandatory for drivechains, BMM addresses remaining concerns. The author also argues against the need for a maximum block size limit to ensure non-negligible transaction fees in the future.The author compares his drivechain proposal to a recent "Scaling Compromise," highlighting its advantages. Unlike the compromise, Sztorc's proposal does not require a hardfork and can quickly add any amount of extra blockspace. In contrast, the "Scaling Compromise" activates SegWit and then performs a hard fork to double the non-witness blockspace within 12 months.Sztorc acknowledges that those familiar with first and second-generation sidechain technology may find his approach different. He expresses pessimism about scalability discussions and suggests that individuals work on their passion projects until the problems are solved, disappear for other reasons, or until everyone agrees to stop discussing them. 2017-06-19T15:41:01+00:00 + In a Bitcoin-Dev mailing list, Paul Sztorc introduced the concept of "Blind Merged Mining" (BMM) as part of his work on "drivechain," a sidechain enabling technology. BMM allows SHA256^2 miners to merge-mine drivechains without running the actual sidechain software, ensuring that sidechains do not affect the fairness of mining. While not necessary for drivechain, BMM addresses some remaining concerns.However, Peter Todd raised concerns about the security properties of BMM, stating that it is weaker than his proposed solution in ZooKeyv. Todd explained that if miners do not validate sidechains, someone could bid the most for the chain and spam invalid headers for months, then withdraw all the coins deposited to the sidechain. Additionally, blind mining prevents miners from determining who should receive the funds. Todd also questioned the incentive for miners to upgrade to full nodes, considering the expenses and time involved.Sztorc has been working on drivechain for some time and provided technical information, changes to Bitcoin related to drivechain, and a blank sidechain template in the email. He has sought feedback at conferences and meetups, such as Scaling Milan, and plans to seek further input at Consensus2017 in New York City.The drivechain upgrade would remove the blocksize limit from the Bitcoin system by adding sidechains through a soft fork. Users who want a larger block Bitcoin can move their BTC to such a network, freeing up space in Bitcoin Core. This upgrade has significant scaling implications and may resolve the scalability debate by allowing users to scale as much as they want through sidechains.Sztorc's proposal includes Blind Merged Mining, which enables SHA256^2 miners to merge-mine drivechains without running the sidechain software. While not mandatory for drivechains, BMM addresses remaining concerns. The author also argues against the need for a maximum block size limit to ensure non-negligible transaction fees in the future.The author compares his drivechain proposal to a recent "Scaling Compromise," highlighting its advantages. Unlike the compromise, Sztorc's proposal does not require a hardfork and can quickly add any amount of extra blockspace. In contrast, the "Scaling Compromise" activates SegWit and then performs a hard fork to double the non-witness blockspace within 12 months.Sztorc acknowledges that those familiar with first and second-generation sidechain technology may find his approach different. He expresses pessimism about scalability discussions and suggests that individuals work on their passion projects until the problems are solved, disappear for other reasons, or until everyone agrees to stop discussing them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Drivechain-RfD-Follow-Up.xml b/static/bitcoin-dev/June_2017/combined_Drivechain-RfD-Follow-Up.xml index e2020bd9b6..c6cedb100a 100644 --- a/static/bitcoin-dev/June_2017/combined_Drivechain-RfD-Follow-Up.xml +++ b/static/bitcoin-dev/June_2017/combined_Drivechain-RfD-Follow-Up.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Drivechain RfD -- Follow Up - 2023-08-01T20:58:13.725682+00:00 + 2025-09-26T15:56:37.228317+00:00 + python-feedgen Paul Sztorc 2017-07-13 17:04:01+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Drivechain RfD -- Follow Up - 2023-08-01T20:58:13.725682+00:00 + 2025-09-26T15:56:37.228492+00:00 - The discussion in the provided context revolves around the security and implementation of drivechains, softforks, and P2SH transactions. Hampus Sjöberg argues that for softforks, 100% of nodes and miners need to upgrade to new rules to prevent chain splits, while for drivechains, only interested nodes validate the other chain. Paul Sztorc agrees but points out that even if some percentage of the network is validating both chains in drivechains, there will be no chain split if miners improperly withdraw from a sidechain. However, he expresses concern about the possibility of sidechain theft turning into a campaign.Greg raises concerns about theft in drivechains and discusses two different usages of the word "theft." He also questions whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes. Experts suggest that delayed withdrawal techniques in drivechains can mitigate the threat of theft_2. The email thread further delves into the security of WT^ transactions compared to P2SH and SegWit transactions. The author expresses doubt that the security of WT^ transactions can match that of P2SH and SegWit transactions.The discussion also highlights the different modes of use for drivechains, ranging from not upgrading Bitcoin software to actively using sidechains. It is emphasized that miners cannot steal funds in drivechains due to automatic enforcement policies enforced by full nodes. Another email exchange between Greg Slepak and Paul Sztorc explores the Drivechain project and its comparison with P2SH. The conversation clarifies four different modes of use for drivechains and addresses the issue of theft in drivechains. It is noted that the security of WT^ transactions can be brought up to the same level as P2SH and SegWit transactions.The conversation also touches upon the feasibility of using a proof-of-burn sidechain as an alternative to merged mining for increased security. Erik Aronesty suggests users would tolerate depreciation due to cheap and secure transactions, but Paul Sztorc counters that this scheme would be more expensive and relatively less secure. The discussion also covers the role of UTXO commitments for sidechains and the potential impact on the main chain's incentive structure. The lightning model is mentioned as a way to prevent further centralization.Overall, the email exchanges provide insights into the technical details, security models, and potential implications of drivechains, softforks, and P2SH transactions. The discussions highlight different perspectives on the security and implementation of these concepts, as well as potential challenges and alternative approaches.In addition to the above context, there is a discussion about the concept of a proof-of-burn sidechain, which requires burning Bitcoin or side-chain tokens to mine the side chain. The size of the burn determines the degree of security. Users can have a secure sidechain that issues a mining reward in sidechain tokens, which can be aggregated and redeemed for Bitcoins. However, any Bitcoins held in the sidechain depreciate in value at a rate of X% per year, which pays for increased security. This functions like an altcoin with high inflation and cheap transactions but is pegged to Bitcoin's price due to the pool of unredeemed Bitcoins held within the side chain.Drivechain is another sidechain enabling technology that seeks to plug many blockchains into the main chain, removing the blocksize limit and addressing scalability concerns. However, there are concerns about centralization and user choice of custodians. The discussion also raises questions about the potential impact on user control over their Bitcoins, as well as the correlation between network security and economic value.There is a debate around whether merged mining or proof-of-burn is a better solution for sidechain security. Some argue that proof-of-burn may result in users avoiding the sidechain due to the depreciation of their Bitcoins, while others believe merged mining would be more competitive. UTXO commitments are also suggested as a way to enhance the security of sidechains.The conversation explores various scenarios and considerations related to implementing Drivechain, including miner control, theft, antifragility, and the ecological impact. The participants recognize the need to balance innovation and security, ensuring that any changes made to the Bitcoin network do not compromise its integrity.Overall, the context provides insights into different perspectives on sidechain technologies and their implications for the Bitcoin ecosystem. It highlights the ongoing discussions and debates within the Bitcoin community regarding scalability, security, centralization, and user control.Furthermore, in the provided context, it is mentioned that there is an 8 MB maxblocksize, which doubles every two years. This implies that the maximum block size in a certain system is initially set at 8 MB, and then it will double in size every two years. The doubling of the maxblocksize every two years suggests a potential increase in the system's capacity to handle larger amounts of data. This can be seen as a measure to accommodate the growing demand for storage space and processing power in various applications 2017-07-13T17:04:01+00:00 + The discussion in the provided context revolves around the security and implementation of drivechains, softforks, and P2SH transactions. Hampus Sjöberg argues that for softforks, 100% of nodes and miners need to upgrade to new rules to prevent chain splits, while for drivechains, only interested nodes validate the other chain. Paul Sztorc agrees but points out that even if some percentage of the network is validating both chains in drivechains, there will be no chain split if miners improperly withdraw from a sidechain. However, he expresses concern about the possibility of sidechain theft turning into a campaign.Greg raises concerns about theft in drivechains and discusses two different usages of the word "theft." He also questions whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes. Experts suggest that delayed withdrawal techniques in drivechains can mitigate the threat of theft_2. The email thread further delves into the security of WT^ transactions compared to P2SH and SegWit transactions. The author expresses doubt that the security of WT^ transactions can match that of P2SH and SegWit transactions.The discussion also highlights the different modes of use for drivechains, ranging from not upgrading Bitcoin software to actively using sidechains. It is emphasized that miners cannot steal funds in drivechains due to automatic enforcement policies enforced by full nodes. Another email exchange between Greg Slepak and Paul Sztorc explores the Drivechain project and its comparison with P2SH. The conversation clarifies four different modes of use for drivechains and addresses the issue of theft in drivechains. It is noted that the security of WT^ transactions can be brought up to the same level as P2SH and SegWit transactions.The conversation also touches upon the feasibility of using a proof-of-burn sidechain as an alternative to merged mining for increased security. Erik Aronesty suggests users would tolerate depreciation due to cheap and secure transactions, but Paul Sztorc counters that this scheme would be more expensive and relatively less secure. The discussion also covers the role of UTXO commitments for sidechains and the potential impact on the main chain's incentive structure. The lightning model is mentioned as a way to prevent further centralization.Overall, the email exchanges provide insights into the technical details, security models, and potential implications of drivechains, softforks, and P2SH transactions. The discussions highlight different perspectives on the security and implementation of these concepts, as well as potential challenges and alternative approaches.In addition to the above context, there is a discussion about the concept of a proof-of-burn sidechain, which requires burning Bitcoin or side-chain tokens to mine the side chain. The size of the burn determines the degree of security. Users can have a secure sidechain that issues a mining reward in sidechain tokens, which can be aggregated and redeemed for Bitcoins. However, any Bitcoins held in the sidechain depreciate in value at a rate of X% per year, which pays for increased security. This functions like an altcoin with high inflation and cheap transactions but is pegged to Bitcoin's price due to the pool of unredeemed Bitcoins held within the side chain.Drivechain is another sidechain enabling technology that seeks to plug many blockchains into the main chain, removing the blocksize limit and addressing scalability concerns. However, there are concerns about centralization and user choice of custodians. The discussion also raises questions about the potential impact on user control over their Bitcoins, as well as the correlation between network security and economic value.There is a debate around whether merged mining or proof-of-burn is a better solution for sidechain security. Some argue that proof-of-burn may result in users avoiding the sidechain due to the depreciation of their Bitcoins, while others believe merged mining would be more competitive. UTXO commitments are also suggested as a way to enhance the security of sidechains.The conversation explores various scenarios and considerations related to implementing Drivechain, including miner control, theft, antifragility, and the ecological impact. The participants recognize the need to balance innovation and security, ensuring that any changes made to the Bitcoin network do not compromise its integrity.Overall, the context provides insights into different perspectives on sidechain technologies and their implications for the Bitcoin ecosystem. It highlights the ongoing discussions and debates within the Bitcoin community regarding scalability, security, centralization, and user control.Furthermore, in the provided context, it is mentioned that there is an 8 MB maxblocksize, which doubles every two years. This implies that the maximum block size in a certain system is initially set at 8 MB, and then it will double in size every two years. The doubling of the maxblocksize every two years suggests a potential increase in the system's capacity to handle larger amounts of data. This can be seen as a measure to accommodate the growing demand for storage space and processing power in various applications - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Hypothetical-2-MB-hardfork-to-follow-BIP148.xml b/static/bitcoin-dev/June_2017/combined_Hypothetical-2-MB-hardfork-to-follow-BIP148.xml index 3eb6fdc38a..0b4eb84d7a 100644 --- a/static/bitcoin-dev/June_2017/combined_Hypothetical-2-MB-hardfork-to-follow-BIP148.xml +++ b/static/bitcoin-dev/June_2017/combined_Hypothetical-2-MB-hardfork-to-follow-BIP148.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Hypothetical 2 MB hardfork to follow BIP148 - 2023-08-01T20:46:29.371616+00:00 - - Nathan Cook 2017-06-12 16:27:14+00:00 - - - Jared Lee Richardson 2017-06-02 19:40:36+00:00 - - - Luke Dashjr 2017-05-31 04:14:25+00:00 - - - Jacob Eliosoff 2017-05-31 03:07:43+00:00 - - - Jorge Timón 2017-05-31 01:22:44+00:00 - - - Jean-Paul Kogelman 2017-05-31 01:09:26+00:00 - - - James MacWhyte 2017-05-30 23:50:01+00:00 - - - Jorge Timón 2017-05-30 22:26:20+00:00 - - - Mark Friedenbach 2017-05-30 21:24:20+00:00 - - - Jacob Eliosoff 2017-05-30 20:10:04+00:00 - - - Jorge Timón 2017-05-30 13:27:58+00:00 - - - Erik Aronesty 2017-05-23 23:07:41+00:00 - - - Luke Dashjr 2017-05-23 20:23:40+00:00 - + 2025-09-26T15:56:58.768681+00:00 + python-feedgen + + + [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 Luke Dashjr + 2017-05-23T20:23:00.000Z + + + Erik Aronesty + 2017-05-23T23:07:00.000Z + + + Jorge Timón + 2017-05-30T13:27:00.000Z + + + Jacob Eliosoff + 2017-05-30T20:10:00.000Z + + + Mark Friedenbach + 2017-05-30T21:24:00.000Z + + + Jorge Timón + 2017-05-30T22:26:00.000Z + + + James MacWhyte + 2017-05-30T23:50:00.000Z + + + Jean-Paul Kogelman + 2017-05-31T01:09:00.000Z + + + Jorge Timón + 2017-05-31T01:22:00.000Z + + + Jacob Eliosoff + 2017-05-31T03:07:00.000Z + + + Luke Dashjr + 2017-05-31T04:14:00.000Z + + + Jared Lee Richardson + 2017-06-02T19:40:00.000Z + + + Nathan Cook + 2017-06-12T16:27:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Hypothetical 2 MB hardfork to follow BIP148 - 2023-08-01T20:46:29.371616+00:00 + 2025-09-26T15:56:58.770179+00:00 - The discussion on the bitcoin-dev mailing list revolves around the need for a transaction size limit to address the quadratic hashing problem. Various proposals have been made, including adding a transaction-size limit of 10kb or 100kb, reducing the block size limit to 1MB initially and then dropping it to 500kb or 100kb at a later block height, and implementing a real 2MB block size hardfork following Segwit BIP148 activation.One proposed change suggests enforcing a block size limit of 2,000,000 bytes upon activation, while keeping the block weight limit at 4,000,000 WU. The proposal eliminates the witness commitment in the generation transaction and replaces it with a hash of the witness reserved value, the witness merkle root hash, and the transaction ID merkle root hash. Additionally, the maximum size of a transaction without witness data is limited to 1 MB.Although this proposal is considered risky and is not endorsed by the author, it provides a possible option for a 2 MB block size hardfork following Segwit BIP148 activation. However, deploying this proposal would require consensus from the entire Bitcoin community and is scheduled for 18 months after the creation date of the BIP.The proposed change enforces a block size limit of 2 MB for legacy Bitcoin transactions, with a corresponding block weight limit of 4000000 WU. The calculation of block weight is modified, assigning a weight of 1 WU to all witness data and 4 WU to all other data. As a result, the witness commitment in the generation transaction is no longer required. Instead, the txid merkle root in the block header is replaced with a hash of the witness reserved value, the witness merkle root hash, and the transaction ID merkle root hash.This proposal is set to be deployed on a flag day, which is the block where the median-past time surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC). It assumes that Segwit has already been activated through BIP141 and/or BIP148. It's important to note that this change represents a hardfork and is not backward compatible. Therefore, it should not be deployed without the consent of the entire Bitcoin community.Activation of this proposal is scheduled for 18 months from the creation date of this BIP. The intention behind this timeline is to provide 6 months to establish consensus and 12 months for deployment. The author has left the motivation and rationale sections blank, urging whoever champions this proposal to complete them. 2017-06-12T16:27:14+00:00 + The discussion on the bitcoin-dev mailing list revolves around the need for a transaction size limit to address the quadratic hashing problem. Various proposals have been made, including adding a transaction-size limit of 10kb or 100kb, reducing the block size limit to 1MB initially and then dropping it to 500kb or 100kb at a later block height, and implementing a real 2MB block size hardfork following Segwit BIP148 activation.One proposed change suggests enforcing a block size limit of 2,000,000 bytes upon activation, while keeping the block weight limit at 4,000,000 WU. The proposal eliminates the witness commitment in the generation transaction and replaces it with a hash of the witness reserved value, the witness merkle root hash, and the transaction ID merkle root hash. Additionally, the maximum size of a transaction without witness data is limited to 1 MB.Although this proposal is considered risky and is not endorsed by the author, it provides a possible option for a 2 MB block size hardfork following Segwit BIP148 activation. However, deploying this proposal would require consensus from the entire Bitcoin community and is scheduled for 18 months after the creation date of the BIP.The proposed change enforces a block size limit of 2 MB for legacy Bitcoin transactions, with a corresponding block weight limit of 4000000 WU. The calculation of block weight is modified, assigning a weight of 1 WU to all witness data and 4 WU to all other data. As a result, the witness commitment in the generation transaction is no longer required. Instead, the txid merkle root in the block header is replaced with a hash of the witness reserved value, the witness merkle root hash, and the transaction ID merkle root hash.This proposal is set to be deployed on a flag day, which is the block where the median-past time surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC). It assumes that Segwit has already been activated through BIP141 and/or BIP148. It's important to note that this change represents a hardfork and is not backward compatible. Therefore, it should not be deployed without the consent of the entire Bitcoin community.Activation of this proposal is scheduled for 18 months from the creation date of this BIP. The intention behind this timeline is to provide 6 months to establish consensus and 12 months for deployment. The author has left the motivation and rationale sections blank, urging whoever champions this proposal to complete them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Miners-forced-to-run-non-core-code-in-order-to-get-segwit-activated.xml b/static/bitcoin-dev/June_2017/combined_Miners-forced-to-run-non-core-code-in-order-to-get-segwit-activated.xml index dafe0bf749..79a797146d 100644 --- a/static/bitcoin-dev/June_2017/combined_Miners-forced-to-run-non-core-code-in-order-to-get-segwit-activated.xml +++ b/static/bitcoin-dev/June_2017/combined_Miners-forced-to-run-non-core-code-in-order-to-get-segwit-activated.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Miners forced to run non-core code in order to get segwit activated - 2023-08-01T21:10:55.363692+00:00 - - Erik Aronesty 2017-06-27 19:26:35+00:00 - - - Jorge Timón 2017-06-27 16:31:26+00:00 - - - Sergio Demian Lerner 2017-06-27 15:42:53+00:00 - - - Jacob Eliosoff 2017-06-21 04:05:53+00:00 - - - Mark Friedenbach 2017-06-21 02:11:15+00:00 - - - Erik Aronesty 2017-06-21 01:36:49+00:00 - - - Jacob Eliosoff 2017-06-20 23:01:14+00:00 - - - Jacob Eliosoff 2017-06-20 22:57:34+00:00 - - - Hampus Sjöberg 2017-06-20 22:53:29+00:00 - - - Mark Friedenbach 2017-06-20 22:48:23+00:00 - - - Gregory Maxwell 2017-06-20 22:34:29+00:00 - - - Jacob Eliosoff 2017-06-20 22:29:27+00:00 - - - Hampus Sjöberg 2017-06-20 22:15:59+00:00 - - - Gregory Maxwell 2017-06-20 21:49:50+00:00 - - - Ryan J Martin 2017-06-20 19:49:57+00:00 - - - Mark Friedenbach 2017-06-20 17:22:18+00:00 - - - Hampus Sjöberg 2017-06-20 16:49:38+00:00 - - - Erik Aronesty 2017-06-20 15:44:36+00:00 - + 2025-09-26T15:56:35.072659+00:00 + python-feedgen + + + [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated Erik Aronesty + 2017-06-20T15:44:00.000Z + + + Hampus Sjöberg + 2017-06-20T16:49:00.000Z + + + Mark Friedenbach + 2017-06-20T17:22:00.000Z + + + Ryan J Martin + 2017-06-20T19:49:00.000Z + + + Gregory Maxwell + 2017-06-20T21:49:00.000Z + + + Hampus Sjöberg + 2017-06-20T22:15:00.000Z + + + Jacob Eliosoff + 2017-06-20T22:29:00.000Z + + + Gregory Maxwell + 2017-06-20T22:34:00.000Z + + + Mark Friedenbach + 2017-06-20T22:48:00.000Z + + + Hampus Sjöberg + 2017-06-20T22:53:00.000Z + + + Jacob Eliosoff + 2017-06-20T22:57:00.000Z + + + Jacob Eliosoff + 2017-06-20T23:01:00.000Z + + + Erik Aronesty + 2017-06-21T01:36:00.000Z + + + Mark Friedenbach + 2017-06-21T02:11:00.000Z + + + Jacob Eliosoff + 2017-06-21T04:05:00.000Z + + + Sergio Demian Lerner + 2017-06-27T15:42:00.000Z + + + Jorge Timón + 2017-06-27T16:31:00.000Z + + + Erik Aronesty + 2017-06-27T19:26:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Miners forced to run non-core code in order to get segwit activated - 2023-08-01T21:10:55.363692+00:00 + 2025-09-26T15:56:35.074692+00:00 - In the ongoing debate over the activation of the Segwit upgrade to the Bitcoin network, there is a possibility that miners may have to choose between two options - BIP148 and Segwit2x. However, there are concerns that some miners are signaling for Segwit2x without signaling for segwit, which is required. The technical community is largely rejecting Segwit2x, and its definition keeps changing without clear specification. This has led to worries that miners may feel forced to run non-reference software in order to prevent a chain split due to lack of support from Bitcoin Core.There is disagreement among miners about whether to choose BIP148 or Segwit2x to activate Segwit. While most Segwit2x signaling miners are reportedly faking it by not signaling for segwit, it is believed that they will start to signal properly when the time comes. However, the rejection of segwit2x by Bitcoin's developers is strong, and there is concern that miners interpreting the situation as being forced to run non-reference software could lead to a one-way street situation.In response, Gregory Maxwell suggests that miners who support segwit can continue signaling it, which would make them soft-fork compatible with BIP148 and BIP91. However, there is still concern about the lack of consensus among miners and the potential for a chain split.The bitcoin-dev mailing list serves as a forum for developers and technical experts in the Bitcoin community to exchange ideas and discuss issues related to the protocol. It has played an important role in shaping the future of Bitcoin, including the ongoing discussions around the implementation of SegWit2x. The mailing list is open to anyone who wishes to subscribe and provides a platform for technical debates and collaboration. Developers have been requesting the SegWit2x development team to provide a BIP for evaluation by the Bitcoin Core team.Overall, the implementation of SegWit2x and the activation of SegWit are complex and ongoing processes that involve collaboration and evaluation among developers. There is still uncertainty about how these developments will play out and whether they will lead to a chain split. The concerns raised by developers about the centralization of power among large mining pools and the need for miners to run non-reference software add to the complexity of the situation. The bitcoin-dev mailing list and the Linux Foundation platform serve as crucial resources for developers working on the Bitcoin network to communicate and collaborate on these issues.It remains unclear how the split will play out and how the two chains will match up. It is likely that if Segwit is activated before August 1st, there will be no split on that day. However, if activation is through Segwit2x and some nodes follow through with a hard fork three months later while others do not, a split will occur in September or October. There is concern about orphaned miners who do not run a Segwit2x node or signal for segwit, but it is believed that the split will not be long-lasting due to the majority hashrate support for segwit2x. The debate highlights the importance of considering the perspectives and needs of different stakeholders in the decision-making process and finding a solution that benefits everyone involved. 2017-06-27T19:26:35+00:00 + In the ongoing debate over the activation of the Segwit upgrade to the Bitcoin network, there is a possibility that miners may have to choose between two options - BIP148 and Segwit2x. However, there are concerns that some miners are signaling for Segwit2x without signaling for segwit, which is required. The technical community is largely rejecting Segwit2x, and its definition keeps changing without clear specification. This has led to worries that miners may feel forced to run non-reference software in order to prevent a chain split due to lack of support from Bitcoin Core.There is disagreement among miners about whether to choose BIP148 or Segwit2x to activate Segwit. While most Segwit2x signaling miners are reportedly faking it by not signaling for segwit, it is believed that they will start to signal properly when the time comes. However, the rejection of segwit2x by Bitcoin's developers is strong, and there is concern that miners interpreting the situation as being forced to run non-reference software could lead to a one-way street situation.In response, Gregory Maxwell suggests that miners who support segwit can continue signaling it, which would make them soft-fork compatible with BIP148 and BIP91. However, there is still concern about the lack of consensus among miners and the potential for a chain split.The bitcoin-dev mailing list serves as a forum for developers and technical experts in the Bitcoin community to exchange ideas and discuss issues related to the protocol. It has played an important role in shaping the future of Bitcoin, including the ongoing discussions around the implementation of SegWit2x. The mailing list is open to anyone who wishes to subscribe and provides a platform for technical debates and collaboration. Developers have been requesting the SegWit2x development team to provide a BIP for evaluation by the Bitcoin Core team.Overall, the implementation of SegWit2x and the activation of SegWit are complex and ongoing processes that involve collaboration and evaluation among developers. There is still uncertainty about how these developments will play out and whether they will lead to a chain split. The concerns raised by developers about the centralization of power among large mining pools and the need for miners to run non-reference software add to the complexity of the situation. The bitcoin-dev mailing list and the Linux Foundation platform serve as crucial resources for developers working on the Bitcoin network to communicate and collaborate on these issues.It remains unclear how the split will play out and how the two chains will match up. It is likely that if Segwit is activated before August 1st, there will be no split on that day. However, if activation is through Segwit2x and some nodes follow through with a hard fork three months later while others do not, a split will occur in September or October. There is concern about orphaned miners who do not run a Segwit2x node or signal for segwit, but it is believed that the split will not be long-lasting due to the majority hashrate support for segwit2x. The debate highlights the importance of considering the perspectives and needs of different stakeholders in the decision-making process and finding a solution that benefits everyone involved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Proposal-Demonstration-of-Phase-in-Full-Network-Upgrade-Activated-by-Miners.xml b/static/bitcoin-dev/June_2017/combined_Proposal-Demonstration-of-Phase-in-Full-Network-Upgrade-Activated-by-Miners.xml index e6d36f2660..fc1b15562d 100644 --- a/static/bitcoin-dev/June_2017/combined_Proposal-Demonstration-of-Phase-in-Full-Network-Upgrade-Activated-by-Miners.xml +++ b/static/bitcoin-dev/June_2017/combined_Proposal-Demonstration-of-Phase-in-Full-Network-Upgrade-Activated-by-Miners.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners - 2023-08-01T21:07:40.604251+00:00 - - Zheming Lin 2017-07-22 03:58:21+00:00 - - - Zheming Lin 2017-06-16 14:39:26+00:00 - - - Eric Voskuil 2017-06-16 03:09:33+00:00 - - - Erik Aronesty 2017-06-15 18:38:57+00:00 - - - Eric Voskuil 2017-06-15 05:04:30+00:00 - - - Jameson Lopp 2017-06-14 20:11:07+00:00 - - - Zheming Lin 2017-06-14 19:04:21+00:00 - - - Jameson Lopp 2017-06-14 18:55:04+00:00 - - - Zheming Lin 2017-06-14 18:30:32+00:00 - - - Zheming Lin 2017-06-14 18:29:35+00:00 - - - Jameson Lopp 2017-06-14 17:20:32+00:00 - - - Zheming Lin 2017-06-14 16:39:42+00:00 - - - Jared Lee Richardson 2017-06-14 01:08:49+00:00 - - - James Hilliard 2017-06-14 00:23:06+00:00 - - - Jared Lee Richardson 2017-06-13 19:35:13+00:00 - - - Gregory Maxwell 2017-06-13 18:11:39+00:00 - - - James Hilliard 2017-06-13 10:20:11+00:00 - - - James Hilliard 2017-06-13 08:37:43+00:00 - - - Zheming Lin 2017-06-13 08:24:41+00:00 - - - Zheming Lin 2017-06-13 08:13:58+00:00 - - - James Hilliard 2017-06-13 07:19:24+00:00 - - - Zheming Lin 2017-06-13 06:50:26+00:00 - - - James Hilliard 2017-06-13 05:44:23+00:00 - - - Zheming Lin 2017-06-13 02:23:41+00:00 - + 2025-09-26T15:56:45.881527+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners Zheming Lin + 2017-06-13T02:23:00.000Z + + + James Hilliard + 2017-06-13T05:44:00.000Z + + + Zheming Lin + 2017-06-13T06:50:00.000Z + + + James Hilliard + 2017-06-13T07:19:00.000Z + + + Zheming Lin + 2017-06-13T08:13:00.000Z + + + Zheming Lin + 2017-06-13T08:24:00.000Z + + + James Hilliard + 2017-06-13T08:37:00.000Z + + + James Hilliard + 2017-06-13T10:20:00.000Z + + + Gregory Maxwell + 2017-06-13T18:11:00.000Z + + + Jared Lee Richardson + 2017-06-13T19:35:00.000Z + + + James Hilliard + 2017-06-14T00:23:00.000Z + + + Jared Lee Richardson + 2017-06-14T01:08:00.000Z + + + Zheming Lin + 2017-06-14T16:39:00.000Z + + + Jameson Lopp + 2017-06-14T17:20:00.000Z + + + Zheming Lin + 2017-06-14T18:29:00.000Z + + + Zheming Lin + 2017-06-14T18:30:00.000Z + + + Jameson Lopp + 2017-06-14T18:55:00.000Z + + + Zheming Lin + 2017-06-14T19:04:00.000Z + + + Jameson Lopp + 2017-06-14T20:11:00.000Z + + + Eric Voskuil + 2017-06-15T05:04:00.000Z + + + Erik Aronesty + 2017-06-15T18:38:00.000Z + + + Eric Voskuil + 2017-06-16T03:09:00.000Z + + + Zheming Lin + 2017-06-16T14:39:00.000Z + + + Zheming Lin + 2017-07-22T03:58:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners - 2023-08-01T21:07:40.604251+00:00 + 2025-09-26T15:56:45.884124+00:00 - In an email conversation among bitcoin developers, the topic of upgrading consensus rules was discussed. It was noted that if miners are passive or veto the activation of new rules, users have the option to refuse blocks that don't show readiness for enforcing the new rules. The discussion also touched on the issue of user choice and whether users should trust the majority of miners or not. It was emphasized that Bitcoin is a market, and users can choose to follow the miners or fork away if they don't trust them. The importance of not relying solely on miners when it comes to choosing consensus rules was highlighted.The proposed protocol upgrade involves using versionbits to define support signals for mining nodes, with tx version used to define current transactions. The deployment will occur in three stages, with an optional fourth stage for integrating codes of the protocol upgrade. Once activated by majority miner signal, mining nodes will orphan blocks with old versionbits and only new versionbit transactions will be allowed after two grace periods. Non-mining nodes have time to upgrade their software during the first two grace periods. The ledger in non-mining wallet nodes is honored and reserved, but users of off-chain wallet services can decide whether or not to follow service providers after receiving notification. Future protocol upgrades can be bonded with node upgrades and activated through miner votes.A new method for activating soft forks called "false signalling" has been proposed by the Bitcoin development team. This method suggests that non-mining nodes should upgrade their software assuming all signals are true. However, it may not be viable for controversial changes. Users will consider market factors when deciding what to do, and the total number of nodes does not necessarily indicate economic and user support.The benefits of the proposed protocol upgrade include incentivizing miners and non-mining nodes to upgrade, ensuring asset security for wallet nodes, and phasing in upgrades under the Nakamoto Consensus. However, there are risks associated with validationless mining, false signaling from miners, and collusion between miners and non-mining nodes. The implementation details of the proposed method are yet to be determined.Overall, the proposed protocol upgrade process aims to ensure that all miners and non-mining nodes upgrade by implementing a phased approach and utilizing majority miner signal. It provides incentives for upgrading, protects asset security, and minimizes the risk of delaying network upgrades. However, there are still challenges and risks that need to be addressed in the implementation.Nodes in the SPY network have the opportunity to upgrade their software as versionbits in the block header do not affect mining. However, after two grace periods, all nodes must be upgraded in order to send transactions and receive confirmations. This requirement is no worse than before and ensures that the ledger in non-mining wallet nodes is respected. Users of off-chain wallet services can choose whether or not to follow the service providers after receiving public notification. Future protocol upgrades can be linked with node upgrades, allowing for sufficient time for nodes to support new protocols. Even if there is a failure in miner activation, the situation will not worsen and the current state will remain stable.The fluctuation of hashing power can impact the longest chain, so having higher activation requirements reduces the risk of temporary forks. It is possible for miners to falsely signal to avoid being orphaned, but non-mining wallet nodes are unable to distinguish between true and false signals. Therefore, non-mining wallet nodes should upgrade assuming all signals are true, and miners signaling false signals should follow suit once all non-mining nodes have upgraded. Non-mining wallet nodes also have the ability to falsely signal without supporting the new protocol. However, genuine nodes should follow the result provided by miners' votes. While it is possible for miners and non-mining nodes to conspire to fork using the old protocol consensus, this possibility cannot be eliminated. Upgrading most passive non-mining nodes reduces their benefit in such scenarios.Transactions from non-mining nodes will not be affected, and there will be ample time for them to upgrade their wallet software. Future protocol upgrades can be independently activated by merging protocol upgrade codes with the upgraded client version and conducting a separate activation vote. This approach ensures that enough time is given for nodes to upgrade their software and support the new protocol, even if the miner vote fails to activate it. 2017-07-22T03:58:21+00:00 + In an email conversation among bitcoin developers, the topic of upgrading consensus rules was discussed. It was noted that if miners are passive or veto the activation of new rules, users have the option to refuse blocks that don't show readiness for enforcing the new rules. The discussion also touched on the issue of user choice and whether users should trust the majority of miners or not. It was emphasized that Bitcoin is a market, and users can choose to follow the miners or fork away if they don't trust them. The importance of not relying solely on miners when it comes to choosing consensus rules was highlighted.The proposed protocol upgrade involves using versionbits to define support signals for mining nodes, with tx version used to define current transactions. The deployment will occur in three stages, with an optional fourth stage for integrating codes of the protocol upgrade. Once activated by majority miner signal, mining nodes will orphan blocks with old versionbits and only new versionbit transactions will be allowed after two grace periods. Non-mining nodes have time to upgrade their software during the first two grace periods. The ledger in non-mining wallet nodes is honored and reserved, but users of off-chain wallet services can decide whether or not to follow service providers after receiving notification. Future protocol upgrades can be bonded with node upgrades and activated through miner votes.A new method for activating soft forks called "false signalling" has been proposed by the Bitcoin development team. This method suggests that non-mining nodes should upgrade their software assuming all signals are true. However, it may not be viable for controversial changes. Users will consider market factors when deciding what to do, and the total number of nodes does not necessarily indicate economic and user support.The benefits of the proposed protocol upgrade include incentivizing miners and non-mining nodes to upgrade, ensuring asset security for wallet nodes, and phasing in upgrades under the Nakamoto Consensus. However, there are risks associated with validationless mining, false signaling from miners, and collusion between miners and non-mining nodes. The implementation details of the proposed method are yet to be determined.Overall, the proposed protocol upgrade process aims to ensure that all miners and non-mining nodes upgrade by implementing a phased approach and utilizing majority miner signal. It provides incentives for upgrading, protects asset security, and minimizes the risk of delaying network upgrades. However, there are still challenges and risks that need to be addressed in the implementation.Nodes in the SPY network have the opportunity to upgrade their software as versionbits in the block header do not affect mining. However, after two grace periods, all nodes must be upgraded in order to send transactions and receive confirmations. This requirement is no worse than before and ensures that the ledger in non-mining wallet nodes is respected. Users of off-chain wallet services can choose whether or not to follow the service providers after receiving public notification. Future protocol upgrades can be linked with node upgrades, allowing for sufficient time for nodes to support new protocols. Even if there is a failure in miner activation, the situation will not worsen and the current state will remain stable.The fluctuation of hashing power can impact the longest chain, so having higher activation requirements reduces the risk of temporary forks. It is possible for miners to falsely signal to avoid being orphaned, but non-mining wallet nodes are unable to distinguish between true and false signals. Therefore, non-mining wallet nodes should upgrade assuming all signals are true, and miners signaling false signals should follow suit once all non-mining nodes have upgraded. Non-mining wallet nodes also have the ability to falsely signal without supporting the new protocol. However, genuine nodes should follow the result provided by miners' votes. While it is possible for miners and non-mining nodes to conspire to fork using the old protocol consensus, this possibility cannot be eliminated. Upgrading most passive non-mining nodes reduces their benefit in such scenarios.Transactions from non-mining nodes will not be affected, and there will be ample time for them to upgrade their wallet software. Future protocol upgrades can be independently activated by merging protocol upgrade codes with the upgraded client version and conducting a separate activation vote. This approach ensures that enough time is given for nodes to upgrade their software and support the new protocol, even if the miner vote fails to activate it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Replay-attacks-make-BIP148-and-BIP149-untennable.xml b/static/bitcoin-dev/June_2017/combined_Replay-attacks-make-BIP148-and-BIP149-untennable.xml index bcff45666d..654d9f2bb3 100644 --- a/static/bitcoin-dev/June_2017/combined_Replay-attacks-make-BIP148-and-BIP149-untennable.xml +++ b/static/bitcoin-dev/June_2017/combined_Replay-attacks-make-BIP148-and-BIP149-untennable.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Replay attacks make BIP148 and BIP149 untennable - 2023-08-01T20:53:59.766266+00:00 - - Nick Johnson 2017-06-08 06:38:48+00:00 - - - Conner Fromknecht 2017-06-08 05:44:40+00:00 - - - Nick Johnson 2017-06-07 17:35:17+00:00 - - - Tao Effect 2017-06-07 16:27:03+00:00 - - - Nick Johnson 2017-06-07 13:25:35+00:00 - - - Kekcoin 2017-06-07 00:46:23+00:00 - - - Tao Effect 2017-06-07 00:38:02+00:00 - - - Kekcoin 2017-06-07 00:29:08+00:00 - - - Tao Effect 2017-06-07 00:26:50+00:00 - - - Kekcoin 2017-06-07 00:19:18+00:00 - - - Tao Effect 2017-06-07 00:04:29+00:00 - - - Kekcoin 2017-06-06 23:59:19+00:00 - - - Tao Effect 2017-06-06 23:31:17+00:00 - - - Tao Effect 2017-06-06 23:27:33+00:00 - - - Anthony Towns 2017-06-06 23:20:15+00:00 - - - Tao Effect 2017-06-06 23:19:39+00:00 - - - Tao Effect 2017-06-06 23:12:26+00:00 - - - Luke Dashjr 2017-06-06 23:08:11+00:00 - - - Gregory Maxwell 2017-06-06 23:02:06+00:00 - - - Tao Effect 2017-06-06 22:39:28+00:00 - - - Tao Effect 2017-06-06 20:43:25+00:00 - + 2025-09-26T15:57:11.648431+00:00 + python-feedgen + + + Tao Effect + 2017-06-06T20:43:00.000Z + + + [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable Tao Effect + 2017-06-06T22:39:00.000Z + + + Gregory Maxwell + 2017-06-06T23:02:00.000Z + + + Luke Dashjr + 2017-06-06T23:08:00.000Z + + + Tao Effect + 2017-06-06T23:12:00.000Z + + + Tao Effect + 2017-06-06T23:19:00.000Z + + + Anthony Towns + 2017-06-06T23:20:00.000Z + + + Tao Effect + 2017-06-06T23:27:00.000Z + + + Tao Effect + 2017-06-06T23:31:00.000Z + + + Kekcoin + 2017-06-06T23:59:00.000Z + + + Tao Effect + 2017-06-07T00:04:00.000Z + + + Kekcoin + 2017-06-07T00:19:00.000Z + + + Tao Effect + 2017-06-07T00:26:00.000Z + + + Kekcoin + 2017-06-07T00:29:00.000Z + + + Tao Effect + 2017-06-07T00:38:00.000Z + + + Kekcoin + 2017-06-07T00:46:00.000Z + + + Nick Johnson + 2017-06-07T13:25:00.000Z + + + Tao Effect + 2017-06-07T16:27:00.000Z + + + Nick Johnson + 2017-06-07T17:35:00.000Z + + + Conner Fromknecht + 2017-06-08T05:44:00.000Z + + + Nick Johnson + 2017-06-08T06:38:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Replay attacks make BIP148 and BIP149 untennable - 2023-08-01T20:53:59.766266+00:00 + 2025-09-26T15:57:11.650390+00:00 - In a recent discussion on the bitcoin-dev mailing list, the Ethereum hard fork was a central topic of debate. Conner Fromknecht argued that the security of any cryptocurrency depends on its ledger and that any alterations made outside of the ledger's rules compromise its security. He equated an "irregular state change" to modifying the underlying ledger. Nick Johnson countered this argument by stating that while an irregular state change was indeed added at a specific block height during the Ethereum hard fork, the ledger itself was not edited. Tao Effect criticized Johnson for not understanding the severity of replay attacks in Bitcoin. Gregory Maxwell accused Ethereum of editing their ledger for the benefit of its centralized administrators, but Johnson reiterated that the Ethereum ledger remained unchanged.The discussion then shifted to the bitcoin-dev mailing list, where the focus was on the security and integrity of cryptocurrencies' ledgers and how they should be defined and maintained. Conner and Nick debated whether a cryptocurrency's state should only be defined by its ledger. Nick clarified that the Ethereum ledger was not edited during the DAO hard fork, but rather an irregular state change was added at a specific block height. Gregory Maxwell took issue with Tao Effect's assertion about the lack of experience in the bitcoin community regarding replay attacks and warned against insulting the community. The conversation also touched on the severity of replay attacks in the Bitcoin community and the lack of experience in dealing with them.Tao Effect sent an email to Nick Johnson to clarify that only an irregular state change was added at a specific block height in the Ethereum hard fork and the ledger remained unchanged. Gregory Maxwell cautioned against insulting the Bitcoin community and accused Ethereum of editing their ledger for the benefit of its centralized administrators. However, Johnson reiterated that the Ethereum ledger was not edited. The conversation also addressed the severity of replay attacks in the Bitcoin community and the lack of experience in dealing with them.Another email thread focused on the security concerns surrounding BIP148 and BIP149. Kekcoin suggested using "post-split coinbases from the legacy chain" as seedcoins for cointainting purposes to mitigate these concerns. The discussion then turned to replay attacks and their potential threat. Tao Effect expressed concerns about the lack of replay protection and its serious implications. They suggested that since BIP148 required over 51% support to succeed, it could adopt a similar approach to SegWit or lower the threshold to 80% as BIP91 did. Kekcoin argued that the replay threat would be irrelevant as there would be no alternative chain to replay transactions on. They claimed that the non-148 chain would have been reorganized into oblivion.The email exchange delved further into the discussion on replay attacks and proposed solutions to prevent them. Kekcoin argued that using "post-chainsplit coinbases from the non-148 chain" was more secure in extreme-adversarial cases such as secret-mining reorg attacks. Tao Effect expressed confusion about Kekcoin's statement regarding the mootness of the replay threat if the non-148 chain faced a large-scale reorganization. The recipient clarified that without replay protection, the threat of replay attacks is always present and very serious.In another email thread, Tao Effect expressed concern about the lack of understanding and discussion surrounding the severity of replay attacks within the Bitcoin community. They attributed this lack of awareness to the community's limited experience with such attacks. While replay attacks have been resolved, there is room for improvement in terms of simplicity and effectiveness. The proposed coin-splitting techniques suggested by BIP148 were deemed complex, risky, and lacking guaranteed success. Additionally, using 148 coinbase transactions for mixing compromised fungibility. The absence of replay protection not only threatens the main chain but also any potential legacy chains created by malicious miners, rendering their coins invalid on the main chain.In response to Tao Effect's concerns, another member of the Bitcoin community emphasized that replay attack issues were previously addressed during discussions surrounding Ethereum's hard fork. The limited dialogue on these matters is attributed to engineers prioritizing stability and not considering BIP148 as a viable solution. However, these concerns apply to all hard fork proposals, possibly even more strongly. It was noted that replay attacks are not the most significant technical challenge; network partitioning presents a larger obstacle. BIP149, with its timeframe allowing for addressing replay attacks and other issues, may avoid the need for a significant fork altogether.Greg Slepak objected to BIP148 and BIP149 based on their involvement in the ETH/ETC hard fork. They acknowledged the differences between the situations, as the ETC/ETH hard fork resulted in two incompatible chains, unlike BIP148 and other soft forks. However, both scenarios are susceptible to replay attacks. Slepak advised caution and suggested refraining from sharing sensitive information via email if there are concerns about access by the NSA.The author of an email expressed uncertainty about the meaning of "render the replay threat moot," and the recipient clarified that without replay protection, the threat of 2017-06-08T06:38:48+00:00 + In a recent discussion on the bitcoin-dev mailing list, the Ethereum hard fork was a central topic of debate. Conner Fromknecht argued that the security of any cryptocurrency depends on its ledger and that any alterations made outside of the ledger's rules compromise its security. He equated an "irregular state change" to modifying the underlying ledger. Nick Johnson countered this argument by stating that while an irregular state change was indeed added at a specific block height during the Ethereum hard fork, the ledger itself was not edited. Tao Effect criticized Johnson for not understanding the severity of replay attacks in Bitcoin. Gregory Maxwell accused Ethereum of editing their ledger for the benefit of its centralized administrators, but Johnson reiterated that the Ethereum ledger remained unchanged.The discussion then shifted to the bitcoin-dev mailing list, where the focus was on the security and integrity of cryptocurrencies' ledgers and how they should be defined and maintained. Conner and Nick debated whether a cryptocurrency's state should only be defined by its ledger. Nick clarified that the Ethereum ledger was not edited during the DAO hard fork, but rather an irregular state change was added at a specific block height. Gregory Maxwell took issue with Tao Effect's assertion about the lack of experience in the bitcoin community regarding replay attacks and warned against insulting the community. The conversation also touched on the severity of replay attacks in the Bitcoin community and the lack of experience in dealing with them.Tao Effect sent an email to Nick Johnson to clarify that only an irregular state change was added at a specific block height in the Ethereum hard fork and the ledger remained unchanged. Gregory Maxwell cautioned against insulting the Bitcoin community and accused Ethereum of editing their ledger for the benefit of its centralized administrators. However, Johnson reiterated that the Ethereum ledger was not edited. The conversation also addressed the severity of replay attacks in the Bitcoin community and the lack of experience in dealing with them.Another email thread focused on the security concerns surrounding BIP148 and BIP149. Kekcoin suggested using "post-split coinbases from the legacy chain" as seedcoins for cointainting purposes to mitigate these concerns. The discussion then turned to replay attacks and their potential threat. Tao Effect expressed concerns about the lack of replay protection and its serious implications. They suggested that since BIP148 required over 51% support to succeed, it could adopt a similar approach to SegWit or lower the threshold to 80% as BIP91 did. Kekcoin argued that the replay threat would be irrelevant as there would be no alternative chain to replay transactions on. They claimed that the non-148 chain would have been reorganized into oblivion.The email exchange delved further into the discussion on replay attacks and proposed solutions to prevent them. Kekcoin argued that using "post-chainsplit coinbases from the non-148 chain" was more secure in extreme-adversarial cases such as secret-mining reorg attacks. Tao Effect expressed confusion about Kekcoin's statement regarding the mootness of the replay threat if the non-148 chain faced a large-scale reorganization. The recipient clarified that without replay protection, the threat of replay attacks is always present and very serious.In another email thread, Tao Effect expressed concern about the lack of understanding and discussion surrounding the severity of replay attacks within the Bitcoin community. They attributed this lack of awareness to the community's limited experience with such attacks. While replay attacks have been resolved, there is room for improvement in terms of simplicity and effectiveness. The proposed coin-splitting techniques suggested by BIP148 were deemed complex, risky, and lacking guaranteed success. Additionally, using 148 coinbase transactions for mixing compromised fungibility. The absence of replay protection not only threatens the main chain but also any potential legacy chains created by malicious miners, rendering their coins invalid on the main chain.In response to Tao Effect's concerns, another member of the Bitcoin community emphasized that replay attack issues were previously addressed during discussions surrounding Ethereum's hard fork. The limited dialogue on these matters is attributed to engineers prioritizing stability and not considering BIP148 as a viable solution. However, these concerns apply to all hard fork proposals, possibly even more strongly. It was noted that replay attacks are not the most significant technical challenge; network partitioning presents a larger obstacle. BIP149, with its timeframe allowing for addressing replay attacks and other issues, may avoid the need for a significant fork altogether.Greg Slepak objected to BIP148 and BIP149 based on their involvement in the ETH/ETC hard fork. They acknowledged the differences between the situations, as the ETC/ETH hard fork resulted in two incompatible chains, unlike BIP148 and other soft forks. However, both scenarios are susceptible to replay attacks. Slepak advised caution and suggested refraining from sharing sensitive information via email if there are concerns about access by the NSA.The author of an email expressed uncertainty about the meaning of "render the replay threat moot," and the recipient clarified that without replay protection, the threat of - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml b/static/bitcoin-dev/June_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml index 714ac16a19..a66034c04d 100644 --- a/static/bitcoin-dev/June_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml +++ b/static/bitcoin-dev/June_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml @@ -1,92 +1,131 @@ - + 2 Combined summary - Segwit2Mb - combined soft/hard fork - Request For Comments - 2023-08-01T20:08:23.855216+00:00 - - Oliver Petruzel 2017-06-03 21:05:23+00:00 - - - Oliver Petruzel 2017-06-03 02:03:47+00:00 - - - Erik Aronesty 2017-06-03 00:53:55+00:00 - - - Sergio Demian Lerner 2017-06-02 21:51:45+00:00 - - - Erik Aronesty 2017-06-02 20:04:25+00:00 - - - Erik Aronesty 2017-06-02 20:04:16+00:00 - - - R E Broadley 2017-06-02 12:29:19+00:00 - - - Aymeric Vitte 2017-04-06 22:29:51+00:00 - - - Sergio Demian Lerner 2017-04-06 21:03:12+00:00 - - - Sergio Demian Lerner 2017-04-06 20:58:56+00:00 - - - Sergio Demian Lerner 2017-04-06 20:42:19+00:00 - - - Erik Aronesty 2017-04-06 02:27:34+00:00 - - - Btc Drak 2017-04-03 14:40:04+00:00 - - - Jorge Timón 2017-04-02 11:43:54+00:00 - - - Natanael 2017-04-02 10:03:31+00:00 - - - Jorge Timón 2017-04-02 04:57:48+00:00 - - - Natanael 2017-04-01 15:34:24+00:00 - - - Jorge Timón 2017-04-01 14:07:32+00:00 - - - Natanael 2017-04-01 13:15:15+00:00 - - - Jorge Timón 2017-04-01 12:33:18+00:00 - - - Sergio Demian Lerner 2017-04-01 11:44:11+00:00 - - - Jared Lee Richardson 2017-04-01 06:55:42+00:00 - - - Sergio Demian Lerner 2017-04-01 03:35:11+00:00 - - - Samson Mow 2017-04-01 03:03:03+00:00 - - - Sergio Demian Lerner 2017-03-31 22:13:35+00:00 - - - Sergio Demian Lerner 2017-03-31 21:50:05+00:00 - - - praxeology_guy 2017-03-31 21:22:02+00:00 - - - Sergio Demian Lerner 2017-03-31 21:09:18+00:00 - + 2025-09-26T15:56:39.412786+00:00 + python-feedgen + + + [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments Sergio Demian Lerner + 2017-03-31T21:09:00.000Z + + + Matt Corallo + 2017-03-31T21:18:00.000Z + + + praxeology_guy + 2017-03-31T21:22:00.000Z + + + Matt Corallo + 2017-03-31T21:22:00.000Z + + + Sergio Demian Lerner + 2017-03-31T21:50:00.000Z + + + Sergio Demian Lerner + 2017-03-31T22:13:00.000Z + + + Samson Mow + 2017-04-01T03:03:00.000Z + + + Sergio Demian Lerner + 2017-04-01T03:35:00.000Z + + + Jared Lee Richardson + 2017-04-01T06:55:00.000Z + + + Sergio Demian Lerner + 2017-04-01T11:44:00.000Z + + + Jorge Timón + 2017-04-01T12:33:00.000Z + + + Natanael + 2017-04-01T13:15:00.000Z + + + Jorge Timón + 2017-04-01T14:07:00.000Z + + + Natanael + 2017-04-01T15:34:00.000Z + + + Jorge Timón + 2017-04-02T04:57:00.000Z + + + Natanael + 2017-04-02T10:03:00.000Z + + + Jorge Timón + 2017-04-02T11:43:00.000Z + + + Btc Drak + 2017-04-03T14:40:00.000Z + + + Erik Aronesty + 2017-04-06T02:27:00.000Z + + + Sergio Demian Lerner + 2017-04-06T20:42:00.000Z + + + Sergio Demian Lerner + 2017-04-06T20:58:00.000Z + + + Sergio Demian Lerner + 2017-04-06T21:03:00.000Z + + + Aymeric Vitte + 2017-04-06T22:29:00.000Z + + + R E Broadley + 2017-06-02T12:29:00.000Z + + + Erik Aronesty + 2017-06-02T20:04:00.000Z + + + Erik Aronesty + 2017-06-02T20:04:00.000Z + + + Sergio Demian Lerner + 2017-06-02T21:51:00.000Z + + + Erik Aronesty + 2017-06-03T00:53:00.000Z + + + Oliver Petruzel + 2017-06-03T02:03:00.000Z + + + Oliver Petruzel + 2017-06-03T21:05:00.000Z + + @@ -115,13 +154,13 @@ - python-feedgen + 2 Combined summary - Segwit2Mb - combined soft/hard fork - Request For Comments - 2023-08-01T20:08:23.855216+00:00 + 2025-09-26T15:56:39.415848+00:00 - Sergio Demian Lerner has proposed two solutions to address the ongoing conflict within the Bitcoin community regarding the activation of segwit and the block size increase. The first proposal, called Segwit2Mb, combines SegWit with a 2MB block size hard-fork that would be activated only if SegWit activates with 95% miner signaling. The objective is to reunite the Bitcoin community and prevent a cryptocurrency split. The second proposal, known as the COOP proposal, suggests gradually increasing the block size limit over a four-year period to 4MB, aiming to prevent sudden spikes in transaction fees and ensure efficient handling of increased network traffic.Both proposals aim to address scalability and efficiency issues in the Bitcoin network. The implementation of segwit has already increased transaction capacity, and further improvements have been made to boost the network's processing speed. However, the current 1MB block size limit has been criticized for limiting the network's capacity during periods of high demand.There are concerns about potential centralization and security risks associated with larger blocks, particularly with the COOP proposal. The COOP proposal has received mixed reactions from the Bitcoin community, while the Segwit2Mb proposal aims to find a middle ground solution.Sergio Demian Lerner emphasizes the importance of 95% miner signaling to prevent a potential Bitcoin fork. He explains that a fork with only 95% miner support would result in reduced transaction capacity and slower confirmation times, leading to higher fees and a growing mempool. He also highlights the need for consensus among nodes and miners to avoid a split similar to what happened with Ethereum HF and Ethereum Classic.The proposed implementation of SegWit, according to the conversation between Natanael and Jorge Timón, would replace the current 1MB block-size limit with a weight limit of 4MB. This implementation is considered a backward compatible soft fork.The Segwit2Mb proposal has received criticism from developers who argue that it ignores previous research and understanding of hardforks. However, Sergio Demian Lerner welcomes community feedback and contributions to improve the proposal.In response to suggestions for improvement, Sergio Demian Lerner considers delaying the hard-fork date and emphasizes the need for further comments from the community. He also suggests considering the impact of technological innovations like Lightning, TumbleBit, and RootStock. However, there are concerns about the potential risks and confusion that could arise from a sudden change in block size increase.The proposed solution, Segwit2Mb, requires all Bitcoin nodes to be updated to prevent them from being forked away in a chain with almost no hashing power before the hard-fork occurs. The proposal aims to see the Lightning Network in action, utilize the non-malleability features in segwit, and discuss other soft-forks in the scaling roadmap.Overall, Sergio Demian Lerner's proposal seeks to find a compromise solution to address the issue of halting innovation for years. While controversial, the proposal encourages community participation and feedback to unlock the current deadlock within the Bitcoin community. 2017-06-03T21:05:23+00:00 + Sergio Demian Lerner has proposed two solutions to address the ongoing conflict within the Bitcoin community regarding the activation of segwit and the block size increase. The first proposal, called Segwit2Mb, combines SegWit with a 2MB block size hard-fork that would be activated only if SegWit activates with 95% miner signaling. The objective is to reunite the Bitcoin community and prevent a cryptocurrency split. The second proposal, known as the COOP proposal, suggests gradually increasing the block size limit over a four-year period to 4MB, aiming to prevent sudden spikes in transaction fees and ensure efficient handling of increased network traffic.Both proposals aim to address scalability and efficiency issues in the Bitcoin network. The implementation of segwit has already increased transaction capacity, and further improvements have been made to boost the network's processing speed. However, the current 1MB block size limit has been criticized for limiting the network's capacity during periods of high demand.There are concerns about potential centralization and security risks associated with larger blocks, particularly with the COOP proposal. The COOP proposal has received mixed reactions from the Bitcoin community, while the Segwit2Mb proposal aims to find a middle ground solution.Sergio Demian Lerner emphasizes the importance of 95% miner signaling to prevent a potential Bitcoin fork. He explains that a fork with only 95% miner support would result in reduced transaction capacity and slower confirmation times, leading to higher fees and a growing mempool. He also highlights the need for consensus among nodes and miners to avoid a split similar to what happened with Ethereum HF and Ethereum Classic.The proposed implementation of SegWit, according to the conversation between Natanael and Jorge Timón, would replace the current 1MB block-size limit with a weight limit of 4MB. This implementation is considered a backward compatible soft fork.The Segwit2Mb proposal has received criticism from developers who argue that it ignores previous research and understanding of hardforks. However, Sergio Demian Lerner welcomes community feedback and contributions to improve the proposal.In response to suggestions for improvement, Sergio Demian Lerner considers delaying the hard-fork date and emphasizes the need for further comments from the community. He also suggests considering the impact of technological innovations like Lightning, TumbleBit, and RootStock. However, there are concerns about the potential risks and confusion that could arise from a sudden change in block size increase.The proposed solution, Segwit2Mb, requires all Bitcoin nodes to be updated to prevent them from being forked away in a chain with almost no hashing power before the hard-fork occurs. The proposal aims to see the Lightning Network in action, utilize the non-malleability features in segwit, and discuss other soft-forks in the scaling roadmap.Overall, Sergio Demian Lerner's proposal seeks to find a compromise solution to address the issue of halting innovation for years. While controversial, the proposal encourages community participation and feedback to unlock the current deadlock within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_The-BIP148-chain-split-may-be-inevitable.xml b/static/bitcoin-dev/June_2017/combined_The-BIP148-chain-split-may-be-inevitable.xml index e9bdafbb27..3e4aa36a4a 100644 --- a/static/bitcoin-dev/June_2017/combined_The-BIP148-chain-split-may-be-inevitable.xml +++ b/static/bitcoin-dev/June_2017/combined_The-BIP148-chain-split-may-be-inevitable.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - The BIP148 chain split may be inevitable - 2023-08-01T20:56:49.276258+00:00 - - Jorge Timón 2017-06-11 17:12:35+00:00 - - - Jorge Timón 2017-06-11 17:11:53+00:00 - - - Jorge Timón 2017-06-11 15:06:01+00:00 - - - Jacob Eliosoff 2017-06-10 18:04:32+00:00 - - - Jacob Eliosoff 2017-06-09 05:23:17+00:00 - - - Jacob Eliosoff 2017-06-09 04:40:57+00:00 - + 2025-09-26T15:56:43.686815+00:00 + python-feedgen + + + [bitcoin-dev] The BIP148 chain split may be inevitable Jacob Eliosoff + 2017-06-09T04:40:00.000Z + + + Jacob Eliosoff + 2017-06-09T05:23:00.000Z + + + Jacob Eliosoff + 2017-06-10T18:04:00.000Z + + + Jorge Timón + 2017-06-11T15:06:00.000Z + + + Jorge Timón + 2017-06-11T17:11:00.000Z + + + Jorge Timón + 2017-06-11T17:12:00.000Z + + - python-feedgen + 2 Combined summary - The BIP148 chain split may be inevitable - 2023-08-01T20:56:49.276258+00:00 + 2025-09-26T15:56:43.687567+00:00 - There has been an update on the prospects of BIP91 avoiding a BIP148 chain split. According to recent findings, the timing isn't as dire as previously suggested. However, unless there is solid progress on a plan, particularly with miner support, the split will still occur. There have been several refinements noted which could get BIP91 (or split protection, Segwit2x, etc.) deployed faster. These include shortening the lock-in window and reducing the 80% threshold. Additionally, BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches lock-in, rather than waiting another period until it "activates". Combining these approaches, July 26th is an approximate hard deadline for over 50% of miners to be running BIP91 in order to prevent the split. This deadline is significantly less tight than the previous June 30th deadline. However, there are steps that need to be completed by that deadline. These include coordinating on a solution, implementing and testing it, convincing over 50% of miners to run it, and upgrading to the new software and begin signaling. A lot of convincing is still needed before miner support for any of these solutions reaches anything like 50%, except for Segwit2x, which has an additional handicap that it probably needs to include deployable hard fork code.Several dates have been provided, including August 1st as the date when BIP148 starts orphaning non-segwit blocks. It is expected that Segwit must activate by adjustment date #4 (~July 27) to avoid the BIP148 split. To avoid the BIP148 split, one of two things would have to happen: either 95% of hashrate start signaling bit 1 by ~June 30 or BIP91 is deployed and over 50% (80% or whatever) of hashrate is activated BIP91 miners by ~June 30. As of now, the split seems inevitable. It's expected that few parts of the ecosystem will join the fork, so disruption will be bearable.Jacob Eliosoff has been analyzing the expected interaction between James Hilliard's BIP91, splitprotection or Segwit2x and the BIP148 UASF. He concludes that it is unlikely that BIP91-type logic can activate segwit in time to avoid a BIP148 chain split, therefore ensuring the BIP148 split is as painless as possible. The deadline of BIP148 is already deployed and thus unlikely to be postponed, which means it starts orphaning non-segwit blocks on midnight (GMT) the morning of August 1. If Segwit activates on adjustment date #5 or later (August), it will be too late to avoid BIP148's split, which will have occurred the moment August began. To avoid the split, >50% of hashpower needs to be BIP91 miners, signaling bit 1 and orphaning non-BIP91 by June 30th.The expected interaction between James Hilliard's BIP91, Splitprotection and Segwit2x, which use variants of BIP91 activation, and the BIP148 UASF has been under discussion. It is unlikely that BIP91-type logic can activate segwit in time to avoid a BIP148 chain split, therefore ensuring the BIP148 split is as painless as possible is necessary. BIP148 starts orphaning non-segwit blocks on midnight (GMT) the morning of August 1. Segwit MUST activate by adj #4 (~July 27) to avoid BIP148's split, assuming compatibility with old BIP141 nodes. Therefore, >50% of hashpower needs to be BIP91 miners, signaling bit 1 and orphaning non-BIP91 by adj #2 (June 30). To avoid the BIP148 split, either 95% of hashrate must start signaling bit 1 by June 30 or BIP91 is deployed and >50% of hashrate is activated BIP91 miners by ~June 30. The BIP148 split is inevitable and few parts of the ecosystem are expected to join the fork, so disruption will be bearable. 2017-06-11T17:12:35+00:00 + There has been an update on the prospects of BIP91 avoiding a BIP148 chain split. According to recent findings, the timing isn't as dire as previously suggested. However, unless there is solid progress on a plan, particularly with miner support, the split will still occur. There have been several refinements noted which could get BIP91 (or split protection, Segwit2x, etc.) deployed faster. These include shortening the lock-in window and reducing the 80% threshold. Additionally, BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches lock-in, rather than waiting another period until it "activates". Combining these approaches, July 26th is an approximate hard deadline for over 50% of miners to be running BIP91 in order to prevent the split. This deadline is significantly less tight than the previous June 30th deadline. However, there are steps that need to be completed by that deadline. These include coordinating on a solution, implementing and testing it, convincing over 50% of miners to run it, and upgrading to the new software and begin signaling. A lot of convincing is still needed before miner support for any of these solutions reaches anything like 50%, except for Segwit2x, which has an additional handicap that it probably needs to include deployable hard fork code.Several dates have been provided, including August 1st as the date when BIP148 starts orphaning non-segwit blocks. It is expected that Segwit must activate by adjustment date #4 (~July 27) to avoid the BIP148 split. To avoid the BIP148 split, one of two things would have to happen: either 95% of hashrate start signaling bit 1 by ~June 30 or BIP91 is deployed and over 50% (80% or whatever) of hashrate is activated BIP91 miners by ~June 30. As of now, the split seems inevitable. It's expected that few parts of the ecosystem will join the fork, so disruption will be bearable.Jacob Eliosoff has been analyzing the expected interaction between James Hilliard's BIP91, splitprotection or Segwit2x and the BIP148 UASF. He concludes that it is unlikely that BIP91-type logic can activate segwit in time to avoid a BIP148 chain split, therefore ensuring the BIP148 split is as painless as possible. The deadline of BIP148 is already deployed and thus unlikely to be postponed, which means it starts orphaning non-segwit blocks on midnight (GMT) the morning of August 1. If Segwit activates on adjustment date #5 or later (August), it will be too late to avoid BIP148's split, which will have occurred the moment August began. To avoid the split, >50% of hashpower needs to be BIP91 miners, signaling bit 1 and orphaning non-BIP91 by June 30th.The expected interaction between James Hilliard's BIP91, Splitprotection and Segwit2x, which use variants of BIP91 activation, and the BIP148 UASF has been under discussion. It is unlikely that BIP91-type logic can activate segwit in time to avoid a BIP148 chain split, therefore ensuring the BIP148 split is as painless as possible is necessary. BIP148 starts orphaning non-segwit blocks on midnight (GMT) the morning of August 1. Segwit MUST activate by adj #4 (~July 27) to avoid BIP148's split, assuming compatibility with old BIP141 nodes. Therefore, >50% of hashpower needs to be BIP91 miners, signaling bit 1 and orphaning non-BIP91 by adj #2 (June 30). To avoid the BIP148 split, either 95% of hashrate must start signaling bit 1 by June 30 or BIP91 is deployed and >50% of hashrate is activated BIP91 miners by ~June 30. The BIP148 split is inevitable and few parts of the ecosystem are expected to join the fork, so disruption will be bearable. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_User-Activated-Soft-Fork-Split-Protection.xml b/static/bitcoin-dev/June_2017/combined_User-Activated-Soft-Fork-Split-Protection.xml index 0b136bc0ed..c3ae63d575 100644 --- a/static/bitcoin-dev/June_2017/combined_User-Activated-Soft-Fork-Split-Protection.xml +++ b/static/bitcoin-dev/June_2017/combined_User-Activated-Soft-Fork-Split-Protection.xml @@ -1,95 +1,127 @@ - + 2 Combined summary - User Activated Soft Fork Split Protection - 2023-08-01T20:56:15.191723+00:00 - - James Hilliard 2017-06-08 09:20:28+00:00 - - - Jared Lee Richardson 2017-06-08 01:01:38+00:00 - - - James Hilliard 2017-06-08 00:44:38+00:00 - - - Jared Lee Richardson 2017-06-08 00:20:23+00:00 - - - James Hilliard 2017-06-08 00:01:19+00:00 - - - Jared Lee Richardson 2017-06-07 23:43:57+00:00 - - - James Hilliard 2017-06-07 23:11:00+00:00 - - - Jared Lee Richardson 2017-06-07 22:53:14+00:00 - - - James Hilliard 2017-06-07 22:23:31+00:00 - - - Jared Lee Richardson 2017-06-07 21:50:18+00:00 - - - James Hilliard 2017-06-07 21:44:52+00:00 - - - Jared Lee Richardson 2017-06-07 21:43:14+00:00 - - - James Hilliard 2017-06-07 21:42:52+00:00 - - - Jared Lee Richardson 2017-06-07 21:29:55+00:00 - - - James Hilliard 2017-06-07 21:21:29+00:00 - - - Jared Lee Richardson 2017-06-07 21:09:04+00:00 - - - Erik Aronesty 2017-06-07 19:59:23+00:00 - - - Jacob Eliosoff 2017-06-07 19:39:48+00:00 - - - Erik Aronesty 2017-06-07 18:05:52+00:00 - - - Jacob Eliosoff 2017-06-07 16:44:32+00:00 - - - Erik Aronesty 2017-06-07 14:10:48+00:00 - - - James Hilliard 2017-06-07 10:13:43+00:00 - - - Tao Effect 2017-06-07 05:20:52+00:00 - - - Jacob Eliosoff 2017-06-07 04:17:37+00:00 - - - James Hilliard 2017-06-07 01:54:37+00:00 - - - Tao Effect 2017-06-07 01:51:39+00:00 - - - James Hilliard 2017-06-07 01:29:18+00:00 - - - Karl Johan Alm 2017-06-07 01:11:25+00:00 - - - James Hilliard 2017-06-07 00:56:10+00:00 - + 2025-09-26T15:57:07.412780+00:00 + python-feedgen + + + [bitcoin-dev] User Activated Soft Fork Split Protection James Hilliard + 2017-06-07T00:56:00.000Z + + + Karl Johan Alm + 2017-06-07T01:11:00.000Z + + + James Hilliard + 2017-06-07T01:29:00.000Z + + + Tao Effect + 2017-06-07T01:51:00.000Z + + + James Hilliard + 2017-06-07T01:54:00.000Z + + + Jacob Eliosoff + 2017-06-07T04:17:00.000Z + + + Tao Effect + 2017-06-07T05:20:00.000Z + + + James Hilliard + 2017-06-07T10:13:00.000Z + + + Erik Aronesty + 2017-06-07T14:10:00.000Z + + + Jacob Eliosoff + 2017-06-07T16:44:00.000Z + + + Erik Aronesty + 2017-06-07T18:05:00.000Z + + + Jacob Eliosoff + 2017-06-07T19:39:00.000Z + + + Erik Aronesty + 2017-06-07T19:59:00.000Z + + + Jared Lee Richardson + 2017-06-07T21:09:00.000Z + + + James Hilliard + 2017-06-07T21:21:00.000Z + + + Jared Lee Richardson + 2017-06-07T21:29:00.000Z + + + James Hilliard + 2017-06-07T21:42:00.000Z + + + Jared Lee Richardson + 2017-06-07T21:43:00.000Z + + + James Hilliard + 2017-06-07T21:44:00.000Z + + + Jared Lee Richardson + 2017-06-07T21:50:00.000Z + + + James Hilliard + 2017-06-07T22:23:00.000Z + + + Jared Lee Richardson + 2017-06-07T22:53:00.000Z + + + James Hilliard + 2017-06-07T23:11:00.000Z + + + Jared Lee Richardson + 2017-06-07T23:43:00.000Z + + + James Hilliard + 2017-06-08T00:01:00.000Z + + + Jared Lee Richardson + 2017-06-08T00:20:00.000Z + + + James Hilliard + 2017-06-08T00:44:00.000Z + + + Jared Lee Richardson + 2017-06-08T01:01:00.000Z + + + James Hilliard + 2017-06-08T09:20:00.000Z + + @@ -119,13 +151,13 @@ - python-feedgen + 2 Combined summary - User Activated Soft Fork Split Protection - 2023-08-01T20:56:15.192723+00:00 + 2025-09-26T15:57:07.415855+00:00 - The viability and success of BIP148, a user-activated soft fork (UASF) to implement Segregated Witness (SegWit) on the Bitcoin network, are discussed in the conversation. However, measuring its potential success is challenging, as metrics such as mining commitments, node signaling, and Reddit upvotes do not provide conclusive evidence. The conversation suggests that markets may offer better insight closer to BIP148 activation.Exchanges are expected to handle the splitting of transactions between chains automatically for less technical users in case of a split. However, the lack of replay protection poses a challenge. The risk of chain wipeout is also discussed, with the non-BIP148 side carrying a higher risk. Economic support is emphasized as a key factor in determining the outcome, rather than hashpower support.The conversation also touches upon the ETH/ETC fork and the potential risks and advantages of BIP148. It mentions a new Bitcoin Improvement Proposal (BIP) called "splitprotection," which proposes using a simple majority of miners to activate mandatory signaling for SegWit ahead of the BIP148 activation date. This proposal aims to eliminate the risk of an extended chain split and allow miners to respond quickly to market forces.Various Bitcoin Improvement Proposals (BIPs) related to the deployment and activation of SegWit are mentioned. BIP147 addresses the issue of dummy stack elements, while BIP149 suggests a second deployment of SegWit. The benefits of SegWit are outlined in an article linked in the context.The document also describes the implementation of a mandatory segwit signaling process known as "splitprotection." It explains that this implementation is compatible with existing deployments and ensures that miners are aware of new rules being enforced. The document is dual licensed and references a mailing list for Bitcoin developers.Overall, the discussion highlights the uncertainties surrounding the success of BIP148 and the importance of economic support, replay protection, and proper consensus in determining the outcome.A new Bitcoin Improvement Proposal (BIP) called splitprotection has been proposed as an alternative to the SegWit2x agreement. The goal of splitprotection is to prevent a potential chain split before the August 1st BIP148 activation date. It uses BIP8 instead of BIP9, with a lower activation threshold and immediate mandatory signaling lock-in. This allows a majority of miners to activate mandatory SegWit signaling and reduce the chances of an extended chain split. Blocks that do not signal as required will be rejected. Users are advised to upgrade to split protection or wait for additional confirmations when accepting payments.The bitcoin-dev mailing list, managed by the Linux Foundation, serves as a forum for developers to discuss Bitcoin code and protocol issues. It is open to anyone interested in contributing to Bitcoin's development. The mailing list helps drive innovation and progress in the world of cryptocurrency by promoting collaboration among developers.The splitprotection soft fork proposal aims to coordinate activation of the existing segwit deployment with less than 95% hash power before BIP148 activation. It leverages the IsSuperMajority() technique historically used to activate soft forks, allowing for a lower signaling threshold while being deployed in a backwards compatible way. Non-signaling blocks during the "segwit" deployment can be orphaned to activate the existing deployment without releasing a new one. Miners need to upgrade their nodes to support split protection to avoid building on top of invalid blocks. The document provides references to various related BIPs and explains the rationale behind this deployment.Another criticism of the splitprotection proposal suggests correcting it to orphan blocks only if more than 50% signal for BIP148 or using two bits: one supporting BIP148 and the other following the miner majority. Some experts argue that passing off splitprotection as the safest defense against a chain split may not be the best option.In summary, the splitprotection BIP offers a solution to prevent a potential chain split before the BIP148 activation date. It allows miners to coordinate activation of segwit with less than 95% hash power, reducing the risk of an extended chain split. The proposal uses IsSuperMajority() and orphaning non-signaling blocks during the "segwit" deployment to activate without releasing a new deployment. Users are advised to upgrade to split protection or wait for additional confirmations when accepting payments. The document provides references to related BIPs and is dual licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal.James Hilliard has proposed a new option called split protection soft fork, which allows miners to prevent a chain split ahead of the August 1st BIP148 activation date. This proposal is in response to the SegWit2x agreement being too slow to activate SegWit mandatory signalling using BIP91 before BIP148. The splitprotection soft fork is essentially BIP91 but uses BIP8 instead of BIP9 with a 2017-06-08T09:20:28+00:00 + The viability and success of BIP148, a user-activated soft fork (UASF) to implement Segregated Witness (SegWit) on the Bitcoin network, are discussed in the conversation. However, measuring its potential success is challenging, as metrics such as mining commitments, node signaling, and Reddit upvotes do not provide conclusive evidence. The conversation suggests that markets may offer better insight closer to BIP148 activation.Exchanges are expected to handle the splitting of transactions between chains automatically for less technical users in case of a split. However, the lack of replay protection poses a challenge. The risk of chain wipeout is also discussed, with the non-BIP148 side carrying a higher risk. Economic support is emphasized as a key factor in determining the outcome, rather than hashpower support.The conversation also touches upon the ETH/ETC fork and the potential risks and advantages of BIP148. It mentions a new Bitcoin Improvement Proposal (BIP) called "splitprotection," which proposes using a simple majority of miners to activate mandatory signaling for SegWit ahead of the BIP148 activation date. This proposal aims to eliminate the risk of an extended chain split and allow miners to respond quickly to market forces.Various Bitcoin Improvement Proposals (BIPs) related to the deployment and activation of SegWit are mentioned. BIP147 addresses the issue of dummy stack elements, while BIP149 suggests a second deployment of SegWit. The benefits of SegWit are outlined in an article linked in the context.The document also describes the implementation of a mandatory segwit signaling process known as "splitprotection." It explains that this implementation is compatible with existing deployments and ensures that miners are aware of new rules being enforced. The document is dual licensed and references a mailing list for Bitcoin developers.Overall, the discussion highlights the uncertainties surrounding the success of BIP148 and the importance of economic support, replay protection, and proper consensus in determining the outcome.A new Bitcoin Improvement Proposal (BIP) called splitprotection has been proposed as an alternative to the SegWit2x agreement. The goal of splitprotection is to prevent a potential chain split before the August 1st BIP148 activation date. It uses BIP8 instead of BIP9, with a lower activation threshold and immediate mandatory signaling lock-in. This allows a majority of miners to activate mandatory SegWit signaling and reduce the chances of an extended chain split. Blocks that do not signal as required will be rejected. Users are advised to upgrade to split protection or wait for additional confirmations when accepting payments.The bitcoin-dev mailing list, managed by the Linux Foundation, serves as a forum for developers to discuss Bitcoin code and protocol issues. It is open to anyone interested in contributing to Bitcoin's development. The mailing list helps drive innovation and progress in the world of cryptocurrency by promoting collaboration among developers.The splitprotection soft fork proposal aims to coordinate activation of the existing segwit deployment with less than 95% hash power before BIP148 activation. It leverages the IsSuperMajority() technique historically used to activate soft forks, allowing for a lower signaling threshold while being deployed in a backwards compatible way. Non-signaling blocks during the "segwit" deployment can be orphaned to activate the existing deployment without releasing a new one. Miners need to upgrade their nodes to support split protection to avoid building on top of invalid blocks. The document provides references to various related BIPs and explains the rationale behind this deployment.Another criticism of the splitprotection proposal suggests correcting it to orphan blocks only if more than 50% signal for BIP148 or using two bits: one supporting BIP148 and the other following the miner majority. Some experts argue that passing off splitprotection as the safest defense against a chain split may not be the best option.In summary, the splitprotection BIP offers a solution to prevent a potential chain split before the BIP148 activation date. It allows miners to coordinate activation of segwit with less than 95% hash power, reducing the risk of an extended chain split. The proposal uses IsSuperMajority() and orphaning non-signaling blocks during the "segwit" deployment to activate without releasing a new deployment. Users are advised to upgrade to split protection or wait for additional confirmations when accepting payments. The document provides references to related BIPs and is dual licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal.James Hilliard has proposed a new option called split protection soft fork, which allows miners to prevent a chain split ahead of the August 1st BIP148 activation date. This proposal is in response to the SegWit2x agreement being too slow to activate SegWit mandatory signalling using BIP91 before BIP148. The splitprotection soft fork is essentially BIP91 but uses BIP8 instead of BIP9 with a - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2017/combined_extended-BIP9-activation-of-segwit-for-legacy-nodes.xml b/static/bitcoin-dev/June_2017/combined_extended-BIP9-activation-of-segwit-for-legacy-nodes.xml index 6dfbe84ec5..c670de285e 100644 --- a/static/bitcoin-dev/June_2017/combined_extended-BIP9-activation-of-segwit-for-legacy-nodes.xml +++ b/static/bitcoin-dev/June_2017/combined_extended-BIP9-activation-of-segwit-for-legacy-nodes.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - extended BIP9 activation of segwit, for legacy nodes - 2023-08-01T20:27:08.540728+00:00 - - Ryan Grant 2017-06-11 19:31:00+00:00 - - - shaolinfry 2017-04-14 20:33:40+00:00 - - - Ryan Grant 2017-04-14 20:12:34+00:00 - + 2025-09-26T15:57:09.533776+00:00 + python-feedgen + + + [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes Ryan Grant + 2017-04-14T20:12:00.000Z + + + shaolinfry + 2017-04-14T20:33:00.000Z + + + Ryan Grant + 2017-06-11T19:31:00.000Z + + - python-feedgen + 2 Combined summary - extended BIP9 activation of segwit, for legacy nodes - 2023-08-01T20:27:08.540728+00:00 + 2025-09-26T15:57:09.534304+00:00 - The proposal aims to activate a BIP149-like segwit in November, allowing for easy testing and deployment. It emphasizes the need for inevitability rather than time for legacy nodes to upgrade. The proposal suggests deploying segwit separately for legacy and semi-legacy nodes to provide immediate participation for semi-legacy nodes. It does not specify deployment specifics but leaves it to future proposals.If the proposed idea is found to be broken or of no benefit during testing, the alternative deployment method (DEPLOYMENT_SEGWIT_ALT1) can be avoided until it expires. Without this proposal, the activation process for BIP149ish would be slow and difficult to plan due to debates, tests, and a courtesy timeout. However, with this proposal, the courtesy period begins as soon as it goes live, simplifying the debate on how BIP149ish should deploy and enabling quicker activation of segwit.Additionally, Shaolinfry has suggested the bip-uaversionbits proposal, which involves reserving a backward compatibility bit for all yet-unknown segwit-compatible proposals to utilize. This proposal aims to allow validating nodes that already support segwit to participate fully without further upgrades, even if segwit is activated through alternate means. It also suggests that future BIP9-compatible deployment attempts may include a date-dependent UASF fallback.By using the proposed backward-compatible bit, more legacy nodes would understand and validate transactions using segregated witnesses after 95% of recent blocks signal for the alternate segwit deployment. The proposal suggests a conservative expiration time of five years for Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147). The provided email includes the proposed deployment logic for segwit.Overall, the activation of segwit has proven to be more challenging than anticipated, but the technical consensus remains clear. The proposal aims to enable validating nodes capable of supporting segwit to participate fully without further upgrades. Despite the slow nature of upgrades on the Bitcoin network, there are distinct advantages to validating and generating segregated witness transactions. 2017-06-11T19:31:00+00:00 + The proposal aims to activate a BIP149-like segwit in November, allowing for easy testing and deployment. It emphasizes the need for inevitability rather than time for legacy nodes to upgrade. The proposal suggests deploying segwit separately for legacy and semi-legacy nodes to provide immediate participation for semi-legacy nodes. It does not specify deployment specifics but leaves it to future proposals.If the proposed idea is found to be broken or of no benefit during testing, the alternative deployment method (DEPLOYMENT_SEGWIT_ALT1) can be avoided until it expires. Without this proposal, the activation process for BIP149ish would be slow and difficult to plan due to debates, tests, and a courtesy timeout. However, with this proposal, the courtesy period begins as soon as it goes live, simplifying the debate on how BIP149ish should deploy and enabling quicker activation of segwit.Additionally, Shaolinfry has suggested the bip-uaversionbits proposal, which involves reserving a backward compatibility bit for all yet-unknown segwit-compatible proposals to utilize. This proposal aims to allow validating nodes that already support segwit to participate fully without further upgrades, even if segwit is activated through alternate means. It also suggests that future BIP9-compatible deployment attempts may include a date-dependent UASF fallback.By using the proposed backward-compatible bit, more legacy nodes would understand and validate transactions using segregated witnesses after 95% of recent blocks signal for the alternate segwit deployment. The proposal suggests a conservative expiration time of five years for Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147). The provided email includes the proposed deployment logic for segwit.Overall, the activation of segwit has proven to be more challenging than anticipated, but the technical consensus remains clear. The proposal aims to enable validating nodes capable of supporting segwit to participate fully without further upgrades. Despite the slow nature of upgrades on the Bitcoin network, there are distinct advantages to validating and generating segregated witness transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_-BIP-Proposal-BetterHash-Mining-Protocol-Replacements.xml b/static/bitcoin-dev/June_2018/combined_-BIP-Proposal-BetterHash-Mining-Protocol-Replacements.xml index 9a731ddbd3..ca068dc7e6 100644 --- a/static/bitcoin-dev/June_2018/combined_-BIP-Proposal-BetterHash-Mining-Protocol-Replacements.xml +++ b/static/bitcoin-dev/June_2018/combined_-BIP-Proposal-BetterHash-Mining-Protocol-Replacements.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - [BIP Proposal] BetterHash Mining Protocol Replacements - 2023-08-01T23:26:02.217725+00:00 - - Matt Corallo 2018-06-06 19:16:09+00:00 - - - Chris Pacia 2018-06-06 01:26:35+00:00 - - - Matt Corallo 2018-06-05 18:44:57+00:00 - + 2025-09-26T15:47:13.633377+00:00 + python-feedgen + + + [bitcoin-dev] [BIP Proposal] BetterHash Mining Protocol Replacements Matt Corallo + 2018-06-05T18:44:00.000Z + + + Chris Pacia + 2018-06-06T01:26:00.000Z + + + Matt Corallo + 2018-06-06T19:16:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] BetterHash Mining Protocol Replacements - 2023-08-01T23:26:02.217725+00:00 + 2025-09-26T15:47:13.633951+00:00 - The Bitcoin Core is proposing a new protocol to replace the existing getblocktemplate and Stratum protocols used in Bitcoin mining pools. This proposal aims to address several shortcomings and achieve three primary goals. Firstly, the new protocol seeks to be more performant and robust for consensus changes. It will allow the same CTransactionRef in the Bitcoin Core, resulting in faster validation processes. Additionally, it will move more block-switching logic within the work provider, enabling better optimization of work switching. Secondly, the protocol aims to provide a more secure, simpler-to-implement, and better-defined alternative to Stratum. It will offer VENDOR_MESSAGEs for extensibility, eliminating conflicting specifications from different vendors. It also aims to improve security by removing network-level centralization attacks through decentralization pressure. Pools will have the ability to accept work selected by users, while still maintaining control over payout management and variance reduction.The proposal has undergone multiple rounds of feedback and offers a more secure and simplified replacement for Stratum. The full BIP draft, along with implementations of the work-generation and pool/proxy parts, can be found on GitHub. Although the implementations are slightly out-of-date, they have successfully mined numerous testnet blocks using various hardware types.Overall, the author believes that the new protocol has the potential to significantly enhance decentralization in Bitcoin mining. 2018-06-06T19:16:09+00:00 + The Bitcoin Core is proposing a new protocol to replace the existing getblocktemplate and Stratum protocols used in Bitcoin mining pools. This proposal aims to address several shortcomings and achieve three primary goals. Firstly, the new protocol seeks to be more performant and robust for consensus changes. It will allow the same CTransactionRef in the Bitcoin Core, resulting in faster validation processes. Additionally, it will move more block-switching logic within the work provider, enabling better optimization of work switching. Secondly, the protocol aims to provide a more secure, simpler-to-implement, and better-defined alternative to Stratum. It will offer VENDOR_MESSAGEs for extensibility, eliminating conflicting specifications from different vendors. It also aims to improve security by removing network-level centralization attacks through decentralization pressure. Pools will have the ability to accept work selected by users, while still maintaining control over payout management and variance reduction.The proposal has undergone multiple rounds of feedback and offers a more secure and simplified replacement for Stratum. The full BIP draft, along with implementations of the work-generation and pool/proxy parts, can be found on GitHub. Although the implementations are slightly out-of-date, they have successfully mined numerous testnet blocks using various hardware types.Overall, the author believes that the new protocol has the potential to significantly enhance decentralization in Bitcoin mining. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_BIP-158-Flexibility-and-Filter-Size.xml b/static/bitcoin-dev/June_2018/combined_BIP-158-Flexibility-and-Filter-Size.xml index 6349f7ebca..081854a7a7 100644 --- a/static/bitcoin-dev/June_2018/combined_BIP-158-Flexibility-and-Filter-Size.xml +++ b/static/bitcoin-dev/June_2018/combined_BIP-158-Flexibility-and-Filter-Size.xml @@ -1,188 +1,251 @@ - + 2 Combined summary - BIP 158 Flexibility and Filter Size - 2023-08-01T23:11:29.318749+00:00 - - Olaoluwa Osuntokun 2018-06-12 23:58:50+00:00 - - - Olaoluwa Osuntokun 2018-06-12 23:51:29+00:00 - - - Gregory Maxwell 2018-06-09 15:45:54+00:00 - - - David A. Harding 2018-06-09 10:34:45+00:00 - - - Olaoluwa Osuntokun 2018-06-08 23:35:29+00:00 - - - Gregory Maxwell 2018-06-08 16:14:41+00:00 - - - Olaoluwa Osuntokun 2018-06-08 05:03:04+00:00 - - - Riccardo Casatta 2018-06-06 15:14:17+00:00 - - - Olaoluwa Osuntokun 2018-06-06 01:12:55+00:00 - - - Gregory Maxwell 2018-06-05 17:52:29+00:00 - - - Jim Posen 2018-06-05 17:22:04+00:00 - - - Karl-Johan Alm 2018-06-05 04:33:06+00:00 - - - Jim Posen 2018-06-05 01:08:01+00:00 - - - Riccardo Casatta 2018-06-04 08:42:10+00:00 - - - Tamas Blummer 2018-06-03 16:50:17+00:00 - - - Tamas Blummer 2018-06-03 16:44:04+00:00 - - - Pieter Wuille 2018-06-03 06:11:56+00:00 - - - Tamas Blummer 2018-06-03 05:14:34+00:00 - - - Gregory Maxwell 2018-06-03 00:28:33+00:00 - - - Tamas Blummer 2018-06-02 22:02:11+00:00 - - - David A. Harding 2018-06-02 12:41:57+00:00 - - - Jim Posen 2018-06-02 02:02:38+00:00 - - - Gregory Maxwell 2018-06-02 00:22:25+00:00 - - - Olaoluwa Osuntokun 2018-06-02 00:01:43+00:00 - - - Gregory Maxwell 2018-06-01 04:15:13+00:00 - - - Olaoluwa Osuntokun 2018-06-01 02:52:48+00:00 - - - Tamas Blummer 2018-05-31 14:27:50+00:00 - - - Olaoluwa Osuntokun 2018-05-29 04:01:35+00:00 - - - Gregory Maxwell 2018-05-29 03:24:45+00:00 - - - Jim Posen 2018-05-29 02:42:52+00:00 - - - Gregory Maxwell 2018-05-28 19:24:09+00:00 - - - Tamas Blummer 2018-05-28 18:28:16+00:00 - - - Tamas Blummer 2018-05-28 18:18:12+00:00 - - - Jim Posen 2018-05-24 03:48:00+00:00 - - - Conner Fromknecht 2018-05-24 01:04:34+00:00 - - - Gregory Maxwell 2018-05-23 17:28:29+00:00 - - - Johan Torås Halseth 2018-05-23 08:16:41+00:00 - - - Jim Posen 2018-05-23 07:38:40+00:00 - - - Jim Posen 2018-05-23 00:42:29+00:00 - - - Johan Torås Halseth 2018-05-22 09:23:29+00:00 - - - Olaoluwa Osuntokun 2018-05-22 01:16:52+00:00 - - - Olaoluwa Osuntokun 2018-05-22 01:15:22+00:00 - - - Johan Torås Halseth 2018-05-21 08:35:28+00:00 - - - Olaoluwa Osuntokun 2018-05-19 03:12:09+00:00 - - - Olaoluwa Osuntokun 2018-05-19 03:08:29+00:00 - - - Pieter Wuille 2018-05-19 03:06:10+00:00 - - - Olaoluwa Osuntokun 2018-05-19 02:57:12+00:00 - - - Olaoluwa Osuntokun 2018-05-19 02:51:02+00:00 - - - Riccardo Casatta 2018-05-18 08:46:29+00:00 - - - Karl-Johan Alm 2018-05-18 06:28:39+00:00 - - - Jim Posen 2018-05-17 21:27:15+00:00 - - - Gregory Maxwell 2018-05-17 20:45:33+00:00 - - - Jim Posen 2018-05-17 20:19:17+00:00 - - - Gregory Maxwell 2018-05-17 18:34:45+00:00 - - - Gregory Maxwell 2018-05-17 18:34:45+00:00 - - - Matt Corallo 2018-05-17 16:59:22+00:00 - - - Gregory Maxwell 2018-05-17 16:36:37+00:00 - - - Matt Corallo 2018-05-17 15:46:18+00:00 - - - Peter Todd 2018-05-17 15:43:15+00:00 - - - Matt Corallo 2018-05-17 15:25:12+00:00 - + 2025-09-26T15:47:03.090216+00:00 + python-feedgen + + + [bitcoin-dev] BIP 158 Flexibility and Filter Size Matt Corallo + 2018-05-17T15:25:00.000Z + + + Peter Todd + 2018-05-17T15:43:00.000Z + + + Matt Corallo + 2018-05-17T15:46:00.000Z + + + Gregory Maxwell + 2018-05-17T16:36:00.000Z + + + Matt Corallo + 2018-05-17T16:59:00.000Z + + + Gregory Maxwell + 2018-05-17T18:34:00.000Z + + + Gregory Maxwell + 2018-05-17T18:34:00.000Z + + + Jim Posen + 2018-05-17T20:19:00.000Z + + + Gregory Maxwell + 2018-05-17T20:45:00.000Z + + + Jim Posen + 2018-05-17T21:27:00.000Z + + + Karl-Johan Alm + 2018-05-18T06:28:00.000Z + + + Riccardo Casatta + 2018-05-18T08:46:00.000Z + + + Olaoluwa Osuntokun + 2018-05-19T02:51:00.000Z + + + Olaoluwa Osuntokun + 2018-05-19T02:57:00.000Z + + + Pieter Wuille + 2018-05-19T03:06:00.000Z + + + Olaoluwa Osuntokun + 2018-05-19T03:08:00.000Z + + + Olaoluwa Osuntokun + 2018-05-19T03:12:00.000Z + + + Johan Torås Halseth + 2018-05-21T08:35:00.000Z + + + Olaoluwa Osuntokun + 2018-05-22T01:15:00.000Z + + + Olaoluwa Osuntokun + 2018-05-22T01:16:00.000Z + + + Johan Torås Halseth + 2018-05-22T09:23:00.000Z + + + Jim Posen + 2018-05-23T00:42:00.000Z + + + Jim Posen + 2018-05-23T07:38:00.000Z + + + Johan Torås Halseth + 2018-05-23T08:16:00.000Z + + + Gregory Maxwell + 2018-05-23T17:28:00.000Z + + + Conner Fromknecht + 2018-05-24T01:04:00.000Z + + + Jim Posen + 2018-05-24T03:48:00.000Z + + + Tamas Blummer + 2018-05-28T18:18:00.000Z + + + Tamas Blummer + 2018-05-28T18:28:00.000Z + + + Gregory Maxwell + 2018-05-28T19:24:00.000Z + + + Jim Posen + 2018-05-29T02:42:00.000Z + + + Gregory Maxwell + 2018-05-29T03:24:00.000Z + + + Olaoluwa Osuntokun + 2018-05-29T04:01:00.000Z + + + Tamas Blummer + 2018-05-31T14:27:00.000Z + + + Olaoluwa Osuntokun + 2018-06-01T02:52:00.000Z + + + Gregory Maxwell + 2018-06-01T04:15:00.000Z + + + Olaoluwa Osuntokun + 2018-06-02T00:01:00.000Z + + + Gregory Maxwell + 2018-06-02T00:22:00.000Z + + + Jim Posen + 2018-06-02T02:02:00.000Z + + + David A. Harding + 2018-06-02T12:41:00.000Z + + + Tamas Blummer + 2018-06-02T22:02:00.000Z + + + Gregory Maxwell + 2018-06-03T00:28:00.000Z + + + Tamas Blummer + 2018-06-03T05:14:00.000Z + + + Pieter Wuille + 2018-06-03T06:11:00.000Z + + + Tamas Blummer + 2018-06-03T16:44:00.000Z + + + Tamas Blummer + 2018-06-03T16:50:00.000Z + + + Riccardo Casatta + 2018-06-04T08:42:00.000Z + + + Jim Posen + 2018-06-05T01:08:00.000Z + + + Karl-Johan Alm + 2018-06-05T04:33:00.000Z + + + Jim Posen + 2018-06-05T17:22:00.000Z + + + Gregory Maxwell + 2018-06-05T17:52:00.000Z + + + Olaoluwa Osuntokun + 2018-06-06T01:12:00.000Z + + + Riccardo Casatta + 2018-06-06T15:14:00.000Z + + + Olaoluwa Osuntokun + 2018-06-08T05:03:00.000Z + + + Gregory Maxwell + 2018-06-08T16:14:00.000Z + + + Olaoluwa Osuntokun + 2018-06-08T23:35:00.000Z + + + David A. Harding + 2018-06-09T10:34:00.000Z + + + Gregory Maxwell + 2018-06-09T15:45:00.000Z + + + Olaoluwa Osuntokun + 2018-06-12T23:51:00.000Z + + + Olaoluwa Osuntokun + 2018-06-12T23:58:00.000Z + + @@ -243,13 +306,13 @@ - python-feedgen + 2 Combined summary - BIP 158 Flexibility and Filter Size - 2023-08-01T23:11:29.319752+00:00 + 2025-09-26T15:47:03.096955+00:00 - The conversation on the bitcoin-dev mailing list revolves around the implementation of new filter formats and commitments for Bitcoin. One proposal suggests excluding OP_RETURN outputs from BIP-158 filters to avoid polluting the filters. The Tier Nolan proposal, which creates a constant-sized proof for future commitments, is viewed as an ugly hack and difficult to implement "full" validation. There is a debate about optimizing for better security or lower bandwidth.The cost and practicality of the current filter design are also discussed. Adding more commitments is seen as a priority, and coordination for an ultimate extensible commitment is suggested. However, the current filter format cannot be committed due to indexing issues. The debate focuses on the trade-off between security and bandwidth optimization.The proposal to change the way filters are created for Bitcoin transactions is also addressed. Currently, the "regular" filter includes the outpoint, but there is a suggestion to switch to including prev scripts instead. The debate focuses on the cost, practicality, and security implications of this change.Multi-layer filtering in BIP 157/158 is also discussed. The benefits of using a map instead of a filter for upper layers are discussed, along with the possibility of using multi-block filters. The process of removing unnecessary items or filters is ongoing, and custom filter types and batch fetching based on block height and numerical range are already defined in BIPs.Tamas Blummer conducted an analysis on the use of filters in Bitcoin history and found that certain filters were smaller than others. The savings from using these filters have been decreasing over time. Blummer also discussed the importance of lighter but SPV secure nodes in helping the network grow while maintaining security.There are debates about relying on a "single honest peer" security model, the current state of non-existing validation in SPV software, and the need for generalized proposals that allow for future extensibility.In conclusion, the discussions revolve around finding the optimal design for filters in light clients, considering factors such as security, efficiency, and data size. Various proposals and modifications have been suggested to improve the current system, and there is ongoing debate about the best approach.The bitcoin-dev mailing list has been engaged in discussions about improving the implementation of block filters, reducing filter sizes, and enhancing security in decentralized networks that store money. The possibility of splitting the basic filter into separate filters based on data type is mentioned, along with potential solutions to address bandwidth concerns. One proposal, BIP 158, aims to enhance the security and privacy of Simplified Payment Verification (SPV) clients. However, concerns have been raised about its impact on existing SPV clients' willingness to adopt it compared to the current bloom filter garbage.The size of the filters used in BIP 158 has been questioned as they may discourage the use of this new approach by existing SPV clients. To overcome this, further exploration is needed to find ways to split out filters and reduce bandwidth usage. A suggestion made is to provide filters specifically designed for certain script templates, such as retrieving outputs that are a specific segwit version X. This targeted filtering could potentially decrease the overall bandwidth required for transactions.It is hoped that by implementing these improvements, the adoption of BIP 158 can be encouraged among SPV clients without compromising their efficiency or willingness to use this enhanced security measure. The discussions on the bitcoin-dev mailing list revolve around finding solutions to improve the implementation of block filters, reducing filter sizes, and enhancing security in decentralized networks that store money. Various suggestions and considerations regarding the filtering process and its impact on lite clients, bandwidth, and network security are being discussed. Further exploration is needed to address concerns about the size of filters used in BIP 158 and their potential impact on existing SPV clients' adoption of the proposal. Splitting out filters based on data type and providing filters specifically designed for certain script templates are suggested approaches to reduce bandwidth usage. These improvements aim to encourage the adoption of BIP 158 while maintaining efficiency and willingness among SPV clients to use this enhanced security measure. 2018-06-12T23:58:50+00:00 + The conversation on the bitcoin-dev mailing list revolves around the implementation of new filter formats and commitments for Bitcoin. One proposal suggests excluding OP_RETURN outputs from BIP-158 filters to avoid polluting the filters. The Tier Nolan proposal, which creates a constant-sized proof for future commitments, is viewed as an ugly hack and difficult to implement "full" validation. There is a debate about optimizing for better security or lower bandwidth.The cost and practicality of the current filter design are also discussed. Adding more commitments is seen as a priority, and coordination for an ultimate extensible commitment is suggested. However, the current filter format cannot be committed due to indexing issues. The debate focuses on the trade-off between security and bandwidth optimization.The proposal to change the way filters are created for Bitcoin transactions is also addressed. Currently, the "regular" filter includes the outpoint, but there is a suggestion to switch to including prev scripts instead. The debate focuses on the cost, practicality, and security implications of this change.Multi-layer filtering in BIP 157/158 is also discussed. The benefits of using a map instead of a filter for upper layers are discussed, along with the possibility of using multi-block filters. The process of removing unnecessary items or filters is ongoing, and custom filter types and batch fetching based on block height and numerical range are already defined in BIPs.Tamas Blummer conducted an analysis on the use of filters in Bitcoin history and found that certain filters were smaller than others. The savings from using these filters have been decreasing over time. Blummer also discussed the importance of lighter but SPV secure nodes in helping the network grow while maintaining security.There are debates about relying on a "single honest peer" security model, the current state of non-existing validation in SPV software, and the need for generalized proposals that allow for future extensibility.In conclusion, the discussions revolve around finding the optimal design for filters in light clients, considering factors such as security, efficiency, and data size. Various proposals and modifications have been suggested to improve the current system, and there is ongoing debate about the best approach.The bitcoin-dev mailing list has been engaged in discussions about improving the implementation of block filters, reducing filter sizes, and enhancing security in decentralized networks that store money. The possibility of splitting the basic filter into separate filters based on data type is mentioned, along with potential solutions to address bandwidth concerns. One proposal, BIP 158, aims to enhance the security and privacy of Simplified Payment Verification (SPV) clients. However, concerns have been raised about its impact on existing SPV clients' willingness to adopt it compared to the current bloom filter garbage.The size of the filters used in BIP 158 has been questioned as they may discourage the use of this new approach by existing SPV clients. To overcome this, further exploration is needed to find ways to split out filters and reduce bandwidth usage. A suggestion made is to provide filters specifically designed for certain script templates, such as retrieving outputs that are a specific segwit version X. This targeted filtering could potentially decrease the overall bandwidth required for transactions.It is hoped that by implementing these improvements, the adoption of BIP 158 can be encouraged among SPV clients without compromising their efficiency or willingness to use this enhanced security measure. The discussions on the bitcoin-dev mailing list revolve around finding solutions to improve the implementation of block filters, reducing filter sizes, and enhancing security in decentralized networks that store money. Various suggestions and considerations regarding the filtering process and its impact on lite clients, bandwidth, and network security are being discussed. Further exploration is needed to address concerns about the size of filters used in BIP 158 and their potential impact on existing SPV clients' adoption of the proposal. Splitting out filters based on data type and providing filters specifically designed for certain script templates are suggested approaches to reduce bandwidth usage. These improvements aim to encourage the adoption of BIP 158 while maintaining efficiency and willingness among SPV clients to use this enhanced security measure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_BIP-174-thoughts.xml b/static/bitcoin-dev/June_2018/combined_BIP-174-thoughts.xml index d417603d5e..179cc04f70 100644 --- a/static/bitcoin-dev/June_2018/combined_BIP-174-thoughts.xml +++ b/static/bitcoin-dev/June_2018/combined_BIP-174-thoughts.xml @@ -1,170 +1,231 @@ - + 2 Combined summary - BIP 174 thoughts - 2023-08-01T23:28:42.591997+00:00 - - Gregory Maxwell 2018-07-11 20:05:32+00:00 - - - Pieter Wuille 2018-07-11 18:27:11+00:00 - - - matejcik 2018-07-10 12:10:10+00:00 - - - Achow101 2018-07-06 18:59:50+00:00 - - - Pieter Wuille 2018-07-05 22:06:53+00:00 - - - William Casarin 2018-07-05 19:20:32+00:00 - - - Jason Les 2018-07-05 17:23:51+00:00 - - - matejcik 2018-07-05 11:52:02+00:00 - - - Pieter Wuille 2018-07-04 19:09:29+00:00 - - - Achow101 2018-07-04 18:35:16+00:00 - - - matejcik 2018-07-04 13:19:11+00:00 - - - Peter D. Gray 2018-06-29 20:31:21+00:00 - - - Achow101 2018-06-29 19:12:27+00:00 - - - matejcik 2018-06-29 09:53:34+00:00 - - - Rodolfo Novak 2018-06-28 20:42:09+00:00 - - - Achow101 2018-06-27 17:55:59+00:00 - - - Pieter Wuille 2018-06-27 15:06:39+00:00 - - - matejcik 2018-06-27 14:11:49+00:00 - - - matejcik 2018-06-27 14:04:06+00:00 - - - Andrea 2018-06-27 13:39:02+00:00 - - - William Casarin 2018-06-27 06:09:09+00:00 - - - Achow101 2018-06-26 21:56:26+00:00 - - - Pieter Wuille 2018-06-26 20:30:04+00:00 - - - Marek Palatinus 2018-06-26 17:11:05+00:00 - - - William Casarin 2018-06-26 16:58:18+00:00 - - - matejcik 2018-06-26 15:33:14+00:00 - - - Achow101 2018-06-25 20:30:28+00:00 - - - Jonas Schnelli 2018-06-25 20:10:12+00:00 - - - Tomas Susanka 2018-06-25 19:47:59+00:00 - - - Andrea 2018-06-24 09:00:53+00:00 - - - Andrew Chow 2018-06-24 08:28:26+00:00 - - - Andrea 2018-06-24 08:19:00+00:00 - - - Andrew Chow 2018-06-23 20:33:11+00:00 - - - Peter D. Gray 2018-06-23 18:27:15+00:00 - - - William Casarin 2018-06-23 17:00:18+00:00 - - - Achow101 2018-06-22 22:28:33+00:00 - - - Pieter Wuille 2018-06-22 19:10:15+00:00 - - - Gregory Maxwell 2018-06-21 21:39:20+00:00 - - - Peter D. Gray 2018-06-21 20:28:15+00:00 - - - Peter D. Gray 2018-06-21 19:56:54+00:00 - - - Pieter Wuille 2018-06-21 17:39:57+00:00 - - - Greg Sanders 2018-06-21 15:40:04+00:00 - - - Tomas Susanka 2018-06-21 14:32:07+00:00 - - - Tomas Susanka 2018-06-21 11:44:37+00:00 - - - matejcik 2018-06-21 11:29:44+00:00 - - - Achow101 2018-06-21 00:39:05+00:00 - - - Jason Les 2018-06-20 00:39:46+00:00 - - - Pieter Wuille 2018-06-19 17:16:51+00:00 - - - Jonas Schnelli 2018-06-19 15:20:34+00:00 - - - matejcik 2018-06-19 14:22:30+00:00 - - - matejcik 2018-06-19 14:20:03+00:00 - - - Jonas Schnelli 2018-06-19 09:38:24+00:00 - - - Peter D. Gray 2018-06-16 15:00:40+00:00 - - - Pieter Wuille 2018-06-15 23:34:40+00:00 - + 2025-09-26T15:47:17.904551+00:00 + python-feedgen + + + [bitcoin-dev] BIP 174 thoughts Pieter Wuille + 2018-06-15T23:34:00.000Z + + + Peter D. Gray + 2018-06-16T15:00:00.000Z + + + Jonas Schnelli + 2018-06-19T09:38:00.000Z + + + matejcik + 2018-06-19T14:20:00.000Z + + + matejcik + 2018-06-19T14:22:00.000Z + + + Jonas Schnelli + 2018-06-19T15:20:00.000Z + + + Pieter Wuille + 2018-06-19T17:16:00.000Z + + + Jason Les + 2018-06-20T00:39:00.000Z + + + Achow101 + 2018-06-21T00:39:00.000Z + + + matejcik + 2018-06-21T11:29:00.000Z + + + Tomas Susanka + 2018-06-21T11:44:00.000Z + + + Tomas Susanka + 2018-06-21T14:32:00.000Z + + + Greg Sanders + 2018-06-21T15:40:00.000Z + + + Pieter Wuille + 2018-06-21T17:39:00.000Z + + + Peter D. Gray + 2018-06-21T19:56:00.000Z + + + Peter D. Gray + 2018-06-21T20:28:00.000Z + + + Gregory Maxwell + 2018-06-21T21:39:00.000Z + + + Pieter Wuille + 2018-06-22T19:10:00.000Z + + + Achow101 + 2018-06-22T22:28:00.000Z + + + William Casarin + 2018-06-23T17:00:00.000Z + + + Peter D. Gray + 2018-06-23T18:27:00.000Z + + + Andrew Chow + 2018-06-23T20:33:00.000Z + + + Andrea + 2018-06-24T08:19:00.000Z + + + Andrew Chow + 2018-06-24T08:28:00.000Z + + + Andrea + 2018-06-24T09:00:00.000Z + + + Tomas Susanka + 2018-06-25T19:47:00.000Z + + + Jonas Schnelli + 2018-06-25T20:10:00.000Z + + + Achow101 + 2018-06-25T20:30:00.000Z + + + matejcik + 2018-06-26T15:33:00.000Z + + + William Casarin + 2018-06-26T16:58:00.000Z + + + Marek Palatinus + 2018-06-26T17:11:00.000Z + + + Pieter Wuille + 2018-06-26T20:30:00.000Z + + + [bitcoin-dev] BIP 174 thoughts Achow101 + 2018-06-26T21:56:00.000Z + + + William Casarin + 2018-06-27T06:09:00.000Z + + + Andrea + 2018-06-27T13:39:00.000Z + + + matejcik + 2018-06-27T14:04:00.000Z + + + matejcik + 2018-06-27T14:11:00.000Z + + + Pieter Wuille + 2018-06-27T15:06:00.000Z + + + Achow101 + 2018-06-27T17:55:00.000Z + + + Rodolfo Novak + 2018-06-28T20:42:00.000Z + + + matejcik + 2018-06-29T09:53:00.000Z + + + Achow101 + 2018-06-29T19:12:00.000Z + + + Peter D. Gray + 2018-06-29T20:31:00.000Z + + + matejcik + 2018-07-04T13:19:00.000Z + + + Achow101 + 2018-07-04T18:35:00.000Z + + + Pieter Wuille + 2018-07-04T19:09:00.000Z + + + matejcik + 2018-07-05T11:52:00.000Z + + + Jason Les + 2018-07-05T17:23:00.000Z + + + William Casarin + 2018-07-05T19:20:00.000Z + + + Pieter Wuille + 2018-07-05T22:06:00.000Z + + + Achow101 + 2018-07-06T18:59:00.000Z + + + matejcik + 2018-07-10T12:10:00.000Z + + + Pieter Wuille + 2018-07-11T18:27:00.000Z + + + Gregory Maxwell + 2018-07-11T20:05:00.000Z + + + [bitcoin-dev] BIP 174 thoughts on graphics vv01f + 2018-07-11T20:54:00.000Z + + @@ -219,13 +280,13 @@ - python-feedgen + 2 Combined summary - BIP 174 thoughts - 2023-08-01T23:28:42.592994+00:00 + 2025-09-26T15:47:17.909828+00:00 - The discussion among Bitcoin developers regarding the policy for signing Bitcoin transactions with extra metadata has raised concerns about the potential difficulty of implementing new features that require extra data. The fear is that if signers are allowed to refuse to sign because of extra fields, it would create pressure to find places to stuff the extra data where it won't interfere with already deployed signers. This would be unfortunate as PSBT was created specifically to avoid field stuffing.In a recent email exchange among developers, it was suggested to add a statement to the Partially Signed Bitcoin Transaction (PSBT) specification to explain that the result of combining two PSBTs from independent participants should be functionally equivalent to processing the original PSBT by A and then B in a sequence. The rationale behind this is that Combiners can always be replaced with just a different topology of data flow. In terms of conflicts between values, the Combiner which picks arbitrarily will not end up with something worse than what is already needed to deal with.The discussion revolves around the possibility of malicious conflicting values in a scenario where one signer produces an invalid signature or modifies any of the other fields already present in the PSBT for consumption by others. It is believed that combiners can always be replaced with just a different topology of data flow since it does not make a difference. The Combiner, which picks arbitrarily in case of conflicts, will never end up with something worse than what one already needs to deal with.In an email thread between Andrew, William Casarin and Jason Les, William expressed concern about the format of parsing key-value maps arrays. He stated that "you can only parse the format properly by first deserializing the transaction. Since there is no 'length' field for the key-value map arrays, you must count the number of transaction input/outputs and use that as the number of kv maps to parse." However, Andrew disagreed and stated that this was not a problem since almost all roles have to deserialize the unsigned tx before they can do anything.The conversation revolves around the safety concerns of allowing combiners to arbitrarily choose a value. It is stated that conflicts in UTXOs, sighash type, redeem/witness scripts, derivation paths, etc. can cause recoverable or unrecoverable errors and sometimes indicate malicious activity. The safest option is to reject conflicts but allow intelligent processing by combiners if they understand the relevant fields.The concern raised in this context is regarding the format of PSBT (partially signed Bitcoin transaction). The writer points out that the format is confusing and can only be parsed by deserializing the transaction. They explain that there is no "length" field for the key-value map arrays, which means that the number of kv maps to parse must be counted based on the number of transaction input/outputs. This process is brittle because if a Combiner writes the wrong number of key-value maps that do not align with the number of inputs and outputs in the transaction, then the PSBT will not be able to be deserialized properly, but it will still be a valid PSBT.There has been a suggestion to standardize file names used when creating .psbt files to ensure reliability and avoid collisions. This would involve using an 8 character trim of the hash of the unsigned transaction, followed by the role that created the file (such as 'Signer'), and then a 4 character trim of the hash of data unique to that role (such as 'partial sig').In a discussion surrounding the Bitcoin wallet standard, Partially Signed Bitcoin Transactions (PSBT), contributors debated whether or not to allow combiners to choose any value in cases of conflicts within the transaction. Concerns were raised that conflicts in certain fields could be at best a recoverable error and at worst malicious activity, making it generally safer to default to rejecting conflicts, and explicitly allowing the Combiner to process them intelligently if it understands the relevant fields.In an email conversation, some concerns have been raised about the strictness and security properties of BIP. The first issue is regarding choosing from duplicate keys when combining. The proposal is to either change the resolution strategy or explain why picking at random is safe. However, outlawing conflicting values would force all signers to implement fixed deterministic nonce generation, which may result in PSBTs that got copied and signed and combined again failing. So, a better approach would be to choose the keys in such a way that picking arbitrarily is safe. Another issue is regarding signing records with unknown keys. It is suggested to codify the behavior in the standard or mark a field as "optional" so that strict signers know they can safely ignore the unknown field. However, there may not be a situation where this is needed, and signers generally inspect transactions they're signing.The email author expresses concerns about the strictness and security properties of Bitcoin Improvement Proposal (BIP). They suggest changing the strategy for choosing from duplicate keys when combining or providing a detailed explanation 2018-07-11T20:05:32+00:00 + The discussion among Bitcoin developers regarding the policy for signing Bitcoin transactions with extra metadata has raised concerns about the potential difficulty of implementing new features that require extra data. The fear is that if signers are allowed to refuse to sign because of extra fields, it would create pressure to find places to stuff the extra data where it won't interfere with already deployed signers. This would be unfortunate as PSBT was created specifically to avoid field stuffing.In a recent email exchange among developers, it was suggested to add a statement to the Partially Signed Bitcoin Transaction (PSBT) specification to explain that the result of combining two PSBTs from independent participants should be functionally equivalent to processing the original PSBT by A and then B in a sequence. The rationale behind this is that Combiners can always be replaced with just a different topology of data flow. In terms of conflicts between values, the Combiner which picks arbitrarily will not end up with something worse than what is already needed to deal with.The discussion revolves around the possibility of malicious conflicting values in a scenario where one signer produces an invalid signature or modifies any of the other fields already present in the PSBT for consumption by others. It is believed that combiners can always be replaced with just a different topology of data flow since it does not make a difference. The Combiner, which picks arbitrarily in case of conflicts, will never end up with something worse than what one already needs to deal with.In an email thread between Andrew, William Casarin and Jason Les, William expressed concern about the format of parsing key-value maps arrays. He stated that "you can only parse the format properly by first deserializing the transaction. Since there is no 'length' field for the key-value map arrays, you must count the number of transaction input/outputs and use that as the number of kv maps to parse." However, Andrew disagreed and stated that this was not a problem since almost all roles have to deserialize the unsigned tx before they can do anything.The conversation revolves around the safety concerns of allowing combiners to arbitrarily choose a value. It is stated that conflicts in UTXOs, sighash type, redeem/witness scripts, derivation paths, etc. can cause recoverable or unrecoverable errors and sometimes indicate malicious activity. The safest option is to reject conflicts but allow intelligent processing by combiners if they understand the relevant fields.The concern raised in this context is regarding the format of PSBT (partially signed Bitcoin transaction). The writer points out that the format is confusing and can only be parsed by deserializing the transaction. They explain that there is no "length" field for the key-value map arrays, which means that the number of kv maps to parse must be counted based on the number of transaction input/outputs. This process is brittle because if a Combiner writes the wrong number of key-value maps that do not align with the number of inputs and outputs in the transaction, then the PSBT will not be able to be deserialized properly, but it will still be a valid PSBT.There has been a suggestion to standardize file names used when creating .psbt files to ensure reliability and avoid collisions. This would involve using an 8 character trim of the hash of the unsigned transaction, followed by the role that created the file (such as 'Signer'), and then a 4 character trim of the hash of data unique to that role (such as 'partial sig').In a discussion surrounding the Bitcoin wallet standard, Partially Signed Bitcoin Transactions (PSBT), contributors debated whether or not to allow combiners to choose any value in cases of conflicts within the transaction. Concerns were raised that conflicts in certain fields could be at best a recoverable error and at worst malicious activity, making it generally safer to default to rejecting conflicts, and explicitly allowing the Combiner to process them intelligently if it understands the relevant fields.In an email conversation, some concerns have been raised about the strictness and security properties of BIP. The first issue is regarding choosing from duplicate keys when combining. The proposal is to either change the resolution strategy or explain why picking at random is safe. However, outlawing conflicting values would force all signers to implement fixed deterministic nonce generation, which may result in PSBTs that got copied and signed and combined again failing. So, a better approach would be to choose the keys in such a way that picking arbitrarily is safe. Another issue is regarding signing records with unknown keys. It is suggested to codify the behavior in the standard or mark a field as "optional" so that strict signers know they can safely ignore the unknown field. However, there may not be a situation where this is needed, and signers generally inspect transactions they're signing.The email author expresses concerns about the strictness and security properties of Bitcoin Improvement Proposal (BIP). They suggest changing the strategy for choosing from duplicate keys when combining or providing a detailed explanation - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml b/static/bitcoin-dev/June_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml index ae34a4ef91..53067d4e58 100644 --- a/static/bitcoin-dev/June_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml +++ b/static/bitcoin-dev/June_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml @@ -1,41 +1,47 @@ - + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 - - Giulia Fanti 2018-07-08 12:50:43+00:00 - - - Gregory Maxwell 2018-06-26 05:20:02+00:00 - - - Bradley Denby 2018-06-26 00:12:02+00:00 - - - Pieter Wuille 2018-06-12 01:05:14+00:00 - - - Bradley Denby 2018-06-11 14:31:09+00:00 - - - Pieter Wuille 2018-06-06 04:01:00+00:00 - - - Bradley Denby 2018-06-04 20:29:50+00:00 - - - Bradley Denby 2018-05-10 12:59:12+00:00 - - - Giulia Fanti 2017-09-21 02:10:29+00:00 - - - Gregory Maxwell 2017-06-13 01:00:50+00:00 - - - Andrew Miller 2017-06-12 14:46:23+00:00 - + 2025-09-26T15:46:58.849169+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation Bradley Denby + 2018-05-10T12:59:00.000Z + + + Bradley Denby + 2018-06-04T20:29:00.000Z + + + Pieter Wuille + 2018-06-06T04:01:00.000Z + + + Bradley Denby + 2018-06-11T14:31:00.000Z + + + Pieter Wuille + 2018-06-12T01:05:00.000Z + + + Bradley Denby + 2018-06-26T00:12:00.000Z + + + Gregory Maxwell + 2018-06-26T05:20:00.000Z + + + Neudecker, Till (TM) + 2018-07-05T14:50:00.000Z + + + Giulia Fanti + 2018-07-08T12:50:00.000Z + + @@ -47,13 +53,13 @@ - python-feedgen + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 + 2025-09-26T15:46:58.850351+00:00 - The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality 2018-07-08T12:50:43+00:00 + The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_BIP-suggestion-PoW-proportional-to-block-transaction-sum.xml b/static/bitcoin-dev/June_2018/combined_BIP-suggestion-PoW-proportional-to-block-transaction-sum.xml index 0b785e4aaf..df41537f1b 100644 --- a/static/bitcoin-dev/June_2018/combined_BIP-suggestion-PoW-proportional-to-block-transaction-sum.xml +++ b/static/bitcoin-dev/June_2018/combined_BIP-suggestion-PoW-proportional-to-block-transaction-sum.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP suggestion: PoW proportional to block transaction sum - 2023-08-01T23:20:26.341262+00:00 - - Darren Weber 2018-06-06 21:01:22+00:00 - - - Thomas Guyot-Sionnest 2018-06-05 10:50:35+00:00 - - - Darren Weber 2018-05-30 16:17:29+00:00 - + 2025-09-26T15:46:54.639125+00:00 + python-feedgen + + + [bitcoin-dev] BIP suggestion: PoW proportional to block transaction sum Darren Weber + 2018-05-30T16:17:00.000Z + + + Thomas Guyot-Sionnest + 2018-06-05T10:50:00.000Z + + + Darren Weber + 2018-06-06T21:01:00.000Z + + - python-feedgen + 2 Combined summary - BIP suggestion: PoW proportional to block transaction sum - 2023-08-01T23:20:26.341262+00:00 + 2025-09-26T15:46:54.639427+00:00 - Darren Weber, a Bitcoin developer, has proposed a new idea on the Bitcoin Github page to enhance security against double-spending attacks. The proposal suggests introducing a hash workload that is proportional to the sum of transactions in a block. The aim is to make it more challenging for malicious attackers to double-spend large amounts by utilizing a relatively brief majority of the network hashing power.However, Thomas Guyot-Sionnest raises concerns about the implementation of this idea. He points out that users may resort to keeping large amounts in multiple smaller addresses to avoid penalties on small transactions. This could lead to an increase in Unspent Transaction Output (UTXO) size for everyone. Moreover, the proposal would require strong consensus and a hard fork, which might not be deemed worthwhile by some.Darren Weber acknowledges that he does not possess sufficient authority to answer implementation-related questions at this stage. However, he intends to carefully consider the points raised by Guyot-Sionnest before proceeding further with the idea.The proposal on Github has generated discussions regarding its potential benefits and drawbacks. Some believe that introducing a hash workload proportional to transaction sums could enhance security against double-spending attacks. Others express concerns about excluding transactions based on their economic value and the possible negative consequences, such as increased UTXO size for all users. Furthermore, implementing the proposal would necessitate good consensus and a hard fork, leading to differing opinions on whether it is worth pursuing.In conclusion, Darren's suggestion to introduce a hash workload proportional to the sum of transactions in a block aims to strengthen security against double-spending attacks. However, there are various considerations and challenges, including potential side-effects and the requirement for consensus and a hard fork. The proposal has sparked debates within the Bitcoin community, with proponents highlighting its potential benefits and others expressing reservations about its feasibility and impact. Darren plans to explore the idea further, taking into account the concerns raised by Thomas Guyot-Sionnest. 2018-06-06T21:01:22+00:00 + Darren Weber, a Bitcoin developer, has proposed a new idea on the Bitcoin Github page to enhance security against double-spending attacks. The proposal suggests introducing a hash workload that is proportional to the sum of transactions in a block. The aim is to make it more challenging for malicious attackers to double-spend large amounts by utilizing a relatively brief majority of the network hashing power.However, Thomas Guyot-Sionnest raises concerns about the implementation of this idea. He points out that users may resort to keeping large amounts in multiple smaller addresses to avoid penalties on small transactions. This could lead to an increase in Unspent Transaction Output (UTXO) size for everyone. Moreover, the proposal would require strong consensus and a hard fork, which might not be deemed worthwhile by some.Darren Weber acknowledges that he does not possess sufficient authority to answer implementation-related questions at this stage. However, he intends to carefully consider the points raised by Guyot-Sionnest before proceeding further with the idea.The proposal on Github has generated discussions regarding its potential benefits and drawbacks. Some believe that introducing a hash workload proportional to transaction sums could enhance security against double-spending attacks. Others express concerns about excluding transactions based on their economic value and the possible negative consequences, such as increased UTXO size for all users. Furthermore, implementing the proposal would necessitate good consensus and a hard fork, leading to differing opinions on whether it is worth pursuing.In conclusion, Darren's suggestion to introduce a hash workload proportional to the sum of transactions in a block aims to strengthen security against double-spending attacks. However, there are various considerations and challenges, including potential side-effects and the requirement for consensus and a hard fork. The proposal has sparked debates within the Bitcoin community, with proponents highlighting its potential benefits and others expressing reservations about its feasibility and impact. Darren plans to explore the idea further, taking into account the concerns raised by Thomas Guyot-Sionnest. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_BIP039-How-to-add-a-Portuguese-wordlist-.xml b/static/bitcoin-dev/June_2018/combined_BIP039-How-to-add-a-Portuguese-wordlist-.xml index 85402f16b0..9cec376d97 100644 --- a/static/bitcoin-dev/June_2018/combined_BIP039-How-to-add-a-Portuguese-wordlist-.xml +++ b/static/bitcoin-dev/June_2018/combined_BIP039-How-to-add-a-Portuguese-wordlist-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP039 - How to add a Portuguese wordlist? - 2023-08-01T23:32:32.294936+00:00 - - AJ West 2018-06-30 15:12:32+00:00 - - - Breno Brito 2018-06-26 15:58:53+00:00 - + 2025-09-26T15:47:09.451366+00:00 + python-feedgen + + + [bitcoin-dev] BIP039 - How to add a Portuguese wordlist? Breno Brito + 2018-06-26T15:58:00.000Z + + + AJ West + 2018-06-30T15:12:00.000Z + + - python-feedgen + 2 Combined summary - BIP039 - How to add a Portuguese wordlist? - 2023-08-01T23:32:32.294936+00:00 + 2025-09-26T15:47:09.451880+00:00 - In a discussion on improving multilingual usage of BIP39, it was suggested that a standard way should be established to convert any words into a hex string, regardless of the language or character encoding. This is in response to the rhetoric that only English words are needed, highlighting the importance of supporting all languages for a standard in wallet seed generation.While there is currently no official Portuguese wordlist or multilingual standard, the ongoing discussion emphasizes the need to start choosing and codifying a standard. To contribute to this effort, a GitHub user has initiated the creation of a Portuguese wordlist which could be beneficial for expanding the BIP039 wordlist.Recognizing the significance of Portuguese as the 6th most spoken language globally and an official language in 10 countries, Breno is interested in proposing the expansion of the BIP039 wordlist to include Portuguese. He is seeking guidance on the steps he should take to make this proposal or to offer assistance if it has already been proposed. 2018-06-30T15:12:32+00:00 + In a discussion on improving multilingual usage of BIP39, it was suggested that a standard way should be established to convert any words into a hex string, regardless of the language or character encoding. This is in response to the rhetoric that only English words are needed, highlighting the importance of supporting all languages for a standard in wallet seed generation.While there is currently no official Portuguese wordlist or multilingual standard, the ongoing discussion emphasizes the need to start choosing and codifying a standard. To contribute to this effort, a GitHub user has initiated the creation of a Portuguese wordlist which could be beneficial for expanding the BIP039 wordlist.Recognizing the significance of Portuguese as the 6th most spoken language globally and an official language in 10 countries, Breno is interested in proposing the expansion of the BIP039 wordlist to include Portuguese. He is seeking guidance on the steps he should take to make this proposal or to offer assistance if it has already been proposed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_BetterHash-status.xml b/static/bitcoin-dev/June_2018/combined_BetterHash-status.xml index c74ea3d4ee..891b069d44 100644 --- a/static/bitcoin-dev/June_2018/combined_BetterHash-status.xml +++ b/static/bitcoin-dev/June_2018/combined_BetterHash-status.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BetterHash status - 2023-08-01T23:32:23.217051+00:00 - - Matt Corallo 2018-06-26 14:44:02+00:00 - - - Casciano, Anthony 2018-06-26 14:32:06+00:00 - + 2025-09-26T15:46:44.131212+00:00 + python-feedgen + + + [bitcoin-dev] BetterHash status Casciano, Anthony + 2018-06-26T14:32:00.000Z + + + Matt Corallo + 2018-06-26T14:44:00.000Z + + - python-feedgen + 2 Combined summary - BetterHash status - 2023-08-01T23:32:23.217051+00:00 + 2025-09-26T15:46:44.131645+00:00 - Anthony Casciano recently inquired about the status of Matt Corallo's "BetterHash" BIP through the bitcoin-dev mailing list. In his message, Casciano expressed his belief that the implementation should be put into production sooner rather than later and requested a second opinion. However, it is important to note that the decision to put things into production ultimately relies on people choosing to adopt them.Unfortunately, the context does not provide specific details or updates regarding the "BetterHash" BIP. It is unclear what kind of information Casciano was seeking. Nonetheless, those interested in contributing to the implementation of the BIP can do so by visiting the GitHub repository at https://github.com/TheBlueMatt/mining-proxy. 2018-06-26T14:44:02+00:00 + Anthony Casciano recently inquired about the status of Matt Corallo's "BetterHash" BIP through the bitcoin-dev mailing list. In his message, Casciano expressed his belief that the implementation should be put into production sooner rather than later and requested a second opinion. However, it is important to note that the decision to put things into production ultimately relies on people choosing to adopt them.Unfortunately, the context does not provide specific details or updates regarding the "BetterHash" BIP. It is unclear what kind of information Casciano was seeking. Nonetheless, those interested in contributing to the implementation of the BIP can do so by visiting the GitHub repository at https://github.com/TheBlueMatt/mining-proxy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_Disallow-insecure-use-of-SIGHASH-SINGLE.xml b/static/bitcoin-dev/June_2018/combined_Disallow-insecure-use-of-SIGHASH-SINGLE.xml index 6bb27c8e7d..26a6475f47 100644 --- a/static/bitcoin-dev/June_2018/combined_Disallow-insecure-use-of-SIGHASH-SINGLE.xml +++ b/static/bitcoin-dev/June_2018/combined_Disallow-insecure-use-of-SIGHASH-SINGLE.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Disallow insecure use of SIGHASH_SINGLE - 2023-08-01T23:25:38.378361+00:00 - - Peter Todd 2018-06-06 00:49:01+00:00 - - - Peter Todd 2018-06-06 00:43:26+00:00 - - - Chris Stewart 2018-06-06 00:17:52+00:00 - - - Johnson Lau 2018-05-31 18:53:01+00:00 - + 2025-09-26T15:46:48.310508+00:00 + python-feedgen + + + [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE Johnson Lau + 2018-05-31T18:53:00.000Z + + + Chris Stewart + 2018-06-06T00:17:00.000Z + + + Peter Todd + 2018-06-06T00:43:00.000Z + + + Peter Todd + 2018-06-06T00:49:00.000Z + + - python-feedgen + 2 Combined summary - Disallow insecure use of SIGHASH_SINGLE - 2023-08-01T23:25:38.378361+00:00 + 2025-09-26T15:46:48.311192+00:00 - A proposal has been made to change the Bitcoin core code in order to disallow the usage of SIGHASH_SINGLE without matched output. This signature form is considered insecure as it commits to no output, which may mislead users into thinking that it commits to one. The issue becomes more problematic in non-segwit scripts, making it easier for any UTXO of the same key to be stolen. The developer suggests implementing a softfork to disable this unintended consensus behavior, as these signatures are inherently unsafe.However, another developer questions the need for a softfork on security grounds and proposes that it may be better to consider soft-forking the code out based on code complexity instead. Additionally, there is uncertainty about whether the non-standardness of the signature means it is secure.In a discussion on the bitcoin-dev mailing list, the possibility of expanding to SIGHASH_NONE is raised. It is noted that SIGHASH_NONE is important because it allows multisig signers to relinquish the need to sign without giving up the private key. The SIGHASH_SINGLE bug can also be used in similar ways.The proposed policy aims to prevent the usage of SIGHASH_SINGLE without matched output. This signature form is considered insecure as it commits to no output, leading to potential theft of any UTXO of the same key in non-segwit scripts. This unintended consensus behavior is among the earliest ones and is inherently unsafe. To disable this feature with a softfork, the first step is to make these signatures non-standard. A pull request has already been made to add this policy to Bitcoin's Github repository. Currently, these signatures are allowed, so making them non-standard is the initial step towards disabling them. 2018-06-06T00:49:01+00:00 + A proposal has been made to change the Bitcoin core code in order to disallow the usage of SIGHASH_SINGLE without matched output. This signature form is considered insecure as it commits to no output, which may mislead users into thinking that it commits to one. The issue becomes more problematic in non-segwit scripts, making it easier for any UTXO of the same key to be stolen. The developer suggests implementing a softfork to disable this unintended consensus behavior, as these signatures are inherently unsafe.However, another developer questions the need for a softfork on security grounds and proposes that it may be better to consider soft-forking the code out based on code complexity instead. Additionally, there is uncertainty about whether the non-standardness of the signature means it is secure.In a discussion on the bitcoin-dev mailing list, the possibility of expanding to SIGHASH_NONE is raised. It is noted that SIGHASH_NONE is important because it allows multisig signers to relinquish the need to sign without giving up the private key. The SIGHASH_SINGLE bug can also be used in similar ways.The proposed policy aims to prevent the usage of SIGHASH_SINGLE without matched output. This signature form is considered insecure as it commits to no output, leading to potential theft of any UTXO of the same key in non-segwit scripts. This unintended consensus behavior is among the earliest ones and is inherently unsafe. To disable this feature with a softfork, the first step is to make these signatures non-standard. A pull request has already been made to add this policy to Bitcoin's Github repository. Currently, these signatures are allowed, so making them non-standard is the initial step towards disabling them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_Graftroot-Private-and-efficient-surrogate-scripts-under-the-taproot-assumption.xml b/static/bitcoin-dev/June_2018/combined_Graftroot-Private-and-efficient-surrogate-scripts-under-the-taproot-assumption.xml index b836e9f731..717802d86b 100644 --- a/static/bitcoin-dev/June_2018/combined_Graftroot-Private-and-efficient-surrogate-scripts-under-the-taproot-assumption.xml +++ b/static/bitcoin-dev/June_2018/combined_Graftroot-Private-and-efficient-surrogate-scripts-under-the-taproot-assumption.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Graftroot: Private and efficient surrogate scripts under the taproot assumption - 2023-08-01T22:36:03.841733+00:00 - - Sjors Provoost 2018-06-30 11:49:36+00:00 - - - Gregory Maxwell 2018-02-24 18:58:59+00:00 - - - Daniel Edgecumbe 2018-02-22 19:44:21+00:00 - - - Ryan Grant 2018-02-22 12:19:36+00:00 - - - Jeremy 2018-02-09 07:42:52+00:00 - - - Jeremy 2018-02-09 07:29:58+00:00 - - - Gregory Maxwell 2018-02-05 19:58:24+00:00 - - - Ryan Grant 2018-02-05 15:56:23+00:00 - - - Gregory Maxwell 2018-02-05 05:58:43+00:00 - + 2025-09-26T15:46:46.222752+00:00 + python-feedgen + + + [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption Gregory Maxwell + 2018-02-05T05:58:00.000Z + + + Ryan Grant + 2018-02-05T15:56:00.000Z + + + Gregory Maxwell + 2018-02-05T19:58:00.000Z + + + Jeremy + 2018-02-09T07:29:00.000Z + + + Jeremy + 2018-02-09T07:42:00.000Z + + + Ryan Grant + 2018-02-22T12:19:00.000Z + + + Daniel Edgecumbe + 2018-02-22T19:44:00.000Z + + + Gregory Maxwell + 2018-02-24T18:58:00.000Z + + + Sjors Provoost + 2018-06-30T11:49:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Graftroot: Private and efficient surrogate scripts under the taproot assumption - 2023-08-01T22:36:03.841733+00:00 + 2025-09-26T15:46:46.223913+00:00 - On February 22nd, 2018, a suggestion was made by Jeremy on the Bitcoin-dev list to improve the utility of a construction by introducing functionality that makes a script invalid after a certain time. This suggestion was discussed in a thread tagged with "nExpiryTime" and users were encouraged to search the archives for more information. The term "fill-or-kill transaction" was also mentioned in a previous discussion on the same list in September 2015. The post was signed off by Sjors.In a recent email conversation on the bitcoin-dev mailing list, Daniel Edgecumbe proposed a method to bind grafts to a specific transaction without requiring aggregation. He suggested signing H(txid, script) instead of H(script), but its impact on aggregation is unknown. This method requires knowing the txid in advance, which can be handled by a graftroot sighash flag. However, in most cases, the txid is not known. Another alternative solution is signing a transaction spending the multisig coin to the graft, but it lacks atomicity, scalability, and privacy. The advantage of the aggregation approach is that it works just in time even on grafts created in advance. A non-interactive schnorr aggregation trick can be used to merge the S values of all graftroots and signatures into a single aggregate, reducing overhead to ~32 bytes, similar to taproot's overhead.The discussion on the Bitcoin-dev mailing list focuses on the case where a delegate is signed conditional on another delegate being signed. Participants suggest the need for something like segwit internally to refer to one side's delegation using a signature-stable identity, but no good solution is currently available. Another point raised in the discussion is the introduction of functionality to make a script invalid after a certain time, allowing exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. This construction enables unilateral key rotation without invalidating the interests of other parties in the existing multisig, requiring only storing the signed delegation.The email thread discusses the introduction of functionality to make a script invalid after a certain time, which can enhance the utility of a construction despite previous re-org behavior. Proposed timelocks would be valid before a certain time or block height and invalid after, allowing for exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. Unilateral key rotation is possible in a multisig setup without invalidating the interests of other parties, as long as all parties agree to add a new key while still allowing the old key to sign.The context suggests the existence of a method that enables unilateral key rotation in a multisig setup without invalidating the interests of other parties. This method does not require any on-chain transactions but involves storing the signed delegation. The Taproot protocol provides only one alternative natively, while the Graftroot protocol allows for an unlimited number of alternatives while maintaining efficiency and privacy. With Graftroot, participants can delegate their ability to sign to a surrogate script by signing just the script with their taproot key and sharing the delegation. When spending the coin, if the signers aren't available, the redeeming party satisfies the script and presents the information along with the signer's signature. Non-interactive schnorr aggregation can be applied to merge the S values of all graftroots and signatures into a single aggregate, lowering overhead to ~32 bytes. However, this approach requires interaction with participants and storage of resulting signatures. Graftroot allows delegation before or after the fact and requires storage. The potential for unexpected surrogate replay and the existence of unused surrogates are considerations to keep in mind. 2018-06-30T11:49:36+00:00 + On February 22nd, 2018, a suggestion was made by Jeremy on the Bitcoin-dev list to improve the utility of a construction by introducing functionality that makes a script invalid after a certain time. This suggestion was discussed in a thread tagged with "nExpiryTime" and users were encouraged to search the archives for more information. The term "fill-or-kill transaction" was also mentioned in a previous discussion on the same list in September 2015. The post was signed off by Sjors.In a recent email conversation on the bitcoin-dev mailing list, Daniel Edgecumbe proposed a method to bind grafts to a specific transaction without requiring aggregation. He suggested signing H(txid, script) instead of H(script), but its impact on aggregation is unknown. This method requires knowing the txid in advance, which can be handled by a graftroot sighash flag. However, in most cases, the txid is not known. Another alternative solution is signing a transaction spending the multisig coin to the graft, but it lacks atomicity, scalability, and privacy. The advantage of the aggregation approach is that it works just in time even on grafts created in advance. A non-interactive schnorr aggregation trick can be used to merge the S values of all graftroots and signatures into a single aggregate, reducing overhead to ~32 bytes, similar to taproot's overhead.The discussion on the Bitcoin-dev mailing list focuses on the case where a delegate is signed conditional on another delegate being signed. Participants suggest the need for something like segwit internally to refer to one side's delegation using a signature-stable identity, but no good solution is currently available. Another point raised in the discussion is the introduction of functionality to make a script invalid after a certain time, allowing exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. This construction enables unilateral key rotation without invalidating the interests of other parties in the existing multisig, requiring only storing the signed delegation.The email thread discusses the introduction of functionality to make a script invalid after a certain time, which can enhance the utility of a construction despite previous re-org behavior. Proposed timelocks would be valid before a certain time or block height and invalid after, allowing for exclusion of old delegates based on timing/block height arguments or pre-signing delegates for different periods of time. Unilateral key rotation is possible in a multisig setup without invalidating the interests of other parties, as long as all parties agree to add a new key while still allowing the old key to sign.The context suggests the existence of a method that enables unilateral key rotation in a multisig setup without invalidating the interests of other parties. This method does not require any on-chain transactions but involves storing the signed delegation. The Taproot protocol provides only one alternative natively, while the Graftroot protocol allows for an unlimited number of alternatives while maintaining efficiency and privacy. With Graftroot, participants can delegate their ability to sign to a surrogate script by signing just the script with their taproot key and sharing the delegation. When spending the coin, if the signers aren't available, the redeeming party satisfies the script and presents the information along with the signer's signature. Non-interactive schnorr aggregation can be applied to merge the S values of all graftroots and signatures into a single aggregate, lowering overhead to ~32 bytes. However, this approach requires interaction with participants and storage of resulting signatures. Graftroot allows delegation before or after the fact and requires storage. The potential for unexpected surrogate replay and the existence of unused surrogates are considerations to keep in mind. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_Miner-dilution-attack-on-Bitcoin-is-that-something-plausible-.xml b/static/bitcoin-dev/June_2018/combined_Miner-dilution-attack-on-Bitcoin-is-that-something-plausible-.xml index 42cfa16573..b4f5edbe1f 100644 --- a/static/bitcoin-dev/June_2018/combined_Miner-dilution-attack-on-Bitcoin-is-that-something-plausible-.xml +++ b/static/bitcoin-dev/June_2018/combined_Miner-dilution-attack-on-Bitcoin-is-that-something-plausible-.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Miner dilution attack on Bitcoin - is that something plausible? - 2023-08-01T23:32:17.516706+00:00 - - Richard Hein 2018-06-19 18:58:01+00:00 - - - Eric Voskuil 2018-06-19 13:54:27+00:00 - - - Bryan Bishop 2018-06-18 20:51:33+00:00 - - - Bram Cohen 2018-06-18 20:40:26+00:00 - - - Laszlo Hanyecz 2018-06-18 18:49:09+00:00 - - - Alexander Leishman 2018-06-18 18:47:40+00:00 - - - Артём Литвинович 2018-06-18 18:34:37+00:00 - + 2025-09-26T15:46:42.041699+00:00 + python-feedgen + + + [bitcoin-dev] Miner dilution attack on Bitcoin - is that something plausible? Артём Литвинович + 2018-06-18T18:34:00.000Z + + + Alexander Leishman + 2018-06-18T18:47:00.000Z + + + Laszlo Hanyecz + 2018-06-18T18:49:00.000Z + + + Bram Cohen + 2018-06-18T20:40:00.000Z + + + Bryan Bishop + 2018-06-18T20:51:00.000Z + + + Eric Voskuil + 2018-06-19T13:54:00.000Z + + + Richard Hein + 2018-06-19T18:58:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Miner dilution attack on Bitcoin - is that something plausible? - 2023-08-01T23:32:17.516706+00:00 + 2025-09-26T15:46:42.042528+00:00 - A potential attack called Dilution, discussed on the bitcoin-dev mailing list, involves a malicious actor acquiring a majority of hash power and producing valid but empty blocks. This would effectively reduce the block rate by half or more, and nodes would be unable to adjust difficulty or blacklist the attacker. The estimated cost for such an attack is $2 billion for equipment and $0.4 billion per month for power costs. The plausibility of this attack has been questioned, but there have been no convincing arguments against it yet.To mitigate this attack, the Other Means Principle has been proposed. This principle suggests that if an attack can be carried out using means other than Bitcoin's protocol, it should not be considered a protocol-level problem. In the case of Dilution, the attack relies on acquiring hash power, which is outside the scope of Bitcoin's protocol. Therefore, it should be mitigated by external means.The email conversation between Bram Cohen and Bryan discusses the possibility of an attacker conspiring to reduce block sizes to increase transaction fees. This could be done with a miner activated soft fork. While the block rate cannot be significantly increased or decreased in the long run due to work difficulty adjustment, an attacker could potentially produce empty blocks to disrupt the system or carry out a 51% attack.The potential impact of the "empty block fallacy" on the Bitcoin network has been a topic of debate among researchers and developers. Some argue that the risk of a malicious actor acquiring a majority of hash power is low, while others emphasize the need for stronger security measures. The ongoing challenges facing the Bitcoin network highlight the need for new solutions and improved security to ensure its stability.In conclusion, Dilution is a potential attack that raises concerns about the reduction of block rates through the production of empty blocks. The cost and feasibility of such an attack make it a plausible scenario. Mitigation strategies, such as the Other Means Principle, are proposed to address this vulnerability. Ongoing discussions and research are necessary to ensure the long-term stability and security of the Bitcoin network. 2018-06-19T18:58:01+00:00 + A potential attack called Dilution, discussed on the bitcoin-dev mailing list, involves a malicious actor acquiring a majority of hash power and producing valid but empty blocks. This would effectively reduce the block rate by half or more, and nodes would be unable to adjust difficulty or blacklist the attacker. The estimated cost for such an attack is $2 billion for equipment and $0.4 billion per month for power costs. The plausibility of this attack has been questioned, but there have been no convincing arguments against it yet.To mitigate this attack, the Other Means Principle has been proposed. This principle suggests that if an attack can be carried out using means other than Bitcoin's protocol, it should not be considered a protocol-level problem. In the case of Dilution, the attack relies on acquiring hash power, which is outside the scope of Bitcoin's protocol. Therefore, it should be mitigated by external means.The email conversation between Bram Cohen and Bryan discusses the possibility of an attacker conspiring to reduce block sizes to increase transaction fees. This could be done with a miner activated soft fork. While the block rate cannot be significantly increased or decreased in the long run due to work difficulty adjustment, an attacker could potentially produce empty blocks to disrupt the system or carry out a 51% attack.The potential impact of the "empty block fallacy" on the Bitcoin network has been a topic of debate among researchers and developers. Some argue that the risk of a malicious actor acquiring a majority of hash power is low, while others emphasize the need for stronger security measures. The ongoing challenges facing the Bitcoin network highlight the need for new solutions and improved security to ensure its stability.In conclusion, Dilution is a potential attack that raises concerns about the reduction of block rates through the production of empty blocks. The cost and feasibility of such an attack make it a plausible scenario. Mitigation strategies, such as the Other Means Principle, are proposed to address this vulnerability. Ongoing discussions and research are necessary to ensure the long-term stability and security of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_New-serialization-encoding-format-for-key-material.xml b/static/bitcoin-dev/June_2018/combined_New-serialization-encoding-format-for-key-material.xml index 18d1a2477c..b5820eee8b 100644 --- a/static/bitcoin-dev/June_2018/combined_New-serialization-encoding-format-for-key-material.xml +++ b/static/bitcoin-dev/June_2018/combined_New-serialization-encoding-format-for-key-material.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - New serialization/encoding format for key material - 2023-08-01T23:19:34.371665+00:00 - - Pieter Wuille 2018-06-23 19:49:54+00:00 - - - Russell O'Connor 2018-06-15 15:54:30+00:00 - - - Russell O'Connor 2018-06-13 14:58:33+00:00 - - - Pieter Wuille 2018-06-13 02:44:47+00:00 - - - Jonas Schnelli 2018-06-03 21:30:48+00:00 - - - Pieter Wuille 2018-06-03 19:23:17+00:00 - - - Jonas Schnelli 2018-06-03 16:51:09+00:00 - - - Jonas Schnelli 2018-05-30 19:03:46+00:00 - - - Gregory Maxwell 2018-05-30 14:08:08+00:00 - - - shiva sitamraju 2018-05-30 06:30:25+00:00 - - - Jonas Schnelli 2018-05-29 09:13:37+00:00 - + 2025-09-26T15:46:56.731619+00:00 + python-feedgen + + + [bitcoin-dev] New serialization/encoding format for key material Jonas Schnelli + 2018-05-29T09:13:00.000Z + + + shiva sitamraju + 2018-05-30T06:30:00.000Z + + + Gregory Maxwell + 2018-05-30T14:08:00.000Z + + + Jonas Schnelli + 2018-05-30T19:03:00.000Z + + + Jonas Schnelli + 2018-06-03T16:51:00.000Z + + + Pieter Wuille + 2018-06-03T19:23:00.000Z + + + Jonas Schnelli + 2018-06-03T21:30:00.000Z + + + Pieter Wuille + 2018-06-13T02:44:00.000Z + + + Russell O'Connor + 2018-06-13T14:58:00.000Z + + + Russell O'Connor + 2018-06-15T15:54:00.000Z + + + Pieter Wuille + 2018-06-23T19:49:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - New serialization/encoding format for key material - 2023-08-01T23:19:34.371665+00:00 + 2025-09-26T15:46:56.733170+00:00 - Pieter and Russell O'Connor have been discussing the correctable error rates of codes designed for length 341, which is the first length enough to support 512 bits of data. The number of correctable errors includes errors inside the checksum characters themselves, meaning that aiming for a certain percentage of correctable characters increases the numbers dramatically. Pieter provides some numbers for codes restricted to a total of 341 characters and assuming 103 data characters, including 26 checksum characters (adding 25%, 20% of overall string), seven errors can be corrected (5% of overall string). With 62 checksum characters (adding 60%, 38% of overall string), 17 errors can be corrected (10% of overall string). With 116 checksum characters (adding 113%, 53% of overall string), 33 errors can be corrected (15% of overall string) and with 195 checksum characters (adding 189%, 65% of overall string), 60 errors can be corrected (20% of overall string). Furthermore, for codes restricted to 1023 characters total (including the checksum characters) and assuming 103 data characters, including 27 checksum characters (adding 26%, 21% of overall string), seven errors can be corrected (5% of overall string). With 64 checksum characters (adding 62%, 38% of overall string), 17 errors can be corrected (10% of overall string), with 127 checksum characters (adding 123%, 57% of overall string), 36 errors can be corrected (15% of overall string), with 294 checksum characters (adding 285%, 74% of overall string), 80 errors can be corrected (20% of overall string), and with 920 checksum characters (adding 893%, 90% of overall string), 255 errors can be corrected (25% of overall string). Russell O'Connor suggests that it might be better to support multiple checksum variants instead of having a trade-off between the length of the code and recovery properties, as the user's medium of storage is likely to vary from person to person. He personally would probably be interested in the 51 or even 102 character checksums variants. Pieter offers to construct reference source code for any of these variants.The number of checksum characters needed to correct errors in codes designed for a length of 341 varies based on the number of errors to be corrected. For correcting one error, three checksum characters are required, and for correcting two errors, seven checksum characters are required. This pattern continues up to correcting 28 errors, which requires 102 checksum characters, or approximately double the length of the code. The trade-off between code length and recovery properties is determined by the user's medium of storage. It may be beneficial to support multiple checksum variants to accommodate varying storage mediums. The proposal suggests supporting longer checksum variants, such as the 51 or 102 character checksums.In an email to the bitcoin-dev mailing list, Jonas Schnelli discussed the presence of 520 bits in a BIP32 chain code with a compressed public key. According to Schnelli, the first 256 bits are the chain code and the remaining 264 bits define the public key. He also explained that in a 33 byte compressed public key, only one bit from the first byte is necessary to convey information, allowing for the other seven bits to be discarded. This reduction can result in a one-character decrease in the bech32 encoded result.Pieter proposed to construct a code and implementation for various BCH codes on the request of Jonas Schnelli. Pieter presented an example BCH code for base32 data which adds 27 checksum characters and can correct up to 7 errors in strings with length up to 1023, including the checksum characters themselves. The code can encode sequences of integers ranging from 0 to 31. He also provided an example of how to decode and correct errors in the encoded message. However, the code he provided has no special properties beyond the ones it is designed for. Pieter suggested that he could easily generate similar code for BCH codes with different properties.The writer expresses concerns about the use of Bech32 for error correction, noting that it is only efficient at correcting one error up to length 1023. While the checksum provides a small constant speedup, it doesn't fundamentally improve recovery. The writer suggests a code that includes computational costs for error correction during disaster recovery and notes that deriving one million child keys and comparing them against an address table would take less than a minute on consumer systems. They propose a trade-off between code length and recovery properties, suggesting that 5% error correction with a 26 char checksum is acceptable. The resulting string with 26 checksum chars is longer than the Bech32 equivalent but still considered acceptable for disaster recovery purposes. Finally, the writer offers to construct a code and implementation based on these requirements.Pieter, a contributor to the 2018-06-23T19:49:54+00:00 + Pieter and Russell O'Connor have been discussing the correctable error rates of codes designed for length 341, which is the first length enough to support 512 bits of data. The number of correctable errors includes errors inside the checksum characters themselves, meaning that aiming for a certain percentage of correctable characters increases the numbers dramatically. Pieter provides some numbers for codes restricted to a total of 341 characters and assuming 103 data characters, including 26 checksum characters (adding 25%, 20% of overall string), seven errors can be corrected (5% of overall string). With 62 checksum characters (adding 60%, 38% of overall string), 17 errors can be corrected (10% of overall string). With 116 checksum characters (adding 113%, 53% of overall string), 33 errors can be corrected (15% of overall string) and with 195 checksum characters (adding 189%, 65% of overall string), 60 errors can be corrected (20% of overall string). Furthermore, for codes restricted to 1023 characters total (including the checksum characters) and assuming 103 data characters, including 27 checksum characters (adding 26%, 21% of overall string), seven errors can be corrected (5% of overall string). With 64 checksum characters (adding 62%, 38% of overall string), 17 errors can be corrected (10% of overall string), with 127 checksum characters (adding 123%, 57% of overall string), 36 errors can be corrected (15% of overall string), with 294 checksum characters (adding 285%, 74% of overall string), 80 errors can be corrected (20% of overall string), and with 920 checksum characters (adding 893%, 90% of overall string), 255 errors can be corrected (25% of overall string). Russell O'Connor suggests that it might be better to support multiple checksum variants instead of having a trade-off between the length of the code and recovery properties, as the user's medium of storage is likely to vary from person to person. He personally would probably be interested in the 51 or even 102 character checksums variants. Pieter offers to construct reference source code for any of these variants.The number of checksum characters needed to correct errors in codes designed for a length of 341 varies based on the number of errors to be corrected. For correcting one error, three checksum characters are required, and for correcting two errors, seven checksum characters are required. This pattern continues up to correcting 28 errors, which requires 102 checksum characters, or approximately double the length of the code. The trade-off between code length and recovery properties is determined by the user's medium of storage. It may be beneficial to support multiple checksum variants to accommodate varying storage mediums. The proposal suggests supporting longer checksum variants, such as the 51 or 102 character checksums.In an email to the bitcoin-dev mailing list, Jonas Schnelli discussed the presence of 520 bits in a BIP32 chain code with a compressed public key. According to Schnelli, the first 256 bits are the chain code and the remaining 264 bits define the public key. He also explained that in a 33 byte compressed public key, only one bit from the first byte is necessary to convey information, allowing for the other seven bits to be discarded. This reduction can result in a one-character decrease in the bech32 encoded result.Pieter proposed to construct a code and implementation for various BCH codes on the request of Jonas Schnelli. Pieter presented an example BCH code for base32 data which adds 27 checksum characters and can correct up to 7 errors in strings with length up to 1023, including the checksum characters themselves. The code can encode sequences of integers ranging from 0 to 31. He also provided an example of how to decode and correct errors in the encoded message. However, the code he provided has no special properties beyond the ones it is designed for. Pieter suggested that he could easily generate similar code for BCH codes with different properties.The writer expresses concerns about the use of Bech32 for error correction, noting that it is only efficient at correcting one error up to length 1023. While the checksum provides a small constant speedup, it doesn't fundamentally improve recovery. The writer suggests a code that includes computational costs for error correction during disaster recovery and notes that deriving one million child keys and comparing them against an address table would take less than a minute on consumer systems. They propose a trade-off between code length and recovery properties, suggesting that 5% error correction with a 26 char checksum is acceptable. The resulting string with 26 checksum chars is longer than the Bech32 equivalent but still considered acceptable for disaster recovery purposes. Finally, the writer offers to construct a code and implementation based on these requirements.Pieter, a contributor to the - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_SIGHASH2-for-version-1-witness-programme.xml b/static/bitcoin-dev/June_2018/combined_SIGHASH2-for-version-1-witness-programme.xml index c9d7619994..c0a0c7902e 100644 --- a/static/bitcoin-dev/June_2018/combined_SIGHASH2-for-version-1-witness-programme.xml +++ b/static/bitcoin-dev/June_2018/combined_SIGHASH2-for-version-1-witness-programme.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 - - Christian Decker 2018-09-03 13:53:33+00:00 - - - Johnson Lau 2018-08-31 07:42:07+00:00 - - - Christian Decker 2018-08-30 20:51:15+00:00 - - - Johnson Lau 2018-08-30 20:38:06+00:00 - - - Gregory Maxwell 2018-07-02 18:23:48+00:00 - - - Johnson Lau 2018-06-01 18:45:57+00:00 - - - Russell O'Connor 2018-06-01 18:15:32+00:00 - - - Johnson Lau 2018-06-01 17:03:05+00:00 - - - Russell O'Connor 2018-06-01 15:03:46+00:00 - - - Johnson Lau 2018-05-31 18:35:41+00:00 - + 2025-09-26T15:47:15.749602+00:00 + python-feedgen + + + [bitcoin-dev] SIGHASH2 for version 1 witness programme Johnson Lau + 2018-05-31T18:35:00.000Z + + + Russell O'Connor + 2018-06-01T15:03:00.000Z + + + Johnson Lau + 2018-06-01T17:03:00.000Z + + + Russell O'Connor + 2018-06-01T18:15:00.000Z + + + Johnson Lau + 2018-06-01T18:45:00.000Z + + + Gregory Maxwell + 2018-07-02T18:23:00.000Z + + + Johnson Lau + 2018-08-30T20:38:00.000Z + + + Christian Decker + 2018-08-30T20:51:00.000Z + + + Johnson Lau + 2018-08-31T07:42:00.000Z + + + Christian Decker + 2018-09-03T13:53:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 + 2025-09-26T15:47:15.750793+00:00 - A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. 2018-09-03T13:53:33+00:00 + A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_Should-Graftroot-be-optional-.xml b/static/bitcoin-dev/June_2018/combined_Should-Graftroot-be-optional-.xml index 71d524cc9f..c73402ef02 100644 --- a/static/bitcoin-dev/June_2018/combined_Should-Graftroot-be-optional-.xml +++ b/static/bitcoin-dev/June_2018/combined_Should-Graftroot-be-optional-.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Should Graftroot be optional? - 2023-08-01T23:16:46.776152+00:00 - - Anthony Towns 2018-06-27 07:29:09+00:00 - - - ZmnSCPxj 2018-06-21 07:09:14+00:00 - - - Gregory Maxwell 2018-06-20 14:30:55+00:00 - - - ZmnSCPxj 2018-06-20 12:12:28+00:00 - - - Tim Ruffing 2018-06-06 21:25:33+00:00 - - - Pieter Wuille 2018-06-06 17:04:23+00:00 - - - Tim Ruffing 2018-06-06 12:48:01+00:00 - - - Pieter Wuille 2018-06-01 00:25:04+00:00 - - - Johnson Lau 2018-05-25 10:14:48+00:00 - - - Johnson Lau 2018-05-25 09:46:29+00:00 - - - Andrew Poelstra 2018-05-24 12:39:55+00:00 - - - Natanael 2018-05-24 09:44:16+00:00 - - - Natanael 2018-05-24 09:32:23+00:00 - - - Gregory Maxwell 2018-05-24 02:08:07+00:00 - - - Pieter Wuille 2018-05-24 01:58:11+00:00 - - - Gregory Maxwell 2018-05-23 23:45:09+00:00 - - - Natanael 2018-05-23 22:06:31+00:00 - - - Andrew Poelstra 2018-05-23 17:52:39+00:00 - - - Andrew Poelstra 2018-05-23 13:50:13+00:00 - - - ZmnSCPxj 2018-05-23 06:15:03+00:00 - - - Pieter Wuille 2018-05-22 18:17:42+00:00 - + 2025-09-26T15:46:52.548352+00:00 + python-feedgen + + + [bitcoin-dev] Should Graftroot be optional? Pieter Wuille + 2018-05-22T18:17:00.000Z + + + ZmnSCPxj + 2018-05-23T06:15:00.000Z + + + Andrew Poelstra + 2018-05-23T13:50:00.000Z + + + Andrew Poelstra + 2018-05-23T17:52:00.000Z + + + Natanael + 2018-05-23T22:06:00.000Z + + + Gregory Maxwell + 2018-05-23T23:45:00.000Z + + + Pieter Wuille + 2018-05-24T01:58:00.000Z + + + Gregory Maxwell + 2018-05-24T02:08:00.000Z + + + Natanael + 2018-05-24T09:32:00.000Z + + + Natanael + 2018-05-24T09:44:00.000Z + + + Andrew Poelstra + 2018-05-24T12:39:00.000Z + + + Johnson Lau + 2018-05-25T09:46:00.000Z + + + Johnson Lau + 2018-05-25T10:14:00.000Z + + + Pieter Wuille + 2018-06-01T00:25:00.000Z + + + Tim Ruffing + 2018-06-06T12:48:00.000Z + + + Pieter Wuille + 2018-06-06T17:04:00.000Z + + + Tim Ruffing + 2018-06-06T21:25:00.000Z + + + ZmnSCPxj + 2018-06-20T12:12:00.000Z + + + Gregory Maxwell + 2018-06-20T14:30:00.000Z + + + ZmnSCPxj + 2018-06-21T07:09:00.000Z + + + Anthony Towns + 2018-06-27T07:29:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Should Graftroot be optional? - 2023-08-01T23:16:46.777151+00:00 + 2025-09-26T15:46:52.550765+00:00 - On May 31, 2018, a discussion took place on the bitcoin-dev mailing list regarding the Graftroot proposal. Pieter Wuille argued that Graftroot delegation is not strictly less powerful than using a normal transaction because it enables delegation in a way that cannot be fixed in the chain. However, there may be practical implications to consider. The conversation also explored the similarities between Graftroot and SIGHASH_NOINPUT, and proposed making Graftroot spending a special sighash flag. It was suggested that the actual signature should still be different to avoid malleability issues.The concept of Graftroot signatures was brought up in a recent Bitcoin development discussion. These signatures commit to a single outpoint, making it impossible for them to be used to spend all outpoints that pay to the same public key. However, if a graftroot signature cannot be made independent of the outpoint, it greatly reduces its functionality. The main benefits of grafts are the ability to delegate before coins exist and making the transfer atomic compared to pre-signing a transaction.Pieter Wuille and Tim Ruffing discussed the design of the Graftroot signature. It was pointed out that the safety of the construction does not solely depend on consensus rules but also on how it is used. The discussion also touched on the compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs.Johnson Lau and Pieter Wuille had a debate about the safety of the Graftroot design. While Johnson Lau argued that if the design is dangerous, then the existing signature checking rules must be equally dangerous, Pieter Wuille emphasized that the safety of a construction depends on more than just consensus rules. He mentioned that having the option of Graftroot being non-optional is not required, as signers can use other methods.Pieter Wuille expressed concerns about the deployment of Taproot and Graftroot in an email to the Bitcoin developers' mailing list. He suggested that a practical deployment may require explicit enablement or disablement of the Graftroot spending path. Various approaches were listed to address this issue, but they were considered less efficient or private compared to allowing Graftroot spends directly. The compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs was also emphasized.In a separate discussion, the topic of accountability for funds held in a P2SH address was raised. The concern was that collusion among parties involved in signing a transaction could undermine the original purpose of the fund. The possibility of using Graftroot to pay funds to a public key without constraint was mentioned. It was agreed that it should be possible to send funds constrained by a script without a public key ever existing.The need for an explicit enable or disable feature for the Graftroot spending path in Taproot and Graftroot deployment was discussed. Suggestions included including a flag to choose in advance whether the script will be static or "editable" and including proof-requiring committed transactions to prevent unauthorized withdrawals. Concerns were raised about potential problems if Taproot and Graftroot were used to withdraw funds without showing in the published script. The importance of being able to prove that a transaction isn't using Taproot and Graftroot was highlighted.Andrew Poelstra raised concerns about Graftroot potentially breaking blind signature schemes but later explained a way to maintain unique keys for every output while retaining the same private key. A scheme for blind signatures was proposed but noted its vulnerability to Wagner's attack. Key-prefixing was suggested to enhance security by making the messagehash unique per-utxo and committed in the chain.ZmnSCPxj proposed modifying the Taproot equation to make Graftroot optional and combining Taproot and Graftroot. This would involve using a one-level Merkle tree where one branch enables or disables Graftroot and the other branch represents an ordinary script. Concerns were raised about signing arbitrary messages and ensuring that the simple-signing case does not become a vulnerability for wallets.The discussions surrounding Taproot and Graftroot have prompted questions about the need for explicit enablement or disablement of the Graftroot spending path in practical deployments. The safety of always permitting both types of script spending paths is being debated, as accidental signing of a script could have broader consequences without Graftroot. In a multisignature setting, the presence of Graftroot could allow a subset of participants to remove others from the set of signers. The discussions highlight the importance of considering potential reasons why certain applications may not adopt these outputs. 2018-06-27T07:29:09+00:00 + On May 31, 2018, a discussion took place on the bitcoin-dev mailing list regarding the Graftroot proposal. Pieter Wuille argued that Graftroot delegation is not strictly less powerful than using a normal transaction because it enables delegation in a way that cannot be fixed in the chain. However, there may be practical implications to consider. The conversation also explored the similarities between Graftroot and SIGHASH_NOINPUT, and proposed making Graftroot spending a special sighash flag. It was suggested that the actual signature should still be different to avoid malleability issues.The concept of Graftroot signatures was brought up in a recent Bitcoin development discussion. These signatures commit to a single outpoint, making it impossible for them to be used to spend all outpoints that pay to the same public key. However, if a graftroot signature cannot be made independent of the outpoint, it greatly reduces its functionality. The main benefits of grafts are the ability to delegate before coins exist and making the transfer atomic compared to pre-signing a transaction.Pieter Wuille and Tim Ruffing discussed the design of the Graftroot signature. It was pointed out that the safety of the construction does not solely depend on consensus rules but also on how it is used. The discussion also touched on the compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs.Johnson Lau and Pieter Wuille had a debate about the safety of the Graftroot design. While Johnson Lau argued that if the design is dangerous, then the existing signature checking rules must be equally dangerous, Pieter Wuille emphasized that the safety of a construction depends on more than just consensus rules. He mentioned that having the option of Graftroot being non-optional is not required, as signers can use other methods.Pieter Wuille expressed concerns about the deployment of Taproot and Graftroot in an email to the Bitcoin developers' mailing list. He suggested that a practical deployment may require explicit enablement or disablement of the Graftroot spending path. Various approaches were listed to address this issue, but they were considered less efficient or private compared to allowing Graftroot spends directly. The compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs was also emphasized.In a separate discussion, the topic of accountability for funds held in a P2SH address was raised. The concern was that collusion among parties involved in signing a transaction could undermine the original purpose of the fund. The possibility of using Graftroot to pay funds to a public key without constraint was mentioned. It was agreed that it should be possible to send funds constrained by a script without a public key ever existing.The need for an explicit enable or disable feature for the Graftroot spending path in Taproot and Graftroot deployment was discussed. Suggestions included including a flag to choose in advance whether the script will be static or "editable" and including proof-requiring committed transactions to prevent unauthorized withdrawals. Concerns were raised about potential problems if Taproot and Graftroot were used to withdraw funds without showing in the published script. The importance of being able to prove that a transaction isn't using Taproot and Graftroot was highlighted.Andrew Poelstra raised concerns about Graftroot potentially breaking blind signature schemes but later explained a way to maintain unique keys for every output while retaining the same private key. A scheme for blind signatures was proposed but noted its vulnerability to Wagner's attack. Key-prefixing was suggested to enhance security by making the messagehash unique per-utxo and committed in the chain.ZmnSCPxj proposed modifying the Taproot equation to make Graftroot optional and combining Taproot and Graftroot. This would involve using a one-level Merkle tree where one branch enables or disables Graftroot and the other branch represents an ordinary script. Concerns were raised about signing arbitrary messages and ensuring that the simple-signing case does not become a vulnerability for wallets.The discussions surrounding Taproot and Graftroot have prompted questions about the need for explicit enablement or disablement of the Graftroot spending path in practical deployments. The safety of always permitting both types of script spending paths is being debated, as accidental signing of a script could have broader consequences without Graftroot. In a multisignature setting, the presence of Graftroot could allow a subset of participants to remove others from the set of signers. The discussions highlight the importance of considering potential reasons why certain applications may not adopt these outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_Testnet-block-generation.xml b/static/bitcoin-dev/June_2018/combined_Testnet-block-generation.xml index c4833560bf..8e0c49aea5 100644 --- a/static/bitcoin-dev/June_2018/combined_Testnet-block-generation.xml +++ b/static/bitcoin-dev/June_2018/combined_Testnet-block-generation.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Testnet block generation - 2023-08-01T23:32:40.553526+00:00 - - Jameson Lopp 2018-06-28 17:33:58+00:00 - - - Mattia Rossi 2018-06-28 13:19:46+00:00 - + 2025-09-26T15:47:00.937896+00:00 + python-feedgen + + + [bitcoin-dev] Testnet block generation Mattia Rossi + 2018-06-28T13:19:00.000Z + + + Jameson Lopp + 2018-06-28T17:33:00.000Z + + - python-feedgen + 2 Combined summary - Testnet block generation - 2023-08-01T23:32:40.553526+00:00 + 2025-09-26T15:47:00.938331+00:00 - In response to the query, Jameson Lopp, a bitcoin developer, explains that the fast block generation in the testnet3 is actually due to a special rule. To further understand this rule, he provides a link to a blog post from Blocktrail. The blog post explains how 16k blocks were discovered in one day during testing, shedding light on the reason behind the rapid block generation.The provided link offers an explanation for the fast block generation observed in the testnet3 of the Bitcoin network. It appears that this behavior is not abnormal but rather a result of a specific rule implemented in the testnet3. The user's concern about the speed of block generation is addressed through Jameson Lopp's clarification and the referenced blog post from Blocktrail. By following the link, users can gain a deeper understanding of the special rule that allows for such rapid block generation in the testnet3. 2018-06-28T17:33:58+00:00 + In response to the query, Jameson Lopp, a bitcoin developer, explains that the fast block generation in the testnet3 is actually due to a special rule. To further understand this rule, he provides a link to a blog post from Blocktrail. The blog post explains how 16k blocks were discovered in one day during testing, shedding light on the reason behind the rapid block generation.The provided link offers an explanation for the fast block generation observed in the testnet3 of the Bitcoin network. It appears that this behavior is not abnormal but rather a result of a specific rule implemented in the testnet3. The user's concern about the speed of block generation is addressed through Jameson Lopp's clarification and the referenced blog post from Blocktrail. By following the link, users can gain a deeper understanding of the special rule that allows for such rapid block generation in the testnet3. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_Trusted-merkle-tree-depth-for-safe-tx-inclusion-proofs-without-a-soft-fork.xml b/static/bitcoin-dev/June_2018/combined_Trusted-merkle-tree-depth-for-safe-tx-inclusion-proofs-without-a-soft-fork.xml index df2a335ab7..147ab75e09 100644 --- a/static/bitcoin-dev/June_2018/combined_Trusted-merkle-tree-depth-for-safe-tx-inclusion-proofs-without-a-soft-fork.xml +++ b/static/bitcoin-dev/June_2018/combined_Trusted-merkle-tree-depth-for-safe-tx-inclusion-proofs-without-a-soft-fork.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - Trusted merkle tree depth for safe tx inclusion proofs without a soft fork - 2023-08-01T23:26:26.925936+00:00 - - Peter Todd 2018-06-09 13:02:55+00:00 - - - Sergio Demian Lerner 2018-06-09 12:51:55+00:00 - - - Peter Todd 2018-06-09 12:50:58+00:00 - - - Peter Todd 2018-06-09 12:45:16+00:00 - - - Sergio Demian Lerner 2018-06-09 12:24:49+00:00 - - - Sergio Demian Lerner 2018-06-09 12:21:17+00:00 - - - Sergio Demian Lerner 2018-06-09 11:03:53+00:00 - - - Bram Cohen 2018-06-09 03:29:30+00:00 - - - Peter Todd 2018-06-07 22:20:28+00:00 - - - Bram Cohen 2018-06-07 21:15:35+00:00 - - - Peter Todd 2018-06-07 17:13:11+00:00 - + 2025-09-26T15:47:11.542354+00:00 + python-feedgen + + + [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork Peter Todd + 2018-06-07T17:13:00.000Z + + + Bram Cohen + 2018-06-07T21:15:00.000Z + + + Peter Todd + 2018-06-07T22:20:00.000Z + + + Bram Cohen + 2018-06-09T03:29:00.000Z + + + Sergio Demian Lerner + 2018-06-09T11:03:00.000Z + + + Sergio Demian Lerner + 2018-06-09T12:21:00.000Z + + + Sergio Demian Lerner + 2018-06-09T12:24:00.000Z + + + Peter Todd + 2018-06-09T12:45:00.000Z + + + Peter Todd + 2018-06-09T12:50:00.000Z + + + Sergio Demian Lerner + 2018-06-09T12:51:00.000Z + + + Peter Todd + 2018-06-09T13:02:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - Trusted merkle tree depth for safe tx inclusion proofs without a soft fork - 2023-08-01T23:26:26.925936+00:00 + 2025-09-26T15:47:11.543646+00:00 - A vulnerability in Simplified Payment Verification (SPV) wallets and nodes has been discussed in an email thread among members of the Bitcoin community. The attack can bypass thousands of confirmations without a Sybil attack, impacting SPV wallets. However, the protections needed for SPV nodes are different and should be considered separately. One way to prevent accepting payments is by checking if any Merkle node is also a valid transaction. This reduces the problem, with false positive rates kept under one in a billion. It has been reported that an attacker with $1.3 million could perform a brute-force attack on 72 bits in four days using ASICs. Therefore, it is advised not to accept more than $1 million using an SPV wallet. However, it has been pointed out that a fake block can be created at a lower cost along with a sybil attack to fool SPV wallets. The attack can be repeated, allowing for multiple parties to be attacked without additional computation.RSK reported a vulnerability affecting hundreds of SPV wallets and systems relying on SPV proofs. They discovered the vulnerability in 2017 and emphasize the need to fix it as their SPV bridge depends on SPV proofs. However, Peter Todd argues that pruned nodes can be made invulnerable to the attack while still being able to verify merkle path tx inclusion proofs. He suggests that fixing the attack for SPV may not be necessary as they can be attacked at a much lower cost by generating fake blocks. Sergio Lerner apologizes for discussing the issue publicly earlier and urges the Bitcoin community to work towards ensuring the security and clean-design of Bitcoin.The vulnerability in the Bitcoin Merkle tree algorithm, which fails to distinguish between inner nodes and 64-byte transactions, was discussed in an email chain. This poses a potential problem for transaction inclusion proofs, as a miner could create a transaction committing to one not in the blockchain. One solution is to compare the length of the Merkle path to the known depth, avoiding the issue. It has been suggested to use version bits to indicate the tree depth or ban transactions with a size lower than or equal to 64. The possibility of maintaining validation of old transactions by caching the number of transactions in previous blocks has also been discussed.In summary, a vulnerability in SPV wallets and nodes has been reported, which can be bypassed without a Sybil attack. Measures to prevent the attack are different for SPV wallets and nodes. An attacker could perform a brute-force attack on 72 bits with $1.3 million, making it advisable not to accept more than $1 million using an SPV wallet. However, a fake block can be created at a lower cost along with a sybil attack to fool SPV wallets. RSK discovered a vulnerability in 2017 and urges the Bitcoin community to fix it. The Bitcoin Merkle tree algorithm fails to distinguish between inner nodes and 64-byte transactions, causing a problem for transaction inclusion proofs. Solutions such as comparing the length of the Merkle path to the known depth or using version bits have been proposed. 2018-06-09T13:02:55+00:00 + A vulnerability in Simplified Payment Verification (SPV) wallets and nodes has been discussed in an email thread among members of the Bitcoin community. The attack can bypass thousands of confirmations without a Sybil attack, impacting SPV wallets. However, the protections needed for SPV nodes are different and should be considered separately. One way to prevent accepting payments is by checking if any Merkle node is also a valid transaction. This reduces the problem, with false positive rates kept under one in a billion. It has been reported that an attacker with $1.3 million could perform a brute-force attack on 72 bits in four days using ASICs. Therefore, it is advised not to accept more than $1 million using an SPV wallet. However, it has been pointed out that a fake block can be created at a lower cost along with a sybil attack to fool SPV wallets. The attack can be repeated, allowing for multiple parties to be attacked without additional computation.RSK reported a vulnerability affecting hundreds of SPV wallets and systems relying on SPV proofs. They discovered the vulnerability in 2017 and emphasize the need to fix it as their SPV bridge depends on SPV proofs. However, Peter Todd argues that pruned nodes can be made invulnerable to the attack while still being able to verify merkle path tx inclusion proofs. He suggests that fixing the attack for SPV may not be necessary as they can be attacked at a much lower cost by generating fake blocks. Sergio Lerner apologizes for discussing the issue publicly earlier and urges the Bitcoin community to work towards ensuring the security and clean-design of Bitcoin.The vulnerability in the Bitcoin Merkle tree algorithm, which fails to distinguish between inner nodes and 64-byte transactions, was discussed in an email chain. This poses a potential problem for transaction inclusion proofs, as a miner could create a transaction committing to one not in the blockchain. One solution is to compare the length of the Merkle path to the known depth, avoiding the issue. It has been suggested to use version bits to indicate the tree depth or ban transactions with a size lower than or equal to 64. The possibility of maintaining validation of old transactions by caching the number of transactions in previous blocks has also been discussed.In summary, a vulnerability in SPV wallets and nodes has been reported, which can be bypassed without a Sybil attack. Measures to prevent the attack are different for SPV wallets and nodes. An attacker could perform a brute-force attack on 72 bits with $1.3 million, making it advisable not to accept more than $1 million using an SPV wallet. However, a fake block can be created at a lower cost along with a sybil attack to fool SPV wallets. RSK discovered a vulnerability in 2017 and urges the Bitcoin community to fix it. The Bitcoin Merkle tree algorithm fails to distinguish between inner nodes and 64-byte transactions, causing a problem for transaction inclusion proofs. Solutions such as comparing the length of the Merkle path to the known depth or using version bits have been proposed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_UHS-Full-node-security-without-maintaining-a-full-UTXO-set.xml b/static/bitcoin-dev/June_2018/combined_UHS-Full-node-security-without-maintaining-a-full-UTXO-set.xml index a271951dee..602afbfff8 100644 --- a/static/bitcoin-dev/June_2018/combined_UHS-Full-node-security-without-maintaining-a-full-UTXO-set.xml +++ b/static/bitcoin-dev/June_2018/combined_UHS-Full-node-security-without-maintaining-a-full-UTXO-set.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - UHS: Full-node security without maintaining a full UTXO set - 2023-08-01T23:08:00.907735+00:00 - - Jim Posen 2018-06-10 23:07:07+00:00 - - - Sjors Provoost 2018-06-07 09:39:59+00:00 - - - Alex Mizrahi 2018-05-18 15:42:00+00:00 - - - Cory Fields 2018-05-17 17:16:46+00:00 - - - Gregory Maxwell 2018-05-17 16:56:39+00:00 - - - Matt Corallo 2018-05-17 15:28:28+00:00 - - - Cory Fields 2018-05-16 16:36:35+00:00 - + 2025-09-26T15:47:07.289723+00:00 + python-feedgen + + + [bitcoin-dev] UHS: Full-node security without maintaining a full UTXO set Cory Fields + 2018-05-16T16:36:00.000Z + + + Matt Corallo + 2018-05-17T15:28:00.000Z + + + Gregory Maxwell + 2018-05-17T16:56:00.000Z + + + Cory Fields + 2018-05-17T17:16:00.000Z + + + Alex Mizrahi + 2018-05-18T15:42:00.000Z + + + Sjors Provoost + 2018-06-07T09:39:00.000Z + + + Jim Posen + 2018-06-10T23:07:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - UHS: Full-node security without maintaining a full UTXO set - 2023-08-01T23:08:00.907735+00:00 + 2025-09-26T15:47:07.290641+00:00 - A proposal has been made to change the way unspent transaction outputs (UTXOs) are stored in Bitcoin. The proposal suggests storing only the hashes of UTXOs instead of their full data, which could result in a 40% reduction in the size of a pruned node and less than a 1% reduction in an archive node. However, there are concerns about the 5% ongoing bandwidth increase required by this change and whether it would be worth the reduction in node size. The current transaction mechanisms are considered inefficient, and implementing this change may actually result in a 25% increase in overhead. Despite these concerns, the proposal does not require any changes to the blockchain data structure and could be implemented without permanently marrying the network to it.The proposal is based on separating the roles of the UTXO set, with one role providing proof that previous outputs exist to be spent and the other role providing the actual previous output data for verification. Instead of storing the full dereferenced prevout entries in a UTXO set, the proposal suggests storing their hashes to an Unspent Transaction Output Hash Set (UHS). This approach offers several advantages, including disk and memory savings, faster validation speeds, and more efficient caching. Pay-to-pubkey outputs would also be less burdensome on full nodes, and an even more aggressive pruning mode could be enabled.However, there are some drawbacks to this approach. It may require a few "bridge nodes" during the transition period, and there is a small increase in network traffic. Non-standard output scripts would still need to be sent in full, but they account for only around 1% of all current UTXOs. Despite these drawbacks, the proposal does not introduce any fundamental changes to Bitcoin's security model.Transitioning from the current UTXO model to the UHS model may be challenging but not overly difficult. Wallets would need to hold full prevout data for their unspent outputs, and a new service-bit would be allocated to indicate nodes willing to serve blocks and transactions with dereferenced prevout data appended. The proposal is still in its early stages, and implementation details need to be worked out. Further analysis is needed to determine whether the benefits of this proposal outweigh the costs.In conclusion, the proposal to store only the hashes of unspent outputs in Bitcoin has the potential to reduce node size and improve efficiency. However, there are concerns about the ongoing bandwidth increase and the overhead of the proposed change. Despite these concerns, the proposal could be implemented without permanently changing the blockchain data structure. Further analysis and testing are needed to fully evaluate the benefits and drawbacks of this proposal. 2018-06-10T23:07:07+00:00 + A proposal has been made to change the way unspent transaction outputs (UTXOs) are stored in Bitcoin. The proposal suggests storing only the hashes of UTXOs instead of their full data, which could result in a 40% reduction in the size of a pruned node and less than a 1% reduction in an archive node. However, there are concerns about the 5% ongoing bandwidth increase required by this change and whether it would be worth the reduction in node size. The current transaction mechanisms are considered inefficient, and implementing this change may actually result in a 25% increase in overhead. Despite these concerns, the proposal does not require any changes to the blockchain data structure and could be implemented without permanently marrying the network to it.The proposal is based on separating the roles of the UTXO set, with one role providing proof that previous outputs exist to be spent and the other role providing the actual previous output data for verification. Instead of storing the full dereferenced prevout entries in a UTXO set, the proposal suggests storing their hashes to an Unspent Transaction Output Hash Set (UHS). This approach offers several advantages, including disk and memory savings, faster validation speeds, and more efficient caching. Pay-to-pubkey outputs would also be less burdensome on full nodes, and an even more aggressive pruning mode could be enabled.However, there are some drawbacks to this approach. It may require a few "bridge nodes" during the transition period, and there is a small increase in network traffic. Non-standard output scripts would still need to be sent in full, but they account for only around 1% of all current UTXOs. Despite these drawbacks, the proposal does not introduce any fundamental changes to Bitcoin's security model.Transitioning from the current UTXO model to the UHS model may be challenging but not overly difficult. Wallets would need to hold full prevout data for their unspent outputs, and a new service-bit would be allocated to indicate nodes willing to serve blocks and transactions with dereferenced prevout data appended. The proposal is still in its early stages, and implementation details need to be worked out. Further analysis is needed to determine whether the benefits of this proposal outweigh the costs.In conclusion, the proposal to store only the hashes of unspent outputs in Bitcoin has the potential to reduce node size and improve efficiency. However, there are concerns about the ongoing bandwidth increase and the overhead of the proposed change. Despite these concerns, the proposal could be implemented without permanently changing the blockchain data structure. Further analysis and testing are needed to fully evaluate the benefits and drawbacks of this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_Why-not-archive-the-backend-of-Bitcoin-blockchain-.xml b/static/bitcoin-dev/June_2018/combined_Why-not-archive-the-backend-of-Bitcoin-blockchain-.xml index 0ec5db9704..1f6c51e18e 100644 --- a/static/bitcoin-dev/June_2018/combined_Why-not-archive-the-backend-of-Bitcoin-blockchain-.xml +++ b/static/bitcoin-dev/June_2018/combined_Why-not-archive-the-backend-of-Bitcoin-blockchain-.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Why not archive the backend of Bitcoin blockchain? - 2023-08-01T23:06:41.003598+00:00 - - Brian Lockhart 2018-06-14 23:24:33+00:00 - - - Christian Decker 2018-06-13 16:17:20+00:00 - - - Brian Lockhart 2018-06-13 15:32:11+00:00 - - - Christian Decker 2018-06-13 13:33:33+00:00 - - - Kulpreet Singh 2018-06-12 08:40:18+00:00 - - - Patrick Shirkey 2018-05-10 10:52:41+00:00 - - - ZmnSCPxj 2018-05-10 07:54:08+00:00 - - - Jim Posen 2018-05-10 06:50:43+00:00 - - - アルム　カールヨハン 2018-05-10 06:48:16+00:00 - - - Segue 2018-05-10 00:56:00+00:00 - + 2025-09-26T15:47:05.196873+00:00 + python-feedgen + + + [bitcoin-dev] Why not archive the backend of Bitcoin blockchain? Segue + 2018-05-10T00:56:00.000Z + + + アルム　カールヨハン + 2018-05-10T06:48:00.000Z + + + Jim Posen + 2018-05-10T06:50:00.000Z + + + ZmnSCPxj + 2018-05-10T07:54:00.000Z + + + Patrick Shirkey + 2018-05-10T10:52:00.000Z + + + Kulpreet Singh + 2018-06-12T08:40:00.000Z + + + Christian Decker + 2018-06-13T13:33:00.000Z + + + Brian Lockhart + 2018-06-13T15:32:00.000Z + + + Christian Decker + 2018-06-13T16:17:00.000Z + + + Brian Lockhart + 2018-06-14T23:24:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Why not archive the backend of Bitcoin blockchain? - 2023-08-01T23:06:41.003598+00:00 + 2025-09-26T15:47:05.197995+00:00 - A Lightning node can access an existing node instead of running its own dedicated instance of bitcoind. This can be achieved by configuring 'bitcoin-cli' to connect to a remote node with the 'rpcconnect', 'rpcuser', and 'rpcpassword' options in the 'bitcoin.conf' file or using command-line options when starting 'lightningd'. All three implementations of Lightning, c-lightning, lnd, and Eclair, support this method. Christian Decker, a developer at Blockstream, confirmed that Lightning nodes need to monitor the network for transactions and suspicious activity, but the bitcoind sitting next to the Lightning node does not need to keep an index of the transactions. Running with '-txindex' is not necessary for a Lightning node. Pruned nodes can work as long as the current blockchain head seen by the Lightning node does not fall into the pruned range. However, an indexed pruned node does not make sense for Lightning. The reliance on bitcoind for Lightning nodes is expected to be minimized in the future.In March 2018, a user on the Lightning-dev list asked about using Lightning without running a full bitcoin blockchain due to limited laptop space. Patrick Shirkey suggested periodically archiving old chapters of the blockchain on at least 150 computers across seven continents, storing just the index. This idea was later posted on the Bitcoin-dev list, noting that the "prune" flag could be used to get a snapshot of the blockchain but may cause issues for Lightning nodes if incompatible with "txindex" and "rescan".C-lightning is not officially rated for pruned bitcoind use, but it can be used if bitcoind is installed and started before lightningd, catching up to the chain. Pruned bitcoind is not officially supported, so any loss of funds due to this setup would be the user's responsibility. The implementation of the "chapter-based" archiving idea needs to be reviewed and implemented, addressing questions such as selecting archive servers and ensuring equal access to historical blockchain data.Bitcoin Core can operate in a pruned mode where most of the historical block data is discarded, keeping only the current UTXO set and recent blocks. However, some nodes on the network need to run in archive mode to help new nodes get in sync. BIP 159 identifies these archive nodes at the gossip layer. While some Lightning implementations use the additional txindex, which is not compatible with pruned mode, Segue suggested archiving chunks of the blockchain on distributed computers to avoid an infinitely long chain. This suggestion was posted on the bitcoin-dev list for further discussion.A user named Yubin Ruan asked about running the Lightning network without a full Bitcoin blockchain due to limited laptop space. Segue proposed the idea of periodically archiving chunks of the blockchain on 150 computers across seven continents to prevent an endlessly growing chain. This suggestion was then shared on the Bitcoin-dev list for more input. Pruning can also be used to store only the last X MB of the blockchain while keeping the UTXO set, which takes up a few GBs of space.In summary, Lightning nodes can access existing nodes instead of running their own dedicated bitcoind instance. Different implementations offer various methods to achieve this. The reliance on bitcoind for Lightning nodes is expected to decrease in the future. There have been discussions about archiving old chapters of the blockchain on multiple computers across continents to avoid an endlessly long chain. Pruned nodes are possible but may cause compatibility issues with txindex and rescan. The implementation of these ideas and their practicality are still being explored. 2018-06-14T23:24:33+00:00 + A Lightning node can access an existing node instead of running its own dedicated instance of bitcoind. This can be achieved by configuring 'bitcoin-cli' to connect to a remote node with the 'rpcconnect', 'rpcuser', and 'rpcpassword' options in the 'bitcoin.conf' file or using command-line options when starting 'lightningd'. All three implementations of Lightning, c-lightning, lnd, and Eclair, support this method. Christian Decker, a developer at Blockstream, confirmed that Lightning nodes need to monitor the network for transactions and suspicious activity, but the bitcoind sitting next to the Lightning node does not need to keep an index of the transactions. Running with '-txindex' is not necessary for a Lightning node. Pruned nodes can work as long as the current blockchain head seen by the Lightning node does not fall into the pruned range. However, an indexed pruned node does not make sense for Lightning. The reliance on bitcoind for Lightning nodes is expected to be minimized in the future.In March 2018, a user on the Lightning-dev list asked about using Lightning without running a full bitcoin blockchain due to limited laptop space. Patrick Shirkey suggested periodically archiving old chapters of the blockchain on at least 150 computers across seven continents, storing just the index. This idea was later posted on the Bitcoin-dev list, noting that the "prune" flag could be used to get a snapshot of the blockchain but may cause issues for Lightning nodes if incompatible with "txindex" and "rescan".C-lightning is not officially rated for pruned bitcoind use, but it can be used if bitcoind is installed and started before lightningd, catching up to the chain. Pruned bitcoind is not officially supported, so any loss of funds due to this setup would be the user's responsibility. The implementation of the "chapter-based" archiving idea needs to be reviewed and implemented, addressing questions such as selecting archive servers and ensuring equal access to historical blockchain data.Bitcoin Core can operate in a pruned mode where most of the historical block data is discarded, keeping only the current UTXO set and recent blocks. However, some nodes on the network need to run in archive mode to help new nodes get in sync. BIP 159 identifies these archive nodes at the gossip layer. While some Lightning implementations use the additional txindex, which is not compatible with pruned mode, Segue suggested archiving chunks of the blockchain on distributed computers to avoid an infinitely long chain. This suggestion was posted on the bitcoin-dev list for further discussion.A user named Yubin Ruan asked about running the Lightning network without a full Bitcoin blockchain due to limited laptop space. Segue proposed the idea of periodically archiving chunks of the blockchain on 150 computers across seven continents to prevent an endlessly growing chain. This suggestion was then shared on the Bitcoin-dev list for more input. Pruning can also be used to store only the last X MB of the blockchain while keeping the UTXO set, which takes up a few GBs of space.In summary, Lightning nodes can access existing nodes instead of running their own dedicated bitcoind instance. Different implementations offer various methods to achieve this. The reliance on bitcoind for Lightning nodes is expected to decrease in the future. There have been discussions about archiving old chapters of the blockchain on multiple computers across continents to avoid an endlessly long chain. Pruned nodes are possible but may cause compatibility issues with txindex and rescan. The implementation of these ideas and their practicality are still being explored. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml b/static/bitcoin-dev/June_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml index 0a88ff0d7d..c0b39b106a 100644 --- a/static/bitcoin-dev/June_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml +++ b/static/bitcoin-dev/June_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts - 2023-08-01T22:54:50.676286+00:00 - - Rusty Russell 2018-06-22 00:32:01+00:00 - - - Christian Decker 2018-05-10 13:57:30+00:00 - - - Olaoluwa Osuntokun 2018-05-07 23:26:05+00:00 - - - Jim Posen 2018-05-02 01:15:10+00:00 - - - Christian Decker 2018-05-01 17:31:28+00:00 - - - Jim Posen 2018-05-01 17:07:22+00:00 - - - Christian Decker 2018-05-01 16:29:09+00:00 - - - Jim Posen 2018-05-01 15:50:27+00:00 - - - Christian Decker 2018-05-01 11:38:12+00:00 - - - Christian Decker 2018-05-01 11:36:32+00:00 - - - ZmnSCPxj 2018-05-01 05:07:54+00:00 - - - ZmnSCPxj 2018-05-01 05:01:52+00:00 - - - Jim Posen 2018-04-30 23:00:55+00:00 - - - Christian Decker 2018-04-30 15:41:38+00:00 - + 2025-09-26T15:46:50.428279+00:00 + python-feedgen + + + [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts Christian Decker + 2018-04-30T15:41:00.000Z + + + Jim Posen + 2018-04-30T23:00:00.000Z + + + ZmnSCPxj + 2018-05-01T05:01:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2018-05-01T05:07:00.000Z + + + Christian Decker + 2018-05-01T11:36:00.000Z + + + Christian Decker + 2018-05-01T11:38:00.000Z + + + Jim Posen + 2018-05-01T15:50:00.000Z + + + Christian Decker + 2018-05-01T16:29:00.000Z + + + Jim Posen + 2018-05-01T17:07:00.000Z + + + Christian Decker + 2018-05-01T17:31:00.000Z + + + Jim Posen + 2018-05-02T01:15:00.000Z + + + Olaoluwa Osuntokun + 2018-05-07T23:26:00.000Z + + + Christian Decker + 2018-05-10T13:57:00.000Z + + + Rusty Russell + 2018-06-22T00:32:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts - 2023-08-01T22:54:50.676286+00:00 + 2025-09-26T15:46:50.429982+00:00 - The discussions surrounding the Lightning Network cover several topics. One of the concerns is the potential for attacks and the need for mitigations. Another topic is the impact of symmetric state and eltoo on HTLC (Hashed Timelock Contract) timeouts. The accumulation of timeout delays is also discussed, along with the use of a fixed offset versus an increased delta at each hop in the network. Additionally, there are concerns raised about the terminology used in a research paper, specifically regarding the terms "input script" and "output script." These conversations contribute to the ongoing development and improvement of the Lightning Network protocol.The Lightning Network implementation teams have introduced a new update mechanism called eltoo. This mechanism addresses some of the challenges faced in specifying and implementing the Lightning Network, and it can be used as a generic update mechanism for off-chain contracts with multiple participants. However, before implementing eltoo, a minor change to Bitcoin is required: the introduction of the SIGHASH_NOINPUT flag for signatures.Currently, the penalty-based invalidation mechanism used in the Lightning specification results in lost funds when an old state is published. Eltoo, on the other hand, is not penalty-based, meaning that publishing an old state does not result in lost funds. Instead, it operates similarly to the duplex micropayment channel construction, where all participants share an identical set of transactions. Eltoo ensures that the last agreed-upon state is settled on-chain, with tradeoffs similar to the current Lightning Network.One advantage of eltoo is its ability to attach fees when settling and even bump fees using CPFP (Child-Pays-For-Parent) or RBF (Replace-By-Fee). It also simplifies outsourcing since old states becoming public no longer pose a threat. Furthermore, eltoo eliminates the need to estimate fees ahead of time and can be utilized for other protocols such as channel factories. When combined with Schnorr signatures, eltoo facilitates the creation of large off-chain contracts with minimal on-chain footprint.However, implementing eltoo would require an increase in the safe CLTV (CheckLockTimeVerify) delta requirements. Currently, HTLCs can be timed out immediately on the settlement transaction. With eltoo, when a downstream channel is closed on-chain, it must wait for the CSV (CheckSequenceVerify) timeout on the update transaction before locking in the timed-out HTLC. This means that the CLTV delta needs to be greater than the CSV timeout, plus some extra time. However, it is believed that the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.Overall, eltoo presents a promising update mechanism for off-chain protocols like the Lightning Network. It offers improvements in terms of simplicity, flexibility in fee management, and potential use in various applications beyond Lightning. More details about the eltoo proposal can be found in the paper linked at [2]. 2018-06-22T00:32:01+00:00 + The discussions surrounding the Lightning Network cover several topics. One of the concerns is the potential for attacks and the need for mitigations. Another topic is the impact of symmetric state and eltoo on HTLC (Hashed Timelock Contract) timeouts. The accumulation of timeout delays is also discussed, along with the use of a fixed offset versus an increased delta at each hop in the network. Additionally, there are concerns raised about the terminology used in a research paper, specifically regarding the terms "input script" and "output script." These conversations contribute to the ongoing development and improvement of the Lightning Network protocol.The Lightning Network implementation teams have introduced a new update mechanism called eltoo. This mechanism addresses some of the challenges faced in specifying and implementing the Lightning Network, and it can be used as a generic update mechanism for off-chain contracts with multiple participants. However, before implementing eltoo, a minor change to Bitcoin is required: the introduction of the SIGHASH_NOINPUT flag for signatures.Currently, the penalty-based invalidation mechanism used in the Lightning specification results in lost funds when an old state is published. Eltoo, on the other hand, is not penalty-based, meaning that publishing an old state does not result in lost funds. Instead, it operates similarly to the duplex micropayment channel construction, where all participants share an identical set of transactions. Eltoo ensures that the last agreed-upon state is settled on-chain, with tradeoffs similar to the current Lightning Network.One advantage of eltoo is its ability to attach fees when settling and even bump fees using CPFP (Child-Pays-For-Parent) or RBF (Replace-By-Fee). It also simplifies outsourcing since old states becoming public no longer pose a threat. Furthermore, eltoo eliminates the need to estimate fees ahead of time and can be utilized for other protocols such as channel factories. When combined with Schnorr signatures, eltoo facilitates the creation of large off-chain contracts with minimal on-chain footprint.However, implementing eltoo would require an increase in the safe CLTV (CheckLockTimeVerify) delta requirements. Currently, HTLCs can be timed out immediately on the settlement transaction. With eltoo, when a downstream channel is closed on-chain, it must wait for the CSV (CheckSequenceVerify) timeout on the update transaction before locking in the timed-out HTLC. This means that the CLTV delta needs to be greater than the CSV timeout, plus some extra time. However, it is believed that the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.Overall, eltoo presents a promising update mechanism for off-chain protocols like the Lightning Network. It offers improvements in terms of simplicity, flexibility in fee management, and potential use in various applications beyond Lightning. More details about the eltoo proposal can be found in the paper linked at [2]. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_-PROPOSAL-Emergency-RBF-BIP-125-.xml b/static/bitcoin-dev/June_2019/combined_-PROPOSAL-Emergency-RBF-BIP-125-.xml index 928dbeaefe..ada431b693 100644 --- a/static/bitcoin-dev/June_2019/combined_-PROPOSAL-Emergency-RBF-BIP-125-.xml +++ b/static/bitcoin-dev/June_2019/combined_-PROPOSAL-Emergency-RBF-BIP-125-.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - [PROPOSAL] Emergency RBF (BIP 125) - 2023-08-02T00:59:12.387101+00:00 - - Rusty Russell 2019-06-14 05:50:17+00:00 - - - rhavar at protonmail.com 2019-06-10 16:34:33+00:00 - - - David A. Harding 2019-06-09 14:07:36+00:00 - - - Russell O'Connor 2019-06-09 04:21:19+00:00 - - - Rusty Russell 2019-06-06 05:16:54+00:00 - - - Rusty Russell 2019-06-06 03:08:50+00:00 - - - Russell O'Connor 2019-06-03 12:56:42+00:00 - - - Matt Corallo 2019-06-03 09:48:31+00:00 - - - rhavar at protonmail.com 2019-06-03 01:49:15+00:00 - - - Rusty Russell 2019-06-02 04:41:39+00:00 - + 2025-09-26T16:04:09.532396+00:00 + python-feedgen + + + [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125) Rusty Russell + 2019-06-02T04:41:00.000Z + + + rhavar + 2019-06-03T01:49:00.000Z + + + Matt Corallo + 2019-06-03T09:48:00.000Z + + + Russell O'Connor + 2019-06-03T12:56:00.000Z + + + Rusty Russell + 2019-06-06T03:08:00.000Z + + + Rusty Russell + 2019-06-06T05:16:00.000Z + + + Russell O'Connor + 2019-06-09T04:21:00.000Z + + + David A. Harding + 2019-06-09T14:07:00.000Z + + + rhavar + 2019-06-10T16:34:00.000Z + + + Rusty Russell + 2019-06-14T05:50:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - [PROPOSAL] Emergency RBF (BIP 125) - 2023-08-02T00:59:12.387101+00:00 + 2025-09-26T16:04:09.533642+00:00 - In a recent discussion on the Bitcoin-dev mailing list, there was a debate over proposed changes to the Replace-By-Fee (RBF) system. Rusty Russell stated that he didn't believe the proposed changes would make things worse, while David A. Harding disagreed and provided a scenario demonstrating the potential negative impact of the proposal. Harding argued that the current rules were insufficient and changes needed to be made. He expressed concern about the constraints of the proposal, which could result in high feerates. Rusty countered by explaining that without RBF changes, a lightning wallet would need to assume it needs to replace a specific transaction, but with RBF changes, it would only need to replace at a certain feerate. He also mentioned that fees required for the next block can be estimated when a block is seen.The discussion focused on proposed changes to the rules for replacing unconfirmed transactions with fee-bumped replacements. One proposal suggested storing a relay bandwidth used (RBU) value with each transaction in the mempool. The replacement would only be valid if its feerate is higher than the transaction it's evicting and its fee is greater than minRelayFee multiplied by RBU. The thread included a scenario where an attacker creates two transactions, one small and one large. Under the new proposed rule, the cost for the attacker to get the small transaction near the top of the mempool would be reduced. There was also a discussion about the limit on the number of unconfirmed transactions accepted by bitcoind, with the BIP125 limit being 100 and Bitcoin Core's current default being 25. These proposed changes could make it harder for wallet software, especially LN wallets, to determine if transactions have been successfully relayed. Overall, the proposed changes add complexity and may result in high feerates.Bitcoin developer Matt Corallo expressed concerns about a proposal to replace Bitcoin's relay fee system with an alternative. He was worried about the potential for "very, very bad" results. Rusty Russell responded by explaining that the new rule would actually reduce costs for attackers and save bandwidth per node.On June 8, 2019, a discussion took place on the Bitcoin development mailing list regarding a new "emergency RBF" rule proposed by Rusty Russell. The rule stated that if the original transaction was not in the top 4,000,000 weight units of the fee-ordered mempool and the replacement transaction is, certain rules would not apply. Concerns were raised about the possibility of someone spamming the mempool by repeatedly using this feature to push transactions down the queue. A suggestion was made to amend the proposal to mitigate this potential issue. It was debated whether it would be practical to execute such a spamming strategy across multiple non-direct peers.Matt Corallo also raised concerns about the implementation of a Bitcoin proposal related to child-pays-for-parent (CPFP) for replacing-by-fee (RBF). He pointed out areas where improvement and clarification were needed, such as calculations for evicted transactions, benchmarks for DoS attacks, and protections for time-critical transactions. Rusty Russell clarified that there would be no issues if miners have conflicting transactions in the top 4MSipa.In another discussion on the bitcoin-dev mailing list, Rusty Russell proposed an "emergency RBF" rule for Bitcoin transactions. This rule would allow users to replace unconfirmed transactions with higher fee ones. Concerns were raised about the possibility of spamming the mempool by using this feature repeatedly. Rusty acknowledged the potential annoyance for recipients but questioned the practicality of executing such a strategy across multiple non-direct peers.Rusty Russell proposed a modification to BIP 125 rules 3, 4, and 5. The "emergency RBF" rule would enable RBF in conditions like lightning unilateral closes. However, concerns were raised about potential issues with evicted transactions and vague protections for time-critical transactions. The proposal was deemed to require more client-side knowledge and complexity than previous proposals but should not be dismissed solely because it may not be the optimal solution.The proposal to modify BIP 125 rules 3, 4, and 5 was made by Rusty Russell. The "emergency RBF" rule would allow for the replacement of unconfirmed transactions if certain conditions are met. It could be used in adversarial conditions like lightning unilateral closes. Concerns were raised about potential spamming and suggestions were made to amend the proposal. Rusty acknowledged the possible issues but believed there might be ways to mitigate them. 2019-06-14T05:50:17+00:00 + In a recent discussion on the Bitcoin-dev mailing list, there was a debate over proposed changes to the Replace-By-Fee (RBF) system. Rusty Russell stated that he didn't believe the proposed changes would make things worse, while David A. Harding disagreed and provided a scenario demonstrating the potential negative impact of the proposal. Harding argued that the current rules were insufficient and changes needed to be made. He expressed concern about the constraints of the proposal, which could result in high feerates. Rusty countered by explaining that without RBF changes, a lightning wallet would need to assume it needs to replace a specific transaction, but with RBF changes, it would only need to replace at a certain feerate. He also mentioned that fees required for the next block can be estimated when a block is seen.The discussion focused on proposed changes to the rules for replacing unconfirmed transactions with fee-bumped replacements. One proposal suggested storing a relay bandwidth used (RBU) value with each transaction in the mempool. The replacement would only be valid if its feerate is higher than the transaction it's evicting and its fee is greater than minRelayFee multiplied by RBU. The thread included a scenario where an attacker creates two transactions, one small and one large. Under the new proposed rule, the cost for the attacker to get the small transaction near the top of the mempool would be reduced. There was also a discussion about the limit on the number of unconfirmed transactions accepted by bitcoind, with the BIP125 limit being 100 and Bitcoin Core's current default being 25. These proposed changes could make it harder for wallet software, especially LN wallets, to determine if transactions have been successfully relayed. Overall, the proposed changes add complexity and may result in high feerates.Bitcoin developer Matt Corallo expressed concerns about a proposal to replace Bitcoin's relay fee system with an alternative. He was worried about the potential for "very, very bad" results. Rusty Russell responded by explaining that the new rule would actually reduce costs for attackers and save bandwidth per node.On June 8, 2019, a discussion took place on the Bitcoin development mailing list regarding a new "emergency RBF" rule proposed by Rusty Russell. The rule stated that if the original transaction was not in the top 4,000,000 weight units of the fee-ordered mempool and the replacement transaction is, certain rules would not apply. Concerns were raised about the possibility of someone spamming the mempool by repeatedly using this feature to push transactions down the queue. A suggestion was made to amend the proposal to mitigate this potential issue. It was debated whether it would be practical to execute such a spamming strategy across multiple non-direct peers.Matt Corallo also raised concerns about the implementation of a Bitcoin proposal related to child-pays-for-parent (CPFP) for replacing-by-fee (RBF). He pointed out areas where improvement and clarification were needed, such as calculations for evicted transactions, benchmarks for DoS attacks, and protections for time-critical transactions. Rusty Russell clarified that there would be no issues if miners have conflicting transactions in the top 4MSipa.In another discussion on the bitcoin-dev mailing list, Rusty Russell proposed an "emergency RBF" rule for Bitcoin transactions. This rule would allow users to replace unconfirmed transactions with higher fee ones. Concerns were raised about the possibility of spamming the mempool by using this feature repeatedly. Rusty acknowledged the potential annoyance for recipients but questioned the practicality of executing such a strategy across multiple non-direct peers.Rusty Russell proposed a modification to BIP 125 rules 3, 4, and 5. The "emergency RBF" rule would enable RBF in conditions like lightning unilateral closes. However, concerns were raised about potential issues with evicted transactions and vague protections for time-critical transactions. The proposal was deemed to require more client-side knowledge and complexity than previous proposals but should not be dismissed solely because it may not be the optimal solution.The proposal to modify BIP 125 rules 3, 4, and 5 was made by Rusty Russell. The "emergency RBF" rule would allow for the replacement of unconfirmed transactions if certain conditions are met. It could be used in adversarial conditions like lightning unilateral closes. Concerns were raised about potential spamming and suggestions were made to amend the proposal. Rusty acknowledged the possible issues but believed there might be ways to mitigate them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_An-alternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml b/static/bitcoin-dev/June_2019/combined_An-alternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml index 7e0e927a71..8424d47c82 100644 --- a/static/bitcoin-dev/June_2019/combined_An-alternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml +++ b/static/bitcoin-dev/June_2019/combined_An-alternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - An alternative: OP_CAT & OP_CHECKSIGFROMSTACK - 2023-08-02T00:53:10.913427+00:00 - - Tamas Blummer 2019-06-13 08:14:02+00:00 - - - Russell O'Connor 2019-05-29 06:49:29+00:00 - - - ZmnSCPxj 2019-05-28 03:41:58+00:00 - - - Anthony Towns 2019-05-27 07:21:28+00:00 - - - Russell O'Connor 2019-05-25 12:52:44+00:00 - - - Jeremy 2019-05-25 01:08:00+00:00 - - - Russell O'Connor 2019-05-24 23:07:28+00:00 - - - Jeremy 2019-05-24 20:51:21+00:00 - - - Russell O'Connor 2019-05-24 15:10:21+00:00 - - - ZmnSCPxj 2019-05-24 04:15:45+00:00 - - - ZmnSCPxj 2019-05-24 03:51:13+00:00 - - - Russell O'Connor 2019-05-23 22:06:45+00:00 - - - Russell O'Connor 2019-05-23 22:00:59+00:00 - - - Jimmy Song 2019-05-23 17:36:19+00:00 - - - ZmnSCPxj 2019-05-23 16:59:15+00:00 - - - Russell O'Connor 2019-05-22 21:01:21+00:00 - + 2025-09-26T16:04:07.438073+00:00 + python-feedgen + + + [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK Russell O'Connor + 2019-05-22T21:01:00.000Z + + + ZmnSCPxj + 2019-05-23T16:59:00.000Z + + + Jimmy Song + 2019-05-23T17:36:00.000Z + + + Russell O'Connor + 2019-05-23T22:00:00.000Z + + + Russell O'Connor + 2019-05-23T22:06:00.000Z + + + ZmnSCPxj + 2019-05-24T03:51:00.000Z + + + ZmnSCPxj + 2019-05-24T04:15:00.000Z + + + Russell O'Connor + 2019-05-24T15:10:00.000Z + + + Jeremy + 2019-05-24T20:51:00.000Z + + + Russell O'Connor + 2019-05-24T23:07:00.000Z + + + Jeremy + 2019-05-25T01:08:00.000Z + + + Russell O'Connor + 2019-05-25T12:52:00.000Z + + + Anthony Towns + 2019-05-27T07:21:00.000Z + + + ZmnSCPxj + 2019-05-28T03:41:00.000Z + + + Russell O'Connor + 2019-05-29T06:49:00.000Z + + + Tamas Blummer + 2019-06-13T08:14:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - An alternative: OP_CAT & OP_CHECKSIGFROMSTACK - 2023-08-02T00:53:10.913427+00:00 + 2025-09-26T16:04:07.439852+00:00 - Another aspect discussed in the proposal is the implementation of oracle-less difficulty contracts without the need for CISC type OP_WORKVERIFY. An example contract is provided, which involves a European digital call option on target difficulty after maturity with a 10-block notice period. The contract can be soft forked by redefining OP_NOP as a prefix (OP_EXTENSION). This demonstrates the flexibility of Bitcoin Script and the potential for creating complex smart contracts.The proposal also suggests adding OP_CAT and OP_CHECKSIGFROMSTACKVERIFY to enable flexible programmability in Bitcoin Script. It argues that some parts of Script have been unsuccessful and not useful in practice, and that a subset of concatenation, arithmetic, CHECKDATASIG, transaction reflection, and/or covenants could create particularly useful programs. The proposal includes a debate on simulating an ANYPREVOUT signature with a data signature and the use of the "CHECK_SIG_MSG_VERIFY" opcode for simplicity and generic programming.Anthony Towns suggests that the infrequent use of certain Script features may be due to a lack of tools rather than a lack of demand. He advocates for implementing a pure functional language that can be compiled down to SCRIPT and leveraged with OP_CHECKSIGFROMSTACK. This would require a proof-of-existence compiler targeting Liquid/Elements SCRIPT. Towns also mentions his Smart Contracts Unchained technique as a way to implement Simplicity on top of Bitcoin, using a user-selected federation to enforce Simplicity execution.The effectiveness of Bitcoin Script has been questioned due to the disabling of certain opcodes and consensus bugs. Russell O'Connor proposes implementing OP_CAT and OP_CHECKSIGFROMSTACKVERIFY as a solution. The proposal suggests that CAT's usefulness is acknowledged, but there is uncertainty about CHECKSIG, which takes the message from the stack. A concrete example of transaction introspection using simulated SIGHASH_ANYPREVOUT is provided.The discussion also revolves around the OP_COSHV opcode and its potential replacement with transaction reflection primitives like OP_NUMINPUTS and OP_PUSHOUTPUTSHASH. The proposal for OP_CHECK_TXID_TEMPLATE_DATA is debated, allowing a variable number of inputs and fixing potential bugs related to TXID malleability. The idea of implementing an alternative CISC-style taproot leaf type is suggested. The benefits and drawbacks of OP_CHECKSIGFROMSTACKVERIFY are discussed, with concerns raised about its potential recursive covenant and negative interaction with future opcodes.In summary, the proposal suggests introducing new opcodes, OP_CAT and OP_CHECKSIGFROMSTACKVERIFY, to enhance the functionality and flexibility of Bitcoin Script. These opcodes can enable various applications and improve the programmability of Bitcoin. However, there are ongoing debates and discussions regarding the implementation and potential limitations of these opcodes, as well as the overall effectiveness of Bitcoin Script in real-world use cases. 2019-06-13T08:14:02+00:00 + Another aspect discussed in the proposal is the implementation of oracle-less difficulty contracts without the need for CISC type OP_WORKVERIFY. An example contract is provided, which involves a European digital call option on target difficulty after maturity with a 10-block notice period. The contract can be soft forked by redefining OP_NOP as a prefix (OP_EXTENSION). This demonstrates the flexibility of Bitcoin Script and the potential for creating complex smart contracts.The proposal also suggests adding OP_CAT and OP_CHECKSIGFROMSTACKVERIFY to enable flexible programmability in Bitcoin Script. It argues that some parts of Script have been unsuccessful and not useful in practice, and that a subset of concatenation, arithmetic, CHECKDATASIG, transaction reflection, and/or covenants could create particularly useful programs. The proposal includes a debate on simulating an ANYPREVOUT signature with a data signature and the use of the "CHECK_SIG_MSG_VERIFY" opcode for simplicity and generic programming.Anthony Towns suggests that the infrequent use of certain Script features may be due to a lack of tools rather than a lack of demand. He advocates for implementing a pure functional language that can be compiled down to SCRIPT and leveraged with OP_CHECKSIGFROMSTACK. This would require a proof-of-existence compiler targeting Liquid/Elements SCRIPT. Towns also mentions his Smart Contracts Unchained technique as a way to implement Simplicity on top of Bitcoin, using a user-selected federation to enforce Simplicity execution.The effectiveness of Bitcoin Script has been questioned due to the disabling of certain opcodes and consensus bugs. Russell O'Connor proposes implementing OP_CAT and OP_CHECKSIGFROMSTACKVERIFY as a solution. The proposal suggests that CAT's usefulness is acknowledged, but there is uncertainty about CHECKSIG, which takes the message from the stack. A concrete example of transaction introspection using simulated SIGHASH_ANYPREVOUT is provided.The discussion also revolves around the OP_COSHV opcode and its potential replacement with transaction reflection primitives like OP_NUMINPUTS and OP_PUSHOUTPUTSHASH. The proposal for OP_CHECK_TXID_TEMPLATE_DATA is debated, allowing a variable number of inputs and fixing potential bugs related to TXID malleability. The idea of implementing an alternative CISC-style taproot leaf type is suggested. The benefits and drawbacks of OP_CHECKSIGFROMSTACKVERIFY are discussed, with concerns raised about its potential recursive covenant and negative interaction with future opcodes.In summary, the proposal suggests introducing new opcodes, OP_CAT and OP_CHECKSIGFROMSTACKVERIFY, to enhance the functionality and flexibility of Bitcoin Script. These opcodes can enable various applications and improve the programmability of Bitcoin. However, there are ongoing debates and discussions regarding the implementation and potential limitations of these opcodes, as well as the overall effectiveness of Bitcoin Script in real-world use cases. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_BIP174-extension-proposal-Global-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml b/static/bitcoin-dev/June_2019/combined_BIP174-extension-proposal-Global-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml index 18d93230ea..007eed2535 100644 --- a/static/bitcoin-dev/June_2019/combined_BIP174-extension-proposal-Global-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml +++ b/static/bitcoin-dev/June_2019/combined_BIP174-extension-proposal-Global-Type-PSBT-GLOBAL-XPUB-SIGNATURE-.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE) - 2023-08-02T01:01:27.845359+00:00 - - Jonathan Underwood 2019-07-23 05:03:32+00:00 - - - Jonathan Underwood 2019-06-29 08:11:56+00:00 - - - Dmitry Petukhov 2019-06-29 04:46:23+00:00 - - - Dmitry Petukhov 2019-06-29 04:31:04+00:00 - - - Jonathan Underwood 2019-06-29 00:19:41+00:00 - - - Dmitry Petukhov 2019-06-28 21:48:16+00:00 - - - Jonathan Underwood 2019-06-28 15:00:22+00:00 - - - Peter D. Gray 2019-06-28 14:37:55+00:00 - - - Jonathan Underwood 2019-06-28 02:44:15+00:00 - - - Dmitry Petukhov 2019-06-27 15:29:32+00:00 - - - Peter D. Gray 2019-06-27 15:07:45+00:00 - - - Jonathan Underwood 2019-06-27 09:52:28+00:00 - - - Jonathan Underwood 2019-06-27 09:32:46+00:00 - - - Jonathan Underwood 2019-06-27 08:59:44+00:00 - - - Jonathan Underwood 2019-06-27 08:16:14+00:00 - - - Jonathan Underwood 2019-06-27 05:07:47+00:00 - - - Jonathan Underwood 2019-06-27 02:11:23+00:00 - + 2025-09-26T16:03:58.948992+00:00 + python-feedgen + + + [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE) Jonathan Underwood + 2019-06-27T02:11:00.000Z + + + Jonathan Underwood + 2019-06-27T05:07:00.000Z + + + Jonathan Underwood + 2019-06-27T08:16:00.000Z + + + Jonathan Underwood + 2019-06-27T08:59:00.000Z + + + Jonathan Underwood + 2019-06-27T09:32:00.000Z + + + Jonathan Underwood + 2019-06-27T09:52:00.000Z + + + Peter D. Gray + 2019-06-27T15:07:00.000Z + + + Dmitry Petukhov + 2019-06-27T15:29:00.000Z + + + Jonathan Underwood + 2019-06-28T02:44:00.000Z + + + Peter D. Gray + 2019-06-28T14:37:00.000Z + + + Jonathan Underwood + 2019-06-28T15:00:00.000Z + + + Dmitry Petukhov + 2019-06-28T21:48:00.000Z + + + Jonathan Underwood + 2019-06-29T00:19:00.000Z + + + Dmitry Petukhov + 2019-06-29T04:31:00.000Z + + + Dmitry Petukhov + 2019-06-29T04:46:00.000Z + + + Jonathan Underwood + 2019-06-29T08:11:00.000Z + + + Jonathan Underwood + 2019-07-23T05:03:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE) - 2023-08-02T01:01:27.845359+00:00 + 2025-09-26T16:03:58.950851+00:00 - Jonathan Underwood, the Chief Bitcoin Officer at Bitbank Co., Ltd., has initiated a discussion on GitHub regarding the security of signed data in one-of-one multisig systems. He argues that explicitly signing the data is more secure, even if the difference is apparent outside the signed data. Dmitry Petukhov suggests using 0 as an indicator for serial numbers and requiring m=1 for single-sig cases. Jonathan mentions that 0x00 represents single sig and 0x01 represents multisig. The discussion also touches upon the use of redeem/witness scripts to differentiate between multisig and single-sig. The conversation also explores the revocation of signatures and the storage of whitelist pubkeys. It is suggested that a hardware wallet could store at least one counter and have rich state stored externally. However, storing a large enough state in the RAM of a resource-constrained device may present a problem. Another idea proposed is to add a serial to xpub-package, which would allow for revoking previously signed packages with compromised keys. In the discussion on the proposed field key format for PSBT, Dmitry Petukhov suggests replacing the signing public key with just a fingerprint of the master key to save bytes. However, it is pointed out that someone other than the signer would need to know the signing_pubkey beforehand for verification purposes. It is decided to use the first 4 bytes of the hash160 of the pubkey as the fingerprint. There is also a suggestion to add a serial number to the xpub package for revoking previously signed packages with compromised keys, but this may require a separate BIP.Jonathan Underwood proposes a solution for verifying change with multisig using the 0x01 global type proposed by Andrew Chow. The proposal involves signing each other's xpubs and creating a wallet that requires the other pubkeys to have signatures via his 0x02 proposal. However, the drawback is having to include n! (of m-of-n) signatures in every PSBT. A proposal is made to extend PSBT to allow for verifying that the destination address in a transaction has not been compromised. It is suggested that this issue be dealt with outside of PSBT to avoid making the core specification too large.A proposal has been made to extend Partially Signed Bitcoin Transactions (PSBT) to include a key value specification that would help verify the address a transaction is being sent to. The proposed scheme involves signing each other's extended public keys (xpubs) by all signers of a transaction, which can then be used to verify the destination address. Concerns were raised about its use in multisig wallets where some keys may be compromised. To prevent compromised keys from invalidating transactions, hardware wallets could be shown a specific 'epoch' word or serial number for xpub packages. These schemes could be included in PSBT as 'meta-information' or 'vendor-specific' fields.The proposed key value specification aims to address the issue of verifying addresses when transferring funds between cold and warm/hot wallets. While BIP32_DERIVATION can verify an address from a specific XPUB, it cannot verify its signature. The solution involves securely verifying the xpub of the warm/hot wallet using an airgap signing tool, uploading the signature/xpub pairs to the online unsigned transaction generator, and including one keyval pair per coldkey/xpub pairing. To avoid complicating the core PSBT specification, it is suggested that the various schemes should be dealt with outside of PSBT as 'PSBT metainformation' or using vendor-specific fields.The proposal also discusses the implementation of multisig wallet security with PSBT by signing all xpubs for a multisig wallet and including them in each transaction. This ensures that all signers are aware of every key involved in the transaction, increasing security for HD wallets. However, concerns were raised about the possibility of partial compromise, where one of the keys is stolen. The need for proper key revocation mechanisms is highlighted to ensure that signed packages cannot be used by attackers.Overall, the proposed extension of PSBT aims to improve the verification process and increase security for HD wallets. Feedback and suggestions for improvement have been invited by Jonathan Underwood. 2019-07-23T05:03:32+00:00 + Jonathan Underwood, the Chief Bitcoin Officer at Bitbank Co., Ltd., has initiated a discussion on GitHub regarding the security of signed data in one-of-one multisig systems. He argues that explicitly signing the data is more secure, even if the difference is apparent outside the signed data. Dmitry Petukhov suggests using 0 as an indicator for serial numbers and requiring m=1 for single-sig cases. Jonathan mentions that 0x00 represents single sig and 0x01 represents multisig. The discussion also touches upon the use of redeem/witness scripts to differentiate between multisig and single-sig. The conversation also explores the revocation of signatures and the storage of whitelist pubkeys. It is suggested that a hardware wallet could store at least one counter and have rich state stored externally. However, storing a large enough state in the RAM of a resource-constrained device may present a problem. Another idea proposed is to add a serial to xpub-package, which would allow for revoking previously signed packages with compromised keys. In the discussion on the proposed field key format for PSBT, Dmitry Petukhov suggests replacing the signing public key with just a fingerprint of the master key to save bytes. However, it is pointed out that someone other than the signer would need to know the signing_pubkey beforehand for verification purposes. It is decided to use the first 4 bytes of the hash160 of the pubkey as the fingerprint. There is also a suggestion to add a serial number to the xpub package for revoking previously signed packages with compromised keys, but this may require a separate BIP.Jonathan Underwood proposes a solution for verifying change with multisig using the 0x01 global type proposed by Andrew Chow. The proposal involves signing each other's xpubs and creating a wallet that requires the other pubkeys to have signatures via his 0x02 proposal. However, the drawback is having to include n! (of m-of-n) signatures in every PSBT. A proposal is made to extend PSBT to allow for verifying that the destination address in a transaction has not been compromised. It is suggested that this issue be dealt with outside of PSBT to avoid making the core specification too large.A proposal has been made to extend Partially Signed Bitcoin Transactions (PSBT) to include a key value specification that would help verify the address a transaction is being sent to. The proposed scheme involves signing each other's extended public keys (xpubs) by all signers of a transaction, which can then be used to verify the destination address. Concerns were raised about its use in multisig wallets where some keys may be compromised. To prevent compromised keys from invalidating transactions, hardware wallets could be shown a specific 'epoch' word or serial number for xpub packages. These schemes could be included in PSBT as 'meta-information' or 'vendor-specific' fields.The proposed key value specification aims to address the issue of verifying addresses when transferring funds between cold and warm/hot wallets. While BIP32_DERIVATION can verify an address from a specific XPUB, it cannot verify its signature. The solution involves securely verifying the xpub of the warm/hot wallet using an airgap signing tool, uploading the signature/xpub pairs to the online unsigned transaction generator, and including one keyval pair per coldkey/xpub pairing. To avoid complicating the core PSBT specification, it is suggested that the various schemes should be dealt with outside of PSBT as 'PSBT metainformation' or using vendor-specific fields.The proposal also discusses the implementation of multisig wallet security with PSBT by signing all xpubs for a multisig wallet and including them in each transaction. This ensures that all signers are aware of every key involved in the transaction, increasing security for HD wallets. However, concerns were raised about the possibility of partial compromise, where one of the keys is stolen. The need for proper key revocation mechanisms is highlighted to ensure that signed packages cannot be used by attackers.Overall, the proposed extension of PSBT aims to improve the verification process and increase security for HD wallets. Feedback and suggestions for improvement have been invited by Jonathan Underwood. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_Formalizing-Blind-Statechains-as-a-minimalistic-blind-signing-server.xml b/static/bitcoin-dev/June_2019/combined_Formalizing-Blind-Statechains-as-a-minimalistic-blind-signing-server.xml index abb39d9ae1..bf9e760037 100644 --- a/static/bitcoin-dev/June_2019/combined_Formalizing-Blind-Statechains-as-a-minimalistic-blind-signing-server.xml +++ b/static/bitcoin-dev/June_2019/combined_Formalizing-Blind-Statechains-as-a-minimalistic-blind-signing-server.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Formalizing Blind Statechains as a minimalistic blind signing server - 2023-08-02T00:59:36.738395+00:00 - - Ruben Somsen 2019-06-14 07:18:27+00:00 - - - ZmnSCPxj 2019-06-13 01:22:38+00:00 - - - Ruben Somsen 2019-06-12 21:26:01+00:00 - - - ZmnSCPxj 2019-06-06 06:31:45+00:00 - - - Ruben Somsen 2019-06-06 05:20:31+00:00 - - - ZmnSCPxj 2019-06-06 00:09:28+00:00 - - - Ruben Somsen 2019-06-04 11:28:26+00:00 - + 2025-09-26T16:04:22.148724+00:00 + python-feedgen + + + [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server Ruben Somsen + 2019-06-04T11:28:00.000Z + + + ZmnSCPxj + 2019-06-06T00:09:00.000Z + + + Ruben Somsen + 2019-06-06T05:20:00.000Z + + + ZmnSCPxj + 2019-06-06T06:31:00.000Z + + + Ruben Somsen + 2019-06-12T21:26:00.000Z + + + ZmnSCPxj + 2019-06-13T01:22:00.000Z + + + Ruben Somsen + 2019-06-14T07:18:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Formalizing Blind Statechains as a minimalistic blind signing server - 2023-08-02T00:59:36.738395+00:00 + 2025-09-26T16:04:22.149656+00:00 - The conversation between Ruben Somsen and ZmnSCPxj revolves around the concept of Statechains, which allows for off-chain transfer of UTXO ownership. They discuss the issues with channel factories, such as the "Stale Factory" and "Broken Factory" problems, and how Statechains can address these problems by utilizing `SIGHASH_NOINPUT`. Privacy concerns are also considered, and they agree that combining Statechains with MuSig is the best approach. Ruben prefers to keep the system script-free, but ZmnSCPxj suggests adding a separate smart contracting layer like Smart Contracts Unchained (SCU). They note that any updateable off-chain cryptocurrency system can achieve what Statechains does, and suggest presenting further transactions to the system in order to append them to existing unilateral-case transactions and cut-through on the next update.In their email conversation, Ruben and ZmnSCPxj discuss the problems with channel factories and propose using `SIGHASH_NOINPUT` for all unilateral paths to address these issues. They also discuss potential privacy concerns if `SIGHASH_ANYPREVOUT` requires a chaperone signature. While Ruben is not in favor of adding scripting, he suggests incorporating Smart Contracts Unchained (SCU) as a separate smart contracting layer. They highlight that anything that can be done with a UTXO on-chain can also be done off-chain via Statechains or other updateable off-chain systems like Spillman, Decker-Wattenhofer, Poon-Dryja, or Decker-Russell-Osuntokun. Trust can be distributed by turning the server into a multisig threshold key. Ruben shares an early draft of Statechains with ZmnSCPxj, explaining how it allows for off-chain transfer of Bitcoin UTXOs using blind signatures. The use of blind signatures makes it possible to transfer the signing rights of a private key without changing the key itself. Ruben proposes the use of blind signature servers with two functions that users can call. He also mentions that Statechains can still make use of the Decker-Wattenhofer construction instead of the Decker-Russell-Osuntokun construction ("eltoo"), as fewer updates are needed for Statechains. Trust can be distributed by turning the server into a multisig threshold key, ensuring security on par with federated sidechains.Ruben suggests using blind signatures to transfer ownership of a Bitcoin UTXO off-chain without changing the key itself. The server would sign blindly and be unaware of what it's signing. Trust can be distributed by turning the server into a multisig threshold key, making security similar to federated sidechains. The Decker-Wattenhofer construction can be used instead of "eltoo" for Statechains. However, there is a possibility of an exit scam once a few significant swaps are in position to be stolen.Statechains allow for the transfer of UTXOs off-chain with the help of a Statechain entity without giving them full custodial control. Ruben Somsen proposes using blind signatures to make the entity unaware of what it's signing. The functionality involves a blind signing server with two functions for users to call. Assuming the server is honest, this allows for the transfer of signing rights without changing the key. The primary use case is transferring ownership of a Bitcoin UTXO off-chain using an eltoo tx. Trust can be distributed by turning the server into a multisig threshold key, providing security comparable to federated sidechains. The blind signing server functionality is not specific to Bitcoin and can be used for non-cryptocurrency related purposes as well. 2019-06-14T07:18:27+00:00 + The conversation between Ruben Somsen and ZmnSCPxj revolves around the concept of Statechains, which allows for off-chain transfer of UTXO ownership. They discuss the issues with channel factories, such as the "Stale Factory" and "Broken Factory" problems, and how Statechains can address these problems by utilizing `SIGHASH_NOINPUT`. Privacy concerns are also considered, and they agree that combining Statechains with MuSig is the best approach. Ruben prefers to keep the system script-free, but ZmnSCPxj suggests adding a separate smart contracting layer like Smart Contracts Unchained (SCU). They note that any updateable off-chain cryptocurrency system can achieve what Statechains does, and suggest presenting further transactions to the system in order to append them to existing unilateral-case transactions and cut-through on the next update.In their email conversation, Ruben and ZmnSCPxj discuss the problems with channel factories and propose using `SIGHASH_NOINPUT` for all unilateral paths to address these issues. They also discuss potential privacy concerns if `SIGHASH_ANYPREVOUT` requires a chaperone signature. While Ruben is not in favor of adding scripting, he suggests incorporating Smart Contracts Unchained (SCU) as a separate smart contracting layer. They highlight that anything that can be done with a UTXO on-chain can also be done off-chain via Statechains or other updateable off-chain systems like Spillman, Decker-Wattenhofer, Poon-Dryja, or Decker-Russell-Osuntokun. Trust can be distributed by turning the server into a multisig threshold key. Ruben shares an early draft of Statechains with ZmnSCPxj, explaining how it allows for off-chain transfer of Bitcoin UTXOs using blind signatures. The use of blind signatures makes it possible to transfer the signing rights of a private key without changing the key itself. Ruben proposes the use of blind signature servers with two functions that users can call. He also mentions that Statechains can still make use of the Decker-Wattenhofer construction instead of the Decker-Russell-Osuntokun construction ("eltoo"), as fewer updates are needed for Statechains. Trust can be distributed by turning the server into a multisig threshold key, ensuring security on par with federated sidechains.Ruben suggests using blind signatures to transfer ownership of a Bitcoin UTXO off-chain without changing the key itself. The server would sign blindly and be unaware of what it's signing. Trust can be distributed by turning the server into a multisig threshold key, making security similar to federated sidechains. The Decker-Wattenhofer construction can be used instead of "eltoo" for Statechains. However, there is a possibility of an exit scam once a few significant swaps are in position to be stolen.Statechains allow for the transfer of UTXOs off-chain with the help of a Statechain entity without giving them full custodial control. Ruben Somsen proposes using blind signatures to make the entity unaware of what it's signing. The functionality involves a blind signing server with two functions for users to call. Assuming the server is honest, this allows for the transfer of signing rights without changing the key. The primary use case is transferring ownership of a Bitcoin UTXO off-chain using an eltoo tx. Trust can be distributed by turning the server into a multisig threshold key, providing security comparable to federated sidechains. The blind signing server functionality is not specific to Bitcoin and can be used for non-cryptocurrency related purposes as well. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_Generalized-covenant-to-implement-side-chains-embedded-into-the-bitcoin-block-chain.xml b/static/bitcoin-dev/June_2019/combined_Generalized-covenant-to-implement-side-chains-embedded-into-the-bitcoin-block-chain.xml index dbea9705e9..f986846049 100644 --- a/static/bitcoin-dev/June_2019/combined_Generalized-covenant-to-implement-side-chains-embedded-into-the-bitcoin-block-chain.xml +++ b/static/bitcoin-dev/June_2019/combined_Generalized-covenant-to-implement-side-chains-embedded-into-the-bitcoin-block-chain.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Generalized covenant to implement side chains embedded into the bitcoin block chain - 2023-08-02T01:05:33.330992+00:00 - - Tamas Blummer 2019-06-30 22:25:03+00:00 - - - Tamas Blummer 2019-06-30 17:50:21+00:00 - - - Tamas Blummer 2019-06-30 16:57:06+00:00 - - - ZmnSCPxj 2019-06-29 20:25:07+00:00 - - - Tamas Blummer 2019-06-29 05:53:57+00:00 - + 2025-09-26T16:04:17.937091+00:00 + python-feedgen + + + [bitcoin-dev] Generalized covenant to implement side chains embedded into the bitcoin block chain Tamas Blummer + 2019-06-29T05:53:00.000Z + + + ZmnSCPxj + 2019-06-29T20:25:00.000Z + + + Tamas Blummer + 2019-06-30T16:57:00.000Z + + + Tamas Blummer + 2019-06-30T17:50:00.000Z + + + Tamas Blummer + 2019-06-30T22:25:00.000Z + + - python-feedgen + 2 Combined summary - Generalized covenant to implement side chains embedded into the bitcoin block chain - 2023-08-02T01:05:33.330992+00:00 + 2025-09-26T16:04:17.937812+00:00 - Tamas Blummer has introduced the concept of a generalized covenant in a recent bitcoin-dev post. This covenant allows for the creation of a federated side chain embedded into the Bitcoin block chain. The covenant puts a coin under the alternative control of Transfer and Exit keys, along with the script controlled by the current owner. Additional transaction level validations apply to transactions spending input with covenants.The purpose of this covenant is to offer alternate control paths, which is what taproot was designed for. By reducing control for the current owner and exploring less invasive predicates first, new use cases can be unlocked. One example is a covenant based on the total work performed by a miner, which could be a candidate for the annex.Another example scenario is presented where Bob purchases an asset guarded by the federation. If Alice wants to exit, she would need the exit signature of the federation. ZmnSCPxj raises concerns about the usefulness of covenants and suggests the idea of Smart Contracts Unchained. In response, Tamas provides an alternative covenant that allows for unrestricted flexibility to the unchained platform while maintaining the exit option.In an email exchange with ZmnSCPxj, Tamas acknowledges making an error in proposing the new covenant and suggests that the original example should remain unchanged. He also admits that he does not have a good answer for why the rightful owner is not enforcing the covenant instead of having it enforced by on-chain consensus.Tamas introduces the concept of a cut-through exit transaction suggested by ZmnSCPxj, which strengthens the example. This involves using the covenant: 'covenant or(_ covenant transitive, and(pkExit, _) covenant drop)'.Overall, the concept of generalized covenants offers a solution for creating federated side chains embedded into the Bitcoin block chain. It allows for alternative control of coins and additional transaction level validations. The examples provided demonstrate how these covenants can be applied in various scenarios. 2019-06-30T22:25:03+00:00 + Tamas Blummer has introduced the concept of a generalized covenant in a recent bitcoin-dev post. This covenant allows for the creation of a federated side chain embedded into the Bitcoin block chain. The covenant puts a coin under the alternative control of Transfer and Exit keys, along with the script controlled by the current owner. Additional transaction level validations apply to transactions spending input with covenants.The purpose of this covenant is to offer alternate control paths, which is what taproot was designed for. By reducing control for the current owner and exploring less invasive predicates first, new use cases can be unlocked. One example is a covenant based on the total work performed by a miner, which could be a candidate for the annex.Another example scenario is presented where Bob purchases an asset guarded by the federation. If Alice wants to exit, she would need the exit signature of the federation. ZmnSCPxj raises concerns about the usefulness of covenants and suggests the idea of Smart Contracts Unchained. In response, Tamas provides an alternative covenant that allows for unrestricted flexibility to the unchained platform while maintaining the exit option.In an email exchange with ZmnSCPxj, Tamas acknowledges making an error in proposing the new covenant and suggests that the original example should remain unchanged. He also admits that he does not have a good answer for why the rightful owner is not enforcing the covenant instead of having it enforced by on-chain consensus.Tamas introduces the concept of a cut-through exit transaction suggested by ZmnSCPxj, which strengthens the example. This involves using the covenant: 'covenant or(_ covenant transitive, and(pkExit, _) covenant drop)'.Overall, the concept of generalized covenants offers a solution for creating federated side chains embedded into the Bitcoin block chain. It allows for alternative control of coins and additional transaction level validations. The examples provided demonstrate how these covenants can be applied in various scenarios. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_Generalized-covenants-with-taproot-enable-riskless-or-risky-lending-prevent-credit-inflation-through-fractional-reserve.xml b/static/bitcoin-dev/June_2019/combined_Generalized-covenants-with-taproot-enable-riskless-or-risky-lending-prevent-credit-inflation-through-fractional-reserve.xml index b10d4e513d..875db634bb 100644 --- a/static/bitcoin-dev/June_2019/combined_Generalized-covenants-with-taproot-enable-riskless-or-risky-lending-prevent-credit-inflation-through-fractional-reserve.xml +++ b/static/bitcoin-dev/June_2019/combined_Generalized-covenants-with-taproot-enable-riskless-or-risky-lending-prevent-credit-inflation-through-fractional-reserve.xml @@ -1,62 +1,187 @@ - + 2 Combined summary - Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve - 2023-08-02T01:04:01.587059+00:00 - - Tamas Blummer 2019-07-09 20:32:53+00:00 - - - Tamas Blummer 2019-07-07 09:18:04+00:00 - - - Tamas Blummer 2019-07-06 13:34:31+00:00 - - - Tamas Blummer 2019-07-06 10:12:44+00:00 - - - Tamas Blummer 2019-07-04 17:10:31+00:00 - - - Tamas Blummer 2019-07-02 12:51:31+00:00 - - - Tamas Blummer 2019-07-02 10:14:32+00:00 - - - Tamas Blummer 2019-07-02 09:47:09+00:00 - - - Tamas Blummer 2019-07-02 09:30:31+00:00 - - - Tamas Blummer 2019-07-02 06:38:55+00:00 - - - Tamas Blummer 2019-07-02 05:08:53+00:00 - - - Tamas Blummer 2019-06-30 20:26:29+00:00 - - - Tamas Blummer 2019-06-30 19:55:41+00:00 - - - Tamas Blummer 2019-06-30 18:35:33+00:00 - - - Tamas Blummer 2019-06-30 10:56:46+00:00 - - - David A. Harding 2019-06-29 18:21:03+00:00 - - - Tamas Blummer 2019-06-28 19:21:56+00:00 - - - Tamas Blummer 2019-06-28 08:27:16+00:00 - + 2025-09-26T16:04:01.103591+00:00 + python-feedgen + + + [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve Tamas Blummer + 2019-06-28T08:27:00.000Z + + + Eric Voskuil + 2019-06-28T17:25:00.000Z + + + Tamas Blummer + 2019-06-28T19:21:00.000Z + + + David A. Harding + 2019-06-29T18:21:00.000Z + + + Eric Voskuil + 2019-06-29T21:21:00.000Z + + + Tamas Blummer + 2019-06-30T10:56:00.000Z + + + Eric Voskuil + 2019-06-30T17:41:00.000Z + + + Tamas Blummer + 2019-06-30T18:35:00.000Z + + + Eric Voskuil + 2019-06-30T18:54:00.000Z + + + Tamas Blummer + 2019-06-30T19:55:00.000Z + + + Eric Voskuil + 2019-06-30T20:13:00.000Z + + + Tamas Blummer + 2019-06-30T20:26:00.000Z + + + Eric Voskuil + 2019-07-01T18:52:00.000Z + + + ZmnSCPxj + 2019-07-02T03:45:00.000Z + + + Tamas Blummer + 2019-07-02T05:08:00.000Z + + + Tamas Blummer + 2019-07-02T06:38:00.000Z + + + ZmnSCPxj + 2019-07-02T08:12:00.000Z + + + Tamas Blummer + 2019-07-02T09:30:00.000Z + + + Tamas Blummer + 2019-07-02T09:47:00.000Z + + + Tamas Blummer + 2019-07-02T10:14:00.000Z + + + ZmnSCPxj + 2019-07-02T10:33:00.000Z + + + Tamas Blummer + 2019-07-02T12:51:00.000Z + + + Eric Voskuil + 2019-07-03T22:30:00.000Z + + + ZmnSCPxj + 2019-07-04T04:57:00.000Z + + + Eric Voskuil + 2019-07-04T16:43:00.000Z + + + Tamas Blummer + 2019-07-04T17:10:00.000Z + + + Eric Voskuil + 2019-07-04T18:31:00.000Z + + + Eric Voskuil + 2019-07-04T19:31:00.000Z + + + ZmnSCPxj + 2019-07-05T04:05:00.000Z + + + Eric Voskuil + 2019-07-05T19:27:00.000Z + + + ZmnSCPxj + 2019-07-05T23:16:00.000Z + + + Eric Voskuil + 2019-07-05T23:20:00.000Z + + + Eric Voskuil + 2019-07-05T23:44:00.000Z + + + ZmnSCPxj + 2019-07-06T00:17:00.000Z + + + Eric Voskuil + 2019-07-06T01:28:00.000Z + + + Eric Voskuil + 2019-07-06T01:46:00.000Z + + + Tamas Blummer + 2019-07-06T10:12:00.000Z + + + Tamas Blummer + 2019-07-06T13:34:00.000Z + + + Eric Voskuil + 2019-07-06T22:21:00.000Z + + + Eric Voskuil + 2019-07-06T22:37:00.000Z + + + Eric Voskuil + 2019-07-07T01:30:00.000Z + + + Tamas Blummer + 2019-07-07T09:18:00.000Z + + + ZmnSCPxj + 2019-07-09T10:31:00.000Z + + + Tamas Blummer + 2019-07-09T20:32:00.000Z + + @@ -75,13 +200,13 @@ - python-feedgen + 2 Combined summary - Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve - 2023-08-02T01:04:01.587059+00:00 + 2025-09-26T16:04:01.107981+00:00 - The email thread revolves around the concept of a "Bitcoin Classified Ads Network" (BCAN) and its potential to create censorship-resistant networks that provide riskless interest on Bitcoin. In BCAN, nodes share advertisements referring to unspent transaction outputs (UTXOs) at the chain tip. Advertisements have a size limit and include a commitment to the text. If nodes exceed this limit, they sort advertisements by value-rate and remove low-value ones. Sellers aim to minimize the value in UTXOs backing their ads. Rent for advertisements is paid to joinmarket makers and LN forwarding nodes. Users can query their own BCAN node for specific advertisements without compromising privacy.The author criticizes Eric's cryproeconomic theories, stating that they accurately describe Bitcoin as money but fail to consider reliable memory for other uses. They argue that if memory had more uses, even temporarily, it would have utility and value. However, Bitcoin lacks consensus rules to enable reliable alternate uses. The finite supply of coins implies a finite memory capacity, making units temporarily un-fungible. This leads to competition for memory units and a price paid to enable alternate use. Giving up temporary control has a positive price, and return of control is certain, resulting in riskless interest. The author suggests designing systems to sustain Bitcoin while avoiding burning for unlimited uses.The conversation between Eric Voskuil and ZmnSCPxj focuses on encumbering UTXOs in an ad market and its relationship to opportunity cost. ZmnSCPxj argues that early recovery of UTXOs eliminates time lock costs, but Eric asserts that he is discussing cryptoeconomic principles, not implementation details. Eric claims that multisig unlock reduces UTXOs to just UTXOs, removing actual encumbrance. Any UTXO can prove ownership in the ad network, but higher-value UTXOs may be prioritized by limited-bandwidth services. Tamas Blummer concludes the email chain.Another email exchange between ZmnSCPxj and Eric Voskuil discusses using the unspentness-time of a UTXO for advertising services or producers. This allows merchants to recover locked funds by spending the advertising UTXO once the stock is sold. The proposal separates fund owners from users, enabling dynamic maturity. Burning is considered unsustainable, so the covenant enables temporary use of UTXOs for something other than money. The current owner of a UTXO will be paid for temporarily giving up control, representing interest.Tamas Blummer and Eric Voskuil discuss imposing costs on use without direct billing. Methods include burning Bitcoins, paying high fees in self-dealing transactions, time-locking own Bitcoins, paying someone else to time-lock, and transferable borrowed Bitcoin. Eric suggests that community hashcash spam protection can raise encumbered coin requirement for advertising threshold price. They also discuss "renting a UTXO of substantial value" and its viability. However, Eric is not fully supportive of generalized covenants as he believes the use-case already exists. ZmnSCPxj presents another use case involving a "Bitcoin Classified Ads Network," where nodes preferentially keep higher-value backed advertisements.Tamas Blummer and ZmnSCPxj discuss the use of temporary control UTXOs for services that require it. If there is demand, users pay fees to the service provider and cover opportunity cost paid to the original holder. Temporary access to significant-value UTXOs induces opportunity cost for users, while burning ordinary UTXOs is seen as unsustainable. Temporary access UTXOs with covenants can build spam-limited public services without an operator and offer HODLers riskless interest.The value of an encumbered UTXO is reduced due to governance by different rules in a de-facto side chain. Renting an encumbered UTXO is only valuable for the advertisement, not opportunity cost. Temporary access through covenants allows anyone with control to recover the cost by sub-renting. Committing to a public key instead of advertisements is suggested, but it risks the HODLer's funds if the advertiser misbehaves.Tamas Blummer and ZmnSCPxj discuss solving problems using covenants. Consensus support is necessary only if an unchained setup is closed uncooperatively. An advertising scheme involving committing a public key on the UTXO is proposed, but it requires trusting the advertising service, which goes against the trustless separation provided by covenants.ZmnSCPxj suggests the Graftroot idea, committing a public key on the UTXO and using a SCRIPT signed by the public key to unlock it. Tamas Blummer points out that this puts HODLer's funds at risk and negates the trustless separation achieved by covenants.The email exchange discusses a "Bitcoin Classified Ads Network" where P2PKH UTXOs embed commitments to advertisements, transmitted via a secondary 2019-07-09T20:32:53+00:00 + The email thread revolves around the concept of a "Bitcoin Classified Ads Network" (BCAN) and its potential to create censorship-resistant networks that provide riskless interest on Bitcoin. In BCAN, nodes share advertisements referring to unspent transaction outputs (UTXOs) at the chain tip. Advertisements have a size limit and include a commitment to the text. If nodes exceed this limit, they sort advertisements by value-rate and remove low-value ones. Sellers aim to minimize the value in UTXOs backing their ads. Rent for advertisements is paid to joinmarket makers and LN forwarding nodes. Users can query their own BCAN node for specific advertisements without compromising privacy.The author criticizes Eric's cryproeconomic theories, stating that they accurately describe Bitcoin as money but fail to consider reliable memory for other uses. They argue that if memory had more uses, even temporarily, it would have utility and value. However, Bitcoin lacks consensus rules to enable reliable alternate uses. The finite supply of coins implies a finite memory capacity, making units temporarily un-fungible. This leads to competition for memory units and a price paid to enable alternate use. Giving up temporary control has a positive price, and return of control is certain, resulting in riskless interest. The author suggests designing systems to sustain Bitcoin while avoiding burning for unlimited uses.The conversation between Eric Voskuil and ZmnSCPxj focuses on encumbering UTXOs in an ad market and its relationship to opportunity cost. ZmnSCPxj argues that early recovery of UTXOs eliminates time lock costs, but Eric asserts that he is discussing cryptoeconomic principles, not implementation details. Eric claims that multisig unlock reduces UTXOs to just UTXOs, removing actual encumbrance. Any UTXO can prove ownership in the ad network, but higher-value UTXOs may be prioritized by limited-bandwidth services. Tamas Blummer concludes the email chain.Another email exchange between ZmnSCPxj and Eric Voskuil discusses using the unspentness-time of a UTXO for advertising services or producers. This allows merchants to recover locked funds by spending the advertising UTXO once the stock is sold. The proposal separates fund owners from users, enabling dynamic maturity. Burning is considered unsustainable, so the covenant enables temporary use of UTXOs for something other than money. The current owner of a UTXO will be paid for temporarily giving up control, representing interest.Tamas Blummer and Eric Voskuil discuss imposing costs on use without direct billing. Methods include burning Bitcoins, paying high fees in self-dealing transactions, time-locking own Bitcoins, paying someone else to time-lock, and transferable borrowed Bitcoin. Eric suggests that community hashcash spam protection can raise encumbered coin requirement for advertising threshold price. They also discuss "renting a UTXO of substantial value" and its viability. However, Eric is not fully supportive of generalized covenants as he believes the use-case already exists. ZmnSCPxj presents another use case involving a "Bitcoin Classified Ads Network," where nodes preferentially keep higher-value backed advertisements.Tamas Blummer and ZmnSCPxj discuss the use of temporary control UTXOs for services that require it. If there is demand, users pay fees to the service provider and cover opportunity cost paid to the original holder. Temporary access to significant-value UTXOs induces opportunity cost for users, while burning ordinary UTXOs is seen as unsustainable. Temporary access UTXOs with covenants can build spam-limited public services without an operator and offer HODLers riskless interest.The value of an encumbered UTXO is reduced due to governance by different rules in a de-facto side chain. Renting an encumbered UTXO is only valuable for the advertisement, not opportunity cost. Temporary access through covenants allows anyone with control to recover the cost by sub-renting. Committing to a public key instead of advertisements is suggested, but it risks the HODLer's funds if the advertiser misbehaves.Tamas Blummer and ZmnSCPxj discuss solving problems using covenants. Consensus support is necessary only if an unchained setup is closed uncooperatively. An advertising scheme involving committing a public key on the UTXO is proposed, but it requires trusting the advertising service, which goes against the trustless separation provided by covenants.ZmnSCPxj suggests the Graftroot idea, committing a public key on the UTXO and using a SCRIPT signed by the public key to unlock it. Tamas Blummer points out that this puts HODLer's funds at risk and negates the trustless separation achieved by covenants.The email exchange discusses a "Bitcoin Classified Ads Network" where P2PKH UTXOs embed commitments to advertisements, transmitted via a secondary - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol.xml b/static/bitcoin-dev/June_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol.xml index 2f15a3290c..a4a31a7a0f 100644 --- a/static/bitcoin-dev/June_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol.xml +++ b/static/bitcoin-dev/June_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP - v2 peer-to-peer message transport protocol - 2023-08-02T01:00:18.342511+00:00 + 2025-09-26T16:04:11.648047+00:00 + python-feedgen Elichai Turkel 2019-06-17 17:13:05+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - New BIP - v2 peer-to-peer message transport protocol - 2023-08-02T01:00:18.342511+00:00 + 2025-09-26T16:04:11.648194+00:00 - In an email conversation between Elichai Turkel and Jonas Schnelli, the topic of the message sequence number for Chacha20 is discussed. Schnelli explains that the proposed AEAD in BIP324 uses a "message sequence number" as the nonce instead of a random nonce. The sequence number starts at 0 and cannot be reset without rekeying. Additionally, the maximum amount of traffic allowed before rekeying is 1GB, and there is no possibility of nonce/key reuse. While XChaCha20 allows for a random nonce, using a sequence number as a nonce is considered safe.The discussion also touches on the change from a 64-bit to a 96-bit nonce in RFC7539. Elichai suggests using the "message sequence number" as the nonce for Chacha20, which prompts a query about whether this number is randomly generated or a counter, and if it can be reset without rekeying. If the number is randomly generated, then a 64-bit nonce may not be secure enough, and it is suggested to either use Chacha20 from RFC7539, which has a 96-bit nonce and 32-bit counter, or manually increment the nonce every time. However, if the number is simply a counter, then a 64-bit nonce should suffice.This email thread emphasizes the importance of understanding nonce and its security implications when implementing cryptographic protocols. 2019-06-17T17:13:05+00:00 + In an email conversation between Elichai Turkel and Jonas Schnelli, the topic of the message sequence number for Chacha20 is discussed. Schnelli explains that the proposed AEAD in BIP324 uses a "message sequence number" as the nonce instead of a random nonce. The sequence number starts at 0 and cannot be reset without rekeying. Additionally, the maximum amount of traffic allowed before rekeying is 1GB, and there is no possibility of nonce/key reuse. While XChaCha20 allows for a random nonce, using a sequence number as a nonce is considered safe.The discussion also touches on the change from a 64-bit to a 96-bit nonce in RFC7539. Elichai suggests using the "message sequence number" as the nonce for Chacha20, which prompts a query about whether this number is randomly generated or a counter, and if it can be reset without rekeying. If the number is randomly generated, then a 64-bit nonce may not be secure enough, and it is suggested to either use Chacha20 from RFC7539, which has a 96-bit nonce and 32-bit counter, or manually increment the nonce every time. However, if the number is simply a counter, then a 64-bit nonce should suffice.This email thread emphasizes the importance of understanding nonce and its security implications when implementing cryptographic protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml b/static/bitcoin-dev/June_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml index 33059efccc..1580457141 100644 --- a/static/bitcoin-dev/June_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml +++ b/static/bitcoin-dev/June_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) - 2023-08-02T00:56:33.739774+00:00 - - Jeremy 2019-10-03 23:22:47+00:00 - - - Dmitry Petukhov 2019-07-08 10:26:24+00:00 - - - Russell O'Connor 2019-06-25 17:05:39+00:00 - - - Jeremy 2019-06-24 22:47:44+00:00 - - - Russell O'Connor 2019-06-24 18:48:51+00:00 - - - Jeremy 2019-06-24 18:07:20+00:00 - - - Russell O'Connor 2019-06-24 14:34:54+00:00 - - - ZmnSCPxj 2019-06-23 13:11:03+00:00 - - - Jeremy 2019-06-23 06:43:22+00:00 - - - Anthony Towns 2019-06-20 22:05:52+00:00 - - - Russell O'Connor 2019-06-18 20:57:34+00:00 - - - ZmnSCPxj 2019-06-06 07:30:13+00:00 - - - Anthony Towns 2019-06-05 09:30:39+00:00 - - - Jeremy 2019-06-02 21:32:20+00:00 - - - Russell O'Connor 2019-06-02 14:32:33+00:00 - - - ZmnSCPxj 2019-06-02 05:35:43+00:00 - - - Jeremy 2019-06-01 05:35:45+00:00 - + 2025-09-26T16:04:20.054048+00:00 + python-feedgen + + + [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) Jeremy + 2019-06-01T05:35:00.000Z + + + ZmnSCPxj + 2019-06-02T05:35:00.000Z + + + Russell O'Connor + 2019-06-02T14:32:00.000Z + + + Jeremy + 2019-06-02T21:32:00.000Z + + + Anthony Towns + 2019-06-05T09:30:00.000Z + + + ZmnSCPxj + 2019-06-06T07:30:00.000Z + + + Russell O'Connor + 2019-06-18T20:57:00.000Z + + + Anthony Towns + 2019-06-20T22:05:00.000Z + + + Jeremy + 2019-06-23T06:43:00.000Z + + + ZmnSCPxj + 2019-06-23T13:11:00.000Z + + + Russell O'Connor + 2019-06-24T14:34:00.000Z + + + Jeremy + 2019-06-24T18:07:00.000Z + + + Russell O'Connor + 2019-06-24T18:48:00.000Z + + + Jeremy + 2019-06-24T22:47:00.000Z + + + Russell O'Connor + 2019-06-25T17:05:00.000Z + + + Dmitry Petukhov + 2019-07-08T10:26:00.000Z + + + Jeremy + 2019-10-03T23:22:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) - 2023-08-02T00:56:33.739774+00:00 + 2025-09-26T16:04:20.055793+00:00 - Jeremy Rubin has proposed an update to the Bitcoin Improvement Proposal (BIP) that replaces Taproot with an OP_NOP upgrade. The BIP introduces OP_NOP4, which enables the OP_SECURETHEBAG feature for segwit and bare script, but not P2SH. Dmitry Petukhov suggests using a control-sig to restrict spending conditions and proposes additional flags for sighash. Anthony Towns suggests simulating OP_SECURETHEBAG with an ANYPREVOUT sighash. The bitcoin-dev mailing list discusses eliminating malleability in UTXOs using the ANYPREVOUTANYSCRIPT signature and the need for improvements in tapscript implementation. There are suggestions to improve script parsing, versioning techniques, and compatibility with templated scripts. The author of the context argues against the use of OP_IF and proposes upgrading the script parser with a new interpreter for Tapscript. They also discuss the introduction of Turing-completeness in Bitcoin SCRIPT and the potential for creating covenants using OP_TWEEKPUBKEY.The debate revolves around the complexity of changes to Bitcoin Core and the need to ensure script semantics are easily understandable. There is a proposal to add the OP_SECURETHEBAG opcode to modify public keys in Bitcoin script, but concerns are raised about its impact on script composability. The commitment of the script itself is questioned, and suggestions are made to include it in the opcode or use an OP_TWEEKPUBKEY operation. Additionally, the possibility of enabling recursive covenants and making Bitcoin SCRIPT Turing-complete is discussed.An alternative approach using an ANYPREVOUT sighash to simulate OP_SECURETHEBAG is suggested. This involves calculating a signature for a pubkey and using "CHECKSIG" in the script. Issues regarding commitment to inputs and the size of the script are raised. Another proposal for an opcode called OP_CHECKTXDIGESTVERIFY is discussed, which could enable covenants and Turing-complete smart contracts. The debate centers around the need to precommit the digest as part of the opcode.In conclusion, the bitcoin-dev mailing list discusses various proposals and improvements related to script semantics, malleability in UTXOs, and the introduction of new opcodes. The focus is on enhancing tapscript implementation, enabling covenants, and exploring the potential for Turing-completeness in Bitcoin SCRIPT.On May 31, 2019, Jeremy Rubin announced the retraction of the proposed opcode 'OP_CHECKOUTPUTSHASHVERIFY' in favor of a new opcode called 'OP_SECURETHEBAG'. The new opcode aims to fix malleability issues and lift the single output restriction to a known number of inputs restriction. It allows for more flexibility while still keeping the ease of use. The proposed change involves pulling a 33-byte value from the stack, consisting of a sha256 hash and a sighash-byte, and adding a new sighash value corresponding to the set of information to include in the hash.The author acknowledges receiving a response from someone named Russell and admits to having missed some points of concern related to malleability. They provide a code snippet showing how TXID is computed and mention that it can be modified in certain cases, leading to potential security issues. However, the author mentions that they have revisited their work and believe they have addressed all the concerns related to malleability. They express hope that their changes will fully address the issue.The new opcode, OP_SECURETHEBAG, commits to both version and locktime, which was not possible with the previous opcode. It also lifts the restriction on the number of inputs needed, allowing for more flexibility. However, this feature requires special design to be safe, and a backout transaction is required before the funding transaction output is committed onchain. For Poon-Dryja channels, the initial commitment transaction is used as the backout transaction. The continued operation of the protocol requires the initial commitment to be revoked at the next update. A plausible backout for the receiver is needed for this purpose. To do so, the funding transaction address is made a Taproot with an internal pubkey 2-of-2 of the receiver and its channel counterparty.The proposed OP_CHECKOUTPUTSHASHVERIFY has been retracted in favor of the new proposal, OP_SECURETHEBAG. The new proposal fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. The previous proposal had some issues with malleability of version and locktime. OP_SECURETHEBAG commits to both of these values and also lifts the restriction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, and instead just commits to the number of inputs. This allows for more flexibility but keeps it easy to get the same single output restriction.A BIP is available at https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki and the implementation can be found at 2019-10-03T23:22:47+00:00 + Jeremy Rubin has proposed an update to the Bitcoin Improvement Proposal (BIP) that replaces Taproot with an OP_NOP upgrade. The BIP introduces OP_NOP4, which enables the OP_SECURETHEBAG feature for segwit and bare script, but not P2SH. Dmitry Petukhov suggests using a control-sig to restrict spending conditions and proposes additional flags for sighash. Anthony Towns suggests simulating OP_SECURETHEBAG with an ANYPREVOUT sighash. The bitcoin-dev mailing list discusses eliminating malleability in UTXOs using the ANYPREVOUTANYSCRIPT signature and the need for improvements in tapscript implementation. There are suggestions to improve script parsing, versioning techniques, and compatibility with templated scripts. The author of the context argues against the use of OP_IF and proposes upgrading the script parser with a new interpreter for Tapscript. They also discuss the introduction of Turing-completeness in Bitcoin SCRIPT and the potential for creating covenants using OP_TWEEKPUBKEY.The debate revolves around the complexity of changes to Bitcoin Core and the need to ensure script semantics are easily understandable. There is a proposal to add the OP_SECURETHEBAG opcode to modify public keys in Bitcoin script, but concerns are raised about its impact on script composability. The commitment of the script itself is questioned, and suggestions are made to include it in the opcode or use an OP_TWEEKPUBKEY operation. Additionally, the possibility of enabling recursive covenants and making Bitcoin SCRIPT Turing-complete is discussed.An alternative approach using an ANYPREVOUT sighash to simulate OP_SECURETHEBAG is suggested. This involves calculating a signature for a pubkey and using "CHECKSIG" in the script. Issues regarding commitment to inputs and the size of the script are raised. Another proposal for an opcode called OP_CHECKTXDIGESTVERIFY is discussed, which could enable covenants and Turing-complete smart contracts. The debate centers around the need to precommit the digest as part of the opcode.In conclusion, the bitcoin-dev mailing list discusses various proposals and improvements related to script semantics, malleability in UTXOs, and the introduction of new opcodes. The focus is on enhancing tapscript implementation, enabling covenants, and exploring the potential for Turing-completeness in Bitcoin SCRIPT.On May 31, 2019, Jeremy Rubin announced the retraction of the proposed opcode 'OP_CHECKOUTPUTSHASHVERIFY' in favor of a new opcode called 'OP_SECURETHEBAG'. The new opcode aims to fix malleability issues and lift the single output restriction to a known number of inputs restriction. It allows for more flexibility while still keeping the ease of use. The proposed change involves pulling a 33-byte value from the stack, consisting of a sha256 hash and a sighash-byte, and adding a new sighash value corresponding to the set of information to include in the hash.The author acknowledges receiving a response from someone named Russell and admits to having missed some points of concern related to malleability. They provide a code snippet showing how TXID is computed and mention that it can be modified in certain cases, leading to potential security issues. However, the author mentions that they have revisited their work and believe they have addressed all the concerns related to malleability. They express hope that their changes will fully address the issue.The new opcode, OP_SECURETHEBAG, commits to both version and locktime, which was not possible with the previous opcode. It also lifts the restriction on the number of inputs needed, allowing for more flexibility. However, this feature requires special design to be safe, and a backout transaction is required before the funding transaction output is committed onchain. For Poon-Dryja channels, the initial commitment transaction is used as the backout transaction. The continued operation of the protocol requires the initial commitment to be revoked at the next update. A plausible backout for the receiver is needed for this purpose. To do so, the funding transaction address is made a Taproot with an internal pubkey 2-of-2 of the receiver and its channel counterparty.The proposed OP_CHECKOUTPUTSHASHVERIFY has been retracted in favor of the new proposal, OP_SECURETHEBAG. The new proposal fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. The previous proposal had some issues with malleability of version and locktime. OP_SECURETHEBAG commits to both of these values and also lifts the restriction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, and instead just commits to the number of inputs. This allows for more flexibility but keeps it easy to get the same single output restriction.A BIP is available at https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki and the implementation can be found at - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_Taproot-proposal.xml b/static/bitcoin-dev/June_2019/combined_Taproot-proposal.xml index e88df4e080..93ab8a033d 100644 --- a/static/bitcoin-dev/June_2019/combined_Taproot-proposal.xml +++ b/static/bitcoin-dev/June_2019/combined_Taproot-proposal.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Taproot proposal - 2023-08-02T00:47:13.477592+00:00 - - Pieter Wuille 2019-09-18 21:21:56+00:00 - - - ZmnSCPxj 2019-09-17 04:09:50+00:00 - - - Greg Sanders 2019-09-16 16:18:35+00:00 - - - Pieter Wuille 2019-08-09 18:29:55+00:00 - - - Elichai Turkel 2019-08-09 14:58:58+00:00 - - - Russell O'Connor 2019-06-28 11:16:46+00:00 - - - Anthony Towns 2019-06-28 09:49:37+00:00 - - - Russell O'Connor 2019-06-27 00:08:01+00:00 - - - Russell O'Connor 2019-05-23 02:32:26+00:00 - - - Pieter Wuille 2019-05-23 02:06:42+00:00 - - - John Newbery 2019-05-22 14:14:44+00:00 - - - Russell O'Connor 2019-05-21 17:20:32+00:00 - - - ZmnSCPxj 2019-05-18 17:51:16+00:00 - - - ZmnSCPxj 2019-05-10 05:38:52+00:00 - - - Johnson Lau 2019-05-09 16:56:57+00:00 - - - Pieter Wuille 2019-05-08 23:06:51+00:00 - - - Luke Dashjr 2019-05-08 13:10:17+00:00 - - - ZmnSCPxj 2019-05-08 05:16:03+00:00 - - - Anthony Towns 2019-05-08 04:49:28+00:00 - - - ZmnSCPxj 2019-05-08 04:37:37+00:00 - - - ZmnSCPxj 2019-05-08 03:44:29+00:00 - - - Sjors Provoost 2019-05-07 20:42:58+00:00 - - - Luke Dashjr 2019-05-06 20:17:09+00:00 - - - Pieter Wuille 2019-05-06 17:57:57+00:00 - + 2025-09-26T16:04:05.316433+00:00 + python-feedgen + + + [bitcoin-dev] Taproot proposal Pieter Wuille + 2019-05-06T17:57:00.000Z + + + Luke Dashjr + 2019-05-06T20:17:00.000Z + + + Sjors Provoost + 2019-05-07T20:42:00.000Z + + + ZmnSCPxj + 2019-05-08T03:44:00.000Z + + + ZmnSCPxj + 2019-05-08T04:37:00.000Z + + + Anthony Towns + 2019-05-08T04:49:00.000Z + + + ZmnSCPxj + 2019-05-08T05:16:00.000Z + + + Luke Dashjr + 2019-05-08T13:10:00.000Z + + + Pieter Wuille + 2019-05-08T23:06:00.000Z + + + Johnson Lau + 2019-05-09T16:56:00.000Z + + + ZmnSCPxj + 2019-05-10T05:38:00.000Z + + + ZmnSCPxj + 2019-05-18T17:51:00.000Z + + + Russell O'Connor + 2019-05-21T17:20:00.000Z + + + John Newbery + 2019-05-22T14:14:00.000Z + + + Pieter Wuille + 2019-05-23T02:06:00.000Z + + + Russell O'Connor + 2019-05-23T02:32:00.000Z + + + Russell O'Connor + 2019-06-27T00:08:00.000Z + + + Anthony Towns + 2019-06-28T09:49:00.000Z + + + Russell O'Connor + 2019-06-28T11:16:00.000Z + + + Elichai Turkel + 2019-08-09T14:58:00.000Z + + + Pieter Wuille + 2019-08-09T18:29:00.000Z + + + Greg Sanders + 2019-09-16T16:18:00.000Z + + + ZmnSCPxj + 2019-09-17T04:09:00.000Z + + + Pieter Wuille + 2019-09-18T21:21:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Taproot proposal - 2023-08-02T00:47:13.477592+00:00 + 2025-09-26T16:04:05.318759+00:00 - Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown. This technique offers improved privacy and can be useful for setting up Pedersen commitments.Another topic of conversation revolves around signing an additional 2019-09-18T21:21:56+00:00 + Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown. This technique offers improved privacy and can be useful for setting up Pedersen commitments.Another topic of conversation revolves around signing an additional - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_Transcripts-from-coredev-tech-Amsterdam-2019-meeting.xml b/static/bitcoin-dev/June_2019/combined_Transcripts-from-coredev-tech-Amsterdam-2019-meeting.xml index 7e82d97de9..91fce1348b 100644 --- a/static/bitcoin-dev/June_2019/combined_Transcripts-from-coredev-tech-Amsterdam-2019-meeting.xml +++ b/static/bitcoin-dev/June_2019/combined_Transcripts-from-coredev-tech-Amsterdam-2019-meeting.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Transcripts from coredev.tech Amsterdam 2019 meeting - 2023-08-02T00:59:49.309087+00:00 - - Cory Fields 2019-06-21 02:56:21+00:00 - - - Bryan Bishop 2019-06-07 15:02:13+00:00 - + 2025-09-26T16:04:03.197400+00:00 + python-feedgen + + + [bitcoin-dev] Transcripts from coredev.tech Amsterdam 2019 meeting Bryan Bishop + 2019-06-07T15:02:00.000Z + + + Cory Fields + 2019-06-21T02:56:00.000Z + + - python-feedgen + 2 Combined summary - Transcripts from coredev.tech Amsterdam 2019 meeting - 2023-08-02T00:59:49.309087+00:00 + 2025-09-26T16:04:03.197876+00:00 - During the coredev.tech Amsterdam 2019 meeting, Bryan Bishop shared comprehensive notes that covered a wide range of topics related to Bitcoin Core development. These notes provide valuable insights into various discussions that took place during the meeting. The topics include the code review process in Bitcoin Core, highlighting the challenges faced by maintainers. The discussion also touched upon wallet re-architecture and consensus cleanup, addressing important aspects of Bitcoin's functionality.Furthermore, the notes delve into technical details such as SIGHASH_NOINPUT, OP_CHECKSIGFROMSTACK, OP_CHECKOUTPUTSHASHVERIFY, and OP_SECURETHEBAG. These discussions shed light on specific features and improvements being considered for Bitcoin Core. Additionally, the meeting also featured a detailed conversation about Taproot, exploring its potential impact on Bitcoin's privacy and scalability.Other topics covered in the meeting include Utreexo, assumeutxo, hardware wallets, and HWI (Hardware Wallet Interface). These discussions offer insights into the development of secure and efficient hardware solutions for Bitcoin storage and transactions. The notes also touch upon bip151, p2p encryption, and v2 message format, which are crucial components of Bitcoin's network communication protocols.The coredev.tech Amsterdam 2019 meeting also addressed the use of Signet for bitcoin test networks, providing an overview of its benefits and potential applications. Additionally, the notes discuss Statechains, presenting a comprehensive overview of this innovative approach to off-chain Bitcoin transfers.In summary, the links provided in the email thread offer detailed information on various aspects of Bitcoin Core development discussed during the coredev.tech Amsterdam 2019 meeting. These insights cover topics such as code review processes, maintainers' challenges, wallet re-architecture, consensus cleanup, specific technical features, scalability solutions, hardware wallets, network communication protocols, test networks, and off-chain transfers. 2019-06-21T02:56:21+00:00 + During the coredev.tech Amsterdam 2019 meeting, Bryan Bishop shared comprehensive notes that covered a wide range of topics related to Bitcoin Core development. These notes provide valuable insights into various discussions that took place during the meeting. The topics include the code review process in Bitcoin Core, highlighting the challenges faced by maintainers. The discussion also touched upon wallet re-architecture and consensus cleanup, addressing important aspects of Bitcoin's functionality.Furthermore, the notes delve into technical details such as SIGHASH_NOINPUT, OP_CHECKSIGFROMSTACK, OP_CHECKOUTPUTSHASHVERIFY, and OP_SECURETHEBAG. These discussions shed light on specific features and improvements being considered for Bitcoin Core. Additionally, the meeting also featured a detailed conversation about Taproot, exploring its potential impact on Bitcoin's privacy and scalability.Other topics covered in the meeting include Utreexo, assumeutxo, hardware wallets, and HWI (Hardware Wallet Interface). These discussions offer insights into the development of secure and efficient hardware solutions for Bitcoin storage and transactions. The notes also touch upon bip151, p2p encryption, and v2 message format, which are crucial components of Bitcoin's network communication protocols.The coredev.tech Amsterdam 2019 meeting also addressed the use of Signet for bitcoin test networks, providing an overview of its benefits and potential applications. Additionally, the notes discuss Statechains, presenting a comprehensive overview of this innovative approach to off-chain Bitcoin transfers.In summary, the links provided in the email thread offer detailed information on various aspects of Bitcoin Core development discussed during the coredev.tech Amsterdam 2019 meeting. These insights cover topics such as code review processes, maintainers' challenges, wallet re-architecture, consensus cleanup, specific technical features, scalability solutions, hardware wallets, network communication protocols, test networks, and off-chain transfers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_bitcoin-dev-Digest-Vol-49-Issue-8.xml b/static/bitcoin-dev/June_2019/combined_bitcoin-dev-Digest-Vol-49-Issue-8.xml index ccf101f158..4bed2fbe23 100644 --- a/static/bitcoin-dev/June_2019/combined_bitcoin-dev-Digest-Vol-49-Issue-8.xml +++ b/static/bitcoin-dev/June_2019/combined_bitcoin-dev-Digest-Vol-49-Issue-8.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-dev Digest, Vol 49, Issue 8 - 2023-08-02T01:00:08.787675+00:00 + 2025-09-26T16:04:13.758417+00:00 + python-feedgen Emil Engler 2019-06-09 18:56:47+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - bitcoin-dev Digest, Vol 49, Issue 8 - 2023-08-02T01:00:08.788676+00:00 + 2025-09-26T16:04:13.758570+00:00 - When utilizing the testnet, it is necessary to address resets. Although a more advantageous option exists, miners continue to rely on the testnet for testing new firmware versions, hardware prototypes, and operation services. The most recent reset occurred in 2011, preceded by two previous resets. As of now, the difficulty levels are expected to remain steady.The focal point of the discussion revolves around the decision of whether or not to reset the testnet, despite the existence of a potentially superior alternative. Miners still find value in using the testnet for testing purposes, including the evaluation of new firmware versions, hardware prototypes, and operation services. It is crucial to acknowledge that the difficulty levels will remain consistent in the foreseeable future. 2019-06-09T18:56:47+00:00 + When utilizing the testnet, it is necessary to address resets. Although a more advantageous option exists, miners continue to rely on the testnet for testing new firmware versions, hardware prototypes, and operation services. The most recent reset occurred in 2011, preceded by two previous resets. As of now, the difficulty levels are expected to remain steady.The focal point of the discussion revolves around the decision of whether or not to reset the testnet, despite the existence of a potentially superior alternative. Miners still find value in using the testnet for testing purposes, including the evaluation of new firmware versions, hardware prototypes, and operation services. It is crucial to acknowledge that the difficulty levels will remain consistent in the foreseeable future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2019/combined_testnet4.xml b/static/bitcoin-dev/June_2019/combined_testnet4.xml index 6454021fb3..2902d03a03 100644 --- a/static/bitcoin-dev/June_2019/combined_testnet4.xml +++ b/static/bitcoin-dev/June_2019/combined_testnet4.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - testnet4 - 2023-08-02T01:00:02.743526+00:00 - - Emil Engler 2019-06-17 11:41:08+00:00 - - - Peter Todd 2019-06-16 20:25:06+00:00 - - - Emil Engler 2019-06-08 15:01:50+00:00 - - - Bryan Bishop 2019-06-08 14:21:40+00:00 - - - Emil Engler 2019-06-07 23:49:16+00:00 - + 2025-09-26T16:04:15.847143+00:00 + python-feedgen + + + [bitcoin-dev] testnet4 Emil Engler + 2019-06-07T23:49:00.000Z + + + Bryan Bishop + 2019-06-08T14:21:00.000Z + + + Emil Engler + 2019-06-08T15:01:00.000Z + + + Peter Todd + 2019-06-16T20:25:00.000Z + + + Emil Engler + 2019-06-17T11:41:00.000Z + + - python-feedgen + 2 Combined summary - testnet4 - 2023-08-02T01:00:02.743526+00:00 + 2025-09-26T16:04:15.847909+00:00 - The use of a testnet blockchain is vital for developers to test new features and upgrades before implementing them on the mainnet. However, the testnet can be vulnerable to spam attacks after a reset until it reaches a certain size due to its lack of value. Peter Todd, a well-known Bitcoin expert, argues that the size of the testnet itself is an important test and has suggested in the past that it should be larger than the mainnet. While he prefers testing on internal regtest nodes or directly on the mainnet, he acknowledges that this may not be feasible for everyone.Recently, there was a discussion on the bitcoin-dev mailing list about whether or not to reset the testnet. One member questioned the need for a reset when there are better alternatives available. However, it was pointed out that the size of the testnet is an important factor to consider, and some argue that it should even be larger than the mainnet. Some developers may conduct their testing on internal regtest nodes or directly on the mainnet, but this approach may not be suitable for everyone. Peter Todd, who participated in the email thread, shared his personal thoughts on various Bitcoin-related topics on his website and provided his contact information through a signature file attached to the email.Emil Engler, another Bitcoin developer, has suggested resetting the testnet blockchain with a new genesis block due to its current size and the lengthy time it takes to sync. He experienced an hour-long sync for approximately 1.5 million blocks, with the blockchain size being around 26GB. However, Bryan Bishop, a Bitcoin Core developer, expressed doubts about the reset happening and recommended exploring Signet as an alternative for configuring separate private and public testing networks. He directed attention to a recent discussion on Signet, which can be found at http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/.In conclusion, Emil Engler proposed resetting the Bitcoin testnet with a new genesis block to address the lengthy synchronization time and large blockchain size. This suggestion aims to save time and resources for Bitcoin developers conducting tests and experiments on the network. Bryan Bishop highlighted Signet as an alternative for configuring different testing networks, providing a link to the relevant discussion transcript. 2019-06-17T11:41:08+00:00 + The use of a testnet blockchain is vital for developers to test new features and upgrades before implementing them on the mainnet. However, the testnet can be vulnerable to spam attacks after a reset until it reaches a certain size due to its lack of value. Peter Todd, a well-known Bitcoin expert, argues that the size of the testnet itself is an important test and has suggested in the past that it should be larger than the mainnet. While he prefers testing on internal regtest nodes or directly on the mainnet, he acknowledges that this may not be feasible for everyone.Recently, there was a discussion on the bitcoin-dev mailing list about whether or not to reset the testnet. One member questioned the need for a reset when there are better alternatives available. However, it was pointed out that the size of the testnet is an important factor to consider, and some argue that it should even be larger than the mainnet. Some developers may conduct their testing on internal regtest nodes or directly on the mainnet, but this approach may not be suitable for everyone. Peter Todd, who participated in the email thread, shared his personal thoughts on various Bitcoin-related topics on his website and provided his contact information through a signature file attached to the email.Emil Engler, another Bitcoin developer, has suggested resetting the testnet blockchain with a new genesis block due to its current size and the lengthy time it takes to sync. He experienced an hour-long sync for approximately 1.5 million blocks, with the blockchain size being around 26GB. However, Bryan Bishop, a Bitcoin Core developer, expressed doubts about the reset happening and recommended exploring Signet as an alternative for configuring separate private and public testing networks. He directed attention to a recent discussion on Signet, which can be found at http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/.In conclusion, Emil Engler proposed resetting the Bitcoin testnet with a new genesis block to address the lengthy synchronization time and large blockchain size. This suggestion aims to save time and resources for Bitcoin developers conducting tests and experiments on the network. Bryan Bishop highlighted Signet as an alternative for configuring different testing networks, providing a link to the relevant discussion transcript. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_-was-BIP-OP-CHECKTEMPLATEVERIFY-Fee-Bumping-Operation.xml b/static/bitcoin-dev/June_2020/combined_-was-BIP-OP-CHECKTEMPLATEVERIFY-Fee-Bumping-Operation.xml index 0e29cb4933..61315790e1 100644 --- a/static/bitcoin-dev/June_2020/combined_-was-BIP-OP-CHECKTEMPLATEVERIFY-Fee-Bumping-Operation.xml +++ b/static/bitcoin-dev/June_2020/combined_-was-BIP-OP-CHECKTEMPLATEVERIFY-Fee-Bumping-Operation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation - 2023-08-02T02:21:36.279244+00:00 + 2025-09-26T16:00:08.400838+00:00 + python-feedgen Dmitry Petukhov 2020-06-08 07:15:11+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation - 2023-08-02T02:21:36.279244+00:00 + 2025-09-26T16:00:08.400988+00:00 - A proposal was made on the bitcoin-dev mailing list to introduce a new type of transaction called PFN (Parent Fixing Nonce) that aims to fix stuck transactions by modifying their parent transactions. However, concerns were raised about the feasibility and complexity of implementing this proposal due to the requirement of a new index of all past transactions for consensus.In response to these concerns, another proposal was suggested for a Fee Bump transaction. This transaction would target a list of TXIDs or a single TXID representing all ancestors it wants to include in a block. The goal is to make it similar to normal transactions for inclusion, with potential minimums for mempool inclusion. However, there are still questions regarding whether the sender of a PFN transaction could Replace-By-Fee (RBF) it or increase the fee for its parent transactions without being able to replace any other transactions besides their own.To address application-DoS attacks in the mempool beyond CTV (CheckTemplateVerify), a potential solution is proposed: the "Pay for Neighbor" transaction. With this approach, a transaction can specify that it wants to pay the fee for another transaction(s). This creates a 'ghost child' transaction that can only be mined if its 'ghost parents' are confirmed as well. This method is essentially Child-Pays-for-Parent (CPFP) but ensures that the examined link is always one hop away, reducing CPFP graph traversal issues. However, the existing CPFP logic is not working as expected, and it may be necessary to remove CPFP entirely to make fee bumping work smoothly.A Fee Bump transaction can name a list of TXIDs or a single TXID that represents all ancestors it wishes to include in a block. It must be included in that block and should have no unconfirmed ancestors or children. Transactions in the mempool can set a flag to opt out of CPFP for descendants/blocks to prevent pinning. Channel protocols should use this feature to prevent pinning and then use the Fee Bump transaction to add fees to transactions that need to be processed.There is also a suggestion to use the annex or anyone-can-spend output for this purpose. If implemented correctly, a coinswap protocol could be layered with the fee-bumping transactions change, providing privacy benefits. Initially, this idea required a hardfork, but it could potentially be achieved as a soft fork past-taproot by including the txids of 'ghost parents' in the taproot annex. However, creating a new index of all past transactions for consensus would be problematic and cannot be done. 2020-06-08T07:15:11+00:00 + A proposal was made on the bitcoin-dev mailing list to introduce a new type of transaction called PFN (Parent Fixing Nonce) that aims to fix stuck transactions by modifying their parent transactions. However, concerns were raised about the feasibility and complexity of implementing this proposal due to the requirement of a new index of all past transactions for consensus.In response to these concerns, another proposal was suggested for a Fee Bump transaction. This transaction would target a list of TXIDs or a single TXID representing all ancestors it wants to include in a block. The goal is to make it similar to normal transactions for inclusion, with potential minimums for mempool inclusion. However, there are still questions regarding whether the sender of a PFN transaction could Replace-By-Fee (RBF) it or increase the fee for its parent transactions without being able to replace any other transactions besides their own.To address application-DoS attacks in the mempool beyond CTV (CheckTemplateVerify), a potential solution is proposed: the "Pay for Neighbor" transaction. With this approach, a transaction can specify that it wants to pay the fee for another transaction(s). This creates a 'ghost child' transaction that can only be mined if its 'ghost parents' are confirmed as well. This method is essentially Child-Pays-for-Parent (CPFP) but ensures that the examined link is always one hop away, reducing CPFP graph traversal issues. However, the existing CPFP logic is not working as expected, and it may be necessary to remove CPFP entirely to make fee bumping work smoothly.A Fee Bump transaction can name a list of TXIDs or a single TXID that represents all ancestors it wishes to include in a block. It must be included in that block and should have no unconfirmed ancestors or children. Transactions in the mempool can set a flag to opt out of CPFP for descendants/blocks to prevent pinning. Channel protocols should use this feature to prevent pinning and then use the Fee Bump transaction to add fees to transactions that need to be processed.There is also a suggestion to use the annex or anyone-can-spend output for this purpose. If implemented correctly, a coinswap protocol could be layered with the fee-bumping transactions change, providing privacy benefits. Initially, this idea required a hardfork, but it could potentially be achieved as a soft fork past-taproot by including the txids of 'ghost parents' in the taproot annex. However, creating a new index of all past transactions for consensus would be problematic and cannot be done. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Announcing-Bitcoin-Wallet-Tracker.xml b/static/bitcoin-dev/June_2020/combined_Announcing-Bitcoin-Wallet-Tracker.xml index 38ccd06ec6..a7147e19a6 100644 --- a/static/bitcoin-dev/June_2020/combined_Announcing-Bitcoin-Wallet-Tracker.xml +++ b/static/bitcoin-dev/June_2020/combined_Announcing-Bitcoin-Wallet-Tracker.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Announcing Bitcoin Wallet Tracker - 2023-08-02T02:20:06.234965+00:00 - - Nadav Ivgi 2020-06-01 08:10:50+00:00 - - - Nadav Ivgi 2020-05-30 14:16:14+00:00 - + 2025-09-26T16:00:06.252125+00:00 + python-feedgen + + + [bitcoin-dev] Announcing Bitcoin Wallet Tracker Nadav Ivgi + 2020-05-30T14:16:00.000Z + + + Nadav Ivgi + 2020-06-01T08:10:00.000Z + + - python-feedgen + 2 Combined summary - Announcing Bitcoin Wallet Tracker - 2023-08-02T02:20:06.234965+00:00 + 2025-09-26T16:00:06.252589+00:00 - Nadav Ivgi has released a new HD wallet indexer called bwt, which is similar to Electrum Personal Server but offers additional indexes on top of the bitcoind wallet functionality. This indexer is designed to track an xpub and automatically derive new addresses as needed, according to the gap limit. It provides real-time updates via Server-Sent Events or Web Hooks, unlike using bitcoind RPC directly. The aim of bwt is to minimize RPC requests to bitcoind. Support for output script descriptors is one major item on the roadmap for future development.Antoine compares esplora-electrs and bwt in terms of performance. Both APIs are designed by Nadav and have similarities. While esplora-electrs keeps a full index of everything, bwt only tracks wallet addresses. Therefore, if the user is only interested in wallet addresses and doesn't have a large number of them, bwt will perform better. However, if there are many addresses, esplora-electrs will be more suitable. Esplora provides comprehensive information about transactions and blocks, while bwt intentionally reduces this information to the subset useful for app development. Bwt provides wallet-contextual information, such as key origins next to addresses and the net change inflicted on the wallet's balance by transactions. Unlike Esplora, bwt provides real-time updates using two different mechanisms: SSE and Web Hooks.Bwt, implemented in Rust by Nadav, is an HD wallet indexer that utilizes the bitcoind wallet functionality to build additional indexes. These indexes can be queried using the Electrum RPC protocol or a developer-friendly HTTP REST API. The electrum server can also be used as an electrum plugin, integrating the server into the electrum client. The HTTP API is designed for wallet tracking and aimed at app developers, serving as a backend for wallets or deposit tracking for watch-only xpubs.In comparison to using bitcoind RPC directly, bwt offers several conveniences. It allows for tracking an xpub and automatically importing new addresses as needed. It provides real-time updates through Server-Sent Events or Web Hooks. The API offers simplifications and conveniences, along with an easy way to catch up with missed events. To minimize RPC requests, the indexer uses labels to store key origin information. It can index 10k incoming transactions in under a second or a mixture of 5k/5k in under 5 seconds. Although it requires an additional RPC call per outgoing transaction to determine spent prevouts, the index is currently stored entirely in-memory without persistence.Nadav has included useful developer resources and a script for setting up a development environment in the README. This early alpha release of bwt is recommended for use with testnet/regtest. 2020-06-01T08:10:50+00:00 + Nadav Ivgi has released a new HD wallet indexer called bwt, which is similar to Electrum Personal Server but offers additional indexes on top of the bitcoind wallet functionality. This indexer is designed to track an xpub and automatically derive new addresses as needed, according to the gap limit. It provides real-time updates via Server-Sent Events or Web Hooks, unlike using bitcoind RPC directly. The aim of bwt is to minimize RPC requests to bitcoind. Support for output script descriptors is one major item on the roadmap for future development.Antoine compares esplora-electrs and bwt in terms of performance. Both APIs are designed by Nadav and have similarities. While esplora-electrs keeps a full index of everything, bwt only tracks wallet addresses. Therefore, if the user is only interested in wallet addresses and doesn't have a large number of them, bwt will perform better. However, if there are many addresses, esplora-electrs will be more suitable. Esplora provides comprehensive information about transactions and blocks, while bwt intentionally reduces this information to the subset useful for app development. Bwt provides wallet-contextual information, such as key origins next to addresses and the net change inflicted on the wallet's balance by transactions. Unlike Esplora, bwt provides real-time updates using two different mechanisms: SSE and Web Hooks.Bwt, implemented in Rust by Nadav, is an HD wallet indexer that utilizes the bitcoind wallet functionality to build additional indexes. These indexes can be queried using the Electrum RPC protocol or a developer-friendly HTTP REST API. The electrum server can also be used as an electrum plugin, integrating the server into the electrum client. The HTTP API is designed for wallet tracking and aimed at app developers, serving as a backend for wallets or deposit tracking for watch-only xpubs.In comparison to using bitcoind RPC directly, bwt offers several conveniences. It allows for tracking an xpub and automatically importing new addresses as needed. It provides real-time updates through Server-Sent Events or Web Hooks. The API offers simplifications and conveniences, along with an easy way to catch up with missed events. To minimize RPC requests, the indexer uses labels to store key origin information. It can index 10k incoming transactions in under a second or a mixture of 5k/5k in under 5 seconds. Although it requires an additional RPC call per outgoing transaction to determine spent prevouts, the index is currently stored entirely in-memory without persistence.Nadav has included useful developer resources and a script for setting up a development environment in the README. This early alpha release of bwt is recommended for use with testnet/regtest. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml b/static/bitcoin-dev/June_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml index 94e1116eb0..ae412b596f 100644 --- a/static/bitcoin-dev/June_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml +++ b/static/bitcoin-dev/June_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml @@ -1,53 +1,55 @@ - + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.880650+00:00 - - Jeremy 2020-09-03 17:47:35+00:00 - - - Jeremy 2020-09-03 17:34:15+00:00 - - - Dmitry Petukhov 2020-09-03 14:42:23+00:00 - - - Dmitry Petukhov 2020-06-08 06:05:45+00:00 - - - Jeremy 2020-06-07 22:45:16+00:00 - - - Joachim Strömbergson 2020-06-07 16:51:10+00:00 - - - ZmnSCPxj 2020-02-15 00:24:37+00:00 - - - Jeremy 2020-02-14 19:16:26+00:00 - - - Dmitry Petukhov 2020-02-14 11:18:26+00:00 - - - Jeremy 2019-12-19 20:08:03+00:00 - - - Jeremy 2019-12-13 23:06:59+00:00 - - - Jeremy 2019-12-11 00:37:59+00:00 - - - Jeremy 2019-11-28 19:59:42+00:00 - - - Russell O'Connor 2019-11-27 21:32:51+00:00 - - - Jeremy 2019-11-26 01:50:40+00:00 - + 2025-09-26T15:59:49.182330+00:00 + python-feedgen + + + Dmitry Petukhov + 2020-02-14T11:18:00.000Z + + + Jeremy + 2020-02-14T19:16:00.000Z + + + ZmnSCPxj + 2020-02-15T00:24:00.000Z + + + Joachim Strömbergson + 2020-06-07T16:51:00.000Z + + + Jeremy + 2020-06-07T22:45:00.000Z + + + Dmitry Petukhov + 2020-06-08T06:05:00.000Z + + + [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation Jeremy + 2020-06-08T06:43:00.000Z + + + Dmitry Petukhov + 2020-06-08T07:15:00.000Z + + + Dmitry Petukhov + 2020-09-03T14:42:00.000Z + + + Jeremy + 2020-09-03T17:34:00.000Z + + + Jeremy + 2020-09-03T17:47:00.000Z + + @@ -63,13 +65,13 @@ - python-feedgen + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.881652+00:00 + 2025-09-26T15:59:49.183746+00:00 - In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast 2020-09-03T17:47:35+00:00 + In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Bitcoin-2-way-pegged-childchains-via-Proof-of-Burn.xml b/static/bitcoin-dev/June_2020/combined_Bitcoin-2-way-pegged-childchains-via-Proof-of-Burn.xml index c25af738d1..c963404e0b 100644 --- a/static/bitcoin-dev/June_2020/combined_Bitcoin-2-way-pegged-childchains-via-Proof-of-Burn.xml +++ b/static/bitcoin-dev/June_2020/combined_Bitcoin-2-way-pegged-childchains-via-Proof-of-Burn.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Bitcoin 2-way-pegged childchains via Proof of Burn - 2023-08-02T02:27:13.779783+00:00 - - ZmnSCPxj 2020-06-26 00:57:13+00:00 - - - Cloud Strife 2020-06-25 21:43:20+00:00 - + 2025-09-26T15:59:47.034701+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn Cloud Strife + 2020-06-25T21:43:00.000Z + + + ZmnSCPxj + 2020-06-26T00:57:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin 2-way-pegged childchains via Proof of Burn - 2023-08-02T02:27:13.779783+00:00 + 2025-09-26T15:59:47.035214+00:00 - In a forum post, CS has proposed a method to build childchains on top of Bitcoin without requiring any changes to the Bitcoin network or user and miner awareness. The childchain would be designed to be Bitcoin-aware and replicate the properties of Proof of Work by necessitating continuous burning of Bitcoin in exchange for fees on the childchain.The security of the childchain and the accuracy of the 2-way-peg could potentially make it a suitable option for lower-value transactions, with the scale being determined by the rate at which Bitcoin is burned. This approach would eliminate the need for additional Proof of Work chains for new blockchains.A detailed write-up of the proposal can be found on bitcointalk.org. However, ZmnSCPxj, in another forum post, critiques the concept of sidechains as a scaling solution for cryptocurrencies. He argues that blockchains do not scale effectively, and instead proposes the Lightning Network as a superior alternative for scalability.The Lightning Network utilizes channels to facilitate scaling, with each channel representing a consensus system between two participants. Atomic swaps are employed to transfer assets between channels and the blockchain. The construction of these channels requires reference to an ultimate arbiter in case of disputes or non-consensus, which is provided by the underlying blockchain layer. Therefore, the blockchain serves as an arbitration mechanism while the channels handle scaling.Returning to the proposal, it aims to construct childchains on top of Bitcoin without requiring any modifications to the Bitcoin network itself. The childchain would be Bitcoin-aware and simulate Proof of Work by mandating the continuous burning of Bitcoin in exchange for fees on the childchain.The selection of the childchain tip is based on the highest total accumulated Bitcoin burnt for the full chained set of childchain block commits, with the objective of emulating total accumulated work. The only asset on the childchain would be a 2-way-peg coin that maintains its value without the need for oracles or collateral. Each valid childchain block must use a small percentage of the burnt amount to deterministically reimburse withdrawals from the childchain.Users have the ability to burn child-BTC and join the withdrawal queue, which is filled as part of the validity requirements by childchain "miners" until it is filled at a 1:1 ratio on the mainchain or more. Similarly, users can burn BTC independently of mining the childchain and receive an equivalent amount of 1:1 child-BTC on the childchain.While childchains may not be as secure as the mainchain, both the security of the childchain and the accuracy of the 2-way-peg could still be acceptable for lower-value transactions, depending on the burning rate. Childchains have the potential to eliminate the need for additional Proof of Work chains for new blockchains, avoiding added complexity while leveraging the Proof of Work performed on Bitcoin as a proxy for unforgeable costliness. Furthermore, childchains benefit from Bitcoin's censorship resistance and data availability.A large volume of low-value transactions that might be too expensive to conduct on the main chain could potentially generate enough fees through childchain miners to afford higher mainchain fees, similar to the concept of "batching for fees". Additionally, the proposal claims to offer the benefits associated with proof of stake systems, such as energy efficiency, without relying on internal permissions or tokens, trusted distributions, or centralizing mechanisms like staking, by simulating proof of work.The proposed approach aims to foster the growth of the Bitcoin ecosystem and replace the need to create alternative cryptocurrencies solely for the purpose of launching a new blockchain. The detailed proposal can be found at https://bitcointalk.org/index.php?topic=5214173.0, where the author is seeking feedback on any overlooked issues or interest in creating a proof of concept. 2020-06-26T00:57:13+00:00 + In a forum post, CS has proposed a method to build childchains on top of Bitcoin without requiring any changes to the Bitcoin network or user and miner awareness. The childchain would be designed to be Bitcoin-aware and replicate the properties of Proof of Work by necessitating continuous burning of Bitcoin in exchange for fees on the childchain.The security of the childchain and the accuracy of the 2-way-peg could potentially make it a suitable option for lower-value transactions, with the scale being determined by the rate at which Bitcoin is burned. This approach would eliminate the need for additional Proof of Work chains for new blockchains.A detailed write-up of the proposal can be found on bitcointalk.org. However, ZmnSCPxj, in another forum post, critiques the concept of sidechains as a scaling solution for cryptocurrencies. He argues that blockchains do not scale effectively, and instead proposes the Lightning Network as a superior alternative for scalability.The Lightning Network utilizes channels to facilitate scaling, with each channel representing a consensus system between two participants. Atomic swaps are employed to transfer assets between channels and the blockchain. The construction of these channels requires reference to an ultimate arbiter in case of disputes or non-consensus, which is provided by the underlying blockchain layer. Therefore, the blockchain serves as an arbitration mechanism while the channels handle scaling.Returning to the proposal, it aims to construct childchains on top of Bitcoin without requiring any modifications to the Bitcoin network itself. The childchain would be Bitcoin-aware and simulate Proof of Work by mandating the continuous burning of Bitcoin in exchange for fees on the childchain.The selection of the childchain tip is based on the highest total accumulated Bitcoin burnt for the full chained set of childchain block commits, with the objective of emulating total accumulated work. The only asset on the childchain would be a 2-way-peg coin that maintains its value without the need for oracles or collateral. Each valid childchain block must use a small percentage of the burnt amount to deterministically reimburse withdrawals from the childchain.Users have the ability to burn child-BTC and join the withdrawal queue, which is filled as part of the validity requirements by childchain "miners" until it is filled at a 1:1 ratio on the mainchain or more. Similarly, users can burn BTC independently of mining the childchain and receive an equivalent amount of 1:1 child-BTC on the childchain.While childchains may not be as secure as the mainchain, both the security of the childchain and the accuracy of the 2-way-peg could still be acceptable for lower-value transactions, depending on the burning rate. Childchains have the potential to eliminate the need for additional Proof of Work chains for new blockchains, avoiding added complexity while leveraging the Proof of Work performed on Bitcoin as a proxy for unforgeable costliness. Furthermore, childchains benefit from Bitcoin's censorship resistance and data availability.A large volume of low-value transactions that might be too expensive to conduct on the main chain could potentially generate enough fees through childchain miners to afford higher mainchain fees, similar to the concept of "batching for fees". Additionally, the proposal claims to offer the benefits associated with proof of stake systems, such as energy efficiency, without relying on internal permissions or tokens, trusted distributions, or centralizing mechanisms like staking, by simulating proof of work.The proposed approach aims to foster the growth of the Bitcoin ecosystem and replace the need to create alternative cryptocurrencies solely for the purpose of launching a new blockchain. The detailed proposal can be found at https://bitcointalk.org/index.php?topic=5214173.0, where the author is seeking feedback on any overlooked issues or interest in creating a proof of concept. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Blind-Statechains.xml b/static/bitcoin-dev/June_2020/combined_Blind-Statechains.xml index 1e86df97c5..53ef5467a4 100644 --- a/static/bitcoin-dev/June_2020/combined_Blind-Statechains.xml +++ b/static/bitcoin-dev/June_2020/combined_Blind-Statechains.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Blind Statechains - 2023-08-02T02:23:57.162610+00:00 - - Tom Trevethan 2020-06-14 22:24:47+00:00 - - - Ruben Somsen 2020-06-12 20:35:37+00:00 - - - Tom Trevethan 2020-06-12 18:11:52+00:00 - + 2025-09-26T15:59:59.841613+00:00 + python-feedgen + + + [bitcoin-dev] Blind Statechains Tom Trevethan + 2020-06-12T18:11:00.000Z + + + Ruben Somsen + 2020-06-12T20:35:00.000Z + + + Tom Trevethan + 2020-06-14T22:24:00.000Z + + - python-feedgen + 2 Combined summary - Blind Statechains - 2023-08-02T02:23:57.162610+00:00 + 2025-09-26T15:59:59.842271+00:00 - The email exchange discusses the implementation of blind signatures in a statechain, which can provide significant privacy benefits. The statechain entity (SE) can be designed to be blind to the transactions it signs, but this means it cannot enforce the rules governing the sequence of backup transactions it co-signs. This issue is particularly relevant in the case of multisig and Schnorr signatures.To address this, existing blind Schnorr protocols could be used to implement a blind SE. However, the team is considering using a two-party Elliptic Curve Digital Signature Algorithm (ECDSA) instead, as there is currently no Schnorr protocol available. Minor modifications to an existing 2P ECDSA scheme may enable one of the signers to be completely blinded.One challenge discussed in the email thread is the need for new owners of a UTXO to validate the history of the chain and verify the uniqueness of the previous owner's ownership. Each new owner must receive, store, and verify the full sequence of backup transactions from the previous owner to prevent theft. This process could potentially lead to bloated and clunky wallets, especially considering that ownership of a UTXO could change hands multiple times off-chain.The email also suggests introducing a secondary "blinding key" to achieve the desired functionality without making changes to the transitory key at each step. Additionally, the email raises the concern that pruning will be impossible if the status of a statechain being pegged out is unknown.Overall, the discussion revolves around the implementation of blind signatures in statechains, the challenges related to enforcing transaction sequence rules, the potential use of blind Schnorr protocols or 2P ECDSA, the need for new owners to validate the chain's history, and the suggestion of a secondary blinding key. Feedback on these matters is welcomed. 2020-06-14T22:24:47+00:00 + The email exchange discusses the implementation of blind signatures in a statechain, which can provide significant privacy benefits. The statechain entity (SE) can be designed to be blind to the transactions it signs, but this means it cannot enforce the rules governing the sequence of backup transactions it co-signs. This issue is particularly relevant in the case of multisig and Schnorr signatures.To address this, existing blind Schnorr protocols could be used to implement a blind SE. However, the team is considering using a two-party Elliptic Curve Digital Signature Algorithm (ECDSA) instead, as there is currently no Schnorr protocol available. Minor modifications to an existing 2P ECDSA scheme may enable one of the signers to be completely blinded.One challenge discussed in the email thread is the need for new owners of a UTXO to validate the history of the chain and verify the uniqueness of the previous owner's ownership. Each new owner must receive, store, and verify the full sequence of backup transactions from the previous owner to prevent theft. This process could potentially lead to bloated and clunky wallets, especially considering that ownership of a UTXO could change hands multiple times off-chain.The email also suggests introducing a secondary "blinding key" to achieve the desired functionality without making changes to the transitory key at each step. Additionally, the email raises the concern that pruning will be impossible if the status of a statechain being pegged out is unknown.Overall, the discussion revolves around the implementation of blind signatures in statechains, the challenges related to enforcing transaction sequence rules, the potential use of blind Schnorr protocols or 2P ECDSA, the need for new owners to validate the chain's history, and the suggestion of a secondary blinding key. Feedback on these matters is welcomed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_CoinPool-exploring-generic-payment-pools-for-Fun-and-Privacy.xml b/static/bitcoin-dev/June_2020/combined_CoinPool-exploring-generic-payment-pools-for-Fun-and-Privacy.xml index 551c191110..e52ceb6a8e 100644 --- a/static/bitcoin-dev/June_2020/combined_CoinPool-exploring-generic-payment-pools-for-Fun-and-Privacy.xml +++ b/static/bitcoin-dev/June_2020/combined_CoinPool-exploring-generic-payment-pools-for-Fun-and-Privacy.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - CoinPool, exploring generic payment pools for Fun and Privacy - 2023-08-02T02:22:46.793336+00:00 - - ZmnSCPxj 2020-06-16 05:23:01+00:00 - - - ZmnSCPxj 2020-06-13 01:20:16+00:00 - - - ZmnSCPxj 2020-06-13 00:45:12+00:00 - - - Antoine Riard 2020-06-13 00:28:27+00:00 - - - Antoine Riard 2020-06-12 23:45:35+00:00 - - - ZmnSCPxj 2020-06-12 08:39:35+00:00 - - - Jeremy 2020-06-11 17:21:08+00:00 - - - Antoine Riard 2020-06-11 08:53:08+00:00 - + 2025-09-26T16:00:12.665516+00:00 + python-feedgen + + + [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy Antoine Riard + 2020-06-11T08:53:00.000Z + + + Jeremy + 2020-06-11T17:21:00.000Z + + + ZmnSCPxj + 2020-06-12T08:39:00.000Z + + + Antoine Riard + 2020-06-12T23:45:00.000Z + + + Antoine Riard + 2020-06-13T00:28:00.000Z + + + ZmnSCPxj + 2020-06-13T00:45:00.000Z + + + ZmnSCPxj + 2020-06-13T01:20:00.000Z + + + ZmnSCPxj + 2020-06-16T05:23:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - CoinPool, exploring generic payment pools for Fun and Privacy - 2023-08-02T02:22:46.793336+00:00 + 2025-09-26T16:00:12.666599+00:00 - ZmnSCPxj's message discusses various ideas related to CoinPool, multiparticipant channels, channel factories, and nodelets. The CoinPool idea allows for better flexibility in forwarding, while channel factories ensure that channels remain usable for forwarding even if one participant goes offline. The use of "virtual nodes" in CoinPool helps pathfinding algorithms work seamlessly, without realizing that these nodes represent the CoinPool.The email also explores the use of WabiSabi and Taproot in a CoinPool to enable interoperation with Lightning Network. This allows for the instantiation of HTLCs (or PTLCs) inside a CoinPool "alias" pubkey identity. If a timelock expires, the other party can request a partial signature to recover the HTLC value. If the signature share is not provided, the CoinPool is dropped onchain, instantiating the HTLC Taproot output onchain.WabiSabi is also discussed as a means to improve anonymity in CoinJoin transactions by allowing participants to pretend to be multiple people. This creates ambiguity and reduces the possibility of tracing leaves by value weight or identifying sockpuppets. The feature of equal-value leaves may come with a higher onchain cost in case of pool breakage.The CoinPool proposal involves a multiparticipant offchain update mechanism, where participants must sign off on the new state. The WabiSabi protocol can be used during the negotiation of a new state, allowing participants to perform value transfers inside the WabiSabi construction. To maintain privacy, participants can move coins randomly across two coins they own at each state update.Antoine and Jeremy have been working on payment pool designs for the Lightning Network. Antoine discussed the use of OP_CTV, while Jeremy proposed a new type of payment pool called "CheckTemplateVerify (CTV) Pools." CTV pools aim to improve efficiency and security by using radix trees and allowing non-interactive any-order withdrawal. They discuss trade-offs between security and performance and the need for better definitions of non-interactivity and privacy optimization.Gleb Naumenko and a collaborator are studying privacy issues in second-layer protocols like Lightning Network. They propose CoinPool as a solution to address privacy leaks and protocol-specific metadata. CoinPool is a low-latency, offchain protocol that can improve on-chain privacy without requiring timelocking coins or extensive use of on-chain space.The email also mentions challenges in deploying CoinPools, such as scalability and the need for new on-chain primitives. However, CoinPool offers scalability benefits by reducing the UTXO set size and batching activities from different users. It provides privacy by breaking payment sender/receiver linkability and keeping internal transfers private. The proposal acknowledges the work of others in the privacy community, such as Greg Maxwell and Dave Harding, who suggested payment pools.Overall, the email discusses various ideas related to CoinPool, WabiSabi, Taproot, and payment pool designs for the Lightning Network. These ideas aim to enhance flexibility, privacy, and efficiency in off-chain transactions while addressing privacy leaks and scalability challenges. 2020-06-16T05:23:01+00:00 + ZmnSCPxj's message discusses various ideas related to CoinPool, multiparticipant channels, channel factories, and nodelets. The CoinPool idea allows for better flexibility in forwarding, while channel factories ensure that channels remain usable for forwarding even if one participant goes offline. The use of "virtual nodes" in CoinPool helps pathfinding algorithms work seamlessly, without realizing that these nodes represent the CoinPool.The email also explores the use of WabiSabi and Taproot in a CoinPool to enable interoperation with Lightning Network. This allows for the instantiation of HTLCs (or PTLCs) inside a CoinPool "alias" pubkey identity. If a timelock expires, the other party can request a partial signature to recover the HTLC value. If the signature share is not provided, the CoinPool is dropped onchain, instantiating the HTLC Taproot output onchain.WabiSabi is also discussed as a means to improve anonymity in CoinJoin transactions by allowing participants to pretend to be multiple people. This creates ambiguity and reduces the possibility of tracing leaves by value weight or identifying sockpuppets. The feature of equal-value leaves may come with a higher onchain cost in case of pool breakage.The CoinPool proposal involves a multiparticipant offchain update mechanism, where participants must sign off on the new state. The WabiSabi protocol can be used during the negotiation of a new state, allowing participants to perform value transfers inside the WabiSabi construction. To maintain privacy, participants can move coins randomly across two coins they own at each state update.Antoine and Jeremy have been working on payment pool designs for the Lightning Network. Antoine discussed the use of OP_CTV, while Jeremy proposed a new type of payment pool called "CheckTemplateVerify (CTV) Pools." CTV pools aim to improve efficiency and security by using radix trees and allowing non-interactive any-order withdrawal. They discuss trade-offs between security and performance and the need for better definitions of non-interactivity and privacy optimization.Gleb Naumenko and a collaborator are studying privacy issues in second-layer protocols like Lightning Network. They propose CoinPool as a solution to address privacy leaks and protocol-specific metadata. CoinPool is a low-latency, offchain protocol that can improve on-chain privacy without requiring timelocking coins or extensive use of on-chain space.The email also mentions challenges in deploying CoinPools, such as scalability and the need for new on-chain primitives. However, CoinPool offers scalability benefits by reducing the UTXO set size and batching activities from different users. It provides privacy by breaking payment sender/receiver linkability and keeping internal transfers private. The proposal acknowledges the work of others in the privacy community, such as Greg Maxwell and Dave Harding, who suggested payment pools.Overall, the email discusses various ideas related to CoinPool, WabiSabi, Taproot, and payment pool designs for the Lightning Network. These ideas aim to enhance flexibility, privacy, and efficiency in off-chain transactions while addressing privacy leaks and scalability challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Design-for-a-CoinSwap-implementation-for-massively-improving-Bitcoin-privacy-and-fungibility.xml b/static/bitcoin-dev/June_2020/combined_Design-for-a-CoinSwap-implementation-for-massively-improving-Bitcoin-privacy-and-fungibility.xml index 6826817b06..edffd4e958 100644 --- a/static/bitcoin-dev/June_2020/combined_Design-for-a-CoinSwap-implementation-for-massively-improving-Bitcoin-privacy-and-fungibility.xml +++ b/static/bitcoin-dev/June_2020/combined_Design-for-a-CoinSwap-implementation-for-massively-improving-Bitcoin-privacy-and-fungibility.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility - 2023-08-02T02:18:36.479718+00:00 - - Jonas Nick 2020-06-19 15:33:09+00:00 - - - Chris Belcher 2020-06-10 11:19:53+00:00 - - - Chris Belcher 2020-06-10 11:15:03+00:00 - - - ZmnSCPxj 2020-06-10 10:58:03+00:00 - - - Chris Belcher 2020-06-10 10:15:36+00:00 - - - ZmnSCPxj 2020-06-10 07:09:04+00:00 - - - Mr. Lee Chiffre 2020-06-10 00:46:41+00:00 - - - Mr. Lee Chiffre 2020-06-10 00:43:40+00:00 - - - ZmnSCPxj 2020-06-06 04:25:11+00:00 - - - ZmnSCPxj 2020-06-06 03:59:30+00:00 - - - ZmnSCPxj 2020-06-06 01:40:18+00:00 - - - Chris Belcher 2020-06-05 22:39:47+00:00 - - - ZmnSCPxj 2020-06-04 16:37:53+00:00 - - - ZmnSCPxj 2020-06-03 14:50:01+00:00 - - - ZmnSCPxj 2020-06-03 04:53:52+00:00 - - - Chris Belcher 2020-06-02 22:24:19+00:00 - - - Ruben Somsen 2020-06-01 10:19:38+00:00 - - - ZmnSCPxj 2020-06-01 02:34:03+00:00 - - - Ruben Somsen 2020-05-31 21:19:22+00:00 - - - ZmnSCPxj 2020-05-31 02:30:55+00:00 - - - Ruben Somsen 2020-05-30 16:00:05+00:00 - - - Chris Belcher 2020-05-25 13:21:21+00:00 - + 2025-09-26T15:59:51.373132+00:00 + python-feedgen + + + [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility Chris Belcher + 2020-05-25T13:21:00.000Z + + + Ruben Somsen + 2020-05-30T16:00:00.000Z + + + ZmnSCPxj + 2020-05-31T02:30:00.000Z + + + Ruben Somsen + 2020-05-31T21:19:00.000Z + + + ZmnSCPxj + 2020-06-01T02:34:00.000Z + + + Ruben Somsen + 2020-06-01T10:19:00.000Z + + + Chris Belcher + 2020-06-02T22:24:00.000Z + + + ZmnSCPxj + 2020-06-03T04:53:00.000Z + + + ZmnSCPxj + 2020-06-03T14:50:00.000Z + + + ZmnSCPxj + 2020-06-04T16:37:00.000Z + + + Chris Belcher + 2020-06-05T22:39:00.000Z + + + ZmnSCPxj + 2020-06-06T01:40:00.000Z + + + ZmnSCPxj + 2020-06-06T03:59:00.000Z + + + ZmnSCPxj + 2020-06-06T04:25:00.000Z + + + Mr. Lee Chiffre + 2020-06-10T00:43:00.000Z + + + Mr. Lee Chiffre + 2020-06-10T00:46:00.000Z + + + ZmnSCPxj + 2020-06-10T07:09:00.000Z + + + Chris Belcher + 2020-06-10T10:15:00.000Z + + + ZmnSCPxj + 2020-06-10T10:58:00.000Z + + + Chris Belcher + 2020-06-10T11:15:00.000Z + + + Chris Belcher + 2020-06-10T11:19:00.000Z + + + Jonas Nick + 2020-06-19T15:33:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility - 2023-08-02T02:18:36.480718+00:00 + 2025-09-26T15:59:51.375616+00:00 - In a recent email conversation, Chris and ZmnSCPxj discuss the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. This scheme suggests that users can CoinSwap as soon as they receive funds, making sending payments as fast as non-CoinSwap on-chain wallets. It requires the user to maintain two internal wallets, a pre-mix wallet, and a post-mix wallet. Unspent funds in the pre-mix wallet are automatically swapped into the post-mix wallet, and when sending funds, coins from the post-mix wallet are spent directly to the payee address. Change outputs go to a new swap immediately instead of going back to the pre-mix or post-mix wallets.The scalability and privacy concerns of Bitcoin are raised in an email exchange between Lee Chiffre and Chris Belcher. Chris explains that his proposed CoinSwap system doesn't break pruning or other resource-saving features, making Bitcoin-with-CoinSwap more scalable than Monero. He also highlights how CoinSwap improves privacy by moving information off-chain, similar to Lightning Network. Chris suggests that even if only 5% of transactions were CoinSwaps, it would significantly improve users' privacy. He demonstrates how CoinSwaps can be used as payment and emphasizes that they are cheaper than Equal-Output CoinJoins. Chris concludes by noting that most day-to-day Bitcoin transactions are expected to happen off-chain using technologies like Lightning Network, which also enhances privacy.The email conversation also discusses the implementation of a new CoinSwap protocol. The protocol is split into phases: channel establishment, HTLC forwarding, HTLC resolution, and private key handover. The Spilman channel is used to create temporary unidirectional time-bound channels for simultaneous funding transactions without the risk of race loss. Bob has to wait for the incoming contract transaction before signing its outgoing contract transaction. The proposed alternative, swap-on-receive+swap-on-change, may not be suitable for every use case, but it is useful for day-to-day Bitcoin transactions.The concern over scalability and privacy in Bitcoin is discussed in a message from Lee Chiffre to Chris. Both Bitcoin and Monero face challenges related to large transaction sizes required for acceptable privacy. The proposed CoinSwap system aims to address these issues by enabling trustless coin swaps that are not linkable to the public blockchain. However, combining multi-transaction with routing may create scalability problems due to multiple branches and layers.In another message, ZmnSCPxj suggests using swap-on-pay or swap-on-receive+swap-on-change approaches for CoinSwap transactions. Swap-on-pay involves swapping funds before sending them to payees to prevent correlation between sends and receives. Swap-on-receive+swap-on-change involves maintaining two internal wallets, pre-mix, and post-mix wallets, to facilitate faster payments. It is noted that the swap-on-receive+swap-on-change approach may not be suitable for users who prioritize privacy and censorship resistance.The email exchange between Chris and ZmnSCPxj explores the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. The conversation also addresses scalability and privacy concerns in Bitcoin and discusses the implementation of a new CoinSwap protocol. The benefits of combining routing and multi-transaction techniques are examined, and various approaches for CoinSwap transactions are proposed.In a conversation about the CoinSwap protocol, it was noted that the order of funding transactions in a chained/routed swap could be used to derive the order of swaps, posing a security risk. To mitigate this, it is advisable for CoinSwap peers to wait for the counterparty's funding transaction to confirm before broadcasting their own. Additionally, the use of `nLockTime`-protected Backouts can allow unilateral recovery of funds if a funding transaction fails to confirm.The email discusses improvements to the CoinSwap protocol, including the use of `nLockTime`-protected Backouts and the creation of Spilman unidirectional payment channels to bring off-chain timing details out of sight. However, these approaches still have vulnerabilities that need to be addressed to prevent loss of control over coins.Security in cryptocurrency transactions is crucial, and waiting for funding transactions to confirm is recommended to avoid theft. Similar to Lightning Network, where contracts cannot be cancelled by publishing older states, the confirmation of the funding transaction in CoinSwap ensures that previous states cannot be validly spent. This highlights the importance of caution and patience when dealing with cryptocurrency transactions.The discussion between Chris and Ruben revolves around PayJoin-with-CoinSwap, which breaks the common-input-ownership heuristic and improves privacy. It can be useful for individuals recovering degraded privacy or spending from reused or linked addresses. However, there are downsides such as potential spying and the need for makers to reveal additional UTXOs. Using decoy UTXOs instead of PoDLE is suggested to resist attacks. Furthermore, the order of funding transactions for chained/routed swaps may 2020-06-19T15:33:09+00:00 + In a recent email conversation, Chris and ZmnSCPxj discuss the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. This scheme suggests that users can CoinSwap as soon as they receive funds, making sending payments as fast as non-CoinSwap on-chain wallets. It requires the user to maintain two internal wallets, a pre-mix wallet, and a post-mix wallet. Unspent funds in the pre-mix wallet are automatically swapped into the post-mix wallet, and when sending funds, coins from the post-mix wallet are spent directly to the payee address. Change outputs go to a new swap immediately instead of going back to the pre-mix or post-mix wallets.The scalability and privacy concerns of Bitcoin are raised in an email exchange between Lee Chiffre and Chris Belcher. Chris explains that his proposed CoinSwap system doesn't break pruning or other resource-saving features, making Bitcoin-with-CoinSwap more scalable than Monero. He also highlights how CoinSwap improves privacy by moving information off-chain, similar to Lightning Network. Chris suggests that even if only 5% of transactions were CoinSwaps, it would significantly improve users' privacy. He demonstrates how CoinSwaps can be used as payment and emphasizes that they are cheaper than Equal-Output CoinJoins. Chris concludes by noting that most day-to-day Bitcoin transactions are expected to happen off-chain using technologies like Lightning Network, which also enhances privacy.The email conversation also discusses the implementation of a new CoinSwap protocol. The protocol is split into phases: channel establishment, HTLC forwarding, HTLC resolution, and private key handover. The Spilman channel is used to create temporary unidirectional time-bound channels for simultaneous funding transactions without the risk of race loss. Bob has to wait for the incoming contract transaction before signing its outgoing contract transaction. The proposed alternative, swap-on-receive+swap-on-change, may not be suitable for every use case, but it is useful for day-to-day Bitcoin transactions.The concern over scalability and privacy in Bitcoin is discussed in a message from Lee Chiffre to Chris. Both Bitcoin and Monero face challenges related to large transaction sizes required for acceptable privacy. The proposed CoinSwap system aims to address these issues by enabling trustless coin swaps that are not linkable to the public blockchain. However, combining multi-transaction with routing may create scalability problems due to multiple branches and layers.In another message, ZmnSCPxj suggests using swap-on-pay or swap-on-receive+swap-on-change approaches for CoinSwap transactions. Swap-on-pay involves swapping funds before sending them to payees to prevent correlation between sends and receives. Swap-on-receive+swap-on-change involves maintaining two internal wallets, pre-mix, and post-mix wallets, to facilitate faster payments. It is noted that the swap-on-receive+swap-on-change approach may not be suitable for users who prioritize privacy and censorship resistance.The email exchange between Chris and ZmnSCPxj explores the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. The conversation also addresses scalability and privacy concerns in Bitcoin and discusses the implementation of a new CoinSwap protocol. The benefits of combining routing and multi-transaction techniques are examined, and various approaches for CoinSwap transactions are proposed.In a conversation about the CoinSwap protocol, it was noted that the order of funding transactions in a chained/routed swap could be used to derive the order of swaps, posing a security risk. To mitigate this, it is advisable for CoinSwap peers to wait for the counterparty's funding transaction to confirm before broadcasting their own. Additionally, the use of `nLockTime`-protected Backouts can allow unilateral recovery of funds if a funding transaction fails to confirm.The email discusses improvements to the CoinSwap protocol, including the use of `nLockTime`-protected Backouts and the creation of Spilman unidirectional payment channels to bring off-chain timing details out of sight. However, these approaches still have vulnerabilities that need to be addressed to prevent loss of control over coins.Security in cryptocurrency transactions is crucial, and waiting for funding transactions to confirm is recommended to avoid theft. Similar to Lightning Network, where contracts cannot be cancelled by publishing older states, the confirmation of the funding transaction in CoinSwap ensures that previous states cannot be validly spent. This highlights the importance of caution and patience when dealing with cryptocurrency transactions.The discussion between Chris and Ruben revolves around PayJoin-with-CoinSwap, which breaks the common-input-ownership heuristic and improves privacy. It can be useful for individuals recovering degraded privacy or spending from reused or linked addresses. However, there are downsides such as potential spying and the need for makers to reveal additional UTXOs. Using decoy UTXOs instead of PoDLE is suggested to resist attacks. Furthermore, the order of funding transactions for chained/routed swaps may - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Hash-based-accumulators-with-quick-insertion.xml b/static/bitcoin-dev/June_2020/combined_Hash-based-accumulators-with-quick-insertion.xml index d9b7ad6487..dc25c6f70e 100644 --- a/static/bitcoin-dev/June_2020/combined_Hash-based-accumulators-with-quick-insertion.xml +++ b/static/bitcoin-dev/June_2020/combined_Hash-based-accumulators-with-quick-insertion.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hash-based accumulators with quick insertion - 2023-08-02T02:21:51.434361+00:00 + 2025-09-26T16:00:23.323045+00:00 + python-feedgen German Luna 2020-06-08 22:01:09+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Hash-based accumulators with quick insertion - 2023-08-02T02:21:51.434361+00:00 + 2025-09-26T16:00:23.323189+00:00 - A mathematician named Germán expressed interest in a piece of work and suggested a method to indirectly support addition and removal by formulating it as a difference of sets, similar to collision-resistant replicated data types (CRDTs). This suggestion involves checking for membership through CheckMembershipInAdditionSet && !CheckMembershipInRemovalSet. Germán also mentioned the possibility of supporting multiple addition/removal by attaching a count of how many times an item has been added, but this may disrupt some aspects of the paper.The author has been focusing on cryptographic accumulators that optimize for quick insertion. Accumulators are data structures that maintain compact commitments to a potentially large set while keeping proofs of membership short. The author's focus is on additive accumulators that support adding new elements but not removing them. The motivation behind this is to enable Script to access an arbitrarily large portion of the blockchain history and state. The author has developed two constructions: 1. An accumulator with insertion time O(1) and proof size O(log^2 n).2. A construction with insertion time O(log log n) and proof size O(log n log log n).The draft writeup and sample python code for these constructions are available on Github. Although the ideas presented in the draft are still unfinished, they are clear and easy to understand. The author is sharing the work at this stage to receive feedback for improving the constructions, covering related work, and exploring potential applications in Bitcoin. One notable application in Bitcoin is the creation of lightweight full nodes that do not require storing the UTXO set, known as the Utreexo accumulator.Overall, the mathematician's comment sparked interest in the work, and the author has been working on cryptographic accumulators that optimize for quick insertion. The author has developed two constructions and is seeking feedback to enhance the constructions, explore related work, and uncover potential applications in Bitcoin, such as lightweight full nodes using the Utreexo accumulator. The draft writeup and sample python code are available on Github for further examination. 2020-06-08T22:01:09+00:00 + A mathematician named Germán expressed interest in a piece of work and suggested a method to indirectly support addition and removal by formulating it as a difference of sets, similar to collision-resistant replicated data types (CRDTs). This suggestion involves checking for membership through CheckMembershipInAdditionSet && !CheckMembershipInRemovalSet. Germán also mentioned the possibility of supporting multiple addition/removal by attaching a count of how many times an item has been added, but this may disrupt some aspects of the paper.The author has been focusing on cryptographic accumulators that optimize for quick insertion. Accumulators are data structures that maintain compact commitments to a potentially large set while keeping proofs of membership short. The author's focus is on additive accumulators that support adding new elements but not removing them. The motivation behind this is to enable Script to access an arbitrarily large portion of the blockchain history and state. The author has developed two constructions: 1. An accumulator with insertion time O(1) and proof size O(log^2 n).2. A construction with insertion time O(log log n) and proof size O(log n log log n).The draft writeup and sample python code for these constructions are available on Github. Although the ideas presented in the draft are still unfinished, they are clear and easy to understand. The author is sharing the work at this stage to receive feedback for improving the constructions, covering related work, and exploring potential applications in Bitcoin. One notable application in Bitcoin is the creation of lightweight full nodes that do not require storing the UTXO set, known as the Utreexo accumulator.Overall, the mathematician's comment sparked interest in the work, and the author has been working on cryptographic accumulators that optimize for quick insertion. The author has developed two constructions and is seeking feedback to enhance the constructions, explore related work, and uncover potential applications in Bitcoin, such as lightweight full nodes using the Utreexo accumulator. The draft writeup and sample python code are available on Github for further examination. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Hiding-CoinSwap-Makers-Among-Custodial-Services.xml b/static/bitcoin-dev/June_2020/combined_Hiding-CoinSwap-Makers-Among-Custodial-Services.xml index d4105372ea..c7b4106cfb 100644 --- a/static/bitcoin-dev/June_2020/combined_Hiding-CoinSwap-Makers-Among-Custodial-Services.xml +++ b/static/bitcoin-dev/June_2020/combined_Hiding-CoinSwap-Makers-Among-Custodial-Services.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Hiding CoinSwap Makers Among Custodial Services - 2023-08-02T02:23:04.645435+00:00 - - ZmnSCPxj 2020-07-17 06:02:03+00:00 - - - Chris Belcher 2020-06-13 23:25:00+00:00 - - - ZmnSCPxj 2020-06-13 14:06:05+00:00 - - - Chris Belcher 2020-06-13 13:38:35+00:00 - - - ZmnSCPxj 2020-06-11 11:51:03+00:00 - + 2025-09-26T16:00:01.967529+00:00 + python-feedgen + + + [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services ZmnSCPxj + 2020-06-11T11:51:00.000Z + + + Chris Belcher + 2020-06-13T13:38:00.000Z + + + ZmnSCPxj + 2020-06-13T14:06:00.000Z + + + Chris Belcher + 2020-06-13T23:25:00.000Z + + + ZmnSCPxj + 2020-07-17T06:02:00.000Z + + - python-feedgen + 2 Combined summary - Hiding CoinSwap Makers Among Custodial Services - 2023-08-02T02:23:04.645435+00:00 + 2025-09-26T16:00:01.968297+00:00 - In a recent email exchange, ZmnSCPxj and Chris discuss the potential benefits of using batching in CoinSwap operations. By slowing down the process, CoinSwappers can pretend to be a service provider and improve privacy. This would also allow makers to use batching and potentially save on fees. However, ZmnSCPxj later realizes that the same kind of batching can also be done by the taker. By contacting two makers in parallel, each CoinSwap operation would look like an ordinary pay-to-someone-and-get-back-change transaction. This method could potentially provide extra privacy and reduced cost for the taker, but its effectiveness is uncertain.The conversation between ZmnSCPxj and Chris revolves around the idea of CoinSwappers slowing down the CoinSwap process to enable makers to use batching. This strategy not only improves privacy by pretending to be a service provider using batching but also offers practical benefits for CoinSwap takers who want greater privacy. By being willing to wait longer, takers can save on miner fees as well.The email exchange briefly discusses the idea of CoinSwappers slowing down the CoinSwap process to allow makers to utilize batching. It seems that CoinSwappers act as intermediaries in the CoinSwap process. Slowing down the process gives makers more time to batch their transactions and potentially save on fees. The email exchange acknowledges that there are important links provided in the email to provide more context for those unfamiliar with the terms used. CoinSwap refers to a specific type of transaction that allows users to swap cryptocurrencies without revealing their identities, while batching is a technique that combines multiple transactions into a single one to save on network fees.ZmnSCPxj, a Bitcoin developer, proposes a technique to enhance CoinSwap user privacy. The approach involves makers operating in rounds and using transaction batching to serve multiple clients with a single transaction. This not only addresses blockchain size issues but also incentivizes makers to adopt the technique by reducing their overall transaction costs. By spreading taint and increasing the effort required for chain analysis, this method can slow down the CoinSwap process and enable makers to utilize batching for improved user privacy.In a post on the bitcoin-dev mailing list, ZmnSCPxj suggests a method to enhance the privacy of SwapMarket customers. This proposal entails makers operating in rounds and using batching to combine multiple client transactions into a single one. By doing so, makers can mitigate blockchain size issues associated with CoinSwap. Although this increases the effort required for chain analysis and spreads taint, makers are incentivized to adopt this technique due to reduced transaction costs and increased profitability. 2020-07-17T06:02:03+00:00 + In a recent email exchange, ZmnSCPxj and Chris discuss the potential benefits of using batching in CoinSwap operations. By slowing down the process, CoinSwappers can pretend to be a service provider and improve privacy. This would also allow makers to use batching and potentially save on fees. However, ZmnSCPxj later realizes that the same kind of batching can also be done by the taker. By contacting two makers in parallel, each CoinSwap operation would look like an ordinary pay-to-someone-and-get-back-change transaction. This method could potentially provide extra privacy and reduced cost for the taker, but its effectiveness is uncertain.The conversation between ZmnSCPxj and Chris revolves around the idea of CoinSwappers slowing down the CoinSwap process to enable makers to use batching. This strategy not only improves privacy by pretending to be a service provider using batching but also offers practical benefits for CoinSwap takers who want greater privacy. By being willing to wait longer, takers can save on miner fees as well.The email exchange briefly discusses the idea of CoinSwappers slowing down the CoinSwap process to allow makers to utilize batching. It seems that CoinSwappers act as intermediaries in the CoinSwap process. Slowing down the process gives makers more time to batch their transactions and potentially save on fees. The email exchange acknowledges that there are important links provided in the email to provide more context for those unfamiliar with the terms used. CoinSwap refers to a specific type of transaction that allows users to swap cryptocurrencies without revealing their identities, while batching is a technique that combines multiple transactions into a single one to save on network fees.ZmnSCPxj, a Bitcoin developer, proposes a technique to enhance CoinSwap user privacy. The approach involves makers operating in rounds and using transaction batching to serve multiple clients with a single transaction. This not only addresses blockchain size issues but also incentivizes makers to adopt the technique by reducing their overall transaction costs. By spreading taint and increasing the effort required for chain analysis, this method can slow down the CoinSwap process and enable makers to utilize batching for improved user privacy.In a post on the bitcoin-dev mailing list, ZmnSCPxj suggests a method to enhance the privacy of SwapMarket customers. This proposal entails makers operating in rounds and using batching to combine multiple client transactions into a single one. By doing so, makers can mitigate blockchain size issues associated with CoinSwap. Although this increases the effort required for chain analysis and spreads taint, makers are incentivized to adopt this technique due to reduced transaction costs and increased profitability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Is-Bitcoin-mempool-synchronized-.xml b/static/bitcoin-dev/June_2020/combined_Is-Bitcoin-mempool-synchronized-.xml index b8f5c89180..dd0ed73b62 100644 --- a/static/bitcoin-dev/June_2020/combined_Is-Bitcoin-mempool-synchronized-.xml +++ b/static/bitcoin-dev/June_2020/combined_Is-Bitcoin-mempool-synchronized-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Is Bitcoin mempool synchronized? - 2023-08-02T02:27:26.764047+00:00 - - ZmnSCPxj 2020-07-01 00:53:46+00:00 - - - Hilda 2020-06-30 19:01:30+00:00 - + 2025-09-26T15:59:55.607391+00:00 + python-feedgen + + + [bitcoin-dev] Is Bitcoin mempool synchronized? Hilda + 2020-06-30T19:01:00.000Z + + + ZmnSCPxj + 2020-07-01T00:53:00.000Z + + - python-feedgen + 2 Combined summary - Is Bitcoin mempool synchronized? - 2023-08-02T02:27:26.764047+00:00 + 2025-09-26T15:59:55.607857+00:00 - Hilda recently raised a question about the synchronization of the Bitcoin system, particularly regarding mempools. Mempools are essentially pools of unconfirmed transactions waiting to be included in the blockchain. While there is no direct way to limit the number of transactions someone can push onto your mempool, certain heuristics can assist in managing this issue.However, it's worth noting that these heuristics can sometimes create desynchronization between different mempools, which can potentially lead to problems. This means that the contents of one node's mempool may not match those of another node, causing discrepancies in transaction data.Fortunately, the blockchain itself serves as the main source of synchronization. The blockchain is a public ledger where all confirmed transactions are recorded in a sequential and synchronized manner. It ensures that transactions are legitimate by requiring miners to perform computationally intensive work towards achieving a difficulty target before they can add a block to the chain. As a result, it becomes practically impossible for someone to spam blocks without putting in considerable effort.It is important to highlight that consensus rules should primarily focus on data contained within blocks, rather than relying on information from mempools. Mempools are ephemeral and not synchronized across all nodes. Therefore, referring to mempool data for verifying the state of the entire Bitcoin system would require checking with every miner continuously, which is impractical.In conclusion, Hilda's query revolves around the verification of synchronization within the Bitcoin system, specifically concerning mempools. While heuristics can help manage the influx of transactions, they can also cause desynchronization between mempools. However, since the blockchain itself is the foundation of synchronization, attempting to spam blocks without performing the necessary computational work is virtually impossible. Consensus rules should prioritize data within blocks rather than relying on ephemeral and unsynchronized mempools. 2020-07-01T00:53:46+00:00 + Hilda recently raised a question about the synchronization of the Bitcoin system, particularly regarding mempools. Mempools are essentially pools of unconfirmed transactions waiting to be included in the blockchain. While there is no direct way to limit the number of transactions someone can push onto your mempool, certain heuristics can assist in managing this issue.However, it's worth noting that these heuristics can sometimes create desynchronization between different mempools, which can potentially lead to problems. This means that the contents of one node's mempool may not match those of another node, causing discrepancies in transaction data.Fortunately, the blockchain itself serves as the main source of synchronization. The blockchain is a public ledger where all confirmed transactions are recorded in a sequential and synchronized manner. It ensures that transactions are legitimate by requiring miners to perform computationally intensive work towards achieving a difficulty target before they can add a block to the chain. As a result, it becomes practically impossible for someone to spam blocks without putting in considerable effort.It is important to highlight that consensus rules should primarily focus on data contained within blocks, rather than relying on information from mempools. Mempools are ephemeral and not synchronized across all nodes. Therefore, referring to mempool data for verifying the state of the entire Bitcoin system would require checking with every miner continuously, which is impractical.In conclusion, Hilda's query revolves around the verification of synchronization within the Bitcoin system, specifically concerning mempools. While heuristics can help manage the influx of transactions, they can also cause desynchronization between mempools. However, since the blockchain itself is the foundation of synchronization, attempting to spam blocks without performing the necessary computational work is virtually impossible. Consensus rules should prioritize data within blocks rather than relying on ephemeral and unsynchronized mempools. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_MAD-HTLC.xml b/static/bitcoin-dev/June_2020/combined_MAD-HTLC.xml index 197bec5ef6..f72fb51123 100644 --- a/static/bitcoin-dev/June_2020/combined_MAD-HTLC.xml +++ b/static/bitcoin-dev/June_2020/combined_MAD-HTLC.xml @@ -1,89 +1,119 @@ - + 2 Combined summary - MAD-HTLC - 2023-08-02T02:25:21.896054+00:00 - - Tejaswi Nadahalli 2020-07-06 11:13:47+00:00 - - - Stanga 2020-07-05 09:03:14+00:00 - - - ZmnSCPxj 2020-07-04 21:05:34+00:00 - - - ZmnSCPxj 2020-07-04 20:58:57+00:00 - - - ZmnSCPxj 2020-07-03 12:38:37+00:00 - - - Tejaswi Nadahalli 2020-07-03 10:44:59+00:00 - - - ZmnSCPxj 2020-07-03 10:16:55+00:00 - - - Tejaswi Nadahalli 2020-07-03 09:43:37+00:00 - - - ZmnSCPxj 2020-07-02 16:06:04+00:00 - - - Tejaswi Nadahalli 2020-07-02 12:39:35+00:00 - - - Tejaswi Nadahalli 2020-07-02 12:22:51+00:00 - - - ZmnSCPxj 2020-07-01 16:58:24+00:00 - - - Tejaswi Nadahalli 2020-06-30 06:45:09+00:00 - - - Stanga 2020-06-30 06:28:58+00:00 - - - ZmnSCPxj 2020-06-29 18:05:10+00:00 - - - Tejaswi Nadahalli 2020-06-29 11:57:52+00:00 - - - David A. Harding 2020-06-28 16:41:32+00:00 - - - David A. Harding 2020-06-28 12:15:17+00:00 - - - Bastien TEINTURIER 2020-06-25 13:12:56+00:00 - - - Nadav Ivgi 2020-06-25 04:35:51+00:00 - - - ZmnSCPxj 2020-06-25 04:04:09+00:00 - - - Nadav Ivgi 2020-06-25 03:26:41+00:00 - - - ZmnSCPxj 2020-06-25 01:38:17+00:00 - - - Stanga 2020-06-23 13:18:35+00:00 - - - Stanga 2020-06-23 12:47:56+00:00 - - - ZmnSCPxj 2020-06-23 09:48:27+00:00 - - - Stanga 2020-06-23 06:41:56+00:00 - + 2025-09-26T15:59:44.919097+00:00 + python-feedgen + + + [bitcoin-dev] MAD-HTLC Stanga + 2020-06-23T06:41:00.000Z + + + ZmnSCPxj + 2020-06-23T09:48:00.000Z + + + Stanga + 2020-06-23T12:47:00.000Z + + + Stanga + 2020-06-23T13:18:00.000Z + + + ZmnSCPxj + 2020-06-25T01:38:00.000Z + + + Nadav Ivgi + 2020-06-25T03:26:00.000Z + + + ZmnSCPxj + 2020-06-25T04:04:00.000Z + + + Nadav Ivgi + 2020-06-25T04:35:00.000Z + + + Bastien TEINTURIER + 2020-06-25T13:12:00.000Z + + + David A. Harding + 2020-06-28T12:15:00.000Z + + + David A. Harding + 2020-06-28T16:41:00.000Z + + + Tejaswi Nadahalli + 2020-06-29T11:57:00.000Z + + + ZmnSCPxj + 2020-06-29T18:05:00.000Z + + + Stanga + 2020-06-30T06:28:00.000Z + + + Tejaswi Nadahalli + 2020-06-30T06:45:00.000Z + + + ZmnSCPxj + 2020-07-01T16:58:00.000Z + + + Tejaswi Nadahalli + 2020-07-02T12:22:00.000Z + + + Tejaswi Nadahalli + 2020-07-02T12:39:00.000Z + + + ZmnSCPxj + 2020-07-02T16:06:00.000Z + + + Tejaswi Nadahalli + 2020-07-03T09:43:00.000Z + + + ZmnSCPxj + 2020-07-03T10:16:00.000Z + + + Tejaswi Nadahalli + 2020-07-03T10:44:00.000Z + + + ZmnSCPxj + 2020-07-03T12:38:00.000Z + + + ZmnSCPxj + 2020-07-04T20:58:00.000Z + + + ZmnSCPxj + 2020-07-04T21:05:00.000Z + + + Stanga + 2020-07-05T09:03:00.000Z + + + Tejaswi Nadahalli + 2020-07-06T11:13:00.000Z + + @@ -111,13 +141,13 @@ - python-feedgen + 2 Combined summary - MAD-HTLC - 2023-08-02T02:25:21.896054+00:00 + 2025-09-26T15:59:44.921924+00:00 - In a recent email conversation, Itay Tsabary discussed the token amount required for the collateral contract in a collateralized contract. He mentioned that the required token amount is low and independent of the deposit tokens. He argued that a relatively small incentive is enough to encourage honest behavior from participants. However, this does result in slightly larger transactions with another UTXO. The recipient of the email questioned whether the collateral had to be at least the same size as the deposit, expressing concerns about the potential for bribery attacks. The discussion between Ittay and ZmnSCPxj on the Bitcoin-dev mailing list focused on myopic and non-myopic miners. Non-myopic miners optimize transaction selection for multiple future blocks, while myopic miners only optimize for the next block. The term "dominates" refers to a strategy in game theory that consistently outperforms another strategy. Myopic strategies tend to beat non-myopic strategies because they impose costs on non-myopic miners. Currently, no miner is non-myopic, but it is possible to implement non-myopia in Bitcoin Core. However, implementing non-myopia is considered pointless since myopic strategies dominate over non-myopic strategies. The MAD-HTLC (Miner-Activated Delayed Hash Time-Locked Contract) consists of two contracts: Deposit and Collateral. The Deposit has three redeem paths, while the Collateral serves as a fidelity bond and has two redeem paths. The MAD-HTLC has three cases, each determining the distribution of BTC based on specific conditions. However, these contracts may not be safe if the counterparty is a miner, as it could incentivize competing miners to reorganize the chain and redirect funds. The analysis of the MAD-HTLC paper shows that, in a scenario where all players are rational, the dominant strategy is to support an attack. This situation can be compared to the Prisoner's Dilemma game. One way to address this is through Iterated Prisoner's Dilemma, but it requires miners to identify each other and act accordingly. Another approach is to have a higher system that enforces a specific strategy and punishes deviations. However, this would lead to a centralized cartel, which would be detrimental to Bitcoin.In another email thread, ZmnSCPxj responded to a post about myopic and non-myopic miners in a mixed population. They argued that myopic strategies dominate over non-myopic ones because myopic miners deduct fees from non-myopic miners by preventing certain transactions from being confirmed. The probability of a bribery attack failing decreases exponentially based on the number of blocks until timeout and the percentage of hashrate controlled by myopic miners. Even with a small amount of myopic hashrate and long timeouts or modest amounts of hashrate and short timeouts, the attack is unlikely to succeed. The discussion also touched on the safety of MAD-HTLC and potential vulnerabilities in the Lightning Network. Concerns were raised about the assumption that the mempool is a shared resource and the possibility of double-spending attacks. Various disincentives for attackers were proposed to mitigate these risks. The overall discussions revolved around the dominance of myopic miners, the likelihood of bribery attacks succeeding, and potential vulnerabilities in different contract models. 2020-07-06T11:13:47+00:00 + In a recent email conversation, Itay Tsabary discussed the token amount required for the collateral contract in a collateralized contract. He mentioned that the required token amount is low and independent of the deposit tokens. He argued that a relatively small incentive is enough to encourage honest behavior from participants. However, this does result in slightly larger transactions with another UTXO. The recipient of the email questioned whether the collateral had to be at least the same size as the deposit, expressing concerns about the potential for bribery attacks. The discussion between Ittay and ZmnSCPxj on the Bitcoin-dev mailing list focused on myopic and non-myopic miners. Non-myopic miners optimize transaction selection for multiple future blocks, while myopic miners only optimize for the next block. The term "dominates" refers to a strategy in game theory that consistently outperforms another strategy. Myopic strategies tend to beat non-myopic strategies because they impose costs on non-myopic miners. Currently, no miner is non-myopic, but it is possible to implement non-myopia in Bitcoin Core. However, implementing non-myopia is considered pointless since myopic strategies dominate over non-myopic strategies. The MAD-HTLC (Miner-Activated Delayed Hash Time-Locked Contract) consists of two contracts: Deposit and Collateral. The Deposit has three redeem paths, while the Collateral serves as a fidelity bond and has two redeem paths. The MAD-HTLC has three cases, each determining the distribution of BTC based on specific conditions. However, these contracts may not be safe if the counterparty is a miner, as it could incentivize competing miners to reorganize the chain and redirect funds. The analysis of the MAD-HTLC paper shows that, in a scenario where all players are rational, the dominant strategy is to support an attack. This situation can be compared to the Prisoner's Dilemma game. One way to address this is through Iterated Prisoner's Dilemma, but it requires miners to identify each other and act accordingly. Another approach is to have a higher system that enforces a specific strategy and punishes deviations. However, this would lead to a centralized cartel, which would be detrimental to Bitcoin.In another email thread, ZmnSCPxj responded to a post about myopic and non-myopic miners in a mixed population. They argued that myopic strategies dominate over non-myopic ones because myopic miners deduct fees from non-myopic miners by preventing certain transactions from being confirmed. The probability of a bribery attack failing decreases exponentially based on the number of blocks until timeout and the percentage of hashrate controlled by myopic miners. Even with a small amount of myopic hashrate and long timeouts or modest amounts of hashrate and short timeouts, the attack is unlikely to succeed. The discussion also touched on the safety of MAD-HTLC and potential vulnerabilities in the Lightning Network. Concerns were raised about the assumption that the mempool is a shared resource and the possibility of double-spending attacks. Various disincentives for attackers were proposed to mitigate these risks. The overall discussions revolved around the dominance of myopic miners, the likelihood of bribery attacks succeeding, and potential vulnerabilities in different contract models. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Question-about-PayJoin-effectiveness.xml b/static/bitcoin-dev/June_2020/combined_Question-about-PayJoin-effectiveness.xml index c34cca4a6c..d08fd09d2f 100644 --- a/static/bitcoin-dev/June_2020/combined_Question-about-PayJoin-effectiveness.xml +++ b/static/bitcoin-dev/June_2020/combined_Question-about-PayJoin-effectiveness.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Question about PayJoin effectiveness - 2023-08-02T02:22:07.379156+00:00 - - Chris Belcher 2020-06-10 17:49:16+00:00 - - - ZmnSCPxj 2020-06-10 06:47:28+00:00 - - - ZmnSCPxj 2020-06-10 06:29:08+00:00 - - - Mr. Lee Chiffre 2020-06-10 04:01:44+00:00 - + 2025-09-26T16:00:16.898079+00:00 + python-feedgen + + + [bitcoin-dev] Question about PayJoin effectiveness Mr. Lee Chiffre + 2020-06-10T04:01:00.000Z + + + ZmnSCPxj + 2020-06-10T06:29:00.000Z + + + ZmnSCPxj + 2020-06-10T06:47:00.000Z + + + Chris Belcher + 2020-06-10T17:49:00.000Z + + - python-feedgen + 2 Combined summary - Question about PayJoin effectiveness - 2023-08-02T02:22:07.380157+00:00 + 2025-09-26T16:00:16.898720+00:00 - In an email to bitcoin-dev, Mr. Lee Chiffre expressed concerns about the effectiveness of payjoin and raised two main points. First, he questioned whether it would be possible for anyone to determine the sender, recipient, and amount of a transaction if payjoin became widely used. He provided an example where Alice pays 0.01 BTC to Bob through payjoin, highlighting that it would be obvious who sent the payment and how much was sent. Even if Alice combined another input, the transaction details would still be apparent. Mr. Lee Chiffre's second concern focused on the potential privacy implications of having just one consolidated unspent transaction output (UTXO) after each payjoin. He illustrated this with an example where Alice payjoins with Bob, and later Clark payjoins with Bob as well. Based on the payjoin between Clark and Bob, Clark could identify which UTXO belonged to Bob and consequently discern which one was Alice's. This could potentially allow someone to de-anonymize the payjoins that occurred before them in the transaction chain. The email response acknowledged that payjoin does break the common-input-ownership heuristic, which is a key factor in the effectiveness of blockchain surveillance. Satoshi mentioned this assumption in the whitepaper, noting the unavoidable loss of privacy. However, the fact that technology exists to challenge this assumption is considered a significant advantage of payjoin. The email also included a link to a paper on the unreasonable effectiveness of address clustering.Payjoin is a method used to enhance the privacy of Bitcoin transactions. Nevertheless, there are concerns about its effectiveness. One major concern is that if payjoin transactions are easily identifiable, it becomes possible for anyone to determine the sender, recipient, and amount involved. Additionally, the consolidation of UTXOs after each payjoin raises questions about the potential privacy breaches in transaction chains. For instance, if multiple payjoins occur with the same entity, it could allow someone to trace back the entire chain and decloak preceding payjoins. To address these concerns, suggestions include shuffling inputs and outputs or consistently using BIP39. While payjoin has the potential to improve privacy, it is important to acknowledge and address the existing concerns to ensure its effectiveness. 2020-06-10T17:49:16+00:00 + In an email to bitcoin-dev, Mr. Lee Chiffre expressed concerns about the effectiveness of payjoin and raised two main points. First, he questioned whether it would be possible for anyone to determine the sender, recipient, and amount of a transaction if payjoin became widely used. He provided an example where Alice pays 0.01 BTC to Bob through payjoin, highlighting that it would be obvious who sent the payment and how much was sent. Even if Alice combined another input, the transaction details would still be apparent. Mr. Lee Chiffre's second concern focused on the potential privacy implications of having just one consolidated unspent transaction output (UTXO) after each payjoin. He illustrated this with an example where Alice payjoins with Bob, and later Clark payjoins with Bob as well. Based on the payjoin between Clark and Bob, Clark could identify which UTXO belonged to Bob and consequently discern which one was Alice's. This could potentially allow someone to de-anonymize the payjoins that occurred before them in the transaction chain. The email response acknowledged that payjoin does break the common-input-ownership heuristic, which is a key factor in the effectiveness of blockchain surveillance. Satoshi mentioned this assumption in the whitepaper, noting the unavoidable loss of privacy. However, the fact that technology exists to challenge this assumption is considered a significant advantage of payjoin. The email also included a link to a paper on the unreasonable effectiveness of address clustering.Payjoin is a method used to enhance the privacy of Bitcoin transactions. Nevertheless, there are concerns about its effectiveness. One major concern is that if payjoin transactions are easily identifiable, it becomes possible for anyone to determine the sender, recipient, and amount involved. Additionally, the consolidation of UTXOs after each payjoin raises questions about the potential privacy breaches in transaction chains. For instance, if multiple payjoins occur with the same entity, it could allow someone to trace back the entire chain and decloak preceding payjoins. To address these concerns, suggestions include shuffling inputs and outputs or consistently using BIP39. While payjoin has the potential to improve privacy, it is important to acknowledge and address the existing concerns to ensure its effectiveness. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_RBF-Pinning-with-Counterparties-and-Competing-Interest.xml b/static/bitcoin-dev/June_2020/combined_RBF-Pinning-with-Counterparties-and-Competing-Interest.xml index 356fe8bc46..2c8b6854ee 100644 --- a/static/bitcoin-dev/June_2020/combined_RBF-Pinning-with-Counterparties-and-Competing-Interest.xml +++ b/static/bitcoin-dev/June_2020/combined_RBF-Pinning-with-Counterparties-and-Competing-Interest.xml @@ -1,125 +1,103 @@ - + 2 Combined summary - RBF Pinning with Counterparties and Competing Interest - 2023-08-02T02:03:13.395560+00:00 - - Matt Corallo 2020-06-24 08:32:52+00:00 - - - Bastien TEINTURIER 2020-06-22 08:25:09+00:00 - - - ZmnSCPxj 2020-06-22 08:15:37+00:00 - - - Bastien TEINTURIER 2020-06-22 07:35:20+00:00 - - - ZmnSCPxj 2020-06-21 02:10:32+00:00 - - - ZmnSCPxj 2020-06-20 16:01:16+00:00 - - - David A. Harding 2020-06-20 10:36:47+00:00 - - - Bastien TEINTURIER 2020-06-20 08:54:03+00:00 - - - David A. Harding 2020-06-19 20:52:20+00:00 - - - David A. Harding 2020-06-19 19:58:46+00:00 - - - Bastien TEINTURIER 2020-06-19 07:44:11+00:00 - - - Rusty Russell 2020-04-27 21:26:19+00:00 - - - Matt Corallo 2020-04-23 22:47:46+00:00 - - - ZmnSCPxj 2020-04-23 12:52:57+00:00 - - - ZmnSCPxj 2020-04-23 12:46:59+00:00 - - - David A. Harding 2020-04-23 09:59:57+00:00 - - - Matt Corallo 2020-04-23 06:21:50+00:00 - - - ZmnSCPxj 2020-04-23 04:50:09+00:00 - - - Jeremy 2020-04-23 01:18:05+00:00 - - - Matt Corallo 2020-04-23 01:10:47+00:00 - - - Olaoluwa Osuntokun 2020-04-22 23:27:49+00:00 - - - Matt Corallo 2020-04-22 23:20:03+00:00 - - - Olaoluwa Osuntokun 2020-04-22 23:13:01+00:00 - - - Olaoluwa Osuntokun 2020-04-22 23:11:08+00:00 - - - Olaoluwa Osuntokun 2020-04-22 23:05:17+00:00 - - - Matt Corallo 2020-04-22 22:53:37+00:00 - - - David A. Harding 2020-04-22 20:28:13+00:00 - - - Antoine Riard 2020-04-22 19:03:29+00:00 - - - David A. Harding 2020-04-22 18:24:54+00:00 - - - Matt Corallo 2020-04-22 16:56:38+00:00 - - - Matt Corallo 2020-04-22 16:50:46+00:00 - - - David A. Harding 2020-04-22 11:51:30+00:00 - - - Bastien TEINTURIER 2020-04-22 08:55:42+00:00 - - - Antoine Riard 2020-04-22 08:01:23+00:00 - - - ZmnSCPxj 2020-04-22 06:08:06+00:00 - - - Olaoluwa Osuntokun 2020-04-22 04:18:29+00:00 - - - Olaoluwa Osuntokun 2020-04-22 04:13:34+00:00 - - - ZmnSCPxj 2020-04-22 04:12:59+00:00 - - - Matt Corallo 2020-04-21 02:43:14+00:00 - + 2025-09-26T16:00:21.170880+00:00 + python-feedgen + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2020-04-22T04:12:00.000Z + + + Olaoluwa Osuntokun + 2020-04-22T04:18:00.000Z + + + ZmnSCPxj + 2020-04-22T06:08:00.000Z + + + Antoine Riard + 2020-04-22T08:01:00.000Z + + + Bastien TEINTURIER + 2020-04-22T08:55:00.000Z + + + Matt Corallo + 2020-04-22T16:56:00.000Z + + + Olaoluwa Osuntokun + 2020-04-22T23:05:00.000Z + + + Olaoluwa Osuntokun + 2020-04-22T23:11:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2020-04-23T04:50:00.000Z + + + Matt Corallo + 2020-04-23T06:21:00.000Z + + + ZmnSCPxj + 2020-04-23T12:46:00.000Z + + + Matt Corallo + 2020-04-23T22:47:00.000Z + + + Bastien TEINTURIER + 2020-06-19T07:44:00.000Z + + + David A. Harding + 2020-06-19T19:58:00.000Z + + + David A. Harding + 2020-06-19T20:52:00.000Z + + + Bastien TEINTURIER + 2020-06-20T08:54:00.000Z + + + David A. Harding + 2020-06-20T10:36:00.000Z + + + ZmnSCPxj + 2020-06-20T16:01:00.000Z + + + ZmnSCPxj + 2020-06-21T02:10:00.000Z + + + Bastien TEINTURIER + 2020-06-22T07:35:00.000Z + + + ZmnSCPxj + 2020-06-22T08:15:00.000Z + + + Bastien TEINTURIER + 2020-06-22T08:25:00.000Z + + + Matt Corallo + 2020-06-24T08:32:00.000Z + + @@ -159,13 +137,13 @@ - python-feedgen + 2 Combined summary - RBF Pinning with Counterparties and Competing Interest - 2023-08-02T02:03:13.395560+00:00 + 2025-09-26T16:00:21.173200+00:00 - The conversations and email threads discussed various proposals and concerns related to the Lightning Network, mempool evictions, double-spend attacks, HTLC spends, and policy rules. One proposal involved bribing miners for knowledge, but it was acknowledged that additional software and complexity would be needed. There were discussions about limiting low-fee-rate packages in the mempool, marking transactions as "likely-to-be-RBF'ed", and potential changes to the Poon-Dryja channels contract text. Increasing development resources to address mempool issues was emphasized. The lightning network community explored solutions such as mempool-watching and the use of anchor outputs. Concerns were raised about computational complexity, bidding wars, and the choice of internal data structures. The economic rationality of accepting higher fee rate packages and the challenges of monitoring the global mempool were also discussed. Overall, the discussions highlighted ongoing efforts to improve the efficiency and security of the Lightning Network and address various challenges and vulnerabilities.The discussion on the Lightning-dev mailing list focused on a potential vulnerability in the Bitcoin Lightning Network's hash locked time contracts (HTLC). The vulnerability arises when a transaction from party A to party C has already timed out, allowing party B and C to engage in a bidding war with miners to get their version of the transaction committed on-chain. To mitigate this, party B must ensure that the HTLC-Timeout is committed on-chain before the timeout, preventing the bidding war from starting. A proposed solution involves using `OP_CHECKSEQUENCEVERIFY` to enforce RBF-flagging and allowing B to fee-bump the HTLC-Timeout signature from C with some on-chain funds if the L+1 timeout is approaching. The current anchors proposal enforces a CSV of 1 block before the HTLCs can be spent, further mitigating the attack. However, there are concerns regarding the reliability of the proposed solutions, including the risk of losing money if the remote party broadcasts their version of the commitment without revoking. There are also discussions about using reject messages with extended functionality to handle conflicts in the mempool, but practical design issues and concerns about potential DoS vectors need to be considered.In an email exchange, limitations of Bitcoin contracts with nested trees of transactions were discussed, as well as the use of mempool-watching as a mitigation measure against attacks on Lightning nodes. Suggestions were made to resolve issues such as eliminating the commitment fee guessing game and allowing users to pay less on force close. Different proposals were presented, including pre-signing all HTLC output spends and making them more free-form, but there were concerns about the need for an overhaul in the channel state machine. The enforcement of BIP125 rule 3, which requires each replacement transaction to pay a higher fee rate than the previous one, was also discussed. Two attack vectors on the Lightning Network were mentioned: delaying the confirmation of honest party transactions to provoke an unbalanced settlement for the victim, and a vulnerability in RBF Pinning HTLC Transactions. Suggestions were made to add an RBF carve-out output to HTLC-Timeout or allow for re-signing the B-side signature for a higher-fee version.ZmnSCPxj proposed a mechanism to protect against RBF attacks on HTLC transactions in the Lightning Network. The suggested solution involved confirming HTLC-Timeout on-chain before a certain time to prevent the theft of the HTLC value. Another proposal was to add an RBF carve-out output to HTLC-Timeout or use SIGHASH_NOINPUT to allow for fee-bumping. The limitations of Bitcoin contracts were discussed, as well as the choice of internal data structures and monitoring the global mempool as a mitigation measure for Lightning implementations.The lightning protocol's vulnerability, where a counterparty could steal HTLC funds using a low-fee, RBF-disabled transaction, was highlighted. Solutions were proposed, such as adding an RBF carve-out output to HTLC-Timeout or allowing for fees using SIGHASH_NOINPUT. The Decker-Russell-Osuntokun approach was mentioned as a way to sidestep this issue. Concerns about anchor outputs and the possibility of using RBF Pinning to steal in-flight HTLCs enforced on-chain were also raised. Alternative proposals were suggested to improve the security of the Lightning Network.Overall, the discussions delved into various technical solutions, concerns, and potential attacks related to transaction security, mempool information, and the Lightning Network. Different proposals and suggestions were presented, highlighting the complexities and challenges of ensuring the integrity and efficiency of Bitcoin transactions. 2020-06-24T08:32:52+00:00 + The conversations and email threads discussed various proposals and concerns related to the Lightning Network, mempool evictions, double-spend attacks, HTLC spends, and policy rules. One proposal involved bribing miners for knowledge, but it was acknowledged that additional software and complexity would be needed. There were discussions about limiting low-fee-rate packages in the mempool, marking transactions as "likely-to-be-RBF'ed", and potential changes to the Poon-Dryja channels contract text. Increasing development resources to address mempool issues was emphasized. The lightning network community explored solutions such as mempool-watching and the use of anchor outputs. Concerns were raised about computational complexity, bidding wars, and the choice of internal data structures. The economic rationality of accepting higher fee rate packages and the challenges of monitoring the global mempool were also discussed. Overall, the discussions highlighted ongoing efforts to improve the efficiency and security of the Lightning Network and address various challenges and vulnerabilities.The discussion on the Lightning-dev mailing list focused on a potential vulnerability in the Bitcoin Lightning Network's hash locked time contracts (HTLC). The vulnerability arises when a transaction from party A to party C has already timed out, allowing party B and C to engage in a bidding war with miners to get their version of the transaction committed on-chain. To mitigate this, party B must ensure that the HTLC-Timeout is committed on-chain before the timeout, preventing the bidding war from starting. A proposed solution involves using `OP_CHECKSEQUENCEVERIFY` to enforce RBF-flagging and allowing B to fee-bump the HTLC-Timeout signature from C with some on-chain funds if the L+1 timeout is approaching. The current anchors proposal enforces a CSV of 1 block before the HTLCs can be spent, further mitigating the attack. However, there are concerns regarding the reliability of the proposed solutions, including the risk of losing money if the remote party broadcasts their version of the commitment without revoking. There are also discussions about using reject messages with extended functionality to handle conflicts in the mempool, but practical design issues and concerns about potential DoS vectors need to be considered.In an email exchange, limitations of Bitcoin contracts with nested trees of transactions were discussed, as well as the use of mempool-watching as a mitigation measure against attacks on Lightning nodes. Suggestions were made to resolve issues such as eliminating the commitment fee guessing game and allowing users to pay less on force close. Different proposals were presented, including pre-signing all HTLC output spends and making them more free-form, but there were concerns about the need for an overhaul in the channel state machine. The enforcement of BIP125 rule 3, which requires each replacement transaction to pay a higher fee rate than the previous one, was also discussed. Two attack vectors on the Lightning Network were mentioned: delaying the confirmation of honest party transactions to provoke an unbalanced settlement for the victim, and a vulnerability in RBF Pinning HTLC Transactions. Suggestions were made to add an RBF carve-out output to HTLC-Timeout or allow for re-signing the B-side signature for a higher-fee version.ZmnSCPxj proposed a mechanism to protect against RBF attacks on HTLC transactions in the Lightning Network. The suggested solution involved confirming HTLC-Timeout on-chain before a certain time to prevent the theft of the HTLC value. Another proposal was to add an RBF carve-out output to HTLC-Timeout or use SIGHASH_NOINPUT to allow for fee-bumping. The limitations of Bitcoin contracts were discussed, as well as the choice of internal data structures and monitoring the global mempool as a mitigation measure for Lightning implementations.The lightning protocol's vulnerability, where a counterparty could steal HTLC funds using a low-fee, RBF-disabled transaction, was highlighted. Solutions were proposed, such as adding an RBF carve-out output to HTLC-Timeout or allowing for fees using SIGHASH_NOINPUT. The Decker-Russell-Osuntokun approach was mentioned as a way to sidestep this issue. Concerns about anchor outputs and the possibility of using RBF Pinning to steal in-flight HTLCs enforced on-chain were also raised. Alternative proposals were suggested to improve the security of the Lightning Network.Overall, the discussions delved into various technical solutions, concerns, and potential attacks related to transaction security, mempool information, and the Lightning Network. Different proposals and suggestions were presented, highlighting the complexities and challenges of ensuring the integrity and efficiency of Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_SAS-Succinct-Atomic-Swap.xml b/static/bitcoin-dev/June_2020/combined_SAS-Succinct-Atomic-Swap.xml index 27bf3a2c69..2234f8e076 100644 --- a/static/bitcoin-dev/June_2020/combined_SAS-Succinct-Atomic-Swap.xml +++ b/static/bitcoin-dev/June_2020/combined_SAS-Succinct-Atomic-Swap.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - SAS: Succinct Atomic Swap - 2023-08-02T02:13:08.885550+00:00 - - ZmnSCPxj 2020-06-03 14:36:46+00:00 - - - Dmitry Petukhov 2020-06-03 09:04:25+00:00 - - - Ruben Somsen 2020-05-15 19:47:29+00:00 - - - ZmnSCPxj 2020-05-15 04:39:33+00:00 - - - Ruben Somsen 2020-05-13 12:33:21+00:00 - - - ZmnSCPxj 2020-05-13 11:39:10+00:00 - - - Ruben Somsen 2020-05-13 09:58:26+00:00 - - - Ruben Somsen 2020-05-13 09:57:05+00:00 - - - ZmnSCPxj 2020-05-13 08:39:37+00:00 - - - Chris Belcher 2020-05-12 22:50:10+00:00 - - - Ruben Somsen 2020-05-12 16:30:26+00:00 - - - ZmnSCPxj 2020-05-12 15:05:57+00:00 - - - Ruben Somsen 2020-05-12 11:34:17+00:00 - - - Ruben Somsen 2020-05-12 11:30:38+00:00 - - - Lloyd Fournier 2020-05-12 06:50:31+00:00 - - - Lloyd Fournier 2020-05-12 06:10:47+00:00 - - - ZmnSCPxj 2020-05-12 04:41:43+00:00 - - - Ruben Somsen 2020-05-11 17:50:21+00:00 - - - ZmnSCPxj 2020-05-11 16:45:21+00:00 - - - Ruben Somsen 2020-05-11 15:29:51+00:00 - + 2025-09-26T16:00:04.133396+00:00 + python-feedgen + + + [bitcoin-dev] SAS: Succinct Atomic Swap Ruben Somsen + 2020-05-11T15:29:00.000Z + + + ZmnSCPxj + 2020-05-11T16:45:00.000Z + + + Ruben Somsen + 2020-05-11T17:50:00.000Z + + + ZmnSCPxj + 2020-05-12T04:41:00.000Z + + + Lloyd Fournier + 2020-05-12T06:10:00.000Z + + + Lloyd Fournier + 2020-05-12T06:50:00.000Z + + + Ruben Somsen + 2020-05-12T11:30:00.000Z + + + Ruben Somsen + 2020-05-12T11:34:00.000Z + + + ZmnSCPxj + 2020-05-12T15:05:00.000Z + + + Ruben Somsen + 2020-05-12T16:30:00.000Z + + + Chris Belcher + 2020-05-12T22:50:00.000Z + + + ZmnSCPxj + 2020-05-13T08:39:00.000Z + + + Ruben Somsen + 2020-05-13T09:57:00.000Z + + + Ruben Somsen + 2020-05-13T09:58:00.000Z + + + ZmnSCPxj + 2020-05-13T11:39:00.000Z + + + Ruben Somsen + 2020-05-13T12:33:00.000Z + + + ZmnSCPxj + 2020-05-15T04:39:00.000Z + + + Ruben Somsen + 2020-05-15T19:47:00.000Z + + + Dmitry Petukhov + 2020-06-03T09:04:00.000Z + + + ZmnSCPxj + 2020-06-03T14:36:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - SAS: Succinct Atomic Swap - 2023-08-02T02:13:08.885550+00:00 + 2025-09-26T16:00:04.135726+00:00 - In an email conversation, ZmnSCPxj informs Dmitry about creating a version of the TLA+ spec in the 'variant_ZmnSCPxj' branch of the SASwap repo. However, there is a possible deadlock after step 9 if Bob fails to publish a success transaction on time. To address this issue, Bob will have a short timeout period after which he will force publication of the success transaction if Alice does not respond. Running multiple servers can mitigate accidents due to computer crashes. A dead man switch system can countermand the main server in such situations. The probability of accidents occurring can be reduced to negligible levels.In another discussion between Ruben and ZmnSCPxj, they discuss the possibility of chaos if Bob neglects to broadcast the success tx before refund tx #1 becomes valid. They propose using sighash_single + anyonecanpay to ensure the TXO is spent before refund tx #1 becomes valid. They also suggest that in a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. Bob should spend his UTXO first to reduce resource wastage. They also discuss how Bob can specify address/value pairs in the success tx, allowing for additional flexibility later.The conversation revolves around a hypothetical situation where Alice and Bob are participating in a protocol. There are concerns about potential chaos if Bob misses the deadline for broadcasting the success tx. It is suggested that Bob should broadcast the success tx before refund tx #1 becomes valid. In a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. It is also important for Bob to spend his UTXO first to minimize resource waste. Additionally, there is a discussion about the use of private key handover and the risks associated with it.In a discussion between Ruben and ZmnSCPxj, they discuss potential issues with a proposed Lightning Network protocol. One concern is the possibility of chaos if Bob lets refund tx #1 become valid after completing the protocol. Another concern is the risk of both Alice and Bob knowing all the secrets on the LTC side and competing over it. The use of multiple CPFP outpoints is suggested to prevent pinning. They also discuss the need for backup watchers in case of irrational behavior.The conversation discusses a proposed protocol where Alice and Bob share secrets on the Litecoin (LTC) side and compete for it. Potential issues with the proposal are highlighted, including the risk of competing revoke transactions and the use of refund transactions that could lead to chaos if broadcasted. The need for a backup watcher is emphasized. The proposal is compared to Lightning Network's HTLCs and the benefits of spending the revoke transaction before or after its absolute timelock period are discussed.The email conversation discusses the use of private key handover for old-style coinswaps to mitigate potential issues with the traditional four-transaction swap. A proposal involving a shortened refund transaction is mentioned, but ZmnSCPxj notes an issue where Bob can give a copy of the revoke tx directly to a miner, forcing Alice to take three transactions to back out of the swap. Mitigation strategies, such as using CPFP outputs and minimum relayable feerate, are discussed. The safest alternative is for Bob to spend before the timelock expires.The conversation between Ruben and ZmnSCPxj discusses the technicalities of conducting a secure and efficient coinswap. Ruben proposes a pre-swap setup to reduce privacy concerns, while ZmnSCPxj suggests using relative timelocks and private key handover. The conversation delves into the specifics of the protocol, potential risks, and mitigation strategies. The importance of running multiple servers to ensure timely execution of transactions is emphasized.The email exchange between Ruben and ZmnSCPxj discusses a proposed CoinSwap protocol and its potential vulnerabilities. The concern is that if Bob misses the deadline, Alice will reclaim the funds. Different proposals are discussed, including using CPFP outputs and minimum relayable feerate. The safety of spending before the timelock expires is highlighted.The email exchange discusses a proposed coinswap scheme with improved scalability and privacy. The conversation highlights the use of relative timelocks and private key handover to achieve efficiency and privacy gains. The benefits of applying private key handover to coinswaps are mentioned.The email exchange between Ruben Somsen and ZmnSCPxj discusses a proposed CoinSwap model and the risks associated with it. The discussion focuses on the possibility of both Alice and Bob claiming the BTC, leading to claimable LTC by both parties. Strategies to mitigate these risks, such as adding two CPFP outputs and using the minimum relayable feerate, are discussed. The safest alternative is suggested to be for Bob to spend before the timelock expires.Ruben Somsen, a Bitcoin developer, has gained recognition for his innovative protocol called "Forced Refund TLC." This protocol addresses the 2020-06-03T14:36:46+00:00 + In an email conversation, ZmnSCPxj informs Dmitry about creating a version of the TLA+ spec in the 'variant_ZmnSCPxj' branch of the SASwap repo. However, there is a possible deadlock after step 9 if Bob fails to publish a success transaction on time. To address this issue, Bob will have a short timeout period after which he will force publication of the success transaction if Alice does not respond. Running multiple servers can mitigate accidents due to computer crashes. A dead man switch system can countermand the main server in such situations. The probability of accidents occurring can be reduced to negligible levels.In another discussion between Ruben and ZmnSCPxj, they discuss the possibility of chaos if Bob neglects to broadcast the success tx before refund tx #1 becomes valid. They propose using sighash_single + anyonecanpay to ensure the TXO is spent before refund tx #1 becomes valid. They also suggest that in a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. Bob should spend his UTXO first to reduce resource wastage. They also discuss how Bob can specify address/value pairs in the success tx, allowing for additional flexibility later.The conversation revolves around a hypothetical situation where Alice and Bob are participating in a protocol. There are concerns about potential chaos if Bob misses the deadline for broadcasting the success tx. It is suggested that Bob should broadcast the success tx before refund tx #1 becomes valid. In a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. It is also important for Bob to spend his UTXO first to minimize resource waste. Additionally, there is a discussion about the use of private key handover and the risks associated with it.In a discussion between Ruben and ZmnSCPxj, they discuss potential issues with a proposed Lightning Network protocol. One concern is the possibility of chaos if Bob lets refund tx #1 become valid after completing the protocol. Another concern is the risk of both Alice and Bob knowing all the secrets on the LTC side and competing over it. The use of multiple CPFP outpoints is suggested to prevent pinning. They also discuss the need for backup watchers in case of irrational behavior.The conversation discusses a proposed protocol where Alice and Bob share secrets on the Litecoin (LTC) side and compete for it. Potential issues with the proposal are highlighted, including the risk of competing revoke transactions and the use of refund transactions that could lead to chaos if broadcasted. The need for a backup watcher is emphasized. The proposal is compared to Lightning Network's HTLCs and the benefits of spending the revoke transaction before or after its absolute timelock period are discussed.The email conversation discusses the use of private key handover for old-style coinswaps to mitigate potential issues with the traditional four-transaction swap. A proposal involving a shortened refund transaction is mentioned, but ZmnSCPxj notes an issue where Bob can give a copy of the revoke tx directly to a miner, forcing Alice to take three transactions to back out of the swap. Mitigation strategies, such as using CPFP outputs and minimum relayable feerate, are discussed. The safest alternative is for Bob to spend before the timelock expires.The conversation between Ruben and ZmnSCPxj discusses the technicalities of conducting a secure and efficient coinswap. Ruben proposes a pre-swap setup to reduce privacy concerns, while ZmnSCPxj suggests using relative timelocks and private key handover. The conversation delves into the specifics of the protocol, potential risks, and mitigation strategies. The importance of running multiple servers to ensure timely execution of transactions is emphasized.The email exchange between Ruben and ZmnSCPxj discusses a proposed CoinSwap protocol and its potential vulnerabilities. The concern is that if Bob misses the deadline, Alice will reclaim the funds. Different proposals are discussed, including using CPFP outputs and minimum relayable feerate. The safety of spending before the timelock expires is highlighted.The email exchange discusses a proposed coinswap scheme with improved scalability and privacy. The conversation highlights the use of relative timelocks and private key handover to achieve efficiency and privacy gains. The benefits of applying private key handover to coinswaps are mentioned.The email exchange between Ruben Somsen and ZmnSCPxj discusses a proposed CoinSwap model and the risks associated with it. The discussion focuses on the possibility of both Alice and Bob claiming the BTC, leading to claimable LTC by both parties. Strategies to mitigate these risks, such as adding two CPFP outputs and using the minimum relayable feerate, are discussed. The safest alternative is suggested to be for Bob to spend before the timelock expires.Ruben Somsen, a Bitcoin developer, has gained recognition for his innovative protocol called "Forced Refund TLC." This protocol addresses the - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Stamping-transaction.xml b/static/bitcoin-dev/June_2020/combined_Stamping-transaction.xml index 46faf7fb04..9e9e05c55c 100644 --- a/static/bitcoin-dev/June_2020/combined_Stamping-transaction.xml +++ b/static/bitcoin-dev/June_2020/combined_Stamping-transaction.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Stamping transaction - 2023-08-02T02:21:20.352012+00:00 - - Chris Riley 2020-06-09 14:16:27+00:00 - - - Mostafa Sedaghat joo 2020-06-09 09:34:57+00:00 - - - ZmnSCPxj 2020-06-07 15:01:42+00:00 - - - Mostafa Sedaghat joo 2020-06-07 07:27:48+00:00 - - - ZmnSCPxj 2020-06-07 00:40:51+00:00 - - - Mostafa Sedaghat joo 2020-06-05 12:05:20+00:00 - + 2025-09-26T16:00:19.018102+00:00 + python-feedgen + + + [bitcoin-dev] Stamping transaction Mostafa Sedaghat joo + 2020-06-05T12:05:00.000Z + + + ZmnSCPxj + 2020-06-07T00:40:00.000Z + + + Mostafa Sedaghat joo + 2020-06-07T07:27:00.000Z + + + ZmnSCPxj + 2020-06-07T15:01:00.000Z + + + Mostafa Sedaghat joo + 2020-06-09T09:34:00.000Z + + + Chris Riley + 2020-06-09T14:16:00.000Z + + - python-feedgen + 2 Combined summary - Stamping transaction - 2023-08-02T02:21:20.352012+00:00 + 2025-09-26T16:00:19.018929+00:00 - In a recent email exchange on the Bitcoin-dev mailing list, Mostafa Sedaghat joo proposed the idea of stamping transactions to decouple them from blocks and keep the size of the blockchain as small as possible. He argued that blockchain size matters, even though data storage is cheap and easy, and suggested that if you need a data-center to keep a copy of a blockchain, then you are far from a decentralization system.However, ZmnSCPxj countered that the entire history of Bitcoin is needed when starting a new node to prove ownership of current coins, and that existing currency systems have not only the "official" minter but also many "unofficial" minters (counterfeiters) which dilute the value of the currency. ZmnSCPxj further argued that validating the stamp is still a cost on every node, and it is that cost that needs to be reflected in pricing every byte in the transaction. He pointed out that UTXOs are retained indefinitely and that outputs in SegWit are 4x more expensive than signatures because signatures are only validated once when the transaction is queued to be put in the mempool.Mostafa Sedaghat joo suggested that the proposed mechanism could be made into a softfork by using an unspendable `scriptPubKey` with 0 output value. ZmnSCPxj countered that soft fork is not possible here since the transaction will not be saved inside the block and only tx hashes will be saved. Mostafa Sedaghat joo suggested that nodes can turn on pruning if the operator doesn't desire to keep all the transactions from the genesis block. Likewise, light clients may not keep any transaction history. He also suggested that when a new node connects to the network, it doesn't need to validate all the blocks since genesis but can start validating from a checkpoint.ZmnSCPxj raised concerns about the incentives for stamped transactions, as users will prefer to run older versions and never upgrade to the new version that requires stamped transactions. He argued that if it is so good for the network, then it should be good for an individual user because the network is made up of individual users anyway. If individual users are not incentivized to use it, then that fact suggests it might not be as good for the network as one might think.In summary, Mostafa suggests decoupling transactions from the block to keep the blockchain size small. However, ZmnSCPxj argues that stamped transactions are not a solution to reduce the blockchain size. The reason why old history is retained is to prove to new nodes that one is the correct owner of the current coins. This is what separates Bitcoin from previous currency systems. Stamped transactions will require a hardfork, which is risky and unlikely to be accepted by everyone. Moreover, validation becomes more expensive as the blockchain grows. Stamped transactions are larger and more expensive than unstamped transactions, making them less incentivized. Users may prefer running older versions and never upgrading to the new version that requires stamped transactions. Furthermore, validating the stamp on every node is still a cost, and it is an incentive problem if individual users are not incentivized to use it. Stamping transactions does not help reduce mempool size as resending the transaction with a fresh stamp increases bandwidth usage. The article discusses the idea of stamping transactions to keep the size of the blockchain as small as possible. However, it is argued that stamping transaction is not how one can be able to keep blockchain size low since very old history is retained to prove that you are the correct owner of the current coins when starting a new node. The proposal would require a hardfork and validation is expected to become more expensive as the blockchain grows. Stamped transactions are more expensive than unstamped transactions due to their larger size. This creates an incentives problem because users will prefer to run older versions and never upgrade to the new version that requires stamped transactions. Finally, it is pointed out that the stamp does not reduce mempool size and re-sending the same transaction with a fresh stamp increases bandwidth use.The proposed mechanism can be made into a softfork by using an unspendable `scriptPubKey` with 0 output value. For instance, a stamp could be any 0-value output whose `scriptPubKey` is `OP_0`, which should be unspendable. Post-softfork nodes would reject blocks where some transaction is stamped and the stamped `` is not within the last N blocks. Block validation now needs to memorize the last N block hashes. The mempool design currently assumes that a transaction that enters the mempool is always valid unless any UTXOs it spends have been removed.If transactions are stamped with a block that has dropped from the stamp TTL, there is an additional need to drop transactions from the mempool. Further, the creator of the transaction gains no advantage from the stamped transaction; it is others who gain an advantage (the 2020-06-09T14:16:27+00:00 + In a recent email exchange on the Bitcoin-dev mailing list, Mostafa Sedaghat joo proposed the idea of stamping transactions to decouple them from blocks and keep the size of the blockchain as small as possible. He argued that blockchain size matters, even though data storage is cheap and easy, and suggested that if you need a data-center to keep a copy of a blockchain, then you are far from a decentralization system.However, ZmnSCPxj countered that the entire history of Bitcoin is needed when starting a new node to prove ownership of current coins, and that existing currency systems have not only the "official" minter but also many "unofficial" minters (counterfeiters) which dilute the value of the currency. ZmnSCPxj further argued that validating the stamp is still a cost on every node, and it is that cost that needs to be reflected in pricing every byte in the transaction. He pointed out that UTXOs are retained indefinitely and that outputs in SegWit are 4x more expensive than signatures because signatures are only validated once when the transaction is queued to be put in the mempool.Mostafa Sedaghat joo suggested that the proposed mechanism could be made into a softfork by using an unspendable `scriptPubKey` with 0 output value. ZmnSCPxj countered that soft fork is not possible here since the transaction will not be saved inside the block and only tx hashes will be saved. Mostafa Sedaghat joo suggested that nodes can turn on pruning if the operator doesn't desire to keep all the transactions from the genesis block. Likewise, light clients may not keep any transaction history. He also suggested that when a new node connects to the network, it doesn't need to validate all the blocks since genesis but can start validating from a checkpoint.ZmnSCPxj raised concerns about the incentives for stamped transactions, as users will prefer to run older versions and never upgrade to the new version that requires stamped transactions. He argued that if it is so good for the network, then it should be good for an individual user because the network is made up of individual users anyway. If individual users are not incentivized to use it, then that fact suggests it might not be as good for the network as one might think.In summary, Mostafa suggests decoupling transactions from the block to keep the blockchain size small. However, ZmnSCPxj argues that stamped transactions are not a solution to reduce the blockchain size. The reason why old history is retained is to prove to new nodes that one is the correct owner of the current coins. This is what separates Bitcoin from previous currency systems. Stamped transactions will require a hardfork, which is risky and unlikely to be accepted by everyone. Moreover, validation becomes more expensive as the blockchain grows. Stamped transactions are larger and more expensive than unstamped transactions, making them less incentivized. Users may prefer running older versions and never upgrading to the new version that requires stamped transactions. Furthermore, validating the stamp on every node is still a cost, and it is an incentive problem if individual users are not incentivized to use it. Stamping transactions does not help reduce mempool size as resending the transaction with a fresh stamp increases bandwidth usage. The article discusses the idea of stamping transactions to keep the size of the blockchain as small as possible. However, it is argued that stamping transaction is not how one can be able to keep blockchain size low since very old history is retained to prove that you are the correct owner of the current coins when starting a new node. The proposal would require a hardfork and validation is expected to become more expensive as the blockchain grows. Stamped transactions are more expensive than unstamped transactions due to their larger size. This creates an incentives problem because users will prefer to run older versions and never upgrade to the new version that requires stamped transactions. Finally, it is pointed out that the stamp does not reduce mempool size and re-sending the same transaction with a fresh stamp increases bandwidth use.The proposed mechanism can be made into a softfork by using an unspendable `scriptPubKey` with 0 output value. For instance, a stamp could be any 0-value output whose `scriptPubKey` is `OP_0`, which should be unspendable. Post-softfork nodes would reject blocks where some transaction is stamped and the stamped `` is not within the last N blocks. Block validation now needs to memorize the last N block hashes. The mempool design currently assumes that a transaction that enters the mempool is always valid unless any UTXOs it spends have been removed.If transactions are stamped with a block that has dropped from the stamp TTL, there is an additional need to drop transactions from the mempool. Further, the creator of the transaction gains no advantage from the stamped transaction; it is others who gain an advantage (the - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_TLA-specification-for-Succint-Atomic-Swap.xml b/static/bitcoin-dev/June_2020/combined_TLA-specification-for-Succint-Atomic-Swap.xml index 5e34a4b252..f6706070f1 100644 --- a/static/bitcoin-dev/June_2020/combined_TLA-specification-for-Succint-Atomic-Swap.xml +++ b/static/bitcoin-dev/June_2020/combined_TLA-specification-for-Succint-Atomic-Swap.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - TLA+ specification for Succint Atomic Swap - 2023-08-02T02:14:52.610003+00:00 - - Dmitry Petukhov 2020-06-01 11:38:54+00:00 - - - Ruben Somsen 2020-05-14 11:41:32+00:00 - - - Dmitry Petukhov 2020-05-14 07:08:05+00:00 - - - Ruben Somsen 2020-05-14 05:31:13+00:00 - - - Dmitry Petukhov 2020-05-14 04:52:15+00:00 - - - Ruben Somsen 2020-05-13 19:03:17+00:00 - - - Dmitry Petukhov 2020-05-13 17:02:22+00:00 - + 2025-09-26T16:00:10.511321+00:00 + python-feedgen + + + [bitcoin-dev] TLA+ specification for Succint Atomic Swap Dmitry Petukhov + 2020-05-13T17:02:00.000Z + + + Ruben Somsen + 2020-05-13T19:03:00.000Z + + + Dmitry Petukhov + 2020-05-14T04:52:00.000Z + + + Ruben Somsen + 2020-05-14T05:31:00.000Z + + + Dmitry Petukhov + 2020-05-14T07:08:00.000Z + + + Ruben Somsen + 2020-05-14T11:41:00.000Z + + + Dmitry Petukhov + 2020-06-01T11:38:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - TLA+ specification for Succint Atomic Swap - 2023-08-02T02:14:52.610003+00:00 + 2025-09-26T16:00:10.512239+00:00 - The author has completed the specification of the Succint Atomic Swap contract in TLA+. The specification covers all relevant behaviors of the participants and even has an option to enable 'non-rational' behavior. The model is capable of exhaustively checking safety properties and temporal properties. Additionally, the model can show hyperproperties, but automatic checking of hyperproperties is not yet available. The model has some limitations, like only having one miner and not modeling fees and mempool priorities. Despite these limitations, the author believes that TLA+ is a suitable tool for specifying and checking smart contract specifications.In an email exchange, Ruben Somsen points out to Dmitry Petukhov that it is important for Bob to confirm success_tx before refund_tx_1 becomes valid. Dmitry agrees and notes that this is unlikely to be a practical problem unless the original fee of success_tx is too small. Ruben also clarifies that Alice won't give her key until she learns secretBob because step 5 comes before step 6 in the diagram. Dmitry admits that he missed this and that he now made the `signers_map` into variable that can be changed to give Bob the ability to sign for Alice. However, he warns that this will add a bunch of new transactions to the model, each Alice&Bob spend having 'Bob unilateral override' case.A conversation between Ruben Somsen and Dmitry about the Lightning Network protocol was shared. They discuss the scenario when Bob gives success_tx to a friendly miner while refund_tx_1 is in the mempool. Ruben explains that this situation would not be an issue because both Alice and Bob had to misbehave for it to happen. Bob should have published the success_tx before refund_tx_1 became valid, and Alice should have sent the revoke_tx followed by refund_tx_2, revealing her secret only after Bob could no longer claim the BTC. Dmitry notes that it's crucial that success_tx is confirmed before refund_tx_1 becomes valid, but this is unlikely to be a practical problem since only Bob can spend success_tx unless the original fee of success_tx is too small. Ruben also corrects Dmitry's assumption that Bob will receive BTC, and the LTC can be locked forever. Ruben explains that Alice would not give her key until she learned secretBob, which occurs in step 6 of the diagram. Ruben then makes a change in the model, making the `signers_map` into a variable that can be changed to give Bob the ability to sign for Alice. This change enables step 6 to be modeled, but it adds several new transactions to the model.The conversation between Ruben and Dmitry revolves around the Lightning Network protocol and its potential issues. They discuss the issue of refund transaction #1 and the success transaction becoming valid at the same time. Ruben explains that this is not an issue because Alice and Bob would both have to misbehave for it to happen. They also discuss the possibility of Bob giving the success_tx to a friendly miner while refund_tx_1 is in the mempool, which could result in Bob receiving both LTC and BTC while Alice loses her BTC. Ruben clarifies that this won't happen if either of them doesn't want it to. Finally, they discuss the cooperative spend of refund_tx #1 by Alice and Bob, which is there to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol.In an email conversation, Ruben Somsen discusses an issue with the Lightning Network where Bob can potentially invalidate a transaction and take both LTC and BTC from Alice. The issue arises due to the fact that Bob cannot wait for Alice to broadcast refund_tx_1 before broadcasting success_tx, which would allow him to invalidate refund_tx_1 and take the BTC. However, Somsen believes this is not ultimately an issue. In response to a question about the destination of Alice and Bob's cooperative spend of refund_tx#1, Somsen explains that they can spend it right away or Alice can spend it a day later, after the tx has confirmed. The Alice & Bob condition is only there to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol. Somsen clarifies that the reason Alice gives Bob her key ("Alice") in step 5 of the diagram is to deny Alice from using refund_tx_1. Finally, there is a discussion about whether Bob could just spend the Alice&Bob output of the very first "commitment" transaction that locks BTC if Alice gives him her key before he shares secretBob via success_tx.Dmitry Petukhov has created a formal specification for the Succint Atomic Swap (SAS) contract presented by Ruben Somsen, using the TLA+ specification language. The model encoded in the specification can successfully detect the violation of the 'no mutual secret knowledge' invariant when one participant bypasses mem 2020-06-01T11:38:54+00:00 + The author has completed the specification of the Succint Atomic Swap contract in TLA+. The specification covers all relevant behaviors of the participants and even has an option to enable 'non-rational' behavior. The model is capable of exhaustively checking safety properties and temporal properties. Additionally, the model can show hyperproperties, but automatic checking of hyperproperties is not yet available. The model has some limitations, like only having one miner and not modeling fees and mempool priorities. Despite these limitations, the author believes that TLA+ is a suitable tool for specifying and checking smart contract specifications.In an email exchange, Ruben Somsen points out to Dmitry Petukhov that it is important for Bob to confirm success_tx before refund_tx_1 becomes valid. Dmitry agrees and notes that this is unlikely to be a practical problem unless the original fee of success_tx is too small. Ruben also clarifies that Alice won't give her key until she learns secretBob because step 5 comes before step 6 in the diagram. Dmitry admits that he missed this and that he now made the `signers_map` into variable that can be changed to give Bob the ability to sign for Alice. However, he warns that this will add a bunch of new transactions to the model, each Alice&Bob spend having 'Bob unilateral override' case.A conversation between Ruben Somsen and Dmitry about the Lightning Network protocol was shared. They discuss the scenario when Bob gives success_tx to a friendly miner while refund_tx_1 is in the mempool. Ruben explains that this situation would not be an issue because both Alice and Bob had to misbehave for it to happen. Bob should have published the success_tx before refund_tx_1 became valid, and Alice should have sent the revoke_tx followed by refund_tx_2, revealing her secret only after Bob could no longer claim the BTC. Dmitry notes that it's crucial that success_tx is confirmed before refund_tx_1 becomes valid, but this is unlikely to be a practical problem since only Bob can spend success_tx unless the original fee of success_tx is too small. Ruben also corrects Dmitry's assumption that Bob will receive BTC, and the LTC can be locked forever. Ruben explains that Alice would not give her key until she learned secretBob, which occurs in step 6 of the diagram. Ruben then makes a change in the model, making the `signers_map` into a variable that can be changed to give Bob the ability to sign for Alice. This change enables step 6 to be modeled, but it adds several new transactions to the model.The conversation between Ruben and Dmitry revolves around the Lightning Network protocol and its potential issues. They discuss the issue of refund transaction #1 and the success transaction becoming valid at the same time. Ruben explains that this is not an issue because Alice and Bob would both have to misbehave for it to happen. They also discuss the possibility of Bob giving the success_tx to a friendly miner while refund_tx_1 is in the mempool, which could result in Bob receiving both LTC and BTC while Alice loses her BTC. Ruben clarifies that this won't happen if either of them doesn't want it to. Finally, they discuss the cooperative spend of refund_tx #1 by Alice and Bob, which is there to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol.In an email conversation, Ruben Somsen discusses an issue with the Lightning Network where Bob can potentially invalidate a transaction and take both LTC and BTC from Alice. The issue arises due to the fact that Bob cannot wait for Alice to broadcast refund_tx_1 before broadcasting success_tx, which would allow him to invalidate refund_tx_1 and take the BTC. However, Somsen believes this is not ultimately an issue. In response to a question about the destination of Alice and Bob's cooperative spend of refund_tx#1, Somsen explains that they can spend it right away or Alice can spend it a day later, after the tx has confirmed. The Alice & Bob condition is only there to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol. Somsen clarifies that the reason Alice gives Bob her key ("Alice") in step 5 of the diagram is to deny Alice from using refund_tx_1. Finally, there is a discussion about whether Bob could just spend the Alice&Bob output of the very first "commitment" transaction that locks BTC if Alice gives him her key before he shares secretBob via success_tx.Dmitry Petukhov has created a formal specification for the Succint Atomic Swap (SAS) contract presented by Ruben Somsen, using the TLA+ specification language. The model encoded in the specification can successfully detect the violation of the 'no mutual secret knowledge' invariant when one participant bypasses mem - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Tainting-CoinJoin-PayJoin-CoinSwap.xml b/static/bitcoin-dev/June_2020/combined_Tainting-CoinJoin-PayJoin-CoinSwap.xml index 64f2967145..d3e247c59e 100644 --- a/static/bitcoin-dev/June_2020/combined_Tainting-CoinJoin-PayJoin-CoinSwap.xml +++ b/static/bitcoin-dev/June_2020/combined_Tainting-CoinJoin-PayJoin-CoinSwap.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Tainting, CoinJoin, PayJoin, CoinSwap - 2023-08-02T02:22:33.024606+00:00 - - nopara73 2020-06-11 11:20:56+00:00 - - - Mr. Lee Chiffre 2020-06-11 02:01:41+00:00 - - - ZmnSCPxj 2020-06-10 23:01:46+00:00 - - - Chris Belcher 2020-06-10 20:10:19+00:00 - - - Greg Sanders 2020-06-10 13:48:55+00:00 - - - nopara73 2020-06-10 12:32:05+00:00 - + 2025-09-26T16:00:14.780182+00:00 + python-feedgen + + + [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap nopara73 + 2020-06-10T12:32:00.000Z + + + Greg Sanders + 2020-06-10T13:48:00.000Z + + + Chris Belcher + 2020-06-10T20:10:00.000Z + + + ZmnSCPxj + 2020-06-10T23:01:00.000Z + + + Mr. Lee Chiffre + 2020-06-11T02:01:00.000Z + + + nopara73 + 2020-06-11T11:20:00.000Z + + - python-feedgen + 2 Combined summary - Tainting, CoinJoin, PayJoin, CoinSwap - 2023-08-02T02:22:33.024606+00:00 + 2025-09-26T16:00:14.781028+00:00 - Bitcoin's fungibility and the discrimination between "clean" and "dirty" Bitcoins are under discussion. A user argues that Bitcoin should be designed without this distinction, as fungibility is crucial. They emphasize the importance of Bitcoin remaining neutral and independent of government control, serving as censorship-resistant money to provide freedom from tyranny. The use of protocols such as CoinJoin, CoinSwap, and PayJoin can offer plausible deniability to blockchain analysis entities, making it challenging for them to determine transaction nature. The user suggests that if "dirty" Bitcoins exist, anyone could pollute random addresses, making it impossible to prove self-transfer or unsolicited donation. UTXO censorship would not work, as customers can opt for services that respect freedom and avoid censorship.The author believes that Bitcoin should be designed to eliminate differentiation between "clean" and "dirty" Bitcoins, prioritizing fungibility. They argue that the distinction between these types of coins is defined by the ruling government, emphasizing Bitcoin's need to remain neutral and independent. Bitcoin's purpose is to act as censorship-resistant money, granting people freedom from tyranny. The author asserts that if anyone can determine a Bitcoin's cleanliness, something is amiss. Protocols like CoinJoin, CoinSwap, and PayJoin offer plausible deniability, spreading the entire "taint" collectively and hindering UTXO censorship. Customers can choose services that uphold freedom and refrain from censorship. Overall, the author advocates for designing Bitcoin to retain neutrality, independence from government control, and fungibility.The context explores taint analysis in Bitcoin transactions and strategies to resist it through involvement of other parts of the Bitcoin economy. Tainted coins possess less value compared to untainted ones, but taint is not universally agreed upon among Bitcoin users. Those attempting to impose taint globally face economic barriers due to limited reach, leading to jurisdictional arbitrage. Censorship resistance is crucial in thwarting global attackers who impose non-consensual taint views. CoinJoin and CoinSwap enhance censorship resistance by aggregating multiple UTXOs and creating new ones with shared taint, thereby spreading it. These protocols improve global resistance against potential global attackers using taint analysis.An email thread on bitcoin-dev highlights the flaws of CoinJoin, PayJoin, and CoinSwap concerning taint analysis. Taint analysis associates specific Bitcoin addresses with particular activities to attack privacy protocols. Coins are categorized as "clean," "dirty," or "suspicious." CoinJoins change a coin's history from clean to suspicious, increasing the risk of targeting by adversaries. PayJoin and CoinSwap do not signal a user's privacy preference, but they may still raise suspicion if the taint analysis algorithm tracks privacy protocol transactions. Involving other parts of the Bitcoin economy in transactions can resist taint analysis attacks. Using Bitcoin as money, earning it, spending it with merchants, who further spend it with others or pay employees, without taint analysis algorithms, offers protection. While unobservable privacy improves privacy and prevents censorship, it may not be a permanent solution to taint analysis. Utilizing Bitcoin as money away from censoring centralized choke points is the only lasting remedy.The author suggests that "super-clusters" can disrupt common input heuristics, making chain analysis techniques challenging for enforcement purposes. Adversaries deem CoinJoins suspicious, while PayJoin and CoinSwap go unnoticed. The author argues that the desire for privacy is assumed to be suspicious, but protocols or social changes could address the taint issue. They propose that PJ/CS does not solve the problem but alters it, leading to similar issues for users. Therefore, a protocol or social change may be necessary to tackle privacy concerns.CoinJoins explicitly convey the desire for privacy, making them suspicious to adversaries. In contrast, PayJoin and CoinSwap remain undetectable, solving this problem. However, this logic does not hold under scrutiny. Coin histories can be clean, dirty, or suspicious, and using a dirty or suspicious coin attracts unwanted attention. If starting with a clean history, CoinJoins render the new coin's history suspicious, eliminating the incentive to use it. With CoinSwap/PayJoin, the new coin can be clean or dirty, but risks persist. Starting with a dirty history, CoinJoins become more appealing as they make the new coin's history suspicious. Yet, CoinSwap/PayJoin still pose risks, potentially implicating users in unrelated dirty coins. Full adoption of any technique resolves the tainting issue, but PJ/CS does not ultimately solve it. Attaining unobservable privacy may be fallacious, necessitating protocol or social changes for tackling taint issues. 2020-06-11T11:20:56+00:00 + Bitcoin's fungibility and the discrimination between "clean" and "dirty" Bitcoins are under discussion. A user argues that Bitcoin should be designed without this distinction, as fungibility is crucial. They emphasize the importance of Bitcoin remaining neutral and independent of government control, serving as censorship-resistant money to provide freedom from tyranny. The use of protocols such as CoinJoin, CoinSwap, and PayJoin can offer plausible deniability to blockchain analysis entities, making it challenging for them to determine transaction nature. The user suggests that if "dirty" Bitcoins exist, anyone could pollute random addresses, making it impossible to prove self-transfer or unsolicited donation. UTXO censorship would not work, as customers can opt for services that respect freedom and avoid censorship.The author believes that Bitcoin should be designed to eliminate differentiation between "clean" and "dirty" Bitcoins, prioritizing fungibility. They argue that the distinction between these types of coins is defined by the ruling government, emphasizing Bitcoin's need to remain neutral and independent. Bitcoin's purpose is to act as censorship-resistant money, granting people freedom from tyranny. The author asserts that if anyone can determine a Bitcoin's cleanliness, something is amiss. Protocols like CoinJoin, CoinSwap, and PayJoin offer plausible deniability, spreading the entire "taint" collectively and hindering UTXO censorship. Customers can choose services that uphold freedom and refrain from censorship. Overall, the author advocates for designing Bitcoin to retain neutrality, independence from government control, and fungibility.The context explores taint analysis in Bitcoin transactions and strategies to resist it through involvement of other parts of the Bitcoin economy. Tainted coins possess less value compared to untainted ones, but taint is not universally agreed upon among Bitcoin users. Those attempting to impose taint globally face economic barriers due to limited reach, leading to jurisdictional arbitrage. Censorship resistance is crucial in thwarting global attackers who impose non-consensual taint views. CoinJoin and CoinSwap enhance censorship resistance by aggregating multiple UTXOs and creating new ones with shared taint, thereby spreading it. These protocols improve global resistance against potential global attackers using taint analysis.An email thread on bitcoin-dev highlights the flaws of CoinJoin, PayJoin, and CoinSwap concerning taint analysis. Taint analysis associates specific Bitcoin addresses with particular activities to attack privacy protocols. Coins are categorized as "clean," "dirty," or "suspicious." CoinJoins change a coin's history from clean to suspicious, increasing the risk of targeting by adversaries. PayJoin and CoinSwap do not signal a user's privacy preference, but they may still raise suspicion if the taint analysis algorithm tracks privacy protocol transactions. Involving other parts of the Bitcoin economy in transactions can resist taint analysis attacks. Using Bitcoin as money, earning it, spending it with merchants, who further spend it with others or pay employees, without taint analysis algorithms, offers protection. While unobservable privacy improves privacy and prevents censorship, it may not be a permanent solution to taint analysis. Utilizing Bitcoin as money away from censoring centralized choke points is the only lasting remedy.The author suggests that "super-clusters" can disrupt common input heuristics, making chain analysis techniques challenging for enforcement purposes. Adversaries deem CoinJoins suspicious, while PayJoin and CoinSwap go unnoticed. The author argues that the desire for privacy is assumed to be suspicious, but protocols or social changes could address the taint issue. They propose that PJ/CS does not solve the problem but alters it, leading to similar issues for users. Therefore, a protocol or social change may be necessary to tackle privacy concerns.CoinJoins explicitly convey the desire for privacy, making them suspicious to adversaries. In contrast, PayJoin and CoinSwap remain undetectable, solving this problem. However, this logic does not hold under scrutiny. Coin histories can be clean, dirty, or suspicious, and using a dirty or suspicious coin attracts unwanted attention. If starting with a clean history, CoinJoins render the new coin's history suspicious, eliminating the incentive to use it. With CoinSwap/PayJoin, the new coin can be clean or dirty, but risks persist. Starting with a dirty history, CoinJoins become more appealing as they make the new coin's history suspicious. Yet, CoinSwap/PayJoin still pose risks, potentially implicating users in unrelated dirty coins. Full adoption of any technique resolves the tainting issue, but PJ/CS does not ultimately solve it. Attaining unobservable privacy may be fallacious, necessitating protocol or social changes for tackling taint issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_Time-dilation-Attacks-on-the-Lightning-Network.xml b/static/bitcoin-dev/June_2020/combined_Time-dilation-Attacks-on-the-Lightning-Network.xml index 8b56e734e4..3c26db524d 100644 --- a/static/bitcoin-dev/June_2020/combined_Time-dilation-Attacks-on-the-Lightning-Network.xml +++ b/static/bitcoin-dev/June_2020/combined_Time-dilation-Attacks-on-the-Lightning-Network.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Time-dilation Attacks on the Lightning Network - 2023-08-02T02:20:47.539059+00:00 - - Antoine Riard 2020-06-11 09:21:48+00:00 - - - ZmnSCPxj 2020-06-10 23:34:53+00:00 - - - Aymeric Vitte 2020-06-08 16:43:27+00:00 - - - ZmnSCPxj 2020-06-08 04:56:56+00:00 - - - Antoine Riard 2020-06-07 22:31:54+00:00 - - - Aymeric Vitte 2020-06-05 15:41:48+00:00 - - - ZmnSCPxj 2020-06-05 11:44:53+00:00 - - - Aymeric Vitte 2020-06-05 10:10:20+00:00 - - - ZmnSCPxj 2020-06-04 02:58:24+00:00 - - - Gleb Naumenko 2020-06-03 16:20:09+00:00 - + 2025-09-26T15:59:57.725362+00:00 + python-feedgen + + + [bitcoin-dev] Time-dilation Attacks on the Lightning Network Gleb Naumenko + 2020-06-03T16:20:00.000Z + + + ZmnSCPxj + 2020-06-04T02:58:00.000Z + + + Aymeric Vitte + 2020-06-05T10:10:00.000Z + + + ZmnSCPxj + 2020-06-05T11:44:00.000Z + + + Aymeric Vitte + 2020-06-05T15:41:00.000Z + + + Antoine Riard + 2020-06-07T22:31:00.000Z + + + ZmnSCPxj + 2020-06-08T04:56:00.000Z + + + Aymeric Vitte + 2020-06-08T16:43:00.000Z + + + ZmnSCPxj + 2020-06-10T23:34:00.000Z + + + Antoine Riard + 2020-06-11T09:21:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Time-dilation Attacks on the Lightning Network - 2023-08-02T02:20:47.540061+00:00 + 2025-09-26T15:59:57.726682+00:00 - Antoine proposed an AltNet+Watchdog proposal in Core that covers the need for a driver framework to plug alternative transport protocols such as radio, DNS, LN Noise, and Tor's Snowflake. The proposal is more generic than just pure LN as privacy-concerned users may want to broadcast their transactions over radio.ZmnSCPxj suggested having a separate software daemon that performs de-eclipsing for Bitcoin full nodes. This deeclipser can use a plugin system and isolate the plugins from the main fullnode software. The P2P protocol can be used so that the fullnode run could be a non-Bitcoin-Core fullnode, such as btcd or rust-bitcoin.A recent discussion on bitcoin-dev highlighted the issue of running both Bitcoin and Lightning nodes on clearnet, which increases their vulnerability to attacks. Running Lightning on Tor could prevent linking, although there is still a possibility of being linked by on-chain transaction monitoring. It was also pointed out that running mixed Bitcoin and/or LN nodes in clearnet and Tor is not difficult for a Tor attacker to identify.The issue of eclipsing Bitcoin nodes being risky has been raised, with a recommendation to mitigate it by running a Bitcoin fullnode on clearnet and a Lightning node over Tor. Checking that absolute timelocks are far in the future compared to the current blockheight is another way to determine if an incoming payment violates the max CLTV. Different types of node eclipses require different mitigations.The research presented in the email thread discusses a time-dilation attack on concurrent transactions that use timelocks. The attack can be performed with just one channel to the victim. The suggestion is to run the Bitcoin node on clearnet and the Lightning node over Tor and connect to random Bitcoin full nodes or Electrum servers.The discussion in this context is about the proposal of a decentralized anonymizer network, which is different from the Tor network. The proposal suggests making a bridge between Tor and clearnet by running two full nodes on the computer. The Tor-fullnode can be used to propagate transactions, but the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic.The Tor network's dependence on a limited set of exit nodes weakens its security. However, Tor hidden services provide good within-Tor rendezvous points. One solution could be to make a bridge between Tor and clearnet by running two fullnodes on the computer. This method would help propagate transactions through the Tor-fullnode while maintaining privacy. However, the eclipse attacker could still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.In a discussion on bitcoin-dev mailing list, ZmnSCPxj suggested running Bitcoin fullnode on clearnet while running Lightning node over Tor to mitigate the issue of eclipsing of Bitcoin nodes. However, there is a risk of correlation between the Lightning node and the Bitcoin node when transactions are broadcast with the attached Bitcoin node. The idea of using Tor network for bitcoin was dismissed as it is based on a wrong postulate.The article discusses an attack on the Lightning Network that targets per-hop packet delay. The attacker routes via the victim, who should have at least two channels with the attacker. The article also suggests running a Bitcoin full node on clearnet while running a Lightning node over Tor as a mitigation strategy to prevent eclipsing of Bitcoin nodes.Gleb Naumenko and Antoine Riard have explored time-dilation attacks on Lightning and written a blog post and paper detailing their findings. The post discusses how an attacker can steal funds from LN users using time-dilation attacks. The authors demonstrate three ways the attacker can steal funds and discuss countermeasures which may increase the attack cost. 2020-06-11T09:21:48+00:00 + Antoine proposed an AltNet+Watchdog proposal in Core that covers the need for a driver framework to plug alternative transport protocols such as radio, DNS, LN Noise, and Tor's Snowflake. The proposal is more generic than just pure LN as privacy-concerned users may want to broadcast their transactions over radio.ZmnSCPxj suggested having a separate software daemon that performs de-eclipsing for Bitcoin full nodes. This deeclipser can use a plugin system and isolate the plugins from the main fullnode software. The P2P protocol can be used so that the fullnode run could be a non-Bitcoin-Core fullnode, such as btcd or rust-bitcoin.A recent discussion on bitcoin-dev highlighted the issue of running both Bitcoin and Lightning nodes on clearnet, which increases their vulnerability to attacks. Running Lightning on Tor could prevent linking, although there is still a possibility of being linked by on-chain transaction monitoring. It was also pointed out that running mixed Bitcoin and/or LN nodes in clearnet and Tor is not difficult for a Tor attacker to identify.The issue of eclipsing Bitcoin nodes being risky has been raised, with a recommendation to mitigate it by running a Bitcoin fullnode on clearnet and a Lightning node over Tor. Checking that absolute timelocks are far in the future compared to the current blockheight is another way to determine if an incoming payment violates the max CLTV. Different types of node eclipses require different mitigations.The research presented in the email thread discusses a time-dilation attack on concurrent transactions that use timelocks. The attack can be performed with just one channel to the victim. The suggestion is to run the Bitcoin node on clearnet and the Lightning node over Tor and connect to random Bitcoin full nodes or Electrum servers.The discussion in this context is about the proposal of a decentralized anonymizer network, which is different from the Tor network. The proposal suggests making a bridge between Tor and clearnet by running two full nodes on the computer. The Tor-fullnode can be used to propagate transactions, but the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic.The Tor network's dependence on a limited set of exit nodes weakens its security. However, Tor hidden services provide good within-Tor rendezvous points. One solution could be to make a bridge between Tor and clearnet by running two fullnodes on the computer. This method would help propagate transactions through the Tor-fullnode while maintaining privacy. However, the eclipse attacker could still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.In a discussion on bitcoin-dev mailing list, ZmnSCPxj suggested running Bitcoin fullnode on clearnet while running Lightning node over Tor to mitigate the issue of eclipsing of Bitcoin nodes. However, there is a risk of correlation between the Lightning node and the Bitcoin node when transactions are broadcast with the attached Bitcoin node. The idea of using Tor network for bitcoin was dismissed as it is based on a wrong postulate.The article discusses an attack on the Lightning Network that targets per-hop packet delay. The attacker routes via the victim, who should have at least two channels with the attacker. The article also suggests running a Bitcoin full node on clearnet while running a Lightning node over Tor as a mitigation strategy to prevent eclipsing of Bitcoin nodes.Gleb Naumenko and Antoine Riard have explored time-dilation attacks on Lightning and written a blog post and paper detailing their findings. The post discusses how an attacker can steal funds from LN users using time-dilation attacks. The authors demonstrate three ways the attacker can steal funds and discuss countermeasures which may increase the attack cost. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2020/combined_WabiSabi-Inside-Batched-CoinSwap.xml b/static/bitcoin-dev/June_2020/combined_WabiSabi-Inside-Batched-CoinSwap.xml index 286560a9c8..af7efcc277 100644 --- a/static/bitcoin-dev/June_2020/combined_WabiSabi-Inside-Batched-CoinSwap.xml +++ b/static/bitcoin-dev/June_2020/combined_WabiSabi-Inside-Batched-CoinSwap.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - WabiSabi Inside Batched CoinSwap - 2023-08-02T02:23:43.570519+00:00 - - ZmnSCPxj 2020-06-12 14:53:59+00:00 - - - ZmnSCPxj 2020-06-12 05:43:29+00:00 - + 2025-09-26T15:59:53.492674+00:00 + python-feedgen + + + [bitcoin-dev] WabiSabi Inside Batched CoinSwap ZmnSCPxj + 2020-06-12T05:43:00.000Z + + + ZmnSCPxj + 2020-06-12T14:53:00.000Z + + - python-feedgen + 2 Combined summary - WabiSabi Inside Batched CoinSwap - 2023-08-02T02:23:43.570519+00:00 + 2025-09-26T15:59:53.493181+00:00 - In a cryptocurrency transaction scenario, Alice initiates the process by creating an unsigned funding transaction with MuSig(Alice, Macky). Following this, Alice and Macky collaborate to create a backout transaction with `nLockTime` set at L2. The MuSig signing ritual is completed before Alice broadcasts the original funding transaction. However, it has come to light that the taker funding transactions should have a closer locktime, referred to as L1, whereas the maker funding transactions should have a later locktime, denoted as L2. This modification requires Macky to claim the incoming funds earlier, consequently unlocking the outgoing payout transaction upon claiming.The WabiSabi protocol, although innovative, lacks proven security and privacy. While WabiSabi intends to enable CoinJoin operations, it creates a transaction where the inputs are linked to the outputs, which is not ideal. A more favorable solution would involve employing CoinSwap and the new swap scheme called Succinct Atomic Swaps, which effectively addresses this issue. By utilizing Batched CoinSwap, makers can serve as WabiSabi servers, while batched takers can act as WabiSabi clients. However, naive CoinSwap necessitates that outputs from the maker be linkable, at least by the maker, to the inputs provided, which contradicts the purpose of WabiSabi in hiding such information from the server. To overcome this, we propose using Signature Selling as the foundation for atomic CoinSwap.In the proposed system, WabiSabi replaces blind signatures with credentials. The notable advantage of credentials lies in their ability to incorporate a homomorphic value, which allows for the representation of a blinded amount. The WabiSabi process involves a single server responsible for issuing credentials and multiple clients whom the server serves. Clients can facilitate value exchange by swapping credentials, subsequently claiming the received credentials and exchanging them for fresh ones.In the context of Batched CoinSwap, Macky takes on the role of a WabiSabi server, while Alice, Bob, and Carol function as WabiSabi clients. Rather than generating a single CoinJoin transaction, they opt for a CoinSwap operation. To initiate this process, all parties agree upon future block heights L1 and L2, where L1 denotes the timelock for the maker's funds and L2 represents the timelock for the takers' funds. Subsequently, they proceed with creating the CoinSwap transaction, which involves several steps.To ensure that the CoinSwap can transpire without the maker being able to link outputs to inputs, this proposal employs the Signature Selling technique. By adopting this approach, the privacy and security objectives of WabiSabi are maintained while facilitating successful CoinSwaps. 2020-06-12T14:53:59+00:00 + In a cryptocurrency transaction scenario, Alice initiates the process by creating an unsigned funding transaction with MuSig(Alice, Macky). Following this, Alice and Macky collaborate to create a backout transaction with `nLockTime` set at L2. The MuSig signing ritual is completed before Alice broadcasts the original funding transaction. However, it has come to light that the taker funding transactions should have a closer locktime, referred to as L1, whereas the maker funding transactions should have a later locktime, denoted as L2. This modification requires Macky to claim the incoming funds earlier, consequently unlocking the outgoing payout transaction upon claiming.The WabiSabi protocol, although innovative, lacks proven security and privacy. While WabiSabi intends to enable CoinJoin operations, it creates a transaction where the inputs are linked to the outputs, which is not ideal. A more favorable solution would involve employing CoinSwap and the new swap scheme called Succinct Atomic Swaps, which effectively addresses this issue. By utilizing Batched CoinSwap, makers can serve as WabiSabi servers, while batched takers can act as WabiSabi clients. However, naive CoinSwap necessitates that outputs from the maker be linkable, at least by the maker, to the inputs provided, which contradicts the purpose of WabiSabi in hiding such information from the server. To overcome this, we propose using Signature Selling as the foundation for atomic CoinSwap.In the proposed system, WabiSabi replaces blind signatures with credentials. The notable advantage of credentials lies in their ability to incorporate a homomorphic value, which allows for the representation of a blinded amount. The WabiSabi process involves a single server responsible for issuing credentials and multiple clients whom the server serves. Clients can facilitate value exchange by swapping credentials, subsequently claiming the received credentials and exchanging them for fresh ones.In the context of Batched CoinSwap, Macky takes on the role of a WabiSabi server, while Alice, Bob, and Carol function as WabiSabi clients. Rather than generating a single CoinJoin transaction, they opt for a CoinSwap operation. To initiate this process, all parties agree upon future block heights L1 and L2, where L1 denotes the timelock for the maker's funds and L2 represents the timelock for the takers' funds. Subsequently, they proceed with creating the CoinSwap transaction, which involves several steps.To ensure that the CoinSwap can transpire without the maker being able to link outputs to inputs, this proposal employs the Signature Selling technique. By adopting this approach, the privacy and security objectives of WabiSabi are maintained while facilitating successful CoinSwaps. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml b/static/bitcoin-dev/June_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml index 4ff223f3d4..4148b513db 100644 --- a/static/bitcoin-dev/June_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml +++ b/static/bitcoin-dev/June_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent - 2023-08-02T03:56:08.130121+00:00 - - Antoine Riard 2021-07-12 00:02:12+00:00 - - - Anthony Towns 2021-07-10 01:47:32+00:00 - - - Antoine Riard 2021-07-09 13:19:45+00:00 - - - Anthony Towns 2021-07-08 11:17:16+00:00 - - - Lloyd Fournier 2021-06-15 03:08:37+00:00 - - - Lloyd Fournier 2021-06-15 00:59:12+00:00 - - - Antoine Riard 2021-06-14 17:18:38+00:00 - - - Antoine Riard 2021-06-14 16:46:56+00:00 - - - Jeremy 2021-06-13 14:16:24+00:00 - - - Lloyd Fournier 2021-06-13 05:56:43+00:00 - - - darosior 2021-06-10 22:47:04+00:00 - - - Antoine Riard 2021-06-10 21:45:04+00:00 - - - Antoine Riard 2021-06-10 21:16:43+00:00 - - - darosior 2021-06-10 13:18:53+00:00 - - - Lloyd Fournier 2021-06-07 02:27:36+00:00 - - - darosior 2021-05-28 22:25:16+00:00 - - - Antoine Riard 2021-05-28 04:13:44+00:00 - - - darosior 2021-05-27 21:45:35+00:00 - - - Antoine Riard 2021-05-27 20:14:13+00:00 - + 2025-09-26T15:39:38.972523+00:00 + python-feedgen + + + [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent Antoine Riard + 2021-05-27T20:14:00.000Z + + + darosior + 2021-05-27T21:45:00.000Z + + + Antoine Riard + 2021-05-28T04:13:00.000Z + + + darosior + 2021-05-28T22:25:00.000Z + + + Lloyd Fournier + 2021-06-07T02:27:00.000Z + + + darosior + 2021-06-10T13:18:00.000Z + + + Antoine Riard + 2021-06-10T21:16:00.000Z + + + Antoine Riard + 2021-06-10T21:45:00.000Z + + + darosior + 2021-06-10T22:47:00.000Z + + + Lloyd Fournier + 2021-06-13T05:56:00.000Z + + + Jeremy + 2021-06-13T14:16:00.000Z + + + Antoine Riard + 2021-06-14T16:46:00.000Z + + + Antoine Riard + 2021-06-14T17:18:00.000Z + + + Lloyd Fournier + 2021-06-15T00:59:00.000Z + + + Lloyd Fournier + 2021-06-15T03:08:00.000Z + + + Anthony Towns + 2021-07-08T11:17:00.000Z + + + Antoine Riard + 2021-07-09T13:19:00.000Z + + + Anthony Towns + 2021-07-10T01:47:00.000Z + + + Antoine Riard + 2021-07-12T00:02:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent - 2023-08-02T03:56:08.130121+00:00 + 2025-09-26T15:39:38.974741+00:00 - In a recent Bitcoin-dev mailing list discussion, there was a proposal to introduce a new SIGHASH_GROUP flag to improve transaction processing efficiency and avoid O(n^2) behavior. The proposal suggests grouping transactions together using the annex field "sig_group_count" and hashing only the relevant outputs when evaluating an input. This optimization aims to reduce overhead and improve transaction signing. The proposal provides an example of combining transactions in the Lightning network to illustrate how the SIGHASH_GROUP flag would work. However, it notes that there may be limitations when certain outputs collide on the absolute output position.Another topic discussed in the email thread is the possibility of introducing more advanced sighash malleability flags, such as SIGHASH_IOMAP, which would allow transaction signers to commit to a map of inputs and outputs. However, concerns were raised about theft possibilities, heaviness of range specification, and quadratic behavior.The discussion also explores a single-party managed fee-bumping system that could solve fee-bumping requirements in the Lightning network without external utxos or additional interaction between parties. This system would allow for fee adjustment by reducing the balance of a transaction or draining an output with HTLC or PTLC. The proposal suggests that this idea could be applied to all Bitcoin transactions, enabling efficient fee adjustments in various scenarios. The benefits and drawbacks of a sponsor-like mechanism for fee-bumping are also discussed.The conversation touches on fee-bumping techniques for second-layer protocols and proposes solutions such as the SIGHASH_ANYPREVOUT softfork proposal or tx mutation schemes. These approaches aim to address security issues and optimize fee-bumping in contract protocols with distrusting counterparties.Overall, the discussions revolve around proposals and ideas to improve transaction processing efficiency, optimize fee-bumping mechanisms, and address security concerns in various Bitcoin-related contexts, including Lightning network transactions and second-layer protocols.Another aspect discussed is input-based fee-bumping as a primitive for Layer 2 solutions. The use of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags is one variant of input-based fee-bumping, but ACP | SINGLE is easily pinable, so ACP | ALL is used for Revault. This requires a pool of fee-bumping UTXOs to be consumed entirely. The author suggests broadcasting a single fan-out transaction creating the entire UTXO pool in advance to overcome this limitation. However, sometimes the cost of many small additional inputs must be incurred. The discussion also explores the possibility of attaching the bumping input at the tail of the chain rather than targeting the root and suggests using smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP or blinded CPFP.The post compares input-based fee-bumping and CPFP techniques for second-layer protocols in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching opportunity, and mempool flexibility. CPFP requires one anchor output per participant, while input-based fee-bumping only requires one input if the bumping utxo offers an adequate feerate point. If a preliminary fan-out transaction must be broadcasted first, one input and two outputs more must be accounted for. CPFP's efficiency in tx-relay bandwidth rebroadcast relies on the assumption of bounded rationality of the participants, while input-based fee-bumping (today) breaks the chain validity and requires updating and rebroadcasting the remaining transactions beyond the updated root. However, input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP doesn't break the chain validity and could preserve the rest of the chain. For fee-bumping batching, CPFP requires one input/one output per aggregated chain, even if the child transaction fields can be shared. Input-based fee-bumping (today) requires one bumping input per chain, but transaction fields can be shared if a preliminary fan-out transaction is used. Input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP can attach one bumping input and outgoing output to the aggregated root. Regarding fee-bumping mempool flexibility, CPFP has limitations and doesn't scale beyond two contract participants, while input-based fee-bumping's acceptance is not restrained by package limits.The post concludes by mentioning future soft forks that allow significant onchain footprint savings, especially in batching, and future package relay bandwidth efficiency that should consider the rebroadcast frequency of CPFPing multi-party protocols.Overall, the conversation delves into various fee-bumping techniques, their advantages, limitations, and potential future improvements. It provides insights into the complexities and trade-offs involved in securing transactions in multi-party protocols. 2021-07-12T00:02:12+00:00 + In a recent Bitcoin-dev mailing list discussion, there was a proposal to introduce a new SIGHASH_GROUP flag to improve transaction processing efficiency and avoid O(n^2) behavior. The proposal suggests grouping transactions together using the annex field "sig_group_count" and hashing only the relevant outputs when evaluating an input. This optimization aims to reduce overhead and improve transaction signing. The proposal provides an example of combining transactions in the Lightning network to illustrate how the SIGHASH_GROUP flag would work. However, it notes that there may be limitations when certain outputs collide on the absolute output position.Another topic discussed in the email thread is the possibility of introducing more advanced sighash malleability flags, such as SIGHASH_IOMAP, which would allow transaction signers to commit to a map of inputs and outputs. However, concerns were raised about theft possibilities, heaviness of range specification, and quadratic behavior.The discussion also explores a single-party managed fee-bumping system that could solve fee-bumping requirements in the Lightning network without external utxos or additional interaction between parties. This system would allow for fee adjustment by reducing the balance of a transaction or draining an output with HTLC or PTLC. The proposal suggests that this idea could be applied to all Bitcoin transactions, enabling efficient fee adjustments in various scenarios. The benefits and drawbacks of a sponsor-like mechanism for fee-bumping are also discussed.The conversation touches on fee-bumping techniques for second-layer protocols and proposes solutions such as the SIGHASH_ANYPREVOUT softfork proposal or tx mutation schemes. These approaches aim to address security issues and optimize fee-bumping in contract protocols with distrusting counterparties.Overall, the discussions revolve around proposals and ideas to improve transaction processing efficiency, optimize fee-bumping mechanisms, and address security concerns in various Bitcoin-related contexts, including Lightning network transactions and second-layer protocols.Another aspect discussed is input-based fee-bumping as a primitive for Layer 2 solutions. The use of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags is one variant of input-based fee-bumping, but ACP | SINGLE is easily pinable, so ACP | ALL is used for Revault. This requires a pool of fee-bumping UTXOs to be consumed entirely. The author suggests broadcasting a single fan-out transaction creating the entire UTXO pool in advance to overcome this limitation. However, sometimes the cost of many small additional inputs must be incurred. The discussion also explores the possibility of attaching the bumping input at the tail of the chain rather than targeting the root and suggests using smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP or blinded CPFP.The post compares input-based fee-bumping and CPFP techniques for second-layer protocols in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching opportunity, and mempool flexibility. CPFP requires one anchor output per participant, while input-based fee-bumping only requires one input if the bumping utxo offers an adequate feerate point. If a preliminary fan-out transaction must be broadcasted first, one input and two outputs more must be accounted for. CPFP's efficiency in tx-relay bandwidth rebroadcast relies on the assumption of bounded rationality of the participants, while input-based fee-bumping (today) breaks the chain validity and requires updating and rebroadcasting the remaining transactions beyond the updated root. However, input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP doesn't break the chain validity and could preserve the rest of the chain. For fee-bumping batching, CPFP requires one input/one output per aggregated chain, even if the child transaction fields can be shared. Input-based fee-bumping (today) requires one bumping input per chain, but transaction fields can be shared if a preliminary fan-out transaction is used. Input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP can attach one bumping input and outgoing output to the aggregated root. Regarding fee-bumping mempool flexibility, CPFP has limitations and doesn't scale beyond two contract participants, while input-based fee-bumping's acceptance is not restrained by package limits.The post concludes by mentioning future soft forks that allow significant onchain footprint savings, especially in batching, and future package relay bandwidth efficiency that should consider the rebroadcast frequency of CPFPing multi-party protocols.Overall, the conversation delves into various fee-bumping techniques, their advantages, limitations, and potential future improvements. It provides insights into the complexities and trade-offs involved in securing transactions in multi-party protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml b/static/bitcoin-dev/June_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml index e4285aaf6a..19965bff97 100644 --- a/static/bitcoin-dev/June_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml +++ b/static/bitcoin-dev/June_2021/combined_BIP-Proposals-for-Output-Script-Descriptors.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - BIP Proposals for Output Script Descriptors - 2023-08-02T04:16:38.460464+00:00 - - Christopher Allen 2021-08-05 20:49:43+00:00 - - - Sjors Provoost 2021-08-05 14:27:12+00:00 - - - Daniel Bayerdorffer 2021-07-04 17:56:28+00:00 - - - Craig Raw 2021-07-03 14:00:51+00:00 - - - David A. Harding 2021-07-03 10:05:40+00:00 - - - Craig Raw 2021-07-03 08:35:48+00:00 - - - Andrew Chow 2021-07-03 05:12:35+00:00 - - - David A. Harding 2021-07-03 03:24:05+00:00 - - - Andrew Chow 2021-07-02 20:05:45+00:00 - - - Andrew Chow 2021-06-29 22:35:49+00:00 - - - Christopher Allen 2021-06-29 22:22:39+00:00 - - - Andrew Chow 2021-06-29 21:14:39+00:00 - + 2025-09-26T15:39:30.525763+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposals for Output Script Descriptors Andrew Chow + 2021-06-29T21:14:00.000Z + + + Christopher Allen + 2021-06-29T22:22:00.000Z + + + Andrew Chow + 2021-06-29T22:35:00.000Z + + + Andrew Chow + 2021-07-02T20:05:00.000Z + + + David A. Harding + 2021-07-03T03:24:00.000Z + + + Andrew Chow + 2021-07-03T05:12:00.000Z + + + Craig Raw + 2021-07-03T08:35:00.000Z + + + David A. Harding + 2021-07-03T10:05:00.000Z + + + Craig Raw + 2021-07-03T14:00:00.000Z + + + Daniel Bayerdorffer + 2021-07-04T17:56:00.000Z + + + Sjors Provoost + 2021-08-05T14:27:00.000Z + + + Christopher Allen + 2021-08-05T20:49:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - BIP Proposals for Output Script Descriptors - 2023-08-02T04:16:38.461465+00:00 + 2025-09-26T15:39:30.527227+00:00 - In a discussion on the bitcoin-dev mailing list, Sjors Provoost proposed adding a birth date or minimum block height to the BIP 32 and BIP 88 standards for Hierarchical Deterministic Path Templates. He suggested using a metadata format to track this information alongside descriptors.The Airgap Wallet Community supports metadata in their UR standards, which use CBOR's tagging capability. The UR standards also provide efficient transport via QR codes or URLs. Interested parties can learn more about these standards by watching a video on Blockchain Commons Technology Overview or reading articles on URs, including guides for key material and SSKRs, as well as UR Request & Response. Additionally, there are specs available on Uniform Resources (UR) and HD Keys. For further questions, individuals can visit the Airgapped Wallet Community on GitHub.Bitcoin Core developer Andrew Chow has proposed formalizing the Output Script Descriptors in a set of 7 BIPs. These descriptors are used to describe collections of output scripts and offer a generic solution to issues with wallet backups and exports. The 7 BIPs specify various descriptors such as non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo descriptor, and opaque descriptors (raw, addr). The proposal also suggests including a birth date and metadata format to track birth data, gap limits, and other necessary information for future wallets. Another document outlines specifications for Bitcoin output script descriptors, specifically for P2WPKH and P2WSH formats (wpkh() and wsh() expressions), as well as P2PK, P2PKH, and P2SH formats (pk(), pkh(), and sh() expressions).There has been a debate on whether to use an apostrophe or 'h' in Bitcoin output script descriptors. Craig Raw argued that using an apostrophe allows for more whitespace and easier visual parsing, while David A. Harding countered that the difference in space usage is negligible and that using 'h' or 'H' avoids potential errors in shell-quoting and is more efficient for metal backups. Daniel Bayerdorffer of Numberall Stamp & Tool Co., Inc. recommended the Bitcoin Recovery Tag as a metal backup option that supports both apostrophes and 'h'. The discussion highlights the importance of considering user experience and practical considerations in the design of Bitcoin-related tools and protocols.The debate over using 'h' or an apostrophe in Bitcoin descriptors continued, with David A. Harding expressing concerns about using 'h' as it takes up more space and makes derivation paths and descriptors more difficult to read. However, Andrew Chow pointed out that the difference in space is only 0.7% and there are no issues with readability or transcription errors due to the use of a fixed character width font and checksums. Additionally, he mentioned that using apostrophes actually provides more whitespace and makes the path easier to parse visually. The real concern lies in using "-containing descriptors in a bourne-style shell, which can lead to loss of money. Ultimately, Raw agreed with Harding's points.David A. Harding proposed making "h"/"H" the preferred aliases instead of "'" in Bitcoin descriptors to improve user experience. However, Andrew Chow raised concerns about increased space usage and difficulty in reading descriptors and derivation paths. David suggested alternative options like completely eliminating "'", but it was not feasible due to widespread use of descriptors, or calculating the checksum over s/(h|H)/', which had been discussed before but not implemented due to the need for dumb checksum checkers that don't have to parse descriptors. In conclusion, the text was updated to use "h", but alternatives were still being considered.Andrew Chow has submitted a pull request to formalize Bitcoin Core's Output Script Descriptors into BIPs. The specifications are split into seven BIPs, with the first one providing general information and the rest specifying different descriptors. These descriptors offer a generic solution to issues with wallet backups by explicitly specifying script types and key derivation paths. They include non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), taproot descriptor (tr), combo descriptor, and opaque descriptors (raw, addr). Jeremy Rubin suggested collecting feedback through WIP PRs. Bitcoin Core has implemented pk(), pkh(), sh(), and tr() descriptors since version 0.17 and version 22.0.In an email exchange between Christopher Allen and Andrew Poelstra, the possibility of supporting time locks in descriptors other than 'raw' was discussed. Andrew mentioned that he expects miniscript to be a follow-up BIP that extends these descriptors and includes timelock functionality. Christopher shared a link to a document titled "Designing Multisig for Independence & Resilience" on Github, which discusses scenarios 2021-08-05T20:49:43+00:00 + In a discussion on the bitcoin-dev mailing list, Sjors Provoost proposed adding a birth date or minimum block height to the BIP 32 and BIP 88 standards for Hierarchical Deterministic Path Templates. He suggested using a metadata format to track this information alongside descriptors.The Airgap Wallet Community supports metadata in their UR standards, which use CBOR's tagging capability. The UR standards also provide efficient transport via QR codes or URLs. Interested parties can learn more about these standards by watching a video on Blockchain Commons Technology Overview or reading articles on URs, including guides for key material and SSKRs, as well as UR Request & Response. Additionally, there are specs available on Uniform Resources (UR) and HD Keys. For further questions, individuals can visit the Airgapped Wallet Community on GitHub.Bitcoin Core developer Andrew Chow has proposed formalizing the Output Script Descriptors in a set of 7 BIPs. These descriptors are used to describe collections of output scripts and offer a generic solution to issues with wallet backups and exports. The 7 BIPs specify various descriptors such as non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo descriptor, and opaque descriptors (raw, addr). The proposal also suggests including a birth date and metadata format to track birth data, gap limits, and other necessary information for future wallets. Another document outlines specifications for Bitcoin output script descriptors, specifically for P2WPKH and P2WSH formats (wpkh() and wsh() expressions), as well as P2PK, P2PKH, and P2SH formats (pk(), pkh(), and sh() expressions).There has been a debate on whether to use an apostrophe or 'h' in Bitcoin output script descriptors. Craig Raw argued that using an apostrophe allows for more whitespace and easier visual parsing, while David A. Harding countered that the difference in space usage is negligible and that using 'h' or 'H' avoids potential errors in shell-quoting and is more efficient for metal backups. Daniel Bayerdorffer of Numberall Stamp & Tool Co., Inc. recommended the Bitcoin Recovery Tag as a metal backup option that supports both apostrophes and 'h'. The discussion highlights the importance of considering user experience and practical considerations in the design of Bitcoin-related tools and protocols.The debate over using 'h' or an apostrophe in Bitcoin descriptors continued, with David A. Harding expressing concerns about using 'h' as it takes up more space and makes derivation paths and descriptors more difficult to read. However, Andrew Chow pointed out that the difference in space is only 0.7% and there are no issues with readability or transcription errors due to the use of a fixed character width font and checksums. Additionally, he mentioned that using apostrophes actually provides more whitespace and makes the path easier to parse visually. The real concern lies in using "-containing descriptors in a bourne-style shell, which can lead to loss of money. Ultimately, Raw agreed with Harding's points.David A. Harding proposed making "h"/"H" the preferred aliases instead of "'" in Bitcoin descriptors to improve user experience. However, Andrew Chow raised concerns about increased space usage and difficulty in reading descriptors and derivation paths. David suggested alternative options like completely eliminating "'", but it was not feasible due to widespread use of descriptors, or calculating the checksum over s/(h|H)/', which had been discussed before but not implemented due to the need for dumb checksum checkers that don't have to parse descriptors. In conclusion, the text was updated to use "h", but alternatives were still being considered.Andrew Chow has submitted a pull request to formalize Bitcoin Core's Output Script Descriptors into BIPs. The specifications are split into seven BIPs, with the first one providing general information and the rest specifying different descriptors. These descriptors offer a generic solution to issues with wallet backups by explicitly specifying script types and key derivation paths. They include non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), taproot descriptor (tr), combo descriptor, and opaque descriptors (raw, addr). Jeremy Rubin suggested collecting feedback through WIP PRs. Bitcoin Core has implemented pk(), pkh(), sh(), and tr() descriptors since version 0.17 and version 22.0.In an email exchange between Christopher Allen and Andrew Poelstra, the possibility of supporting time locks in descriptors other than 'raw' was discussed. Andrew mentioned that he expects miniscript to be a follow-up BIP that extends these descriptors and includes timelock functionality. Christopher shared a link to a document titled "Designing Multisig for Independence & Resilience" on Github, which discusses scenarios - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_BIP-proposal-Anti-fee-sniping-protection-with-nSequence-in-taproot-transactions-to-improve-privacy-for-off-chain-protocols.xml b/static/bitcoin-dev/June_2021/combined_BIP-proposal-Anti-fee-sniping-protection-with-nSequence-in-taproot-transactions-to-improve-privacy-for-off-chain-protocols.xml index f597482001..775703d652 100644 --- a/static/bitcoin-dev/June_2021/combined_BIP-proposal-Anti-fee-sniping-protection-with-nSequence-in-taproot-transactions-to-improve-privacy-for-off-chain-protocols.xml +++ b/static/bitcoin-dev/June_2021/combined_BIP-proposal-Anti-fee-sniping-protection-with-nSequence-in-taproot-transactions-to-improve-privacy-for-off-chain-protocols.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols - 2023-08-02T03:59:33.810647+00:00 - - Chris Belcher 2021-07-22 14:44:11+00:00 - - - Chris Belcher 2021-06-29 09:25:52+00:00 - - - Ben Carman 2021-06-28 10:55:30+00:00 - - - Chris Belcher 2021-06-10 12:56:46+00:00 - + 2025-09-26T15:39:43.149030+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols Chris Belcher + 2021-06-10T12:56:00.000Z + + + Ben Carman + 2021-06-28T10:55:00.000Z + + + Chris Belcher + 2021-06-29T09:25:00.000Z + + + Chris Belcher + 2021-07-22T14:44:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols - 2023-08-02T03:59:33.810647+00:00 + 2025-09-26T15:39:43.149674+00:00 - The author of the taproot privacy BIP proposal has created python-like pseudocode to clarify the specification based on feedback. The pseudocode incorporates the suggestion of selecting a random input instead of the first one. It is important for wallet developers to include this BIP in their implementations as it will enhance the privacy and fungibility of off-chain protocols. Additionally, it will improve incentives for miners in Bitcoin's low-inflation future. The provided pseudocode includes a function called "apply_anti_fee_sniping_fields" which sets the transaction version to 2 in accordance with bip68. If any of the transaction inputs have more than 65535 confirmations or are taproot inputs, the function sets nlocktime. Otherwise, there is a 50% chance that either nlocktime or nsequence will be chosen. If a specific condition is met and randint(10) == 0, the function sets transaction.nlocktime to max(0, transaction.nlocktime - randint(0, 99)). If not, it randomly selects an input index and sets transaction.inputs[input_index].nsequence to transaction.inputs[input_index].confirmations(). Similarly, if the condition is met and randint(10) == 0, the function sets transaction.inputs[input_index].nsequence to max(0, transaction.inputs[input_index].nsequence - randint(0, 99)).The bitcoin-dev mailing list recently discussed potential amendments to BIP68, which focuses on the use of nSequence in transaction inputs. The current proposal states that nSequence should only apply to the first input when multiple inputs are present. However, participants in the discussion highlighted complications that could arise for protocols like DLC and dual funded lightning, where input ordering is unknown until both parties reveal their inputs. To address these concerns, it was suggested that the BIP be revised to state that "at least one of the inputs of the transaction" should have nSequence applied, and on-chain wallets should randomly select an input when applying nSequence. These changes would also impact CoinJoins and transactions involving multiple parties contributing inputs.The article emphasizes the potential complications that could arise from limiting nSequence to the first input of a transaction with multiple inputs. This issue could affect protocols like DLC and dual funded lightning, where input ordering is not known until all inputs are revealed. To ensure compatibility with these protocols, it is proposed that nSequence should apply to "at least one of the inputs of the transaction" instead of just the first input.The proposal introduces a new type of wallet behavior using BIP341 taproot, which enhances anonymity for off-chain protocols utilizing point-time-locked contracts (PTLCs) such as CoinSwap, Lightning, and Discrete Log Contracts. By incorporating nSequence in taproot transactions, on-chain wallets like Bitcoin Core can improve the privacy and fungibility of bitcoin. The proposal suggests using nSequence instead of nLockTime anti-fee-sniping protection, as nSequence values are currently uncommon and would designate off-chain settlement transactions as ordinary spend transactions. It is crucial for the community and wallet developers to implement this proposal to build up the anonymity set of nSequence transactions alongside the adoption of taproot by wallets. Fee sniping poses hypothetical challenges to Bitcoin mining in a low-inflation future, and anti-fee-sniping protection using nLockTime or nSequence contributes to pushing the blockchain forward. While nLockTime is currently used, it presents absolute lock time, whereas many off-chain protocols employ relative lock times. Hence, both nLockTime and nSequence should be utilized, with wallets choosing either an nLockTime value or nSequence values to discourage fee sniping. When creating transactions involving UTXOs protected by BIP341 taproot, wallets should also include a second random branch that sets the nLockTime or nSequence value further back. This enhances privacy for transactions that are delayed after signing due to factors like high-latency mix networks. If the UTXOs being spent have more than 65535 confirmations, wallets should use nLockTime instead of nSequence. It is important to note that this proposal does not require consensus changes and can be adopted gradually by wallets. However, for greater privacy, it is recommended for software to adopt it as soon as possible during the implementation of taproot wallets. By doing so, taproot adoption will already incorporate the nSequence code. More information on this proposal can be found in the provided references. 2021-07-22T14:44:11+00:00 + The author of the taproot privacy BIP proposal has created python-like pseudocode to clarify the specification based on feedback. The pseudocode incorporates the suggestion of selecting a random input instead of the first one. It is important for wallet developers to include this BIP in their implementations as it will enhance the privacy and fungibility of off-chain protocols. Additionally, it will improve incentives for miners in Bitcoin's low-inflation future. The provided pseudocode includes a function called "apply_anti_fee_sniping_fields" which sets the transaction version to 2 in accordance with bip68. If any of the transaction inputs have more than 65535 confirmations or are taproot inputs, the function sets nlocktime. Otherwise, there is a 50% chance that either nlocktime or nsequence will be chosen. If a specific condition is met and randint(10) == 0, the function sets transaction.nlocktime to max(0, transaction.nlocktime - randint(0, 99)). If not, it randomly selects an input index and sets transaction.inputs[input_index].nsequence to transaction.inputs[input_index].confirmations(). Similarly, if the condition is met and randint(10) == 0, the function sets transaction.inputs[input_index].nsequence to max(0, transaction.inputs[input_index].nsequence - randint(0, 99)).The bitcoin-dev mailing list recently discussed potential amendments to BIP68, which focuses on the use of nSequence in transaction inputs. The current proposal states that nSequence should only apply to the first input when multiple inputs are present. However, participants in the discussion highlighted complications that could arise for protocols like DLC and dual funded lightning, where input ordering is unknown until both parties reveal their inputs. To address these concerns, it was suggested that the BIP be revised to state that "at least one of the inputs of the transaction" should have nSequence applied, and on-chain wallets should randomly select an input when applying nSequence. These changes would also impact CoinJoins and transactions involving multiple parties contributing inputs.The article emphasizes the potential complications that could arise from limiting nSequence to the first input of a transaction with multiple inputs. This issue could affect protocols like DLC and dual funded lightning, where input ordering is not known until all inputs are revealed. To ensure compatibility with these protocols, it is proposed that nSequence should apply to "at least one of the inputs of the transaction" instead of just the first input.The proposal introduces a new type of wallet behavior using BIP341 taproot, which enhances anonymity for off-chain protocols utilizing point-time-locked contracts (PTLCs) such as CoinSwap, Lightning, and Discrete Log Contracts. By incorporating nSequence in taproot transactions, on-chain wallets like Bitcoin Core can improve the privacy and fungibility of bitcoin. The proposal suggests using nSequence instead of nLockTime anti-fee-sniping protection, as nSequence values are currently uncommon and would designate off-chain settlement transactions as ordinary spend transactions. It is crucial for the community and wallet developers to implement this proposal to build up the anonymity set of nSequence transactions alongside the adoption of taproot by wallets. Fee sniping poses hypothetical challenges to Bitcoin mining in a low-inflation future, and anti-fee-sniping protection using nLockTime or nSequence contributes to pushing the blockchain forward. While nLockTime is currently used, it presents absolute lock time, whereas many off-chain protocols employ relative lock times. Hence, both nLockTime and nSequence should be utilized, with wallets choosing either an nLockTime value or nSequence values to discourage fee sniping. When creating transactions involving UTXOs protected by BIP341 taproot, wallets should also include a second random branch that sets the nLockTime or nSequence value further back. This enhances privacy for transactions that are delayed after signing due to factors like high-latency mix networks. If the UTXOs being spent have more than 65535 confirmations, wallets should use nLockTime instead of nSequence. It is important to note that this proposal does not require consensus changes and can be adopted gradually by wallets. However, for greater privacy, it is recommended for software to adopt it as soon as possible during the implementation of taproot wallets. By doing so, taproot adoption will already incorporate the nSequence code. More information on this proposal can be found in the provided references. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_BIP118-confusion-SIGHASH-NOINPUT-is-now-SIGHASH-ANYPREVOUT-i-think-.xml b/static/bitcoin-dev/June_2021/combined_BIP118-confusion-SIGHASH-NOINPUT-is-now-SIGHASH-ANYPREVOUT-i-think-.xml index e2c85414be..291efa9f9c 100644 --- a/static/bitcoin-dev/June_2021/combined_BIP118-confusion-SIGHASH-NOINPUT-is-now-SIGHASH-ANYPREVOUT-i-think-.xml +++ b/static/bitcoin-dev/June_2021/combined_BIP118-confusion-SIGHASH-NOINPUT-is-now-SIGHASH-ANYPREVOUT-i-think-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - BIP118 confusion / SIGHASH_NOINPUT is now SIGHASH_ANYPREVOUT (i think) - 2023-08-02T04:00:39.987795+00:00 - - Ryan Grant 2021-06-12 20:56:55+00:00 - - - Ryan Grant 2021-06-12 19:52:45+00:00 - + 2025-09-26T15:39:41.062897+00:00 + python-feedgen + + + [bitcoin-dev] BIP118 confusion / SIGHASH_NOINPUT is now SIGHASH_ANYPREVOUT (i think) Ryan Grant + 2021-06-12T19:52:00.000Z + + + Ryan Grant + 2021-06-12T20:56:00.000Z + + - python-feedgen + 2 Combined summary - BIP118 confusion / SIGHASH_NOINPUT is now SIGHASH_ANYPREVOUT (i think) - 2023-08-02T04:00:39.987795+00:00 + 2025-09-26T15:39:41.063386+00:00 - During a discussion on the GitHub platform, Ryan Grant raised awareness of the confusion surrounding the recent updates to the BIP118 draft. It appears that many individuals are unaware of the significant changes that have occurred since May 2019, including a name change to SIGHASH_ANYPREVOUT. The specific details of these revisions can be found in the "Revisions" section within the internal heading. Interestingly, the version in bitcoin/bips had remained unchanged since 2018 until it recently diverged and received a minor fix two months ago. Despite this update, it still utilizes the SIGHASH_NOINPUT terminology. However, with the activation of taproot, it is now widely believed that the preferred method for easing lightning network client state requirements will be SIGHASH_ANYPREVOUT. The author of the message expresses confusion as to why the updated draft of BIP118 has not gained more attention from a broader audience. For further information regarding the revisions made to the draft, additional details can be found by following the provided links on the GitHub platform. 2021-06-12T20:56:55+00:00 + During a discussion on the GitHub platform, Ryan Grant raised awareness of the confusion surrounding the recent updates to the BIP118 draft. It appears that many individuals are unaware of the significant changes that have occurred since May 2019, including a name change to SIGHASH_ANYPREVOUT. The specific details of these revisions can be found in the "Revisions" section within the internal heading. Interestingly, the version in bitcoin/bips had remained unchanged since 2018 until it recently diverged and received a minor fix two months ago. Despite this update, it still utilizes the SIGHASH_NOINPUT terminology. However, with the activation of taproot, it is now widely believed that the preferred method for easing lightning network client state requirements will be SIGHASH_ANYPREVOUT. The author of the message expresses confusion as to why the updated draft of BIP118 has not gained more attention from a broader audience. For further information regarding the revisions made to the draft, additional details can be found by following the provided links on the GitHub platform. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml b/static/bitcoin-dev/June_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml index 1c91c16afb..adc68da589 100644 --- a/static/bitcoin-dev/June_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml +++ b/static/bitcoin-dev/June_2021/combined_Boost-Bitcoin-circulation-Million-Transactions-Per-Second-with-stronger-privacy.xml @@ -1,131 +1,175 @@ - + 2 Combined summary - Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy - 2023-08-02T04:05:11.326798+00:00 - - Erik Aronesty 2022-11-02 17:30:13+00:00 - - - raymo at riseup.net 2021-08-09 20:22:57+00:00 - - - raymo at riseup.net 2021-08-09 16:22:29+00:00 - - - s7r 2021-08-09 00:03:31+00:00 - - - raymo at riseup.net 2021-08-08 09:11:42+00:00 - - - Tao Effect 2021-07-17 18:54:22+00:00 - - - raymo at riseup.net 2021-07-17 15:50:30+00:00 - - - Billy Tetrud 2021-07-07 03:20:38+00:00 - - - raymo at riseup.net 2021-07-03 08:02:09+00:00 - - - Billy Tetrud 2021-07-02 17:57:54+00:00 - - - raymo at riseup.net 2021-07-01 22:15:13+00:00 - - - Erik Aronesty 2021-07-01 20:49:16+00:00 - - - raymo at riseup.net 2021-07-01 20:11:10+00:00 - - - raymo at riseup.net 2021-06-30 12:21:27+00:00 - - - ZmnSCPxj 2021-06-29 21:42:26+00:00 - - - raymo at riseup.net 2021-06-28 19:07:40+00:00 - - - Ricardo Filipe 2021-06-28 18:05:46+00:00 - - - Alex Schoof 2021-06-28 17:58:47+00:00 - - - raymo at riseup.net 2021-06-28 17:38:10+00:00 - - - Tao Effect 2021-06-28 17:29:40+00:00 - - - raymo at riseup.net 2021-06-28 16:58:37+00:00 - - - raymo at riseup.net 2021-06-28 16:33:24+00:00 - - - ZmnSCPxj 2021-06-28 15:28:44+00:00 - - - James Hilliard 2021-06-28 11:28:13+00:00 - - - raymo at riseup.net 2021-06-28 09:52:38+00:00 - - - James Hilliard 2021-06-28 08:23:00+00:00 - - - raymo at riseup.net 2021-06-28 06:29:59+00:00 - - - ZmnSCPxj 2021-06-28 05:20:08+00:00 - - - raymo at riseup.net 2021-06-27 11:05:04+00:00 - - - ZmnSCPxj 2021-06-27 04:53:52+00:00 - - - raymo at riseup.net 2021-06-26 21:54:26+00:00 - - - Billy Tetrud 2021-06-22 18:20:51+00:00 - - - James Hilliard 2021-06-20 01:59:54+00:00 - - - ZmnSCPxj 2021-06-20 00:53:58+00:00 - - - Erik Aronesty 2021-06-19 21:14:08+00:00 - - - raymo at riseup.net 2021-06-18 20:22:08+00:00 - - - raymo at riseup.net 2021-06-18 20:00:12+00:00 - - - Alex Schoof 2021-06-18 13:44:17+00:00 - - - Erik Aronesty 2021-06-18 13:37:54+00:00 - - - Erik Aronesty 2021-06-18 01:42:39+00:00 - - - raymo at riseup.net 2021-06-16 13:44:24+00:00 - + 2025-09-26T15:39:19.935936+00:00 + python-feedgen + + + [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo + 2021-06-16T13:44:00.000Z + + + Erik Aronesty + 2021-06-18T01:42:00.000Z + + + Erik Aronesty + 2021-06-18T13:37:00.000Z + + + Alex Schoof + 2021-06-18T13:44:00.000Z + + + raymo + 2021-06-18T20:00:00.000Z + + + raymo + 2021-06-18T20:22:00.000Z + + + Erik Aronesty + 2021-06-19T21:14:00.000Z + + + ZmnSCPxj + 2021-06-20T00:53:00.000Z + + + James Hilliard + 2021-06-20T01:59:00.000Z + + + Billy Tetrud + 2021-06-22T18:20:00.000Z + + + raymo + 2021-06-26T21:54:00.000Z + + + ZmnSCPxj + 2021-06-27T04:53:00.000Z + + + raymo + 2021-06-27T11:05:00.000Z + + + ZmnSCPxj + 2021-06-28T05:20:00.000Z + + + raymo + 2021-06-28T06:29:00.000Z + + + James Hilliard + 2021-06-28T08:23:00.000Z + + + raymo + 2021-06-28T09:52:00.000Z + + + James Hilliard + 2021-06-28T11:28:00.000Z + + + ZmnSCPxj + 2021-06-28T15:28:00.000Z + + + raymo + 2021-06-28T16:33:00.000Z + + + raymo + 2021-06-28T16:58:00.000Z + + + Tao Effect + 2021-06-28T17:29:00.000Z + + + raymo + 2021-06-28T17:38:00.000Z + + + Alex Schoof + 2021-06-28T17:58:00.000Z + + + Ricardo Filipe + 2021-06-28T18:05:00.000Z + + + raymo + 2021-06-28T19:07:00.000Z + + + ZmnSCPxj + 2021-06-29T21:42:00.000Z + + + raymo + 2021-06-30T12:21:00.000Z + + + raymo + 2021-07-01T20:11:00.000Z + + + Erik Aronesty + 2021-07-01T20:49:00.000Z + + + raymo + 2021-07-01T22:15:00.000Z + + + Billy Tetrud + 2021-07-02T17:57:00.000Z + + + raymo + 2021-07-03T08:02:00.000Z + + + Billy Tetrud + 2021-07-07T03:20:00.000Z + + + raymo + 2021-07-17T15:50:00.000Z + + + Tao Effect + 2021-07-17T18:54:00.000Z + + + raymo + 2021-08-08T09:11:00.000Z + + + s7r + 2021-08-09T00:03:00.000Z + + + raymo + 2021-08-09T16:22:00.000Z + + + raymo + 2021-08-09T20:22:00.000Z + + + Erik Aronesty + 2022-11-02T17:30:00.000Z + + @@ -167,13 +211,13 @@ - python-feedgen + 2 Combined summary - Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy - 2023-08-02T04:05:11.326798+00:00 + 2025-09-26T15:39:19.940083+00:00 - Full Replace-By-Fee (RBF) is becoming the norm in the Sabu protocol, and transactions without it can be rejected. Watchtowers can prevent attacks in progress by offering an always-on watchtower service for a small fee. The Sabu state functions as another mempool, so it's important for all parties to maintain it.An email exchange between Raymo and Chris Riley discusses the uncertainty surrounding potential revenue increases under the Sabu protocol. While upgrading the Bitcoin protocol wouldn't be technically difficult, consensus on implementation changes is required. If there are difficulties with implementing changes to the Bitcoin core protocol, the Stratum protocol could be changed instead.Miners have the incentive to accept the highest fee transaction, but there is no guarantee due to the untrusted nature of the network. It is still uncertain whether miners will prefer the highest fee transaction or keep the first transaction received and drop subsequent ones.The Guarantee Transaction is created based on the Main Transaction but has no direct relation to it. Miners choose the Guarantee Transaction over other transactions spending the same UTXO(s) because it offers a notably higher fee. Bob must be online 24/7 to prevent Alice's attack from succeeding completely.The email thread also discusses a hypothetical fraudulent attack on Bitcoin's Lightning Network. This attack involves a malicious actor using already-spent inputs to defraud a creditor. Despite a higher fee in the Guarantee transaction, miners are unlikely to drop the Sabu-Killing-transaction and consider only the Guarantee transaction. The attack has a 99% chance of success, and Bob needs to be online continuously to prevent it.The email raises a question about how Bob can spend the coins he received and become an issuer in relation to another creditor, Dave. If Alice tries to defraud Bob after he spent his Sabu credit to Dave, Dave would need to hold all parent "guarantee transactions" and watch for potential fraudulent transactions.Raymo, the creator of Sabu, suggests penalties for issuers, creditors, and miners instead of a claw-back mechanism. He is actively working on realizing the Sabu protocol and Gazin wallet. The proposal is open for review and feedback on various platforms.The Sabu protocol aims to improve Bitcoin circulation, transaction processing speed (TPS), and privacy. It allows users to send and receive Bitcoin without opening channels or paying transaction fees. Transactions are recorded on the Bitcoin blockchain only in case of fraudulent activity. The protocol involves issuers who own Bitcoin and creditors who receive it in exchange for goods or services.The security model of Sabu relies on guarantee transactions to ensure creditors receive payment even in case of fraud. The protocol offers self-sovereignty and decentralized communication, with PGP encryption ensuring privacy. Wallets can add friends using email addresses or scanned public keys. Each transaction is a small money transfer with specific inputs and outputs, and creditors pay a Sabu-transaction-fee to issuers.Despite concerns about the assumptions made in the proposal and the use of email for user identification and communication, the Sabu protocol offers a promising solution to improve Bitcoin circulation, TPS, and privacy. It provides an alternative to the Lightning Network and traditional custodial solutions.In conclusion, the Sabu protocol proposes a peer-to-peer network architecture that allows for improved Bitcoin trading with enhanced privacy and self-sovereignty. It addresses concerns about cheating through guarantee transactions and offers an alternative approach to transaction processing speed. However, further evaluation and addressing of concerns are necessary for successful implementation.The author of the article suggests using email as the primary communication method for transactions, despite potential privacy concerns. They argue that email is the most neutral, free, and globally accessible option. However, this protocol does not address the issue of preventing fraud proofs. As alternatives, QR codes and device-to-device linking are proposed for adding contacts to the contact list.To improve Bitcoin's transaction per second (TPS) and privacy, a proposal has been made to create a new cryptocurrency called IOUs that would run on top of Bitcoin. However, there are concerns about preventing double-spending, network latency, and spam filters when using email as the remote procedure call mechanism. Consensus among nodes is necessary to avoid conflicts regarding the correct set of "sent notes".Another plan to enhance Bitcoin's TPS and privacy involves implementing an off-chain transaction network, as suggested by Raymo. This system guarantees security through relative fees and the cost-of-theft. It is recommended for small transactions similar to Lightning but without limits or routing protocols. More details can be found in Raymo's Medium post and Bitcointalk forum, where the community is invited to provide feedback and thoughts.In summary, various discussions have taken place regarding mining behavior, high transaction fees, and latency issues in the Bitcoin network. The vulnerability of sybil attacks and proxy attacks has also been addressed, along with suggestions for defense mechanisms. Both the Sabu protocol and Raymo's proposal aim to improve Bitcoin's TPS and 2022-11-02T17:30:13+00:00 + Full Replace-By-Fee (RBF) is becoming the norm in the Sabu protocol, and transactions without it can be rejected. Watchtowers can prevent attacks in progress by offering an always-on watchtower service for a small fee. The Sabu state functions as another mempool, so it's important for all parties to maintain it.An email exchange between Raymo and Chris Riley discusses the uncertainty surrounding potential revenue increases under the Sabu protocol. While upgrading the Bitcoin protocol wouldn't be technically difficult, consensus on implementation changes is required. If there are difficulties with implementing changes to the Bitcoin core protocol, the Stratum protocol could be changed instead.Miners have the incentive to accept the highest fee transaction, but there is no guarantee due to the untrusted nature of the network. It is still uncertain whether miners will prefer the highest fee transaction or keep the first transaction received and drop subsequent ones.The Guarantee Transaction is created based on the Main Transaction but has no direct relation to it. Miners choose the Guarantee Transaction over other transactions spending the same UTXO(s) because it offers a notably higher fee. Bob must be online 24/7 to prevent Alice's attack from succeeding completely.The email thread also discusses a hypothetical fraudulent attack on Bitcoin's Lightning Network. This attack involves a malicious actor using already-spent inputs to defraud a creditor. Despite a higher fee in the Guarantee transaction, miners are unlikely to drop the Sabu-Killing-transaction and consider only the Guarantee transaction. The attack has a 99% chance of success, and Bob needs to be online continuously to prevent it.The email raises a question about how Bob can spend the coins he received and become an issuer in relation to another creditor, Dave. If Alice tries to defraud Bob after he spent his Sabu credit to Dave, Dave would need to hold all parent "guarantee transactions" and watch for potential fraudulent transactions.Raymo, the creator of Sabu, suggests penalties for issuers, creditors, and miners instead of a claw-back mechanism. He is actively working on realizing the Sabu protocol and Gazin wallet. The proposal is open for review and feedback on various platforms.The Sabu protocol aims to improve Bitcoin circulation, transaction processing speed (TPS), and privacy. It allows users to send and receive Bitcoin without opening channels or paying transaction fees. Transactions are recorded on the Bitcoin blockchain only in case of fraudulent activity. The protocol involves issuers who own Bitcoin and creditors who receive it in exchange for goods or services.The security model of Sabu relies on guarantee transactions to ensure creditors receive payment even in case of fraud. The protocol offers self-sovereignty and decentralized communication, with PGP encryption ensuring privacy. Wallets can add friends using email addresses or scanned public keys. Each transaction is a small money transfer with specific inputs and outputs, and creditors pay a Sabu-transaction-fee to issuers.Despite concerns about the assumptions made in the proposal and the use of email for user identification and communication, the Sabu protocol offers a promising solution to improve Bitcoin circulation, TPS, and privacy. It provides an alternative to the Lightning Network and traditional custodial solutions.In conclusion, the Sabu protocol proposes a peer-to-peer network architecture that allows for improved Bitcoin trading with enhanced privacy and self-sovereignty. It addresses concerns about cheating through guarantee transactions and offers an alternative approach to transaction processing speed. However, further evaluation and addressing of concerns are necessary for successful implementation.The author of the article suggests using email as the primary communication method for transactions, despite potential privacy concerns. They argue that email is the most neutral, free, and globally accessible option. However, this protocol does not address the issue of preventing fraud proofs. As alternatives, QR codes and device-to-device linking are proposed for adding contacts to the contact list.To improve Bitcoin's transaction per second (TPS) and privacy, a proposal has been made to create a new cryptocurrency called IOUs that would run on top of Bitcoin. However, there are concerns about preventing double-spending, network latency, and spam filters when using email as the remote procedure call mechanism. Consensus among nodes is necessary to avoid conflicts regarding the correct set of "sent notes".Another plan to enhance Bitcoin's TPS and privacy involves implementing an off-chain transaction network, as suggested by Raymo. This system guarantees security through relative fees and the cost-of-theft. It is recommended for small transactions similar to Lightning but without limits or routing protocols. More details can be found in Raymo's Medium post and Bitcointalk forum, where the community is invited to provide feedback and thoughts.In summary, various discussions have taken place regarding mining behavior, high transaction fees, and latency issues in the Bitcoin network. The vulnerability of sybil attacks and proxy attacks has also been addressed, along with suggestions for defense mechanisms. Both the Sabu protocol and Raymo's proposal aim to improve Bitcoin's TPS and - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Derivation-Paths-for-Single-Key-Taproot-Scripts.xml b/static/bitcoin-dev/June_2021/combined_Derivation-Paths-for-Single-Key-Taproot-Scripts.xml index 70cf8c9c04..51e8a3cdc7 100644 --- a/static/bitcoin-dev/June_2021/combined_Derivation-Paths-for-Single-Key-Taproot-Scripts.xml +++ b/static/bitcoin-dev/June_2021/combined_Derivation-Paths-for-Single-Key-Taproot-Scripts.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Derivation Paths for Single Key Taproot Scripts - 2023-08-02T04:13:39.214209+00:00 - - Andrew Chow 2021-07-02 20:03:20+00:00 - - - Pavol Rusnak 2021-06-30 11:07:43+00:00 - - - Craig Raw 2021-06-23 08:22:48+00:00 - - - Andrew Chow 2021-06-23 01:17:01+00:00 - + 2025-09-26T15:39:15.650064+00:00 + python-feedgen + + + [bitcoin-dev] Derivation Paths for Single Key Taproot Scripts Andrew Chow + 2021-06-23T01:17:00.000Z + + + Craig Raw + 2021-06-23T08:22:00.000Z + + + Pavol Rusnak + 2021-06-30T11:07:00.000Z + + + Andrew Chow + 2021-07-02T20:03:00.000Z + + - python-feedgen + 2 Combined summary - Derivation Paths for Single Key Taproot Scripts - 2023-08-02T04:13:39.214209+00:00 + 2025-09-26T15:39:15.650721+00:00 - Andrew Chow has proposed a derivation path scheme for keys used in Taproot scripts, which is based on BIP 44 and will have the purpose level path m/86'. The derived keys should be for the Taproot internal key and then tweaked with the hash of itself as recommended by BIP 341. These keys should not be used directly as the Taproot output pubkey, and no new version bytes for extended key serialization are specified in this BIP since descriptors eliminate the need for it. Although Andrew feels that this BIP is somewhat unnecessary, it seems like it will be needed to drive adoption and implementation of Taproot into software and hardware wallets.The proposed derivation scheme aims to provide HD wallets with a common scheme to recover single key Taproot outputs. It consists of two steps to derive multiple deterministic addresses based on a BIP 32 master private key. The first step uses the same account-structure as defined in BIPs 44, 49, and 84 but with a different purpose value for the script type. The second step derives the output key used in the P2TR script from the derived public key using the method recommended in BIP 341.This BIP is not backwards compatible by design. An incompatible wallet will not discover these accounts at all, and the user will notice that something is wrong. However, since the proposed method is similar to the one used in BIPs 44, 49, and 84, it should not be difficult to implement.The document includes references to BIPs 32, 43, 44, 49, 84, and 341. The BIP is licensed under the 2-clause BSD license, and the text can be viewed on GitHub.In addition, Pavol Rusnak, the co-founder and CTO of SatoshiLabs, has proposed a new Bitcoin Improvement Proposal (BIP) that follows the pattern of his previous successful proposals, BIP43, BIP44, and BIP84. The details of the proposal have not been disclosed yet.Overall, the proposed derivation scheme for keys used in Taproot scripts aims to provide HD wallets with a common scheme to recover single key Taproot outputs. It is based on BIP 44 and is identical to BIPs 49 and 84. The purpose level path will be set to the BIP number once assigned. The derived keys should be tweaked with the hash of itself as recommended by BIP 341 and should not be used directly as the Taproot output pubkey. This BIP does not specify new version bytes for extended key serialization due to the availability of descriptors. The proposed scheme will make it easier for HD wallets to recover single key Taproot outputs and drive adoption of Taproot into software and hardware wallets. 2021-07-02T20:03:20+00:00 + Andrew Chow has proposed a derivation path scheme for keys used in Taproot scripts, which is based on BIP 44 and will have the purpose level path m/86'. The derived keys should be for the Taproot internal key and then tweaked with the hash of itself as recommended by BIP 341. These keys should not be used directly as the Taproot output pubkey, and no new version bytes for extended key serialization are specified in this BIP since descriptors eliminate the need for it. Although Andrew feels that this BIP is somewhat unnecessary, it seems like it will be needed to drive adoption and implementation of Taproot into software and hardware wallets.The proposed derivation scheme aims to provide HD wallets with a common scheme to recover single key Taproot outputs. It consists of two steps to derive multiple deterministic addresses based on a BIP 32 master private key. The first step uses the same account-structure as defined in BIPs 44, 49, and 84 but with a different purpose value for the script type. The second step derives the output key used in the P2TR script from the derived public key using the method recommended in BIP 341.This BIP is not backwards compatible by design. An incompatible wallet will not discover these accounts at all, and the user will notice that something is wrong. However, since the proposed method is similar to the one used in BIPs 44, 49, and 84, it should not be difficult to implement.The document includes references to BIPs 32, 43, 44, 49, 84, and 341. The BIP is licensed under the 2-clause BSD license, and the text can be viewed on GitHub.In addition, Pavol Rusnak, the co-founder and CTO of SatoshiLabs, has proposed a new Bitcoin Improvement Proposal (BIP) that follows the pattern of his previous successful proposals, BIP43, BIP44, and BIP84. The details of the proposal have not been disclosed yet.Overall, the proposed derivation scheme for keys used in Taproot scripts aims to provide HD wallets with a common scheme to recover single key Taproot outputs. It is based on BIP 44 and is identical to BIPs 49 and 84. The purpose level path will be set to the BIP number once assigned. The derived keys should be tweaked with the hash of itself as recommended by BIP 341 and should not be used directly as the Taproot output pubkey. This BIP does not specify new version bytes for extended key serialization due to the availability of descriptors. The proposed scheme will make it easier for HD wallets to recover single key Taproot outputs and drive adoption of Taproot into software and hardware wallets. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Last-week-s-second-IRC-workshop-on-L2-onchain-support-and-wrap-up.xml b/static/bitcoin-dev/June_2021/combined_Last-week-s-second-IRC-workshop-on-L2-onchain-support-and-wrap-up.xml index 65db18a9cc..08a10bfdd0 100644 --- a/static/bitcoin-dev/June_2021/combined_Last-week-s-second-IRC-workshop-on-L2-onchain-support-and-wrap-up.xml +++ b/static/bitcoin-dev/June_2021/combined_Last-week-s-second-IRC-workshop-on-L2-onchain-support-and-wrap-up.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Last week's second IRC workshop on L2 onchain support and wrap up - 2023-08-02T04:15:19.233258+00:00 - - Michael Folkson 2021-07-29 11:36:25+00:00 - - - Michael Folkson 2021-06-29 09:44:11+00:00 - + 2025-09-26T15:39:36.851476+00:00 + python-feedgen + + + [bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up Michael Folkson + 2021-06-29T09:44:00.000Z + + + Michael Folkson + 2021-07-29T11:36:00.000Z + + - python-feedgen + 2 Combined summary - Last week's second IRC workshop on L2 onchain support and wrap up - 2023-08-02T04:15:19.233258+00:00 + 2025-09-26T15:39:36.851926+00:00 - The recent online Sydney Socratic Seminar focused on L2 onchain support and discussed various aspects of Bitcoin Improvement Proposal (BIP) 125 RBF. The attendees explored ideas such as SIGHASH_IOMAP, fee sponsorship, and transaction mutation. They also delved into the topics of fee bumping and package relay, with a consensus that enabling two transaction packages would suffice for Lightning and DLCs. The potential benefits of package relay for L2 protocols in addressing future fee unpredictability were highlighted, with previous work by Suhas Daftuar being mentioned.Taproot and witness replacement were also discussed during the seminar. Participants noted that miniscript could assess the transaction pinning risk of a bloated witness. They further suggested that a future soft fork could utilize the annex in Taproot to inflate the fee rate of a witness. In another workshop specifically dedicated to Bitcoin package relay and fee bumping, attendees emphasized the usefulness of package relay for Layer 2 protocols. This approach can help tackle the uncertainty surrounding future fees. Previous works by Suhas Daftuar and Gloria Zhao were acknowledged in this area. The participants agreed that enabling two transaction packages would be adequate for Lightning and DLCs, although concerns were raised about the potential complexity associated with larger package sizes.The workshop also explored the option of utilizing two packages, A and B, or B and C, if supporting three transaction packages proved challenging. Furthermore, attendees suggested communicating only hints, such as fee rate hints, instead of relaying entire transactions. Witness replacement and Taproot were additional topics of discussion. It was proposed that replacing a larger witness with a smaller one could reduce transaction fees. A future soft fork could give significance to the annex in Taproot, allowing for the inflation of a witness's fee rate.To conclude the workshop, the attendees agreed that two transaction packages would adequately support currently deployed L2 protocols. Ongoing discussions are taking place regarding the deprecation of opt-in RBF and the implementation of full RBF. The participants also addressed the need for a status quo and ad hoc security incident response policy in case of cross-layer security issues. Additionally, they advised L2 protocol designers to minimize assumptions on the base layer. 2021-07-29T11:36:25+00:00 + The recent online Sydney Socratic Seminar focused on L2 onchain support and discussed various aspects of Bitcoin Improvement Proposal (BIP) 125 RBF. The attendees explored ideas such as SIGHASH_IOMAP, fee sponsorship, and transaction mutation. They also delved into the topics of fee bumping and package relay, with a consensus that enabling two transaction packages would suffice for Lightning and DLCs. The potential benefits of package relay for L2 protocols in addressing future fee unpredictability were highlighted, with previous work by Suhas Daftuar being mentioned.Taproot and witness replacement were also discussed during the seminar. Participants noted that miniscript could assess the transaction pinning risk of a bloated witness. They further suggested that a future soft fork could utilize the annex in Taproot to inflate the fee rate of a witness. In another workshop specifically dedicated to Bitcoin package relay and fee bumping, attendees emphasized the usefulness of package relay for Layer 2 protocols. This approach can help tackle the uncertainty surrounding future fees. Previous works by Suhas Daftuar and Gloria Zhao were acknowledged in this area. The participants agreed that enabling two transaction packages would be adequate for Lightning and DLCs, although concerns were raised about the potential complexity associated with larger package sizes.The workshop also explored the option of utilizing two packages, A and B, or B and C, if supporting three transaction packages proved challenging. Furthermore, attendees suggested communicating only hints, such as fee rate hints, instead of relaying entire transactions. Witness replacement and Taproot were additional topics of discussion. It was proposed that replacing a larger witness with a smaller one could reduce transaction fees. A future soft fork could give significance to the annex in Taproot, allowing for the inflation of a witness's fee rate.To conclude the workshop, the attendees agreed that two transaction packages would adequately support currently deployed L2 protocols. Ongoing discussions are taking place regarding the deprecation of opt-in RBF and the implementation of full RBF. The participants also addressed the need for a status quo and ad hoc security incident response policy in case of cross-layer security issues. Additionally, they advised L2 protocol designers to minimize assumptions on the base layer. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_OP-BEFOREBLOCKVERIFY-discussing-and-opcode-that-invalidates-a-spend-path-after-a-certain-block.xml b/static/bitcoin-dev/June_2021/combined_OP-BEFOREBLOCKVERIFY-discussing-and-opcode-that-invalidates-a-spend-path-after-a-certain-block.xml index 068858d1ee..a6e7bd35cb 100644 --- a/static/bitcoin-dev/June_2021/combined_OP-BEFOREBLOCKVERIFY-discussing-and-opcode-that-invalidates-a-spend-path-after-a-certain-block.xml +++ b/static/bitcoin-dev/June_2021/combined_OP-BEFOREBLOCKVERIFY-discussing-and-opcode-that-invalidates-a-spend-path-after-a-certain-block.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block - 2023-08-02T04:00:32.128279+00:00 - - Billy Tetrud 2021-06-13 22:12:21+00:00 - - - Billy Tetrud 2021-06-12 18:48:24+00:00 - - - Russell O'Connor 2021-06-12 15:58:29+00:00 - - - Billy Tetrud 2021-06-12 07:59:16+00:00 - - - Russell O'Connor 2021-06-11 11:43:22+00:00 - - - James MacWhyte 2021-06-11 11:12:16+00:00 - - - Billy Tetrud 2021-06-11 05:59:56+00:00 - - - Russell O'Connor 2021-06-10 23:20:19+00:00 - - - Billy Tetrud 2021-06-10 22:19:55+00:00 - - - Russell O'Connor 2021-06-10 18:35:41+00:00 - - - Billy Tetrud 2021-06-10 17:35:25+00:00 - + 2025-09-26T15:39:34.760169+00:00 + python-feedgen + + + [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block Billy Tetrud + 2021-06-10T17:35:00.000Z + + + Russell O'Connor + 2021-06-10T18:35:00.000Z + + + Billy Tetrud + 2021-06-10T22:19:00.000Z + + + Russell O'Connor + 2021-06-10T23:20:00.000Z + + + Billy Tetrud + 2021-06-11T05:59:00.000Z + + + James MacWhyte + 2021-06-11T11:12:00.000Z + + + Russell O'Connor + 2021-06-11T11:43:00.000Z + + + Billy Tetrud + 2021-06-12T07:59:00.000Z + + + Russell O'Connor + 2021-06-12T15:58:00.000Z + + + Billy Tetrud + 2021-06-12T18:48:00.000Z + + + Billy Tetrud + 2021-06-13T22:12:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block - 2023-08-02T04:00:32.128279+00:00 + 2025-09-26T15:39:34.761573+00:00 - Bitcoin developer BT has proposed a new opcode called OP_BEFOREBLOCKVERIFY (OP_BBV) that would enable switch-off transactions. This opcode would make a transaction invalid if the current block is greater than or equal to a specified block height. The purpose of this functionality is to handle expiring payments or reversible payments that require multiple transactions, but can be simplified into one transaction with OP_BBV.BT mentioned that this opcode could have applications in creating more efficient wallet vaults. However, he also acknowledged concerns about opcodes that could invalidate valid transactions. Specifically, he highlighted two potential issues: 1) the possibility of malicious actors spamming the mempool with transactions containing the opcode, and 2) the risk of "bad" reorg behavior.Regarding the first concern, BT believes that it is solvable. He suggests that software can be designed to warn users to wait for six confirmations in scenarios where a six-block reorg could reverse the transaction. By implementing this safeguard, the risk of invalidating valid transactions due to spamming can be mitigated.As for the second concern, BT argues that it is not a significant problem. He points out that users should generally wait for six confirmations before considering a transaction as final. This waiting period reduces the likelihood of encountering reorg-related issues.In order to address these tradeoffs and risks associated with OP_BBV, BT has written a document outlining the proposal in detail. He has also provided a bip (Bitcoin Improvement Proposal) for OP_BBV. In his document, BT advises against discussing the specifics of the vault application in the thread related to OP_BBV, suggesting that the focus should be on the opcode itself.BT is now seeking feedback from the Bitcoin community regarding his proposal. This feedback will help in refining the design and addressing any potential concerns. 2021-06-13T22:12:21+00:00 + Bitcoin developer BT has proposed a new opcode called OP_BEFOREBLOCKVERIFY (OP_BBV) that would enable switch-off transactions. This opcode would make a transaction invalid if the current block is greater than or equal to a specified block height. The purpose of this functionality is to handle expiring payments or reversible payments that require multiple transactions, but can be simplified into one transaction with OP_BBV.BT mentioned that this opcode could have applications in creating more efficient wallet vaults. However, he also acknowledged concerns about opcodes that could invalidate valid transactions. Specifically, he highlighted two potential issues: 1) the possibility of malicious actors spamming the mempool with transactions containing the opcode, and 2) the risk of "bad" reorg behavior.Regarding the first concern, BT believes that it is solvable. He suggests that software can be designed to warn users to wait for six confirmations in scenarios where a six-block reorg could reverse the transaction. By implementing this safeguard, the risk of invalidating valid transactions due to spamming can be mitigated.As for the second concern, BT argues that it is not a significant problem. He points out that users should generally wait for six confirmations before considering a transaction as final. This waiting period reduces the likelihood of encountering reorg-related issues.In order to address these tradeoffs and risks associated with OP_BBV, BT has written a document outlining the proposal in detail. He has also provided a bip (Bitcoin Improvement Proposal) for OP_BBV. In his document, BT advises against discussing the specifics of the vault application in the thread related to OP_BBV, suggesting that the focus should be on the opcode itself.BT is now seeking feedback from the Bitcoin community regarding his proposal. This feedback will help in refining the design and addressing any potential concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Opinion-on-proof-of-stake-in-future.xml b/static/bitcoin-dev/June_2021/combined_Opinion-on-proof-of-stake-in-future.xml index 7ca41f852f..b2cc37c2fd 100644 --- a/static/bitcoin-dev/June_2021/combined_Opinion-on-proof-of-stake-in-future.xml +++ b/static/bitcoin-dev/June_2021/combined_Opinion-on-proof-of-stake-in-future.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Opinion on proof of stake in future - 2023-08-02T03:47:09.348187+00:00 + 2025-09-26T15:39:28.411095+00:00 + python-feedgen Billy Tetrud 2021-06-26 16:26:12+00:00 @@ -271,13 +272,13 @@ - python-feedgen + 2 Combined summary - Opinion on proof of stake in future - 2023-08-02T03:47:09.348187+00:00 + 2025-09-26T15:39:28.411363+00:00 - The ongoing debate within the bitcoin-dev community revolves around the compatibility of Proof of Stake (PoS) with Bitcoin's objectives. Some argue that PoS contradicts Bitcoin's permissionless nature and introduces trust into the system, while others propose alternatives like Proof of Burn (PoB) but acknowledge block timing issues. Overall, consensus is that new consensus algorithms must meet high standards, and PoS has not yet demonstrated properties consistent with Bitcoin's objectives.Verifiable Delay Functions (VDFs) are being discussed as a potential solution to regulate block times in proof-of-burn blockchains. However, concerns exist regarding ways to increase sequential speed without compromising energy consumption. Despite these concerns, there are promising developments with VDFs that could address block regulation problems without relying solely on brute-force search PoW.Reducing the block reward in Bitcoin has been proposed as a means to improve its mainstream reputation and reduce energy expenditure. However, it should be noted that the block reward is already being reduced through halving events every four years. Concerns about the environmental impact of Bitcoin mining persist, with estimates suggesting that it consumes more energy than entire countries. Arguments in favor of Bitcoin's energy consumption include the use of renewable energy sources for mining and the potential for Bitcoin to incentivize the development of a more sustainable energy grid.Discussions also revolve around the potential of chip fabs to eliminate the hardware barrier and allow more people to participate in Bitcoin mining. It is believed that the energy economy still has more supply than competition, and as prices drop, renewable energy would outcompete nonrenewable sources. The impact of Bitcoin mining on energy usage is seen as an opportunity for investment in renewable energy sources rather than a cause for shame.Various perspectives on PoS as a consensus mechanism for Bitcoin mining are presented. Some argue against implementing PoS due to security concerns and concentration of power. Others believe that PoS may have advantages for other cryptocurrencies but may not be the best solution for Bitcoin. The discussions highlight the need to find sustainable solutions for mining and energy consumption in the cryptocurrency space, with ongoing exploration of alternatives such as VDFs. 2021-06-26T16:26:12+00:00 + The ongoing debate within the bitcoin-dev community revolves around the compatibility of Proof of Stake (PoS) with Bitcoin's objectives. Some argue that PoS contradicts Bitcoin's permissionless nature and introduces trust into the system, while others propose alternatives like Proof of Burn (PoB) but acknowledge block timing issues. Overall, consensus is that new consensus algorithms must meet high standards, and PoS has not yet demonstrated properties consistent with Bitcoin's objectives.Verifiable Delay Functions (VDFs) are being discussed as a potential solution to regulate block times in proof-of-burn blockchains. However, concerns exist regarding ways to increase sequential speed without compromising energy consumption. Despite these concerns, there are promising developments with VDFs that could address block regulation problems without relying solely on brute-force search PoW.Reducing the block reward in Bitcoin has been proposed as a means to improve its mainstream reputation and reduce energy expenditure. However, it should be noted that the block reward is already being reduced through halving events every four years. Concerns about the environmental impact of Bitcoin mining persist, with estimates suggesting that it consumes more energy than entire countries. Arguments in favor of Bitcoin's energy consumption include the use of renewable energy sources for mining and the potential for Bitcoin to incentivize the development of a more sustainable energy grid.Discussions also revolve around the potential of chip fabs to eliminate the hardware barrier and allow more people to participate in Bitcoin mining. It is believed that the energy economy still has more supply than competition, and as prices drop, renewable energy would outcompete nonrenewable sources. The impact of Bitcoin mining on energy usage is seen as an opportunity for investment in renewable energy sources rather than a cause for shame.Various perspectives on PoS as a consensus mechanism for Bitcoin mining are presented. Some argue against implementing PoS due to security concerns and concentration of power. Others believe that PoS may have advantages for other cryptocurrencies but may not be the best solution for Bitcoin. The discussions highlight the need to find sustainable solutions for mining and energy consumption in the cryptocurrency space, with ongoing exploration of alternatives such as VDFs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml b/static/bitcoin-dev/June_2021/combined_Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml index beea789210..22678bd6c1 100644 --- a/static/bitcoin-dev/June_2021/combined_Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml +++ b/static/bitcoin-dev/June_2021/combined_Proposal-Full-RBF-in-Bitcoin-Core-24-0.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Proposal: Full-RBF in Bitcoin Core 24.0 - 2023-08-02T04:01:48.545744+00:00 - - damian at willtech.com.au 2021-12-20 02:30:57+00:00 - - - Antoine Riard 2021-12-19 18:55:01+00:00 - - - Peter Todd 2021-12-18 17:52:07+00:00 - - - Jeremy 2021-12-18 16:51:46+00:00 - - - Billy Tetrud 2021-06-30 19:21:29+00:00 - - - Corey Haddad 2021-06-30 14:06:50+00:00 - - - Jeremy 2021-06-26 19:00:02+00:00 - - - Billy Tetrud 2021-06-26 16:13:23+00:00 - - - Antoine Riard 2021-06-25 00:23:01+00:00 - - - Greg Sanders 2021-06-17 22:28:45+00:00 - - - Billy Tetrud 2021-06-17 00:58:22+00:00 - - - Antoine Riard 2021-06-15 16:55:14+00:00 - + 2025-09-26T15:39:24.168826+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0 Antoine Riard + 2021-06-15T16:55:00.000Z + + + Billy Tetrud + 2021-06-17T00:58:00.000Z + + + Greg Sanders + 2021-06-17T22:28:00.000Z + + + Antoine Riard + 2021-06-25T00:23:00.000Z + + + Billy Tetrud + 2021-06-26T16:13:00.000Z + + + Jeremy + 2021-06-26T19:00:00.000Z + + + Corey Haddad + 2021-06-30T14:06:00.000Z + + + Billy Tetrud + 2021-06-30T19:21:00.000Z + + + Jeremy + 2021-12-18T16:51:00.000Z + + + Peter Todd + 2021-12-18T17:52:00.000Z + + + Antoine Riard + 2021-12-19T18:55:00.000Z + + + damian + 2021-12-20T02:30:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Proposal: Full-RBF in Bitcoin Core 24.0 - 2023-08-02T04:01:48.545744+00:00 + 2025-09-26T15:39:24.170238+00:00 - The Bitcoin community is currently engaged in a discussion about the future of 0-conf transactions and how to address the associated security risks. One proposal that has been put forward is to deprecate opt-in Replace-by-Fee (RBF) and replace it with full-RBF as the default replacement policy in Bitcoin Core version 24.0. The rationale behind this proposal is to mitigate the risk of denial-of-service (DoS) attacks on multi-party funded transactions enabled by RBF opt-out. These attacks can occur when a malicious counterparty broadcasts a low-feerate, opt-out spending of its own collateral input before engaging in cooperative funding, leading to a DoS situation.Another concern is the risk of mempool malicious partitions, where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets. Opt-in RBF serves as a low-cost partitioning tool, which nullifies most potential progress to mitigate such malicious partitioning. To address these issues, it has been suggested to gradually transition away from full-RBF by enforcing non-replaceability n seconds after the first seen transaction. The goal is to reduce the ability to partition mempools by broadcasting irreplaceable conflicts all at once.In terms of enhancing the security of 0-conf transactions, proactive and reactive security models have been proposed. Proactive models include double-spend monitoring and receiver-side fee-topping with package relay, while reactive models involve economic reputation-based compensations. These approaches aim to detect and respond to successful double-spend attempts and ensure the integrity of 0-conf transactions.The discussion also highlights the need to balance the interests of existing 0-conf users and the development of Layer 2 solutions. While some argue for the preservation of 0-conf transactions, others believe that enabling upcoming interests of fancy Layer 2 solutions is crucial. The decision to switch to full-RBF may be deferred to future updates if it is deemed too early.The proposal to deprecate opt-in Replace-by-Fee (RBF) in favor of full-RBF as the default replacement policy in Bitcoin Core version 24.0 has been put forward by Antoine Riard. This proposal is motivated by ongoing and anticipated changes in the Bitcoin ecosystem. One issue with opt-in RBF is that it doesn't suit the deployment of robust second-layer protocols, and opt-out RBF can be used as a Denial-of-Service (DoS) vector against multi-party funded transactions and mempool partitions.There are questions about whether the community wants to support 0-conf payments at this point, given that there are better mechanisms for fast payments such as Lightning. While few service providers are offering zero-conf channels, where you can start to spend instantly, the security model of 0-conf is far weaker than other payment models. However, there are some Bitcoin services well-known to rely on 0-conf, but beyond how much of the Bitcoin traffic is tied to 0-conf is a hard question. Furthermore, it's not clear how software generally informs the user about 0-conf payment detection, though typically, it's something like an "Unconfirmed" annotation on incoming transactions.To enhance 0-conf security, double-spend monitoring/receiver-side fee-topping with package relay and economic reputation-based compensations are some approaches that could be considered. Overall, the proposal highlights the fact that a transaction relay/mempool acceptance policy might be beneficial to some class of already-deployed Bitcoin applications while being detrimental to newer ones. It is essential to preserve the current interests of 0-conf users while enabling upcoming interests of fancy Layer 2 solutions to flourish. If there is agreement on switching to full-RBF, but 0.24 sounds too early, it can be deferred to 0.25 or 0.26.The bitcoin-dev mailing list has been discussing the adoption of RBF as a standard treatment for all transactions, rather than an opt-in/out feature. Some members believe that opting out of RBF is a weak defense and could lead to theft events. However, there are concerns that eliminating opt-in RBF could affect users who rely on 0-conf payments, which are based on far weaker assumptions. The use of 0-conf payments is still unclear, and it is uncertain how often they are used in the Bitcoin ecosystem at this point.One issue with opt-out RBF is that it allows attackers to perform DoS attacks against multi-party funded transactions by propagating an RBF opt-out double-spend of its contributed input before the honest transaction is broadcasted by the protocol orchestra. This can waste the time value of the victim's inputs or force exhaustion of the fee-bumping reserve. Another problem with opt-out RBF is the risk of mempool malicious partitions where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets.To enhance 0-conf security, reactive security models such as economic reputation-based compens 2021-12-20T02:30:57+00:00 + The Bitcoin community is currently engaged in a discussion about the future of 0-conf transactions and how to address the associated security risks. One proposal that has been put forward is to deprecate opt-in Replace-by-Fee (RBF) and replace it with full-RBF as the default replacement policy in Bitcoin Core version 24.0. The rationale behind this proposal is to mitigate the risk of denial-of-service (DoS) attacks on multi-party funded transactions enabled by RBF opt-out. These attacks can occur when a malicious counterparty broadcasts a low-feerate, opt-out spending of its own collateral input before engaging in cooperative funding, leading to a DoS situation.Another concern is the risk of mempool malicious partitions, where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets. Opt-in RBF serves as a low-cost partitioning tool, which nullifies most potential progress to mitigate such malicious partitioning. To address these issues, it has been suggested to gradually transition away from full-RBF by enforcing non-replaceability n seconds after the first seen transaction. The goal is to reduce the ability to partition mempools by broadcasting irreplaceable conflicts all at once.In terms of enhancing the security of 0-conf transactions, proactive and reactive security models have been proposed. Proactive models include double-spend monitoring and receiver-side fee-topping with package relay, while reactive models involve economic reputation-based compensations. These approaches aim to detect and respond to successful double-spend attempts and ensure the integrity of 0-conf transactions.The discussion also highlights the need to balance the interests of existing 0-conf users and the development of Layer 2 solutions. While some argue for the preservation of 0-conf transactions, others believe that enabling upcoming interests of fancy Layer 2 solutions is crucial. The decision to switch to full-RBF may be deferred to future updates if it is deemed too early.The proposal to deprecate opt-in Replace-by-Fee (RBF) in favor of full-RBF as the default replacement policy in Bitcoin Core version 24.0 has been put forward by Antoine Riard. This proposal is motivated by ongoing and anticipated changes in the Bitcoin ecosystem. One issue with opt-in RBF is that it doesn't suit the deployment of robust second-layer protocols, and opt-out RBF can be used as a Denial-of-Service (DoS) vector against multi-party funded transactions and mempool partitions.There are questions about whether the community wants to support 0-conf payments at this point, given that there are better mechanisms for fast payments such as Lightning. While few service providers are offering zero-conf channels, where you can start to spend instantly, the security model of 0-conf is far weaker than other payment models. However, there are some Bitcoin services well-known to rely on 0-conf, but beyond how much of the Bitcoin traffic is tied to 0-conf is a hard question. Furthermore, it's not clear how software generally informs the user about 0-conf payment detection, though typically, it's something like an "Unconfirmed" annotation on incoming transactions.To enhance 0-conf security, double-spend monitoring/receiver-side fee-topping with package relay and economic reputation-based compensations are some approaches that could be considered. Overall, the proposal highlights the fact that a transaction relay/mempool acceptance policy might be beneficial to some class of already-deployed Bitcoin applications while being detrimental to newer ones. It is essential to preserve the current interests of 0-conf users while enabling upcoming interests of fancy Layer 2 solutions to flourish. If there is agreement on switching to full-RBF, but 0.24 sounds too early, it can be deferred to 0.25 or 0.26.The bitcoin-dev mailing list has been discussing the adoption of RBF as a standard treatment for all transactions, rather than an opt-in/out feature. Some members believe that opting out of RBF is a weak defense and could lead to theft events. However, there are concerns that eliminating opt-in RBF could affect users who rely on 0-conf payments, which are based on far weaker assumptions. The use of 0-conf payments is still unclear, and it is uncertain how often they are used in the Bitcoin ecosystem at this point.One issue with opt-out RBF is that it allows attackers to perform DoS attacks against multi-party funded transactions by propagating an RBF opt-out double-spend of its contributed input before the honest transaction is broadcasted by the protocol orchestra. This can waste the time value of the victim's inputs or force exhaustion of the fee-bumping reserve. Another problem with opt-out RBF is the risk of mempool malicious partitions where an attacker exploits network topology or divergence in mempools policies to partition network mempools into different subsets.To enhance 0-conf security, reactive security models such as economic reputation-based compens - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Taproot-Fields-for-PSBT.xml b/static/bitcoin-dev/June_2021/combined_Taproot-Fields-for-PSBT.xml index 0edbc8e4bd..1876f1a3e1 100644 --- a/static/bitcoin-dev/June_2021/combined_Taproot-Fields-for-PSBT.xml +++ b/static/bitcoin-dev/June_2021/combined_Taproot-Fields-for-PSBT.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Taproot Fields for PSBT - 2023-08-02T04:12:43.924281+00:00 - - Pieter Wuille 2021-11-24 16:08:18+00:00 - - - Greg Sanders 2021-11-24 16:00:42+00:00 - - - Sjors Provoost 2021-11-24 12:44:46+00:00 - - - Jeremy 2021-07-08 20:06:08+00:00 - - - Salvatore Ingala 2021-06-28 19:56:37+00:00 - - - Andrew Chow 2021-06-28 16:04:19+00:00 - - - Salvatore Ingala 2021-06-28 10:03:42+00:00 - - - Andrew Chow 2021-06-22 21:22:28+00:00 - + 2025-09-26T15:39:32.614593+00:00 + python-feedgen + + + [bitcoin-dev] Taproot Fields for PSBT Andrew Chow + 2021-06-22T21:22:00.000Z + + + Salvatore Ingala + 2021-06-28T10:03:00.000Z + + + Andrew Chow + 2021-06-28T16:04:00.000Z + + + Salvatore Ingala + 2021-06-28T19:56:00.000Z + + + Jeremy + 2021-07-08T20:06:00.000Z + + + Sjors Provoost + 2021-11-24T12:44:00.000Z + + + Greg Sanders + 2021-11-24T16:00:00.000Z + + + Pieter Wuille + 2021-11-24T16:08:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Taproot Fields for PSBT - 2023-08-02T04:12:43.924281+00:00 + 2025-09-26T15:39:32.615666+00:00 - In a recent email exchange on the bitcoin-dev mailing list, Sjors Provoost expressed confusion regarding the inclusion of the tapleaf merkle path in the PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION fields. Pieter Wuille responded by explaining that these additional fields are necessary for signers who may not have prior knowledge of the script being signed. The inclusion of the derivation path and tapleaf merkle path allows signers to sign without fully understanding the script or needing to parse it. However, the actual script information is still included for those who wish to analyze or factor it into their decision whether to sign.The confusion arose from Andrew Chow's proposal of a BIP that defines new fields for Taproot support in PSBT. These fields include the Taproot Key BIP32 Derivation Path for both PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION. The fields contain the 32-byte X-only public key, a compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, and then the master key fingerprint concatenated with the derivation path of the public key. These fields provide the necessary information about which keys are present in which leaves and how those keys are derived for signers to sign the transaction.Furthermore, Jeremy Rubin has suggested allowing different keys to specify different sighash flags, which would provide greater flexibility in specifying signature requirements. This would allow for more specific and granular signature requirements, such as chaperone signatures with anyprevout. Currently, the sighashtype key is per-input, and if a sighash type is not provided, the signer should sign using SIGHASH_ALL but may use any sighash type they wish. Rubin has requested this change to be implemented in order to enhance flexibility.Salvatore Ingala thanked Andrew for clarifying that more than one leaf can be added to the Partially Signed Bitcoin Transaction (PSBT). Additionally, Ingala suggested labeling key types that are present multiple times with different keydata in order to assist less experienced readers.Ingala also proposed a change regarding the Taproot Leaf Script as specified in BIP 341. The current control block for this leaf can be up to 4129 bytes long, which is larger than other defined PSBT types. Ingala suggested splitting it into two PSBT types, PSBT_IN_TAP_LEAF_SCRIPT and PSBT_IN_TAP_LEAF_CONTROL_BLOCK, both with no keydata. However, Andrew Chow pointed out that a taproot tree can have multiple leaf scripts and the actual script to be used may not be known at the time of adding them to the PSBT. Therefore, using only two fields with no keydata would not allow for the specification of multiple leaf scripts. Furthermore, the same leaf script can appear multiple times in the tree, so using the leaf hash as keydata would not be sufficient. To enable multiple different leaf scripts and the same leaf script to appear multiple times, the control block itself needs to be used as keydata.The proposal for Taproot support in PSBT introduces several new fields, including Taproot Key Spend Signature, Taproot Script Spend Signature, Taproot Leaf Script, Taproot Key BIP 32 Derivation Path, Taproot Internal Key, and Taproot Merkle Root. These fields are necessary to carry the information required for signing Taproot inputs. The proposal also recommends using PSBT_IN_WITNESS_UTXO for Taproot inputs instead of PSBT_IN_NON_WITNESS_UTXO to prevent potential attacks involving an updater lying about the amounts in an output. The proposal is designed to be compatible with the existing PSBT format, ensuring that old software will ignore the new fields. Test vectors are yet to be determined. 2021-11-24T16:08:18+00:00 + In a recent email exchange on the bitcoin-dev mailing list, Sjors Provoost expressed confusion regarding the inclusion of the tapleaf merkle path in the PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION fields. Pieter Wuille responded by explaining that these additional fields are necessary for signers who may not have prior knowledge of the script being signed. The inclusion of the derivation path and tapleaf merkle path allows signers to sign without fully understanding the script or needing to parse it. However, the actual script information is still included for those who wish to analyze or factor it into their decision whether to sign.The confusion arose from Andrew Chow's proposal of a BIP that defines new fields for Taproot support in PSBT. These fields include the Taproot Key BIP32 Derivation Path for both PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION. The fields contain the 32-byte X-only public key, a compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, and then the master key fingerprint concatenated with the derivation path of the public key. These fields provide the necessary information about which keys are present in which leaves and how those keys are derived for signers to sign the transaction.Furthermore, Jeremy Rubin has suggested allowing different keys to specify different sighash flags, which would provide greater flexibility in specifying signature requirements. This would allow for more specific and granular signature requirements, such as chaperone signatures with anyprevout. Currently, the sighashtype key is per-input, and if a sighash type is not provided, the signer should sign using SIGHASH_ALL but may use any sighash type they wish. Rubin has requested this change to be implemented in order to enhance flexibility.Salvatore Ingala thanked Andrew for clarifying that more than one leaf can be added to the Partially Signed Bitcoin Transaction (PSBT). Additionally, Ingala suggested labeling key types that are present multiple times with different keydata in order to assist less experienced readers.Ingala also proposed a change regarding the Taproot Leaf Script as specified in BIP 341. The current control block for this leaf can be up to 4129 bytes long, which is larger than other defined PSBT types. Ingala suggested splitting it into two PSBT types, PSBT_IN_TAP_LEAF_SCRIPT and PSBT_IN_TAP_LEAF_CONTROL_BLOCK, both with no keydata. However, Andrew Chow pointed out that a taproot tree can have multiple leaf scripts and the actual script to be used may not be known at the time of adding them to the PSBT. Therefore, using only two fields with no keydata would not allow for the specification of multiple leaf scripts. Furthermore, the same leaf script can appear multiple times in the tree, so using the leaf hash as keydata would not be sufficient. To enable multiple different leaf scripts and the same leaf script to appear multiple times, the control block itself needs to be used as keydata.The proposal for Taproot support in PSBT introduces several new fields, including Taproot Key Spend Signature, Taproot Script Spend Signature, Taproot Leaf Script, Taproot Key BIP 32 Derivation Path, Taproot Internal Key, and Taproot Merkle Root. These fields are necessary to carry the information required for signing Taproot inputs. The proposal also recommends using PSBT_IN_WITNESS_UTXO for Taproot inputs instead of PSBT_IN_NON_WITNESS_UTXO to prevent potential attacks involving an updater lying about the amounts in an output. The proposal is designed to be compatible with the existing PSBT format, ensuring that old software will ignore the new fields. Test vectors are yet to be determined. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork-upgrades.xml b/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork-upgrades.xml index 7a987915bd..7f5e7be0a3 100644 --- a/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork-upgrades.xml +++ b/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork-upgrades.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - Trinary Version Signaling for softfork upgrades - 2023-08-02T04:14:50.370680+00:00 - - Billy Tetrud 2021-06-30 19:42:50+00:00 - - - Billy Tetrud 2021-06-30 19:30:33+00:00 - - - eric at voskuil.org 2021-06-30 09:52:42+00:00 - - - Jorge Timón 2021-06-30 09:16:51+00:00 - - - eric at voskuil.org 2021-06-30 08:55:47+00:00 - - - Zac Greenwood 2021-06-30 06:39:41+00:00 - - - Billy Tetrud 2021-06-30 02:02:36+00:00 - - - Eric Voskuil 2021-06-29 19:44:09+00:00 - - - Jorge Timón 2021-06-29 19:28:20+00:00 - - - Eric Voskuil 2021-06-29 18:17:22+00:00 - - - Luke Dashjr 2021-06-29 17:55:11+00:00 - - - Eric Voskuil 2021-06-29 08:44:56+00:00 - - - Jorge Timón 2021-06-29 08:32:33+00:00 - - - Billy Tetrud 2021-06-27 18:11:46+00:00 - - - Eric Voskuil 2021-06-27 09:21:58+00:00 - - - Jorge Timón 2021-06-27 08:47:06+00:00 - - - Eric Voskuil 2021-06-26 22:05:05+00:00 - - - Eric Voskuil 2021-06-26 21:43:55+00:00 - - - Luke Dashjr 2021-06-26 21:13:04+00:00 - - - Billy Tetrud 2021-06-26 20:21:52+00:00 - + 2025-09-26T15:39:26.294278+00:00 + python-feedgen + + + [bitcoin-dev] Trinary Version Signaling for softfork upgrades Billy Tetrud + 2021-06-26T20:21:00.000Z + + + Luke Dashjr + 2021-06-26T21:13:00.000Z + + + Eric Voskuil + 2021-06-26T21:43:00.000Z + + + Eric Voskuil + 2021-06-26T22:05:00.000Z + + + Jorge Timón + 2021-06-27T08:47:00.000Z + + + Eric Voskuil + 2021-06-27T09:21:00.000Z + + + Billy Tetrud + 2021-06-27T18:11:00.000Z + + + Jorge Timón + 2021-06-29T08:32:00.000Z + + + Eric Voskuil + 2021-06-29T08:44:00.000Z + + + Luke Dashjr + 2021-06-29T17:55:00.000Z + + + Eric Voskuil + 2021-06-29T18:17:00.000Z + + + Jorge Timón + 2021-06-29T19:28:00.000Z + + + Eric Voskuil + 2021-06-29T19:44:00.000Z + + + Billy Tetrud + 2021-06-30T02:02:00.000Z + + + Zac Greenwood + 2021-06-30T06:39:00.000Z + + + eric + 2021-06-30T08:55:00.000Z + + + Jorge Timón + 2021-06-30T09:16:00.000Z + + + eric + 2021-06-30T09:52:00.000Z + + + Billy Tetrud + 2021-06-30T19:30:00.000Z + + + Billy Tetrud + 2021-06-30T19:42:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - Trinary Version Signaling for softfork upgrades - 2023-08-02T04:14:50.370680+00:00 + 2025-09-26T15:39:26.296598+00:00 - A recent controversy over upgrade mechanisms for the taproot upgrade has sparked discussions on how to prevent chain splits and ensure smooth activation of soft forks. Currently, there are three signaling states for upgrades: actively supporting the change, actively opposing the change, or not signaling (default state). This allows miners who oppose the change to update their software and signal opposition while still remaining lazy, without significantly slowing down soft fork activation.To accurately estimate user sentiment, existing mechanisms such as community discussion, social consensus estimation, and miner signaling during deployment periods are used. However, these mechanisms provide rough estimates, so additional barriers are necessary for upgrades with higher thresholds of success. Ultimately, achieving majority hash power support is crucial for successful activation.In an email to the Bitcoin development mailing list, Eric Voskuil emphasized that there is no choice between creating a split and hash power enforcement. Soft forks are rule changes and require majority hash power enforcement to be compatible. Voskuil called out misleading statements about soft fork "compatibility" and activation without hash power enforcement, highlighting that it can indeed lead to a split. He emphasized that users decide the rules, not miners or developers, and mining is a way for anyone to have a say in the process.Luke Dashjr added that BIP8 LOT=True ensures miners cannot entirely block an upgrade but they can still slow it down. Users who oppose a soft fork should treat the successful signal as invalid, ensuring they do not follow a chain with the enforced rules. Billy Tetrud proposed using trinary version signaling instead of binary signaling for soft fork upgrades. This would allow for three signaling states: actively supporting the change, actively opposing the change, or not signaling. This additional information could expedite the release of non-contentious upgrades with a lower percentage of miners signaling support. For contentious upgrades, miners who oppose the change would be incentivized to update their software to actively signal opposition.The recent controversy surrounding upgrade mechanisms for the taproot upgrade has led to the proposal of a new soft fork upgrade mechanism. This mechanism uses trinary version signaling, allowing for three signaling states: actively support the change, actively oppose the change, or not signaling at all. By incorporating this additional information, non-contentious upgrades can be released more quickly with a lower percentage of miners signaling support. For contentious upgrades, miners who oppose the change are encouraged to update their software and actively signal opposition. The higher the threshold necessary to lock in the upgrade, the greater the opposition. This incentivizes lazy miners who oppose the change to update their software while still allowing them to remain lazy without significantly slowing down the soft fork activation.The proposal recommends discussing new soft fork upgrade mechanisms when there are no pressing soft fork upgrades ready to deploy. Delaying discussions until the need arises may lead to contention, as seen with the taproot upgrade. The author invites comments and feedback on the proposed mechanism through comments or GitHub issues on the proposal repository. 2021-06-30T19:42:50+00:00 + A recent controversy over upgrade mechanisms for the taproot upgrade has sparked discussions on how to prevent chain splits and ensure smooth activation of soft forks. Currently, there are three signaling states for upgrades: actively supporting the change, actively opposing the change, or not signaling (default state). This allows miners who oppose the change to update their software and signal opposition while still remaining lazy, without significantly slowing down soft fork activation.To accurately estimate user sentiment, existing mechanisms such as community discussion, social consensus estimation, and miner signaling during deployment periods are used. However, these mechanisms provide rough estimates, so additional barriers are necessary for upgrades with higher thresholds of success. Ultimately, achieving majority hash power support is crucial for successful activation.In an email to the Bitcoin development mailing list, Eric Voskuil emphasized that there is no choice between creating a split and hash power enforcement. Soft forks are rule changes and require majority hash power enforcement to be compatible. Voskuil called out misleading statements about soft fork "compatibility" and activation without hash power enforcement, highlighting that it can indeed lead to a split. He emphasized that users decide the rules, not miners or developers, and mining is a way for anyone to have a say in the process.Luke Dashjr added that BIP8 LOT=True ensures miners cannot entirely block an upgrade but they can still slow it down. Users who oppose a soft fork should treat the successful signal as invalid, ensuring they do not follow a chain with the enforced rules. Billy Tetrud proposed using trinary version signaling instead of binary signaling for soft fork upgrades. This would allow for three signaling states: actively supporting the change, actively opposing the change, or not signaling. This additional information could expedite the release of non-contentious upgrades with a lower percentage of miners signaling support. For contentious upgrades, miners who oppose the change would be incentivized to update their software to actively signal opposition.The recent controversy surrounding upgrade mechanisms for the taproot upgrade has led to the proposal of a new soft fork upgrade mechanism. This mechanism uses trinary version signaling, allowing for three signaling states: actively support the change, actively oppose the change, or not signaling at all. By incorporating this additional information, non-contentious upgrades can be released more quickly with a lower percentage of miners signaling support. For contentious upgrades, miners who oppose the change are encouraged to update their software and actively signal opposition. The higher the threshold necessary to lock in the upgrade, the greater the opposition. This incentivizes lazy miners who oppose the change to update their software while still allowing them to remain lazy without significantly slowing down the soft fork activation.The proposal recommends discussing new soft fork upgrade mechanisms when there are no pressing soft fork upgrades ready to deploy. Delaying discussions until the need arises may lead to contention, as seen with the taproot upgrade. The author invites comments and feedback on the proposed mechanism through comments or GitHub issues on the proposal repository. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork.xml b/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork.xml index 30822cb30f..d5ba6191fe 100644 --- a/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork.xml +++ b/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Trinary Version Signaling for softfork - 2023-08-02T04:15:05.856979+00:00 + 2025-09-26T15:39:22.054790+00:00 + python-feedgen Eric Voskuil 2021-06-30 18:11:06+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Trinary Version Signaling for softfork - 2023-08-02T04:15:05.856979+00:00 + 2025-09-26T15:39:22.054941+00:00 - In a recent email exchange between Zac Greenwood and Eric Voskuil, the topic of whether a node enforces consensus rules in Bitcoin was debated. Voskuil argued that it is up to economic nodes, people who refuse to accept invalid money, to enforce consensus rules. Greenwood disagreed, stating that nodes do enforce consensus rules by disregarding invalid transactions and blocks. He provided examples from the BCH split to support his argument. The debate continued with Greenwood asserting that non-economic nodes are ignored by the network, while Voskuil emphasized the role of merchants in enforcing consensus rules.Another discussion focused on the relationship between game theory and Bitcoin. Voskuil expressed skepticism regarding the relevance of game theory to Bitcoin, stating that he has not seen any demonstration of their connection. He also clarified that mining pools and exchanges do not necessarily discuss before signaling for a soft fork. Miners can mine whatever they want and earn block rewards. Voskuil further explained that consensus rules are enforced by merchants who reject trading for something they don't consider money. The conversation highlighted the misunderstanding of signaling as voting and emphasized the complexity of enforcing consensus rules.Further discussions explored the enforcement of consensus rules in the Bitcoin network. One participant argued that it is ultimately up to individuals to enforce the decision to reject invalid transactions, while another participant asserted that nodes definitely enforce consensus rules and define what Bitcoin is. The conversations also touched on topics such as chain splits, soft fork signaling, and the role of miners. The participants offered different perspectives, highlighting the complexity and differing viewpoints surrounding the enforcement of consensus rules.Voskuil responded to questions related to Bitcoin's consensus rules and mining, noting that two people on different rules imply a chain split. He highlighted the absence of a concept of "the rules" and questioned why miners would mine a chain that nobody wants to use. Voskuil expressed uncertainty about the relevance of game theory to Bitcoin and clarified that a node does not enforce anything. He emphasized the role of merchants in enforcing consensus rules and addressed misconceptions about soft fork signaling. Voskuil stated that miners mine whichever chain they want and earn block rewards, and that signaling is not equivalent to voting.In summary, the discussions revolved around the enforcement of consensus rules in the Bitcoin network. While there were differing opinions, it was acknowledged that both nodes and merchants play a role in enforcing these rules. The complexity of enforcing consensus rules, the relevance of game theory, and the misconceptions surrounding soft fork signaling were also highlighted. Ultimately, the conversations showcased the multiple perspectives and challenges associated with maintaining consensus in the Bitcoin network. 2021-06-30T18:11:06+00:00 + In a recent email exchange between Zac Greenwood and Eric Voskuil, the topic of whether a node enforces consensus rules in Bitcoin was debated. Voskuil argued that it is up to economic nodes, people who refuse to accept invalid money, to enforce consensus rules. Greenwood disagreed, stating that nodes do enforce consensus rules by disregarding invalid transactions and blocks. He provided examples from the BCH split to support his argument. The debate continued with Greenwood asserting that non-economic nodes are ignored by the network, while Voskuil emphasized the role of merchants in enforcing consensus rules.Another discussion focused on the relationship between game theory and Bitcoin. Voskuil expressed skepticism regarding the relevance of game theory to Bitcoin, stating that he has not seen any demonstration of their connection. He also clarified that mining pools and exchanges do not necessarily discuss before signaling for a soft fork. Miners can mine whatever they want and earn block rewards. Voskuil further explained that consensus rules are enforced by merchants who reject trading for something they don't consider money. The conversation highlighted the misunderstanding of signaling as voting and emphasized the complexity of enforcing consensus rules.Further discussions explored the enforcement of consensus rules in the Bitcoin network. One participant argued that it is ultimately up to individuals to enforce the decision to reject invalid transactions, while another participant asserted that nodes definitely enforce consensus rules and define what Bitcoin is. The conversations also touched on topics such as chain splits, soft fork signaling, and the role of miners. The participants offered different perspectives, highlighting the complexity and differing viewpoints surrounding the enforcement of consensus rules.Voskuil responded to questions related to Bitcoin's consensus rules and mining, noting that two people on different rules imply a chain split. He highlighted the absence of a concept of "the rules" and questioned why miners would mine a chain that nobody wants to use. Voskuil expressed uncertainty about the relevance of game theory to Bitcoin and clarified that a node does not enforce anything. He emphasized the role of merchants in enforcing consensus rules and addressed misconceptions about soft fork signaling. Voskuil stated that miners mine whichever chain they want and earn block rewards, and that signaling is not equivalent to voting.In summary, the discussions revolved around the enforcement of consensus rules in the Bitcoin network. While there were differing opinions, it was acknowledged that both nodes and merchants play a role in enforcing these rules. The complexity of enforcing consensus rules, the relevance of game theory, and the misconceptions surrounding soft fork signaling were also highlighted. Ultimately, the conversations showcased the multiple perspectives and challenges associated with maintaining consensus in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Tuesday-s-IRC-workshop-on-L2-onchain-support.xml b/static/bitcoin-dev/June_2021/combined_Tuesday-s-IRC-workshop-on-L2-onchain-support.xml index 01754f4887..26d66934e9 100644 --- a/static/bitcoin-dev/June_2021/combined_Tuesday-s-IRC-workshop-on-L2-onchain-support.xml +++ b/static/bitcoin-dev/June_2021/combined_Tuesday-s-IRC-workshop-on-L2-onchain-support.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Tuesday’s IRC workshop on L2 onchain support - 2023-08-02T04:12:11.188042+00:00 - - Michael Folkson 2021-06-22 18:40:19+00:00 - - - Billy Tetrud 2021-06-22 18:26:34+00:00 - - - Michael Folkson 2021-06-22 18:21:39+00:00 - - - Billy Tetrud 2021-06-22 18:01:46+00:00 - - - Michael Folkson 2021-06-17 17:01:59+00:00 - + 2025-09-26T15:39:13.560511+00:00 + python-feedgen + + + [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support Michael Folkson + 2021-06-17T17:01:00.000Z + + + Billy Tetrud + 2021-06-22T18:01:00.000Z + + + Michael Folkson + 2021-06-22T18:21:00.000Z + + + Billy Tetrud + 2021-06-22T18:26:00.000Z + + + Michael Folkson + 2021-06-22T18:40:00.000Z + + - python-feedgen + 2 Combined summary - Tuesday’s IRC workshop on L2 onchain support - 2023-08-02T04:12:11.188042+00:00 + 2025-09-26T15:39:13.561248+00:00 - During a recent Bitcoin development meeting, the community discussed various topics related to Layer 2 (L2) protocols, including network transaction fee rates and relay. It was acknowledged that perfect security guarantees on these aspects are not possible, but efforts were made to strengthen the security assumption of L2 protocols like Lightning and DLCs. Ideas such as fee-sensitive timelocks, transaction relay overlay networks, and miners' profit incentive were discussed.The idea of fee-sensitive timelocks was raised, which would require a soft fork. This concept aims to increase the resilience of the Lightning Network during periods of fee congestion. The workshop also explored the possibility of using fee-bumping techniques to close or restructure channels during elevated fee markets.The impact of changes to Bitcoin Core on L2 protocols was a topic of discussion. Some changes in Bitcoin Core, particularly privacy improvements, may conflict with the goal of minimizing transaction propagation times. To address this, a suggestion was made to create a nightly bitcoind build, allowing L2 developers to write regression tests against the latest builds.The meeting also touched upon full Replace-by-Fee (RBF) proposals. While a proposal for full RBF in a future version of Bitcoin Core was posted, concerns were raised about the potential creation of mempool partitions and its impact on businesses relying on zero confirmations. Ariard, the proposer, plans to reach out to such businesses to assess the implications of this change.Next week's meeting will focus on fee bumping and package relay advancements in Bitcoin Core, specifically the work done by glozow. The discussion log and additional notes from the meeting can be found in the L2 zoology repository set up by ariard.Overall, the workshop aimed to address the challenges of guaranteeing secure transaction propagation and inclusion in time-sensitive mined blocks within L2 protocols. While perfect security guarantees may not be feasible, the community explored various ideas and proposals to strengthen the security assumption and improve the overall efficiency and functionality of Bitcoin transactions. 2021-06-22T18:40:19+00:00 + During a recent Bitcoin development meeting, the community discussed various topics related to Layer 2 (L2) protocols, including network transaction fee rates and relay. It was acknowledged that perfect security guarantees on these aspects are not possible, but efforts were made to strengthen the security assumption of L2 protocols like Lightning and DLCs. Ideas such as fee-sensitive timelocks, transaction relay overlay networks, and miners' profit incentive were discussed.The idea of fee-sensitive timelocks was raised, which would require a soft fork. This concept aims to increase the resilience of the Lightning Network during periods of fee congestion. The workshop also explored the possibility of using fee-bumping techniques to close or restructure channels during elevated fee markets.The impact of changes to Bitcoin Core on L2 protocols was a topic of discussion. Some changes in Bitcoin Core, particularly privacy improvements, may conflict with the goal of minimizing transaction propagation times. To address this, a suggestion was made to create a nightly bitcoind build, allowing L2 developers to write regression tests against the latest builds.The meeting also touched upon full Replace-by-Fee (RBF) proposals. While a proposal for full RBF in a future version of Bitcoin Core was posted, concerns were raised about the potential creation of mempool partitions and its impact on businesses relying on zero confirmations. Ariard, the proposer, plans to reach out to such businesses to assess the implications of this change.Next week's meeting will focus on fee bumping and package relay advancements in Bitcoin Core, specifically the work done by glozow. The discussion log and additional notes from the meeting can be found in the L2 zoology repository set up by ariard.Overall, the workshop aimed to address the challenges of guaranteeing secure transaction propagation and inclusion in time-sensitive mined blocks within L2 protocols. While perfect security guarantees may not be feasible, the community explored various ideas and proposals to strengthen the security assumption and improve the overall efficiency and functionality of Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2021/combined_Waiting-SIGHASH-ANYPREVOUT-and-Packing-Packages.xml b/static/bitcoin-dev/June_2021/combined_Waiting-SIGHASH-ANYPREVOUT-and-Packing-Packages.xml index 0b474314c4..e440271d36 100644 --- a/static/bitcoin-dev/June_2021/combined_Waiting-SIGHASH-ANYPREVOUT-and-Packing-Packages.xml +++ b/static/bitcoin-dev/June_2021/combined_Waiting-SIGHASH-ANYPREVOUT-and-Packing-Packages.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Waiting SIGHASH_ANYPREVOUT and Packing Packages - 2023-08-02T04:12:22.370931+00:00 - - Antoine Riard 2021-06-24 13:03:21+00:00 - - - Michael Folkson 2021-06-21 10:20:40+00:00 - - - Antoine Riard 2021-06-21 08:13:32+00:00 - - - David A. Harding 2021-06-19 13:36:53+00:00 - - - Antoine Riard 2021-06-19 01:34:28+00:00 - - - Antoine Riard 2021-06-18 22:11:38+00:00 - + 2025-09-26T15:39:17.765961+00:00 + python-feedgen + + + [bitcoin-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages Antoine Riard + 2021-06-18T22:11:00.000Z + + + Antoine Riard + 2021-06-19T01:34:00.000Z + + + [bitcoin-dev] [Lightning-dev] " David A. Harding + 2021-06-19T13:36:00.000Z + + + Antoine Riard + 2021-06-21T08:13:00.000Z + + + Michael Folkson + 2021-06-21T10:20:00.000Z + + + Antoine Riard + 2021-06-24T13:03:00.000Z + + - python-feedgen + 2 Combined summary - Waiting SIGHASH_ANYPREVOUT and Packing Packages - 2023-08-02T04:12:22.370931+00:00 + 2025-09-26T15:39:17.766787+00:00 - Antoine Riard and David A. Harding recently had a discussion about potential changes to Bitcoin Core and the Lightning Network. They discussed scalability, coordination among different layers, and long-term roadmaps for decentralized projects like Bitcoin Core. Antoine proposed solutions to technical issues such as pre-signed feerate/tx-pinnings, package-relay, and blind CPFP fee bump transactions. However, caution was suggested before promoting these ideas, and more detailed write-ups and discussions within the Bitcoin community were encouraged.One of the main issues discussed was the pre-signed feerate problem in the Lightning Network. Antoine proposed two potential solutions: package-relay and SIGHASH_ANYPREVOUT. While there were concerns about how SIGHASH_ANYPREVOUT would solve pinnings beyond previous discussions, package-relay was seen as a clear improvement. The timeline for implementing these changes is uncertain, and creating timelines without consulting a large number of contributors was deemed inappropriate and unrealistic.Antoine emphasized the importance of spreading ideas, learning from mistakes, and building better systems. He invited participants to form their own opinions based on different factors and trusted experts' opinions. He also highlighted the need for concrete numbers and dates to address safety holes in the ecosystem before they become real problems.The discussions also touched on various technical details, including the compatibility of SIGHASH_ANYPREVOUT with eltoo and potential attacks that could exploit the anyprevout idea. There were suggestions for more detailed write-ups and discussions within the community before promoting these ideas further.Overall, the discussions revolved around addressing scalability and coordination challenges in Bitcoin development, proposing solutions to technical issues, and emphasizing the importance of careful consideration and collaboration within the Bitcoin community. 2021-06-24T13:03:21+00:00 + Antoine Riard and David A. Harding recently had a discussion about potential changes to Bitcoin Core and the Lightning Network. They discussed scalability, coordination among different layers, and long-term roadmaps for decentralized projects like Bitcoin Core. Antoine proposed solutions to technical issues such as pre-signed feerate/tx-pinnings, package-relay, and blind CPFP fee bump transactions. However, caution was suggested before promoting these ideas, and more detailed write-ups and discussions within the Bitcoin community were encouraged.One of the main issues discussed was the pre-signed feerate problem in the Lightning Network. Antoine proposed two potential solutions: package-relay and SIGHASH_ANYPREVOUT. While there were concerns about how SIGHASH_ANYPREVOUT would solve pinnings beyond previous discussions, package-relay was seen as a clear improvement. The timeline for implementing these changes is uncertain, and creating timelines without consulting a large number of contributors was deemed inappropriate and unrealistic.Antoine emphasized the importance of spreading ideas, learning from mistakes, and building better systems. He invited participants to form their own opinions based on different factors and trusted experts' opinions. He also highlighted the need for concrete numbers and dates to address safety holes in the ecosystem before they become real problems.The discussions also touched on various technical details, including the compatibility of SIGHASH_ANYPREVOUT with eltoo and potential attacks that could exploit the anyprevout idea. There were suggestions for more detailed write-ups and discussions within the community before promoting these ideas further.Overall, the discussions revolved around addressing scalability and coordination challenges in Bitcoin development, proposing solutions to technical issues, and emphasizing the importance of careful consideration and collaboration within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml index a7256419d8..9b83a75720 100644 --- a/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml @@ -2,7 +2,7 @@ 2 Combined summary - Packaged Transaction Relay - 2025-09-26T14:31:37.851598+00:00 + 2025-09-26T15:46:37.840027+00:00 python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - Packaged Transaction Relay - 2025-09-26T14:31:37.851752+00:00 + 2025-09-26T15:46:37.840214+00:00 2022-10-10T22:05:38+00:00 The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. diff --git a/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml b/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml index d666068332..2ed24658a3 100644 --- a/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml +++ b/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - Why OpenTimestamps does not "linearize" its transactions - 2025-09-26T14:31:22.878355+00:00 + 2025-09-26T15:46:35.708155+00:00 python-feedgen Peter Todd 2022-06-19 11:04:50+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - Why OpenTimestamps does not "linearize" its transactions - 2025-09-26T14:31:22.878521+00:00 + 2025-09-26T15:46:35.708311+00:00 2022-06-19T11:04:50+00:00 In a recent email exchange on the bitcoin-dev mailing list, concerns were raised regarding the use of OpenTimestamps (OTS) for timestamping. One user expressed worry about the requirement to publicize .ots files and suggested including more cryptographic information in the original OP_RETURN to eliminate the need for this. However, it was clarified that publication is not actually a part of the OTS system.The discussion also touched upon the issue of security with .ots files when shared with other parties. Without cryptographic pinning, there is a possibility that a fourth party could replace the .ots file, changing the timestamp to a later date and compromising the validity of the data. Additionally, there were concerns about the potential loss of transaction history containing OTS hashes in chain forks.Another user highlighted the limitations of OTS in proving the timing and uniqueness of documents. While OTS can prove the duration of a document, it cannot demonstrate its shortness or whether an earlier version was already published. The user referred to this as the system being "designed to be broken" as it allows individuals to rewrite history by republishing others' documents under different contexts.The conversation also delved into the scalability and efficiency of OTS. It was noted that through the use of merkle trees, OTS can timestamp tens of thousands of messages with a single transaction, making it a more efficient option. However, there were suggestions for additional measures to ensure the security and uniqueness of timestamps, such as publicizing nonces and document hashes with user consent.Overall, the discussions highlighted the complexities and considerations involved in using timestamp services like OpenTimestamps. While they provide valuable information about the existence of content at a given time, there are limitations and security concerns that need to be addressed to ensure the validity and reliability of the timestamps.In the context of proving the existence of a message prior to a certain point in time, linearization is not considered as a viable solution. The focus is on verifying statements about messages rather than timestamp proofs. To address this issue, random beacons provide a solution by offering dual-sided bounds on the creation time of messages. By creating messages that are known to have been created after a specific point in time and with an unpredictable prior, the accuracy of timestamp proofs can be ensured.For use-cases that require day to hour level precision, Bitcoin block hashes serve as an effective random beacon. However, for higher precision absolute time, there are several trusted alternatives available. These include the NIST random beacon and Roughtime, among others.Overall, random beacons offer a way to establish the creation time of messages, allowing for the verification of statements without relying solely on timestamp proofs. Whether using Bitcoin block hashes or other trusted alternatives, random beacons provide a valuable tool for various precision requirements. diff --git a/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml b/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml index 64401efb90..e1b63adaa1 100644 --- a/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml +++ b/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 85, Issue 4 - 2025-09-26T14:31:44.341548+00:00 + 2025-09-26T15:46:39.955695+00:00 python-feedgen Billy Tetrud 2022-06-15 04:02:38+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 85, Issue 4 - 2025-09-26T14:31:44.341711+00:00 + 2025-09-26T15:46:39.955828+00:00 2022-06-15T04:02:38+00:00 The concept of consensus in Bitcoin involves trust, which is measured using a mechanism called Trust Metric. The Ford Fulkerson Max Flow Algorithm is used to convert an unordered graph of "Trust Declarations" into a Directed Acyclic Graph with weighting to prevent faults. Sybil resistance is achieved by linking pseudo-identities to trusted individuals and requiring a minimum number of Trust Declarations. However, attackers can still pose as trustworthy individuals. Negative Certs were considered but not implemented due to potential harm.Maintaining the system requires discipline and does not incentivize people without risking bribery. Getting people to pay BTC to make declarations of trust is difficult. There was a discussion about whether developers are paid enough in BTC to afford making declarations, and the idea of separating the Declaration from the payment threshold was proposed. This would allow anyone to enter a zero-value transaction with a Declaration of Trust, but independent post-processing would determine inclusion in the Graph Processing.Luke Kenneth Casson Leighton suggests that trust metrics could address misinformation undermining Bitcoin. Trust metrics are similar to the Bitcoin protocol and could benefit the ecosystem. Trust metrics quantify who's trusted among a set of people and can be used to answer questions about Bitcoin. Public declarations of trust and Maximum-Flow Graph analysis help filter out spam. Colluding users farming aliases can game trust metrics, but Sybil resistance can be bolstered by charging fees or requiring proof of funds. Adding trust metrics evaluation to the Bitcoin protocol would help developers evaluate whom to trust for protocol development.AliceXBT discusses misinformation being used to undermine Bitcoin and suggests Trust Metrics as a solution. She mentions advogato.org as a successful experiment in this regard. Public declarations of trust and Maximum-Flow Graph analysis help filter out false information. AliceXBT finds it ironic that trust metric evaluation was not added to the Bitcoin protocol from the start, hindering developers' ability to evaluate whom to trust for protocol development. diff --git a/static/bitcoin-dev/March_2016/combined_BIP-2-promotion-to-Final.xml b/static/bitcoin-dev/March_2016/combined_BIP-2-promotion-to-Final.xml index 9729313371..8aac466c22 100644 --- a/static/bitcoin-dev/March_2016/combined_BIP-2-promotion-to-Final.xml +++ b/static/bitcoin-dev/March_2016/combined_BIP-2-promotion-to-Final.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 2 promotion to Final - 2023-08-01T17:57:21.303461+00:00 + 2025-09-26T15:41:55.878177+00:00 + python-feedgen David A. Harding 2016-03-18 22:52:55+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - BIP 2 promotion to Final - 2023-08-01T17:57:21.303461+00:00 + 2025-09-26T15:41:55.878354+00:00 - Dave suggests that the BIP authors should be allowed to decide for themselves which wiki is better instead of arguing. He proposes using Draft-BIP2's provision for authors to specify their own backup wiki as policy in all cases, eliminating the need for a backup wiki altogether. This would allow for greater flexibility and autonomy among authors.In a discussion between Btc Drak and Luke Dashjr about the use of external sources for BIP comments, Luke argues that BIP comments are not part of the BIP itself and can be kept external. Btc Drak objects to using external sources and suggests using the Wiki feature at bitcoin/bips. Luke clarifies that stronger moderation was needed, which is why the BIP process was moved to GitHub. However, he believes that such moderation is unnecessary for BIP comments. The discussion ends without reaching a resolution.Luke suggests that BIP comments should not be linked to external sources like the Bitcoin Wiki but rather made using the Wiki feature at bitcoin/bips itself. External sources are bound to go stale over time. The forum for comments should have a low barrier of use, and the Bitcoin Wiki requires only a request for editing privileges unlike GitHub wiki that would require reading and agreeing to a lengthy Terms of Service contract. The Bitcoin Wiki has been shown to stand the test of time and is less likely to move than the GitHub repository. The BIP process originated on the Wiki and was only moved to GitHub because stronger moderation was needed. Such moderation is unnecessary for BIP Comments. It is suggested that non-reference implementation lists/links be moved to BIP Comments rather than constantly revising the BIPs with them.Mustafa Al-Bassam raises concerns about the adoption of hard-fork BIP by the entire Bitcoin economy. He points out that even if a small minority refuses to accept a hard fork, it can veto the entire process. Another member clarifies that the hardfork can still happen, but for it to move to the final state, deployment needs to be universal. The discussion highlights the importance of unanimous agreement in the Bitcoin ecosystem for hard forks to be successful.In a conversation between Luke Dashjr and Mustafa Al-Bassam, they discuss the wording of a soft-fork that does not become final as long as a hard-fork has potentially-majority support or at most three months. Mustafa raises concerns about the requirement for adoption from the entire Bitcoin economy for a hard-fork BIP. He questions what would happen if one shop owner out of thousands did not adapt to the hard-fork. Luke clarifies that one shop cannot operate in a vacuum and they will soon find themselves no longer selling in exchange for bitcoin payments. The discussion concludes that any hard fork BIPs are unlikely to reach final status.Jorge Timón raises concerns about an attacker preventing a BIP from reaching final status. Mustafa Al-Bassam proposes a definition for when a hard fork becomes active, but Timón points out that an attacker could easily prevent a BIP from becoming final with little time or effort. While there may not be an obvious incentive for such an attack, Timón argues that some people might do it purely for the enjoyment of causing trouble. He suggests that any hard fork BIPs are unlikely to reach final status.Luke Dashjr opens a pull request to move BIP 2 to final status. The current requirement is that "the reference implementation is complete and accepted by the community". Luke intends to apply BIP 2's more specific criteria to itself, which requires rough consensus on the mailing list and addressing all objections. If there are no outstanding objections by April 9th, 2016, the draft BIP will be considered to have reached rough consensus and updated to Final Status. 2016-03-18T22:52:55+00:00 + Dave suggests that the BIP authors should be allowed to decide for themselves which wiki is better instead of arguing. He proposes using Draft-BIP2's provision for authors to specify their own backup wiki as policy in all cases, eliminating the need for a backup wiki altogether. This would allow for greater flexibility and autonomy among authors.In a discussion between Btc Drak and Luke Dashjr about the use of external sources for BIP comments, Luke argues that BIP comments are not part of the BIP itself and can be kept external. Btc Drak objects to using external sources and suggests using the Wiki feature at bitcoin/bips. Luke clarifies that stronger moderation was needed, which is why the BIP process was moved to GitHub. However, he believes that such moderation is unnecessary for BIP comments. The discussion ends without reaching a resolution.Luke suggests that BIP comments should not be linked to external sources like the Bitcoin Wiki but rather made using the Wiki feature at bitcoin/bips itself. External sources are bound to go stale over time. The forum for comments should have a low barrier of use, and the Bitcoin Wiki requires only a request for editing privileges unlike GitHub wiki that would require reading and agreeing to a lengthy Terms of Service contract. The Bitcoin Wiki has been shown to stand the test of time and is less likely to move than the GitHub repository. The BIP process originated on the Wiki and was only moved to GitHub because stronger moderation was needed. Such moderation is unnecessary for BIP Comments. It is suggested that non-reference implementation lists/links be moved to BIP Comments rather than constantly revising the BIPs with them.Mustafa Al-Bassam raises concerns about the adoption of hard-fork BIP by the entire Bitcoin economy. He points out that even if a small minority refuses to accept a hard fork, it can veto the entire process. Another member clarifies that the hardfork can still happen, but for it to move to the final state, deployment needs to be universal. The discussion highlights the importance of unanimous agreement in the Bitcoin ecosystem for hard forks to be successful.In a conversation between Luke Dashjr and Mustafa Al-Bassam, they discuss the wording of a soft-fork that does not become final as long as a hard-fork has potentially-majority support or at most three months. Mustafa raises concerns about the requirement for adoption from the entire Bitcoin economy for a hard-fork BIP. He questions what would happen if one shop owner out of thousands did not adapt to the hard-fork. Luke clarifies that one shop cannot operate in a vacuum and they will soon find themselves no longer selling in exchange for bitcoin payments. The discussion concludes that any hard fork BIPs are unlikely to reach final status.Jorge Timón raises concerns about an attacker preventing a BIP from reaching final status. Mustafa Al-Bassam proposes a definition for when a hard fork becomes active, but Timón points out that an attacker could easily prevent a BIP from becoming final with little time or effort. While there may not be an obvious incentive for such an attack, Timón argues that some people might do it purely for the enjoyment of causing trouble. He suggests that any hard fork BIPs are unlikely to reach final status.Luke Dashjr opens a pull request to move BIP 2 to final status. The current requirement is that "the reference implementation is complete and accepted by the community". Luke intends to apply BIP 2's more specific criteria to itself, which requires rough consensus on the mailing list and addressing all objections. If there are no outstanding objections by April 9th, 2016, the draft BIP will be considered to have reached rough consensus and updated to Final Status. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml b/static/bitcoin-dev/March_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml index 1cb02b4d1f..7c60f2ac32 100644 --- a/static/bitcoin-dev/March_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml +++ b/static/bitcoin-dev/March_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Process: Status, comments, and copyright licenses - 2023-08-01T17:42:26.680157+00:00 + 2025-09-26T15:41:49.536647+00:00 + python-feedgen Mustafa Al-Bassam 2016-03-10 00:37:46+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - BIP Process: Status, comments, and copyright licenses - 2023-08-01T17:42:26.681157+00:00 + 2025-09-26T15:41:49.536822+00:00 - The Bitcoin Improvement Proposals (BIPs) are currently overseen by the mailing list, which could lead to centralized control. A proposal has been made to replace the mailing list with a "public discussion medium" such as forums or conferences. Luke Dashjr has created a draft BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concern about too much control being given to those who control the mailing list and wiki.Luke Dashjr suggested keeping reviews on the mailing list while using author-chosen forums in addition to the Bitcoin Wiki. Ryan Grant questioned the process for changing the status of a BIP from Draft to Active when rough consensus is reached on the mailing list. Luke explained that the wiki page is for leaving comments after discussion is over, and all review should remain on the mailing list. He also suggested that any forum used for review should have indisputable records of moderation and user edits.Luke Dashjr has made changes to BIP 2 to reduce hard feelings during comments. He proposed that a BIP author gather new/edited comment titles and report them once a week. Mediawiki offers watchlists for this purpose, and the wiki as a whole should be verifiable.A draft BIP by Luke Dashjr provides clarification on the Status field, expands allowable licenses, and adds public comments. Feedback on the draft is welcome. BIP99 aims to establish safe deployment requirements for an uncontroversial hardfork, but the concept of "adoption consensus" needs a neutral term. Suggestions are sought to make this clearer.Dave Scotese suggested that rules and code define Bitcoin, but consensus is needed after release. Gavin Andresen expressed concern about the definition of "consensus" giving too much control to the mailing list and wiki. Suggestions to make the meaning of "consensus" clear are welcomed.Jorge Timón suggested finding another term for "consensus" in the BIP document to avoid confusion. Luke-Jr agreed and proposed using "concord rules/code" instead of "consensus rules/code".Gavin Andresen expressed concern about the definition of "consensus" in the BIP process, giving too much control to the mailing list and wiki. He added a statement clarifying that the criteria for updating the status of BIPs should not be used to oppose or reject a BIP.The overuse of the term "consensus" in various contexts has caused confusion. Suggestions for alternative terms are welcomed. Luke-Jr suggested replacing it with "nearly universal acceptance" or "ecosystem-harmonious".Luke Dashjr and Dave Scotese discussed the need for coordination among multiple applications providing their own implementations of API/RPC and corresponding BIPs. They agreed that only one application would be standard to avoid confusion. The status of a BIP and comments should be unrelated metrics. The author of a BIP should be allowed to specify other internet locations for comments, but this could potentially be abused.Luke Dashjr proposed a draft BIP that provides clarity on the Status field, expands allowable licenses, and introduces public comments. Gavin Andresen expressed concerns about the definition of "consensus" giving too much control to the mailing list and wiki.Dave Scotese addressed the question of multiple applications providing their own implementations of API/RPC and corresponding BIPs. He stated that only one such application should be standard to avoid confusion. The status of a BIP and comments should not influence each other. The author of a BIP should be allowed to specify other internet locations for comments, although this could be potentially abused.Luke Dashjr requested objections to reach consensus on formally defining consensus. Clear reasoning must be given for objections not deemed substantiated by the community. Comments on BIPs should be solicited on the bitcoin-dev mailing list and summarized fairly in the wiki. Wiki registration and monitoring should not be a required hurdle to participation.Luke Dashjr completed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. Comments and status are unrelated metrics. The author of a BIP can specify other internet locations for comments.Luke Dashjr proposed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concerns about the definition of "consensus" giving too much centralized control.Dave Scotese stated that multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. The status of a BIP and comments should not directly influence each other. The author of a BIP should be allowed to specify other internet locations for comments. Clear reasoning must be offered for objections not deemed substantiated by the community.Luke Dashjr requested objections for consensus on formally defining consensus. Comments on BIPs should be solicited on 2016-03-10T00:37:46+00:00 + The Bitcoin Improvement Proposals (BIPs) are currently overseen by the mailing list, which could lead to centralized control. A proposal has been made to replace the mailing list with a "public discussion medium" such as forums or conferences. Luke Dashjr has created a draft BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concern about too much control being given to those who control the mailing list and wiki.Luke Dashjr suggested keeping reviews on the mailing list while using author-chosen forums in addition to the Bitcoin Wiki. Ryan Grant questioned the process for changing the status of a BIP from Draft to Active when rough consensus is reached on the mailing list. Luke explained that the wiki page is for leaving comments after discussion is over, and all review should remain on the mailing list. He also suggested that any forum used for review should have indisputable records of moderation and user edits.Luke Dashjr has made changes to BIP 2 to reduce hard feelings during comments. He proposed that a BIP author gather new/edited comment titles and report them once a week. Mediawiki offers watchlists for this purpose, and the wiki as a whole should be verifiable.A draft BIP by Luke Dashjr provides clarification on the Status field, expands allowable licenses, and adds public comments. Feedback on the draft is welcome. BIP99 aims to establish safe deployment requirements for an uncontroversial hardfork, but the concept of "adoption consensus" needs a neutral term. Suggestions are sought to make this clearer.Dave Scotese suggested that rules and code define Bitcoin, but consensus is needed after release. Gavin Andresen expressed concern about the definition of "consensus" giving too much control to the mailing list and wiki. Suggestions to make the meaning of "consensus" clear are welcomed.Jorge Timón suggested finding another term for "consensus" in the BIP document to avoid confusion. Luke-Jr agreed and proposed using "concord rules/code" instead of "consensus rules/code".Gavin Andresen expressed concern about the definition of "consensus" in the BIP process, giving too much control to the mailing list and wiki. He added a statement clarifying that the criteria for updating the status of BIPs should not be used to oppose or reject a BIP.The overuse of the term "consensus" in various contexts has caused confusion. Suggestions for alternative terms are welcomed. Luke-Jr suggested replacing it with "nearly universal acceptance" or "ecosystem-harmonious".Luke Dashjr and Dave Scotese discussed the need for coordination among multiple applications providing their own implementations of API/RPC and corresponding BIPs. They agreed that only one application would be standard to avoid confusion. The status of a BIP and comments should be unrelated metrics. The author of a BIP should be allowed to specify other internet locations for comments, but this could potentially be abused.Luke Dashjr proposed a draft BIP that provides clarity on the Status field, expands allowable licenses, and introduces public comments. Gavin Andresen expressed concerns about the definition of "consensus" giving too much control to the mailing list and wiki.Dave Scotese addressed the question of multiple applications providing their own implementations of API/RPC and corresponding BIPs. He stated that only one such application should be standard to avoid confusion. The status of a BIP and comments should not influence each other. The author of a BIP should be allowed to specify other internet locations for comments, although this could be potentially abused.Luke Dashjr requested objections to reach consensus on formally defining consensus. Clear reasoning must be given for objections not deemed substantiated by the community. Comments on BIPs should be solicited on the bitcoin-dev mailing list and summarized fairly in the wiki. Wiki registration and monitoring should not be a required hurdle to participation.Luke Dashjr completed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. Comments and status are unrelated metrics. The author of a BIP can specify other internet locations for comments.Luke Dashjr proposed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concerns about the definition of "consensus" giving too much centralized control.Dave Scotese stated that multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. The status of a BIP and comments should not directly influence each other. The author of a BIP should be allowed to specify other internet locations for comments. Clear reasoning must be offered for objections not deemed substantiated by the community.Luke Dashjr requested objections for consensus on formally defining consensus. Comments on BIPs should be solicited on - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_BIP147-minor-error.xml b/static/bitcoin-dev/March_2016/combined_BIP147-minor-error.xml index 430f12e222..e6e33da977 100644 --- a/static/bitcoin-dev/March_2016/combined_BIP147-minor-error.xml +++ b/static/bitcoin-dev/March_2016/combined_BIP147-minor-error.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP147 minor error - 2023-08-01T17:58:31.296609+00:00 + 2025-09-26T15:41:51.650963+00:00 + python-feedgen Sergio Demian Lerner 2016-03-22 10:39:51+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP147 minor error - 2023-08-01T17:58:31.296609+00:00 + 2025-09-26T15:41:51.651096+00:00 - On March 21, 2016, Sergio Demian Lerner reported a minor error in BIP147 to the bitcoin-dev mailing list. The BIP147 defines the cost of a sigop in traditional script as 4 and the cost of a sigop in a witness program as 1. The new rule states that the total sigop cost should be no more than 80,000. However, the code implements the rule differently, using the condition (nSigOps + (nWitSigOps + 3)/4 > MAX_BLOCK_SIGOPS) to determine if there is an error. This implementation does not align with what was defined in the BIP147.To demonstrate the error in the implemented code, Lerner provided an example. He stated that nSigOps = 1 and nWitSigOps = 79999, which does not violate the BIP147 definition but does cause an error in the implemented code. This discrepancy between the BIP definition and the code's implementation can lead to confusion and potential issues in the Bitcoin network.Lerner highlighted this error in a post to the bitcoin-dev mailing list, drawing attention to the need for the code to accurately reflect the rules defined in BIP147. By addressing this issue and ensuring consistency between the BIP and the code, developers can prevent such errors and maintain the integrity of the Bitcoin protocol. 2016-03-22T10:39:51+00:00 + On March 21, 2016, Sergio Demian Lerner reported a minor error in BIP147 to the bitcoin-dev mailing list. The BIP147 defines the cost of a sigop in traditional script as 4 and the cost of a sigop in a witness program as 1. The new rule states that the total sigop cost should be no more than 80,000. However, the code implements the rule differently, using the condition (nSigOps + (nWitSigOps + 3)/4 > MAX_BLOCK_SIGOPS) to determine if there is an error. This implementation does not align with what was defined in the BIP147.To demonstrate the error in the implemented code, Lerner provided an example. He stated that nSigOps = 1 and nWitSigOps = 79999, which does not violate the BIP147 definition but does cause an error in the implemented code. This discrepancy between the BIP definition and the code's implementation can lead to confusion and potential issues in the Bitcoin network.Lerner highlighted this error in a post to the bitcoin-dev mailing list, drawing attention to the need for the code to accurately reflect the rules defined in BIP147. By addressing this issue and ensuring consistency between the BIP and the code, developers can prevent such errors and maintain the integrity of the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_BIP75-Out-of-Band-Address-Exchange.xml b/static/bitcoin-dev/March_2016/combined_BIP75-Out-of-Band-Address-Exchange.xml index a318c37c46..0680feff91 100644 --- a/static/bitcoin-dev/March_2016/combined_BIP75-Out-of-Band-Address-Exchange.xml +++ b/static/bitcoin-dev/March_2016/combined_BIP75-Out-of-Band-Address-Exchange.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP75 - Out of Band Address Exchange - 2023-08-01T17:58:04.306704+00:00 + 2025-09-26T15:42:02.218015+00:00 + python-feedgen James MacWhyte 2016-03-17 01:23:09+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP75 - Out of Band Address Exchange - 2023-08-01T17:58:04.306704+00:00 + 2025-09-26T15:42:02.218193+00:00 - On March 1, a new Bitcoin Improvement Proposal (BIP) was proposed, tentatively assigned number 75 and titled "Out of Band Address Exchange using Payment Protocol Encryption". The proposal suggests adding optional fields to the BIP70 paymentDetails message. These fields include subtractable fee, fee per kb, and replace by fee. James MacWhyte believes that these extensions should be included in the new BIP as a general modernization of BIP70. However, Andreas Schildbach disagrees and argues that these extensions should go to separate BIPs since they are unrelated to secure and authenticated bi-directional BIP70 communication.Justin Newton is open to either leaving the extensions in or creating a separate BIP. In response to the fee part of BIP75, Schildbach proposes declaring an absolute amount that the payee is willing to cover instead of letting the payee define a fee rate. He suggests deducting the amount from the BIP70 payment message and displaying only the exceeding amount if it exceeds existing fee policies to avoid disputes. The discussion continues on the bitcoin-dev mailing list.There is a general issue with the Bitcoin Improvement Proposal process regarding multiple orthogonal "sub-BIPs". For example, BIP32 faces this issue where HD wallets implement the derivation part but not the hierarchy part. While splitting BIP32 into two BIPs without content changes was declined, there is no harm in using a BIP for a small thing, and BIP numbers are infinite. James MacWhyte's proposal for BIP75 has been tentatively assigned number 75 and changed the title to be more accurate. Some optional fields have been added to the BIP70 paymentDetails message, including subtractable fee, fee per kb, and replace by fee. These extensions clarify the fee and are not related to secure and authenticated bi-directional BIP70 communication. Andreas Schildbach believes that these extensions should go to separate BIPs to avoid polluting the original idea of BIP75. James MacWhyte, on the other hand, sees BIP75 as a general modernization of BIP70 and believes it is acceptable to include these extensions in the new BIP.In summary, a new version of BIP has been proposed, tentatively assigned number 75, and titled "Out of Band Address Exchange using Payment Protocol Encryption". The proposal suggests adding optional fields to the paymentDetails message, including subtractable fee, fee per kb, and replace by fee. There are differing opinions on whether these extensions should be included in the new BIP or placed in separate BIPs. The Bitcoin Improvement Proposal process has encountered issues with multiple sub-BIPs, and there are ongoing discussions regarding the best approach for BIP75. 2016-03-17T01:23:09+00:00 + On March 1, a new Bitcoin Improvement Proposal (BIP) was proposed, tentatively assigned number 75 and titled "Out of Band Address Exchange using Payment Protocol Encryption". The proposal suggests adding optional fields to the BIP70 paymentDetails message. These fields include subtractable fee, fee per kb, and replace by fee. James MacWhyte believes that these extensions should be included in the new BIP as a general modernization of BIP70. However, Andreas Schildbach disagrees and argues that these extensions should go to separate BIPs since they are unrelated to secure and authenticated bi-directional BIP70 communication.Justin Newton is open to either leaving the extensions in or creating a separate BIP. In response to the fee part of BIP75, Schildbach proposes declaring an absolute amount that the payee is willing to cover instead of letting the payee define a fee rate. He suggests deducting the amount from the BIP70 payment message and displaying only the exceeding amount if it exceeds existing fee policies to avoid disputes. The discussion continues on the bitcoin-dev mailing list.There is a general issue with the Bitcoin Improvement Proposal process regarding multiple orthogonal "sub-BIPs". For example, BIP32 faces this issue where HD wallets implement the derivation part but not the hierarchy part. While splitting BIP32 into two BIPs without content changes was declined, there is no harm in using a BIP for a small thing, and BIP numbers are infinite. James MacWhyte's proposal for BIP75 has been tentatively assigned number 75 and changed the title to be more accurate. Some optional fields have been added to the BIP70 paymentDetails message, including subtractable fee, fee per kb, and replace by fee. These extensions clarify the fee and are not related to secure and authenticated bi-directional BIP70 communication. Andreas Schildbach believes that these extensions should go to separate BIPs to avoid polluting the original idea of BIP75. James MacWhyte, on the other hand, sees BIP75 as a general modernization of BIP70 and believes it is acceptable to include these extensions in the new BIP.In summary, a new version of BIP has been proposed, tentatively assigned number 75, and titled "Out of Band Address Exchange using Payment Protocol Encryption". The proposal suggests adding optional fields to the paymentDetails message, including subtractable fee, fee per kb, and replace by fee. There are differing opinions on whether these extensions should be included in the new BIP or placed in separate BIPs. The Bitcoin Improvement Proposal process has encountered issues with multiple sub-BIPs, and there are ongoing discussions regarding the best approach for BIP75. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_Bitcoin-Guarantees-Strong-not-Eventual-Consistency-.xml b/static/bitcoin-dev/March_2016/combined_Bitcoin-Guarantees-Strong-not-Eventual-Consistency-.xml index 5b3335e0d7..eb49cf53eb 100644 --- a/static/bitcoin-dev/March_2016/combined_Bitcoin-Guarantees-Strong-not-Eventual-Consistency-.xml +++ b/static/bitcoin-dev/March_2016/combined_Bitcoin-Guarantees-Strong-not-Eventual-Consistency-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Guarantees Strong, not Eventual, Consistency. - 2023-08-01T17:54:26.099353+00:00 + 2025-09-26T15:41:57.993400+00:00 + python-feedgen Emin Gün Sirer 2016-03-02 16:56:28+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Guarantees Strong, not Eventual, Consistency. - 2023-08-01T17:54:26.099353+00:00 + 2025-09-26T15:41:57.993582+00:00 - The concept of eventual consistency is commonly used in distributed computing to ensure high availability in systems. It guarantees that all accesses to a specific data item will eventually return its last updated value if no new updates are made. However, this does not require a system to have a final state as most practical database systems operate continuously without one.Regarding Bitcoin, the reference client's listreceivedbyaddress function returns the number of confirmations by default, and getbalance and getreceivedbyaddress functions take a number of confirmations as an argument. This is done to protect the application from suffix reorgs, where a block is removed from the blockchain due to a fork. In practice, there may be a difference between 0 probability and epsilon probability, but it is negligible due to hardware errors. Therefore, an omega can be selected such that the chance of processor mis-execution is higher than observing a reorganization.Contrary to popular belief, Bitcoin does not provide eventual consistency. The author of a post on the Bitcoin-dev mailing list argues that Bitcoin actually guarantees strong consistency. Eventually consistent systems do not have a final state and may give inconsistent responses to queries over time. However, Bitcoin does not ignore the contents of the last X blocks, and a Bitcoin node queried about the current blockchain state will give inconsistent answers when there are block rearrangements. This inconsistency indicates that Bitcoin does not provide strong consistency.Furthermore, Bitcoin provides a probabilistic, accumulative probability rather than a perfect one. This probability drops exponentially but is never exactly 0. This is similar to hash collisions, which Bitcoin relies on for its correctness.The author of the post hopes to dispel the false perception that Bitcoin is eventually consistent and believes that this idea has become a bad meme that should be laid to rest. Bitcoin actually guarantees strong consistency and operates differently from systems that provide eventual consistency. 2016-03-02T16:56:28+00:00 + The concept of eventual consistency is commonly used in distributed computing to ensure high availability in systems. It guarantees that all accesses to a specific data item will eventually return its last updated value if no new updates are made. However, this does not require a system to have a final state as most practical database systems operate continuously without one.Regarding Bitcoin, the reference client's listreceivedbyaddress function returns the number of confirmations by default, and getbalance and getreceivedbyaddress functions take a number of confirmations as an argument. This is done to protect the application from suffix reorgs, where a block is removed from the blockchain due to a fork. In practice, there may be a difference between 0 probability and epsilon probability, but it is negligible due to hardware errors. Therefore, an omega can be selected such that the chance of processor mis-execution is higher than observing a reorganization.Contrary to popular belief, Bitcoin does not provide eventual consistency. The author of a post on the Bitcoin-dev mailing list argues that Bitcoin actually guarantees strong consistency. Eventually consistent systems do not have a final state and may give inconsistent responses to queries over time. However, Bitcoin does not ignore the contents of the last X blocks, and a Bitcoin node queried about the current blockchain state will give inconsistent answers when there are block rearrangements. This inconsistency indicates that Bitcoin does not provide strong consistency.Furthermore, Bitcoin provides a probabilistic, accumulative probability rather than a perfect one. This probability drops exponentially but is never exactly 0. This is similar to hash collisions, which Bitcoin relies on for its correctness.The author of the post hopes to dispel the false perception that Bitcoin is eventually consistent and believes that this idea has become a bad meme that should be laid to rest. Bitcoin actually guarantees strong consistency and operates differently from systems that provide eventual consistency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_Hardfork-to-fix-difficulty-drop-algorithm.xml b/static/bitcoin-dev/March_2016/combined_Hardfork-to-fix-difficulty-drop-algorithm.xml index 5603348f76..b85d870dbd 100644 --- a/static/bitcoin-dev/March_2016/combined_Hardfork-to-fix-difficulty-drop-algorithm.xml +++ b/static/bitcoin-dev/March_2016/combined_Hardfork-to-fix-difficulty-drop-algorithm.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hardfork to fix difficulty drop algorithm - 2023-08-01T17:55:46.527931+00:00 + 2025-09-26T15:41:47.421096+00:00 + python-feedgen Dave Hudson 2016-03-09 23:24:15+00:00 @@ -127,13 +128,13 @@ - python-feedgen + 2 Combined summary - Hardfork to fix difficulty drop algorithm - 2023-08-01T17:55:46.528925+00:00 + 2025-09-26T15:41:47.421263+00:00 - In an email exchange between Bob McElrath and Dave Hudson, they discuss the challenges of accurately measuring the hashrate in Bitcoin. Hudson suggests a damping-based design for measurement, but McElrath expresses doubts about its accuracy over short timeframes. Additionally, the consensus data lacks a strong notion of time, making it difficult to calculate difficulty based on anything outside of the consensus.Henning Kopp expresses his thoughts on the community's process for making decisions regarding Bitcoin. He believes that the community should demonstrate a good process for making such decisions and show that they can separate meaningful underlying principles from implementation details. Another individual disagrees with Kopp's statement that the coin limit was a meaningful underlying principle while mining reward halving was an implementation detail. They provide a link to a post by Dr. Back, who had been pointing this out for some time.Bitcoin miners have invested heavily in the industry with hash rates increasing by almost 70% in the last six to seven months. However, there are several ways in which this information could be irrelevant; some miners may expect to breakeven before the halving, while others may believe that the halving will not pose any problems. In addition, many miners anticipate that the price of bitcoin will increase around the time of the halving, though others believe it could just as easily decrease. The fact that these same miners were mining when the coin price was $250 last year indicates that profitability won't be a significant concern if the price remains around $400.The problem of working out a timeframe over which to run the derivative calculations is not an easy one. From a measurement theory perspective, this can be done by treating each block as a measurement and performing error propagation to derive an error on the derivatives. Bitcoin's block timing follows the statistical theory of Poisson Point Process, and there is a lot of literature available on how to handle this.The difficulty retargeting in cryptocurrencies is a matter of concern. A damping-based design is an obvious choice for this, but the problem is working out a timeframe over which to run the derivative calculations. The measurement of hashrate is pretty inaccurate, and even 2016 events aren't enough to predict difficulty swings accurately. To react meaningfully to a significant loss of hashing, a window of around two weeks is necessary.Bitcoin developers are discussing the upcoming subsidy halving this July and the potential for a significant drop in mining rate, which could lead to longer block intervals and the block size limit being hit sooner than expected. They propose a hardfork to the difficulty adjustment algorithm so it can adapt quicker to such a drop in mining rate. Some suggest adjusting the economic parameter instead of the difficulty targeting mechanism. It is important to demonstrate a good process for making decisions and separating meaningful underlying principles from implementation details.Luke Dashjr suggests an adjustment to the reward schedule to alleviate concerns about the upcoming subsidy halving. He suggests that instead of a large supply shock every four years, the reward could drop yearly or at each difficulty adjustment in a way that smooths out the inflation curve. He believes this could increase confidence in the system if the community demonstrates a good decision-making process.The success of Bitcoin has led to discussions about hard forks and the possibility of creating a new Bitcoin. The creation of a new Bitcoin would benefit from the brand awareness of Bitcoin and would not require consensus if the market values it more than the original Bitcoin. However, a hard fork is still considered contentious, and a soft fork is preferable. It is also possible to create an altcoin with a different coin limit and a smooth inflation schedule instead of abrupt drops.In a discussion among Bitcoin developers, Gregory Maxwell questions the proposal of a large difficulty drop in the Bitcoin network, stating that it would only make sense if there was evidence suggesting a significant decrease in hashrate. Paul suggests that miners should invest in hardware closer to the halving, rather than making investments too soon. He notes that assuming miners are already located in low-power-cost areas, the difficulty will quickly rise to compensate for improvements in power efficiency, which could result in the cancellation of any benefits by July.Drak has tested code for an altcoin that could potentially address the issue of the block size limit being reached earlier than anticipated. However, it is unclear which altcoin he is referring to. Luke Dashjr argues that historically, difficulty has followed value rather than being influenced by factors such as a longer block interval and higher per-block transaction volume. Nonetheless, having prepared code for negative scenarios in case of an emergency seems reasonable. The development of a local fee market and an increase in fees could attract more miners back to the network, along with an expected higher exchange rate. Pavel Janik suggests that if the blockchain network experiences a longer block interval, it could result in a higher per-block transaction volume, potentially reaching the block size limit sooner. However, if the coin's exchange rate can accommodate this expectation, a local fee market would develop, leading to increased fees and 2016-03-09T23:24:15+00:00 + In an email exchange between Bob McElrath and Dave Hudson, they discuss the challenges of accurately measuring the hashrate in Bitcoin. Hudson suggests a damping-based design for measurement, but McElrath expresses doubts about its accuracy over short timeframes. Additionally, the consensus data lacks a strong notion of time, making it difficult to calculate difficulty based on anything outside of the consensus.Henning Kopp expresses his thoughts on the community's process for making decisions regarding Bitcoin. He believes that the community should demonstrate a good process for making such decisions and show that they can separate meaningful underlying principles from implementation details. Another individual disagrees with Kopp's statement that the coin limit was a meaningful underlying principle while mining reward halving was an implementation detail. They provide a link to a post by Dr. Back, who had been pointing this out for some time.Bitcoin miners have invested heavily in the industry with hash rates increasing by almost 70% in the last six to seven months. However, there are several ways in which this information could be irrelevant; some miners may expect to breakeven before the halving, while others may believe that the halving will not pose any problems. In addition, many miners anticipate that the price of bitcoin will increase around the time of the halving, though others believe it could just as easily decrease. The fact that these same miners were mining when the coin price was $250 last year indicates that profitability won't be a significant concern if the price remains around $400.The problem of working out a timeframe over which to run the derivative calculations is not an easy one. From a measurement theory perspective, this can be done by treating each block as a measurement and performing error propagation to derive an error on the derivatives. Bitcoin's block timing follows the statistical theory of Poisson Point Process, and there is a lot of literature available on how to handle this.The difficulty retargeting in cryptocurrencies is a matter of concern. A damping-based design is an obvious choice for this, but the problem is working out a timeframe over which to run the derivative calculations. The measurement of hashrate is pretty inaccurate, and even 2016 events aren't enough to predict difficulty swings accurately. To react meaningfully to a significant loss of hashing, a window of around two weeks is necessary.Bitcoin developers are discussing the upcoming subsidy halving this July and the potential for a significant drop in mining rate, which could lead to longer block intervals and the block size limit being hit sooner than expected. They propose a hardfork to the difficulty adjustment algorithm so it can adapt quicker to such a drop in mining rate. Some suggest adjusting the economic parameter instead of the difficulty targeting mechanism. It is important to demonstrate a good process for making decisions and separating meaningful underlying principles from implementation details.Luke Dashjr suggests an adjustment to the reward schedule to alleviate concerns about the upcoming subsidy halving. He suggests that instead of a large supply shock every four years, the reward could drop yearly or at each difficulty adjustment in a way that smooths out the inflation curve. He believes this could increase confidence in the system if the community demonstrates a good decision-making process.The success of Bitcoin has led to discussions about hard forks and the possibility of creating a new Bitcoin. The creation of a new Bitcoin would benefit from the brand awareness of Bitcoin and would not require consensus if the market values it more than the original Bitcoin. However, a hard fork is still considered contentious, and a soft fork is preferable. It is also possible to create an altcoin with a different coin limit and a smooth inflation schedule instead of abrupt drops.In a discussion among Bitcoin developers, Gregory Maxwell questions the proposal of a large difficulty drop in the Bitcoin network, stating that it would only make sense if there was evidence suggesting a significant decrease in hashrate. Paul suggests that miners should invest in hardware closer to the halving, rather than making investments too soon. He notes that assuming miners are already located in low-power-cost areas, the difficulty will quickly rise to compensate for improvements in power efficiency, which could result in the cancellation of any benefits by July.Drak has tested code for an altcoin that could potentially address the issue of the block size limit being reached earlier than anticipated. However, it is unclear which altcoin he is referring to. Luke Dashjr argues that historically, difficulty has followed value rather than being influenced by factors such as a longer block interval and higher per-block transaction volume. Nonetheless, having prepared code for negative scenarios in case of an emergency seems reasonable. The development of a local fee market and an increase in fees could attract more miners back to the network, along with an expected higher exchange rate. Pavel Janik suggests that if the blockchain network experiences a longer block interval, it could result in a higher per-block transaction volume, potentially reaching the block size limit sooner. However, if the coin's exchange rate can accommodate this expectation, a local fee market would develop, leading to increased fees and - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml b/static/bitcoin-dev/March_2016/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml index d279ef56fe..3555341f16 100644 --- a/static/bitcoin-dev/March_2016/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml +++ b/static/bitcoin-dev/March_2016/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report - 2023-08-01T15:02:51.488157+00:00 + 2025-09-26T15:41:38.967137+00:00 + python-feedgen Gregory Maxwell 2016-03-01 00:57:58+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report - 2023-08-01T15:02:51.488157+00:00 + 2025-09-26T15:41:38.967270+00:00 - In the Bitcoin-dev mailing list conversation, Wei initiates a discussion on the privacy features of the Bitcoin-Qt wallet application. Kristov Atlas responds with his best guesses, highlighting key aspects of the application's privacy features.Bitcoin-Qt implements cryptographic randomization of transaction ordering, which provides maximum privacy. However, the BIP 69 recommendation could also offer the same level of privacy if universally used. The joinmarket module can be used with Bitcoin-Qt to incorporate coinjoins. Currently, there are no decentralized mixing tools available that do not harm user privacy.The article mentions that Bitcoin-Qt does not implement anti-features like donations and always maintains the highest possible FP rate. To obtain balance information, the software makes remote queries, but users can direct these queries to use Tor for all communications. All network connections are independent via Tor by default, ensuring privacy. Separate wallets are required for separate "identities".One concern raised is that an attacker could deduce that transactions come from the same client by observing transactions signed by private keys from multiple wallets. However, changing the wallet ensures that the node no longer knows any of them.The article emphasizes that reliable deletion of private data is not feasible on current hardware/OSes. Therefore, users are advised to use OS-level encryption for local privacy protection. Backups are stored locally, and there is no linkage to email or SMS.Bitcoin-Qt does not perform any external lookup related to identifying transaction senders or recipients. It connects to known p2p full nodes to bootstrap the connection to the Bitcoin p2p network. Users are recommended to run Tor to prevent identifiable traffic, except for timing/volume analysis.The application allows users to encrypt the wallet file with a password, preventing decryption of private keys without the password. Each wallet file can have its own single password for spending protection, and there is no custodianship involved. The article notes that no obvious telemetry data is being sent.Regarding the source code and building process, the application supports a deterministic build process actively audited by multiple parties who post cryptographic signatures of their duplicated builds. This ensures that users can compile the application themselves in a manner that produces an identical binary version to the distributed one.In conclusion, the email thread provides answers to various privacy and security questions related to Bitcoin-Qt. It addresses transaction formatting, mixing, donations, balance queries, network privacy, physical access, custodianship, telemetry data, and source code and building. The Open Bitcoin Privacy Project includes Bitcoin-Qt in its survey to measure wallet privacy and requests developers to answer a set of questions about how different wallets handle these aspects. 2016-03-01T00:57:58+00:00 + In the Bitcoin-dev mailing list conversation, Wei initiates a discussion on the privacy features of the Bitcoin-Qt wallet application. Kristov Atlas responds with his best guesses, highlighting key aspects of the application's privacy features.Bitcoin-Qt implements cryptographic randomization of transaction ordering, which provides maximum privacy. However, the BIP 69 recommendation could also offer the same level of privacy if universally used. The joinmarket module can be used with Bitcoin-Qt to incorporate coinjoins. Currently, there are no decentralized mixing tools available that do not harm user privacy.The article mentions that Bitcoin-Qt does not implement anti-features like donations and always maintains the highest possible FP rate. To obtain balance information, the software makes remote queries, but users can direct these queries to use Tor for all communications. All network connections are independent via Tor by default, ensuring privacy. Separate wallets are required for separate "identities".One concern raised is that an attacker could deduce that transactions come from the same client by observing transactions signed by private keys from multiple wallets. However, changing the wallet ensures that the node no longer knows any of them.The article emphasizes that reliable deletion of private data is not feasible on current hardware/OSes. Therefore, users are advised to use OS-level encryption for local privacy protection. Backups are stored locally, and there is no linkage to email or SMS.Bitcoin-Qt does not perform any external lookup related to identifying transaction senders or recipients. It connects to known p2p full nodes to bootstrap the connection to the Bitcoin p2p network. Users are recommended to run Tor to prevent identifiable traffic, except for timing/volume analysis.The application allows users to encrypt the wallet file with a password, preventing decryption of private keys without the password. Each wallet file can have its own single password for spending protection, and there is no custodianship involved. The article notes that no obvious telemetry data is being sent.Regarding the source code and building process, the application supports a deterministic build process actively audited by multiple parties who post cryptographic signatures of their duplicated builds. This ensures that users can compile the application themselves in a manner that produces an identical binary version to the distributed one.In conclusion, the email thread provides answers to various privacy and security questions related to Bitcoin-Qt. It addresses transaction formatting, mixing, donations, balance queries, network privacy, physical access, custodianship, telemetry data, and source code and building. The Open Bitcoin Privacy Project includes Bitcoin-Qt in its survey to measure wallet privacy and requests developers to answer a set of questions about how different wallets handle these aspects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_Proposed-BIP-Maximum-block-size-consensus-rule-based-on-median-block-size-adaptive-block-size-.xml b/static/bitcoin-dev/March_2016/combined_Proposed-BIP-Maximum-block-size-consensus-rule-based-on-median-block-size-adaptive-block-size-.xml index e9923c6f3b..55677c2ef9 100644 --- a/static/bitcoin-dev/March_2016/combined_Proposed-BIP-Maximum-block-size-consensus-rule-based-on-median-block-size-adaptive-block-size-.xml +++ b/static/bitcoin-dev/March_2016/combined_Proposed-BIP-Maximum-block-size-consensus-rule-based-on-median-block-size-adaptive-block-size-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed BIP: Maximum block size consensus rule based on median block size (adaptive block size) - 2023-08-01T18:02:43.122261+00:00 + 2025-09-26T15:42:00.106850+00:00 + python-feedgen Tier Nolan 2016-03-25 18:48:15+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Proposed BIP: Maximum block size consensus rule based on median block size (adaptive block size) - 2023-08-01T18:02:43.122261+00:00 + 2025-09-26T15:42:00.106975+00:00 - The email thread discusses the proposal to change the MAX_BLOCK_SIZE consensus rule in the Bitcoin network. The proposed change is based on the median block size over the last three months, allowing the maximum block size to increase or decrease based on actual network usage. The purpose of this consensus rule change is to allow the network's capacity to adjust to changes in user demand and scaling related technology advancements, while still being protected from denial of service attacks.The use of floating point calculations in consensus code is considered a bad idea, so the standard practice is to use very large integers instead. The suggestion is made to use an array of integers in the get median function, even though the block size has to be an integer. This would still allow for a rounded-up integer limit on the block size.To gain acceptance for the proposed change, it is suggested to add a second limiter to the growth rate. One idea is to make it so that the block size isn't allowed to more than double every year, similar to the 1MB limit on the lower end. The graphs provided likely underestimate the growth rate, as the current 1MB limit inherently restricts things to that size.A draft BIP (Bitcoin Improvement Proposal) has been created to formalize the proposed change to the MAX_BLOCK_SIZE consensus rule. The draft is available on GitHub and was submitted by Chris Kleeschulte. 2016-03-25T18:48:15+00:00 + The email thread discusses the proposal to change the MAX_BLOCK_SIZE consensus rule in the Bitcoin network. The proposed change is based on the median block size over the last three months, allowing the maximum block size to increase or decrease based on actual network usage. The purpose of this consensus rule change is to allow the network's capacity to adjust to changes in user demand and scaling related technology advancements, while still being protected from denial of service attacks.The use of floating point calculations in consensus code is considered a bad idea, so the standard practice is to use very large integers instead. The suggestion is made to use an array of integers in the get median function, even though the block size has to be an integer. This would still allow for a rounded-up integer limit on the block size.To gain acceptance for the proposed change, it is suggested to add a second limiter to the growth rate. One idea is to make it so that the block size isn't allowed to more than double every year, similar to the 1MB limit on the lower end. The graphs provided likely underestimate the growth rate, as the current 1MB limit inherently restricts things to that size.A draft BIP (Bitcoin Improvement Proposal) has been created to formalize the proposed change to the MAX_BLOCK_SIZE consensus rule. The draft is available on GitHub and was submitted by Chris Kleeschulte. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_Proposed-BIP-extension-to-BIP-0070.xml b/static/bitcoin-dev/March_2016/combined_Proposed-BIP-extension-to-BIP-0070.xml index ed9475f66b..0d7873b59f 100644 --- a/static/bitcoin-dev/March_2016/combined_Proposed-BIP-extension-to-BIP-0070.xml +++ b/static/bitcoin-dev/March_2016/combined_Proposed-BIP-extension-to-BIP-0070.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed BIP extension to BIP 0070 - 2023-08-01T17:54:09.999711+00:00 + 2025-09-26T15:41:41.081685+00:00 + python-feedgen James MacWhyte 2016-03-09 01:17:11+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Proposed BIP extension to BIP 0070 - 2023-08-01T17:54:09.999711+00:00 + 2025-09-26T15:41:41.081848+00:00 - The Bitcoin Improvement Proposal (BIP) 70 Payment Protocol extension aims to create a permissioned and encrypted exchange of payment information between two parties. The extension enhances the Payment Protocol by ensuring that payment details can only be seen by the participants in the transaction. It also allows for store and forward servers to sign and serve Payment Requests, and gives the sender of funds the option of sharing their identity with the receiver.The proposed update to the Payment Protocol has three main goals. Firstly, it ensures that payment details are only visible to the participants in the transaction, enhancing privacy. Secondly, it allows for store and forward servers to enable mobile wallets to sign and serve Payment Requests, making the process more convenient. Lastly, it gives the senders of funds the option to share their identity with the receiver. This feature could be used to make bitcoin logs more human-readable or to help regulated financial entities meet regulatory requirements.The protocol is designed to be flexible, allowing developers to build different types of schemes while maintaining standard messages that can be forwarded between services if needed. The email thread also discusses the possibility of a user uploading authenticated PaymentRequests to an untrusted server, which would then encrypt and pass them on in response to InvoiceRequests.A draft BIP proposal has been made to update the Payment Protocol, with the goal of enabling two parties to exchange payment information in an encrypted manner. This update would automate wallet address communication and allow for off-blockchain transaction logs that are human-readable. The motivation behind this extension is to ensure payment details are only visible to participants, enable store and forward servers, and give senders the option of sharing their identity with the receiver.The proposed extension to BIP70 has several potential benefits. It could make bitcoin logs more human-readable, allow users to control who they release payment details to, help political campaigns meet regulatory requirements, and provide a way for regulated financial entities to meet their own regulatory requirements. The full proposal can be found on GitHub, and feedback is welcomed.In summary, the proposed update to the Payment Protocol aims to create a permissioned and encrypted exchange of payment information. It allows for automated communication of wallet addresses and enables the creation of human-readable off-blockchain transaction logs. The extension ensures that payment details are only visible to participants, allows for store and forward servers, and gives senders the option of sharing their identity with receivers. This update has the potential to make bitcoin logs more human-readable, help political campaigns comply with regulations, and provide a way for regulated financial entities to meet requirements. Justin W. Newton, Founder/CEO of Netki, Inc., has shared the full proposal on GitHub and is seeking feedback. 2016-03-09T01:17:11+00:00 + The Bitcoin Improvement Proposal (BIP) 70 Payment Protocol extension aims to create a permissioned and encrypted exchange of payment information between two parties. The extension enhances the Payment Protocol by ensuring that payment details can only be seen by the participants in the transaction. It also allows for store and forward servers to sign and serve Payment Requests, and gives the sender of funds the option of sharing their identity with the receiver.The proposed update to the Payment Protocol has three main goals. Firstly, it ensures that payment details are only visible to the participants in the transaction, enhancing privacy. Secondly, it allows for store and forward servers to enable mobile wallets to sign and serve Payment Requests, making the process more convenient. Lastly, it gives the senders of funds the option to share their identity with the receiver. This feature could be used to make bitcoin logs more human-readable or to help regulated financial entities meet regulatory requirements.The protocol is designed to be flexible, allowing developers to build different types of schemes while maintaining standard messages that can be forwarded between services if needed. The email thread also discusses the possibility of a user uploading authenticated PaymentRequests to an untrusted server, which would then encrypt and pass them on in response to InvoiceRequests.A draft BIP proposal has been made to update the Payment Protocol, with the goal of enabling two parties to exchange payment information in an encrypted manner. This update would automate wallet address communication and allow for off-blockchain transaction logs that are human-readable. The motivation behind this extension is to ensure payment details are only visible to participants, enable store and forward servers, and give senders the option of sharing their identity with the receiver.The proposed extension to BIP70 has several potential benefits. It could make bitcoin logs more human-readable, allow users to control who they release payment details to, help political campaigns meet regulatory requirements, and provide a way for regulated financial entities to meet their own regulatory requirements. The full proposal can be found on GitHub, and feedback is welcomed.In summary, the proposed update to the Payment Protocol aims to create a permissioned and encrypted exchange of payment information. It allows for automated communication of wallet addresses and enables the creation of human-readable off-blockchain transaction logs. The extension ensures that payment details are only visible to participants, allows for store and forward servers, and gives senders the option of sharing their identity with receivers. This update has the potential to make bitcoin logs more human-readable, help political campaigns comply with regulations, and provide a way for regulated financial entities to meet requirements. Justin W. Newton, Founder/CEO of Netki, Inc., has shared the full proposal on GitHub and is seeking feedback. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_Proposed-release-schedule-0-13-0.xml b/static/bitcoin-dev/March_2016/combined_Proposed-release-schedule-0-13-0.xml index 665049e00b..f18369e2b2 100644 --- a/static/bitcoin-dev/March_2016/combined_Proposed-release-schedule-0-13-0.xml +++ b/static/bitcoin-dev/March_2016/combined_Proposed-release-schedule-0-13-0.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed release schedule 0.13.0 - 2023-08-01T17:58:21.045170+00:00 + 2025-09-26T15:41:34.741839+00:00 + python-feedgen Wladimir J. van der Laan 2016-03-16 11:42:02+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Proposed release schedule 0.13.0 - 2023-08-01T17:58:21.045170+00:00 + 2025-09-26T15:41:34.741997+00:00 - In an email dated March 14, 2016, Wladimir J. van der Laan presented a release schedule for version 0.13.0 of Bitcoin. However, there was a mistake in the listing of the release dates, as they were mentioned as May 1 and May 15, 2015 instead of 2016. To track the progress of this project more actively, one can refer to the Bitcoin GitHub page, specifically the issue tracker and milestone section dedicated to version 0.13.0.The proposed release schedule for version 0.13.0 of the software entails various stages, each with its own set of deadlines and objectives. The first deadline is set for May 1st, 2015, which signifies the commencement of the translation process for the new version. During this phase, Transifex will be made available for translations; however, there will be a "soft" translation string freeze, implying that no significant changes to the strings will be allowed until the release. Additionally, translations for the previous version, 0.11, will be finalized and closed.The subsequent deadline is scheduled for May 15th, 2015, marking the feature freeze for version 0.13.0. From this point onwards, only bug fixes will be accepted until the final release. Furthermore, a complete translation string freeze will be implemented, disallowing any further modifications to the source language until the release.On June 6th, 2016, the 0.13 branch will be split off from the master branch, signaling the initiation of the Release Candidate cycle. The first RC for version 0.13.0 will be tagged and released during this phase. Additionally, merging for version 0.14 will commence on the master branch.Finally, the goal is to release the final version of 0.13.0 on July 1st, 2016. 2016-03-16T11:42:02+00:00 + In an email dated March 14, 2016, Wladimir J. van der Laan presented a release schedule for version 0.13.0 of Bitcoin. However, there was a mistake in the listing of the release dates, as they were mentioned as May 1 and May 15, 2015 instead of 2016. To track the progress of this project more actively, one can refer to the Bitcoin GitHub page, specifically the issue tracker and milestone section dedicated to version 0.13.0.The proposed release schedule for version 0.13.0 of the software entails various stages, each with its own set of deadlines and objectives. The first deadline is set for May 1st, 2015, which signifies the commencement of the translation process for the new version. During this phase, Transifex will be made available for translations; however, there will be a "soft" translation string freeze, implying that no significant changes to the strings will be allowed until the release. Additionally, translations for the previous version, 0.11, will be finalized and closed.The subsequent deadline is scheduled for May 15th, 2015, marking the feature freeze for version 0.13.0. From this point onwards, only bug fixes will be accepted until the final release. Furthermore, a complete translation string freeze will be implemented, disallowing any further modifications to the source language until the release.On June 6th, 2016, the 0.13 branch will be split off from the master branch, signaling the initiation of the Release Candidate cycle. The first RC for version 0.13.0 will be tagged and released during this phase. Additionally, merging for version 0.14 will commence on the master branch.Finally, the goal is to release the final version of 0.13.0 on July 1st, 2016. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_Services-bit-for-xthin-blocks.xml b/static/bitcoin-dev/March_2016/combined_Services-bit-for-xthin-blocks.xml index 478cfdb653..1323d97a76 100644 --- a/static/bitcoin-dev/March_2016/combined_Services-bit-for-xthin-blocks.xml +++ b/static/bitcoin-dev/March_2016/combined_Services-bit-for-xthin-blocks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Services bit for xthin blocks - 2023-08-01T17:56:50.325353+00:00 + 2025-09-26T15:41:43.192216+00:00 + python-feedgen Tier Nolan 2016-03-09 21:11:36+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Services bit for xthin blocks - 2023-08-01T17:56:50.325353+00:00 + 2025-09-26T15:41:43.192368+00:00 - Andrew Stone, a member of the Bitcoin Unlimited team, expressed satisfaction with their own process for documentation and discussion of cross-implementation standards. He sees the Bitcoin Improvement Proposal (BIP) process and the bitcoin-dev mailing list as Core specific. The BIP process allows for hashlocked descriptions of specifications to be implemented against. Stone proposed a process for claiming service bits, which involves justifying the claim, providing a finalized description of the feature within three months, deploying the feature within six months, and locking the bit after six months of active use.Luke Dashjr, in response to a proposal by Bitcoin Unlimited, clarified that the BIP process was actually created by Amir Taaki, not affiliated with Core, and encouraged Bitcoin Unlimited to use it for peer review from the wider Bitcoin development community. He offered to assign BIP numbers to the current Bitcoin Unlimited Improvement Proposals (BUIPs) if they meet the necessary requirements. Dashjr requested links to each of the BUIPs and noted that discussions may occur on other forums besides the mailing list.Stone wrote to the bitcoin-dev mailing list regarding the documentation and discussion of cross-implementation standards. Dashjr replied, stating that bitcoin-dev and the BIP process are not affiliated with Core, and suggested that Bitcoin Unlimited use the BIP process for peer review. He also offered to assign BIP numbers to the current BUIPs if they meet the requirements and requested links to them.Stone proposed using bit 4 as a services bit to indicate that the Bitcoin Unlimited client is capable of communicating thin blocks. Gregory Maxwell suggested a more general proposal that allows customization of user-agent specific service bits in the user-agent string. This would provide flexibility for future development and allow other clients to recognize or follow suit. The proposal does not change peer selection, and if it did, the preferred signaling mechanism would be the one in BIP 130. Stone also mentioned his tech services and ownership of Litmocracy and Meme Racing.A BIP concerning the use of a particular services bit for the extreme thin block protocol was sent to Luke jr for discussion. Bitcoin Unlimited has its own process for documentation and discussion on an uncensored forum. Stone requested interested engineers to join their forum with ideas and criticisms. It is up to Core to decide whether they want to preserve interoperability by avoiding the use of bit 1. The BIP proposes using a service bit to communicate support for thin block communication messages, with the most appropriate location being a service bit. The preferred signaling mechanism is likely the one in BIP 130, and numbers are obtained through writing BIPs.The email thread discussed the proposal to use bit 4 as a services bit for indicating that the Bitcoin Unlimited client can communicate thin blocks. Maxwell questioned if this would change peer selection and suggested using the signaling mechanism in BIP 130 if it does not. If it does change peer selection, a BIP documenting the usage should be written. The conversation ended without further discussion.The discussion highlighted the need for a services bit to indicate a node's capability to communicate thin blocks. The proposal suggested using bit 4, as bit 3 is reserved for Segregated Witness. However, before claiming a bit, proof of usefulness and actual users is required. The NODE_GETUTXO bit, which is included in the BIPs, is not supported by Core and is only one of XT's features. Claiming one of the temporary bits 24-31 is also possible. Relevant information on NODE_GETUTXO and NODE_BLOOM can be found in their respective GitHub links. Providing a link to "thin blocks" would promote further discussion about its merits.In summary, G. Andrew Stone proposed implementing a services bit in the Bitcoin Unlimited client to indicate its capability of communicating thin blocks. Luke Dashjr clarified the BIP process's affiliation and encouraged Bitcoin Unlimited to use it for peer review. Gregory Maxwell suggested a more general proposal for user-agent specific service bits. The discussion also touched on the standard method for obtaining numbers through writing BIPs. 2016-03-09T21:11:36+00:00 + Andrew Stone, a member of the Bitcoin Unlimited team, expressed satisfaction with their own process for documentation and discussion of cross-implementation standards. He sees the Bitcoin Improvement Proposal (BIP) process and the bitcoin-dev mailing list as Core specific. The BIP process allows for hashlocked descriptions of specifications to be implemented against. Stone proposed a process for claiming service bits, which involves justifying the claim, providing a finalized description of the feature within three months, deploying the feature within six months, and locking the bit after six months of active use.Luke Dashjr, in response to a proposal by Bitcoin Unlimited, clarified that the BIP process was actually created by Amir Taaki, not affiliated with Core, and encouraged Bitcoin Unlimited to use it for peer review from the wider Bitcoin development community. He offered to assign BIP numbers to the current Bitcoin Unlimited Improvement Proposals (BUIPs) if they meet the necessary requirements. Dashjr requested links to each of the BUIPs and noted that discussions may occur on other forums besides the mailing list.Stone wrote to the bitcoin-dev mailing list regarding the documentation and discussion of cross-implementation standards. Dashjr replied, stating that bitcoin-dev and the BIP process are not affiliated with Core, and suggested that Bitcoin Unlimited use the BIP process for peer review. He also offered to assign BIP numbers to the current BUIPs if they meet the requirements and requested links to them.Stone proposed using bit 4 as a services bit to indicate that the Bitcoin Unlimited client is capable of communicating thin blocks. Gregory Maxwell suggested a more general proposal that allows customization of user-agent specific service bits in the user-agent string. This would provide flexibility for future development and allow other clients to recognize or follow suit. The proposal does not change peer selection, and if it did, the preferred signaling mechanism would be the one in BIP 130. Stone also mentioned his tech services and ownership of Litmocracy and Meme Racing.A BIP concerning the use of a particular services bit for the extreme thin block protocol was sent to Luke jr for discussion. Bitcoin Unlimited has its own process for documentation and discussion on an uncensored forum. Stone requested interested engineers to join their forum with ideas and criticisms. It is up to Core to decide whether they want to preserve interoperability by avoiding the use of bit 1. The BIP proposes using a service bit to communicate support for thin block communication messages, with the most appropriate location being a service bit. The preferred signaling mechanism is likely the one in BIP 130, and numbers are obtained through writing BIPs.The email thread discussed the proposal to use bit 4 as a services bit for indicating that the Bitcoin Unlimited client can communicate thin blocks. Maxwell questioned if this would change peer selection and suggested using the signaling mechanism in BIP 130 if it does not. If it does change peer selection, a BIP documenting the usage should be written. The conversation ended without further discussion.The discussion highlighted the need for a services bit to indicate a node's capability to communicate thin blocks. The proposal suggested using bit 4, as bit 3 is reserved for Segregated Witness. However, before claiming a bit, proof of usefulness and actual users is required. The NODE_GETUTXO bit, which is included in the BIPs, is not supported by Core and is only one of XT's features. Claiming one of the temporary bits 24-31 is also possible. Relevant information on NODE_GETUTXO and NODE_BLOOM can be found in their respective GitHub links. Providing a link to "thin blocks" would promote further discussion about its merits.In summary, G. Andrew Stone proposed implementing a services bit in the Bitcoin Unlimited client to indicate its capability of communicating thin blocks. Luke Dashjr clarified the BIP process's affiliation and encouraged Bitcoin Unlimited to use it for peer review. Gregory Maxwell suggested a more general proposal for user-agent specific service bits. The discussion also touched on the standard method for obtaining numbers through writing BIPs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_bitcoin-dev-Digest-Vol-10-Issue-13.xml b/static/bitcoin-dev/March_2016/combined_bitcoin-dev-Digest-Vol-10-Issue-13.xml index 2c48445269..fc66024b49 100644 --- a/static/bitcoin-dev/March_2016/combined_bitcoin-dev-Digest-Vol-10-Issue-13.xml +++ b/static/bitcoin-dev/March_2016/combined_bitcoin-dev-Digest-Vol-10-Issue-13.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-dev Digest, Vol 10, Issue 13 - 2023-08-01T17:57:41.897727+00:00 + 2025-09-26T15:41:53.764399+00:00 + python-feedgen Bob McElrath 2016-03-09 06:17:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - bitcoin-dev Digest, Vol 10, Issue 13 - 2023-08-01T17:57:41.897727+00:00 + 2025-09-26T15:41:53.764582+00:00 - During a discussion on the Bitcoin-dev mailing list, Daniele Pinna suggested an alternative approach to implementing a proposal for real-time hash rate rebalancing. Instead of adjusting the difficulty at each new block using the current method, Pinna proposed performing a weighted average of the previous 2016 blocks to find an optimal weighting based on historical interblock timing data. The goal was to prevent oscillation between blocks, even when miners switch hardware on and off.Pinna noted that the optimal solution for this rebalancing is the critically damped oscillator. This solution would provide a zero-parameter, optimal damping solution for a varying hashrate. However, Mike Wozniak pointed out that Simplified Payment Verification (SPV) wallets must also calculate retargeting but stated that it is a simple calculation that would not affect the runtime of SPV wallets.Bob McElrath proposed a simple algorithm called the "critically damped harmonic oscillator" for hashrate rebalancing. This algorithm aims to find the first and second derivatives of the hashrate over time, resulting in a damped harmonic oscillator system with two parameters: oscillation frequency and damping factor. The maximum oscillation frequency is determined by the block rate, as any oscillation faster than that cannot be accurately measured by block times. The damping rate is set to twice the oscillation frequency for critical damping.While McElrath's solution is a numeric approximation to a differential equation, it offers an optimal damping solution for a varying hashrate without the need for additional parameters. It is also possible for weak block proposals to obtain better approximations to the hashrate.Dave Hudson suggested that instead of adopting McElrath's proposal, the community should adjust the difficulty at each new block using the current method. However, if faster relaxation in case of adversity is required, a weighted average of the previous 2016 blocks could be performed based on historical interblock timing data. This approach would allow for finding an optimal weighting to address the issue.Overall, the discussion on the Bitcoin-dev mailing list revolved around different approaches to hash rate rebalancing and difficulty adjustment. While Pinna proposed a weighted average based on historical data, McElrath suggested a critically damped harmonic oscillator algorithm. Hudson, on the other hand, advocated for sticking with the current method of difficulty adjustment but acknowledged the potential benefits of a weighted average approach in certain situations. 2016-03-09T06:17:50+00:00 + During a discussion on the Bitcoin-dev mailing list, Daniele Pinna suggested an alternative approach to implementing a proposal for real-time hash rate rebalancing. Instead of adjusting the difficulty at each new block using the current method, Pinna proposed performing a weighted average of the previous 2016 blocks to find an optimal weighting based on historical interblock timing data. The goal was to prevent oscillation between blocks, even when miners switch hardware on and off.Pinna noted that the optimal solution for this rebalancing is the critically damped oscillator. This solution would provide a zero-parameter, optimal damping solution for a varying hashrate. However, Mike Wozniak pointed out that Simplified Payment Verification (SPV) wallets must also calculate retargeting but stated that it is a simple calculation that would not affect the runtime of SPV wallets.Bob McElrath proposed a simple algorithm called the "critically damped harmonic oscillator" for hashrate rebalancing. This algorithm aims to find the first and second derivatives of the hashrate over time, resulting in a damped harmonic oscillator system with two parameters: oscillation frequency and damping factor. The maximum oscillation frequency is determined by the block rate, as any oscillation faster than that cannot be accurately measured by block times. The damping rate is set to twice the oscillation frequency for critical damping.While McElrath's solution is a numeric approximation to a differential equation, it offers an optimal damping solution for a varying hashrate without the need for additional parameters. It is also possible for weak block proposals to obtain better approximations to the hashrate.Dave Hudson suggested that instead of adopting McElrath's proposal, the community should adjust the difficulty at each new block using the current method. However, if faster relaxation in case of adversity is required, a weighted average of the previous 2016 blocks could be performed based on historical interblock timing data. This approach would allow for finding an optimal weighting to address the issue.Overall, the discussion on the Bitcoin-dev mailing list revolved around different approaches to hash rate rebalancing and difficulty adjustment. While Pinna proposed a weighted average based on historical data, McElrath suggested a critically damped harmonic oscillator algorithm. Hudson, on the other hand, advocated for sticking with the current method of difficulty adjustment but acknowledged the potential benefits of a weighted average approach in certain situations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_consensus-rule-change-for-TX-fee-safety.xml b/static/bitcoin-dev/March_2016/combined_consensus-rule-change-for-TX-fee-safety.xml index 0cce5f21f5..eba01f4a89 100644 --- a/static/bitcoin-dev/March_2016/combined_consensus-rule-change-for-TX-fee-safety.xml +++ b/static/bitcoin-dev/March_2016/combined_consensus-rule-change-for-TX-fee-safety.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - consensus rule change for TX fee safety - 2023-08-01T17:56:18.715948+00:00 + 2025-09-26T15:41:45.305302+00:00 + python-feedgen Dave Scotese 2016-03-03 16:38:17+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - consensus rule change for TX fee safety - 2023-08-01T17:56:18.715948+00:00 + 2025-09-26T15:41:45.305467+00:00 - The bitcoin-dev mailing list discussion has raised concerns about transaction fees and the need for safety rules. Alice Wonder proposed implementing protections to prevent typo blunders in transactions, citing an example of a 15 BTC transaction fee that was likely a mistake. She suggested two possible solutions: limiting the fee to the sum of outputs or limiting the fee per byte based on the previous block's largest fee per byte. Henning Kopp agreed with implementing the rule as a safety mechanism in the client rather than through a hard fork. Jorge Timón suggested improving existing checks and implementing them at the wallet layer.Bitcoin Core already has a safety limit, called the "absurd fee" limit, which is set at 10000 times the minimum relay fee to prevent large transaction fees. This limit applies to both the wallet and the sendrawtransaction RPC call. There is also a user-configurable option, -maxtxfee, to limit fees set by the wallet, which defaults to 0.1 BTC. In Bitcoin Core 0.13, it is planned to use -maxtxfee for both the wallet and the RPC interface. Historically, large transaction fees were caused by insufficient warnings from wallet software, making it the responsibility of operators to ensure user-friendliness. However, there are legitimate use cases for paying large fees, such as convenience for miners and increased privacy.In the bitcoin-dev mailing list discussion, Alice Wonder proposed adding safety rules for transaction fees to prevent mistakes. She suggested limiting the fee based on the sum of outputs or the previous block's largest fee per byte. Some participants disagreed with implementing this as a hard fork and instead suggested implementing it as a safety mechanism in the client. Alice Wonder argued that adding protections could increase confidence in using bitcoin and prevent typo blunders. The discussion concluded without a clear consensus on how to proceed.A user in the discussion suggested limitations on transaction fees, either by not allowing them to be larger than the sum of outputs or by limiting the fee per byte based on the previous block. They disagreed with this idea, stating that such checks should be done by transaction creation clients or that nodes could choose not to accept transactions with high fees into their mempool based on policy. They also argued that these limitations should not be part of the consensus layer.Henning Kopp proposed implementing a safety mechanism in the client to warn users if certain conditions are met, rather than doing a hard fork. Peter Todd pointed out that Bitcoin Core already has a safety limit called the "absurd fee" limit, which is set at 10000 times the minimum relay fee. This limit applies to both the wallet and the sendrawtransaction RPC call. The wallet also has a user-configurable option, -maxtxfee, to limit fees set by the wallet, currently defaulting to 0.1 BTC.Alice Wonder suggested implementing a safety rule for transaction fees in the next hard fork on the bitcoin-dev mailing list. She mentioned an incident where a user paid a 15 BTC fee due to a probable typo or client bug. Two proposed solutions were limiting the fee to the sum of outputs or limiting the fee per byte based on the previous block. Alice argued that adding protections could increase user confidence, using the four-byte checksum in public addresses as an example. Henning Kopp suggested implementing the safety mechanism in the client rather than through a hard fork, with a warning pop-up for conditions A) or B) being met.A recent Bitcoin transaction with an unusually high fee has sparked discussions about the need for safety rules regarding transaction fees during hard forks. The transaction in question involved a 15 BTC fee, equivalent to approximately $130,000. Experts have suggested that implementing safety rules for transaction fees could prevent similar incidents in the future. The issue has reignited debates about the scalability of Bitcoin and its adoption, with concerns raised about high transaction fees hindering wider usage. However, some argue that this incident is isolated and not indicative of broader issues in the cryptocurrency ecosystem. The incident serves as a reminder of the challenges facing the industry as it continues to grow and mature. Concrete action to address transaction fees during hard forks remains uncertain. 2016-03-03T16:38:17+00:00 + The bitcoin-dev mailing list discussion has raised concerns about transaction fees and the need for safety rules. Alice Wonder proposed implementing protections to prevent typo blunders in transactions, citing an example of a 15 BTC transaction fee that was likely a mistake. She suggested two possible solutions: limiting the fee to the sum of outputs or limiting the fee per byte based on the previous block's largest fee per byte. Henning Kopp agreed with implementing the rule as a safety mechanism in the client rather than through a hard fork. Jorge Timón suggested improving existing checks and implementing them at the wallet layer.Bitcoin Core already has a safety limit, called the "absurd fee" limit, which is set at 10000 times the minimum relay fee to prevent large transaction fees. This limit applies to both the wallet and the sendrawtransaction RPC call. There is also a user-configurable option, -maxtxfee, to limit fees set by the wallet, which defaults to 0.1 BTC. In Bitcoin Core 0.13, it is planned to use -maxtxfee for both the wallet and the RPC interface. Historically, large transaction fees were caused by insufficient warnings from wallet software, making it the responsibility of operators to ensure user-friendliness. However, there are legitimate use cases for paying large fees, such as convenience for miners and increased privacy.In the bitcoin-dev mailing list discussion, Alice Wonder proposed adding safety rules for transaction fees to prevent mistakes. She suggested limiting the fee based on the sum of outputs or the previous block's largest fee per byte. Some participants disagreed with implementing this as a hard fork and instead suggested implementing it as a safety mechanism in the client. Alice Wonder argued that adding protections could increase confidence in using bitcoin and prevent typo blunders. The discussion concluded without a clear consensus on how to proceed.A user in the discussion suggested limitations on transaction fees, either by not allowing them to be larger than the sum of outputs or by limiting the fee per byte based on the previous block. They disagreed with this idea, stating that such checks should be done by transaction creation clients or that nodes could choose not to accept transactions with high fees into their mempool based on policy. They also argued that these limitations should not be part of the consensus layer.Henning Kopp proposed implementing a safety mechanism in the client to warn users if certain conditions are met, rather than doing a hard fork. Peter Todd pointed out that Bitcoin Core already has a safety limit called the "absurd fee" limit, which is set at 10000 times the minimum relay fee. This limit applies to both the wallet and the sendrawtransaction RPC call. The wallet also has a user-configurable option, -maxtxfee, to limit fees set by the wallet, currently defaulting to 0.1 BTC.Alice Wonder suggested implementing a safety rule for transaction fees in the next hard fork on the bitcoin-dev mailing list. She mentioned an incident where a user paid a 15 BTC fee due to a probable typo or client bug. Two proposed solutions were limiting the fee to the sum of outputs or limiting the fee per byte based on the previous block. Alice argued that adding protections could increase user confidence, using the four-byte checksum in public addresses as an example. Henning Kopp suggested implementing the safety mechanism in the client rather than through a hard fork, with a warning pop-up for conditions A) or B) being met.A recent Bitcoin transaction with an unusually high fee has sparked discussions about the need for safety rules regarding transaction fees during hard forks. The transaction in question involved a 15 BTC fee, equivalent to approximately $130,000. Experts have suggested that implementing safety rules for transaction fees could prevent similar incidents in the future. The issue has reignited debates about the scalability of Bitcoin and its adoption, with concerns raised about high transaction fees hindering wider usage. However, some argue that this incident is isolated and not indicative of broader issues in the cryptocurrency ecosystem. The incident serves as a reminder of the challenges facing the industry as it continues to grow and mature. Concrete action to address transaction fees during hard forks remains uncertain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_p2p-authentication-and-encryption-BIPs.xml b/static/bitcoin-dev/March_2016/combined_p2p-authentication-and-encryption-BIPs.xml index f54bcffec0..aa7a6ca230 100644 --- a/static/bitcoin-dev/March_2016/combined_p2p-authentication-and-encryption-BIPs.xml +++ b/static/bitcoin-dev/March_2016/combined_p2p-authentication-and-encryption-BIPs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - p2p authentication and encryption BIPs - 2023-08-01T18:00:13.282875+00:00 + 2025-09-26T15:41:36.854324+00:00 + python-feedgen Jonas Schnelli 2016-05-25 09:36:24+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - p2p authentication and encryption BIPs - 2023-08-01T18:00:13.282875+00:00 + 2025-09-26T15:41:36.854498+00:00 - The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, 2016-05-25T09:36:24+00:00 + The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_A-BIP-proposal-for-segwit-addresses.xml b/static/bitcoin-dev/March_2017/combined_A-BIP-proposal-for-segwit-addresses.xml index a4586bc3d9..90f10d1113 100644 --- a/static/bitcoin-dev/March_2017/combined_A-BIP-proposal-for-segwit-addresses.xml +++ b/static/bitcoin-dev/March_2017/combined_A-BIP-proposal-for-segwit-addresses.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - A BIP proposal for segwit addresses - 2023-08-01T19:50:37.233258+00:00 - - Russell O'Connor 2018-07-26 14:31:30+00:00 - - - Russell O'Connor 2018-07-26 13:43:19+00:00 - - - Pieter Wuille 2017-05-20 20:13:13+00:00 - - - Peter Todd 2017-05-07 22:34:29+00:00 - - - Pieter Wuille 2017-05-07 21:39:14+00:00 - - - Lucas Ontivero 2017-03-30 04:50:54+00:00 - - - Andreas Schildbach 2017-03-29 10:07:40+00:00 - - - Peter Todd 2017-03-21 19:14:54+00:00 - - - Andreas Schildbach 2017-03-21 16:16:30+00:00 - - - Pieter Wuille 2017-03-20 21:35:08+00:00 - + 2025-09-26T15:36:20.932782+00:00 + python-feedgen + + + [bitcoin-dev] A BIP proposal for segwit addresses Pieter Wuille + 2017-03-20T21:35:00.000Z + + + Andreas Schildbach + 2017-03-21T16:16:00.000Z + + + Peter Todd + 2017-03-21T19:14:00.000Z + + + Andreas Schildbach + 2017-03-29T10:07:00.000Z + + + Lucas Ontivero + 2017-03-30T04:50:00.000Z + + + Pieter Wuille + 2017-05-07T21:39:00.000Z + + + Peter Todd + 2017-05-07T22:34:00.000Z + + + Pieter Wuille + 2017-05-20T20:13:00.000Z + + + Russell O'Connor + 2018-07-26T13:43:00.000Z + + + Russell O'Connor + 2018-07-26T14:31:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - A BIP proposal for segwit addresses - 2023-08-01T19:50:37.233258+00:00 + 2025-09-26T15:36:20.934006+00:00 - In an email exchange, Russell O'Connor suggested adding a note to the BIP (Bitcoin Improvement Proposal) stating that the Human Readable Part (HRP) should be specified in lowercase or at least mentioning that uppercase and lowercase HRPs are considered equivalent and will be converted to lowercase during validation. The HRP is required to contain 1 to 83 US-ASCII characters, with each character having a value in the range of 33-126, and its validity may be further restricted by specific applications. Bech32, which is used for encoding BTC addresses, forbids mixed-case and converts everything to lowercase, so it is advisable to warn against using uppercase in the HRP. This change would not be normative.Pieter Wuille has requested a BIP number assignment for his proposal, which is available on GitHub under the name BIP173. The proposal aims to introduce a commonly recognizable format for BTC addresses that has good properties for all use cases. It emphasizes the importance of addressing all places where humans interact with addresses, including voice transmission and QR codes. However, compactness is not the primary goal of the BIP.The discussion on the Bitcoin-dev mailing list centered around the ability of non-native English speakers to communicate BTC addresses with English speakers. Peter Todd explained that it is not a binary issue as some non-native speakers may know how to pronounce numbers or alphabetical characters but not special characters. Two new reference implementations (Haskell and Rust) have been contributed recently, and C++ and Go implementations are in progress. Peter Todd also shared his experience of implementing Bech32 encoding for a non-BTC use-case and found it straightforward.The writer is considering whether to respond to a mail list or make a comment in a commit file. They discuss the motivation behind this, which is the lack of support for big numbers in most programming languages when performing mathematical operations required by BIP58. The writer also questions the need for a new encoding format and raises concerns about potential confusion. They note that if a new type of address can be encoded with Bech32 in the future, a new address type may be needed regardless. They argue against using non-alphanumeric characters in addresses for certain contexts, such as filenames, and suggest using something like "Base 64url" or ideally Base 94 for shorter QR codes.In a recent discussion on the Bitcoin-dev mailing list, Andreas Schildbach suggested using Base 43 for QR code encoding in Bitcoin Wallet to make addresses shorter. However, Peter Todd responded with concerns about the downsides of using non-alphanumeric characters in addresses, such as making them difficult to use in various contexts and not being familiar to non-English speaking users. He also questioned the need for transmitting addresses via voice communication. Todd further explained that when used for URLs, Base 32 (as well as Base 43) actually makes QR codes bigger due to the characters used for URL parameters. To make them shorter, he suggested using something like "Base 64url" or preferably Base 94 which includes all printable ASCII characters.Andreas Schildbach's suggestion of using Base 43 for QR code encoding in Bitcoin Wallet to shorten addresses may not be efficient due to the downsides associated with non-alphanumeric characters. These characters can complicate usage in different contexts and may not be familiar to non-English-speaking users. The suggestion was made as an alternative to using Base 32, which is seen as less efficient than the QR code alphanumeric mode that accommodates 44 characters. Peter Todd advises reviewing the "Rational" section of the BIP for more details.Pieter Wuille proposed a new BIP for native SegWit addresses to replace BIP 142 on March 20, 2017. These addresses are optional but offer better efficiency, flexibility, and user-friendliness. The format uses a simple checksum algorithm with strong error detection properties and is based on Base 32 encoding. Reference code in several languages, as well as a website demonstrating it, are included. The text of the proposal can be found on GitHub.Pieter's proposal for native SegWit addresses aims to replace the current BIP 142. These addresses, while not required for SegWit, provide improved efficiency, flexibility, and user-friendliness. They utilize a base 32 encoding format with a simple checksum algorithm that ensures strong error detection. The proposal includes reference code in multiple programming languages and a website for demonstration purposes. The full text of the proposal can be accessed on GitHub. 2018-07-26T14:31:30+00:00 + In an email exchange, Russell O'Connor suggested adding a note to the BIP (Bitcoin Improvement Proposal) stating that the Human Readable Part (HRP) should be specified in lowercase or at least mentioning that uppercase and lowercase HRPs are considered equivalent and will be converted to lowercase during validation. The HRP is required to contain 1 to 83 US-ASCII characters, with each character having a value in the range of 33-126, and its validity may be further restricted by specific applications. Bech32, which is used for encoding BTC addresses, forbids mixed-case and converts everything to lowercase, so it is advisable to warn against using uppercase in the HRP. This change would not be normative.Pieter Wuille has requested a BIP number assignment for his proposal, which is available on GitHub under the name BIP173. The proposal aims to introduce a commonly recognizable format for BTC addresses that has good properties for all use cases. It emphasizes the importance of addressing all places where humans interact with addresses, including voice transmission and QR codes. However, compactness is not the primary goal of the BIP.The discussion on the Bitcoin-dev mailing list centered around the ability of non-native English speakers to communicate BTC addresses with English speakers. Peter Todd explained that it is not a binary issue as some non-native speakers may know how to pronounce numbers or alphabetical characters but not special characters. Two new reference implementations (Haskell and Rust) have been contributed recently, and C++ and Go implementations are in progress. Peter Todd also shared his experience of implementing Bech32 encoding for a non-BTC use-case and found it straightforward.The writer is considering whether to respond to a mail list or make a comment in a commit file. They discuss the motivation behind this, which is the lack of support for big numbers in most programming languages when performing mathematical operations required by BIP58. The writer also questions the need for a new encoding format and raises concerns about potential confusion. They note that if a new type of address can be encoded with Bech32 in the future, a new address type may be needed regardless. They argue against using non-alphanumeric characters in addresses for certain contexts, such as filenames, and suggest using something like "Base 64url" or ideally Base 94 for shorter QR codes.In a recent discussion on the Bitcoin-dev mailing list, Andreas Schildbach suggested using Base 43 for QR code encoding in Bitcoin Wallet to make addresses shorter. However, Peter Todd responded with concerns about the downsides of using non-alphanumeric characters in addresses, such as making them difficult to use in various contexts and not being familiar to non-English speaking users. He also questioned the need for transmitting addresses via voice communication. Todd further explained that when used for URLs, Base 32 (as well as Base 43) actually makes QR codes bigger due to the characters used for URL parameters. To make them shorter, he suggested using something like "Base 64url" or preferably Base 94 which includes all printable ASCII characters.Andreas Schildbach's suggestion of using Base 43 for QR code encoding in Bitcoin Wallet to shorten addresses may not be efficient due to the downsides associated with non-alphanumeric characters. These characters can complicate usage in different contexts and may not be familiar to non-English-speaking users. The suggestion was made as an alternative to using Base 32, which is seen as less efficient than the QR code alphanumeric mode that accommodates 44 characters. Peter Todd advises reviewing the "Rational" section of the BIP for more details.Pieter Wuille proposed a new BIP for native SegWit addresses to replace BIP 142 on March 20, 2017. These addresses are optional but offer better efficiency, flexibility, and user-friendliness. The format uses a simple checksum algorithm with strong error detection properties and is based on Base 32 encoding. Reference code in several languages, as well as a website demonstrating it, are included. The text of the proposal can be found on GitHub.Pieter's proposal for native SegWit addresses aims to replace the current BIP 142. These addresses, while not required for SegWit, provide improved efficiency, flexibility, and user-friendliness. They utilize a base 32 encoding format with a simple checksum algorithm that ensures strong error detection. The proposal includes reference code in multiple programming languages and a website for demonstration purposes. The full text of the proposal can be accessed on GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_A-Better-MMR-Definition.xml b/static/bitcoin-dev/March_2017/combined_A-Better-MMR-Definition.xml index 7e6f57a653..3b40153273 100644 --- a/static/bitcoin-dev/March_2017/combined_A-Better-MMR-Definition.xml +++ b/static/bitcoin-dev/March_2017/combined_A-Better-MMR-Definition.xml @@ -1,95 +1,127 @@ - + 2 Combined summary - A Better MMR Definition - 2023-08-01T19:34:55.774037+00:00 - - praxeology_guy 2017-04-01 19:46:12+00:00 - - - praxeology_guy 2017-04-01 10:18:12+00:00 - - - Bram Cohen 2017-03-31 20:38:16+00:00 - - - Peter Todd 2017-03-01 22:31:01+00:00 - - - Peter Todd 2017-03-01 01:56:16+00:00 - - - Bram Cohen 2017-03-01 01:47:30+00:00 - - - Pieter Wuille 2017-02-28 23:24:28+00:00 - - - Bram Cohen 2017-02-28 23:10:16+00:00 - - - G. Andrew Stone 2017-02-28 16:43:29+00:00 - - - Bram Cohen 2017-02-25 06:23:20+00:00 - - - Peter Todd 2017-02-25 04:12:02+00:00 - - - Bram Cohen 2017-02-24 22:20:19+00:00 - - - Peter Todd 2017-02-24 04:36:13+00:00 - - - Bram Cohen 2017-02-24 03:32:43+00:00 - - - Peter Todd 2017-02-24 03:15:31+00:00 - - - Bram Cohen 2017-02-24 03:02:36+00:00 - - - Peter Todd 2017-02-24 02:58:11+00:00 - - - Bram Cohen 2017-02-24 02:50:10+00:00 - - - Peter Todd 2017-02-24 01:09:43+00:00 - - - Bram Cohen 2017-02-24 00:49:01+00:00 - - - Peter Todd 2017-02-23 23:51:05+00:00 - - - Bram Cohen 2017-02-23 23:13:43+00:00 - - - Peter Todd 2017-02-23 18:31:40+00:00 - - - G. Andrew Stone 2017-02-23 18:28:18+00:00 - - - Peter Todd 2017-02-23 18:19:29+00:00 - - - Chris Priest 2017-02-23 17:53:58+00:00 - - - Peter Todd 2017-02-23 07:41:37+00:00 - - - Bram Cohen 2017-02-23 03:07:08+00:00 - - - Peter Todd 2017-02-23 01:15:06+00:00 - + 2025-09-26T15:36:12.505380+00:00 + python-feedgen + + + [bitcoin-dev] A Better MMR Definition Peter Todd + 2017-02-23T01:15:00.000Z + + + Bram Cohen + 2017-02-23T03:07:00.000Z + + + Peter Todd + 2017-02-23T07:41:00.000Z + + + Chris Priest + 2017-02-23T17:53:00.000Z + + + Peter Todd + 2017-02-23T18:19:00.000Z + + + G. Andrew Stone + 2017-02-23T18:28:00.000Z + + + Peter Todd + 2017-02-23T18:31:00.000Z + + + Bram Cohen + 2017-02-23T23:13:00.000Z + + + Peter Todd + 2017-02-23T23:51:00.000Z + + + Bram Cohen + 2017-02-24T00:49:00.000Z + + + Peter Todd + 2017-02-24T01:09:00.000Z + + + Bram Cohen + 2017-02-24T02:50:00.000Z + + + Peter Todd + 2017-02-24T02:58:00.000Z + + + Bram Cohen + 2017-02-24T03:02:00.000Z + + + Peter Todd + 2017-02-24T03:15:00.000Z + + + Bram Cohen + 2017-02-24T03:32:00.000Z + + + Peter Todd + 2017-02-24T04:36:00.000Z + + + Bram Cohen + 2017-02-24T22:20:00.000Z + + + Peter Todd + 2017-02-25T04:12:00.000Z + + + Bram Cohen + 2017-02-25T06:23:00.000Z + + + G. Andrew Stone + 2017-02-28T16:43:00.000Z + + + Bram Cohen + 2017-02-28T23:10:00.000Z + + + Pieter Wuille + 2017-02-28T23:24:00.000Z + + + Bram Cohen + 2017-03-01T01:47:00.000Z + + + Peter Todd + 2017-03-01T01:56:00.000Z + + + Peter Todd + 2017-03-01T22:31:00.000Z + + + Bram Cohen + 2017-03-31T20:38:00.000Z + + + praxeology_guy + 2017-04-01T10:18:00.000Z + + + praxeology_guy + 2017-04-01T19:46:00.000Z + + @@ -119,13 +151,13 @@ - python-feedgen + 2 Combined summary - A Better MMR Definition - 2023-08-01T19:34:55.775036+00:00 + 2025-09-26T15:36:12.508650+00:00 - In an email exchange between Bram Cohen and Peter Todd, the concept of UTXO commitments and the use of merkle trees for proving the current state of an output were discussed. Todd suggested committing to the state of all transaction outputs with a merkle tree structure, while Cohen argued that MMRs seemed redundant with the actual blockchain history. However, they agreed on the main goal of UTXO commitments: making a compact proof that something is still in the UTXO set.There were concerns about the performance and scalability of implementing UTXO commitments, particularly due to the size of the txo set. Cohen believed that with appropriate format and implementation tricks, good enough performance could be achieved. The benefits and drawbacks of using MMRs were also discussed. Todd argued that MMRs were redundant because you could prove something is in the TXO or STXO set using the actual blockchain, while Cohen believed that UTXO commitments provided benefits in terms of proving block validity and preventing fraud.The importance of independent validation by full nodes and the potential issues of relying too heavily on proofs were also touched upon. Todd emphasized the need to consider MMRs on their own merits before comparing them to UTXO commitments.Another email conversation involved G. Andrew Stone asking about efficient nonexistence proofs in an insertion-ordered MMR. This proposal aimed to enhance the efficiency of non-existence proofs and improve TXO commitments. Additionally, there was a discussion about the definition of a prunable MMR for use in Bitcoin. The improved definition committed to the number of items in the tree implicitly, allowing for an efficient proof-of-tree-size by following the right-most nodes. The insertion-ordered MMR was seen as a way to enhance non-existence proofs and overall TXO commitments.Overall, these discussions highlighted the ongoing exploration of UTXO commitments and MMRs as potential solutions for improving the scalability, performance, and security of blockchain transactions. 2017-04-01T19:46:12+00:00 + In an email exchange between Bram Cohen and Peter Todd, the concept of UTXO commitments and the use of merkle trees for proving the current state of an output were discussed. Todd suggested committing to the state of all transaction outputs with a merkle tree structure, while Cohen argued that MMRs seemed redundant with the actual blockchain history. However, they agreed on the main goal of UTXO commitments: making a compact proof that something is still in the UTXO set.There were concerns about the performance and scalability of implementing UTXO commitments, particularly due to the size of the txo set. Cohen believed that with appropriate format and implementation tricks, good enough performance could be achieved. The benefits and drawbacks of using MMRs were also discussed. Todd argued that MMRs were redundant because you could prove something is in the TXO or STXO set using the actual blockchain, while Cohen believed that UTXO commitments provided benefits in terms of proving block validity and preventing fraud.The importance of independent validation by full nodes and the potential issues of relying too heavily on proofs were also touched upon. Todd emphasized the need to consider MMRs on their own merits before comparing them to UTXO commitments.Another email conversation involved G. Andrew Stone asking about efficient nonexistence proofs in an insertion-ordered MMR. This proposal aimed to enhance the efficiency of non-existence proofs and improve TXO commitments. Additionally, there was a discussion about the definition of a prunable MMR for use in Bitcoin. The improved definition committed to the number of items in the tree implicitly, allowing for an efficient proof-of-tree-size by following the right-most nodes. The insertion-ordered MMR was seen as a way to enhance non-existence proofs and overall TXO commitments.Overall, these discussions highlighted the ongoing exploration of UTXO commitments and MMRs as potential solutions for improving the scalability, performance, and security of blockchain transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_A-Commitment-suitable-UTXO-set-Balances-file-data-structure.xml b/static/bitcoin-dev/March_2017/combined_A-Commitment-suitable-UTXO-set-Balances-file-data-structure.xml index dfdf89e58d..8c83ac82fe 100644 --- a/static/bitcoin-dev/March_2017/combined_A-Commitment-suitable-UTXO-set-Balances-file-data-structure.xml +++ b/static/bitcoin-dev/March_2017/combined_A-Commitment-suitable-UTXO-set-Balances-file-data-structure.xml @@ -1,31 +1,38 @@ - + 2 - Combined summary - A Commitment-suitable UTXO set "Balances" file data structure - 2023-08-01T19:44:42.094778+00:00 - - Bram Cohen 2017-03-08 03:07:31+00:00 - - - bfd at cock.lu 2017-03-08 01:55:41+00:00 - - - Bram Cohen 2017-03-08 01:55:18+00:00 - - - praxeology_guy 2017-03-07 21:28:49+00:00 - + Combined summary - A Commitment-suitable UTXO set "Balances" file data structure + 2025-09-26T15:36:16.689164+00:00 + python-feedgen + + + [bitcoin-dev] A Commitment-suitable UTXO set "Balances" file data structure praxeology_guy + 2017-03-07T21:28:00.000Z + + + Bram Cohen + 2017-03-08T01:55:00.000Z + + + bfd + 2017-03-08T01:55:00.000Z + + + Bram Cohen + 2017-03-08T03:07:00.000Z + + - python-feedgen + 2 - Combined summary - A Commitment-suitable UTXO set "Balances" file data structure - 2023-08-01T19:44:42.094778+00:00 + Combined summary - A Commitment-suitable UTXO set "Balances" file data structure + 2025-09-26T15:36:16.689852+00:00 - In a discussion on the Bitcoin-dev mailing list, a user raised concerns about the expense and scalability of having a commitment to a "balance" of an "address." The user argued that this approach is not particularly useful for clients. However, it was also discussed that creating infrequent utxo commitments could allow new clients to download just the contents of the utxo set without retrieving the entire blockchain history.The proposal for a commitment-suitable UTXO set "Balances" file data structure was introduced in the bitcoin-dev mailing list. This proposed structure would allow all nodes in the network to verify their UTXO set's data integrity and enable pruned nodes to start synchronizing at a Balances file's block height instead of the genesis block. To make this work, Bitcoin would need a new policy where a UTXO commitment is made every "Balances/UTXO Commitment Period" (BCP) blocks. The file/commitment should be made in a background thread, starting at least BCP/2 blocks after the last block containing a utxo commitment.The balances file summary includes a header with file type, file version, size of balances, and root hash. The balances are listed sorted by txid, with each balance containing the length, txid, and variable-length CCoins. The proposal suggests dividing the 2GB of balance data into 65536 pieces, with each piece being 32*1024 bytes. The transaction index is an array of txix and piece offset, while the Merkle tree hashes consist of leaf hashes and node hashes.One member of the Bitcoin-dev mailing list proposed using Merkle tree hashes to store output transactions and output numbers, but another member suggested using a patricia trie instead to allow for incremental updates. The proposed Merkle set format would work well for the intended usage and could be synced with the work difficulty reset interval. However, a shorter block period would require nodes to keep more copies of the balances file. On the other hand, a patricia-based format would allow for more frequent UTXO commitments with minimal cost of updating and handle reorgs by undoing the last few transactions in the set and rolling forward.The proposed Commitment-suitable UTXO set "Balances" file data structure allows pruned nodes to satisfy SPV (Simplified Payment Verification) nodes and start synchronizing at a Balances file's block height instead of the genesis block. All nodes in the network can verify their UTXO set's data integrity through this structure. A new policy is needed where a UTXO commitment is made every "Balances/UTXO Commitment Period" (BCP) blocks. The commitment is made on the state of the UTXO at BCP blocks ago, and the file/commitment is made in a background thread, starting at least BCP/2 blocks after the last block containing a utxo commitment.The Balances file summary consists of a header, balances, balance index, and Merkle tree hashes. Balances are listed by txid, and a piece represents a portion of the balance data. The proposed piece size is 32*1024 bytes. The transaction index includes the first N bytes of a txid and piece offset. The Merkle tree hashes consist of leaf hashes, node hashes, or copying up if only one child. The design suggests that the piece size should be small enough to avoid wasting effort when receiving invalid pieces and should also be small if this data structure is used instead of block history for SPV proof. The child count = 2 Merkle tree structure is necessary only if this data structure is used to satisfy SPV clients. Otherwise, the root hash could have the leaf hashes as its direct children. The balance index serves to support SPV clients.Other design notes suggest making the "Balances/UTXO Commitment Period" 5000 blocks, allowing more frequent checks on UTXO set integrity and enabling new pruning nodes to start syncing closer to the tip. The suggested design change to the chainstate "CCoinsViewDB" utxo database proposes modifying the "CCoins" data structure to keep track of spends that shouldn't be included in the commitment. Vtipspends could hold {vout_ix, blockhash} instead of just vout_ix. To check whether a txo is spent, a parameter specifying the "fork tip hash" or "fork chain" would be required. Feedback is welcome on these proposals. 2017-03-08T03:07:31+00:00 + In a discussion on the Bitcoin-dev mailing list, a user raised concerns about the expense and scalability of having a commitment to a "balance" of an "address." The user argued that this approach is not particularly useful for clients. However, it was also discussed that creating infrequent utxo commitments could allow new clients to download just the contents of the utxo set without retrieving the entire blockchain history.The proposal for a commitment-suitable UTXO set "Balances" file data structure was introduced in the bitcoin-dev mailing list. This proposed structure would allow all nodes in the network to verify their UTXO set's data integrity and enable pruned nodes to start synchronizing at a Balances file's block height instead of the genesis block. To make this work, Bitcoin would need a new policy where a UTXO commitment is made every "Balances/UTXO Commitment Period" (BCP) blocks. The file/commitment should be made in a background thread, starting at least BCP/2 blocks after the last block containing a utxo commitment.The balances file summary includes a header with file type, file version, size of balances, and root hash. The balances are listed sorted by txid, with each balance containing the length, txid, and variable-length CCoins. The proposal suggests dividing the 2GB of balance data into 65536 pieces, with each piece being 32*1024 bytes. The transaction index is an array of txix and piece offset, while the Merkle tree hashes consist of leaf hashes and node hashes.One member of the Bitcoin-dev mailing list proposed using Merkle tree hashes to store output transactions and output numbers, but another member suggested using a patricia trie instead to allow for incremental updates. The proposed Merkle set format would work well for the intended usage and could be synced with the work difficulty reset interval. However, a shorter block period would require nodes to keep more copies of the balances file. On the other hand, a patricia-based format would allow for more frequent UTXO commitments with minimal cost of updating and handle reorgs by undoing the last few transactions in the set and rolling forward.The proposed Commitment-suitable UTXO set "Balances" file data structure allows pruned nodes to satisfy SPV (Simplified Payment Verification) nodes and start synchronizing at a Balances file's block height instead of the genesis block. All nodes in the network can verify their UTXO set's data integrity through this structure. A new policy is needed where a UTXO commitment is made every "Balances/UTXO Commitment Period" (BCP) blocks. The commitment is made on the state of the UTXO at BCP blocks ago, and the file/commitment is made in a background thread, starting at least BCP/2 blocks after the last block containing a utxo commitment.The Balances file summary consists of a header, balances, balance index, and Merkle tree hashes. Balances are listed by txid, and a piece represents a portion of the balance data. The proposed piece size is 32*1024 bytes. The transaction index includes the first N bytes of a txid and piece offset. The Merkle tree hashes consist of leaf hashes, node hashes, or copying up if only one child. The design suggests that the piece size should be small enough to avoid wasting effort when receiving invalid pieces and should also be small if this data structure is used instead of block history for SPV proof. The child count = 2 Merkle tree structure is necessary only if this data structure is used to satisfy SPV clients. Otherwise, the root hash could have the leaf hashes as its direct children. The balance index serves to support SPV clients.Other design notes suggest making the "Balances/UTXO Commitment Period" 5000 blocks, allowing more frequent checks on UTXO set integrity and enabling new pruning nodes to start syncing closer to the tip. The suggested design change to the chainstate "CCoinsViewDB" utxo database proposes modifying the "CCoins" data structure to keep track of spends that shouldn't be included in the commitment. Vtipspends could hold {vout_ix, blockhash} instead of just vout_ix. To check whether a txo is spent, a parameter specifying the "fork tip hash" or "fork chain" would be required. Feedback is welcome on these proposals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Bandwidth-limits-and-LN-w-node-relay-network-topography.xml b/static/bitcoin-dev/March_2017/combined_Bandwidth-limits-and-LN-w-node-relay-network-topography.xml index 7822d81a7e..828e7a92c1 100644 --- a/static/bitcoin-dev/March_2017/combined_Bandwidth-limits-and-LN-w-node-relay-network-topography.xml +++ b/static/bitcoin-dev/March_2017/combined_Bandwidth-limits-and-LN-w-node-relay-network-topography.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Bandwidth limits and LN w/ node relay network topography - 2023-08-01T19:55:53.674052+00:00 - - Aymeric Vitte 2017-03-27 17:09:20+00:00 - - - praxeology_guy 2017-03-26 22:11:14+00:00 - + 2025-09-26T15:36:39.838188+00:00 + python-feedgen + + + [bitcoin-dev] Bandwidth limits and LN w/ node relay network topography praxeology_guy + 2017-03-26T22:11:00.000Z + + + Aymeric Vitte + 2017-03-27T17:09:00.000Z + + - python-feedgen + 2 Combined summary - Bandwidth limits and LN w/ node relay network topography - 2023-08-01T19:55:53.674052+00:00 + 2025-09-26T15:36:39.838671+00:00 - The email thread on the bitcoin-dev mailing list discussed several topics related to bandwidth limits, Lightning Network, and network splits. One suggestion was to establish global and per node up/down bandwidth limits and communicate them to peers. This would allow for monitoring of actual bandwidth usage and adjustment of connections to meet desired goals. The idea of using Lightning Network to prepay for bandwidth/data was also proposed, with the possibility of paying different amounts for different types of data. Refunds could be requested for useless/duplicate/invalid/spam data, and connections with nodes that do not refund could be terminated. These measures would incentivize the relay of unconfirmed transactions and new blocks, while improving spam/DDoS resilience.Another suggestion was to relay advertisements of available bandwidth and prices. This would enable nodes to make informed decisions about their connections based on bandwidth availability and costs. To identify network splits, nodes could generate a hash of "nonce + pub key + tip blockhash" that surpasses a difficulty threshold. By broadcasting this information, nodes can prove their existence and connectedness. Monitoring the history of these broadcasts could help identify disruptions in the network. It was questioned why nodes attempting to split would not behave correctly and be banned by other nodes. The potential for centralization was also raised, with a mention of the Tor network's method of selecting nodes based on advertised bandwidth.Throughout the discussion, various links were provided for Zcash wallets, Bitcoin wallets, the torrent dynamic blocklist, checking a 10 million password list, anti-spies and private torrents, dynamic blocklist, Peersm, torrent-live, node-Tor, and GitHub. 2017-03-27T17:09:20+00:00 + The email thread on the bitcoin-dev mailing list discussed several topics related to bandwidth limits, Lightning Network, and network splits. One suggestion was to establish global and per node up/down bandwidth limits and communicate them to peers. This would allow for monitoring of actual bandwidth usage and adjustment of connections to meet desired goals. The idea of using Lightning Network to prepay for bandwidth/data was also proposed, with the possibility of paying different amounts for different types of data. Refunds could be requested for useless/duplicate/invalid/spam data, and connections with nodes that do not refund could be terminated. These measures would incentivize the relay of unconfirmed transactions and new blocks, while improving spam/DDoS resilience.Another suggestion was to relay advertisements of available bandwidth and prices. This would enable nodes to make informed decisions about their connections based on bandwidth availability and costs. To identify network splits, nodes could generate a hash of "nonce + pub key + tip blockhash" that surpasses a difficulty threshold. By broadcasting this information, nodes can prove their existence and connectedness. Monitoring the history of these broadcasts could help identify disruptions in the network. It was questioned why nodes attempting to split would not behave correctly and be banned by other nodes. The potential for centralization was also raised, with a mention of the Tor network's method of selecting nodes based on advertised bandwidth.Throughout the discussion, various links were provided for Zcash wallets, Bitcoin wallets, the torrent dynamic blocklist, checking a 10 million password list, anti-spies and private torrents, dynamic blocklist, Peersm, torrent-live, node-Tor, and GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Block-size-adjustment-idea-expedience-fees-difficulty-scaling-proportional-to-block-size-fee-pool-.xml b/static/bitcoin-dev/March_2017/combined_Block-size-adjustment-idea-expedience-fees-difficulty-scaling-proportional-to-block-size-fee-pool-.xml index fea4b4f9a9..b7afc705d7 100644 --- a/static/bitcoin-dev/March_2017/combined_Block-size-adjustment-idea-expedience-fees-difficulty-scaling-proportional-to-block-size-fee-pool-.xml +++ b/static/bitcoin-dev/March_2017/combined_Block-size-adjustment-idea-expedience-fees-difficulty-scaling-proportional-to-block-size-fee-pool-.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) - 2023-08-01T20:05:24.551728+00:00 - - Natanael 2017-03-31 04:15:17+00:00 - - - Natanael 2017-03-31 04:14:30+00:00 - - - Natanael 2017-03-30 18:41:19+00:00 - - - Natanael 2017-03-30 10:19:33+00:00 - - - Luke Dashjr 2017-03-30 10:04:05+00:00 - - - Natanael 2017-03-30 09:34:31+00:00 - + 2025-09-26T15:36:29.325201+00:00 + python-feedgen + + + [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) Natanael + 2017-03-30T09:34:00.000Z + + + Luke Dashjr + 2017-03-30T10:04:00.000Z + + + Natanael + 2017-03-30T10:19:00.000Z + + + Natanael + 2017-03-30T18:41:00.000Z + + + Natanael + 2017-03-31T04:14:00.000Z + + + Natanael + 2017-03-31T04:15:00.000Z + + - python-feedgen + 2 Combined summary - Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) - 2023-08-01T20:05:24.551728+00:00 + 2025-09-26T15:36:29.326040+00:00 - On March 30, 2017, a proposal was made to alter the difficulty scaling of block size. The proposal suggests that larger blocks would mean greater difficulty, but this doesn't scale linearly. Miners can take a penalty in difficulty to claim a greater number of high fee transactions in the same amount of time, effectively increasing their profits. However, when such profitable fees aren't available, they have to reduce the block size. In other words, users pay miners to increase block size, or don't pay, which reduces it.The proposal suggests that the process could be simplified if a fee pool is created through softfork code instead of hardfork code. However, the effect will be partially reduced by the mining subsidy until it reaches parity with average total fees. Instead of altering the difficulty calculation, the proposal suggests altering the percentage of fees that the miner gets to claim versus what they have to donate to the pool based on the size of the block they generated. Larger blocks would mean a smaller percentage of fees. This is another way to pay for block size, and on average, miners that generate smaller blocks take a share of what otherwise would be part of the mining profits of those generating larger blocks. It is necessary to keep pieces of the section from above on expected blocksize calculation because the closer one is to the expected blocksize, the more they keep. Thus, adjustments need to be made according to usage.In an email from Luke Dashjr on March 30th, 2017, he expressed his skepticism towards a proposal that suggested miners could potentially delay some transactions with lower fees in order to include them in the next block. He argued that miners always mine as if it's their only chance to get the fee, because if they don't, another miner will. Thus, after one block, the fee effectively drops to zero already. However, Dashjr proposed that with correctly configured incentives, making it more profitable to delay certain transactions with lower fees and including them in the next block would smooth out transaction inclusion.One suggestion was to change difficulty scaling from using a simple logarithm to a function that first behaves like a logarithm up to some multiple of the standard block size, after which difficulty starts increasing faster and reaches a greater-than-linear ratio in expected required hash per mined bit. Dashjr also suggested tipping over at around a block size three times the standard block size, since the standard block size increases with continuous load after retargeting, the block size at which this happens also increases.Additionally, Dashjr noted that the fee pool does counteract the idea of delaying transactions with lower fees, as miners will still receive a share via the pool when there are fewer transactions available the next time they create a block, similar to insurance. Therefore, he questioned the incentive for a user to pay an individual miner the fee directly.In a Bitcoin development mailing list, a proposal to expedite transactions by adding a second fee type was made. This would involve a specially labeled anyone-can-spend output with a defined "best-before" block number and a function describing the decline of the fee value for every future block. Miners can claim the full expedience fee plus a standard fee before block N, a reduced expedience fee plus standard fee between block N+1 and N+X, and only the standard fee after that. However, it was pointed out that OP_RETURN wouldn't work in this scenario and a new signature-check opcode would be required. Additionally, there is no real purpose to this proposal as miners already mine for fees as if it's their only chance to get the fee, so the fee effectively drops to 0 after one block. Another proposal that was softfork compatible was made for a fee pool to prevent miners from publishing their own "out of band fee" address and collecting all the fees directly.The author proposes a set of ideas to incentivize behavior improvement in Bitcoin. The first idea is called Expedience fees, which would allow transactions to have a second fee type that would grant miners the ability to claim a "best-before" block number for a given function that describes the decline of the fee value for every future block. When a transaction is processed late, the remainder of the expedience fee output is returned to the specified address among the inputs/outputs. The second idea is called Fee Pool, which is intended to act as a "buffer" to smooth out fee payments and prevent deliberate forking to steal fees. The third idea is Block size dependent difficulty scaling, which proposes that larger blocks mean greater difficulty, but it doesn't scale linearly. In order for a miner to profit from additional transactions, their fees must exceed the calculated cost of the resulting difficulty penalty to make it worth creating a larger block. The author believes that combining Expedience fees with Block size dependent difficulty scaling makes it even more effective. 2017-03-31T04:15:17+00:00 + On March 30, 2017, a proposal was made to alter the difficulty scaling of block size. The proposal suggests that larger blocks would mean greater difficulty, but this doesn't scale linearly. Miners can take a penalty in difficulty to claim a greater number of high fee transactions in the same amount of time, effectively increasing their profits. However, when such profitable fees aren't available, they have to reduce the block size. In other words, users pay miners to increase block size, or don't pay, which reduces it.The proposal suggests that the process could be simplified if a fee pool is created through softfork code instead of hardfork code. However, the effect will be partially reduced by the mining subsidy until it reaches parity with average total fees. Instead of altering the difficulty calculation, the proposal suggests altering the percentage of fees that the miner gets to claim versus what they have to donate to the pool based on the size of the block they generated. Larger blocks would mean a smaller percentage of fees. This is another way to pay for block size, and on average, miners that generate smaller blocks take a share of what otherwise would be part of the mining profits of those generating larger blocks. It is necessary to keep pieces of the section from above on expected blocksize calculation because the closer one is to the expected blocksize, the more they keep. Thus, adjustments need to be made according to usage.In an email from Luke Dashjr on March 30th, 2017, he expressed his skepticism towards a proposal that suggested miners could potentially delay some transactions with lower fees in order to include them in the next block. He argued that miners always mine as if it's their only chance to get the fee, because if they don't, another miner will. Thus, after one block, the fee effectively drops to zero already. However, Dashjr proposed that with correctly configured incentives, making it more profitable to delay certain transactions with lower fees and including them in the next block would smooth out transaction inclusion.One suggestion was to change difficulty scaling from using a simple logarithm to a function that first behaves like a logarithm up to some multiple of the standard block size, after which difficulty starts increasing faster and reaches a greater-than-linear ratio in expected required hash per mined bit. Dashjr also suggested tipping over at around a block size three times the standard block size, since the standard block size increases with continuous load after retargeting, the block size at which this happens also increases.Additionally, Dashjr noted that the fee pool does counteract the idea of delaying transactions with lower fees, as miners will still receive a share via the pool when there are fewer transactions available the next time they create a block, similar to insurance. Therefore, he questioned the incentive for a user to pay an individual miner the fee directly.In a Bitcoin development mailing list, a proposal to expedite transactions by adding a second fee type was made. This would involve a specially labeled anyone-can-spend output with a defined "best-before" block number and a function describing the decline of the fee value for every future block. Miners can claim the full expedience fee plus a standard fee before block N, a reduced expedience fee plus standard fee between block N+1 and N+X, and only the standard fee after that. However, it was pointed out that OP_RETURN wouldn't work in this scenario and a new signature-check opcode would be required. Additionally, there is no real purpose to this proposal as miners already mine for fees as if it's their only chance to get the fee, so the fee effectively drops to 0 after one block. Another proposal that was softfork compatible was made for a fee pool to prevent miners from publishing their own "out of band fee" address and collecting all the fees directly.The author proposes a set of ideas to incentivize behavior improvement in Bitcoin. The first idea is called Expedience fees, which would allow transactions to have a second fee type that would grant miners the ability to claim a "best-before" block number for a given function that describes the decline of the fee value for every future block. When a transaction is processed late, the remainder of the expedience fee output is returned to the specified address among the inputs/outputs. The second idea is called Fee Pool, which is intended to act as a "buffer" to smooth out fee payments and prevent deliberate forking to steal fees. The third idea is Block size dependent difficulty scaling, which proposes that larger blocks mean greater difficulty, but it doesn't scale linearly. In order for a miner to profit from additional transactions, their fees must exceed the calculated cost of the resulting difficulty penalty to make it worth creating a larger block. The author believes that combining Expedience fees with Block size dependent difficulty scaling makes it even more effective. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml b/static/bitcoin-dev/March_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml index f4364d22b6..a357e1d639 100644 --- a/static/bitcoin-dev/March_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml +++ b/static/bitcoin-dev/March_2017/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml @@ -1,113 +1,147 @@ - + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 - - bfd at cock.lu 2017-04-01 23:49:03+00:00 - - - Tom Harding 2017-03-16 15:05:11+00:00 - - - bfd at cock.lu 2017-03-16 00:25:01+00:00 - - - Tom Harding 2017-03-15 22:36:09+00:00 - - - Chris Belcher 2017-02-17 00:28:59+00:00 - - - Erik Aronesty 2017-01-06 22:07:36+00:00 - - - Eric Voskuil 2017-01-06 21:50:47+00:00 - - - James MacWhyte 2017-01-06 21:35:58+00:00 - - - Chris Priest 2017-01-06 20:15:46+00:00 - - - Aaron Voisine 2017-01-06 07:07:34+00:00 - - - bfd at cock.lu 2017-01-06 02:15:26+00:00 - - - bfd at cock.lu 2017-01-06 02:04:22+00:00 - - - Christian Decker 2017-01-05 14:48:33+00:00 - - - Eric Voskuil 2017-01-05 07:45:18+00:00 - - - Chris Priest 2017-01-05 07:06:36+00:00 - - - Leo Wandersleb 2017-01-04 16:13:41+00:00 - - - Adam Back 2017-01-04 11:00:55+00:00 - - - Jorge Timón 2017-01-04 10:13:02+00:00 - - - Aaron Voisine 2017-01-04 08:56:21+00:00 - - - Jonas Schnelli 2017-01-04 07:47:10+00:00 - - - Eric Voskuil 2017-01-04 06:06:31+00:00 - - - Aaron Voisine 2017-01-04 00:36:34+00:00 - - - bfd at cock.lu 2017-01-04 00:10:14+00:00 - - - Aaron Voisine 2017-01-03 23:46:00+00:00 - - - adiabat 2017-01-03 23:06:26+00:00 - - - bfd at cock.lu 2017-01-03 22:28:56+00:00 - - - Aaron Voisine 2017-01-03 22:18:21+00:00 - - - bfd at cock.lu 2017-01-03 20:24:35+00:00 - - - bfd at cock.lu 2017-01-03 20:18:59+00:00 - - - Jonas Schnelli 2017-01-01 21:01:23+00:00 - - - Leo Wandersleb 2016-07-28 21:07:29+00:00 - - - Bob McElrath 2016-05-11 20:29:33+00:00 - - - Bob McElrath 2016-05-11 20:06:48+00:00 - - - Gregory Maxwell 2016-05-09 08:57:08+00:00 - - - bfd at cock.lu 2016-05-09 08:26:06+00:00 - + 2025-09-26T15:37:05.114440+00:00 + python-feedgen + + + [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd + 2016-05-09T08:26:00.000Z + + + Gregory Maxwell + 2016-05-09T08:57:00.000Z + + + Bob McElrath + 2016-05-11T20:06:00.000Z + + + Bob McElrath + 2016-05-11T20:29:00.000Z + + + Leo Wandersleb + 2016-07-28T21:07:00.000Z + + + bfd + 2017-01-03T20:18:00.000Z + + + bfd + 2017-01-03T20:24:00.000Z + + + Aaron Voisine + 2017-01-03T22:18:00.000Z + + + bfd + 2017-01-03T22:28:00.000Z + + + adiabat + 2017-01-03T23:06:00.000Z + + + Aaron Voisine + 2017-01-03T23:46:00.000Z + + + bfd + 2017-01-04T00:10:00.000Z + + + Aaron Voisine + 2017-01-04T00:36:00.000Z + + + Eric Voskuil + 2017-01-04T06:06:00.000Z + + + Jonas Schnelli + 2017-01-04T07:47:00.000Z + + + Aaron Voisine + 2017-01-04T08:56:00.000Z + + + Jorge Timón + 2017-01-04T10:13:00.000Z + + + Adam Back + 2017-01-04T11:00:00.000Z + + + Leo Wandersleb + 2017-01-04T16:13:00.000Z + + + Chris Priest + 2017-01-05T07:06:00.000Z + + + Eric Voskuil + 2017-01-05T07:45:00.000Z + + + Christian Decker + 2017-01-05T14:48:00.000Z + + + bfd + 2017-01-06T02:04:00.000Z + + + bfd + 2017-01-06T02:15:00.000Z + + + Aaron Voisine + 2017-01-06T07:07:00.000Z + + + Chris Priest + 2017-01-06T20:15:00.000Z + + + James MacWhyte + 2017-01-06T21:35:00.000Z + + + Eric Voskuil + 2017-01-06T21:50:00.000Z + + + Erik Aronesty + 2017-01-06T22:07:00.000Z + + + Chris Belcher + 2017-02-17T00:28:00.000Z + + + Tom Harding + 2017-03-15T22:36:00.000Z + + + bfd + 2017-03-16T00:25:00.000Z + + + Tom Harding + 2017-03-16T15:05:00.000Z + + + bfd + 2017-04-01T23:49:00.000Z + + @@ -143,13 +177,13 @@ - python-feedgen + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 + 2025-09-26T15:37:05.118226+00:00 - In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On 2017-04-01T23:49:03+00:00 + In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Currency-exchange-rate-information-API.xml b/static/bitcoin-dev/March_2017/combined_Currency-exchange-rate-information-API.xml index 07dcc98c16..e454478763 100644 --- a/static/bitcoin-dev/March_2017/combined_Currency-exchange-rate-information-API.xml +++ b/static/bitcoin-dev/March_2017/combined_Currency-exchange-rate-information-API.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Currency/exchange rate information API - 2023-08-01T19:42:24.341628+00:00 - - Andrew LeCody 2017-03-13 18:10:57+00:00 - - - Marcel Jamin 2017-03-07 09:29:24+00:00 - - - Andreas Schildbach 2017-03-06 23:14:13+00:00 - - - Tim Ruffing 2017-03-06 22:38:25+00:00 - - - Tim Ruffing 2017-03-06 22:30:59+00:00 - - - Luke Dashjr 2017-03-06 22:21:24+00:00 - - - Luke Dashjr 2017-03-06 22:14:47+00:00 - - - Tim Ruffing 2017-03-06 22:02:53+00:00 - - - Tim Ruffing 2017-03-06 21:54:16+00:00 - - - Jonas Schnelli 2017-03-06 08:14:23+00:00 - - - Luke Dashjr 2017-03-06 07:09:39+00:00 - - - Tim Ruffing 2017-03-06 05:37:24+00:00 - - - アルム　カールヨハン 2017-03-04 15:18:50+00:00 - - - Luke Dashjr 2017-03-04 08:27:32+00:00 - + 2025-09-26T15:36:54.585739+00:00 + python-feedgen + + + [bitcoin-dev] Currency/exchange rate information API Luke Dashjr + 2017-03-04T08:27:00.000Z + + + アルム　カールヨハン + 2017-03-04T15:18:00.000Z + + + Tim Ruffing + 2017-03-06T05:37:00.000Z + + + Luke Dashjr + 2017-03-06T07:09:00.000Z + + + Jonas Schnelli + 2017-03-06T08:14:00.000Z + + + Tim Ruffing + 2017-03-06T21:54:00.000Z + + + Tim Ruffing + 2017-03-06T22:02:00.000Z + + + Luke Dashjr + 2017-03-06T22:14:00.000Z + + + Luke Dashjr + 2017-03-06T22:21:00.000Z + + + Tim Ruffing + 2017-03-06T22:30:00.000Z + + + Tim Ruffing + 2017-03-06T22:38:00.000Z + + + Andreas Schildbach + 2017-03-06T23:14:00.000Z + + + Marcel Jamin + 2017-03-07T09:29:00.000Z + + + Andrew LeCody + 2017-03-13T18:10:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Currency/exchange rate information API - 2023-08-01T19:42:24.341628+00:00 + 2025-09-26T15:36:54.587314+00:00 - The Bitcoin developer community is exploring the inclusion of fiat currency information in Bitcoin Knots. Currently, there is a lack of a common format for this data, resulting in multiple implementations in Electrum. To address this issue, Luke Dashjr has drafted a Bitcoin Improvement Proposal (BIP) that aims to standardize the process. The draft suggests using XBT (as BTC) for Bitcoin amounts, although it may not be the ideal option as satoshis do not have a pseudo-ISO currency code. The format of JSON used in the API is called JSON Streaming, and as long as exchanges adhere to the BIP and maintain one JSON object per line, decoding will not be an issue. Clients should word-wrap long lines and use JSON escapes for newlines. In a discussion on the bitcoin-dev mailing list, Tim Ruffing questioned the necessity of historical rate information for typical applications. However, it was argued that this feature is indeed necessary as all incoming transactions are historical, and wallets are often offline when these transactions occur. This highlights the importance of understanding the technical details and requirements of cryptocurrency applications.Furthermore, Ruffing suggested the need for a standardized way of indicating connection status to clients, including an "out-of-date" warning. However, he later corrected himself, realizing that he had mixed up two separate issues: keepalive for longpolling and the definition of low and high. Regarding keepalive for longpolling, Ruffing expressed uncertainty about whether it's better solved with TCP keepalive or on a higher layer. For defining low and high, he felt that providing exact definitions in the BIP would not be detrimental since it's a minor issue overall.Luke Dashjr addressed privacy concerns related to requesting specific timestamps, suggesting that when from/to don't have an exact record, the previous/next (respectively) should be provided. He also mentioned the potential usefulness of a standardized way of indicating the meaning of user-defined values in the type field.Ruffing brought up the need for a periodic message system in longpolling, as without it, clients cannot distinguish between a situation where the value is still within requested bounds and when the connection has dropped. Another participant in the discussion pointed out that this was actually the job of TCP and questioned the necessity of an explicit keepalive configuration.In terms of displaying historical transactions, Ruffing suggested that the exchange rate at the time of payment would be useful but there is currently no query to retrieve the value closest to a specific timestamp. Ruffing specified that when from/to don't have an exact record, the previous/next (respectively) should be provided. However, the client or server cannot specify granularity in the current draft, leading to potential issues with timezone and daylight saving time. Ruffing also proposed defining precise values for the type field and suggesting that the server should specify the meaning of "low" in the description of the currency-pair feed.The Bitcoin Improvement Proposal (BIP) aims to reduce workload during implementation and allow for more data to be shown to users without implementing proprietary APIs. Longpolling is seen as useful for Bitcoin due to the significant fluctuations in rates over a short period. However, there are concerns about public API connections reaching their maximum limit. The historical rate feature is deemed necessary for displaying historical transactions, but its usefulness is questionable. The ability to choose the time scale of data and clearly define the type field is considered important. Pushing may be more suitable for "current" rates than polling, but it adds complexity in other areas such as state. Authentication of servers and the use of HTTPS to prevent manipulation of exchange rates were discussed as important factors. There is a need for a query that retrieves the closest value to a specific timestamp, allowing the market rate at the time of payment to be displayed. However, it was mentioned that not all clients want to download and process a large amount of historical data. The current draft is insufficient for specifying granularity, raising issues with timezone and daylight saving time. Luke Dashjr proposed the BIP to standardize fiat currency information in Bitcoin Knots, aiming to simplify interoperability between exchange rate providers and wallets or other software. However, there are still concerns about missing critical components and improving the interface. 2017-03-13T18:10:57+00:00 + The Bitcoin developer community is exploring the inclusion of fiat currency information in Bitcoin Knots. Currently, there is a lack of a common format for this data, resulting in multiple implementations in Electrum. To address this issue, Luke Dashjr has drafted a Bitcoin Improvement Proposal (BIP) that aims to standardize the process. The draft suggests using XBT (as BTC) for Bitcoin amounts, although it may not be the ideal option as satoshis do not have a pseudo-ISO currency code. The format of JSON used in the API is called JSON Streaming, and as long as exchanges adhere to the BIP and maintain one JSON object per line, decoding will not be an issue. Clients should word-wrap long lines and use JSON escapes for newlines. In a discussion on the bitcoin-dev mailing list, Tim Ruffing questioned the necessity of historical rate information for typical applications. However, it was argued that this feature is indeed necessary as all incoming transactions are historical, and wallets are often offline when these transactions occur. This highlights the importance of understanding the technical details and requirements of cryptocurrency applications.Furthermore, Ruffing suggested the need for a standardized way of indicating connection status to clients, including an "out-of-date" warning. However, he later corrected himself, realizing that he had mixed up two separate issues: keepalive for longpolling and the definition of low and high. Regarding keepalive for longpolling, Ruffing expressed uncertainty about whether it's better solved with TCP keepalive or on a higher layer. For defining low and high, he felt that providing exact definitions in the BIP would not be detrimental since it's a minor issue overall.Luke Dashjr addressed privacy concerns related to requesting specific timestamps, suggesting that when from/to don't have an exact record, the previous/next (respectively) should be provided. He also mentioned the potential usefulness of a standardized way of indicating the meaning of user-defined values in the type field.Ruffing brought up the need for a periodic message system in longpolling, as without it, clients cannot distinguish between a situation where the value is still within requested bounds and when the connection has dropped. Another participant in the discussion pointed out that this was actually the job of TCP and questioned the necessity of an explicit keepalive configuration.In terms of displaying historical transactions, Ruffing suggested that the exchange rate at the time of payment would be useful but there is currently no query to retrieve the value closest to a specific timestamp. Ruffing specified that when from/to don't have an exact record, the previous/next (respectively) should be provided. However, the client or server cannot specify granularity in the current draft, leading to potential issues with timezone and daylight saving time. Ruffing also proposed defining precise values for the type field and suggesting that the server should specify the meaning of "low" in the description of the currency-pair feed.The Bitcoin Improvement Proposal (BIP) aims to reduce workload during implementation and allow for more data to be shown to users without implementing proprietary APIs. Longpolling is seen as useful for Bitcoin due to the significant fluctuations in rates over a short period. However, there are concerns about public API connections reaching their maximum limit. The historical rate feature is deemed necessary for displaying historical transactions, but its usefulness is questionable. The ability to choose the time scale of data and clearly define the type field is considered important. Pushing may be more suitable for "current" rates than polling, but it adds complexity in other areas such as state. Authentication of servers and the use of HTTPS to prevent manipulation of exchange rates were discussed as important factors. There is a need for a query that retrieves the closest value to a specific timestamp, allowing the market rate at the time of payment to be displayed. However, it was mentioned that not all clients want to download and process a large amount of historical data. The current draft is insufficient for specifying granularity, raising issues with timezone and daylight saving time. Luke Dashjr proposed the BIP to standardize fiat currency information in Bitcoin Knots, aiming to simplify interoperability between exchange rate providers and wallets or other software. However, there are still concerns about missing critical components and improving the interface. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Defending-against-empty-or-near-empty-blocks-from-malicious-miner-takeover-.xml b/static/bitcoin-dev/March_2017/combined_Defending-against-empty-or-near-empty-blocks-from-malicious-miner-takeover-.xml index 00e8ece4dd..16ab4f80f5 100644 --- a/static/bitcoin-dev/March_2017/combined_Defending-against-empty-or-near-empty-blocks-from-malicious-miner-takeover-.xml +++ b/static/bitcoin-dev/March_2017/combined_Defending-against-empty-or-near-empty-blocks-from-malicious-miner-takeover-.xml @@ -1,71 +1,99 @@ - + 2 Combined summary - Defending against empty or near empty blocks from malicious miner takeover? - 2023-08-01T19:54:14.648636+00:00 - - CANNON 2017-04-14 02:22:18+00:00 - - - Aymeric Vitte 2017-03-27 10:25:00+00:00 - - - Eric Voskuil 2017-03-26 22:15:54+00:00 - - - Tom Harding 2017-03-26 21:42:51+00:00 - - - Eric Voskuil 2017-03-26 21:12:20+00:00 - - - Bryan Bishop 2017-03-26 20:44:12+00:00 - - - Trevin Hofmann 2017-03-26 20:37:28+00:00 - - - Bryan Bishop 2017-03-26 20:22:19+00:00 - - - Alphonse Pace 2017-03-26 20:20:56+00:00 - - - Peter R 2017-03-26 19:05:38+00:00 - - - Alex Morcos 2017-03-26 11:27:30+00:00 - - - Chris Pacia 2017-03-26 09:13:17+00:00 - - - Alex Morcos 2017-03-26 02:38:16+00:00 - - - Peter R 2017-03-25 20:28:44+00:00 - - - CANNON 2017-03-25 16:12:54+00:00 - - - Aymeric Vitte 2017-03-24 19:00:40+00:00 - - - Aymeric Vitte 2017-03-24 19:00:31+00:00 - - - Hampus Sjöberg 2017-03-24 17:37:25+00:00 - - - Nick ODell 2017-03-24 17:29:54+00:00 - - - Emin Gün Sirer 2017-03-24 16:27:47+00:00 - - - CANNON 2017-03-24 16:03:31+00:00 - + 2025-09-26T15:36:48.286905+00:00 + python-feedgen + + + [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? CANNON + 2017-03-24T16:03:00.000Z + + + Emin Gün Sirer + 2017-03-24T16:27:00.000Z + + + Nick ODell + 2017-03-24T17:29:00.000Z + + + Hampus Sjöberg + 2017-03-24T17:37:00.000Z + + + Aymeric Vitte + 2017-03-24T19:00:00.000Z + + + [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? Aymeric Vitte + 2017-03-24T19:00:00.000Z + + + CANNON + 2017-03-25T16:12:00.000Z + + + Peter R + 2017-03-25T20:28:00.000Z + + + Alex Morcos + 2017-03-26T02:38:00.000Z + + + [bitcoin-dev] Two altcoins and a 51% attack (was: Defending against empty or near empty blocks from malicious miner takeover?) Eric Voskuil + 2017-03-26T03:00:00.000Z + + + Chris Pacia + 2017-03-26T09:13:00.000Z + + + Alex Morcos + 2017-03-26T11:27:00.000Z + + + Peter R + 2017-03-26T19:05:00.000Z + + + Alphonse Pace + 2017-03-26T20:20:00.000Z + + + Bryan Bishop + 2017-03-26T20:22:00.000Z + + + Trevin Hofmann + 2017-03-26T20:37:00.000Z + + + Bryan Bishop + 2017-03-26T20:44:00.000Z + + + Eric Voskuil + 2017-03-26T21:12:00.000Z + + + Tom Harding + 2017-03-26T21:42:00.000Z + + + Eric Voskuil + 2017-03-26T22:15:00.000Z + + + Aymeric Vitte + 2017-03-27T10:25:00.000Z + + + CANNON + 2017-04-14T02:22:00.000Z + + @@ -87,13 +115,13 @@ - python-feedgen + 2 Combined summary - Defending against empty or near empty blocks from malicious miner takeover? - 2023-08-01T19:54:14.648636+00:00 + 2025-09-26T15:36:48.289478+00:00 - In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the language used to describe future network upgrades. The debate focused on whether the term "network upgrade" was misleading and whether a proposed attack on the old chain was an attempt to transfer economic activity from BTC to BTU. There were also questions about the ethics of minority hash power producers in such situations.One concern raised by Emin Gün Sirer was that filling empty blocks with transactions could lead to forks and create a new attack vector. He warned that bad actors could time the flood of new transactions with the discovery of a block by a competitor in order to orphan the block and fork the chain. However, Peter R criticized the use of the term "network upgrade" instead of the technical term "hard fork," finding it misleading. Eric Voskuil had presented the proposal on behalf of an unknown group, which led to questions about the lack of clarity around the proposal and its proponents.The discussion also touched on the activation of segwit through bip9-based soft-fork. Bryan Bishop and Peter R discussed the possibility of a hash power minority not upgrading and producing a minority branch. Peter R suggested that any invalid blocks produced by the minority would be orphaned, serving as a wake-up call to upgrade. However, Bishop refuted this claim, stating that miner blocks will not be orphaned unless they are intentionally segwit-invalid.Trevin Hofmann and Bryan also discussed the issue of non-upgraded miners producing invalid blocks. Hofmann argued that if non-upgraded miners follow the new rules, their blocks will not be orphaned. Bryan countered that there is no need for a "wake-up call to upgrade" as the point of a soft-fork is to reduce incompatibility. He suggested running "border nodes" to ensure compliance.The proposed techniques to reduce the chances of a blockchain split involve orphaning the blocks of non-compliant miners and re-organizing any minority branch with empty blocks. However, some members of the community believe that a peaceful split would be preferable to these proposed tactics for enforcing the upgrade. Peter R believes that miners will not upgrade until they are confident that no minority chain will survive.The discussion also touched on the definition and implementation of soft forks and hard forks. There were concerns about the lack of precision and consistency in discussing these concepts, and whether miners should have the right to enforce soft forks. Alex Morcos expressed disapproval of implementing Segregated Witness (SegWit) as a soft fork, arguing that it prevents users from using the rules they want.Overall, there is ongoing debate and concern within the Bitcoin community regarding network upgrades, terminology, consensus requirements, and the potential for blockchain splits. Various proposals and arguments have been put forward to address these issues, with differing opinions on the best approaches to ensuring a smooth transition and minimizing disruption.Another issue of concern within the Bitcoin community is the centralization of mining power. Currently, only a small group of people control a majority of the hashing power, leading to concerns about their ability to manipulate the network for their own agenda. The fear is that these miners could kill the valid chain to force economic activity onto their adversary-controlled chain.One proposed update is to ignore empty blocks as a means of mitigating the problem of blocking empty or near-empty blocks. However, there are concerns about defense from blocks that are intentionally small but not empty. It may be possible to have nodes ignore not only empty blocks but also abnormally small blocks compared to the number of valid transactions in the mempool.There needs to be discussion on various attacks and how they can be guarded against, along with contingency plans. Increasing the number of full nodes is suggested as a priority, along with designing incentives for people to run full nodes and setting up a system for people to set up full nodes in a timely manner. It is proposed that Bram Cohen be asked to resurrect the bitcoin miner Epic Scale, which could increase mining power if users upgrade. Additionally, activating proof of space by anticipation is suggested as an alternative solution.Promoting full nodes by making the bitcoin-qt blockchain and chain state available through torrents is also suggested to encourage more people to set up full nodes. However, it is acknowledged that there is historical consensus between miners and developers that may have hindered the prioritization of increasing the number of full nodes.In the email conversation on the bitcoin-dev mailing list, concerns were raised over a proposal to update nodes to ignore empty blocks. The concern was that this would make block validity depend on things that are not in the blockchain and could lead to different mempool sizes for different nodes, causing a lack of consensus. There was also concern about malicious miners orphaning the chain after many blocks, even with non-empty blocks, and whether it was possible to mitigate this.The overall discussion revolved around the issue of centralization of mining power and the potential threat posed by a small group of miners controlling a large amount of hash power. The 2017-04-14T02:22:18+00:00 + In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the language used to describe future network upgrades. The debate focused on whether the term "network upgrade" was misleading and whether a proposed attack on the old chain was an attempt to transfer economic activity from BTC to BTU. There were also questions about the ethics of minority hash power producers in such situations.One concern raised by Emin Gün Sirer was that filling empty blocks with transactions could lead to forks and create a new attack vector. He warned that bad actors could time the flood of new transactions with the discovery of a block by a competitor in order to orphan the block and fork the chain. However, Peter R criticized the use of the term "network upgrade" instead of the technical term "hard fork," finding it misleading. Eric Voskuil had presented the proposal on behalf of an unknown group, which led to questions about the lack of clarity around the proposal and its proponents.The discussion also touched on the activation of segwit through bip9-based soft-fork. Bryan Bishop and Peter R discussed the possibility of a hash power minority not upgrading and producing a minority branch. Peter R suggested that any invalid blocks produced by the minority would be orphaned, serving as a wake-up call to upgrade. However, Bishop refuted this claim, stating that miner blocks will not be orphaned unless they are intentionally segwit-invalid.Trevin Hofmann and Bryan also discussed the issue of non-upgraded miners producing invalid blocks. Hofmann argued that if non-upgraded miners follow the new rules, their blocks will not be orphaned. Bryan countered that there is no need for a "wake-up call to upgrade" as the point of a soft-fork is to reduce incompatibility. He suggested running "border nodes" to ensure compliance.The proposed techniques to reduce the chances of a blockchain split involve orphaning the blocks of non-compliant miners and re-organizing any minority branch with empty blocks. However, some members of the community believe that a peaceful split would be preferable to these proposed tactics for enforcing the upgrade. Peter R believes that miners will not upgrade until they are confident that no minority chain will survive.The discussion also touched on the definition and implementation of soft forks and hard forks. There were concerns about the lack of precision and consistency in discussing these concepts, and whether miners should have the right to enforce soft forks. Alex Morcos expressed disapproval of implementing Segregated Witness (SegWit) as a soft fork, arguing that it prevents users from using the rules they want.Overall, there is ongoing debate and concern within the Bitcoin community regarding network upgrades, terminology, consensus requirements, and the potential for blockchain splits. Various proposals and arguments have been put forward to address these issues, with differing opinions on the best approaches to ensuring a smooth transition and minimizing disruption.Another issue of concern within the Bitcoin community is the centralization of mining power. Currently, only a small group of people control a majority of the hashing power, leading to concerns about their ability to manipulate the network for their own agenda. The fear is that these miners could kill the valid chain to force economic activity onto their adversary-controlled chain.One proposed update is to ignore empty blocks as a means of mitigating the problem of blocking empty or near-empty blocks. However, there are concerns about defense from blocks that are intentionally small but not empty. It may be possible to have nodes ignore not only empty blocks but also abnormally small blocks compared to the number of valid transactions in the mempool.There needs to be discussion on various attacks and how they can be guarded against, along with contingency plans. Increasing the number of full nodes is suggested as a priority, along with designing incentives for people to run full nodes and setting up a system for people to set up full nodes in a timely manner. It is proposed that Bram Cohen be asked to resurrect the bitcoin miner Epic Scale, which could increase mining power if users upgrade. Additionally, activating proof of space by anticipation is suggested as an alternative solution.Promoting full nodes by making the bitcoin-qt blockchain and chain state available through torrents is also suggested to encourage more people to set up full nodes. However, it is acknowledged that there is historical consensus between miners and developers that may have hindered the prioritization of increasing the number of full nodes.In the email conversation on the bitcoin-dev mailing list, concerns were raised over a proposal to update nodes to ignore empty blocks. The concern was that this would make block validity depend on things that are not in the blockchain and could lead to different mempool sizes for different nodes, causing a lack of consensus. There was also concern about malicious miners orphaning the chain after many blocks, even with non-empty blocks, and whether it was possible to mitigate this.The overall discussion revolved around the issue of centralization of mining power and the potential threat posed by a small group of miners controlling a large amount of hash power. The - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Encouraging-good-miners.xml b/static/bitcoin-dev/March_2017/combined_Encouraging-good-miners.xml index 408c7cedae..f93d8b1e0b 100644 --- a/static/bitcoin-dev/March_2017/combined_Encouraging-good-miners.xml +++ b/static/bitcoin-dev/March_2017/combined_Encouraging-good-miners.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Encouraging good miners - 2023-08-01T19:56:15.927518+00:00 - - Juan Garavaglia 2017-03-28 14:38:40+00:00 - - - Antoine Le Calvez 2017-03-27 20:56:49+00:00 - - - Eric Voskuil 2017-03-27 20:01:41+00:00 - - - Stian Ellingsen 2017-03-27 17:50:12+00:00 - - - Tom Zander 2017-03-27 17:29:57+00:00 - - - Btc Ideas 2017-03-27 16:29:26+00:00 - - - Jameson Lopp 2017-03-27 16:29:05+00:00 - - - Btc Ideas 2017-03-27 16:12:19+00:00 - + 2025-09-26T15:36:14.602164+00:00 + python-feedgen + + + [bitcoin-dev] Encouraging good miners Btc Ideas + 2017-03-27T16:12:00.000Z + + + Jameson Lopp + 2017-03-27T16:29:00.000Z + + + Btc Ideas + 2017-03-27T16:29:00.000Z + + + Tom Zander + 2017-03-27T17:29:00.000Z + + + Stian Ellingsen + 2017-03-27T17:50:00.000Z + + + Eric Voskuil + 2017-03-27T20:01:00.000Z + + + Antoine Le Calvez + 2017-03-27T20:56:00.000Z + + + Juan Garavaglia + 2017-03-28T14:38:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Encouraging good miners - 2023-08-01T19:56:15.928527+00:00 + 2025-09-26T15:36:14.603225+00:00 - The bitcoin-dev mailing list is currently discussing ways to incentivize "good" miners and discourage those who mine empty or small blocks. One suggestion is to add a preference for mined blocks with more transactions when two blocks of the same height are found. This would increase the incentive for full blocks, as miners wouldn't be able to assume that a smaller block would win them the reward. However, there are concerns that this could lead to miners filling up their blocks with junk transactions, leaving larger, more space-efficient transactions in the mempool.Another issue raised is that miners may not have an incentive to build upon blocks that contain transactions similar to what they themselves would include based on their mempool at the time. Instead, they may be better off building upon blocks that leave the most valuable transactions in the mempool, such as small or empty blocks, and leave some valuable transactions for the next miner. A proposed solution to this problem is a soft-fork that requires miners to pay a portion of their fees to future miners, encouraging them to include more valuable transactions in their blocks.It is also mentioned that if a miner tries to harm the network by mining empty blocks, the rest of the miners will start rejecting their blocks, causing them to lose the reward incentive and align with the behavior of the rest of the miners.The discussion focuses on promoting efficient transaction patterns on the blockchain. The current approach of incentivizing more transactions is criticized for being inefficient and promoting long transaction chains. Instead, it is suggested to incentivize miners to mine blocks that reduce the UTXO set size or another metric that promotes efficient use of the blockchain.The proposal put forward by Btc Ideas via bitcoin-dev is to add a preference for mined blocks with more transactions when two blocks of the same height are found. This would increase the incentive for full blocks and prevent miners from attacking the chain by mining small or empty blocks. However, it is acknowledged that there are still many ways in which miners can attack the chain.The relation between block size and propagation speed has been decoupled with the use of xthin/compact blocks, allowing miners to send a smaller version of a block that is recreated using the memory pool. This eliminates the need for revalidating transactions when a block is mined. However, it cannot be assumed that all transactions are publicly available. Miners creating bigger blocks as long as all transactions are in the mempool poses no downside. Withholding transactions still maintains the economic advantage of latency as a function of block size, potentially leading to centralization pressure.Overall, the discussion highlights the importance of promoting efficiency in transaction patterns on the blockchain and considering various metrics to incentivize miners towards this goal. The proposal to add a preference for blocks with more transactions is one potential solution, but further consideration and fleshing out of the idea is needed to address potential flaws and ensure its effectiveness. 2017-03-28T14:38:40+00:00 + The bitcoin-dev mailing list is currently discussing ways to incentivize "good" miners and discourage those who mine empty or small blocks. One suggestion is to add a preference for mined blocks with more transactions when two blocks of the same height are found. This would increase the incentive for full blocks, as miners wouldn't be able to assume that a smaller block would win them the reward. However, there are concerns that this could lead to miners filling up their blocks with junk transactions, leaving larger, more space-efficient transactions in the mempool.Another issue raised is that miners may not have an incentive to build upon blocks that contain transactions similar to what they themselves would include based on their mempool at the time. Instead, they may be better off building upon blocks that leave the most valuable transactions in the mempool, such as small or empty blocks, and leave some valuable transactions for the next miner. A proposed solution to this problem is a soft-fork that requires miners to pay a portion of their fees to future miners, encouraging them to include more valuable transactions in their blocks.It is also mentioned that if a miner tries to harm the network by mining empty blocks, the rest of the miners will start rejecting their blocks, causing them to lose the reward incentive and align with the behavior of the rest of the miners.The discussion focuses on promoting efficient transaction patterns on the blockchain. The current approach of incentivizing more transactions is criticized for being inefficient and promoting long transaction chains. Instead, it is suggested to incentivize miners to mine blocks that reduce the UTXO set size or another metric that promotes efficient use of the blockchain.The proposal put forward by Btc Ideas via bitcoin-dev is to add a preference for mined blocks with more transactions when two blocks of the same height are found. This would increase the incentive for full blocks and prevent miners from attacking the chain by mining small or empty blocks. However, it is acknowledged that there are still many ways in which miners can attack the chain.The relation between block size and propagation speed has been decoupled with the use of xthin/compact blocks, allowing miners to send a smaller version of a block that is recreated using the memory pool. This eliminates the need for revalidating transactions when a block is mined. However, it cannot be assumed that all transactions are publicly available. Miners creating bigger blocks as long as all transactions are in the mempool poses no downside. Withholding transactions still maintains the economic advantage of latency as a function of block size, potentially leading to centralization pressure.Overall, the discussion highlights the importance of promoting efficiency in transaction patterns on the blockchain and considering various metrics to incentivize miners towards this goal. The proposal to add a preference for blocks with more transactions is one potential solution, but further consideration and fleshing out of the idea is needed to address potential flaws and ensure its effectiveness. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Flag-day-activation-of-segwit.xml b/static/bitcoin-dev/March_2017/combined_Flag-day-activation-of-segwit.xml index 8ce4215ba7..44213c3e4d 100644 --- a/static/bitcoin-dev/March_2017/combined_Flag-day-activation-of-segwit.xml +++ b/static/bitcoin-dev/March_2017/combined_Flag-day-activation-of-segwit.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Flag day activation of segwit - 2023-08-01T19:46:03.337823+00:00 - - praxeology_guy 2017-03-26 11:08:08+00:00 - - - Nick ODell 2017-03-13 22:18:15+00:00 - - - shaolinfry 2017-03-13 10:54:48+00:00 - - - shaolinfry 2017-03-13 10:36:30+00:00 - - - David Vorick 2017-03-13 10:35:38+00:00 - - - Nick ODell 2017-03-13 04:59:10+00:00 - - - Luke Dashjr 2017-03-13 03:01:40+00:00 - - - shaolinfry 2017-03-12 21:04:11+00:00 - - - David Vorick 2017-03-12 17:20:15+00:00 - - - shaolinfry 2017-03-12 15:50:27+00:00 - + 2025-09-26T15:36:58.807848+00:00 + python-feedgen + + + [bitcoin-dev] Flag day activation of segwit shaolinfry + 2017-03-12T15:50:00.000Z + + + David Vorick + 2017-03-12T17:20:00.000Z + + + shaolinfry + 2017-03-12T21:04:00.000Z + + + Luke Dashjr + 2017-03-13T03:01:00.000Z + + + Nick ODell + 2017-03-13T04:59:00.000Z + + + David Vorick + 2017-03-13T10:35:00.000Z + + + shaolinfry + 2017-03-13T10:36:00.000Z + + + shaolinfry + 2017-03-13T10:54:00.000Z + + + Nick ODell + 2017-03-13T22:18:00.000Z + + + praxeology_guy + 2017-03-26T11:08:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Flag day activation of segwit - 2023-08-01T19:46:03.337823+00:00 + 2025-09-26T15:36:58.809081+00:00 - The discussion revolves around the activation of Segregated Witness (SegWit) on the Bitcoin network. Currently, the proposal states that if at least 1916 out of 2016 blocks signal readiness for SegWit, it will be activated in the next retarget cycle. However, some suggest changing this requirement to just one block signaling readiness. Concerns are raised about participants who do not upgrade and may refuse to build on SegWit blocks or even build on invalid ones. One suggestion is to fork and let them learn the hard way.On the Bitcoin-dev mailing list, a proposal is made for mandatory SegWit activation between October 1st and November 15th, 2017. Developer Luke Dashjr points out that the proposal is not BIP9 compatible and suggests not setting the bit after activation. He also suggests adding a condition to not require mandatory signaling during the LOCKED_IN period. A code is presented to check for SegWit signaling in relayed blocks, with a denial-of-service attack triggered if the block does not signal for SegWit. Compatibility with BIP9 is discussed, suggesting checking if the SegWit bit has already locked in before further checks. The code includes a time condition to ensure the activation period has passed.The community discusses activating SegWit without releasing a new deployment. A counter-fork called "Double UASF" is proposed, enforcing UASF rules plus an additional rule. If 60% of blocks signal for Double UASF, any block creating or spending a segregated witness output is invalid. Miners who adopt Double UASF ban all SegWit transactions and don't need to understand SegWit or commit to a specific structure. It is noted that delayed activation of SegWit hinders protocol innovations such as MAST, Covenants, Schnorr signature schemes, and signature aggregation. Activating the existing SegWit deployment without a new one is suggested, similar to how P2SH was activated.A BIP proposal is made for mandatory SegWit activation between October 1st and November 15th, 2017. It is suggested to obtain cooperation agreements from major economic players before setting a flag day. Non-signaling miners would not get paid and their blocks rejected, incentivizing them to signal or find other profitable options. The existing SegWit deployment would be triggered for those who have upgraded. Close to 100% cooperation is desired as these entities hold user's bitcoins and can threaten the success of a UASF. If the UASF triggers with majority support but miners resist, there may be a temporary minority block reward chain. Failure of the UASF means a permanent coin split.The delayed activation of SegWit hinders protocol innovations and existing systems that rely on SegWit. A suggestion is made to release code that rejects non-signaling SegWit blocks, triggering BIP9 activation. A BIP16-like soft fork flag day activation proposal is drafted, aiming to activate SegWit between October 1st and November 15th, 2017 if the existing deployment is not activated earlier. This would avoid a complete new deployment and hash power veto. The community discusses the importance of the ecosystem industry's investment in SegWit adoption and the need for caution in opposing a UASF.Overall, the discussions focus on activating SegWit and addressing concerns regarding compatibility, participation, and the potential for forks. The delayed activation of SegWit is seen as hindering innovation and existing systems, prompting proposals for mandatory activation and alternative approaches like Double UASF. Cooperation from major economic players is deemed crucial for successful activation. 2017-03-26T11:08:08+00:00 + The discussion revolves around the activation of Segregated Witness (SegWit) on the Bitcoin network. Currently, the proposal states that if at least 1916 out of 2016 blocks signal readiness for SegWit, it will be activated in the next retarget cycle. However, some suggest changing this requirement to just one block signaling readiness. Concerns are raised about participants who do not upgrade and may refuse to build on SegWit blocks or even build on invalid ones. One suggestion is to fork and let them learn the hard way.On the Bitcoin-dev mailing list, a proposal is made for mandatory SegWit activation between October 1st and November 15th, 2017. Developer Luke Dashjr points out that the proposal is not BIP9 compatible and suggests not setting the bit after activation. He also suggests adding a condition to not require mandatory signaling during the LOCKED_IN period. A code is presented to check for SegWit signaling in relayed blocks, with a denial-of-service attack triggered if the block does not signal for SegWit. Compatibility with BIP9 is discussed, suggesting checking if the SegWit bit has already locked in before further checks. The code includes a time condition to ensure the activation period has passed.The community discusses activating SegWit without releasing a new deployment. A counter-fork called "Double UASF" is proposed, enforcing UASF rules plus an additional rule. If 60% of blocks signal for Double UASF, any block creating or spending a segregated witness output is invalid. Miners who adopt Double UASF ban all SegWit transactions and don't need to understand SegWit or commit to a specific structure. It is noted that delayed activation of SegWit hinders protocol innovations such as MAST, Covenants, Schnorr signature schemes, and signature aggregation. Activating the existing SegWit deployment without a new one is suggested, similar to how P2SH was activated.A BIP proposal is made for mandatory SegWit activation between October 1st and November 15th, 2017. It is suggested to obtain cooperation agreements from major economic players before setting a flag day. Non-signaling miners would not get paid and their blocks rejected, incentivizing them to signal or find other profitable options. The existing SegWit deployment would be triggered for those who have upgraded. Close to 100% cooperation is desired as these entities hold user's bitcoins and can threaten the success of a UASF. If the UASF triggers with majority support but miners resist, there may be a temporary minority block reward chain. Failure of the UASF means a permanent coin split.The delayed activation of SegWit hinders protocol innovations and existing systems that rely on SegWit. A suggestion is made to release code that rejects non-signaling SegWit blocks, triggering BIP9 activation. A BIP16-like soft fork flag day activation proposal is drafted, aiming to activate SegWit between October 1st and November 15th, 2017 if the existing deployment is not activated earlier. This would avoid a complete new deployment and hash power veto. The community discusses the importance of the ecosystem industry's investment in SegWit adoption and the need for caution in opposing a UASF.Overall, the discussions focus on activating SegWit and addressing concerns regarding compatibility, participation, and the potential for forks. The delayed activation of SegWit is seen as hindering innovation and existing systems, prompting proposals for mandatory activation and alternative approaches like Double UASF. Cooperation from major economic players is deemed crucial for successful activation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Fraud-proofs-for-block-size-weight.xml b/static/bitcoin-dev/March_2017/combined_Fraud-proofs-for-block-size-weight.xml index 4ea916e87f..4cabd9bddc 100644 --- a/static/bitcoin-dev/March_2017/combined_Fraud-proofs-for-block-size-weight.xml +++ b/static/bitcoin-dev/March_2017/combined_Fraud-proofs-for-block-size-weight.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Fraud proofs for block size/weight - 2023-08-01T19:52:22.764066+00:00 - - Matt Corallo 2017-03-28 22:35:05+00:00 - - - Chris Pacia 2017-03-26 14:16:15+00:00 - - - Luke Dashjr 2017-03-25 05:16:25+00:00 - - - Jorge Timón 2017-03-23 18:27:39+00:00 - - - Matt Corallo 2017-03-22 21:51:08+00:00 - - - Bram Cohen 2017-03-22 20:49:08+00:00 - - - Luke Dashjr 2017-03-22 08:47:30+00:00 - + 2025-09-26T15:36:31.416624+00:00 + python-feedgen + + + [bitcoin-dev] Fraud proofs for block size/weight Luke Dashjr + 2017-03-22T08:47:00.000Z + + + Bram Cohen + 2017-03-22T20:49:00.000Z + + + Matt Corallo + 2017-03-22T21:51:00.000Z + + + Jorge Timón + 2017-03-23T18:27:00.000Z + + + Luke Dashjr + 2017-03-25T05:16:00.000Z + + + Chris Pacia + 2017-03-26T14:16:00.000Z + + + Matt Corallo + 2017-03-28T22:35:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Fraud proofs for block size/weight - 2023-08-01T19:52:22.764066+00:00 + 2025-09-26T15:36:31.417493+00:00 - In a discussion about the validity of blocks in Bitcoin, a user questions the assumption that all blocks are valid aside from size. They argue that as long as it can be assumed that the block is valid and a SHA256 midstate cannot be forged to result in a given hash value, it is not necessary to show that a leaf in the merkle tree is a parseable transaction. However, they concede that accuracy in counting the minimum number of transactions is important due to parts of the merkle tree being repeated. Luke Dashjr expresses concern about the proposal, stating that the only way to establish the number of transactions is to show that a leaf is a parsable transaction, and asks for any ideas.On March 25, 2017, Luke Dashjr asked for ideas in the bitcoin-dev mailing list. He proposed a solution where the size can be aggregated up the tree such that each midstate hash is the hash of branches below plus the aggregate of the sizes below. This would result in the root hash being (left + right + size/weight), and the proof would simply be the preimage.A recent email exchange between Jorge Timón and Luke Dashjr on the bitcoin-dev mailing list discussed the need for better organization in Bitcoin's full block validation specification. Timón suggested that the "Creation of proofs" section should precede "Proof verification," and recommended a clearer definition for "full-weight block proof." Dashjr added a definitions section to the spec and clarified language around rechecking blocks known to be invalid. The two also discussed the need for establishing the correct number of transactions in a block and how a "full tx size proof" can help achieve this, although it was noted that current methods may not be sufficient.Luke Dashjr has presented a draft BIP for fraud proofs and how light clients can detect blockchains that are simply invalid due to excess size and/or weight. This specific attack can be proven, and reliably so, since the proof cannot be broken without also breaking their attempted hardfork at the same time. This is necessary to establish that the claimed block transaction count is correct. The proposed system would allow light clients to verify that a full node they're connected to is not lying to them about the state of the network or the validity of transactions. The draft BIP for fraud proofs includes the creation of proofs, proof verification, proof format, network protocol, rationale, and more. Some questions have been raised regarding the draft BIP, such as whether it requires information to be added to blocks or if it can work on the existing format, does it count the number of transactions or their total length, and does it allow for proofs of length in the positive direction demonstrating that a block is good.The Bitcoin blockchain is at risk of being attacked by miners using oversized blocks to force a hard fork, which could be proven. Users who do not use their own full node for validation may need protection from these attacks to ensure they remain on the Bitcoin blockchain. Luke Dashjr has written a draft BIP for fraud proofs and how light clients can detect blockchains that are invalid due to excess size and/or weight. This draft may be ready for implementation, but suggestions are welcome for improvement. The key observation is that all you need to show the length and hash of a transaction is the final SHA256 midstate and chunk, which can prove the exact size of a transaction. A valid transaction must be at least 60 bytes long for compression. However, much of the compression possibility goes away if you're proving something other than "too large". It is ideal to have an extension to SPV protocol so light clients require proofs of blocks not being too big, given the credible threat of there being an extremely large-scale attack on the network of that form.Luke Dashjr, a Bitcoin developer, has proposed a draft BIP (Bitcoin Improvement Proposal) for fraud proofs which could help light clients detect blockchains that are invalid due to excess size and/or weight resulting from miners attacking with oversized blocks in an attempt to force a hardfork. While ideally all users should use their own full node for validation, many Bitcoin holders still do not and may require protection from these attacks to ensure they remain on the Bitcoin blockchain. The proposed solution can prove if a specific attack is happening and can reliably protect users by ensuring that the proof cannot be broken without also breaking the attempted hardfork at the same time. The draft is available on GitHub and is potentially ready for implementation, though suggestions for improvement are welcome.The generalised case of fraud proofs being impossible has been challenged by recent proposals of miners using oversized blocks to force a hardfork. This specific attack can be proven as the proof cannot be broken without also breaking their attempted hardfork. However, not all bitcoin holders use their own full node for validation leaving them vulnerable to such attacks. To address this, a draft BIP has been written that proposes fraud proofs and how light clients can detect invalid blockchains due to excess size and/or 2017-03-28T22:35:05+00:00 + In a discussion about the validity of blocks in Bitcoin, a user questions the assumption that all blocks are valid aside from size. They argue that as long as it can be assumed that the block is valid and a SHA256 midstate cannot be forged to result in a given hash value, it is not necessary to show that a leaf in the merkle tree is a parseable transaction. However, they concede that accuracy in counting the minimum number of transactions is important due to parts of the merkle tree being repeated. Luke Dashjr expresses concern about the proposal, stating that the only way to establish the number of transactions is to show that a leaf is a parsable transaction, and asks for any ideas.On March 25, 2017, Luke Dashjr asked for ideas in the bitcoin-dev mailing list. He proposed a solution where the size can be aggregated up the tree such that each midstate hash is the hash of branches below plus the aggregate of the sizes below. This would result in the root hash being (left + right + size/weight), and the proof would simply be the preimage.A recent email exchange between Jorge Timón and Luke Dashjr on the bitcoin-dev mailing list discussed the need for better organization in Bitcoin's full block validation specification. Timón suggested that the "Creation of proofs" section should precede "Proof verification," and recommended a clearer definition for "full-weight block proof." Dashjr added a definitions section to the spec and clarified language around rechecking blocks known to be invalid. The two also discussed the need for establishing the correct number of transactions in a block and how a "full tx size proof" can help achieve this, although it was noted that current methods may not be sufficient.Luke Dashjr has presented a draft BIP for fraud proofs and how light clients can detect blockchains that are simply invalid due to excess size and/or weight. This specific attack can be proven, and reliably so, since the proof cannot be broken without also breaking their attempted hardfork at the same time. This is necessary to establish that the claimed block transaction count is correct. The proposed system would allow light clients to verify that a full node they're connected to is not lying to them about the state of the network or the validity of transactions. The draft BIP for fraud proofs includes the creation of proofs, proof verification, proof format, network protocol, rationale, and more. Some questions have been raised regarding the draft BIP, such as whether it requires information to be added to blocks or if it can work on the existing format, does it count the number of transactions or their total length, and does it allow for proofs of length in the positive direction demonstrating that a block is good.The Bitcoin blockchain is at risk of being attacked by miners using oversized blocks to force a hard fork, which could be proven. Users who do not use their own full node for validation may need protection from these attacks to ensure they remain on the Bitcoin blockchain. Luke Dashjr has written a draft BIP for fraud proofs and how light clients can detect blockchains that are invalid due to excess size and/or weight. This draft may be ready for implementation, but suggestions are welcome for improvement. The key observation is that all you need to show the length and hash of a transaction is the final SHA256 midstate and chunk, which can prove the exact size of a transaction. A valid transaction must be at least 60 bytes long for compression. However, much of the compression possibility goes away if you're proving something other than "too large". It is ideal to have an extension to SPV protocol so light clients require proofs of blocks not being too big, given the credible threat of there being an extremely large-scale attack on the network of that form.Luke Dashjr, a Bitcoin developer, has proposed a draft BIP (Bitcoin Improvement Proposal) for fraud proofs which could help light clients detect blockchains that are invalid due to excess size and/or weight resulting from miners attacking with oversized blocks in an attempt to force a hardfork. While ideally all users should use their own full node for validation, many Bitcoin holders still do not and may require protection from these attacks to ensure they remain on the Bitcoin blockchain. The proposed solution can prove if a specific attack is happening and can reliably protect users by ensuring that the proof cannot be broken without also breaking the attempted hardfork at the same time. The draft is available on GitHub and is potentially ready for implementation, though suggestions for improvement are welcome.The generalised case of fraud proofs being impossible has been challenged by recent proposals of miners using oversized blocks to force a hardfork. This specific attack can be proven as the proof cannot be broken without also breaking their attempted hardfork. However, not all bitcoin holders use their own full node for validation leaving them vulnerable to such attacks. To address this, a draft BIP has been written that proposes fraud proofs and how light clients can detect invalid blockchains due to excess size and/or - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml b/static/bitcoin-dev/March_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml index a729e18abb..b5efc53d07 100644 --- a/static/bitcoin-dev/March_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml +++ b/static/bitcoin-dev/March_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hard fork proposal from last week's meeting - 2023-08-01T20:00:31.147207+00:00 + 2025-09-26T15:36:46.166694+00:00 + python-feedgen Staf Verhaegen 2017-04-02 19:12:06+00:00 @@ -327,13 +328,13 @@ - python-feedgen + 2 Combined summary - Hard fork proposal from last week's meeting - 2023-08-01T20:00:31.150204+00:00 + 2025-09-26T15:36:46.166915+00:00 - The Bitcoin community has been engaged in ongoing discussions about the scalability of Bitcoin and the balance between on-chain scaling and layer two scaling. Some members argue that on-chain bandwidth should be available for layer two scaling to thrive and propose exploring sharding solutions. However, others emphasize the importance of individuals running full nodes on personal computers for security and challenge this assertion.The scalability of processing transactions in a distributed system like Bitcoin is a significant challenge. While network speeds have improved, there is still a debate about raising the block size limit. Some participants believe it is possible but risky, while others suggest waiting until SegWit activates before considering any additional increases.Running full nodes on personal computers is seen as crucial for the security of Bitcoin. There are discussions about the feasibility of running nodes and potential alternatives such as lightweight clients, zero-knowledge proofs, and hardware wallets. Maintaining the security of the Bitcoin network is highly dependent on personal computers.The importance of low node costs and the consequences of high transaction fees are also discussed. Some argue that a true fee-market is needed, where miners can choose to make blocks smaller to increase fees. However, increasing transaction fees may allow other cryptocurrencies to gain market share for low-value use cases. The market will continue to innovate solutions when there is profit to be made.The ongoing debate over block size increases involves different factions with differing opinions. It is crucial to carefully consider the impact on node costs and the potential burden on archival nodes. Before making any changes to the block size, implementing fixes and conducting studies are important steps.Overall, the Bitcoin community is actively discussing the scalability of Bitcoin, the importance of individuals running full nodes on personal computers for security, and the ongoing debate over on-chain scaling versus layer two scaling. The cost implications of running a node capable of handling massive transaction volumes are also being considered. In order to address these challenges and ensure the growth and security of Bitcoin, the community is exploring various solutions and technologies. 2017-04-02T19:12:06+00:00 + The Bitcoin community has been engaged in ongoing discussions about the scalability of Bitcoin and the balance between on-chain scaling and layer two scaling. Some members argue that on-chain bandwidth should be available for layer two scaling to thrive and propose exploring sharding solutions. However, others emphasize the importance of individuals running full nodes on personal computers for security and challenge this assertion.The scalability of processing transactions in a distributed system like Bitcoin is a significant challenge. While network speeds have improved, there is still a debate about raising the block size limit. Some participants believe it is possible but risky, while others suggest waiting until SegWit activates before considering any additional increases.Running full nodes on personal computers is seen as crucial for the security of Bitcoin. There are discussions about the feasibility of running nodes and potential alternatives such as lightweight clients, zero-knowledge proofs, and hardware wallets. Maintaining the security of the Bitcoin network is highly dependent on personal computers.The importance of low node costs and the consequences of high transaction fees are also discussed. Some argue that a true fee-market is needed, where miners can choose to make blocks smaller to increase fees. However, increasing transaction fees may allow other cryptocurrencies to gain market share for low-value use cases. The market will continue to innovate solutions when there is profit to be made.The ongoing debate over block size increases involves different factions with differing opinions. It is crucial to carefully consider the impact on node costs and the potential burden on archival nodes. Before making any changes to the block size, implementing fixes and conducting studies are important steps.Overall, the Bitcoin community is actively discussing the scalability of Bitcoin, the importance of individuals running full nodes on personal computers for security, and the ongoing debate over on-chain scaling versus layer two scaling. The cost implications of running a node capable of handling massive transaction volumes are also being considered. In order to address these challenges and ensure the growth and security of Bitcoin, the community is exploring various solutions and technologies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_High-consensus-fork-system-for-scaling-without-limits.xml b/static/bitcoin-dev/March_2017/combined_High-consensus-fork-system-for-scaling-without-limits.xml index 40c65d3f70..339af527de 100644 --- a/static/bitcoin-dev/March_2017/combined_High-consensus-fork-system-for-scaling-without-limits.xml +++ b/static/bitcoin-dev/March_2017/combined_High-consensus-fork-system-for-scaling-without-limits.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - High consensus fork system for scaling without limits - 2023-08-01T19:44:56.013806+00:00 - - Erik Aronesty 2017-03-09 15:29:07+00:00 - - - Andrew Chow 2017-03-08 21:21:15+00:00 - - - Erik Aronesty 2017-03-08 19:42:11+00:00 - + 2025-09-26T15:36:10.386463+00:00 + python-feedgen + + + [bitcoin-dev] High consensus fork system for scaling without limits Erik Aronesty + 2017-03-08T19:42:00.000Z + + + Andrew Chow + 2017-03-08T21:21:00.000Z + + + Erik Aronesty + 2017-03-09T15:29:00.000Z + + - python-feedgen + 2 Combined summary - High consensus fork system for scaling without limits - 2023-08-01T19:44:56.013806+00:00 + 2025-09-26T15:36:10.387060+00:00 - A proposal for a Bitcoin Improvement Proposal (BIP) has been made to allow users and miners to signal their readiness for changes in block size. The proposal suggests introducing an Excessive Block size (EB) as an absolute upper bound that cannot be overridden by miners. Currently, the EB is set at 1MB but can be configured in a config file as an advanced feature.Users are encouraged to publicly report their EBs, and Core developers can ship a version with a default EB that aligns with both miner and economic majority after a 95% consensus fork. A versioning system ensures that the old and new networks are incompatible.The primary goal of this proposal is to remove political issues from affecting core developers. By allowing users and miners to wrangle over fees without developer involvement, it aims to address the inherent political nature of fees, which can create barriers for low-net-worth individuals transacting using this technology.If a small business in Africa, for example, cannot afford to set up a full node due to high fees, it hampers participation as a hub. Therefore, it is important for major exchanges and users to publicly announce their EBs so that miners can have a more reliable signal to go on.The proposal also addresses the broader concept of scaling, highlighting that it encompasses more than just increasing the block size. It emphasizes the need to consider factors beyond block size when addressing scalability.To implement this system, a soft fork and a versioning system would be necessary to ensure compatibility between the old and new networks. Users who fail to update their EB within the 6-month period will be excluded from the majority fork.Overall, the proposed BIP allows users and miners to signal their readiness for changes in block size, introduces an absolute upper bound for block size, and emphasizes the importance of considering scalability beyond just block size. It aims to remove political issues from core developers' decision-making and encourages major exchanges and users to publicly announce their EBs. 2017-03-09T15:29:07+00:00 + A proposal for a Bitcoin Improvement Proposal (BIP) has been made to allow users and miners to signal their readiness for changes in block size. The proposal suggests introducing an Excessive Block size (EB) as an absolute upper bound that cannot be overridden by miners. Currently, the EB is set at 1MB but can be configured in a config file as an advanced feature.Users are encouraged to publicly report their EBs, and Core developers can ship a version with a default EB that aligns with both miner and economic majority after a 95% consensus fork. A versioning system ensures that the old and new networks are incompatible.The primary goal of this proposal is to remove political issues from affecting core developers. By allowing users and miners to wrangle over fees without developer involvement, it aims to address the inherent political nature of fees, which can create barriers for low-net-worth individuals transacting using this technology.If a small business in Africa, for example, cannot afford to set up a full node due to high fees, it hampers participation as a hub. Therefore, it is important for major exchanges and users to publicly announce their EBs so that miners can have a more reliable signal to go on.The proposal also addresses the broader concept of scaling, highlighting that it encompasses more than just increasing the block size. It emphasizes the need to consider factors beyond block size when addressing scalability.To implement this system, a soft fork and a versioning system would be necessary to ensure compatibility between the old and new networks. Users who fail to update their EB within the 6-month period will be excluded from the majority fork.Overall, the proposed BIP allows users and miners to signal their readiness for changes in block size, introduces an absolute upper bound for block size, and emphasizes the importance of considering scalability beyond just block size. It aims to remove political issues from core developers' decision-making and encourages major exchanges and users to publicly announce their EBs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_High-fees-centralization.xml b/static/bitcoin-dev/March_2017/combined_High-fees-centralization.xml index dcf1b91d99..678027dd31 100644 --- a/static/bitcoin-dev/March_2017/combined_High-fees-centralization.xml +++ b/static/bitcoin-dev/March_2017/combined_High-fees-centralization.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - High fees / centralization - 2023-08-01T20:05:59.101814+00:00 - - Staf Verhaegen 2017-04-02 19:45:11+00:00 - - - Vladimir Zaytsev 2017-03-31 02:26:31+00:00 - - - Jared Lee Richardson 2017-03-31 02:01:49+00:00 - - - Vladimir Zaytsev 2017-03-31 01:39:23+00:00 - - - Tom Harding 2017-03-31 01:13:35+00:00 - - - Jared Lee Richardson 2017-03-30 21:52:01+00:00 - - - David Vorick 2017-03-30 16:14:24+00:00 - - - Tom Harding 2017-03-30 15:38:20+00:00 - + 2025-09-26T15:36:37.748233+00:00 + python-feedgen + + + [bitcoin-dev] High fees / centralization Tom Harding + 2017-03-30T15:38:00.000Z + + + David Vorick + 2017-03-30T16:14:00.000Z + + + Jared Lee Richardson + 2017-03-30T21:52:00.000Z + + + Tom Harding + 2017-03-31T01:13:00.000Z + + + Vladimir Zaytsev + 2017-03-31T01:39:00.000Z + + + Jared Lee Richardson + 2017-03-31T02:01:00.000Z + + + Vladimir Zaytsev + 2017-03-31T02:26:00.000Z + + + Staf Verhaegen + 2017-04-02T19:45:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - High fees / centralization - 2023-08-01T20:05:59.102816+00:00 + 2025-09-26T15:36:37.749169+00:00 - Jared Lee Richardson, a member of the bitcoin development community, expressed interest in the concept of blockchain sharding - dividing the blockchain into smaller parts to increase efficiency. However, he expressed doubts about the possibility of resolving conflicts between these shards and committing transactions between them in a trustless manner. Staf suggested a system where different nodes could agree to process parts of transactions, allowing 20,000 nodes to work like 5,000 full nodes.The discussion revolves around the possibility of implementing blockchain sharding in a trustless manner. The concern is about resolving conflicts between the shards and committing transactions between them. Vladimir Zaytsev suggests organizing "branches" of smaller activity to join the main tree after they grow. However, it may not be necessary to accept everything in the chain, and it is too early to record every sight.Jared Lee Richardson points out that fees higher than $1 per transaction are inevitable without blocksize increases, most likely before 2020. He argues that if both monetary sovereignty and supporting daily transactions can be achieved, then why not have both? An altcoin with both will take Bitcoin's monetary sovereignty crown by default.The author suggests that there should be a way to organize "branches" of smaller activity to join the main tree after they grow. They feel that not everything needs to be accepted in the chain and that it is too early to record every sight. The discussion then turns to the topic of transaction fees and whether or not they will become high enough to block home users from using the network. The consensus is that, even without a blocksize increase, most home purchases will be large enough to fit on the blocksize in the foreseeable future. However, it is uncertain what level transaction fees will become unappealing for consumers, with some predicting above $1 per tx, while others predict above $10 as being niche-level. Without a blocksize increase, fees higher than $1/tx are basically inevitable before 2020. The author suggests that if node operational costs are going to be highly weighted, there needs to be a solid justification with mathematical models or examples. The author argues that Bitcoin's core innovation of monetary sovereignty should not be thrown away in pursuit of supporting only 0.1% of the world's daily transactions. They suggest that if both can easily coexist, why not have both? Finally, the author warns that an altcoin with both (monetary sovereignty and support for daily transactions) will take Bitcoin's monetary sovereignty crown by default.In a message exchange between David Vorick and Tom Harding on the bitcoin-dev mailing list, Harding expressed concerns over the effects of rising fees on small miners. He argued that small miners use pools for smaller and more frequent payments, which rising fees will make less feasible, potentially causing them to give up mining altogether. In response, Vorick pointed out that miners get paid once every ten minutes, regardless of the size or number of fee transactions. He also stated that fees are not yet high enough to block home users from using the network, and that it would be unwise to sacrifice the core innovation of monetary sovereignty in order to support a small fraction of daily transactions. However, he acknowledged that rising fees could lead to unintended consequences, such as increased miner centralization and fewer full nodes.The discussion on Bitcoin-dev mailing list revolves around how rising fees could affect the Bitcoin network and its users. While some argue that increasing fees would force home users to stop using the network, others believe that most home purchases will still fit within the blocksize limit even without a blocksize increase. The focus should be on not losing the core innovation of monetary sovereignty in pursuit of supporting only 0.1% of the world's daily transactions. An altcoin with both lower fees and monetary sovereignty would take over Bitcoin's crown. Additionally, small miners who use pools for smaller, more frequent payments would be affected by rising fees and it could lead to centralization of mining power. However, it is argued that fees do not change the payout rate for miners who get paid on average once every ten minutes.In an email to the bitcoin-dev mailing list, Tom Harding responded to Raystonn's argument against small miners using pools by stating that small miners use pools because they want smaller, more frequent payments. Rising fees force them to take payments less frequently and will only lead to more small miners giving up. The centralizing effect is much stronger than the oft-cited worry of small miners joining large pools to decrease orphan rates. According to Harding, miners get paid on average once every ten minutes and the size of fees and number of fee transactions does not change the payout rate. However, he believes that we are still far from the point where fees are high enough to block home users from using the network. Finally, Harding argues that Bitcoin has many high-value use cases such as savings and that the core innovation of monetary sovereignty should not be thrown away in pursuit of supporting 0.1% 2017-04-02T19:45:11+00:00 + Jared Lee Richardson, a member of the bitcoin development community, expressed interest in the concept of blockchain sharding - dividing the blockchain into smaller parts to increase efficiency. However, he expressed doubts about the possibility of resolving conflicts between these shards and committing transactions between them in a trustless manner. Staf suggested a system where different nodes could agree to process parts of transactions, allowing 20,000 nodes to work like 5,000 full nodes.The discussion revolves around the possibility of implementing blockchain sharding in a trustless manner. The concern is about resolving conflicts between the shards and committing transactions between them. Vladimir Zaytsev suggests organizing "branches" of smaller activity to join the main tree after they grow. However, it may not be necessary to accept everything in the chain, and it is too early to record every sight.Jared Lee Richardson points out that fees higher than $1 per transaction are inevitable without blocksize increases, most likely before 2020. He argues that if both monetary sovereignty and supporting daily transactions can be achieved, then why not have both? An altcoin with both will take Bitcoin's monetary sovereignty crown by default.The author suggests that there should be a way to organize "branches" of smaller activity to join the main tree after they grow. They feel that not everything needs to be accepted in the chain and that it is too early to record every sight. The discussion then turns to the topic of transaction fees and whether or not they will become high enough to block home users from using the network. The consensus is that, even without a blocksize increase, most home purchases will be large enough to fit on the blocksize in the foreseeable future. However, it is uncertain what level transaction fees will become unappealing for consumers, with some predicting above $1 per tx, while others predict above $10 as being niche-level. Without a blocksize increase, fees higher than $1/tx are basically inevitable before 2020. The author suggests that if node operational costs are going to be highly weighted, there needs to be a solid justification with mathematical models or examples. The author argues that Bitcoin's core innovation of monetary sovereignty should not be thrown away in pursuit of supporting only 0.1% of the world's daily transactions. They suggest that if both can easily coexist, why not have both? Finally, the author warns that an altcoin with both (monetary sovereignty and support for daily transactions) will take Bitcoin's monetary sovereignty crown by default.In a message exchange between David Vorick and Tom Harding on the bitcoin-dev mailing list, Harding expressed concerns over the effects of rising fees on small miners. He argued that small miners use pools for smaller and more frequent payments, which rising fees will make less feasible, potentially causing them to give up mining altogether. In response, Vorick pointed out that miners get paid once every ten minutes, regardless of the size or number of fee transactions. He also stated that fees are not yet high enough to block home users from using the network, and that it would be unwise to sacrifice the core innovation of monetary sovereignty in order to support a small fraction of daily transactions. However, he acknowledged that rising fees could lead to unintended consequences, such as increased miner centralization and fewer full nodes.The discussion on Bitcoin-dev mailing list revolves around how rising fees could affect the Bitcoin network and its users. While some argue that increasing fees would force home users to stop using the network, others believe that most home purchases will still fit within the blocksize limit even without a blocksize increase. The focus should be on not losing the core innovation of monetary sovereignty in pursuit of supporting only 0.1% of the world's daily transactions. An altcoin with both lower fees and monetary sovereignty would take over Bitcoin's crown. Additionally, small miners who use pools for smaller, more frequent payments would be affected by rising fees and it could lead to centralization of mining power. However, it is argued that fees do not change the payout rate for miners who get paid on average once every ten minutes.In an email to the bitcoin-dev mailing list, Tom Harding responded to Raystonn's argument against small miners using pools by stating that small miners use pools because they want smaller, more frequent payments. Rising fees force them to take payments less frequently and will only lead to more small miners giving up. The centralizing effect is much stronger than the oft-cited worry of small miners joining large pools to decrease orphan rates. According to Harding, miners get paid on average once every ten minutes and the size of fees and number of fee transactions does not change the payout rate. However, he believes that we are still far from the point where fees are high enough to block home users from using the network. Finally, Harding argues that Bitcoin has many high-value use cases such as savings and that the core innovation of monetary sovereignty should not be thrown away in pursuit of supporting 0.1% - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Inquiry-Transaction-Tiering.xml b/static/bitcoin-dev/March_2017/combined_Inquiry-Transaction-Tiering.xml index e7bc4de836..13b3fe002a 100644 --- a/static/bitcoin-dev/March_2017/combined_Inquiry-Transaction-Tiering.xml +++ b/static/bitcoin-dev/March_2017/combined_Inquiry-Transaction-Tiering.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Inquiry: Transaction Tiering - 2023-08-01T19:50:03.601698+00:00 - - Tom Zander 2017-03-29 13:10:05+00:00 - - - Martin Stolze 2017-03-29 12:51:47+00:00 - - - Martin Stolze 2017-03-29 12:48:42+00:00 - - - Tom Zander 2017-03-29 09:04:18+00:00 - - - Martin Stolze 2017-03-28 19:51:02+00:00 - - - Andrew Baine 2017-03-28 14:57:09+00:00 - - - Martin Stolze 2017-03-28 12:58:31+00:00 - - - praxeology_guy 2017-03-28 07:02:35+00:00 - - - Martin Stolze 2017-03-27 21:11:38+00:00 - - - Martin Stolze 2017-03-27 17:18:22+00:00 - - - AJ West 2017-03-27 16:29:20+00:00 - - - greg misiorek 2017-03-26 12:11:44+00:00 - - - praxeology_guy 2017-03-26 11:12:01+00:00 - - - Martin Stolze 2017-03-25 17:15:50+00:00 - - - praxeology_guy 2017-03-25 04:42:30+00:00 - - - Martin Stolze 2017-03-22 17:48:52+00:00 - - - Tim Ruffing 2017-03-21 15:18:26+00:00 - - - Martin Stolze 2017-03-20 20:12:36+00:00 - + 2025-09-26T15:36:25.145666+00:00 + python-feedgen + + + [bitcoin-dev] Inquiry: Transaction Tiering Martin Stolze + 2017-03-20T20:12:00.000Z + + + Tim Ruffing + 2017-03-21T15:18:00.000Z + + + Martin Stolze + 2017-03-22T17:48:00.000Z + + + praxeology_guy + 2017-03-25T04:42:00.000Z + + + Martin Stolze + 2017-03-25T17:15:00.000Z + + + praxeology_guy + 2017-03-26T11:12:00.000Z + + + greg misiorek + 2017-03-26T12:11:00.000Z + + + AJ West + 2017-03-27T16:29:00.000Z + + + Martin Stolze + 2017-03-27T17:18:00.000Z + + + Martin Stolze + 2017-03-27T21:11:00.000Z + + + praxeology_guy + 2017-03-28T07:02:00.000Z + + + Martin Stolze + 2017-03-28T12:58:00.000Z + + + Andrew Baine + 2017-03-28T14:57:00.000Z + + + Martin Stolze + 2017-03-28T19:51:00.000Z + + + Tom Zander + 2017-03-29T09:04:00.000Z + + + Martin Stolze + 2017-03-29T12:48:00.000Z + + + Martin Stolze + 2017-03-29T12:51:00.000Z + + + Tom Zander + 2017-03-29T13:10:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Inquiry: Transaction Tiering - 2023-08-01T19:50:03.601698+00:00 + 2025-09-26T15:36:25.147488+00:00 - In a recent email exchange on the bitcoin-dev mailing list, Martin Stolze questions the assumption that rational economic interest is the driving force behind all hash-power action in Bitcoin mining. He argues that even a small portion of hash power motivated by rational economic interest would validate the concept. Additionally, he refutes the claim that 100% of miners need to be honest, pointing out the distributed nature of the system. Tom Zander suggests taking the discussion to a different forum rather than spamming the dev list.The discussion centers around the concept of "miners as service providers" and providing additional choice to those who are affected by hash-power centralization. The idea is to have miners listen to the network instead of soliciting transactions directly from users, which can go against the peer-to-peer nature of the network. Two proposed methods for providing this service are creating segregated mempools managed by an authenticated third-party and directing mining fees to preferred miners. However, both methods have potential pitfalls that require attention.Bitcoin end-users want to support specific miners based on various factors such as political positions and physical location. Certain miners will naturally become preferred by users regardless of the involvement of the Bitcoin developer community. The recent language used by the ECB and drafts by the EU suggest a need for a way for commercial interest to transact in a regulated space. A proof-of-concept project called Preferred Miner, created by AJ West, aims to stimulate discussion on this issue.Tom Zander responds to a discussion about the authority of transaction processors (block generators) in Bitcoin. He argues that miners do not have authority to decide which transactions to mine or not; rather, they make economic decisions based on their incentives. The distribution of miners means that one miner cannot stop others from mining certain transactions. Concerns about transaction processors having arbitrary authority to discriminate participants are based on a misconception and are not applicable to the current Bitcoin protocol.In another email exchange, praxeology_guy argues that miners do not have authority as they compete for profit. Martin counters by stating that the process of acquiring block space does give miners power to decide over that particular space. Praxeology_guy admits that using miner signaling to determine whether SegWit should be activated was a mistake and proposes alternative methods involving more entities to activate SegWit in the future.The discussion also touches on the idea of transaction tiering, allowing users to choose where they transact. Currently, Bitcoin does not provide users with the ability to choose their place of business. The conversation explores the challenges and potential pitfalls of implementing this feature without compatibility issues or forks. The importance of clear and accurate terminology in Bitcoin is also highlighted.Overall, these discussions highlight the desire for users to have more choice in selecting miners or transaction processors. Various proposals and concepts are presented, but there are challenges that need to be addressed. The Bitcoin developer community is actively engaged in discussing these issues and exploring potential solutions. 2017-03-29T13:10:05+00:00 + In a recent email exchange on the bitcoin-dev mailing list, Martin Stolze questions the assumption that rational economic interest is the driving force behind all hash-power action in Bitcoin mining. He argues that even a small portion of hash power motivated by rational economic interest would validate the concept. Additionally, he refutes the claim that 100% of miners need to be honest, pointing out the distributed nature of the system. Tom Zander suggests taking the discussion to a different forum rather than spamming the dev list.The discussion centers around the concept of "miners as service providers" and providing additional choice to those who are affected by hash-power centralization. The idea is to have miners listen to the network instead of soliciting transactions directly from users, which can go against the peer-to-peer nature of the network. Two proposed methods for providing this service are creating segregated mempools managed by an authenticated third-party and directing mining fees to preferred miners. However, both methods have potential pitfalls that require attention.Bitcoin end-users want to support specific miners based on various factors such as political positions and physical location. Certain miners will naturally become preferred by users regardless of the involvement of the Bitcoin developer community. The recent language used by the ECB and drafts by the EU suggest a need for a way for commercial interest to transact in a regulated space. A proof-of-concept project called Preferred Miner, created by AJ West, aims to stimulate discussion on this issue.Tom Zander responds to a discussion about the authority of transaction processors (block generators) in Bitcoin. He argues that miners do not have authority to decide which transactions to mine or not; rather, they make economic decisions based on their incentives. The distribution of miners means that one miner cannot stop others from mining certain transactions. Concerns about transaction processors having arbitrary authority to discriminate participants are based on a misconception and are not applicable to the current Bitcoin protocol.In another email exchange, praxeology_guy argues that miners do not have authority as they compete for profit. Martin counters by stating that the process of acquiring block space does give miners power to decide over that particular space. Praxeology_guy admits that using miner signaling to determine whether SegWit should be activated was a mistake and proposes alternative methods involving more entities to activate SegWit in the future.The discussion also touches on the idea of transaction tiering, allowing users to choose where they transact. Currently, Bitcoin does not provide users with the ability to choose their place of business. The conversation explores the challenges and potential pitfalls of implementing this feature without compatibility issues or forks. The importance of clear and accurate terminology in Bitcoin is also highlighted.Overall, these discussions highlight the desire for users to have more choice in selecting miners or transaction processors. Various proposals and concepts are presented, but there are challenges that need to be addressed. The Bitcoin developer community is actively engaged in discussing these issues and exploring potential solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Issolated-Bitcoin-Nodes.xml b/static/bitcoin-dev/March_2017/combined_Issolated-Bitcoin-Nodes.xml index f1155c5a3b..1354ee7999 100644 --- a/static/bitcoin-dev/March_2017/combined_Issolated-Bitcoin-Nodes.xml +++ b/static/bitcoin-dev/March_2017/combined_Issolated-Bitcoin-Nodes.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Issolated Bitcoin Nodes - 2023-08-01T19:52:48.387435+00:00 - - Andrew Chow 2017-03-24 03:38:21+00:00 - - - Eric Voskuil 2017-03-24 01:58:37+00:00 - - - James Hilliard 2017-03-24 00:31:25+00:00 - - - Pieter Wuille 2017-03-24 00:20:32+00:00 - - - Andrew Chow 2017-03-23 23:14:28+00:00 - - - Matt Corallo 2017-03-23 23:01:09+00:00 - - - Juan Garavaglia 2017-03-23 22:37:34+00:00 - + 2025-09-26T15:37:00.901100+00:00 + python-feedgen + + + [bitcoin-dev] Issolated Bitcoin Nodes Juan Garavaglia + 2017-03-23T22:37:00.000Z + + + Matt Corallo + 2017-03-23T23:01:00.000Z + + + Andrew Chow + 2017-03-23T23:14:00.000Z + + + Pieter Wuille + 2017-03-24T00:20:00.000Z + + + James Hilliard + 2017-03-24T00:31:00.000Z + + + Eric Voskuil + 2017-03-24T01:58:00.000Z + + + Andrew Chow + 2017-03-24T03:38:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Issolated Bitcoin Nodes - 2023-08-01T19:52:48.387435+00:00 + 2025-09-26T15:37:00.901982+00:00 - On the Bitcoin development mailing list, there has been a discussion regarding backward compatibility issues between nodes running version 0.13.X+ and older versions. It was observed that when blocks are propagated from bitcoind 0.12.+ to newer nodes, they are not being propagated to peers with newer versions, while these newer blocks are being propagated to peers with older versions without any issues. This behavior is expected as nodes with SegWit active only download blocks from other SegWit peers, as old peers cannot provide the witness data required for verification.Bitcoin Testnet has faced chain splits and reorganizations due to the backward compatibility issue between nodes running version 0.12.x and those running 0.13.0 or higher. The latter requires Segregated Witness (SegWit) functionality and rejects blocks received from 0.12.x nodes with stripped witnesses. As Testnet has fewer nodes and less difficulty, some miners may use 0.13.0+ mining blocks which do not propagate well, leading to multiple chain splits and reorgs. This issue is currently unable to be exploited maliciously, but it can result in a 0.13+ node becoming isolated by 0.12 peers without notice to the owner. Alternative Bitcoin implementations may act as bridges between the two versions and facilitate chain reorgs.Investigations into the reorganizations in the Bitcoin testnet have revealed that the issue lies in nodes running version 0.12, which may have longer or different chains compared to newer versions like 0.13. There seems to be a problem in the communication between the different versions, where newer blocks are not being propagated to older nodes, while older blocks are being propagated without issues. This indicates a backward compatibility issue, which can be replicated by forcing a node to exclusively use peers running 0.12 or older versions. While there have been no reported malicious uses of this issue, node owners running 0.13 or higher should be aware of the potential for isolation by 0.12 peers.Reports of reorganizations in the Bitcoin testnet have been observed, with forks being created by multiple users mining different blocks on each chain. The issue appears to involve nodes running version 0.12, which may have longer or different chains than newer versions like 0.13. The problem lies in the communication between these versions, where newer blocks are not propagated to older nodes, while older blocks are propagated without issues. This backward compatibility issue can be replicated by exclusively using peers running 0.12 or older versions. While there have been no reported malicious uses of this issue, it is important for node owners running 0.13 or higher to be aware of the potential for isolation by 0.12 peers.There have been reorganizations in the Bitcoin testnet that are not related to network issues. Bitcoin explorers such as blocktrail.com or blockr.io were following different chains at different heights, indicating a backward compatibility issue between 0.13.X+ and older versions. This issue can be replicated by forcing the latest version of bitcoind to exclusively use peers of versions 0.12.X and older, resulting in the latest version node never receiving a new block. While it remains unclear if this issue can be exploited maliciously, Bitcoin 0.13.X+ should remain compatible with older versions, and there is no notice for the node owner. 2017-03-24T03:38:21+00:00 + On the Bitcoin development mailing list, there has been a discussion regarding backward compatibility issues between nodes running version 0.13.X+ and older versions. It was observed that when blocks are propagated from bitcoind 0.12.+ to newer nodes, they are not being propagated to peers with newer versions, while these newer blocks are being propagated to peers with older versions without any issues. This behavior is expected as nodes with SegWit active only download blocks from other SegWit peers, as old peers cannot provide the witness data required for verification.Bitcoin Testnet has faced chain splits and reorganizations due to the backward compatibility issue between nodes running version 0.12.x and those running 0.13.0 or higher. The latter requires Segregated Witness (SegWit) functionality and rejects blocks received from 0.12.x nodes with stripped witnesses. As Testnet has fewer nodes and less difficulty, some miners may use 0.13.0+ mining blocks which do not propagate well, leading to multiple chain splits and reorgs. This issue is currently unable to be exploited maliciously, but it can result in a 0.13+ node becoming isolated by 0.12 peers without notice to the owner. Alternative Bitcoin implementations may act as bridges between the two versions and facilitate chain reorgs.Investigations into the reorganizations in the Bitcoin testnet have revealed that the issue lies in nodes running version 0.12, which may have longer or different chains compared to newer versions like 0.13. There seems to be a problem in the communication between the different versions, where newer blocks are not being propagated to older nodes, while older blocks are being propagated without issues. This indicates a backward compatibility issue, which can be replicated by forcing a node to exclusively use peers running 0.12 or older versions. While there have been no reported malicious uses of this issue, node owners running 0.13 or higher should be aware of the potential for isolation by 0.12 peers.Reports of reorganizations in the Bitcoin testnet have been observed, with forks being created by multiple users mining different blocks on each chain. The issue appears to involve nodes running version 0.12, which may have longer or different chains than newer versions like 0.13. The problem lies in the communication between these versions, where newer blocks are not propagated to older nodes, while older blocks are propagated without issues. This backward compatibility issue can be replicated by exclusively using peers running 0.12 or older versions. While there have been no reported malicious uses of this issue, it is important for node owners running 0.13 or higher to be aware of the potential for isolation by 0.12 peers.There have been reorganizations in the Bitcoin testnet that are not related to network issues. Bitcoin explorers such as blocktrail.com or blockr.io were following different chains at different heights, indicating a backward compatibility issue between 0.13.X+ and older versions. This issue can be replicated by forcing the latest version of bitcoind to exclusively use peers of versions 0.12.X and older, resulting in the latest version node never receiving a new block. While it remains unclear if this issue can be exploited maliciously, Bitcoin 0.13.X+ should remain compatible with older versions, and there is no notice for the node owner. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Malice-Reactive-Proof-of-Work-Additions-MR-POWA-Protecting-Bitcoin-from-malicious-miners.xml b/static/bitcoin-dev/March_2017/combined_Malice-Reactive-Proof-of-Work-Additions-MR-POWA-Protecting-Bitcoin-from-malicious-miners.xml index 198c68f834..a6abb4ee3b 100644 --- a/static/bitcoin-dev/March_2017/combined_Malice-Reactive-Proof-of-Work-Additions-MR-POWA-Protecting-Bitcoin-from-malicious-miners.xml +++ b/static/bitcoin-dev/March_2017/combined_Malice-Reactive-Proof-of-Work-Additions-MR-POWA-Protecting-Bitcoin-from-malicious-miners.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners - 2023-08-01T19:47:38.144810+00:00 - - Natanael 2017-04-17 22:34:55+00:00 - - - Erik Aronesty 2017-04-17 11:17:17+00:00 - - - Erik Aronesty 2017-04-17 07:47:48+00:00 - - - bfd at cock.lu 2017-04-17 01:28:56+00:00 - - - Erik Aronesty 2017-04-16 20:04:56+00:00 - - - John Hardy 2017-03-20 21:29:29+00:00 - - - John Hardy 2017-03-20 21:23:17+00:00 - - - David Vorick 2017-03-20 18:51:51+00:00 - - - Nick ODell 2017-03-20 18:02:52+00:00 - - - Bram Cohen 2017-03-20 17:49:59+00:00 - - - Andrew Johnson 2017-03-20 16:10:32+00:00 - - - Marcos mayorga 2017-03-20 15:55:41+00:00 - - - John Hardy 2017-03-20 15:46:28+00:00 - - - Andrew Johnson 2017-03-20 15:38:01+00:00 - - - John Hardy 2017-03-18 16:01:08+00:00 - + 2025-09-26T15:36:44.046178+00:00 + python-feedgen + + + [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners John Hardy + 2017-03-18T16:01:00.000Z + + + Andrew Johnson + 2017-03-20T15:38:00.000Z + + + John Hardy + 2017-03-20T15:46:00.000Z + + + Marcos mayorga + 2017-03-20T15:55:00.000Z + + + Andrew Johnson + 2017-03-20T16:10:00.000Z + + + Bram Cohen + 2017-03-20T17:49:00.000Z + + + Nick ODell + 2017-03-20T18:02:00.000Z + + + David Vorick + 2017-03-20T18:51:00.000Z + + + John Hardy + 2017-03-20T21:23:00.000Z + + + John Hardy + 2017-03-20T21:29:00.000Z + + + Erik Aronesty + 2017-04-16T20:04:00.000Z + + + bfd + 2017-04-17T01:28:00.000Z + + + Erik Aronesty + 2017-04-17T07:47:00.000Z + + + Erik Aronesty + 2017-04-17T11:17:00.000Z + + + Natanael + 2017-04-17T22:34:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners - 2023-08-01T19:47:38.144810+00:00 + 2025-09-26T15:36:44.048014+00:00 - John Hardy proposes the implementation of Malicious Miner Reactive Proof of Work Additions (MR POWA) as a solution to the issue of miner centralization in Bitcoin. This proposal suggests introducing multiple new proofs of work (PoW) that have been proven in altcoin implementations, such as Scrypt, Ethash, and Equihash. The goal is to diversify hardware and reduce the impact of subsidized or inexpensive electricity in certain regions.MR POWA would be activated as a hard fork in response to a malicious attempt by a hashpower majority to introduce a contentious hard fork. Instead of completely eliminating SHA256 as a hashing method and changing the PoW algorithm, Hardy recommends adding new PoWs to diversify hardware. This approach would improve decentralization.Under MR POWA, there would be four proofs of work with a 40-minute block target difficulty for each. Additionally, a rule could be implemented where two different proofs of work must find a block before a method can start hashing again. This ensures that only 50% of hardware is hashing at any given time, preventing a sudden gain or drop in hashpower from significantly impacting the network.Hardy believes that MR POWA would serve as a deterrent to malicious actors attempting to abuse their position and create a huge risk for them. If consensus were to form around a future hard fork, nodes would be able to upgrade, and MR POWA would have no economic significance on non-upgraded nodes, resulting in an immediately abandoned vestigial chain with no miner incentive.Overall, Hardy sees MR POWA as a proactive measure to prevent malicious use of hashpower and emphasizes that Bitcoin's strength lies in the ability of the economic majority to find solutions to emerging challenges. 2017-04-17T22:34:55+00:00 + John Hardy proposes the implementation of Malicious Miner Reactive Proof of Work Additions (MR POWA) as a solution to the issue of miner centralization in Bitcoin. This proposal suggests introducing multiple new proofs of work (PoW) that have been proven in altcoin implementations, such as Scrypt, Ethash, and Equihash. The goal is to diversify hardware and reduce the impact of subsidized or inexpensive electricity in certain regions.MR POWA would be activated as a hard fork in response to a malicious attempt by a hashpower majority to introduce a contentious hard fork. Instead of completely eliminating SHA256 as a hashing method and changing the PoW algorithm, Hardy recommends adding new PoWs to diversify hardware. This approach would improve decentralization.Under MR POWA, there would be four proofs of work with a 40-minute block target difficulty for each. Additionally, a rule could be implemented where two different proofs of work must find a block before a method can start hashing again. This ensures that only 50% of hardware is hashing at any given time, preventing a sudden gain or drop in hashpower from significantly impacting the network.Hardy believes that MR POWA would serve as a deterrent to malicious actors attempting to abuse their position and create a huge risk for them. If consensus were to form around a future hard fork, nodes would be able to upgrade, and MR POWA would have no economic significance on non-upgraded nodes, resulting in an immediately abandoned vestigial chain with no miner incentive.Overall, Hardy sees MR POWA as a proactive measure to prevent malicious use of hashpower and emphasizes that Bitcoin's strength lies in the ability of the economic majority to find solutions to emerging challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Moving-towards-user-activated-soft-fork-activation.xml b/static/bitcoin-dev/March_2017/combined_Moving-towards-user-activated-soft-fork-activation.xml index 4863ffda6d..713ad229b2 100644 --- a/static/bitcoin-dev/March_2017/combined_Moving-towards-user-activated-soft-fork-activation.xml +++ b/static/bitcoin-dev/March_2017/combined_Moving-towards-user-activated-soft-fork-activation.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Moving towards user activated soft fork activation - 2023-08-01T19:40:15.088441+00:00 - - shaolinfry 2017-03-12 15:47:28+00:00 - - - Alphonse Pace 2017-03-07 19:13:29+00:00 - - - Eric Voskuil 2017-03-07 18:13:36+00:00 - - - Eric Voskuil 2017-03-07 17:37:15+00:00 - - - Tom Zander 2017-03-07 09:17:18+00:00 - - - Edmund Edgar 2017-03-07 01:07:05+00:00 - - - Gareth Williams 2017-03-06 23:23:47+00:00 - - - Edmund Edgar 2017-03-06 10:29:35+00:00 - - - David Vorick 2017-03-06 09:18:38+00:00 - - - Nick ODell 2017-03-05 21:31:26+00:00 - - - Eric Voskuil 2017-03-05 18:48:33+00:00 - - - David Vorick 2017-03-05 18:10:15+00:00 - - - Chris Belcher 2017-03-05 14:33:06+00:00 - - - Luke Dashjr 2017-02-28 21:20:29+00:00 - - - Eric Voskuil 2017-02-27 16:50:07+00:00 - - - shaolinfry 2017-02-27 16:02:52+00:00 - - - Jameson Lopp 2017-02-26 17:34:57+00:00 - - - shaolinfry 2017-02-25 23:55:51+00:00 - + 2025-09-26T15:36:33.536750+00:00 + python-feedgen + + + [bitcoin-dev] Moving towards user activated soft fork activation shaolinfry + 2017-02-25T23:55:00.000Z + + + Jameson Lopp + 2017-02-26T17:34:00.000Z + + + shaolinfry + 2017-02-27T16:02:00.000Z + + + Eric Voskuil + 2017-02-27T16:50:00.000Z + + + Luke Dashjr + 2017-02-28T21:20:00.000Z + + + Chris Belcher + 2017-03-05T14:33:00.000Z + + + David Vorick + 2017-03-05T18:10:00.000Z + + + Eric Voskuil + 2017-03-05T18:48:00.000Z + + + Nick ODell + 2017-03-05T21:31:00.000Z + + + David Vorick + 2017-03-06T09:18:00.000Z + + + Edmund Edgar + 2017-03-06T10:29:00.000Z + + + Gareth Williams + 2017-03-06T23:23:00.000Z + + + Edmund Edgar + 2017-03-07T01:07:00.000Z + + + Tom Zander + 2017-03-07T09:17:00.000Z + + + Eric Voskuil + 2017-03-07T17:37:00.000Z + + + Eric Voskuil + 2017-03-07T18:13:00.000Z + + + Alphonse Pace + 2017-03-07T19:13:00.000Z + + + shaolinfry + 2017-03-12T15:47:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Moving towards user activated soft fork activation - 2023-08-01T19:40:15.088441+00:00 + 2025-09-26T15:36:33.538757+00:00 - The author of BIP9 has proposed an extension to the existing protocol that introduces an additional activation parameter for soft forks. The new parameter, called "activationtime," specifies a minimum median time past of a block at which the deployment should transition to the locked-in state. This allows full nodes to coordinate synchronized activation based on a median past time using the BIP9 state machine.The state transition workflow for this proposal is the same as in BIP9, except when the activation time is greater than zero. In such cases, the workflow will be DEFINED -> STARTED -> PRE_LOCK_IN -> LOCKED_IN -> ACTIVE. The guidelines suggest setting the activation time to some date in the future, which must be less than the BIP9 timeout.A living list of deployment proposals can be found on GitHub, and an optional mandatory signaling function is included in the reference implementation. The discussion on the Bitcoin-dev mailing list revolves around the possibility of a hash-minority attacking a hash-majority in Bitcoin. Some argue that it is impossible for non-mining users to attack miners, while others believe it is possible by refusing to buy their coinbase transaction.The majority of hash rate can choose to continue with old rules or not, and users are free to follow tighter rules than before or reject them. The disagreement can be resolved peacefully through unilateral separation. However, if the majority of users are hostile and reject blocks that miners create, then what the miners bring to the table is also removed. Bitcoin works when the majority of the hashpower and the (economic) majority of users are balanced in power and have their goals aligned. A hash-minority attacking the hash-majority is an attack upon Bitcoin as a whole and opens up the possibility of governments trying to push through changes in the same way.In another discussion on the Bitcoin-dev mailing list, participants debated whether a "hashpower activated soft fork to censor transactions" could be seen as censorship. One member argued that Bitcoin's defense against censorship and disruption is due to the broad distribution of over 50% of hash power among a large number of people. The conversation then turned to the idea that miners have no technical or ethical obligation to follow any particular set of rules. Instead, security is based on decentralization, not well-behaved people or software. They also noted that if every person on the planet was a miner, it would be much harder to achieve consensus on any proposed material change. Regardless, the nature of sound money is that it doesn't change.In another email thread, concerns were raised over hashpower activated soft forks to censor transactions in response to user-activated soft forks (UASF) that the majority of hashpower disagrees with. However, it was clarified that the suggestion was not to censor transactions but to change the form they take. It was argued that a set of users forcing miners to do something is silly, and a minority miner fraction forcing the majority to do something is equally silly. Responding to such attacks with a proof-of-work hard fork that would result in two chains, allowing the market to decide which one "wins," was suggested. It was emphasized that Bitcoin only works when the majority of hashpower and the economic majority of users are balanced in power and have their goals aligned.In an email exchange, participants discussed whether a "hashpower activated soft fork to censor transactions" could be seen as censorship. It was argued that Bitcoin's defense against censorship and disruption is due to the broad distribution of over 50% of hash power among a large number of people. The conversation then turned to the idea that miners have no technical or ethical obligation to follow any particular set of rules. Instead, security is based on decentralization, not well-behaved people or software. It was noted that if every person on the planet was a miner, it would be much harder to achieve consensus on any proposed material change. The nature of sound money is that it doesn't change.The concept of User Activated Soft Fork (UASF) in Bitcoin is seen as a positive development that aligns with the balance of powers in the cryptocurrency. Unlike hard forks, UASF provides an opt-in feature that appeals to users interested in participating in the fork. In a UASF, the segwit-valid chain will be favored over the segwit-invalid chain if it has more work, leading to the annihilation of the latter. Only miners who recode their software can initiate such a fork.The accidental fork created after BIP66 was short-lived and lasted only a few blocks. Segwit-invalid coins are considered riskier assets and have a lower price than segwit-valid coins. Investors demand higher risk premiums for holding them, and short sellers may sell down the price if the value goes to zero. Hashpower follows price in cryptocurrencies like Bitcoin, so the segwit-invalid chain will eventually be overtaken by a higher-hashrate chain. UASF should only proceed if a significant portion of the economic majority ensures 2017-03-12T15:47:28+00:00 + The author of BIP9 has proposed an extension to the existing protocol that introduces an additional activation parameter for soft forks. The new parameter, called "activationtime," specifies a minimum median time past of a block at which the deployment should transition to the locked-in state. This allows full nodes to coordinate synchronized activation based on a median past time using the BIP9 state machine.The state transition workflow for this proposal is the same as in BIP9, except when the activation time is greater than zero. In such cases, the workflow will be DEFINED -> STARTED -> PRE_LOCK_IN -> LOCKED_IN -> ACTIVE. The guidelines suggest setting the activation time to some date in the future, which must be less than the BIP9 timeout.A living list of deployment proposals can be found on GitHub, and an optional mandatory signaling function is included in the reference implementation. The discussion on the Bitcoin-dev mailing list revolves around the possibility of a hash-minority attacking a hash-majority in Bitcoin. Some argue that it is impossible for non-mining users to attack miners, while others believe it is possible by refusing to buy their coinbase transaction.The majority of hash rate can choose to continue with old rules or not, and users are free to follow tighter rules than before or reject them. The disagreement can be resolved peacefully through unilateral separation. However, if the majority of users are hostile and reject blocks that miners create, then what the miners bring to the table is also removed. Bitcoin works when the majority of the hashpower and the (economic) majority of users are balanced in power and have their goals aligned. A hash-minority attacking the hash-majority is an attack upon Bitcoin as a whole and opens up the possibility of governments trying to push through changes in the same way.In another discussion on the Bitcoin-dev mailing list, participants debated whether a "hashpower activated soft fork to censor transactions" could be seen as censorship. One member argued that Bitcoin's defense against censorship and disruption is due to the broad distribution of over 50% of hash power among a large number of people. The conversation then turned to the idea that miners have no technical or ethical obligation to follow any particular set of rules. Instead, security is based on decentralization, not well-behaved people or software. They also noted that if every person on the planet was a miner, it would be much harder to achieve consensus on any proposed material change. Regardless, the nature of sound money is that it doesn't change.In another email thread, concerns were raised over hashpower activated soft forks to censor transactions in response to user-activated soft forks (UASF) that the majority of hashpower disagrees with. However, it was clarified that the suggestion was not to censor transactions but to change the form they take. It was argued that a set of users forcing miners to do something is silly, and a minority miner fraction forcing the majority to do something is equally silly. Responding to such attacks with a proof-of-work hard fork that would result in two chains, allowing the market to decide which one "wins," was suggested. It was emphasized that Bitcoin only works when the majority of hashpower and the economic majority of users are balanced in power and have their goals aligned.In an email exchange, participants discussed whether a "hashpower activated soft fork to censor transactions" could be seen as censorship. It was argued that Bitcoin's defense against censorship and disruption is due to the broad distribution of over 50% of hash power among a large number of people. The conversation then turned to the idea that miners have no technical or ethical obligation to follow any particular set of rules. Instead, security is based on decentralization, not well-behaved people or software. It was noted that if every person on the planet was a miner, it would be much harder to achieve consensus on any proposed material change. The nature of sound money is that it doesn't change.The concept of User Activated Soft Fork (UASF) in Bitcoin is seen as a positive development that aligns with the balance of powers in the cryptocurrency. Unlike hard forks, UASF provides an opt-in feature that appeals to users interested in participating in the fork. In a UASF, the segwit-valid chain will be favored over the segwit-invalid chain if it has more work, leading to the annihilation of the latter. Only miners who recode their software can initiate such a fork.The accidental fork created after BIP66 was short-lived and lasted only a few blocks. Segwit-invalid coins are considered riskier assets and have a lower price than segwit-valid coins. Investors demand higher risk premiums for holding them, and short sellers may sell down the price if the value goes to zero. Hashpower follows price in cryptocurrencies like Bitcoin, so the segwit-invalid chain will eventually be overtaken by a higher-hashrate chain. UASF should only proceed if a significant portion of the economic majority ensures - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Quadratic-hashing-solution-for-a-post-segwit-hard-fork.xml b/static/bitcoin-dev/March_2017/combined_Quadratic-hashing-solution-for-a-post-segwit-hard-fork.xml index 2c4b28dd12..8134af3072 100644 --- a/static/bitcoin-dev/March_2017/combined_Quadratic-hashing-solution-for-a-post-segwit-hard-fork.xml +++ b/static/bitcoin-dev/March_2017/combined_Quadratic-hashing-solution-for-a-post-segwit-hard-fork.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Quadratic hashing solution for a post-segwit hard fork - 2023-08-01T19:46:19.799524+00:00 - - Jorge Timón 2017-03-17 10:39:07+00:00 - - - Erik Aronesty 2017-03-17 00:44:27+00:00 - - - Alphonse Pace 2017-03-16 15:24:14+00:00 - - - Erik Aronesty 2017-03-14 23:26:17+00:00 - + 2025-09-26T15:36:41.935601+00:00 + python-feedgen + + + [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork Erik Aronesty + 2017-03-14T23:26:00.000Z + + + Alphonse Pace + 2017-03-16T15:24:00.000Z + + + Erik Aronesty + 2017-03-17T00:44:00.000Z + + + Jorge Timón + 2017-03-17T10:39:00.000Z + + - python-feedgen + 2 Combined summary - Quadratic hashing solution for a post-segwit hard fork - 2023-08-01T19:46:19.799524+00:00 + 2025-09-26T15:36:41.936347+00:00 - In an email thread dated March 17, 2017, Erik Aronesty discusses the challenges and potential solutions related to implementing protocol improvements and larger block sizes in a blockchain system. The speaker suggests that these changes can be handled through a soft fork, allowing the system to be updated without forcing all users to adopt the new rules immediately. It is also proposed that migration to a new system can be achieved by restricting transactions between old and new versions.The speaker emphasizes the importance of carefully considering the technical implications and potential challenges associated with updating a blockchain system. By taking a thoughtful and strategic approach, it may be possible to successfully implement important improvements and advancements while minimizing disruption to the existing user base.However, the proposal to optimize transaction selection by introducing a second dimension has been criticized for unnecessarily complicating the process for miners. The use of block weight in Segwit already solves this issue, making the proposed solution redundant and potentially problematic. The complications that could arise from introducing additional dimensions are highlighted through the example of the Bin Packing Problem. It is argued that the proposed solution would not make any significant improvements and should be reconsidered.After further discussion, a proposal for a post-segwit hard fork is put forward. This proposal involves partitioning the block into three segments: a 1MB old transaction non-witness segment, a new XMB segwit non-witness segment, and a new XMB witness segment. This approach allows users of older, more expensive validation transactions to continue using them, but with higher fees required for the restricted space. Additionally, new segwit blocks that don't have hashing problems can be included in the new non-witness segment of the block. The main objective of this proposal is to address block size limits, increase efficiency, and maintain the security of the blockchain. 2017-03-17T10:39:07+00:00 + In an email thread dated March 17, 2017, Erik Aronesty discusses the challenges and potential solutions related to implementing protocol improvements and larger block sizes in a blockchain system. The speaker suggests that these changes can be handled through a soft fork, allowing the system to be updated without forcing all users to adopt the new rules immediately. It is also proposed that migration to a new system can be achieved by restricting transactions between old and new versions.The speaker emphasizes the importance of carefully considering the technical implications and potential challenges associated with updating a blockchain system. By taking a thoughtful and strategic approach, it may be possible to successfully implement important improvements and advancements while minimizing disruption to the existing user base.However, the proposal to optimize transaction selection by introducing a second dimension has been criticized for unnecessarily complicating the process for miners. The use of block weight in Segwit already solves this issue, making the proposed solution redundant and potentially problematic. The complications that could arise from introducing additional dimensions are highlighted through the example of the Bin Packing Problem. It is argued that the proposed solution would not make any significant improvements and should be reconsidered.After further discussion, a proposal for a post-segwit hard fork is put forward. This proposal involves partitioning the block into three segments: a 1MB old transaction non-witness segment, a new XMB segwit non-witness segment, and a new XMB witness segment. This approach allows users of older, more expensive validation transactions to continue using them, but with higher fees required for the restricted space. Additionally, new segwit blocks that don't have hashing problems can be included in the new non-witness segment of the block. The main objective of this proposal is to address block size limits, increase efficiency, and maintain the security of the blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Refund-Excesss-Fee-Hard-Fork-Proposal.xml b/static/bitcoin-dev/March_2017/combined_Refund-Excesss-Fee-Hard-Fork-Proposal.xml index 12542ce6de..c5d22ee56a 100644 --- a/static/bitcoin-dev/March_2017/combined_Refund-Excesss-Fee-Hard-Fork-Proposal.xml +++ b/static/bitcoin-dev/March_2017/combined_Refund-Excesss-Fee-Hard-Fork-Proposal.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Refund Excesss Fee Hard Fork Proposal - 2023-08-01T20:06:38.037279+00:00 - - praxeology_guy 2017-03-31 21:17:16+00:00 - - - Bram Cohen 2017-03-31 20:57:04+00:00 - - - praxeology_guy 2017-03-31 20:29:41+00:00 - + 2025-09-26T15:37:02.989911+00:00 + python-feedgen + + + [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal praxeology_guy + 2017-03-31T20:29:00.000Z + + + Bram Cohen + 2017-03-31T20:57:00.000Z + + + praxeology_guy + 2017-03-31T21:17:00.000Z + + - python-feedgen + 2 Combined summary - Refund Excesss Fee Hard Fork Proposal - 2023-08-01T20:06:38.037279+00:00 + 2025-09-26T15:37:02.990508+00:00 - The distribution of fees in bitcoin transactions is a key aspect to consider. Most of the income is generated from transactions with fees near the "Lowest Invested First Basis" (LIFB). However, there is concern that miners may choose not to fill blocks completely if low fee marginal transactions end up costing them money. This could have negative implications for Child Pays For Parent (CPFP), where a parent fee is not considered as LIFB.A proposal was made on the bitcoin-dev mailing list by user praxeology_guy to change the fee policy for bitcoin transactions. The suggestion is to reduce all fee/byte in a block to the lowest included fee/byte and allow transactions to specify which outputs receive what portions of the transaction fee. However, this approach may incentivize miners to not fill blocks completely if low fee marginal transactions become unprofitable for them. An alternative approach proposed is to incentivize miners to prioritize transaction fees more by reducing mining rewards. This could be achieved through a soft fork that requires a portion of all mining rewards to be sent to an unspendable address.The proposed hard fork change involves refunding excess fee amounts higher than the lowest included fee in a block. This change would result in all fee/byte in a block being reduced to the lowest included fee/byte. Transactions would then specify how and which outputs receive portions of [(TX_fee/TX_length - LIFB)*TX_length]. This change is desirable because it addresses the issue of miners prioritizing transactions with the highest fee/byte, leaving users who prefer lower fees at a disadvantage. Some users require quick confirmation times and are willing to pay higher fees, but still prefer to pay the LIFB fee/byte amount. Lower fees are important for transfer efficiency and make a money system more competitive.However, it is important to note that this proposed hard fork change is significant and may come with performance problems. Hard forks are generally challenging to implement, and if fees are already very small and there is minimal difference between a high priority fee/byte and the LIFB, the issue may not be significant. Despite these challenges, the proposal has been put forward, although it remains uncertain whether such a hard fork will ultimately be deemed worthwhile. 2017-03-31T21:17:16+00:00 + The distribution of fees in bitcoin transactions is a key aspect to consider. Most of the income is generated from transactions with fees near the "Lowest Invested First Basis" (LIFB). However, there is concern that miners may choose not to fill blocks completely if low fee marginal transactions end up costing them money. This could have negative implications for Child Pays For Parent (CPFP), where a parent fee is not considered as LIFB.A proposal was made on the bitcoin-dev mailing list by user praxeology_guy to change the fee policy for bitcoin transactions. The suggestion is to reduce all fee/byte in a block to the lowest included fee/byte and allow transactions to specify which outputs receive what portions of the transaction fee. However, this approach may incentivize miners to not fill blocks completely if low fee marginal transactions become unprofitable for them. An alternative approach proposed is to incentivize miners to prioritize transaction fees more by reducing mining rewards. This could be achieved through a soft fork that requires a portion of all mining rewards to be sent to an unspendable address.The proposed hard fork change involves refunding excess fee amounts higher than the lowest included fee in a block. This change would result in all fee/byte in a block being reduced to the lowest included fee/byte. Transactions would then specify how and which outputs receive portions of [(TX_fee/TX_length - LIFB)*TX_length]. This change is desirable because it addresses the issue of miners prioritizing transactions with the highest fee/byte, leaving users who prefer lower fees at a disadvantage. Some users require quick confirmation times and are willing to pay higher fees, but still prefer to pay the LIFB fee/byte amount. Lower fees are important for transfer efficiency and make a money system more competitive.However, it is important to note that this proposed hard fork change is significant and may come with performance problems. Hard forks are generally challenging to implement, and if fees are already very small and there is minimal difference between a high priority fee/byte and the LIFB, the issue may not be significant. Despite these challenges, the proposal has been put forward, although it remains uncertain whether such a hard fork will ultimately be deemed worthwhile. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Requirement-for-pseudonymous-BIP-submissions.xml b/static/bitcoin-dev/March_2017/combined_Requirement-for-pseudonymous-BIP-submissions.xml index 17e8288e84..19a361d2c5 100644 --- a/static/bitcoin-dev/March_2017/combined_Requirement-for-pseudonymous-BIP-submissions.xml +++ b/static/bitcoin-dev/March_2017/combined_Requirement-for-pseudonymous-BIP-submissions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Requirement for pseudonymous BIP submissions - 2023-08-01T19:46:46.519305+00:00 + 2025-09-26T15:36:56.703960+00:00 + python-feedgen Tom Zander 2017-03-29 08:49:38+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Requirement for pseudonymous BIP submissions - 2023-08-01T19:46:46.519305+00:00 + 2025-09-26T15:36:56.704137+00:00 - The ongoing Bitcoin scaling debate has become politicized, with one side advocating for increasing block size via segwit and the other through a hard fork. Companies are hesitant to take sides due to potential backlash. Pseudonymous submissions are suggested to be carried by a well-known member of the Bitcoin community to ensure credibility. Bips are seen politically based on their usefulness to each side rather than who suggests them. Protocol changes cannot be made until after a protocol upgrade has been implemented.In an email thread, Chris Stewart proposed a method that would allow individuals to reveal themselves after the BIP has been accepted. While this process cannot be forced upon people, it may become a de facto requirement by the BIP maintainer. The conversation then turns to making decisions based on merit versus financial gain. The author suggests that decisions within the project are based on return on investment (ROI), rather than merit. In fact, if killing the project or running all competing miners out of business is more profitable, many actors involved are obligated to attempt to do so. The author suggests that if merit were important, there should be a way to finance development that provides real financial incentives for merit. Additionally, the author believes that demurrage and increasing the money supply have more merit, but they are not profitable to existing Bitcoin investors, thus making them less discussed.The conversation on the Bitcoin-dev mailing list started with a discussion about the inconvenience of creating new email and GitHub accounts to submit BIPs. It was pointed out that GitHub doesn't allow multiple accounts. This led to a suggestion from Luke Dashjr for a decentralized version control system that would let users propose BIPs anonymously and get paid in crypto for the best commits. The proposed system would be developed using Mercurial, BitTorrent, and pynode by motivated grad students who know Python. A crowdfunding effort was suggested to support the development of this system.Anonymity is emphasized in the cryptocurrency community, with concerns raised about being a "recognizable target" discouraging contributions. BitFury's CEO is criticized for threatening to sue developers, with the argument that decisions should be made on merit alone. Privacy concerns are also discussed, with suggestions for creating a safe space for merit and recommendations for http://gplspace.org/.The author of the email to bitcoin-dev-request highlights the fact that GitHub does not allow multiple accounts per email address. This means that a user cannot have more than one account linked to the same email address on GitHub.To avoid the politicization of protocol-level changes and promote technical progress, Chris Stewart proposes a pseudonymous BIP system. Authors would be required to submit their proposals under a pseudonym, allowing the focus to be solely on the proposal's technical merits rather than who submitted it. The goal is to level the playing field and prevent trolls from discussing protocol changes. If desired, authors can reveal the preimage of the author hash to prove their identity after the acceptance of their BIP.Overall, the context highlights the importance of anonymity in the cryptocurrency community, the need for decisions based on merit rather than personal agendas, and proposals for improving the submission process for Bitcoin Improvement Proposals (BIPs) while maintaining privacy. 2017-03-29T08:49:38+00:00 + The ongoing Bitcoin scaling debate has become politicized, with one side advocating for increasing block size via segwit and the other through a hard fork. Companies are hesitant to take sides due to potential backlash. Pseudonymous submissions are suggested to be carried by a well-known member of the Bitcoin community to ensure credibility. Bips are seen politically based on their usefulness to each side rather than who suggests them. Protocol changes cannot be made until after a protocol upgrade has been implemented.In an email thread, Chris Stewart proposed a method that would allow individuals to reveal themselves after the BIP has been accepted. While this process cannot be forced upon people, it may become a de facto requirement by the BIP maintainer. The conversation then turns to making decisions based on merit versus financial gain. The author suggests that decisions within the project are based on return on investment (ROI), rather than merit. In fact, if killing the project or running all competing miners out of business is more profitable, many actors involved are obligated to attempt to do so. The author suggests that if merit were important, there should be a way to finance development that provides real financial incentives for merit. Additionally, the author believes that demurrage and increasing the money supply have more merit, but they are not profitable to existing Bitcoin investors, thus making them less discussed.The conversation on the Bitcoin-dev mailing list started with a discussion about the inconvenience of creating new email and GitHub accounts to submit BIPs. It was pointed out that GitHub doesn't allow multiple accounts. This led to a suggestion from Luke Dashjr for a decentralized version control system that would let users propose BIPs anonymously and get paid in crypto for the best commits. The proposed system would be developed using Mercurial, BitTorrent, and pynode by motivated grad students who know Python. A crowdfunding effort was suggested to support the development of this system.Anonymity is emphasized in the cryptocurrency community, with concerns raised about being a "recognizable target" discouraging contributions. BitFury's CEO is criticized for threatening to sue developers, with the argument that decisions should be made on merit alone. Privacy concerns are also discussed, with suggestions for creating a safe space for merit and recommendations for http://gplspace.org/.The author of the email to bitcoin-dev-request highlights the fact that GitHub does not allow multiple accounts per email address. This means that a user cannot have more than one account linked to the same email address on GitHub.To avoid the politicization of protocol-level changes and promote technical progress, Chris Stewart proposes a pseudonymous BIP system. Authors would be required to submit their proposals under a pseudonym, allowing the focus to be solely on the proposal's technical merits rather than who submitted it. The goal is to level the playing field and prevent trolls from discussing protocol changes. If desired, authors can reveal the preimage of the author hash to prove their identity after the acceptance of their BIP.Overall, the context highlights the importance of anonymity in the cryptocurrency community, the need for decisions based on merit rather than personal agendas, and proposals for improving the submission process for Bitcoin Improvement Proposals (BIPs) while maintaining privacy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Segregated-witness-p2p-layer-compatibility.xml b/static/bitcoin-dev/March_2017/combined_Segregated-witness-p2p-layer-compatibility.xml index 77f111eed5..8a81dc74db 100644 --- a/static/bitcoin-dev/March_2017/combined_Segregated-witness-p2p-layer-compatibility.xml +++ b/static/bitcoin-dev/March_2017/combined_Segregated-witness-p2p-layer-compatibility.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Segregated witness p2p layer compatibility - 2023-08-01T19:56:34.409277+00:00 - - Eric Voskuil 2017-03-27 21:03:08+00:00 - - - Matt Corallo 2017-03-27 19:32:30+00:00 - - - Suhas Daftuar 2017-03-27 19:22:43+00:00 - + 2025-09-26T15:36:27.233818+00:00 + python-feedgen + + + [bitcoin-dev] Segregated witness p2p layer compatibility Suhas Daftuar + 2017-03-27T19:22:00.000Z + + + Matt Corallo + 2017-03-27T19:32:00.000Z + + + Eric Voskuil + 2017-03-27T21:03:00.000Z + + - python-feedgen + 2 Combined summary - Segregated witness p2p layer compatibility - 2023-08-01T19:56:34.409277+00:00 + 2025-09-26T15:36:27.234333+00:00 - A recent discussion on the Bitcoin-dev mailing list focused on the implementation of SegWit and its implications for miners and nodes. Eric Voskuil raised concerns that pre-SegWit miners would produce blocks that SegWit nodes would not receive due to the protocol requirements. However, Suhas Daftuar clarified that this is an "implementation detail" in the Bitcoin Core code and alternate implementations compliant with BIP 144 could handle it differently.At the consensus layer, non-SegWit blocks that are valid to older nodes are also valid to SegWit nodes. This means that if a miner is using an older version of Bitcoin Core before SegWit activates, the blocks they find will be valid to all nodes. Bitcoin Core has been designed to not see valid blocks announced by certain peers, and forcing it to do so requires the peer-to-peer network to work around its current implementation.The behavior of block download logic after SegWit activation was further discussed to address misconceptions. According to Suhas Daftuar, nodes will not download any blocks from non-SegWit peers after activation to prevent downloading invalid blocks. However, non-SegWit blocks are evaluated under the same rules as pre-SegWit software versions and remain valid to all types of nodes. The decision to not download blocks from non-witness peers is an implementation detail in the Bitcoin Core code, not a requirement.Responding to Eric Voskuil's comment, Suhas explained that miners who want to continue mining after SegWit activation using pre-SegWit software would need a way to relay their blocks to a SegWit-enabled peer. Several methods were suggested, including using the RPC call "submitblock" on a SegWit-enabled node, explicitly delivering the block to a SegWit node over the P2P network, running a bridge node, or peer directly with other miners. It is expected that non-SegWit miners' blocks will still be relayed post-SegWit activation through the bridge nodes currently running.In conclusion, the discussion clarified the behavior of the Bitcoin Core's Segregated Witness code and its impact on block download logic. While there are implementation details to consider, non-SegWit blocks remain valid to SegWit nodes, and there are various ways for miners using pre-SegWit software to relay their blocks to SegWit-enabled peers. 2017-03-27T21:03:08+00:00 + A recent discussion on the Bitcoin-dev mailing list focused on the implementation of SegWit and its implications for miners and nodes. Eric Voskuil raised concerns that pre-SegWit miners would produce blocks that SegWit nodes would not receive due to the protocol requirements. However, Suhas Daftuar clarified that this is an "implementation detail" in the Bitcoin Core code and alternate implementations compliant with BIP 144 could handle it differently.At the consensus layer, non-SegWit blocks that are valid to older nodes are also valid to SegWit nodes. This means that if a miner is using an older version of Bitcoin Core before SegWit activates, the blocks they find will be valid to all nodes. Bitcoin Core has been designed to not see valid blocks announced by certain peers, and forcing it to do so requires the peer-to-peer network to work around its current implementation.The behavior of block download logic after SegWit activation was further discussed to address misconceptions. According to Suhas Daftuar, nodes will not download any blocks from non-SegWit peers after activation to prevent downloading invalid blocks. However, non-SegWit blocks are evaluated under the same rules as pre-SegWit software versions and remain valid to all types of nodes. The decision to not download blocks from non-witness peers is an implementation detail in the Bitcoin Core code, not a requirement.Responding to Eric Voskuil's comment, Suhas explained that miners who want to continue mining after SegWit activation using pre-SegWit software would need a way to relay their blocks to a SegWit-enabled peer. Several methods were suggested, including using the RPC call "submitblock" on a SegWit-enabled node, explicitly delivering the block to a SegWit node over the P2P network, running a bridge node, or peer directly with other miners. It is expected that non-SegWit miners' blocks will still be relayed post-SegWit activation through the bridge nodes currently running.In conclusion, the discussion clarified the behavior of the Bitcoin Core's Segregated Witness code and its impact on block download logic. While there are implementation details to consider, non-SegWit blocks remain valid to SegWit nodes, and there are various ways for miners using pre-SegWit software to relay their blocks to SegWit-enabled peers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml b/static/bitcoin-dev/March_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml index b5cdd69fe8..e62e4aec0e 100644 --- a/static/bitcoin-dev/March_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml +++ b/static/bitcoin-dev/March_2017/combined_Segwit2Mb-combined-soft-hard-fork-Request-For-Comments.xml @@ -1,92 +1,131 @@ - + 2 Combined summary - Segwit2Mb - combined soft/hard fork - Request For Comments - 2023-08-01T20:08:23.855216+00:00 - - Oliver Petruzel 2017-06-03 21:05:23+00:00 - - - Oliver Petruzel 2017-06-03 02:03:47+00:00 - - - Erik Aronesty 2017-06-03 00:53:55+00:00 - - - Sergio Demian Lerner 2017-06-02 21:51:45+00:00 - - - Erik Aronesty 2017-06-02 20:04:25+00:00 - - - Erik Aronesty 2017-06-02 20:04:16+00:00 - - - R E Broadley 2017-06-02 12:29:19+00:00 - - - Aymeric Vitte 2017-04-06 22:29:51+00:00 - - - Sergio Demian Lerner 2017-04-06 21:03:12+00:00 - - - Sergio Demian Lerner 2017-04-06 20:58:56+00:00 - - - Sergio Demian Lerner 2017-04-06 20:42:19+00:00 - - - Erik Aronesty 2017-04-06 02:27:34+00:00 - - - Btc Drak 2017-04-03 14:40:04+00:00 - - - Jorge Timón 2017-04-02 11:43:54+00:00 - - - Natanael 2017-04-02 10:03:31+00:00 - - - Jorge Timón 2017-04-02 04:57:48+00:00 - - - Natanael 2017-04-01 15:34:24+00:00 - - - Jorge Timón 2017-04-01 14:07:32+00:00 - - - Natanael 2017-04-01 13:15:15+00:00 - - - Jorge Timón 2017-04-01 12:33:18+00:00 - - - Sergio Demian Lerner 2017-04-01 11:44:11+00:00 - - - Jared Lee Richardson 2017-04-01 06:55:42+00:00 - - - Sergio Demian Lerner 2017-04-01 03:35:11+00:00 - - - Samson Mow 2017-04-01 03:03:03+00:00 - - - Sergio Demian Lerner 2017-03-31 22:13:35+00:00 - - - Sergio Demian Lerner 2017-03-31 21:50:05+00:00 - - - praxeology_guy 2017-03-31 21:22:02+00:00 - - - Sergio Demian Lerner 2017-03-31 21:09:18+00:00 - + 2025-09-26T15:36:18.837994+00:00 + python-feedgen + + + [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments Sergio Demian Lerner + 2017-03-31T21:09:00.000Z + + + Matt Corallo + 2017-03-31T21:18:00.000Z + + + praxeology_guy + 2017-03-31T21:22:00.000Z + + + Matt Corallo + 2017-03-31T21:22:00.000Z + + + Sergio Demian Lerner + 2017-03-31T21:50:00.000Z + + + Sergio Demian Lerner + 2017-03-31T22:13:00.000Z + + + Samson Mow + 2017-04-01T03:03:00.000Z + + + Sergio Demian Lerner + 2017-04-01T03:35:00.000Z + + + Jared Lee Richardson + 2017-04-01T06:55:00.000Z + + + Sergio Demian Lerner + 2017-04-01T11:44:00.000Z + + + Jorge Timón + 2017-04-01T12:33:00.000Z + + + Natanael + 2017-04-01T13:15:00.000Z + + + Jorge Timón + 2017-04-01T14:07:00.000Z + + + Natanael + 2017-04-01T15:34:00.000Z + + + Jorge Timón + 2017-04-02T04:57:00.000Z + + + Natanael + 2017-04-02T10:03:00.000Z + + + Jorge Timón + 2017-04-02T11:43:00.000Z + + + Btc Drak + 2017-04-03T14:40:00.000Z + + + Erik Aronesty + 2017-04-06T02:27:00.000Z + + + Sergio Demian Lerner + 2017-04-06T20:42:00.000Z + + + Sergio Demian Lerner + 2017-04-06T20:58:00.000Z + + + Sergio Demian Lerner + 2017-04-06T21:03:00.000Z + + + Aymeric Vitte + 2017-04-06T22:29:00.000Z + + + R E Broadley + 2017-06-02T12:29:00.000Z + + + Erik Aronesty + 2017-06-02T20:04:00.000Z + + + Erik Aronesty + 2017-06-02T20:04:00.000Z + + + Sergio Demian Lerner + 2017-06-02T21:51:00.000Z + + + Erik Aronesty + 2017-06-03T00:53:00.000Z + + + Oliver Petruzel + 2017-06-03T02:03:00.000Z + + + Oliver Petruzel + 2017-06-03T21:05:00.000Z + + @@ -115,13 +154,13 @@ - python-feedgen + 2 Combined summary - Segwit2Mb - combined soft/hard fork - Request For Comments - 2023-08-01T20:08:23.855216+00:00 + 2025-09-26T15:36:18.841254+00:00 - Sergio Demian Lerner has proposed two solutions to address the ongoing conflict within the Bitcoin community regarding the activation of segwit and the block size increase. The first proposal, called Segwit2Mb, combines SegWit with a 2MB block size hard-fork that would be activated only if SegWit activates with 95% miner signaling. The objective is to reunite the Bitcoin community and prevent a cryptocurrency split. The second proposal, known as the COOP proposal, suggests gradually increasing the block size limit over a four-year period to 4MB, aiming to prevent sudden spikes in transaction fees and ensure efficient handling of increased network traffic.Both proposals aim to address scalability and efficiency issues in the Bitcoin network. The implementation of segwit has already increased transaction capacity, and further improvements have been made to boost the network's processing speed. However, the current 1MB block size limit has been criticized for limiting the network's capacity during periods of high demand.There are concerns about potential centralization and security risks associated with larger blocks, particularly with the COOP proposal. The COOP proposal has received mixed reactions from the Bitcoin community, while the Segwit2Mb proposal aims to find a middle ground solution.Sergio Demian Lerner emphasizes the importance of 95% miner signaling to prevent a potential Bitcoin fork. He explains that a fork with only 95% miner support would result in reduced transaction capacity and slower confirmation times, leading to higher fees and a growing mempool. He also highlights the need for consensus among nodes and miners to avoid a split similar to what happened with Ethereum HF and Ethereum Classic.The proposed implementation of SegWit, according to the conversation between Natanael and Jorge Timón, would replace the current 1MB block-size limit with a weight limit of 4MB. This implementation is considered a backward compatible soft fork.The Segwit2Mb proposal has received criticism from developers who argue that it ignores previous research and understanding of hardforks. However, Sergio Demian Lerner welcomes community feedback and contributions to improve the proposal.In response to suggestions for improvement, Sergio Demian Lerner considers delaying the hard-fork date and emphasizes the need for further comments from the community. He also suggests considering the impact of technological innovations like Lightning, TumbleBit, and RootStock. However, there are concerns about the potential risks and confusion that could arise from a sudden change in block size increase.The proposed solution, Segwit2Mb, requires all Bitcoin nodes to be updated to prevent them from being forked away in a chain with almost no hashing power before the hard-fork occurs. The proposal aims to see the Lightning Network in action, utilize the non-malleability features in segwit, and discuss other soft-forks in the scaling roadmap.Overall, Sergio Demian Lerner's proposal seeks to find a compromise solution to address the issue of halting innovation for years. While controversial, the proposal encourages community participation and feedback to unlock the current deadlock within the Bitcoin community. 2017-06-03T21:05:23+00:00 + Sergio Demian Lerner has proposed two solutions to address the ongoing conflict within the Bitcoin community regarding the activation of segwit and the block size increase. The first proposal, called Segwit2Mb, combines SegWit with a 2MB block size hard-fork that would be activated only if SegWit activates with 95% miner signaling. The objective is to reunite the Bitcoin community and prevent a cryptocurrency split. The second proposal, known as the COOP proposal, suggests gradually increasing the block size limit over a four-year period to 4MB, aiming to prevent sudden spikes in transaction fees and ensure efficient handling of increased network traffic.Both proposals aim to address scalability and efficiency issues in the Bitcoin network. The implementation of segwit has already increased transaction capacity, and further improvements have been made to boost the network's processing speed. However, the current 1MB block size limit has been criticized for limiting the network's capacity during periods of high demand.There are concerns about potential centralization and security risks associated with larger blocks, particularly with the COOP proposal. The COOP proposal has received mixed reactions from the Bitcoin community, while the Segwit2Mb proposal aims to find a middle ground solution.Sergio Demian Lerner emphasizes the importance of 95% miner signaling to prevent a potential Bitcoin fork. He explains that a fork with only 95% miner support would result in reduced transaction capacity and slower confirmation times, leading to higher fees and a growing mempool. He also highlights the need for consensus among nodes and miners to avoid a split similar to what happened with Ethereum HF and Ethereum Classic.The proposed implementation of SegWit, according to the conversation between Natanael and Jorge Timón, would replace the current 1MB block-size limit with a weight limit of 4MB. This implementation is considered a backward compatible soft fork.The Segwit2Mb proposal has received criticism from developers who argue that it ignores previous research and understanding of hardforks. However, Sergio Demian Lerner welcomes community feedback and contributions to improve the proposal.In response to suggestions for improvement, Sergio Demian Lerner considers delaying the hard-fork date and emphasizes the need for further comments from the community. He also suggests considering the impact of technological innovations like Lightning, TumbleBit, and RootStock. However, there are concerns about the potential risks and confusion that could arise from a sudden change in block size increase.The proposed solution, Segwit2Mb, requires all Bitcoin nodes to be updated to prevent them from being forked away in a chain with almost no hashing power before the hard-fork occurs. The proposal aims to see the Lightning Network in action, utilize the non-malleability features in segwit, and discuss other soft-forks in the scaling roadmap.Overall, Sergio Demian Lerner's proposal seeks to find a compromise solution to address the issue of halting innovation for years. While controversial, the proposal encourages community participation and feedback to unlock the current deadlock within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Solution-for-blockchain-congestion-and-determination-of-block-size-by-bitcoin-network-protocol-itself-.xml b/static/bitcoin-dev/March_2017/combined_Solution-for-blockchain-congestion-and-determination-of-block-size-by-bitcoin-network-protocol-itself-.xml index 8812b717ea..aacfc441df 100644 --- a/static/bitcoin-dev/March_2017/combined_Solution-for-blockchain-congestion-and-determination-of-block-size-by-bitcoin-network-protocol-itself-.xml +++ b/static/bitcoin-dev/March_2017/combined_Solution-for-blockchain-congestion-and-determination-of-block-size-by-bitcoin-network-protocol-itself-.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself. - 2023-08-01T19:45:35.390918+00:00 - - Erik Aronesty 2017-03-14 23:20:48+00:00 - - - ashish khandekar 2017-03-13 13:08:24+00:00 - - - Bram Cohen 2017-03-12 18:00:10+00:00 - - - Dionysis Zindros 2017-03-12 14:52:29+00:00 - - - David Vorick 2017-03-12 14:44:20+00:00 - - - ashish khandekar 2017-03-12 09:51:12+00:00 - + 2025-09-26T15:36:52.493994+00:00 + python-feedgen + + + [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself ashish khandekar + 2017-03-12T09:51:00.000Z + + + David Vorick + 2017-03-12T14:44:00.000Z + + + Dionysis Zindros + 2017-03-12T14:52:00.000Z + + + Bram Cohen + 2017-03-12T18:00:00.000Z + + + ashish khandekar + 2017-03-13T13:08:00.000Z + + + Erik Aronesty + 2017-03-14T23:20:00.000Z + + - python-feedgen + 2 Combined summary - Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself. - 2023-08-01T19:45:35.390918+00:00 + 2025-09-26T15:36:52.494828+00:00 - In the Bitcoin community, a member has raised concerns about spamming the network, block sizes, and release schedule/consensus levels. They are considering submitting a Bitcoin Improvement Proposal (BIP) to address these issues. Another member suggests that there is no quadratic hashing solution to these problems, and mentions that a proposal similar to BIP107 could be relevant. However, there are no specifics provided regarding the timing or consensus levels required for this proposal.A suggestion has been made to create a FAQ about blocksize increase proposals in Bitcoin. The argument is that previous proposals, including Bitcoin Classic, have encountered similar issues, and repeating them with minor adjustments is not productive.The context also includes a communication from David Vorick via the bitcoin-dev mailing list, referencing a proposal by Washington Sanchez. Vorick seeks clarification on the purpose of the block size limit to facilitate a constructive discussion about the proposal. The provided link leads to the text of Sanchez's BIP 107.The discussion revolves around the purpose of the block size limit, with the speaker emphasizing the need for a clear understanding to foster productive conversations. However, no further details are given regarding the specific proposal or the block size limit itself.Currently, the maximum block size in the Bitcoin protocol is 1mb, leading to a "fee market" where high transaction fees are necessary for smooth Bitcoin usage. This creates challenges for merchants and new users who may be unaware of developments in the Bitcoin community. The 1mb limit also results in a finite number of transactions that can be confirmed, leading to a backlog and potential blockchain congestion.To address these issues, a proposed solution involves allowing the Bitcoin network to dynamically adjust the maximum block size based on prevailing network conditions. This adjustment would be determined by tracking the total size of transactions between consecutive network difficulty changes and dividing it by 2016, rounding up to the nearest kb. This value would then be compared to the previous block size, with the higher of the two becoming the new maximum block size. This adaptive approach would enable the network to automatically adjust the block size and defend against stress tests or spam attacks in the future.To prevent orphaned blocks and extremely small blocks, a minimum block size should also be implemented, ranging from 30-60% of the maximum block size. By implementing these proactive measures, the Bitcoin blockchain can alleviate congestion and provide sufficient space for transactions to be included in blocks more easily. 2017-03-14T23:20:48+00:00 + In the Bitcoin community, a member has raised concerns about spamming the network, block sizes, and release schedule/consensus levels. They are considering submitting a Bitcoin Improvement Proposal (BIP) to address these issues. Another member suggests that there is no quadratic hashing solution to these problems, and mentions that a proposal similar to BIP107 could be relevant. However, there are no specifics provided regarding the timing or consensus levels required for this proposal.A suggestion has been made to create a FAQ about blocksize increase proposals in Bitcoin. The argument is that previous proposals, including Bitcoin Classic, have encountered similar issues, and repeating them with minor adjustments is not productive.The context also includes a communication from David Vorick via the bitcoin-dev mailing list, referencing a proposal by Washington Sanchez. Vorick seeks clarification on the purpose of the block size limit to facilitate a constructive discussion about the proposal. The provided link leads to the text of Sanchez's BIP 107.The discussion revolves around the purpose of the block size limit, with the speaker emphasizing the need for a clear understanding to foster productive conversations. However, no further details are given regarding the specific proposal or the block size limit itself.Currently, the maximum block size in the Bitcoin protocol is 1mb, leading to a "fee market" where high transaction fees are necessary for smooth Bitcoin usage. This creates challenges for merchants and new users who may be unaware of developments in the Bitcoin community. The 1mb limit also results in a finite number of transactions that can be confirmed, leading to a backlog and potential blockchain congestion.To address these issues, a proposed solution involves allowing the Bitcoin network to dynamically adjust the maximum block size based on prevailing network conditions. This adjustment would be determined by tracking the total size of transactions between consecutive network difficulty changes and dividing it by 2016, rounding up to the nearest kb. This value would then be compared to the previous block size, with the higher of the two becoming the new maximum block size. This adaptive approach would enable the network to automatically adjust the block size and defend against stress tests or spam attacks in the future.To prevent orphaned blocks and extremely small blocks, a minimum block size should also be implemented, ranging from 30-60% of the maximum block size. By implementing these proactive measures, the Bitcoin blockchain can alleviate congestion and provide sufficient space for transactions to be included in blocks more easily. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Strong-Anti-Replay-via-Coinbase-Transactions.xml b/static/bitcoin-dev/March_2017/combined_Strong-Anti-Replay-via-Coinbase-Transactions.xml index 81374859da..c20f1e733d 100644 --- a/static/bitcoin-dev/March_2017/combined_Strong-Anti-Replay-via-Coinbase-Transactions.xml +++ b/static/bitcoin-dev/March_2017/combined_Strong-Anti-Replay-via-Coinbase-Transactions.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Strong Anti-Replay via Coinbase Transactions - 2023-08-01T19:55:39.267984+00:00 - - Luke Dashjr 2017-03-29 09:15:57+00:00 - - - Cameron Garnham 2017-03-25 03:30:22+00:00 - + 2025-09-26T15:36:23.024169+00:00 + python-feedgen + + + [bitcoin-dev] Strong Anti-Replay via Coinbase Transactions Cameron Garnham + 2017-03-25T03:30:00.000Z + + + Luke Dashjr + 2017-03-29T09:15:00.000Z + + - python-feedgen + 2 Combined summary - Strong Anti-Replay via Coinbase Transactions - 2023-08-01T19:55:39.267984+00:00 + 2025-09-26T15:36:23.024667+00:00 - On March 25th, 2017, Cameron Garnham proposed a Bitcoin Improvement Proposal (BIP) aimed at protecting users from potential loss of funds due to transaction replay attacks during a chain split. The proposal suggests the activation of a soft fork that includes the creation of a new OpCode called 'OP_ANTI_REPLAY'. This OpCode would be defined as an unused NoOp and can only be created in a coinbase transaction with a value of one Satoshi.According to the proposal, every block's coinbase transaction should create exactly 1000 new OP_ANTI_REPLAY outputs, up to a total of 100,000. If an OP_ANTI_REPLAY output is spent in a block, a corresponding new OP_ANTI_REPLAY must be included in the same block. Miners are advised to account for the size of an OP_ANTI_REPLAY transaction as the sum of the transaction size and the size of an OP_ANTI_REPLAY output in the coinbase.In the event of a chain split after the implementation of this BIP, miners are expected to recycle all the OP_ANTI_REPLAY outputs by spending and recreating them in new blocks. This process would renew the protection for the new chain. However, it is noted that this recycling process may be spammy and require frequent updating due to regular chain splits.The proposal emphasizes the convenience it would provide for wallets to automate the inclusion of new coinbase inputs into transactions that spend potentially repayable transactions. However, the document acknowledges the difficulty of checking for competing transactions, which may make this convenience unattainable. Instead, it suggests using a single reserved output to recycle transactions.The soft fork proposed in this document is intended to enable users to make transactions with confidence that they cannot be replayed on a different chain. It is compatible with all existing bitcoin software, and once activated, all deployed Bitcoin Full Nodes will enforce the anti-replay provisions for Bitcoin Users. However, only upgraded nodes will enforce the additional requirements related to OP_ANTI_REPLAY.The BIP also introduces Opt-In-RBF enforcement, where higher-fee transactions take priority in case of conflicting spends of OP_ANTI_REPLAY outputs, creating competition among users for this resource. The document does not discuss SegWit Compatibility.This proposal is dual licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal, and it includes a reference implementation to be developed, although its feasibility is uncertain given the challenges mentioned earlier. 2017-03-29T09:15:57+00:00 + On March 25th, 2017, Cameron Garnham proposed a Bitcoin Improvement Proposal (BIP) aimed at protecting users from potential loss of funds due to transaction replay attacks during a chain split. The proposal suggests the activation of a soft fork that includes the creation of a new OpCode called 'OP_ANTI_REPLAY'. This OpCode would be defined as an unused NoOp and can only be created in a coinbase transaction with a value of one Satoshi.According to the proposal, every block's coinbase transaction should create exactly 1000 new OP_ANTI_REPLAY outputs, up to a total of 100,000. If an OP_ANTI_REPLAY output is spent in a block, a corresponding new OP_ANTI_REPLAY must be included in the same block. Miners are advised to account for the size of an OP_ANTI_REPLAY transaction as the sum of the transaction size and the size of an OP_ANTI_REPLAY output in the coinbase.In the event of a chain split after the implementation of this BIP, miners are expected to recycle all the OP_ANTI_REPLAY outputs by spending and recreating them in new blocks. This process would renew the protection for the new chain. However, it is noted that this recycling process may be spammy and require frequent updating due to regular chain splits.The proposal emphasizes the convenience it would provide for wallets to automate the inclusion of new coinbase inputs into transactions that spend potentially repayable transactions. However, the document acknowledges the difficulty of checking for competing transactions, which may make this convenience unattainable. Instead, it suggests using a single reserved output to recycle transactions.The soft fork proposed in this document is intended to enable users to make transactions with confidence that they cannot be replayed on a different chain. It is compatible with all existing bitcoin software, and once activated, all deployed Bitcoin Full Nodes will enforce the anti-replay provisions for Bitcoin Users. However, only upgraded nodes will enforce the additional requirements related to OP_ANTI_REPLAY.The BIP also introduces Opt-In-RBF enforcement, where higher-fee transactions take priority in case of conflicting spends of OP_ANTI_REPLAY outputs, creating competition among users for this resource. The document does not discuss SegWit Compatibility.This proposal is dual licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal, and it includes a reference implementation to be developed, although its feasibility is uncertain given the challenges mentioned earlier. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers-and-BIP150-.xml b/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers-and-BIP150-.xml index 335136311c..d7ffbd7051 100644 --- a/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers-and-BIP150-.xml +++ b/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers-and-BIP150-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Unique node identifiers (and BIP150) - 2023-08-01T19:45:15.460649+00:00 + 2025-09-26T15:36:50.404349+00:00 + python-feedgen Jonas Schnelli 2017-03-08 21:31:01+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Unique node identifiers (and BIP150) - 2023-08-01T19:45:15.460649+00:00 + 2025-09-26T15:36:50.404538+00:00 - In a message exchange between Tom and an unknown sender, the sender warns Tom about the security risks associated with open wifi base stations in public areas. The sender explains that setting up an open wifi base station with a hidden ssid can lead to tracking, as phones will automatically try to connect to it by revealing their ssid. This could be particularly problematic if there is a network of these base stations.The sender goes on to mention that this same issue could potentially affect Tom's BIP (Bitcoin Improvement Proposal) as well. In the BIP, a node wants to connect using the AUTHCHALLENGE, which includes the hash of the person they are trying to connect with. Tom argues that the hash includes encryption session information, making it impossible to distinguish identities. However, the sender disagrees, stating that the hash never changes and anyone listening can see the same hash being sent on every connection to that peer, regardless of where it's connected from.Despite their disagreement, Tom asks if the sender has read the BIP, suggesting that their discussion is related to a technical document or protocol. On March 8th, 2017, Jonas Schnelli wrote a message about BIP150 on the bitcoin-dev mailing list. He explained that BIP150 has an optional authentication feature designed to not reveal any node identity without first obtaining a crypto-proof from another peer who already knows the identity. This feature is meant to be fingerprint-free. Schnelli also mentioned that peers cannot be identified without having the identity-keys pre-shared by node operators.Tom Zander, however, pointed out a vulnerability in the BIP. He compared it to the issue of having an open wifi base station in a public street, explaining that the connection process of BIP involves sending the same hash every time one connects to a node. This makes it easy to fingerprint and track a peer's activity. Zander proposed using industry standards like Diffie-Hellman key exchange as a more secure alternative.Zander's concern was primarily focused on privacy and tracking. By using the analogy of an open wifi base station, he illustrated the potential weaknesses in BIP150's authentication process. This discussion shed light on the need for improvements in BIP150's design and suggested alternative solutions to address the identified vulnerabilities. 2017-03-08T21:31:01+00:00 + In a message exchange between Tom and an unknown sender, the sender warns Tom about the security risks associated with open wifi base stations in public areas. The sender explains that setting up an open wifi base station with a hidden ssid can lead to tracking, as phones will automatically try to connect to it by revealing their ssid. This could be particularly problematic if there is a network of these base stations.The sender goes on to mention that this same issue could potentially affect Tom's BIP (Bitcoin Improvement Proposal) as well. In the BIP, a node wants to connect using the AUTHCHALLENGE, which includes the hash of the person they are trying to connect with. Tom argues that the hash includes encryption session information, making it impossible to distinguish identities. However, the sender disagrees, stating that the hash never changes and anyone listening can see the same hash being sent on every connection to that peer, regardless of where it's connected from.Despite their disagreement, Tom asks if the sender has read the BIP, suggesting that their discussion is related to a technical document or protocol. On March 8th, 2017, Jonas Schnelli wrote a message about BIP150 on the bitcoin-dev mailing list. He explained that BIP150 has an optional authentication feature designed to not reveal any node identity without first obtaining a crypto-proof from another peer who already knows the identity. This feature is meant to be fingerprint-free. Schnelli also mentioned that peers cannot be identified without having the identity-keys pre-shared by node operators.Tom Zander, however, pointed out a vulnerability in the BIP. He compared it to the issue of having an open wifi base station in a public street, explaining that the connection process of BIP involves sending the same hash every time one connects to a node. This makes it easy to fingerprint and track a peer's activity. Zander proposed using industry standards like Diffie-Hellman key exchange as a more secure alternative.Zander's concern was primarily focused on privacy and tracking. By using the analogy of an open wifi base station, he illustrated the potential weaknesses in BIP150's authentication process. This discussion shed light on the need for improvements in BIP150's design and suggested alternative solutions to address the identified vulnerabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers.xml b/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers.xml index 90ea9e1936..c6047a8ccb 100644 --- a/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers.xml +++ b/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers.xml @@ -1,53 +1,79 @@ - + 2 Combined summary - Unique node identifiers - 2023-08-01T19:44:05.990235+00:00 - - Eric Voskuil 2017-03-22 00:04:47+00:00 - - - Aymeric Vitte 2017-03-09 11:01:49+00:00 - - - Pieter Wuille 2017-03-09 01:55:32+00:00 - - - Eric Voskuil 2017-03-09 01:08:04+00:00 - - - Pieter Wuille 2017-03-08 23:12:01+00:00 - - - Jonas Schnelli 2017-03-08 21:20:39+00:00 - - - Eric Voskuil 2017-03-08 21:09:05+00:00 - - - Jonas Schnelli 2017-03-08 19:47:54+00:00 - - - bfd at cock.lu 2017-03-08 02:01:26+00:00 - - - Eric Voskuil 2017-03-07 18:44:07+00:00 - - - John Hardy 2017-03-05 13:57:08+00:00 - - - Btc Drak 2017-03-05 13:27:08+00:00 - - - John Hardy 2017-03-05 12:55:27+00:00 - - - Marcel Jamin 2017-03-05 06:29:16+00:00 - - - John Hardy 2017-03-04 16:04:50+00:00 - + 2025-09-26T15:36:35.656739+00:00 + python-feedgen + + + [bitcoin-dev] Unique node identifiers John Hardy + 2017-03-04T16:04:00.000Z + + + Marcel Jamin + 2017-03-05T06:29:00.000Z + + + John Hardy + 2017-03-05T12:55:00.000Z + + + Btc Drak + 2017-03-05T13:27:00.000Z + + + John Hardy + 2017-03-05T13:57:00.000Z + + + Eric Voskuil + 2017-03-07T18:44:00.000Z + + + bfd + 2017-03-08T02:01:00.000Z + + + Jonas Schnelli + 2017-03-08T19:47:00.000Z + + + Eric Voskuil + 2017-03-08T21:09:00.000Z + + + Jonas Schnelli + 2017-03-08T21:20:00.000Z + + + [bitcoin-dev] Unique node identifiers (and BIP150) Tom Zander + 2017-03-08T21:25:00.000Z + + + Jonas Schnelli + 2017-03-08T21:31:00.000Z + + + Pieter Wuille + 2017-03-08T23:12:00.000Z + + + Eric Voskuil + 2017-03-09T01:08:00.000Z + + + Pieter Wuille + 2017-03-09T01:55:00.000Z + + + Aymeric Vitte + 2017-03-09T11:01:00.000Z + + + [bitcoin-dev] Unique node identifiers Eric Voskuil + 2017-03-22T00:04:00.000Z + + @@ -63,13 +89,13 @@ - python-feedgen + 2 Combined summary - Unique node identifiers - 2023-08-01T19:44:05.990235+00:00 + 2025-09-26T15:36:35.658619+00:00 - The email conversation between Eric Voskuil and Pieter Wuille revolves around the introduction of visible node identities on the Bitcoin network. Eric argues that IP addresses are not strong enough for various entities like web wallets, APIs, exchanges, and miners to prove that they are only connecting with authorized "customers" that they know. However, both parties agree that the proposal is misguided and easy to fake. They mention BIP150 as an optional extension of IP addresses but also discuss the centralized nature of the Tor network. The original proposal for visible node identities is seen as contradictory to the decentralized nature of Bitcoin. The impact of visible node identities on node count and the ease of faking them is also discussed.In another email exchange between Eric Voskuil and Pieter Wuille, Voskuil argues that weak identity is not a problem in Bitcoin. Wuille counters by mentioning the option to exclude certain connections through the use of -onlyacceptconnectionsfrom=IP. However, Wuille ultimately disagrees with Voskuil's argument and dismisses visible node identities as irrelevant. This highlights the ongoing debate within the Bitcoin community regarding the balance between privacy and network security.The email conversation between two individuals on the Bitcoin development team discusses the issue of node identification and privacy concerns related to BIP150 and BIP151. One party argues that these proposals provide a way to partition the network but do not offer significant privacy benefits. The other party argues against this, stating that nodes are not designed to be identifiable and that BIP150 does not lead to every node being identifiable. The importance of open discussion and technical debate in the development of new proposals is emphasized.The discussion on BIP150 gets sidetracked as there is a difference between identification/fingerprinting and proving identity. BIP150 is seen as facilitating the latter and should be the focus of attention. The extension of IP addresses provided by BIP150 is considered more secure against network-level attackers. The relationship between BIP150 and the new proposal for unique node identification mechanism is mentioned.In an email thread between Eric Voskuil and Jonas Schnelli, Voskuil expresses objection to BIP150's claim of guaranteeing node ownership. Schnelli accuses Voskuil of spreading FUD (fear, uncertainty, and doubt) and urges him to stop attacking BIP150/151 with such arguments. Voskuil mentions previous demands from a notable Core dev and points to a lengthy discussion thread on the topic for review.In an email conversation between Jonas Schnelli and Eric Lombrozo, Eric objects to BIP150, which claims to guarantee node ownership. Eric explains that nodes are not designed to be identifiable in any way. Jonas argues that provable identity works through the presharing of keys, which is what the new proposal promotes. A statement made by a Core dev about nodes not being identifiable is also mentioned.The context discusses the design of nodes, which are not meant to be identifiable in any way. There is an objection to BIP150, a protocol that allows peers to guarantee node ownership. However, the response refutes this objection, stating that BIP150 offers optional fingerprint-free authentication and does not reveal any node identifiers without first receiving proof from other peers who already know the identity.The discussion revolves around the concept of unique node identifiers in Bitcoin. Nodes are not designed to be identifiable, including persisting identities across IP changes or when connecting over different networks. However, there is a proposal for an anonymous, opt-in, unique node identification mechanism to counter sybil attacks and compile lists of active nodes. Some see this proposal as pointless, as it provides no actual security or privacy benefit.A proposal has been made for an anonymous, opt-in, unique node identification mechanism to counter sybil attacks. The idea is for each node to create a unique identifier in the form of a Bitcoin address. The node generates a private key, backs it up, and uses the corresponding public key as its unique identifier. The node can then respond with this identifier and a signature to prove its authenticity. This information can be used to identify patterns and dismiss sybil attacks.The email conversation between Btc Drak and John Hardy focuses on the unique node identification mechanism and its significance in countering sybil attacks. Btc Drak argues against nodes being identifiable technically or socially, as it compromises privacy. John Hardy proposes an anonymous opt-in unique identifier for each node to compile lists of active nodes. However, Btc Drak maintains that absolute node counts are meaningless and only fully validating nodes participating in economic activity matter.The concept of a pseudo-anonymous identity is discussed within the context of today's digital age. It provides individuals with the ability to create an online persona separate from their real-life identity, offering a level of protection against potential privacy breaches. This allows individuals to control what personal information is made public and when it is revealed. The flexibility of opting out at any time is emphasized, 2017-03-22T00:04:47+00:00 + The email conversation between Eric Voskuil and Pieter Wuille revolves around the introduction of visible node identities on the Bitcoin network. Eric argues that IP addresses are not strong enough for various entities like web wallets, APIs, exchanges, and miners to prove that they are only connecting with authorized "customers" that they know. However, both parties agree that the proposal is misguided and easy to fake. They mention BIP150 as an optional extension of IP addresses but also discuss the centralized nature of the Tor network. The original proposal for visible node identities is seen as contradictory to the decentralized nature of Bitcoin. The impact of visible node identities on node count and the ease of faking them is also discussed.In another email exchange between Eric Voskuil and Pieter Wuille, Voskuil argues that weak identity is not a problem in Bitcoin. Wuille counters by mentioning the option to exclude certain connections through the use of -onlyacceptconnectionsfrom=IP. However, Wuille ultimately disagrees with Voskuil's argument and dismisses visible node identities as irrelevant. This highlights the ongoing debate within the Bitcoin community regarding the balance between privacy and network security.The email conversation between two individuals on the Bitcoin development team discusses the issue of node identification and privacy concerns related to BIP150 and BIP151. One party argues that these proposals provide a way to partition the network but do not offer significant privacy benefits. The other party argues against this, stating that nodes are not designed to be identifiable and that BIP150 does not lead to every node being identifiable. The importance of open discussion and technical debate in the development of new proposals is emphasized.The discussion on BIP150 gets sidetracked as there is a difference between identification/fingerprinting and proving identity. BIP150 is seen as facilitating the latter and should be the focus of attention. The extension of IP addresses provided by BIP150 is considered more secure against network-level attackers. The relationship between BIP150 and the new proposal for unique node identification mechanism is mentioned.In an email thread between Eric Voskuil and Jonas Schnelli, Voskuil expresses objection to BIP150's claim of guaranteeing node ownership. Schnelli accuses Voskuil of spreading FUD (fear, uncertainty, and doubt) and urges him to stop attacking BIP150/151 with such arguments. Voskuil mentions previous demands from a notable Core dev and points to a lengthy discussion thread on the topic for review.In an email conversation between Jonas Schnelli and Eric Lombrozo, Eric objects to BIP150, which claims to guarantee node ownership. Eric explains that nodes are not designed to be identifiable in any way. Jonas argues that provable identity works through the presharing of keys, which is what the new proposal promotes. A statement made by a Core dev about nodes not being identifiable is also mentioned.The context discusses the design of nodes, which are not meant to be identifiable in any way. There is an objection to BIP150, a protocol that allows peers to guarantee node ownership. However, the response refutes this objection, stating that BIP150 offers optional fingerprint-free authentication and does not reveal any node identifiers without first receiving proof from other peers who already know the identity.The discussion revolves around the concept of unique node identifiers in Bitcoin. Nodes are not designed to be identifiable, including persisting identities across IP changes or when connecting over different networks. However, there is a proposal for an anonymous, opt-in, unique node identification mechanism to counter sybil attacks and compile lists of active nodes. Some see this proposal as pointless, as it provides no actual security or privacy benefit.A proposal has been made for an anonymous, opt-in, unique node identification mechanism to counter sybil attacks. The idea is for each node to create a unique identifier in the form of a Bitcoin address. The node generates a private key, backs it up, and uses the corresponding public key as its unique identifier. The node can then respond with this identifier and a signature to prove its authenticity. This information can be used to identify patterns and dismiss sybil attacks.The email conversation between Btc Drak and John Hardy focuses on the unique node identification mechanism and its significance in countering sybil attacks. Btc Drak argues against nodes being identifiable technically or socially, as it compromises privacy. John Hardy proposes an anonymous opt-in unique identifier for each node to compile lists of active nodes. However, Btc Drak maintains that absolute node counts are meaningless and only fully validating nodes participating in economic activity matter.The concept of a pseudo-anonymous identity is discussed within the context of today's digital age. It provides individuals with the ability to create an online persona separate from their real-life identity, offering a level of protection against potential privacy breaches. This allows individuals to control what personal information is made public and when it is revealed. The flexibility of opting out at any time is emphasized, - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_-sign-verify-message-replacement.xml b/static/bitcoin-dev/March_2018/combined_-sign-verify-message-replacement.xml index 31d1d89a15..1742346f48 100644 --- a/static/bitcoin-dev/March_2018/combined_-sign-verify-message-replacement.xml +++ b/static/bitcoin-dev/March_2018/combined_-sign-verify-message-replacement.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - {sign|verify}message replacement - 2023-08-01T22:48:51.019896+00:00 - - Karl Johan Alm 2018-03-27 08:09:41+00:00 - - - Pieter Wuille 2018-03-26 08:53:23+00:00 - - - Karl Johan Alm 2018-03-16 02:04:51+00:00 - - - Greg Sanders 2018-03-16 01:59:45+00:00 - - - Karl Johan Alm 2018-03-16 00:38:06+00:00 - - - Jim Posen 2018-03-15 20:53:34+00:00 - - - Luke Dashjr 2018-03-15 14:14:04+00:00 - - - Damian Williamson 2018-03-15 10:15:17+00:00 - - - Karl Johan Alm 2018-03-15 07:36:48+00:00 - - - Karl Johan Alm 2018-03-15 07:25:21+00:00 - - - Jim Posen 2018-03-15 06:43:21+00:00 - - - Karl Johan Alm 2018-03-15 03:01:03+00:00 - - - Anthony Towns 2018-03-14 16:12:11+00:00 - - - Luke Dashjr 2018-03-14 12:36:47+00:00 - - - Kalle Rosenbaum 2018-03-14 09:46:55+00:00 - - - Karl Johan Alm 2018-03-14 08:09:20+00:00 - + 2025-09-26T15:33:44.908778+00:00 + python-feedgen + + + [bitcoin-dev] {sign|verify}message replacement Karl Johan Alm + 2018-03-14T08:09:00.000Z + + + Kalle Rosenbaum + 2018-03-14T09:46:00.000Z + + + Luke Dashjr + 2018-03-14T12:36:00.000Z + + + Anthony Towns + 2018-03-14T16:12:00.000Z + + + Karl Johan Alm + 2018-03-15T03:01:00.000Z + + + Jim Posen + 2018-03-15T06:43:00.000Z + + + Karl Johan Alm + 2018-03-15T07:25:00.000Z + + + Karl Johan Alm + 2018-03-15T07:36:00.000Z + + + Damian Williamson + 2018-03-15T10:15:00.000Z + + + Luke Dashjr + 2018-03-15T14:14:00.000Z + + + Jim Posen + 2018-03-15T20:53:00.000Z + + + Karl Johan Alm + 2018-03-16T00:38:00.000Z + + + Greg Sanders + 2018-03-16T01:59:00.000Z + + + Karl Johan Alm + 2018-03-16T02:04:00.000Z + + + Pieter Wuille + 2018-03-26T08:53:00.000Z + + + Karl Johan Alm + 2018-03-27T08:09:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - {sign|verify}message replacement - 2023-08-01T22:48:51.020895+00:00 + 2025-09-26T15:33:44.910868+00:00 - Pieter Wuille has suggested including a version number in the signature that corresponds to a set of validation flags. This would allow verifiers to determine if they know the version number and report inconclusive results if they don't. He also proposes the idea of double verification, where the signature is checked against both consensus rules and standardness rules. If both verifications are valid, the signature is considered valid. If both are invalid, the signature is considered invalid. If the verifications yield different results, the validation is reported as inconclusive. Pieter believes that the double verify approach shows promise.In response to RPC commands, Pieter suggests extending the existing signmessage/verifymessage RPC. However, he acknowledges that there may be dependencies on the legacy behavior in some cases, so adding a legacy mode or using the old way for 1xx addresses should be sufficient.Pieter also warns about the danger of using prehashed messages for message signing. He cautions that this could be used to trick someone into signing an actual transaction unintentionally. To avoid this, he recommends always forcibly prefixing "Bitcoin signed message" to the message being signed.Karl Johan Alm proposes a replacement for the currently broken message signing tools that only work for legacy 1xx addresses. He suggests introducing a new structure called SignatureProof, which is a container for scriptSig and witnessProgram. Pieter Wuille suggests adding more logic to handle softforks and compatibility. One possible solution is to include a version number in the signature that corresponds to a set of validation flags. This way, if a verifier encounters a version number it doesn't know, it can report the validation as inconclusive.The conversation on the bitcoin-dev mailing list revolves around finding a solution for proving present possession of funds without compromising fungibility or hot/cold wallet separation. One proposal suggests using a FORKID in a transaction to allow for a mempool acceptance test that returns true even if the signature is not valid according to Bitcoin consensus, but only due to the FORKID. Another suggestion is to include time conditions for spending the funds. The default SIGHASH_ALL is recommended for simplicity, but an additional byte may need to be appended to the signature for encoding checks to pass. There is some debate about whether the sighash flag affects the outcome of verification.Luke Dashjr and Jim Posen discuss using sign messages to prove the availability of funds without compromising fungibility or hot/cold wallet separation. They suggest including nLockTime and nSequence in the proof container, with default values of 0 and 0xFFFF respectively. It is suggested to append a byte at the end of the signature for encoding checks, but keeping it as 0x00 since it does not affect the outcome of the verification. The participants also suggest assuming sufficient time/height on CLTV/CSV checks when there are no inputs.Luke Dashjr suggests that the current message signing feature should support "proof of funds" as a separate feature in addition to proving ownership of coins. Karl Johan Alm points out that such a feature could compromise fungibility and make hot/cold wallet separation impossible. Instead, he suggests that the feature should allow users to prove the availability of funds.The context discusses the idea of a custom signature checker that uses a specified address to derive a sighash and scriptPubKey. The proposed solution involves using the VerifyScript function with a new signature checker class. If the verify function returns true, it indicates a successful check, while false indicates an unsuccessful check. Feedback on this proposal is welcome.To implement this, the suggestion is to use the VerifyScript function along with the new signature checker class. When the sign parameter is set to true, the sighash is derived from the specified address. However, when sign is false, sha256d(message) is used instead. This approach allows for flexibility and customization in the process, ensuring that the appropriate parameters are used based on the situation. 2018-03-27T08:09:41+00:00 + Pieter Wuille has suggested including a version number in the signature that corresponds to a set of validation flags. This would allow verifiers to determine if they know the version number and report inconclusive results if they don't. He also proposes the idea of double verification, where the signature is checked against both consensus rules and standardness rules. If both verifications are valid, the signature is considered valid. If both are invalid, the signature is considered invalid. If the verifications yield different results, the validation is reported as inconclusive. Pieter believes that the double verify approach shows promise.In response to RPC commands, Pieter suggests extending the existing signmessage/verifymessage RPC. However, he acknowledges that there may be dependencies on the legacy behavior in some cases, so adding a legacy mode or using the old way for 1xx addresses should be sufficient.Pieter also warns about the danger of using prehashed messages for message signing. He cautions that this could be used to trick someone into signing an actual transaction unintentionally. To avoid this, he recommends always forcibly prefixing "Bitcoin signed message" to the message being signed.Karl Johan Alm proposes a replacement for the currently broken message signing tools that only work for legacy 1xx addresses. He suggests introducing a new structure called SignatureProof, which is a container for scriptSig and witnessProgram. Pieter Wuille suggests adding more logic to handle softforks and compatibility. One possible solution is to include a version number in the signature that corresponds to a set of validation flags. This way, if a verifier encounters a version number it doesn't know, it can report the validation as inconclusive.The conversation on the bitcoin-dev mailing list revolves around finding a solution for proving present possession of funds without compromising fungibility or hot/cold wallet separation. One proposal suggests using a FORKID in a transaction to allow for a mempool acceptance test that returns true even if the signature is not valid according to Bitcoin consensus, but only due to the FORKID. Another suggestion is to include time conditions for spending the funds. The default SIGHASH_ALL is recommended for simplicity, but an additional byte may need to be appended to the signature for encoding checks to pass. There is some debate about whether the sighash flag affects the outcome of verification.Luke Dashjr and Jim Posen discuss using sign messages to prove the availability of funds without compromising fungibility or hot/cold wallet separation. They suggest including nLockTime and nSequence in the proof container, with default values of 0 and 0xFFFF respectively. It is suggested to append a byte at the end of the signature for encoding checks, but keeping it as 0x00 since it does not affect the outcome of the verification. The participants also suggest assuming sufficient time/height on CLTV/CSV checks when there are no inputs.Luke Dashjr suggests that the current message signing feature should support "proof of funds" as a separate feature in addition to proving ownership of coins. Karl Johan Alm points out that such a feature could compromise fungibility and make hot/cold wallet separation impossible. Instead, he suggests that the feature should allow users to prove the availability of funds.The context discusses the idea of a custom signature checker that uses a specified address to derive a sighash and scriptPubKey. The proposed solution involves using the VerifyScript function with a new signature checker class. If the verify function returns true, it indicates a successful check, while false indicates an unsuccessful check. Feedback on this proposal is welcome.To implement this, the suggestion is to use the VerifyScript function along with the new signature checker class. When the sign parameter is set to true, the sighash is derived from the specified address. However, when sign is false, sha256d(message) is used instead. This approach allows for flexibility and customization in the process, ensuring that the appropriate parameters are used based on the situation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_BIP-117-Feedback.xml b/static/bitcoin-dev/March_2018/combined_BIP-117-Feedback.xml index 089f71075e..7fc680bb71 100644 --- a/static/bitcoin-dev/March_2018/combined_BIP-117-Feedback.xml +++ b/static/bitcoin-dev/March_2018/combined_BIP-117-Feedback.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - BIP 117 Feedback - 2023-08-01T22:27:01.437678+00:00 - - Johnson Lau 2018-03-05 15:28:20+00:00 - - - Russell O'Connor 2018-01-16 08:39:28+00:00 - - - Luke Dashjr 2018-01-16 04:15:54+00:00 - - - Gregory Maxwell 2018-01-16 03:27:26+00:00 - - - Rusty Russell 2018-01-16 01:06:14+00:00 - - - Russell O'Connor 2018-01-12 10:48:33+00:00 - - - Mark Friedenbach 2018-01-09 22:57:34+00:00 - - - Pieter Wuille 2018-01-09 14:21:08+00:00 - - - Mark Friedenbach 2018-01-09 12:40:30+00:00 - - - Rusty Russell 2018-01-09 11:22:18+00:00 - + 2025-09-26T15:34:03.825353+00:00 + python-feedgen + + + [bitcoin-dev] BIP 117 Feedback Rusty Russell + 2018-01-09T11:22:00.000Z + + + Mark Friedenbach + 2018-01-09T12:40:00.000Z + + + Pieter Wuille + 2018-01-09T14:21:00.000Z + + + Mark Friedenbach + 2018-01-09T22:57:00.000Z + + + Russell O'Connor + 2018-01-12T10:48:00.000Z + + + Rusty Russell + 2018-01-16T01:06:00.000Z + + + Gregory Maxwell + 2018-01-16T03:27:00.000Z + + + Luke Dashjr + 2018-01-16T04:15:00.000Z + + + Russell O'Connor + 2018-01-16T08:39:00.000Z + + + Johnson Lau + 2018-03-05T15:28:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP 117 Feedback - 2023-08-01T22:27:01.437678+00:00 + 2025-09-26T15:34:03.826679+00:00 - Rusty Russell has raised concerns about the flexibility of BIP 117 in a post on the bitcoin-dev mailing list. He believes that BIP 117 is trying to do too much and finds the use of altstack awkward. Instead, he suggests implementing a simpler form of tail recursion by having a single blob. He also expresses concern over the dropping of SIGOP and opcode limits in BIP 117 and calls for more justification, including measurements and bounds on execution times.Rusty proposes restoring statically analyzability by limiting rules to version 3 segwit transactions, counting only the top element of the stack, and requiring the popped-off blob for tail recursion to be identical to that top element of the stack.Regarding the use of altstack, Rusty suggests leaving it untouched in v0 P2WSH. He points out that if anyone is already using altstack, BIP 117 could potentially confiscate those UTXOs as the altstack would likely be non-executable. Even in v1 witness, Rusty believes altstack should remain temporary data storage.Rusty also highlights the security vulnerability in BIP 117, where concatenated scripts can be skipped by using an invalid push operation in the scriptSig, making the whole concatenated script a simple push.Luke Dashjr also contributes to the discussion, shifting the conversation to the added requirement that some pubkeys in a multisig must be parsable. He mentions that people have reported difficulty retrieving their funds due to this change, but clarifies that it is only a change to the standardness rules, not a consensus change. He assures that these funds are not permanently lost and can be retrieved with miner help.The discussion on the bitcoin-dev mailing list further explores the situation for BIP 117 and BIP-141. It is noted that BIP-141 requires a script to result in exactly a single TRUE on the stack, while P2SH scripts have not followed this rule. However, this does not affect the altstack, which is a separate stack. The principle of "standard transactions must still work" was violated with low-S, but it was considered trivial due to specific mitigating factors.The viability of BIP 117 as a soft fork for Script is also discussed, comparing it to past soft forks. BIP 117 introduces new rules that could render existing commitments unspendable and remove ownership of funds. It is argued that new consensus features should follow the UNIX philosophy of being small, modular, and incremental changes to enable unrestricted innovation.Mark Friedenbach discusses the use of the alt stack as a hack for segwit script version 0 and proposes future improvements to switch to a witness script version and a new segwit output version that supports native MAST. The author argues against removing SIGOP and opcode limits entirely and suggests limiting per-script execution proportional to the script size.Overall, there are concerns about the flexibility, security, and potential loss of funds associated with BIP 117. Various suggestions and proposals are made to address these concerns and improve the implementation of Segregated Witness in Bitcoin. 2018-03-05T15:28:20+00:00 + Rusty Russell has raised concerns about the flexibility of BIP 117 in a post on the bitcoin-dev mailing list. He believes that BIP 117 is trying to do too much and finds the use of altstack awkward. Instead, he suggests implementing a simpler form of tail recursion by having a single blob. He also expresses concern over the dropping of SIGOP and opcode limits in BIP 117 and calls for more justification, including measurements and bounds on execution times.Rusty proposes restoring statically analyzability by limiting rules to version 3 segwit transactions, counting only the top element of the stack, and requiring the popped-off blob for tail recursion to be identical to that top element of the stack.Regarding the use of altstack, Rusty suggests leaving it untouched in v0 P2WSH. He points out that if anyone is already using altstack, BIP 117 could potentially confiscate those UTXOs as the altstack would likely be non-executable. Even in v1 witness, Rusty believes altstack should remain temporary data storage.Rusty also highlights the security vulnerability in BIP 117, where concatenated scripts can be skipped by using an invalid push operation in the scriptSig, making the whole concatenated script a simple push.Luke Dashjr also contributes to the discussion, shifting the conversation to the added requirement that some pubkeys in a multisig must be parsable. He mentions that people have reported difficulty retrieving their funds due to this change, but clarifies that it is only a change to the standardness rules, not a consensus change. He assures that these funds are not permanently lost and can be retrieved with miner help.The discussion on the bitcoin-dev mailing list further explores the situation for BIP 117 and BIP-141. It is noted that BIP-141 requires a script to result in exactly a single TRUE on the stack, while P2SH scripts have not followed this rule. However, this does not affect the altstack, which is a separate stack. The principle of "standard transactions must still work" was violated with low-S, but it was considered trivial due to specific mitigating factors.The viability of BIP 117 as a soft fork for Script is also discussed, comparing it to past soft forks. BIP 117 introduces new rules that could render existing commitments unspendable and remove ownership of funds. It is argued that new consensus features should follow the UNIX philosophy of being small, modular, and incremental changes to enable unrestricted innovation.Mark Friedenbach discusses the use of the alt stack as a hack for segwit script version 0 and proposes future improvements to switch to a witness script version and a new segwit output version that supports native MAST. The author argues against removing SIGOP and opcode limits entirely and suggests limiting per-script execution proportional to the script size.Overall, there are concerns about the flexibility, security, and potential loss of funds associated with BIP 117. Various suggestions and proposals are made to address these concerns and improve the implementation of Segregated Witness in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader-stratum-mining-configure.xml b/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader-stratum-mining-configure.xml index ee0f878158..57cd3776e5 100644 --- a/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader-stratum-mining-configure.xml +++ b/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader-stratum-mining-configure.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure - 2023-08-01T22:47:00.850446+00:00 + 2025-09-26T15:33:53.316063+00:00 + python-feedgen Luke Dashjr 2018-03-07 15:48:00+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure - 2023-08-01T22:47:00.850446+00:00 + 2025-09-26T15:33:53.316189+00:00 - On March 7, 2018, Btc Drak proposed a new Bitcoin Improvement Proposal (BIP) to reserve 16 bits of the block header nVersion field for general-purpose use and remove their meaning for version bits soft-fork signaling. The purpose of this proposal was to allow miners to utilize some of the nVersion bits for other purposes without generating false warnings about unknown soft forks. By implementing this change, the number of parallel soft-fork activations using version bits would be reduced from 29 to 13, while preventing node software from emitting false warnings. It should be noted that this proposal does not assign specific bits for specific purposes, allowing flexibility for version-rolling AsicBoost or nonce rolling to reduce CPU load on mining controllers.Luke Dashjr responded to Btc Drak's proposal by questioning the necessity of it and pointing out that similar proposals were made years ago by Timo and Sergio. He suggested that the current draft should integrate their work without attempting to take credit for it. Furthermore, Dashjr emphasized that it would be inappropriate to implement a draft BIP on the mainnet before any discussion or consensus had been reached, describing such actions as malicious.Jan Čapek criticized the reasoning behind the choice of the new method for miner configuration, arguing that defining the response type would have been a better solution than reinventing it incompatibly for no reason. This criticism was directed at the mining.configure proposal, which aimed to address issues with the existing method, mining.capabilities. The decision to adopt mining.configure was based on the expectation of a deterministic response. Additional information regarding the rationale for this new method can be found on Github.In summary, the email thread discusses two proposals related to Bitcoin mining. The first proposal involves a new miner configuration method called mining.configure, chosen for its expected deterministic response. The second proposal aims to reserve 16 bits of the block header nVersion field for general-purpose use and remove their meaning for version bits soft-fork signaling. This proposal would reduce the number of parallel soft-fork activations using version bits and prevent false warnings from node software. Luke Dashjr expressed concerns about the necessity and proper procedure of implementing these proposals, while Jan Čapek criticized the reasoning behind the choice of the new miner configuration method. 2018-03-07T15:48:00+00:00 + On March 7, 2018, Btc Drak proposed a new Bitcoin Improvement Proposal (BIP) to reserve 16 bits of the block header nVersion field for general-purpose use and remove their meaning for version bits soft-fork signaling. The purpose of this proposal was to allow miners to utilize some of the nVersion bits for other purposes without generating false warnings about unknown soft forks. By implementing this change, the number of parallel soft-fork activations using version bits would be reduced from 29 to 13, while preventing node software from emitting false warnings. It should be noted that this proposal does not assign specific bits for specific purposes, allowing flexibility for version-rolling AsicBoost or nonce rolling to reduce CPU load on mining controllers.Luke Dashjr responded to Btc Drak's proposal by questioning the necessity of it and pointing out that similar proposals were made years ago by Timo and Sergio. He suggested that the current draft should integrate their work without attempting to take credit for it. Furthermore, Dashjr emphasized that it would be inappropriate to implement a draft BIP on the mainnet before any discussion or consensus had been reached, describing such actions as malicious.Jan Čapek criticized the reasoning behind the choice of the new method for miner configuration, arguing that defining the response type would have been a better solution than reinventing it incompatibly for no reason. This criticism was directed at the mining.configure proposal, which aimed to address issues with the existing method, mining.capabilities. The decision to adopt mining.configure was based on the expectation of a deterministic response. Additional information regarding the rationale for this new method can be found on Github.In summary, the email thread discusses two proposals related to Bitcoin mining. The first proposal involves a new miner configuration method called mining.configure, chosen for its expected deterministic response. The second proposal aims to reserve 16 bits of the block header nVersion field for general-purpose use and remove their meaning for version bits soft-fork signaling. This proposal would reduce the number of parallel soft-fork activations using version bits and prevent false warnings from node software. Luke Dashjr expressed concerns about the necessity and proper procedure of implementing these proposals, while Jan Čapek criticized the reasoning behind the choice of the new miner configuration method. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader.xml b/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader.xml index 8ea8aab75d..42add114ee 100644 --- a/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader.xml +++ b/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader.xml @@ -1,23 +1,36 @@ - + 2 Combined summary - BIP proposal: Reserved nversion bits in blockheader - 2023-08-01T22:46:45.536172+00:00 - - Luke Dashjr 2018-03-07 14:43:11+00:00 - - - Btc Drak 2018-03-07 08:19:57+00:00 - + 2025-09-26T15:34:05.912287+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader Btc Drak + 2018-03-07T08:19:00.000Z + + + Luke Dashjr + 2018-03-07T14:43:00.000Z + + + [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure Jan Čapek + 2018-03-07T15:43:00.000Z + + + Luke Dashjr + 2018-03-07T15:48:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal: Reserved nversion bits in blockheader - 2023-08-01T22:46:45.536172+00:00 + 2025-09-26T15:34:05.912949+00:00 - A proposal has been made to reserve 16 bits of the nVersion field in the block header for general purpose use, reducing the number of parallel soft-fork activations using versionbits from 29 to 13. This proposal aims to prevent node software from emitting false warnings about unknown signalling bits under the versionbits signalling system (BIP8/9). The author of the proposal suggests reserving upper bits of the nVersion field instead of annexing the lower 2 bytes. The scope of the proposal is limited to reserving bits for general use without specifying specific uses for each bit. The author provides examples of potential use cases for these reserved bits, such as version-rolling AsicBoost and nonce rolling to reduce CPU load on mining controllers. However, specific use cases are not crucial for this proposal.The proposal is revived due to the introduction of the DragonMint miner, which utilizes version-rolling AsicBoost on mainnet. It is important to address this to ensure that node software can adapt the versionbits warning system to avoid false positives. By reserving bits for general use, mining manufacturers can operate within the designated area without causing disruption or inconvenience. The current draft of the proposal integrates the work of Timo and Sergio, who had proposed something similar in the past. The author emphasizes the importance of basing the specification on their work instead of creating a completely new specification. The complete specification includes updates for GBT and the Stratum mining protocol.It is emphasized that it is not appropriate to use a draft BIP on mainnet before any discussion or consensus has been reached. Doing so would be considered malicious. The author hopes that DragonMint miners can still operate using the current Bitcoin protocol. To implement the proposal, 16 bits from the block header nVersion field, starting from 13 and ending at 28 inclusive (0x1fffe000), are reserved for general use and removed from BIP8 and BIP9 specifications. A mask of 0xe0001fff should be applied to nVersion bits so that bits 13-28 inclusive will be ignored for soft-fork signalling and unknown soft-fork warnings. Importantly, this proposal is backwards compatible and does not require a soft fork to be implemented.The proposal is dual licensed as BSD-3-Clause and CC0-1.0 Universal, ensuring that it can be used and implemented by the community effectively. Overall, this proposal aims to reserve bits for general use in order to prevent false warnings and allow mining manufacturers to operate within designated areas without causing disruption or inconvenience. 2018-03-07T14:43:11+00:00 + A proposal has been made to reserve 16 bits of the nVersion field in the block header for general purpose use, reducing the number of parallel soft-fork activations using versionbits from 29 to 13. This proposal aims to prevent node software from emitting false warnings about unknown signalling bits under the versionbits signalling system (BIP8/9). The author of the proposal suggests reserving upper bits of the nVersion field instead of annexing the lower 2 bytes. The scope of the proposal is limited to reserving bits for general use without specifying specific uses for each bit. The author provides examples of potential use cases for these reserved bits, such as version-rolling AsicBoost and nonce rolling to reduce CPU load on mining controllers. However, specific use cases are not crucial for this proposal.The proposal is revived due to the introduction of the DragonMint miner, which utilizes version-rolling AsicBoost on mainnet. It is important to address this to ensure that node software can adapt the versionbits warning system to avoid false positives. By reserving bits for general use, mining manufacturers can operate within the designated area without causing disruption or inconvenience. The current draft of the proposal integrates the work of Timo and Sergio, who had proposed something similar in the past. The author emphasizes the importance of basing the specification on their work instead of creating a completely new specification. The complete specification includes updates for GBT and the Stratum mining protocol.It is emphasized that it is not appropriate to use a draft BIP on mainnet before any discussion or consensus has been reached. Doing so would be considered malicious. The author hopes that DragonMint miners can still operate using the current Bitcoin protocol. To implement the proposal, 16 bits from the block header nVersion field, starting from 13 and ending at 28 inclusive (0x1fffe000), are reserved for general use and removed from BIP8 and BIP9 specifications. A mask of 0xe0001fff should be applied to nVersion bits so that bits 13-28 inclusive will be ignored for soft-fork signalling and unknown soft-fork warnings. Importantly, this proposal is backwards compatible and does not require a soft fork to be implemented.The proposal is dual licensed as BSD-3-Clause and CC0-1.0 Universal, ensuring that it can be used and implemented by the community effectively. Overall, this proposal aims to reserve bits for general use in order to prevent false warnings and allow mining manufacturers to operate within designated areas without causing disruption or inconvenience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_Bulletproof-CT-as-basis-for-election-voting-.xml b/static/bitcoin-dev/March_2018/combined_Bulletproof-CT-as-basis-for-election-voting-.xml index 2d8d492c82..e748b8a0ed 100644 --- a/static/bitcoin-dev/March_2018/combined_Bulletproof-CT-as-basis-for-election-voting-.xml +++ b/static/bitcoin-dev/March_2018/combined_Bulletproof-CT-as-basis-for-election-voting-.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Bulletproof CT as basis for election voting? - 2023-08-01T22:47:39.545897+00:00 - - Tim Ruffing 2018-03-12 09:32:55+00:00 - - - ZmnSCPxj 2018-03-12 06:46:39+00:00 - - - ZmnSCPxj 2018-03-12 04:14:42+00:00 - - - JOSE FEMENIAS CAÑUELO 2018-03-11 12:44:47+00:00 - + 2025-09-26T15:33:40.732139+00:00 + python-feedgen + + + [bitcoin-dev] Bulletproof CT as basis for election voting? JOSE FEMENIAS CAÑUELO + 2018-03-11T12:44:00.000Z + + + ZmnSCPxj + 2018-03-12T04:14:00.000Z + + + ZmnSCPxj + 2018-03-12T06:46:00.000Z + + + Tim Ruffing + 2018-03-12T09:32:00.000Z + + - python-feedgen + 2 Combined summary - Bulletproof CT as basis for election voting? - 2023-08-01T22:47:39.545897+00:00 + 2025-09-26T15:33:40.732853+00:00 - In an email conversation between Tim and JOSE FEMENIAS CAÑUELO, the potential use of blockchain in electronic voting is discussed. Tim mentions that homomorphic commitments and zero-knowledge proofs have been used in e-voting for a while, and a bulletin board is needed to store ballots. While blockchain can be useful in some cases, it may not be necessary in all situations. Tim suggests reading literature on e-voting, including a paper on blockchains and e-voting.JOSE proposes a simple implementation for e-voting using Bulletproof Confidential Transactions. In this implementation, each citizen is issued a coin representing a vote, and voters send their coins to their preferred party. Tim does not point out any specific issues with JOSE's proposal but suggests discussing such topics elsewhere.However, there are concerns regarding the power of The Party, a miner-strong group that controls the government of a whole country. The Party could censor transactions that do not give them non-zero amounts of coins. If The Party has control over miners or is composed of miners, they can censor transactions based on certain heuristics. This prevents mixing, and other parties may end up voting based on controlled hash power. Proof-of-stake can mitigate this, but no solution currently exists. A multi-asset international blockchain with confidential assets can help prevent centralization, but trust in miners is limited to the fees paid to them. Miners charge as much as they can for the hashrate, leading to potentially high charges for vote transfers if detected by miners. The possibility of uncensorability using a two-step commitment is mentioned, but if the vote is valuable enough, a miner might choose to forgo its fee instead of confirming the second commitment. It may be more effective to focus on libertarian solutions on top of blockchains rather than forcing democratic ideals onto them.ZmnSCPxj responds to a question about the use of Bulletproof Confidential Transactions in an election. He explains that MimbleWimble operates under the assumption that the sender needs to reveal some secrets to the receiver, allowing the receiver to know if it received 0 or 1 coin from that sender. ZmnSCPxj believes that if voters send vote-coins directly to "The Party," then "The Party" can identify the votes of specific voters and potentially take action against them. However, aggregators/mixers can be used to obscure the source of coins. Additionally, sending directly from the transaction of the Voting Authority to another transaction to the selected party would enable members of The Party who secretly control the Voting Authority records to determine which voters received which outputs of the Voting Authority.Jose Femenias Canuelo initiates the discussion by sharing his thoughts on the use of Bulletproof Confidential Transactions in an election. He suggests that the Voting Authority should send a coin (representing one vote) to each citizen above 18. Each voter would then send their coin to their preferred party as part of a Bulletproof Confidential Transaction, along with 0 coins to other parties to disguise their vote. This method ensures that each party will accumulate votes equal to the number of coins received. However, there may be missing features required in Bulletproof to fully support this use case. It is crucial to consider these features before implementing this simplistic approach.Overall, the use of Bulletproof Confidential Transactions in electronic voting can hide the amount transferred while still allowing for auditability. The proposed implementation involves issuing a coin to each eligible citizen, who then sends it to their preferred party. However, certain challenges and potential issues need to be addressed before adopting this approach. 2018-03-12T09:32:55+00:00 + In an email conversation between Tim and JOSE FEMENIAS CAÑUELO, the potential use of blockchain in electronic voting is discussed. Tim mentions that homomorphic commitments and zero-knowledge proofs have been used in e-voting for a while, and a bulletin board is needed to store ballots. While blockchain can be useful in some cases, it may not be necessary in all situations. Tim suggests reading literature on e-voting, including a paper on blockchains and e-voting.JOSE proposes a simple implementation for e-voting using Bulletproof Confidential Transactions. In this implementation, each citizen is issued a coin representing a vote, and voters send their coins to their preferred party. Tim does not point out any specific issues with JOSE's proposal but suggests discussing such topics elsewhere.However, there are concerns regarding the power of The Party, a miner-strong group that controls the government of a whole country. The Party could censor transactions that do not give them non-zero amounts of coins. If The Party has control over miners or is composed of miners, they can censor transactions based on certain heuristics. This prevents mixing, and other parties may end up voting based on controlled hash power. Proof-of-stake can mitigate this, but no solution currently exists. A multi-asset international blockchain with confidential assets can help prevent centralization, but trust in miners is limited to the fees paid to them. Miners charge as much as they can for the hashrate, leading to potentially high charges for vote transfers if detected by miners. The possibility of uncensorability using a two-step commitment is mentioned, but if the vote is valuable enough, a miner might choose to forgo its fee instead of confirming the second commitment. It may be more effective to focus on libertarian solutions on top of blockchains rather than forcing democratic ideals onto them.ZmnSCPxj responds to a question about the use of Bulletproof Confidential Transactions in an election. He explains that MimbleWimble operates under the assumption that the sender needs to reveal some secrets to the receiver, allowing the receiver to know if it received 0 or 1 coin from that sender. ZmnSCPxj believes that if voters send vote-coins directly to "The Party," then "The Party" can identify the votes of specific voters and potentially take action against them. However, aggregators/mixers can be used to obscure the source of coins. Additionally, sending directly from the transaction of the Voting Authority to another transaction to the selected party would enable members of The Party who secretly control the Voting Authority records to determine which voters received which outputs of the Voting Authority.Jose Femenias Canuelo initiates the discussion by sharing his thoughts on the use of Bulletproof Confidential Transactions in an election. He suggests that the Voting Authority should send a coin (representing one vote) to each citizen above 18. Each voter would then send their coin to their preferred party as part of a Bulletproof Confidential Transaction, along with 0 coins to other parties to disguise their vote. This method ensures that each party will accumulate votes equal to the number of coins received. However, there may be missing features required in Bulletproof to fully support this use case. It is crucial to consider these features before implementing this simplistic approach.Overall, the use of Bulletproof Confidential Transactions in electronic voting can hide the amount transferred while still allowing for auditability. The proposed implementation involves issuing a coin to each eligible citizen, who then sends it to their preferred party. However, certain challenges and potential issues need to be addressed before adopting this approach. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_Lookinf-for-issues-to-contribute-to.xml b/static/bitcoin-dev/March_2018/combined_Lookinf-for-issues-to-contribute-to.xml index 084b7281f6..4aa9faef1b 100644 --- a/static/bitcoin-dev/March_2018/combined_Lookinf-for-issues-to-contribute-to.xml +++ b/static/bitcoin-dev/March_2018/combined_Lookinf-for-issues-to-contribute-to.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Lookinf for issues to contribute to - 2023-08-01T22:50:27.843227+00:00 - - rhavar at protonmail.com 2018-03-24 14:50:54+00:00 - - - Daniel R 2018-03-24 13:52:56+00:00 - + 2025-09-26T15:33:49.114618+00:00 + python-feedgen + + + [bitcoin-dev] Lookinf for issues to contribute to Daniel R + 2018-03-24T13:52:00.000Z + + + rhavar + 2018-03-24T14:50:00.000Z + + - python-feedgen + 2 Combined summary - Lookinf for issues to contribute to - 2023-08-01T22:50:27.843227+00:00 + 2025-09-26T15:33:49.115175+00:00 - Daniel R, an intermediate programmer with knowledge of Python, C/C++, and Java, is eager to contribute to Bitcoin Core. He has already cloned the git repository and seeks guidance on learning more about the structure of Bitcoin Core. Additionally, Daniel wants to work on specific problems that will allow him to gain experience with the source code. With a strong understanding of cryptographic concepts and procedures, Daniel is also teaching himself math related to elliptic curves.Ryan, offering direction to Daniel, suggests starting with simple and seemingly mundane changes to organically develop a better understanding of Bitcoin Core. Ryan recommends visiting https://github.com/bitcoin/bitcoin/pulls to find issues, reproduce the problem, test potential fixes, and learn from others' solutions. According to Ryan, there is a significant demand for practical problem-solving skills, rather than advanced mathematics, in the Bitcoin and cryptocurrency space.Notably, while Daniel pursues his goal of contributing to Bitcoin Core, he is concurrently working on his bachelor thesis. The thesis focuses on exploring the utilization of blockchain technology in the car industry, meticulously analyzing various aspects of protocol design. 2018-03-24T14:50:54+00:00 + Daniel R, an intermediate programmer with knowledge of Python, C/C++, and Java, is eager to contribute to Bitcoin Core. He has already cloned the git repository and seeks guidance on learning more about the structure of Bitcoin Core. Additionally, Daniel wants to work on specific problems that will allow him to gain experience with the source code. With a strong understanding of cryptographic concepts and procedures, Daniel is also teaching himself math related to elliptic curves.Ryan, offering direction to Daniel, suggests starting with simple and seemingly mundane changes to organically develop a better understanding of Bitcoin Core. Ryan recommends visiting https://github.com/bitcoin/bitcoin/pulls to find issues, reproduce the problem, test potential fixes, and learn from others' solutions. According to Ryan, there is a significant demand for practical problem-solving skills, rather than advanced mathematics, in the Bitcoin and cryptocurrency space.Notably, while Daniel pursues his goal of contributing to Bitcoin Core, he is concurrently working on his bachelor thesis. The thesis focuses on exploring the utilization of blockchain technology in the car industry, meticulously analyzing various aspects of protocol design. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_Optimized-Header-Sync.xml b/static/bitcoin-dev/March_2018/combined_Optimized-Header-Sync.xml index 7231018595..797140a698 100644 --- a/static/bitcoin-dev/March_2018/combined_Optimized-Header-Sync.xml +++ b/static/bitcoin-dev/March_2018/combined_Optimized-Header-Sync.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Optimized Header Sync - 2023-08-01T22:50:48.395157+00:00 - - Jim Posen 2018-04-03 05:34:39+00:00 - - - Riccardo Casatta 2018-03-30 08:06:24+00:00 - - - Anthony Towns 2018-03-30 06:14:18+00:00 - - - Jim Posen 2018-03-30 00:50:30+00:00 - - - Riccardo Casatta 2018-03-29 08:17:12+00:00 - - - Jim Posen 2018-03-27 23:31:58+00:00 - + 2025-09-26T15:33:47.029275+00:00 + python-feedgen + + + [bitcoin-dev] Optimized Header Sync Jim Posen + 2018-03-27T23:31:00.000Z + + + Riccardo Casatta + 2018-03-29T08:17:00.000Z + + + Jim Posen + 2018-03-30T00:50:00.000Z + + + Anthony Towns + 2018-03-30T06:14:00.000Z + + + Riccardo Casatta + 2018-03-30T08:06:00.000Z + + + Jim Posen + 2018-04-03T05:34:00.000Z + + - python-feedgen + 2 Combined summary - Optimized Header Sync - 2023-08-01T22:50:48.395157+00:00 + 2025-09-26T15:33:47.030245+00:00 - In a recent bitcoin-dev discussion, the topic of handling checkpoints and compressed header streams was brought up. It was suggested that these items should be handled in chunks of 2016 headers and queried by chunk number instead of height. This method is cache-friendly and avoids using bit 0 and bit 1 in the bitfield.Jim Posen expressed interest in treating checkpoints as commitments to chain work. Another user suggested setting checkpoints every 2016 blocks and including the corresponding bits value for that set of blocks. This would allow each node to commit to approximately how much work their entire chain has by sending around 10KB of data. The deltas in each node's chain's target could then be verified by downloading the 2016 headers between those checkpoints and checking the timestamps and proof of work match both the old target and the new target from adjacent checkpoints.A new P2P network extension has been proposed to improve the syncing of block headers in Bitcoin clients. Optimized clients fetch all block headers before fetching all blocks themselves. The current protocol for fetching headers can be optimized further by compressing header data and downloading more headers simultaneously. The proposed messages enable sync strategies that are resilient against types of attacks. The NODE_HEADERS_V2 service bit is used to list block hashes at specified intervals. The proposed header download protocol reduces bandwidth usage by ~40%-50% and supports downloading headers ranges from multiple peers in parallel, which is not possible with the current mechanism. This also enables sync strategies with better resistance to denial-of-service attacks.Sync strategies include forward sequential syncing, parallel header download, and random sampling proof-of-work. The rationale behind including the coinbase transaction in the headers messages is due to its cryptographic commitments to a block's height. A simpler approach could be to encode the headers in groups of 2016 headers. The P2P messages are designed to be flexible, supporting multiple header sync strategies and leaving room for future innovations. A checkpoint is defined for a block as a tuple of its hash and the chain work. The proposed messages enable sync strategies that are resilient against types of attacks. The checkpts response includes a start height, end height, start checkpoint, end checkpoint, interval, checkpoints length, and checkpoints.The full BIP specification can be found at https://github.com/jimpo/bips/blob/headers-sync/headersv2.mediawiki. Credit is given to Gregory Maxwell, Suhas Daftuar, and Pieter Wuille for their contributions. The proposed protocol is backwards compatible and has no changes to consensus rules.Overall, the proposed P2P network extension aims to improve the syncing of block headers in Bitcoin clients by introducing compressed header data and efficient syncing strategies. This extension reduces bandwidth usage and supports parallel header downloads, making the synchronization process faster and more resistant to attacks. By treating checkpoints as commitments to chain work, nodes can estimate the amount of work in their chains and verify it using the 2016 headers between checkpoints. The proposed protocol is designed to be flexible and leaves room for future innovations, while also being compatible with existing implementations and consensus rules. 2018-04-03T05:34:39+00:00 + In a recent bitcoin-dev discussion, the topic of handling checkpoints and compressed header streams was brought up. It was suggested that these items should be handled in chunks of 2016 headers and queried by chunk number instead of height. This method is cache-friendly and avoids using bit 0 and bit 1 in the bitfield.Jim Posen expressed interest in treating checkpoints as commitments to chain work. Another user suggested setting checkpoints every 2016 blocks and including the corresponding bits value for that set of blocks. This would allow each node to commit to approximately how much work their entire chain has by sending around 10KB of data. The deltas in each node's chain's target could then be verified by downloading the 2016 headers between those checkpoints and checking the timestamps and proof of work match both the old target and the new target from adjacent checkpoints.A new P2P network extension has been proposed to improve the syncing of block headers in Bitcoin clients. Optimized clients fetch all block headers before fetching all blocks themselves. The current protocol for fetching headers can be optimized further by compressing header data and downloading more headers simultaneously. The proposed messages enable sync strategies that are resilient against types of attacks. The NODE_HEADERS_V2 service bit is used to list block hashes at specified intervals. The proposed header download protocol reduces bandwidth usage by ~40%-50% and supports downloading headers ranges from multiple peers in parallel, which is not possible with the current mechanism. This also enables sync strategies with better resistance to denial-of-service attacks.Sync strategies include forward sequential syncing, parallel header download, and random sampling proof-of-work. The rationale behind including the coinbase transaction in the headers messages is due to its cryptographic commitments to a block's height. A simpler approach could be to encode the headers in groups of 2016 headers. The P2P messages are designed to be flexible, supporting multiple header sync strategies and leaving room for future innovations. A checkpoint is defined for a block as a tuple of its hash and the chain work. The proposed messages enable sync strategies that are resilient against types of attacks. The checkpts response includes a start height, end height, start checkpoint, end checkpoint, interval, checkpoints length, and checkpoints.The full BIP specification can be found at https://github.com/jimpo/bips/blob/headers-sync/headersv2.mediawiki. Credit is given to Gregory Maxwell, Suhas Daftuar, and Pieter Wuille for their contributions. The proposed protocol is backwards compatible and has no changes to consensus rules.Overall, the proposed P2P network extension aims to improve the syncing of block headers in Bitcoin clients by introducing compressed header data and efficient syncing strategies. This extension reduces bandwidth usage and supports parallel header downloads, making the synchronization process faster and more resistant to attacks. By treating checkpoints as commitments to chain work, nodes can estimate the amount of work in their chains and verify it using the 2016 headers between checkpoints. The proposed protocol is designed to be flexible and leaves room for future innovations, while also being compatible with existing implementations and consensus rules. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_Revisiting-BIP-125-RBF-policy-.xml b/static/bitcoin-dev/March_2018/combined_Revisiting-BIP-125-RBF-policy-.xml index 152d0aefce..ebbc936dcf 100644 --- a/static/bitcoin-dev/March_2018/combined_Revisiting-BIP-125-RBF-policy-.xml +++ b/static/bitcoin-dev/March_2018/combined_Revisiting-BIP-125-RBF-policy-.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Revisiting BIP 125 RBF policy. - 2023-08-01T22:41:40.917212+00:00 - - rhavar at protonmail.com 2018-03-09 18:40:34+00:00 - - - Peter Todd 2018-03-09 18:28:03+00:00 - - - Russell O'Connor 2018-03-08 20:07:43+00:00 - - - Peter Todd 2018-03-08 18:34:26+00:00 - - - Russell O'Connor 2018-03-08 15:39:46+00:00 - - - Peter Todd 2018-03-01 15:11:29+00:00 - - - Russell O'Connor 2018-02-27 16:25:59+00:00 - - - Greg Sanders 2018-02-14 14:16:29+00:00 - - - Russell O'Connor 2018-02-14 14:08:01+00:00 - - - rhavar at protonmail.com 2018-02-14 02:07:25+00:00 - - - Peter Todd 2018-02-13 18:40:34+00:00 - - - Russell O'Connor 2018-02-12 23:46:43+00:00 - - - Peter Todd 2018-02-12 23:42:25+00:00 - - - rhavar at protonmail.com 2018-02-12 23:23:12+00:00 - - - Russell O'Connor 2018-02-12 23:19:40+00:00 - - - Peter Todd 2018-02-12 22:58:28+00:00 - - - rhavar at protonmail.com 2018-02-12 17:30:04+00:00 - - - Russell O'Connor 2018-02-12 15:52:30+00:00 - + 2025-09-26T15:33:57.522079+00:00 + python-feedgen + + + [bitcoin-dev] Revisiting BIP 125 RBF policy Russell O'Connor + 2018-02-12T15:52:00.000Z + + + rhavar + 2018-02-12T17:30:00.000Z + + + Peter Todd + 2018-02-12T22:58:00.000Z + + + Russell O'Connor + 2018-02-12T23:19:00.000Z + + + rhavar + 2018-02-12T23:23:00.000Z + + + Peter Todd + 2018-02-12T23:42:00.000Z + + + Russell O'Connor + 2018-02-12T23:46:00.000Z + + + Peter Todd + 2018-02-13T18:40:00.000Z + + + rhavar + 2018-02-14T02:07:00.000Z + + + Russell O'Connor + 2018-02-14T14:08:00.000Z + + + Greg Sanders + 2018-02-14T14:16:00.000Z + + + Russell O'Connor + 2018-02-27T16:25:00.000Z + + + Peter Todd + 2018-03-01T15:11:00.000Z + + + Russell O'Connor + 2018-03-08T15:39:00.000Z + + + Peter Todd + 2018-03-08T18:34:00.000Z + + + Russell O'Connor + 2018-03-08T20:07:00.000Z + + + Peter Todd + 2018-03-09T18:28:00.000Z + + + rhavar + 2018-03-09T18:40:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Revisiting BIP 125 RBF policy. - 2023-08-01T22:41:40.917212+00:00 + 2025-09-26T15:33:57.523921+00:00 - The email thread on the bitcoin-dev mailing list discusses the relaxation of some of the Denial of Service (DoS) prevention rules to open up more use cases and adoption. The issue of institutional wallets sweeping incoming payments and sweeping unconfirmed outputs is raised, but it is believed that this behavior is unintentional. It is suggested that if people start using the new replacement behavior, then institutions doing these sweeps may stop doing it. The development of a reasonable standard Replace-by-Fee (RBF) policy that aligns with miner incentives is discussed as miners prefer transactions with higher package fee rates. The weakening of DoS protections is not considered a huge problem, and it is proposed to try relaxing some of the rules in a release and see what happens.In a discussion about Bitcoin's Replace-by-Fee (RBF) policy, Russell O'Connor suggested that replaced transactions should require a fee increase of at least the min-fee-rate times the size of all the transactions being ejected. Peter Todd raised concerns about weakening anti-DoS protections, but O'Connor clarified that he was not suggesting removing them entirely. The issue of institutional wallets sweeping unconfirmed outputs was also discussed as they seem to be happy to sweep unconfirmed outputs, which is potentially problematic. Additionally, there was a discussion about miner incentives and developing a reasonable standard RBF policy that aligns with those incentives. There was some disagreement about whether miners and full nodes have slightly different priorities. Nonetheless, Todd agreed to try the new replacement behavior in a release and see what happens. If people use this new replacement behavior, it may discourage institutions from sweeping unconfirmed outputs, which can be dangerous in reorgs.Peter Todd and Russell O'Connor were discussing the proposed change in RBF policy. Peter Todd pointed out that replacing a transaction without paying fees is identical to what an attacker is trying to do, making any such scheme vulnerable to attack. Russell argued that the current policy is problematic in practice where normal transactions are being performed and no one is attacking each other. However, Peter countered that the argument is not valid as normal users creating issues has nothing to do with relaxing anti-DoS protections. He suggested that replaced transactions require a fee increase of at least min-fee-rate times the size of all the transactions being ejected (in addition to the other proposed requirements). Moreover, Peter questioned how often non-attacking users face issues, but Russell pointed out that institutional wallets sweeping incoming payments regularly cause this problem. They also discussed miners' preference for higher package fee rates regardless of personal preferred RBF policies, making it important to develop a reasonable standard RBF policy that aligns with miner incentives and is robust against possible DoS vectors. This change in RBF policy can partially mitigate the problem of pinned transactions.Russell O'Connor proposed a change in RBF policy, but Peter Todd argued that solving this problem is impossible because it opens up an attack by relaxing anti-DoS protections. Todd stated that normal users creating issues does not happen often and can be avoided by skipping the use of RBF replacements if someone spends an unconfirmed output that was sent to them. He also pointed out that the argument of normal users not attacking each other has nothing to do with the issue at hand and that any protection scheme will be as vulnerable to attack as not having protection in the first place. Ultimately, Todd suggested that the attack may not be important enough to matter.In an email exchange, Peter Todd and Russell O'Connor discussed the possibility of solving the problem of replacing transactions that have been offered a new transaction with a higher fee rate. Todd expressed his belief that it is not possible to solve this issue because someone has already consumed network bandwidth that should be paid for with fees. He stated that any attempt to replace a transaction without paying those fees would be vulnerable to attack and likened it to what an attacker would try to do. However, he did mention that if the attack isn't significant enough, it may not matter. O'Connor agreed with Todd's assessment but still believes that pursuing the proposed change in Replace-by-Fee (RBF) policy is worthwhile as the current policy is problematic in practice for normal transactions.In a discussion on the Bitcoin Development mailing list, Peter Todd expressed his opinion that it is not possible to solve the problem of unconfirmed payments. Specifically, he was referring to the case where Alice resends her unconfirmed payment. He believes that an attack aimed at replacing a transaction without paying fees would be just as vulnerable as not having any protection in place at all. Todd suggests that solving this issue may not be of great importance and could be tolerated. Russell O'Connor had asked Todd for clarification on whether he meant there was a specific problem with a proposal to replace transactions when offered a new transaction whose fee rate exceeds the package fee rate of the original transaction or if there was another issue he foresees.On February 14, 2018, a discussion took place on the bitcoin-dev mailing list regarding the computation. 2018-03-09T18:40:34+00:00 + The email thread on the bitcoin-dev mailing list discusses the relaxation of some of the Denial of Service (DoS) prevention rules to open up more use cases and adoption. The issue of institutional wallets sweeping incoming payments and sweeping unconfirmed outputs is raised, but it is believed that this behavior is unintentional. It is suggested that if people start using the new replacement behavior, then institutions doing these sweeps may stop doing it. The development of a reasonable standard Replace-by-Fee (RBF) policy that aligns with miner incentives is discussed as miners prefer transactions with higher package fee rates. The weakening of DoS protections is not considered a huge problem, and it is proposed to try relaxing some of the rules in a release and see what happens.In a discussion about Bitcoin's Replace-by-Fee (RBF) policy, Russell O'Connor suggested that replaced transactions should require a fee increase of at least the min-fee-rate times the size of all the transactions being ejected. Peter Todd raised concerns about weakening anti-DoS protections, but O'Connor clarified that he was not suggesting removing them entirely. The issue of institutional wallets sweeping unconfirmed outputs was also discussed as they seem to be happy to sweep unconfirmed outputs, which is potentially problematic. Additionally, there was a discussion about miner incentives and developing a reasonable standard RBF policy that aligns with those incentives. There was some disagreement about whether miners and full nodes have slightly different priorities. Nonetheless, Todd agreed to try the new replacement behavior in a release and see what happens. If people use this new replacement behavior, it may discourage institutions from sweeping unconfirmed outputs, which can be dangerous in reorgs.Peter Todd and Russell O'Connor were discussing the proposed change in RBF policy. Peter Todd pointed out that replacing a transaction without paying fees is identical to what an attacker is trying to do, making any such scheme vulnerable to attack. Russell argued that the current policy is problematic in practice where normal transactions are being performed and no one is attacking each other. However, Peter countered that the argument is not valid as normal users creating issues has nothing to do with relaxing anti-DoS protections. He suggested that replaced transactions require a fee increase of at least min-fee-rate times the size of all the transactions being ejected (in addition to the other proposed requirements). Moreover, Peter questioned how often non-attacking users face issues, but Russell pointed out that institutional wallets sweeping incoming payments regularly cause this problem. They also discussed miners' preference for higher package fee rates regardless of personal preferred RBF policies, making it important to develop a reasonable standard RBF policy that aligns with miner incentives and is robust against possible DoS vectors. This change in RBF policy can partially mitigate the problem of pinned transactions.Russell O'Connor proposed a change in RBF policy, but Peter Todd argued that solving this problem is impossible because it opens up an attack by relaxing anti-DoS protections. Todd stated that normal users creating issues does not happen often and can be avoided by skipping the use of RBF replacements if someone spends an unconfirmed output that was sent to them. He also pointed out that the argument of normal users not attacking each other has nothing to do with the issue at hand and that any protection scheme will be as vulnerable to attack as not having protection in the first place. Ultimately, Todd suggested that the attack may not be important enough to matter.In an email exchange, Peter Todd and Russell O'Connor discussed the possibility of solving the problem of replacing transactions that have been offered a new transaction with a higher fee rate. Todd expressed his belief that it is not possible to solve this issue because someone has already consumed network bandwidth that should be paid for with fees. He stated that any attempt to replace a transaction without paying those fees would be vulnerable to attack and likened it to what an attacker would try to do. However, he did mention that if the attack isn't significant enough, it may not matter. O'Connor agreed with Todd's assessment but still believes that pursuing the proposed change in Replace-by-Fee (RBF) policy is worthwhile as the current policy is problematic in practice for normal transactions.In a discussion on the Bitcoin Development mailing list, Peter Todd expressed his opinion that it is not possible to solve the problem of unconfirmed payments. Specifically, he was referring to the case where Alice resends her unconfirmed payment. He believes that an attack aimed at replacing a transaction without paying fees would be just as vulnerable as not having any protection in place at all. Todd suggests that solving this issue may not be of great importance and could be tolerated. Russell O'Connor had asked Todd for clarification on whether he meant there was a specific problem with a proposal to replace transactions when offered a new transaction whose fee rate exceeds the package fee rate of the original transaction or if there was another issue he foresees.On February 14, 2018, a discussion took place on the bitcoin-dev mailing list regarding the computation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_Simple-lock-unlock-mechanism.xml b/static/bitcoin-dev/March_2018/combined_Simple-lock-unlock-mechanism.xml index 7340d0bdfe..51d291dce9 100644 --- a/static/bitcoin-dev/March_2018/combined_Simple-lock-unlock-mechanism.xml +++ b/static/bitcoin-dev/March_2018/combined_Simple-lock-unlock-mechanism.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Simple lock/unlock mechanism - 2023-08-01T22:45:54.958542+00:00 - - アルム　カールヨハン 2018-03-05 14:53:16+00:00 - - - アルム　カールヨハン 2018-03-01 05:11:54+00:00 - - - Adam Back 2018-02-28 23:36:05+00:00 - - - Anthony Towns 2018-02-28 22:30:44+00:00 - - - アルム　カールヨハン 2018-02-28 04:34:18+00:00 - - - アルム　カールヨハン 2018-02-28 03:47:29+00:00 - + 2025-09-26T15:33:51.202823+00:00 + python-feedgen + + + [bitcoin-dev] Simple lock/unlock mechanism アルム　カールヨハン + 2018-02-28T03:47:00.000Z + + + アルム　カールヨハン + 2018-02-28T04:34:00.000Z + + + Anthony Towns + 2018-02-28T22:30:00.000Z + + + Adam Back + 2018-02-28T23:36:00.000Z + + + アルム　カールヨハン + 2018-03-01T05:11:00.000Z + + + アルム　カールヨハン + 2018-03-05T14:53:00.000Z + + - python-feedgen + 2 Combined summary - Simple lock/unlock mechanism - 2023-08-01T22:45:54.958542+00:00 + 2025-09-26T15:33:51.203657+00:00 - In an email conversation, a user named Kalle expressed confusion about the use of graftroot in relation to multisig and freezing. Another user had suggested that using multisig would be simpler than freezing coins, but Kalle pointed out that both methods require both signatories to access the coins, and graftroot can override CLTV. Kalle also noted that graftroot requires a pubkey instead of a p2sh format.Discussions within the bitcoin-dev community are centered around the possibility of a software-only time-lock vault. Concerns have been raised about Graftroot potentially breaking the system if someone signs a time-locked output with a script that has no time-lock. To address this, some propose using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. However, others argue that this defeats the purpose and suggest using multisig instead and skipping the freezing process altogether. Adam Back suggests a method involving a CSV timelock, deleting one private key after broadcasting, and using graftroot and another privkey to spend the coins. But this approach has the drawback of the robber forcing the user to execute a step. It is suggested to include as part of 'freezing' a send to a new ephemeral key as 'initialization'. A simpler model would involve a third party refusing to co-sign until a pre-arranged time, avoiding the need for two on-chain transactions. Some users are seeking an easy way to lock up a significant portion of their coins. A security firm could offer a service where unexpected unfreeze transactions trigger an alarm.In a recent discussion on bitcoin-dev, Kalle proposed a software-only time-lock vault. Another participant mentioned that Root compatibility wouldn't be an issue if the key is deleted and delegated signatures cannot bypass the CSV timeout restriction. However, marking keys as Rootable vs not in a sighash sense could lead to privacy/fungibility loss. One drawback of this proposal is the difficulty in assuring key deletion with HD wallet seeds setup-time backup model.Anthony suggests a simpler model where a third party refuses to co-sign until a pre-arranged time, eliminating the need for two on-chain transactions. With bulletproofs and CT rangeproofs / general ECDL ZKPS, it's possible to prove things about private keys or hidden attributes of public keys without disclosing them. Private key covenants could be used to prove that certain conditions are met without revealing them.To address Kalle's concern about graftroot breaking the time-lock function, Anthony suggests using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. Increasing it to 3-of-3 or 5-of-5 could be even better if multiple independent services support it.A member of the Bitcoin development community has raised concerns about Graftroot potentially allowing someone to sign a time-locked output without a time-lock script. To prevent this, it has been suggested to use a 2-of-2 muSig with an independent third party that only signs CLTV scripts. It may also be possible to increase the number of required signatures to enhance security.Kalle recently proposed the idea of locking up bitcoin with an "OP_CSV" attached to it. The concept involves creating a transaction that spends UTXOs to a P2SH address and then discarding the private keys. To spend the bitcoin, the transaction must be broadcasted and a specified amount of time must pass before using the new txout. Kalle suggests Bitcoin Core could introduce "freeze" and "unfreeze" commands to facilitate this process. The "freeze" command would lock a certain amount of bitcoin for a given number of days, while the "unfreeze" command would list all frozen transactions and allow users to unfreeze specific ones. This locking system could disincentivize potential robbers, but there may be issues with high transaction fees and stuck transactions.In summary, discussions within the bitcoin-dev community revolve around the use of graftroot, multisig, and freezing to enhance security in Bitcoin transactions. There are proposals for a software-only time-lock vault and suggestions for addressing potential issues with graftroot. Additionally, Kalle's idea of locking up bitcoin with an "OP_CSV" has been discussed, along with the introduction of new commands in Bitcoin Core. These developments aim to prevent physical thefts of cryptocurrencies but come with their own challenges. 2018-03-05T14:53:16+00:00 + In an email conversation, a user named Kalle expressed confusion about the use of graftroot in relation to multisig and freezing. Another user had suggested that using multisig would be simpler than freezing coins, but Kalle pointed out that both methods require both signatories to access the coins, and graftroot can override CLTV. Kalle also noted that graftroot requires a pubkey instead of a p2sh format.Discussions within the bitcoin-dev community are centered around the possibility of a software-only time-lock vault. Concerns have been raised about Graftroot potentially breaking the system if someone signs a time-locked output with a script that has no time-lock. To address this, some propose using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. However, others argue that this defeats the purpose and suggest using multisig instead and skipping the freezing process altogether. Adam Back suggests a method involving a CSV timelock, deleting one private key after broadcasting, and using graftroot and another privkey to spend the coins. But this approach has the drawback of the robber forcing the user to execute a step. It is suggested to include as part of 'freezing' a send to a new ephemeral key as 'initialization'. A simpler model would involve a third party refusing to co-sign until a pre-arranged time, avoiding the need for two on-chain transactions. Some users are seeking an easy way to lock up a significant portion of their coins. A security firm could offer a service where unexpected unfreeze transactions trigger an alarm.In a recent discussion on bitcoin-dev, Kalle proposed a software-only time-lock vault. Another participant mentioned that Root compatibility wouldn't be an issue if the key is deleted and delegated signatures cannot bypass the CSV timeout restriction. However, marking keys as Rootable vs not in a sighash sense could lead to privacy/fungibility loss. One drawback of this proposal is the difficulty in assuring key deletion with HD wallet seeds setup-time backup model.Anthony suggests a simpler model where a third party refuses to co-sign until a pre-arranged time, eliminating the need for two on-chain transactions. With bulletproofs and CT rangeproofs / general ECDL ZKPS, it's possible to prove things about private keys or hidden attributes of public keys without disclosing them. Private key covenants could be used to prove that certain conditions are met without revealing them.To address Kalle's concern about graftroot breaking the time-lock function, Anthony suggests using a 2-of-2 muSig with an independent third party that only signs CLTV scripts. Increasing it to 3-of-3 or 5-of-5 could be even better if multiple independent services support it.A member of the Bitcoin development community has raised concerns about Graftroot potentially allowing someone to sign a time-locked output without a time-lock script. To prevent this, it has been suggested to use a 2-of-2 muSig with an independent third party that only signs CLTV scripts. It may also be possible to increase the number of required signatures to enhance security.Kalle recently proposed the idea of locking up bitcoin with an "OP_CSV" attached to it. The concept involves creating a transaction that spends UTXOs to a P2SH address and then discarding the private keys. To spend the bitcoin, the transaction must be broadcasted and a specified amount of time must pass before using the new txout. Kalle suggests Bitcoin Core could introduce "freeze" and "unfreeze" commands to facilitate this process. The "freeze" command would lock a certain amount of bitcoin for a given number of days, while the "unfreeze" command would list all frozen transactions and allow users to unfreeze specific ones. This locking system could disincentivize potential robbers, but there may be issues with high transaction fees and stuck transactions.In summary, discussions within the bitcoin-dev community revolve around the use of graftroot, multisig, and freezing to enhance security in Bitcoin transactions. There are proposals for a software-only time-lock vault and suggestions for addressing potential issues with graftroot. Additionally, Kalle's idea of locking up bitcoin with an "OP_CSV" has been discussed, along with the introduction of new commands in Bitcoin Core. These developments aim to prevent physical thefts of cryptocurrencies but come with their own challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_Soft-Fork-Activation-Enforcement-w-o-Signaling-.xml b/static/bitcoin-dev/March_2018/combined_Soft-Fork-Activation-Enforcement-w-o-Signaling-.xml index 653f9e5fbf..3b60a37b13 100644 --- a/static/bitcoin-dev/March_2018/combined_Soft-Fork-Activation-Enforcement-w-o-Signaling-.xml +++ b/static/bitcoin-dev/March_2018/combined_Soft-Fork-Activation-Enforcement-w-o-Signaling-.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Soft Fork Activation & Enforcement w/o Signaling? - 2023-08-01T22:50:18.782960+00:00 - - Jorge Timón 2018-03-30 20:52:50+00:00 - - - Samad Sajanlal 2018-03-29 05:14:42+00:00 - - - Jorge Timón 2018-03-28 12:55:26+00:00 - - - Samad Sajanlal 2018-03-21 22:04:35+00:00 - + 2025-09-26T15:33:59.613800+00:00 + python-feedgen + + + [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling? Samad Sajanlal + 2018-03-21T22:04:00.000Z + + + Jorge Timón + 2018-03-28T12:55:00.000Z + + + Samad Sajanlal + 2018-03-29T05:14:00.000Z + + + Jorge Timón + 2018-03-30T20:52:00.000Z + + - python-feedgen + 2 Combined summary - Soft Fork Activation & Enforcement w/o Signaling? - 2023-08-01T22:50:18.782960+00:00 + 2025-09-26T15:33:59.614425+00:00 - A developer inquired about the possibility of activating soft forks, such as BIP65 and BIP66, without prior signaling from miners. He noted that his project is a clone of a clone of Bitcoin that did not and never intends to replace Bitcoin. The whole network will upgrade their clients within a short window (~2 weeks), so they would schedule the activation ~2 months out from when the client is released to ensure everyone has time to upgrade.The developer is trying to bring the code branch up to 0.15 at least, so that they can implement Segwit and other key features that Bitcoin has introduced. He also asked if the block version gets bumped up automatically at the time that a soft fork activates or if there is additional stuff that he needs to do within the code to ensure it bumps up at the same time.Jorge Timón responded, stating that softforks can be activated at a given height and he didn't see any reason why they couldn't rebase to 0.16 directly. He also mentioned that the block version bumping was a mistake in bip34 and the developer doesn't really need to bump the version number. Jorge recommended reading bip34 and what it activates in the code, recalling that the last thing was bip65. The current deployed codebase (based on bitcoin 0.9.4) makes versions 0x00000002 (as seen by a 0.15 client), whereas 0.15 and 0.16 use block versions as 0x20000000. Therefore, it appears safe to activate soft forks which require a minimum of version 3 and 4 blocks (0x00000003 and 0x00000004, respectively) without any signaling beforehand. Activating them will segregate the 0.15 clients onto their own fork, which is why the repercussions of doing it without any signaling beforehand must be understood. The block version will bump up automatically at the time that a soft fork activates.In a discussion on the bitcoin-dev mailing list, Samad Sajanlal asked if it is possible to activate soft forks such as BIP65 and BIP66 without prior signaling from miners. He noticed in chainparams.cpp that there are block heights where the enforcement begins. Samad is working on a project that is a clone of a clone of bitcoin, and they currently do not have BIP65 or BIP66 enforced - no signaling of these soft forks either. Samad wanted to know if the entire network upgrades to the correct version of the software (based on bitcoin 0.15), which includes the block height that has enforcement, can they simply skip over the signaling and go straight into activation/enforcement.In response, an intelligent assistant stated that it is possible to activate softforks at a given height. The block version bumping was a mistake in bip34, so there is no need to bump the version number. The assistant recommended reading bip34 and what it activates in the code. The last thing that was activated was bip65. The assistant also mentioned that the repercussions of activating the soft forks without any signaling beforehand would segregate the 0.15 clients onto their own fork.Samad also asked another related question - does the block version get bumped up automatically at the time that a soft fork activates, or is there additional stuff that needs to be done within the code to ensure it bumps up at the same time? From what Samad saw in the code, it appears that it will bump up automatically, but he wanted some confirmation on that.The author is seeking advice on whether it is possible to activate soft forks like BIP65 and BIP66 without prior signaling from miners. They are working on a project that is a clone of a clone of Bitcoin, which currently does not have BIP65 or BIP66 enforced - no signaling of these soft forks either. The project aims to bring the code branch up to 0.15 so that they can implement Segwit and other key features introduced by Bitcoin. However, activating soft forks will segregate the 0.15 clients onto their own fork.The author wants to know if they can skip over signaling and go straight into activation/enforcement if the entire network upgrades to the correct version of the software based on Bitcoin 0.15, which includes the block height that has enforcement. As their network is very small, it is reasonable to assume that the whole network will upgrade their clients within a short window (~2 weeks). The author would schedule the activation ~2 months out from when the client is released to ensure everyone has time to upgrade.The author also asks if the block version gets bumped up automatically at the time that a soft fork activates or if there is additional stuff that needs to be done within the code to ensure it bumps up at the same time. From what the author saw in the code, it appears that it will bump up automatically, but they would like 2018-03-30T20:52:50+00:00 + A developer inquired about the possibility of activating soft forks, such as BIP65 and BIP66, without prior signaling from miners. He noted that his project is a clone of a clone of Bitcoin that did not and never intends to replace Bitcoin. The whole network will upgrade their clients within a short window (~2 weeks), so they would schedule the activation ~2 months out from when the client is released to ensure everyone has time to upgrade.The developer is trying to bring the code branch up to 0.15 at least, so that they can implement Segwit and other key features that Bitcoin has introduced. He also asked if the block version gets bumped up automatically at the time that a soft fork activates or if there is additional stuff that he needs to do within the code to ensure it bumps up at the same time.Jorge Timón responded, stating that softforks can be activated at a given height and he didn't see any reason why they couldn't rebase to 0.16 directly. He also mentioned that the block version bumping was a mistake in bip34 and the developer doesn't really need to bump the version number. Jorge recommended reading bip34 and what it activates in the code, recalling that the last thing was bip65. The current deployed codebase (based on bitcoin 0.9.4) makes versions 0x00000002 (as seen by a 0.15 client), whereas 0.15 and 0.16 use block versions as 0x20000000. Therefore, it appears safe to activate soft forks which require a minimum of version 3 and 4 blocks (0x00000003 and 0x00000004, respectively) without any signaling beforehand. Activating them will segregate the 0.15 clients onto their own fork, which is why the repercussions of doing it without any signaling beforehand must be understood. The block version will bump up automatically at the time that a soft fork activates.In a discussion on the bitcoin-dev mailing list, Samad Sajanlal asked if it is possible to activate soft forks such as BIP65 and BIP66 without prior signaling from miners. He noticed in chainparams.cpp that there are block heights where the enforcement begins. Samad is working on a project that is a clone of a clone of bitcoin, and they currently do not have BIP65 or BIP66 enforced - no signaling of these soft forks either. Samad wanted to know if the entire network upgrades to the correct version of the software (based on bitcoin 0.15), which includes the block height that has enforcement, can they simply skip over the signaling and go straight into activation/enforcement.In response, an intelligent assistant stated that it is possible to activate softforks at a given height. The block version bumping was a mistake in bip34, so there is no need to bump the version number. The assistant recommended reading bip34 and what it activates in the code. The last thing that was activated was bip65. The assistant also mentioned that the repercussions of activating the soft forks without any signaling beforehand would segregate the 0.15 clients onto their own fork.Samad also asked another related question - does the block version get bumped up automatically at the time that a soft fork activates, or is there additional stuff that needs to be done within the code to ensure it bumps up at the same time? From what Samad saw in the code, it appears that it will bump up automatically, but he wanted some confirmation on that.The author is seeking advice on whether it is possible to activate soft forks like BIP65 and BIP66 without prior signaling from miners. They are working on a project that is a clone of a clone of Bitcoin, which currently does not have BIP65 or BIP66 enforced - no signaling of these soft forks either. The project aims to bring the code branch up to 0.15 so that they can implement Segwit and other key features introduced by Bitcoin. However, activating soft forks will segregate the 0.15 clients onto their own fork.The author wants to know if they can skip over signaling and go straight into activation/enforcement if the entire network upgrades to the correct version of the software based on Bitcoin 0.15, which includes the block height that has enforcement. As their network is very small, it is reasonable to assume that the whole network will upgrade their clients within a short window (~2 weeks). The author would schedule the activation ~2 months out from when the client is released to ensure everyone has time to upgrade.The author also asks if the block version gets bumped up automatically at the time that a soft fork activates or if there is additional stuff that needs to be done within the code to ensure it bumps up at the same time. From what the author saw in the code, it appears that it will bump up automatically, but they would like - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_Soft-forks-and-schnorr-signature-aggregation.xml b/static/bitcoin-dev/March_2018/combined_Soft-forks-and-schnorr-signature-aggregation.xml index 5f95080bbb..d783b6c64d 100644 --- a/static/bitcoin-dev/March_2018/combined_Soft-forks-and-schnorr-signature-aggregation.xml +++ b/static/bitcoin-dev/March_2018/combined_Soft-forks-and-schnorr-signature-aggregation.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Soft-forks and schnorr signature aggregation - 2023-08-01T22:49:43.596054+00:00 - - Bram Cohen 2018-03-28 03:19:48+00:00 - - - Anthony Towns 2018-03-27 06:34:33+00:00 - - - Bram Cohen 2018-03-22 00:47:01+00:00 - - - ZmnSCPxj at protonmail.com 2018-03-21 23:28:00+00:00 - - - Andrew Poelstra 2018-03-21 12:45:21+00:00 - - - Anthony Towns 2018-03-21 11:21:19+00:00 - - - ZmnSCPxj 2018-03-21 07:53:59+00:00 - - - Anthony Towns 2018-03-21 04:06:18+00:00 - + 2025-09-26T15:34:01.730654+00:00 + python-feedgen + + + [bitcoin-dev] Soft-forks and schnorr signature aggregation Anthony Towns + 2018-03-21T04:06:00.000Z + + + ZmnSCPxj + 2018-03-21T07:53:00.000Z + + + Anthony Towns + 2018-03-21T11:21:00.000Z + + + Andrew Poelstra + 2018-03-21T12:45:00.000Z + + + ZmnSCPxj + 2018-03-21T23:28:00.000Z + + + Bram Cohen + 2018-03-22T00:47:00.000Z + + + Anthony Towns + 2018-03-27T06:34:00.000Z + + + Bram Cohen + 2018-03-28T03:19:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Soft-forks and schnorr signature aggregation - 2023-08-01T22:49:43.596054+00:00 + 2025-09-26T15:34:01.731681+00:00 - Bitcoin developers are currently discussing the possibility of reclaiming unused opcodes in the software's scripting language and repurposing them as RETURN_VALID. This proposal, suggested by Bram Cohen, aims to simplify scripts and save bytes. While there is some agreement on this idea, there is a debate over whether to keep just one OP_NOP or not.One of the main challenges in implementing this change is dealing with unknown opcodes being parsed in unexecuted sections of code. Several options were discussed, including causing a RETURN_VALID at parse time, exterminating IF and MASTing, adding IFJUMP, IFNJUMP, and JUMP opcodes, or requiring new opcodes to have fixed length 1.The discussion also touched on the implementation of multisig opcodes. Cohen suggested using MAST as an elegant solution for a large number of possibilities, while others proposed more complex formulas for combining signatures.Another topic of discussion was signature aggregation in Bitcoin. Developers explored the concept of gathering public keys for aggregate signature checking instead of individual signatures. However, reconciling script with signature aggregation was noted as a difficulty, especially in terms of transaction-level aggregate differences between pre-fork and post-fork nodes.In a separate email thread, Anthony Towns proposed focusing on Schnorr signatures, Taproot, MAST, and re-enabling opcodes rather than interactive signature aggregation. The complexity of signature aggregation, particularly its impact on blind signature protocols, was highlighted by Andrew Poelstra. Poelstra suggests that zero-knowledge proofs could be used to address the issue.In another email conversation, Zeeman suggested a simplified solution for aggregated signatures using dedicated opcodes. AJ explained that checking gathered public keys only happens at the transaction level, making additional opcodes unnecessary in scripts. AJ also mentioned the importance of cross-input signature aggregation and the Bellare-Neven verification algorithm.To implement both signature aggregation and RETURN_VALID together, various solutions were discussed. These included carefully writing scripts, using dedicated opcodes, or employing a Merkleized Abstract Syntax Tree (MAST). The use of separate buckets for independent signature generation and verification was also explored.Soft-forking new opcodes presents challenges, particularly in validating new classes of addresses with existing nodes. The use of RETURN_VALID opcodes was suggested as an alternative solution, allowing for any behavior. However, caution is needed to ensure compatibility and avoid hard forks.Overall, the proposed solutions aim to make signature aggregation possible while maintaining compatibility with the existing Bitcoin infrastructure. Bitcoin Core developers are considering introducing a new segwit witness version (v2) that supports Schnorr signatures, MAST scripts, and has specific opcodes for aggregating signatures. A config setting will be maintained to allow users to prevent a hard fork until the next release after activation. 2018-03-28T03:19:48+00:00 + Bitcoin developers are currently discussing the possibility of reclaiming unused opcodes in the software's scripting language and repurposing them as RETURN_VALID. This proposal, suggested by Bram Cohen, aims to simplify scripts and save bytes. While there is some agreement on this idea, there is a debate over whether to keep just one OP_NOP or not.One of the main challenges in implementing this change is dealing with unknown opcodes being parsed in unexecuted sections of code. Several options were discussed, including causing a RETURN_VALID at parse time, exterminating IF and MASTing, adding IFJUMP, IFNJUMP, and JUMP opcodes, or requiring new opcodes to have fixed length 1.The discussion also touched on the implementation of multisig opcodes. Cohen suggested using MAST as an elegant solution for a large number of possibilities, while others proposed more complex formulas for combining signatures.Another topic of discussion was signature aggregation in Bitcoin. Developers explored the concept of gathering public keys for aggregate signature checking instead of individual signatures. However, reconciling script with signature aggregation was noted as a difficulty, especially in terms of transaction-level aggregate differences between pre-fork and post-fork nodes.In a separate email thread, Anthony Towns proposed focusing on Schnorr signatures, Taproot, MAST, and re-enabling opcodes rather than interactive signature aggregation. The complexity of signature aggregation, particularly its impact on blind signature protocols, was highlighted by Andrew Poelstra. Poelstra suggests that zero-knowledge proofs could be used to address the issue.In another email conversation, Zeeman suggested a simplified solution for aggregated signatures using dedicated opcodes. AJ explained that checking gathered public keys only happens at the transaction level, making additional opcodes unnecessary in scripts. AJ also mentioned the importance of cross-input signature aggregation and the Bellare-Neven verification algorithm.To implement both signature aggregation and RETURN_VALID together, various solutions were discussed. These included carefully writing scripts, using dedicated opcodes, or employing a Merkleized Abstract Syntax Tree (MAST). The use of separate buckets for independent signature generation and verification was also explored.Soft-forking new opcodes presents challenges, particularly in validating new classes of addresses with existing nodes. The use of RETURN_VALID opcodes was suggested as an alternative solution, allowing for any behavior. However, caution is needed to ensure compatibility and avoid hard forks.Overall, the proposed solutions aim to make signature aggregation possible while maintaining compatibility with the existing Bitcoin infrastructure. Bitcoin Core developers are considering introducing a new segwit witness version (v2) that supports Schnorr signatures, MAST scripts, and has specific opcodes for aggregating signatures. A config setting will be maintained to allow users to prevent a hard fork until the next release after activation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_feature-Enhance-privacy-by-change-obfuscation.xml b/static/bitcoin-dev/March_2018/combined_feature-Enhance-privacy-by-change-obfuscation.xml index 782bcb1b9c..6d3ed71307 100644 --- a/static/bitcoin-dev/March_2018/combined_feature-Enhance-privacy-by-change-obfuscation.xml +++ b/static/bitcoin-dev/March_2018/combined_feature-Enhance-privacy-by-change-obfuscation.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - feature: Enhance privacy by change obfuscation - 2023-08-01T22:49:09.755739+00:00 - - Damian Williamson 2018-04-01 14:37:13+00:00 - - - Eric Voskuil 2018-03-18 18:59:28+00:00 - - - Damian Williamson 2018-03-18 07:07:58+00:00 - - - Evan Klitzke 2018-03-18 05:50:34+00:00 - - - Damian Williamson 2018-03-18 01:34:20+00:00 - + 2025-09-26T15:33:42.821582+00:00 + python-feedgen + + + [bitcoin-dev] feature: Enhance privacy by change obfuscation Damian Williamson + 2018-03-18T01:34:00.000Z + + + Evan Klitzke + 2018-03-18T05:50:00.000Z + + + Damian Williamson + 2018-03-18T07:07:00.000Z + + + Eric Voskuil + 2018-03-18T18:59:00.000Z + + + Damian Williamson + 2018-04-01T14:37:00.000Z + + - python-feedgen + 2 Combined summary - feature: Enhance privacy by change obfuscation - 2023-08-01T22:49:09.756739+00:00 + 2025-09-26T15:33:42.822198+00:00 - Electrum version 3.0.6 now offers a new option for multiple change addresses, although it is not enabled by default. Eric Voskuil responded to a proposal regarding privacy enhancement through change obfuscation by clarifying a misconception about the cost of unspent outputs. He explained that the perceived increase in cost is not necessary and arises from specific node software implementations.There is a common belief that the count of unspent outputs in a network leads to higher costs due to the bloat in UTXO size. However, this belief is inaccurate, as the additional cost is not required but rather a result of implementation details in certain node software. Redundant indexing of unspent outputs is unnecessary, meaning not everyone has to bear the cost.In a Bitcoin-dev thread, Damian Williamson proposed a feature called change obfuscation to enhance transaction privacy. The idea was to randomly distribute change across up to twenty output addresses, ensuring each output is not dust. However, Evan Klitzke pointed out that this approach would be costly for the network due to the increased UTXO size. Moreover, it may not provide the desired level of privacy, since the wallet would need to combine those inputs in future transactions, resulting in higher transaction fees. Despite understanding the additional cost, Klitzke did not support the suggestion.In response to Williamson's proposal, an "Enhanced privacy" option was introduced in Bitcoin Core for transaction creation. This feature allows users to distribute change randomly across up to twenty output addresses (with a minimum of five), as long as each output is not dust. It is recommended to limit the total number of random addresses based on the change amount. If additional inputs are available, they can be selected to increase the change, although this may reduce obfuscation when the outputs are spent. However, the initial spend with change will have a higher transaction cost due to increased outputs, and subsequent spending of the change will depend on the future spend amount(s) and the number of inputs required.Although there is still a possibility of transaction linkage, guessing what was retained by the owner of the original utxo's becomes more challenging unless the new change outputs are spent together in the same transaction. Ultimately, the "Enhanced privacy" option significantly improves privacy for Bitcoin Core users. 2018-04-01T14:37:13+00:00 + Electrum version 3.0.6 now offers a new option for multiple change addresses, although it is not enabled by default. Eric Voskuil responded to a proposal regarding privacy enhancement through change obfuscation by clarifying a misconception about the cost of unspent outputs. He explained that the perceived increase in cost is not necessary and arises from specific node software implementations.There is a common belief that the count of unspent outputs in a network leads to higher costs due to the bloat in UTXO size. However, this belief is inaccurate, as the additional cost is not required but rather a result of implementation details in certain node software. Redundant indexing of unspent outputs is unnecessary, meaning not everyone has to bear the cost.In a Bitcoin-dev thread, Damian Williamson proposed a feature called change obfuscation to enhance transaction privacy. The idea was to randomly distribute change across up to twenty output addresses, ensuring each output is not dust. However, Evan Klitzke pointed out that this approach would be costly for the network due to the increased UTXO size. Moreover, it may not provide the desired level of privacy, since the wallet would need to combine those inputs in future transactions, resulting in higher transaction fees. Despite understanding the additional cost, Klitzke did not support the suggestion.In response to Williamson's proposal, an "Enhanced privacy" option was introduced in Bitcoin Core for transaction creation. This feature allows users to distribute change randomly across up to twenty output addresses (with a minimum of five), as long as each output is not dust. It is recommended to limit the total number of random addresses based on the change amount. If additional inputs are available, they can be selected to increase the change, although this may reduce obfuscation when the outputs are spent. However, the initial spend with change will have a higher transaction cost due to increased outputs, and subsequent spending of the change will depend on the future spend amount(s) and the number of inputs required.Although there is still a possibility of transaction linkage, guessing what was retained by the owner of the original utxo's becomes more challenging unless the new change outputs are spent together in the same transaction. Ultimately, the "Enhanced privacy" option significantly improves privacy for Bitcoin Core users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2018/combined_version-relay-behavior-change.xml b/static/bitcoin-dev/March_2018/combined_version-relay-behavior-change.xml index 737d72e240..b4a96fe095 100644 --- a/static/bitcoin-dev/March_2018/combined_version-relay-behavior-change.xml +++ b/static/bitcoin-dev/March_2018/combined_version-relay-behavior-change.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - version.relay behavior change - 2023-08-01T22:47:12.642590+00:00 - - Eric Voskuil 2018-03-16 08:27:47+00:00 - - - Andrew Chow 2018-03-15 15:44:43+00:00 - - - Eric Voskuil 2018-03-15 09:17:22+00:00 - - - Andrew Chow 2018-03-09 15:33:32+00:00 - - - Eric Voskuil 2018-03-09 07:50:02+00:00 - + 2025-09-26T15:33:55.405191+00:00 + python-feedgen + + + [bitcoin-dev] version.relay behavior change Eric Voskuil + 2018-03-09T07:50:00.000Z + + + Andrew Chow + 2018-03-09T15:33:00.000Z + + + Eric Voskuil + 2018-03-15T09:17:00.000Z + + + Andrew Chow + 2018-03-15T15:44:00.000Z + + + Eric Voskuil + 2018-03-16T08:27:00.000Z + + - python-feedgen + 2 Combined summary - version.relay behavior change - 2023-08-01T22:47:12.642590+00:00 + 2025-09-26T15:33:55.405923+00:00 - In a recent discussion on the bitcoin-dev mailing list, Eric Voskuil raised concerns about nodes that no longer seem to be honoring the version.relay=false flag (BIP37) in /Satoshi:0.15.0/ and later versions of Bitcoin Core. Andrew Chow responded, suggesting that these nodes may not actually be forked from Bitcoin Core, but rather fake nodes that do not follow the protocol or perform verification. These fake nodes can set any user agent they want, including Bitcoin Core's user agents. Despite reviewing the relevant Core sources and syncing against a Core node locally, Voskuil still suspects that this behavior is related to Core, as it is very common and all user agents are consistent.Voskuil does not see any issues with Core sources or his own flag and version settings. However, he has previously dropped peers for noncompliance with the protocol and is considering reinstating this behavior. It is unclear whether this behavior is intentional or a bug, and specific details on how to reproduce the issue have been requested.In summary, Eric Voskuil reported on the bitcoin-dev mailing list that nodes running /Satoshi:0.15.0/ and later versions are not honoring the version.relay=false flag (BIP37). Andrew Chow suggested that these nodes may be fake and not actually connected to Bitcoin Core, while Voskuil suspects that the behavior is related to Core due to its commonness and consistent user agents. The cause of this behavior, whether intentional or a bug, remains unclear, and further details have been requested to reproduce the issue. 2018-03-16T08:27:47+00:00 + In a recent discussion on the bitcoin-dev mailing list, Eric Voskuil raised concerns about nodes that no longer seem to be honoring the version.relay=false flag (BIP37) in /Satoshi:0.15.0/ and later versions of Bitcoin Core. Andrew Chow responded, suggesting that these nodes may not actually be forked from Bitcoin Core, but rather fake nodes that do not follow the protocol or perform verification. These fake nodes can set any user agent they want, including Bitcoin Core's user agents. Despite reviewing the relevant Core sources and syncing against a Core node locally, Voskuil still suspects that this behavior is related to Core, as it is very common and all user agents are consistent.Voskuil does not see any issues with Core sources or his own flag and version settings. However, he has previously dropped peers for noncompliance with the protocol and is considering reinstating this behavior. It is unclear whether this behavior is intentional or a bug, and specific details on how to reproduce the issue have been requested.In summary, Eric Voskuil reported on the bitcoin-dev mailing list that nodes running /Satoshi:0.15.0/ and later versions are not honoring the version.relay=false flag (BIP37). Andrew Chow suggested that these nodes may be fake and not actually connected to Bitcoin Core, while Voskuil suspects that the behavior is related to Core due to its commonness and consistent user agents. The cause of this behavior, whether intentional or a bug, remains unclear, and further details have been requested to reproduce the issue. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_BIP-Proposal-The-Great-Consensus-Cleanup.xml b/static/bitcoin-dev/March_2019/combined_BIP-Proposal-The-Great-Consensus-Cleanup.xml index a9c48356c8..d187f54eea 100644 --- a/static/bitcoin-dev/March_2019/combined_BIP-Proposal-The-Great-Consensus-Cleanup.xml +++ b/static/bitcoin-dev/March_2019/combined_BIP-Proposal-The-Great-Consensus-Cleanup.xml @@ -1,27 +1,137 @@ - + 2 Combined summary - BIP Proposal: The Great Consensus Cleanup - 2023-08-02T00:35:59.132988+00:00 - - Matt Corallo 2019-03-07 19:44:23+00:00 - - - Luke Dashjr 2019-03-07 10:44:34+00:00 - - - Matt Corallo 2019-03-06 21:39:15+00:00 - + 2025-09-26T15:47:22.173721+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo + 2019-03-06T21:39:00.000Z + + + Luke Dashjr + 2019-03-07T10:44:00.000Z + + + [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor + 2019-03-07T15:03:00.000Z + + + [bitcoin-dev] Sighash Type Byte; " Russell O'Connor + 2019-03-07T15:16:00.000Z + + + Matt Corallo + 2019-03-07T19:44:00.000Z + + + Matt Corallo + 2019-03-07T19:50:00.000Z + + + Matt Corallo + 2019-03-07T19:57:00.000Z + + + Russell O'Connor + 2019-03-08T15:57:00.000Z + + + Russell O'Connor + 2019-03-08T15:57:00.000Z + + + Matt Corallo + 2019-03-08T18:35:00.000Z + + + Sjors Provoost + 2019-03-08T19:12:00.000Z + + + Matt Corallo + 2019-03-08T20:14:00.000Z + + + Russell O'Connor + 2019-03-09T18:29:00.000Z + + + Russell O'Connor + 2019-03-09T18:29:00.000Z + + + Jacob Eliosoff + 2019-03-10T03:25:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2019-03-10T14:25:00.000Z + + + Russell O'Connor + 2019-03-10T15:22:00.000Z + + + Moral Agent + 2019-03-10T18:24:00.000Z + + + Dustin Dettmer + 2019-03-10T18:28:00.000Z + + + Russell O'Connor + 2019-03-11T17:49:00.000Z + + + Russell O'Connor + 2019-03-11T19:15:00.000Z + + + Matt Corallo + 2019-03-12T02:23:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2019-03-12T07:34:00.000Z + + + Matt Corallo + 2019-03-12T21:08:00.000Z + + + Jacob Eliosoff + 2019-03-12T22:39:00.000Z + + + Gregory Maxwell + 2019-03-13T00:54:00.000Z + + + Russell O'Connor + 2019-03-13T01:34:00.000Z + + + Russell O'Connor + 2019-03-13T01:34:00.000Z + + + Russell O'Connor + 2019-03-13T01:38:00.000Z + + - python-feedgen + 2 Combined summary - BIP Proposal: The Great Consensus Cleanup - 2023-08-02T00:35:59.132988+00:00 + 2025-09-26T15:47:22.176660+00:00 - In an email exchange between Luke Dashjr and Matt Corallo, Matt requested the assignment of a BIP number for a proposed soft fork to improve Bitcoin's security. Luke suggested including a Backward Compatibility section and opening a bips repo PR after discussion on the ML. One of the proposed changes is making non-standard signature hash types invalid to limit the potential signature hashes used per-input and improve caching efficiency. Additionally, caching the just-before-the-last-byte sighash midstate and hashing only the last byte when checking signatures was suggested.Luke sought clarity on what exactly was being removed with regards to the spec change. He emphasized the importance of fixing the timewarp vulnerability, which could be exploited by miners to inflate the currency supply maliciously or create extension blocks through forking. Although extension blocks are generally discouraged, the arguments in favor of timewarp-based inter-block-time reductions also apply to extension blocks.The proposal states that transactions smaller than 65 bytes without witness data will now be considered invalid, and the rationale for this change will explain why the size doesn't count the witness. It is strongly recommended that SPV clients enforce the new nTime rules to avoid following potential forks since miners currently only enforce increasing timestamps against the median-timestamp-of-last-11-blocks.The proposal acknowledges that several early-stage proposals, such as Schnorr signatures, Taproot, Graftroot, and MAST, may affect script execution but are not expected to interact with the changes in this BIP as they are likely to only apply to SegWit scripts. The defined sighash type byte rule only applies to current signature-checking opcodes, as any new signature-checking is expected to be implemented through the introduction of new opcodes.Matt Corallo requested a BIP number for a proposed soft fork to enhance Bitcoin's security in a message on the Bitcoin Development mailing list. The proposal includes changes like making non-standard signature hash types invalid and enforcing strict rules on transaction timestamps to prevent time-warp attacks. It also notes that early-stage proposals such as Schnorr signatures, Taproot, Graftroot, and MAST are not expected to interact with the changes in this BIP. A Backward Compatibility section is needed, and a bips repo PR should be opened after discussion on the ML. The proposal recommends SPV clients enforce the new nTime rules to avoid following potential forks.The Great Consensus Cleanup is a Bitcoin Improvement Proposal (BIP) aiming to simplify Bitcoin implementations, improve validation times, and address various vulnerabilities. The proposal suggests allowing timestamps on difficulty-adjustment blocks to go backwards by 600 seconds, fixing the long-standing "timewarp" inflation vulnerability without rendering existing mining hardware unusable. It also proposes making certain transaction sizes invalid to resolve vulnerabilities related to malleation in merkle tree construction.The BIP will be deployed using "version bits" BIP9 with the name "cleanups," using bit 3 as the activation signal, with different start times for mainnet and testnet. However, it may result in the activation of the new soft-fork rules coinciding with the scheduled block-subsidy halving. The BIP author argues that fixing the timewarp vulnerability is crucial because exploiting it could lead to malicious inflation of the currency supply by miners or forking through extension blocks, which is not an ideal approach.Bitcoin Improvement Proposal 118 (BIP 118) proposes the activation of Taproot, a new address format and signature scheme aimed at improving privacy and flexibility of Bitcoin transactions. The proposal suggests using BIP 141 (Segregated Witness) and BIP 143 (Transaction Signature Verification for Version 0 Witness Program) as activation methods. It also includes changes like reducing valid scriptSigs to the minimal set of operations generating any stack state, disabling non-canonical sighash types, and allowing nTime to go backward by 600 seconds to prevent attacks and simplify analysis.The proposal mentions that several early-stage proposals, including Schnorr signatures, Taproot, Graftroot, and MAST, may affect script execution but are not expected to interact with the changes in this BIP, except for the sighash type byte rule. The authors recommend implementing BIP 9 to ensure miner upgrade prior to activation and express gratitude to various individuals for their helpful feedback and the entire Bitcoin Protocol Development Community.The reference implementation for the proposal can be found on Github at Bitcoin Core Pull #15482. The proposal provides references to other resources, including the difficulty adjustment algorithm in Bitcoin, the issues related to leaf nodes in the transaction merkle tree, and official stratum specifications. 2019-03-07T19:44:23+00:00 + In an email exchange between Luke Dashjr and Matt Corallo, Matt requested the assignment of a BIP number for a proposed soft fork to improve Bitcoin's security. Luke suggested including a Backward Compatibility section and opening a bips repo PR after discussion on the ML. One of the proposed changes is making non-standard signature hash types invalid to limit the potential signature hashes used per-input and improve caching efficiency. Additionally, caching the just-before-the-last-byte sighash midstate and hashing only the last byte when checking signatures was suggested.Luke sought clarity on what exactly was being removed with regards to the spec change. He emphasized the importance of fixing the timewarp vulnerability, which could be exploited by miners to inflate the currency supply maliciously or create extension blocks through forking. Although extension blocks are generally discouraged, the arguments in favor of timewarp-based inter-block-time reductions also apply to extension blocks.The proposal states that transactions smaller than 65 bytes without witness data will now be considered invalid, and the rationale for this change will explain why the size doesn't count the witness. It is strongly recommended that SPV clients enforce the new nTime rules to avoid following potential forks since miners currently only enforce increasing timestamps against the median-timestamp-of-last-11-blocks.The proposal acknowledges that several early-stage proposals, such as Schnorr signatures, Taproot, Graftroot, and MAST, may affect script execution but are not expected to interact with the changes in this BIP as they are likely to only apply to SegWit scripts. The defined sighash type byte rule only applies to current signature-checking opcodes, as any new signature-checking is expected to be implemented through the introduction of new opcodes.Matt Corallo requested a BIP number for a proposed soft fork to enhance Bitcoin's security in a message on the Bitcoin Development mailing list. The proposal includes changes like making non-standard signature hash types invalid and enforcing strict rules on transaction timestamps to prevent time-warp attacks. It also notes that early-stage proposals such as Schnorr signatures, Taproot, Graftroot, and MAST are not expected to interact with the changes in this BIP. A Backward Compatibility section is needed, and a bips repo PR should be opened after discussion on the ML. The proposal recommends SPV clients enforce the new nTime rules to avoid following potential forks.The Great Consensus Cleanup is a Bitcoin Improvement Proposal (BIP) aiming to simplify Bitcoin implementations, improve validation times, and address various vulnerabilities. The proposal suggests allowing timestamps on difficulty-adjustment blocks to go backwards by 600 seconds, fixing the long-standing "timewarp" inflation vulnerability without rendering existing mining hardware unusable. It also proposes making certain transaction sizes invalid to resolve vulnerabilities related to malleation in merkle tree construction.The BIP will be deployed using "version bits" BIP9 with the name "cleanups," using bit 3 as the activation signal, with different start times for mainnet and testnet. However, it may result in the activation of the new soft-fork rules coinciding with the scheduled block-subsidy halving. The BIP author argues that fixing the timewarp vulnerability is crucial because exploiting it could lead to malicious inflation of the currency supply by miners or forking through extension blocks, which is not an ideal approach.Bitcoin Improvement Proposal 118 (BIP 118) proposes the activation of Taproot, a new address format and signature scheme aimed at improving privacy and flexibility of Bitcoin transactions. The proposal suggests using BIP 141 (Segregated Witness) and BIP 143 (Transaction Signature Verification for Version 0 Witness Program) as activation methods. It also includes changes like reducing valid scriptSigs to the minimal set of operations generating any stack state, disabling non-canonical sighash types, and allowing nTime to go backward by 600 seconds to prevent attacks and simplify analysis.The proposal mentions that several early-stage proposals, including Schnorr signatures, Taproot, Graftroot, and MAST, may affect script execution but are not expected to interact with the changes in this BIP, except for the sighash type byte rule. The authors recommend implementing BIP 9 to ensure miner upgrade prior to activation and express gratitude to various individuals for their helpful feedback and the entire Bitcoin Protocol Development Community.The reference implementation for the proposal can be found on Github at Bitcoin Core Pull #15482. The proposal provides references to other resources, including the difficulty adjustment algorithm in Bitcoin, the issues related to leaf nodes in the transaction merkle tree, and official stratum specifications. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_BIP-Symbol-for-satoshi.xml b/static/bitcoin-dev/March_2019/combined_BIP-Symbol-for-satoshi.xml index 2b791f0d94..105d21acdd 100644 --- a/static/bitcoin-dev/March_2019/combined_BIP-Symbol-for-satoshi.xml +++ b/static/bitcoin-dev/March_2019/combined_BIP-Symbol-for-satoshi.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - BIP - Symbol for satoshi - 2023-08-02T00:32:15.254714+00:00 - - Federico Tenga 2019-03-07 18:10:41+00:00 - - - Tamas Blummer 2019-03-07 10:57:03+00:00 - - - Amine Chakak 2019-03-06 23:59:12+00:00 - - - Gregory Maxwell 2019-03-06 23:35:49+00:00 - - - Amine Chakak 2019-02-23 22:10:28+00:00 - + 2025-09-26T15:47:51.560957+00:00 + python-feedgen + + + [bitcoin-dev] BIP - Symbol for satoshi Amine Chakak + 2019-02-23T22:10:00.000Z + + + Gregory Maxwell + 2019-03-06T23:35:00.000Z + + + Amine Chakak + 2019-03-06T23:59:00.000Z + + + Tamas Blummer + 2019-03-07T10:57:00.000Z + + + Federico Tenga + 2019-03-07T18:10:00.000Z + + - python-feedgen + 2 Combined summary - BIP - Symbol for satoshi - 2023-08-02T00:32:15.254714+00:00 + 2025-09-26T15:47:51.561735+00:00 - In a recent discussion on the bitcoin-dev mailing list, Gregory Maxwell expressed his opposition to naming the smallest unit of bitcoin after Satoshi. He argued that if Satoshi wanted this, he would have done it himself and that the behavior is "creepy" and harmful to Bitcoin. However, another participant in the discussion disagreed, stating that having a common term for small amounts is important for improving user experience. They believe that using satoshis as a unit is more likely to achieve this goal than scientific notations.One potential issue with using satoshis as a unit is that it may sound strange or even humorous to native Japanese speakers. The discussion suggests that getting feedback from Japanese speakers on this topic could be useful. Regarding the proposal to formalize the symbol for satoshi, there is some disagreement about whether it has sufficient support to become a standard. The suggestion is made to wait for something to emerge that already has widespread usage, such as a symbol used by popular wallets or service providers.Non-engineers are unlikely to adopt scientific notation or mili/nano/pico prefixes for money. The convention is that most common currencies either have no change or only one that is 1/100 of the base unit, which is what practically all existing finance software and non-Bitcoin related UI that deals with money assumes. Bitcoin engineering blindness ignores evident cultural preference and pre-existing finance-related software.Tamas Blummer supports the BIP for bits as a base unit for Bitcoin. However, Gregory Maxwell finds it creepy and harmful to Bitcoin to name currency units after Satoshi. Lightning network does not use satoshis as a base unit but uses units of 10 picobitcoin. A BIP for satoshi as a base unit is not appropriate.In an email exchange between Amine Chakak and Gregory Maxwell, the idea of switching the base unit of Bitcoin to Satoshi was discussed. However, Maxwell expressed his disagreement with the idea, stating that if Satoshi Nakamoto had wanted the currency units named after him, he would have done so himself. Maxwell also criticized the behavior as "creepy" and "harmful" to Bitcoin. Chakak also mentioned the use of satoshis as a base unit in the Lightning Network, but Maxwell corrected him, stating that Lightning uses units of 10 picobitcoin (1e-11 btc), which is significantly smaller. Finally, Chakak asked if it would be appropriate to write a BIP for the proposed change, but Maxwell advised against it, stating "Please don't."A proposal to switch to "satoshi" as a base unit for Bitcoin has been floated around, but it has met with criticism from some members of the Bitcoin community. The idea was presented on the bitcoin-dev mailing list by Amine Chakak, but one user argued that if Bitcoin creator Satoshi Nakamoto had wanted the currency units named after him, he would have done so himself. Additionally, another user pointed out that the lightning network, which is built on top of Bitcoin, actually uses units of 10 picobitcoin rather than satoshis. As a result, the idea of creating a Bitcoin Improvement Proposal (BIP) for the switch to satoshi as a base unit was discouraged.The writer is proposing an idea for a satoshi symbol to be used as the base unit in cryptocurrency transactions. The proposal comes from Twitter user @bitficus, and the idea has already been discussed within the community since the lightning network already uses satoshis as a base unit. The proposal link is provided and the writer asks if it would be appropriate to write a BIP (Bitcoin Improvement Proposal) for it. The writer is following the website's instruction to first propose ideas for BIPS on the mailing list before submitting them formally. 2019-03-07T18:10:41+00:00 + In a recent discussion on the bitcoin-dev mailing list, Gregory Maxwell expressed his opposition to naming the smallest unit of bitcoin after Satoshi. He argued that if Satoshi wanted this, he would have done it himself and that the behavior is "creepy" and harmful to Bitcoin. However, another participant in the discussion disagreed, stating that having a common term for small amounts is important for improving user experience. They believe that using satoshis as a unit is more likely to achieve this goal than scientific notations.One potential issue with using satoshis as a unit is that it may sound strange or even humorous to native Japanese speakers. The discussion suggests that getting feedback from Japanese speakers on this topic could be useful. Regarding the proposal to formalize the symbol for satoshi, there is some disagreement about whether it has sufficient support to become a standard. The suggestion is made to wait for something to emerge that already has widespread usage, such as a symbol used by popular wallets or service providers.Non-engineers are unlikely to adopt scientific notation or mili/nano/pico prefixes for money. The convention is that most common currencies either have no change or only one that is 1/100 of the base unit, which is what practically all existing finance software and non-Bitcoin related UI that deals with money assumes. Bitcoin engineering blindness ignores evident cultural preference and pre-existing finance-related software.Tamas Blummer supports the BIP for bits as a base unit for Bitcoin. However, Gregory Maxwell finds it creepy and harmful to Bitcoin to name currency units after Satoshi. Lightning network does not use satoshis as a base unit but uses units of 10 picobitcoin. A BIP for satoshi as a base unit is not appropriate.In an email exchange between Amine Chakak and Gregory Maxwell, the idea of switching the base unit of Bitcoin to Satoshi was discussed. However, Maxwell expressed his disagreement with the idea, stating that if Satoshi Nakamoto had wanted the currency units named after him, he would have done so himself. Maxwell also criticized the behavior as "creepy" and "harmful" to Bitcoin. Chakak also mentioned the use of satoshis as a base unit in the Lightning Network, but Maxwell corrected him, stating that Lightning uses units of 10 picobitcoin (1e-11 btc), which is significantly smaller. Finally, Chakak asked if it would be appropriate to write a BIP for the proposed change, but Maxwell advised against it, stating "Please don't."A proposal to switch to "satoshi" as a base unit for Bitcoin has been floated around, but it has met with criticism from some members of the Bitcoin community. The idea was presented on the bitcoin-dev mailing list by Amine Chakak, but one user argued that if Bitcoin creator Satoshi Nakamoto had wanted the currency units named after him, he would have done so himself. Additionally, another user pointed out that the lightning network, which is built on top of Bitcoin, actually uses units of 10 picobitcoin rather than satoshis. As a result, the idea of creating a Bitcoin Improvement Proposal (BIP) for the switch to satoshi as a base unit was discouraged.The writer is proposing an idea for a satoshi symbol to be used as the base unit in cryptocurrency transactions. The proposal comes from Twitter user @bitficus, and the idea has already been discussed within the community since the lightning network already uses satoshis as a base unit. The proposal link is provided and the writer asks if it would be appropriate to write a BIP (Bitcoin Improvement Proposal) for it. The writer is following the website's instruction to first propose ideas for BIPS on the mailing list before submitting them formally. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml b/static/bitcoin-dev/March_2019/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml index 7db93a92a4..d5411bc5f1 100644 --- a/static/bitcoin-dev/March_2019/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml +++ b/static/bitcoin-dev/March_2019/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - BIP proposal, Pay to Contract BIP43 Application - 2023-08-01T21:26:35.599175+00:00 - - ZmnSCPxj 2019-03-12 07:05:37+00:00 - - - Omar Shibli 2019-03-12 05:53:45+00:00 - - - Omar Shibli 2017-09-01 07:16:41+00:00 - - - omar shibli 2017-08-15 16:40:36+00:00 - - - Gregory Maxwell 2017-08-15 05:12:11+00:00 - - - omar shibli 2017-08-14 06:05:35+00:00 - + 2025-09-26T15:47:34.818474+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application omar shibli + 2017-08-14T06:05:00.000Z + + + Gregory Maxwell + 2017-08-15T05:12:00.000Z + + + omar shibli + 2017-08-15T16:40:00.000Z + + + Omar Shibli + 2017-09-01T07:16:00.000Z + + + Omar Shibli + 2019-03-12T05:53:00.000Z + + + ZmnSCPxj + 2019-03-12T07:05:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal, Pay to Contract BIP43 Application - 2023-08-01T21:26:35.600176+00:00 + 2025-09-26T15:47:34.819274+00:00 - The email conversation revolves around a proposed method for embedding cryptographic signatures into public keys based on HD Wallets - BIP32. ZmnSCPxj raised concerns about the possibility of an attacker finding two contracts whose derivations alias each other and the possibility of multiple contracting systems. Omar Shibli responded to Gregory Maxwell's feedback with some fixes which he submitted on Github. Omar Shibli further expressed his opinion that the security fix was redundant. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey.In August 2017, Omar Shibli shared his method for embedding cryptographic signatures into a public key based on HD Wallets - BIP32, in a trade finance application. He proposed defining various levels in BIP32 path to compute child public keys and addresses. He also provided an example of contract commitment address computation. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey. Gregory also pointed out that the proposal did not address durability issues. Omar Shibli updated the BIP to address Gregory's concerns.The email thread includes a message from Omar Shibli expressing his appreciation for Gregory Maxwell's work in the FOSS ecosystem, particularly in Bitcoin and Blockstream. He also submitted fixes to Gregory's concerns regarding a security fix patch in the CKD function (BIP32) and requested his review. In another email, Omar shared an updated draft of a BIP specifying the multiparty key derivation scheme for the pay-to-contract protocol and sought feedback. Gregory had previously raised concerns about the security of the construction and durability issues which were not addressed in the proposal. Omar clarified the application of the construction, provided an example and updated the BIP to address Gregory's concerns. The full BIP draft is available on GitHub.A team has developed a basic trade finance application to conduct transactions using the Homomorphic Payment Addresses and the Pay-to-Contract Protocol paper. They have generalised it and made it BIP43 complaint. The team defines levels in BIP32 path as m / purpose' / coin_type' / contract_id' / *. Contract_id is an arbitrary number within the valid range of indices. Then, they define contract base as following prefix: m / purpose' / coin_type' / contract_id'. Contract commitment address is computed by hashing a document with a cryptographic hash function of your choice (e.g. Blake2), mapping the hash to partial derivation path and computing child public key by chaining the derivation path from step 2 with contract base. Payment address funds could be reclaimed only if the customer_contract_signature is provided by the customer. In terms of durability, their app is pretty simple at this point, they don't store anything, they let customer download and manage the files.The construction appears to be completely insecure, according to Gregory Maxwell. He believes that this is because the pubkey is easily manipulated. The team updated the BIP to explicitly specify the multiparty key derivation scheme, which they hope will address Maxwell's concerns. The BIP draft can be found on GitHub. Omar, from the team, thanks Gregory for his feedback and welcomes any further feedback.The email conversation is about a method to embed cryptographic signatures into public keys based on HD Wallets - BIP32. The application uses two cryptographic signatures from both sides for practical purposes. The proposed construction includes contract base, payment base, and payment address which can only be reclaimed by the customer_contract_signature. The current application is not very durable as it doesn't store anything, instead, the customer downloads and manages the files. Gregory Maxwell raises concerns about the security of the construction, its applications, and durability issues. Omar Shibli describes an abstract idea where levels are defined in BIP32 path, contract_id is an arbitrary number within valid indices and contract commitment address is computed using a cryptographic hash function. He also provides an example to illustrate the process. The full BIP draft is available on GitHub, and they seek feedback to develop a standard.A developer named Omar Shibli has proposed a new method for conducting transactions using the Homomorphic Payment Addresses and Pay-to-Contract Protocol, which uses the homomorphic property of elliptic curve encryption to achieve payment. The proposal defines levels in BIP32 path and contract commitment address that is computed by hashing a document with a cryptographic hash function, partitioning the array into parts, converting each part to an integer in decimal format, and joining all strings with a slash. The proposal does not address security concerns around payment to contracts or durability issues when losing funds if the exact contract is lost. There is no standard specification on how to conduct such transactions in cyberspace, but developers hope this proposal will result in a standard for the benefit of the community. The full BIP draft can be found at the provided link.The pay-to-contract protocol 2019-03-12T07:05:37+00:00 + The email conversation revolves around a proposed method for embedding cryptographic signatures into public keys based on HD Wallets - BIP32. ZmnSCPxj raised concerns about the possibility of an attacker finding two contracts whose derivations alias each other and the possibility of multiple contracting systems. Omar Shibli responded to Gregory Maxwell's feedback with some fixes which he submitted on Github. Omar Shibli further expressed his opinion that the security fix was redundant. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey.In August 2017, Omar Shibli shared his method for embedding cryptographic signatures into a public key based on HD Wallets - BIP32, in a trade finance application. He proposed defining various levels in BIP32 path to compute child public keys and addresses. He also provided an example of contract commitment address computation. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey. Gregory also pointed out that the proposal did not address durability issues. Omar Shibli updated the BIP to address Gregory's concerns.The email thread includes a message from Omar Shibli expressing his appreciation for Gregory Maxwell's work in the FOSS ecosystem, particularly in Bitcoin and Blockstream. He also submitted fixes to Gregory's concerns regarding a security fix patch in the CKD function (BIP32) and requested his review. In another email, Omar shared an updated draft of a BIP specifying the multiparty key derivation scheme for the pay-to-contract protocol and sought feedback. Gregory had previously raised concerns about the security of the construction and durability issues which were not addressed in the proposal. Omar clarified the application of the construction, provided an example and updated the BIP to address Gregory's concerns. The full BIP draft is available on GitHub.A team has developed a basic trade finance application to conduct transactions using the Homomorphic Payment Addresses and the Pay-to-Contract Protocol paper. They have generalised it and made it BIP43 complaint. The team defines levels in BIP32 path as m / purpose' / coin_type' / contract_id' / *. Contract_id is an arbitrary number within the valid range of indices. Then, they define contract base as following prefix: m / purpose' / coin_type' / contract_id'. Contract commitment address is computed by hashing a document with a cryptographic hash function of your choice (e.g. Blake2), mapping the hash to partial derivation path and computing child public key by chaining the derivation path from step 2 with contract base. Payment address funds could be reclaimed only if the customer_contract_signature is provided by the customer. In terms of durability, their app is pretty simple at this point, they don't store anything, they let customer download and manage the files.The construction appears to be completely insecure, according to Gregory Maxwell. He believes that this is because the pubkey is easily manipulated. The team updated the BIP to explicitly specify the multiparty key derivation scheme, which they hope will address Maxwell's concerns. The BIP draft can be found on GitHub. Omar, from the team, thanks Gregory for his feedback and welcomes any further feedback.The email conversation is about a method to embed cryptographic signatures into public keys based on HD Wallets - BIP32. The application uses two cryptographic signatures from both sides for practical purposes. The proposed construction includes contract base, payment base, and payment address which can only be reclaimed by the customer_contract_signature. The current application is not very durable as it doesn't store anything, instead, the customer downloads and manages the files. Gregory Maxwell raises concerns about the security of the construction, its applications, and durability issues. Omar Shibli describes an abstract idea where levels are defined in BIP32 path, contract_id is an arbitrary number within valid indices and contract commitment address is computed using a cryptographic hash function. He also provides an example to illustrate the process. The full BIP draft is available on GitHub, and they seek feedback to develop a standard.A developer named Omar Shibli has proposed a new method for conducting transactions using the Homomorphic Payment Addresses and Pay-to-Contract Protocol, which uses the homomorphic property of elliptic curve encryption to achieve payment. The proposal defines levels in BIP32 path and contract commitment address that is computed by hashing a document with a cryptographic hash function, partitioning the array into parts, converting each part to an integer in decimal format, and joining all strings with a slash. The proposal does not address security concerns around payment to contracts or durability issues when losing funds if the exact contract is lost. There is no standard specification on how to conduct such transactions in cyberspace, but developers hope this proposal will result in a standard for the benefit of the community. The full BIP draft can be found at the provided link.The pay-to-contract protocol - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_BIP-proposal-addrv2-message.xml b/static/bitcoin-dev/March_2019/combined_BIP-proposal-addrv2-message.xml index 62bcb1ada3..f2f2a3b025 100644 --- a/static/bitcoin-dev/March_2019/combined_BIP-proposal-addrv2-message.xml +++ b/static/bitcoin-dev/March_2019/combined_BIP-proposal-addrv2-message.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP proposal - addrv2 message - 2023-08-02T00:30:54.606027+00:00 - - Sjors Provoost 2019-03-06 09:05:09+00:00 - - - Gregory Maxwell 2019-03-06 03:02:51+00:00 - - - Wladimir J. van der Laan 2019-02-18 07:56:38+00:00 - + 2025-09-26T15:47:41.114278+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal - addrv2 message Wladimir J. van der Laan + 2019-02-18T07:56:00.000Z + + + Gregory Maxwell + 2019-03-06T03:02:00.000Z + + + Sjors Provoost + 2019-03-06T09:05:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal - addrv2 message - 2023-08-02T00:30:54.606027+00:00 + 2025-09-26T15:47:41.114851+00:00 - The concept ACK discusses several considerations regarding the gossip protocol in Bitcoin. The first consideration is whether a client should store and gossip address formats that they do not know about, especially those outside a certain overlay network. Three scenarios where a node may not know about an address format are discussed, followed by recommendations on how to proceed in each case. Despite concerns about gossiping unverified information, it is suggested that sharing information about other networks could be useful for nodes to help bootstrap connections.Another consideration is the precision of the time field in the protocol. It is argued that using seconds precision can be excessive and harmful. To address this, it is recommended to reduce the time field to 16 bits and quantize it to 1-hour precision, creating a "time ago seen" metric. This would reduce space requirements and mitigate attacks that exploit high-precision timestamps for mapping the current network topology.The document also proposes the inclusion of optional (per-service) data, which could be useful for various purposes, including optional flags. To encode the length of the payload for each flag, a byte count and type system is recommended. The authors acknowledge that while adding more information would create more opportunities for mapping the network topology, it could also be beneficial for certain use cases.A discussion on the Bitcoin-dev mailing list has raised questions about the maximum length of addresses for the Bitcoin protocol, specifically for the I2P network. It is suggested that the maximum address length should be defined per address type, considering there are two formats in use. Additionally, there was a debate on whether clients should store and gossip address formats they do not know about. It is proposed that clients should be discouraged from gossiping types they don't understand but not forbidden from doing so. However, caution should be exercised when gossiping unknown address types to prevent file transfer over invalid address types, particularly for networks without exit nodes.The document proposes a new P2P message called addrv2 to gossip longer node addresses over the P2P network. This is necessary to support new-generation Onion addresses, I2P, and other networks with longer endpoint addresses than what currently fits in the 128 bits of the addr message. The addrv2 message is defined as a message where pchCommand == "addrv2" and is serialized in the standard encoding for P2P messages. It has a format similar to the current addr message but with changes to accommodate longer addresses and a different time and services format.The list of reserved network IDs includes IPV4, IPV6, TORV2, TORV3, I2P, and CJDNS. Clients must ignore address types they do not know about to allow for future extensibility. They may also store and gossip address formats that they do not know about. However, they should reject addresses that have a different length than specified in the table for a specific address ID. The addrv2 messages should only be sent to peers with a certain protocol version or higher.The document lists various considerations that need further discussion, such as gossiping addresses outside a certain overlay network, the lower precision of the time field, rolling port into addr, or making the port optional. It is noted that the reference implementation is not yet available. 2019-03-06T09:05:09+00:00 + The concept ACK discusses several considerations regarding the gossip protocol in Bitcoin. The first consideration is whether a client should store and gossip address formats that they do not know about, especially those outside a certain overlay network. Three scenarios where a node may not know about an address format are discussed, followed by recommendations on how to proceed in each case. Despite concerns about gossiping unverified information, it is suggested that sharing information about other networks could be useful for nodes to help bootstrap connections.Another consideration is the precision of the time field in the protocol. It is argued that using seconds precision can be excessive and harmful. To address this, it is recommended to reduce the time field to 16 bits and quantize it to 1-hour precision, creating a "time ago seen" metric. This would reduce space requirements and mitigate attacks that exploit high-precision timestamps for mapping the current network topology.The document also proposes the inclusion of optional (per-service) data, which could be useful for various purposes, including optional flags. To encode the length of the payload for each flag, a byte count and type system is recommended. The authors acknowledge that while adding more information would create more opportunities for mapping the network topology, it could also be beneficial for certain use cases.A discussion on the Bitcoin-dev mailing list has raised questions about the maximum length of addresses for the Bitcoin protocol, specifically for the I2P network. It is suggested that the maximum address length should be defined per address type, considering there are two formats in use. Additionally, there was a debate on whether clients should store and gossip address formats they do not know about. It is proposed that clients should be discouraged from gossiping types they don't understand but not forbidden from doing so. However, caution should be exercised when gossiping unknown address types to prevent file transfer over invalid address types, particularly for networks without exit nodes.The document proposes a new P2P message called addrv2 to gossip longer node addresses over the P2P network. This is necessary to support new-generation Onion addresses, I2P, and other networks with longer endpoint addresses than what currently fits in the 128 bits of the addr message. The addrv2 message is defined as a message where pchCommand == "addrv2" and is serialized in the standard encoding for P2P messages. It has a format similar to the current addr message but with changes to accommodate longer addresses and a different time and services format.The list of reserved network IDs includes IPV4, IPV6, TORV2, TORV3, I2P, and CJDNS. Clients must ignore address types they do not know about to allow for future extensibility. They may also store and gossip address formats that they do not know about. However, they should reject addresses that have a different length than specified in the table for a specific address ID. The addrv2 messages should only be sent to peers with a certain protocol version or higher.The document lists various considerations that need further discussion, such as gossiping addresses outside a certain overlay network, the lower precision of the time field, rolling port into addr, or making the port optional. It is noted that the reference implementation is not yet available. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_BIP174-PSBT-extensions.xml b/static/bitcoin-dev/March_2019/combined_BIP174-PSBT-extensions.xml index 1aa2224b46..1040cf2980 100644 --- a/static/bitcoin-dev/March_2019/combined_BIP174-PSBT-extensions.xml +++ b/static/bitcoin-dev/March_2019/combined_BIP174-PSBT-extensions.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP174 / PSBT extensions - 2023-08-02T00:35:30.194737+00:00 - - Gregory Maxwell 2019-03-08 00:40:00+00:00 - - - Andrew Chow 2019-03-07 15:34:26+00:00 - - - Andrew Poelstra 2019-03-06 18:08:00+00:00 - + 2025-09-26T15:47:36.907290+00:00 + python-feedgen + + + [bitcoin-dev] BIP174 / PSBT extensions Andrew Poelstra + 2019-03-06T18:08:00.000Z + + + Andrew Chow + 2019-03-07T15:34:00.000Z + + + Gregory Maxwell + 2019-03-08T00:40:00.000Z + + - python-feedgen + 2 Combined summary - BIP174 / PSBT extensions - 2023-08-02T00:35:30.194737+00:00 + 2025-09-26T15:47:36.907844+00:00 - A recent discussion on the bitcoin-dev mailing list regarding Proprietary extension to Partially Signed Bitcoin Transactions (PSBT) has revealed different opinions. Andrew Chow expressed concern that such an extension would break the central idea of PSBT, which is to contain everything required to construct a transaction. He argued that relying on parties in the transaction to have state and remember details is not a reasonable assumption. However, other participants disagreed and suggested that it is acceptable for someone to use a proprietary extension to PSBT as long as it is used only between their own systems or with a translator to talk to ordinary PSBT elements.As a solution, they proposed adding a versioning field to indicate the specific PSBT dialect being used. This would allow for more reasonable error messages and help to identify any incompatible versions. The discussion highlighted the importance of maintaining the integrity and compatibility of PSBT, while also allowing space for innovation and customization for specific use cases.In an email thread on the bitcoin-dev mailing list, Andrew Poelstra, Director of Research at Blockstream, proposed several extensions to PSBT. The first proposal suggests adding a field to PSBT_GLOBAL_UNSIGNED_TX that contains only a transaction ID (txid) of the unsigned transaction. This would save bandwidth if signers have already seen the transaction or can construct it themselves. However, this proposal would break the central idea of PSBT.The second proposal is to add a version field to the global table, although its purpose remains unclear. The remaining proposals suggest adding various fields to per-input and per-output tables for different purposes. These include the confirmed depth of referenced txout, maps from SHA2 hashes to their 32-byte preimages, maps from public keys to 32-byte "tweaks" used in pay-to-contract construction, maps from public keys to partial nonce commitments, partial nonces, and partial signatures, and maps from signatures (or signature nonces) to sign-to-contract tweaks. However, these last two suggestions are considered premature and require further development and standardization of related protocols.Finally, Poelstra proposes adding a field (or family of fields) to every table that is "proprietary use" and guaranteed not to be defined by any future PSBT extension. Specifically, every field with key-type 0xFF could be considered "proprietary". The special field in the global table whose key is only 0xFF should be a "proprietary version field" with unspecified semantics, but an understanding that specific users might insert a GUID or something similar to recognize their own PSBTs.Overall, the discussion highlights the need for careful consideration when extending BIP174 and the importance of balancing innovation and customization with maintaining the integrity and compatibility of PSBT. 2019-03-08T00:40:00+00:00 + A recent discussion on the bitcoin-dev mailing list regarding Proprietary extension to Partially Signed Bitcoin Transactions (PSBT) has revealed different opinions. Andrew Chow expressed concern that such an extension would break the central idea of PSBT, which is to contain everything required to construct a transaction. He argued that relying on parties in the transaction to have state and remember details is not a reasonable assumption. However, other participants disagreed and suggested that it is acceptable for someone to use a proprietary extension to PSBT as long as it is used only between their own systems or with a translator to talk to ordinary PSBT elements.As a solution, they proposed adding a versioning field to indicate the specific PSBT dialect being used. This would allow for more reasonable error messages and help to identify any incompatible versions. The discussion highlighted the importance of maintaining the integrity and compatibility of PSBT, while also allowing space for innovation and customization for specific use cases.In an email thread on the bitcoin-dev mailing list, Andrew Poelstra, Director of Research at Blockstream, proposed several extensions to PSBT. The first proposal suggests adding a field to PSBT_GLOBAL_UNSIGNED_TX that contains only a transaction ID (txid) of the unsigned transaction. This would save bandwidth if signers have already seen the transaction or can construct it themselves. However, this proposal would break the central idea of PSBT.The second proposal is to add a version field to the global table, although its purpose remains unclear. The remaining proposals suggest adding various fields to per-input and per-output tables for different purposes. These include the confirmed depth of referenced txout, maps from SHA2 hashes to their 32-byte preimages, maps from public keys to 32-byte "tweaks" used in pay-to-contract construction, maps from public keys to partial nonce commitments, partial nonces, and partial signatures, and maps from signatures (or signature nonces) to sign-to-contract tweaks. However, these last two suggestions are considered premature and require further development and standardization of related protocols.Finally, Poelstra proposes adding a field (or family of fields) to every table that is "proprietary use" and guaranteed not to be defined by any future PSBT extension. Specifically, every field with key-type 0xFF could be considered "proprietary". The special field in the global table whose key is only 0xFF should be a "proprietary version field" with unspecified semantics, but an understanding that specific users might insert a GUID or something similar to recognize their own PSBTs.Overall, the discussion highlights the need for careful consideration when extending BIP174 and the importance of balancing innovation and customization with maintaining the integrity and compatibility of PSBT. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_Fortune-Cookies-to-Bitcoin-Seed.xml b/static/bitcoin-dev/March_2019/combined_Fortune-Cookies-to-Bitcoin-Seed.xml index b16c2b8b08..5653051334 100644 --- a/static/bitcoin-dev/March_2019/combined_Fortune-Cookies-to-Bitcoin-Seed.xml +++ b/static/bitcoin-dev/March_2019/combined_Fortune-Cookies-to-Bitcoin-Seed.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Fortune Cookies to Bitcoin Seed - 2023-08-02T00:32:53.894879+00:00 - - Trey Del Bonis 2019-03-06 01:37:35+00:00 - - - James MacWhyte 2019-03-06 01:05:54+00:00 - - - Trey Del Bonis 2019-02-28 03:48:57+00:00 - + 2025-09-26T15:47:49.473550+00:00 + python-feedgen + + + [bitcoin-dev] Fortune Cookies to Bitcoin Seed Trey Del Bonis + 2019-02-28T03:48:00.000Z + + + James MacWhyte + 2019-03-06T01:05:00.000Z + + + Trey Del Bonis + 2019-03-06T01:37:00.000Z + + - python-feedgen + 2 Combined summary - Fortune Cookies to Bitcoin Seed - 2023-08-02T00:32:53.894879+00:00 + 2025-09-26T15:47:49.474110+00:00 - A member of the bitcoin-dev community proposed a method of generating wallets using a list of 20 Chinese take-out menu items as seed phrases. However, another member pointed out that this method lacks sufficient security, providing only 77 bits of entropy and being vulnerable to brute force attacks within a few hours. They recommended using a BIP-39 seed phrase or incorporating additional secret phrases for greater entropy. Moreover, it was noted that some vendors print only 35 different combinations of Chinese food items, further reducing the security of this approach. The original poster acknowledged that their idea was merely for amusement and lacked practical applicability.In an email thread discussing Bitcoin development, Trey Del Bonis suggested that having 20 paper wallets might be excessive, although it would yield a staggering 390700800 possible wallets. Nevertheless, the speed at which mid-level hardware can check addresses (50k per second) means that all possibilities could be explored in just two hours. Consequently, Del Bonis cautioned against considering this method as a challenge for someone who discovers the 20 pieces of paper, assuming they are concealing the wallet. Instead, relying on a strong random number generator (RNG) would offer better entropy than trusting the printing company.Another proposal put forth by a Bitcoin developer involves creating a wallet seed from the numbers found in fortune cookies. Each number is estimated to possess approximately 6.6 bits of entropy, suggesting that around seven fortunes would be sufficient for a "very secure" wallet seed. To enhance security, it is recommended to divide the information between something physical and something memorized, making compromise more difficult. Additionally, this scheme allows for plausible deniability by generating decoy wallets using other fortune numbers. Although a Python script has been created to demonstrate the concept, it should be noted that the idea is still in its early stages, with concerns raised about potential weaknesses, such as individuals discarding their fortunes. 2019-03-06T01:37:35+00:00 + A member of the bitcoin-dev community proposed a method of generating wallets using a list of 20 Chinese take-out menu items as seed phrases. However, another member pointed out that this method lacks sufficient security, providing only 77 bits of entropy and being vulnerable to brute force attacks within a few hours. They recommended using a BIP-39 seed phrase or incorporating additional secret phrases for greater entropy. Moreover, it was noted that some vendors print only 35 different combinations of Chinese food items, further reducing the security of this approach. The original poster acknowledged that their idea was merely for amusement and lacked practical applicability.In an email thread discussing Bitcoin development, Trey Del Bonis suggested that having 20 paper wallets might be excessive, although it would yield a staggering 390700800 possible wallets. Nevertheless, the speed at which mid-level hardware can check addresses (50k per second) means that all possibilities could be explored in just two hours. Consequently, Del Bonis cautioned against considering this method as a challenge for someone who discovers the 20 pieces of paper, assuming they are concealing the wallet. Instead, relying on a strong random number generator (RNG) would offer better entropy than trusting the printing company.Another proposal put forth by a Bitcoin developer involves creating a wallet seed from the numbers found in fortune cookies. Each number is estimated to possess approximately 6.6 bits of entropy, suggesting that around seven fortunes would be sufficient for a "very secure" wallet seed. To enhance security, it is recommended to divide the information between something physical and something memorized, making compromise more difficult. Additionally, this scheme allows for plausible deniability by generating decoy wallets using other fortune numbers. Although a Python script has been created to demonstrate the concept, it should be noted that the idea is still in its early stages, with concerns raised about potential weaknesses, such as individuals discarding their fortunes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_More-thoughts-on-NOINPUT-safety.xml b/static/bitcoin-dev/March_2019/combined_More-thoughts-on-NOINPUT-safety.xml index d6f63c7028..d66af65771 100644 --- a/static/bitcoin-dev/March_2019/combined_More-thoughts-on-NOINPUT-safety.xml +++ b/static/bitcoin-dev/March_2019/combined_More-thoughts-on-NOINPUT-safety.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - More thoughts on NOINPUT safety - 2023-08-02T00:39:11.911579+00:00 - - ZmnSCPxj 2019-03-22 07:46:28+00:00 - - - Johnson Lau 2019-03-22 04:23:28+00:00 - - - Anthony Towns 2019-03-22 02:58:46+00:00 - - - ZmnSCPxj 2019-03-22 01:59:14+00:00 - - - Anthony Towns 2019-03-21 11:55:22+00:00 - - - ZmnSCPxj 2019-03-21 10:05:09+00:00 - - - Anthony Towns 2019-03-21 09:06:14+00:00 - - - Johnson Lau 2019-03-21 08:37:54+00:00 - - - ZmnSCPxj 2019-03-20 08:07:00+00:00 - - - ZmnSCPxj 2019-03-20 07:38:22+00:00 - - - Rusty Russell 2019-03-20 03:33:55+00:00 - - - Rusty Russell 2019-03-20 00:22:05+00:00 - - - Christian Decker 2019-03-14 12:00:56+00:00 - - - ZmnSCPxj 2019-03-14 07:55:20+00:00 - - - Anthony Towns 2019-03-14 07:24:56+00:00 - - - ZmnSCPxj 2019-03-14 05:22:59+00:00 - - - Anthony Towns 2019-03-13 11:10:50+00:00 - - - ZmnSCPxj 2019-03-13 06:41:47+00:00 - - - Anthony Towns 2019-03-13 01:41:43+00:00 - + 2025-09-26T15:47:20.036206+00:00 + python-feedgen + + + [bitcoin-dev] More thoughts on NOINPUT safety Anthony Towns + 2019-03-13T01:41:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2019-03-13T06:41:00.000Z + + + Anthony Towns + 2019-03-13T11:10:00.000Z + + + ZmnSCPxj + 2019-03-14T05:22:00.000Z + + + Anthony Towns + 2019-03-14T07:24:00.000Z + + + ZmnSCPxj + 2019-03-14T07:55:00.000Z + + + Christian Decker + 2019-03-14T12:00:00.000Z + + + Rusty Russell + 2019-03-20T00:22:00.000Z + + + Rusty Russell + 2019-03-20T03:33:00.000Z + + + ZmnSCPxj + 2019-03-20T07:38:00.000Z + + + ZmnSCPxj + 2019-03-20T08:07:00.000Z + + + Johnson Lau + 2019-03-21T08:37:00.000Z + + + Anthony Towns + 2019-03-21T09:06:00.000Z + + + ZmnSCPxj + 2019-03-21T10:05:00.000Z + + + Anthony Towns + 2019-03-21T11:55:00.000Z + + + ZmnSCPxj + 2019-03-22T01:59:00.000Z + + + Anthony Towns + 2019-03-22T02:58:00.000Z + + + Johnson Lau + 2019-03-22T04:23:00.000Z + + + ZmnSCPxj + 2019-03-22T07:46:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - More thoughts on NOINPUT safety - 2023-08-02T00:39:11.911579+00:00 + 2025-09-26T15:47:20.038215+00:00 - ZmnSCPxj and AJ Towns were discussing the implementation of eltoo in Bitcoin's Script language. They explored different options for enforcing timelocks in settlement transactions. ZmnSCPxj suggested using OP_CHECKLOCKTIMEVERIFY and OP_CHECKDLSVERIFY, while AJ proposed using OP_CODESEPARATOR. However, they acknowledged that both approaches require a flag for commitment to the scriptcode, which is not provided by BIP118.They also discussed the use of separate keys in the two branches of the script. The discussion touched on the necessity of OP_CSV in the settlement branch and concluded that OP_CSV is not needed if one party cannot single-handedly decide the relative locktime, as is the case with muSig. The post clarified that even a script without OP_CSV does not require it as long as the signatures use the same relative locktime.In another email exchange, ZmnSCPxj and AJ discussed the enforcement of relative timelocks in settlement transactions. AJ proposed refusing to sign a settlement transaction that doesn't have the timelock set as a way to enforce relative timelock in the settlement branch. They also mentioned that due to BIP-68 being enforced by consensus, settlement-1 signed by ZmnSCPxj is not immediately spendable by update-1.The conversation highlighted the technical details involved in enforcing timelocks in settlement transactions for offchain channels. It emphasized the need for a distinct public key for settlement transactions and the enforcement of nLockTime with OP_CHECKLOCKTIMEVERIFY. It also discussed the possibility of using OP_CODESEPARATOR to distinguish between update and settlement transactions.AJ and ZmnSCPxj discussed potential ways to simplify the Bitcoin script for Taproot. They explored using different shared keys in the two branches of the script and signing with NOINPUT, NOSCRIPT, and codeseparatorpos to enforce CheckLockTimeVerify (CLTV). They also mentioned the requirement of two pubkeys, two sigs, and the taproot point reveal.The email exchange touched on the proposal of using either of two scripts for eltoo. It was clarified that both scripts can be used, with differences in the signing process. One style involves exchanging the NOINPUT signature, while the other style requires cosigning the muSig with NOINPUT and sharing the private key for Q. The discussion highlighted the simplicity of the first style and the efficiency of the second style with multiple parties.ZmnSCPxj raised a question about the "must have a non-SIGHASH_NOINPUT" rule and its implications for watchtowers. It was suggested that watchtowers store both SIGHASH_NOINPUT signatures from both sides in the blob sent to them. Rusty Russell responded by mentioning the possibility of future segwit versions relaxing the rule. ZmnSCPxj proposed the idea of requiring a sig that commits to the input tx as a safe and inexpensive approach to address the issue.The discussion delved into the potential problems with NOINPUT signatures and the need for safety measures. The differentiation between malicious and non-malicious double-spends was debated, with concerns raised about the risks associated with coins sent to the sender. The conversation emphasized the importance of implementing safety measures that are helpful in practical failure scenarios. It was suggested that a "sig that commits to the input tx" could be a standardness rule for NOINPUT.Anthony Towns proposed the concept of tagged outputs, called "taproot plus," which would allow for the use of noinput signatures alongside normal taproot addresses. Different transaction structures were discussed, including cooperative claims, update transactions, settlement transactions, and trigger transactions. Concerns were raised about how to bind update transactions to the funding tx output if they are not tagged. Solutions such as storing multiple separate states or adding a trigger transaction were considered.ZmnSCPxj shared insights on the disadvantages of maximizing privacy, particularly in terms of performance and use with DLC. He suggested splitting a channel into high-activity LN payments and rare-activity DLC bets as a way to mitigate the potential issues.In a discussion on the Lightning-dev mailing list, ZmnSCPxj responds to AJ's post about the potential conflict between output tagging and Taproot. ZmnSCPxj raises the question of whether it is possible to hide the clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot. They also provide their thoughts on using scriptless scripts for HTLCs and bilateral/cooperative close when an HTLC is in-flight.The email proposes a way to enhance the security of the eltoo channel in Bitcoin by requiring every script to have a valid signature that commits to the input. However, this approach has some drawbacks such as revealing the taproot point and two keys, and additional script overhead. The email suggests that requiring a non-NOINPUT signature can provide a defense against third party malleability, unlike output tagging. They argue that even 2019-03-22T07:46:28+00:00 + ZmnSCPxj and AJ Towns were discussing the implementation of eltoo in Bitcoin's Script language. They explored different options for enforcing timelocks in settlement transactions. ZmnSCPxj suggested using OP_CHECKLOCKTIMEVERIFY and OP_CHECKDLSVERIFY, while AJ proposed using OP_CODESEPARATOR. However, they acknowledged that both approaches require a flag for commitment to the scriptcode, which is not provided by BIP118.They also discussed the use of separate keys in the two branches of the script. The discussion touched on the necessity of OP_CSV in the settlement branch and concluded that OP_CSV is not needed if one party cannot single-handedly decide the relative locktime, as is the case with muSig. The post clarified that even a script without OP_CSV does not require it as long as the signatures use the same relative locktime.In another email exchange, ZmnSCPxj and AJ discussed the enforcement of relative timelocks in settlement transactions. AJ proposed refusing to sign a settlement transaction that doesn't have the timelock set as a way to enforce relative timelock in the settlement branch. They also mentioned that due to BIP-68 being enforced by consensus, settlement-1 signed by ZmnSCPxj is not immediately spendable by update-1.The conversation highlighted the technical details involved in enforcing timelocks in settlement transactions for offchain channels. It emphasized the need for a distinct public key for settlement transactions and the enforcement of nLockTime with OP_CHECKLOCKTIMEVERIFY. It also discussed the possibility of using OP_CODESEPARATOR to distinguish between update and settlement transactions.AJ and ZmnSCPxj discussed potential ways to simplify the Bitcoin script for Taproot. They explored using different shared keys in the two branches of the script and signing with NOINPUT, NOSCRIPT, and codeseparatorpos to enforce CheckLockTimeVerify (CLTV). They also mentioned the requirement of two pubkeys, two sigs, and the taproot point reveal.The email exchange touched on the proposal of using either of two scripts for eltoo. It was clarified that both scripts can be used, with differences in the signing process. One style involves exchanging the NOINPUT signature, while the other style requires cosigning the muSig with NOINPUT and sharing the private key for Q. The discussion highlighted the simplicity of the first style and the efficiency of the second style with multiple parties.ZmnSCPxj raised a question about the "must have a non-SIGHASH_NOINPUT" rule and its implications for watchtowers. It was suggested that watchtowers store both SIGHASH_NOINPUT signatures from both sides in the blob sent to them. Rusty Russell responded by mentioning the possibility of future segwit versions relaxing the rule. ZmnSCPxj proposed the idea of requiring a sig that commits to the input tx as a safe and inexpensive approach to address the issue.The discussion delved into the potential problems with NOINPUT signatures and the need for safety measures. The differentiation between malicious and non-malicious double-spends was debated, with concerns raised about the risks associated with coins sent to the sender. The conversation emphasized the importance of implementing safety measures that are helpful in practical failure scenarios. It was suggested that a "sig that commits to the input tx" could be a standardness rule for NOINPUT.Anthony Towns proposed the concept of tagged outputs, called "taproot plus," which would allow for the use of noinput signatures alongside normal taproot addresses. Different transaction structures were discussed, including cooperative claims, update transactions, settlement transactions, and trigger transactions. Concerns were raised about how to bind update transactions to the funding tx output if they are not tagged. Solutions such as storing multiple separate states or adding a trigger transaction were considered.ZmnSCPxj shared insights on the disadvantages of maximizing privacy, particularly in terms of performance and use with DLC. He suggested splitting a channel into high-activity LN payments and rare-activity DLC bets as a way to mitigate the potential issues.In a discussion on the Lightning-dev mailing list, ZmnSCPxj responds to AJ's post about the potential conflict between output tagging and Taproot. ZmnSCPxj raises the question of whether it is possible to hide the clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot. They also provide their thoughts on using scriptless scripts for HTLCs and bilateral/cooperative close when an HTLC is in-flight.The email proposes a way to enhance the security of the eltoo channel in Bitcoin by requiring every script to have a valid signature that commits to the input. However, this approach has some drawbacks such as revealing the taproot point and two keys, and additional script overhead. The email suggests that requiring a non-NOINPUT signature can provide a defense against third party malleability, unlike output tagging. They argue that even - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol-former-BIP151-.xml b/static/bitcoin-dev/March_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol-former-BIP151-.xml index f370a73dfc..899dbc2ef2 100644 --- a/static/bitcoin-dev/March_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol-former-BIP151-.xml +++ b/static/bitcoin-dev/March_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol-former-BIP151-.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - New BIP - v2 peer-to-peer message transport protocol (former BIP151) - 2023-08-02T00:40:05.191007+00:00 - - Eric Voskuil 2019-03-25 06:32:58+00:00 - - - Jonas Schnelli 2019-03-24 19:35:45+00:00 - - - David A. Harding 2019-03-24 15:38:56+00:00 - - - David A. Harding 2019-03-24 13:29:10+00:00 - - - Jonas Schnelli 2019-03-22 21:04:46+00:00 - + 2025-09-26T15:47:39.023018+00:00 + python-feedgen + + + [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151) Jonas Schnelli + 2019-03-22T21:04:00.000Z + + + David A. Harding + 2019-03-24T13:29:00.000Z + + + David A. Harding + 2019-03-24T15:38:00.000Z + + + Jonas Schnelli + 2019-03-24T19:35:00.000Z + + + Eric Voskuil + 2019-03-25T06:32:00.000Z + + - python-feedgen + 2 Combined summary - New BIP - v2 peer-to-peer message transport protocol (former BIP151) - 2023-08-02T00:40:05.191007+00:00 + 2025-09-26T15:47:39.023767+00:00 - On 22nd March 2019, Jonas Schnelli proposed a new Bitcoin peer-to-peer transport protocol with opportunistic encryption via the bitcoin-dev mailing list. The current unencrypted message transport is inefficient and vulnerable to various attacks. This proposal aims to address these issues by introducing opportunistic encryption. The key idea is that encrypting public data between anonymous peers is pointless, so the proposal focuses on identifying data manipulation by communicating peers.The proposal acknowledges that encrypting traffic between peers is already possible with existing encryption mechanisms, but those solutions are not widely deployed due to the complexity of setting up a secure channel. The proposed protocol aims to make encryption more accessible by providing an easy-to-use solution.The proposal includes specific requirements for peers supporting the new message transport protocol. Peers must accept encryption requests from all peers and signal NODE_P2P_V2. Peers supporting NODE_P2P_V2 must accept encrypted communication as specified in the proposal. It is assumed that the two peers using this protocol know and trust each other and have the ability to communicate over a secure side channel.In a discussion on the bitcoin-dev mailing list, Dave raised a question about the optional nature of short command IDs in the v2 message format. He suggested having a fixed-length field for all message types instead of dealing with variable size and mapping negotiation. Jonas argued that short IDs can help avoid collisions in the future, especially for high-frequency messages. He also mentioned that there are only 26 different message types currently, so short IDs may not be necessary for all of them. He proposed that short IDs can be altered with the message protocol version, and adding them should be straightforward. However, he noted that some commands may not benefit significantly from short IDs, as there are only 244 available.In another discussion, David A. Harding questioned why short IDs were optional and specified only for certain message types. Gregory Maxwell explained that allocating short IDs to existing messages is easy, but adding new protocol messages would require coordination with all developers working on protocol extensions. This could lead to disagreements and delays. Allowing nodes to use arbitrary command names eliminates this issue and saves bandwidth through optional negotiation. Harding found this reasoning reasonable after understanding the motivation behind it.The discussion also covered the structure of v2 messages, including field size, description, data type, and comments for each message. The command field must start with a byte that defines the length of the ASCII command string or a short command ID. Short command IDs are supported for high-frequency message types but are optional and can be negotiated between peers. The list of all net message types in the src/protocol.cpp file was shared.The proposed Version 2 Peer-to-Peer Message Transport Protocol aims to provide a more efficient and secure communication method for Bitcoin. It addresses vulnerabilities in the current unencrypted message transport and introduces opportunistic encryption to detect data manipulation by communicating peers. The protocol requires an optimized AEAD construct, a NODE_P2P_V2 signal, a 32-byte "pseudorandom" key exchange, removal of the multi-message envelope, and the use of a 3-byte integer to determine packet length. Short-command-IDs are introduced for high-frequency message types, but their usage is optional and may be negotiated between peers. The proposal also outlines the key derivation process, symmetric encryption cipher keys, and the encryption scheme used (ChaCha20-Poly1305).Overall, the proposal aims to enhance the security and efficiency of the Bitcoin peer-to-peer network by introducing opportunistic encryption and addressing vulnerabilities in the current message transport. It provides detailed specifications for peers supporting the new protocol and discusses the optional nature of short command IDs. The proposal is backward compatible, allowing non-supporting peers to continue using unencrypted communications. 2019-03-25T06:32:58+00:00 + On 22nd March 2019, Jonas Schnelli proposed a new Bitcoin peer-to-peer transport protocol with opportunistic encryption via the bitcoin-dev mailing list. The current unencrypted message transport is inefficient and vulnerable to various attacks. This proposal aims to address these issues by introducing opportunistic encryption. The key idea is that encrypting public data between anonymous peers is pointless, so the proposal focuses on identifying data manipulation by communicating peers.The proposal acknowledges that encrypting traffic between peers is already possible with existing encryption mechanisms, but those solutions are not widely deployed due to the complexity of setting up a secure channel. The proposed protocol aims to make encryption more accessible by providing an easy-to-use solution.The proposal includes specific requirements for peers supporting the new message transport protocol. Peers must accept encryption requests from all peers and signal NODE_P2P_V2. Peers supporting NODE_P2P_V2 must accept encrypted communication as specified in the proposal. It is assumed that the two peers using this protocol know and trust each other and have the ability to communicate over a secure side channel.In a discussion on the bitcoin-dev mailing list, Dave raised a question about the optional nature of short command IDs in the v2 message format. He suggested having a fixed-length field for all message types instead of dealing with variable size and mapping negotiation. Jonas argued that short IDs can help avoid collisions in the future, especially for high-frequency messages. He also mentioned that there are only 26 different message types currently, so short IDs may not be necessary for all of them. He proposed that short IDs can be altered with the message protocol version, and adding them should be straightforward. However, he noted that some commands may not benefit significantly from short IDs, as there are only 244 available.In another discussion, David A. Harding questioned why short IDs were optional and specified only for certain message types. Gregory Maxwell explained that allocating short IDs to existing messages is easy, but adding new protocol messages would require coordination with all developers working on protocol extensions. This could lead to disagreements and delays. Allowing nodes to use arbitrary command names eliminates this issue and saves bandwidth through optional negotiation. Harding found this reasoning reasonable after understanding the motivation behind it.The discussion also covered the structure of v2 messages, including field size, description, data type, and comments for each message. The command field must start with a byte that defines the length of the ASCII command string or a short command ID. Short command IDs are supported for high-frequency message types but are optional and can be negotiated between peers. The list of all net message types in the src/protocol.cpp file was shared.The proposed Version 2 Peer-to-Peer Message Transport Protocol aims to provide a more efficient and secure communication method for Bitcoin. It addresses vulnerabilities in the current unencrypted message transport and introduces opportunistic encryption to detect data manipulation by communicating peers. The protocol requires an optimized AEAD construct, a NODE_P2P_V2 signal, a 32-byte "pseudorandom" key exchange, removal of the multi-message envelope, and the use of a 3-byte integer to determine packet length. Short-command-IDs are introduced for high-frequency message types, but their usage is optional and may be negotiated between peers. The proposal also outlines the key derivation process, symmetric encryption cipher keys, and the encryption scheme used (ChaCha20-Poly1305).Overall, the proposal aims to enhance the security and efficiency of the Bitcoin peer-to-peer network by introducing opportunistic encryption and addressing vulnerabilities in the current message transport. It provides detailed specifications for peers supporting the new protocol and discusses the optional nature of short command IDs. The proposal is backward compatible, allowing non-supporting peers to continue using unencrypted communications. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_Notice-List-Infrastructure-Migration.xml b/static/bitcoin-dev/March_2019/combined_Notice-List-Infrastructure-Migration.xml index 434aec7341..3a351e52e8 100644 --- a/static/bitcoin-dev/March_2019/combined_Notice-List-Infrastructure-Migration.xml +++ b/static/bitcoin-dev/March_2019/combined_Notice-List-Infrastructure-Migration.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Notice: List Infrastructure Migration - 2023-08-02T00:39:37.847262+00:00 - - Omar Shibli 2019-03-20 06:03:24+00:00 - - - Peter Todd 2019-03-19 18:01:51+00:00 - - - Warren Togami Jr. 2019-03-18 22:35:47+00:00 - + 2025-09-26T15:47:45.295935+00:00 + python-feedgen + + + [bitcoin-dev] Notice: List Infrastructure Migration Warren Togami Jr. + 2019-03-18T22:35:00.000Z + + + Peter Todd + 2019-03-19T18:01:00.000Z + + + Omar Shibli + 2019-03-20T06:03:00.000Z + + - python-feedgen + 2 Combined summary - Notice: List Infrastructure Migration - 2023-08-02T00:39:37.847262+00:00 + 2025-09-26T15:47:45.296419+00:00 - Warren Togami Jr. has announced on the bitcoin-dev mailing list that a new archive will be created independently outside of the Linux Foundation. This move aims to ensure that future archives do not have to be moved again, even if there are changes to the underlying list infrastructure. The new archive will include a search function and allow users to perform git clone for a local instance.During the discussion, Peter Todd raised the question of where the git archive would be created and maintained. He suggested that it should be timestamped and PGP signed. Another user requested more communication in advance with relaxed timelines for future migration phases.It was announced that starting this week, Bitcoin-oriented lists such as bitcoin-dev and lightning-dev will begin migrating from https://lists.linuxfoundation.org/mailman/listinfo to the Linux Foundation's new list infrastructure operated by groups.io. The exact switch-over date is still unknown, but users are advised to unsubscribe prior to migration if they do not wish to be auto-subscribed to the new list management system.While each list is notified that migration is complete, users can continue to use these lists as-is. However, archives are considered important for prior art and historic value. A plan is being developed with the Linux Foundation sysadmins to ensure that the current archive permalinks remain static or redirected to the correct post in the new archive.The new archive will be operated independently outside of the Linux Foundation using an open source tool. This will allow all future archives to remain in place, even if there are changes to the underlying list infrastructure. Users will have access to a search function and the ability to git clone for a local instance. More details will be provided soon. 2019-03-20T06:03:24+00:00 + Warren Togami Jr. has announced on the bitcoin-dev mailing list that a new archive will be created independently outside of the Linux Foundation. This move aims to ensure that future archives do not have to be moved again, even if there are changes to the underlying list infrastructure. The new archive will include a search function and allow users to perform git clone for a local instance.During the discussion, Peter Todd raised the question of where the git archive would be created and maintained. He suggested that it should be timestamped and PGP signed. Another user requested more communication in advance with relaxed timelines for future migration phases.It was announced that starting this week, Bitcoin-oriented lists such as bitcoin-dev and lightning-dev will begin migrating from https://lists.linuxfoundation.org/mailman/listinfo to the Linux Foundation's new list infrastructure operated by groups.io. The exact switch-over date is still unknown, but users are advised to unsubscribe prior to migration if they do not wish to be auto-subscribed to the new list management system.While each list is notified that migration is complete, users can continue to use these lists as-is. However, archives are considered important for prior art and historic value. A plan is being developed with the Linux Foundation sysadmins to ensure that the current archive permalinks remain static or redirected to the correct post in the new archive.The new archive will be operated independently outside of the Linux Foundation using an open source tool. This will allow all future archives to remain in place, even if there are changes to the underlying list infrastructure. Users will have access to a search function and the ability to git clone for a local instance. More details will be provided soon. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_OP-CODESEPARATOR-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml b/static/bitcoin-dev/March_2019/combined_OP-CODESEPARATOR-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml index e85bc23646..a5e1fe9e53 100644 --- a/static/bitcoin-dev/March_2019/combined_OP-CODESEPARATOR-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml +++ b/static/bitcoin-dev/March_2019/combined_OP-CODESEPARATOR-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup - 2023-08-02T00:36:47.010419+00:00 + 2025-09-26T15:47:32.725732+00:00 + python-feedgen Russell O'Connor 2019-03-13 01:38:44+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup - 2023-08-02T00:36:47.010419+00:00 + 2025-09-26T15:47:32.725923+00:00 - A proposal has been made to fix a vulnerability in Bitcoin using OP_CODESEPARATOR. The proposal suggests implementing a soft-fork rule that increases an input's weight based on the number of OP_CODESEPARATORs executed and the weight of the UTXO being spent, plus an additional 40 bytes. However, there are concerns that this may result in low fees and could be complex to implement.Another suggestion is to limit the maximum number of OP_CODESEPARATORs allowed per script. However, there is skepticism about this approach as it may render some transactions unspendable. It is emphasized that non-standardness should not be used as an excuse to permanently destroy people's funds.In an email exchange between Matt Corallo and Russell O'Connor, the topic of OP_CODESEPARATOR in non-BIP 143 scripts failing script validation was discussed. While OP_CODESEPARATOR is used for users to sign specific branches within scripts, it appears to have limited practical use cases. O'Connor argues that activating a soft-fork that disables OP_CODESEPARATOR would risk people's money and proposes alternative solutions such as increasing the transaction's weight or imposing a limit on the number of OP_CODESEPARATORs allowed per script.Corallo disagrees with this proposal, noting that such limits could make moderately-large transactions unspendable. He believes that OP_CODESEPARATOR in non-segwit scripts represents a significant vulnerability in Bitcoin and suggests a soft fork rule to address this.Russell O'Connor expresses concerns about disabling OP_CODESEPARATOR in non-BIP 143 scripts, stating that it is necessary for signing specific branches with multiple possible conditions reusing the same public key. Matt Corallo argues that despite efforts, there have been few practical use-cases for this feature. He suggests that OP_CODESEPARATOR in non-segwit scripts poses a vulnerability that needs to be addressed. Corallo dismisses the concern of funds being permanently lost, stating that it is not a sufficient reason to avoid fixing the vulnerability. He proposes increasing the transaction's weight upon OP_CODESEPARATOR execution or implementing a limit on the number of OP_CODESEPARATORs allowed per script.OP_CODESEPARATOR is a mechanism for users to sign specific branches within scripts. However, it fails script validation in non-BIP 143 scripts and poses a vulnerability in Bitcoin. Activating a soft-fork to disable OP_CODESEPARATOR could result in funds being permanently lost. To address this vulnerability, alternative solutions such as increasing the transaction's weight or imposing a limit on the number of OP_CODESEPARATORs executed per script have been suggested. The goal is to prevent fund loss without compromising security. 2019-03-13T01:38:44+00:00 + A proposal has been made to fix a vulnerability in Bitcoin using OP_CODESEPARATOR. The proposal suggests implementing a soft-fork rule that increases an input's weight based on the number of OP_CODESEPARATORs executed and the weight of the UTXO being spent, plus an additional 40 bytes. However, there are concerns that this may result in low fees and could be complex to implement.Another suggestion is to limit the maximum number of OP_CODESEPARATORs allowed per script. However, there is skepticism about this approach as it may render some transactions unspendable. It is emphasized that non-standardness should not be used as an excuse to permanently destroy people's funds.In an email exchange between Matt Corallo and Russell O'Connor, the topic of OP_CODESEPARATOR in non-BIP 143 scripts failing script validation was discussed. While OP_CODESEPARATOR is used for users to sign specific branches within scripts, it appears to have limited practical use cases. O'Connor argues that activating a soft-fork that disables OP_CODESEPARATOR would risk people's money and proposes alternative solutions such as increasing the transaction's weight or imposing a limit on the number of OP_CODESEPARATORs allowed per script.Corallo disagrees with this proposal, noting that such limits could make moderately-large transactions unspendable. He believes that OP_CODESEPARATOR in non-segwit scripts represents a significant vulnerability in Bitcoin and suggests a soft fork rule to address this.Russell O'Connor expresses concerns about disabling OP_CODESEPARATOR in non-BIP 143 scripts, stating that it is necessary for signing specific branches with multiple possible conditions reusing the same public key. Matt Corallo argues that despite efforts, there have been few practical use-cases for this feature. He suggests that OP_CODESEPARATOR in non-segwit scripts poses a vulnerability that needs to be addressed. Corallo dismisses the concern of funds being permanently lost, stating that it is not a sufficient reason to avoid fixing the vulnerability. He proposes increasing the transaction's weight upon OP_CODESEPARATOR execution or implementing a limit on the number of OP_CODESEPARATORs allowed per script.OP_CODESEPARATOR is a mechanism for users to sign specific branches within scripts. However, it fails script validation in non-BIP 143 scripts and poses a vulnerability in Bitcoin. Activating a soft-fork to disable OP_CODESEPARATOR could result in funds being permanently lost. To address this vulnerability, alternative solutions such as increasing the transaction's weight or imposing a limit on the number of OP_CODESEPARATORs executed per script have been suggested. The goal is to prevent fund loss without compromising security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_Payjoin-privacy-with-the-receiver-of-the-transaction.xml b/static/bitcoin-dev/March_2019/combined_Payjoin-privacy-with-the-receiver-of-the-transaction.xml index e91ef04c42..a704e74cd0 100644 --- a/static/bitcoin-dev/March_2019/combined_Payjoin-privacy-with-the-receiver-of-the-transaction.xml +++ b/static/bitcoin-dev/March_2019/combined_Payjoin-privacy-with-the-receiver-of-the-transaction.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Payjoin privacy with the receiver of the transaction - 2023-08-02T00:39:24.662438+00:00 - - ZmnSCPxj 2019-03-22 16:05:13+00:00 - - - Kenshiro [] 2019-03-22 11:15:26+00:00 - - - Kenshiro [] 2019-03-22 10:23:24+00:00 - - - rhavar at protonmail.com 2019-03-21 16:52:41+00:00 - - - Kenshiro [] 2019-03-18 10:55:34+00:00 - + 2025-09-26T15:47:43.202272+00:00 + python-feedgen + + + [bitcoin-dev] Payjoin privacy with the receiver of the transaction Kenshiro [] + 2019-03-18T10:55:00.000Z + + + rhavar + 2019-03-21T16:52:00.000Z + + + Kenshiro [] + 2019-03-22T10:23:00.000Z + + + Kenshiro [] + 2019-03-22T11:15:00.000Z + + + ZmnSCPxj + 2019-03-22T16:05:00.000Z + + - python-feedgen + 2 Combined summary - Payjoin privacy with the receiver of the transaction - 2023-08-02T00:39:24.662438+00:00 + 2025-09-26T15:47:43.203009+00:00 - The discussion revolves around the idea of enhancing privacy in Bitcoin transactions through the use of payjoin and "pre-fragmenting" wallets. However, it is acknowledged that this approach may not be practical for everyday users due to cost-ineffectiveness and resulting large transactions. To address privacy concerns with payjoin, a proposed solution involves automatically splitting the balance into multiple addresses with smaller amounts when a high-value bitcoin amount is received, such as $100 or more. This would prevent the recipient from being able to determine the total balance held by the sender. However, it is recognized that this feature may not be feasible for all users due to the larger and less cost-effective transactions it would entail.It is noted that small amount addresses combined with payjoin can provide real privacy to Bitcoin users, but different coin selection and utxo management strategies may be necessary depending on individual user preferences. Those who prioritize privacy can enable the auto-splitting feature in their wallet, while those who do not require privacy can disable it.A key concern regarding payjoin is the potential privacy leak when a user sends a payment from an address containing a larger amount than the intended transfer. To mitigate this issue, a suggested solution is to implement a wallet check that ensures no address contains more than a designated "safe" amount, such as 0.01 BTC or less. If an address exceeds this amount, the wallet could automatically make a self-payment to split the balance into several addresses, preventing the recipient from deducing the sender's total bitcoin balance.Overall, the discussion emphasizes the tradeoffs involved in coin selection, utxo management, and payjoin contributed input selection. It highlights the importance of considering individual needs and preferences when using a Bitcoin wallet. 2019-03-22T16:05:13+00:00 + The discussion revolves around the idea of enhancing privacy in Bitcoin transactions through the use of payjoin and "pre-fragmenting" wallets. However, it is acknowledged that this approach may not be practical for everyday users due to cost-ineffectiveness and resulting large transactions. To address privacy concerns with payjoin, a proposed solution involves automatically splitting the balance into multiple addresses with smaller amounts when a high-value bitcoin amount is received, such as $100 or more. This would prevent the recipient from being able to determine the total balance held by the sender. However, it is recognized that this feature may not be feasible for all users due to the larger and less cost-effective transactions it would entail.It is noted that small amount addresses combined with payjoin can provide real privacy to Bitcoin users, but different coin selection and utxo management strategies may be necessary depending on individual user preferences. Those who prioritize privacy can enable the auto-splitting feature in their wallet, while those who do not require privacy can disable it.A key concern regarding payjoin is the potential privacy leak when a user sends a payment from an address containing a larger amount than the intended transfer. To mitigate this issue, a suggested solution is to implement a wallet check that ensures no address contains more than a designated "safe" amount, such as 0.01 BTC or less. If an address exceeds this amount, the wallet could automatically make a self-payment to split the balance into several addresses, preventing the recipient from deducing the sender's total bitcoin balance.Overall, the discussion emphasizes the tradeoffs involved in coin selection, utxo management, and payjoin contributed input selection. It highlights the importance of considering individual needs and preferences when using a Bitcoin wallet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_Pre-BIP-Solving-for-spam-and-other-abuse-with-an-HTLB.xml b/static/bitcoin-dev/March_2019/combined_Pre-BIP-Solving-for-spam-and-other-abuse-with-an-HTLB.xml index 509daafc66..db5ad15dde 100644 --- a/static/bitcoin-dev/March_2019/combined_Pre-BIP-Solving-for-spam-and-other-abuse-with-an-HTLB.xml +++ b/static/bitcoin-dev/March_2019/combined_Pre-BIP-Solving-for-spam-and-other-abuse-with-an-HTLB.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Pre BIP: Solving for spam and other abuse with an HTLB - 2023-08-02T00:37:49.242849+00:00 - - ZmnSCPxj 2019-03-19 00:22:25+00:00 - - - ZmnSCPxj 2019-03-18 04:22:52+00:00 - - - Alistair Mann 2019-03-17 20:27:35+00:00 - - - Alistair Mann 2019-03-17 16:11:29+00:00 - - - ZmnSCPxj 2019-03-12 04:14:54+00:00 - - - Alistair Mann 2019-03-11 16:01:12+00:00 - + 2025-09-26T15:47:47.385591+00:00 + python-feedgen + + + [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB Alistair Mann + 2019-03-11T16:01:00.000Z + + + ZmnSCPxj + 2019-03-12T04:14:00.000Z + + + Alistair Mann + 2019-03-17T16:11:00.000Z + + + Alistair Mann + 2019-03-17T20:27:00.000Z + + + ZmnSCPxj + 2019-03-18T04:22:00.000Z + + + ZmnSCPxj + 2019-03-19T00:22:00.000Z + + - python-feedgen + 2 Combined summary - Pre BIP: Solving for spam and other abuse with an HTLB - 2023-08-02T00:37:49.243849+00:00 + 2025-09-26T15:47:47.386567+00:00 - Alistair Mann and ZmnSCPxj have been discussing a potential Bitcoin Improvement Proposal (BIP) for "Good Behaviour Bonds". ZmnSCPxj suggests using Hashed Time-Locked Bonds (HTLB) over Hashed Time-Locked Contracts (HTLC) to improve privacy. However, this would require the redundant and HASHOP not to be standardized. The conversation then shifts to whether Bob could immediately fail the HTLB to Alice's benefit, leading Alistair to modify his proof-of-concept code to investigate this change.ZmnSCPxj suggests an early return to Alice without any input from her, and describes the overall flow of messages involved in the process. This involves Alice sending the preimage, HASHOP, and a new address for "early return", making a transaction to the HTLC pattern. Bob has until the HASHOP timeout to decide whether to claim the money or return it to Alice, and if he hasn't decided by the timeout, Alice can get her money back.ZmnSCPxj also proposes a Funding Transaction Pattern that improves privacy by keeping a script offline. It would use HTLB over HTLC to make it indistinguishable on-chain from other uses of HTLC and add to privacy. The redundant would have to be given by Alice to Bob to hide the use of HTLB over HTLC among other HTLC UTXOs.Alistair Mann welcomes the Funding Transaction Pattern and acknowledges that it would improve the mainnet's use of scripts. He also expresses gratitude to those who provided feedback on his proposal for the BIP, including non-bot visitors to the berewic.com site. He plans to submit a formal write-up for the BIP assuming no major changes.In summary, Alistair Mann received feedback on his proposed BIP for "Good Behaviour Bonds" involving HTLB and HTLC. ZmnSCPxj suggests using HTLB over HTLC to improve privacy and proposes a Funding Transaction Pattern to keep the script offline. The conversation also explores the possibility of Bob immediately failing the HTLB to benefit Alice. Alistair Mann welcomes the suggestions and plans to submit a formal write-up for the BIP based on community feedback. 2019-03-19T00:22:25+00:00 + Alistair Mann and ZmnSCPxj have been discussing a potential Bitcoin Improvement Proposal (BIP) for "Good Behaviour Bonds". ZmnSCPxj suggests using Hashed Time-Locked Bonds (HTLB) over Hashed Time-Locked Contracts (HTLC) to improve privacy. However, this would require the redundant and HASHOP not to be standardized. The conversation then shifts to whether Bob could immediately fail the HTLB to Alice's benefit, leading Alistair to modify his proof-of-concept code to investigate this change.ZmnSCPxj suggests an early return to Alice without any input from her, and describes the overall flow of messages involved in the process. This involves Alice sending the preimage, HASHOP, and a new address for "early return", making a transaction to the HTLC pattern. Bob has until the HASHOP timeout to decide whether to claim the money or return it to Alice, and if he hasn't decided by the timeout, Alice can get her money back.ZmnSCPxj also proposes a Funding Transaction Pattern that improves privacy by keeping a script offline. It would use HTLB over HTLC to make it indistinguishable on-chain from other uses of HTLC and add to privacy. The redundant would have to be given by Alice to Bob to hide the use of HTLB over HTLC among other HTLC UTXOs.Alistair Mann welcomes the Funding Transaction Pattern and acknowledges that it would improve the mainnet's use of scripts. He also expresses gratitude to those who provided feedback on his proposal for the BIP, including non-bot visitors to the berewic.com site. He plans to submit a formal write-up for the BIP assuming no major changes.In summary, Alistair Mann received feedback on his proposed BIP for "Good Behaviour Bonds" involving HTLB and HTLC. ZmnSCPxj suggests using HTLB over HTLC to improve privacy and proposes a Funding Transaction Pattern to keep the script offline. The conversation also explores the possibility of Bob immediately failing the HTLB to benefit Alice. Alistair Mann welcomes the suggestions and plans to submit a formal write-up for the BIP based on community feedback. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_Privacy-literature-review.xml b/static/bitcoin-dev/March_2019/combined_Privacy-literature-review.xml index 98dc06bdf1..07acf0d4d3 100644 --- a/static/bitcoin-dev/March_2019/combined_Privacy-literature-review.xml +++ b/static/bitcoin-dev/March_2019/combined_Privacy-literature-review.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Privacy literature review - 2023-08-02T00:31:34.989521+00:00 - - Adam Ficsor 2019-03-06 14:28:02+00:00 - - - Chris Belcher 2019-02-23 20:17:17+00:00 - + 2025-09-26T15:47:28.500442+00:00 + python-feedgen + + + [bitcoin-dev] Privacy literature review Chris Belcher + 2019-02-23T20:17:00.000Z + + + Adam Ficsor + 2019-03-06T14:28:00.000Z + + - python-feedgen + 2 Combined summary - Privacy literature review - 2023-08-02T00:31:34.989521+00:00 + 2025-09-26T15:47:28.500866+00:00 - Ádám Ficsór, a member of the Bitcoin community, expressed his gratitude for Chris Belcher's work on a comprehensive literature review focused on Bitcoin privacy. This literature review, which can be accessed on the Bitcoin Wiki, covers all aspects of privacy in Bitcoin, including the Lightning network. Notably, it includes practical examples to illustrate the concepts discussed. Belcher has also created a new wiki category that contains smaller articles related to Bitcoin privacy.Ficsór mentioned that he is contributing to the same cause by delivering presentations on the topic. These presentations will eventually become a six-part series, with the first two parts already available. The initial presentation delves into network level privacy, while the second part focuses on blockchain level privacy. Both presentations can be found using the provided links.In conclusion, the author of the email, signed off as "CB," has been diligently working on a literature review regarding Bitcoin privacy. This review comprehensively addresses privacy concerns in Bitcoin, including the Lightning Network, and provides practical examples. Additionally, the author has established a new wiki category for smaller articles related to Bitcoin privacy, further contributing to the community's understanding of this important subject. 2019-03-06T14:28:02+00:00 + Ádám Ficsór, a member of the Bitcoin community, expressed his gratitude for Chris Belcher's work on a comprehensive literature review focused on Bitcoin privacy. This literature review, which can be accessed on the Bitcoin Wiki, covers all aspects of privacy in Bitcoin, including the Lightning network. Notably, it includes practical examples to illustrate the concepts discussed. Belcher has also created a new wiki category that contains smaller articles related to Bitcoin privacy.Ficsór mentioned that he is contributing to the same cause by delivering presentations on the topic. These presentations will eventually become a six-part series, with the first two parts already available. The initial presentation delves into network level privacy, while the second part focuses on blockchain level privacy. Both presentations can be found using the provided links.In conclusion, the author of the email, signed off as "CB," has been diligently working on a literature review regarding Bitcoin privacy. This review comprehensively addresses privacy concerns in Bitcoin, including the Lightning Network, and provides practical examples. Additionally, the author has established a new wiki category for smaller articles related to Bitcoin privacy, further contributing to the community's understanding of this important subject. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_Removal-of-reject-network-messages-from-Bitcoin-Core-BIP61-.xml b/static/bitcoin-dev/March_2019/combined_Removal-of-reject-network-messages-from-Bitcoin-Core-BIP61-.xml index 924582ce05..3ca95b6b8f 100644 --- a/static/bitcoin-dev/March_2019/combined_Removal-of-reject-network-messages-from-Bitcoin-Core-BIP61-.xml +++ b/static/bitcoin-dev/March_2019/combined_Removal-of-reject-network-messages-from-Bitcoin-Core-BIP61-.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Removal of reject network messages from Bitcoin Core (BIP61) - 2023-08-02T00:34:07.125703+00:00 - - Andreas Schildbach 2019-10-21 08:44:16+00:00 - - - Eric Voskuil 2019-10-20 05:13:12+00:00 - - - David A. Harding 2019-10-18 22:45:35+00:00 - - - John Newbery 2019-10-18 20:53:23+00:00 - - - Eric Voskuil 2019-10-17 20:16:47+00:00 - - - Andreas Schildbach 2019-10-17 19:38:53+00:00 - - - John Newbery 2019-10-16 16:43:53+00:00 - - - Aymeric Vitte 2019-03-14 09:46:28+00:00 - - - Dustin Dettmer 2019-03-13 22:30:44+00:00 - - - Oscar Guindzberg 2019-03-13 14:41:50+00:00 - - - Andreas Schildbach 2019-03-13 14:29:43+00:00 - - - Gregory Maxwell 2019-03-12 22:14:10+00:00 - - - Andreas Schildbach 2019-03-12 17:08:52+00:00 - - - Gregory Maxwell 2019-03-08 00:52:56+00:00 - - - Eric Voskuil 2019-03-08 00:30:51+00:00 - - - Wilmer Paulino 2019-03-08 00:09:01+00:00 - - - Aymeric Vitte 2019-03-07 20:52:33+00:00 - - - Andreas Schildbach 2019-03-07 17:58:01+00:00 - - - Sjors Provoost 2019-03-07 13:59:47+00:00 - - - Andreas Schildbach 2019-03-06 16:49:20+00:00 - - - Dustin Dettmer 2019-03-06 04:00:35+00:00 - - - Marco Falke 2019-03-06 00:53:18+00:00 - + 2025-09-26T15:47:26.412897+00:00 + python-feedgen + + + [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) Marco Falke + 2019-03-06T00:53:00.000Z + + + Dustin Dettmer + 2019-03-06T04:00:00.000Z + + + Andreas Schildbach + 2019-03-06T16:49:00.000Z + + + Sjors Provoost + 2019-03-07T13:59:00.000Z + + + Andreas Schildbach + 2019-03-07T17:58:00.000Z + + + Aymeric Vitte + 2019-03-07T20:52:00.000Z + + + Wilmer Paulino + 2019-03-08T00:09:00.000Z + + + Eric Voskuil + 2019-03-08T00:30:00.000Z + + + Gregory Maxwell + 2019-03-08T00:52:00.000Z + + + Andreas Schildbach + 2019-03-12T17:08:00.000Z + + + Gregory Maxwell + 2019-03-12T22:14:00.000Z + + + Andreas Schildbach + 2019-03-13T14:29:00.000Z + + + Oscar Guindzberg + 2019-03-13T14:41:00.000Z + + + Dustin Dettmer + 2019-03-13T22:30:00.000Z + + + Aymeric Vitte + 2019-03-14T09:46:00.000Z + + + John Newbery + 2019-10-16T16:43:00.000Z + + + Andreas Schildbach + 2019-10-17T19:38:00.000Z + + + Eric Voskuil + 2019-10-17T20:16:00.000Z + + + John Newbery + 2019-10-18T20:53:00.000Z + + + David A. Harding + 2019-10-18T22:45:00.000Z + + + Eric Voskuil + 2019-10-20T05:13:00.000Z + + + Andreas Schildbach + 2019-10-21T08:44:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Removal of reject network messages from Bitcoin Core (BIP61) - 2023-08-02T00:34:07.125703+00:00 + 2025-09-26T15:47:26.415256+00:00 - In a recent discussion on the bitcoin-dev mailing list, the use of "reject" messages in the Bitcoin network was debated. It was argued that nodes on the network cannot be trusted to send valid reject messages, so this feature should only be used when connected to a trusted node. However, it was also pointed out that nodes generally rely on the assumption they are connected to at least one honest peer, allowing for a convergence on the set of honest peers and the ability to ban or disconnect those who send invalid reject messages for valid transactions.Bitcoin Core developer, Marco Falke, proposed removing the reject message feature from Bitcoin Core to make the codebase slimmer. However, it was noted that Neutrino, a light client implementation, currently relies on receiving reject messages from its peers when broadcasting a transaction to the network. Despite this, Falke believes that removing the feature would help in terms of comprehension and maintainability. The alternative recommended by Falke is not suitable for use cases where the main thing required is identification of whether a broadcasted transaction is valid or not. Reject messages are also useful when developing new light clients, as feedback from the network on why a transaction was rejected helps identify potential bugs in their transaction crafting logic. While Falke suggested testing the validity of a transaction through specific RPCs, such as `sendrawtransaction` and `testmempoolaccept`, these are not helpful for light clients. Therefore, it is believed that disabling the reject message feature by default would hinder light clients' ability to realize they are broadcasting invalid transactions. Thus, the feature should remain enabled by default to aid the light clients of the network.Bitcoin Core may remove the reject messages feature from its system, as it has been disabled by default since version 0.18.0. This feature is toggled by the `-enablebip61` command line option. Developers have proposed alternative testing methods for those who rely on the feature, including inspecting log messages produced by a recent version of Bitcoin Core, using specific RPCs to test the validity of blocks and transactions, and relying on fee estimation to determine transaction fees and setting replace-by-fee if desired. The proposal to remove the feature from Bitcoin Core 0.19.0 has been made unless there are valid concerns about its removal.Overall, the debate centers around the trustworthiness of reject messages sent by nodes on the Bitcoin network. While some argue that this feature should only be used when connected to trusted nodes, others believe that removing it would make the codebase slimmer and easier to maintain. However, alternative testing methods have been proposed, and it is important to consider the impact on light clients and their ability to identify and correct invalid transactions. 2019-10-21T08:44:16+00:00 + In a recent discussion on the bitcoin-dev mailing list, the use of "reject" messages in the Bitcoin network was debated. It was argued that nodes on the network cannot be trusted to send valid reject messages, so this feature should only be used when connected to a trusted node. However, it was also pointed out that nodes generally rely on the assumption they are connected to at least one honest peer, allowing for a convergence on the set of honest peers and the ability to ban or disconnect those who send invalid reject messages for valid transactions.Bitcoin Core developer, Marco Falke, proposed removing the reject message feature from Bitcoin Core to make the codebase slimmer. However, it was noted that Neutrino, a light client implementation, currently relies on receiving reject messages from its peers when broadcasting a transaction to the network. Despite this, Falke believes that removing the feature would help in terms of comprehension and maintainability. The alternative recommended by Falke is not suitable for use cases where the main thing required is identification of whether a broadcasted transaction is valid or not. Reject messages are also useful when developing new light clients, as feedback from the network on why a transaction was rejected helps identify potential bugs in their transaction crafting logic. While Falke suggested testing the validity of a transaction through specific RPCs, such as `sendrawtransaction` and `testmempoolaccept`, these are not helpful for light clients. Therefore, it is believed that disabling the reject message feature by default would hinder light clients' ability to realize they are broadcasting invalid transactions. Thus, the feature should remain enabled by default to aid the light clients of the network.Bitcoin Core may remove the reject messages feature from its system, as it has been disabled by default since version 0.18.0. This feature is toggled by the `-enablebip61` command line option. Developers have proposed alternative testing methods for those who rely on the feature, including inspecting log messages produced by a recent version of Bitcoin Core, using specific RPCs to test the validity of blocks and transactions, and relying on fee estimation to determine transaction fees and setting replace-by-fee if desired. The proposal to remove the feature from Bitcoin Core 0.19.0 has been made unless there are valid concerns about its removal.Overall, the debate centers around the trustworthiness of reject messages sent by nodes on the Bitcoin network. While some argue that this feature should only be used when connected to trusted nodes, others believe that removing it would make the codebase slimmer and easier to maintain. However, alternative testing methods have been proposed, and it is important to consider the impact on light clients and their ability to identify and correct invalid transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_Sighash-Type-Byte-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml b/static/bitcoin-dev/March_2019/combined_Sighash-Type-Byte-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml index 33344e2d8a..a245f8ee30 100644 --- a/static/bitcoin-dev/March_2019/combined_Sighash-Type-Byte-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml +++ b/static/bitcoin-dev/March_2019/combined_Sighash-Type-Byte-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup - 2023-08-02T00:37:12.107474+00:00 + 2025-09-26T15:47:24.296431+00:00 + python-feedgen Russell O'Connor 2019-03-13 01:34:21+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup - 2023-08-02T00:37:12.107474+00:00 + 2025-09-26T15:47:24.296614+00:00 - In an email exchange, Russell O'Connor and Matt Corallo discuss the possibility of removing certain aspects of the Bitcoin protocol through a soft-fork. O'Connor suggests classifying nSequence numbers, NOP1-NOP10, and extra sighash types as redundant and removing them. However, Corallo argues that even carve-outs for OP_NOP may not be sufficient in some cases. He believes soft forks should invalidate unused bits of the protocol, similar to OP_NOPs. While sighash bits are less likely candidates for soft-forking, Corallo sees no issue with removing them if they are redundant and not in use.O'Connor disagrees, stating that these bits are unsuitable for soft-forking within legacy Script. He argues that random bits inserted into locked-for-more-than-a-year transactions are not sufficient reason to not soft-fork them out. He points out the lack of precedent for soft-forking out working transactions unless the security of the Bitcoin protocol itself is at risk. O'Connor believes crossing this line should only happen under existential threats.Corallo suggests that the reason these bits are not seen in use on the blockchain could be because users trying to use them are caught up in the fact that they are not being relayed by default and violating SCRIPT_VERIFY_STRICTENC. He argues that making transactions non-standard and then using their lack of usage to justify a soft-fork is unacceptable.O'Connor counters with examples of users whose funds are tied up due to other changes in Bitcoin Core's default relay policy. He believes permanently destroying their funds before their transactions have a chance to get mined would be unfair. The exchange highlights the debate around whether certain aspects of the Bitcoin protocol should be removed via soft-fork and the potential consequences of doing so.The discussion also touches on default relay policies and how changes to them can affect users' ability to use certain transactions. Ultimately, there is disagreement between the two individuals on whether the potential harm caused by removing these bits outweighs the benefits of simplifying the transaction format.In addition to the debate on removing certain bits, there is a discussion on disabling unused bits within the sighash type byte. The author proposes that since these bits are not in use, they could be soft-forked out without significant impact, comparing them to OP_NOPs. However, O'Connor argues that the sighash type byte is useful for storing ancillary data during signatures. He suggests that some users may have unbroadcast transactions in cold storage with UTXOs whose private keys may have been lost, making disabling these sighashes risky. O'Connor proposes an alternative proposal of caching the just-before-the-last-byte sighash midstate instead.The sighash type byte plays a crucial role in signature evaluation during Bitcoin scripting operations. However, if this byte is anything other than specific values, script execution fails. Despite this limitation, some users have been utilizing the sighash type byte to store additional data during signatures. This usage means that there may be unbroadcast transactions in cold storage with UTXOs whose private keys are lost. While the risk of disabling these sighashes may seem low, O'Connor argues that it could put people's funds at risk. He suggests considering an alternative proposal of caching the just-before-the-last-byte sighash midstate before implementing any changes to the Bitcoin protocol. 2019-03-13T01:34:21+00:00 + In an email exchange, Russell O'Connor and Matt Corallo discuss the possibility of removing certain aspects of the Bitcoin protocol through a soft-fork. O'Connor suggests classifying nSequence numbers, NOP1-NOP10, and extra sighash types as redundant and removing them. However, Corallo argues that even carve-outs for OP_NOP may not be sufficient in some cases. He believes soft forks should invalidate unused bits of the protocol, similar to OP_NOPs. While sighash bits are less likely candidates for soft-forking, Corallo sees no issue with removing them if they are redundant and not in use.O'Connor disagrees, stating that these bits are unsuitable for soft-forking within legacy Script. He argues that random bits inserted into locked-for-more-than-a-year transactions are not sufficient reason to not soft-fork them out. He points out the lack of precedent for soft-forking out working transactions unless the security of the Bitcoin protocol itself is at risk. O'Connor believes crossing this line should only happen under existential threats.Corallo suggests that the reason these bits are not seen in use on the blockchain could be because users trying to use them are caught up in the fact that they are not being relayed by default and violating SCRIPT_VERIFY_STRICTENC. He argues that making transactions non-standard and then using their lack of usage to justify a soft-fork is unacceptable.O'Connor counters with examples of users whose funds are tied up due to other changes in Bitcoin Core's default relay policy. He believes permanently destroying their funds before their transactions have a chance to get mined would be unfair. The exchange highlights the debate around whether certain aspects of the Bitcoin protocol should be removed via soft-fork and the potential consequences of doing so.The discussion also touches on default relay policies and how changes to them can affect users' ability to use certain transactions. Ultimately, there is disagreement between the two individuals on whether the potential harm caused by removing these bits outweighs the benefits of simplifying the transaction format.In addition to the debate on removing certain bits, there is a discussion on disabling unused bits within the sighash type byte. The author proposes that since these bits are not in use, they could be soft-forked out without significant impact, comparing them to OP_NOPs. However, O'Connor argues that the sighash type byte is useful for storing ancillary data during signatures. He suggests that some users may have unbroadcast transactions in cold storage with UTXOs whose private keys may have been lost, making disabling these sighashes risky. O'Connor proposes an alternative proposal of caching the just-before-the-last-byte sighash midstate instead.The sighash type byte plays a crucial role in signature evaluation during Bitcoin scripting operations. However, if this byte is anything other than specific values, script execution fails. Despite this limitation, some users have been utilizing the sighash type byte to store additional data during signatures. This usage means that there may be unbroadcast transactions in cold storage with UTXOs whose private keys are lost. While the risk of disabling these sighashes may seem low, O'Connor argues that it could put people's funds at risk. He suggests considering an alternative proposal of caching the just-before-the-last-byte sighash midstate before implementing any changes to the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2019/combined_Signet.xml b/static/bitcoin-dev/March_2019/combined_Signet.xml index f381969582..7796bdb580 100644 --- a/static/bitcoin-dev/March_2019/combined_Signet.xml +++ b/static/bitcoin-dev/March_2019/combined_Signet.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Signet - 2023-08-02T00:37:33.042881+00:00 + 2025-09-26T15:47:30.614003+00:00 + python-feedgen Karl-Johan Alm 2019-03-14 01:17:31+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Signet - 2023-08-02T00:37:33.042881+00:00 + 2025-09-26T15:47:30.614189+00:00 - Dear Varunram,Thank you for expressing your concerns regarding the use of a common signet controlled by a trusted entity. While using a signet would be beneficial in testing reorgs, it is important to consider the potential issues that may arise. The maintainer's unscheduled work or emergencies could impact the testing process, and people would need to run Signet1 nodes in parallel with current testnet nodes. To test Signet on a global scale, individuals can spin up nodes in various locations and use centralized services like AWS.In an email exchange between Anthony Towns and Kalle Alm, the idea of making signatures optional in headers was discussed. This would allow for "light nodes" that don't download or verify signatures. Signatures would only sign the traditional 80-byte header and wouldn't be included in the block's tx merkle root. However, this approach comes with added complexity, as signature-aware nodes would need to reject headers sent from non-signature-aware nodes. One solution proposed is to enforce including the previous block's header signature in the current block's coinbase.Matt Corallo suggested keeping the existing block header format and applying signature rules to a field in the coinbase transaction for easier testing. However, there are concerns that this approach could make DoS attacks easier. David A. Harding proposed connecting lite clients to trusted nodes on signet to protect against missing/invalid-signature DoS.The idea of moving digital signatures from Bitcoin blocks to help with scaling and reduce block size was discussed. It was suggested that users could connect their lite clients to trusted nodes on signet to protect against missing/invalid-signature DoS. Trusted signer Alice and Bob were proposed as multiple keys to sign blocks, allowing users to choose their preferred behavior.Karl-Johan Alm proposed a new network called "signet" as a centralized alternative to the existing testnet. Signet blocks are signed by a specific key instead of using proof of work, offering predictability, stability, and ease of global testing. Anyone can create a signet by creating a key pair and a challenge scriptPubKey. A default persistent "signet1" is proposed to be created, which can be replaced in future versions if necessary.In conclusion, the introduction of signet as a complement to the existing testnet provides benefits such as predictability, stability, and ease of global testing. However, it is important to address concerns regarding the potential impact of unscheduled work or emergencies on the testing process. The discussion also explored the idea of making signatures optional in headers and connecting lite clients to trusted nodes on signet. Overall, the implementation of signet would enhance the Bitcoin protocol's testing capabilities and provide a more stable and predictable environment for developers.Best regards,Kalle 2019-03-14T01:17:31+00:00 + Dear Varunram,Thank you for expressing your concerns regarding the use of a common signet controlled by a trusted entity. While using a signet would be beneficial in testing reorgs, it is important to consider the potential issues that may arise. The maintainer's unscheduled work or emergencies could impact the testing process, and people would need to run Signet1 nodes in parallel with current testnet nodes. To test Signet on a global scale, individuals can spin up nodes in various locations and use centralized services like AWS.In an email exchange between Anthony Towns and Kalle Alm, the idea of making signatures optional in headers was discussed. This would allow for "light nodes" that don't download or verify signatures. Signatures would only sign the traditional 80-byte header and wouldn't be included in the block's tx merkle root. However, this approach comes with added complexity, as signature-aware nodes would need to reject headers sent from non-signature-aware nodes. One solution proposed is to enforce including the previous block's header signature in the current block's coinbase.Matt Corallo suggested keeping the existing block header format and applying signature rules to a field in the coinbase transaction for easier testing. However, there are concerns that this approach could make DoS attacks easier. David A. Harding proposed connecting lite clients to trusted nodes on signet to protect against missing/invalid-signature DoS.The idea of moving digital signatures from Bitcoin blocks to help with scaling and reduce block size was discussed. It was suggested that users could connect their lite clients to trusted nodes on signet to protect against missing/invalid-signature DoS. Trusted signer Alice and Bob were proposed as multiple keys to sign blocks, allowing users to choose their preferred behavior.Karl-Johan Alm proposed a new network called "signet" as a centralized alternative to the existing testnet. Signet blocks are signed by a specific key instead of using proof of work, offering predictability, stability, and ease of global testing. Anyone can create a signet by creating a key pair and a challenge scriptPubKey. A default persistent "signet1" is proposed to be created, which can be replaced in future versions if necessary.In conclusion, the introduction of signet as a complement to the existing testnet provides benefits such as predictability, stability, and ease of global testing. However, it is important to address concerns regarding the potential impact of unscheduled work or emergencies on the testing process. The discussion also explored the idea of making signatures optional in headers and connecting lite clients to trusted nodes on signet. Overall, the implementation of signet would enhance the Bitcoin protocol's testing capabilities and provide a more stable and predictable environment for developers.Best regards,Kalle - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_BIP-340-updates-even-pubkeys-more-secure-nonce-generation.xml b/static/bitcoin-dev/March_2020/combined_BIP-340-updates-even-pubkeys-more-secure-nonce-generation.xml index d99b2f0e65..fa8efbbbb1 100644 --- a/static/bitcoin-dev/March_2020/combined_BIP-340-updates-even-pubkeys-more-secure-nonce-generation.xml +++ b/static/bitcoin-dev/March_2020/combined_BIP-340-updates-even-pubkeys-more-secure-nonce-generation.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP 340 updates: even pubkeys, more secure nonce generation - 2023-08-02T01:51:58.348605+00:00 - - Lloyd Fournier 2020-03-22 05:51:59+00:00 - - - Lloyd Fournier 2020-02-27 04:55:21+00:00 - - - Jonas Nick 2020-02-26 15:34:04+00:00 - - - Lloyd Fournier 2020-02-26 04:20:58+00:00 - - - Pieter Wuille 2020-02-24 04:26:17+00:00 - + 2025-09-26T15:34:41.742832+00:00 + python-feedgen + + + [bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation Pieter Wuille + 2020-02-24T04:26:00.000Z + + + [bitcoin-dev] Fwd: " Russell O'Connor + 2020-02-26T03:26:00.000Z + + + [bitcoin-dev] " Lloyd Fournier + 2020-02-26T04:20:00.000Z + + + Jonas Nick + 2020-02-26T15:34:00.000Z + + + Lloyd Fournier + 2020-02-27T04:55:00.000Z + + + Lloyd Fournier + 2020-03-22T05:51:00.000Z + + - python-feedgen + 2 Combined summary - BIP 340 updates: even pubkeys, more secure nonce generation - 2023-08-02T01:51:58.348605+00:00 + 2025-09-26T15:34:41.743726+00:00 - The bitcoin-dev mailing list has been discussing the need to protect against differential power analysis, which is a method used to extract sensitive information from cryptographic systems by analyzing their power consumption. The traditional method of mixing randomness was found to be vulnerable, so a different approach is now being recommended. This involves completely masking the private key with randomness before continuing. The writer suggests that including this method in the specification would be beneficial. They also raise concerns about the vulnerability of hardware wallets to these attacks during key derivation, as getting side channel information from hashes in nonce derivation means getting it from hashes in HD key derivation as well.In the discussion on BIP 340-342, two changes have been proposed. The first change involves modifying the Y coordinate of 32-byte public keys from implicitly square to implicitly even. This change will make signing slightly faster and verification negligibly slower. Importantly, it simplifies integration with existing key generation infrastructure like BIP32 and PSBT. The second change focuses on more secure nonce generation. It is recommended to include actual signing-time randomness into the nonce generation process to protect against fault injection attacks and differential power analysis. These changes aim to improve the security of the specification while still allowing optimization for use cases. One participant suggests that specifying the most minimal way to produce a signature securely is the most useful thing for the document, while another participant emphasizes the importance of a standard for nonce exfiltration protection and MuSig for compatibility across wallets. To ensure consistent failure of code written for earlier BIP texts, new tagged hash tags have been introduced.Pieter Wuille, a Bitcoin Core developer and co-founder of Blockstream, has made several small changes to BIP 340-342, despite initially stating that no further semantical changes were expected. In the first change, the Y coordinate of 32-byte public keys is changed from implicitly square to implicitly even. This modification improves signing speed, simplifies integration with existing key generation infrastructure, and has minimal impact on verification speed. The second change focuses on more secure nonce generation by including the public key in the process, incorporating actual signing-time randomness, and using a different method of mixing in this randomness to protect against differential power analysis. Additionally, new tagged hash tags have been added to ensure consistent failure of code written for earlier BIP texts.Pieter Wuille's updates to BIP 340-342 proposals aim to improve the security of the specifications. These changes include modifying the Y-coordinate of 32-byte public keys, enhancing nonce generation security, and adjusting tagged hash tags. Most changes are related to more secure nonce generation, with only one change affecting validation rules. The Y coordinate of the internal R point in the signature remains implicitly square. Implementers are encouraged to use precomputed values for public key data and include it in the nonce generation to mitigate the risk of private key leakage. A different method of mixing randomness is used to protect against differential power analysis. The modified tagged hash tags ensure consistent failure of code written for earlier BIP texts. 2020-03-22T05:51:59+00:00 + The bitcoin-dev mailing list has been discussing the need to protect against differential power analysis, which is a method used to extract sensitive information from cryptographic systems by analyzing their power consumption. The traditional method of mixing randomness was found to be vulnerable, so a different approach is now being recommended. This involves completely masking the private key with randomness before continuing. The writer suggests that including this method in the specification would be beneficial. They also raise concerns about the vulnerability of hardware wallets to these attacks during key derivation, as getting side channel information from hashes in nonce derivation means getting it from hashes in HD key derivation as well.In the discussion on BIP 340-342, two changes have been proposed. The first change involves modifying the Y coordinate of 32-byte public keys from implicitly square to implicitly even. This change will make signing slightly faster and verification negligibly slower. Importantly, it simplifies integration with existing key generation infrastructure like BIP32 and PSBT. The second change focuses on more secure nonce generation. It is recommended to include actual signing-time randomness into the nonce generation process to protect against fault injection attacks and differential power analysis. These changes aim to improve the security of the specification while still allowing optimization for use cases. One participant suggests that specifying the most minimal way to produce a signature securely is the most useful thing for the document, while another participant emphasizes the importance of a standard for nonce exfiltration protection and MuSig for compatibility across wallets. To ensure consistent failure of code written for earlier BIP texts, new tagged hash tags have been introduced.Pieter Wuille, a Bitcoin Core developer and co-founder of Blockstream, has made several small changes to BIP 340-342, despite initially stating that no further semantical changes were expected. In the first change, the Y coordinate of 32-byte public keys is changed from implicitly square to implicitly even. This modification improves signing speed, simplifies integration with existing key generation infrastructure, and has minimal impact on verification speed. The second change focuses on more secure nonce generation by including the public key in the process, incorporating actual signing-time randomness, and using a different method of mixing in this randomness to protect against differential power analysis. Additionally, new tagged hash tags have been added to ensure consistent failure of code written for earlier BIP texts.Pieter Wuille's updates to BIP 340-342 proposals aim to improve the security of the specifications. These changes include modifying the Y-coordinate of 32-byte public keys, enhancing nonce generation security, and adjusting tagged hash tags. Most changes are related to more secure nonce generation, with only one change affecting validation rules. The Y coordinate of the internal R point in the signature remains implicitly square. Implementers are encouraged to use precomputed values for public key data and include it in the nonce generation to mitigate the risk of private key leakage. A different method of mixing randomness is used to protect against differential power analysis. The modified tagged hash tags ensure consistent failure of code written for earlier BIP texts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown-question-poll.xml b/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown-question-poll.xml index d9dccb35b9..9edb7417a7 100644 --- a/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown-question-poll.xml +++ b/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown-question-poll.xml @@ -1,44 +1,71 @@ - + 2 Combined summary - Block solving slowdown question/poll - 2023-08-02T01:56:23.687830+00:00 - - ZmnSCPxj 2020-03-28 02:12:37+00:00 - - - Andrew Cann 2020-03-27 09:17:34+00:00 - - - ZmnSCPxj 2020-03-26 01:42:22+00:00 - - - Andrew Cann 2020-03-25 15:23:02+00:00 - - - ZmnSCPxj 2020-03-24 07:42:46+00:00 - - - Dave Scotese 2020-03-23 18:39:05+00:00 - - - Andrew Cann 2020-03-23 12:59:22+00:00 - - - Dave Scotese 2020-03-22 18:17:26+00:00 - - - Eric Voskuil 2020-03-22 16:54:19+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2020-03-22 11:58:33+00:00 - - - David A. Harding 2020-03-22 07:54:15+00:00 - - - Dave Scotese 2020-03-21 18:40:24+00:00 - + 2025-09-26T15:34:50.148883+00:00 + python-feedgen + + + [bitcoin-dev] Block solving slowdown question/poll Dave Scotese + 2020-03-21T18:40:00.000Z + + + David A. Harding + 2020-03-22T07:54:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2020-03-22T11:58:00.000Z + + + Eric Voskuil + 2020-03-22T16:54:00.000Z + + + Dave Scotese + 2020-03-22T18:17:00.000Z + + + Andrew Cann + 2020-03-23T12:59:00.000Z + + + Dave Scotese + 2020-03-23T18:39:00.000Z + + + ZmnSCPxj + 2020-03-24T07:42:00.000Z + + + Andrew Cann + 2020-03-25T15:23:00.000Z + + + ZmnSCPxj + 2020-03-26T01:42:00.000Z + + + Andrew Cann + 2020-03-27T09:17:00.000Z + + + ZmnSCPxj + 2020-03-28T02:12:00.000Z + + + [bitcoin-dev] Block solving slowdown Andrew Cann + 2020-03-29T08:11:00.000Z + + + ZmnSCPxj + 2020-03-30T02:59:00.000Z + + + ZmnSCPxj + 2020-03-31T02:06:00.000Z + + @@ -51,13 +78,13 @@ - python-feedgen + 2 Combined summary - Block solving slowdown question/poll - 2023-08-02T01:56:23.688832+00:00 + 2025-09-26T15:34:50.150586+00:00 - The email thread discusses several key topics related to the Bitcoin protocol and its long-term sustainability. One topic is the concern over a phenomenon in capitalism where individual self-interest can lead to undesirable outcomes for everyone involved. This is illustrated using the example of fish farms in a lake, where each farm produces waste that lowers productivity. The discussion then moves to whether a similar dynamic would occur in Bitcoin with the block weight limit and transaction fees.Another topic of discussion is the potential security risks to the Bitcoin network. There are concerns about the possibility of a 51% attack by a state actor with a warehouse full of ASICs mining empty blocks all day. Additionally, losing private keys is highlighted as a risk, as it would result in the inability to change the vote of the UTXO containing the bitcoins. The need for transaction fees to ensure security is emphasized, and the tragedy of the commons concept is explained using the example of aquaculture in a lake.The idea of increasing the Bitcoin supply beyond 21 million is considered fundamentally broken, as it would change the meaning of Bitcoin and create a contradiction in its use. The role of transaction fees as an implicit "field" for voting on the necessary security is discussed. It is noted that transaction fees are only paid when bitcoins are moved, and there is no ongoing cost for holding bitcoins. The concept of voting on security through dilution is introduced, with votes weighted by the value of the UTXO. The importance of transaction fees for maintaining security is emphasized.The proposal for allowing a non-zero block reward in Bitcoin is debated. The argument against this proposal is that it would break the fundamental meaning of Bitcoin by exceeding the 21 million limit. However, the idea of a voting system for determining the cost of security is explored, where bitcoin holders can vote on the inflation rate. The author questions if transaction fees can ever drop dangerously low and suggests alternative ideas for ensuring network security.The long-term plan for ensuring the security of the Bitcoin network as the block reward drops is discussed. The current mechanism of transaction fees and their role in voting on security is highlighted as the best-known solution. The idea of an adjustable block reward, where bitcoin holders can vote on the appropriate reward, is proposed but criticized as fundamentally broken. The potential increase in the value per byte stored in the blockchain over time is mentioned, along with the possibility of holding companies with specialized scripts to handle transactions for multiple customers.There is a discussion about the possibility of building a difficulty adjustment trigger into Bitcoin software to address potential delays in retargeting. The proposal suggests miners signaling their recognition if the expected 2016 blocks have not been mined after twice the expected wait time. This would result in an expedited difficulty adjustment for the rest of the blocks and the following difficulty period. The idea is raised for consideration as a BIP, and other emails in the thread discuss mining as a lottery and potential solutions for handling a drop in mining power.The concern over miners optimizing their mining profit by limiting the hash rate during retargeting is brought up. Holding a lottery for mining is proposed as a more profitable solution for the ecosystem. The options of doing nothing or hard forking a difficulty reduction are discussed to address block solving slowdown. The decision to do nothing is deemed suitable if bitcoins retain some value compared to the previous retarget period and most mining equipment is operational. However, a hard fork to reduce difficulty may be necessary if there is a significant drop in bitcoin price or a large fraction of mining equipment becomes unusable.The email thread also addresses a question regarding how to handle a potential drop in mining power that could delay retargeting. Two practical solutions are suggested: doing nothing or implementing a hard fork to reduce difficulty. If most mining equipment is still operational and bitcoins retain some value, doing nothing is considered the best choice. However, if the bitcoin price plummets or a large fraction of mining equipment becomes unusable, a hard fork may be necessary to maintain a sustainable difficulty level.The discussion revolves around a scenario where the mining power drops off at a rate that could potentially delay retargeting. The author seeks ideas on how to avoid such a delay and expresses confidence in the Bitcoin community's ability to address the situation. Input from others is sought on potential solutions to handle this problem and ensure the smooth functioning of the network. 2020-03-28T02:12:37+00:00 + The email thread discusses several key topics related to the Bitcoin protocol and its long-term sustainability. One topic is the concern over a phenomenon in capitalism where individual self-interest can lead to undesirable outcomes for everyone involved. This is illustrated using the example of fish farms in a lake, where each farm produces waste that lowers productivity. The discussion then moves to whether a similar dynamic would occur in Bitcoin with the block weight limit and transaction fees.Another topic of discussion is the potential security risks to the Bitcoin network. There are concerns about the possibility of a 51% attack by a state actor with a warehouse full of ASICs mining empty blocks all day. Additionally, losing private keys is highlighted as a risk, as it would result in the inability to change the vote of the UTXO containing the bitcoins. The need for transaction fees to ensure security is emphasized, and the tragedy of the commons concept is explained using the example of aquaculture in a lake.The idea of increasing the Bitcoin supply beyond 21 million is considered fundamentally broken, as it would change the meaning of Bitcoin and create a contradiction in its use. The role of transaction fees as an implicit "field" for voting on the necessary security is discussed. It is noted that transaction fees are only paid when bitcoins are moved, and there is no ongoing cost for holding bitcoins. The concept of voting on security through dilution is introduced, with votes weighted by the value of the UTXO. The importance of transaction fees for maintaining security is emphasized.The proposal for allowing a non-zero block reward in Bitcoin is debated. The argument against this proposal is that it would break the fundamental meaning of Bitcoin by exceeding the 21 million limit. However, the idea of a voting system for determining the cost of security is explored, where bitcoin holders can vote on the inflation rate. The author questions if transaction fees can ever drop dangerously low and suggests alternative ideas for ensuring network security.The long-term plan for ensuring the security of the Bitcoin network as the block reward drops is discussed. The current mechanism of transaction fees and their role in voting on security is highlighted as the best-known solution. The idea of an adjustable block reward, where bitcoin holders can vote on the appropriate reward, is proposed but criticized as fundamentally broken. The potential increase in the value per byte stored in the blockchain over time is mentioned, along with the possibility of holding companies with specialized scripts to handle transactions for multiple customers.There is a discussion about the possibility of building a difficulty adjustment trigger into Bitcoin software to address potential delays in retargeting. The proposal suggests miners signaling their recognition if the expected 2016 blocks have not been mined after twice the expected wait time. This would result in an expedited difficulty adjustment for the rest of the blocks and the following difficulty period. The idea is raised for consideration as a BIP, and other emails in the thread discuss mining as a lottery and potential solutions for handling a drop in mining power.The concern over miners optimizing their mining profit by limiting the hash rate during retargeting is brought up. Holding a lottery for mining is proposed as a more profitable solution for the ecosystem. The options of doing nothing or hard forking a difficulty reduction are discussed to address block solving slowdown. The decision to do nothing is deemed suitable if bitcoins retain some value compared to the previous retarget period and most mining equipment is operational. However, a hard fork to reduce difficulty may be necessary if there is a significant drop in bitcoin price or a large fraction of mining equipment becomes unusable.The email thread also addresses a question regarding how to handle a potential drop in mining power that could delay retargeting. Two practical solutions are suggested: doing nothing or implementing a hard fork to reduce difficulty. If most mining equipment is still operational and bitcoins retain some value, doing nothing is considered the best choice. However, if the bitcoin price plummets or a large fraction of mining equipment becomes unusable, a hard fork may be necessary to maintain a sustainable difficulty level.The discussion revolves around a scenario where the mining power drops off at a rate that could potentially delay retargeting. The author seeks ideas on how to avoid such a delay and expresses confidence in the Bitcoin community's ability to address the situation. Input from others is sought on potential solutions to handle this problem and ensure the smooth functioning of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown.xml b/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown.xml index 91ee57a22b..8a666b0693 100644 --- a/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown.xml +++ b/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block solving slowdown - 2023-08-02T02:01:20.755308+00:00 + 2025-09-26T15:34:45.943906+00:00 + python-feedgen ZmnSCPxj 2020-03-31 02:06:32+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Block solving slowdown - 2023-08-02T02:01:20.755308+00:00 + 2025-09-26T15:34:45.944052+00:00 - Miners' behavior under a new ruleset is a concern raised by the author of the message. The author argues that miners, who benefit directly from increased inflation rates and have the power to decide which transactions are added to blocks, are likely to accept attempts to delete UTXOs (Unspent Transaction Outputs) that vote for lower inflation rates and create UTXOs that vote for higher inflation rates. This would result in miners strongly controlling the inflation rate of the coin. Additionally, as inflation grants more coins to miners, they would also have more control over the value of the coin used for voting.To avoid the moral hazard of beneficiaries of higher inflation rates being the ones who determine the inflation rate, Bitcoin has a fixed inflation rate schedule.The Bitcoin system introduces a competition for limited block space, forcing users to assess how much security they are willing to pay for. This ensures that individuals pay the market rate for block space, determined by supply and demand. However, this mechanism may lead to some individuals paying less than what is required to maintain network security.Off-chain mechanisms in Bitcoin do not eliminate on-chain fees but rather distribute them across multiple logical transactions, increasing effective capacity while still maintaining on-chain fees at a level that ensures healthy blockchain operation. However, the use of Lightning nodes, one such off-chain mechanism, is not a permanent solution as they will eventually close, leading to on-chain funds being in the slow and expensive on-chain domain. Therefore, there will always be a need for a block weight limit to ensure miners can be paid.The block weight limit in Bitcoin restricts the number of transactions that can be included in a block, ensuring miners receive payment. However, each individual only has an incentive to pay the market rate for block space based on supply and demand. This creates a collective action problem, where individuals aim to pay the minimum necessary to include their transaction in a block while relying on others to cover the cost of transaction security.Although off-chain mechanisms can increase effective capacity, reducing demand for block space and transaction fees, this could lead to a decrease in miner revenue below the level required to maintain network security. Finding a solution to this problem remains an ongoing challenge. 2020-03-31T02:06:32+00:00 + Miners' behavior under a new ruleset is a concern raised by the author of the message. The author argues that miners, who benefit directly from increased inflation rates and have the power to decide which transactions are added to blocks, are likely to accept attempts to delete UTXOs (Unspent Transaction Outputs) that vote for lower inflation rates and create UTXOs that vote for higher inflation rates. This would result in miners strongly controlling the inflation rate of the coin. Additionally, as inflation grants more coins to miners, they would also have more control over the value of the coin used for voting.To avoid the moral hazard of beneficiaries of higher inflation rates being the ones who determine the inflation rate, Bitcoin has a fixed inflation rate schedule.The Bitcoin system introduces a competition for limited block space, forcing users to assess how much security they are willing to pay for. This ensures that individuals pay the market rate for block space, determined by supply and demand. However, this mechanism may lead to some individuals paying less than what is required to maintain network security.Off-chain mechanisms in Bitcoin do not eliminate on-chain fees but rather distribute them across multiple logical transactions, increasing effective capacity while still maintaining on-chain fees at a level that ensures healthy blockchain operation. However, the use of Lightning nodes, one such off-chain mechanism, is not a permanent solution as they will eventually close, leading to on-chain funds being in the slow and expensive on-chain domain. Therefore, there will always be a need for a block weight limit to ensure miners can be paid.The block weight limit in Bitcoin restricts the number of transactions that can be included in a block, ensuring miners receive payment. However, each individual only has an incentive to pay the market rate for block space based on supply and demand. This creates a collective action problem, where individuals aim to pay the minimum necessary to include their transaction in a block while relying on others to cover the cost of transaction security.Although off-chain mechanisms can increase effective capacity, reducing demand for block space and transaction fees, this could lead to a decrease in miner revenue below the level required to maintain network security. Finding a solution to this problem remains an ongoing challenge. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Hash-function-requirements-for-Taproot.xml b/static/bitcoin-dev/March_2020/combined_Hash-function-requirements-for-Taproot.xml index 9950e785d2..492d42e9ee 100644 --- a/static/bitcoin-dev/March_2020/combined_Hash-function-requirements-for-Taproot.xml +++ b/static/bitcoin-dev/March_2020/combined_Hash-function-requirements-for-Taproot.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Hash function requirements for Taproot - 2023-08-02T01:54:55.985605+00:00 - - Lloyd Fournier 2020-03-16 07:31:44+00:00 - - - Tim Ruffing 2020-03-12 17:04:47+00:00 - - - Lloyd Fournier 2020-03-05 09:56:54+00:00 - - - ZmnSCPxj 2020-03-04 23:29:09+00:00 - - - Lloyd Fournier 2020-03-04 07:10:04+00:00 - + 2025-09-26T15:34:56.479369+00:00 + python-feedgen + + + [bitcoin-dev] Hash function requirements for Taproot Lloyd Fournier + 2020-03-04T07:10:00.000Z + + + ZmnSCPxj + 2020-03-04T23:29:00.000Z + + + Lloyd Fournier + 2020-03-05T09:56:00.000Z + + + Tim Ruffing + 2020-03-12T17:04:00.000Z + + + Lloyd Fournier + 2020-03-16T07:31:00.000Z + + - python-feedgen + 2 Combined summary - Hash function requirements for Taproot - 2023-08-02T01:54:55.985605+00:00 + 2025-09-26T15:34:56.480203+00:00 - The email conversation and discussions revolve around the security of Taproot and how it can be formally modeled. The author suggests that a commitment scheme is a more natural model for Taproot's security, but an optimal model should capture both worlds. The properties of this model include that obtaining signatures for the inner key does not help to forge the outer key, obtaining signatures for the outer key does not help to open the commitment, and obtaining an opening does not help to forge either key.The author hopes to prove that any secure key generation method will be secure once Taproot is applied if it is a secure commitment scheme. They believe that we can dismiss the need for any signing or commitment opening oracles in any security notion of Taproot and restrict our notion of Taproot's security to its interaction with the key generation protocol only. This leads to a modular and composable security model for Taproot.In a conversation between Lloyd Fournier and Tim Ruffing, Lloyd provides comments on the security of Taproot. Property (2) is difficult to argue as it depends on the multi-party key generation protocol. Taproot is completely broken when combined with a proof of knowledge key generation protocol where each party provides a proof of knowledge of the secret key. Poelstra presented a proof in the ROM for the security of Taproot. It frames Taproot as a way of combining two signature schemes into one public key - Schnorr and Tapscript. Modeling it as a commitment scheme is more natural, but an optimal model would capture both worlds.The discussion further revolves around the use of an interactive key generation protocol similar to coin tossing, which generates a uniformly random key. This is compared to MuSig, which is not guaranteed to be uniformly random against a malicious party. The coordination and interaction required to arrange getting into an n-of-n is also discussed, as well as reducing latency by reducing communication rounds. Different counters and plans are proposed to address these issues.In another email conversation, LL is thanked by ZmnSCPxj for a work that seems quite interesting. ZmnSCPxj asks for clarification about "coin-tossing" as it was mentioned in the previous message. LL explains that coin-tossing is an interactive key generation protocol where everyone generates fresh keypairs and sends the hash of their pubkey to everyone else. After receiving hashes from everyone else, everybody sends their pubkeys to generate the aggregate key. The benefits and drawbacks of reducing communication rounds for creating signatures during offchain operation are also discussed.The Financial Cryptography conference 2020 featured a poster presentation by LLFourn that aimed to demonstrate the security requirements for the tweak hash function in Taproot. The author explained that Taproot requires no new assumptions of SHA256 over what are already made by Schnorr signatures themselves, except when using a non-interactive key generation protocol to produce a Taproot internal key. The poster used the Generic Group Model to figure out how the hash function would have to fail for Taproot to be insecure. There are three scenarios/games to consider when asking whether Taproot is secure in the context of Bitcoin: Taproot Forge, Covert Taproot, and Second Covert Taproot.Properties (1) and (2) can be argued succinctly if we prove that Taproot is a secure commitment scheme. Property (2) is more difficult to argue as it depends on the multi-party key generation protocol. The MuSig key generation protocol is considered in this case. Proving that Taproot is a binding commitment scheme in the Random Oracle Model is straightforward and proves properties (1) and (3). For property (2), the reduction does not work for n-party MuSig.The cost of Taproot is mostly borne by theoreticians as they have to consider the implications of it being both a public key and a commitment. However, for the user and Bitcoin as a whole, it offers an overwhelming benefit. It adds complexity to making security claims in the GGM but also offers exciting new opportunities for non-interactivity and fungibility over what just Schnorr would provide. The work presented is not considered a final proof, and anyone who wants to take over this research direction and do a proper job of it is welcome to do so. 2020-03-16T07:31:44+00:00 + The email conversation and discussions revolve around the security of Taproot and how it can be formally modeled. The author suggests that a commitment scheme is a more natural model for Taproot's security, but an optimal model should capture both worlds. The properties of this model include that obtaining signatures for the inner key does not help to forge the outer key, obtaining signatures for the outer key does not help to open the commitment, and obtaining an opening does not help to forge either key.The author hopes to prove that any secure key generation method will be secure once Taproot is applied if it is a secure commitment scheme. They believe that we can dismiss the need for any signing or commitment opening oracles in any security notion of Taproot and restrict our notion of Taproot's security to its interaction with the key generation protocol only. This leads to a modular and composable security model for Taproot.In a conversation between Lloyd Fournier and Tim Ruffing, Lloyd provides comments on the security of Taproot. Property (2) is difficult to argue as it depends on the multi-party key generation protocol. Taproot is completely broken when combined with a proof of knowledge key generation protocol where each party provides a proof of knowledge of the secret key. Poelstra presented a proof in the ROM for the security of Taproot. It frames Taproot as a way of combining two signature schemes into one public key - Schnorr and Tapscript. Modeling it as a commitment scheme is more natural, but an optimal model would capture both worlds.The discussion further revolves around the use of an interactive key generation protocol similar to coin tossing, which generates a uniformly random key. This is compared to MuSig, which is not guaranteed to be uniformly random against a malicious party. The coordination and interaction required to arrange getting into an n-of-n is also discussed, as well as reducing latency by reducing communication rounds. Different counters and plans are proposed to address these issues.In another email conversation, LL is thanked by ZmnSCPxj for a work that seems quite interesting. ZmnSCPxj asks for clarification about "coin-tossing" as it was mentioned in the previous message. LL explains that coin-tossing is an interactive key generation protocol where everyone generates fresh keypairs and sends the hash of their pubkey to everyone else. After receiving hashes from everyone else, everybody sends their pubkeys to generate the aggregate key. The benefits and drawbacks of reducing communication rounds for creating signatures during offchain operation are also discussed.The Financial Cryptography conference 2020 featured a poster presentation by LLFourn that aimed to demonstrate the security requirements for the tweak hash function in Taproot. The author explained that Taproot requires no new assumptions of SHA256 over what are already made by Schnorr signatures themselves, except when using a non-interactive key generation protocol to produce a Taproot internal key. The poster used the Generic Group Model to figure out how the hash function would have to fail for Taproot to be insecure. There are three scenarios/games to consider when asking whether Taproot is secure in the context of Bitcoin: Taproot Forge, Covert Taproot, and Second Covert Taproot.Properties (1) and (2) can be argued succinctly if we prove that Taproot is a secure commitment scheme. Property (2) is more difficult to argue as it depends on the multi-party key generation protocol. The MuSig key generation protocol is considered in this case. Proving that Taproot is a binding commitment scheme in the Random Oracle Model is straightforward and proves properties (1) and (3). For property (2), the reduction does not work for n-party MuSig.The cost of Taproot is mostly borne by theoreticians as they have to consider the implications of it being both a public key and a commitment. However, for the user and Bitcoin as a whole, it offers an overwhelming benefit. It adds complexity to making security claims in the GGM but also offers exciting new opportunities for non-interactivity and fungibility over what just Schnorr would provide. The work presented is not considered a final proof, and anyone who wants to take over this research direction and do a proper job of it is welcome to do so. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Mitigating-Differential-Power-Analysis-in-BIP-340.xml b/static/bitcoin-dev/March_2020/combined_Mitigating-Differential-Power-Analysis-in-BIP-340.xml index a2a9a0296e..b64eecd624 100644 --- a/static/bitcoin-dev/March_2020/combined_Mitigating-Differential-Power-Analysis-in-BIP-340.xml +++ b/static/bitcoin-dev/March_2020/combined_Mitigating-Differential-Power-Analysis-in-BIP-340.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Mitigating Differential Power Analysis in BIP-340 - 2023-08-02T01:56:36.603022+00:00 - - Lloyd Fournier 2020-03-25 15:07:48+00:00 - - - Pieter Wuille 2020-03-24 18:56:38+00:00 - - - Lloyd Fournier 2020-03-24 13:00:45+00:00 - + 2025-09-26T15:34:37.528816+00:00 + python-feedgen + + + [bitcoin-dev] Mitigating Differential Power Analysis in BIP-340 Lloyd Fournier + 2020-03-24T13:00:00.000Z + + + Pieter Wuille + 2020-03-24T18:56:00.000Z + + + Lloyd Fournier + 2020-03-25T15:07:00.000Z + + - python-feedgen + 2 Combined summary - Mitigating Differential Power Analysis in BIP-340 - 2023-08-02T01:56:36.603022+00:00 + 2025-09-26T15:34:37.529384+00:00 - On March 24, 2020, Lloyd Fournier posted a message to the bitcoin-dev mailing list regarding proposed changes to BIP-340. These changes included adding random auxiliary data into the nonce derivation function to enhance security against "differential power analysis" (DPA) attacks. However, Pieter Wuille responded to the email, expressing agreement with Lloyd but also providing a summary of the discussion that led to the decision to use a non-standard scheme.Pieter pointed out an issue that Lloyd may have overlooked in a BIP32/Taproot scenario. The private key used in the signing algorithm functions as both a secret and something known to the attacker. This means that interactions between bits inside the hash operation, which all come from the private key, can potentially leak bit-level information. To address this, Pieter suggested XORing the private key with another value before passing it to the hash function. This would prevent the leakage of bit-level information.However, Pieter acknowledged that DPA issues are challenging to reason about, as finding a realistic attack model that only leaks some information without immediately exposing the entire key is difficult. The discussion also touched upon concerns such as efficiency, the risk of midstate leakage in the hash function, and the presence of public keys from an attacker in the signing algorithm.The proposed solution discussed in the thread, H(priv XOR H(aux) || pub || msg), seemed to satisfy most of the requirements. Pieter emphasized that different prioritizations might lead to different conclusions. He welcomed further input and suggestions on the matter.In summary, the post on the mailing list delves into the security of a proposed change to BIP-340 involving the addition of random auxiliary data to prevent DPA attacks. The author questions whether this new approach offers any significant advantages over the current simpler and more efficient method. They argue that the current method is already secure against DPA attacks and provide explanations of how DPA attacks work, along with relevant papers and sources for further reading. The author suggests that if there are justifications for the new approach that they do not understand, these should be documented. 2020-03-25T15:07:48+00:00 + On March 24, 2020, Lloyd Fournier posted a message to the bitcoin-dev mailing list regarding proposed changes to BIP-340. These changes included adding random auxiliary data into the nonce derivation function to enhance security against "differential power analysis" (DPA) attacks. However, Pieter Wuille responded to the email, expressing agreement with Lloyd but also providing a summary of the discussion that led to the decision to use a non-standard scheme.Pieter pointed out an issue that Lloyd may have overlooked in a BIP32/Taproot scenario. The private key used in the signing algorithm functions as both a secret and something known to the attacker. This means that interactions between bits inside the hash operation, which all come from the private key, can potentially leak bit-level information. To address this, Pieter suggested XORing the private key with another value before passing it to the hash function. This would prevent the leakage of bit-level information.However, Pieter acknowledged that DPA issues are challenging to reason about, as finding a realistic attack model that only leaks some information without immediately exposing the entire key is difficult. The discussion also touched upon concerns such as efficiency, the risk of midstate leakage in the hash function, and the presence of public keys from an attacker in the signing algorithm.The proposed solution discussed in the thread, H(priv XOR H(aux) || pub || msg), seemed to satisfy most of the requirements. Pieter emphasized that different prioritizations might lead to different conclusions. He welcomed further input and suggestions on the matter.In summary, the post on the mailing list delves into the security of a proposed change to BIP-340 involving the addition of random auxiliary data to prevent DPA attacks. The author questions whether this new approach offers any significant advantages over the current simpler and more efficient method. They argue that the current method is already secure against DPA attacks and provide explanations of how DPA attacks work, along with relevant papers and sources for further reading. The author suggests that if there are justifications for the new approach that they do not understand, these should be documented. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml b/static/bitcoin-dev/March_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml index 2b52cbdef1..3343467ad5 100644 --- a/static/bitcoin-dev/March_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml +++ b/static/bitcoin-dev/March_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Nonce blinding protocol for hardware wallets and airgapped signers - 2023-08-02T01:53:12.423124+00:00 + 2025-09-26T15:34:35.440265+00:00 + python-feedgen Dustin Dettmer 2020-03-02 20:01:51+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Nonce blinding protocol for hardware wallets and airgapped signers - 2023-08-02T01:53:12.424131+00:00 + 2025-09-26T15:34:35.440428+00:00 - Stepan Snigirev has proposed a protocol for signing messages using an air-gapped computer or hardware wallet in the Bitcoin development mailing list. This comes in response to the acknowledgment that these devices can be compromised through supply chain attacks or malicious firmware updates. The proposed protocol aims to reduce the attack surface by involving additional entropy from the host. The protocol requires the host to pick a random number `n` and send its hash along with the message `m` to the signer. The signer calculates a nonce `k` and sends the corresponding point `R=kG` to the host, committing to the chosen nonce. The preimage `n` is then sent to the signer, who tweaks the nonce by this number and signs the message. The signed message is sent back to the host, who verifies that the public point in the signature is tweaked by `n`.Extensions to the protocol are also suggested by Snigirev. One extension involves the use of multiple hosts, where all hosts don't trust each other and the signer. In this case, hosts can concatenate hashes and preimages to add external entropy to the nonce. Another extension involves the use of a stateless random signer. If the signer wants to generate a nonce non-deterministically but doesn't have the ability to store it, they can send back meta-information to the host that would help regenerate the same nonce later.The proposed protocol can be implemented for PSBT using key-value pairs added to BIP-174. These include keys such as {PSBT_IN_EXT_NONCE_HASH}|{pubkey} for sha256(n1)|sha256(n2)|..., {PSBT_IN_NONCE_COMMITMENT}|{pubkey} for the 33-byte R point, {PSBT_IN_NONCE_SIGNER_METADATA}|{pubkey} for any value, and {PSBT_IN_EXT_NONCE_PREIMAGE}|{pubkey} for n1|n2|....Marko expresses gratitude for the implementation of a protocol for PSBT anti-nonce covert channel and backports the scheme to ECDSA in the secp256k1 library. He suggests using the generalized sign-to-contract scheme in PSBT, where the final nonce is computed as `k' = k + H(k*G, n)` instead of `k'=k+n`. Proprietary fields or key-value pairs can be added to BIP-174 depending on the interest of others. Careful verification against the state stored by the host for the PSBT is necessary to avoid implementation mistakes and private key leakage.The writer appreciates the initiative of implementing and releasing a protocol inspired by a blog post. The protocol was implemented in the secp256k1 library for Schnorr sigs and backported to ECDSA for current transactions. Proof of concepts were made to verify its effectiveness. The generalized sign-to-contract scheme was used in these implementations, with the final nonce computed as `k' = k + H(k*G, n)`. However, caution is advised when implementing the protocol with an air-gapped signer, as wrong implementation could lead to private key leaks. Guidelines and best practices to avoid pitfalls are requested.When generating a digital signature, it is unsafe to use only the message and private key. Instead, all data from the host should be used to create a nonce. Multiple blinding factors can also be used. If completely random nonces cannot be gathered due to insufficient entropy, any available source of entropy can be mixed into the nonce generation function. Glitch attacks, where two identical messages produce different signatures due to a flipped bit in the message, can be prevented by including a monotonic counter in the nonce generation function. The Yubikey had a problem with RNG initialization that caused private key leakage, so it's recommended to avoid pure RNG-generated nonces.The compromise of hardware wallets and air-gapped computers is discussed, highlighting the risks of supply chain attacks and malicious firmware updates. The proposed protocol aims to address these concerns by involving additional entropy from the host in the signing process. It is noted that using a deterministic scheme with only the message and privkey would be unsafe in certain scenarios. To prevent targeted attacks, it's recommended to derive the nonce from the message, `sha256(n)`, and the privkey mixed together using a suitable hashing function. While completely random nonces are ideal, resource limitations may prevent their use.Stepan Snigirev proposes a protocol to prevent the compromise of hardware wallets or air-gapped computers used for signing transactions. The protocol involves the host picking a random number and sending its hash along with the message to the signer, who computes a nonce and commits to it by sending the corresponding point to the host. The preimage is then sent back to the signer, who tweaks the nonce and signs the message. The host verifies that the public point in the signature is tweaked by the same amount. If the signer wants to generate a nonce non-determin 2020-03-02T20:01:51+00:00 + Stepan Snigirev has proposed a protocol for signing messages using an air-gapped computer or hardware wallet in the Bitcoin development mailing list. This comes in response to the acknowledgment that these devices can be compromised through supply chain attacks or malicious firmware updates. The proposed protocol aims to reduce the attack surface by involving additional entropy from the host. The protocol requires the host to pick a random number `n` and send its hash along with the message `m` to the signer. The signer calculates a nonce `k` and sends the corresponding point `R=kG` to the host, committing to the chosen nonce. The preimage `n` is then sent to the signer, who tweaks the nonce by this number and signs the message. The signed message is sent back to the host, who verifies that the public point in the signature is tweaked by `n`.Extensions to the protocol are also suggested by Snigirev. One extension involves the use of multiple hosts, where all hosts don't trust each other and the signer. In this case, hosts can concatenate hashes and preimages to add external entropy to the nonce. Another extension involves the use of a stateless random signer. If the signer wants to generate a nonce non-deterministically but doesn't have the ability to store it, they can send back meta-information to the host that would help regenerate the same nonce later.The proposed protocol can be implemented for PSBT using key-value pairs added to BIP-174. These include keys such as {PSBT_IN_EXT_NONCE_HASH}|{pubkey} for sha256(n1)|sha256(n2)|..., {PSBT_IN_NONCE_COMMITMENT}|{pubkey} for the 33-byte R point, {PSBT_IN_NONCE_SIGNER_METADATA}|{pubkey} for any value, and {PSBT_IN_EXT_NONCE_PREIMAGE}|{pubkey} for n1|n2|....Marko expresses gratitude for the implementation of a protocol for PSBT anti-nonce covert channel and backports the scheme to ECDSA in the secp256k1 library. He suggests using the generalized sign-to-contract scheme in PSBT, where the final nonce is computed as `k' = k + H(k*G, n)` instead of `k'=k+n`. Proprietary fields or key-value pairs can be added to BIP-174 depending on the interest of others. Careful verification against the state stored by the host for the PSBT is necessary to avoid implementation mistakes and private key leakage.The writer appreciates the initiative of implementing and releasing a protocol inspired by a blog post. The protocol was implemented in the secp256k1 library for Schnorr sigs and backported to ECDSA for current transactions. Proof of concepts were made to verify its effectiveness. The generalized sign-to-contract scheme was used in these implementations, with the final nonce computed as `k' = k + H(k*G, n)`. However, caution is advised when implementing the protocol with an air-gapped signer, as wrong implementation could lead to private key leaks. Guidelines and best practices to avoid pitfalls are requested.When generating a digital signature, it is unsafe to use only the message and private key. Instead, all data from the host should be used to create a nonce. Multiple blinding factors can also be used. If completely random nonces cannot be gathered due to insufficient entropy, any available source of entropy can be mixed into the nonce generation function. Glitch attacks, where two identical messages produce different signatures due to a flipped bit in the message, can be prevented by including a monotonic counter in the nonce generation function. The Yubikey had a problem with RNG initialization that caused private key leakage, so it's recommended to avoid pure RNG-generated nonces.The compromise of hardware wallets and air-gapped computers is discussed, highlighting the risks of supply chain attacks and malicious firmware updates. The proposed protocol aims to address these concerns by involving additional entropy from the host in the signing process. It is noted that using a deterministic scheme with only the message and privkey would be unsafe in certain scenarios. To prevent targeted attacks, it's recommended to derive the nonce from the message, `sha256(n)`, and the privkey mixed together using a suitable hashing function. While completely random nonces are ideal, resource limitations may prevent their use.Stepan Snigirev proposes a protocol to prevent the compromise of hardware wallets or air-gapped computers used for signing transactions. The protocol involves the host picking a random number and sending its hash along with the message to the signer, who computes a nonce and commits to it by sending the corresponding point to the host. The preimage is then sent back to the signer, who tweaks the nonce and signs the message. The host verifies that the public point in the signature is tweaked by the same amount. If the signer wants to generate a nonce non-determin - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Overview-of-anti-covert-channel-signing-techniques.xml b/static/bitcoin-dev/March_2020/combined_Overview-of-anti-covert-channel-signing-techniques.xml index 3d9d70b2b6..8b04dda5f3 100644 --- a/static/bitcoin-dev/March_2020/combined_Overview-of-anti-covert-channel-signing-techniques.xml +++ b/static/bitcoin-dev/March_2020/combined_Overview-of-anti-covert-channel-signing-techniques.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Overview of anti-covert-channel signing techniques - 2023-08-02T01:54:01.422249+00:00 - - Dustin Dettmer 2020-03-24 14:51:32+00:00 - - - Tim Ruffing 2020-03-24 07:49:38+00:00 - - - Dustin Dettmer 2020-03-23 14:38:45+00:00 - - - Tim Ruffing 2020-03-22 15:38:21+00:00 - - - Russell O'Connor 2020-03-22 15:30:34+00:00 - - - Tim Ruffing 2020-03-22 09:43:12+00:00 - - - Marko Bencun 2020-03-21 20:29:26+00:00 - - - Russell O'Connor 2020-03-21 16:59:47+00:00 - - - Tim Ruffing 2020-03-21 13:34:14+00:00 - - - Pieter Wuille 2020-03-03 21:35:55+00:00 - + 2025-09-26T15:34:52.268553+00:00 + python-feedgen + + + [bitcoin-dev] Overview of anti-covert-channel signing techniques Pieter Wuille + 2020-03-03T21:35:00.000Z + + + Tim Ruffing + 2020-03-21T13:34:00.000Z + + + Russell O'Connor + 2020-03-21T16:59:00.000Z + + + Marko Bencun + 2020-03-21T20:29:00.000Z + + + Tim Ruffing + 2020-03-22T09:43:00.000Z + + + Russell O'Connor + 2020-03-22T15:30:00.000Z + + + Tim Ruffing + 2020-03-22T15:38:00.000Z + + + Dustin Dettmer + 2020-03-23T14:38:00.000Z + + + Tim Ruffing + 2020-03-24T07:49:00.000Z + + + Dustin Dettmer + 2020-03-24T14:51:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Overview of anti-covert-channel signing techniques - 2023-08-02T01:54:01.422249+00:00 + 2025-09-26T15:34:52.269826+00:00 - Dustin explains to Tim a technique for protecting against the theft of funds by malicious hardware or software. The technique involves splitting the software into two parts: a generator and a validator. The generator creates addresses and withdrawal transactions offline, while the validator double checks everything the generator does. It is best if the validator is written independently of the generator. This technique works regardless of how bitcoins are stored.Pieter Wuille suggests that splitting the software over two stages can greatly increase security if both hardware and software are compromised. He suggests various measures such as exporting xpubs before receiving, generating and exporting withdrawal transactions offline, and verifying transactions using external software. He also provides a link to a tool called Gatekeeper on GitHub that can be used for this purpose.Russell O'Connor and Tim discuss the importance of addressing both pubkey and signature issues. They agree that a non-deterministic signature scheme proposed in the conversation poses more severe issues than the pubkey problem. They believe that a standardized scheme with the benefits of non-determinism without covert channels is necessary.Tim Ruffing raises concerns about the security of hardware wallets in an email thread. He mentions that key generation is also a concern as the PRG used to derive the seed can be manipulated by manufacturers. Other participants in the discussion argue that public keys can be spot checked for non-standard proposals, but synthetic nonces proposed in the conversation cannot be spot checked. They emphasize the need for anti-covert signing protocols.The conversation includes discussions on secure key generation, signing protocols, and protecting against malicious software. The commit-and-reveal protocol is suggested for generating a master public key pair with contributions from both hardware and software. However, it has drawbacks and is not compatible with hardened derivation. Various schemes are proposed to improve the security of hardware wallets against potential attacks.A discussion on the bitcoin-dev mailing list focuses on the security concerns of hardware wallets. The PRG used for key generation can be manipulated by hardware manufacturers, posing a threat to both signing and key generation. The importance of anti-covert channel signing protocols is emphasized.The article discusses different anti-covert channel signing schemes and their trade-offs. The focus is on the MSW and MHW attack models, assuming a Schnorr-like signature protocol. Various schemes are proposed to prevent predictable nonce values, avoid covert channels, and address issues related to Schnorr signatures. The best solution depends on priorities such as statelessness, protection against failure bias, and resistance against side-channel attacks.While hardware wallets can be hacked, the article notes that it may not be a significant concern. The importance of further research and standardization in this area is emphasized. 2020-03-24T14:51:32+00:00 + Dustin explains to Tim a technique for protecting against the theft of funds by malicious hardware or software. The technique involves splitting the software into two parts: a generator and a validator. The generator creates addresses and withdrawal transactions offline, while the validator double checks everything the generator does. It is best if the validator is written independently of the generator. This technique works regardless of how bitcoins are stored.Pieter Wuille suggests that splitting the software over two stages can greatly increase security if both hardware and software are compromised. He suggests various measures such as exporting xpubs before receiving, generating and exporting withdrawal transactions offline, and verifying transactions using external software. He also provides a link to a tool called Gatekeeper on GitHub that can be used for this purpose.Russell O'Connor and Tim discuss the importance of addressing both pubkey and signature issues. They agree that a non-deterministic signature scheme proposed in the conversation poses more severe issues than the pubkey problem. They believe that a standardized scheme with the benefits of non-determinism without covert channels is necessary.Tim Ruffing raises concerns about the security of hardware wallets in an email thread. He mentions that key generation is also a concern as the PRG used to derive the seed can be manipulated by manufacturers. Other participants in the discussion argue that public keys can be spot checked for non-standard proposals, but synthetic nonces proposed in the conversation cannot be spot checked. They emphasize the need for anti-covert signing protocols.The conversation includes discussions on secure key generation, signing protocols, and protecting against malicious software. The commit-and-reveal protocol is suggested for generating a master public key pair with contributions from both hardware and software. However, it has drawbacks and is not compatible with hardened derivation. Various schemes are proposed to improve the security of hardware wallets against potential attacks.A discussion on the bitcoin-dev mailing list focuses on the security concerns of hardware wallets. The PRG used for key generation can be manipulated by hardware manufacturers, posing a threat to both signing and key generation. The importance of anti-covert channel signing protocols is emphasized.The article discusses different anti-covert channel signing schemes and their trade-offs. The focus is on the MSW and MHW attack models, assuming a Schnorr-like signature protocol. Various schemes are proposed to prevent predictable nonce values, avoid covert channels, and address issues related to Schnorr signatures. The best solution depends on priorities such as statelessness, protection against failure bias, and resistance against side-channel attacks.While hardware wallets can be hacked, the article notes that it may not be a significant concern. The importance of further research and standardization in this area is emphasized. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_RFC-Deterministic-Entropy-From-BIP32-Keychains.xml b/static/bitcoin-dev/March_2020/combined_RFC-Deterministic-Entropy-From-BIP32-Keychains.xml index d38cf31e1d..d59bf5bc4b 100644 --- a/static/bitcoin-dev/March_2020/combined_RFC-Deterministic-Entropy-From-BIP32-Keychains.xml +++ b/static/bitcoin-dev/March_2020/combined_RFC-Deterministic-Entropy-From-BIP32-Keychains.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - RFC: Deterministic Entropy From BIP32 Keychains - 2023-08-02T01:55:55.140748+00:00 - - Adam Back 2020-03-25 13:54:18+00:00 - - - Tim Ruffing 2020-03-24 08:07:04+00:00 - - - Ethan Kosakovsky 2020-03-22 11:58:53+00:00 - - - Ethan Kosakovsky 2020-03-21 15:10:48+00:00 - - - Christopher Allen 2020-03-21 01:46:19+00:00 - - - Peter D. Gray 2020-03-20 20:02:53+00:00 - - - Ethan Kosakovsky 2020-03-20 17:35:13+00:00 - - - Ethan Kosakovsky 2020-03-20 17:34:05+00:00 - - - Pavol Rusnak 2020-03-20 16:29:49+00:00 - - - Ethan Kosakovsky 2020-03-20 15:44:01+00:00 - + 2025-09-26T15:34:54.386618+00:00 + python-feedgen + + + [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains Ethan Kosakovsky + 2020-03-20T15:44:00.000Z + + + Pavol Rusnak + 2020-03-20T16:29:00.000Z + + + Ethan Kosakovsky + 2020-03-20T17:34:00.000Z + + + Ethan Kosakovsky + 2020-03-20T17:35:00.000Z + + + Peter D. Gray + 2020-03-20T20:02:00.000Z + + + Christopher Allen + 2020-03-21T01:46:00.000Z + + + Ethan Kosakovsky + 2020-03-21T15:10:00.000Z + + + Ethan Kosakovsky + 2020-03-22T11:58:00.000Z + + + Tim Ruffing + 2020-03-24T08:07:00.000Z + + + Adam Back + 2020-03-25T13:54:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - RFC: Deterministic Entropy From BIP32 Keychains - 2023-08-02T01:55:55.140748+00:00 + 2025-09-26T15:34:54.387862+00:00 - The proposed extension/standard aims to solve the problem of managing multiple seeds and backups by providing a way to deterministically derive initial entropy for creating keychain mnemonics and seeds. The proposal suggests using a single BIP32 style "master root key" and specifies a derivation scheme using the format `m/83696968'/type'/index'`. To ensure compatibility, the proposal suggests using HMAC-SHA512 for calculating entropy, as it is already required in devices supporting BIP32. The resulting entropy can then be used to derive a mnemonic, wallet, or other relevant entities based on the specified `type`.The proposal also emphasizes that wallet developers do not need to make any changes, as the interaction point remains the BIP39 seed, which most developers are familiar with. The document includes three test cases demonstrating the derivation of child keys from parent keys using both BIP32 and BIP39. These test cases provide details such as bits required for the child key, WIF, k, entropy, and BIP39 seed and mnemonic for the derived child key.The references cited in the proposal are BIP32 and BIP39, which are standards for hierarchical deterministic wallets. The document is dual-licensed under the Open Publication License and BSD 2-clause license. The proposal presented by Ethan Kosakovsky has sparked discussions and opinions within the bitcoin-dev community. Christopher Allen agrees with the problem statement but suggests finding standard ways to protect the entropy seed for creating hierarchies of keys using airgap solutions. Peter D. Gray, the founder of Coinkite, expresses approval and recognition of the proposal, considering it a valuable contribution to solving the issue of managing multiple seeds and backups. However, there are also members of the community, such as Pavol Rusnak, who express confusion about the problem being addressed in the proposal.The main objective of the proposal is to allow one root key or mnemonic to derive various root keychains in different formats, depending on the user's preference or hardware signing devices. This proposed standard is currently in the proposed stage and has not yet received any comments. If implemented, this standard would enable devices that store the HD seed as a BIP39 mnemonic, Electrum seed, or BIP32 root key to adopt it. The proposal includes three test cases with different master BIP39 seed inputs, master BIP32 root keys, and paths. Each test case also provides information such as the required bits, derived child WIF, derived child k value, child entropy, converted entropy to WIF, child BIP39 mnemonic, child BIP39 seed, and child BIP32 root key.HMAC-SHA512 has been chosen as the function to process the resulting private key due to its compatibility with embedded devices, as it is already required in devices supporting BIP32. The ultimate goal of this proposal is to address the issue of having too many seeds and backups, while still preserving the original motivation behind BIP32. 2020-03-25T13:54:18+00:00 + The proposed extension/standard aims to solve the problem of managing multiple seeds and backups by providing a way to deterministically derive initial entropy for creating keychain mnemonics and seeds. The proposal suggests using a single BIP32 style "master root key" and specifies a derivation scheme using the format `m/83696968'/type'/index'`. To ensure compatibility, the proposal suggests using HMAC-SHA512 for calculating entropy, as it is already required in devices supporting BIP32. The resulting entropy can then be used to derive a mnemonic, wallet, or other relevant entities based on the specified `type`.The proposal also emphasizes that wallet developers do not need to make any changes, as the interaction point remains the BIP39 seed, which most developers are familiar with. The document includes three test cases demonstrating the derivation of child keys from parent keys using both BIP32 and BIP39. These test cases provide details such as bits required for the child key, WIF, k, entropy, and BIP39 seed and mnemonic for the derived child key.The references cited in the proposal are BIP32 and BIP39, which are standards for hierarchical deterministic wallets. The document is dual-licensed under the Open Publication License and BSD 2-clause license. The proposal presented by Ethan Kosakovsky has sparked discussions and opinions within the bitcoin-dev community. Christopher Allen agrees with the problem statement but suggests finding standard ways to protect the entropy seed for creating hierarchies of keys using airgap solutions. Peter D. Gray, the founder of Coinkite, expresses approval and recognition of the proposal, considering it a valuable contribution to solving the issue of managing multiple seeds and backups. However, there are also members of the community, such as Pavol Rusnak, who express confusion about the problem being addressed in the proposal.The main objective of the proposal is to allow one root key or mnemonic to derive various root keychains in different formats, depending on the user's preference or hardware signing devices. This proposed standard is currently in the proposed stage and has not yet received any comments. If implemented, this standard would enable devices that store the HD seed as a BIP39 mnemonic, Electrum seed, or BIP32 root key to adopt it. The proposal includes three test cases with different master BIP39 seed inputs, master BIP32 root keys, and paths. Each test case also provides information such as the required bits, derived child WIF, derived child k value, child entropy, converted entropy to WIF, child BIP39 mnemonic, child BIP39 seed, and child BIP32 root key.HMAC-SHA512 has been chosen as the function to process the resulting private key due to its compatibility with embedded devices, as it is already required in devices supporting BIP32. The ultimate goal of this proposal is to address the issue of having too many seeds and backups, while still preserving the original motivation behind BIP32. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_RFC-Kicking-BIP-322-message-signing-into-motion.xml b/static/bitcoin-dev/March_2020/combined_RFC-Kicking-BIP-322-message-signing-into-motion.xml index 0dcf0d4f5c..084c7288db 100644 --- a/static/bitcoin-dev/March_2020/combined_RFC-Kicking-BIP-322-message-signing-into-motion.xml +++ b/static/bitcoin-dev/March_2020/combined_RFC-Kicking-BIP-322-message-signing-into-motion.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - RFC: Kicking BIP-322 (message signing) into motion - 2023-08-02T01:54:27.832496+00:00 - - Karl-Johan Alm 2020-03-25 06:31:56+00:00 - - - Greg Sanders 2020-03-04 14:43:13+00:00 - - - Luke Dashjr 2020-03-04 14:35:16+00:00 - - - Karl-Johan Alm 2020-03-04 07:03:34+00:00 - - - Karl-Johan Alm 2020-03-04 06:23:53+00:00 - + 2025-09-26T15:34:58.569895+00:00 + python-feedgen + + + [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion Karl-Johan Alm + 2020-03-04T06:23:00.000Z + + + Karl-Johan Alm + 2020-03-04T07:03:00.000Z + + + Luke Dashjr + 2020-03-04T14:35:00.000Z + + + Greg Sanders + 2020-03-04T14:43:00.000Z + + + Karl-Johan Alm + 2020-03-25T06:31:00.000Z + + - python-feedgen + 2 Combined summary - RFC: Kicking BIP-322 (message signing) into motion - 2023-08-02T01:54:27.832496+00:00 + 2025-09-26T15:34:58.570740+00:00 - In this email thread from the Bitcoin-dev mailing list, several proposals for improving the BIP-322 pull request are discussed. The first proposal involves replacing the signmessage system with a prove funds system to discourage the misleading use of signmessage as a way to prove funds. The second proposal suggests using a transaction instead of a new format and making the first input's txid the message hash to ensure that the transaction cannot be broadcasted. The third proposal involves using Trezor style, which has already been adopted but limits generic signing. The fourth proposal is to introduce OP_MESSAGEONLY, which would make "dumb" signers more difficult to support as they would have to do script interpretation to make sure they're not signing something real with funds. Finally, the email asks if anyone has any other suggestions for improving BIP-322.Karl-Johan Alm has reached out to the bitcoin-dev mailing list regarding his BIP-322 pull request, which aims to improve Bitcoin's signing message functionality. He notes that a similar pull request was merged into Bitcoin Core without considering BIP-322 compatibility, leading Karl-Johan to believe that people dislike BIP-322 in its current form. To make the pull request more appealing, Karl-Johan suggests several potential changes. Firstly, he recommends throwing out the sign message system entirely and replacing it with a proof-of-funds system. Secondly, he suggests using a transaction rather than a new format, with the first input's txid serving as the message hash to ensure the transaction cannot be broadcasted. Thirdly, Karl-Johan proposes adopting the Trezor style, which is already in use but limits generic signing. Fourthly, he recommends introducing OP_MESSAGEONLY to enable messaging purposes without consuming an op_code. Lastly, he invites suggestions for any other solutions. Karl-Johan encourages harsh criticism of these proposals if necessary so that he can improve or abandon the BIP-322 pull request accordingly.The author of a BIP-322 pull request has noticed that despite their PR being open for twice the time as another PR to Bitcoin Core, which touched on the same areas of complexity, the latter was merged without any consideration for BIP-322 compatibility. This leads them to believe that people dislike BIP-322 in its current form. They are seeking criticism to improve their PR and have listed several things that they can do to make it more appealing. Firstly, they suggest that the use of signmessage as a way to prove funds should be discouraged entirely and replaced with a prove funds system, which is an opinion shared by Luke-jr and Greg Maxwell. Secondly, they propose using a transaction rather than a new format by making the first input’s txid the message hash, which would ensure the tx cannot be broadcasted and could provide to an existing hardware wallet without modifications. Mark Friedenbach and Johnson Lau support this idea but Lau also suggests modifying the signature hash, which defeats the benefit above since now hardware wallets cannot sign. Prusnak is against this idea and proposes using the Trezor style instead. The Trezor style has already been adopted, but the drawback is that we would be stuck with the exact same limitations as in the legacy system, which we wanted to fix in the updated version. Lastly, the author suggests introducing OP_MESSAGEONLY, which means the script following the code would never be valid. For messaging purposes, OP_MESSAGEONLY is considered as OP_NOP and ignored. A message could be signed with either key_m or key_s, but for spending purposes, only key_s is valid. 2020-03-25T06:31:56+00:00 + In this email thread from the Bitcoin-dev mailing list, several proposals for improving the BIP-322 pull request are discussed. The first proposal involves replacing the signmessage system with a prove funds system to discourage the misleading use of signmessage as a way to prove funds. The second proposal suggests using a transaction instead of a new format and making the first input's txid the message hash to ensure that the transaction cannot be broadcasted. The third proposal involves using Trezor style, which has already been adopted but limits generic signing. The fourth proposal is to introduce OP_MESSAGEONLY, which would make "dumb" signers more difficult to support as they would have to do script interpretation to make sure they're not signing something real with funds. Finally, the email asks if anyone has any other suggestions for improving BIP-322.Karl-Johan Alm has reached out to the bitcoin-dev mailing list regarding his BIP-322 pull request, which aims to improve Bitcoin's signing message functionality. He notes that a similar pull request was merged into Bitcoin Core without considering BIP-322 compatibility, leading Karl-Johan to believe that people dislike BIP-322 in its current form. To make the pull request more appealing, Karl-Johan suggests several potential changes. Firstly, he recommends throwing out the sign message system entirely and replacing it with a proof-of-funds system. Secondly, he suggests using a transaction rather than a new format, with the first input's txid serving as the message hash to ensure the transaction cannot be broadcasted. Thirdly, Karl-Johan proposes adopting the Trezor style, which is already in use but limits generic signing. Fourthly, he recommends introducing OP_MESSAGEONLY to enable messaging purposes without consuming an op_code. Lastly, he invites suggestions for any other solutions. Karl-Johan encourages harsh criticism of these proposals if necessary so that he can improve or abandon the BIP-322 pull request accordingly.The author of a BIP-322 pull request has noticed that despite their PR being open for twice the time as another PR to Bitcoin Core, which touched on the same areas of complexity, the latter was merged without any consideration for BIP-322 compatibility. This leads them to believe that people dislike BIP-322 in its current form. They are seeking criticism to improve their PR and have listed several things that they can do to make it more appealing. Firstly, they suggest that the use of signmessage as a way to prove funds should be discouraged entirely and replaced with a prove funds system, which is an opinion shared by Luke-jr and Greg Maxwell. Secondly, they propose using a transaction rather than a new format by making the first input’s txid the message hash, which would ensure the tx cannot be broadcasted and could provide to an existing hardware wallet without modifications. Mark Friedenbach and Johnson Lau support this idea but Lau also suggests modifying the signature hash, which defeats the benefit above since now hardware wallets cannot sign. Prusnak is against this idea and proposes using the Trezor style instead. The Trezor style has already been adopted, but the drawback is that we would be stuck with the exact same limitations as in the legacy system, which we wanted to fix in the updated version. Lastly, the author suggests introducing OP_MESSAGEONLY, which means the script following the code would never be valid. For messaging purposes, OP_MESSAGEONLY is considered as OP_NOP and ignored. A message could be signed with either key_m or key_s, but for spending purposes, only key_s is valid. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Removing-Single-Point-of-Failure-with-Seed-Phrase-Storage.xml b/static/bitcoin-dev/March_2020/combined_Removing-Single-Point-of-Failure-with-Seed-Phrase-Storage.xml index 9b087ed89e..9dafa543fb 100644 --- a/static/bitcoin-dev/March_2020/combined_Removing-Single-Point-of-Failure-with-Seed-Phrase-Storage.xml +++ b/static/bitcoin-dev/March_2020/combined_Removing-Single-Point-of-Failure-with-Seed-Phrase-Storage.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Removing Single Point of Failure with Seed Phrase Storage - 2023-08-02T01:52:24.038046+00:00 - - Russell O'Connor 2020-03-06 11:11:11+00:00 - - - ZmnSCPxj 2020-02-28 13:10:27+00:00 - - - Christopher Allen 2020-02-26 20:26:44+00:00 - - - Jeremy 2020-02-26 19:56:09+00:00 - - - Contact Team 2020-02-26 13:02:20+00:00 - + 2025-09-26T15:34:43.830676+00:00 + python-feedgen + + + [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage Contact Team + 2020-02-26T13:02:00.000Z + + + Jeremy + 2020-02-26T19:56:00.000Z + + + Christopher Allen + 2020-02-26T20:26:00.000Z + + + ZmnSCPxj + 2020-02-28T13:10:00.000Z + + + Russell O'Connor + 2020-03-06T11:11:00.000Z + + + [bitcoin-dev] On the compatibility of Bech32 and Shamir's Secret Sharing Russell O'Connor + 2020-08-03T22:49:00.000Z + + - python-feedgen + 2 Combined summary - Removing Single Point of Failure with Seed Phrase Storage - 2023-08-02T01:52:24.038046+00:00 + 2025-09-26T15:34:43.831627+00:00 - The email thread discusses the benefits and issues with using Shamir's Secret Sharing as a replacement for paper. A concept has been proposed for creating secret shares using paper computers, which splits a secret encoded in the Bech32 alphabet into 2-of-n shares. However, there are still more issues that need to be addressed before using it for valuable data. The proposed method is experimental and has only been tested with a 10-character "secret" data. It generates shares easily but recovering the secret data is more work. The error correcting code should contain an error correcting code for robust recovery. While this scheme may be workable for some, it requires manual computation, which may lead to errors.The limitations of Shamir split backups are discussed, mentioning that the key can exist plaintext on a device at some point. Non-interactive multisig is suggested as a better solution as it allows signing transactions without having keys in the same room/place/device ever. However, Shamir split backups still have a place in operational security scenarios. The best C-library for Shamir sharding of recovery seeds is available at the Blockchain Commons Github but needs refactoring to be a good standalone library. Air-gapped open-source open hardware for seed creations and Shamir restoration is also being worked on. Verifiable Secret Sharing (VSS) is considered better than Shamir Secret Sharing for seed sharding in the long-term. Bitcoin multisig transactions are recommended as the best solution for self-sovereign recovery of funds. The SmartCustody book offers current best practices for single seed recovery and is now working on v2 of the book, which will cover multisign and fiduciary scenarios.Seed phrase security is a topic of ongoing discussion, with different opinions and security models used by individuals. Paper or metal engraving options are commonly used but act as a single point of failure. Hardware wallets, even those using a secure element, can still be vulnerable to hacking. The Cypherock X1 Wallet offers a potential solution by using Shamir Secret Sharing to split the seed phrase into four different shares, each stored in a PIN-protected card with a secure element. Any two of these four cards are needed to recover the seed or make a transaction, reducing the risk of losing the seed phrase. The storage and computation aspects of this hardware wallet are decoupled, providing added security through distribution. However, Shamir's shares have the issue that the key does exist plaintext on a device at some point. Non-interactive multisig provides an alternative benefit by allowing transactions to be signed without having keys in the same room/place/device ever. Feedback from the community is welcomed regarding the Cypherock X1 Wallet. 2020-03-06T11:11:11+00:00 + The email thread discusses the benefits and issues with using Shamir's Secret Sharing as a replacement for paper. A concept has been proposed for creating secret shares using paper computers, which splits a secret encoded in the Bech32 alphabet into 2-of-n shares. However, there are still more issues that need to be addressed before using it for valuable data. The proposed method is experimental and has only been tested with a 10-character "secret" data. It generates shares easily but recovering the secret data is more work. The error correcting code should contain an error correcting code for robust recovery. While this scheme may be workable for some, it requires manual computation, which may lead to errors.The limitations of Shamir split backups are discussed, mentioning that the key can exist plaintext on a device at some point. Non-interactive multisig is suggested as a better solution as it allows signing transactions without having keys in the same room/place/device ever. However, Shamir split backups still have a place in operational security scenarios. The best C-library for Shamir sharding of recovery seeds is available at the Blockchain Commons Github but needs refactoring to be a good standalone library. Air-gapped open-source open hardware for seed creations and Shamir restoration is also being worked on. Verifiable Secret Sharing (VSS) is considered better than Shamir Secret Sharing for seed sharding in the long-term. Bitcoin multisig transactions are recommended as the best solution for self-sovereign recovery of funds. The SmartCustody book offers current best practices for single seed recovery and is now working on v2 of the book, which will cover multisign and fiduciary scenarios.Seed phrase security is a topic of ongoing discussion, with different opinions and security models used by individuals. Paper or metal engraving options are commonly used but act as a single point of failure. Hardware wallets, even those using a secure element, can still be vulnerable to hacking. The Cypherock X1 Wallet offers a potential solution by using Shamir Secret Sharing to split the seed phrase into four different shares, each stored in a PIN-protected card with a secure element. Any two of these four cards are needed to recover the seed or make a transaction, reducing the risk of losing the seed phrase. The storage and computation aspects of this hardware wallet are decoupled, providing added security through distribution. However, Shamir's shares have the issue that the key does exist plaintext on a device at some point. Non-interactive multisig provides an alternative benefit by allowing transactions to be signed without having keys in the same room/place/device ever. Feedback from the community is welcomed regarding the Cypherock X1 Wallet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Schnorr-sigs-vs-pairing-sigs.xml b/static/bitcoin-dev/March_2020/combined_Schnorr-sigs-vs-pairing-sigs.xml index 24b96e093e..197a48c323 100644 --- a/static/bitcoin-dev/March_2020/combined_Schnorr-sigs-vs-pairing-sigs.xml +++ b/static/bitcoin-dev/March_2020/combined_Schnorr-sigs-vs-pairing-sigs.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Schnorr sigs vs pairing sigs - 2023-08-02T01:55:05.387322+00:00 - - Lloyd Fournier 2020-03-06 06:40:24+00:00 - - - Erik Aronesty 2020-03-05 19:01:27+00:00 - + 2025-09-26T15:34:48.032247+00:00 + python-feedgen + + + [bitcoin-dev] Schnorr sigs vs pairing sigs Erik Aronesty + 2020-03-05T19:01:00.000Z + + + Lloyd Fournier + 2020-03-06T06:40:00.000Z + + - python-feedgen + 2 Combined summary - Schnorr sigs vs pairing sigs - 2023-08-02T01:55:05.387322+00:00 + 2025-09-26T15:34:48.032774+00:00 - In a recent discussion on the Bitcoin-dev mailing list, the topic of debate revolves around the use of pairing-based signatures versus non-deterministic signatures like Schnorr over BLS. The main point of contention is whether randomness in signature schemes is preferable as it enables a type of signature encryption known as "adaptor signatures," which holds significance for layer 2 protocols. To support their argument, the original poster shares a paper they wrote on the subject titled "One-Time Verifiably Encrypted Signatures A.K.A Adaptor Signatures."However, Erik Aronesty presents an opposing viewpoint by emphasizing that Schnorr signatures heavily depend on the masking provided by a random nonce. Aronesty points out that there are various straightforward methods to introduce bias in these signatures, such as using hash + modulo. He further cites a study presented at ECC2017, which reveals that even a mere 2 bits of bias can lead to severe attacks. In light of this vulnerability, Aronesty suggests considering pairing-based signatures as they may be slower but offer more flexibility and better security implementations.Overall, the discussion highlights the trade-offs between different signature schemes, with proponents of randomness arguing for the inclusion of adaptor signatures in layer 2 protocols, while others caution against the potential biases that can compromise the security of Schnorr signatures. Ultimately, the decision regarding the choice of signature scheme depends on striking a balance between performance, flexibility, and security. 2020-03-06T06:40:24+00:00 + In a recent discussion on the Bitcoin-dev mailing list, the topic of debate revolves around the use of pairing-based signatures versus non-deterministic signatures like Schnorr over BLS. The main point of contention is whether randomness in signature schemes is preferable as it enables a type of signature encryption known as "adaptor signatures," which holds significance for layer 2 protocols. To support their argument, the original poster shares a paper they wrote on the subject titled "One-Time Verifiably Encrypted Signatures A.K.A Adaptor Signatures."However, Erik Aronesty presents an opposing viewpoint by emphasizing that Schnorr signatures heavily depend on the masking provided by a random nonce. Aronesty points out that there are various straightforward methods to introduce bias in these signatures, such as using hash + modulo. He further cites a study presented at ECC2017, which reveals that even a mere 2 bits of bias can lead to severe attacks. In light of this vulnerability, Aronesty suggests considering pairing-based signatures as they may be slower but offer more flexibility and better security implementations.Overall, the discussion highlights the trade-offs between different signature schemes, with proponents of randomness arguing for the inclusion of adaptor signatures in layer 2 protocols, while others caution against the potential biases that can compromise the security of Schnorr signatures. Ultimately, the decision regarding the choice of signature scheme depends on striking a balance between performance, flexibility, and security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2020/combined_Statechain-implementations.xml b/static/bitcoin-dev/March_2020/combined_Statechain-implementations.xml index 8801004338..70daf38a79 100644 --- a/static/bitcoin-dev/March_2020/combined_Statechain-implementations.xml +++ b/static/bitcoin-dev/March_2020/combined_Statechain-implementations.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - Statechain implementations - 2023-08-02T01:58:10.360456+00:00 - - Tom Trevethan 2020-05-07 14:54:53+00:00 - - - Tom Trevethan 2020-04-05 21:25:51+00:00 - - - ZmnSCPxj 2020-04-05 18:24:39+00:00 - - - Bob McElrath 2020-04-05 14:17:17+00:00 - - - ZmnSCPxj 2020-04-04 12:07:28+00:00 - - - Nadav Kohen 2020-04-03 16:37:15+00:00 - - - Tom Trevethan 2020-04-02 22:56:17+00:00 - - - Tom Trevethan 2020-03-31 11:41:46+00:00 - - - David A. Harding 2020-03-31 10:35:08+00:00 - - - ZmnSCPxj 2020-03-30 01:25:36+00:00 - - - Ruben Somsen 2020-03-28 17:42:58+00:00 - - - Ruben Somsen 2020-03-28 17:38:47+00:00 - - - ZmnSCPxj 2020-03-28 02:42:27+00:00 - - - ZmnSCPxj 2020-03-28 02:20:33+00:00 - - - Bob McElrath 2020-03-27 17:10:18+00:00 - - - Ruben Somsen 2020-03-27 15:12:33+00:00 - - - ZmnSCPxj 2020-03-27 01:46:15+00:00 - - - Ruben Somsen 2020-03-26 18:53:13+00:00 - - - Greg Sanders 2020-03-26 17:17:13+00:00 - - - Christian Decker 2020-03-26 17:12:44+00:00 - - - Bob McElrath 2020-03-26 14:52:36+00:00 - - - Ruben Somsen 2020-03-26 12:36:20+00:00 - - - Albert 2020-03-26 03:55:50+00:00 - - - ZmnSCPxj 2020-03-26 01:20:47+00:00 - - - Tom Trevethan 2020-03-25 13:52:10+00:00 - + 2025-09-26T15:34:39.648933+00:00 + python-feedgen + + + [bitcoin-dev] Statechain implementations Tom Trevethan + 2020-03-25T13:52:00.000Z + + + ZmnSCPxj + 2020-03-26T01:20:00.000Z + + + Albert + 2020-03-26T03:55:00.000Z + + + Ruben Somsen + 2020-03-26T12:36:00.000Z + + + Bob McElrath + 2020-03-26T14:52:00.000Z + + + Christian Decker + 2020-03-26T17:12:00.000Z + + + Greg Sanders + 2020-03-26T17:17:00.000Z + + + Ruben Somsen + 2020-03-26T18:53:00.000Z + + + ZmnSCPxj + 2020-03-27T01:46:00.000Z + + + Ruben Somsen + 2020-03-27T15:12:00.000Z + + + Bob McElrath + 2020-03-27T17:10:00.000Z + + + ZmnSCPxj + 2020-03-28T02:20:00.000Z + + + ZmnSCPxj + 2020-03-28T02:42:00.000Z + + + Ruben Somsen + 2020-03-28T17:38:00.000Z + + + Ruben Somsen + 2020-03-28T17:42:00.000Z + + + ZmnSCPxj + 2020-03-30T01:25:00.000Z + + + David A. Harding + 2020-03-31T10:35:00.000Z + + + Tom Trevethan + 2020-03-31T11:41:00.000Z + + + Tom Trevethan + 2020-04-02T22:56:00.000Z + + + Nadav Kohen + 2020-04-03T16:37:00.000Z + + + ZmnSCPxj + 2020-04-04T12:07:00.000Z + + + Bob McElrath + 2020-04-05T14:17:00.000Z + + + ZmnSCPxj + 2020-04-05T18:24:00.000Z + + + Tom Trevethan + 2020-04-05T21:25:00.000Z + + + Tom Trevethan + 2020-05-07T14:54:00.000Z + + @@ -103,13 +131,13 @@ - python-feedgen + 2 Combined summary - Statechain implementations - 2023-08-02T01:58:10.360456+00:00 + 2025-09-26T15:34:39.651708+00:00 - CommerceBlock is actively working on implementing their statechain using KZen's 2P ECDSA protocol and Rust. They plan to use a sparse Merkle tree attested to a Mainstay slot for the proof-of-publication/proof-of-ownership. The statechain will allow the current owner to prove if there has been theft from them.Nadav has concerns about potential scams by the Statechain Entity (SE) where they buy the UTXO, transfer it, and then steal it. This issue can be solved by adding a new user key to the protocol that would make it traceable/provable. For open-ended UTXOs, an invalidation tree relative locktime backup mechanism will likely be used. Tom Trevethan clarifies that his patent application is different from the ideas currently being worked on. On the bitcoin-dev mailing list, a proposal was made for an exchange platform that operates using off-chain transactions and does not require on-chain transactions. This platform would be capable of generating multiple transactions, which can be recorded on a blockchain under different circumstances. The proposal suggests that some off-chain transactions should still be valid for recording on the blockchain in the event of a catastrophic failure of the exchange, such as the permanent shutdown of the exchange or loss of key shares.A two-party elliptic curve digital signature algorithm script would be used to perform functions of a two-party elliptic curve digital signature algorithm. The proposal also notes that a malicious actor would have to collude with a previous owner of the funds to recreate the full key making it difficult for them to compromise the exchange platform. Dave proposed this idea, and Bob McElrath responded to it by quoting H.L. Mencken's famous statement that "For every complex problem, there is a solution that is simple, neat, and wrong."In an email chain on the Bitcoin development mailing list, several proposals were discussed to increase platform security. One proposal involved using two-party elliptic curve digital signature algorithms to make it difficult for malicious actors to compromise the exchange platform. The processor would be configured to perform these functions, which would limit opportunities for attackers to compromise the platform. Bob McElrath noted that this proposed solution may not be effective in preventing all attacks and ended his email with a quote by H.L. Mencken: "For every complex problem, there is a solution that is simple, neat, and wrong."Another proposal discussed was the statechain protocol. Nadav Kohen raised concerns over the possibility of a malicious Statechain Entity (SE) stealing a user's UTXO by collaborating with or being a previous owner. Tom suggested using proof-of-publication as a way to enable the current owner to prove ownership and prevent double-spending, as well as provide evidence of fraud on the part of the SE. Bob McElrath suggested using single use seals to track ownership history and prevent the SE from buying the UTXO, noting that the attack would require collusion with the current UTXO owner. Nadav proposed adding a new user key to the protocol, which would be required for a transfer to be valid on the statechain.Tom provided a more detailed document specifying the proposed protocol, including improvements to the transfer mechanism and an explanation of how this can be used to transfer/novate positions in DLCs. He also addressed concerns about nChain Holdings' patent application related to secure off-chain blockchain transactions.The discussion is about the security assumptions of statechains. It is mentioned that an attack on statechains requires collaboration with the current UTXO owner, who is transferring the UXTO to a non-statechain entity and knows the target of the transfer, obtaining the target pubkey for the transfer out-of-band with respect to the SE or the SE can MITM that. The security assumption is that the sender or receiver does not collude with the SE. If either does, then the attack is generally possible.The SE cannot be allowed to be both operator of the SE and a customer of it as this clearly violates the no-receiver collusion principle. Adding a new user key doesn't change the situation as the user has already acquiesced to the transfer. Any past owner of the coin can collude with the statechain authority in order to steal the onchain funds regardless of who the current owner is within the statechain. So, trust must still be put in the statechain authority. The security assumptions should be that the statechain authority really does delete keys and does not make backups, and no past or current owner of the coin colludes with the statechain authority.The Statechain concept proposes non-custodial off-chain Bitcoin transfer. The current holder of UTXO must obtain the target pubkey for the transfer out-of-band with respect to the SE, or the SE can MITM that. Nadav Kohen raised concerns about an untraceable scam by the Statechain Entity (SE). It involves buying the UTXO, transferring it to someone else, 2020-05-07T14:54:53+00:00 + CommerceBlock is actively working on implementing their statechain using KZen's 2P ECDSA protocol and Rust. They plan to use a sparse Merkle tree attested to a Mainstay slot for the proof-of-publication/proof-of-ownership. The statechain will allow the current owner to prove if there has been theft from them.Nadav has concerns about potential scams by the Statechain Entity (SE) where they buy the UTXO, transfer it, and then steal it. This issue can be solved by adding a new user key to the protocol that would make it traceable/provable. For open-ended UTXOs, an invalidation tree relative locktime backup mechanism will likely be used. Tom Trevethan clarifies that his patent application is different from the ideas currently being worked on. On the bitcoin-dev mailing list, a proposal was made for an exchange platform that operates using off-chain transactions and does not require on-chain transactions. This platform would be capable of generating multiple transactions, which can be recorded on a blockchain under different circumstances. The proposal suggests that some off-chain transactions should still be valid for recording on the blockchain in the event of a catastrophic failure of the exchange, such as the permanent shutdown of the exchange or loss of key shares.A two-party elliptic curve digital signature algorithm script would be used to perform functions of a two-party elliptic curve digital signature algorithm. The proposal also notes that a malicious actor would have to collude with a previous owner of the funds to recreate the full key making it difficult for them to compromise the exchange platform. Dave proposed this idea, and Bob McElrath responded to it by quoting H.L. Mencken's famous statement that "For every complex problem, there is a solution that is simple, neat, and wrong."In an email chain on the Bitcoin development mailing list, several proposals were discussed to increase platform security. One proposal involved using two-party elliptic curve digital signature algorithms to make it difficult for malicious actors to compromise the exchange platform. The processor would be configured to perform these functions, which would limit opportunities for attackers to compromise the platform. Bob McElrath noted that this proposed solution may not be effective in preventing all attacks and ended his email with a quote by H.L. Mencken: "For every complex problem, there is a solution that is simple, neat, and wrong."Another proposal discussed was the statechain protocol. Nadav Kohen raised concerns over the possibility of a malicious Statechain Entity (SE) stealing a user's UTXO by collaborating with or being a previous owner. Tom suggested using proof-of-publication as a way to enable the current owner to prove ownership and prevent double-spending, as well as provide evidence of fraud on the part of the SE. Bob McElrath suggested using single use seals to track ownership history and prevent the SE from buying the UTXO, noting that the attack would require collusion with the current UTXO owner. Nadav proposed adding a new user key to the protocol, which would be required for a transfer to be valid on the statechain.Tom provided a more detailed document specifying the proposed protocol, including improvements to the transfer mechanism and an explanation of how this can be used to transfer/novate positions in DLCs. He also addressed concerns about nChain Holdings' patent application related to secure off-chain blockchain transactions.The discussion is about the security assumptions of statechains. It is mentioned that an attack on statechains requires collaboration with the current UTXO owner, who is transferring the UXTO to a non-statechain entity and knows the target of the transfer, obtaining the target pubkey for the transfer out-of-band with respect to the SE or the SE can MITM that. The security assumption is that the sender or receiver does not collude with the SE. If either does, then the attack is generally possible.The SE cannot be allowed to be both operator of the SE and a customer of it as this clearly violates the no-receiver collusion principle. Adding a new user key doesn't change the situation as the user has already acquiesced to the transfer. Any past owner of the coin can collude with the statechain authority in order to steal the onchain funds regardless of who the current owner is within the statechain. So, trust must still be put in the statechain authority. The security assumptions should be that the statechain authority really does delete keys and does not make backups, and no past or current owner of the coin colludes with the statechain authority.The Statechain concept proposes non-custodial off-chain Bitcoin transfer. The current holder of UTXO must obtain the target pubkey for the transfer out-of-band with respect to the SE, or the SE can MITM that. Nadav Kohen raised concerns about an untraceable scam by the Statechain Entity (SE). It involves buying the UTXO, transferring it to someone else, - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_-Recurring-Taproot-activation-meeting-on-IRC-Tuesday-23rd-March-19-00-UTC-every-fortnight.xml b/static/bitcoin-dev/March_2021/combined_-Recurring-Taproot-activation-meeting-on-IRC-Tuesday-23rd-March-19-00-UTC-every-fortnight.xml index f361720ec2..62755caab4 100644 --- a/static/bitcoin-dev/March_2021/combined_-Recurring-Taproot-activation-meeting-on-IRC-Tuesday-23rd-March-19-00-UTC-every-fortnight.xml +++ b/static/bitcoin-dev/March_2021/combined_-Recurring-Taproot-activation-meeting-on-IRC-Tuesday-23rd-March-19-00-UTC-every-fortnight.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight - 2023-08-02T03:28:36.173363+00:00 - - Michael Folkson 2021-03-22 12:10:03+00:00 - - - Jeremy 2021-03-21 18:10:42+00:00 - - - Jeremy 2021-03-19 21:41:43+00:00 - + 2025-09-26T16:05:27.497230+00:00 + python-feedgen + + + [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight Jeremy + 2021-03-19T21:41:00.000Z + + + Jeremy + 2021-03-21T18:10:00.000Z + + + Michael Folkson + 2021-03-22T12:10:00.000Z + + - python-feedgen + 2 Combined summary - (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight - 2023-08-02T03:28:36.174362+00:00 + 2025-09-26T16:05:27.497875+00:00 - The activation of Taproot is gaining importance among stakeholders, with the proposed start height set for May 1st. To address any concerns regarding block height versus MTP and proposed timetables, a meeting will be held on Tuesday, which everyone is encouraged to attend. It is crucial to avoid dragging the minimum activation height into December, making November an ideal time. Flexibility exists in the exact timetable to ensure the optimal code is merged. For further assistance, Michael Folkson can be contacted via email or Keybase, and his PGP key is provided.Jeremy Rubin has sent a reminder email for the Taproot Activation Meeting, which he will host. The meeting is scheduled for 19:00 UTC on Tuesday (12pm Pacific Time). Participants are urged to pre-register any comments today or tomorrow, including concerns about using a Speedy Trial to activate Taproot. The primary focus of the meeting will be addressing any blocking issues and finalizing parameter selection. Discussions will also cover selecting between start/stop heights and times for a speedy trial, parameter selection for start/stop/active points, parameter flexibility, and simultaneous UASF. Those unable to attend can pre-register their comments by replying to the email, adhering to the specified categories to keep the meeting on track. An ICS file with scheduling for this meeting and subsequent ones in advance is attached. Ongoing discussions can take place in the open channel, and participants can utilize the web chat client available.Jeremy Rubin has proposed a Taproot Activation Meeting to conclude parameter selection and resolve any blocking issues. The meeting, held fortnightly in the future, will take place on Tuesday. Attendees must pre-register their comments, and the focal points will involve resolving concerns related to using a Speedy Trial for Taproot activation, selecting start/stop heights and times for a speedy trial, parameter selection for start/stop/active points, parameter flexibility, and simultaneous UASF. Specific instructions for participation can be found in the email, and an ongoing discussion can be carried out through the web chat client provided. 2021-03-22T12:10:03+00:00 + The activation of Taproot is gaining importance among stakeholders, with the proposed start height set for May 1st. To address any concerns regarding block height versus MTP and proposed timetables, a meeting will be held on Tuesday, which everyone is encouraged to attend. It is crucial to avoid dragging the minimum activation height into December, making November an ideal time. Flexibility exists in the exact timetable to ensure the optimal code is merged. For further assistance, Michael Folkson can be contacted via email or Keybase, and his PGP key is provided.Jeremy Rubin has sent a reminder email for the Taproot Activation Meeting, which he will host. The meeting is scheduled for 19:00 UTC on Tuesday (12pm Pacific Time). Participants are urged to pre-register any comments today or tomorrow, including concerns about using a Speedy Trial to activate Taproot. The primary focus of the meeting will be addressing any blocking issues and finalizing parameter selection. Discussions will also cover selecting between start/stop heights and times for a speedy trial, parameter selection for start/stop/active points, parameter flexibility, and simultaneous UASF. Those unable to attend can pre-register their comments by replying to the email, adhering to the specified categories to keep the meeting on track. An ICS file with scheduling for this meeting and subsequent ones in advance is attached. Ongoing discussions can take place in the open channel, and participants can utilize the web chat client available.Jeremy Rubin has proposed a Taproot Activation Meeting to conclude parameter selection and resolve any blocking issues. The meeting, held fortnightly in the future, will take place on Tuesday. Attendees must pre-register their comments, and the focal points will involve resolving concerns related to using a Speedy Trial for Taproot activation, selecting start/stop heights and times for a speedy trial, parameter selection for start/stop/active points, parameter flexibility, and simultaneous UASF. Specific instructions for participation can be found in the email, and an ongoing discussion can be carried out through the web chat client provided. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_A-design-for-Probabilistic-Partial-Pruning.xml b/static/bitcoin-dev/March_2021/combined_A-design-for-Probabilistic-Partial-Pruning.xml index 74d4a0c1a8..239fc3ca75 100644 --- a/static/bitcoin-dev/March_2021/combined_A-design-for-Probabilistic-Partial-Pruning.xml +++ b/static/bitcoin-dev/March_2021/combined_A-design-for-Probabilistic-Partial-Pruning.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - A design for Probabilistic Partial Pruning - 2023-08-02T03:15:34.692962+00:00 - - Keagan McClelland 2021-03-01 20:55:10+00:00 - - - eric at voskuil.org 2021-03-01 09:37:06+00:00 - - - Craig Raw 2021-03-01 06:22:01+00:00 - - - Leo Wandersleb 2021-02-28 03:41:06+00:00 - - - David A. Harding 2021-02-27 23:37:52+00:00 - - - Yuval Kogman 2021-02-27 22:13:29+00:00 - - - Yuval Kogman 2021-02-27 22:09:48+00:00 - - - David A. Harding 2021-02-27 19:19:34+00:00 - - - Igor Cota 2021-02-27 07:10:39+00:00 - - - Keagan McClelland 2021-02-26 18:40:35+00:00 - + 2025-09-26T16:05:58.980732+00:00 + python-feedgen + + + [bitcoin-dev] A design for Probabilistic Partial Pruning Keagan McClelland + 2021-02-26T18:40:00.000Z + + + Igor Cota + 2021-02-27T07:10:00.000Z + + + David A. Harding + 2021-02-27T19:19:00.000Z + + + Yuval Kogman + 2021-02-27T22:09:00.000Z + + + Yuval Kogman + 2021-02-27T22:13:00.000Z + + + David A. Harding + 2021-02-27T23:37:00.000Z + + + Leo Wandersleb + 2021-02-28T03:41:00.000Z + + + Craig Raw + 2021-03-01T06:22:00.000Z + + + eric + 2021-03-01T09:37:00.000Z + + + Keagan McClelland + 2021-03-01T20:55:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - A design for Probabilistic Partial Pruning - 2023-08-02T03:15:34.692962+00:00 + 2025-09-26T16:05:58.982002+00:00 - The bitcoin-dev mailing list has been discussing a proposal to address the issue of ongoing storage costs for full nodes and pruned nodes. Currently, users have two options: either prune everything except the most recent blocks or keep everything since genesis. The proposed solution is to randomly prune some of the blocks from history based on a unique node seed and threshold expressed as a percentage of blocks. This would increase data redundancy and share the load across nodes more uniformly, reducing the pressure on full archive nodes during the initial block download (IBD) process.The discussion also explores the use of fountain codes to increase data redundancy and improve the distribution of blocks. Fountain codes create an infinite stream of codewords that can be XORed to recover the full message. This approach, known as SeF, retains a fixed number of codewords from the encoding concatenated blocks and serves them to compatible clients. It has been found to be more robust than retaining a random sample of blocks.The proposal suggests advertising the node's seed and threshold as a peer service once the IBD is complete. This would allow other nodes to determine which blocks each peer has. However, concerns about fingerprinting weaknesses have been raised, and it is noted that popular node software is unlikely to adopt this idea unless it solves an urgent problem.Another suggestion is to decide on a range of blocks to keep beforehand, rather than making the decision block-by-block. This could be computationally lighter and better serve other nodes due to the sequential nature of IBD. A paper proposing a distributed hash table (DHT) scheme by Ryosuke Abe is recommended for further reading.Overall, the proposal aims to provide a solution to the ongoing storage costs for full nodes and pruned nodes by randomly pruning blocks from history based on a unique node seed and threshold. Feedback is being sought on the protocol design and the barriers to implementing this functionality into Core. 2021-03-01T20:55:10+00:00 + The bitcoin-dev mailing list has been discussing a proposal to address the issue of ongoing storage costs for full nodes and pruned nodes. Currently, users have two options: either prune everything except the most recent blocks or keep everything since genesis. The proposed solution is to randomly prune some of the blocks from history based on a unique node seed and threshold expressed as a percentage of blocks. This would increase data redundancy and share the load across nodes more uniformly, reducing the pressure on full archive nodes during the initial block download (IBD) process.The discussion also explores the use of fountain codes to increase data redundancy and improve the distribution of blocks. Fountain codes create an infinite stream of codewords that can be XORed to recover the full message. This approach, known as SeF, retains a fixed number of codewords from the encoding concatenated blocks and serves them to compatible clients. It has been found to be more robust than retaining a random sample of blocks.The proposal suggests advertising the node's seed and threshold as a peer service once the IBD is complete. This would allow other nodes to determine which blocks each peer has. However, concerns about fingerprinting weaknesses have been raised, and it is noted that popular node software is unlikely to adopt this idea unless it solves an urgent problem.Another suggestion is to decide on a range of blocks to keep beforehand, rather than making the decision block-by-block. This could be computationally lighter and better serve other nodes due to the sequential nature of IBD. A paper proposing a distributed hash table (DHT) scheme by Ryosuke Abe is recommended for further reading.Overall, the proposal aims to provide a solution to the ongoing storage costs for full nodes and pruned nodes by randomly pruning blocks from history based on a unique node seed and threshold. Feedback is being sought on the protocol design and the barriers to implementing this functionality into Core. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_An-alternative-to-BIP-32-.xml b/static/bitcoin-dev/March_2021/combined_An-alternative-to-BIP-32-.xml index db3080d97c..094b5cba2d 100644 --- a/static/bitcoin-dev/March_2021/combined_An-alternative-to-BIP-32-.xml +++ b/static/bitcoin-dev/March_2021/combined_An-alternative-to-BIP-32-.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - An alternative to BIP 32? - 2023-08-02T03:28:21.017941+00:00 - - Erik Aronesty 2021-03-22 12:05:13+00:00 - - - vjudeu 2021-03-22 07:51:00+00:00 - - - Tim Ruffing 2021-03-21 21:45:19+00:00 - - - vjudeu 2021-03-20 20:25:36+00:00 - - - vjudeu 2021-03-20 20:25:03+00:00 - - - Tim Ruffing 2021-03-20 10:08:30+00:00 - - - Arik Sosman 2021-03-20 02:08:39+00:00 - - - Erik Aronesty 2021-03-20 01:32:46+00:00 - - - vjudeu 2021-03-19 19:46:26+00:00 - + 2025-09-26T16:05:35.905711+00:00 + python-feedgen + + + [bitcoin-dev] An alternative to BIP 32? vjudeu + 2021-03-19T19:46:00.000Z + + + Erik Aronesty + 2021-03-20T01:32:00.000Z + + + Arik Sosman + 2021-03-20T02:08:00.000Z + + + Tim Ruffing + 2021-03-20T10:08:00.000Z + + + vjudeu + 2021-03-20T20:25:00.000Z + + + vjudeu + 2021-03-20T20:25:00.000Z + + + Tim Ruffing + 2021-03-21T21:45:00.000Z + + + vjudeu + 2021-03-22T07:51:00.000Z + + + Erik Aronesty + 2021-03-22T12:05:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - An alternative to BIP 32? - 2023-08-02T03:28:21.017941+00:00 + 2025-09-26T16:05:35.906784+00:00 - In a recent email thread on the Bitcoin-dev mailing list, Erik Aronesty suggested using sha3-256 for generating hashes instead of sha256 due to certain attacks such as length extension. A user named Arik Sosman asked if sha256-hmac(nonce, publicKeyPoint) would be a suitable and safe alternative.The security of a hierarchical deterministic (HD) wallet scheme that can be specified in three lines cannot be assumed without specifying the security goals, according to Tim Ruffing. The main issue with using a simple incrementation method for public keys is that all those keys can be linked together easily. However, by making the offset deterministic but less predictable, it should be secure enough. Offset equals SHA256(masterPublicKey || nonce), but it is not clear how the nonce is obtained. In a deterministic scheme, either the master private key is involved in the derivation of nonce, which would make the nonce unpredictable, or it's not, which would make the nonce predictable. It may also be possible to compute a parent private key from a private key.The discussion revolves around the security of a proposed HD wallet scheme. The scheme involves using a private key to calculate a public key and incrementing it. However, all of the resulting public keys can be easily linked together, which is the only problem with this approach. To make it more secure, the suggestion is to use deterministic but less predictable offsets instead of simple incrementation. This would result in parent, first child and second child keys that cannot be linked together unless the offset is guessed by an attacker.The discussion revolves around the safety and suitability of a simple HD wallet design that uses pure ECDSA and SHA-256. The design involves generating a master public key and child public keys using SHA-256 and a nonce. The concern raised is whether this design is safe to implement in practice, given that SHA-256 suffers from certain attacks, such as length extension attacks. Erik Aronesty suggests using SHA3-256 instead, as it does not suffer from padding-related vulnerabilities.The safety of a HD wallet scheme was questioned by vjudeu in an email to bitcoin-dev. The scheme can be specified in just three lines, without even defining the security goals. In response, Tim stated that it would not be safe to assume the implementation of such a scheme is secure. His comment may come across as harsh, but it is important to prioritize safety when it comes to cryptocurrency wallets.In a discussion on the bitcoin-dev mailing list, a question was raised about the suitability and safety of using sha256-hmac(nonce, publicKeyPoint) as an alternative to sha3. Erik Aronesty recommended the use of sha3-256 instead, citing vulnerabilities in sha256 such as length extension attacks that could lead to information leaks depending on concatenation methods.In a discussion on the Bitcoin-dev mailing list, a user suggested using sha3-256 instead of sha256 for designing an HD wallet. They explained that sha256 is vulnerable to certain attacks such as length extension, which could potentially leak information depending on how things are concatenated. They suggest choosing something where padding doesn't matter.A user recently shared a link to a bitcoin forum discussing a simple and interesting HD wallet design. The user is seeking input on whether there are any flaws in the design or if it is safe for practical use. The design appears to use pure ECDSA and SHA-256, with a masterPublicKey generated from the masterPrivateKey multiplied by G. The masterChildPublicKey is derived from the masterPublicKey and a 256-bit nonce using SHA-256 and mod n. Similarly, the masterChildPrivateKey is derived from the masterPrivateKey and nonce using SHA-256 and mod n.Overall, the discussion highlights the importance of choosing secure algorithms when designing cryptographic schemes. In this case, the suggestion to use sha3-256 over sha256 may provide better protection against certain attacks. It is crucial for developers to thoroughly test and verify the security of any new implementations before use. 2021-03-22T12:05:13+00:00 + In a recent email thread on the Bitcoin-dev mailing list, Erik Aronesty suggested using sha3-256 for generating hashes instead of sha256 due to certain attacks such as length extension. A user named Arik Sosman asked if sha256-hmac(nonce, publicKeyPoint) would be a suitable and safe alternative.The security of a hierarchical deterministic (HD) wallet scheme that can be specified in three lines cannot be assumed without specifying the security goals, according to Tim Ruffing. The main issue with using a simple incrementation method for public keys is that all those keys can be linked together easily. However, by making the offset deterministic but less predictable, it should be secure enough. Offset equals SHA256(masterPublicKey || nonce), but it is not clear how the nonce is obtained. In a deterministic scheme, either the master private key is involved in the derivation of nonce, which would make the nonce unpredictable, or it's not, which would make the nonce predictable. It may also be possible to compute a parent private key from a private key.The discussion revolves around the security of a proposed HD wallet scheme. The scheme involves using a private key to calculate a public key and incrementing it. However, all of the resulting public keys can be easily linked together, which is the only problem with this approach. To make it more secure, the suggestion is to use deterministic but less predictable offsets instead of simple incrementation. This would result in parent, first child and second child keys that cannot be linked together unless the offset is guessed by an attacker.The discussion revolves around the safety and suitability of a simple HD wallet design that uses pure ECDSA and SHA-256. The design involves generating a master public key and child public keys using SHA-256 and a nonce. The concern raised is whether this design is safe to implement in practice, given that SHA-256 suffers from certain attacks, such as length extension attacks. Erik Aronesty suggests using SHA3-256 instead, as it does not suffer from padding-related vulnerabilities.The safety of a HD wallet scheme was questioned by vjudeu in an email to bitcoin-dev. The scheme can be specified in just three lines, without even defining the security goals. In response, Tim stated that it would not be safe to assume the implementation of such a scheme is secure. His comment may come across as harsh, but it is important to prioritize safety when it comes to cryptocurrency wallets.In a discussion on the bitcoin-dev mailing list, a question was raised about the suitability and safety of using sha256-hmac(nonce, publicKeyPoint) as an alternative to sha3. Erik Aronesty recommended the use of sha3-256 instead, citing vulnerabilities in sha256 such as length extension attacks that could lead to information leaks depending on concatenation methods.In a discussion on the Bitcoin-dev mailing list, a user suggested using sha3-256 instead of sha256 for designing an HD wallet. They explained that sha256 is vulnerable to certain attacks such as length extension, which could potentially leak information depending on how things are concatenated. They suggest choosing something where padding doesn't matter.A user recently shared a link to a bitcoin forum discussing a simple and interesting HD wallet design. The user is seeking input on whether there are any flaws in the design or if it is safe for practical use. The design appears to use pure ECDSA and SHA-256, with a masterPublicKey generated from the masterPrivateKey multiplied by G. The masterChildPublicKey is derived from the masterPublicKey and a 256-bit nonce using SHA-256 and mod n. Similarly, the masterChildPrivateKey is derived from the masterPrivateKey and nonce using SHA-256 and mod n.Overall, the discussion highlights the importance of choosing secure algorithms when designing cryptographic schemes. In this case, the suggestion to use sha3-256 over sha256 may provide better protection against certain attacks. It is crucial for developers to thoroughly test and verify the security of any new implementations before use. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_BIP-Proposal-Consensus-hard-fork-PoST-Datastore-for-Energy-Efficient-Mining.xml b/static/bitcoin-dev/March_2021/combined_BIP-Proposal-Consensus-hard-fork-PoST-Datastore-for-Energy-Efficient-Mining.xml index 53509dcdda..387e574c54 100644 --- a/static/bitcoin-dev/March_2021/combined_BIP-Proposal-Consensus-hard-fork-PoST-Datastore-for-Energy-Efficient-Mining.xml +++ b/static/bitcoin-dev/March_2021/combined_BIP-Proposal-Consensus-hard-fork-PoST-Datastore-for-Energy-Efficient-Mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining - 2023-08-02T03:22:33.957304+00:00 + 2025-09-26T16:05:10.618670+00:00 + python-feedgen Lonero Foundation 2021-03-17 07:06:32+00:00 @@ -151,13 +152,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining - 2023-08-02T03:22:33.957304+00:00 + 2025-09-26T16:05:10.618844+00:00 - In a recent email exchange on the Bitcoin-dev mailing list, there was a discussion about improving the cryptography layer for validation in Bitcoin mining. Andrew proposed a document suggesting a better cryptography algorithm that could reduce costs while maintaining security. However, Devrandom argued that the negative externalities of energy expenditure would soon be eliminated due to the adoption of renewable energy sources.The conversation also touched on the topic of proof of work (PoW) and its relation to energy consumption. Ryan Grant shared an article arguing that nothing is cheaper than proof of work, but it did not prove that energy expenditure has to be the primary cost of mining work. The paper mentioned that the mining market tends to expend resources equivalent to miner rewards, but it did not provide conclusive evidence about energy consumption as the primary cost.Andrew had also mentioned the idea of a staking hybrid, which could change the dynamics and economic forces in Bitcoin mining. However, staking was considered cryptodynamically insecure and not censorship-resistant, so it wouldn't likely be seen as a contribution to Bitcoin. Other attempts to improve energy efficiency were either disguised proof of work or repurposing computing power, neither of which would lead to a reduction in dedicated energy consumption.In another email exchange with the Lonero Foundation, Andrew proposed a cryptography proposal to improve hashing efficiency and address vulnerabilities in the BTC network. He believed that this upgrade should be discussed, considering the suggestion of bigger block height proposals as hard forks. Andrew asked about the preferred format for his proposal.Devrandom responded to another email by discussing the argument that proof of work is the cheapest method for mining. They pointed out that while the mining market tends to use resources equivalent to miner rewards, it does not necessarily mean that energy expenditure is the primary cost. Devrandom also mentioned that negative externalities from energy consumption may decrease as the move towards renewables progresses.The email thread focused on the discussion of a better cryptography layer for validation and the proposal of a document. It did not directly address the energy-efficient argument for renewables or mining devices. However, a paper was linked that suggested the mining market tends to use resources equivalent to rewards without proving energy expenditure as the primary cost. The debate revolved around the potential negative externalities of energy consumption and the potential reduction through renewable energy sources.In a separate email to the bitcoin-dev mailing list, a member of the Lonero Foundation proposed a BIP to address energy efficiency concerns in Bitcoin mining. However, another member disagreed with the proposal, citing previous discussions that rejected similar ideas. Links were provided to BIP 2, which outlines the BIP process, and a blog post advocating for the value of proof of work. The conversation shifted towards whether technically well-constructed proposals guaranteed to be rejected should be allowed in the BIP repository. It was suggested that such proposals should be unilaterally rejected as spam by the BIP Editor, but a moderation log should be maintained to ensure transparency and prevent censorship.The writer of one email sought guidance on creating a new BIP to tackle energy efficiency issues in Bitcoin mining. They were unsure about the format and whether to attach a README to their draft proposal on GitHub. Their proposed solution involved integrating a hybrid mining approach with proof of work and proof of stake for Bitcoin's SHA-256 hash algorithm. The writer, despite their background as a Quantum Engineer and Bioinformatics consultant, believed their proposal could be of interest and wanted to submit a detailed document explaining its workings. 2021-03-17T07:06:32+00:00 + In a recent email exchange on the Bitcoin-dev mailing list, there was a discussion about improving the cryptography layer for validation in Bitcoin mining. Andrew proposed a document suggesting a better cryptography algorithm that could reduce costs while maintaining security. However, Devrandom argued that the negative externalities of energy expenditure would soon be eliminated due to the adoption of renewable energy sources.The conversation also touched on the topic of proof of work (PoW) and its relation to energy consumption. Ryan Grant shared an article arguing that nothing is cheaper than proof of work, but it did not prove that energy expenditure has to be the primary cost of mining work. The paper mentioned that the mining market tends to expend resources equivalent to miner rewards, but it did not provide conclusive evidence about energy consumption as the primary cost.Andrew had also mentioned the idea of a staking hybrid, which could change the dynamics and economic forces in Bitcoin mining. However, staking was considered cryptodynamically insecure and not censorship-resistant, so it wouldn't likely be seen as a contribution to Bitcoin. Other attempts to improve energy efficiency were either disguised proof of work or repurposing computing power, neither of which would lead to a reduction in dedicated energy consumption.In another email exchange with the Lonero Foundation, Andrew proposed a cryptography proposal to improve hashing efficiency and address vulnerabilities in the BTC network. He believed that this upgrade should be discussed, considering the suggestion of bigger block height proposals as hard forks. Andrew asked about the preferred format for his proposal.Devrandom responded to another email by discussing the argument that proof of work is the cheapest method for mining. They pointed out that while the mining market tends to use resources equivalent to miner rewards, it does not necessarily mean that energy expenditure is the primary cost. Devrandom also mentioned that negative externalities from energy consumption may decrease as the move towards renewables progresses.The email thread focused on the discussion of a better cryptography layer for validation and the proposal of a document. It did not directly address the energy-efficient argument for renewables or mining devices. However, a paper was linked that suggested the mining market tends to use resources equivalent to rewards without proving energy expenditure as the primary cost. The debate revolved around the potential negative externalities of energy consumption and the potential reduction through renewable energy sources.In a separate email to the bitcoin-dev mailing list, a member of the Lonero Foundation proposed a BIP to address energy efficiency concerns in Bitcoin mining. However, another member disagreed with the proposal, citing previous discussions that rejected similar ideas. Links were provided to BIP 2, which outlines the BIP process, and a blog post advocating for the value of proof of work. The conversation shifted towards whether technically well-constructed proposals guaranteed to be rejected should be allowed in the BIP repository. It was suggested that such proposals should be unilaterally rejected as spam by the BIP Editor, but a moderation log should be maintained to ensure transparency and prevent censorship.The writer of one email sought guidance on creating a new BIP to tackle energy efficiency issues in Bitcoin mining. They were unsure about the format and whether to attach a README to their draft proposal on GitHub. Their proposed solution involved integrating a hybrid mining approach with proof of work and proof of stake for Bitcoin's SHA-256 hash algorithm. The writer, despite their background as a Quantum Engineer and Bioinformatics consultant, believed their proposal could be of interest and wanted to submit a detailed document explaining its workings. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_BIP70-is-dead-What-now-.xml b/static/bitcoin-dev/March_2021/combined_BIP70-is-dead-What-now-.xml index 88a48a5f54..e01b807a28 100644 --- a/static/bitcoin-dev/March_2021/combined_BIP70-is-dead-What-now-.xml +++ b/static/bitcoin-dev/March_2021/combined_BIP70-is-dead-What-now-.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - BIP70 is dead. What now? - 2023-08-02T03:12:49.715839+00:00 - - P G 2021-03-04 15:56:10+00:00 - - - Eoin McQuinn 2021-02-20 15:53:57+00:00 - - - Andrew Kozlik 2021-02-19 13:34:16+00:00 - - - Charles Hill 2021-02-19 10:33:45+00:00 - - - Thomas Voegtlin 2021-02-19 09:14:39+00:00 - + 2025-09-26T16:05:44.322992+00:00 + python-feedgen + + + [bitcoin-dev] BIP70 is dead. What now? Thomas Voegtlin + 2021-02-19T09:14:00.000Z + + + Charles Hill + 2021-02-19T10:33:00.000Z + + + Andrew Kozlik + 2021-02-19T13:34:00.000Z + + + Eoin McQuinn + 2021-02-20T15:53:00.000Z + + + P G + 2021-03-04T15:56:00.000Z + + - python-feedgen + 2 Combined summary - BIP70 is dead. What now? - 2023-08-02T03:12:49.715839+00:00 + 2025-09-26T16:05:44.323771+00:00 - In a recent Bitcoin-dev mailing list, Thomas Voegtlin expressed his dislike of the BIP70 standard but found the feature of signed payment requests useful. He believes that receiving a signed request from an exchange would serve as proof that the exchange asked him to send coins to a specific address, especially important in case of exchange hijacking. However, no exchange has implemented this feature. Andrew Kozlik shared his experimental implementation of a new payment request format in Trezor T, similar to BIP-70 but with some differences. It does not rely on X.509 and instead uses mandatory signatures for protection against man-in-the-middle attacks. It also solves problems with coin exchange by ensuring correct BTC and LTC addresses. Charles Hill shared a URL signing scheme for LNURL, which could be modified to fit Thomas' use-case. Voegtlin suggested adopting a standard for signed requests, which could guide users' decisions on which exchange to use. He would remove BIP70 support from Electrum if a new standard was adopted. 2021-03-04T15:56:10+00:00 + In a recent Bitcoin-dev mailing list, Thomas Voegtlin expressed his dislike of the BIP70 standard but found the feature of signed payment requests useful. He believes that receiving a signed request from an exchange would serve as proof that the exchange asked him to send coins to a specific address, especially important in case of exchange hijacking. However, no exchange has implemented this feature. Andrew Kozlik shared his experimental implementation of a new payment request format in Trezor T, similar to BIP-70 but with some differences. It does not rely on X.509 and instead uses mandatory signatures for protection against man-in-the-middle attacks. It also solves problems with coin exchange by ensuring correct BTC and LTC addresses. Charles Hill shared a URL signing scheme for LNURL, which could be modified to fit Thomas' use-case. Voegtlin suggested adopting a standard for signed requests, which could guide users' decisions on which exchange to use. He would remove BIP70 support from Electrum if a new standard was adopted. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Delegated-signatures-in-Bitcoin-within-existing-rules-no-fork-required.xml b/static/bitcoin-dev/March_2021/combined_Delegated-signatures-in-Bitcoin-within-existing-rules-no-fork-required.xml index f8d4b718b5..4b1875bcf5 100644 --- a/static/bitcoin-dev/March_2021/combined_Delegated-signatures-in-Bitcoin-within-existing-rules-no-fork-required.xml +++ b/static/bitcoin-dev/March_2021/combined_Delegated-signatures-in-Bitcoin-within-existing-rules-no-fork-required.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Delegated signatures in Bitcoin within existing rules, no fork required - 2023-08-02T03:23:46.918380+00:00 - - Guido Dassori 2021-03-24 13:33:07+00:00 - - - Jeremy 2021-03-17 06:30:23+00:00 - - - ZmnSCPxj 2021-03-16 08:36:09+00:00 - - - Jeremy 2021-03-16 06:16:23+00:00 - - - ZmnSCPxj 2021-03-16 06:09:56+00:00 - - - Jeremy 2021-03-10 23:55:43+00:00 - + 2025-09-26T16:05:48.501825+00:00 + python-feedgen + + + [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required Jeremy + 2021-03-10T23:55:00.000Z + + + ZmnSCPxj + 2021-03-16T06:09:00.000Z + + + Jeremy + 2021-03-16T06:16:00.000Z + + + ZmnSCPxj + 2021-03-16T08:36:00.000Z + + + Jeremy + 2021-03-17T06:30:00.000Z + + + Guido Dassori + 2021-03-24T13:33:00.000Z + + - python-feedgen + 2 Combined summary - Delegated signatures in Bitcoin within existing rules, no fork required - 2023-08-02T03:23:46.918380+00:00 + 2025-09-26T16:05:48.502697+00:00 - Guido mentioned that he implemented a similar idea in a POC available on GH since a while and they are working to make it production ready. They run a 2-on-3 wallet with buy/sell features and aim to cut their transaction fees down to ~5%.In the context of delegating funds, Jeremy Rubin notes that SIGHASH_NONE or SIGHASH_SINGLE can be used to allow the delegator to dynamically choose things like a change output. Jeremy also mentions that layered encryption can enable a decent amount of scripting capability for fully pre-signed transactions. He suggests that in cases where privacy is a goal, delegates can contact the original signer and ask to cooperate. However, in some circumstances this may not be viable given access to keys or whatnot.A hybrid approach can be taken where the user delegates to a script and provides a default sighash_all txn, and a modifiable sighash_none/single. Interestingly, there is a subset of cases where it is desirable to have privacy from the original script holder. ZmnSCPxj notes that an advantage of the technique that Jeremy described is that the delegator can impose additional restrictions that are programmable via any SCRIPT, an ability that merely handing over the privkey cannot do.If the delegatee is a known single entity, and S is simply the delegatee key plus some additional restrictions, it may be possible to sign with `SIGHASH_ALL` a transaction that spends A and D, and outputs to a singlesig of the delegatee key. This would avoid the use of `SIGHASH_NONE`, for a mild improvement in privacy. In terms of offchain technology, if the delegator remains online, the delegatee may present a witness satisfying S to the delegator, and ask the delegator to provide an alternate transaction that spends A directly without spending D and outputs to whatever the delegatee wants. The delegator cannot refuse since the delegatee can always use the `SIGHASH_NONE` signature and spend to whatever it decides provided it can present a witness satisfying S.One generalized use-case for delegation would be if the delegator suspects it may not be online or able to sign with the delegator key.The conversation between Jeremy Rubin and ZmnSCPxj discusses the advantages of using SIGHASH_NONE and SIGHASH_SINGLE for partial funds delegations. This allows the delegator to dynamically choose certain factors like a change output, which cannot be achieved by simply handing over the privkey. Additionally, layered encryption can be used to delegate to multiple parties using Checksig scripts and presigned transactions. However, this may compromise privacy, and in situations where privacy is a goal, the delegation can contact the original signer for cooperation. A hybrid approach could also be used, where delegates are provided with a default sighash_all txn and a modifiable sighash_none/single, allowing them to decide what is best to use. Another interesting point discussed is the subset of cases where it is desirable to have privacy from the original script holder. Overall, the conversation delves into various aspects and use-cases of delegation and highlights its advantages and limitations.The technique of delegating through additional restrictions programmable via any SCRIPT has an advantage over simply handing over the privkey to the delegatee. It allows for the imposition of further restrictions that cannot be achieved through mere handover. If the delegatee is a known single entity and S is the delegatee key plus some additional restrictions, it is possible to sign with `SIGHASH_ALL` a transaction that spends A and D and outputs to a singlesig of the delegatee key, which improves privacy. However, if S is already unusual enough, this variation may have little value. In terms of offchain technology, if the delegator remains online, the delegatee may present a witness satisfying S to the delegator and ask for an alternate transaction that spends A directly without spending D and outputs to whatever the delegatee wants. This is a typical "close transaction" for layer 2 technology.In this email conversation, ZmnSCPxj and JeremyRubin discuss various ideas related to Bitcoin transaction delegation. One idea discussed is the use of multiple delegates with independent scripts to enforce disparate conditions. This can be useful in cases where one delegate requires a relative height lock while another requires a relative time lock. Another idea discussed is sequenced contingent delegation, which involves constructing a specific TXID to delegate coins, making their delegation contingent on some other contract reaching a particular state. However, this model requires coordination between the main and observing contracts as each coin delegate can only be claimed once. Lastly, they discuss redelegating, where A delegates to S, who then delegates to S', allowing the original owner to still control the coin.The email discusses three different mechanisms for delegating coins in a Bitcoin transaction. The first mechanism, multiple delegates, involves signing a transaction with several delegate outputs to enforce multiple conditions. For example, one delegate output may require a relative 2021-03-24T13:33:07+00:00 + Guido mentioned that he implemented a similar idea in a POC available on GH since a while and they are working to make it production ready. They run a 2-on-3 wallet with buy/sell features and aim to cut their transaction fees down to ~5%.In the context of delegating funds, Jeremy Rubin notes that SIGHASH_NONE or SIGHASH_SINGLE can be used to allow the delegator to dynamically choose things like a change output. Jeremy also mentions that layered encryption can enable a decent amount of scripting capability for fully pre-signed transactions. He suggests that in cases where privacy is a goal, delegates can contact the original signer and ask to cooperate. However, in some circumstances this may not be viable given access to keys or whatnot.A hybrid approach can be taken where the user delegates to a script and provides a default sighash_all txn, and a modifiable sighash_none/single. Interestingly, there is a subset of cases where it is desirable to have privacy from the original script holder. ZmnSCPxj notes that an advantage of the technique that Jeremy described is that the delegator can impose additional restrictions that are programmable via any SCRIPT, an ability that merely handing over the privkey cannot do.If the delegatee is a known single entity, and S is simply the delegatee key plus some additional restrictions, it may be possible to sign with `SIGHASH_ALL` a transaction that spends A and D, and outputs to a singlesig of the delegatee key. This would avoid the use of `SIGHASH_NONE`, for a mild improvement in privacy. In terms of offchain technology, if the delegator remains online, the delegatee may present a witness satisfying S to the delegator, and ask the delegator to provide an alternate transaction that spends A directly without spending D and outputs to whatever the delegatee wants. The delegator cannot refuse since the delegatee can always use the `SIGHASH_NONE` signature and spend to whatever it decides provided it can present a witness satisfying S.One generalized use-case for delegation would be if the delegator suspects it may not be online or able to sign with the delegator key.The conversation between Jeremy Rubin and ZmnSCPxj discusses the advantages of using SIGHASH_NONE and SIGHASH_SINGLE for partial funds delegations. This allows the delegator to dynamically choose certain factors like a change output, which cannot be achieved by simply handing over the privkey. Additionally, layered encryption can be used to delegate to multiple parties using Checksig scripts and presigned transactions. However, this may compromise privacy, and in situations where privacy is a goal, the delegation can contact the original signer for cooperation. A hybrid approach could also be used, where delegates are provided with a default sighash_all txn and a modifiable sighash_none/single, allowing them to decide what is best to use. Another interesting point discussed is the subset of cases where it is desirable to have privacy from the original script holder. Overall, the conversation delves into various aspects and use-cases of delegation and highlights its advantages and limitations.The technique of delegating through additional restrictions programmable via any SCRIPT has an advantage over simply handing over the privkey to the delegatee. It allows for the imposition of further restrictions that cannot be achieved through mere handover. If the delegatee is a known single entity and S is the delegatee key plus some additional restrictions, it is possible to sign with `SIGHASH_ALL` a transaction that spends A and D and outputs to a singlesig of the delegatee key, which improves privacy. However, if S is already unusual enough, this variation may have little value. In terms of offchain technology, if the delegator remains online, the delegatee may present a witness satisfying S to the delegator and ask for an alternate transaction that spends A directly without spending D and outputs to whatever the delegatee wants. This is a typical "close transaction" for layer 2 technology.In this email conversation, ZmnSCPxj and JeremyRubin discuss various ideas related to Bitcoin transaction delegation. One idea discussed is the use of multiple delegates with independent scripts to enforce disparate conditions. This can be useful in cases where one delegate requires a relative height lock while another requires a relative time lock. Another idea discussed is sequenced contingent delegation, which involves constructing a specific TXID to delegate coins, making their delegation contingent on some other contract reaching a particular state. However, this model requires coordination between the main and observing contracts as each coin delegate can only be claimed once. Lastly, they discuss redelegating, where A delegates to S, who then delegates to S', allowing the original owner to still control the coin.The email discusses three different mechanisms for delegating coins in a Bitcoin transaction. The first mechanism, multiple delegates, involves signing a transaction with several delegate outputs to enforce multiple conditions. For example, one delegate output may require a relative - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Exploring-alternative-activation-mechanisms-decreasing-threshold.xml b/static/bitcoin-dev/March_2021/combined_Exploring-alternative-activation-mechanisms-decreasing-threshold.xml index 73243c1980..3f09c9555e 100644 --- a/static/bitcoin-dev/March_2021/combined_Exploring-alternative-activation-mechanisms-decreasing-threshold.xml +++ b/static/bitcoin-dev/March_2021/combined_Exploring-alternative-activation-mechanisms-decreasing-threshold.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Exploring alternative activation mechanisms: decreasing threshold - 2023-08-02T03:15:09.390974+00:00 - - Anthony Towns 2021-03-01 14:33:33+00:00 - - - Ryan Grant 2021-02-28 14:06:42+00:00 - - - Matt Corallo 2021-02-28 02:38:54+00:00 - - - Gregorio Guidi 2021-02-27 23:49:46+00:00 - - - Luke Dashjr 2021-02-27 17:55:00+00:00 - - - Ryan Grant 2021-02-26 17:48:33+00:00 - - - Gregorio Guidi 2021-02-25 22:33:25+00:00 - + 2025-09-26T16:05:19.052285+00:00 + python-feedgen + + + [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold Gregorio Guidi + 2021-02-25T22:33:00.000Z + + + Ryan Grant + 2021-02-26T17:48:00.000Z + + + Luke Dashjr + 2021-02-27T17:55:00.000Z + + + Gregorio Guidi + 2021-02-27T23:49:00.000Z + + + Matt Corallo + 2021-02-28T02:38:00.000Z + + + Ryan Grant + 2021-02-28T14:06:00.000Z + + + Anthony Towns + 2021-03-01T14:33:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Exploring alternative activation mechanisms: decreasing threshold - 2023-08-02T03:15:09.390974+00:00 + 2025-09-26T16:05:19.053153+00:00 - Bitcoin developer Luke Dashjr has expressed concerns about the potential chaos that could arise from non-signalled activation. He warns that anti-soft-fork and pro-SF nodes may end up on the same chain, following conflicting perceptions of the rules. This could result in a strong incentive not to rely on the rules if a resolution is not found.The author of the article discusses the potential risks and downsides of implementing soft forks in cryptocurrency. For instance, allowing miners to steal user funds goes against new rules, and enforcing new rules can lead to hard-fork events and the need for new software. To mitigate these risks, the author suggests delaying activation until all objections are resolved or committing to activation on-chain based on specific criteria.The author also provides examples of past controversial soft forks, including halting segwit deployment due to covert ASICBoost which could have prevented a hard forked chain split. However, the existing plan was followed, and BCH resulted.The author notes that small numbers of advocates running code to enforce a flag day could lead to failure, and that controversy may prevent adoption of certain soft forks. As a solution, the author suggests supporting "user-prohibited soft-forks" in a similar way to "user-activated soft-forks," moving action to whether users are required/prohibited from signaling.On February 27, 2021, Luke Dashjr, via bitcoin-dev expressed concern over the activation of softforks lacking signalling. According to him, this creates ambiguity as it is unclear if the softfork has been activated at all. However, he suggested that the ambiguity can be resolved by seeing one block in the heaviest valid chain.Gregorio Guidi proposed a new activation mechanism for soft forks called "decreasing threshold activation". This approach aims to overcome the limitations of the LOT=true/false dichotomy. It operates similarly to BIP8 but with a gradually reduced threshold that triggers the STARTED -> LOCKED_IN transition on each period in steps of 24 blocks (~1.2%). This approach is relatively conservative at the beginning, requiring a clear majority of signaling hashrate for activation to happen, indicating that the activation is relatively safe.The proposed method simplifies the activation mechanism and eliminates the need to work with different client releases and issues associated with deployed nodes with different consensus parameters. It also removes the motivation to create UASF clients that force activation and provides users and miners with time to safely fork themselves off from the chain followed by Core if they choose not to upgrade.The proposed method has received some pushback, but the hope is that it will be adopted as the default mechanism, requiring little discussion on how to activate future soft forks.Overall, the author emphasizes the need to carefully consider the implications and potential failure modes of implementing soft forks in cryptocurrency. The decreasing threshold activation proposal offers a potential solution to address some of the challenges and risks associated with soft forks. 2021-03-01T14:33:33+00:00 + Bitcoin developer Luke Dashjr has expressed concerns about the potential chaos that could arise from non-signalled activation. He warns that anti-soft-fork and pro-SF nodes may end up on the same chain, following conflicting perceptions of the rules. This could result in a strong incentive not to rely on the rules if a resolution is not found.The author of the article discusses the potential risks and downsides of implementing soft forks in cryptocurrency. For instance, allowing miners to steal user funds goes against new rules, and enforcing new rules can lead to hard-fork events and the need for new software. To mitigate these risks, the author suggests delaying activation until all objections are resolved or committing to activation on-chain based on specific criteria.The author also provides examples of past controversial soft forks, including halting segwit deployment due to covert ASICBoost which could have prevented a hard forked chain split. However, the existing plan was followed, and BCH resulted.The author notes that small numbers of advocates running code to enforce a flag day could lead to failure, and that controversy may prevent adoption of certain soft forks. As a solution, the author suggests supporting "user-prohibited soft-forks" in a similar way to "user-activated soft-forks," moving action to whether users are required/prohibited from signaling.On February 27, 2021, Luke Dashjr, via bitcoin-dev expressed concern over the activation of softforks lacking signalling. According to him, this creates ambiguity as it is unclear if the softfork has been activated at all. However, he suggested that the ambiguity can be resolved by seeing one block in the heaviest valid chain.Gregorio Guidi proposed a new activation mechanism for soft forks called "decreasing threshold activation". This approach aims to overcome the limitations of the LOT=true/false dichotomy. It operates similarly to BIP8 but with a gradually reduced threshold that triggers the STARTED -> LOCKED_IN transition on each period in steps of 24 blocks (~1.2%). This approach is relatively conservative at the beginning, requiring a clear majority of signaling hashrate for activation to happen, indicating that the activation is relatively safe.The proposed method simplifies the activation mechanism and eliminates the need to work with different client releases and issues associated with deployed nodes with different consensus parameters. It also removes the motivation to create UASF clients that force activation and provides users and miners with time to safely fork themselves off from the chain followed by Core if they choose not to upgrade.The proposed method has received some pushback, but the hope is that it will be adopted as the default mechanism, requiring little discussion on how to activate future soft forks.Overall, the author emphasizes the need to carefully consider the implications and potential failure modes of implementing soft forks in cryptocurrency. The decreasing threshold activation proposal offers a potential solution to address some of the challenges and risks associated with soft forks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_LOT-False-is-dangerous-and-shouldn-t-be-used.xml b/static/bitcoin-dev/March_2021/combined_LOT-False-is-dangerous-and-shouldn-t-be-used.xml index 96de6aad06..8e5f6725b2 100644 --- a/static/bitcoin-dev/March_2021/combined_LOT-False-is-dangerous-and-shouldn-t-be-used.xml +++ b/static/bitcoin-dev/March_2021/combined_LOT-False-is-dangerous-and-shouldn-t-be-used.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - LOT=False is dangerous and shouldn't be used - 2023-08-02T03:18:28.798769+00:00 - - yanmaani at cock.li 2021-03-03 22:58:10+00:00 - - - Emil Pfeffer 2021-03-03 16:27:24+00:00 - - - Eric Voskuil 2021-03-02 20:07:16+00:00 - - - Chris Belcher 2021-03-02 18:21:59+00:00 - - - Erik Aronesty 2021-03-02 06:11:17+00:00 - - - Emil Pfeffer 2021-03-01 17:52:54+00:00 - - - yanmaani at cock.li 2021-03-01 16:54:07+00:00 - - - Anthony Towns 2021-03-01 15:06:14+00:00 - - - Luke Dashjr 2021-02-28 19:33:30+00:00 - + 2025-09-26T16:05:08.506333+00:00 + python-feedgen + + + [bitcoin-dev] LOT=False is dangerous and shouldn't be used Luke Dashjr + 2021-02-28T19:33:00.000Z + + + Anthony Towns + 2021-03-01T15:06:00.000Z + + + yanmaani + 2021-03-01T16:54:00.000Z + + + Emil Pfeffer + 2021-03-01T17:52:00.000Z + + + Erik Aronesty + 2021-03-02T06:11:00.000Z + + + Chris Belcher + 2021-03-02T18:21:00.000Z + + + Eric Voskuil + 2021-03-02T20:07:00.000Z + + + Emil Pfeffer + 2021-03-03T16:27:00.000Z + + + yanmaani + 2021-03-03T22:58:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - LOT=False is dangerous and shouldn't be used - 2023-08-02T03:18:28.798769+00:00 + 2025-09-26T16:05:08.507387+00:00 - The email thread and discussion on the bitcoin-dev mailing list revolve around the activation mechanism for the Taproot soft fork in Bitcoin. The proposal of LOT=false, where Taproot will be activated if at least 95% of miners vote yes, is compared to the LOT=true proposal, where Taproot will be activated if at least 0% of miners vote yes. A declining percentage of signaling activation is suggested as a compromise, eventually becoming a LOT=true. It is argued that LOT=true holds all the benefits and satisfies arguments for LOT=false with the cooldown period.It is mentioned that old node software will continue to work in the case of a soft-fork, and users following bip8 with lockinontimeout=false will enforce taproot rules if activation occurs. The risk is said to be maximally reduced by deploying LOT=True as the only parameter, while introducing LOT=False would increase the probability and severity of risk.There is a debate over the use of miner signaling for activation, with one member arguing that it is not a bug but an inherent part of how Bitcoin works. The purpose of miner signaling is to avoid a chain split by countering majority hash power censorship. However, another member argues that using LOT=false reintroduces a bug by giving miners a veto and incentive to second-guess activation decisions. In contrast, LOT=true avoids regression on bugs and combines the certainty of a flag day with the speed improvement of a MASF.The discussion also covers concerns about chain splits and unreliable networks for users who do not enforce Taproot rules. It is pointed out that avoiding a reorg can be achieved through various means, such as running "invalidateblock" or examining block headers. However, there are differing opinions on the level of risk associated with LOT=False. Some argue that LOT=True should be the only deployed parameter to minimize risk, while others note that LOT=False is already the default behavior of existing node software.The conversation also touches on the potential for miners to veto a BIP 9 activation, with one member claiming that miners were unable to do so in 2017. However, there is disagreement on whether this is a valid argument.In conclusion, the debate revolves around the risks and benefits of using LOT=true or LOT=false for Taproot activation. Some argue that LOT=false puts users and the network at significant risk, while others believe that LOT=true minimizes risk for everyone. There is a call to remove LOT as an option entirely and deploy all soft forks with LOT=true, but there is no consensus on this issue yet. 2021-03-03T22:58:10+00:00 + The email thread and discussion on the bitcoin-dev mailing list revolve around the activation mechanism for the Taproot soft fork in Bitcoin. The proposal of LOT=false, where Taproot will be activated if at least 95% of miners vote yes, is compared to the LOT=true proposal, where Taproot will be activated if at least 0% of miners vote yes. A declining percentage of signaling activation is suggested as a compromise, eventually becoming a LOT=true. It is argued that LOT=true holds all the benefits and satisfies arguments for LOT=false with the cooldown period.It is mentioned that old node software will continue to work in the case of a soft-fork, and users following bip8 with lockinontimeout=false will enforce taproot rules if activation occurs. The risk is said to be maximally reduced by deploying LOT=True as the only parameter, while introducing LOT=False would increase the probability and severity of risk.There is a debate over the use of miner signaling for activation, with one member arguing that it is not a bug but an inherent part of how Bitcoin works. The purpose of miner signaling is to avoid a chain split by countering majority hash power censorship. However, another member argues that using LOT=false reintroduces a bug by giving miners a veto and incentive to second-guess activation decisions. In contrast, LOT=true avoids regression on bugs and combines the certainty of a flag day with the speed improvement of a MASF.The discussion also covers concerns about chain splits and unreliable networks for users who do not enforce Taproot rules. It is pointed out that avoiding a reorg can be achieved through various means, such as running "invalidateblock" or examining block headers. However, there are differing opinions on the level of risk associated with LOT=False. Some argue that LOT=True should be the only deployed parameter to minimize risk, while others note that LOT=False is already the default behavior of existing node software.The conversation also touches on the potential for miners to veto a BIP 9 activation, with one member claiming that miners were unable to do so in 2017. However, there is disagreement on whether this is a valid argument.In conclusion, the debate revolves around the risks and benefits of using LOT=true or LOT=false for Taproot activation. Some argue that LOT=false puts users and the network at significant risk, while others believe that LOT=true minimizes risk for everyone. There is a call to remove LOT as an option entirely and deploy all soft forks with LOT=true, but there is no consensus on this issue yet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_MASF-true-LOT-informational.xml b/static/bitcoin-dev/March_2021/combined_MASF-true-LOT-informational.xml index 07422731cf..b0066a66c1 100644 --- a/static/bitcoin-dev/March_2021/combined_MASF-true-LOT-informational.xml +++ b/static/bitcoin-dev/March_2021/combined_MASF-true-LOT-informational.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - MASF=true + LOT=informational - 2023-08-02T03:21:06.811628+00:00 - - Erik Aronesty 2021-03-04 18:40:18+00:00 - - - John Rand 2021-03-04 14:25:41+00:00 - + 2025-09-26T16:05:52.685943+00:00 + python-feedgen + + + [bitcoin-dev] MASF=true + LOT=informational John Rand + 2021-03-04T14:25:00.000Z + + + Erik Aronesty + 2021-03-04T18:40:00.000Z + + - python-feedgen + 2 Combined summary - MASF=true + LOT=informational - 2023-08-02T03:21:06.811628+00:00 + 2025-09-26T16:05:52.686395+00:00 - The Bitcoin community is currently engaged in discussions regarding the activation configurations for soft forks. The developers are seeking ways to improve the mechanisms for activating these forks. Four activation configurations have been proposed and analyzed, each with its own rationale.The first configuration involves setting MASF (Miner Activated Soft Fork) to true and LOT (Lock-in on Timeout) to false. This approach is considered a safe and conservative option. However, it also perpetuates the risk demonstrated by BIP 141/BIP9.The second configuration is the inverse of the first, with MASF set to true and LOT set to true. The third configuration suggests setting MASF to false and LOT to informational. This configuration utilizes the non-standardness part of schnorr to activate at a flag height without normative signaling in version bits. However, it introduces needless delays.The fourth configuration combines MASF set to true (similar to the first or second configuration) with LOT set to informational (as in the third configuration). This configuration provides signaling in an optional and informational sense that is not normative for consensus code. It informs the ecosystem about hashrate-verified opt-in assertion of readiness from pools.Using a declining activation threshold over time grants miners control over the timing of activation, rather than leaving it to chance. This approach is similar to LOT set to true, but with a higher likelihood of activation without requiring intervening releases or changes to the code.There were concerns raised about offending miners, but given that pools indicated approximately 90% support, this concern seems dubious to many. Additionally, if there were a market need to reject a soft-fork, that could also be done with a UASF (User Activated Soft Fork).Disagreements and the potential for partly incompatible clients with different activation configurations change the risk calculation for LOT set to false. Therefore, LOT set to false may not be safer in practice, and it does not absolve reference client developers from contributing to the combined risk.To avoid misinterpretation of developer control, if LOT set to true were a hidden flag in bitcoin reference code or released by another project, it would prevent any misunderstandings about control. Further discussions on the thread propose substituting informational signaling instead, which would allow users and the market to benefit from information about miner intent. This approach may be more reliable in signaling a willing readiness rather than a UASF under duress mandatory signal.The community is actively considering different combinations of MASF and LOT, taking into account reliability and informing the ecosystem about hashrate-verified opt-in assertions of readiness from pools. In the event that activation is unreasonably delayed, forced miner signaling could be argued to be less reliable, as the mechanism for signaling on pools lacks an automated link to fullnode software versions.Users and services are advised to ensure they are running schnorr validating full-nodes, and SPV (Simplified Payment Verification) users should verify that their wallets rely on schnorr upgraded full-nodes. These measures will help ensure the smooth implementation of the proposed activation configurations for soft forks in the Bitcoin network. 2021-03-04T18:40:18+00:00 + The Bitcoin community is currently engaged in discussions regarding the activation configurations for soft forks. The developers are seeking ways to improve the mechanisms for activating these forks. Four activation configurations have been proposed and analyzed, each with its own rationale.The first configuration involves setting MASF (Miner Activated Soft Fork) to true and LOT (Lock-in on Timeout) to false. This approach is considered a safe and conservative option. However, it also perpetuates the risk demonstrated by BIP 141/BIP9.The second configuration is the inverse of the first, with MASF set to true and LOT set to true. The third configuration suggests setting MASF to false and LOT to informational. This configuration utilizes the non-standardness part of schnorr to activate at a flag height without normative signaling in version bits. However, it introduces needless delays.The fourth configuration combines MASF set to true (similar to the first or second configuration) with LOT set to informational (as in the third configuration). This configuration provides signaling in an optional and informational sense that is not normative for consensus code. It informs the ecosystem about hashrate-verified opt-in assertion of readiness from pools.Using a declining activation threshold over time grants miners control over the timing of activation, rather than leaving it to chance. This approach is similar to LOT set to true, but with a higher likelihood of activation without requiring intervening releases or changes to the code.There were concerns raised about offending miners, but given that pools indicated approximately 90% support, this concern seems dubious to many. Additionally, if there were a market need to reject a soft-fork, that could also be done with a UASF (User Activated Soft Fork).Disagreements and the potential for partly incompatible clients with different activation configurations change the risk calculation for LOT set to false. Therefore, LOT set to false may not be safer in practice, and it does not absolve reference client developers from contributing to the combined risk.To avoid misinterpretation of developer control, if LOT set to true were a hidden flag in bitcoin reference code or released by another project, it would prevent any misunderstandings about control. Further discussions on the thread propose substituting informational signaling instead, which would allow users and the market to benefit from information about miner intent. This approach may be more reliable in signaling a willing readiness rather than a UASF under duress mandatory signal.The community is actively considering different combinations of MASF and LOT, taking into account reliability and informing the ecosystem about hashrate-verified opt-in assertions of readiness from pools. In the event that activation is unreasonably delayed, forced miner signaling could be argued to be less reliable, as the mechanism for signaling on pools lacks an automated link to fullnode software versions.Users and services are advised to ensure they are running schnorr validating full-nodes, and SPV (Simplified Payment Verification) users should verify that their wallets rely on schnorr upgraded full-nodes. These measures will help ensure the smooth implementation of the proposed activation configurations for soft forks in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Making-the-case-for-flag-day-activation-of-taproot.xml b/static/bitcoin-dev/March_2021/combined_Making-the-case-for-flag-day-activation-of-taproot.xml index e50df8a850..1584c9ad86 100644 --- a/static/bitcoin-dev/March_2021/combined_Making-the-case-for-flag-day-activation-of-taproot.xml +++ b/static/bitcoin-dev/March_2021/combined_Making-the-case-for-flag-day-activation-of-taproot.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Making the case for flag day activation of taproot - 2023-08-02T03:20:33.318346+00:00 - - Anthony Towns 2021-03-29 09:17:57+00:00 - - - Matt Corallo 2021-03-06 17:57:22+00:00 - - - Luke Dashjr 2021-03-05 18:17:40+00:00 - - - Ryan Grant 2021-03-05 14:51:12+00:00 - - - Eric Voskuil 2021-03-04 23:45:11+00:00 - - - Keagan McClelland 2021-03-04 18:23:21+00:00 - - - Russell O'Connor 2021-03-04 13:47:13+00:00 - - - Matt Corallo 2021-03-03 22:14:10+00:00 - - - Luke Kenneth Casson Leighton 2021-03-03 22:12:21+00:00 - - - yanmaani at cock.li 2021-03-03 21:39:33+00:00 - - - Chris Belcher 2021-03-03 20:48:17+00:00 - - - Russell O'Connor 2021-03-03 19:08:21+00:00 - - - yanmaani at cock.li 2021-03-03 17:30:20+00:00 - - - Vincent Truong 2021-03-03 16:19:42+00:00 - - - Chris Belcher 2021-03-03 14:39:23+00:00 - + 2025-09-26T16:05:23.293278+00:00 + python-feedgen + + + [bitcoin-dev] Making the case for flag day activation of taproot Chris Belcher + 2021-03-03T14:39:00.000Z + + + Vincent Truong + 2021-03-03T16:19:00.000Z + + + yanmaani + 2021-03-03T17:30:00.000Z + + + Russell O'Connor + 2021-03-03T19:08:00.000Z + + + Chris Belcher + 2021-03-03T20:48:00.000Z + + + yanmaani + 2021-03-03T21:39:00.000Z + + + Luke Kenneth Casson Leighton + 2021-03-03T22:12:00.000Z + + + Matt Corallo + 2021-03-03T22:14:00.000Z + + + Russell O'Connor + 2021-03-04T13:47:00.000Z + + + Keagan McClelland + 2021-03-04T18:23:00.000Z + + + Eric Voskuil + 2021-03-04T23:45:00.000Z + + + Ryan Grant + 2021-03-05T14:51:00.000Z + + + Luke Dashjr + 2021-03-05T18:17:00.000Z + + + Matt Corallo + 2021-03-06T17:57:00.000Z + + + Anthony Towns + 2021-03-29T09:17:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Making the case for flag day activation of taproot - 2023-08-02T03:20:33.318346+00:00 + 2025-09-26T16:05:23.295022+00:00 - In the ongoing debate within the Bitcoin community about activating Taproot, Bitcoin developer Chris Belcher proposed flag day activation as a potential solution. This method aims to avoid social media brinksmanship and potential chain splits by setting a specific block height after which the new Taproot rules become enforced. Flag day activation eliminates the reliance on miner signaling and gives users more control over the adoption of new software.The proposed flag day activation method aims to provide a smoother transition to the new rules. By choosing a block height in the future or having mining pools, businesses, and users review the code and assess its neutrality and benefits, conservative supporters can feel more comfortable with the activation process. It also mitigates the vulnerability to social media attacks by requiring all users to run different node software.While there are concerns that flag day activation may limit opposition through social media and force users to comply with Core's decisions, alternative suggestions include making controversial settings changeable without requiring a fork. The BIP8 method, previously proposed, has faced gridlock due to concerns about different parts of the ecosystem running different consensus rules. This lack of agreement within the community risks missing the opportunity for Taproot and future soft forks.In conclusion, the proposal for flag day activation is seen as a way forward that addresses objections and risks associated with other methods. It ensures a smoother transition to Taproot while allowing users to have more control over the activation process. However, the decision on how to proceed ultimately lies with the Bitcoin economy and its users. 2021-03-29T09:17:57+00:00 + In the ongoing debate within the Bitcoin community about activating Taproot, Bitcoin developer Chris Belcher proposed flag day activation as a potential solution. This method aims to avoid social media brinksmanship and potential chain splits by setting a specific block height after which the new Taproot rules become enforced. Flag day activation eliminates the reliance on miner signaling and gives users more control over the adoption of new software.The proposed flag day activation method aims to provide a smoother transition to the new rules. By choosing a block height in the future or having mining pools, businesses, and users review the code and assess its neutrality and benefits, conservative supporters can feel more comfortable with the activation process. It also mitigates the vulnerability to social media attacks by requiring all users to run different node software.While there are concerns that flag day activation may limit opposition through social media and force users to comply with Core's decisions, alternative suggestions include making controversial settings changeable without requiring a fork. The BIP8 method, previously proposed, has faced gridlock due to concerns about different parts of the ecosystem running different consensus rules. This lack of agreement within the community risks missing the opportunity for Taproot and future soft forks.In conclusion, the proposal for flag day activation is seen as a way forward that addresses objections and risks associated with other methods. It ensures a smoother transition to Taproot while allowing users to have more control over the activation process. However, the decision on how to proceed ultimately lies with the Bitcoin economy and its users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml b/static/bitcoin-dev/March_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml index 8e32d05db1..5de4774b01 100644 --- a/static/bitcoin-dev/March_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml +++ b/static/bitcoin-dev/March_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - March 23rd 2021 Taproot Activation Meeting Notes - 2023-08-02T03:29:44.650329+00:00 + 2025-09-26T16:05:16.959307+00:00 + python-feedgen Anthony Towns 2021-04-08 11:11:06+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - March 23rd 2021 Taproot Activation Meeting Notes - 2023-08-02T03:29:44.651293+00:00 + 2025-09-26T16:05:16.959499+00:00 - In recent discussions on the bitcoin-dev mailing list, the focus has been on establishing developer and user consensus for Bitcoin. One suggestion is to create a contingency plan for a chain split, which some argue is good preparation. However, others believe that this approach does not address the underlying issue of consensus. The ideal scenario would allow users to download any version of bitcoind and run it with default settings, confident in the validity of their payments. Third-party explorers can track invalid chains, but these measures are only useful after a split has occurred. The risk of a split is higher during an attack on Bitcoin. Suggestions like lockinontimeout have been made, but they are not seen as the ideal solution. Businesses accepting Bitcoin payments need to know what software to run to stay in consensus with the network. Streamlining the consensus-building process is crucial. One possible solution is to implement an approach dealing with miners who don't upgrade to enforce a soft-fork quickly.Another thread discussed the Signet-based Taproot activation proposal. Different opinions were expressed regarding whether to use a Lot=false compromise or embrace brinkmanship tooling. Some argued that de-escalation in the strategy toolkit makes Bitcoin stronger, while others disagreed and emphasized the lack of agreement on a grand plan. Downsides of using LOT=true were mentioned, including dropping blocks from apathetic miners and the risk of a split. However, tracking economic majority is already possible based on previous experiences. The disagreement continued regarding the normalization of brinkmanship, with some members highlighting the need to optimize for a reliable Bitcoin and avoid strife.Claus Ehrenberg suggested that Taproot should be activated if either miners or users decide for it, with a chain split as the fairest way to resolve conflicts. Rusty Russell proposed the Speedy Trial approach, pretending that miners were not asked, and letting users ultimately decide. Preparation for a UASF branch along with ST was also discussed.The Bitcoin development community discussed the implementation of Taproot and parameter selection for an upcoming release. They targeted a May 1st release date and discussed the use of block heights or MTP for signaling periods. The team considered the advantages and disadvantages of each approach and adjusted the timing and other parameters based on preferences and technical considerations.Jeremy Rubin accused Michael Folkson of being disingenuous in his response and disagreed with his rejection of MTP-based ST. Folkson expressed his preference for consistent use of block heights and rejected the idea of using a mix of block heights and MTP in the same activation mechanism.Overall, the discussions revolve around finding the best approach to establish consensus for Bitcoin, activate Taproot, and handle potential challenges such as chain splits and miners failing to upgrade. The community aims to optimize the decision-making process, ensure payment validity, and strengthen the Bitcoin network.During a recent meeting on the activation mechanism for Taproot, there was a discussion about using block heights consistently or a mix of block heights and MTP. Michael Folkson preferred consistent use of block heights and disagreed with using a mix. The meeting also addressed the use of a speedy trial variant, which received no new objections. However, there was uncertainty about Rusty Russell's objection and whether it remains if sufficiently addressed.There was no consensus reached on selecting between block heights and MTP. Parameter selection discussions included targeting a May 1st release, specific start and stop times, and activation height proposals. It was agreed that November 15th should remain a target date, with limited belief that the release could be stretched into June if necessary.Simultaneous User Activated Soft Fork (UASF) was also discussed, with luke-jr suggesting that a UASF client must be able to release before the Taproot client. However, this sentiment was not shared by others, and it was agreed that a UASF can proceed independently of Taproot. Additionally, luke-jr objected to using MTP in combination with Taproot, while Jeremy Rubin objected to using block heights, citing concerns about avoiding contentious forks. 2021-04-08T11:11:06+00:00 + In recent discussions on the bitcoin-dev mailing list, the focus has been on establishing developer and user consensus for Bitcoin. One suggestion is to create a contingency plan for a chain split, which some argue is good preparation. However, others believe that this approach does not address the underlying issue of consensus. The ideal scenario would allow users to download any version of bitcoind and run it with default settings, confident in the validity of their payments. Third-party explorers can track invalid chains, but these measures are only useful after a split has occurred. The risk of a split is higher during an attack on Bitcoin. Suggestions like lockinontimeout have been made, but they are not seen as the ideal solution. Businesses accepting Bitcoin payments need to know what software to run to stay in consensus with the network. Streamlining the consensus-building process is crucial. One possible solution is to implement an approach dealing with miners who don't upgrade to enforce a soft-fork quickly.Another thread discussed the Signet-based Taproot activation proposal. Different opinions were expressed regarding whether to use a Lot=false compromise or embrace brinkmanship tooling. Some argued that de-escalation in the strategy toolkit makes Bitcoin stronger, while others disagreed and emphasized the lack of agreement on a grand plan. Downsides of using LOT=true were mentioned, including dropping blocks from apathetic miners and the risk of a split. However, tracking economic majority is already possible based on previous experiences. The disagreement continued regarding the normalization of brinkmanship, with some members highlighting the need to optimize for a reliable Bitcoin and avoid strife.Claus Ehrenberg suggested that Taproot should be activated if either miners or users decide for it, with a chain split as the fairest way to resolve conflicts. Rusty Russell proposed the Speedy Trial approach, pretending that miners were not asked, and letting users ultimately decide. Preparation for a UASF branch along with ST was also discussed.The Bitcoin development community discussed the implementation of Taproot and parameter selection for an upcoming release. They targeted a May 1st release date and discussed the use of block heights or MTP for signaling periods. The team considered the advantages and disadvantages of each approach and adjusted the timing and other parameters based on preferences and technical considerations.Jeremy Rubin accused Michael Folkson of being disingenuous in his response and disagreed with his rejection of MTP-based ST. Folkson expressed his preference for consistent use of block heights and rejected the idea of using a mix of block heights and MTP in the same activation mechanism.Overall, the discussions revolve around finding the best approach to establish consensus for Bitcoin, activate Taproot, and handle potential challenges such as chain splits and miners failing to upgrade. The community aims to optimize the decision-making process, ensure payment validity, and strengthen the Bitcoin network.During a recent meeting on the activation mechanism for Taproot, there was a discussion about using block heights consistently or a mix of block heights and MTP. Michael Folkson preferred consistent use of block heights and disagreed with using a mix. The meeting also addressed the use of a speedy trial variant, which received no new objections. However, there was uncertainty about Rusty Russell's objection and whether it remains if sufficiently addressed.There was no consensus reached on selecting between block heights and MTP. Parameter selection discussions included targeting a May 1st release, specific start and stop times, and activation height proposals. It was agreed that November 15th should remain a target date, with limited belief that the release could be stretched into June if necessary.Simultaneous User Activated Soft Fork (UASF) was also discussed, with luke-jr suggesting that a UASF client must be able to release before the Taproot client. However, this sentiment was not shared by others, and it was agreed that a UASF can proceed independently of Taproot. Additionally, luke-jr objected to using MTP in combination with Taproot, while Jeremy Rubin objected to using block heights, citing concerns about avoiding contentious forks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_New-PSBT-version-proposal.xml b/static/bitcoin-dev/March_2021/combined_New-PSBT-version-proposal.xml index eb4755dd2e..ad5abdbb67 100644 --- a/static/bitcoin-dev/March_2021/combined_New-PSBT-version-proposal.xml +++ b/static/bitcoin-dev/March_2021/combined_New-PSBT-version-proposal.xml @@ -1,59 +1,47 @@ - + 2 Combined summary - New PSBT version proposal - 2023-08-02T02:54:05.328979+00:00 - - Lloyd Fournier 2021-04-05 00:35:14+00:00 - - - Lloyd Fournier 2021-03-10 00:20:58+00:00 - - - Andrew Chow 2021-01-21 19:50:45+00:00 - - - Andrew Chow 2021-01-15 17:28:09+00:00 - - - Andrew Chow 2021-01-14 17:07:44+00:00 - - - Rusty Russell 2021-01-08 00:40:06+00:00 - - - Andrew Chow 2021-01-06 23:48:31+00:00 - - - Rusty Russell 2021-01-06 23:26:25+00:00 - - - Jeremy 2021-01-02 06:34:00+00:00 - - - Andrew Chow 2020-12-23 21:32:33+00:00 - - - Andrew Chow 2020-12-23 21:30:04+00:00 - - - Andrew Poelstra 2020-12-23 15:22:01+00:00 - - - fiatjaf 2020-12-23 03:30:20+00:00 - - - Andrew Chow 2020-12-22 20:12:22+00:00 - - - Andrew Poelstra 2020-12-16 17:44:11+00:00 - - - Sanket Kanjalkar 2020-12-10 11:28:23+00:00 - - - Andrew Chow 2020-12-09 22:25:37+00:00 - + 2025-09-26T16:05:33.813368+00:00 + python-feedgen + + + Jeremy + 2021-01-02T06:34:00.000Z + + + Rusty Russell + 2021-01-06T23:26:00.000Z + + + Andrew Chow + 2021-01-06T23:48:00.000Z + + + Rusty Russell + 2021-01-08T00:40:00.000Z + + + Andrew Chow + 2021-01-14T17:07:00.000Z + + + Andrew Chow + 2021-01-15T17:28:00.000Z + + + Andrew Chow + 2021-01-21T19:50:00.000Z + + + Lloyd Fournier + 2021-03-10T00:20:00.000Z + + + Lloyd Fournier + 2021-04-05T00:35:00.000Z + + @@ -71,13 +59,13 @@ - python-feedgen + 2 Combined summary - New PSBT version proposal - 2023-08-02T02:54:05.328979+00:00 + 2025-09-26T16:05:33.814609+00:00 - A proposal has been made to introduce a new version of Partially Signed Bitcoin Transactions (PSBTs) called PSBT v1. This new version addresses deficiencies in the current PSBT v0 and allows for inputs and outputs to be added to the transaction after its creation. The primary change is that all input and output data will be contained in their respective maps, eliminating the need to parse an unsigned transaction. Several new fields will be added to support this change, including PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, and PSBT_GLOBAL_UNDER_CONSTRUCTION.Andrew Chow has also proposed another version called PSBTv2, which is a backward-incompatible update to the PSBT protocol. It introduces fields like Transaction Version, Fallback Locktime, Input Count, Output Count, and Transaction Modifiable Flags. Additionally, the process of determining the nLockTime field of a transaction is explained in detail.Rusty Russell and Andrew Chow discuss the addition of a new global field called PSBT_GLOBAL_UNDER_CONSTRUCTION in an email exchange. This field is used to signal whether inputs and outputs can be added to the PSBT. Rusty suggests flagging this by omitting redundant fields, but Andrew explains that those fields are necessary to determine the number of input and output maps. They also discuss the possibility of signed inputs being added to transactions and the complexity of allowing modification of inputs and outputs after the Creator role is done.Overall, these proposed changes aim to improve the usability and functionality of the PSBT format, allowing for easier construction of transactions and the addition of inputs and outputs as needed.Andrew Chow has proposed a new version of Partially Signed Bitcoin Transactions (PSBT), called PSBT v1, to address the deficiencies in the current PSBT v0. The primary change in the new version is to have all input and output data for each contained within their respective maps, disallowing PSBT_GLOBAL_UNSIGNED_TX. Several new fields are added for Global, Input, and Output, including PSBT_GLOBAL_TX_VERSION, PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, PSBT_GLOBAL_OUTPUT_COUNT, PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE, PSBT_IN_REQUIRED_LOCKTIME, PSBT_OUT_VALUE, and PSBT_OUT_OUTPUT_SCRIPT.These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, care must be taken to ensure that adding additional inputs and outputs will not invalidate existing signatures. Finalizers must choose the maximum of all the *_LOCKTIME fields to choose the locktime for the transaction.PSBT v1 also introduces two lock time fields - one for a time-based lock time and the other for a height-based lock time. This is necessary because all inputs must use the same type of lock time (height or time). Additionally, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, is added to signal whether inputs and outputs can be added to the PSBT. Rules must be followed to ensure that adding new inputs and outputs does not invalidate existing signatures.To uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. Combiners can create an unsigned transaction given the transaction version, input prevouts, outputs, and computed locktime, which can then be used as a way to identify PSBTs.As the changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1 needs a version number bump to enforce backward incompatibility. However, once the inputs and outputs are decided, a PSBT can be downgraded back to v0 by creating an unsigned transaction from the fields mentioned above and dropping these new fields.Andrew Chow has proposed these changes in BIP 174 and is willing to write a pull request to modify it if the changes are deemed reasonable.A new version of Partially Signed Bitcoin Transaction (PSBT) has been proposed to address the deficiencies in the current PSBT v0. The main change in this proposal is to store all input and output data for each in their respective maps, eliminating the need to parse an unsigned transaction and perform a lookup for data. This change would disallow the use of the PSBT_GLOBAL_UNSIGNED_TX field in the new version.To implement these changes, several fields are suggested to be added to both the Global and Input/Output sections of PSBT. One notable addition is the PSBT_GLOBAL_PREFERRED_LOCKTIME, which specifies the locktime to use if no inputs require a specific locktime. Another important field is the PSBT_IN_REQUIRED_LOCKTIME, which is necessary for inputs involving OP_CHECKLOCKTIMEVERIFY. This field allows finalizers to choose a locktime that meets the minimum requirement without needing to understand the scripts involved.It is worth mentioning that a Bitcoin transaction only has a single locktime, while a PSBT may have multiple locktimes. Therefore, finalizers must select 2021-04-05T00:35:14+00:00 + A proposal has been made to introduce a new version of Partially Signed Bitcoin Transactions (PSBTs) called PSBT v1. This new version addresses deficiencies in the current PSBT v0 and allows for inputs and outputs to be added to the transaction after its creation. The primary change is that all input and output data will be contained in their respective maps, eliminating the need to parse an unsigned transaction. Several new fields will be added to support this change, including PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, and PSBT_GLOBAL_UNDER_CONSTRUCTION.Andrew Chow has also proposed another version called PSBTv2, which is a backward-incompatible update to the PSBT protocol. It introduces fields like Transaction Version, Fallback Locktime, Input Count, Output Count, and Transaction Modifiable Flags. Additionally, the process of determining the nLockTime field of a transaction is explained in detail.Rusty Russell and Andrew Chow discuss the addition of a new global field called PSBT_GLOBAL_UNDER_CONSTRUCTION in an email exchange. This field is used to signal whether inputs and outputs can be added to the PSBT. Rusty suggests flagging this by omitting redundant fields, but Andrew explains that those fields are necessary to determine the number of input and output maps. They also discuss the possibility of signed inputs being added to transactions and the complexity of allowing modification of inputs and outputs after the Creator role is done.Overall, these proposed changes aim to improve the usability and functionality of the PSBT format, allowing for easier construction of transactions and the addition of inputs and outputs as needed.Andrew Chow has proposed a new version of Partially Signed Bitcoin Transactions (PSBT), called PSBT v1, to address the deficiencies in the current PSBT v0. The primary change in the new version is to have all input and output data for each contained within their respective maps, disallowing PSBT_GLOBAL_UNSIGNED_TX. Several new fields are added for Global, Input, and Output, including PSBT_GLOBAL_TX_VERSION, PSBT_GLOBAL_PREFERRED_LOCKTIME, PSBT_GLOBAL_INPUT_COUNT, PSBT_GLOBAL_OUTPUT_COUNT, PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE, PSBT_IN_REQUIRED_LOCKTIME, PSBT_OUT_VALUE, and PSBT_OUT_OUTPUT_SCRIPT.These changes allow for PSBT to be used in the construction of transactions, with inputs and outputs being added as needed. However, care must be taken to ensure that adding additional inputs and outputs will not invalidate existing signatures. Finalizers must choose the maximum of all the *_LOCKTIME fields to choose the locktime for the transaction.PSBT v1 also introduces two lock time fields - one for a time-based lock time and the other for a height-based lock time. This is necessary because all inputs must use the same type of lock time (height or time). Additionally, a new global field, PSBT_GLOBAL_UNDER_CONSTRUCTION, is added to signal whether inputs and outputs can be added to the PSBT. Rules must be followed to ensure that adding new inputs and outputs does not invalidate existing signatures.To uniquely identify transactions for combiners, a txid can be computed from the information present in the PSBT. Combiners can create an unsigned transaction given the transaction version, input prevouts, outputs, and computed locktime, which can then be used as a way to identify PSBTs.As the changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1 needs a version number bump to enforce backward incompatibility. However, once the inputs and outputs are decided, a PSBT can be downgraded back to v0 by creating an unsigned transaction from the fields mentioned above and dropping these new fields.Andrew Chow has proposed these changes in BIP 174 and is willing to write a pull request to modify it if the changes are deemed reasonable.A new version of Partially Signed Bitcoin Transaction (PSBT) has been proposed to address the deficiencies in the current PSBT v0. The main change in this proposal is to store all input and output data for each in their respective maps, eliminating the need to parse an unsigned transaction and perform a lookup for data. This change would disallow the use of the PSBT_GLOBAL_UNSIGNED_TX field in the new version.To implement these changes, several fields are suggested to be added to both the Global and Input/Output sections of PSBT. One notable addition is the PSBT_GLOBAL_PREFERRED_LOCKTIME, which specifies the locktime to use if no inputs require a specific locktime. Another important field is the PSBT_IN_REQUIRED_LOCKTIME, which is necessary for inputs involving OP_CHECKLOCKTIMEVERIFY. This field allows finalizers to choose a locktime that meets the minimum requirement without needing to understand the scripts involved.It is worth mentioning that a Bitcoin transaction only has a single locktime, while a PSBT may have multiple locktimes. Therefore, finalizers must select - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml b/static/bitcoin-dev/March_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml index 886b6ea232..fd94aec4f4 100644 --- a/static/bitcoin-dev/March_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml +++ b/static/bitcoin-dev/March_2021/combined_PSA-Taproot-loss-of-quantum-protections.xml @@ -1,83 +1,127 @@ - + 2 Combined summary - PSA: Taproot loss of quantum protections - 2023-08-02T03:25:39.708542+00:00 - - Erik Aronesty 2021-08-12 22:08:40+00:00 - - - Lloyd Fournier 2021-04-16 05:00:07+00:00 - - - ZmnSCPxj 2021-04-16 03:47:45+00:00 - - - Lloyd Fournier 2021-04-05 00:27:50+00:00 - - - Tim Ruffing 2021-03-23 10:50:20+00:00 - - - Martin Schwarz 2021-03-23 09:36:32+00:00 - - - Erik Aronesty 2021-03-22 14:24:55+00:00 - - - Eoin McQuinn 2021-03-17 11:56:26+00:00 - - - Ryan Grant 2021-03-17 01:23:50+00:00 - - - Matt Corallo 2021-03-16 17:25:40+00:00 - - - Andrea 2021-03-16 14:10:21+00:00 - - - Andrew Poelstra 2021-03-16 13:28:34+00:00 - - - Luke Dashjr 2021-03-16 03:44:25+00:00 - - - ZmnSCPxj 2021-03-16 02:38:55+00:00 - - - Anthony Towns 2021-03-16 00:50:01+00:00 - - - David A. Harding 2021-03-16 00:24:01+00:00 - - - Lloyd Fournier 2021-03-15 23:46:05+00:00 - - - Matt Corallo 2021-03-15 23:19:22+00:00 - - - Andrew Poelstra 2021-03-15 23:12:18+00:00 - - - Karl-Johan Alm 2021-03-15 23:01:47+00:00 - - - Matt Corallo 2021-03-15 22:48:21+00:00 - - - Jeremy 2021-03-15 22:40:07+00:00 - - - Robert Spigler 2021-03-15 22:30:35+00:00 - - - Matt Corallo 2021-03-15 22:05:45+00:00 - - - Luke Dashjr 2021-03-15 21:48:15+00:00 - + 2025-09-26T16:05:40.141596+00:00 + python-feedgen + + + [bitcoin-dev] PSA: Taproot loss of quantum protections Luke Dashjr + 2021-03-15T21:48:00.000Z + + + Matt Corallo + 2021-03-15T22:05:00.000Z + + + Robert Spigler + 2021-03-15T22:30:00.000Z + + + Jeremy + 2021-03-15T22:40:00.000Z + + + Matt Corallo + 2021-03-15T22:48:00.000Z + + + Karl-Johan Alm + 2021-03-15T23:01:00.000Z + + + Andrew Poelstra + 2021-03-15T23:12:00.000Z + + + Matt Corallo + 2021-03-15T23:19:00.000Z + + + Lloyd Fournier + 2021-03-15T23:46:00.000Z + + + [bitcoin-dev] PSA: Taproot loss of quantum protections David A. Harding + 2021-03-16T00:24:00.000Z + + + Anthony Towns + 2021-03-16T00:50:00.000Z + + + ZmnSCPxj + 2021-03-16T02:38:00.000Z + + + Luke Dashjr + 2021-03-16T03:44:00.000Z + + + Andrew Poelstra + 2021-03-16T13:28:00.000Z + + + Andrea + 2021-03-16T14:10:00.000Z + + + [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections) Andrew Poelstra + 2021-03-16T15:15:00.000Z + + + Matt Corallo + 2021-03-16T17:25:00.000Z + + + Ryan Grant + 2021-03-17T01:23:00.000Z + + + ZmnSCPxj + 2021-03-17T04:24:00.000Z + + + Andrea + 2021-03-17T08:29:00.000Z + + + Eoin McQuinn + 2021-03-17T11:56:00.000Z + + + Andrea Barontini + 2021-03-20T16:31:00.000Z + + + Erik Aronesty + 2021-03-22T14:24:00.000Z + + + Martin Schwarz + 2021-03-23T09:36:00.000Z + + + Tim Ruffing + 2021-03-23T10:50:00.000Z + + + Lloyd Fournier + 2021-04-05T00:27:00.000Z + + + ZmnSCPxj + 2021-04-16T03:47:00.000Z + + + Lloyd Fournier + 2021-04-16T05:00:00.000Z + + + Erik Aronesty + 2021-08-12T22:08:00.000Z + + @@ -103,13 +147,13 @@ - python-feedgen + 2 Combined summary - PSA: Taproot loss of quantum protections - 2023-08-02T03:25:39.708542+00:00 + 2025-09-26T16:05:40.144564+00:00 - The safety of Taproot, a proposed upgrade to Bitcoin's software, has been a topic of discussion on the bitcoin-dev mailing list. Some individuals have expressed concerns about the vulnerability of Taproot to quantum computing attacks. They argue that Taproot lacks an important safety protection against quantum computers. However, others believe that there is no significant difference in terms of Bitcoin's vulnerability to quantum computing before and after Taproot.Address reuse has also been brought up as a factor in the debate. While hash-based addresses are recommended to reduce the risk of address reuse, many people still reuse Bitcoin invoice addresses. It has been pointed out that 37% of the supply is at risk of quantum attack due to this practice.Developer Mark Friedenbach is particularly concerned about Taproot's vulnerability to quantum computers. He suggests that without Taproot, the network could "pause" while a full quantum-safe solution is developed. However, with Taproot, it could become an unrecoverable situation if quantum computers come online before a solution is implemented. Friedenbach argues that Taproot does not provide any additional benefits, as the features it proposes can be implemented using hashed keys instead of raw keys. Despite these concerns, Friedenbach believes that Taproot should not be rejected and suggests adding a hash on top in an additional softfork to address the safety issue.In response to the argument that 37% of the supply being at risk is a security concern, Friedenbach suggests that social efforts discouraging address reuse can improve the situation. He also mentions that when neglected or abandoned/lost coins are compromised by quantum computers, it can be seen as equivalent to Bitcoin mining. Therefore, he argues that 37% of the supply minable by quantum computers is no different than 37% minable by ASICs.Despite the concerns raised, Taproot has entered the activation phase, and it is expected that the software will be released in the next month or two. Friedenbach recommends that anyone using Bitcoin read his article and other arguments on the topic to decide if this is a concern for them, and encourages them to make their own posts accordingly.Overall, the discussions revolve around the potential risks and mitigations related to quantum computing and Taproot in the Bitcoin ecosystem. The community is actively addressing these challenges and working towards ensuring the security and resilience of the network. 2021-08-12T22:08:40+00:00 + The safety of Taproot, a proposed upgrade to Bitcoin's software, has been a topic of discussion on the bitcoin-dev mailing list. Some individuals have expressed concerns about the vulnerability of Taproot to quantum computing attacks. They argue that Taproot lacks an important safety protection against quantum computers. However, others believe that there is no significant difference in terms of Bitcoin's vulnerability to quantum computing before and after Taproot.Address reuse has also been brought up as a factor in the debate. While hash-based addresses are recommended to reduce the risk of address reuse, many people still reuse Bitcoin invoice addresses. It has been pointed out that 37% of the supply is at risk of quantum attack due to this practice.Developer Mark Friedenbach is particularly concerned about Taproot's vulnerability to quantum computers. He suggests that without Taproot, the network could "pause" while a full quantum-safe solution is developed. However, with Taproot, it could become an unrecoverable situation if quantum computers come online before a solution is implemented. Friedenbach argues that Taproot does not provide any additional benefits, as the features it proposes can be implemented using hashed keys instead of raw keys. Despite these concerns, Friedenbach believes that Taproot should not be rejected and suggests adding a hash on top in an additional softfork to address the safety issue.In response to the argument that 37% of the supply being at risk is a security concern, Friedenbach suggests that social efforts discouraging address reuse can improve the situation. He also mentions that when neglected or abandoned/lost coins are compromised by quantum computers, it can be seen as equivalent to Bitcoin mining. Therefore, he argues that 37% of the supply minable by quantum computers is no different than 37% minable by ASICs.Despite the concerns raised, Taproot has entered the activation phase, and it is expected that the software will be released in the next month or two. Friedenbach recommends that anyone using Bitcoin read his article and other arguments on the topic to decide if this is a concern for them, and encourages them to make their own posts accordingly.Overall, the discussions revolve around the potential risks and mitigations related to quantum computing and Taproot in the Bitcoin ecosystem. The community is actively addressing these challenges and working towards ensuring the security and resilience of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Proposal-for-new-disabletx-p2p-message.xml b/static/bitcoin-dev/March_2021/combined_Proposal-for-new-disabletx-p2p-message.xml index 9c300254c7..0e1261af3e 100644 --- a/static/bitcoin-dev/March_2021/combined_Proposal-for-new-disabletx-p2p-message.xml +++ b/static/bitcoin-dev/March_2021/combined_Proposal-for-new-disabletx-p2p-message.xml @@ -1,41 +1,55 @@ - + 2 - Combined summary - Proposal for new "disabletx" p2p message - 2023-08-02T03:00:35.927900+00:00 - - Antoine Riard 2021-03-02 22:42:14+00:00 - - - Anthony Towns 2021-03-02 16:31:27+00:00 - - - John Newbery 2021-03-02 12:11:23+00:00 - - - Antoine Riard 2021-03-01 23:11:51+00:00 - - - John Newbery 2021-03-01 20:58:46+00:00 - - - Suhas Daftuar 2021-01-19 19:19:12+00:00 - - - Anthony Towns 2021-01-14 06:46:00+00:00 - - - Matt Corallo 2021-01-14 05:39:16+00:00 - - - Anthony Towns 2021-01-14 05:32:57+00:00 - - - Matt Corallo 2021-01-13 06:40:03+00:00 - - - Suhas Daftuar 2021-01-06 16:35:11+00:00 - + Combined summary - Proposal for new "disabletx" p2p message + 2025-09-26T16:05:38.026577+00:00 + python-feedgen + + + [bitcoin-dev] Proposal for new "disabletx" p2p message Suhas Daftuar + 2021-01-06T16:35:00.000Z + + + Matt Corallo + 2021-01-13T06:40:00.000Z + + + Anthony Towns + 2021-01-14T05:32:00.000Z + + + Matt Corallo + 2021-01-14T05:39:00.000Z + + + Anthony Towns + 2021-01-14T06:46:00.000Z + + + Suhas Daftuar + 2021-01-19T19:19:00.000Z + + + John Newbery + 2021-03-01T20:58:00.000Z + + + Antoine Riard + 2021-03-01T23:11:00.000Z + + + John Newbery + 2021-03-02T12:11:00.000Z + + + Anthony Towns + 2021-03-02T16:31:00.000Z + + + Antoine Riard + 2021-03-02T22:42:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 - Combined summary - Proposal for new "disabletx" p2p message - 2023-08-02T03:00:35.927900+00:00 + Combined summary - Proposal for new "disabletx" p2p message + 2025-09-26T16:05:38.027750+00:00 - In a Bitcoin development mailing list, there is a proposal to increase the number of block-relay-only connections and improve addr record propagation without making changes to the p2p protocol. The proposal suggests using the fRelay field in the version message to indicate no transaction relay. However, there are concerns about this approach, and it is recommended to have a well-defined standard with a clean negotiation mechanism.To prevent addr black holes, it is suggested that Bitcoin Core should only relay addr records to an inbound peer if it has previously received an addr or addrv2 message from that peer. This approach will improve addr propagation immediately and prevent sending addr records to all addr black holes.A new p2p message called "disabletx" is proposed to allow peers to communicate that they do not want to send or receive loose transactions for the lifetime of a connection. This message aims to create low-resource connections that protect against partition attacks on the network. Nodes implementing this BIP must set the protocol version to 70017 or higher.The proposed changes aim to increase the number of inbound block-relay-only peers while minimizing resource requirements and improving addr record propagation. This would be achieved by initializing transaction relay data structures after the version message is received and only if certain conditions are met. Additionally, a new p2p message, "disabletx," would be added to facilitate connections over which only block-related data are relayed.However, there are disagreements regarding the use of fRelay and the need for a clear negotiation mechanism. Some argue that reusing fRelay for a different purpose is not ideal and suggest having a well-defined standard instead. They also propose explicitly negotiating addr relay for more flexibility.Overall, the proposed changes aim to enhance the efficiency and security of peer connections in the Bitcoin network, specifically focusing on block propagation and addr record propagation. These changes would help protect against network attacks and improve the overall performance of the network. Bitcoin Core has already implemented some of these functionalities in previous versions, demonstrating the feasibility and potential benefits of these proposals.In a recent email thread, Bitcoin developer Suhas Daftuar has proposed the addition of a new optional peer-to-peer (p2p) message called "disabletx" to the Bitcoin protocol. This message would allow peers to communicate that they do not want to send or receive loose transactions during their connection. The purpose of this message is to facilitate low-resource connections on the network, where only block-related data are relayed, in order to strengthen network security against partition attacks.Currently, software has been deployed that initiates connections on the Bitcoin network and sets the transaction relay field to false, preventing transaction relay from occurring on the connection. These connections serve two purposes: enhancing the robustness of a node to network partitioning attacks and reducing an adversary's ability to learn the complete network graph. However, there is a need for a more standardized approach to indicate that loose transactions will not be sent or received for the entire lifetime of a connection.The proposal suggests adding the "disabletx" message as a new p2p message to address this need. It also recommends using the existing "fRelay" field in the version message to indicate that no transaction relay can happen for the entire lifetime of the connection. By postponing resource allocation for transaction relay data structures until after the version message has been received, the proposal aims to minimize resource usage for incoming block-relay-only connections.Additionally, the proposal suggests updating the inbound eviction logic to protect more inbound peers that do not have transaction relay data structures. It recommends initializing address data structures for inbound connections only when specific messages related to addresses are received on the connection. Furthermore, it proposes modestly increasing the number of outbound block-relay-only connections.The Bitcoin Improvement Proposal (BIP) 324 also suggests disabling address relay between peers to prevent network analysis attacks. While the proposal does not require software to relay addresses, it allows for future protocol extensions that might specify how address relay should be negotiated.The proposed changes aim to strengthen network security against partition attacks and network analysis attacks while minimizing resource usage for incoming block-relay-only connections. The full details of the proposals, including compatibility information, can be found in the respective BIPs. 2021-03-02T22:42:14+00:00 + In a Bitcoin development mailing list, there is a proposal to increase the number of block-relay-only connections and improve addr record propagation without making changes to the p2p protocol. The proposal suggests using the fRelay field in the version message to indicate no transaction relay. However, there are concerns about this approach, and it is recommended to have a well-defined standard with a clean negotiation mechanism.To prevent addr black holes, it is suggested that Bitcoin Core should only relay addr records to an inbound peer if it has previously received an addr or addrv2 message from that peer. This approach will improve addr propagation immediately and prevent sending addr records to all addr black holes.A new p2p message called "disabletx" is proposed to allow peers to communicate that they do not want to send or receive loose transactions for the lifetime of a connection. This message aims to create low-resource connections that protect against partition attacks on the network. Nodes implementing this BIP must set the protocol version to 70017 or higher.The proposed changes aim to increase the number of inbound block-relay-only peers while minimizing resource requirements and improving addr record propagation. This would be achieved by initializing transaction relay data structures after the version message is received and only if certain conditions are met. Additionally, a new p2p message, "disabletx," would be added to facilitate connections over which only block-related data are relayed.However, there are disagreements regarding the use of fRelay and the need for a clear negotiation mechanism. Some argue that reusing fRelay for a different purpose is not ideal and suggest having a well-defined standard instead. They also propose explicitly negotiating addr relay for more flexibility.Overall, the proposed changes aim to enhance the efficiency and security of peer connections in the Bitcoin network, specifically focusing on block propagation and addr record propagation. These changes would help protect against network attacks and improve the overall performance of the network. Bitcoin Core has already implemented some of these functionalities in previous versions, demonstrating the feasibility and potential benefits of these proposals.In a recent email thread, Bitcoin developer Suhas Daftuar has proposed the addition of a new optional peer-to-peer (p2p) message called "disabletx" to the Bitcoin protocol. This message would allow peers to communicate that they do not want to send or receive loose transactions during their connection. The purpose of this message is to facilitate low-resource connections on the network, where only block-related data are relayed, in order to strengthen network security against partition attacks.Currently, software has been deployed that initiates connections on the Bitcoin network and sets the transaction relay field to false, preventing transaction relay from occurring on the connection. These connections serve two purposes: enhancing the robustness of a node to network partitioning attacks and reducing an adversary's ability to learn the complete network graph. However, there is a need for a more standardized approach to indicate that loose transactions will not be sent or received for the entire lifetime of a connection.The proposal suggests adding the "disabletx" message as a new p2p message to address this need. It also recommends using the existing "fRelay" field in the version message to indicate that no transaction relay can happen for the entire lifetime of the connection. By postponing resource allocation for transaction relay data structures until after the version message has been received, the proposal aims to minimize resource usage for incoming block-relay-only connections.Additionally, the proposal suggests updating the inbound eviction logic to protect more inbound peers that do not have transaction relay data structures. It recommends initializing address data structures for inbound connections only when specific messages related to addresses are received on the connection. Furthermore, it proposes modestly increasing the number of outbound block-relay-only connections.The Bitcoin Improvement Proposal (BIP) 324 also suggests disabling address relay between peers to prevent network analysis attacks. While the proposal does not require software to relay addresses, it allows for future protocol extensions that might specify how address relay should be negotiated.The proposed changes aim to strengthen network security against partition attacks and network analysis attacks while minimizing resource usage for incoming block-relay-only connections. The full details of the proposals, including compatibility information, can be found in the respective BIPs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Provisions-was-PSA-Taproot-loss-of-quantum-protections-.xml b/static/bitcoin-dev/March_2021/combined_Provisions-was-PSA-Taproot-loss-of-quantum-protections-.xml index 9fc54c9c4b..5b0ecfc6e3 100644 --- a/static/bitcoin-dev/March_2021/combined_Provisions-was-PSA-Taproot-loss-of-quantum-protections-.xml +++ b/static/bitcoin-dev/March_2021/combined_Provisions-was-PSA-Taproot-loss-of-quantum-protections-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Provisions (was: PSA: Taproot loss of quantum protections) - 2023-08-02T03:27:54.364938+00:00 + 2025-09-26T16:05:56.890528+00:00 + python-feedgen Andrea Barontini 2021-03-20 16:31:19+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Provisions (was: PSA: Taproot loss of quantum protections) - 2023-08-02T03:27:54.364938+00:00 + 2025-09-26T16:05:56.890659+00:00 - In a conversation between Andrew, ZmnSCPxj, and Jonas, they discuss the use of Taproot in zero-knowledge proofs. The sender of the message has reviewed the resources provided and is unsure if Jonas' code qualifies as a use of Taproot for anonymity sets. However, they express their enjoyment in discovering new things and being part of the community.ZmnSCPxj responds to Andrew and Andrea's inquiry about Taproot ring signatures by providing links to the Bitcoin Wiki page on Taproot uses and a GitHub repository authored by Jonas on Taproot ring signatures. Although they admit to not having read the GitHub page themselves, the inclusion of these resources may be helpful for further research or understanding of Taproot and its applications.In a Bitcoin-dev mailing list, Andrea asks for references to ring signatures over/for/via Taproot and clarification on what "Provisions" means. Andrew Poelstra replies, explaining that Provisions is a scheme for proving ownership of funds by associating Bitcoin outputs with a Pedersen commitment. This allows for a zero-knowledge proof of owning a certain amount of BTC without revealing specific UTXOs. Currently, only a small anonymity set can use Provisions due to the lack of known public keys for most unspent Bitcoin outputs. However, Taproot outputs, which have exposed public keys, will be an exception, allowing for larger anonymity sets. Andrew also shares a link to simpler things that can be done with Taproot keys along these lines.Overall, this conversation provides insights into the use of Taproot in zero-knowledge proofs, the concept of Provisions for proof of ownership, and the resources available for further reading on the topic. 2021-03-20T16:31:19+00:00 + In a conversation between Andrew, ZmnSCPxj, and Jonas, they discuss the use of Taproot in zero-knowledge proofs. The sender of the message has reviewed the resources provided and is unsure if Jonas' code qualifies as a use of Taproot for anonymity sets. However, they express their enjoyment in discovering new things and being part of the community.ZmnSCPxj responds to Andrew and Andrea's inquiry about Taproot ring signatures by providing links to the Bitcoin Wiki page on Taproot uses and a GitHub repository authored by Jonas on Taproot ring signatures. Although they admit to not having read the GitHub page themselves, the inclusion of these resources may be helpful for further research or understanding of Taproot and its applications.In a Bitcoin-dev mailing list, Andrea asks for references to ring signatures over/for/via Taproot and clarification on what "Provisions" means. Andrew Poelstra replies, explaining that Provisions is a scheme for proving ownership of funds by associating Bitcoin outputs with a Pedersen commitment. This allows for a zero-knowledge proof of owning a certain amount of BTC without revealing specific UTXOs. Currently, only a small anonymity set can use Provisions due to the lack of known public keys for most unspent Bitcoin outputs. However, Taproot outputs, which have exposed public keys, will be an exception, allowing for larger anonymity sets. Andrew also shares a link to simpler things that can be done with Taproot keys along these lines.Overall, this conversation provides insights into the use of Taproot in zero-knowledge proofs, the concept of Provisions for proof of ownership, and the resources available for further reading on the topic. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Response-to-Rusty-Russell-from-Github.xml b/static/bitcoin-dev/March_2021/combined_Response-to-Rusty-Russell-from-Github.xml index 3d5b06d02a..437b5d50bf 100644 --- a/static/bitcoin-dev/March_2021/combined_Response-to-Rusty-Russell-from-Github.xml +++ b/static/bitcoin-dev/March_2021/combined_Response-to-Rusty-Russell-from-Github.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Response to Rusty Russell from Github - 2023-08-02T03:31:06.862084+00:00 - - Matt Corallo 2021-04-07 00:46:16+00:00 - - - Rusty Russell 2021-04-06 04:40:55+00:00 - - - Jeremy 2021-03-25 17:35:25+00:00 - + 2025-09-26T16:05:54.775807+00:00 + python-feedgen + + + [bitcoin-dev] Response to Rusty Russell from Github Jeremy + 2021-03-25T17:35:00.000Z + + + Rusty Russell + 2021-04-06T04:40:00.000Z + + + Matt Corallo + 2021-04-07T00:46:00.000Z + + - python-feedgen + 2 Combined summary - Response to Rusty Russell from Github - 2023-08-02T03:31:06.862084+00:00 + 2025-09-26T16:05:54.776355+00:00 - Developer Rusty Russell recently expressed his disagreement with using BIP8 with LOT configuration as a long-term solution for Bitcoin's future. In a post on bitcoin-dev, he argued that a regular flag day without signaling but openly communicated may be a better alternative. He emphasized the importance of considering infrastructure and drew parallels to the need for elections in government. Russell also outlined four reasons why a fresh release, rather than individually setting LOT configuration, could be simpler and safer. These reasons include avoiding consensus sensitivity issues, eliminating the risk of missed windows, enabling a faster soft-fail process, and preventing block invalidation if miners continue without signaling.While acknowledging that this approach isn't perfect, Russell didn't propose any immediate solutions to make it easier. He also discussed the technical aspects of BIP-8 and its effectiveness in preventing forks. With hopes of maintaining a harmonious ecosystem, he suggested that having BIP-8 deployed and ready could provide a safety net if necessary.The discussion primarily centered around the activation logic for Taproot. While Speedy Trial (ST) is not the final decision on activation logic, BIP8 with LOT configuration doesn't formalize how economic nodes send a network-legible signal before a chain split. Russell proposed a three-step process where developers release but do not activate, miners signal, and users have the option to override by compiling and releasing a patched Bitcoin with moderate changes to activate Taproot at a later date. He argued that this process is simpler and safer than using a configurable LOT.Furthermore, there was a discussion about the limitations of tying improvements together and the belief that each improvement should stand or fall on its own merits. Additionally, serious objections were raised regarding BIP8 in various deployment modes, including the risk of unnecessary chain splits, potential downtime for those running lot=true, and the possibility of reorganizations and wipeouts for those running lot=false. The author stressed the need for significant improvements in these areas.Lastly, the author suggested that once Taproot is resolved, there are other opportunities to enhance activation methodologies, such as consensus cleanup, anyprevout, ctv, graftroot, annex-based block commitments, and op_cat/covenants. 2021-04-07T00:46:16+00:00 + Developer Rusty Russell recently expressed his disagreement with using BIP8 with LOT configuration as a long-term solution for Bitcoin's future. In a post on bitcoin-dev, he argued that a regular flag day without signaling but openly communicated may be a better alternative. He emphasized the importance of considering infrastructure and drew parallels to the need for elections in government. Russell also outlined four reasons why a fresh release, rather than individually setting LOT configuration, could be simpler and safer. These reasons include avoiding consensus sensitivity issues, eliminating the risk of missed windows, enabling a faster soft-fail process, and preventing block invalidation if miners continue without signaling.While acknowledging that this approach isn't perfect, Russell didn't propose any immediate solutions to make it easier. He also discussed the technical aspects of BIP-8 and its effectiveness in preventing forks. With hopes of maintaining a harmonious ecosystem, he suggested that having BIP-8 deployed and ready could provide a safety net if necessary.The discussion primarily centered around the activation logic for Taproot. While Speedy Trial (ST) is not the final decision on activation logic, BIP8 with LOT configuration doesn't formalize how economic nodes send a network-legible signal before a chain split. Russell proposed a three-step process where developers release but do not activate, miners signal, and users have the option to override by compiling and releasing a patched Bitcoin with moderate changes to activate Taproot at a later date. He argued that this process is simpler and safer than using a configurable LOT.Furthermore, there was a discussion about the limitations of tying improvements together and the belief that each improvement should stand or fall on its own merits. Additionally, serious objections were raised regarding BIP8 in various deployment modes, including the risk of unnecessary chain splits, potential downtime for those running lot=true, and the possibility of reorganizations and wipeouts for those running lot=false. The author stressed the need for significant improvements in these areas.Lastly, the author suggested that once Taproot is resolved, there are other opportunities to enhance activation methodologies, such as consensus cleanup, anyprevout, ctv, graftroot, annex-based block commitments, and op_cat/covenants. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Signature-and-Script-Independent-Hierarchy-for-Deterministic-Wallets-.xml b/static/bitcoin-dev/March_2021/combined_Signature-and-Script-Independent-Hierarchy-for-Deterministic-Wallets-.xml index 970e4168d5..ffc74f548e 100644 --- a/static/bitcoin-dev/March_2021/combined_Signature-and-Script-Independent-Hierarchy-for-Deterministic-Wallets-.xml +++ b/static/bitcoin-dev/March_2021/combined_Signature-and-Script-Independent-Hierarchy-for-Deterministic-Wallets-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Signature and Script Independent Hierarchy for Deterministic Wallets. - 2023-08-02T03:24:12.012249+00:00 + 2025-09-26T16:05:25.412035+00:00 + python-feedgen Robert Spigler 2021-03-19 08:59:05+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Signature and Script Independent Hierarchy for Deterministic Wallets. - 2023-08-02T03:24:12.012249+00:00 + 2025-09-26T16:05:25.412236+00:00 - Developer Robert Spigler has proposed a Bitcoin Improvement Proposal (BIP) for multisignature and single signature wallets. However, concerns have been raised about the impact of the proposal on single signature wallets by ghost43 and Jochen Hoenicke. As a result, Spigler has decided to revert the proposal back to multisignature derivations, which he believes will address all concerns. The updated proposal can be found on Github, along with Spigler's personal fingerprint.In a discussion on the bitcoin-dev mailing list, Robert Spigler argued that wallets shouldn't have to check all script types on recovery and proposed a new standard called "Signature and Script Independent Hierarchy for Deterministic Wallets." According to Robert, descriptor wallets can solve this problem. For multisignature wallets, each cosigner stores their extended private key (xprv) and the wallet descriptor for backup. To recover, simply combine M private keys and check the script designated in 1 of the descriptor copies. For single signature wallets, it is the same, except only one signature is needed. Jochen disagreed with Robert's proposal and pointed out that currently, BIP39/BIP44 wallets can recover all accounts using just the seed words without the need for public keys or derivation paths. Additionally, Jochen stated that most hardware wallets currently rely on this feature. However, autodiscover doesn't work for multisig wallets, unless some output descriptor is stored in an OP_RETURN on the blockchain.The proposal to encode script type in the derivation is being questioned as output descriptors are becoming more prevalent. Two options have been suggested: 1) Use derivation paths that do not encode the script type and educate users to backup output descriptors in addition to their seed words or 2) Use a standard set of derivation paths that encode the script type, ensuring fund recovery even if users do not back it up by checking against common derivations. Robert Spigler suggests using descriptor wallets for multisignature and single signature wallets. To backup a multisignature wallet, each cosigner stores their extended private key and the wallet descriptor. For single signature wallets, the same applies but only one signature is needed.The current standards for deterministic wallets have many issues, including the mixing of keys and scripts in the same layer. BIP44/49/84 specifies a path that includes per-script derivations, but these are made redundant with descriptors. The proposal is to create extended private/public keys independent of the script or signature type. In multisignature wallets, each cosigner stores their xprv and the wallet descriptor for backup. For single signature wallets, only one signature is needed. There is a tradeoff as the proposal mixes discoverable and non-discoverable scripts in the same derivation scheme, which could turn all scripts into being non-discoverable. The workaround is to backup both seed words and output script descriptors, which is less user-friendly than backing up just a seed but more generic and extendable.Robert Spigler is working on a draft BIP for a signature and script independent hierarchy for deterministic wallets. He believes that with the implementation of descriptor wallets, the typical use case of a BIP43 `purpose’` level per script type is redundant. The differentiation of separate BIPs for multisignature derivation paths is also considered redundant. Descriptors can set the order of the public keys with multi or have them sorted lexicographically with sortedmulti. Robert proposes that keys and scripts should not be mixed in the same layer. The wallet should create extended private/public keys independent of the script or signature type, whereas the descriptor language tells wallets to watch (single or multi-sig) outputs with the specified public keys. 2021-03-19T08:59:05+00:00 + Developer Robert Spigler has proposed a Bitcoin Improvement Proposal (BIP) for multisignature and single signature wallets. However, concerns have been raised about the impact of the proposal on single signature wallets by ghost43 and Jochen Hoenicke. As a result, Spigler has decided to revert the proposal back to multisignature derivations, which he believes will address all concerns. The updated proposal can be found on Github, along with Spigler's personal fingerprint.In a discussion on the bitcoin-dev mailing list, Robert Spigler argued that wallets shouldn't have to check all script types on recovery and proposed a new standard called "Signature and Script Independent Hierarchy for Deterministic Wallets." According to Robert, descriptor wallets can solve this problem. For multisignature wallets, each cosigner stores their extended private key (xprv) and the wallet descriptor for backup. To recover, simply combine M private keys and check the script designated in 1 of the descriptor copies. For single signature wallets, it is the same, except only one signature is needed. Jochen disagreed with Robert's proposal and pointed out that currently, BIP39/BIP44 wallets can recover all accounts using just the seed words without the need for public keys or derivation paths. Additionally, Jochen stated that most hardware wallets currently rely on this feature. However, autodiscover doesn't work for multisig wallets, unless some output descriptor is stored in an OP_RETURN on the blockchain.The proposal to encode script type in the derivation is being questioned as output descriptors are becoming more prevalent. Two options have been suggested: 1) Use derivation paths that do not encode the script type and educate users to backup output descriptors in addition to their seed words or 2) Use a standard set of derivation paths that encode the script type, ensuring fund recovery even if users do not back it up by checking against common derivations. Robert Spigler suggests using descriptor wallets for multisignature and single signature wallets. To backup a multisignature wallet, each cosigner stores their extended private key and the wallet descriptor. For single signature wallets, the same applies but only one signature is needed.The current standards for deterministic wallets have many issues, including the mixing of keys and scripts in the same layer. BIP44/49/84 specifies a path that includes per-script derivations, but these are made redundant with descriptors. The proposal is to create extended private/public keys independent of the script or signature type. In multisignature wallets, each cosigner stores their xprv and the wallet descriptor for backup. For single signature wallets, only one signature is needed. There is a tradeoff as the proposal mixes discoverable and non-discoverable scripts in the same derivation scheme, which could turn all scripts into being non-discoverable. The workaround is to backup both seed words and output script descriptors, which is less user-friendly than backing up just a seed but more generic and extendable.Robert Spigler is working on a draft BIP for a signature and script independent hierarchy for deterministic wallets. He believes that with the implementation of descriptor wallets, the typical use case of a BIP43 `purpose’` level per script type is redundant. The differentiation of separate BIPs for multisignature derivation paths is also considered redundant. Descriptors can set the order of the public keys with multi or have them sorted lexicographically with sortedmulti. Robert proposes that keys and scripts should not be mixed in the same layer. The wallet should create extended private/public keys independent of the script or signature type, whereas the descriptor language tells wallets to watch (single or multi-sig) outputs with the specified public keys. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Straight-Flag-Day-Height-Taproot-Activation.xml b/static/bitcoin-dev/March_2021/combined_Straight-Flag-Day-Height-Taproot-Activation.xml index 3fe2dcd8d0..f0565053f0 100644 --- a/static/bitcoin-dev/March_2021/combined_Straight-Flag-Day-Height-Taproot-Activation.xml +++ b/static/bitcoin-dev/March_2021/combined_Straight-Flag-Day-Height-Taproot-Activation.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Straight Flag Day (Height) Taproot Activation - 2023-08-02T03:16:51.206553+00:00 - - eric at voskuil.org 2021-03-08 14:13:44+00:00 - - - Jorge Timón 2021-03-08 12:51:50+00:00 - - - Anthony Towns 2021-03-06 11:33:26+00:00 - - - Matt Corallo 2021-03-03 16:49:57+00:00 - - - Anthony Towns 2021-03-03 14:59:02+00:00 - - - Eric Voskuil 2021-02-28 20:38:13+00:00 - - - Matt Corallo 2021-02-28 20:25:15+00:00 - - - Matt Corallo 2021-02-28 20:20:56+00:00 - - - Eric Voskuil 2021-02-28 20:19:59+00:00 - - - Jeremy 2021-02-28 20:02:15+00:00 - - - Matt Corallo 2021-02-28 19:51:55+00:00 - - - Jeremy 2021-02-28 19:43:53+00:00 - - - Matt Corallo 2021-02-28 17:29:36+00:00 - - - Luke Dashjr 2021-02-28 17:20:05+00:00 - - - Matt Corallo 2021-02-28 16:45:22+00:00 - + 2025-09-26T16:05:14.845814+00:00 + python-feedgen + + + [bitcoin-dev] Straight Flag Day (Height) Taproot Activation Matt Corallo + 2021-02-28T16:45:00.000Z + + + Luke Dashjr + 2021-02-28T17:20:00.000Z + + + Matt Corallo + 2021-02-28T17:29:00.000Z + + + Jeremy + 2021-02-28T19:43:00.000Z + + + Matt Corallo + 2021-02-28T19:51:00.000Z + + + Jeremy + 2021-02-28T20:02:00.000Z + + + Eric Voskuil + 2021-02-28T20:19:00.000Z + + + Matt Corallo + 2021-02-28T20:20:00.000Z + + + Matt Corallo + 2021-02-28T20:25:00.000Z + + + Eric Voskuil + 2021-02-28T20:38:00.000Z + + + Anthony Towns + 2021-03-03T14:59:00.000Z + + + Matt Corallo + 2021-03-03T16:49:00.000Z + + + Anthony Towns + 2021-03-06T11:33:00.000Z + + + Jorge Timón + 2021-03-08T12:51:00.000Z + + + eric + 2021-03-08T14:13:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Straight Flag Day (Height) Taproot Activation - 2023-08-02T03:16:51.206553+00:00 + 2025-09-26T16:05:14.847638+00:00 - There is an ongoing debate among Bitcoin developers about the implementation of Taproot and how to activate it. One proposed solution is the "speedy trial" approach, which involves signaling before activation to establish community consensus. Another suggestion is to activate Taproot via a traditional flag day, allowing miners to signal uptake for taproot rules prior to activation. However, there are concerns about client compatibility and the potential for miners to generate invalid blocks. Discussions also revolve around the role of mandatory signaling versus a flag day and the need for careful planning and consideration when making changes to the Bitcoin network.The bitcoin-dev mailing list recently discussed the possibility of a mandatory signaling flag day for Taproot activation. Some members believe that a flag day would be simpler and easier to communicate than using activation parameters based on the percentage of upgraded nodes. However, there are concerns about network disruption and compatibility with early activation. The debate also touches on the BIP-8 protocol and whether early activation or a fixed activation date would be preferable.Despite these discussions, there is general agreement that a flag day might be the best option at this time. It is suggested that LOT=true could allow for compatibility with early activation if desired. Matt Corallo proposed a flag day activation for Taproot, but Luke Dashjr disagreed, emphasizing the importance of upgraded nodes across the network for successful activation. Dashjr also highlighted the risks of a LOT=False deployment and the complications it brings to the BIP 8 approach.Another proposal suggested activating Taproot through a traditional flag day with a set date in August 2022. However, Dashjr argued that this approach still has issues similar to BIP149, as it does not clearly indicate activation. He emphasized the need for high node-level adoption and warned against demanding alternative consensus rules or configuration flags.The ongoing debate and lack of consensus have likely delayed the release of Taproot activation. One suggestion to maintain consensus is to use a flag-day activation that meets certain criteria. The risk of hashpower loss can be mitigated by seeking commitment prior to release. Although a flag day activation has its own risks, it may be worth considering to avoid prolonged debate and delay.It is noted that Taproot activation has been in progress for a while, with no urgency until recently. Those seeking activation for market reasons should look forward to the event in 2022. Overall, the best course of action for Taproot activation is still under debate, considering factors such as network disruption, compatibility, and consensus among nodes. 2021-03-08T14:13:44+00:00 + There is an ongoing debate among Bitcoin developers about the implementation of Taproot and how to activate it. One proposed solution is the "speedy trial" approach, which involves signaling before activation to establish community consensus. Another suggestion is to activate Taproot via a traditional flag day, allowing miners to signal uptake for taproot rules prior to activation. However, there are concerns about client compatibility and the potential for miners to generate invalid blocks. Discussions also revolve around the role of mandatory signaling versus a flag day and the need for careful planning and consideration when making changes to the Bitcoin network.The bitcoin-dev mailing list recently discussed the possibility of a mandatory signaling flag day for Taproot activation. Some members believe that a flag day would be simpler and easier to communicate than using activation parameters based on the percentage of upgraded nodes. However, there are concerns about network disruption and compatibility with early activation. The debate also touches on the BIP-8 protocol and whether early activation or a fixed activation date would be preferable.Despite these discussions, there is general agreement that a flag day might be the best option at this time. It is suggested that LOT=true could allow for compatibility with early activation if desired. Matt Corallo proposed a flag day activation for Taproot, but Luke Dashjr disagreed, emphasizing the importance of upgraded nodes across the network for successful activation. Dashjr also highlighted the risks of a LOT=False deployment and the complications it brings to the BIP 8 approach.Another proposal suggested activating Taproot through a traditional flag day with a set date in August 2022. However, Dashjr argued that this approach still has issues similar to BIP149, as it does not clearly indicate activation. He emphasized the need for high node-level adoption and warned against demanding alternative consensus rules or configuration flags.The ongoing debate and lack of consensus have likely delayed the release of Taproot activation. One suggestion to maintain consensus is to use a flag-day activation that meets certain criteria. The risk of hashpower loss can be mitigated by seeking commitment prior to release. Although a flag day activation has its own risks, it may be worth considering to avoid prolonged debate and delay.It is noted that Taproot activation has been in progress for a while, with no urgency until recently. Those seeking activation for market reasons should look forward to the event in 2022. Overall, the best course of action for Taproot activation is still under debate, considering factors such as network disruption, compatibility, and consensus among nodes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Taproot-NACK.xml b/static/bitcoin-dev/March_2021/combined_Taproot-NACK.xml index 6224094319..0bb6fb0b0b 100644 --- a/static/bitcoin-dev/March_2021/combined_Taproot-NACK.xml +++ b/static/bitcoin-dev/March_2021/combined_Taproot-NACK.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Taproot NACK - 2023-08-02T03:14:03.702616+00:00 + 2025-09-26T16:05:21.174745+00:00 + python-feedgen DA Williamson 2021-03-18 01:10:38+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - Taproot NACK - 2023-08-02T03:14:03.702616+00:00 + 2025-09-26T16:05:21.174928+00:00 - The email thread on the bitcoin-dev mailing list revolves around discussions about privacy concerns related to Bitcoin transactions and the proposed Taproot protocol change. LORD HIS EXCELLENCY JAMES HRMH expresses concerns about increased privacy and potential obfuscation of transactions, which could lead to government bans. However, other members argue that Taproot does not increase privacy beyond current techniques like coinjoin, payjoin, and lightning. The importance of maintaining transparency in the blockchain while still allowing for privacy is emphasized.The conversation also touches on the affiliation of LORD HIS EXCELLENCY JAMES HRMH with a Bitcoin mixer service, raising questions about their motivations and potential conflicts of interest. The need for proper disclosure when discussing transaction privacy is highlighted.Another member named Damian A. James Williamson, associated with Willtech, shares contact information but does not provide specific advice or information about projects. The intention behind the email is unclear.The debate centers around striking a balance between privacy and security with transparency and accountability in Bitcoin transactions. Various perspectives are shared, including the value proposition of Bitcoin, the availability of privacy suitable for cash, and the implications of obfuscating transactions on government bans.Overall, the email thread covers topics such as consensus, censorship resistance, fraud prevention, privacy techniques, and the presence of a disruptive troll on the bitcoin-dev mailing list. It provides insights into various perspectives and approaches within the Bitcoin community. 2021-03-18T01:10:38+00:00 + The email thread on the bitcoin-dev mailing list revolves around discussions about privacy concerns related to Bitcoin transactions and the proposed Taproot protocol change. LORD HIS EXCELLENCY JAMES HRMH expresses concerns about increased privacy and potential obfuscation of transactions, which could lead to government bans. However, other members argue that Taproot does not increase privacy beyond current techniques like coinjoin, payjoin, and lightning. The importance of maintaining transparency in the blockchain while still allowing for privacy is emphasized.The conversation also touches on the affiliation of LORD HIS EXCELLENCY JAMES HRMH with a Bitcoin mixer service, raising questions about their motivations and potential conflicts of interest. The need for proper disclosure when discussing transaction privacy is highlighted.Another member named Damian A. James Williamson, associated with Willtech, shares contact information but does not provide specific advice or information about projects. The intention behind the email is unclear.The debate centers around striking a balance between privacy and security with transparency and accountability in Bitcoin transactions. Various perspectives are shared, including the value proposition of Bitcoin, the availability of privacy suitable for cash, and the implications of obfuscating transactions on government bans.Overall, the email thread covers topics such as consensus, censorship resistance, fraud prevention, privacy techniques, and the presence of a disruptive troll on the bitcoin-dev mailing list. It provides insights into various perspectives and approaches within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-16th-March-19-00-UTC.xml b/static/bitcoin-dev/March_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-16th-March-19-00-UTC.xml index 03d8e79bcb..d106ccba22 100644 --- a/static/bitcoin-dev/March_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-16th-March-19-00-UTC.xml +++ b/static/bitcoin-dev/March_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-16th-March-19-00-UTC.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC - 2023-08-02T03:24:44.359550+00:00 - - Prayank 2021-03-19 16:55:27+00:00 - - - Emil Pfeffer 2021-03-19 10:45:44+00:00 - - - Prayank 2021-03-17 08:21:39+00:00 - - - Emil Pfeffer 2021-03-16 17:42:33+00:00 - - - Luke Dashjr 2021-03-15 21:46:35+00:00 - - - Jeremy 2021-03-15 20:59:11+00:00 - - - Luke Dashjr 2021-03-15 19:37:37+00:00 - - - Jeremy 2021-03-15 19:14:02+00:00 - - - Luke Dashjr 2021-03-15 17:20:04+00:00 - + 2025-09-26T16:05:50.596384+00:00 + python-feedgen + + + [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC Luke Dashjr + 2021-03-15T17:20:00.000Z + + + Jeremy + 2021-03-15T19:14:00.000Z + + + Luke Dashjr + 2021-03-15T19:37:00.000Z + + + Jeremy + 2021-03-15T20:59:00.000Z + + + Luke Dashjr + 2021-03-15T21:46:00.000Z + + + Emil Pfeffer + 2021-03-16T17:42:00.000Z + + + Prayank + 2021-03-17T08:21:00.000Z + + + Emil Pfeffer + 2021-03-19T10:45:00.000Z + + + Prayank + 2021-03-19T16:55:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC - 2023-08-02T03:24:44.359550+00:00 + 2025-09-26T16:05:50.597511+00:00 - The conversation revolves around the block time interval of Bitcoin and the protocol for p2p decentralized network. The speaker agrees with the opinions of Greg Maxwell and Chris Belcher regarding the matter and has been sharing them on various platforms. They emphasize that Bitcoin is a protocol, and users are free to run whatever implementation they prefer. The speaker denies the assumption of the existence of any entity that gets to decide what goes on and exclude others from the decision-making process. Instead, they expect experienced individuals to lead the development of Bitcoin. The mention of "we're all Satoshi" refers to learning from the past and not discouraging discussions about soft forks that will improve Bitcoin. In an email exchange on March 17, 2021, Prayank discussed the rushed upgrade of Taproot. They debated whether or not it was a rushed approach, with one person arguing that it depended on the perception of time and past experience. They also discussed rules that can and cannot be changed in regards to upgrading Bitcoin Core and how much time is needed for users to make informed decisions. The conversation touched on various topics such as mass adoption, lightning network, and the freedom of users to decide which implementation to run. Finally, they agreed to involve as few people as possible to speed up the upgrade, while still welcoming everyone to participate and learn.The discussion revolves around the Taproot activation mechanism, and some users are concerned about the speed of the upgrade. However, others argue that it is not rushed and that there is still time for the UASF if required. The aim is to improve Bitcoin and not for quick gains. Lightning Network is a separate project focused on layer 2, which will benefit from Taproot. While "we" do not change things established in the past, MAST threshold can be lower to speed up the upgrade without representing an economic majority. Everyone should be welcome to participate in meetings, ask questions, learn more and contribute, but involving as few people as possible can help get the job done regarding the software and parameters of the new consensus.A meeting is scheduled for March 16th to discuss the proposed Speedy Trial activation plan for Taproot. There is disagreement among developers on whether this plan should be implemented, as it conflicts with the original timeline established for the upgrade. Some developers believe that changing established rules and rushing upgrades sets a bad precedent for Bitcoin development. Additionally, it is noted that progress has been slow on materializing the main activation plan, and more developers need to get involved if it is going to move forward. However, others argue that involving fewer people will make it easier to get the job done. The MAST threshold could be lowered to speed up the upgrade. If turnout for the meeting is low, it may be postponed to a later date.Luke Dashjr, a Bitcoin Core developer, has been discussing the timeline and recommendation from the meeting on February 16th regarding the activation proposal for Taproot. The first period overlaps with the last period of AChow's ST pull request. While a release today is impossible, waiting for a week without making any progress is not preferable either. It is hoped that there will be consensus to adapt around ST, shifting everything later. roconnor suggested enclosing ST's timeline, as it is the best solution. Jeremy Rubin wrote back asking Luke to expand on the timeline issue and which timelines are incompatible and why. He also mentioned that keeping the current timeline would require software supporting it to be released today. Jeremy suggested postponing the meeting by a week to prevent arbitrary “too low turnout” measures. Luke agreed to have a discussion tomorrow and a meeting next week to resolve issues in a more binding way. The previous meeting had consensus for BIP8 activation parameters except LOT, assuming a release around this time. Since then, a release has not occurred, and the new idea of Speedy Trial has been proposed to preempt the original/main activation plan. There haven't been enough people involved in materializing the main activation plan, and if it's going to move forward, more people need to get actively involved. This meeting is tentatively scheduled for March 16th at the usual time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel.On March 15th, a tentative meeting was announced in freenode's ##Taproot-activation IRC channel to discuss the proposed Speedy Trial activation plan and adjust the previous BIP8 activation parameters. The meeting was scheduled for the following day, March 16th, at 19:00 UTC. However, some participants expressed concerns over the short notice of less than 24 hours and suggested postponing the meeting by a week to allow more time for planning. Luke Dashjr, who initiated the meeting, argued that a delay would imply rejection of sticking to the original plan and suggested having a general discussion on March 16th instead. Dashjr stated that if someone wishes to insist on 2021-03-19T16:55:27+00:00 + The conversation revolves around the block time interval of Bitcoin and the protocol for p2p decentralized network. The speaker agrees with the opinions of Greg Maxwell and Chris Belcher regarding the matter and has been sharing them on various platforms. They emphasize that Bitcoin is a protocol, and users are free to run whatever implementation they prefer. The speaker denies the assumption of the existence of any entity that gets to decide what goes on and exclude others from the decision-making process. Instead, they expect experienced individuals to lead the development of Bitcoin. The mention of "we're all Satoshi" refers to learning from the past and not discouraging discussions about soft forks that will improve Bitcoin. In an email exchange on March 17, 2021, Prayank discussed the rushed upgrade of Taproot. They debated whether or not it was a rushed approach, with one person arguing that it depended on the perception of time and past experience. They also discussed rules that can and cannot be changed in regards to upgrading Bitcoin Core and how much time is needed for users to make informed decisions. The conversation touched on various topics such as mass adoption, lightning network, and the freedom of users to decide which implementation to run. Finally, they agreed to involve as few people as possible to speed up the upgrade, while still welcoming everyone to participate and learn.The discussion revolves around the Taproot activation mechanism, and some users are concerned about the speed of the upgrade. However, others argue that it is not rushed and that there is still time for the UASF if required. The aim is to improve Bitcoin and not for quick gains. Lightning Network is a separate project focused on layer 2, which will benefit from Taproot. While "we" do not change things established in the past, MAST threshold can be lower to speed up the upgrade without representing an economic majority. Everyone should be welcome to participate in meetings, ask questions, learn more and contribute, but involving as few people as possible can help get the job done regarding the software and parameters of the new consensus.A meeting is scheduled for March 16th to discuss the proposed Speedy Trial activation plan for Taproot. There is disagreement among developers on whether this plan should be implemented, as it conflicts with the original timeline established for the upgrade. Some developers believe that changing established rules and rushing upgrades sets a bad precedent for Bitcoin development. Additionally, it is noted that progress has been slow on materializing the main activation plan, and more developers need to get involved if it is going to move forward. However, others argue that involving fewer people will make it easier to get the job done. The MAST threshold could be lowered to speed up the upgrade. If turnout for the meeting is low, it may be postponed to a later date.Luke Dashjr, a Bitcoin Core developer, has been discussing the timeline and recommendation from the meeting on February 16th regarding the activation proposal for Taproot. The first period overlaps with the last period of AChow's ST pull request. While a release today is impossible, waiting for a week without making any progress is not preferable either. It is hoped that there will be consensus to adapt around ST, shifting everything later. roconnor suggested enclosing ST's timeline, as it is the best solution. Jeremy Rubin wrote back asking Luke to expand on the timeline issue and which timelines are incompatible and why. He also mentioned that keeping the current timeline would require software supporting it to be released today. Jeremy suggested postponing the meeting by a week to prevent arbitrary “too low turnout” measures. Luke agreed to have a discussion tomorrow and a meeting next week to resolve issues in a more binding way. The previous meeting had consensus for BIP8 activation parameters except LOT, assuming a release around this time. Since then, a release has not occurred, and the new idea of Speedy Trial has been proposed to preempt the original/main activation plan. There haven't been enough people involved in materializing the main activation plan, and if it's going to move forward, more people need to get actively involved. This meeting is tentatively scheduled for March 16th at the usual time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel.On March 15th, a tentative meeting was announced in freenode's ##Taproot-activation IRC channel to discuss the proposed Speedy Trial activation plan and adjust the previous BIP8 activation parameters. The meeting was scheduled for the following day, March 16th, at 19:00 UTC. However, some participants expressed concerns over the short notice of less than 24 hours and suggested postponing the meeting by a week to allow more time for planning. Luke Dashjr, who initiated the meeting, argued that a delay would imply rejection of sticking to the original plan and suggested having a general discussion on March 16th instead. Dashjr stated that if someone wishes to insist on - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Taproot-activation-proposal-Speedy-Trial-.xml b/static/bitcoin-dev/March_2021/combined_Taproot-activation-proposal-Speedy-Trial-.xml index 7902b8073b..7915cbb6d3 100644 --- a/static/bitcoin-dev/March_2021/combined_Taproot-activation-proposal-Speedy-Trial-.xml +++ b/static/bitcoin-dev/March_2021/combined_Taproot-activation-proposal-Speedy-Trial-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Taproot activation proposal "Speedy Trial" - 2023-08-02T03:23:09.242355+00:00 + Combined summary - Taproot activation proposal "Speedy Trial" + 2025-09-26T16:05:12.732289+00:00 + python-feedgen Michael Folkson 2021-03-15 14:06:45+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 - Combined summary - Taproot activation proposal "Speedy Trial" - 2023-08-02T03:23:09.242355+00:00 + Combined summary - Taproot activation proposal "Speedy Trial" + 2025-09-26T16:05:12.732519+00:00 - Bitcoin developers have proposed a new activation mechanism called Speedy Trial for the Taproot upgrade. This proposal aims to quickly succeed or fail without compromising safety. Miners would signal readiness for Taproot, and if the 90% threshold is not reached within three months, the activation attempt fails. The proposed timeline includes the release of full nodes with activation code, signal tracking, lock-in, and activation.Some are concerned about the three-month window potentially leading to network splits. David Harding has proposed an activation timeline for Taproot, suggesting specific dates for release, signal tracking, lock-in, and activation. His proposal can be implemented using either BIP9 or BIP8. The timeline includes a delay between lock-in and activation, and signaling begins in April. False signaling is possible with any proposal, but it is not required in Speedy Trial.Russell O'Connor has proposed Speedy Trial as a way to ensure widespread adoption of Taproot without compromising safety. The proposal includes an extended lock-in period and does not require mandatory signaling. However, concerns exist about false signaling and unprepared miners losing money. Implementation details are still being discussed, and a patch against BIP8 may be developed if Speedy Trial gains traction.The Taproot activation discussion has been ongoing for several years, with previous proposals and discussions dating back to 2015 and 2016. The latest proposal aims to generate fast progress and provide data for future activation proposals. Developers are working on updates to Bitcoin Core's code to support the proposed activation parameters.Overall, the Speedy Trial proposal offers a way to activate Taproot quickly and safely, with options for implementation using existing code or a proposed patchset. The proposal addresses concerns about network splits and false signaling while allowing for advanced notice and preparation by users and organizations. The goal is to find a solution that achieves widespread adoption of new consensus rules while maintaining the integrity of the Bitcoin network. 2021-03-15T14:06:45+00:00 + Bitcoin developers have proposed a new activation mechanism called Speedy Trial for the Taproot upgrade. This proposal aims to quickly succeed or fail without compromising safety. Miners would signal readiness for Taproot, and if the 90% threshold is not reached within three months, the activation attempt fails. The proposed timeline includes the release of full nodes with activation code, signal tracking, lock-in, and activation.Some are concerned about the three-month window potentially leading to network splits. David Harding has proposed an activation timeline for Taproot, suggesting specific dates for release, signal tracking, lock-in, and activation. His proposal can be implemented using either BIP9 or BIP8. The timeline includes a delay between lock-in and activation, and signaling begins in April. False signaling is possible with any proposal, but it is not required in Speedy Trial.Russell O'Connor has proposed Speedy Trial as a way to ensure widespread adoption of Taproot without compromising safety. The proposal includes an extended lock-in period and does not require mandatory signaling. However, concerns exist about false signaling and unprepared miners losing money. Implementation details are still being discussed, and a patch against BIP8 may be developed if Speedy Trial gains traction.The Taproot activation discussion has been ongoing for several years, with previous proposals and discussions dating back to 2015 and 2016. The latest proposal aims to generate fast progress and provide data for future activation proposals. Developers are working on updates to Bitcoin Core's code to support the proposed activation parameters.Overall, the Speedy Trial proposal offers a way to activate Taproot quickly and safely, with options for implementation using existing code or a proposed patchset. The proposal addresses concerns about network splits and false signaling while allowing for advanced notice and preparation by users and organizations. The goal is to find a solution that achieves widespread adoption of new consensus rules while maintaining the integrity of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_UASF-LOT-true-kick-off-meeting-Tuesday-March-2nd-19-00-UTC-on-uasf-IRC-channel.xml b/static/bitcoin-dev/March_2021/combined_UASF-LOT-true-kick-off-meeting-Tuesday-March-2nd-19-00-UTC-on-uasf-IRC-channel.xml index ee533c7565..9de65a1ec8 100644 --- a/static/bitcoin-dev/March_2021/combined_UASF-LOT-true-kick-off-meeting-Tuesday-March-2nd-19-00-UTC-on-uasf-IRC-channel.xml +++ b/static/bitcoin-dev/March_2021/combined_UASF-LOT-true-kick-off-meeting-Tuesday-March-2nd-19-00-UTC-on-uasf-IRC-channel.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel - 2023-08-02T03:19:35.331192+00:00 - - Eric Voskuil 2021-03-02 20:19:41+00:00 - - - Ariel Lorenzo-Luaces 2021-03-02 19:36:54+00:00 - - - Luke Dashjr 2021-03-02 18:57:38+00:00 - - - Ariel Lorenzo-Luaces 2021-03-02 18:22:35+00:00 - - - Michael Folkson 2021-03-01 17:47:57+00:00 - + 2025-09-26T16:06:01.071753+00:00 + python-feedgen + + + [bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel Michael Folkson + 2021-03-01T17:47:00.000Z + + + Ariel Lorenzo-Luaces + 2021-03-02T18:22:00.000Z + + + Luke Dashjr + 2021-03-02T18:57:00.000Z + + + Ariel Lorenzo-Luaces + 2021-03-02T19:36:00.000Z + + + Eric Voskuil + 2021-03-02T20:19:00.000Z + + - python-feedgen + 2 Combined summary - UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel - 2023-08-02T03:19:35.332194+00:00 + 2025-09-26T16:06:01.072479+00:00 - The term "51% attack" is commonly used to refer to a majority censor, but some argue that the term is better reserved for stealing from someone using hash power. The term helps people understand the mechanism of hash power soft fork enforcement. However, referring to miners enforcing rules without social support as a 51% attack confuses the actual behavior and implies that the mechanism is somehow different because of an ill-defined level of agreement.Ariel Lorenzo-Luaces suggested that LOT=false has a clear advantage in that it can happen without the need for a social movement, only requiring the convincing of 95% of miners. Apathetic users would not notice any disruption regardless of the success or failure of the activation. On the other hand, LOT=true requires being able to 51% the blockchain to win apathetic users, which could be disruptive if miners choose to create an invalid chain. However, Luke Dashjr argues that LOT=True does not necessarily result in this scenario and that miners could create an invalid chain at any time with or without a softfork involved.In a Bitcoin-dev conversation between Ariel Lorenzo-Luaces and Luke Dashjr, the former made a statement implying that LOT=false activation method is better than LOT=true. Dashjr corrected him by saying that miners enforcing rules without social support is not a soft fork but a 51% attack. Ariel responded by stating that he never said LOT=true does it; rather, it must achieve 51% miner support to pose reorg risks to force apathetic users into paying attention. Dashjr further explained that LOT=True doesn't cause such disruption unless miners choose to create an invalid chain, which they could do at any time with or without a softfork involved.A conversation on bitcoin-dev mailing list highlighted the advantages of a softfork with LOT=false activation method. It can be achieved without the need for social movement, but only requires convincing 95% of miners. The apathetic users will not notice any service disruption, regardless of the success or failure of the activation. This is why it became the default activation method. However, forcing rules without social support is considered a 51% attack, which is not a softfork. On the other hand, LOT=true requires 51% of the blockchain to win the apathetic users, which can lead to disruptive reorgs. However, this is not true as LOT=true does not create an invalid chain. Miners can create an invalid chain at any time, with or without a softfork involved.It has been eight months since the Taproot activation discussion began, and while progress has been made towards overwhelming consensus on the activation mechanism (BIP 8) and all parameters except lockinontimeout (LOT), there is still no philosopher's stone that will garner 100% consensus without any chain split risk. It is unclear whether Bitcoin Core will be able to release any activation code due to disagreement logjams. As a result, some are advocating for a community release implementing LOT=true in a similar spirit to the 2017 UASF effort, as approximately 90% of mining pools have declared support, and there is overwhelming community consensus to activate Taproot. However, others argue that a social movement would require tremendous work to convince users, miners, and service providers to run a UASF client.There is also the option of LOT=false, which does not require a social movement but only convincing 95% of miners. Apathetic users will never notice any service disruption regardless of the success or failure of the activation. The choice has always been about the order, with some thinking LOT=true should be attempted first and others thinking LOT=false should be attempted first. The author urges people to try LOT=false first, as a minor chain split one year later and a year of wasted time could result from a failed UASF movement. Social movements are hard to create, especially when the people you're trying to convince don't feel threatened. It would be a shame to meet back here a year later after verbal conflicts, misdirection, lies, vilification, reorgs, double spends, PoW changes, and threats galore.It has been eight months since Steve Lee initiated the Taproot activation discussion through the creation of IRC channel ##taproot-activation. Though there were discussions prior to this, it was the first step towards finding a solution. However, even after eight months, some people are still searching for a philosopher's stone that will garner 100 percent consensus with zero chain split risk. Michael Folkson suggests stepping away from circular debates and building on the progress made so far. Overwhelming consensus has been achieved on the activation mechanism (BIP 8) and all parameters except for one (lockinontimeout or LOT). The absence of a Core release with activation code might require energy being spent on a user-activated soft fork (UASF) release, implementing LOT=true, in a similar spirit to 2017's 2021-03-02T20:19:41+00:00 + The term "51% attack" is commonly used to refer to a majority censor, but some argue that the term is better reserved for stealing from someone using hash power. The term helps people understand the mechanism of hash power soft fork enforcement. However, referring to miners enforcing rules without social support as a 51% attack confuses the actual behavior and implies that the mechanism is somehow different because of an ill-defined level of agreement.Ariel Lorenzo-Luaces suggested that LOT=false has a clear advantage in that it can happen without the need for a social movement, only requiring the convincing of 95% of miners. Apathetic users would not notice any disruption regardless of the success or failure of the activation. On the other hand, LOT=true requires being able to 51% the blockchain to win apathetic users, which could be disruptive if miners choose to create an invalid chain. However, Luke Dashjr argues that LOT=True does not necessarily result in this scenario and that miners could create an invalid chain at any time with or without a softfork involved.In a Bitcoin-dev conversation between Ariel Lorenzo-Luaces and Luke Dashjr, the former made a statement implying that LOT=false activation method is better than LOT=true. Dashjr corrected him by saying that miners enforcing rules without social support is not a soft fork but a 51% attack. Ariel responded by stating that he never said LOT=true does it; rather, it must achieve 51% miner support to pose reorg risks to force apathetic users into paying attention. Dashjr further explained that LOT=True doesn't cause such disruption unless miners choose to create an invalid chain, which they could do at any time with or without a softfork involved.A conversation on bitcoin-dev mailing list highlighted the advantages of a softfork with LOT=false activation method. It can be achieved without the need for social movement, but only requires convincing 95% of miners. The apathetic users will not notice any service disruption, regardless of the success or failure of the activation. This is why it became the default activation method. However, forcing rules without social support is considered a 51% attack, which is not a softfork. On the other hand, LOT=true requires 51% of the blockchain to win the apathetic users, which can lead to disruptive reorgs. However, this is not true as LOT=true does not create an invalid chain. Miners can create an invalid chain at any time, with or without a softfork involved.It has been eight months since the Taproot activation discussion began, and while progress has been made towards overwhelming consensus on the activation mechanism (BIP 8) and all parameters except lockinontimeout (LOT), there is still no philosopher's stone that will garner 100% consensus without any chain split risk. It is unclear whether Bitcoin Core will be able to release any activation code due to disagreement logjams. As a result, some are advocating for a community release implementing LOT=true in a similar spirit to the 2017 UASF effort, as approximately 90% of mining pools have declared support, and there is overwhelming community consensus to activate Taproot. However, others argue that a social movement would require tremendous work to convince users, miners, and service providers to run a UASF client.There is also the option of LOT=false, which does not require a social movement but only convincing 95% of miners. Apathetic users will never notice any service disruption regardless of the success or failure of the activation. The choice has always been about the order, with some thinking LOT=true should be attempted first and others thinking LOT=false should be attempted first. The author urges people to try LOT=false first, as a minor chain split one year later and a year of wasted time could result from a failed UASF movement. Social movements are hard to create, especially when the people you're trying to convince don't feel threatened. It would be a shame to meet back here a year later after verbal conflicts, misdirection, lies, vilification, reorgs, double spends, PoW changes, and threats galore.It has been eight months since Steve Lee initiated the Taproot activation discussion through the creation of IRC channel ##taproot-activation. Though there were discussions prior to this, it was the first step towards finding a solution. However, even after eight months, some people are still searching for a philosopher's stone that will garner 100 percent consensus with zero chain split risk. Michael Folkson suggests stepping away from circular debates and building on the progress made so far. Overwhelming consensus has been achieved on the activation mechanism (BIP 8) and all parameters except for one (lockinontimeout or LOT). The absence of a Core release with activation code might require energy being spent on a user-activated soft fork (UASF) release, implementing LOT=true, in a similar spirit to 2017's - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml b/static/bitcoin-dev/March_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml index b8b18895ef..efadcae014 100644 --- a/static/bitcoin-dev/March_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml +++ b/static/bitcoin-dev/March_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Yesterday's Taproot activation meeting on lockinontimeout (LOT) - 2023-08-02T03:10:33.543115+00:00 + 2025-09-26T16:05:31.696131+00:00 + python-feedgen Ariel Lorenzo-Luaces 2021-03-02 18:32:00+00:00 @@ -171,13 +172,13 @@ - python-feedgen + 2 Combined summary - Yesterday's Taproot activation meeting on lockinontimeout (LOT) - 2023-08-02T03:10:33.543115+00:00 + 2025-09-26T16:05:31.696332+00:00 - The Bitcoin community is currently engaged in discussions about the activation of Taproot, a proposed soft-fork upgrade for the network. The activation method itself has raised concerns about the risk of chain splits and the potential impact on consensus. One suggestion to minimize this risk is to release a version of Bitcoin Core that requires users to choose between activating Taproot with LOT=true or LOT=false. However, there are debates about whether giving miners too much control over consensus could set a problematic precedent.Bitcoin Core developer Matt Corallo emphasized the long-standing policy of not including options that could harm users, explaining that the role of Bitcoin Core developers is to recommend technically sound and consensus-supported courses of action. While users are free to run their own software, he doesn't anticipate that the minority advocating for certain options on platforms like Twitter will have sufficient influence to sustain their choices if they find themselves on a chain with no blocks.The ongoing debate on the activation mechanism for Taproot includes discussions about whether to set the lock-in on timeout (LOT) parameter to true or false. Various viewpoints have been expressed, with some participants arguing for LOT=true and others suggesting LOT=false. Michael Folkson, who summarized the outcomes of a Taproot activation meeting, concluded that there was no overwhelming consensus but noted stronger opposition to LOT=true from Bitcoin Core contributors and Lightning developers. Based on this, he recommended proposing LOT=false as the activation parameter.However, the decision-making process is still ongoing, and code review of the Bitcoin Core PR #19573 is scheduled for February 23rd. While there are diverging opinions on the best course of action, the goal remains to activate Taproot as early as possible while minimizing risks and ensuring broad consensus within the Bitcoin community.It's worth noting that an activation mechanism is a consensus change that can be contentious. Therefore, it's important to engage in open discussions and prepare for different scenarios without being antagonistic or destructive. The Bitcoin community aims to find a resolution that aligns with the collective interest and avoids detrimental outcomes.The activation of Taproot has sparked debates within the Bitcoin community. Some members suggest setting LOT=false to minimize the risk, while others propose allowing users to make the choice themselves. There is disagreement on which option is safer, with arguments made for both LOT=true and LOT=false.During a recent meeting on Taproot activation, there was majority support for LOT=false over LOT=true. However, concerns were raised about the representativeness of the meeting, as only around 100 people attended. Despite this, it is recommended to propose LOT=false in order to finalize Taproot activation parameters and propose them to the community.It is emphasized that users are not forced to upgrade to any particular software version, and there is a possibility that only a small number of people will run LOT=true while others delay their upgrade. The goal is to avoid a chain split and falling out of consensus.The Bitcoin community acknowledges the importance of open discussions and preparation for worst-case scenarios in order to build secure systems. A code review of Bitcoin Core PR #19573 is scheduled, and participants are thanked for engaging productively and in good faith.Overall, the Bitcoin community is actively discussing the activation of Taproot and considering the potential risks and benefits. The debate centers around whether to set LOT to true or false, with arguments made for both options. The community aims to reach a consensus and activate Taproot in a way that minimizes risks and ensures the long-term growth and security of the ecosystem.The ongoing debate on the activation of Taproot continues, with different perspectives on the implementation and consensus rules. Software complexity and infrastructure limitations have been raised as challenges. The proposal for a LOT=true option in Bitcoin Core has faced opposition, leading to the recommendation of proposing LOT=false. Communication, agreement, and avoiding forced-signaling via forks are emphasized. Multiple forks and alternative implementations are suggested to enhance decentralization. The aim is to activate Taproot as early as possible while considering consensus and technical soundness.In the recent meeting on Taproot activation, arguments for both LOT=true and LOT=false were discussed. While there was no overwhelming consensus, there was more opposition against LOT=true among Bitcoin Core contributors, Lightning developers, and other community members. Some mining pools expressed a preference for LOT=false. It was decided to propose LOT=false at this time, considering the aim of activating the Taproot soft fork as early as possible.Matt Corallo emphasized the importance of communication and agreement in the activation process. He suggested that if there is broad consensus for Taproot but some miners fail to upgrade, a flag day activation could be considered instead of a UASF/BIP8-style fork, which carries additional risks. The tradeoffs of a BIP8(false, ∞) option were also discussed, with suggestions for maintaining multiple forks of Bitcoin Core to enhance decentralization.The practicality of implementing a LOT=false option in Bitcoin Core was questioned due to the software complexity involved. Bitcoin Core's long-standing policy is not to ship options that 2021-03-02T18:32:00+00:00 + The Bitcoin community is currently engaged in discussions about the activation of Taproot, a proposed soft-fork upgrade for the network. The activation method itself has raised concerns about the risk of chain splits and the potential impact on consensus. One suggestion to minimize this risk is to release a version of Bitcoin Core that requires users to choose between activating Taproot with LOT=true or LOT=false. However, there are debates about whether giving miners too much control over consensus could set a problematic precedent.Bitcoin Core developer Matt Corallo emphasized the long-standing policy of not including options that could harm users, explaining that the role of Bitcoin Core developers is to recommend technically sound and consensus-supported courses of action. While users are free to run their own software, he doesn't anticipate that the minority advocating for certain options on platforms like Twitter will have sufficient influence to sustain their choices if they find themselves on a chain with no blocks.The ongoing debate on the activation mechanism for Taproot includes discussions about whether to set the lock-in on timeout (LOT) parameter to true or false. Various viewpoints have been expressed, with some participants arguing for LOT=true and others suggesting LOT=false. Michael Folkson, who summarized the outcomes of a Taproot activation meeting, concluded that there was no overwhelming consensus but noted stronger opposition to LOT=true from Bitcoin Core contributors and Lightning developers. Based on this, he recommended proposing LOT=false as the activation parameter.However, the decision-making process is still ongoing, and code review of the Bitcoin Core PR #19573 is scheduled for February 23rd. While there are diverging opinions on the best course of action, the goal remains to activate Taproot as early as possible while minimizing risks and ensuring broad consensus within the Bitcoin community.It's worth noting that an activation mechanism is a consensus change that can be contentious. Therefore, it's important to engage in open discussions and prepare for different scenarios without being antagonistic or destructive. The Bitcoin community aims to find a resolution that aligns with the collective interest and avoids detrimental outcomes.The activation of Taproot has sparked debates within the Bitcoin community. Some members suggest setting LOT=false to minimize the risk, while others propose allowing users to make the choice themselves. There is disagreement on which option is safer, with arguments made for both LOT=true and LOT=false.During a recent meeting on Taproot activation, there was majority support for LOT=false over LOT=true. However, concerns were raised about the representativeness of the meeting, as only around 100 people attended. Despite this, it is recommended to propose LOT=false in order to finalize Taproot activation parameters and propose them to the community.It is emphasized that users are not forced to upgrade to any particular software version, and there is a possibility that only a small number of people will run LOT=true while others delay their upgrade. The goal is to avoid a chain split and falling out of consensus.The Bitcoin community acknowledges the importance of open discussions and preparation for worst-case scenarios in order to build secure systems. A code review of Bitcoin Core PR #19573 is scheduled, and participants are thanked for engaging productively and in good faith.Overall, the Bitcoin community is actively discussing the activation of Taproot and considering the potential risks and benefits. The debate centers around whether to set LOT to true or false, with arguments made for both options. The community aims to reach a consensus and activate Taproot in a way that minimizes risks and ensures the long-term growth and security of the ecosystem.The ongoing debate on the activation of Taproot continues, with different perspectives on the implementation and consensus rules. Software complexity and infrastructure limitations have been raised as challenges. The proposal for a LOT=true option in Bitcoin Core has faced opposition, leading to the recommendation of proposing LOT=false. Communication, agreement, and avoiding forced-signaling via forks are emphasized. Multiple forks and alternative implementations are suggested to enhance decentralization. The aim is to activate Taproot as early as possible while considering consensus and technical soundness.In the recent meeting on Taproot activation, arguments for both LOT=true and LOT=false were discussed. While there was no overwhelming consensus, there was more opposition against LOT=true among Bitcoin Core contributors, Lightning developers, and other community members. Some mining pools expressed a preference for LOT=false. It was decided to propose LOT=false at this time, considering the aim of activating the Taproot soft fork as early as possible.Matt Corallo emphasized the importance of communication and agreement in the activation process. He suggested that if there is broad consensus for Taproot but some miners fail to upgrade, a flag day activation could be considered instead of a UASF/BIP8-style fork, which carries additional risks. The tradeoffs of a BIP8(false, ∞) option were also discussed, with suggestions for maintaining multiple forks of Bitcoin Core to enhance decentralization.The practicality of implementing a LOT=false option in Bitcoin Core was questioned due to the software complexity involved. Bitcoin Core's long-standing policy is not to ship options that - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Yesterday-s-UASF-LOT-true-kick-off-meeting.xml b/static/bitcoin-dev/March_2021/combined_Yesterday-s-UASF-LOT-true-kick-off-meeting.xml index 6e17debc6d..3c49d7b30c 100644 --- a/static/bitcoin-dev/March_2021/combined_Yesterday-s-UASF-LOT-true-kick-off-meeting.xml +++ b/static/bitcoin-dev/March_2021/combined_Yesterday-s-UASF-LOT-true-kick-off-meeting.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Yesterday’s UASF (LOT=true) kick off meeting - 2023-08-02T03:19:58.502837+00:00 - - Michael Folkson 2021-03-04 10:54:19+00:00 - - - Ariel Luaces 2021-03-04 02:18:29+00:00 - - - Michael Folkson 2021-03-03 12:15:02+00:00 - + 2025-09-26T16:05:46.412153+00:00 + python-feedgen + + + [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting Michael Folkson + 2021-03-03T12:15:00.000Z + + + Ariel Luaces + 2021-03-04T02:18:00.000Z + + + Michael Folkson + 2021-03-04T10:54:00.000Z + + - python-feedgen + 2 Combined summary - Yesterday’s UASF (LOT=true) kick off meeting - 2023-08-02T03:19:58.502837+00:00 + 2025-09-26T16:05:46.412724+00:00 - Ariel Luaces and Michael Folkson have engaged in an email exchange discussing the activation of Taproot on Bitcoin. Michael expresses concern about a small group of conservative developers who are obstructing progress by ignoring the work done by others and delaying the activation until they find their desired solution. He argues that consensus on one parameter of the activation mechanism should not require as high a level of agreement as for the actual soft fork being activated.In contrast, Ariel believes that the current risk to Taproot and future activations comes from a vocal minority of users who threaten to co-opt a LOT=false activation by manipulating the parameter and orchestrating a marketing campaign that could result in a contentious fork if things do not go well. As long as this threat persists, achieving consensus will be challenging. Ariel suggests that Bitcoin should remain as it is until the minority forks off with their own alt-node. If the UASF minority is determined to create the alt-node, Ariel hopes that it will be released promptly to break the deadlock, allowing for an early LOT=false activation.Michael counters Ariel's argument by stating that Ariel misunderstands BIP 8 (LOT=true). He clarifies that no specific timetable has been finalized yet, but the earliest the MUST_SIGNAL period would commence is approximately July 2022. To Michael, this timeline does not seem quick enough if Ariel aims for a LOT=false release following a failed LOT=true release. Michael concludes by expressing hope that people will reconsider their stance as the date approaches and realize that a LOT=true (UASF) version might be the only way to activate Taproot.The discussion surrounding Taproot activation has generated frustration, leading to extensive conversations in high-level activation discussions. The writer notes concerns that the current environment is not conducive to development and review. It appears likely that Core will only ship BIP 8 (1 year, LOT=false) as there is currently no alternative available, which raises the possibility of Core shipping nothing at all. The small group of developers who adopt a conservative approach and engage in philosophical debates are seen as the greatest risk to Taproot's gradual demise, resulting in delays in upgrading and preparing for manageable risks later in the year. This delay is causing the trillion-dollar industry waiting for the upgrade to spend time monitoring arguments instead of making necessary preparations.To ensure Taproot's activation this year (2021), it is essential to provide miners and users with the ability to activate it through any means available, be it Core or a UASF release. Failure to do so may result in Taproot never being activated. The writer emphasizes the need for a UASF (LOT=true) project to be ready, similar to the one in 2017, to prevent a small group from impeding progress. However, the writer also acknowledges that Core should be given the opportunity to ship a BIP 8 (1 year, LOT=false) activation that undergoes thorough review and testing like any other Core consensus code change.Once the situation has calmed down, it is important to reevaluate the progress made and make decisions accordingly. Michael Folkson, the author of this message, can be contacted via email at michaelfolkson@gmail.com, Keybase: michaelfolkson, or PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3. 2021-03-04T10:54:19+00:00 + Ariel Luaces and Michael Folkson have engaged in an email exchange discussing the activation of Taproot on Bitcoin. Michael expresses concern about a small group of conservative developers who are obstructing progress by ignoring the work done by others and delaying the activation until they find their desired solution. He argues that consensus on one parameter of the activation mechanism should not require as high a level of agreement as for the actual soft fork being activated.In contrast, Ariel believes that the current risk to Taproot and future activations comes from a vocal minority of users who threaten to co-opt a LOT=false activation by manipulating the parameter and orchestrating a marketing campaign that could result in a contentious fork if things do not go well. As long as this threat persists, achieving consensus will be challenging. Ariel suggests that Bitcoin should remain as it is until the minority forks off with their own alt-node. If the UASF minority is determined to create the alt-node, Ariel hopes that it will be released promptly to break the deadlock, allowing for an early LOT=false activation.Michael counters Ariel's argument by stating that Ariel misunderstands BIP 8 (LOT=true). He clarifies that no specific timetable has been finalized yet, but the earliest the MUST_SIGNAL period would commence is approximately July 2022. To Michael, this timeline does not seem quick enough if Ariel aims for a LOT=false release following a failed LOT=true release. Michael concludes by expressing hope that people will reconsider their stance as the date approaches and realize that a LOT=true (UASF) version might be the only way to activate Taproot.The discussion surrounding Taproot activation has generated frustration, leading to extensive conversations in high-level activation discussions. The writer notes concerns that the current environment is not conducive to development and review. It appears likely that Core will only ship BIP 8 (1 year, LOT=false) as there is currently no alternative available, which raises the possibility of Core shipping nothing at all. The small group of developers who adopt a conservative approach and engage in philosophical debates are seen as the greatest risk to Taproot's gradual demise, resulting in delays in upgrading and preparing for manageable risks later in the year. This delay is causing the trillion-dollar industry waiting for the upgrade to spend time monitoring arguments instead of making necessary preparations.To ensure Taproot's activation this year (2021), it is essential to provide miners and users with the ability to activate it through any means available, be it Core or a UASF release. Failure to do so may result in Taproot never being activated. The writer emphasizes the need for a UASF (LOT=true) project to be ready, similar to the one in 2017, to prevent a small group from impeding progress. However, the writer also acknowledges that Core should be given the opportunity to ship a BIP 8 (1 year, LOT=false) activation that undergoes thorough review and testing like any other Core consensus code change.Once the situation has calmed down, it is important to reevaluate the progress made and make decisions accordingly. Michael Folkson, the author of this message, can be contacted via email at michaelfolkson@gmail.com, Keybase: michaelfolkson, or PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_Yet-another-Taproot-activation-logic.xml b/static/bitcoin-dev/March_2021/combined_Yet-another-Taproot-activation-logic.xml index 47aae686cc..663d12b4c9 100644 --- a/static/bitcoin-dev/March_2021/combined_Yet-another-Taproot-activation-logic.xml +++ b/static/bitcoin-dev/March_2021/combined_Yet-another-Taproot-activation-logic.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Yet another Taproot activation logic - 2023-08-02T03:23:27.760768+00:00 - - Carlo Spiller 2021-03-08 08:24:15+00:00 - - - Ariel Lorenzo-Luaces 2021-03-07 21:13:47+00:00 - - - Carlo Spiller 2021-03-07 09:58:30+00:00 - + 2025-09-26T16:05:29.585216+00:00 + python-feedgen + + + [bitcoin-dev] Yet another Taproot activation logic Carlo Spiller + 2021-03-07T09:58:00.000Z + + + Ariel Lorenzo-Luaces + 2021-03-07T21:13:00.000Z + + + Carlo Spiller + 2021-03-08T08:24:00.000Z + + - python-feedgen + 2 Combined summary - Yet another Taproot activation logic - 2023-08-02T03:23:27.761769+00:00 + 2025-09-26T16:05:29.585720+00:00 - In response to Carlo's proposal, Ariel Lorenzo-Luaces points out a flaw in the plan. Users would not know what to do if signaling is between 51% and 79%. This could potentially lead to a user-activated soft fork (UASF) that may cause concerns for other users, as they could be at risk of significant reorganizations in order to gain support. To address this issue, Lorenzo-Luaces suggests a Simple Majority Activation (SMA) proposal with a final activation threshold set at 51%. This eliminates the incentive for a UASF because if 51% is not reached, it indicates insufficient miner support to maintain the integrity of the chain.Carlo's proposal aims to modify the activation threshold for Taproot, but it has raised some concerns among users. The new proposal suggests an initial deployment with LOT=false and an activation threshold of 95% of miner signaling. If, after six months, Taproot is not activated by MASF, but at least 80% of hashpower signals for the upgrade, a lock-in date is set for another six months later, and the threshold for MASF is lowered to 90%. However, if the initial six months of signaling with LOT=false fail to reach the 80% threshold, the proposal expires.One of the main issues with Carlo's proposal is that it leaves users uncertain about how to activate Taproot if signaling falls between 51% and 79%. This uncertainty can lead to the potential for a UASF movement, which seeks to activate Taproot without the need for 21% to 49% of miners to signal. However, a UASF movement would require a hard fork to change the proof-of-work (PoW) mechanism for protection and change addresses to prevent double spends if support is less than 50%. Such a movement with a miner majority can create fear among other users due to the possibility of significant reorganizations to gain support and followers.In light of these concerns, Lorenzo-Luaces suggests the SMA proposal with a final activation threshold set at 51%. This removes the incentive for a UASF because if the threshold of 51% is not reached, it indicates that there is insufficient miner support to maintain the chain's integrity. By adopting this approach, the risks associated with a potential UASF can be mitigated, providing a more stable and secure activation process for Taproot. 2021-03-08T08:24:15+00:00 + In response to Carlo's proposal, Ariel Lorenzo-Luaces points out a flaw in the plan. Users would not know what to do if signaling is between 51% and 79%. This could potentially lead to a user-activated soft fork (UASF) that may cause concerns for other users, as they could be at risk of significant reorganizations in order to gain support. To address this issue, Lorenzo-Luaces suggests a Simple Majority Activation (SMA) proposal with a final activation threshold set at 51%. This eliminates the incentive for a UASF because if 51% is not reached, it indicates insufficient miner support to maintain the integrity of the chain.Carlo's proposal aims to modify the activation threshold for Taproot, but it has raised some concerns among users. The new proposal suggests an initial deployment with LOT=false and an activation threshold of 95% of miner signaling. If, after six months, Taproot is not activated by MASF, but at least 80% of hashpower signals for the upgrade, a lock-in date is set for another six months later, and the threshold for MASF is lowered to 90%. However, if the initial six months of signaling with LOT=false fail to reach the 80% threshold, the proposal expires.One of the main issues with Carlo's proposal is that it leaves users uncertain about how to activate Taproot if signaling falls between 51% and 79%. This uncertainty can lead to the potential for a UASF movement, which seeks to activate Taproot without the need for 21% to 49% of miners to signal. However, a UASF movement would require a hard fork to change the proof-of-work (PoW) mechanism for protection and change addresses to prevent double spends if support is less than 50%. Such a movement with a miner majority can create fear among other users due to the possibility of significant reorganizations to gain support and followers.In light of these concerns, Lorenzo-Luaces suggests the SMA proposal with a final activation threshold set at 51%. This removes the incentive for a UASF because if the threshold of 51% is not reached, it indicates that there is insufficient miner support to maintain the chain's integrity. By adopting this approach, the risks associated with a potential UASF can be mitigated, providing a more stable and secure activation process for Taproot. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2021/combined_activation-mechanism-considerations.xml b/static/bitcoin-dev/March_2021/combined_activation-mechanism-considerations.xml index 742a0b709a..595eda7024 100644 --- a/static/bitcoin-dev/March_2021/combined_activation-mechanism-considerations.xml +++ b/static/bitcoin-dev/March_2021/combined_activation-mechanism-considerations.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - activation mechanism considerations - 2023-08-02T03:20:45.851045+00:00 - - Steve Lee 2021-03-04 16:00:08+00:00 - - - Melvin Carvalho 2021-03-04 09:25:41+00:00 - - - John Rand 2021-03-03 23:02:14+00:00 - + 2025-09-26T16:05:42.236965+00:00 + python-feedgen + + + [bitcoin-dev] activation mechanism considerations John Rand + 2021-03-03T23:02:00.000Z + + + Melvin Carvalho + 2021-03-04T09:25:00.000Z + + + Steve Lee + 2021-03-04T16:00:00.000Z + + - python-feedgen + 2 Combined summary - activation mechanism considerations - 2023-08-02T03:20:45.851045+00:00 + 2025-09-26T16:05:42.237542+00:00 - The recent discussion on the bitcoin-dev mailing list emphasized the importance of achieving consensus for taproot and the activation mechanism. It was acknowledged that not all future soft-forks may receive as much support as taproot, making it crucial to approach the activation topic with patience and calm. Rushing into ill-considered decisions should be avoided.John Rand, in an email to the mailing list, stressed the need for positive progress on the activation topic. He stated that Bitcoin must prevail in achieving a future upgrade, even in the face of powerful interests counter to the interests of Bitcoin users and investors. In order to achieve this, the activation topic should be treated with decorum and tight non-emotive reasoning, devoid of frustration and impatience.Rand proposed incremental improvement as a way to handle complex and unintuitive topics. This allows people to learn as they go, rather than trying to solve everything in one step. Failure to upgrade or demoralizing protocol researchers could pose a systemic risk, considering that there will be more upgrades that Bitcoin will need in the future.One suggestion put forward in response to Rand's proposal was to have an incorruptible machine that gathers the highest fee transactions from the mempool and posts them every 10 minutes. This would make Bitcoin largely run itself. Additionally, it was suggested that forks could potentially become a diminishing issue over time.In conclusion, the discussion revolved around the importance of achieving consensus for future soft-forks and the need to handle the activation topic with consideration and decorum. The potential risks of failing to upgrade were highlighted, and suggestions were made for improving the activation process. It was reiterated that incremental improvement is key, and now is a convenient time to make progress in this area. 2021-03-04T16:00:08+00:00 + The recent discussion on the bitcoin-dev mailing list emphasized the importance of achieving consensus for taproot and the activation mechanism. It was acknowledged that not all future soft-forks may receive as much support as taproot, making it crucial to approach the activation topic with patience and calm. Rushing into ill-considered decisions should be avoided.John Rand, in an email to the mailing list, stressed the need for positive progress on the activation topic. He stated that Bitcoin must prevail in achieving a future upgrade, even in the face of powerful interests counter to the interests of Bitcoin users and investors. In order to achieve this, the activation topic should be treated with decorum and tight non-emotive reasoning, devoid of frustration and impatience.Rand proposed incremental improvement as a way to handle complex and unintuitive topics. This allows people to learn as they go, rather than trying to solve everything in one step. Failure to upgrade or demoralizing protocol researchers could pose a systemic risk, considering that there will be more upgrades that Bitcoin will need in the future.One suggestion put forward in response to Rand's proposal was to have an incorruptible machine that gathers the highest fee transactions from the mempool and posts them every 10 minutes. This would make Bitcoin largely run itself. Additionally, it was suggested that forks could potentially become a diminishing issue over time.In conclusion, the discussion revolved around the importance of achieving consensus for future soft-forks and the need to handle the activation topic with consideration and decorum. The potential risks of failing to upgrade were highlighted, and suggestions were made for improving the activation process. It was reiterated that incremental improvement is key, and now is a convenient time to make progress in this area. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml b/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml index 8c4f9ea63a..3ccf251a26 100644 --- a/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml +++ b/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml @@ -2,7 +2,7 @@ 2 Combined summary - Decentralized BIP 47 payment code directory - 2025-09-26T14:35:18.252934+00:00 + 2025-09-26T15:56:26.533983+00:00 python-feedgen Prayank 2022-03-02 04:45:58+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Decentralized BIP 47 payment code directory - 2025-09-26T14:35:18.253118+00:00 + 2025-09-26T15:56:26.534133+00:00 2022-03-02T04:45:58+00:00 In a conversation between Peter and Prayank, Prayank introduces a newer version (v3 and v4) of BIP47, which has been proposed on GitHub. This version aims to solve the toxic change issue and seems like an improvement. Prayank explains that using an xpub does not provide anonymity because anyone who has access to the xpub, including platforms or hackers, can identify one's payments. However, using a payment code allows for public association without revealing the payment identifier on the blockchain, making it difficult for others to determine if funds have been received. Prayank also suggests a rust library that can assist application developers in implementing BIP47 into different bitcoin projects.The OpenBitcoinPrivacyProject has proposed a newer version of BIP47, v3 and v4, which addresses certain issues present in the previous version. The new version eliminates the toxic change issue by modifying the notification from Alice to Bob as a transaction from Alice to herself, functioning as a bare 1 of 3 multisig. Two pubkeys represent Alice's payment code and Bob's payment identifier. This change incurs a one-time overhead of 64 bytes for the two pubkeys, which is spread out over the lifespan of the relationship between Alice and Bob. Additionally, the first economic payment from Alice to Bob can be included with the notification transaction. Payment codes can be recovered from the bip32 seed without requiring extra backups. The new version is already being used in production with Samourai wallet. BIP47 v3 enables Alice to receive Bob's address without exposing her IP/identity to Charlie. Charlie can observe Alice receiving the payment code material from Bob but cannot determine if Alice proceeded to make a payment to Bob. Unlike an xpub, this method ensures privacy even if the xpub is shared with a crowdfunding platform, as the platform or any potential hackers cannot identify the payments made by Alice. By using the payment code, individuals can publicly associate themselves with their payment code without revealing if they have received funds, as the payment code is not visible on the blockchain.Twitter has seen discussions about BIP47 and its potential to enhance privacy. However, some developers argue that it merely adds spam to the Bitcoin network without providing any actual improvements. Additionally, the only existing implementation of BIP47 is Paynym, a centralized payment code directory managed by Samourai wallet, raising concerns regarding privacy and security. To address these concerns, the author suggests utilizing TXT records and domains. They present a proof of concept using GNS (GNU Name Service) to create a payment code for Alice, adding it as a TXT record with an expiry date, and verifying it. The author also proposes using `gnunet-publish` as a replacement for notification transactions. These solutions could potentially help users avoid sharing their bitcoin addresses on social media platforms when receiving donations. In addition to these suggestions, the author provides links to related resources, including a Q&A on accepting donations correctly and a new proposal addressing privacy concerns. diff --git a/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml b/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml index 2871844a8e..4676a281e2 100644 --- a/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml +++ b/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml @@ -2,7 +2,7 @@ 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2025-09-26T14:35:46.097865+00:00 + 2025-09-26T15:56:28.686168+00:00 python-feedgen Paul Sztorc 2022-03-04 20:06:50+00:00 @@ -93,10 +93,11 @@ + 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2025-09-26T14:35:46.098032+00:00 + 2025-09-26T15:56:28.686331+00:00 2022-03-04T20:06:50+00:00 In an email exchange on the bitcoin-dev mailing list, Billy Tetrud discusses sidechains and their potential to address the issue of a less-secure altcoin dominating Bitcoin. While he acknowledges some merits of sidechains in this scenario, Tetrud points out that they do not completely solve the problem. He raises concerns about a sidechain cutting off the main chain and whether it would be in the best interest of enough people. Tetrud also explores the benefits and drawbacks of largeblock sidechains compared to other payment systems like Visa and Lightning. Various tradeoffs, such as onboarding, payment speed, micropayments, fees, and contribution to layer 1 security budget, are considered. Tetrud concludes that if a layer 2 is harmless, its existence can be justified by one net benefit for some users.Another discussion revolves around the size of commitments needed for sidechains and channel factories. User ZmnSCPxj suggests a solution to reduce on-chain bytes by utilizing tweaks in the miner's key and unused TapScript. This eliminates the need for separate commitments and reduces data requirements. Additionally, sidechains can push zero bytes on-chain by using OP_RETURN inside TapScript for checking purposes.The conversation centers around the potential dominance of a sidechain over Bitcoin and how it could prevent an altcoin from dominating. The consensus is that having all chains, centralized and decentralized, in the same monetary unit ensures the decentralized chain always exists without interference from monetary network effects. However, it is argued that a sidechain cannot exist without its main chain, and if it becomes too popular, people may stop using the main chain altogether. The discussion also compares the benefits of a largeblock sidechain to Visa and Lightning and considers the burden on Bitcoin-only nodes. The potential advantages to users of a largeblock sidechain are discussed, including lower fees and more decentralization. The idea of sweeping fiat transactions into a largeblock sidechain is also explored.Another conversation between Billy Tetrud and Paul focuses on the use of sidechains in Bitcoin. Billy proposes that all chains, decentralized and centralized, being in the same monetary unit ensures the existence of the decentralized chain without interference from network effects. Paul disagrees, stating that sidechains cannot exist without their main chain and gives an example using a zcash sidechain. They also discuss the merits of largeblock sidechains and how they can allow users to easily sweep fiat transactions into the BTC universe. Paul believes that largeblock sidechains would not burden Bitcoin Core full nodes.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin scalability, sidechains, network effects, and the security of Lightning Network and Drivechains. Participants argue that sidechains are necessary to prevent people from switching entirely to altcoins, which could be heavily exploited by attackers. Another participant suggests that having all chains in the same monetary unit guarantees the existence of the decentralized chain. The discussion delves into the security risks of LN channel factories and compares the security of LN and Drivechains. The participants emphasize the importance of separating the onboarding rate from the payment rate for designing different structures.The email exchange on the bitcoin-dev mailing list centers around the use of recursive covenants and their potential impact on Bitcoin. The discussion explores implementing techniques like Drivechains using recursive covenants. While concerns about negative effects on Bitcoin or the user base are raised, it is suggested that separate soft forks can be used to add recursive covenants if consensus is reached. The rejection of Drivechains in Bitcoin is also discussed, with arguments made against their implementation due to their distinct security model and potential block size increase. However, proponents argue that Drivechains could have a positive impact and should be given a chance. The debate includes discussions on miner censorship, block size increase, and the need for consensus changes. Paul Sztorc responds to the rejection of Drivechains, stating that there is no strong incentive for mainchain miners and sidechain validators to merge their businesses. He refutes claims that Drivechains would degrade security and believes that Drivechain was ahead of its time and will eventually be adopted. Other discussions revolve around encumbrances and restrictions on spend from covenants, the potential harm to the fungibility of UTXOs, and the shift in risk models. Some argue that introducing different risk models can be damaging to fungibility, while others believe that being able to reject certain coins is at the heart of Bitcoin's security. The email exchanges highlight the ongoing debates and considerations surrounding recursive covenants, Drivechains, and their potential impact on Bitcoin.In a recent email to the Bitcoin-dev mailing list, Jeremy Rubin raises concerns about proposals enabling more "featureful" covenants by adding additional computation into bitcoin script. They emphasize the importance of limiting operations in bitcoin script to "verification" rather than "computation" whenever possible. The author expresses uncertainty about these proposals and fears that opcodes like OP_CAT and OP_TX introduce unnecessary complexity into the script. However, diff --git a/static/bitcoin-dev/May_2016/combined_BIP-Number-Request-Open-Asset.xml b/static/bitcoin-dev/May_2016/combined_BIP-Number-Request-Open-Asset.xml index 8ca47b0e08..a48c497b3a 100644 --- a/static/bitcoin-dev/May_2016/combined_BIP-Number-Request-Open-Asset.xml +++ b/static/bitcoin-dev/May_2016/combined_BIP-Number-Request-Open-Asset.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Number Request: Open Asset - 2023-08-01T18:24:14.439237+00:00 + 2025-09-26T15:35:11.253720+00:00 + python-feedgen Nicolas Dorier 2016-08-13 02:25:04+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - BIP Number Request: Open Asset - 2023-08-01T18:24:14.439237+00:00 + 2025-09-26T15:35:11.253885+00:00 - The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it 2016-08-13T02:25:04+00:00 + The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_BIP-OP-PRANDOM.xml b/static/bitcoin-dev/May_2016/combined_BIP-OP-PRANDOM.xml index 0d8c9ebc00..93c316e430 100644 --- a/static/bitcoin-dev/May_2016/combined_BIP-OP-PRANDOM.xml +++ b/static/bitcoin-dev/May_2016/combined_BIP-OP-PRANDOM.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: OP_PRANDOM - 2023-08-01T18:23:34.670639+00:00 + 2025-09-26T15:35:17.597693+00:00 + python-feedgen Sergio Demian Lerner 2016-05-24 14:36:35+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BIP: OP_PRANDOM - 2023-08-01T18:23:34.670639+00:00 + 2025-09-26T15:35:17.597856+00:00 - The email conversation posted discusses the issue of using random numbers in Bitcoin. A proposed solution is the use of the Bitcoin Beacon paper, which suggests deciding a random bit on the majority 1s or 0s of least significant bits taken from last block hashes. The protocol πbeacon is also examined, which outputs unpredictable and publicly verifiable randomness. The paper shows that πbeacon can be instantiated via Bitcoin under sensible assumptions, but provides an impossibility result that stems from the similarity between the Bitcoin model and Santha-Vazirani sources for cases in which the adversary has an infinite budget. The email also discusses the potential security risks of using multiple block hashes as a source of randomness, which can be mitigated by every miner needing to be bribed to control the results of the random numbers. Additionally, Eric Martindale mentions OP_DETERMINISTICRANDOM from the Elements Project as a possible solution. Finally, Jeremy Rubin suggests adding OP_XOR back and then using something like Blum's fair coin-flipping over the phone for these use cases.A protocol named πbeacon is examined in a paper by Iddo Bentov, Ariel Gabizon, and David Zuckerman that outputs unpredictable and publicly verifiable randomness. Bitcoin can be used to instantiate πbeacon under sensible assumptions. However, an impossibility result exists in case the adversary has an infinite budget as it stems from the similarity between the Bitcoin model and Santha-Vazirani sources. A hybrid protocol that combines trusted parties and a Bitcoin-based beacon is also provided. In a discussion on bitcoin-dev mailing list, Eric Martindale suggests taking a look at OP_DETERMINISTICRANDOM from the Elements Project as it aims to achieve a similar goal. Matthew Roberts explores the idea of using multiple block hashes as a source of randomness, but Johnson Lau points out that this does not make it any safer since the miner of the last block always determines the results. To protect the details of contracts using OP_PRANDOM from miners, pay-to-script-hash can be used, but there is still a non-zero risk of participants attempting to bribe a miner.The discussion on the bitcoin-dev mailing list revolves around the security of using OP_PRANDOM to generate random numbers. It is argued that OP_PRANDOM is not secure and adds extra validation overhead on a block composed of transactions spending an OP_PRANDOM output from different blocks. The suggestion is made to add OP_XOR back and use Blum's fair coin-flipping over the phone. However, there are limitations and issues with this approach. Another option suggested is to use OP_DETERMINISTICRANDOM from the Elements Project. There is also a discussion on the security aspect of using multiple block hashes as a source of randomness and how Pay-to-script-hash can be used to protect the details of contracts using OP_PRANDOM. The risk of a participant attempting to bribe a miner to control the results of the random numbers is considered low as the number of required bribes goes up.A suggestion was made to Matthew Roberts to take a look at OP_DETERMINISTICRANDOM from the Elements Project, as it aims to achieve a similar goal. The code for this can be found in the alpha branch. In response to this, Johnson Lau stated that using the hash of multiple blocks does not make it any safer and that the miner of the last block always determines the results. However, to protect the details of contracts that use OP_PRANDOM from the prying eyes of miners, Pay-to-script-hash can be used, and the inclusion of multiple block hashes as a source of randomness is a must. The risk approaches zero as N goes up. Matthew Roberts mentioned a possible solution where the hash of the proof of work hash could be used as part of the number, but he needs to sleep on it for now.The context is a discussion of the security of using multiple block hashes as a source of randomness. It is suggested that combining block hashes by taking the first N bits from each block hash to produce a single number may be a better approach than the current direction. Another suggestion is to use the hash of the proof of work hash as part of the number, making it infinitely expensive to manipulate the number. However, there is a non-zero risk of a participant in a contract attempting to bribe a miner, so the inclusion of multiple block hashes as a source of randomness is necessary. Every miner would effectively need to be bribed to ensure control over the results of the random numbers. Using Pay-to-script-hash can protect the details of contracts that use OP_PRANDOM from miners' prying eyes. The risk approaches zero as N goes up.In a discussion on the bitcoin-dev mailing list, Johnson Lau questioned the usefulness of using the hash of multiple blocks to secure transactions. He argued that since the miner of the last block ultimately determines the results, knowing the hashes of previous blocks doesn't make it any safer. However, pay-to-script-hash can be utilized 2016-05-24T14:36:35+00:00 + The email conversation posted discusses the issue of using random numbers in Bitcoin. A proposed solution is the use of the Bitcoin Beacon paper, which suggests deciding a random bit on the majority 1s or 0s of least significant bits taken from last block hashes. The protocol πbeacon is also examined, which outputs unpredictable and publicly verifiable randomness. The paper shows that πbeacon can be instantiated via Bitcoin under sensible assumptions, but provides an impossibility result that stems from the similarity between the Bitcoin model and Santha-Vazirani sources for cases in which the adversary has an infinite budget. The email also discusses the potential security risks of using multiple block hashes as a source of randomness, which can be mitigated by every miner needing to be bribed to control the results of the random numbers. Additionally, Eric Martindale mentions OP_DETERMINISTICRANDOM from the Elements Project as a possible solution. Finally, Jeremy Rubin suggests adding OP_XOR back and then using something like Blum's fair coin-flipping over the phone for these use cases.A protocol named πbeacon is examined in a paper by Iddo Bentov, Ariel Gabizon, and David Zuckerman that outputs unpredictable and publicly verifiable randomness. Bitcoin can be used to instantiate πbeacon under sensible assumptions. However, an impossibility result exists in case the adversary has an infinite budget as it stems from the similarity between the Bitcoin model and Santha-Vazirani sources. A hybrid protocol that combines trusted parties and a Bitcoin-based beacon is also provided. In a discussion on bitcoin-dev mailing list, Eric Martindale suggests taking a look at OP_DETERMINISTICRANDOM from the Elements Project as it aims to achieve a similar goal. Matthew Roberts explores the idea of using multiple block hashes as a source of randomness, but Johnson Lau points out that this does not make it any safer since the miner of the last block always determines the results. To protect the details of contracts using OP_PRANDOM from miners, pay-to-script-hash can be used, but there is still a non-zero risk of participants attempting to bribe a miner.The discussion on the bitcoin-dev mailing list revolves around the security of using OP_PRANDOM to generate random numbers. It is argued that OP_PRANDOM is not secure and adds extra validation overhead on a block composed of transactions spending an OP_PRANDOM output from different blocks. The suggestion is made to add OP_XOR back and use Blum's fair coin-flipping over the phone. However, there are limitations and issues with this approach. Another option suggested is to use OP_DETERMINISTICRANDOM from the Elements Project. There is also a discussion on the security aspect of using multiple block hashes as a source of randomness and how Pay-to-script-hash can be used to protect the details of contracts using OP_PRANDOM. The risk of a participant attempting to bribe a miner to control the results of the random numbers is considered low as the number of required bribes goes up.A suggestion was made to Matthew Roberts to take a look at OP_DETERMINISTICRANDOM from the Elements Project, as it aims to achieve a similar goal. The code for this can be found in the alpha branch. In response to this, Johnson Lau stated that using the hash of multiple blocks does not make it any safer and that the miner of the last block always determines the results. However, to protect the details of contracts that use OP_PRANDOM from the prying eyes of miners, Pay-to-script-hash can be used, and the inclusion of multiple block hashes as a source of randomness is a must. The risk approaches zero as N goes up. Matthew Roberts mentioned a possible solution where the hash of the proof of work hash could be used as part of the number, but he needs to sleep on it for now.The context is a discussion of the security of using multiple block hashes as a source of randomness. It is suggested that combining block hashes by taking the first N bits from each block hash to produce a single number may be a better approach than the current direction. Another suggestion is to use the hash of the proof of work hash as part of the number, making it infinitely expensive to manipulate the number. However, there is a non-zero risk of a participant in a contract attempting to bribe a miner, so the inclusion of multiple block hashes as a source of randomness is necessary. Every miner would effectively need to be bribed to ensure control over the results of the random numbers. Using Pay-to-script-hash can protect the details of contracts that use OP_PRANDOM from miners' prying eyes. The risk approaches zero as N goes up.In a discussion on the bitcoin-dev mailing list, Johnson Lau questioned the usefulness of using the hash of multiple blocks to secure transactions. He argued that since the miner of the last block ultimately determines the results, knowing the hashes of previous blocks doesn't make it any safer. However, pay-to-script-hash can be utilized - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_Bip44-extension-for-P2SH-P2WSH-.xml b/static/bitcoin-dev/May_2016/combined_Bip44-extension-for-P2SH-P2WSH-.xml index bbb10d75a3..24b4aeed6b 100644 --- a/static/bitcoin-dev/May_2016/combined_Bip44-extension-for-P2SH-P2WSH-.xml +++ b/static/bitcoin-dev/May_2016/combined_Bip44-extension-for-P2SH-P2WSH-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bip44 extension for P2SH/P2WSH/... - 2023-08-01T18:21:28.595777+00:00 + 2025-09-26T15:35:09.140667+00:00 + python-feedgen Aaron Voisine 2016-05-15 17:36:54+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Bip44 extension for P2SH/P2WSH/... - 2023-08-01T18:21:28.595777+00:00 + 2025-09-26T15:35:09.140840+00:00 - In an email conversation, Daniel Weigl and Aaron Voisine discussed the idea of using 0x40000000 as the next available number to specify witness addresses. Weigl expressed concern that every BIP-compatible wallet in the future would have to implement all legacy derivation and transaction schemes. Voisine agreed that old derivations would still need to be supported for many decades, but suggested using a new BIP43 purpose number for segwit only wallets. He also proposed specifying 0x40000000/1 for the change/receive index to maintain compatibility with other schemes for upgrading existing wallets.Another discussion focused on implementing a new derivation path parallel to Bip44 but with a different purpose, allowing users to choose between normal and witness accounts. However, this approach would require all Bip-compatible wallets in the future to implement all legacy derivation and transaction schemes and could result in non-deterministic failures when importing seeds or xPriv/xPub across different capable wallets. The solution proposed was to use 0x40000000 as the bit field flag to specify witness addresses, compatible with existing accounts and wallet layouts. However, recovering on non-segwit software would miss segwit receives.Jonas Schnelli raised the issue of the lack of BIP39 import support in wallets such as Schildbachs android wallet, Electrum, and Breadwallet. It was confirmed that these wallets are not BIP44 compatible, and there were concerns about the security risks involved in importing a bip39 mnemonic into a hardware wallet. Despite the potential risks, it was recommended to send all coins to the new seed.Electrum's developer explained that they do not support Bip39 import due to the lack of a version number in BIP39 seed phrases, which is needed for maintaining backward compatibility. As Electrum allocated a new version number for seed phrases derived to segwit addresses, BIP39 designers would need to change the semantics of their checksum bits to encode a version number for segwit.There were discussions about the challenges of moving funds to a new wallet, potential loss of funds if the old wallet has used more than 1000 addresses, and the need for wallets to implement BIP32 HD. Importing a wallet, especially cross-wallet imports, was considered a tricky step that may require expertise and further improvements.BIP43 and BIP44 were discussed, with BIP43 defining how balance retrieval works and BIP44 based on this idea. The goal was to ensure that the same balance is always seen on wallets that use the same BIP and seed.Opinions differed on whether importing a BIP32 wallet is still an expert job. Some argued that it is not, as reasonable wallets now use BIP39 mnemonic for this purpose. However, concerns were raised about cross-wallet imports using BIP39 and the potential problems associated with it.The email thread also touched on the topic of recovering funds from a wallet conforming to BIPXX, which requires wallet software to handle BIPXX. Importing a bip32 wallet was still considered an expert job, and there were discussions on how to improve the process.A proposed scheme involved using the chain index instead of the account index to indicate the type of address, but it created confusion regarding wallet compatibility with segwit. It was suggested to have another BIP specifically for segwit to clarify compatibility.In a discussion about the default BIP32 wallet layout, Aaron Voisine suggested using a bit field flag to specify the type of address. He proposed using 0x40000000 as the flag since 0x80000000 is already used for hardened derivation. However, Pavol Rusnak questioned the advantages of this optimization and noted that the discussion was off-topic as they were discussing multiple-accounts per wallet layout, not one-account-per-wallet design.The idea of specifying the type of address as a bit field flag is liked because it avoids checking multiple address types for each key. The suggestion was to use 0x40000000 as the flag, which would be compatible with existing accounts and wallet layouts. However, recovering on non-segwit software would miss segwit receives. Another option proposed was to define a new derivation path parallel to Bip44, allowing users to choose between a "Normal account" and a "Witness account". Pavol Rusnak from SatoshiLabs.com suggested that option #2 is better and they plan to implement it in myTREZOR. There are plans for BIP44 compliant wallets, but no visible results yet.Daniel Weigl suggested two options for improving the wallet experience. The second option involves defining a new derivation path parallel to Bip44 but with a different purpose, allowing users to choose between a "normal" or "witness" account. The team agreed that option #2 would be better and plans to implement it in myTREZOR. It was mentioned that there is a project in the pipeline for BIP 2016-05-15T17:36:54+00:00 + In an email conversation, Daniel Weigl and Aaron Voisine discussed the idea of using 0x40000000 as the next available number to specify witness addresses. Weigl expressed concern that every BIP-compatible wallet in the future would have to implement all legacy derivation and transaction schemes. Voisine agreed that old derivations would still need to be supported for many decades, but suggested using a new BIP43 purpose number for segwit only wallets. He also proposed specifying 0x40000000/1 for the change/receive index to maintain compatibility with other schemes for upgrading existing wallets.Another discussion focused on implementing a new derivation path parallel to Bip44 but with a different purpose, allowing users to choose between normal and witness accounts. However, this approach would require all Bip-compatible wallets in the future to implement all legacy derivation and transaction schemes and could result in non-deterministic failures when importing seeds or xPriv/xPub across different capable wallets. The solution proposed was to use 0x40000000 as the bit field flag to specify witness addresses, compatible with existing accounts and wallet layouts. However, recovering on non-segwit software would miss segwit receives.Jonas Schnelli raised the issue of the lack of BIP39 import support in wallets such as Schildbachs android wallet, Electrum, and Breadwallet. It was confirmed that these wallets are not BIP44 compatible, and there were concerns about the security risks involved in importing a bip39 mnemonic into a hardware wallet. Despite the potential risks, it was recommended to send all coins to the new seed.Electrum's developer explained that they do not support Bip39 import due to the lack of a version number in BIP39 seed phrases, which is needed for maintaining backward compatibility. As Electrum allocated a new version number for seed phrases derived to segwit addresses, BIP39 designers would need to change the semantics of their checksum bits to encode a version number for segwit.There were discussions about the challenges of moving funds to a new wallet, potential loss of funds if the old wallet has used more than 1000 addresses, and the need for wallets to implement BIP32 HD. Importing a wallet, especially cross-wallet imports, was considered a tricky step that may require expertise and further improvements.BIP43 and BIP44 were discussed, with BIP43 defining how balance retrieval works and BIP44 based on this idea. The goal was to ensure that the same balance is always seen on wallets that use the same BIP and seed.Opinions differed on whether importing a BIP32 wallet is still an expert job. Some argued that it is not, as reasonable wallets now use BIP39 mnemonic for this purpose. However, concerns were raised about cross-wallet imports using BIP39 and the potential problems associated with it.The email thread also touched on the topic of recovering funds from a wallet conforming to BIPXX, which requires wallet software to handle BIPXX. Importing a bip32 wallet was still considered an expert job, and there were discussions on how to improve the process.A proposed scheme involved using the chain index instead of the account index to indicate the type of address, but it created confusion regarding wallet compatibility with segwit. It was suggested to have another BIP specifically for segwit to clarify compatibility.In a discussion about the default BIP32 wallet layout, Aaron Voisine suggested using a bit field flag to specify the type of address. He proposed using 0x40000000 as the flag since 0x80000000 is already used for hardened derivation. However, Pavol Rusnak questioned the advantages of this optimization and noted that the discussion was off-topic as they were discussing multiple-accounts per wallet layout, not one-account-per-wallet design.The idea of specifying the type of address as a bit field flag is liked because it avoids checking multiple address types for each key. The suggestion was to use 0x40000000 as the flag, which would be compatible with existing accounts and wallet layouts. However, recovering on non-segwit software would miss segwit receives. Another option proposed was to define a new derivation path parallel to Bip44, allowing users to choose between a "Normal account" and a "Witness account". Pavol Rusnak from SatoshiLabs.com suggested that option #2 is better and they plan to implement it in myTREZOR. There are plans for BIP44 compliant wallets, but no visible results yet.Daniel Weigl suggested two options for improving the wallet experience. The second option involves defining a new derivation path parallel to Bip44 but with a different purpose, allowing users to choose between a "normal" or "witness" account. The team agreed that option #2 would be better and plans to implement it in myTREZOR. It was mentioned that there is a project in the pipeline for BIP - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml b/static/bitcoin-dev/May_2016/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml index 8e731e228d..49cc13d2a9 100644 --- a/static/bitcoin-dev/May_2016/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml +++ b/static/bitcoin-dev/May_2016/combined_Committed-bloom-filters-for-improved-wallet-performance-and-SPV-security.xml @@ -1,113 +1,147 @@ - + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 - - bfd at cock.lu 2017-04-01 23:49:03+00:00 - - - Tom Harding 2017-03-16 15:05:11+00:00 - - - bfd at cock.lu 2017-03-16 00:25:01+00:00 - - - Tom Harding 2017-03-15 22:36:09+00:00 - - - Chris Belcher 2017-02-17 00:28:59+00:00 - - - Erik Aronesty 2017-01-06 22:07:36+00:00 - - - Eric Voskuil 2017-01-06 21:50:47+00:00 - - - James MacWhyte 2017-01-06 21:35:58+00:00 - - - Chris Priest 2017-01-06 20:15:46+00:00 - - - Aaron Voisine 2017-01-06 07:07:34+00:00 - - - bfd at cock.lu 2017-01-06 02:15:26+00:00 - - - bfd at cock.lu 2017-01-06 02:04:22+00:00 - - - Christian Decker 2017-01-05 14:48:33+00:00 - - - Eric Voskuil 2017-01-05 07:45:18+00:00 - - - Chris Priest 2017-01-05 07:06:36+00:00 - - - Leo Wandersleb 2017-01-04 16:13:41+00:00 - - - Adam Back 2017-01-04 11:00:55+00:00 - - - Jorge Timón 2017-01-04 10:13:02+00:00 - - - Aaron Voisine 2017-01-04 08:56:21+00:00 - - - Jonas Schnelli 2017-01-04 07:47:10+00:00 - - - Eric Voskuil 2017-01-04 06:06:31+00:00 - - - Aaron Voisine 2017-01-04 00:36:34+00:00 - - - bfd at cock.lu 2017-01-04 00:10:14+00:00 - - - Aaron Voisine 2017-01-03 23:46:00+00:00 - - - adiabat 2017-01-03 23:06:26+00:00 - - - bfd at cock.lu 2017-01-03 22:28:56+00:00 - - - Aaron Voisine 2017-01-03 22:18:21+00:00 - - - bfd at cock.lu 2017-01-03 20:24:35+00:00 - - - bfd at cock.lu 2017-01-03 20:18:59+00:00 - - - Jonas Schnelli 2017-01-01 21:01:23+00:00 - - - Leo Wandersleb 2016-07-28 21:07:29+00:00 - - - Bob McElrath 2016-05-11 20:29:33+00:00 - - - Bob McElrath 2016-05-11 20:06:48+00:00 - - - Gregory Maxwell 2016-05-09 08:57:08+00:00 - - - bfd at cock.lu 2016-05-09 08:26:06+00:00 - + 2025-09-26T15:35:21.833143+00:00 + python-feedgen + + + [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd + 2016-05-09T08:26:00.000Z + + + Gregory Maxwell + 2016-05-09T08:57:00.000Z + + + Bob McElrath + 2016-05-11T20:06:00.000Z + + + Bob McElrath + 2016-05-11T20:29:00.000Z + + + Leo Wandersleb + 2016-07-28T21:07:00.000Z + + + bfd + 2017-01-03T20:18:00.000Z + + + bfd + 2017-01-03T20:24:00.000Z + + + Aaron Voisine + 2017-01-03T22:18:00.000Z + + + bfd + 2017-01-03T22:28:00.000Z + + + adiabat + 2017-01-03T23:06:00.000Z + + + Aaron Voisine + 2017-01-03T23:46:00.000Z + + + bfd + 2017-01-04T00:10:00.000Z + + + Aaron Voisine + 2017-01-04T00:36:00.000Z + + + Eric Voskuil + 2017-01-04T06:06:00.000Z + + + Jonas Schnelli + 2017-01-04T07:47:00.000Z + + + Aaron Voisine + 2017-01-04T08:56:00.000Z + + + Jorge Timón + 2017-01-04T10:13:00.000Z + + + Adam Back + 2017-01-04T11:00:00.000Z + + + Leo Wandersleb + 2017-01-04T16:13:00.000Z + + + Chris Priest + 2017-01-05T07:06:00.000Z + + + Eric Voskuil + 2017-01-05T07:45:00.000Z + + + Christian Decker + 2017-01-05T14:48:00.000Z + + + bfd + 2017-01-06T02:04:00.000Z + + + bfd + 2017-01-06T02:15:00.000Z + + + Aaron Voisine + 2017-01-06T07:07:00.000Z + + + Chris Priest + 2017-01-06T20:15:00.000Z + + + James MacWhyte + 2017-01-06T21:35:00.000Z + + + Eric Voskuil + 2017-01-06T21:50:00.000Z + + + Erik Aronesty + 2017-01-06T22:07:00.000Z + + + Chris Belcher + 2017-02-17T00:28:00.000Z + + + Tom Harding + 2017-03-15T22:36:00.000Z + + + bfd + 2017-03-16T00:25:00.000Z + + + Tom Harding + 2017-03-16T15:05:00.000Z + + + bfd + 2017-04-01T23:49:00.000Z + + @@ -143,13 +177,13 @@ - python-feedgen + 2 Combined summary - Committed bloom filters for improved wallet performance and SPV security - 2023-08-01T18:08:45.575890+00:00 + 2025-09-26T15:35:21.836330+00:00 - In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On 2017-04-01T23:49:03+00:00 + In a recent discussion on the bitcoin-dev forum, Chris Belcher expressed his support for the committed bloom filter idea over BIP37 for better privacy. However, he noted that downloading blocks from multiple peers with new tor circuits is still necessary for good privacy when using Bitcoin frequently. Belcher also discussed the challenges of finding transaction subgraphs from blocks and how a Bayesian approach could potentially address this issue. Looking to the future, Belcher believes off-chain transactions will likely be the best option for private and high-volume use of Bitcoin.Additionally, another participant in the discussion shared their belief that BIP37 is effectively unused by most wallets and services.The discussion is about compact fraud proofs in Bitcoin and their feasibility. The author argues that compact fraud proofs do not exist and even if they did, ensuring their visibility to SPV clients would pose the same problems as BIP37. It is pointed out that in the implementation of BIP37, they have no security except for a vague hope that they are not being lied to and that the chain with the most work they are seeing is actually valid. The author also mentions that during the validationless mining failure around the BIP66 activation, miners produced 6 invalid blocks in a chain and many more invalid blocks in isolated bursts for a period lasting several months. Due to the instability of the network, it is unreasonable to accept anything except multiple confirmations. The slides presented gloss over the fact that compact fraud proofs in Bitcoin aren't possible, and that the "Simplified Payment Verification" (SPV) implementation used today differs significantly from the version described in the Bitcoin white paper. In the white paper, SPV clients had the same security as fully validating nodes, while the implementation of BIP37 provides no security except a vague hope that users are not being lied to. The suggested solution does not preclude unconfirmed transactions from being used with a commitment scheme, but their usefulness for those who aren't validating is limited. During the validationless mining failure around the BIP66 activation, miners produced numerous invalid blocks, making it unreasonable to accept anything except multiple confirmations.The proposed Bloom filter method, similar to BIP37, still has a vulnerability where combining partial wallet information with transaction subgraph information can reveal which addresses belong to the wallet. The peel chain attack can identify change addresses that belong to the same wallet as an address matching the bloom filter. False positives can occur, but probability decreases as the number of transactions increases. The committed Bloom filter proposal is vulnerable to the same type of attack because it still leaks information about which addresses the wallet is interested in. The committed Bloom filter is created by deterministically creating a Bloom Filter Digest (BFD) of every block's inputs and outputs. A binary comparison between the BFD and a second bloom filter of relevant key material determines whether there are matching transactions. The BFD can be cached between clients without needing to be recomputed, and it can be used to do re-scans locally of wallets without needing the block data available to scan or reading the entire blockchain from disk.Leo Wandersleb responded to a mail thread in which a user proposed to create deterministic Bloom filter digest of every block. Leo mentioned that he had independently started implementing a similar idea, but his version ignored the commitment and signing part. He believes that 80GB compressed to 3GB would be ideal, as it could be stored on a phone. However, with segWit, the higher transaction count per MB would make this worse. Bob McElrath suggested using Cuckoo filter instead of Bloom filter, as optimal filters are logarithmic in the false-positive rate and linear in the number of elements it contains for fixed false-positive rate.The Bitcoin-Dev mailing list is being used to discuss the concept of 0-conf transactions. The debate centers around whether or not end-users should rely on 0-conf. James MacWhyte believes that the purpose of this discussion is to build base functionality so wallet developers can provide usability to their end-users. He also believes that instead of debating what wallet designers should do, we should provide tools and let the market sort out any issues that arise. Chris Priest explains that 0-conf is a method for determining the probability that a valid transaction will be mined in a block before that transaction gets mined. He also mentions that there is no "security catastrophe" with 0-conf transactions. Eric Voskuil disagrees with Priest's view and calls it an example of a Bitcoin security catastrophe.The purpose of the bitcoin protocol development is to build base functionality for companies and individuals to provide usability to the end-user. The 0-conf debate has become a UX issue. Wallet developers should hide or mark 0-conf transactions appropriately, instead of debating on what they should or shouldn't do. The list will provide tools and let the market sort it out. If wallet developers start receiving complaints on confusion and loss caused by 0-conf transactions, they will find a solution.On - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_Compact-Block-Relay-BIP.xml b/static/bitcoin-dev/May_2016/combined_Compact-Block-Relay-BIP.xml index 067dd45c29..8af86f5ba8 100644 --- a/static/bitcoin-dev/May_2016/combined_Compact-Block-Relay-BIP.xml +++ b/static/bitcoin-dev/May_2016/combined_Compact-Block-Relay-BIP.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Compact Block Relay BIP - 2023-08-01T18:06:23.793794+00:00 + 2025-09-26T15:35:04.912477+00:00 + python-feedgen Matt Corallo 2016-05-18 01:49:10+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Compact Block Relay BIP - 2023-08-01T18:06:23.793794+00:00 + 2025-09-26T15:35:04.912701+00:00 - In a Bitcoin developers mailing list conversation, Rusty Russell proposed using variable-length bit encodings to reduce the size of transmitted data. Gregory Maxwell questioned the reliability and failure rate of this approach. Russell suggested using variable-length IDs and avoiding nonces to save time. However, Maxwell disagreed, stating that it would increase the cost of collisions. The conversation also touched on the idea of using UDP instead of TCP, but Russell was not convinced. Finally, Russell mentioned adding extra bits in the sender's coding to prevent collisions.Bitcoin developers are working on a new compact block relay system that will send transactions in smaller packets. This system aims to reduce bandwidth requirements and improve transmission speed between nodes. Instead of sending all transaction details, miners would only send a unique identifier for each transaction along with a list of excluded transactions. The receiving node would then request the full transaction information if needed.Pieter explained the length of short IDs required and suggested allowing the sender to choose. He also discussed techniques for reducing the number of bytes used for txids. Matt Corallo designed a BIP for compact block relay, introducing new data structures and a variable-length integer encoding. Short transaction IDs were introduced to represent a transaction without sending a full hash. Several heuristics can be used to improve performance, such as treating short txids that match multiple mempool transactions as non-matches and verifying against the sender's mempool to check for collisions.In another email thread, Peter R raised concerns about collision attacks, and Gregory Maxwell explained the likelihood of finding two transactions with the same initial 8 bytes of txid. Peter calculated the number of possible pairs in a set of transactions and questioned how to find the pair. Later, Peter suggested a faster way to scan the set using binary search. He agreed that the attack was feasible.The conversation also involved discussions about moderation and off-topic posts, with recommendations for sending further posts to appropriate mailing lists.Overall, the Bitcoin developers are exploring various techniques to improve the network's speed and efficiency, including reducing the size of transmitted data, using variable-length encodings, and optimizing transaction identification and relay.In a discussion on the bitcoin-dev mailing list, Tom and Gregory debated over the use of service bits for indicating additional peer-to-peer feature support. Gregory argued against using service bits for negating optional parameters, while Tom believed they were the right solution. They also discussed variable length encoding and collision attacks. Matt Corallo proposed a solution called Compact Block Relay BIP to address block propagation issues, but Tom criticized it as too complicated. The discussion also touched on the use of short transaction IDs and the acknowledgment of contributors to the document.The conversation shifted to the relay protocol and its optimization for propagation time rather than bandwidth. Two other proposals, xthin block and ILBT, were mentioned as potential solutions to decrease bandwidth usage, but further information was requested. Matt Corallo introduced his Compact Block Relay BIP, which aims to reduce data transmission. He explained the protocol flow, the calculation of short transaction IDs, and backward compatibility with older clients. The implementation of the BIP can be found on Github.A user reported testing the compact block relay design for a couple of weeks and observed a significant reduction in block-bytes sent and bandwidth spikes. The measurements showed that a high percentage of blocks were transferred with low latency, even without prediction.Matt Corallo's BIP-formatted design spec for compact block relay aimed to limit on-wire bytes during block relay. The latest version of the document can be found on Github. A user who tested the design reported over 96% reduction in block-bytes sent and decreased bandwidth spikes. The user's measurements showed that a significant percentage of blocks were transferred with low latency, even without prediction.The Compact Block Relay BIP designed by Matt Corallo aims to reduce block relay time and conserve bandwidth for nodes on the P2P network. The protocol includes two modes: high-bandwidth and low-bandwidth. Several new messages and inv types are introduced, along with the use of short transaction IDs. The protocol also includes new data structures and a variable-length integer encoding. Nodes are required to follow specific rules when requesting and sending compact blocks.The document discusses the protocol for handling missing transactions in the Bitcoin network. It emphasizes the importance of validating that the header properly commits to each transaction in the block before sending a cmpctblock message. When a requested blocktxn message is received, nodes are advised to reconstruct the full block. To improve block relay time, nodes are recommended to send a sendcmpct message with the first integer set to 1 to up to three peers based on their past performance in providing blocks quickly. Additionally, all nodes should send a sendcmpct message to all appropriate peers. Nodes with limited inbound bandwidth should prioritize using MSG_CMPCT_BLOCK/getblocktxn requests when requesting blocks. When sending cmpctblock messages, nodes should limit prefilledtxn to approximately 10KB of transactions. To optimize efficiency, nodes may choose one 2016-05-18T01:49:10+00:00 + In a Bitcoin developers mailing list conversation, Rusty Russell proposed using variable-length bit encodings to reduce the size of transmitted data. Gregory Maxwell questioned the reliability and failure rate of this approach. Russell suggested using variable-length IDs and avoiding nonces to save time. However, Maxwell disagreed, stating that it would increase the cost of collisions. The conversation also touched on the idea of using UDP instead of TCP, but Russell was not convinced. Finally, Russell mentioned adding extra bits in the sender's coding to prevent collisions.Bitcoin developers are working on a new compact block relay system that will send transactions in smaller packets. This system aims to reduce bandwidth requirements and improve transmission speed between nodes. Instead of sending all transaction details, miners would only send a unique identifier for each transaction along with a list of excluded transactions. The receiving node would then request the full transaction information if needed.Pieter explained the length of short IDs required and suggested allowing the sender to choose. He also discussed techniques for reducing the number of bytes used for txids. Matt Corallo designed a BIP for compact block relay, introducing new data structures and a variable-length integer encoding. Short transaction IDs were introduced to represent a transaction without sending a full hash. Several heuristics can be used to improve performance, such as treating short txids that match multiple mempool transactions as non-matches and verifying against the sender's mempool to check for collisions.In another email thread, Peter R raised concerns about collision attacks, and Gregory Maxwell explained the likelihood of finding two transactions with the same initial 8 bytes of txid. Peter calculated the number of possible pairs in a set of transactions and questioned how to find the pair. Later, Peter suggested a faster way to scan the set using binary search. He agreed that the attack was feasible.The conversation also involved discussions about moderation and off-topic posts, with recommendations for sending further posts to appropriate mailing lists.Overall, the Bitcoin developers are exploring various techniques to improve the network's speed and efficiency, including reducing the size of transmitted data, using variable-length encodings, and optimizing transaction identification and relay.In a discussion on the bitcoin-dev mailing list, Tom and Gregory debated over the use of service bits for indicating additional peer-to-peer feature support. Gregory argued against using service bits for negating optional parameters, while Tom believed they were the right solution. They also discussed variable length encoding and collision attacks. Matt Corallo proposed a solution called Compact Block Relay BIP to address block propagation issues, but Tom criticized it as too complicated. The discussion also touched on the use of short transaction IDs and the acknowledgment of contributors to the document.The conversation shifted to the relay protocol and its optimization for propagation time rather than bandwidth. Two other proposals, xthin block and ILBT, were mentioned as potential solutions to decrease bandwidth usage, but further information was requested. Matt Corallo introduced his Compact Block Relay BIP, which aims to reduce data transmission. He explained the protocol flow, the calculation of short transaction IDs, and backward compatibility with older clients. The implementation of the BIP can be found on Github.A user reported testing the compact block relay design for a couple of weeks and observed a significant reduction in block-bytes sent and bandwidth spikes. The measurements showed that a high percentage of blocks were transferred with low latency, even without prediction.Matt Corallo's BIP-formatted design spec for compact block relay aimed to limit on-wire bytes during block relay. The latest version of the document can be found on Github. A user who tested the design reported over 96% reduction in block-bytes sent and decreased bandwidth spikes. The user's measurements showed that a significant percentage of blocks were transferred with low latency, even without prediction.The Compact Block Relay BIP designed by Matt Corallo aims to reduce block relay time and conserve bandwidth for nodes on the P2P network. The protocol includes two modes: high-bandwidth and low-bandwidth. Several new messages and inv types are introduced, along with the use of short transaction IDs. The protocol also includes new data structures and a variable-length integer encoding. Nodes are required to follow specific rules when requesting and sending compact blocks.The document discusses the protocol for handling missing transactions in the Bitcoin network. It emphasizes the importance of validating that the header properly commits to each transaction in the block before sending a cmpctblock message. When a requested blocktxn message is received, nodes are advised to reconstruct the full block. To improve block relay time, nodes are recommended to send a sendcmpct message with the first integer set to 1 to up to three peers based on their past performance in providing blocks quickly. Additionally, all nodes should send a sendcmpct message to all appropriate peers. Nodes with limited inbound bandwidth should prioritize using MSG_CMPCT_BLOCK/getblocktxn requests when requesting blocks. When sending cmpctblock messages, nodes should limit prefilledtxn to approximately 10KB of transactions. To optimize efficiency, nodes may choose one - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_Making-AsicBoost-irrelevant.xml b/static/bitcoin-dev/May_2016/combined_Making-AsicBoost-irrelevant.xml index 6514def11a..52d5f0fca3 100644 --- a/static/bitcoin-dev/May_2016/combined_Making-AsicBoost-irrelevant.xml +++ b/static/bitcoin-dev/May_2016/combined_Making-AsicBoost-irrelevant.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Making AsicBoost irrelevant - 2023-08-01T18:19:58.950181+00:00 + 2025-09-26T15:35:19.710586+00:00 + python-feedgen Jorge Timón 2016-05-12 11:05:51+00:00 @@ -159,13 +160,13 @@ - python-feedgen + 2 Combined summary - Making AsicBoost irrelevant - 2023-08-01T18:19:58.950181+00:00 + 2025-09-26T15:35:19.710803+00:00 - In May 2016, the bitcoin-dev mailing list saw discussions on various topics related to the Bitcoin protocol and its potential optimizations. One topic debated was the possibility of forking the Bitcoin blockchain to create altcoins. Timo Hanke argued that forking would result in an altcoin, while another participant disagreed, stating that survival depends on demand. The discussion was suggested to be moved to the bitcoin-discuss forum for further exploration.Another discussion revolved around ASIC optimizations and whether they should be kept secret. Sergio Demian Lerner proposed that changing the protocol would imply the need for secrecy, but Tom Harding countered by pointing out that other optimizations are already kept secret. There was also debate about patent encumbrance in ASIC design and manufacturing, with Gregory Maxwell proposing a modification to the Proof-of-Work algorithm to neutralize the advantage of implementing AsicBoost. Peter Todd emphasized the importance of allowing the market to determine winners and losers.Timo Hanke accused Bitcoin Core developers of undermining his work through a blockchain fork, but Peter Todd noted that it is impossible to determine if Hanke's AsicBoost technology was used. Todd suggested miners negotiate lower licensing fees for the patent. The conversation also touched on the redesign of the Bitcoin block header and concerns over banning AsicBoost miners. Timo Hanke proposed a new mining header to address some issues related to the redesign.Overall, these discussions showcased different perspectives on the impact of optimizations, patents, and forks in the Bitcoin ecosystem. Centralization, fairness, and balancing innovation with network stability were key considerations. The developers and community members engaged in thoughtful exchanges, exploring various solutions and potential outcomes.The ongoing discussion in the Bitcoin community focused on the patented AsicBoost optimization and its potential implications. A major concern was the inability to determine if a block was mined with AsicBoost, making it challenging to assess its usage. This issue could lead to a chain fork if AsicBoost miners are banned, resulting in two co-existing Bitcoin blockchains. Sergio Demian Lerner proposed a redesign of the Bitcoin block header to increase nonce space and address this issue.The discussion also mentioned XORing bytes 64-76 with the first 12 bytes of the SHA2 midstate, but it was noted that this would only marginally increase the difficulty of finding a collision. It was recommended to restrict the use of 10 bytes to prevent timestamp rolling on-chip by hardware. There were differing opinions on the impact of banning AsicBoost, with concerns about hindering competition and decentralization, as well as centralizing the technology with one manufacturer.Opinions varied on the likelihood of a hard fork resulting from banning AsicBoost, with some believing it could lead to a chain fork, while others argued that AsicBoost blocks would be ignored until they stop being produced. The possibility of a difficulty adjustment on the AsicBoost chain was also mentioned, which could result in both chains growing at similar speeds. Changing the protocol to render AsicBoost useless was thoroughly discussed, with considerations for fairness and exploring alternative optimizations.Transparency and careful consideration of changes to the Bitcoin protocol were recognized as crucial for the health and stability of the network, as well as promoting fair competition and decentralization.In a post to the bitcoin-dev mailing list, Matt Corallo suggested several changes to render AsicBoost useless during a hard fork. These changes included fixing the version field, altering the merkle root, and swapping bytes within the merkle root and timestamp fields. Tier Nolan also proposed enhancing security by splitting the merkle root into two pieces. Peter Todd raised concerns about implementation without affecting existing mining hardware or SPV compatibility. The email referred to the HK agreement and provided links to additional discussions.The HK agreement aimed to make AsicBoost and similar optimizations ineffective through a hard fork. The goal was to find the best approach compatible with SPV and existing mining hardware. Changes from SPV clients were acceptable if necessary, but compatibility was essential. The Bitcoin Roundtable Consensus and discussions on the bitcoin-dev mailing list were valuable sources for further information, and Peter Todd was suggested as a contact for more details. 2016-05-12T11:05:51+00:00 + In May 2016, the bitcoin-dev mailing list saw discussions on various topics related to the Bitcoin protocol and its potential optimizations. One topic debated was the possibility of forking the Bitcoin blockchain to create altcoins. Timo Hanke argued that forking would result in an altcoin, while another participant disagreed, stating that survival depends on demand. The discussion was suggested to be moved to the bitcoin-discuss forum for further exploration.Another discussion revolved around ASIC optimizations and whether they should be kept secret. Sergio Demian Lerner proposed that changing the protocol would imply the need for secrecy, but Tom Harding countered by pointing out that other optimizations are already kept secret. There was also debate about patent encumbrance in ASIC design and manufacturing, with Gregory Maxwell proposing a modification to the Proof-of-Work algorithm to neutralize the advantage of implementing AsicBoost. Peter Todd emphasized the importance of allowing the market to determine winners and losers.Timo Hanke accused Bitcoin Core developers of undermining his work through a blockchain fork, but Peter Todd noted that it is impossible to determine if Hanke's AsicBoost technology was used. Todd suggested miners negotiate lower licensing fees for the patent. The conversation also touched on the redesign of the Bitcoin block header and concerns over banning AsicBoost miners. Timo Hanke proposed a new mining header to address some issues related to the redesign.Overall, these discussions showcased different perspectives on the impact of optimizations, patents, and forks in the Bitcoin ecosystem. Centralization, fairness, and balancing innovation with network stability were key considerations. The developers and community members engaged in thoughtful exchanges, exploring various solutions and potential outcomes.The ongoing discussion in the Bitcoin community focused on the patented AsicBoost optimization and its potential implications. A major concern was the inability to determine if a block was mined with AsicBoost, making it challenging to assess its usage. This issue could lead to a chain fork if AsicBoost miners are banned, resulting in two co-existing Bitcoin blockchains. Sergio Demian Lerner proposed a redesign of the Bitcoin block header to increase nonce space and address this issue.The discussion also mentioned XORing bytes 64-76 with the first 12 bytes of the SHA2 midstate, but it was noted that this would only marginally increase the difficulty of finding a collision. It was recommended to restrict the use of 10 bytes to prevent timestamp rolling on-chip by hardware. There were differing opinions on the impact of banning AsicBoost, with concerns about hindering competition and decentralization, as well as centralizing the technology with one manufacturer.Opinions varied on the likelihood of a hard fork resulting from banning AsicBoost, with some believing it could lead to a chain fork, while others argued that AsicBoost blocks would be ignored until they stop being produced. The possibility of a difficulty adjustment on the AsicBoost chain was also mentioned, which could result in both chains growing at similar speeds. Changing the protocol to render AsicBoost useless was thoroughly discussed, with considerations for fairness and exploring alternative optimizations.Transparency and careful consideration of changes to the Bitcoin protocol were recognized as crucial for the health and stability of the network, as well as promoting fair competition and decentralization.In a post to the bitcoin-dev mailing list, Matt Corallo suggested several changes to render AsicBoost useless during a hard fork. These changes included fixing the version field, altering the merkle root, and swapping bytes within the merkle root and timestamp fields. Tier Nolan also proposed enhancing security by splitting the merkle root into two pieces. Peter Todd raised concerns about implementation without affecting existing mining hardware or SPV compatibility. The email referred to the HK agreement and provided links to additional discussions.The HK agreement aimed to make AsicBoost and similar optimizations ineffective through a hard fork. The goal was to find the best approach compatible with SPV and existing mining hardware. Changes from SPV clients were acceptable if necessary, but compatibility was essential. The Bitcoin Roundtable Consensus and discussions on the bitcoin-dev mailing list were valuable sources for further information, and Peter Todd was suggested as a contact for more details. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_Making-UTXO-Set-Growth-Irrelevant-With-Low-Latency-Delayed-TXO-Commitments.xml b/static/bitcoin-dev/May_2016/combined_Making-UTXO-Set-Growth-Irrelevant-With-Low-Latency-Delayed-TXO-Commitments.xml index 30640a3189..03edbd42ea 100644 --- a/static/bitcoin-dev/May_2016/combined_Making-UTXO-Set-Growth-Irrelevant-With-Low-Latency-Delayed-TXO-Commitments.xml +++ b/static/bitcoin-dev/May_2016/combined_Making-UTXO-Set-Growth-Irrelevant-With-Low-Latency-Delayed-TXO-Commitments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments - 2023-08-01T18:22:55.519051+00:00 + 2025-09-26T15:35:07.026844+00:00 + python-feedgen Peter Todd 2016-05-22 08:55:33+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments - 2023-08-01T18:22:55.519051+00:00 + 2025-09-26T15:35:07.027020+00:00 - In a comparison of two proposals related to Bitcoin mining, Johnson Lau's proposal from 2015 suggests using the pruned UTXO set and 32 bytes per archived block for mining. However, there may be difficulty in spending archived outputs without knowing the status of other archived outputs from the same block. Lau proposes that third-party archival nodes can perform full re-scans of the blockchain to generate proof.Peter Todd claims to have a better proposal, where the dormant UTXO list is indexed by UTXO expiration order, making it impossible to verify the contents of that commitment without the global state of all UTXO data.The article discusses the issue of UTXO growth in Bitcoin and how it poses a threat to long-term decentralization. The current lack of consensus rules limiting UTXO growth can be attributed to factors such as lost coins, dust outputs, and non-Bitcoin-value-transfer use-cases. While Segregated Witness aims to reduce the UTXO set size, it may not discourage all UTXO growing behavior.To address this, TXO commitments propose a Merkle Mountain Range (MMR) that commits to the state of all transaction outputs, allowing less frequently accessed parts of the UTXO set to be archived while still providing a mechanism to spend those archived outputs. This improves storage efficiency and scalability, reducing the need for SPV wallet software to trust third parties.In a discussion about TXO commitments, Peter Todd explains how the proposed Merkle Mountain Range (MMR) allows new items to be appended to the tree with minimal storage requirements. Once an output is added to the TXO MMR, it is never removed, even if it is spent. Todd also discusses the implementation of a high-performance/low-latency delayed commitment full-node that stores the UTXO set, STXO set, TXO journal, and TXO MMR list. The TXO MMR implementation can store a large number of states with minimal data requirements, allowing for efficient pruning and unpruning of data.In another discussion, Todd argues against having both an append-only TXO and an append-only STXO, as indexing the STXO would be difficult due to the random position of new STXOs. However, if the STXO was indexed by txout creation order, it would be similar to Todd's proposed insertion-ordered TXO commitment. The article also mentions the availability of the MMR implementation with pruning support on Github and how the proofchains MMR scheme fixes the problem of proving the position in the tree.The article further discusses the proposed TXO commitments using Merkle Mountain Range (MMR), which allows for compactly proving the current state of an output. It explores the implementation details and benefits of using MMRs, such as reduced storage requirements and improved retrieval efficiency. However, there are still questions that need to be addressed, including how TXO commitments will interact with fraud proofs and whether incentivization schemes for miners can discount or ignore TXO commitment proof sizes. Optimization possibilities and the decision of UTXO archiving based on size or threshold are also mentioned.Overall, TXO commitments represent an improvement in Bitcoin's scalability and storage efficiency. The proposal addresses the issue of UTXO growth and provides mechanisms for efficient storage and retrieval of transaction outputs. However, further work and consideration are needed to fully implement and optimize TXO commitments, as well as address potential security concerns and interaction with fraud proofs.The article delves into the implementation of Transaction Output (TXO) commitments in Bitcoin's security model. It addresses the issue of TXO growth, which poses a challenge to the decentralization of Bitcoin. Currently, there are no rules limiting the size of the Unspent Transaction Output (UTXO) set, leading to significant memory expansion. The proposed solution is the Merkle Mountain Range (MMR), also known as TXO commitments, which offers a deterministic and indexable merkle tree structure. This allows for efficient appending of new items with minimal storage requirements.Implementing UTXO commitments without delaying commitment can adversely affect small miners' orphan rates, causing slower block validation. By introducing a delay, the latency-critical task becomes an average throughput problem. The TXO journal records spent outputs in the TXO MMR, and the MMR data is hashed to obtain the TXO commitment digest. While the TXO commitment calculation may have lower throughput compared to the UTXO only scheme, it offers tradeoffs that can mitigate the impact on validation throughput.The article highlights the challenges involved in implementing TXO commitments, such as determining the minimum age considered "assumed valid" and balancing political, social, and technical concerns. It suggests further work on optimizing the TXO commitment scheme to simplify complexity, prioritizing bitcoin value-transfer, and exploring alternative metrics/incentives for miner fairness and decentralization.The proposed high-performance/low-latency delayed commitment full-node implementation requires storing 2016-05-22T08:55:33+00:00 + In a comparison of two proposals related to Bitcoin mining, Johnson Lau's proposal from 2015 suggests using the pruned UTXO set and 32 bytes per archived block for mining. However, there may be difficulty in spending archived outputs without knowing the status of other archived outputs from the same block. Lau proposes that third-party archival nodes can perform full re-scans of the blockchain to generate proof.Peter Todd claims to have a better proposal, where the dormant UTXO list is indexed by UTXO expiration order, making it impossible to verify the contents of that commitment without the global state of all UTXO data.The article discusses the issue of UTXO growth in Bitcoin and how it poses a threat to long-term decentralization. The current lack of consensus rules limiting UTXO growth can be attributed to factors such as lost coins, dust outputs, and non-Bitcoin-value-transfer use-cases. While Segregated Witness aims to reduce the UTXO set size, it may not discourage all UTXO growing behavior.To address this, TXO commitments propose a Merkle Mountain Range (MMR) that commits to the state of all transaction outputs, allowing less frequently accessed parts of the UTXO set to be archived while still providing a mechanism to spend those archived outputs. This improves storage efficiency and scalability, reducing the need for SPV wallet software to trust third parties.In a discussion about TXO commitments, Peter Todd explains how the proposed Merkle Mountain Range (MMR) allows new items to be appended to the tree with minimal storage requirements. Once an output is added to the TXO MMR, it is never removed, even if it is spent. Todd also discusses the implementation of a high-performance/low-latency delayed commitment full-node that stores the UTXO set, STXO set, TXO journal, and TXO MMR list. The TXO MMR implementation can store a large number of states with minimal data requirements, allowing for efficient pruning and unpruning of data.In another discussion, Todd argues against having both an append-only TXO and an append-only STXO, as indexing the STXO would be difficult due to the random position of new STXOs. However, if the STXO was indexed by txout creation order, it would be similar to Todd's proposed insertion-ordered TXO commitment. The article also mentions the availability of the MMR implementation with pruning support on Github and how the proofchains MMR scheme fixes the problem of proving the position in the tree.The article further discusses the proposed TXO commitments using Merkle Mountain Range (MMR), which allows for compactly proving the current state of an output. It explores the implementation details and benefits of using MMRs, such as reduced storage requirements and improved retrieval efficiency. However, there are still questions that need to be addressed, including how TXO commitments will interact with fraud proofs and whether incentivization schemes for miners can discount or ignore TXO commitment proof sizes. Optimization possibilities and the decision of UTXO archiving based on size or threshold are also mentioned.Overall, TXO commitments represent an improvement in Bitcoin's scalability and storage efficiency. The proposal addresses the issue of UTXO growth and provides mechanisms for efficient storage and retrieval of transaction outputs. However, further work and consideration are needed to fully implement and optimize TXO commitments, as well as address potential security concerns and interaction with fraud proofs.The article delves into the implementation of Transaction Output (TXO) commitments in Bitcoin's security model. It addresses the issue of TXO growth, which poses a challenge to the decentralization of Bitcoin. Currently, there are no rules limiting the size of the Unspent Transaction Output (UTXO) set, leading to significant memory expansion. The proposed solution is the Merkle Mountain Range (MMR), also known as TXO commitments, which offers a deterministic and indexable merkle tree structure. This allows for efficient appending of new items with minimal storage requirements.Implementing UTXO commitments without delaying commitment can adversely affect small miners' orphan rates, causing slower block validation. By introducing a delay, the latency-critical task becomes an average throughput problem. The TXO journal records spent outputs in the TXO MMR, and the MMR data is hashed to obtain the TXO commitment digest. While the TXO commitment calculation may have lower throughput compared to the UTXO only scheme, it offers tradeoffs that can mitigate the impact on validation throughput.The article highlights the challenges involved in implementing TXO commitments, such as determining the minimum age considered "assumed valid" and balancing political, social, and technical concerns. It suggests further work on optimizing the TXO commitment scheme to simplify complexity, prioritizing bitcoin value-transfer, and exploring alternative metrics/incentives for miner fairness and decentralization.The proposed high-performance/low-latency delayed commitment full-node implementation requires storing - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_Proposal-to-update-BIP-32.xml b/static/bitcoin-dev/May_2016/combined_Proposal-to-update-BIP-32.xml index 9de537dbb0..b72b26bec9 100644 --- a/static/bitcoin-dev/May_2016/combined_Proposal-to-update-BIP-32.xml +++ b/static/bitcoin-dev/May_2016/combined_Proposal-to-update-BIP-32.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal to update BIP-32 - 2023-08-01T18:03:45.159425+00:00 + 2025-09-26T15:35:13.366784+00:00 + python-feedgen Gregory Maxwell 2016-05-08 11:09:45+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Proposal to update BIP-32 - 2023-08-01T18:03:45.159425+00:00 + 2025-09-26T15:35:13.366944+00:00 - On May 8, 2016, Pavol Rusnak reached out to the bitcoin-dev mailing list seeking Sipa's opinion on a proposed fix. Marek Palatinus also requested Sipa's input and expressed support for the proposal. However, since Sipa had not been active on the mailing list, he did not receive the message.In an email exchange between Eric Lombrozo and Jochen Hoenicke, they discussed the probability of a specific case of BIP32 triggering. They concluded that the likelihood of it happening is incredibly small at 2^-128. While many have been using BIP32 for years, some app developers feel that dealing with this level of complexity is not worth the effort. However, if handling the case is easy to implement and isolate in program flow, Lombrozo would be in favor of implementing a solution. The idea is to handle the problem in the library so app developers don't have to worry about missing addresses or ignore the issue. This could be achieved by having the library retry instead of returning an error.On April 21, 2016, Eric Lombrozo raised a concern on bitcoin-dev regarding the handling of cases where the BIP-32 derivation path is invalid. This issue is further complicated by limited software performing these checks. Additionally, even if a check is performed, handling the exception can be challenging as skipping may not always be an option. The motivation behind addressing this issue is to enable BIP-32 usage for non-secp256k1 curves such as the NIST P-256 curve with a chance of 2^-32. An example of an invalid BIP-32 path was found by Jochen at m/28578'/33941 derived from a hexadecimal seed.Jochen Hoenicke proposed an update to BIP-32, suggesting that if the computed hash is larger or equal to the prime or 0, the node should be considered invalid and skipped in the BIP-32 tree. He recommended modifying the procedure by repeating the hashing with slightly different input data until a valid private key is found. This way, the library will always return a valid node for all paths. Jochen believes that the chance of this affecting anyone is less than 10^-30 and that backward compatibility issues are minimal. However, many app developers feel that dealing with this complexity may not be worth the effort. Nevertheless, if the handling of this case is simple to implement and isolate in the program flow, Jochen is in favor of making changes.The proposal suggests updating BIP-32 to make it easier for developers to use. Currently, the specification requires all callers of CKDpriv or CKDpub to check for errors when the computed hash is larger or equal to the prime or zero, and handle these errors appropriately. This places an additional burden on application developers instead of being able to handle it within the BIP-32 library. Furthermore, it is unclear how to proceed if an intermediate node is missing. The suggestion is to repeat the hashing with slightly different input data until a valid private key is found. This approach ensures that the library always returns a valid node for all paths, avoiding issues encountered with the original version. The proposal also includes suggestions for updating the derivation functions and root node derivation from the seed. While there may be minimal backward compatibility issues, the author believes that the benefits of the update outweigh any potential consequences. The post concludes with questions regarding how to update the BIP and which algorithm is preferred for implementation. 2016-05-08T11:09:45+00:00 + On May 8, 2016, Pavol Rusnak reached out to the bitcoin-dev mailing list seeking Sipa's opinion on a proposed fix. Marek Palatinus also requested Sipa's input and expressed support for the proposal. However, since Sipa had not been active on the mailing list, he did not receive the message.In an email exchange between Eric Lombrozo and Jochen Hoenicke, they discussed the probability of a specific case of BIP32 triggering. They concluded that the likelihood of it happening is incredibly small at 2^-128. While many have been using BIP32 for years, some app developers feel that dealing with this level of complexity is not worth the effort. However, if handling the case is easy to implement and isolate in program flow, Lombrozo would be in favor of implementing a solution. The idea is to handle the problem in the library so app developers don't have to worry about missing addresses or ignore the issue. This could be achieved by having the library retry instead of returning an error.On April 21, 2016, Eric Lombrozo raised a concern on bitcoin-dev regarding the handling of cases where the BIP-32 derivation path is invalid. This issue is further complicated by limited software performing these checks. Additionally, even if a check is performed, handling the exception can be challenging as skipping may not always be an option. The motivation behind addressing this issue is to enable BIP-32 usage for non-secp256k1 curves such as the NIST P-256 curve with a chance of 2^-32. An example of an invalid BIP-32 path was found by Jochen at m/28578'/33941 derived from a hexadecimal seed.Jochen Hoenicke proposed an update to BIP-32, suggesting that if the computed hash is larger or equal to the prime or 0, the node should be considered invalid and skipped in the BIP-32 tree. He recommended modifying the procedure by repeating the hashing with slightly different input data until a valid private key is found. This way, the library will always return a valid node for all paths. Jochen believes that the chance of this affecting anyone is less than 10^-30 and that backward compatibility issues are minimal. However, many app developers feel that dealing with this complexity may not be worth the effort. Nevertheless, if the handling of this case is simple to implement and isolate in the program flow, Jochen is in favor of making changes.The proposal suggests updating BIP-32 to make it easier for developers to use. Currently, the specification requires all callers of CKDpriv or CKDpub to check for errors when the computed hash is larger or equal to the prime or zero, and handle these errors appropriately. This places an additional burden on application developers instead of being able to handle it within the BIP-32 library. Furthermore, it is unclear how to proceed if an intermediate node is missing. The suggestion is to repeat the hashing with slightly different input data until a valid private key is found. This approach ensures that the library always returns a valid node for all paths, avoiding issues encountered with the original version. The proposal also includes suggestions for updating the derivation functions and root node derivation from the seed. While there may be minimal backward compatibility issues, the author believes that the benefits of the update outweigh any potential consequences. The post concludes with questions regarding how to update the BIP and which algorithm is preferred for implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml b/static/bitcoin-dev/May_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml index b13c3518db..032175f96e 100644 --- a/static/bitcoin-dev/May_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml +++ b/static/bitcoin-dev/May_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC for BIP: Best Practices for Heterogeneous Input Script Transactions - 2023-08-01T17:49:34.520202+00:00 + 2025-09-26T15:35:15.483644+00:00 + python-feedgen Luke Dashjr 2016-05-26 00:00:37+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - RFC for BIP: Best Practices for Heterogeneous Input Script Transactions - 2023-08-01T17:49:34.520202+00:00 + 2025-09-26T15:35:15.483822+00:00 - On May 19, 2016, Kristov Atlas introduced a Bitcoin Improvement Proposal (BIP) known as BIP 126. This proposal suggests the implementation of Heterogenous Input Script Transactions (HITs), which allow for transactions to have multiple inputs with different scripts. It is important to note that transactions are not associated with specific Bitcoin addresses, but rather with inputs that spend from Unspent Transaction Outputs (UTXOs). Furthermore, it is uncommon for inputs to have identical scripts.The draft proposal titled "Best Practices for Heterogeneous Input Script Transactions (HITs)" aims to mitigate the negative impact on privacy and user protection protocols when transactions involve inputs with different scripts. The document outlines a set of guidelines to address the privacy concerns associated with HITs, while maximizing the effectiveness of user protection protocols. To achieve this, the specification proposes two forms of HITs: Standard form and alternate form.Standard form HIT transactions must adhere to specific rules. These rules include having an equal number of unique input/output scripts, ensuring all output scripts are unique, requiring at least one pair of outputs with equal value, and making sure the largest output in the transaction belongs to a set containing at least two identically-sized outputs. These requirements serve various purposes such as preventing address reuse, limiting the growth of the UTXO set, and optimizing behavior to make intentional HITs resemble unavoidable HITs.In cases where standard form HITs are not feasible, such as when HITs are unavoidable or the user does not possess sets of UTXOs with identical scripts, alternate form HITs can be employed. A compliant implementation can construct a transaction by finding the smallest combination of inputs whose value is equal to or greater than the desired spend. These inputs are then added to the transaction along with a spend output and change output. The process is repeated to create a second spend output and change output, with the change outputs adjusted as necessary to cover the transaction fee. The aim of this approach is to maximize the effectiveness of user-protecting protocols, minimize the adverse consequences of unavoidable HITs, and limit the impact on UTXO set growth.Non-compliant heterogenous input script transactions may be created if a user wishes to create an output larger than half the total size of their spendable outputs or if their inputs are not distributed in a manner that allows for the completion of the alternate form procedure.In conclusion, this document proposes a set of best practice guidelines to minimize the adverse privacy consequences of creating transactions with inputs composed of different scripts. The guidelines aim to maximize the effectiveness of protection protocols, minimize the negative consequences of unavoidable HITs, and limit the effect on the UTXO set growth. It defines terms related to HITs and provides rules for both standard form and alternate form HITs. The recommendations aim to enhance privacy and optimize the usage of HITs while ensuring compliance with the proposed guidelines. 2016-05-26T00:00:37+00:00 + On May 19, 2016, Kristov Atlas introduced a Bitcoin Improvement Proposal (BIP) known as BIP 126. This proposal suggests the implementation of Heterogenous Input Script Transactions (HITs), which allow for transactions to have multiple inputs with different scripts. It is important to note that transactions are not associated with specific Bitcoin addresses, but rather with inputs that spend from Unspent Transaction Outputs (UTXOs). Furthermore, it is uncommon for inputs to have identical scripts.The draft proposal titled "Best Practices for Heterogeneous Input Script Transactions (HITs)" aims to mitigate the negative impact on privacy and user protection protocols when transactions involve inputs with different scripts. The document outlines a set of guidelines to address the privacy concerns associated with HITs, while maximizing the effectiveness of user protection protocols. To achieve this, the specification proposes two forms of HITs: Standard form and alternate form.Standard form HIT transactions must adhere to specific rules. These rules include having an equal number of unique input/output scripts, ensuring all output scripts are unique, requiring at least one pair of outputs with equal value, and making sure the largest output in the transaction belongs to a set containing at least two identically-sized outputs. These requirements serve various purposes such as preventing address reuse, limiting the growth of the UTXO set, and optimizing behavior to make intentional HITs resemble unavoidable HITs.In cases where standard form HITs are not feasible, such as when HITs are unavoidable or the user does not possess sets of UTXOs with identical scripts, alternate form HITs can be employed. A compliant implementation can construct a transaction by finding the smallest combination of inputs whose value is equal to or greater than the desired spend. These inputs are then added to the transaction along with a spend output and change output. The process is repeated to create a second spend output and change output, with the change outputs adjusted as necessary to cover the transaction fee. The aim of this approach is to maximize the effectiveness of user-protecting protocols, minimize the adverse consequences of unavoidable HITs, and limit the impact on UTXO set growth.Non-compliant heterogenous input script transactions may be created if a user wishes to create an output larger than half the total size of their spendable outputs or if their inputs are not distributed in a manner that allows for the completion of the alternate form procedure.In conclusion, this document proposes a set of best practice guidelines to minimize the adverse privacy consequences of creating transactions with inputs composed of different scripts. The guidelines aim to maximize the effectiveness of protection protocols, minimize the negative consequences of unavoidable HITs, and limit the effect on the UTXO set growth. It defines terms related to HITs and provides rules for both standard form and alternate form HITs. The recommendations aim to enhance privacy and optimize the usage of HITs while ensuring compliance with the proposed guidelines. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_p2p-authentication-and-encryption-BIPs.xml b/static/bitcoin-dev/May_2016/combined_p2p-authentication-and-encryption-BIPs.xml index 614f155472..571a867b47 100644 --- a/static/bitcoin-dev/May_2016/combined_p2p-authentication-and-encryption-BIPs.xml +++ b/static/bitcoin-dev/May_2016/combined_p2p-authentication-and-encryption-BIPs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - p2p authentication and encryption BIPs - 2023-08-01T18:00:13.282875+00:00 + 2025-09-26T15:35:02.794848+00:00 + python-feedgen Jonas Schnelli 2016-05-25 09:36:24+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - p2p authentication and encryption BIPs - 2023-08-01T18:00:13.282875+00:00 + 2025-09-26T15:35:02.795034+00:00 - The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, 2016-05-25T09:36:24+00:00 + The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml b/static/bitcoin-dev/May_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml index 2a579f4039..b246447e69 100644 --- a/static/bitcoin-dev/May_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml +++ b/static/bitcoin-dev/May_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - segwit subsidy and multi-sender (coinjoin) transactions - 2023-08-01T18:04:29.439589+00:00 + 2025-09-26T15:35:00.682618+00:00 + python-feedgen Peter Todd 2016-05-03 02:05:11+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - segwit subsidy and multi-sender (coinjoin) transactions - 2023-08-01T18:04:29.440590+00:00 + 2025-09-26T15:35:00.682746+00:00 - Kristov Atlas, a developer, has shared a sample of 16 transaction IDs from the BitcoinTalk thread on JoinMarket. These transactions reveal an average ratio of 1.38 outputs to inputs. Atlas points out that this situation is unsustainable because eventually the change needs to be combined again or else the unspent transaction outputs (UTXOs) will not get spent. However, the advantage of segwit discount for CoinJoin transactions is that it makes spending UTXOs cheaper and recovers funds that would otherwise be lost to dust.In a discussion on bitcoin-dev about the impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones, Kristov Atlas raises the question of whether this subsidy serves as a financial disincentive against CoinJoin transactions. It is noted that CoinJoin transactions do not necessitate any specific behavior that would be affected by this subsidy. Normal transactions spend a coin and create a payment of a specified amount along with change, and CoinJoins are no different in this regard. While users may sometimes split their outputs to enhance privacy, resulting in the "more outputs" effect, this alone does not increase costs under segwit. The total cost for a user to create an output paying themselves includes both the cost of creation and the eventual cost of spending it. Segwit's cost calculation improvements shift some relative cost from spending to creation, but the same users pay for both. It is important to consider where other transactions are when evaluating the output to input ratio for self-sends. For example, in block 409711, there is an average of 1.4647 outputs per input, although this figure varies across different blocks.Regarding the sample of the 16 transaction IDs posted in the JoinMarket thread on BitcoinTalk, which showed an average ratio of 1.38 outputs to inputs, it is pointed out that it is strange to state this as a fact right after providing data that disproves it. The author also requests that people refrain from discussing Schnorr signatures since they are not currently part of any immediate roadmap. However, it is mentioned that Schnorr signatures for Bitcoin have been in development for years and are one of the first proposed uses of segwit versioning. Schnorr multisignature signature aggregates would significantly reduce the cost of CoinJoin transactions, and if there were any disincentive, it would be eliminated by planned use of segwit versioning.The impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones has raised questions. This subsidy makes signature data, which does not affect the size of the unspent transaction output (UTXO) set, 75% cheaper than data that does impact the UTXO set size. The expectation is that users will prefer transactions that minimize the impact on the UTXO set in order to reduce fees, and developers will design new features that also minimize this impact. While this could potentially act as a disincentive against CoinJoin transactions, it remains unclear if there is any evidence to support this claim. It is worth noting that traditional CoinJoin transactions typically create around two UTXOs for every one they consume, unless address reuse is involved. The author emphasizes that they do not wish to discuss Schnorr signatures in replies, as they are not currently part of any immediate roadmap. 2016-05-03T02:05:11+00:00 + Kristov Atlas, a developer, has shared a sample of 16 transaction IDs from the BitcoinTalk thread on JoinMarket. These transactions reveal an average ratio of 1.38 outputs to inputs. Atlas points out that this situation is unsustainable because eventually the change needs to be combined again or else the unspent transaction outputs (UTXOs) will not get spent. However, the advantage of segwit discount for CoinJoin transactions is that it makes spending UTXOs cheaper and recovers funds that would otherwise be lost to dust.In a discussion on bitcoin-dev about the impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones, Kristov Atlas raises the question of whether this subsidy serves as a financial disincentive against CoinJoin transactions. It is noted that CoinJoin transactions do not necessitate any specific behavior that would be affected by this subsidy. Normal transactions spend a coin and create a payment of a specified amount along with change, and CoinJoins are no different in this regard. While users may sometimes split their outputs to enhance privacy, resulting in the "more outputs" effect, this alone does not increase costs under segwit. The total cost for a user to create an output paying themselves includes both the cost of creation and the eventual cost of spending it. Segwit's cost calculation improvements shift some relative cost from spending to creation, but the same users pay for both. It is important to consider where other transactions are when evaluating the output to input ratio for self-sends. For example, in block 409711, there is an average of 1.4647 outputs per input, although this figure varies across different blocks.Regarding the sample of the 16 transaction IDs posted in the JoinMarket thread on BitcoinTalk, which showed an average ratio of 1.38 outputs to inputs, it is pointed out that it is strange to state this as a fact right after providing data that disproves it. The author also requests that people refrain from discussing Schnorr signatures since they are not currently part of any immediate roadmap. However, it is mentioned that Schnorr signatures for Bitcoin have been in development for years and are one of the first proposed uses of segwit versioning. Schnorr multisignature signature aggregates would significantly reduce the cost of CoinJoin transactions, and if there were any disincentive, it would be eliminated by planned use of segwit versioning.The impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones has raised questions. This subsidy makes signature data, which does not affect the size of the unspent transaction output (UTXO) set, 75% cheaper than data that does impact the UTXO set size. The expectation is that users will prefer transactions that minimize the impact on the UTXO set in order to reduce fees, and developers will design new features that also minimize this impact. While this could potentially act as a disincentive against CoinJoin transactions, it remains unclear if there is any evidence to support this claim. It is worth noting that traditional CoinJoin transactions typically create around two UTXOs for every one they consume, unless address reuse is involved. The author emphasizes that they do not wish to discuss Schnorr signatures in replies, as they are not currently part of any immediate roadmap. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_A-BIP-proposal-for-conveniently-referring-to-confirmed-transactions.xml b/static/bitcoin-dev/May_2017/combined_A-BIP-proposal-for-conveniently-referring-to-confirmed-transactions.xml index 61db6ba1a0..5fb8f13687 100644 --- a/static/bitcoin-dev/May_2017/combined_A-BIP-proposal-for-conveniently-referring-to-confirmed-transactions.xml +++ b/static/bitcoin-dev/May_2017/combined_A-BIP-proposal-for-conveniently-referring-to-confirmed-transactions.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - A BIP proposal for conveniently referring to confirmed transactions - 2023-08-01T20:44:09.769883+00:00 - - Tom Zander 2017-07-17 13:40:29+00:00 - - - Велеслав 2017-07-15 05:00:18+00:00 - - - Clark Moody 2017-07-14 18:43:37+00:00 - - - Велеслав 2017-05-23 15:30:58+00:00 - + 2025-09-26T15:57:37.105943+00:00 + python-feedgen + + + [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions Велеслав + 2017-05-23T15:30:00.000Z + + + Clark Moody + 2017-07-14T18:43:00.000Z + + + Велеслав + 2017-07-15T05:00:00.000Z + + + Tom Zander + 2017-07-17T13:40:00.000Z + + - python-feedgen + 2 Combined summary - A BIP proposal for conveniently referring to confirmed transactions - 2023-08-01T20:44:09.769883+00:00 + 2025-09-26T15:57:37.106660+00:00 - In a bitcoin-dev discussion, Clark Moody expressed understanding for keeping all reference strings to the 14-character version by keeping the data payload to 40 bits. However, he questioned the point of having a user-readable tx-reference. He argued that in the actual blockchain, the txid would still be used and a less readable but more compact format is useful because space optimization is prioritized over human comprehension. Moody suggested that one possible use case could be wanting to spend a specific output or reporting a specific transaction as proof to a merchant or tax office. However, for any such use cases, an individual would still need to provide a proof of holding the private keys. Therefore, using a human-readable format does not make much sense since a cryptographic proof of ownership cannot be read no matter how hard one tries.Tom Zander asked for one or two use cases where human-readable formats might be useful. The message is a response to a review of a proposal by Clark Moody. The proposal involves conveniently referring to confirmed transactions. The pull request can be found at https://github.com/bitcoin/bips/pull/555 while the proposed specification is at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Position_References.mediawiki.The author of the message notes that various variable length encodings were considered and found to have too high an overhead. Instead, the concept of "Display Formats" was proposed. These formats are tailored to specific purposes and can be optimized to a much greater extent. In case there is a hard fork extending Bitcoin's block transaction capacity beyond 8191 transactions, a "Bitcoin Display Format 1" will be defined. In case of a Drive-Chain style extension or other indirect extension to Bitcoin's transactional capacity, a new magic value will be created to define a tailored Display Format for the new system. The author believes that it makes no sense to define an undefined format now. A new format can be defined in the future when the needs of Bitcoin users can be better understood.Clark Moody suggests that the proposal places artificial limitations on the format. The author responds that a variable-length encoding similar to Bitcoin's variable ints could be used. Bit-packing to the 40 bits might also be overkill as one bit-packed byte could suffice. The protocol version would occupy the first two bits, supporting values 0-3.In a GitHub discussion, users expressed concern over the limitations of the current format for reference strings. The 14-character version is desirable, but it restricts the data payload to 40 bits, limiting the format to year 2048 and 8191 transactions. While Version 1 encoding may address this issue, current blocks are still approaching the transaction limit.A suggestion was made to use variable-length encoding similar to Bitcoin's variable ints, which would allow for a format that can handle very large blocks and future growth. Additionally, it was noted that Bech32 reference libraries can encode from byte arrays into the base-5 arrays native to Bech32, making bit-packing to the 40 bits unnecessary. Instead, one bit-packed byte could be used to start, with the first two bits indicating the protocol version (0-3). Overall, there are concerns about the artificial limitations of the current format and potential solutions to address them.The author has proposed a BIP that suggests a way to reference transactions that have been successfully inserted into the blockchain. The format of the proposal utilizes Bech32 encoding and is designed to be both short and useful for human usage. The draft also includes a C reference implementation. The author has taken special care to ensure that this BIP can be extended naturally to support future upgrades to Bitcoin, Bitcoin Sidechains, or even other blockchain projects. However, the current draft only specifies support for the Bitcoin Main Chain and the Test Network. The author hopes that the bitcoin-development mailing list participants find this draft BIP interesting and useful. The BIP can be read in full at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Postion_References.mediawiki. If assigned with a BIP number, some small updates to the specification will be made in accommodation. 2017-07-17T13:40:29+00:00 + In a bitcoin-dev discussion, Clark Moody expressed understanding for keeping all reference strings to the 14-character version by keeping the data payload to 40 bits. However, he questioned the point of having a user-readable tx-reference. He argued that in the actual blockchain, the txid would still be used and a less readable but more compact format is useful because space optimization is prioritized over human comprehension. Moody suggested that one possible use case could be wanting to spend a specific output or reporting a specific transaction as proof to a merchant or tax office. However, for any such use cases, an individual would still need to provide a proof of holding the private keys. Therefore, using a human-readable format does not make much sense since a cryptographic proof of ownership cannot be read no matter how hard one tries.Tom Zander asked for one or two use cases where human-readable formats might be useful. The message is a response to a review of a proposal by Clark Moody. The proposal involves conveniently referring to confirmed transactions. The pull request can be found at https://github.com/bitcoin/bips/pull/555 while the proposed specification is at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Position_References.mediawiki.The author of the message notes that various variable length encodings were considered and found to have too high an overhead. Instead, the concept of "Display Formats" was proposed. These formats are tailored to specific purposes and can be optimized to a much greater extent. In case there is a hard fork extending Bitcoin's block transaction capacity beyond 8191 transactions, a "Bitcoin Display Format 1" will be defined. In case of a Drive-Chain style extension or other indirect extension to Bitcoin's transactional capacity, a new magic value will be created to define a tailored Display Format for the new system. The author believes that it makes no sense to define an undefined format now. A new format can be defined in the future when the needs of Bitcoin users can be better understood.Clark Moody suggests that the proposal places artificial limitations on the format. The author responds that a variable-length encoding similar to Bitcoin's variable ints could be used. Bit-packing to the 40 bits might also be overkill as one bit-packed byte could suffice. The protocol version would occupy the first two bits, supporting values 0-3.In a GitHub discussion, users expressed concern over the limitations of the current format for reference strings. The 14-character version is desirable, but it restricts the data payload to 40 bits, limiting the format to year 2048 and 8191 transactions. While Version 1 encoding may address this issue, current blocks are still approaching the transaction limit.A suggestion was made to use variable-length encoding similar to Bitcoin's variable ints, which would allow for a format that can handle very large blocks and future growth. Additionally, it was noted that Bech32 reference libraries can encode from byte arrays into the base-5 arrays native to Bech32, making bit-packing to the 40 bits unnecessary. Instead, one bit-packed byte could be used to start, with the first two bits indicating the protocol version (0-3). Overall, there are concerns about the artificial limitations of the current format and potential solutions to address them.The author has proposed a BIP that suggests a way to reference transactions that have been successfully inserted into the blockchain. The format of the proposal utilizes Bech32 encoding and is designed to be both short and useful for human usage. The draft also includes a C reference implementation. The author has taken special care to ensure that this BIP can be extended naturally to support future upgrades to Bitcoin, Bitcoin Sidechains, or even other blockchain projects. However, the current draft only specifies support for the Bitcoin Main Chain and the Test Network. The author hopes that the bitcoin-development mailing list participants find this draft BIP interesting and useful. The BIP can be read in full at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Postion_References.mediawiki. If assigned with a BIP number, some small updates to the specification will be made in accommodation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_A-BIP-proposal-for-segwit-addresses.xml b/static/bitcoin-dev/May_2017/combined_A-BIP-proposal-for-segwit-addresses.xml index 16005d5210..4606ba13d8 100644 --- a/static/bitcoin-dev/May_2017/combined_A-BIP-proposal-for-segwit-addresses.xml +++ b/static/bitcoin-dev/May_2017/combined_A-BIP-proposal-for-segwit-addresses.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - A BIP proposal for segwit addresses - 2023-08-01T19:50:37.233258+00:00 - - Russell O'Connor 2018-07-26 14:31:30+00:00 - - - Russell O'Connor 2018-07-26 13:43:19+00:00 - - - Pieter Wuille 2017-05-20 20:13:13+00:00 - - - Peter Todd 2017-05-07 22:34:29+00:00 - - - Pieter Wuille 2017-05-07 21:39:14+00:00 - - - Lucas Ontivero 2017-03-30 04:50:54+00:00 - - - Andreas Schildbach 2017-03-29 10:07:40+00:00 - - - Peter Todd 2017-03-21 19:14:54+00:00 - - - Andreas Schildbach 2017-03-21 16:16:30+00:00 - - - Pieter Wuille 2017-03-20 21:35:08+00:00 - + 2025-09-26T15:57:45.637812+00:00 + python-feedgen + + + [bitcoin-dev] A BIP proposal for segwit addresses Pieter Wuille + 2017-03-20T21:35:00.000Z + + + Andreas Schildbach + 2017-03-21T16:16:00.000Z + + + Peter Todd + 2017-03-21T19:14:00.000Z + + + Andreas Schildbach + 2017-03-29T10:07:00.000Z + + + Lucas Ontivero + 2017-03-30T04:50:00.000Z + + + Pieter Wuille + 2017-05-07T21:39:00.000Z + + + Peter Todd + 2017-05-07T22:34:00.000Z + + + Pieter Wuille + 2017-05-20T20:13:00.000Z + + + Russell O'Connor + 2018-07-26T13:43:00.000Z + + + Russell O'Connor + 2018-07-26T14:31:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - A BIP proposal for segwit addresses - 2023-08-01T19:50:37.233258+00:00 + 2025-09-26T15:57:45.639135+00:00 - In an email exchange, Russell O'Connor suggested adding a note to the BIP (Bitcoin Improvement Proposal) stating that the Human Readable Part (HRP) should be specified in lowercase or at least mentioning that uppercase and lowercase HRPs are considered equivalent and will be converted to lowercase during validation. The HRP is required to contain 1 to 83 US-ASCII characters, with each character having a value in the range of 33-126, and its validity may be further restricted by specific applications. Bech32, which is used for encoding BTC addresses, forbids mixed-case and converts everything to lowercase, so it is advisable to warn against using uppercase in the HRP. This change would not be normative.Pieter Wuille has requested a BIP number assignment for his proposal, which is available on GitHub under the name BIP173. The proposal aims to introduce a commonly recognizable format for BTC addresses that has good properties for all use cases. It emphasizes the importance of addressing all places where humans interact with addresses, including voice transmission and QR codes. However, compactness is not the primary goal of the BIP.The discussion on the Bitcoin-dev mailing list centered around the ability of non-native English speakers to communicate BTC addresses with English speakers. Peter Todd explained that it is not a binary issue as some non-native speakers may know how to pronounce numbers or alphabetical characters but not special characters. Two new reference implementations (Haskell and Rust) have been contributed recently, and C++ and Go implementations are in progress. Peter Todd also shared his experience of implementing Bech32 encoding for a non-BTC use-case and found it straightforward.The writer is considering whether to respond to a mail list or make a comment in a commit file. They discuss the motivation behind this, which is the lack of support for big numbers in most programming languages when performing mathematical operations required by BIP58. The writer also questions the need for a new encoding format and raises concerns about potential confusion. They note that if a new type of address can be encoded with Bech32 in the future, a new address type may be needed regardless. They argue against using non-alphanumeric characters in addresses for certain contexts, such as filenames, and suggest using something like "Base 64url" or ideally Base 94 for shorter QR codes.In a recent discussion on the Bitcoin-dev mailing list, Andreas Schildbach suggested using Base 43 for QR code encoding in Bitcoin Wallet to make addresses shorter. However, Peter Todd responded with concerns about the downsides of using non-alphanumeric characters in addresses, such as making them difficult to use in various contexts and not being familiar to non-English speaking users. He also questioned the need for transmitting addresses via voice communication. Todd further explained that when used for URLs, Base 32 (as well as Base 43) actually makes QR codes bigger due to the characters used for URL parameters. To make them shorter, he suggested using something like "Base 64url" or preferably Base 94 which includes all printable ASCII characters.Andreas Schildbach's suggestion of using Base 43 for QR code encoding in Bitcoin Wallet to shorten addresses may not be efficient due to the downsides associated with non-alphanumeric characters. These characters can complicate usage in different contexts and may not be familiar to non-English-speaking users. The suggestion was made as an alternative to using Base 32, which is seen as less efficient than the QR code alphanumeric mode that accommodates 44 characters. Peter Todd advises reviewing the "Rational" section of the BIP for more details.Pieter Wuille proposed a new BIP for native SegWit addresses to replace BIP 142 on March 20, 2017. These addresses are optional but offer better efficiency, flexibility, and user-friendliness. The format uses a simple checksum algorithm with strong error detection properties and is based on Base 32 encoding. Reference code in several languages, as well as a website demonstrating it, are included. The text of the proposal can be found on GitHub.Pieter's proposal for native SegWit addresses aims to replace the current BIP 142. These addresses, while not required for SegWit, provide improved efficiency, flexibility, and user-friendliness. They utilize a base 32 encoding format with a simple checksum algorithm that ensures strong error detection. The proposal includes reference code in multiple programming languages and a website for demonstration purposes. The full text of the proposal can be accessed on GitHub. 2018-07-26T14:31:30+00:00 + In an email exchange, Russell O'Connor suggested adding a note to the BIP (Bitcoin Improvement Proposal) stating that the Human Readable Part (HRP) should be specified in lowercase or at least mentioning that uppercase and lowercase HRPs are considered equivalent and will be converted to lowercase during validation. The HRP is required to contain 1 to 83 US-ASCII characters, with each character having a value in the range of 33-126, and its validity may be further restricted by specific applications. Bech32, which is used for encoding BTC addresses, forbids mixed-case and converts everything to lowercase, so it is advisable to warn against using uppercase in the HRP. This change would not be normative.Pieter Wuille has requested a BIP number assignment for his proposal, which is available on GitHub under the name BIP173. The proposal aims to introduce a commonly recognizable format for BTC addresses that has good properties for all use cases. It emphasizes the importance of addressing all places where humans interact with addresses, including voice transmission and QR codes. However, compactness is not the primary goal of the BIP.The discussion on the Bitcoin-dev mailing list centered around the ability of non-native English speakers to communicate BTC addresses with English speakers. Peter Todd explained that it is not a binary issue as some non-native speakers may know how to pronounce numbers or alphabetical characters but not special characters. Two new reference implementations (Haskell and Rust) have been contributed recently, and C++ and Go implementations are in progress. Peter Todd also shared his experience of implementing Bech32 encoding for a non-BTC use-case and found it straightforward.The writer is considering whether to respond to a mail list or make a comment in a commit file. They discuss the motivation behind this, which is the lack of support for big numbers in most programming languages when performing mathematical operations required by BIP58. The writer also questions the need for a new encoding format and raises concerns about potential confusion. They note that if a new type of address can be encoded with Bech32 in the future, a new address type may be needed regardless. They argue against using non-alphanumeric characters in addresses for certain contexts, such as filenames, and suggest using something like "Base 64url" or ideally Base 94 for shorter QR codes.In a recent discussion on the Bitcoin-dev mailing list, Andreas Schildbach suggested using Base 43 for QR code encoding in Bitcoin Wallet to make addresses shorter. However, Peter Todd responded with concerns about the downsides of using non-alphanumeric characters in addresses, such as making them difficult to use in various contexts and not being familiar to non-English speaking users. He also questioned the need for transmitting addresses via voice communication. Todd further explained that when used for URLs, Base 32 (as well as Base 43) actually makes QR codes bigger due to the characters used for URL parameters. To make them shorter, he suggested using something like "Base 64url" or preferably Base 94 which includes all printable ASCII characters.Andreas Schildbach's suggestion of using Base 43 for QR code encoding in Bitcoin Wallet to shorten addresses may not be efficient due to the downsides associated with non-alphanumeric characters. These characters can complicate usage in different contexts and may not be familiar to non-English-speaking users. The suggestion was made as an alternative to using Base 32, which is seen as less efficient than the QR code alphanumeric mode that accommodates 44 characters. Peter Todd advises reviewing the "Rational" section of the BIP for more details.Pieter Wuille proposed a new BIP for native SegWit addresses to replace BIP 142 on March 20, 2017. These addresses are optional but offer better efficiency, flexibility, and user-friendliness. The format uses a simple checksum algorithm with strong error detection properties and is based on Base 32 encoding. Reference code in several languages, as well as a website demonstrating it, are included. The text of the proposal can be found on GitHub.Pieter's proposal for native SegWit addresses aims to replace the current BIP 142. These addresses, while not required for SegWit, provide improved efficiency, flexibility, and user-friendliness. They utilize a base 32 encoding format with a simple checksum algorithm that ensures strong error detection. The proposal includes reference code in multiple programming languages and a website for demonstration purposes. The full text of the proposal can be accessed on GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_A-Method-for-Computing-Merkle-Roots-of-Annotated-Binary-Trees.xml b/static/bitcoin-dev/May_2017/combined_A-Method-for-Computing-Merkle-Roots-of-Annotated-Binary-Trees.xml index df3385cc30..4e226db93d 100644 --- a/static/bitcoin-dev/May_2017/combined_A-Method-for-Computing-Merkle-Roots-of-Annotated-Binary-Trees.xml +++ b/static/bitcoin-dev/May_2017/combined_A-Method-for-Computing-Merkle-Roots-of-Annotated-Binary-Trees.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - A Method for Computing Merkle Roots of Annotated Binary Trees - 2023-08-01T20:42:00.085812+00:00 - - Peter Todd 2017-06-27 04:13:08+00:00 - - - Russell O'Connor 2017-06-01 15:10:56+00:00 - - - Peter Todd 2017-05-29 16:10:59+00:00 - - - Russell O'Connor 2017-05-29 14:55:37+00:00 - - - Peter Todd 2017-05-28 08:26:24+00:00 - - - Russell O'Connor 2017-05-27 22:07:07+00:00 - - - Peter Todd 2017-05-27 17:41:38+00:00 - - - Bram Cohen 2017-05-23 06:06:07+00:00 - - - Russell O'Connor 2017-05-22 22:32:38+00:00 - - - Peter Todd 2017-05-22 14:05:48+00:00 - - - Russell O'Connor 2017-05-22 07:05:49+00:00 - + 2025-09-26T15:58:28.331399+00:00 + python-feedgen + + + [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees Russell O'Connor + 2017-05-22T07:05:00.000Z + + + Peter Todd + 2017-05-22T14:05:00.000Z + + + Russell O'Connor + 2017-05-22T22:32:00.000Z + + + Bram Cohen + 2017-05-23T06:06:00.000Z + + + Peter Todd + 2017-05-27T17:41:00.000Z + + + Russell O'Connor + 2017-05-27T22:07:00.000Z + + + Peter Todd + 2017-05-28T08:26:00.000Z + + + Russell O'Connor + 2017-05-29T14:55:00.000Z + + + Peter Todd + 2017-05-29T16:10:00.000Z + + + Russell O'Connor + 2017-06-01T15:10:00.000Z + + + Peter Todd + 2017-06-27T04:13:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - A Method for Computing Merkle Roots of Annotated Binary Trees - 2023-08-01T20:42:00.086817+00:00 + 2025-09-26T15:58:28.332736+00:00 - In a series of email exchanges between Russell O'Connor and Peter Todd, concerns were raised about the security of the SHA-256 compression function with chosen initial values in relation to pruned trees. Todd acknowledged these concerns and stated that there is no reason to believe that the compression function will be secure under such circumstances. It was also mentioned that fixed points can be found for the SHA256 compression function if the attacker can control the initial value.The discussion also involved a proposal for the Merkle tree data structure. O'Connor suggested using the hash of tags in the first argument of the Sha256Compress function as a way to avoid the need for SHA256's padding while still maintaining the Merkle-Damgård property. However, Todd pointed out that this approach is similar to using SHA256 directly and proposed computing the midstate sha256Compress(IV, t) instead of sha256(t). They also discussed the idea of using safe tags to prevent collisions between the Sha256 and MerkleRoot functions, but Todd argued against depending on tag uniqueness as it could lead to unintended collisions. Ultimately, Todd concluded that if a system is designed where collisions don't matter, then collisions between the sha256 and merkleroot functions won't matter either.Another point of discussion involved the security of the SHA-256 compression function with chosen initial values in pruned trees. O'Connor proposed a solution involving putting the hash of the tags into Sha256Compress's first argument, which would hold the Merkle-Damgard property under certain conditions but would lose the ability to avoid collisions between the Sha256 and MerkleRoot functions using safe tags. Todd noted that this issue arises because in pruned trees, the left merkleRoot cannot be guaranteed to be a midstate of a genuine SHA256 hash.In another email conversation, O'Connor and Todd discussed the math operations used in creating a Merkle Root. O'Connor used the symbol "⋅" to represent concatenation and "×" to represent the Cartesian product. Todd asked for clarification on the specific meaning of the Cartesian product, to which O'Connor defined it as pairs of A and B in the sense of type theory used in languages like Standard ML or Haskell. They also discussed the sha256Compress function, its arguments, and its return value.In a discussion on the Bitcoin development mailing list, O'Connor described the SHA256 compression function used in creating Merkle Tries. He suggested a construction where values are already hashed down to 256 bits before being passed in, and tags are used to determine the type of node. This approach improves performance by skipping unary hashes, and there seems to be no downside as long as tags are inexpensive.The email exchanges between O'Connor and Todd revolved around the technical details of Bitcoin's cryptography, particularly regarding the math operations and functions used in the computation of MerkleRoot.In summary, the discussions focused on concerns about the security of the SHA-256 compression function with chosen initial values in pruned trees and proposed solutions involving the use of hash tags and different math operations. The conversations also delved into the specifics of the sha256Compress function and its arguments, as well as the Merkle-Damgård property and the use of safe tags to prevent collisions. Overall, the emails provided detailed insights into the complexities of Bitcoin's cryptography and its Merkle tree data structure. 2017-06-27T04:13:08+00:00 + In a series of email exchanges between Russell O'Connor and Peter Todd, concerns were raised about the security of the SHA-256 compression function with chosen initial values in relation to pruned trees. Todd acknowledged these concerns and stated that there is no reason to believe that the compression function will be secure under such circumstances. It was also mentioned that fixed points can be found for the SHA256 compression function if the attacker can control the initial value.The discussion also involved a proposal for the Merkle tree data structure. O'Connor suggested using the hash of tags in the first argument of the Sha256Compress function as a way to avoid the need for SHA256's padding while still maintaining the Merkle-Damgård property. However, Todd pointed out that this approach is similar to using SHA256 directly and proposed computing the midstate sha256Compress(IV, t) instead of sha256(t). They also discussed the idea of using safe tags to prevent collisions between the Sha256 and MerkleRoot functions, but Todd argued against depending on tag uniqueness as it could lead to unintended collisions. Ultimately, Todd concluded that if a system is designed where collisions don't matter, then collisions between the sha256 and merkleroot functions won't matter either.Another point of discussion involved the security of the SHA-256 compression function with chosen initial values in pruned trees. O'Connor proposed a solution involving putting the hash of the tags into Sha256Compress's first argument, which would hold the Merkle-Damgard property under certain conditions but would lose the ability to avoid collisions between the Sha256 and MerkleRoot functions using safe tags. Todd noted that this issue arises because in pruned trees, the left merkleRoot cannot be guaranteed to be a midstate of a genuine SHA256 hash.In another email conversation, O'Connor and Todd discussed the math operations used in creating a Merkle Root. O'Connor used the symbol "⋅" to represent concatenation and "×" to represent the Cartesian product. Todd asked for clarification on the specific meaning of the Cartesian product, to which O'Connor defined it as pairs of A and B in the sense of type theory used in languages like Standard ML or Haskell. They also discussed the sha256Compress function, its arguments, and its return value.In a discussion on the Bitcoin development mailing list, O'Connor described the SHA256 compression function used in creating Merkle Tries. He suggested a construction where values are already hashed down to 256 bits before being passed in, and tags are used to determine the type of node. This approach improves performance by skipping unary hashes, and there seems to be no downside as long as tags are inexpensive.The email exchanges between O'Connor and Todd revolved around the technical details of Bitcoin's cryptography, particularly regarding the math operations and functions used in the computation of MerkleRoot.In summary, the discussions focused on concerns about the security of the SHA-256 compression function with chosen initial values in pruned trees and proposed solutions involving the use of hash tags and different math operations. The conversations also delved into the specifics of the sha256Compress function and its arguments, as well as the Merkle-Damgård property and the use of safe tags to prevent collisions. Overall, the emails provided detailed insights into the complexities of Bitcoin's cryptography and its Merkle tree data structure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_A-proposal-to-reintroduce-the-disabled-script-opcodes.xml b/static/bitcoin-dev/May_2017/combined_A-proposal-to-reintroduce-the-disabled-script-opcodes.xml index 3841aa921a..af91566a83 100644 --- a/static/bitcoin-dev/May_2017/combined_A-proposal-to-reintroduce-the-disabled-script-opcodes.xml +++ b/static/bitcoin-dev/May_2017/combined_A-proposal-to-reintroduce-the-disabled-script-opcodes.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - A proposal to reintroduce the disabled script opcodes - 2023-08-01T20:38:48.401828+00:00 - - Ethan Heilman 2017-05-22 16:43:11+00:00 - - - Peter Todd 2017-05-22 16:14:04+00:00 - - - Ethan Heilman 2017-05-22 14:41:40+00:00 - - - Peter Todd 2017-05-22 14:09:19+00:00 - - - Hampus Sjöberg 2017-05-19 13:13:03+00:00 - - - Mark Boldyrev 2017-05-19 06:07:41+00:00 - + 2025-09-26T15:58:32.562576+00:00 + python-feedgen + + + [bitcoin-dev] A proposal to reintroduce the disabled script opcodes Mark Boldyrev + 2017-05-19T06:07:00.000Z + + + Hampus Sjöberg + 2017-05-19T13:13:00.000Z + + + Peter Todd + 2017-05-22T14:09:00.000Z + + + Ethan Heilman + 2017-05-22T14:41:00.000Z + + + Peter Todd + 2017-05-22T16:14:00.000Z + + + Ethan Heilman + 2017-05-22T16:43:00.000Z + + - python-feedgen + 2 Combined summary - A proposal to reintroduce the disabled script opcodes - 2023-08-01T20:38:48.401828+00:00 + 2025-09-26T15:58:32.563436+00:00 - The user is requesting the implementation of an OP_CAT instruction that concatenates hash outputs together. This instruction would pop N vectors of the stack, concatenate them, and hash them. The user suggests that the instruction should have a maximum output size of 512 Bytes and should be able to handle input vectors of any size without exceeding 32 Bytes of memory usage. The purpose of this instruction is to securely and compactly verify many hashes and hash preimages in offchain Tumblebit transactions.In an email conversation between Ethan Heilman and Peter Todd, Ethan proposes the use of OP_CAT to reduce the size of transactions for offchain Tumblebit transactions. With OP_CAT, only one hash would need to be stored in the transaction instead of multiple hashes. This would significantly reduce the size of the transaction. Peter asks about the maximum output size and suggests that Ethan's proposal could be a good use-case for a BIP.The author of a Bitcoin development mailing list post is also requesting the implementation of OP_CAT. They believe that OP_CAT would help securely and compactly verify many hashes and hash preimages, reducing the size of Tumblebit transactions. Currently, when checking a transaction that releases multiple preimages, each preimage and its corresponding hash must be stored and checked individually. However, with OP_CAT, only one hash would need to be stored in the transaction. The author suggests an example formula for the hash calculation using OP_CAT. They acknowledge that most of the existing math OP codes are not helpful due to their 32-bit nature and strange overflow behavior.Another participant in the Bitcoin development mailing list, Mark Boldyrev, suggests reintroducing the "disabled" opcodes to enhance script flexibility and allow for the creation of sophisticated native smart contracts. Boldyrev believes that these opcodes should be reintroduced along with a standardized behavior definition. He gives an example of how the script should exit and fail when an opcode results in an arithmetic error, such as OP_DIV with a zero divisor. He also suggests that string splice opcodes should check their arguments for correctness. Boldyrev mentions that these opcodes would enable the creation of advanced smart contracts and refers to the CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY bip as examples.Re-enabling the old OP-codes in Bitcoin would require a hard fork, but if SegWit is enabled, new OP-codes can be allocated via a soft fork by introducing a new version of Script. The Elements alpha project has experimented with re-enabling the old OP-codes. There was a bug in Core software back in 2010 that allowed denial-of-service attacks due to the software crashing while executing a script on some machines. Mark Boldyrev emphasizes the need for reintroducing the removed opcodes along with standardized behavior definitions to enhance script flexibility and enable the creation of sophisticated native smart contracts. These opcodes should handle cases like arithmetic errors and incorrect arguments in a controlled manner.Overall, the implementation of OP_CAT, along with the reintroduction of disabled opcodes and standardized behavior definitions, would greatly enhance the flexibility of scripts and allow for the creation of more advanced smart contracts in Bitcoin. 2017-05-22T16:43:11+00:00 + The user is requesting the implementation of an OP_CAT instruction that concatenates hash outputs together. This instruction would pop N vectors of the stack, concatenate them, and hash them. The user suggests that the instruction should have a maximum output size of 512 Bytes and should be able to handle input vectors of any size without exceeding 32 Bytes of memory usage. The purpose of this instruction is to securely and compactly verify many hashes and hash preimages in offchain Tumblebit transactions.In an email conversation between Ethan Heilman and Peter Todd, Ethan proposes the use of OP_CAT to reduce the size of transactions for offchain Tumblebit transactions. With OP_CAT, only one hash would need to be stored in the transaction instead of multiple hashes. This would significantly reduce the size of the transaction. Peter asks about the maximum output size and suggests that Ethan's proposal could be a good use-case for a BIP.The author of a Bitcoin development mailing list post is also requesting the implementation of OP_CAT. They believe that OP_CAT would help securely and compactly verify many hashes and hash preimages, reducing the size of Tumblebit transactions. Currently, when checking a transaction that releases multiple preimages, each preimage and its corresponding hash must be stored and checked individually. However, with OP_CAT, only one hash would need to be stored in the transaction. The author suggests an example formula for the hash calculation using OP_CAT. They acknowledge that most of the existing math OP codes are not helpful due to their 32-bit nature and strange overflow behavior.Another participant in the Bitcoin development mailing list, Mark Boldyrev, suggests reintroducing the "disabled" opcodes to enhance script flexibility and allow for the creation of sophisticated native smart contracts. Boldyrev believes that these opcodes should be reintroduced along with a standardized behavior definition. He gives an example of how the script should exit and fail when an opcode results in an arithmetic error, such as OP_DIV with a zero divisor. He also suggests that string splice opcodes should check their arguments for correctness. Boldyrev mentions that these opcodes would enable the creation of advanced smart contracts and refers to the CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY bip as examples.Re-enabling the old OP-codes in Bitcoin would require a hard fork, but if SegWit is enabled, new OP-codes can be allocated via a soft fork by introducing a new version of Script. The Elements alpha project has experimented with re-enabling the old OP-codes. There was a bug in Core software back in 2010 that allowed denial-of-service attacks due to the software crashing while executing a script on some machines. Mark Boldyrev emphasizes the need for reintroducing the removed opcodes along with standardized behavior definitions to enhance script flexibility and enable the creation of sophisticated native smart contracts. These opcodes should handle cases like arithmetic errors and incorrect arguments in a controlled manner.Overall, the implementation of OP_CAT, along with the reintroduction of disabled opcodes and standardized behavior definitions, would greatly enhance the flexibility of scripts and allow for the creation of more advanced smart contracts in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_BIP-Block-signal-enforcement-via-tx-fees.xml b/static/bitcoin-dev/May_2017/combined_BIP-Block-signal-enforcement-via-tx-fees.xml index ed54651609..5b35038bf8 100644 --- a/static/bitcoin-dev/May_2017/combined_BIP-Block-signal-enforcement-via-tx-fees.xml +++ b/static/bitcoin-dev/May_2017/combined_BIP-Block-signal-enforcement-via-tx-fees.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - BIP: Block signal enforcement via tx fees - 2023-08-01T20:37:33.597196+00:00 - - Anthony Towns 2017-05-20 05:05:43+00:00 - - - Rusty Russell 2017-05-15 01:14:13+00:00 - - - ZmnSCPxj 2017-05-14 12:18:18+00:00 - - - Russell O'Connor 2017-05-13 17:11:27+00:00 - - - Luke Dashjr 2017-05-13 16:42:44+00:00 - - - Peter Todd 2017-05-13 12:48:48+00:00 - - - Eric Voskuil 2017-05-13 06:43:59+00:00 - - - Luke Dashjr 2017-05-13 05:45:24+00:00 - - - Eric Voskuil 2017-05-13 05:36:43+00:00 - - - Luke Dashjr 2017-05-13 05:26:58+00:00 - - - Russell O'Connor 2017-05-13 04:23:41+00:00 - - - ZmnSCPxj 2017-05-13 03:54:50+00:00 - - - Eric Voskuil 2017-05-13 03:26:08+00:00 - - - Luke Dashjr 2017-05-13 00:49:33+00:00 - - - Peter Todd 2017-05-12 22:22:14+00:00 - - - ZmnSCPxj 2017-05-12 22:17:30+00:00 - - - Luke Dashjr 2017-05-12 19:22:56+00:00 - + 2025-09-26T15:58:26.212173+00:00 + python-feedgen + + + [bitcoin-dev] BIP: Block signal enforcement via tx fees Luke Dashjr + 2017-05-12T19:22:00.000Z + + + ZmnSCPxj + 2017-05-12T22:17:00.000Z + + + Peter Todd + 2017-05-12T22:22:00.000Z + + + Luke Dashjr + 2017-05-13T00:49:00.000Z + + + Eric Voskuil + 2017-05-13T03:26:00.000Z + + + ZmnSCPxj + 2017-05-13T03:54:00.000Z + + + Russell O'Connor + 2017-05-13T04:23:00.000Z + + + Luke Dashjr + 2017-05-13T05:26:00.000Z + + + Eric Voskuil + 2017-05-13T05:36:00.000Z + + + Luke Dashjr + 2017-05-13T05:45:00.000Z + + + Eric Voskuil + 2017-05-13T06:43:00.000Z + + + Peter Todd + 2017-05-13T12:48:00.000Z + + + Luke Dashjr + 2017-05-13T16:42:00.000Z + + + Russell O'Connor + 2017-05-13T17:11:00.000Z + + + ZmnSCPxj + 2017-05-14T12:18:00.000Z + + + Rusty Russell + 2017-05-15T01:14:00.000Z + + + Anthony Towns + 2017-05-20T05:05:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - BIP: Block signal enforcement via tx fees - 2023-08-01T20:37:33.597196+00:00 + 2025-09-26T15:58:26.214029+00:00 - The email thread discusses different approaches to ensuring that the timeout for versionbits is specified. One approach suggested is to bundle a pair of similar transactions, one with transaction version bits set and another with locktime set. Another approach is to use input height, which invalidates a transaction in a block if the soft-fork has not timed out or activated, the block does not signal bit N, the transaction version does signal bit N and at least one input to the transaction has a height >= S. This approach also allows for bit reuse and is compatible with using bitcoin days destroyed as a weighting measure.The discussion on versionbits and its behavior after deployment timeout was the subject of communication between Russell O'Connor and Luke Dashjr. It was suggested that a user can add a timeout by bundling a pair of similar transactions, one with the transaction version bits set and another with a locktime set. Later, a proposal by Dashjr suggested adding a subset of nVersion to simplify the process while using fewer precious nVersion bits. The proposal allows specifying a single bit and only supports BIP8/9-style signalling.The proposal presented is deemed imperfect by the writer, as it rewards signalling whereas the end goal is activation. The writer suggests a different approach that would reward activation and proposes an opcode to create an assurance contract for activation of a softfork. They acknowledge their limited knowledge about Bitcoin's codebase but believe the suggested spec is workable. Additionally, the writer highlights the possibility of inverse logic wherein a vote against a softfork can be cast.On May 13, 2017, Luke Dashjr emailed about the need to specify a timeout for versionbits to avoid losing their meaning after deployment. Users can bundle a pair of similar transactions, one with transaction version bits set and another with a locktime set to add a timeout. Dashjr's formal condition includes a check for block version, but it does not prevent upgrading versionbits. Any txVersion that does not begin with 0b001 is unconditionally acceptable and available for further soft-forking.In a discussion on Bitcoin development, Peter Todd and another user debated the idea of users paying for signalling of softforks. The other user argued that as long as the deployment of the softfork is widespread, the risk of users not paying is minimal. Peter Todd countered by saying that this assumption relies on the notion that the users who pay for soft-fork signalling will represent an economic majority, which may not always be the case. He suggests that if the economic majority hasn't consented to the softfork, many users will make their transactions conditional on non-signalling.The discussion involves potential issues with nVersion signaling, which is difficult to enforce. Users are responsible for adoption of rules and paying miners for signaling certain bits can further complicate the situation. The risk of false signaling is minimal if deployment of the softfork is widespread, but it could lead to a breakdown in honesty of the nVersion system if users pay prematurely. There is concern that users paying for soft-fork signaling may not represent an economic majority and miners could take extra fees provided by a small percentage of users while violating the nVersion protocol. Additionally, the discussion highlights concerns with the inadequacy and unreadability of English language specifications; it is suggested to use the "reference implementation" as the specification instead.The discussion between Luke Dashjr and Eric Voskuil revolves around the issue of mining centralization in Bitcoin. Dashjr contends that most people cannot mine except at a huge expense, so the profits from every miner you buy will go to pay for Bitmain growing their arsenal more than enough to offset your influence. Voskuil disagrees that nobody should mine because it's a zero-sum game that one miner will always win and therefore we should not push up the hash rate by trying to compete because the same miner just makes more money on the hardware. He argues that there is nothing inherently wrong with paying people to run nodes or signal "readiness," but there is no reason whatsoever to consider these ideas beneficial from a personal/economic or security/decentralization standpoint.In an email thread, Eric Voskuil argues that mining is broken and it is difficult for people to influence miners without incurring a huge expense. He also suggests that paying people to run nodes or signal readiness is not beneficial from either personal/economic or security/decentralization standpoint. Eric's argument assumes that miners are a government or control Bitcoin in some way, which is incorrect. Miners are entrusted with enforcement of softforks, and their refusal to do so is considered an attack on the network.In this message, ZmnSCPxj argues that it is economically logical for some people to pay fees to others with better Bitcoin to hash rate conversion rates rather than suffering a lower conversion rate due to differences in electricity rates depending on country. However, the author of the message disagrees, stating that this is simply an argument for all people to pay one person. 2017-05-20T05:05:43+00:00 + The email thread discusses different approaches to ensuring that the timeout for versionbits is specified. One approach suggested is to bundle a pair of similar transactions, one with transaction version bits set and another with locktime set. Another approach is to use input height, which invalidates a transaction in a block if the soft-fork has not timed out or activated, the block does not signal bit N, the transaction version does signal bit N and at least one input to the transaction has a height >= S. This approach also allows for bit reuse and is compatible with using bitcoin days destroyed as a weighting measure.The discussion on versionbits and its behavior after deployment timeout was the subject of communication between Russell O'Connor and Luke Dashjr. It was suggested that a user can add a timeout by bundling a pair of similar transactions, one with the transaction version bits set and another with a locktime set. Later, a proposal by Dashjr suggested adding a subset of nVersion to simplify the process while using fewer precious nVersion bits. The proposal allows specifying a single bit and only supports BIP8/9-style signalling.The proposal presented is deemed imperfect by the writer, as it rewards signalling whereas the end goal is activation. The writer suggests a different approach that would reward activation and proposes an opcode to create an assurance contract for activation of a softfork. They acknowledge their limited knowledge about Bitcoin's codebase but believe the suggested spec is workable. Additionally, the writer highlights the possibility of inverse logic wherein a vote against a softfork can be cast.On May 13, 2017, Luke Dashjr emailed about the need to specify a timeout for versionbits to avoid losing their meaning after deployment. Users can bundle a pair of similar transactions, one with transaction version bits set and another with a locktime set to add a timeout. Dashjr's formal condition includes a check for block version, but it does not prevent upgrading versionbits. Any txVersion that does not begin with 0b001 is unconditionally acceptable and available for further soft-forking.In a discussion on Bitcoin development, Peter Todd and another user debated the idea of users paying for signalling of softforks. The other user argued that as long as the deployment of the softfork is widespread, the risk of users not paying is minimal. Peter Todd countered by saying that this assumption relies on the notion that the users who pay for soft-fork signalling will represent an economic majority, which may not always be the case. He suggests that if the economic majority hasn't consented to the softfork, many users will make their transactions conditional on non-signalling.The discussion involves potential issues with nVersion signaling, which is difficult to enforce. Users are responsible for adoption of rules and paying miners for signaling certain bits can further complicate the situation. The risk of false signaling is minimal if deployment of the softfork is widespread, but it could lead to a breakdown in honesty of the nVersion system if users pay prematurely. There is concern that users paying for soft-fork signaling may not represent an economic majority and miners could take extra fees provided by a small percentage of users while violating the nVersion protocol. Additionally, the discussion highlights concerns with the inadequacy and unreadability of English language specifications; it is suggested to use the "reference implementation" as the specification instead.The discussion between Luke Dashjr and Eric Voskuil revolves around the issue of mining centralization in Bitcoin. Dashjr contends that most people cannot mine except at a huge expense, so the profits from every miner you buy will go to pay for Bitmain growing their arsenal more than enough to offset your influence. Voskuil disagrees that nobody should mine because it's a zero-sum game that one miner will always win and therefore we should not push up the hash rate by trying to compete because the same miner just makes more money on the hardware. He argues that there is nothing inherently wrong with paying people to run nodes or signal "readiness," but there is no reason whatsoever to consider these ideas beneficial from a personal/economic or security/decentralization standpoint.In an email thread, Eric Voskuil argues that mining is broken and it is difficult for people to influence miners without incurring a huge expense. He also suggests that paying people to run nodes or signal readiness is not beneficial from either personal/economic or security/decentralization standpoint. Eric's argument assumes that miners are a government or control Bitcoin in some way, which is incorrect. Miners are entrusted with enforcement of softforks, and their refusal to do so is considered an attack on the network.In this message, ZmnSCPxj argues that it is economically logical for some people to pay fees to others with better Bitcoin to hash rate conversion rates rather than suffering a lower conversion rate due to differences in electricity rates depending on country. However, the author of the message disagrees, stating that this is simply an argument for all people to pay one person. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_BIP-Proposal-Rate-Limiting-with-server-specified-Proof-of-Work-challenges.xml b/static/bitcoin-dev/May_2017/combined_BIP-Proposal-Rate-Limiting-with-server-specified-Proof-of-Work-challenges.xml index f5acc88e5c..11855856e2 100644 --- a/static/bitcoin-dev/May_2017/combined_BIP-Proposal-Rate-Limiting-with-server-specified-Proof-of-Work-challenges.xml +++ b/static/bitcoin-dev/May_2017/combined_BIP-Proposal-Rate-Limiting-with-server-specified-Proof-of-Work-challenges.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - BIP Proposal: Rate Limiting with server specified Proof of Work challenges - 2023-08-01T20:33:55.494910+00:00 - - Karl Johan Alm 2017-05-19 04:09:29+00:00 - - - Karl Johan Alm 2017-05-09 01:15:25+00:00 - - - Erik Aronesty 2017-05-08 18:58:54+00:00 - - - Karl Johan Alm 2017-05-08 02:48:54+00:00 - + 2025-09-26T15:58:34.677369+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges Karl Johan Alm + 2017-05-08T02:48:00.000Z + + + Erik Aronesty + 2017-05-08T18:58:00.000Z + + + Karl Johan Alm + 2017-05-09T01:15:00.000Z + + + Karl Johan Alm + 2017-05-19T04:09:00.000Z + + - python-feedgen + 2 Combined summary - BIP Proposal: Rate Limiting with server specified Proof of Work challenges - 2023-08-01T20:33:55.494910+00:00 + 2025-09-26T15:58:34.678050+00:00 - Karl Johan Alm has proposed a new feature for rate limiting purposes in which nodes can solve arbitrary Proof of Work (PoW) challenges in exchange for connection slots. The proposal aims to cover DoS risky services such as bloom filters. Two types of PoW, sha256 and cuckoo-cycle, have been included in the proposal and can be combined in different ways. The BIP has been posted on GitHub and has not received any negative feedback so far. If there are no objections, the proposer intends to have a BIP number assigned. The link to the proposal can be found at https://github.com/kallewoof/bips/blob/pow-connection-slots/bip-rate-limiting-via-pow.mediawiki.Erik Aronesty has suggested specifying rate-limiting PoW as bytecode, allowing nodes to plug in various "machine-captcha" measures. However, it is unclear what he means by this. The BIP includes methods to determine an approximate time to solve, discarding challenges that take longer than the challenge's expiration. Another approach suggested by others is requiring a nanobit payment, which could further prevent DDOS attacks and generate revenue for nodes. However, this approach also has unwanted side effects that need clarification. In the proposed scenario, the node requesting PoW does not gain anything from lying to the node performing the work.Overall, the proposal by Karl Johan Alm offers a new feature to limit the rate of connections using PoW challenges. It includes two types of PoW, sha256 and cuckoo-cycle, which can be combined for enhanced security. The feature aims to cover other DoS risky services like bloom filters. The proposal has been shared on GitHub, and feedback is welcome. 2017-05-19T04:09:29+00:00 + Karl Johan Alm has proposed a new feature for rate limiting purposes in which nodes can solve arbitrary Proof of Work (PoW) challenges in exchange for connection slots. The proposal aims to cover DoS risky services such as bloom filters. Two types of PoW, sha256 and cuckoo-cycle, have been included in the proposal and can be combined in different ways. The BIP has been posted on GitHub and has not received any negative feedback so far. If there are no objections, the proposer intends to have a BIP number assigned. The link to the proposal can be found at https://github.com/kallewoof/bips/blob/pow-connection-slots/bip-rate-limiting-via-pow.mediawiki.Erik Aronesty has suggested specifying rate-limiting PoW as bytecode, allowing nodes to plug in various "machine-captcha" measures. However, it is unclear what he means by this. The BIP includes methods to determine an approximate time to solve, discarding challenges that take longer than the challenge's expiration. Another approach suggested by others is requiring a nanobit payment, which could further prevent DDOS attacks and generate revenue for nodes. However, this approach also has unwanted side effects that need clarification. In the proposed scenario, the node requesting PoW does not gain anything from lying to the node performing the work.Overall, the proposal by Karl Johan Alm offers a new feature to limit the rate of connections using PoW challenges. It includes two types of PoW, sha256 and cuckoo-cycle, which can be combined for enhanced security. The feature aims to cover other DoS risky services like bloom filters. The proposal has been shared on GitHub, and feedback is welcome. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_BIP-proposal-NODE-NETWORK-LIMITED-service-bits.xml b/static/bitcoin-dev/May_2017/combined_BIP-proposal-NODE-NETWORK-LIMITED-service-bits.xml index 4dba20d52f..84c0dca51c 100644 --- a/static/bitcoin-dev/May_2017/combined_BIP-proposal-NODE-NETWORK-LIMITED-service-bits.xml +++ b/static/bitcoin-dev/May_2017/combined_BIP-proposal-NODE-NETWORK-LIMITED-service-bits.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - BIP proposal: NODE_NETWORK_LIMITED service bits - 2023-08-01T20:35:56.038210+00:00 - - Gregory Maxwell 2017-05-12 02:22:15+00:00 - - - Eric Voskuil 2017-05-11 21:05:09+00:00 - - - Aymeric Vitte 2017-05-11 20:36:33+00:00 - - - Jonas Schnelli 2017-05-11 20:10:08+00:00 - - - Luke Dashjr 2017-05-11 19:24:21+00:00 - - - Gregory Maxwell 2017-05-11 18:17:19+00:00 - - - Jonas Schnelli 2017-05-11 15:13:12+00:00 - + 2025-09-26T15:58:09.086834+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits Jonas Schnelli + 2017-05-11T15:13:00.000Z + + + Gregory Maxwell + 2017-05-11T18:17:00.000Z + + + Luke Dashjr + 2017-05-11T19:24:00.000Z + + + Jonas Schnelli + 2017-05-11T20:10:00.000Z + + + Aymeric Vitte + 2017-05-11T20:36:00.000Z + + + Eric Voskuil + 2017-05-11T21:05:00.000Z + + + Gregory Maxwell + 2017-05-12T02:22:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: NODE_NETWORK_LIMITED service bits - 2023-08-01T20:35:56.038210+00:00 + 2025-09-26T15:58:09.087758+00:00 - The discussion in the Bitcoin-dev mailing list revolves around the proposal by Jonas Schnelli to improve the signaling of valuable services by pruned peers. The proposal can be found on Github and participants have expressed concerns about the instructions for relay addresses in the proposal. It is suggested that the instructions should not instruct individuals to relay specific addresses but rather relay addresses they would connect to, to avoid relaying information that is not useful.There are concerns raised about the default setting for pruning in Bitcoin, with some participants suggesting that the focus should be on scaling full nodes rather than making pruning the default. The level of approximation and "useless maths/papers" used to support various arguments is criticized. One participant suggests that every full node operator should simply not connect to or relay the address of any peer advertising itself as diminished. The cost of the entire chain is estimated at $7.50, with breathing room, and it is suggested that anyone wanting to save a few dollars would be better off attempting to hide their pruning.The discussion also revolves around defining the service bits for historical blocks. Some suggest leaving both bits undefined, while others propose using Gregory's proposal of a minimum of 2016*2 blocks. The reason for choosing a 49-day time limit is discussed, allowing Simplified Payment Verification (SPV) peers to be offline for a month and still catch up with a pruned peer. There is confusion about whether Core guarantees the 288 blocks post-segwit activation.There is also a concern raised about light clients who are not checking the nServiceFlags from a relayed addr-message, as they may unwillingly connect to a pruned peer and ask for filtered blocks below their pruned depth. The email includes links to various resources including Zcash wallets made simple, Bitcoin wallets made simple, torrent blocklists, and anti-spy software.In summary, the discussion focuses on the usefulness of defining a deterministically chosen set of historical blocks within a certain timeframe and whether it would be better to leave it undefined. The proposal suggests that peers should connect a limited amount of their available outbound connections to peers signaling the NODE_NETWORK_LIMITED_* service bits. There is also a concern about light clients unknowingly connecting to pruned peers. The author of the email has shared a BIP proposal to improve the signaling of valuable services by pruned peers and welcomes feedback on the draft. 2017-05-12T02:22:15+00:00 + The discussion in the Bitcoin-dev mailing list revolves around the proposal by Jonas Schnelli to improve the signaling of valuable services by pruned peers. The proposal can be found on Github and participants have expressed concerns about the instructions for relay addresses in the proposal. It is suggested that the instructions should not instruct individuals to relay specific addresses but rather relay addresses they would connect to, to avoid relaying information that is not useful.There are concerns raised about the default setting for pruning in Bitcoin, with some participants suggesting that the focus should be on scaling full nodes rather than making pruning the default. The level of approximation and "useless maths/papers" used to support various arguments is criticized. One participant suggests that every full node operator should simply not connect to or relay the address of any peer advertising itself as diminished. The cost of the entire chain is estimated at $7.50, with breathing room, and it is suggested that anyone wanting to save a few dollars would be better off attempting to hide their pruning.The discussion also revolves around defining the service bits for historical blocks. Some suggest leaving both bits undefined, while others propose using Gregory's proposal of a minimum of 2016*2 blocks. The reason for choosing a 49-day time limit is discussed, allowing Simplified Payment Verification (SPV) peers to be offline for a month and still catch up with a pruned peer. There is confusion about whether Core guarantees the 288 blocks post-segwit activation.There is also a concern raised about light clients who are not checking the nServiceFlags from a relayed addr-message, as they may unwillingly connect to a pruned peer and ask for filtered blocks below their pruned depth. The email includes links to various resources including Zcash wallets made simple, Bitcoin wallets made simple, torrent blocklists, and anti-spy software.In summary, the discussion focuses on the usefulness of defining a deterministically chosen set of historical blocks within a certain timeframe and whether it would be better to leave it undefined. The proposal suggests that peers should connect a limited amount of their available outbound connections to peers signaling the NODE_NETWORK_LIMITED_* service bits. There is also a concern about light clients unknowingly connecting to pruned peers. The author of the email has shared a BIP proposal to improve the signaling of valuable services by pruned peers and welcomes feedback on the draft. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_BIP149-timeout-why-so-far-in-the-future-.xml b/static/bitcoin-dev/May_2017/combined_BIP149-timeout-why-so-far-in-the-future-.xml index 552db4713d..651b26d27e 100644 --- a/static/bitcoin-dev/May_2017/combined_BIP149-timeout-why-so-far-in-the-future-.xml +++ b/static/bitcoin-dev/May_2017/combined_BIP149-timeout-why-so-far-in-the-future-.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - BIP149 timeout-- why so far in the future? - 2023-08-01T20:45:02.556824+00:00 - - Jorge Timón 2017-06-11 14:29:08+00:00 - - - Martijn Meijering 2017-06-11 13:44:17+00:00 - - - Jorge Timón 2017-06-11 13:17:43+00:00 - - - Ryan Grant 2017-06-11 05:48:39+00:00 - - - Rusty Russell 2017-05-27 01:19:33+00:00 - - - Matt Corallo 2017-05-26 20:04:58+00:00 - - - shaolinfry 2017-05-26 07:28:09+00:00 - - - Rusty Russell 2017-05-24 04:26:56+00:00 - - - Gregory Maxwell 2017-05-23 17:50:12+00:00 - + 2025-09-26T15:57:32.871080+00:00 + python-feedgen + + + [bitcoin-dev] BIP149 timeout-- why so far in the future? Gregory Maxwell + 2017-05-23T17:50:00.000Z + + + Rusty Russell + 2017-05-24T04:26:00.000Z + + + shaolinfry + 2017-05-26T07:28:00.000Z + + + Matt Corallo + 2017-05-26T20:04:00.000Z + + + Rusty Russell + 2017-05-27T01:19:00.000Z + + + Ryan Grant + 2017-06-11T05:48:00.000Z + + + Jorge Timón + 2017-06-11T13:17:00.000Z + + + Martijn Meijering + 2017-06-11T13:44:00.000Z + + + Jorge Timón + 2017-06-11T14:29:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - BIP149 timeout-- why so far in the future? - 2023-08-01T20:45:02.557826+00:00 + 2025-09-26T15:57:32.872205+00:00 - In a recent discussion on the bitcoin-dev mailing list, Jorge Timón proposed that BIP 149 should only activate if BIP 141 has expired unsuccessfully. This would be done by not removing the BIP 141 deployment with bip9. If SegWit activates before November 15th, BIP 149 nodes can detect and interpret it correctly. However, if it activates after November 15th, a separate service bit in the p2p network will be needed for pre-BIP 149 nodes to know whether SegWit has activated or not. Timón's proposal has raised concerns about the testing requirements of BIP 149.Some individuals argue that BIP 149 should be merged and released immediately, while others believe that more testing is necessary. The concern is that if BIP 149 is deployed before the activation of SegWit pre-November 15th, then BIP 149 nodes would use the old service bit for SegWit instead of the new one. There has been some work done to modify the code to account for this scenario, but there seems to be little interest in releasing BIP 149 before November 15th. A query was raised about whether there would be any problem with activating BIP 149 on November 16th.The activation of BIP 149 on November 16th could potentially cause problems for some users of Bitcoin. While the activation would improve the scalability and security of the network, it could also lead to compatibility issues for wallets and exchanges that are not prepared for SegWit addresses. Additionally, users who have not upgraded their nodes to support SegWit may find themselves unable to validate transactions or participate in the network after the activation. It is recommended that users ensure their wallets and exchanges are compatible with SegWit and upgrade their nodes as soon as possible to avoid any potential issues.There is ongoing debate within the Bitcoin community about the best way to activate SegWit, with some advocating for BIP 148 as an alternative proposal. However, BIP 149 has gained significant support and is expected to proceed as planned.In an email conversation between Rusty Russell and Matt Corallo, they discuss the timing of releasing code related to SegWit. Corallo emphasizes that the timeout for SegWit is not as important as when the code can be released, which he predicts will take several months after the current timeout. Russell had assumed that the code would be included in the next point release.A discussion on the bitcoin-dev mailing list focused on the timeout and release of code for SegWit. Gregory Maxwell suggested that the BIP 149 timeout was set too far in the future and that it could take up to six months after release for a stable transition. Rusty Russell agreed and proposed a deadline of December 16th, 2017, or January 16th, 2018, to avoid interference from the end-of-year holidays. This delay has set back SegWit by one to two months beyond what would have been experienced with BIP 8. It is expected that the release of the code will take several months after the current timeout.In another email exchange on the bitcoin-dev mailing list, a Bitcoin developer suggested bringing forward the BIP 149 activation date. Originally set far out enough to avoid focusing on the date rather than the proposal itself, the activation date could potentially be reduced to six months or less from November 2017. The developer argued that the community's eagerness for SegWit, as evidenced by the quick upgrade to BIP 141, suggests that they will also upgrade quickly to BIP 149. Gregory Maxwell questioned the timeline based on the observed adoption rates of SegWit, suggesting that it could take up to six months after release for a stable transition. Rusty Russell agreed and recommended a December 16th, 2017 deadline (or January 16th during EOY holidays). This delay pushes back SegWit by one to two months beyond what would have happened with BIP 8.The speed of SegWit adoption has led to concerns about the distant future of the BIP 149 timeout. It is believed that it could take up to six months after release for the required density for a stable transition. However, this timeline may not be applicable if it were a different proposal and not SegWit, where network penetration has already been observed. 2017-06-11T14:29:08+00:00 + In a recent discussion on the bitcoin-dev mailing list, Jorge Timón proposed that BIP 149 should only activate if BIP 141 has expired unsuccessfully. This would be done by not removing the BIP 141 deployment with bip9. If SegWit activates before November 15th, BIP 149 nodes can detect and interpret it correctly. However, if it activates after November 15th, a separate service bit in the p2p network will be needed for pre-BIP 149 nodes to know whether SegWit has activated or not. Timón's proposal has raised concerns about the testing requirements of BIP 149.Some individuals argue that BIP 149 should be merged and released immediately, while others believe that more testing is necessary. The concern is that if BIP 149 is deployed before the activation of SegWit pre-November 15th, then BIP 149 nodes would use the old service bit for SegWit instead of the new one. There has been some work done to modify the code to account for this scenario, but there seems to be little interest in releasing BIP 149 before November 15th. A query was raised about whether there would be any problem with activating BIP 149 on November 16th.The activation of BIP 149 on November 16th could potentially cause problems for some users of Bitcoin. While the activation would improve the scalability and security of the network, it could also lead to compatibility issues for wallets and exchanges that are not prepared for SegWit addresses. Additionally, users who have not upgraded their nodes to support SegWit may find themselves unable to validate transactions or participate in the network after the activation. It is recommended that users ensure their wallets and exchanges are compatible with SegWit and upgrade their nodes as soon as possible to avoid any potential issues.There is ongoing debate within the Bitcoin community about the best way to activate SegWit, with some advocating for BIP 148 as an alternative proposal. However, BIP 149 has gained significant support and is expected to proceed as planned.In an email conversation between Rusty Russell and Matt Corallo, they discuss the timing of releasing code related to SegWit. Corallo emphasizes that the timeout for SegWit is not as important as when the code can be released, which he predicts will take several months after the current timeout. Russell had assumed that the code would be included in the next point release.A discussion on the bitcoin-dev mailing list focused on the timeout and release of code for SegWit. Gregory Maxwell suggested that the BIP 149 timeout was set too far in the future and that it could take up to six months after release for a stable transition. Rusty Russell agreed and proposed a deadline of December 16th, 2017, or January 16th, 2018, to avoid interference from the end-of-year holidays. This delay has set back SegWit by one to two months beyond what would have been experienced with BIP 8. It is expected that the release of the code will take several months after the current timeout.In another email exchange on the bitcoin-dev mailing list, a Bitcoin developer suggested bringing forward the BIP 149 activation date. Originally set far out enough to avoid focusing on the date rather than the proposal itself, the activation date could potentially be reduced to six months or less from November 2017. The developer argued that the community's eagerness for SegWit, as evidenced by the quick upgrade to BIP 141, suggests that they will also upgrade quickly to BIP 149. Gregory Maxwell questioned the timeline based on the observed adoption rates of SegWit, suggesting that it could take up to six months after release for a stable transition. Rusty Russell agreed and recommended a December 16th, 2017 deadline (or January 16th during EOY holidays). This delay pushes back SegWit by one to two months beyond what would have happened with BIP 8.The speed of SegWit adoption has led to concerns about the distant future of the BIP 149 timeout. It is believed that it could take up to six months after release for the required density for a stable transition. However, this timeline may not be applicable if it were a different proposal and not SegWit, where network penetration has already been observed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Barry-Silbert-segwit-agreement.xml b/static/bitcoin-dev/May_2017/combined_Barry-Silbert-segwit-agreement.xml index 47bf663846..eb2f3f16b8 100644 --- a/static/bitcoin-dev/May_2017/combined_Barry-Silbert-segwit-agreement.xml +++ b/static/bitcoin-dev/May_2017/combined_Barry-Silbert-segwit-agreement.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Barry Silbert segwit agreement - 2023-08-01T20:39:47.720027+00:00 - - James Hilliard 2017-05-28 23:28:11+00:00 - - - Tom Zander 2017-05-28 20:51:46+00:00 - - - Matt Corallo 2017-05-26 22:44:44+00:00 - - - Tom Zander 2017-05-26 22:12:49+00:00 - - - James Hilliard 2017-05-26 21:30:37+00:00 - - - Jacob Eliosoff 2017-05-26 20:10:38+00:00 - - - Matt Corallo 2017-05-26 20:02:41+00:00 - - - Tom Zander 2017-05-26 18:48:32+00:00 - - - Jacob Eliosoff 2017-05-26 17:47:11+00:00 - - - Daniele Pinna 2017-05-22 12:29:12+00:00 - - - Hampus Sjöberg 2017-05-22 09:23:22+00:00 - - - Peter Todd 2017-05-22 06:27:04+00:00 - - - shaolinfry 2017-05-22 06:12:08+00:00 - + 2025-09-26T15:58:06.964799+00:00 + python-feedgen + + + shaolinfry + 2017-05-22T06:12:00.000Z + + + Peter Todd + 2017-05-22T06:27:00.000Z + + + Hampus Sjöberg + 2017-05-22T09:23:00.000Z + + + Daniele Pinna + 2017-05-22T12:29:00.000Z + + + [bitcoin-dev] Barry Silbert segwit agreement Jacob Eliosoff + 2017-05-26T17:47:00.000Z + + + Tom Zander + 2017-05-26T18:48:00.000Z + + + Matt Corallo + 2017-05-26T20:02:00.000Z + + + Jacob Eliosoff + 2017-05-26T20:10:00.000Z + + + James Hilliard + 2017-05-26T21:30:00.000Z + + + Tom Zander + 2017-05-26T22:12:00.000Z + + + Matt Corallo + 2017-05-26T22:44:00.000Z + + + Tom Zander + 2017-05-28T20:51:00.000Z + + + James Hilliard + 2017-05-28T23:28:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Barry Silbert segwit agreement - 2023-08-01T20:39:47.720027+00:00 + 2025-09-26T15:58:06.966171+00:00 - Tom Zander suggests a solution to the issues with version 0.13.1+ and its segwit related features. He recommends banning older clients and advising them to upgrade. He proposes replacing the bit1 activation code with a bit4 logic based on 80% and no end-date. James Hilliard discusses the issues with SegWit and the need for multiple activation codepaths. Zander argues that one activation codepath based on 80% is sufficient.The development of a hard fork would require months of testing, so it is necessary to wait until BIP141 is active. The fastest path forward would be to use BIP91 to activate BIP141 via mandatory signalling. Then, the hard fork code can be developed assuming BIP141 is active. This staged rollout of segwit followed by a hard fork allows for a single testable upgrade path.Jacob Eliosoff proposes triggering BIP141 signalling when Silbert/NYC Segwit2MB proposal's lock-in supports 80%. Matt Corallo responds, suggesting continued research into meeting the spirit of the agreement. The proposal aims to minimize incompatibility with existing nodes but still has challenges regarding an aggressive hard fork schedule and possible chain splits.The email thread also discusses the feasibility of scheduling a hard fork, the need for compromise, and finding a safe and collaborative solution. Various proposals and activation strategies are mentioned, emphasizing the importance of addressing capacity increase beyond 2MB and replay protection. The writer expresses doubts about Barry Silbert's proposal and suggests activating BIP141 first, then hardforking to 2MB later. Other options such as BIP148 and different activation methods are discussed.On May 22, 2017, a proposal known as the Barry Silbert agreement was shared. This agreement, made between select participants, suggested changing the signaling mechanism to trick people into upgrading their node software to support a hard fork code. James Hilliard proposed an alternative option called BIP148 miner triggered (MASF) with a lower threshold above 50%, which would be compatible with the existing segwit protocol once activated. However, the writer suspects political engineering behind this proposal.The writer has received a copy of the Barry Silbert agreement, which can be found at https://pastebin.com/VuCYteJh. According to the agreement, participants are required to immediately activate Segwit under a different activation proposal. This proposal does not activate BIP141 and instead introduces a completely new deployment that is incompatible with the BIP141 deployment. The reason for this is that they could not convince 95% of the hashpower to trigger activation, so they opted for a lower 80% threshold.There are several options for activating Segwit now, including having 95% of the hashrate signal, deploying BIP148 UASF, redeploying Segwit on a new bit, or implementing the BIP148 miner triggered (MASF) with a lower threshold above 50%. The writer recommends the fourth option, as it lowers the threshold from 95% to 65%, increasing the chances of quick activation. However, this still leaves the activation in the hands of miners, which may have its drawbacks.The writer criticizes the Barry Silbert agreement for being ill-considered and lacking peer review from the technical community. The suggestion of a hard fork in four months is deemed unrealistic and without technical merits. The writer believes that closed-door agreements among selected participants are not the appropriate way to achieve consensus for changing a decentralized system worth $30 billion. The writer aims to assist in the immediate activation of Segwit, which only requires hashrate participation, and is open to all reasonable options that facilitate safe and collaborative progress. 2017-05-28T23:28:11+00:00 + Tom Zander suggests a solution to the issues with version 0.13.1+ and its segwit related features. He recommends banning older clients and advising them to upgrade. He proposes replacing the bit1 activation code with a bit4 logic based on 80% and no end-date. James Hilliard discusses the issues with SegWit and the need for multiple activation codepaths. Zander argues that one activation codepath based on 80% is sufficient.The development of a hard fork would require months of testing, so it is necessary to wait until BIP141 is active. The fastest path forward would be to use BIP91 to activate BIP141 via mandatory signalling. Then, the hard fork code can be developed assuming BIP141 is active. This staged rollout of segwit followed by a hard fork allows for a single testable upgrade path.Jacob Eliosoff proposes triggering BIP141 signalling when Silbert/NYC Segwit2MB proposal's lock-in supports 80%. Matt Corallo responds, suggesting continued research into meeting the spirit of the agreement. The proposal aims to minimize incompatibility with existing nodes but still has challenges regarding an aggressive hard fork schedule and possible chain splits.The email thread also discusses the feasibility of scheduling a hard fork, the need for compromise, and finding a safe and collaborative solution. Various proposals and activation strategies are mentioned, emphasizing the importance of addressing capacity increase beyond 2MB and replay protection. The writer expresses doubts about Barry Silbert's proposal and suggests activating BIP141 first, then hardforking to 2MB later. Other options such as BIP148 and different activation methods are discussed.On May 22, 2017, a proposal known as the Barry Silbert agreement was shared. This agreement, made between select participants, suggested changing the signaling mechanism to trick people into upgrading their node software to support a hard fork code. James Hilliard proposed an alternative option called BIP148 miner triggered (MASF) with a lower threshold above 50%, which would be compatible with the existing segwit protocol once activated. However, the writer suspects political engineering behind this proposal.The writer has received a copy of the Barry Silbert agreement, which can be found at https://pastebin.com/VuCYteJh. According to the agreement, participants are required to immediately activate Segwit under a different activation proposal. This proposal does not activate BIP141 and instead introduces a completely new deployment that is incompatible with the BIP141 deployment. The reason for this is that they could not convince 95% of the hashpower to trigger activation, so they opted for a lower 80% threshold.There are several options for activating Segwit now, including having 95% of the hashrate signal, deploying BIP148 UASF, redeploying Segwit on a new bit, or implementing the BIP148 miner triggered (MASF) with a lower threshold above 50%. The writer recommends the fourth option, as it lowers the threshold from 95% to 65%, increasing the chances of quick activation. However, this still leaves the activation in the hands of miners, which may have its drawbacks.The writer criticizes the Barry Silbert agreement for being ill-considered and lacking peer review from the technical community. The suggestion of a hard fork in four months is deemed unrealistic and without technical merits. The writer believes that closed-door agreements among selected participants are not the appropriate way to achieve consensus for changing a decentralized system worth $30 billion. The writer aims to assist in the immediate activation of Segwit, which only requires hashrate participation, and is open to all reasonable options that facilitate safe and collaborative progress. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Combining-SPV-and-Stealth-addresses.xml b/static/bitcoin-dev/May_2017/combined_Combining-SPV-and-Stealth-addresses.xml index ae6948d136..6c4f7c3cfb 100644 --- a/static/bitcoin-dev/May_2017/combined_Combining-SPV-and-Stealth-addresses.xml +++ b/static/bitcoin-dev/May_2017/combined_Combining-SPV-and-Stealth-addresses.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Combining SPV and Stealth addresses - 2023-08-01T20:33:04.893080+00:00 - - Henning Kopp 2017-05-06 09:38:06+00:00 - - - Chris Pacia 2017-05-04 16:23:27+00:00 - - - Henning Kopp 2017-05-04 12:51:39+00:00 - + 2025-09-26T15:57:34.988664+00:00 + python-feedgen + + + [bitcoin-dev] Combining SPV and Stealth addresses Henning Kopp + 2017-05-04T12:51:00.000Z + + + Chris Pacia + 2017-05-04T16:23:00.000Z + + + Henning Kopp + 2017-05-06T09:38:00.000Z + + - python-feedgen + 2 Combined summary - Combining SPV and Stealth addresses - 2023-08-01T20:33:04.893080+00:00 + 2025-09-26T15:57:34.989171+00:00 - A discussion was initiated by Henning Kopp on the bitcoin-dev mailing list regarding the combination of Stealth addresses with Simplified Payment Verification (SPV). SPV is a mechanism where thin clients can put their public keys in a bloom filter and request Merkle proofs from full nodes for transactions related to those keys, ensuring privacy for the client. Stealth addresses, on the other hand, provide receiver privacy by allowing the sender to derive a one-time pubkey for the recipient to recover the payment.The goal of combining these two methods is to enable the use of stealth addresses on smartphones without compromising privacy. However, a challenge arises when checking if a transaction belongs to a specific pubkey (Q,R) because the full node needs the private scanning key d to verify the equation R' = R + H(dP)*G for each transaction. This requirement raises concerns as providing the private scanning key would link all transactions, undermining privacy.Several ideas were presented in the discussion to address this issue. One suggestion involved modifying the scheme to ensure that the private scanning key d is kept private. However, it was noted that there is no way to recompute d from the equation, making this solution insufficient. Another idea proposed was the use of multiparty computation, but it was deemed costly.The author also mentioned the possibility of search functionality without leaking the search pattern. However, this approach was considered unfeasible since the full node still needs to compute on the data it has found and retrieve the complete Merkle proofs.In conclusion, the author challenges the community to come up with better ideas for combining stealth addresses with SPV in order to achieve privacy on smartphones. It is clear that finding a solution that maintains anonymity while allowing for efficient transaction verification remains an ongoing challenge for the Bitcoin community. 2017-05-06T09:38:06+00:00 + A discussion was initiated by Henning Kopp on the bitcoin-dev mailing list regarding the combination of Stealth addresses with Simplified Payment Verification (SPV). SPV is a mechanism where thin clients can put their public keys in a bloom filter and request Merkle proofs from full nodes for transactions related to those keys, ensuring privacy for the client. Stealth addresses, on the other hand, provide receiver privacy by allowing the sender to derive a one-time pubkey for the recipient to recover the payment.The goal of combining these two methods is to enable the use of stealth addresses on smartphones without compromising privacy. However, a challenge arises when checking if a transaction belongs to a specific pubkey (Q,R) because the full node needs the private scanning key d to verify the equation R' = R + H(dP)*G for each transaction. This requirement raises concerns as providing the private scanning key would link all transactions, undermining privacy.Several ideas were presented in the discussion to address this issue. One suggestion involved modifying the scheme to ensure that the private scanning key d is kept private. However, it was noted that there is no way to recompute d from the equation, making this solution insufficient. Another idea proposed was the use of multiparty computation, but it was deemed costly.The author also mentioned the possibility of search functionality without leaking the search pattern. However, this approach was considered unfeasible since the full node still needs to compute on the data it has found and retrieve the complete Merkle proofs.In conclusion, the author challenges the community to come up with better ideas for combining stealth addresses with SPV in order to achieve privacy on smartphones. It is clear that finding a solution that maintains anonymity while allowing for efficient transaction verification remains an ongoing challenge for the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Compatibility-Oriented-Omnibus-Proposal.xml b/static/bitcoin-dev/May_2017/combined_Compatibility-Oriented-Omnibus-Proposal.xml index 42fd326c0f..f06b97b660 100644 --- a/static/bitcoin-dev/May_2017/combined_Compatibility-Oriented-Omnibus-Proposal.xml +++ b/static/bitcoin-dev/May_2017/combined_Compatibility-Oriented-Omnibus-Proposal.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Compatibility-Oriented Omnibus Proposal - 2023-08-01T20:48:08.740175+00:00 - - Sergio Demian Lerner 2017-06-02 21:57:12+00:00 - - - Jared Lee Richardson 2017-06-02 20:13:58+00:00 - - - CalvinRechner 2017-05-30 22:20:25+00:00 - - - Erik Aronesty 2017-05-30 15:51:17+00:00 - - - Oliver Petruzel 2017-05-29 23:49:59+00:00 - - - Erik Aronesty 2017-05-29 22:52:36+00:00 - - - James Hilliard 2017-05-29 10:19:18+00:00 - - - CalvinRechner 2017-05-29 01:18:13+00:00 - + 2025-09-26T15:57:39.257790+00:00 + python-feedgen + + + [bitcoin-dev] Compatibility-Oriented Omnibus Proposal CalvinRechner + 2017-05-29T01:18:00.000Z + + + James Hilliard + 2017-05-29T10:19:00.000Z + + + Erik Aronesty + 2017-05-29T22:52:00.000Z + + + Oliver Petruzel + 2017-05-29T23:49:00.000Z + + + Erik Aronesty + 2017-05-30T15:51:00.000Z + + + CalvinRechner + 2017-05-30T22:20:00.000Z + + + Jared Lee Richardson + 2017-06-02T20:13:00.000Z + + + Sergio Demian Lerner + 2017-06-02T21:57:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Compatibility-Oriented Omnibus Proposal - 2023-08-01T20:48:08.741173+00:00 + 2025-09-26T15:57:39.259055+00:00 - In a Bitcoin-dev email thread, concerns were raised about the compatibility of LukeJr's suggested 2MB cap with the NY agreement. Users questioned the reasoning behind this decision and suggested incorporating a gradual blocksize increase beyond the initial 2MB cap to satisfy the conditions of the Scaling Agreement. The purpose of the Omnibus Proposal is to achieve the goals of the Consensus 2017 Scaling Agreement while preventing chain-split risks. The proposal sets automatic hard fork rules once SegWit is activated and calls upon the developers of the Segwit2x Team to consider and honor the Omnibus Proposal.There is controversy over including a secondary limit on the block size increase in the segwit + 2mb agreement. Users expect a linear increase in block size when the Base Size is increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. Jared suggests that hard data is needed to justify the secondary limitation or it should be left out in favor of a transaction size limit. Shaolin Fry's "Mandatory activation of segwit deployment" is included to cause the existing "segwit" deployment to activate without needing to release a new deployment. However, this may cause more controversy due to tight timelines and specific signaling requirements.Calvin Rechner believes that incorporating Luke-Jr's 2MB limit and discount-rebalancing would satisfy the conditions of the Scaling Agreement while ensuring maximum safety, minimum code discrepancies, and minimum controversy among the community. He suggests a gradual increase to a larger size cap to achieve cooperation between the community, industry, and developers. The Omnibus Proposal guarantees a successful SegWit activation followed by a hard fork and represents compatibility with existing deployment approaches.The Compatibility-Oriented Omnibus Proposal aims to achieve the goals of the Consensus 2017 Scaling Agreement by minimizing disruption and loss potential. It suggests phasing in a gradual blocksize increase beyond the initial 2MB cap and committing to unity to prevent chain-split risks. The proposal ensures a successful SegWit activation followed by a hard fork, enforcing legacy consensus compatibility until the specified block height. It is designed to serve as a template for achieving true consensus in the Bitcoin community.The current situation in the Bitcoin community involves multiple proposals and potential hard forks. The xkcd comic "Standards" illustrates the problem with having too many competing standards. One potential fork, a rapid 2MB+Segwit hard fork coin, has the potential to fragment the network if not enacted unanimously. BIP148 in Core seems necessary to defend against attacks. LukeJr's proposed 2MB block size hardfork may also become controversial. Oliver Petruzel seeks an explanation for this unexpected outcome.There is a proposal for a 2MB block size hardfork in the Bitcoin community. Experts suggest it as the best way to implement this change, as long as it is adopted unanimously. A block size limit will need to be imposed to enforce the new block size and ensure smooth network operation. The proposal aims to fulfill the commitments of the Consensus 2017 Scaling Agreement.The proposal suggests combining several constituent proposals into a single omnibus proposal and patch set. It plans to activate SegWit at an 80% signaling threshold while also activating a 2MB hard fork within six months. It incorporates protectionary measures to ensure a safe fork activation. The proposal assumes genuine commitment from the signatories of the Scaling Agreement and aims to remain compatible with future network updates.The Compatibility-oriented Omnibus Proposal is an attempt to combine multiple proposals and achieve the goals of the Consensus 2017 Scaling Agreement. It includes various activation options to prevent delays and maximize compatibility. The proposal links the activation of SegWit with a later hard fork block size increase. It imposes a legacy witness discount and a 2MB blocksize limit to ensure a safe fork activation. It is designed to unite the Bitcoin community under a common front.The proposal aims to fulfill the commitments of the Consensus 2017 Scaling Agreement by combining several proposals into a single patch set. It includes activation options and protectionary measures to ensure safe fork activation. Although not likely to be merged into Bitcoin Core immediately, it is written with compatibility in mind. The proposal assumes commitment from the signatories of the agreement and aims to achieve true consensus.Overall, the Bitcoin development community is active and engaged, with various platforms for discussion and collaboration. The proposal provides an opportunity for cooperation and unity while minimizing risks. The availability of resources such as mailing lists and public forums contributes to ongoing innovation in the field of cryptocurrency. 2017-06-02T21:57:12+00:00 + In a Bitcoin-dev email thread, concerns were raised about the compatibility of LukeJr's suggested 2MB cap with the NY agreement. Users questioned the reasoning behind this decision and suggested incorporating a gradual blocksize increase beyond the initial 2MB cap to satisfy the conditions of the Scaling Agreement. The purpose of the Omnibus Proposal is to achieve the goals of the Consensus 2017 Scaling Agreement while preventing chain-split risks. The proposal sets automatic hard fork rules once SegWit is activated and calls upon the developers of the Segwit2x Team to consider and honor the Omnibus Proposal.There is controversy over including a secondary limit on the block size increase in the segwit + 2mb agreement. Users expect a linear increase in block size when the Base Size is increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. Jared suggests that hard data is needed to justify the secondary limitation or it should be left out in favor of a transaction size limit. Shaolin Fry's "Mandatory activation of segwit deployment" is included to cause the existing "segwit" deployment to activate without needing to release a new deployment. However, this may cause more controversy due to tight timelines and specific signaling requirements.Calvin Rechner believes that incorporating Luke-Jr's 2MB limit and discount-rebalancing would satisfy the conditions of the Scaling Agreement while ensuring maximum safety, minimum code discrepancies, and minimum controversy among the community. He suggests a gradual increase to a larger size cap to achieve cooperation between the community, industry, and developers. The Omnibus Proposal guarantees a successful SegWit activation followed by a hard fork and represents compatibility with existing deployment approaches.The Compatibility-Oriented Omnibus Proposal aims to achieve the goals of the Consensus 2017 Scaling Agreement by minimizing disruption and loss potential. It suggests phasing in a gradual blocksize increase beyond the initial 2MB cap and committing to unity to prevent chain-split risks. The proposal ensures a successful SegWit activation followed by a hard fork, enforcing legacy consensus compatibility until the specified block height. It is designed to serve as a template for achieving true consensus in the Bitcoin community.The current situation in the Bitcoin community involves multiple proposals and potential hard forks. The xkcd comic "Standards" illustrates the problem with having too many competing standards. One potential fork, a rapid 2MB+Segwit hard fork coin, has the potential to fragment the network if not enacted unanimously. BIP148 in Core seems necessary to defend against attacks. LukeJr's proposed 2MB block size hardfork may also become controversial. Oliver Petruzel seeks an explanation for this unexpected outcome.There is a proposal for a 2MB block size hardfork in the Bitcoin community. Experts suggest it as the best way to implement this change, as long as it is adopted unanimously. A block size limit will need to be imposed to enforce the new block size and ensure smooth network operation. The proposal aims to fulfill the commitments of the Consensus 2017 Scaling Agreement.The proposal suggests combining several constituent proposals into a single omnibus proposal and patch set. It plans to activate SegWit at an 80% signaling threshold while also activating a 2MB hard fork within six months. It incorporates protectionary measures to ensure a safe fork activation. The proposal assumes genuine commitment from the signatories of the Scaling Agreement and aims to remain compatible with future network updates.The Compatibility-oriented Omnibus Proposal is an attempt to combine multiple proposals and achieve the goals of the Consensus 2017 Scaling Agreement. It includes various activation options to prevent delays and maximize compatibility. The proposal links the activation of SegWit with a later hard fork block size increase. It imposes a legacy witness discount and a 2MB blocksize limit to ensure a safe fork activation. It is designed to unite the Bitcoin community under a common front.The proposal aims to fulfill the commitments of the Consensus 2017 Scaling Agreement by combining several proposals into a single patch set. It includes activation options and protectionary measures to ensure safe fork activation. Although not likely to be merged into Bitcoin Core immediately, it is written with compatibility in mind. The proposal assumes commitment from the signatories of the agreement and aims to achieve true consensus.Overall, the Bitcoin development community is active and engaged, with various platforms for discussion and collaboration. The proposal provides an opportunity for cooperation and unity while minimizing risks. The availability of resources such as mailing lists and public forums contributes to ongoing innovation in the field of cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Drivechain-Request-for-Discussion.xml b/static/bitcoin-dev/May_2017/combined_Drivechain-Request-for-Discussion.xml index 97fd48e65d..d706013af5 100644 --- a/static/bitcoin-dev/May_2017/combined_Drivechain-Request-for-Discussion.xml +++ b/static/bitcoin-dev/May_2017/combined_Drivechain-Request-for-Discussion.xml @@ -1,80 +1,183 @@ - + 2 Combined summary - Drivechain -- Request for Discussion - 2023-08-01T20:40:46.011696+00:00 - - Chris Stewart 2017-06-19 15:41:01+00:00 - - - CryptAxe 2017-06-18 21:27:52+00:00 - - - Chris Stewart 2017-06-18 14:36:24+00:00 - - - Paul Sztorc 2017-06-10 16:28:09+00:00 - - - Sergio Demian Lerner 2017-06-09 21:54:00+00:00 - - - Paul Sztorc 2017-05-30 05:11:51+00:00 - - - Erik Aronesty 2017-05-29 05:54:34+00:00 - - - Peter Todd 2017-05-28 21:07:57+00:00 - - - Tier Nolan 2017-05-25 22:08:00+00:00 - - - CryptAxe 2017-05-24 17:32:22+00:00 - - - Tier Nolan 2017-05-24 10:05:38+00:00 - - - Tier Nolan 2017-05-24 08:50:22+00:00 - - - ZmnSCPxj 2017-05-23 23:26:52+00:00 - - - Paul Sztorc 2017-05-23 14:22:43+00:00 - - - Paul Sztorc 2017-05-23 14:12:24+00:00 - - - Tier Nolan 2017-05-23 09:51:26+00:00 - - - ZmnSCPxj 2017-05-23 00:13:55+00:00 - - - Paul Sztorc 2017-05-22 20:00:19+00:00 - - - Tier Nolan 2017-05-22 19:12:54+00:00 - - - Paul Sztorc 2017-05-22 16:19:14+00:00 - - - Paul Sztorc 2017-05-22 15:30:46+00:00 - - - ZmnSCPxj 2017-05-22 14:39:19+00:00 - - - Peter Todd 2017-05-22 13:33:35+00:00 - - - Paul Sztorc 2017-05-22 06:17:07+00:00 - + 2025-09-26T15:58:17.656567+00:00 + python-feedgen + + + [bitcoin-dev] Drivechain -- Request for Discussion Paul Sztorc + 2017-05-22T06:17:00.000Z + + + Peter Todd + 2017-05-22T13:33:00.000Z + + + ZmnSCPxj + 2017-05-22T14:39:00.000Z + + + Paul Sztorc + 2017-05-22T15:30:00.000Z + + + Paul Sztorc + 2017-05-22T16:19:00.000Z + + + Tier Nolan + 2017-05-22T19:12:00.000Z + + + Paul Sztorc + 2017-05-22T20:00:00.000Z + + + ZmnSCPxj + 2017-05-23T00:13:00.000Z + + + Tier Nolan + 2017-05-23T09:51:00.000Z + + + Paul Sztorc + 2017-05-23T14:12:00.000Z + + + Paul Sztorc + 2017-05-23T14:22:00.000Z + + + ZmnSCPxj + 2017-05-23T23:26:00.000Z + + + Tier Nolan + 2017-05-24T08:50:00.000Z + + + Tier Nolan + 2017-05-24T10:05:00.000Z + + + CryptAxe + 2017-05-24T17:32:00.000Z + + + Tier Nolan + 2017-05-25T22:08:00.000Z + + + Peter Todd + 2017-05-28T21:07:00.000Z + + + Erik Aronesty + 2017-05-29T05:54:00.000Z + + + Paul Sztorc + 2017-05-30T05:11:00.000Z + + + Sergio Demian Lerner + 2017-06-09T21:54:00.000Z + + + Paul Sztorc + 2017-06-10T16:28:00.000Z + + + [bitcoin-dev] Drivechain RfD -- Follow Up Paul Sztorc + 2017-06-10T17:04:00.000Z + + + Chris Stewart + 2017-06-18T14:36:00.000Z + + + CryptAxe + 2017-06-18T21:27:00.000Z + + + Tao Effect + 2017-06-18T21:30:00.000Z + + + Chris Stewart + 2017-06-19T15:41:00.000Z + + + Paul Sztorc + 2017-06-19T16:04:00.000Z + + + Paul Sztorc + 2017-06-20T11:54:00.000Z + + + Erik Aronesty + 2017-06-20T13:38:00.000Z + + + Paul Sztorc + 2017-06-22T13:27:00.000Z + + + Erik Aronesty + 2017-06-22T13:45:00.000Z + + + Paul Sztorc + 2017-06-22T20:30:00.000Z + + + Erik Aronesty + 2017-06-23T14:19:00.000Z + + + Moral Agent + 2017-06-23T14:51:00.000Z + + + Paul Sztorc + 2017-06-23T18:11:00.000Z + + + Tao Effect + 2017-07-12T22:43:00.000Z + + + Paul Sztorc + 2017-07-13T00:26:00.000Z + + + Tao Effect + 2017-07-13T01:15:00.000Z + + + Paul Sztorc + 2017-07-13T02:58:00.000Z + + + Tao Effect + 2017-07-13T03:24:00.000Z + + + Hampus Sjöberg + 2017-07-13T13:17:00.000Z + + + Paul Sztorc + 2017-07-13T15:39:00.000Z + + + Paul Sztorc + 2017-07-13T17:04:00.000Z + + @@ -99,13 +202,13 @@ - python-feedgen + 2 Combined summary - Drivechain -- Request for Discussion - 2023-08-01T20:40:46.011696+00:00 + 2025-09-26T15:58:17.661087+00:00 - In a Bitcoin-Dev mailing list, Paul Sztorc introduced the concept of "Blind Merged Mining" (BMM) as part of his work on "drivechain," a sidechain enabling technology. BMM allows SHA256^2 miners to merge-mine drivechains without running the actual sidechain software, ensuring that sidechains do not affect the fairness of mining. While not necessary for drivechain, BMM addresses some remaining concerns.However, Peter Todd raised concerns about the security properties of BMM, stating that it is weaker than his proposed solution in ZooKeyv. Todd explained that if miners do not validate sidechains, someone could bid the most for the chain and spam invalid headers for months, then withdraw all the coins deposited to the sidechain. Additionally, blind mining prevents miners from determining who should receive the funds. Todd also questioned the incentive for miners to upgrade to full nodes, considering the expenses and time involved.Sztorc has been working on drivechain for some time and provided technical information, changes to Bitcoin related to drivechain, and a blank sidechain template in the email. He has sought feedback at conferences and meetups, such as Scaling Milan, and plans to seek further input at Consensus2017 in New York City.The drivechain upgrade would remove the blocksize limit from the Bitcoin system by adding sidechains through a soft fork. Users who want a larger block Bitcoin can move their BTC to such a network, freeing up space in Bitcoin Core. This upgrade has significant scaling implications and may resolve the scalability debate by allowing users to scale as much as they want through sidechains.Sztorc's proposal includes Blind Merged Mining, which enables SHA256^2 miners to merge-mine drivechains without running the sidechain software. While not mandatory for drivechains, BMM addresses remaining concerns. The author also argues against the need for a maximum block size limit to ensure non-negligible transaction fees in the future.The author compares his drivechain proposal to a recent "Scaling Compromise," highlighting its advantages. Unlike the compromise, Sztorc's proposal does not require a hardfork and can quickly add any amount of extra blockspace. In contrast, the "Scaling Compromise" activates SegWit and then performs a hard fork to double the non-witness blockspace within 12 months.Sztorc acknowledges that those familiar with first and second-generation sidechain technology may find his approach different. He expresses pessimism about scalability discussions and suggests that individuals work on their passion projects until the problems are solved, disappear for other reasons, or until everyone agrees to stop discussing them. 2017-06-19T15:41:01+00:00 + In a Bitcoin-Dev mailing list, Paul Sztorc introduced the concept of "Blind Merged Mining" (BMM) as part of his work on "drivechain," a sidechain enabling technology. BMM allows SHA256^2 miners to merge-mine drivechains without running the actual sidechain software, ensuring that sidechains do not affect the fairness of mining. While not necessary for drivechain, BMM addresses some remaining concerns.However, Peter Todd raised concerns about the security properties of BMM, stating that it is weaker than his proposed solution in ZooKeyv. Todd explained that if miners do not validate sidechains, someone could bid the most for the chain and spam invalid headers for months, then withdraw all the coins deposited to the sidechain. Additionally, blind mining prevents miners from determining who should receive the funds. Todd also questioned the incentive for miners to upgrade to full nodes, considering the expenses and time involved.Sztorc has been working on drivechain for some time and provided technical information, changes to Bitcoin related to drivechain, and a blank sidechain template in the email. He has sought feedback at conferences and meetups, such as Scaling Milan, and plans to seek further input at Consensus2017 in New York City.The drivechain upgrade would remove the blocksize limit from the Bitcoin system by adding sidechains through a soft fork. Users who want a larger block Bitcoin can move their BTC to such a network, freeing up space in Bitcoin Core. This upgrade has significant scaling implications and may resolve the scalability debate by allowing users to scale as much as they want through sidechains.Sztorc's proposal includes Blind Merged Mining, which enables SHA256^2 miners to merge-mine drivechains without running the sidechain software. While not mandatory for drivechains, BMM addresses remaining concerns. The author also argues against the need for a maximum block size limit to ensure non-negligible transaction fees in the future.The author compares his drivechain proposal to a recent "Scaling Compromise," highlighting its advantages. Unlike the compromise, Sztorc's proposal does not require a hardfork and can quickly add any amount of extra blockspace. In contrast, the "Scaling Compromise" activates SegWit and then performs a hard fork to double the non-witness blockspace within 12 months.Sztorc acknowledges that those familiar with first and second-generation sidechain technology may find his approach different. He expresses pessimism about scalability discussions and suggests that individuals work on their passion projects until the problems are solved, disappear for other reasons, or until everyone agrees to stop discussing them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Emergency-Deployment-of-SegWit-as-a-partial-mitigation-of-CVE-2017-9230.xml b/static/bitcoin-dev/May_2017/combined_Emergency-Deployment-of-SegWit-as-a-partial-mitigation-of-CVE-2017-9230.xml index 4f2a30b5a1..66139d3a3d 100644 --- a/static/bitcoin-dev/May_2017/combined_Emergency-Deployment-of-SegWit-as-a-partial-mitigation-of-CVE-2017-9230.xml +++ b/static/bitcoin-dev/May_2017/combined_Emergency-Deployment-of-SegWit-as-a-partial-mitigation-of-CVE-2017-9230.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230 - 2023-08-01T20:47:32.222970+00:00 - - Eric Voskuil 2017-05-31 06:17:59+00:00 - - - Anthony Towns 2017-05-29 11:19:14+00:00 - - - Eric Voskuil 2017-05-27 20:07:58+00:00 - - - Anthony Towns 2017-05-27 06:37:26+00:00 - - - Cameron Garnham 2017-05-26 19:20:42+00:00 - - - Tom Zander 2017-05-26 14:54:03+00:00 - - - Erik Aronesty 2017-05-26 14:39:30+00:00 - - - Tom Zander 2017-05-26 09:21:55+00:00 - - - Eric Voskuil 2017-05-26 08:15:56+00:00 - - - Cameron Garnham 2017-05-26 08:02:27+00:00 - - - Andreas M. Antonopoulos 2017-05-26 06:52:26+00:00 - - - Cameron Garnham 2017-05-26 06:30:08+00:00 - + 2025-09-26T15:57:56.299962+00:00 + python-feedgen + + + [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230 Cameron Garnham + 2017-05-26T06:30:00.000Z + + + Andreas M. Antonopoulos + 2017-05-26T06:52:00.000Z + + + Cameron Garnham + 2017-05-26T08:02:00.000Z + + + Eric Voskuil + 2017-05-26T08:15:00.000Z + + + Tom Zander + 2017-05-26T09:21:00.000Z + + + Erik Aronesty + 2017-05-26T14:39:00.000Z + + + Tom Zander + 2017-05-26T14:54:00.000Z + + + Cameron Garnham + 2017-05-26T19:20:00.000Z + + + Anthony Towns + 2017-05-27T06:37:00.000Z + + + Eric Voskuil + 2017-05-27T20:07:00.000Z + + + Anthony Towns + 2017-05-29T11:19:00.000Z + + + Eric Voskuil + 2017-05-31T06:17:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230 - 2023-08-01T20:47:32.223970+00:00 + 2025-09-26T15:57:56.301511+00:00 - The discussion on the bitcoin-dev mailing list revolves around the impact of the ASICBOOST patent on Bitcoin mining. It is debated whether blocking ASICBoost would decrease everyone's hashrate by the same amount, and if an ASIC patent would have the same formulation as an ASICBoost patent. The conversation concludes that an unblockable mining patent advantage may arise in the future. The possibility of a state licensing regime for miners is also discussed, with concerns raised about license fees and unequal access to optional technology. The defense against a patent is to ignore it and focus on risk-sharing and decentralization. However, it is acknowledged that Bitcoin cannot prevent state patent/licensing/tax regimes and needs to find solutions to cope with them.In another email exchange, the impact of patents on Bitcoin mining is discussed. It is suggested that 67% of miners are using ASICBOOST instead of signaling for SegWit due to a patent owned by former Bitcoin Core developer Sergio Lerner. The feasibility of blocking ASICBOOST is analyzed, and concerns are raised about the potential monopoly and lack of decentralization in Bitcoin mining. There are also discussions about the Bit4 MASF proposal for increasing the block size limit, skepticism about its feasibility, and concerns about miners not signaling for SegWit.Cameron Garnham claims that ASICBOOST is the primary reason for the refusal of 67% of miners to signal for SegWit. Tom Zander questions this assumption and suggests that miners are open to disabling ASICBOOST. The use of SegWit as a partial-mitigation for the security vulnerability ASICBOOST is proposed, along with alternative solutions. The trade-offs of deploying a quick partial-mitigation versus a slower but more conservative approach are debated.A severe security vulnerability called ASICBOOST (CVE-2017-9230) is actively being exploited in the Bitcoin network. It is proposed to use SegWit as a partial-mitigation of ASICBOOST, and there is intense debate over the security trade-offs of deploying a quick partial-mitigation versus a slower approach. Gregory Maxwell proposes an alternative solution to defuse covert ASICBOOST with a segwit-like commitment to the coinbase. The politicization of ASICBOOST is criticized for potentially damaging Bitcoin development and security.The active exploitation of the security vulnerability ASICBOOST (CVE-2017-9230) in the Bitcoin network is discussed. SegWit is proposed as a partial-mitigation for ASICBOOST, and there are debates over the security trade-offs of deploying a quick partial-mitigation versus a slower approach. An alternative proposal by Gregory Maxwell to defuse covert ASICBOOST with a segwit-like commitment to the coinbase is also considered. Concerns are raised about politicizing the issue and potential damage to Bitcoin development and security.Overall, the discussions revolve around the impact of the ASICBOOST patent on Bitcoin mining, the feasibility of blocking ASICBOOST, the use of SegWit as a partial-mitigation, the skepticism towards the Bit4 MASF proposal, and concerns about miners not signaling for SegWit. There is intense debate over the security trade-offs and the need to find solutions to cope with patent/licensing/tax regimes. The context also highlights the severity of the security vulnerability ASICBOOST and the potential risks it poses to Bitcoin. 2017-05-31T06:17:59+00:00 + The discussion on the bitcoin-dev mailing list revolves around the impact of the ASICBOOST patent on Bitcoin mining. It is debated whether blocking ASICBoost would decrease everyone's hashrate by the same amount, and if an ASIC patent would have the same formulation as an ASICBoost patent. The conversation concludes that an unblockable mining patent advantage may arise in the future. The possibility of a state licensing regime for miners is also discussed, with concerns raised about license fees and unequal access to optional technology. The defense against a patent is to ignore it and focus on risk-sharing and decentralization. However, it is acknowledged that Bitcoin cannot prevent state patent/licensing/tax regimes and needs to find solutions to cope with them.In another email exchange, the impact of patents on Bitcoin mining is discussed. It is suggested that 67% of miners are using ASICBOOST instead of signaling for SegWit due to a patent owned by former Bitcoin Core developer Sergio Lerner. The feasibility of blocking ASICBOOST is analyzed, and concerns are raised about the potential monopoly and lack of decentralization in Bitcoin mining. There are also discussions about the Bit4 MASF proposal for increasing the block size limit, skepticism about its feasibility, and concerns about miners not signaling for SegWit.Cameron Garnham claims that ASICBOOST is the primary reason for the refusal of 67% of miners to signal for SegWit. Tom Zander questions this assumption and suggests that miners are open to disabling ASICBOOST. The use of SegWit as a partial-mitigation for the security vulnerability ASICBOOST is proposed, along with alternative solutions. The trade-offs of deploying a quick partial-mitigation versus a slower but more conservative approach are debated.A severe security vulnerability called ASICBOOST (CVE-2017-9230) is actively being exploited in the Bitcoin network. It is proposed to use SegWit as a partial-mitigation of ASICBOOST, and there is intense debate over the security trade-offs of deploying a quick partial-mitigation versus a slower approach. Gregory Maxwell proposes an alternative solution to defuse covert ASICBOOST with a segwit-like commitment to the coinbase. The politicization of ASICBOOST is criticized for potentially damaging Bitcoin development and security.The active exploitation of the security vulnerability ASICBOOST (CVE-2017-9230) in the Bitcoin network is discussed. SegWit is proposed as a partial-mitigation for ASICBOOST, and there are debates over the security trade-offs of deploying a quick partial-mitigation versus a slower approach. An alternative proposal by Gregory Maxwell to defuse covert ASICBOOST with a segwit-like commitment to the coinbase is also considered. Concerns are raised about politicizing the issue and potential damage to Bitcoin development and security.Overall, the discussions revolve around the impact of the ASICBOOST patent on Bitcoin mining, the feasibility of blocking ASICBOOST, the use of SegWit as a partial-mitigation, the skepticism towards the Bit4 MASF proposal, and concerns about miners not signaling for SegWit. There is intense debate over the security trade-offs and the need to find solutions to cope with patent/licensing/tax regimes. The context also highlights the severity of the security vulnerability ASICBOOST and the potential risks it poses to Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml b/static/bitcoin-dev/May_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml index e28a0c6cc8..a3f99793f6 100644 --- a/static/bitcoin-dev/May_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml +++ b/static/bitcoin-dev/May_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Extension block proposal by Jeffrey et al - 2023-08-01T20:14:37.007434+00:00 + 2025-09-26T15:57:41.408110+00:00 + python-feedgen Christopher Jeffrey 2017-05-10 01:19:30+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Extension block proposal by Jeffrey et al - 2023-08-01T20:14:37.008942+00:00 + 2025-09-26T15:57:41.408280+00:00 - A proposal has been made for an extension block that would allow atomic swaps between Bitcoin and Xbitcoin. However, there are concerns about the maturity rule and its impact on legacy wallets. Christopher Jeffrey suggests revising the extension block code to coexist with mainchain segwit and require exiting outputs to only be witness programs. This would mitigate the issue assuming most segwit-supporting wallets implement this rule before the activation of segwit.There is also discussion about allowing direct exit payments to legacy addresses and the lock-up period for exiting outputs. One solution is to add a maturity requirement for exiting outputs, but this would make non-upgraded wallets unusable. Another solution is to move all exiting outputs to the coinbase, but this would deteriorate user experience and essentially become a hardfork. It is suggested that switching to witness programs only and requiring exiting outputs to be witness programs may be a good balance between fungibility and backward-compatibility.The proposal also addresses the issue of making return outputs transparent to unupgraded wallets. The proposed solution is to send them to something non-standard today. The mainchain segwit is important in enabling atomic swaps between Bitcoin and Xbitcoin. The extension block specification/code is being revised to coexist with mainchain segwit and require exiting outputs to only be witness programs.In another discussion, Olaoluwa Osuntokun analyzes the xblock proposal and focuses on the sub-proposal for Lightning Network (LN) safety enhancement. The proposal involves a block-size decrease for each open channel within the network, which reserves space for honest parties to punish dishonest channel counter parties. There is also a proposal for a Pre-Allocated Smart-contract Dispute Arena (PASDA) to address systematic risks in the LN. However, the system has not been fully specified and evaluated yet.Overall, the discussions revolve around the proposed extension block, its compatibility with segwit, the issue of direct exit payments to legacy addresses, and the need for a balance between fungibility and backward-compatibility. The proposal also introduces additional safety measures for Lightning Network (LN) and blockchain availability in case of channel disputes.The writer of the context raises concerns about a new Bitcoin Improvement Proposal (BIP) and expresses disappointment that their proposal was not given more consideration. They criticize the lack of specificity in the proposed approach to resolving transaction malleability and suggest changes to how the merkle root is calculated. Additionally, they question whether direct exit payment to legacy addresses should be allowed and propose limiting the number of soft-fork upgrades, increasing the points for witness v0 outputs, and setting a higher dust threshold.A work-in-progress extension block proposal has been introduced by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. The proposal is available on Github and aims to increase bitcoin transaction throughput without altering existing consensus rules. However, the writer argues that extension blocks create additional complexity compared to other proposals and can potentially create two classes of "full nodes," leaving some insecure. They also mention potential issues with the maximum extension size and the validity of output script code in extension blocks.The Witness Vector specification details that every 73 bytes in the serialized witness vector is worth one additional point, but it doesn't explain why this number was chosen. The writer emphasizes the importance of submitting BIPs in MediaWiki format and for discussion on the bitcoin-dev mailing list rather than social media and news outlets. They assert that extension blocks are more like a hard-fork rather than a soft-fork and highlight the potential legal implications of BIPs not being recognized in certain jurisdictions.The UTXO set behaves fundamentally differently with the extension block proposal, but mostly in a compatible manner. Canonical blocks containing entering outputs must have an extension block commitment, even if it contains all zeroes. The writer suggests adding a special message to the genesis resolution transaction and mentions the possibility of including a witness vector using BIP141 transaction serialization within the extended transaction vector. They also note the enforcement of a consensus dust threshold within the extension block.The deployment name for this specification is "extblk" and appears as "!extblk" in GBT. The writer points out that while the start time for the deactivation deployment is mentioned, there is no information about the timeout or how to continue the extension block. They critique the lack of clarity and specificity in the new BIP and propose alternative solutions. Finally, they caution against specifying policy in BIPs and comment on the potential negative effects of deactivating unused chains. 2017-05-10T01:19:30+00:00 + A proposal has been made for an extension block that would allow atomic swaps between Bitcoin and Xbitcoin. However, there are concerns about the maturity rule and its impact on legacy wallets. Christopher Jeffrey suggests revising the extension block code to coexist with mainchain segwit and require exiting outputs to only be witness programs. This would mitigate the issue assuming most segwit-supporting wallets implement this rule before the activation of segwit.There is also discussion about allowing direct exit payments to legacy addresses and the lock-up period for exiting outputs. One solution is to add a maturity requirement for exiting outputs, but this would make non-upgraded wallets unusable. Another solution is to move all exiting outputs to the coinbase, but this would deteriorate user experience and essentially become a hardfork. It is suggested that switching to witness programs only and requiring exiting outputs to be witness programs may be a good balance between fungibility and backward-compatibility.The proposal also addresses the issue of making return outputs transparent to unupgraded wallets. The proposed solution is to send them to something non-standard today. The mainchain segwit is important in enabling atomic swaps between Bitcoin and Xbitcoin. The extension block specification/code is being revised to coexist with mainchain segwit and require exiting outputs to only be witness programs.In another discussion, Olaoluwa Osuntokun analyzes the xblock proposal and focuses on the sub-proposal for Lightning Network (LN) safety enhancement. The proposal involves a block-size decrease for each open channel within the network, which reserves space for honest parties to punish dishonest channel counter parties. There is also a proposal for a Pre-Allocated Smart-contract Dispute Arena (PASDA) to address systematic risks in the LN. However, the system has not been fully specified and evaluated yet.Overall, the discussions revolve around the proposed extension block, its compatibility with segwit, the issue of direct exit payments to legacy addresses, and the need for a balance between fungibility and backward-compatibility. The proposal also introduces additional safety measures for Lightning Network (LN) and blockchain availability in case of channel disputes.The writer of the context raises concerns about a new Bitcoin Improvement Proposal (BIP) and expresses disappointment that their proposal was not given more consideration. They criticize the lack of specificity in the proposed approach to resolving transaction malleability and suggest changes to how the merkle root is calculated. Additionally, they question whether direct exit payment to legacy addresses should be allowed and propose limiting the number of soft-fork upgrades, increasing the points for witness v0 outputs, and setting a higher dust threshold.A work-in-progress extension block proposal has been introduced by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. The proposal is available on Github and aims to increase bitcoin transaction throughput without altering existing consensus rules. However, the writer argues that extension blocks create additional complexity compared to other proposals and can potentially create two classes of "full nodes," leaving some insecure. They also mention potential issues with the maximum extension size and the validity of output script code in extension blocks.The Witness Vector specification details that every 73 bytes in the serialized witness vector is worth one additional point, but it doesn't explain why this number was chosen. The writer emphasizes the importance of submitting BIPs in MediaWiki format and for discussion on the bitcoin-dev mailing list rather than social media and news outlets. They assert that extension blocks are more like a hard-fork rather than a soft-fork and highlight the potential legal implications of BIPs not being recognized in certain jurisdictions.The UTXO set behaves fundamentally differently with the extension block proposal, but mostly in a compatible manner. Canonical blocks containing entering outputs must have an extension block commitment, even if it contains all zeroes. The writer suggests adding a special message to the genesis resolution transaction and mentions the possibility of including a witness vector using BIP141 transaction serialization within the extended transaction vector. They also note the enforcement of a consensus dust threshold within the extension block.The deployment name for this specification is "extblk" and appears as "!extblk" in GBT. The writer points out that while the start time for the deactivation deployment is mentioned, there is no information about the timeout or how to continue the extension block. They critique the lack of clarity and specificity in the new BIP and propose alternative solutions. Finally, they caution against specifying policy in BIPs and comment on the potential negative effects of deactivating unused chains. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Full-node-tip-function.xml b/static/bitcoin-dev/May_2017/combined_Full-node-tip-function.xml index 423c76b8d5..ff33a95672 100644 --- a/static/bitcoin-dev/May_2017/combined_Full-node-tip-function.xml +++ b/static/bitcoin-dev/May_2017/combined_Full-node-tip-function.xml @@ -1,53 +1,71 @@ - + 2 - Combined summary - Full node "tip" function - 2023-08-01T20:32:49.383275+00:00 - - Sergio Demian Lerner 2017-05-08 22:15:48+00:00 - - - Natanael 2017-05-08 21:44:41+00:00 - - - Sergio Demian Lerner 2017-05-08 21:00:10+00:00 - - - Erik Aronesty 2017-05-04 19:28:10+00:00 - - - Tom Zander 2017-05-04 14:57:59+00:00 - - - Aymeric Vitte 2017-05-04 14:31:11+00:00 - - - Erik Aronesty 2017-05-04 13:47:45+00:00 - - - Aymeric Vitte 2017-05-04 13:37:43+00:00 - - - Erik Aronesty 2017-05-04 13:15:02+00:00 - - - Tomas 2017-05-04 10:38:29+00:00 - - - Luke Dashjr 2017-05-03 23:21:13+00:00 - - - Matt Corallo 2017-05-03 22:03:43+00:00 - - - Gregory Maxwell 2017-05-03 21:53:07+00:00 - - - Ben Thompson 2017-05-03 21:43:16+00:00 - - - Erik Aronesty 2017-05-03 21:08:35+00:00 - + Combined summary - Full node "tip" function + 2025-09-26T15:58:02.653809+00:00 + python-feedgen + + + [bitcoin-dev] Full node "tip" function Erik Aronesty + 2017-05-03T21:08:00.000Z + + + Ben Thompson + 2017-05-03T21:43:00.000Z + + + Gregory Maxwell + 2017-05-03T21:53:00.000Z + + + Matt Corallo + 2017-05-03T22:03:00.000Z + + + Luke Dashjr + 2017-05-03T23:21:00.000Z + + + Tomas + 2017-05-04T10:38:00.000Z + + + Erik Aronesty + 2017-05-04T13:15:00.000Z + + + Aymeric Vitte + 2017-05-04T13:37:00.000Z + + + Erik Aronesty + 2017-05-04T13:47:00.000Z + + + Aymeric Vitte + 2017-05-04T14:31:00.000Z + + + Tom Zander + 2017-05-04T14:57:00.000Z + + + Erik Aronesty + 2017-05-04T19:28:00.000Z + + + Sergio Demian Lerner + 2017-05-08T21:00:00.000Z + + + Natanael + 2017-05-08T21:44:00.000Z + + + Sergio Demian Lerner + 2017-05-08T22:15:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 - Combined summary - Full node "tip" function - 2023-08-01T20:32:49.384271+00:00 + Combined summary - Full node "tip" function + 2025-09-26T15:58:02.655478+00:00 - A proposal was made on the bitcoin-dev mailing list regarding the downloading of the blockchain from full nodes. The proposal suggests that full nodes should advertise a bitcoin address for users to send a tip to the peers that served them. It is recommended that a tip of 10mbit should suffice. This approach aims to incentivize users to contribute to the peers that provided them with blockchain data.However, there are concerns that this could create a barrier for hosting one's own full node, as users would have to pay $15 just to obtain a copy of the blockchain. In response to this concern, the proposal suggests that full nodes can require a tip for downloading the blockchain. In this case, users who do not specify a tip amount would not be able to use these nodes. The intention behind this requirement is to encourage stable nodes to remain online for longer periods and discourage "installation spam" attacks on the network.It is important to note that adding a cost to the blockchain could potentially lead to centralization, as most users are likely to download the blockchain from a node that does not enforce a tip requirement. This raises questions about the long-term implications of the proposal.The proposal also highlights that if a user downloads the blockchain from a full node that requires a tip, they should receive their money back and more as long as the full node remains online. This creates an incentive for quality, long-term hosting of full nodes.If successful, this approach could pave the way for considering fees for other node operations in the future. However, further discussion and consideration are required to address the potential centralization issues and ensure the effectiveness of this proposed system. 2017-05-08T22:15:48+00:00 + A proposal was made on the bitcoin-dev mailing list regarding the downloading of the blockchain from full nodes. The proposal suggests that full nodes should advertise a bitcoin address for users to send a tip to the peers that served them. It is recommended that a tip of 10mbit should suffice. This approach aims to incentivize users to contribute to the peers that provided them with blockchain data.However, there are concerns that this could create a barrier for hosting one's own full node, as users would have to pay $15 just to obtain a copy of the blockchain. In response to this concern, the proposal suggests that full nodes can require a tip for downloading the blockchain. In this case, users who do not specify a tip amount would not be able to use these nodes. The intention behind this requirement is to encourage stable nodes to remain online for longer periods and discourage "installation spam" attacks on the network.It is important to note that adding a cost to the blockchain could potentially lead to centralization, as most users are likely to download the blockchain from a node that does not enforce a tip requirement. This raises questions about the long-term implications of the proposal.The proposal also highlights that if a user downloads the blockchain from a full node that requires a tip, they should receive their money back and more as long as the full node remains online. This creates an incentive for quality, long-term hosting of full nodes.If successful, this approach could pave the way for considering fees for other node operations in the future. However, further discussion and consideration are required to address the potential centralization issues and ensure the effectiveness of this proposed system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Hypothetical-2-MB-hardfork-to-follow-BIP148.xml b/static/bitcoin-dev/May_2017/combined_Hypothetical-2-MB-hardfork-to-follow-BIP148.xml index d45adecd77..e3035099e1 100644 --- a/static/bitcoin-dev/May_2017/combined_Hypothetical-2-MB-hardfork-to-follow-BIP148.xml +++ b/static/bitcoin-dev/May_2017/combined_Hypothetical-2-MB-hardfork-to-follow-BIP148.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Hypothetical 2 MB hardfork to follow BIP148 - 2023-08-01T20:46:29.371616+00:00 - - Nathan Cook 2017-06-12 16:27:14+00:00 - - - Jared Lee Richardson 2017-06-02 19:40:36+00:00 - - - Luke Dashjr 2017-05-31 04:14:25+00:00 - - - Jacob Eliosoff 2017-05-31 03:07:43+00:00 - - - Jorge Timón 2017-05-31 01:22:44+00:00 - - - Jean-Paul Kogelman 2017-05-31 01:09:26+00:00 - - - James MacWhyte 2017-05-30 23:50:01+00:00 - - - Jorge Timón 2017-05-30 22:26:20+00:00 - - - Mark Friedenbach 2017-05-30 21:24:20+00:00 - - - Jacob Eliosoff 2017-05-30 20:10:04+00:00 - - - Jorge Timón 2017-05-30 13:27:58+00:00 - - - Erik Aronesty 2017-05-23 23:07:41+00:00 - - - Luke Dashjr 2017-05-23 20:23:40+00:00 - + 2025-09-26T15:58:19.782990+00:00 + python-feedgen + + + [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 Luke Dashjr + 2017-05-23T20:23:00.000Z + + + Erik Aronesty + 2017-05-23T23:07:00.000Z + + + Jorge Timón + 2017-05-30T13:27:00.000Z + + + Jacob Eliosoff + 2017-05-30T20:10:00.000Z + + + Mark Friedenbach + 2017-05-30T21:24:00.000Z + + + Jorge Timón + 2017-05-30T22:26:00.000Z + + + James MacWhyte + 2017-05-30T23:50:00.000Z + + + Jean-Paul Kogelman + 2017-05-31T01:09:00.000Z + + + Jorge Timón + 2017-05-31T01:22:00.000Z + + + Jacob Eliosoff + 2017-05-31T03:07:00.000Z + + + Luke Dashjr + 2017-05-31T04:14:00.000Z + + + Jared Lee Richardson + 2017-06-02T19:40:00.000Z + + + Nathan Cook + 2017-06-12T16:27:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Hypothetical 2 MB hardfork to follow BIP148 - 2023-08-01T20:46:29.371616+00:00 + 2025-09-26T15:58:19.784500+00:00 - The discussion on the bitcoin-dev mailing list revolves around the need for a transaction size limit to address the quadratic hashing problem. Various proposals have been made, including adding a transaction-size limit of 10kb or 100kb, reducing the block size limit to 1MB initially and then dropping it to 500kb or 100kb at a later block height, and implementing a real 2MB block size hardfork following Segwit BIP148 activation.One proposed change suggests enforcing a block size limit of 2,000,000 bytes upon activation, while keeping the block weight limit at 4,000,000 WU. The proposal eliminates the witness commitment in the generation transaction and replaces it with a hash of the witness reserved value, the witness merkle root hash, and the transaction ID merkle root hash. Additionally, the maximum size of a transaction without witness data is limited to 1 MB.Although this proposal is considered risky and is not endorsed by the author, it provides a possible option for a 2 MB block size hardfork following Segwit BIP148 activation. However, deploying this proposal would require consensus from the entire Bitcoin community and is scheduled for 18 months after the creation date of the BIP.The proposed change enforces a block size limit of 2 MB for legacy Bitcoin transactions, with a corresponding block weight limit of 4000000 WU. The calculation of block weight is modified, assigning a weight of 1 WU to all witness data and 4 WU to all other data. As a result, the witness commitment in the generation transaction is no longer required. Instead, the txid merkle root in the block header is replaced with a hash of the witness reserved value, the witness merkle root hash, and the transaction ID merkle root hash.This proposal is set to be deployed on a flag day, which is the block where the median-past time surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC). It assumes that Segwit has already been activated through BIP141 and/or BIP148. It's important to note that this change represents a hardfork and is not backward compatible. Therefore, it should not be deployed without the consent of the entire Bitcoin community.Activation of this proposal is scheduled for 18 months from the creation date of this BIP. The intention behind this timeline is to provide 6 months to establish consensus and 12 months for deployment. The author has left the motivation and rationale sections blank, urging whoever champions this proposal to complete them. 2017-06-12T16:27:14+00:00 + The discussion on the bitcoin-dev mailing list revolves around the need for a transaction size limit to address the quadratic hashing problem. Various proposals have been made, including adding a transaction-size limit of 10kb or 100kb, reducing the block size limit to 1MB initially and then dropping it to 500kb or 100kb at a later block height, and implementing a real 2MB block size hardfork following Segwit BIP148 activation.One proposed change suggests enforcing a block size limit of 2,000,000 bytes upon activation, while keeping the block weight limit at 4,000,000 WU. The proposal eliminates the witness commitment in the generation transaction and replaces it with a hash of the witness reserved value, the witness merkle root hash, and the transaction ID merkle root hash. Additionally, the maximum size of a transaction without witness data is limited to 1 MB.Although this proposal is considered risky and is not endorsed by the author, it provides a possible option for a 2 MB block size hardfork following Segwit BIP148 activation. However, deploying this proposal would require consensus from the entire Bitcoin community and is scheduled for 18 months after the creation date of the BIP.The proposed change enforces a block size limit of 2 MB for legacy Bitcoin transactions, with a corresponding block weight limit of 4000000 WU. The calculation of block weight is modified, assigning a weight of 1 WU to all witness data and 4 WU to all other data. As a result, the witness commitment in the generation transaction is no longer required. Instead, the txid merkle root in the block header is replaced with a hash of the witness reserved value, the witness merkle root hash, and the transaction ID merkle root hash.This proposal is set to be deployed on a flag day, which is the block where the median-past time surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC). It assumes that Segwit has already been activated through BIP141 and/or BIP148. It's important to note that this change represents a hardfork and is not backward compatible. Therefore, it should not be deployed without the consent of the entire Bitcoin community.Activation of this proposal is scheduled for 18 months from the creation date of this BIP. The intention behind this timeline is to provide 6 months to establish consensus and 12 months for deployment. The author has left the motivation and rationale sections blank, urging whoever champions this proposal to complete them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_I-do-not-support-the-BIP-148-UASF.xml b/static/bitcoin-dev/May_2017/combined_I-do-not-support-the-BIP-148-UASF.xml index b8b82ee22d..b7dc748689 100644 --- a/static/bitcoin-dev/May_2017/combined_I-do-not-support-the-BIP-148-UASF.xml +++ b/static/bitcoin-dev/May_2017/combined_I-do-not-support-the-BIP-148-UASF.xml @@ -1,131 +1,175 @@ - + 2 Combined summary - I do not support the BIP 148 UASF - 2023-08-01T20:25:06.816096+00:00 - - Jorge Timón 2017-05-23 13:20:10+00:00 - - - Luke Dashjr 2017-05-23 12:55:26+00:00 - - - Hampus Sjöberg 2017-05-23 09:47:48+00:00 - - - Karl Johan Alm 2017-05-23 06:30:01+00:00 - - - Steven Pine 2017-05-23 04:03:49+00:00 - - - Suhas Daftuar 2017-05-22 19:23:22+00:00 - - - Erik Aronesty 2017-05-02 16:54:35+00:00 - - - Luke Dashjr 2017-04-25 18:46:09+00:00 - - - Gregory Maxwell 2017-04-25 18:28:14+00:00 - - - shaolinfry 2017-04-20 18:39:36+00:00 - - - Erik Aronesty 2017-04-20 15:48:21+00:00 - - - Alphonse Pace 2017-04-20 14:23:40+00:00 - - - Erik Aronesty 2017-04-19 16:17:39+00:00 - - - Gregory Maxwell 2017-04-15 18:50:17+00:00 - - - Ryan Grant 2017-04-15 14:54:00+00:00 - - - Greg Sanders 2017-04-15 13:54:57+00:00 - - - Mark Friedenbach 2017-04-15 13:42:25+00:00 - - - Natanael 2017-04-15 13:23:35+00:00 - - - Cameron Garnham 2017-04-15 08:05:10+00:00 - - - Chris Acheson 2017-04-15 07:46:47+00:00 - - - Gregory Maxwell 2017-04-15 07:04:45+00:00 - - - Cameron Garnham 2017-04-15 06:28:41+00:00 - - - Gregory Maxwell 2017-04-15 04:47:43+00:00 - - - Steven Pine 2017-04-15 04:10:26+00:00 - - - Gregory Maxwell 2017-04-15 03:29:10+00:00 - - - Chris Stewart 2017-04-15 03:05:25+00:00 - - - Steven Pine 2017-04-15 02:01:17+00:00 - - - Gregory Maxwell 2017-04-14 21:12:47+00:00 - - - James Hilliard 2017-04-14 21:10:46+00:00 - - - Gregory Maxwell 2017-04-14 20:59:55+00:00 - - - Tom Zander 2017-04-14 20:58:15+00:00 - - - James Hilliard 2017-04-14 20:51:04+00:00 - - - Tom Zander 2017-04-14 20:34:26+00:00 - - - James Hilliard 2017-04-14 19:33:49+00:00 - - - Tom Zander 2017-04-14 19:20:39+00:00 - - - Tom Zander 2017-04-14 19:12:19+00:00 - - - praxeology_guy 2017-04-14 18:33:39+00:00 - - - Chris Stewart 2017-04-14 17:36:34+00:00 - - - praxeology_guy 2017-04-14 16:50:47+00:00 - - - Chris Acheson 2017-04-14 10:52:46+00:00 - - - Gregory Maxwell 2017-04-14 07:56:31+00:00 - + 2025-09-26T15:58:24.055227+00:00 + python-feedgen + + + [bitcoin-dev] I do not support the BIP 148 UASF Gregory Maxwell + 2017-04-14T07:56:00.000Z + + + Chris Acheson + 2017-04-14T10:52:00.000Z + + + praxeology_guy + 2017-04-14T16:50:00.000Z + + + Chris Stewart + 2017-04-14T17:36:00.000Z + + + praxeology_guy + 2017-04-14T18:33:00.000Z + + + Tom Zander + 2017-04-14T19:12:00.000Z + + + Tom Zander + 2017-04-14T19:20:00.000Z + + + James Hilliard + 2017-04-14T19:33:00.000Z + + + Tom Zander + 2017-04-14T20:34:00.000Z + + + James Hilliard + 2017-04-14T20:51:00.000Z + + + Tom Zander + 2017-04-14T20:58:00.000Z + + + Gregory Maxwell + 2017-04-14T20:59:00.000Z + + + James Hilliard + 2017-04-14T21:10:00.000Z + + + Gregory Maxwell + 2017-04-14T21:12:00.000Z + + + Steven Pine + 2017-04-15T02:01:00.000Z + + + Chris Stewart + 2017-04-15T03:05:00.000Z + + + Gregory Maxwell + 2017-04-15T03:29:00.000Z + + + Steven Pine + 2017-04-15T04:10:00.000Z + + + Gregory Maxwell + 2017-04-15T04:47:00.000Z + + + Cameron Garnham + 2017-04-15T06:28:00.000Z + + + Gregory Maxwell + 2017-04-15T07:04:00.000Z + + + Chris Acheson + 2017-04-15T07:46:00.000Z + + + Cameron Garnham + 2017-04-15T08:05:00.000Z + + + Natanael + 2017-04-15T13:23:00.000Z + + + Mark Friedenbach + 2017-04-15T13:42:00.000Z + + + Greg Sanders + 2017-04-15T13:54:00.000Z + + + Ryan Grant + 2017-04-15T14:54:00.000Z + + + Gregory Maxwell + 2017-04-15T18:50:00.000Z + + + Erik Aronesty + 2017-04-19T16:17:00.000Z + + + Alphonse Pace + 2017-04-20T14:23:00.000Z + + + Erik Aronesty + 2017-04-20T15:48:00.000Z + + + shaolinfry + 2017-04-20T18:39:00.000Z + + + Gregory Maxwell + 2017-04-25T18:28:00.000Z + + + Luke Dashjr + 2017-04-25T18:46:00.000Z + + + Erik Aronesty + 2017-05-02T16:54:00.000Z + + + Suhas Daftuar + 2017-05-22T19:23:00.000Z + + + Steven Pine + 2017-05-23T04:03:00.000Z + + + Karl Johan Alm + 2017-05-23T06:30:00.000Z + + + Hampus Sjöberg + 2017-05-23T09:47:00.000Z + + + Luke Dashjr + 2017-05-23T12:55:00.000Z + + + Jorge Timón + 2017-05-23T13:20:00.000Z + + @@ -167,13 +211,13 @@ - python-feedgen + 2 Combined summary - I do not support the BIP 148 UASF - 2023-08-01T20:25:06.816096+00:00 + 2025-09-26T15:58:24.059184+00:00 - The ongoing discussion within the bitcoin-dev community revolves around the activation of Segwit in Bitcoin. There are debates and concerns raised regarding the User Activated Soft Fork (UASF) proposal for activating soft forks. One member questions the requirement for public support while not allowing members to express doubts about the UASF proposal. Concerns are raised about the effectiveness and reliability of UASF, as well as the potential for consensus bugs and the inability for nodes to identify invalid transactions.Another member expresses disappointment over public statements against UASF proposals, stating that they detract from grassroots efforts. Mark Friedenbach suggests a new proposal called "Catch-All Segwit Activation" as a potential solution to address this issue.Discussions focus on the safety and effectiveness of UASFs, with arguments made for orphaning non-compliant blocks on the flag date rather than considering the fork active on that date. Concerns about consensus bugs and the lack of communication between nodes regarding invalid transactions are also raised.The controversy surrounding BIP16 vs BIP17 is discussed, with criticisms of the inferior solution resulting from the split. The need for careful review and consideration of specific proposals is emphasized, rather than rushing to implement something quickly. The ongoing scaling debate within the Bitcoin community is mentioned, with calls for a quick resolution and the prioritization of user needs over miners.Conversations also address the technical requirements for timeout and bit assignments in BIP9. BIP148 is classified as a "user enforced miner soft-fork activation" rather than a UASF. The limitation of this approach, in terms of disruptiveness, is acknowledged.Discussions touch on the activation of SegWit and the expectations surrounding it. It is clarified that SegWit will continue to be used until a better solution comes along or interest in it diminishes. The lack of a clear definition of "the core team" is highlighted, making it difficult for outsiders to make credible proposals without contributing to the project. Caution is urged, with a reminder that changes in decentralized systems like Bitcoin cannot be expected to happen at the same speed as centralized systems.Overall, the discussions revolve around the effectiveness, safety, and controversies surrounding UASFs, BIPs, and the activation of SegWit in the Bitcoin community.Gregory Maxwell expresses reservations about the UASF approach to force Segwit activation, advocating for a patient approach instead. He suggests alternative ways to achieve the benefits of Segwit, such as removing the discount on signature data to address UTXO bloat. Despite differences in approach, most agree that Segwit will bring significant improvements to Bitcoin, including the elimination of transaction malleability and script versioning.Maxwell supports Segwit but criticizes the BIP148 UASF proposal for its disruptive nature. He believes that the forced activation of existing nodes almost guarantees disruption, while Segwit was designed to allow older unmodified miners to continue operating without interruption. Maxwell emphasizes the importance of maintaining Bitcoin's engineering standards and stability, suggesting less disruptive mechanisms and patience in activating Segwit.Discussions address the risk of non-upgraded nodes mining invalid blocks on a SegWit network. While there are concerns, it is clarified that the only real risk lies in intentionally mining on top of an invalid block, which is unlikely to happen accidentally.The conversation delves into the policy and protocol rules for mining transactions on the blockchain. It is explained that policy rules are not guaranteed to be present on all mining nodes, necessitating consensus rule enforcement to avoid chain forks.Concerns about orphaning and forking caused by the BIP148 proposal are discussed. Suggestions are made to reject only blocks containing Segwit transactions rather than rejecting all pre-Segwit transaction blocks. Various proposals for a reliable activation method are discussed, with differing opinions on the most practical approach. However, it is agreed that Segwit has undergone enough testing and it is time to activate it.There are arguments about the disruptive nature of the BIP148 UASF proposal for miners who do not upgrade. Alternative proposals aim to avoid forced disruption by allowing non-upgraded miners and nodes to continue operating as non-upgraded. The prioritization of minimizing disruption for users is emphasized, with the expectation that all miners will eventually upgrade after the initial disruption. The forced orphaning aspect of the proposal is seen as an unavoidable side-effect to make the UASF less disruptive for Bitcoin users.The author of this piece supports the implementation of segwit in Bitcoin but expresses their lack of support for the BIP148 UASF proposal. They argue that BIP148 does not meet the same engineering standards as segwit and best practices in protocol development. The main flaw with BIP148 is the forced activation of existing nodes, which may cause minor disruption. In contrast, segwit was designed to ensure that older unmodified miners could continue operating without interruption after activation.While acknowledging the motivation behind the BIP148 proposal, the author believes it falls short of the normal standards upheld by the Bitcoin 2017-05-23T13:20:10+00:00 + The ongoing discussion within the bitcoin-dev community revolves around the activation of Segwit in Bitcoin. There are debates and concerns raised regarding the User Activated Soft Fork (UASF) proposal for activating soft forks. One member questions the requirement for public support while not allowing members to express doubts about the UASF proposal. Concerns are raised about the effectiveness and reliability of UASF, as well as the potential for consensus bugs and the inability for nodes to identify invalid transactions.Another member expresses disappointment over public statements against UASF proposals, stating that they detract from grassroots efforts. Mark Friedenbach suggests a new proposal called "Catch-All Segwit Activation" as a potential solution to address this issue.Discussions focus on the safety and effectiveness of UASFs, with arguments made for orphaning non-compliant blocks on the flag date rather than considering the fork active on that date. Concerns about consensus bugs and the lack of communication between nodes regarding invalid transactions are also raised.The controversy surrounding BIP16 vs BIP17 is discussed, with criticisms of the inferior solution resulting from the split. The need for careful review and consideration of specific proposals is emphasized, rather than rushing to implement something quickly. The ongoing scaling debate within the Bitcoin community is mentioned, with calls for a quick resolution and the prioritization of user needs over miners.Conversations also address the technical requirements for timeout and bit assignments in BIP9. BIP148 is classified as a "user enforced miner soft-fork activation" rather than a UASF. The limitation of this approach, in terms of disruptiveness, is acknowledged.Discussions touch on the activation of SegWit and the expectations surrounding it. It is clarified that SegWit will continue to be used until a better solution comes along or interest in it diminishes. The lack of a clear definition of "the core team" is highlighted, making it difficult for outsiders to make credible proposals without contributing to the project. Caution is urged, with a reminder that changes in decentralized systems like Bitcoin cannot be expected to happen at the same speed as centralized systems.Overall, the discussions revolve around the effectiveness, safety, and controversies surrounding UASFs, BIPs, and the activation of SegWit in the Bitcoin community.Gregory Maxwell expresses reservations about the UASF approach to force Segwit activation, advocating for a patient approach instead. He suggests alternative ways to achieve the benefits of Segwit, such as removing the discount on signature data to address UTXO bloat. Despite differences in approach, most agree that Segwit will bring significant improvements to Bitcoin, including the elimination of transaction malleability and script versioning.Maxwell supports Segwit but criticizes the BIP148 UASF proposal for its disruptive nature. He believes that the forced activation of existing nodes almost guarantees disruption, while Segwit was designed to allow older unmodified miners to continue operating without interruption. Maxwell emphasizes the importance of maintaining Bitcoin's engineering standards and stability, suggesting less disruptive mechanisms and patience in activating Segwit.Discussions address the risk of non-upgraded nodes mining invalid blocks on a SegWit network. While there are concerns, it is clarified that the only real risk lies in intentionally mining on top of an invalid block, which is unlikely to happen accidentally.The conversation delves into the policy and protocol rules for mining transactions on the blockchain. It is explained that policy rules are not guaranteed to be present on all mining nodes, necessitating consensus rule enforcement to avoid chain forks.Concerns about orphaning and forking caused by the BIP148 proposal are discussed. Suggestions are made to reject only blocks containing Segwit transactions rather than rejecting all pre-Segwit transaction blocks. Various proposals for a reliable activation method are discussed, with differing opinions on the most practical approach. However, it is agreed that Segwit has undergone enough testing and it is time to activate it.There are arguments about the disruptive nature of the BIP148 UASF proposal for miners who do not upgrade. Alternative proposals aim to avoid forced disruption by allowing non-upgraded miners and nodes to continue operating as non-upgraded. The prioritization of minimizing disruption for users is emphasized, with the expectation that all miners will eventually upgrade after the initial disruption. The forced orphaning aspect of the proposal is seen as an unavoidable side-effect to make the UASF less disruptive for Bitcoin users.The author of this piece supports the implementation of segwit in Bitcoin but expresses their lack of support for the BIP148 UASF proposal. They argue that BIP148 does not meet the same engineering standards as segwit and best practices in protocol development. The main flaw with BIP148 is the forced activation of existing nodes, which may cause minor disruption. In contrast, segwit was designed to ensure that older unmodified miners could continue operating without interruption after activation.While acknowledging the motivation behind the BIP148 proposal, the author believes it falls short of the normal standards upheld by the Bitcoin - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Improvement-Proposal.xml b/static/bitcoin-dev/May_2017/combined_Improvement-Proposal.xml index 8f3fd4daa2..5c560da1e6 100644 --- a/static/bitcoin-dev/May_2017/combined_Improvement-Proposal.xml +++ b/static/bitcoin-dev/May_2017/combined_Improvement-Proposal.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Improvement Proposal - 2023-08-01T20:48:54.876106+00:00 - - praxeology_guy 2017-05-30 17:30:55+00:00 - - - Yann Carlier 2017-05-30 13:48:30+00:00 - + 2025-09-26T15:58:11.201827+00:00 + python-feedgen + + + [bitcoin-dev] Improvement Proposal Yann Carlier + 2017-05-30T13:48:00.000Z + + + praxeology_guy + 2017-05-30T17:30:00.000Z + + - python-feedgen + 2 Combined summary - Improvement Proposal - 2023-08-01T20:48:54.876106+00:00 + 2025-09-26T15:58:11.202292+00:00 - A proposal was put forward on the Bitcoin-dev mailing list to enable users to participate in the BTC blockchain network without mining. The proposal suggested implementing a lottery system that would run alongside mining, where lucky participants would be randomly rewarded at specific intervals of time. However, Yann raised concerns about the feasibility of this idea due to the potential for Sybil attacks. Even if there was a way to prove that an entity performed transaction validation, Sybil attacks could still undermine the system. Additionally, proving the relay of transaction data to others is also vulnerable to Sybil attacks.To address these issues, the improvement proposal suggests allowing devices, including mobile and IoT devices, to connect and participate in the BTC blockchain network without mining. Participants would have the opportunity to take part in a lottery scheme that operates parallel to mining within the same network and on the blockchain. The incentive for these participants would be the chance to be randomly rewarded at regular intervals of time. However, it should be noted that participants would need to pay a price for each connection round.Overall, the proposal aims to expand participation in the BTC blockchain network by providing an alternative means for users to engage with the system. By incorporating a lottery system, it offers an additional incentive for users to connect their devices and contribute to the network. However, the potential vulnerabilities to Sybil attacks must be carefully considered and addressed to ensure the effectiveness and security of the proposed system. 2017-05-30T17:30:55+00:00 + A proposal was put forward on the Bitcoin-dev mailing list to enable users to participate in the BTC blockchain network without mining. The proposal suggested implementing a lottery system that would run alongside mining, where lucky participants would be randomly rewarded at specific intervals of time. However, Yann raised concerns about the feasibility of this idea due to the potential for Sybil attacks. Even if there was a way to prove that an entity performed transaction validation, Sybil attacks could still undermine the system. Additionally, proving the relay of transaction data to others is also vulnerable to Sybil attacks.To address these issues, the improvement proposal suggests allowing devices, including mobile and IoT devices, to connect and participate in the BTC blockchain network without mining. Participants would have the opportunity to take part in a lottery scheme that operates parallel to mining within the same network and on the blockchain. The incentive for these participants would be the chance to be randomly rewarded at regular intervals of time. However, it should be noted that participants would need to pay a price for each connection round.Overall, the proposal aims to expand participation in the BTC blockchain network by providing an alternative means for users to engage with the system. By incorporating a lottery system, it offers an additional incentive for users to connect their devices and contribute to the network. However, the potential vulnerabilities to Sybil attacks must be carefully considered and addressed to ensure the effectiveness and security of the proposed system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Network-layer-attacks.xml b/static/bitcoin-dev/May_2017/combined_Network-layer-attacks.xml index b381446d7e..d06cc52879 100644 --- a/static/bitcoin-dev/May_2017/combined_Network-layer-attacks.xml +++ b/static/bitcoin-dev/May_2017/combined_Network-layer-attacks.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Network-layer attacks - 2023-08-01T20:35:35.860644+00:00 - - Eric Voskuil 2017-05-09 23:11:31+00:00 - - - Greg Sanders 2017-05-09 18:05:43+00:00 - - - Raystonn . 2017-05-09 16:09:09+00:00 - + 2025-09-26T15:57:49.880029+00:00 + python-feedgen + + + [bitcoin-dev] Network-layer attacks Raystonn . + 2017-05-09T16:09:00.000Z + + + Greg Sanders + 2017-05-09T18:05:00.000Z + + + Eric Voskuil + 2017-05-09T23:11:00.000Z + + - python-feedgen + 2 Combined summary - Network-layer attacks - 2023-08-01T20:35:35.860644+00:00 + 2025-09-26T15:57:49.880649+00:00 - In response to the study, the author of this response disagrees with the proposed solution of encrypting traffic among miners. They argue that encryption alone cannot identify the intended miner and could potentially be exploited by attackers. Instead, the author suggests using authenticated connections as a means of securing the network. The paper acknowledges that encryption is not effective in mitigating certain risks, such as isolating a smaller set of nodes for extended periods or biased outgoing connections. To address these issues, the paper recommends several countermeasures. These include increasing the diversity of node connections, selecting Bitcoin peers while considering routing, monitoring round-trip time (RTT), embracing churn, using gateways in different ASes, preferring peers hosted in the same AS and in /24 prefixes, using distinct control and data channels, employing UDP heartbeats, and requesting blocks on multiple connections. The author emphasizes the importance of authentication in centralizing the network and highlights that the most obvious solution is not always the most effective.The message posted on the Bitcoin-dev mailing list provided links to Bip proposals (bip-0150.mediawiki and bip-0151.mediawiki) related to the use of encryption in securing communications between nodes. However, no further details about the study or its findings were given.Overall, the study contributes valuable insights into the risks posed to the Bitcoin peer-to-peer network and individual nodes, as well as suggesting potential mitigations. It cautions against relying solely on encryption due to associated risks of centralization, highlighting the need for authenticated connections as an alternative approach. 2017-05-09T23:11:31+00:00 + In response to the study, the author of this response disagrees with the proposed solution of encrypting traffic among miners. They argue that encryption alone cannot identify the intended miner and could potentially be exploited by attackers. Instead, the author suggests using authenticated connections as a means of securing the network. The paper acknowledges that encryption is not effective in mitigating certain risks, such as isolating a smaller set of nodes for extended periods or biased outgoing connections. To address these issues, the paper recommends several countermeasures. These include increasing the diversity of node connections, selecting Bitcoin peers while considering routing, monitoring round-trip time (RTT), embracing churn, using gateways in different ASes, preferring peers hosted in the same AS and in /24 prefixes, using distinct control and data channels, employing UDP heartbeats, and requesting blocks on multiple connections. The author emphasizes the importance of authentication in centralizing the network and highlights that the most obvious solution is not always the most effective.The message posted on the Bitcoin-dev mailing list provided links to Bip proposals (bip-0150.mediawiki and bip-0151.mediawiki) related to the use of encryption in securing communications between nodes. However, no further details about the study or its findings were given.Overall, the study contributes valuable insights into the risks posed to the Bitcoin peer-to-peer network and individual nodes, as well as suggesting potential mitigations. It cautions against relying solely on encryption due to associated risks of centralization, highlighting the need for authenticated connections as an alternative approach. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Non-confirming-block-signalling.xml b/static/bitcoin-dev/May_2017/combined_Non-confirming-block-signalling.xml index 9726970f80..7ffadb4b44 100644 --- a/static/bitcoin-dev/May_2017/combined_Non-confirming-block-signalling.xml +++ b/static/bitcoin-dev/May_2017/combined_Non-confirming-block-signalling.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Non-confirming block signalling - 2023-08-01T20:33:15.199394+00:00 + 2025-09-26T15:58:15.460226+00:00 + python-feedgen Tomas 2017-05-05 13:09:17+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Non-confirming block signalling - 2023-08-01T20:33:15.199394+00:00 + 2025-09-26T15:58:15.460355+00:00 - On May 5, 2017, Tomas proposed a method to mark blocks indicating that they were generated without verifying the previous block by using a bit of the version field. This proposal aims to address the issue of reduced security caused by SPV-mining. Bryan Bishop responded to the proposal, acknowledging that it had been previously discussed in a Bitcoin-dev mailing list post from December 2015, which he provided a link to. Tomas's suggestion involves utilizing a specific bit in the version field to indicate blocks that were generated without verifying the previous block. By implementing this marking system, the potential risks associated with SPV-mining can be mitigated. It is important to note that the idea had already been discussed in a Bitcoin-dev mailing list post in December 2015, and Bryan Bishop shared the link to this discussion.In addition to the proposal and the reference to the earlier discussion, Bryan included his contact information in his email signature. His personal website, heybryan.org, was provided along with his phone number. This information allows for further communication and collaboration on the topic.For more detailed information about the proposal, including the full proposal document and related discussions, the BIP can be found on Tomas's GitHub page. 2017-05-05T13:09:17+00:00 + On May 5, 2017, Tomas proposed a method to mark blocks indicating that they were generated without verifying the previous block by using a bit of the version field. This proposal aims to address the issue of reduced security caused by SPV-mining. Bryan Bishop responded to the proposal, acknowledging that it had been previously discussed in a Bitcoin-dev mailing list post from December 2015, which he provided a link to. Tomas's suggestion involves utilizing a specific bit in the version field to indicate blocks that were generated without verifying the previous block. By implementing this marking system, the potential risks associated with SPV-mining can be mitigated. It is important to note that the idea had already been discussed in a Bitcoin-dev mailing list post in December 2015, and Bryan Bishop shared the link to this discussion.In addition to the proposal and the reference to the earlier discussion, Bryan included his contact information in his email signature. His personal website, heybryan.org, was provided along with his phone number. This information allows for further communication and collaboration on the topic.For more detailed information about the proposal, including the full proposal document and related discussions, the BIP can be found on Tomas's GitHub page. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Per-block-non-interactive-Schnorr-signature-aggregation.xml b/static/bitcoin-dev/May_2017/combined_Per-block-non-interactive-Schnorr-signature-aggregation.xml index 066fcad28f..a9e467b286 100644 --- a/static/bitcoin-dev/May_2017/combined_Per-block-non-interactive-Schnorr-signature-aggregation.xml +++ b/static/bitcoin-dev/May_2017/combined_Per-block-non-interactive-Schnorr-signature-aggregation.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Per-block non-interactive Schnorr signature aggregation - 2023-08-01T20:33:41.352835+00:00 - - adiabat 2017-05-10 14:59:08+00:00 - - - Andrew Poelstra 2017-05-10 07:55:42+00:00 - - - Russell O'Connor 2017-05-10 01:59:06+00:00 - - - adiabat 2017-05-07 06:45:00+00:00 - + 2025-09-26T15:58:00.535355+00:00 + python-feedgen + + + [bitcoin-dev] Per-block non-interactive Schnorr signature aggregation adiabat + 2017-05-07T06:45:00.000Z + + + Russell O'Connor + 2017-05-10T01:59:00.000Z + + + Andrew Poelstra + 2017-05-10T07:55:00.000Z + + + adiabat + 2017-05-10T14:59:00.000Z + + - python-feedgen + 2 Combined summary - Per-block non-interactive Schnorr signature aggregation - 2023-08-01T20:33:41.353836+00:00 + 2025-09-26T15:58:00.536019+00:00 - A potential vulnerability in Bitcoin's signature aggregation feature is discussed in this conversation. The Wagner generalized birthday attack could be used to manipulate the system by varying the R values and colliding hashes. To defend against this attack, a possible solution is proposed where the miner calculates s-aggregate and aggregates all the public keys from the aggregated signatures in the block. They then sort and hash the concatenated list of pubkeys, multiplying s by this combo-pubkey hash. Verification would involve creating the same combo-pubkey hash, multiplying s by the multiplicative inverse of the calculated h(c), and verifying s. However, the impact on verification speed is uncertain.Another optimization proposed involves concatenating all the R's or P's in the order they appear in the block. Then, the miner commits to s*h(c)^1, the multiplicative inverse of the hash of all those values. During verification, nodes can simply multiply by h(c) instead of calculating the inverse. Russell O'Connor argues that a proposal under consideration is flawed, demonstrating a scenario where Bob tries to steal Alice's UTXO using random values to create an invalid individual signature that becomes valid when combined with other inputs.Andrew Poelstra suggests using non-interactive Schnorr aggregation as a solution. This involves independent Schnorr sigs without aggregation until a miner produces a block. The miner multiplies each s_i by H(witness root || index), sums up the s_i's, and commits the sum somewhere that doesn't affect the root. Verifiers can recognize the signature given only the transaction it signs and R_i, which determine a valid signature.The proposal being discussed involves Schnorr signatures and non-interactive partial aggregation of signatures on a per-block basis. It aims to save space without apparent security issues but requires feedback from experts to ensure its safety. Private keys, public keys, and s values are generated for each signature. Unique R values are used for signing and verification. While interactive aggregate signatures require co-signers to build an aggregate R value, non-interactively half of the signature can be aggregated by summing up the s values. This approach reduces signature size to 32 bytes each, allowing more signatures in a block while taking up less disk and network space. However, caching signatures and quickly validating a block may be challenging, although validation with cached signatures seems possible without elliptic curve operations. Expert feedback is necessary to ensure the proposal's safety.The implementation of Schnorr signatures in a future witness version could potentially enable non-interactive partial aggregation of signatures on a per-block basis, saving space. There appear to be no security issues, but the author seeks feedback from the mailing list to identify any vulnerabilities. The signature process involves generating private keys multiplied by a generator to get public keys, followed by calculating 's' values for each signature. Interactive aggregate signatures involve co-signers sharing R values to build an aggregate R value. Non-interactively, half the signature can be aggregated by summing up the s values. When making transactions, wallets sign in the usual way, and the signature [R, s] goes into the witness stack. Miners remove the s values from compatible inputs when generating a block and commit to the aggregate s value in the coinbase transaction. The advantages include fitting more signatures in a block, occupying less disk and network space, and speeding up block verification. 2017-05-10T14:59:08+00:00 + A potential vulnerability in Bitcoin's signature aggregation feature is discussed in this conversation. The Wagner generalized birthday attack could be used to manipulate the system by varying the R values and colliding hashes. To defend against this attack, a possible solution is proposed where the miner calculates s-aggregate and aggregates all the public keys from the aggregated signatures in the block. They then sort and hash the concatenated list of pubkeys, multiplying s by this combo-pubkey hash. Verification would involve creating the same combo-pubkey hash, multiplying s by the multiplicative inverse of the calculated h(c), and verifying s. However, the impact on verification speed is uncertain.Another optimization proposed involves concatenating all the R's or P's in the order they appear in the block. Then, the miner commits to s*h(c)^1, the multiplicative inverse of the hash of all those values. During verification, nodes can simply multiply by h(c) instead of calculating the inverse. Russell O'Connor argues that a proposal under consideration is flawed, demonstrating a scenario where Bob tries to steal Alice's UTXO using random values to create an invalid individual signature that becomes valid when combined with other inputs.Andrew Poelstra suggests using non-interactive Schnorr aggregation as a solution. This involves independent Schnorr sigs without aggregation until a miner produces a block. The miner multiplies each s_i by H(witness root || index), sums up the s_i's, and commits the sum somewhere that doesn't affect the root. Verifiers can recognize the signature given only the transaction it signs and R_i, which determine a valid signature.The proposal being discussed involves Schnorr signatures and non-interactive partial aggregation of signatures on a per-block basis. It aims to save space without apparent security issues but requires feedback from experts to ensure its safety. Private keys, public keys, and s values are generated for each signature. Unique R values are used for signing and verification. While interactive aggregate signatures require co-signers to build an aggregate R value, non-interactively half of the signature can be aggregated by summing up the s values. This approach reduces signature size to 32 bytes each, allowing more signatures in a block while taking up less disk and network space. However, caching signatures and quickly validating a block may be challenging, although validation with cached signatures seems possible without elliptic curve operations. Expert feedback is necessary to ensure the proposal's safety.The implementation of Schnorr signatures in a future witness version could potentially enable non-interactive partial aggregation of signatures on a per-block basis, saving space. There appear to be no security issues, but the author seeks feedback from the mailing list to identify any vulnerabilities. The signature process involves generating private keys multiplied by a generator to get public keys, followed by calculating 's' values for each signature. Interactive aggregate signatures involve co-signers sharing R values to build an aggregate R value. Non-interactively, half the signature can be aggregated by summing up the s values. When making transactions, wallets sign in the usual way, and the signature [R, s] goes into the witness stack. Miners remove the s values from compatible inputs when generating a block and commit to the aggregate s value in the coinbase transaction. The advantages include fitting more signatures in a block, occupying less disk and network space, and speeding up block verification. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Proposal-to-allow-users-to-configure-the-maximum-block-weight-based-on-a-support-threshold.xml b/static/bitcoin-dev/May_2017/combined_Proposal-to-allow-users-to-configure-the-maximum-block-weight-based-on-a-support-threshold.xml index e35a73eb1e..6f6c99eba3 100644 --- a/static/bitcoin-dev/May_2017/combined_Proposal-to-allow-users-to-configure-the-maximum-block-weight-based-on-a-support-threshold.xml +++ b/static/bitcoin-dev/May_2017/combined_Proposal-to-allow-users-to-configure-the-maximum-block-weight-based-on-a-support-threshold.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Proposal to allow users to configure the maximum block weight based on a support threshold - 2023-08-01T20:43:34.794054+00:00 - - Tomas 2017-05-24 08:34:10+00:00 - - - Erik Aronesty 2017-05-24 02:42:30+00:00 - - - Tomas 2017-05-23 10:50:37+00:00 - + 2025-09-26T15:58:30.444315+00:00 + python-feedgen + + + [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold Tomas + 2017-05-23T10:50:00.000Z + + + Erik Aronesty + 2017-05-24T02:42:00.000Z + + + Tomas + 2017-05-24T08:34:00.000Z + + - python-feedgen + 2 Combined summary - Proposal to allow users to configure the maximum block weight based on a support threshold - 2023-08-01T20:43:34.794054+00:00 + 2025-09-26T15:58:30.444956+00:00 - On May 23, 2017, Tomas van der Wansem proposed a mechanism on bitcoin-dev that would allow users to configure their own maximum block weight at a support threshold. The purpose of this proposal is to provide users with the freedom to choose their parameters while still maintaining coordination of any changes. It should be noted that this proposal does not give more power to miners nor reduce decentralization.Erik Aronesty further suggests using UTXO bits instead of block thresholds to coordinate size changes. This provides an optional way to synchronize changes without the need for off-chain agreements. It is seen as a simple improvement over the current situation.The proposal emphasizes that miners cannot change the block size or any other rule without the support of the users. This is because their blocks and coins would be rejected if they go against the consensus. Without the proposed mechanism, someone could manipulate a miner into believing that 99% of nodes are ready for a larger weight, even if that is not true.The user agent signaling, according to Erik, is not very important. It is widely recognized that counting them cannot be relied upon. Therefore, the proposal focuses on allowing users to configure their own maximum block weight, giving them the authority to set their parameters while still ensuring coordination.The complete proposal can be found on Github under the BIP-changing-the-maximum-block weight-based-on-a-support-threshold.mediawiki. It is designed to prevent off-chain debates and maintain coordination among users. Miners still rely on their blocks being accepted by economic nodes to sell their minted coins, and this proposal does not alter that relationship. 2017-05-24T08:34:10+00:00 + On May 23, 2017, Tomas van der Wansem proposed a mechanism on bitcoin-dev that would allow users to configure their own maximum block weight at a support threshold. The purpose of this proposal is to provide users with the freedom to choose their parameters while still maintaining coordination of any changes. It should be noted that this proposal does not give more power to miners nor reduce decentralization.Erik Aronesty further suggests using UTXO bits instead of block thresholds to coordinate size changes. This provides an optional way to synchronize changes without the need for off-chain agreements. It is seen as a simple improvement over the current situation.The proposal emphasizes that miners cannot change the block size or any other rule without the support of the users. This is because their blocks and coins would be rejected if they go against the consensus. Without the proposed mechanism, someone could manipulate a miner into believing that 99% of nodes are ready for a larger weight, even if that is not true.The user agent signaling, according to Erik, is not very important. It is widely recognized that counting them cannot be relied upon. Therefore, the proposal focuses on allowing users to configure their own maximum block weight, giving them the authority to set their parameters while still ensuring coordination.The complete proposal can be found on Github under the BIP-changing-the-maximum-block weight-based-on-a-support-threshold.mediawiki. It is designed to prevent off-chain debates and maintain coordination among users. Miners still rely on their blocks being accepted by economic nodes to sell their minted coins, and this proposal does not alter that relationship. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Reduced-signalling-threshold-activation-of-existing-segwit-deployment.xml b/static/bitcoin-dev/May_2017/combined_Reduced-signalling-threshold-activation-of-existing-segwit-deployment.xml index 5b6bb9f18b..eb842a0075 100644 --- a/static/bitcoin-dev/May_2017/combined_Reduced-signalling-threshold-activation-of-existing-segwit-deployment.xml +++ b/static/bitcoin-dev/May_2017/combined_Reduced-signalling-threshold-activation-of-existing-segwit-deployment.xml @@ -1,38 +1,55 @@ - + 2 Combined summary - Reduced signalling threshold activation of existing segwit deployment - 2023-08-01T20:43:21.006352+00:00 - - Erik Aronesty 2017-05-24 16:44:55+00:00 - - - James Hilliard 2017-05-24 16:36:03+00:00 - - - Wang Chun 2017-05-24 16:02:09+00:00 - - - Andrew Chow 2017-05-23 20:58:14+00:00 - - - James Hilliard 2017-05-23 20:42:46+00:00 - - - Andrew Chow 2017-05-23 20:39:19+00:00 - - - James Hilliard 2017-05-23 16:56:51+00:00 - - - Kekcoin 2017-05-23 09:51:19+00:00 - - - Erik Aronesty 2017-05-23 04:00:53+00:00 - - - James Hilliard 2017-05-22 22:40:13+00:00 - + 2025-09-26T15:57:52.032345+00:00 + python-feedgen + + + [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment James Hilliard + 2017-05-22T22:40:00.000Z + + + Matt Corallo + 2017-05-22T22:43:00.000Z + + + Erik Aronesty + 2017-05-23T04:00:00.000Z + + + Kekcoin + 2017-05-23T09:51:00.000Z + + + James Hilliard + 2017-05-23T16:56:00.000Z + + + Andrew Chow + 2017-05-23T20:39:00.000Z + + + James Hilliard + 2017-05-23T20:42:00.000Z + + + Andrew Chow + 2017-05-23T20:58:00.000Z + + + Wang Chun + 2017-05-24T16:02:00.000Z + + + James Hilliard + 2017-05-24T16:36:00.000Z + + + Erik Aronesty + 2017-05-24T16:44:00.000Z + + @@ -43,13 +60,13 @@ - python-feedgen + 2 Combined summary - Reduced signalling threshold activation of existing segwit deployment - 2023-08-01T20:43:21.006352+00:00 + 2025-09-26T15:57:52.033761+00:00 - A proposal by James Hilliard has been put forward to activate Segregated Witness (SegWit) at an 80% threshold using bit 4. The main objective of this proposal is to minimize the risk of chain split and network disruption while ensuring backward compatibility and rapid activation of SegWit. The implementation is fully compatible with the User Activated Soft Fork (UASF) movement, effectively turning supporting miners into BIP148 enforcers.The proposal addresses concerns about compatibility with the current SegWit implementation by triggering a mandatory signaling period that will activate SegWit on existing nodes. It also specifies a method to activate the existing BIP9 SegWit deployment with a majority hash power less than 95%. The proposal highlights the benefits of SegWit, such as increasing the block size, fixing transaction malleability, and making scripting easier to upgrade.Feedback from participants has included suggestions to lower the signaling threshold to 75% and concerns about the compatibility with the current SegWit implementation. The discussion surrounding the proposal provides insights into the technical aspects of activating SegWit and the different perspectives on the process.Overall, the proposal aims to activate Segregated Witness at an 80% threshold using bit 4 to minimize chain split risk and network disruption. It is compatible with the current SegWit implementation and offers several benefits, such as increasing the block size and fixing transaction malleability. The proposal has sparked a discussion among participants, highlighting various viewpoints and considerations for the activation process. 2017-05-24T16:44:55+00:00 + A proposal by James Hilliard has been put forward to activate Segregated Witness (SegWit) at an 80% threshold using bit 4. The main objective of this proposal is to minimize the risk of chain split and network disruption while ensuring backward compatibility and rapid activation of SegWit. The implementation is fully compatible with the User Activated Soft Fork (UASF) movement, effectively turning supporting miners into BIP148 enforcers.The proposal addresses concerns about compatibility with the current SegWit implementation by triggering a mandatory signaling period that will activate SegWit on existing nodes. It also specifies a method to activate the existing BIP9 SegWit deployment with a majority hash power less than 95%. The proposal highlights the benefits of SegWit, such as increasing the block size, fixing transaction malleability, and making scripting easier to upgrade.Feedback from participants has included suggestions to lower the signaling threshold to 75% and concerns about the compatibility with the current SegWit implementation. The discussion surrounding the proposal provides insights into the technical aspects of activating SegWit and the different perspectives on the process.Overall, the proposal aims to activate Segregated Witness at an 80% threshold using bit 4 to minimize chain split risk and network disruption. It is compatible with the current SegWit implementation and offers several benefits, such as increasing the block size and fixing transaction malleability. The proposal has sparked a discussion among participants, highlighting various viewpoints and considerations for the activation process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Rolling-UTXO-set-hashes.xml b/static/bitcoin-dev/May_2017/combined_Rolling-UTXO-set-hashes.xml index a535769d33..32609826e5 100644 --- a/static/bitcoin-dev/May_2017/combined_Rolling-UTXO-set-hashes.xml +++ b/static/bitcoin-dev/May_2017/combined_Rolling-UTXO-set-hashes.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Rolling UTXO set hashes - 2023-08-01T20:37:59.843555+00:00 - - Pieter Wuille 2017-05-23 20:43:45+00:00 - - - Rusty Russell 2017-05-23 04:47:48+00:00 - - - Gregory Maxwell 2017-05-16 18:20:00+00:00 - - - Pieter Wuille 2017-05-16 18:17:19+00:00 - - - Peter Todd 2017-05-16 11:01:04+00:00 - - - ZmnSCPxj 2017-05-16 00:15:58+00:00 - - - Gregory Maxwell 2017-05-15 23:59:58+00:00 - - - ZmnSCPxj 2017-05-15 23:04:01+00:00 - - - Peter R 2017-05-15 20:53:45+00:00 - - - Pieter Wuille 2017-05-15 20:01:14+00:00 - + 2025-09-26T15:57:47.767819+00:00 + python-feedgen + + + [bitcoin-dev] Rolling UTXO set hashes Pieter Wuille + 2017-05-15T20:01:00.000Z + + + Peter R + 2017-05-15T20:53:00.000Z + + + ZmnSCPxj + 2017-05-15T23:04:00.000Z + + + Gregory Maxwell + 2017-05-15T23:59:00.000Z + + + ZmnSCPxj + 2017-05-16T00:15:00.000Z + + + Peter Todd + 2017-05-16T11:01:00.000Z + + + Pieter Wuille + 2017-05-16T18:17:00.000Z + + + Gregory Maxwell + 2017-05-16T18:20:00.000Z + + + Rusty Russell + 2017-05-23T04:47:00.000Z + + + Pieter Wuille + 2017-05-23T20:43:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Rolling UTXO set hashes - 2023-08-01T20:37:59.843555+00:00 + 2025-09-26T15:57:47.768680+00:00 - A discussion on the bitcoin-dev mailing list focused on the efficient construction of UTXO commitments. The group considered the ability of lightweight nodes to validate the hash without accessing the entire UTXO set. One proposed method involved using SHA512 with a truncated output as a key to seed a ChaCha20 PRNG. Another approach suggested a simple txid||outnumber hash that could be validated by lightweight nodes.The debate also touched on the serialization of transaction outputs (txout). One approach was minimal and had no normative data structures, while another reused existing primitives. Gregory Maxwell preferred the second approach as it allowed for simple validation without knowledge of the UTXO set. However, he mentioned that in a SegWit world, including additional information in the serialization would result in a larger UTXO set required for validation.Peter Todd argued that previous UTXO commitment schemes did not require miners to participate in generating a commitment. However, network-wide choices were still necessary for these approaches to be useful. In a partial deployment, producing proofs of unspentness became more expensive than running an old or new full node. Todd suggested investigating solutions to efficiently compare UTXO sets separately from reducing full node costs.The advantages of committing to UTXO data were discussed, particularly for lite nodes. Lite nodes could download UTXO sets from full nodes and verify them by validating block headers starting from the genesis block. Compact membership proofs were deemed necessary for most arguments. Additionally, there was growing interest in full block lite clients for privacy reasons, which complemented membership proofless usage.Pieter Wuille proposed gaining experience with operating without committing to UTXO data before implementing it. He emphasized the need for careful consideration due to the consensus change involved. Wuille also highlighted the importance of adding the merkle tree root of transactions to the commitment for audibility and engineering reasons. Otherwise, DOS attacks could occur. There was also a suggestion to commit to the UTXO of the previous block and the merkle tree root of transactions in the current block to reduce SPV mining.The email mentioned various use cases for a rolling set hash. It could replace Bitcoin Core's gettxoutsetinfo RPC's hash computation, making the process instant and more usable. The rolling set hash could also assist in fast sync methods with known good blocks/UTXO sets and database consistency checking. Another proposal involved a "chain-flip" hard fork where the UTXO hash would be in the block header instead of the merkle tree root of transactions.Pieter Wuille initiated a discussion on efficient UTXO set hash computation. Two approaches, MuHash and ECMH, were presented for efficient addition and deletion of set elements. Preliminary benchmarks showed that both approaches were fast enough for full nodes to maintain a rolling cryptographic checksum of the UTXO set at all times. The rolling set hash could replace the current gettxoutsetinfo RPC's hash computation and assist in fast sync methods and database consistency checking.Overall, the discussion focused on finding efficient ways to construct UTXO commitments, improve transaction outputs serialization, and explore the advantages and implementation considerations of committing to UTXO data. Various proposals and approaches were discussed, along with their potential use cases and implications. 2017-05-23T20:43:45+00:00 + A discussion on the bitcoin-dev mailing list focused on the efficient construction of UTXO commitments. The group considered the ability of lightweight nodes to validate the hash without accessing the entire UTXO set. One proposed method involved using SHA512 with a truncated output as a key to seed a ChaCha20 PRNG. Another approach suggested a simple txid||outnumber hash that could be validated by lightweight nodes.The debate also touched on the serialization of transaction outputs (txout). One approach was minimal and had no normative data structures, while another reused existing primitives. Gregory Maxwell preferred the second approach as it allowed for simple validation without knowledge of the UTXO set. However, he mentioned that in a SegWit world, including additional information in the serialization would result in a larger UTXO set required for validation.Peter Todd argued that previous UTXO commitment schemes did not require miners to participate in generating a commitment. However, network-wide choices were still necessary for these approaches to be useful. In a partial deployment, producing proofs of unspentness became more expensive than running an old or new full node. Todd suggested investigating solutions to efficiently compare UTXO sets separately from reducing full node costs.The advantages of committing to UTXO data were discussed, particularly for lite nodes. Lite nodes could download UTXO sets from full nodes and verify them by validating block headers starting from the genesis block. Compact membership proofs were deemed necessary for most arguments. Additionally, there was growing interest in full block lite clients for privacy reasons, which complemented membership proofless usage.Pieter Wuille proposed gaining experience with operating without committing to UTXO data before implementing it. He emphasized the need for careful consideration due to the consensus change involved. Wuille also highlighted the importance of adding the merkle tree root of transactions to the commitment for audibility and engineering reasons. Otherwise, DOS attacks could occur. There was also a suggestion to commit to the UTXO of the previous block and the merkle tree root of transactions in the current block to reduce SPV mining.The email mentioned various use cases for a rolling set hash. It could replace Bitcoin Core's gettxoutsetinfo RPC's hash computation, making the process instant and more usable. The rolling set hash could also assist in fast sync methods with known good blocks/UTXO sets and database consistency checking. Another proposal involved a "chain-flip" hard fork where the UTXO hash would be in the block header instead of the merkle tree root of transactions.Pieter Wuille initiated a discussion on efficient UTXO set hash computation. Two approaches, MuHash and ECMH, were presented for efficient addition and deletion of set elements. Preliminary benchmarks showed that both approaches were fast enough for full nodes to maintain a rolling cryptographic checksum of the UTXO set at all times. The rolling set hash could replace the current gettxoutsetinfo RPC's hash computation and assist in fast sync methods and database consistency checking.Overall, the discussion focused on finding efficient ways to construct UTXO commitments, improve transaction outputs serialization, and explore the advantages and implementation considerations of committing to UTXO data. Various proposals and approaches were discussed, along with their potential use cases and implications. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Small-Nodes-A-Better-Alternative-to-Pruned-Nodes.xml b/static/bitcoin-dev/May_2017/combined_Small-Nodes-A-Better-Alternative-to-Pruned-Nodes.xml index 9fcd32e958..52f7ba95cd 100644 --- a/static/bitcoin-dev/May_2017/combined_Small-Nodes-A-Better-Alternative-to-Pruned-Nodes.xml +++ b/static/bitcoin-dev/May_2017/combined_Small-Nodes-A-Better-Alternative-to-Pruned-Nodes.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Small Nodes: A Better Alternative to Pruned Nodes - 2023-08-01T20:28:26.315407+00:00 - - Aymeric Vitte 2017-05-03 22:45:40+00:00 - - - Natanael 2017-05-03 19:10:47+00:00 - - - Erik Aronesty 2017-05-03 14:03:58+00:00 - - - Aymeric Vitte 2017-04-23 16:27:15+00:00 - - - Gregory Maxwell 2017-04-21 20:38:36+00:00 - - - Leandro Coutinho 2017-04-21 15:58:43+00:00 - - - David Kaufman 2017-04-21 13:35:51+00:00 - - - Tom Zander 2017-04-21 08:27:36+00:00 - - - Aymeric Vitte 2017-04-20 23:42:03+00:00 - - - Andrew Poelstra 2017-04-20 20:32:12+00:00 - - - Erik Aronesty 2017-04-20 15:50:24+00:00 - - - Aymeric Vitte 2017-04-20 11:27:32+00:00 - - - Tom Zander 2017-04-20 09:46:33+00:00 - - - David Vorick 2017-04-19 17:30:30+00:00 - - - Angel Leon 2017-04-19 13:47:40+00:00 - - - udevNull 2017-04-19 04:28:48+00:00 - - - Aymeric Vitte 2017-04-18 23:19:04+00:00 - - - Tier Nolan 2017-04-18 13:07:09+00:00 - - - Tom Zander 2017-04-18 10:50:31+00:00 - - - Jonas Schnelli 2017-04-18 07:43:52+00:00 - - - Aymeric Vitte 2017-04-17 10:14:25+00:00 - - - David Vorick 2017-04-17 07:27:35+00:00 - - - Danny Thorpe 2017-04-17 07:11:07+00:00 - - - David Vorick 2017-04-17 06:54:49+00:00 - + 2025-09-26T15:58:04.843831+00:00 + python-feedgen + + + [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes David Vorick + 2017-04-17T06:54:00.000Z + + + Danny Thorpe + 2017-04-17T07:11:00.000Z + + + David Vorick + 2017-04-17T07:27:00.000Z + + + Aymeric Vitte + 2017-04-17T10:14:00.000Z + + + Jonas Schnelli + 2017-04-18T07:43:00.000Z + + + Tom Zander + 2017-04-18T10:50:00.000Z + + + Tier Nolan + 2017-04-18T13:07:00.000Z + + + Aymeric Vitte + 2017-04-18T23:19:00.000Z + + + udevNull + 2017-04-19T04:28:00.000Z + + + Angel Leon + 2017-04-19T13:47:00.000Z + + + David Vorick + 2017-04-19T17:30:00.000Z + + + Tom Zander + 2017-04-20T09:46:00.000Z + + + Aymeric Vitte + 2017-04-20T11:27:00.000Z + + + Erik Aronesty + 2017-04-20T15:50:00.000Z + + + Andrew Poelstra + 2017-04-20T20:32:00.000Z + + + Aymeric Vitte + 2017-04-20T23:42:00.000Z + + + Tom Zander + 2017-04-21T08:27:00.000Z + + + David Kaufman + 2017-04-21T13:35:00.000Z + + + Leandro Coutinho + 2017-04-21T15:58:00.000Z + + + Gregory Maxwell + 2017-04-21T20:38:00.000Z + + + Aymeric Vitte + 2017-04-23T16:27:00.000Z + + + Erik Aronesty + 2017-05-03T14:03:00.000Z + + + Natanael + 2017-05-03T19:10:00.000Z + + + Aymeric Vitte + 2017-05-03T22:45:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Small Nodes: A Better Alternative to Pruned Nodes - 2023-08-01T20:28:26.316422+00:00 + 2025-09-26T15:58:04.846350+00:00 - The discussions on the bitcoin-dev mailing list revolve around finding solutions to reduce failure probabilities, increase the number of full nodes, and decrease the storage requirement for running a full Bitcoin node. Various proposals are suggested, including storing random percentages of less commonly available blocks, using Forward Error Correction (FEC) codes like Reed-Solomon codes, allowing pruning of old transactions, and implementing small nodes with Reed-Solomon coding. These proposals aim to improve network health, scalability, and accessibility while addressing security and reliability concerns.One proposal suggests adding a third mode for nodes, allowing them to signal that they keep the last 1000 blocks. This would be beneficial for pruned nodes, as they could partially serve historical blocks instead of serving all or none. Another proposal suggests a "random pruning mode" for nodes, which stores a random set of blocks and drops random blocks as disk space runs out. However, this proposal has disadvantages due to the potential inability to download certain blocks, particularly with active adversaries.The aim is to decrease the resource requirements for running a full node, which is crucial for decentralization, security, and protection against political interference. A suggestion is to compactly indicate which blocks a node has, allowing each node to store a subset of blocks. However, missing even a single block could pose a significant problem. Financially incentivizing nodes is a complex issue, as it may lead to malicious actors automating deployment. However, offering rewards for long-term commitment could be a potential solution.There are concerns about the default setting of pruned nodes in bitcoin-core, with claims that it could become problematic. The priority should be to increase the number of full nodes with incentives for people to run them. In a previous discussion, there was a suggestion to compactly indicate which blocks a node has, and it was recommended that each node store the last few days' worth of blocks.David Vorick proposes a solution called "small nodes" to increase the number of users running full nodes. Small nodes would only need to store about 20% of the blockchain using Reed-Solomon coding. Each small node has a permanent index and stores a piece that corresponds to its index. The full block can be recovered by connecting to six random small node peers. Vorick believes this solution would greatly benefit decentralization without putting pressure on archival nodes.Disk space consumption is identified as a significant factor preventing more people from running full nodes. Pruned nodes are currently the best alternative, but this puts pressure on archival nodes. The proposed solution is a new node type called a "small node" that stores only 20% of the blockchain. Small nodes use erasure coding to store fragments of blocks and can recover the entire blockchain by connecting to six random small node peers. There are challenges in preventing denial-of-service attacks and ensuring the correctness of the stored pieces. Implementing small nodes would require a non-trivial amount of code but could significantly increase the percentage of users running full nodes and create a healthier network. 2017-05-03T22:45:40+00:00 + The discussions on the bitcoin-dev mailing list revolve around finding solutions to reduce failure probabilities, increase the number of full nodes, and decrease the storage requirement for running a full Bitcoin node. Various proposals are suggested, including storing random percentages of less commonly available blocks, using Forward Error Correction (FEC) codes like Reed-Solomon codes, allowing pruning of old transactions, and implementing small nodes with Reed-Solomon coding. These proposals aim to improve network health, scalability, and accessibility while addressing security and reliability concerns.One proposal suggests adding a third mode for nodes, allowing them to signal that they keep the last 1000 blocks. This would be beneficial for pruned nodes, as they could partially serve historical blocks instead of serving all or none. Another proposal suggests a "random pruning mode" for nodes, which stores a random set of blocks and drops random blocks as disk space runs out. However, this proposal has disadvantages due to the potential inability to download certain blocks, particularly with active adversaries.The aim is to decrease the resource requirements for running a full node, which is crucial for decentralization, security, and protection against political interference. A suggestion is to compactly indicate which blocks a node has, allowing each node to store a subset of blocks. However, missing even a single block could pose a significant problem. Financially incentivizing nodes is a complex issue, as it may lead to malicious actors automating deployment. However, offering rewards for long-term commitment could be a potential solution.There are concerns about the default setting of pruned nodes in bitcoin-core, with claims that it could become problematic. The priority should be to increase the number of full nodes with incentives for people to run them. In a previous discussion, there was a suggestion to compactly indicate which blocks a node has, and it was recommended that each node store the last few days' worth of blocks.David Vorick proposes a solution called "small nodes" to increase the number of users running full nodes. Small nodes would only need to store about 20% of the blockchain using Reed-Solomon coding. Each small node has a permanent index and stores a piece that corresponds to its index. The full block can be recovered by connecting to six random small node peers. Vorick believes this solution would greatly benefit decentralization without putting pressure on archival nodes.Disk space consumption is identified as a significant factor preventing more people from running full nodes. Pruned nodes are currently the best alternative, but this puts pressure on archival nodes. The proposed solution is a new node type called a "small node" that stores only 20% of the blockchain. Small nodes use erasure coding to store fragments of blocks and can recover the entire blockchain by connecting to six random small node peers. There are challenges in preventing denial-of-service attacks and ensuring the correctness of the stored pieces. Implementing small nodes would require a non-trivial amount of code but could significantly increase the percentage of users running full nodes and create a healthier network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Some-real-world-results-about-the-current-Segwit-Discount.xml b/static/bitcoin-dev/May_2017/combined_Some-real-world-results-about-the-current-Segwit-Discount.xml index 455f61a486..ad2e097b31 100644 --- a/static/bitcoin-dev/May_2017/combined_Some-real-world-results-about-the-current-Segwit-Discount.xml +++ b/static/bitcoin-dev/May_2017/combined_Some-real-world-results-about-the-current-Segwit-Discount.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Some real-world results about the current Segwit Discount - 2023-08-01T20:35:23.093356+00:00 - - Sergio Demian Lerner 2017-05-10 19:40:12+00:00 - - - Matt Corallo 2017-05-10 16:39:00+00:00 - - - Sergio Demian Lerner 2017-05-10 15:25:27+00:00 - - - Matt Corallo 2017-05-10 14:05:30+00:00 - - - Jorge Timón 2017-05-10 05:37:33+00:00 - - - Sergio Demian Lerner 2017-05-09 20:58:35+00:00 - - - Gregory Maxwell 2017-05-09 20:13:14+00:00 - - - Matt Corallo 2017-05-09 19:42:56+00:00 - - - Gregory Maxwell 2017-05-09 19:30:52+00:00 - - - Sergio Demian Lerner 2017-05-09 19:15:32+00:00 - - - Sergio Demian Lerner 2017-05-09 18:58:25+00:00 - - - Matt Corallo 2017-05-09 18:15:45+00:00 - - - James Hilliard 2017-05-09 16:27:59+00:00 - - - Johnson Lau 2017-05-09 16:27:40+00:00 - - - Sergio Demian Lerner 2017-05-09 16:19:13+00:00 - - - Johnson Lau 2017-05-09 15:45:04+00:00 - - - James Hilliard 2017-05-09 14:33:34+00:00 - - - Sergio Demian Lerner 2017-05-09 13:49:05+00:00 - - - Gregory Maxwell 2017-05-08 23:56:49+00:00 - - - Alphonse Pace 2017-05-08 23:47:32+00:00 - - - Sergio Demian Lerner 2017-05-08 22:42:23+00:00 - + 2025-09-26T15:57:43.522510+00:00 + python-feedgen + + + [bitcoin-dev] Some real-world results about the current Segwit Discount Sergio Demian Lerner + 2017-05-08T22:42:00.000Z + + + Alphonse Pace + 2017-05-08T23:47:00.000Z + + + Gregory Maxwell + 2017-05-08T23:56:00.000Z + + + Sergio Demian Lerner + 2017-05-09T13:49:00.000Z + + + James Hilliard + 2017-05-09T14:33:00.000Z + + + Johnson Lau + 2017-05-09T15:45:00.000Z + + + Sergio Demian Lerner + 2017-05-09T16:19:00.000Z + + + Johnson Lau + 2017-05-09T16:27:00.000Z + + + James Hilliard + 2017-05-09T16:27:00.000Z + + + Matt Corallo + 2017-05-09T18:15:00.000Z + + + Sergio Demian Lerner + 2017-05-09T18:58:00.000Z + + + Sergio Demian Lerner + 2017-05-09T19:15:00.000Z + + + Gregory Maxwell + 2017-05-09T19:30:00.000Z + + + Matt Corallo + 2017-05-09T19:42:00.000Z + + + Gregory Maxwell + 2017-05-09T20:13:00.000Z + + + Sergio Demian Lerner + 2017-05-09T20:58:00.000Z + + + Jorge Timón + 2017-05-10T05:37:00.000Z + + + Matt Corallo + 2017-05-10T14:05:00.000Z + + + Sergio Demian Lerner + 2017-05-10T15:25:00.000Z + + + Matt Corallo + 2017-05-10T16:39:00.000Z + + + Sergio Demian Lerner + 2017-05-10T19:40:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Some real-world results about the current Segwit Discount - 2023-08-01T20:35:23.094357+00:00 + 2025-09-26T15:57:43.524762+00:00 - In an email thread, Matt Corallo and Sergio Demian Lerner discuss the implementation of Segregated Witness (Segwit) in Bitcoin. Lerner proposes changing the parameters of Segwit to increase the chance of a consensual hard fork being accepted with minimal code changes. Corallo disagrees and emphasizes the importance of Segwit as a key feature for Bitcoin's long-term reliability. Despite their disagreement, Lerner clarifies that he is not advocating, but rather mediating the discussion. The email also includes some lighthearted banter between the participants.The conversation revolves around the best approach for solving the SegWit block size discount issue. Lerner suggests throwing out the SegWit goals, while others propose increasing the discount ratio. Corallo argues that reducing the cost of input prevout itself would be a better solution, as it achieves the SegWit goal and lowers the ratio between worst-case and average-case block size. Gregory Maxwell joins the conversation with a playful remark.The discussion also touches on the potential capacity of Segwit combined with a 2MB hard fork. Lerner calculates that this combination can provide 50% more capacity than Segwit alone. However, there are concerns about the increased Unspent Transaction Output (UTXO) bloat with this combination. Gregory Maxwell notes that optimizing raw size may not be relevant in the long run, but if it were, the limit should be pure size.There is another debate about the maximum block weight for Bitcoin transactions. Suggestions are made, but it is pointed out that the numbers do not work out as expected. The conversation reveals that the initial suggestion was in the context of a soft fork, not a hard fork.Another thread discusses the discount system for SegWit transactions. Lerner suggests a 50% witness discount would be better for preventing witness spam and future scalability options. However, Alphonse Pace disagrees and claims that the current 75% discount is sufficient. The conversation also touches on the potential impact of these changes on the maximum number of transactions per second.In a separate discussion, there is a suggestion to implement a soft fork to a 50% discount before a soft fork to a 75% discount. Lerner argues that going from a more restrictive ruleset to a less restrictive one is more difficult and may not be fully backwards compatible. Johnson Lau notes that any parameter can be changed in a hard fork, so this discussion does not necessarily relate to the current BIP141 proposal.The conversation continues with Lerner proposing a soft fork to a 50% discount now and another soft fork to a 75% discount later, if needed. Johnson Lau points out that any parameter can be changed in a hard fork, so it is not related to the current BIP141 proposal. Lerner suggests a more conservative 50% discount to avoid making the worst-case block size unnecessarily large in case of a future hard fork.The discussion on the Segwit discount concludes with Lerner suggesting a soft fork to 50% now and another soft fork to 75% later, if required. Johnson Lau notes that any parameter can be changed in a hard fork and suggests using 75% in a soft fork and changing it to a different value or redefining the definition of weight with a hard fork later.Overall, the email thread and discussions highlight the ongoing debates and considerations regarding the implementation and parameters of Segregated Witness in Bitcoin. The participants express differing opinions on the best approach, with some emphasizing the importance of Segwit's features for long-term reliability and others discussing potential scalability options and bloat concerns.Full nodes face a challenge with the size of the Unspent Transaction Output (UTXO) set, making it a bigger issue than the size of the blockchain itself. The current 75% discount on witness space does not effectively prevent witness spam, but instead leaves room for it. Sergio Demian Lerner suggests that a 50% witness discount would be more appropriate to address this issue.Lerner conducted an analysis of 1000 blocks starting from Block #461653 and computed various metrics, including the size of witness and non-witness data. He found that the 75% discount worsens worst-case block sizes, increasing them to 4MB instead of the desired 2.7MB. By using a 50% witness discount, scaling could be less risky as it would keep the worst-case block size at 5.4MB instead of 8MB.Witness spam refers to the free space in the witness part of a block that miners can fill to create larger blocks with low latency, potentially leading to centralization. The current 75% discount does not effectively prevent witness spam and only achieves more transactions per second if the type of transactions change. Currently, 80% of all inputs/outputs are P2PKH, and utilizing the extra witness space would require a shift towards multisig transactions.Lerner's analysis indicates that the 2017-05-10T19:40:12+00:00 + In an email thread, Matt Corallo and Sergio Demian Lerner discuss the implementation of Segregated Witness (Segwit) in Bitcoin. Lerner proposes changing the parameters of Segwit to increase the chance of a consensual hard fork being accepted with minimal code changes. Corallo disagrees and emphasizes the importance of Segwit as a key feature for Bitcoin's long-term reliability. Despite their disagreement, Lerner clarifies that he is not advocating, but rather mediating the discussion. The email also includes some lighthearted banter between the participants.The conversation revolves around the best approach for solving the SegWit block size discount issue. Lerner suggests throwing out the SegWit goals, while others propose increasing the discount ratio. Corallo argues that reducing the cost of input prevout itself would be a better solution, as it achieves the SegWit goal and lowers the ratio between worst-case and average-case block size. Gregory Maxwell joins the conversation with a playful remark.The discussion also touches on the potential capacity of Segwit combined with a 2MB hard fork. Lerner calculates that this combination can provide 50% more capacity than Segwit alone. However, there are concerns about the increased Unspent Transaction Output (UTXO) bloat with this combination. Gregory Maxwell notes that optimizing raw size may not be relevant in the long run, but if it were, the limit should be pure size.There is another debate about the maximum block weight for Bitcoin transactions. Suggestions are made, but it is pointed out that the numbers do not work out as expected. The conversation reveals that the initial suggestion was in the context of a soft fork, not a hard fork.Another thread discusses the discount system for SegWit transactions. Lerner suggests a 50% witness discount would be better for preventing witness spam and future scalability options. However, Alphonse Pace disagrees and claims that the current 75% discount is sufficient. The conversation also touches on the potential impact of these changes on the maximum number of transactions per second.In a separate discussion, there is a suggestion to implement a soft fork to a 50% discount before a soft fork to a 75% discount. Lerner argues that going from a more restrictive ruleset to a less restrictive one is more difficult and may not be fully backwards compatible. Johnson Lau notes that any parameter can be changed in a hard fork, so this discussion does not necessarily relate to the current BIP141 proposal.The conversation continues with Lerner proposing a soft fork to a 50% discount now and another soft fork to a 75% discount later, if needed. Johnson Lau points out that any parameter can be changed in a hard fork, so it is not related to the current BIP141 proposal. Lerner suggests a more conservative 50% discount to avoid making the worst-case block size unnecessarily large in case of a future hard fork.The discussion on the Segwit discount concludes with Lerner suggesting a soft fork to 50% now and another soft fork to 75% later, if required. Johnson Lau notes that any parameter can be changed in a hard fork and suggests using 75% in a soft fork and changing it to a different value or redefining the definition of weight with a hard fork later.Overall, the email thread and discussions highlight the ongoing debates and considerations regarding the implementation and parameters of Segregated Witness in Bitcoin. The participants express differing opinions on the best approach, with some emphasizing the importance of Segwit's features for long-term reliability and others discussing potential scalability options and bloat concerns.Full nodes face a challenge with the size of the Unspent Transaction Output (UTXO) set, making it a bigger issue than the size of the blockchain itself. The current 75% discount on witness space does not effectively prevent witness spam, but instead leaves room for it. Sergio Demian Lerner suggests that a 50% witness discount would be more appropriate to address this issue.Lerner conducted an analysis of 1000 blocks starting from Block #461653 and computed various metrics, including the size of witness and non-witness data. He found that the 75% discount worsens worst-case block sizes, increasing them to 4MB instead of the desired 2.7MB. By using a 50% witness discount, scaling could be less risky as it would keep the worst-case block size at 5.4MB instead of 8MB.Witness spam refers to the free space in the witness part of a block that miners can fill to create larger blocks with low latency, potentially leading to centralization. The current 75% discount does not effectively prevent witness spam and only achieves more transactions per second if the type of transactions change. Currently, 80% of all inputs/outputs are P2PKH, and utilizing the extra witness space would require a shift towards multisig transactions.Lerner's analysis indicates that the - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_TXMempool-and-dirty-entries.xml b/static/bitcoin-dev/May_2017/combined_TXMempool-and-dirty-entries.xml index 9ac88925e8..41e17f2f5d 100644 --- a/static/bitcoin-dev/May_2017/combined_TXMempool-and-dirty-entries.xml +++ b/static/bitcoin-dev/May_2017/combined_TXMempool-and-dirty-entries.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - TXMempool and dirty entries - 2023-08-01T20:34:02.449636+00:00 - - Suhas Daftuar 2017-05-08 16:33:42+00:00 - - - DJ Bitcoin 2017-05-08 09:38:16+00:00 - + 2025-09-26T15:58:13.312792+00:00 + python-feedgen + + + [bitcoin-dev] TXMempool and dirty entries DJ Bitcoin + 2017-05-08T09:38:00.000Z + + + Suhas Daftuar + 2017-05-08T16:33:00.000Z + + - python-feedgen + 2 Combined summary - TXMempool and dirty entries - 2023-08-01T20:34:02.449636+00:00 + 2025-09-26T15:58:13.313270+00:00 - The bitcoin-dev mailing list has been moved to bcc as it is more suitable for discussions related to Bitcoin Core implementation specifics. The work limit was removed in preparation for ancestor-feerate-mining, prompting the need for comments to be cleaned up to match the new code. Users are encouraged to file issues or open pull requests on the official GitHub repository to update the comments accordingly.DJ Bitcoin raised a question on the bitcoin-dev mailing list about the use of txmempool and the concept of "dirty" entries. The nCountWithDescendants variable in CTxMemPoolEntry is always nonzero, leading DJ Bitcoin to inquire about where this notion of "dirty" is defined.For more information or to contribute to the discussion, users can visit the GitHub repository at https://github.com/bitcoin/bitcoin. 2017-05-08T16:33:42+00:00 + The bitcoin-dev mailing list has been moved to bcc as it is more suitable for discussions related to Bitcoin Core implementation specifics. The work limit was removed in preparation for ancestor-feerate-mining, prompting the need for comments to be cleaned up to match the new code. Users are encouraged to file issues or open pull requests on the official GitHub repository to update the comments accordingly.DJ Bitcoin raised a question on the bitcoin-dev mailing list about the use of txmempool and the concept of "dirty" entries. The nCountWithDescendants variable in CTxMemPoolEntry is always nonzero, leading DJ Bitcoin to inquire about where this notion of "dirty" is defined.For more information or to contribute to the discussion, users can visit the GitHub repository at https://github.com/bitcoin/bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_TXO-commitments-do-not-need-a-soft-fork-to-be-useful.xml b/static/bitcoin-dev/May_2017/combined_TXO-commitments-do-not-need-a-soft-fork-to-be-useful.xml index 3711146fe2..a9a729e5af 100644 --- a/static/bitcoin-dev/May_2017/combined_TXO-commitments-do-not-need-a-soft-fork-to-be-useful.xml +++ b/static/bitcoin-dev/May_2017/combined_TXO-commitments-do-not-need-a-soft-fork-to-be-useful.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - TXO commitments do not need a soft-fork to be useful - 2023-08-01T19:33:38.969799+00:00 - - Peter Todd 2017-05-16 12:23:53+00:00 - - - Alex Mizrahi 2017-05-16 12:15:17+00:00 - - - praxeology_guy 2017-02-28 16:26:40+00:00 - - - Peter Todd 2017-02-23 07:23:10+00:00 - - - Eric Lombrozo 2017-02-23 03:30:37+00:00 - - - Peter Todd 2017-02-23 01:11:47+00:00 - + 2025-09-26T15:57:58.418301+00:00 + python-feedgen + + + [bitcoin-dev] TXO commitments do not need a soft-fork to be useful Peter Todd + 2017-02-23T01:11:00.000Z + + + Eric Lombrozo + 2017-02-23T03:30:00.000Z + + + Peter Todd + 2017-02-23T07:23:00.000Z + + + praxeology_guy + 2017-02-28T16:26:00.000Z + + + Alex Mizrahi + 2017-05-16T12:15:00.000Z + + + Peter Todd + 2017-05-16T12:23:00.000Z + + - python-feedgen + 2 Combined summary - TXO commitments do not need a soft-fork to be useful - 2023-08-01T19:33:38.969799+00:00 + 2025-09-26T15:57:58.419296+00:00 - In a bitcoin-dev discussion thread, it has been pointed out that TXO commitments can be useful without the need for a consensus protocol change. This realization was shared by Alex Mizrahi, who noted that TXO commitments do not require changes to the consensus protocol to be valuable. It was also mentioned that Peter Todd had previously discussed the idea of a distributed file system in 2013, but his explanation may have been confusing to some due to its reference to a DHT. The importance of clear explanations and analogies was emphasized in the discussion.Another topic of discussion among the bitcoin-dev community is the usefulness of communicating the UTXO (Transaction Output). Praxeology suggested using commitments to incentivize miners to verify the UTXO. Praxeology wrote a detailed write-up called "Synchronization Checkpoints" on Github, outlining the idea. The proposal involves miners putting a commitment at the current Checkpoint Block, which would be a hash of the full state of the UTXO at the previous Checkpoint Block. To ensure high performance, Praxeology suggests maintaining a DB table for sorting the UTXO, waiting for no forks blocks after a CheckPoint Block is made, populating a new UTXO Checkpoint File, and using Merkle tree or bittorrent style hashing for the UTXO Checkpoint File.The discussion also touched on the possibility of implementing a cryptographic data structure to improve delayed TXO commitments using lazy hashing. The proposed data structure would replace commitments with pointers, combining a cryptographic data structure with a standard pointer-based data structure. However, one challenge is how to handle proofs, as the level of verification possible depends on the digests calculated by each node. This approach only works for data structures where the overall structure of the tree does not change as nodes are added and updated.The email thread posted on the Bitcoin-dev mailing list focuses on the implementation of TXO commitments in Bitcoin. Peter Todd proposed that TXO commitments can be implemented without miners committing to the TXO commitment itself. Instead, a TXO commitment allows the data set (TXO set) to be securely provided by an untrusted third party, allowing the data itself to be discarded. If a valid TXO commitment exists, the TXO data can be discarded and untrusted entities can provide that data on demand. Todd argues that this implementation would allow full nodes with limited storage space to keep track of a TXO commitment and prune older UTXOs that are unlikely to be spent. Transactions and blocks spending these UTXOs can trustlessly provide the necessary data to temporarily fill in the node's local TXO set database. Todd suggests a deployment plan for implementing a TXO commitment scheme, including P2P support for advertising pruned parts of the TXO set, and producing, consuming, and updating TXO unspentness proofs during transaction and block relaying.Todd also proposes that a snapshot with an attestation from trusted individuals is a better security model than having miners attest to validity. This security model is similar to the recently implemented -assumevalid scheme, where anyone with a full node can audit the validity of assumed valid TXO commitments. However, Todd acknowledges that this is a weaker security model as a false TXO commitment can more easily trick a node into accepting invalid transactions or blocks. A compromise could be using assumed valid TXO commitments and extending the suggestion of having nodes validate the chain backwards to eventually validate 100% of the chain. Todd provides references to related work on SPV bitcoind and the -assumevalid scheme.In conclusion, the discussions revolve around the potential usefulness of TXO commitments without consensus protocol changes, the implementation of a cryptographic data structure for delayed commitments, and the practicality of implementing a TXO commitment scheme in Bitcoin. 2017-05-16T12:23:53+00:00 + In a bitcoin-dev discussion thread, it has been pointed out that TXO commitments can be useful without the need for a consensus protocol change. This realization was shared by Alex Mizrahi, who noted that TXO commitments do not require changes to the consensus protocol to be valuable. It was also mentioned that Peter Todd had previously discussed the idea of a distributed file system in 2013, but his explanation may have been confusing to some due to its reference to a DHT. The importance of clear explanations and analogies was emphasized in the discussion.Another topic of discussion among the bitcoin-dev community is the usefulness of communicating the UTXO (Transaction Output). Praxeology suggested using commitments to incentivize miners to verify the UTXO. Praxeology wrote a detailed write-up called "Synchronization Checkpoints" on Github, outlining the idea. The proposal involves miners putting a commitment at the current Checkpoint Block, which would be a hash of the full state of the UTXO at the previous Checkpoint Block. To ensure high performance, Praxeology suggests maintaining a DB table for sorting the UTXO, waiting for no forks blocks after a CheckPoint Block is made, populating a new UTXO Checkpoint File, and using Merkle tree or bittorrent style hashing for the UTXO Checkpoint File.The discussion also touched on the possibility of implementing a cryptographic data structure to improve delayed TXO commitments using lazy hashing. The proposed data structure would replace commitments with pointers, combining a cryptographic data structure with a standard pointer-based data structure. However, one challenge is how to handle proofs, as the level of verification possible depends on the digests calculated by each node. This approach only works for data structures where the overall structure of the tree does not change as nodes are added and updated.The email thread posted on the Bitcoin-dev mailing list focuses on the implementation of TXO commitments in Bitcoin. Peter Todd proposed that TXO commitments can be implemented without miners committing to the TXO commitment itself. Instead, a TXO commitment allows the data set (TXO set) to be securely provided by an untrusted third party, allowing the data itself to be discarded. If a valid TXO commitment exists, the TXO data can be discarded and untrusted entities can provide that data on demand. Todd argues that this implementation would allow full nodes with limited storage space to keep track of a TXO commitment and prune older UTXOs that are unlikely to be spent. Transactions and blocks spending these UTXOs can trustlessly provide the necessary data to temporarily fill in the node's local TXO set database. Todd suggests a deployment plan for implementing a TXO commitment scheme, including P2P support for advertising pruned parts of the TXO set, and producing, consuming, and updating TXO unspentness proofs during transaction and block relaying.Todd also proposes that a snapshot with an attestation from trusted individuals is a better security model than having miners attest to validity. This security model is similar to the recently implemented -assumevalid scheme, where anyone with a full node can audit the validity of assumed valid TXO commitments. However, Todd acknowledges that this is a weaker security model as a false TXO commitment can more easily trick a node into accepting invalid transactions or blocks. A compromise could be using assumed valid TXO commitments and extending the suggestion of having nodes validate the chain backwards to eventually validate 100% of the chain. Todd provides references to related work on SPV bitcoind and the -assumevalid scheme.In conclusion, the discussions revolve around the potential usefulness of TXO commitments without consensus protocol changes, the implementation of a cryptographic data structure for delayed commitments, and the practicality of implementing a TXO commitment scheme in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Transaction-signalling.xml b/static/bitcoin-dev/May_2017/combined_Transaction-signalling.xml index d2b44f3209..3705cf51f2 100644 --- a/static/bitcoin-dev/May_2017/combined_Transaction-signalling.xml +++ b/static/bitcoin-dev/May_2017/combined_Transaction-signalling.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Transaction signalling - 2023-08-01T20:30:08.114536+00:00 - - Erik Aronesty 2017-05-03 19:41:07+00:00 - - - Erik Aronesty 2017-04-20 16:14:18+00:00 - - - Tim Ruffing 2017-04-18 22:29:17+00:00 - - - Christian Decker 2017-04-18 18:07:25+00:00 - - - Erik Aronesty 2017-04-18 18:01:52+00:00 - - - Marcel Jamin 2017-04-18 14:52:04+00:00 - - - Erik Aronesty 2017-04-17 15:50:51+00:00 - + 2025-09-26T15:58:21.902733+00:00 + python-feedgen + + + [bitcoin-dev] Transaction signalling Erik Aronesty + 2017-04-17T15:50:00.000Z + + + Marcel Jamin + 2017-04-18T14:52:00.000Z + + + Erik Aronesty + 2017-04-18T18:01:00.000Z + + + Christian Decker + 2017-04-18T18:07:00.000Z + + + Tim Ruffing + 2017-04-18T22:29:00.000Z + + + Erik Aronesty + 2017-04-20T16:14:00.000Z + + + Erik Aronesty + 2017-05-03T19:41:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Transaction signalling - 2023-08-01T20:30:08.114536+00:00 + 2025-09-26T15:58:21.903693+00:00 - BIP XXXX proposes a change to the usage of the 'OP_RETURN' script opcode in Bitcoin transactions, allowing multiple changes (features) to be deployed in parallel. The proposal relies on interpreting the output field as a bit vector, where each bit can be used to track an independent change. BIP9 introduced a mechanism for doing soft-forking changes relying on measuring miner support indicated by version bits in block headers.However, any change which may conflict with miners but is acceptable to users may be difficult to deploy. BIP XXXX can be used in conjunction with BIP 9 to more safely deploy soft-forking changes that do not require a supermajority of miners but do require a large percentage of active users. Alternatively, BIP XXXX signalling can be used to gauge user support for "features" - independent of its use as a direct deployment mechanism. Each "feature" is specified by the same set of per-chain parameters as in BIP9, with the same usage and meaning (name, bit, starttime and timeout).If the outputs contain a zero valued OP_RETURN, and the length of the key is 2 bytes, and if the first byte (prefix) of that OP_RETURN's key parameter is 0x012, then the remaining byte is to be interpreted as an 8-bit little-endian integer, and bits are selected within this integer as values. The alternative to flag-day deployment can cause issues for users of a feature that has failed to achieve adequate miner support. BIP XXXX proposes a solution to this problem.In a bitcoin-dev thread, Christian Decker proposed the extension of signaling capabilities to end-users, which would give stakeholders a voice in network decisions. He suggested using output scripts as the best field for signaling since they are specified by the recipient of funds and are already stored in the UTXO. The last 4 bits of the pubkey/pubkeyhash could be used to opt-in, with the vote (0/1) depending on the stakeholders' desired signal.However, unlike the OP_RETURN proposal, users who do not intend to signal will also be included in the tally. To ensure voluntary votes, the opt-in should be adjusted accordingly, but too many opt-in bits may exacerbate existing problems with HD Wallet lookahead. Tim Ruffing added that using addresses creates vulnerabilities, so an OP_RETURN signal seems the safest way to go for UA signaling. He suggested modeling a BIP after BIP9, with some discussion of how to properly collect statistics and the ability for nodes to activate features based on an "economic majority" defined in this way.One member of the bitcoin-dev mailing list, Tim, doesn't have a general opinion on signaling, but does express concern about using addresses for signaling, citing privacy implications. Christian Decker responds to Tim's concerns, suggesting that extending signaling capabilities to end-users would give stakeholders a voice in network decisions and provide data for informed decisions. Decker suggests several fields that could be used for signaling, including OP_RETURN, locktime, and output scripts, but ultimately decides that output scripts are likely the best option due to their easy tallying and the fact that they are already stored in the UTXO.The writer is in favor of extending signaling capabilities to the end-users. While exploring various signaling ideas, the writer suggests that fields such as OP_RETURN and locktime may not be suitable for this purpose due to issues related to data transfer, storage, and tagging. The output script field is suggested as the best option for signaling as it is specified by the recipient of funds and is already stored in UTXO. The writer also suggests using the last 4 bits of the pubkey/pubkeyhash to opt-in and vote.A proposal has been made to tag fee-paying transactions with information about the capabilities of the node that created it. The tagging would occur on the addresses, and the weighting would be by value, so it's a measure of economic significance. This could be useful in gauging economic support for certain upgrades, especially if excluding long transaction chains.A suggestion was made on the Bitcoin-dev mailing list about adding a signal to OP_RETURN that would allow users to tag validated input addresses. With this information, nodes could activate new features after a certain percentage of tagged input addresses is reached within a specific time period. This tagging may provide a better indication of economic support for certain upgrades than simply counting reachable nodes.The proposal suggests using a signal added to OP_RETURN to tag all validated input addresses. This would allow a node to activate a new feature after a certain percentage of tagged input addresses are reached within a specified time period. The idea is to use this in addition to a flag day to trigger feature activation with some reassurance of user uptake. 2017-05-03T19:41:07+00:00 + BIP XXXX proposes a change to the usage of the 'OP_RETURN' script opcode in Bitcoin transactions, allowing multiple changes (features) to be deployed in parallel. The proposal relies on interpreting the output field as a bit vector, where each bit can be used to track an independent change. BIP9 introduced a mechanism for doing soft-forking changes relying on measuring miner support indicated by version bits in block headers.However, any change which may conflict with miners but is acceptable to users may be difficult to deploy. BIP XXXX can be used in conjunction with BIP 9 to more safely deploy soft-forking changes that do not require a supermajority of miners but do require a large percentage of active users. Alternatively, BIP XXXX signalling can be used to gauge user support for "features" - independent of its use as a direct deployment mechanism. Each "feature" is specified by the same set of per-chain parameters as in BIP9, with the same usage and meaning (name, bit, starttime and timeout).If the outputs contain a zero valued OP_RETURN, and the length of the key is 2 bytes, and if the first byte (prefix) of that OP_RETURN's key parameter is 0x012, then the remaining byte is to be interpreted as an 8-bit little-endian integer, and bits are selected within this integer as values. The alternative to flag-day deployment can cause issues for users of a feature that has failed to achieve adequate miner support. BIP XXXX proposes a solution to this problem.In a bitcoin-dev thread, Christian Decker proposed the extension of signaling capabilities to end-users, which would give stakeholders a voice in network decisions. He suggested using output scripts as the best field for signaling since they are specified by the recipient of funds and are already stored in the UTXO. The last 4 bits of the pubkey/pubkeyhash could be used to opt-in, with the vote (0/1) depending on the stakeholders' desired signal.However, unlike the OP_RETURN proposal, users who do not intend to signal will also be included in the tally. To ensure voluntary votes, the opt-in should be adjusted accordingly, but too many opt-in bits may exacerbate existing problems with HD Wallet lookahead. Tim Ruffing added that using addresses creates vulnerabilities, so an OP_RETURN signal seems the safest way to go for UA signaling. He suggested modeling a BIP after BIP9, with some discussion of how to properly collect statistics and the ability for nodes to activate features based on an "economic majority" defined in this way.One member of the bitcoin-dev mailing list, Tim, doesn't have a general opinion on signaling, but does express concern about using addresses for signaling, citing privacy implications. Christian Decker responds to Tim's concerns, suggesting that extending signaling capabilities to end-users would give stakeholders a voice in network decisions and provide data for informed decisions. Decker suggests several fields that could be used for signaling, including OP_RETURN, locktime, and output scripts, but ultimately decides that output scripts are likely the best option due to their easy tallying and the fact that they are already stored in the UTXO.The writer is in favor of extending signaling capabilities to the end-users. While exploring various signaling ideas, the writer suggests that fields such as OP_RETURN and locktime may not be suitable for this purpose due to issues related to data transfer, storage, and tagging. The output script field is suggested as the best option for signaling as it is specified by the recipient of funds and is already stored in UTXO. The writer also suggests using the last 4 bits of the pubkey/pubkeyhash to opt-in and vote.A proposal has been made to tag fee-paying transactions with information about the capabilities of the node that created it. The tagging would occur on the addresses, and the weighting would be by value, so it's a measure of economic significance. This could be useful in gauging economic support for certain upgrades, especially if excluding long transaction chains.A suggestion was made on the Bitcoin-dev mailing list about adding a signal to OP_RETURN that would allow users to tag validated input addresses. With this information, nodes could activate new features after a certain percentage of tagged input addresses is reached within a specific time period. This tagging may provide a better indication of economic support for certain upgrades than simply counting reachable nodes.The proposal suggests using a signal added to OP_RETURN to tag all validated input addresses. This would allow a node to activate a new feature after a certain percentage of tagged input addresses are reached within a specified time period. The idea is to use this in addition to a flag day to trigger feature activation with some reassurance of user uptake. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2017/combined_Treating-ASICBOOST-as-a-Security-Vulnerability.xml b/static/bitcoin-dev/May_2017/combined_Treating-ASICBOOST-as-a-Security-Vulnerability.xml index ca5233aa34..03bc953941 100644 --- a/static/bitcoin-dev/May_2017/combined_Treating-ASICBOOST-as-a-Security-Vulnerability.xml +++ b/static/bitcoin-dev/May_2017/combined_Treating-ASICBOOST-as-a-Security-Vulnerability.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Treating ‘ASICBOOST’ as a Security Vulnerability - 2023-08-01T20:38:23.982664+00:00 - - Cameron Garnham 2017-05-24 17:59:28+00:00 - - - Cameron Garnham 2017-05-19 07:32:36+00:00 - - - Erik Aronesty 2017-05-19 07:16:20+00:00 - - - Ryan Grant 2017-05-18 19:28:38+00:00 - - - Tier Nolan 2017-05-18 14:59:50+00:00 - - - James Hilliard 2017-05-18 13:57:08+00:00 - - - Cameron Garnham 2017-05-18 13:44:47+00:00 - + 2025-09-26T15:57:54.146237+00:00 + python-feedgen + + + [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability Cameron Garnham + 2017-05-18T13:44:00.000Z + + + James Hilliard + 2017-05-18T13:57:00.000Z + + + Tier Nolan + 2017-05-18T14:59:00.000Z + + + Ryan Grant + 2017-05-18T19:28:00.000Z + + + Erik Aronesty + 2017-05-19T07:16:00.000Z + + + Cameron Garnham + 2017-05-19T07:32:00.000Z + + + Cameron Garnham + 2017-05-24T17:59:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Treating ‘ASICBOOST’ as a Security Vulnerability - 2023-08-01T20:38:23.982664+00:00 + 2025-09-26T15:57:54.147223+00:00 - The vulnerability known as ASICBOOST has been assigned a CVE identifier, CVE-2017-9230, by Bitcoin developers. This security vulnerability exploits the design of Bitcoin's proof-of-work algorithm, violating the assumptions that each execution of the function will be independent and that the choice of input should not change its difficulty to evaluate. Originally promoted as a patented mining optimization, ASICBOOST is now regarded as an actively exploited security vulnerability. The patent holder has a dedicated website for this vulnerability. The Mitre CVE team suggested a more appropriate description for CVE-2017-9230 than the one proposed by the developer who assigned the vulnerability number.Several discussions and academic write-ups are available online regarding ASICBOOST. Ryan Grant discusses the perverse incentives created by the vulnerability, while Tier Nolan discusses the non-independent calculation of the proof-of-work. Gregory Maxwell provides evidence of active exploitation of the vulnerability. The original discovery of the vulnerability was made by Dr. Timo Hanke and Sergio Lerner, and it was reported to CVE by Cameron Garnham.ASICBOOST affects all versions of Bitcoin and creates unfair advantages in mining, leading to layer-violations and creating perverse system incentives. The vulnerability falls under Cryptocurrency Mining Algorithm Weakness and Cryptocurrency Proof-of-Work Algorithm Weakness. Bitcoin has confirmed the existence of the vulnerability as the vendor of the product.In an email thread, Cameron Garnham expresses concern that ASICBOOST violates the security assumptions of Bitcoin's proof-of-work function. Garnham argues that the vulnerability creates deviations from the Bitcoin Security Model, potentially leading to security vulnerabilities. Tier Nolan suggests that as long as the effort to find a block is proportional to the block difficulty parameter, ASICBOOST is simply an optimization rather than an exploit. However, it has been discovered that bits in the block header can be used for dual meanings, creating unexpected incentives to block protocol improvements. Therefore, action must be taken to address this issue promptly.Cameron Garnham highlights in an email to the bitcoin-dev mailing list that significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities. The effort to find a block should be proportional to the block difficulty parameter, but ASICBOOST performs multiple checks in parallel, violating the independence of each hash. This creates a vulnerability in the system. Garnham argues that 'ASICBOOST' attacks Bitcoin's security assumptions and exploits the Proof-of-Work Function. He recommends fixing this vulnerability quickly by implementing various measures such as adding extra data in the Coinbase Transaction and making a deterministic ordering of transaction chains within a block.Another member of the Bitcoin Development Mailing List suggests that the current approach to 'ASICBOOST' does not comply with established best practices for security vulnerabilities. Deviations from the Bitcoin Security Model should be considered security vulnerabilities, and being able to craft inputs that are significantly easier to check than alternatives is a vulnerability. They recommend assigning a CVE to the vulnerability exploited by 'ASICBOOST' and taking swift action to restore the quality of the Bitcoin Proof-of-Work function. Various steps are suggested, including adding extra data in the Coinbase Transaction and making a deterministic ordering of transaction chains within a block. If there is a hard-fork, the Proof-of-Work internal merkle structure should be directly considered. The writer emphasizes the need for the Bitcoin community to fix this vulnerability promptly. 2017-05-24T17:59:28+00:00 + The vulnerability known as ASICBOOST has been assigned a CVE identifier, CVE-2017-9230, by Bitcoin developers. This security vulnerability exploits the design of Bitcoin's proof-of-work algorithm, violating the assumptions that each execution of the function will be independent and that the choice of input should not change its difficulty to evaluate. Originally promoted as a patented mining optimization, ASICBOOST is now regarded as an actively exploited security vulnerability. The patent holder has a dedicated website for this vulnerability. The Mitre CVE team suggested a more appropriate description for CVE-2017-9230 than the one proposed by the developer who assigned the vulnerability number.Several discussions and academic write-ups are available online regarding ASICBOOST. Ryan Grant discusses the perverse incentives created by the vulnerability, while Tier Nolan discusses the non-independent calculation of the proof-of-work. Gregory Maxwell provides evidence of active exploitation of the vulnerability. The original discovery of the vulnerability was made by Dr. Timo Hanke and Sergio Lerner, and it was reported to CVE by Cameron Garnham.ASICBOOST affects all versions of Bitcoin and creates unfair advantages in mining, leading to layer-violations and creating perverse system incentives. The vulnerability falls under Cryptocurrency Mining Algorithm Weakness and Cryptocurrency Proof-of-Work Algorithm Weakness. Bitcoin has confirmed the existence of the vulnerability as the vendor of the product.In an email thread, Cameron Garnham expresses concern that ASICBOOST violates the security assumptions of Bitcoin's proof-of-work function. Garnham argues that the vulnerability creates deviations from the Bitcoin Security Model, potentially leading to security vulnerabilities. Tier Nolan suggests that as long as the effort to find a block is proportional to the block difficulty parameter, ASICBOOST is simply an optimization rather than an exploit. However, it has been discovered that bits in the block header can be used for dual meanings, creating unexpected incentives to block protocol improvements. Therefore, action must be taken to address this issue promptly.Cameron Garnham highlights in an email to the bitcoin-dev mailing list that significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities. The effort to find a block should be proportional to the block difficulty parameter, but ASICBOOST performs multiple checks in parallel, violating the independence of each hash. This creates a vulnerability in the system. Garnham argues that 'ASICBOOST' attacks Bitcoin's security assumptions and exploits the Proof-of-Work Function. He recommends fixing this vulnerability quickly by implementing various measures such as adding extra data in the Coinbase Transaction and making a deterministic ordering of transaction chains within a block.Another member of the Bitcoin Development Mailing List suggests that the current approach to 'ASICBOOST' does not comply with established best practices for security vulnerabilities. Deviations from the Bitcoin Security Model should be considered security vulnerabilities, and being able to craft inputs that are significantly easier to check than alternatives is a vulnerability. They recommend assigning a CVE to the vulnerability exploited by 'ASICBOOST' and taking swift action to restore the quality of the Bitcoin Proof-of-Work function. Various steps are suggested, including adding extra data in the Coinbase Transaction and making a deterministic ordering of transaction chains within a block. If there is a hard-fork, the Proof-of-Work internal merkle structure should be directly considered. The writer emphasizes the need for the Bitcoin community to fix this vulnerability promptly. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_-bitcoin-discuss-Checkpoints-in-the-Blockchain-.xml b/static/bitcoin-dev/May_2018/combined_-bitcoin-discuss-Checkpoints-in-the-Blockchain-.xml index d93c58e054..d2d3137426 100644 --- a/static/bitcoin-dev/May_2018/combined_-bitcoin-discuss-Checkpoints-in-the-Blockchain-.xml +++ b/static/bitcoin-dev/May_2018/combined_-bitcoin-discuss-Checkpoints-in-the-Blockchain-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [bitcoin-discuss] Checkpoints in the Blockchain. - 2023-08-01T23:15:10.445844+00:00 + 2025-09-26T15:37:51.467339+00:00 + python-feedgen Dave Scotese 2018-05-21 20:03:37+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [bitcoin-discuss] Checkpoints in the Blockchain. - 2023-08-01T23:15:10.445844+00:00 + 2025-09-26T15:37:51.467522+00:00 - The Bitcoin-discuss forum has been discussing the importance of deep blockchain corruption recovery mechanisms and the potential issues with using Stuxnet to change copies of the blockchain. Some members suggest rendering the blockchain into something memorable to prevent hijacking of memory, while others argue that the blockchain itself is the perfect solution due to its internal consistency and resistance to attacks. However, concerns have been raised about the creation of two versions of the code, one with a fake checkpoint useful to a powerful attacker.The discussion highlights the need for a shared memory of the state of a recent UTXO Set to obviate the need for historical transaction data and the challenges of choosing between multiple options. It emphasizes the importance of maintaining the integrity of the blockchain to ensure the validity of transactions and the security of the network.One suggestion put forth by Dave Scotese on the mailing list is to render a SHA256 hash into something memorable and difficult to forget. Each of the 256 bits could be used to specify something important about the rendering, which is memorable in an instinctive human-memory way. If enough people involved in Bitcoin recognize this protection, it relieves the need to retain the full blockchain to validate the UTXO Set at that point, as it can be validated without reference to any prior computer record.Scott Roberts disagreed with this premise and proposed using words as a common way of achieving what Scotese was thinking about. By making the checkpoint a hash that meets a difficulty target, the possibilities are reduced to 2^182 at the current hashrate instead of 2^256, requiring only 12 or 13 common words. To address the issue of forgetting passphrases, Scotese suggests coupling the data with more items than usual, creating a phrase memorable only in the language for which the algorithm is developed.An algorithm could be used with the Bip39 word list to categorize the words according to parts of speech. The bits could then be used to determine the next word in a kind of ad-lib, but this creates a phrase that is only memorable in the language for which the algorithm is developed.Overall, the discussion highlights the importance of finding ways to maintain the integrity of the blockchain while making it more accessible and user-friendly. 2018-05-21T20:03:37+00:00 + The Bitcoin-discuss forum has been discussing the importance of deep blockchain corruption recovery mechanisms and the potential issues with using Stuxnet to change copies of the blockchain. Some members suggest rendering the blockchain into something memorable to prevent hijacking of memory, while others argue that the blockchain itself is the perfect solution due to its internal consistency and resistance to attacks. However, concerns have been raised about the creation of two versions of the code, one with a fake checkpoint useful to a powerful attacker.The discussion highlights the need for a shared memory of the state of a recent UTXO Set to obviate the need for historical transaction data and the challenges of choosing between multiple options. It emphasizes the importance of maintaining the integrity of the blockchain to ensure the validity of transactions and the security of the network.One suggestion put forth by Dave Scotese on the mailing list is to render a SHA256 hash into something memorable and difficult to forget. Each of the 256 bits could be used to specify something important about the rendering, which is memorable in an instinctive human-memory way. If enough people involved in Bitcoin recognize this protection, it relieves the need to retain the full blockchain to validate the UTXO Set at that point, as it can be validated without reference to any prior computer record.Scott Roberts disagreed with this premise and proposed using words as a common way of achieving what Scotese was thinking about. By making the checkpoint a hash that meets a difficulty target, the possibilities are reduced to 2^182 at the current hashrate instead of 2^256, requiring only 12 or 13 common words. To address the issue of forgetting passphrases, Scotese suggests coupling the data with more items than usual, creating a phrase memorable only in the language for which the algorithm is developed.An algorithm could be used with the Bip39 word list to categorize the words according to parts of speech. The bits could then be used to determine the next word in a kind of ad-lib, but this creates a phrase that is only memorable in the language for which the algorithm is developed.Overall, the discussion highlights the importance of finding ways to maintain the integrity of the blockchain while making it more accessible and user-friendly. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_BIP-158-Flexibility-and-Filter-Size.xml b/static/bitcoin-dev/May_2018/combined_BIP-158-Flexibility-and-Filter-Size.xml index e6c50a6743..451ef29463 100644 --- a/static/bitcoin-dev/May_2018/combined_BIP-158-Flexibility-and-Filter-Size.xml +++ b/static/bitcoin-dev/May_2018/combined_BIP-158-Flexibility-and-Filter-Size.xml @@ -1,188 +1,251 @@ - + 2 Combined summary - BIP 158 Flexibility and Filter Size - 2023-08-01T23:11:29.318749+00:00 - - Olaoluwa Osuntokun 2018-06-12 23:58:50+00:00 - - - Olaoluwa Osuntokun 2018-06-12 23:51:29+00:00 - - - Gregory Maxwell 2018-06-09 15:45:54+00:00 - - - David A. Harding 2018-06-09 10:34:45+00:00 - - - Olaoluwa Osuntokun 2018-06-08 23:35:29+00:00 - - - Gregory Maxwell 2018-06-08 16:14:41+00:00 - - - Olaoluwa Osuntokun 2018-06-08 05:03:04+00:00 - - - Riccardo Casatta 2018-06-06 15:14:17+00:00 - - - Olaoluwa Osuntokun 2018-06-06 01:12:55+00:00 - - - Gregory Maxwell 2018-06-05 17:52:29+00:00 - - - Jim Posen 2018-06-05 17:22:04+00:00 - - - Karl-Johan Alm 2018-06-05 04:33:06+00:00 - - - Jim Posen 2018-06-05 01:08:01+00:00 - - - Riccardo Casatta 2018-06-04 08:42:10+00:00 - - - Tamas Blummer 2018-06-03 16:50:17+00:00 - - - Tamas Blummer 2018-06-03 16:44:04+00:00 - - - Pieter Wuille 2018-06-03 06:11:56+00:00 - - - Tamas Blummer 2018-06-03 05:14:34+00:00 - - - Gregory Maxwell 2018-06-03 00:28:33+00:00 - - - Tamas Blummer 2018-06-02 22:02:11+00:00 - - - David A. Harding 2018-06-02 12:41:57+00:00 - - - Jim Posen 2018-06-02 02:02:38+00:00 - - - Gregory Maxwell 2018-06-02 00:22:25+00:00 - - - Olaoluwa Osuntokun 2018-06-02 00:01:43+00:00 - - - Gregory Maxwell 2018-06-01 04:15:13+00:00 - - - Olaoluwa Osuntokun 2018-06-01 02:52:48+00:00 - - - Tamas Blummer 2018-05-31 14:27:50+00:00 - - - Olaoluwa Osuntokun 2018-05-29 04:01:35+00:00 - - - Gregory Maxwell 2018-05-29 03:24:45+00:00 - - - Jim Posen 2018-05-29 02:42:52+00:00 - - - Gregory Maxwell 2018-05-28 19:24:09+00:00 - - - Tamas Blummer 2018-05-28 18:28:16+00:00 - - - Tamas Blummer 2018-05-28 18:18:12+00:00 - - - Jim Posen 2018-05-24 03:48:00+00:00 - - - Conner Fromknecht 2018-05-24 01:04:34+00:00 - - - Gregory Maxwell 2018-05-23 17:28:29+00:00 - - - Johan Torås Halseth 2018-05-23 08:16:41+00:00 - - - Jim Posen 2018-05-23 07:38:40+00:00 - - - Jim Posen 2018-05-23 00:42:29+00:00 - - - Johan Torås Halseth 2018-05-22 09:23:29+00:00 - - - Olaoluwa Osuntokun 2018-05-22 01:16:52+00:00 - - - Olaoluwa Osuntokun 2018-05-22 01:15:22+00:00 - - - Johan Torås Halseth 2018-05-21 08:35:28+00:00 - - - Olaoluwa Osuntokun 2018-05-19 03:12:09+00:00 - - - Olaoluwa Osuntokun 2018-05-19 03:08:29+00:00 - - - Pieter Wuille 2018-05-19 03:06:10+00:00 - - - Olaoluwa Osuntokun 2018-05-19 02:57:12+00:00 - - - Olaoluwa Osuntokun 2018-05-19 02:51:02+00:00 - - - Riccardo Casatta 2018-05-18 08:46:29+00:00 - - - Karl-Johan Alm 2018-05-18 06:28:39+00:00 - - - Jim Posen 2018-05-17 21:27:15+00:00 - - - Gregory Maxwell 2018-05-17 20:45:33+00:00 - - - Jim Posen 2018-05-17 20:19:17+00:00 - - - Gregory Maxwell 2018-05-17 18:34:45+00:00 - - - Gregory Maxwell 2018-05-17 18:34:45+00:00 - - - Matt Corallo 2018-05-17 16:59:22+00:00 - - - Gregory Maxwell 2018-05-17 16:36:37+00:00 - - - Matt Corallo 2018-05-17 15:46:18+00:00 - - - Peter Todd 2018-05-17 15:43:15+00:00 - - - Matt Corallo 2018-05-17 15:25:12+00:00 - + 2025-09-26T15:38:02.008598+00:00 + python-feedgen + + + [bitcoin-dev] BIP 158 Flexibility and Filter Size Matt Corallo + 2018-05-17T15:25:00.000Z + + + Peter Todd + 2018-05-17T15:43:00.000Z + + + Matt Corallo + 2018-05-17T15:46:00.000Z + + + Gregory Maxwell + 2018-05-17T16:36:00.000Z + + + Matt Corallo + 2018-05-17T16:59:00.000Z + + + Gregory Maxwell + 2018-05-17T18:34:00.000Z + + + Gregory Maxwell + 2018-05-17T18:34:00.000Z + + + Jim Posen + 2018-05-17T20:19:00.000Z + + + Gregory Maxwell + 2018-05-17T20:45:00.000Z + + + Jim Posen + 2018-05-17T21:27:00.000Z + + + Karl-Johan Alm + 2018-05-18T06:28:00.000Z + + + Riccardo Casatta + 2018-05-18T08:46:00.000Z + + + Olaoluwa Osuntokun + 2018-05-19T02:51:00.000Z + + + Olaoluwa Osuntokun + 2018-05-19T02:57:00.000Z + + + Pieter Wuille + 2018-05-19T03:06:00.000Z + + + Olaoluwa Osuntokun + 2018-05-19T03:08:00.000Z + + + Olaoluwa Osuntokun + 2018-05-19T03:12:00.000Z + + + Johan Torås Halseth + 2018-05-21T08:35:00.000Z + + + Olaoluwa Osuntokun + 2018-05-22T01:15:00.000Z + + + Olaoluwa Osuntokun + 2018-05-22T01:16:00.000Z + + + Johan Torås Halseth + 2018-05-22T09:23:00.000Z + + + Jim Posen + 2018-05-23T00:42:00.000Z + + + Jim Posen + 2018-05-23T07:38:00.000Z + + + Johan Torås Halseth + 2018-05-23T08:16:00.000Z + + + Gregory Maxwell + 2018-05-23T17:28:00.000Z + + + Conner Fromknecht + 2018-05-24T01:04:00.000Z + + + Jim Posen + 2018-05-24T03:48:00.000Z + + + Tamas Blummer + 2018-05-28T18:18:00.000Z + + + Tamas Blummer + 2018-05-28T18:28:00.000Z + + + Gregory Maxwell + 2018-05-28T19:24:00.000Z + + + Jim Posen + 2018-05-29T02:42:00.000Z + + + Gregory Maxwell + 2018-05-29T03:24:00.000Z + + + Olaoluwa Osuntokun + 2018-05-29T04:01:00.000Z + + + Tamas Blummer + 2018-05-31T14:27:00.000Z + + + Olaoluwa Osuntokun + 2018-06-01T02:52:00.000Z + + + Gregory Maxwell + 2018-06-01T04:15:00.000Z + + + Olaoluwa Osuntokun + 2018-06-02T00:01:00.000Z + + + Gregory Maxwell + 2018-06-02T00:22:00.000Z + + + Jim Posen + 2018-06-02T02:02:00.000Z + + + David A. Harding + 2018-06-02T12:41:00.000Z + + + Tamas Blummer + 2018-06-02T22:02:00.000Z + + + Gregory Maxwell + 2018-06-03T00:28:00.000Z + + + Tamas Blummer + 2018-06-03T05:14:00.000Z + + + Pieter Wuille + 2018-06-03T06:11:00.000Z + + + Tamas Blummer + 2018-06-03T16:44:00.000Z + + + Tamas Blummer + 2018-06-03T16:50:00.000Z + + + Riccardo Casatta + 2018-06-04T08:42:00.000Z + + + Jim Posen + 2018-06-05T01:08:00.000Z + + + Karl-Johan Alm + 2018-06-05T04:33:00.000Z + + + Jim Posen + 2018-06-05T17:22:00.000Z + + + Gregory Maxwell + 2018-06-05T17:52:00.000Z + + + Olaoluwa Osuntokun + 2018-06-06T01:12:00.000Z + + + Riccardo Casatta + 2018-06-06T15:14:00.000Z + + + Olaoluwa Osuntokun + 2018-06-08T05:03:00.000Z + + + Gregory Maxwell + 2018-06-08T16:14:00.000Z + + + Olaoluwa Osuntokun + 2018-06-08T23:35:00.000Z + + + David A. Harding + 2018-06-09T10:34:00.000Z + + + Gregory Maxwell + 2018-06-09T15:45:00.000Z + + + Olaoluwa Osuntokun + 2018-06-12T23:51:00.000Z + + + Olaoluwa Osuntokun + 2018-06-12T23:58:00.000Z + + @@ -243,13 +306,13 @@ - python-feedgen + 2 Combined summary - BIP 158 Flexibility and Filter Size - 2023-08-01T23:11:29.319752+00:00 + 2025-09-26T15:38:02.014399+00:00 - The conversation on the bitcoin-dev mailing list revolves around the implementation of new filter formats and commitments for Bitcoin. One proposal suggests excluding OP_RETURN outputs from BIP-158 filters to avoid polluting the filters. The Tier Nolan proposal, which creates a constant-sized proof for future commitments, is viewed as an ugly hack and difficult to implement "full" validation. There is a debate about optimizing for better security or lower bandwidth.The cost and practicality of the current filter design are also discussed. Adding more commitments is seen as a priority, and coordination for an ultimate extensible commitment is suggested. However, the current filter format cannot be committed due to indexing issues. The debate focuses on the trade-off between security and bandwidth optimization.The proposal to change the way filters are created for Bitcoin transactions is also addressed. Currently, the "regular" filter includes the outpoint, but there is a suggestion to switch to including prev scripts instead. The debate focuses on the cost, practicality, and security implications of this change.Multi-layer filtering in BIP 157/158 is also discussed. The benefits of using a map instead of a filter for upper layers are discussed, along with the possibility of using multi-block filters. The process of removing unnecessary items or filters is ongoing, and custom filter types and batch fetching based on block height and numerical range are already defined in BIPs.Tamas Blummer conducted an analysis on the use of filters in Bitcoin history and found that certain filters were smaller than others. The savings from using these filters have been decreasing over time. Blummer also discussed the importance of lighter but SPV secure nodes in helping the network grow while maintaining security.There are debates about relying on a "single honest peer" security model, the current state of non-existing validation in SPV software, and the need for generalized proposals that allow for future extensibility.In conclusion, the discussions revolve around finding the optimal design for filters in light clients, considering factors such as security, efficiency, and data size. Various proposals and modifications have been suggested to improve the current system, and there is ongoing debate about the best approach.The bitcoin-dev mailing list has been engaged in discussions about improving the implementation of block filters, reducing filter sizes, and enhancing security in decentralized networks that store money. The possibility of splitting the basic filter into separate filters based on data type is mentioned, along with potential solutions to address bandwidth concerns. One proposal, BIP 158, aims to enhance the security and privacy of Simplified Payment Verification (SPV) clients. However, concerns have been raised about its impact on existing SPV clients' willingness to adopt it compared to the current bloom filter garbage.The size of the filters used in BIP 158 has been questioned as they may discourage the use of this new approach by existing SPV clients. To overcome this, further exploration is needed to find ways to split out filters and reduce bandwidth usage. A suggestion made is to provide filters specifically designed for certain script templates, such as retrieving outputs that are a specific segwit version X. This targeted filtering could potentially decrease the overall bandwidth required for transactions.It is hoped that by implementing these improvements, the adoption of BIP 158 can be encouraged among SPV clients without compromising their efficiency or willingness to use this enhanced security measure. The discussions on the bitcoin-dev mailing list revolve around finding solutions to improve the implementation of block filters, reducing filter sizes, and enhancing security in decentralized networks that store money. Various suggestions and considerations regarding the filtering process and its impact on lite clients, bandwidth, and network security are being discussed. Further exploration is needed to address concerns about the size of filters used in BIP 158 and their potential impact on existing SPV clients' adoption of the proposal. Splitting out filters based on data type and providing filters specifically designed for certain script templates are suggested approaches to reduce bandwidth usage. These improvements aim to encourage the adoption of BIP 158 while maintaining efficiency and willingness among SPV clients to use this enhanced security measure. 2018-06-12T23:58:50+00:00 + The conversation on the bitcoin-dev mailing list revolves around the implementation of new filter formats and commitments for Bitcoin. One proposal suggests excluding OP_RETURN outputs from BIP-158 filters to avoid polluting the filters. The Tier Nolan proposal, which creates a constant-sized proof for future commitments, is viewed as an ugly hack and difficult to implement "full" validation. There is a debate about optimizing for better security or lower bandwidth.The cost and practicality of the current filter design are also discussed. Adding more commitments is seen as a priority, and coordination for an ultimate extensible commitment is suggested. However, the current filter format cannot be committed due to indexing issues. The debate focuses on the trade-off between security and bandwidth optimization.The proposal to change the way filters are created for Bitcoin transactions is also addressed. Currently, the "regular" filter includes the outpoint, but there is a suggestion to switch to including prev scripts instead. The debate focuses on the cost, practicality, and security implications of this change.Multi-layer filtering in BIP 157/158 is also discussed. The benefits of using a map instead of a filter for upper layers are discussed, along with the possibility of using multi-block filters. The process of removing unnecessary items or filters is ongoing, and custom filter types and batch fetching based on block height and numerical range are already defined in BIPs.Tamas Blummer conducted an analysis on the use of filters in Bitcoin history and found that certain filters were smaller than others. The savings from using these filters have been decreasing over time. Blummer also discussed the importance of lighter but SPV secure nodes in helping the network grow while maintaining security.There are debates about relying on a "single honest peer" security model, the current state of non-existing validation in SPV software, and the need for generalized proposals that allow for future extensibility.In conclusion, the discussions revolve around finding the optimal design for filters in light clients, considering factors such as security, efficiency, and data size. Various proposals and modifications have been suggested to improve the current system, and there is ongoing debate about the best approach.The bitcoin-dev mailing list has been engaged in discussions about improving the implementation of block filters, reducing filter sizes, and enhancing security in decentralized networks that store money. The possibility of splitting the basic filter into separate filters based on data type is mentioned, along with potential solutions to address bandwidth concerns. One proposal, BIP 158, aims to enhance the security and privacy of Simplified Payment Verification (SPV) clients. However, concerns have been raised about its impact on existing SPV clients' willingness to adopt it compared to the current bloom filter garbage.The size of the filters used in BIP 158 has been questioned as they may discourage the use of this new approach by existing SPV clients. To overcome this, further exploration is needed to find ways to split out filters and reduce bandwidth usage. A suggestion made is to provide filters specifically designed for certain script templates, such as retrieving outputs that are a specific segwit version X. This targeted filtering could potentially decrease the overall bandwidth required for transactions.It is hoped that by implementing these improvements, the adoption of BIP 158 can be encouraged among SPV clients without compromising their efficiency or willingness to use this enhanced security measure. The discussions on the bitcoin-dev mailing list revolve around finding solutions to improve the implementation of block filters, reducing filter sizes, and enhancing security in decentralized networks that store money. Various suggestions and considerations regarding the filtering process and its impact on lite clients, bandwidth, and network security are being discussed. Further exploration is needed to address concerns about the size of filters used in BIP 158 and their potential impact on existing SPV clients' adoption of the proposal. Splitting out filters based on data type and providing filters specifically designed for certain script templates are suggested approaches to reduce bandwidth usage. These improvements aim to encourage the adoption of BIP 158 while maintaining efficiency and willingness among SPV clients to use this enhanced security measure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml b/static/bitcoin-dev/May_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml index ae34a4ef91..9e45d4b511 100644 --- a/static/bitcoin-dev/May_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml +++ b/static/bitcoin-dev/May_2018/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml @@ -1,41 +1,47 @@ - + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 - - Giulia Fanti 2018-07-08 12:50:43+00:00 - - - Gregory Maxwell 2018-06-26 05:20:02+00:00 - - - Bradley Denby 2018-06-26 00:12:02+00:00 - - - Pieter Wuille 2018-06-12 01:05:14+00:00 - - - Bradley Denby 2018-06-11 14:31:09+00:00 - - - Pieter Wuille 2018-06-06 04:01:00+00:00 - - - Bradley Denby 2018-06-04 20:29:50+00:00 - - - Bradley Denby 2018-05-10 12:59:12+00:00 - - - Giulia Fanti 2017-09-21 02:10:29+00:00 - - - Gregory Maxwell 2017-06-13 01:00:50+00:00 - - - Andrew Miller 2017-06-12 14:46:23+00:00 - + 2025-09-26T15:37:57.763061+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation Bradley Denby + 2018-05-10T12:59:00.000Z + + + Bradley Denby + 2018-06-04T20:29:00.000Z + + + Pieter Wuille + 2018-06-06T04:01:00.000Z + + + Bradley Denby + 2018-06-11T14:31:00.000Z + + + Pieter Wuille + 2018-06-12T01:05:00.000Z + + + Bradley Denby + 2018-06-26T00:12:00.000Z + + + Gregory Maxwell + 2018-06-26T05:20:00.000Z + + + Neudecker, Till (TM) + 2018-07-05T14:50:00.000Z + + + Giulia Fanti + 2018-07-08T12:50:00.000Z + + @@ -47,13 +53,13 @@ - python-feedgen + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 + 2025-09-26T15:37:57.764205+00:00 - The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality 2018-07-08T12:50:43+00:00 + The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_BIP-sighash-noinput.xml b/static/bitcoin-dev/May_2018/combined_BIP-sighash-noinput.xml index 43f6d8d1b4..18a09d7afa 100644 --- a/static/bitcoin-dev/May_2018/combined_BIP-sighash-noinput.xml +++ b/static/bitcoin-dev/May_2018/combined_BIP-sighash-noinput.xml @@ -1,110 +1,147 @@ - + 2 Combined summary - BIP sighash_noinput - 2023-08-01T22:58:34.573011+00:00 - - Jonas Nick 2018-09-26 20:40:02+00:00 - - - Johnson Lau 2018-09-26 19:45:49+00:00 - - - Jonas Nick 2018-09-26 09:36:57+00:00 - - - Christian Decker 2018-07-13 11:07:48+00:00 - - - fred savage 2018-07-13 09:50:47+00:00 - - - Rusty Russell 2018-07-13 00:04:14+00:00 - - - ZmnSCPxj 2018-07-11 07:43:49+00:00 - - - Peter Todd 2018-07-09 09:41:39+00:00 - - - vv01f 2018-07-05 08:18:44+00:00 - - - fred savage 2018-07-04 18:08:43+00:00 - - - Gregory Maxwell 2018-07-03 23:45:22+00:00 - - - Luke Dashjr 2018-07-03 12:13:44+00:00 - - - Christian Decker 2018-07-03 12:05:09+00:00 - - - William Casarin 2018-07-03 11:54:37+00:00 - - - ZmnSCPxj 2018-07-03 06:58:36+00:00 - - - Peter Todd 2018-07-03 05:21:00+00:00 - - - Rusty Russell 2018-07-03 04:56:53+00:00 - - - Gregory Maxwell 2018-07-02 18:11:54+00:00 - - - Christian Decker 2018-05-15 14:28:22+00:00 - - - Anthony Towns 2018-05-14 09:23:29+00:00 - - - Christian Decker 2018-05-10 14:12:21+00:00 - - - Rusty Russell 2018-05-09 23:04:58+00:00 - - - Olaoluwa Osuntokun 2018-05-09 23:01:39+00:00 - - - Anthony Towns 2018-05-08 14:40:21+00:00 - - - Olaoluwa Osuntokun 2018-05-07 23:47:23+00:00 - - - Bram Cohen 2018-05-07 20:51:11+00:00 - - - Christian Decker 2018-05-07 19:40:46+00:00 - - - ZmnSCPxj 2018-05-04 14:25:46+00:00 - - - Christian Decker 2018-05-04 11:09:09+00:00 - - - ZmnSCPxj 2018-05-04 09:15:41+00:00 - - - Christian Decker 2018-05-01 17:32:32+00:00 - - - Russell O'Connor 2018-05-01 16:58:37+00:00 - - - Dario Sneidermanis 2018-04-30 18:25:42+00:00 - - - Christian Decker 2018-04-30 16:29:53+00:00 - + 2025-09-26T15:37:43.025903+00:00 + python-feedgen + + + [bitcoin-dev] BIP sighash_noinput Christian Decker + 2018-04-30T16:29:00.000Z + + + Dario Sneidermanis + 2018-04-30T18:25:00.000Z + + + Russell O'Connor + 2018-05-01T16:58:00.000Z + + + Christian Decker + 2018-05-01T17:32:00.000Z + + + ZmnSCPxj + 2018-05-04T09:15:00.000Z + + + Christian Decker + 2018-05-04T11:09:00.000Z + + + ZmnSCPxj + 2018-05-04T14:25:00.000Z + + + Christian Decker + 2018-05-07T19:40:00.000Z + + + Bram Cohen + 2018-05-07T20:51:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2018-05-07T23:47:00.000Z + + + [bitcoin-dev] " Anthony Towns + 2018-05-08T14:40:00.000Z + + + Olaoluwa Osuntokun + 2018-05-09T23:01:00.000Z + + + Rusty Russell + 2018-05-09T23:04:00.000Z + + + Christian Decker + 2018-05-10T14:12:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2018-05-14T09:23:00.000Z + + + Christian Decker + 2018-05-15T14:28:00.000Z + + + Gregory Maxwell + 2018-07-02T18:11:00.000Z + + + Rusty Russell + 2018-07-03T04:56:00.000Z + + + Peter Todd + 2018-07-03T05:21:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2018-07-03T06:58:00.000Z + + + William Casarin + 2018-07-03T11:54:00.000Z + + + Christian Decker + 2018-07-03T12:05:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Luke Dashjr + 2018-07-03T12:13:00.000Z + + + Gregory Maxwell + 2018-07-03T23:45:00.000Z + + + fred savage + 2018-07-04T18:08:00.000Z + + + vv01f + 2018-07-05T08:18:00.000Z + + + Peter Todd + 2018-07-09T09:41:00.000Z + + + ZmnSCPxj + 2018-07-11T07:43:00.000Z + + + Rusty Russell + 2018-07-13T00:04:00.000Z + + + fred savage + 2018-07-13T09:50:00.000Z + + + Christian Decker + 2018-07-13T11:07:00.000Z + + + Jonas Nick + 2018-09-26T09:36:00.000Z + + + Johnson Lau + 2018-09-26T19:45:00.000Z + + + Jonas Nick + 2018-09-26T20:40:00.000Z + + @@ -139,13 +176,13 @@ - python-feedgen + 2 Combined summary - BIP sighash_noinput - 2023-08-01T22:58:34.573011+00:00 + 2025-09-26T15:37:43.029284+00:00 - The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions. Laolu emphasizes the importance of making the proposal small 2018-09-26T20:40:02+00:00 + The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions. Laolu emphasizes the importance of making the proposal small - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_BIP-suggestion-PoW-proportional-to-block-transaction-sum.xml b/static/bitcoin-dev/May_2018/combined_BIP-suggestion-PoW-proportional-to-block-transaction-sum.xml index 87a3a3a0b6..1c6b0fc3bf 100644 --- a/static/bitcoin-dev/May_2018/combined_BIP-suggestion-PoW-proportional-to-block-transaction-sum.xml +++ b/static/bitcoin-dev/May_2018/combined_BIP-suggestion-PoW-proportional-to-block-transaction-sum.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - BIP suggestion: PoW proportional to block transaction sum - 2023-08-01T23:20:26.341262+00:00 - - Darren Weber 2018-06-06 21:01:22+00:00 - - - Thomas Guyot-Sionnest 2018-06-05 10:50:35+00:00 - - - Darren Weber 2018-05-30 16:17:29+00:00 - + 2025-09-26T15:37:49.354212+00:00 + python-feedgen + + + [bitcoin-dev] BIP suggestion: PoW proportional to block transaction sum Darren Weber + 2018-05-30T16:17:00.000Z + + + Thomas Guyot-Sionnest + 2018-06-05T10:50:00.000Z + + + Darren Weber + 2018-06-06T21:01:00.000Z + + - python-feedgen + 2 Combined summary - BIP suggestion: PoW proportional to block transaction sum - 2023-08-01T23:20:26.341262+00:00 + 2025-09-26T15:37:49.354744+00:00 - Darren Weber, a Bitcoin developer, has proposed a new idea on the Bitcoin Github page to enhance security against double-spending attacks. The proposal suggests introducing a hash workload that is proportional to the sum of transactions in a block. The aim is to make it more challenging for malicious attackers to double-spend large amounts by utilizing a relatively brief majority of the network hashing power.However, Thomas Guyot-Sionnest raises concerns about the implementation of this idea. He points out that users may resort to keeping large amounts in multiple smaller addresses to avoid penalties on small transactions. This could lead to an increase in Unspent Transaction Output (UTXO) size for everyone. Moreover, the proposal would require strong consensus and a hard fork, which might not be deemed worthwhile by some.Darren Weber acknowledges that he does not possess sufficient authority to answer implementation-related questions at this stage. However, he intends to carefully consider the points raised by Guyot-Sionnest before proceeding further with the idea.The proposal on Github has generated discussions regarding its potential benefits and drawbacks. Some believe that introducing a hash workload proportional to transaction sums could enhance security against double-spending attacks. Others express concerns about excluding transactions based on their economic value and the possible negative consequences, such as increased UTXO size for all users. Furthermore, implementing the proposal would necessitate good consensus and a hard fork, leading to differing opinions on whether it is worth pursuing.In conclusion, Darren's suggestion to introduce a hash workload proportional to the sum of transactions in a block aims to strengthen security against double-spending attacks. However, there are various considerations and challenges, including potential side-effects and the requirement for consensus and a hard fork. The proposal has sparked debates within the Bitcoin community, with proponents highlighting its potential benefits and others expressing reservations about its feasibility and impact. Darren plans to explore the idea further, taking into account the concerns raised by Thomas Guyot-Sionnest. 2018-06-06T21:01:22+00:00 + Darren Weber, a Bitcoin developer, has proposed a new idea on the Bitcoin Github page to enhance security against double-spending attacks. The proposal suggests introducing a hash workload that is proportional to the sum of transactions in a block. The aim is to make it more challenging for malicious attackers to double-spend large amounts by utilizing a relatively brief majority of the network hashing power.However, Thomas Guyot-Sionnest raises concerns about the implementation of this idea. He points out that users may resort to keeping large amounts in multiple smaller addresses to avoid penalties on small transactions. This could lead to an increase in Unspent Transaction Output (UTXO) size for everyone. Moreover, the proposal would require strong consensus and a hard fork, which might not be deemed worthwhile by some.Darren Weber acknowledges that he does not possess sufficient authority to answer implementation-related questions at this stage. However, he intends to carefully consider the points raised by Guyot-Sionnest before proceeding further with the idea.The proposal on Github has generated discussions regarding its potential benefits and drawbacks. Some believe that introducing a hash workload proportional to transaction sums could enhance security against double-spending attacks. Others express concerns about excluding transactions based on their economic value and the possible negative consequences, such as increased UTXO size for all users. Furthermore, implementing the proposal would necessitate good consensus and a hard fork, leading to differing opinions on whether it is worth pursuing.In conclusion, Darren's suggestion to introduce a hash workload proportional to the sum of transactions in a block aims to strengthen security against double-spending attacks. However, there are various considerations and challenges, including potential side-effects and the requirement for consensus and a hard fork. The proposal has sparked debates within the Bitcoin community, with proponents highlighting its potential benefits and others expressing reservations about its feasibility and impact. Darren plans to explore the idea further, taking into account the concerns raised by Thomas Guyot-Sionnest. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_Disallow-insecure-use-of-SIGHASH-SINGLE.xml b/static/bitcoin-dev/May_2018/combined_Disallow-insecure-use-of-SIGHASH-SINGLE.xml index 18f7380da2..4520e8c331 100644 --- a/static/bitcoin-dev/May_2018/combined_Disallow-insecure-use-of-SIGHASH-SINGLE.xml +++ b/static/bitcoin-dev/May_2018/combined_Disallow-insecure-use-of-SIGHASH-SINGLE.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Disallow insecure use of SIGHASH_SINGLE - 2023-08-01T23:25:38.378361+00:00 - - Peter Todd 2018-06-06 00:49:01+00:00 - - - Peter Todd 2018-06-06 00:43:26+00:00 - - - Chris Stewart 2018-06-06 00:17:52+00:00 - - - Johnson Lau 2018-05-31 18:53:01+00:00 - + 2025-09-26T15:37:40.910952+00:00 + python-feedgen + + + [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE Johnson Lau + 2018-05-31T18:53:00.000Z + + + Chris Stewart + 2018-06-06T00:17:00.000Z + + + Peter Todd + 2018-06-06T00:43:00.000Z + + + Peter Todd + 2018-06-06T00:49:00.000Z + + - python-feedgen + 2 Combined summary - Disallow insecure use of SIGHASH_SINGLE - 2023-08-01T23:25:38.378361+00:00 + 2025-09-26T15:37:40.911722+00:00 - A proposal has been made to change the Bitcoin core code in order to disallow the usage of SIGHASH_SINGLE without matched output. This signature form is considered insecure as it commits to no output, which may mislead users into thinking that it commits to one. The issue becomes more problematic in non-segwit scripts, making it easier for any UTXO of the same key to be stolen. The developer suggests implementing a softfork to disable this unintended consensus behavior, as these signatures are inherently unsafe.However, another developer questions the need for a softfork on security grounds and proposes that it may be better to consider soft-forking the code out based on code complexity instead. Additionally, there is uncertainty about whether the non-standardness of the signature means it is secure.In a discussion on the bitcoin-dev mailing list, the possibility of expanding to SIGHASH_NONE is raised. It is noted that SIGHASH_NONE is important because it allows multisig signers to relinquish the need to sign without giving up the private key. The SIGHASH_SINGLE bug can also be used in similar ways.The proposed policy aims to prevent the usage of SIGHASH_SINGLE without matched output. This signature form is considered insecure as it commits to no output, leading to potential theft of any UTXO of the same key in non-segwit scripts. This unintended consensus behavior is among the earliest ones and is inherently unsafe. To disable this feature with a softfork, the first step is to make these signatures non-standard. A pull request has already been made to add this policy to Bitcoin's Github repository. Currently, these signatures are allowed, so making them non-standard is the initial step towards disabling them. 2018-06-06T00:49:01+00:00 + A proposal has been made to change the Bitcoin core code in order to disallow the usage of SIGHASH_SINGLE without matched output. This signature form is considered insecure as it commits to no output, which may mislead users into thinking that it commits to one. The issue becomes more problematic in non-segwit scripts, making it easier for any UTXO of the same key to be stolen. The developer suggests implementing a softfork to disable this unintended consensus behavior, as these signatures are inherently unsafe.However, another developer questions the need for a softfork on security grounds and proposes that it may be better to consider soft-forking the code out based on code complexity instead. Additionally, there is uncertainty about whether the non-standardness of the signature means it is secure.In a discussion on the bitcoin-dev mailing list, the possibility of expanding to SIGHASH_NONE is raised. It is noted that SIGHASH_NONE is important because it allows multisig signers to relinquish the need to sign without giving up the private key. The SIGHASH_SINGLE bug can also be used in similar ways.The proposed policy aims to prevent the usage of SIGHASH_SINGLE without matched output. This signature form is considered insecure as it commits to no output, leading to potential theft of any UTXO of the same key in non-segwit scripts. This unintended consensus behavior is among the earliest ones and is inherently unsafe. To disable this feature with a softfork, the first step is to make these signatures non-standard. A pull request has already been made to add this policy to Bitcoin's Github repository. Currently, these signatures are allowed, so making them non-standard is the initial step towards disabling them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_Idea-More-decimal-places-for-lower-minimum-fee.xml b/static/bitcoin-dev/May_2018/combined_Idea-More-decimal-places-for-lower-minimum-fee.xml index de67f4d564..a6b3173591 100644 --- a/static/bitcoin-dev/May_2018/combined_Idea-More-decimal-places-for-lower-minimum-fee.xml +++ b/static/bitcoin-dev/May_2018/combined_Idea-More-decimal-places-for-lower-minimum-fee.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Idea: More decimal places for lower minimum fee - 2023-08-01T23:07:06.634580+00:00 - - Alex Morcos 2018-05-10 13:05:27+00:00 - - - st-bind at posteo.de 2018-05-10 08:10:51+00:00 - + 2025-09-26T15:38:12.478283+00:00 + python-feedgen + + + [bitcoin-dev] Idea: More decimal places for lower minimum fee st-bind + 2018-05-10T08:10:00.000Z + + + Alex Morcos + 2018-05-10T13:05:00.000Z + + - python-feedgen + 2 Combined summary - Idea: More decimal places for lower minimum fee - 2023-08-01T23:07:06.634580+00:00 + 2025-09-26T15:38:12.478742+00:00 - In Bitcoin Core, fee rates are measured in satoshis/kB. The current minimum fee is set at 1 satoshi per byte, which corresponds to approximately 0.09 USD per kB. However, this fee is now considered significant and may hinder everyday payments without spamming the mempool with free transactions. To address this issue, a proposal has been made to introduce more decimal places and set the minimum fee at 1 of the new smallest unit. By implementing this change, it would be possible to make affordable everyday payments while also preventing mempool spam. It should be noted that for this change to have a significant impact, it would require the rest of the network and miners to adapt as well. 2018-05-10T13:05:27+00:00 + In Bitcoin Core, fee rates are measured in satoshis/kB. The current minimum fee is set at 1 satoshi per byte, which corresponds to approximately 0.09 USD per kB. However, this fee is now considered significant and may hinder everyday payments without spamming the mempool with free transactions. To address this issue, a proposal has been made to introduce more decimal places and set the minimum fee at 1 of the new smallest unit. By implementing this change, it would be possible to make affordable everyday payments while also preventing mempool spam. It should be noted that for this change to have a significant impact, it would require the rest of the network and miners to adapt as well. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_MAST-Schnorr-related-soft-forks.xml b/static/bitcoin-dev/May_2018/combined_MAST-Schnorr-related-soft-forks.xml index 6a9376193d..fbd4fd5659 100644 --- a/static/bitcoin-dev/May_2018/combined_MAST-Schnorr-related-soft-forks.xml +++ b/static/bitcoin-dev/May_2018/combined_MAST-Schnorr-related-soft-forks.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - MAST/Schnorr related soft-forks - 2023-08-01T23:07:41.006702+00:00 - - Chris Belcher 2018-05-10 22:44:36+00:00 - - - Bram Cohen 2018-05-10 20:11:04+00:00 - - - Russell O'Connor 2018-05-10 14:23:09+00:00 - - - Anthony Towns 2018-05-10 12:10:27+00:00 - + 2025-09-26T15:38:04.112638+00:00 + python-feedgen + + + [bitcoin-dev] MAST/Schnorr related soft-forks Anthony Towns + 2018-05-10T12:10:00.000Z + + + Russell O'Connor + 2018-05-10T14:23:00.000Z + + + Bram Cohen + 2018-05-10T20:11:00.000Z + + + Chris Belcher + 2018-05-10T22:44:00.000Z + + - python-feedgen + 2 Combined summary - MAST/Schnorr related soft-forks - 2023-08-01T23:07:41.006702+00:00 + 2025-09-26T15:38:04.113257+00:00 - The Bitcoin Core Devs are engaged in discussions regarding the post-Schnorr signing process, which aims to enhance fungibility by making different features indistinguishable. This would render tracking and data mining useless, but it necessitates the development, review, testing, and deployment of all features together rather than individually. The ideas surrounding post-Schnorr signing can be categorized into Schnorr CHECKSIG, Merkelized Abstract Syntax Trees (MAST), Taproot, Graftroot, Interactive Signature Aggregation, Non-interactive Half-Signature Aggregation within Transaction, New SIGHASH modes, p2pk versus p2pkh, Other new Opcodes, Hard-fork Automatic Upgrade of p2pkh to be Spendable via Segwit, and the debate on whether addresses should be hashes or scripts.Most of these improvements require new segwit versions, with MAST being potentially evaluated independently in segwit v0. However, other enhancements such as Schnorr p2pk(h) addresses and taproot+mast addresses would need a soft-fork for segwit v1. Further upgrades including graftroot, interactive signature aggregation, and non-interactive sig aggregation would be introduced in later segwit versions.During discussions, there were concerns raised about graftroot and the possibility of delaying its implementation until non-interactive sig aggregation becomes feasible. It was suggested that (e) and (f) should be separated if non-interactive sig aggregation is not possible. The overall goal of the post-Schnorr signing process is to improve fungibility, but the approach of developing all features together could potentially delay certain improvements. Interested individuals can subscribe to the bitcoin-dev mailing list for more information on these discussions.In another discussion on the Bitcoin developer mailing list, Anthony Towns proposed a soft-fork to enable Schnorr signatures and CHECKSIGFROMSTACK. This proposal has various benefits, such as payment decorrelation for lightning and improved multi-signature schemes. While it could be implemented with a single new script type, significant work would still be required for its rollout. Other potential changes discussed include MAST, Taproot, Graftroot, Interactive Signature Aggregation, and New SIGHASH modes. These changes would require new segwit versions, except for MAST, which could be evaluated independently.The proposed soft-fork timeline suggests starting with implementing MAST in segwit v0, followed by Schnorr p2pk(h) addresses and taproot+mast addresses in segwit v1. Further upgrades including graftroot in segwit v2, interactive signature aggregation in segwit v2, and non-interactive sig aggregation in segwit v3 would be introduced later.During the discussion, the possibility of implementing signature aggregation as a variation of segwit v1 was explored. However, concerns were raised about the time it might take and the urgency for graftroot. It was suggested that delaying implementation until non-interactive sig aggregation becomes possible would be a better option. Some participants expressed concerns about the feasibility of non-interactive sig aggregation, leading to the suggestion of separating (e) and (f). There was also a preference for doing them as a single upgrade.Overall, the discussions revolved around proposed changes to Bitcoin's segwit protocol and the optimal approach to implementing them. Those interested can refer to the post documenting the discussion for further details. Anthony Towns compiled a list of ideas for signing post-Schnorr, which includes Schnorr CHECKSIG, MAST, Taproot, Graftroot, Interactive Signature Aggregation, Non-interactive half-signature aggregation within transaction, New SIGHASH modes, p2pk versus p2pkh, Other new opcodes, Hard-fork automatic upgrade of p2pkh to be spendable via segwit, and Should addresses be hashes or scripts? Each idea is accompanied by its benefits, requirements, approaches, drawbacks, and rationale. Some ideas require a new segwit version, while others can be implemented independently.The proposed soft-fork timeline suggests implementing MAST in segwit v0 if there is sufficient support, followed by Schnorr p2pk(h) addresses and taproot+mast addresses in segwit v1. Further upgrades including graftroot in segwit v2, interactive signature aggregation in segwit v2, and non-interactive sig aggregation in segwit v3 would be introduced later.Bitcoin developers are exploring several upgrades to the cryptocurrency system. One proposal involves introducing a soft fork for Merkelized Abstract Syntax Trees (MAST) in SegWit v0, which offers logarithmic scaling for scripts with multiple alternative paths. Another proposal includes introducing a new SIGHASH mode and deciding between pubkeyhash or just pubkey for addresses. Schnorr p2pk(h) addresses and taproot+mast addresses could be introduced in SegWit v1, combining pay-to-pubkey and pay-to-script in a single address. Graftroot, which allows delegation of authorization to spend an output on the blockchain, 2018-05-10T22:44:36+00:00 + The Bitcoin Core Devs are engaged in discussions regarding the post-Schnorr signing process, which aims to enhance fungibility by making different features indistinguishable. This would render tracking and data mining useless, but it necessitates the development, review, testing, and deployment of all features together rather than individually. The ideas surrounding post-Schnorr signing can be categorized into Schnorr CHECKSIG, Merkelized Abstract Syntax Trees (MAST), Taproot, Graftroot, Interactive Signature Aggregation, Non-interactive Half-Signature Aggregation within Transaction, New SIGHASH modes, p2pk versus p2pkh, Other new Opcodes, Hard-fork Automatic Upgrade of p2pkh to be Spendable via Segwit, and the debate on whether addresses should be hashes or scripts.Most of these improvements require new segwit versions, with MAST being potentially evaluated independently in segwit v0. However, other enhancements such as Schnorr p2pk(h) addresses and taproot+mast addresses would need a soft-fork for segwit v1. Further upgrades including graftroot, interactive signature aggregation, and non-interactive sig aggregation would be introduced in later segwit versions.During discussions, there were concerns raised about graftroot and the possibility of delaying its implementation until non-interactive sig aggregation becomes feasible. It was suggested that (e) and (f) should be separated if non-interactive sig aggregation is not possible. The overall goal of the post-Schnorr signing process is to improve fungibility, but the approach of developing all features together could potentially delay certain improvements. Interested individuals can subscribe to the bitcoin-dev mailing list for more information on these discussions.In another discussion on the Bitcoin developer mailing list, Anthony Towns proposed a soft-fork to enable Schnorr signatures and CHECKSIGFROMSTACK. This proposal has various benefits, such as payment decorrelation for lightning and improved multi-signature schemes. While it could be implemented with a single new script type, significant work would still be required for its rollout. Other potential changes discussed include MAST, Taproot, Graftroot, Interactive Signature Aggregation, and New SIGHASH modes. These changes would require new segwit versions, except for MAST, which could be evaluated independently.The proposed soft-fork timeline suggests starting with implementing MAST in segwit v0, followed by Schnorr p2pk(h) addresses and taproot+mast addresses in segwit v1. Further upgrades including graftroot in segwit v2, interactive signature aggregation in segwit v2, and non-interactive sig aggregation in segwit v3 would be introduced later.During the discussion, the possibility of implementing signature aggregation as a variation of segwit v1 was explored. However, concerns were raised about the time it might take and the urgency for graftroot. It was suggested that delaying implementation until non-interactive sig aggregation becomes possible would be a better option. Some participants expressed concerns about the feasibility of non-interactive sig aggregation, leading to the suggestion of separating (e) and (f). There was also a preference for doing them as a single upgrade.Overall, the discussions revolved around proposed changes to Bitcoin's segwit protocol and the optimal approach to implementing them. Those interested can refer to the post documenting the discussion for further details. Anthony Towns compiled a list of ideas for signing post-Schnorr, which includes Schnorr CHECKSIG, MAST, Taproot, Graftroot, Interactive Signature Aggregation, Non-interactive half-signature aggregation within transaction, New SIGHASH modes, p2pk versus p2pkh, Other new opcodes, Hard-fork automatic upgrade of p2pkh to be spendable via segwit, and Should addresses be hashes or scripts? Each idea is accompanied by its benefits, requirements, approaches, drawbacks, and rationale. Some ideas require a new segwit version, while others can be implemented independently.The proposed soft-fork timeline suggests implementing MAST in segwit v0 if there is sufficient support, followed by Schnorr p2pk(h) addresses and taproot+mast addresses in segwit v1. Further upgrades including graftroot in segwit v2, interactive signature aggregation in segwit v2, and non-interactive sig aggregation in segwit v3 would be introduced later.Bitcoin developers are exploring several upgrades to the cryptocurrency system. One proposal involves introducing a soft fork for Merkelized Abstract Syntax Trees (MAST) in SegWit v0, which offers logarithmic scaling for scripts with multiple alternative paths. Another proposal includes introducing a new SIGHASH mode and deciding between pubkeyhash or just pubkey for addresses. Schnorr p2pk(h) addresses and taproot+mast addresses could be introduced in SegWit v1, combining pay-to-pubkey and pay-to-script in a single address. Graftroot, which allows delegation of authorization to spend an output on the blockchain, - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_Making-OP-TRUE-standard-.xml b/static/bitcoin-dev/May_2018/combined_Making-OP-TRUE-standard-.xml index 5a46aab8c1..49332a080d 100644 --- a/static/bitcoin-dev/May_2018/combined_Making-OP-TRUE-standard-.xml +++ b/static/bitcoin-dev/May_2018/combined_Making-OP-TRUE-standard-.xml @@ -1,86 +1,115 @@ - + 2 Combined summary - Making OP_TRUE standard? - 2023-08-01T23:06:11.832043+00:00 - - Rusty Russell 2018-05-31 02:47:58+00:00 - - - Rusty Russell 2018-05-30 02:47:20+00:00 - - - Russell O'Connor 2018-05-21 14:20:39+00:00 - - - Peter Todd 2018-05-21 03:56:58+00:00 - - - Rusty Russell 2018-05-21 03:44:06+00:00 - - - Jim Posen 2018-05-17 20:06:26+00:00 - - - Christian Decker 2018-05-17 17:35:53+00:00 - - - ZmnSCPxj 2018-05-17 10:28:54+00:00 - - - Rusty Russell 2018-05-17 02:44:53+00:00 - - - ZmnSCPxj 2018-05-15 01:22:26+00:00 - - - ZmnSCPxj 2018-05-11 02:44:13+00:00 - - - Luke Dashjr 2018-05-10 09:43:28+00:00 - - - Jorge Timón 2018-05-10 09:33:30+00:00 - - - Jorge Timón 2018-05-10 09:33:29+00:00 - - - ZmnSCPxj 2018-05-10 03:07:49+00:00 - - - Luke Dashjr 2018-05-10 02:27:41+00:00 - - - Rusty Russell 2018-05-10 02:08:43+00:00 - - - Rusty Russell 2018-05-10 02:06:41+00:00 - - - Olaoluwa Osuntokun 2018-05-09 22:06:03+00:00 - - - Peter Todd 2018-05-09 20:59:14+00:00 - - - Johnson Lau 2018-05-09 20:19:31+00:00 - - - Peter Todd 2018-05-09 19:27:33+00:00 - - - Johnson Lau 2018-05-09 17:56:46+00:00 - - - ZmnSCPxj 2018-05-09 03:02:37+00:00 - - - Olaoluwa Osuntokun 2018-05-09 00:24:59+00:00 - - - Rusty Russell 2018-05-08 23:57:11+00:00 - + 2025-09-26T15:38:16.680100+00:00 + python-feedgen + + + [bitcoin-dev] Making OP_TRUE standard? Rusty Russell + 2018-05-08T23:57:00.000Z + + + Olaoluwa Osuntokun + 2018-05-09T00:24:00.000Z + + + ZmnSCPxj + 2018-05-09T03:02:00.000Z + + + Johnson Lau + 2018-05-09T17:56:00.000Z + + + Peter Todd + 2018-05-09T19:27:00.000Z + + + Johnson Lau + 2018-05-09T20:19:00.000Z + + + Peter Todd + 2018-05-09T20:59:00.000Z + + + Olaoluwa Osuntokun + 2018-05-09T22:06:00.000Z + + + Rusty Russell + 2018-05-10T02:06:00.000Z + + + Rusty Russell + 2018-05-10T02:08:00.000Z + + + Luke Dashjr + 2018-05-10T02:27:00.000Z + + + ZmnSCPxj + 2018-05-10T03:07:00.000Z + + + Jorge Timón + 2018-05-10T09:33:00.000Z + + + Jorge Timón + 2018-05-10T09:33:00.000Z + + + Luke Dashjr + 2018-05-10T09:43:00.000Z + + + ZmnSCPxj + 2018-05-11T02:44:00.000Z + + + ZmnSCPxj + 2018-05-15T01:22:00.000Z + + + Rusty Russell + 2018-05-17T02:44:00.000Z + + + ZmnSCPxj + 2018-05-17T10:28:00.000Z + + + Christian Decker + 2018-05-17T17:35:00.000Z + + + Jim Posen + 2018-05-17T20:06:00.000Z + + + Rusty Russell + 2018-05-21T03:44:00.000Z + + + Peter Todd + 2018-05-21T03:56:00.000Z + + + Russell O'Connor + 2018-05-21T14:20:00.000Z + + + Rusty Russell + 2018-05-30T02:47:00.000Z + + + Rusty Russell + 2018-05-31T02:47:00.000Z + + @@ -107,13 +136,13 @@ - python-feedgen + 2 Combined summary - Making OP_TRUE standard? - 2023-08-01T23:06:11.832043+00:00 + 2025-09-26T15:38:16.683130+00:00 - Rusty Russell has suggested a potential denial-of-service (DoS) attack on Bitcoin that involves sending a 100,000 vbyte transaction at 1sat/vbyte, replacing it with a 108 vbyte transaction at 2sat/vbyte which spends one of those inputs. This attack can be performed only about 86 times per block given the time it takes for this to propagate to 50% of the network. The cost for this attack is 68576 satoshi, assuming a 50% chance the 100k transaction gets mined. However, the 50% chance assumption is almost wrong, making the cost for the transactions much lower at 18576, i.e., 463x lower than just sending 1sat/vbyte txs under optimal conditions.To address the DoS potential directly, Rusty Russell suggests implementing a solution that delays processing of transactions by 30-60 seconds if a replacement doesn't meet certain criteria but increases the feerate by at least minrelayfee. This would eventually result in replacing-by-fee (RBF) of a larger transaction but it would take longer. It should be easy to implement as similar timers will be required for dandelion. Christian provided more detailed propagation statistics showing that larger transactions propagate slower, but only by a factor of 2.5 or so.There have been discussions on the Bitcoin development mailing list regarding the enforcement of Replace-By-Fee (RBF) on spending transactions using OP_CSV with a relative locktime of zero. Marco Falke points out that if the parent is RBF, the child inherits it. However, Matt Corallo points out that you can block RBF with a large-but-lowball tx. Peter Todd explains that the rule preventing bandwidth usage DoS attacks on the mempool is why the rule exists, and dropping it would allow attackers to repeatedly broadcast and replace transactions to use up tx relay bandwidth for significantly lower cost than otherwise.Luke Dashjr suggests having a consensus rule that a bit must be set for an expected behavior and the bit may only be set when the last output is exactly 00000000000000000181. Rusty Russell believes the best mitigation against UTXO bloat is to make the fees as low as possible, put a CSV delay on the to-remote output, and attach more value to the OP_TRUE output. However, it turns out they probably don't want an OP_TRUE output nor P2SH, because then the spending tx would be malleable. So P2WSH is preferred. Russell suggests that the network benefits from using OP_TRUE outweighs the risk, but it would be nice if OP_TRUE P2WSH spends were always considered RBF.Luke and ZmnSCPxj discuss the possibility of having multiple dummy outputs in a transaction. They question if there is any legitimate reason for having multiple such outputs. However, they consider the use of `SIGHASH_SINGLE` flag, which may require adjustment of transaction inputs if a dummy output is added as the first output. Despite this, it is noted that the discussion is focused on transaction serialization, and it is unclear whether `SIGHASH_SINGLE` is affected by the presence of dummy outputs.ZmnSCPxj clarifies that the template-script idea for Lightning does not make it mandatory to spend in the same block, but rather the UTXO would cease to be valid after that block. Luke and the rest of the list thanked ZmnSCPxj for the clarification and stated that their previous rumination about having two options for Lightning was incorrect. For Lightning, they simply need to add a 0-value OP_TRUE output always to transactions that require both side signatures. This 0-value output will serve as a "hook" for adding more fees if needed.Rusty Russell proposes including a 546 satoshi OP_TRUE output in commitment transactions for the Lightning network to solve the problem of predicting future fees. This would allow for minimal fees and the use of CPFP.In a recent discussion on the Bitcoin-dev mailing list, Olaoluwa Osuntokun asked about the downsides of using p2wsh. The immediate implementation of this method seems to be more practical as compared to policy changes which can be quite fuzzy and would require a uniform rollout for the propagation of commitment transactions. Rusty expressed his expectation that the policy changes will eventually be implemented despite the challenges. He also mentioned his annoyance with people who work around issues without bringing them to his attention.Johnson Lau proposed creating a standard for "0 fee tx with exactly one OP_TRUE output" to ensure that CPFP would always be needed and the output wouldn't pollute the UTXO set. However, it was noted that this approach wouldn't propagate.Lau suggested using ANYONECANPAY to sign the transaction instead, allowing for more inputs to be added for fees without requiring any protocol changes. However, this was rejected due to the fact that it 2018-05-31T02:47:58+00:00 + Rusty Russell has suggested a potential denial-of-service (DoS) attack on Bitcoin that involves sending a 100,000 vbyte transaction at 1sat/vbyte, replacing it with a 108 vbyte transaction at 2sat/vbyte which spends one of those inputs. This attack can be performed only about 86 times per block given the time it takes for this to propagate to 50% of the network. The cost for this attack is 68576 satoshi, assuming a 50% chance the 100k transaction gets mined. However, the 50% chance assumption is almost wrong, making the cost for the transactions much lower at 18576, i.e., 463x lower than just sending 1sat/vbyte txs under optimal conditions.To address the DoS potential directly, Rusty Russell suggests implementing a solution that delays processing of transactions by 30-60 seconds if a replacement doesn't meet certain criteria but increases the feerate by at least minrelayfee. This would eventually result in replacing-by-fee (RBF) of a larger transaction but it would take longer. It should be easy to implement as similar timers will be required for dandelion. Christian provided more detailed propagation statistics showing that larger transactions propagate slower, but only by a factor of 2.5 or so.There have been discussions on the Bitcoin development mailing list regarding the enforcement of Replace-By-Fee (RBF) on spending transactions using OP_CSV with a relative locktime of zero. Marco Falke points out that if the parent is RBF, the child inherits it. However, Matt Corallo points out that you can block RBF with a large-but-lowball tx. Peter Todd explains that the rule preventing bandwidth usage DoS attacks on the mempool is why the rule exists, and dropping it would allow attackers to repeatedly broadcast and replace transactions to use up tx relay bandwidth for significantly lower cost than otherwise.Luke Dashjr suggests having a consensus rule that a bit must be set for an expected behavior and the bit may only be set when the last output is exactly 00000000000000000181. Rusty Russell believes the best mitigation against UTXO bloat is to make the fees as low as possible, put a CSV delay on the to-remote output, and attach more value to the OP_TRUE output. However, it turns out they probably don't want an OP_TRUE output nor P2SH, because then the spending tx would be malleable. So P2WSH is preferred. Russell suggests that the network benefits from using OP_TRUE outweighs the risk, but it would be nice if OP_TRUE P2WSH spends were always considered RBF.Luke and ZmnSCPxj discuss the possibility of having multiple dummy outputs in a transaction. They question if there is any legitimate reason for having multiple such outputs. However, they consider the use of `SIGHASH_SINGLE` flag, which may require adjustment of transaction inputs if a dummy output is added as the first output. Despite this, it is noted that the discussion is focused on transaction serialization, and it is unclear whether `SIGHASH_SINGLE` is affected by the presence of dummy outputs.ZmnSCPxj clarifies that the template-script idea for Lightning does not make it mandatory to spend in the same block, but rather the UTXO would cease to be valid after that block. Luke and the rest of the list thanked ZmnSCPxj for the clarification and stated that their previous rumination about having two options for Lightning was incorrect. For Lightning, they simply need to add a 0-value OP_TRUE output always to transactions that require both side signatures. This 0-value output will serve as a "hook" for adding more fees if needed.Rusty Russell proposes including a 546 satoshi OP_TRUE output in commitment transactions for the Lightning network to solve the problem of predicting future fees. This would allow for minimal fees and the use of CPFP.In a recent discussion on the Bitcoin-dev mailing list, Olaoluwa Osuntokun asked about the downsides of using p2wsh. The immediate implementation of this method seems to be more practical as compared to policy changes which can be quite fuzzy and would require a uniform rollout for the propagation of commitment transactions. Rusty expressed his expectation that the policy changes will eventually be implemented despite the challenges. He also mentioned his annoyance with people who work around issues without bringing them to his attention.Johnson Lau proposed creating a standard for "0 fee tx with exactly one OP_TRUE output" to ensure that CPFP would always be needed and the output wouldn't pollute the UTXO set. However, it was noted that this approach wouldn't propagate.Lau suggested using ANYONECANPAY to sign the transaction instead, allowing for more inputs to be added for fees without requiring any protocol changes. However, this was rejected due to the fact that it - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_Minimizing-the-redundancy-in-Golomb-Coded-Sets.xml b/static/bitcoin-dev/May_2018/combined_Minimizing-the-redundancy-in-Golomb-Coded-Sets.xml index b22c93c0de..3be3244080 100644 --- a/static/bitcoin-dev/May_2018/combined_Minimizing-the-redundancy-in-Golomb-Coded-Sets.xml +++ b/static/bitcoin-dev/May_2018/combined_Minimizing-the-redundancy-in-Golomb-Coded-Sets.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Minimizing the redundancy in Golomb Coded Sets - 2023-08-01T23:18:58.646865+00:00 - - Lucas Ontivero 2018-05-30 03:10:04+00:00 - - - Jim Posen 2018-05-29 22:38:01+00:00 - - - Gregory Maxwell 2018-05-25 21:13:55+00:00 - - - Gregory Maxwell 2018-05-25 18:42:41+00:00 - - - Pieter Wuille 2018-05-25 17:54:17+00:00 - + 2025-09-26T15:37:38.821639+00:00 + python-feedgen + + + [bitcoin-dev] Minimizing the redundancy in Golomb Coded Sets Pieter Wuille + 2018-05-25T17:54:00.000Z + + + Gregory Maxwell + 2018-05-25T18:42:00.000Z + + + Gregory Maxwell + 2018-05-25T21:13:00.000Z + + + Jim Posen + 2018-05-29T22:38:00.000Z + + + Lucas Ontivero + 2018-05-30T03:10:00.000Z + + - python-feedgen + 2 Combined summary - Minimizing the redundancy in Golomb Coded Sets - 2023-08-01T23:18:58.646865+00:00 + 2025-09-26T15:37:38.822299+00:00 - In a recent email exchange on the bitcoin-dev mailing list, Jim Posen shared his analysis of selecting a good P value to reduce total data downloaded using Golomb-Rice filters on mainnet. He determined that the optimal B parameter for different numbers of filter elements watched by the client ranges from 13 to 23. In particular, for C = 10, B = 13 is optimal; for C = 100, B = 16 is optimal; for C = 1,000, B = 20 is optimal; and for C = 10,000, B = 23 is optimal. Posen also attached some results and offered to share the CSV and raw notebook if people were interested.The author conducted an analysis on selecting a good P value to reduce total data downloaded considering both filters themselves and blocks in the case of false positive matches, using data from mainnet. The quantity it minimizes is based on the number of filter elements per block (N), Golomb-Rice coding parameter (B), and the number of filter elements watched by the client (C). The main result shows that for different values of C, the optimal value of B ranges from 13 to 23. Any value of B in the range 16 to 20 seems reasonable, with M=1.4971 * 2^B for optimal compression. The selection of the parameter depends on the target number of elements that a client may watch. Gregory Maxwell via bitcoin-dev corrected a previous statement regarding configuration and stated that M=784931 and rice parameter 19 should be used. The author also provided some results and offered to share the CSV and raw notebook if people are interested.In an email on May 25, 2018 at 6:42 PM, Gregory Maxwell wrote about a configuration error in which the values for M and the rice parameter were incorrect. According to Maxwell, if the configuration was correct, then M should have been equal to 784931 and the rice parameter B should have been 19. The mistake was due to a paste error, as Maxwell had initially provided the values M=1569861 and B=19.In a recent communication on Bitcoin-dev, Pieter Wuille proposed optimal parameter selection for the Golomb Coded Sets in BIP158. He suggested that if an FP rate of exactly 1 in 2^20 is required, then the Rice parameter should be 19 instead of 20. If not, then an FP rate of 1 in a 1.4971*2^B should be picked. Pieter's approximations were used to analyze what parameters minimize total communications for lite wallet scanning. The result showed that M=784931 resulted in a lower total data rate than M=1569861. When using all-scripts inputs and outputs (but no txids), it is estimated that roughly 7500 bits will be set. Therefore, M=1569861 and rice parameter 19 should be used to achieve the actual optimal FP rate for total data transferred. It is noted that different clients will have different monitoring requirements and thus, it makes sense to pick a parameter with optimal compression rather than optimal-data-transfer-for-a-specific-key-count.Pieter spent some time working on the optimal parameter selection for the Golomb Coded Sets proposed in BIP158. The details of the work can be found on his GitHub page. He found that if an FP rate of exactly 1 in 2^20 is desired, the Rice parameter should be 19 instead of 20. If a different FP rate is preferred, such as 1 in a 1.4971*2^B, then M=784931 B=19 or M=1569861 B=20 would be good choices. 2018-05-30T03:10:04+00:00 + In a recent email exchange on the bitcoin-dev mailing list, Jim Posen shared his analysis of selecting a good P value to reduce total data downloaded using Golomb-Rice filters on mainnet. He determined that the optimal B parameter for different numbers of filter elements watched by the client ranges from 13 to 23. In particular, for C = 10, B = 13 is optimal; for C = 100, B = 16 is optimal; for C = 1,000, B = 20 is optimal; and for C = 10,000, B = 23 is optimal. Posen also attached some results and offered to share the CSV and raw notebook if people were interested.The author conducted an analysis on selecting a good P value to reduce total data downloaded considering both filters themselves and blocks in the case of false positive matches, using data from mainnet. The quantity it minimizes is based on the number of filter elements per block (N), Golomb-Rice coding parameter (B), and the number of filter elements watched by the client (C). The main result shows that for different values of C, the optimal value of B ranges from 13 to 23. Any value of B in the range 16 to 20 seems reasonable, with M=1.4971 * 2^B for optimal compression. The selection of the parameter depends on the target number of elements that a client may watch. Gregory Maxwell via bitcoin-dev corrected a previous statement regarding configuration and stated that M=784931 and rice parameter 19 should be used. The author also provided some results and offered to share the CSV and raw notebook if people are interested.In an email on May 25, 2018 at 6:42 PM, Gregory Maxwell wrote about a configuration error in which the values for M and the rice parameter were incorrect. According to Maxwell, if the configuration was correct, then M should have been equal to 784931 and the rice parameter B should have been 19. The mistake was due to a paste error, as Maxwell had initially provided the values M=1569861 and B=19.In a recent communication on Bitcoin-dev, Pieter Wuille proposed optimal parameter selection for the Golomb Coded Sets in BIP158. He suggested that if an FP rate of exactly 1 in 2^20 is required, then the Rice parameter should be 19 instead of 20. If not, then an FP rate of 1 in a 1.4971*2^B should be picked. Pieter's approximations were used to analyze what parameters minimize total communications for lite wallet scanning. The result showed that M=784931 resulted in a lower total data rate than M=1569861. When using all-scripts inputs and outputs (but no txids), it is estimated that roughly 7500 bits will be set. Therefore, M=1569861 and rice parameter 19 should be used to achieve the actual optimal FP rate for total data transferred. It is noted that different clients will have different monitoring requirements and thus, it makes sense to pick a parameter with optimal compression rather than optimal-data-transfer-for-a-specific-key-count.Pieter spent some time working on the optimal parameter selection for the Golomb Coded Sets proposed in BIP158. The details of the work can be found on his GitHub page. He found that if an FP rate of exactly 1 in 2^20 is desired, the Rice parameter should be 19 instead of 20. If a different FP rate is preferred, such as 1 in a 1.4971*2^B, then M=784931 B=19 or M=1569861 B=20 would be good choices. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_Moving-away-from-BIP37-unsetting-NODE-BLOOM.xml b/static/bitcoin-dev/May_2018/combined_Moving-away-from-BIP37-unsetting-NODE-BLOOM.xml index d7aeb24ef9..9dadeec38b 100644 --- a/static/bitcoin-dev/May_2018/combined_Moving-away-from-BIP37-unsetting-NODE-BLOOM.xml +++ b/static/bitcoin-dev/May_2018/combined_Moving-away-from-BIP37-unsetting-NODE-BLOOM.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Moving away from BIP37, unsetting NODE_BLOOM - 2023-08-01T23:08:33.468260+00:00 - - Jonas Schnelli 2018-05-17 07:47:34+00:00 - - - Caius Cosades 2018-05-16 21:22:47+00:00 - + 2025-09-26T15:37:53.555535+00:00 + python-feedgen + + + [bitcoin-dev] Moving away from BIP37, unsetting NODE_BLOOM Caius Cosades + 2018-05-16T21:22:00.000Z + + + Jonas Schnelli + 2018-05-17T07:47:00.000Z + + - python-feedgen + 2 Combined summary - Moving away from BIP37, unsetting NODE_BLOOM - 2023-08-01T23:08:33.468260+00:00 + 2025-09-26T15:37:53.556037+00:00 - The Bitcoin network is currently facing issues with BIP37, a lightweight wallet that connects to nodes and requests an arbitrary bloom filter on their block files and mempool. Unfortunately, this system poses significant denial of service problems and places undue load on the network by default. Moreover, it fails to provide an acceptable level of security and reliability to lightweight wallets.In addition to these concerns, there are major privacy and load-distribution issues associated with BIP37. This raises the risk of breaking existing SPV (Simplified Payment Verification) client models and pushing users towards centralized validation solutions. Such a shift could potentially worsen privacy and security concerns even further.Recognizing these problems, Caius Cosades suggests that NODE_BLOOM services should be defaulted to zero in the next major release. Furthermore, any software relying on BIP37 should consider moving to alternative filtering options or utilizing another dedicated software to serve their requests. To fully address the issue, future releases of reference software should completely remove BIP37 commands.Developers are increasingly reaching a consensus on disabling BIP37 in network nodes due to the significant denial of service issues it presents. BIP37 allows lightweight wallets to connect to nodes and request the loading of an arbitrary bloom filter onto their block files and mempool. Unfortunately, this puts unnecessary strain on the network and fails to offer sufficient security and reliability to lightweight wallets.Moreover, BIP37 was intended to provide stronger privacy than it actually does. Any node capable of capturing `filterload` and `filteradd` responses can easily de-anonymize an entire wallet, regardless of the amount of noise added to the filters. While this can be countered by having multiple peers simultaneously return filter results, it compromises privacy and increases network load.To support the argument against BIP37, several links to mailing lists, GitHub issues, and research papers have been provided. These resources highlight the concerns surrounding BIP37 and further reinforce the need for its removal from future releases of reference software.Overall, there is a growing consensus among developers to disable BIP37 in network nodes due to significant denial of service issues and its inadequate security and reliability for lightweight wallets. Moving forward, it is recommended that alternative filtering options or dedicated software be utilized instead, and that future releases of reference software no longer include BIP37 commands. 2018-05-17T07:47:34+00:00 + The Bitcoin network is currently facing issues with BIP37, a lightweight wallet that connects to nodes and requests an arbitrary bloom filter on their block files and mempool. Unfortunately, this system poses significant denial of service problems and places undue load on the network by default. Moreover, it fails to provide an acceptable level of security and reliability to lightweight wallets.In addition to these concerns, there are major privacy and load-distribution issues associated with BIP37. This raises the risk of breaking existing SPV (Simplified Payment Verification) client models and pushing users towards centralized validation solutions. Such a shift could potentially worsen privacy and security concerns even further.Recognizing these problems, Caius Cosades suggests that NODE_BLOOM services should be defaulted to zero in the next major release. Furthermore, any software relying on BIP37 should consider moving to alternative filtering options or utilizing another dedicated software to serve their requests. To fully address the issue, future releases of reference software should completely remove BIP37 commands.Developers are increasingly reaching a consensus on disabling BIP37 in network nodes due to the significant denial of service issues it presents. BIP37 allows lightweight wallets to connect to nodes and request the loading of an arbitrary bloom filter onto their block files and mempool. Unfortunately, this puts unnecessary strain on the network and fails to offer sufficient security and reliability to lightweight wallets.Moreover, BIP37 was intended to provide stronger privacy than it actually does. Any node capable of capturing `filterload` and `filteradd` responses can easily de-anonymize an entire wallet, regardless of the amount of noise added to the filters. While this can be countered by having multiple peers simultaneously return filter results, it compromises privacy and increases network load.To support the argument against BIP37, several links to mailing lists, GitHub issues, and research papers have been provided. These resources highlight the concerns surrounding BIP37 and further reinforce the need for its removal from future releases of reference software.Overall, there is a growing consensus among developers to disable BIP37 in network nodes due to significant denial of service issues and its inadequate security and reliability for lightweight wallets. Moving forward, it is recommended that alternative filtering options or dedicated software be utilized instead, and that future releases of reference software no longer include BIP37 commands. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_Multi-signature-and-multi-coin-HD-wallet-in-one-BIP32-derivation-path-new-BIP-.xml b/static/bitcoin-dev/May_2018/combined_Multi-signature-and-multi-coin-HD-wallet-in-one-BIP32-derivation-path-new-BIP-.xml index 299b43aea4..4a4c826e91 100644 --- a/static/bitcoin-dev/May_2018/combined_Multi-signature-and-multi-coin-HD-wallet-in-one-BIP32-derivation-path-new-BIP-.xml +++ b/static/bitcoin-dev/May_2018/combined_Multi-signature-and-multi-coin-HD-wallet-in-one-BIP32-derivation-path-new-BIP-.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP) - 2023-08-01T22:53:40.079698+00:00 - - Paul Brown 2018-05-04 08:23:21+00:00 - - - Clark Moody 2018-05-04 00:09:38+00:00 - - - Paul Brown 2018-04-26 14:05:06+00:00 - - - Paul Brown 2018-04-25 16:44:55+00:00 - - - Clark Moody 2018-04-25 14:35:57+00:00 - - - Paul Brown 2018-04-25 09:35:03+00:00 - + 2025-09-26T15:37:59.857072+00:00 + python-feedgen + + + [bitcoin-dev] Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP) Paul Brown + 2018-04-25T09:35:00.000Z + + + Clark Moody + 2018-04-25T14:35:00.000Z + + + Paul Brown + 2018-04-25T16:44:00.000Z + + + Paul Brown + 2018-04-26T14:05:00.000Z + + + Clark Moody + 2018-05-04T00:09:00.000Z + + + Paul Brown + 2018-05-04T08:23:00.000Z + + - python-feedgen + 2 Combined summary - Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP) - 2023-08-01T22:53:40.079698+00:00 + 2025-09-26T15:37:59.857918+00:00 - In a discussion on the Bitcoin Development mailing list, Paul Brown proposed a new BIP32 derivation path that supports a single or multi-signature and multi-coin wallet from a single master seed. The proposal combines BIP44 and BIP45, addressing issues with BIP44's lack of clarity in terms of address format, representation of single-sig or multi-sig wallets, number of cosigners, and collision prevention on the same address index. Brown suggests using bech32 serialized addresses and extending the derivation path below coin type to represent the address format. He proposes creating a separate specification similar to SLIP-0044 to define the list of address formats and derivation path values, allowing for future address formats to be easily supported. Clark Moody suggests using the xpub serialization format described in SLIP-0032 as an alternative solution, which includes the derivation path within the xpub itself and uses Bech32 for encoding. Moody argues that this solves the bootstrapping problem and avoids the requirement for users to know the specific BIP number. Brown responds by acknowledging that his initial encoding was incorrect and suggests further extending the derivation path based on the coin type value. He believes a separate spec can be created to support different address formats without requiring new BIPs. The proposal includes several links to other related Bitcoin Improvement Proposals and discussions on addressing collisions and separating cosigners in the derivation path. 2018-05-04T08:23:21+00:00 + In a discussion on the Bitcoin Development mailing list, Paul Brown proposed a new BIP32 derivation path that supports a single or multi-signature and multi-coin wallet from a single master seed. The proposal combines BIP44 and BIP45, addressing issues with BIP44's lack of clarity in terms of address format, representation of single-sig or multi-sig wallets, number of cosigners, and collision prevention on the same address index. Brown suggests using bech32 serialized addresses and extending the derivation path below coin type to represent the address format. He proposes creating a separate specification similar to SLIP-0044 to define the list of address formats and derivation path values, allowing for future address formats to be easily supported. Clark Moody suggests using the xpub serialization format described in SLIP-0032 as an alternative solution, which includes the derivation path within the xpub itself and uses Bech32 for encoding. Moody argues that this solves the bootstrapping problem and avoids the requirement for users to know the specific BIP number. Brown responds by acknowledging that his initial encoding was incorrect and suggests further extending the derivation path based on the coin type value. He believes a separate spec can be created to support different address formats without requiring new BIPs. The proposal includes several links to other related Bitcoin Improvement Proposals and discussions on addressing collisions and separating cosigners in the derivation path. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_New-serialization-encoding-format-for-key-material.xml b/static/bitcoin-dev/May_2018/combined_New-serialization-encoding-format-for-key-material.xml index 7c44560b11..6b836ca0c0 100644 --- a/static/bitcoin-dev/May_2018/combined_New-serialization-encoding-format-for-key-material.xml +++ b/static/bitcoin-dev/May_2018/combined_New-serialization-encoding-format-for-key-material.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - New serialization/encoding format for key material - 2023-08-01T23:19:34.371665+00:00 - - Pieter Wuille 2018-06-23 19:49:54+00:00 - - - Russell O'Connor 2018-06-15 15:54:30+00:00 - - - Russell O'Connor 2018-06-13 14:58:33+00:00 - - - Pieter Wuille 2018-06-13 02:44:47+00:00 - - - Jonas Schnelli 2018-06-03 21:30:48+00:00 - - - Pieter Wuille 2018-06-03 19:23:17+00:00 - - - Jonas Schnelli 2018-06-03 16:51:09+00:00 - - - Jonas Schnelli 2018-05-30 19:03:46+00:00 - - - Gregory Maxwell 2018-05-30 14:08:08+00:00 - - - shiva sitamraju 2018-05-30 06:30:25+00:00 - - - Jonas Schnelli 2018-05-29 09:13:37+00:00 - + 2025-09-26T15:37:55.643116+00:00 + python-feedgen + + + [bitcoin-dev] New serialization/encoding format for key material Jonas Schnelli + 2018-05-29T09:13:00.000Z + + + shiva sitamraju + 2018-05-30T06:30:00.000Z + + + Gregory Maxwell + 2018-05-30T14:08:00.000Z + + + Jonas Schnelli + 2018-05-30T19:03:00.000Z + + + Jonas Schnelli + 2018-06-03T16:51:00.000Z + + + Pieter Wuille + 2018-06-03T19:23:00.000Z + + + Jonas Schnelli + 2018-06-03T21:30:00.000Z + + + Pieter Wuille + 2018-06-13T02:44:00.000Z + + + Russell O'Connor + 2018-06-13T14:58:00.000Z + + + Russell O'Connor + 2018-06-15T15:54:00.000Z + + + Pieter Wuille + 2018-06-23T19:49:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - New serialization/encoding format for key material - 2023-08-01T23:19:34.371665+00:00 + 2025-09-26T15:37:55.644402+00:00 - Pieter and Russell O'Connor have been discussing the correctable error rates of codes designed for length 341, which is the first length enough to support 512 bits of data. The number of correctable errors includes errors inside the checksum characters themselves, meaning that aiming for a certain percentage of correctable characters increases the numbers dramatically. Pieter provides some numbers for codes restricted to a total of 341 characters and assuming 103 data characters, including 26 checksum characters (adding 25%, 20% of overall string), seven errors can be corrected (5% of overall string). With 62 checksum characters (adding 60%, 38% of overall string), 17 errors can be corrected (10% of overall string). With 116 checksum characters (adding 113%, 53% of overall string), 33 errors can be corrected (15% of overall string) and with 195 checksum characters (adding 189%, 65% of overall string), 60 errors can be corrected (20% of overall string). Furthermore, for codes restricted to 1023 characters total (including the checksum characters) and assuming 103 data characters, including 27 checksum characters (adding 26%, 21% of overall string), seven errors can be corrected (5% of overall string). With 64 checksum characters (adding 62%, 38% of overall string), 17 errors can be corrected (10% of overall string), with 127 checksum characters (adding 123%, 57% of overall string), 36 errors can be corrected (15% of overall string), with 294 checksum characters (adding 285%, 74% of overall string), 80 errors can be corrected (20% of overall string), and with 920 checksum characters (adding 893%, 90% of overall string), 255 errors can be corrected (25% of overall string). Russell O'Connor suggests that it might be better to support multiple checksum variants instead of having a trade-off between the length of the code and recovery properties, as the user's medium of storage is likely to vary from person to person. He personally would probably be interested in the 51 or even 102 character checksums variants. Pieter offers to construct reference source code for any of these variants.The number of checksum characters needed to correct errors in codes designed for a length of 341 varies based on the number of errors to be corrected. For correcting one error, three checksum characters are required, and for correcting two errors, seven checksum characters are required. This pattern continues up to correcting 28 errors, which requires 102 checksum characters, or approximately double the length of the code. The trade-off between code length and recovery properties is determined by the user's medium of storage. It may be beneficial to support multiple checksum variants to accommodate varying storage mediums. The proposal suggests supporting longer checksum variants, such as the 51 or 102 character checksums.In an email to the bitcoin-dev mailing list, Jonas Schnelli discussed the presence of 520 bits in a BIP32 chain code with a compressed public key. According to Schnelli, the first 256 bits are the chain code and the remaining 264 bits define the public key. He also explained that in a 33 byte compressed public key, only one bit from the first byte is necessary to convey information, allowing for the other seven bits to be discarded. This reduction can result in a one-character decrease in the bech32 encoded result.Pieter proposed to construct a code and implementation for various BCH codes on the request of Jonas Schnelli. Pieter presented an example BCH code for base32 data which adds 27 checksum characters and can correct up to 7 errors in strings with length up to 1023, including the checksum characters themselves. The code can encode sequences of integers ranging from 0 to 31. He also provided an example of how to decode and correct errors in the encoded message. However, the code he provided has no special properties beyond the ones it is designed for. Pieter suggested that he could easily generate similar code for BCH codes with different properties.The writer expresses concerns about the use of Bech32 for error correction, noting that it is only efficient at correcting one error up to length 1023. While the checksum provides a small constant speedup, it doesn't fundamentally improve recovery. The writer suggests a code that includes computational costs for error correction during disaster recovery and notes that deriving one million child keys and comparing them against an address table would take less than a minute on consumer systems. They propose a trade-off between code length and recovery properties, suggesting that 5% error correction with a 26 char checksum is acceptable. The resulting string with 26 checksum chars is longer than the Bech32 equivalent but still considered acceptable for disaster recovery purposes. Finally, the writer offers to construct a code and implementation based on these requirements.Pieter, a contributor to the 2018-06-23T19:49:54+00:00 + Pieter and Russell O'Connor have been discussing the correctable error rates of codes designed for length 341, which is the first length enough to support 512 bits of data. The number of correctable errors includes errors inside the checksum characters themselves, meaning that aiming for a certain percentage of correctable characters increases the numbers dramatically. Pieter provides some numbers for codes restricted to a total of 341 characters and assuming 103 data characters, including 26 checksum characters (adding 25%, 20% of overall string), seven errors can be corrected (5% of overall string). With 62 checksum characters (adding 60%, 38% of overall string), 17 errors can be corrected (10% of overall string). With 116 checksum characters (adding 113%, 53% of overall string), 33 errors can be corrected (15% of overall string) and with 195 checksum characters (adding 189%, 65% of overall string), 60 errors can be corrected (20% of overall string). Furthermore, for codes restricted to 1023 characters total (including the checksum characters) and assuming 103 data characters, including 27 checksum characters (adding 26%, 21% of overall string), seven errors can be corrected (5% of overall string). With 64 checksum characters (adding 62%, 38% of overall string), 17 errors can be corrected (10% of overall string), with 127 checksum characters (adding 123%, 57% of overall string), 36 errors can be corrected (15% of overall string), with 294 checksum characters (adding 285%, 74% of overall string), 80 errors can be corrected (20% of overall string), and with 920 checksum characters (adding 893%, 90% of overall string), 255 errors can be corrected (25% of overall string). Russell O'Connor suggests that it might be better to support multiple checksum variants instead of having a trade-off between the length of the code and recovery properties, as the user's medium of storage is likely to vary from person to person. He personally would probably be interested in the 51 or even 102 character checksums variants. Pieter offers to construct reference source code for any of these variants.The number of checksum characters needed to correct errors in codes designed for a length of 341 varies based on the number of errors to be corrected. For correcting one error, three checksum characters are required, and for correcting two errors, seven checksum characters are required. This pattern continues up to correcting 28 errors, which requires 102 checksum characters, or approximately double the length of the code. The trade-off between code length and recovery properties is determined by the user's medium of storage. It may be beneficial to support multiple checksum variants to accommodate varying storage mediums. The proposal suggests supporting longer checksum variants, such as the 51 or 102 character checksums.In an email to the bitcoin-dev mailing list, Jonas Schnelli discussed the presence of 520 bits in a BIP32 chain code with a compressed public key. According to Schnelli, the first 256 bits are the chain code and the remaining 264 bits define the public key. He also explained that in a 33 byte compressed public key, only one bit from the first byte is necessary to convey information, allowing for the other seven bits to be discarded. This reduction can result in a one-character decrease in the bech32 encoded result.Pieter proposed to construct a code and implementation for various BCH codes on the request of Jonas Schnelli. Pieter presented an example BCH code for base32 data which adds 27 checksum characters and can correct up to 7 errors in strings with length up to 1023, including the checksum characters themselves. The code can encode sequences of integers ranging from 0 to 31. He also provided an example of how to decode and correct errors in the encoded message. However, the code he provided has no special properties beyond the ones it is designed for. Pieter suggested that he could easily generate similar code for BCH codes with different properties.The writer expresses concerns about the use of Bech32 for error correction, noting that it is only efficient at correcting one error up to length 1023. While the checksum provides a small constant speedup, it doesn't fundamentally improve recovery. The writer suggests a code that includes computational costs for error correction during disaster recovery and notes that deriving one million child keys and comparing them against an address table would take less than a minute on consumer systems. They propose a trade-off between code length and recovery properties, suggesting that 5% error correction with a 26 char checksum is acceptable. The resulting string with 26 checksum chars is longer than the Bech32 equivalent but still considered acceptable for disaster recovery purposes. Finally, the writer offers to construct a code and implementation based on these requirements.Pieter, a contributor to the - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_SIGHASH2-for-version-1-witness-programme.xml b/static/bitcoin-dev/May_2018/combined_SIGHASH2-for-version-1-witness-programme.xml index c9d7619994..3527638a0a 100644 --- a/static/bitcoin-dev/May_2018/combined_SIGHASH2-for-version-1-witness-programme.xml +++ b/static/bitcoin-dev/May_2018/combined_SIGHASH2-for-version-1-witness-programme.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 - - Christian Decker 2018-09-03 13:53:33+00:00 - - - Johnson Lau 2018-08-31 07:42:07+00:00 - - - Christian Decker 2018-08-30 20:51:15+00:00 - - - Johnson Lau 2018-08-30 20:38:06+00:00 - - - Gregory Maxwell 2018-07-02 18:23:48+00:00 - - - Johnson Lau 2018-06-01 18:45:57+00:00 - - - Russell O'Connor 2018-06-01 18:15:32+00:00 - - - Johnson Lau 2018-06-01 17:03:05+00:00 - - - Russell O'Connor 2018-06-01 15:03:46+00:00 - - - Johnson Lau 2018-05-31 18:35:41+00:00 - + 2025-09-26T15:38:14.590525+00:00 + python-feedgen + + + [bitcoin-dev] SIGHASH2 for version 1 witness programme Johnson Lau + 2018-05-31T18:35:00.000Z + + + Russell O'Connor + 2018-06-01T15:03:00.000Z + + + Johnson Lau + 2018-06-01T17:03:00.000Z + + + Russell O'Connor + 2018-06-01T18:15:00.000Z + + + Johnson Lau + 2018-06-01T18:45:00.000Z + + + Gregory Maxwell + 2018-07-02T18:23:00.000Z + + + Johnson Lau + 2018-08-30T20:38:00.000Z + + + Christian Decker + 2018-08-30T20:51:00.000Z + + + Johnson Lau + 2018-08-31T07:42:00.000Z + + + Christian Decker + 2018-09-03T13:53:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 + 2025-09-26T15:38:14.591698+00:00 - A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. 2018-09-03T13:53:33+00:00 + A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_Should-Graftroot-be-optional-.xml b/static/bitcoin-dev/May_2018/combined_Should-Graftroot-be-optional-.xml index ce82a4147a..90c0e5a85d 100644 --- a/static/bitcoin-dev/May_2018/combined_Should-Graftroot-be-optional-.xml +++ b/static/bitcoin-dev/May_2018/combined_Should-Graftroot-be-optional-.xml @@ -1,71 +1,95 @@ - + 2 Combined summary - Should Graftroot be optional? - 2023-08-01T23:16:46.776152+00:00 - - Anthony Towns 2018-06-27 07:29:09+00:00 - - - ZmnSCPxj 2018-06-21 07:09:14+00:00 - - - Gregory Maxwell 2018-06-20 14:30:55+00:00 - - - ZmnSCPxj 2018-06-20 12:12:28+00:00 - - - Tim Ruffing 2018-06-06 21:25:33+00:00 - - - Pieter Wuille 2018-06-06 17:04:23+00:00 - - - Tim Ruffing 2018-06-06 12:48:01+00:00 - - - Pieter Wuille 2018-06-01 00:25:04+00:00 - - - Johnson Lau 2018-05-25 10:14:48+00:00 - - - Johnson Lau 2018-05-25 09:46:29+00:00 - - - Andrew Poelstra 2018-05-24 12:39:55+00:00 - - - Natanael 2018-05-24 09:44:16+00:00 - - - Natanael 2018-05-24 09:32:23+00:00 - - - Gregory Maxwell 2018-05-24 02:08:07+00:00 - - - Pieter Wuille 2018-05-24 01:58:11+00:00 - - - Gregory Maxwell 2018-05-23 23:45:09+00:00 - - - Natanael 2018-05-23 22:06:31+00:00 - - - Andrew Poelstra 2018-05-23 17:52:39+00:00 - - - Andrew Poelstra 2018-05-23 13:50:13+00:00 - - - ZmnSCPxj 2018-05-23 06:15:03+00:00 - - - Pieter Wuille 2018-05-22 18:17:42+00:00 - + 2025-09-26T15:37:47.263167+00:00 + python-feedgen + + + [bitcoin-dev] Should Graftroot be optional? Pieter Wuille + 2018-05-22T18:17:00.000Z + + + ZmnSCPxj + 2018-05-23T06:15:00.000Z + + + Andrew Poelstra + 2018-05-23T13:50:00.000Z + + + Andrew Poelstra + 2018-05-23T17:52:00.000Z + + + Natanael + 2018-05-23T22:06:00.000Z + + + Gregory Maxwell + 2018-05-23T23:45:00.000Z + + + Pieter Wuille + 2018-05-24T01:58:00.000Z + + + Gregory Maxwell + 2018-05-24T02:08:00.000Z + + + Natanael + 2018-05-24T09:32:00.000Z + + + Natanael + 2018-05-24T09:44:00.000Z + + + Andrew Poelstra + 2018-05-24T12:39:00.000Z + + + Johnson Lau + 2018-05-25T09:46:00.000Z + + + Johnson Lau + 2018-05-25T10:14:00.000Z + + + Pieter Wuille + 2018-06-01T00:25:00.000Z + + + Tim Ruffing + 2018-06-06T12:48:00.000Z + + + Pieter Wuille + 2018-06-06T17:04:00.000Z + + + Tim Ruffing + 2018-06-06T21:25:00.000Z + + + ZmnSCPxj + 2018-06-20T12:12:00.000Z + + + Gregory Maxwell + 2018-06-20T14:30:00.000Z + + + ZmnSCPxj + 2018-06-21T07:09:00.000Z + + + Anthony Towns + 2018-06-27T07:29:00.000Z + + @@ -87,13 +111,13 @@ - python-feedgen + 2 Combined summary - Should Graftroot be optional? - 2023-08-01T23:16:46.777151+00:00 + 2025-09-26T15:37:47.265231+00:00 - On May 31, 2018, a discussion took place on the bitcoin-dev mailing list regarding the Graftroot proposal. Pieter Wuille argued that Graftroot delegation is not strictly less powerful than using a normal transaction because it enables delegation in a way that cannot be fixed in the chain. However, there may be practical implications to consider. The conversation also explored the similarities between Graftroot and SIGHASH_NOINPUT, and proposed making Graftroot spending a special sighash flag. It was suggested that the actual signature should still be different to avoid malleability issues.The concept of Graftroot signatures was brought up in a recent Bitcoin development discussion. These signatures commit to a single outpoint, making it impossible for them to be used to spend all outpoints that pay to the same public key. However, if a graftroot signature cannot be made independent of the outpoint, it greatly reduces its functionality. The main benefits of grafts are the ability to delegate before coins exist and making the transfer atomic compared to pre-signing a transaction.Pieter Wuille and Tim Ruffing discussed the design of the Graftroot signature. It was pointed out that the safety of the construction does not solely depend on consensus rules but also on how it is used. The discussion also touched on the compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs.Johnson Lau and Pieter Wuille had a debate about the safety of the Graftroot design. While Johnson Lau argued that if the design is dangerous, then the existing signature checking rules must be equally dangerous, Pieter Wuille emphasized that the safety of a construction depends on more than just consensus rules. He mentioned that having the option of Graftroot being non-optional is not required, as signers can use other methods.Pieter Wuille expressed concerns about the deployment of Taproot and Graftroot in an email to the Bitcoin developers' mailing list. He suggested that a practical deployment may require explicit enablement or disablement of the Graftroot spending path. Various approaches were listed to address this issue, but they were considered less efficient or private compared to allowing Graftroot spends directly. The compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs was also emphasized.In a separate discussion, the topic of accountability for funds held in a P2SH address was raised. The concern was that collusion among parties involved in signing a transaction could undermine the original purpose of the fund. The possibility of using Graftroot to pay funds to a public key without constraint was mentioned. It was agreed that it should be possible to send funds constrained by a script without a public key ever existing.The need for an explicit enable or disable feature for the Graftroot spending path in Taproot and Graftroot deployment was discussed. Suggestions included including a flag to choose in advance whether the script will be static or "editable" and including proof-requiring committed transactions to prevent unauthorized withdrawals. Concerns were raised about potential problems if Taproot and Graftroot were used to withdraw funds without showing in the published script. The importance of being able to prove that a transaction isn't using Taproot and Graftroot was highlighted.Andrew Poelstra raised concerns about Graftroot potentially breaking blind signature schemes but later explained a way to maintain unique keys for every output while retaining the same private key. A scheme for blind signatures was proposed but noted its vulnerability to Wagner's attack. Key-prefixing was suggested to enhance security by making the messagehash unique per-utxo and committed in the chain.ZmnSCPxj proposed modifying the Taproot equation to make Graftroot optional and combining Taproot and Graftroot. This would involve using a one-level Merkle tree where one branch enables or disables Graftroot and the other branch represents an ordinary script. Concerns were raised about signing arbitrary messages and ensuring that the simple-signing case does not become a vulnerability for wallets.The discussions surrounding Taproot and Graftroot have prompted questions about the need for explicit enablement or disablement of the Graftroot spending path in practical deployments. The safety of always permitting both types of script spending paths is being debated, as accidental signing of a script could have broader consequences without Graftroot. In a multisignature setting, the presence of Graftroot could allow a subset of participants to remove others from the set of signers. The discussions highlight the importance of considering potential reasons why certain applications may not adopt these outputs. 2018-06-27T07:29:09+00:00 + On May 31, 2018, a discussion took place on the bitcoin-dev mailing list regarding the Graftroot proposal. Pieter Wuille argued that Graftroot delegation is not strictly less powerful than using a normal transaction because it enables delegation in a way that cannot be fixed in the chain. However, there may be practical implications to consider. The conversation also explored the similarities between Graftroot and SIGHASH_NOINPUT, and proposed making Graftroot spending a special sighash flag. It was suggested that the actual signature should still be different to avoid malleability issues.The concept of Graftroot signatures was brought up in a recent Bitcoin development discussion. These signatures commit to a single outpoint, making it impossible for them to be used to spend all outpoints that pay to the same public key. However, if a graftroot signature cannot be made independent of the outpoint, it greatly reduces its functionality. The main benefits of grafts are the ability to delegate before coins exist and making the transfer atomic compared to pre-signing a transaction.Pieter Wuille and Tim Ruffing discussed the design of the Graftroot signature. It was pointed out that the safety of the construction does not solely depend on consensus rules but also on how it is used. The discussion also touched on the compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs.Johnson Lau and Pieter Wuille had a debate about the safety of the Graftroot design. While Johnson Lau argued that if the design is dangerous, then the existing signature checking rules must be equally dangerous, Pieter Wuille emphasized that the safety of a construction depends on more than just consensus rules. He mentioned that having the option of Graftroot being non-optional is not required, as signers can use other methods.Pieter Wuille expressed concerns about the deployment of Taproot and Graftroot in an email to the Bitcoin developers' mailing list. He suggested that a practical deployment may require explicit enablement or disablement of the Graftroot spending path. Various approaches were listed to address this issue, but they were considered less efficient or private compared to allowing Graftroot spends directly. The compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs was also emphasized.In a separate discussion, the topic of accountability for funds held in a P2SH address was raised. The concern was that collusion among parties involved in signing a transaction could undermine the original purpose of the fund. The possibility of using Graftroot to pay funds to a public key without constraint was mentioned. It was agreed that it should be possible to send funds constrained by a script without a public key ever existing.The need for an explicit enable or disable feature for the Graftroot spending path in Taproot and Graftroot deployment was discussed. Suggestions included including a flag to choose in advance whether the script will be static or "editable" and including proof-requiring committed transactions to prevent unauthorized withdrawals. Concerns were raised about potential problems if Taproot and Graftroot were used to withdraw funds without showing in the published script. The importance of being able to prove that a transaction isn't using Taproot and Graftroot was highlighted.Andrew Poelstra raised concerns about Graftroot potentially breaking blind signature schemes but later explained a way to maintain unique keys for every output while retaining the same private key. A scheme for blind signatures was proposed but noted its vulnerability to Wagner's attack. Key-prefixing was suggested to enhance security by making the messagehash unique per-utxo and committed in the chain.ZmnSCPxj proposed modifying the Taproot equation to make Graftroot optional and combining Taproot and Graftroot. This would involve using a one-level Merkle tree where one branch enables or disables Graftroot and the other branch represents an ordinary script. Concerns were raised about signing arbitrary messages and ensuring that the simple-signing case does not become a vulnerability for wallets.The discussions surrounding Taproot and Graftroot have prompted questions about the need for explicit enablement or disablement of the Graftroot spending path in practical deployments. The safety of always permitting both types of script spending paths is being debated, as accidental signing of a script could have broader consequences without Graftroot. In a multisignature setting, the presence of Graftroot could allow a subset of participants to remove others from the set of signers. The discussions highlight the importance of considering potential reasons why certain applications may not adopt these outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_TXO-bitfield-size-graphs.xml b/static/bitcoin-dev/May_2018/combined_TXO-bitfield-size-graphs.xml index 78418106b3..b7032b915f 100644 --- a/static/bitcoin-dev/May_2018/combined_TXO-bitfield-size-graphs.xml +++ b/static/bitcoin-dev/May_2018/combined_TXO-bitfield-size-graphs.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - TXO bitfield size graphs - 2023-08-01T23:18:28.758991+00:00 - - Jim Posen 2018-05-24 04:02:17+00:00 - - - Bram Cohen 2018-05-24 02:43:44+00:00 - - - Jim Posen 2018-05-23 23:48:33+00:00 - + 2025-09-26T15:38:08.297626+00:00 + python-feedgen + + + [bitcoin-dev] TXO bitfield size graphs Jim Posen + 2018-05-23T23:48:00.000Z + + + Bram Cohen + 2018-05-24T02:43:00.000Z + + + Jim Posen + 2018-05-24T04:02:00.000Z + + - python-feedgen + 2 Combined summary - TXO bitfield size graphs - 2023-08-01T23:18:28.758991+00:00 + 2025-09-26T15:38:08.298098+00:00 - The email thread revolves around the discussion of compression ratios for TXO (transaction output) bitfields and their feasibility in committing to block headers. The main objective is to compress the bitfields when sending proofs of spentness/unspentness to light clients, especially considering bandwidth limitations. One proposed solution is constructing a Merkle Mountain Range over the bitfield chunks to efficiently prove spentness to clients. The top graph presented in the email shows the compression ratios achievable on a TXO bitfield split into 4 KiB chunks using gzip (level=9) and lz4. The data was collected at block height 523,303. It was observed that the compression ratio is lower for older chunks and even worse for more recent blocks. Over the entire history, gzip achieves a compression ratio of 34.4%, lz4 achieves 54.8%, and bz2 achieves 37.6%.Additionally, the bottom graph illustrates the sizes of per-block bitfields, which are more suitable for constructions where an output's position is determined by its block hash plus relative index. In terms of overall compression ratios, gzip achieves 50%, lz4 achieves 70%, and bz2 achieves 61.5% for these separately stored bitfields.During the discussion, Bram Cohen suggests that using run length encoding on the number of repeated bits and compressing it with elias omega encoding could potentially yield better results than standard compression algorithms as it natively handles bitfields.Overall, the research aims to explore the possibility of committing to TXO bitfields with block headers to enable UTXO inclusion/exclusion proofs for light clients. The analysis of compression ratios reveals the efficiency of different algorithms, highlighting the importance of choosing the appropriate compression method based on the nature of the data. 2018-05-24T04:02:17+00:00 + The email thread revolves around the discussion of compression ratios for TXO (transaction output) bitfields and their feasibility in committing to block headers. The main objective is to compress the bitfields when sending proofs of spentness/unspentness to light clients, especially considering bandwidth limitations. One proposed solution is constructing a Merkle Mountain Range over the bitfield chunks to efficiently prove spentness to clients. The top graph presented in the email shows the compression ratios achievable on a TXO bitfield split into 4 KiB chunks using gzip (level=9) and lz4. The data was collected at block height 523,303. It was observed that the compression ratio is lower for older chunks and even worse for more recent blocks. Over the entire history, gzip achieves a compression ratio of 34.4%, lz4 achieves 54.8%, and bz2 achieves 37.6%.Additionally, the bottom graph illustrates the sizes of per-block bitfields, which are more suitable for constructions where an output's position is determined by its block hash plus relative index. In terms of overall compression ratios, gzip achieves 50%, lz4 achieves 70%, and bz2 achieves 61.5% for these separately stored bitfields.During the discussion, Bram Cohen suggests that using run length encoding on the number of repeated bits and compressing it with elias omega encoding could potentially yield better results than standard compression algorithms as it natively handles bitfields.Overall, the research aims to explore the possibility of committing to TXO bitfields with block headers to enable UTXO inclusion/exclusion proofs for light clients. The analysis of compression ratios reveals the efficiency of different algorithms, highlighting the importance of choosing the appropriate compression method based on the nature of the data. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_UHS-Full-node-security-without-maintaining-a-full-UTXO-set.xml b/static/bitcoin-dev/May_2018/combined_UHS-Full-node-security-without-maintaining-a-full-UTXO-set.xml index 3ec377fcfb..f4dd10f2d1 100644 --- a/static/bitcoin-dev/May_2018/combined_UHS-Full-node-security-without-maintaining-a-full-UTXO-set.xml +++ b/static/bitcoin-dev/May_2018/combined_UHS-Full-node-security-without-maintaining-a-full-UTXO-set.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - UHS: Full-node security without maintaining a full UTXO set - 2023-08-01T23:08:00.907735+00:00 - - Jim Posen 2018-06-10 23:07:07+00:00 - - - Sjors Provoost 2018-06-07 09:39:59+00:00 - - - Alex Mizrahi 2018-05-18 15:42:00+00:00 - - - Cory Fields 2018-05-17 17:16:46+00:00 - - - Gregory Maxwell 2018-05-17 16:56:39+00:00 - - - Matt Corallo 2018-05-17 15:28:28+00:00 - - - Cory Fields 2018-05-16 16:36:35+00:00 - + 2025-09-26T15:38:10.390549+00:00 + python-feedgen + + + [bitcoin-dev] UHS: Full-node security without maintaining a full UTXO set Cory Fields + 2018-05-16T16:36:00.000Z + + + Matt Corallo + 2018-05-17T15:28:00.000Z + + + Gregory Maxwell + 2018-05-17T16:56:00.000Z + + + Cory Fields + 2018-05-17T17:16:00.000Z + + + Alex Mizrahi + 2018-05-18T15:42:00.000Z + + + Sjors Provoost + 2018-06-07T09:39:00.000Z + + + Jim Posen + 2018-06-10T23:07:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - UHS: Full-node security without maintaining a full UTXO set - 2023-08-01T23:08:00.907735+00:00 + 2025-09-26T15:38:10.391377+00:00 - A proposal has been made to change the way unspent transaction outputs (UTXOs) are stored in Bitcoin. The proposal suggests storing only the hashes of UTXOs instead of their full data, which could result in a 40% reduction in the size of a pruned node and less than a 1% reduction in an archive node. However, there are concerns about the 5% ongoing bandwidth increase required by this change and whether it would be worth the reduction in node size. The current transaction mechanisms are considered inefficient, and implementing this change may actually result in a 25% increase in overhead. Despite these concerns, the proposal does not require any changes to the blockchain data structure and could be implemented without permanently marrying the network to it.The proposal is based on separating the roles of the UTXO set, with one role providing proof that previous outputs exist to be spent and the other role providing the actual previous output data for verification. Instead of storing the full dereferenced prevout entries in a UTXO set, the proposal suggests storing their hashes to an Unspent Transaction Output Hash Set (UHS). This approach offers several advantages, including disk and memory savings, faster validation speeds, and more efficient caching. Pay-to-pubkey outputs would also be less burdensome on full nodes, and an even more aggressive pruning mode could be enabled.However, there are some drawbacks to this approach. It may require a few "bridge nodes" during the transition period, and there is a small increase in network traffic. Non-standard output scripts would still need to be sent in full, but they account for only around 1% of all current UTXOs. Despite these drawbacks, the proposal does not introduce any fundamental changes to Bitcoin's security model.Transitioning from the current UTXO model to the UHS model may be challenging but not overly difficult. Wallets would need to hold full prevout data for their unspent outputs, and a new service-bit would be allocated to indicate nodes willing to serve blocks and transactions with dereferenced prevout data appended. The proposal is still in its early stages, and implementation details need to be worked out. Further analysis is needed to determine whether the benefits of this proposal outweigh the costs.In conclusion, the proposal to store only the hashes of unspent outputs in Bitcoin has the potential to reduce node size and improve efficiency. However, there are concerns about the ongoing bandwidth increase and the overhead of the proposed change. Despite these concerns, the proposal could be implemented without permanently changing the blockchain data structure. Further analysis and testing are needed to fully evaluate the benefits and drawbacks of this proposal. 2018-06-10T23:07:07+00:00 + A proposal has been made to change the way unspent transaction outputs (UTXOs) are stored in Bitcoin. The proposal suggests storing only the hashes of UTXOs instead of their full data, which could result in a 40% reduction in the size of a pruned node and less than a 1% reduction in an archive node. However, there are concerns about the 5% ongoing bandwidth increase required by this change and whether it would be worth the reduction in node size. The current transaction mechanisms are considered inefficient, and implementing this change may actually result in a 25% increase in overhead. Despite these concerns, the proposal does not require any changes to the blockchain data structure and could be implemented without permanently marrying the network to it.The proposal is based on separating the roles of the UTXO set, with one role providing proof that previous outputs exist to be spent and the other role providing the actual previous output data for verification. Instead of storing the full dereferenced prevout entries in a UTXO set, the proposal suggests storing their hashes to an Unspent Transaction Output Hash Set (UHS). This approach offers several advantages, including disk and memory savings, faster validation speeds, and more efficient caching. Pay-to-pubkey outputs would also be less burdensome on full nodes, and an even more aggressive pruning mode could be enabled.However, there are some drawbacks to this approach. It may require a few "bridge nodes" during the transition period, and there is a small increase in network traffic. Non-standard output scripts would still need to be sent in full, but they account for only around 1% of all current UTXOs. Despite these drawbacks, the proposal does not introduce any fundamental changes to Bitcoin's security model.Transitioning from the current UTXO model to the UHS model may be challenging but not overly difficult. Wallets would need to hold full prevout data for their unspent outputs, and a new service-bit would be allocated to indicate nodes willing to serve blocks and transactions with dereferenced prevout data appended. The proposal is still in its early stages, and implementation details need to be worked out. Further analysis is needed to determine whether the benefits of this proposal outweigh the costs.In conclusion, the proposal to store only the hashes of unspent outputs in Bitcoin has the potential to reduce node size and improve efficiency. However, there are concerns about the ongoing bandwidth increase and the overhead of the proposed change. Despite these concerns, the proposal could be implemented without permanently changing the blockchain data structure. Further analysis and testing are needed to fully evaluate the benefits and drawbacks of this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_Why-not-archive-the-backend-of-Bitcoin-blockchain-.xml b/static/bitcoin-dev/May_2018/combined_Why-not-archive-the-backend-of-Bitcoin-blockchain-.xml index 68178cdf79..319e972d99 100644 --- a/static/bitcoin-dev/May_2018/combined_Why-not-archive-the-backend-of-Bitcoin-blockchain-.xml +++ b/static/bitcoin-dev/May_2018/combined_Why-not-archive-the-backend-of-Bitcoin-blockchain-.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Why not archive the backend of Bitcoin blockchain? - 2023-08-01T23:06:41.003598+00:00 - - Brian Lockhart 2018-06-14 23:24:33+00:00 - - - Christian Decker 2018-06-13 16:17:20+00:00 - - - Brian Lockhart 2018-06-13 15:32:11+00:00 - - - Christian Decker 2018-06-13 13:33:33+00:00 - - - Kulpreet Singh 2018-06-12 08:40:18+00:00 - - - Patrick Shirkey 2018-05-10 10:52:41+00:00 - - - ZmnSCPxj 2018-05-10 07:54:08+00:00 - - - Jim Posen 2018-05-10 06:50:43+00:00 - - - アルム　カールヨハン 2018-05-10 06:48:16+00:00 - - - Segue 2018-05-10 00:56:00+00:00 - + 2025-09-26T15:38:06.206145+00:00 + python-feedgen + + + [bitcoin-dev] Why not archive the backend of Bitcoin blockchain? Segue + 2018-05-10T00:56:00.000Z + + + アルム　カールヨハン + 2018-05-10T06:48:00.000Z + + + Jim Posen + 2018-05-10T06:50:00.000Z + + + ZmnSCPxj + 2018-05-10T07:54:00.000Z + + + Patrick Shirkey + 2018-05-10T10:52:00.000Z + + + Kulpreet Singh + 2018-06-12T08:40:00.000Z + + + Christian Decker + 2018-06-13T13:33:00.000Z + + + Brian Lockhart + 2018-06-13T15:32:00.000Z + + + Christian Decker + 2018-06-13T16:17:00.000Z + + + Brian Lockhart + 2018-06-14T23:24:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Why not archive the backend of Bitcoin blockchain? - 2023-08-01T23:06:41.003598+00:00 + 2025-09-26T15:38:06.207342+00:00 - A Lightning node can access an existing node instead of running its own dedicated instance of bitcoind. This can be achieved by configuring 'bitcoin-cli' to connect to a remote node with the 'rpcconnect', 'rpcuser', and 'rpcpassword' options in the 'bitcoin.conf' file or using command-line options when starting 'lightningd'. All three implementations of Lightning, c-lightning, lnd, and Eclair, support this method. Christian Decker, a developer at Blockstream, confirmed that Lightning nodes need to monitor the network for transactions and suspicious activity, but the bitcoind sitting next to the Lightning node does not need to keep an index of the transactions. Running with '-txindex' is not necessary for a Lightning node. Pruned nodes can work as long as the current blockchain head seen by the Lightning node does not fall into the pruned range. However, an indexed pruned node does not make sense for Lightning. The reliance on bitcoind for Lightning nodes is expected to be minimized in the future.In March 2018, a user on the Lightning-dev list asked about using Lightning without running a full bitcoin blockchain due to limited laptop space. Patrick Shirkey suggested periodically archiving old chapters of the blockchain on at least 150 computers across seven continents, storing just the index. This idea was later posted on the Bitcoin-dev list, noting that the "prune" flag could be used to get a snapshot of the blockchain but may cause issues for Lightning nodes if incompatible with "txindex" and "rescan".C-lightning is not officially rated for pruned bitcoind use, but it can be used if bitcoind is installed and started before lightningd, catching up to the chain. Pruned bitcoind is not officially supported, so any loss of funds due to this setup would be the user's responsibility. The implementation of the "chapter-based" archiving idea needs to be reviewed and implemented, addressing questions such as selecting archive servers and ensuring equal access to historical blockchain data.Bitcoin Core can operate in a pruned mode where most of the historical block data is discarded, keeping only the current UTXO set and recent blocks. However, some nodes on the network need to run in archive mode to help new nodes get in sync. BIP 159 identifies these archive nodes at the gossip layer. While some Lightning implementations use the additional txindex, which is not compatible with pruned mode, Segue suggested archiving chunks of the blockchain on distributed computers to avoid an infinitely long chain. This suggestion was posted on the bitcoin-dev list for further discussion.A user named Yubin Ruan asked about running the Lightning network without a full Bitcoin blockchain due to limited laptop space. Segue proposed the idea of periodically archiving chunks of the blockchain on 150 computers across seven continents to prevent an endlessly growing chain. This suggestion was then shared on the Bitcoin-dev list for more input. Pruning can also be used to store only the last X MB of the blockchain while keeping the UTXO set, which takes up a few GBs of space.In summary, Lightning nodes can access existing nodes instead of running their own dedicated bitcoind instance. Different implementations offer various methods to achieve this. The reliance on bitcoind for Lightning nodes is expected to decrease in the future. There have been discussions about archiving old chapters of the blockchain on multiple computers across continents to avoid an endlessly long chain. Pruned nodes are possible but may cause compatibility issues with txindex and rescan. The implementation of these ideas and their practicality are still being explored. 2018-06-14T23:24:33+00:00 + A Lightning node can access an existing node instead of running its own dedicated instance of bitcoind. This can be achieved by configuring 'bitcoin-cli' to connect to a remote node with the 'rpcconnect', 'rpcuser', and 'rpcpassword' options in the 'bitcoin.conf' file or using command-line options when starting 'lightningd'. All three implementations of Lightning, c-lightning, lnd, and Eclair, support this method. Christian Decker, a developer at Blockstream, confirmed that Lightning nodes need to monitor the network for transactions and suspicious activity, but the bitcoind sitting next to the Lightning node does not need to keep an index of the transactions. Running with '-txindex' is not necessary for a Lightning node. Pruned nodes can work as long as the current blockchain head seen by the Lightning node does not fall into the pruned range. However, an indexed pruned node does not make sense for Lightning. The reliance on bitcoind for Lightning nodes is expected to be minimized in the future.In March 2018, a user on the Lightning-dev list asked about using Lightning without running a full bitcoin blockchain due to limited laptop space. Patrick Shirkey suggested periodically archiving old chapters of the blockchain on at least 150 computers across seven continents, storing just the index. This idea was later posted on the Bitcoin-dev list, noting that the "prune" flag could be used to get a snapshot of the blockchain but may cause issues for Lightning nodes if incompatible with "txindex" and "rescan".C-lightning is not officially rated for pruned bitcoind use, but it can be used if bitcoind is installed and started before lightningd, catching up to the chain. Pruned bitcoind is not officially supported, so any loss of funds due to this setup would be the user's responsibility. The implementation of the "chapter-based" archiving idea needs to be reviewed and implemented, addressing questions such as selecting archive servers and ensuring equal access to historical blockchain data.Bitcoin Core can operate in a pruned mode where most of the historical block data is discarded, keeping only the current UTXO set and recent blocks. However, some nodes on the network need to run in archive mode to help new nodes get in sync. BIP 159 identifies these archive nodes at the gossip layer. While some Lightning implementations use the additional txindex, which is not compatible with pruned mode, Segue suggested archiving chunks of the blockchain on distributed computers to avoid an infinitely long chain. This suggestion was posted on the bitcoin-dev list for further discussion.A user named Yubin Ruan asked about running the Lightning network without a full Bitcoin blockchain due to limited laptop space. Segue proposed the idea of periodically archiving chunks of the blockchain on 150 computers across seven continents to prevent an endlessly growing chain. This suggestion was then shared on the Bitcoin-dev list for more input. Pruning can also be used to store only the last X MB of the blockchain while keeping the UTXO set, which takes up a few GBs of space.In summary, Lightning nodes can access existing nodes instead of running their own dedicated bitcoind instance. Different implementations offer various methods to achieve this. The reliance on bitcoind for Lightning nodes is expected to decrease in the future. There have been discussions about archiving old chapters of the blockchain on multiple computers across continents to avoid an endlessly long chain. Pruned nodes are possible but may cause compatibility issues with txindex and rescan. The implementation of these ideas and their practicality are still being explored. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml b/static/bitcoin-dev/May_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml index 0a88ff0d7d..598b202eb2 100644 --- a/static/bitcoin-dev/May_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml +++ b/static/bitcoin-dev/May_2018/combined_eltoo-A-Simplified-update-Mechanism-for-Lightning-and-Off-Chain-Contracts.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts - 2023-08-01T22:54:50.676286+00:00 - - Rusty Russell 2018-06-22 00:32:01+00:00 - - - Christian Decker 2018-05-10 13:57:30+00:00 - - - Olaoluwa Osuntokun 2018-05-07 23:26:05+00:00 - - - Jim Posen 2018-05-02 01:15:10+00:00 - - - Christian Decker 2018-05-01 17:31:28+00:00 - - - Jim Posen 2018-05-01 17:07:22+00:00 - - - Christian Decker 2018-05-01 16:29:09+00:00 - - - Jim Posen 2018-05-01 15:50:27+00:00 - - - Christian Decker 2018-05-01 11:38:12+00:00 - - - Christian Decker 2018-05-01 11:36:32+00:00 - - - ZmnSCPxj 2018-05-01 05:07:54+00:00 - - - ZmnSCPxj 2018-05-01 05:01:52+00:00 - - - Jim Posen 2018-04-30 23:00:55+00:00 - - - Christian Decker 2018-04-30 15:41:38+00:00 - + 2025-09-26T15:37:45.144171+00:00 + python-feedgen + + + [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts Christian Decker + 2018-04-30T15:41:00.000Z + + + Jim Posen + 2018-04-30T23:00:00.000Z + + + ZmnSCPxj + 2018-05-01T05:01:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2018-05-01T05:07:00.000Z + + + Christian Decker + 2018-05-01T11:36:00.000Z + + + Christian Decker + 2018-05-01T11:38:00.000Z + + + Jim Posen + 2018-05-01T15:50:00.000Z + + + Christian Decker + 2018-05-01T16:29:00.000Z + + + Jim Posen + 2018-05-01T17:07:00.000Z + + + Christian Decker + 2018-05-01T17:31:00.000Z + + + Jim Posen + 2018-05-02T01:15:00.000Z + + + Olaoluwa Osuntokun + 2018-05-07T23:26:00.000Z + + + Christian Decker + 2018-05-10T13:57:00.000Z + + + Rusty Russell + 2018-06-22T00:32:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts - 2023-08-01T22:54:50.676286+00:00 + 2025-09-26T15:37:45.145800+00:00 - The discussions surrounding the Lightning Network cover several topics. One of the concerns is the potential for attacks and the need for mitigations. Another topic is the impact of symmetric state and eltoo on HTLC (Hashed Timelock Contract) timeouts. The accumulation of timeout delays is also discussed, along with the use of a fixed offset versus an increased delta at each hop in the network. Additionally, there are concerns raised about the terminology used in a research paper, specifically regarding the terms "input script" and "output script." These conversations contribute to the ongoing development and improvement of the Lightning Network protocol.The Lightning Network implementation teams have introduced a new update mechanism called eltoo. This mechanism addresses some of the challenges faced in specifying and implementing the Lightning Network, and it can be used as a generic update mechanism for off-chain contracts with multiple participants. However, before implementing eltoo, a minor change to Bitcoin is required: the introduction of the SIGHASH_NOINPUT flag for signatures.Currently, the penalty-based invalidation mechanism used in the Lightning specification results in lost funds when an old state is published. Eltoo, on the other hand, is not penalty-based, meaning that publishing an old state does not result in lost funds. Instead, it operates similarly to the duplex micropayment channel construction, where all participants share an identical set of transactions. Eltoo ensures that the last agreed-upon state is settled on-chain, with tradeoffs similar to the current Lightning Network.One advantage of eltoo is its ability to attach fees when settling and even bump fees using CPFP (Child-Pays-For-Parent) or RBF (Replace-By-Fee). It also simplifies outsourcing since old states becoming public no longer pose a threat. Furthermore, eltoo eliminates the need to estimate fees ahead of time and can be utilized for other protocols such as channel factories. When combined with Schnorr signatures, eltoo facilitates the creation of large off-chain contracts with minimal on-chain footprint.However, implementing eltoo would require an increase in the safe CLTV (CheckLockTimeVerify) delta requirements. Currently, HTLCs can be timed out immediately on the settlement transaction. With eltoo, when a downstream channel is closed on-chain, it must wait for the CSV (CheckSequenceVerify) timeout on the update transaction before locking in the timed-out HTLC. This means that the CLTV delta needs to be greater than the CSV timeout, plus some extra time. However, it is believed that the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.Overall, eltoo presents a promising update mechanism for off-chain protocols like the Lightning Network. It offers improvements in terms of simplicity, flexibility in fee management, and potential use in various applications beyond Lightning. More details about the eltoo proposal can be found in the paper linked at [2]. 2018-06-22T00:32:01+00:00 + The discussions surrounding the Lightning Network cover several topics. One of the concerns is the potential for attacks and the need for mitigations. Another topic is the impact of symmetric state and eltoo on HTLC (Hashed Timelock Contract) timeouts. The accumulation of timeout delays is also discussed, along with the use of a fixed offset versus an increased delta at each hop in the network. Additionally, there are concerns raised about the terminology used in a research paper, specifically regarding the terms "input script" and "output script." These conversations contribute to the ongoing development and improvement of the Lightning Network protocol.The Lightning Network implementation teams have introduced a new update mechanism called eltoo. This mechanism addresses some of the challenges faced in specifying and implementing the Lightning Network, and it can be used as a generic update mechanism for off-chain contracts with multiple participants. However, before implementing eltoo, a minor change to Bitcoin is required: the introduction of the SIGHASH_NOINPUT flag for signatures.Currently, the penalty-based invalidation mechanism used in the Lightning specification results in lost funds when an old state is published. Eltoo, on the other hand, is not penalty-based, meaning that publishing an old state does not result in lost funds. Instead, it operates similarly to the duplex micropayment channel construction, where all participants share an identical set of transactions. Eltoo ensures that the last agreed-upon state is settled on-chain, with tradeoffs similar to the current Lightning Network.One advantage of eltoo is its ability to attach fees when settling and even bump fees using CPFP (Child-Pays-For-Parent) or RBF (Replace-By-Fee). It also simplifies outsourcing since old states becoming public no longer pose a threat. Furthermore, eltoo eliminates the need to estimate fees ahead of time and can be utilized for other protocols such as channel factories. When combined with Schnorr signatures, eltoo facilitates the creation of large off-chain contracts with minimal on-chain footprint.However, implementing eltoo would require an increase in the safe CLTV (CheckLockTimeVerify) delta requirements. Currently, HTLCs can be timed out immediately on the settlement transaction. With eltoo, when a downstream channel is closed on-chain, it must wait for the CSV (CheckSequenceVerify) timeout on the update transaction before locking in the timed-out HTLC. This means that the CLTV delta needs to be greater than the CSV timeout, plus some extra time. However, it is believed that the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.Overall, eltoo presents a promising update mechanism for off-chain protocols like the Lightning Network. It offers improvements in terms of simplicity, flexibility in fee management, and potential use in various applications beyond Lightning. More details about the eltoo proposal can be found in the paper linked at [2]. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_Adding-xpub-field-to-PSBT-to-make-multisig-more-secure.xml b/static/bitcoin-dev/May_2019/combined_Adding-xpub-field-to-PSBT-to-make-multisig-more-secure.xml index b173f71e19..924669a807 100644 --- a/static/bitcoin-dev/May_2019/combined_Adding-xpub-field-to-PSBT-to-make-multisig-more-secure.xml +++ b/static/bitcoin-dev/May_2019/combined_Adding-xpub-field-to-PSBT-to-make-multisig-more-secure.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Adding xpub field to PSBT to make multisig more secure - 2023-08-02T00:44:57.994125+00:00 - - Dmitry Petukhov 2019-05-09 17:08:47+00:00 - - - jan matejek 2019-05-08 07:54:53+00:00 - - - Dmitry Petukhov 2019-05-07 13:40:34+00:00 - - - Stepan Snigirev 2019-05-07 09:23:44+00:00 - - - Peter D. Gray 2019-05-03 13:29:45+00:00 - - - Andrew Chow 2019-05-01 16:57:38+00:00 - - - Stepan Snigirev 2019-04-26 15:21:06+00:00 - + 2025-09-26T15:40:44.022518+00:00 + python-feedgen + + + [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure Stepan Snigirev + 2019-04-26T15:21:00.000Z + + + Andrew Chow + 2019-05-01T16:57:00.000Z + + + Peter D. Gray + 2019-05-03T13:29:00.000Z + + + Stepan Snigirev + 2019-05-07T09:23:00.000Z + + + Dmitry Petukhov + 2019-05-07T13:40:00.000Z + + + jan matejek + 2019-05-08T07:54:00.000Z + + + Dmitry Petukhov + 2019-05-09T17:08:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Adding xpub field to PSBT to make multisig more secure - 2023-08-02T00:44:57.994125+00:00 + 2025-09-26T15:40:44.023480+00:00 - In a bitcoin-dev thread, the author proposes a solution to aggregate spending from different wallets into one transaction for efficiency and convenience. They suggest using stateful signers that store trusted xpubs to apply it to stateless hardware wallets. This would allow distinguishing trusted outputs even if the inputs are not derived from the same set of xpubs. However, this idea is seen as an attempt at a different and broader problem.Dmitry Petukhov suggests in the thread that a hardware wallet can sign a message consisting of xpubs of participants and auxiliary text during the setup phase. However, this method seems overly complicated and its purpose is unclear. The thread discusses the threat model and suggests that each individual multisig signature signs the set of signers. This ensures that if an attacker provides bad xpubs, the signature won't be valid for the given multisig output. The weak spot in the process is generating the receiving address, but this issue is unrelated to PSBT.To safely show an incoming address to the user, PSBT-signing devices still need to store the xpubs of their co-signers. However, hardware wallets need to be stateless for easy wiping and recovering. To solve this, the user can verify a multisignature address or xpub on the screens of all devices during the setup phase. Hardware wallets can then mark outputs that use the pubkeys derived from 'verified' xpubs as 'trusted' outputs. This allows distinguishing trusted outputs even if the inputs are not all derived from the same set of xpubs.The proposal suggests sharing xpubs in the global section of the file, with a restriction that they must only include the hardened prefix of the path. The existing bip32 derivation path included in individual inputs and outputs should be merged in as needed. However, it is not necessary to restrict xpubs to have only hardened derivation. PSBT-signing devices still need to store the xpubs of their co-signers for safe verification of incoming addresses. The proposal also suggests using the extension serialization format without any encodings for PSBT, and keeping the prefix that defines if the key is used for testnet or mainnet may also be useful.Stepan Snigirev raises concerns about the possibility of user funds being stolen in multisignature setups using the current specifications for PSBT. An attacker could replace half of the keys in the change address with their own keys and still get the transaction signed. To fix this issue, Snigirev suggests adding an xpub field to the inputs and outputs metadata so that signers can verify that the same xpubs are used for public keys in inputs and outputs. He proposes two new key-value pairs to be added to PSBT: `PSBT_IN_BIP32_XPUB` and `PSBT_OUT_BIP32_XPUB`. This would ensure that the output is indeed a change. Snigirev also suggests reviewing the communication protocols of existing hardware and multisignature wallets to see if there are other solutions to this issue. If the proposal is accepted, he plans to prepare a pull request to the bip. 2019-05-09T17:08:47+00:00 + In a bitcoin-dev thread, the author proposes a solution to aggregate spending from different wallets into one transaction for efficiency and convenience. They suggest using stateful signers that store trusted xpubs to apply it to stateless hardware wallets. This would allow distinguishing trusted outputs even if the inputs are not derived from the same set of xpubs. However, this idea is seen as an attempt at a different and broader problem.Dmitry Petukhov suggests in the thread that a hardware wallet can sign a message consisting of xpubs of participants and auxiliary text during the setup phase. However, this method seems overly complicated and its purpose is unclear. The thread discusses the threat model and suggests that each individual multisig signature signs the set of signers. This ensures that if an attacker provides bad xpubs, the signature won't be valid for the given multisig output. The weak spot in the process is generating the receiving address, but this issue is unrelated to PSBT.To safely show an incoming address to the user, PSBT-signing devices still need to store the xpubs of their co-signers. However, hardware wallets need to be stateless for easy wiping and recovering. To solve this, the user can verify a multisignature address or xpub on the screens of all devices during the setup phase. Hardware wallets can then mark outputs that use the pubkeys derived from 'verified' xpubs as 'trusted' outputs. This allows distinguishing trusted outputs even if the inputs are not all derived from the same set of xpubs.The proposal suggests sharing xpubs in the global section of the file, with a restriction that they must only include the hardened prefix of the path. The existing bip32 derivation path included in individual inputs and outputs should be merged in as needed. However, it is not necessary to restrict xpubs to have only hardened derivation. PSBT-signing devices still need to store the xpubs of their co-signers for safe verification of incoming addresses. The proposal also suggests using the extension serialization format without any encodings for PSBT, and keeping the prefix that defines if the key is used for testnet or mainnet may also be useful.Stepan Snigirev raises concerns about the possibility of user funds being stolen in multisignature setups using the current specifications for PSBT. An attacker could replace half of the keys in the change address with their own keys and still get the transaction signed. To fix this issue, Snigirev suggests adding an xpub field to the inputs and outputs metadata so that signers can verify that the same xpubs are used for public keys in inputs and outputs. He proposes two new key-value pairs to be added to PSBT: `PSBT_IN_BIP32_XPUB` and `PSBT_OUT_BIP32_XPUB`. This would ensure that the output is indeed a change. Snigirev also suggests reviewing the communication protocols of existing hardware and multisignature wallets to see if there are other solutions to this issue. If the proposal is accepted, he plans to prepare a pull request to the bip. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_An-alternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml b/static/bitcoin-dev/May_2019/combined_An-alternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml index 72269516df..d738c82dce 100644 --- a/static/bitcoin-dev/May_2019/combined_An-alternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml +++ b/static/bitcoin-dev/May_2019/combined_An-alternative-OP-CAT-OP-CHECKSIGFROMSTACK.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - An alternative: OP_CAT & OP_CHECKSIGFROMSTACK - 2023-08-02T00:53:10.913427+00:00 - - Tamas Blummer 2019-06-13 08:14:02+00:00 - - - Russell O'Connor 2019-05-29 06:49:29+00:00 - - - ZmnSCPxj 2019-05-28 03:41:58+00:00 - - - Anthony Towns 2019-05-27 07:21:28+00:00 - - - Russell O'Connor 2019-05-25 12:52:44+00:00 - - - Jeremy 2019-05-25 01:08:00+00:00 - - - Russell O'Connor 2019-05-24 23:07:28+00:00 - - - Jeremy 2019-05-24 20:51:21+00:00 - - - Russell O'Connor 2019-05-24 15:10:21+00:00 - - - ZmnSCPxj 2019-05-24 04:15:45+00:00 - - - ZmnSCPxj 2019-05-24 03:51:13+00:00 - - - Russell O'Connor 2019-05-23 22:06:45+00:00 - - - Russell O'Connor 2019-05-23 22:00:59+00:00 - - - Jimmy Song 2019-05-23 17:36:19+00:00 - - - ZmnSCPxj 2019-05-23 16:59:15+00:00 - - - Russell O'Connor 2019-05-22 21:01:21+00:00 - + 2025-09-26T15:40:31.452613+00:00 + python-feedgen + + + [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK Russell O'Connor + 2019-05-22T21:01:00.000Z + + + ZmnSCPxj + 2019-05-23T16:59:00.000Z + + + Jimmy Song + 2019-05-23T17:36:00.000Z + + + Russell O'Connor + 2019-05-23T22:00:00.000Z + + + Russell O'Connor + 2019-05-23T22:06:00.000Z + + + ZmnSCPxj + 2019-05-24T03:51:00.000Z + + + ZmnSCPxj + 2019-05-24T04:15:00.000Z + + + Russell O'Connor + 2019-05-24T15:10:00.000Z + + + Jeremy + 2019-05-24T20:51:00.000Z + + + Russell O'Connor + 2019-05-24T23:07:00.000Z + + + Jeremy + 2019-05-25T01:08:00.000Z + + + Russell O'Connor + 2019-05-25T12:52:00.000Z + + + Anthony Towns + 2019-05-27T07:21:00.000Z + + + ZmnSCPxj + 2019-05-28T03:41:00.000Z + + + Russell O'Connor + 2019-05-29T06:49:00.000Z + + + Tamas Blummer + 2019-06-13T08:14:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - An alternative: OP_CAT & OP_CHECKSIGFROMSTACK - 2023-08-02T00:53:10.913427+00:00 + 2025-09-26T15:40:31.454328+00:00 - Another aspect discussed in the proposal is the implementation of oracle-less difficulty contracts without the need for CISC type OP_WORKVERIFY. An example contract is provided, which involves a European digital call option on target difficulty after maturity with a 10-block notice period. The contract can be soft forked by redefining OP_NOP as a prefix (OP_EXTENSION). This demonstrates the flexibility of Bitcoin Script and the potential for creating complex smart contracts.The proposal also suggests adding OP_CAT and OP_CHECKSIGFROMSTACKVERIFY to enable flexible programmability in Bitcoin Script. It argues that some parts of Script have been unsuccessful and not useful in practice, and that a subset of concatenation, arithmetic, CHECKDATASIG, transaction reflection, and/or covenants could create particularly useful programs. The proposal includes a debate on simulating an ANYPREVOUT signature with a data signature and the use of the "CHECK_SIG_MSG_VERIFY" opcode for simplicity and generic programming.Anthony Towns suggests that the infrequent use of certain Script features may be due to a lack of tools rather than a lack of demand. He advocates for implementing a pure functional language that can be compiled down to SCRIPT and leveraged with OP_CHECKSIGFROMSTACK. This would require a proof-of-existence compiler targeting Liquid/Elements SCRIPT. Towns also mentions his Smart Contracts Unchained technique as a way to implement Simplicity on top of Bitcoin, using a user-selected federation to enforce Simplicity execution.The effectiveness of Bitcoin Script has been questioned due to the disabling of certain opcodes and consensus bugs. Russell O'Connor proposes implementing OP_CAT and OP_CHECKSIGFROMSTACKVERIFY as a solution. The proposal suggests that CAT's usefulness is acknowledged, but there is uncertainty about CHECKSIG, which takes the message from the stack. A concrete example of transaction introspection using simulated SIGHASH_ANYPREVOUT is provided.The discussion also revolves around the OP_COSHV opcode and its potential replacement with transaction reflection primitives like OP_NUMINPUTS and OP_PUSHOUTPUTSHASH. The proposal for OP_CHECK_TXID_TEMPLATE_DATA is debated, allowing a variable number of inputs and fixing potential bugs related to TXID malleability. The idea of implementing an alternative CISC-style taproot leaf type is suggested. The benefits and drawbacks of OP_CHECKSIGFROMSTACKVERIFY are discussed, with concerns raised about its potential recursive covenant and negative interaction with future opcodes.In summary, the proposal suggests introducing new opcodes, OP_CAT and OP_CHECKSIGFROMSTACKVERIFY, to enhance the functionality and flexibility of Bitcoin Script. These opcodes can enable various applications and improve the programmability of Bitcoin. However, there are ongoing debates and discussions regarding the implementation and potential limitations of these opcodes, as well as the overall effectiveness of Bitcoin Script in real-world use cases. 2019-06-13T08:14:02+00:00 + Another aspect discussed in the proposal is the implementation of oracle-less difficulty contracts without the need for CISC type OP_WORKVERIFY. An example contract is provided, which involves a European digital call option on target difficulty after maturity with a 10-block notice period. The contract can be soft forked by redefining OP_NOP as a prefix (OP_EXTENSION). This demonstrates the flexibility of Bitcoin Script and the potential for creating complex smart contracts.The proposal also suggests adding OP_CAT and OP_CHECKSIGFROMSTACKVERIFY to enable flexible programmability in Bitcoin Script. It argues that some parts of Script have been unsuccessful and not useful in practice, and that a subset of concatenation, arithmetic, CHECKDATASIG, transaction reflection, and/or covenants could create particularly useful programs. The proposal includes a debate on simulating an ANYPREVOUT signature with a data signature and the use of the "CHECK_SIG_MSG_VERIFY" opcode for simplicity and generic programming.Anthony Towns suggests that the infrequent use of certain Script features may be due to a lack of tools rather than a lack of demand. He advocates for implementing a pure functional language that can be compiled down to SCRIPT and leveraged with OP_CHECKSIGFROMSTACK. This would require a proof-of-existence compiler targeting Liquid/Elements SCRIPT. Towns also mentions his Smart Contracts Unchained technique as a way to implement Simplicity on top of Bitcoin, using a user-selected federation to enforce Simplicity execution.The effectiveness of Bitcoin Script has been questioned due to the disabling of certain opcodes and consensus bugs. Russell O'Connor proposes implementing OP_CAT and OP_CHECKSIGFROMSTACKVERIFY as a solution. The proposal suggests that CAT's usefulness is acknowledged, but there is uncertainty about CHECKSIG, which takes the message from the stack. A concrete example of transaction introspection using simulated SIGHASH_ANYPREVOUT is provided.The discussion also revolves around the OP_COSHV opcode and its potential replacement with transaction reflection primitives like OP_NUMINPUTS and OP_PUSHOUTPUTSHASH. The proposal for OP_CHECK_TXID_TEMPLATE_DATA is debated, allowing a variable number of inputs and fixing potential bugs related to TXID malleability. The idea of implementing an alternative CISC-style taproot leaf type is suggested. The benefits and drawbacks of OP_CHECKSIGFROMSTACKVERIFY are discussed, with concerns raised about its potential recursive covenant and negative interaction with future opcodes.In summary, the proposal suggests introducing new opcodes, OP_CAT and OP_CHECKSIGFROMSTACKVERIFY, to enhance the functionality and flexibility of Bitcoin Script. These opcodes can enable various applications and improve the programmability of Bitcoin. However, there are ongoing debates and discussions regarding the implementation and potential limitations of these opcodes, as well as the overall effectiveness of Bitcoin Script in real-world use cases. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_Congestion-Control-via-OP-CHECKOUTPUTSHASHVERIFY-proposal.xml b/static/bitcoin-dev/May_2019/combined_Congestion-Control-via-OP-CHECKOUTPUTSHASHVERIFY-proposal.xml index e7c24ad49c..09518c729e 100644 --- a/static/bitcoin-dev/May_2019/combined_Congestion-Control-via-OP-CHECKOUTPUTSHASHVERIFY-proposal.xml +++ b/static/bitcoin-dev/May_2019/combined_Congestion-Control-via-OP-CHECKOUTPUTSHASHVERIFY-proposal.xml @@ -1,47 +1,119 @@ - + 2 Combined summary - Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal - 2023-08-02T00:52:05.530637+00:00 - - ZmnSCPxj 2019-05-25 03:56:22+00:00 - - - Jeremy 2019-05-24 21:15:07+00:00 - - - Jeremy 2019-05-24 20:36:03+00:00 - - - Johnson Lau 2019-05-24 19:12:32+00:00 - - - ZmnSCPxj 2019-05-23 03:45:39+00:00 - - - Anthony Towns 2019-05-22 20:49:11+00:00 - - - Jeremy 2019-05-22 08:10:23+00:00 - - - ZmnSCPxj 2019-05-22 06:04:27+00:00 - - - Jeremy 2019-05-22 05:11:55+00:00 - - - ZmnSCPxj 2019-05-22 02:51:52+00:00 - - - Jeremy 2019-05-22 01:47:11+00:00 - - - Matt Corallo 2019-05-21 19:41:22+00:00 - - - Jeremy 2019-05-20 20:58:03+00:00 - + 2025-09-26T15:40:27.206181+00:00 + python-feedgen + + + [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal Jeremy + 2019-05-20T20:58:00.000Z + + + Matt Corallo + 2019-05-21T19:41:00.000Z + + + Jeremy + 2019-05-22T01:47:00.000Z + + + ZmnSCPxj + 2019-05-22T02:51:00.000Z + + + Jeremy + 2019-05-22T05:11:00.000Z + + + ZmnSCPxj + 2019-05-22T06:04:00.000Z + + + Jeremy + 2019-05-22T08:10:00.000Z + + + Anthony Towns + 2019-05-22T20:49:00.000Z + + + ZmnSCPxj + 2019-05-23T03:45:00.000Z + + + [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party Tamas Blummer + 2019-05-23T17:42:00.000Z + + + Jorge Timón + 2019-05-23T19:03:00.000Z + + + Nathan Cook + 2019-05-23T19:05:00.000Z + + + Tamas Blummer + 2019-05-23T19:10:00.000Z + + + Tamas Blummer + 2019-05-23T19:18:00.000Z + + + Nathan Cook + 2019-05-23T19:21:00.000Z + + + Tamas Blummer + 2019-05-23T19:45:00.000Z + + + Pieter Wuille + 2019-05-23T19:45:00.000Z + + + Tamas Blummer + 2019-05-23T19:54:00.000Z + + + Nathan Cook + 2019-05-23T20:07:00.000Z + + + Tamas Blummer + 2019-05-23T20:26:00.000Z + + + Johnson Lau + 2019-05-24T08:15:00.000Z + + + Natanael + 2019-05-24T08:36:00.000Z + + + Tamas Blummer + 2019-05-24T16:23:00.000Z + + + [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal Johnson Lau + 2019-05-24T19:12:00.000Z + + + Jeremy + 2019-05-24T20:36:00.000Z + + + Jeremy + 2019-05-24T21:15:00.000Z + + + ZmnSCPxj + 2019-05-25T03:56:00.000Z + + @@ -55,13 +127,13 @@ - python-feedgen + 2 Combined summary - Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal - 2023-08-02T00:52:05.531642+00:00 + 2025-09-26T15:40:27.209202+00:00 - Jeremy Rubin has proposed a new opcode draft called OP_CHECKOUTPUTSHASHVERIFY, which aims to provide easy-to-use and trustless congestion control techniques through a rudimentary form of covenant. This opcode allows Bitcoin users to confirm payments to multiple users in a single transaction without creating the UTXO on-chain immediately. The draft covers this use case in detail, along with a few other use cases.A reference implementation of the consensus changes and tests can be found on GitHub, along with the BIP draft. Matt Corallo agrees that covenants should be implemented but suggests a more comprehensive scripting system that offers additional features beyond just congestion control. He refers to these as 'certified checks' and believes they resemble pre-signed scripts for multisig transactions, without requiring interactive setup. Corallo emphasizes the importance of flexibility and versioning in the design, making it easier to add more features in the future.The proposed BIP aims to deploy the opcode change simultaneously with Taproot as an OPSUCCESS. However, it can also be deployed separately if necessary. The changes required for the new opcode amount to approximately 74 lines of code built upon sipa's Taproot reference implementation.Overall, Jeremy Rubin's draft proposes an opcode that enables congestion control and provides a limited form of covenant for Bitcoin transactions. Matt Corallo supports the concept but suggests a more flexible solution. The BIP draft and the reference implementation can be found on GitHub, offering further details and testing capabilities for interested parties. 2019-05-25T03:56:22+00:00 + Jeremy Rubin has proposed a new opcode draft called OP_CHECKOUTPUTSHASHVERIFY, which aims to provide easy-to-use and trustless congestion control techniques through a rudimentary form of covenant. This opcode allows Bitcoin users to confirm payments to multiple users in a single transaction without creating the UTXO on-chain immediately. The draft covers this use case in detail, along with a few other use cases.A reference implementation of the consensus changes and tests can be found on GitHub, along with the BIP draft. Matt Corallo agrees that covenants should be implemented but suggests a more comprehensive scripting system that offers additional features beyond just congestion control. He refers to these as 'certified checks' and believes they resemble pre-signed scripts for multisig transactions, without requiring interactive setup. Corallo emphasizes the importance of flexibility and versioning in the design, making it easier to add more features in the future.The proposed BIP aims to deploy the opcode change simultaneously with Taproot as an OPSUCCESS. However, it can also be deployed separately if necessary. The changes required for the new opcode amount to approximately 74 lines of code built upon sipa's Taproot reference implementation.Overall, Jeremy Rubin's draft proposes an opcode that enables congestion control and provides a limited form of covenant for Bitcoin transactions. Matt Corallo supports the concept but suggests a more flexible solution. The BIP draft and the reference implementation can be found on GitHub, offering further details and testing capabilities for interested parties. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_IBLT-Bitcoin.xml b/static/bitcoin-dev/May_2019/combined_IBLT-Bitcoin.xml index e69c91a15a..aef9d9ff54 100644 --- a/static/bitcoin-dev/May_2019/combined_IBLT-Bitcoin.xml +++ b/static/bitcoin-dev/May_2019/combined_IBLT-Bitcoin.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - IBLT & Bitcoin - 2023-08-02T00:51:25.862132+00:00 - - ZmnSCPxj 2019-05-13 23:39:51+00:00 - - - Christopher DeLucia 2019-05-12 01:35:38+00:00 - + 2025-09-26T15:40:35.658088+00:00 + python-feedgen + + + [bitcoin-dev] IBLT & Bitcoin Christopher DeLucia + 2019-05-12T01:35:00.000Z + + + ZmnSCPxj + 2019-05-13T23:39:00.000Z + + - python-feedgen + 2 Combined summary - IBLT & Bitcoin - 2023-08-02T00:51:25.862132+00:00 + 2025-09-26T15:40:35.658649+00:00 - ZmnSCPxj, a member of the Bitcoin community, has shared a proposal for improved transaction relay on GitHub. The proposal utilizes Bose-Chaudhuri-Hocquenghem codes for set reconciliation, aiming to enhance the efficiency of transaction processing. This development could potentially have significant implications for the Bitcoin network.Furthermore, Christopher DeLucia, an individual who produced a paper in 2017 on Invertible Bloom Lookup Tables (IBLT) applications and Bitcoin, recently shared his work with the Bitcoin-dev mailing list. Although the paper referenced research conducted by Gavin Andresen and Rusty Russell, it is important to note that it was not peer-reviewed and was solely created for a class assignment during DeLucia's time in college.DeLucia openly acknowledges that he has not revisited the paper or explored Bitcoin since 2017. However, while cleaning out old documents, he stumbled upon it and decided to share it with the Bitcoin community in case it could provide any valuable insights or contribute to ongoing discussions surrounding IBLT applications in the context of Bitcoin.In order to facilitate the dissemination of his paper, DeLucia provided a non-text attachment in PDF format, ensuring that interested individuals can access and review his findings. This gesture highlights the collaborative nature of the Bitcoin community, as members continuously strive to share knowledge and ideas that may further the advancement of the technology.Overall, these recent developments within the Bitcoin community showcase the dedication and commitment of its members to explore innovative approaches, such as the use of Bose-Chaudhuri-Hocquenghem codes and IBLT applications, to improve transaction relay and optimize the functioning of the network. Through open collaboration and information sharing, the Bitcoin ecosystem continues to evolve and progress towards achieving enhanced scalability and efficiency. 2019-05-13T23:39:51+00:00 + ZmnSCPxj, a member of the Bitcoin community, has shared a proposal for improved transaction relay on GitHub. The proposal utilizes Bose-Chaudhuri-Hocquenghem codes for set reconciliation, aiming to enhance the efficiency of transaction processing. This development could potentially have significant implications for the Bitcoin network.Furthermore, Christopher DeLucia, an individual who produced a paper in 2017 on Invertible Bloom Lookup Tables (IBLT) applications and Bitcoin, recently shared his work with the Bitcoin-dev mailing list. Although the paper referenced research conducted by Gavin Andresen and Rusty Russell, it is important to note that it was not peer-reviewed and was solely created for a class assignment during DeLucia's time in college.DeLucia openly acknowledges that he has not revisited the paper or explored Bitcoin since 2017. However, while cleaning out old documents, he stumbled upon it and decided to share it with the Bitcoin community in case it could provide any valuable insights or contribute to ongoing discussions surrounding IBLT applications in the context of Bitcoin.In order to facilitate the dissemination of his paper, DeLucia provided a non-text attachment in PDF format, ensuring that interested individuals can access and review his findings. This gesture highlights the collaborative nature of the Bitcoin community, as members continuously strive to share knowledge and ideas that may further the advancement of the technology.Overall, these recent developments within the Bitcoin community showcase the dedication and commitment of its members to explore innovative approaches, such as the use of Bose-Chaudhuri-Hocquenghem codes and IBLT applications, to improve transaction relay and optimize the functioning of the network. Through open collaboration and information sharing, the Bitcoin ecosystem continues to evolve and progress towards achieving enhanced scalability and efficiency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_IsStandard.xml b/static/bitcoin-dev/May_2019/combined_IsStandard.xml index c24cbf3c6f..817c6fa414 100644 --- a/static/bitcoin-dev/May_2019/combined_IsStandard.xml +++ b/static/bitcoin-dev/May_2019/combined_IsStandard.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - IsStandard - 2023-08-02T00:45:44.650088+00:00 - - Aymeric Vitte 2019-05-03 09:51:25+00:00 - - - Pieter Wuille 2019-05-02 23:35:06+00:00 - - - James Prestwich 2019-05-02 23:33:09+00:00 - - - Aymeric Vitte 2019-05-02 10:01:54+00:00 - - - ZmnSCPxj 2019-05-02 00:10:37+00:00 - - - Aymeric Vitte 2019-04-30 09:43:27+00:00 - - - ZmnSCPxj 2019-04-30 04:29:18+00:00 - - - Marco Falke 2019-04-29 17:27:29+00:00 - - - Aymeric Vitte 2019-04-29 09:30:39+00:00 - - - Luke Dashjr 2019-04-29 03:01:41+00:00 - - - ZmnSCPxj 2019-04-29 01:46:35+00:00 - - - Aymeric Vitte 2019-04-27 10:37:29+00:00 - + 2025-09-26T15:40:25.087300+00:00 + python-feedgen + + + [bitcoin-dev] IsStandard Aymeric Vitte + 2019-04-27T10:37:00.000Z + + + ZmnSCPxj + 2019-04-29T01:46:00.000Z + + + Luke Dashjr + 2019-04-29T03:01:00.000Z + + + Aymeric Vitte + 2019-04-29T09:30:00.000Z + + + Marco Falke + 2019-04-29T17:27:00.000Z + + + ZmnSCPxj + 2019-04-30T04:29:00.000Z + + + Aymeric Vitte + 2019-04-30T09:43:00.000Z + + + ZmnSCPxj + 2019-05-02T00:10:00.000Z + + + Aymeric Vitte + 2019-05-02T10:01:00.000Z + + + James Prestwich + 2019-05-02T23:33:00.000Z + + + Pieter Wuille + 2019-05-02T23:35:00.000Z + + + Aymeric Vitte + 2019-05-03T09:51:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - IsStandard - 2023-08-02T00:45:44.650088+00:00 + 2025-09-26T15:40:25.088678+00:00 - In a recent bitcoin-dev discussion, the standardness of bitcoin scripting was brought into question. Contributors discussed whether non-usual transactions would be relayed by nodes and how to determine what nodes will accept. It was agreed upon that any custom script can be wrapped in P2SH and P2WSH and it will be propagated. However, P2PKH and P2WPKH cannot have custom scripts. Once a claim on a modified x-of-3 is propagated, the redeemScript becomes known and someone can attempt to RBF with a modified witness stack or scriptSig to claim the UTXO. The standardness of Bitcoin Cash (BCH) transactions is still unclear. SHA bounties were also discussed, which can be propagated if they are wrapped in P2SH or P2WSH. However, the redeemScript must be published by the creator or bribed a miner if the transaction is not time-sensitive.Pieter clarified that all spends of P2SH/P2WSH are standard, except for non-push operations in the scriptSig, resource limitations, protections against known attack vectors, and usage of unconditionally spendable constructions intended for future extensions. He also confirmed that redeem scripts for the sha bounties are in op_return.James Prestwich provided a reference for default TX_NONSTANDARD policies in v0.18, but noted that documenting standardness is challenging as it varies from version to version. His reference only applied to v0.18 and may already be outdated.The conversation highlighted that P2PKH, P2WPKH, P2SH, and P2WSH are recognized as templates by most current nodes and are expected to be propagated by a majority of nodes. Any custom script can be wrapped in P2SH and P2WSH and will be propagated, as these templates hide the details of the custom script. However, filtering based on the custom script is not possible. For BCH, it was noted that P2PKH and P2WPKH cannot have custom scripts, but the standardness of other transactions remains unclear.ZmnSCPxj explained that nodes can have any policy for propagating transactions, but transactions that do not pay out to P2PKH, P2WPKH, P2SH, or P2WSH are unlikely to be propagated by most nodes. However, coordination with miners is still possible to get these non-standard transactions mined. The standardness of Bitcoin transactions and scripts is not described in a single document and may change over time or across different implementations.Luke Dashjr emphasized that IsStandard, which implements a node's policy, should not be given much attention when defining new standards. Instead, he recommended focusing on documenting actual standards rather than IsStandard beyond the code.In conclusion, the standardness of Bitcoin transactions varies from version to version and across different implementations. P2PKH, P2WPKH, P2SH, and P2WSH are generally recognized as standard templates, but anything that does not fit into these templates is less likely to be propagated by nodes. However, coordination with miners can still allow non-standard transactions to be mined. It is important to document actual standards rather than relying solely on IsStandard function in the code. 2019-05-03T09:51:25+00:00 + In a recent bitcoin-dev discussion, the standardness of bitcoin scripting was brought into question. Contributors discussed whether non-usual transactions would be relayed by nodes and how to determine what nodes will accept. It was agreed upon that any custom script can be wrapped in P2SH and P2WSH and it will be propagated. However, P2PKH and P2WPKH cannot have custom scripts. Once a claim on a modified x-of-3 is propagated, the redeemScript becomes known and someone can attempt to RBF with a modified witness stack or scriptSig to claim the UTXO. The standardness of Bitcoin Cash (BCH) transactions is still unclear. SHA bounties were also discussed, which can be propagated if they are wrapped in P2SH or P2WSH. However, the redeemScript must be published by the creator or bribed a miner if the transaction is not time-sensitive.Pieter clarified that all spends of P2SH/P2WSH are standard, except for non-push operations in the scriptSig, resource limitations, protections against known attack vectors, and usage of unconditionally spendable constructions intended for future extensions. He also confirmed that redeem scripts for the sha bounties are in op_return.James Prestwich provided a reference for default TX_NONSTANDARD policies in v0.18, but noted that documenting standardness is challenging as it varies from version to version. His reference only applied to v0.18 and may already be outdated.The conversation highlighted that P2PKH, P2WPKH, P2SH, and P2WSH are recognized as templates by most current nodes and are expected to be propagated by a majority of nodes. Any custom script can be wrapped in P2SH and P2WSH and will be propagated, as these templates hide the details of the custom script. However, filtering based on the custom script is not possible. For BCH, it was noted that P2PKH and P2WPKH cannot have custom scripts, but the standardness of other transactions remains unclear.ZmnSCPxj explained that nodes can have any policy for propagating transactions, but transactions that do not pay out to P2PKH, P2WPKH, P2SH, or P2WSH are unlikely to be propagated by most nodes. However, coordination with miners is still possible to get these non-standard transactions mined. The standardness of Bitcoin transactions and scripts is not described in a single document and may change over time or across different implementations.Luke Dashjr emphasized that IsStandard, which implements a node's policy, should not be given much attention when defining new standards. Instead, he recommended focusing on documenting actual standards rather than IsStandard beyond the code.In conclusion, the standardness of Bitcoin transactions varies from version to version and across different implementations. P2PKH, P2WPKH, P2SH, and P2WSH are generally recognized as standard templates, but anything that does not fit into these templates is less likely to be propagated by nodes. However, coordination with miners can still allow non-standard transactions to be mined. It is important to document actual standards rather than relying solely on IsStandard function in the code. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_OP-DIFFICULTY-to-enable-difficulty-hedges-bets-without-an-oracle-and-3rd-party-.xml b/static/bitcoin-dev/May_2019/combined_OP-DIFFICULTY-to-enable-difficulty-hedges-bets-without-an-oracle-and-3rd-party-.xml index a63cf67b57..f13b84a65b 100644 --- a/static/bitcoin-dev/May_2019/combined_OP-DIFFICULTY-to-enable-difficulty-hedges-bets-without-an-oracle-and-3rd-party-.xml +++ b/static/bitcoin-dev/May_2019/combined_OP-DIFFICULTY-to-enable-difficulty-hedges-bets-without-an-oracle-and-3rd-party-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party. - 2023-08-02T00:54:46.994984+00:00 + 2025-09-26T15:40:33.568955+00:00 + python-feedgen Tamas Blummer 2019-05-24 16:23:38+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party. - 2023-08-02T00:54:46.994984+00:00 + 2025-09-26T15:40:33.569130+00:00 - Tamas Blummer, a blockchain developer, has proposed a new opcode called OP_DIFFICULTY that aims to provide a native solution to hedge risks in Bitcoin mining. The proposed transaction would only be valid after the difficulty-adjusted block in the future. It would involve a multi-sig escrow from participants in the bet, with the winner broadcasting the result. This proposal aligns with Bitcoin's aim to avoid third-party intermediaries and addresses the significant economic interest of the Bitcoin economy.However, there are concerns about the implementation of this proposal. Pieter Wuille has raised concerns about potential complications in implementing mempools and determining the validity of unconfirmed transactions if the difficulty can be directly observed by the script language. Tamas Blummer acknowledges these concerns and suggests that similar constructions are needed for observing block difficulty as for observing block time/height.Nathan Cook proposes an alternative approach using OP_CHECKBLOCKATHEIGHT, but Tamas points out that this opcode fetches the block hash rather than the content of the header, making it unsuitable for comparing difficulty levels. Despite these concerns and alternative suggestions, Tamas Blummer believes that his proposal offers a better solution than traditional commodity markets' futures and options.The current method of using nLocktime denominated in block height to hedge risks in Bitcoin mining has limitations. Blummer argues that a native solution within Bitcoin may be more efficient. The proposed OP_DIFFICULTY opcode would put the value of difficulty onto the stack for the block the transaction is included in. By comparing this value with a strike, the transaction can be executed without counterparty risk and without relying on an oracle to settle the bet.Blummer plans to draft a BIP (Bitcoin Improvement Proposal) for the OP_DIFFICULTY opcode and invites others to provide feedback or contribute to its further development. 2019-05-24T16:23:38+00:00 + Tamas Blummer, a blockchain developer, has proposed a new opcode called OP_DIFFICULTY that aims to provide a native solution to hedge risks in Bitcoin mining. The proposed transaction would only be valid after the difficulty-adjusted block in the future. It would involve a multi-sig escrow from participants in the bet, with the winner broadcasting the result. This proposal aligns with Bitcoin's aim to avoid third-party intermediaries and addresses the significant economic interest of the Bitcoin economy.However, there are concerns about the implementation of this proposal. Pieter Wuille has raised concerns about potential complications in implementing mempools and determining the validity of unconfirmed transactions if the difficulty can be directly observed by the script language. Tamas Blummer acknowledges these concerns and suggests that similar constructions are needed for observing block difficulty as for observing block time/height.Nathan Cook proposes an alternative approach using OP_CHECKBLOCKATHEIGHT, but Tamas points out that this opcode fetches the block hash rather than the content of the header, making it unsuitable for comparing difficulty levels. Despite these concerns and alternative suggestions, Tamas Blummer believes that his proposal offers a better solution than traditional commodity markets' futures and options.The current method of using nLocktime denominated in block height to hedge risks in Bitcoin mining has limitations. Blummer argues that a native solution within Bitcoin may be more efficient. The proposed OP_DIFFICULTY opcode would put the value of difficulty onto the stack for the block the transaction is included in. By comparing this value with a strike, the transaction can be executed without counterparty risk and without relying on an oracle to settle the bet.Blummer plans to draft a BIP (Bitcoin Improvement Proposal) for the OP_DIFFICULTY opcode and invites others to provide feedback or contribute to its further development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_SIGHASH-ANYPREVOUT-proposal.xml b/static/bitcoin-dev/May_2019/combined_SIGHASH-ANYPREVOUT-proposal.xml index 479bf955e7..cc9491f217 100644 --- a/static/bitcoin-dev/May_2019/combined_SIGHASH-ANYPREVOUT-proposal.xml +++ b/static/bitcoin-dev/May_2019/combined_SIGHASH-ANYPREVOUT-proposal.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - SIGHASH_ANYPREVOUT proposal - 2023-08-02T00:51:13.043485+00:00 - - Rusty Russell 2019-05-27 01:26:01+00:00 - - - Anthony Towns 2019-05-22 20:11:31+00:00 - - - Rusty Russell 2019-05-22 02:47:31+00:00 - - - Anthony Towns 2019-05-10 20:38:04+00:00 - + 2025-09-26T15:40:39.836360+00:00 + python-feedgen + + + [bitcoin-dev] SIGHASH_ANYPREVOUT proposal Anthony Towns + 2019-05-10T20:38:00.000Z + + + Rusty Russell + 2019-05-22T02:47:00.000Z + + + Anthony Towns + 2019-05-22T20:11:00.000Z + + + Rusty Russell + 2019-05-27T01:26:00.000Z + + - python-feedgen + 2 Combined summary - SIGHASH_ANYPREVOUT proposal - 2023-08-02T00:51:13.044485+00:00 + 2025-09-26T15:40:39.837046+00:00 - Rusty Russell, a Bitcoin developer, and Anthony Towns are engaged in a discussion about the safety of ANYPREVOUT. Rusty suggests renaming it to SIGHASH_UNSAFE_ANYPREVOUT and adding a warning about its unsafe nature for general wallet usage. On the other hand, Anthony argues that if something requires a warning, it should not be included in the consensus layer and suggests finding a way to make ANYPREVOUT safe enough without scary warnings.Rusty believes that funds are safe in Bitcoin as long as they are held in a cryptographically secured UTXO and under sufficient proof of work. He theorizes that if individuals only use ANYPREVOUT to sign transactions that pay the money back to themselves, their funds will remain safe. However, Rusty's concern is sharing with an untrusted party, which he deems insecure without further complex arrangements.Rusty expresses his concerns over the risk to non-ANYPREVOUT using transactions, marking it as a bad idea but concludes that it is not the case. He also highlights the concern of accidentally using ANYPREVOUT, which he believes is unlikely since keys need to be marked now. Furthermore, he mentions the concern of using correctly but nasty gotchas, which is inherent in rebinding. However, this concern is addressed by Don't Reuse Addresses.Rusty suggests changing the bip introduction to explicitly state that "THESE SIGNATURE HASHES ARE UNSAFE FOR NORMAL WALLET USAGE" and renaming it SIGHASH_UNSAFE_ANYPREVOUT. He also expresses discomfort with the new power in Bitcoin called rebinding but insists on supporting objections with facts.Anthony Towns shares a follow-up BIP draft that enables SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. Rusty shows interest in the proposal but suggests eliminating the chaparone signature requirement. He provides four reasons why he believes the benefits of chaparones do not justify enshrining their complexity into the protocol.The author of the BIP draft expresses less confidence in ANYPREVOUT's readiness for implementation and deployment than in taproot's. The author suggests requiring an additional regular signature to accompany every ANYPREVOUT signature to limit possible negative impacts. However, they acknowledge that this assumption may not survive adversarial reality.The BIP draft and a sample implementation based on the taproot branch are available via links provided by the author. The implementation includes interesting features such as upgrading tapscript's existing opcodes for new SIGHASH methods or potentially introducing a new signature scheme or elliptic curve. Two variants of ANYPREVOUT, ANYPREVOUT and ANYPREVOUTANYSCRIPT, are described, which seem useful for eltoo. Lastly, the BIP attempts to describe the security implications of ANYPREVOUT-style signatures. 2019-05-27T01:26:01+00:00 + Rusty Russell, a Bitcoin developer, and Anthony Towns are engaged in a discussion about the safety of ANYPREVOUT. Rusty suggests renaming it to SIGHASH_UNSAFE_ANYPREVOUT and adding a warning about its unsafe nature for general wallet usage. On the other hand, Anthony argues that if something requires a warning, it should not be included in the consensus layer and suggests finding a way to make ANYPREVOUT safe enough without scary warnings.Rusty believes that funds are safe in Bitcoin as long as they are held in a cryptographically secured UTXO and under sufficient proof of work. He theorizes that if individuals only use ANYPREVOUT to sign transactions that pay the money back to themselves, their funds will remain safe. However, Rusty's concern is sharing with an untrusted party, which he deems insecure without further complex arrangements.Rusty expresses his concerns over the risk to non-ANYPREVOUT using transactions, marking it as a bad idea but concludes that it is not the case. He also highlights the concern of accidentally using ANYPREVOUT, which he believes is unlikely since keys need to be marked now. Furthermore, he mentions the concern of using correctly but nasty gotchas, which is inherent in rebinding. However, this concern is addressed by Don't Reuse Addresses.Rusty suggests changing the bip introduction to explicitly state that "THESE SIGNATURE HASHES ARE UNSAFE FOR NORMAL WALLET USAGE" and renaming it SIGHASH_UNSAFE_ANYPREVOUT. He also expresses discomfort with the new power in Bitcoin called rebinding but insists on supporting objections with facts.Anthony Towns shares a follow-up BIP draft that enables SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. Rusty shows interest in the proposal but suggests eliminating the chaparone signature requirement. He provides four reasons why he believes the benefits of chaparones do not justify enshrining their complexity into the protocol.The author of the BIP draft expresses less confidence in ANYPREVOUT's readiness for implementation and deployment than in taproot's. The author suggests requiring an additional regular signature to accompany every ANYPREVOUT signature to limit possible negative impacts. However, they acknowledge that this assumption may not survive adversarial reality.The BIP draft and a sample implementation based on the taproot branch are available via links provided by the author. The implementation includes interesting features such as upgrading tapscript's existing opcodes for new SIGHASH methods or potentially introducing a new signature scheme or elliptic curve. Two variants of ANYPREVOUT, ANYPREVOUT and ANYPREVOUTANYSCRIPT, are described, which seem useful for eltoo. Lastly, the BIP attempts to describe the security implications of ANYPREVOUT-style signatures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_Safety-of-committing-only-to-transaction-outputs.xml b/static/bitcoin-dev/May_2019/combined_Safety-of-committing-only-to-transaction-outputs.xml index b4942c8821..0c0816973a 100644 --- a/static/bitcoin-dev/May_2019/combined_Safety-of-committing-only-to-transaction-outputs.xml +++ b/static/bitcoin-dev/May_2019/combined_Safety-of-committing-only-to-transaction-outputs.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Safety of committing only to transaction outputs - 2023-08-02T00:55:06.284765+00:00 - - Johnson Lau 2019-05-25 07:53:34+00:00 - - - Jeremy 2019-05-24 20:59:03+00:00 - - - Johnson Lau 2019-05-23 20:54:01+00:00 - + 2025-09-26T15:40:37.746239+00:00 + python-feedgen + + + [bitcoin-dev] Safety of committing only to transaction outputs Johnson Lau + 2019-05-23T20:54:00.000Z + + + Jeremy + 2019-05-24T20:59:00.000Z + + + Johnson Lau + 2019-05-25T07:53:00.000Z + + - python-feedgen + 2 Combined summary - Safety of committing only to transaction outputs - 2023-08-02T00:55:06.284765+00:00 + 2025-09-26T15:40:37.746822+00:00 - Jeremy Rubin proposed several mechanisms to enhance witness replay-ability and improve safety in blockchain transactions. One of his suggestions is to salt the taproot key or taproot leaf script at the last stage of a congestion control tree. However, he acknowledged that this salt would not be effective if the address is reused. Additionally, he recommended making chaperone signatures optional, as there may be cases where they are unnecessary.Rubin also mentioned that OP_COSHV is compatible with an additional checksig operation. This compatibility allows for more flexibility in implementing security measures. Furthermore, he proposed two other mechanisms: OP_CHECKINPUTSHASHVERIFY and OP_CHECKFEEVERIFY. OP_CHECKINPUTSHASHVERIFY enables the checking of the hash of inputs to ensure they match a specific value. This mechanism has broader applications beyond witness replay-ability. On the other hand, OP_CHECKFEEVERIFY allows for an explicit commitment to the exact amount of fee, limiting replays to transactions funded with the same amount as the previous one. However, it is important to note that transactions using OP_CHECKFEEVERIFY must have all inputs and outputs set.In a separate discussion initiated by Johnson Lau, the topic revolves around enabling witnesses to commit only to transaction outputs, but not inputs. Currently, the bitcoin script system offers three options: committing to both inputs and outputs, committing to only inputs, or not committing to any input or output. However, not committing to any input or output is deemed unsafe as it allows relay/mining nodes to redirect payment to any output they choose. It also makes the witness/scriptSig easily replayable, allowing future payments to be swept immediately.To address this issue, three active proposals have been put forward: CAT and CHECKSIGFROMSTACK (CSFS), ANYPREVOUT (aka NOINPUT), and CHECKOUTPUTSHASHVERIFY (COHV). These proposals ensure that payment redirection is impossible. However, not committing to any input means that the witness can be replayed without the consent of the address owner. The ANYPREVOUT proposal aims to solve this problem by requiring a chaperone signature that commits to the input.It is worth noting that if the rationale for a chaperone signature holds, it should apply to all the proposals mentioned above. A more general approach would be to always require a "safe" signature that commits to at least one input. However, this approach interacts poorly with the unknown public key type upgrade path described in bip-tapscript, as it would require a hardfork to turn an unknown type signature into a safe signature. Nevertheless, a new leaf version could be used for every new sighash type introduced to establish a new definition for a "safe sig". Additionally, customized sighash policies could be implemented with CAT/CSFS. 2019-05-25T07:53:34+00:00 + Jeremy Rubin proposed several mechanisms to enhance witness replay-ability and improve safety in blockchain transactions. One of his suggestions is to salt the taproot key or taproot leaf script at the last stage of a congestion control tree. However, he acknowledged that this salt would not be effective if the address is reused. Additionally, he recommended making chaperone signatures optional, as there may be cases where they are unnecessary.Rubin also mentioned that OP_COSHV is compatible with an additional checksig operation. This compatibility allows for more flexibility in implementing security measures. Furthermore, he proposed two other mechanisms: OP_CHECKINPUTSHASHVERIFY and OP_CHECKFEEVERIFY. OP_CHECKINPUTSHASHVERIFY enables the checking of the hash of inputs to ensure they match a specific value. This mechanism has broader applications beyond witness replay-ability. On the other hand, OP_CHECKFEEVERIFY allows for an explicit commitment to the exact amount of fee, limiting replays to transactions funded with the same amount as the previous one. However, it is important to note that transactions using OP_CHECKFEEVERIFY must have all inputs and outputs set.In a separate discussion initiated by Johnson Lau, the topic revolves around enabling witnesses to commit only to transaction outputs, but not inputs. Currently, the bitcoin script system offers three options: committing to both inputs and outputs, committing to only inputs, or not committing to any input or output. However, not committing to any input or output is deemed unsafe as it allows relay/mining nodes to redirect payment to any output they choose. It also makes the witness/scriptSig easily replayable, allowing future payments to be swept immediately.To address this issue, three active proposals have been put forward: CAT and CHECKSIGFROMSTACK (CSFS), ANYPREVOUT (aka NOINPUT), and CHECKOUTPUTSHASHVERIFY (COHV). These proposals ensure that payment redirection is impossible. However, not committing to any input means that the witness can be replayed without the consent of the address owner. The ANYPREVOUT proposal aims to solve this problem by requiring a chaperone signature that commits to the input.It is worth noting that if the rationale for a chaperone signature holds, it should apply to all the proposals mentioned above. A more general approach would be to always require a "safe" signature that commits to at least one input. However, this approach interacts poorly with the unknown public key type upgrade path described in bip-tapscript, as it would require a hardfork to turn an unknown type signature into a safe signature. Nevertheless, a new leaf version could be used for every new sighash type introduced to establish a new definition for a "safe sig". Additionally, customized sighash policies could be implemented with CAT/CSFS. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_Taproot-proposal.xml b/static/bitcoin-dev/May_2019/combined_Taproot-proposal.xml index e88df4e080..6905090ca0 100644 --- a/static/bitcoin-dev/May_2019/combined_Taproot-proposal.xml +++ b/static/bitcoin-dev/May_2019/combined_Taproot-proposal.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Taproot proposal - 2023-08-02T00:47:13.477592+00:00 - - Pieter Wuille 2019-09-18 21:21:56+00:00 - - - ZmnSCPxj 2019-09-17 04:09:50+00:00 - - - Greg Sanders 2019-09-16 16:18:35+00:00 - - - Pieter Wuille 2019-08-09 18:29:55+00:00 - - - Elichai Turkel 2019-08-09 14:58:58+00:00 - - - Russell O'Connor 2019-06-28 11:16:46+00:00 - - - Anthony Towns 2019-06-28 09:49:37+00:00 - - - Russell O'Connor 2019-06-27 00:08:01+00:00 - - - Russell O'Connor 2019-05-23 02:32:26+00:00 - - - Pieter Wuille 2019-05-23 02:06:42+00:00 - - - John Newbery 2019-05-22 14:14:44+00:00 - - - Russell O'Connor 2019-05-21 17:20:32+00:00 - - - ZmnSCPxj 2019-05-18 17:51:16+00:00 - - - ZmnSCPxj 2019-05-10 05:38:52+00:00 - - - Johnson Lau 2019-05-09 16:56:57+00:00 - - - Pieter Wuille 2019-05-08 23:06:51+00:00 - - - Luke Dashjr 2019-05-08 13:10:17+00:00 - - - ZmnSCPxj 2019-05-08 05:16:03+00:00 - - - Anthony Towns 2019-05-08 04:49:28+00:00 - - - ZmnSCPxj 2019-05-08 04:37:37+00:00 - - - ZmnSCPxj 2019-05-08 03:44:29+00:00 - - - Sjors Provoost 2019-05-07 20:42:58+00:00 - - - Luke Dashjr 2019-05-06 20:17:09+00:00 - - - Pieter Wuille 2019-05-06 17:57:57+00:00 - + 2025-09-26T15:40:29.331849+00:00 + python-feedgen + + + [bitcoin-dev] Taproot proposal Pieter Wuille + 2019-05-06T17:57:00.000Z + + + Luke Dashjr + 2019-05-06T20:17:00.000Z + + + Sjors Provoost + 2019-05-07T20:42:00.000Z + + + ZmnSCPxj + 2019-05-08T03:44:00.000Z + + + ZmnSCPxj + 2019-05-08T04:37:00.000Z + + + Anthony Towns + 2019-05-08T04:49:00.000Z + + + ZmnSCPxj + 2019-05-08T05:16:00.000Z + + + Luke Dashjr + 2019-05-08T13:10:00.000Z + + + Pieter Wuille + 2019-05-08T23:06:00.000Z + + + Johnson Lau + 2019-05-09T16:56:00.000Z + + + ZmnSCPxj + 2019-05-10T05:38:00.000Z + + + ZmnSCPxj + 2019-05-18T17:51:00.000Z + + + Russell O'Connor + 2019-05-21T17:20:00.000Z + + + John Newbery + 2019-05-22T14:14:00.000Z + + + Pieter Wuille + 2019-05-23T02:06:00.000Z + + + Russell O'Connor + 2019-05-23T02:32:00.000Z + + + Russell O'Connor + 2019-06-27T00:08:00.000Z + + + Anthony Towns + 2019-06-28T09:49:00.000Z + + + Russell O'Connor + 2019-06-28T11:16:00.000Z + + + Elichai Turkel + 2019-08-09T14:58:00.000Z + + + Pieter Wuille + 2019-08-09T18:29:00.000Z + + + Greg Sanders + 2019-09-16T16:18:00.000Z + + + ZmnSCPxj + 2019-09-17T04:09:00.000Z + + + Pieter Wuille + 2019-09-18T21:21:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Taproot proposal - 2023-08-02T00:47:13.477592+00:00 + 2025-09-26T15:40:29.334381+00:00 - Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown. This technique offers improved privacy and can be useful for setting up Pedersen commitments.Another topic of conversation revolves around signing an additional 2019-09-18T21:21:56+00:00 + Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown. This technique offers improved privacy and can be useful for setting up Pedersen commitments.Another topic of conversation revolves around signing an additional - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2019/combined_Two-questions-about-segwit-implementation.xml b/static/bitcoin-dev/May_2019/combined_Two-questions-about-segwit-implementation.xml index 282497a598..025e4028be 100644 --- a/static/bitcoin-dev/May_2019/combined_Two-questions-about-segwit-implementation.xml +++ b/static/bitcoin-dev/May_2019/combined_Two-questions-about-segwit-implementation.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Two questions about segwit implementation - 2023-08-02T00:55:23.516257+00:00 - - Kostas Karasavvas 2019-05-27 07:26:21+00:00 - - - Aymeric Vitte 2019-05-26 21:17:30+00:00 - - - Thomas Kerin 2019-05-26 19:34:55+00:00 - - - Pieter Wuille 2019-05-26 17:54:08+00:00 - - - Johnson Lau 2019-05-26 17:24:13+00:00 - - - Aymeric Vitte 2019-05-26 17:09:31+00:00 - - - Johnson Lau 2019-05-26 16:28:57+00:00 - - - Aymeric Vitte 2019-05-26 16:18:46+00:00 - - - Johnson Lau 2019-05-26 14:33:06+00:00 - - - Aymeric Vitte 2019-05-25 23:56:48+00:00 - + 2025-09-26T15:40:41.934077+00:00 + python-feedgen + + + [bitcoin-dev] Two questions about segwit implementation Aymeric Vitte + 2019-05-25T23:56:00.000Z + + + Johnson Lau + 2019-05-26T14:33:00.000Z + + + Aymeric Vitte + 2019-05-26T16:18:00.000Z + + + Johnson Lau + 2019-05-26T16:28:00.000Z + + + Aymeric Vitte + 2019-05-26T17:09:00.000Z + + + Johnson Lau + 2019-05-26T17:24:00.000Z + + + Pieter Wuille + 2019-05-26T17:54:00.000Z + + + Thomas Kerin + 2019-05-26T19:34:00.000Z + + + Aymeric Vitte + 2019-05-26T21:17:00.000Z + + + Kostas Karasavvas + 2019-05-27T07:26:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Two questions about segwit implementation - 2023-08-02T00:55:23.516257+00:00 + 2025-09-26T15:40:41.935388+00:00 - Recently, Aymeric Vitte discovered that his implementation of segwit was incorrect due to a misinterpretation of the specifications. He mistakenly believed that scriptsig would be included in the witness data as it is, but he learned that op_pushdata is replaced by varlen. This realization led Vitte to question why OP_0 is represented as 00 in witness data instead of 0100 and whether this applies to other op_codes.The reason behind OP_0 being represented as 00 in witness data lies in the fact that op_pushdata allows for unsigned integers. The extra byte of 00 is used to specify that the value is zero. This clarification was provided in response to Vitte's question.Vitte also questioned the presence of a 00 length in segwit data for non-segwit inputs. It was explained that the witness data length is assumed to be the same as the inputs length. For non-segwit inputs, the 00 is needed to indicate that the witness data is empty. This information is necessary because validators have no way of knowing which inputs are segwit-enabled until they look up the UTXO set. Hence, there needs to be a way to inform the validator that the witness for a particular input is empty, and the 00 serves this purpose.The discussion on the Bitcoin development mailing list further delved into the topic of empty scriptPubKey or OP_1 being a use case. It was clarified that an empty scriptSig does not necessarily imply a segwit input. If the previous scriptPubKey is OP_1 and does not allow witness, it can still be spent with an empty scriptSig. Similarly, a scriptSig resembling a spend of P2SH-segwit also does not imply a segwit input. These points were raised and addressed by Johnson Lau in the discussion.One concern highlighted during the discussion was the lack of clear documentation on this topic. The participants noted the need for more comprehensive and precise specifications to avoid misunderstandings and incorrect implementations.The Bitcoin scriptSig, which populates the stack for opcodes to operate on, was also discussed. It was explained that witnesses are similar to the script stack and are passed in as the script stack. OP_0 pushes a zero length value onto the stack, while OP_1 pushes 0x01, serialized as 0101. The witness structure can be considered as vector<stack>, and its length must match the number of inputs.In summary, Aymeric Vitte discovered errors in his segwit implementation and raised questions about the representation of OP_0 in witness data and the presence of a 00 length in segwit data for non-segwit inputs. The discussion clarified that OP_0 is represented as 00 to indicate zero length and that the 00 length is necessary to inform validators that the witness for a specific input is empty. The conversation also addressed the use cases of empty scriptPubKey and OP_1. The need for clearer documentation on this topic was emphasized, and the functioning of Bitcoin scriptSig and witness structures was explained. 2019-05-27T07:26:21+00:00 + Recently, Aymeric Vitte discovered that his implementation of segwit was incorrect due to a misinterpretation of the specifications. He mistakenly believed that scriptsig would be included in the witness data as it is, but he learned that op_pushdata is replaced by varlen. This realization led Vitte to question why OP_0 is represented as 00 in witness data instead of 0100 and whether this applies to other op_codes.The reason behind OP_0 being represented as 00 in witness data lies in the fact that op_pushdata allows for unsigned integers. The extra byte of 00 is used to specify that the value is zero. This clarification was provided in response to Vitte's question.Vitte also questioned the presence of a 00 length in segwit data for non-segwit inputs. It was explained that the witness data length is assumed to be the same as the inputs length. For non-segwit inputs, the 00 is needed to indicate that the witness data is empty. This information is necessary because validators have no way of knowing which inputs are segwit-enabled until they look up the UTXO set. Hence, there needs to be a way to inform the validator that the witness for a particular input is empty, and the 00 serves this purpose.The discussion on the Bitcoin development mailing list further delved into the topic of empty scriptPubKey or OP_1 being a use case. It was clarified that an empty scriptSig does not necessarily imply a segwit input. If the previous scriptPubKey is OP_1 and does not allow witness, it can still be spent with an empty scriptSig. Similarly, a scriptSig resembling a spend of P2SH-segwit also does not imply a segwit input. These points were raised and addressed by Johnson Lau in the discussion.One concern highlighted during the discussion was the lack of clear documentation on this topic. The participants noted the need for more comprehensive and precise specifications to avoid misunderstandings and incorrect implementations.The Bitcoin scriptSig, which populates the stack for opcodes to operate on, was also discussed. It was explained that witnesses are similar to the script stack and are passed in as the script stack. OP_0 pushes a zero length value onto the stack, while OP_1 pushes 0x01, serialized as 0101. The witness structure can be considered as vector<stack>, and its length must match the number of inputs.In summary, Aymeric Vitte discovered errors in his segwit implementation and raised questions about the representation of OP_0 in witness data and the presence of a 00 length in segwit data for non-segwit inputs. The discussion clarified that OP_0 is represented as 00 to indicate zero length and that the 00 length is necessary to inform validators that the witness for a specific input is empty. The conversation also addressed the use cases of empty scriptPubKey and OP_1. The need for clearer documentation on this topic was emphasized, and the functioning of Bitcoin scriptSig and witness structures was explained. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_Announcing-Bitcoin-Wallet-Tracker.xml b/static/bitcoin-dev/May_2020/combined_Announcing-Bitcoin-Wallet-Tracker.xml index 0810463182..bf909d647d 100644 --- a/static/bitcoin-dev/May_2020/combined_Announcing-Bitcoin-Wallet-Tracker.xml +++ b/static/bitcoin-dev/May_2020/combined_Announcing-Bitcoin-Wallet-Tracker.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Announcing Bitcoin Wallet Tracker - 2023-08-02T02:20:06.234965+00:00 - - Nadav Ivgi 2020-06-01 08:10:50+00:00 - - - Nadav Ivgi 2020-05-30 14:16:14+00:00 - + 2025-09-26T15:36:04.092966+00:00 + python-feedgen + + + [bitcoin-dev] Announcing Bitcoin Wallet Tracker Nadav Ivgi + 2020-05-30T14:16:00.000Z + + + Nadav Ivgi + 2020-06-01T08:10:00.000Z + + - python-feedgen + 2 Combined summary - Announcing Bitcoin Wallet Tracker - 2023-08-02T02:20:06.234965+00:00 + 2025-09-26T15:36:04.093415+00:00 - Nadav Ivgi has released a new HD wallet indexer called bwt, which is similar to Electrum Personal Server but offers additional indexes on top of the bitcoind wallet functionality. This indexer is designed to track an xpub and automatically derive new addresses as needed, according to the gap limit. It provides real-time updates via Server-Sent Events or Web Hooks, unlike using bitcoind RPC directly. The aim of bwt is to minimize RPC requests to bitcoind. Support for output script descriptors is one major item on the roadmap for future development.Antoine compares esplora-electrs and bwt in terms of performance. Both APIs are designed by Nadav and have similarities. While esplora-electrs keeps a full index of everything, bwt only tracks wallet addresses. Therefore, if the user is only interested in wallet addresses and doesn't have a large number of them, bwt will perform better. However, if there are many addresses, esplora-electrs will be more suitable. Esplora provides comprehensive information about transactions and blocks, while bwt intentionally reduces this information to the subset useful for app development. Bwt provides wallet-contextual information, such as key origins next to addresses and the net change inflicted on the wallet's balance by transactions. Unlike Esplora, bwt provides real-time updates using two different mechanisms: SSE and Web Hooks.Bwt, implemented in Rust by Nadav, is an HD wallet indexer that utilizes the bitcoind wallet functionality to build additional indexes. These indexes can be queried using the Electrum RPC protocol or a developer-friendly HTTP REST API. The electrum server can also be used as an electrum plugin, integrating the server into the electrum client. The HTTP API is designed for wallet tracking and aimed at app developers, serving as a backend for wallets or deposit tracking for watch-only xpubs.In comparison to using bitcoind RPC directly, bwt offers several conveniences. It allows for tracking an xpub and automatically importing new addresses as needed. It provides real-time updates through Server-Sent Events or Web Hooks. The API offers simplifications and conveniences, along with an easy way to catch up with missed events. To minimize RPC requests, the indexer uses labels to store key origin information. It can index 10k incoming transactions in under a second or a mixture of 5k/5k in under 5 seconds. Although it requires an additional RPC call per outgoing transaction to determine spent prevouts, the index is currently stored entirely in-memory without persistence.Nadav has included useful developer resources and a script for setting up a development environment in the README. This early alpha release of bwt is recommended for use with testnet/regtest. 2020-06-01T08:10:50+00:00 + Nadav Ivgi has released a new HD wallet indexer called bwt, which is similar to Electrum Personal Server but offers additional indexes on top of the bitcoind wallet functionality. This indexer is designed to track an xpub and automatically derive new addresses as needed, according to the gap limit. It provides real-time updates via Server-Sent Events or Web Hooks, unlike using bitcoind RPC directly. The aim of bwt is to minimize RPC requests to bitcoind. Support for output script descriptors is one major item on the roadmap for future development.Antoine compares esplora-electrs and bwt in terms of performance. Both APIs are designed by Nadav and have similarities. While esplora-electrs keeps a full index of everything, bwt only tracks wallet addresses. Therefore, if the user is only interested in wallet addresses and doesn't have a large number of them, bwt will perform better. However, if there are many addresses, esplora-electrs will be more suitable. Esplora provides comprehensive information about transactions and blocks, while bwt intentionally reduces this information to the subset useful for app development. Bwt provides wallet-contextual information, such as key origins next to addresses and the net change inflicted on the wallet's balance by transactions. Unlike Esplora, bwt provides real-time updates using two different mechanisms: SSE and Web Hooks.Bwt, implemented in Rust by Nadav, is an HD wallet indexer that utilizes the bitcoind wallet functionality to build additional indexes. These indexes can be queried using the Electrum RPC protocol or a developer-friendly HTTP REST API. The electrum server can also be used as an electrum plugin, integrating the server into the electrum client. The HTTP API is designed for wallet tracking and aimed at app developers, serving as a backend for wallets or deposit tracking for watch-only xpubs.In comparison to using bitcoind RPC directly, bwt offers several conveniences. It allows for tracking an xpub and automatically importing new addresses as needed. It provides real-time updates through Server-Sent Events or Web Hooks. The API offers simplifications and conveniences, along with an easy way to catch up with missed events. To minimize RPC requests, the indexer uses labels to store key origin information. It can index 10k incoming transactions in under a second or a mixture of 5k/5k in under 5 seconds. Although it requires an additional RPC call per outgoing transaction to determine spent prevouts, the index is currently stored entirely in-memory without persistence.Nadav has included useful developer resources and a script for setting up a development environment in the README. This early alpha release of bwt is recommended for use with testnet/regtest. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_BIP-341-Committing-to-all-scriptPubKeys-in-the-signature-message.xml b/static/bitcoin-dev/May_2020/combined_BIP-341-Committing-to-all-scriptPubKeys-in-the-signature-message.xml index bde8cfa228..51f7dca97c 100644 --- a/static/bitcoin-dev/May_2020/combined_BIP-341-Committing-to-all-scriptPubKeys-in-the-signature-message.xml +++ b/static/bitcoin-dev/May_2020/combined_BIP-341-Committing-to-all-scriptPubKeys-in-the-signature-message.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - BIP-341: Committing to all scriptPubKeys in the signature message - 2023-08-02T02:08:51.329382+00:00 - - Pieter Wuille 2020-05-11 22:12:33+00:00 - - - Jonas Nick 2020-05-05 10:20:18+00:00 - - - Andrew Kozlik 2020-05-04 15:48:00+00:00 - - - Russell O'Connor 2020-05-02 21:15:51+00:00 - - - Russell O'Connor 2020-05-02 14:43:13+00:00 - - - Anthony Towns 2020-05-02 14:26:02+00:00 - - - David A. Harding 2020-05-02 12:53:12+00:00 - - - Jeremy 2020-05-02 04:35:41+00:00 - - - Greg Sanders 2020-05-01 12:25:53+00:00 - - - Russell O'Connor 2020-05-01 12:23:07+00:00 - - - Andrew Kozlik 2020-05-01 08:48:41+00:00 - - - Jeremy 2020-05-01 06:57:09+00:00 - - - Andrew Kozlik 2020-04-29 14:57:46+00:00 - + 2025-09-26T15:35:47.178837+00:00 + python-feedgen + + + [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message Andrew Kozlik + 2020-04-29T14:57:00.000Z + + + Jeremy + 2020-05-01T06:57:00.000Z + + + Andrew Kozlik + 2020-05-01T08:48:00.000Z + + + Russell O'Connor + 2020-05-01T12:23:00.000Z + + + Greg Sanders + 2020-05-01T12:25:00.000Z + + + Jeremy + 2020-05-02T04:35:00.000Z + + + David A. Harding + 2020-05-02T12:53:00.000Z + + + Anthony Towns + 2020-05-02T14:26:00.000Z + + + Russell O'Connor + 2020-05-02T14:43:00.000Z + + + Russell O'Connor + 2020-05-02T21:15:00.000Z + + + Andrew Kozlik + 2020-05-04T15:48:00.000Z + + + Jonas Nick + 2020-05-05T10:20:00.000Z + + + Pieter Wuille + 2020-05-11T22:12:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - BIP-341: Committing to all scriptPubKeys in the signature message - 2023-08-02T02:08:51.329382+00:00 + 2025-09-26T15:35:47.180321+00:00 - Pieter Wuille, a Bitcoin Core developer, has proposed a change to the existing BIP341 and BIP342. This change aims to improve the ability of signers to determine whether they can safely sign with only O(1) information per input. The current model poses limitations as in some cases signers may need to be provided with the entire creating transaction. Wuille supports AJ's approach, which does not increase per-signature hashing while retaining the ability to cache information across BIP141/BIP341. Coinbaseness and height are also being considered, but Wuille believes their utility is low.The proposed amendment to BIP-341 suggests committing to the scriptPubKeys of all transaction inputs instead of just the output being spent. This change is aimed at improving the reliability of determining ownership of external inputs, particularly in applications like CoinJoin where transactions contain external inputs. Without this mechanism, an adversary could display incorrect information about the amount being spent, resulting in theft of user funds. The proposed solution commits to every spent scriptPubKey and therefore every element of the TxOut instead of just the amount. Committing to the input values in the transaction digest would allow for compact fee proofs, and the same reasoning applies to scriptPubKeys. Coinjoin with offline signers would be substantially harder without this proposal.The proposal being discussed is related to the inclusion of sha_scriptPubKeys in a transaction's signature message. However, this would limit some use cases where SIGHASH_ALL behavior is not required. The proposal suggests that sha_scriptPubKeys should only be included if hash_type does not match SIGHASH_ANYONECANPAY. The context also highlights an attack scenario in CoinJoin transactions where the attacker can construct a transaction with two inputs and outputs of identical value, one belonging to the user and another to the attacker. As an alternative proposal, it is suggested that a separate BIP for new sigash flags be created. Additionally, the email mentions the importance of including the scriptPubKey to verify the ownership proof signature. Finally, the email describes how adding the height of the coin to the signature message would constitute a change of a different caliber and is not currently proposed.In an email exchange, Anthony Towns raises concerns about missing information in Bitcoin transactions, specifically the height of a coin and whether it is a Coinbase output. He suggests that committing to the coinbase flag might have some use, but cautions against adding the height of the coin as it would make it hard to chain unconfirmed spends. In a discussion about verifying output scriptPubKeys in Bitcoin transactions, it is pointed out that not verifying these keys would limit one's ability to track where funds went. The current design of sharing the hashOutputs value with BIP-143 is seen as a valuable property to maintain.Russell O'Connor suggests separating the hashes of the ScriptPubKeys from the input values in sha_scriptPubKeys, while Andrew's suggestion to add another hash to the signature message for sha_scriptPubKeys achieves this. They could also make the scriptPubKey field dependent on hash_type matching ANYONECANPAY, which would mean committing to each component of the UTXOs being spent. Russell O'Connor also proposed separating the hashing of the output values from the output ScriptPubKeys in sha_outputs so that applications interested only in summing the values of the outputs do not have to wade through those arbitrary long ScriptPubKeys in the outputs.Andrew Kozlik discusses the need for a wallet to ascertain non-ownership of an external input by obtaining the scriptPubKey of the previous output spent by the input. He mentions the impracticality of checking whether a scriptPubKey contains any of the possible two billion keys in a specific BIP32 derivation path. Greg Saunders' scheme can be used as an alternative, which requires one-way communication from a signing device to a coordinator.In a Bitcoin development discussion, Andrew Kozlik proposed a modification to the signature message of BIP-0341. He suggested that the signature message should commit to the scriptPubKeys of all transaction inputs, rather than just the scriptPubKey of the output being spent. This proposal is motivated by the need for wallets in situations such as CoinJoin to accurately determine if an input belongs to the wallet or not, in order to calculate the actual amount being spent by the user.The proposed solution involves adding another hash to the signature message: sha_scriptPubKeys (32). This hash would be the SHA256 of the serialization of all scriptPubKeys of the previous outputs spent by the transaction. By including this hash, wallets would be able to reliably determine for each input whether it belongs to the wallet or not, ensuring the accuracy of the amount being spent.Jeremy Rubin responded to Andrew's proposal by suggesting that using SIGHASH_ALL would sign the COutPoints of all inputs, eliminating the need for signing any additional data. Additionally, he proposed using the metadata protocol to provide all input transactions for checking the 2020-05-11T22:12:33+00:00 + Pieter Wuille, a Bitcoin Core developer, has proposed a change to the existing BIP341 and BIP342. This change aims to improve the ability of signers to determine whether they can safely sign with only O(1) information per input. The current model poses limitations as in some cases signers may need to be provided with the entire creating transaction. Wuille supports AJ's approach, which does not increase per-signature hashing while retaining the ability to cache information across BIP141/BIP341. Coinbaseness and height are also being considered, but Wuille believes their utility is low.The proposed amendment to BIP-341 suggests committing to the scriptPubKeys of all transaction inputs instead of just the output being spent. This change is aimed at improving the reliability of determining ownership of external inputs, particularly in applications like CoinJoin where transactions contain external inputs. Without this mechanism, an adversary could display incorrect information about the amount being spent, resulting in theft of user funds. The proposed solution commits to every spent scriptPubKey and therefore every element of the TxOut instead of just the amount. Committing to the input values in the transaction digest would allow for compact fee proofs, and the same reasoning applies to scriptPubKeys. Coinjoin with offline signers would be substantially harder without this proposal.The proposal being discussed is related to the inclusion of sha_scriptPubKeys in a transaction's signature message. However, this would limit some use cases where SIGHASH_ALL behavior is not required. The proposal suggests that sha_scriptPubKeys should only be included if hash_type does not match SIGHASH_ANYONECANPAY. The context also highlights an attack scenario in CoinJoin transactions where the attacker can construct a transaction with two inputs and outputs of identical value, one belonging to the user and another to the attacker. As an alternative proposal, it is suggested that a separate BIP for new sigash flags be created. Additionally, the email mentions the importance of including the scriptPubKey to verify the ownership proof signature. Finally, the email describes how adding the height of the coin to the signature message would constitute a change of a different caliber and is not currently proposed.In an email exchange, Anthony Towns raises concerns about missing information in Bitcoin transactions, specifically the height of a coin and whether it is a Coinbase output. He suggests that committing to the coinbase flag might have some use, but cautions against adding the height of the coin as it would make it hard to chain unconfirmed spends. In a discussion about verifying output scriptPubKeys in Bitcoin transactions, it is pointed out that not verifying these keys would limit one's ability to track where funds went. The current design of sharing the hashOutputs value with BIP-143 is seen as a valuable property to maintain.Russell O'Connor suggests separating the hashes of the ScriptPubKeys from the input values in sha_scriptPubKeys, while Andrew's suggestion to add another hash to the signature message for sha_scriptPubKeys achieves this. They could also make the scriptPubKey field dependent on hash_type matching ANYONECANPAY, which would mean committing to each component of the UTXOs being spent. Russell O'Connor also proposed separating the hashing of the output values from the output ScriptPubKeys in sha_outputs so that applications interested only in summing the values of the outputs do not have to wade through those arbitrary long ScriptPubKeys in the outputs.Andrew Kozlik discusses the need for a wallet to ascertain non-ownership of an external input by obtaining the scriptPubKey of the previous output spent by the input. He mentions the impracticality of checking whether a scriptPubKey contains any of the possible two billion keys in a specific BIP32 derivation path. Greg Saunders' scheme can be used as an alternative, which requires one-way communication from a signing device to a coordinator.In a Bitcoin development discussion, Andrew Kozlik proposed a modification to the signature message of BIP-0341. He suggested that the signature message should commit to the scriptPubKeys of all transaction inputs, rather than just the scriptPubKey of the output being spent. This proposal is motivated by the need for wallets in situations such as CoinJoin to accurately determine if an input belongs to the wallet or not, in order to calculate the actual amount being spent by the user.The proposed solution involves adding another hash to the signature message: sha_scriptPubKeys (32). This hash would be the SHA256 of the serialization of all scriptPubKeys of the previous outputs spent by the transaction. By including this hash, wallets would be able to reliably determine for each input whether it belongs to the wallet or not, ensuring the accuracy of the amount being spent.Jeremy Rubin responded to Andrew's proposal by suggesting that using SIGHASH_ALL would sign the COutPoints of all inputs, eliminating the need for signing any additional data. Additionally, he proposed using the metadata protocol to provide all input transactions for checking the - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_Compressed-block-headers.xml b/static/bitcoin-dev/May_2020/combined_Compressed-block-headers.xml index fc6e1eb586..97beb8c5bb 100644 --- a/static/bitcoin-dev/May_2020/combined_Compressed-block-headers.xml +++ b/static/bitcoin-dev/May_2020/combined_Compressed-block-headers.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Compressed block headers - 2023-08-02T02:11:54.560330+00:00 - - Richard Myers 2020-05-20 13:06:11+00:00 - - - Robin Linus 2020-05-11 12:26:54+00:00 - - - Richard Myers 2020-05-11 11:46:04+00:00 - - - Will Clark 2020-05-08 12:31:06+00:00 - + 2025-09-26T15:35:55.606791+00:00 + python-feedgen + + + [bitcoin-dev] Compressed block headers Will Clark + 2020-05-08T12:31:00.000Z + + + Richard Myers + 2020-05-11T11:46:00.000Z + + + Robin Linus + 2020-05-11T12:26:00.000Z + + + Richard Myers + 2020-05-20T13:06:00.000Z + + - python-feedgen + 2 Combined summary - Compressed block headers - 2023-08-02T02:11:54.560330+00:00 + 2025-09-26T15:35:55.607473+00:00 - The proposed specification includes a new data type called `block_header2` which compresses some fields completely and others under certain conditions. The Version field will usually be identical to one referenced in one of the previous 7 unique versions, as indicated by bits 0,1,2 of the Bitfield. The previous block hash will always be the `SHA256(SHA256())`, so it is redundant if the previous header is known. The timestamp (in seconds) can be represented as an offset from the previous headers' timestamp using a 2-byte signed short int. NBits can also be transmitted according to the proposed specification. Txn_count is included to make parsing of these messages compatible with parsing of `block` messages but can be removed for transmission of compact headers.The proposal also includes a bitfield to make parsing of header messages easier and further increase header compression, which adds 1 byte for every block in the chain. A new service bit would be required so that nodes can advertise their ability to supply compact headers. Three new messages would be used by nodes that enable compact block header support: `getheaders2`, `sendheaders2`, and `headers2`. The first header in the first `block_header2[]` vector to a newly-connected client must contain the full `nBits`, `timestamp`, `version`, and `prev_block_hash` fields, along with a correctly populated `bitfield` byte.The proposed scheme could save up to 49% of bandwidth required for a continuous header sync from genesis. However, there are potential drawbacks to implementing this compression scheme. It may require higher computation and memory for caching the last few versions, and there could be complexity and bugs associated with its implementation. Additionally, the use of low-bandwidth light clients should not be encouraged.The `headers2` message is returned in response to a `getheaders2` or at new header announcement following a `sendheaders2` request. It contains both `length` and `headers` fields, where the `headers` field contains compressed block headers in the specified format. The first header in the first `block_header2[]` vector to a newly-connected client must contain the full `nBits`, `timestamp`, `version`, and `prev_block_hash` fields, along with a correctly populated `bitfield` byte. Subsequent headers in a contiguous vector should follow the compressed format. If subsequent compressed headers are supplied to an already-connected client requesting compressed headers, they should also follow the compressed format.This proposal by Will Clark aims to provide significant bandwidth savings for low bandwidth nodes during IBD and block announcements. By compressing block headers, the size can be reduced from 81 bytes to as little as 39 bytes, resulting in a saving of 49% of the required bandwidth. The proposed specification includes a new data type, service bit, and three new messages to enable compact block header support. However, there are potential drawbacks to consider, such as increased computation and memory requirements, complexity in implementation, and the need to discourage the use of low-bandwidth light clients. 2020-05-20T13:06:11+00:00 + The proposed specification includes a new data type called `block_header2` which compresses some fields completely and others under certain conditions. The Version field will usually be identical to one referenced in one of the previous 7 unique versions, as indicated by bits 0,1,2 of the Bitfield. The previous block hash will always be the `SHA256(SHA256())`, so it is redundant if the previous header is known. The timestamp (in seconds) can be represented as an offset from the previous headers' timestamp using a 2-byte signed short int. NBits can also be transmitted according to the proposed specification. Txn_count is included to make parsing of these messages compatible with parsing of `block` messages but can be removed for transmission of compact headers.The proposal also includes a bitfield to make parsing of header messages easier and further increase header compression, which adds 1 byte for every block in the chain. A new service bit would be required so that nodes can advertise their ability to supply compact headers. Three new messages would be used by nodes that enable compact block header support: `getheaders2`, `sendheaders2`, and `headers2`. The first header in the first `block_header2[]` vector to a newly-connected client must contain the full `nBits`, `timestamp`, `version`, and `prev_block_hash` fields, along with a correctly populated `bitfield` byte.The proposed scheme could save up to 49% of bandwidth required for a continuous header sync from genesis. However, there are potential drawbacks to implementing this compression scheme. It may require higher computation and memory for caching the last few versions, and there could be complexity and bugs associated with its implementation. Additionally, the use of low-bandwidth light clients should not be encouraged.The `headers2` message is returned in response to a `getheaders2` or at new header announcement following a `sendheaders2` request. It contains both `length` and `headers` fields, where the `headers` field contains compressed block headers in the specified format. The first header in the first `block_header2[]` vector to a newly-connected client must contain the full `nBits`, `timestamp`, `version`, and `prev_block_hash` fields, along with a correctly populated `bitfield` byte. Subsequent headers in a contiguous vector should follow the compressed format. If subsequent compressed headers are supplied to an already-connected client requesting compressed headers, they should also follow the compressed format.This proposal by Will Clark aims to provide significant bandwidth savings for low bandwidth nodes during IBD and block announcements. By compressing block headers, the size can be reduced from 81 bytes to as little as 39 bytes, resulting in a saving of 49% of the required bandwidth. The proposed specification includes a new data type, service bit, and three new messages to enable compact block header support. However, there are potential drawbacks to consider, such as increased computation and memory requirements, complexity in implementation, and the need to discourage the use of low-bandwidth light clients. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_Design-for-a-CoinSwap-implementation-for-massively-improving-Bitcoin-privacy-and-fungibility.xml b/static/bitcoin-dev/May_2020/combined_Design-for-a-CoinSwap-implementation-for-massively-improving-Bitcoin-privacy-and-fungibility.xml index 0cdf663294..1314200aff 100644 --- a/static/bitcoin-dev/May_2020/combined_Design-for-a-CoinSwap-implementation-for-massively-improving-Bitcoin-privacy-and-fungibility.xml +++ b/static/bitcoin-dev/May_2020/combined_Design-for-a-CoinSwap-implementation-for-massively-improving-Bitcoin-privacy-and-fungibility.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility - 2023-08-02T02:18:36.479718+00:00 - - Jonas Nick 2020-06-19 15:33:09+00:00 - - - Chris Belcher 2020-06-10 11:19:53+00:00 - - - Chris Belcher 2020-06-10 11:15:03+00:00 - - - ZmnSCPxj 2020-06-10 10:58:03+00:00 - - - Chris Belcher 2020-06-10 10:15:36+00:00 - - - ZmnSCPxj 2020-06-10 07:09:04+00:00 - - - Mr. Lee Chiffre 2020-06-10 00:46:41+00:00 - - - Mr. Lee Chiffre 2020-06-10 00:43:40+00:00 - - - ZmnSCPxj 2020-06-06 04:25:11+00:00 - - - ZmnSCPxj 2020-06-06 03:59:30+00:00 - - - ZmnSCPxj 2020-06-06 01:40:18+00:00 - - - Chris Belcher 2020-06-05 22:39:47+00:00 - - - ZmnSCPxj 2020-06-04 16:37:53+00:00 - - - ZmnSCPxj 2020-06-03 14:50:01+00:00 - - - ZmnSCPxj 2020-06-03 04:53:52+00:00 - - - Chris Belcher 2020-06-02 22:24:19+00:00 - - - Ruben Somsen 2020-06-01 10:19:38+00:00 - - - ZmnSCPxj 2020-06-01 02:34:03+00:00 - - - Ruben Somsen 2020-05-31 21:19:22+00:00 - - - ZmnSCPxj 2020-05-31 02:30:55+00:00 - - - Ruben Somsen 2020-05-30 16:00:05+00:00 - - - Chris Belcher 2020-05-25 13:21:21+00:00 - + 2025-09-26T15:35:49.326603+00:00 + python-feedgen + + + [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility Chris Belcher + 2020-05-25T13:21:00.000Z + + + Ruben Somsen + 2020-05-30T16:00:00.000Z + + + ZmnSCPxj + 2020-05-31T02:30:00.000Z + + + Ruben Somsen + 2020-05-31T21:19:00.000Z + + + ZmnSCPxj + 2020-06-01T02:34:00.000Z + + + Ruben Somsen + 2020-06-01T10:19:00.000Z + + + Chris Belcher + 2020-06-02T22:24:00.000Z + + + ZmnSCPxj + 2020-06-03T04:53:00.000Z + + + ZmnSCPxj + 2020-06-03T14:50:00.000Z + + + ZmnSCPxj + 2020-06-04T16:37:00.000Z + + + Chris Belcher + 2020-06-05T22:39:00.000Z + + + ZmnSCPxj + 2020-06-06T01:40:00.000Z + + + ZmnSCPxj + 2020-06-06T03:59:00.000Z + + + ZmnSCPxj + 2020-06-06T04:25:00.000Z + + + Mr. Lee Chiffre + 2020-06-10T00:43:00.000Z + + + Mr. Lee Chiffre + 2020-06-10T00:46:00.000Z + + + ZmnSCPxj + 2020-06-10T07:09:00.000Z + + + Chris Belcher + 2020-06-10T10:15:00.000Z + + + ZmnSCPxj + 2020-06-10T10:58:00.000Z + + + Chris Belcher + 2020-06-10T11:15:00.000Z + + + Chris Belcher + 2020-06-10T11:19:00.000Z + + + Jonas Nick + 2020-06-19T15:33:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility - 2023-08-02T02:18:36.480718+00:00 + 2025-09-26T15:35:49.328869+00:00 - In a recent email conversation, Chris and ZmnSCPxj discuss the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. This scheme suggests that users can CoinSwap as soon as they receive funds, making sending payments as fast as non-CoinSwap on-chain wallets. It requires the user to maintain two internal wallets, a pre-mix wallet, and a post-mix wallet. Unspent funds in the pre-mix wallet are automatically swapped into the post-mix wallet, and when sending funds, coins from the post-mix wallet are spent directly to the payee address. Change outputs go to a new swap immediately instead of going back to the pre-mix or post-mix wallets.The scalability and privacy concerns of Bitcoin are raised in an email exchange between Lee Chiffre and Chris Belcher. Chris explains that his proposed CoinSwap system doesn't break pruning or other resource-saving features, making Bitcoin-with-CoinSwap more scalable than Monero. He also highlights how CoinSwap improves privacy by moving information off-chain, similar to Lightning Network. Chris suggests that even if only 5% of transactions were CoinSwaps, it would significantly improve users' privacy. He demonstrates how CoinSwaps can be used as payment and emphasizes that they are cheaper than Equal-Output CoinJoins. Chris concludes by noting that most day-to-day Bitcoin transactions are expected to happen off-chain using technologies like Lightning Network, which also enhances privacy.The email conversation also discusses the implementation of a new CoinSwap protocol. The protocol is split into phases: channel establishment, HTLC forwarding, HTLC resolution, and private key handover. The Spilman channel is used to create temporary unidirectional time-bound channels for simultaneous funding transactions without the risk of race loss. Bob has to wait for the incoming contract transaction before signing its outgoing contract transaction. The proposed alternative, swap-on-receive+swap-on-change, may not be suitable for every use case, but it is useful for day-to-day Bitcoin transactions.The concern over scalability and privacy in Bitcoin is discussed in a message from Lee Chiffre to Chris. Both Bitcoin and Monero face challenges related to large transaction sizes required for acceptable privacy. The proposed CoinSwap system aims to address these issues by enabling trustless coin swaps that are not linkable to the public blockchain. However, combining multi-transaction with routing may create scalability problems due to multiple branches and layers.In another message, ZmnSCPxj suggests using swap-on-pay or swap-on-receive+swap-on-change approaches for CoinSwap transactions. Swap-on-pay involves swapping funds before sending them to payees to prevent correlation between sends and receives. Swap-on-receive+swap-on-change involves maintaining two internal wallets, pre-mix, and post-mix wallets, to facilitate faster payments. It is noted that the swap-on-receive+swap-on-change approach may not be suitable for users who prioritize privacy and censorship resistance.The email exchange between Chris and ZmnSCPxj explores the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. The conversation also addresses scalability and privacy concerns in Bitcoin and discusses the implementation of a new CoinSwap protocol. The benefits of combining routing and multi-transaction techniques are examined, and various approaches for CoinSwap transactions are proposed.In a conversation about the CoinSwap protocol, it was noted that the order of funding transactions in a chained/routed swap could be used to derive the order of swaps, posing a security risk. To mitigate this, it is advisable for CoinSwap peers to wait for the counterparty's funding transaction to confirm before broadcasting their own. Additionally, the use of `nLockTime`-protected Backouts can allow unilateral recovery of funds if a funding transaction fails to confirm.The email discusses improvements to the CoinSwap protocol, including the use of `nLockTime`-protected Backouts and the creation of Spilman unidirectional payment channels to bring off-chain timing details out of sight. However, these approaches still have vulnerabilities that need to be addressed to prevent loss of control over coins.Security in cryptocurrency transactions is crucial, and waiting for funding transactions to confirm is recommended to avoid theft. Similar to Lightning Network, where contracts cannot be cancelled by publishing older states, the confirmation of the funding transaction in CoinSwap ensures that previous states cannot be validly spent. This highlights the importance of caution and patience when dealing with cryptocurrency transactions.The discussion between Chris and Ruben revolves around PayJoin-with-CoinSwap, which breaks the common-input-ownership heuristic and improves privacy. It can be useful for individuals recovering degraded privacy or spending from reused or linked addresses. However, there are downsides such as potential spying and the need for makers to reveal additional UTXOs. Using decoy UTXOs instead of PoDLE is suggested to resist attacks. Furthermore, the order of funding transactions for chained/routed swaps may 2020-06-19T15:33:09+00:00 + In a recent email conversation, Chris and ZmnSCPxj discuss the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. This scheme suggests that users can CoinSwap as soon as they receive funds, making sending payments as fast as non-CoinSwap on-chain wallets. It requires the user to maintain two internal wallets, a pre-mix wallet, and a post-mix wallet. Unspent funds in the pre-mix wallet are automatically swapped into the post-mix wallet, and when sending funds, coins from the post-mix wallet are spent directly to the payee address. Change outputs go to a new swap immediately instead of going back to the pre-mix or post-mix wallets.The scalability and privacy concerns of Bitcoin are raised in an email exchange between Lee Chiffre and Chris Belcher. Chris explains that his proposed CoinSwap system doesn't break pruning or other resource-saving features, making Bitcoin-with-CoinSwap more scalable than Monero. He also highlights how CoinSwap improves privacy by moving information off-chain, similar to Lightning Network. Chris suggests that even if only 5% of transactions were CoinSwaps, it would significantly improve users' privacy. He demonstrates how CoinSwaps can be used as payment and emphasizes that they are cheaper than Equal-Output CoinJoins. Chris concludes by noting that most day-to-day Bitcoin transactions are expected to happen off-chain using technologies like Lightning Network, which also enhances privacy.The email conversation also discusses the implementation of a new CoinSwap protocol. The protocol is split into phases: channel establishment, HTLC forwarding, HTLC resolution, and private key handover. The Spilman channel is used to create temporary unidirectional time-bound channels for simultaneous funding transactions without the risk of race loss. Bob has to wait for the incoming contract transaction before signing its outgoing contract transaction. The proposed alternative, swap-on-receive+swap-on-change, may not be suitable for every use case, but it is useful for day-to-day Bitcoin transactions.The concern over scalability and privacy in Bitcoin is discussed in a message from Lee Chiffre to Chris. Both Bitcoin and Monero face challenges related to large transaction sizes required for acceptable privacy. The proposed CoinSwap system aims to address these issues by enabling trustless coin swaps that are not linkable to the public blockchain. However, combining multi-transaction with routing may create scalability problems due to multiple branches and layers.In another message, ZmnSCPxj suggests using swap-on-pay or swap-on-receive+swap-on-change approaches for CoinSwap transactions. Swap-on-pay involves swapping funds before sending them to payees to prevent correlation between sends and receives. Swap-on-receive+swap-on-change involves maintaining two internal wallets, pre-mix, and post-mix wallets, to facilitate faster payments. It is noted that the swap-on-receive+swap-on-change approach may not be suitable for users who prioritize privacy and censorship resistance.The email exchange between Chris and ZmnSCPxj explores the proposal of a swap-on-receive+swap-on-change scheme as an alternative to CoinSwap. The conversation also addresses scalability and privacy concerns in Bitcoin and discusses the implementation of a new CoinSwap protocol. The benefits of combining routing and multi-transaction techniques are examined, and various approaches for CoinSwap transactions are proposed.In a conversation about the CoinSwap protocol, it was noted that the order of funding transactions in a chained/routed swap could be used to derive the order of swaps, posing a security risk. To mitigate this, it is advisable for CoinSwap peers to wait for the counterparty's funding transaction to confirm before broadcasting their own. Additionally, the use of `nLockTime`-protected Backouts can allow unilateral recovery of funds if a funding transaction fails to confirm.The email discusses improvements to the CoinSwap protocol, including the use of `nLockTime`-protected Backouts and the creation of Spilman unidirectional payment channels to bring off-chain timing details out of sight. However, these approaches still have vulnerabilities that need to be addressed to prevent loss of control over coins.Security in cryptocurrency transactions is crucial, and waiting for funding transactions to confirm is recommended to avoid theft. Similar to Lightning Network, where contracts cannot be cancelled by publishing older states, the confirmation of the funding transaction in CoinSwap ensures that previous states cannot be validly spent. This highlights the importance of caution and patience when dealing with cryptocurrency transactions.The discussion between Chris and Ruben revolves around PayJoin-with-CoinSwap, which breaks the common-input-ownership heuristic and improves privacy. It can be useful for individuals recovering degraded privacy or spending from reused or linked addresses. However, there are downsides such as potential spying and the need for makers to reveal additional UTXOs. Using decoy UTXOs instead of PoDLE is suggested to resist attacks. Furthermore, the order of funding transactions for chained/routed swaps may - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_Fwd-Semi-Traceless-2-party-coinjoin-off-chain-protocol-using-schnorr-signatures.xml b/static/bitcoin-dev/May_2020/combined_Fwd-Semi-Traceless-2-party-coinjoin-off-chain-protocol-using-schnorr-signatures.xml index 434035e854..f20160e9aa 100644 --- a/static/bitcoin-dev/May_2020/combined_Fwd-Semi-Traceless-2-party-coinjoin-off-chain-protocol-using-schnorr-signatures.xml +++ b/static/bitcoin-dev/May_2020/combined_Fwd-Semi-Traceless-2-party-coinjoin-off-chain-protocol-using-schnorr-signatures.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures - 2023-08-02T02:05:31.929016+00:00 - - ZmnSCPxj 2020-05-04 08:28:41+00:00 - - - Chris Belcher 2020-05-03 19:28:23+00:00 - - - ZmnSCPxj 2020-05-01 07:17:19+00:00 - - - Chris Belcher 2020-04-30 17:18:03+00:00 - - - ZmnSCPxj 2020-04-30 08:54:28+00:00 - - - Chris Belcher 2020-04-29 15:06:01+00:00 - - - ZmnSCPxj 2020-04-29 07:56:16+00:00 - - - Chris Belcher 2020-04-28 13:03:36+00:00 - - - German Luna 2020-04-24 13:42:12+00:00 - - - ZmnSCPxj 2020-04-24 01:34:51+00:00 - - - German Luna 2020-04-23 18:40:06+00:00 - - - ZmnSCPxj 2020-04-23 17:56:08+00:00 - - - German Luna 2020-04-22 18:42:18+00:00 - + 2025-09-26T15:35:59.876313+00:00 + python-feedgen + + + [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures German Luna + 2020-04-22T18:42:00.000Z + + + ZmnSCPxj + 2020-04-23T17:56:00.000Z + + + German Luna + 2020-04-23T18:40:00.000Z + + + ZmnSCPxj + 2020-04-24T01:34:00.000Z + + + German Luna + 2020-04-24T13:42:00.000Z + + + Chris Belcher + 2020-04-28T13:03:00.000Z + + + ZmnSCPxj + 2020-04-29T07:56:00.000Z + + + Chris Belcher + 2020-04-29T15:06:00.000Z + + + ZmnSCPxj + 2020-04-30T08:54:00.000Z + + + Chris Belcher + 2020-04-30T17:18:00.000Z + + + ZmnSCPxj + 2020-05-01T07:17:00.000Z + + + Chris Belcher + 2020-05-03T19:28:00.000Z + + + ZmnSCPxj + 2020-05-04T08:28:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures - 2023-08-02T02:05:31.929016+00:00 + 2025-09-26T15:35:59.877863+00:00 - CoinSwap is a Bitcoin protocol that aims to improve privacy in transactions. However, there are limitations to the current approach of using CoinSwap with mixdepths. While mixdepths can protect against co-spending inputs, they may not be necessary for multi-transaction CoinSwaps where no coins are merged. If coins need to be merged, it is suggested that they should be in the same mixdepth.To address the issue of 1-input-1-output transactions being markers, a proposal is made to use a PayJoin construction for the second transaction. Additionally, Alice can spend her UTXOs in 2-output transactions and manipulate the change output detection heuristics to enhance privacy.The concept of private key turnover in CoinSwap is discussed, which involves turning over bilateral control to the swap partner after exchanging the swap secret. This allows for more flexibility and efficiency in the transaction process. Bob, the maker, can merge transactions without coordination with Alice and can fee bump using RBF instead of CPFP, reducing blockchain space usage.In terms of privacy, the conversation highlights the use of false positives in creating a large number of sets of transactions that add up to a certain value by chance, making it difficult for adversaries to identify the user's transactions. Standardized swap amounts are suggested to increase anonymity sets, and the distribution of output values on the blockchain is considered as a factor in achieving privacy.Overall, CoinSwap is seen as a promising method for improving privacy in Bitcoin transactions. However, there are ongoing discussions and proposals to further enhance its effectiveness and address potential limitations.In another topic of discussion, a protocol for traceless atomic swaps within the same chain is mentioned. This protocol involves using a suitably chosen schnorr signature instead of the secret 't' typically used in atomic swaps. The protocol enables parties to exchange funds without revealing their transaction histories.To perform the atomic swap, Alice and Bob provide each other with public keys and create P2PKH addresses where the funds will eventually be sent. They exchange time-locked refund transactions for the funding transactions, and adaptor signatures are used to validate the spending from these addresses. Steps are taken to ensure that the funds cannot be separated or claimed prematurely, while maintaining plausible deniability as the joint private keys are not accessible.The email suggests reaching out to experts in privacy tech for further insights and mentions specific individuals such as belcher, waxwing, and nopara73. Feedback is encouraged, and the author emphasizes the need for consultation with experts to gather more information on these topics. 2020-05-04T08:28:41+00:00 + CoinSwap is a Bitcoin protocol that aims to improve privacy in transactions. However, there are limitations to the current approach of using CoinSwap with mixdepths. While mixdepths can protect against co-spending inputs, they may not be necessary for multi-transaction CoinSwaps where no coins are merged. If coins need to be merged, it is suggested that they should be in the same mixdepth.To address the issue of 1-input-1-output transactions being markers, a proposal is made to use a PayJoin construction for the second transaction. Additionally, Alice can spend her UTXOs in 2-output transactions and manipulate the change output detection heuristics to enhance privacy.The concept of private key turnover in CoinSwap is discussed, which involves turning over bilateral control to the swap partner after exchanging the swap secret. This allows for more flexibility and efficiency in the transaction process. Bob, the maker, can merge transactions without coordination with Alice and can fee bump using RBF instead of CPFP, reducing blockchain space usage.In terms of privacy, the conversation highlights the use of false positives in creating a large number of sets of transactions that add up to a certain value by chance, making it difficult for adversaries to identify the user's transactions. Standardized swap amounts are suggested to increase anonymity sets, and the distribution of output values on the blockchain is considered as a factor in achieving privacy.Overall, CoinSwap is seen as a promising method for improving privacy in Bitcoin transactions. However, there are ongoing discussions and proposals to further enhance its effectiveness and address potential limitations.In another topic of discussion, a protocol for traceless atomic swaps within the same chain is mentioned. This protocol involves using a suitably chosen schnorr signature instead of the secret 't' typically used in atomic swaps. The protocol enables parties to exchange funds without revealing their transaction histories.To perform the atomic swap, Alice and Bob provide each other with public keys and create P2PKH addresses where the funds will eventually be sent. They exchange time-locked refund transactions for the funding transactions, and adaptor signatures are used to validate the spending from these addresses. Steps are taken to ensure that the funds cannot be separated or claimed prematurely, while maintaining plausible deniability as the joint private keys are not accessible.The email suggests reaching out to experts in privacy tech for further insights and mentions specific individuals such as belcher, waxwing, and nopara73. Feedback is encouraged, and the author emphasizes the need for consultation with experts to gather more information on these topics. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_MIN-STANDARD-TX-NONWITNESS-SIZE-and-OP-RETURN.xml b/static/bitcoin-dev/May_2020/combined_MIN-STANDARD-TX-NONWITNESS-SIZE-and-OP-RETURN.xml index 4cb8caee7f..738e938dd2 100644 --- a/static/bitcoin-dev/May_2020/combined_MIN-STANDARD-TX-NONWITNESS-SIZE-and-OP-RETURN.xml +++ b/static/bitcoin-dev/May_2020/combined_MIN-STANDARD-TX-NONWITNESS-SIZE-and-OP-RETURN.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN - 2023-08-02T02:16:26.957790+00:00 - - Russell O'Connor 2020-05-27 15:15:47+00:00 - - - ZmnSCPxj 2020-05-24 00:52:13+00:00 - - - Greg Sanders 2020-05-23 15:25:06+00:00 - - - Greg Sanders 2020-05-23 15:24:28+00:00 - - - Thomas Voegtlin 2020-05-23 14:49:03+00:00 - + 2025-09-26T15:35:53.512436+00:00 + python-feedgen + + + [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN Thomas Voegtlin + 2020-05-23T14:49:00.000Z + + + Greg Sanders + 2020-05-23T15:24:00.000Z + + + Greg Sanders + 2020-05-23T15:25:00.000Z + + + ZmnSCPxj + 2020-05-24T00:52:00.000Z + + + Russell O'Connor + 2020-05-27T15:15:00.000Z + + - python-feedgen + 2 Combined summary - MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN - 2023-08-02T02:16:26.957790+00:00 + 2025-09-26T15:35:53.513178+00:00 - In a recent discussion on the bitcoin-dev mailing list, Thomas Voegtlin raised a question regarding the minimum transaction size of 82 bytes. He was specifically concerned about constructing a 60-byte transaction that was being rejected due to this requirement. ZmnSCPxj, another member of the mailing list, responded by explaining that the high minimum size is in place to protect against an attack known as CVE-2017-12842. This attack involves using a 32-bit hash collision to create a 'bad' block. ZmnSCPxj further elaborated that even with SHA256 padding, which includes a length value of the original message data, accepting 60-byte transactions could still leave them vulnerable to attacks. The discussion concluded that it may be safe to accept 65-byte or larger transactions, but this would not solve Thomas's specific issue. Additionally, it was noted that SHA256 also includes padding that ensures messages of different lengths have different padding.Another aspect of the discussion focused on the reasoning behind the current minimum transaction size and the potential vulnerabilities associated with smaller transactions. Greg Sanders joined the discussion and mentioned that the number was chosen to protect against the CVE-2017-12842 attack covertly. He shared a link to the pull request that updated the text explicitly mentioning this fact. The consensus among the participants of the discussion was that lowering the minimum transaction size to 60 bytes could pose security threats and risks. Therefore, it was deemed more feasible to maintain the current value of 82 bytes.The issue brought up by Thomas Voegtlin pertained to his attempt to CPFP (Child Pays For Parent) a transaction using OP_RETURN. Due to the remaining output value being lower than the dust threshold, the scriptPubkey of the output became OP_RETURN + OP_0 with a single p2wsh input. As a result, the transaction size without witness was 60 bytes, which fell below the MIN_STANDARD_TX_NONWITNESS_SIZE requirement of 82 bytes. Thomas questioned why this value was set so high and suggested lowering it to 60 bytes. Greg Sanders explained that the higher value was chosen to protect against CVE-2017-12842 covertly. He shared a link to the pull request on GitHub that explicitly mentioned this fact.Thomas Voegtlin's inquiry highlights the need for understanding the various requirements and protections within the Bitcoin network. The response from the mailing list members provides valuable insight into the reasoning behind certain standards, such as MIN_STANDARD_TX_NONWITNESS_SIZE. It is crucial for developers and users to stay informed and up-to-date on these standards to ensure the safety and efficiency of transactions in the network. 2020-05-27T15:15:47+00:00 + In a recent discussion on the bitcoin-dev mailing list, Thomas Voegtlin raised a question regarding the minimum transaction size of 82 bytes. He was specifically concerned about constructing a 60-byte transaction that was being rejected due to this requirement. ZmnSCPxj, another member of the mailing list, responded by explaining that the high minimum size is in place to protect against an attack known as CVE-2017-12842. This attack involves using a 32-bit hash collision to create a 'bad' block. ZmnSCPxj further elaborated that even with SHA256 padding, which includes a length value of the original message data, accepting 60-byte transactions could still leave them vulnerable to attacks. The discussion concluded that it may be safe to accept 65-byte or larger transactions, but this would not solve Thomas's specific issue. Additionally, it was noted that SHA256 also includes padding that ensures messages of different lengths have different padding.Another aspect of the discussion focused on the reasoning behind the current minimum transaction size and the potential vulnerabilities associated with smaller transactions. Greg Sanders joined the discussion and mentioned that the number was chosen to protect against the CVE-2017-12842 attack covertly. He shared a link to the pull request that updated the text explicitly mentioning this fact. The consensus among the participants of the discussion was that lowering the minimum transaction size to 60 bytes could pose security threats and risks. Therefore, it was deemed more feasible to maintain the current value of 82 bytes.The issue brought up by Thomas Voegtlin pertained to his attempt to CPFP (Child Pays For Parent) a transaction using OP_RETURN. Due to the remaining output value being lower than the dust threshold, the scriptPubkey of the output became OP_RETURN + OP_0 with a single p2wsh input. As a result, the transaction size without witness was 60 bytes, which fell below the MIN_STANDARD_TX_NONWITNESS_SIZE requirement of 82 bytes. Thomas questioned why this value was set so high and suggested lowering it to 60 bytes. Greg Sanders explained that the higher value was chosen to protect against CVE-2017-12842 covertly. He shared a link to the pull request on GitHub that explicitly mentioned this fact.Thomas Voegtlin's inquiry highlights the need for understanding the various requirements and protections within the Bitcoin network. The response from the mailing list members provides valuable insight into the reasoning behind certain standards, such as MIN_STANDARD_TX_NONWITNESS_SIZE. It is crucial for developers and users to stay informed and up-to-date on these standards to ensure the safety and efficiency of transactions in the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_On-the-scalability-issues-of-onboarding-millions-of-LN-mobile-clients.xml b/static/bitcoin-dev/May_2020/combined_On-the-scalability-issues-of-onboarding-millions-of-LN-mobile-clients.xml index c42eafa374..77d0282304 100644 --- a/static/bitcoin-dev/May_2020/combined_On-the-scalability-issues-of-onboarding-millions-of-LN-mobile-clients.xml +++ b/static/bitcoin-dev/May_2020/combined_On-the-scalability-issues-of-onboarding-millions-of-LN-mobile-clients.xml @@ -1,101 +1,135 @@ - + 2 Combined summary - On the scalability issues of onboarding millions of LN mobile clients - 2023-08-02T02:11:33.606489+00:00 - - Christopher Allen 2020-05-17 09:11:33+00:00 - - - Antoine Riard 2020-05-17 03:37:46+00:00 - - - William Casarin 2020-05-14 15:27:11+00:00 - - - Keagan McClelland 2020-05-14 15:25:57+00:00 - - - ZmnSCPxj 2020-05-14 04:02:07+00:00 - - - Antoine Riard 2020-05-13 19:51:29+00:00 - - - Chris Belcher 2020-05-12 21:05:46+00:00 - - - ZmnSCPxj 2020-05-12 15:48:30+00:00 - - - Richard Myers 2020-05-12 10:09:34+00:00 - - - ZmnSCPxj 2020-05-11 05:44:08+00:00 - - - Antoine Riard 2020-05-09 07:48:33+00:00 - - - Antoine Riard 2020-05-09 07:22:52+00:00 - - - Christopher Allen 2020-05-08 21:29:48+00:00 - - - Braydon Fuller 2020-05-08 20:22:30+00:00 - - - Keagan McClelland 2020-05-08 20:01:40+00:00 - - - Braydon Fuller 2020-05-08 19:51:15+00:00 - - - Braydon Fuller 2020-05-08 19:33:55+00:00 - - - Igor Cota 2020-05-07 16:40:49+00:00 - - - Keagan McClelland 2020-05-07 04:07:09+00:00 - - - Antoine Riard 2020-05-07 03:56:17+00:00 - - - Keagan McClelland 2020-05-06 16:00:15+00:00 - - - Antoine Riard 2020-05-06 09:40:06+00:00 - - - Antoine Riard 2020-05-06 09:21:17+00:00 - - - Antoine Riard 2020-05-06 09:06:11+00:00 - - - Antoine Riard 2020-05-06 08:27:45+00:00 - - - Olaoluwa Osuntokun 2020-05-06 00:31:32+00:00 - - - John Newbery 2020-05-05 17:09:33+00:00 - - - Lloyd Fournier 2020-05-05 15:16:01+00:00 - - - ZmnSCPxj 2020-05-05 13:49:58+00:00 - - - Luke Dashjr 2020-05-05 13:00:37+00:00 - - - Antoine Riard 2020-05-05 10:17:37+00:00 - + 2025-09-26T15:35:57.754412+00:00 + python-feedgen + + + [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients Antoine Riard + 2020-05-05T10:17:00.000Z + + + Luke Dashjr + 2020-05-05T13:00:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2020-05-05T13:49:00.000Z + + + [bitcoin-dev] " Lloyd Fournier + 2020-05-05T15:16:00.000Z + + + John Newbery + 2020-05-05T17:09:00.000Z + + + Olaoluwa Osuntokun + 2020-05-06T00:31:00.000Z + + + Antoine Riard + 2020-05-06T08:27:00.000Z + + + [bitcoin-dev] " Antoine Riard + 2020-05-06T09:06:00.000Z + + + Antoine Riard + 2020-05-06T09:21:00.000Z + + + Antoine Riard + 2020-05-06T09:40:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Keagan McClelland + 2020-05-06T16:00:00.000Z + + + Antoine Riard + 2020-05-07T03:56:00.000Z + + + Keagan McClelland + 2020-05-07T04:07:00.000Z + + + Igor Cota + 2020-05-07T16:40:00.000Z + + + Braydon Fuller + 2020-05-08T19:33:00.000Z + + + Braydon Fuller + 2020-05-08T19:51:00.000Z + + + Keagan McClelland + 2020-05-08T20:01:00.000Z + + + Braydon Fuller + 2020-05-08T20:22:00.000Z + + + Christopher Allen + 2020-05-08T21:29:00.000Z + + + Antoine Riard + 2020-05-09T07:22:00.000Z + + + Antoine Riard + 2020-05-09T07:48:00.000Z + + + ZmnSCPxj + 2020-05-11T05:44:00.000Z + + + Richard Myers + 2020-05-12T10:09:00.000Z + + + ZmnSCPxj + 2020-05-12T15:48:00.000Z + + + Chris Belcher + 2020-05-12T21:05:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Antoine Riard + 2020-05-13T19:51:00.000Z + + + ZmnSCPxj + 2020-05-14T04:02:00.000Z + + + Keagan McClelland + 2020-05-14T15:25:00.000Z + + + William Casarin + 2020-05-14T15:27:00.000Z + + + Antoine Riard + 2020-05-17T03:37:00.000Z + + + Christopher Allen + 2020-05-17T09:11:00.000Z + + @@ -127,13 +161,13 @@ - python-feedgen + 2 Combined summary - On the scalability issues of onboarding millions of LN mobile clients - 2023-08-02T02:11:33.606489+00:00 + 2025-09-26T15:35:57.757632+00:00 - The email conversation revolves around improving the user experience of connecting a mobile Lightning Network client to a home full node. Currently, a solution called QuickConnect exists, but it still needs further development. Contributions to requirements and proposals for the next version are welcome.The discussion explores the potential of Lightning Network replacing centralized custodial services, which would allow for scalability while maintaining noncustodiality. Evaluating economic weight in Lightning is challenging due to different chain views. The implementation of backup servers that are publicly-facing is suggested, but ensuring uniform distribution is difficult in a free market. An alternative solution proposed is to have everyone run a privately-owned server, similar to having a Lightning node at home with a full node accessed via a remote control mobile device.The conversation also highlights the importance of combining UX, user education, and fallback security mechanisms to avoid economy hijack. The economic weight of nodes is discussed in evaluating miner consensus-hijack success. The hope is that Lightning will replace centralized custodial services, but there are concerns about compromising Bitcoin's security model. It is emphasized that a supermajority of the economy should be verifying transactions using their own full nodes to prevent potential attacks and splits in the system.Another topic of discussion is the challenges faced by off-grid nodes relying on local network peers for blockchain information. Possible solutions include using prepaid tokens issued by validation-information-providers or utilizing watchtower service providers. Privacy concerns when public-service nodes serve generic headers to light clients are also addressed, with a suggestion to use Tor for accessing public-service nodes and decorrelating payments for services.In addition, proposals are made for defining different sets of wallet functionality to inform the future of core wallet functionality. A collaboration is suggested to work on this, starting with a transparent shim between bitcoin-core and remote RPC. The idea of running full nodes on mobile phones as part-time or Sleeper Nodes is also proposed.The challenges in designing a scalable, secure, and private chain access backend for Lightning Network clients are discussed. Compensating node operators for servicing filters may be necessary, but avoiding market concentration is a concern.Finally, the need for an interface between a peer and owner interface is expressed, with suggestions for a cryptographic capability mechanism that allows remote wallets to request specific node functions and additional authorization for rarer services. Blockchain Commons expresses interest in hosting a collaboration to define different sets of wallet functionality for future core wallet improvements.In an email conversation, Keagan McClelland and others discussed the limitations of the RPC interface in Bitcoin Core and the need for a peer service model between "full public" and "owner only" interfaces. The RPC interface exposes unnecessary functionality and introduces risks. Keagan suggests that light clients should explicitly choose their full node tethers to limit peer services to authenticated peers. However, there are concerns about consensus capture by economically weighty institutions.Antoine Riard discusses the potential scalability issues of BIP 157 and highlights the positive aspect of BIP 157+158's protocol, which would make serving light clients stateless. This allows for the servability of the entire protocol over HTTP, taking advantage of established CDNs and anycast serving infrastructure. Compact block filters can be useful due to their statelessness, as they eliminate the inefficiencies of Bloom filters for blocks.Igor Cota suggests exploring the feasibility of running full nodes on everyday phones as an alternative to relying on a few thousand full-node operators servicing Lightning Network mobile clients. He proposes part-time or Sleeper Nodes™ that work while their operator is asleep, allowing mobile nodes to earn their keep. Antoine Riard discusses the ongoing advancement of BIP 157 implementation in Core and the future of light client protocols. He suggests introducing monetary compensation for servicing filters to incentivize full node operators.The discussion also revolves around externalizing the costs of security from light clients onto full nodes. It is suggested that having light clients choose their full node tethers explicitly could be a solution, but there are concerns about consensus capture by economically weighty institutions. Luke Dashjr opposes improving the "full node-less" experience, stating that it compromises Bitcoin's security assumption. All efforts to improve the "full node-less" experience should be actively avoided.The scalability of light client protocols for Lightning Network is discussed, along with the need for a scalable, secure, private chain access backend for millions of LN clients. The current trust-minimization paradigm may be shifted by LN, but efforts to improve the "full node-less" experience should be avoided. Monetary compensation can be introduced in exchange for servicing filters, and LSATs can be used to add a lightweight payment mechanism.The implementation of BIP 157 protocol in Core is also discussed. Arguments against light clients are restated, but the choice is whether to offer a better or worse light client technology. The benefits of BIP 157 over existing technologies are summarized, including uniqueness for a block and being less prone to DoS attacks. Opponents to merging support for BIP 157 argue that 2020-05-17T09:11:33+00:00 + The email conversation revolves around improving the user experience of connecting a mobile Lightning Network client to a home full node. Currently, a solution called QuickConnect exists, but it still needs further development. Contributions to requirements and proposals for the next version are welcome.The discussion explores the potential of Lightning Network replacing centralized custodial services, which would allow for scalability while maintaining noncustodiality. Evaluating economic weight in Lightning is challenging due to different chain views. The implementation of backup servers that are publicly-facing is suggested, but ensuring uniform distribution is difficult in a free market. An alternative solution proposed is to have everyone run a privately-owned server, similar to having a Lightning node at home with a full node accessed via a remote control mobile device.The conversation also highlights the importance of combining UX, user education, and fallback security mechanisms to avoid economy hijack. The economic weight of nodes is discussed in evaluating miner consensus-hijack success. The hope is that Lightning will replace centralized custodial services, but there are concerns about compromising Bitcoin's security model. It is emphasized that a supermajority of the economy should be verifying transactions using their own full nodes to prevent potential attacks and splits in the system.Another topic of discussion is the challenges faced by off-grid nodes relying on local network peers for blockchain information. Possible solutions include using prepaid tokens issued by validation-information-providers or utilizing watchtower service providers. Privacy concerns when public-service nodes serve generic headers to light clients are also addressed, with a suggestion to use Tor for accessing public-service nodes and decorrelating payments for services.In addition, proposals are made for defining different sets of wallet functionality to inform the future of core wallet functionality. A collaboration is suggested to work on this, starting with a transparent shim between bitcoin-core and remote RPC. The idea of running full nodes on mobile phones as part-time or Sleeper Nodes is also proposed.The challenges in designing a scalable, secure, and private chain access backend for Lightning Network clients are discussed. Compensating node operators for servicing filters may be necessary, but avoiding market concentration is a concern.Finally, the need for an interface between a peer and owner interface is expressed, with suggestions for a cryptographic capability mechanism that allows remote wallets to request specific node functions and additional authorization for rarer services. Blockchain Commons expresses interest in hosting a collaboration to define different sets of wallet functionality for future core wallet improvements.In an email conversation, Keagan McClelland and others discussed the limitations of the RPC interface in Bitcoin Core and the need for a peer service model between "full public" and "owner only" interfaces. The RPC interface exposes unnecessary functionality and introduces risks. Keagan suggests that light clients should explicitly choose their full node tethers to limit peer services to authenticated peers. However, there are concerns about consensus capture by economically weighty institutions.Antoine Riard discusses the potential scalability issues of BIP 157 and highlights the positive aspect of BIP 157+158's protocol, which would make serving light clients stateless. This allows for the servability of the entire protocol over HTTP, taking advantage of established CDNs and anycast serving infrastructure. Compact block filters can be useful due to their statelessness, as they eliminate the inefficiencies of Bloom filters for blocks.Igor Cota suggests exploring the feasibility of running full nodes on everyday phones as an alternative to relying on a few thousand full-node operators servicing Lightning Network mobile clients. He proposes part-time or Sleeper Nodes™ that work while their operator is asleep, allowing mobile nodes to earn their keep. Antoine Riard discusses the ongoing advancement of BIP 157 implementation in Core and the future of light client protocols. He suggests introducing monetary compensation for servicing filters to incentivize full node operators.The discussion also revolves around externalizing the costs of security from light clients onto full nodes. It is suggested that having light clients choose their full node tethers explicitly could be a solution, but there are concerns about consensus capture by economically weighty institutions. Luke Dashjr opposes improving the "full node-less" experience, stating that it compromises Bitcoin's security assumption. All efforts to improve the "full node-less" experience should be actively avoided.The scalability of light client protocols for Lightning Network is discussed, along with the need for a scalable, secure, private chain access backend for millions of LN clients. The current trust-minimization paradigm may be shifted by LN, but efforts to improve the "full node-less" experience should be avoided. Monetary compensation can be introduced in exchange for servicing filters, and LSATs can be used to add a lightweight payment mechanism.The implementation of BIP 157 protocol in Core is also discussed. Arguments against light clients are restated, but the choice is whether to offer a better or worse light client technology. The benefits of BIP 157 over existing technologies are summarized, including uniqueness for a block and being less prone to DoS attacks. Opponents to merging support for BIP 157 argue that - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_Post-mix-coinjoin-usage-with-multisig-and-cpfp-in-bitcoin-core-wallet.xml b/static/bitcoin-dev/May_2020/combined_Post-mix-coinjoin-usage-with-multisig-and-cpfp-in-bitcoin-core-wallet.xml index 7ea666c4fe..e35bf3cd80 100644 --- a/static/bitcoin-dev/May_2020/combined_Post-mix-coinjoin-usage-with-multisig-and-cpfp-in-bitcoin-core-wallet.xml +++ b/static/bitcoin-dev/May_2020/combined_Post-mix-coinjoin-usage-with-multisig-and-cpfp-in-bitcoin-core-wallet.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet - 2023-08-02T02:16:53.842674+00:00 - - ZmnSCPxj 2020-05-27 04:11:47+00:00 - - - Prayank 2020-05-26 12:50:03+00:00 - - - ZmnSCPxj 2020-05-26 02:46:07+00:00 - - - prayank at tutanota.de 2020-05-25 12:16:10+00:00 - - - ZmnSCPxj 2020-05-25 06:54:27+00:00 - - - prayank at tutanota.de 2020-05-24 21:44:27+00:00 - + 2025-09-26T15:35:51.421051+00:00 + python-feedgen + + + [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet prayank + 2020-05-24T21:44:00.000Z + + + ZmnSCPxj + 2020-05-25T06:54:00.000Z + + + prayank + 2020-05-25T12:16:00.000Z + + + ZmnSCPxj + 2020-05-26T02:46:00.000Z + + + Prayank + 2020-05-26T12:50:00.000Z + + + ZmnSCPxj + 2020-05-27T04:11:00.000Z + + - python-feedgen + 2 Combined summary - Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet - 2023-08-02T02:16:53.842674+00:00 + 2025-09-26T15:35:51.421981+00:00 - The email conversation revolves around finding a secure method to spend coins after coinjoin. The proposed solution involves using multisig transactions with three parties and reviewing outputs before confirming the transaction. In case of disputes, the system can become complex by locking some amount of money in a 2 of 2 multisig or using incentive structures. The focus is on post-mix usage, which is equally important as coinjoin, and aims to make it difficult for people trying to monitor transactions. JoinMarket already has a PayJoin implementation, but the proposed technique is not too different from what JoinMarket already does for normal sends. However, a chain of such mixers could work better if done correctly.The discussion also touches on the use of multisig for privacy and how Schnorr and Taproot can improve its usage. Multisig usage may not be ideal currently, but better privacy for multisig will enable the implementation of various ideas on Bitcoin using different multisig setups and combinations of other available tools. The goal is to provide users with more options to spend UTXOs easily in different ways after coinjoin, making it challenging for people to analyze transactions or algorithms monitoring and flagging reporting txs 24/7.In the email exchange, Prayank clarifies that Peer 1 does not need to be a trusted third party. Instead, some peers involved in the system can provide liquidity for others, and incentives can be provided through small fees. By having different ways to mix, it becomes harder for spy companies to analyze transactions. Prayank believes that one such setup might not make a huge difference, but a chain of such mixers will work better if everything is done correctly. Better privacy for multisig will open up possibilities for implementing numerous ideas on Bitcoin using different multisig setups and combinations of other available tools.ZmnSCPxj provides an article on protocol design for privacy and seeks clarification on Prayank's overall goals. Prayank explains that his intention is to contribute and add more options for people to improve privacy on Bitcoin. He states that JoinMarket already has a superior technology, but he wants to explore different mixing options to make it harder for spy companies to analyze transactions.ZmnSCPxj confirms understanding Prayank's proposal and mentions that JoinMarket does not require a trusted third party. Instead, it involves one or more untrusted third parties participating in signing a single transaction without the need for an intermediate m-of-n address. JoinMarket allows the market taker to determine the equal-value outputs and define the destination address, which can be controlled by the payee. ZmnSCPxj shares that JoinMarket includes information on how to connect with enabling third parties called "market makers."ZmnSCPxj explains his idea of post-mix usage using multisig and CPFP in a Medium article. The protocol involves three participants: Peer 3 as the payee, Peer 2 as the payer, and Peer 1 as an enabling trusted third party. The goal is for Peer 2 to pay 0.006BTC to Peer 3. The protocol consists of three steps: computing a 2-of-3 address with the public keys of Peer 2, Peer 1, and Peer 3, individually paying their owned funds to the 2-of-3 address, and consuming the new outputs into another transaction with equal-valued outputs to hide coin ownership. ZmnSCPxj confirms understanding the protocol and suggests that JoinMarket's technology eliminates the need for a trusted third party and provides flexibility in determining output values and destinations.The author shares a proof of concept in a Medium article, demonstrating the use of multisig and CPFP for post-mix usage. They seek feedback on potentially adding these options to the Bitcoin Core wallet, particularly with the upcoming taproot upgrade and its impact on privacy for multisig transactions. The author references Peter Wuille's response on Reddit, which suggests that taproot could indeed improve privacy for multisig. Ultimately, the author is seeking input to further develop their idea beyond just an article on Medium. 2020-05-27T04:11:47+00:00 + The email conversation revolves around finding a secure method to spend coins after coinjoin. The proposed solution involves using multisig transactions with three parties and reviewing outputs before confirming the transaction. In case of disputes, the system can become complex by locking some amount of money in a 2 of 2 multisig or using incentive structures. The focus is on post-mix usage, which is equally important as coinjoin, and aims to make it difficult for people trying to monitor transactions. JoinMarket already has a PayJoin implementation, but the proposed technique is not too different from what JoinMarket already does for normal sends. However, a chain of such mixers could work better if done correctly.The discussion also touches on the use of multisig for privacy and how Schnorr and Taproot can improve its usage. Multisig usage may not be ideal currently, but better privacy for multisig will enable the implementation of various ideas on Bitcoin using different multisig setups and combinations of other available tools. The goal is to provide users with more options to spend UTXOs easily in different ways after coinjoin, making it challenging for people to analyze transactions or algorithms monitoring and flagging reporting txs 24/7.In the email exchange, Prayank clarifies that Peer 1 does not need to be a trusted third party. Instead, some peers involved in the system can provide liquidity for others, and incentives can be provided through small fees. By having different ways to mix, it becomes harder for spy companies to analyze transactions. Prayank believes that one such setup might not make a huge difference, but a chain of such mixers will work better if everything is done correctly. Better privacy for multisig will open up possibilities for implementing numerous ideas on Bitcoin using different multisig setups and combinations of other available tools.ZmnSCPxj provides an article on protocol design for privacy and seeks clarification on Prayank's overall goals. Prayank explains that his intention is to contribute and add more options for people to improve privacy on Bitcoin. He states that JoinMarket already has a superior technology, but he wants to explore different mixing options to make it harder for spy companies to analyze transactions.ZmnSCPxj confirms understanding Prayank's proposal and mentions that JoinMarket does not require a trusted third party. Instead, it involves one or more untrusted third parties participating in signing a single transaction without the need for an intermediate m-of-n address. JoinMarket allows the market taker to determine the equal-value outputs and define the destination address, which can be controlled by the payee. ZmnSCPxj shares that JoinMarket includes information on how to connect with enabling third parties called "market makers."ZmnSCPxj explains his idea of post-mix usage using multisig and CPFP in a Medium article. The protocol involves three participants: Peer 3 as the payee, Peer 2 as the payer, and Peer 1 as an enabling trusted third party. The goal is for Peer 2 to pay 0.006BTC to Peer 3. The protocol consists of three steps: computing a 2-of-3 address with the public keys of Peer 2, Peer 1, and Peer 3, individually paying their owned funds to the 2-of-3 address, and consuming the new outputs into another transaction with equal-valued outputs to hide coin ownership. ZmnSCPxj confirms understanding the protocol and suggests that JoinMarket's technology eliminates the need for a trusted third party and provides flexibility in determining output values and destinations.The author shares a proof of concept in a Medium article, demonstrating the use of multisig and CPFP for post-mix usage. They seek feedback on potentially adding these options to the Bitcoin Core wallet, particularly with the upcoming taproot upgrade and its impact on privacy for multisig transactions. The author references Peter Wuille's response on Reddit, which suggests that taproot could indeed improve privacy for multisig. Ultimately, the author is seeking input to further develop their idea beyond just an article on Medium. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_Revault-a-multi-party-vault-architecture.xml b/static/bitcoin-dev/May_2020/combined_Revault-a-multi-party-vault-architecture.xml index 45bc15d4b9..3a39ac1873 100644 --- a/static/bitcoin-dev/May_2020/combined_Revault-a-multi-party-vault-architecture.xml +++ b/static/bitcoin-dev/May_2020/combined_Revault-a-multi-party-vault-architecture.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Revault: a multi-party vault architecture - 2023-08-02T02:06:47.849604+00:00 - - darosior 2020-05-08 10:34:49+00:00 - - - darosior 2020-04-24 15:00:16+00:00 - + 2025-09-26T15:35:45.086144+00:00 + python-feedgen + + + [bitcoin-dev] Revault: a multi-party vault architecture darosior + 2020-04-24T15:00:00.000Z + + + darosior + 2020-05-08T10:34:00.000Z + + - python-feedgen + 2 Combined summary - Revault: a multi-party vault architecture - 2023-08-02T02:06:47.849604+00:00 + 2025-09-26T15:35:45.086626+00:00 - Antoine and Kevin have developed a new multiparty vault architecture called Revault, which aims to secure shared storage of coins without relying on a trusted third party and disincentivizing theft attempts. The system uses N-of-N multisigs and relies on pre-signed and revocable transactions. However, it does not protect against intentional locking of funds, so users are expected to solve blockage issues outside the Bitcoin network through legal contracts.Revault utilizes six transaction types: Vault Transaction, Emergency Transaction, Unvault Transaction, Unvault Emergency Transaction, Cancel Transaction, and Spend Transaction. Stakeholders exchange the signatures of all the revaulting transactions after receiving a new vault utxo and then exchange the signatures of the unvaulting transaction before proceeding. Until this process is complete, the coins are not available to be spent.To avoid weak security assumptions, stakeholders exchange SINGLE | ANYONECANPAY signatures for the revaulting transactions and append their own as SIGHASH_ALL before broadcasting. They also have the option to add an additional input (and potentially output) to increase fees. This protection leverages the fact that revaulting transactions only have one input and one output, with the change being part of the spend transaction.In order to cover a feerate increase after broadcast, revaulting transactions may signal for RBF. However, the fee bumping construction is potentially vulnerable to transaction pinning. To address this, ALL | ANYONECANPAY signatures are now exchanged for revaulting transactions, restricting the creation of a new output only spendable by one party.The fee bumping process is now done in two stages to avoid consuming an entire UTXO. If any issues arise, any stakeholder can trigger an emergency transaction at any point.The architecture was first designed by Kevin Loaec, who was hired by NOIA for this purpose. It was inspired by Bryan Bishop's single-party vault architecture. A work-in-progress draft/demo/PoC is available on Github, which uses 4 stakeholders, 2 or 3 traders, a CSV of 6 blocks for the unvault script, and a CSV of approximately 1 month for the emergency scripts. The detailed transactions used can be found in the doc/ directory of the same repository and are coded in the revault/transactions/ module. 2020-05-08T10:34:49+00:00 + Antoine and Kevin have developed a new multiparty vault architecture called Revault, which aims to secure shared storage of coins without relying on a trusted third party and disincentivizing theft attempts. The system uses N-of-N multisigs and relies on pre-signed and revocable transactions. However, it does not protect against intentional locking of funds, so users are expected to solve blockage issues outside the Bitcoin network through legal contracts.Revault utilizes six transaction types: Vault Transaction, Emergency Transaction, Unvault Transaction, Unvault Emergency Transaction, Cancel Transaction, and Spend Transaction. Stakeholders exchange the signatures of all the revaulting transactions after receiving a new vault utxo and then exchange the signatures of the unvaulting transaction before proceeding. Until this process is complete, the coins are not available to be spent.To avoid weak security assumptions, stakeholders exchange SINGLE | ANYONECANPAY signatures for the revaulting transactions and append their own as SIGHASH_ALL before broadcasting. They also have the option to add an additional input (and potentially output) to increase fees. This protection leverages the fact that revaulting transactions only have one input and one output, with the change being part of the spend transaction.In order to cover a feerate increase after broadcast, revaulting transactions may signal for RBF. However, the fee bumping construction is potentially vulnerable to transaction pinning. To address this, ALL | ANYONECANPAY signatures are now exchanged for revaulting transactions, restricting the creation of a new output only spendable by one party.The fee bumping process is now done in two stages to avoid consuming an entire UTXO. If any issues arise, any stakeholder can trigger an emergency transaction at any point.The architecture was first designed by Kevin Loaec, who was hired by NOIA for this purpose. It was inspired by Bryan Bishop's single-party vault architecture. A work-in-progress draft/demo/PoC is available on Github, which uses 4 stakeholders, 2 or 3 traders, a CSV of 6 blocks for the unvault script, and a CSV of approximately 1 month for the emergency scripts. The detailed transactions used can be found in the doc/ directory of the same repository and are coded in the revault/transactions/ module. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_SAS-Succinct-Atomic-Swap.xml b/static/bitcoin-dev/May_2020/combined_SAS-Succinct-Atomic-Swap.xml index 9165561c45..2ec0e393ca 100644 --- a/static/bitcoin-dev/May_2020/combined_SAS-Succinct-Atomic-Swap.xml +++ b/static/bitcoin-dev/May_2020/combined_SAS-Succinct-Atomic-Swap.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - SAS: Succinct Atomic Swap - 2023-08-02T02:13:08.885550+00:00 - - ZmnSCPxj 2020-06-03 14:36:46+00:00 - - - Dmitry Petukhov 2020-06-03 09:04:25+00:00 - - - Ruben Somsen 2020-05-15 19:47:29+00:00 - - - ZmnSCPxj 2020-05-15 04:39:33+00:00 - - - Ruben Somsen 2020-05-13 12:33:21+00:00 - - - ZmnSCPxj 2020-05-13 11:39:10+00:00 - - - Ruben Somsen 2020-05-13 09:58:26+00:00 - - - Ruben Somsen 2020-05-13 09:57:05+00:00 - - - ZmnSCPxj 2020-05-13 08:39:37+00:00 - - - Chris Belcher 2020-05-12 22:50:10+00:00 - - - Ruben Somsen 2020-05-12 16:30:26+00:00 - - - ZmnSCPxj 2020-05-12 15:05:57+00:00 - - - Ruben Somsen 2020-05-12 11:34:17+00:00 - - - Ruben Somsen 2020-05-12 11:30:38+00:00 - - - Lloyd Fournier 2020-05-12 06:50:31+00:00 - - - Lloyd Fournier 2020-05-12 06:10:47+00:00 - - - ZmnSCPxj 2020-05-12 04:41:43+00:00 - - - Ruben Somsen 2020-05-11 17:50:21+00:00 - - - ZmnSCPxj 2020-05-11 16:45:21+00:00 - - - Ruben Somsen 2020-05-11 15:29:51+00:00 - + 2025-09-26T15:36:02.000101+00:00 + python-feedgen + + + [bitcoin-dev] SAS: Succinct Atomic Swap Ruben Somsen + 2020-05-11T15:29:00.000Z + + + ZmnSCPxj + 2020-05-11T16:45:00.000Z + + + Ruben Somsen + 2020-05-11T17:50:00.000Z + + + ZmnSCPxj + 2020-05-12T04:41:00.000Z + + + Lloyd Fournier + 2020-05-12T06:10:00.000Z + + + Lloyd Fournier + 2020-05-12T06:50:00.000Z + + + Ruben Somsen + 2020-05-12T11:30:00.000Z + + + Ruben Somsen + 2020-05-12T11:34:00.000Z + + + ZmnSCPxj + 2020-05-12T15:05:00.000Z + + + Ruben Somsen + 2020-05-12T16:30:00.000Z + + + Chris Belcher + 2020-05-12T22:50:00.000Z + + + ZmnSCPxj + 2020-05-13T08:39:00.000Z + + + Ruben Somsen + 2020-05-13T09:57:00.000Z + + + Ruben Somsen + 2020-05-13T09:58:00.000Z + + + ZmnSCPxj + 2020-05-13T11:39:00.000Z + + + Ruben Somsen + 2020-05-13T12:33:00.000Z + + + ZmnSCPxj + 2020-05-15T04:39:00.000Z + + + Ruben Somsen + 2020-05-15T19:47:00.000Z + + + Dmitry Petukhov + 2020-06-03T09:04:00.000Z + + + ZmnSCPxj + 2020-06-03T14:36:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - SAS: Succinct Atomic Swap - 2023-08-02T02:13:08.885550+00:00 + 2025-09-26T15:36:02.002524+00:00 - In an email conversation, ZmnSCPxj informs Dmitry about creating a version of the TLA+ spec in the 'variant_ZmnSCPxj' branch of the SASwap repo. However, there is a possible deadlock after step 9 if Bob fails to publish a success transaction on time. To address this issue, Bob will have a short timeout period after which he will force publication of the success transaction if Alice does not respond. Running multiple servers can mitigate accidents due to computer crashes. A dead man switch system can countermand the main server in such situations. The probability of accidents occurring can be reduced to negligible levels.In another discussion between Ruben and ZmnSCPxj, they discuss the possibility of chaos if Bob neglects to broadcast the success tx before refund tx #1 becomes valid. They propose using sighash_single + anyonecanpay to ensure the TXO is spent before refund tx #1 becomes valid. They also suggest that in a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. Bob should spend his UTXO first to reduce resource wastage. They also discuss how Bob can specify address/value pairs in the success tx, allowing for additional flexibility later.The conversation revolves around a hypothetical situation where Alice and Bob are participating in a protocol. There are concerns about potential chaos if Bob misses the deadline for broadcasting the success tx. It is suggested that Bob should broadcast the success tx before refund tx #1 becomes valid. In a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. It is also important for Bob to spend his UTXO first to minimize resource waste. Additionally, there is a discussion about the use of private key handover and the risks associated with it.In a discussion between Ruben and ZmnSCPxj, they discuss potential issues with a proposed Lightning Network protocol. One concern is the possibility of chaos if Bob lets refund tx #1 become valid after completing the protocol. Another concern is the risk of both Alice and Bob knowing all the secrets on the LTC side and competing over it. The use of multiple CPFP outpoints is suggested to prevent pinning. They also discuss the need for backup watchers in case of irrational behavior.The conversation discusses a proposed protocol where Alice and Bob share secrets on the Litecoin (LTC) side and compete for it. Potential issues with the proposal are highlighted, including the risk of competing revoke transactions and the use of refund transactions that could lead to chaos if broadcasted. The need for a backup watcher is emphasized. The proposal is compared to Lightning Network's HTLCs and the benefits of spending the revoke transaction before or after its absolute timelock period are discussed.The email conversation discusses the use of private key handover for old-style coinswaps to mitigate potential issues with the traditional four-transaction swap. A proposal involving a shortened refund transaction is mentioned, but ZmnSCPxj notes an issue where Bob can give a copy of the revoke tx directly to a miner, forcing Alice to take three transactions to back out of the swap. Mitigation strategies, such as using CPFP outputs and minimum relayable feerate, are discussed. The safest alternative is for Bob to spend before the timelock expires.The conversation between Ruben and ZmnSCPxj discusses the technicalities of conducting a secure and efficient coinswap. Ruben proposes a pre-swap setup to reduce privacy concerns, while ZmnSCPxj suggests using relative timelocks and private key handover. The conversation delves into the specifics of the protocol, potential risks, and mitigation strategies. The importance of running multiple servers to ensure timely execution of transactions is emphasized.The email exchange between Ruben and ZmnSCPxj discusses a proposed CoinSwap protocol and its potential vulnerabilities. The concern is that if Bob misses the deadline, Alice will reclaim the funds. Different proposals are discussed, including using CPFP outputs and minimum relayable feerate. The safety of spending before the timelock expires is highlighted.The email exchange discusses a proposed coinswap scheme with improved scalability and privacy. The conversation highlights the use of relative timelocks and private key handover to achieve efficiency and privacy gains. The benefits of applying private key handover to coinswaps are mentioned.The email exchange between Ruben Somsen and ZmnSCPxj discusses a proposed CoinSwap model and the risks associated with it. The discussion focuses on the possibility of both Alice and Bob claiming the BTC, leading to claimable LTC by both parties. Strategies to mitigate these risks, such as adding two CPFP outputs and using the minimum relayable feerate, are discussed. The safest alternative is suggested to be for Bob to spend before the timelock expires.Ruben Somsen, a Bitcoin developer, has gained recognition for his innovative protocol called "Forced Refund TLC." This protocol addresses the 2020-06-03T14:36:46+00:00 + In an email conversation, ZmnSCPxj informs Dmitry about creating a version of the TLA+ spec in the 'variant_ZmnSCPxj' branch of the SASwap repo. However, there is a possible deadlock after step 9 if Bob fails to publish a success transaction on time. To address this issue, Bob will have a short timeout period after which he will force publication of the success transaction if Alice does not respond. Running multiple servers can mitigate accidents due to computer crashes. A dead man switch system can countermand the main server in such situations. The probability of accidents occurring can be reduced to negligible levels.In another discussion between Ruben and ZmnSCPxj, they discuss the possibility of chaos if Bob neglects to broadcast the success tx before refund tx #1 becomes valid. They propose using sighash_single + anyonecanpay to ensure the TXO is spent before refund tx #1 becomes valid. They also suggest that in a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. Bob should spend his UTXO first to reduce resource wastage. They also discuss how Bob can specify address/value pairs in the success tx, allowing for additional flexibility later.The conversation revolves around a hypothetical situation where Alice and Bob are participating in a protocol. There are concerns about potential chaos if Bob misses the deadline for broadcasting the success tx. It is suggested that Bob should broadcast the success tx before refund tx #1 becomes valid. In a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. It is also important for Bob to spend his UTXO first to minimize resource waste. Additionally, there is a discussion about the use of private key handover and the risks associated with it.In a discussion between Ruben and ZmnSCPxj, they discuss potential issues with a proposed Lightning Network protocol. One concern is the possibility of chaos if Bob lets refund tx #1 become valid after completing the protocol. Another concern is the risk of both Alice and Bob knowing all the secrets on the LTC side and competing over it. The use of multiple CPFP outpoints is suggested to prevent pinning. They also discuss the need for backup watchers in case of irrational behavior.The conversation discusses a proposed protocol where Alice and Bob share secrets on the Litecoin (LTC) side and compete for it. Potential issues with the proposal are highlighted, including the risk of competing revoke transactions and the use of refund transactions that could lead to chaos if broadcasted. The need for a backup watcher is emphasized. The proposal is compared to Lightning Network's HTLCs and the benefits of spending the revoke transaction before or after its absolute timelock period are discussed.The email conversation discusses the use of private key handover for old-style coinswaps to mitigate potential issues with the traditional four-transaction swap. A proposal involving a shortened refund transaction is mentioned, but ZmnSCPxj notes an issue where Bob can give a copy of the revoke tx directly to a miner, forcing Alice to take three transactions to back out of the swap. Mitigation strategies, such as using CPFP outputs and minimum relayable feerate, are discussed. The safest alternative is for Bob to spend before the timelock expires.The conversation between Ruben and ZmnSCPxj discusses the technicalities of conducting a secure and efficient coinswap. Ruben proposes a pre-swap setup to reduce privacy concerns, while ZmnSCPxj suggests using relative timelocks and private key handover. The conversation delves into the specifics of the protocol, potential risks, and mitigation strategies. The importance of running multiple servers to ensure timely execution of transactions is emphasized.The email exchange between Ruben and ZmnSCPxj discusses a proposed CoinSwap protocol and its potential vulnerabilities. The concern is that if Bob misses the deadline, Alice will reclaim the funds. Different proposals are discussed, including using CPFP outputs and minimum relayable feerate. The safety of spending before the timelock expires is highlighted.The email exchange discusses a proposed coinswap scheme with improved scalability and privacy. The conversation highlights the use of relative timelocks and private key handover to achieve efficiency and privacy gains. The benefits of applying private key handover to coinswaps are mentioned.The email exchange between Ruben Somsen and ZmnSCPxj discusses a proposed CoinSwap model and the risks associated with it. The discussion focuses on the possibility of both Alice and Bob claiming the BTC, leading to claimable LTC by both parties. Strategies to mitigate these risks, such as adding two CPFP outputs and using the minimum relayable feerate, are discussed. The safest alternative is suggested to be for Bob to spend before the timelock expires.Ruben Somsen, a Bitcoin developer, has gained recognition for his innovative protocol called "Forced Refund TLC." This protocol addresses the - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_Statechain-implementations.xml b/static/bitcoin-dev/May_2020/combined_Statechain-implementations.xml index 9be88f3915..64105ebbde 100644 --- a/static/bitcoin-dev/May_2020/combined_Statechain-implementations.xml +++ b/static/bitcoin-dev/May_2020/combined_Statechain-implementations.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - Statechain implementations - 2023-08-02T01:58:10.360456+00:00 - - Tom Trevethan 2020-05-07 14:54:53+00:00 - - - Tom Trevethan 2020-04-05 21:25:51+00:00 - - - ZmnSCPxj 2020-04-05 18:24:39+00:00 - - - Bob McElrath 2020-04-05 14:17:17+00:00 - - - ZmnSCPxj 2020-04-04 12:07:28+00:00 - - - Nadav Kohen 2020-04-03 16:37:15+00:00 - - - Tom Trevethan 2020-04-02 22:56:17+00:00 - - - Tom Trevethan 2020-03-31 11:41:46+00:00 - - - David A. Harding 2020-03-31 10:35:08+00:00 - - - ZmnSCPxj 2020-03-30 01:25:36+00:00 - - - Ruben Somsen 2020-03-28 17:42:58+00:00 - - - Ruben Somsen 2020-03-28 17:38:47+00:00 - - - ZmnSCPxj 2020-03-28 02:42:27+00:00 - - - ZmnSCPxj 2020-03-28 02:20:33+00:00 - - - Bob McElrath 2020-03-27 17:10:18+00:00 - - - Ruben Somsen 2020-03-27 15:12:33+00:00 - - - ZmnSCPxj 2020-03-27 01:46:15+00:00 - - - Ruben Somsen 2020-03-26 18:53:13+00:00 - - - Greg Sanders 2020-03-26 17:17:13+00:00 - - - Christian Decker 2020-03-26 17:12:44+00:00 - - - Bob McElrath 2020-03-26 14:52:36+00:00 - - - Ruben Somsen 2020-03-26 12:36:20+00:00 - - - Albert 2020-03-26 03:55:50+00:00 - - - ZmnSCPxj 2020-03-26 01:20:47+00:00 - - - Tom Trevethan 2020-03-25 13:52:10+00:00 - + 2025-09-26T15:35:42.993748+00:00 + python-feedgen + + + [bitcoin-dev] Statechain implementations Tom Trevethan + 2020-03-25T13:52:00.000Z + + + ZmnSCPxj + 2020-03-26T01:20:00.000Z + + + Albert + 2020-03-26T03:55:00.000Z + + + Ruben Somsen + 2020-03-26T12:36:00.000Z + + + Bob McElrath + 2020-03-26T14:52:00.000Z + + + Christian Decker + 2020-03-26T17:12:00.000Z + + + Greg Sanders + 2020-03-26T17:17:00.000Z + + + Ruben Somsen + 2020-03-26T18:53:00.000Z + + + ZmnSCPxj + 2020-03-27T01:46:00.000Z + + + Ruben Somsen + 2020-03-27T15:12:00.000Z + + + Bob McElrath + 2020-03-27T17:10:00.000Z + + + ZmnSCPxj + 2020-03-28T02:20:00.000Z + + + ZmnSCPxj + 2020-03-28T02:42:00.000Z + + + Ruben Somsen + 2020-03-28T17:38:00.000Z + + + Ruben Somsen + 2020-03-28T17:42:00.000Z + + + ZmnSCPxj + 2020-03-30T01:25:00.000Z + + + David A. Harding + 2020-03-31T10:35:00.000Z + + + Tom Trevethan + 2020-03-31T11:41:00.000Z + + + Tom Trevethan + 2020-04-02T22:56:00.000Z + + + Nadav Kohen + 2020-04-03T16:37:00.000Z + + + ZmnSCPxj + 2020-04-04T12:07:00.000Z + + + Bob McElrath + 2020-04-05T14:17:00.000Z + + + ZmnSCPxj + 2020-04-05T18:24:00.000Z + + + Tom Trevethan + 2020-04-05T21:25:00.000Z + + + Tom Trevethan + 2020-05-07T14:54:00.000Z + + @@ -103,13 +131,13 @@ - python-feedgen + 2 Combined summary - Statechain implementations - 2023-08-02T01:58:10.360456+00:00 + 2025-09-26T15:35:42.996312+00:00 - CommerceBlock is actively working on implementing their statechain using KZen's 2P ECDSA protocol and Rust. They plan to use a sparse Merkle tree attested to a Mainstay slot for the proof-of-publication/proof-of-ownership. The statechain will allow the current owner to prove if there has been theft from them.Nadav has concerns about potential scams by the Statechain Entity (SE) where they buy the UTXO, transfer it, and then steal it. This issue can be solved by adding a new user key to the protocol that would make it traceable/provable. For open-ended UTXOs, an invalidation tree relative locktime backup mechanism will likely be used. Tom Trevethan clarifies that his patent application is different from the ideas currently being worked on. On the bitcoin-dev mailing list, a proposal was made for an exchange platform that operates using off-chain transactions and does not require on-chain transactions. This platform would be capable of generating multiple transactions, which can be recorded on a blockchain under different circumstances. The proposal suggests that some off-chain transactions should still be valid for recording on the blockchain in the event of a catastrophic failure of the exchange, such as the permanent shutdown of the exchange or loss of key shares.A two-party elliptic curve digital signature algorithm script would be used to perform functions of a two-party elliptic curve digital signature algorithm. The proposal also notes that a malicious actor would have to collude with a previous owner of the funds to recreate the full key making it difficult for them to compromise the exchange platform. Dave proposed this idea, and Bob McElrath responded to it by quoting H.L. Mencken's famous statement that "For every complex problem, there is a solution that is simple, neat, and wrong."In an email chain on the Bitcoin development mailing list, several proposals were discussed to increase platform security. One proposal involved using two-party elliptic curve digital signature algorithms to make it difficult for malicious actors to compromise the exchange platform. The processor would be configured to perform these functions, which would limit opportunities for attackers to compromise the platform. Bob McElrath noted that this proposed solution may not be effective in preventing all attacks and ended his email with a quote by H.L. Mencken: "For every complex problem, there is a solution that is simple, neat, and wrong."Another proposal discussed was the statechain protocol. Nadav Kohen raised concerns over the possibility of a malicious Statechain Entity (SE) stealing a user's UTXO by collaborating with or being a previous owner. Tom suggested using proof-of-publication as a way to enable the current owner to prove ownership and prevent double-spending, as well as provide evidence of fraud on the part of the SE. Bob McElrath suggested using single use seals to track ownership history and prevent the SE from buying the UTXO, noting that the attack would require collusion with the current UTXO owner. Nadav proposed adding a new user key to the protocol, which would be required for a transfer to be valid on the statechain.Tom provided a more detailed document specifying the proposed protocol, including improvements to the transfer mechanism and an explanation of how this can be used to transfer/novate positions in DLCs. He also addressed concerns about nChain Holdings' patent application related to secure off-chain blockchain transactions.The discussion is about the security assumptions of statechains. It is mentioned that an attack on statechains requires collaboration with the current UTXO owner, who is transferring the UXTO to a non-statechain entity and knows the target of the transfer, obtaining the target pubkey for the transfer out-of-band with respect to the SE or the SE can MITM that. The security assumption is that the sender or receiver does not collude with the SE. If either does, then the attack is generally possible.The SE cannot be allowed to be both operator of the SE and a customer of it as this clearly violates the no-receiver collusion principle. Adding a new user key doesn't change the situation as the user has already acquiesced to the transfer. Any past owner of the coin can collude with the statechain authority in order to steal the onchain funds regardless of who the current owner is within the statechain. So, trust must still be put in the statechain authority. The security assumptions should be that the statechain authority really does delete keys and does not make backups, and no past or current owner of the coin colludes with the statechain authority.The Statechain concept proposes non-custodial off-chain Bitcoin transfer. The current holder of UTXO must obtain the target pubkey for the transfer out-of-band with respect to the SE, or the SE can MITM that. Nadav Kohen raised concerns about an untraceable scam by the Statechain Entity (SE). It involves buying the UTXO, transferring it to someone else, 2020-05-07T14:54:53+00:00 + CommerceBlock is actively working on implementing their statechain using KZen's 2P ECDSA protocol and Rust. They plan to use a sparse Merkle tree attested to a Mainstay slot for the proof-of-publication/proof-of-ownership. The statechain will allow the current owner to prove if there has been theft from them.Nadav has concerns about potential scams by the Statechain Entity (SE) where they buy the UTXO, transfer it, and then steal it. This issue can be solved by adding a new user key to the protocol that would make it traceable/provable. For open-ended UTXOs, an invalidation tree relative locktime backup mechanism will likely be used. Tom Trevethan clarifies that his patent application is different from the ideas currently being worked on. On the bitcoin-dev mailing list, a proposal was made for an exchange platform that operates using off-chain transactions and does not require on-chain transactions. This platform would be capable of generating multiple transactions, which can be recorded on a blockchain under different circumstances. The proposal suggests that some off-chain transactions should still be valid for recording on the blockchain in the event of a catastrophic failure of the exchange, such as the permanent shutdown of the exchange or loss of key shares.A two-party elliptic curve digital signature algorithm script would be used to perform functions of a two-party elliptic curve digital signature algorithm. The proposal also notes that a malicious actor would have to collude with a previous owner of the funds to recreate the full key making it difficult for them to compromise the exchange platform. Dave proposed this idea, and Bob McElrath responded to it by quoting H.L. Mencken's famous statement that "For every complex problem, there is a solution that is simple, neat, and wrong."In an email chain on the Bitcoin development mailing list, several proposals were discussed to increase platform security. One proposal involved using two-party elliptic curve digital signature algorithms to make it difficult for malicious actors to compromise the exchange platform. The processor would be configured to perform these functions, which would limit opportunities for attackers to compromise the platform. Bob McElrath noted that this proposed solution may not be effective in preventing all attacks and ended his email with a quote by H.L. Mencken: "For every complex problem, there is a solution that is simple, neat, and wrong."Another proposal discussed was the statechain protocol. Nadav Kohen raised concerns over the possibility of a malicious Statechain Entity (SE) stealing a user's UTXO by collaborating with or being a previous owner. Tom suggested using proof-of-publication as a way to enable the current owner to prove ownership and prevent double-spending, as well as provide evidence of fraud on the part of the SE. Bob McElrath suggested using single use seals to track ownership history and prevent the SE from buying the UTXO, noting that the attack would require collusion with the current UTXO owner. Nadav proposed adding a new user key to the protocol, which would be required for a transfer to be valid on the statechain.Tom provided a more detailed document specifying the proposed protocol, including improvements to the transfer mechanism and an explanation of how this can be used to transfer/novate positions in DLCs. He also addressed concerns about nChain Holdings' patent application related to secure off-chain blockchain transactions.The discussion is about the security assumptions of statechains. It is mentioned that an attack on statechains requires collaboration with the current UTXO owner, who is transferring the UXTO to a non-statechain entity and knows the target of the transfer, obtaining the target pubkey for the transfer out-of-band with respect to the SE or the SE can MITM that. The security assumption is that the sender or receiver does not collude with the SE. If either does, then the attack is generally possible.The SE cannot be allowed to be both operator of the SE and a customer of it as this clearly violates the no-receiver collusion principle. Adding a new user key doesn't change the situation as the user has already acquiesced to the transfer. Any past owner of the coin can collude with the statechain authority in order to steal the onchain funds regardless of who the current owner is within the statechain. So, trust must still be put in the statechain authority. The security assumptions should be that the statechain authority really does delete keys and does not make backups, and no past or current owner of the coin colludes with the statechain authority.The Statechain concept proposes non-custodial off-chain Bitcoin transfer. The current holder of UTXO must obtain the target pubkey for the transfer out-of-band with respect to the SE, or the SE can MITM that. Nadav Kohen raised concerns about an untraceable scam by the Statechain Entity (SE). It involves buying the UTXO, transferring it to someone else, - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_TLA-specification-for-Succint-Atomic-Swap.xml b/static/bitcoin-dev/May_2020/combined_TLA-specification-for-Succint-Atomic-Swap.xml index 331585c991..f33e77d023 100644 --- a/static/bitcoin-dev/May_2020/combined_TLA-specification-for-Succint-Atomic-Swap.xml +++ b/static/bitcoin-dev/May_2020/combined_TLA-specification-for-Succint-Atomic-Swap.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - TLA+ specification for Succint Atomic Swap - 2023-08-02T02:14:52.610003+00:00 - - Dmitry Petukhov 2020-06-01 11:38:54+00:00 - - - Ruben Somsen 2020-05-14 11:41:32+00:00 - - - Dmitry Petukhov 2020-05-14 07:08:05+00:00 - - - Ruben Somsen 2020-05-14 05:31:13+00:00 - - - Dmitry Petukhov 2020-05-14 04:52:15+00:00 - - - Ruben Somsen 2020-05-13 19:03:17+00:00 - - - Dmitry Petukhov 2020-05-13 17:02:22+00:00 - + 2025-09-26T15:36:06.183073+00:00 + python-feedgen + + + [bitcoin-dev] TLA+ specification for Succint Atomic Swap Dmitry Petukhov + 2020-05-13T17:02:00.000Z + + + Ruben Somsen + 2020-05-13T19:03:00.000Z + + + Dmitry Petukhov + 2020-05-14T04:52:00.000Z + + + Ruben Somsen + 2020-05-14T05:31:00.000Z + + + Dmitry Petukhov + 2020-05-14T07:08:00.000Z + + + Ruben Somsen + 2020-05-14T11:41:00.000Z + + + Dmitry Petukhov + 2020-06-01T11:38:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - TLA+ specification for Succint Atomic Swap - 2023-08-02T02:14:52.610003+00:00 + 2025-09-26T15:36:06.184050+00:00 - The author has completed the specification of the Succint Atomic Swap contract in TLA+. The specification covers all relevant behaviors of the participants and even has an option to enable 'non-rational' behavior. The model is capable of exhaustively checking safety properties and temporal properties. Additionally, the model can show hyperproperties, but automatic checking of hyperproperties is not yet available. The model has some limitations, like only having one miner and not modeling fees and mempool priorities. Despite these limitations, the author believes that TLA+ is a suitable tool for specifying and checking smart contract specifications.In an email exchange, Ruben Somsen points out to Dmitry Petukhov that it is important for Bob to confirm success_tx before refund_tx_1 becomes valid. Dmitry agrees and notes that this is unlikely to be a practical problem unless the original fee of success_tx is too small. Ruben also clarifies that Alice won't give her key until she learns secretBob because step 5 comes before step 6 in the diagram. Dmitry admits that he missed this and that he now made the `signers_map` into variable that can be changed to give Bob the ability to sign for Alice. However, he warns that this will add a bunch of new transactions to the model, each Alice&Bob spend having 'Bob unilateral override' case.A conversation between Ruben Somsen and Dmitry about the Lightning Network protocol was shared. They discuss the scenario when Bob gives success_tx to a friendly miner while refund_tx_1 is in the mempool. Ruben explains that this situation would not be an issue because both Alice and Bob had to misbehave for it to happen. Bob should have published the success_tx before refund_tx_1 became valid, and Alice should have sent the revoke_tx followed by refund_tx_2, revealing her secret only after Bob could no longer claim the BTC. Dmitry notes that it's crucial that success_tx is confirmed before refund_tx_1 becomes valid, but this is unlikely to be a practical problem since only Bob can spend success_tx unless the original fee of success_tx is too small. Ruben also corrects Dmitry's assumption that Bob will receive BTC, and the LTC can be locked forever. Ruben explains that Alice would not give her key until she learned secretBob, which occurs in step 6 of the diagram. Ruben then makes a change in the model, making the `signers_map` into a variable that can be changed to give Bob the ability to sign for Alice. This change enables step 6 to be modeled, but it adds several new transactions to the model.The conversation between Ruben and Dmitry revolves around the Lightning Network protocol and its potential issues. They discuss the issue of refund transaction #1 and the success transaction becoming valid at the same time. Ruben explains that this is not an issue because Alice and Bob would both have to misbehave for it to happen. They also discuss the possibility of Bob giving the success_tx to a friendly miner while refund_tx_1 is in the mempool, which could result in Bob receiving both LTC and BTC while Alice loses her BTC. Ruben clarifies that this won't happen if either of them doesn't want it to. Finally, they discuss the cooperative spend of refund_tx #1 by Alice and Bob, which is there to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol.In an email conversation, Ruben Somsen discusses an issue with the Lightning Network where Bob can potentially invalidate a transaction and take both LTC and BTC from Alice. The issue arises due to the fact that Bob cannot wait for Alice to broadcast refund_tx_1 before broadcasting success_tx, which would allow him to invalidate refund_tx_1 and take the BTC. However, Somsen believes this is not ultimately an issue. In response to a question about the destination of Alice and Bob's cooperative spend of refund_tx#1, Somsen explains that they can spend it right away or Alice can spend it a day later, after the tx has confirmed. The Alice & Bob condition is only there to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol. Somsen clarifies that the reason Alice gives Bob her key ("Alice") in step 5 of the diagram is to deny Alice from using refund_tx_1. Finally, there is a discussion about whether Bob could just spend the Alice&Bob output of the very first "commitment" transaction that locks BTC if Alice gives him her key before he shares secretBob via success_tx.Dmitry Petukhov has created a formal specification for the Succint Atomic Swap (SAS) contract presented by Ruben Somsen, using the TLA+ specification language. The model encoded in the specification can successfully detect the violation of the 'no mutual secret knowledge' invariant when one participant bypasses mem 2020-06-01T11:38:54+00:00 + The author has completed the specification of the Succint Atomic Swap contract in TLA+. The specification covers all relevant behaviors of the participants and even has an option to enable 'non-rational' behavior. The model is capable of exhaustively checking safety properties and temporal properties. Additionally, the model can show hyperproperties, but automatic checking of hyperproperties is not yet available. The model has some limitations, like only having one miner and not modeling fees and mempool priorities. Despite these limitations, the author believes that TLA+ is a suitable tool for specifying and checking smart contract specifications.In an email exchange, Ruben Somsen points out to Dmitry Petukhov that it is important for Bob to confirm success_tx before refund_tx_1 becomes valid. Dmitry agrees and notes that this is unlikely to be a practical problem unless the original fee of success_tx is too small. Ruben also clarifies that Alice won't give her key until she learns secretBob because step 5 comes before step 6 in the diagram. Dmitry admits that he missed this and that he now made the `signers_map` into variable that can be changed to give Bob the ability to sign for Alice. However, he warns that this will add a bunch of new transactions to the model, each Alice&Bob spend having 'Bob unilateral override' case.A conversation between Ruben Somsen and Dmitry about the Lightning Network protocol was shared. They discuss the scenario when Bob gives success_tx to a friendly miner while refund_tx_1 is in the mempool. Ruben explains that this situation would not be an issue because both Alice and Bob had to misbehave for it to happen. Bob should have published the success_tx before refund_tx_1 became valid, and Alice should have sent the revoke_tx followed by refund_tx_2, revealing her secret only after Bob could no longer claim the BTC. Dmitry notes that it's crucial that success_tx is confirmed before refund_tx_1 becomes valid, but this is unlikely to be a practical problem since only Bob can spend success_tx unless the original fee of success_tx is too small. Ruben also corrects Dmitry's assumption that Bob will receive BTC, and the LTC can be locked forever. Ruben explains that Alice would not give her key until she learned secretBob, which occurs in step 6 of the diagram. Ruben then makes a change in the model, making the `signers_map` into a variable that can be changed to give Bob the ability to sign for Alice. This change enables step 6 to be modeled, but it adds several new transactions to the model.The conversation between Ruben and Dmitry revolves around the Lightning Network protocol and its potential issues. They discuss the issue of refund transaction #1 and the success transaction becoming valid at the same time. Ruben explains that this is not an issue because Alice and Bob would both have to misbehave for it to happen. They also discuss the possibility of Bob giving the success_tx to a friendly miner while refund_tx_1 is in the mempool, which could result in Bob receiving both LTC and BTC while Alice loses her BTC. Ruben clarifies that this won't happen if either of them doesn't want it to. Finally, they discuss the cooperative spend of refund_tx #1 by Alice and Bob, which is there to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol.In an email conversation, Ruben Somsen discusses an issue with the Lightning Network where Bob can potentially invalidate a transaction and take both LTC and BTC from Alice. The issue arises due to the fact that Bob cannot wait for Alice to broadcast refund_tx_1 before broadcasting success_tx, which would allow him to invalidate refund_tx_1 and take the BTC. However, Somsen believes this is not ultimately an issue. In response to a question about the destination of Alice and Bob's cooperative spend of refund_tx#1, Somsen explains that they can spend it right away or Alice can spend it a day later, after the tx has confirmed. The Alice & Bob condition is only there to ensure that Bob can spend the money before Alice once he receives her key at the end of the protocol. Somsen clarifies that the reason Alice gives Bob her key ("Alice") in step 5 of the diagram is to deny Alice from using refund_tx_1. Finally, there is a discussion about whether Bob could just spend the Alice&Bob output of the very first "commitment" transaction that locks BTC if Alice gives him her key before he shares secretBob via success_tx.Dmitry Petukhov has created a formal specification for the Succint Atomic Swap (SAS) contract presented by Ruben Somsen, using the TLA+ specification language. The model encoded in the specification can successfully detect the violation of the 'no mutual secret knowledge' invariant when one participant bypasses mem - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2020/combined_hashcash-newhash.xml b/static/bitcoin-dev/May_2020/combined_hashcash-newhash.xml index 5823735cff..9759331266 100644 --- a/static/bitcoin-dev/May_2020/combined_hashcash-newhash.xml +++ b/static/bitcoin-dev/May_2020/combined_hashcash-newhash.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - hashcash-newhash - 2023-08-02T02:16:09.059000+00:00 - - Erik Aronesty 2020-05-27 14:12:26+00:00 - - - ZmnSCPxj 2020-05-27 04:47:43+00:00 - - - Karl 2020-05-25 11:54:58+00:00 - - - ZmnSCPxj 2020-05-25 07:58:19+00:00 - - - Karl 2020-05-25 07:03:20+00:00 - - - Ariel Lorenzo-Luaces 2020-05-24 23:51:10+00:00 - - - Karl 2020-05-24 19:50:12+00:00 - - - ZmnSCPxj 2020-05-24 16:51:36+00:00 - - - Karl 2020-05-24 09:02:59+00:00 - - - ZmnSCPxj 2020-05-24 01:12:04+00:00 - - - Karl 2020-05-23 11:00:54+00:00 - + 2025-09-26T15:36:08.300330+00:00 + python-feedgen + + + [bitcoin-dev] hashcash-newhash Karl + 2020-05-23T11:00:00.000Z + + + ZmnSCPxj + 2020-05-24T01:12:00.000Z + + + Karl + 2020-05-24T09:02:00.000Z + + + ZmnSCPxj + 2020-05-24T16:51:00.000Z + + + Karl + 2020-05-24T19:50:00.000Z + + + Ariel Lorenzo-Luaces + 2020-05-24T23:51:00.000Z + + + Karl + 2020-05-25T07:03:00.000Z + + + ZmnSCPxj + 2020-05-25T07:58:00.000Z + + + Karl + 2020-05-25T11:54:00.000Z + + + ZmnSCPxj + 2020-05-27T04:47:00.000Z + + + Erik Aronesty + 2020-05-27T14:12:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - hashcash-newhash - 2023-08-02T02:16:09.059000+00:00 + 2025-09-26T15:36:08.301720+00:00 - One of the key issues in the world of blockchain and cryptocurrency is the block reward system. Currently, the block reward is determined by the previous hash, but there is a suggestion to change this approach. The author proposes adjusting the block reward from the previous hash to the next, with different rewards being accepted. This could be achieved by calculating an appropriate rate based on the difficulty.The main idea behind this proposal is to ensure that present-day ASICs (Application-Specific Integrated Circuits) become obsolete due to competition. By introducing new hashes at a frequency that prevents the development of new ASICs, it would level the playing field and prevent any one entity from gaining an unfair advantage.Karl Semich, the author of this proposition, is actively seeking feedback and opinions on this matter. He is interested in hearing thoughts and concerns from the blockchain and cryptocurrency community. It is essential to gather various viewpoints to further explore the feasibility and potential implications of this suggested change.Overall, this proposal aims to address the issue of ASIC dominance in the blockchain space by adjusting the block reward system. By incorporating different rewards and preventing the development of new ASICs, it strives to create a fairer and more competitive environment. Karl Semich welcomes input from the community to foster discussion and refine this concept.In another email conversation, a different topic is discussed regarding the possibility of an algorithm change in case of a public mathematical breaking of the current SHA-256 algorithm used in Bitcoin mining. Ariel responds to this by explaining that cryptographic algorithms don't usually break completely, but may have their security reduced through exploits. If an exploit can be deployed as a software patch to most ASICs, the issue can be resolved during the next difficulty adjustment. If not, GPUs and FPGAs can still compete with less adaptive ASICs until new ASICs using the exploit are produced. Ariel also notes that there is no official "public breaking" of a hash function, but rather a gradual loss of security over time. The conversation emphasizes the need to plan for algorithm changes and improve the security of the blockchain in the face of ongoing cryptanalysis research and advancements in computer hardware.The conversation initiated by Karl via bitcoin-dev focuses on the need to plan for future algorithm changes in Bitcoin mining. The discussion revolves around the potential obsoletion of ASICs due to a public mathematical breaking of the SHA-256 algorithm. Karl suggests migrating to new hashing algorithms to increase decentralization and security. However, ZmnSCPxj argues that changing the hash algorithm is not a practical solution. Developing new hash algorithms is costly and requires coordinated hardforks at a high rate, which may put too much power in the hands of developers. ZmnSCPxj believes that non-ASIC resistance is not a significant issue, as miner earnings are determined by the cost of power supply. Instead, the focus should be on improving energy efficiency and increasing access to cheap energy to address the issue of miner centralization. The conversation highlights the importance of considering the impact on existing miners and finding a balance between decentralization and security.Lastly, Karl Semich initiates a discussion with Ariel about the need to plan for an algorithm change in case of a public mathematical breaking of the current SHA-256 algorithm used in Bitcoin mining. Ariel explains that cryptographic algorithms don't typically break completely, but their security may be reduced through exploits. He suggests that if an exploit can be deployed as a software patch to most ASICs, the issue can be resolved during the next difficulty adjustment. If not, GPUs and FPGAs can still compete with less adaptive ASICs until new ASICs utilizing the exploit are produced. The conversation emphasizes the importance of planning for algorithm changes to ensure the security of the blockchain, taking into account ongoing cryptanalysis research and advancements in computer hardware. 2020-05-27T14:12:26+00:00 + One of the key issues in the world of blockchain and cryptocurrency is the block reward system. Currently, the block reward is determined by the previous hash, but there is a suggestion to change this approach. The author proposes adjusting the block reward from the previous hash to the next, with different rewards being accepted. This could be achieved by calculating an appropriate rate based on the difficulty.The main idea behind this proposal is to ensure that present-day ASICs (Application-Specific Integrated Circuits) become obsolete due to competition. By introducing new hashes at a frequency that prevents the development of new ASICs, it would level the playing field and prevent any one entity from gaining an unfair advantage.Karl Semich, the author of this proposition, is actively seeking feedback and opinions on this matter. He is interested in hearing thoughts and concerns from the blockchain and cryptocurrency community. It is essential to gather various viewpoints to further explore the feasibility and potential implications of this suggested change.Overall, this proposal aims to address the issue of ASIC dominance in the blockchain space by adjusting the block reward system. By incorporating different rewards and preventing the development of new ASICs, it strives to create a fairer and more competitive environment. Karl Semich welcomes input from the community to foster discussion and refine this concept.In another email conversation, a different topic is discussed regarding the possibility of an algorithm change in case of a public mathematical breaking of the current SHA-256 algorithm used in Bitcoin mining. Ariel responds to this by explaining that cryptographic algorithms don't usually break completely, but may have their security reduced through exploits. If an exploit can be deployed as a software patch to most ASICs, the issue can be resolved during the next difficulty adjustment. If not, GPUs and FPGAs can still compete with less adaptive ASICs until new ASICs using the exploit are produced. Ariel also notes that there is no official "public breaking" of a hash function, but rather a gradual loss of security over time. The conversation emphasizes the need to plan for algorithm changes and improve the security of the blockchain in the face of ongoing cryptanalysis research and advancements in computer hardware.The conversation initiated by Karl via bitcoin-dev focuses on the need to plan for future algorithm changes in Bitcoin mining. The discussion revolves around the potential obsoletion of ASICs due to a public mathematical breaking of the SHA-256 algorithm. Karl suggests migrating to new hashing algorithms to increase decentralization and security. However, ZmnSCPxj argues that changing the hash algorithm is not a practical solution. Developing new hash algorithms is costly and requires coordinated hardforks at a high rate, which may put too much power in the hands of developers. ZmnSCPxj believes that non-ASIC resistance is not a significant issue, as miner earnings are determined by the cost of power supply. Instead, the focus should be on improving energy efficiency and increasing access to cheap energy to address the issue of miner centralization. The conversation highlights the importance of considering the impact on existing miners and finding a balance between decentralization and security.Lastly, Karl Semich initiates a discussion with Ariel about the need to plan for an algorithm change in case of a public mathematical breaking of the current SHA-256 algorithm used in Bitcoin mining. Ariel explains that cryptographic algorithms don't typically break completely, but their security may be reduced through exploits. He suggests that if an exploit can be deployed as a software patch to most ASICs, the issue can be resolved during the next difficulty adjustment. If not, GPUs and FPGAs can still compete with less adaptive ASICs until new ASICs utilizing the exploit are produced. The conversation emphasizes the importance of planning for algorithm changes to ensure the security of the blockchain, taking into account ongoing cryptanalysis research and advancements in computer hardware. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml b/static/bitcoin-dev/May_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml index 48d21caab8..23da8cfa33 100644 --- a/static/bitcoin-dev/May_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml +++ b/static/bitcoin-dev/May_2021/combined_A-Stroll-through-Fee-Bumping-Techniques-Input-Based-vs-Child-Pay-For-Parent.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent - 2023-08-02T03:56:08.130121+00:00 - - Antoine Riard 2021-07-12 00:02:12+00:00 - - - Anthony Towns 2021-07-10 01:47:32+00:00 - - - Antoine Riard 2021-07-09 13:19:45+00:00 - - - Anthony Towns 2021-07-08 11:17:16+00:00 - - - Lloyd Fournier 2021-06-15 03:08:37+00:00 - - - Lloyd Fournier 2021-06-15 00:59:12+00:00 - - - Antoine Riard 2021-06-14 17:18:38+00:00 - - - Antoine Riard 2021-06-14 16:46:56+00:00 - - - Jeremy 2021-06-13 14:16:24+00:00 - - - Lloyd Fournier 2021-06-13 05:56:43+00:00 - - - darosior 2021-06-10 22:47:04+00:00 - - - Antoine Riard 2021-06-10 21:45:04+00:00 - - - Antoine Riard 2021-06-10 21:16:43+00:00 - - - darosior 2021-06-10 13:18:53+00:00 - - - Lloyd Fournier 2021-06-07 02:27:36+00:00 - - - darosior 2021-05-28 22:25:16+00:00 - - - Antoine Riard 2021-05-28 04:13:44+00:00 - - - darosior 2021-05-27 21:45:35+00:00 - - - Antoine Riard 2021-05-27 20:14:13+00:00 - + 2025-09-26T15:54:14.237164+00:00 + python-feedgen + + + [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent Antoine Riard + 2021-05-27T20:14:00.000Z + + + darosior + 2021-05-27T21:45:00.000Z + + + Antoine Riard + 2021-05-28T04:13:00.000Z + + + darosior + 2021-05-28T22:25:00.000Z + + + Lloyd Fournier + 2021-06-07T02:27:00.000Z + + + darosior + 2021-06-10T13:18:00.000Z + + + Antoine Riard + 2021-06-10T21:16:00.000Z + + + Antoine Riard + 2021-06-10T21:45:00.000Z + + + darosior + 2021-06-10T22:47:00.000Z + + + Lloyd Fournier + 2021-06-13T05:56:00.000Z + + + Jeremy + 2021-06-13T14:16:00.000Z + + + Antoine Riard + 2021-06-14T16:46:00.000Z + + + Antoine Riard + 2021-06-14T17:18:00.000Z + + + Lloyd Fournier + 2021-06-15T00:59:00.000Z + + + Lloyd Fournier + 2021-06-15T03:08:00.000Z + + + Anthony Towns + 2021-07-08T11:17:00.000Z + + + Antoine Riard + 2021-07-09T13:19:00.000Z + + + Anthony Towns + 2021-07-10T01:47:00.000Z + + + Antoine Riard + 2021-07-12T00:02:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent - 2023-08-02T03:56:08.130121+00:00 + 2025-09-26T15:54:14.239191+00:00 - In a recent Bitcoin-dev mailing list discussion, there was a proposal to introduce a new SIGHASH_GROUP flag to improve transaction processing efficiency and avoid O(n^2) behavior. The proposal suggests grouping transactions together using the annex field "sig_group_count" and hashing only the relevant outputs when evaluating an input. This optimization aims to reduce overhead and improve transaction signing. The proposal provides an example of combining transactions in the Lightning network to illustrate how the SIGHASH_GROUP flag would work. However, it notes that there may be limitations when certain outputs collide on the absolute output position.Another topic discussed in the email thread is the possibility of introducing more advanced sighash malleability flags, such as SIGHASH_IOMAP, which would allow transaction signers to commit to a map of inputs and outputs. However, concerns were raised about theft possibilities, heaviness of range specification, and quadratic behavior.The discussion also explores a single-party managed fee-bumping system that could solve fee-bumping requirements in the Lightning network without external utxos or additional interaction between parties. This system would allow for fee adjustment by reducing the balance of a transaction or draining an output with HTLC or PTLC. The proposal suggests that this idea could be applied to all Bitcoin transactions, enabling efficient fee adjustments in various scenarios. The benefits and drawbacks of a sponsor-like mechanism for fee-bumping are also discussed.The conversation touches on fee-bumping techniques for second-layer protocols and proposes solutions such as the SIGHASH_ANYPREVOUT softfork proposal or tx mutation schemes. These approaches aim to address security issues and optimize fee-bumping in contract protocols with distrusting counterparties.Overall, the discussions revolve around proposals and ideas to improve transaction processing efficiency, optimize fee-bumping mechanisms, and address security concerns in various Bitcoin-related contexts, including Lightning network transactions and second-layer protocols.Another aspect discussed is input-based fee-bumping as a primitive for Layer 2 solutions. The use of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags is one variant of input-based fee-bumping, but ACP | SINGLE is easily pinable, so ACP | ALL is used for Revault. This requires a pool of fee-bumping UTXOs to be consumed entirely. The author suggests broadcasting a single fan-out transaction creating the entire UTXO pool in advance to overcome this limitation. However, sometimes the cost of many small additional inputs must be incurred. The discussion also explores the possibility of attaching the bumping input at the tail of the chain rather than targeting the root and suggests using smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP or blinded CPFP.The post compares input-based fee-bumping and CPFP techniques for second-layer protocols in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching opportunity, and mempool flexibility. CPFP requires one anchor output per participant, while input-based fee-bumping only requires one input if the bumping utxo offers an adequate feerate point. If a preliminary fan-out transaction must be broadcasted first, one input and two outputs more must be accounted for. CPFP's efficiency in tx-relay bandwidth rebroadcast relies on the assumption of bounded rationality of the participants, while input-based fee-bumping (today) breaks the chain validity and requires updating and rebroadcasting the remaining transactions beyond the updated root. However, input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP doesn't break the chain validity and could preserve the rest of the chain. For fee-bumping batching, CPFP requires one input/one output per aggregated chain, even if the child transaction fields can be shared. Input-based fee-bumping (today) requires one bumping input per chain, but transaction fields can be shared if a preliminary fan-out transaction is used. Input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP can attach one bumping input and outgoing output to the aggregated root. Regarding fee-bumping mempool flexibility, CPFP has limitations and doesn't scale beyond two contract participants, while input-based fee-bumping's acceptance is not restrained by package limits.The post concludes by mentioning future soft forks that allow significant onchain footprint savings, especially in batching, and future package relay bandwidth efficiency that should consider the rebroadcast frequency of CPFPing multi-party protocols.Overall, the conversation delves into various fee-bumping techniques, their advantages, limitations, and potential future improvements. It provides insights into the complexities and trade-offs involved in securing transactions in multi-party protocols. 2021-07-12T00:02:12+00:00 + In a recent Bitcoin-dev mailing list discussion, there was a proposal to introduce a new SIGHASH_GROUP flag to improve transaction processing efficiency and avoid O(n^2) behavior. The proposal suggests grouping transactions together using the annex field "sig_group_count" and hashing only the relevant outputs when evaluating an input. This optimization aims to reduce overhead and improve transaction signing. The proposal provides an example of combining transactions in the Lightning network to illustrate how the SIGHASH_GROUP flag would work. However, it notes that there may be limitations when certain outputs collide on the absolute output position.Another topic discussed in the email thread is the possibility of introducing more advanced sighash malleability flags, such as SIGHASH_IOMAP, which would allow transaction signers to commit to a map of inputs and outputs. However, concerns were raised about theft possibilities, heaviness of range specification, and quadratic behavior.The discussion also explores a single-party managed fee-bumping system that could solve fee-bumping requirements in the Lightning network without external utxos or additional interaction between parties. This system would allow for fee adjustment by reducing the balance of a transaction or draining an output with HTLC or PTLC. The proposal suggests that this idea could be applied to all Bitcoin transactions, enabling efficient fee adjustments in various scenarios. The benefits and drawbacks of a sponsor-like mechanism for fee-bumping are also discussed.The conversation touches on fee-bumping techniques for second-layer protocols and proposes solutions such as the SIGHASH_ANYPREVOUT softfork proposal or tx mutation schemes. These approaches aim to address security issues and optimize fee-bumping in contract protocols with distrusting counterparties.Overall, the discussions revolve around proposals and ideas to improve transaction processing efficiency, optimize fee-bumping mechanisms, and address security concerns in various Bitcoin-related contexts, including Lightning network transactions and second-layer protocols.Another aspect discussed is input-based fee-bumping as a primitive for Layer 2 solutions. The use of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags is one variant of input-based fee-bumping, but ACP | SINGLE is easily pinable, so ACP | ALL is used for Revault. This requires a pool of fee-bumping UTXOs to be consumed entirely. The author suggests broadcasting a single fan-out transaction creating the entire UTXO pool in advance to overcome this limitation. However, sometimes the cost of many small additional inputs must be incurred. The discussion also explores the possibility of attaching the bumping input at the tail of the chain rather than targeting the root and suggests using smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP or blinded CPFP.The post compares input-based fee-bumping and CPFP techniques for second-layer protocols in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching opportunity, and mempool flexibility. CPFP requires one anchor output per participant, while input-based fee-bumping only requires one input if the bumping utxo offers an adequate feerate point. If a preliminary fan-out transaction must be broadcasted first, one input and two outputs more must be accounted for. CPFP's efficiency in tx-relay bandwidth rebroadcast relies on the assumption of bounded rationality of the participants, while input-based fee-bumping (today) breaks the chain validity and requires updating and rebroadcasting the remaining transactions beyond the updated root. However, input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP doesn't break the chain validity and could preserve the rest of the chain. For fee-bumping batching, CPFP requires one input/one output per aggregated chain, even if the child transaction fields can be shared. Input-based fee-bumping (today) requires one bumping input per chain, but transaction fields can be shared if a preliminary fan-out transaction is used. Input-based fee-bumping with SIGHASH_ANYPREVOUT+SIGHASH_IOMAP can attach one bumping input and outgoing output to the aggregated root. Regarding fee-bumping mempool flexibility, CPFP has limitations and doesn't scale beyond two contract participants, while input-based fee-bumping's acceptance is not restrained by package limits.The post concludes by mentioning future soft forks that allow significant onchain footprint savings, especially in batching, and future package relay bandwidth efficiency that should consider the rebroadcast frequency of CPFPing multi-party protocols.Overall, the conversation delves into various fee-bumping techniques, their advantages, limitations, and potential future improvements. It provides insights into the complexities and trade-offs involved in securing transactions in multi-party protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Additional-BIPs-related-to-other-proposals.xml b/static/bitcoin-dev/May_2021/combined_Additional-BIPs-related-to-other-proposals.xml index 07051d3e5d..2c4c5d3de2 100644 --- a/static/bitcoin-dev/May_2021/combined_Additional-BIPs-related-to-other-proposals.xml +++ b/static/bitcoin-dev/May_2021/combined_Additional-BIPs-related-to-other-proposals.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Additional BIPs related to other proposals - 2023-08-02T03:40:48.914889+00:00 - - Billy Tetrud 2021-05-22 06:01:19+00:00 - - - Luke Dashjr 2021-05-22 02:33:45+00:00 - - - Billy Tetrud 2021-05-21 07:56:51+00:00 - - - Christopher Gilliard 2021-04-24 02:05:53+00:00 - + 2025-09-26T15:54:12.122548+00:00 + python-feedgen + + + [bitcoin-dev] Additional BIPs related to other proposals Christopher Gilliard + 2021-04-24T02:05:00.000Z + + + Billy Tetrud + 2021-05-21T07:56:00.000Z + + + Luke Dashjr + 2021-05-22T02:33:00.000Z + + + Billy Tetrud + 2021-05-22T06:01:00.000Z + + - python-feedgen + 2 Combined summary - Additional BIPs related to other proposals - 2023-08-02T03:40:48.914889+00:00 + 2025-09-26T15:54:12.123207+00:00 - During a conversation on the bitcoin-dev mailing list, Luke Dashjr and Billy Tetrud discussed Bitcoin Improvement Proposals (BIPs). Tetrud expressed his opinion that the BIPs seemed unrelated to changing the base layer of Bitcoin, although they were well organized. Dashjr clarified that BIPs are not limited to the base layer and can be used for coordinating Bitcoin software at any layer.The email exchange on the mailing list also revealed that Christopher Gilliard has created three additional BIPs related to his recent proposals. These BIPs, which focus on notification, moderation, and web of trust (WoT), can be found on Github. While the documents are well put together, they are seen as building on top of the Bitcoin platform without directly changing its base layer. Feedback, questions, and comments regarding these proposals are encouraged.To access Chris's BIPs related to his recent proposals, the links provided on Github can be followed. The first link is associated with notification, the second one with moderation, and the third one with Web of Trust (WoT). Chris is seeking feedback, questions, or comments on these proposals. 2021-05-22T06:01:19+00:00 + During a conversation on the bitcoin-dev mailing list, Luke Dashjr and Billy Tetrud discussed Bitcoin Improvement Proposals (BIPs). Tetrud expressed his opinion that the BIPs seemed unrelated to changing the base layer of Bitcoin, although they were well organized. Dashjr clarified that BIPs are not limited to the base layer and can be used for coordinating Bitcoin software at any layer.The email exchange on the mailing list also revealed that Christopher Gilliard has created three additional BIPs related to his recent proposals. These BIPs, which focus on notification, moderation, and web of trust (WoT), can be found on Github. While the documents are well put together, they are seen as building on top of the Bitcoin platform without directly changing its base layer. Feedback, questions, and comments regarding these proposals are encouraged.To access Chris's BIPs related to his recent proposals, the links provided on Github can be followed. The first link is associated with notification, the second one with moderation, and the third one with Web of Trust (WoT). Chris is seeking feedback, questions, or comments on these proposals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_BIP-limiting-OP-RETURN-HF.xml b/static/bitcoin-dev/May_2021/combined_BIP-limiting-OP-RETURN-HF.xml index 2df1a3f882..d416a906fa 100644 --- a/static/bitcoin-dev/May_2021/combined_BIP-limiting-OP-RETURN-HF.xml +++ b/static/bitcoin-dev/May_2021/combined_BIP-limiting-OP-RETURN-HF.xml @@ -1,83 +1,111 @@ - + 2 Combined summary - BIP - limiting OP_RETURN / HF - 2023-08-02T03:36:18.290138+00:00 - - Ruben Somsen 2021-05-04 12:51:14+00:00 - - - ZmnSCPxj 2021-05-03 05:17:46+00:00 - - - Ruben Somsen 2021-04-20 19:07:00+00:00 - - - Christopher Gilliard 2021-04-20 17:12:35+00:00 - - - Zach Greenwood 2021-04-20 08:45:31+00:00 - - - yanmaani at cock.li 2021-04-20 01:23:12+00:00 - - - yanmaani at cock.li 2021-04-20 01:22:51+00:00 - - - Christopher Gilliard 2021-04-17 16:57:34+00:00 - - - Peter Todd 2021-04-17 15:50:08+00:00 - - - Kostas Karasavvas 2021-04-17 07:41:39+00:00 - - - Christopher Gilliard 2021-04-17 03:57:55+00:00 - - - ZmnSCPxj 2021-04-16 23:52:48+00:00 - - - Christopher Gilliard 2021-04-16 21:09:25+00:00 - - - Ruben Somsen 2021-04-16 20:30:06+00:00 - - - Christopher Gilliard 2021-04-16 20:12:07+00:00 - - - Kostas Karasavvas 2021-04-16 19:15:28+00:00 - - - Jeremy 2021-04-16 18:00:29+00:00 - - - Christopher Gilliard 2021-04-16 17:05:12+00:00 - - - Jeremy 2021-04-16 16:32:13+00:00 - - - Andrew Poelstra 2021-04-16 15:55:47+00:00 - - - Christopher Gilliard 2021-04-16 15:34:33+00:00 - - - Christopher Gilliard 2021-04-16 15:33:40+00:00 - - - Clark Moody 2021-04-16 13:59:01+00:00 - - - Russell O'Connor 2021-04-16 13:56:11+00:00 - - - Christopher Gilliard 2021-04-16 07:45:15+00:00 - + 2025-09-26T15:53:48.991206+00:00 + python-feedgen + + + [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard + 2021-04-16T07:45:00.000Z + + + Russell O'Connor + 2021-04-16T13:56:00.000Z + + + Clark Moody + 2021-04-16T13:59:00.000Z + + + Christopher Gilliard + 2021-04-16T15:33:00.000Z + + + Christopher Gilliard + 2021-04-16T15:34:00.000Z + + + Andrew Poelstra + 2021-04-16T15:55:00.000Z + + + Jeremy + 2021-04-16T16:32:00.000Z + + + Christopher Gilliard + 2021-04-16T17:05:00.000Z + + + Jeremy + 2021-04-16T18:00:00.000Z + + + Kostas Karasavvas + 2021-04-16T19:15:00.000Z + + + Christopher Gilliard + 2021-04-16T20:12:00.000Z + + + Ruben Somsen + 2021-04-16T20:30:00.000Z + + + Christopher Gilliard + 2021-04-16T21:09:00.000Z + + + ZmnSCPxj + 2021-04-16T23:52:00.000Z + + + Christopher Gilliard + 2021-04-17T03:57:00.000Z + + + Kostas Karasavvas + 2021-04-17T07:41:00.000Z + + + Peter Todd + 2021-04-17T15:50:00.000Z + + + Christopher Gilliard + 2021-04-17T16:57:00.000Z + + + yanmaani + 2021-04-20T01:22:00.000Z + + + yanmaani + 2021-04-20T01:23:00.000Z + + + Zach Greenwood + 2021-04-20T08:45:00.000Z + + + Christopher Gilliard + 2021-04-20T17:12:00.000Z + + + Ruben Somsen + 2021-04-20T19:07:00.000Z + + + ZmnSCPxj + 2021-05-03T05:17:00.000Z + + + Ruben Somsen + 2021-05-04T12:51:00.000Z + + @@ -103,13 +131,13 @@ - python-feedgen + 2 Combined summary - BIP - limiting OP_RETURN / HF - 2023-08-02T03:36:18.290138+00:00 + 2025-09-26T15:53:48.994001+00:00 - In a recent email exchange, Ruben Somsen and ZmnSCPxj discussed the concept of blind merged mining (BMM) and its potential drawbacks. They discussed how sidechain functionaries may not earn anything once there are multiple functionaries, as they do all the work but gain nothing in return. However, Ruben explained that if one entity consistently creates all the sidechain blocks without leaving any profit for others, it's easy for anyone to step in and outbid them if they try to abuse their position. He also highlighted the similarity between being a spacechain miner and a spacechain user, with the only difference being the availability of BTC to mine the block reward.The conversation also touched upon the use of the term "sidechain" and whether it accurately describes a chain with its own altcoin. Ruben preferred not to call it a "BMM chain" because, in his view, it's not a sidechain if it has its own altcoin. ZmnSCPxj expressed concern about BMM on the mainchain, stating that sidechain functionaries would not earn anything once there are multiple functionaries, and even with just one functionary, the entire sidechain would depend on that entity. The potential drawbacks of blind merged mining were explored, and the possibility of addressing some of these issues through the spacechain design was discussed.The conversation between Yanmaani and Ruben focused on merged mining. Ruben suggested that the current method of storing one hash for a merkle root in Coinbase is not "blind" and proposed a mechanism called the perpetual one-way peg to enable fair "spacecoin" creation by burning BTC to pay for fees. ZmnSCPxj expressed concern about BMM on the main chain, highlighting the issue of bidding wars among functionaries resulting in no earnings for sidechain functionaries. The dependence on a single sidechain functionary was seen as a potential problem. Ruben proposed a mechanism for blind merged mining using a native token called "spacecoin" and explained how it could avoid some of the issues associated with BMM.Zach Greenwood and Yanmaani discussed the issue of storing data on the blockchain, with Zach suggesting the need for a more efficient way to store data while still being almost as expensive per byte compared to using OP_RETURN. Yanmaani proposed adding rules to limit OP_RETURN transactions and committing data in the coinbase transaction to simplify merged mining. The question of payment handling and potential storage costs were raised. Chris responded, mentioning another email sent to the dev alias with additional BIPs and suggesting discussing those BIPs in a new thread.A message posted to the Bitcoin-dev mailing list proposed the development of a facility for more efficient and cost-effective storage of data on-chain. The post highlighted the limitations of using OP_RETURN and suggested a layer two solution for timestamping that integrates into other services. The existing aggregated timestamping service was mentioned, and the high transaction fees were seen as a deterrent to excessive data embedding in the Bitcoin blockchain.The concept of merged mining and the use of one hash per block were discussed. The issue of competition between users wanting to use the hash was raised, resulting in fee-bidding. The proposal included implementing rules to limit OP_RETURN transactions and committing data in the coinbase transaction. Payment handling and storage costs were also considered.The idea of replacing SHA-256d with another solution was explored, considering the malleability of calculating expensive Proof of Work (PoW) and the need to retool the Peer-to-Peer (P2P) protocol. Incentives for miners to upgrade were also discussed, highlighting the challenges of implementing changes without weaker hash power producing alternate chains that appear valid to old clients. The issues that need to be addressed before replacing SHA-256d were emphasized.Christopher Gilliard and Peter Todd discussed the proposal for a layer 2 solution for timestamping that integrates into other services. The limitations of timestamping for proving uniqueness were highlighted, and an existing aggregated timestamping service was mentioned. The need to prevent excessive data embedding through consensus changes and the current high transaction fees were also discussed.Christopher Gilliard's proposed Bitcoin Improvement Proposal (BIP) regarding OP_RETURN limitations was met with feedback and objections. The proposal suggests increasing the limit and implementing a layer two protocol for data aggregation using merkle trees. Concerns were raised about the need for a hard fork and the lack of detail in the proposal. Additional BIPs were mentioned as a response to address these concerns. Feedback included correcting the byte limit for OP_RETURN and discussing the need for incentives and flexibility in accommodating different use cases.The limitations on OP_RETURN transactions were seen as ineffective in blocking arbitrary data embedding on the blockchain. Encoding data inside legacy multi-signature scriptpubkeys was noted as a workaround, but it posed problems in terms of UTXO set management. The same technique was suggested for P2PKH and P2WSH as well, making it difficult 2021-05-04T12:51:14+00:00 + In a recent email exchange, Ruben Somsen and ZmnSCPxj discussed the concept of blind merged mining (BMM) and its potential drawbacks. They discussed how sidechain functionaries may not earn anything once there are multiple functionaries, as they do all the work but gain nothing in return. However, Ruben explained that if one entity consistently creates all the sidechain blocks without leaving any profit for others, it's easy for anyone to step in and outbid them if they try to abuse their position. He also highlighted the similarity between being a spacechain miner and a spacechain user, with the only difference being the availability of BTC to mine the block reward.The conversation also touched upon the use of the term "sidechain" and whether it accurately describes a chain with its own altcoin. Ruben preferred not to call it a "BMM chain" because, in his view, it's not a sidechain if it has its own altcoin. ZmnSCPxj expressed concern about BMM on the mainchain, stating that sidechain functionaries would not earn anything once there are multiple functionaries, and even with just one functionary, the entire sidechain would depend on that entity. The potential drawbacks of blind merged mining were explored, and the possibility of addressing some of these issues through the spacechain design was discussed.The conversation between Yanmaani and Ruben focused on merged mining. Ruben suggested that the current method of storing one hash for a merkle root in Coinbase is not "blind" and proposed a mechanism called the perpetual one-way peg to enable fair "spacecoin" creation by burning BTC to pay for fees. ZmnSCPxj expressed concern about BMM on the main chain, highlighting the issue of bidding wars among functionaries resulting in no earnings for sidechain functionaries. The dependence on a single sidechain functionary was seen as a potential problem. Ruben proposed a mechanism for blind merged mining using a native token called "spacecoin" and explained how it could avoid some of the issues associated with BMM.Zach Greenwood and Yanmaani discussed the issue of storing data on the blockchain, with Zach suggesting the need for a more efficient way to store data while still being almost as expensive per byte compared to using OP_RETURN. Yanmaani proposed adding rules to limit OP_RETURN transactions and committing data in the coinbase transaction to simplify merged mining. The question of payment handling and potential storage costs were raised. Chris responded, mentioning another email sent to the dev alias with additional BIPs and suggesting discussing those BIPs in a new thread.A message posted to the Bitcoin-dev mailing list proposed the development of a facility for more efficient and cost-effective storage of data on-chain. The post highlighted the limitations of using OP_RETURN and suggested a layer two solution for timestamping that integrates into other services. The existing aggregated timestamping service was mentioned, and the high transaction fees were seen as a deterrent to excessive data embedding in the Bitcoin blockchain.The concept of merged mining and the use of one hash per block were discussed. The issue of competition between users wanting to use the hash was raised, resulting in fee-bidding. The proposal included implementing rules to limit OP_RETURN transactions and committing data in the coinbase transaction. Payment handling and storage costs were also considered.The idea of replacing SHA-256d with another solution was explored, considering the malleability of calculating expensive Proof of Work (PoW) and the need to retool the Peer-to-Peer (P2P) protocol. Incentives for miners to upgrade were also discussed, highlighting the challenges of implementing changes without weaker hash power producing alternate chains that appear valid to old clients. The issues that need to be addressed before replacing SHA-256d were emphasized.Christopher Gilliard and Peter Todd discussed the proposal for a layer 2 solution for timestamping that integrates into other services. The limitations of timestamping for proving uniqueness were highlighted, and an existing aggregated timestamping service was mentioned. The need to prevent excessive data embedding through consensus changes and the current high transaction fees were also discussed.Christopher Gilliard's proposed Bitcoin Improvement Proposal (BIP) regarding OP_RETURN limitations was met with feedback and objections. The proposal suggests increasing the limit and implementing a layer two protocol for data aggregation using merkle trees. Concerns were raised about the need for a hard fork and the lack of detail in the proposal. Additional BIPs were mentioned as a response to address these concerns. Feedback included correcting the byte limit for OP_RETURN and discussing the need for incentives and flexibility in accommodating different use cases.The limitations on OP_RETURN transactions were seen as ineffective in blocking arbitrary data embedding on the blockchain. Encoding data inside legacy multi-signature scriptpubkeys was noted as a workaround, but it posed problems in terms of UTXO set management. The same technique was suggested for P2PKH and P2WSH as well, making it difficult - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Consensus-protocol-immutability-is-a-feature.xml b/static/bitcoin-dev/May_2021/combined_Consensus-protocol-immutability-is-a-feature.xml index a28ba10a9c..8232f7d777 100644 --- a/static/bitcoin-dev/May_2021/combined_Consensus-protocol-immutability-is-a-feature.xml +++ b/static/bitcoin-dev/May_2021/combined_Consensus-protocol-immutability-is-a-feature.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Consensus protocol immutability is a feature - 2023-08-02T03:53:33.433054+00:00 + 2025-09-26T15:54:03.712216+00:00 + python-feedgen Jorge Timón 2021-05-25 10:24:43+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Consensus protocol immutability is a feature - 2023-08-02T03:53:33.433054+00:00 + 2025-09-26T15:54:03.712426+00:00 - In an email exchange on the bitcoin-dev mailing list, the possibility of using softforks for certain changes to the Bitcoin protocol was discussed. While there were differing opinions on whether hardforks should be completely avoided, one proposal suggested changing the block header format to include both SHA-256 and SHA-3 hashes. This would allow new nodes to see the correct SHA-3 hashes if SHA-256 were to be broken in the future. It was also mentioned that the Merkle Tree could be changed to use SHA3 instead. However, it was noted that making changes to the block header format and proof-of-work computation may require a hardfork. Despite this, the coinbase allows for new commitments to be added, similar to SegWit's `witness` field.The discussion emphasized the challenges and hurdles that any hardfork would have to go through, similar to what Taproot and SegWit experienced. Any hardfork would require more engineering manpower and several years of work before being considered. The conversation provided valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. Interested individuals were also invited to join the conversation by signing up for the mailing list. Another discussion on the bitcoin-dev mailing list explored the limitations and possibilities of implementing softforks. It was noted that while significant changes can be made to transaction and block formats with softforks, there are limitations to what can be changed. The block header format and how proof-of-work is computed from it cannot be changed without a hardfork. The discussion highlighted the hurdles that any hardfork would have to overcome, as seen with SegWit and Taproot. Hardforks would require more engineering manpower and several years of work. The conclusion was that it is important to work with the existing system or start working on future solutions today.A user on the mailing list pointed out that the space of possible softforks is wider than expected. They discussed the potential for changes to block discovery rates and cited SegWit as an example of massive changes that can be made with softforks. However, they noted that the block header format and proof-of-work computation cannot be usefully changed with softforks. The discussion also highlighted the importance of Taproot's implementation and deployment, which took time due to controversy surrounding the activation code. It was emphasized that any hardfork would have to go through similar hurdles and must be prepared to work on it for several years. The discussion concluded by emphasizing the need to find solutions for future problems and mentioned the existence of an "emergency" branch for adding post-quantum signature schemes in case of a quantum break.In another email exchange, the topic of consensus protocol changes in Bitcoin was discussed. One participant argued that hard forks are required for hard consensus changes, while soft forks can be useful. Another participant disagreed and highlighted the importance of consensus protocol changes in improving Bitcoin's efficiency and addressing user needs. They mentioned examples like relative lock time verify and SegWit, which have made lightning transactions easier and more efficient. The discussion touched upon the role of hard forks and soft forks in implementing these changes, as well as the ongoing debate within the Bitcoin community about the balance between stability and adapting to changing user needs.Overall, the email exchanges provided valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. They highlighted the challenges and limitations of implementing changes through softforks, the hurdles that any hardfork would have to overcome, and the importance of consensus protocol changes in improving Bitcoin's efficiency and addressing user needs. 2021-05-25T10:24:43+00:00 + In an email exchange on the bitcoin-dev mailing list, the possibility of using softforks for certain changes to the Bitcoin protocol was discussed. While there were differing opinions on whether hardforks should be completely avoided, one proposal suggested changing the block header format to include both SHA-256 and SHA-3 hashes. This would allow new nodes to see the correct SHA-3 hashes if SHA-256 were to be broken in the future. It was also mentioned that the Merkle Tree could be changed to use SHA3 instead. However, it was noted that making changes to the block header format and proof-of-work computation may require a hardfork. Despite this, the coinbase allows for new commitments to be added, similar to SegWit's `witness` field.The discussion emphasized the challenges and hurdles that any hardfork would have to go through, similar to what Taproot and SegWit experienced. Any hardfork would require more engineering manpower and several years of work before being considered. The conversation provided valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. Interested individuals were also invited to join the conversation by signing up for the mailing list. Another discussion on the bitcoin-dev mailing list explored the limitations and possibilities of implementing softforks. It was noted that while significant changes can be made to transaction and block formats with softforks, there are limitations to what can be changed. The block header format and how proof-of-work is computed from it cannot be changed without a hardfork. The discussion highlighted the hurdles that any hardfork would have to overcome, as seen with SegWit and Taproot. Hardforks would require more engineering manpower and several years of work. The conclusion was that it is important to work with the existing system or start working on future solutions today.A user on the mailing list pointed out that the space of possible softforks is wider than expected. They discussed the potential for changes to block discovery rates and cited SegWit as an example of massive changes that can be made with softforks. However, they noted that the block header format and proof-of-work computation cannot be usefully changed with softforks. The discussion also highlighted the importance of Taproot's implementation and deployment, which took time due to controversy surrounding the activation code. It was emphasized that any hardfork would have to go through similar hurdles and must be prepared to work on it for several years. The discussion concluded by emphasizing the need to find solutions for future problems and mentioned the existence of an "emergency" branch for adding post-quantum signature schemes in case of a quantum break.In another email exchange, the topic of consensus protocol changes in Bitcoin was discussed. One participant argued that hard forks are required for hard consensus changes, while soft forks can be useful. Another participant disagreed and highlighted the importance of consensus protocol changes in improving Bitcoin's efficiency and addressing user needs. They mentioned examples like relative lock time verify and SegWit, which have made lightning transactions easier and more efficient. The discussion touched upon the role of hard forks and soft forks in implementing these changes, as well as the ongoing debate within the Bitcoin community about the balance between stability and adapting to changing user needs.Overall, the email exchanges provided valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. They highlighted the challenges and limitations of implementing changes through softforks, the hurdles that any hardfork would have to overcome, and the importance of consensus protocol changes in improving Bitcoin's efficiency and addressing user needs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Encryption-of-an-existing-BIP39-mnemonic-without-changing-the-seed.xml b/static/bitcoin-dev/May_2021/combined_Encryption-of-an-existing-BIP39-mnemonic-without-changing-the-seed.xml index 22f53faea6..a86f914c9a 100644 --- a/static/bitcoin-dev/May_2021/combined_Encryption-of-an-existing-BIP39-mnemonic-without-changing-the-seed.xml +++ b/static/bitcoin-dev/May_2021/combined_Encryption-of-an-existing-BIP39-mnemonic-without-changing-the-seed.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Encryption of an existing BIP39 mnemonic without changing the seed - 2023-08-02T03:44:04.962378+00:00 - - yanmaani at cock.li 2021-05-08 22:49:01+00:00 - - - Tobias Kaupat 2021-05-06 14:10:31+00:00 - - - Erik Aronesty 2021-05-06 13:19:31+00:00 - - - Peter D. Gray 2021-05-06 12:56:37+00:00 - - - Tobias Kaupat 2021-05-05 17:32:05+00:00 - + 2025-09-26T15:54:18.471025+00:00 + python-feedgen + + + [bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed Tobias Kaupat + 2021-05-05T17:32:00.000Z + + + Peter D. Gray + 2021-05-06T12:56:00.000Z + + + Erik Aronesty + 2021-05-06T13:19:00.000Z + + + Tobias Kaupat + 2021-05-06T14:10:00.000Z + + + yanmaani + 2021-05-08T22:49:00.000Z + + - python-feedgen + 2 Combined summary - Encryption of an existing BIP39 mnemonic without changing the seed - 2023-08-02T03:44:04.962378+00:00 + 2025-09-26T15:54:18.471820+00:00 - In a recent post on the bitcoin-dev mailing list, Tobias Kaupat introduced a proposed solution for a use case involving the protection of an existing mnemonic for a hardware wallet. The objective is to save the mnemonic in an encrypted form on a paper backup while maintaining backup properties such as error correction.Kaupat's solution involves several steps. First, the existing mnemonic is used to extract the related entropy. Then, a SHA526 hash is created from a user-defined password, which serves as the key for an AES CTR encryption of the entropy. The encrypted entropy is then used to derive a new mnemonic that can be stored on a paper backup. To restore the original mnemonic, one must know the password and repeat the process.During the discussion, Erik Aronesty suggested stretching the password using pbkdf2 or argon2 with around 30k rounds before hashing it. Kaupat agreed with this suggestion, particularly favoring pbkdf2 since it is already used in the BIP39 specification. He also expressed his preference for solutions based on provably secure algorithms rather than less secure "rot23 derivations" like Seedshift.The proposal put forth by Kaupat requires a security review, and he welcomes feedback and suggestions from the community. He has provided a GoLang implementation of his proposal on GitHub for reference.In addition to Kaupat's proposal, the post mentions another feature called "Seed XOR" offered by Coldcard release. This feature allows multiple standard BIP-39 seed phrases to be bitwise XOR'ed together, creating a new seed. It enables the splitting of an existing seed into multiple phrases or combining an existing seed phrase with a new one to generate a new random seed phrase and wallet. The XOR process can be done manually on paper, and each resulting part has its own checksum and functions as a decoy wallet.Overall, Kaupat's proposal presents a solution for securely encrypting and storing an existing mnemonic on a paper backup, while the Seed XOR feature provides an alternative method for manipulating seed phrases. Both proposals aim to address different use cases and security concerns within the bitcoin-dev community. 2021-05-08T22:49:01+00:00 + In a recent post on the bitcoin-dev mailing list, Tobias Kaupat introduced a proposed solution for a use case involving the protection of an existing mnemonic for a hardware wallet. The objective is to save the mnemonic in an encrypted form on a paper backup while maintaining backup properties such as error correction.Kaupat's solution involves several steps. First, the existing mnemonic is used to extract the related entropy. Then, a SHA526 hash is created from a user-defined password, which serves as the key for an AES CTR encryption of the entropy. The encrypted entropy is then used to derive a new mnemonic that can be stored on a paper backup. To restore the original mnemonic, one must know the password and repeat the process.During the discussion, Erik Aronesty suggested stretching the password using pbkdf2 or argon2 with around 30k rounds before hashing it. Kaupat agreed with this suggestion, particularly favoring pbkdf2 since it is already used in the BIP39 specification. He also expressed his preference for solutions based on provably secure algorithms rather than less secure "rot23 derivations" like Seedshift.The proposal put forth by Kaupat requires a security review, and he welcomes feedback and suggestions from the community. He has provided a GoLang implementation of his proposal on GitHub for reference.In addition to Kaupat's proposal, the post mentions another feature called "Seed XOR" offered by Coldcard release. This feature allows multiple standard BIP-39 seed phrases to be bitwise XOR'ed together, creating a new seed. It enables the splitting of an existing seed into multiple phrases or combining an existing seed phrase with a new one to generate a new random seed phrase and wallet. The XOR process can be done manually on paper, and each resulting part has its own checksum and functions as a decoy wallet.Overall, Kaupat's proposal presents a solution for securely encrypting and storing an existing mnemonic on a paper backup, while the Seed XOR feature provides an alternative method for manipulating seed phrases. Both proposals aim to address different use cases and security concerns within the bitcoin-dev community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Fee-estimates-and-RBF.xml b/static/bitcoin-dev/May_2021/combined_Fee-estimates-and-RBF.xml index 44fdbcce4d..cd18164c24 100644 --- a/static/bitcoin-dev/May_2021/combined_Fee-estimates-and-RBF.xml +++ b/static/bitcoin-dev/May_2021/combined_Fee-estimates-and-RBF.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fee estimates and RBF - 2023-08-02T03:43:36.516184+00:00 + 2025-09-26T15:54:05.823265+00:00 + python-feedgen ZmnSCPxj 2021-05-18 13:10:12+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Fee estimates and RBF - 2023-08-02T03:43:36.516184+00:00 + 2025-09-26T15:54:05.823465+00:00 - Implementing Replace-By-Fee (RBF) in financial code presents challenges in exception handling and testing reorgs. Thorough testing is necessary, but code with many branches due to handling exceptions is difficult to cover completely. C-lightning supports RBF, but potential edge cases may cause mishandling of replaced transactions and loss of onchain funds. The combination of RBF and Child-Pays-for-Parent (CPFP) has yet to be explored fully, with potential use cases like the maker-taker model requiring careful exception handling.In a discussion on Bitcoin Stack Exchange, Jeremy and ZmnSCPxj share their thoughts on fee estimation. The recent CVE related to RBF by Antoine Riard and the differences between RBF implementation in Bitcoin Core and btcd are also discussed. However, the reasoning behind not implementing inherited signalling in Bitcoin Core remains unclear.In an email exchange, ZmnSCPxj and Prayank discuss engineering issues related to a full RBF wallet. While ZmnSCPxj believes a true full-RBF wallet should be the goal, he acknowledges the engineering challenges. He explains the process of a true full-RBF wallet and warns about race conditions when miners find new blocks while fees are being bumped. The wallet needs to track "pending spends" and correlate them with actual transactions. ZmnSCPxj also notes that spending unconfirmed inputs may not be safe due to conflicting transactions. Engineering issues pose significant challenges in achieving a true full-RBF wallet.The author of the message agrees that a "true" full-RBF wallet should be the goal for every on-chain wallet but notes the difficulties in achieving this. They explain how some wallets handle unconfirmed inputs and the simplification of database design. To achieve a true full-RBF wallet, the wallet must keep track of pending spends and correlate them with actual transactions. The author admits they have not considered all factors related to this issue.Jeremy Rubin shares a link with Prayank explaining the concept of a "fee-only" wallet. This feature allows users to arrange fee bumps using a separate wallet without disturbing on-chain dependents. It can be cheaper than RBF since users are not subject to the feerate improvement rule. Rubin suggests creating a market via LN for transaction inclusion by a particular date. Prayank raises concerns about different estimations used in wallets and proposes a three-step approach: showing mempool stats, leaving the fee rate decision to the user, and using RBF algorithms for automated bidding.In an email exchange, Jeremy Rubin shares a post on Bitcoin-dev related to background services. He highlights the potential of a separate fee-only wallet for arranging fee bumps without disturbing on-chain dependents. He suggests it could be cheaper than RBF and discusses the idea of creating a market for transaction inclusion. Prayank discusses different fee estimations and suggests sharing mempool stats and allowing users to decide the fee rate. He proposes using RBF algorithms and wonders if the proposed approach would work offline.The writer begins with personal well-being and recovery from COVID-19 before discussing Bitcoin transactions and fee estimations. They question the use of different estimations and propose showing mempool stats and allowing users to decide on the fee rate. They compare this to estimating buy orders in the BTCUSD orderbook. The writer finds current estimations misleading and suggests a three-step approach, including RBF algorithms for automated bidding. They seek input on the proposed approach and provide an example of replacing transactions with different fee rates even when offline. 2021-05-18T13:10:12+00:00 + Implementing Replace-By-Fee (RBF) in financial code presents challenges in exception handling and testing reorgs. Thorough testing is necessary, but code with many branches due to handling exceptions is difficult to cover completely. C-lightning supports RBF, but potential edge cases may cause mishandling of replaced transactions and loss of onchain funds. The combination of RBF and Child-Pays-for-Parent (CPFP) has yet to be explored fully, with potential use cases like the maker-taker model requiring careful exception handling.In a discussion on Bitcoin Stack Exchange, Jeremy and ZmnSCPxj share their thoughts on fee estimation. The recent CVE related to RBF by Antoine Riard and the differences between RBF implementation in Bitcoin Core and btcd are also discussed. However, the reasoning behind not implementing inherited signalling in Bitcoin Core remains unclear.In an email exchange, ZmnSCPxj and Prayank discuss engineering issues related to a full RBF wallet. While ZmnSCPxj believes a true full-RBF wallet should be the goal, he acknowledges the engineering challenges. He explains the process of a true full-RBF wallet and warns about race conditions when miners find new blocks while fees are being bumped. The wallet needs to track "pending spends" and correlate them with actual transactions. ZmnSCPxj also notes that spending unconfirmed inputs may not be safe due to conflicting transactions. Engineering issues pose significant challenges in achieving a true full-RBF wallet.The author of the message agrees that a "true" full-RBF wallet should be the goal for every on-chain wallet but notes the difficulties in achieving this. They explain how some wallets handle unconfirmed inputs and the simplification of database design. To achieve a true full-RBF wallet, the wallet must keep track of pending spends and correlate them with actual transactions. The author admits they have not considered all factors related to this issue.Jeremy Rubin shares a link with Prayank explaining the concept of a "fee-only" wallet. This feature allows users to arrange fee bumps using a separate wallet without disturbing on-chain dependents. It can be cheaper than RBF since users are not subject to the feerate improvement rule. Rubin suggests creating a market via LN for transaction inclusion by a particular date. Prayank raises concerns about different estimations used in wallets and proposes a three-step approach: showing mempool stats, leaving the fee rate decision to the user, and using RBF algorithms for automated bidding.In an email exchange, Jeremy Rubin shares a post on Bitcoin-dev related to background services. He highlights the potential of a separate fee-only wallet for arranging fee bumps without disturbing on-chain dependents. He suggests it could be cheaper than RBF and discusses the idea of creating a market for transaction inclusion. Prayank discusses different fee estimations and suggests sharing mempool stats and allowing users to decide the fee rate. He proposes using RBF algorithms and wonders if the proposed approach would work offline.The writer begins with personal well-being and recovery from COVID-19 before discussing Bitcoin transactions and fee estimations. They question the use of different estimations and propose showing mempool stats and allowing users to decide on the fee rate. They compare this to estimating buy orders in the BTCUSD orderbook. The writer finds current estimations misleading and suggests a three-step approach, including RBF algorithms for automated bidding. They seek input on the proposed approach and provide an example of replacing transactions with different fee rates even when offline. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Full-Disclosure-CVE-2021-31876-Defect-in-Bitcoin-Core-s-bip125-logic.xml b/static/bitcoin-dev/May_2021/combined_Full-Disclosure-CVE-2021-31876-Defect-in-Bitcoin-Core-s-bip125-logic.xml index 247539bcaa..867a781334 100644 --- a/static/bitcoin-dev/May_2021/combined_Full-Disclosure-CVE-2021-31876-Defect-in-Bitcoin-Core-s-bip125-logic.xml +++ b/static/bitcoin-dev/May_2021/combined_Full-Disclosure-CVE-2021-31876-Defect-in-Bitcoin-Core-s-bip125-logic.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic - 2023-08-02T03:44:14.911782+00:00 - - Olaoluwa Osuntokun 2021-05-13 01:06:21+00:00 - - - Antoine Riard 2021-05-12 13:19:37+00:00 - - - Antoine Riard 2021-05-12 13:11:50+00:00 - - - Luke Dashjr 2021-05-11 21:50:50+00:00 - - - Ruben Somsen 2021-05-11 21:16:18+00:00 - - - darosior 2021-05-09 07:56:43+00:00 - - - Antoine Riard 2021-05-06 13:55:53+00:00 - + 2025-09-26T15:53:51.081634+00:00 + python-feedgen + + + [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic Antoine Riard + 2021-05-06T13:55:00.000Z + + + darosior + 2021-05-09T07:56:00.000Z + + + Ruben Somsen + 2021-05-11T21:16:00.000Z + + + Luke Dashjr + 2021-05-11T21:50:00.000Z + + + Antoine Riard + 2021-05-12T13:11:00.000Z + + + Antoine Riard + 2021-05-12T13:19:00.000Z + + + Olaoluwa Osuntokun + 2021-05-13T01:06:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic - 2023-08-02T03:44:14.911782+00:00 + 2025-09-26T15:53:51.082653+00:00 - Antoine Riard, a Bitcoin Core developer, has identified two defects that have security implications for downstream projects. The first defect is in the Bitcoin Core bip125 logic, where an unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an unconfirmed parent with nSequence does not enforce the "through inheritance" signaling as described in the Bip 125 specification. This allows attackers to pin an opt-out child without a higher fee, reducing the odds of confirmation and lowering the cost of attack.The second defect relates to the Lightning Network (LN) codebase and involves a pinning transaction that signals "RBF opt-in" through nSequence child, but this is inconsistent with the inherited signaling mechanism described in BIP 125. LN nodes operators concerned about this defect may prefer anchor outputs channels to mitigate this specific pinning vector.The defect was disclosed to the LN project maintainers, who were informed that the currently deployed anchor outputs protocol upgrade mitigates the issue, but old channels remain vulnerable. Antoine Riard believes that there is a lack of an established policy for coordinated security disclosures between a base layer implementation and its downstream projects, as well as a lack of a clear methodology to identify affected projects and emergency upgrade mechanisms.The defect was assigned CVE-2021-31876, and full disclosure was made to the bitcoin-dev mailing list. It is important to note that the provided context is incomplete, and more details are needed for a comprehensive summary. 2021-05-13T01:06:21+00:00 + Antoine Riard, a Bitcoin Core developer, has identified two defects that have security implications for downstream projects. The first defect is in the Bitcoin Core bip125 logic, where an unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an unconfirmed parent with nSequence does not enforce the "through inheritance" signaling as described in the Bip 125 specification. This allows attackers to pin an opt-out child without a higher fee, reducing the odds of confirmation and lowering the cost of attack.The second defect relates to the Lightning Network (LN) codebase and involves a pinning transaction that signals "RBF opt-in" through nSequence child, but this is inconsistent with the inherited signaling mechanism described in BIP 125. LN nodes operators concerned about this defect may prefer anchor outputs channels to mitigate this specific pinning vector.The defect was disclosed to the LN project maintainers, who were informed that the currently deployed anchor outputs protocol upgrade mitigates the issue, but old channels remain vulnerable. Antoine Riard believes that there is a lack of an established policy for coordinated security disclosures between a base layer implementation and its downstream projects, as well as a lack of a clear methodology to identify affected projects and emergency upgrade mechanisms.The defect was assigned CVE-2021-31876, and full disclosure was made to the bitcoin-dev mailing list. It is important to note that the provided context is incomplete, and more details are needed for a comprehensive summary. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Gradual-transition-to-an-alternate-proof-without-a-hard-fork-.xml b/static/bitcoin-dev/May_2021/combined_Gradual-transition-to-an-alternate-proof-without-a-hard-fork-.xml index 93e3a299f0..053a8957e9 100644 --- a/static/bitcoin-dev/May_2021/combined_Gradual-transition-to-an-alternate-proof-without-a-hard-fork-.xml +++ b/static/bitcoin-dev/May_2021/combined_Gradual-transition-to-an-alternate-proof-without-a-hard-fork-.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Gradual transition to an alternate proof without a hard fork. - 2023-08-02T03:38:04.408573+00:00 - - Erik Aronesty 2021-05-21 20:54:57+00:00 - - - Billy Tetrud 2021-05-21 20:11:27+00:00 - - - Anthony Towns 2021-04-17 11:47:17+00:00 - - - Devrandom 2021-04-17 11:19:46+00:00 - - - vjudeu 2021-04-17 09:41:44+00:00 - - - Erik Aronesty 2021-04-16 21:47:44+00:00 - - - Jeremy 2021-04-16 21:24:30+00:00 - - - Erik Aronesty 2021-04-16 20:48:35+00:00 - + 2025-09-26T15:54:24.863499+00:00 + python-feedgen + + + [bitcoin-dev] Gradual transition to an alternate proof without a hard fork Erik Aronesty + 2021-04-16T20:48:00.000Z + + + Jeremy + 2021-04-16T21:24:00.000Z + + + Erik Aronesty + 2021-04-16T21:47:00.000Z + + + vjudeu + 2021-04-17T09:41:00.000Z + + + Devrandom + 2021-04-17T11:19:00.000Z + + + Anthony Towns + 2021-04-17T11:47:00.000Z + + + Billy Tetrud + 2021-05-21T20:11:00.000Z + + + Erik Aronesty + 2021-05-21T20:54:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Gradual transition to an alternate proof without a hard fork. - 2023-08-02T03:38:04.408573+00:00 + 2025-09-26T15:54:24.864516+00:00 - A proposal has been made to switch the consensus protocol and hash function for proof of work in Bitcoin. It suggests a transitionary period where both consensus mechanisms are used, allowing miners time to manage the logistics of switching over. The goal is to smoothly switch from 100% of blocks created by the old mechanism to 0%, then gradually increase the blocks created by the new mechanism. However, there is a risk that miners may not cooperate, leading to an unfair distribution of blocks.One possibility discussed is transitioning to a proof-of-burn system, which would require burners to provide proof of burning in addition to proof of work. This would make mining more expensive and decrease the need for proof of work over time. Eventually, the required proof of burn would reach 100% of the required work to mine. It is unclear whether a hard fork would be necessary for this transition, as it could potentially be done in a back-compatible way. However, it is suggested that everyone should be running the new software by a certain date to ensure they follow the same chain.Another option considered is a soft fork to switch to a different proof-of-work algorithm. This would require miners and users to support the transition. The difficulty of proof of work would need to drop to one, and the rest would be solved by a different proof mechanism. As long as enough proof of the new mechanism is produced and most nodes use upgraded software, it should be resistant to attacks. However, gaining support from miners and users may be challenging.The proposed transition from proof of work to proof of burn assumes the existence of a proof-of-burn model that accurately reflects the investment in ASICs for maintaining miner incentives. It suggests a gradual decrease in the need for proof of work as proof of burn becomes more prominent. It questions whether a hard fork would be necessary for this transition, as existing nodes not aware of the rules could continue to validate. However, concerns are raised about the possibility of miners not willing to switch to proof of burn and the potential for one miner to disrupt the system by ramping up difficulty.In a discussion on the bitcoin-dev mailing list, the idea of transitioning from proof of work to proof of burn is proposed. The transition would involve validating nodes requiring proof of burn in addition to proof of work, gradually decreasing the need for proof of work. Eventually, proof of burn would be required at 100% of the "required work" to mine. It is suggested that a hard fork may not be necessary for this transition, as it could be done in a back-compatible way. However, concerns are raised about miners not cooperating and the potential for one miner to increase difficulty for everyone else.Overall, the proposals put forth aim to transition from proof of work to alternative consensus mechanisms such as proof of burn. The transition would require careful planning and coordination among miners and users to ensure a smooth switch over. The necessity of a hard fork or soft fork depends on the specific approach taken, but both options have their challenges and considerations. 2021-05-21T20:54:57+00:00 + A proposal has been made to switch the consensus protocol and hash function for proof of work in Bitcoin. It suggests a transitionary period where both consensus mechanisms are used, allowing miners time to manage the logistics of switching over. The goal is to smoothly switch from 100% of blocks created by the old mechanism to 0%, then gradually increase the blocks created by the new mechanism. However, there is a risk that miners may not cooperate, leading to an unfair distribution of blocks.One possibility discussed is transitioning to a proof-of-burn system, which would require burners to provide proof of burning in addition to proof of work. This would make mining more expensive and decrease the need for proof of work over time. Eventually, the required proof of burn would reach 100% of the required work to mine. It is unclear whether a hard fork would be necessary for this transition, as it could potentially be done in a back-compatible way. However, it is suggested that everyone should be running the new software by a certain date to ensure they follow the same chain.Another option considered is a soft fork to switch to a different proof-of-work algorithm. This would require miners and users to support the transition. The difficulty of proof of work would need to drop to one, and the rest would be solved by a different proof mechanism. As long as enough proof of the new mechanism is produced and most nodes use upgraded software, it should be resistant to attacks. However, gaining support from miners and users may be challenging.The proposed transition from proof of work to proof of burn assumes the existence of a proof-of-burn model that accurately reflects the investment in ASICs for maintaining miner incentives. It suggests a gradual decrease in the need for proof of work as proof of burn becomes more prominent. It questions whether a hard fork would be necessary for this transition, as existing nodes not aware of the rules could continue to validate. However, concerns are raised about the possibility of miners not willing to switch to proof of burn and the potential for one miner to disrupt the system by ramping up difficulty.In a discussion on the bitcoin-dev mailing list, the idea of transitioning from proof of work to proof of burn is proposed. The transition would involve validating nodes requiring proof of burn in addition to proof of work, gradually decreasing the need for proof of work. Eventually, proof of burn would be required at 100% of the "required work" to mine. It is suggested that a hard fork may not be necessary for this transition, as it could be done in a back-compatible way. However, concerns are raised about miners not cooperating and the potential for one miner to increase difficulty for everyone else.Overall, the proposals put forth aim to transition from proof of work to alternative consensus mechanisms such as proof of burn. The transition would require careful planning and coordination among miners and users to ensure a smooth switch over. The necessity of a hard fork or soft fork depends on the specific approach taken, but both options have their challenges and considerations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Improvement-on-Blockbuilding.xml b/static/bitcoin-dev/May_2021/combined_Improvement-on-Blockbuilding.xml index cc3caf920d..8d8cc53699 100644 --- a/static/bitcoin-dev/May_2021/combined_Improvement-on-Blockbuilding.xml +++ b/static/bitcoin-dev/May_2021/combined_Improvement-on-Blockbuilding.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Improvement on Blockbuilding - 2023-08-02T03:55:01.268957+00:00 - - Jorge Timón 2021-05-29 15:04:57+00:00 - - - Antoine Riard 2021-05-29 06:32:53+00:00 - - - Murch 2021-05-25 14:27:06+00:00 - + 2025-09-26T15:54:07.909526+00:00 + python-feedgen + + + [bitcoin-dev] Improvement on Blockbuilding Murch + 2021-05-25T14:27:00.000Z + + + Antoine Riard + 2021-05-29T06:32:00.000Z + + + Jorge Timón + 2021-05-29T15:04:00.000Z + + - python-feedgen + 2 Combined summary - Improvement on Blockbuilding - 2023-08-02T03:55:01.268957+00:00 + 2025-09-26T15:54:07.910085+00:00 - Mark and Clara have proposed an improvement to the current Bitcoin Core block building algorithm. Currently, Bitcoin Core uses a straightforward greedy algorithm which evaluates each transaction’s effective fee rate in the context of its unconfirmed ancestors. This overlooks situations in which multiple descendant transactions could be grouped with their shared ancestors to form a more attractive transaction set for block inclusion.Their suggested algorithm, called Candidate Set-based Block Building (CSB), would consider such scenarios, resulting in more efficient use of block space. Experimental data shows that their algorithm did better on more than 94% of blocks (99% for times of high congestion).However, Antoine raises some questions and concerns about the proposal. He wonders if CSB feerate performance will improve as transaction graphs with multiple disjunctive branches become more regular in the future, citing examples like OP_CTV's style congestion-tree, LN's splicing or chain of coinjoins. He also brings up the issue of malicious miners using hard-to-traverse CPFP constellations to prevent competitors from assembling block templates or slowing down their computation. It remains to be seen how much CSB makes that kind of DoS possible/efficient.From the point of view of global blockspace demand, if miners generally became DPFA-sensitive, it could encourage creation of additional transactions for the sole purpose of bumping stuck ancestors. As ASB's ancestor set and CSB's candidate set, a fee bidder would have to pay the feerate to cover the new transaction fields, high enough to catch up with the already-present feerate set. It might be more fee-rate efficient to RBF the first child, but there is a replacement feerate penalty to consider.A suggestion has been made to improve the current Bitcoin Core block building algorithm by a group of developers. They propose an alternative algorithm that considers grouping multiple descendant transactions with their shared ancestors to form a more attractive transaction set for block inclusion. The current straightforward greedy algorithm overlooks such situations and only evaluates each transaction's effective fee rate in the context of its unconfirmed ancestors.To illustrate, four transactions A, B, C, and D are used as an example along with their fee rates and weights. B is a descendant of A, C is a descendant of B, and D is a descendant of A. The current algorithm would consider {A,B,C} best with an effective fee rate of 10, while the suggested algorithm would also consider {A,B,C,D} which has an effective fee rate of 11.Experimental data shows that the proposed algorithm performs better than the current algorithm on more than 94% of blocks and 99% during times of high congestion.The full details of the proposal can be found in a document provided by the developers, and they welcome any comments, criticisms, or suggestions. The research code for the proposed algorithm is also available on Github. The developers note that LP solvers did slightly better than their proposed algorithm but at the cost of longer running times. However, Greg Maxwell's past research suggests that better running times are possible with LP solvers. 2021-05-29T15:04:57+00:00 + Mark and Clara have proposed an improvement to the current Bitcoin Core block building algorithm. Currently, Bitcoin Core uses a straightforward greedy algorithm which evaluates each transaction’s effective fee rate in the context of its unconfirmed ancestors. This overlooks situations in which multiple descendant transactions could be grouped with their shared ancestors to form a more attractive transaction set for block inclusion.Their suggested algorithm, called Candidate Set-based Block Building (CSB), would consider such scenarios, resulting in more efficient use of block space. Experimental data shows that their algorithm did better on more than 94% of blocks (99% for times of high congestion).However, Antoine raises some questions and concerns about the proposal. He wonders if CSB feerate performance will improve as transaction graphs with multiple disjunctive branches become more regular in the future, citing examples like OP_CTV's style congestion-tree, LN's splicing or chain of coinjoins. He also brings up the issue of malicious miners using hard-to-traverse CPFP constellations to prevent competitors from assembling block templates or slowing down their computation. It remains to be seen how much CSB makes that kind of DoS possible/efficient.From the point of view of global blockspace demand, if miners generally became DPFA-sensitive, it could encourage creation of additional transactions for the sole purpose of bumping stuck ancestors. As ASB's ancestor set and CSB's candidate set, a fee bidder would have to pay the feerate to cover the new transaction fields, high enough to catch up with the already-present feerate set. It might be more fee-rate efficient to RBF the first child, but there is a replacement feerate penalty to consider.A suggestion has been made to improve the current Bitcoin Core block building algorithm by a group of developers. They propose an alternative algorithm that considers grouping multiple descendant transactions with their shared ancestors to form a more attractive transaction set for block inclusion. The current straightforward greedy algorithm overlooks such situations and only evaluates each transaction's effective fee rate in the context of its unconfirmed ancestors.To illustrate, four transactions A, B, C, and D are used as an example along with their fee rates and weights. B is a descendant of A, C is a descendant of B, and D is a descendant of A. The current algorithm would consider {A,B,C} best with an effective fee rate of 10, while the suggested algorithm would also consider {A,B,C,D} which has an effective fee rate of 11.Experimental data shows that the proposed algorithm performs better than the current algorithm on more than 94% of blocks and 99% during times of high congestion.The full details of the proposal can be found in a document provided by the developers, and they welcome any comments, criticisms, or suggestions. The research code for the proposed algorithm is also available on Github. The developers note that LP solvers did slightly better than their proposed algorithm but at the cost of longer running times. However, Greg Maxwell's past research suggests that better running times are possible with LP solvers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Opinion-on-proof-of-stake-in-future.xml b/static/bitcoin-dev/May_2021/combined_Opinion-on-proof-of-stake-in-future.xml index c6bce0cc3b..6de55c24bf 100644 --- a/static/bitcoin-dev/May_2021/combined_Opinion-on-proof-of-stake-in-future.xml +++ b/static/bitcoin-dev/May_2021/combined_Opinion-on-proof-of-stake-in-future.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Opinion on proof of stake in future - 2023-08-02T03:47:09.348187+00:00 + 2025-09-26T15:53:57.426123+00:00 + python-feedgen Billy Tetrud 2021-06-26 16:26:12+00:00 @@ -271,13 +272,13 @@ - python-feedgen + 2 Combined summary - Opinion on proof of stake in future - 2023-08-02T03:47:09.348187+00:00 + 2025-09-26T15:53:57.426366+00:00 - The ongoing debate within the bitcoin-dev community revolves around the compatibility of Proof of Stake (PoS) with Bitcoin's objectives. Some argue that PoS contradicts Bitcoin's permissionless nature and introduces trust into the system, while others propose alternatives like Proof of Burn (PoB) but acknowledge block timing issues. Overall, consensus is that new consensus algorithms must meet high standards, and PoS has not yet demonstrated properties consistent with Bitcoin's objectives.Verifiable Delay Functions (VDFs) are being discussed as a potential solution to regulate block times in proof-of-burn blockchains. However, concerns exist regarding ways to increase sequential speed without compromising energy consumption. Despite these concerns, there are promising developments with VDFs that could address block regulation problems without relying solely on brute-force search PoW.Reducing the block reward in Bitcoin has been proposed as a means to improve its mainstream reputation and reduce energy expenditure. However, it should be noted that the block reward is already being reduced through halving events every four years. Concerns about the environmental impact of Bitcoin mining persist, with estimates suggesting that it consumes more energy than entire countries. Arguments in favor of Bitcoin's energy consumption include the use of renewable energy sources for mining and the potential for Bitcoin to incentivize the development of a more sustainable energy grid.Discussions also revolve around the potential of chip fabs to eliminate the hardware barrier and allow more people to participate in Bitcoin mining. It is believed that the energy economy still has more supply than competition, and as prices drop, renewable energy would outcompete nonrenewable sources. The impact of Bitcoin mining on energy usage is seen as an opportunity for investment in renewable energy sources rather than a cause for shame.Various perspectives on PoS as a consensus mechanism for Bitcoin mining are presented. Some argue against implementing PoS due to security concerns and concentration of power. Others believe that PoS may have advantages for other cryptocurrencies but may not be the best solution for Bitcoin. The discussions highlight the need to find sustainable solutions for mining and energy consumption in the cryptocurrency space, with ongoing exploration of alternatives such as VDFs. 2021-06-26T16:26:12+00:00 + The ongoing debate within the bitcoin-dev community revolves around the compatibility of Proof of Stake (PoS) with Bitcoin's objectives. Some argue that PoS contradicts Bitcoin's permissionless nature and introduces trust into the system, while others propose alternatives like Proof of Burn (PoB) but acknowledge block timing issues. Overall, consensus is that new consensus algorithms must meet high standards, and PoS has not yet demonstrated properties consistent with Bitcoin's objectives.Verifiable Delay Functions (VDFs) are being discussed as a potential solution to regulate block times in proof-of-burn blockchains. However, concerns exist regarding ways to increase sequential speed without compromising energy consumption. Despite these concerns, there are promising developments with VDFs that could address block regulation problems without relying solely on brute-force search PoW.Reducing the block reward in Bitcoin has been proposed as a means to improve its mainstream reputation and reduce energy expenditure. However, it should be noted that the block reward is already being reduced through halving events every four years. Concerns about the environmental impact of Bitcoin mining persist, with estimates suggesting that it consumes more energy than entire countries. Arguments in favor of Bitcoin's energy consumption include the use of renewable energy sources for mining and the potential for Bitcoin to incentivize the development of a more sustainable energy grid.Discussions also revolve around the potential of chip fabs to eliminate the hardware barrier and allow more people to participate in Bitcoin mining. It is believed that the energy economy still has more supply than competition, and as prices drop, renewable energy would outcompete nonrenewable sources. The impact of Bitcoin mining on energy usage is seen as an opportunity for investment in renewable energy sources rather than a cause for shame.Various perspectives on PoS as a consensus mechanism for Bitcoin mining are presented. Some argue against implementing PoS due to security concerns and concentration of power. Others believe that PoS may have advantages for other cryptocurrencies but may not be the best solution for Bitcoin. The discussions highlight the need to find sustainable solutions for mining and energy consumption in the cryptocurrency space, with ongoing exploration of alternatives such as VDFs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Prediction-Markets-and-Bitcoin.xml b/static/bitcoin-dev/May_2021/combined_Prediction-Markets-and-Bitcoin.xml index 7e9faacdb2..54d3e05357 100644 --- a/static/bitcoin-dev/May_2021/combined_Prediction-Markets-and-Bitcoin.xml +++ b/static/bitcoin-dev/May_2021/combined_Prediction-Markets-and-Bitcoin.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Prediction Markets and Bitcoin - 2023-08-02T03:32:35.386426+00:00 - - ZmnSCPxj 2021-05-18 12:15:58+00:00 - - - Prayank 2021-05-11 09:05:40+00:00 - - - ZmnSCPxj 2021-04-16 03:39:27+00:00 - - - Prayank 2021-04-07 19:07:45+00:00 - + 2025-09-26T15:53:59.514008+00:00 + python-feedgen + + + [bitcoin-dev] Prediction Markets and Bitcoin Prayank + 2021-04-07T19:07:00.000Z + + + ZmnSCPxj + 2021-04-16T03:39:00.000Z + + + Prayank + 2021-05-11T09:05:00.000Z + + + ZmnSCPxj + 2021-05-18T12:15:00.000Z + + - python-feedgen + 2 Combined summary - Prediction Markets and Bitcoin - 2023-08-02T03:32:35.386426+00:00 + 2025-09-26T15:53:59.514668+00:00 - The direction of Bitcoin development should not be solely determined by those funding it, as they may have their own opinions and influence. While a position in a futures market represents a prediction about the possible outcomes of an event, it is not equivalent to funding Bitcoin development. Bitcoin developers often have a significant stake in Bitcoin, and changes in its price can greatly affect their life savings. A position in a futures market can represent an implicit threat to "fund" or "de-fund" developers based on the direction of development.The email discusses the use of futures markets in Bitcoin, acknowledging their potential benefits for hedging and collecting information, but also warning about their potential misuse. The writer agrees that development must be free to experiment and follow what is best technically, but disagrees that development must follow the market. They argue that people funding Bitcoin development can have opinions and influence but cannot impose or force anything on the Bitcoin protocol. Prediction markets are suggested as a way to negotiate between the two aspects.The email provides examples of how futures markets can be used in Bitcoin, such as hedging transaction fees or the activation of soft forks like Taproot. However, the email also warns about issues with incentives, legality, knowledge, and volume and liquidity that could lead to incorrect usage of futures markets. The inaccuracies of prediction markets are also discussed, including past failures in predicting events such as Brexit and the 2016 US presidential elections.The CEO of Sid Meier's Alpha Centauri, Nwabudike Morgan, once stated that human behavior is economic behavior and competition for limited resources remains a constant. This statement holds true in the world of cryptocurrency and blockchain technology where every joule of negentropy is a carefully measured resource. While it is essential for development to be free and experiment with new techniques, the people funding the development must impose the direction of the development. The negotiation between these two aspects is difficult and often unclear, which is why prediction markets are necessary to advance the negotiation process.Bitcoin futures markets provide an opportunity to make money and filter out noise, but require money to participate. They can also be manipulated by exchanges or traders with large amounts of money and could distract from the development of Bitcoin itself. Prediction markets or tokens could help improve information about Bitcoin, but should not replace Bitcoin development. The writer suggests a chatroom requiring payments in satoshis as a better way to filter out noise while also supporting developers.In conclusion, the email acknowledges the role of futures markets in Bitcoin, but cautions against relying solely on them to decide important matters in Bitcoin. Instead, the writer emphasizes the importance of considering a wide range of sources such as the Bitcoin Dev Mailing List, GitHub repositories, IRC channels, and conversations with various stakeholders involved in Bitcoin. 2021-05-18T12:15:58+00:00 + The direction of Bitcoin development should not be solely determined by those funding it, as they may have their own opinions and influence. While a position in a futures market represents a prediction about the possible outcomes of an event, it is not equivalent to funding Bitcoin development. Bitcoin developers often have a significant stake in Bitcoin, and changes in its price can greatly affect their life savings. A position in a futures market can represent an implicit threat to "fund" or "de-fund" developers based on the direction of development.The email discusses the use of futures markets in Bitcoin, acknowledging their potential benefits for hedging and collecting information, but also warning about their potential misuse. The writer agrees that development must be free to experiment and follow what is best technically, but disagrees that development must follow the market. They argue that people funding Bitcoin development can have opinions and influence but cannot impose or force anything on the Bitcoin protocol. Prediction markets are suggested as a way to negotiate between the two aspects.The email provides examples of how futures markets can be used in Bitcoin, such as hedging transaction fees or the activation of soft forks like Taproot. However, the email also warns about issues with incentives, legality, knowledge, and volume and liquidity that could lead to incorrect usage of futures markets. The inaccuracies of prediction markets are also discussed, including past failures in predicting events such as Brexit and the 2016 US presidential elections.The CEO of Sid Meier's Alpha Centauri, Nwabudike Morgan, once stated that human behavior is economic behavior and competition for limited resources remains a constant. This statement holds true in the world of cryptocurrency and blockchain technology where every joule of negentropy is a carefully measured resource. While it is essential for development to be free and experiment with new techniques, the people funding the development must impose the direction of the development. The negotiation between these two aspects is difficult and often unclear, which is why prediction markets are necessary to advance the negotiation process.Bitcoin futures markets provide an opportunity to make money and filter out noise, but require money to participate. They can also be manipulated by exchanges or traders with large amounts of money and could distract from the development of Bitcoin itself. Prediction markets or tokens could help improve information about Bitcoin, but should not replace Bitcoin development. The writer suggests a chatroom requiring payments in satoshis as a better way to filter out noise while also supporting developers.In conclusion, the email acknowledges the role of futures markets in Bitcoin, but cautions against relying solely on them to decide important matters in Bitcoin. Instead, the writer emphasizes the importance of considering a wide range of sources such as the Bitcoin Dev Mailing List, GitHub repositories, IRC channels, and conversations with various stakeholders involved in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Proposal-Force-to-do-nothing-for-first-9-minutes-to-save-90-of-mining-energy.xml b/static/bitcoin-dev/May_2021/combined_Proposal-Force-to-do-nothing-for-first-9-minutes-to-save-90-of-mining-energy.xml index 0aa4e7daa1..323ac9d472 100644 --- a/static/bitcoin-dev/May_2021/combined_Proposal-Force-to-do-nothing-for-first-9-minutes-to-save-90-of-mining-energy.xml +++ b/static/bitcoin-dev/May_2021/combined_Proposal-Force-to-do-nothing-for-first-9-minutes-to-save-90-of-mining-energy.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy - 2023-08-02T03:51:50.970249+00:00 + 2025-09-26T15:53:55.310736+00:00 + python-feedgen ZmnSCPxj 2021-05-18 08:04:56+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy - 2023-08-02T03:51:50.970249+00:00 + 2025-09-26T15:53:55.310944+00:00 - One of the main concerns surrounding Bitcoin mining is its high energy consumption. However, it is important to consider that the cost of mining Bitcoin involves more than just energy, including capital expenses and operational costs. Miners who have access to excess waste energy, such as Chinese miners near hydropower stations, pay a near-zero price for energy, which contributes significantly to the total energy usage of Bitcoin. While the energy usage is high, it is worth noting that a considerable amount of this energy comes from renewable sources, making the carbon footprint of Bitcoin less alarming than it seems.The email thread discusses various proposals to address the issue of energy consumption in Bitcoin mining. One proposal suggests encouraging users to support "green miners" by allowing only these miners to process their transactions. This would create economic incentives for miners to use green energy or purchase offsets. Another proposal suggests implementing a clock mechanism on a peer network level, where transactions would be broadcasted after a 9-minute delay. This could potentially decrease energy consumption, but there are concerns about its feasibility and effectiveness.There is also a discussion about the relationship between mining budgets and energy expenditure. Some argue that reducing energy consumption may lead to increased spending on hardware. It is important to find a balance between energy efficiency and maintaining the security and robustness of the Bitcoin network.In an email to the bitcoin-dev mailing list, Michael Fuhrmann proposes the idea of not mining for the first 9 minutes after a block is found. This aims to prevent pre-mining during this time window. However, there are concerns about the security of the network and the synchronization of clocks in a distributed network. While the idea may be appreciated, it appears to be impractical.Overall, the email thread provides a comprehensive overview of the different proposals and considerations related to the issue of energy consumption in Bitcoin mining. Finding a working solution that addresses energy concerns without compromising the robustness of the network is crucial for the sustainability of Bitcoin mining. 2021-05-18T08:04:56+00:00 + One of the main concerns surrounding Bitcoin mining is its high energy consumption. However, it is important to consider that the cost of mining Bitcoin involves more than just energy, including capital expenses and operational costs. Miners who have access to excess waste energy, such as Chinese miners near hydropower stations, pay a near-zero price for energy, which contributes significantly to the total energy usage of Bitcoin. While the energy usage is high, it is worth noting that a considerable amount of this energy comes from renewable sources, making the carbon footprint of Bitcoin less alarming than it seems.The email thread discusses various proposals to address the issue of energy consumption in Bitcoin mining. One proposal suggests encouraging users to support "green miners" by allowing only these miners to process their transactions. This would create economic incentives for miners to use green energy or purchase offsets. Another proposal suggests implementing a clock mechanism on a peer network level, where transactions would be broadcasted after a 9-minute delay. This could potentially decrease energy consumption, but there are concerns about its feasibility and effectiveness.There is also a discussion about the relationship between mining budgets and energy expenditure. Some argue that reducing energy consumption may lead to increased spending on hardware. It is important to find a balance between energy efficiency and maintaining the security and robustness of the Bitcoin network.In an email to the bitcoin-dev mailing list, Michael Fuhrmann proposes the idea of not mining for the first 9 minutes after a block is found. This aims to prevent pre-mining during this time window. However, there are concerns about the security of the network and the synchronization of clocks in a distributed network. While the idea may be appreciated, it appears to be impractical.Overall, the email thread provides a comprehensive overview of the different proposals and considerations related to the issue of energy consumption in Bitcoin mining. Finding a working solution that addresses energy concerns without compromising the robustness of the network is crucial for the sustainability of Bitcoin mining. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Proposal-Low-Energy-Bitcoin-PoW.xml b/static/bitcoin-dev/May_2021/combined_Proposal-Low-Energy-Bitcoin-PoW.xml index c55cdc17f8..ef17bf3418 100644 --- a/static/bitcoin-dev/May_2021/combined_Proposal-Low-Energy-Bitcoin-PoW.xml +++ b/static/bitcoin-dev/May_2021/combined_Proposal-Low-Energy-Bitcoin-PoW.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Proposal: Low Energy Bitcoin PoW - 2023-08-02T03:53:12.628777+00:00 - - Keagan McClelland 2021-05-18 16:47:29+00:00 - - - ZmnSCPxj 2021-05-18 12:58:19+00:00 - - - Claus Ehrenberg 2021-05-18 12:46:39+00:00 - - - ZmnSCPxj 2021-05-18 12:22:09+00:00 - - - mike at powx.org 2021-05-18 12:17:46+00:00 - - - ZmnSCPxj 2021-05-18 11:58:44+00:00 - - - mike at powx.org 2021-05-18 11:43:18+00:00 - - - ZmnSCPxj 2021-05-18 11:36:49+00:00 - - - mike at powx.org 2021-05-18 11:05:44+00:00 - - - mike at powx.org 2021-05-18 10:59:46+00:00 - - - ZmnSCPxj 2021-05-18 10:58:59+00:00 - - - Devrandom 2021-05-18 09:18:24+00:00 - - - ZmnSCPxj 2021-05-18 06:46:58+00:00 - - - Keagan McClelland 2021-05-17 21:13:42+00:00 - - - Bogdan Penkovsky 2021-05-17 19:32:08+00:00 - + 2025-09-26T15:54:10.029125+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Low Energy Bitcoin PoW Bogdan Penkovsky + 2021-05-17T19:32:00.000Z + + + Keagan McClelland + 2021-05-17T21:13:00.000Z + + + ZmnSCPxj + 2021-05-18T06:46:00.000Z + + + Devrandom + 2021-05-18T09:18:00.000Z + + + ZmnSCPxj + 2021-05-18T10:58:00.000Z + + + mike + 2021-05-18T10:59:00.000Z + + + mike + 2021-05-18T11:05:00.000Z + + + ZmnSCPxj + 2021-05-18T11:36:00.000Z + + + mike + 2021-05-18T11:43:00.000Z + + + ZmnSCPxj + 2021-05-18T11:58:00.000Z + + + mike + 2021-05-18T12:17:00.000Z + + + ZmnSCPxj + 2021-05-18T12:22:00.000Z + + + Claus Ehrenberg + 2021-05-18T12:46:00.000Z + + + ZmnSCPxj + 2021-05-18T12:58:00.000Z + + + Keagan McClelland + 2021-05-18T16:47:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Proposal: Low Energy Bitcoin PoW - 2023-08-02T03:53:12.628777+00:00 + 2025-09-26T15:54:10.030897+00:00 - A draft proposal has been introduced to the Bitcoin development community, outlining a new proof-of-work (PoW) called Optical Proof of Work (oPoW). The goal of this proposal is to address Bitcoin's heavy energy consumption, which has led to mining centralization and limited participation in the network. The oPoW aims to shift the focus of mining expenses from energy to hardware, allowing for a more energy-efficient and secure system.By implementing oPoW, the operating costs of mining can be reduced, making it easier for new miners to enter the market. This would be achieved by investing in low-energy photonic miners, thus reducing the reliance on massive energy consumption. The authors emphasize the importance of maintaining the security of PoW while decreasing its environmental impact.The PoWx organization has proposed oPoW as an alternative method for cryptocurrency mining. It utilizes photonic processors that leverage waveguides in silicon to perform matrix-vector multiplications essential for mining. The organization has even developed example code for obtaining the matrix M using a pseudo-random number generation algorithm.The distribution of mining activity relative to the cost of operating a single mining hardware piece (CAPEX/OPEX ratio) is also discussed in the proposal. It suggests that a shift towards capital expenses rather than energy expenses can lead to reduced energy consumption and geographically distributed mining.To implement oPoW on the Bitcoin network, a hard fork is not necessarily required. It can be added as a dual PoW alongside the existing system through a soft fork. The PoWx organization anticipates demonstrating commercial low-energy mining on their network within the next six months due to significant advancements in optical and analog matrix-vector-multiplication chipsets.In light of recent events, such as the hashrate crash in China and Tesla's change in accepting Bitcoin as payment, the proposal highlights the real-world downsides of the current energy-intensive PoW. The authors recommend updating the underlying PoW protocol to ensure scalability and sustainability as Bitcoin evolves into a global currency.Overall, the oPoW proposal aims to address the environmental concerns associated with Bitcoin mining by shifting the focus from energy to hardware expenses. By doing so, it seeks to increase participation in the network, reduce energy consumption, and maintain the security of the PoW system. The authors plan to release open-source hardware designs for oPoW miner prototypes and continue their efforts to advance low-energy mining capabilities. 2021-05-18T16:47:29+00:00 + A draft proposal has been introduced to the Bitcoin development community, outlining a new proof-of-work (PoW) called Optical Proof of Work (oPoW). The goal of this proposal is to address Bitcoin's heavy energy consumption, which has led to mining centralization and limited participation in the network. The oPoW aims to shift the focus of mining expenses from energy to hardware, allowing for a more energy-efficient and secure system.By implementing oPoW, the operating costs of mining can be reduced, making it easier for new miners to enter the market. This would be achieved by investing in low-energy photonic miners, thus reducing the reliance on massive energy consumption. The authors emphasize the importance of maintaining the security of PoW while decreasing its environmental impact.The PoWx organization has proposed oPoW as an alternative method for cryptocurrency mining. It utilizes photonic processors that leverage waveguides in silicon to perform matrix-vector multiplications essential for mining. The organization has even developed example code for obtaining the matrix M using a pseudo-random number generation algorithm.The distribution of mining activity relative to the cost of operating a single mining hardware piece (CAPEX/OPEX ratio) is also discussed in the proposal. It suggests that a shift towards capital expenses rather than energy expenses can lead to reduced energy consumption and geographically distributed mining.To implement oPoW on the Bitcoin network, a hard fork is not necessarily required. It can be added as a dual PoW alongside the existing system through a soft fork. The PoWx organization anticipates demonstrating commercial low-energy mining on their network within the next six months due to significant advancements in optical and analog matrix-vector-multiplication chipsets.In light of recent events, such as the hashrate crash in China and Tesla's change in accepting Bitcoin as payment, the proposal highlights the real-world downsides of the current energy-intensive PoW. The authors recommend updating the underlying PoW protocol to ensure scalability and sustainability as Bitcoin evolves into a global currency.Overall, the oPoW proposal aims to address the environmental concerns associated with Bitcoin mining by shifting the focus from energy to hardware expenses. By doing so, it seeks to increase participation in the network, reduce energy consumption, and maintain the security of the PoW system. The authors plan to release open-source hardware designs for oPoW miner prototypes and continue their efforts to advance low-energy mining capabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Proposal-for-an-Informational-BIP.xml b/static/bitcoin-dev/May_2021/combined_Proposal-for-an-Informational-BIP.xml index b3207f3750..3907fbf2f2 100644 --- a/static/bitcoin-dev/May_2021/combined_Proposal-for-an-Informational-BIP.xml +++ b/static/bitcoin-dev/May_2021/combined_Proposal-for-an-Informational-BIP.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Proposal for an Informational BIP - 2023-08-02T03:51:11.330003+00:00 - - BitPLATES (Chris) 2021-05-11 17:45:13+00:00 - - - BitPLATES (Chris) 2021-05-11 08:48:44+00:00 - - - BitPLATES (Chris) 2021-05-10 06:30:22+00:00 - - - Tobias Kaupat 2021-05-09 22:53:51+00:00 - - - BitPLATES (Chris) 2021-05-09 08:29:05+00:00 - - - Tobias Kaupat 2021-05-09 07:24:28+00:00 - - - BitPLATES® (Chris) 2021-05-08 15:21:51+00:00 - + 2025-09-26T15:54:01.601625+00:00 + python-feedgen + + + [bitcoin-dev] Proposal for an Informational BIP BitPLATES® (Chris) + 2021-05-08T15:21:00.000Z + + + Tobias Kaupat + 2021-05-09T07:24:00.000Z + + + BitPLATES (Chris) + 2021-05-09T08:29:00.000Z + + + Tobias Kaupat + 2021-05-09T22:53:00.000Z + + + BitPLATES (Chris) + 2021-05-10T06:30:00.000Z + + + BitPLATES (Chris) + 2021-05-11T08:48:00.000Z + + + BitPLATES (Chris) + 2021-05-11T17:45:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Proposal for an Informational BIP - 2023-08-02T03:51:11.330003+00:00 + 2025-09-26T15:54:01.602520+00:00 - The email conversation revolves around Chris's proposal for a 'quantum' passphrase as an optional method of producing a BIP39 passphrase. The proposal aims to provide two-factor authentication and a high level of protection for a Bitcoin wallet using only 24 seed words. It offers several advantages over existing methods, including plausible deniability, discouragement of user-created passphrases, and standardization through the use of BIP39-only words. The method involves generating the BIP39 mnemonic seed words and converting them into the 'quantum' passphrase following four non-destructive rules.The proposal suggests using a 'quantum' passphrase to enhance the security of backup devices and prevent coercion. This passphrase is up to 96 characters long, discouraging the use of user-created words or sentences that may compromise security. The large amount of data required for the passphrase also encourages physical backup.Additionally, the use of BIP39-only words in the passphrase provides standardization and helps avoid mistakes from overly complicated combinations of letters, numbers, and symbols. By creating a two-wallet configuration, users can split the two factors of protection, similar to a 2 of 2 'multi-sig' setup.Creating a BIP39-compatible passphrase with a new set of 24 seed words adds 76 degrees of complexity, meaning there are 10⁷⁶ possible combinations of words. Following four non-destructive BIP39-compatible rules, these 24 seed words can function as a 'quantum' passphrase. This approach offers adequate risk management by producing multiple backup devices and storing them strategically in different geographical locations. 2021-05-11T17:45:13+00:00 + The email conversation revolves around Chris's proposal for a 'quantum' passphrase as an optional method of producing a BIP39 passphrase. The proposal aims to provide two-factor authentication and a high level of protection for a Bitcoin wallet using only 24 seed words. It offers several advantages over existing methods, including plausible deniability, discouragement of user-created passphrases, and standardization through the use of BIP39-only words. The method involves generating the BIP39 mnemonic seed words and converting them into the 'quantum' passphrase following four non-destructive rules.The proposal suggests using a 'quantum' passphrase to enhance the security of backup devices and prevent coercion. This passphrase is up to 96 characters long, discouraging the use of user-created words or sentences that may compromise security. The large amount of data required for the passphrase also encourages physical backup.Additionally, the use of BIP39-only words in the passphrase provides standardization and helps avoid mistakes from overly complicated combinations of letters, numbers, and symbols. By creating a two-wallet configuration, users can split the two factors of protection, similar to a 2 of 2 'multi-sig' setup.Creating a BIP39-compatible passphrase with a new set of 24 seed words adds 76 degrees of complexity, meaning there are 10⁷⁶ possible combinations of words. Following four non-destructive BIP39-compatible rules, these 24 seed words can function as a 'quantum' passphrase. This approach offers adequate risk management by producing multiple backup devices and storing them strategically in different geographical locations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Reducing-block-reward-via-soft-fork.xml b/static/bitcoin-dev/May_2021/combined_Reducing-block-reward-via-soft-fork.xml index e200c051fe..20d71c1354 100644 --- a/static/bitcoin-dev/May_2021/combined_Reducing-block-reward-via-soft-fork.xml +++ b/static/bitcoin-dev/May_2021/combined_Reducing-block-reward-via-soft-fork.xml @@ -1,50 +1,71 @@ - + 2 Combined summary - Reducing block reward via soft fork - 2023-08-02T03:54:30.370790+00:00 - - Billy Tetrud 2021-05-25 19:40:58+00:00 - - - Melvin Carvalho 2021-05-25 08:53:40+00:00 - - - Jorge Timón 2021-05-25 08:35:56+00:00 - - - Billy Tetrud 2021-05-25 08:01:07+00:00 - - - Karl 2021-05-25 00:55:34+00:00 - - - Phuoc Do 2021-05-24 22:03:32+00:00 - - - Erik Aronesty 2021-05-24 21:55:14+00:00 - - - Billy Tetrud 2021-05-24 20:28:41+00:00 - - - Karl 2021-05-23 19:44:18+00:00 - - - ZmnSCPxj 2021-05-23 13:35:12+00:00 - - - Karl 2021-05-23 12:08:33+00:00 - - - ZmnSCPxj 2021-05-23 11:26:59+00:00 - - - Anton Ragin 2021-05-23 10:42:49+00:00 - - - James Lu 2021-05-23 01:00:19+00:00 - + 2025-09-26T15:54:22.743147+00:00 + python-feedgen + + + [bitcoin-dev] Reducing block reward via soft fork James Lu + 2021-05-23T01:00:00.000Z + + + Anton Ragin + 2021-05-23T10:42:00.000Z + + + [bitcoin-dev] " ZmnSCPxj + 2021-05-23T11:26:00.000Z + + + Karl + 2021-05-23T12:08:00.000Z + + + ZmnSCPxj + 2021-05-23T13:35:00.000Z + + + [bitcoin-dev] Fwd: " James Lu + 2021-05-23T14:40:00.000Z + + + Karl + 2021-05-23T19:44:00.000Z + + + Billy Tetrud + 2021-05-24T20:28:00.000Z + + + Erik Aronesty + 2021-05-24T21:55:00.000Z + + + Phuoc Do + 2021-05-24T22:03:00.000Z + + + Karl + 2021-05-25T00:55:00.000Z + + + Billy Tetrud + 2021-05-25T08:01:00.000Z + + + Jorge Timón + 2021-05-25T08:35:00.000Z + + + Melvin Carvalho + 2021-05-25T08:53:00.000Z + + + Billy Tetrud + 2021-05-25T19:40:00.000Z + + @@ -59,13 +80,13 @@ - python-feedgen + 2 Combined summary - Reducing block reward via soft fork - 2023-08-02T03:54:30.371792+00:00 + 2025-09-26T15:54:22.744825+00:00 - In a recent email exchange among Bitcoin community members, the security of Bitcoin was discussed. Estimates for the cost of an attack on Bitcoin ranged from $1.5 billion to $720 billion for government attacks. The security model of Bitcoin was described as dual and heterogeneous, with both a block subsidy and fee model. Fluctuation of fees was identified as a factor that could impact the effectiveness of an attack. The discussion also touched upon reducing Bitcoin's security to save costs, acknowledging the need for more accurate analysis to determine necessary security levels and attack budgets. Suggestions were made to incentivize good behavior in the mining industry, such as coding incentives for investigating miners' business practices.Concerns were raised about the environmental impact of Bitcoin mining, with proposals to address energy consumption and pollution. Making proof of work a proof of environmental kindness was suggested, but it was recognized that no single solution exists and agreement on acceptable solutions is necessary. Potential vulnerabilities of Bitcoin were examined, including covert compromise of mining pool operations, widespread compromise of networked mining systems, and the possibility of government interference in mining farms. Careful consideration of security measures was emphasized to protect against attacks.The relationship between security and inflation in Bitcoin was explored, with arguments that a fee market alone is not sufficient to sustain the system. The need for more energy usage and determining how much energy should be spent on mining were also discussed. The level of security required for transactions on the blockchain was deliberated, noting that while most transactions may not require high security, all transactions must have the same level of security if provided. The Lightning Network was proposed as a solution for securing majority transactions that do not require extensive security measures.Overall, the discussions highlighted the importance of determining the necessary level of security for Bitcoin and making informed decisions on trade-offs. More accurate analysis, careful consideration of alternative solutions, and addressing vulnerabilities were deemed crucial for the future of Bitcoin.Another discussion on the Bitcoin-dev mailing list focused on reducing the block reward and its impact on energy use. It was suggested that increasing popularity of Bitcoin raises fees and energy use, but if it becomes an issue, the block size could be raised to lower fees. However, there is little economic incentive to fine carbon emissions, and enforcing that pollution be paid for by those who cause it was emphasized. Various suggestions were made to prove carbon offsetting and implement an on-chain tax for environmental harm.The author argued that reducing the block reward of Bitcoin is not necessarily bad as it reduces the incentive to mine and lowers energy consumption. The focus should be on energy efficiency rather than energy use, aiming to get the most work possible with the least entropy-increase. Properly accounting for negative environmental effects of mining and charging fines to miners would naturally encourage the adoption of sustainable and renewable processes. The author also highlighted the importance of not rejecting Bitcoin based on environmental concerns, as it is an honest currency in accounting for its energy usage. The need to enforce that pollution be paid for by those who cause it was emphasized.An alternative to outright rejection of transactions that attempt to spend increased block rewards was suggested: treating them as no-ops. However, this alternative was deemed inefficient as it reduces available block space for operational transactions.The Bitcoin network has a self-balancing system that reduces energy consumption as adoption decreases due to public concerns about its environmental impact. In 2024, block rewards will decrease by 50%, further reducing miner incentives. To make Bitcoin greener, users could prioritize green miners who would receive more transaction fees, creating an economic incentive for environmentally-friendly mining. A proposal was made to gradually reduce the block reward by adding fewer coins to the UTXO set per block. This proposal has potential weaknesses, including centralization towards Chinese miners, the risk of network split without consensus, and the cost of reversing recent Bitcoin transactions. Despite these challenges, given the current political climate and public discussion on Bitcoin's energy use, it may be socially feasible to ask users and major exchanges to install a version of Bitcoin that implements this proposal. 2021-05-25T19:40:58+00:00 + In a recent email exchange among Bitcoin community members, the security of Bitcoin was discussed. Estimates for the cost of an attack on Bitcoin ranged from $1.5 billion to $720 billion for government attacks. The security model of Bitcoin was described as dual and heterogeneous, with both a block subsidy and fee model. Fluctuation of fees was identified as a factor that could impact the effectiveness of an attack. The discussion also touched upon reducing Bitcoin's security to save costs, acknowledging the need for more accurate analysis to determine necessary security levels and attack budgets. Suggestions were made to incentivize good behavior in the mining industry, such as coding incentives for investigating miners' business practices.Concerns were raised about the environmental impact of Bitcoin mining, with proposals to address energy consumption and pollution. Making proof of work a proof of environmental kindness was suggested, but it was recognized that no single solution exists and agreement on acceptable solutions is necessary. Potential vulnerabilities of Bitcoin were examined, including covert compromise of mining pool operations, widespread compromise of networked mining systems, and the possibility of government interference in mining farms. Careful consideration of security measures was emphasized to protect against attacks.The relationship between security and inflation in Bitcoin was explored, with arguments that a fee market alone is not sufficient to sustain the system. The need for more energy usage and determining how much energy should be spent on mining were also discussed. The level of security required for transactions on the blockchain was deliberated, noting that while most transactions may not require high security, all transactions must have the same level of security if provided. The Lightning Network was proposed as a solution for securing majority transactions that do not require extensive security measures.Overall, the discussions highlighted the importance of determining the necessary level of security for Bitcoin and making informed decisions on trade-offs. More accurate analysis, careful consideration of alternative solutions, and addressing vulnerabilities were deemed crucial for the future of Bitcoin.Another discussion on the Bitcoin-dev mailing list focused on reducing the block reward and its impact on energy use. It was suggested that increasing popularity of Bitcoin raises fees and energy use, but if it becomes an issue, the block size could be raised to lower fees. However, there is little economic incentive to fine carbon emissions, and enforcing that pollution be paid for by those who cause it was emphasized. Various suggestions were made to prove carbon offsetting and implement an on-chain tax for environmental harm.The author argued that reducing the block reward of Bitcoin is not necessarily bad as it reduces the incentive to mine and lowers energy consumption. The focus should be on energy efficiency rather than energy use, aiming to get the most work possible with the least entropy-increase. Properly accounting for negative environmental effects of mining and charging fines to miners would naturally encourage the adoption of sustainable and renewable processes. The author also highlighted the importance of not rejecting Bitcoin based on environmental concerns, as it is an honest currency in accounting for its energy usage. The need to enforce that pollution be paid for by those who cause it was emphasized.An alternative to outright rejection of transactions that attempt to spend increased block rewards was suggested: treating them as no-ops. However, this alternative was deemed inefficient as it reduces available block space for operational transactions.The Bitcoin network has a self-balancing system that reduces energy consumption as adoption decreases due to public concerns about its environmental impact. In 2024, block rewards will decrease by 50%, further reducing miner incentives. To make Bitcoin greener, users could prioritize green miners who would receive more transaction fees, creating an economic incentive for environmentally-friendly mining. A proposal was made to gradually reduce the block reward by adding fewer coins to the UTXO set per block. This proposal has potential weaknesses, including centralization towards Chinese miners, the risk of network split without consensus, and the cost of reversing recent Bitcoin transactions. Despite these challenges, given the current political climate and public discussion on Bitcoin's energy use, it may be socially feasible to ask users and major exchanges to install a version of Bitcoin that implements this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Sum-of-the-keys-attack-on-taproot.xml b/static/bitcoin-dev/May_2021/combined_Sum-of-the-keys-attack-on-taproot.xml index 5dcacab0bb..2df16266ad 100644 --- a/static/bitcoin-dev/May_2021/combined_Sum-of-the-keys-attack-on-taproot.xml +++ b/static/bitcoin-dev/May_2021/combined_Sum-of-the-keys-attack-on-taproot.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Sum of the keys attack on taproot - 2023-08-02T03:52:03.303430+00:00 - - Ruben Somsen 2021-05-15 20:35:37+00:00 - - - Tim Ruffing 2021-05-15 20:25:23+00:00 - - - vjudeu 2021-05-15 10:21:00+00:00 - + 2025-09-26T15:54:20.589909+00:00 + python-feedgen + + + [bitcoin-dev] Sum of the keys attack on taproot vjudeu + 2021-05-15T10:21:00.000Z + + + Tim Ruffing + 2021-05-15T20:25:00.000Z + + + Ruben Somsen + 2021-05-15T20:35:00.000Z + + - python-feedgen + 2 Combined summary - Sum of the keys attack on taproot - 2023-08-02T03:52:03.303430+00:00 + 2025-09-26T15:54:20.590531+00:00 - On May 15, 2021, the bitcoin-dev mailing list saw a discussion about Taproot's ability to produce a signature matching the sum of public keys used in Taproot. Vjudeu initially suggested that this would be possible, but Tim Ruffing corrected this statement by asserting that Taproot does not enable cross-input aggregation or the ability to spend multiple UTXOs with a single signature.To further the discussion, Ruben recommended reading about MuSig, a key aggregation scheme that utilizes Schnorr signatures. The provided link directs to a Blockstream blog post that provides detailed information on MuSig.In the context of Taproot security, the scenario of Bob attempting to steal Alice's coins was discussed. Bob knows Alice's public key "a*G" and creates a taproot address "(b-a)*G" to receive a small amount of funds. Bob then crafts a transaction with two inputs, taking coins from both "a*G" and "(b-a)*G" addresses. He needs to produce a signature that matches the sum of the public keys used in taproot, which simplifies to "b*G". Bob uses his private key "b" to generate a Schnorr signature.However, there are potential protections against such attacks. One solution involves implementing a multisignature setup, requiring both Alice and Bob to sign off on any transactions. Another approach is to employ a timelock, enabling Alice to delay transactions for a certain period of time. Additionally, Alice can utilize coin control features to safeguard her coins from these types of attacks.It is crucial for users to be aware of these potential risks and take appropriate precautions to protect their assets when utilizing Taproot technology. 2021-05-15T20:35:37+00:00 + On May 15, 2021, the bitcoin-dev mailing list saw a discussion about Taproot's ability to produce a signature matching the sum of public keys used in Taproot. Vjudeu initially suggested that this would be possible, but Tim Ruffing corrected this statement by asserting that Taproot does not enable cross-input aggregation or the ability to spend multiple UTXOs with a single signature.To further the discussion, Ruben recommended reading about MuSig, a key aggregation scheme that utilizes Schnorr signatures. The provided link directs to a Blockstream blog post that provides detailed information on MuSig.In the context of Taproot security, the scenario of Bob attempting to steal Alice's coins was discussed. Bob knows Alice's public key "a*G" and creates a taproot address "(b-a)*G" to receive a small amount of funds. Bob then crafts a transaction with two inputs, taking coins from both "a*G" and "(b-a)*G" addresses. He needs to produce a signature that matches the sum of the public keys used in taproot, which simplifies to "b*G". Bob uses his private key "b" to generate a Schnorr signature.However, there are potential protections against such attacks. One solution involves implementing a multisignature setup, requiring both Alice and Bob to sign off on any transactions. Another approach is to employ a timelock, enabling Alice to delay transactions for a certain period of time. Additionally, Alice can utilize coin control features to safeguard her coins from these types of attacks.It is crucial for users to be aware of these potential risks and take appropriate precautions to protect their assets when utilizing Taproot technology. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_Tweaking-tapscript-instead-of-public-key.xml b/static/bitcoin-dev/May_2021/combined_Tweaking-tapscript-instead-of-public-key.xml index 1a2e225ba9..655d36d291 100644 --- a/static/bitcoin-dev/May_2021/combined_Tweaking-tapscript-instead-of-public-key.xml +++ b/static/bitcoin-dev/May_2021/combined_Tweaking-tapscript-instead-of-public-key.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Tweaking tapscript instead of public key - 2023-08-02T03:54:39.702426+00:00 - - Ruben Somsen 2021-05-23 17:58:13+00:00 - - - vjudeu 2021-05-23 16:02:45+00:00 - + 2025-09-26T15:54:16.356947+00:00 + python-feedgen + + + [bitcoin-dev] Tweaking tapscript instead of public key vjudeu + 2021-05-23T16:02:00.000Z + + + Ruben Somsen + 2021-05-23T17:58:00.000Z + + - python-feedgen + 2 Combined summary - Tweaking tapscript instead of public key - 2023-08-02T03:54:39.702426+00:00 + 2025-09-26T15:54:16.357436+00:00 - In a question posed on the Bitcoin-dev mailing list, the possibility of modifying a Taproot output without changing its address is discussed. The response clarifies that while a P2TR address contains a 32-byte public key that can be used for creating Schnorr signatures or revealing tapscript, changing the spending conditions would require a commitment to be made. Specifically, the Taproot equation Q = P + hash(P||m)*G is mentioned, where P is hashed together with the message to create a commitment. If the message is altered, a different commitment would be generated, thereby preventing modifications to the spending conditions without moving the on-chain coins.It is noted that a P2TR address encompasses a 32-byte public key, which can be directly used for generating Schnorr signatures or indirectly utilized by revealing tapscript. This prompts the question of whether it is possible to modify any taproot output after confirmation without altering the address. It is suggested that the owner could potentially make use of the base point private key associated with the P2TR address tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqqzj3dz to modify spending conditions without needing to move the on-chain coins.For further details and reference, the original Taproot thread is provided as a linked resource. 2021-05-23T17:58:13+00:00 + In a question posed on the Bitcoin-dev mailing list, the possibility of modifying a Taproot output without changing its address is discussed. The response clarifies that while a P2TR address contains a 32-byte public key that can be used for creating Schnorr signatures or revealing tapscript, changing the spending conditions would require a commitment to be made. Specifically, the Taproot equation Q = P + hash(P||m)*G is mentioned, where P is hashed together with the message to create a commitment. If the message is altered, a different commitment would be generated, thereby preventing modifications to the spending conditions without moving the on-chain coins.It is noted that a P2TR address encompasses a 32-byte public key, which can be directly used for generating Schnorr signatures or indirectly utilized by revealing tapscript. This prompts the question of whether it is possible to modify any taproot output after confirmation without altering the address. It is suggested that the owner could potentially make use of the base point private key associated with the P2TR address tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqqzj3dz to modify spending conditions without needing to move the on-chain coins.For further details and reference, the original Taproot thread is provided as a linked resource. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2021/combined_maximum-block-height-on-transaction.xml b/static/bitcoin-dev/May_2021/combined_maximum-block-height-on-transaction.xml index d300c5478c..baa0f989a5 100644 --- a/static/bitcoin-dev/May_2021/combined_maximum-block-height-on-transaction.xml +++ b/static/bitcoin-dev/May_2021/combined_maximum-block-height-on-transaction.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - maximum block height on transaction - 2023-08-02T03:34:07.044664+00:00 + 2025-09-26T15:53:53.196232+00:00 + python-feedgen ZmnSCPxj 2021-05-03 02:30:07+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - maximum block height on transaction - 2023-08-02T03:34:07.044664+00:00 + 2025-09-26T15:53:53.196376+00:00 - The email thread on the bitcoin-dev mailing list discusses the issue of increasing CPU usage and code complexity when adding a field or opcode to transactions. It proposes a solution involving a "hidden" field in a transaction with a default value compatible with pre-softfork rules, along with an opcode that manipulates this field. Additionally, the proposal suggests implementing a maximum block height on transactions using a new field and opcode. This functionality allows users to be safely offline at the time of timeout in any complicated timeout-based contract. However, it also increases risk for the contractor holding lien on the hashlock branch in a two-participant contract, making the proposal less significant improvement to Bitcoin.Satoshi's statement about the inability to safely implement OP_BLOCKNUMBER is brought up in the discussion. One user suggests that software could be written to warn users about edge cases, arguing that if a person waits for 6 blocks before accepting a transaction as confirmed, there should be no likely scenario where any finalized transaction needs to be reverted. They believe that any transaction with 5 or fewer confirmations should be considered fair game for reversal. The possibility of buggy software is not seen as a good reason to block an opcode. Another user suggests using two transactions, one with a desired expiry at H and another with nlocktime H, to accomplish the goal of a rough expiry. After a timeout, participants in the first transaction can cancel the action using the second transaction. However, limiting the maximum block height for a specific transaction would have the same problem as cited above for OP_BLOCKNUMBER. A third user asks if there is any way to specify a maximum block height on a transaction and considers it useful. The discussion emphasizes the risks and limitations of implementing OP_BLOCKNUMBER. It is noted that limiting the maximum block height for a specific transaction would face the same problem as OP_BLOCKNUMBER in the event of a blockchain reorganization. Instead, nTimeLock is suggested as an alternative solution. nTimeLock is an open transaction that can be replaced with new versions until the deadline. It could be used to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. While nTimeLock is not currently enabled or used, the support for its implementation is available.In response to the discussion, a user suggests accomplishing a rough goal by using tx A with a desired expiry at H and then using tx B with nlocktime H and creating outputs equivalent to inputs. After a timeout, participants in tx A can cancel the action using tx B. However, the effectiveness of this approach depends on the use case and further clarification is needed.The possibility of specifying a maximum block height on a transaction is raised during a discussion on the bitcoin-dev mailing list. However, it is pointed out that such a feature would encounter the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorganization. As an alternative, nTimeLock is suggested. This open transaction can be replaced with new versions until the deadline, and the highest version at the deadline is recorded. It can be utilized for escrow transactions that automatically lock and proceed unless revoked before the deadline. Although nTimeLock is not currently enabled or used, the necessary support exists for its future implementation.A user on the Bitcoin development mailing list inquires about the possibility of specifying a maximum block height for a transaction. However, it is noted that implementing such a feature would present the same issue as the OP_BLOCKNUMBER transaction, which becomes invalid during a blockchain reorganization. Instead, an alternative option called nTimeLock is proposed. nTimeLock allows for an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is then recorded. This feature could be used for escrow transactions that automatically lock and proceed unless revoked before the deadline. While nTimeLock is not currently enabled or used, the necessary support exists for its implementation in the future.The inquiry regarding the possibility of specifying a maximum block height on a transaction is raised by a user. However, it is pointed out that this feature would face the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorg. An alternative suggestion is made to use nTimeLock, which is an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is recorded. This feature could be useful for creating escrow transactions that automatically lock and go through unless revoked before the deadline. While nTimeLock is currently not enabled or used, the support for its implementation is available. In conclusion, the discussions on the bitcoin-dev mailing list revolve around the issue of increasing CPU usage and code complexity when adding fields or opcodes to transactions. Various suggestions and alternatives are proposed, such as using hidden fields, implementing a maximum block height, and utilizing nTimeLock. The limitations of implementing OP_BLOCKNUMBER and the potential risks associated with each solution are thoroughly examined. Ultimately, any modification to 2021-05-03T02:30:07+00:00 + The email thread on the bitcoin-dev mailing list discusses the issue of increasing CPU usage and code complexity when adding a field or opcode to transactions. It proposes a solution involving a "hidden" field in a transaction with a default value compatible with pre-softfork rules, along with an opcode that manipulates this field. Additionally, the proposal suggests implementing a maximum block height on transactions using a new field and opcode. This functionality allows users to be safely offline at the time of timeout in any complicated timeout-based contract. However, it also increases risk for the contractor holding lien on the hashlock branch in a two-participant contract, making the proposal less significant improvement to Bitcoin.Satoshi's statement about the inability to safely implement OP_BLOCKNUMBER is brought up in the discussion. One user suggests that software could be written to warn users about edge cases, arguing that if a person waits for 6 blocks before accepting a transaction as confirmed, there should be no likely scenario where any finalized transaction needs to be reverted. They believe that any transaction with 5 or fewer confirmations should be considered fair game for reversal. The possibility of buggy software is not seen as a good reason to block an opcode. Another user suggests using two transactions, one with a desired expiry at H and another with nlocktime H, to accomplish the goal of a rough expiry. After a timeout, participants in the first transaction can cancel the action using the second transaction. However, limiting the maximum block height for a specific transaction would have the same problem as cited above for OP_BLOCKNUMBER. A third user asks if there is any way to specify a maximum block height on a transaction and considers it useful. The discussion emphasizes the risks and limitations of implementing OP_BLOCKNUMBER. It is noted that limiting the maximum block height for a specific transaction would face the same problem as OP_BLOCKNUMBER in the event of a blockchain reorganization. Instead, nTimeLock is suggested as an alternative solution. nTimeLock is an open transaction that can be replaced with new versions until the deadline. It could be used to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. While nTimeLock is not currently enabled or used, the support for its implementation is available.In response to the discussion, a user suggests accomplishing a rough goal by using tx A with a desired expiry at H and then using tx B with nlocktime H and creating outputs equivalent to inputs. After a timeout, participants in tx A can cancel the action using tx B. However, the effectiveness of this approach depends on the use case and further clarification is needed.The possibility of specifying a maximum block height on a transaction is raised during a discussion on the bitcoin-dev mailing list. However, it is pointed out that such a feature would encounter the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorganization. As an alternative, nTimeLock is suggested. This open transaction can be replaced with new versions until the deadline, and the highest version at the deadline is recorded. It can be utilized for escrow transactions that automatically lock and proceed unless revoked before the deadline. Although nTimeLock is not currently enabled or used, the necessary support exists for its future implementation.A user on the Bitcoin development mailing list inquires about the possibility of specifying a maximum block height for a transaction. However, it is noted that implementing such a feature would present the same issue as the OP_BLOCKNUMBER transaction, which becomes invalid during a blockchain reorganization. Instead, an alternative option called nTimeLock is proposed. nTimeLock allows for an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is then recorded. This feature could be used for escrow transactions that automatically lock and proceed unless revoked before the deadline. While nTimeLock is not currently enabled or used, the necessary support exists for its implementation in the future.The inquiry regarding the possibility of specifying a maximum block height on a transaction is raised by a user. However, it is pointed out that this feature would face the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorg. An alternative suggestion is made to use nTimeLock, which is an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is recorded. This feature could be useful for creating escrow transactions that automatically lock and go through unless revoked before the deadline. While nTimeLock is currently not enabled or used, the support for its implementation is available. In conclusion, the discussions on the bitcoin-dev mailing list revolve around the issue of increasing CPU usage and code complexity when adding fields or opcodes to transactions. Various suggestions and alternatives are proposed, such as using hidden fields, implementing a maximum block height, and utilizing nTimeLock. The limitations of implementing OP_BLOCKNUMBER and the potential risks associated with each solution are thoroughly examined. Ultimately, any modification to - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml b/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml index b8e52e4a47..4fe0e34d72 100644 --- a/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml +++ b/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml @@ -2,7 +2,7 @@ 2 Combined summary - What to do when contentious soft fork activations are attempted - 2025-09-26T14:38:24.542058+00:00 + 2025-09-26T15:59:27.831598+00:00 python-feedgen Jorge Timón 2022-05-07 01:57:39+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - What to do when contentious soft fork activations are attempted - 2025-09-26T14:38:24.542201+00:00 + 2025-09-26T15:59:27.831763+00:00 2022-05-07T01:57:39+00:00 The email conversation between Jorge Timón and John Tromp on the Bitcoin-dev mailing list has sparked a discussion on irony. Timón accused Tromp of making personal attacks against Andreas Antonopoulos for his opinions on bip8. However, Tromp pointed out that Timón himself had made a personal attack by calling Jeremy ignorant about bip8. This led to a discussion on how ironic it is that people who base their arguments on personal attacks are also the ones who complain the most about personal attacks.In a separate discussion on the bitcoin-dev mailing list, Jorge Timón questioned a claim made by Russell O'Connor about the design of Speedy Trial (ST). Timón found the claim strange and stated that the grace period for slower activation after lock-in was added to address concerns raised by people who disliked the proposal. However, he still believed that speedy trial was a bad proposal due to incorrect analysis. O'Connor responded by quoting his own blog post where he clarified that the design of speedy trial was not based on any activation philosophy about failing fast.In another email exchange, Jorge Timón suggested that it is unnecessary to personally attack Andreas for his opinions. He argued that the only reason Jeremy Rubin does not like BIP8 is because he is ignorant about it and has not reviewed it enough. However, John Tromp pointed out the irony in equating 'clueless about BIP119' with a personal attack and then calling Jeremy ignorant about BIP8. The conversation seems to revolve around differences of opinion regarding different Bitcoin Improvement Proposals (BIPs).In a separate email thread, Ryan Grant defends the OP_CTV covenant proposal after Jorge Timón questioned Andreas' criticism. Ryan argues that OP_CTV covenants cannot restrict any address that the sender does not control and criticizes Andreas for not code-reviewing BIP119 or the pull request. Ryan believes that Andreas did not look into the reason why the proposed client was safe and would not cause a chain split. The conversation also references Russell O'Connor's explanation for how Speedy Trials arose in the consensus process and how it was designed.The email threads also touch upon the concept of covenants in Bitcoin and the contributions made by individuals towards it. There is a mention of Bip8 and the importance of being open-minded to understand its analysis. The discussions revolve around the need for education, avoiding personal attacks, addressing misinformation, and looking at technical details when discussing contentious soft forks and covenant proposals.Michael Folkson expresses his thoughts on the recent attempt to activate a contentious soft fork and questions what should be done differently if such attempts happen again. He believes that it is unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split and suggests there should be a personal cost to dissuade them from trying it again. Folkson acknowledges that Bitcoin is a permissionless network and no authority can stop such attempts, but hopes that people will actively resist and prevent the network from being fundamentally broken.Overall, the email exchanges and threads highlight discussions on irony, differences of opinion regarding Bitcoin Improvement Proposals, the design of Speedy Trial, criticism of covenant proposals, addressing misinformation, and the recent attempt to activate a contentious soft fork. The conversations emphasize the importance of education, avoiding personal attacks, and considering technical details when discussing contentious topics in the Bitcoin community. diff --git a/static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml b/static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml index 9f741e5ff0..96ed94e7c8 100644 --- a/static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml +++ b/static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP Proposal] Buried Deployments - 2023-08-01T19:13:27.524442+00:00 + 2025-09-26T15:53:38.413012+00:00 + python-feedgen Eric Voskuil 2016-11-17 10:10:30+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - [BIP Proposal] Buried Deployments - 2023-08-01T19:13:27.525439+00:00 + 2025-09-26T15:53:38.413204+00:00 - In a recent email exchange, bitcoin developers Pieter Wuille and Eric Voskuil discussed the use of checkpoints in the blockchain. Checkpoints have been used as a way to prevent attacks, but Wuille argues that they are not necessary and can be removed. He suggests that users validate the full chain without checkpoints and select their own checkpoints instead.Voskuil expresses concern that this could lead to centralization of control over the "true chain", but Wuille counters that developers already have this power and good review and release practices can mitigate the risk.The conversation also touches on buried softforks, which modify the validity of a theoretically construable chain from invalid to valid. Wuille believes that avoiding certain checks for BIP34 and BIP66 could improve performance optimization, but Voskuil disagrees and sees no benefit in this approach.Another topic of discussion is the comparison between BIP30 and BIP34. Voskuil clarifies that duplicate transaction hashes can still occur in Bitcoin even with the activation of BIP34, and that BIP30 is not validated after BIP34 is active because blocks complying with BIP34 will always comply with BIP30.The email exchange also involves a discussion about a recent change in Bitcoin Core regarding the deployment of BIPs 34, 66, and 65. The change replaces the trigger mechanism with cached block heights, simplifying and optimizing the process. Voskuil initially opposes the change, but others argue that it doesn't represent a performance improvement and merely cements attributes of the blockchain's history. There is also mention of BIP30 and BIP50, which were given similar treatment after a reasonable amount of time had passed.In addition, there are discussions about reducing code complexity, defining maximum depth of reorganization, and the definition of "BIP" itself. The conversation provides different perspectives on these topics, with some arguing for the elimination of checkpoints and others highlighting potential issues and complexities.Bitcoin Core has recently merged a simplification to the consensus rules surrounding the deployment of BIPs 34, 66, and 65. This change replaces the trigger mechanism for prior soft forks by caching the block heights at which those consensus rules became enforced. The purpose of this change is to simplify and optimize the trigger mechanism. However, this proposal has been met with criticism from Eric Voskuil, who calls it a "horrible precedent" and argues that it is not a significant performance optimization. Despite the debate, the change has already been merged into Bitcoin Core.The change is considered a minor one, but the rationale behind it has been documented in a BIP for posterity. Prior soft forks were activated via miner signaling in block version numbers. Now, with the chain having passed the blocks where those consensus rules were triggered, caching the block heights at which those rules were enforced is seen as a more efficient solution. This change solidifies certain attributes of the blockchain's history that are not disputed. It is widely agreed upon that BIP34 was activated at block 227931, BIP65 at block 388381, and BIP66 at block 363725. While this change does not provide justification for the consensus rule change, it ensures that any reorganization that disconnects the activating block will raise concerns about the security assumptions of Bitcoin.Despite potential concerns about a consensus split, the change is not expected to cause fundamental security concerns in Bitcoin. The proposal suggests that including at least one checkpoint to directly verify that no 50k reorganizations will occur would make the change a soft fork instead of a hard fork. Chains that do not go through the checkpoint would be rejected, but no new chains would be allowed. The purpose of the checkpoint is to validate the assumption that no such large reorganizations will happen. However, many people still want to verify the legacy chain. This checkpointing process would only be necessary during the headers-first part of the download.The simplified consensus rules have not yet appeared in any released software but are expected to be included in the next release, 0.14.0. Despite concerns raised about the performance optimization and the process followed for this change, the developer responsible has agreed to modify the BIP draft to de-emphasize the performance aspect. The full draft of the BIP can be found on GitHub.In summary, Bitcoin Core has merged a simplification to the consensus rules surrounding the deployment of certain BIPs. This change replaces the trigger mechanism for prior soft forks by caching the block heights at which those rules were enforced. While there has been criticism regarding this change, it has already been merged into Bitcoin Core. The purpose of this change is to simplify and optimize the trigger mechanism, although concerns have been raised about its performance optimization and the process followed. The full draft of the BIP can be found on GitHub, and the change is expected to be included in the next software release. 2016-11-17T10:10:30+00:00 + In a recent email exchange, bitcoin developers Pieter Wuille and Eric Voskuil discussed the use of checkpoints in the blockchain. Checkpoints have been used as a way to prevent attacks, but Wuille argues that they are not necessary and can be removed. He suggests that users validate the full chain without checkpoints and select their own checkpoints instead.Voskuil expresses concern that this could lead to centralization of control over the "true chain", but Wuille counters that developers already have this power and good review and release practices can mitigate the risk.The conversation also touches on buried softforks, which modify the validity of a theoretically construable chain from invalid to valid. Wuille believes that avoiding certain checks for BIP34 and BIP66 could improve performance optimization, but Voskuil disagrees and sees no benefit in this approach.Another topic of discussion is the comparison between BIP30 and BIP34. Voskuil clarifies that duplicate transaction hashes can still occur in Bitcoin even with the activation of BIP34, and that BIP30 is not validated after BIP34 is active because blocks complying with BIP34 will always comply with BIP30.The email exchange also involves a discussion about a recent change in Bitcoin Core regarding the deployment of BIPs 34, 66, and 65. The change replaces the trigger mechanism with cached block heights, simplifying and optimizing the process. Voskuil initially opposes the change, but others argue that it doesn't represent a performance improvement and merely cements attributes of the blockchain's history. There is also mention of BIP30 and BIP50, which were given similar treatment after a reasonable amount of time had passed.In addition, there are discussions about reducing code complexity, defining maximum depth of reorganization, and the definition of "BIP" itself. The conversation provides different perspectives on these topics, with some arguing for the elimination of checkpoints and others highlighting potential issues and complexities.Bitcoin Core has recently merged a simplification to the consensus rules surrounding the deployment of BIPs 34, 66, and 65. This change replaces the trigger mechanism for prior soft forks by caching the block heights at which those consensus rules became enforced. The purpose of this change is to simplify and optimize the trigger mechanism. However, this proposal has been met with criticism from Eric Voskuil, who calls it a "horrible precedent" and argues that it is not a significant performance optimization. Despite the debate, the change has already been merged into Bitcoin Core.The change is considered a minor one, but the rationale behind it has been documented in a BIP for posterity. Prior soft forks were activated via miner signaling in block version numbers. Now, with the chain having passed the blocks where those consensus rules were triggered, caching the block heights at which those rules were enforced is seen as a more efficient solution. This change solidifies certain attributes of the blockchain's history that are not disputed. It is widely agreed upon that BIP34 was activated at block 227931, BIP65 at block 388381, and BIP66 at block 363725. While this change does not provide justification for the consensus rule change, it ensures that any reorganization that disconnects the activating block will raise concerns about the security assumptions of Bitcoin.Despite potential concerns about a consensus split, the change is not expected to cause fundamental security concerns in Bitcoin. The proposal suggests that including at least one checkpoint to directly verify that no 50k reorganizations will occur would make the change a soft fork instead of a hard fork. Chains that do not go through the checkpoint would be rejected, but no new chains would be allowed. The purpose of the checkpoint is to validate the assumption that no such large reorganizations will happen. However, many people still want to verify the legacy chain. This checkpointing process would only be necessary during the headers-first part of the download.The simplified consensus rules have not yet appeared in any released software but are expected to be included in the next release, 0.14.0. Despite concerns raised about the performance optimization and the process followed for this change, the developer responsible has agreed to modify the BIP draft to de-emphasize the performance aspect. The full draft of the BIP can be found on GitHub.In summary, Bitcoin Core has merged a simplification to the consensus rules surrounding the deployment of certain BIPs. This change replaces the trigger mechanism for prior soft forks by caching the block heights at which those rules were enforced. While there has been criticism regarding this change, it has already been merged into Bitcoin Core. The purpose of this change is to simplify and optimize the trigger mechanism, although concerns have been raised about its performance optimization and the process followed. The full draft of the BIP can be found on GitHub, and the change is expected to be included in the next software release. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2016/combined_BIP-idea-Standardised-p2sh-bitcoin-addresses-requiring-an-arbitrary-and-or-combination-of-keys.xml b/static/bitcoin-dev/Nov_2016/combined_BIP-idea-Standardised-p2sh-bitcoin-addresses-requiring-an-arbitrary-and-or-combination-of-keys.xml index 6992de4811..b5505d1906 100644 --- a/static/bitcoin-dev/Nov_2016/combined_BIP-idea-Standardised-p2sh-bitcoin-addresses-requiring-an-arbitrary-and-or-combination-of-keys.xml +++ b/static/bitcoin-dev/Nov_2016/combined_BIP-idea-Standardised-p2sh-bitcoin-addresses-requiring-an-arbitrary-and-or-combination-of-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP idea: Standardised p2sh bitcoin addresses requiring an arbitrary and/or combination of keys - 2023-08-01T19:15:32.653219+00:00 + 2025-09-26T15:53:36.303097+00:00 + python-feedgen Edmund Edgar 2016-11-30 00:00:43+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP idea: Standardised p2sh bitcoin addresses requiring an arbitrary and/or combination of keys - 2023-08-01T19:15:32.653219+00:00 + 2025-09-26T15:53:36.303285+00:00 - Erland Lewin has proposed a method to create "Boolean addresses" that can be redeemed by a set of keys and multi-signatures combined with logical and/or operations. The aim of this proposal is to standardize these addresses, allowing for interoperability among wallet software. By implementing a consistent way to generate a P2SH script from a given boolean address tree, wallet authors can create, sign, and share signature requests for these addresses.A Boolean address is described as a tree structure, starting at a root node. The nodes within the tree can be an "and" operation, an "or" operation, a public key, a multisig operation n-of-m with a list of public keys, or a CHECKLOCKTIMEVERIFY operation. This proposal provides flexibility for various scenarios. For example, corporations can utilize this proposal to allow signatures by "A or (2 of 4 of B, C, D, E)," enabling spending by either the CEO or board members with their respective keys.Additionally, individuals like Alice can redeem her address in case of key loss or compromise. She can set up her address as "A or (B and 1-of-3 of C, D, E)." This means that if Alice loses her key or if her cloud wallet key is compromised, she can still access her funds using a combination of keys C, D, or E.The implementation of this proposal will establish a well-defined process for generating a P2SH script based on a given boolean address tree. It will also outline how spending transactions are to be signed. Reality Keys, a platform that verifies information against real-world events, recognizes the value of this proposal in addressing pain points and suggests that its adoption by wallet authors would be beneficial. Edmund Edgar, founder of Social Minds Inc (KK), supports the proposal's sensible implementation.In conclusion, Erland Lewin's proposal offers a consistent method for creating Boolean addresses that can be redeemed by a combination of keys and multi-signatures using logical and/or operations. Its implementation will ensure standardized interoperability among wallet software while providing clear guidelines for generating P2SH scripts and signing spending transactions. 2016-11-30T00:00:43+00:00 + Erland Lewin has proposed a method to create "Boolean addresses" that can be redeemed by a set of keys and multi-signatures combined with logical and/or operations. The aim of this proposal is to standardize these addresses, allowing for interoperability among wallet software. By implementing a consistent way to generate a P2SH script from a given boolean address tree, wallet authors can create, sign, and share signature requests for these addresses.A Boolean address is described as a tree structure, starting at a root node. The nodes within the tree can be an "and" operation, an "or" operation, a public key, a multisig operation n-of-m with a list of public keys, or a CHECKLOCKTIMEVERIFY operation. This proposal provides flexibility for various scenarios. For example, corporations can utilize this proposal to allow signatures by "A or (2 of 4 of B, C, D, E)," enabling spending by either the CEO or board members with their respective keys.Additionally, individuals like Alice can redeem her address in case of key loss or compromise. She can set up her address as "A or (B and 1-of-3 of C, D, E)." This means that if Alice loses her key or if her cloud wallet key is compromised, she can still access her funds using a combination of keys C, D, or E.The implementation of this proposal will establish a well-defined process for generating a P2SH script based on a given boolean address tree. It will also outline how spending transactions are to be signed. Reality Keys, a platform that verifies information against real-world events, recognizes the value of this proposal in addressing pain points and suggests that its adoption by wallet authors would be beneficial. Edmund Edgar, founder of Social Minds Inc (KK), supports the proposal's sensible implementation.In conclusion, Erland Lewin's proposal offers a consistent method for creating Boolean addresses that can be redeemed by a combination of keys and multi-signatures using logical and/or operations. Its implementation will ensure standardized interoperability among wallet software while providing clear guidelines for generating P2SH scripts and signing spending transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2016/combined_BIP30-and-BIP34-interaction-was-Re-BIP-Proposal-Buried-Deployments-.xml b/static/bitcoin-dev/Nov_2016/combined_BIP30-and-BIP34-interaction-was-Re-BIP-Proposal-Buried-Deployments-.xml index 9ce4334060..f611832709 100644 --- a/static/bitcoin-dev/Nov_2016/combined_BIP30-and-BIP34-interaction-was-Re-BIP-Proposal-Buried-Deployments-.xml +++ b/static/bitcoin-dev/Nov_2016/combined_BIP30-and-BIP34-interaction-was-Re-BIP-Proposal-Buried-Deployments-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments) - 2023-08-01T19:14:30.939869+00:00 + 2025-09-26T15:53:42.644360+00:00 + python-feedgen Eric Voskuil 2016-11-18 16:47:09+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments) - 2023-08-01T19:14:30.939869+00:00 + 2025-09-26T15:53:42.644558+00:00 - In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the possibility of transaction hash collisions and their potential impact on the Bitcoin network. While it is unlikely that such collisions will occur due to the strength of SHA256, there is still a small chance that they could happen. BIP30 allows for fully-spent transactions to be duplicated for pruning purposes, but this means that there could be duplicated transaction IDs (txids) in the future. BIP34 aims to enforce block and transaction uniqueness, but does not explicitly reject collisions by consensus. To address this issue, a suggestion is made to draft a new BIP, but it is noted that doing so would make it impossible to guard against chain splits caused by pruning.Peter Todd responds to these concerns, stating that the likelihood of a transaction hash collision is highly unlikely, as SHA256 is currently a secure algorithm with infeasible brute-force attacks against 256-bit keys. He emphasizes that if SHA256 were to become weak, Bitcoin would be fundamentally broken, as miners would be able to generate blocks with collisions in transactions and merkle trees, leading to multiple contradictory transaction histories. Todd cites Bruce Schneier's statement that brute-force attacks against 256-bit keys will remain infeasible until computers are built from something other than matter and occupy something other than space.Eric Voskuil explains in another discussion that banning duplicate transaction hashes outright is not feasible, as it would require spent transaction hashes to be retained forever, contradicting the concept of pruning nodes. Additionally, implementing such a ban would result in a chain split and a hard fork. While BIP34 prevents exact duplicate transactions, different transactions can still have the same hash if their parents are identical. However, as long as the hash function remains secure, future transactions are guaranteed to have unique txids.Tier Nolan adds that as long as there is no hash function break, the rules guarantee that all future transactions will have different txids. However, Eric Voskuil points out that if there is an address collision, someone may lose money, while a tx hash collision handled differently by implementations could lead to a chain split. It is emphasized that nodes cannot dismiss this possibility and must remain vigilant. Nolan explains that the only way for two transactions to have the same txid is if their parents are identical, as txids of parents are included in a transaction. While coinbases used to allow for the possibility of identical transactions, exceptions were made because duplicate outputs were not possible in the database. All new coinbases will have unique hashes, ensuring that all future transactions will have different txids.In regards to BIP30, it is clarified that it prevents duplicate transaction hashes only when a new transaction hash duplicates that of a preceding transaction with unspent outputs. On the other hand, BIP34 does not prevent duplicate transaction hashes from different transactions. Two cases of duplicate transaction hashes have already occurred, one of which was exempted from validation because it had become buried in the chain, while the other complied with the BIP30 rule due to its predecessor being spent. BIP34 now precludes exact duplicate transactions. The collision of regular transactions is highly unlikely due to inputs and usage of entropy, but coinbase transactions, which do not have inputs, present a worrying case. BIP30 introduces committed height to prevent collisions on coinbase transactions.Overall, while the likelihood of transaction hash collisions is low, precautions must be taken to ensure the integrity of the Bitcoin network. The discussions highlight the importance of maintaining a secure hash function and implementing measures such as BIP30 and BIP34 to prevent collisions and chain splits. 2016-11-18T16:47:09+00:00 + In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the possibility of transaction hash collisions and their potential impact on the Bitcoin network. While it is unlikely that such collisions will occur due to the strength of SHA256, there is still a small chance that they could happen. BIP30 allows for fully-spent transactions to be duplicated for pruning purposes, but this means that there could be duplicated transaction IDs (txids) in the future. BIP34 aims to enforce block and transaction uniqueness, but does not explicitly reject collisions by consensus. To address this issue, a suggestion is made to draft a new BIP, but it is noted that doing so would make it impossible to guard against chain splits caused by pruning.Peter Todd responds to these concerns, stating that the likelihood of a transaction hash collision is highly unlikely, as SHA256 is currently a secure algorithm with infeasible brute-force attacks against 256-bit keys. He emphasizes that if SHA256 were to become weak, Bitcoin would be fundamentally broken, as miners would be able to generate blocks with collisions in transactions and merkle trees, leading to multiple contradictory transaction histories. Todd cites Bruce Schneier's statement that brute-force attacks against 256-bit keys will remain infeasible until computers are built from something other than matter and occupy something other than space.Eric Voskuil explains in another discussion that banning duplicate transaction hashes outright is not feasible, as it would require spent transaction hashes to be retained forever, contradicting the concept of pruning nodes. Additionally, implementing such a ban would result in a chain split and a hard fork. While BIP34 prevents exact duplicate transactions, different transactions can still have the same hash if their parents are identical. However, as long as the hash function remains secure, future transactions are guaranteed to have unique txids.Tier Nolan adds that as long as there is no hash function break, the rules guarantee that all future transactions will have different txids. However, Eric Voskuil points out that if there is an address collision, someone may lose money, while a tx hash collision handled differently by implementations could lead to a chain split. It is emphasized that nodes cannot dismiss this possibility and must remain vigilant. Nolan explains that the only way for two transactions to have the same txid is if their parents are identical, as txids of parents are included in a transaction. While coinbases used to allow for the possibility of identical transactions, exceptions were made because duplicate outputs were not possible in the database. All new coinbases will have unique hashes, ensuring that all future transactions will have different txids.In regards to BIP30, it is clarified that it prevents duplicate transaction hashes only when a new transaction hash duplicates that of a preceding transaction with unspent outputs. On the other hand, BIP34 does not prevent duplicate transaction hashes from different transactions. Two cases of duplicate transaction hashes have already occurred, one of which was exempted from validation because it had become buried in the chain, while the other complied with the BIP30 rule due to its predecessor being spent. BIP34 now precludes exact duplicate transactions. The collision of regular transactions is highly unlikely due to inputs and usage of entropy, but coinbase transactions, which do not have inputs, present a worrying case. BIP30 introduces committed height to prevent collisions on coinbase transactions.Overall, while the likelihood of transaction hash collisions is low, precautions must be taken to ensure the integrity of the Bitcoin network. The discussions highlight the importance of maintaining a secure hash function and implementing measures such as BIP30 and BIP34 to prevent collisions and chain splits. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2016/combined_Flexible-Transactions-.xml b/static/bitcoin-dev/Nov_2016/combined_Flexible-Transactions-.xml index 20d9ff0861..28e2c202a1 100644 --- a/static/bitcoin-dev/Nov_2016/combined_Flexible-Transactions-.xml +++ b/static/bitcoin-dev/Nov_2016/combined_Flexible-Transactions-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Flexible Transactions. - 2023-08-01T19:14:50.325199+00:00 + 2025-09-26T15:53:46.873936+00:00 + python-feedgen Russell O'Connor 2016-11-21 21:29:21+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Flexible Transactions. - 2023-08-01T19:14:50.325199+00:00 + 2025-09-26T15:53:46.874084+00:00 - In response to an email from Russell, Tom Zander from the bitcoin-dev mailing list expressed gratitude for his review but mentioned that the issue raised had already been resolved some time ago. It was revealed that Tom had waited for six weeks before sending the email. Russell expressed satisfaction with the solution and looked forward to seeing BIP 134 updated accordingly. On 21 November 2016, Russell O'Connor expressed concern about Tom's proposal to change the semantics of OP_CHECKSIG in version 2 of 'script', deeming it too naive. Tom had previously explained that in version 2, the data signed would be equivalent to the transaction-id, simplifying the process. However, Tom responded to Russell's email stating that the issue had already been fixed and thanked him for the review after the six-week wait. Tom also provided links to his blog and vlog.The proposal to change the semantics of OP_CHECKSIG in version 2 of script suggested altering the signed data to align with the transaction-id, streamlining the process. However, critics argue that this proposal is overly simplistic. They explain that the SIGHASH data utilized in both Bitcoin script and Segwit script contains information indicating which input is being signed. By signing only the transaction id, the proposed signature fails to include the data specifying which input of the transaction is being signed. Consequently, if different inputs share the same public key due to key reuse, the signatures on those inputs will be identical. Additionally, the Flexible Transactions proposal introduces a new vulnerability to Bitcoin that currently does not exist.An example is given to illustrate this flaw, where two individuals jointly prepare a transaction with one input from each person. If one individual deceives the other by using the outpoint from the other person's transaction, which has the same public key as their chosen input, they can duplicate the signature provided by the other person and fund both inputs for the "jointly" funded purchase. This flaw is considered to be on par with transaction malleability, which is already being addressed. Therefore, caution and vigilance are necessary to avoid this trap, requiring unexpected work. It is advised not to expose Bitcoin to this line of attack. Consequently, it is crucial to thoroughly comprehend the reasons behind existing processes before proposing changes. 2016-11-21T21:29:21+00:00 + In response to an email from Russell, Tom Zander from the bitcoin-dev mailing list expressed gratitude for his review but mentioned that the issue raised had already been resolved some time ago. It was revealed that Tom had waited for six weeks before sending the email. Russell expressed satisfaction with the solution and looked forward to seeing BIP 134 updated accordingly. On 21 November 2016, Russell O'Connor expressed concern about Tom's proposal to change the semantics of OP_CHECKSIG in version 2 of 'script', deeming it too naive. Tom had previously explained that in version 2, the data signed would be equivalent to the transaction-id, simplifying the process. However, Tom responded to Russell's email stating that the issue had already been fixed and thanked him for the review after the six-week wait. Tom also provided links to his blog and vlog.The proposal to change the semantics of OP_CHECKSIG in version 2 of script suggested altering the signed data to align with the transaction-id, streamlining the process. However, critics argue that this proposal is overly simplistic. They explain that the SIGHASH data utilized in both Bitcoin script and Segwit script contains information indicating which input is being signed. By signing only the transaction id, the proposed signature fails to include the data specifying which input of the transaction is being signed. Consequently, if different inputs share the same public key due to key reuse, the signatures on those inputs will be identical. Additionally, the Flexible Transactions proposal introduces a new vulnerability to Bitcoin that currently does not exist.An example is given to illustrate this flaw, where two individuals jointly prepare a transaction with one input from each person. If one individual deceives the other by using the outpoint from the other person's transaction, which has the same public key as their chosen input, they can duplicate the signature provided by the other person and fund both inputs for the "jointly" funded purchase. This flaw is considered to be on par with transaction malleability, which is already being addressed. Therefore, caution and vigilance are necessary to avoid this trap, requiring unexpected work. It is advised not to expose Bitcoin to this line of attack. Consequently, it is crucial to thoroughly comprehend the reasons behind existing processes before proposing changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2016/combined_Implementing-Covenants-with-OP-CHECKSIGFROMSTACKVERIFY.xml b/static/bitcoin-dev/Nov_2016/combined_Implementing-Covenants-with-OP-CHECKSIGFROMSTACKVERIFY.xml index 9aca15839e..7e1a1047b7 100644 --- a/static/bitcoin-dev/Nov_2016/combined_Implementing-Covenants-with-OP-CHECKSIGFROMSTACKVERIFY.xml +++ b/static/bitcoin-dev/Nov_2016/combined_Implementing-Covenants-with-OP-CHECKSIGFROMSTACKVERIFY.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY - 2023-08-01T19:12:07.382820+00:00 + 2025-09-26T15:53:44.757276+00:00 + python-feedgen Jeremy 2016-11-07 19:30:26+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY - 2023-08-01T19:12:07.383831+00:00 + 2025-09-26T15:53:44.757415+00:00 - Russell O'Connor has provided a detailed explanation on how to implement covenants using the OP_CAT and OP_CHECKSIGFROMSTACKVERIFY op codes in the Elements Alpha sidechain. These op codes allow for the construction of covenants in Elements Alpha currently. O'Connor has also demonstrated the construction of the Moeser-Eyal-Sirer vault as an example. The implementation involves creating an output that can be spent by anyone if it is double-spent with two different transactions. This is achieved by adding a case to the script that allows spending when two valid signatures on different messages under the public key of the output are given.The "opt-in miner takes double-spend" functionality can be implemented using either OP_CAT or OP_CHECKSIGFROMSTACKVERIFY. By creating an output that is spendable by everyone if it is double-spent, the next miner who mines the double-spent transaction will receive all the money. The recipient can accept zero-conf transactions, knowing that the sender will lose the money upon attempting to double-spend. In the case of OP_CHECKSIGFROMSTACKVERIFY, spending is allowed if two valid signatures on different messages under the public key of the output are provided. OP_CAT offers a simpler way to achieve the same functionality by converting Bitcoin's ECDSA into an opt-in one-time signature scheme.During the discussion on the bitcoin-dev mailing list, Daniel Robinson and Russell O'Connor explored the possibility of implementing "poison transactions" using OP_CHECKSIGFROMSTACKVERIFY. O'Connor mentioned that while he had not extensively studied poison transactions, adding transaction introspection operations could save a significant amount of work as the transaction data is easily recoverable. Although there are no immediate plans to include transaction introspection opcodes in Elements, it remains a possibility in the future.Johnson Lau also joined the conversation, sharing his alternative implementation of OP_CHECKSIGFROMSTACKVERIFY. Instead of hashing the data on stack, he directly puts the 32 byte hash onto the stack. Lau believes that this approach offers more flexibility as not all systems use double-SHA256.The discussion prompted Russell O'Connor to encourage the collection and implementation of other useful covenants. A business case example was presented, demonstrating the usage of multisig with an oracle determination to protect against renegotiation or unforeseen circumstances. The terms of the transaction included a CLTV lasting several years, and both parties could mutually select and sign one of the payout distributions for early exit. The desired features were the ability for one party to sell their participation before the CLTV becomes valid and the mutual revocation of rogue oracle-entities without affecting other terms.Overall, the implementation of covenants using OP_CAT and OP_CHECKSIGFROMSTACKVERIFY in the Elements Alpha sidechain has been detailed by Russell O'Connor. The construction process is already available and can be used to create various types of covenants. Johnson Lau has also provided an alternative implementation of OP_CHECKSIGFROMSTACKVERIFY. O'Connor welcomes suggestions for implementing other useful covenants and encourages the community to share their ideas. 2016-11-07T19:30:26+00:00 + Russell O'Connor has provided a detailed explanation on how to implement covenants using the OP_CAT and OP_CHECKSIGFROMSTACKVERIFY op codes in the Elements Alpha sidechain. These op codes allow for the construction of covenants in Elements Alpha currently. O'Connor has also demonstrated the construction of the Moeser-Eyal-Sirer vault as an example. The implementation involves creating an output that can be spent by anyone if it is double-spent with two different transactions. This is achieved by adding a case to the script that allows spending when two valid signatures on different messages under the public key of the output are given.The "opt-in miner takes double-spend" functionality can be implemented using either OP_CAT or OP_CHECKSIGFROMSTACKVERIFY. By creating an output that is spendable by everyone if it is double-spent, the next miner who mines the double-spent transaction will receive all the money. The recipient can accept zero-conf transactions, knowing that the sender will lose the money upon attempting to double-spend. In the case of OP_CHECKSIGFROMSTACKVERIFY, spending is allowed if two valid signatures on different messages under the public key of the output are provided. OP_CAT offers a simpler way to achieve the same functionality by converting Bitcoin's ECDSA into an opt-in one-time signature scheme.During the discussion on the bitcoin-dev mailing list, Daniel Robinson and Russell O'Connor explored the possibility of implementing "poison transactions" using OP_CHECKSIGFROMSTACKVERIFY. O'Connor mentioned that while he had not extensively studied poison transactions, adding transaction introspection operations could save a significant amount of work as the transaction data is easily recoverable. Although there are no immediate plans to include transaction introspection opcodes in Elements, it remains a possibility in the future.Johnson Lau also joined the conversation, sharing his alternative implementation of OP_CHECKSIGFROMSTACKVERIFY. Instead of hashing the data on stack, he directly puts the 32 byte hash onto the stack. Lau believes that this approach offers more flexibility as not all systems use double-SHA256.The discussion prompted Russell O'Connor to encourage the collection and implementation of other useful covenants. A business case example was presented, demonstrating the usage of multisig with an oracle determination to protect against renegotiation or unforeseen circumstances. The terms of the transaction included a CLTV lasting several years, and both parties could mutually select and sign one of the payout distributions for early exit. The desired features were the ability for one party to sell their participation before the CLTV becomes valid and the mutual revocation of rogue oracle-entities without affecting other terms.Overall, the implementation of covenants using OP_CAT and OP_CHECKSIGFROMSTACKVERIFY in the Elements Alpha sidechain has been detailed by Russell O'Connor. The construction process is already available and can be used to create various types of covenants. Johnson Lau has also provided an alternative implementation of OP_CHECKSIGFROMSTACKVERIFY. O'Connor welcomes suggestions for implementing other useful covenants and encourages the community to share their ideas. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2016/combined_The-Excessive-Block-Gate-How-a-Bitcoin-Unlimited-Node-Deals-With-Large-Blocks.xml b/static/bitcoin-dev/Nov_2016/combined_The-Excessive-Block-Gate-How-a-Bitcoin-Unlimited-Node-Deals-With-Large-Blocks.xml index 148d86d9c8..27ea209e53 100644 --- a/static/bitcoin-dev/Nov_2016/combined_The-Excessive-Block-Gate-How-a-Bitcoin-Unlimited-Node-Deals-With-Large-Blocks.xml +++ b/static/bitcoin-dev/Nov_2016/combined_The-Excessive-Block-Gate-How-a-Bitcoin-Unlimited-Node-Deals-With-Large-Blocks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks - 2023-08-01T19:15:13.163617+00:00 + 2025-09-26T15:53:40.530838+00:00 + python-feedgen Tom Zander 2016-11-27 07:47:00+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks - 2023-08-01T19:15:13.163617+00:00 + 2025-09-26T15:53:40.531011+00:00 - On November 26, 2016, Peter R via bitcoin-dev suggested that miners should set the same block size limit and signal it reliably, similar to what Bitcoin Unlimited (BU) miners do. This concept was recently implemented in Classic, which will now respect the EB limit and put it in the coinbase. Tom Zander mentioned that there may be a significant difference in cost versus expected earnings of creating a block. Sergio and Tom discussed how miners setting their block size limits above or below the "effective BSL" can disadvantage them. The conversation also highlighted that it is in the best interest of miners to all set the same block size limit and signal it reliably in their coinbase TX.Sergio Demian Lerner wrote an email expressing concern about the false premise of his reasoning and conclusions about BU block size policies for miners. He believes that all miners need to follow the same block size policy to prevent short forks. The conversation between Sergio and Tom emphasized the importance of miners announcing and following the same block size policy to prevent short forks. They also discussed the possibility of improvements to be made to the policy that BU uses.Bitcoin developers are discussing the possibility of unlimited block size in the Bitcoin Core implementation of the consensus protocol. Sergio expressed concern about the riskiness of this change without detailed analysis. Tom responded that he did not see it as a change, but rather miners would simply choose a rule that maximizes their revenue. The concept of proof-of-work was discussed, highlighting that the longer a chain, the higher the probability that it will be extended. The issue of having a 3 or 4 deep fork was acknowledged as a problem in Bitcoin, but it hasn't happened for ages and miners prefer it that way.The email conversation between Sergio and Peter focused on the acceptance of payment in BU when the gate policy of 51% miners is not known. Sergio suggested that miners should advertise their gate block size and acceptance depth in their coinbase field to provide clarity. Peter responded by providing a link to an article that explains how Bitcoin Unlimited's excessive-block logic works from the perspective of a single node. He also mentioned that BU's market-based solution to the block-size limit is gaining support and hopes to write a follow-up article describing how this behavior facilitates the emergence of a fluid and organic block size limit at the network scale.In summary, the discussions revolve around miners setting the same block size limit, preventing short forks, the concept of proof-of-work, the possibility of unlimited block size, and the workings of Bitcoin Unlimited. The conversation also explores the idea of miners advertising their gate block size and acceptance depth, and the potential improvements to be made to BU's policy. 2016-11-27T07:47:00+00:00 + On November 26, 2016, Peter R via bitcoin-dev suggested that miners should set the same block size limit and signal it reliably, similar to what Bitcoin Unlimited (BU) miners do. This concept was recently implemented in Classic, which will now respect the EB limit and put it in the coinbase. Tom Zander mentioned that there may be a significant difference in cost versus expected earnings of creating a block. Sergio and Tom discussed how miners setting their block size limits above or below the "effective BSL" can disadvantage them. The conversation also highlighted that it is in the best interest of miners to all set the same block size limit and signal it reliably in their coinbase TX.Sergio Demian Lerner wrote an email expressing concern about the false premise of his reasoning and conclusions about BU block size policies for miners. He believes that all miners need to follow the same block size policy to prevent short forks. The conversation between Sergio and Tom emphasized the importance of miners announcing and following the same block size policy to prevent short forks. They also discussed the possibility of improvements to be made to the policy that BU uses.Bitcoin developers are discussing the possibility of unlimited block size in the Bitcoin Core implementation of the consensus protocol. Sergio expressed concern about the riskiness of this change without detailed analysis. Tom responded that he did not see it as a change, but rather miners would simply choose a rule that maximizes their revenue. The concept of proof-of-work was discussed, highlighting that the longer a chain, the higher the probability that it will be extended. The issue of having a 3 or 4 deep fork was acknowledged as a problem in Bitcoin, but it hasn't happened for ages and miners prefer it that way.The email conversation between Sergio and Peter focused on the acceptance of payment in BU when the gate policy of 51% miners is not known. Sergio suggested that miners should advertise their gate block size and acceptance depth in their coinbase field to provide clarity. Peter responded by providing a link to an article that explains how Bitcoin Unlimited's excessive-block logic works from the perspective of a single node. He also mentioned that BU's market-based solution to the block-size limit is gaining support and hopes to write a follow-up article describing how this behavior facilitates the emergence of a fluid and organic block size limit at the network scale.In summary, the discussions revolve around miners setting the same block size limit, preventing short forks, the concept of proof-of-work, the possibility of unlimited block size, and the workings of Bitcoin Unlimited. The conversation also explores the idea of miners advertising their gate block size and acceptance depth, and the potential improvements to be made to BU's policy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_A-DNS-like-decentralized-mapping-for-wallet-addresses-.xml b/static/bitcoin-dev/Nov_2017/combined_A-DNS-like-decentralized-mapping-for-wallet-addresses-.xml index 489ba1708c..254b73c25f 100644 --- a/static/bitcoin-dev/Nov_2017/combined_A-DNS-like-decentralized-mapping-for-wallet-addresses-.xml +++ b/static/bitcoin-dev/Nov_2017/combined_A-DNS-like-decentralized-mapping-for-wallet-addresses-.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - A DNS-like decentralized mapping for wallet addresses? - 2023-08-01T22:13:01.316898+00:00 - - Hampus Sjöberg 2017-12-19 13:11:24+00:00 - - - Damian Williamson 2017-12-19 09:05:34+00:00 - - - Sjors Provoost 2017-12-18 11:26:19+00:00 - - - Antonis Anastasiadis 2017-12-01 11:07:14+00:00 - - - Jérémie Dubois-Lacoste 2017-12-01 08:24:44+00:00 - - - CANNON 2017-12-01 04:17:37+00:00 - - - CANNON 2017-12-01 04:12:24+00:00 - - - Lucas Clemente Vella 2017-12-01 03:15:00+00:00 - - - Douglas Roark 2017-12-01 03:08:24+00:00 - - - Justin Newton 2017-12-01 00:10:29+00:00 - - - Tao Effect 2017-12-01 00:00:26+00:00 - - - mandar mulherkar 2017-11-30 22:20:10+00:00 - + 2025-09-26T15:50:25.225270+00:00 + python-feedgen + + + [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses? mandar mulherkar + 2017-11-30T22:20:00.000Z + + + Tao Effect + 2017-12-01T00:00:00.000Z + + + Justin Newton + 2017-12-01T00:10:00.000Z + + + Douglas Roark + 2017-12-01T03:08:00.000Z + + + Lucas Clemente Vella + 2017-12-01T03:15:00.000Z + + + CANNON + 2017-12-01T04:12:00.000Z + + + CANNON + 2017-12-01T04:17:00.000Z + + + Jérémie Dubois-Lacoste + 2017-12-01T08:24:00.000Z + + + Antonis Anastasiadis + 2017-12-01T11:07:00.000Z + + + Sjors Provoost + 2017-12-18T11:26:00.000Z + + + Damian Williamson + 2017-12-19T09:05:00.000Z + + + Hampus Sjöberg + 2017-12-19T13:11:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - A DNS-like decentralized mapping for wallet addresses? - 2023-08-01T22:13:01.316898+00:00 + 2025-09-26T15:50:25.226650+00:00 - The Bitcoin community has been discussing the possibility of a store-and-forward server that would allow users to trade privacy for convenience. This proposed solution, similar to BIP75, would allow users to use an email address as their account instead of a single Bitcoin address or xpubkey. While some members of the community express concerns about the security risks associated with the addition of DNS, others find it intriguing and believe it could be developed into something useful, especially when combined with BIP32 and BIP-47.The idea is to develop a Bitcoin wallet with an integrated name to address mapping feature, potentially based on Bitcoin Core. This mapping feature could include names, strings, and email addresses. However, relying on an additional service like DNS does introduce availability risks. It has been suggested that combining this mapping feature with BIP-47 could be beneficial, as payment codes could be associated with email addresses via DNS. The sender could then email the recipient the necessary information to retrieve funds, and the first transaction could have a time-locked refund in case the payment code becomes stale.The concept of a DNS-like decentralized mapping service for cryptocurrency addresses has been discussed on the bitcoin-dev mailing list. Douglas Roark shared his experience of working on a similar project with Armory and Verisign, which leveraged BIP32 to generate payment requests that automatically directed payees to the correct branch. Sjors proposed combining this with BIP-47 to associate payment codes with email addresses via DNS. The Open Alias project was recommended as a resource for further exploration.Lucas Clemente Vella expressed that a certain feature, which he believes has great potential, did not gain widespread adoption. He mentioned Namecoin as an alternative, as it aimed to build a decentralized domain name system (DNS) similar to Bitcoin's blockchain. Mandar Mulherkar questioned whether a DNS-like decentralized mapping service could provide user-friendly crypto addresses instead of long wallet addresses. OpenAlias.org was suggested as a possible solution.A new member of the bitcoin-dev community, Mandar Mulherkar, proposed the creation of a DNS-like decentralized mapping service for cryptocurrency addresses. This would allow users to input human-readable addresses that can be converted into wallet addresses by software. The original altcoin, Namecoin, attempted to build a similar system but did not gain widespread adoption. The user requested guidance on where to research this concept further.Another proposal for a DNS-like decentralized mapping service for crypto addresses was discussed on the bitcoin-dev mailing list. Armory and Verisign had previously attempted such a project, leveraging BIP32 to generate payment requests that directed payees to the correct branch. Douglas Roark considered this an interesting draft that could be developed further, with DNSSEC as a means to bootstrap identity to a common, reasonably secure standard.Mandar Mulherkar expressed curiosity about whether a DNS-like decentralized mapping service could provide user-friendly crypto addresses instead of long wallet addresses. The idea is to simplify the adoption process by eliminating the need for long strings or QR codes. One responder recommended WalletNames.com, which provides users with a human-readable name that can be mapped to their cryptocurrency address.In summary, there have been discussions within the Bitcoin community about the potential of a DNS-like decentralized mapping service for cryptocurrency addresses. This would enable users to input human-readable addresses that could be converted into wallet addresses by software. While some projects have attempted this in the past, there are ongoing efforts to explore and develop this concept further. Resources like Open Alias, Namecoin, Blockstack, and WalletNames.com have been suggested to research and potentially implement this idea. 2017-12-19T13:11:24+00:00 + The Bitcoin community has been discussing the possibility of a store-and-forward server that would allow users to trade privacy for convenience. This proposed solution, similar to BIP75, would allow users to use an email address as their account instead of a single Bitcoin address or xpubkey. While some members of the community express concerns about the security risks associated with the addition of DNS, others find it intriguing and believe it could be developed into something useful, especially when combined with BIP32 and BIP-47.The idea is to develop a Bitcoin wallet with an integrated name to address mapping feature, potentially based on Bitcoin Core. This mapping feature could include names, strings, and email addresses. However, relying on an additional service like DNS does introduce availability risks. It has been suggested that combining this mapping feature with BIP-47 could be beneficial, as payment codes could be associated with email addresses via DNS. The sender could then email the recipient the necessary information to retrieve funds, and the first transaction could have a time-locked refund in case the payment code becomes stale.The concept of a DNS-like decentralized mapping service for cryptocurrency addresses has been discussed on the bitcoin-dev mailing list. Douglas Roark shared his experience of working on a similar project with Armory and Verisign, which leveraged BIP32 to generate payment requests that automatically directed payees to the correct branch. Sjors proposed combining this with BIP-47 to associate payment codes with email addresses via DNS. The Open Alias project was recommended as a resource for further exploration.Lucas Clemente Vella expressed that a certain feature, which he believes has great potential, did not gain widespread adoption. He mentioned Namecoin as an alternative, as it aimed to build a decentralized domain name system (DNS) similar to Bitcoin's blockchain. Mandar Mulherkar questioned whether a DNS-like decentralized mapping service could provide user-friendly crypto addresses instead of long wallet addresses. OpenAlias.org was suggested as a possible solution.A new member of the bitcoin-dev community, Mandar Mulherkar, proposed the creation of a DNS-like decentralized mapping service for cryptocurrency addresses. This would allow users to input human-readable addresses that can be converted into wallet addresses by software. The original altcoin, Namecoin, attempted to build a similar system but did not gain widespread adoption. The user requested guidance on where to research this concept further.Another proposal for a DNS-like decentralized mapping service for crypto addresses was discussed on the bitcoin-dev mailing list. Armory and Verisign had previously attempted such a project, leveraging BIP32 to generate payment requests that directed payees to the correct branch. Douglas Roark considered this an interesting draft that could be developed further, with DNSSEC as a means to bootstrap identity to a common, reasonably secure standard.Mandar Mulherkar expressed curiosity about whether a DNS-like decentralized mapping service could provide user-friendly crypto addresses instead of long wallet addresses. The idea is to simplify the adoption process by eliminating the need for long strings or QR codes. One responder recommended WalletNames.com, which provides users with a human-readable name that can be mapped to their cryptocurrency address.In summary, there have been discussions within the Bitcoin community about the potential of a DNS-like decentralized mapping service for cryptocurrency addresses. This would enable users to input human-readable addresses that could be converted into wallet addresses by software. While some projects have attempted this in the past, there are ongoing efforts to explore and develop this concept further. Resources like Open Alias, Namecoin, Blockstack, and WalletNames.com have been suggested to research and potentially implement this idea. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_BIP-Idea-Marginal-Pricing.xml b/static/bitcoin-dev/Nov_2017/combined_BIP-Idea-Marginal-Pricing.xml index c6c2d2bf6f..b32b877dd4 100644 --- a/static/bitcoin-dev/Nov_2017/combined_BIP-Idea-Marginal-Pricing.xml +++ b/static/bitcoin-dev/Nov_2017/combined_BIP-Idea-Marginal-Pricing.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - BIP Idea: Marginal Pricing - 2023-08-01T22:11:38.305271+00:00 - - Damian Williamson 2017-12-02 03:55:22+00:00 - - - Ryan J Martin 2017-12-01 07:58:01+00:00 - - - Chenxi Cai 2017-11-30 16:15:01+00:00 - - - Eric Voskuil 2017-11-30 12:03:30+00:00 - - - Gregory Maxwell 2017-11-30 11:40:54+00:00 - - - Federico Tenga 2017-11-30 09:37:57+00:00 - - - Gregory Maxwell 2017-11-30 09:12:48+00:00 - - - William Morriss 2017-11-30 06:13:15+00:00 - - - William Morriss 2017-11-30 06:05:02+00:00 - - - Chenxi Cai 2017-11-30 05:52:24+00:00 - - - Ben Kloester 2017-11-30 02:38:25+00:00 - - - William Morriss 2017-11-30 00:47:43+00:00 - + 2025-09-26T15:50:31.513119+00:00 + python-feedgen + + + [bitcoin-dev] BIP Idea: Marginal Pricing William Morriss + 2017-11-30T00:47:00.000Z + + + Ben Kloester + 2017-11-30T02:38:00.000Z + + + Chenxi Cai + 2017-11-30T05:52:00.000Z + + + William Morriss + 2017-11-30T06:05:00.000Z + + + William Morriss + 2017-11-30T06:13:00.000Z + + + Gregory Maxwell + 2017-11-30T09:12:00.000Z + + + Federico Tenga + 2017-11-30T09:37:00.000Z + + + Gregory Maxwell + 2017-11-30T11:40:00.000Z + + + Eric Voskuil + 2017-11-30T12:03:00.000Z + + + Chenxi Cai + 2017-11-30T16:15:00.000Z + + + Ryan J Martin + 2017-12-01T07:58:00.000Z + + + Damian Williamson + 2017-12-02T03:55:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - BIP Idea: Marginal Pricing - 2023-08-01T22:11:38.305271+00:00 + 2025-09-26T15:50:31.514554+00:00 - A proposal has been made on the Bitcoin-dev mailing list to maximize total transaction fees and hash power. The proposal suggests using a marginal pricing system without a block size limit. Each transaction would have a transaction weight based on the fee paid and time waiting in the pool. A higher fee would increase the likelihood of a transaction being included in the current block. The dynamic block size limit would be regulated by profit motive, and all fees would be fair.William Morriss proposed the idea of Marginal Pricing in a Bitcoin Improvement Proposal (BIP) to address challenges in the current transaction market. The proposal aims to reduce pending transaction time, individual transaction fees, and increase total transaction fees. It suggests miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block, refunding excess fees. The block size limit would be removed to allow for a dynamic limit regulated by profit motive. However, there are challenges in implementing this proposal, including the need for validators to agree on the maximum block size and the risk of miners cheating by including extra transactions.The current fee system used in Bitcoin, Generalized first-price auction, may not be maximizing miners' fees. A two-part pricing scheme with a fixed fee per transaction and variable fee per byte could deter spamming and capture revenue from users with higher willingness to pay. While Vickrey–Clarke–Groves auction elicits truthful bids from bidders, it may not maximize miners' fees as much as other systems. The choice of fee design will not impact miners' fees unless the outcomes of the auction change. Switching to a marginal price bidding system could supersede the block size limit and change the outcome of the auction.An email thread on the Bitcoin-dev mailing list discussed a proposal to redesign Bitcoin's fee market. The proposal suggested changing the fee structure but not removing the block size limit. Out-of-band payments were a concern, but it was argued that miners would not have incentives to mine only out-of-band transactions. Bitcoin is neutral on how miners are paid, and on-chain fee payment has benefits such as preserving anonymity. There is no evidence of centralization pressure with marginal fees.The discussion also touched on the topic of Out of Band (OOB) fees in Bitcoin. The system disincentivizes both miners and users from preferring OOB fees. Competent wallet software can draft transactions paying OOB and min fee at equivalent rates. Miners would construct blocks that maximize their revenue. The use of MINFEE is not an equilibrium. Variance in fee willingness could result in variance in network capacity. However, rich uncle bill wasting money with high fees would handicap the network. Super-rational behavior could lead to collusion among miners to permit high fee-rate transactions every other block.The conversation among members of the bitcoin-dev mailing list discussed a proposal to change the fee structure in order to reduce the cost of running a node. Concerns were raised about miners spamming the network for free, which could increase the cost of running a node. A previous article proposed redesigning Bitcoin's fee market, but it broke down due to concerns about out-of-band payments. The author argues that the system disincentivizes out-of-band tx fees, and there is no more centralization pressure with marginal fees than before.The email thread also addressed the possibility of using alternative auction systems in Bitcoin. Currently, Bitcoin uses a Generalized first-price auction, but alternative approaches such as Generalized second-price or Vickrey-Clarke-Groves auctions were considered. However, the choice of fee design will not impact miners' fees unless the outcomes of the auction change. Changing the bidding system to the marginal price would allow for a superseding of the block size limit and change the outcome of the auction.The proposal aims to maximize total transaction fees, reduce pending transaction time, and lower individual transaction fees. It suggests accepting zero fees natively in the protocol and instead accepting actual fees out-of-band or via OP_TRUE outputs. Miners would implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block, and excess transaction fees would be refunded to the inputs. This dynamic block size limit regulated by profit motive would maximize transaction fees for every block.Overall, the discussion revolves around proposals to redesign Bitcoin's fee market, maximize total transaction fees, reduce pending transaction time, and lower individual transaction fees. Various approaches, such as marginal pricing and alternative auction systems, have been considered. Challenges such as validators agreeing on maximum block size and miners cheating by including extra transactions need to be addressed.The proposal in this context is to remove the block size limit in order to address the downsides associated with a fixed block size. These downsides include unpredictable transaction settlement time, variable transaction fees depending on network congestion, and frequent overpay. By eliminating the block size limit, miners would be able to choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees would 2017-12-02T03:55:22+00:00 + A proposal has been made on the Bitcoin-dev mailing list to maximize total transaction fees and hash power. The proposal suggests using a marginal pricing system without a block size limit. Each transaction would have a transaction weight based on the fee paid and time waiting in the pool. A higher fee would increase the likelihood of a transaction being included in the current block. The dynamic block size limit would be regulated by profit motive, and all fees would be fair.William Morriss proposed the idea of Marginal Pricing in a Bitcoin Improvement Proposal (BIP) to address challenges in the current transaction market. The proposal aims to reduce pending transaction time, individual transaction fees, and increase total transaction fees. It suggests miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block, refunding excess fees. The block size limit would be removed to allow for a dynamic limit regulated by profit motive. However, there are challenges in implementing this proposal, including the need for validators to agree on the maximum block size and the risk of miners cheating by including extra transactions.The current fee system used in Bitcoin, Generalized first-price auction, may not be maximizing miners' fees. A two-part pricing scheme with a fixed fee per transaction and variable fee per byte could deter spamming and capture revenue from users with higher willingness to pay. While Vickrey–Clarke–Groves auction elicits truthful bids from bidders, it may not maximize miners' fees as much as other systems. The choice of fee design will not impact miners' fees unless the outcomes of the auction change. Switching to a marginal price bidding system could supersede the block size limit and change the outcome of the auction.An email thread on the Bitcoin-dev mailing list discussed a proposal to redesign Bitcoin's fee market. The proposal suggested changing the fee structure but not removing the block size limit. Out-of-band payments were a concern, but it was argued that miners would not have incentives to mine only out-of-band transactions. Bitcoin is neutral on how miners are paid, and on-chain fee payment has benefits such as preserving anonymity. There is no evidence of centralization pressure with marginal fees.The discussion also touched on the topic of Out of Band (OOB) fees in Bitcoin. The system disincentivizes both miners and users from preferring OOB fees. Competent wallet software can draft transactions paying OOB and min fee at equivalent rates. Miners would construct blocks that maximize their revenue. The use of MINFEE is not an equilibrium. Variance in fee willingness could result in variance in network capacity. However, rich uncle bill wasting money with high fees would handicap the network. Super-rational behavior could lead to collusion among miners to permit high fee-rate transactions every other block.The conversation among members of the bitcoin-dev mailing list discussed a proposal to change the fee structure in order to reduce the cost of running a node. Concerns were raised about miners spamming the network for free, which could increase the cost of running a node. A previous article proposed redesigning Bitcoin's fee market, but it broke down due to concerns about out-of-band payments. The author argues that the system disincentivizes out-of-band tx fees, and there is no more centralization pressure with marginal fees than before.The email thread also addressed the possibility of using alternative auction systems in Bitcoin. Currently, Bitcoin uses a Generalized first-price auction, but alternative approaches such as Generalized second-price or Vickrey-Clarke-Groves auctions were considered. However, the choice of fee design will not impact miners' fees unless the outcomes of the auction change. Changing the bidding system to the marginal price would allow for a superseding of the block size limit and change the outcome of the auction.The proposal aims to maximize total transaction fees, reduce pending transaction time, and lower individual transaction fees. It suggests accepting zero fees natively in the protocol and instead accepting actual fees out-of-band or via OP_TRUE outputs. Miners would implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block, and excess transaction fees would be refunded to the inputs. This dynamic block size limit regulated by profit motive would maximize transaction fees for every block.Overall, the discussion revolves around proposals to redesign Bitcoin's fee market, maximize total transaction fees, reduce pending transaction time, and lower individual transaction fees. Various approaches, such as marginal pricing and alternative auction systems, have been considered. Challenges such as validators agreeing on maximum block size and miners cheating by including extra transactions need to be addressed.The proposal in this context is to remove the block size limit in order to address the downsides associated with a fixed block size. These downsides include unpredictable transaction settlement time, variable transaction fees depending on network congestion, and frequent overpay. By eliminating the block size limit, miners would be able to choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees would - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_BIP-Proposal-Compact-Client-Side-Filtering-for-Light-Clients.xml b/static/bitcoin-dev/Nov_2017/combined_BIP-Proposal-Compact-Client-Side-Filtering-for-Light-Clients.xml index dc12d0a28b..5ef918cfc1 100644 --- a/static/bitcoin-dev/Nov_2017/combined_BIP-Proposal-Compact-Client-Side-Filtering-for-Light-Clients.xml +++ b/static/bitcoin-dev/Nov_2017/combined_BIP-Proposal-Compact-Client-Side-Filtering-for-Light-Clients.xml @@ -1,122 +1,167 @@ - + 2 Combined summary - BIP Proposal: Compact Client Side Filtering for Light Clients - 2023-08-01T20:51:02.028155+00:00 - - Olaoluwa Osuntokun 2017-11-09 23:44:07+00:00 - - - Adam Back 2017-06-20 17:20:53+00:00 - - - bfd at cock.lu 2017-06-20 13:08:03+00:00 - - - Tom Zander 2017-06-20 09:52:00+00:00 - - - Eric Voskuil 2017-06-20 07:03:43+00:00 - - - Gregory Maxwell 2017-06-19 22:41:49+00:00 - - - Andreas Schildbach 2017-06-19 20:49:17+00:00 - - - Tom Zander 2017-06-19 16:38:55+00:00 - - - adiabat 2017-06-19 16:36:41+00:00 - - - Jonas Schnelli 2017-06-19 16:30:18+00:00 - - - Jonas Schnelli 2017-06-19 16:22:03+00:00 - - - Jonas Schnelli 2017-06-19 16:10:13+00:00 - - - Tom Zander 2017-06-19 16:07:45+00:00 - - - Andreas Schildbach 2017-06-19 15:59:57+00:00 - - - Jonas Schnelli 2017-06-19 15:49:59+00:00 - - - Andreas Schildbach 2017-06-19 15:43:14+00:00 - - - Tom Zander 2017-06-19 15:15:10+00:00 - - - bfd at cock.lu 2017-06-19 12:26:46+00:00 - - - Andreas Schildbach 2017-06-19 11:58:18+00:00 - - - Tomas 2017-06-09 08:26:52+00:00 - - - Olaoluwa Osuntokun 2017-06-09 04:47:19+00:00 - - - Olaoluwa Osuntokun 2017-06-09 03:59:17+00:00 - - - Olaoluwa Osuntokun 2017-06-09 03:50:37+00:00 - - - Olaoluwa Osuntokun 2017-06-09 03:42:58+00:00 - - - Olaoluwa Osuntokun 2017-06-09 03:03:51+00:00 - - - Tomas 2017-06-08 09:50:08+00:00 - - - Gregory Maxwell 2017-06-07 21:41:36+00:00 - - - Karl Johan Alm 2017-06-05 02:06:32+00:00 - - - Alex Akselrod 2017-06-02 17:55:31+00:00 - - - Chris Pacia 2017-06-02 16:07:17+00:00 - - - Karl Johan Alm 2017-06-02 06:00:30+00:00 - - - Olaoluwa Osuntokun 2017-06-02 04:49:16+00:00 - - - Alex Akselrod 2017-06-02 03:35:29+00:00 - - - Gregory Maxwell 2017-06-02 02:28:54+00:00 - - - Chris 2017-06-02 02:15:16+00:00 - - - Olaoluwa Osuntokun 2017-06-01 22:10:34+00:00 - - - Eric Lombrozo 2017-06-01 21:00:02+00:00 - - - Olaoluwa Osuntokun 2017-06-01 19:01:14+00:00 - + 2025-09-26T15:50:18.918721+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients Olaoluwa Osuntokun + 2017-06-01T19:01:00.000Z + + + Eric Lombrozo + 2017-06-01T21:00:00.000Z + + + Matt Corallo + 2017-06-01T21:33:00.000Z + + + Olaoluwa Osuntokun + 2017-06-01T22:10:00.000Z + + + Chris + 2017-06-02T02:15:00.000Z + + + Gregory Maxwell + 2017-06-02T02:28:00.000Z + + + Alex Akselrod + 2017-06-02T03:35:00.000Z + + + Olaoluwa Osuntokun + 2017-06-02T04:49:00.000Z + + + Karl Johan Alm + 2017-06-02T06:00:00.000Z + + + Chris Pacia + 2017-06-02T16:07:00.000Z + + + Alex Akselrod + 2017-06-02T17:55:00.000Z + + + Karl Johan Alm + 2017-06-05T02:06:00.000Z + + + Gregory Maxwell + 2017-06-07T21:41:00.000Z + + + Tomas + 2017-06-08T09:50:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T03:03:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T03:42:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T03:50:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T03:59:00.000Z + + + Olaoluwa Osuntokun + 2017-06-09T04:47:00.000Z + + + Tomas + 2017-06-09T08:26:00.000Z + + + Andreas Schildbach + 2017-06-19T11:58:00.000Z + + + bfd + 2017-06-19T12:26:00.000Z + + + Tom Zander + 2017-06-19T15:15:00.000Z + + + Andreas Schildbach + 2017-06-19T15:43:00.000Z + + + Jonas Schnelli + 2017-06-19T15:49:00.000Z + + + Andreas Schildbach + 2017-06-19T15:59:00.000Z + + + Tom Zander + 2017-06-19T16:07:00.000Z + + + Jonas Schnelli + 2017-06-19T16:10:00.000Z + + + Jonas Schnelli + 2017-06-19T16:22:00.000Z + + + Jonas Schnelli + 2017-06-19T16:30:00.000Z + + + adiabat + 2017-06-19T16:36:00.000Z + + + Tom Zander + 2017-06-19T16:38:00.000Z + + + Andreas Schildbach + 2017-06-19T20:49:00.000Z + + + Gregory Maxwell + 2017-06-19T22:41:00.000Z + + + Eric Voskuil + 2017-06-20T07:03:00.000Z + + + Tom Zander + 2017-06-20T09:52:00.000Z + + + bfd + 2017-06-20T13:08:00.000Z + + + Adam Back + 2017-06-20T17:20:00.000Z + + + Olaoluwa Osuntokun + 2017-11-09T23:44:00.000Z + + @@ -155,13 +200,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal: Compact Client Side Filtering for Light Clients - 2023-08-01T20:51:02.029154+00:00 + 2025-09-26T15:50:18.922732+00:00 - There have been ongoing discussions and debates within the Bitcoin community regarding the necessity of filtering unconfirmed transactions. One of the main points of contention is the trade-off between privacy and transaction notification in Bitcoin wallets.The current method of filtering unconfirmed transactions, known as BIP37, has been criticized for its resource consumption and lack of long-term value for Bitcoin. Some argue that relying solely on BIP37 availability is fragile and exploring alternative methods is reasonable.In a discussion thread on the bitcoin-dev forum, it was suggested that users may be willing to sacrifice privacy by using client-side filtering in exchange for not having an "incoming transaction" feature or fetching all received transactions only when they need 0-conf. However, others argue that immediate feedback on transactions being broadcasted is necessary for basic usability.It has been noted that there are privacy issues associated with BIP37, but they are not a significant concern for most regular users. On the other hand, delayed or missing transactions are a much more common issue faced by Bitcoin wallet users.The concept of Simplified Payment Verification (SPV) was brought up in the discussion, with the reminder that it is not applicable to unconfirmed transactions. SPV relies on miners committing to a transaction through work to provide assurance to the user that the transaction is valid. However, unconfirmed transactions can be easily forged by anyone, including the user's ISP.The debate also touched on the use of mempool filtering, which gives users false assurance that there is a valid but yet-to-be-confirmed transaction sending them money. It was pointed out that unconfirmed transactions are not final and can still be rejected by the network.In addition to the discussion on filtering unconfirmed transactions, there have been proposals for new light client Bitcoin Improvement Proposals (BIPs) that aim to improve the usability and efficiency of Bitcoin wallets. These proposals include suggestions for different types of light clients and potential solutions to address issues in the construction and lookup of filters.Overall, there is ongoing dialogue within the Bitcoin community about the balance between privacy and transaction notification in Bitcoin wallets. Various proposals and ideas are being discussed to improve the usability and efficiency of Bitcoin wallets while considering the trade-offs involved. Feedback from users and developers is being sought to further refine these proposals. 2017-11-09T23:44:07+00:00 + There have been ongoing discussions and debates within the Bitcoin community regarding the necessity of filtering unconfirmed transactions. One of the main points of contention is the trade-off between privacy and transaction notification in Bitcoin wallets.The current method of filtering unconfirmed transactions, known as BIP37, has been criticized for its resource consumption and lack of long-term value for Bitcoin. Some argue that relying solely on BIP37 availability is fragile and exploring alternative methods is reasonable.In a discussion thread on the bitcoin-dev forum, it was suggested that users may be willing to sacrifice privacy by using client-side filtering in exchange for not having an "incoming transaction" feature or fetching all received transactions only when they need 0-conf. However, others argue that immediate feedback on transactions being broadcasted is necessary for basic usability.It has been noted that there are privacy issues associated with BIP37, but they are not a significant concern for most regular users. On the other hand, delayed or missing transactions are a much more common issue faced by Bitcoin wallet users.The concept of Simplified Payment Verification (SPV) was brought up in the discussion, with the reminder that it is not applicable to unconfirmed transactions. SPV relies on miners committing to a transaction through work to provide assurance to the user that the transaction is valid. However, unconfirmed transactions can be easily forged by anyone, including the user's ISP.The debate also touched on the use of mempool filtering, which gives users false assurance that there is a valid but yet-to-be-confirmed transaction sending them money. It was pointed out that unconfirmed transactions are not final and can still be rejected by the network.In addition to the discussion on filtering unconfirmed transactions, there have been proposals for new light client Bitcoin Improvement Proposals (BIPs) that aim to improve the usability and efficiency of Bitcoin wallets. These proposals include suggestions for different types of light clients and potential solutions to address issues in the construction and lookup of filters.Overall, there is ongoing dialogue within the Bitcoin community about the balance between privacy and transaction notification in Bitcoin wallets. Various proposals and ideas are being discussed to improve the usability and efficiency of Bitcoin wallets while considering the trade-offs involved. Feedback from users and developers is being sought to further refine these proposals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_BIP159-NODE-NETWORK-LIMITED-service-bits-extendability.xml b/static/bitcoin-dev/Nov_2017/combined_BIP159-NODE-NETWORK-LIMITED-service-bits-extendability.xml index 1d603055ad..025269baae 100644 --- a/static/bitcoin-dev/Nov_2017/combined_BIP159-NODE-NETWORK-LIMITED-service-bits-extendability.xml +++ b/static/bitcoin-dev/Nov_2017/combined_BIP159-NODE-NETWORK-LIMITED-service-bits-extendability.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - BIP159 - NODE_NETWORK_LIMITED service bits, extendability - 2023-08-01T22:10:00.226753+00:00 - - Peter Todd 2017-11-28 10:48:28+00:00 - - - Jonas Schnelli 2017-11-21 19:00:21+00:00 - - - Gregory Maxwell 2017-11-21 18:45:33+00:00 - - - Sjors Provoost 2017-11-21 14:03:46+00:00 - + 2025-09-26T15:50:29.401203+00:00 + python-feedgen + + + [bitcoin-dev] BIP159 - NODE_NETWORK_LIMITED service bits, extendability Sjors Provoost + 2017-11-21T14:03:00.000Z + + + Gregory Maxwell + 2017-11-21T18:45:00.000Z + + + Jonas Schnelli + 2017-11-21T19:00:00.000Z + + + Peter Todd + 2017-11-28T10:48:00.000Z + + - python-feedgen + 2 Combined summary - BIP159 - NODE_NETWORK_LIMITED service bits, extendability - 2023-08-01T22:10:00.226753+00:00 + 2025-09-26T15:50:29.401890+00:00 - The proposed Bitcoin Core implementation of BIP159 aims to allow pruned nodes to serve a limited number of historical blocks, instead of none at all. However, there is a concern that this would be wasteful as pruned nodes with 10-100 GB of storage would only be able to share the most recent 288 blocks.To address this, a future extension of the BIP could allow more flexibility by limiting the number of choices to e.g. 288 + 1000 * 2^n. This would provide node operators with the option to choose a greater prune depth if they are willing to accept the increased risk of fingerprinting.Upgraded nodes may need a new message type to communicate the chosen prune depth. It is suggested that waiting for BIP150 would be appropriate, as it would exempt whitelisted peers from the anti-fingerprinting measure. However, restricting it to just whitelisted peers may not be desirable.In order to improve the BIP itself, minor suggestions have been made. These include adding links to mailing list discussions in the reference section and explaining that 288 is not just the minimum limit for Bitcoin Core, but also represents the bulk of traffic.Currently, virtually no one sets any parameter other than the minimum for pruning. However, in the future, further pruning identifying bits will be set so that nodes can answer for their blocks. Defining additional levels has been delayed due to insufficient experience and concerns about interaction with other proposals.Fetching additional blocks is seen as less significant due to the abundance of nodes that serve anything on the network. Additionally, the probability of fetching older blocks becomes close to uniform after a few weeks, and these fetches are mainly for newly initializing nodes.Overall, the proposed implementation of BIP159 seeks to balance the desire to serve archived blocks with the need to prevent fingerprinting. Future extensions and improvements are being considered to provide more flexibility and enhance the functionality of pruned nodes in the Bitcoin network. 2017-11-28T10:48:28+00:00 + The proposed Bitcoin Core implementation of BIP159 aims to allow pruned nodes to serve a limited number of historical blocks, instead of none at all. However, there is a concern that this would be wasteful as pruned nodes with 10-100 GB of storage would only be able to share the most recent 288 blocks.To address this, a future extension of the BIP could allow more flexibility by limiting the number of choices to e.g. 288 + 1000 * 2^n. This would provide node operators with the option to choose a greater prune depth if they are willing to accept the increased risk of fingerprinting.Upgraded nodes may need a new message type to communicate the chosen prune depth. It is suggested that waiting for BIP150 would be appropriate, as it would exempt whitelisted peers from the anti-fingerprinting measure. However, restricting it to just whitelisted peers may not be desirable.In order to improve the BIP itself, minor suggestions have been made. These include adding links to mailing list discussions in the reference section and explaining that 288 is not just the minimum limit for Bitcoin Core, but also represents the bulk of traffic.Currently, virtually no one sets any parameter other than the minimum for pruning. However, in the future, further pruning identifying bits will be set so that nodes can answer for their blocks. Defining additional levels has been delayed due to insufficient experience and concerns about interaction with other proposals.Fetching additional blocks is seen as less significant due to the abundance of nodes that serve anything on the network. Additionally, the probability of fetching older blocks becomes close to uniform after a few weeks, and these fetches are mainly for newly initializing nodes.Overall, the proposed implementation of BIP159 seeks to balance the desire to serve archived blocks with the need to prevent fingerprinting. Future extensions and improvements are being considered to provide more flexibility and enhance the functionality of pruned nodes in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Bitcoin-Cash-s-new-difficulty-algorithm.xml b/static/bitcoin-dev/Nov_2017/combined_Bitcoin-Cash-s-new-difficulty-algorithm.xml index 45f19bc27a..03fa628a95 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Bitcoin-Cash-s-new-difficulty-algorithm.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Bitcoin-Cash-s-new-difficulty-algorithm.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Bitcoin Cash's new difficulty algorithm - 2023-08-01T22:06:15.473765+00:00 - - Jacob Eliosoff 2017-11-04 03:37:06+00:00 - - - Scott Roberts 2017-11-03 01:59:47+00:00 - - - gb 2017-11-03 00:47:27+00:00 - - - Gregory Maxwell 2017-11-03 00:00:07+00:00 - - - Scott Roberts 2017-11-02 23:53:25+00:00 - - - CryptAxe 2017-11-02 23:39:41+00:00 - - - Gregory Maxwell 2017-11-02 23:37:29+00:00 - - - Scott Roberts 2017-11-02 23:31:55+00:00 - + 2025-09-26T15:50:16.793832+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Cash's new difficulty algorithm Scott Roberts + 2017-11-02T23:31:00.000Z + + + Gregory Maxwell + 2017-11-02T23:37:00.000Z + + + CryptAxe + 2017-11-02T23:39:00.000Z + + + Scott Roberts + 2017-11-02T23:53:00.000Z + + + Gregory Maxwell + 2017-11-03T00:00:00.000Z + + + gb + 2017-11-03T00:47:00.000Z + + + Scott Roberts + 2017-11-03T01:59:00.000Z + + + Jacob Eliosoff + 2017-11-04T03:37:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Cash's new difficulty algorithm - 2023-08-01T22:06:15.473765+00:00 + 2025-09-26T15:50:16.794840+00:00 - There is concern that changes to the difficulty adjustment algorithm (DAA) for Bitcoin Cash (BCH) may have implications for Bitcoin (BTC). The current DA is only sufficient if BCH has the highest hashpower, which could lead to long block delays. High transaction fees could incentivize miners to defect back to BTC, but if SegWit2x becomes more comparable in price to BCH, hashpower could oscillate between the two coins, causing delays for both. It is advised to monitor what happens when BCH implements its new algorithm to see if BTC needs a hard fork for the same reason and requires a similar fix.Scott Roberts suggests that Bitcoin may need to hard fork and use a similar algorithm to BCH, as it is likely to be simple and tested. BCH's algorithm uses a median of 3 for the beginning and end of the window to address bad timestamp issues. It also has limits on the adjustment per block. Roberts recommends that BTC consider using this algorithm with a modification of N=50 instead of the current N=144. Another contender is Degnr8's D622 algorithm, which gives higher weight to more recent timestamps.Bitcoin Cash plans to implement a new difficulty algorithm with its hard fork on November 13th. If necessary, Bitcoin may also hard fork to use a similar algorithm. The current algorithm for BTC is considered slow and only effective if it has the highest hashpower. The first coin to hard fork and fix the difficulty problem will have an advantage, as observed in other altcoins. Developers are advised to observe BCH's implementation of the new algorithm to prepare for a potential hard fork.The discussion on the Bitcoin development mailing list regarding the implementation of a new difficulty algorithm for Bitcoin Cash reveals differing opinions. Scott Roberts praises the code but expresses concern about potential politicization if the word "Cash" is mentioned. Gregory Maxwell argues that the discussion is off-topic and criticizes the proposal as coming from a competing system. The mailing list is reminded to focus on Bitcoin development and avoid off-topic posts.In an email, Scott Roberts praises the code of a previously criticized group as a viable solution to a threat facing Bitcoin. He urges colleagues not to be distracted by competitors trying to divert attention away from their own proposals.Overall, Bitcoin Cash's new difficulty algorithm is seen as one of the best options due to its simplicity and testing. It uses a median of three for the beginning and end of the window to address timestamp issues. There are also limits on adjustment per block. Bitcoin may consider adopting this algorithm with a modification of N=50. However, Degnr8's D622 algorithm is regarded as a better contender. It assigns higher weight to recent timestamps. Any modification to the algorithm's weighted average is believed to reduce its effectiveness. Bitcoin Cash's hard fork on November 13th will provide insight into the success of their new algorithm. 2017-11-04T03:37:06+00:00 + There is concern that changes to the difficulty adjustment algorithm (DAA) for Bitcoin Cash (BCH) may have implications for Bitcoin (BTC). The current DA is only sufficient if BCH has the highest hashpower, which could lead to long block delays. High transaction fees could incentivize miners to defect back to BTC, but if SegWit2x becomes more comparable in price to BCH, hashpower could oscillate between the two coins, causing delays for both. It is advised to monitor what happens when BCH implements its new algorithm to see if BTC needs a hard fork for the same reason and requires a similar fix.Scott Roberts suggests that Bitcoin may need to hard fork and use a similar algorithm to BCH, as it is likely to be simple and tested. BCH's algorithm uses a median of 3 for the beginning and end of the window to address bad timestamp issues. It also has limits on the adjustment per block. Roberts recommends that BTC consider using this algorithm with a modification of N=50 instead of the current N=144. Another contender is Degnr8's D622 algorithm, which gives higher weight to more recent timestamps.Bitcoin Cash plans to implement a new difficulty algorithm with its hard fork on November 13th. If necessary, Bitcoin may also hard fork to use a similar algorithm. The current algorithm for BTC is considered slow and only effective if it has the highest hashpower. The first coin to hard fork and fix the difficulty problem will have an advantage, as observed in other altcoins. Developers are advised to observe BCH's implementation of the new algorithm to prepare for a potential hard fork.The discussion on the Bitcoin development mailing list regarding the implementation of a new difficulty algorithm for Bitcoin Cash reveals differing opinions. Scott Roberts praises the code but expresses concern about potential politicization if the word "Cash" is mentioned. Gregory Maxwell argues that the discussion is off-topic and criticizes the proposal as coming from a competing system. The mailing list is reminded to focus on Bitcoin development and avoid off-topic posts.In an email, Scott Roberts praises the code of a previously criticized group as a viable solution to a threat facing Bitcoin. He urges colleagues not to be distracted by competitors trying to divert attention away from their own proposals.Overall, Bitcoin Cash's new difficulty algorithm is seen as one of the best options due to its simplicity and testing. It uses a median of three for the beginning and end of the window to address timestamp issues. There are also limits on adjustment per block. Bitcoin may consider adopting this algorithm with a modification of N=50. However, Degnr8's D622 algorithm is regarded as a better contender. It assigns higher weight to recent timestamps. Any modification to the algorithm's weighted average is believed to reduce its effectiveness. Bitcoin Cash's hard fork on November 13th will provide insight into the success of their new algorithm. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Block-compression.xml b/static/bitcoin-dev/Nov_2017/combined_Block-compression.xml index 5066065bc7..a9c67ebe70 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Block-compression.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Block-compression.xml @@ -1,27 +1,37 @@ - + 2 Combined summary - Block compression - 2023-08-01T22:10:14.417453+00:00 - - Jonas Schnelli 2017-11-27 20:49:07+00:00 - - - Marco Pontello 2017-11-27 12:08:05+00:00 - - - Jeff Johnson 2017-11-27 02:11:27+00:00 - + 2025-09-26T15:50:27.316143+00:00 + python-feedgen + + + [bitcoin-dev] Block compression Jeff Johnson + 2017-11-27T02:11:00.000Z + + + [bitcoin-dev] 答复: " lonsdale aseaday + 2017-11-27T02:32:00.000Z + + + [bitcoin-dev] " Marco Pontello + 2017-11-27T12:08:00.000Z + + + Jonas Schnelli + 2017-11-27T20:49:00.000Z + + - python-feedgen + 2 Combined summary - Block compression - 2023-08-01T22:10:14.417453+00:00 + 2025-09-26T15:50:27.316826+00:00 - In a recent email conversation on the Bitcoin-dev mailing list, Jeff Johnson presented a potential solution to increase the amount of data in a block without increasing its size on disk. He conducted tests using different compression algorithms on a raw Bitcoin block and achieved a compression ratio of approximately 50%. The compression methods he tested included Gzip, LZMA, ZStandard, and LZ4.Among these methods, LZ4 demonstrated the fastest decompression speed at 3.3GB per second, which is almost half the speed of memcpy. Considering that blocks will be decompressed significantly more times than they will be compressed, decompression time is of greater importance.If this solution were to be implemented in the Bitcoin protocol, there would need to be a mechanism to specify the compression type using a set of bits. This would allow for the potential addition of future compression algorithms. Miners would have the flexibility to decide how many transactions they want to include in a block while keeping the compressed size within the limit.To accommodate the compression, the Bitcoin client code would require modifications to handle the appropriate compression bits and adjust the limits of signature data accordingly. It is worth noting that Schnorr signatures, which are expected to be introduced as a compression gain of 25%, could potentially achieve even further compression when combined with the compression methods mentioned by Johnson.The issue of bandwidth usage during historical block transmission was also addressed. If bandwidth is a concern, on-the-fly Gzip compression similar to Apache's mod_deflate could be applied. Furthermore, if disk space is an issue, it is suggested that the database layer should handle the compression.Although previous discussions have revolved around similar approaches, it remains uncertain whether compression should be integrated into the Bitcoin protocol directly or implemented through different layers. Regardless, Jeff Johnson's findings on a recent Bitcoin block can be accessed through the link provided in the original message.In summary, Jeff Johnson has proposed a solution to increase block data without increasing its size on disk. By utilizing various compression algorithms, he achieved a 50% compression ratio on a raw Bitcoin block. The fastest decompression speed was observed with LZ4, and the practical choice for compression was ZStandard. Implementation of this solution would require miners to specify the compression type, while the Bitcoin client code would need to be modified accordingly. There is potential for further compression gains when combining Schnorr signatures with the proposed compression methods. Bandwidth concerns could be addressed through on-the-fly Gzip compression, while disk space issues may be handled by the database layer. 2017-11-27T20:49:07+00:00 + In a recent email conversation on the Bitcoin-dev mailing list, Jeff Johnson presented a potential solution to increase the amount of data in a block without increasing its size on disk. He conducted tests using different compression algorithms on a raw Bitcoin block and achieved a compression ratio of approximately 50%. The compression methods he tested included Gzip, LZMA, ZStandard, and LZ4.Among these methods, LZ4 demonstrated the fastest decompression speed at 3.3GB per second, which is almost half the speed of memcpy. Considering that blocks will be decompressed significantly more times than they will be compressed, decompression time is of greater importance.If this solution were to be implemented in the Bitcoin protocol, there would need to be a mechanism to specify the compression type using a set of bits. This would allow for the potential addition of future compression algorithms. Miners would have the flexibility to decide how many transactions they want to include in a block while keeping the compressed size within the limit.To accommodate the compression, the Bitcoin client code would require modifications to handle the appropriate compression bits and adjust the limits of signature data accordingly. It is worth noting that Schnorr signatures, which are expected to be introduced as a compression gain of 25%, could potentially achieve even further compression when combined with the compression methods mentioned by Johnson.The issue of bandwidth usage during historical block transmission was also addressed. If bandwidth is a concern, on-the-fly Gzip compression similar to Apache's mod_deflate could be applied. Furthermore, if disk space is an issue, it is suggested that the database layer should handle the compression.Although previous discussions have revolved around similar approaches, it remains uncertain whether compression should be integrated into the Bitcoin protocol directly or implemented through different layers. Regardless, Jeff Johnson's findings on a recent Bitcoin block can be accessed through the link provided in the original message.In summary, Jeff Johnson has proposed a solution to increase block data without increasing its size on disk. By utilizing various compression algorithms, he achieved a 50% compression ratio on a raw Bitcoin block. The fastest decompression speed was observed with LZ4, and the practical choice for compression was ZStandard. Implementation of this solution would require miners to specify the compression type, while the Bitcoin client code would need to be modified accordingly. There is potential for further compression gains when combining Schnorr signatures with the proposed compression methods. Bandwidth concerns could be addressed through on-the-fly Gzip compression, while disk space issues may be handled by the database layer. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Centralizing-mining-by-force.xml b/static/bitcoin-dev/Nov_2017/combined_Centralizing-mining-by-force.xml index 75ed958b99..582638bf61 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Centralizing-mining-by-force.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Centralizing-mining-by-force.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Centralizing mining by force - 2023-08-01T22:07:43.306394+00:00 - - Eric Voskuil 2017-11-09 18:18:17+00:00 - - - ZmnSCPxj 2017-11-08 05:37:39+00:00 - - - Marc Bevand 2017-11-08 05:04:07+00:00 - - - Robert Taylor 2017-11-07 03:55:59+00:00 - + 2025-09-26T15:50:12.591986+00:00 + python-feedgen + + + [bitcoin-dev] Centralizing mining by force Robert Taylor + 2017-11-07T03:55:00.000Z + + + Marc Bevand + 2017-11-08T05:04:00.000Z + + + ZmnSCPxj + 2017-11-08T05:37:00.000Z + + + Eric Voskuil + 2017-11-09T18:18:00.000Z + + - python-feedgen + 2 Combined summary - Centralizing mining by force - 2023-08-01T22:07:43.306394+00:00 + 2025-09-26T15:50:12.592670+00:00 - In a recent discussion on the bitcoin-dev mailing list, the threat of a majority attack, also known as a "51% attack," on Bitcoin was raised. This attack involves a majority of miners forming a cartel and invalidating blocks made by miners outside of their group. One proposed method for achieving this is through a soft fork that requires a signature from a set of keys known only to the cartel. While there is no technical mechanism in place to prevent such an attack, it is argued that miners are not incentivized to perform it as it would destroy confidence in Bitcoin and ultimately impact their revenues.However, it is noted that in practice, there exists an incentive to disrupt the market for transaction confirmation, as statism is profitable and a primary source of revenue is seigniorage. This presents a hefty incentive for those who feel threatened by Bitcoin's disruption of that privilege. The security model of Bitcoin is based on miners and merchants defending their mutually beneficial market from the state, rather than balancing power between them. Despite broad decentralization mitigating the risk to each individual, people must be willing to defend their mines and economic nodes, which requires personal risk.The discussion also touched on the importance of fullnodes in determining which set of rules to follow. If fullnodes do not care about the cartel's actions, then the group of miners that is larger wins. However, if fullnodes check one or the other set of rules, then that set of rules will win. Given current politics, it is likely that fullnodes will institute an anti-cartel rule in this case and reject the cartel, resulting in low hashrate for the cartel. Eventually, the cartel will be betrayed by one of its members mining the anti-cartel chain in return for fees and valuable block rewards.In conclusion, while it may not be feasible for one actor to gain a majority of hash power alone, collusion among a group of miners makes it possible. To ensure the continued security and integrity of the Bitcoin network, countermeasures must be put in place to prevent centralization of mining by force. Fullnodes need to be aware of the rules and reject any attempt to form a cartel. The ongoing discussion amongst those involved in Bitcoin development aims to address these concerns and find solutions that maintain the permissionless nature of mining. 2017-11-09T18:18:17+00:00 + In a recent discussion on the bitcoin-dev mailing list, the threat of a majority attack, also known as a "51% attack," on Bitcoin was raised. This attack involves a majority of miners forming a cartel and invalidating blocks made by miners outside of their group. One proposed method for achieving this is through a soft fork that requires a signature from a set of keys known only to the cartel. While there is no technical mechanism in place to prevent such an attack, it is argued that miners are not incentivized to perform it as it would destroy confidence in Bitcoin and ultimately impact their revenues.However, it is noted that in practice, there exists an incentive to disrupt the market for transaction confirmation, as statism is profitable and a primary source of revenue is seigniorage. This presents a hefty incentive for those who feel threatened by Bitcoin's disruption of that privilege. The security model of Bitcoin is based on miners and merchants defending their mutually beneficial market from the state, rather than balancing power between them. Despite broad decentralization mitigating the risk to each individual, people must be willing to defend their mines and economic nodes, which requires personal risk.The discussion also touched on the importance of fullnodes in determining which set of rules to follow. If fullnodes do not care about the cartel's actions, then the group of miners that is larger wins. However, if fullnodes check one or the other set of rules, then that set of rules will win. Given current politics, it is likely that fullnodes will institute an anti-cartel rule in this case and reject the cartel, resulting in low hashrate for the cartel. Eventually, the cartel will be betrayed by one of its members mining the anti-cartel chain in return for fees and valuable block rewards.In conclusion, while it may not be feasible for one actor to gain a majority of hash power alone, collusion among a group of miners makes it possible. To ensure the continued security and integrity of the Bitcoin network, countermeasures must be put in place to prevent centralization of mining by force. Fullnodes need to be aware of the rules and reject any attempt to form a cartel. The ongoing discussion amongst those involved in Bitcoin development aims to address these concerns and find solutions that maintain the permissionless nature of mining. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Generalised-Replay-Protection-for-Future-Hard-Forks.xml b/static/bitcoin-dev/Nov_2017/combined_Generalised-Replay-Protection-for-Future-Hard-Forks.xml index 999a5b0ba0..9b6120486f 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Generalised-Replay-Protection-for-Future-Hard-Forks.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Generalised-Replay-Protection-for-Future-Hard-Forks.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Generalised Replay Protection for Future Hard Forks - 2023-08-01T22:07:26.488981+00:00 - - Jacob Eliosoff 2017-11-15 05:02:48+00:00 - - - Mats Jerratsch 2017-11-14 13:49:56+00:00 - - - Spartacus Rex 2017-11-13 17:02:07+00:00 - - - Jacob Eliosoff 2017-11-13 15:31:55+00:00 - - - Mats Jerratsch 2017-11-13 10:03:04+00:00 - - - Jacob Eliosoff 2017-11-11 05:18:11+00:00 - - - Mats Jerratsch 2017-11-10 11:28:06+00:00 - - - Sjors Provoost 2017-11-09 21:01:10+00:00 - - - Jacob Eliosoff 2017-11-09 20:45:43+00:00 - - - Mats Jerratsch 2017-11-08 16:45:01+00:00 - - - Jacob Eliosoff 2017-11-06 19:21:28+00:00 - - - Mats Jerratsch 2017-11-05 23:48:43+00:00 - + 2025-09-26T15:50:21.014102+00:00 + python-feedgen + + + [bitcoin-dev] Generalised Replay Protection for Future Hard Forks Mats Jerratsch + 2017-11-05T23:48:00.000Z + + + Jacob Eliosoff + 2017-11-06T19:21:00.000Z + + + Mats Jerratsch + 2017-11-08T16:45:00.000Z + + + Jacob Eliosoff + 2017-11-09T20:45:00.000Z + + + Sjors Provoost + 2017-11-09T21:01:00.000Z + + + Mats Jerratsch + 2017-11-10T11:28:00.000Z + + + Jacob Eliosoff + 2017-11-11T05:18:00.000Z + + + Mats Jerratsch + 2017-11-13T10:03:00.000Z + + + Jacob Eliosoff + 2017-11-13T15:31:00.000Z + + + Spartacus Rex + 2017-11-13T17:02:00.000Z + + + Mats Jerratsch + 2017-11-14T13:49:00.000Z + + + Jacob Eliosoff + 2017-11-15T05:02:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Generalised Replay Protection for Future Hard Forks - 2023-08-01T22:07:26.488981+00:00 + 2025-09-26T15:50:21.015602+00:00 - The email thread discusses a proposal for creating fork-specific addresses to enhance transaction safety and enable light clients to differentiate between multiple forks. The proposal suggests assigning a unique 'nForkId' to each leaf, which must match the 'nForkId' of the validating software for a transaction to be considered valid.However, there is a dilemma with LN commitment transactions where they either need to have a specific 'nForkId' or 'nForkId 0'. To address this, incorporating Luke's OP_CHECKBLOCKATHEIGHT and using solutions like SIGHASH_BLOCKCOMMIT are suggested.The proposed solution not only adds replay protection but also improves overall transaction safety by utilizing a dedicated address format per fork. This helps prevent issues like sending BCH to a BTC address. Every leaf must have a unique 'nForkId', and transactions are only deemed valid if their 'nForkId' matches exactly the 'nForkId' of the validating software.The discussion also touches on the use of nForkId in Lightning Network (LN) transactions. It is recommended to set 'nForkId>=1' for the funding transaction to protect it from replay attacks on past forks. For commitment transactions, 'nForkId=0' can be used, making it valid on all chains. However, users should be aware that the parent transaction it tries to spend (the funding transaction) only exists on two chains - the original one and the forked one.The conversation emphasizes the importance of implementing a generic replay protection scheme in advance to avoid breaking old transactions on one of the chains. It is suggested that 'nForkId=0' should be valid on all future forks. Additionally, different choices can be made in scenarios involving forks, such as creating commitment transactions with 'nForkId=0' or closing the payment channel on the new token after the fork.The proposal also considers using the human-readable part of the standard as the fork id and discusses potential limitations. It highlights the benefits of incorporating fork IDs into new address formats to provide comprehensive replay protection during hard forks.The proposed solution aims to address the issue of 'mis-sends' that could occur due to non-upgraded wallet software during hard forks. By including the token identifier in the address itself, mis-sends are made fundamentally impossible. However, there is a possibility of 'mis-receiving' if the receiving wallet is not aware of a newer chain and creates an address for the old token. This proposal allows wallets to distinguish between different tokens, enabling different implementations.The proposal advocates integrating replay protection into the protocol to prevent ad-hoc solutions and support non-hostile forks. It suggests utilizing a fork-specific incompatible address space to protect users from sending coins on the wrong chain. Light clients can enforce the use of 'nForkId' in the coinbase/block header or utilize a new P2P message type for sending transactions. The proposal also discusses the potential of allowing signatures with 'nForkId=1' through a soft fork by adjusting the script version of SegWit.In conclusion, the proposed solution provides a comprehensive approach to replay protection during hard forks and encourages developers to incorporate fork IDs into new address formats. It aims to enhance transaction safety, prevent mis-sends, and enable light clients to differentiate between multiple forks.The proposal suggests a solution for introducing forks without breaking existing clients by incrementing the script version of SegWit, ensuring full backwards compatibility. This approach can be generalized in software to include replay protection and a new address space. By implementing this method, forks can be introduced while maintaining the functionality of existing clients. The proposal highlights the potential for this approach to be applied across various software systems. 2017-11-15T05:02:48+00:00 + The email thread discusses a proposal for creating fork-specific addresses to enhance transaction safety and enable light clients to differentiate between multiple forks. The proposal suggests assigning a unique 'nForkId' to each leaf, which must match the 'nForkId' of the validating software for a transaction to be considered valid.However, there is a dilemma with LN commitment transactions where they either need to have a specific 'nForkId' or 'nForkId 0'. To address this, incorporating Luke's OP_CHECKBLOCKATHEIGHT and using solutions like SIGHASH_BLOCKCOMMIT are suggested.The proposed solution not only adds replay protection but also improves overall transaction safety by utilizing a dedicated address format per fork. This helps prevent issues like sending BCH to a BTC address. Every leaf must have a unique 'nForkId', and transactions are only deemed valid if their 'nForkId' matches exactly the 'nForkId' of the validating software.The discussion also touches on the use of nForkId in Lightning Network (LN) transactions. It is recommended to set 'nForkId>=1' for the funding transaction to protect it from replay attacks on past forks. For commitment transactions, 'nForkId=0' can be used, making it valid on all chains. However, users should be aware that the parent transaction it tries to spend (the funding transaction) only exists on two chains - the original one and the forked one.The conversation emphasizes the importance of implementing a generic replay protection scheme in advance to avoid breaking old transactions on one of the chains. It is suggested that 'nForkId=0' should be valid on all future forks. Additionally, different choices can be made in scenarios involving forks, such as creating commitment transactions with 'nForkId=0' or closing the payment channel on the new token after the fork.The proposal also considers using the human-readable part of the standard as the fork id and discusses potential limitations. It highlights the benefits of incorporating fork IDs into new address formats to provide comprehensive replay protection during hard forks.The proposed solution aims to address the issue of 'mis-sends' that could occur due to non-upgraded wallet software during hard forks. By including the token identifier in the address itself, mis-sends are made fundamentally impossible. However, there is a possibility of 'mis-receiving' if the receiving wallet is not aware of a newer chain and creates an address for the old token. This proposal allows wallets to distinguish between different tokens, enabling different implementations.The proposal advocates integrating replay protection into the protocol to prevent ad-hoc solutions and support non-hostile forks. It suggests utilizing a fork-specific incompatible address space to protect users from sending coins on the wrong chain. Light clients can enforce the use of 'nForkId' in the coinbase/block header or utilize a new P2P message type for sending transactions. The proposal also discusses the potential of allowing signatures with 'nForkId=1' through a soft fork by adjusting the script version of SegWit.In conclusion, the proposed solution provides a comprehensive approach to replay protection during hard forks and encourages developers to incorporate fork IDs into new address formats. It aims to enhance transaction safety, prevent mis-sends, and enable light clients to differentiate between multiple forks.The proposal suggests a solution for introducing forks without breaking existing clients by incrementing the script version of SegWit, ensuring full backwards compatibility. This approach can be generalized in software to include replay protection and a new address space. By implementing this method, forks can be introduced while maintaining the functionality of existing clients. The proposal highlights the potential for this approach to be applied across various software systems. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Introducing-a-POW-through-a-soft-fork.xml b/static/bitcoin-dev/Nov_2017/combined_Introducing-a-POW-through-a-soft-fork.xml index a13c507b34..7657d06059 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Introducing-a-POW-through-a-soft-fork.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Introducing-a-POW-through-a-soft-fork.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Introducing a POW through a soft-fork - 2023-08-01T22:05:29.659796+00:00 - - Eric Voskuil 2017-11-11 19:51:04+00:00 - - - Devrandom 2017-11-07 04:38:51+00:00 - - - Devrandom 2017-11-06 23:38:20+00:00 - - - Devrandom 2017-11-06 22:39:02+00:00 - - - Eric Voskuil 2017-11-06 20:55:29+00:00 - - - Paul Sztorc 2017-11-06 20:30:30+00:00 - - - Peter Todd 2017-11-06 19:50:00+00:00 - - - Devrandom 2017-11-03 01:02:25+00:00 - - - Tao Effect 2017-11-02 23:55:55+00:00 - - - Devrandom 2017-11-01 05:48:27+00:00 - + 2025-09-26T15:50:06.282497+00:00 + python-feedgen + + + [bitcoin-dev] Introducing a POW through a soft-fork Devrandom + 2017-11-01T05:48:00.000Z + + + Tao Effect + 2017-11-02T23:55:00.000Z + + + Devrandom + 2017-11-03T01:02:00.000Z + + + Peter Todd + 2017-11-06T19:50:00.000Z + + + Paul Sztorc + 2017-11-06T20:30:00.000Z + + + Eric Voskuil + 2017-11-06T20:55:00.000Z + + + Devrandom + 2017-11-06T22:39:00.000Z + + + Devrandom + 2017-11-06T23:38:00.000Z + + + Devrandom + 2017-11-07T04:38:00.000Z + + + Eric Voskuil + 2017-11-11T19:51:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Introducing a POW through a soft-fork - 2023-08-01T22:05:29.659796+00:00 + 2025-09-26T15:50:06.283613+00:00 - In a recent discussion on the bitcoin-dev mailing list, a proposal was made to introduce a new Proof of Work (POW) system through a soft-fork. However, some participants argued that it should be considered a "pseudo-soft-fork" due to its different security model. The proposed change involves introducing auxiliary POW blocks between normal blocks, with each aux-POW block pointing to the previous normal block and containing transactions like a normal block. Each normal block would also have to point to the previous aux-POW block and contain all transactions from that block.The proposal aims to mitigate centralization pressures and reduce the impact of mining power fluctuations by introducing an intermediary confirmation point. This would allow cooperative miners to migrate over time and prevent economies of scale. The new POW system would be gradually transitioned over a period of 1-3 years, giving nodes ample time to upgrade after the fork activates. However, it is important to note that non-upgraded nodes may end up on the wrong chain during an attack, making this change a semi-hard fork.There are also security implications to consider, such as increased orphan rates resulting from decreased block intervals. Some participants argue that the orphan rate would remain unchanged since the total transaction rate and block size would remain the same. However, others point out that the expected time to find each type of block would be halved, leading to a doubling of the orphan rate.Experts like Peter Todd and Paul Sztorc have reviewed the proposal and provided valuable insights. Todd argues that the proposal should be called a "pseudo-soft-fork" due to its different security model, while Sztorc agrees with Todd's comments. The discussion also touches on the choice of a suitable POW, potential pitfalls including botnet mining and unexpected optimizations, and the need for deep analysis.Overall, the proposal aims to introduce a new POW system while reducing the risk of a hard-fork. It acknowledges the challenges and potential drawbacks but offers a less disruptive approach by allowing for gradual transitions. Further evaluation and analysis are needed to determine the feasibility and effectiveness of this proposed change. 2017-11-11T19:51:04+00:00 + In a recent discussion on the bitcoin-dev mailing list, a proposal was made to introduce a new Proof of Work (POW) system through a soft-fork. However, some participants argued that it should be considered a "pseudo-soft-fork" due to its different security model. The proposed change involves introducing auxiliary POW blocks between normal blocks, with each aux-POW block pointing to the previous normal block and containing transactions like a normal block. Each normal block would also have to point to the previous aux-POW block and contain all transactions from that block.The proposal aims to mitigate centralization pressures and reduce the impact of mining power fluctuations by introducing an intermediary confirmation point. This would allow cooperative miners to migrate over time and prevent economies of scale. The new POW system would be gradually transitioned over a period of 1-3 years, giving nodes ample time to upgrade after the fork activates. However, it is important to note that non-upgraded nodes may end up on the wrong chain during an attack, making this change a semi-hard fork.There are also security implications to consider, such as increased orphan rates resulting from decreased block intervals. Some participants argue that the orphan rate would remain unchanged since the total transaction rate and block size would remain the same. However, others point out that the expected time to find each type of block would be halved, leading to a doubling of the orphan rate.Experts like Peter Todd and Paul Sztorc have reviewed the proposal and provided valuable insights. Todd argues that the proposal should be called a "pseudo-soft-fork" due to its different security model, while Sztorc agrees with Todd's comments. The discussion also touches on the choice of a suitable POW, potential pitfalls including botnet mining and unexpected optimizations, and the need for deep analysis.Overall, the proposal aims to introduce a new POW system while reducing the risk of a hard-fork. It acknowledges the challenges and potential drawbacks but offers a less disruptive approach by allowing for gradual transitions. Further evaluation and analysis are needed to determine the feasibility and effectiveness of this proposed change. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Making-OP-CODESEPARATOR-and-FindAndDelete-in-non-segwit-scripts-non-standard.xml b/static/bitcoin-dev/Nov_2017/combined_Making-OP-CODESEPARATOR-and-FindAndDelete-in-non-segwit-scripts-non-standard.xml index 63333a8199..04577dfe4d 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Making-OP-CODESEPARATOR-and-FindAndDelete-in-non-segwit-scripts-non-standard.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Making-OP-CODESEPARATOR-and-FindAndDelete-in-non-segwit-scripts-non-standard.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard - 2023-08-01T22:09:01.849226+00:00 - - Matt Corallo 2017-11-27 21:33:37+00:00 - - - Mark Friedenbach 2017-11-27 21:06:35+00:00 - - - Matt Corallo 2017-11-27 16:33:07+00:00 - - - Sjors Provoost 2017-11-16 09:27:18+00:00 - - - Mark Friedenbach 2017-11-15 19:54:17+00:00 - - - Johnson Lau 2017-11-15 18:02:48+00:00 - + 2025-09-26T15:50:08.374241+00:00 + python-feedgen + + + [bitcoin-dev] Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard Johnson Lau + 2017-11-15T18:02:00.000Z + + + Mark Friedenbach + 2017-11-15T19:54:00.000Z + + + Sjors Provoost + 2017-11-16T09:27:00.000Z + + + Matt Corallo + 2017-11-27T16:33:00.000Z + + + Mark Friedenbach + 2017-11-27T21:06:00.000Z + + + Matt Corallo + 2017-11-27T21:33:00.000Z + + - python-feedgen + 2 Combined summary - Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard - 2023-08-01T22:09:01.849226+00:00 + 2025-09-26T15:50:08.375120+00:00 - The Bitcoin community is currently discussing the proposal to make OP_CODESEPARATOR and FindAndDelete non-standard in non-segwit scripts. These functions are considered to be useless and complicated, falling outside of best practices. The aim of this proposal is to discourage their use, but there are concerns about potentially destroying value and leaving pre-signed transactions vulnerable.Matt Corallo suggests that soft-forking behavior into OP_NOPs or nSequence could be a useful approach to make the code more secure. However, he strongly disagrees with only soft-forking out transactions that are "fundamentally insecure," arguing that we should be willing to soft-fork out things that clearly fall outside of best practices.Mark Friedenbach raises concerns about removing these features unless they are fundamentally insecure and vulnerable. Johnson Lau proposes that disabling both functions would ensure that scriptCode serialized inside SignatureHash() must be constant. If a soft-fork is used to remove FindAndDelete() and OP_CODESEPARATOR from non-segwit scripts, all blocks before the softfork block can be whitelisted to completely remove FindAndDelete() from the consensus code later.The proposal to make OP_CODESEPARATOR and FindAndDelete non-standard in non-segwit scripts has been met with mixed opinions. While some argue that making them non-standard is a good change to discourage their use and better inform discussions, others raise concerns about potential value destruction and unknown pre-signed transactions utilizing these features. The debate also revolves around whether soft-forking out only fundamentally insecure transactions is sufficient or if features falling outside of best practices should also be considered for removal.Overall, the proposal aims to set clear best practices and improve the security of the bitcoin protocol. Soft-forking out these features would require a significant time frame, giving users who rely on them an opportunity to object and reconsider the soft-fork. The discussion continues on the bitcoin-dev mailing list, with different perspectives and suggestions being put forward. 2017-11-27T21:33:37+00:00 + The Bitcoin community is currently discussing the proposal to make OP_CODESEPARATOR and FindAndDelete non-standard in non-segwit scripts. These functions are considered to be useless and complicated, falling outside of best practices. The aim of this proposal is to discourage their use, but there are concerns about potentially destroying value and leaving pre-signed transactions vulnerable.Matt Corallo suggests that soft-forking behavior into OP_NOPs or nSequence could be a useful approach to make the code more secure. However, he strongly disagrees with only soft-forking out transactions that are "fundamentally insecure," arguing that we should be willing to soft-fork out things that clearly fall outside of best practices.Mark Friedenbach raises concerns about removing these features unless they are fundamentally insecure and vulnerable. Johnson Lau proposes that disabling both functions would ensure that scriptCode serialized inside SignatureHash() must be constant. If a soft-fork is used to remove FindAndDelete() and OP_CODESEPARATOR from non-segwit scripts, all blocks before the softfork block can be whitelisted to completely remove FindAndDelete() from the consensus code later.The proposal to make OP_CODESEPARATOR and FindAndDelete non-standard in non-segwit scripts has been met with mixed opinions. While some argue that making them non-standard is a good change to discourage their use and better inform discussions, others raise concerns about potential value destruction and unknown pre-signed transactions utilizing these features. The debate also revolves around whether soft-forking out only fundamentally insecure transactions is sufficient or if features falling outside of best practices should also be considered for removal.Overall, the proposal aims to set clear best practices and improve the security of the bitcoin protocol. Soft-forking out these features would require a significant time frame, giving users who rely on them an opportunity to object and reconsider the soft-fork. The discussion continues on the bitcoin-dev mailing list, with different perspectives and suggestions being put forward. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml b/static/bitcoin-dev/Nov_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml index 1e6e0cffe8..78e6feeb04 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml @@ -1,59 +1,167 @@ - + 2 Combined summary - Merkle branch verification & tail-call semantics for generalized MAST - 2023-08-01T21:47:30.334441+00:00 - - Luke Dashjr 2017-11-04 07:59:07+00:00 - - - Mark Friedenbach 2017-11-01 15:08:46+00:00 - - - Luke Dashjr 2017-11-01 08:43:48+00:00 - - - Mark Friedenbach 2017-10-28 04:40:01+00:00 - - - Russell O'Connor 2017-10-02 17:15:38+00:00 - - - Mark Friedenbach 2017-09-30 23:51:49+00:00 - - - Luke Dashjr 2017-09-30 23:23:32+00:00 - - - Mark Friedenbach 2017-09-19 00:46:30+00:00 - - - Peter Todd 2017-09-13 09:41:07+00:00 - - - Karl Johan Alm 2017-09-12 23:27:36+00:00 - - - Mark Friedenbach 2017-09-12 19:57:10+00:00 - - - Johnson Lau 2017-09-12 08:55:59+00:00 - - - Bryan Bishop 2017-09-12 02:13:24+00:00 - - - Mark Friedenbach 2017-09-12 02:03:42+00:00 - - - Adán Sánchez de Pedro Crespo 2017-09-11 20:37:55+00:00 - - - Johnson Lau 2017-09-08 09:21:22+00:00 - - - Mark Friedenbach 2017-09-07 00:38:55+00:00 - + 2025-09-26T15:50:10.496791+00:00 + python-feedgen + + + [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Mark Friedenbach + 2017-09-07T00:38:00.000Z + + + Johnson Lau + 2017-09-08T09:21:00.000Z + + + Adán Sánchez de Pedro Crespo + 2017-09-11T20:37:00.000Z + + + Mark Friedenbach + 2017-09-12T02:03:00.000Z + + + Bryan Bishop + 2017-09-12T02:13:00.000Z + + + Johnson Lau + 2017-09-12T08:55:00.000Z + + + Mark Friedenbach + 2017-09-12T19:57:00.000Z + + + Karl Johan Alm + 2017-09-12T23:27:00.000Z + + + Peter Todd + 2017-09-13T09:41:00.000Z + + + Mark Friedenbach + 2017-09-19T00:46:00.000Z + + + [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Luke Dashjr + 2017-09-19T03:09:00.000Z + + + Mark Friedenbach + 2017-09-19T07:33:00.000Z + + + [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Johnson Lau + 2017-09-20T05:13:00.000Z + + + Mark Friedenbach + 2017-09-20T19:29:00.000Z + + + Johnson Lau + 2017-09-21T03:58:00.000Z + + + Luke Dashjr + 2017-09-21T04:11:00.000Z + + + Johnson Lau + 2017-09-21T08:02:00.000Z + + + Luke Dashjr + 2017-09-21T16:33:00.000Z + + + Johnson Lau + 2017-09-21T17:38:00.000Z + + + Sergio Demian Lerner + 2017-09-22T20:32:00.000Z + + + Mark Friedenbach + 2017-09-22T21:11:00.000Z + + + Sergio Demian Lerner + 2017-09-22T21:32:00.000Z + + + Mark Friedenbach + 2017-09-22T21:39:00.000Z + + + Sergio Demian Lerner + 2017-09-22T21:54:00.000Z + + + Mark Friedenbach + 2017-09-22T22:07:00.000Z + + + Pieter Wuille + 2017-09-22T22:09:00.000Z + + + [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Luke Dashjr + 2017-09-30T23:23:00.000Z + + + Mark Friedenbach + 2017-09-30T23:51:00.000Z + + + Russell O'Connor + 2017-10-02T17:15:00.000Z + + + Mark Friedenbach + 2017-10-28T04:40:00.000Z + + + Luke Dashjr + 2017-11-01T08:43:00.000Z + + + Mark Friedenbach + 2017-11-01T15:08:00.000Z + + + Luke Dashjr + 2017-11-04T07:59:00.000Z + + + [bitcoin-dev] maximum block height on transaction Erik Aronesty + 2021-04-09T08:15:00.000Z + + + Russell O'Connor + 2021-04-09T11:39:00.000Z + + + Jeremy + 2021-04-09T15:54:00.000Z + + + Billy Tetrud + 2021-04-12T20:04:00.000Z + + + ZmnSCPxj + 2021-04-16T04:24:00.000Z + + + ZmnSCPxj + 2021-05-03T02:30:00.000Z + + @@ -71,13 +179,13 @@ - python-feedgen + 2 Combined summary - Merkle branch verification & tail-call semantics for generalized MAST - 2023-08-01T21:47:30.334441+00:00 + 2025-09-26T15:50:10.500938+00:00 - During a discussion on the bitcoin-dev mailing list, Mark Friedenbach and Johnson Lau discussed the use of OP_CHECKSIGADD and its vulnerability to Denial of Service (DoS) attacks. Friedenbach suggested using a new witness version instead, but Lau raised concerns about potential slowness. They debated design decisions for a new witness version, including tree signatures and MAST. The use of limits to prevent DoS attacks was also discussed, with Friedenbach proposing committing the total validation cost as the first witness stack item. He argued that the cost of implementing such changes would be worth it. Friedenbach also proposed an alternative solution involving removing certain lines of code from interpreter.cpp. Both proposals had different pros and cons and should not be purposefully restricted to compare head to head.Friedenbach apologized for the delay in responding to emails due to a cold. Lau had pointed out that tail-call execution semantics require an "unclean stack", which is invalid in BIP141. A new witness version could be used instead. Friedenbach disagreed with the current SigOp counting method used by Bitcoin, suggesting a single linear metric that combines all factors with appropriate coefficients. He proposed having the witness commit to the maximum resources consumed by validation of the spend of the coin. Maintaining static analysability for global limits was deemed important to prevent attacks on relay and mining nodes. There was also a suggestion to re-evaluate the need for counting SigOps other than for legacy consensus rule compliance. Witness script versioning was noted to be fully compatible with P2SH and BIP173. The minimal BIP114 solution could involve hiding scripts in a hash. A repository containing the latest implementation of BIP 114 can be found on GitHub.The email thread also included discussions about tail-call execution semantics, unclosed stacks, SigOp counting, and witness script versioning. Friedenbach highlighted an error regarding an "unclean stack" in a participant's comment. This mistake was also pointed out at the recent CoreDev meetup. The complexity of the BIP114 implementation was questioned, and there was a query regarding the availability of a repository for the latest BIP 114 implementation. Links to the original BIP114 and its revised versions were provided.In another discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed two new features to be added to the Bitcoin protocol via soft-fork activation. These features are MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics. MBV allows script authors to force redemption to use values selected from a pre-determined set committed to in the scriptPubKey, without revealing unused elements in the set for enhanced privacy and smaller script sizes. Tail-call execution semantics allow a single level of recursion into a subscript, providing properties similar to P2SH while being more flexible. Friedenbach believed that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects.During a discussion about the MAST proposal, there was a suggestion to have different opcodes for single vs multi-element MBV for script analysis purposes. However, it was countered that static analysability can be maintained if the script encodes the number of elements as an integer push to the top of the stack immediately before the opcode. Mark Friedenbach was assigned the task of investigating an ideal serialization format for a multi-element proof, which is the only thing holding back a multi-element MBV proposal. The discussion also touched on tail-call semantics, script version upgrades, and other related issues.Overall, Mark Friedenbach has proposed two new features, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics, to be added to the Bitcoin protocol. These features provide enhanced privacy, smaller script sizes, and flexibility in script execution. Friedenbach believes that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects. 2017-11-04T07:59:07+00:00 + During a discussion on the bitcoin-dev mailing list, Mark Friedenbach and Johnson Lau discussed the use of OP_CHECKSIGADD and its vulnerability to Denial of Service (DoS) attacks. Friedenbach suggested using a new witness version instead, but Lau raised concerns about potential slowness. They debated design decisions for a new witness version, including tree signatures and MAST. The use of limits to prevent DoS attacks was also discussed, with Friedenbach proposing committing the total validation cost as the first witness stack item. He argued that the cost of implementing such changes would be worth it. Friedenbach also proposed an alternative solution involving removing certain lines of code from interpreter.cpp. Both proposals had different pros and cons and should not be purposefully restricted to compare head to head.Friedenbach apologized for the delay in responding to emails due to a cold. Lau had pointed out that tail-call execution semantics require an "unclean stack", which is invalid in BIP141. A new witness version could be used instead. Friedenbach disagreed with the current SigOp counting method used by Bitcoin, suggesting a single linear metric that combines all factors with appropriate coefficients. He proposed having the witness commit to the maximum resources consumed by validation of the spend of the coin. Maintaining static analysability for global limits was deemed important to prevent attacks on relay and mining nodes. There was also a suggestion to re-evaluate the need for counting SigOps other than for legacy consensus rule compliance. Witness script versioning was noted to be fully compatible with P2SH and BIP173. The minimal BIP114 solution could involve hiding scripts in a hash. A repository containing the latest implementation of BIP 114 can be found on GitHub.The email thread also included discussions about tail-call execution semantics, unclosed stacks, SigOp counting, and witness script versioning. Friedenbach highlighted an error regarding an "unclean stack" in a participant's comment. This mistake was also pointed out at the recent CoreDev meetup. The complexity of the BIP114 implementation was questioned, and there was a query regarding the availability of a repository for the latest BIP 114 implementation. Links to the original BIP114 and its revised versions were provided.In another discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed two new features to be added to the Bitcoin protocol via soft-fork activation. These features are MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics. MBV allows script authors to force redemption to use values selected from a pre-determined set committed to in the scriptPubKey, without revealing unused elements in the set for enhanced privacy and smaller script sizes. Tail-call execution semantics allow a single level of recursion into a subscript, providing properties similar to P2SH while being more flexible. Friedenbach believed that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects.During a discussion about the MAST proposal, there was a suggestion to have different opcodes for single vs multi-element MBV for script analysis purposes. However, it was countered that static analysability can be maintained if the script encodes the number of elements as an integer push to the top of the stack immediately before the opcode. Mark Friedenbach was assigned the task of investigating an ideal serialization format for a multi-element proof, which is the only thing holding back a multi-element MBV proposal. The discussion also touched on tail-call semantics, script version upgrades, and other related issues.Overall, Mark Friedenbach has proposed two new features, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics, to be added to the Bitcoin protocol. These features provide enhanced privacy, smaller script sizes, and flexibility in script execution. Friedenbach believes that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Proposal-allocate-Github-issue-instead-of-wiki-page-to-BIP-discussion.xml b/static/bitcoin-dev/Nov_2017/combined_Proposal-allocate-Github-issue-instead-of-wiki-page-to-BIP-discussion.xml index e3b9bba107..e7c2fc1c27 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Proposal-allocate-Github-issue-instead-of-wiki-page-to-BIP-discussion.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Proposal-allocate-Github-issue-instead-of-wiki-page-to-BIP-discussion.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Proposal: allocate Github issue instead of wiki page to BIP discussion - 2023-08-01T22:06:30.425624+00:00 - - Aymeric Vitte 2017-11-03 18:15:10+00:00 - - - Sjors Provoost 2017-11-03 09:50:15+00:00 - + 2025-09-26T15:50:02.085213+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: allocate Github issue instead of wiki page to BIP discussion Sjors Provoost + 2017-11-03T09:50:00.000Z + + + Aymeric Vitte + 2017-11-03T18:15:00.000Z + + - python-feedgen + 2 Combined summary - Proposal: allocate Github issue instead of wiki page to BIP discussion - 2023-08-01T22:06:30.425624+00:00 + 2025-09-26T15:50:02.085675+00:00 - In a recent post on the bitcoin-dev mailing list, Sjors Provoost put forward a suggestion to enable Github issues for Bitcoin Improvement Proposals (BIPs). Currently, discussions on BIPs take place on wiki pages, but leaving comments requires editing the page. Provoost argues that using Github issues would streamline the commenting process and make it more efficient. However, there are concerns about diverting discussion away from the mailing list and potential confusion between pull requests and discussion issues.The author of the post acknowledges that the current method of leaving comments on BIPs, through wiki pages, can be cumbersome and in need of improvement. To address this, they propose utilizing Github issues for each BIP. By linking each BIP's wiki page to a corresponding issue on Github, it would provide an easier way for individuals to leave comments, especially for smaller BIPs that may not warrant extensive discussion on the mailing list. However, one concern raised is that the introduction of Github issues might lead to a shift in discussion away from the mailing list. To mitigate this, the author suggests temporarily locking the issue to prevent further comments and ensuring that the main discussion still takes place on the mailing list. Another potential issue is the confusion that could arise between pull requests and the discussion issues on Github.To address these concerns, the author seeks clarification on the next steps if the community agrees with the idea. They inquire whether proposing a change to the existing commenting process or creating a new BIP altogether would be the appropriate course of action.In summary, Sjors Provoost proposes enabling Github issues for Bitcoin Improvement Proposals (BIPs) to improve the commenting process. While acknowledging the current clunkiness of using wiki pages for discussion, there are concerns about diverting discussion away from the mailing list and confusion between pull requests and discussion issues on Github. The author seeks guidance on the next steps if the community supports the idea, whether it involves proposing a change or creating a new BIP. 2017-11-03T18:15:10+00:00 + In a recent post on the bitcoin-dev mailing list, Sjors Provoost put forward a suggestion to enable Github issues for Bitcoin Improvement Proposals (BIPs). Currently, discussions on BIPs take place on wiki pages, but leaving comments requires editing the page. Provoost argues that using Github issues would streamline the commenting process and make it more efficient. However, there are concerns about diverting discussion away from the mailing list and potential confusion between pull requests and discussion issues.The author of the post acknowledges that the current method of leaving comments on BIPs, through wiki pages, can be cumbersome and in need of improvement. To address this, they propose utilizing Github issues for each BIP. By linking each BIP's wiki page to a corresponding issue on Github, it would provide an easier way for individuals to leave comments, especially for smaller BIPs that may not warrant extensive discussion on the mailing list. However, one concern raised is that the introduction of Github issues might lead to a shift in discussion away from the mailing list. To mitigate this, the author suggests temporarily locking the issue to prevent further comments and ensuring that the main discussion still takes place on the mailing list. Another potential issue is the confusion that could arise between pull requests and the discussion issues on Github.To address these concerns, the author seeks clarification on the next steps if the community agrees with the idea. They inquire whether proposing a change to the existing commenting process or creating a new BIP altogether would be the appropriate course of action.In summary, Sjors Provoost proposes enabling Github issues for Bitcoin Improvement Proposals (BIPs) to improve the commenting process. While acknowledging the current clunkiness of using wiki pages for discussion, there are concerns about diverting discussion away from the mailing list and confusion between pull requests and discussion issues on Github. The author seeks guidance on the next steps if the community supports the idea, whether it involves proposing a change or creating a new BIP. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Protocol-Level-Pruning.xml b/static/bitcoin-dev/Nov_2017/combined_Protocol-Level-Pruning.xml index 875ded24ac..f9b0a055c9 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Protocol-Level-Pruning.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Protocol-Level-Pruning.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Protocol-Level Pruning - 2023-08-01T22:09:26.599740+00:00 - - William Casarin 2017-11-17 19:07:04+00:00 - - - Marc Bevand 2017-11-16 17:19:13+00:00 - - - Bryan Bishop 2017-11-16 17:14:47+00:00 - - - Marc Bevand 2017-11-16 16:56:46+00:00 - + 2025-09-26T15:50:04.180042+00:00 + python-feedgen + + + [bitcoin-dev] Protocol-Level Pruning Marc Bevand + 2017-11-16T16:56:00.000Z + + + Bryan Bishop + 2017-11-16T17:14:00.000Z + + + Marc Bevand + 2017-11-16T17:19:00.000Z + + + William Casarin + 2017-11-17T19:07:00.000Z + + - python-feedgen + 2 Combined summary - Protocol-Level Pruning - 2023-08-01T22:09:26.599740+00:00 + 2025-09-26T15:50:04.180681+00:00 - Bryan Bishop, a Bitcoin developer, recently shared his thoughts on UTXO set commitment proposals in a bitcoin-dev post. He provided various links to resources such as previous discussions, bitfields, and source code proposals related to delayed TXO commitments, rolling UTXO set hashes, and the usefulness of TXO commitments. However, Bryan acknowledged that he was uncertain whether the recipient of his message had already explored these proposals. In conclusion, he posed a question about the possibility of categorizing these discussions by topic for easier accessibility.In response to an email from Marc, who expressed interest in a seemingly simple idea that may have already been discussed, Bryan shared several links to previous proposals for UTXO set commitment. These proposals included TXO bitfields, delayed TXO commitments, rolling UTXO set hashes, and more. Additionally, he mentioned the availability of numerous other resources, including source code proposals. Bryan's contact information, including his website and phone number, was also provided in his email signature.It appears that the speaker, Bryan, is unsure if the recipient has reviewed prior UTXO set commitment proposals. Consequently, they offer bookmarks pertaining to UTXO set commitments, TXO bitfields, delayed TXO commitments, the usefulness of TXO commitments without requiring a soft-fork, and rolling UTXO set hashes. They further note the existence of additional resources, such as source code proposals. Bryan introduces himself by name and provides his website and phone number for contact purposes.Marc, another Bitcoin developer, introduced the concept of protocol-level pruning (PLP) as a means to significantly reduce the size of the blockchain and facilitate on-chain scaling. The idea involves serializing the UTXO set in a standardized manner and publishing its hash in the block header, thereby committing the blockchain to it. When a new node joins the network, it would solely download the block headers and identify the most recent block containing the UTXO set hash, subsequently obtaining the UTXO set from peers. Nodes would serialize and verify that their UTXO set hash matches the one published in the blockchain every 576 blocks. Currently, the serialized UTXO set occupies approximately 3GB, while the entire blockchain amounts to about 150GB. Hence, implementing PLP could reduce the data stored by full nodes by a factor of roughly 50. To avoid hashing the complete UTXO set every 576 blocks, the UTXO set serialization could be accomplished using a sparse Merkle tree, enabling on-the-fly recomputation of the hash as new blocks are mined. Although a regular Merkle tree could suffice, sparse Merkle trees offer greater efficiency. With PLP, all full nodes within the network could transition to this approach without the need for any node to archive the entire blockchain. However, these nodes would no longer be capable of handling reorganizations that extend beyond the last UTXO set hash published on the chain since prior blocks have been discarded. Consequently, it may be sufficient to retain the last N*576 blocks (where N=10?) as a workaround. 2017-11-17T19:07:04+00:00 + Bryan Bishop, a Bitcoin developer, recently shared his thoughts on UTXO set commitment proposals in a bitcoin-dev post. He provided various links to resources such as previous discussions, bitfields, and source code proposals related to delayed TXO commitments, rolling UTXO set hashes, and the usefulness of TXO commitments. However, Bryan acknowledged that he was uncertain whether the recipient of his message had already explored these proposals. In conclusion, he posed a question about the possibility of categorizing these discussions by topic for easier accessibility.In response to an email from Marc, who expressed interest in a seemingly simple idea that may have already been discussed, Bryan shared several links to previous proposals for UTXO set commitment. These proposals included TXO bitfields, delayed TXO commitments, rolling UTXO set hashes, and more. Additionally, he mentioned the availability of numerous other resources, including source code proposals. Bryan's contact information, including his website and phone number, was also provided in his email signature.It appears that the speaker, Bryan, is unsure if the recipient has reviewed prior UTXO set commitment proposals. Consequently, they offer bookmarks pertaining to UTXO set commitments, TXO bitfields, delayed TXO commitments, the usefulness of TXO commitments without requiring a soft-fork, and rolling UTXO set hashes. They further note the existence of additional resources, such as source code proposals. Bryan introduces himself by name and provides his website and phone number for contact purposes.Marc, another Bitcoin developer, introduced the concept of protocol-level pruning (PLP) as a means to significantly reduce the size of the blockchain and facilitate on-chain scaling. The idea involves serializing the UTXO set in a standardized manner and publishing its hash in the block header, thereby committing the blockchain to it. When a new node joins the network, it would solely download the block headers and identify the most recent block containing the UTXO set hash, subsequently obtaining the UTXO set from peers. Nodes would serialize and verify that their UTXO set hash matches the one published in the blockchain every 576 blocks. Currently, the serialized UTXO set occupies approximately 3GB, while the entire blockchain amounts to about 150GB. Hence, implementing PLP could reduce the data stored by full nodes by a factor of roughly 50. To avoid hashing the complete UTXO set every 576 blocks, the UTXO set serialization could be accomplished using a sparse Merkle tree, enabling on-the-fly recomputation of the hash as new blocks are mined. Although a regular Merkle tree could suffice, sparse Merkle trees offer greater efficiency. With PLP, all full nodes within the network could transition to this approach without the need for any node to archive the entire blockchain. However, these nodes would no longer be capable of handling reorganizations that extend beyond the last UTXO set hash published on the chain since prior blocks have been discarded. Consequently, it may be sufficient to retain the last N*576 blocks (where N=10?) as a workaround. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Simplicity-An-alternative-to-Script.xml b/static/bitcoin-dev/Nov_2017/combined_Simplicity-An-alternative-to-Script.xml index 40801ea01c..f1d4b4febc 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Simplicity-An-alternative-to-Script.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Simplicity-An-alternative-to-Script.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Simplicity: An alternative to Script - 2023-08-01T22:04:38.991234+00:00 - - Mark Friedenbach 2017-11-01 01:46:54+00:00 - - - Russell O'Connor 2017-10-31 21:01:05+00:00 - - - Mark Friedenbach 2017-10-31 20:46:49+00:00 - - - Russell O'Connor 2017-10-31 20:38:16+00:00 - - - Gregory Maxwell 2017-10-30 23:29:28+00:00 - - - Matt Corallo 2017-10-30 22:50:04+00:00 - - - Mark Friedenbach 2017-10-30 22:32:42+00:00 - - - Matt Corallo 2017-10-30 22:14:44+00:00 - - - Mark Friedenbach 2017-10-30 21:56:00+00:00 - - - Matt Corallo 2017-10-30 21:42:44+00:00 - - - Mark Friedenbach 2017-10-30 15:31:22+00:00 - - - Russell O'Connor 2017-10-30 15:22:20+00:00 - + 2025-09-26T15:50:23.132809+00:00 + python-feedgen + + + [bitcoin-dev] Simplicity: An alternative to Script Russell O'Connor + 2017-10-30T15:22:00.000Z + + + Mark Friedenbach + 2017-10-30T15:31:00.000Z + + + Matt Corallo + 2017-10-30T21:42:00.000Z + + + Mark Friedenbach + 2017-10-30T21:56:00.000Z + + + Matt Corallo + 2017-10-30T22:14:00.000Z + + + Mark Friedenbach + 2017-10-30T22:32:00.000Z + + + Matt Corallo + 2017-10-30T22:50:00.000Z + + + Gregory Maxwell + 2017-10-30T23:29:00.000Z + + + Russell O'Connor + 2017-10-31T20:38:00.000Z + + + Mark Friedenbach + 2017-10-31T20:46:00.000Z + + + Russell O'Connor + 2017-10-31T21:01:00.000Z + + + Mark Friedenbach + 2017-11-01T01:46:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Simplicity: An alternative to Script - 2023-08-01T22:04:38.992239+00:00 + 2025-09-26T15:50:23.134306+00:00 - Russell O'Connor, a Bitcoin developer, has proposed an alternative to Bitcoin Script called Simplicity. This language is a low-level, typed, functional, native MAST language designed to operate at the consensus layer. Simplicity comes with formal denotational semantics and operational semantics that have been proven equivalent in the Coq proof assistant. The language also includes easy-to-compute static analyses that can calculate bounds on space and time resources needed for evaluation.Simplicity is still in the research and development phase, but it is anticipated that jets will replace common Simplicity expressions with C code to reduce the sigops/weight/fee-cost of transactions. These jets will cover arithmetic operations, elliptic curve operations, and cryptographic operations including hashing and digital signature validation. The final design of Simplicity includes full convent support, support for signature aggregation, and support for delegation.The author plans to develop a broad set of useful jets covering arithmetic operations, elliptic curve operations, and cryptographic operations. Simplicity's denotational semantics do not imply an order of operations, but the author plans to address this by using Luke's fail-success-on-unknown-operation. The language also includes extensions such as full convent support, signature aggregation, and delegation.The author is working on producing an SDK that will include formal semantics, correctness proofs, a Haskell implementation, and a C interpreter for Simplicity. After the SDK is complete, Simplicity will be made available in the Elements project for experimentation in sidechains. However, it will only be considered for inclusion in Bitcoin after extensive vetting.In a recent bitcoin-dev email thread, there were discussions about how to deal with "jets" in Bitcoin. One proposal suggested using discounted jets for scripting. Another proposal suggested using script versions to encode optimized jets and their costs. These proposals are independent of Simplicity but can be applied to it.Overall, Simplicity is a promising alternative to Bitcoin Script, offering a low-level, typed, functional, and native MAST language with formal denotational and operational semantics. It aims to enhance privacy and reduce resource costs through branch pruning and the use of jets. The author is actively working on developing the language further and plans to make it available for experimentation in sidechains. However, more research and vetting are needed before considering Simplicity for inclusion in Bitcoin. O'Connor emphasized that this work is not intended to delay consideration of the various Merkelized Script proposals currently ongoing. 2017-11-01T01:46:54+00:00 + Russell O'Connor, a Bitcoin developer, has proposed an alternative to Bitcoin Script called Simplicity. This language is a low-level, typed, functional, native MAST language designed to operate at the consensus layer. Simplicity comes with formal denotational semantics and operational semantics that have been proven equivalent in the Coq proof assistant. The language also includes easy-to-compute static analyses that can calculate bounds on space and time resources needed for evaluation.Simplicity is still in the research and development phase, but it is anticipated that jets will replace common Simplicity expressions with C code to reduce the sigops/weight/fee-cost of transactions. These jets will cover arithmetic operations, elliptic curve operations, and cryptographic operations including hashing and digital signature validation. The final design of Simplicity includes full convent support, support for signature aggregation, and support for delegation.The author plans to develop a broad set of useful jets covering arithmetic operations, elliptic curve operations, and cryptographic operations. Simplicity's denotational semantics do not imply an order of operations, but the author plans to address this by using Luke's fail-success-on-unknown-operation. The language also includes extensions such as full convent support, signature aggregation, and delegation.The author is working on producing an SDK that will include formal semantics, correctness proofs, a Haskell implementation, and a C interpreter for Simplicity. After the SDK is complete, Simplicity will be made available in the Elements project for experimentation in sidechains. However, it will only be considered for inclusion in Bitcoin after extensive vetting.In a recent bitcoin-dev email thread, there were discussions about how to deal with "jets" in Bitcoin. One proposal suggested using discounted jets for scripting. Another proposal suggested using script versions to encode optimized jets and their costs. These proposals are independent of Simplicity but can be applied to it.Overall, Simplicity is a promising alternative to Bitcoin Script, offering a low-level, typed, functional, and native MAST language with formal denotational and operational semantics. It aims to enhance privacy and reduce resource costs through branch pruning and the use of jets. The author is actively working on developing the language further and plans to make it available for experimentation in sidechains. However, more research and vetting are needed before considering Simplicity for inclusion in Bitcoin. O'Connor emphasized that this work is not intended to delay consideration of the various Merkelized Script proposals currently ongoing. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Simplicity-proposal-Jets-.xml b/static/bitcoin-dev/Nov_2017/combined_Simplicity-proposal-Jets-.xml index 64d6c676a6..b1fc40e6c6 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Simplicity-proposal-Jets-.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Simplicity-proposal-Jets-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Simplicity proposal - Jets? - 2023-08-01T22:05:54.451476+00:00 + 2025-09-26T15:50:14.704175+00:00 + python-feedgen Adán Sánchez de Pedro Crespo 2017-11-03 16:42:38+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Simplicity proposal - Jets? - 2023-08-01T22:05:54.451476+00:00 + 2025-09-26T15:50:14.704352+00:00 - The Simplicity proposal introduces the concept of "jets", which are precompiled functions that can be called directly from Simplicity code. These jets allow for faster execution of Simplicity code compared to other blockchain languages, while also increasing security by reducing vulnerabilities to bugs and attacks. Each Simplicity expression is identified by its MAST root, which is the Merkle root of all branches in its Abstract Syntax Tree. When the Simplicity interpreter encounters an expression with a jet, it looks for it in a predefined jets dictionary and finds the binary for a precompiled, formally proven implementation of the function. This means that popular Simplicity expressions can be recognized and directly evaluated using specialized C or assembly code, rather than being interpreted.In response to concerns about the need for Simplicity code to be publicly available in the blockchain when using jets, it was explained that discounted jets will be explicitly labeled as jets in the commitment. If a user can provide a Merkle path to an explicit jet node that isn't among the known discounted jets, it will not be executed. This mitigates the need for large algorithms like EDCA verification/SHA256 hashing to take up space in the blockchain. Additionally, in a softfork for a jet, the Simplicity code for the jet could be defined as "consensus", eliminating the need for it to be provided within every script output. The use of formal verification ensures that the jets match the corresponding Simplicity code.The bitcoin-dev mailing list featured discussions on the Simplicity proposal and the use of jets. Users raised questions about the need for Simplicity code to be publicly available and the possibility of mitigating this. Russell O'Connor, in response, referred to section 3.4 of the Simplicity proposal document and explained how jets work. He mentioned that jets are briefly discussed in the proposal and are a way to recognize popular Simplicity expressions and directly evaluate their functions using specialized C or assembly code. Russell also clarified that discounted jets will be explicitly labeled as jets in the commitment, and a Merkle path to an explicit jet node can be provided if it isn't among the known discounted jets.The Simplicity programming language uses jets as a smart optimization technique to make complex Simplicity contracts more computationally efficient. Jets leverage the frames stack in the Simplicity Bit Machine, allowing for known results of expressions to be written to the active write frame instead of executing the expression step-by-step again. This optimization reduces CPU usage and ensures that jets cannot introduce side effects. Different sets of jets can create single-purpose dialects, similar to domain-specific languages, enhancing the vocabulary and semantics of Simplicity code.While there is a lack of specific information and links regarding jets in the Simplicity proposal, it is mentioned that discounted jets will be identified as such in the commitment. If a Merkle path can be provided to an explicit jet node that is not among the known discounted jets, it will also be considered a jet. However, further details on this feature are currently unavailable. 2017-11-03T16:42:38+00:00 + The Simplicity proposal introduces the concept of "jets", which are precompiled functions that can be called directly from Simplicity code. These jets allow for faster execution of Simplicity code compared to other blockchain languages, while also increasing security by reducing vulnerabilities to bugs and attacks. Each Simplicity expression is identified by its MAST root, which is the Merkle root of all branches in its Abstract Syntax Tree. When the Simplicity interpreter encounters an expression with a jet, it looks for it in a predefined jets dictionary and finds the binary for a precompiled, formally proven implementation of the function. This means that popular Simplicity expressions can be recognized and directly evaluated using specialized C or assembly code, rather than being interpreted.In response to concerns about the need for Simplicity code to be publicly available in the blockchain when using jets, it was explained that discounted jets will be explicitly labeled as jets in the commitment. If a user can provide a Merkle path to an explicit jet node that isn't among the known discounted jets, it will not be executed. This mitigates the need for large algorithms like EDCA verification/SHA256 hashing to take up space in the blockchain. Additionally, in a softfork for a jet, the Simplicity code for the jet could be defined as "consensus", eliminating the need for it to be provided within every script output. The use of formal verification ensures that the jets match the corresponding Simplicity code.The bitcoin-dev mailing list featured discussions on the Simplicity proposal and the use of jets. Users raised questions about the need for Simplicity code to be publicly available and the possibility of mitigating this. Russell O'Connor, in response, referred to section 3.4 of the Simplicity proposal document and explained how jets work. He mentioned that jets are briefly discussed in the proposal and are a way to recognize popular Simplicity expressions and directly evaluate their functions using specialized C or assembly code. Russell also clarified that discounted jets will be explicitly labeled as jets in the commitment, and a Merkle path to an explicit jet node can be provided if it isn't among the known discounted jets.The Simplicity programming language uses jets as a smart optimization technique to make complex Simplicity contracts more computationally efficient. Jets leverage the frames stack in the Simplicity Bit Machine, allowing for known results of expressions to be written to the active write frame instead of executing the expression step-by-step again. This optimization reduces CPU usage and ensures that jets cannot introduce side effects. Different sets of jets can create single-purpose dialects, similar to domain-specific languages, enhancing the vocabulary and semantics of Simplicity code.While there is a lack of specific information and links regarding jets in the Simplicity proposal, it is mentioned that discounted jets will be identified as such in the commitment. If a Merkle path can be provided to an explicit jet node that is not among the known discounted jets, it will also be considered a jet. However, further details on this feature are currently unavailable. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Updates-on-Confidential-Transactions-efficiency.xml b/static/bitcoin-dev/Nov_2017/combined_Updates-on-Confidential-Transactions-efficiency.xml index 0aa35af35d..8e189ca675 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Updates-on-Confidential-Transactions-efficiency.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Updates-on-Confidential-Transactions-efficiency.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Updates on Confidential Transactions efficiency - 2023-08-01T22:08:18.215647+00:00 - - Andrew Poelstra 2017-12-04 17:17:11+00:00 - - - Gregory Maxwell 2017-11-14 10:51:13+00:00 - - - Gregory Maxwell 2017-11-14 10:38:33+00:00 - - - Peter Todd 2017-11-14 10:07:28+00:00 - - - Peter Todd 2017-11-14 09:11:23+00:00 - - - Gregory Maxwell 2017-11-14 01:21:14+00:00 - + 2025-09-26T15:50:35.689823+00:00 + python-feedgen + + + [bitcoin-dev] Updates on Confidential Transactions efficiency Gregory Maxwell + 2017-11-14T01:21:00.000Z + + + Peter Todd + 2017-11-14T09:11:00.000Z + + + Peter Todd + 2017-11-14T10:07:00.000Z + + + Gregory Maxwell + 2017-11-14T10:38:00.000Z + + + Gregory Maxwell + 2017-11-14T10:51:00.000Z + + + Andrew Poelstra + 2017-12-04T17:17:00.000Z + + - python-feedgen + 2 Combined summary - Updates on Confidential Transactions efficiency - 2023-08-01T22:08:18.215647+00:00 + 2025-09-26T15:50:35.690639+00:00 - Andrew Poelstra has implemented the single-output version of Bulletproofs, a cryptographic proof system that can prove statements about encrypted data. The benchmarks were performed on one core of an Intel i7-6820MQ, and reflect verification of a single 64-bit rangeproof. By using GLV endomorphism supported by the curve secp256k1, speedup was observed. It reflects a 3.47x speedup over the verification speed of the old rangeproofs without the endomorphism. Even without aggregation, two rangeproofs are verified nearly 15% faster than verifying one twice. The old rangeproofs require only 128 multiplies for a 64-bit proof, then 256 for two, and so on, while at the same time the new Bulletproofs perform significantly better. The Bulletproof verification process is a recursive process which does not appear to be expressible as a single multiproduct, and in fact it appears to require nearly twice as many multiplications as claimed. There are still a few open issues that Andrew plans to help resolve in the coming month.In an email exchange, Gregory Maxwell discussed the scalability and privacy of different transaction topologies. He noted that ring-in and tree-in approaches, used by Monero and Zcash, are more private but less scalable than CT+valueshuffle. However, he also mentioned a fourth topology that is closely related to ring-in, which involves taking N inputs and writing >= N outputs, replacing some coins with new outputs or encrypted dummies while re-encrypting others in a way that their owner can still decode. This approach avoids the spent coins list by allowing for malleation of inputs. In the past, there was no efficient way to construct this topology in a plain DL setting, but it may be possible with bulletproofs.In an email exchange, Peter Todd and Gregory Maxwell discuss the risks associated with privacy in cryptocurrency systems. Todd argues that privacy breaches threaten users' freedom, while Maxwell questions the feasibility of implementing perfectly hiding systems in practice. They also discuss the possibility of using switch commitments to retain computational-hiding-depending-on-the-hardness-of-inverting-hashes while retaining an option to upgrade or block spending via unsound mechanisms in the event of a crypto break. The conversation then shifts to the scalability of ring-in and tree-in approaches in Monero and Zcash, with Maxwell suggesting ways to extend these approaches to a traceable 1 of N input for Monero. He also proposes using a hash tree to provide tree-in style transactions with proofs that grow with the log() of the size of the tree, although he acknowledges that this would come at the cost of larger proofs and slower verification. Despite its drawbacks, Maxwell believes that the interactive-sparse-in (CJ) approach has its own attractiveness.Gregory Maxwell discusses an approach that could be constructed without new cryptographic assumptions, be high-performance compared to alternatives, have no trusted setup, and not involve the creation of any forever-growing unprunable accumulators. All major alternative schemes failed multiple criteria in comparison. In response to the issue of unprunable accumulators, it was suggested that it would be feasible to use accumulator epochs. This would either make unspent coins in a previous epoch unspendable after some expiry time is reached or make use of a merkelized key-value scheme with transaction-provided proofs to shift the costs of maintaining the accumulator to wallets. Epoch size would be a tradeoff between state size and k-anonymity set size.Gregory Maxwell announces the release of Bulletproofs, a new zero-knowledge proof system that shrinks the size of cryptographic proofs and makes them safer. Bulletproofs can be used to increase the privacy and confidentiality of cryptocurrencies such as Bitcoin, while also making them more scalable. The technology was developed by researchers at University College London (UCL), Blockstream and Stanford University, and is based on previous work by UCL's Jonathan Bootle.Adam Back proposed the use of additive homomorphic commitments in Bitcoin to improve transaction privacy. This approach, known as confidential transactions, makes transaction amounts private and complements CoinJoin by avoiding the issue of joins being decoded due to different amounts being used. Recent work has focused on reducing the range proof size further. In a recent publication on confidential assets, the size was reduced to 96*log3(2)*bits + 32. Benedikt Bünz at Stanford was able to apply and optimize the inner product argument of Jonathan Bootle to achieve an aggregate range proof for CT with size 64 * (log2(bits * num_outputs)) + 288. This scheme also has a straightforward and efficient method for multi-party computation, which means that the aggregates can be used in all-party-private coinjoins like the value shuffle work mentioned above. Verification in this new work requires computation which is more than linear in the size of the proof. 2017-12-04T17:17:11+00:00 + Andrew Poelstra has implemented the single-output version of Bulletproofs, a cryptographic proof system that can prove statements about encrypted data. The benchmarks were performed on one core of an Intel i7-6820MQ, and reflect verification of a single 64-bit rangeproof. By using GLV endomorphism supported by the curve secp256k1, speedup was observed. It reflects a 3.47x speedup over the verification speed of the old rangeproofs without the endomorphism. Even without aggregation, two rangeproofs are verified nearly 15% faster than verifying one twice. The old rangeproofs require only 128 multiplies for a 64-bit proof, then 256 for two, and so on, while at the same time the new Bulletproofs perform significantly better. The Bulletproof verification process is a recursive process which does not appear to be expressible as a single multiproduct, and in fact it appears to require nearly twice as many multiplications as claimed. There are still a few open issues that Andrew plans to help resolve in the coming month.In an email exchange, Gregory Maxwell discussed the scalability and privacy of different transaction topologies. He noted that ring-in and tree-in approaches, used by Monero and Zcash, are more private but less scalable than CT+valueshuffle. However, he also mentioned a fourth topology that is closely related to ring-in, which involves taking N inputs and writing >= N outputs, replacing some coins with new outputs or encrypted dummies while re-encrypting others in a way that their owner can still decode. This approach avoids the spent coins list by allowing for malleation of inputs. In the past, there was no efficient way to construct this topology in a plain DL setting, but it may be possible with bulletproofs.In an email exchange, Peter Todd and Gregory Maxwell discuss the risks associated with privacy in cryptocurrency systems. Todd argues that privacy breaches threaten users' freedom, while Maxwell questions the feasibility of implementing perfectly hiding systems in practice. They also discuss the possibility of using switch commitments to retain computational-hiding-depending-on-the-hardness-of-inverting-hashes while retaining an option to upgrade or block spending via unsound mechanisms in the event of a crypto break. The conversation then shifts to the scalability of ring-in and tree-in approaches in Monero and Zcash, with Maxwell suggesting ways to extend these approaches to a traceable 1 of N input for Monero. He also proposes using a hash tree to provide tree-in style transactions with proofs that grow with the log() of the size of the tree, although he acknowledges that this would come at the cost of larger proofs and slower verification. Despite its drawbacks, Maxwell believes that the interactive-sparse-in (CJ) approach has its own attractiveness.Gregory Maxwell discusses an approach that could be constructed without new cryptographic assumptions, be high-performance compared to alternatives, have no trusted setup, and not involve the creation of any forever-growing unprunable accumulators. All major alternative schemes failed multiple criteria in comparison. In response to the issue of unprunable accumulators, it was suggested that it would be feasible to use accumulator epochs. This would either make unspent coins in a previous epoch unspendable after some expiry time is reached or make use of a merkelized key-value scheme with transaction-provided proofs to shift the costs of maintaining the accumulator to wallets. Epoch size would be a tradeoff between state size and k-anonymity set size.Gregory Maxwell announces the release of Bulletproofs, a new zero-knowledge proof system that shrinks the size of cryptographic proofs and makes them safer. Bulletproofs can be used to increase the privacy and confidentiality of cryptocurrencies such as Bitcoin, while also making them more scalable. The technology was developed by researchers at University College London (UCL), Blockstream and Stanford University, and is based on previous work by UCL's Jonathan Bootle.Adam Back proposed the use of additive homomorphic commitments in Bitcoin to improve transaction privacy. This approach, known as confidential transactions, makes transaction amounts private and complements CoinJoin by avoiding the issue of joins being decoded due to different amounts being used. Recent work has focused on reducing the range proof size further. In a recent publication on confidential assets, the size was reduced to 96*log3(2)*bits + 32. Benedikt Bünz at Stanford was able to apply and optimize the inner product argument of Jonathan Bootle to achieve an aggregate range proof for CT with size 64 * (log2(bits * num_outputs)) + 288. This scheme also has a straightforward and efficient method for multi-party computation, which means that the aggregates can be used in all-party-private coinjoins like the value shuffle work mentioned above. Verification in this new work requires computation which is more than linear in the size of the proof. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2017/combined_Why-SegWit-Anyway-.xml b/static/bitcoin-dev/Nov_2017/combined_Why-SegWit-Anyway-.xml index 25a9e64256..0f0d520370 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Why-SegWit-Anyway-.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Why-SegWit-Anyway-.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Why SegWit Anyway? - 2023-08-01T22:09:44.996730+00:00 - - CANNON 2017-11-25 15:41:44+00:00 - - - Adán Sánchez de Pedro Crespo 2017-11-21 13:16:48+00:00 - - - Steve Shadders 2017-11-21 13:10:28+00:00 - - - Johnson Lau 2017-11-20 19:58:57+00:00 - - - Gregory Maxwell 2017-11-20 18:59:34+00:00 - - - Praveen Baratam 2017-11-20 18:07:40+00:00 - - - Dan Bryant 2017-11-20 18:04:09+00:00 - - - Johnson Lau 2017-11-20 17:45:18+00:00 - - - Ariel Lorenzo-Luaces 2017-11-20 17:39:11+00:00 - - - Praveen Baratam 2017-11-20 17:24:33+00:00 - + 2025-09-26T15:50:33.602200+00:00 + python-feedgen + + + [bitcoin-dev] Why SegWit Anyway? Praveen Baratam + 2017-11-20T17:24:00.000Z + + + Ariel Lorenzo-Luaces + 2017-11-20T17:39:00.000Z + + + Johnson Lau + 2017-11-20T17:45:00.000Z + + + Dan Bryant + 2017-11-20T18:04:00.000Z + + + Praveen Baratam + 2017-11-20T18:07:00.000Z + + + Gregory Maxwell + 2017-11-20T18:59:00.000Z + + + Johnson Lau + 2017-11-20T19:58:00.000Z + + + Steve Shadders + 2017-11-21T13:10:00.000Z + + + Adán Sánchez de Pedro Crespo + 2017-11-21T13:16:00.000Z + + + CANNON + 2017-11-25T15:41:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Why SegWit Anyway? - 2023-08-01T22:09:44.996730+00:00 + 2025-09-26T15:50:33.603623+00:00 - Segregated Witness (SegWit) has several benefits, as discussed in a post by Adán Sánchez de Pedro Crespo. One of these benefits is that SegWit signatures can be cheaper to verify compared to traditional signatures, which were vulnerable to denial-of-service (DoS) attacks using forged transactions. These attacks could take several minutes to verify and were highly disruptive. There may be additional resources available for those interested in learning more about these types of attacks.SegWit transactions spend less "weight," allowing miners to fit more transactions into a block and use less power. They also provide reduced transaction fees, larger capacity for transactions, and increased security. While there is no direct incentive for miners to choose SegWit transactions over non-SegWit ones, artificially distorted block weight rules create an incentive for miners to select SegWit transactions and earn more fees.There have been concerns about changing the definition of TxID, as it would require a hardfork upgrade and potentially lead to a chain split if not everyone upgrades. To address this issue, BIP140 proposes using "normalized TxID" as a softfork solution to fix malleability issues without changing the definition of TxID. However, this approach makes the UTXO set permanently bigger as the database needs to store both txid and normalized txid.The discussion also touches upon the question of why the format of transactions needs to be changed in SegWit. Johnson Lau explains that different SIGHASH flags make it impossible to compute the Transaction ID the same way as the hash for signing the transaction. Changing the definition of TxID would require a hardfork change, while using BIP140 as a softfork solution avoids these complications.Another developer clarifies that SegWit does not separate signatures from the rest of the transaction data, but rather excludes them from the TXID. The serialization of SegWit on the p2p network encodes the witness field inside the transactions.In summary, SegWit offers various benefits such as cheaper signature verification, increased transaction capacity, and reduced fees. There are ongoing discussions about the best approach to address transaction malleability, with BIP140 proposing a softfork solution that avoids changing the definition of TxID. However, there are concerns about the increased size of the UTXO set with this solution. The format of transactions in SegWit has been changed to improve scalability and security, with signatures excluded from the TXID. 2017-11-25T15:41:44+00:00 + Segregated Witness (SegWit) has several benefits, as discussed in a post by Adán Sánchez de Pedro Crespo. One of these benefits is that SegWit signatures can be cheaper to verify compared to traditional signatures, which were vulnerable to denial-of-service (DoS) attacks using forged transactions. These attacks could take several minutes to verify and were highly disruptive. There may be additional resources available for those interested in learning more about these types of attacks.SegWit transactions spend less "weight," allowing miners to fit more transactions into a block and use less power. They also provide reduced transaction fees, larger capacity for transactions, and increased security. While there is no direct incentive for miners to choose SegWit transactions over non-SegWit ones, artificially distorted block weight rules create an incentive for miners to select SegWit transactions and earn more fees.There have been concerns about changing the definition of TxID, as it would require a hardfork upgrade and potentially lead to a chain split if not everyone upgrades. To address this issue, BIP140 proposes using "normalized TxID" as a softfork solution to fix malleability issues without changing the definition of TxID. However, this approach makes the UTXO set permanently bigger as the database needs to store both txid and normalized txid.The discussion also touches upon the question of why the format of transactions needs to be changed in SegWit. Johnson Lau explains that different SIGHASH flags make it impossible to compute the Transaction ID the same way as the hash for signing the transaction. Changing the definition of TxID would require a hardfork change, while using BIP140 as a softfork solution avoids these complications.Another developer clarifies that SegWit does not separate signatures from the rest of the transaction data, but rather excludes them from the TXID. The serialization of SegWit on the p2p network encodes the witness field inside the transactions.In summary, SegWit offers various benefits such as cheaper signature verification, increased transaction capacity, and reduced fees. There are ongoing discussions about the best approach to address transaction malleability, with BIP140 proposing a softfork solution that avoids changing the definition of TxID. However, there are concerns about the increased size of the UTXO set with this solution. The format of transactions in SegWit has been changed to improve scalability and security, with signatures excluded from the TXID. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2018/combined_BIP-Proposal-Address-Paste-Improvement.xml b/static/bitcoin-dev/Nov_2018/combined_BIP-Proposal-Address-Paste-Improvement.xml index 6bb9206d2f..3accec14df 100644 --- a/static/bitcoin-dev/Nov_2018/combined_BIP-Proposal-Address-Paste-Improvement.xml +++ b/static/bitcoin-dev/Nov_2018/combined_BIP-Proposal-Address-Paste-Improvement.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - BIP Proposal - Address Paste Improvement - 2023-08-01T23:58:56.562249+00:00 - - Adam Ficsor 2018-12-01 12:07:40+00:00 - - - James MacWhyte 2018-12-01 04:57:20+00:00 - - - Adam Ficsor 2018-11-12 03:23:53+00:00 - - - Dmitry Petukhov 2018-11-08 18:00:04+00:00 - - - Moral Agent 2018-11-08 17:43:36+00:00 - - - Jeffrey Paul 2018-11-08 17:12:17+00:00 - - - Andreas Schildbach 2018-11-08 15:28:41+00:00 - - - Dmitry Petukhov 2018-11-08 08:11:30+00:00 - - - Andreas Schildbach 2018-11-07 21:28:54+00:00 - - - Adam Ficsor 2018-11-07 14:09:53+00:00 - + 2025-09-26T15:31:32.238694+00:00 + python-feedgen + + + [bitcoin-dev] BIP Proposal - Address Paste Improvement Adam Ficsor + 2018-11-07T14:09:00.000Z + + + Andreas Schildbach + 2018-11-07T21:28:00.000Z + + + Dmitry Petukhov + 2018-11-08T08:11:00.000Z + + + Andreas Schildbach + 2018-11-08T15:28:00.000Z + + + Jeffrey Paul + 2018-11-08T17:12:00.000Z + + + Moral Agent + 2018-11-08T17:43:00.000Z + + + Dmitry Petukhov + 2018-11-08T18:00:00.000Z + + + Adam Ficsor + 2018-11-12T03:23:00.000Z + + + James MacWhyte + 2018-12-01T04:57:00.000Z + + + Adam Ficsor + 2018-12-01T12:07:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP Proposal - Address Paste Improvement - 2023-08-01T23:58:56.562249+00:00 + 2025-09-26T15:31:32.239896+00:00 - The discussion thread focuses on the need to establish a standard for transferring Bitcoin addresses from web pages or messages to wallet address input fields. Various methods were suggested, including QR code scanning, "bitcoin:" URI intent, and the BIP70 payment protocol. However, concerns were raised about incentivizing users to use copypaste functionality extensively, as it can be easily compromised by crypto hijackers. It was argued that moving to other ways of specifying destinations could also pose security issues. The conversation also touched on BIP75 and BIP47 protocols, which may help with address transfer but have limited wallet support due to their complexity. A work-in-progress implementation exists in Wasabi. Ultimately, the decision whether this needs to be a BIP or not depends on the community's valuation of user experience.In the Bitcoin developer email thread, the issue of transferring an address from a webpage to a wallet address input field was discussed. Suggestions included QR code scanning and using "bitcoin:" URI intent on Android. However, in many cases, addresses are presented as text to copy. Some proposed autodetecting Bitcoin addresses and converting them to "bitcoin:" links, but adoption of this feature may be slow. The conversation also delved into the BIP70, BIP75, and BIP47 payment protocols, with limited wallet support for the latter two due to their complexity. One commenter questioned the need for this to be a BIP, emphasizing that it is more of a UX detail rather than a Bitcoin protocol. They requested further elaboration on the need for documentation. Another commenter raised concerns about incentivizing excessive use of copypaste functionality, but argued that crypto hijackers use the clipboard because it is convenient, not because it is the only method they can hijack. The existence of a work-in-progress implementation in Wasabi was mentioned.The mechanism for end-users to transfer an address from a web page to the wallet address input field was discussed in the thread. Various methods such as QR code scanning, "bitcoin:" URI intent, and BIP70 payment message intent were suggested. However, in many cases, addresses are presented as text for users to copy. There were concerns about incentivizing excessive use of copypaste functionality, countered by the argument that crypto hijackers use the clipboard because it is convenient, not because it is their only method of hijacking. The conversation also touched on crypto hijackers, which was considered off-topic. It was noted that there is a work-in-progress implementation in Wasabi. For well-known entities, the BIP70 payment protocol with authentication via certificates can be used, but it does not cover the use case of relying solely on the person in front of you as the trust anchor. BIP75 and BIP47 protocols may help, but their limited wallet support is attributed to their complexity.There are several mechanisms available for end-users to transfer an address from a web page to the wallet address input field, including QR code scanning, "bitcoin:" URI intent, and BIP70 payment message intent. However, in many cases, addresses are presented as text for users to copy. This raised concerns about incentivizing excessive use of copypaste functionality. On the other hand, it was argued that crypto hijackers use the clipboard because it is convenient, rather than it being their only method of hijacking. The discussion also mentioned the existence of a work-in-progress implementation in Wasabi. For cases where the payee is a well-known entity, the BIP70 payment protocol with authentication via certificates can be used. However, this protocol does not address the use case where the person in front of you is the only trust anchor. BIP75 and BIP47 protocols were also mentioned as potential solutions, but their limited wallet support is likely due to their relative complexity.The act of copying addresses to the clipboard is discouraged due to security risks, as malware can easily replace addresses with their own. Suggestions were made to implement an address authentication procedure that balances convenience and security. These suggestions include using 2FA, visual fingerprints, and signing the destination address with the key of an already-known address. However, finding a solution that meets both criteria remains a challenge. The discussion also highlighted the need for a convenient mechanism for end-users to transfer an address from a web page to the wallet address input field. Various methods such as QR code scanning and URI intents were suggested, but the adoption of these features may be slow. The BIP70 payment protocol with authentication via certificates was mentioned as a solution for well-known entities, but it does not cover the use case of relying solely on the person in front of you as the trust anchor. 2018-12-01T12:07:40+00:00 + The discussion thread focuses on the need to establish a standard for transferring Bitcoin addresses from web pages or messages to wallet address input fields. Various methods were suggested, including QR code scanning, "bitcoin:" URI intent, and the BIP70 payment protocol. However, concerns were raised about incentivizing users to use copypaste functionality extensively, as it can be easily compromised by crypto hijackers. It was argued that moving to other ways of specifying destinations could also pose security issues. The conversation also touched on BIP75 and BIP47 protocols, which may help with address transfer but have limited wallet support due to their complexity. A work-in-progress implementation exists in Wasabi. Ultimately, the decision whether this needs to be a BIP or not depends on the community's valuation of user experience.In the Bitcoin developer email thread, the issue of transferring an address from a webpage to a wallet address input field was discussed. Suggestions included QR code scanning and using "bitcoin:" URI intent on Android. However, in many cases, addresses are presented as text to copy. Some proposed autodetecting Bitcoin addresses and converting them to "bitcoin:" links, but adoption of this feature may be slow. The conversation also delved into the BIP70, BIP75, and BIP47 payment protocols, with limited wallet support for the latter two due to their complexity. One commenter questioned the need for this to be a BIP, emphasizing that it is more of a UX detail rather than a Bitcoin protocol. They requested further elaboration on the need for documentation. Another commenter raised concerns about incentivizing excessive use of copypaste functionality, but argued that crypto hijackers use the clipboard because it is convenient, not because it is the only method they can hijack. The existence of a work-in-progress implementation in Wasabi was mentioned.The mechanism for end-users to transfer an address from a web page to the wallet address input field was discussed in the thread. Various methods such as QR code scanning, "bitcoin:" URI intent, and BIP70 payment message intent were suggested. However, in many cases, addresses are presented as text for users to copy. There were concerns about incentivizing excessive use of copypaste functionality, countered by the argument that crypto hijackers use the clipboard because it is convenient, not because it is their only method of hijacking. The conversation also touched on crypto hijackers, which was considered off-topic. It was noted that there is a work-in-progress implementation in Wasabi. For well-known entities, the BIP70 payment protocol with authentication via certificates can be used, but it does not cover the use case of relying solely on the person in front of you as the trust anchor. BIP75 and BIP47 protocols may help, but their limited wallet support is attributed to their complexity.There are several mechanisms available for end-users to transfer an address from a web page to the wallet address input field, including QR code scanning, "bitcoin:" URI intent, and BIP70 payment message intent. However, in many cases, addresses are presented as text for users to copy. This raised concerns about incentivizing excessive use of copypaste functionality. On the other hand, it was argued that crypto hijackers use the clipboard because it is convenient, rather than it being their only method of hijacking. The discussion also mentioned the existence of a work-in-progress implementation in Wasabi. For cases where the payee is a well-known entity, the BIP70 payment protocol with authentication via certificates can be used. However, this protocol does not address the use case where the person in front of you is the only trust anchor. BIP75 and BIP47 protocols were also mentioned as potential solutions, but their limited wallet support is likely due to their relative complexity.The act of copying addresses to the clipboard is discouraged due to security risks, as malware can easily replace addresses with their own. Suggestions were made to implement an address authentication procedure that balances convenience and security. These suggestions include using 2FA, visual fingerprints, and signing the destination address with the key of an already-known address. However, finding a solution that meets both criteria remains a challenge. The discussion also highlighted the need for a convenient mechanism for end-users to transfer an address from a web page to the wallet address input field. Various methods such as QR code scanning and URI intents were suggested, but the adoption of these features may be slow. The BIP70 payment protocol with authentication via certificates was mentioned as a solution for well-known entities, but it does not cover the use case of relying solely on the person in front of you as the trust anchor. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2018/combined_BIP-SLIP-0039-better-multi-language-support.xml b/static/bitcoin-dev/Nov_2018/combined_BIP-SLIP-0039-better-multi-language-support.xml index cb27622184..1384df6ef2 100644 --- a/static/bitcoin-dev/Nov_2018/combined_BIP-SLIP-0039-better-multi-language-support.xml +++ b/static/bitcoin-dev/Nov_2018/combined_BIP-SLIP-0039-better-multi-language-support.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP- & SLIP-0039 -- better multi-language support - 2023-08-01T23:58:10.827450+00:00 + 2025-09-26T15:31:38.532805+00:00 + python-feedgen Weiji Guo 2018-11-22 17:25:07+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP- & SLIP-0039 -- better multi-language support - 2023-08-01T23:58:10.828451+00:00 + 2025-09-26T15:31:38.532979+00:00 - In a bitcoin-dev discussion, Steven Hatzakis proposed revising the process for generating BIP39 seed by feeding the initial entropy into the PBKDF2 function instead of using words. Weiji suggested incorporating Shamir's Secret Sharing (SSS) into the design to maintain language independence and enable mnemonics in multiple languages simultaneously. The proposed revision includes a language id for each defined wordlist in the SSS share, as well as other parameters such as share id, threshold, index, share value, and checksum. Weiji also suggested using two languages or one language + numbers to cross-check for errors in handprinting. Another discussion on the use of mnemonics in different languages highlighted the issue that while words cannot be directly translated, the underlying entropy is the same when comparing mnemonics generated across different languages from the same initial entropy. Two options were suggested to solve this problem: either have the wallet recognize the language and re-map the entropy accordingly or revise how the BIP39 seed is generated by hashing the entropy instead of the words. It was also suggested to include the identifier of the chosen wordlist as part of the mnemonic and maintain an official list of named dictionaries for user selection.The BIP39 seed generation process currently depends on the language chosen for the mnemonic sentence, limiting users to specific languages. The proposed solution is to represent the mnemonic code as the underlying entropy or pre-master secret, allowing for the same seed/secret to be displayed in any language. Decimal numbers could also be used to represent the seed/secret for users who struggle with words in other languages. However, it should be noted that two mnemonics generated with the same entropy will produce different BIP39 seeds depending on the language chosen.In a conversation between Neill Miller and Jonathan Underwood, it was mentioned that Electrum treats BIP39 recovery in the same way as non-BIP39 mnemonics. Jonathan mentioned that Electrum follows the BIP39 specifications for recovery, but Neill pointed out that Electrum mnemonics are not based on BIP39.Jonathan Underwood further discussed how Electrum handles BIP39 recovery according to the specifications, while mentioning that not all apps follow the BIP39 spec. He expressed the difficulty of expecting every app to support multiple languages due to the lack of adherence to the spec. However, he noted that Electrum allows for restoring random strings with a warning. Neill Miller confirmed that Electrum mnemonics are not based on BIP39.Jonathan Underwood emphasized that while multiple languages in BIP39 make sense, it is unreasonable to expect every app to load every language due to the lack of adherence to the spec. He clarified that Electrum follows the BIP39 recovery process but warned about restoring random strings. Neill confirmed this information.BIP39 provides flexibility in wordlists for generating mnemonic sentences, but it is advised to use mnemonics generated by the algorithm described in the specification. Software must compute a checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid. The BIP39 multi-language feature is important for non-English speakers, but many wallets only support the English wordlist. Electrum seeds are language/wordlist agnostic and allow for restoration of random strings. The need to address the language issue in BIP39 has led to proposals such as representing the mnemonic code as underlying entropy or using decimal numbers instead of words.Weiji Guo highlighted that BIP-0039 is language dependent, limiting users who prefer non-English languages. While SLIP-0039 offers SSS capability with an English wordlist, it does not provide a user-friendly solution. Weiji proposed two solutions: representing the mnemonic code as underlying entropy or allowing the seed/secret to be represented in decimal numbers for users who struggle with words in other languages. Implementation details for these proposals are uncertain, and community input is sought.In summary, there have been discussions and proposals to address the language dependence of BIP39 mnemonics. Suggestions include revising the seed generation process, incorporating Shamir's Secret Sharing, and representing the mnemonic code as underlying entropy or using decimal numbers. Electrum follows the BIP39 recovery process but also supports non-BIP39 mnemonics. The lack of adherence to the BIP39 spec by other apps has made it challenging to support multiple languages. Further exploration and input from the community are needed to find a suitable solution. 2018-11-22T17:25:07+00:00 + In a bitcoin-dev discussion, Steven Hatzakis proposed revising the process for generating BIP39 seed by feeding the initial entropy into the PBKDF2 function instead of using words. Weiji suggested incorporating Shamir's Secret Sharing (SSS) into the design to maintain language independence and enable mnemonics in multiple languages simultaneously. The proposed revision includes a language id for each defined wordlist in the SSS share, as well as other parameters such as share id, threshold, index, share value, and checksum. Weiji also suggested using two languages or one language + numbers to cross-check for errors in handprinting. Another discussion on the use of mnemonics in different languages highlighted the issue that while words cannot be directly translated, the underlying entropy is the same when comparing mnemonics generated across different languages from the same initial entropy. Two options were suggested to solve this problem: either have the wallet recognize the language and re-map the entropy accordingly or revise how the BIP39 seed is generated by hashing the entropy instead of the words. It was also suggested to include the identifier of the chosen wordlist as part of the mnemonic and maintain an official list of named dictionaries for user selection.The BIP39 seed generation process currently depends on the language chosen for the mnemonic sentence, limiting users to specific languages. The proposed solution is to represent the mnemonic code as the underlying entropy or pre-master secret, allowing for the same seed/secret to be displayed in any language. Decimal numbers could also be used to represent the seed/secret for users who struggle with words in other languages. However, it should be noted that two mnemonics generated with the same entropy will produce different BIP39 seeds depending on the language chosen.In a conversation between Neill Miller and Jonathan Underwood, it was mentioned that Electrum treats BIP39 recovery in the same way as non-BIP39 mnemonics. Jonathan mentioned that Electrum follows the BIP39 specifications for recovery, but Neill pointed out that Electrum mnemonics are not based on BIP39.Jonathan Underwood further discussed how Electrum handles BIP39 recovery according to the specifications, while mentioning that not all apps follow the BIP39 spec. He expressed the difficulty of expecting every app to support multiple languages due to the lack of adherence to the spec. However, he noted that Electrum allows for restoring random strings with a warning. Neill Miller confirmed that Electrum mnemonics are not based on BIP39.Jonathan Underwood emphasized that while multiple languages in BIP39 make sense, it is unreasonable to expect every app to load every language due to the lack of adherence to the spec. He clarified that Electrum follows the BIP39 recovery process but warned about restoring random strings. Neill confirmed this information.BIP39 provides flexibility in wordlists for generating mnemonic sentences, but it is advised to use mnemonics generated by the algorithm described in the specification. Software must compute a checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid. The BIP39 multi-language feature is important for non-English speakers, but many wallets only support the English wordlist. Electrum seeds are language/wordlist agnostic and allow for restoration of random strings. The need to address the language issue in BIP39 has led to proposals such as representing the mnemonic code as underlying entropy or using decimal numbers instead of words.Weiji Guo highlighted that BIP-0039 is language dependent, limiting users who prefer non-English languages. While SLIP-0039 offers SSS capability with an English wordlist, it does not provide a user-friendly solution. Weiji proposed two solutions: representing the mnemonic code as underlying entropy or allowing the seed/secret to be represented in decimal numbers for users who struggle with words in other languages. Implementation details for these proposals are uncertain, and community input is sought.In summary, there have been discussions and proposals to address the language dependence of BIP39 mnemonics. Suggestions include revising the seed generation process, incorporating Shamir's Secret Sharing, and representing the mnemonic code as underlying entropy or using decimal numbers. Electrum follows the BIP39 recovery process but also supports non-BIP39 mnemonics. The lack of adherence to the BIP39 spec by other apps has made it challenging to support multiple languages. Further exploration and input from the community are needed to find a suitable solution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2018/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml b/static/bitcoin-dev/Nov_2018/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml index ba0ee494d2..8458e0175d 100644 --- a/static/bitcoin-dev/Nov_2018/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml +++ b/static/bitcoin-dev/Nov_2018/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml @@ -1,65 +1,63 @@ - + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 - - Johan Torås Halseth 2019-10-30 07:22:53+00:00 - - - David A. Harding 2019-10-28 17:14:38+00:00 - - - Johan Torås Halseth 2019-10-28 09:45:39+00:00 - - - David A. Harding 2019-10-27 22:54:02+00:00 - - - Jeremy 2019-10-27 19:13:09+00:00 - - - Matt Corallo 2019-10-25 17:30:41+00:00 - - - Johan Torås Halseth 2019-10-25 07:05:15+00:00 - - - Matt Corallo 2019-10-24 21:25:14+00:00 - - - Johan Torås Halseth 2019-10-24 13:49:09+00:00 - - - Rusty Russell 2019-02-13 04:22:39+00:00 - - - Matt Corallo 2019-01-08 14:46:45+00:00 - - - Rusty Russell 2019-01-08 05:50:20+00:00 - - - Matt Corallo 2019-01-07 15:18:52+00:00 - - - Rusty Russell 2018-12-04 03:33:53+00:00 - - - ZmnSCPxj 2018-12-03 04:16:10+00:00 - - - Bob McElrath 2018-12-02 15:08:39+00:00 - - - Matt Corallo 2018-11-30 19:33:56+00:00 - - - Russell O'Connor 2018-11-30 17:38:04+00:00 - - - Matt Corallo 2018-11-29 19:37:54+00:00 - + 2025-09-26T15:31:25.953385+00:00 + python-feedgen + + + Matt Corallo + 2019-01-07T15:18:00.000Z + + + Rusty Russell + 2019-01-08T05:50:00.000Z + + + Matt Corallo + 2019-01-08T14:46:00.000Z + + + Rusty Russell + 2019-02-13T04:22:00.000Z + + + Johan Torås Halseth + 2019-10-24T13:49:00.000Z + + + Matt Corallo + 2019-10-24T21:25:00.000Z + + + Johan Torås Halseth + 2019-10-25T07:05:00.000Z + + + Matt Corallo + 2019-10-25T17:30:00.000Z + + + Jeremy + 2019-10-27T19:13:00.000Z + + + David A. Harding + 2019-10-27T22:54:00.000Z + + + Johan Torås Halseth + 2019-10-28T09:45:00.000Z + + + David A. Harding + 2019-10-28T17:14:00.000Z + + + Johan Torås Halseth + 2019-10-30T07:22:00.000Z + + @@ -79,13 +77,13 @@ - python-feedgen + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 + 2025-09-26T15:31:25.955032+00:00 - In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly 2019-10-30T07:22:53+00:00 + In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2018/combined_Considering-starting-a-toy-full-node-implementation-Any-advice-.xml b/static/bitcoin-dev/Nov_2018/combined_Considering-starting-a-toy-full-node-implementation-Any-advice-.xml index 1ff04d194c..b05997fa9f 100644 --- a/static/bitcoin-dev/Nov_2018/combined_Considering-starting-a-toy-full-node-implementation-Any-advice-.xml +++ b/static/bitcoin-dev/Nov_2018/combined_Considering-starting-a-toy-full-node-implementation-Any-advice-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Considering starting a toy full-node implementation. Any advice? - 2023-08-01T23:58:22.973831+00:00 + 2025-09-26T15:31:28.067889+00:00 + python-feedgen John C. Vernaleo 2018-11-07 16:19:26+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Considering starting a toy full-node implementation. Any advice? - 2023-08-01T23:58:22.973831+00:00 + 2025-09-26T15:31:28.068018+00:00 - In a message to the bitcoin-dev mailing list, an individual expressed their intention to develop a toy full-node implementation for educational purposes. They sought advice on which resources to use as a reference for the protocol, where to start, and any general tips or advice for such a project. Artem, in response, advised the individual to start small and take small steps, such as connecting to nodes and downloading blocks. They also suggested that the individual should not dismiss the idea of creating a wallet or mining capabilities, as these can provide a good understanding of keys and transactions. Additionally, Artem warned that the individual should be prepared to work with large and diverse sets of data. They also mentioned that new exploitable signatures are unlikely to be found, as there are constantly bots scanning the blockchain for weak keys and signatures.Artem provided several references for the individual, including bitcoin.org/en/developer-reference, en.bitcoin.it/wiki/Protocol_documentation, and github.com/bitcoin/bips. They wished the individual luck and fun in their project. The individual mentioned considering using btcd as a reference since they are unfamiliar with C++. They clarified that they do not intend to include a wallet or mining capabilities in their implementation. It is worth mentioning that one reply in the discussion warned against using an SSD or SD card due to the potential damage caused by repeated downloading of the blockchain, based on previous experiences. Finally, another reply cautioned about the presence of artwork and puzzles in the early blockchain, highlighting its historical significance. 2018-11-07T16:19:26+00:00 + In a message to the bitcoin-dev mailing list, an individual expressed their intention to develop a toy full-node implementation for educational purposes. They sought advice on which resources to use as a reference for the protocol, where to start, and any general tips or advice for such a project. Artem, in response, advised the individual to start small and take small steps, such as connecting to nodes and downloading blocks. They also suggested that the individual should not dismiss the idea of creating a wallet or mining capabilities, as these can provide a good understanding of keys and transactions. Additionally, Artem warned that the individual should be prepared to work with large and diverse sets of data. They also mentioned that new exploitable signatures are unlikely to be found, as there are constantly bots scanning the blockchain for weak keys and signatures.Artem provided several references for the individual, including bitcoin.org/en/developer-reference, en.bitcoin.it/wiki/Protocol_documentation, and github.com/bitcoin/bips. They wished the individual luck and fun in their project. The individual mentioned considering using btcd as a reference since they are unfamiliar with C++. They clarified that they do not intend to include a wallet or mining capabilities in their implementation. It is worth mentioning that one reply in the discussion warned against using an SSD or SD card due to the potential damage caused by repeated downloading of the blockchain, based on previous experiences. Finally, another reply cautioned about the presence of artwork and puzzles in the early blockchain, highlighting its historical significance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2018/combined_Multi-party-Schnorr-Rust-implementation.xml b/static/bitcoin-dev/Nov_2018/combined_Multi-party-Schnorr-Rust-implementation.xml index 7a990bbf1e..900d634105 100644 --- a/static/bitcoin-dev/Nov_2018/combined_Multi-party-Schnorr-Rust-implementation.xml +++ b/static/bitcoin-dev/Nov_2018/combined_Multi-party-Schnorr-Rust-implementation.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Multi party Schnorr Rust implementation - 2023-08-02T00:09:49.548865+00:00 - - Jonas Nick 2018-11-28 16:43:12+00:00 - - - Anthony Towns 2018-11-28 10:49:46+00:00 - - - Omer Shlomovits 2018-11-28 08:13:08+00:00 - - - Devrandom 2018-11-28 06:33:30+00:00 - - - Omer Shlomovits 2018-11-27 17:52:51+00:00 - + 2025-09-26T15:31:34.329227+00:00 + python-feedgen + + + [bitcoin-dev] Multi party Schnorr Rust implementation Omer Shlomovits + 2018-11-27T17:52:00.000Z + + + Devrandom + 2018-11-28T06:33:00.000Z + + + Omer Shlomovits + 2018-11-28T08:13:00.000Z + + + Anthony Towns + 2018-11-28T10:49:00.000Z + + + Jonas Nick + 2018-11-28T16:43:00.000Z + + - python-feedgen + 2 Combined summary - Multi party Schnorr Rust implementation - 2023-08-02T00:09:49.548865+00:00 + 2025-09-26T15:31:34.330005+00:00 - In the Bitcoin-dev mailing list discussion, the topic of non-interactive threshold signatures and their suitability for air-gapped use cases was raised. A workaround was proposed to achieve almost true non-interactivity. The protocol involves several phases, starting with producing secret nonces and calculating public nonces. These values are then shared among participants, and received nonces are checked for consistency. When a signing request is made, if the nonce has already been used, the process is aborted. Otherwise, the signer calculates the signature and shares it. This approach allows for multiple signatures to be done during a set period of time.To ensure that the same nonce is not used with a different message, some state needs to be kept instead of generating the nonce based on the message and private key. The workaround involves batching signing requests into four phases. In phase 1, secret nonces are produced and public nonces are calculated. The hashes of these nonces are then shared. In phase 2, other parties' hashes are stored, and the public nonces are shared. In phase 3, the received nonces are checked for consistency. Finally, in phase 4, a signing request is made, and if the nonce has already been used, the process is aborted. Otherwise, the signer calculates the signature and shares it.This process can also be combined so that when a signing request is received, the user checks the consistency of the received nonce, calculates a new nonce by summing up all the nonces, and performs the signature. This allows for an untrusted app to coordinate the signing process and handle the communication. It is important to note that this workaround is almost as good as true non-interactivity if the signing hardware is capable of securely storing and updating a few kilobytes of state.In another discussion on the bitcoin-dev mailing list, the search for non-interactive threshold signatures continues. The current best solution involves using the DKG from GG18 without Paillier and the DLog PoK for the threshold Schnorr DKG and ephemeral key distributed generation. This solution aims to replace hardware security with threshold security, assuming that it is better to trust that no more than a certain number of machines will get corrupted at the same time. However, candidates for non-interactive threshold signatures seem to be lacking. The author provides links to relevant whitepapers and implementations for further reference.In addition to the mailing list discussions, the author, Omer Shlomovits, has been working on Rust reference implementations for multi-party schemes for Schnorr signatures. These include aggregated signatures, accountable signatures, and threshold signatures (work in progress). The project can be found on GitHub and aims to be bip-schnorr compliant when run in a single party configuration. Omer welcomes questions, suggestions, and pull requests from the community. Links to relevant papers and BIPs are provided for further information. 2018-11-28T16:43:12+00:00 + In the Bitcoin-dev mailing list discussion, the topic of non-interactive threshold signatures and their suitability for air-gapped use cases was raised. A workaround was proposed to achieve almost true non-interactivity. The protocol involves several phases, starting with producing secret nonces and calculating public nonces. These values are then shared among participants, and received nonces are checked for consistency. When a signing request is made, if the nonce has already been used, the process is aborted. Otherwise, the signer calculates the signature and shares it. This approach allows for multiple signatures to be done during a set period of time.To ensure that the same nonce is not used with a different message, some state needs to be kept instead of generating the nonce based on the message and private key. The workaround involves batching signing requests into four phases. In phase 1, secret nonces are produced and public nonces are calculated. The hashes of these nonces are then shared. In phase 2, other parties' hashes are stored, and the public nonces are shared. In phase 3, the received nonces are checked for consistency. Finally, in phase 4, a signing request is made, and if the nonce has already been used, the process is aborted. Otherwise, the signer calculates the signature and shares it.This process can also be combined so that when a signing request is received, the user checks the consistency of the received nonce, calculates a new nonce by summing up all the nonces, and performs the signature. This allows for an untrusted app to coordinate the signing process and handle the communication. It is important to note that this workaround is almost as good as true non-interactivity if the signing hardware is capable of securely storing and updating a few kilobytes of state.In another discussion on the bitcoin-dev mailing list, the search for non-interactive threshold signatures continues. The current best solution involves using the DKG from GG18 without Paillier and the DLog PoK for the threshold Schnorr DKG and ephemeral key distributed generation. This solution aims to replace hardware security with threshold security, assuming that it is better to trust that no more than a certain number of machines will get corrupted at the same time. However, candidates for non-interactive threshold signatures seem to be lacking. The author provides links to relevant whitepapers and implementations for further reference.In addition to the mailing list discussions, the author, Omer Shlomovits, has been working on Rust reference implementations for multi-party schemes for Schnorr signatures. These include aggregated signatures, accountable signatures, and threshold signatures (work in progress). The project can be found on GitHub and aims to be bip-schnorr compliant when run in a single party configuration. Omer welcomes questions, suggestions, and pull requests from the community. Links to relevant papers and BIPs are provided for further information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2018/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml b/static/bitcoin-dev/Nov_2018/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml index 4eccfe3713..c5df914239 100644 --- a/static/bitcoin-dev/Nov_2018/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml +++ b/static/bitcoin-dev/Nov_2018/combined_Safer-sighashes-and-more-granular-SIGHASH-NOINPUT.xml @@ -1,173 +1,15 @@ - + 2 Combined summary - Safer sighashes and more granular SIGHASH_NOINPUT - 2023-08-02T00:02:39.338876+00:00 - - Pieter Wuille 2019-02-09 00:39:54+00:00 - - - Johnson Lau 2018-12-24 21:23:44+00:00 - - - ZmnSCPxj 2018-12-24 12:01:58+00:00 - - - Johnson Lau 2018-12-23 16:33:48+00:00 - - - Anthony Towns 2018-12-23 04:26:59+00:00 - - - Johnson Lau 2018-12-21 18:54:42+00:00 - - - Rusty Russell 2018-12-20 23:17:15+00:00 - - - Johnson Lau 2018-12-20 19:34:38+00:00 - - - Rusty Russell 2018-12-19 00:39:26+00:00 - - - Peter Todd 2018-12-18 04:22:58+00:00 - - - Johnson Lau 2018-12-17 19:08:26+00:00 - - - Rusty Russell 2018-12-17 03:10:42+00:00 - - - Rusty Russell 2018-12-16 06:55:48+00:00 - - - Johnson Lau 2018-12-14 13:55:43+00:00 - - - Anthony Towns 2018-12-14 09:30:02+00:00 - - - Anthony Towns 2018-12-14 00:47:29+00:00 - - - Russell O'Connor 2018-12-13 16:50:10+00:00 - - - Russell O'Connor 2018-12-13 16:34:17+00:00 - - - Russell O'Connor 2018-12-13 16:21:10+00:00 - - - Rusty Russell 2018-12-13 00:37:28+00:00 - - - Anthony Towns 2018-12-13 00:24:38+00:00 - - - Anthony Towns 2018-12-13 00:05:53+00:00 - - - Rusty Russell 2018-12-12 23:49:02+00:00 - - - Johnson Lau 2018-12-12 20:00:50+00:00 - - - Johnson Lau 2018-12-12 19:53:38+00:00 - - - Rusty Russell 2018-12-12 09:42:10+00:00 - - - Russell O'Connor 2018-12-11 22:50:24+00:00 - - - David A. Harding 2018-12-11 17:47:24+00:00 - - - Russell O'Connor 2018-12-11 15:36:59+00:00 - - - David A. Harding 2018-12-09 22:41:57+00:00 - - - Johnson Lau 2018-12-09 19:13:34+00:00 - - - Russell O'Connor 2018-12-06 16:57:09+00:00 - - - Christian Decker 2018-11-29 18:29:10+00:00 - - - Christian Decker 2018-11-29 17:00:09+00:00 - - - Bob McElrath 2018-11-28 14:04:13+00:00 - - - Johnson Lau 2018-11-28 08:40:34+00:00 - - - Johnson Lau 2018-11-28 08:31:48+00:00 - - - Pieter Wuille 2018-11-28 03:41:02+00:00 - - - Bob McElrath 2018-11-28 00:54:16+00:00 - - - Johnson Lau 2018-11-24 08:13:46+00:00 - - - Russell O'Connor 2018-11-23 20:18:13+00:00 - - - Johnson Lau 2018-11-23 10:47:10+00:00 - - - Christian Decker 2018-11-23 09:40:20+00:00 - - - Anthony Towns 2018-11-23 06:04:04+00:00 - - - Anthony Towns 2018-11-23 05:03:30+00:00 - - - Russell O'Connor 2018-11-22 22:10:11+00:00 - - - Johnson Lau 2018-11-22 20:52:54+00:00 - - - Russell O'Connor 2018-11-22 16:23:54+00:00 - - - Johnson Lau 2018-11-22 14:28:35+00:00 - - - Johnson Lau 2018-11-21 17:55:22+00:00 - - - Russell O'Connor 2018-11-21 17:07:30+00:00 - - - Christian Decker 2018-11-21 11:20:44+00:00 - - - Christian Decker 2018-11-21 11:15:44+00:00 - - - Anthony Towns 2018-11-20 20:29:04+00:00 - - - Pieter Wuille 2018-11-19 22:37:57+00:00 - + 2025-09-26T15:31:36.418471+00:00 + python-feedgen + + + Pieter Wuille + 2019-02-09T00:39:00.000Z + + @@ -223,13 +65,13 @@ - python-feedgen + 2 Combined summary - Safer sighashes and more granular SIGHASH_NOINPUT - 2023-08-02T00:02:39.340876+00:00 + 2025-09-26T15:31:36.418873+00:00 - In recent discussions among Bitcoin developers, several proposals and considerations were raised regarding the Bitcoin protocol. Pieter Wuille raised concerns about the reuse of OP_MASK and SIGHASH_NOINPUT, with the latter posing a greater risk. Realistic risks associated with NOINPUT were discussed, and output tagging was suggested as an alternative. A proposed script involving CODESEPARATOR was presented, which could eliminate the need for certain cases under taproot. The use of CODESEPARATOR for Scriptless Script without Schnorr was also mentioned.There were debates on the usefulness of OP_CODESEPARATOR under Taproot. Some argued that committing to the masked script is not necessary if best practices are followed, while others believed that using IF+CODESEP approach could be cheaper for certain scripts. The usability and security of OP_CODESEPARATOR with NOINPUT were questioned, but its usefulness in some cases was acknowledged.The discussions also touched upon witness weight malleability in Bitcoin Script and the proposal to use a 64-byte signature for the default "signing all" sighash. There were concerns about estimating witness weight in multisig cases. The discussion explored the possibility of transforming any script into an equivalent one that avoids witness weight malleability.The role of scriptmask in a taproot world and its tradeoff with security were discussed. Opcodes like IF, NOTIF, VERIFY, DROP, and arithmetic opcodes accepting CScriptNum inputs posed challenges. Suggestions were made to eliminate witness weight malleability in practice through policies and consensus enforcement.The discussions also covered topics such as the implementation of covenants/vaults using NOINPUT, changes to Bitcoin script, the efficiency of the sighash cache, and the removal of OP_CODESEPARATOR.In summary, the discussions revolved around various proposals and considerations related to Bitcoin Script, including mask complexity, witness weight malleability, sighash flags, opcodes, and their impact on security and functionality. The ongoing efforts of the Bitcoin development community to improve the efficiency, security, and flexibility of the Bitcoin protocol were reflected in these discussions.The Bitcoin development community is currently exploring options for replacing OP_CODESEPARATOR, which takes a significant amount of time to execute. One suggestion is to add an internal counter that increments with every control flow operator, allowing signatures to cover the value of this counter or the index of the block within the Bitcoin Script program. The community is open to any solution that can replace the functionality of OP_CODESEPARATOR.Anthony Towns, a member of the Bitcoin development community, has raised concerns about the implementation of NOINPUT in the BIP 118 specification. He suggests that implementing NOINPUT implies the ANYONECANPAY feature, but removing the blanking of the 'hashSequence' field may affect this implication. Christian, another community member, agrees that there may not be a good use case for keeping the number of inputs with NOINPUT.Pieter Wuille, a Bitcoin Core developer, has proposed additions to the sighash for future segwit versions. These additions include committing to the absolute transaction fee and scriptPubKey in addition to the scriptCode. To prevent lying about the type of output being spent, these additions are made optional. Wuille's proposal introduces three new sighash flags: SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK. He also suggests adding a new opcode, OP_MASK, which acts as a NOP during execution.The computation of the sighash would follow the BIP143 method, with modifications based on the presence of the new flags. If SIGHASH_SCRIPTMASK is present, every subsequent opcode/push after an OP_MASK in scriptCode is removed. The scriptPubKey being spent is added to the sighash unless SIGHASH_SCRIPTMASK is set. The transaction fee is added to the sighash unless SIGHASH_NOFEE is set. Additionally, when SIGHASH_NOINPUT is set, hashPrevouts, hashSequence, and outpoint are set to null.Christian expresses concern about introducing a new opcode to mask things in the sighash, but considers it a minor issue. He also notes that Wuille's proposal may address some downsides of BIP118 by committing to the script when possible. Wuille seeks feedback on whether his proposal introduces redundant flexibility or overlooks any obvious use cases.In summary, Pieter Wuille proposes three new sighash flags, namely SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK, along with the addition of a new opcode called OP_MASK. These additions aim to enhance the functionality of the sighash in future segwit versions. The proposal suggests specific modifications to the sighash computation process, including the addition of transaction fee and scriptPubKey commitment. The community is encouraged to provide feedback on these proposals and identify any potential issues or use cases that may have been overlooked. 2019-02-09T00:39:54+00:00 + In recent discussions among Bitcoin developers, several proposals and considerations were raised regarding the Bitcoin protocol. Pieter Wuille raised concerns about the reuse of OP_MASK and SIGHASH_NOINPUT, with the latter posing a greater risk. Realistic risks associated with NOINPUT were discussed, and output tagging was suggested as an alternative. A proposed script involving CODESEPARATOR was presented, which could eliminate the need for certain cases under taproot. The use of CODESEPARATOR for Scriptless Script without Schnorr was also mentioned.There were debates on the usefulness of OP_CODESEPARATOR under Taproot. Some argued that committing to the masked script is not necessary if best practices are followed, while others believed that using IF+CODESEP approach could be cheaper for certain scripts. The usability and security of OP_CODESEPARATOR with NOINPUT were questioned, but its usefulness in some cases was acknowledged.The discussions also touched upon witness weight malleability in Bitcoin Script and the proposal to use a 64-byte signature for the default "signing all" sighash. There were concerns about estimating witness weight in multisig cases. The discussion explored the possibility of transforming any script into an equivalent one that avoids witness weight malleability.The role of scriptmask in a taproot world and its tradeoff with security were discussed. Opcodes like IF, NOTIF, VERIFY, DROP, and arithmetic opcodes accepting CScriptNum inputs posed challenges. Suggestions were made to eliminate witness weight malleability in practice through policies and consensus enforcement.The discussions also covered topics such as the implementation of covenants/vaults using NOINPUT, changes to Bitcoin script, the efficiency of the sighash cache, and the removal of OP_CODESEPARATOR.In summary, the discussions revolved around various proposals and considerations related to Bitcoin Script, including mask complexity, witness weight malleability, sighash flags, opcodes, and their impact on security and functionality. The ongoing efforts of the Bitcoin development community to improve the efficiency, security, and flexibility of the Bitcoin protocol were reflected in these discussions.The Bitcoin development community is currently exploring options for replacing OP_CODESEPARATOR, which takes a significant amount of time to execute. One suggestion is to add an internal counter that increments with every control flow operator, allowing signatures to cover the value of this counter or the index of the block within the Bitcoin Script program. The community is open to any solution that can replace the functionality of OP_CODESEPARATOR.Anthony Towns, a member of the Bitcoin development community, has raised concerns about the implementation of NOINPUT in the BIP 118 specification. He suggests that implementing NOINPUT implies the ANYONECANPAY feature, but removing the blanking of the 'hashSequence' field may affect this implication. Christian, another community member, agrees that there may not be a good use case for keeping the number of inputs with NOINPUT.Pieter Wuille, a Bitcoin Core developer, has proposed additions to the sighash for future segwit versions. These additions include committing to the absolute transaction fee and scriptPubKey in addition to the scriptCode. To prevent lying about the type of output being spent, these additions are made optional. Wuille's proposal introduces three new sighash flags: SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK. He also suggests adding a new opcode, OP_MASK, which acts as a NOP during execution.The computation of the sighash would follow the BIP143 method, with modifications based on the presence of the new flags. If SIGHASH_SCRIPTMASK is present, every subsequent opcode/push after an OP_MASK in scriptCode is removed. The scriptPubKey being spent is added to the sighash unless SIGHASH_SCRIPTMASK is set. The transaction fee is added to the sighash unless SIGHASH_NOFEE is set. Additionally, when SIGHASH_NOINPUT is set, hashPrevouts, hashSequence, and outpoint are set to null.Christian expresses concern about introducing a new opcode to mask things in the sighash, but considers it a minor issue. He also notes that Wuille's proposal may address some downsides of BIP118 by committing to the script when possible. Wuille seeks feedback on whether his proposal introduces redundant flexibility or overlooks any obvious use cases.In summary, Pieter Wuille proposes three new sighash flags, namely SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK, along with the addition of a new opcode called OP_MASK. These additions aim to enhance the functionality of the sighash in future segwit versions. The proposal suggests specific modifications to the sighash computation process, including the addition of transaction fee and scriptPubKey commitment. The community is encouraged to provide feedback on these proposals and identify any potential issues or use cases that may have been overlooked. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2018/combined_draft-proposal-change-forwarding-improved-fungibility-through-wallet-interoperability-.xml b/static/bitcoin-dev/Nov_2018/combined_draft-proposal-change-forwarding-improved-fungibility-through-wallet-interoperability-.xml index 3cdb177909..5eaba9bc9c 100644 --- a/static/bitcoin-dev/Nov_2018/combined_draft-proposal-change-forwarding-improved-fungibility-through-wallet-interoperability-.xml +++ b/static/bitcoin-dev/Nov_2018/combined_draft-proposal-change-forwarding-improved-fungibility-through-wallet-interoperability-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - draft proposal: change forwarding (improved fungibility through wallet interoperability) - 2023-08-01T23:57:16.773016+00:00 - - Yuval Kogman 2018-12-01 15:33:52+00:00 - - - James MacWhyte 2018-12-01 05:06:29+00:00 - - - Yuval Kogman 2018-11-06 15:50:38+00:00 - + 2025-09-26T15:31:30.152468+00:00 + python-feedgen + + + [bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability) Yuval Kogman + 2018-11-06T15:50:00.000Z + + + James MacWhyte + 2018-12-01T05:06:00.000Z + + + Yuval Kogman + 2018-12-01T15:33:00.000Z + + - python-feedgen + 2 Combined summary - draft proposal: change forwarding (improved fungibility through wallet interoperability) - 2023-08-01T23:57:16.773016+00:00 + 2025-09-26T15:31:30.153060+00:00 - In an email thread on the bitcoin-dev mailing list, a proposed method based on BIP32 to improve fungibility and on-chain privacy with wallets that don't prioritize these factors was questioned by James. He sought clarification on the user experience (UX) and how wallet developers could implement this feature. James also raised doubts about why a privacy-conscious user would choose a non-private wallet in the first place, and why a non-privacy-conscious user would bother enabling this option. He expressed skepticism about the proposal's usefulness from a product standpoint and questioned its need to be a BIP.The proposal, introduced by Yuval Kogman, aims to enhance fungibility and on-chain privacy in wallets that do not focus on these aspects. It suggests making minimal changes to safely forward change outputs to more specialized wallets. The draft proposal is still incomplete, with unresolved questions regarding the specific format to use. However, Yuval included two viable options in the proposal, seeking input and criticism from the mailing list. They also mentioned that the proposal is intended to complement more comprehensive proposals like BIP79.Yuval acknowledged the contributions of SirMeow, Adam Ficsor, and Adam Gibson, who reviewed earlier versions of the proposal and provided valuable feedback and suggestions. While Yuval has a slight preference for the first option presented in the proposal, they remain undecided due to tradeoffs. Hence, Yuval reached out to the mailing list for further insights and opinions. 2018-12-01T15:33:52+00:00 + In an email thread on the bitcoin-dev mailing list, a proposed method based on BIP32 to improve fungibility and on-chain privacy with wallets that don't prioritize these factors was questioned by James. He sought clarification on the user experience (UX) and how wallet developers could implement this feature. James also raised doubts about why a privacy-conscious user would choose a non-private wallet in the first place, and why a non-privacy-conscious user would bother enabling this option. He expressed skepticism about the proposal's usefulness from a product standpoint and questioned its need to be a BIP.The proposal, introduced by Yuval Kogman, aims to enhance fungibility and on-chain privacy in wallets that do not focus on these aspects. It suggests making minimal changes to safely forward change outputs to more specialized wallets. The draft proposal is still incomplete, with unresolved questions regarding the specific format to use. However, Yuval included two viable options in the proposal, seeking input and criticism from the mailing list. They also mentioned that the proposal is intended to complement more comprehensive proposals like BIP79.Yuval acknowledged the contributions of SirMeow, Adam Ficsor, and Adam Gibson, who reviewed earlier versions of the proposal and provided valuable feedback and suggestions. While Yuval has a slight preference for the first option presented in the proposal, they remain undecided due to tradeoffs. Hence, Yuval reached out to the mailing list for further insights and opinions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml b/static/bitcoin-dev/Nov_2019/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml index 94e1116eb0..75e39c13ef 100644 --- a/static/bitcoin-dev/Nov_2019/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml +++ b/static/bitcoin-dev/Nov_2019/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml @@ -1,53 +1,55 @@ - + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.880650+00:00 - - Jeremy 2020-09-03 17:47:35+00:00 - - - Jeremy 2020-09-03 17:34:15+00:00 - - - Dmitry Petukhov 2020-09-03 14:42:23+00:00 - - - Dmitry Petukhov 2020-06-08 06:05:45+00:00 - - - Jeremy 2020-06-07 22:45:16+00:00 - - - Joachim Strömbergson 2020-06-07 16:51:10+00:00 - - - ZmnSCPxj 2020-02-15 00:24:37+00:00 - - - Jeremy 2020-02-14 19:16:26+00:00 - - - Dmitry Petukhov 2020-02-14 11:18:26+00:00 - - - Jeremy 2019-12-19 20:08:03+00:00 - - - Jeremy 2019-12-13 23:06:59+00:00 - - - Jeremy 2019-12-11 00:37:59+00:00 - - - Jeremy 2019-11-28 19:59:42+00:00 - - - Russell O'Connor 2019-11-27 21:32:51+00:00 - - - Jeremy 2019-11-26 01:50:40+00:00 - + 2025-09-26T15:33:21.900667+00:00 + python-feedgen + + + Dmitry Petukhov + 2020-02-14T11:18:00.000Z + + + Jeremy + 2020-02-14T19:16:00.000Z + + + ZmnSCPxj + 2020-02-15T00:24:00.000Z + + + Joachim Strömbergson + 2020-06-07T16:51:00.000Z + + + Jeremy + 2020-06-07T22:45:00.000Z + + + Dmitry Petukhov + 2020-06-08T06:05:00.000Z + + + [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation Jeremy + 2020-06-08T06:43:00.000Z + + + Dmitry Petukhov + 2020-06-08T07:15:00.000Z + + + Dmitry Petukhov + 2020-09-03T14:42:00.000Z + + + Jeremy + 2020-09-03T17:34:00.000Z + + + Jeremy + 2020-09-03T17:47:00.000Z + + @@ -63,13 +65,13 @@ - python-feedgen + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.881652+00:00 + 2025-09-26T15:33:21.901972+00:00 - In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast 2020-09-03T17:47:35+00:00 + In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_Bech32-weakness-and-impact-on-bip-taproot-addresses.xml b/static/bitcoin-dev/Nov_2019/combined_Bech32-weakness-and-impact-on-bip-taproot-addresses.xml index a8ac123dcb..add4f069ef 100644 --- a/static/bitcoin-dev/Nov_2019/combined_Bech32-weakness-and-impact-on-bip-taproot-addresses.xml +++ b/static/bitcoin-dev/Nov_2019/combined_Bech32-weakness-and-impact-on-bip-taproot-addresses.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Bech32 weakness and impact on bip-taproot addresses - 2023-08-02T01:30:47.272776+00:00 - - Russell O'Connor 2020-07-15 21:11:11+00:00 - - - Greg Sanders 2020-07-15 21:05:22+00:00 - - - Russell O'Connor 2020-07-15 20:56:12+00:00 - - - Pieter Wuille 2019-11-13 06:30:18+00:00 - - - ZmnSCPxj 2019-11-13 05:32:32+00:00 - - - Clark Moody 2019-11-13 02:56:54+00:00 - - - Matt Corallo 2019-11-11 01:02:15+00:00 - - - Pieter Wuille 2019-11-10 21:51:48+00:00 - - - Damian Mee 2019-11-08 13:42:13+00:00 - - - Russell O'Connor 2019-11-08 13:03:52+00:00 - - - ZmnSCPxj 2019-11-08 05:11:53+00:00 - - - Eric Voskuil 2019-11-08 03:15:53+00:00 - - - David A. Harding 2019-11-08 02:15:41+00:00 - - - Matt Corallo 2019-11-08 00:41:54+00:00 - - - Greg Sanders 2019-11-07 22:45:02+00:00 - - - Pieter Wuille 2019-11-07 22:35:42+00:00 - + 2025-09-26T15:33:38.638700+00:00 + python-feedgen + + + [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses Pieter Wuille + 2019-11-07T22:35:00.000Z + + + Greg Sanders + 2019-11-07T22:45:00.000Z + + + Matt Corallo + 2019-11-08T00:41:00.000Z + + + David A. Harding + 2019-11-08T02:15:00.000Z + + + Eric Voskuil + 2019-11-08T03:15:00.000Z + + + ZmnSCPxj + 2019-11-08T05:11:00.000Z + + + Russell O'Connor + 2019-11-08T13:03:00.000Z + + + Damian Mee + 2019-11-08T13:42:00.000Z + + + Pieter Wuille + 2019-11-10T21:51:00.000Z + + + Matt Corallo + 2019-11-11T01:02:00.000Z + + + Clark Moody + 2019-11-13T02:56:00.000Z + + + ZmnSCPxj + 2019-11-13T05:32:00.000Z + + + Pieter Wuille + 2019-11-13T06:30:00.000Z + + + Russell O'Connor + 2020-07-15T20:56:00.000Z + + + Greg Sanders + 2020-07-15T21:05:00.000Z + + + Russell O'Connor + 2020-07-15T21:11:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - Bech32 weakness and impact on bip-taproot addresses - 2023-08-02T01:30:47.272776+00:00 + 2025-09-26T15:33:38.640488+00:00 - The Bitcoin development community is engaged in discussions regarding potential amendments to BIP173, specifically related to the "bc" and "tb" segwit address formats. Russell O'Connor has proposed restricting these formats to specific witness program sizes, ranging from 20 to 40 bytes. The aim is to enhance security by excluding shorter witness program sizes with insufficient entropy. This proposal comes as a response to Pieter Wuille's suggestion that such restrictions are unnecessary. Greg Sanders seeks clarification on the significance of bold vs not-bold numbers in relation to witness and address lengths.Another proposal by Russell O'Connor suggests length-prefixing the witness program to address the unused characters in the bech32 alphabet. He proposes creating a new human-readable prefix, potentially "btc1," for length-prefixed bitcoin witness programs. However, ZmnSCPxj's proposal to modify the Bech32 SegWit address format was considered impractical.The discussion also includes considerations for accommodating the taproot program, which corresponds to a witness program length of 32 bytes. The use of alternate checksums for Segwit outputs of various lengths is another topic under discussion. Two options have been presented: implementing a consensus or standardness rule to enforce library upgrades, or addressing the issue within the bech32 algorithm itself. David A. Harding advocates for addressing the issue within the bech32 algorithm, despite potential disruptions to batched transactions.In the context of these discussions, Pieter Wuille proposes amending BIP173 to limit witness programs to lengths of 20 or 32, while still allowing other versions besides 0. The idea is to modify the XOR constant in the checksum encoding process to handle various program lengths without creating a new address format or increasing cognitive load for users.Overall, the Bitcoin development community is focused on exploring amendments and improvements to address formats, witness program lengths, and checksums. The goal is to enhance security, prevent unintended spending, and accommodate future developments while minimizing disruption to existing infrastructure.On the Bitcoin-dev mailing list, a discussion has been initiated regarding the implementation of a rule to prevent witness v1 outputs of length other than 32. Currently, these outputs remain unencumbered, allowing anyone to spend them. One option is to outlaw v1 witness outputs of length 31 and 33, but this would require library upgrades for users of v1+ segwit. This issue was previously addressed in problem #15846, and there are two potential ways to address it: implementing a consensus rule or a standardness rule.A vulnerability has been discovered in the bech32 address format where inserting or erasing "q"s before a final "p" does not invalidate it. While this issue may influence design decisions around bip-taproot, it has little effect on the security of P2WPKH/P2WSH addresses as they are only valid for specific lengths. Outlawing unencumbered witness v1 outputs of length other than 32 could prevent such an insertion or erasure from resulting in an output that can be spent by anyone. However, instead of implementing a consensus/standardness fix, it is suggested to redefine bech32 to disallow such addresses.Pieter Wuille, a developer of bitcoin, posted about a mutation weakness in bech32 on the Bitcoin-dev mailing list. Inserting or erasing "q"s before the final "p" in a bech32 string does not invalidate it due to an oversight in the original design. This mutation weakness has little effect on the security of P2WPKH/P2WSH addresses but may impact design decisions around bip-taproot. In the current draft of bip-taproot, witness v1 outputs of length other than 32 remain unencumbered, allowing anyone to spend them. To prevent this, one option is to outlaw v1 witness outputs of length 31 and 33. Pieter apologizes for not catching this issue earlier and seeks thoughts from the community on preventing similar issues in the future. 2020-07-15T21:11:11+00:00 + The Bitcoin development community is engaged in discussions regarding potential amendments to BIP173, specifically related to the "bc" and "tb" segwit address formats. Russell O'Connor has proposed restricting these formats to specific witness program sizes, ranging from 20 to 40 bytes. The aim is to enhance security by excluding shorter witness program sizes with insufficient entropy. This proposal comes as a response to Pieter Wuille's suggestion that such restrictions are unnecessary. Greg Sanders seeks clarification on the significance of bold vs not-bold numbers in relation to witness and address lengths.Another proposal by Russell O'Connor suggests length-prefixing the witness program to address the unused characters in the bech32 alphabet. He proposes creating a new human-readable prefix, potentially "btc1," for length-prefixed bitcoin witness programs. However, ZmnSCPxj's proposal to modify the Bech32 SegWit address format was considered impractical.The discussion also includes considerations for accommodating the taproot program, which corresponds to a witness program length of 32 bytes. The use of alternate checksums for Segwit outputs of various lengths is another topic under discussion. Two options have been presented: implementing a consensus or standardness rule to enforce library upgrades, or addressing the issue within the bech32 algorithm itself. David A. Harding advocates for addressing the issue within the bech32 algorithm, despite potential disruptions to batched transactions.In the context of these discussions, Pieter Wuille proposes amending BIP173 to limit witness programs to lengths of 20 or 32, while still allowing other versions besides 0. The idea is to modify the XOR constant in the checksum encoding process to handle various program lengths without creating a new address format or increasing cognitive load for users.Overall, the Bitcoin development community is focused on exploring amendments and improvements to address formats, witness program lengths, and checksums. The goal is to enhance security, prevent unintended spending, and accommodate future developments while minimizing disruption to existing infrastructure.On the Bitcoin-dev mailing list, a discussion has been initiated regarding the implementation of a rule to prevent witness v1 outputs of length other than 32. Currently, these outputs remain unencumbered, allowing anyone to spend them. One option is to outlaw v1 witness outputs of length 31 and 33, but this would require library upgrades for users of v1+ segwit. This issue was previously addressed in problem #15846, and there are two potential ways to address it: implementing a consensus rule or a standardness rule.A vulnerability has been discovered in the bech32 address format where inserting or erasing "q"s before a final "p" does not invalidate it. While this issue may influence design decisions around bip-taproot, it has little effect on the security of P2WPKH/P2WSH addresses as they are only valid for specific lengths. Outlawing unencumbered witness v1 outputs of length other than 32 could prevent such an insertion or erasure from resulting in an output that can be spent by anyone. However, instead of implementing a consensus/standardness fix, it is suggested to redefine bech32 to disallow such addresses.Pieter Wuille, a developer of bitcoin, posted about a mutation weakness in bech32 on the Bitcoin-dev mailing list. Inserting or erasing "q"s before the final "p" in a bech32 string does not invalidate it due to an oversight in the original design. This mutation weakness has little effect on the security of P2WPKH/P2WSH addresses but may impact design decisions around bip-taproot. In the current draft of bip-taproot, witness v1 outputs of length other than 32 remain unencumbered, allowing anyone to spend them. To prevent this, one option is to outlaw v1 witness outputs of length 31 and 33. Pieter apologizes for not catching this issue earlier and seeks thoughts from the community on preventing similar issues in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_CVE-2017-18350-disclosure.xml b/static/bitcoin-dev/Nov_2019/combined_CVE-2017-18350-disclosure.xml index 47ff430918..fd6faf083b 100644 --- a/static/bitcoin-dev/Nov_2019/combined_CVE-2017-18350-disclosure.xml +++ b/static/bitcoin-dev/Nov_2019/combined_CVE-2017-18350-disclosure.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - CVE-2017-18350 disclosure - 2023-08-02T01:32:03.476543+00:00 - - Aymeric Vitte 2019-11-10 00:23:03+00:00 - - - Aymeric Vitte 2019-11-09 19:33:25+00:00 - - - Aymeric Vitte 2019-11-08 19:40:17+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2019-11-08 17:03:02+00:00 - - - Luke Dashjr 2019-11-08 15:07:36+00:00 - + 2025-09-26T15:33:19.785361+00:00 + python-feedgen + + + [bitcoin-dev] CVE-2017-18350 disclosure Luke Dashjr + 2019-11-08T15:07:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2019-11-08T17:03:00.000Z + + + Aymeric Vitte + 2019-11-08T19:40:00.000Z + + + Aymeric Vitte + 2019-11-09T19:33:00.000Z + + + Aymeric Vitte + 2019-11-10T00:23:00.000Z + + - python-feedgen + 2 Combined summary - CVE-2017-18350 disclosure - 2023-08-02T01:32:03.476543+00:00 + 2025-09-26T15:33:19.786198+00:00 - The discussion revolves around the use of SOCKS proxy and the Tor network with Bitcoin. One participant argues that using Bitcoin on the Tor network is not advisable due to its centralized structure and limited capacity, but using the Tor protocol for Bitcoin can add encryption and anonymity. He recommends using node-Tor, an open-source project designed for p2p, to relay the Bitcoin anonymized protocol using the Tor protocol between nodes. Another participant believes that SOCKS proxies have their use in controlled gateway infrastructure and that the Tor project is designed to allow anonymity and connection privacy. They argue that reducing Tor connectivity would be detrimental.The conversation also touches upon the disclosure of a buffer overflow vulnerability, CVE-2017-18350, which allows a malicious SOCKS proxy server to overwrite the program stack on systems with a signed char type. The vulnerability was discovered by practicalswift in 2017 and fixed in v0.15.1 of Bitcoin Core on November 9, 2017. It was initially introduced in v0.7.0rc1 of Bitcoin Core on August 27, 2012. The fix involved changing the dummy buffer to an explicitly unsigned data type to prevent conversion to/from a negative number. The existence of the vulnerability was disclosed to the bitcoin-dev mailing list in June 2019.In addition to Bitcoin Core, the email signature of one participant contains links related to Bitcoin and Zcash wallets, torrent blocklists, and anti-spy measures. The discussion highlights the advantages and disadvantages of using SOCKS proxy and the Tor network with Bitcoin, emphasizing the importance of understanding the potential vulnerabilities and risks associated with them. The focus should be on anonymizing Bitcoin when required and making it a true peer-to-peer network. 2019-11-10T00:23:03+00:00 + The discussion revolves around the use of SOCKS proxy and the Tor network with Bitcoin. One participant argues that using Bitcoin on the Tor network is not advisable due to its centralized structure and limited capacity, but using the Tor protocol for Bitcoin can add encryption and anonymity. He recommends using node-Tor, an open-source project designed for p2p, to relay the Bitcoin anonymized protocol using the Tor protocol between nodes. Another participant believes that SOCKS proxies have their use in controlled gateway infrastructure and that the Tor project is designed to allow anonymity and connection privacy. They argue that reducing Tor connectivity would be detrimental.The conversation also touches upon the disclosure of a buffer overflow vulnerability, CVE-2017-18350, which allows a malicious SOCKS proxy server to overwrite the program stack on systems with a signed char type. The vulnerability was discovered by practicalswift in 2017 and fixed in v0.15.1 of Bitcoin Core on November 9, 2017. It was initially introduced in v0.7.0rc1 of Bitcoin Core on August 27, 2012. The fix involved changing the dummy buffer to an explicitly unsigned data type to prevent conversion to/from a negative number. The existence of the vulnerability was disclosed to the bitcoin-dev mailing list in June 2019.In addition to Bitcoin Core, the email signature of one participant contains links related to Bitcoin and Zcash wallets, torrent blocklists, and anti-spy measures. The discussion highlights the advantages and disadvantages of using SOCKS proxy and the Tor network with Bitcoin, emphasizing the importance of understanding the potential vulnerabilities and risks associated with them. The focus should be on anonymizing Bitcoin when required and making it a true peer-to-peer network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_Composable-MuSig.xml b/static/bitcoin-dev/Nov_2019/combined_Composable-MuSig.xml index 824d68bc56..f4c91b2508 100644 --- a/static/bitcoin-dev/Nov_2019/combined_Composable-MuSig.xml +++ b/static/bitcoin-dev/Nov_2019/combined_Composable-MuSig.xml @@ -1,38 +1,27 @@ - + 2 Combined summary - Composable MuSig - 2023-08-02T01:34:08.477767+00:00 - - Tim Ruffing 2020-02-24 16:56:06+00:00 - - - Erik Aronesty 2020-02-24 15:30:54+00:00 - - - Tim Ruffing 2020-02-24 11:16:38+00:00 - - - Erik Aronesty 2020-02-23 07:27:39+00:00 - - - Lloyd Fournier 2019-12-08 06:10:00+00:00 - - - ZmnSCPxj 2019-12-08 01:15:51+00:00 - - - Lloyd Fournier 2019-12-02 03:30:26+00:00 - - - ZmnSCPxj 2019-12-02 02:05:01+00:00 - - - Lloyd Fournier 2019-11-29 05:50:33+00:00 - - - ZmnSCPxj 2019-11-25 11:00:22+00:00 - + 2025-09-26T15:33:30.258859+00:00 + python-feedgen + + + Erik Aronesty + 2020-02-23T07:27:00.000Z + + + Tim Ruffing + 2020-02-24T11:16:00.000Z + + + Erik Aronesty + 2020-02-24T15:30:00.000Z + + + Tim Ruffing + 2020-02-24T16:56:00.000Z + + @@ -43,13 +32,13 @@ - python-feedgen + 2 Combined summary - Composable MuSig - 2023-08-02T01:34:08.477767+00:00 + 2025-09-26T15:33:30.259670+00:00 - The discussion on the bitcoin-dev mailing list focuses on preventing repeated signings of the same message and using a "validity" time window to limit an attacker's control. The Drijvers, et al paper addresses parallel and aborted signings, where ksums can be used. Adding a signature timeout to the message is proposed as a solution, where participants refuse to sign if the time is too far in the future or if a message has been used previously within that time window.There are concerns about the safety of two-phase MuSig, with reference to a paper arguing it may be unsafe due to the number of parallel sessions. It is suggested that using 3-round MuSig could eliminate this issue.The MuSig protocol is discussed, highlighting its vulnerability to attacks when used in compositions. A proposal called Multi-R is introduced to address this problem by allowing participants to submit multiple R commitments. Alternative proposals involving Pedersen or ElGamal commitments are also mentioned but found to have security flaws.A composable commitment scheme appropriate for MuSig R coin tossing is discussed, with the author stating that deeper analysis is needed to determine the requirements of MuSig for the commitment scheme. The author suggests that Schnorr and ECDSA signatures can be viewed as commitment schemes on points and proposes using them as composable commitments in a MuSig scheme.Pedersen commitments are discussed in relation to MuSig R coin tossing, suggesting that using `X` committed with Pedersen commitments in place of `q * G` in an ElGamal commitment can prevent cancellation attacks. However, alternative methods involving Schnorr signatures and using contributions `R[a]` and `R[b]` as public keys are also suggested, albeit with increased complexity.The MuSig composition problem is addressed, emphasizing the need for the three-phase MuSig protocol instead of the potentially unsafe two-phase variant when one participant is an aggregate entity. The potential security issues of the two-phase protocol and the Wagner Generalized Birthday Paradox attack are highlighted. The Multi-R proposal is suggested as a modification to address this vulnerability.The Lightning Nodelets proposal on lightning-dev is discussed, mentioning the use of MuSig on public keys of participants and the need for one or more participants to be an aggregate entity. The MuSig composition problem arises when there is a possibility of participant equality. The three-phase MuSig protocol is described, along with its potential vulnerabilities and proposed solutions such as the Multi-R proposal.Overall, the discussion focuses on addressing the security flaws of the MuSig protocol, proposing various solutions including signature timeouts, multi-round MuSig, composable commitment schemes, and modifications to the protocol structure. 2020-02-24T16:56:06+00:00 + The discussion on the bitcoin-dev mailing list focuses on preventing repeated signings of the same message and using a "validity" time window to limit an attacker's control. The Drijvers, et al paper addresses parallel and aborted signings, where ksums can be used. Adding a signature timeout to the message is proposed as a solution, where participants refuse to sign if the time is too far in the future or if a message has been used previously within that time window.There are concerns about the safety of two-phase MuSig, with reference to a paper arguing it may be unsafe due to the number of parallel sessions. It is suggested that using 3-round MuSig could eliminate this issue.The MuSig protocol is discussed, highlighting its vulnerability to attacks when used in compositions. A proposal called Multi-R is introduced to address this problem by allowing participants to submit multiple R commitments. Alternative proposals involving Pedersen or ElGamal commitments are also mentioned but found to have security flaws.A composable commitment scheme appropriate for MuSig R coin tossing is discussed, with the author stating that deeper analysis is needed to determine the requirements of MuSig for the commitment scheme. The author suggests that Schnorr and ECDSA signatures can be viewed as commitment schemes on points and proposes using them as composable commitments in a MuSig scheme.Pedersen commitments are discussed in relation to MuSig R coin tossing, suggesting that using `X` committed with Pedersen commitments in place of `q * G` in an ElGamal commitment can prevent cancellation attacks. However, alternative methods involving Schnorr signatures and using contributions `R[a]` and `R[b]` as public keys are also suggested, albeit with increased complexity.The MuSig composition problem is addressed, emphasizing the need for the three-phase MuSig protocol instead of the potentially unsafe two-phase variant when one participant is an aggregate entity. The potential security issues of the two-phase protocol and the Wagner Generalized Birthday Paradox attack are highlighted. The Multi-R proposal is suggested as a modification to address this vulnerability.The Lightning Nodelets proposal on lightning-dev is discussed, mentioning the use of MuSig on public keys of participants and the need for one or more participants to be an aggregate entity. The MuSig composition problem arises when there is a possibility of participant equality. The three-phase MuSig protocol is described, along with its potential vulnerabilities and proposed solutions such as the Multi-R proposal.Overall, the discussion focuses on addressing the security flaws of the MuSig protocol, proposing various solutions including signature timeouts, multi-round MuSig, composable commitment schemes, and modifications to the protocol structure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_Draft-BIP-for-SNICKER.xml b/static/bitcoin-dev/Nov_2019/combined_Draft-BIP-for-SNICKER.xml index 532ee3f67b..f72c083a79 100644 --- a/static/bitcoin-dev/Nov_2019/combined_Draft-BIP-for-SNICKER.xml +++ b/static/bitcoin-dev/Nov_2019/combined_Draft-BIP-for-SNICKER.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Draft BIP for SNICKER - 2023-08-02T01:18:16.750104+00:00 - - AdamISZ 2019-11-23 12:43:27+00:00 - - - popo 2019-11-22 14:57:10+00:00 - - - AdamISZ 2019-11-22 14:02:56+00:00 - - - Riccardo Casatta 2019-11-06 16:52:06+00:00 - - - AdamISZ 2019-10-22 13:21:00+00:00 - - - SomberNight 2019-10-21 15:04:59+00:00 - - - Riccardo Casatta 2019-10-21 11:00:26+00:00 - - - David A. Harding 2019-10-21 00:06:08+00:00 - - - SomberNight 2019-10-20 00:29:25+00:00 - - - AdamISZ 2019-09-01 13:46:57+00:00 - + 2025-09-26T15:33:36.549201+00:00 + python-feedgen + + + [bitcoin-dev] Draft BIP for SNICKER AdamISZ + 2019-09-01T13:46:00.000Z + + + SomberNight + 2019-10-20T00:29:00.000Z + + + David A. Harding + 2019-10-21T00:06:00.000Z + + + Riccardo Casatta + 2019-10-21T11:00:00.000Z + + + SomberNight + 2019-10-21T15:04:00.000Z + + + AdamISZ + 2019-10-22T13:21:00.000Z + + + Riccardo Casatta + 2019-11-06T16:52:00.000Z + + + AdamISZ + 2019-11-22T14:02:00.000Z + + + popo + 2019-11-22T14:57:00.000Z + + + AdamISZ + 2019-11-23T12:43:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for SNICKER - 2023-08-02T01:18:16.750104+00:00 + 2025-09-26T15:33:36.550352+00:00 - The SNICKER proposal aims to provide increased privacy benefits over traditional coinjoin in Bitcoin. It suggests a two-party coinjoin implementation that trades off size for convenience and low effort. However, there are no privacy guarantees, and frequent two-party mixes can degrade blockchain analysis. The proposal involves specialized entities as Proposers, with only the Receiver requiring zero effort. Coinjoin breaks the common input ownership heuristic, and the delinking effect of equal-sized outputs of the same scriptpubkey type is valuable.The discussion on the bitcoin-dev mailing list revolves around the issue of watch-only wallets and the key tweak (`c` as per draft BIP) required for effective coinjoin functionality. Classic watch-only use cases are incompatible with SNICKER, but recovering from zero information and monitoring in real-time as new SNICKER transactions arrive are possible. The `c` values could be sent from the hot to the cold wallets without changing the cold's security model.The email exchange discusses the complexity and cost implications of adding second-stage transactions to SNICKER. It aligns with CoinJoinXT and segwit ideas but may not be implemented. The watch-only issue is addressed, emphasizing the need to keep the key tweak secret to the proposer and receiver. AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer are also mentioned. The discussions have been useful in exploring the potential benefits and limitations of SNICKER.Riccardo Casatta proposes a solution to the watch-only issue in CoinJoin transactions, suggesting the creation of a separate encrypted transaction along with the CoinJoin transaction. AdamISZ responds that adding this complexity may not be feasible due to cost implications. The key tweak `c` must be known by the proposer and receiver but not by anyone else, making it incompatible with classic watch-only use cases. However, sending `c` values from the hot wallet to the cold wallet is possible without changing the cold's security model. The discussions highlight the challenges related to watch-only wallets and the security considerations for Receiver from a Proposer.The SNICKER protocol's recovery process is necessary for wallet recovery, requiring communication between the hot and cold wallets. Monitoring a wallet in real-time with no privkey access is incompatible with this, but hot/cold monitoring is feasible if desired. Ongoing address discovery is required for many use cases of watch-only wallets, which would break without SNICKER's functionality.The implementation of SNICKER in Electrum for the "Receiver" role is discussed, highlighting the incompatibility with watch-only wallets. Interaction with the cold wallet is required, and a recovery procedure is proposed. The candidate transactions can be transferred to the cold wallet using means like USB drives or QR codes, and the cold wallet can perform the necessary steps using its private keys. This process may need to be repeated for subsequent SNICKER rounds.The SNICKER proposal aims to break common chain-analysis assumptions and provide increased privacy benefits. However, it is incompatible with watch-only wallets. Users must choose between using xpubs or participating in SNICKER coinjoins as a Receiver during wallet creation. Adjustments to the scheme are unclear, as the key tweak `c` must be known only by the coinjoin participants.A draft BIP for the SNICKER proposal has been shared, highlighting its ease of implementation for wallet developers. However, there is uncertainty on transaction and encryption specifications.The author of the context has implemented the algorithm used by Electrum, but there are concerns regarding its validity. The author is seeking feedback on their draft to address these concerns. It is important to note that the specific details of the algorithm used by Electrum are not provided in the context. However, the fact that the author has attempted to replicate it suggests that it may play a significant role in their work. To gain a better understanding of the algorithm and its implications, it would be helpful to review the feedback and suggestions provided by others. By incorporating this feedback into their draft, the author can strengthen their work and potentially address any doubts or uncertainties surrounding the algorithm's efficacy. In conclusion, the author has implemented an algorithm similar to the one used by Electrum, but there are doubts about its reliability. The author seeks feedback on their draft to ensure the accuracy and effectiveness of their work. Reviewing the algorithm and considering the feedback received will aid in improving the overall quality and validity of the author's implementation. 2019-11-23T12:43:27+00:00 + The SNICKER proposal aims to provide increased privacy benefits over traditional coinjoin in Bitcoin. It suggests a two-party coinjoin implementation that trades off size for convenience and low effort. However, there are no privacy guarantees, and frequent two-party mixes can degrade blockchain analysis. The proposal involves specialized entities as Proposers, with only the Receiver requiring zero effort. Coinjoin breaks the common input ownership heuristic, and the delinking effect of equal-sized outputs of the same scriptpubkey type is valuable.The discussion on the bitcoin-dev mailing list revolves around the issue of watch-only wallets and the key tweak (`c` as per draft BIP) required for effective coinjoin functionality. Classic watch-only use cases are incompatible with SNICKER, but recovering from zero information and monitoring in real-time as new SNICKER transactions arrive are possible. The `c` values could be sent from the hot to the cold wallets without changing the cold's security model.The email exchange discusses the complexity and cost implications of adding second-stage transactions to SNICKER. It aligns with CoinJoinXT and segwit ideas but may not be implemented. The watch-only issue is addressed, emphasizing the need to keep the key tweak secret to the proposer and receiver. AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer are also mentioned. The discussions have been useful in exploring the potential benefits and limitations of SNICKER.Riccardo Casatta proposes a solution to the watch-only issue in CoinJoin transactions, suggesting the creation of a separate encrypted transaction along with the CoinJoin transaction. AdamISZ responds that adding this complexity may not be feasible due to cost implications. The key tweak `c` must be known by the proposer and receiver but not by anyone else, making it incompatible with classic watch-only use cases. However, sending `c` values from the hot wallet to the cold wallet is possible without changing the cold's security model. The discussions highlight the challenges related to watch-only wallets and the security considerations for Receiver from a Proposer.The SNICKER protocol's recovery process is necessary for wallet recovery, requiring communication between the hot and cold wallets. Monitoring a wallet in real-time with no privkey access is incompatible with this, but hot/cold monitoring is feasible if desired. Ongoing address discovery is required for many use cases of watch-only wallets, which would break without SNICKER's functionality.The implementation of SNICKER in Electrum for the "Receiver" role is discussed, highlighting the incompatibility with watch-only wallets. Interaction with the cold wallet is required, and a recovery procedure is proposed. The candidate transactions can be transferred to the cold wallet using means like USB drives or QR codes, and the cold wallet can perform the necessary steps using its private keys. This process may need to be repeated for subsequent SNICKER rounds.The SNICKER proposal aims to break common chain-analysis assumptions and provide increased privacy benefits. However, it is incompatible with watch-only wallets. Users must choose between using xpubs or participating in SNICKER coinjoins as a Receiver during wallet creation. Adjustments to the scheme are unclear, as the key tweak `c` must be known only by the coinjoin participants.A draft BIP for the SNICKER proposal has been shared, highlighting its ease of implementation for wallet developers. However, there is uncertainty on transaction and encryption specifications.The author of the context has implemented the algorithm used by Electrum, but there are concerns regarding its validity. The author is seeking feedback on their draft to address these concerns. It is important to note that the specific details of the algorithm used by Electrum are not provided in the context. However, the fact that the author has attempted to replicate it suggests that it may play a significant role in their work. To gain a better understanding of the algorithm and its implications, it would be helpful to review the feedback and suggestions provided by others. By incorporating this feedback into their draft, the author can strengthen their work and potentially address any doubts or uncertainties surrounding the algorithm's efficacy. In conclusion, the author has implemented an algorithm similar to the one used by Electrum, but there are doubts about its reliability. The author seeks feedback on their draft to ensure the accuracy and effectiveness of their work. Reviewing the algorithm and considering the feedback received will aid in improving the overall quality and validity of the author's implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_Dynamic-MaxBlockSize-3-Byte-Solution.xml b/static/bitcoin-dev/Nov_2019/combined_Dynamic-MaxBlockSize-3-Byte-Solution.xml index 6c805b5039..2e6865afff 100644 --- a/static/bitcoin-dev/Nov_2019/combined_Dynamic-MaxBlockSize-3-Byte-Solution.xml +++ b/static/bitcoin-dev/Nov_2019/combined_Dynamic-MaxBlockSize-3-Byte-Solution.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Dynamic MaxBlockSize - 3 Byte Solution - 2023-08-02T01:29:49.372749+00:00 - - Luke Dashjr 2019-11-11 19:56:15+00:00 - - - Hampus Sjöberg 2019-11-11 17:10:16+00:00 - - - Luke Dashjr 2019-11-11 16:47:04+00:00 - - - Hampus Sjöberg 2019-11-11 16:08:43+00:00 - - - ZmnSCPxj 2019-11-11 13:52:49+00:00 - - - Alberto Aldave 2019-11-08 17:04:20+00:00 - - - Joachim Strömbergson 2019-11-08 15:19:17+00:00 - - - Emil Engler 2019-11-08 14:36:52+00:00 - - - Trevor Groves 2019-11-07 03:33:36+00:00 - + 2025-09-26T15:33:23.995878+00:00 + python-feedgen + + + [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution Trevor Groves + 2019-11-07T03:33:00.000Z + + + Emil Engler + 2019-11-08T14:36:00.000Z + + + Joachim Strömbergson + 2019-11-08T15:19:00.000Z + + + Alberto Aldave + 2019-11-08T17:04:00.000Z + + + ZmnSCPxj + 2019-11-11T13:52:00.000Z + + + Hampus Sjöberg + 2019-11-11T16:08:00.000Z + + + Luke Dashjr + 2019-11-11T16:47:00.000Z + + + Hampus Sjöberg + 2019-11-11T17:10:00.000Z + + + Luke Dashjr + 2019-11-11T19:56:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Dynamic MaxBlockSize - 3 Byte Solution - 2023-08-02T01:29:49.372749+00:00 + 2025-09-26T15:33:23.996939+00:00 - In a recent discussion on the bitcoin-dev mailing list, Hampus Sjöberg and Luke-Jr debated the current block size of Bitcoin. Hampus suggested that the average block size would decrease when exchanges start using Lightning or Liquid, while Luke disagreed due to spam padding blocks. They also discussed the possibility of increasing the block size, with Hampus advocating for a hard fork and Luke pointing out past malicious attempts. The use of extension blocks was also debated, with Hampus finding them convoluted and Luke arguing they are still a softfork. Both agreed on the importance of consensus in making changes to maintain Bitcoin's stability and security.Another email thread on the bitcoin-dev mailing list focused on the proposal for Dynamic MaxBlockSize (DMBS). This solution suggests adding a 3-byte variable factor to the white space in the current block to adjust the block size based on market demand. The ruleset evaluates factors such as transaction fees and the current block size to determine whether to increase or decrease the block size. Participants expressed differing opinions on the proposal, with some advocating for keeping the block size low and others raising concerns about reorganization and the feasibility of the DMBS solution. The aim is to find a middle ground that allows for dynamic scaling without compromising security or changing existing rules.The fees paid to miners in Bitcoin are economically incentivized and serve as an anonymity technique. To address issues related to block size and scaling, the proposal for Dynamic MaxBlockSize (DMBS) suggests adding a 3-byte variable factor to evaluate market demand. This approach aims to strike a balance between scalability and resource consumption while maintaining existing security measures. The software would evaluate the MaxBlockSize Variable and ActivateONBlock Variable from distributed blocks to provide synchronization. By adjusting the block size according to market demand, the DMBS proposal seeks to address concerns dynamically without compromising security or changing existing rulesets.The proposal for Dynamic MaxBlockSize (DMBS) on the bitcoin-dev mailing list involves adding a 3-byte variable factor to the white space in the current block. The aim is to address block size and scaling concerns without compromising security or changing existing rules. However, some members of the community expressed skepticism, stating that the proposal misunderstands the concept of scaling and may compromise network security. There are also concerns about decentralization if blocks become too large. While Segwit has improved space efficiency, it remains uncertain whether advanced offchain constructions can fully resolve block size issues. Overall, opinions on the viability of the proposed solution are divided.The email thread discussing the proposal for Dynamic MaxBlockSize (DMBS) suggests adding a 3-byte variable factor to evaluate market demand and adjust the block size dynamically. Some members of the community expressed doubts about the necessity of addressing block size concerns due to Lightning and SegWit, while others emphasized the need to test and prove the effectiveness of off-chain constructions like channel factories. The DMBS proposal aims to strike a middle ground by allowing for adjustments based on market demand while maintaining existing security measures. The author seeks feedback on the viability of the solution and its potential to solve scaling issues.A proposal called Dynamic MaxBlockSize (DMBS) has been put forward on the bitcoin-dev mailing list. It involves adding a 3-byte variable factor to the white space in the current block to adjust the maximum block size based on market demand. The ruleset evaluates transaction fees and block sizes to determine whether to increase or decrease the block size. Safety measures are included to prevent bloat and limit changes. Feedback from the community is sought regarding the feasibility of accommodating the 3-byte variable and the value of using extra space to address the scaling issue.The proposal for Dynamic MaxBlockSize (DMBS) suggests adding a 3-byte variable factor to the white space in the current block to evaluate market demand and adjust the block size accordingly. The ruleset considers factors such as transaction fees and current block size to determine whether to increase or decrease the block size. Safety measures are implemented to prevent excessive changes. While some members expressed skepticism towards the proposal, others believe it provides a suitable middle ground solution for scaling without compromising security. The community is asked to provide feedback on the viability of accommodating the 3-byte variable and the effectiveness of solving the scaling issue.The Dynamic MaxBlockSize (DMBS) proposal aims to address the block size issue by adding a 3-byte variable factor to the white space in the current block. The ruleset evaluates market-driven demand and adjusts the block size accordingly. Some members of the community have raised concerns about the feasibility and potential negative impacts of the proposal, while others see it as a middle ground solution that maintains security and existing rulesets. Feedback from the community is solicited to assess the viability of the proposal and its ability to effectively solve scaling issues. 2019-11-11T19:56:15+00:00 + In a recent discussion on the bitcoin-dev mailing list, Hampus Sjöberg and Luke-Jr debated the current block size of Bitcoin. Hampus suggested that the average block size would decrease when exchanges start using Lightning or Liquid, while Luke disagreed due to spam padding blocks. They also discussed the possibility of increasing the block size, with Hampus advocating for a hard fork and Luke pointing out past malicious attempts. The use of extension blocks was also debated, with Hampus finding them convoluted and Luke arguing they are still a softfork. Both agreed on the importance of consensus in making changes to maintain Bitcoin's stability and security.Another email thread on the bitcoin-dev mailing list focused on the proposal for Dynamic MaxBlockSize (DMBS). This solution suggests adding a 3-byte variable factor to the white space in the current block to adjust the block size based on market demand. The ruleset evaluates factors such as transaction fees and the current block size to determine whether to increase or decrease the block size. Participants expressed differing opinions on the proposal, with some advocating for keeping the block size low and others raising concerns about reorganization and the feasibility of the DMBS solution. The aim is to find a middle ground that allows for dynamic scaling without compromising security or changing existing rules.The fees paid to miners in Bitcoin are economically incentivized and serve as an anonymity technique. To address issues related to block size and scaling, the proposal for Dynamic MaxBlockSize (DMBS) suggests adding a 3-byte variable factor to evaluate market demand. This approach aims to strike a balance between scalability and resource consumption while maintaining existing security measures. The software would evaluate the MaxBlockSize Variable and ActivateONBlock Variable from distributed blocks to provide synchronization. By adjusting the block size according to market demand, the DMBS proposal seeks to address concerns dynamically without compromising security or changing existing rulesets.The proposal for Dynamic MaxBlockSize (DMBS) on the bitcoin-dev mailing list involves adding a 3-byte variable factor to the white space in the current block. The aim is to address block size and scaling concerns without compromising security or changing existing rules. However, some members of the community expressed skepticism, stating that the proposal misunderstands the concept of scaling and may compromise network security. There are also concerns about decentralization if blocks become too large. While Segwit has improved space efficiency, it remains uncertain whether advanced offchain constructions can fully resolve block size issues. Overall, opinions on the viability of the proposed solution are divided.The email thread discussing the proposal for Dynamic MaxBlockSize (DMBS) suggests adding a 3-byte variable factor to evaluate market demand and adjust the block size dynamically. Some members of the community expressed doubts about the necessity of addressing block size concerns due to Lightning and SegWit, while others emphasized the need to test and prove the effectiveness of off-chain constructions like channel factories. The DMBS proposal aims to strike a middle ground by allowing for adjustments based on market demand while maintaining existing security measures. The author seeks feedback on the viability of the solution and its potential to solve scaling issues.A proposal called Dynamic MaxBlockSize (DMBS) has been put forward on the bitcoin-dev mailing list. It involves adding a 3-byte variable factor to the white space in the current block to adjust the maximum block size based on market demand. The ruleset evaluates transaction fees and block sizes to determine whether to increase or decrease the block size. Safety measures are included to prevent bloat and limit changes. Feedback from the community is sought regarding the feasibility of accommodating the 3-byte variable and the value of using extra space to address the scaling issue.The proposal for Dynamic MaxBlockSize (DMBS) suggests adding a 3-byte variable factor to the white space in the current block to evaluate market demand and adjust the block size accordingly. The ruleset considers factors such as transaction fees and current block size to determine whether to increase or decrease the block size. Safety measures are implemented to prevent excessive changes. While some members expressed skepticism towards the proposal, others believe it provides a suitable middle ground solution for scaling without compromising security. The community is asked to provide feedback on the viability of accommodating the 3-byte variable and the effectiveness of solving the scaling issue.The Dynamic MaxBlockSize (DMBS) proposal aims to address the block size issue by adding a 3-byte variable factor to the white space in the current block. The ruleset evaluates market-driven demand and adjusts the block size accordingly. Some members of the community have raised concerns about the feasibility and potential negative impacts of the proposal, while others see it as a middle ground solution that maintains security and existing rulesets. Feedback from the community is solicited to assess the viability of the proposal and its ability to effectively solve scaling issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_I-want-to-rebuild-the-GUI-in-JavaScript.xml b/static/bitcoin-dev/Nov_2019/combined_I-want-to-rebuild-the-GUI-in-JavaScript.xml index 71eca24fa9..41abbc6b0c 100644 --- a/static/bitcoin-dev/Nov_2019/combined_I-want-to-rebuild-the-GUI-in-JavaScript.xml +++ b/static/bitcoin-dev/Nov_2019/combined_I-want-to-rebuild-the-GUI-in-JavaScript.xml @@ -1,35 +1,27 @@ - + 2 Combined summary - I want to rebuild the GUI in JavaScript - 2023-08-02T01:33:31.357353+00:00 - - M.K. Safi 2020-01-16 18:30:24+00:00 - - - Daniel Edgecumbe 2019-11-23 20:07:17+00:00 - - - Jonas Schnelli 2019-11-23 18:27:47+00:00 - - - Oscar Lafarga 2019-11-23 16:49:18+00:00 - - - M.K. Safi 2019-11-23 06:45:02+00:00 - + 2025-09-26T15:33:26.086768+00:00 + python-feedgen + + + M.K. Safi + 2020-01-16T18:30:00.000Z + + - python-feedgen + 2 Combined summary - I want to rebuild the GUI in JavaScript - 2023-08-02T01:33:31.357353+00:00 + 2025-09-26T15:33:26.087140+00:00 - In an email thread, the original sender thanks Jonas for his feedback and removes the topic from discussion on the Bitcoin Core Github issue. However, he mentions that he has been working on a proof-of-concept over the past month and has published it on GitHub for those interested in following the progress. He encourages contributions to the project and provides information on how to get involved. Jonas responds to the original sender's email, stating that the topic of rebuilding Bitcoin Core GUI using the JavaScript Electron framework is not appropriate for discussion on the Bitcoin Core Github issue. He suggests that if the original sender wants to pursue this idea, they should work on a third-party project where their Electron UI can connect to Bitcoin Core over RPC. Jonas also explains that adding an Electron/JavaScript UI to the Bitcoin Core repository is unlikely to happen due to concerns raised by Bitcoin Core contributors and users who are opposed to using a browser and JavaScript for a relatively simple user interface. He provides links to relevant Github issues for further reference.The email thread also mentions a front-end for Bitcoin available at bitcoin.electronrelocation.com, but development has been halted due to time constraints. The live demo of this front-end accepts payments and sends them via QR codes. The source code is available on git.esotericnonsense.com.A discussion on rebuilding Bitcoin Core GUI using the JavaScript Electron framework took place on the bitcoin-dev mailing list. One suggestion was to have Electron drive the UI by running bitcoind and communicating with it through RPC. However, there are concerns about achieving feature-parity with the existing Qt implementation and the need for a secure dependency management solution. The possibility of the Electron UI existing as an independent client rather than replacing the Qt UI is also discussed.In a forum post, a user expresses their desire to rebuild Bitcoin Core GUI using the Electron framework and seeks insights into the pros and cons of transitioning from Qt to Electron. However, many Bitcoin Core contributors and users are opposed to using a browser and JavaScript for a UI with simple user-stories. The user is advised to work on a third-party project where their Electron UI can connect to Bitcoin Core over RPC or contribute to incorporating long polling into Bitcoin Core. It is unlikely that an Electron/JavaScript UI will be added to the Bitcoin Core repository. Two relevant links are provided for further reading.The author of the email expresses their interest in rebuilding Bitcoin Core GUI using the Electron framework and asks if there have been any previous attempts or ongoing efforts in this direction. They propose having Electron drive the UI by running bitcoind and communicating with it through RPC but question whether this approach can achieve feature-parity with the Qt implementation, which has direct access to Bitcoin Core code. Another member of the mailing list highlights the need for secure dependency management due to the security-focused nature of Bitcoin Core software and the potential vulnerabilities in the way NPM handles Electron app dependencies. The discussion explores the possibility of the Electron UI existing as an independent client and debates whether it could replace the Qt UI. The topic of rebuilding Bitcoin Core GUI using the Electron framework is being explored with considerations for security and feature parity with the current Qt implementation. 2020-01-16T18:30:24+00:00 + In an email thread, the original sender thanks Jonas for his feedback and removes the topic from discussion on the Bitcoin Core Github issue. However, he mentions that he has been working on a proof-of-concept over the past month and has published it on GitHub for those interested in following the progress. He encourages contributions to the project and provides information on how to get involved. Jonas responds to the original sender's email, stating that the topic of rebuilding Bitcoin Core GUI using the JavaScript Electron framework is not appropriate for discussion on the Bitcoin Core Github issue. He suggests that if the original sender wants to pursue this idea, they should work on a third-party project where their Electron UI can connect to Bitcoin Core over RPC. Jonas also explains that adding an Electron/JavaScript UI to the Bitcoin Core repository is unlikely to happen due to concerns raised by Bitcoin Core contributors and users who are opposed to using a browser and JavaScript for a relatively simple user interface. He provides links to relevant Github issues for further reference.The email thread also mentions a front-end for Bitcoin available at bitcoin.electronrelocation.com, but development has been halted due to time constraints. The live demo of this front-end accepts payments and sends them via QR codes. The source code is available on git.esotericnonsense.com.A discussion on rebuilding Bitcoin Core GUI using the JavaScript Electron framework took place on the bitcoin-dev mailing list. One suggestion was to have Electron drive the UI by running bitcoind and communicating with it through RPC. However, there are concerns about achieving feature-parity with the existing Qt implementation and the need for a secure dependency management solution. The possibility of the Electron UI existing as an independent client rather than replacing the Qt UI is also discussed.In a forum post, a user expresses their desire to rebuild Bitcoin Core GUI using the Electron framework and seeks insights into the pros and cons of transitioning from Qt to Electron. However, many Bitcoin Core contributors and users are opposed to using a browser and JavaScript for a UI with simple user-stories. The user is advised to work on a third-party project where their Electron UI can connect to Bitcoin Core over RPC or contribute to incorporating long polling into Bitcoin Core. It is unlikely that an Electron/JavaScript UI will be added to the Bitcoin Core repository. Two relevant links are provided for further reading.The author of the email expresses their interest in rebuilding Bitcoin Core GUI using the Electron framework and asks if there have been any previous attempts or ongoing efforts in this direction. They propose having Electron drive the UI by running bitcoind and communicating with it through RPC but question whether this approach can achieve feature-parity with the Qt implementation, which has direct access to Bitcoin Core code. Another member of the mailing list highlights the need for secure dependency management due to the security-focused nature of Bitcoin Core software and the potential vulnerabilities in the way NPM handles Electron app dependencies. The discussion explores the possibility of the Electron UI existing as an independent client and debates whether it could replace the Qt UI. The topic of rebuilding Bitcoin Core GUI using the Electron framework is being explored with considerations for security and feature parity with the current Qt implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_PSBT-GLOBAL-XPUB-Version-bytes-in-xpub.xml b/static/bitcoin-dev/Nov_2019/combined_PSBT-GLOBAL-XPUB-Version-bytes-in-xpub.xml index 421d1a1f90..6fe06cbcf5 100644 --- a/static/bitcoin-dev/Nov_2019/combined_PSBT-GLOBAL-XPUB-Version-bytes-in-xpub.xml +++ b/static/bitcoin-dev/Nov_2019/combined_PSBT-GLOBAL-XPUB-Version-bytes-in-xpub.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - PSBT_GLOBAL_XPUB: Version bytes in xpub - 2023-08-02T01:32:38.587644+00:00 - - Andrew Chow 2019-11-16 04:54:49+00:00 - - - Ian Kroozbi 2019-11-15 22:29:01+00:00 - + 2025-09-26T15:33:28.172584+00:00 + python-feedgen + + + [bitcoin-dev] PSBT_GLOBAL_XPUB: Version bytes in xpub Ian Kroozbi + 2019-11-15T22:29:00.000Z + + + Andrew Chow + 2019-11-16T04:54:00.000Z + + - python-feedgen + 2 Combined summary - PSBT_GLOBAL_XPUB: Version bytes in xpub - 2023-08-02T01:32:38.587644+00:00 + 2025-09-26T15:33:28.173022+00:00 - In a recent discussion on the bitcoin-dev mailing list, there was a debate regarding the inclusion of version bytes in the xpubs in the GLOBAL_XPUB field. The question raised was whether these version bytes were necessary or if they should be ignored. Andrew, a member of the list, argued that since xpubs are already a predefined standard with existing serialization code in many software, it would be simpler to reuse these standards. However, he believed that the version bytes themselves did not matter and could be disregarded. Ian countered this argument by suggesting that the version bytes seemed to be superfluous data considering that the transaction format and the rest of the PSBT key-values are network agnostic. He proposed that if network data needed to be attached to the PSBT, it would be better to use a new key instead of including it in the xpubs. Ian also pointed out a potential issue of conflicting versions on different xpubs in the PSBT, which could be eliminated by removing the version bytes. The discussion further explored the idea of keeping only the chain code and public key in the xpubs, without including the version bytes. Some participants argued for including additional data such as prefixes that define if the key is used for testnet or mainnet. However, others remained undecided about whether or not to include any data outside of the public key and chain code. They emphasized the importance of discussing the rationale behind including or omitting such data. Overall, the debate centered around the usefulness and necessity of version bytes in xpubs within the GLOBAL_XPUB field. While some advocated for their removal, others suggested keeping additional data like prefixes. The potential issue of conflicting versions on different xpubs in the PSBT was recognized, and the possibility of attaching network data to the PSBT using a new key was also mentioned. 2019-11-16T04:54:49+00:00 + In a recent discussion on the bitcoin-dev mailing list, there was a debate regarding the inclusion of version bytes in the xpubs in the GLOBAL_XPUB field. The question raised was whether these version bytes were necessary or if they should be ignored. Andrew, a member of the list, argued that since xpubs are already a predefined standard with existing serialization code in many software, it would be simpler to reuse these standards. However, he believed that the version bytes themselves did not matter and could be disregarded. Ian countered this argument by suggesting that the version bytes seemed to be superfluous data considering that the transaction format and the rest of the PSBT key-values are network agnostic. He proposed that if network data needed to be attached to the PSBT, it would be better to use a new key instead of including it in the xpubs. Ian also pointed out a potential issue of conflicting versions on different xpubs in the PSBT, which could be eliminated by removing the version bytes. The discussion further explored the idea of keeping only the chain code and public key in the xpubs, without including the version bytes. Some participants argued for including additional data such as prefixes that define if the key is used for testnet or mainnet. However, others remained undecided about whether or not to include any data outside of the public key and chain code. They emphasized the importance of discussing the rationale behind including or omitting such data. Overall, the debate centered around the usefulness and necessity of version bytes in xpubs within the GLOBAL_XPUB field. While some advocated for their removal, others suggested keeping additional data like prefixes. The potential issue of conflicting versions on different xpubs in the PSBT was recognized, and the possibility of attaching network data to the PSBT using a new key was also mentioned. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_Signing-CHECKSIG-position-in-Tapscript.xml b/static/bitcoin-dev/Nov_2019/combined_Signing-CHECKSIG-position-in-Tapscript.xml index 5fdff49c77..b212e3635b 100644 --- a/static/bitcoin-dev/Nov_2019/combined_Signing-CHECKSIG-position-in-Tapscript.xml +++ b/static/bitcoin-dev/Nov_2019/combined_Signing-CHECKSIG-position-in-Tapscript.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Signing CHECKSIG position in Tapscript - 2023-08-02T01:41:18.154125+00:00 - - Anthony Towns 2019-12-06 04:51:53+00:00 - - - Russell O'Connor 2019-12-05 20:24:46+00:00 - - - Anthony Towns 2019-12-03 08:35:38+00:00 - - - Russell O'Connor 2019-12-01 16:09:54+00:00 - - - Anthony Towns 2019-11-28 08:06:59+00:00 - - - Russell O'Connor 2019-11-27 21:29:32+00:00 - + 2025-09-26T15:33:34.459906+00:00 + python-feedgen + + + [bitcoin-dev] Signing CHECKSIG position in Tapscript Russell O'Connor + 2019-11-27T21:29:00.000Z + + + Anthony Towns + 2019-11-28T08:06:00.000Z + + + Russell O'Connor + 2019-12-01T16:09:00.000Z + + + Anthony Towns + 2019-12-03T08:35:00.000Z + + + Russell O'Connor + 2019-12-05T20:24:00.000Z + + + Anthony Towns + 2019-12-06T04:51:00.000Z + + - python-feedgen + 2 Combined summary - Signing CHECKSIG position in Tapscript - 2023-08-02T01:41:18.154125+00:00 + 2025-09-26T15:33:34.460755+00:00 - In an email thread, Russell O'Connor and gmaxwell discuss potential amendments to the CODESEPARATOR's behavior in Bitcoin's scripting language. The proposed amendment aims to update an accumulator with a running hash value to ensure that all executed CODESEPARATOR positions are covered by the signature. Gmaxwell suggests using the name "OP_BREADCRUMB" for this new functionality. However, aj cautions against proposing this idea too soon, citing concerns about practical need and whether opcode or sighash flag functionality is more appropriate. Aj also suggests a policy that would allow signatures to cover some function of witness value and proposes a replacement for CODESEPARATOR's behavior that pushes a stack item into the accumulator rather than pushing the CODESEPARATOR position. Aj also notes that the annex may not be general enough to accommodate these changes and proposes committing to a hash of all witness data as a possible solution. They propose an "OP_DATACOMMIT" opcode that pops an element from the stack, does hash_"DataCommit", and later signatures commit to that value. Aj suggests implementing CODESEP at position "x" in the script as equivalent to "DATACOMMIT," but acknowledges that this approach warrants something better. Overall, aj suggests that this proposal needs further exploration before it can be coded into consensus.After discussing and considering the concern of other users masquerading pubkeys in complex scripts, it is determined that this is a non-issue because any policy expressed in a script is logically equivalent to a set of conditions and signatures on pubkeys that can be expressed in disjunctive normal form. However, there is still an issue with pubkey reuse within a single script, as it can allow someone to take a signature intended for one condition and transplant it to redeem under another. To avoid this, it is important for Alice to ensure she doesn't reuse pubkeys that she considers under her control for different conditions when she wants her signature to distinguish between them. While avoiding pubkey reuse within a script should be easier than avoiding it for different UTXOs, converting a policy to disjunctive normal form can involve an exponential blowup. Additionally, there may be cases where a policy requires an exponential number of pubkeys, which isn't tractable to do in Script. Taproot's MAST (Merklized Alternative Script Tree) can provide a solution for certain cases.The email conversation revolves around the vulnerability of signature copying attacks, particularly pertaining to the use of CODESEPARATOR in the Taproot script version. The issue is that signing the CODESEPARATOR position without signing the script code is considered nonsensical as it is signing a piece of data without an interpretation of its meaning. However, the current implementation includes an index to the digest being signed, so signatures at different indexes are distinct. Participants discuss various techniques such as miniscript and fixed templates to allow limited safe changes to policy and prevent signature reuse in different scripts. The proposed solution, ANYPREVOUTANYSCRIPT, would not sign the script code but would continue signing the CODESEPARATOR position, allowing for restricted signature reuse. This means users can prevent their funds from going to certain addresses without compromising security.While the concept of CODESEPARATOR in taproot is discussed as a possible solution, some argue that it would not be widely used or sufficient. There are only two known use cases for CODESEPARATOR, one being the reveal-a-secret-key-by-forced-nonce-reuse script, which requires pubkey recovery and does not work with bip-schnorr, and the other is ntumblebit's escrow script. It is ultimately agreed that analyzing scripts before collaborating is necessary to prevent vulnerability to signature copying attacks. Although the proposal to eliminate CODESEPARATOR opcode in the Taproot script version is seen as effective enough to save most people most of the time, it may not save everyone all the time. Some participants suggest that CODESEP is a marginally more efficient/general fix than the proposal made.In an email exchange, Anthony Towns shares a link to a discussion on Taproot BIP review. The conversation revolves around signing the position of the enclosing OP_IF/OP_NOTIF/OP_ELSE of the OP_IF/OP_NOTIF/OP_ELSE block that the checksig is within, or signing the byte offset instead of the opcode number offset. It is suggested that signing the enclosing OP_IF... would allow sharing of the hashed signed data in a normal multisig sequence of operations. A sighash flag could control whether or not the signature covers the CHECKSIG position or not, with SIGHASH_ALL including the CHECKSIG position.Russell O'Connor proposed an amendment to the current tapscript proposal, which requires a signature on the last executed CODESEPRATOR position. He suggested that instead of signing the last executed CODESEPRATOR position, we should sign the position of the CHECKSIG (or other signing opcode) being executed. There is a discussion about this topic at http://www.erisian.com 2019-12-06T04:51:53+00:00 + In an email thread, Russell O'Connor and gmaxwell discuss potential amendments to the CODESEPARATOR's behavior in Bitcoin's scripting language. The proposed amendment aims to update an accumulator with a running hash value to ensure that all executed CODESEPARATOR positions are covered by the signature. Gmaxwell suggests using the name "OP_BREADCRUMB" for this new functionality. However, aj cautions against proposing this idea too soon, citing concerns about practical need and whether opcode or sighash flag functionality is more appropriate. Aj also suggests a policy that would allow signatures to cover some function of witness value and proposes a replacement for CODESEPARATOR's behavior that pushes a stack item into the accumulator rather than pushing the CODESEPARATOR position. Aj also notes that the annex may not be general enough to accommodate these changes and proposes committing to a hash of all witness data as a possible solution. They propose an "OP_DATACOMMIT" opcode that pops an element from the stack, does hash_"DataCommit", and later signatures commit to that value. Aj suggests implementing CODESEP at position "x" in the script as equivalent to "DATACOMMIT," but acknowledges that this approach warrants something better. Overall, aj suggests that this proposal needs further exploration before it can be coded into consensus.After discussing and considering the concern of other users masquerading pubkeys in complex scripts, it is determined that this is a non-issue because any policy expressed in a script is logically equivalent to a set of conditions and signatures on pubkeys that can be expressed in disjunctive normal form. However, there is still an issue with pubkey reuse within a single script, as it can allow someone to take a signature intended for one condition and transplant it to redeem under another. To avoid this, it is important for Alice to ensure she doesn't reuse pubkeys that she considers under her control for different conditions when she wants her signature to distinguish between them. While avoiding pubkey reuse within a script should be easier than avoiding it for different UTXOs, converting a policy to disjunctive normal form can involve an exponential blowup. Additionally, there may be cases where a policy requires an exponential number of pubkeys, which isn't tractable to do in Script. Taproot's MAST (Merklized Alternative Script Tree) can provide a solution for certain cases.The email conversation revolves around the vulnerability of signature copying attacks, particularly pertaining to the use of CODESEPARATOR in the Taproot script version. The issue is that signing the CODESEPARATOR position without signing the script code is considered nonsensical as it is signing a piece of data without an interpretation of its meaning. However, the current implementation includes an index to the digest being signed, so signatures at different indexes are distinct. Participants discuss various techniques such as miniscript and fixed templates to allow limited safe changes to policy and prevent signature reuse in different scripts. The proposed solution, ANYPREVOUTANYSCRIPT, would not sign the script code but would continue signing the CODESEPARATOR position, allowing for restricted signature reuse. This means users can prevent their funds from going to certain addresses without compromising security.While the concept of CODESEPARATOR in taproot is discussed as a possible solution, some argue that it would not be widely used or sufficient. There are only two known use cases for CODESEPARATOR, one being the reveal-a-secret-key-by-forced-nonce-reuse script, which requires pubkey recovery and does not work with bip-schnorr, and the other is ntumblebit's escrow script. It is ultimately agreed that analyzing scripts before collaborating is necessary to prevent vulnerability to signature copying attacks. Although the proposal to eliminate CODESEPARATOR opcode in the Taproot script version is seen as effective enough to save most people most of the time, it may not save everyone all the time. Some participants suggest that CODESEP is a marginally more efficient/general fix than the proposal made.In an email exchange, Anthony Towns shares a link to a discussion on Taproot BIP review. The conversation revolves around signing the position of the enclosing OP_IF/OP_NOTIF/OP_ELSE of the OP_IF/OP_NOTIF/OP_ELSE block that the checksig is within, or signing the byte offset instead of the opcode number offset. It is suggested that signing the enclosing OP_IF... would allow sharing of the hashed signed data in a normal multisig sequence of operations. A sighash flag could control whether or not the signature covers the CHECKSIG position or not, with SIGHASH_ALL including the CHECKSIG position.Russell O'Connor proposed an amendment to the current tapscript proposal, which requires a signature on the last executed CODESEPRATOR position. He suggested that instead of signing the last executed CODESEPRATOR position, we should sign the position of the CHECKSIG (or other signing opcode) being executed. There is a discussion about this topic at http://www.erisian.com - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_Towards-a-singular-payment-protocol.xml b/static/bitcoin-dev/Nov_2019/combined_Towards-a-singular-payment-protocol.xml index 6034811be1..ca2ad18c4c 100644 --- a/static/bitcoin-dev/Nov_2019/combined_Towards-a-singular-payment-protocol.xml +++ b/static/bitcoin-dev/Nov_2019/combined_Towards-a-singular-payment-protocol.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Towards a singular payment protocol - 2023-08-02T01:32:25.593917+00:00 - - Ben Dewaal 2019-11-14 12:31:44+00:00 - - - EE 2019-11-13 17:49:05+00:00 - - - Ben Dewaal 2019-11-13 08:52:19+00:00 - - - ee at cypherpunk.org 2019-11-12 15:02:09+00:00 - + 2025-09-26T15:33:17.695580+00:00 + python-feedgen + + + [bitcoin-dev] Towards a singular payment protocol ee + 2019-11-12T15:02:00.000Z + + + Ben Dewaal + 2019-11-13T08:52:00.000Z + + + EE + 2019-11-13T17:49:00.000Z + + + Ben Dewaal + 2019-11-14T12:31:00.000Z + + - python-feedgen + 2 Combined summary - Towards a singular payment protocol - 2023-08-02T01:32:25.593917+00:00 + 2025-09-26T15:33:17.696231+00:00 - The topic of Bitcoin protocol standardization was discussed in an email conversation between two individuals. The first individual argues that Bitcoin, being an open protocol, won't deprecate other protocols without a strong reason, as no individual gets to dictate "the right way". However, the second individual believes that wallet developers prefer keeping things simple until a clear path is seen. They differentiate between building a Bitcoin wallet and a cryptocurrency wallet, thus dismissing complexities faced by other cryptocurrencies. BIP-70 was mentioned as being deprecated *in* Bitcoin Core by the second individual. The first individual suggests that under-supported standards pose a problem as they take longer for wallet developers to implement. But the second individual disagrees, believing that the payment protocol is separate from the blockchain and can be developed independently. They view the Lightning Network as a payment network applicable to other blockchains as well. The second individual fails to understand the value of requesting payment in one currency based on the value of another, considering the current behavior superior. The first individual disagrees, stating that a well-written spec should address conflicts and design around them. The second individual opposes proposals adding complexity without clear benefits. They feel that Lightning invoices and ongoing discussions provide sufficient coverage for their needs.The proposal to merge cryptocurrency URI schemes is being discussed in response to concerns raised by Ben Dewaal. Existing standards are not fully implemented in any wallet, requiring multiple schemes to be maintained, which is cumbersome for developers. Merging the major proposed standards into a single one allows efforts to focus on a unified protocol, dropping what doesn't work. This basis would facilitate more complex payment systems with advanced features, reducing necessary attributes. Different levels of support could be introduced, such as 'pay: simple' or 'pay: multi', accommodating various types of payments. Concerns about defining attributes and ensuring correct software interpretation are addressed, suggesting the fixing of difficult-to-interpret aspects before standardization. Eventually, wallets and payment systems would fully support this standard, enabling them to claim 'pay:' supported.However, Ben does not find the proposal to add a new URI scheme for wallet developers beneficial. He identifies three main problems: the coexistence of other schemes alongside the new one creates more work without easing developers' lives, simple URI schemes become less suitable and future-proof as payment systems grow complex, and defining attributes and potential errors becomes unreasonable, leading to incompatible implementations. Ben fails to see the merits of this proposal.Another proposal seeks to establish a payment protocol independent of a specific blockchain, usable with fiat or cryptocurrency. The protocol allows multiple payments and currencies in a single transaction, referencing the value of one currency while paying in another. It also permits fees to be paid by either the sender or recipient, with trusted third parties calculating valuation and fees. The aim is to create a single payment system for wallet developers working with multiple currencies and increase support for a universal protocol across various currencies and blockchains. The author acknowledges opposition due to support for other coins but emphasizes considering the proposal's potential to enhance Bitcoin functionality and promote a universal payment protocol. While future sections on smart contracts and private communications are planned, the current focus is on payments and maintaining functionality for all blockchains. The proposal hopes to evolve into a BIP but requests constructive criticism and feedback before moving forward. 2019-11-14T12:31:44+00:00 + The topic of Bitcoin protocol standardization was discussed in an email conversation between two individuals. The first individual argues that Bitcoin, being an open protocol, won't deprecate other protocols without a strong reason, as no individual gets to dictate "the right way". However, the second individual believes that wallet developers prefer keeping things simple until a clear path is seen. They differentiate between building a Bitcoin wallet and a cryptocurrency wallet, thus dismissing complexities faced by other cryptocurrencies. BIP-70 was mentioned as being deprecated *in* Bitcoin Core by the second individual. The first individual suggests that under-supported standards pose a problem as they take longer for wallet developers to implement. But the second individual disagrees, believing that the payment protocol is separate from the blockchain and can be developed independently. They view the Lightning Network as a payment network applicable to other blockchains as well. The second individual fails to understand the value of requesting payment in one currency based on the value of another, considering the current behavior superior. The first individual disagrees, stating that a well-written spec should address conflicts and design around them. The second individual opposes proposals adding complexity without clear benefits. They feel that Lightning invoices and ongoing discussions provide sufficient coverage for their needs.The proposal to merge cryptocurrency URI schemes is being discussed in response to concerns raised by Ben Dewaal. Existing standards are not fully implemented in any wallet, requiring multiple schemes to be maintained, which is cumbersome for developers. Merging the major proposed standards into a single one allows efforts to focus on a unified protocol, dropping what doesn't work. This basis would facilitate more complex payment systems with advanced features, reducing necessary attributes. Different levels of support could be introduced, such as 'pay: simple' or 'pay: multi', accommodating various types of payments. Concerns about defining attributes and ensuring correct software interpretation are addressed, suggesting the fixing of difficult-to-interpret aspects before standardization. Eventually, wallets and payment systems would fully support this standard, enabling them to claim 'pay:' supported.However, Ben does not find the proposal to add a new URI scheme for wallet developers beneficial. He identifies three main problems: the coexistence of other schemes alongside the new one creates more work without easing developers' lives, simple URI schemes become less suitable and future-proof as payment systems grow complex, and defining attributes and potential errors becomes unreasonable, leading to incompatible implementations. Ben fails to see the merits of this proposal.Another proposal seeks to establish a payment protocol independent of a specific blockchain, usable with fiat or cryptocurrency. The protocol allows multiple payments and currencies in a single transaction, referencing the value of one currency while paying in another. It also permits fees to be paid by either the sender or recipient, with trusted third parties calculating valuation and fees. The aim is to create a single payment system for wallet developers working with multiple currencies and increase support for a universal protocol across various currencies and blockchains. The author acknowledges opposition due to support for other coins but emphasizes considering the proposal's potential to enhance Bitcoin functionality and promote a universal payment protocol. While future sections on smart contracts and private communications are planned, the current focus is on payments and maintaining functionality for all blockchains. The proposal hopes to evolve into a BIP but requests constructive criticism and feedback before moving forward. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2019/combined_v3-onion-services.xml b/static/bitcoin-dev/Nov_2019/combined_v3-onion-services.xml index c3022c8289..4f547c775d 100644 --- a/static/bitcoin-dev/Nov_2019/combined_v3-onion-services.xml +++ b/static/bitcoin-dev/Nov_2019/combined_v3-onion-services.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - v3 onion services - 2023-08-02T01:33:09.015661+00:00 - - Aymeric Vitte 2019-11-18 22:19:23+00:00 - - - Carl Dong 2019-11-18 16:44:00+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2019-11-18 12:34:49+00:00 - - - Aymeric Vitte 2019-11-18 11:59:03+00:00 - - - Matt Corallo 2019-11-17 23:42:03+00:00 - - - Christopher Allen 2019-11-17 23:01:23+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2019-11-17 20:04:04+00:00 - - - s7r 2019-11-17 15:35:16+00:00 - - - Mr. Lee Chiffre 2019-11-17 04:33:31+00:00 - + 2025-09-26T15:33:32.348120+00:00 + python-feedgen + + + [bitcoin-dev] v3 onion services Mr. Lee Chiffre + 2019-11-17T04:33:00.000Z + + + s7r + 2019-11-17T15:35:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2019-11-17T20:04:00.000Z + + + Christopher Allen + 2019-11-17T23:01:00.000Z + + + Matt Corallo + 2019-11-17T23:42:00.000Z + + + Aymeric Vitte + 2019-11-18T11:59:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2019-11-18T12:34:00.000Z + + + Carl Dong + 2019-11-18T16:44:00.000Z + + + Aymeric Vitte + 2019-11-18T22:19:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - v3 onion services - 2023-08-02T01:33:09.015661+00:00 + 2025-09-26T15:33:32.349272+00:00 - In a post on the bitcoin-dev mailing list, the author questions the rationale for hiding a bitcoin node using Rendezvous (RDV) points like hidden services. They argue that the purpose of Bitcoin is to anonymize communications between nodes and/or clients, not to hide the fact that someone is operating a node. The author suggests finding another way to achieve this goal instead of mimicking the Tor network for RDV points with .onion addresses. They believe that using the Tor network for Bitcoin is not a good idea for security and performance reasons.Another member of the mailing list, Mr. Lee Chiffre, asks if any current node software supports v3 onion addresses or I2P addresses. He is working on creating a new Bitcoin node that will use v3 hidden service instead of v2 and is considering using Bitcoin Core and btcd. Carl Dong responds to Lee Chiffre's inquiry and shares a link to his work-in-progress pull request for implementing addrv2 (BIP-155), which includes support for I2P and Torv3 address.Carl Dong, a Bitcoin developer, is seeking feedback on his ongoing discussion about implementing addrv2 (BIP-155). He reaches out to Mr. Lee Chiffre via the bitcoin-dev mailing list to clarify if the I2P and Torv3 address support is what he meant. Carl shares his work-in-progress pull request, merged BIP, and a link for ongoing discussion. Mr. Lee Chiffre mentions that the current Bitcoin client core supports v2 hidden service, but he is in the process of creating a new Bitcoin node that will use v3 hidden service instead of v2. He is looking at bitcoin core and btcd to use, but wants to know if they support v3 onion addresses and what it would take to support longer addresses used by i2p and tor v3.The Tor team encourages active participation from Tor nodes, particularly exit, middle, and guard nodes, rather than just client nodes. The documentation for Bitcoin.SE does not extensively cover configuring Tor as it actively participates in the Tor network by default. However, there are efforts to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. The author suggests linking Bitcoin traffic with something like node-Tor as a better long-term solution. Node-Tor is lighter, easier to use/configure/maintain, and doesn't require the onions RDV concepts and addresses. There is ongoing work on this front, and contributions to the effort are welcome.There is an ongoing effort to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. This effort is called "addrv2," and contributions are welcome. Mr. Lee Chiffre's recent message to the bitcoin-dev mailing list inquires about the support for v3 onion addresses in bitcoin client core, as well as I2P addresses. He is creating a new Bitcoin node that will use v3 hidden service and wants to know if the current software supports these addresses or what it would take to enable support. The bitcoin-dev mailing list is open for discussion and review of this effort, and any contributions are welcome.Blockchain Commons has incorporated v3 tor authentication into their Bitcoin Standup project, which allows remote control of a full node. The project is currently available only for macOS but will soon be launched on other platforms. Documentation for the project can be found on their GitHub page. A video demonstrating how to securely connect remote full nodes to the iOS wallet Fully Noded is also available on YouTube. Christopher Allen announced this development.Bitcoin Core currently supports v2 Tor hidden services but not yet v3. The use of v3 ephemeral service is not necessary for node connectivity but allows for hidden listening. While it is not urgent to add v3 support, it will eventually be essential as Tor drops support for v2. Bitcoin Core's limit of 128-bit addresses in the p2p protocol requires reworking to support longer v3 onion addresses. For now, those who want a Tor-only full node should use v2 onion services. It is possible to use both v2 and v3 onion services simultaneously in the same Tor configuration file.The author proposes creating a new bitcoin node that will use v3 hidden service instead of v2. They are exploring options between bitcoin core and btcd to use for this new node. They are also interested in knowing if either of these or current node software supports v3 onion addresses for the node address and I2P addresses. If not, they want to know what it would take to get the software to support the longer addresses used by i2p and tor v3. 2019-11-18T22:19:23+00:00 + In a post on the bitcoin-dev mailing list, the author questions the rationale for hiding a bitcoin node using Rendezvous (RDV) points like hidden services. They argue that the purpose of Bitcoin is to anonymize communications between nodes and/or clients, not to hide the fact that someone is operating a node. The author suggests finding another way to achieve this goal instead of mimicking the Tor network for RDV points with .onion addresses. They believe that using the Tor network for Bitcoin is not a good idea for security and performance reasons.Another member of the mailing list, Mr. Lee Chiffre, asks if any current node software supports v3 onion addresses or I2P addresses. He is working on creating a new Bitcoin node that will use v3 hidden service instead of v2 and is considering using Bitcoin Core and btcd. Carl Dong responds to Lee Chiffre's inquiry and shares a link to his work-in-progress pull request for implementing addrv2 (BIP-155), which includes support for I2P and Torv3 address.Carl Dong, a Bitcoin developer, is seeking feedback on his ongoing discussion about implementing addrv2 (BIP-155). He reaches out to Mr. Lee Chiffre via the bitcoin-dev mailing list to clarify if the I2P and Torv3 address support is what he meant. Carl shares his work-in-progress pull request, merged BIP, and a link for ongoing discussion. Mr. Lee Chiffre mentions that the current Bitcoin client core supports v2 hidden service, but he is in the process of creating a new Bitcoin node that will use v3 hidden service instead of v2. He is looking at bitcoin core and btcd to use, but wants to know if they support v3 onion addresses and what it would take to support longer addresses used by i2p and tor v3.The Tor team encourages active participation from Tor nodes, particularly exit, middle, and guard nodes, rather than just client nodes. The documentation for Bitcoin.SE does not extensively cover configuring Tor as it actively participates in the Tor network by default. However, there are efforts to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. The author suggests linking Bitcoin traffic with something like node-Tor as a better long-term solution. Node-Tor is lighter, easier to use/configure/maintain, and doesn't require the onions RDV concepts and addresses. There is ongoing work on this front, and contributions to the effort are welcome.There is an ongoing effort to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. This effort is called "addrv2," and contributions are welcome. Mr. Lee Chiffre's recent message to the bitcoin-dev mailing list inquires about the support for v3 onion addresses in bitcoin client core, as well as I2P addresses. He is creating a new Bitcoin node that will use v3 hidden service and wants to know if the current software supports these addresses or what it would take to enable support. The bitcoin-dev mailing list is open for discussion and review of this effort, and any contributions are welcome.Blockchain Commons has incorporated v3 tor authentication into their Bitcoin Standup project, which allows remote control of a full node. The project is currently available only for macOS but will soon be launched on other platforms. Documentation for the project can be found on their GitHub page. A video demonstrating how to securely connect remote full nodes to the iOS wallet Fully Noded is also available on YouTube. Christopher Allen announced this development.Bitcoin Core currently supports v2 Tor hidden services but not yet v3. The use of v3 ephemeral service is not necessary for node connectivity but allows for hidden listening. While it is not urgent to add v3 support, it will eventually be essential as Tor drops support for v2. Bitcoin Core's limit of 128-bit addresses in the p2p protocol requires reworking to support longer v3 onion addresses. For now, those who want a Tor-only full node should use v2 onion services. It is possible to use both v2 and v3 onion services simultaneously in the same Tor configuration file.The author proposes creating a new bitcoin node that will use v3 hidden service instead of v2. They are exploring options between bitcoin core and btcd to use for this new node. They are also interested in knowing if either of these or current node software supports v3 onion addresses for the node address and I2P addresses. If not, they want to know what it would take to get the software to support the longer addresses used by i2p and tor v3. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2020/combined_Against-proprietary-and-PoR-fields-in-PSBT-BIP174.xml b/static/bitcoin-dev/Nov_2020/combined_Against-proprietary-and-PoR-fields-in-PSBT-BIP174.xml index 675a6573ac..035488c19a 100644 --- a/static/bitcoin-dev/Nov_2020/combined_Against-proprietary-and-PoR-fields-in-PSBT-BIP174.xml +++ b/static/bitcoin-dev/Nov_2020/combined_Against-proprietary-and-PoR-fields-in-PSBT-BIP174.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Against proprietary and PoR fields in PSBT BIP174 - 2023-08-02T02:51:44.778562+00:00 - - Jonathan Underwood 2020-11-26 23:24:32+00:00 - - - Ferdinando M. Ametrano 2020-11-16 23:38:19+00:00 - - - Ferdinando M. Ametrano 2020-11-16 23:01:34+00:00 - + 2025-09-26T15:57:20.167839+00:00 + python-feedgen + + + [bitcoin-dev] Against proprietary and PoR fields in PSBT BIP174 Ferdinando M. Ametrano + 2020-11-16T23:01:00.000Z + + + Ferdinando M. Ametrano + 2020-11-16T23:38:00.000Z + + + Jonathan Underwood + 2020-11-26T23:24:00.000Z + + - python-feedgen + 2 Combined summary - Against proprietary and PoR fields in PSBT BIP174 - 2023-08-02T02:51:44.778562+00:00 + 2025-09-26T15:57:20.168433+00:00 - A proposal has been made to remove the 'proprietary' and 'proof-of-reserves' types from the PSBT specifications, as they have nothing to do with the intrinsic operations required to finalize a valid transaction from PSBT manipulation. Ferdinando M. Ametrano has submitted a pull request to the bips repo suggesting this change. He questions the rationale for these types, stating that any information content they could provide for non-standard PSBT manipulation could stay in the 'unknown' field without any loss of generality.Ametrano believes that as long as BIP174 states that unknown data must be kept during PSBT manipulation, there is no need for explicit support for 'proprietary' and 'proof-of-reserves' types. He mentions that he has a project where they include proprietary information in the PSBT, and any PSBT software supporting unknown data keeps their proprietary information intact. Therefore, there is no need for a PSBT implementation to provide explicit support for these types.The author of the btclib library also fails to understand the rationale for the 'proprietary' and 'proof-of-reserves' types. They argue that these types are unrelated to the intrinsic operations required to finalize a valid transaction from PSBT manipulation. They suggest that any information content provided by these types could be stored in the 'unknown' field without any issues. The author emphasizes that their project includes proprietary information in the PSBT, and the software successfully retrieves this information from serialized PSBT.The conclusion drawn by both Ametrano and the btclib library author is reinforced by the evidence that all PSBT implementations they know of, including bitcoin core and HWI, do not implement 'proprietary' and 'proof-of-reserve' types. This suggests that these types might be ignored if included in BIP174. Considering this, it is highly likely that part of BIP174 will be removed. 2020-11-26T23:24:32+00:00 + A proposal has been made to remove the 'proprietary' and 'proof-of-reserves' types from the PSBT specifications, as they have nothing to do with the intrinsic operations required to finalize a valid transaction from PSBT manipulation. Ferdinando M. Ametrano has submitted a pull request to the bips repo suggesting this change. He questions the rationale for these types, stating that any information content they could provide for non-standard PSBT manipulation could stay in the 'unknown' field without any loss of generality.Ametrano believes that as long as BIP174 states that unknown data must be kept during PSBT manipulation, there is no need for explicit support for 'proprietary' and 'proof-of-reserves' types. He mentions that he has a project where they include proprietary information in the PSBT, and any PSBT software supporting unknown data keeps their proprietary information intact. Therefore, there is no need for a PSBT implementation to provide explicit support for these types.The author of the btclib library also fails to understand the rationale for the 'proprietary' and 'proof-of-reserves' types. They argue that these types are unrelated to the intrinsic operations required to finalize a valid transaction from PSBT manipulation. They suggest that any information content provided by these types could be stored in the 'unknown' field without any issues. The author emphasizes that their project includes proprietary information in the PSBT, and the software successfully retrieves this information from serialized PSBT.The conclusion drawn by both Ametrano and the btclib library author is reinforced by the evidence that all PSBT implementations they know of, including bitcoin core and HWI, do not implement 'proprietary' and 'proof-of-reserve' types. This suggests that these types might be ignored if included in BIP174. Considering this, it is highly likely that part of BIP174 will be removed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2020/combined_Bitcoin-Archaeology.xml b/static/bitcoin-dev/Nov_2020/combined_Bitcoin-Archaeology.xml index 47610d8bbc..e28412dcf3 100644 --- a/static/bitcoin-dev/Nov_2020/combined_Bitcoin-Archaeology.xml +++ b/static/bitcoin-dev/Nov_2020/combined_Bitcoin-Archaeology.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Bitcoin Archaeology - 2023-08-02T02:51:17.638203+00:00 - - Dan Bryant 2020-11-21 22:59:36+00:00 - - - Dan Bryant 2020-11-15 05:41:33+00:00 - - - Dan Bryant 2020-11-14 17:00:12+00:00 - - - Dan Bryant 2020-11-11 15:06:54+00:00 - + 2025-09-26T15:57:28.643856+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Archaeology Dan Bryant + 2020-11-11T15:06:00.000Z + + + Dan Bryant + 2020-11-14T17:00:00.000Z + + + Dan Bryant + 2020-11-15T05:41:00.000Z + + + Dan Bryant + 2020-11-21T22:59:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Archaeology - 2023-08-02T02:51:17.638203+00:00 + 2025-09-26T15:57:28.644493+00:00 - A user is searching for a specific file, "bitcoin-0.1.2.rar," from 2009/2010 that they have been unable to locate. They have managed to gather all the source archives from versions 0.1.0 to 0.9.0, except for this missing file, and are interested in examining it out of curiosity. Unfortunately, the Web Archive does not have any crawlers that captured the file. However, the user provides links to its first and last sightings on the Web Archive.Dan Bryant is currently working on building old OpenSSL releases in MSYS/MinGW v1.0.11, specifically for the first three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5). However, he is facing issues with OpenSSL due to problems in mk1mf.pl. He is seeking guidance to complete the build and has already attempted various options, such as finding a non-sketchy copy of Visual C++ 6.0 and using precompiled OpenSSL releases. The user also provides links to the tools Dan used for the project and mentions that he is refining his work before posting binary builds on his repository.The author of the post has successfully compiled Bitcoin versions 0.1.0 to 0.3.13, after which the compiler was changed. They plan to refine their work and post binary builds on the repository. In order to prevent spamming the `#bitcoin` IRC channel, they may disable the IRC bot. They mention a patch process that will make it easier and reveal their intention to stop at version 0.8.6 since official builds start from there.In an earlier post, the author describes their experience in attempting to build the first three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5) using vintage Oct 2009 toolchains with MSYS/MinGW v1.0.11. Most things seemed to build successfully, except for OpenSSL, which failed due to issues in mk1mf.pl. The author explores different options, such as finding out how Satoshi (the creator of Bitcoin) did the MinGW OpenSSL build back in 2009, attempting the OpenSSL build through Cygwin, or using Msys2 with later versions of perl and libc. They also consider purchasing a copy of VC 6 on eBay. Additionally, they suggest patching Bitcoin 0.1.0 to use OpenSSL v1.0.0 where they fixed the perl bug. Alternatively, they could give up and use a precompiled OpenSSL release or use the Linux build methods introduced in Bitcoin v0.1.6. The author provides links to the binaries used to create the build environment for anyone interested in trying it themselves.The author's goal is to build the first three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5) similar to the Github Arctic Code Vault and the Nakamoto Institute. They refer to the original Satoshi posts that suggest these builds could be done using Visual C++ version 6.0 or MinGW and MSYS (at v1.0.11). However, since most versions of VC 6 are no longer available online, the only option left is MinGW, which can still be found on sourceforge. Unfortunately, OpenSSL fails to build due to issues in mk1mf.pl, possibly because of a problematic version of perl in MSYS v1.0.11. The author seeks help in recalling the steps to build OpenSSL v0.9.8h in MSYS 1.0.11 and asks if anyone knows where to find a non-sketchy copy of Visual C++ 6.0. They provide several options to address the issue and mention that reproducing these old builds is important, even though it may seem like a challenging task. The author identifies the mk1mf.pl bug as being related to parsing the list of headers through var_add, clean_up_ws, or do_copy_rule subs. The directories are dropped when building the make rules, causing make to assume all headers are at the root and resulting in a failed build. The author suspects that there may be missing versions of sed, basename, or dirname in MSYS, but the exact dependency has yet to be discovered. The provided references include the Satoshi Nakamoto code repository and the OpenSSL mk1mf.pl file on GitHub. 2020-11-21T22:59:36+00:00 + A user is searching for a specific file, "bitcoin-0.1.2.rar," from 2009/2010 that they have been unable to locate. They have managed to gather all the source archives from versions 0.1.0 to 0.9.0, except for this missing file, and are interested in examining it out of curiosity. Unfortunately, the Web Archive does not have any crawlers that captured the file. However, the user provides links to its first and last sightings on the Web Archive.Dan Bryant is currently working on building old OpenSSL releases in MSYS/MinGW v1.0.11, specifically for the first three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5). However, he is facing issues with OpenSSL due to problems in mk1mf.pl. He is seeking guidance to complete the build and has already attempted various options, such as finding a non-sketchy copy of Visual C++ 6.0 and using precompiled OpenSSL releases. The user also provides links to the tools Dan used for the project and mentions that he is refining his work before posting binary builds on his repository.The author of the post has successfully compiled Bitcoin versions 0.1.0 to 0.3.13, after which the compiler was changed. They plan to refine their work and post binary builds on the repository. In order to prevent spamming the `#bitcoin` IRC channel, they may disable the IRC bot. They mention a patch process that will make it easier and reveal their intention to stop at version 0.8.6 since official builds start from there.In an earlier post, the author describes their experience in attempting to build the first three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5) using vintage Oct 2009 toolchains with MSYS/MinGW v1.0.11. Most things seemed to build successfully, except for OpenSSL, which failed due to issues in mk1mf.pl. The author explores different options, such as finding out how Satoshi (the creator of Bitcoin) did the MinGW OpenSSL build back in 2009, attempting the OpenSSL build through Cygwin, or using Msys2 with later versions of perl and libc. They also consider purchasing a copy of VC 6 on eBay. Additionally, they suggest patching Bitcoin 0.1.0 to use OpenSSL v1.0.0 where they fixed the perl bug. Alternatively, they could give up and use a precompiled OpenSSL release or use the Linux build methods introduced in Bitcoin v0.1.6. The author provides links to the binaries used to create the build environment for anyone interested in trying it themselves.The author's goal is to build the first three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5) similar to the Github Arctic Code Vault and the Nakamoto Institute. They refer to the original Satoshi posts that suggest these builds could be done using Visual C++ version 6.0 or MinGW and MSYS (at v1.0.11). However, since most versions of VC 6 are no longer available online, the only option left is MinGW, which can still be found on sourceforge. Unfortunately, OpenSSL fails to build due to issues in mk1mf.pl, possibly because of a problematic version of perl in MSYS v1.0.11. The author seeks help in recalling the steps to build OpenSSL v0.9.8h in MSYS 1.0.11 and asks if anyone knows where to find a non-sketchy copy of Visual C++ 6.0. They provide several options to address the issue and mention that reproducing these old builds is important, even though it may seem like a challenging task. The author identifies the mk1mf.pl bug as being related to parsing the list of headers through var_add, clean_up_ws, or do_copy_rule subs. The directories are dropped when building the make rules, causing make to assume all headers are at the root and resulting in a failed build. The author suspects that there may be missing versions of sed, basename, or dirname in MSYS, but the exact dependency has yet to be discovered. The provided references include the Satoshi Nakamoto code repository and the OpenSSL mk1mf.pl file on GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2020/combined_Bulletin-boards-without-selective-censorability-for-bitcoin-fungibility-markets.xml b/static/bitcoin-dev/Nov_2020/combined_Bulletin-boards-without-selective-censorability-for-bitcoin-fungibility-markets.xml index a36722e2f3..a91d91de2a 100644 --- a/static/bitcoin-dev/Nov_2020/combined_Bulletin-boards-without-selective-censorability-for-bitcoin-fungibility-markets.xml +++ b/static/bitcoin-dev/Nov_2020/combined_Bulletin-boards-without-selective-censorability-for-bitcoin-fungibility-markets.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Bulletin boards without selective censorability for bitcoin fungibility markets - 2023-08-02T02:51:54.828397+00:00 - - yanmaani at cock.li 2020-11-25 01:52:08+00:00 - - - Ruben Somsen 2020-11-23 13:53:15+00:00 - - - AdamISZ 2020-11-23 12:24:18+00:00 - - - AdamISZ 2020-11-23 00:40:56+00:00 - + 2025-09-26T15:57:22.279983+00:00 + python-feedgen + + + [bitcoin-dev] Bulletin boards without selective censorability for bitcoin fungibility markets AdamISZ + 2020-11-23T00:40:00.000Z + + + AdamISZ + 2020-11-23T12:24:00.000Z + + + Ruben Somsen + 2020-11-23T13:53:00.000Z + + + yanmaani + 2020-11-25T01:52:00.000Z + + - python-feedgen + 2 Combined summary - Bulletin boards without selective censorability for bitcoin fungibility markets - 2023-08-02T02:51:54.828397+00:00 + 2025-09-26T15:57:22.280671+00:00 - In a post to the bitcoin-dev mailing list, AdamISZ asked for feedback on his idea for creating "bitcoin fungibility markets" that prioritize liquidity and privacy. However, Greg Maxwell pointed out a flaw in the idea, where makers could falsely claim censorship after not sending the plaintext. Upon further reflection, it was acknowledged that the problem is more challenging than anticipated, as existing solutions rely on slow and expensive blockchain bulletin boards.Ruben Somsen, a Bitcoin developer, responded by suggesting the possibility of creating a custom blockchain using Blind Merged Mining for a censorship-resistant data layer. Although it may not be the most practical solution, Ruben provided a link to more details about the perpetual one-way peg mechanism needed to pay for fees without introducing speculation.AdamISZ reflected on the difficulty of finding a solution for this problem without relying on the slow and expensive blockchain or begging the question. The proposed idea aims to make selective censorship difficult through cryptographic blinding and a proof-of-misbehavior approach. It is designed to work for various bitcoin-native systems, not just CoinJoin, and would allow systems like Joinmarket to run on a single bulletin board server with reduced resource requirements. The goal is to disincentivize censorship and make it challenging to achieve through collusion among servers. 2020-11-25T01:52:08+00:00 + In a post to the bitcoin-dev mailing list, AdamISZ asked for feedback on his idea for creating "bitcoin fungibility markets" that prioritize liquidity and privacy. However, Greg Maxwell pointed out a flaw in the idea, where makers could falsely claim censorship after not sending the plaintext. Upon further reflection, it was acknowledged that the problem is more challenging than anticipated, as existing solutions rely on slow and expensive blockchain bulletin boards.Ruben Somsen, a Bitcoin developer, responded by suggesting the possibility of creating a custom blockchain using Blind Merged Mining for a censorship-resistant data layer. Although it may not be the most practical solution, Ruben provided a link to more details about the perpetual one-way peg mechanism needed to pay for fees without introducing speculation.AdamISZ reflected on the difficulty of finding a solution for this problem without relying on the slow and expensive blockchain or begging the question. The proposed idea aims to make selective censorship difficult through cryptographic blinding and a proof-of-misbehavior approach. It is designed to work for various bitcoin-native systems, not just CoinJoin, and would allow systems like Joinmarket to run on a single bulletin board server with reduced resource requirements. The goal is to disincentivize censorship and make it challenging to achieve through collusion among servers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2020/combined_CoinPools-based-on-m-of-n-Schnorr-aggregated-signatures.xml b/static/bitcoin-dev/Nov_2020/combined_CoinPools-based-on-m-of-n-Schnorr-aggregated-signatures.xml index e8f434a9fe..28e781e186 100644 --- a/static/bitcoin-dev/Nov_2020/combined_CoinPools-based-on-m-of-n-Schnorr-aggregated-signatures.xml +++ b/static/bitcoin-dev/Nov_2020/combined_CoinPools-based-on-m-of-n-Schnorr-aggregated-signatures.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - CoinPools based on m-of-n Schnorr aggregated signatures - 2023-08-02T02:51:30.572504+00:00 - - ZmnSCPxj 2020-11-16 01:32:11+00:00 - - - Sridhar G 2020-11-15 22:18:17+00:00 - + 2025-09-26T15:57:26.531352+00:00 + python-feedgen + + + [bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated signatures Sridhar G + 2020-11-15T22:18:00.000Z + + + ZmnSCPxj + 2020-11-16T01:32:00.000Z + + - python-feedgen + 2 Combined summary - CoinPools based on m-of-n Schnorr aggregated signatures - 2023-08-02T02:51:30.572504+00:00 + 2025-09-26T15:57:26.531825+00:00 - The author presents a model for m-of-n multisig transactions using Schnorr aggregate signatures to facilitate CoinPools for off-chain scalability. The model involves the creation of a pool containing all N public keys, with a specified threshold M. Deposits can be made to this pool using an OP_LOAD_POOL_AGG_PUB_KEY OP_CHECKSIG script. The redeem script requires an aggregated signature from all signers and a bitmap of signers. To support this scheme, the author proposes two new opcodes: OP_POOL and OP_LOAD_POOL_AGG_PUB_KEY.The OP_POOL opcode allows the creation of a new coin pool, while the OP_LOAD_POOL_AGG_PUB_KEY opcode loads the pool, checks if there are at least 'm' signers, aggregates the public key of the signers, and verifies the SIGNERS_BITMAP. This bitmap is a 32-byte value that represents which public keys from the pool have signed the transaction.By utilizing a large pool of signers, the proposed scheme enables scalability of m-of-n multisig transactions and provides trust-minimized off-chain scalability solutions. However, a drawback of this approach is that it requires exposing the public keys of the pool members. In addition, the author discusses the possibility of generating an m-of-n aggregated pubkey, which would involve an interactive setup and extra data storage. The current plan is to implement an OP_CHECKSIGADD, where the script would be: OP_CHECKSIGADD OP_CHECKSIGADD OP_CHECKSIGADD OP_EQUAL. However, OP_POOL would have a single m-of-m signature.Overall, the proposal seeks feedback on whether this scheme is suitable for enabling CoinPool for the Bitcoin network, considering the potential exposure of public keys. 2020-11-16T01:32:11+00:00 + The author presents a model for m-of-n multisig transactions using Schnorr aggregate signatures to facilitate CoinPools for off-chain scalability. The model involves the creation of a pool containing all N public keys, with a specified threshold M. Deposits can be made to this pool using an OP_LOAD_POOL_AGG_PUB_KEY OP_CHECKSIG script. The redeem script requires an aggregated signature from all signers and a bitmap of signers. To support this scheme, the author proposes two new opcodes: OP_POOL and OP_LOAD_POOL_AGG_PUB_KEY.The OP_POOL opcode allows the creation of a new coin pool, while the OP_LOAD_POOL_AGG_PUB_KEY opcode loads the pool, checks if there are at least 'm' signers, aggregates the public key of the signers, and verifies the SIGNERS_BITMAP. This bitmap is a 32-byte value that represents which public keys from the pool have signed the transaction.By utilizing a large pool of signers, the proposed scheme enables scalability of m-of-n multisig transactions and provides trust-minimized off-chain scalability solutions. However, a drawback of this approach is that it requires exposing the public keys of the pool members. In addition, the author discusses the possibility of generating an m-of-n aggregated pubkey, which would involve an interactive setup and extra data storage. The current plan is to implement an OP_CHECKSIGADD, where the script would be: OP_CHECKSIGADD OP_CHECKSIGADD OP_CHECKSIGADD OP_EQUAL. However, OP_POOL would have a single m-of-m signature.Overall, the proposal seeks feedback on whether this scheme is suitable for enabling CoinPool for the Bitcoin network, considering the potential exposure of public keys. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2020/combined_Formal-specification-of-Miniscript-in-Alloy.xml b/static/bitcoin-dev/Nov_2020/combined_Formal-specification-of-Miniscript-in-Alloy.xml index 59e2a8adca..536bd65214 100644 --- a/static/bitcoin-dev/Nov_2020/combined_Formal-specification-of-Miniscript-in-Alloy.xml +++ b/static/bitcoin-dev/Nov_2020/combined_Formal-specification-of-Miniscript-in-Alloy.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Formal specification of Miniscript in Alloy - 2023-08-02T02:52:07.083199+00:00 - - Dmitry Petukhov 2020-11-25 16:09:46+00:00 - - - Clark Moody 2020-11-25 15:43:10+00:00 - - - Dmitry Petukhov 2020-11-25 11:15:55+00:00 - + 2025-09-26T15:57:15.881673+00:00 + python-feedgen + + + [bitcoin-dev] Formal specification of Miniscript in Alloy Dmitry Petukhov + 2020-11-25T11:15:00.000Z + + + Clark Moody + 2020-11-25T15:43:00.000Z + + + Dmitry Petukhov + 2020-11-25T16:09:00.000Z + + - python-feedgen + 2 Combined summary - Formal specification of Miniscript in Alloy - 2023-08-02T02:52:07.083199+00:00 + 2025-09-26T15:57:15.882224+00:00 - Dmitry Petukhov has recently developed a formal specification of Miniscript using the Alloy analyzer's specification language. This specification serves multiple purposes, including aiding in the implementation of Miniscript libraries, generating test cases for implementation, and ensuring the accuracy of the implementation against the spec. Furthermore, the spec can also be used to extend or modify Miniscript and explore its various properties.The Alloy spec created by Petukhov is noteworthy as it represents the first formal specification for Miniscript. Notably, the node definitions within the spec are highly readable, facilitating ease of use and comprehension. While other frameworks, such as the K framework, could have been used for this task, they lacked reference documentation at the time.However, users should bear in mind that the spec may contain some errors or inconsistencies. As a result, Dmitry encourages users to submit any issues they encounter on Github or communicate them through other means. By doing so, the spec can be refined and improved over time.In addition to sharing the spec on Github, Dmitry Petukhov also responded to Clark's query about whether there were any other spec definitions in alternate formal grammars. It appears that, at present, the Alloy spec is the only one available, but Dmitry welcomes any contributions or suggestions from individuals interested in Miniscript.Overall, the formal specification of Miniscript created by Dmitry Petukhov offers a valuable resource for developers and researchers working with Miniscript. With its potential applications in library implementation, test case generation, implementation verification, and exploration of Miniscript properties, this spec provides an important foundation for further progress in the field. 2020-11-25T16:09:46+00:00 + Dmitry Petukhov has recently developed a formal specification of Miniscript using the Alloy analyzer's specification language. This specification serves multiple purposes, including aiding in the implementation of Miniscript libraries, generating test cases for implementation, and ensuring the accuracy of the implementation against the spec. Furthermore, the spec can also be used to extend or modify Miniscript and explore its various properties.The Alloy spec created by Petukhov is noteworthy as it represents the first formal specification for Miniscript. Notably, the node definitions within the spec are highly readable, facilitating ease of use and comprehension. While other frameworks, such as the K framework, could have been used for this task, they lacked reference documentation at the time.However, users should bear in mind that the spec may contain some errors or inconsistencies. As a result, Dmitry encourages users to submit any issues they encounter on Github or communicate them through other means. By doing so, the spec can be refined and improved over time.In addition to sharing the spec on Github, Dmitry Petukhov also responded to Clark's query about whether there were any other spec definitions in alternate formal grammars. It appears that, at present, the Alloy spec is the only one available, but Dmitry welcomes any contributions or suggestions from individuals interested in Miniscript.Overall, the formal specification of Miniscript created by Dmitry Petukhov offers a valuable resource for developers and researchers working with Miniscript. With its potential applications in library implementation, test case generation, implementation verification, and exploration of Miniscript properties, this spec provides an important foundation for further progress in the field. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2020/combined_Out-of-band-transaction-fees.xml b/static/bitcoin-dev/Nov_2020/combined_Out-of-band-transaction-fees.xml index 36a965b5e5..fc1a773f49 100644 --- a/static/bitcoin-dev/Nov_2020/combined_Out-of-band-transaction-fees.xml +++ b/static/bitcoin-dev/Nov_2020/combined_Out-of-band-transaction-fees.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Out-of-band transaction fees - 2023-08-02T02:52:26.033368+00:00 - - Sebastian Geisler 2020-12-01 19:14:26+00:00 - - - ZmnSCPxj 2020-12-01 16:24:11+00:00 - - - ZmnSCPxj 2020-12-01 15:49:49+00:00 - - - Sebastian Geisler 2020-12-01 14:19:56+00:00 - - - eric at voskuil.org 2020-12-01 01:06:13+00:00 - - - Sebastian Geisler 2020-11-30 23:03:06+00:00 - + 2025-09-26T15:57:24.412787+00:00 + python-feedgen + + + [bitcoin-dev] Out-of-band transaction fees Sebastian Geisler + 2020-11-30T23:03:00.000Z + + + eric + 2020-12-01T01:06:00.000Z + + + Sebastian Geisler + 2020-12-01T14:19:00.000Z + + + ZmnSCPxj + 2020-12-01T15:49:00.000Z + + + ZmnSCPxj + 2020-12-01T16:24:00.000Z + + + Sebastian Geisler + 2020-12-01T19:14:00.000Z + + - python-feedgen + 2 Combined summary - Out-of-band transaction fees - 2023-08-02T02:52:26.033368+00:00 + 2025-09-26T15:57:24.413599+00:00 - In a discussion about improving the privacy of Bitcoin, participants consider alternative methods to enhance blockchain layer privacy. They explore the idea of paying someone to add their unspent transaction output (UTXO) to a transaction for fees, rather than relying on distinguishing honest service providers. The goal is to improve privacy regardless of standardized UTXO sizes. While protocols like JoinMarket and SwapMarket have been successful in this area, they have some overheads and require more UTXOs and larger transactions than necessary.Unequal output size CoinJoins are not well understood in terms of privacy properties, whereas evenly sized output CoinJoins offer efficiency. Speculatively, if Bitcoin becomes mainstream and transaction prices increase significantly, using Layer 2 (L2) technology and evenly sized UTXOs could be more cost-effective. However, this approach only works when exact values are unimportant and requires fee hacks.Although the initial idea has regulatory risks, there is potential for exploring an arbitrary-amount scheme that provides strong assurances efficiently. The conversation aims to devise a method for individuals to pay fees for transaction confirmation without linking other coins. A CoinJoin-like approach is suggested, using only Layer 1 (L1) and combining fees through a "FeeJoin" mechanism.The proposed mechanism involves a third-party service dividing its service into fixed-feerate bins. Clients can select their preferred feerate bin, ensuring miners and chain analysis cannot link the resulting transaction as they only see the resulting transaction. The ultimate objective is to improve privacy at the Bitcoin blockchain layer, regardless of the method used or whether standardized UTXO sizes are employed. Both JoinMarket and the upcoming SwapMarket do not require specific standardized UTXO sizes, giving clients the flexibility to choose any sizes they prefer.Developer Sebastian Geisler suggests the possibility of out-of-band transactions, allowing fees to be paid externally while preserving privacy. This would benefit tumbling and CoinJoin-type protocols. However, this approach relies on Layer 2 mechanisms like the Lightning Network and requires a reliable fee-bumping mechanism at Layer 1. Geisler highlights that out-of-band transaction fees have seen little interest thus far. One potential use case is sending UTXOs "intact" for settlement applications in Layer 2 systems.Geisler proposes having a standardized system for out-of-band transactions instead of each pool implementing its own API. Each service would announce the means of payment it supports, allowing users and miners to choose when paying or redeeming fees. Miners including a transaction would authenticate their claim with a unique public key. Nevertheless, concerns are raised about the centralizing effects and the potential difficulty of evaluating the trustworthiness of multiple third-party services.In summary, Sebastian Geisler's proposal of out-of-band transaction fees offers privacy-preserving fee payments in Bitcoin transactions. This can be beneficial for sending UTXOs "intact" and introducing further ambiguity in CoinJoin-like protocols. Standardizing such a system and mitigating centralizing effects are crucial. Users should be able to choose from different means of payment, and miners should authenticate their claims with a unique public key. Although not a general solution for fee payments, out-of-band options can assist specific protocols as Bitcoin serves as a settlement and reserve layer. 2020-12-01T19:14:26+00:00 + In a discussion about improving the privacy of Bitcoin, participants consider alternative methods to enhance blockchain layer privacy. They explore the idea of paying someone to add their unspent transaction output (UTXO) to a transaction for fees, rather than relying on distinguishing honest service providers. The goal is to improve privacy regardless of standardized UTXO sizes. While protocols like JoinMarket and SwapMarket have been successful in this area, they have some overheads and require more UTXOs and larger transactions than necessary.Unequal output size CoinJoins are not well understood in terms of privacy properties, whereas evenly sized output CoinJoins offer efficiency. Speculatively, if Bitcoin becomes mainstream and transaction prices increase significantly, using Layer 2 (L2) technology and evenly sized UTXOs could be more cost-effective. However, this approach only works when exact values are unimportant and requires fee hacks.Although the initial idea has regulatory risks, there is potential for exploring an arbitrary-amount scheme that provides strong assurances efficiently. The conversation aims to devise a method for individuals to pay fees for transaction confirmation without linking other coins. A CoinJoin-like approach is suggested, using only Layer 1 (L1) and combining fees through a "FeeJoin" mechanism.The proposed mechanism involves a third-party service dividing its service into fixed-feerate bins. Clients can select their preferred feerate bin, ensuring miners and chain analysis cannot link the resulting transaction as they only see the resulting transaction. The ultimate objective is to improve privacy at the Bitcoin blockchain layer, regardless of the method used or whether standardized UTXO sizes are employed. Both JoinMarket and the upcoming SwapMarket do not require specific standardized UTXO sizes, giving clients the flexibility to choose any sizes they prefer.Developer Sebastian Geisler suggests the possibility of out-of-band transactions, allowing fees to be paid externally while preserving privacy. This would benefit tumbling and CoinJoin-type protocols. However, this approach relies on Layer 2 mechanisms like the Lightning Network and requires a reliable fee-bumping mechanism at Layer 1. Geisler highlights that out-of-band transaction fees have seen little interest thus far. One potential use case is sending UTXOs "intact" for settlement applications in Layer 2 systems.Geisler proposes having a standardized system for out-of-band transactions instead of each pool implementing its own API. Each service would announce the means of payment it supports, allowing users and miners to choose when paying or redeeming fees. Miners including a transaction would authenticate their claim with a unique public key. Nevertheless, concerns are raised about the centralizing effects and the potential difficulty of evaluating the trustworthiness of multiple third-party services.In summary, Sebastian Geisler's proposal of out-of-band transaction fees offers privacy-preserving fee payments in Bitcoin transactions. This can be beneficial for sending UTXOs "intact" and introducing further ambiguity in CoinJoin-like protocols. Standardizing such a system and mitigating centralizing effects are crucial. Users should be able to choose from different means of payment, and miners should authenticate their claims with a unique public key. Although not a general solution for fee payments, out-of-band options can assist specific protocols as Bitcoin serves as a settlement and reserve layer. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml b/static/bitcoin-dev/Nov_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml index 37fc060e18..a2c1fb15a6 100644 --- a/static/bitcoin-dev/Nov_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml +++ b/static/bitcoin-dev/Nov_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Progress on bech32 for future Segwit Versions (BIP-173) - 2023-08-02T02:47:10.950630+00:00 - - Pieter Wuille 2020-12-18 02:02:04+00:00 - - - Ryan Grant 2020-12-08 17:39:23+00:00 - - - Pieter Wuille 2020-12-06 20:43:49+00:00 - - - David A. Harding 2020-12-06 13:04:53+00:00 - - - Pieter Wuille 2020-12-05 23:10:51+00:00 - - - Pieter Wuille 2020-12-05 22:59:17+00:00 - - - Mike Schmidt 2020-11-06 19:49:44+00:00 - - - Pieter Wuille 2020-10-28 00:20:40+00:00 - - - Rusty Russell 2020-10-21 04:51:34+00:00 - - - Rusty Russell 2020-10-21 04:39:32+00:00 - - - ZmnSCPxj 2020-10-21 03:05:35+00:00 - - - Mike Schmidt 2020-10-20 23:52:07+00:00 - - - Pieter Wuille 2020-10-20 20:12:25+00:00 - - - David A. Harding 2020-10-20 10:29:52+00:00 - - - Riccardo Casatta 2020-10-20 09:21:43+00:00 - - - Rusty Russell 2020-10-20 03:31:45+00:00 - - - Rusty Russell 2020-10-20 00:42:06+00:00 - - - Pieter Wuille 2020-10-19 22:55:50+00:00 - - - Rusty Russell 2020-10-19 00:49:17+00:00 - - - Pieter Wuille 2020-10-16 21:09:04+00:00 - - - Rusty Russell 2020-10-15 01:40:30+00:00 - - - Russell O'Connor 2020-10-08 15:21:47+00:00 - - - David A. Harding 2020-10-08 14:59:38+00:00 - - - Rusty Russell 2020-10-08 00:21:10+00:00 - + 2025-09-26T15:57:18.034703+00:00 + python-feedgen + + + [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173) Rusty Russell + 2020-10-08T00:21:00.000Z + + + David A. Harding + 2020-10-08T14:59:00.000Z + + + Russell O'Connor + 2020-10-08T15:21:00.000Z + + + Rusty Russell + 2020-10-15T01:40:00.000Z + + + Pieter Wuille + 2020-10-16T21:09:00.000Z + + + Rusty Russell + 2020-10-19T00:49:00.000Z + + + Pieter Wuille + 2020-10-19T22:55:00.000Z + + + Rusty Russell + 2020-10-20T00:42:00.000Z + + + Rusty Russell + 2020-10-20T03:31:00.000Z + + + Riccardo Casatta + 2020-10-20T09:21:00.000Z + + + David A. Harding + 2020-10-20T10:29:00.000Z + + + Pieter Wuille + 2020-10-20T20:12:00.000Z + + + Mike Schmidt + 2020-10-20T23:52:00.000Z + + + ZmnSCPxj + 2020-10-21T03:05:00.000Z + + + Rusty Russell + 2020-10-21T04:39:00.000Z + + + Rusty Russell + 2020-10-21T04:51:00.000Z + + + Pieter Wuille + 2020-10-28T00:20:00.000Z + + + Mike Schmidt + 2020-11-06T19:49:00.000Z + + + Pieter Wuille + 2020-12-05T22:59:00.000Z + + + Pieter Wuille + 2020-12-05T23:10:00.000Z + + + David A. Harding + 2020-12-06T13:04:00.000Z + + + Pieter Wuille + 2020-12-06T20:43:00.000Z + + + Ryan Grant + 2020-12-08T17:39:00.000Z + + + Pieter Wuille + 2020-12-18T02:02:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Progress on bech32 for future Segwit Versions (BIP-173) - 2023-08-02T02:47:10.950630+00:00 + 2025-09-26T15:57:18.037436+00:00 - In a recent discussion on the Bitcoin mailing list, Pieter Wuille and Rusty Russell explored the implementation of changes to witness version 1 (v1) addresses. Currently, there are no v1 receivers, so the focus is on determining what software and infrastructure support sending to v1 addresses and whether they will upgrade. The first option discussed is to continue using v1, while the second option involves upgrading to a new version. There are concerns about trailing typos causing issues for non-upgraded software under option 1. Option 2, on the other hand, would likely lead to fixes when someone attempts a v1 send. However, it is possible that non-upgraded software may never get fixed, delaying the ability to use v1 addresses.Pieter is interested in understanding which codebases, services, and infrastructure currently support sending to witness v1 BIP173 addresses. Rusty suggests spamming an address from various sources to test compatibility with v1 addresses. They discuss the potential adoption of new technology based on the replacement of older infrastructure and codebases. Both Pieter and Rusty acknowledge that their thinking on this matter may change over time.Another proposal brought up by Rusty Russell involves two options for the future of v1 receivers. The first option is to continue using v1, while the second option requires upgrading to a new version. The support for sending to v1 BIP173 addresses is a key consideration in making this decision. Rusty favors the second option as it forces upgrades and breaks clearly. He believes that accepting v1 addresses without upgrades could create liabilities. David A. Harding agrees with the first proposal, highlighting the effort put into obtaining widespread support for bech32 addresses. Harding suggests that consensus should restrict v1 witness program size to maximize safety.In a separate thread, David A. Harding expresses his preference for using the backwards compatible proposal from BIPs PR#945. He suggests that consensus should restrict v1 witness program size by rejecting transactions with scriptPubKeys paying v1 witness programs that aren't exactly 32 bytes. Harding believes that deferring a hard decision is not useful, and he hopes that most software will have implemented length limits by the time segwit v2 is used.Rusty Russell proposes an alternative to the length restrictions discussed in a BIPs pull request. The alternative involves using a checksum change based on the first byte, unless the first byte is 0. There are two proposals debated in the discussion. The first proposal suggests length restrictions for future segwits, while the second proposal suggests a checksum change based on the first byte. Rusty prefers the second option as it forces upgrades and breaks clearly. However, David A. Harding argues that the second option does not force upgrades but creates another opt-in address format. Harding favors the backwards compatible proposal from BIPs PR#945 and suggests consensus restricting v1 witness program size for safety purposes.The author of the proposal suggests an alternative to length restrictions proposed by Rusty Russell. The alternative involves using a variant based on the first byte, unless the first byte is 0. There are two proposals discussed: length restrictions and a checksum change based on the first byte. The first proposal restricts future segwit versions, while the second weakens guarantees against typos. The author prefers the second proposal as it forces upgrades and addresses the length extension bug. They emphasize the need for a decision to be made promptly to begin upgrading software. It is also mentioned that Lightning uses bech32 over longer lengths but will follow Bitcoin's choice.Overall, the discussions revolve around the implementation of changes to witness version 1 addresses, the support for sending to v1 BIP173 addresses, and the options for future versions. Various proposals and concerns are raised regarding compatibility, upgrades, safety, and the simplicity of the changes. The participants acknowledge that their perspectives may evolve over time and emphasize the importance of gathering data and making informed decisions. 2020-12-18T02:02:04+00:00 + In a recent discussion on the Bitcoin mailing list, Pieter Wuille and Rusty Russell explored the implementation of changes to witness version 1 (v1) addresses. Currently, there are no v1 receivers, so the focus is on determining what software and infrastructure support sending to v1 addresses and whether they will upgrade. The first option discussed is to continue using v1, while the second option involves upgrading to a new version. There are concerns about trailing typos causing issues for non-upgraded software under option 1. Option 2, on the other hand, would likely lead to fixes when someone attempts a v1 send. However, it is possible that non-upgraded software may never get fixed, delaying the ability to use v1 addresses.Pieter is interested in understanding which codebases, services, and infrastructure currently support sending to witness v1 BIP173 addresses. Rusty suggests spamming an address from various sources to test compatibility with v1 addresses. They discuss the potential adoption of new technology based on the replacement of older infrastructure and codebases. Both Pieter and Rusty acknowledge that their thinking on this matter may change over time.Another proposal brought up by Rusty Russell involves two options for the future of v1 receivers. The first option is to continue using v1, while the second option requires upgrading to a new version. The support for sending to v1 BIP173 addresses is a key consideration in making this decision. Rusty favors the second option as it forces upgrades and breaks clearly. He believes that accepting v1 addresses without upgrades could create liabilities. David A. Harding agrees with the first proposal, highlighting the effort put into obtaining widespread support for bech32 addresses. Harding suggests that consensus should restrict v1 witness program size to maximize safety.In a separate thread, David A. Harding expresses his preference for using the backwards compatible proposal from BIPs PR#945. He suggests that consensus should restrict v1 witness program size by rejecting transactions with scriptPubKeys paying v1 witness programs that aren't exactly 32 bytes. Harding believes that deferring a hard decision is not useful, and he hopes that most software will have implemented length limits by the time segwit v2 is used.Rusty Russell proposes an alternative to the length restrictions discussed in a BIPs pull request. The alternative involves using a checksum change based on the first byte, unless the first byte is 0. There are two proposals debated in the discussion. The first proposal suggests length restrictions for future segwits, while the second proposal suggests a checksum change based on the first byte. Rusty prefers the second option as it forces upgrades and breaks clearly. However, David A. Harding argues that the second option does not force upgrades but creates another opt-in address format. Harding favors the backwards compatible proposal from BIPs PR#945 and suggests consensus restricting v1 witness program size for safety purposes.The author of the proposal suggests an alternative to length restrictions proposed by Rusty Russell. The alternative involves using a variant based on the first byte, unless the first byte is 0. There are two proposals discussed: length restrictions and a checksum change based on the first byte. The first proposal restricts future segwit versions, while the second weakens guarantees against typos. The author prefers the second proposal as it forces upgrades and addresses the length extension bug. They emphasize the need for a decision to be made promptly to begin upgrading software. It is also mentioned that Lightning uses bech32 over longer lengths but will follow Bitcoin's choice.Overall, the discussions revolve around the implementation of changes to witness version 1 addresses, the support for sending to v1 BIP173 addresses, and the options for future versions. Various proposals and concerns are raised regarding compatibility, upgrades, safety, and the simplicity of the changes. The participants acknowledge that their perspectives may evolve over time and emphasize the importance of gathering data and making informed decisions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2020/combined_RFC-BIP-0002-Defer-not-reject-.xml b/static/bitcoin-dev/Nov_2020/combined_RFC-BIP-0002-Defer-not-reject-.xml index 628e472e84..c1561a6883 100644 --- a/static/bitcoin-dev/Nov_2020/combined_RFC-BIP-0002-Defer-not-reject-.xml +++ b/static/bitcoin-dev/Nov_2020/combined_RFC-BIP-0002-Defer-not-reject-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - RFC BIP-0002: Defer, not reject. - 2023-08-02T02:50:33.531766+00:00 - - アルム　カールヨハン 2020-11-02 12:11:40+00:00 - - - アルム　カールヨハン 2020-10-13 10:06:09+00:00 - + 2025-09-26T15:57:30.755104+00:00 + python-feedgen + + + [bitcoin-dev] RFC BIP-0002: Defer, not reject アルム　カールヨハン + 2020-10-13T10:06:00.000Z + + + アルム　カールヨハン + 2020-11-02T12:11:00.000Z + + - python-feedgen + 2 Combined summary - RFC BIP-0002: Defer, not reject. - 2023-08-02T02:50:33.531766+00:00 + 2025-09-26T15:57:30.755568+00:00 - A proposed change to BIP-0002 has been made by アルム　カールヨハン, suggesting that the current 3-year-rule be modified. Currently, a BIP can only be changed to "Rejected" status after three years. However, アルム　カールヨハン proposes that the status should be changed to "Deferred" instead of "Rejected". The current rules for rejecting a BIP have ambiguous meanings, with both "soft" and "hard" rejections. The aim of this proposal is to disambiguate the second option into "deferred" status or add a new status called "Inactive".In addition to this proposal, there is an alternative suggestion that proposes updating the rejection criteria in BIP 2. The proposal recommends requiring an actual concern rather than just a lack of progress in three years for a BIP to be rejected. The details of these proposals can be found on the following link: https://github.com/bitcoin/bips/pull/1016. Readers are encouraged to consider either one or both of these proposals. The proposer of the minor change to BIP-0002 suggests allowing anyone to change the status of a BIP to "Deferred" instead of "Rejected". The current 3-year-rule already has ambiguous meaning with "hard" and "soft" rejects. The intention of this proposal is to clarify the second option by either classifying it as "deferred" or introducing a new status called "Inactive". It is important to note that the BIP editor will not unreasonably reject a BIP. There are several reasons for rejecting a BIP, including duplication of effort, disregard for formatting rules, being too unfocused or broad, being technically unsound, not providing proper motivation or addressing backward compatibility, or not aligning with the Bitcoin philosophy. If a BIP has not made progress in three years, it may be changed from Draft or Proposed status to Rejected status upon request by any person. However, if the champion of the BIP provides revisions that meaningfully address public criticism, it may be changed to Draft status. Alternatively, if the BIP meets the required criteria as described in the previous paragraph, it may be changed to Proposed status. 2020-11-02T12:11:40+00:00 + A proposed change to BIP-0002 has been made by アルム　カールヨハン, suggesting that the current 3-year-rule be modified. Currently, a BIP can only be changed to "Rejected" status after three years. However, アルム　カールヨハン proposes that the status should be changed to "Deferred" instead of "Rejected". The current rules for rejecting a BIP have ambiguous meanings, with both "soft" and "hard" rejections. The aim of this proposal is to disambiguate the second option into "deferred" status or add a new status called "Inactive".In addition to this proposal, there is an alternative suggestion that proposes updating the rejection criteria in BIP 2. The proposal recommends requiring an actual concern rather than just a lack of progress in three years for a BIP to be rejected. The details of these proposals can be found on the following link: https://github.com/bitcoin/bips/pull/1016. Readers are encouraged to consider either one or both of these proposals. The proposer of the minor change to BIP-0002 suggests allowing anyone to change the status of a BIP to "Deferred" instead of "Rejected". The current 3-year-rule already has ambiguous meaning with "hard" and "soft" rejects. The intention of this proposal is to clarify the second option by either classifying it as "deferred" or introducing a new status called "Inactive". It is important to note that the BIP editor will not unreasonably reject a BIP. There are several reasons for rejecting a BIP, including duplication of effort, disregard for formatting rules, being too unfocused or broad, being technically unsound, not providing proper motivation or addressing backward compatibility, or not aligning with the Bitcoin philosophy. If a BIP has not made progress in three years, it may be changed from Draft or Proposed status to Rejected status upon request by any person. However, if the champion of the BIP provides revisions that meaningfully address public criticism, it may be changed to Draft status. Alternatively, if the BIP meets the required criteria as described in the previous paragraph, it may be changed to Proposed status. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_A-fee-bumping-model.xml b/static/bitcoin-dev/Nov_2021/combined_A-fee-bumping-model.xml index c346d5ec83..49fc7c0aff 100644 --- a/static/bitcoin-dev/Nov_2021/combined_A-fee-bumping-model.xml +++ b/static/bitcoin-dev/Nov_2021/combined_A-fee-bumping-model.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A fee-bumping model - 2023-08-02T05:10:48.545853+00:00 + 2025-09-26T15:34:22.784714+00:00 + python-feedgen Peter Todd 2021-12-09 13:50:33+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - A fee-bumping model - 2023-08-02T05:10:48.545853+00:00 + 2025-09-26T15:34:22.784878+00:00 - emails discussing the topic. It also mentions the idea of creating an insurance project for the LGBTQ community in India and shares a presentation by Jack Mallers on creating derivatives to hedge fees.In summary, the discussions and articles revolve around the importance of fee-bumping strategies for the security and efficiency of protocols built on Bitcoin. The challenges of fee estimation, confirmation of transactions, and overpayments are addressed, along with proposed solutions such as presigned transactions, reserve feerates, and consolidation with fanout. The need for accurate fee estimation, policy-level mitigations, new consensus rules, and potential insurance markets are emphasized throughout the conversations and articles. 2021-12-09T13:50:33+00:00 + emails discussing the topic. It also mentions the idea of creating an insurance project for the LGBTQ community in India and shares a presentation by Jack Mallers on creating derivatives to hedge fees.In summary, the discussions and articles revolve around the importance of fee-bumping strategies for the security and efficiency of protocols built on Bitcoin. The challenges of fee estimation, confirmation of transactions, and overpayments are addressed, along with proposed solutions such as presigned transactions, reserve feerates, and consolidation with fanout. The need for accurate fee estimation, policy-level mitigations, new consensus rules, and potential insurance markets are emphasized throughout the conversations and articles. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_Covenant-opcode-proposal-OP-CONSTRAINDESTINATION-an-alternative-to-OP-CTV-.xml b/static/bitcoin-dev/Nov_2021/combined_Covenant-opcode-proposal-OP-CONSTRAINDESTINATION-an-alternative-to-OP-CTV-.xml index b35e1c1393..abdd07e653 100644 --- a/static/bitcoin-dev/Nov_2021/combined_Covenant-opcode-proposal-OP-CONSTRAINDESTINATION-an-alternative-to-OP-CTV-.xml +++ b/static/bitcoin-dev/Nov_2021/combined_Covenant-opcode-proposal-OP-CONSTRAINDESTINATION-an-alternative-to-OP-CTV-.xml @@ -1,50 +1,115 @@ - + 2 Combined summary - Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) - 2023-08-02T04:24:39.456958+00:00 - - Billy Tetrud 2021-11-01 01:19:42+00:00 - - - Billy Tetrud 2021-07-30 18:42:23+00:00 - - - Jeremy 2021-07-28 22:30:19+00:00 - - - Billy Tetrud 2021-07-28 17:57:09+00:00 - - - Zac Greenwood 2021-07-28 04:57:33+00:00 - - - Billy Tetrud 2021-07-27 17:21:11+00:00 - - - Zac Greenwood 2021-07-27 11:18:11+00:00 - - - Billy Tetrud 2021-07-27 00:41:29+00:00 - - - James MacWhyte 2021-07-26 21:08:09+00:00 - - - Billy Tetrud 2021-07-26 20:18:35+00:00 - - - David A. Harding 2021-07-26 00:05:53+00:00 - - - Billy Tetrud 2021-07-25 19:49:38+00:00 - - - David A. Harding 2021-07-25 05:38:03+00:00 - - - Billy Tetrud 2021-07-21 05:56:10+00:00 - + 2025-09-26T15:34:18.546605+00:00 + python-feedgen + + + [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud + 2021-07-21T05:56:00.000Z + + + David A. Harding + 2021-07-25T05:38:00.000Z + + + Billy Tetrud + 2021-07-25T19:49:00.000Z + + + David A. Harding + 2021-07-26T00:05:00.000Z + + + Billy Tetrud + 2021-07-26T20:18:00.000Z + + + James MacWhyte + 2021-07-26T21:08:00.000Z + + + Billy Tetrud + 2021-07-27T00:41:00.000Z + + + Zac Greenwood + 2021-07-27T11:18:00.000Z + + + Billy Tetrud + 2021-07-27T17:21:00.000Z + + + Zac Greenwood + 2021-07-28T04:57:00.000Z + + + Billy Tetrud + 2021-07-28T17:57:00.000Z + + + Jeremy + 2021-07-28T22:30:00.000Z + + + Billy Tetrud + 2021-07-30T18:42:00.000Z + + + [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood + 2021-07-31T20:01:00.000Z + + + Billy Tetrud + 2021-08-02T04:40:00.000Z + + + ZmnSCPxj + 2021-08-10T02:17:00.000Z + + + Zac Greenwood + 2021-08-13T11:02:00.000Z + + + ZmnSCPxj + 2021-08-14T01:50:00.000Z + + + Zac Greenwood + 2021-08-16T11:17:00.000Z + + + ZmnSCPxj + 2021-08-16T11:48:00.000Z + + + Zac Greenwood + 2021-08-30T14:43:00.000Z + + + ZmnSCPxj + 2021-08-31T09:00:00.000Z + + + Zac Greenwood + 2021-08-31T14:09:00.000Z + + + ZmnSCPxj + 2021-08-31T14:22:00.000Z + + + Zac Greenwood + 2021-09-01T15:15:00.000Z + + + Billy Tetrud + 2021-11-01T01:19:00.000Z + + @@ -59,13 +124,13 @@ - python-feedgen + 2 Combined summary - Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) - 2023-08-02T04:24:39.456958+00:00 + 2025-09-26T15:34:18.549563+00:00 - The conversation begins with Billy explaining the benefits of a 2-key wallet vault using OP_CD over a normal 2-of-2 multisig wallet. He highlights that with a wallet vault, only one key is needed to spend funds, but an attacker would need to steal two or more keys. This provides better redundancy and security. Billy also shares a link to a wallet vault design that utilizes OP_CD and discusses his vision for creating highly secure wallets.The discussion then shifts to implementing a mechanism to limit the maximum amount that can be sent from an address. Billy suggests designing a system where coins are combined in a single output and encumbered with a script that allows a limited amount to be sent while requiring the remaining bitcoins to be returned to the sender. He emphasizes the effectiveness of such a system in preventing theft. Zac further elaborates on how this mechanism might work in a typical use case scenario and proposes rate-limiting parameters that could be implemented.Next, the optimization of Bitcoin transactions is discussed. Jeremy suggests splitting up the fee limiting functionality from OP_CD into a separate opcode called OP_LIMITFEECONTRIBUTION. Billy acknowledges the considerations involved in this approach, including evaluating input addresses without knowing their contribution amounts. He also suggests allowing the omission of an output value in cases where the entire output amount is contributed by that input to reduce transaction size.The conversations highlight the benefits, limitations, and considerations related to optimizing Bitcoin transactions, implementing mechanisms to limit the maximum amount sent from an address, and creating secure wallet vaults using covenant opcodes like OP_CD. They also discuss the potential impact on transaction size, security, and user experience.Another topic of discussion is the manipulation of fee rates in Bitcoin transactions by miners. It is estimated that filling 15% of each block with self-pay transactions could raise median fees by approximately 5%. However, this type of attack may not be profitable for dishonest miners due to the large number of transactions needed. The proposed use case for wallet vaults is also discussed, aiming to limit the amount that can be stolen through fees by attackers. Concerns are raised about miners abusing the fee limit mechanism in multi-party scenarios.In an email exchange, Billy suggests calculating the median fee rate for each block and taking the average of those stored per-block median numbers. However, Dave disagrees and believes that miners may have the opportunity to raise the fee rate in certain situations. It is emphasized that every miner is also a user of Bitcoin, and every Bitcoin user may eventually become a miner. Dave provides an example where an attacker could work with a cartel of miners to raise the median fee rate and take all of someone's coins in fees.The proposal being discussed involves constraining the amount of fee that an output can contribute. MedianFeeRate and maxFeeContribution are defined as mechanisms to calculate and limit fees. Storing the feerate for every transaction in a 3,000 block window is considered impractical, so it is suggested to find the median fee-rate for each block instead. Concerns are expressed regarding the effect of this proposal on miner incentives and the redundancy of the fee mechanism.Finally, the OP_CONSTRAINDESTINATION opcode is proposed as a solution to restrict the destination address that an output's coins can be directed to. This opcode allows for step-wise covenant scripts and aims to create more flexible wallet vaults compared to OP_CHECKTEMPLATEVERIFY. The proposal can be found on Github, and feedback is welcomed to improve its presentation or identify any issues. 2021-11-01T01:19:42+00:00 + The conversation begins with Billy explaining the benefits of a 2-key wallet vault using OP_CD over a normal 2-of-2 multisig wallet. He highlights that with a wallet vault, only one key is needed to spend funds, but an attacker would need to steal two or more keys. This provides better redundancy and security. Billy also shares a link to a wallet vault design that utilizes OP_CD and discusses his vision for creating highly secure wallets.The discussion then shifts to implementing a mechanism to limit the maximum amount that can be sent from an address. Billy suggests designing a system where coins are combined in a single output and encumbered with a script that allows a limited amount to be sent while requiring the remaining bitcoins to be returned to the sender. He emphasizes the effectiveness of such a system in preventing theft. Zac further elaborates on how this mechanism might work in a typical use case scenario and proposes rate-limiting parameters that could be implemented.Next, the optimization of Bitcoin transactions is discussed. Jeremy suggests splitting up the fee limiting functionality from OP_CD into a separate opcode called OP_LIMITFEECONTRIBUTION. Billy acknowledges the considerations involved in this approach, including evaluating input addresses without knowing their contribution amounts. He also suggests allowing the omission of an output value in cases where the entire output amount is contributed by that input to reduce transaction size.The conversations highlight the benefits, limitations, and considerations related to optimizing Bitcoin transactions, implementing mechanisms to limit the maximum amount sent from an address, and creating secure wallet vaults using covenant opcodes like OP_CD. They also discuss the potential impact on transaction size, security, and user experience.Another topic of discussion is the manipulation of fee rates in Bitcoin transactions by miners. It is estimated that filling 15% of each block with self-pay transactions could raise median fees by approximately 5%. However, this type of attack may not be profitable for dishonest miners due to the large number of transactions needed. The proposed use case for wallet vaults is also discussed, aiming to limit the amount that can be stolen through fees by attackers. Concerns are raised about miners abusing the fee limit mechanism in multi-party scenarios.In an email exchange, Billy suggests calculating the median fee rate for each block and taking the average of those stored per-block median numbers. However, Dave disagrees and believes that miners may have the opportunity to raise the fee rate in certain situations. It is emphasized that every miner is also a user of Bitcoin, and every Bitcoin user may eventually become a miner. Dave provides an example where an attacker could work with a cartel of miners to raise the median fee rate and take all of someone's coins in fees.The proposal being discussed involves constraining the amount of fee that an output can contribute. MedianFeeRate and maxFeeContribution are defined as mechanisms to calculate and limit fees. Storing the feerate for every transaction in a 3,000 block window is considered impractical, so it is suggested to find the median fee-rate for each block instead. Concerns are expressed regarding the effect of this proposal on miner incentives and the redundancy of the fee mechanism.Finally, the OP_CONSTRAINDESTINATION opcode is proposed as a solution to restrict the destination address that an output's coins can be directed to. This opcode allows for step-wise covenant scripts and aims to create more flexible wallet vaults compared to OP_CHECKTEMPLATEVERIFY. The proposal can be found on Github, and feedback is welcomed to improve its presentation or identify any issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml b/static/bitcoin-dev/Nov_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml index 6a174a0cb6..7ff93c6ae1 100644 --- a/static/bitcoin-dev/Nov_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml +++ b/static/bitcoin-dev/Nov_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Mock introducing vulnerability in important Bitcoin projects - 2023-08-02T04:51:41.971421+00:00 - - Anthony Towns 2022-08-19 03:09:46+00:00 - - - Prayank 2021-11-18 20:29:24+00:00 - - - ZmnSCPxj 2021-10-04 03:59:34+00:00 - - - Luke Dashjr 2021-10-03 21:33:43+00:00 - - - Manuel Costa 2021-10-03 09:11:53+00:00 - - - Prayank 2021-10-02 09:19:37+00:00 - - - Ryan Grant 2021-10-01 20:15:56+00:00 - - - Prayank 2021-10-01 15:55:15+00:00 - - - ZmnSCPxj 2021-10-01 12:27:19+00:00 - - - Prayank 2021-10-01 03:03:00+00:00 - - - Ruben Somsen 2021-09-30 20:36:08+00:00 - - - Prayank 2021-09-27 23:19:40+00:00 - - - ZmnSCPxj 2021-09-27 10:13:02+00:00 - - - Prayank 2021-09-27 01:52:41+00:00 - + 2025-09-26T15:34:08.036357+00:00 + python-feedgen + + + [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects Prayank + 2021-09-27T01:52:00.000Z + + + ZmnSCPxj + 2021-09-27T10:13:00.000Z + + + Prayank + 2021-09-27T23:19:00.000Z + + + Ruben Somsen + 2021-09-30T20:36:00.000Z + + + Prayank + 2021-10-01T03:03:00.000Z + + + ZmnSCPxj + 2021-10-01T12:27:00.000Z + + + Prayank + 2021-10-01T15:55:00.000Z + + + Ryan Grant + 2021-10-01T20:15:00.000Z + + + Prayank + 2021-10-02T09:19:00.000Z + + + Manuel Costa + 2021-10-03T09:11:00.000Z + + + Luke Dashjr + 2021-10-03T21:33:00.000Z + + + ZmnSCPxj + 2021-10-04T03:59:00.000Z + + + Prayank + 2021-11-18T20:29:00.000Z + + + Anthony Towns + 2022-08-19T03:09:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Mock introducing vulnerability in important Bitcoin projects - 2023-08-02T04:51:41.971421+00:00 + 2025-09-26T15:34:08.037947+00:00 - In November 2021, Prayank announced an exercise to test the review process in three Bitcoin projects: Bitcoin Core, LND, and Bisq. They created a salted hash for the username and planned to create pull requests over the next six months. If vulnerabilities were caught during the review process, they would publicly announce them, but if not, they would privately reveal them later. However, after nine months, there has been no public report on the exercise, leaving it unclear whether any vulnerabilities have been introduced.The email conversation emphasizes the importance of regularly testing and verifying the review process in open-source Bitcoin projects. One participant suggests using commit messages with specific requirements to test the process against attacks. Another participant proposes that developers should be forced to opt-in to practice rounds of testing, as they cannot opt-out of potential real-world attacks. The email concludes by emphasizing the importance of independent thought during the review process.ZmnSCPxj suggests improving the review process to prevent attacks and waste contributors' time. They propose a scheme involving commit messages with specific requirements and the option for developers to opt-out of the study. However, they note that developers cannot opt out of potential NSA attacks.A discussion thread raises concerns about potential attempts to introduce vulnerabilities into Bitcoin Core codebase. Some proposals suggest a "Red Team exercise" to test the system's resilience. Others argue for improving the review process instead. The proposed exercise would involve public precommitments collected at ceremonial intervals, with community approval granted for the inserted security flaws.The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes are proposed, including a sortition system. The ideal process involves one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The process includes public precommitments and the use of block hashes as a random oracle.The post proposes a scheme to improve security in Bitcoin development using a sortition system. The scheme involves public precommitments collected at ceremonial intervals, with hash1 being a sortition ticket and hash2 being a public precommitment. The random oracle could be block hashes, and the red-team-concurrency difficulty parameter could control the selection process. The developer would have community approval to opportunistically insert a security flaw.The proposed exercise aims to improve the reputation factor and review attention for new pull requests. It suggests a secret sortition system to encourage more developers to participate without harming their reputation. The scheme includes public precommitments collected at ceremonial intervals and a red-team-concurrency difficulty parameter.The email exchange between Prayank and ZmnSCPxj discusses the importance of review processes in open-source Bitcoin projects. They agree on the necessity of reviews to catch vulnerabilities and caution against using unmerged PRs in production without careful review. Prayank proposes an exercise to test the review process by introducing vulnerability-adding PRs, while ZmnSCPxj emphasizes the need for private handling of any vulnerabilities found.The email discussion highlights the importance of review processes for ensuring security in Bitcoin development. The group agrees that relying on reviews is better for security and discusses the value of testing vulnerabilities in the review process. They propose a plan to create pseudonyms and introduce vulnerability-adding PRs to targets to test the review processes. The plan includes inserting random numbers among the commitments and publicly praising successful reviews.Prayank's proposal to conduct an exercise to study vulnerabilities in Bitcoin projects is met with caution. Ruben Somsen advises getting approval from contributors before proceeding to avoid causing mistrust and extra work for existing contributors. Prayank emphasizes reviewing pull requests based on code rather than author claims and asks whether trusting authors or having a good review process is better for security. They mention several Bitcoin projects they plan to test and note that x00 will assist them in the exercise.Prayank proposes an exercise to study vulnerabilities in Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating new GitHub accounts, studying issues in various Bitcoin projects, preparing pull requests to introduce vulnerabilities, and documenting the results. x00 will assist Prayank in this exercise, which has no fixed completion date.The email thread discusses introducing vulnerabilities in Bitcoin projects and observing how maintainers and reviewers respond. Ruben Somsen advises caution and suggests obtaining approval from contributors beforehand. ZmnSCPxj proposes a method using hash names and randomized salt as precommitments. They also highlight the potential impact on existing contributors and refer to a similar event in the Linux community.Prayank proposes an exercise to introduce vulnerabilities in Bitcoin projects and document the responses of maintainers and reviewers. They plan to create new GitHub accounts, study issues in various Bitcoin projects, and prepare pull requests to introduce vulnerabilities. They mention x00 as someone who will assist them in the exercise.In an email exchange, Prayank proposes an exercise to introduce vulnerabilities in various important Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating 2022-08-19T03:09:46+00:00 + In November 2021, Prayank announced an exercise to test the review process in three Bitcoin projects: Bitcoin Core, LND, and Bisq. They created a salted hash for the username and planned to create pull requests over the next six months. If vulnerabilities were caught during the review process, they would publicly announce them, but if not, they would privately reveal them later. However, after nine months, there has been no public report on the exercise, leaving it unclear whether any vulnerabilities have been introduced.The email conversation emphasizes the importance of regularly testing and verifying the review process in open-source Bitcoin projects. One participant suggests using commit messages with specific requirements to test the process against attacks. Another participant proposes that developers should be forced to opt-in to practice rounds of testing, as they cannot opt-out of potential real-world attacks. The email concludes by emphasizing the importance of independent thought during the review process.ZmnSCPxj suggests improving the review process to prevent attacks and waste contributors' time. They propose a scheme involving commit messages with specific requirements and the option for developers to opt-out of the study. However, they note that developers cannot opt out of potential NSA attacks.A discussion thread raises concerns about potential attempts to introduce vulnerabilities into Bitcoin Core codebase. Some proposals suggest a "Red Team exercise" to test the system's resilience. Others argue for improving the review process instead. The proposed exercise would involve public precommitments collected at ceremonial intervals, with community approval granted for the inserted security flaws.The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes are proposed, including a sortition system. The ideal process involves one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The process includes public precommitments and the use of block hashes as a random oracle.The post proposes a scheme to improve security in Bitcoin development using a sortition system. The scheme involves public precommitments collected at ceremonial intervals, with hash1 being a sortition ticket and hash2 being a public precommitment. The random oracle could be block hashes, and the red-team-concurrency difficulty parameter could control the selection process. The developer would have community approval to opportunistically insert a security flaw.The proposed exercise aims to improve the reputation factor and review attention for new pull requests. It suggests a secret sortition system to encourage more developers to participate without harming their reputation. The scheme includes public precommitments collected at ceremonial intervals and a red-team-concurrency difficulty parameter.The email exchange between Prayank and ZmnSCPxj discusses the importance of review processes in open-source Bitcoin projects. They agree on the necessity of reviews to catch vulnerabilities and caution against using unmerged PRs in production without careful review. Prayank proposes an exercise to test the review process by introducing vulnerability-adding PRs, while ZmnSCPxj emphasizes the need for private handling of any vulnerabilities found.The email discussion highlights the importance of review processes for ensuring security in Bitcoin development. The group agrees that relying on reviews is better for security and discusses the value of testing vulnerabilities in the review process. They propose a plan to create pseudonyms and introduce vulnerability-adding PRs to targets to test the review processes. The plan includes inserting random numbers among the commitments and publicly praising successful reviews.Prayank's proposal to conduct an exercise to study vulnerabilities in Bitcoin projects is met with caution. Ruben Somsen advises getting approval from contributors before proceeding to avoid causing mistrust and extra work for existing contributors. Prayank emphasizes reviewing pull requests based on code rather than author claims and asks whether trusting authors or having a good review process is better for security. They mention several Bitcoin projects they plan to test and note that x00 will assist them in the exercise.Prayank proposes an exercise to study vulnerabilities in Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating new GitHub accounts, studying issues in various Bitcoin projects, preparing pull requests to introduce vulnerabilities, and documenting the results. x00 will assist Prayank in this exercise, which has no fixed completion date.The email thread discusses introducing vulnerabilities in Bitcoin projects and observing how maintainers and reviewers respond. Ruben Somsen advises caution and suggests obtaining approval from contributors beforehand. ZmnSCPxj proposes a method using hash names and randomized salt as precommitments. They also highlight the potential impact on existing contributors and refer to a similar event in the Linux community.Prayank proposes an exercise to introduce vulnerabilities in Bitcoin projects and document the responses of maintainers and reviewers. They plan to create new GitHub accounts, study issues in various Bitcoin projects, and prepare pull requests to introduce vulnerabilities. They mention x00 as someone who will assist them in the exercise.In an email exchange, Prayank proposes an exercise to introduce vulnerabilities in various important Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_Neutrino-Taproot-and-The-Evolution-of-BiPs-157-158.xml b/static/bitcoin-dev/Nov_2021/combined_Neutrino-Taproot-and-The-Evolution-of-BiPs-157-158.xml index 6161c8a99a..eaeb9f0196 100644 --- a/static/bitcoin-dev/Nov_2021/combined_Neutrino-Taproot-and-The-Evolution-of-BiPs-157-158.xml +++ b/static/bitcoin-dev/Nov_2021/combined_Neutrino-Taproot-and-The-Evolution-of-BiPs-157-158.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Neutrino, Taproot, and The Evolution of BiPs 157/158 - 2023-08-02T05:09:16.406560+00:00 - - Olaoluwa Osuntokun 2021-11-04 22:07:52+00:00 - - - Olaoluwa Osuntokun 2021-11-04 22:01:13+00:00 - + 2025-09-26T15:34:12.221949+00:00 + python-feedgen + + + [bitcoin-dev] Neutrino, Taproot, and The Evolution of BiPs 157/158 Olaoluwa Osuntokun + 2021-11-04T22:01:00.000Z + + + Olaoluwa Osuntokun + 2021-11-04T22:07:00.000Z + + - python-feedgen + 2 Combined summary - Neutrino, Taproot, and The Evolution of BiPs 157/158 - 2023-08-02T05:09:16.406560+00:00 + 2025-09-26T15:34:12.222463+00:00 - Last week, there was a problem with the Neutrino nodes on the testnet. This issue was caused by a faulty heuristic in the client code that tried to verify the contents of a filter more thoroughly. However, it is important to note that there is nothing fundamentally wrong with BIP 157/158 in relation to taproot.The good news is that the problematic heuristic has been removed, and it will be included in lnd 0.14. This update has also been tagged with neutrino 0.13. To ensure a smooth transition for neutrino clients during the Taproot upgrade on the mainnet, users have the option to upgrade to version 0.14 or apply a small patch.In addition to addressing the recent issue, progress is being made towards adding more taproot-specific functionality. Some of the items being considered include reviving old projects to incorporate a micropayment-for-data layer, creating new segwit-only filters with re-parameterized fp rates, and developing filters that include witness data for matching on internal/external keys, the control block, merkle root, annex, etc.Furthermore, efforts are being made to introduce a new protocol extension to btcd, along with a corresponding BIP, which would allow nodes to fetch block undo data in order to fully verify fetched filters or reconcile conflicting filters. There is also ongoing work on new filters that span across multiple blocks, as well as progress towards a proposal that allows filters to be committed either as a soft-fork or a "velvet fork," where miners can optionally commit to the past filter header chain.Overall, steps are being taken to address the issues encountered with the Neutrino client code and to enhance taproot-specific functionality. Users can upgrade to the latest version or apply a patch to ensure a smooth transition during the Taproot upgrade on the mainnet. 2021-11-04T22:07:52+00:00 + Last week, there was a problem with the Neutrino nodes on the testnet. This issue was caused by a faulty heuristic in the client code that tried to verify the contents of a filter more thoroughly. However, it is important to note that there is nothing fundamentally wrong with BIP 157/158 in relation to taproot.The good news is that the problematic heuristic has been removed, and it will be included in lnd 0.14. This update has also been tagged with neutrino 0.13. To ensure a smooth transition for neutrino clients during the Taproot upgrade on the mainnet, users have the option to upgrade to version 0.14 or apply a small patch.In addition to addressing the recent issue, progress is being made towards adding more taproot-specific functionality. Some of the items being considered include reviving old projects to incorporate a micropayment-for-data layer, creating new segwit-only filters with re-parameterized fp rates, and developing filters that include witness data for matching on internal/external keys, the control block, merkle root, annex, etc.Furthermore, efforts are being made to introduce a new protocol extension to btcd, along with a corresponding BIP, which would allow nodes to fetch block undo data in order to fully verify fetched filters or reconcile conflicting filters. There is also ongoing work on new filters that span across multiple blocks, as well as progress towards a proposal that allows filters to be committed either as a soft-fork or a "velvet fork," where miners can optionally commit to the past filter header chain.Overall, steps are being taken to address the issues encountered with the Neutrino client code and to enhance taproot-specific functionality. Users can upgrade to the latest version or apply a patch to ensure a smooth transition during the Taproot upgrade on the mainnet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_Taproot-Fields-for-PSBT.xml b/static/bitcoin-dev/Nov_2021/combined_Taproot-Fields-for-PSBT.xml index ee143a8ff1..e788adb7b0 100644 --- a/static/bitcoin-dev/Nov_2021/combined_Taproot-Fields-for-PSBT.xml +++ b/static/bitcoin-dev/Nov_2021/combined_Taproot-Fields-for-PSBT.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Taproot Fields for PSBT - 2023-08-02T04:12:43.924281+00:00 - - Pieter Wuille 2021-11-24 16:08:18+00:00 - - - Greg Sanders 2021-11-24 16:00:42+00:00 - - - Sjors Provoost 2021-11-24 12:44:46+00:00 - - - Jeremy 2021-07-08 20:06:08+00:00 - - - Salvatore Ingala 2021-06-28 19:56:37+00:00 - - - Andrew Chow 2021-06-28 16:04:19+00:00 - - - Salvatore Ingala 2021-06-28 10:03:42+00:00 - - - Andrew Chow 2021-06-22 21:22:28+00:00 - + 2025-09-26T15:34:16.424674+00:00 + python-feedgen + + + [bitcoin-dev] Taproot Fields for PSBT Andrew Chow + 2021-06-22T21:22:00.000Z + + + Salvatore Ingala + 2021-06-28T10:03:00.000Z + + + Andrew Chow + 2021-06-28T16:04:00.000Z + + + Salvatore Ingala + 2021-06-28T19:56:00.000Z + + + Jeremy + 2021-07-08T20:06:00.000Z + + + Sjors Provoost + 2021-11-24T12:44:00.000Z + + + Greg Sanders + 2021-11-24T16:00:00.000Z + + + Pieter Wuille + 2021-11-24T16:08:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Taproot Fields for PSBT - 2023-08-02T04:12:43.924281+00:00 + 2025-09-26T15:34:16.425758+00:00 - In a recent email exchange on the bitcoin-dev mailing list, Sjors Provoost expressed confusion regarding the inclusion of the tapleaf merkle path in the PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION fields. Pieter Wuille responded by explaining that these additional fields are necessary for signers who may not have prior knowledge of the script being signed. The inclusion of the derivation path and tapleaf merkle path allows signers to sign without fully understanding the script or needing to parse it. However, the actual script information is still included for those who wish to analyze or factor it into their decision whether to sign.The confusion arose from Andrew Chow's proposal of a BIP that defines new fields for Taproot support in PSBT. These fields include the Taproot Key BIP32 Derivation Path for both PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION. The fields contain the 32-byte X-only public key, a compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, and then the master key fingerprint concatenated with the derivation path of the public key. These fields provide the necessary information about which keys are present in which leaves and how those keys are derived for signers to sign the transaction.Furthermore, Jeremy Rubin has suggested allowing different keys to specify different sighash flags, which would provide greater flexibility in specifying signature requirements. This would allow for more specific and granular signature requirements, such as chaperone signatures with anyprevout. Currently, the sighashtype key is per-input, and if a sighash type is not provided, the signer should sign using SIGHASH_ALL but may use any sighash type they wish. Rubin has requested this change to be implemented in order to enhance flexibility.Salvatore Ingala thanked Andrew for clarifying that more than one leaf can be added to the Partially Signed Bitcoin Transaction (PSBT). Additionally, Ingala suggested labeling key types that are present multiple times with different keydata in order to assist less experienced readers.Ingala also proposed a change regarding the Taproot Leaf Script as specified in BIP 341. The current control block for this leaf can be up to 4129 bytes long, which is larger than other defined PSBT types. Ingala suggested splitting it into two PSBT types, PSBT_IN_TAP_LEAF_SCRIPT and PSBT_IN_TAP_LEAF_CONTROL_BLOCK, both with no keydata. However, Andrew Chow pointed out that a taproot tree can have multiple leaf scripts and the actual script to be used may not be known at the time of adding them to the PSBT. Therefore, using only two fields with no keydata would not allow for the specification of multiple leaf scripts. Furthermore, the same leaf script can appear multiple times in the tree, so using the leaf hash as keydata would not be sufficient. To enable multiple different leaf scripts and the same leaf script to appear multiple times, the control block itself needs to be used as keydata.The proposal for Taproot support in PSBT introduces several new fields, including Taproot Key Spend Signature, Taproot Script Spend Signature, Taproot Leaf Script, Taproot Key BIP 32 Derivation Path, Taproot Internal Key, and Taproot Merkle Root. These fields are necessary to carry the information required for signing Taproot inputs. The proposal also recommends using PSBT_IN_WITNESS_UTXO for Taproot inputs instead of PSBT_IN_NON_WITNESS_UTXO to prevent potential attacks involving an updater lying about the amounts in an output. The proposal is designed to be compatible with the existing PSBT format, ensuring that old software will ignore the new fields. Test vectors are yet to be determined. 2021-11-24T16:08:18+00:00 + In a recent email exchange on the bitcoin-dev mailing list, Sjors Provoost expressed confusion regarding the inclusion of the tapleaf merkle path in the PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION fields. Pieter Wuille responded by explaining that these additional fields are necessary for signers who may not have prior knowledge of the script being signed. The inclusion of the derivation path and tapleaf merkle path allows signers to sign without fully understanding the script or needing to parse it. However, the actual script information is still included for those who wish to analyze or factor it into their decision whether to sign.The confusion arose from Andrew Chow's proposal of a BIP that defines new fields for Taproot support in PSBT. These fields include the Taproot Key BIP32 Derivation Path for both PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION. The fields contain the 32-byte X-only public key, a compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, and then the master key fingerprint concatenated with the derivation path of the public key. These fields provide the necessary information about which keys are present in which leaves and how those keys are derived for signers to sign the transaction.Furthermore, Jeremy Rubin has suggested allowing different keys to specify different sighash flags, which would provide greater flexibility in specifying signature requirements. This would allow for more specific and granular signature requirements, such as chaperone signatures with anyprevout. Currently, the sighashtype key is per-input, and if a sighash type is not provided, the signer should sign using SIGHASH_ALL but may use any sighash type they wish. Rubin has requested this change to be implemented in order to enhance flexibility.Salvatore Ingala thanked Andrew for clarifying that more than one leaf can be added to the Partially Signed Bitcoin Transaction (PSBT). Additionally, Ingala suggested labeling key types that are present multiple times with different keydata in order to assist less experienced readers.Ingala also proposed a change regarding the Taproot Leaf Script as specified in BIP 341. The current control block for this leaf can be up to 4129 bytes long, which is larger than other defined PSBT types. Ingala suggested splitting it into two PSBT types, PSBT_IN_TAP_LEAF_SCRIPT and PSBT_IN_TAP_LEAF_CONTROL_BLOCK, both with no keydata. However, Andrew Chow pointed out that a taproot tree can have multiple leaf scripts and the actual script to be used may not be known at the time of adding them to the PSBT. Therefore, using only two fields with no keydata would not allow for the specification of multiple leaf scripts. Furthermore, the same leaf script can appear multiple times in the tree, so using the leaf hash as keydata would not be sufficient. To enable multiple different leaf scripts and the same leaf script to appear multiple times, the control block itself needs to be used as keydata.The proposal for Taproot support in PSBT introduces several new fields, including Taproot Key Spend Signature, Taproot Script Spend Signature, Taproot Leaf Script, Taproot Key BIP 32 Derivation Path, Taproot Internal Key, and Taproot Merkle Root. These fields are necessary to carry the information required for signing Taproot inputs. The proposal also recommends using PSBT_IN_WITNESS_UTXO for Taproot inputs instead of PSBT_IN_NON_WITNESS_UTXO to prevent potential attacks involving an updater lying about the amounts in an output. The proposal is designed to be compatible with the existing PSBT format, ensuring that old software will ignore the new fields. Test vectors are yet to be determined. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_Taproot-activates-A-time-block-line.xml b/static/bitcoin-dev/Nov_2021/combined_Taproot-activates-A-time-block-line.xml index 50a40b4c2e..e91722ab9d 100644 --- a/static/bitcoin-dev/Nov_2021/combined_Taproot-activates-A-time-block-line.xml +++ b/static/bitcoin-dev/Nov_2021/combined_Taproot-activates-A-time-block-line.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Taproot activates - A time/block line - 2023-08-02T05:09:34.784787+00:00 - - 0xB10C 2021-11-24 17:29:54+00:00 - - - Michael Folkson 2021-11-15 14:42:44+00:00 - + 2025-09-26T15:34:24.874190+00:00 + python-feedgen + + + [bitcoin-dev] Taproot activates - A time/block line Michael Folkson + 2021-11-15T14:42:00.000Z + + + 0xB10C + 2021-11-24T17:29:00.000Z + + - python-feedgen + 2 Combined summary - Taproot activates - A time/block line - 2023-08-02T05:09:34.784787+00:00 + 2025-09-26T15:34:24.874642+00:00 - The recent activation of Taproot, a significant upgrade to Bitcoin's protocol, has brought to light some issues with Taproot readiness among mining pools. F2Pool and AntPool, the third and fifth largest pools respectively, were slow to upgrade their nodes to include P2TR spends. F2Pool had a custom patch to their node's peer selection behavior that caused them to not be connected to any P2TR-spend-relaying peers. This issue was discovered when an engineer from F2Pool reached out for help debugging. However, F2Pool has since fixed the problem.AntPool also faced issues with P2TR spends but was quick to react once notified. They had already tested version 22.0 and planned to update soon. Alejandro De La Torre, who communicated with AntPool, suggested that the same old peer issue that F2Pool faced could have been the issue for AntPool as well.It is believed that some mining pools signaled readiness without being fully prepared due to community pressure or running nodes with custom patches. To address this, it was suggested to implement a feature that alerts or warns a node operator if their node does not have any peers relaying a particular soft-fork transaction. This could be done through a getnodealerts RPC that a node operator can connect to their monitoring. Additionally, for the next soft-fork where relay is affected, mining pool signaling instructions could state the need to upgrade to a specific version and ensure having a few peers with the same version before signaling readiness.Before the activation of Taproot, there were several key events recorded. 0xB10C and F2Pool spent from Taproot outputs in July, months before Taproot rules were enforced. These spends did not need to meet Taproot consensus rules and are therefore not considered the "first" Taproot spends. The last block before Taproot rules were enforced was mined by AntPool. Non-timelocked P2TR outputs were considered anyone-can-spend as Taproot rules were not yet being enforced. The first block where full nodes started enforcing Taproot rules was mined by F2Pool. However, F2Pool did not enforce Taproot rules or include any Taproot spends in this block, which could have caused a re-org when the block was rejected by full nodes. Similarly, AntPool did not include any Taproot spends in subsequent blocks. The first block with valid Taproot spends was mined by Foundry USA.After the activation of Taproot, several individuals completed Taproot spends, including bitbug42, Andrew Chow, Pieter Wuille, BitGo, jaoNoctus, narcelio, and ottosch. Alekos Filini used modified code from the BDK library to complete the first use of OP_CHECKSIGADD on the mainnet. Various individuals and entities played a significant role in monitoring and highlighting these events online, including 0xB10C, Greg Maxwell, Murch, Daniel McNally, Rearden Code, Chun, and pinheadmz. Additionally, various block explorers proved useful for monitoring Taproot activation. Overall, there was significant interest and scrutiny surrounding this successful upgrade, showcasing a promising future for Bitcoin. 2021-11-24T17:29:54+00:00 + The recent activation of Taproot, a significant upgrade to Bitcoin's protocol, has brought to light some issues with Taproot readiness among mining pools. F2Pool and AntPool, the third and fifth largest pools respectively, were slow to upgrade their nodes to include P2TR spends. F2Pool had a custom patch to their node's peer selection behavior that caused them to not be connected to any P2TR-spend-relaying peers. This issue was discovered when an engineer from F2Pool reached out for help debugging. However, F2Pool has since fixed the problem.AntPool also faced issues with P2TR spends but was quick to react once notified. They had already tested version 22.0 and planned to update soon. Alejandro De La Torre, who communicated with AntPool, suggested that the same old peer issue that F2Pool faced could have been the issue for AntPool as well.It is believed that some mining pools signaled readiness without being fully prepared due to community pressure or running nodes with custom patches. To address this, it was suggested to implement a feature that alerts or warns a node operator if their node does not have any peers relaying a particular soft-fork transaction. This could be done through a getnodealerts RPC that a node operator can connect to their monitoring. Additionally, for the next soft-fork where relay is affected, mining pool signaling instructions could state the need to upgrade to a specific version and ensure having a few peers with the same version before signaling readiness.Before the activation of Taproot, there were several key events recorded. 0xB10C and F2Pool spent from Taproot outputs in July, months before Taproot rules were enforced. These spends did not need to meet Taproot consensus rules and are therefore not considered the "first" Taproot spends. The last block before Taproot rules were enforced was mined by AntPool. Non-timelocked P2TR outputs were considered anyone-can-spend as Taproot rules were not yet being enforced. The first block where full nodes started enforcing Taproot rules was mined by F2Pool. However, F2Pool did not enforce Taproot rules or include any Taproot spends in this block, which could have caused a re-org when the block was rejected by full nodes. Similarly, AntPool did not include any Taproot spends in subsequent blocks. The first block with valid Taproot spends was mined by Foundry USA.After the activation of Taproot, several individuals completed Taproot spends, including bitbug42, Andrew Chow, Pieter Wuille, BitGo, jaoNoctus, narcelio, and ottosch. Alekos Filini used modified code from the BDK library to complete the first use of OP_CHECKSIGADD on the mainnet. Various individuals and entities played a significant role in monitoring and highlighting these events online, including 0xB10C, Greg Maxwell, Murch, Daniel McNally, Rearden Code, Chun, and pinheadmz. Additionally, various block explorers proved useful for monitoring Taproot activation. Overall, there was significant interest and scrutiny surrounding this successful upgrade, showcasing a promising future for Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_Trying-to-patch-Core-ZMQ-rawtx-topic-to-only-publish-unconfirmed-transactions-How-.xml b/static/bitcoin-dev/Nov_2021/combined_Trying-to-patch-Core-ZMQ-rawtx-topic-to-only-publish-unconfirmed-transactions-How-.xml index 49fa05326a..ff2fbcc4da 100644 --- a/static/bitcoin-dev/Nov_2021/combined_Trying-to-patch-Core-ZMQ-rawtx-topic-to-only-publish-unconfirmed-transactions-How-.xml +++ b/static/bitcoin-dev/Nov_2021/combined_Trying-to-patch-Core-ZMQ-rawtx-topic-to-only-publish-unconfirmed-transactions-How-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How? - 2023-08-02T05:10:04.251556+00:00 + Combined summary - Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How? + 2025-09-26T15:34:26.988620+00:00 + python-feedgen Ali Sherief 2021-11-29 14:13:37+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 - Combined summary - Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How? - 2023-08-02T05:10:04.251556+00:00 + Combined summary - Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How? + 2025-09-26T15:34:26.988796+00:00 - In an email thread on the bitcoin-dev mailing list, a discussion is being held regarding an issue with the ZeroMQ topic "rawtx." This topic emits a raw transaction when it appears on the mempool, but it also emits the same transaction once it has been confirmed. This causes problems with software that de-duplicates arrays, as the same transaction is received twice. The proposed solution is to configure Core to only publish unconfirmed transactions. However, this cannot be done through configuration or command-line options and requires editing the source code directly.A draft pull request has been opened by 0xB10C to add a rawmempooltx publisher. This PR includes a new function called NotifyMempoolTransaction() in zmq/zmqnotificationinterface.cpp, which notifies the CZMQNotificationInterface about TransactionAddedToMempool. The function calls the publisher with the rawmempooltx topic. The author of the PR mentions that a mempool transaction publisher with both the raw transaction and transaction fee would also be useful, but changes to the chain notifications in interfaces/chain.h would be necessary for this.Meanwhile, on the Bitcointalk forum, a user named Ali Sherief reports experiencing the issue with the "rawtx" topic emitting confirmed transactions. Ali attempts to instruct Core to only publish unconfirmed transactions but discovers that it requires editing the source code directly. They are uncertain which function in src/zmq/zmqnotificationinterface.cpp needs to be patched for their own build. They mention two possibilities: CZMQNotificationInterface::TransactionRemovedFromMempool or void CZMQNotificationInterface::BlockDisconnected, both of which call the NotifyTransaction() method that fires a message on the "rawtx" channel.The author refers to Jonas Schnelli's suggestion from several years ago to add an `if (!pblock)` check. However, they note that the function he was referencing no longer exists and are unsure if the pblock check is still applicable in the present day to determine the block a transaction is inside.To resolve the issue, Prayank suggests a solution to Ali. The solution involves saving zmqpubsequence=tcp://127.0.0.1:28332 in the bitcoin.conf file, running bitcoind, and executing a Python script provided at https://pastebin.com/raw/tNp2x5y3. Prayank shares screenshots of the script execution, showing the status of accepted, connected (block), and removal transactions. Prayank recommends modifying the script to handle transaction duplication since transactions could be printed twice. Alternatively, they suggest using debug=mempool and reading debug.log for changes without polling.Overall, the discussion revolves around the issue with the ZeroMQ topic "rawtx" emitting confirmed transactions and the need to patch the source code to only publish unconfirmed transactions. Suggestions have been made through a pull request and on the Bitcointalk forum, but the exact function to be patched and the applicability of Jonas Schnelli's suggestion are still under consideration. Additionally, Prayank offers a solution involving configuration changes and a Python script to manage transaction duplication. 2021-11-29T14:13:37+00:00 + In an email thread on the bitcoin-dev mailing list, a discussion is being held regarding an issue with the ZeroMQ topic "rawtx." This topic emits a raw transaction when it appears on the mempool, but it also emits the same transaction once it has been confirmed. This causes problems with software that de-duplicates arrays, as the same transaction is received twice. The proposed solution is to configure Core to only publish unconfirmed transactions. However, this cannot be done through configuration or command-line options and requires editing the source code directly.A draft pull request has been opened by 0xB10C to add a rawmempooltx publisher. This PR includes a new function called NotifyMempoolTransaction() in zmq/zmqnotificationinterface.cpp, which notifies the CZMQNotificationInterface about TransactionAddedToMempool. The function calls the publisher with the rawmempooltx topic. The author of the PR mentions that a mempool transaction publisher with both the raw transaction and transaction fee would also be useful, but changes to the chain notifications in interfaces/chain.h would be necessary for this.Meanwhile, on the Bitcointalk forum, a user named Ali Sherief reports experiencing the issue with the "rawtx" topic emitting confirmed transactions. Ali attempts to instruct Core to only publish unconfirmed transactions but discovers that it requires editing the source code directly. They are uncertain which function in src/zmq/zmqnotificationinterface.cpp needs to be patched for their own build. They mention two possibilities: CZMQNotificationInterface::TransactionRemovedFromMempool or void CZMQNotificationInterface::BlockDisconnected, both of which call the NotifyTransaction() method that fires a message on the "rawtx" channel.The author refers to Jonas Schnelli's suggestion from several years ago to add an `if (!pblock)` check. However, they note that the function he was referencing no longer exists and are unsure if the pblock check is still applicable in the present day to determine the block a transaction is inside.To resolve the issue, Prayank suggests a solution to Ali. The solution involves saving zmqpubsequence=tcp://127.0.0.1:28332 in the bitcoin.conf file, running bitcoind, and executing a Python script provided at https://pastebin.com/raw/tNp2x5y3. Prayank shares screenshots of the script execution, showing the status of accepted, connected (block), and removal transactions. Prayank recommends modifying the script to handle transaction duplication since transactions could be printed twice. Alternatively, they suggest using debug=mempool and reading debug.log for changes without polling.Overall, the discussion revolves around the issue with the ZeroMQ topic "rawtx" emitting confirmed transactions and the need to patch the source code to only publish unconfirmed transactions. Suggestions have been made through a pull request and on the Bitcointalk forum, but the exact function to be patched and the applicability of Jonas Schnelli's suggestion are still under consideration. Additionally, Prayank offers a solution involving configuration changes and a Python script to manage transaction duplication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_bitcoin-org-missing-bitcoin-core-version-22-0.xml b/static/bitcoin-dev/Nov_2021/combined_bitcoin-org-missing-bitcoin-core-version-22-0.xml index 1f15d082ea..3cb4eacc9d 100644 --- a/static/bitcoin-dev/Nov_2021/combined_bitcoin-org-missing-bitcoin-core-version-22-0.xml +++ b/static/bitcoin-dev/Nov_2021/combined_bitcoin-org-missing-bitcoin-core-version-22-0.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - bitcoin.org missing bitcoin core version 22.0 - 2023-08-02T05:06:42.579979+00:00 - - Prayank 2021-11-09 12:49:14+00:00 - - - ZmnSCPxj 2021-11-08 03:02:33+00:00 - - - yanmaani at cock.li 2021-11-05 14:45:36+00:00 - - - damian at willtech.com.au 2021-11-05 10:52:00+00:00 - - - Prayank 2021-11-05 08:17:22+00:00 - - - Andrew Chow 2021-10-20 21:50:13+00:00 - - - Kate Salazar 2021-10-20 20:18:03+00:00 - - - Owen Gunden 2021-10-20 19:49:19+00:00 - - - Charles Hill 2021-10-20 19:43:27+00:00 - - - Pieter Wuille 2021-10-20 19:37:48+00:00 - - - Owen Gunden 2021-10-20 19:20:54+00:00 - - - Prayank 2021-10-20 14:47:17+00:00 - - - Owen Gunden 2021-10-20 12:54:36+00:00 - + 2025-09-26T15:34:10.132260+00:00 + python-feedgen + + + [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0 Owen Gunden + 2021-10-20T12:54:00.000Z + + + Prayank + 2021-10-20T14:47:00.000Z + + + Owen Gunden + 2021-10-20T19:20:00.000Z + + + Pieter Wuille + 2021-10-20T19:37:00.000Z + + + Charles Hill + 2021-10-20T19:43:00.000Z + + + Owen Gunden + 2021-10-20T19:49:00.000Z + + + Kate Salazar + 2021-10-20T20:18:00.000Z + + + Andrew Chow + 2021-10-20T21:50:00.000Z + + + Prayank + 2021-11-05T08:17:00.000Z + + + damian + 2021-11-05T10:52:00.000Z + + + yanmaani + 2021-11-05T14:45:00.000Z + + + ZmnSCPxj + 2021-11-08T03:02:00.000Z + + + Prayank + 2021-11-09T12:49:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - bitcoin.org missing bitcoin core version 22.0 - 2023-08-02T05:06:42.579979+00:00 + 2025-09-26T15:34:10.133765+00:00 - In a recent conversation between Prayank and Yanmaani, the focus was on decentralization in Bitcoin full node implementations. Prayank proposed that increasing the usage of alternative full node implementations could enhance decentralization. However, Yanmaani pointed out the potential risk of consensus splits. They explored other ways to improve decentralization, including having independent contributors like Luke Dashjr and Amir Taaki, involving individuals from different countries in important roles, and funding alternative full node implementations such as Bitcoin Knots.Yanmaani raised concerns about the issue of money, stating that contributors may have less independence if their source of income is not independent. To address this, they suggested implementing a system similar to Monero's CCS or a fund controlled in a civilized and non-centralized manner to protect developers from threats to their funding. Both parties agreed that funding is a challenging problem to solve in Bitcoin due to its public good nature.The discussion also touched upon the importance of having more people from different countries taking up significant roles in Bitcoin. However, there were concerns about funding individuals from under-represented countries and the potential vulnerability of anonymous individuals funded by non-robust sources. Despite these challenges, it was emphasized that encouraging more individuals to contribute to Bitcoin's success is beneficial. The alternative scenario of smart individuals from disadvantaged backgrounds attacking Bitcoin to escape their circumstances was also highlighted.In another discussion on the bitcoin-dev mailing list, Prayank suggested that true decentralization in full node implementations goes beyond sharing the Bitcoin whitepaper. One solution proposed was to increase the usage of alternative full node implementations since the majority currently use Bitcoin Core. However, the risk of consensus splits and the inability to run personal forks in case of subversion via soft-fork hindered this suggestion. Prayank also recommended having independent contributors and maintainers like Luke Dashjr and Amir Taaki, who are not influenced by funding sources. However, the need for funding to support contributors' work posed a challenge.The involvement of individuals from different countries in important roles was also discussed. While it was initially suggested as a way to improve decentralization, concerns were raised about funding individuals in under-represented countries and the potential vulnerability to attacks on their funding. It was argued that contributors who are financially secure may be better suited for important roles. The idea of having more anonymous contributors was also explored but deemed difficult due to financial limitations and the limited benefits gained from non-robust funding sources.Furthermore, it was recommended that individuals and organizations funding Bitcoin projects should consider contributing to alternative full node implementations. However, the lack of true independence in most alternative implementations, as they need to be bug-for-bug compatible with Bitcoin Core, presented a challenge. The suggestion was made for the creation of a fund where donations could be made to support developers. This fund would be controlled in a civilized and non-centralized manner, providing some insulation for developers against threats to their contributions.The author of an email argued against the notion that decentralization alone is responsible for a project's success. They stated that multiple software implementation choices only hold value if there is an attack on fungibility or consensus. The author recommended using Bitcoin Core version 21 and creating a fork if such an attack occurs. They emphasized the importance of establishing a properly delegated organization for maintaining Bitcoin's consensus and decentralized currency. The author also mentioned the Commonwealth Bank of Australia's inclusion of buying and selling Bitcoin as one of its services, highlighting the significance of defending the existing consensus.In another email exchange, Prayank shared their perspective on improving Bitcoin's decentralization. They advocated for increased usage of alternative full node implementations like Bitcoin Knots to reduce reliance on Bitcoin Core, which currently dominates the landscape. Prayank stressed the importance of having maintainers who are independent and not influenced by any particular entity. They also expressed the need for individuals from different countries to play significant roles in Bitcoin. Additionally, Prayank suggested that organizations funding Bitcoin projects should consider supporting alternative full node implementations. They referred to a Medium post that emphasized the importance of acknowledging and addressing problems to drive improvement in engineering.The email exchange also mentioned the impending activation of Taproot, with only a limited number of blocks remaining. This milestone was seen as another success for Bitcoin's ongoing development. In response to a question about the new website and GPG signers, Prayank supported Wladimir's decision to stop signing releases, considering it a sensible move to decrease reliance on a single individual. They shared a link to a blog post by Wladimir discussing decentralization. The exchange concluded with a reminder to verify tree hashes and trust signed annotated tags when building releases.In an email thread on the Bitcoin-dev mailing list, developer Owen Gunden expressed concern regarding recent changes to the Bitcoin Core project's website and release signing process. Specifically, Gunden noted that Wladimir van der Laan, the lead maintainer of Bitcoin Core, had stopped signing releases as of version 22.0. However, other 2021-11-09T12:49:14+00:00 + In a recent conversation between Prayank and Yanmaani, the focus was on decentralization in Bitcoin full node implementations. Prayank proposed that increasing the usage of alternative full node implementations could enhance decentralization. However, Yanmaani pointed out the potential risk of consensus splits. They explored other ways to improve decentralization, including having independent contributors like Luke Dashjr and Amir Taaki, involving individuals from different countries in important roles, and funding alternative full node implementations such as Bitcoin Knots.Yanmaani raised concerns about the issue of money, stating that contributors may have less independence if their source of income is not independent. To address this, they suggested implementing a system similar to Monero's CCS or a fund controlled in a civilized and non-centralized manner to protect developers from threats to their funding. Both parties agreed that funding is a challenging problem to solve in Bitcoin due to its public good nature.The discussion also touched upon the importance of having more people from different countries taking up significant roles in Bitcoin. However, there were concerns about funding individuals from under-represented countries and the potential vulnerability of anonymous individuals funded by non-robust sources. Despite these challenges, it was emphasized that encouraging more individuals to contribute to Bitcoin's success is beneficial. The alternative scenario of smart individuals from disadvantaged backgrounds attacking Bitcoin to escape their circumstances was also highlighted.In another discussion on the bitcoin-dev mailing list, Prayank suggested that true decentralization in full node implementations goes beyond sharing the Bitcoin whitepaper. One solution proposed was to increase the usage of alternative full node implementations since the majority currently use Bitcoin Core. However, the risk of consensus splits and the inability to run personal forks in case of subversion via soft-fork hindered this suggestion. Prayank also recommended having independent contributors and maintainers like Luke Dashjr and Amir Taaki, who are not influenced by funding sources. However, the need for funding to support contributors' work posed a challenge.The involvement of individuals from different countries in important roles was also discussed. While it was initially suggested as a way to improve decentralization, concerns were raised about funding individuals in under-represented countries and the potential vulnerability to attacks on their funding. It was argued that contributors who are financially secure may be better suited for important roles. The idea of having more anonymous contributors was also explored but deemed difficult due to financial limitations and the limited benefits gained from non-robust funding sources.Furthermore, it was recommended that individuals and organizations funding Bitcoin projects should consider contributing to alternative full node implementations. However, the lack of true independence in most alternative implementations, as they need to be bug-for-bug compatible with Bitcoin Core, presented a challenge. The suggestion was made for the creation of a fund where donations could be made to support developers. This fund would be controlled in a civilized and non-centralized manner, providing some insulation for developers against threats to their contributions.The author of an email argued against the notion that decentralization alone is responsible for a project's success. They stated that multiple software implementation choices only hold value if there is an attack on fungibility or consensus. The author recommended using Bitcoin Core version 21 and creating a fork if such an attack occurs. They emphasized the importance of establishing a properly delegated organization for maintaining Bitcoin's consensus and decentralized currency. The author also mentioned the Commonwealth Bank of Australia's inclusion of buying and selling Bitcoin as one of its services, highlighting the significance of defending the existing consensus.In another email exchange, Prayank shared their perspective on improving Bitcoin's decentralization. They advocated for increased usage of alternative full node implementations like Bitcoin Knots to reduce reliance on Bitcoin Core, which currently dominates the landscape. Prayank stressed the importance of having maintainers who are independent and not influenced by any particular entity. They also expressed the need for individuals from different countries to play significant roles in Bitcoin. Additionally, Prayank suggested that organizations funding Bitcoin projects should consider supporting alternative full node implementations. They referred to a Medium post that emphasized the importance of acknowledging and addressing problems to drive improvement in engineering.The email exchange also mentioned the impending activation of Taproot, with only a limited number of blocks remaining. This milestone was seen as another success for Bitcoin's ongoing development. In response to a question about the new website and GPG signers, Prayank supported Wladimir's decision to stop signing releases, considering it a sensible move to decrease reliance on a single individual. They shared a link to a blog post by Wladimir discussing decentralization. The exchange concluded with a reminder to verify tree hashes and trust signed annotated tags when building releases.In an email thread on the Bitcoin-dev mailing list, developer Owen Gunden expressed concern regarding recent changes to the Bitcoin Core project's website and release signing process. Specifically, Gunden noted that Wladimir van der Laan, the lead maintainer of Bitcoin Core, had stopped signing releases as of version 22.0. However, other - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_bitcoinj-fork-with-Taproot-support.xml b/static/bitcoin-dev/Nov_2021/combined_bitcoinj-fork-with-Taproot-support.xml index e410e7e71b..bf58e8960a 100644 --- a/static/bitcoin-dev/Nov_2021/combined_bitcoinj-fork-with-Taproot-support.xml +++ b/static/bitcoin-dev/Nov_2021/combined_bitcoinj-fork-with-Taproot-support.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoinj fork with Taproot support - 2023-08-02T05:09:46.483793+00:00 + 2025-09-26T15:34:14.332284+00:00 + python-feedgen n1ms0s 2021-11-17 20:05:55+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - bitcoinj fork with Taproot support - 2023-08-02T05:09:46.483793+00:00 + 2025-09-26T15:34:14.332416+00:00 - On the Bitcoin development mailing list, a discussion took place regarding the relaying of P2TR spends. Prior to version 0.19.0, creating outputs with an unknown witness version was considered non-standard and violated BIP 173. However, this issue was resolved in PR #15846 for version 0.19.0+. Despite the fix, post-segwit pre-taproot Bitcoin Core releases still reject P2TR spends. A user on the Bitcoin StackExchange forum suggested a potential solution using bitcoinj. They made it so that the client only connects to nodes with at least protocol version 70016, which successfully addressed the issue. In another discussion led by Andrew Chow on November 17th, 2021, it was mentioned that creating outputs with an unknown witness version was previously deemed non-standard and violated BIP 173. The problem at hand, however, pertains to getting P2TR spends to relay. All post-segwit pre-taproot Bitcoin Core releases currently reject these spends. A developer named n1ms0s recently shared their work on a fork of bitcoinj that includes basic Taproot support. This fork allows for sending and receiving with Taproot addresses using a bitcoinj SPV wallet, as well as public/private key tweaking. However, when attempting to broadcast a Taproot transaction to older nodes (around version 0.18.0), an error response stating "Witness version reserved for soft-fork upgrades" is encountered. Seeking assistance, the developer posted a question on Stack Exchange, inviting feedback and contributions to address this issue.Overall, the discussions highlight the challenges surrounding P2TR spends and the rejection of such spends by post-segwit pre-taproot Bitcoin Core releases. Additionally, they shed light on the efforts of a developer working on a bitcoinj fork with basic Taproot support, who seeks assistance in resolving the issue encountered when broadcasting Taproot transactions to older nodes. 2021-11-17T20:05:55+00:00 + On the Bitcoin development mailing list, a discussion took place regarding the relaying of P2TR spends. Prior to version 0.19.0, creating outputs with an unknown witness version was considered non-standard and violated BIP 173. However, this issue was resolved in PR #15846 for version 0.19.0+. Despite the fix, post-segwit pre-taproot Bitcoin Core releases still reject P2TR spends. A user on the Bitcoin StackExchange forum suggested a potential solution using bitcoinj. They made it so that the client only connects to nodes with at least protocol version 70016, which successfully addressed the issue. In another discussion led by Andrew Chow on November 17th, 2021, it was mentioned that creating outputs with an unknown witness version was previously deemed non-standard and violated BIP 173. The problem at hand, however, pertains to getting P2TR spends to relay. All post-segwit pre-taproot Bitcoin Core releases currently reject these spends. A developer named n1ms0s recently shared their work on a fork of bitcoinj that includes basic Taproot support. This fork allows for sending and receiving with Taproot addresses using a bitcoinj SPV wallet, as well as public/private key tweaking. However, when attempting to broadcast a Taproot transaction to older nodes (around version 0.18.0), an error response stating "Witness version reserved for soft-fork upgrades" is encountered. Seeking assistance, the developer posted a question on Stack Exchange, inviting feedback and contributions to address this issue.Overall, the discussions highlight the challenges surrounding P2TR spends and the rejection of such spends by post-segwit pre-taproot Bitcoin Core releases. Additionally, they shed light on the efforts of a developer working on a bitcoinj fork with basic Taproot support, who seeks assistance in resolving the issue encountered when broadcasting Taproot transactions to older nodes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2021/combined_death-to-the-mempool-long-live-the-mempool.xml b/static/bitcoin-dev/Nov_2021/combined_death-to-the-mempool-long-live-the-mempool.xml index c04099531f..5c374bf51b 100644 --- a/static/bitcoin-dev/Nov_2021/combined_death-to-the-mempool-long-live-the-mempool.xml +++ b/static/bitcoin-dev/Nov_2021/combined_death-to-the-mempool-long-live-the-mempool.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - death to the mempool, long live the mempool - 2023-08-02T05:08:02.506243+00:00 - - ZmnSCPxj 2021-11-03 10:12:57+00:00 - - - ZmnSCPxj 2021-10-28 01:04:10+00:00 - - - yanmaani at cock.li 2021-10-27 23:05:59+00:00 - - - Peter Todd 2021-10-27 20:01:51+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-27 08:44:42+00:00 - - - Antoine Riard 2021-10-26 23:44:45+00:00 - - - Gloria Zhao 2021-10-26 18:16:51+00:00 - - - ZmnSCPxj 2021-10-26 16:38:27+00:00 - - - Pieter Wuille 2021-10-26 16:26:43+00:00 - - - darosior 2021-10-26 14:09:28+00:00 - - - ZmnSCPxj 2021-10-26 08:56:10+00:00 - - - eric at voskuil.org 2021-10-26 08:31:18+00:00 - - - ZmnSCPxj 2021-10-26 08:02:24+00:00 - - - lisa neigut 2021-10-26 02:56:21+00:00 - + 2025-09-26T15:34:20.668543+00:00 + python-feedgen + + + [bitcoin-dev] death to the mempool, long live the mempool lisa neigut + 2021-10-26T02:56:00.000Z + + + ZmnSCPxj + 2021-10-26T08:02:00.000Z + + + eric + 2021-10-26T08:31:00.000Z + + + ZmnSCPxj + 2021-10-26T08:56:00.000Z + + + darosior + 2021-10-26T14:09:00.000Z + + + Pieter Wuille + 2021-10-26T16:26:00.000Z + + + ZmnSCPxj + 2021-10-26T16:38:00.000Z + + + Gloria Zhao + 2021-10-26T18:16:00.000Z + + + Antoine Riard + 2021-10-26T23:44:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-27T08:44:00.000Z + + + Peter Todd + 2021-10-27T20:01:00.000Z + + + yanmaani + 2021-10-27T23:05:00.000Z + + + ZmnSCPxj + 2021-10-28T01:04:00.000Z + + + ZmnSCPxj + 2021-11-03T10:12:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - death to the mempool, long live the mempool - 2023-08-02T05:08:02.506243+00:00 + 2025-09-26T15:34:20.669983+00:00 - In recent discussions on the bitcoin-dev mailing list, there has been a proposal to eliminate the mempool and instead have users submit their transactions directly to mining pools. This idea has sparked debate among developers and experts in the Bitcoin community.One argument in favor of removing the mempool is that it would greatly reduce the bandwidth requirement for running a node and keep transaction intentionality private until confirmed. It is suggested that this would naturally resolve current issues related to package relay and replace-by-fee (RBF) rules. However, critics argue that removing the mempool would complicate solo mining and make BetterHash proposals more difficult. They also point out that it deviates from the security model of Bitcoin and exposes the network to potential denial-of-service (DoS) attacks.Another concern raised is the potential for centralization and higher barriers to entry if users are required to submit transactions directly to mining pools. Proponents of the proposal suggest that direct communication between block template construction venues and transaction proposers could provide a venue for direct feedback on acceptable feerates, making transaction confirmation timelines less variable and allowing block producers to enforce their own minimum security budget. Critics argue that this information can already be communicated over HTTP and that removing the mempool would only reinvent its purpose.The discussion also touches on the issue of dynamic, trust-minimized discovery of mining endpoints. There is a concern that a static list of endpoints could create artificial barriers to entry and lead to centralization. One defense mechanism currently used in Bitcoin Core is selecting outbound peers based on different subnets, but replicating this mechanism for mining endpoints could downgrade the mining competition. The consensus seems to be that while opting out of transaction broadcasting is acceptable, the mempool will always be necessary to maintain a decentralized and trust-minimized system.In addition to the proposal to eliminate the mempool, there are other suggestions being discussed. These include using an anonymous communication network such as Tor for submitting transactions directly to mining pools, implementing an overlay network to relay miner-incentive compatible transactions, and finding alternative solutions such as weak blocks to address the concerns related to the mempool.Overall, the discussions highlight the importance of maintaining a decentralized and trust-minimized system in Bitcoin while avoiding artificial barriers to entry and centralization vectors. The proposal to eliminate the mempool has sparked debate, with arguments for and against its removal based on various considerations such as bandwidth requirements, transaction intentionality, solo mining, BetterHash proposals, security budgets, and DoS attacks.The current design of Bitcoin's transaction pool is being discussed by Lisa and ZmnSCPxj. ZmnSCPxj suggests using gossiping mining endpoints instead of transactions to improve anonymity and reduce global bandwidth usage. However, this method may be more expensive than having a persistent identity. Anonymity in transactions is considered important, but there are potential limitations in contacting all miners globally to confirm transactions.The Bitcoin Protocol Discussion mailing list has been discussing the possibility of eliminating the mempool, which stores unconfirmed transactions. Instead, it has been proposed that users should submit their transactions directly to mining pools through an anonymous communication network like Tor. This would reduce the bandwidth requirement for running a node and keep the intentionality of transactions private until confirmed. However, it would complicate solo mining and make BetterHash proposals more difficult. It would also require miners to identify themselves, potentially compromising anonymity.Eliminating the mempool would greatly reduce the bandwidth requirement for running a node and resolve issues with package relay and RBF rules. However, it would complicate solo mining and make BetterHash proposals harder to implement. The mining set should ideally be anonymous to prevent state co-option of mines and attacks with sufficient hashpower. The objection to this proposal is that it requires miners to identify themselves, although many miners already do so. P2Pool would not work well in this model, and non-side fees serve as an anonymity layer, where neither the miner nor the transactor needs to know each other's identity.Removing the mempool and allowing users to submit transactions directly to mining pools over an anonymous communication network like Tor would greatly reduce the bandwidth requirement for running a node and maintain the privacy of transactions until they are confirmed. However, it would complicate solo mining and make BetterHash proposals more challenging. A direct communication channel between block template construction venues and transaction proposers would allow for direct feedback on acceptable feerates, making transaction confirmation timelines less variable and providing block producers with a mechanism to enforce their own minimum security budget. Initial feerate estimation would need to be based on published blocks or direct interactions with block producers.In summary, there are ongoing discussions about eliminating the mempool and having users submit transactions directly to mining pools over an anonymous communication network like Tor. While this would reduce bandwidth requirements and maintain transaction privacy, it could complicate solo mining and make BetterHash proposals more difficult. The importance of anonymity in transactions and the need for miners to look like potential miners on the network for improved security are also emphasized. However 2021-11-03T10:12:57+00:00 + In recent discussions on the bitcoin-dev mailing list, there has been a proposal to eliminate the mempool and instead have users submit their transactions directly to mining pools. This idea has sparked debate among developers and experts in the Bitcoin community.One argument in favor of removing the mempool is that it would greatly reduce the bandwidth requirement for running a node and keep transaction intentionality private until confirmed. It is suggested that this would naturally resolve current issues related to package relay and replace-by-fee (RBF) rules. However, critics argue that removing the mempool would complicate solo mining and make BetterHash proposals more difficult. They also point out that it deviates from the security model of Bitcoin and exposes the network to potential denial-of-service (DoS) attacks.Another concern raised is the potential for centralization and higher barriers to entry if users are required to submit transactions directly to mining pools. Proponents of the proposal suggest that direct communication between block template construction venues and transaction proposers could provide a venue for direct feedback on acceptable feerates, making transaction confirmation timelines less variable and allowing block producers to enforce their own minimum security budget. Critics argue that this information can already be communicated over HTTP and that removing the mempool would only reinvent its purpose.The discussion also touches on the issue of dynamic, trust-minimized discovery of mining endpoints. There is a concern that a static list of endpoints could create artificial barriers to entry and lead to centralization. One defense mechanism currently used in Bitcoin Core is selecting outbound peers based on different subnets, but replicating this mechanism for mining endpoints could downgrade the mining competition. The consensus seems to be that while opting out of transaction broadcasting is acceptable, the mempool will always be necessary to maintain a decentralized and trust-minimized system.In addition to the proposal to eliminate the mempool, there are other suggestions being discussed. These include using an anonymous communication network such as Tor for submitting transactions directly to mining pools, implementing an overlay network to relay miner-incentive compatible transactions, and finding alternative solutions such as weak blocks to address the concerns related to the mempool.Overall, the discussions highlight the importance of maintaining a decentralized and trust-minimized system in Bitcoin while avoiding artificial barriers to entry and centralization vectors. The proposal to eliminate the mempool has sparked debate, with arguments for and against its removal based on various considerations such as bandwidth requirements, transaction intentionality, solo mining, BetterHash proposals, security budgets, and DoS attacks.The current design of Bitcoin's transaction pool is being discussed by Lisa and ZmnSCPxj. ZmnSCPxj suggests using gossiping mining endpoints instead of transactions to improve anonymity and reduce global bandwidth usage. However, this method may be more expensive than having a persistent identity. Anonymity in transactions is considered important, but there are potential limitations in contacting all miners globally to confirm transactions.The Bitcoin Protocol Discussion mailing list has been discussing the possibility of eliminating the mempool, which stores unconfirmed transactions. Instead, it has been proposed that users should submit their transactions directly to mining pools through an anonymous communication network like Tor. This would reduce the bandwidth requirement for running a node and keep the intentionality of transactions private until confirmed. However, it would complicate solo mining and make BetterHash proposals more difficult. It would also require miners to identify themselves, potentially compromising anonymity.Eliminating the mempool would greatly reduce the bandwidth requirement for running a node and resolve issues with package relay and RBF rules. However, it would complicate solo mining and make BetterHash proposals harder to implement. The mining set should ideally be anonymous to prevent state co-option of mines and attacks with sufficient hashpower. The objection to this proposal is that it requires miners to identify themselves, although many miners already do so. P2Pool would not work well in this model, and non-side fees serve as an anonymity layer, where neither the miner nor the transactor needs to know each other's identity.Removing the mempool and allowing users to submit transactions directly to mining pools over an anonymous communication network like Tor would greatly reduce the bandwidth requirement for running a node and maintain the privacy of transactions until they are confirmed. However, it would complicate solo mining and make BetterHash proposals more challenging. A direct communication channel between block template construction venues and transaction proposers would allow for direct feedback on acceptable feerates, making transaction confirmation timelines less variable and providing block producers with a mechanism to enforce their own minimum security budget. Initial feerate estimation would need to be based on published blocks or direct interactions with block producers.In summary, there are ongoing discussions about eliminating the mempool and having users submit transactions directly to mining pools over an anonymous communication network like Tor. While this would reduce bandwidth requirements and maintain transaction privacy, it could complicate solo mining and make BetterHash proposals more difficult. The importance of anonymity in transactions and the need for miners to look like potential miners on the network for improved security are also emphasized. However - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index f728bcc7dc..01bd473059 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -2,7 +2,7 @@ 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:29:27.286630+00:00 + 2025-09-26T15:44:02.165244+00:00 python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -81,10 +81,11 @@ + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:29:27.286802+00:00 + 2025-09-26T15:44:02.165439+00:00 2023-03-13T16:38:25+00:00 On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to diff --git a/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml b/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml index c91762aee4..36292c4d9f 100644 --- a/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml +++ b/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml @@ -2,7 +2,7 @@ 2 Combined summary - On mempool policy consistency - 2025-09-26T14:29:22.950536+00:00 + 2025-09-26T15:44:00.048645+00:00 python-feedgen email at yancy.lol 2022-11-10 14:38:27+00:00 @@ -137,10 +137,11 @@ + 2 Combined summary - On mempool policy consistency - 2025-09-26T14:29:22.950737+00:00 + 2025-09-26T15:44:00.048830+00:00 2022-11-10T14:38:27+00:00 The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases. The discussion also touched upon diff --git a/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml b/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml index 928b95fbb4..12b1870801 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml @@ -2,7 +2,7 @@ 2 Combined summary - Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime - 2025-09-26T14:29:40.120226+00:00 + 2025-09-26T15:44:04.307168+00:00 python-feedgen David A. Harding 2022-11-11 03:00:58+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime - 2025-09-26T14:29:40.120366+00:00 + 2025-09-26T15:44:04.307321+00:00 2022-11-11T03:00:58+00:00 In a recent email thread on the bitcoin-dev mailing list, Peter Todd proposed a solution to address Rule #3 pinning in multi-party transactions. The attack involves one party broadcasting a low fee transaction that ties up funds from other parties, making it difficult for them to spend their inputs unless they pay for the malicious party's transaction. Todd's solution involves pre-signing transactions with nLockTime set far into the future and spending one or more inputs of the transaction with a high enough fee to replace any attempts to exploit the rule.However, there are several open questions and challenges associated with this solution. One issue is determining the high fee needed to guarantee replacements with high odds. Since the sat/vb (satoshi per virtual byte) is unknown at the time of signature exchange among participants, overshooting and adopting a historical worst-case mempool feerate may be necessary. This introduces economic lower bounds on the funds involved in a contract, creating a griefing vector where a participant could deliberately pin to inflict asymmetric damage without entering into any fee competition.To address these challenges, participants may consider unilaterally spending after a protocol/implementation timepoint to save the time value of their contributed UTXOs over operation success. Additionally, a proposed more workable solution is to rely on package-relay, an ephemeral anchor output, and a special replacement regime (e.g., nVersion=3). This would allow the multi-party funded transaction coordinator to unilateral fee-bump, step-by-step, without relying on assumptions about the knowledge of network mempools and burning excessive fees.The email exchange between Antoine and Peter Todd also highlights the issue of incentive compatibility when considering miner harvesting attacks as part of the threat model. It remains unclear if the v3 rules that depend on miners arbitrarily rejecting transactions from their mempools are sufficiently incentive compatible to work effectively.Overall, the Bitcoin community is actively discussing ways to prevent pinning attacks on multi-party transactions. Implementing pre-signed transactions with nLockTime set in the future and utilizing a combination of package-relay, an ephemeral anchor output, and a special replacement regime could potentially address this issue. However, there are still challenges to be addressed, such as determining the appropriate fee and ensuring incentive compatibility in the face of potential miner harvesting attacks. diff --git a/static/bitcoin-dev/Oct_2016/combined_-no-subject-.xml b/static/bitcoin-dev/Oct_2016/combined_-no-subject-.xml index a09c8867b3..8dc8d2661d 100644 --- a/static/bitcoin-dev/Oct_2016/combined_-no-subject-.xml +++ b/static/bitcoin-dev/Oct_2016/combined_-no-subject-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - (no subject) - 2023-08-01T05:01:33.099019+00:00 + 2025-09-26T16:01:41.821712+00:00 + python-feedgen Btc Drak 2016-10-17 13:13:25+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - (no subject) - 2023-08-01T05:01:33.099019+00:00 + 2025-09-26T16:01:41.821881+00:00 - On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. 2016-10-17T13:13:25+00:00 + On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_1-Year-bitcoin-dev-Moderation-Review.xml b/static/bitcoin-dev/Oct_2016/combined_1-Year-bitcoin-dev-Moderation-Review.xml index 64c74989f2..4380e67c2f 100644 --- a/static/bitcoin-dev/Oct_2016/combined_1-Year-bitcoin-dev-Moderation-Review.xml +++ b/static/bitcoin-dev/Oct_2016/combined_1-Year-bitcoin-dev-Moderation-Review.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 1 Year bitcoin-dev Moderation Review - 2023-08-01T19:08:40.444967+00:00 + 2025-09-26T16:01:39.710917+00:00 + python-feedgen Dave Scotese 2016-10-10 15:34:17+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - 1 Year bitcoin-dev Moderation Review - 2023-08-01T19:08:40.444967+00:00 + 2025-09-26T16:01:39.711075+00:00 - A member of the bitcoin-dev mailing list, Jeremy Rubin, has raised concerns about the moderation policy and its impact on the community. According to Rubin, since the implementation of moderation, there has been a noticeable decline in the number of messages posted daily, making the community less accessible. He suggests that people may be self-censoring out of fear of being moderated as trolling or spam, which is reducing the value of the list. Henning Kopp agrees with Rubin's assessment and emphasizes the need to keep non-development talk off the developer list. This discussion highlights the importance of communication channels in the development process and how excessive moderation can hinder communication and the exchange of ideas within a community.Jeremy, a member of the Bitcoin development team, questions whether the moderation on the bitcoin-dev mailing list is stifling discussion and diminishing the list's value. While recognizing the potential benefits of moderation, he argues that it may have gone too far, discouraging people from writing emails due to the fear of being moderated. Jeremy believes that the rate of moderated posts does not accurately reflect the "chilling effect" of moderation, which reduces email activity and limits valuable communication within the community. He suggests that the community should collectively address this issue in order to restore open communication.Another member of the community, Henning Kopp, agrees that non-development talk should be kept off the bitcoin-dev mailing list but proposes finding a way to revitalize the bitcoin-discuss list, which has not gained enough contributors. The suggestion is made that bitcoin-discuss should have an opt-out system instead of opt-in, raising questions about the subscription counts for both bitcoin-dev and bitcoin-discuss. The author of the message requests this information from the moderators, although their specific reason for wanting it is unclear. The choice between an opt-in and opt-out system can impact the number of subscribers to a group or mailing list.In summary, Jeremy Rubin initiates a discussion on the impact of moderation on the bitcoin-dev mailing list, expressing concerns about decreased email activity and self-censorship. He suggests reopening the communication channel while acknowledging the need to keep non-development talk separate. The suggestion of an opt-out system for the bitcoin-discuss list is also raised, raising questions about subscription counts for both lists. Overall, this discussion highlights the importance of effective communication channels and the potential consequences of excessive moderation within a community. 2016-10-10T15:34:17+00:00 + A member of the bitcoin-dev mailing list, Jeremy Rubin, has raised concerns about the moderation policy and its impact on the community. According to Rubin, since the implementation of moderation, there has been a noticeable decline in the number of messages posted daily, making the community less accessible. He suggests that people may be self-censoring out of fear of being moderated as trolling or spam, which is reducing the value of the list. Henning Kopp agrees with Rubin's assessment and emphasizes the need to keep non-development talk off the developer list. This discussion highlights the importance of communication channels in the development process and how excessive moderation can hinder communication and the exchange of ideas within a community.Jeremy, a member of the Bitcoin development team, questions whether the moderation on the bitcoin-dev mailing list is stifling discussion and diminishing the list's value. While recognizing the potential benefits of moderation, he argues that it may have gone too far, discouraging people from writing emails due to the fear of being moderated. Jeremy believes that the rate of moderated posts does not accurately reflect the "chilling effect" of moderation, which reduces email activity and limits valuable communication within the community. He suggests that the community should collectively address this issue in order to restore open communication.Another member of the community, Henning Kopp, agrees that non-development talk should be kept off the bitcoin-dev mailing list but proposes finding a way to revitalize the bitcoin-discuss list, which has not gained enough contributors. The suggestion is made that bitcoin-discuss should have an opt-out system instead of opt-in, raising questions about the subscription counts for both bitcoin-dev and bitcoin-discuss. The author of the message requests this information from the moderators, although their specific reason for wanting it is unclear. The choice between an opt-in and opt-out system can impact the number of subscribers to a group or mailing list.In summary, Jeremy Rubin initiates a discussion on the impact of moderation on the bitcoin-dev mailing list, expressing concerns about decreased email activity and self-censorship. He suggests reopening the communication channel while acknowledging the need to keep non-development talk separate. The suggestion of an opt-out system for the bitcoin-discuss list is also raised, raising questions about subscription counts for both lists. Overall, this discussion highlights the importance of effective communication channels and the potential consequences of excessive moderation within a community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_About-ASICBoost.xml b/static/bitcoin-dev/Oct_2016/combined_About-ASICBoost.xml index 9b45964518..87b5237e7b 100644 --- a/static/bitcoin-dev/Oct_2016/combined_About-ASICBoost.xml +++ b/static/bitcoin-dev/Oct_2016/combined_About-ASICBoost.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - About ASICBoost - 2023-08-01T19:08:07.114785+00:00 + 2025-09-26T16:01:35.484320+00:00 + python-feedgen Gregory Maxwell 2016-10-02 23:27:20+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - About ASICBoost - 2023-08-01T19:08:07.114785+00:00 + 2025-09-26T16:01:35.484472+00:00 - In an email dated October 2, 2016, Bitcoin developer Matt Corallo expressed concerns about the Bitcoin Foundation's potential disregard for Bitcoin's future centralization. He criticized the idea of asking the foundation to pay a license fee to avoid holding the rest of the Bitcoin mining community hostage. Corallo also mentioned the lack of transparent licensing and transparency in public discussions after the patent had been filed. However, he acknowledged that they cannot change the past and instead suggested focusing on collaboration for the future.The Bitcoin Foundation's lack of transparency regarding licensing has come under fire after they failed to license a patent from Sergio Lerner. In 2013, Lerner reached out to the foundation asking if they would license his patent on fair terms. The foundation declined, stating that it did not believe the proprietary patent would be significant. The lack of transparent licensing has raised concerns about centralization pressure and the potential harm it could cause Bitcoin in the long-term. Matt Corallo has criticized the foundation for its handling of the situation, suggesting that their disregard for future centralization is worrying.In a message to the bitcoin-dev mailing list, Matt Corallo criticized anonymous miner "Satoshi Nakamoto" for not showing concern towards centralization pressure and its potential long-term harm to Bitcoin. However, it was revealed that Sergio had privately expressed concerns about centralization pressure and reached out to the BCF in 2013 to license his patent which would make its user(s) 30% more effective than others under "fair" terms. The BCF responded by encouraging him to seek the patent as they didn't think it would be a big deal.The Bitcoin community is concerned about unnecessary entanglements of consensus code with patents. Sergio Demian Lerner had proposed an extra nonce space BIP and had already applied for the ASICBOOST patent without disclosing it in the BIP nor in the Bitcoin Core pull request. The BIP proposal does not increase or decrease the entanglement of Bitcoin consensus code with any patents and AsicBoost is possible with or without adoption of that BIP proposal. The rationale behind the BIP proposal was to eliminate incentives to mess with the merkle root and, in the extreme case, to mine empty blocks. The concern is that this might be happening again as Lerner proposed a new sidechain BIP. It is great that Lerner has now committed to looking into the Defensive Patent License which seems likely to mitigate some of the patent concerns.In an email thread on the Bitcoin-dev mailing list, Sergio Demian Lerner asked Peter Todd to explain his views on a patent for hardware design for ASICs. Lerner notes that there are at least three similar patents filed by major Bitcoin ASIC manufacturers in three different countries. Todd responds that the comparison is misleading and he is not aware of any other patents on Bitcoin-specific ASIC technology which are practically enforceable or which the owners have indicated they wish to enforce. Of the two patents which Lerner pointed out which were filed on essentially the same optimization that ASICBoost covers, Todd says that Lerner's predates both of them, invalidating both the Spondoolies one and the AntMiner one. Todd claims that only Lerner's patent is practical and likely to be enforced in the vast majority of the world. Todd believes that optimizations to the hashing algorithm are not themselves "attacks" on Bitcoin. But only when they are used in a rent-seeking fashion to push for more centralization and lower miner revenue do they become so. One of the biggest advantages of SHA256 in the context of mining is exactly that it is a relatively simple algorithm, allowing for fewer large algorithmic optimizations. This opens the doors to more competition in the ASIC market than if only few people had the knowledge (or a patent) to build efficient ASICs. Todd claims that while the high-end ASIC-manufacturing industry is highly-centralized, making it worse by limiting those who can build Bitcoin ASICs from anyone with access to such a fab to only those who can, additionally, negotiate for patent rights and navigate the modern patent system, is far from ideal. Todd criticizes Lerner's proposal for a hard fork, with the only argument given as to why it should happen being that he thought there was an attack, but couldn't yet "really tell if they could affect Bitcoin". Instead of following up with more information, as he indicated he would, he went and patented the optimizations and has gone on rent-seeking behavior since. Todd concludes that if Lerner had acted in a way which indicated even the slightest regard for centralization pressure and the harm it can do to Bitcoin in the long-term, then he doesn't think many would be blaming him.The context is a discussion about the implementation of ASICBoost in Bitcoin, which was proposed as a way to improve mining efficiency. The author shares that they had shared their findings with some core developers prior to the BIP proposal, but it is unclear if they kept it secret or shared it with 2016-10-02T23:27:20+00:00 + In an email dated October 2, 2016, Bitcoin developer Matt Corallo expressed concerns about the Bitcoin Foundation's potential disregard for Bitcoin's future centralization. He criticized the idea of asking the foundation to pay a license fee to avoid holding the rest of the Bitcoin mining community hostage. Corallo also mentioned the lack of transparent licensing and transparency in public discussions after the patent had been filed. However, he acknowledged that they cannot change the past and instead suggested focusing on collaboration for the future.The Bitcoin Foundation's lack of transparency regarding licensing has come under fire after they failed to license a patent from Sergio Lerner. In 2013, Lerner reached out to the foundation asking if they would license his patent on fair terms. The foundation declined, stating that it did not believe the proprietary patent would be significant. The lack of transparent licensing has raised concerns about centralization pressure and the potential harm it could cause Bitcoin in the long-term. Matt Corallo has criticized the foundation for its handling of the situation, suggesting that their disregard for future centralization is worrying.In a message to the bitcoin-dev mailing list, Matt Corallo criticized anonymous miner "Satoshi Nakamoto" for not showing concern towards centralization pressure and its potential long-term harm to Bitcoin. However, it was revealed that Sergio had privately expressed concerns about centralization pressure and reached out to the BCF in 2013 to license his patent which would make its user(s) 30% more effective than others under "fair" terms. The BCF responded by encouraging him to seek the patent as they didn't think it would be a big deal.The Bitcoin community is concerned about unnecessary entanglements of consensus code with patents. Sergio Demian Lerner had proposed an extra nonce space BIP and had already applied for the ASICBOOST patent without disclosing it in the BIP nor in the Bitcoin Core pull request. The BIP proposal does not increase or decrease the entanglement of Bitcoin consensus code with any patents and AsicBoost is possible with or without adoption of that BIP proposal. The rationale behind the BIP proposal was to eliminate incentives to mess with the merkle root and, in the extreme case, to mine empty blocks. The concern is that this might be happening again as Lerner proposed a new sidechain BIP. It is great that Lerner has now committed to looking into the Defensive Patent License which seems likely to mitigate some of the patent concerns.In an email thread on the Bitcoin-dev mailing list, Sergio Demian Lerner asked Peter Todd to explain his views on a patent for hardware design for ASICs. Lerner notes that there are at least three similar patents filed by major Bitcoin ASIC manufacturers in three different countries. Todd responds that the comparison is misleading and he is not aware of any other patents on Bitcoin-specific ASIC technology which are practically enforceable or which the owners have indicated they wish to enforce. Of the two patents which Lerner pointed out which were filed on essentially the same optimization that ASICBoost covers, Todd says that Lerner's predates both of them, invalidating both the Spondoolies one and the AntMiner one. Todd claims that only Lerner's patent is practical and likely to be enforced in the vast majority of the world. Todd believes that optimizations to the hashing algorithm are not themselves "attacks" on Bitcoin. But only when they are used in a rent-seeking fashion to push for more centralization and lower miner revenue do they become so. One of the biggest advantages of SHA256 in the context of mining is exactly that it is a relatively simple algorithm, allowing for fewer large algorithmic optimizations. This opens the doors to more competition in the ASIC market than if only few people had the knowledge (or a patent) to build efficient ASICs. Todd claims that while the high-end ASIC-manufacturing industry is highly-centralized, making it worse by limiting those who can build Bitcoin ASICs from anyone with access to such a fab to only those who can, additionally, negotiate for patent rights and navigate the modern patent system, is far from ideal. Todd criticizes Lerner's proposal for a hard fork, with the only argument given as to why it should happen being that he thought there was an attack, but couldn't yet "really tell if they could affect Bitcoin". Instead of following up with more information, as he indicated he would, he went and patented the optimizations and has gone on rent-seeking behavior since. Todd concludes that if Lerner had acted in a way which indicated even the slightest regard for centralization pressure and the harm it can do to Bitcoin in the long-term, then he doesn't think many would be blaming him.The context is a discussion about the implementation of ASICBoost in Bitcoin, which was proposed as a way to improve mining efficiency. The author shares that they had shared their findings with some core developers prior to the BIP proposal, but it is unclear if they kept it secret or shared it with - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_BIP-2-revival-and-rework.xml b/static/bitcoin-dev/Oct_2016/combined_BIP-2-revival-and-rework.xml index 6599416055..f3774da54f 100644 --- a/static/bitcoin-dev/Oct_2016/combined_BIP-2-revival-and-rework.xml +++ b/static/bitcoin-dev/Oct_2016/combined_BIP-2-revival-and-rework.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 2 revival and rework - 2023-08-01T19:05:44.160816+00:00 + 2025-09-26T16:01:46.045239+00:00 + python-feedgen Tom Zander 2016-10-16 14:56:36+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP 2 revival and rework - 2023-08-01T19:05:44.160816+00:00 + 2025-09-26T16:01:46.045394+00:00 - In a discussion on whether work can be released under public domain and CC-BY-SA, Marco Falke and Tom Zander had differing views. Zander believed that it is not possible to dual-license something under both CC-BY-SA and public domain because all licenses are based on having copyright, whereas public domain means the lack of copyright. Zander preferred copyleft licenses for BIPs. Tom Zander suggested that BIPs should be licensed as public domain with a CC-BY option. It was pointed out that while BIP 1 requires public domain or OPL, it does not forbid other licenses. Similarly, BIP 2 allows for other acceptable licenses but does not recommend them. Despite the goal of no longer allowing public domain as the only copyright option, BIP 2 does not forbid releasing work under public domain in jurisdictions where it is recognized as legal. Many BIP authors have previously chosen public domain as the only option.On October 15, 2016, Tom Zander and Marco Falke discussed the licensing of BIPs. Zander had dual-licensed BIP 134 under OPL and CC-BY-SA for future acceptance of CC-BY-SA without needing permission from all authors to remove the OPL. Falke pointed out that BIP 2 does not allow public domain as the only copyright option, to which Zander responded that public domain was never the only option.In an email exchange between Tom Zander and Luke Dashjr, they discussed licensing options for BIPs. Zander suggested public domain (CC0) or a CC-BY option, while Dashjr added MIT/BSD licenses. Dashjr explained that BIP 1 only allows OPL and public domain, so BIP 2 can be available under OPL until it activates. Dashjr clarified that CC0 and public domain are different. Dashjr was asked to reach out to the community to ensure BIP 2 has been heard and discussed. France and Germany do not recognize public domain, while GPL is valid anywhere copyright laws exist.On October 15, 2016, a discussion took place on the Bitcoin development mailing list regarding the licensing of BIPs. Marco Falke suggested licensing BIPs under CC0 with a CC-BY option, while Tom Zander disagreed and suggested a requirement for "Share alike" and an optional "Attribution." It was argued that more restrictive licenses are not suitable for BIPs and that the BIP repository is not the place to promote open access. BIP 2 allows for such licenses but does not recommend them. Clarity around proposed changes and reasoning was encouraged. The discussion concluded with the suggestion to move forward with BIP 2 if there were no objections.In a conversation on the Bitcoin Development mailing list about licensing for BIPs, it was suggested that "Share alike" be required and "Attribution" be optional. However, it was pointed out that there is no Creative Commons license option that requires Share Alike and allows Attribution as an option. CC0, MIT/BSD, or CC-BY were proposed as suitable licenses for BIPs. The suitability of more restrictive licenses and promoting open access in the BIP repository were also discussed. BIP 2 allows for such licenses but does not recommend them. The email thread concluded with the suggestion to move forward with BIP 2 if there were no objections.Luke Dashjr announced that the Open Publication License (OPL) will no longer be acceptable for BIPs. He recommended replacing OPL with one or two Creative Commons licenses, with the choice between CCO and BY-SA licenses alongside public domain. The Open Publication License, created in 1999, was superseded by Creative Commons licenses. Luke-jr made updates to BIP 2, replacing BIP 1, and introduced changes such as the acceptance of non-image auxiliary files, required email addresses for authors, and disallowing Markdown format. The updated BIP 2 was open for review with the aim of completion by Christmas. 2016-10-16T14:56:36+00:00 + In a discussion on whether work can be released under public domain and CC-BY-SA, Marco Falke and Tom Zander had differing views. Zander believed that it is not possible to dual-license something under both CC-BY-SA and public domain because all licenses are based on having copyright, whereas public domain means the lack of copyright. Zander preferred copyleft licenses for BIPs. Tom Zander suggested that BIPs should be licensed as public domain with a CC-BY option. It was pointed out that while BIP 1 requires public domain or OPL, it does not forbid other licenses. Similarly, BIP 2 allows for other acceptable licenses but does not recommend them. Despite the goal of no longer allowing public domain as the only copyright option, BIP 2 does not forbid releasing work under public domain in jurisdictions where it is recognized as legal. Many BIP authors have previously chosen public domain as the only option.On October 15, 2016, Tom Zander and Marco Falke discussed the licensing of BIPs. Zander had dual-licensed BIP 134 under OPL and CC-BY-SA for future acceptance of CC-BY-SA without needing permission from all authors to remove the OPL. Falke pointed out that BIP 2 does not allow public domain as the only copyright option, to which Zander responded that public domain was never the only option.In an email exchange between Tom Zander and Luke Dashjr, they discussed licensing options for BIPs. Zander suggested public domain (CC0) or a CC-BY option, while Dashjr added MIT/BSD licenses. Dashjr explained that BIP 1 only allows OPL and public domain, so BIP 2 can be available under OPL until it activates. Dashjr clarified that CC0 and public domain are different. Dashjr was asked to reach out to the community to ensure BIP 2 has been heard and discussed. France and Germany do not recognize public domain, while GPL is valid anywhere copyright laws exist.On October 15, 2016, a discussion took place on the Bitcoin development mailing list regarding the licensing of BIPs. Marco Falke suggested licensing BIPs under CC0 with a CC-BY option, while Tom Zander disagreed and suggested a requirement for "Share alike" and an optional "Attribution." It was argued that more restrictive licenses are not suitable for BIPs and that the BIP repository is not the place to promote open access. BIP 2 allows for such licenses but does not recommend them. Clarity around proposed changes and reasoning was encouraged. The discussion concluded with the suggestion to move forward with BIP 2 if there were no objections.In a conversation on the Bitcoin Development mailing list about licensing for BIPs, it was suggested that "Share alike" be required and "Attribution" be optional. However, it was pointed out that there is no Creative Commons license option that requires Share Alike and allows Attribution as an option. CC0, MIT/BSD, or CC-BY were proposed as suitable licenses for BIPs. The suitability of more restrictive licenses and promoting open access in the BIP repository were also discussed. BIP 2 allows for such licenses but does not recommend them. The email thread concluded with the suggestion to move forward with BIP 2 if there were no objections.Luke Dashjr announced that the Open Publication License (OPL) will no longer be acceptable for BIPs. He recommended replacing OPL with one or two Creative Commons licenses, with the choice between CCO and BY-SA licenses alongside public domain. The Open Publication License, created in 1999, was superseded by Creative Commons licenses. Luke-jr made updates to BIP 2, replacing BIP 1, and introduced changes such as the acceptance of non-image auxiliary files, required email addresses for authors, and disallowing Markdown format. The updated BIP 2 was open for review with the aim of completion by Christmas. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml b/static/bitcoin-dev/Oct_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml index 6f3e19695f..005b985384 100644 --- a/static/bitcoin-dev/Oct_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml +++ b/static/bitcoin-dev/Oct_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft: OP_CHECKBLOCKATHEIGHT - 2023-08-01T19:04:16.255801+00:00 + 2025-09-26T16:01:27.037329+00:00 + python-feedgen Nathan Cook 2016-10-05 02:15:36+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - BIP draft: OP_CHECKBLOCKATHEIGHT - 2023-08-01T19:04:16.255801+00:00 + 2025-09-26T16:01:27.037533+00:00 - A proposal has been made for a new opcode, OP_CHECKBLOCKATHEIGHT, in the Bitcoin scripting system. This opcode aims to tackle the problem of re-issuing bitcoin transactions when the coins they spend have been conflicted or double-spent. The proposal sparked a discussion among developers on the bitcoin-dev mailing list.Some developers expressed concerns about the complexity and potential risks of the opcode. They argued that the added complexity may not be worth the reward of protecting Bitcoiners from untrusted creditors. There were also concerns about the impact on fungibility and the risk of invalidation caused by blockchain reorganizations.Luke Dashjr, the developer who proposed the opcode, provided examples to illustrate how it could solve the problem of double-spending. One example involved Alice sending Bob BTC using a specific UTXO, but Fred double-spends that UTXO, invalidating Alice's transfer. Without the new opcode, Alice could send Bob a different UTXO, but there is a risk of both UTXOs being mined, resulting in Bob receiving more BTC than intended. With the new opcode, Alice can create a transaction that is only valid in the blockchain where Fred's double-spend has been confirmed. If that block is reorganized out, the transaction becomes invalid, ensuring that Bob receives only the original UTXO or a revised transaction if the double-spend is confirmed again.The discussion also touched upon other aspects related to the proposed opcode. There were suggestions to prevent overuse of the opcode and enforce a maximum survivable reorg to ensure sensible handling of exposed coins. Concerns were raised about the impact on mempool handling and the potential for persistent chain forks.Overall, the proposed opcode aims to address the issue of double-spending and conflicts in bitcoin transactions. It introduces a new way for users to create transactions that are only valid in specific blockchain scenarios, ensuring that the intended recipient receives the correct amount of BTC without the risk of loss due to blockchain reorganizations. However, there are ongoing discussions and debates among developers about the complexity and potential risks associated with implementing this opcode.The proposal has been put forward by Luke-Jr, who is seeking feedback from the community on whether this approach is a good idea. It is currently uncertain whether this proposal will be accepted and implemented by the Bitcoin community. However, if accepted, the proposed opcode could potentially provide a solution to the issue of double-spending that has plagued the Bitcoin network in the past. Overall, this BIP presents an interesting and innovative approach to addressing the problem of double-spending in the Bitcoin network. While its acceptance and implementation are yet to be determined, it is worth considering as a potential solution to this long-standing issue. 2016-10-05T02:15:36+00:00 + A proposal has been made for a new opcode, OP_CHECKBLOCKATHEIGHT, in the Bitcoin scripting system. This opcode aims to tackle the problem of re-issuing bitcoin transactions when the coins they spend have been conflicted or double-spent. The proposal sparked a discussion among developers on the bitcoin-dev mailing list.Some developers expressed concerns about the complexity and potential risks of the opcode. They argued that the added complexity may not be worth the reward of protecting Bitcoiners from untrusted creditors. There were also concerns about the impact on fungibility and the risk of invalidation caused by blockchain reorganizations.Luke Dashjr, the developer who proposed the opcode, provided examples to illustrate how it could solve the problem of double-spending. One example involved Alice sending Bob BTC using a specific UTXO, but Fred double-spends that UTXO, invalidating Alice's transfer. Without the new opcode, Alice could send Bob a different UTXO, but there is a risk of both UTXOs being mined, resulting in Bob receiving more BTC than intended. With the new opcode, Alice can create a transaction that is only valid in the blockchain where Fred's double-spend has been confirmed. If that block is reorganized out, the transaction becomes invalid, ensuring that Bob receives only the original UTXO or a revised transaction if the double-spend is confirmed again.The discussion also touched upon other aspects related to the proposed opcode. There were suggestions to prevent overuse of the opcode and enforce a maximum survivable reorg to ensure sensible handling of exposed coins. Concerns were raised about the impact on mempool handling and the potential for persistent chain forks.Overall, the proposed opcode aims to address the issue of double-spending and conflicts in bitcoin transactions. It introduces a new way for users to create transactions that are only valid in specific blockchain scenarios, ensuring that the intended recipient receives the correct amount of BTC without the risk of loss due to blockchain reorganizations. However, there are ongoing discussions and debates among developers about the complexity and potential risks associated with implementing this opcode.The proposal has been put forward by Luke-Jr, who is seeking feedback from the community on whether this approach is a good idea. It is currently uncertain whether this proposal will be accepted and implemented by the Bitcoin community. However, if accepted, the proposed opcode could potentially provide a solution to the issue of double-spending that has plagued the Bitcoin network in the past. Overall, this BIP presents an interesting and innovative approach to addressing the problem of double-spending in the Bitcoin network. While its acceptance and implementation are yet to be determined, it is worth considering as a potential solution to this long-standing issue. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_Could-a-sidechain-protocol-create-an-addressable-Internet-of-Blockchains-and-facilitate-scaling-.xml b/static/bitcoin-dev/Oct_2016/combined_Could-a-sidechain-protocol-create-an-addressable-Internet-of-Blockchains-and-facilitate-scaling-.xml index 79eea0d75f..4b4f0e5b75 100644 --- a/static/bitcoin-dev/Oct_2016/combined_Could-a-sidechain-protocol-create-an-addressable-Internet-of-Blockchains-and-facilitate-scaling-.xml +++ b/static/bitcoin-dev/Oct_2016/combined_Could-a-sidechain-protocol-create-an-addressable-Internet-of-Blockchains-and-facilitate-scaling-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Could a sidechain protocol create an addressable "Internet of Blockchains" and facilitate scaling? - 2023-08-01T19:09:02.859509+00:00 + Combined summary - Could a sidechain protocol create an addressable "Internet of Blockchains" and facilitate scaling? + 2025-09-26T16:01:33.370861+00:00 + python-feedgen Natanael 2016-10-12 01:28:46+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 - Combined summary - Could a sidechain protocol create an addressable "Internet of Blockchains" and facilitate scaling? - 2023-08-01T19:09:02.859509+00:00 + Combined summary - Could a sidechain protocol create an addressable "Internet of Blockchains" and facilitate scaling? + 2025-09-26T16:01:33.371012+00:00 - Sidechains are a tool for scaling Bitcoin by transferring them from the main blockchain to external blockchains. However, the current approach keeps sidechains isolated from each other, requiring a slow transfer back to the mainchain. To address this, a proposed protocol for addressable blockchains aims to create an Internet of Blockchains by using a shared proof of work. This protocol would allow Bitcoins to be moved into a master sidechain called Angel, which sits at the top of a tree of blockchains.In this system, each blockchain has its own unique address similar to an IP address, and the Angel blockchain acts as a registrar, keeping a public record of every blockchain and its properties. Creating a new blockchain is as simple as including a createBlockchain transaction in an Angel block with specified parameters like block creation time and size limit.Mining in the Angel blockchain follows a standardized format, creating hashes that enable different blockchains to contribute to the same proof of work. Child blockchains inherit security from their parents without the same level of PoW difficulty. This means that if a child attempts a double spend by withdrawing to a parent after spending on the child, it will be instantly visible. Child nodes can then broadcast proof of the double spend to parent chain nodes, preventing them from mining on those blocks.The Angel blockchain allows for a free market approach, allowing different approaches and use cases such as privacy, high transaction volume, and Turing completeness to coexist seamlessly alongside each other. Bitcoin serves as the standard medium of exchange for these complementary blockchains.Another concept to achieve infinite scaling is compressing validation data maximally to enable Turing completeness for multiple interacting chains or "namespaces". This rolling blockchain uses Zero-knowledge proofs for secure pruning and preserves the entire history. Each chain is registered under a unique name and defines its own external API and rules for updating its data.Programs (transactions) can be transformed into a "diff" on the blockchain state with accompanying Zero-knowledge proofs. These proofs can be chained, allowing groups of users on a chain to create a proof for their changes, which is then compressed and sent to miners who generate a proof for the root. However, interaction between many chains can make validation inefficient, requiring more client interaction.The ideal scenario would involve creating a Lightning Network equivalent for processing programs in near real-time and quickly settling on changes to commit to the root. Programs would need to be designed for networking so that servers can negotiate their APIs across all chains until they have a complete set of changes without conflicts to commit.Overall, the proposed protocol for addressable blockchains and the Angel blockchain aim to enable scaling Bitcoin infinitely by allowing different blockchains to coexist and interact seamlessly, while preserving security and decentralization. 2016-10-12T01:28:46+00:00 + Sidechains are a tool for scaling Bitcoin by transferring them from the main blockchain to external blockchains. However, the current approach keeps sidechains isolated from each other, requiring a slow transfer back to the mainchain. To address this, a proposed protocol for addressable blockchains aims to create an Internet of Blockchains by using a shared proof of work. This protocol would allow Bitcoins to be moved into a master sidechain called Angel, which sits at the top of a tree of blockchains.In this system, each blockchain has its own unique address similar to an IP address, and the Angel blockchain acts as a registrar, keeping a public record of every blockchain and its properties. Creating a new blockchain is as simple as including a createBlockchain transaction in an Angel block with specified parameters like block creation time and size limit.Mining in the Angel blockchain follows a standardized format, creating hashes that enable different blockchains to contribute to the same proof of work. Child blockchains inherit security from their parents without the same level of PoW difficulty. This means that if a child attempts a double spend by withdrawing to a parent after spending on the child, it will be instantly visible. Child nodes can then broadcast proof of the double spend to parent chain nodes, preventing them from mining on those blocks.The Angel blockchain allows for a free market approach, allowing different approaches and use cases such as privacy, high transaction volume, and Turing completeness to coexist seamlessly alongside each other. Bitcoin serves as the standard medium of exchange for these complementary blockchains.Another concept to achieve infinite scaling is compressing validation data maximally to enable Turing completeness for multiple interacting chains or "namespaces". This rolling blockchain uses Zero-knowledge proofs for secure pruning and preserves the entire history. Each chain is registered under a unique name and defines its own external API and rules for updating its data.Programs (transactions) can be transformed into a "diff" on the blockchain state with accompanying Zero-knowledge proofs. These proofs can be chained, allowing groups of users on a chain to create a proof for their changes, which is then compressed and sent to miners who generate a proof for the root. However, interaction between many chains can make validation inefficient, requiring more client interaction.The ideal scenario would involve creating a Lightning Network equivalent for processing programs in near real-time and quickly settling on changes to commit to the root. Programs would need to be designed for networking so that servers can negotiate their APIs across all chains until they have a complete set of changes without conflicts to commit.Overall, the proposed protocol for addressable blockchains and the Angel blockchain aim to enable scaling Bitcoin infinitely by allowing different blockchains to coexist and interact seamlessly, while preserving security and decentralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_DPL-is-not-only-not-enough-but-brings-unfounded-confidence-to-Bitcoin-users.xml b/static/bitcoin-dev/Oct_2016/combined_DPL-is-not-only-not-enough-but-brings-unfounded-confidence-to-Bitcoin-users.xml index a563983972..25feb1973c 100644 --- a/static/bitcoin-dev/Oct_2016/combined_DPL-is-not-only-not-enough-but-brings-unfounded-confidence-to-Bitcoin-users.xml +++ b/static/bitcoin-dev/Oct_2016/combined_DPL-is-not-only-not-enough-but-brings-unfounded-confidence-to-Bitcoin-users.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DPL is not only not enough, but brings unfounded confidence to Bitcoin users - 2023-08-01T19:09:56.073302+00:00 + 2025-09-26T16:01:48.158839+00:00 + python-feedgen Tom Zander 2016-10-15 10:01:32+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - DPL is not only not enough, but brings unfounded confidence to Bitcoin users - 2023-08-01T19:09:56.073302+00:00 + 2025-09-26T16:01:48.159001+00:00 - In an email conversation on the bitcoin-dev list, Daniel Robinson and Tom Zander discussed the potential advantages of the Defensive Patent License (DPL) over unilateral patent disarmament. Zander pointed out that the DPL could be more effective than MIT/BSD licenses because it creates an incentive for other companies to adopt it as well. This is important because MIT/BSD licenses allow companies to take without giving back, which doesn't build a community. Copyleft allows people to embrace and take, but if they extend they have to give back.The discussion on the bitcoin-dev mailing list has centered around the role of patents in the technology industry. While non-practicing entities are a known issue, companies also obtain patents to prevent competition and produce competing products. Obtaining a patent for defensive purposes can make it difficult for others to obtain patents on the same subject matter. However, several people have noted that patent applications are more effective than defensive publication at getting prior art under the noses of patent examiners.One user argues that pledging not to use patents offensively defeats the point of owning patents, which is to use them offensively either to prevent competition or get licensing fees. Defensive patents are useless against litigants who do not produce or make anything and whose "product" is patent lawsuits. Another user expresses concern about the Defensive Patent License (DPL) v1.1 and how it may pose a threat to Bitcoin users. Companies that join the DPL can enforce their patents against anyone who has chosen not to join, meaning most individuals cannot and will not hire patent attorneys to advise them on what benefits they are resigning. The DPL is revocable by the signers, so if Bitcoin Core ends up using any DPL-covered patent, the company owning the patent can later force all new Bitcoin users to pay royalties.A solution proposed by one user is to grant everyone an irrevocable license for the content of emails or BIPs. However, there is a problem with defining "Bitcoin users," as different forks and versions of Bitcoin may exist. Another suggestion is to change the Bitcoin Core license to an Apache2/LGPL3 dual license to ensure the copyright license also has anti-patent protections. The discussion highlights the complex issue of patents in the technology industry and the need for careful consideration when obtaining and utilizing them.The context of the conversation is related to a proposal made by an individual for a Bitcoin Improvement Proposal (BIP) that had the effect of benefiting their ASICBOOST patent without disclosing it. The individual denies the accusation and explains that the BIP actually protects the network from stealth Shared-Nonce mining. The rejection of the BIP has made the Bitcoin network less secure, as it is unclear to what extent the mining method is in use. The ASICBOOST patent, according to the individual, protects Bitcoiners from mining centralization, and they have no control over the company that owns the technology. The individual proposes a community crowdfund to license the technology and put it into the public domain.The email thread discusses the potential advantage of a dedicated Bitcoin-related defensive patent pool, similar to Linux's Open Invention Network. The idea is to strategically deploy patent licenses to encourage cooperation and punish aggressors. Additionally, it is suggested that changing the Bitcoin Core license to something like Apache2/LGPL3 dual license could ensure the copyright license also has anti-patent protections. The use of Apache2.0 license for new releases and contributions can be feasible, while already-existing code and previous releases will remain under the MIT license. The discussion also highlights the benefits of using Apache2.0 license, which contains an explicit patent license grant and terminates that license if the licensee asserts a claim alleging that the covered work infringes a patent.The Defensive Patent License (DPL) has been criticized for being dangerous for Bitcoin users, as it allows companies that join DPL to enforce their patents against anyone who has not joined. Furthermore, the license is revocable by signers, which could lead to new Bitcoin users being forced to pay royalties. However, a dedicated Bitcoin-related defensive patent pool, similar to Linux's Open Invention Network, could strategically deploy patent licenses to incentivize cooperation and punish aggressors. Additionally, changing the Bitcoin Core license to something like an Apache2/LGPL3 dual license could ensure the copyright license also has anti-patent protections. The Apache 2.0 license contains an explicit patent license grant and terminates that license if the licensee asserts a claim alleging that the covered work infringes a patent. This might be an effective deterrent against bringing patent claims based on alleged infringement in Bitcoin Core. Upgrading to the Apache license for new releases and contributions would be feasible, leaving already-existing code and previous releases under the MIT license (a copyright "soft-fork").In a Bitcoin development discussion, Sergio Demian Lerner expressed his concerns about the Defensive Patent License (DPL) v1.1. He stated that it is 2016-10-15T10:01:32+00:00 + In an email conversation on the bitcoin-dev list, Daniel Robinson and Tom Zander discussed the potential advantages of the Defensive Patent License (DPL) over unilateral patent disarmament. Zander pointed out that the DPL could be more effective than MIT/BSD licenses because it creates an incentive for other companies to adopt it as well. This is important because MIT/BSD licenses allow companies to take without giving back, which doesn't build a community. Copyleft allows people to embrace and take, but if they extend they have to give back.The discussion on the bitcoin-dev mailing list has centered around the role of patents in the technology industry. While non-practicing entities are a known issue, companies also obtain patents to prevent competition and produce competing products. Obtaining a patent for defensive purposes can make it difficult for others to obtain patents on the same subject matter. However, several people have noted that patent applications are more effective than defensive publication at getting prior art under the noses of patent examiners.One user argues that pledging not to use patents offensively defeats the point of owning patents, which is to use them offensively either to prevent competition or get licensing fees. Defensive patents are useless against litigants who do not produce or make anything and whose "product" is patent lawsuits. Another user expresses concern about the Defensive Patent License (DPL) v1.1 and how it may pose a threat to Bitcoin users. Companies that join the DPL can enforce their patents against anyone who has chosen not to join, meaning most individuals cannot and will not hire patent attorneys to advise them on what benefits they are resigning. The DPL is revocable by the signers, so if Bitcoin Core ends up using any DPL-covered patent, the company owning the patent can later force all new Bitcoin users to pay royalties.A solution proposed by one user is to grant everyone an irrevocable license for the content of emails or BIPs. However, there is a problem with defining "Bitcoin users," as different forks and versions of Bitcoin may exist. Another suggestion is to change the Bitcoin Core license to an Apache2/LGPL3 dual license to ensure the copyright license also has anti-patent protections. The discussion highlights the complex issue of patents in the technology industry and the need for careful consideration when obtaining and utilizing them.The context of the conversation is related to a proposal made by an individual for a Bitcoin Improvement Proposal (BIP) that had the effect of benefiting their ASICBOOST patent without disclosing it. The individual denies the accusation and explains that the BIP actually protects the network from stealth Shared-Nonce mining. The rejection of the BIP has made the Bitcoin network less secure, as it is unclear to what extent the mining method is in use. The ASICBOOST patent, according to the individual, protects Bitcoiners from mining centralization, and they have no control over the company that owns the technology. The individual proposes a community crowdfund to license the technology and put it into the public domain.The email thread discusses the potential advantage of a dedicated Bitcoin-related defensive patent pool, similar to Linux's Open Invention Network. The idea is to strategically deploy patent licenses to encourage cooperation and punish aggressors. Additionally, it is suggested that changing the Bitcoin Core license to something like Apache2/LGPL3 dual license could ensure the copyright license also has anti-patent protections. The use of Apache2.0 license for new releases and contributions can be feasible, while already-existing code and previous releases will remain under the MIT license. The discussion also highlights the benefits of using Apache2.0 license, which contains an explicit patent license grant and terminates that license if the licensee asserts a claim alleging that the covered work infringes a patent.The Defensive Patent License (DPL) has been criticized for being dangerous for Bitcoin users, as it allows companies that join DPL to enforce their patents against anyone who has not joined. Furthermore, the license is revocable by signers, which could lead to new Bitcoin users being forced to pay royalties. However, a dedicated Bitcoin-related defensive patent pool, similar to Linux's Open Invention Network, could strategically deploy patent licenses to incentivize cooperation and punish aggressors. Additionally, changing the Bitcoin Core license to something like an Apache2/LGPL3 dual license could ensure the copyright license also has anti-patent protections. The Apache 2.0 license contains an explicit patent license grant and terminates that license if the licensee asserts a claim alleging that the covered work infringes a patent. This might be an effective deterrent against bringing patent claims based on alleged infringement in Bitcoin Core. Upgrading to the Apache license for new releases and contributions would be feasible, leaving already-existing code and previous releases under the MIT license (a copyright "soft-fork").In a Bitcoin development discussion, Sergio Demian Lerner expressed his concerns about the Defensive Patent License (DPL) v1.1. He stated that it is - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_Defensive-Patent-License-Offer-Notice.xml b/static/bitcoin-dev/Oct_2016/combined_Defensive-Patent-License-Offer-Notice.xml index 0a1fa68988..28ad80ca3c 100644 --- a/static/bitcoin-dev/Oct_2016/combined_Defensive-Patent-License-Offer-Notice.xml +++ b/static/bitcoin-dev/Oct_2016/combined_Defensive-Patent-License-Offer-Notice.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Defensive Patent License Offer Notice - 2023-08-01T19:09:16.527858+00:00 + 2025-09-26T16:01:37.597596+00:00 + python-feedgen greg misiorek 2016-10-13 13:03:45+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Defensive Patent License Offer Notice - 2023-08-01T19:09:16.527858+00:00 + 2025-09-26T16:01:37.597726+00:00 - Peter Todd, a Bitcoin Core developer, has made a significant declaration regarding his patents. He has declared himself and any technology companies he controls as "Defensive" by committing to offer a Defensive Patent License (DPL) for any of his patents, whether they exist currently or in the future, to any DPL User. It is worth noting that neither Peter Todd nor any companies under his control currently have any patents.The announcement was made on Peter Todd's website, petertodd.org, and includes a link to the transaction ID (txid) of a Bitcoin transaction containing the message. This adds transparency and verifiability to his commitment. It is important to highlight that Peter Todd is offering only a specific version of the DPL based on the advice of his lawyer. The inclusion of the language "all technology companies I control" is to prevent any complications with non-technology companies he may control in the future. Examples of such non-technology companies include family real-estate holding companies and the non-profit caving group he is a part of.As of now, Peter Todd only controls one company, which he considers a "technology company". This company is the numbered company through which he conducts all his consulting work. Therefore, the offer mentioned above applies to this company. Furthermore, if Peter Todd gains control of any other technology companies in the future, the same offer will apply to them.For those interested in contacting Peter Todd, he can be reached at the email address "pete@petertodd.org". His commitment to offering a Defensive Patent License demonstrates his dedication to promoting an open and collaborative approach to technological advancements within the Bitcoin community. 2016-10-13T13:03:45+00:00 + Peter Todd, a Bitcoin Core developer, has made a significant declaration regarding his patents. He has declared himself and any technology companies he controls as "Defensive" by committing to offer a Defensive Patent License (DPL) for any of his patents, whether they exist currently or in the future, to any DPL User. It is worth noting that neither Peter Todd nor any companies under his control currently have any patents.The announcement was made on Peter Todd's website, petertodd.org, and includes a link to the transaction ID (txid) of a Bitcoin transaction containing the message. This adds transparency and verifiability to his commitment. It is important to highlight that Peter Todd is offering only a specific version of the DPL based on the advice of his lawyer. The inclusion of the language "all technology companies I control" is to prevent any complications with non-technology companies he may control in the future. Examples of such non-technology companies include family real-estate holding companies and the non-profit caving group he is a part of.As of now, Peter Todd only controls one company, which he considers a "technology company". This company is the numbered company through which he conducts all his consulting work. Therefore, the offer mentioned above applies to this company. Furthermore, if Peter Todd gains control of any other technology companies in the future, the same offer will apply to them.For those interested in contacting Peter Todd, he can be reached at the email address "pete@petertodd.org". His commitment to offering a Defensive Patent License demonstrates his dedication to promoting an open and collaborative approach to technological advancements within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_Drivechain-proposal-using-OP-COUNT-ACKS.xml b/static/bitcoin-dev/Oct_2016/combined_Drivechain-proposal-using-OP-COUNT-ACKS.xml index b7a6b0d004..9e3dc41a59 100644 --- a/static/bitcoin-dev/Oct_2016/combined_Drivechain-proposal-using-OP-COUNT-ACKS.xml +++ b/static/bitcoin-dev/Oct_2016/combined_Drivechain-proposal-using-OP-COUNT-ACKS.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Drivechain proposal using OP_COUNT_ACKS - 2023-08-01T19:07:27.640200+00:00 + 2025-09-26T16:01:24.925422+00:00 + python-feedgen Johnson Lau 2016-10-25 17:45:20+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Drivechain proposal using OP_COUNT_ACKS - 2023-08-01T19:07:27.641201+00:00 + 2025-09-26T16:01:24.925672+00:00 - The discussion revolves around proposals to improve the Bitcoin protocol through a softfork. One proposal suggests using an unused code instead of OP_NOPx, while another considers a new witness version and additional field in the witness. There are concerns about limited coinbase space and potential poll space shortage.Sergio Demian Lerner has proposed a segwit-based and soft-forked opcode called OP_COUNT_ACKS to count acknowledgement tags in coinbase fields. The proposal aims to achieve zero risk of invalidating a block, strong protection from DoS attacks, and minimum block space consumption. Lerner will discuss the design at the Scaling Bitcoin event.The proposed system includes a new opcode that counts acks and nacks tags in coinbase fields and pushes the totals onto the script stack. Concerns were raised about the validity of transactions and the potential for double-spending. Transactions redeeming outputs containing or referencing OP_COUNT_ACKS are not broadcast by the network and can only be included by miners.There is a discussion about encumbrances on the proposal that could prevent its use in the Bitcoin project. Suggestions are made to resolve patent concerns, such as voluntary disclosure of patents with a free license or adopting a defensive patent strategy. Concerns are also raised about the validity of transactions being dependent on the block they are included in.The context also mentions the implementation of decentralised sidechains and the process of redemption from a side chain. It is noted that the speaker's understanding of sidechain developments may be incomplete.In another email thread, it is discussed whether Rootstock's proposal is encumbered by patents or pending patents. Suggestions are made for Rootstock to adopt a legally binding patent pledge or license to ensure their developments remain free and open. The purpose of the list is emphasized as technical discussion, not political disagreements.There is a conversation between Sergio Demian Lerner and Peter Todd about a down vote on Lerner's Rootstock proposal. Lerner suggests that Rootstock adopt a legally binding patent pledge/license, such as the Defensive Patent License (DPL), to continue collaborating. Todd raises concerns about Rootstock's prior behavior regarding patents and suggests guarantees to prevent offensive use of patents.Sergio Demian Lerner, Bitcoiner and RSK co-founder, has proposed a drivechain in the BIP draft that he hopes will be used as the foundation for new 2-way-pegged blockchains. This drivechain aims to expand the use cases of Bitcoin by allowing it to be taken to new niches and tested in different scenarios. The drivechain is designed with various key properties in mind, such as ensuring no risk of invalidating a block, minimizing additional computation during blockchain management and re-organization, offering strong protection against DoS attacks, consuming minimal block space, and eliminating the risk of cross-secondary chain invalidation.Lerner's proposal comes after expressing concerns over proposals from individuals or colleagues who have a history of patenting Bitcoin consensus relevant technology. He believes that this behavior poses a serious threat to decentralization and suggests that it needs to be addressed in a convincing and legally binding manner. To move forward, he proposes exploring Blockstream's patent pledges. However, Lerner NACKed the proposal due to its history of patenting. The proposal specifically pertained to drivechains which RSK (also known as Rootstock) intends to use for their two-way pegged blockchain implementation.In light of the approaching ScalingBitcoin event, Lerner saw it as an opportune time to publish the proposal on drivechains. While the full BIP and reference implementation can be found on GitHub, it should be noted that the code is still unaudited. Lerner will be available at ScalingBitcoin to discuss the design rationale, potential improvements, changes, and ideas related to the proposed drivechain. 2016-10-25T17:45:20+00:00 + The discussion revolves around proposals to improve the Bitcoin protocol through a softfork. One proposal suggests using an unused code instead of OP_NOPx, while another considers a new witness version and additional field in the witness. There are concerns about limited coinbase space and potential poll space shortage.Sergio Demian Lerner has proposed a segwit-based and soft-forked opcode called OP_COUNT_ACKS to count acknowledgement tags in coinbase fields. The proposal aims to achieve zero risk of invalidating a block, strong protection from DoS attacks, and minimum block space consumption. Lerner will discuss the design at the Scaling Bitcoin event.The proposed system includes a new opcode that counts acks and nacks tags in coinbase fields and pushes the totals onto the script stack. Concerns were raised about the validity of transactions and the potential for double-spending. Transactions redeeming outputs containing or referencing OP_COUNT_ACKS are not broadcast by the network and can only be included by miners.There is a discussion about encumbrances on the proposal that could prevent its use in the Bitcoin project. Suggestions are made to resolve patent concerns, such as voluntary disclosure of patents with a free license or adopting a defensive patent strategy. Concerns are also raised about the validity of transactions being dependent on the block they are included in.The context also mentions the implementation of decentralised sidechains and the process of redemption from a side chain. It is noted that the speaker's understanding of sidechain developments may be incomplete.In another email thread, it is discussed whether Rootstock's proposal is encumbered by patents or pending patents. Suggestions are made for Rootstock to adopt a legally binding patent pledge or license to ensure their developments remain free and open. The purpose of the list is emphasized as technical discussion, not political disagreements.There is a conversation between Sergio Demian Lerner and Peter Todd about a down vote on Lerner's Rootstock proposal. Lerner suggests that Rootstock adopt a legally binding patent pledge/license, such as the Defensive Patent License (DPL), to continue collaborating. Todd raises concerns about Rootstock's prior behavior regarding patents and suggests guarantees to prevent offensive use of patents.Sergio Demian Lerner, Bitcoiner and RSK co-founder, has proposed a drivechain in the BIP draft that he hopes will be used as the foundation for new 2-way-pegged blockchains. This drivechain aims to expand the use cases of Bitcoin by allowing it to be taken to new niches and tested in different scenarios. The drivechain is designed with various key properties in mind, such as ensuring no risk of invalidating a block, minimizing additional computation during blockchain management and re-organization, offering strong protection against DoS attacks, consuming minimal block space, and eliminating the risk of cross-secondary chain invalidation.Lerner's proposal comes after expressing concerns over proposals from individuals or colleagues who have a history of patenting Bitcoin consensus relevant technology. He believes that this behavior poses a serious threat to decentralization and suggests that it needs to be addressed in a convincing and legally binding manner. To move forward, he proposes exploring Blockstream's patent pledges. However, Lerner NACKed the proposal due to its history of patenting. The proposal specifically pertained to drivechains which RSK (also known as Rootstock) intends to use for their two-way pegged blockchain implementation.In light of the approaching ScalingBitcoin event, Lerner saw it as an opportune time to publish the proposal on drivechains. While the full BIP and reference implementation can be found on GitHub, it should be noted that the code is still unaudited. Lerner will be available at ScalingBitcoin to discuss the design rationale, potential improvements, changes, and ideas related to the proposed drivechain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_On-going-work-Coin-Selection-Simulation.xml b/static/bitcoin-dev/Oct_2016/combined_On-going-work-Coin-Selection-Simulation.xml index bbc598ebeb..e94ec445e6 100644 --- a/static/bitcoin-dev/Oct_2016/combined_On-going-work-Coin-Selection-Simulation.xml +++ b/static/bitcoin-dev/Oct_2016/combined_On-going-work-Coin-Selection-Simulation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On-going work: Coin Selection Simulation - 2023-08-01T19:02:53.385142+00:00 + 2025-09-26T16:01:22.809236+00:00 + python-feedgen Murch 2016-10-21 14:09:57+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - On-going work: Coin Selection Simulation - 2023-08-01T19:02:53.385142+00:00 + 2025-09-26T16:01:22.809406+00:00 - Murch, a Master's thesis student, has developed a Coin Selection Simulator and re-implemented multiple coin selection strategies of prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin). He invites interested parties to take a look at his work, which includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation. Murch has analyzed the Coin Selection problem and created a framework to simulate wallet behavior on the basis of a sequence of payments. He plans to publish the simulation code around Scaling Bitcoin or after he turns in his thesis.Murch also addresses a question from Daniel Weigl regarding why Mycelium generates a very big UTXO set for 5460sat. Murch explains that his simulation of the Mycelium coin selection adds small change outputs to the fee but got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Therefore, the results in the table might be slightly too big, but likely indicative of the actual Mycelium behavior. Murch assumes that Mycelium doesn't create small change outputs but rather hardly ever spends them when received. Murch believes that Mycelium appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up.A researcher, Murch, has analyzed the Coin Selection problem and re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. As part of this research, Murch created a framework to simulate wallet behavior on the basis of a sequence of payments. The simulation results are presented in a two-page description along with three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Murch also invited feedback and requested another sequence of incoming and outgoing payment amounts to run the simulation on. In response to Murch's email, Daniel Weigl, from Mycelium, inquired about the behavior of Mycelium coin selection algorithm. Murch clarified that Mycelium selects UTXO in a FIFO approach, but prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems to be the likely reason for Mycelium's small UTXO build-up. BreadWallet uses a very similar FIFO approach, but doesn't prune which causes their average UTXO set to be much smaller. A balanced approach between these two approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, who is compiling his Master's thesis about Coin Selection, has created a framework to simulate wallet behavior on the basis of a sequence of payments. He re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF containing a two-page description of his ongoing work includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Daniel Weigl asked about Mycelium's large UTXO set for 5460sat (=TransactionUtils.MINIMUM_OUTPUT_VALUE). Murch replied that his simulation did add small change outputs to the fee, but he got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Murch corrected the boundary in his simulation now and will update his simulation results before Scaling Bitcoin. Regarding Mycelium, Murch stated that it doesn't create small change outputs but rather hardly ever spends them when received. It appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up. A balanced approach between BreadWallet's and Mycelium's approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, a researcher, has compiled his Master's thesis about Coin Selection and his presentation proposal to Scaling Bitcoin has been accepted. In his thesis, he analyzed the Coin Selection problem, created a framework to simulate wallet behavior on the basis of a sequence of payments, and re-implemented multiple coin selection strategies of prominent Bitcoin wallets such as Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF contains a two-page 2016-10-21T14:09:57+00:00 + Murch, a Master's thesis student, has developed a Coin Selection Simulator and re-implemented multiple coin selection strategies of prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin). He invites interested parties to take a look at his work, which includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation. Murch has analyzed the Coin Selection problem and created a framework to simulate wallet behavior on the basis of a sequence of payments. He plans to publish the simulation code around Scaling Bitcoin or after he turns in his thesis.Murch also addresses a question from Daniel Weigl regarding why Mycelium generates a very big UTXO set for 5460sat. Murch explains that his simulation of the Mycelium coin selection adds small change outputs to the fee but got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Therefore, the results in the table might be slightly too big, but likely indicative of the actual Mycelium behavior. Murch assumes that Mycelium doesn't create small change outputs but rather hardly ever spends them when received. Murch believes that Mycelium appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up.A researcher, Murch, has analyzed the Coin Selection problem and re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. As part of this research, Murch created a framework to simulate wallet behavior on the basis of a sequence of payments. The simulation results are presented in a two-page description along with three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Murch also invited feedback and requested another sequence of incoming and outgoing payment amounts to run the simulation on. In response to Murch's email, Daniel Weigl, from Mycelium, inquired about the behavior of Mycelium coin selection algorithm. Murch clarified that Mycelium selects UTXO in a FIFO approach, but prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems to be the likely reason for Mycelium's small UTXO build-up. BreadWallet uses a very similar FIFO approach, but doesn't prune which causes their average UTXO set to be much smaller. A balanced approach between these two approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, who is compiling his Master's thesis about Coin Selection, has created a framework to simulate wallet behavior on the basis of a sequence of payments. He re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF containing a two-page description of his ongoing work includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Daniel Weigl asked about Mycelium's large UTXO set for 5460sat (=TransactionUtils.MINIMUM_OUTPUT_VALUE). Murch replied that his simulation did add small change outputs to the fee, but he got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Murch corrected the boundary in his simulation now and will update his simulation results before Scaling Bitcoin. Regarding Mycelium, Murch stated that it doesn't create small change outputs but rather hardly ever spends them when received. It appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up. A balanced approach between BreadWallet's and Mycelium's approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, a researcher, has compiled his Master's thesis about Coin Selection and his presentation proposal to Scaling Bitcoin has been accepted. In his thesis, he analyzed the Coin Selection problem, created a framework to simulate wallet behavior on the basis of a sequence of payments, and re-implemented multiple coin selection strategies of prominent Bitcoin wallets such as Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF contains a two-page - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_Start-time-for-BIP141-segwit-.xml b/static/bitcoin-dev/Oct_2016/combined_Start-time-for-BIP141-segwit-.xml index 4683f88fb2..66ff7c6f82 100644 --- a/static/bitcoin-dev/Oct_2016/combined_Start-time-for-BIP141-segwit-.xml +++ b/static/bitcoin-dev/Oct_2016/combined_Start-time-for-BIP141-segwit-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Start time for BIP141 (segwit) - 2023-08-01T19:11:28.846432+00:00 + 2025-09-26T16:01:29.149122+00:00 + python-feedgen Jorge Timón 2016-10-17 13:31:07+00:00 @@ -111,13 +112,13 @@ - python-feedgen + 2 Combined summary - Start time for BIP141 (segwit) - 2023-08-01T19:11:28.847442+00:00 + 2025-09-26T16:01:29.149336+00:00 - In a recent discussion on the Bitcoin-dev mailing list, concerns were raised about the safety and implementation of the SegWit upgrade. Tom Zander pointed out that if any issues occurred after deployment, all transactions made during that time would become everyone-can-spent transactions, resulting in real people losing real money. He emphasized the importance of ensuring proper miner support before activation to avoid this risk.However, there was debate over whether a longer grace period would actually make the network safer. Some members argued that companies would not roll out their updates until lock-in is confirmed, while others believed that many wallets already had code ready and tested but had not yet released it. The discussion also touched upon the amount of code and changes in SegWit, with Zander expressing concern that it was a dangerous change in Bitcoin. However, another member pointed out that SegWit had undergone extensive testing and review on various testnets.There were also discussions about the status of wallet developer updates for SegWit support. Some developers had already worked on SegWit support, but concerns were raised about inadequate testing and vetting. In addition, there were concerns about potential network splits and the need for an extended "fallow period" to ensure safety. However, some members dismissed these concerns and insisted that the safety period should not be extended.The discussion also mentioned the controversy surrounding the implementation of SegWit and the objections raised by some members. Despite this, most underlying libraries have already been adapted or are being adapted for SegWit. However, since SegWit is not yet live on mainnet, most libraries cannot release their SegWit supported versions until it is released as final. Companies are already planning to update their services for SegWit, but the actual state of wallet readiness may not be accurately reflected.Overall, the discussion on the Bitcoin-dev mailing list revolved around the safety measures for deploying SegWit, concerns about potential issues, and the readiness of wallet developers to support SegWit. There were differing opinions on the need for a longer grace period and the risks associated with the changes in SegWit. The debate highlighted the complexity and controversy surrounding the implementation of this upgrade.Tom Zander, a developer, has raised concerns about the deployment of SegWit, stating that using BIP9 to shorten the grace period is risky. He argues that once deployed, the feature cannot be rolled back, potentially turning all transactions into everyone-can-spend transactions. Zander believes that there is no need to use BIP9 and that stalling the process for two months does not improve security.In response, developer Jorge Timón argues that changing BIP9's initial date would not benefit those who have not yet started working on supporting SegWit. Zander suggests that if the reason for the short activation timespan is the use of BIP9, then it should not be used at all.There are objections to the implementation of SegWit due to its long wait time and the fact that some wallets are taking a "wait and see" approach. The majority of wallets are not ready for SegWit, leading to reservations about investing resources in adding support for a feature that may not be activated. Flexible Transactions has been proposed as a safer alternative, but its activation is dependent on whether it is locked in.The deployment of Segregated Witness (SegWit) has faced objections, with some wallets adopting a cautious approach. This is because most wallets are not prepared for SegWit activation, and they may not want to allocate resources to a feature that may never be activated. Flexible Transactions has been suggested as an alternative, but it remains uncertain which option will ultimately be activated.Bitcoin Core's 0.13.1 release includes segregated witness for Bitcoin mainnet after extensive testing. Setting BIP 141's start time to November 15, 2016, was proposed, following the recommendation to set the versionbits start time a month in the future. Activation on the network requires passing this date, a full retarget window of 2016 blocks with 95% signaling the version bit (bit 1 for BIP141), and a fallow period of another 2016 blocks.SPV wallets will continue to function normally without upgrading, as full nodes will provide transactions in a format they understand. However, end users may want to upgrade to benefit from lower transaction fees. Tom Zander suggests a minimum of two months for the fallow period, as this upgrade affects both businesses and end users.Gavin Andresen conducted a survey on how long it would take businesses and individuals to upgrade to a new release, with no one responding that it would take more than two weeks. He believes that those running their own validation code should be able to mitigate any risks associated with SegWit activation. While there have been objections to the implementation of SegWit, several wallets are close to finishing their support.In a discussion on the bitcoin-dev mailing list 2016-10-17T13:31:07+00:00 + In a recent discussion on the Bitcoin-dev mailing list, concerns were raised about the safety and implementation of the SegWit upgrade. Tom Zander pointed out that if any issues occurred after deployment, all transactions made during that time would become everyone-can-spent transactions, resulting in real people losing real money. He emphasized the importance of ensuring proper miner support before activation to avoid this risk.However, there was debate over whether a longer grace period would actually make the network safer. Some members argued that companies would not roll out their updates until lock-in is confirmed, while others believed that many wallets already had code ready and tested but had not yet released it. The discussion also touched upon the amount of code and changes in SegWit, with Zander expressing concern that it was a dangerous change in Bitcoin. However, another member pointed out that SegWit had undergone extensive testing and review on various testnets.There were also discussions about the status of wallet developer updates for SegWit support. Some developers had already worked on SegWit support, but concerns were raised about inadequate testing and vetting. In addition, there were concerns about potential network splits and the need for an extended "fallow period" to ensure safety. However, some members dismissed these concerns and insisted that the safety period should not be extended.The discussion also mentioned the controversy surrounding the implementation of SegWit and the objections raised by some members. Despite this, most underlying libraries have already been adapted or are being adapted for SegWit. However, since SegWit is not yet live on mainnet, most libraries cannot release their SegWit supported versions until it is released as final. Companies are already planning to update their services for SegWit, but the actual state of wallet readiness may not be accurately reflected.Overall, the discussion on the Bitcoin-dev mailing list revolved around the safety measures for deploying SegWit, concerns about potential issues, and the readiness of wallet developers to support SegWit. There were differing opinions on the need for a longer grace period and the risks associated with the changes in SegWit. The debate highlighted the complexity and controversy surrounding the implementation of this upgrade.Tom Zander, a developer, has raised concerns about the deployment of SegWit, stating that using BIP9 to shorten the grace period is risky. He argues that once deployed, the feature cannot be rolled back, potentially turning all transactions into everyone-can-spend transactions. Zander believes that there is no need to use BIP9 and that stalling the process for two months does not improve security.In response, developer Jorge Timón argues that changing BIP9's initial date would not benefit those who have not yet started working on supporting SegWit. Zander suggests that if the reason for the short activation timespan is the use of BIP9, then it should not be used at all.There are objections to the implementation of SegWit due to its long wait time and the fact that some wallets are taking a "wait and see" approach. The majority of wallets are not ready for SegWit, leading to reservations about investing resources in adding support for a feature that may not be activated. Flexible Transactions has been proposed as a safer alternative, but its activation is dependent on whether it is locked in.The deployment of Segregated Witness (SegWit) has faced objections, with some wallets adopting a cautious approach. This is because most wallets are not prepared for SegWit activation, and they may not want to allocate resources to a feature that may never be activated. Flexible Transactions has been suggested as an alternative, but it remains uncertain which option will ultimately be activated.Bitcoin Core's 0.13.1 release includes segregated witness for Bitcoin mainnet after extensive testing. Setting BIP 141's start time to November 15, 2016, was proposed, following the recommendation to set the versionbits start time a month in the future. Activation on the network requires passing this date, a full retarget window of 2016 blocks with 95% signaling the version bit (bit 1 for BIP141), and a fallow period of another 2016 blocks.SPV wallets will continue to function normally without upgrading, as full nodes will provide transactions in a format they understand. However, end users may want to upgrade to benefit from lower transaction fees. Tom Zander suggests a minimum of two months for the fallow period, as this upgrade affects both businesses and end users.Gavin Andresen conducted a survey on how long it would take businesses and individuals to upgrade to a new release, with no one responding that it would take more than two weeks. He believes that those running their own validation code should be able to mitigate any risks associated with SegWit activation. While there have been objections to the implementation of SegWit, several wallets are close to finishing their support.In a discussion on the bitcoin-dev mailing list - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_The-Soft-Fork-Deception.xml b/static/bitcoin-dev/Oct_2016/combined_The-Soft-Fork-Deception.xml index 6153964a0c..c3648d0e4e 100644 --- a/static/bitcoin-dev/Oct_2016/combined_The-Soft-Fork-Deception.xml +++ b/static/bitcoin-dev/Oct_2016/combined_The-Soft-Fork-Deception.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The Soft Fork Deception - 2023-08-01T19:11:41.423977+00:00 + 2025-09-26T16:01:43.931045+00:00 + python-feedgen Andrew C 2016-10-28 15:28:35+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - The Soft Fork Deception - 2023-08-01T19:11:41.423977+00:00 + 2025-09-26T16:01:43.931203+00:00 - The email thread discussing soft forks in Bitcoin Core reveals a misconception that soft forks do not require users to upgrade software. However, this is not entirely accurate, as miners and users who wish to utilize old rules are no longer able to do so under tightened rules implemented through soft forks. This can lead to network splits and the creation of two separate coins. The thread mentions the BIP 66 hard fork, which occurred due to greedy miners engaging in SPV mining rather than "sloppy deployment" by developers. The upcoming Segregated Witness (SegWit) soft fork is also discussed, raising questions about whether non-SegWit transactions will still validate blocks and whether miners mining non-SegWit blocks will be disregarded. One proposal suggests removing previously "soft forked" rules for non-SegWit transactions and requiring them only for SegWit transactions, making SegWit optional. However, this would necessitate a hard fork and result in functionality loss and various bug fixes. Amidst the conversation, Andrew proposes creating a new client called Bitcoin Authentic if his proposal does not gain traction. Other participants in the thread show little interest in this idea. Overall, the discussion highlights the need for clarity regarding the impact of soft forks on software upgrades, concerns about the upcoming SegWit soft fork, and proposals for alternative approaches to implementing new features. 2016-10-28T15:28:35+00:00 + The email thread discussing soft forks in Bitcoin Core reveals a misconception that soft forks do not require users to upgrade software. However, this is not entirely accurate, as miners and users who wish to utilize old rules are no longer able to do so under tightened rules implemented through soft forks. This can lead to network splits and the creation of two separate coins. The thread mentions the BIP 66 hard fork, which occurred due to greedy miners engaging in SPV mining rather than "sloppy deployment" by developers. The upcoming Segregated Witness (SegWit) soft fork is also discussed, raising questions about whether non-SegWit transactions will still validate blocks and whether miners mining non-SegWit blocks will be disregarded. One proposal suggests removing previously "soft forked" rules for non-SegWit transactions and requiring them only for SegWit transactions, making SegWit optional. However, this would necessitate a hard fork and result in functionality loss and various bug fixes. Amidst the conversation, Andrew proposes creating a new client called Bitcoin Authentic if his proposal does not gain traction. Other participants in the thread show little interest in this idea. Overall, the discussion highlights the need for clarity regarding the impact of soft forks on software upgrades, concerns about the upcoming SegWit soft fork, and proposals for alternative approaches to implementing new features. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_The-use-OP-COUNT-ACKS-for-paying-for-a-common-good-for-miners.xml b/static/bitcoin-dev/Oct_2016/combined_The-use-OP-COUNT-ACKS-for-paying-for-a-common-good-for-miners.xml index 68566a0962..481d8aae7d 100644 --- a/static/bitcoin-dev/Oct_2016/combined_The-use-OP-COUNT-ACKS-for-paying-for-a-common-good-for-miners.xml +++ b/static/bitcoin-dev/Oct_2016/combined_The-use-OP-COUNT-ACKS-for-paying-for-a-common-good-for-miners.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The use OP_COUNT_ACKS for paying for a common good for miners - 2023-08-01T19:08:20.555512+00:00 + 2025-09-26T16:01:31.258443+00:00 + python-feedgen Jorge Timón 2016-10-03 06:17:25+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - The use OP_COUNT_ACKS for paying for a common good for miners - 2023-08-01T19:08:20.555512+00:00 + 2025-09-26T16:01:31.258613+00:00 - In October 2016, Sergio Demian Lerner proposed a use case for OP_COUNT_ACKS in Bitcoin. This feature would allow users to pay miners for various services that they can provide as a group for the common good. These services could range from smoothing fee payments over multiple blocks to jointly purchasing better internet service in order to improve bandwidth and reduce latency between miners.To utilize this feature, users can send bitcoins to a script that contains OP_COUNT_ACKS. The script requires 51% of miners' approval for the transaction. Additionally, users can add a special text tag, such as "FOR-MINERS-TO-BUY-X", to these outputs. By doing so, users can effectively send bitcoins to miners and request the majority of them to vote on the proposal. If the proposal is accepted, a transaction will be created to redeem the funds.The implementation of OP_COUNT_ACKS and its associated crowdfunding system could potentially address the tragedy of the commons problem that Bitcoin may face in the long term. It allows users to collectively crowdfund the mining of the following n blocks, ensuring the sustainable growth and operation of the Bitcoin network. With this system, users have the ability to financially support miners and incentivize their participation in providing valuable services for the Bitcoin community.Overall, OP_COUNT_ACKS presents an innovative solution for users to pay for services provided by miners for the common good. By utilizing this feature, Bitcoin users can contribute to the long-term sustainability and development of the Bitcoin network. 2016-10-03T06:17:25+00:00 + In October 2016, Sergio Demian Lerner proposed a use case for OP_COUNT_ACKS in Bitcoin. This feature would allow users to pay miners for various services that they can provide as a group for the common good. These services could range from smoothing fee payments over multiple blocks to jointly purchasing better internet service in order to improve bandwidth and reduce latency between miners.To utilize this feature, users can send bitcoins to a script that contains OP_COUNT_ACKS. The script requires 51% of miners' approval for the transaction. Additionally, users can add a special text tag, such as "FOR-MINERS-TO-BUY-X", to these outputs. By doing so, users can effectively send bitcoins to miners and request the majority of them to vote on the proposal. If the proposal is accepted, a transaction will be created to redeem the funds.The implementation of OP_COUNT_ACKS and its associated crowdfunding system could potentially address the tragedy of the commons problem that Bitcoin may face in the long term. It allows users to collectively crowdfund the mining of the following n blocks, ensuring the sustainable growth and operation of the Bitcoin network. With this system, users have the ability to financially support miners and incentivize their participation in providing valuable services for the Bitcoin community.Overall, OP_COUNT_ACKS presents an innovative solution for users to pay for services provided by miners for the common good. By utilizing this feature, Bitcoin users can contribute to the long-term sustainability and development of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_A-solution-may-solve-Block-Withholding-Attack.xml b/static/bitcoin-dev/Oct_2017/combined_A-solution-may-solve-Block-Withholding-Attack.xml index 8b26d67f44..87e8da30f6 100644 --- a/static/bitcoin-dev/Oct_2017/combined_A-solution-may-solve-Block-Withholding-Attack.xml +++ b/static/bitcoin-dev/Oct_2017/combined_A-solution-may-solve-Block-Withholding-Attack.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - A solution may solve Block Withholding Attack - 2023-08-01T22:01:03.444454+00:00 - - Kevin Pan 2017-10-08 09:28:32+00:00 - - - James Hilliard 2017-10-06 14:36:15+00:00 - - - 潘志彪 2017-10-03 15:52:16+00:00 - + 2025-09-26T15:32:03.835703+00:00 + python-feedgen + + + [bitcoin-dev] A solution may solve Block Withholding Attack 潘志彪 + 2017-10-03T15:52:00.000Z + + + James Hilliard + 2017-10-06T14:36:00.000Z + + + Kevin Pan + 2017-10-08T09:28:00.000Z + + - python-feedgen + 2 Combined summary - A solution may solve Block Withholding Attack - 2023-08-01T22:01:03.444454+00:00 + 2025-09-26T15:32:03.836264+00:00 - Kevin Pan has proposed a solution to the Block Withholding Attack in Bitcoin. The idea is based on a proposal by Aviv Zohar and involves changing the difficulty algorithm. The new_diff equation divides DIFF_1 by the absolute value of the target minus an offset value. This offset value, which is a 32-byte uint256 in Bitcoin, must be within a specific range provided to miners by the mining pool.To implement this solution, the merkle root hash algorithm needs a slight modification to include the offset_hash at the beginning of the tx hashes array. When miners receive a job from the mining pool, they are given the PoW hash range (miner_hash_begin/end). If miners find a hash that falls within this range, they should submit it to the pool as a valid share. On the other hand, if the hash value is between the network_hash_begin and network_hash_end, then the miner has found a valid block.The network_diff, which is much higher than the miner's diff, ensures that cheat miners cannot determine which share could make a valid block. This prevents them from withholding blocks. However, there are two challenges with implementing this solution. Firstly, it requires a hard fork, which is not an easy task. Secondly, existing ASIC DSHA256 chips would become useless. Nonetheless, Pan believes that new ASIC chips can be created based on current technology.In addition to Pan's proposal, there have been other proposals to address the Block Withholding Attack, such as one from 2012 that may be possible to implement in existing miners. However, some mining pools, including those unable to remove the NYA tag, are currently unable to express their opinions or standpoint fully. Overall, the proposed solution by Kevin Pan offers a potential way to prevent the Block Withholding Attack in Bitcoin, although it comes with its own set of challenges. 2017-10-08T09:28:32+00:00 + Kevin Pan has proposed a solution to the Block Withholding Attack in Bitcoin. The idea is based on a proposal by Aviv Zohar and involves changing the difficulty algorithm. The new_diff equation divides DIFF_1 by the absolute value of the target minus an offset value. This offset value, which is a 32-byte uint256 in Bitcoin, must be within a specific range provided to miners by the mining pool.To implement this solution, the merkle root hash algorithm needs a slight modification to include the offset_hash at the beginning of the tx hashes array. When miners receive a job from the mining pool, they are given the PoW hash range (miner_hash_begin/end). If miners find a hash that falls within this range, they should submit it to the pool as a valid share. On the other hand, if the hash value is between the network_hash_begin and network_hash_end, then the miner has found a valid block.The network_diff, which is much higher than the miner's diff, ensures that cheat miners cannot determine which share could make a valid block. This prevents them from withholding blocks. However, there are two challenges with implementing this solution. Firstly, it requires a hard fork, which is not an easy task. Secondly, existing ASIC DSHA256 chips would become useless. Nonetheless, Pan believes that new ASIC chips can be created based on current technology.In addition to Pan's proposal, there have been other proposals to address the Block Withholding Attack, such as one from 2012 that may be possible to implement in existing miners. However, some mining pools, including those unable to remove the NYA tag, are currently unable to express their opinions or standpoint fully. Overall, the proposed solution by Kevin Pan offers a potential way to prevent the Block Withholding Attack in Bitcoin, although it comes with its own set of challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_Bitcoin-Core-build-system-automake-vs-cmake-.xml b/static/bitcoin-dev/Oct_2017/combined_Bitcoin-Core-build-system-automake-vs-cmake-.xml index 45d8b03b93..8c41c71c0b 100644 --- a/static/bitcoin-dev/Oct_2017/combined_Bitcoin-Core-build-system-automake-vs-cmake-.xml +++ b/static/bitcoin-dev/Oct_2017/combined_Bitcoin-Core-build-system-automake-vs-cmake-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Bitcoin Core build system (automake vs cmake) - 2023-08-01T22:03:32.997185+00:00 - - Thomas Guyot-Sionnest 2017-10-24 15:25:19+00:00 - - - Kosta Zertsekel 2017-10-23 11:52:04+00:00 - - - Kosta Zertsekel 2017-10-22 17:11:09+00:00 - + 2025-09-26T15:31:55.471617+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Core build system (automake vs cmake) Kosta Zertsekel + 2017-10-22T17:11:00.000Z + + + Kosta Zertsekel + 2017-10-23T11:52:00.000Z + + + Thomas Guyot-Sionnest + 2017-10-24T15:25:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Core build system (automake vs cmake) - 2023-08-01T22:03:32.997185+00:00 + 2025-09-26T15:31:55.472131+00:00 - In a conversation on the bitcoin-dev mailing list, Kosta Zertsekel expressed his curiosity about why Bitcoin Core uses Automake as its build system instead of cmake, which is generally considered to be better. Jeffrey Paul responded by stating that Automake is the standard and does not require any additional installation on most systems. He further asked Zertsekel about the specific problem he was trying to solve for bitcoin-core.Zertsekel provided quotes about the benefits of CMake build tools and inquired if there had been any discussion about choosing the best build system for Bitcoin Core. Thomas, another participant in the conversation, suggested that unless CMake can address a specific problem without causing other issues, there is no need to change the current build system. He also encouraged Zertsekel to convert bitcoin-core to CMake and demonstrate its advantages before proposing its adoption by developers.Although Jeffrey Paul defended the use of Automake due to its status as a standard and easy accessibility on most systems, there have been ongoing discussions about replacing Automake with more advanced build systems like Meson and Ninja. These alternatives were specifically developed to replace Automake and have already been adopted by companies and projects such as JetBrains and the KDE Project.In summary, Kosta Zertsekel questioned the decision to use Automake as the build system for Bitcoin Core, suggesting that CMake would be a better choice. While some participants defended the use of Automake as the standard, others acknowledged the potential benefits of alternative build systems. The discussion highlights the importance of considering specific problems and demonstrating the advantages of a new build system before proposing its adoption. 2017-10-24T15:25:19+00:00 + In a conversation on the bitcoin-dev mailing list, Kosta Zertsekel expressed his curiosity about why Bitcoin Core uses Automake as its build system instead of cmake, which is generally considered to be better. Jeffrey Paul responded by stating that Automake is the standard and does not require any additional installation on most systems. He further asked Zertsekel about the specific problem he was trying to solve for bitcoin-core.Zertsekel provided quotes about the benefits of CMake build tools and inquired if there had been any discussion about choosing the best build system for Bitcoin Core. Thomas, another participant in the conversation, suggested that unless CMake can address a specific problem without causing other issues, there is no need to change the current build system. He also encouraged Zertsekel to convert bitcoin-core to CMake and demonstrate its advantages before proposing its adoption by developers.Although Jeffrey Paul defended the use of Automake due to its status as a standard and easy accessibility on most systems, there have been ongoing discussions about replacing Automake with more advanced build systems like Meson and Ninja. These alternatives were specifically developed to replace Automake and have already been adopted by companies and projects such as JetBrains and the KDE Project.In summary, Kosta Zertsekel questioned the decision to use Automake as the build system for Bitcoin Core, suggesting that CMake would be a better choice. While some participants defended the use of Automake as the standard, others acknowledged the potential benefits of alternative build systems. The discussion highlights the importance of considering specific problems and demonstrating the advantages of a new build system before proposing its adoption. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_Generalized-sharding-protocol-for-decentralized-scaling-without-Miners-owning-our-BTC.xml b/static/bitcoin-dev/Oct_2017/combined_Generalized-sharding-protocol-for-decentralized-scaling-without-Miners-owning-our-BTC.xml index 9b019942cd..cf60efba95 100644 --- a/static/bitcoin-dev/Oct_2017/combined_Generalized-sharding-protocol-for-decentralized-scaling-without-Miners-owning-our-BTC.xml +++ b/static/bitcoin-dev/Oct_2017/combined_Generalized-sharding-protocol-for-decentralized-scaling-without-Miners-owning-our-BTC.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - Generalized sharding protocol for decentralized scaling without Miners owning our BTC - 2023-08-01T22:01:59.385992+00:00 - - Ben Kloester 2017-10-11 02:04:01+00:00 - - - James Hudon 2017-10-10 20:57:03+00:00 - - - CryptAxe 2017-10-10 20:49:20+00:00 - - - Tao Effect 2017-10-10 20:43:17+00:00 - - - Paul Sztorc 2017-10-10 20:23:45+00:00 - - - Lucas Clemente Vella 2017-10-10 20:23:43+00:00 - - - Lucas Clemente Vella 2017-10-10 20:18:39+00:00 - - - Tao Effect 2017-10-10 20:13:20+00:00 - - - CryptAxe 2017-10-10 19:50:13+00:00 - - - Tao Effect 2017-10-10 19:25:03+00:00 - - - Paul Sztorc 2017-10-10 15:09:21+00:00 - - - Tao Effect 2017-10-10 14:09:44+00:00 - - - Paul Sztorc 2017-10-10 11:20:36+00:00 - - - Tao Effect 2017-10-10 05:19:58+00:00 - - - Paul Sztorc 2017-10-10 01:39:33+00:00 - - - Tao Effect 2017-10-10 01:02:38+00:00 - - - Tao Effect 2017-10-10 00:04:55+00:00 - + 2025-09-26T15:31:59.645890+00:00 + python-feedgen + + + [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC Tao Effect + 2017-10-10T00:04:00.000Z + + + Tao Effect + 2017-10-10T01:02:00.000Z + + + Paul Sztorc + 2017-10-10T01:39:00.000Z + + + Tao Effect + 2017-10-10T05:19:00.000Z + + + Paul Sztorc + 2017-10-10T11:20:00.000Z + + + Tao Effect + 2017-10-10T14:09:00.000Z + + + Paul Sztorc + 2017-10-10T15:09:00.000Z + + + Tao Effect + 2017-10-10T19:25:00.000Z + + + CryptAxe + 2017-10-10T19:50:00.000Z + + + Tao Effect + 2017-10-10T20:13:00.000Z + + + Lucas Clemente Vella + 2017-10-10T20:18:00.000Z + + + Lucas Clemente Vella + 2017-10-10T20:23:00.000Z + + + Paul Sztorc + 2017-10-10T20:23:00.000Z + + + Tao Effect + 2017-10-10T20:43:00.000Z + + + CryptAxe + 2017-10-10T20:49:00.000Z + + + James Hudon + 2017-10-10T20:57:00.000Z + + + Ben Kloester + 2017-10-11T02:04:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - Generalized sharding protocol for decentralized scaling without Miners owning our BTC - 2023-08-01T22:01:59.385992+00:00 + 2025-09-26T15:31:59.647756+00:00 - In an email to a list, Greg Slepak suggests a generic sharding protocol for all blockchains, including Bitcoin. This protocol aims to enhance scaling without compromising security and eliminates the need for miners to have ownership of coins. While acknowledging that the idea may not be new, as it might have been proposed earlier in different forms like Interledger, Greg presents a solution where users can burn their coins on Chain A and create a minting transaction on Chain B. The specific mechanisms to prevent coin loss would require further discussion among the group. However, thin clients, nodes, and miners can easily verify these actions, allowing users' client software to locate the other coins.The proposed protocol does not require much modification to the Bitcoin protocol and allows for scaling without sacrificing security. Some participants in the discussion raised concerns about changing the number of Bitcoins in existence and the potential loss of money for users. However, proponents of the proposal argue that the burning of coins applies only to the original coins and does not change the total amount of Bitcoin. There is also a comparison made between the proposed sharding protocol and Drivechain, with the former being favored for its better security and decentralized nature. Overall, the conversation reflects ongoing efforts to find solutions for scaling Bitcoin while maintaining its core principles. Greg expresses his apologies if similar ideas have already been mentioned by others. 2017-10-11T02:04:01+00:00 + In an email to a list, Greg Slepak suggests a generic sharding protocol for all blockchains, including Bitcoin. This protocol aims to enhance scaling without compromising security and eliminates the need for miners to have ownership of coins. While acknowledging that the idea may not be new, as it might have been proposed earlier in different forms like Interledger, Greg presents a solution where users can burn their coins on Chain A and create a minting transaction on Chain B. The specific mechanisms to prevent coin loss would require further discussion among the group. However, thin clients, nodes, and miners can easily verify these actions, allowing users' client software to locate the other coins.The proposed protocol does not require much modification to the Bitcoin protocol and allows for scaling without sacrificing security. Some participants in the discussion raised concerns about changing the number of Bitcoins in existence and the potential loss of money for users. However, proponents of the proposal argue that the burning of coins applies only to the original coins and does not change the total amount of Bitcoin. There is also a comparison made between the proposed sharding protocol and Drivechain, with the former being favored for its better security and decentralized nature. Overall, the conversation reflects ongoing efforts to find solutions for scaling Bitcoin while maintaining its core principles. Greg expresses his apologies if similar ideas have already been mentioned by others. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_Improving-Scalability-via-Block-Time-Decrease.xml b/static/bitcoin-dev/Oct_2017/combined_Improving-Scalability-via-Block-Time-Decrease.xml index fe5662b2d7..e9b5e8a6c6 100644 --- a/static/bitcoin-dev/Oct_2017/combined_Improving-Scalability-via-Block-Time-Decrease.xml +++ b/static/bitcoin-dev/Oct_2017/combined_Improving-Scalability-via-Block-Time-Decrease.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Improving Scalability via Block Time Decrease - 2023-08-01T22:03:03.425292+00:00 - - Adán Sánchez de Pedro Crespo 2017-10-19 13:41:51+00:00 - - - Jonathan Sterling 2017-10-19 06:52:48+00:00 - + 2025-09-26T15:31:57.558814+00:00 + python-feedgen + + + [bitcoin-dev] Improving Scalability via Block Time Decrease Jonathan Sterling + 2017-10-19T06:52:00.000Z + + + Adán Sánchez de Pedro Crespo + 2017-10-19T13:41:00.000Z + + - python-feedgen + 2 Combined summary - Improving Scalability via Block Time Decrease - 2023-08-01T22:03:03.425292+00:00 + 2025-09-26T15:31:57.559278+00:00 - Blockchains that produce blocks quickly often face reduced security due to a high stale rate. This is because the time it takes for a block to propagate through the network can result in another miner mining a block before the first one reaches them, thus impacting network security. Additionally, if a mining pool with a higher hash power produces blocks quickly, they are more likely to have a higher risk of producing stale blocks compared to other miners.Reducing the average block time may require adjusting the block size accordingly to prevent the blockchain from growing too fast or transaction fees from decreasing, which could be exploited by spammers to bloat UTXO sets. One proposed solution to address the downsides of faster blocks is the "Greedy Heaviest Observed Subtree" (GHOST) protocol.The author questions the benefits of faster blocks for Bitcoin and seeks valid points on why the current 10-minute block time is considered optimal, apart from the idea of not fixing something that isn't broken. Adán Sánchez de Pedro Crespo, the CTO of Stampery Inc., shares this perspective.Satoshi Nakamoto, the creator of Bitcoin, chose the 10-minute block time as a compromise between confirmation time and wasted work caused by chain splits. However, there may be room for optimization in this number considering technological advancements and the absence of a definitive formula to determine the ideal rate.Jonathan Sterling ponders if further exploration into this matter is warranted and provides links to relevant articles for reference. He welcomes guidance if his understanding is flawed. 2017-10-19T13:41:51+00:00 + Blockchains that produce blocks quickly often face reduced security due to a high stale rate. This is because the time it takes for a block to propagate through the network can result in another miner mining a block before the first one reaches them, thus impacting network security. Additionally, if a mining pool with a higher hash power produces blocks quickly, they are more likely to have a higher risk of producing stale blocks compared to other miners.Reducing the average block time may require adjusting the block size accordingly to prevent the blockchain from growing too fast or transaction fees from decreasing, which could be exploited by spammers to bloat UTXO sets. One proposed solution to address the downsides of faster blocks is the "Greedy Heaviest Observed Subtree" (GHOST) protocol.The author questions the benefits of faster blocks for Bitcoin and seeks valid points on why the current 10-minute block time is considered optimal, apart from the idea of not fixing something that isn't broken. Adán Sánchez de Pedro Crespo, the CTO of Stampery Inc., shares this perspective.Satoshi Nakamoto, the creator of Bitcoin, chose the 10-minute block time as a compromise between confirmation time and wasted work caused by chain splits. However, there may be room for optimization in this number considering technological advancements and the absence of a definitive formula to determine the ideal rate.Jonathan Sterling ponders if further exploration into this matter is warranted and provides links to relevant articles for reference. He welcomes guidance if his understanding is flawed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml b/static/bitcoin-dev/Oct_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml index 1e6e0cffe8..b7426dd992 100644 --- a/static/bitcoin-dev/Oct_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml +++ b/static/bitcoin-dev/Oct_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml @@ -1,59 +1,167 @@ - + 2 Combined summary - Merkle branch verification & tail-call semantics for generalized MAST - 2023-08-01T21:47:30.334441+00:00 - - Luke Dashjr 2017-11-04 07:59:07+00:00 - - - Mark Friedenbach 2017-11-01 15:08:46+00:00 - - - Luke Dashjr 2017-11-01 08:43:48+00:00 - - - Mark Friedenbach 2017-10-28 04:40:01+00:00 - - - Russell O'Connor 2017-10-02 17:15:38+00:00 - - - Mark Friedenbach 2017-09-30 23:51:49+00:00 - - - Luke Dashjr 2017-09-30 23:23:32+00:00 - - - Mark Friedenbach 2017-09-19 00:46:30+00:00 - - - Peter Todd 2017-09-13 09:41:07+00:00 - - - Karl Johan Alm 2017-09-12 23:27:36+00:00 - - - Mark Friedenbach 2017-09-12 19:57:10+00:00 - - - Johnson Lau 2017-09-12 08:55:59+00:00 - - - Bryan Bishop 2017-09-12 02:13:24+00:00 - - - Mark Friedenbach 2017-09-12 02:03:42+00:00 - - - Adán Sánchez de Pedro Crespo 2017-09-11 20:37:55+00:00 - - - Johnson Lau 2017-09-08 09:21:22+00:00 - - - Mark Friedenbach 2017-09-07 00:38:55+00:00 - + 2025-09-26T15:31:46.963522+00:00 + python-feedgen + + + [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Mark Friedenbach + 2017-09-07T00:38:00.000Z + + + Johnson Lau + 2017-09-08T09:21:00.000Z + + + Adán Sánchez de Pedro Crespo + 2017-09-11T20:37:00.000Z + + + Mark Friedenbach + 2017-09-12T02:03:00.000Z + + + Bryan Bishop + 2017-09-12T02:13:00.000Z + + + Johnson Lau + 2017-09-12T08:55:00.000Z + + + Mark Friedenbach + 2017-09-12T19:57:00.000Z + + + Karl Johan Alm + 2017-09-12T23:27:00.000Z + + + Peter Todd + 2017-09-13T09:41:00.000Z + + + Mark Friedenbach + 2017-09-19T00:46:00.000Z + + + [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Luke Dashjr + 2017-09-19T03:09:00.000Z + + + Mark Friedenbach + 2017-09-19T07:33:00.000Z + + + [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Johnson Lau + 2017-09-20T05:13:00.000Z + + + Mark Friedenbach + 2017-09-20T19:29:00.000Z + + + Johnson Lau + 2017-09-21T03:58:00.000Z + + + Luke Dashjr + 2017-09-21T04:11:00.000Z + + + Johnson Lau + 2017-09-21T08:02:00.000Z + + + Luke Dashjr + 2017-09-21T16:33:00.000Z + + + Johnson Lau + 2017-09-21T17:38:00.000Z + + + Sergio Demian Lerner + 2017-09-22T20:32:00.000Z + + + Mark Friedenbach + 2017-09-22T21:11:00.000Z + + + Sergio Demian Lerner + 2017-09-22T21:32:00.000Z + + + Mark Friedenbach + 2017-09-22T21:39:00.000Z + + + Sergio Demian Lerner + 2017-09-22T21:54:00.000Z + + + Mark Friedenbach + 2017-09-22T22:07:00.000Z + + + Pieter Wuille + 2017-09-22T22:09:00.000Z + + + [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Luke Dashjr + 2017-09-30T23:23:00.000Z + + + Mark Friedenbach + 2017-09-30T23:51:00.000Z + + + Russell O'Connor + 2017-10-02T17:15:00.000Z + + + Mark Friedenbach + 2017-10-28T04:40:00.000Z + + + Luke Dashjr + 2017-11-01T08:43:00.000Z + + + Mark Friedenbach + 2017-11-01T15:08:00.000Z + + + Luke Dashjr + 2017-11-04T07:59:00.000Z + + + [bitcoin-dev] maximum block height on transaction Erik Aronesty + 2021-04-09T08:15:00.000Z + + + Russell O'Connor + 2021-04-09T11:39:00.000Z + + + Jeremy + 2021-04-09T15:54:00.000Z + + + Billy Tetrud + 2021-04-12T20:04:00.000Z + + + ZmnSCPxj + 2021-04-16T04:24:00.000Z + + + ZmnSCPxj + 2021-05-03T02:30:00.000Z + + @@ -71,13 +179,13 @@ - python-feedgen + 2 Combined summary - Merkle branch verification & tail-call semantics for generalized MAST - 2023-08-01T21:47:30.334441+00:00 + 2025-09-26T15:31:46.967287+00:00 - During a discussion on the bitcoin-dev mailing list, Mark Friedenbach and Johnson Lau discussed the use of OP_CHECKSIGADD and its vulnerability to Denial of Service (DoS) attacks. Friedenbach suggested using a new witness version instead, but Lau raised concerns about potential slowness. They debated design decisions for a new witness version, including tree signatures and MAST. The use of limits to prevent DoS attacks was also discussed, with Friedenbach proposing committing the total validation cost as the first witness stack item. He argued that the cost of implementing such changes would be worth it. Friedenbach also proposed an alternative solution involving removing certain lines of code from interpreter.cpp. Both proposals had different pros and cons and should not be purposefully restricted to compare head to head.Friedenbach apologized for the delay in responding to emails due to a cold. Lau had pointed out that tail-call execution semantics require an "unclean stack", which is invalid in BIP141. A new witness version could be used instead. Friedenbach disagreed with the current SigOp counting method used by Bitcoin, suggesting a single linear metric that combines all factors with appropriate coefficients. He proposed having the witness commit to the maximum resources consumed by validation of the spend of the coin. Maintaining static analysability for global limits was deemed important to prevent attacks on relay and mining nodes. There was also a suggestion to re-evaluate the need for counting SigOps other than for legacy consensus rule compliance. Witness script versioning was noted to be fully compatible with P2SH and BIP173. The minimal BIP114 solution could involve hiding scripts in a hash. A repository containing the latest implementation of BIP 114 can be found on GitHub.The email thread also included discussions about tail-call execution semantics, unclosed stacks, SigOp counting, and witness script versioning. Friedenbach highlighted an error regarding an "unclean stack" in a participant's comment. This mistake was also pointed out at the recent CoreDev meetup. The complexity of the BIP114 implementation was questioned, and there was a query regarding the availability of a repository for the latest BIP 114 implementation. Links to the original BIP114 and its revised versions were provided.In another discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed two new features to be added to the Bitcoin protocol via soft-fork activation. These features are MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics. MBV allows script authors to force redemption to use values selected from a pre-determined set committed to in the scriptPubKey, without revealing unused elements in the set for enhanced privacy and smaller script sizes. Tail-call execution semantics allow a single level of recursion into a subscript, providing properties similar to P2SH while being more flexible. Friedenbach believed that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects.During a discussion about the MAST proposal, there was a suggestion to have different opcodes for single vs multi-element MBV for script analysis purposes. However, it was countered that static analysability can be maintained if the script encodes the number of elements as an integer push to the top of the stack immediately before the opcode. Mark Friedenbach was assigned the task of investigating an ideal serialization format for a multi-element proof, which is the only thing holding back a multi-element MBV proposal. The discussion also touched on tail-call semantics, script version upgrades, and other related issues.Overall, Mark Friedenbach has proposed two new features, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics, to be added to the Bitcoin protocol. These features provide enhanced privacy, smaller script sizes, and flexibility in script execution. Friedenbach believes that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects. 2017-11-04T07:59:07+00:00 + During a discussion on the bitcoin-dev mailing list, Mark Friedenbach and Johnson Lau discussed the use of OP_CHECKSIGADD and its vulnerability to Denial of Service (DoS) attacks. Friedenbach suggested using a new witness version instead, but Lau raised concerns about potential slowness. They debated design decisions for a new witness version, including tree signatures and MAST. The use of limits to prevent DoS attacks was also discussed, with Friedenbach proposing committing the total validation cost as the first witness stack item. He argued that the cost of implementing such changes would be worth it. Friedenbach also proposed an alternative solution involving removing certain lines of code from interpreter.cpp. Both proposals had different pros and cons and should not be purposefully restricted to compare head to head.Friedenbach apologized for the delay in responding to emails due to a cold. Lau had pointed out that tail-call execution semantics require an "unclean stack", which is invalid in BIP141. A new witness version could be used instead. Friedenbach disagreed with the current SigOp counting method used by Bitcoin, suggesting a single linear metric that combines all factors with appropriate coefficients. He proposed having the witness commit to the maximum resources consumed by validation of the spend of the coin. Maintaining static analysability for global limits was deemed important to prevent attacks on relay and mining nodes. There was also a suggestion to re-evaluate the need for counting SigOps other than for legacy consensus rule compliance. Witness script versioning was noted to be fully compatible with P2SH and BIP173. The minimal BIP114 solution could involve hiding scripts in a hash. A repository containing the latest implementation of BIP 114 can be found on GitHub.The email thread also included discussions about tail-call execution semantics, unclosed stacks, SigOp counting, and witness script versioning. Friedenbach highlighted an error regarding an "unclean stack" in a participant's comment. This mistake was also pointed out at the recent CoreDev meetup. The complexity of the BIP114 implementation was questioned, and there was a query regarding the availability of a repository for the latest BIP 114 implementation. Links to the original BIP114 and its revised versions were provided.In another discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed two new features to be added to the Bitcoin protocol via soft-fork activation. These features are MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics. MBV allows script authors to force redemption to use values selected from a pre-determined set committed to in the scriptPubKey, without revealing unused elements in the set for enhanced privacy and smaller script sizes. Tail-call execution semantics allow a single level of recursion into a subscript, providing properties similar to P2SH while being more flexible. Friedenbach believed that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects.During a discussion about the MAST proposal, there was a suggestion to have different opcodes for single vs multi-element MBV for script analysis purposes. However, it was countered that static analysability can be maintained if the script encodes the number of elements as an integer push to the top of the stack immediately before the opcode. Mark Friedenbach was assigned the task of investigating an ideal serialization format for a multi-element proof, which is the only thing holding back a multi-element MBV proposal. The discussion also touched on tail-call semantics, script version upgrades, and other related issues.Overall, Mark Friedenbach has proposed two new features, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics, to be added to the Bitcoin protocol. These features provide enhanced privacy, smaller script sizes, and flexibility in script execution. Friedenbach believes that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_New-difficulty-algorithm-needed-for-SegWit2x-fork-reformatted-text-.xml b/static/bitcoin-dev/Oct_2017/combined_New-difficulty-algorithm-needed-for-SegWit2x-fork-reformatted-text-.xml index c587f83922..70695ed733 100644 --- a/static/bitcoin-dev/Oct_2017/combined_New-difficulty-algorithm-needed-for-SegWit2x-fork-reformatted-text-.xml +++ b/static/bitcoin-dev/Oct_2017/combined_New-difficulty-algorithm-needed-for-SegWit2x-fork-reformatted-text-.xml @@ -1,35 +1,51 @@ - + 2 Combined summary - New difficulty algorithm needed for SegWit2x fork? (reformatted text) - 2023-08-01T22:01:33.815546+00:00 - - Scott Roberts 2017-10-12 08:51:33+00:00 - - - Moral Agent 2017-10-11 15:28:08+00:00 - - - Mark Friedenbach 2017-10-11 04:08:52+00:00 - - - ZmnSCPxj 2017-10-11 02:48:13+00:00 - - - Ben Kloester 2017-10-11 01:44:52+00:00 - - - greg misiorek 2017-10-10 10:34:35+00:00 - - - Ben Kloester 2017-10-10 02:57:23+00:00 - - - Mark Friedenbach 2017-10-10 02:19:11+00:00 - - - Scott Roberts 2017-10-09 22:57:32+00:00 - + 2025-09-26T15:32:01.742226+00:00 + python-feedgen + + + [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text) Scott Roberts + 2017-10-09T22:57:00.000Z + + + Mark Friedenbach + 2017-10-10T02:19:00.000Z + + + Ben Kloester + 2017-10-10T02:57:00.000Z + + + greg misiorek + 2017-10-10T10:34:00.000Z + + + Scott Roberts + 2017-10-11T01:29:00.000Z + + + Ben Kloester + 2017-10-11T01:44:00.000Z + + + ZmnSCPxj + 2017-10-11T02:48:00.000Z + + + Mark Friedenbach + 2017-10-11T04:08:00.000Z + + + Moral Agent + 2017-10-11T15:28:00.000Z + + + Scott Roberts + 2017-10-12T08:51:00.000Z + + @@ -39,13 +55,13 @@ - python-feedgen + 2 Combined summary - New difficulty algorithm needed for SegWit2x fork? (reformatted text) - 2023-08-01T22:01:33.816546+00:00 + 2025-09-26T15:32:01.743497+00:00 - In the provided context, it is mentioned that the author made a post and received no arguments against it. As a result, they decided to work on a Bitcoin Improvement Proposal (BIP). The specific details of the original post or the content of the BIP are not provided. An HTML file is attached, but its contents remain unknown.The main issue discussed is the difficulty adjustment algorithm in Bitcoin. It is stated that this algorithm creates a problem where hashpower does not align with user interests. While changing the algorithm may improve functionality, it does not address the underlying problem. If this incentive problem remains unsolved and Bitcoin faces a hashpower attack, the project could fail. However, developers can publish a contingency plan, such as an emergency hard fork to a different retarget algorithm, to mitigate this risk. This hard fork would require broad consensus and could signal to miners that the legacy chain will react and survive. Although an emergency hard fork carries risks, it may be worth considering depending on the scenario in November.A proposal suggesting the deployment of a hard fork to Bitcoin in the event of a 51% attack is deemed unhelpful. This would create two altcoins competing for hashpower instead of one. The main issue of hashpower not aligning with users' interests would still persist. The value proposition of Bitcoin is based on economic incentives creating a secure trustless ledger, and if these incentives fail, the experiment fails. Rushed and poorly reviewed hard forks like B2X should not be repeated, and future hard forks should undergo thorough expert and community review. The proposed solution to the miner's profit-seeking behavior without considering security, users, and nodes is a hard fork with a new difficulty algorithm. This algorithm uses a simple rolling average with a smaller window and adjusts the reward based on recent solvetimes to encourage more mining or slow it down if necessary. However, this proposal requires peer review before implementation.The writer explains that there is a practical limit to the number of blocks that can be orphaned even under a 51% attack. The value of tokens solely on the 2X chain would not be as high as those on the Core chain, incentivizing miners to acquire tokens on the Core chain. In hardfork situations, hodlers have more power than miners due to economic disincentives for mining on the 2X chain. Switching to Bitcoin Cash (BCH) is also unattractive as its value is lower than BT2 tokens. Changing difficulty algorithms can have negative effects on chain security. Instead, it is suggested to let the market determine the fate of 2X without responding with a hard fork. Changes like difficulty adjustment, proof-of-work change, or block size should not be made in response to a contentious hard fork. If the Core chain fails, then Bitcoin as a whole has failed, and hodlers are advised to sell their holdings and find other sources of amusement.In an email exchange on the Bitcoin-dev mailing list, Scott Roberts proposed a new difficulty algorithm to address issues related to miners prioritizing maximum profit over security, users, and nodes. The proposal suggests a hard fork to implement a new difficulty algorithm using a simple rolling average with a smaller window. The reward would be adjusted based on recent solvetimes to encourage or slow down mining accordingly. However, Mark Friedenbach disagrees with creating a contingency plan for the incumbent chain under a 51% attack, considering it rushed and hypocritical. He suggests reframing the proposal as a hardfork wishlist research problem for a properly planned hard fork in the future. The email recommends discussing this topic in the hardfork research group for better accommodation.The bitcoin difficulty algorithm is highlighted as a problem that could lead to the minority chain becoming the "better" coin. Hard forks should not be rushed and require extensive expert and community review. The hardfork research group is suggested as a more suitable venue for discussion on this topic. A new difficulty algorithm proposal is presented, utilizing a simple rolling average with a smaller window. This approach has been implemented by many small coins to prevent sudden departure of big miners, leaving constant miners with high difficulty. The proposed algorithm is deemed faster, simpler, and better than any other known difficulty algorithm.The email thread on the Bitcoin-dev mailing list focuses on a contingency plan in case the incumbent chain following Bitcoin Core consensus rules is subjected to a 51% attack. The proposal suggests a hard fork to implement a new difficulty algorithm using a simple rolling average with a smaller window. The reward would be adjusted based on recent solvetimes to maintain the coin issuance rate on schedule. However, concerns are raised about the technical merits of the proposal and the rush to implement it through a poorly reviewed hard fork. It is suggested that this proposal be reframed as a research problem for a future properly planned hard fork. The hardfork research group is recommended as a more appropriate venue for further discussion. There is also a mention of Luke's work on BitcoinHardfork, but its 2017-10-12T08:51:33+00:00 + In the provided context, it is mentioned that the author made a post and received no arguments against it. As a result, they decided to work on a Bitcoin Improvement Proposal (BIP). The specific details of the original post or the content of the BIP are not provided. An HTML file is attached, but its contents remain unknown.The main issue discussed is the difficulty adjustment algorithm in Bitcoin. It is stated that this algorithm creates a problem where hashpower does not align with user interests. While changing the algorithm may improve functionality, it does not address the underlying problem. If this incentive problem remains unsolved and Bitcoin faces a hashpower attack, the project could fail. However, developers can publish a contingency plan, such as an emergency hard fork to a different retarget algorithm, to mitigate this risk. This hard fork would require broad consensus and could signal to miners that the legacy chain will react and survive. Although an emergency hard fork carries risks, it may be worth considering depending on the scenario in November.A proposal suggesting the deployment of a hard fork to Bitcoin in the event of a 51% attack is deemed unhelpful. This would create two altcoins competing for hashpower instead of one. The main issue of hashpower not aligning with users' interests would still persist. The value proposition of Bitcoin is based on economic incentives creating a secure trustless ledger, and if these incentives fail, the experiment fails. Rushed and poorly reviewed hard forks like B2X should not be repeated, and future hard forks should undergo thorough expert and community review. The proposed solution to the miner's profit-seeking behavior without considering security, users, and nodes is a hard fork with a new difficulty algorithm. This algorithm uses a simple rolling average with a smaller window and adjusts the reward based on recent solvetimes to encourage more mining or slow it down if necessary. However, this proposal requires peer review before implementation.The writer explains that there is a practical limit to the number of blocks that can be orphaned even under a 51% attack. The value of tokens solely on the 2X chain would not be as high as those on the Core chain, incentivizing miners to acquire tokens on the Core chain. In hardfork situations, hodlers have more power than miners due to economic disincentives for mining on the 2X chain. Switching to Bitcoin Cash (BCH) is also unattractive as its value is lower than BT2 tokens. Changing difficulty algorithms can have negative effects on chain security. Instead, it is suggested to let the market determine the fate of 2X without responding with a hard fork. Changes like difficulty adjustment, proof-of-work change, or block size should not be made in response to a contentious hard fork. If the Core chain fails, then Bitcoin as a whole has failed, and hodlers are advised to sell their holdings and find other sources of amusement.In an email exchange on the Bitcoin-dev mailing list, Scott Roberts proposed a new difficulty algorithm to address issues related to miners prioritizing maximum profit over security, users, and nodes. The proposal suggests a hard fork to implement a new difficulty algorithm using a simple rolling average with a smaller window. The reward would be adjusted based on recent solvetimes to encourage or slow down mining accordingly. However, Mark Friedenbach disagrees with creating a contingency plan for the incumbent chain under a 51% attack, considering it rushed and hypocritical. He suggests reframing the proposal as a hardfork wishlist research problem for a properly planned hard fork in the future. The email recommends discussing this topic in the hardfork research group for better accommodation.The bitcoin difficulty algorithm is highlighted as a problem that could lead to the minority chain becoming the "better" coin. Hard forks should not be rushed and require extensive expert and community review. The hardfork research group is suggested as a more suitable venue for discussion on this topic. A new difficulty algorithm proposal is presented, utilizing a simple rolling average with a smaller window. This approach has been implemented by many small coins to prevent sudden departure of big miners, leaving constant miners with high difficulty. The proposed algorithm is deemed faster, simpler, and better than any other known difficulty algorithm.The email thread on the Bitcoin-dev mailing list focuses on a contingency plan in case the incumbent chain following Bitcoin Core consensus rules is subjected to a 51% attack. The proposal suggests a hard fork to implement a new difficulty algorithm using a simple rolling average with a smaller window. The reward would be adjusted based on recent solvetimes to maintain the coin issuance rate on schedule. However, concerns are raised about the technical merits of the proposal and the rush to implement it through a poorly reviewed hard fork. It is suggested that this proposal be reframed as a research problem for a future properly planned hard fork. The hardfork research group is recommended as a more appropriate venue for further discussion. There is also a mention of Luke's work on BitcoinHardfork, but its - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_New-difficulty-algorithm-part-2.xml b/static/bitcoin-dev/Oct_2017/combined_New-difficulty-algorithm-part-2.xml index b61ebd2a37..1ed50d6fe1 100644 --- a/static/bitcoin-dev/Oct_2017/combined_New-difficulty-algorithm-part-2.xml +++ b/static/bitcoin-dev/Oct_2017/combined_New-difficulty-algorithm-part-2.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - New difficulty algorithm part 2 - 2023-08-01T22:02:36.035649+00:00 - - Scott Roberts 2017-10-13 11:35:09+00:00 - - - ZmnSCPxj 2017-10-13 04:45:33+00:00 - - - Scott Roberts 2017-10-12 15:42:02+00:00 - - - Mark Friedenbach 2017-10-12 15:25:23+00:00 - - - ZmnSCPxj 2017-10-12 10:40:24+00:00 - - - Scott Roberts 2017-10-11 14:50:20+00:00 - + 2025-09-26T15:31:40.618284+00:00 + python-feedgen + + + [bitcoin-dev] New difficulty algorithm part 2 Scott Roberts + 2017-10-11T14:50:00.000Z + + + ZmnSCPxj + 2017-10-12T10:40:00.000Z + + + Mark Friedenbach + 2017-10-12T15:25:00.000Z + + + Scott Roberts + 2017-10-12T15:42:00.000Z + + + ZmnSCPxj + 2017-10-13T04:45:00.000Z + + + Scott Roberts + 2017-10-13T11:35:00.000Z + + - python-feedgen + 2 Combined summary - New difficulty algorithm part 2 - 2023-08-01T22:02:36.035649+00:00 + 2025-09-26T15:31:40.619133+00:00 - The discussion revolves around the need for a new difficulty algorithm for Bitcoin. One participant argues that slow response times indicate less intelligence and advocates for implementing a better algorithm to enhance future security. Another participant believes that a constant value should be neither inflationary nor deflationary, and determining this without a third-party index is crucial. The conversation then shifts to the impact of the BitFinex price ratio on transaction rates. It is suggested that a faster measurement of hashrate for difficulty can lead to more efficient and accurate economic determination. The roles of developers, users, hodlers, and miners in Bitcoin governance are also explored. Miners are compared to banks lobbying for higher total fees, while hodlers, who hold 90% of the coin, lobby for both security and price increases. Users prioritize stability over price fluctuations. The discussion concludes with the notion that hardforks are risky and require massive coordination efforts, making them unfeasible within a month. Off-chain methods can enable fast market determination, and developers should aim to expand the coin quantity to maintain constant value, which aligns with the five characteristics of an ideal currency.The argument is made that miners prioritize profitability and will choose the chain that yields higher rewards in fees and valued tokens. However, it is noted that all chains must follow the same difficulty adjustment, and hardforks are generally seen as dangerous. The conversation then delves into the power dynamics between developers, users, hodlers, and miners in Bitcoin governance. Hodlers, described as the new 1%, lobby for security and price increases, while miners act like banks seeking higher total fees. Users are the group developers need to protect against both hodlers and miners, focusing on stability rather than price. The idea of expanding the coin quantity to maintain value is introduced but viewed as a departure from the fixed limit nature of Bitcoin, potentially making it deflationary.ZmnSCPxj argues that miners would choose a chain providing 1 token as a fee per block, even if an unwanted chain offers 2 tokens as a fee per block. This is because the unwanted chain's tokens are valued at only 1/4 of the desired chain's tokens. However, this argument fails to consider the price for a coin capable of handling double the transactions. Some hodlers, including Roger Ver, advocate for a coin with more transactions, lower price, and lower fees per coin transferred to attract more merchants, customers, and miners. Bitcoin's consensus truth operates on the principle of "might is right," allowing buyers and sellers to shift some might to miners through fees, which can conflict with hodlers' interests in security and price increases. The importance of meeting user needs for long-term value is debated alongside the significance of mining infrastructure.The thread acknowledges that developers serve as a governing authority influenced by users, hodlers, and miners. Hodlers hold a significant portion of the coin and lobby for security while also being interested in price increases. Users, referred to as "the people," should be protected by developers from the demands of both hodlers and miners, as they do not want to pay unnecessary fees merely for their coin to dominate. The suggestion is made that developers strive for an expansion of the coin quantity to maintain constant value, aligning with the five characteristics of an ideal currency. Peaceful and sustainable forks are encouraged, enabling constant value, security, and low transaction fees per coin transfer. Forks with faster difficulty adjustments are deemed more capable of retaining value.Addressing a statement about Core developers holding vast amounts of Bitcoin and their influence over hardforks, it is clarified that there is no incentive for developers to hold more Bitcoin than others in the industry. Becoming a Bitcoin developer does not require holding Bitcoin. Numerous individuals and organizations who are not developers possess massive amounts of Bitcoin. While Core developers may have influence over Bitcoin's direction, they do not possess complete control and cannot prevent hardforks.The power dynamics between hodlers and miners in hardfork situations are discussed, with the understanding that hodlers hold more power. However, when hodlers are evenly split between coins, miners will favor the coin with higher transaction fees, potentially eroding hodler confidence and causing longer delays. Hardforks further fracture the community and should be avoided. It is emphasized that hodlers will retain held coins regardless of available transaction rate, and any hardfork going against Core's wishes may collapse due to Core developers' action as hodlers, without requiring special actions as developers.The feasibility of a hard fork in Bitcoin is debated, with the author arguing that it would not address issues like long transaction delays unless the difficulty algorithm allows price to guide hash power instead of vice versa. The author suggests that Core might need to fork to a faster responding difficulty algorithm if faced with a lower hashrate. Another participant notes that changing the difficulty adjustment algorithm does not resolve the misalignment of hashpower with users' interests. However, the author believes that minority hashrate coins 2017-10-13T11:35:09+00:00 + The discussion revolves around the need for a new difficulty algorithm for Bitcoin. One participant argues that slow response times indicate less intelligence and advocates for implementing a better algorithm to enhance future security. Another participant believes that a constant value should be neither inflationary nor deflationary, and determining this without a third-party index is crucial. The conversation then shifts to the impact of the BitFinex price ratio on transaction rates. It is suggested that a faster measurement of hashrate for difficulty can lead to more efficient and accurate economic determination. The roles of developers, users, hodlers, and miners in Bitcoin governance are also explored. Miners are compared to banks lobbying for higher total fees, while hodlers, who hold 90% of the coin, lobby for both security and price increases. Users prioritize stability over price fluctuations. The discussion concludes with the notion that hardforks are risky and require massive coordination efforts, making them unfeasible within a month. Off-chain methods can enable fast market determination, and developers should aim to expand the coin quantity to maintain constant value, which aligns with the five characteristics of an ideal currency.The argument is made that miners prioritize profitability and will choose the chain that yields higher rewards in fees and valued tokens. However, it is noted that all chains must follow the same difficulty adjustment, and hardforks are generally seen as dangerous. The conversation then delves into the power dynamics between developers, users, hodlers, and miners in Bitcoin governance. Hodlers, described as the new 1%, lobby for security and price increases, while miners act like banks seeking higher total fees. Users are the group developers need to protect against both hodlers and miners, focusing on stability rather than price. The idea of expanding the coin quantity to maintain value is introduced but viewed as a departure from the fixed limit nature of Bitcoin, potentially making it deflationary.ZmnSCPxj argues that miners would choose a chain providing 1 token as a fee per block, even if an unwanted chain offers 2 tokens as a fee per block. This is because the unwanted chain's tokens are valued at only 1/4 of the desired chain's tokens. However, this argument fails to consider the price for a coin capable of handling double the transactions. Some hodlers, including Roger Ver, advocate for a coin with more transactions, lower price, and lower fees per coin transferred to attract more merchants, customers, and miners. Bitcoin's consensus truth operates on the principle of "might is right," allowing buyers and sellers to shift some might to miners through fees, which can conflict with hodlers' interests in security and price increases. The importance of meeting user needs for long-term value is debated alongside the significance of mining infrastructure.The thread acknowledges that developers serve as a governing authority influenced by users, hodlers, and miners. Hodlers hold a significant portion of the coin and lobby for security while also being interested in price increases. Users, referred to as "the people," should be protected by developers from the demands of both hodlers and miners, as they do not want to pay unnecessary fees merely for their coin to dominate. The suggestion is made that developers strive for an expansion of the coin quantity to maintain constant value, aligning with the five characteristics of an ideal currency. Peaceful and sustainable forks are encouraged, enabling constant value, security, and low transaction fees per coin transfer. Forks with faster difficulty adjustments are deemed more capable of retaining value.Addressing a statement about Core developers holding vast amounts of Bitcoin and their influence over hardforks, it is clarified that there is no incentive for developers to hold more Bitcoin than others in the industry. Becoming a Bitcoin developer does not require holding Bitcoin. Numerous individuals and organizations who are not developers possess massive amounts of Bitcoin. While Core developers may have influence over Bitcoin's direction, they do not possess complete control and cannot prevent hardforks.The power dynamics between hodlers and miners in hardfork situations are discussed, with the understanding that hodlers hold more power. However, when hodlers are evenly split between coins, miners will favor the coin with higher transaction fees, potentially eroding hodler confidence and causing longer delays. Hardforks further fracture the community and should be avoided. It is emphasized that hodlers will retain held coins regardless of available transaction rate, and any hardfork going against Core's wishes may collapse due to Core developers' action as hodlers, without requiring special actions as developers.The feasibility of a hard fork in Bitcoin is debated, with the author arguing that it would not address issues like long transaction delays unless the difficulty algorithm allows price to guide hash power instead of vice versa. The author suggests that Core might need to fork to a faster responding difficulty algorithm if faced with a lower hashrate. Another participant notes that changing the difficulty adjustment algorithm does not resolve the misalignment of hashpower with users' interests. However, the author believes that minority hashrate coins - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_Simplicity-An-alternative-to-Script.xml b/static/bitcoin-dev/Oct_2017/combined_Simplicity-An-alternative-to-Script.xml index db539af781..94dd9b7d26 100644 --- a/static/bitcoin-dev/Oct_2017/combined_Simplicity-An-alternative-to-Script.xml +++ b/static/bitcoin-dev/Oct_2017/combined_Simplicity-An-alternative-to-Script.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Simplicity: An alternative to Script - 2023-08-01T22:04:38.991234+00:00 - - Mark Friedenbach 2017-11-01 01:46:54+00:00 - - - Russell O'Connor 2017-10-31 21:01:05+00:00 - - - Mark Friedenbach 2017-10-31 20:46:49+00:00 - - - Russell O'Connor 2017-10-31 20:38:16+00:00 - - - Gregory Maxwell 2017-10-30 23:29:28+00:00 - - - Matt Corallo 2017-10-30 22:50:04+00:00 - - - Mark Friedenbach 2017-10-30 22:32:42+00:00 - - - Matt Corallo 2017-10-30 22:14:44+00:00 - - - Mark Friedenbach 2017-10-30 21:56:00+00:00 - - - Matt Corallo 2017-10-30 21:42:44+00:00 - - - Mark Friedenbach 2017-10-30 15:31:22+00:00 - - - Russell O'Connor 2017-10-30 15:22:20+00:00 - + 2025-09-26T15:31:53.380509+00:00 + python-feedgen + + + [bitcoin-dev] Simplicity: An alternative to Script Russell O'Connor + 2017-10-30T15:22:00.000Z + + + Mark Friedenbach + 2017-10-30T15:31:00.000Z + + + Matt Corallo + 2017-10-30T21:42:00.000Z + + + Mark Friedenbach + 2017-10-30T21:56:00.000Z + + + Matt Corallo + 2017-10-30T22:14:00.000Z + + + Mark Friedenbach + 2017-10-30T22:32:00.000Z + + + Matt Corallo + 2017-10-30T22:50:00.000Z + + + Gregory Maxwell + 2017-10-30T23:29:00.000Z + + + Russell O'Connor + 2017-10-31T20:38:00.000Z + + + Mark Friedenbach + 2017-10-31T20:46:00.000Z + + + Russell O'Connor + 2017-10-31T21:01:00.000Z + + + Mark Friedenbach + 2017-11-01T01:46:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Simplicity: An alternative to Script - 2023-08-01T22:04:38.992239+00:00 + 2025-09-26T15:31:53.381893+00:00 - Russell O'Connor, a Bitcoin developer, has proposed an alternative to Bitcoin Script called Simplicity. This language is a low-level, typed, functional, native MAST language designed to operate at the consensus layer. Simplicity comes with formal denotational semantics and operational semantics that have been proven equivalent in the Coq proof assistant. The language also includes easy-to-compute static analyses that can calculate bounds on space and time resources needed for evaluation.Simplicity is still in the research and development phase, but it is anticipated that jets will replace common Simplicity expressions with C code to reduce the sigops/weight/fee-cost of transactions. These jets will cover arithmetic operations, elliptic curve operations, and cryptographic operations including hashing and digital signature validation. The final design of Simplicity includes full convent support, support for signature aggregation, and support for delegation.The author plans to develop a broad set of useful jets covering arithmetic operations, elliptic curve operations, and cryptographic operations. Simplicity's denotational semantics do not imply an order of operations, but the author plans to address this by using Luke's fail-success-on-unknown-operation. The language also includes extensions such as full convent support, signature aggregation, and delegation.The author is working on producing an SDK that will include formal semantics, correctness proofs, a Haskell implementation, and a C interpreter for Simplicity. After the SDK is complete, Simplicity will be made available in the Elements project for experimentation in sidechains. However, it will only be considered for inclusion in Bitcoin after extensive vetting.In a recent bitcoin-dev email thread, there were discussions about how to deal with "jets" in Bitcoin. One proposal suggested using discounted jets for scripting. Another proposal suggested using script versions to encode optimized jets and their costs. These proposals are independent of Simplicity but can be applied to it.Overall, Simplicity is a promising alternative to Bitcoin Script, offering a low-level, typed, functional, and native MAST language with formal denotational and operational semantics. It aims to enhance privacy and reduce resource costs through branch pruning and the use of jets. The author is actively working on developing the language further and plans to make it available for experimentation in sidechains. However, more research and vetting are needed before considering Simplicity for inclusion in Bitcoin. O'Connor emphasized that this work is not intended to delay consideration of the various Merkelized Script proposals currently ongoing. 2017-11-01T01:46:54+00:00 + Russell O'Connor, a Bitcoin developer, has proposed an alternative to Bitcoin Script called Simplicity. This language is a low-level, typed, functional, native MAST language designed to operate at the consensus layer. Simplicity comes with formal denotational semantics and operational semantics that have been proven equivalent in the Coq proof assistant. The language also includes easy-to-compute static analyses that can calculate bounds on space and time resources needed for evaluation.Simplicity is still in the research and development phase, but it is anticipated that jets will replace common Simplicity expressions with C code to reduce the sigops/weight/fee-cost of transactions. These jets will cover arithmetic operations, elliptic curve operations, and cryptographic operations including hashing and digital signature validation. The final design of Simplicity includes full convent support, support for signature aggregation, and support for delegation.The author plans to develop a broad set of useful jets covering arithmetic operations, elliptic curve operations, and cryptographic operations. Simplicity's denotational semantics do not imply an order of operations, but the author plans to address this by using Luke's fail-success-on-unknown-operation. The language also includes extensions such as full convent support, signature aggregation, and delegation.The author is working on producing an SDK that will include formal semantics, correctness proofs, a Haskell implementation, and a C interpreter for Simplicity. After the SDK is complete, Simplicity will be made available in the Elements project for experimentation in sidechains. However, it will only be considered for inclusion in Bitcoin after extensive vetting.In a recent bitcoin-dev email thread, there were discussions about how to deal with "jets" in Bitcoin. One proposal suggested using discounted jets for scripting. Another proposal suggested using script versions to encode optimized jets and their costs. These proposals are independent of Simplicity but can be applied to it.Overall, Simplicity is a promising alternative to Bitcoin Script, offering a low-level, typed, functional, and native MAST language with formal denotational and operational semantics. It aims to enhance privacy and reduce resource costs through branch pruning and the use of jets. The author is actively working on developing the language further and plans to make it available for experimentation in sidechains. However, more research and vetting are needed before considering Simplicity for inclusion in Bitcoin. O'Connor emphasized that this work is not intended to delay consideration of the various Merkelized Script proposals currently ongoing. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_Version-1-witness-programs-first-draft-.xml b/static/bitcoin-dev/Oct_2017/combined_Version-1-witness-programs-first-draft-.xml index 771ab3b915..37c36d25dd 100644 --- a/static/bitcoin-dev/Oct_2017/combined_Version-1-witness-programs-first-draft-.xml +++ b/static/bitcoin-dev/Oct_2017/combined_Version-1-witness-programs-first-draft-.xml @@ -1,68 +1,91 @@ - + 2 Combined summary - Version 1 witness programs (first draft) - 2023-08-01T22:00:48.925704+00:00 - - Russell O'Connor 2017-10-05 21:28:48+00:00 - - - Mark Friedenbach 2017-10-05 20:33:56+00:00 - - - Russell O'Connor 2017-10-02 20:38:49+00:00 - - - Sjors Provoost 2017-10-02 09:09:00+00:00 - - - Luke Dashjr 2017-10-02 02:56:27+00:00 - - - Luke Dashjr 2017-10-02 00:45:22+00:00 - - - Mark Friedenbach 2017-10-02 00:35:38+00:00 - - - Johnson Lau 2017-10-01 21:32:56+00:00 - - - Luke Dashjr 2017-10-01 20:43:18+00:00 - - - Mark Friedenbach 2017-10-01 20:39:11+00:00 - - - Russell O'Connor 2017-10-01 19:41:46+00:00 - - - Mark Friedenbach 2017-10-01 19:27:21+00:00 - - - Russell O'Connor 2017-10-01 19:05:38+00:00 - - - Mark Friedenbach 2017-10-01 18:34:07+00:00 - - - Luke Dashjr 2017-10-01 17:36:05+00:00 - - - Felix Weis 2017-10-01 11:22:30+00:00 - - - Mark Friedenbach 2017-10-01 05:04:32+00:00 - - - Luke Dashjr 2017-10-01 02:47:41+00:00 - - - Mark Friedenbach 2017-10-01 02:23:47+00:00 - - - Luke Dashjr 2017-10-01 01:13:29+00:00 - + 2025-09-26T15:31:44.842946+00:00 + python-feedgen + + + [bitcoin-dev] Version 1 witness programs (first draft) Luke Dashjr + 2017-10-01T01:13:00.000Z + + + Mark Friedenbach + 2017-10-01T02:23:00.000Z + + + Luke Dashjr + 2017-10-01T02:47:00.000Z + + + Mark Friedenbach + 2017-10-01T05:04:00.000Z + + + Felix Weis + 2017-10-01T11:22:00.000Z + + + Luke Dashjr + 2017-10-01T17:36:00.000Z + + + Mark Friedenbach + 2017-10-01T18:34:00.000Z + + + Russell O'Connor + 2017-10-01T19:05:00.000Z + + + Mark Friedenbach + 2017-10-01T19:27:00.000Z + + + Russell O'Connor + 2017-10-01T19:41:00.000Z + + + Mark Friedenbach + 2017-10-01T20:39:00.000Z + + + Luke Dashjr + 2017-10-01T20:43:00.000Z + + + Johnson Lau + 2017-10-01T21:32:00.000Z + + + Mark Friedenbach + 2017-10-02T00:35:00.000Z + + + Luke Dashjr + 2017-10-02T00:45:00.000Z + + + Luke Dashjr + 2017-10-02T02:56:00.000Z + + + Sjors Provoost + 2017-10-02T09:09:00.000Z + + + Russell O'Connor + 2017-10-02T20:38:00.000Z + + + Mark Friedenbach + 2017-10-05T20:33:00.000Z + + + Russell O'Connor + 2017-10-05T21:28:00.000Z + + @@ -83,13 +106,13 @@ - python-feedgen + 2 Combined summary - Version 1 witness programs (first draft) - 2023-08-01T22:00:48.926705+00:00 + 2025-09-26T15:31:44.845071+00:00 - The email conversation among Bitcoin developers revolves around potential changes to the signature format and Bitcoin scripting. Mark Friedenbach clarifies that an idea proposed by Johnson Lau belongs to Lau and suggests it is uncontroversial. Luke Dashjr proposes a first draft for Segwit and Bitcoin scripting, introducing five changes including a new witness version, eliminating the need to guess signature size, allowing signatures to commit to additional conditions, interpreting the final stack element as a tail-call Script, and making undefined opcodes exit the script with success. Russell O'Connor suggests replacing the requirement in CHECKMULTISIG with a bitfield specifying which pubkeys are used.Friedenbach suggests using script execution flags based on script versions to gate new behavior instead of OP_RETURNTRUE or generalized NOP method. This suggestion breaks parallel soft-fork deployments. Luke Dashjr proposes two new options for BIP114 but later changes his mind. Friedenbach suggests gating new behavior based on script execution flags set by the script version, which also breaks parallel softfork deployments. They discuss allowing signature-time commitment of extra scripts through tail-call semantics, scriptWitCode, or extra-data as script in OP_CHECKSIG. They emphasize the need for planning the overall design/layout in advance.Johnson Lau and Luke Dashjr discuss various options for allowing further upgrades within v1 witness, including using a minor version in the witness with OP_RETURNTRUE as a fallback. They suggest proposing these as their own script updates instead of creating a complex overhaul. They also address whether to allow static analysis of sigop and how it can be done.The email thread discusses three proposals with similar goals but different designs. The first proposal suggests allowing further upgrades within v1 witness using minor versions. The second proposal suggests using OP_RETURNTRUE, but it is unfit for signature aggregation. The third proposal suggests using the generalized NOP method, but it raises issues with VERIFY-type code. Instead, the email suggests gating new behavior based on script execution flags set by the script version. The email also addresses whether to allow signature-time commitment of extra scripts and whether to allow static analysis of sigop.Friedenbach proposes incorporating an optional commitment to witness size in bytes using SIGHASH_WITNESS_SIZE. Script validation flags can prevent malleability issues, but they were not made consensus rules with Segwit v0 due to concerns over scope creep. Friedenbach discusses creating a SIGHASH_WITNESS_WEIGHT flag instead of SIGHASH_WITNESS_DEPTH. O'Connor argues that requiring a counterparty to choose their keys before signing is reasonable in multi-party signing of inputs.The Bitcoin developer community discusses potential changes to the signature format, including easy implementation of cross chain replay protection in future hard forks and eliminating the clean stack consensus requirement. Luke Dashjr proposes a draft for Segwit and Bitcoin scripting with key changes such as introducing minor versions for witnesses, undefined opcodes causing the script to exit with success, a shorter fixed-length signature format, and signatures committing to additional conditions. However, there are still unresolved issues regarding the commitment of the signature to script interpreter flags and internal "sigversion".Luke Dashjr's draft aims to simplify scripting by introducing minor versions for witnesses, allowing undefined opcodes to cause the script to exit with success, and enabling signatures to commit to additional conditions. The CLEANSTACK rule would be eliminated, and the number of items on the stack would be included in the signature hash. There is still an issue regarding the commitment of the signature to the script interpreter flags and internal "sigversion" that needs resolution.Luke Dashjr shares a first draft for potential changes to Segwit and Bitcoin scripting, including minor versions for witnesses, causing the script to exit with success when encountering undefined opcodes, executing a tail-call Script if the final stack element is not true or false, and implementing a new fixed-length signature format. The proposal aims to address replay protection concerns with OP_CHECKBLOCKATHEIGHT (BIP 115). However, the commitment of the signature to script interpreter flags and internal "sigversion" remains a complex issue that needs resolution. Feedback is sought from the community.The email conversation and proposals among Bitcoin developers focus on potential changes to the signature format to enhance flexibility and compatibility with future hard forks. Ideas explored include cross chain replay protection, elimination of the clean stack consensus requirement, and inclusion of the number of witness elements in the signature hash. Luke Dashjr's draft proposes specific changes, but there are unresolved issues that need resolution before deployment. Continuous feedback from the community is encouraged. 2017-10-05T21:28:48+00:00 + The email conversation among Bitcoin developers revolves around potential changes to the signature format and Bitcoin scripting. Mark Friedenbach clarifies that an idea proposed by Johnson Lau belongs to Lau and suggests it is uncontroversial. Luke Dashjr proposes a first draft for Segwit and Bitcoin scripting, introducing five changes including a new witness version, eliminating the need to guess signature size, allowing signatures to commit to additional conditions, interpreting the final stack element as a tail-call Script, and making undefined opcodes exit the script with success. Russell O'Connor suggests replacing the requirement in CHECKMULTISIG with a bitfield specifying which pubkeys are used.Friedenbach suggests using script execution flags based on script versions to gate new behavior instead of OP_RETURNTRUE or generalized NOP method. This suggestion breaks parallel soft-fork deployments. Luke Dashjr proposes two new options for BIP114 but later changes his mind. Friedenbach suggests gating new behavior based on script execution flags set by the script version, which also breaks parallel softfork deployments. They discuss allowing signature-time commitment of extra scripts through tail-call semantics, scriptWitCode, or extra-data as script in OP_CHECKSIG. They emphasize the need for planning the overall design/layout in advance.Johnson Lau and Luke Dashjr discuss various options for allowing further upgrades within v1 witness, including using a minor version in the witness with OP_RETURNTRUE as a fallback. They suggest proposing these as their own script updates instead of creating a complex overhaul. They also address whether to allow static analysis of sigop and how it can be done.The email thread discusses three proposals with similar goals but different designs. The first proposal suggests allowing further upgrades within v1 witness using minor versions. The second proposal suggests using OP_RETURNTRUE, but it is unfit for signature aggregation. The third proposal suggests using the generalized NOP method, but it raises issues with VERIFY-type code. Instead, the email suggests gating new behavior based on script execution flags set by the script version. The email also addresses whether to allow signature-time commitment of extra scripts and whether to allow static analysis of sigop.Friedenbach proposes incorporating an optional commitment to witness size in bytes using SIGHASH_WITNESS_SIZE. Script validation flags can prevent malleability issues, but they were not made consensus rules with Segwit v0 due to concerns over scope creep. Friedenbach discusses creating a SIGHASH_WITNESS_WEIGHT flag instead of SIGHASH_WITNESS_DEPTH. O'Connor argues that requiring a counterparty to choose their keys before signing is reasonable in multi-party signing of inputs.The Bitcoin developer community discusses potential changes to the signature format, including easy implementation of cross chain replay protection in future hard forks and eliminating the clean stack consensus requirement. Luke Dashjr proposes a draft for Segwit and Bitcoin scripting with key changes such as introducing minor versions for witnesses, undefined opcodes causing the script to exit with success, a shorter fixed-length signature format, and signatures committing to additional conditions. However, there are still unresolved issues regarding the commitment of the signature to script interpreter flags and internal "sigversion".Luke Dashjr's draft aims to simplify scripting by introducing minor versions for witnesses, allowing undefined opcodes to cause the script to exit with success, and enabling signatures to commit to additional conditions. The CLEANSTACK rule would be eliminated, and the number of items on the stack would be included in the signature hash. There is still an issue regarding the commitment of the signature to the script interpreter flags and internal "sigversion" that needs resolution.Luke Dashjr shares a first draft for potential changes to Segwit and Bitcoin scripting, including minor versions for witnesses, causing the script to exit with success when encountering undefined opcodes, executing a tail-call Script if the final stack element is not true or false, and implementing a new fixed-length signature format. The proposal aims to address replay protection concerns with OP_CHECKBLOCKATHEIGHT (BIP 115). However, the commitment of the signature to script interpreter flags and internal "sigversion" remains a complex issue that needs resolution. Feedback is sought from the community.The email conversation and proposals among Bitcoin developers focus on potential changes to the signature format to enhance flexibility and compatibility with future hard forks. Ideas explored include cross chain replay protection, elimination of the clean stack consensus requirement, and inclusion of the number of witness elements in the signature hash. Luke Dashjr's draft proposes specific changes, but there are unresolved issues that need resolution before deployment. Continuous feedback from the community is encouraged. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_Visually-Differentiable-Bitcoin-Addresses.xml b/static/bitcoin-dev/Oct_2017/combined_Visually-Differentiable-Bitcoin-Addresses.xml index 509d5ebf42..b622ebb2a6 100644 --- a/static/bitcoin-dev/Oct_2017/combined_Visually-Differentiable-Bitcoin-Addresses.xml +++ b/static/bitcoin-dev/Oct_2017/combined_Visually-Differentiable-Bitcoin-Addresses.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Visually Differentiable - Bitcoin Addresses - 2023-08-01T22:03:52.434803+00:00 - - Moral Agent 2017-10-30 16:48:09+00:00 - - - Danny Thorpe 2017-10-30 16:15:45+00:00 - - - Moral Agent 2017-10-30 14:39:07+00:00 - - - Pieter Wuille 2017-10-30 14:26:29+00:00 - - - Ben Thompson 2017-10-30 14:23:51+00:00 - - - shiva sitamraju 2017-10-30 13:13:56+00:00 - - - Ben Thompson 2017-10-30 12:49:18+00:00 - - - Ricardo Filipe 2017-10-30 12:14:42+00:00 - - - shiva sitamraju 2017-10-30 08:56:40+00:00 - + 2025-09-26T15:31:42.729243+00:00 + python-feedgen + + + [bitcoin-dev] Visually Differentiable - Bitcoin Addresses shiva sitamraju + 2017-10-30T08:56:00.000Z + + + Ricardo Filipe + 2017-10-30T12:14:00.000Z + + + Ben Thompson + 2017-10-30T12:49:00.000Z + + + shiva sitamraju + 2017-10-30T13:13:00.000Z + + + Ben Thompson + 2017-10-30T14:23:00.000Z + + + Pieter Wuille + 2017-10-30T14:26:00.000Z + + + Moral Agent + 2017-10-30T14:39:00.000Z + + + Danny Thorpe + 2017-10-30T16:15:00.000Z + + + Moral Agent + 2017-10-30T16:48:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Visually Differentiable - Bitcoin Addresses - 2023-08-01T22:03:52.434803+00:00 + 2025-09-26T15:31:42.730283+00:00 - The bitcoin-dev mailing list recently discussed the usability and verification of bitcoin addresses. One suggestion was to map a 25-byte address to 16 words from a 6000-word list for easier human verification. It was emphasized that any small change in the input should produce a significantly different output to ensure security. The idea of displaying the 16 words in a 4 x 4 grid with no visual distractions was recommended. Additionally, grinding an address with enough zeros at the beginning to be expressed by fewer words was proposed for higher security keys.The use of images to verify addresses was also explored, but it was noted that our visual processing system may unconsciously "correct" visual input, making it unreliable. Generating an image based on the bytes of an address was suggested, but it was acknowledged that even small changes to the text input would result in significantly different images, which may not be practical for verification purposes.One specific concern raised was the lack of visual distinction in the Bech32 address format. With traditional addresses, users could visually compare the first few bytes, such as "1Ko" or "1L3." However, with Bech32 addresses, only the "bc1." prefix is visible, making it difficult to differentiate between addresses visually. This can lead to errors when copying addresses and detecting rogue software that alters the address.On the bitcoin-dev mailing list, Shiva Sitamraju highlighted the usability problems caused by long addresses in block explorers, mobiles, and payment terminals. Ben Thompson added that checking only the first few bytes of a bitcoin address is insufficient to ensure its correctness, as vanity addresses matching the initial characters can be generated quickly. Moral Agent suggested mapping 25-byte addresses to a 16-word list for easier verification, while Danny proposed generating images based on the address bytes using identicon.The discussion focused on improving the visual distinctiveness of bitcoin addresses to facilitate easier verification and use. It was noted that the length of some addresses, particularly Bech32 addresses, can create usability challenges. Users expressed the need for visually distinct first few bytes in order to verify addresses accurately. However, no specific solutions were proposed during the discussion. The importance of address verification in ensuring secure and accurate bitcoin transactions was emphasized throughout the conversation. 2017-10-30T16:48:09+00:00 + The bitcoin-dev mailing list recently discussed the usability and verification of bitcoin addresses. One suggestion was to map a 25-byte address to 16 words from a 6000-word list for easier human verification. It was emphasized that any small change in the input should produce a significantly different output to ensure security. The idea of displaying the 16 words in a 4 x 4 grid with no visual distractions was recommended. Additionally, grinding an address with enough zeros at the beginning to be expressed by fewer words was proposed for higher security keys.The use of images to verify addresses was also explored, but it was noted that our visual processing system may unconsciously "correct" visual input, making it unreliable. Generating an image based on the bytes of an address was suggested, but it was acknowledged that even small changes to the text input would result in significantly different images, which may not be practical for verification purposes.One specific concern raised was the lack of visual distinction in the Bech32 address format. With traditional addresses, users could visually compare the first few bytes, such as "1Ko" or "1L3." However, with Bech32 addresses, only the "bc1." prefix is visible, making it difficult to differentiate between addresses visually. This can lead to errors when copying addresses and detecting rogue software that alters the address.On the bitcoin-dev mailing list, Shiva Sitamraju highlighted the usability problems caused by long addresses in block explorers, mobiles, and payment terminals. Ben Thompson added that checking only the first few bytes of a bitcoin address is insufficient to ensure its correctness, as vanity addresses matching the initial characters can be generated quickly. Moral Agent suggested mapping 25-byte addresses to a 16-word list for easier verification, while Danny proposed generating images based on the address bytes using identicon.The discussion focused on improving the visual distinctiveness of bitcoin addresses to facilitate easier verification and use. It was noted that the length of some addresses, particularly Bech32 addresses, can create usability challenges. Users expressed the need for visually distinct first few bytes in order to verify addresses accurately. However, no specific solutions were proposed during the discussion. The importance of address verification in ensuring secure and accurate bitcoin transactions was emphasized throughout the conversation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-21.xml b/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-21.xml index 43c973f70c..31d767fec3 100644 --- a/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-21.xml +++ b/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-21.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-dev Digest, Vol 29, Issue 21 - 2023-08-01T22:02:51.308029+00:00 + 2025-09-26T15:31:51.264700+00:00 + python-feedgen Scott Roberts 2017-10-13 13:57:33+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - bitcoin-dev Digest, Vol 29, Issue 21 - 2023-08-01T22:02:51.308029+00:00 + 2025-09-26T15:31:51.264844+00:00 - The email conversation on the Bitcoin-dev mailing list covers a wide range of topics related to Bitcoin. One important topic discussed is the relationship between mining infrastructure and the price of Bitcoin. ZmnSCPxj argues that mining follows price, while Ilansky believes the opposite. However, it is noted that biases away from ZmnSCPxj's viewpoint reveal the need for a more responsive difficulty algorithm.The discussion then turns to the possibility of a fork clone using a faster difficulty to attack Bitcoin's slow difficulty if it reaches a comparable price. This would lower the value of Bitcoin until it forks to fix the difficulty. It is emphasized that hardforks require massive coordination efforts that cannot be feasibly done within a month. The current price ratio suggests that there is no immediate need for a new difficulty algorithm.The email conversation also explores the deflationary nature of Bitcoin and the potential for it to become a constant value coin. The role of good developers in determining the long-term value of Bitcoin is highlighted, along with the importance of miners, hodlers, and users. The idea of using a faster responding difficulty to prevent miners from bullying smaller coins is discussed, but the risks of hardforks are also acknowledged.Lastly, the debate centers on whether increasing the quantity of the coin is necessary to maintain a constant value and the potential economic distortions this may cause. It is argued that expanding the coin quantity is needed to keep the value constant, which goes against the conception of Bitcoin as having a fixed limit and becoming deflationary. However, it is noted that hardforks require significant coordination efforts and that fewer back-incompatible changes to a coin are generally preferable.Overall, the email conversation provides valuable insights into various factors that impact Bitcoin's ecosystem and its future trajectory. The discussion touches on mining infrastructure, difficulty algorithms, deflationary qualities, the role of developers, and the implications of expanding the coin quantity. 2017-10-13T13:57:33+00:00 + The email conversation on the Bitcoin-dev mailing list covers a wide range of topics related to Bitcoin. One important topic discussed is the relationship between mining infrastructure and the price of Bitcoin. ZmnSCPxj argues that mining follows price, while Ilansky believes the opposite. However, it is noted that biases away from ZmnSCPxj's viewpoint reveal the need for a more responsive difficulty algorithm.The discussion then turns to the possibility of a fork clone using a faster difficulty to attack Bitcoin's slow difficulty if it reaches a comparable price. This would lower the value of Bitcoin until it forks to fix the difficulty. It is emphasized that hardforks require massive coordination efforts that cannot be feasibly done within a month. The current price ratio suggests that there is no immediate need for a new difficulty algorithm.The email conversation also explores the deflationary nature of Bitcoin and the potential for it to become a constant value coin. The role of good developers in determining the long-term value of Bitcoin is highlighted, along with the importance of miners, hodlers, and users. The idea of using a faster responding difficulty to prevent miners from bullying smaller coins is discussed, but the risks of hardforks are also acknowledged.Lastly, the debate centers on whether increasing the quantity of the coin is necessary to maintain a constant value and the potential economic distortions this may cause. It is argued that expanding the coin quantity is needed to keep the value constant, which goes against the conception of Bitcoin as having a fixed limit and becoming deflationary. However, it is noted that hardforks require significant coordination efforts and that fewer back-incompatible changes to a coin are generally preferable.Overall, the email conversation provides valuable insights into various factors that impact Bitcoin's ecosystem and its future trajectory. The discussion touches on mining infrastructure, difficulty algorithms, deflationary qualities, the role of developers, and the implications of expanding the coin quantity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-24.xml b/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-24.xml index a64b0e319d..03c797ac91 100644 --- a/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-24.xml +++ b/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-24.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-dev Digest, Vol 29, Issue 24 - 2023-08-01T22:03:22.176465+00:00 + 2025-09-26T15:31:49.153981+00:00 + python-feedgen Mark Friedenbach 2017-10-20 18:55:55+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - bitcoin-dev Digest, Vol 29, Issue 24 - 2023-08-01T22:03:22.176465+00:00 + 2025-09-26T15:31:49.154135+00:00 - The bitcoin-dev mailing list is currently discussing the possibility of decreasing the block time for Bitcoin in order to improve scalability. The current block time of ten minutes was chosen by Satoshi as a compromise between confirmation time and wasted work due to chain splits. However, with advancements in technology and the absence of a precise formula to determine the optimal rate, there is speculation about whether the block time could be reduced further.While shorter block times would result in more chain splits, it may be possible to go lower than ten minutes without significant issues. It is important to note that reducing the block interval comes with several centralizing downsides. One concern is the potential for reduced security due to a high stale rate. When blocks take time to propagate through the network, if one miner mines a block while another miner simultaneously mines a different block before the first block propagates, the second block becomes wasted and does not contribute to network security. This issue is compounded when the block interval is short enough for the stale rate to be high. Additionally, there is a risk of centralization where mining pools with more hash power have a higher chance of producing stale blocks. This means that blockchains producing blocks quickly are likely to give one mining pool de facto control over the mining process.Another consideration when reducing the block time is the need to decrease the block size accordingly. In a hypothetical scenario with a five-minute block time, there would be twice the block space available for miners to include transactions. This could lead to the blockchain growing at a faster rate, which is detrimental to decentralization. Furthermore, reducing the block time may cause transaction fees to decrease, making it cheaper for spammers to bloat the UTXO (Unspent Transaction Output) sets.There have been various proposals to address the downsides of faster blocks, with one notable suggestion being the "Greedy Heaviest Observed Subtree" (GHOST) protocol. This protocol aims to overcome the security and centralization concerns associated with reducing block time. Additionally, it is worth mentioning that the Lightning teams have made significant progress in point-of-sale support, providing an alternative solution to scalability.While the goal for Bitcoin may be to eventually achieve a block time of one second or less, current technology is not yet developed enough to support this level of speed due to the limitations imposed by the speed of light. However, there have been efforts to mitigate potential issues, such as the development of a script to prevent a "sybil attack" from 2x. The efficacy and ethical implications of this script are subjects of debate within the community. 2017-10-20T18:55:55+00:00 + The bitcoin-dev mailing list is currently discussing the possibility of decreasing the block time for Bitcoin in order to improve scalability. The current block time of ten minutes was chosen by Satoshi as a compromise between confirmation time and wasted work due to chain splits. However, with advancements in technology and the absence of a precise formula to determine the optimal rate, there is speculation about whether the block time could be reduced further.While shorter block times would result in more chain splits, it may be possible to go lower than ten minutes without significant issues. It is important to note that reducing the block interval comes with several centralizing downsides. One concern is the potential for reduced security due to a high stale rate. When blocks take time to propagate through the network, if one miner mines a block while another miner simultaneously mines a different block before the first block propagates, the second block becomes wasted and does not contribute to network security. This issue is compounded when the block interval is short enough for the stale rate to be high. Additionally, there is a risk of centralization where mining pools with more hash power have a higher chance of producing stale blocks. This means that blockchains producing blocks quickly are likely to give one mining pool de facto control over the mining process.Another consideration when reducing the block time is the need to decrease the block size accordingly. In a hypothetical scenario with a five-minute block time, there would be twice the block space available for miners to include transactions. This could lead to the blockchain growing at a faster rate, which is detrimental to decentralization. Furthermore, reducing the block time may cause transaction fees to decrease, making it cheaper for spammers to bloat the UTXO (Unspent Transaction Output) sets.There have been various proposals to address the downsides of faster blocks, with one notable suggestion being the "Greedy Heaviest Observed Subtree" (GHOST) protocol. This protocol aims to overcome the security and centralization concerns associated with reducing block time. Additionally, it is worth mentioning that the Lightning teams have made significant progress in point-of-sale support, providing an alternative solution to scalability.While the goal for Bitcoin may be to eventually achieve a block time of one second or less, current technology is not yet developed enough to support this level of speed due to the limitations imposed by the speed of light. However, there have been efforts to mitigate potential issues, such as the development of a script to prevent a "sybil attack" from 2x. The efficacy and ethical implications of this script are subjects of debate within the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2018/combined_-BIP-Proposal-Nym-Enrolment-Transaction-Template.xml b/static/bitcoin-dev/Oct_2018/combined_-BIP-Proposal-Nym-Enrolment-Transaction-Template.xml index f9fb142252..f0a77423ad 100644 --- a/static/bitcoin-dev/Oct_2018/combined_-BIP-Proposal-Nym-Enrolment-Transaction-Template.xml +++ b/static/bitcoin-dev/Oct_2018/combined_-BIP-Proposal-Nym-Enrolment-Transaction-Template.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - [BIP Proposal] Nym Enrolment Transaction Template - 2023-08-01T23:56:04.790488+00:00 - - Kalle Rosenbaum 2018-10-08 18:59:00+00:00 - - - Велеслав 2018-10-07 03:30:59+00:00 - + 2025-09-26T16:03:10.336352+00:00 + python-feedgen + + + [bitcoin-dev] [BIP Proposal] Nym Enrolment Transaction Template Велеслав + 2018-10-07T03:30:00.000Z + + + Kalle Rosenbaum + 2018-10-08T18:59:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Nym Enrolment Transaction Template - 2023-08-01T23:56:04.790488+00:00 + 2025-09-26T16:03:10.336828+00:00 - Велеслав has submitted a proposal for a new transaction template that can be used as a cryptographic pseudonym. This proposal is specific to the application layer of Bitcoin and does not involve any consensus changes. Kalle has raised a few comments and questions regarding the proposal. He inquired about why only one input is required and why type p2wpkh on input is demanded. Kalle also questioned the necessity of verifying "SIZE 32 EQUALVERIFY" on output 2 and the requirement for a segwit version 0 change output. Additionally, he sought clarification on the distinction between IsStandard rules and nym protocol rules in the specification section. Kalle couldn't locate information about 1-byte-nym_version and 1-byte-nym_use and their usage.The writer's draft BIP proposes a new transaction template that adopts the next available transaction version number. The objective of this proposal is to establish a unique transaction structure that serves as a cryptographic pseudonym. It should be noted that this proposal is not intended to introduce any consensus changes but rather focuses on the application layer of Bitcoin. The writer expresses hope that the community will find this proposal valuable and encourages a thorough review.For detailed information on the proposal, it can be found on Github at https://github.com/veleslavs/bips/blob/bip_nym_tx/bip-nym_tx.mediawiki. Велеслав extends gratitude to the entire team who provided support during the creation of this proposal. 2018-10-08T18:59:00+00:00 + Велеслав has submitted a proposal for a new transaction template that can be used as a cryptographic pseudonym. This proposal is specific to the application layer of Bitcoin and does not involve any consensus changes. Kalle has raised a few comments and questions regarding the proposal. He inquired about why only one input is required and why type p2wpkh on input is demanded. Kalle also questioned the necessity of verifying "SIZE 32 EQUALVERIFY" on output 2 and the requirement for a segwit version 0 change output. Additionally, he sought clarification on the distinction between IsStandard rules and nym protocol rules in the specification section. Kalle couldn't locate information about 1-byte-nym_version and 1-byte-nym_use and their usage.The writer's draft BIP proposes a new transaction template that adopts the next available transaction version number. The objective of this proposal is to establish a unique transaction structure that serves as a cryptographic pseudonym. It should be noted that this proposal is not intended to introduce any consensus changes but rather focuses on the application layer of Bitcoin. The writer expresses hope that the community will find this proposal valuable and encourages a thorough review.For detailed information on the proposal, it can be found on Github at https://github.com/veleslavs/bips/blob/bip_nym_tx/bip-nym_tx.mediawiki. Велеслав extends gratitude to the entire team who provided support during the creation of this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2018/combined_BIP-for-segwit-compatibility-URIs.xml b/static/bitcoin-dev/Oct_2018/combined_BIP-for-segwit-compatibility-URIs.xml index d42c1f7d88..abf4bbe698 100644 --- a/static/bitcoin-dev/Oct_2018/combined_BIP-for-segwit-compatibility-URIs.xml +++ b/static/bitcoin-dev/Oct_2018/combined_BIP-for-segwit-compatibility-URIs.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - BIP for segwit compatibility URIs - 2023-08-01T23:56:30.566271+00:00 - - Srintuar 2018-10-18 23:58:54+00:00 - - - Clark Moody 2018-10-18 22:27:41+00:00 - - - vv01f 2018-10-18 16:52:49+00:00 - - - Clark Moody 2018-10-18 14:20:45+00:00 - - - Srintuar 2018-10-14 19:52:25+00:00 - + 2025-09-26T16:03:18.751404+00:00 + python-feedgen + + + [bitcoin-dev] BIP for segwit compatibility URIs Srintuar + 2018-10-14T19:52:00.000Z + + + Clark Moody + 2018-10-18T14:20:00.000Z + + + vv01f + 2018-10-18T16:52:00.000Z + + + Clark Moody + 2018-10-18T22:27:00.000Z + + + Srintuar + 2018-10-18T23:58:00.000Z + + - python-feedgen + 2 Combined summary - BIP for segwit compatibility URIs - 2023-08-01T23:56:30.566271+00:00 + 2025-09-26T16:03:18.752177+00:00 - The Bitcoin Improvement Proposal (BIP) being discussed involves the use of a concise encoding method, such as a single letter "a", to reduce the size of QR codes. However, there is recognition that using "address" would be more self-explanatory. To determine feasibility, sample QR code sizes for typical use cases will be included. The proposal aims to address the issue of multiple keys with the same name in many wallets by suggesting the use of a delimiter. The author plans to update the BIP proposal and submit it again.In a discussion on the bitcoin-dev mailing list, Clark Moody agrees with spelling out the `address` field. In response to vv01f's suggestion of using the `&` separator and returning either an address or an array of addresses, Clark points out that there is no standard for specifying an array in a URI. He suggests using a delimiter-separated list under one parameter to maintain compatibility. This approach leverages the fact that most languages have library functions for splitting strings on commas. The conversation also touches on future-proofing the syntax by passing a list of addresses to `addr`. The focus of the discussion revolves around finding the best way to structure URIs for Bitcoin transactions.Another discussion regarding the separator for Bitcoin addresses concluded that the & symbol could be used without needing a delimiter. The return value would either be an address or an array of addresses. It was suggested to name the parameter "address" instead of using a shortcut. On October 18, 2018, Clark Moody proposed a syntax that would make the system future-proof by passing a list of addresses to "addr" using the bitcoin:[?addr=[address1,address2]] format.The main objective of this BIP is to enable all users to easily make payments from any wallet while ensuring backward compatibility does not impede segwit adoption. The proposed URI scheme allows for compatibility with both native segwit (bech32) wallets and legacy wallets (base58). Merchants can receive payments to a bech32 address, while older clients can still make base58 encoded payments. To future-proof address changes, a list of addresses can be passed to `addr`. The syntax is bitcoin:[?addr=[address1,address2]]. The addresses in the comma-separated list are ranked in order of preference, with the highest ranked first. A consumer of this URI should attempt to understand each address in the list before falling back to the next one, finally resorting to the base address after `bitcoin:`. An example of this syntax would be bitcoin:3xBase58compatibleAddress?addr=fancyFutureEncoding0x01,bech32address1qx01.This proposal suggests a URI scheme that ensures backward compatibility with both native segwit (bech32) wallets and legacy wallets (base58). It is based on an adaptation of BIP 0021 by Nils Schneider and Matt Corallo. The purpose of this URI scheme is to facilitate easy payments from any wallet without hindering backward compatibility as a barrier to segwit adoption. The specification includes Query Keys such as 'addr', which specifies an alternative bitcoin destination preferred over the "bitcoinaddress" field of the URL. The simpler syntax for this scheme is bitcoin:[?amount=][?label=][?message=][?addr=]. An example provided in the proposal demonstrates how the address can be used along with the preferred bitcoin destination. Currently, there are no reference implementations available for Bitcoin clients. 2018-10-18T23:58:54+00:00 + The Bitcoin Improvement Proposal (BIP) being discussed involves the use of a concise encoding method, such as a single letter "a", to reduce the size of QR codes. However, there is recognition that using "address" would be more self-explanatory. To determine feasibility, sample QR code sizes for typical use cases will be included. The proposal aims to address the issue of multiple keys with the same name in many wallets by suggesting the use of a delimiter. The author plans to update the BIP proposal and submit it again.In a discussion on the bitcoin-dev mailing list, Clark Moody agrees with spelling out the `address` field. In response to vv01f's suggestion of using the `&` separator and returning either an address or an array of addresses, Clark points out that there is no standard for specifying an array in a URI. He suggests using a delimiter-separated list under one parameter to maintain compatibility. This approach leverages the fact that most languages have library functions for splitting strings on commas. The conversation also touches on future-proofing the syntax by passing a list of addresses to `addr`. The focus of the discussion revolves around finding the best way to structure URIs for Bitcoin transactions.Another discussion regarding the separator for Bitcoin addresses concluded that the & symbol could be used without needing a delimiter. The return value would either be an address or an array of addresses. It was suggested to name the parameter "address" instead of using a shortcut. On October 18, 2018, Clark Moody proposed a syntax that would make the system future-proof by passing a list of addresses to "addr" using the bitcoin:[?addr=[address1,address2]] format.The main objective of this BIP is to enable all users to easily make payments from any wallet while ensuring backward compatibility does not impede segwit adoption. The proposed URI scheme allows for compatibility with both native segwit (bech32) wallets and legacy wallets (base58). Merchants can receive payments to a bech32 address, while older clients can still make base58 encoded payments. To future-proof address changes, a list of addresses can be passed to `addr`. The syntax is bitcoin:[?addr=[address1,address2]]. The addresses in the comma-separated list are ranked in order of preference, with the highest ranked first. A consumer of this URI should attempt to understand each address in the list before falling back to the next one, finally resorting to the base address after `bitcoin:`. An example of this syntax would be bitcoin:3xBase58compatibleAddress?addr=fancyFutureEncoding0x01,bech32address1qx01.This proposal suggests a URI scheme that ensures backward compatibility with both native segwit (bech32) wallets and legacy wallets (base58). It is based on an adaptation of BIP 0021 by Nils Schneider and Matt Corallo. The purpose of this URI scheme is to facilitate easy payments from any wallet without hindering backward compatibility as a barrier to segwit adoption. The specification includes Query Keys such as 'addr', which specifies an alternative bitcoin destination preferred over the "bitcoinaddress" field of the URL. The simpler syntax for this scheme is bitcoin:[?amount=][?label=][?message=][?addr=]. An example provided in the proposal demonstrates how the address can be used along with the preferred bitcoin destination. Currently, there are no reference implementations available for Bitcoin clients. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2018/combined_Bitcoin-Core-0-17-0-released.xml b/static/bitcoin-dev/Oct_2018/combined_Bitcoin-Core-0-17-0-released.xml index 685173f060..135b26e5d5 100644 --- a/static/bitcoin-dev/Oct_2018/combined_Bitcoin-Core-0-17-0-released.xml +++ b/static/bitcoin-dev/Oct_2018/combined_Bitcoin-Core-0-17-0-released.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Bitcoin Core 0.17.0 released - 2023-08-01T23:55:38.811272+00:00 - - Jorge Timón 2018-10-03 23:53:07+00:00 - - - Wladimir J. van der Laan 2018-10-03 10:29:26+00:00 - + 2025-09-26T16:03:16.653326+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Core 0.17.0 released Wladimir J. van der Laan + 2018-10-03T10:29:00.000Z + + + Jorge Timón + 2018-10-03T23:53:00.000Z + + - python-feedgen + 2 Combined summary - Bitcoin Core 0.17.0 released - 2023-08-01T23:55:38.812271+00:00 + 2025-09-26T16:03:16.653745+00:00 - Bitcoin Core version 0.17.0 has been released, bringing various new features, bug fixes, and performance improvements. Some of the notable changes include the option to limit block storage and set different options for different networks through a single configuration file. The 'account' API has been replaced with the 'label' API, and compatibility with BIP 174 Partially Signed Bitcoin Transactions support has been added.The update also includes the introduction of new thread safety annotations, Clang compile-time checking, and enhancements to performance. The release removes the '-blockmaxsize' option for miners to limit their blocks' sizes and discontinues Python 2 support for all test files and tools. Improvements have been made to block and transaction handling, and the option to specify the directory for block storage is now available.Additionally, the Bitcoin Core team has made numerous improvements to the software in recent months, including updates related to build systems, tests and QA, bug fixes, changes to the options dialog, peer table, and send coins dialog to improve readability, and enhancements to performance. Over 50 patches have been submitted in the latest code review, addressing bugs found within the software and updating the testing framework.Bitcoin Core version 0.17.1 has also been released, with changes and improvements such as preventing shared conf files from failing with different available options in different binaries, checking for AVX2 code, as well as AVX, XSAVE, and OS support. Documentation changes have been made, including updates to UNIX documentation and explanations on how to update chainTxData in the release process.In terms of security, Bitcoin Core version 0.16.3 includes a fix for a denial-of-service vulnerability that could have allowed an attacker to crash a network node by flooding it with duplicate transactions. The update also provides credit to individuals who contributed to the project, including translators on Transifex.Bitcoin Core is client software used to mine and operate with bitcoin. The latest version, 0.17.0, has been released for multiple operating systems and platforms. It includes new features such as the addition of an RPC command called "assumesvalid" and a new wallet format called descriptors. The release also includes updates to build instructions for specific operating systems, renaming "OS X" to "macOS," and clarifications on certain aspects of the software.It is important to note that upgrading from older versions may result in memory blow-up during the roll-back of blocks to the SegWit activation point, and the GUI may experience visual glitches in the new MacOS dark mode. However, the Bitcoin Core team continues to make improvements to the software to enhance performance, security, and usability. 2018-10-03T23:53:07+00:00 + Bitcoin Core version 0.17.0 has been released, bringing various new features, bug fixes, and performance improvements. Some of the notable changes include the option to limit block storage and set different options for different networks through a single configuration file. The 'account' API has been replaced with the 'label' API, and compatibility with BIP 174 Partially Signed Bitcoin Transactions support has been added.The update also includes the introduction of new thread safety annotations, Clang compile-time checking, and enhancements to performance. The release removes the '-blockmaxsize' option for miners to limit their blocks' sizes and discontinues Python 2 support for all test files and tools. Improvements have been made to block and transaction handling, and the option to specify the directory for block storage is now available.Additionally, the Bitcoin Core team has made numerous improvements to the software in recent months, including updates related to build systems, tests and QA, bug fixes, changes to the options dialog, peer table, and send coins dialog to improve readability, and enhancements to performance. Over 50 patches have been submitted in the latest code review, addressing bugs found within the software and updating the testing framework.Bitcoin Core version 0.17.1 has also been released, with changes and improvements such as preventing shared conf files from failing with different available options in different binaries, checking for AVX2 code, as well as AVX, XSAVE, and OS support. Documentation changes have been made, including updates to UNIX documentation and explanations on how to update chainTxData in the release process.In terms of security, Bitcoin Core version 0.16.3 includes a fix for a denial-of-service vulnerability that could have allowed an attacker to crash a network node by flooding it with duplicate transactions. The update also provides credit to individuals who contributed to the project, including translators on Transifex.Bitcoin Core is client software used to mine and operate with bitcoin. The latest version, 0.17.0, has been released for multiple operating systems and platforms. It includes new features such as the addition of an RPC command called "assumesvalid" and a new wallet format called descriptors. The release also includes updates to build instructions for specific operating systems, renaming "OS X" to "macOS," and clarifications on certain aspects of the software.It is important to note that upgrading from older versions may result in memory blow-up during the roll-back of blocks to the SegWit activation point, and the GUI may experience visual glitches in the new MacOS dark mode. However, the Bitcoin Core team continues to make improvements to the software to enhance performance, security, and usability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2018/combined_Generalised-taproot.xml b/static/bitcoin-dev/Oct_2018/combined_Generalised-taproot.xml index f8e398c774..b7b6c4a3cf 100644 --- a/static/bitcoin-dev/Oct_2018/combined_Generalised-taproot.xml +++ b/static/bitcoin-dev/Oct_2018/combined_Generalised-taproot.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Generalised taproot - 2023-08-01T23:40:05.077900+00:00 + 2025-09-26T16:03:22.952330+00:00 + python-feedgen Pieter Wuille 2018-10-24 02:22:24+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Generalised taproot - 2023-08-01T23:40:05.077900+00:00 + 2025-09-26T16:03:22.952499+00:00 - Pieter Wuille, a Bitcoin Core developer, has introduced a new construction called "g'root" to address the issue of recursive-taproot-without-revealing-intermediary-scripts. This structure combines the concepts of Pedersen Commitments and taproot, resulting in an equation that combines private keys, hashes of additional conditions, and alternative spending methods.The g'root construction eliminates the distinction between pay-to-pubkey and pay-to-script constructions, providing an easy way to create a softfork-safe cross-input aggregation system. It also ensures that any future cross-input signature aggregation system only applies to companion keys that are not susceptible to potential changes in the scripting language.Wuille suggests deploying schnorr/taproot/mast initially, followed by the addition of graftroot/aggregation. Finally, the deployment of generalised taproot alongside graftroot/aggregation is recommended.In addition to this proposal, there is another suggestion for recursive taproot that utilizes Pedersen Commitments. By combining the taproot structure with a second generator in the curve, it becomes possible to create a pubkey point that can be spent either through direct signing or by revealing additional conditions.To maintain secrecy, the proposal allows users to hide whether there are any lower layers until the merkle-tree of scripts is reached. Furthermore, it enables the non-disclosure of conditions corresponding to any keys other than the one being spent with.This proposal is as space-efficient as basic taproot and potentially more efficient than using a merkle tree with taproot when there are three spending paths.To summarize, Pieter Wuille's "g'root" construction and the proposal for recursive taproot with Pedersen Commitments aim to enhance the functionality and efficiency of Bitcoin transactions. These proposals suggest deploying different components such as schnorr/taproot/mast and graftroot/aggregation in a phased manner to ensure a smooth transition. 2018-10-24T02:22:24+00:00 + Pieter Wuille, a Bitcoin Core developer, has introduced a new construction called "g'root" to address the issue of recursive-taproot-without-revealing-intermediary-scripts. This structure combines the concepts of Pedersen Commitments and taproot, resulting in an equation that combines private keys, hashes of additional conditions, and alternative spending methods.The g'root construction eliminates the distinction between pay-to-pubkey and pay-to-script constructions, providing an easy way to create a softfork-safe cross-input aggregation system. It also ensures that any future cross-input signature aggregation system only applies to companion keys that are not susceptible to potential changes in the scripting language.Wuille suggests deploying schnorr/taproot/mast initially, followed by the addition of graftroot/aggregation. Finally, the deployment of generalised taproot alongside graftroot/aggregation is recommended.In addition to this proposal, there is another suggestion for recursive taproot that utilizes Pedersen Commitments. By combining the taproot structure with a second generator in the curve, it becomes possible to create a pubkey point that can be spent either through direct signing or by revealing additional conditions.To maintain secrecy, the proposal allows users to hide whether there are any lower layers until the merkle-tree of scripts is reached. Furthermore, it enables the non-disclosure of conditions corresponding to any keys other than the one being spent with.This proposal is as space-efficient as basic taproot and potentially more efficient than using a merkle tree with taproot when there are three spending paths.To summarize, Pieter Wuille's "g'root" construction and the proposal for recursive taproot with Pedersen Commitments aim to enhance the functionality and efficiency of Bitcoin transactions. These proposals suggest deploying different components such as schnorr/taproot/mast and graftroot/aggregation in a phased manner to ensure a smooth transition. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2018/combined_MultiSig-request-URI-proposal.xml b/static/bitcoin-dev/Oct_2018/combined_MultiSig-request-URI-proposal.xml index 7d0ce18a6c..2c21413f95 100644 --- a/static/bitcoin-dev/Oct_2018/combined_MultiSig-request-URI-proposal.xml +++ b/static/bitcoin-dev/Oct_2018/combined_MultiSig-request-URI-proposal.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - MultiSig request URI proposal - 2023-08-01T23:55:52.692556+00:00 - - James MacWhyte 2018-10-08 23:42:57+00:00 - - - おのかちお 2018-10-04 14:03:37+00:00 - + 2025-09-26T16:03:12.424308+00:00 + python-feedgen + + + [bitcoin-dev] MultiSig request URI proposal おのかちお + 2018-10-04T14:03:00.000Z + + + James MacWhyte + 2018-10-08T23:42:00.000Z + + - python-feedgen + 2 Combined summary - MultiSig request URI proposal - 2023-08-01T23:55:52.692556+00:00 + 2025-09-26T16:03:12.424774+00:00 - In a discussion on the bitcoin-dev mailing list, user おのかちお has proposed an idea for a new URI scheme that would enable multisig requests from websites to users' local wallets. Currently, there is no Multisig request URI in Bitcoin's BIP 21, and the writer suggests the implementation of a bitcoin-sigreq URI scheme to address this gap.The proposed bitcoin-sigreq URI scheme would include the raw transaction encoded in base64, as well as parameters such as the public key for the sign key pair and the path for HD wallet position. This would allow websites to send multisig requests directly to users' local wallets, enabling them to participate in on-chain multisig transactions.However, the writer acknowledges potential issues with using a URI scheme for two-way communication in the context of on-chain multisig transactions. These transactions require multiple parties to provide signatures and one party to aggregate and publish the transaction. While BIP72 allows for callbacks to be included in the URI, it was designed for one-way communication and may not be suitable for two-way communication.Given these concerns, the author suggests exploring alternative methods that are better suited for two-way communication instead of solely relying on the URI system. The writer seeks feedback and input from the community on the proposed bitcoin-sigreq URI scheme and its feasibility in facilitating multisig requests between websites and users' local wallets.Overall, the proposed idea aims to enhance the functionality of Bitcoin's BIP 21 by introducing a new URI scheme specifically designed for multisig requests. By allowing websites to communicate directly with users' local wallets, this scheme could streamline the process of participating in on-chain multisig transactions. However, further consideration is needed to address the challenges associated with two-way communication using a URI scheme. 2018-10-08T23:42:57+00:00 + In a discussion on the bitcoin-dev mailing list, user おのかちお has proposed an idea for a new URI scheme that would enable multisig requests from websites to users' local wallets. Currently, there is no Multisig request URI in Bitcoin's BIP 21, and the writer suggests the implementation of a bitcoin-sigreq URI scheme to address this gap.The proposed bitcoin-sigreq URI scheme would include the raw transaction encoded in base64, as well as parameters such as the public key for the sign key pair and the path for HD wallet position. This would allow websites to send multisig requests directly to users' local wallets, enabling them to participate in on-chain multisig transactions.However, the writer acknowledges potential issues with using a URI scheme for two-way communication in the context of on-chain multisig transactions. These transactions require multiple parties to provide signatures and one party to aggregate and publish the transaction. While BIP72 allows for callbacks to be included in the URI, it was designed for one-way communication and may not be suitable for two-way communication.Given these concerns, the author suggests exploring alternative methods that are better suited for two-way communication instead of solely relying on the URI system. The writer seeks feedback and input from the community on the proposed bitcoin-sigreq URI scheme and its feasibility in facilitating multisig requests between websites and users' local wallets.Overall, the proposed idea aims to enhance the functionality of Bitcoin's BIP 21 by introducing a new URI scheme specifically designed for multisig requests. By allowing websites to communicate directly with users' local wallets, this scheme could streamline the process of participating in on-chain multisig transactions. However, further consideration is needed to address the challenges associated with two-way communication using a URI scheme. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2018/combined_Request-OP-CHECKTXOUTSCRIPTHASHVERIFY.xml b/static/bitcoin-dev/Oct_2018/combined_Request-OP-CHECKTXOUTSCRIPTHASHVERIFY.xml index 0045d9dcad..887d03be9c 100644 --- a/static/bitcoin-dev/Oct_2018/combined_Request-OP-CHECKTXOUTSCRIPTHASHVERIFY.xml +++ b/static/bitcoin-dev/Oct_2018/combined_Request-OP-CHECKTXOUTSCRIPTHASHVERIFY.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Request: OP_CHECKTXOUTSCRIPTHASHVERIFY - 2023-08-01T23:56:46.683568+00:00 - - ZmnSCPxj 2018-10-17 10:22:59+00:00 - - - kim juan 2018-10-17 06:58:10+00:00 - - - ZmnSCPxj 2018-10-17 05:17:15+00:00 - - - kim juan 2018-10-17 04:26:34+00:00 - + 2025-09-26T16:03:14.508201+00:00 + python-feedgen + + + [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY kim juan + 2018-10-17T04:26:00.000Z + + + ZmnSCPxj + 2018-10-17T05:17:00.000Z + + + kim juan + 2018-10-17T06:58:00.000Z + + + ZmnSCPxj + 2018-10-17T10:22:00.000Z + + - python-feedgen + 2 Combined summary - Request: OP_CHECKTXOUTSCRIPTHASHVERIFY - 2023-08-01T23:56:46.683568+00:00 + 2025-09-26T16:03:14.508879+00:00 - A new opcode, OP_CHECKTXOUTSCRIPTHASHVERIFY, is being proposed for the Bitcoin scripting system. This opcode would allow a transaction output to be spendable only in a predefined manner, potentially reducing the risk of key loss. However, there are concerns about covenants and vaults being visible on-chain and requiring complex script templates, which could increase block space usage. Efforts have also been made to move contract execution off-chain. ZmnSCPxj suggests an improvement to the specification of OP_CHECKTXOUTSCRIPTHASHVERIFY, with plans to focus future SCRIPT updates on SegWit versions. The opcode would succeed if certain conditions are met, such as being a P2WSH with a matching SegWit version and hash, or being the same as the transaction output being spent. If none of these conditions are met, the operation will fail. A sample use case is provided, where Acme has an ordinary key pair and a secure key pair. The private key of the secure key pair remains hidden until it needs to revoke the transaction of the ordinary key pair. To spend the outputs from the ThisRedeemScript, they must be forwarded to the NextRedeemScript. Even if the original key pair is compromised, the attacker can only spend the outputs in this specific way and must publish the transaction. The NextRedeemScript is time-locked, allowing Acme to monitor for unauthorized transactions and react within the specified duration. In certain cases, the combination of both key pairs as one multisig can immediately spend the output regardless of the timelock.The email thread emphasizes that CSV and CTLV have already paved the way for retroactive invalidation, as seen in protocols like HTLC of the lightning network. The proposed opcode could address other problems requiring retroactive invalidation in a less interactive manner than channels. By influencing how outputs can be spent, the opcode could make attacks less rewarding. However, there are still potential privacy concerns, and the use case assumes that P2SH is an exceptional case for custodians like e-commerce merchants and exchanges. 2018-10-17T10:22:59+00:00 + A new opcode, OP_CHECKTXOUTSCRIPTHASHVERIFY, is being proposed for the Bitcoin scripting system. This opcode would allow a transaction output to be spendable only in a predefined manner, potentially reducing the risk of key loss. However, there are concerns about covenants and vaults being visible on-chain and requiring complex script templates, which could increase block space usage. Efforts have also been made to move contract execution off-chain. ZmnSCPxj suggests an improvement to the specification of OP_CHECKTXOUTSCRIPTHASHVERIFY, with plans to focus future SCRIPT updates on SegWit versions. The opcode would succeed if certain conditions are met, such as being a P2WSH with a matching SegWit version and hash, or being the same as the transaction output being spent. If none of these conditions are met, the operation will fail. A sample use case is provided, where Acme has an ordinary key pair and a secure key pair. The private key of the secure key pair remains hidden until it needs to revoke the transaction of the ordinary key pair. To spend the outputs from the ThisRedeemScript, they must be forwarded to the NextRedeemScript. Even if the original key pair is compromised, the attacker can only spend the outputs in this specific way and must publish the transaction. The NextRedeemScript is time-locked, allowing Acme to monitor for unauthorized transactions and react within the specified duration. In certain cases, the combination of both key pairs as one multisig can immediately spend the output regardless of the timelock.The email thread emphasizes that CSV and CTLV have already paved the way for retroactive invalidation, as seen in protocols like HTLC of the lightning network. The proposed opcode could address other problems requiring retroactive invalidation in a less interactive manner than channels. By influencing how outputs can be spent, the opcode could make attacks less rewarding. However, there are still potential privacy concerns, and the use case assumes that P2SH is an exceptional case for custodians like e-commerce merchants and exchanges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2018/combined_Transaction-Input-Output-Sorting.xml b/static/bitcoin-dev/Oct_2018/combined_Transaction-Input-Output-Sorting.xml index 161b44ee95..f0e040228c 100644 --- a/static/bitcoin-dev/Oct_2018/combined_Transaction-Input-Output-Sorting.xml +++ b/static/bitcoin-dev/Oct_2018/combined_Transaction-Input-Output-Sorting.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Transaction Input/Output Sorting - 2023-08-01T23:57:05.216655+00:00 - - rhavar at protonmail.com 2018-10-24 18:21:00+00:00 - - - rhavar at protonmail.com 2018-10-24 17:52:38+00:00 - - - Gregory Maxwell 2018-10-24 16:12:39+00:00 - - - Chris Belcher 2018-10-23 14:29:30+00:00 - - - rhavar at protonmail.com 2018-10-22 01:54:55+00:00 - - - Pavol Rusnak 2018-10-21 21:54:26+00:00 - - - rhavar at protonmail.com 2018-10-21 19:00:59+00:00 - + 2025-09-26T16:03:20.841395+00:00 + python-feedgen + + + [bitcoin-dev] Transaction Input/Output Sorting rhavar + 2018-10-21T19:00:00.000Z + + + Pavol Rusnak + 2018-10-21T21:54:00.000Z + + + rhavar + 2018-10-22T01:54:00.000Z + + + Chris Belcher + 2018-10-23T14:29:00.000Z + + + Gregory Maxwell + 2018-10-24T16:12:00.000Z + + + rhavar + 2018-10-24T17:52:00.000Z + + + rhavar + 2018-10-24T18:21:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Transaction Input/Output Sorting - 2023-08-01T23:57:05.217654+00:00 + 2025-09-26T16:03:20.842393+00:00 - A script was written by Ryan to test the popularity of bip69 and randomization in transactions. The results showed that only 42% of transactions were bip69 when randomized, indicating that randomization is currently more popular than bip69. However, with more inputs and outputs, bip69 can be determined with high confidence. Gregory Maxwell commented on this, stating that randomly ordered two-input transactions have a 50% chance of following bip69, making the reported 60% adherence to bip69 a small minority.Chris Belcher expressed gratitude for bringing attention to the topic and mentioned that around 60% of transactions follow bip69 according to statistics provided by p2sh.info/dashboard/db/bip-69-stats. However, he noted that this percentage may be due to chance, as a transaction with two inputs ordered randomly has a 50% chance of following bip69. Therefore, the percentage of transactions following bip69 appears to be a small minority.There was a suggestion to create a bitcoin wiki page to track wallets that use bip69, which would make it easier to determine which wallets can have code written for them and which ones can be bugged about bip69. Ryan Havar expressed concerns about the fungibility of bitcoin and the reliance on blockchain analysis and centralized analytics services, which could harm its value and history.The email exchange also discussed the difficulty in detecting wallet boundaries in bitcoin transactions. Currently, it is possible to determine if a transaction uses bip69 or not, but it is harder to establish wallet boundaries because an outside observer cannot tell if a transaction uses deterministic sorting or not. This raises concerns about the fungibility of bitcoin and the effectiveness of blockchain analysis, which relies heavily on fragile heuristics and can be easily tricked.Ryan Havar expressed concern over how easy it is to spot the boundaries between different wallets and suggested a potential solution of deterministic sorting based on a semi-secret. This approach would involve using a standardized sort order based on a semi-secret called the "sortingSecret," which would allow for external verification of correct sorting while appearing totally randomized. This solution addresses the impasse between wallets that prefer deterministic sorting and those that object to it due to privacy loss and future incompatibility concerns. 2018-10-24T18:21:00+00:00 + A script was written by Ryan to test the popularity of bip69 and randomization in transactions. The results showed that only 42% of transactions were bip69 when randomized, indicating that randomization is currently more popular than bip69. However, with more inputs and outputs, bip69 can be determined with high confidence. Gregory Maxwell commented on this, stating that randomly ordered two-input transactions have a 50% chance of following bip69, making the reported 60% adherence to bip69 a small minority.Chris Belcher expressed gratitude for bringing attention to the topic and mentioned that around 60% of transactions follow bip69 according to statistics provided by p2sh.info/dashboard/db/bip-69-stats. However, he noted that this percentage may be due to chance, as a transaction with two inputs ordered randomly has a 50% chance of following bip69. Therefore, the percentage of transactions following bip69 appears to be a small minority.There was a suggestion to create a bitcoin wiki page to track wallets that use bip69, which would make it easier to determine which wallets can have code written for them and which ones can be bugged about bip69. Ryan Havar expressed concerns about the fungibility of bitcoin and the reliance on blockchain analysis and centralized analytics services, which could harm its value and history.The email exchange also discussed the difficulty in detecting wallet boundaries in bitcoin transactions. Currently, it is possible to determine if a transaction uses bip69 or not, but it is harder to establish wallet boundaries because an outside observer cannot tell if a transaction uses deterministic sorting or not. This raises concerns about the fungibility of bitcoin and the effectiveness of blockchain analysis, which relies heavily on fragile heuristics and can be easily tricked.Ryan Havar expressed concern over how easy it is to spot the boundaries between different wallets and suggested a potential solution of deterministic sorting based on a semi-secret. This approach would involve using a standardized sort order based on a semi-secret called the "sortingSecret," which would allow for external verification of correct sorting while appearing totally randomized. This solution addresses the impasse between wallets that prefer deterministic sorting and those that object to it due to privacy loss and future incompatibility concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_BIPable-idea-Consistent-and-better-definition-of-the-term-address-.xml b/static/bitcoin-dev/Oct_2019/combined_BIPable-idea-Consistent-and-better-definition-of-the-term-address-.xml index 125cd4af54..35dc2f770e 100644 --- a/static/bitcoin-dev/Oct_2019/combined_BIPable-idea-Consistent-and-better-definition-of-the-term-address-.xml +++ b/static/bitcoin-dev/Oct_2019/combined_BIPable-idea-Consistent-and-better-definition-of-the-term-address-.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - BIPable-idea: Consistent and better definition of the term 'address' - 2023-08-02T01:28:02.169982+00:00 - - Emil Engler 2019-10-17 19:28:44+00:00 - - - Marco Falke 2019-10-17 13:23:39+00:00 - - - Emil Engler 2019-10-11 21:03:45+00:00 - - - Ariel Lorenzo-Luaces 2019-10-11 04:22:03+00:00 - - - Karl-Johan Alm 2019-10-11 02:00:51+00:00 - - - Lloyd Fournier 2019-10-11 01:13:40+00:00 - - - Emil Engler 2019-10-10 15:05:36+00:00 - - - Chris Belcher 2019-10-09 19:32:13+00:00 - - - Emil Engler 2019-10-06 16:06:27+00:00 - - - Luke Dashjr 2019-10-06 11:32:33+00:00 - - - Emil Engler 2019-10-05 21:57:48+00:00 - + 2025-09-26T15:27:22.608740+00:00 + python-feedgen + + + [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address' Emil Engler + 2019-10-05T21:57:00.000Z + + + Luke Dashjr + 2019-10-06T11:32:00.000Z + + + Emil Engler + 2019-10-06T16:06:00.000Z + + + Chris Belcher + 2019-10-09T19:32:00.000Z + + + Emil Engler + 2019-10-10T15:05:00.000Z + + + Lloyd Fournier + 2019-10-11T01:13:00.000Z + + + Karl-Johan Alm + 2019-10-11T02:00:00.000Z + + + Ariel Lorenzo-Luaces + 2019-10-11T04:22:00.000Z + + + Emil Engler + 2019-10-11T21:03:00.000Z + + + Marco Falke + 2019-10-17T13:23:00.000Z + + + Emil Engler + 2019-10-17T19:28:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - BIPable-idea: Consistent and better definition of the term 'address' - 2023-08-02T01:28:02.170982+00:00 + 2025-09-26T15:27:22.610019+00:00 - In a recent email thread on the bitcoin-dev mailing list, there has been discussion about finding a better term to replace the current term "Bitcoin address" in Bitcoin transactions. The use of the term "bitcoin invoice address" coined by Chris Belcher has received positive feedback from members of the community, as it is easily translatable into other languages and holds relevance in the context of generating invoices for Bitcoin transactions. The adoption of language that is easily understood by the masses is seen as crucial for widespread acceptance of cryptocurrencies like Bitcoin.The proposal suggests using the term "Funding Codes" as a replacement for the term "address" in Bitcoin transactions. This term is preferred because it can be used as both a verb and a noun, which aligns well with Bitcoin transactions. Additionally, the word "code" accurately describes the signature script associated with addresses. The use of "Funding Codes" is particularly relevant in the context of self-executing smart contracts and upcoming developments like schnorr and taproot. The term sounds good when spoken, has two words and three syllables, and can easily be abbreviated as "code."The concept of a Bitcoin invoice has also been discussed, with proposals to convert the invoice address into a Bitcoin address gaining support. Emil Engler has expressed gratitude for the feedback received and has announced the decision to write a Bitcoin Improvement Proposal (BIP) for better on-chain privacy. However, there is still a need to find a suitable term to replace the word "address." Suggestions include Invoice ID, Payment Token, Bitcoin invoice (address), and Bitcoin invoice (path). Chris Belcher's suggestion of 'Bitcoin Invoice' stands out due to its similarity to the Lightning Network's term "invoice."There has been a comparison between the use of clay bulla in ancient times and Bitcoin addresses. The practice of impressing tokens onto wet bulla to ensure trust and prevent tampering has similarities to the use of Bitcoin addresses. Emil Engler is seeking a consensus on the best replacement term for a Bitcoin address, with suggestions including Invoice ID, Payment Token, Bitcoin invoice (address), and Bitcoin invoice (path). Belcher's suggestion of "Bitcoin Invoice" appeals to Engler due to its similarity to the Lightning Network's term "invoice."The proposal to change the term "Bitcoin address" aims to discourage repeated use of the same receiving address. Suggestions such as "Payment Password" or "Transaction Password" have been made as alternative terms. The current use of the term "address" leads to misunderstandings, as people associate it with something fixed and permanent. Some members of the community argue that neither the address nor public key are passwords and suggest alternative terms like "invoice id" or "payment token." While the idea has generated some discussion, no formal action has been taken yet.In conclusion, there is ongoing discussion within the bitcoin-dev community about finding a better term to replace the current term "Bitcoin address" in Bitcoin transactions. The proposal suggests using terms like "Funding Codes" or "Bitcoin Invoice" as alternatives. Standardization and widespread adoption of easily understood language are seen as important steps towards the acceptance of cryptocurrencies like Bitcoin. Feedback and consensus-building efforts are ongoing, with the possibility of a Bitcoin Improvement Proposal (BIP) being written on the topic. 2019-10-17T19:28:44+00:00 + In a recent email thread on the bitcoin-dev mailing list, there has been discussion about finding a better term to replace the current term "Bitcoin address" in Bitcoin transactions. The use of the term "bitcoin invoice address" coined by Chris Belcher has received positive feedback from members of the community, as it is easily translatable into other languages and holds relevance in the context of generating invoices for Bitcoin transactions. The adoption of language that is easily understood by the masses is seen as crucial for widespread acceptance of cryptocurrencies like Bitcoin.The proposal suggests using the term "Funding Codes" as a replacement for the term "address" in Bitcoin transactions. This term is preferred because it can be used as both a verb and a noun, which aligns well with Bitcoin transactions. Additionally, the word "code" accurately describes the signature script associated with addresses. The use of "Funding Codes" is particularly relevant in the context of self-executing smart contracts and upcoming developments like schnorr and taproot. The term sounds good when spoken, has two words and three syllables, and can easily be abbreviated as "code."The concept of a Bitcoin invoice has also been discussed, with proposals to convert the invoice address into a Bitcoin address gaining support. Emil Engler has expressed gratitude for the feedback received and has announced the decision to write a Bitcoin Improvement Proposal (BIP) for better on-chain privacy. However, there is still a need to find a suitable term to replace the word "address." Suggestions include Invoice ID, Payment Token, Bitcoin invoice (address), and Bitcoin invoice (path). Chris Belcher's suggestion of 'Bitcoin Invoice' stands out due to its similarity to the Lightning Network's term "invoice."There has been a comparison between the use of clay bulla in ancient times and Bitcoin addresses. The practice of impressing tokens onto wet bulla to ensure trust and prevent tampering has similarities to the use of Bitcoin addresses. Emil Engler is seeking a consensus on the best replacement term for a Bitcoin address, with suggestions including Invoice ID, Payment Token, Bitcoin invoice (address), and Bitcoin invoice (path). Belcher's suggestion of "Bitcoin Invoice" appeals to Engler due to its similarity to the Lightning Network's term "invoice."The proposal to change the term "Bitcoin address" aims to discourage repeated use of the same receiving address. Suggestions such as "Payment Password" or "Transaction Password" have been made as alternative terms. The current use of the term "address" leads to misunderstandings, as people associate it with something fixed and permanent. Some members of the community argue that neither the address nor public key are passwords and suggest alternative terms like "invoice id" or "payment token." While the idea has generated some discussion, no formal action has been taken yet.In conclusion, there is ongoing discussion within the bitcoin-dev community about finding a better term to replace the current term "Bitcoin address" in Bitcoin transactions. The proposal suggests using terms like "Funding Codes" or "Bitcoin Invoice" as alternatives. Standardization and widespread adoption of easily understood language are seen as important steps towards the acceptance of cryptocurrencies like Bitcoin. Feedback and consensus-building efforts are ongoing, with the possibility of a Bitcoin Improvement Proposal (BIP) being written on the topic. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Block-Batch-Filters-for-Light-Clients.xml b/static/bitcoin-dev/Oct_2019/combined_Block-Batch-Filters-for-Light-Clients.xml index e3f2d32d71..474f06006d 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Block-Batch-Filters-for-Light-Clients.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Block-Batch-Filters-for-Light-Clients.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block Batch Filters for Light Clients - 2023-08-02T01:21:33.512882+00:00 + 2025-09-26T15:27:16.193115+00:00 + python-feedgen Jonas Schnelli 2019-10-11 15:44:54+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Block Batch Filters for Light Clients - 2023-08-02T01:21:33.512882+00:00 + 2025-09-26T15:27:16.193255+00:00 - The conversation discusses the limitations of BIP 157 compared to BIP 37 in terms of applying filters to mempool and checking zero confirmation transactions. The light client can only process unconfirmed transactions by loading the entire mempool transaction flow, which raises concerns about DOS and fingerprinting. To address this, a possible solution is suggested, which involves retrieving a complete compact filter of the entire mempool using a maximum size ordered by feerate. This filter could be dynamically constructed and updated based on time intervals rather than every new transaction in the mempool. The process includes generating a mempool filter, connecting to the peer, requesting the filter, processing it for relevant transactions, and sending getdata for those transactions. After the initial retrieve, the light client inspects all new transactions received from peers (filterless unconfirmed tx detection). Alternatively, the mempool filter can be requested again after a timeout if the previous process consumes too much bandwidth. The goal is to make the light client process more efficient without compromising privacy and security.The Block Batch Filters draft has been improved, unlocking the ability to filter unconfirmed transactions for SPV nodes using BIP 157 instead of BIP 37, which had privacy leaks. This allows light clients that refused to use BIP 37 to process unconfirmed transactions by loading the entire mempool transaction flow. Additionally, the Mempool Transaction Filters draft proposes a future consensus layer soft-fork to incorporate block filters commitment into block validation rules, protecting light nodes from payment hiding attacks. This method also reduces bandwidth consumption compared to block filters and downloading full blocks for affected addresses.The updated version of the draft for BIP block batch filters can be found on the Bitaps Github page. It includes changes such as a return to Golomb coding and a simpler, more effective schema implementation. The total filter size is smaller than BIP 158, with estimated savings of over 20%. The filter is deterministic and could potentially be committed as a commitment in coinbase transactions in the future. The GCS parameters are flexible to maintain necessary FPS, and the filter has been split into two parts - unique elements and duplicated elements - with the latter encoded more effectively. However, there are still questions about the optimal range for batch, the need for SIP hash instead of using the first 64 bits from pub key/script hash, and whether unique/duplicated elements should be downloaded separately or if filter types should be added for these purposes. Feedback and discussions on these topics are welcome.Aleksey Karpov also shared a draft of a BIP for compact probabilistic block filters as an alternative to BIP 158. While BIP 158 has a low false positive rate, a higher false positive rate filter could achieve lower bandwidth while syncing the blockchain. However, BIP 158 does not support filter batching due to the design of its parameters for siphash and Golomb coding. The proposed alternative uses delta coding and splits data into two bit string sequences, compressing the second sequence with two rounds of the Huffman algorithm. This method has an effectiveness rate of about 98% compared to Golomb with optimal parameters. Batching block filters significantly reduces their size, and separating filters by address type allows lite clients to avoid downloading redundant information without compromising privacy. The recommended strategy for lite client filters download is to get the biggest filter (smallest blocks/size rate) for a blocks range, then, in case of a positive test, get medium filters to reduce the blocks range, followed by getting block filters for the affected range and downloading affected blocks over TOR. An implementation in Python can be found on GitHub.Tamas Blummer also shared his thoughts on the use of filters in deciding whether to download newly announced blocks. He believes that whole chain scans would be better served with plain sequential reads in map-reduce style. Many clients do not care about filters for blocks before the birth date of their wallet's keys, so they skip over the majority of history, resulting in greater savings than any aggregate filter. Blummer wishes for a filter commitment as it could unlock more utility than marginal savings through a more elaborate design.In conclusion, there are ongoing developments and discussions regarding the limitations of BIP 157, the improvements to the Block Batch Filters draft, and the proposed alternative compact probabilistic block filters. The aim is to make the light client process more efficient while ensuring privacy and security. Feedback and input on these matters are encouraged. 2019-10-11T15:44:54+00:00 + The conversation discusses the limitations of BIP 157 compared to BIP 37 in terms of applying filters to mempool and checking zero confirmation transactions. The light client can only process unconfirmed transactions by loading the entire mempool transaction flow, which raises concerns about DOS and fingerprinting. To address this, a possible solution is suggested, which involves retrieving a complete compact filter of the entire mempool using a maximum size ordered by feerate. This filter could be dynamically constructed and updated based on time intervals rather than every new transaction in the mempool. The process includes generating a mempool filter, connecting to the peer, requesting the filter, processing it for relevant transactions, and sending getdata for those transactions. After the initial retrieve, the light client inspects all new transactions received from peers (filterless unconfirmed tx detection). Alternatively, the mempool filter can be requested again after a timeout if the previous process consumes too much bandwidth. The goal is to make the light client process more efficient without compromising privacy and security.The Block Batch Filters draft has been improved, unlocking the ability to filter unconfirmed transactions for SPV nodes using BIP 157 instead of BIP 37, which had privacy leaks. This allows light clients that refused to use BIP 37 to process unconfirmed transactions by loading the entire mempool transaction flow. Additionally, the Mempool Transaction Filters draft proposes a future consensus layer soft-fork to incorporate block filters commitment into block validation rules, protecting light nodes from payment hiding attacks. This method also reduces bandwidth consumption compared to block filters and downloading full blocks for affected addresses.The updated version of the draft for BIP block batch filters can be found on the Bitaps Github page. It includes changes such as a return to Golomb coding and a simpler, more effective schema implementation. The total filter size is smaller than BIP 158, with estimated savings of over 20%. The filter is deterministic and could potentially be committed as a commitment in coinbase transactions in the future. The GCS parameters are flexible to maintain necessary FPS, and the filter has been split into two parts - unique elements and duplicated elements - with the latter encoded more effectively. However, there are still questions about the optimal range for batch, the need for SIP hash instead of using the first 64 bits from pub key/script hash, and whether unique/duplicated elements should be downloaded separately or if filter types should be added for these purposes. Feedback and discussions on these topics are welcome.Aleksey Karpov also shared a draft of a BIP for compact probabilistic block filters as an alternative to BIP 158. While BIP 158 has a low false positive rate, a higher false positive rate filter could achieve lower bandwidth while syncing the blockchain. However, BIP 158 does not support filter batching due to the design of its parameters for siphash and Golomb coding. The proposed alternative uses delta coding and splits data into two bit string sequences, compressing the second sequence with two rounds of the Huffman algorithm. This method has an effectiveness rate of about 98% compared to Golomb with optimal parameters. Batching block filters significantly reduces their size, and separating filters by address type allows lite clients to avoid downloading redundant information without compromising privacy. The recommended strategy for lite client filters download is to get the biggest filter (smallest blocks/size rate) for a blocks range, then, in case of a positive test, get medium filters to reduce the blocks range, followed by getting block filters for the affected range and downloading affected blocks over TOR. An implementation in Python can be found on GitHub.Tamas Blummer also shared his thoughts on the use of filters in deciding whether to download newly announced blocks. He believes that whole chain scans would be better served with plain sequential reads in map-reduce style. Many clients do not care about filters for blocks before the birth date of their wallet's keys, so they skip over the majority of history, resulting in greater savings than any aggregate filter. Blummer wishes for a filter commitment as it could unlock more utility than marginal savings through a more elaborate design.In conclusion, there are ongoing developments and discussions regarding the limitations of BIP 157, the improvements to the Block Batch Filters draft, and the proposed alternative compact probabilistic block filters. The aim is to make the light client process more efficient while ensuring privacy and security. Feedback and input on these matters are encouraged. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml b/static/bitcoin-dev/Oct_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml index ba0ee494d2..9f499d0f3d 100644 --- a/static/bitcoin-dev/Oct_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml +++ b/static/bitcoin-dev/Oct_2019/combined_CPFP-Carve-Out-for-Fee-Prediction-Issues-in-Contracting-Applications-eg-Lightning-.xml @@ -1,65 +1,63 @@ - + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 - - Johan Torås Halseth 2019-10-30 07:22:53+00:00 - - - David A. Harding 2019-10-28 17:14:38+00:00 - - - Johan Torås Halseth 2019-10-28 09:45:39+00:00 - - - David A. Harding 2019-10-27 22:54:02+00:00 - - - Jeremy 2019-10-27 19:13:09+00:00 - - - Matt Corallo 2019-10-25 17:30:41+00:00 - - - Johan Torås Halseth 2019-10-25 07:05:15+00:00 - - - Matt Corallo 2019-10-24 21:25:14+00:00 - - - Johan Torås Halseth 2019-10-24 13:49:09+00:00 - - - Rusty Russell 2019-02-13 04:22:39+00:00 - - - Matt Corallo 2019-01-08 14:46:45+00:00 - - - Rusty Russell 2019-01-08 05:50:20+00:00 - - - Matt Corallo 2019-01-07 15:18:52+00:00 - - - Rusty Russell 2018-12-04 03:33:53+00:00 - - - ZmnSCPxj 2018-12-03 04:16:10+00:00 - - - Bob McElrath 2018-12-02 15:08:39+00:00 - - - Matt Corallo 2018-11-30 19:33:56+00:00 - - - Russell O'Connor 2018-11-30 17:38:04+00:00 - - - Matt Corallo 2018-11-29 19:37:54+00:00 - + 2025-09-26T15:27:09.779466+00:00 + python-feedgen + + + Matt Corallo + 2019-01-07T15:18:00.000Z + + + Rusty Russell + 2019-01-08T05:50:00.000Z + + + Matt Corallo + 2019-01-08T14:46:00.000Z + + + Rusty Russell + 2019-02-13T04:22:00.000Z + + + Johan Torås Halseth + 2019-10-24T13:49:00.000Z + + + Matt Corallo + 2019-10-24T21:25:00.000Z + + + Johan Torås Halseth + 2019-10-25T07:05:00.000Z + + + Matt Corallo + 2019-10-25T17:30:00.000Z + + + Jeremy + 2019-10-27T19:13:00.000Z + + + David A. Harding + 2019-10-27T22:54:00.000Z + + + Johan Torås Halseth + 2019-10-28T09:45:00.000Z + + + David A. Harding + 2019-10-28T17:14:00.000Z + + + Johan Torås Halseth + 2019-10-30T07:22:00.000Z + + @@ -79,13 +77,13 @@ - python-feedgen + 2 Combined summary - CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) - 2023-08-02T00:11:07.720143+00:00 + 2025-09-26T15:27:09.781189+00:00 - In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly 2019-10-30T07:22:53+00:00 + In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee. This allows the original transaction and its dependent child transaction to be processed more quickly - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Chain-width-expansion.xml b/static/bitcoin-dev/Oct_2019/combined_Chain-width-expansion.xml index 81776b665b..8e108d401e 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Chain-width-expansion.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Chain-width-expansion.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - Chain width expansion - 2023-08-02T01:27:12.173907+00:00 - - Braydon Fuller 2019-10-16 19:25:31+00:00 - - - Braydon Fuller 2019-10-16 19:07:25+00:00 - - - Tier Nolan 2019-10-15 18:30:58+00:00 - - - Joachim Strömbergson 2019-10-15 15:50:29+00:00 - - - Braydon Fuller 2019-10-15 08:12:09+00:00 - - - Joachim Strömbergson 2019-10-15 07:20:07+00:00 - - - Braydon Fuller 2019-10-15 00:42:06+00:00 - - - Braydon Fuller 2019-10-15 00:38:55+00:00 - - - Tier Nolan 2019-10-12 20:46:40+00:00 - - - Joachim Strömbergson 2019-10-12 17:56:51+00:00 - - - Tier Nolan 2019-10-12 16:27:42+00:00 - - - Braydon Fuller 2019-10-11 21:24:27+00:00 - - - Braydon Fuller 2019-10-10 16:16:16+00:00 - - - Tier Nolan 2019-10-04 23:31:18+00:00 - - - Braydon Fuller 2019-10-04 19:51:26+00:00 - - - David A. Harding 2019-10-04 08:20:31+00:00 - - - Braydon Fuller 2019-10-04 00:38:36+00:00 - + 2025-09-26T15:27:14.039342+00:00 + python-feedgen + + + [bitcoin-dev] Chain width expansion Braydon Fuller + 2019-10-04T00:38:00.000Z + + + David A. Harding + 2019-10-04T08:20:00.000Z + + + Braydon Fuller + 2019-10-04T19:51:00.000Z + + + Tier Nolan + 2019-10-04T23:31:00.000Z + + + Braydon Fuller + 2019-10-10T16:16:00.000Z + + + Braydon Fuller + 2019-10-11T21:24:00.000Z + + + Tier Nolan + 2019-10-12T16:27:00.000Z + + + Joachim Strömbergson + 2019-10-12T17:56:00.000Z + + + Tier Nolan + 2019-10-12T20:46:00.000Z + + + Braydon Fuller + 2019-10-15T00:38:00.000Z + + + Braydon Fuller + 2019-10-15T00:42:00.000Z + + + Joachim Strömbergson + 2019-10-15T07:20:00.000Z + + + Braydon Fuller + 2019-10-15T08:12:00.000Z + + + Joachim Strömbergson + 2019-10-15T15:50:00.000Z + + + Tier Nolan + 2019-10-15T18:30:00.000Z + + + Braydon Fuller + 2019-10-16T19:07:00.000Z + + + Braydon Fuller + 2019-10-16T19:25:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - Chain width expansion - 2023-08-02T01:27:12.173907+00:00 + 2025-09-26T15:27:14.041167+00:00 - Joachim Strömbergson proposed a method to generate longer chains with a slow timestamp increase without increasing difficulty. However, this approach is not applicable during a time warp attack where fake timestamps can be created for all blocks except those relevant to the retarget calculation. The Bitcoin-dev community has not yet discussed the timewarp attack.To address this issue, Tier Nolan suggests implementing a soft fork that limits the maximum difference between the timestamp for the first header in a period and the last header in the previous period. This solution is part of a draft proposal called "The Great Consensus Cleanup" and would need to be effective for both the main chain and any future forked chains.Braydon Fuller points out that using the block height in the coinbase for validation purposes is not feasible as it requires previous headers. Instead, it is suggested that the lowest digest for a blockchain represents the total chainwork, and a formula to estimate the total hash count is provided. Producing a fake set of 10 headers with higher work than the main chain would require as much effort as building an alternative chain. However, tracing back to the genesis block for one of those headers would require following the actual chain.The complexity of generating longer chains with a slow timestamp increase while keeping the difficulty at a minimum level is discussed. It is explained that such a chain would result in a reduced time between blocks, about 7 minutes instead of 10 minutes, and the difficulty would adjust accordingly. However, this calculation does not apply during a time warp attack where fake timestamps can be created for all blocks except the first and last block in the 2016 block window. This is in reference to the non-overlapping difficulty calculation and off-by-one bug.In an email exchange, Joachim Strömbergson proposes a method for generating a longer blockchain with a slow timestamp increase without increasing difficulty. However, it is clarified that this calculation does not apply during a time warp attack, where timestamps can be faked for all blocks except those relevant to the retarget calculation. The discussion also addresses the vulnerability of nodes during initial sync when joining the network until the minimum chainwork is achieved.A proposal is made for a "seed" based system to prevent dishonest peers from disrupting chains. This system would require each peer to provide proof of the header with the lowest digest on their main chain, and chains ending at the strongest seeds would be kept preferentially when discarding chains. It is suggested that nodes should stay "headers-only" until they hit a minimum chainwork threshold to mitigate vulnerabilities during initial sync when joining the network. However, there are concerns that this could also be used to prevent nodes from joining the network.Another proposal suggests creating a succinct chainwork proof for all cases in the Bitcoin network. This would involve using a "seed" based system where a header with a very low digest is defined as a seed. Chains ending at the strongest seeds would be kept preferentially when discarding chains. However, this would require a way to download chains backwards, which the protocol currently does not support.David A. Harding discusses a proposed solution for DoS attacks that does not require enabling or maintaining checkpoints. The proposal suggests implementing a new consensus rule to not fork or accept headers below a minimum difficulty once the best chain work is achieved at the release time of the software. However, there are challenges with this approach, including the vulnerability of nodes during initial sync when joining the network until the minimum chainwork is achieved, and the potential for a contentious hardfork leaving minority hash power without the ability to softfork away without agreeing on a hardfork.In an email thread, Tier Nolan discusses the need for peers to prove their total chain proof-of-work (POW). He suggests limiting things by peer rather than globally and tracking the unrequested header rate per peer. Honest peers with more chainwork would have a time advantage over dishonest peers with less chainwork. Nolan gives an example of how this system works, highlighting its susceptibility to Sybil attacks.Overall, the context explores various proposals and discussions related to generating longer chains with a slow timestamp increase without increasing difficulty, preventing time warp attacks, validating block height, and addressing vulnerabilities and security concerns in the Bitcoin network. These discussions highlight the ongoing development and evolution of the network to address new challenges and threats. 2019-10-16T19:25:31+00:00 + Joachim Strömbergson proposed a method to generate longer chains with a slow timestamp increase without increasing difficulty. However, this approach is not applicable during a time warp attack where fake timestamps can be created for all blocks except those relevant to the retarget calculation. The Bitcoin-dev community has not yet discussed the timewarp attack.To address this issue, Tier Nolan suggests implementing a soft fork that limits the maximum difference between the timestamp for the first header in a period and the last header in the previous period. This solution is part of a draft proposal called "The Great Consensus Cleanup" and would need to be effective for both the main chain and any future forked chains.Braydon Fuller points out that using the block height in the coinbase for validation purposes is not feasible as it requires previous headers. Instead, it is suggested that the lowest digest for a blockchain represents the total chainwork, and a formula to estimate the total hash count is provided. Producing a fake set of 10 headers with higher work than the main chain would require as much effort as building an alternative chain. However, tracing back to the genesis block for one of those headers would require following the actual chain.The complexity of generating longer chains with a slow timestamp increase while keeping the difficulty at a minimum level is discussed. It is explained that such a chain would result in a reduced time between blocks, about 7 minutes instead of 10 minutes, and the difficulty would adjust accordingly. However, this calculation does not apply during a time warp attack where fake timestamps can be created for all blocks except the first and last block in the 2016 block window. This is in reference to the non-overlapping difficulty calculation and off-by-one bug.In an email exchange, Joachim Strömbergson proposes a method for generating a longer blockchain with a slow timestamp increase without increasing difficulty. However, it is clarified that this calculation does not apply during a time warp attack, where timestamps can be faked for all blocks except those relevant to the retarget calculation. The discussion also addresses the vulnerability of nodes during initial sync when joining the network until the minimum chainwork is achieved.A proposal is made for a "seed" based system to prevent dishonest peers from disrupting chains. This system would require each peer to provide proof of the header with the lowest digest on their main chain, and chains ending at the strongest seeds would be kept preferentially when discarding chains. It is suggested that nodes should stay "headers-only" until they hit a minimum chainwork threshold to mitigate vulnerabilities during initial sync when joining the network. However, there are concerns that this could also be used to prevent nodes from joining the network.Another proposal suggests creating a succinct chainwork proof for all cases in the Bitcoin network. This would involve using a "seed" based system where a header with a very low digest is defined as a seed. Chains ending at the strongest seeds would be kept preferentially when discarding chains. However, this would require a way to download chains backwards, which the protocol currently does not support.David A. Harding discusses a proposed solution for DoS attacks that does not require enabling or maintaining checkpoints. The proposal suggests implementing a new consensus rule to not fork or accept headers below a minimum difficulty once the best chain work is achieved at the release time of the software. However, there are challenges with this approach, including the vulnerability of nodes during initial sync when joining the network until the minimum chainwork is achieved, and the potential for a contentious hardfork leaving minority hash power without the ability to softfork away without agreeing on a hardfork.In an email thread, Tier Nolan discusses the need for peers to prove their total chain proof-of-work (POW). He suggests limiting things by peer rather than globally and tracking the unrequested header rate per peer. Honest peers with more chainwork would have a time advantage over dishonest peers with less chainwork. Nolan gives an example of how this system works, highlighting its susceptibility to Sybil attacks.Overall, the context explores various proposals and discussions related to generating longer chains with a slow timestamp increase without increasing difficulty, preventing time warp attacks, validating block height, and addressing vulnerabilities and security concerns in the Bitcoin network. These discussions highlight the ongoing development and evolution of the network to address new challenges and threats. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_ChainWallet-A-way-to-prevent-loss-of-funds-by-physical-violence.xml b/static/bitcoin-dev/Oct_2019/combined_ChainWallet-A-way-to-prevent-loss-of-funds-by-physical-violence.xml index 2b154ef23d..bda6ea928d 100644 --- a/static/bitcoin-dev/Oct_2019/combined_ChainWallet-A-way-to-prevent-loss-of-funds-by-physical-violence.xml +++ b/static/bitcoin-dev/Oct_2019/combined_ChainWallet-A-way-to-prevent-loss-of-funds-by-physical-violence.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - ChainWallet - A way to prevent loss of funds by physical violence - 2023-08-02T01:27:40.599570+00:00 - - Bryan Bishop 2019-10-04 10:02:59+00:00 - - - Saulo Fonseca 2019-10-04 09:15:40+00:00 - + 2025-09-26T15:27:11.893543+00:00 + python-feedgen + + + [bitcoin-dev] ChainWallet - A way to prevent loss of funds by physical violence Saulo Fonseca + 2019-10-04T09:15:00.000Z + + + Bryan Bishop + 2019-10-04T10:02:00.000Z + + - python-feedgen + 2 Combined summary - ChainWallet - A way to prevent loss of funds by physical violence - 2023-08-02T01:27:40.599570+00:00 + 2025-09-26T15:27:11.894037+00:00 - Saulo Fonseca has proposed the creation of a new layer of protection called key stretching for cryptocurrency wallets. However, the user cannot prove if they are using this technique or petertodd's timelock encryption, which gives attackers little incentive to stop physically attacking until they have access to spendable UTXOs. To achieve the same effect, it has been suggested to use on-chain timelocks, delete-the-bits with a rangeproof and zero-knowledge proof, or a similar idea proposed by adam3us. You can find more information about adam3us's proposal at https://bitcointalk.org/index.php?topic=311000.0.Another proposal for wallet protection is ChainWallet, which involves creating a chain of hashes over the private key to generate a new wallet. The length of the chain can be easily memorized as an exponent, such as 2^40 or 10^12, and creating a long chain (billions or trillions of hashes) will take a significant amount of time. This prevents coins from being moved in an unplanned way, such as during a kidnapping. The most popular hash algorithm for this method is SHA-256, but other algorithms can also be used. The goal is to add "time" as part of the puzzle, rather than solely relying on entropy.ChainWallet is compared to BrainWallets with an added chain. BrainWallets have a bad reputation due to the possibility of brute-force attacks, but if a ChainWallet takes one second to generate, the speed of an attack is reduced to one guess per second, making a brute force attack practically impossible. Although ChainWallets are not immune to misuse, a wallet implementation could address this issue by enforcing a minimum chain length and blocking commonly used words as passwords. The major advantage of ChainWallet is its ability to prevent theft. Even if someone tries to force the user to give their private key, it would take an extremely long time to generate the wallet, making it practically impossible to access the coins.ChainWallet can be used as an alternative to BIP39, where instead of memorizing 24 words, a password and two numbers (base and exponent) define the length of the chain. This is easier to remember, eliminating the need to write it down. It is important to note that ChainWallet is not applicable in every case and should be considered as an additional option alongside other methods available in the crypto environment, such as multisig and smart contracts.A proof of concept for ChainWallet in C++ can be found on GitHub, and discussions about it can be found on various Reddit threads. The community has been testing the concept for some time and is currently running a challenge to solve it. When a user wants to transfer their coins to another location, they should re-generate their wallet in a planned manner using the same original private key and length of the chain. 2019-10-04T10:02:59+00:00 + Saulo Fonseca has proposed the creation of a new layer of protection called key stretching for cryptocurrency wallets. However, the user cannot prove if they are using this technique or petertodd's timelock encryption, which gives attackers little incentive to stop physically attacking until they have access to spendable UTXOs. To achieve the same effect, it has been suggested to use on-chain timelocks, delete-the-bits with a rangeproof and zero-knowledge proof, or a similar idea proposed by adam3us. You can find more information about adam3us's proposal at https://bitcointalk.org/index.php?topic=311000.0.Another proposal for wallet protection is ChainWallet, which involves creating a chain of hashes over the private key to generate a new wallet. The length of the chain can be easily memorized as an exponent, such as 2^40 or 10^12, and creating a long chain (billions or trillions of hashes) will take a significant amount of time. This prevents coins from being moved in an unplanned way, such as during a kidnapping. The most popular hash algorithm for this method is SHA-256, but other algorithms can also be used. The goal is to add "time" as part of the puzzle, rather than solely relying on entropy.ChainWallet is compared to BrainWallets with an added chain. BrainWallets have a bad reputation due to the possibility of brute-force attacks, but if a ChainWallet takes one second to generate, the speed of an attack is reduced to one guess per second, making a brute force attack practically impossible. Although ChainWallets are not immune to misuse, a wallet implementation could address this issue by enforcing a minimum chain length and blocking commonly used words as passwords. The major advantage of ChainWallet is its ability to prevent theft. Even if someone tries to force the user to give their private key, it would take an extremely long time to generate the wallet, making it practically impossible to access the coins.ChainWallet can be used as an alternative to BIP39, where instead of memorizing 24 words, a password and two numbers (base and exponent) define the length of the chain. This is easier to remember, eliminating the need to write it down. It is important to note that ChainWallet is not applicable in every case and should be considered as an additional option alongside other methods available in the crypto environment, such as multisig and smart contracts.A proof of concept for ChainWallet in C++ can be found on GitHub, and discussions about it can be found on various Reddit threads. The community has been testing the concept for some time and is currently running a challenge to solve it. When a user wants to transfer their coins to another location, they should re-generate their wallet in a planned manner using the same original private key and length of the chain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Continuing-the-discussion-about-noinput-anyprevout.xml b/static/bitcoin-dev/Oct_2019/combined_Continuing-the-discussion-about-noinput-anyprevout.xml index 722807ecb7..d288fd08b7 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Continuing-the-discussion-about-noinput-anyprevout.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Continuing-the-discussion-about-noinput-anyprevout.xml @@ -1,77 +1,155 @@ - + 2 Combined summary - Continuing the discussion about noinput / anyprevout - 2023-08-02T01:23:46.150383+00:00 - - Anthony Towns 2019-10-05 10:06:15+00:00 - - - Christian Decker 2019-10-03 11:08:29+00:00 - - - Christian Decker 2019-10-03 10:30:03+00:00 - - - Christian Decker 2019-10-03 10:01:58+00:00 - - - Christian Decker 2019-10-03 09:57:05+00:00 - - - Christian Decker 2019-10-03 09:42:00+00:00 - - - ZmnSCPxj 2019-10-03 03:07:55+00:00 - - - Anthony Towns 2019-10-03 01:47:58+00:00 - - - s7r 2019-10-02 15:11:25+00:00 - - - ZmnSCPxj 2019-10-02 02:03:43+00:00 - - - Anthony Towns 2019-10-01 15:59:29+00:00 - - - ZmnSCPxj 2019-10-01 15:42:08+00:00 - - - ZmnSCPxj 2019-10-01 15:35:34+00:00 - - - Chris Stewart 2019-10-01 15:14:56+00:00 - - - Anthony Towns 2019-10-01 14:45:48+00:00 - - - Ethan Heilman 2019-10-01 14:27:21+00:00 - - - Christian Decker 2019-10-01 14:26:39+00:00 - - - Christian Decker 2019-10-01 14:20:25+00:00 - - - ZmnSCPxj 2019-10-01 13:31:49+00:00 - - - Chris Stewart 2019-10-01 12:23:47+00:00 - - - ZmnSCPxj 2019-09-30 23:28:43+00:00 - - - ZmnSCPxj 2019-09-30 16:00:35+00:00 - - - Christian Decker 2019-09-30 13:23:56+00:00 - + 2025-09-26T15:27:29.027627+00:00 + python-feedgen + + + [bitcoin-dev] Continuing the discussion about noinput / anyprevout Christian Decker + 2019-09-30T13:23:00.000Z + + + ZmnSCPxj + 2019-09-30T16:00:00.000Z + + + ZmnSCPxj + 2019-09-30T23:28:00.000Z + + + Chris Stewart + 2019-10-01T12:23:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2019-10-01T13:31:00.000Z + + + Christian Decker + 2019-10-01T14:20:00.000Z + + + Christian Decker + 2019-10-01T14:26:00.000Z + + + Ethan Heilman + 2019-10-01T14:27:00.000Z + + + Anthony Towns + 2019-10-01T14:45:00.000Z + + + Chris Stewart + 2019-10-01T15:14:00.000Z + + + ZmnSCPxj + 2019-10-01T15:35:00.000Z + + + ZmnSCPxj + 2019-10-01T15:42:00.000Z + + + [bitcoin-dev] " Anthony Towns + 2019-10-01T15:59:00.000Z + + + ZmnSCPxj + 2019-10-02T02:03:00.000Z + + + [bitcoin-dev] " s7r + 2019-10-02T15:11:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2019-10-03T01:47:00.000Z + + + ZmnSCPxj + 2019-10-03T03:07:00.000Z + + + Christian Decker + 2019-10-03T09:42:00.000Z + + + Christian Decker + 2019-10-03T09:57:00.000Z + + + Christian Decker + 2019-10-03T10:01:00.000Z + + + Christian Decker + 2019-10-03T10:30:00.000Z + + + Christian Decker + 2019-10-03T11:08:00.000Z + + + [bitcoin-dev] OP_CAT was " Ethan Heilman + 2019-10-03T15:05:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2019-10-03T23:42:00.000Z + + + Ethan Heilman + 2019-10-04T00:48:00.000Z + + + Jeremy + 2019-10-04T05:02:00.000Z + + + ZmnSCPxj + 2019-10-04T07:00:00.000Z + + + Peter Todd + 2019-10-04T11:15:00.000Z + + + Jeremy + 2019-10-04T18:33:00.000Z + + + Jeremy + 2019-10-04T18:40:00.000Z + + + Anthony Towns + 2019-10-05T10:06:00.000Z + + + Peter Todd + 2019-10-05T15:49:00.000Z + + + Lloyd Fournier + 2019-10-06T07:02:00.000Z + + + ZmnSCPxj + 2019-10-06T08:46:00.000Z + + + Peter Todd + 2019-10-06T09:12:00.000Z + + + Andrew Poelstra + 2019-10-09T16:56:00.000Z + + @@ -95,13 +173,13 @@ - python-feedgen + 2 Combined summary - Continuing the discussion about noinput / anyprevout - 2023-08-02T01:23:46.150383+00:00 + 2025-09-26T15:27:29.031481+00:00 - In a Bitcoin development mailing list, there have been discussions about various proposals and ideas related to the implementation of new opcodes and public key types. One proposal suggests creating an opcode called `OP_CHECKSIG_WITHOUT_INPUT` that would ignore any `SIGHASH` flags on a signature. Another member suggests encoding the new code in a tapscript public key type. The discussions revolve around the benefits and drawbacks of these proposals for off-chain protocols, particularly for eltoo.There is also a discussion about the usefulness of noinput/anyprevoutanyscript/anyprevout and their potential impact on off-chain protocol designs. While there is general agreement on the adoption of these proposals, concerns are raised about the potential misuse of no_input by bad wallet designers. However, it is suggested that there are simpler ways to cut corners and that good wallet options will always be available.The discussions also touch upon the advantages and disadvantages of chaperone signatures and output tagging/explicit opt-in. Some developers believe that the downsides of chaperone signatures outweigh their benefits, as they require additional code complexity. Output tagging is also seen as potentially negatively impacting the anonymity set of taproot transactions.Efforts are made to merge proposals such as BIP-118 and bip-anyprevout, but chaperone signatures and output tagging are suggested to be part of the discussion of security alternatives rather than the initial specification. It is emphasized that making core code simpler and handling potential issues in higher-level non-consensus code is preferable.In another Bitcoin development discussion, the idea of creating a new opcode called `OP_CHECKSIG_WITHOUT_INPUT` as an alternative to `SIGHASH_NOINPUT` is proposed. However, it is pointed out that there wouldn't be much difference between creating a new opcode and making a new tapscript public key type. The discussions explore the pros and cons of each approach, considering factors such as design space, potential bikeshedding, and signature verification modalities.The discussions also touch upon the proposal of output tagging as a solution for transaction malleability. While some developers see it as a viable solution, others oppose it because it goes against the uniformity of unspent Taproot outputs and may impose additional costs in terms of transaction complexity and anonymity.There are also discussions about the implementation of Decker-Russell-Osuntokun and its potential use cases. Suggestions are made regarding the use of trigger transactions, plain bip-schnorr-signed outputs, and off-chain payment networks to increase anonymity sets and ensure security.Overall, the discussions aim to find optimal solutions for off-chain protocol designs while considering factors such as security, simplicity, and usability.The author of the email expresses concerns about the potential risks associated with the introduction of SIGHASH_NOINPUT in the Bitcoin protocol, particularly in relation to address reuse. They highlight that if a digital signature from a cold storage address with a SIGHASH_NOINPUT signature is replayed on the blockchain, it could lead to fund loss. This becomes especially problematic if the second signing path that uses SIGHASH_NOINPUT gets mixed up with the first signing path that controls an exchange's on-chain funds.Despite these risks, SIGHASH_NOINPUT is seen as a valuable tool for off-chain protocols like Lightning, but it would require large economic entities such as exchanges to have a separate signing path using SIGHASH_NOINPUT to keep on-chain and off-chain hot wallet signing procedures distinct. The author also raises concerns about introducing more complexities into the protocol and suggests disallowing the use of SIGHASH protocols with unexpected behavior.The article discusses two proposals, BIP-118 and bip-anyprevout, which aim to allow rebinding of transactions to new outputs. However, there are still unclear points regarding the dangers of SIGHASH_NOINPUT and chaperone signatures. Chaperone signatures ensure there is no third-party malleability of transactions but have downsides such as additional size and the possibility of protocols using a globally known privkey. Output tagging is proposed as a way to disincentivize non-smart-contract cases by making output scripts unaddressable, potentially creating two domains: one for user-addressable destinations and one for contracts.Christian Decker, a developer at Blockstream, proposes "eltoo" transactions as a means to significantly reduce costs associated with using the Lightning Network. While these transactions are less flexible, they could replace existing ones in the Lightning Network, enabling almost instant and low-cost Bitcoin payments. Decker also suggests using output tagging and chaperone signatures alongside eltoo transactions to enhance security and efficiency.The email proposes the creation of a new opcode, OP_CHECKSIG_WITHOUT_INPUT, equivalent to SIGHASH_NOINPUT, which would be embedded in a Taproot script. This opcode would ignore any SIGHASH flags on a signature and instead hash the current transaction without input references before checking it against the signature. The author questions why there is less 2019-10-05T10:06:15+00:00 + In a Bitcoin development mailing list, there have been discussions about various proposals and ideas related to the implementation of new opcodes and public key types. One proposal suggests creating an opcode called `OP_CHECKSIG_WITHOUT_INPUT` that would ignore any `SIGHASH` flags on a signature. Another member suggests encoding the new code in a tapscript public key type. The discussions revolve around the benefits and drawbacks of these proposals for off-chain protocols, particularly for eltoo.There is also a discussion about the usefulness of noinput/anyprevoutanyscript/anyprevout and their potential impact on off-chain protocol designs. While there is general agreement on the adoption of these proposals, concerns are raised about the potential misuse of no_input by bad wallet designers. However, it is suggested that there are simpler ways to cut corners and that good wallet options will always be available.The discussions also touch upon the advantages and disadvantages of chaperone signatures and output tagging/explicit opt-in. Some developers believe that the downsides of chaperone signatures outweigh their benefits, as they require additional code complexity. Output tagging is also seen as potentially negatively impacting the anonymity set of taproot transactions.Efforts are made to merge proposals such as BIP-118 and bip-anyprevout, but chaperone signatures and output tagging are suggested to be part of the discussion of security alternatives rather than the initial specification. It is emphasized that making core code simpler and handling potential issues in higher-level non-consensus code is preferable.In another Bitcoin development discussion, the idea of creating a new opcode called `OP_CHECKSIG_WITHOUT_INPUT` as an alternative to `SIGHASH_NOINPUT` is proposed. However, it is pointed out that there wouldn't be much difference between creating a new opcode and making a new tapscript public key type. The discussions explore the pros and cons of each approach, considering factors such as design space, potential bikeshedding, and signature verification modalities.The discussions also touch upon the proposal of output tagging as a solution for transaction malleability. While some developers see it as a viable solution, others oppose it because it goes against the uniformity of unspent Taproot outputs and may impose additional costs in terms of transaction complexity and anonymity.There are also discussions about the implementation of Decker-Russell-Osuntokun and its potential use cases. Suggestions are made regarding the use of trigger transactions, plain bip-schnorr-signed outputs, and off-chain payment networks to increase anonymity sets and ensure security.Overall, the discussions aim to find optimal solutions for off-chain protocol designs while considering factors such as security, simplicity, and usability.The author of the email expresses concerns about the potential risks associated with the introduction of SIGHASH_NOINPUT in the Bitcoin protocol, particularly in relation to address reuse. They highlight that if a digital signature from a cold storage address with a SIGHASH_NOINPUT signature is replayed on the blockchain, it could lead to fund loss. This becomes especially problematic if the second signing path that uses SIGHASH_NOINPUT gets mixed up with the first signing path that controls an exchange's on-chain funds.Despite these risks, SIGHASH_NOINPUT is seen as a valuable tool for off-chain protocols like Lightning, but it would require large economic entities such as exchanges to have a separate signing path using SIGHASH_NOINPUT to keep on-chain and off-chain hot wallet signing procedures distinct. The author also raises concerns about introducing more complexities into the protocol and suggests disallowing the use of SIGHASH protocols with unexpected behavior.The article discusses two proposals, BIP-118 and bip-anyprevout, which aim to allow rebinding of transactions to new outputs. However, there are still unclear points regarding the dangers of SIGHASH_NOINPUT and chaperone signatures. Chaperone signatures ensure there is no third-party malleability of transactions but have downsides such as additional size and the possibility of protocols using a globally known privkey. Output tagging is proposed as a way to disincentivize non-smart-contract cases by making output scripts unaddressable, potentially creating two domains: one for user-addressable destinations and one for contracts.Christian Decker, a developer at Blockstream, proposes "eltoo" transactions as a means to significantly reduce costs associated with using the Lightning Network. While these transactions are less flexible, they could replace existing ones in the Lightning Network, enabling almost instant and low-cost Bitcoin payments. Decker also suggests using output tagging and chaperone signatures alongside eltoo transactions to enhance security and efficiency.The email proposes the creation of a new opcode, OP_CHECKSIG_WITHOUT_INPUT, equivalent to SIGHASH_NOINPUT, which would be embedded in a Taproot script. This opcode would ignore any SIGHASH flags on a signature and instead hash the current transaction without input references before checking it against the signature. The author questions why there is less - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Draft-BIP-for-SNICKER.xml b/static/bitcoin-dev/Oct_2019/combined_Draft-BIP-for-SNICKER.xml index 532ee3f67b..0d34809068 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Draft-BIP-for-SNICKER.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Draft-BIP-for-SNICKER.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Draft BIP for SNICKER - 2023-08-02T01:18:16.750104+00:00 - - AdamISZ 2019-11-23 12:43:27+00:00 - - - popo 2019-11-22 14:57:10+00:00 - - - AdamISZ 2019-11-22 14:02:56+00:00 - - - Riccardo Casatta 2019-11-06 16:52:06+00:00 - - - AdamISZ 2019-10-22 13:21:00+00:00 - - - SomberNight 2019-10-21 15:04:59+00:00 - - - Riccardo Casatta 2019-10-21 11:00:26+00:00 - - - David A. Harding 2019-10-21 00:06:08+00:00 - - - SomberNight 2019-10-20 00:29:25+00:00 - - - AdamISZ 2019-09-01 13:46:57+00:00 - + 2025-09-26T15:27:41.815868+00:00 + python-feedgen + + + [bitcoin-dev] Draft BIP for SNICKER AdamISZ + 2019-09-01T13:46:00.000Z + + + SomberNight + 2019-10-20T00:29:00.000Z + + + David A. Harding + 2019-10-21T00:06:00.000Z + + + Riccardo Casatta + 2019-10-21T11:00:00.000Z + + + SomberNight + 2019-10-21T15:04:00.000Z + + + AdamISZ + 2019-10-22T13:21:00.000Z + + + Riccardo Casatta + 2019-11-06T16:52:00.000Z + + + AdamISZ + 2019-11-22T14:02:00.000Z + + + popo + 2019-11-22T14:57:00.000Z + + + AdamISZ + 2019-11-23T12:43:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for SNICKER - 2023-08-02T01:18:16.750104+00:00 + 2025-09-26T15:27:41.816967+00:00 - The SNICKER proposal aims to provide increased privacy benefits over traditional coinjoin in Bitcoin. It suggests a two-party coinjoin implementation that trades off size for convenience and low effort. However, there are no privacy guarantees, and frequent two-party mixes can degrade blockchain analysis. The proposal involves specialized entities as Proposers, with only the Receiver requiring zero effort. Coinjoin breaks the common input ownership heuristic, and the delinking effect of equal-sized outputs of the same scriptpubkey type is valuable.The discussion on the bitcoin-dev mailing list revolves around the issue of watch-only wallets and the key tweak (`c` as per draft BIP) required for effective coinjoin functionality. Classic watch-only use cases are incompatible with SNICKER, but recovering from zero information and monitoring in real-time as new SNICKER transactions arrive are possible. The `c` values could be sent from the hot to the cold wallets without changing the cold's security model.The email exchange discusses the complexity and cost implications of adding second-stage transactions to SNICKER. It aligns with CoinJoinXT and segwit ideas but may not be implemented. The watch-only issue is addressed, emphasizing the need to keep the key tweak secret to the proposer and receiver. AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer are also mentioned. The discussions have been useful in exploring the potential benefits and limitations of SNICKER.Riccardo Casatta proposes a solution to the watch-only issue in CoinJoin transactions, suggesting the creation of a separate encrypted transaction along with the CoinJoin transaction. AdamISZ responds that adding this complexity may not be feasible due to cost implications. The key tweak `c` must be known by the proposer and receiver but not by anyone else, making it incompatible with classic watch-only use cases. However, sending `c` values from the hot wallet to the cold wallet is possible without changing the cold's security model. The discussions highlight the challenges related to watch-only wallets and the security considerations for Receiver from a Proposer.The SNICKER protocol's recovery process is necessary for wallet recovery, requiring communication between the hot and cold wallets. Monitoring a wallet in real-time with no privkey access is incompatible with this, but hot/cold monitoring is feasible if desired. Ongoing address discovery is required for many use cases of watch-only wallets, which would break without SNICKER's functionality.The implementation of SNICKER in Electrum for the "Receiver" role is discussed, highlighting the incompatibility with watch-only wallets. Interaction with the cold wallet is required, and a recovery procedure is proposed. The candidate transactions can be transferred to the cold wallet using means like USB drives or QR codes, and the cold wallet can perform the necessary steps using its private keys. This process may need to be repeated for subsequent SNICKER rounds.The SNICKER proposal aims to break common chain-analysis assumptions and provide increased privacy benefits. However, it is incompatible with watch-only wallets. Users must choose between using xpubs or participating in SNICKER coinjoins as a Receiver during wallet creation. Adjustments to the scheme are unclear, as the key tweak `c` must be known only by the coinjoin participants.A draft BIP for the SNICKER proposal has been shared, highlighting its ease of implementation for wallet developers. However, there is uncertainty on transaction and encryption specifications.The author of the context has implemented the algorithm used by Electrum, but there are concerns regarding its validity. The author is seeking feedback on their draft to address these concerns. It is important to note that the specific details of the algorithm used by Electrum are not provided in the context. However, the fact that the author has attempted to replicate it suggests that it may play a significant role in their work. To gain a better understanding of the algorithm and its implications, it would be helpful to review the feedback and suggestions provided by others. By incorporating this feedback into their draft, the author can strengthen their work and potentially address any doubts or uncertainties surrounding the algorithm's efficacy. In conclusion, the author has implemented an algorithm similar to the one used by Electrum, but there are doubts about its reliability. The author seeks feedback on their draft to ensure the accuracy and effectiveness of their work. Reviewing the algorithm and considering the feedback received will aid in improving the overall quality and validity of the author's implementation. 2019-11-23T12:43:27+00:00 + The SNICKER proposal aims to provide increased privacy benefits over traditional coinjoin in Bitcoin. It suggests a two-party coinjoin implementation that trades off size for convenience and low effort. However, there are no privacy guarantees, and frequent two-party mixes can degrade blockchain analysis. The proposal involves specialized entities as Proposers, with only the Receiver requiring zero effort. Coinjoin breaks the common input ownership heuristic, and the delinking effect of equal-sized outputs of the same scriptpubkey type is valuable.The discussion on the bitcoin-dev mailing list revolves around the issue of watch-only wallets and the key tweak (`c` as per draft BIP) required for effective coinjoin functionality. Classic watch-only use cases are incompatible with SNICKER, but recovering from zero information and monitoring in real-time as new SNICKER transactions arrive are possible. The `c` values could be sent from the hot to the cold wallets without changing the cold's security model.The email exchange discusses the complexity and cost implications of adding second-stage transactions to SNICKER. It aligns with CoinJoinXT and segwit ideas but may not be implemented. The watch-only issue is addressed, emphasizing the need to keep the key tweak secret to the proposer and receiver. AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer are also mentioned. The discussions have been useful in exploring the potential benefits and limitations of SNICKER.Riccardo Casatta proposes a solution to the watch-only issue in CoinJoin transactions, suggesting the creation of a separate encrypted transaction along with the CoinJoin transaction. AdamISZ responds that adding this complexity may not be feasible due to cost implications. The key tweak `c` must be known by the proposer and receiver but not by anyone else, making it incompatible with classic watch-only use cases. However, sending `c` values from the hot wallet to the cold wallet is possible without changing the cold's security model. The discussions highlight the challenges related to watch-only wallets and the security considerations for Receiver from a Proposer.The SNICKER protocol's recovery process is necessary for wallet recovery, requiring communication between the hot and cold wallets. Monitoring a wallet in real-time with no privkey access is incompatible with this, but hot/cold monitoring is feasible if desired. Ongoing address discovery is required for many use cases of watch-only wallets, which would break without SNICKER's functionality.The implementation of SNICKER in Electrum for the "Receiver" role is discussed, highlighting the incompatibility with watch-only wallets. Interaction with the cold wallet is required, and a recovery procedure is proposed. The candidate transactions can be transferred to the cold wallet using means like USB drives or QR codes, and the cold wallet can perform the necessary steps using its private keys. This process may need to be repeated for subsequent SNICKER rounds.The SNICKER proposal aims to break common chain-analysis assumptions and provide increased privacy benefits. However, it is incompatible with watch-only wallets. Users must choose between using xpubs or participating in SNICKER coinjoins as a Receiver during wallet creation. Adjustments to the scheme are unclear, as the key tweak `c` must be known only by the coinjoin participants.A draft BIP for the SNICKER proposal has been shared, highlighting its ease of implementation for wallet developers. However, there is uncertainty on transaction and encryption specifications.The author of the context has implemented the algorithm used by Electrum, but there are concerns regarding its validity. The author is seeking feedback on their draft to address these concerns. It is important to note that the specific details of the algorithm used by Electrum are not provided in the context. However, the fact that the author has attempted to replicate it suggests that it may play a significant role in their work. To gain a better understanding of the algorithm and its implications, it would be helpful to review the feedback and suggestions provided by others. By incorporating this feedback into their draft, the author can strengthen their work and potentially address any doubts or uncertainties surrounding the algorithm's efficacy. In conclusion, the author has implemented an algorithm similar to the one used by Electrum, but there are doubts about its reliability. The author seeks feedback on their draft to ensure the accuracy and effectiveness of their work. Reviewing the algorithm and considering the feedback received will aid in improving the overall quality and validity of the author's implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Human-readable-format-for-private-keys.xml b/static/bitcoin-dev/Oct_2019/combined_Human-readable-format-for-private-keys.xml index dd4072f767..d2c8cb8ca3 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Human-readable-format-for-private-keys.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Human-readable-format-for-private-keys.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Human readable format for private keys - 2023-08-02T01:28:16.279158+00:00 - - JW Weatherman 2019-12-10 02:11:10+00:00 - - - JW Weatherman 2019-10-05 22:51:20+00:00 - + 2025-09-26T15:27:37.538904+00:00 + python-feedgen + + + [bitcoin-dev] Human readable format for private keys JW Weatherman + 2019-10-05T22:51:00.000Z + + + JW Weatherman + 2019-12-10T02:11:00.000Z + + - python-feedgen + 2 Combined summary - Human readable format for private keys - 2023-08-02T01:28:16.279158+00:00 + 2025-09-26T15:27:37.539395+00:00 - JW Weatherman has proposed a feature for Bitcoin that aims to solve issues related to private keys. Currently, mistakes can be made when reading or writing private keys, and errors are only identified once the entire key is entered. This lack of error indication and the potential loss of private keys stored on paper due to the loss of a single character pose significant problems.To address these issues, JW Weatherman suggests using the NATO phonetic alphabet to display or enter private keys. In this system, lower case letters are indicated by not capitalizing the word, while capital letters and numbers should be capitalized. The use of the internationally recognized NATO phonetic alphabet ensures that each letter is easily distinguishable when spoken and written, reducing the likelihood of errors during recovery.The proposal also includes the insertion of checksum letters into the private key. Specifically, every 5th word in the key would serve as a checksum for the previous 4 words. For example, a sentence like "ALFA tango THREE SIX bravo" would have "bravo" as the checksum for the preceding 4 words. This checksum can be calculated and verified as the private key is entered. If an error is made, the checksum would immediately indicate it within the 5-word segment. Moreover, even if an entire word is lost across multiple lines, the checksum would make it relatively easy to guess the correct words.During a live demonstration, JW Weatherman showcased the use of the NATO alphabet and checksums every 4 words. This approach removes the stress of attempting to write unambiguous characters and makes typing with autocomplete easier, particularly when the word dictionary is not involved.The proposal seeks adoption by Bitcoin Core as it utilizes existing private keys without impacting key generation. Furthermore, it does not require a standardized and well-known word list for every language. Essentially, this proposal serves as a display format that ideally would not necessitate invasive code changes. 2019-12-10T02:11:10+00:00 + JW Weatherman has proposed a feature for Bitcoin that aims to solve issues related to private keys. Currently, mistakes can be made when reading or writing private keys, and errors are only identified once the entire key is entered. This lack of error indication and the potential loss of private keys stored on paper due to the loss of a single character pose significant problems.To address these issues, JW Weatherman suggests using the NATO phonetic alphabet to display or enter private keys. In this system, lower case letters are indicated by not capitalizing the word, while capital letters and numbers should be capitalized. The use of the internationally recognized NATO phonetic alphabet ensures that each letter is easily distinguishable when spoken and written, reducing the likelihood of errors during recovery.The proposal also includes the insertion of checksum letters into the private key. Specifically, every 5th word in the key would serve as a checksum for the previous 4 words. For example, a sentence like "ALFA tango THREE SIX bravo" would have "bravo" as the checksum for the preceding 4 words. This checksum can be calculated and verified as the private key is entered. If an error is made, the checksum would immediately indicate it within the 5-word segment. Moreover, even if an entire word is lost across multiple lines, the checksum would make it relatively easy to guess the correct words.During a live demonstration, JW Weatherman showcased the use of the NATO alphabet and checksums every 4 words. This approach removes the stress of attempting to write unambiguous characters and makes typing with autocomplete easier, particularly when the word dictionary is not involved.The proposal seeks adoption by Bitcoin Core as it utilizes existing private keys without impacting key generation. Furthermore, it does not require a standardized and well-known word list for every language. Essentially, this proposal serves as a display format that ideally would not necessitate invasive code changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Is-Signet-Bitcoin-.xml b/static/bitcoin-dev/Oct_2019/combined_Is-Signet-Bitcoin-.xml index 1600505e8d..9f3cc0a285 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Is-Signet-Bitcoin-.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Is-Signet-Bitcoin-.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Is Signet Bitcoin? - 2023-08-02T01:28:39.567734+00:00 - - Matt Corallo 2019-10-15 05:33:53+00:00 - - - Jonathan Underwood 2019-10-15 04:38:29+00:00 - - - Karl-Johan Alm 2019-10-15 02:54:28+00:00 - + 2025-09-26T15:27:20.489866+00:00 + python-feedgen + + + [bitcoin-dev] Is Signet Bitcoin? Karl-Johan Alm + 2019-10-15T02:54:00.000Z + + + Jonathan Underwood + 2019-10-15T04:38:00.000Z + + + Matt Corallo + 2019-10-15T05:33:00.000Z + + - python-feedgen + 2 Combined summary - Is Signet Bitcoin? - 2023-08-02T01:28:39.567734+00:00 + 2025-09-26T15:27:20.490396+00:00 - The recent pull request to add Signet to the BIPs repository has encountered a delay as the maintainer is uncertain about whether Signet should have a BIP at all. The question at hand is whether Signet can be considered Bitcoin or not. While some argue that Signet is Bitcoin and having a BIP would enhance interoperability among various software in the Bitcoin community, others view Signet as "interoperability for how to build good testing for Bitcoin" rather than being Bitcoin itself.The proposal for Signet stems from an issue with the reliability of Testnet, which is commonly utilized for Bitcoin development purposes. In order to tackle this problem and enhance the development environment for Bitcoin, there has been a suggestion to create a more reliable type of testnet. However, the debate revolves around the distinction between Testnet and Signet. Despite neither being completely compatible with the mainnet consensus processes, Testnet is considered Bitcoin while Signet is not. Jon seeks an understanding of the reasoning behind these distinctions.In conclusion, the pull request for Signet in the bips repository has hit a roadblock due to uncertainty regarding its status as a BIP. The maintainer questions whether Signet qualifies as Bitcoin, although proponents argue that it does. They believe that having a BIP for Signet would promote interoperability within the Bitcoin software ecosystem. Feedback on this matter is encouraged and can be provided directly on the pull request or via the bitcoin-dev mailing list. 2019-10-15T05:33:53+00:00 + The recent pull request to add Signet to the BIPs repository has encountered a delay as the maintainer is uncertain about whether Signet should have a BIP at all. The question at hand is whether Signet can be considered Bitcoin or not. While some argue that Signet is Bitcoin and having a BIP would enhance interoperability among various software in the Bitcoin community, others view Signet as "interoperability for how to build good testing for Bitcoin" rather than being Bitcoin itself.The proposal for Signet stems from an issue with the reliability of Testnet, which is commonly utilized for Bitcoin development purposes. In order to tackle this problem and enhance the development environment for Bitcoin, there has been a suggestion to create a more reliable type of testnet. However, the debate revolves around the distinction between Testnet and Signet. Despite neither being completely compatible with the mainnet consensus processes, Testnet is considered Bitcoin while Signet is not. Jon seeks an understanding of the reasoning behind these distinctions.In conclusion, the pull request for Signet in the bips repository has hit a roadblock due to uncertainty regarding its status as a BIP. The maintainer questions whether Signet qualifies as Bitcoin, although proponents argue that it does. They believe that having a BIP for Signet would promote interoperability within the Bitcoin software ecosystem. Feedback on this matter is encouraged and can be provided directly on the pull request or via the bitcoin-dev mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_OP-CAT-was-Re-Continuing-the-discussion-about-noinput-anyprevout.xml b/static/bitcoin-dev/Oct_2019/combined_OP-CAT-was-Re-Continuing-the-discussion-about-noinput-anyprevout.xml index 532094c38a..9e101c2b4b 100644 --- a/static/bitcoin-dev/Oct_2019/combined_OP-CAT-was-Re-Continuing-the-discussion-about-noinput-anyprevout.xml +++ b/static/bitcoin-dev/Oct_2019/combined_OP-CAT-was-Re-Continuing-the-discussion-about-noinput-anyprevout.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - OP_CAT was Re: Continuing the discussion about noinput / anyprevout - 2023-08-02T01:25:51.727532+00:00 + 2025-09-26T15:27:07.612358+00:00 + python-feedgen Andrew Poelstra 2019-10-09 16:56:51+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - OP_CAT was Re: Continuing the discussion about noinput / anyprevout - 2023-08-02T01:25:51.727532+00:00 + 2025-09-26T15:27:07.612566+00:00 - The conversations surrounding the development of Bitcoin have focused on various opcodes and approaches to improve efficiency, address limitations, and enable new possibilities for protocol building. One proposal suggests encoding `SIGHASH` on public keys by using either 33-byte or 34-byte representations, which would allow operations like `OP_CHECKSIG` to determine the sighash algorithm based on the public key rather than the signature.Another topic of discussion has been the limitations of Merkle trees in Bitcoin blocks, specifically in determining whether a hash represents a subnode or a leaf transaction. To address this, there is a proposal to implement tagged SHA256 as a new opcode, which could help solve the issue.There have also been considerations about the usefulness and efficiency of OP_CAT, an opcode that concatenates stack values. Concerns have been raised regarding its efficiency and behavior when allocating new memory and copying existing data. Suggestions have been made to set maximum output size limits for OP_CAT, ranging from 64 bytes to 256 bytes, as a way to reduce worst-case behavior.The Lightning-dev mailing list has seen discussions about replacing OP_CAT with OP_SHA256STREAM, which would allow unlimited data concatenation using the streaming properties of a SHA256 hash function. The advantages and disadvantages of this proposal have been explored, including the tension between generic-use components and specific-use components. However, it is noted that OP_SHA256STREAM would become unusable if SHA256 is ever compromised.Various individuals have shared their opinions on OP_CAT versus other options like SHA256STREAM in email threads. Additionally, conversations have revolved around scriptless scripts, adaptor signatures, and paying for a merkle path without validating it on-chain.Throughout these discussions, participants emphasize the need for basic tools and opcodes like OP_CAT to facilitate the development of future protocols on Bitcoin. They also highlight the importance of designing layer 2 protocols first and then adapting layer 1 accordingly.In summary, the conversations surrounding Bitcoin's development involve evaluating the benefits and trade-offs of different opcodes and approaches. The focus is on improving efficiency, addressing limitations, and enabling new possibilities for protocol building. Notably, developments such as the introduction of new opcodes and the proposed `OP_SETPUBKEYSIGHASH` are significant for enhancing the security and privacy of Bitcoin transactions. 2019-10-09T16:56:51+00:00 + The conversations surrounding the development of Bitcoin have focused on various opcodes and approaches to improve efficiency, address limitations, and enable new possibilities for protocol building. One proposal suggests encoding `SIGHASH` on public keys by using either 33-byte or 34-byte representations, which would allow operations like `OP_CHECKSIG` to determine the sighash algorithm based on the public key rather than the signature.Another topic of discussion has been the limitations of Merkle trees in Bitcoin blocks, specifically in determining whether a hash represents a subnode or a leaf transaction. To address this, there is a proposal to implement tagged SHA256 as a new opcode, which could help solve the issue.There have also been considerations about the usefulness and efficiency of OP_CAT, an opcode that concatenates stack values. Concerns have been raised regarding its efficiency and behavior when allocating new memory and copying existing data. Suggestions have been made to set maximum output size limits for OP_CAT, ranging from 64 bytes to 256 bytes, as a way to reduce worst-case behavior.The Lightning-dev mailing list has seen discussions about replacing OP_CAT with OP_SHA256STREAM, which would allow unlimited data concatenation using the streaming properties of a SHA256 hash function. The advantages and disadvantages of this proposal have been explored, including the tension between generic-use components and specific-use components. However, it is noted that OP_SHA256STREAM would become unusable if SHA256 is ever compromised.Various individuals have shared their opinions on OP_CAT versus other options like SHA256STREAM in email threads. Additionally, conversations have revolved around scriptless scripts, adaptor signatures, and paying for a merkle path without validating it on-chain.Throughout these discussions, participants emphasize the need for basic tools and opcodes like OP_CAT to facilitate the development of future protocols on Bitcoin. They also highlight the importance of designing layer 2 protocols first and then adapting layer 1 accordingly.In summary, the conversations surrounding Bitcoin's development involve evaluating the benefits and trade-offs of different opcodes and approaches. The focus is on improving efficiency, addressing limitations, and enabling new possibilities for protocol building. Notably, developments such as the introduction of new opcodes and the proposed `OP_SETPUBKEYSIGHASH` are significant for enhancing the security and privacy of Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml b/static/bitcoin-dev/Oct_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml index 58375ba71b..1ca1cbcbf6 100644 --- a/static/bitcoin-dev/Oct_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml +++ b/static/bitcoin-dev/Oct_2019/combined_OP-SECURETHEBAG-supersedes-OP-CHECKOUTPUTSVERIFY-.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) - 2023-08-02T00:56:33.739774+00:00 - - Jeremy 2019-10-03 23:22:47+00:00 - - - Dmitry Petukhov 2019-07-08 10:26:24+00:00 - - - Russell O'Connor 2019-06-25 17:05:39+00:00 - - - Jeremy 2019-06-24 22:47:44+00:00 - - - Russell O'Connor 2019-06-24 18:48:51+00:00 - - - Jeremy 2019-06-24 18:07:20+00:00 - - - Russell O'Connor 2019-06-24 14:34:54+00:00 - - - ZmnSCPxj 2019-06-23 13:11:03+00:00 - - - Jeremy 2019-06-23 06:43:22+00:00 - - - Anthony Towns 2019-06-20 22:05:52+00:00 - - - Russell O'Connor 2019-06-18 20:57:34+00:00 - - - ZmnSCPxj 2019-06-06 07:30:13+00:00 - - - Anthony Towns 2019-06-05 09:30:39+00:00 - - - Jeremy 2019-06-02 21:32:20+00:00 - - - Russell O'Connor 2019-06-02 14:32:33+00:00 - - - ZmnSCPxj 2019-06-02 05:35:43+00:00 - - - Jeremy 2019-06-01 05:35:45+00:00 - + 2025-09-26T15:27:33.301777+00:00 + python-feedgen + + + [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) Jeremy + 2019-06-01T05:35:00.000Z + + + ZmnSCPxj + 2019-06-02T05:35:00.000Z + + + Russell O'Connor + 2019-06-02T14:32:00.000Z + + + Jeremy + 2019-06-02T21:32:00.000Z + + + Anthony Towns + 2019-06-05T09:30:00.000Z + + + ZmnSCPxj + 2019-06-06T07:30:00.000Z + + + Russell O'Connor + 2019-06-18T20:57:00.000Z + + + Anthony Towns + 2019-06-20T22:05:00.000Z + + + Jeremy + 2019-06-23T06:43:00.000Z + + + ZmnSCPxj + 2019-06-23T13:11:00.000Z + + + Russell O'Connor + 2019-06-24T14:34:00.000Z + + + Jeremy + 2019-06-24T18:07:00.000Z + + + Russell O'Connor + 2019-06-24T18:48:00.000Z + + + Jeremy + 2019-06-24T22:47:00.000Z + + + Russell O'Connor + 2019-06-25T17:05:00.000Z + + + Dmitry Petukhov + 2019-07-08T10:26:00.000Z + + + Jeremy + 2019-10-03T23:22:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) - 2023-08-02T00:56:33.739774+00:00 + 2025-09-26T15:27:33.303888+00:00 - Jeremy Rubin has proposed an update to the Bitcoin Improvement Proposal (BIP) that replaces Taproot with an OP_NOP upgrade. The BIP introduces OP_NOP4, which enables the OP_SECURETHEBAG feature for segwit and bare script, but not P2SH. Dmitry Petukhov suggests using a control-sig to restrict spending conditions and proposes additional flags for sighash. Anthony Towns suggests simulating OP_SECURETHEBAG with an ANYPREVOUT sighash. The bitcoin-dev mailing list discusses eliminating malleability in UTXOs using the ANYPREVOUTANYSCRIPT signature and the need for improvements in tapscript implementation. There are suggestions to improve script parsing, versioning techniques, and compatibility with templated scripts. The author of the context argues against the use of OP_IF and proposes upgrading the script parser with a new interpreter for Tapscript. They also discuss the introduction of Turing-completeness in Bitcoin SCRIPT and the potential for creating covenants using OP_TWEEKPUBKEY.The debate revolves around the complexity of changes to Bitcoin Core and the need to ensure script semantics are easily understandable. There is a proposal to add the OP_SECURETHEBAG opcode to modify public keys in Bitcoin script, but concerns are raised about its impact on script composability. The commitment of the script itself is questioned, and suggestions are made to include it in the opcode or use an OP_TWEEKPUBKEY operation. Additionally, the possibility of enabling recursive covenants and making Bitcoin SCRIPT Turing-complete is discussed.An alternative approach using an ANYPREVOUT sighash to simulate OP_SECURETHEBAG is suggested. This involves calculating a signature for a pubkey and using "CHECKSIG" in the script. Issues regarding commitment to inputs and the size of the script are raised. Another proposal for an opcode called OP_CHECKTXDIGESTVERIFY is discussed, which could enable covenants and Turing-complete smart contracts. The debate centers around the need to precommit the digest as part of the opcode.In conclusion, the bitcoin-dev mailing list discusses various proposals and improvements related to script semantics, malleability in UTXOs, and the introduction of new opcodes. The focus is on enhancing tapscript implementation, enabling covenants, and exploring the potential for Turing-completeness in Bitcoin SCRIPT.On May 31, 2019, Jeremy Rubin announced the retraction of the proposed opcode 'OP_CHECKOUTPUTSHASHVERIFY' in favor of a new opcode called 'OP_SECURETHEBAG'. The new opcode aims to fix malleability issues and lift the single output restriction to a known number of inputs restriction. It allows for more flexibility while still keeping the ease of use. The proposed change involves pulling a 33-byte value from the stack, consisting of a sha256 hash and a sighash-byte, and adding a new sighash value corresponding to the set of information to include in the hash.The author acknowledges receiving a response from someone named Russell and admits to having missed some points of concern related to malleability. They provide a code snippet showing how TXID is computed and mention that it can be modified in certain cases, leading to potential security issues. However, the author mentions that they have revisited their work and believe they have addressed all the concerns related to malleability. They express hope that their changes will fully address the issue.The new opcode, OP_SECURETHEBAG, commits to both version and locktime, which was not possible with the previous opcode. It also lifts the restriction on the number of inputs needed, allowing for more flexibility. However, this feature requires special design to be safe, and a backout transaction is required before the funding transaction output is committed onchain. For Poon-Dryja channels, the initial commitment transaction is used as the backout transaction. The continued operation of the protocol requires the initial commitment to be revoked at the next update. A plausible backout for the receiver is needed for this purpose. To do so, the funding transaction address is made a Taproot with an internal pubkey 2-of-2 of the receiver and its channel counterparty.The proposed OP_CHECKOUTPUTSHASHVERIFY has been retracted in favor of the new proposal, OP_SECURETHEBAG. The new proposal fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. The previous proposal had some issues with malleability of version and locktime. OP_SECURETHEBAG commits to both of these values and also lifts the restriction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, and instead just commits to the number of inputs. This allows for more flexibility but keeps it easy to get the same single output restriction.A BIP is available at https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki and the implementation can be found at 2019-10-03T23:22:47+00:00 + Jeremy Rubin has proposed an update to the Bitcoin Improvement Proposal (BIP) that replaces Taproot with an OP_NOP upgrade. The BIP introduces OP_NOP4, which enables the OP_SECURETHEBAG feature for segwit and bare script, but not P2SH. Dmitry Petukhov suggests using a control-sig to restrict spending conditions and proposes additional flags for sighash. Anthony Towns suggests simulating OP_SECURETHEBAG with an ANYPREVOUT sighash. The bitcoin-dev mailing list discusses eliminating malleability in UTXOs using the ANYPREVOUTANYSCRIPT signature and the need for improvements in tapscript implementation. There are suggestions to improve script parsing, versioning techniques, and compatibility with templated scripts. The author of the context argues against the use of OP_IF and proposes upgrading the script parser with a new interpreter for Tapscript. They also discuss the introduction of Turing-completeness in Bitcoin SCRIPT and the potential for creating covenants using OP_TWEEKPUBKEY.The debate revolves around the complexity of changes to Bitcoin Core and the need to ensure script semantics are easily understandable. There is a proposal to add the OP_SECURETHEBAG opcode to modify public keys in Bitcoin script, but concerns are raised about its impact on script composability. The commitment of the script itself is questioned, and suggestions are made to include it in the opcode or use an OP_TWEEKPUBKEY operation. Additionally, the possibility of enabling recursive covenants and making Bitcoin SCRIPT Turing-complete is discussed.An alternative approach using an ANYPREVOUT sighash to simulate OP_SECURETHEBAG is suggested. This involves calculating a signature for a pubkey and using "CHECKSIG" in the script. Issues regarding commitment to inputs and the size of the script are raised. Another proposal for an opcode called OP_CHECKTXDIGESTVERIFY is discussed, which could enable covenants and Turing-complete smart contracts. The debate centers around the need to precommit the digest as part of the opcode.In conclusion, the bitcoin-dev mailing list discusses various proposals and improvements related to script semantics, malleability in UTXOs, and the introduction of new opcodes. The focus is on enhancing tapscript implementation, enabling covenants, and exploring the potential for Turing-completeness in Bitcoin SCRIPT.On May 31, 2019, Jeremy Rubin announced the retraction of the proposed opcode 'OP_CHECKOUTPUTSHASHVERIFY' in favor of a new opcode called 'OP_SECURETHEBAG'. The new opcode aims to fix malleability issues and lift the single output restriction to a known number of inputs restriction. It allows for more flexibility while still keeping the ease of use. The proposed change involves pulling a 33-byte value from the stack, consisting of a sha256 hash and a sighash-byte, and adding a new sighash value corresponding to the set of information to include in the hash.The author acknowledges receiving a response from someone named Russell and admits to having missed some points of concern related to malleability. They provide a code snippet showing how TXID is computed and mention that it can be modified in certain cases, leading to potential security issues. However, the author mentions that they have revisited their work and believe they have addressed all the concerns related to malleability. They express hope that their changes will fully address the issue.The new opcode, OP_SECURETHEBAG, commits to both version and locktime, which was not possible with the previous opcode. It also lifts the restriction on the number of inputs needed, allowing for more flexibility. However, this feature requires special design to be safe, and a backout transaction is required before the funding transaction output is committed onchain. For Poon-Dryja channels, the initial commitment transaction is used as the backout transaction. The continued operation of the protocol requires the initial commitment to be revoked at the next update. A plausible backout for the receiver is needed for this purpose. To do so, the funding transaction address is made a Taproot with an internal pubkey 2-of-2 of the receiver and its channel counterparty.The proposed OP_CHECKOUTPUTSHASHVERIFY has been retracted in favor of the new proposal, OP_SECURETHEBAG. The new proposal fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. The previous proposal had some issues with malleability of version and locktime. OP_SECURETHEBAG commits to both of these values and also lifts the restriction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, and instead just commits to the number of inputs. This allows for more flexibility but keeps it easy to get the same single output restriction.A BIP is available at https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki and the implementation can be found at - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_PSBT-global-key-for-network.xml b/static/bitcoin-dev/Oct_2019/combined_PSBT-global-key-for-network.xml index 886ea84346..f5496ec5e0 100644 --- a/static/bitcoin-dev/Oct_2019/combined_PSBT-global-key-for-network.xml +++ b/static/bitcoin-dev/Oct_2019/combined_PSBT-global-key-for-network.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - PSBT global key for network - 2023-08-02T01:26:05.543206+00:00 - - 木ノ下じょな 2019-10-04 05:54:52+00:00 - - - Jimmy Song 2019-10-03 20:14:22+00:00 - + 2025-09-26T15:27:24.726789+00:00 + python-feedgen + + + [bitcoin-dev] PSBT global key for network Jimmy Song + 2019-10-03T20:14:00.000Z + + + 木ノ下じょな + 2019-10-04T05:54:00.000Z + + - python-feedgen + 2 Combined summary - PSBT global key for network - 2023-08-02T01:26:05.543206+00:00 + 2025-09-26T15:27:24.727237+00:00 - In an email to the bitcoin-dev mailing list, Jimmy Song has proposed adding a new key-value pair to the global context of BIP174, Partially-Signed Bitcoin Transactions (PSBT). The proposal aims to indicate the network that the coins are on, as it is important for each signer to ensure that the inputs being referenced in the PSBT exist. This information becomes even more crucial when dealing with Proof-of-Reserves inputs.According to the proposal, the suggested key for network in the global key-value store is 0x03. The corresponding value would be a variable integer that specifies the network. For Bitcoin mainnet, the value 0x00 would be used, while for Bitcoin testnet, the value 0x01 would be used. This way, it becomes easier to identify which network the coins belong to.Furthermore, the proposal states that other coins interested in using the PSBT should follow the coin network number from SLIP-0044, but with the high bit removed. This ensures compatibility and consistency across different networks.However, Jon, in his response to the email, argues against the inclusion of a network section in the PSBT. He believes that the only time the network could pose a problem is in the case of a fork-coin. In such cases, adding a network section would not help verify anything and might give a false sense of security. Instead, it could be seen as a security minus.Currently, BitcoinJS utilizes network parameters to allow for the use of addresses in addOutput. However, Jon is considering removing this feature, further questioning the necessity of a network section in the PSBT.Overall, the proposal by Jimmy Song suggests adding a key-value pair to indicate the network in the global context of BIP174, Partially-Signed Bitcoin Transactions. While it aims to provide clarity and ensure the existence of referenced inputs, there are differing opinions on its usefulness. Nevertheless, the proposal leaves room for potential extension to other networks in the future. 2019-10-04T05:54:52+00:00 + In an email to the bitcoin-dev mailing list, Jimmy Song has proposed adding a new key-value pair to the global context of BIP174, Partially-Signed Bitcoin Transactions (PSBT). The proposal aims to indicate the network that the coins are on, as it is important for each signer to ensure that the inputs being referenced in the PSBT exist. This information becomes even more crucial when dealing with Proof-of-Reserves inputs.According to the proposal, the suggested key for network in the global key-value store is 0x03. The corresponding value would be a variable integer that specifies the network. For Bitcoin mainnet, the value 0x00 would be used, while for Bitcoin testnet, the value 0x01 would be used. This way, it becomes easier to identify which network the coins belong to.Furthermore, the proposal states that other coins interested in using the PSBT should follow the coin network number from SLIP-0044, but with the high bit removed. This ensures compatibility and consistency across different networks.However, Jon, in his response to the email, argues against the inclusion of a network section in the PSBT. He believes that the only time the network could pose a problem is in the case of a fork-coin. In such cases, adding a network section would not help verify anything and might give a false sense of security. Instead, it could be seen as a security minus.Currently, BitcoinJS utilizes network parameters to allow for the use of addresses in addOutput. However, Jon is considering removing this feature, further questioning the necessity of a network section in the PSBT.Overall, the proposal by Jimmy Song suggests adding a key-value pair to indicate the network in the global context of BIP174, Partially-Signed Bitcoin Transactions. While it aims to provide clarity and ensure the existence of referenced inputs, there are differing opinions on its usefulness. Nevertheless, the proposal leaves room for potential extension to other networks in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Removal-of-reject-network-messages-from-Bitcoin-Core-BIP61-.xml b/static/bitcoin-dev/Oct_2019/combined_Removal-of-reject-network-messages-from-Bitcoin-Core-BIP61-.xml index dbcd619b4f..f4b6e24197 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Removal-of-reject-network-messages-from-Bitcoin-Core-BIP61-.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Removal-of-reject-network-messages-from-Bitcoin-Core-BIP61-.xml @@ -1,74 +1,99 @@ - + 2 Combined summary - Removal of reject network messages from Bitcoin Core (BIP61) - 2023-08-02T00:34:07.125703+00:00 - - Andreas Schildbach 2019-10-21 08:44:16+00:00 - - - Eric Voskuil 2019-10-20 05:13:12+00:00 - - - David A. Harding 2019-10-18 22:45:35+00:00 - - - John Newbery 2019-10-18 20:53:23+00:00 - - - Eric Voskuil 2019-10-17 20:16:47+00:00 - - - Andreas Schildbach 2019-10-17 19:38:53+00:00 - - - John Newbery 2019-10-16 16:43:53+00:00 - - - Aymeric Vitte 2019-03-14 09:46:28+00:00 - - - Dustin Dettmer 2019-03-13 22:30:44+00:00 - - - Oscar Guindzberg 2019-03-13 14:41:50+00:00 - - - Andreas Schildbach 2019-03-13 14:29:43+00:00 - - - Gregory Maxwell 2019-03-12 22:14:10+00:00 - - - Andreas Schildbach 2019-03-12 17:08:52+00:00 - - - Gregory Maxwell 2019-03-08 00:52:56+00:00 - - - Eric Voskuil 2019-03-08 00:30:51+00:00 - - - Wilmer Paulino 2019-03-08 00:09:01+00:00 - - - Aymeric Vitte 2019-03-07 20:52:33+00:00 - - - Andreas Schildbach 2019-03-07 17:58:01+00:00 - - - Sjors Provoost 2019-03-07 13:59:47+00:00 - - - Andreas Schildbach 2019-03-06 16:49:20+00:00 - - - Dustin Dettmer 2019-03-06 04:00:35+00:00 - - - Marco Falke 2019-03-06 00:53:18+00:00 - + 2025-09-26T15:27:18.370960+00:00 + python-feedgen + + + [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) Marco Falke + 2019-03-06T00:53:00.000Z + + + Dustin Dettmer + 2019-03-06T04:00:00.000Z + + + Andreas Schildbach + 2019-03-06T16:49:00.000Z + + + Sjors Provoost + 2019-03-07T13:59:00.000Z + + + Andreas Schildbach + 2019-03-07T17:58:00.000Z + + + Aymeric Vitte + 2019-03-07T20:52:00.000Z + + + Wilmer Paulino + 2019-03-08T00:09:00.000Z + + + Eric Voskuil + 2019-03-08T00:30:00.000Z + + + Gregory Maxwell + 2019-03-08T00:52:00.000Z + + + Andreas Schildbach + 2019-03-12T17:08:00.000Z + + + Gregory Maxwell + 2019-03-12T22:14:00.000Z + + + Andreas Schildbach + 2019-03-13T14:29:00.000Z + + + Oscar Guindzberg + 2019-03-13T14:41:00.000Z + + + Dustin Dettmer + 2019-03-13T22:30:00.000Z + + + Aymeric Vitte + 2019-03-14T09:46:00.000Z + + + John Newbery + 2019-10-16T16:43:00.000Z + + + Andreas Schildbach + 2019-10-17T19:38:00.000Z + + + Eric Voskuil + 2019-10-17T20:16:00.000Z + + + John Newbery + 2019-10-18T20:53:00.000Z + + + David A. Harding + 2019-10-18T22:45:00.000Z + + + Eric Voskuil + 2019-10-20T05:13:00.000Z + + + Andreas Schildbach + 2019-10-21T08:44:00.000Z + + @@ -91,13 +116,13 @@ - python-feedgen + 2 Combined summary - Removal of reject network messages from Bitcoin Core (BIP61) - 2023-08-02T00:34:07.125703+00:00 + 2025-09-26T15:27:18.373187+00:00 - In a recent discussion on the bitcoin-dev mailing list, the use of "reject" messages in the Bitcoin network was debated. It was argued that nodes on the network cannot be trusted to send valid reject messages, so this feature should only be used when connected to a trusted node. However, it was also pointed out that nodes generally rely on the assumption they are connected to at least one honest peer, allowing for a convergence on the set of honest peers and the ability to ban or disconnect those who send invalid reject messages for valid transactions.Bitcoin Core developer, Marco Falke, proposed removing the reject message feature from Bitcoin Core to make the codebase slimmer. However, it was noted that Neutrino, a light client implementation, currently relies on receiving reject messages from its peers when broadcasting a transaction to the network. Despite this, Falke believes that removing the feature would help in terms of comprehension and maintainability. The alternative recommended by Falke is not suitable for use cases where the main thing required is identification of whether a broadcasted transaction is valid or not. Reject messages are also useful when developing new light clients, as feedback from the network on why a transaction was rejected helps identify potential bugs in their transaction crafting logic. While Falke suggested testing the validity of a transaction through specific RPCs, such as `sendrawtransaction` and `testmempoolaccept`, these are not helpful for light clients. Therefore, it is believed that disabling the reject message feature by default would hinder light clients' ability to realize they are broadcasting invalid transactions. Thus, the feature should remain enabled by default to aid the light clients of the network.Bitcoin Core may remove the reject messages feature from its system, as it has been disabled by default since version 0.18.0. This feature is toggled by the `-enablebip61` command line option. Developers have proposed alternative testing methods for those who rely on the feature, including inspecting log messages produced by a recent version of Bitcoin Core, using specific RPCs to test the validity of blocks and transactions, and relying on fee estimation to determine transaction fees and setting replace-by-fee if desired. The proposal to remove the feature from Bitcoin Core 0.19.0 has been made unless there are valid concerns about its removal.Overall, the debate centers around the trustworthiness of reject messages sent by nodes on the Bitcoin network. While some argue that this feature should only be used when connected to trusted nodes, others believe that removing it would make the codebase slimmer and easier to maintain. However, alternative testing methods have been proposed, and it is important to consider the impact on light clients and their ability to identify and correct invalid transactions. 2019-10-21T08:44:16+00:00 + In a recent discussion on the bitcoin-dev mailing list, the use of "reject" messages in the Bitcoin network was debated. It was argued that nodes on the network cannot be trusted to send valid reject messages, so this feature should only be used when connected to a trusted node. However, it was also pointed out that nodes generally rely on the assumption they are connected to at least one honest peer, allowing for a convergence on the set of honest peers and the ability to ban or disconnect those who send invalid reject messages for valid transactions.Bitcoin Core developer, Marco Falke, proposed removing the reject message feature from Bitcoin Core to make the codebase slimmer. However, it was noted that Neutrino, a light client implementation, currently relies on receiving reject messages from its peers when broadcasting a transaction to the network. Despite this, Falke believes that removing the feature would help in terms of comprehension and maintainability. The alternative recommended by Falke is not suitable for use cases where the main thing required is identification of whether a broadcasted transaction is valid or not. Reject messages are also useful when developing new light clients, as feedback from the network on why a transaction was rejected helps identify potential bugs in their transaction crafting logic. While Falke suggested testing the validity of a transaction through specific RPCs, such as `sendrawtransaction` and `testmempoolaccept`, these are not helpful for light clients. Therefore, it is believed that disabling the reject message feature by default would hinder light clients' ability to realize they are broadcasting invalid transactions. Thus, the feature should remain enabled by default to aid the light clients of the network.Bitcoin Core may remove the reject messages feature from its system, as it has been disabled by default since version 0.18.0. This feature is toggled by the `-enablebip61` command line option. Developers have proposed alternative testing methods for those who rely on the feature, including inspecting log messages produced by a recent version of Bitcoin Core, using specific RPCs to test the validity of blocks and transactions, and relying on fee estimation to determine transaction fees and setting replace-by-fee if desired. The proposal to remove the feature from Bitcoin Core 0.19.0 has been made unless there are valid concerns about its removal.Overall, the debate centers around the trustworthiness of reject messages sent by nodes on the Bitcoin network. While some argue that this feature should only be used when connected to trusted nodes, others believe that removing it would make the codebase slimmer and easier to maintain. However, alternative testing methods have been proposed, and it is important to consider the impact on light clients and their ability to identify and correct invalid transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Signaling-support-for-addr-relay-revision-1-.xml b/static/bitcoin-dev/Oct_2019/combined_Signaling-support-for-addr-relay-revision-1-.xml index 4d84646810..0c935b51e8 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Signaling-support-for-addr-relay-revision-1-.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Signaling-support-for-addr-relay-revision-1-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Signaling support for addr relay (revision #1) - 2023-08-02T01:29:17.825758+00:00 - - Joachim Strömbergson 2019-10-24 08:01:49+00:00 - - - Gleb Naumenko 2019-10-23 21:52:49+00:00 - + 2025-09-26T15:27:26.843323+00:00 + python-feedgen + + + [bitcoin-dev] Signaling support for addr relay (revision #1) Gleb Naumenko + 2019-10-23T21:52:00.000Z + + + Joachim Strömbergson + 2019-10-24T08:01:00.000Z + + - python-feedgen + 2 Combined summary - Signaling support for addr relay (revision #1) - 2023-08-02T01:29:17.826756+00:00 + 2025-09-26T15:27:26.843770+00:00 - In an email, the author proposes extending BIP-155 with per-link-direction negotiation to address relay in the Bitcoin network. While they don't have a strong opinion, they believe that the per-link variant makes more sense as they cannot imagine a future requirement for opting out completely. The author points out that address relay in the Bitcoin network is under-specified and suggests a solution to decouple address relay considerations from light/full node/block-relay-only.The proposed solution involves making it explicit whether a node promises to participate in address relay by forwarding unsolicited messages and responding to GETADDR. The author presents two ways to implement this: either through the introduction of 2 new service bits or by using per-link-direction negotiation with BIP-155. According to the author, having more flexibility with per-link-direction negotiation is advantageous for the future of the protocol. They mention that some nodes might want to opt-out of address relay for a subset of their links. Therefore, the author suggests extending BIP-155 with per-link-direction negotiation. However, they express interest in hearing the opinion of the community on this matter.To provide further information, the author includes two references in the email for additional reading. 2019-10-24T08:01:49+00:00 + In an email, the author proposes extending BIP-155 with per-link-direction negotiation to address relay in the Bitcoin network. While they don't have a strong opinion, they believe that the per-link variant makes more sense as they cannot imagine a future requirement for opting out completely. The author points out that address relay in the Bitcoin network is under-specified and suggests a solution to decouple address relay considerations from light/full node/block-relay-only.The proposed solution involves making it explicit whether a node promises to participate in address relay by forwarding unsolicited messages and responding to GETADDR. The author presents two ways to implement this: either through the introduction of 2 new service bits or by using per-link-direction negotiation with BIP-155. According to the author, having more flexibility with per-link-direction negotiation is advantageous for the future of the protocol. They mention that some nodes might want to opt-out of address relay for a subset of their links. Therefore, the author suggests extending BIP-155 with per-link-direction negotiation. However, they express interest in hearing the opinion of the community on this matter.To provide further information, the author includes two references in the email for additional reading. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Smaller-Bitcoin-address-accounts-in-the-blockchain-.xml b/static/bitcoin-dev/Oct_2019/combined_Smaller-Bitcoin-address-accounts-in-the-blockchain-.xml index 95deb1bbb7..f45e7ca26a 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Smaller-Bitcoin-address-accounts-in-the-blockchain-.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Smaller-Bitcoin-address-accounts-in-the-blockchain-.xml @@ -1,23 +1,28 @@ - + 2 - Combined summary - Smaller "Bitcoin address" accounts in the blockchain. - 2023-08-02T01:27:23.328267+00:00 - - ZmnSCPxj 2019-10-04 06:45:35+00:00 - - - Dave Scotese 2019-10-04 01:37:33+00:00 - + Combined summary - Smaller "Bitcoin address" accounts in the blockchain. + 2025-09-26T15:27:35.416381+00:00 + python-feedgen + + + [bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain Dave Scotese + 2019-10-04T01:37:00.000Z + + + ZmnSCPxj + 2019-10-04T06:45:00.000Z + + - python-feedgen + 2 - Combined summary - Smaller "Bitcoin address" accounts in the blockchain. - 2023-08-02T01:27:23.328267+00:00 + Combined summary - Smaller "Bitcoin address" accounts in the blockchain. + 2025-09-26T15:27:35.416855+00:00 - The idea of creating a shorter transaction that points to an existing output with a larger amount is being discussed by Bitcoin developers. This approach aims to aggregate bitcoin to a UTXO that may not be economically viable otherwise. By utilizing this method, the capacity of lightning channels could be increased without the need to close and re-open a new channel.However, implementing this account-style approach in the current Bitcoin system poses challenges. The UTXO-style is deeply ingrained in Bitcoin's design and cannot be easily modified through a softfork. Unlike UTXOs where every spend drains the entire "account," the issue with an account-style approach arises when the account is overdrawn.To address these challenges, a solution called pay-to-endpoint/payjoin is proposed. This method involves referencing a previous UTXO owned by the payee and creating a new UTXO containing the total value of the old UTXO and the value to be transferred from the payer to the payee. This preserves privacy better than the previously discussed proposal.However, there are some drawbacks to this approach. The payee must be online and cooperate, providing signatures for the old UTXO, which adds more blockchain data. Additionally, the new UTXO needs to publish a script as well.In terms of the Lightning Network layer, it would need to handle the possibility of a "short channel ID" changing. Despite these challenges, exploring the creation of shorter transactions that point to existing outputs with larger amounts could have significant benefits for Bitcoin's scalability and efficiency. 2019-10-04T06:45:35+00:00 + The idea of creating a shorter transaction that points to an existing output with a larger amount is being discussed by Bitcoin developers. This approach aims to aggregate bitcoin to a UTXO that may not be economically viable otherwise. By utilizing this method, the capacity of lightning channels could be increased without the need to close and re-open a new channel.However, implementing this account-style approach in the current Bitcoin system poses challenges. The UTXO-style is deeply ingrained in Bitcoin's design and cannot be easily modified through a softfork. Unlike UTXOs where every spend drains the entire "account," the issue with an account-style approach arises when the account is overdrawn.To address these challenges, a solution called pay-to-endpoint/payjoin is proposed. This method involves referencing a previous UTXO owned by the payee and creating a new UTXO containing the total value of the old UTXO and the value to be transferred from the payer to the payee. This preserves privacy better than the previously discussed proposal.However, there are some drawbacks to this approach. The payee must be online and cooperate, providing signatures for the old UTXO, which adds more blockchain data. Additionally, the new UTXO needs to publish a script as well.In terms of the Lightning Network layer, it would need to handle the possibility of a "short channel ID" changing. Despite these challenges, exploring the creation of shorter transactions that point to existing outputs with larger amounts could have significant benefits for Bitcoin's scalability and efficiency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Transition-to-post-quantum.xml b/static/bitcoin-dev/Oct_2019/combined_Transition-to-post-quantum.xml index 234d947347..59da70b778 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Transition-to-post-quantum.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Transition-to-post-quantum.xml @@ -1,44 +1,59 @@ - + 2 Combined summary - Transition to post-quantum - 2023-08-01T22:39:00.161188+00:00 - - Erik Aronesty 2019-10-24 15:34:14+00:00 - - - Tim Ruffing 2018-02-15 23:44:19+00:00 - - - Natanael 2018-02-15 22:45:09+00:00 - - - Natanael 2018-02-15 22:44:05+00:00 - - - Tim Ruffing 2018-02-15 21:57:41+00:00 - - - Natanael 2018-02-15 20:27:27+00:00 - - - Tim Ruffing 2018-02-15 15:59:27+00:00 - - - Tristan Hoy 2018-02-13 10:06:31+00:00 - - - Tim Ruffing 2018-02-13 06:46:14+00:00 - - - Tristan Hoy 2018-02-12 21:32:35+00:00 - - - Tim Ruffing 2018-02-12 15:50:50+00:00 - - - Tristan Hoy 2018-02-12 14:13:11+00:00 - + 2025-09-26T15:27:31.148358+00:00 + python-feedgen + + + [bitcoin-dev] Transition to post-quantum Tristan Hoy + 2018-02-12T14:13:00.000Z + + + Tim Ruffing + 2018-02-12T15:50:00.000Z + + + Tristan Hoy + 2018-02-12T21:32:00.000Z + + + Tim Ruffing + 2018-02-13T06:46:00.000Z + + + Tristan Hoy + 2018-02-13T10:06:00.000Z + + + Tim Ruffing + 2018-02-15T15:59:00.000Z + + + Natanael + 2018-02-15T20:27:00.000Z + + + Tim Ruffing + 2018-02-15T21:57:00.000Z + + + Natanael + 2018-02-15T22:44:00.000Z + + + Natanael + 2018-02-15T22:45:00.000Z + + + Tim Ruffing + 2018-02-15T23:44:00.000Z + + + Erik Aronesty + 2019-10-24T15:34:00.000Z + + @@ -51,13 +66,13 @@ - python-feedgen + 2 Combined summary - Transition to post-quantum - 2023-08-01T22:39:00.161188+00:00 + 2025-09-26T15:27:31.149642+00:00 - A spam-proof scheme has been proposed to address the quantum threat in blockchain. The scheme involves publishing a transaction on the blockchain that lists pre-quantum signature and hash of post-quantum address. Future transactions would require both pre and post-quantum signatures. There are two quantum addressing schemes, and if a new discovery shows a second scheme with smaller transactions and faster validation, Soft-fork 2 will refuse upgrades to the first scheme beyond a certain block number.Zero-knowledge proofs are discussed as a means to recover an UTXO with a P2PKH address, but it can be complex for arbitrary scripts. Natanael suggests publishing the full transaction except for public keys and signatures, committing to it, and revealing it later to prevent attackers from modifying the transaction. However, this approach can be a target for Denial of Service (DoS) attacks. Rate limiting is not considered safe, but requiring transaction fees even for commitments may be a solution. The feasibility of such solutions depends on the efficiency of zero-knowledge proof systems.In an email conversation, Natanael expresses concerns about the security implications of allowing expiration for a certain system. However, the exact details of the system and context of the conversation are not provided. The email exchange involves a discussion about the potential security risks associated with allowing expiration for a particular system.In an email discussion on the Bitcoin development mailing list, Tim Ruffing proposes a scheme for securing transactions using hash commitments. Some members raise concerns about the security and practicality of the proposal. One issue raised is the vulnerability to denial-of-service attacks if transactions expire. No consensus is reached on the proposal.In an email exchange between Natanael and Tim, they discuss a potential attack on Bitcoin's commitment scheme. In one situation, an attacker can block an honest user's transaction and make their own commitment and transaction. However, the honest commitment wins and the attacker is unsuccessful.Tim Ruffing sends a message to the bitcoin-dev mailing list regarding consensus rules for UTXOs and commitments. He describes two different situations related to commitment expiration and doubles in the blockchain. No consensus is reached on the proposal.The proposal is to include a classic signature to ensure that if the classic_pk has been revealed, then anyone can prevent spending funds as desired. A fixed variant is presented that supports any hash-based addresses. The scheme requires multiple hash functions and authenticated symmetric encryption. It proposes a commit step and a decommit step to spend a UTXO. The scheme is a variant of Adam Back's proposal for committed transactions. The main problem is the flooding of the blockchain with commitments, but it can be addressed through transaction fees. Double-spending is excluded after the first step is confirmed.In a post-quantum world, a certain type of transaction in Bitcoin is vulnerable to front-running if ECDSA is broken. The decommit step does not specify the effects, while the commit step fixes this. A proactive measure is required before ECDSA is compromised. Tristan Hoy proposes a strategy that mitigates against a post-quantum attack without changes to the Bitcoin protocol. It involves changing key generation only and would be implemented by wallet providers.Tristan Hoy presents research on post-quantum attacks on Bitcoin and options for mitigation. Recommended post-quantum DSAs are not scalable, and committing to a specific one would be premature. He proposes a strategy that mitigates against the worst-case scenario without protocol changes or commitment to a specific DSA. The strategy involves a change to key generation and would be implemented by wallet providers.Tristan Hoy proposes a strategy to mitigate the potential effects of a post-quantum attack on Bitcoin. None of the recommended post-quantum DSAs are scalable. The strategy involves changing key generation and would be implemented by wallet providers.In a recent message, Tristan Hoy shares research on post-quantum attacks on Bitcoin and options for mitigation. None of the recommended post-quantum DSA algorithms are scalable, but a strategy that mitigates against the worst-case scenario without protocol changes or commitment to a specific DSA is proposed. The strategy involves a change to key generation and would be implemented by wallet providers. Feedback on the proposal is requested.Dr. Matt Green, a cryptography expert, has proposed a scalable solution for addressing the security vulnerabilities that may arise from quantum computers attacking Bitcoin's Elliptic Curve Digital Signature Algorithm (ECDSA). In his proposal, Dr. Green outlines a strategy to mitigate the potential risks of an early attack on ECDSA without making any alterations to the Bitcoin protocol or committing to a specific post-quantum Digital Signature Algorithm (DSA) that may become outdated in the next 3-5 years.The suggested solution revolves around modifying only the key generation process, which would be implemented by wallet providers. By making this change, the proposal aims to provide a secure method for transferring balances into a post-quantum DSA address space, even if ECDSA is completely compromised. The 2019-10-24T15:34:14+00:00 + A spam-proof scheme has been proposed to address the quantum threat in blockchain. The scheme involves publishing a transaction on the blockchain that lists pre-quantum signature and hash of post-quantum address. Future transactions would require both pre and post-quantum signatures. There are two quantum addressing schemes, and if a new discovery shows a second scheme with smaller transactions and faster validation, Soft-fork 2 will refuse upgrades to the first scheme beyond a certain block number.Zero-knowledge proofs are discussed as a means to recover an UTXO with a P2PKH address, but it can be complex for arbitrary scripts. Natanael suggests publishing the full transaction except for public keys and signatures, committing to it, and revealing it later to prevent attackers from modifying the transaction. However, this approach can be a target for Denial of Service (DoS) attacks. Rate limiting is not considered safe, but requiring transaction fees even for commitments may be a solution. The feasibility of such solutions depends on the efficiency of zero-knowledge proof systems.In an email conversation, Natanael expresses concerns about the security implications of allowing expiration for a certain system. However, the exact details of the system and context of the conversation are not provided. The email exchange involves a discussion about the potential security risks associated with allowing expiration for a particular system.In an email discussion on the Bitcoin development mailing list, Tim Ruffing proposes a scheme for securing transactions using hash commitments. Some members raise concerns about the security and practicality of the proposal. One issue raised is the vulnerability to denial-of-service attacks if transactions expire. No consensus is reached on the proposal.In an email exchange between Natanael and Tim, they discuss a potential attack on Bitcoin's commitment scheme. In one situation, an attacker can block an honest user's transaction and make their own commitment and transaction. However, the honest commitment wins and the attacker is unsuccessful.Tim Ruffing sends a message to the bitcoin-dev mailing list regarding consensus rules for UTXOs and commitments. He describes two different situations related to commitment expiration and doubles in the blockchain. No consensus is reached on the proposal.The proposal is to include a classic signature to ensure that if the classic_pk has been revealed, then anyone can prevent spending funds as desired. A fixed variant is presented that supports any hash-based addresses. The scheme requires multiple hash functions and authenticated symmetric encryption. It proposes a commit step and a decommit step to spend a UTXO. The scheme is a variant of Adam Back's proposal for committed transactions. The main problem is the flooding of the blockchain with commitments, but it can be addressed through transaction fees. Double-spending is excluded after the first step is confirmed.In a post-quantum world, a certain type of transaction in Bitcoin is vulnerable to front-running if ECDSA is broken. The decommit step does not specify the effects, while the commit step fixes this. A proactive measure is required before ECDSA is compromised. Tristan Hoy proposes a strategy that mitigates against a post-quantum attack without changes to the Bitcoin protocol. It involves changing key generation only and would be implemented by wallet providers.Tristan Hoy presents research on post-quantum attacks on Bitcoin and options for mitigation. Recommended post-quantum DSAs are not scalable, and committing to a specific one would be premature. He proposes a strategy that mitigates against the worst-case scenario without protocol changes or commitment to a specific DSA. The strategy involves a change to key generation and would be implemented by wallet providers.Tristan Hoy proposes a strategy to mitigate the potential effects of a post-quantum attack on Bitcoin. None of the recommended post-quantum DSAs are scalable. The strategy involves changing key generation and would be implemented by wallet providers.In a recent message, Tristan Hoy shares research on post-quantum attacks on Bitcoin and options for mitigation. None of the recommended post-quantum DSA algorithms are scalable, but a strategy that mitigates against the worst-case scenario without protocol changes or commitment to a specific DSA is proposed. The strategy involves a change to key generation and would be implemented by wallet providers. Feedback on the proposal is requested.Dr. Matt Green, a cryptography expert, has proposed a scalable solution for addressing the security vulnerabilities that may arise from quantum computers attacking Bitcoin's Elliptic Curve Digital Signature Algorithm (ECDSA). In his proposal, Dr. Green outlines a strategy to mitigate the potential risks of an early attack on ECDSA without making any alterations to the Bitcoin protocol or committing to a specific post-quantum Digital Signature Algorithm (DSA) that may become outdated in the next 3-5 years.The suggested solution revolves around modifying only the key generation process, which would be implemented by wallet providers. By making this change, the proposal aims to provide a secure method for transferring balances into a post-quantum DSA address space, even if ECDSA is completely compromised. The - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2019/combined_Trustless-hash-price-insurance-contracts.xml b/static/bitcoin-dev/Oct_2019/combined_Trustless-hash-price-insurance-contracts.xml index 4f84216eb4..b88da78cfe 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Trustless-hash-price-insurance-contracts.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Trustless-hash-price-insurance-contracts.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Trustless hash-price insurance contracts - 2023-08-02T01:29:08.553046+00:00 - - Eric Voskuil 2019-10-21 03:34:12+00:00 - - - Lucas H 2019-10-20 21:33:24+00:00 - - - Eric Voskuil 2019-10-20 20:17:03+00:00 - - - Lucas H 2019-10-20 19:45:49+00:00 - - - Eric Voskuil 2019-10-20 16:16:57+00:00 - - - JW Weatherman 2019-10-20 16:10:53+00:00 - - - Eric Voskuil 2019-10-20 14:57:37+00:00 - - - JW Weatherman 2019-10-20 14:10:55+00:00 - - - Eric Voskuil 2019-10-20 05:03:09+00:00 - - - Lucas H 2019-10-18 22:01:54+00:00 - + 2025-09-26T15:27:39.695395+00:00 + python-feedgen + + + [bitcoin-dev] Trustless hash-price insurance contracts Lucas H + 2019-10-18T22:01:00.000Z + + + Eric Voskuil + 2019-10-20T05:03:00.000Z + + + JW Weatherman + 2019-10-20T14:10:00.000Z + + + Eric Voskuil + 2019-10-20T14:57:00.000Z + + + JW Weatherman + 2019-10-20T16:10:00.000Z + + + Eric Voskuil + 2019-10-20T16:16:00.000Z + + + Lucas H + 2019-10-20T19:45:00.000Z + + + Eric Voskuil + 2019-10-20T20:17:00.000Z + + + Lucas H + 2019-10-20T21:33:00.000Z + + + Eric Voskuil + 2019-10-21T03:34:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Trustless hash-price insurance contracts - 2023-08-02T01:29:08.553046+00:00 + 2025-09-26T15:27:39.696668+00:00 - A Bitcoin miner has proposed a trustless contract to ensure minimum profitability for mining operations. The contract is implemented as a Bitcoin transaction and involves both the insurer and the miner. It includes a deposit from the insurer and a premium payment from the miner. The contract has three conditions for payment: expiry date, mutual agreement, or the provision of a pre-image that produces a hash within certain difficulty constraints. The main idea behind the contract is to guarantee a minimum profitability for the miner in case hashing becomes cheap enough to make it more profitable to find a suitable pre-image instead of mining Bitcoin.The proposed contract allows the miner to still mine Bitcoin and compensate for lower-than-expected rewards by using part of the insurance deposit. However, there are implementation challenges due to the inability to perform arithmetic comparison with long integers >32bit in the script. This means that the difficulty requirement needs to be handled in a hacky manner. One possible solution is to use the hashes of one or more pre-images with a given short length, where the miner must provide the exact pre-images chosen by the insurer.Eric Voskuil questions the assumption underlying the problem statement. He argues that if any miner is profitable, it is the miner with the new equipment. He believes that if a miner with new equipment is not profitable, the hash rate will drop until it becomes profitable. He suggests that the assumption of increasing hash rate implies an expectation of increasing return on investment. Therefore, he argues that a loss on new equipment implies that all miners are operating at a loss, which is not a sustainable situation.The discussion concludes with Lucas expressing more interest in the technical feasibility of the contract than its economic practicality in the present. The proposal was discussed on the bitcoin-dev mailing list, and feedback on the idea was requested.In conclusion, the proposed trustless contract offers a potential solution to guarantee minimum profitability for Bitcoin mining operations. However, there are challenges in its implementation, particularly regarding the handling of difficulty requirements. Eric Voskuil raises questions about the assumption that all miners are unprofitable, stating that a miner with new equipment should be profitable, and if not, the hash rate will decrease until it becomes profitable. 2019-10-21T03:34:12+00:00 + A Bitcoin miner has proposed a trustless contract to ensure minimum profitability for mining operations. The contract is implemented as a Bitcoin transaction and involves both the insurer and the miner. It includes a deposit from the insurer and a premium payment from the miner. The contract has three conditions for payment: expiry date, mutual agreement, or the provision of a pre-image that produces a hash within certain difficulty constraints. The main idea behind the contract is to guarantee a minimum profitability for the miner in case hashing becomes cheap enough to make it more profitable to find a suitable pre-image instead of mining Bitcoin.The proposed contract allows the miner to still mine Bitcoin and compensate for lower-than-expected rewards by using part of the insurance deposit. However, there are implementation challenges due to the inability to perform arithmetic comparison with long integers >32bit in the script. This means that the difficulty requirement needs to be handled in a hacky manner. One possible solution is to use the hashes of one or more pre-images with a given short length, where the miner must provide the exact pre-images chosen by the insurer.Eric Voskuil questions the assumption underlying the problem statement. He argues that if any miner is profitable, it is the miner with the new equipment. He believes that if a miner with new equipment is not profitable, the hash rate will drop until it becomes profitable. He suggests that the assumption of increasing hash rate implies an expectation of increasing return on investment. Therefore, he argues that a loss on new equipment implies that all miners are operating at a loss, which is not a sustainable situation.The discussion concludes with Lucas expressing more interest in the technical feasibility of the contract than its economic practicality in the present. The proposal was discussed on the bitcoin-dev mailing list, and feedback on the idea was requested.In conclusion, the proposed trustless contract offers a potential solution to guarantee minimum profitability for Bitcoin mining operations. However, there are challenges in its implementation, particularly regarding the handling of difficulty requirements. Eric Voskuil raises questions about the assumption that all miners are unprofitable, stating that a miner with new equipment should be profitable, and if not, the hash rate will decrease until it becomes profitable. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_A-thought-experiment-on-bitcoin-for-payroll-privacy.xml b/static/bitcoin-dev/Oct_2020/combined_A-thought-experiment-on-bitcoin-for-payroll-privacy.xml index 1a600ebb0c..afd5d175b2 100644 --- a/static/bitcoin-dev/Oct_2020/combined_A-thought-experiment-on-bitcoin-for-payroll-privacy.xml +++ b/static/bitcoin-dev/Oct_2020/combined_A-thought-experiment-on-bitcoin-for-payroll-privacy.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - A thought experiment on bitcoin for payroll privacy - 2023-08-02T02:45:18.131449+00:00 - - ZmnSCPxj 2020-10-06 04:10:52+00:00 - - - ZmnSCPxj 2020-10-05 02:41:14+00:00 - - - ZmnSCPxj 2020-10-04 14:24:59+00:00 - - - Thomas Hartman 2020-10-04 14:07:05+00:00 - - - ZmnSCPxj 2020-10-04 03:45:14+00:00 - - - ZmnSCPxj 2020-10-03 22:24:58+00:00 - - - Mr. Lee Chiffre 2020-10-03 05:21:17+00:00 - + 2025-09-26T15:37:17.796784+00:00 + python-feedgen + + + [bitcoin-dev] A thought experiment on bitcoin for payroll privacy Mr. Lee Chiffre + 2020-10-03T05:21:00.000Z + + + ZmnSCPxj + 2020-10-03T22:24:00.000Z + + + ZmnSCPxj + 2020-10-04T03:45:00.000Z + + + Thomas Hartman + 2020-10-04T14:07:00.000Z + + + ZmnSCPxj + 2020-10-04T14:24:00.000Z + + + ZmnSCPxj + 2020-10-05T02:41:00.000Z + + + ZmnSCPxj + 2020-10-06T04:10:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - A thought experiment on bitcoin for payroll privacy - 2023-08-02T02:45:18.131449+00:00 + 2025-09-26T15:37:17.797726+00:00 - ZmnSCPxj, a contributor to the Lightning Network, argues against the proposal of always publishing all channels due to concerns about employee privacy. He warns that revealing the size of a channel between a company and an employee could disclose the employee's bi-weekly salary. To obscure this information, proposals suggest obscuring short-channel-ids in routehints for both published and unpublished channels. ZmnSCPxj also explains how feerate settings in invoices can still be identifiable, but suggests using a small random increase in feerate to obscure the channel referenced in the invoice.ZmnSCPxj further discusses the issue of funding inbound balance on the Lightning Network. He responds to a comment about not being able to front up funds for inbound balance without consuming all of the treasury. He emphasizes the importance of having enough funds available to pay employee salaries to avoid business failure. He explains how even with just one employee, it is possible to make the Lightning Network work by using offchain-to-onchain swap services to put money on-chain and create a new channel for paying the promised salary. He emphasizes that it is unnecessary to lock up all funds and suggests keeping enough in channels to cover continuous operational expenses, including salaries. This method can work regardless of the number of employees.In another discussion, ZmnSCPxj addresses the possibility of a company having only one big to-network channel for Lightning usage. He argues against the assumption that a company cannot front up funds for inbound balance. He explains that even with just one new hire, the company can use offchain-to-onchain swaps to create a new channel and pay the promised salary. The company's funds are not locked up, only the employee's funds. As the company operates and receives money in its big to-network channel, it can cover expenses and salaries. ZmnSCPxj emphasizes the need to keep some funds for other expenses and states that this scenario can work regardless of the number of employees.The author of the text addresses the concern of locking up funds to pay employees via Lightning Network. They argue that it is a necessary step and not an unreasonable assumption. They explain how even with a single big channel and one employee, the system can still work as long as the company earns enough money to cover expenses and salaries. The author concludes by stating that this system will work regardless of the number of employees.In an email exchange, ZmnSCPxj discusses the issue of inbound liquidity on the Lightning Network. They suggest that companies can open channels with employees who have insufficient inbound liquidity to receive their salaries. If an employee's node does not have enough capacity, the company can use offchain-to-onchain swaps to create a new channel for the employee. The size of the channel can be increased or alternative methods can be used to free up capacity for occasional bonuses or permanent raises. The author also notes that even if an employee leaves the company, the channel need not be closed as the company can earn forwarding fees from their new employer or income source. This solution is seen as better than the onchain situation.Lastly, the text mentions Cut Throat Industries, a company that pays its 120 employees biweekly using a single transaction with the company's treasury as input and each employee payroll as output. However, this exposes sensitive information about the company's worth, treasury amount, number of employees, and average payroll. To address these concerns, the company considers using Bitcoin with privacy, but currently believes that paying on-chain is the only solution. However, fronting up funds for inbound balance would consume all of the company's treasury, making it an impractical option. 2020-10-06T04:10:52+00:00 + ZmnSCPxj, a contributor to the Lightning Network, argues against the proposal of always publishing all channels due to concerns about employee privacy. He warns that revealing the size of a channel between a company and an employee could disclose the employee's bi-weekly salary. To obscure this information, proposals suggest obscuring short-channel-ids in routehints for both published and unpublished channels. ZmnSCPxj also explains how feerate settings in invoices can still be identifiable, but suggests using a small random increase in feerate to obscure the channel referenced in the invoice.ZmnSCPxj further discusses the issue of funding inbound balance on the Lightning Network. He responds to a comment about not being able to front up funds for inbound balance without consuming all of the treasury. He emphasizes the importance of having enough funds available to pay employee salaries to avoid business failure. He explains how even with just one employee, it is possible to make the Lightning Network work by using offchain-to-onchain swap services to put money on-chain and create a new channel for paying the promised salary. He emphasizes that it is unnecessary to lock up all funds and suggests keeping enough in channels to cover continuous operational expenses, including salaries. This method can work regardless of the number of employees.In another discussion, ZmnSCPxj addresses the possibility of a company having only one big to-network channel for Lightning usage. He argues against the assumption that a company cannot front up funds for inbound balance. He explains that even with just one new hire, the company can use offchain-to-onchain swaps to create a new channel and pay the promised salary. The company's funds are not locked up, only the employee's funds. As the company operates and receives money in its big to-network channel, it can cover expenses and salaries. ZmnSCPxj emphasizes the need to keep some funds for other expenses and states that this scenario can work regardless of the number of employees.The author of the text addresses the concern of locking up funds to pay employees via Lightning Network. They argue that it is a necessary step and not an unreasonable assumption. They explain how even with a single big channel and one employee, the system can still work as long as the company earns enough money to cover expenses and salaries. The author concludes by stating that this system will work regardless of the number of employees.In an email exchange, ZmnSCPxj discusses the issue of inbound liquidity on the Lightning Network. They suggest that companies can open channels with employees who have insufficient inbound liquidity to receive their salaries. If an employee's node does not have enough capacity, the company can use offchain-to-onchain swaps to create a new channel for the employee. The size of the channel can be increased or alternative methods can be used to free up capacity for occasional bonuses or permanent raises. The author also notes that even if an employee leaves the company, the channel need not be closed as the company can earn forwarding fees from their new employer or income source. This solution is seen as better than the onchain situation.Lastly, the text mentions Cut Throat Industries, a company that pays its 120 employees biweekly using a single transaction with the company's treasury as input and each employee payroll as output. However, this exposes sensitive information about the company's worth, treasury amount, number of employees, and average payroll. To address these concerns, the company considers using Bitcoin with privacy, but currently believes that paying on-chain is the only solution. However, fronting up funds for inbound balance would consume all of the company's treasury, making it an impractical option. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_BIP-draft-BIP32-Path-Templates.xml b/static/bitcoin-dev/Oct_2020/combined_BIP-draft-BIP32-Path-Templates.xml index 725d611270..1f42fc70f3 100644 --- a/static/bitcoin-dev/Oct_2020/combined_BIP-draft-BIP32-Path-Templates.xml +++ b/static/bitcoin-dev/Oct_2020/combined_BIP-draft-BIP32-Path-Templates.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - BIP draft: BIP32 Path Templates - 2023-08-02T02:27:58.765588+00:00 - - Dmitry Petukhov 2020-10-26 13:04:56+00:00 - - - Dmitry Petukhov 2020-07-06 15:24:27+00:00 - - - Dmitry Petukhov 2020-07-03 19:10:50+00:00 - - - Dmitry Petukhov 2020-07-03 16:53:44+00:00 - - - David A. Harding 2020-07-03 14:39:45+00:00 - - - Dmitry Petukhov 2020-07-02 16:28:39+00:00 - + 2025-09-26T15:37:13.598291+00:00 + python-feedgen + + + [bitcoin-dev] BIP draft: BIP32 Path Templates Dmitry Petukhov + 2020-07-02T16:28:00.000Z + + + David A. Harding + 2020-07-03T14:39:00.000Z + + + Dmitry Petukhov + 2020-07-03T16:53:00.000Z + + + Dmitry Petukhov + 2020-07-03T19:10:00.000Z + + + Dmitry Petukhov + 2020-07-06T15:24:00.000Z + + + Dmitry Petukhov + 2020-10-26T13:04:00.000Z + + - python-feedgen + 2 Combined summary - BIP draft: BIP32 Path Templates - 2023-08-02T02:27:58.765588+00:00 + 2025-09-26T15:37:13.599153+00:00 - The author of a Bitcoin Improvement Proposal (BIP) has introduced a Python reference implementation of BIP32 path templates compatible with micropython. The FSM formal spec has been corrected and thoroughly tested in both C and Python implementations. The author has submitted a PR to the bips repo and is open to feedback. However, no information is provided about a non-text attachment included.In July 2020, Dmitry Petukhov suggested that having clear specifications and licensed quality implementations would facilitate the adoption of a specific format. He shared a C implementation on GitHub with an MIT license, but no further details are given.The BIP draft aims to establish a format for path templates that enables interoperability among software and hardware vendors by specifying derivation path restrictions. This allows software vendors to create profiles containing constraints on the paths used in their custom derivation schemes. Users can then install these profiles into hardware wallets that support path templates. By enforcing the specified constraints, the device ensures that the software solution functions as intended.Path templates provide a standardized way to describe constraints for BIP32 paths. They allow for application-specific restrictions and identification of multiple chains of addresses. For example, a signing scheme may require only certain whitelisted derivation paths to be used during HD derivation when signing inputs or checking if an output is the change output. By placing the constraints in the signer's configuration, this approach accommodates different vendor-developed schemes and prevents conflicts with custom software solutions.The proposed format for path templates serves as a building block for interoperability between hardware and software vendors. It offers a flexible alternative to rigid sets of "well-known" paths by adopting a common format for specifying restrictions. The hope is that vendors will find it easier to adopt this format with the availability of clear specifications and permissibly licensed quality implementations.In a Bitcoin development mailing list, Dmitry Petukhov suggested creating a BIP draft for path templates. Dave Harding requested clarification on how these templates compare to key origin identification and examples of their usage. He also questioned whether they are intended for backups, multisig wallet coordination, or managing data between software transaction construction and hardware device signing.The author's proposal for a standard format aims to describe constraints on BIP32 paths. The BIP draft specifies "path templates" that facilitate the distinction between valid and invalid paths based on defined constraints. It includes examples of templates and a formal specification of a finite state machine for parsing. A Python implementation for template parsing and matching already exists.While the BIP32 derivation path format allows for custom schemes, unrestricted usage can be unsafe in certain contexts. Hard-coding checks for well-known paths into software and firmware reduces interoperability. To address this, the author proposes a flexible approach that defines a standard notation for "BIP32 path templates" to succinctly describe constraints on the derivation path.Support for these path templates will enhance interoperability and flexibility, enabling vendors and developers to easily define their own custom restrictions. Having standardized formats for custom path templates encourages the development of a common approach to enforce application-specific path restrictions in devices and applications. For example, devices could allow the installation of application-specific profiles with path templates and custom parameters. However, precautions must be taken to prevent the accidental installation of malicious or incorrect profiles. 2020-10-26T13:04:56+00:00 + The author of a Bitcoin Improvement Proposal (BIP) has introduced a Python reference implementation of BIP32 path templates compatible with micropython. The FSM formal spec has been corrected and thoroughly tested in both C and Python implementations. The author has submitted a PR to the bips repo and is open to feedback. However, no information is provided about a non-text attachment included.In July 2020, Dmitry Petukhov suggested that having clear specifications and licensed quality implementations would facilitate the adoption of a specific format. He shared a C implementation on GitHub with an MIT license, but no further details are given.The BIP draft aims to establish a format for path templates that enables interoperability among software and hardware vendors by specifying derivation path restrictions. This allows software vendors to create profiles containing constraints on the paths used in their custom derivation schemes. Users can then install these profiles into hardware wallets that support path templates. By enforcing the specified constraints, the device ensures that the software solution functions as intended.Path templates provide a standardized way to describe constraints for BIP32 paths. They allow for application-specific restrictions and identification of multiple chains of addresses. For example, a signing scheme may require only certain whitelisted derivation paths to be used during HD derivation when signing inputs or checking if an output is the change output. By placing the constraints in the signer's configuration, this approach accommodates different vendor-developed schemes and prevents conflicts with custom software solutions.The proposed format for path templates serves as a building block for interoperability between hardware and software vendors. It offers a flexible alternative to rigid sets of "well-known" paths by adopting a common format for specifying restrictions. The hope is that vendors will find it easier to adopt this format with the availability of clear specifications and permissibly licensed quality implementations.In a Bitcoin development mailing list, Dmitry Petukhov suggested creating a BIP draft for path templates. Dave Harding requested clarification on how these templates compare to key origin identification and examples of their usage. He also questioned whether they are intended for backups, multisig wallet coordination, or managing data between software transaction construction and hardware device signing.The author's proposal for a standard format aims to describe constraints on BIP32 paths. The BIP draft specifies "path templates" that facilitate the distinction between valid and invalid paths based on defined constraints. It includes examples of templates and a formal specification of a finite state machine for parsing. A Python implementation for template parsing and matching already exists.While the BIP32 derivation path format allows for custom schemes, unrestricted usage can be unsafe in certain contexts. Hard-coding checks for well-known paths into software and firmware reduces interoperability. To address this, the author proposes a flexible approach that defines a standard notation for "BIP32 path templates" to succinctly describe constraints on the derivation path.Support for these path templates will enhance interoperability and flexibility, enabling vendors and developers to easily define their own custom restrictions. Having standardized formats for custom path templates encourages the development of a common approach to enforce application-specific path restrictions in devices and applications. For example, devices could allow the installation of application-specific profiles with path templates and custom parameters. However, precautions must be taken to prevent the accidental installation of malicious or incorrect profiles. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap-appendium.xml b/static/bitcoin-dev/Oct_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap-appendium.xml index cda7ce3b98..01f55c455d 100644 --- a/static/bitcoin-dev/Oct_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap-appendium.xml +++ b/static/bitcoin-dev/Oct_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap-appendium.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Detailed protocol design for routed multi-transaction CoinSwap appendium - 2023-08-02T02:45:36.478735+00:00 + 2025-09-26T15:37:11.509537+00:00 + python-feedgen ZmnSCPxj 2020-10-03 13:31:58+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Detailed protocol design for routed multi-transaction CoinSwap appendium - 2023-08-02T02:45:36.478735+00:00 + 2025-09-26T15:37:11.509670+00:00 - The email conversation between Chris and ZmnSCPxj discusses the incentives against post-coinswap-theft-attempt, even with K=0. The extra miner fee paid by Bob acts as a disincentive for theft. In the v2 protocol, each CoinSwap party knows a different version of the contract transactions, allowing Alice to identify the correct fidelity bond. ZmnSCPxj appreciates this observation and will further consider it.A new version of the CoinSwap protocol has been released, offering a secure and private method for exchanging cryptocurrencies. This protocol incorporates staggered timelocks, hash preimages, and anti-DOS features to ensure that parties can retrieve their coins in case of an abort while maintaining privacy. The protocol includes multi-transaction CoinSwaps, routed CoinSwaps, liquidity market, private key handover, and fidelity bonds.Routed CoinSwaps are a feature of the protocol, involving one market taker and two makers, but can be extended to include more makers. Funding transactions pay into 2-of-2 multisig addresses, while contract transactions may spend from the 2-of-2 multisig outputs. To prevent attacks like low miner fees or intentional transaction abortion, parties must refuse to sign a contract transaction if the corresponding funding transaction pays greater miner fees than the attacker's.Collateral payments are suggested to deter post-coinswap-theft-attempts. The v2 design of CoinSwap is explained in detail using three parties: Alice, Bob, and Charlie. The taker (Alice) does not need collateral payments and can fully spend their entire wallet in one set of CoinSwaps. Contract transactions have different versions depending on who knows them. The table of balances before and after a coinswap demonstrates that everyone receives their money back and pays their own miner fees.However, a successful CoinSwap with a post-CoinSwap-theft-attempt results in Bob losing K bitcoins and an extra miner fee, while Charlie gains K bitcoins. The document provides a thorough analysis of possible attacks, deviations from the protocol, miner fees, and vulnerabilities of RBF. Parties must monitor the network and be prepared to respond with their own sweep using a preimage.The reaction of blacklisting both fidelity bonds by Alice may not be the most appropriate approach, as one maker could use it to blacklist another (and themselves). Overall, the CoinSwap protocol aims to offer a secure, private, and efficient means of exchanging cryptocurrencies between parties. 2020-10-03T13:31:58+00:00 + The email conversation between Chris and ZmnSCPxj discusses the incentives against post-coinswap-theft-attempt, even with K=0. The extra miner fee paid by Bob acts as a disincentive for theft. In the v2 protocol, each CoinSwap party knows a different version of the contract transactions, allowing Alice to identify the correct fidelity bond. ZmnSCPxj appreciates this observation and will further consider it.A new version of the CoinSwap protocol has been released, offering a secure and private method for exchanging cryptocurrencies. This protocol incorporates staggered timelocks, hash preimages, and anti-DOS features to ensure that parties can retrieve their coins in case of an abort while maintaining privacy. The protocol includes multi-transaction CoinSwaps, routed CoinSwaps, liquidity market, private key handover, and fidelity bonds.Routed CoinSwaps are a feature of the protocol, involving one market taker and two makers, but can be extended to include more makers. Funding transactions pay into 2-of-2 multisig addresses, while contract transactions may spend from the 2-of-2 multisig outputs. To prevent attacks like low miner fees or intentional transaction abortion, parties must refuse to sign a contract transaction if the corresponding funding transaction pays greater miner fees than the attacker's.Collateral payments are suggested to deter post-coinswap-theft-attempts. The v2 design of CoinSwap is explained in detail using three parties: Alice, Bob, and Charlie. The taker (Alice) does not need collateral payments and can fully spend their entire wallet in one set of CoinSwaps. Contract transactions have different versions depending on who knows them. The table of balances before and after a coinswap demonstrates that everyone receives their money back and pays their own miner fees.However, a successful CoinSwap with a post-CoinSwap-theft-attempt results in Bob losing K bitcoins and an extra miner fee, while Charlie gains K bitcoins. The document provides a thorough analysis of possible attacks, deviations from the protocol, miner fees, and vulnerabilities of RBF. Parties must monitor the network and be prepared to respond with their own sweep using a preimage.The reaction of blacklisting both fidelity bonds by Alice may not be the most appropriate approach, as one maker could use it to blacklist another (and themselves). Overall, the CoinSwap protocol aims to offer a secure, private, and efficient means of exchanging cryptocurrencies between parties. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_Floating-Point-Nakamoto-Consensus.xml b/static/bitcoin-dev/Oct_2020/combined_Floating-Point-Nakamoto-Consensus.xml index 64547a56da..8b51fc819a 100644 --- a/static/bitcoin-dev/Oct_2020/combined_Floating-Point-Nakamoto-Consensus.xml +++ b/static/bitcoin-dev/Oct_2020/combined_Floating-Point-Nakamoto-Consensus.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Floating-Point Nakamoto Consensus - 2023-08-02T02:42:52.955847+00:00 - - yanmaani at cock.li 2020-10-15 16:02:09+00:00 - - - Mike Brooks 2020-10-10 01:26:07+00:00 - - - Mike Brooks 2020-10-10 00:59:31+00:00 - - - Bob McElrath 2020-10-08 18:43:00+00:00 - - - Mike Brooks 2020-10-04 15:58:58+00:00 - - - Mike Brooks 2020-10-01 19:26:01+00:00 - - - Larry Ruane 2020-10-01 16:42:27+00:00 - - - ZmnSCPxj 2020-10-01 06:47:01+00:00 - - - ZmnSCPxj 2020-10-01 01:36:35+00:00 - - - Mike Brooks 2020-09-30 23:53:25+00:00 - - - ZmnSCPxj 2020-09-30 23:44:59+00:00 - - - Mike Brooks 2020-09-30 06:37:47+00:00 - - - ZmnSCPxj 2020-09-30 06:31:41+00:00 - - - Mike Brooks 2020-09-29 16:00:12+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2020-09-29 03:10:36+00:00 - - - Franck Royer 2020-09-29 01:51:03+00:00 - - - Mike Brooks 2020-09-26 11:09:23+00:00 - - - David A. Harding 2020-09-26 10:11:23+00:00 - - - Mike Brooks 2020-09-25 17:35:36+00:00 - - - Jeremy 2020-09-25 16:33:14+00:00 - - - Mike Brooks 2020-09-25 16:04:11+00:00 - - - bitcoin ml 2020-09-25 15:18:17+00:00 - - - Mike Brooks 2020-09-24 19:40:46+00:00 - + 2025-09-26T15:37:09.390091+00:00 + python-feedgen + + + [bitcoin-dev] Floating-Point Nakamoto Consensus Mike Brooks + 2020-09-24T19:40:00.000Z + + + bitcoin ml + 2020-09-25T15:18:00.000Z + + + Mike Brooks + 2020-09-25T16:04:00.000Z + + + Jeremy + 2020-09-25T16:33:00.000Z + + + Mike Brooks + 2020-09-25T17:35:00.000Z + + + David A. Harding + 2020-09-26T10:11:00.000Z + + + Mike Brooks + 2020-09-26T11:09:00.000Z + + + Franck Royer + 2020-09-29T01:51:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2020-09-29T03:10:00.000Z + + + Mike Brooks + 2020-09-29T16:00:00.000Z + + + ZmnSCPxj + 2020-09-30T06:31:00.000Z + + + Mike Brooks + 2020-09-30T06:37:00.000Z + + + ZmnSCPxj + 2020-09-30T23:44:00.000Z + + + Mike Brooks + 2020-09-30T23:53:00.000Z + + + ZmnSCPxj + 2020-10-01T01:36:00.000Z + + + ZmnSCPxj + 2020-10-01T06:47:00.000Z + + + Larry Ruane + 2020-10-01T16:42:00.000Z + + + Mike Brooks + 2020-10-01T19:26:00.000Z + + + Mike Brooks + 2020-10-04T15:58:00.000Z + + + Bob McElrath + 2020-10-08T18:43:00.000Z + + + Mike Brooks + 2020-10-10T00:59:00.000Z + + + Mike Brooks + 2020-10-10T01:26:00.000Z + + + yanmaani + 2020-10-15T16:02:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - Floating-Point Nakamoto Consensus - 2023-08-02T02:42:52.955847+00:00 + 2025-09-26T15:37:09.392327+00:00 - The proposal of Floating-Point Nakamoto Consensus (FPNC) aims to improve the network by avoiding ambiguity and enabling determinism. It assigns floating-point fitness values to blocks, giving miners two valid options when mining a block with high rewards but close fitness to the minimum. Miners can either build on top of that block or replace it, with increasing probability as the block subsidy decreases. While this incentivizes reorgs, the author argues that adding more precision can prevent confusion and allow for immediate decision-making without waiting for chain extensions. The proposal is not related to SegWit but can be implemented in any blockchain using Nakamoto Consensus. A complete implementation of FPNC is available in the provided links.The article discusses vulnerabilities in Nakamoto Consensus and proposes a solution called Floating-Point Nakamoto Consensus. This solution increases the cost of replacing the current winning block, making it harder for adversaries to create a hard fork and disrupt the network. The author emphasizes the need for fully decentralized solutions to Byzantine fault-injection and disagreements. Floating-Point Nakamoto Consensus prevents re-org chains from going beyond a single block, expediting consensus formation. The dominant chain is incentivized, eroding support for weaker chains. The article concludes that any blockchain using Nakamoto Consensus can be modified to use Floating-Point Nakamoto Consensus.In an email thread, Lord James HRMH suggests adding more bits of precision to avoid confusion in selecting the highest-work chain. Waiting for further chain extension may not be necessary if the network can immediately decide based on higher proof of work and greater precision. The email also discusses the threat model of an eclipse attack and how malicious miners can manipulate disagreement in the network. The attacker keeps the disagreement open until their transactions are validated on the honest chain, replacing it with the chain generated by dishonest miners.The article explains how Floating-Point Nakamoto Consensus improves consensus generation by introducing a fitness test. The most recently formed block with the highest local fitness score is preferred, eroding support for weaker chains. A soft fork can be used to implement Floating-Point Nakamoto Consensus, allowing patched and non-patched nodes to coexist. The article concludes that any blockchain using Nakamoto Consensus can be modified to use a fitness constraint like Floating-Point Nakamoto Consensus.The author discusses the use of work and fitness in Bitcoin consensus. Work is an unbiased estimator of computational effort, while fitness introduces bias without additional valuable information. The question of introducing the historic block hash as a consensus-critical parameter is argued against, as it adds unnecessary randomness to chain selection. The author argues that delaying or preempting messages is cheaper than producing better fitness scores, creating a race condition. The article also mentions ongoing malicious mining campaigns and proposes solutions to mitigate them.In an email exchange, Larry Ruane shares his open-source POW network mining simulator that simulates Bitcoin's POW and can be modified for variations. Mike suggests actively pinging nodes running weaker blocks to inform them of new blocks. Larry's project receives praise, and Mike plans to provide a PR. The GitHub link for Larry's project is included.The context of another conversation involves an exploit condition in Bitcoin's network. The speaker responds to Mike's argument, highlighting the unlikelihood of certain conditions and the need for more time before disclosure of exploits. They emphasize the importance of security fundamentals and the risks of change in Bitcoin.In a separate email conversation, ZmnSCPxj raises concerns about growing disagreement in mining capacity and the need to avoid ambiguity in consensus. They discuss an exploit that was reported to the Bitcoin-core security team and cannot be fixed by Floating-Point Nakamoto Consensus. The need for more time before disclosure is highlighted, along with the importance of sensible disclosure policies.Overall, the articles and conversations discuss vulnerabilities in Nakamoto Consensus, propose solutions like Floating-Point Nakamoto Consensus, and address various threat models and exploits in Bitcoin's network. 2020-10-15T16:02:09+00:00 + The proposal of Floating-Point Nakamoto Consensus (FPNC) aims to improve the network by avoiding ambiguity and enabling determinism. It assigns floating-point fitness values to blocks, giving miners two valid options when mining a block with high rewards but close fitness to the minimum. Miners can either build on top of that block or replace it, with increasing probability as the block subsidy decreases. While this incentivizes reorgs, the author argues that adding more precision can prevent confusion and allow for immediate decision-making without waiting for chain extensions. The proposal is not related to SegWit but can be implemented in any blockchain using Nakamoto Consensus. A complete implementation of FPNC is available in the provided links.The article discusses vulnerabilities in Nakamoto Consensus and proposes a solution called Floating-Point Nakamoto Consensus. This solution increases the cost of replacing the current winning block, making it harder for adversaries to create a hard fork and disrupt the network. The author emphasizes the need for fully decentralized solutions to Byzantine fault-injection and disagreements. Floating-Point Nakamoto Consensus prevents re-org chains from going beyond a single block, expediting consensus formation. The dominant chain is incentivized, eroding support for weaker chains. The article concludes that any blockchain using Nakamoto Consensus can be modified to use Floating-Point Nakamoto Consensus.In an email thread, Lord James HRMH suggests adding more bits of precision to avoid confusion in selecting the highest-work chain. Waiting for further chain extension may not be necessary if the network can immediately decide based on higher proof of work and greater precision. The email also discusses the threat model of an eclipse attack and how malicious miners can manipulate disagreement in the network. The attacker keeps the disagreement open until their transactions are validated on the honest chain, replacing it with the chain generated by dishonest miners.The article explains how Floating-Point Nakamoto Consensus improves consensus generation by introducing a fitness test. The most recently formed block with the highest local fitness score is preferred, eroding support for weaker chains. A soft fork can be used to implement Floating-Point Nakamoto Consensus, allowing patched and non-patched nodes to coexist. The article concludes that any blockchain using Nakamoto Consensus can be modified to use a fitness constraint like Floating-Point Nakamoto Consensus.The author discusses the use of work and fitness in Bitcoin consensus. Work is an unbiased estimator of computational effort, while fitness introduces bias without additional valuable information. The question of introducing the historic block hash as a consensus-critical parameter is argued against, as it adds unnecessary randomness to chain selection. The author argues that delaying or preempting messages is cheaper than producing better fitness scores, creating a race condition. The article also mentions ongoing malicious mining campaigns and proposes solutions to mitigate them.In an email exchange, Larry Ruane shares his open-source POW network mining simulator that simulates Bitcoin's POW and can be modified for variations. Mike suggests actively pinging nodes running weaker blocks to inform them of new blocks. Larry's project receives praise, and Mike plans to provide a PR. The GitHub link for Larry's project is included.The context of another conversation involves an exploit condition in Bitcoin's network. The speaker responds to Mike's argument, highlighting the unlikelihood of certain conditions and the need for more time before disclosure of exploits. They emphasize the importance of security fundamentals and the risks of change in Bitcoin.In a separate email conversation, ZmnSCPxj raises concerns about growing disagreement in mining capacity and the need to avoid ambiguity in consensus. They discuss an exploit that was reported to the Bitcoin-core security team and cannot be fixed by Floating-Point Nakamoto Consensus. The need for more time before disclosure is highlighted, along with the importance of sensible disclosure policies.Overall, the articles and conversations discuss vulnerabilities in Nakamoto Consensus, propose solutions like Floating-Point Nakamoto Consensus, and address various threat models and exploits in Bitcoin's network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_Is-BIP32-s-chain-code-needed-.xml b/static/bitcoin-dev/Oct_2020/combined_Is-BIP32-s-chain-code-needed-.xml index b0ee2b6871..208ba3755c 100644 --- a/static/bitcoin-dev/Oct_2020/combined_Is-BIP32-s-chain-code-needed-.xml +++ b/static/bitcoin-dev/Oct_2020/combined_Is-BIP32-s-chain-code-needed-.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Is BIP32's chain code needed? - 2023-08-02T02:44:44.304146+00:00 - - Adam Back 2020-10-17 09:14:59+00:00 - - - Pieter Wuille 2020-10-16 21:41:07+00:00 - - - Christopher Allen 2020-10-05 20:34:48+00:00 - - - Lloyd Fournier 2020-10-05 02:49:48+00:00 - - - Leonardo Comandini 2020-09-29 17:34:28+00:00 - + 2025-09-26T15:37:19.887482+00:00 + python-feedgen + + + [bitcoin-dev] Is BIP32's chain code needed? Leonardo Comandini + 2020-09-29T17:34:00.000Z + + + Lloyd Fournier + 2020-10-05T02:49:00.000Z + + + Christopher Allen + 2020-10-05T20:34:00.000Z + + + Pieter Wuille + 2020-10-16T21:41:00.000Z + + + Adam Back + 2020-10-17T09:14:00.000Z + + - python-feedgen + 2 Combined summary - Is BIP32's chain code needed? - 2023-08-02T02:44:44.304146+00:00 + 2025-09-26T15:37:19.888214+00:00 - In a discussion on the bitcoin-dev mailing list, Leonardo Comandini questions the necessity of the chain code in BIP32. He argues that the additional entropy provided by the chain code is not needed and intends to demonstrate this through a schematic of BIP32 operations. Pieter Wuille, in response, provides historical context on how the chain code ended up being included in BIP32. He explains that BIP32 was inspired by Alan Reiner's Armory software, which had a different key derivation scheme that included a chain code. The chain code allowed for the derivation of multiple "chains" of keys from the same key pair. BIP32 improved upon this by enabling random access into the derived keys and hierarchical derivation with a sub-"chain code" for every subkey.Wuille defends the inclusion of the chain code in BIP32 by stating that xpubs require more protection than public keys alone and that the chain code adds an extra layer of security. Additionally, using a chain code prevents entropy reduction through repeated hashing. However, he acknowledges that from a cryptographic standpoint, the chain code is not necessary and only has practical advantages.The discussion also touches on interoperability and avoiding vendor lock-in. While compromises have been made in the past regarding the amount of entropy used, recent proposals such as SLIP-39 and Lightning Labs' seed mnemonics have raised concerns about interoperability and lock-in issues. The Blockchain Commons and a community of airgapped wallet developers have developed a specification called SSKR, which uses the same seed-to-master key technique as BIP32 to address these concerns.Leonardo Comandini further presents his alternative proposal for key derivation without the chain code. He provides a schematic of BIP32 operations and highlights the advantages of his proposed scheme, including shorter backups for keys and user-friendly backup for child keys. The proposed scheme also allows for mnemonics for subaccount keys. Comandini references various hash functions and provides links to BIP32, BIP39, and a pay-to-contract scheme for more information.Another contributor in the discussion acknowledges that there is no fundamental flaw with Comandini's proposal but admits they haven't spent much time developing wallets.The author of another post argues that the chain code in BIP32 is not necessary and provides a schematic of BIP32 operations to compare with an alternative proposal. The post introduces private and public child derivation formulae, as well as the corresponding chain codes. The post then presents an alternative proposal for derivation without the chain code, using a strong hash function 'h' to convert its output to an integer. This alternative proposal claims to have the same properties as BIP32 and allows for mnemonics for subaccount keys. References [1]-[3] are provided for further information. 2020-10-17T09:14:59+00:00 + In a discussion on the bitcoin-dev mailing list, Leonardo Comandini questions the necessity of the chain code in BIP32. He argues that the additional entropy provided by the chain code is not needed and intends to demonstrate this through a schematic of BIP32 operations. Pieter Wuille, in response, provides historical context on how the chain code ended up being included in BIP32. He explains that BIP32 was inspired by Alan Reiner's Armory software, which had a different key derivation scheme that included a chain code. The chain code allowed for the derivation of multiple "chains" of keys from the same key pair. BIP32 improved upon this by enabling random access into the derived keys and hierarchical derivation with a sub-"chain code" for every subkey.Wuille defends the inclusion of the chain code in BIP32 by stating that xpubs require more protection than public keys alone and that the chain code adds an extra layer of security. Additionally, using a chain code prevents entropy reduction through repeated hashing. However, he acknowledges that from a cryptographic standpoint, the chain code is not necessary and only has practical advantages.The discussion also touches on interoperability and avoiding vendor lock-in. While compromises have been made in the past regarding the amount of entropy used, recent proposals such as SLIP-39 and Lightning Labs' seed mnemonics have raised concerns about interoperability and lock-in issues. The Blockchain Commons and a community of airgapped wallet developers have developed a specification called SSKR, which uses the same seed-to-master key technique as BIP32 to address these concerns.Leonardo Comandini further presents his alternative proposal for key derivation without the chain code. He provides a schematic of BIP32 operations and highlights the advantages of his proposed scheme, including shorter backups for keys and user-friendly backup for child keys. The proposed scheme also allows for mnemonics for subaccount keys. Comandini references various hash functions and provides links to BIP32, BIP39, and a pay-to-contract scheme for more information.Another contributor in the discussion acknowledges that there is no fundamental flaw with Comandini's proposal but admits they haven't spent much time developing wallets.The author of another post argues that the chain code in BIP32 is not necessary and provides a schematic of BIP32 operations to compare with an alternative proposal. The post introduces private and public child derivation formulae, as well as the corresponding chain codes. The post then presents an alternative proposal for derivation without the chain code, using a strong hash function 'h' to convert its output to an integer. This alternative proposal claims to have the same properties as BIP32 and allows for mnemonics for subaccount keys. References [1]-[3] are provided for further information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_Progress-on-Miner-Withholding-FPNC.xml b/static/bitcoin-dev/Oct_2020/combined_Progress-on-Miner-Withholding-FPNC.xml index 4b14f128a8..0171087620 100644 --- a/static/bitcoin-dev/Oct_2020/combined_Progress-on-Miner-Withholding-FPNC.xml +++ b/static/bitcoin-dev/Oct_2020/combined_Progress-on-Miner-Withholding-FPNC.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Progress on Miner Withholding - FPNC - 2023-08-02T02:45:54.122147+00:00 + 2025-09-26T15:37:15.709887+00:00 + python-feedgen Mike Brooks 2020-10-09 00:16:40+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Progress on Miner Withholding - FPNC - 2023-08-02T02:45:54.122147+00:00 + 2025-09-26T15:37:15.710044+00:00 - In a discussion on the bitcoin-dev mailing list, Mike Brooks agrees with Pieter Wuille's concerns about the impact of the FPNC idea on CPU consumption and the electorate. He argues that the "getdata" message is a problem for operators and suggests that the threshold for a patch may be too high. Mike believes that FPNC can rebalance incentives and resolve abuses that reshape the electorate, leading to a more decentralized and fair network than the current "first seen" approach.Pieter Wuille responds to Mike, pointing out that Greg Maxwell is not part of the conversation and clarifying that the discussion mainly revolves around a DoS attack report, which was ultimately a mistake.The discussion thread focuses on two proposed changes to address the issues of miner withholding attacks and network decentralization. The current problem is that miners have an incentive to withhold blocks to gain an advantage in calculating the next block, resulting in a centralized network and transaction delays. The proposed solution involves rebalancing selfish-mining incentives, faster block creation times, and implementing FPNC. However, ZmnSCPxj warns about the reintroduction of selfish mining attacks if FPNC is implemented, making it a hard NAK. Despite the risks, proponents argue that the proposed changes will benefit the network and users.The article explains that the miner withholding attack is a significant issue in the Bitcoin network, leading to centralization and delays in transactions. FPNC is proposed as a solution, introducing a floating-point fitness value for each block to enable fair disagreement resolution and reduce the incentive to withhold blocks. By speeding up block formation time and maintaining inflation targets, the impact of malignant miners can be mitigated. The proposed changes aim to reduce unfair advantages given to large mining pools and promote honest mining practices.The author discusses the miner withholding attack and FPNC, highlighting the unintended incentive it creates for miners to hold onto blocks. Withholding blocks gives major mining pools an unfair advantage, contributes to centralization, and delays transactions. The proposed solution, FPNC, is considered a hard NAK due to the risk of reintroducing selfish mining attacks. The author suggests raising the threshold to 33% as a potential solution.Mike Brooks reveals that the idea for FPNC came from a conversation with ZmnSCPxj regarding re-org stability. After discussing with ZmnSCPxj and Greg Maxwell, it was agreed that the current problems facing the network are more significant than theoretical ones. Pieter Wuille clarifies that the discussion primarily revolves around a DoS attack report that turned out to be a mistake. 2020-10-09T00:16:40+00:00 + In a discussion on the bitcoin-dev mailing list, Mike Brooks agrees with Pieter Wuille's concerns about the impact of the FPNC idea on CPU consumption and the electorate. He argues that the "getdata" message is a problem for operators and suggests that the threshold for a patch may be too high. Mike believes that FPNC can rebalance incentives and resolve abuses that reshape the electorate, leading to a more decentralized and fair network than the current "first seen" approach.Pieter Wuille responds to Mike, pointing out that Greg Maxwell is not part of the conversation and clarifying that the discussion mainly revolves around a DoS attack report, which was ultimately a mistake.The discussion thread focuses on two proposed changes to address the issues of miner withholding attacks and network decentralization. The current problem is that miners have an incentive to withhold blocks to gain an advantage in calculating the next block, resulting in a centralized network and transaction delays. The proposed solution involves rebalancing selfish-mining incentives, faster block creation times, and implementing FPNC. However, ZmnSCPxj warns about the reintroduction of selfish mining attacks if FPNC is implemented, making it a hard NAK. Despite the risks, proponents argue that the proposed changes will benefit the network and users.The article explains that the miner withholding attack is a significant issue in the Bitcoin network, leading to centralization and delays in transactions. FPNC is proposed as a solution, introducing a floating-point fitness value for each block to enable fair disagreement resolution and reduce the incentive to withhold blocks. By speeding up block formation time and maintaining inflation targets, the impact of malignant miners can be mitigated. The proposed changes aim to reduce unfair advantages given to large mining pools and promote honest mining practices.The author discusses the miner withholding attack and FPNC, highlighting the unintended incentive it creates for miners to hold onto blocks. Withholding blocks gives major mining pools an unfair advantage, contributes to centralization, and delays transactions. The proposed solution, FPNC, is considered a hard NAK due to the risk of reintroducing selfish mining attacks. The author suggests raising the threshold to 33% as a potential solution.Mike Brooks reveals that the idea for FPNC came from a conversation with ZmnSCPxj regarding re-org stability. After discussing with ZmnSCPxj and Greg Maxwell, it was agreed that the current problems facing the network are more significant than theoretical ones. Pieter Wuille clarifies that the discussion primarily revolves around a DoS attack report that turned out to be a mistake. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml b/static/bitcoin-dev/Oct_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml index 6fc36c6cff..8c52e97dbc 100644 --- a/static/bitcoin-dev/Oct_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml +++ b/static/bitcoin-dev/Oct_2020/combined_Progress-on-bech32-for-future-Segwit-Versions-BIP-173-.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Progress on bech32 for future Segwit Versions (BIP-173) - 2023-08-02T02:47:10.950630+00:00 - - Pieter Wuille 2020-12-18 02:02:04+00:00 - - - Ryan Grant 2020-12-08 17:39:23+00:00 - - - Pieter Wuille 2020-12-06 20:43:49+00:00 - - - David A. Harding 2020-12-06 13:04:53+00:00 - - - Pieter Wuille 2020-12-05 23:10:51+00:00 - - - Pieter Wuille 2020-12-05 22:59:17+00:00 - - - Mike Schmidt 2020-11-06 19:49:44+00:00 - - - Pieter Wuille 2020-10-28 00:20:40+00:00 - - - Rusty Russell 2020-10-21 04:51:34+00:00 - - - Rusty Russell 2020-10-21 04:39:32+00:00 - - - ZmnSCPxj 2020-10-21 03:05:35+00:00 - - - Mike Schmidt 2020-10-20 23:52:07+00:00 - - - Pieter Wuille 2020-10-20 20:12:25+00:00 - - - David A. Harding 2020-10-20 10:29:52+00:00 - - - Riccardo Casatta 2020-10-20 09:21:43+00:00 - - - Rusty Russell 2020-10-20 03:31:45+00:00 - - - Rusty Russell 2020-10-20 00:42:06+00:00 - - - Pieter Wuille 2020-10-19 22:55:50+00:00 - - - Rusty Russell 2020-10-19 00:49:17+00:00 - - - Pieter Wuille 2020-10-16 21:09:04+00:00 - - - Rusty Russell 2020-10-15 01:40:30+00:00 - - - Russell O'Connor 2020-10-08 15:21:47+00:00 - - - David A. Harding 2020-10-08 14:59:38+00:00 - - - Rusty Russell 2020-10-08 00:21:10+00:00 - + 2025-09-26T15:37:07.236744+00:00 + python-feedgen + + + [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173) Rusty Russell + 2020-10-08T00:21:00.000Z + + + David A. Harding + 2020-10-08T14:59:00.000Z + + + Russell O'Connor + 2020-10-08T15:21:00.000Z + + + Rusty Russell + 2020-10-15T01:40:00.000Z + + + Pieter Wuille + 2020-10-16T21:09:00.000Z + + + Rusty Russell + 2020-10-19T00:49:00.000Z + + + Pieter Wuille + 2020-10-19T22:55:00.000Z + + + Rusty Russell + 2020-10-20T00:42:00.000Z + + + Rusty Russell + 2020-10-20T03:31:00.000Z + + + Riccardo Casatta + 2020-10-20T09:21:00.000Z + + + David A. Harding + 2020-10-20T10:29:00.000Z + + + Pieter Wuille + 2020-10-20T20:12:00.000Z + + + Mike Schmidt + 2020-10-20T23:52:00.000Z + + + ZmnSCPxj + 2020-10-21T03:05:00.000Z + + + Rusty Russell + 2020-10-21T04:39:00.000Z + + + Rusty Russell + 2020-10-21T04:51:00.000Z + + + Pieter Wuille + 2020-10-28T00:20:00.000Z + + + Mike Schmidt + 2020-11-06T19:49:00.000Z + + + Pieter Wuille + 2020-12-05T22:59:00.000Z + + + Pieter Wuille + 2020-12-05T23:10:00.000Z + + + David A. Harding + 2020-12-06T13:04:00.000Z + + + Pieter Wuille + 2020-12-06T20:43:00.000Z + + + Ryan Grant + 2020-12-08T17:39:00.000Z + + + Pieter Wuille + 2020-12-18T02:02:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Progress on bech32 for future Segwit Versions (BIP-173) - 2023-08-02T02:47:10.950630+00:00 + 2025-09-26T15:37:07.239482+00:00 - In a recent discussion on the Bitcoin mailing list, Pieter Wuille and Rusty Russell explored the implementation of changes to witness version 1 (v1) addresses. Currently, there are no v1 receivers, so the focus is on determining what software and infrastructure support sending to v1 addresses and whether they will upgrade. The first option discussed is to continue using v1, while the second option involves upgrading to a new version. There are concerns about trailing typos causing issues for non-upgraded software under option 1. Option 2, on the other hand, would likely lead to fixes when someone attempts a v1 send. However, it is possible that non-upgraded software may never get fixed, delaying the ability to use v1 addresses.Pieter is interested in understanding which codebases, services, and infrastructure currently support sending to witness v1 BIP173 addresses. Rusty suggests spamming an address from various sources to test compatibility with v1 addresses. They discuss the potential adoption of new technology based on the replacement of older infrastructure and codebases. Both Pieter and Rusty acknowledge that their thinking on this matter may change over time.Another proposal brought up by Rusty Russell involves two options for the future of v1 receivers. The first option is to continue using v1, while the second option requires upgrading to a new version. The support for sending to v1 BIP173 addresses is a key consideration in making this decision. Rusty favors the second option as it forces upgrades and breaks clearly. He believes that accepting v1 addresses without upgrades could create liabilities. David A. Harding agrees with the first proposal, highlighting the effort put into obtaining widespread support for bech32 addresses. Harding suggests that consensus should restrict v1 witness program size to maximize safety.In a separate thread, David A. Harding expresses his preference for using the backwards compatible proposal from BIPs PR#945. He suggests that consensus should restrict v1 witness program size by rejecting transactions with scriptPubKeys paying v1 witness programs that aren't exactly 32 bytes. Harding believes that deferring a hard decision is not useful, and he hopes that most software will have implemented length limits by the time segwit v2 is used.Rusty Russell proposes an alternative to the length restrictions discussed in a BIPs pull request. The alternative involves using a checksum change based on the first byte, unless the first byte is 0. There are two proposals debated in the discussion. The first proposal suggests length restrictions for future segwits, while the second proposal suggests a checksum change based on the first byte. Rusty prefers the second option as it forces upgrades and breaks clearly. However, David A. Harding argues that the second option does not force upgrades but creates another opt-in address format. Harding favors the backwards compatible proposal from BIPs PR#945 and suggests consensus restricting v1 witness program size for safety purposes.The author of the proposal suggests an alternative to length restrictions proposed by Rusty Russell. The alternative involves using a variant based on the first byte, unless the first byte is 0. There are two proposals discussed: length restrictions and a checksum change based on the first byte. The first proposal restricts future segwit versions, while the second weakens guarantees against typos. The author prefers the second proposal as it forces upgrades and addresses the length extension bug. They emphasize the need for a decision to be made promptly to begin upgrading software. It is also mentioned that Lightning uses bech32 over longer lengths but will follow Bitcoin's choice.Overall, the discussions revolve around the implementation of changes to witness version 1 addresses, the support for sending to v1 BIP173 addresses, and the options for future versions. Various proposals and concerns are raised regarding compatibility, upgrades, safety, and the simplicity of the changes. The participants acknowledge that their perspectives may evolve over time and emphasize the importance of gathering data and making informed decisions. 2020-12-18T02:02:04+00:00 + In a recent discussion on the Bitcoin mailing list, Pieter Wuille and Rusty Russell explored the implementation of changes to witness version 1 (v1) addresses. Currently, there are no v1 receivers, so the focus is on determining what software and infrastructure support sending to v1 addresses and whether they will upgrade. The first option discussed is to continue using v1, while the second option involves upgrading to a new version. There are concerns about trailing typos causing issues for non-upgraded software under option 1. Option 2, on the other hand, would likely lead to fixes when someone attempts a v1 send. However, it is possible that non-upgraded software may never get fixed, delaying the ability to use v1 addresses.Pieter is interested in understanding which codebases, services, and infrastructure currently support sending to witness v1 BIP173 addresses. Rusty suggests spamming an address from various sources to test compatibility with v1 addresses. They discuss the potential adoption of new technology based on the replacement of older infrastructure and codebases. Both Pieter and Rusty acknowledge that their thinking on this matter may change over time.Another proposal brought up by Rusty Russell involves two options for the future of v1 receivers. The first option is to continue using v1, while the second option requires upgrading to a new version. The support for sending to v1 BIP173 addresses is a key consideration in making this decision. Rusty favors the second option as it forces upgrades and breaks clearly. He believes that accepting v1 addresses without upgrades could create liabilities. David A. Harding agrees with the first proposal, highlighting the effort put into obtaining widespread support for bech32 addresses. Harding suggests that consensus should restrict v1 witness program size to maximize safety.In a separate thread, David A. Harding expresses his preference for using the backwards compatible proposal from BIPs PR#945. He suggests that consensus should restrict v1 witness program size by rejecting transactions with scriptPubKeys paying v1 witness programs that aren't exactly 32 bytes. Harding believes that deferring a hard decision is not useful, and he hopes that most software will have implemented length limits by the time segwit v2 is used.Rusty Russell proposes an alternative to the length restrictions discussed in a BIPs pull request. The alternative involves using a checksum change based on the first byte, unless the first byte is 0. There are two proposals debated in the discussion. The first proposal suggests length restrictions for future segwits, while the second proposal suggests a checksum change based on the first byte. Rusty prefers the second option as it forces upgrades and breaks clearly. However, David A. Harding argues that the second option does not force upgrades but creates another opt-in address format. Harding favors the backwards compatible proposal from BIPs PR#945 and suggests consensus restricting v1 witness program size for safety purposes.The author of the proposal suggests an alternative to length restrictions proposed by Rusty Russell. The alternative involves using a variant based on the first byte, unless the first byte is 0. There are two proposals discussed: length restrictions and a checksum change based on the first byte. The first proposal restricts future segwit versions, while the second weakens guarantees against typos. The author prefers the second proposal as it forces upgrades and addresses the length extension bug. They emphasize the need for a decision to be made promptly to begin upgrading software. It is also mentioned that Lightning uses bech32 over longer lengths but will follow Bitcoin's choice.Overall, the discussions revolve around the implementation of changes to witness version 1 addresses, the support for sending to v1 BIP173 addresses, and the options for future versions. Various proposals and concerns are raised regarding compatibility, upgrades, safety, and the simplicity of the changes. The participants acknowledge that their perspectives may evolve over time and emphasize the importance of gathering data and making informed decisions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_RFC-BIP-0002-Defer-not-reject-.xml b/static/bitcoin-dev/Oct_2020/combined_RFC-BIP-0002-Defer-not-reject-.xml index 9ef4a0d61a..d86e7075bd 100644 --- a/static/bitcoin-dev/Oct_2020/combined_RFC-BIP-0002-Defer-not-reject-.xml +++ b/static/bitcoin-dev/Oct_2020/combined_RFC-BIP-0002-Defer-not-reject-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - RFC BIP-0002: Defer, not reject. - 2023-08-02T02:50:33.531766+00:00 - - アルム　カールヨハン 2020-11-02 12:11:40+00:00 - - - アルム　カールヨハン 2020-10-13 10:06:09+00:00 - + 2025-09-26T15:37:24.057856+00:00 + python-feedgen + + + [bitcoin-dev] RFC BIP-0002: Defer, not reject アルム　カールヨハン + 2020-10-13T10:06:00.000Z + + + アルム　カールヨハン + 2020-11-02T12:11:00.000Z + + - python-feedgen + 2 Combined summary - RFC BIP-0002: Defer, not reject. - 2023-08-02T02:50:33.531766+00:00 + 2025-09-26T15:37:24.058314+00:00 - A proposed change to BIP-0002 has been made by アルム　カールヨハン, suggesting that the current 3-year-rule be modified. Currently, a BIP can only be changed to "Rejected" status after three years. However, アルム　カールヨハン proposes that the status should be changed to "Deferred" instead of "Rejected". The current rules for rejecting a BIP have ambiguous meanings, with both "soft" and "hard" rejections. The aim of this proposal is to disambiguate the second option into "deferred" status or add a new status called "Inactive".In addition to this proposal, there is an alternative suggestion that proposes updating the rejection criteria in BIP 2. The proposal recommends requiring an actual concern rather than just a lack of progress in three years for a BIP to be rejected. The details of these proposals can be found on the following link: https://github.com/bitcoin/bips/pull/1016. Readers are encouraged to consider either one or both of these proposals. The proposer of the minor change to BIP-0002 suggests allowing anyone to change the status of a BIP to "Deferred" instead of "Rejected". The current 3-year-rule already has ambiguous meaning with "hard" and "soft" rejects. The intention of this proposal is to clarify the second option by either classifying it as "deferred" or introducing a new status called "Inactive". It is important to note that the BIP editor will not unreasonably reject a BIP. There are several reasons for rejecting a BIP, including duplication of effort, disregard for formatting rules, being too unfocused or broad, being technically unsound, not providing proper motivation or addressing backward compatibility, or not aligning with the Bitcoin philosophy. If a BIP has not made progress in three years, it may be changed from Draft or Proposed status to Rejected status upon request by any person. However, if the champion of the BIP provides revisions that meaningfully address public criticism, it may be changed to Draft status. Alternatively, if the BIP meets the required criteria as described in the previous paragraph, it may be changed to Proposed status. 2020-11-02T12:11:40+00:00 + A proposed change to BIP-0002 has been made by アルム　カールヨハン, suggesting that the current 3-year-rule be modified. Currently, a BIP can only be changed to "Rejected" status after three years. However, アルム　カールヨハン proposes that the status should be changed to "Deferred" instead of "Rejected". The current rules for rejecting a BIP have ambiguous meanings, with both "soft" and "hard" rejections. The aim of this proposal is to disambiguate the second option into "deferred" status or add a new status called "Inactive".In addition to this proposal, there is an alternative suggestion that proposes updating the rejection criteria in BIP 2. The proposal recommends requiring an actual concern rather than just a lack of progress in three years for a BIP to be rejected. The details of these proposals can be found on the following link: https://github.com/bitcoin/bips/pull/1016. Readers are encouraged to consider either one or both of these proposals. The proposer of the minor change to BIP-0002 suggests allowing anyone to change the status of a BIP to "Deferred" instead of "Rejected". The current 3-year-rule already has ambiguous meaning with "hard" and "soft" rejects. The intention of this proposal is to clarify the second option by either classifying it as "deferred" or introducing a new status called "Inactive". It is important to note that the BIP editor will not unreasonably reject a BIP. There are several reasons for rejecting a BIP, including duplication of effort, disregard for formatting rules, being too unfocused or broad, being technically unsound, not providing proper motivation or addressing backward compatibility, or not aligning with the Bitcoin philosophy. If a BIP has not made progress in three years, it may be changed from Draft or Proposed status to Rejected status upon request by any person. However, if the champion of the BIP provides revisions that meaningfully address public criticism, it may be changed to Draft status. Alternatively, if the BIP meets the required criteria as described in the previous paragraph, it may be changed to Proposed status. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2020/combined_Suggestion-Solve-year-2106-problem-by-taking-timestamps-mod-2-32.xml b/static/bitcoin-dev/Oct_2020/combined_Suggestion-Solve-year-2106-problem-by-taking-timestamps-mod-2-32.xml index 86d48c61fc..46b4de6e80 100644 --- a/static/bitcoin-dev/Oct_2020/combined_Suggestion-Solve-year-2106-problem-by-taking-timestamps-mod-2-32.xml +++ b/static/bitcoin-dev/Oct_2020/combined_Suggestion-Solve-year-2106-problem-by-taking-timestamps-mod-2-32.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 - 2023-08-02T02:41:11.701704+00:00 - - Pieter Wuille 2020-10-16 21:58:20+00:00 - - - yanmaani at cock.li 2020-09-19 12:36:47+00:00 - + 2025-09-26T15:37:21.972286+00:00 + python-feedgen + + + [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 yanmaani + 2020-09-19T12:36:00.000Z + + + Pieter Wuille + 2020-10-16T21:58:00.000Z + + - python-feedgen + 2 Combined summary - Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 - 2023-08-02T02:41:11.701704+00:00 + 2025-09-26T15:37:21.972738+00:00 - In a Bitcoin-dev email thread, user yanmaani has suggested an amendment to the timestamp rules in the Bitcoin network. Currently, there are certain rules in place for block timestamps - they must not be lower than the median of the last 11 blocks, greater than the current time plus two hours, or greater than 2^32, which would cause Bitcoin to "die" around February 7th, 2106.Yanmaani's proposed solution involves treating block headers as having a 64-bit timestamp. The requirement is that the difference between the timestamp and the median timestamp of the past 11 blocks should be at least one and at most 2^32. To achieve this, the higher 32 bits of the timestamp are set equal to the median of the past 11 blocks on deserialization. If this violates the rule mentioned above, it is set one higher.User Pieter believes that Yanmaani's solution is in line with what will eventually be addressed and thinks it may be worth considering as a BIP (Bitcoin Improvement Proposal) in the future.Currently, Bitcoin faces a problem with its timestamp rules. There are restrictions that prevent the block timestamp from being lower than the median of the last 11 blocks, greater than the current time plus two hours, or greater than 2^32. This means that if no timestamp below 2^32 exceeds the median of the last 11 blocks, Bitcoin would "die" on or about February 7, 2106.One proposed solution to this problem is to change the rules so that the block timestamp plus k*2^32 may not be lower than the median of the last 11 blocks and may not be greater than the current time plus two hours. It is important to note that k is an integer with the same value for the calculations of both Rule 1 and Rule 2. However, this solution would cause a hardfork in 2106, approximately 85.5 years from now, and it is expected that 95% of nodes would have updated by then.Another proposed solution is to use 64-bit timestamps. However, this would break compatibility with other software that has specific expectations of header fields, such as ASICs' firmware. Furthermore, this solution would cause a hardfork before the date of timestamp overflow, making it less appropriate.It remains to be seen whether Yanmaani's idea is worth considering as a BIP. This discussion highlights the challenges faced by Bitcoin in relation to its timestamp rules and the potential solutions that could be explored in order to address these issues. 2020-10-16T21:58:20+00:00 + In a Bitcoin-dev email thread, user yanmaani has suggested an amendment to the timestamp rules in the Bitcoin network. Currently, there are certain rules in place for block timestamps - they must not be lower than the median of the last 11 blocks, greater than the current time plus two hours, or greater than 2^32, which would cause Bitcoin to "die" around February 7th, 2106.Yanmaani's proposed solution involves treating block headers as having a 64-bit timestamp. The requirement is that the difference between the timestamp and the median timestamp of the past 11 blocks should be at least one and at most 2^32. To achieve this, the higher 32 bits of the timestamp are set equal to the median of the past 11 blocks on deserialization. If this violates the rule mentioned above, it is set one higher.User Pieter believes that Yanmaani's solution is in line with what will eventually be addressed and thinks it may be worth considering as a BIP (Bitcoin Improvement Proposal) in the future.Currently, Bitcoin faces a problem with its timestamp rules. There are restrictions that prevent the block timestamp from being lower than the median of the last 11 blocks, greater than the current time plus two hours, or greater than 2^32. This means that if no timestamp below 2^32 exceeds the median of the last 11 blocks, Bitcoin would "die" on or about February 7, 2106.One proposed solution to this problem is to change the rules so that the block timestamp plus k*2^32 may not be lower than the median of the last 11 blocks and may not be greater than the current time plus two hours. It is important to note that k is an integer with the same value for the calculations of both Rule 1 and Rule 2. However, this solution would cause a hardfork in 2106, approximately 85.5 years from now, and it is expected that 95% of nodes would have updated by then.Another proposed solution is to use 64-bit timestamps. However, this would break compatibility with other software that has specific expectations of header fields, such as ASICs' firmware. Furthermore, this solution would cause a hardfork before the date of timestamp overflow, making it less appropriate.It remains to be seen whether Yanmaani's idea is worth considering as a BIP. This discussion highlights the challenges faced by Bitcoin in relation to its timestamp rules and the potential solutions that could be explored in order to address these issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml b/static/bitcoin-dev/Oct_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml index 677297ebed..ce7f96888d 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin - 2023-08-02T04:51:14.026095+00:00 + 2025-09-26T16:03:35.617045+00:00 + python-feedgen jlspc 2021-10-10 22:03:38+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin - 2023-08-02T04:51:14.026095+00:00 + 2025-09-26T16:03:35.617210+00:00 - In a recent email exchange, John responded to Anthony Towns' gratitude for reviewing his paper on Inherited IDs (IIDs) and clarified some misunderstandings. Despite the use of an operator in certain protocols, John emphasized that IIDs remain trust-free since the operator cannot control funds or hinder others from receiving their rightful share. Moreover, the simulation of IIDs with anyprevout is not feasible due to its lack of a covenant mechanism, which is crucial for unconditional ownership transfer.John's paper highlights the fundamental functionality of IIDs, namely the ability to facilitate "update-forest" and "challenge-and-response" operations. These features enable the secure transfer of channel ownership in a trust-free manner using a single transaction. By utilizing this approach, IIDs can eliminate the need for watchtowers and create factories with an unlimited number of parties and channels. Importantly, these achievements are made possible by implementing a safer change to Bitcoin compared to the support provided for floating transactions.During a conversation between John Law and ZmnSCPxj, ZmnSCPxj presents a counterargument regarding the necessity of on-chain transactions for updating a factory's set of channels. ZmnSCPxj asserts that factories can already be created without relying on Taproot technology. This can be achieved by initially creating an n-of-n output for the funding transaction, which can then be split through an off-chain transaction. To modify the set of channels, participants simply create and sign an alternate transaction that spends the original output to a new n-of-n output involving the same participants. Subsequently, they broadcast this transaction to update the channel configuration. ZmnSCPxj describes this process as akin to a "no updates" factory, as it bypasses the closing transaction of the previous factory by initiating a new one.Overall, John's response sheds light on the capabilities of IIDs and their potential to revolutionize the way channels are managed and ownership is transferred. Meanwhile, ZmnSCPxj introduces an alternative perspective on the concept of factories and challenges the necessity of on-chain updates. 2021-10-10T22:03:38+00:00 + In a recent email exchange, John responded to Anthony Towns' gratitude for reviewing his paper on Inherited IDs (IIDs) and clarified some misunderstandings. Despite the use of an operator in certain protocols, John emphasized that IIDs remain trust-free since the operator cannot control funds or hinder others from receiving their rightful share. Moreover, the simulation of IIDs with anyprevout is not feasible due to its lack of a covenant mechanism, which is crucial for unconditional ownership transfer.John's paper highlights the fundamental functionality of IIDs, namely the ability to facilitate "update-forest" and "challenge-and-response" operations. These features enable the secure transfer of channel ownership in a trust-free manner using a single transaction. By utilizing this approach, IIDs can eliminate the need for watchtowers and create factories with an unlimited number of parties and channels. Importantly, these achievements are made possible by implementing a safer change to Bitcoin compared to the support provided for floating transactions.During a conversation between John Law and ZmnSCPxj, ZmnSCPxj presents a counterargument regarding the necessity of on-chain transactions for updating a factory's set of channels. ZmnSCPxj asserts that factories can already be created without relying on Taproot technology. This can be achieved by initially creating an n-of-n output for the funding transaction, which can then be split through an off-chain transaction. To modify the set of channels, participants simply create and sign an alternate transaction that spends the original output to a new n-of-n output involving the same participants. Subsequently, they broadcast this transaction to update the channel configuration. ZmnSCPxj describes this process as akin to a "no updates" factory, as it bypasses the closing transaction of the previous factory by initiating a new one.Overall, John's response sheds light on the capabilities of IIDs and their potential to revolutionize the way channels are managed and ownership is transferred. Meanwhile, ZmnSCPxj introduces an alternative perspective on the concept of factories and challenges the necessity of on-chain updates. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Interrogating-a-BIP157-server-BIP158-change-proposal.xml b/static/bitcoin-dev/Oct_2021/combined_Interrogating-a-BIP157-server-BIP158-change-proposal.xml index 89e1822382..1abc6ab299 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Interrogating-a-BIP157-server-BIP158-change-proposal.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Interrogating-a-BIP157-server-BIP158-change-proposal.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Interrogating a BIP157 server, BIP158 change proposal - 2023-08-02T00:28:46.332040+00:00 - - Dustin Dettmer 2021-10-03 09:53:00+00:00 - - - Pieter Wuille 2019-02-07 20:36:25+00:00 - - - Tamas Blummer 2019-02-06 21:17:17+00:00 - - - Tamas Blummer 2019-02-06 19:48:09+00:00 - - - Gregory Maxwell 2019-02-06 18:17:11+00:00 - - - Tamas Blummer 2019-02-06 08:09:55+00:00 - - - Olaoluwa Osuntokun 2019-02-06 00:17:05+00:00 - - - Olaoluwa Osuntokun 2019-02-06 00:05:57+00:00 - - - Tamas Blummer 2019-02-05 20:10:09+00:00 - - - Matt Corallo 2019-02-05 12:21:45+00:00 - - - Olaoluwa Osuntokun 2019-02-05 01:42:57+00:00 - - - Tamas Blummer 2019-02-04 20:59:44+00:00 - - - Jim Posen 2019-02-04 20:18:08+00:00 - - - Tamas Blummer 2019-02-04 11:41:20+00:00 - + 2025-09-26T16:03:37.735244+00:00 + python-feedgen + + + [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal Tamas Blummer + 2019-02-04T11:41:00.000Z + + + Jim Posen + 2019-02-04T20:18:00.000Z + + + Tamas Blummer + 2019-02-04T20:59:00.000Z + + + Olaoluwa Osuntokun + 2019-02-05T01:42:00.000Z + + + Matt Corallo + 2019-02-05T12:21:00.000Z + + + Tamas Blummer + 2019-02-05T20:10:00.000Z + + + Olaoluwa Osuntokun + 2019-02-06T00:05:00.000Z + + + Olaoluwa Osuntokun + 2019-02-06T00:17:00.000Z + + + Tamas Blummer + 2019-02-06T08:09:00.000Z + + + Gregory Maxwell + 2019-02-06T18:17:00.000Z + + + Tamas Blummer + 2019-02-06T19:48:00.000Z + + + Tamas Blummer + 2019-02-06T21:17:00.000Z + + + Pieter Wuille + 2019-02-07T20:36:00.000Z + + + Dustin Dettmer + 2021-10-03T09:53:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Interrogating a BIP157 server, BIP158 change proposal - 2023-08-02T00:28:46.333042+00:00 + 2025-09-26T16:03:37.736798+00:00 - In a recent email exchange, Tamas Blummer and Olaoluwa Osuntokun discussed the advantages and disadvantages of various Bitcoin block filters. Blummer suggested that moving to a spent outpoint + output script filter would be more secure and allow light clients to perform further probabilistic checks. However, Osuntokun believes it is too late to change the current deployment of the BIPs and instead suggests adding new filter types in the future.Jim Posen also adds to the discussion, proposing three possibilities for improving client protocol given the limitations of the current filter system. Option two, which involves clients tracking multiple possible filter header chains and considering the union of their matches, is favored by Posen due to its simplicity and support from the BIP 157 P2P protocol.Tamas Blummer has suggested a change to BIP158, which would allow for a decision on which filter chain is correct at lower bandwidth usage. He proposes having a basic filter that contains exactly the spent outpoints and the scriptPubKey of each output aside from all OP_RETURN output scripts for each transaction in a block. The client could then download the entire filter of the block and check it entirely against the contents of the same block. If there is a divergence at a checkpoint, the client would request the filter headers between the last matching and first divergent checkpoint to figure out which block's filter is the first that does not match previous assumptions. The client would then download the corresponding block, check that its header fits the PoW secured best header chain, re-calculate merkle root of its transaction list to know that it is complete and query the filter to see if every output script of every transaction is contained in there. If not, the server is lying, and the case is closed, and the server disconnected.In an email exchange between Tamas Blummer and Laolu Osuntokun, Tamas argued that the current design choice of filters limits light clients from proving filter correctness. He suggested a change to BIP158 to use spent outpoints and output scripts instead of input and output scripts, which would allow for filter correctness to be proven by downloading only the block in question. The advantages of this approach include a simpler interrogation process for filter servers and the ability for clients to decide on the availability of spent coins without maintaining the UTXO set. Jim Posen suggested three possibilities to address this issue, including introducing a new P2P message to retrieve all prev-outputs for a given block, tracking multiple possible filter header chains, or committing filters into the chain via witness reserved value or coinbase OP_RETURN. However, option 2 was favored as it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written.In a Bitcoin development thread, Jim Posen proposed a solution to prevent "input script malleability" and restrict what an attacker can do. This involves introducing a new P2P message to retrieve all prev-outputs for a given block, and verifying the scripts against the block by executing them. However, Olaoluwa Osuntokun stated that it is too late in the current deployment of the BIPs to change things around yet again. Instead, he suggests that the BIP already has measures in place for adding new filter types in the future, which may be worthwhile additions. Matt expressed confusion regarding this proposal and its potential effectiveness.A potential change to Bitcoin Improvement Proposal (BIP) 157/158 has been discussed on the Bitcoin-dev mailing list. Tamas Blummer suggests that a filter collecting spent output and output scripts would be more useful than the current design, as it allows for a decision on filter correctness by knowing the block only. This filter is just as useful for wallets as one on spent script since they naturally scan the blockchain forward and learn about their coins by the output script before they need to check spends of those outpoints.Blummer's proposal involves implementing an interrogation by downloading blocks at checkpoints since it is much simpler than following multiple possible filter paths. A spent outpoint filter allows for deciding on coin availability based on immutable store without the updated and eventually rolled back UTXO store. False positives can be sorted out with a block download.On the other hand, Jim Posen suggested three possibilities in this regard. The first involves introducing a new P2P message to retrieve all prev-outputs for a given block and verifying the scripts against the block by executing them. The second includes clients tracking multiple possible filter header chains and considering the union of their matches. If any filter received for a particular block header matches, the client downloads the block. The third possibility involves committing the filters into the chain via witness reserved value or coinbase OP_RETURN and giving up on the pre-softfork BIP 157 P2P mode.The discussion indicates the need for more discussion on the client protocol since clients cannot reliably determine the integrity of a block filter in a bandwidth-efficient manner 2021-10-03T09:53:00+00:00 + In a recent email exchange, Tamas Blummer and Olaoluwa Osuntokun discussed the advantages and disadvantages of various Bitcoin block filters. Blummer suggested that moving to a spent outpoint + output script filter would be more secure and allow light clients to perform further probabilistic checks. However, Osuntokun believes it is too late to change the current deployment of the BIPs and instead suggests adding new filter types in the future.Jim Posen also adds to the discussion, proposing three possibilities for improving client protocol given the limitations of the current filter system. Option two, which involves clients tracking multiple possible filter header chains and considering the union of their matches, is favored by Posen due to its simplicity and support from the BIP 157 P2P protocol.Tamas Blummer has suggested a change to BIP158, which would allow for a decision on which filter chain is correct at lower bandwidth usage. He proposes having a basic filter that contains exactly the spent outpoints and the scriptPubKey of each output aside from all OP_RETURN output scripts for each transaction in a block. The client could then download the entire filter of the block and check it entirely against the contents of the same block. If there is a divergence at a checkpoint, the client would request the filter headers between the last matching and first divergent checkpoint to figure out which block's filter is the first that does not match previous assumptions. The client would then download the corresponding block, check that its header fits the PoW secured best header chain, re-calculate merkle root of its transaction list to know that it is complete and query the filter to see if every output script of every transaction is contained in there. If not, the server is lying, and the case is closed, and the server disconnected.In an email exchange between Tamas Blummer and Laolu Osuntokun, Tamas argued that the current design choice of filters limits light clients from proving filter correctness. He suggested a change to BIP158 to use spent outpoints and output scripts instead of input and output scripts, which would allow for filter correctness to be proven by downloading only the block in question. The advantages of this approach include a simpler interrogation process for filter servers and the ability for clients to decide on the availability of spent coins without maintaining the UTXO set. Jim Posen suggested three possibilities to address this issue, including introducing a new P2P message to retrieve all prev-outputs for a given block, tracking multiple possible filter header chains, or committing filters into the chain via witness reserved value or coinbase OP_RETURN. However, option 2 was favored as it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written.In a Bitcoin development thread, Jim Posen proposed a solution to prevent "input script malleability" and restrict what an attacker can do. This involves introducing a new P2P message to retrieve all prev-outputs for a given block, and verifying the scripts against the block by executing them. However, Olaoluwa Osuntokun stated that it is too late in the current deployment of the BIPs to change things around yet again. Instead, he suggests that the BIP already has measures in place for adding new filter types in the future, which may be worthwhile additions. Matt expressed confusion regarding this proposal and its potential effectiveness.A potential change to Bitcoin Improvement Proposal (BIP) 157/158 has been discussed on the Bitcoin-dev mailing list. Tamas Blummer suggests that a filter collecting spent output and output scripts would be more useful than the current design, as it allows for a decision on filter correctness by knowing the block only. This filter is just as useful for wallets as one on spent script since they naturally scan the blockchain forward and learn about their coins by the output script before they need to check spends of those outpoints.Blummer's proposal involves implementing an interrogation by downloading blocks at checkpoints since it is much simpler than following multiple possible filter paths. A spent outpoint filter allows for deciding on coin availability based on immutable store without the updated and eventually rolled back UTXO store. False positives can be sorted out with a block download.On the other hand, Jim Posen suggested three possibilities in this regard. The first involves introducing a new P2P message to retrieve all prev-outputs for a given block and verifying the scripts against the block by executing them. The second includes clients tracking multiple possible filter header chains and considering the union of their matches. If any filter received for a particular block header matches, the client downloads the block. The third possibility involves committing the filters into the chain via witness reserved value or coinbase OP_RETURN and giving up on the pre-softfork BIP 157 P2P mode.The discussion indicates the need for more discussion on the client protocol since clients cannot reliably determine the integrity of a block filter in a bandwidth-efficient manner - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml b/static/bitcoin-dev/Oct_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml index 6a174a0cb6..2af84ffe7a 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Mock introducing vulnerability in important Bitcoin projects - 2023-08-02T04:51:41.971421+00:00 - - Anthony Towns 2022-08-19 03:09:46+00:00 - - - Prayank 2021-11-18 20:29:24+00:00 - - - ZmnSCPxj 2021-10-04 03:59:34+00:00 - - - Luke Dashjr 2021-10-03 21:33:43+00:00 - - - Manuel Costa 2021-10-03 09:11:53+00:00 - - - Prayank 2021-10-02 09:19:37+00:00 - - - Ryan Grant 2021-10-01 20:15:56+00:00 - - - Prayank 2021-10-01 15:55:15+00:00 - - - ZmnSCPxj 2021-10-01 12:27:19+00:00 - - - Prayank 2021-10-01 03:03:00+00:00 - - - Ruben Somsen 2021-09-30 20:36:08+00:00 - - - Prayank 2021-09-27 23:19:40+00:00 - - - ZmnSCPxj 2021-09-27 10:13:02+00:00 - - - Prayank 2021-09-27 01:52:41+00:00 - + 2025-09-26T16:03:25.069131+00:00 + python-feedgen + + + [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects Prayank + 2021-09-27T01:52:00.000Z + + + ZmnSCPxj + 2021-09-27T10:13:00.000Z + + + Prayank + 2021-09-27T23:19:00.000Z + + + Ruben Somsen + 2021-09-30T20:36:00.000Z + + + Prayank + 2021-10-01T03:03:00.000Z + + + ZmnSCPxj + 2021-10-01T12:27:00.000Z + + + Prayank + 2021-10-01T15:55:00.000Z + + + Ryan Grant + 2021-10-01T20:15:00.000Z + + + Prayank + 2021-10-02T09:19:00.000Z + + + Manuel Costa + 2021-10-03T09:11:00.000Z + + + Luke Dashjr + 2021-10-03T21:33:00.000Z + + + ZmnSCPxj + 2021-10-04T03:59:00.000Z + + + Prayank + 2021-11-18T20:29:00.000Z + + + Anthony Towns + 2022-08-19T03:09:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Mock introducing vulnerability in important Bitcoin projects - 2023-08-02T04:51:41.971421+00:00 + 2025-09-26T16:03:25.070732+00:00 - In November 2021, Prayank announced an exercise to test the review process in three Bitcoin projects: Bitcoin Core, LND, and Bisq. They created a salted hash for the username and planned to create pull requests over the next six months. If vulnerabilities were caught during the review process, they would publicly announce them, but if not, they would privately reveal them later. However, after nine months, there has been no public report on the exercise, leaving it unclear whether any vulnerabilities have been introduced.The email conversation emphasizes the importance of regularly testing and verifying the review process in open-source Bitcoin projects. One participant suggests using commit messages with specific requirements to test the process against attacks. Another participant proposes that developers should be forced to opt-in to practice rounds of testing, as they cannot opt-out of potential real-world attacks. The email concludes by emphasizing the importance of independent thought during the review process.ZmnSCPxj suggests improving the review process to prevent attacks and waste contributors' time. They propose a scheme involving commit messages with specific requirements and the option for developers to opt-out of the study. However, they note that developers cannot opt out of potential NSA attacks.A discussion thread raises concerns about potential attempts to introduce vulnerabilities into Bitcoin Core codebase. Some proposals suggest a "Red Team exercise" to test the system's resilience. Others argue for improving the review process instead. The proposed exercise would involve public precommitments collected at ceremonial intervals, with community approval granted for the inserted security flaws.The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes are proposed, including a sortition system. The ideal process involves one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The process includes public precommitments and the use of block hashes as a random oracle.The post proposes a scheme to improve security in Bitcoin development using a sortition system. The scheme involves public precommitments collected at ceremonial intervals, with hash1 being a sortition ticket and hash2 being a public precommitment. The random oracle could be block hashes, and the red-team-concurrency difficulty parameter could control the selection process. The developer would have community approval to opportunistically insert a security flaw.The proposed exercise aims to improve the reputation factor and review attention for new pull requests. It suggests a secret sortition system to encourage more developers to participate without harming their reputation. The scheme includes public precommitments collected at ceremonial intervals and a red-team-concurrency difficulty parameter.The email exchange between Prayank and ZmnSCPxj discusses the importance of review processes in open-source Bitcoin projects. They agree on the necessity of reviews to catch vulnerabilities and caution against using unmerged PRs in production without careful review. Prayank proposes an exercise to test the review process by introducing vulnerability-adding PRs, while ZmnSCPxj emphasizes the need for private handling of any vulnerabilities found.The email discussion highlights the importance of review processes for ensuring security in Bitcoin development. The group agrees that relying on reviews is better for security and discusses the value of testing vulnerabilities in the review process. They propose a plan to create pseudonyms and introduce vulnerability-adding PRs to targets to test the review processes. The plan includes inserting random numbers among the commitments and publicly praising successful reviews.Prayank's proposal to conduct an exercise to study vulnerabilities in Bitcoin projects is met with caution. Ruben Somsen advises getting approval from contributors before proceeding to avoid causing mistrust and extra work for existing contributors. Prayank emphasizes reviewing pull requests based on code rather than author claims and asks whether trusting authors or having a good review process is better for security. They mention several Bitcoin projects they plan to test and note that x00 will assist them in the exercise.Prayank proposes an exercise to study vulnerabilities in Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating new GitHub accounts, studying issues in various Bitcoin projects, preparing pull requests to introduce vulnerabilities, and documenting the results. x00 will assist Prayank in this exercise, which has no fixed completion date.The email thread discusses introducing vulnerabilities in Bitcoin projects and observing how maintainers and reviewers respond. Ruben Somsen advises caution and suggests obtaining approval from contributors beforehand. ZmnSCPxj proposes a method using hash names and randomized salt as precommitments. They also highlight the potential impact on existing contributors and refer to a similar event in the Linux community.Prayank proposes an exercise to introduce vulnerabilities in Bitcoin projects and document the responses of maintainers and reviewers. They plan to create new GitHub accounts, study issues in various Bitcoin projects, and prepare pull requests to introduce vulnerabilities. They mention x00 as someone who will assist them in the exercise.In an email exchange, Prayank proposes an exercise to introduce vulnerabilities in various important Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating 2022-08-19T03:09:46+00:00 + In November 2021, Prayank announced an exercise to test the review process in three Bitcoin projects: Bitcoin Core, LND, and Bisq. They created a salted hash for the username and planned to create pull requests over the next six months. If vulnerabilities were caught during the review process, they would publicly announce them, but if not, they would privately reveal them later. However, after nine months, there has been no public report on the exercise, leaving it unclear whether any vulnerabilities have been introduced.The email conversation emphasizes the importance of regularly testing and verifying the review process in open-source Bitcoin projects. One participant suggests using commit messages with specific requirements to test the process against attacks. Another participant proposes that developers should be forced to opt-in to practice rounds of testing, as they cannot opt-out of potential real-world attacks. The email concludes by emphasizing the importance of independent thought during the review process.ZmnSCPxj suggests improving the review process to prevent attacks and waste contributors' time. They propose a scheme involving commit messages with specific requirements and the option for developers to opt-out of the study. However, they note that developers cannot opt out of potential NSA attacks.A discussion thread raises concerns about potential attempts to introduce vulnerabilities into Bitcoin Core codebase. Some proposals suggest a "Red Team exercise" to test the system's resilience. Others argue for improving the review process instead. The proposed exercise would involve public precommitments collected at ceremonial intervals, with community approval granted for the inserted security flaws.The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes are proposed, including a sortition system. The ideal process involves one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The process includes public precommitments and the use of block hashes as a random oracle.The post proposes a scheme to improve security in Bitcoin development using a sortition system. The scheme involves public precommitments collected at ceremonial intervals, with hash1 being a sortition ticket and hash2 being a public precommitment. The random oracle could be block hashes, and the red-team-concurrency difficulty parameter could control the selection process. The developer would have community approval to opportunistically insert a security flaw.The proposed exercise aims to improve the reputation factor and review attention for new pull requests. It suggests a secret sortition system to encourage more developers to participate without harming their reputation. The scheme includes public precommitments collected at ceremonial intervals and a red-team-concurrency difficulty parameter.The email exchange between Prayank and ZmnSCPxj discusses the importance of review processes in open-source Bitcoin projects. They agree on the necessity of reviews to catch vulnerabilities and caution against using unmerged PRs in production without careful review. Prayank proposes an exercise to test the review process by introducing vulnerability-adding PRs, while ZmnSCPxj emphasizes the need for private handling of any vulnerabilities found.The email discussion highlights the importance of review processes for ensuring security in Bitcoin development. The group agrees that relying on reviews is better for security and discusses the value of testing vulnerabilities in the review process. They propose a plan to create pseudonyms and introduce vulnerability-adding PRs to targets to test the review processes. The plan includes inserting random numbers among the commitments and publicly praising successful reviews.Prayank's proposal to conduct an exercise to study vulnerabilities in Bitcoin projects is met with caution. Ruben Somsen advises getting approval from contributors before proceeding to avoid causing mistrust and extra work for existing contributors. Prayank emphasizes reviewing pull requests based on code rather than author claims and asks whether trusting authors or having a good review process is better for security. They mention several Bitcoin projects they plan to test and note that x00 will assist them in the exercise.Prayank proposes an exercise to study vulnerabilities in Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating new GitHub accounts, studying issues in various Bitcoin projects, preparing pull requests to introduce vulnerabilities, and documenting the results. x00 will assist Prayank in this exercise, which has no fixed completion date.The email thread discusses introducing vulnerabilities in Bitcoin projects and observing how maintainers and reviewers respond. Ruben Somsen advises caution and suggests obtaining approval from contributors beforehand. ZmnSCPxj proposes a method using hash names and randomized salt as precommitments. They also highlight the potential impact on existing contributors and refer to a similar event in the Linux community.Prayank proposes an exercise to introduce vulnerabilities in Bitcoin projects and document the responses of maintainers and reviewers. They plan to create new GitHub accounts, study issues in various Bitcoin projects, and prepare pull requests to introduce vulnerabilities. They mention x00 as someone who will assist them in the exercise.In an email exchange, Prayank proposes an exercise to introduce vulnerabilities in various important Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_On-the-regularity-of-soft-forks.xml b/static/bitcoin-dev/Oct_2021/combined_On-the-regularity-of-soft-forks.xml index da718ca7db..91990f7f84 100644 --- a/static/bitcoin-dev/Oct_2021/combined_On-the-regularity-of-soft-forks.xml +++ b/static/bitcoin-dev/Oct_2021/combined_On-the-regularity-of-soft-forks.xml @@ -1,47 +1,47 @@ - + 2 Combined summary - On the regularity of soft forks - 2023-08-02T04:54:30.049777+00:00 - - Billy Tetrud 2022-01-19 02:26:12+00:00 - - - Prayank 2022-01-18 17:22:05+00:00 - - - Billy Tetrud 2022-01-18 16:00:06+00:00 - - - vjudeu at gazeta.pl 2022-01-01 15:45:11+00:00 - - - Keagan McClelland 2021-12-31 03:10:48+00:00 - - - Michael Folkson 2021-10-16 11:02:08+00:00 - - - micaroni at gmail.com 2021-10-15 00:43:40+00:00 - - - Anthony Towns 2021-10-14 23:52:07+00:00 - - - Jorge Timón 2021-10-12 19:04:02+00:00 - - - ZmnSCPxj 2021-10-11 19:53:39+00:00 - - - Jeremy 2021-10-11 19:12:58+00:00 - - - Prayank 2021-10-11 16:03:16+00:00 - - - Michael Folkson 2021-10-11 12:24:10+00:00 - + 2025-09-26T16:03:29.289977+00:00 + python-feedgen + + + [bitcoin-dev] On the regularity of soft forks Michael Folkson + 2021-10-11T12:24:00.000Z + + + Prayank + 2021-10-11T16:03:00.000Z + + + Jeremy + 2021-10-11T19:12:00.000Z + + + ZmnSCPxj + 2021-10-11T19:53:00.000Z + + + Jorge Timón + 2021-10-12T19:04:00.000Z + + + Anthony Towns + 2021-10-14T23:52:00.000Z + + + micaroni + 2021-10-15T00:43:00.000Z + + + Michael Folkson + 2021-10-16T11:02:00.000Z + + + Keagan McClelland + 2021-12-31T03:10:00.000Z + + @@ -55,13 +55,13 @@ - python-feedgen + 2 Combined summary - On the regularity of soft forks - 2023-08-02T04:54:30.049777+00:00 + 2025-09-26T16:03:29.291115+00:00 - Miner signaling is a tool used to indicate readiness for a soft fork, but it should not be seen as a form of voting or expressing support for the fork. This distinction is crucial in order to avoid confusion and misinterpretation by users. The signaling process for taproot, for example, caused confusion among different communities as many believed that miners were actually voting for taproot. To address this issue, there needs to be sufficient community consensus before enabling miner signaling.Prayank, the author of the article, acknowledges that despite sharing a link to clarify the matter, there are still people who hold the misconception that miners vote during signaling. This confusion is further fueled by the differing opinions of developers on MASF (Miner Activated Soft Fork) versus UASF (User Activated Soft Fork). Finding a solution to this problem is a concern for Prayank.The author argues against frequent soft forks with only a single or minimal set of features, advocating instead for infrequent soft forks that include batches of features. The primary focus should be on ensuring the robustness, security, and resistance to harmful or suboptimal changes within the system. Soft fork code should not be merged into a Bitcoin implementation until there is sufficient community consensus on the entirety of that soft fork.In situations where there is no overwhelming community consensus on the activation method, activation parameters, and what to do if the initial attempt fails, the activation of soft forks carries additional risks. These risks include the potential for bugs, consensus divergences, and flawed implementations of soft fork features. Therefore, infrequent soft forks with batches of features are favored over frequent soft forks with only a single feature.Overall, the article emphasizes the need for clear communication and understanding regarding miner signaling, as well as the importance of community consensus in the implementation of soft forks. It also highlights the benefits of infrequent soft forks with multiple features in order to prioritize the security and stability of the Bitcoin system. 2022-01-19T02:26:12+00:00 + Miner signaling is a tool used to indicate readiness for a soft fork, but it should not be seen as a form of voting or expressing support for the fork. This distinction is crucial in order to avoid confusion and misinterpretation by users. The signaling process for taproot, for example, caused confusion among different communities as many believed that miners were actually voting for taproot. To address this issue, there needs to be sufficient community consensus before enabling miner signaling.Prayank, the author of the article, acknowledges that despite sharing a link to clarify the matter, there are still people who hold the misconception that miners vote during signaling. This confusion is further fueled by the differing opinions of developers on MASF (Miner Activated Soft Fork) versus UASF (User Activated Soft Fork). Finding a solution to this problem is a concern for Prayank.The author argues against frequent soft forks with only a single or minimal set of features, advocating instead for infrequent soft forks that include batches of features. The primary focus should be on ensuring the robustness, security, and resistance to harmful or suboptimal changes within the system. Soft fork code should not be merged into a Bitcoin implementation until there is sufficient community consensus on the entirety of that soft fork.In situations where there is no overwhelming community consensus on the activation method, activation parameters, and what to do if the initial attempt fails, the activation of soft forks carries additional risks. These risks include the potential for bugs, consensus divergences, and flawed implementations of soft fork features. Therefore, infrequent soft forks with batches of features are favored over frequent soft forks with only a single feature.Overall, the article emphasizes the need for clear communication and understanding regarding miner signaling, as well as the importance of community consensus in the implementation of soft forks. It also highlights the benefits of infrequent soft forks with multiple features in order to prioritize the security and stability of the Bitcoin system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Proposal-Package-Mempool-Accept-and-Package-RBF.xml b/static/bitcoin-dev/Oct_2021/combined_Proposal-Package-Mempool-Accept-and-Package-RBF.xml index ebf13d82f1..e469f788a4 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Proposal-Package-Mempool-Accept-and-Package-RBF.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Proposal-Package-Mempool-Accept-and-Package-RBF.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Proposal: Package Mempool Accept and Package RBF - 2023-08-02T04:48:13.719007+00:00 - - darosior 2021-10-14 10:48:55+00:00 - - - Gloria Zhao 2021-09-29 11:56:24+00:00 - - - Antoine Riard 2021-09-28 22:59:11+00:00 - - - Bastien TEINTURIER 2021-09-27 07:15:18+00:00 - - - Antoine Riard 2021-09-26 21:10:14+00:00 - - - Gloria Zhao 2021-09-23 15:36:02+00:00 - - - Antoine Riard 2021-09-23 04:29:39+00:00 - - - Gloria Zhao 2021-09-22 13:26:14+00:00 - - - Bastien TEINTURIER 2021-09-22 07:10:38+00:00 - - - Gloria Zhao 2021-09-21 16:42:33+00:00 - - - Bastien TEINTURIER 2021-09-21 15:18:28+00:00 - - - Gloria Zhao 2021-09-21 11:18:31+00:00 - - - Gloria Zhao 2021-09-20 15:10:14+00:00 - - - Bastien TEINTURIER 2021-09-20 09:19:38+00:00 - - - Antoine Riard 2021-09-19 23:16:45+00:00 - - - Gloria Zhao 2021-09-16 07:51:25+00:00 - + 2025-09-26T16:03:44.164279+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Package Mempool Accept and Package RBF Gloria Zhao + 2021-09-16T07:51:00.000Z + + + Antoine Riard + 2021-09-19T23:16:00.000Z + + + Bastien TEINTURIER + 2021-09-20T09:19:00.000Z + + + Gloria Zhao + 2021-09-20T15:10:00.000Z + + + Gloria Zhao + 2021-09-21T11:18:00.000Z + + + Bastien TEINTURIER + 2021-09-21T15:18:00.000Z + + + Gloria Zhao + 2021-09-21T16:42:00.000Z + + + Bastien TEINTURIER + 2021-09-22T07:10:00.000Z + + + Gloria Zhao + 2021-09-22T13:26:00.000Z + + + Antoine Riard + 2021-09-23T04:29:00.000Z + + + Gloria Zhao + 2021-09-23T15:36:00.000Z + + + Antoine Riard + 2021-09-26T21:10:00.000Z + + + Bastien TEINTURIER + 2021-09-27T07:15:00.000Z + + + Antoine Riard + 2021-09-28T22:59:00.000Z + + + Gloria Zhao + 2021-09-29T11:56:00.000Z + + + darosior + 2021-10-14T10:48:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - Proposal: Package Mempool Accept and Package RBF - 2023-08-02T04:48:13.719007+00:00 + 2025-09-26T16:03:44.166047+00:00 - The email thread on the bitcoin-dev mailing list discusses various aspects of the proposed package relay for Bitcoin Core. The discussions revolve around package acceptance rules, deduplication, and topologies. There is a debate on the logical order of the proposed checks and whether only the package RBF should apply. The limitations on topology are also discussed, with some suggesting a conservative approach of deploying during a first phase of 1-parent/1-child.Gloria Zhao and Antoine Riard discuss the proposed implementation of package relay for Bitcoin. They cover topics such as the removal of transactions already in the mempool during package submission, evaluation of fee rates for packages, and how replacements will work. They also discuss potential issues with multi-parent-1-child packages and their use in fee-bumping replaceable transactions. They mention the possibility of implementing a "witness replacement" project alongside package mempool acceptance.There is a discussion about the rules for Package Replace-by-Fee (RBF) in Bitcoin. The proposal includes conditions such as having a higher ancestor score than the original transactions, not including new unconfirmed inputs unless they were included in the original transactions, and having a total fee higher than the replaced transactions. The package feerate must be higher than the replaced transactions by at least the minimum relay feerate, and the package cannot replace more than 100 mempool transactions.The conversations aim to improve the efficiency and security of Bitcoin's mempool. There are concerns about Lightning developers who may not be aware of mempool subtleties and suggestions to constrain L2 design space using a 1-parent + 1-child model. The discussions cover various scenarios, including batched fee-bumping, mempool conflicts, and multi-commitment-broadcast-as-one-package. The goal is to make fee-bumping tools more powerful for users while maintaining transaction safety.There are proposals for changes to Bitcoin Core's mempool policy to enable package validation for package relay. The proposed policy allows for packages with multiple parents and one child to be validated together, improving fee-bumping tools for time-sensitive transactions. The proposal also introduces the concept of Package Mempool Accept, which includes changes to mempool validation logic, policy, and transaction relay to propagate transactions with the highest package feerates to miners.The discussions also touch on potential risks and safety concerns related to package acceptance and replacements. Concerns are raised about CPFP batching for Lightning Network time-sensitive closure and the possibility of malicious transactions delaying transaction propagation and confirmation within the same package. There is a focus on ensuring better utilization of block space while maintaining transaction safety.Overall, these discussions aim to enhance the transaction process in the Bitcoin network by optimizing validation, propagation, and fee-bumping tools. The proposals and debates explore various aspects of package acceptance, replacement-by-fee rules, and topology limitations. The goal is to improve efficiency, security, and flexibility for users and applications like Lightning.The Bitcoin Core development team has proposed a new system called package relay to improve transaction validation and propagation. This system allows for the creation of packages consisting of multiple parents and one child, which aids in fee estimations and transaction relay. The proposal introduces package feerate, which considers modified fees and virtual size of all transactions in the package. It also sets limitations on fee-bumping to prevent DoS vectors and ensures that replacement transactions have an ancestor score at least as high as the original ones. The package relay system has implications for Lightning Network (LN) requirements and other Layer 2 protocols/applications. It is suggested to deploy it in a phased manner to improve second-layer safety. The proposed system enables CPFP within packages and provides fee-bumping tools for users. To test the submission logic, Package Mempool Accept initially uses RPC. Fee-related checks use the package feerate, and parents can replace mempool transactions, but the child cannot. The bitcoin-dev mailing list has discussed the proposal, exploring differences from BIP125 and addressing potential scenarios and FAQs.Overall, the package relay system aims to improve package validation and relay in Bitcoin Core without requiring consensus or P2P protocol changes. It allows for better propagation of high-feerate transactions, more powerful fee-bumping tools for users, and adjustments to fees at broadcast time for Layer 2 applications. The proposed changes include modifications to mempool policy, allowing for packages with multiple parents and one child, and using the total package feerate instead of individual feerates. The author provides a draft implementation of the proposal and clarifies terminology and existing rules. However, there are limitations, such as the package not being able to replace more than 100 mempool transactions and not being able to contain already-confirmed transactions. 2021-10-14T10:48:55+00:00 + The email thread on the bitcoin-dev mailing list discusses various aspects of the proposed package relay for Bitcoin Core. The discussions revolve around package acceptance rules, deduplication, and topologies. There is a debate on the logical order of the proposed checks and whether only the package RBF should apply. The limitations on topology are also discussed, with some suggesting a conservative approach of deploying during a first phase of 1-parent/1-child.Gloria Zhao and Antoine Riard discuss the proposed implementation of package relay for Bitcoin. They cover topics such as the removal of transactions already in the mempool during package submission, evaluation of fee rates for packages, and how replacements will work. They also discuss potential issues with multi-parent-1-child packages and their use in fee-bumping replaceable transactions. They mention the possibility of implementing a "witness replacement" project alongside package mempool acceptance.There is a discussion about the rules for Package Replace-by-Fee (RBF) in Bitcoin. The proposal includes conditions such as having a higher ancestor score than the original transactions, not including new unconfirmed inputs unless they were included in the original transactions, and having a total fee higher than the replaced transactions. The package feerate must be higher than the replaced transactions by at least the minimum relay feerate, and the package cannot replace more than 100 mempool transactions.The conversations aim to improve the efficiency and security of Bitcoin's mempool. There are concerns about Lightning developers who may not be aware of mempool subtleties and suggestions to constrain L2 design space using a 1-parent + 1-child model. The discussions cover various scenarios, including batched fee-bumping, mempool conflicts, and multi-commitment-broadcast-as-one-package. The goal is to make fee-bumping tools more powerful for users while maintaining transaction safety.There are proposals for changes to Bitcoin Core's mempool policy to enable package validation for package relay. The proposed policy allows for packages with multiple parents and one child to be validated together, improving fee-bumping tools for time-sensitive transactions. The proposal also introduces the concept of Package Mempool Accept, which includes changes to mempool validation logic, policy, and transaction relay to propagate transactions with the highest package feerates to miners.The discussions also touch on potential risks and safety concerns related to package acceptance and replacements. Concerns are raised about CPFP batching for Lightning Network time-sensitive closure and the possibility of malicious transactions delaying transaction propagation and confirmation within the same package. There is a focus on ensuring better utilization of block space while maintaining transaction safety.Overall, these discussions aim to enhance the transaction process in the Bitcoin network by optimizing validation, propagation, and fee-bumping tools. The proposals and debates explore various aspects of package acceptance, replacement-by-fee rules, and topology limitations. The goal is to improve efficiency, security, and flexibility for users and applications like Lightning.The Bitcoin Core development team has proposed a new system called package relay to improve transaction validation and propagation. This system allows for the creation of packages consisting of multiple parents and one child, which aids in fee estimations and transaction relay. The proposal introduces package feerate, which considers modified fees and virtual size of all transactions in the package. It also sets limitations on fee-bumping to prevent DoS vectors and ensures that replacement transactions have an ancestor score at least as high as the original ones. The package relay system has implications for Lightning Network (LN) requirements and other Layer 2 protocols/applications. It is suggested to deploy it in a phased manner to improve second-layer safety. The proposed system enables CPFP within packages and provides fee-bumping tools for users. To test the submission logic, Package Mempool Accept initially uses RPC. Fee-related checks use the package feerate, and parents can replace mempool transactions, but the child cannot. The bitcoin-dev mailing list has discussed the proposal, exploring differences from BIP125 and addressing potential scenarios and FAQs.Overall, the package relay system aims to improve package validation and relay in Bitcoin Core without requiring consensus or P2P protocol changes. It allows for better propagation of high-feerate transactions, more powerful fee-bumping tools for users, and adjustments to fees at broadcast time for Layer 2 applications. The proposed changes include modifications to mempool policy, allowing for packages with multiple parents and one child, and using the total package feerate instead of individual feerates. The author provides a draft implementation of the proposal and clarifies terminology and existing rules. However, there are limitations, such as the package not being able to replace more than 100 mempool transactions and not being able to contain already-confirmed transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Question-must-every-mining-rig-attempt-every-block-.xml b/static/bitcoin-dev/Oct_2021/combined_Question-must-every-mining-rig-attempt-every-block-.xml index 31ac5e44a0..6428b39c40 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Question-must-every-mining-rig-attempt-every-block-.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Question-must-every-mining-rig-attempt-every-block-.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - Question- must every mining rig attempt every block? - 2023-08-02T04:53:31.022190+00:00 - - Billy Tetrud 2021-10-08 15:08:02+00:00 - - - Ruben Somsen 2021-10-05 14:42:40+00:00 - - - ZmnSCPxj 2021-10-05 14:41:24+00:00 - - - Nathan T Alexander 2021-10-05 12:23:09+00:00 - + 2025-09-26T16:03:50.468495+00:00 + python-feedgen + + + [bitcoin-dev] Question- must every mining rig attempt every block? Nathan T Alexander + 2021-10-05T12:23:00.000Z + + + ZmnSCPxj + 2021-10-05T14:41:00.000Z + + + Ruben Somsen + 2021-10-05T14:42:00.000Z + + + Billy Tetrud + 2021-10-08T15:08:00.000Z + + - python-feedgen + 2 Combined summary - Question- must every mining rig attempt every block? - 2023-08-02T04:53:31.022190+00:00 + 2025-09-26T16:03:50.469159+00:00 - Proof of stake systems aim to create non-gameable attributes using red light-green light mechanisms. However, proof of identity cannot be implemented in a decentralized adversarial environment. The Proof of Work consensus mechanism addresses the Sybil issue by making mining completely random. Hybrid systems that combine proof of work and proof of stake exist but are not very effective. "Green mining" is unlikely to be seriously considered for Bitcoin, as discussions on the topic have already taken place on Bitcoin Stack Exchange and Bitcoin-dev mailing list.In response to Nathan's question about conserving energy in Bitcoin mining, Ruben suggests that there have been previous discussions on "green mining" and provides links to a thread on Bitcoin-dev from May 2021 and Bitcoin Stack Exchange. However, Ruben notes that these discussions are unlikely to result in serious consideration for Bitcoin. Nathan proposes using a non-gameable attribute of each mining rig to calculate whether a block would be accepted by that rig, potentially reducing energy consumption. He suggests using the bitcoin network ID as this attribute, creating a green light/red light system. Ruben does not provide further comment on Nathan's proposal.The conversation discusses the idea of conserving energy in Bitcoin mining. Nathan proposes incorporating a non-gameable attribute into each mining rig to determine if a block will be accepted. However, it is pointed out that miners can game the system by grinding on which of their multiple addresses gets the green light. Identifying miners reduces anonymity, and miners use multiple addresses as protection against state co-option. It is suggested to hash data from the last successful block along with the miner's attribute and if it falls below a certain number set by an algorithm, the miner gets a green light to produce a valid block. However, reducing power consumption makes it easier for states to purchase and co-opt mines, posing a threat to the security of the system. Therefore, power consumption is an important security parameter in Bitcoin mining.In summary, Nathan proposes a method to conserve energy in Bitcoin mining by incorporating a non-gameable attribute into each mining rig. This attribute would be used to determine if a block will be accepted by the rig, creating a green light/red light system. However, there are concerns about miners gaming the system and the potential impact on anonymity and security. Power consumption is seen as an important security parameter in the Bitcoin network. 2021-10-08T15:08:02+00:00 + Proof of stake systems aim to create non-gameable attributes using red light-green light mechanisms. However, proof of identity cannot be implemented in a decentralized adversarial environment. The Proof of Work consensus mechanism addresses the Sybil issue by making mining completely random. Hybrid systems that combine proof of work and proof of stake exist but are not very effective. "Green mining" is unlikely to be seriously considered for Bitcoin, as discussions on the topic have already taken place on Bitcoin Stack Exchange and Bitcoin-dev mailing list.In response to Nathan's question about conserving energy in Bitcoin mining, Ruben suggests that there have been previous discussions on "green mining" and provides links to a thread on Bitcoin-dev from May 2021 and Bitcoin Stack Exchange. However, Ruben notes that these discussions are unlikely to result in serious consideration for Bitcoin. Nathan proposes using a non-gameable attribute of each mining rig to calculate whether a block would be accepted by that rig, potentially reducing energy consumption. He suggests using the bitcoin network ID as this attribute, creating a green light/red light system. Ruben does not provide further comment on Nathan's proposal.The conversation discusses the idea of conserving energy in Bitcoin mining. Nathan proposes incorporating a non-gameable attribute into each mining rig to determine if a block will be accepted. However, it is pointed out that miners can game the system by grinding on which of their multiple addresses gets the green light. Identifying miners reduces anonymity, and miners use multiple addresses as protection against state co-option. It is suggested to hash data from the last successful block along with the miner's attribute and if it falls below a certain number set by an algorithm, the miner gets a green light to produce a valid block. However, reducing power consumption makes it easier for states to purchase and co-opt mines, posing a threat to the security of the system. Therefore, power consumption is an important security parameter in Bitcoin mining.In summary, Nathan proposes a method to conserve energy in Bitcoin mining by incorporating a non-gameable attribute into each mining rig. This attribute would be used to determine if a block will be accepted by the rig, creating a green light/red light system. However, there are concerns about miners gaming the system and the potential impact on anonymity and security. Power consumption is seen as an important security parameter in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Removing-the-Dust-Limit.xml b/static/bitcoin-dev/Oct_2021/combined_Removing-the-Dust-Limit.xml index 4cbc05258f..744efd78d2 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Removing-the-Dust-Limit.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Removing-the-Dust-Limit.xml @@ -1,119 +1,151 @@ - + 2 Combined summary - Removing the Dust Limit - 2023-08-02T04:31:39.825006+00:00 - - vjudeu at gazeta.pl 2022-03-12 13:02:24+00:00 - - - ZmnSCPxj 2021-10-08 22:47:11+00:00 - - - ZmnSCPxj 2021-10-08 10:38:50+00:00 - - - shymaa arafat 2021-10-08 07:44:59+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 10:35:16+00:00 - - - ZmnSCPxj 2021-10-07 10:01:53+00:00 - - - shymaa arafat 2021-10-07 09:13:33+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 08:34:17+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 08:17:40+00:00 - - - ZmnSCPxj 2021-10-07 04:52:01+00:00 - - - Erik Aronesty 2021-10-01 13:40:06+00:00 - - - Pieter Wuille 2021-09-30 22:07:08+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-08-30 03:31:56+00:00 - - - shymaa arafat 2021-08-27 09:07:35+00:00 - - - Billy Tetrud 2021-08-26 21:21:25+00:00 - - - ZmnSCPxj 2021-08-21 03:10:46+00:00 - - - shymaa arafat 2021-08-20 05:45:31+00:00 - - - Jeremy 2021-08-20 04:51:31+00:00 - - - shymaa arafat 2021-08-18 19:06:30+00:00 - - - Anthony Towns 2021-08-12 22:03:39+00:00 - - - ZmnSCPxj 2021-08-11 00:46:36+00:00 - - - Antoine Riard 2021-08-10 22:37:48+00:00 - - - Charlie Lee 2021-08-10 18:39:39+00:00 - - - ZmnSCPxj 2021-08-10 11:37:37+00:00 - - - David A. Harding 2021-08-10 06:14:41+00:00 - - - Billy Tetrud 2021-08-10 05:44:04+00:00 - - - Jeremy 2021-08-10 05:04:07+00:00 - - - Billy Tetrud 2021-08-10 00:30:02+00:00 - - - Antoine Riard 2021-08-09 13:22:28+00:00 - - - Karl 2021-08-09 11:58:03+00:00 - - - Prayank 2021-08-09 10:25:50+00:00 - - - Jeremy 2021-08-08 23:07:27+00:00 - - - Jeremy 2021-08-08 22:46:26+00:00 - - - David A. Harding 2021-08-08 21:51:01+00:00 - - - Oleg Andreev 2021-08-08 21:41:32+00:00 - - - Matt Corallo 2021-08-08 21:14:23+00:00 - - - Jeremy 2021-08-08 18:52:55+00:00 - + 2025-09-26T16:03:39.859495+00:00 + python-feedgen + + + [bitcoin-dev] Removing the Dust Limit Jeremy + 2021-08-08T18:52:00.000Z + + + Matt Corallo + 2021-08-08T21:14:00.000Z + + + Oleg Andreev + 2021-08-08T21:41:00.000Z + + + [bitcoin-dev] [Lightning-dev] " David A. Harding + 2021-08-08T21:51:00.000Z + + + Jeremy + 2021-08-08T22:46:00.000Z + + + Jeremy + 2021-08-08T23:07:00.000Z + + + [bitcoin-dev] " Prayank + 2021-08-09T10:25:00.000Z + + + Karl + 2021-08-09T11:58:00.000Z + + + Antoine Riard + 2021-08-09T13:22:00.000Z + + + Billy Tetrud + 2021-08-10T00:30:00.000Z + + + Jeremy + 2021-08-10T05:04:00.000Z + + + Billy Tetrud + 2021-08-10T05:44:00.000Z + + + David A. Harding + 2021-08-10T06:14:00.000Z + + + ZmnSCPxj + 2021-08-10T11:37:00.000Z + + + Charlie Lee + 2021-08-10T18:39:00.000Z + + + Antoine Riard + 2021-08-10T22:37:00.000Z + + + ZmnSCPxj + 2021-08-11T00:46:00.000Z + + + Anthony Towns + 2021-08-12T22:03:00.000Z + + + Jeremy + 2021-08-20T04:51:00.000Z + + + shymaa arafat + 2021-08-20T05:45:00.000Z + + + ZmnSCPxj + 2021-08-21T03:10:00.000Z + + + Billy Tetrud + 2021-08-26T21:21:00.000Z + + + shymaa arafat + 2021-08-27T09:07:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-08-30T03:31:00.000Z + + + Pieter Wuille + 2021-09-30T22:07:00.000Z + + + Erik Aronesty + 2021-10-01T13:40:00.000Z + + + ZmnSCPxj + 2021-10-07T04:52:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T08:17:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T08:34:00.000Z + + + shymaa arafat + 2021-10-07T09:13:00.000Z + + + ZmnSCPxj + 2021-10-07T10:01:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T10:35:00.000Z + + + shymaa arafat + 2021-10-08T07:44:00.000Z + + + ZmnSCPxj + 2021-10-08T10:38:00.000Z + + + ZmnSCPxj + 2021-10-08T22:47:00.000Z + + @@ -151,13 +183,13 @@ - python-feedgen + 2 Combined summary - Removing the Dust Limit - 2023-08-02T04:31:39.825967+00:00 + 2025-09-26T16:03:39.862987+00:00 - Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees. However, this short-term incentive is countered by concerns about spam and dust fingerprinting attacks.In conclusion, 2022-03-12T13:02:24+00:00 + Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees. However, this short-term incentive is countered by concerns about spam and dust fingerprinting attacks.In conclusion, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Reorgs-on-SigNet-Looking-for-feedback-on-approach-and-parameters.xml b/static/bitcoin-dev/Oct_2021/combined_Reorgs-on-SigNet-Looking-for-feedback-on-approach-and-parameters.xml index 7f0aac5832..909fa0f3f3 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Reorgs-on-SigNet-Looking-for-feedback-on-approach-and-parameters.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Reorgs-on-SigNet-Looking-for-feedback-on-approach-and-parameters.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Reorgs on SigNet - Looking for feedback on approach and parameters - 2023-08-02T04:41:16.248558+00:00 - - Anthony Towns 2021-10-15 04:41:50+00:00 - - - Matt Corallo 2021-09-15 15:24:43+00:00 - - - Anthony Towns 2021-09-14 04:56:10+00:00 - - - Matt Corallo 2021-09-13 16:24:29+00:00 - - - Michael Folkson 2021-09-13 12:30:31+00:00 - - - Matt Corallo 2021-09-13 05:33:24+00:00 - - - Greg Sanders 2021-09-12 14:54:33+00:00 - - - vjudeu at gazeta.pl 2021-09-12 14:29:08+00:00 - - - Anthony Towns 2021-09-12 07:53:05+00:00 - - - David A. Harding 2021-09-10 20:00:05+00:00 - - - Matt Corallo 2021-09-10 19:22:00+00:00 - - - Michael Folkson 2021-09-10 19:00:39+00:00 - - - Matt Corallo 2021-09-10 18:24:15+00:00 - - - Michael Folkson 2021-09-10 13:05:40+00:00 - - - Matt Corallo 2021-09-10 00:50:08+00:00 - - - Anthony Towns 2021-09-08 07:59:04+00:00 - - - Jeremy 2021-09-07 16:44:17+00:00 - - - 0xB10C 2021-09-07 16:07:47+00:00 - + 2025-09-26T16:03:48.376491+00:00 + python-feedgen + + + [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters 0xB10C + 2021-09-07T16:07:00.000Z + + + Jeremy + 2021-09-07T16:44:00.000Z + + + Anthony Towns + 2021-09-08T07:59:00.000Z + + + Matt Corallo + 2021-09-10T00:50:00.000Z + + + Michael Folkson + 2021-09-10T13:05:00.000Z + + + Matt Corallo + 2021-09-10T18:24:00.000Z + + + Michael Folkson + 2021-09-10T19:00:00.000Z + + + Matt Corallo + 2021-09-10T19:22:00.000Z + + + David A. Harding + 2021-09-10T20:00:00.000Z + + + Anthony Towns + 2021-09-12T07:53:00.000Z + + + vjudeu + 2021-09-12T14:29:00.000Z + + + Greg Sanders + 2021-09-12T14:54:00.000Z + + + Matt Corallo + 2021-09-13T05:33:00.000Z + + + Michael Folkson + 2021-09-13T12:30:00.000Z + + + Matt Corallo + 2021-09-13T16:24:00.000Z + + + Anthony Towns + 2021-09-14T04:56:00.000Z + + + Matt Corallo + 2021-09-15T15:24:00.000Z + + + Anthony Towns + 2021-10-15T04:41:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Reorgs on SigNet - Looking for feedback on approach and parameters - 2023-08-02T04:41:16.249560+00:00 + 2025-09-26T16:03:48.378436+00:00 - The discussion on the Bitcoin Signet revolved around simplifying testing and addressing re-org behavior. The aim of Signet is to replicate mainnet as closely as possible, allowing software to use it without modification. However, there were suggestions for improving the simulation of mainnet behavior.One proposal suggested having existing block producers generate new keys and only sign reorgs with those keys. This would give users the option to accept signatures from both sets of keys or only non-reorg keys, providing a more reliable simulation of mainnet behavior. Importantly, this suggestion wouldn't require users to sign blocks themselves.There was a debate about the frequency of reorgs on the default Signet. Some argued for more regular reorgs (e.g., every 8 hours) to test applications' ability to withstand different flavors of re-orgs. Others believed that making reorgs too frequent would deviate significantly from mainnet behavior and recommended testing normal mainnet behavior before focusing on reorgs.Another proposal was to introduce a version bit for blocks, requiring users to sign blocks. However, the added complexity of this approach was questioned, as the default Signet currently leaves block signing to network block signers. It was suggested that a flag set via a configuration argument could be used instead, with no-reorgs or 8-hour re-orgs as the default.To further resemble mainnet, the random generation of batches of transactions to fill up blocks and create a fee market was proposed. This would facilitate testing features like RBF and Lightning unhappy paths on the default Signet in the future.The discussions also explored various aspects related to reorgs on Signet. One proposal suggested using a version bit flag for blocks that won't end up in the most work chain, giving users the choice to opt-out of reorgs. The frequency and depth of reorgs were debated, with suggestions for frequent reorgs (e.g., every block) or less frequent ones (e.g., once per week). The depth of reorgs was considered, with different depths serving different testing purposes. It was proposed that the depth of reorgs be deterministically random within a minimum and maximum range based on block hash or nonce.Two scenarios were suggested for testing reorg handling: a race between two chains and a chain rollback scenario. Questions arose regarding the frequency of reorgs on the default Signet and how engineers currently test their applications' reorg handling.Developers sought feedback on implementing support for planned chain reorganizations in Signet. Two scenarios were proposed: races between chains and chain rollbacks. Users would have the option to opt-out of reorgs by setting a version bit flag on affected blocks. The frequency and depth of reorgs would depend on user needs, considering users across different time zones. The first step would be to implement the race scenario and set up a public test-Signet. If there is interest, chain rollbacks could be implemented, and conflicting transactions could be included in the branches.Overall, the discussions aimed to find the best approach to simulate mainnet behavior while providing an easy testing environment for applications. Feedback from developers and users was crucial in determining the optimal parameters for reorgs and ensuring a reliable testing environment for Bitcoin developers. 2021-10-15T04:41:50+00:00 + The discussion on the Bitcoin Signet revolved around simplifying testing and addressing re-org behavior. The aim of Signet is to replicate mainnet as closely as possible, allowing software to use it without modification. However, there were suggestions for improving the simulation of mainnet behavior.One proposal suggested having existing block producers generate new keys and only sign reorgs with those keys. This would give users the option to accept signatures from both sets of keys or only non-reorg keys, providing a more reliable simulation of mainnet behavior. Importantly, this suggestion wouldn't require users to sign blocks themselves.There was a debate about the frequency of reorgs on the default Signet. Some argued for more regular reorgs (e.g., every 8 hours) to test applications' ability to withstand different flavors of re-orgs. Others believed that making reorgs too frequent would deviate significantly from mainnet behavior and recommended testing normal mainnet behavior before focusing on reorgs.Another proposal was to introduce a version bit for blocks, requiring users to sign blocks. However, the added complexity of this approach was questioned, as the default Signet currently leaves block signing to network block signers. It was suggested that a flag set via a configuration argument could be used instead, with no-reorgs or 8-hour re-orgs as the default.To further resemble mainnet, the random generation of batches of transactions to fill up blocks and create a fee market was proposed. This would facilitate testing features like RBF and Lightning unhappy paths on the default Signet in the future.The discussions also explored various aspects related to reorgs on Signet. One proposal suggested using a version bit flag for blocks that won't end up in the most work chain, giving users the choice to opt-out of reorgs. The frequency and depth of reorgs were debated, with suggestions for frequent reorgs (e.g., every block) or less frequent ones (e.g., once per week). The depth of reorgs was considered, with different depths serving different testing purposes. It was proposed that the depth of reorgs be deterministically random within a minimum and maximum range based on block hash or nonce.Two scenarios were suggested for testing reorg handling: a race between two chains and a chain rollback scenario. Questions arose regarding the frequency of reorgs on the default Signet and how engineers currently test their applications' reorg handling.Developers sought feedback on implementing support for planned chain reorganizations in Signet. Two scenarios were proposed: races between chains and chain rollbacks. Users would have the option to opt-out of reorgs by setting a version bit flag on affected blocks. The frequency and depth of reorgs would depend on user needs, considering users across different time zones. The first step would be to implement the race scenario and set up a public test-Signet. If there is interest, chain rollbacks could be implemented, and conflicting transactions could be included in the branches.Overall, the discussions aimed to find the best approach to simulate mainnet behavior while providing an easy testing environment for applications. Feedback from developers and users was crucial in determining the optimal parameters for reorgs and ensuring a reliable testing environment for Bitcoin developers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml b/static/bitcoin-dev/Oct_2021/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml index 1c6cc48fb4..2776762484 100644 --- a/static/bitcoin-dev/Oct_2021/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml +++ b/static/bitcoin-dev/Oct_2021/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - TAPLEAF_UPDATE_VERIFY covenant opcode - 2023-08-02T04:43:31.285155+00:00 - - Tim Ruffing 2022-07-08 19:52:12+00:00 - - - Billy Tetrud 2021-10-29 15:47:12+00:00 - - - Olaoluwa Osuntokun 2021-09-23 00:29:18+00:00 - - - Antoine Riard 2021-09-22 01:40:16+00:00 - - - Anthony Towns 2021-09-20 14:52:46+00:00 - - - Antoine Riard 2021-09-18 14:11:10+00:00 - - - Anthony Towns 2021-09-15 06:50:51+00:00 - - - Antoine Riard 2021-09-12 23:37:56+00:00 - - - Anthony Towns 2021-09-11 03:26:44+00:00 - - - Anthony Towns 2021-09-10 07:42:19+00:00 - - - Antoine Riard 2021-09-10 04:12:24+00:00 - - - Jeremy 2021-09-09 19:26:37+00:00 - - - Jeremy 2021-09-09 15:54:25+00:00 - - - darosior 2021-09-09 12:56:10+00:00 - - - Matt Corallo 2021-09-09 09:16:12+00:00 - - - Anthony Towns 2021-09-09 06:53:30+00:00 - - - Anthony Towns 2021-09-09 06:41:38+00:00 - + 2025-09-26T16:03:54.734624+00:00 + python-feedgen + + + [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode Anthony Towns + 2021-09-09T06:41:00.000Z + + + Anthony Towns + 2021-09-09T06:53:00.000Z + + + Matt Corallo + 2021-09-09T09:16:00.000Z + + + darosior + 2021-09-09T12:56:00.000Z + + + Jeremy + 2021-09-09T15:54:00.000Z + + + Jeremy + 2021-09-09T19:26:00.000Z + + + Antoine Riard + 2021-09-10T04:12:00.000Z + + + Anthony Towns + 2021-09-10T07:42:00.000Z + + + Anthony Towns + 2021-09-11T03:26:00.000Z + + + Antoine Riard + 2021-09-12T23:37:00.000Z + + + Anthony Towns + 2021-09-15T06:50:00.000Z + + + Antoine Riard + 2021-09-18T14:11:00.000Z + + + Anthony Towns + 2021-09-20T14:52:00.000Z + + + Antoine Riard + 2021-09-22T01:40:00.000Z + + + Olaoluwa Osuntokun + 2021-09-23T00:29:00.000Z + + + Billy Tetrud + 2021-10-29T15:47:00.000Z + + + Tim Ruffing + 2022-07-08T19:52:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - TAPLEAF_UPDATE_VERIFY covenant opcode - 2023-08-02T04:43:31.285155+00:00 + 2025-09-26T16:03:54.736468+00:00 - In the context of Taproot and off-chain contract transactions, the conversation revolves around proposing new opcodes and discussing various optimizations and security concerns. One proposal is for a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV), which would allow for updating the internal public key, specifying a new step for the merkle path, and removing scripts or merkle path steps. The author suggests modifying the proposal to obtain the script from the annex, making it more powerful and allowing for dynamic script updates. This modification would require the addition of an OP_PUSH_ANNEX opcode.The discussion also touches on the issue of utxos interacting with each other and proposes the use of a fixed ID to identify contracts. This would allow transactions to spend/interact with a contract without needing to know the set of active utxos where that contract lives. Nodes would need to maintain an extra index into the UTXO set, but this can be alleviated with a utreexo-like solution.Another topic of discussion is the design and implementation of specific capabilities for off-chain contract transactions. Suggestions include splitting funds between multiple parties, selective withdrawals based on time or conditions, and using opcodes like IN_OUT_AMOUNT to specify authorized withdrawal ranges for hot wallets. Security concerns, such as replay attacks and trust in counterparty cooperation, are also addressed.The conversation explores different ways to optimize Taproot's smart contract capabilities while maintaining security and reliability. The MERKLESUB opcode is discussed, highlighting its ability to refer to non-corresponding outputs but lacking certain abilities like adding branches or preserving current scripts. Trade-offs and potential solutions are proposed, including extending the signature digest algorithm and introducing a new opcode.Overall, the participants show a deep understanding of the technical complexities involved in designing and implementing off-chain contract transactions. They discuss various proposals, optimizations, and security considerations to enhance the functionality and usability of Taproot and off-chain contracts on the Bitcoin network.Anthony Towns discusses Taproot and proposes splitting the discussion into two parts. The first part focuses on improving the functionality and efficiency of transactions using Taproot scripts. This involves updating a UTXO by changing the taproot tree using a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV). This enables the creation of more complex covenants that limit hot wallet withdrawals, protect funds with both hot and cold wallet keys, and verify that funds are being appropriately retained in the updated scriptPubKey.The second part of the discussion addresses more efficient and private one-in, one-out transactions within a pooled fund represented by a UTXO. However, this method requires everyone in the pool to be online to sign via the key path, which can limit the number of people who can reasonably be included in a pool before there's a breakdown. This enables joint funding of ventures, where participants put BTC into a pooled UTXO, ready to finalize the purchase of land while having the ability to reclaim their funds if the deal falls through.Despite these advantages, both proposals have limitations. The first proposal cannot tweak scripts in areas of the merkle tree that it cannot see, while the second proposal requires all members of the pool to be online to sign via the key path. Bitcoin developer AJ Towns believes that these limitations could be simulated with CAT and CHECKSIGFROMSTACK but introducing dedicated opcodes for this functionality would make the feature easier to use correctly and cheap and efficient for both wallets and nodes to validate.In addition to the discussion on Taproot, Anthony Towns also addresses other aspects related to Taproot implementation. He suggests upgrading ADD, SUB, and the comparison operators to support 64-bit values to resolve issues with complicated calculations. He also discusses TLUV, which controls how spending scripts can change between input sPK and output sPK, and proposes a script for implementing the release/locked/available vault construct. Furthermore, he explores the issue of TLUV's parity in taproot addresses and suggests various approaches to solve it.The context also mentions constructing hashes programmatically using "OP_CAT" or similar functionality, allowing for interesting behavior such as adding oneself to a pool if they contribute at least 10 BTC. However, using templates is necessary when constructing a new script programmatically to ensure efficiency. There is a caveat that people could bypass covenant constraints if allowed to add arbitrary opcodes.Towns further discusses the pooled scheme and updating the internal pubkey, which becomes complicated due to the use of 32-byte x-only pubkeys for the scriptPubKey and the internal public key. He provides an example scenario where removing a participant from the pool might result in switching the scriptPubKey, causing potential issues with key path spends.Overall, the context provides a detailed discussion of various aspects of Taproot and potential issues that may arise when constructing a new script programmatically. While Towns proposes solutions to these issues, there are still caveats to consider. The article concludes by suggesting that dedicated opcodes for this functionality would make 2022-07-08T19:52:12+00:00 + In the context of Taproot and off-chain contract transactions, the conversation revolves around proposing new opcodes and discussing various optimizations and security concerns. One proposal is for a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV), which would allow for updating the internal public key, specifying a new step for the merkle path, and removing scripts or merkle path steps. The author suggests modifying the proposal to obtain the script from the annex, making it more powerful and allowing for dynamic script updates. This modification would require the addition of an OP_PUSH_ANNEX opcode.The discussion also touches on the issue of utxos interacting with each other and proposes the use of a fixed ID to identify contracts. This would allow transactions to spend/interact with a contract without needing to know the set of active utxos where that contract lives. Nodes would need to maintain an extra index into the UTXO set, but this can be alleviated with a utreexo-like solution.Another topic of discussion is the design and implementation of specific capabilities for off-chain contract transactions. Suggestions include splitting funds between multiple parties, selective withdrawals based on time or conditions, and using opcodes like IN_OUT_AMOUNT to specify authorized withdrawal ranges for hot wallets. Security concerns, such as replay attacks and trust in counterparty cooperation, are also addressed.The conversation explores different ways to optimize Taproot's smart contract capabilities while maintaining security and reliability. The MERKLESUB opcode is discussed, highlighting its ability to refer to non-corresponding outputs but lacking certain abilities like adding branches or preserving current scripts. Trade-offs and potential solutions are proposed, including extending the signature digest algorithm and introducing a new opcode.Overall, the participants show a deep understanding of the technical complexities involved in designing and implementing off-chain contract transactions. They discuss various proposals, optimizations, and security considerations to enhance the functionality and usability of Taproot and off-chain contracts on the Bitcoin network.Anthony Towns discusses Taproot and proposes splitting the discussion into two parts. The first part focuses on improving the functionality and efficiency of transactions using Taproot scripts. This involves updating a UTXO by changing the taproot tree using a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV). This enables the creation of more complex covenants that limit hot wallet withdrawals, protect funds with both hot and cold wallet keys, and verify that funds are being appropriately retained in the updated scriptPubKey.The second part of the discussion addresses more efficient and private one-in, one-out transactions within a pooled fund represented by a UTXO. However, this method requires everyone in the pool to be online to sign via the key path, which can limit the number of people who can reasonably be included in a pool before there's a breakdown. This enables joint funding of ventures, where participants put BTC into a pooled UTXO, ready to finalize the purchase of land while having the ability to reclaim their funds if the deal falls through.Despite these advantages, both proposals have limitations. The first proposal cannot tweak scripts in areas of the merkle tree that it cannot see, while the second proposal requires all members of the pool to be online to sign via the key path. Bitcoin developer AJ Towns believes that these limitations could be simulated with CAT and CHECKSIGFROMSTACK but introducing dedicated opcodes for this functionality would make the feature easier to use correctly and cheap and efficient for both wallets and nodes to validate.In addition to the discussion on Taproot, Anthony Towns also addresses other aspects related to Taproot implementation. He suggests upgrading ADD, SUB, and the comparison operators to support 64-bit values to resolve issues with complicated calculations. He also discusses TLUV, which controls how spending scripts can change between input sPK and output sPK, and proposes a script for implementing the release/locked/available vault construct. Furthermore, he explores the issue of TLUV's parity in taproot addresses and suggests various approaches to solve it.The context also mentions constructing hashes programmatically using "OP_CAT" or similar functionality, allowing for interesting behavior such as adding oneself to a pool if they contribute at least 10 BTC. However, using templates is necessary when constructing a new script programmatically to ensure efficiency. There is a caveat that people could bypass covenant constraints if allowed to add arbitrary opcodes.Towns further discusses the pooled scheme and updating the internal pubkey, which becomes complicated due to the use of 32-byte x-only pubkeys for the scriptPubKey and the internal public key. He provides an example scenario where removing a participant from the pool might result in switching the scriptPubKey, causing potential issues with key path spends.Overall, the context provides a detailed discussion of various aspects of Taproot and potential issues that may arise when constructing a new script programmatically. While Towns proposes solutions to these issues, there are still caveats to consider. The article concludes by suggesting that dedicated opcodes for this functionality would make - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Taproot-testnet-wallet.xml b/static/bitcoin-dev/Oct_2021/combined_Taproot-testnet-wallet.xml index e173ef11fe..7254822c8b 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Taproot-testnet-wallet.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Taproot-testnet-wallet.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Taproot testnet wallet - 2023-08-02T04:53:55.510803+00:00 + 2025-09-26T16:03:52.583378+00:00 + python-feedgen Prayank 2021-10-15 14:12:23+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Taproot testnet wallet - 2023-08-02T04:53:55.510803+00:00 + 2025-09-26T16:03:52.583549+00:00 - The email discusses the implementation of Bitcoin's Taproot addresses in bitcoinj and the need for testing against a wallet that can receive to P2TR and spend back. The author shares a transaction they did days ago which creates a P2TR output and provides detailed steps taken for the transaction. They suggest adding test vectors in BIP 86 for TPRV as suggested by Anthony Towns in a previous email.On October 15th, 2021, Anthony Towns posted on the bitcoin-dev forum discussing whether any testnet faucets would accept bech32m addresses directly. Although unsure, he mentioned that the same process works with testnet. It is noted that there are faucets that accept such addresses, including Bitcoin Faucet, but they require the use of a bech32 checksum instead of bech32m.Bitcoin Core users can create a taproot-capable wallet following several steps. Firstly, they need to have or create a descriptor wallet with descriptors=true using the createwallet RPC command. Secondly, they should import a taproot descriptor in the form "tr(KEY)", where KEY can be a tprv.../* or any other supported key expression. Thirdly, they can get a new address with addresstype=bech32m. It is mentioned that this process is currently somewhat cumbersome, especially prior to taproot activating on mainnet.To create a taproot-capable wallet in Bitcoin Core using the master branch, there are five steps involved. First, users should create a descriptor wallet using the command 'bitcoin-cli -signet -named createwallet wallet_name=descwallet descriptors=true load_on_startup=true'. Second, they need to get the associated bip32 tprv private key using 'TPRV=$(bitcoin-cli -rpcwallet=descwallet -signet listdescriptors true | jq '.descriptors | .[].desc' | sed 's/^.*(//;s/[)/].*//' | uniq | head -n1)'. Note that this step requires an updated version of bitcoin-cli due to PR#21500. Third, users should construct the taproot descriptor per BIP 86 using 'DESC="tr($TPRV/86'/1'/0'/0/*)"' and 'CHK="$(bitcoin-cli -rpcwallet=descwallet -signet getdescriptorinfo "$DESC" | jq -r .checksum)"'. Fourth, import the descriptor using 'bitcoin-cli -rpcwallet=descwallet -signet importdescriptors "[{\"desc\": \"$DESC#$CHK\", \"active\": true, \"timestamp\": \"now\", \"range\": [0,1000], \"next_index\": 1}]"'. Finally, get an address using 'bitcoin-cli -rpcwallet=descwallet -signet getnewaddress '' bech32m'.Andreas Schildbach via bitcoin-dev is trying to finish off bitcoinj's implementation for sending to taproot addresses. They are requesting a testnet wallet that can receive to P2TR and spend back in order to complete this task. Despite their efforts, they have been unable to obtain a taproot address from Bitcoin Core 22.0. Pieter has responded to Andreas' request by providing instructions on how to construct a taproot-capable wallet in Bitcoin Core. This involves having or creating a descriptor wallet with descriptors=true, importing a taproot descriptor (of the form "tr(KEY)") as active descriptor with active=true, where KEY can be a tprv.../* or any other supported key expression, and getting a new address with addresstype=bech32m. Pieter has also provided a taproot address for testing purposes: tb1p84x2ryuyfevgnlpnxt9f39gm7r68gwtvllxqe5w2n5ru00s9aquslzggwq. If testnet coins are sent there, Pieter has requested an email address to return them.The individual working on implementing bitcoinj's sending feature for taproot addresses is requesting a testnet wallet that can receive to P2TR and spend back. They have been unable to obtain a taproot address from Bitcoin Core 22.0 and are seeking assistance. They do not care about the safety of their testnet coins, so there is no need to worry about compromised private keys. 2021-10-15T14:12:23+00:00 + The email discusses the implementation of Bitcoin's Taproot addresses in bitcoinj and the need for testing against a wallet that can receive to P2TR and spend back. The author shares a transaction they did days ago which creates a P2TR output and provides detailed steps taken for the transaction. They suggest adding test vectors in BIP 86 for TPRV as suggested by Anthony Towns in a previous email.On October 15th, 2021, Anthony Towns posted on the bitcoin-dev forum discussing whether any testnet faucets would accept bech32m addresses directly. Although unsure, he mentioned that the same process works with testnet. It is noted that there are faucets that accept such addresses, including Bitcoin Faucet, but they require the use of a bech32 checksum instead of bech32m.Bitcoin Core users can create a taproot-capable wallet following several steps. Firstly, they need to have or create a descriptor wallet with descriptors=true using the createwallet RPC command. Secondly, they should import a taproot descriptor in the form "tr(KEY)", where KEY can be a tprv.../* or any other supported key expression. Thirdly, they can get a new address with addresstype=bech32m. It is mentioned that this process is currently somewhat cumbersome, especially prior to taproot activating on mainnet.To create a taproot-capable wallet in Bitcoin Core using the master branch, there are five steps involved. First, users should create a descriptor wallet using the command 'bitcoin-cli -signet -named createwallet wallet_name=descwallet descriptors=true load_on_startup=true'. Second, they need to get the associated bip32 tprv private key using 'TPRV=$(bitcoin-cli -rpcwallet=descwallet -signet listdescriptors true | jq '.descriptors | .[].desc' | sed 's/^.*(//;s/[)/].*//' | uniq | head -n1)'. Note that this step requires an updated version of bitcoin-cli due to PR#21500. Third, users should construct the taproot descriptor per BIP 86 using 'DESC="tr($TPRV/86'/1'/0'/0/*)"' and 'CHK="$(bitcoin-cli -rpcwallet=descwallet -signet getdescriptorinfo "$DESC" | jq -r .checksum)"'. Fourth, import the descriptor using 'bitcoin-cli -rpcwallet=descwallet -signet importdescriptors "[{\"desc\": \"$DESC#$CHK\", \"active\": true, \"timestamp\": \"now\", \"range\": [0,1000], \"next_index\": 1}]"'. Finally, get an address using 'bitcoin-cli -rpcwallet=descwallet -signet getnewaddress '' bech32m'.Andreas Schildbach via bitcoin-dev is trying to finish off bitcoinj's implementation for sending to taproot addresses. They are requesting a testnet wallet that can receive to P2TR and spend back in order to complete this task. Despite their efforts, they have been unable to obtain a taproot address from Bitcoin Core 22.0. Pieter has responded to Andreas' request by providing instructions on how to construct a taproot-capable wallet in Bitcoin Core. This involves having or creating a descriptor wallet with descriptors=true, importing a taproot descriptor (of the form "tr(KEY)") as active descriptor with active=true, where KEY can be a tprv.../* or any other supported key expression, and getting a new address with addresstype=bech32m. Pieter has also provided a taproot address for testing purposes: tb1p84x2ryuyfevgnlpnxt9f39gm7r68gwtvllxqe5w2n5ru00s9aquslzggwq. If testnet coins are sent there, Pieter has requested an email address to return them.The individual working on implementing bitcoinj's sending feature for taproot addresses is requesting a testnet wallet that can receive to P2TR and spend back. They have been unable to obtain a taproot address from Bitcoin Core 22.0 and are seeking assistance. They do not care about the safety of their testnet coins, so there is no need to worry about compromised private keys. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Test-cases-for-Taproot-signature-message.xml b/static/bitcoin-dev/Oct_2021/combined_Test-cases-for-Taproot-signature-message.xml index c7a5179fd6..f42fdf8fbd 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Test-cases-for-Taproot-signature-message.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Test-cases-for-Taproot-signature-message.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Test cases for Taproot signature message - 2023-08-02T04:50:14.059947+00:00 - - Giacomo Caironi 2021-10-06 20:35:51+00:00 - - - Giacomo Caironi 2021-09-18 11:32:28+00:00 - - - Riccardo Casatta 2021-09-17 07:07:48+00:00 - - - Pieter Wuille 2021-09-16 22:30:19+00:00 - - - Giacomo Caironi 2021-09-16 21:36:48+00:00 - + 2025-09-26T16:03:46.257584+00:00 + python-feedgen + + + [bitcoin-dev] Test cases for Taproot signature message Giacomo Caironi + 2021-09-16T21:36:00.000Z + + + Pieter Wuille + 2021-09-16T22:30:00.000Z + + + Riccardo Casatta + 2021-09-17T07:07:00.000Z + + + Giacomo Caironi + 2021-09-18T11:32:00.000Z + + + Giacomo Caironi + 2021-10-06T20:35:00.000Z + + - python-feedgen + 2 Combined summary - Test cases for Taproot signature message - 2023-08-02T04:50:14.059947+00:00 + 2025-09-26T16:03:46.258291+00:00 - A pull request has been opened for the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The pull request is related to a discussion between Giacomo Caironi and Pieter Wuille on the bitcoin-dev mailing list.Caironi had created three test cases for the SigMsg function in a python implementation of bitcoin signature messages, but he was unsure if they were correct. He had also noted that the documentation and test vectors for Taproot signature message were not as clear as those for Segwit signature message.Wuille agreed with Caironi's observations and explained that BIP 341 defines a common message function for Taproot and Segwit, which is then built up for key path spending and tapscript spending respectively. While this could have been a separate BIP, it would not have been a very clean separation. Wuille did not support changing this at the moment given the state of deployment of the BIPs, but he acknowledged that the documentation/vectors could be improved in the existing documents.Caironi had also pointed out that the test vectors for Taproot were not atomic and did not target a specific part of the code, making debugging difficult. Wuille agreed and suggested that test vectors for certain P2TR scriptPubKeys, derived from certain internal keys and script trees, could be useful for developers of signing code. Wuille welcomed Caironi's offer to write test cases for Taproot and offered to help integrate them in Bitcoin Core and the BIPs.The sender created three test cases for the SigMsg function, which can be found at a provided link. The tests cover most of the function but do not include the ext_flag, so they are only applicable to taproot key paths. If one wants to test script paths, they would need to implement more than this function and use the official test vector. The sender requests that someone review the test cases.In a separate email, Giacomo Caironi complains about the lack of documentation for Taproot signature messages compared to Segwit signature messages in BIPs. The signature message function is defined in BIP 341, while the test vectors are in a different BIP 341, making it confusing.Pieter Wuille responds by clarifying that there is no separate BIP for the signature message function because it is different for BIP341 and BIP342. The common part could have been a separate BIP, but given the state of deployment, he does not support changing it at this point. He suggests improving existing documentation/vectors instead.Giacomo Caironi also notes that the test vectors for Taproot have no documentation and are not atomic, making it difficult to debug when something goes wrong. Pieter Wuille agrees and notes that the existing tests are intended for verifying an implementation against and ensuring future code changes don't break anything. While the existing tests have higher coverage than the Segwit tests, they are not useful as documentation. Pieter Wuille suggests writing test vectors aimed at helping debugging issues, such as the sighash code or P2TR scriptPubKeys derived from internal keys and script trees.A developer named Riccardo Casatta has written the Rust implementation of Bitcoin signature messages and created some test vectors to double-check. These test vectors can be found on GitHub.Meanwhile, Giacomo Caironi has worked on a Python implementation of Bitcoin signature messages and noticed that there is better documentation for Segwit signature message than Taproot. He suggests creating a different BIP only for Taproot signature message instead of defining it in BIP 341 and keeping the test vectors in a different BIP. The test vectors for Taproot have no documentation and are not atomic, which makes debugging difficult. In contrast, BIP 143 provides hash preimages for debugging the function in Segwit signature hash. Caironi is willing to write the test cases for Taproot if his idea is accepted. This is his first time contributing to Bitcoin and he apologizes if he wrote something wrong due to English being his second language.On September 16th, 2021, Giacomo Caironi posted on bitcoin-dev forum regarding the documentation of Taproot signature message. He found that Segwit signature messaging had better documentation than Taproot. According to Caironi, Segwit signature message has its own BIP with test cases while Taproot's signature message function is defined in BIP 341 and the test vectors are in a different BIP (also 341). Caironi suggested creating a separate BIP for Taproot signature message like Segwit.Pieter Wuille responded by mentioning that there is no separate BIP for the signature message function as the message function is different for BIP341 and BIP342. Wuille suggested that the existing documentation/vectors can be improved in the existing documents instead of creating a separate BIP.Caironi also brought up the issue of test vectors for Taproot having no documentation and not being atomic, which can 2021-10-06T20:35:51+00:00 + A pull request has been opened for the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The pull request is related to a discussion between Giacomo Caironi and Pieter Wuille on the bitcoin-dev mailing list.Caironi had created three test cases for the SigMsg function in a python implementation of bitcoin signature messages, but he was unsure if they were correct. He had also noted that the documentation and test vectors for Taproot signature message were not as clear as those for Segwit signature message.Wuille agreed with Caironi's observations and explained that BIP 341 defines a common message function for Taproot and Segwit, which is then built up for key path spending and tapscript spending respectively. While this could have been a separate BIP, it would not have been a very clean separation. Wuille did not support changing this at the moment given the state of deployment of the BIPs, but he acknowledged that the documentation/vectors could be improved in the existing documents.Caironi had also pointed out that the test vectors for Taproot were not atomic and did not target a specific part of the code, making debugging difficult. Wuille agreed and suggested that test vectors for certain P2TR scriptPubKeys, derived from certain internal keys and script trees, could be useful for developers of signing code. Wuille welcomed Caironi's offer to write test cases for Taproot and offered to help integrate them in Bitcoin Core and the BIPs.The sender created three test cases for the SigMsg function, which can be found at a provided link. The tests cover most of the function but do not include the ext_flag, so they are only applicable to taproot key paths. If one wants to test script paths, they would need to implement more than this function and use the official test vector. The sender requests that someone review the test cases.In a separate email, Giacomo Caironi complains about the lack of documentation for Taproot signature messages compared to Segwit signature messages in BIPs. The signature message function is defined in BIP 341, while the test vectors are in a different BIP 341, making it confusing.Pieter Wuille responds by clarifying that there is no separate BIP for the signature message function because it is different for BIP341 and BIP342. The common part could have been a separate BIP, but given the state of deployment, he does not support changing it at this point. He suggests improving existing documentation/vectors instead.Giacomo Caironi also notes that the test vectors for Taproot have no documentation and are not atomic, making it difficult to debug when something goes wrong. Pieter Wuille agrees and notes that the existing tests are intended for verifying an implementation against and ensuring future code changes don't break anything. While the existing tests have higher coverage than the Segwit tests, they are not useful as documentation. Pieter Wuille suggests writing test vectors aimed at helping debugging issues, such as the sighash code or P2TR scriptPubKeys derived from internal keys and script trees.A developer named Riccardo Casatta has written the Rust implementation of Bitcoin signature messages and created some test vectors to double-check. These test vectors can be found on GitHub.Meanwhile, Giacomo Caironi has worked on a Python implementation of Bitcoin signature messages and noticed that there is better documentation for Segwit signature message than Taproot. He suggests creating a different BIP only for Taproot signature message instead of defining it in BIP 341 and keeping the test vectors in a different BIP. The test vectors for Taproot have no documentation and are not atomic, which makes debugging difficult. In contrast, BIP 143 provides hash preimages for debugging the function in Segwit signature hash. Caironi is willing to write the test cases for Taproot if his idea is accepted. This is his first time contributing to Bitcoin and he apologizes if he wrote something wrong due to English being his second language.On September 16th, 2021, Giacomo Caironi posted on bitcoin-dev forum regarding the documentation of Taproot signature message. He found that Segwit signature messaging had better documentation than Taproot. According to Caironi, Segwit signature message has its own BIP with test cases while Taproot's signature message function is defined in BIP 341 and the test vectors are in a different BIP (also 341). Caironi suggested creating a separate BIP for Taproot signature message like Segwit.Pieter Wuille responded by mentioning that there is no separate BIP for the signature message function as the message function is different for BIP341 and BIP342. Wuille suggested that the existing documentation/vectors can be improved in the existing documents instead of creating a separate BIP.Caironi also brought up the issue of test vectors for Taproot having no documentation and not being atomic, which can - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Wednesday-s-second-BIP-process-meeting.xml b/static/bitcoin-dev/Oct_2021/combined_Wednesday-s-second-BIP-process-meeting.xml index d0b196c331..94f7961342 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Wednesday-s-second-BIP-process-meeting.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Wednesday-s-second-BIP-process-meeting.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Wednesday’s second BIP process meeting - 2023-08-02T04:53:06.904916+00:00 + 2025-09-26T16:03:33.503502+00:00 + python-feedgen Prayank 2021-10-06 04:02:55+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Wednesday’s second BIP process meeting - 2023-08-02T04:53:06.904916+00:00 + 2025-09-26T16:03:33.503692+00:00 - The recent BIP process meetings focused on various topics related to Bitcoin Improvement Proposals (BIPs). One of the main issues discussed was the concern about having too many BIPs of varying quality, similar to what Ethereum has experienced. Storing BIPs in multiple repositories was considered impractical as it would be difficult to monitor and maintain them all. The participants acknowledged the desire for greater decentralization but emphasized the importance of having a centralized repository for easier management.The discussions also touched upon the motivations behind introducing alternative parallel processes to the BIPs, such as BOLTs and SLIPs. While anyone is free to set up their own repositories or parallel processes, there was a need to prevent unnecessary splintering and ensure that important documents are properly BIPed. Concerns were raised about the absence of certain BIPs, like BIP 48, and whether Lightning BOLTs should be treated as BIPs in the future.Kalle Alm's proposal for BIP extensions received support from the participants, but further clarity on their usage was requested. It was suggested that using dates or short extension names instead of numbers would be more effective and avoid confusion.The participants agreed that further discussion should take place on the #bitcoin-dev Libera IRC channel. Progress is expected on an update to BIP 3 in the coming weeks and months. Efforts were made to increase participation in the meetings, including reaching out to Christopher and utilizing social media platforms.However, it was noted that influential developers who had previously advocated for decentralization were not present at the meetings, and there has been no follow-up on the mailing list. Decentralization was seen as necessary only in cases where there were issues with Luke Dashjr.Overall, the BIP process meetings provided valuable insights and highlighted the need for balancing decentralization with practicality. Further discussions and updates are anticipated in the near future. 2021-10-06T04:02:55+00:00 + The recent BIP process meetings focused on various topics related to Bitcoin Improvement Proposals (BIPs). One of the main issues discussed was the concern about having too many BIPs of varying quality, similar to what Ethereum has experienced. Storing BIPs in multiple repositories was considered impractical as it would be difficult to monitor and maintain them all. The participants acknowledged the desire for greater decentralization but emphasized the importance of having a centralized repository for easier management.The discussions also touched upon the motivations behind introducing alternative parallel processes to the BIPs, such as BOLTs and SLIPs. While anyone is free to set up their own repositories or parallel processes, there was a need to prevent unnecessary splintering and ensure that important documents are properly BIPed. Concerns were raised about the absence of certain BIPs, like BIP 48, and whether Lightning BOLTs should be treated as BIPs in the future.Kalle Alm's proposal for BIP extensions received support from the participants, but further clarity on their usage was requested. It was suggested that using dates or short extension names instead of numbers would be more effective and avoid confusion.The participants agreed that further discussion should take place on the #bitcoin-dev Libera IRC channel. Progress is expected on an update to BIP 3 in the coming weeks and months. Efforts were made to increase participation in the meetings, including reaching out to Christopher and utilizing social media platforms.However, it was noted that influential developers who had previously advocated for decentralization were not present at the meetings, and there has been no follow-up on the mailing list. Decentralization was seen as necessary only in cases where there were issues with Luke Dashjr.Overall, the BIP process meetings provided valuable insights and highlighted the need for balancing decentralization with practicality. Further discussions and updates are anticipated in the near future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_Year-2038-problem-and-year-2106-chain-halting.xml b/static/bitcoin-dev/Oct_2021/combined_Year-2038-problem-and-year-2106-chain-halting.xml index 9fc9c36d10..62e85991b4 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Year-2038-problem-and-year-2106-chain-halting.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Year-2038-problem-and-year-2106-chain-halting.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Year 2038 problem and year 2106 chain halting - 2023-08-02T05:06:13.903709+00:00 - - yanmaani at cock.li 2021-10-18 02:55:32+00:00 - - - damian at willtech.com.au 2021-10-17 22:38:16+00:00 - - - Kate Salazar 2021-10-17 15:46:46+00:00 - - - yanmaani at cock.li 2021-10-17 15:14:41+00:00 - - - Kate Salazar 2021-10-17 08:19:07+00:00 - - - vjudeu at gazeta.pl 2021-10-17 07:24:43+00:00 - - - ZmnSCPxj 2021-10-16 23:23:15+00:00 - - - Kate Salazar 2021-10-16 21:34:32+00:00 - - - David Bakin 2021-10-16 20:37:27+00:00 - - - vjudeu at gazeta.pl 2021-10-16 09:06:17+00:00 - - - ZmnSCPxj 2021-10-15 23:01:46+00:00 - - - vjudeu at gazeta.pl 2021-10-15 22:22:00+00:00 - - - yanmaani at cock.li 2021-10-15 15:44:59+00:00 - - - James Lu 2021-10-15 15:27:42+00:00 - - - vjudeu at gazeta.pl 2021-10-13 19:16:05+00:00 - + 2025-09-26T16:03:31.383430+00:00 + python-feedgen + + + [bitcoin-dev] Year 2038 problem and year 2106 chain halting vjudeu + 2021-10-13T19:16:00.000Z + + + James Lu + 2021-10-15T15:27:00.000Z + + + yanmaani + 2021-10-15T15:44:00.000Z + + + vjudeu + 2021-10-15T22:22:00.000Z + + + ZmnSCPxj + 2021-10-15T23:01:00.000Z + + + vjudeu + 2021-10-16T09:06:00.000Z + + + David Bakin + 2021-10-16T20:37:00.000Z + + + Kate Salazar + 2021-10-16T21:34:00.000Z + + + ZmnSCPxj + 2021-10-16T23:23:00.000Z + + + vjudeu + 2021-10-17T07:24:00.000Z + + + Kate Salazar + 2021-10-17T08:19:00.000Z + + + yanmaani + 2021-10-17T15:14:00.000Z + + + Kate Salazar + 2021-10-17T15:46:00.000Z + + + damian + 2021-10-17T22:38:00.000Z + + + yanmaani + 2021-10-18T02:55:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Year 2038 problem and year 2106 chain halting - 2023-08-02T05:06:13.903709+00:00 + 2025-09-26T16:03:31.385081+00:00 - The Bitcoin development mailing list has been actively discussing the issue of timestamp overflow in Bitcoin transactions. One proposed solution involves introducing a new variable 'k' to represent the most significant 32 bits of a 64-bit timestamp. This 'k' value would be stored in all cases where time is used to avoid confusion. However, there are concerns that skipping 'k' could cause problems with OP_CHECKLOCKTIMEVERIFY or nLockTime. To address these concerns, it is suggested to add the 'k' value to the coinbase transaction and combine the lower bits from the block header and higher bits from the coinbase transaction.Additionally, it may be necessary to add the 'k' value to the nLockTime field in a similar way as transaction witness in SegWit. The same approach is needed for each OP_CHECKLOCKTIMEVERIFY, and pushing high 32 bits before the currently-used value may solve that. While this proposal requires a hard fork, it is not one that needs to take effect for many years.Another discussion on the mailing list focused on the potential functionality issues of Bitcoin Core after the year 2038. It was noted that if the current time is non-negative, the software will stop working due to assertion checking. Furthermore, the entire chain will halt once it reaches median time 0xffffffff in 2106. Suggestions were made to fix these issues in a soft-fork manner instead of a hard fork.There were also discussions regarding the increment of timestamps in new blocks by post-softfork nodes. It was suggested that the fastest rate can be achieved by incrementing timestamps once per 6 blocks, resulting in a x3600 increase. However, difficulty calculations need to account for the time increase once per difficulty change to maintain a realistic level. The context also mentions what happens if a series of blocks has a timestamp of 0xFFFFFFFF at the appropriate time, which would cause the chain to halt for all old clients.The Bitcoin-dev mailing list also highlighted a potential issue known as the "year 2038 problem" where the chain may halt for all old clients due to the lack of a 32-bit value greater than 0xffffffff. Solutions were proposed, such as adding a 64-bit timestamp to the coinbase transaction and using a similar scheme for nLockTime. However, changing the timestamp datatype could cause hardware incompatibility and require a hard fork.In summary, the discussions on the Bitcoin development mailing list revolve around addressing the issue of timestamp overflow in Bitcoin transactions. Various proposals and solutions have been suggested, including introducing a new variable 'k', combining block header and coinbase transaction bits, and adding timestamps to the nLockTime field. There are also concerns about the functionality of Bitcoin Core after the year 2038 and suggestions for fixing these issues through soft forks. 2021-10-18T02:55:32+00:00 + The Bitcoin development mailing list has been actively discussing the issue of timestamp overflow in Bitcoin transactions. One proposed solution involves introducing a new variable 'k' to represent the most significant 32 bits of a 64-bit timestamp. This 'k' value would be stored in all cases where time is used to avoid confusion. However, there are concerns that skipping 'k' could cause problems with OP_CHECKLOCKTIMEVERIFY or nLockTime. To address these concerns, it is suggested to add the 'k' value to the coinbase transaction and combine the lower bits from the block header and higher bits from the coinbase transaction.Additionally, it may be necessary to add the 'k' value to the nLockTime field in a similar way as transaction witness in SegWit. The same approach is needed for each OP_CHECKLOCKTIMEVERIFY, and pushing high 32 bits before the currently-used value may solve that. While this proposal requires a hard fork, it is not one that needs to take effect for many years.Another discussion on the mailing list focused on the potential functionality issues of Bitcoin Core after the year 2038. It was noted that if the current time is non-negative, the software will stop working due to assertion checking. Furthermore, the entire chain will halt once it reaches median time 0xffffffff in 2106. Suggestions were made to fix these issues in a soft-fork manner instead of a hard fork.There were also discussions regarding the increment of timestamps in new blocks by post-softfork nodes. It was suggested that the fastest rate can be achieved by incrementing timestamps once per 6 blocks, resulting in a x3600 increase. However, difficulty calculations need to account for the time increase once per difficulty change to maintain a realistic level. The context also mentions what happens if a series of blocks has a timestamp of 0xFFFFFFFF at the appropriate time, which would cause the chain to halt for all old clients.The Bitcoin-dev mailing list also highlighted a potential issue known as the "year 2038 problem" where the chain may halt for all old clients due to the lack of a 32-bit value greater than 0xffffffff. Solutions were proposed, such as adding a 64-bit timestamp to the coinbase transaction and using a similar scheme for nLockTime. However, changing the timestamp datatype could cause hardware incompatibility and require a hard fork.In summary, the discussions on the Bitcoin development mailing list revolve around addressing the issue of timestamp overflow in Bitcoin transactions. Various proposals and solutions have been suggested, including introducing a new variable 'k', combining block header and coinbase transaction bits, and adding timestamps to the nLockTime field. There are also concerns about the functionality of Bitcoin Core after the year 2038 and suggestions for fixing these issues through soft forks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_bitcoin-java-a-new-bitcoin-library.xml b/static/bitcoin-dev/Oct_2021/combined_bitcoin-java-a-new-bitcoin-library.xml index 3af8f5a7d0..9ffff531e4 100644 --- a/static/bitcoin-dev/Oct_2021/combined_bitcoin-java-a-new-bitcoin-library.xml +++ b/static/bitcoin-dev/Oct_2021/combined_bitcoin-java-a-new-bitcoin-library.xml @@ -1,31 +1,38 @@ - + 2 Combined summary - bitcoin-java, a new bitcoin library - 2023-08-02T04:53:17.825025+00:00 - - Humberto Marcolino 2021-10-05 22:58:41+00:00 - - - Steve Myers 2021-10-05 15:47:16+00:00 - - - Mohamed Youssef 2021-10-05 09:40:42+00:00 - - - Humberto Marcolino 2021-10-05 00:23:38+00:00 - + 2025-09-26T16:03:56.827015+00:00 + python-feedgen + + + [bitcoin-dev] bitcoin-java, a new bitcoin library Humberto Marcolino + 2021-10-05T00:23:00.000Z + + + Mohamed Youssef + 2021-10-05T09:40:00.000Z + + + Steve Myers + 2021-10-05T15:47:00.000Z + + + Humberto Marcolino + 2021-10-05T22:58:00.000Z + + - python-feedgen + 2 Combined summary - bitcoin-java, a new bitcoin library - 2023-08-02T04:53:17.825025+00:00 + 2025-09-26T16:03:56.827665+00:00 - Humberto Marcolino, owner of the repository https://github.com/bitcoin-education/bitcoin-java, has developed an open-source Bitcoin library written in Java. The library includes support for taproot single key transactions and was built with educational purposes in mind. It aims to provide a leaner alternative to bitcoinj, which is considered too feature-heavy. The library does not include features for communication with nodes or any online capabilities, making it ideal for developers looking to build a wallet in Java.Humberto welcomes feedback, pull requests (PRs), and issues from the community. To facilitate collaboration, he has created a discord server for the project. Additionally, he plans to share more examples using the library on the project's website, https://www.bitcoineducation.site/.Mohamed Youssef, a member of the bitcoin-dev community, expressed interest in the library and asked if there were plans for a slack or IRC for collaboration. In response, Steve, a member of the Bitcoin Dev Kit project, suggested that Humberto take a look at their project on GitHub, which is focused on building support for Kotlin/Java and eventually Swift and iOS. Steve also mentioned that joining their team could be a great opportunity for learning about the primitives for on-chain Bitcoin.Overall, Humberto's new open-source Bitcoin library offers developers a lightweight solution for building wallets in Java, with support for taproot single key transactions. The library's focus on education and exclusion of communication and online features make it a valuable resource for those seeking to understand and work with Bitcoin in Java. Feedback and collaboration are encouraged, and interested individuals can visit the project's website for more information and examples. 2021-10-05T22:58:41+00:00 + Humberto Marcolino, owner of the repository https://github.com/bitcoin-education/bitcoin-java, has developed an open-source Bitcoin library written in Java. The library includes support for taproot single key transactions and was built with educational purposes in mind. It aims to provide a leaner alternative to bitcoinj, which is considered too feature-heavy. The library does not include features for communication with nodes or any online capabilities, making it ideal for developers looking to build a wallet in Java.Humberto welcomes feedback, pull requests (PRs), and issues from the community. To facilitate collaboration, he has created a discord server for the project. Additionally, he plans to share more examples using the library on the project's website, https://www.bitcoineducation.site/.Mohamed Youssef, a member of the bitcoin-dev community, expressed interest in the library and asked if there were plans for a slack or IRC for collaboration. In response, Steve, a member of the Bitcoin Dev Kit project, suggested that Humberto take a look at their project on GitHub, which is focused on building support for Kotlin/Java and eventually Swift and iOS. Steve also mentioned that joining their team could be a great opportunity for learning about the primitives for on-chain Bitcoin.Overall, Humberto's new open-source Bitcoin library offers developers a lightweight solution for building wallets in Java, with support for taproot single key transactions. The library's focus on education and exclusion of communication and online features make it a valuable resource for those seeking to understand and work with Bitcoin in Java. Feedback and collaboration are encouraged, and interested individuals can visit the project's website for more information and examples. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_bitcoin-org-missing-bitcoin-core-version-22-0.xml b/static/bitcoin-dev/Oct_2021/combined_bitcoin-org-missing-bitcoin-core-version-22-0.xml index a52a2d6d29..5cf333509d 100644 --- a/static/bitcoin-dev/Oct_2021/combined_bitcoin-org-missing-bitcoin-core-version-22-0.xml +++ b/static/bitcoin-dev/Oct_2021/combined_bitcoin-org-missing-bitcoin-core-version-22-0.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - bitcoin.org missing bitcoin core version 22.0 - 2023-08-02T05:06:42.579979+00:00 - - Prayank 2021-11-09 12:49:14+00:00 - - - ZmnSCPxj 2021-11-08 03:02:33+00:00 - - - yanmaani at cock.li 2021-11-05 14:45:36+00:00 - - - damian at willtech.com.au 2021-11-05 10:52:00+00:00 - - - Prayank 2021-11-05 08:17:22+00:00 - - - Andrew Chow 2021-10-20 21:50:13+00:00 - - - Kate Salazar 2021-10-20 20:18:03+00:00 - - - Owen Gunden 2021-10-20 19:49:19+00:00 - - - Charles Hill 2021-10-20 19:43:27+00:00 - - - Pieter Wuille 2021-10-20 19:37:48+00:00 - - - Owen Gunden 2021-10-20 19:20:54+00:00 - - - Prayank 2021-10-20 14:47:17+00:00 - - - Owen Gunden 2021-10-20 12:54:36+00:00 - + 2025-09-26T16:03:27.169482+00:00 + python-feedgen + + + [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0 Owen Gunden + 2021-10-20T12:54:00.000Z + + + Prayank + 2021-10-20T14:47:00.000Z + + + Owen Gunden + 2021-10-20T19:20:00.000Z + + + Pieter Wuille + 2021-10-20T19:37:00.000Z + + + Charles Hill + 2021-10-20T19:43:00.000Z + + + Owen Gunden + 2021-10-20T19:49:00.000Z + + + Kate Salazar + 2021-10-20T20:18:00.000Z + + + Andrew Chow + 2021-10-20T21:50:00.000Z + + + Prayank + 2021-11-05T08:17:00.000Z + + + damian + 2021-11-05T10:52:00.000Z + + + yanmaani + 2021-11-05T14:45:00.000Z + + + ZmnSCPxj + 2021-11-08T03:02:00.000Z + + + Prayank + 2021-11-09T12:49:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - bitcoin.org missing bitcoin core version 22.0 - 2023-08-02T05:06:42.579979+00:00 + 2025-09-26T16:03:27.171019+00:00 - In a recent conversation between Prayank and Yanmaani, the focus was on decentralization in Bitcoin full node implementations. Prayank proposed that increasing the usage of alternative full node implementations could enhance decentralization. However, Yanmaani pointed out the potential risk of consensus splits. They explored other ways to improve decentralization, including having independent contributors like Luke Dashjr and Amir Taaki, involving individuals from different countries in important roles, and funding alternative full node implementations such as Bitcoin Knots.Yanmaani raised concerns about the issue of money, stating that contributors may have less independence if their source of income is not independent. To address this, they suggested implementing a system similar to Monero's CCS or a fund controlled in a civilized and non-centralized manner to protect developers from threats to their funding. Both parties agreed that funding is a challenging problem to solve in Bitcoin due to its public good nature.The discussion also touched upon the importance of having more people from different countries taking up significant roles in Bitcoin. However, there were concerns about funding individuals from under-represented countries and the potential vulnerability of anonymous individuals funded by non-robust sources. Despite these challenges, it was emphasized that encouraging more individuals to contribute to Bitcoin's success is beneficial. The alternative scenario of smart individuals from disadvantaged backgrounds attacking Bitcoin to escape their circumstances was also highlighted.In another discussion on the bitcoin-dev mailing list, Prayank suggested that true decentralization in full node implementations goes beyond sharing the Bitcoin whitepaper. One solution proposed was to increase the usage of alternative full node implementations since the majority currently use Bitcoin Core. However, the risk of consensus splits and the inability to run personal forks in case of subversion via soft-fork hindered this suggestion. Prayank also recommended having independent contributors and maintainers like Luke Dashjr and Amir Taaki, who are not influenced by funding sources. However, the need for funding to support contributors' work posed a challenge.The involvement of individuals from different countries in important roles was also discussed. While it was initially suggested as a way to improve decentralization, concerns were raised about funding individuals in under-represented countries and the potential vulnerability to attacks on their funding. It was argued that contributors who are financially secure may be better suited for important roles. The idea of having more anonymous contributors was also explored but deemed difficult due to financial limitations and the limited benefits gained from non-robust funding sources.Furthermore, it was recommended that individuals and organizations funding Bitcoin projects should consider contributing to alternative full node implementations. However, the lack of true independence in most alternative implementations, as they need to be bug-for-bug compatible with Bitcoin Core, presented a challenge. The suggestion was made for the creation of a fund where donations could be made to support developers. This fund would be controlled in a civilized and non-centralized manner, providing some insulation for developers against threats to their contributions.The author of an email argued against the notion that decentralization alone is responsible for a project's success. They stated that multiple software implementation choices only hold value if there is an attack on fungibility or consensus. The author recommended using Bitcoin Core version 21 and creating a fork if such an attack occurs. They emphasized the importance of establishing a properly delegated organization for maintaining Bitcoin's consensus and decentralized currency. The author also mentioned the Commonwealth Bank of Australia's inclusion of buying and selling Bitcoin as one of its services, highlighting the significance of defending the existing consensus.In another email exchange, Prayank shared their perspective on improving Bitcoin's decentralization. They advocated for increased usage of alternative full node implementations like Bitcoin Knots to reduce reliance on Bitcoin Core, which currently dominates the landscape. Prayank stressed the importance of having maintainers who are independent and not influenced by any particular entity. They also expressed the need for individuals from different countries to play significant roles in Bitcoin. Additionally, Prayank suggested that organizations funding Bitcoin projects should consider supporting alternative full node implementations. They referred to a Medium post that emphasized the importance of acknowledging and addressing problems to drive improvement in engineering.The email exchange also mentioned the impending activation of Taproot, with only a limited number of blocks remaining. This milestone was seen as another success for Bitcoin's ongoing development. In response to a question about the new website and GPG signers, Prayank supported Wladimir's decision to stop signing releases, considering it a sensible move to decrease reliance on a single individual. They shared a link to a blog post by Wladimir discussing decentralization. The exchange concluded with a reminder to verify tree hashes and trust signed annotated tags when building releases.In an email thread on the Bitcoin-dev mailing list, developer Owen Gunden expressed concern regarding recent changes to the Bitcoin Core project's website and release signing process. Specifically, Gunden noted that Wladimir van der Laan, the lead maintainer of Bitcoin Core, had stopped signing releases as of version 22.0. However, other 2021-11-09T12:49:14+00:00 + In a recent conversation between Prayank and Yanmaani, the focus was on decentralization in Bitcoin full node implementations. Prayank proposed that increasing the usage of alternative full node implementations could enhance decentralization. However, Yanmaani pointed out the potential risk of consensus splits. They explored other ways to improve decentralization, including having independent contributors like Luke Dashjr and Amir Taaki, involving individuals from different countries in important roles, and funding alternative full node implementations such as Bitcoin Knots.Yanmaani raised concerns about the issue of money, stating that contributors may have less independence if their source of income is not independent. To address this, they suggested implementing a system similar to Monero's CCS or a fund controlled in a civilized and non-centralized manner to protect developers from threats to their funding. Both parties agreed that funding is a challenging problem to solve in Bitcoin due to its public good nature.The discussion also touched upon the importance of having more people from different countries taking up significant roles in Bitcoin. However, there were concerns about funding individuals from under-represented countries and the potential vulnerability of anonymous individuals funded by non-robust sources. Despite these challenges, it was emphasized that encouraging more individuals to contribute to Bitcoin's success is beneficial. The alternative scenario of smart individuals from disadvantaged backgrounds attacking Bitcoin to escape their circumstances was also highlighted.In another discussion on the bitcoin-dev mailing list, Prayank suggested that true decentralization in full node implementations goes beyond sharing the Bitcoin whitepaper. One solution proposed was to increase the usage of alternative full node implementations since the majority currently use Bitcoin Core. However, the risk of consensus splits and the inability to run personal forks in case of subversion via soft-fork hindered this suggestion. Prayank also recommended having independent contributors and maintainers like Luke Dashjr and Amir Taaki, who are not influenced by funding sources. However, the need for funding to support contributors' work posed a challenge.The involvement of individuals from different countries in important roles was also discussed. While it was initially suggested as a way to improve decentralization, concerns were raised about funding individuals in under-represented countries and the potential vulnerability to attacks on their funding. It was argued that contributors who are financially secure may be better suited for important roles. The idea of having more anonymous contributors was also explored but deemed difficult due to financial limitations and the limited benefits gained from non-robust funding sources.Furthermore, it was recommended that individuals and organizations funding Bitcoin projects should consider contributing to alternative full node implementations. However, the lack of true independence in most alternative implementations, as they need to be bug-for-bug compatible with Bitcoin Core, presented a challenge. The suggestion was made for the creation of a fund where donations could be made to support developers. This fund would be controlled in a civilized and non-centralized manner, providing some insulation for developers against threats to their contributions.The author of an email argued against the notion that decentralization alone is responsible for a project's success. They stated that multiple software implementation choices only hold value if there is an attack on fungibility or consensus. The author recommended using Bitcoin Core version 21 and creating a fork if such an attack occurs. They emphasized the importance of establishing a properly delegated organization for maintaining Bitcoin's consensus and decentralized currency. The author also mentioned the Commonwealth Bank of Australia's inclusion of buying and selling Bitcoin as one of its services, highlighting the significance of defending the existing consensus.In another email exchange, Prayank shared their perspective on improving Bitcoin's decentralization. They advocated for increased usage of alternative full node implementations like Bitcoin Knots to reduce reliance on Bitcoin Core, which currently dominates the landscape. Prayank stressed the importance of having maintainers who are independent and not influenced by any particular entity. They also expressed the need for individuals from different countries to play significant roles in Bitcoin. Additionally, Prayank suggested that organizations funding Bitcoin projects should consider supporting alternative full node implementations. They referred to a Medium post that emphasized the importance of acknowledging and addressing problems to drive improvement in engineering.The email exchange also mentioned the impending activation of Taproot, with only a limited number of blocks remaining. This milestone was seen as another success for Bitcoin's ongoing development. In response to a question about the new website and GPG signers, Prayank supported Wladimir's decision to stop signing releases, considering it a sensible move to decrease reliance on a single individual. They shared a link to a blog post by Wladimir discussing decentralization. The exchange concluded with a reminder to verify tree hashes and trust signed annotated tags when building releases.In an email thread on the Bitcoin-dev mailing list, developer Owen Gunden expressed concern regarding recent changes to the Bitcoin Core project's website and release signing process. Specifically, Gunden noted that Wladimir van der Laan, the lead maintainer of Bitcoin Core, had stopped signing releases as of version 22.0. However, other - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2021/combined_death-to-the-mempool-long-live-the-mempool.xml b/static/bitcoin-dev/Oct_2021/combined_death-to-the-mempool-long-live-the-mempool.xml index 459a20cce3..11034fbce5 100644 --- a/static/bitcoin-dev/Oct_2021/combined_death-to-the-mempool-long-live-the-mempool.xml +++ b/static/bitcoin-dev/Oct_2021/combined_death-to-the-mempool-long-live-the-mempool.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - death to the mempool, long live the mempool - 2023-08-02T05:08:02.506243+00:00 - - ZmnSCPxj 2021-11-03 10:12:57+00:00 - - - ZmnSCPxj 2021-10-28 01:04:10+00:00 - - - yanmaani at cock.li 2021-10-27 23:05:59+00:00 - - - Peter Todd 2021-10-27 20:01:51+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-27 08:44:42+00:00 - - - Antoine Riard 2021-10-26 23:44:45+00:00 - - - Gloria Zhao 2021-10-26 18:16:51+00:00 - - - ZmnSCPxj 2021-10-26 16:38:27+00:00 - - - Pieter Wuille 2021-10-26 16:26:43+00:00 - - - darosior 2021-10-26 14:09:28+00:00 - - - ZmnSCPxj 2021-10-26 08:56:10+00:00 - - - eric at voskuil.org 2021-10-26 08:31:18+00:00 - - - ZmnSCPxj 2021-10-26 08:02:24+00:00 - - - lisa neigut 2021-10-26 02:56:21+00:00 - + 2025-09-26T16:03:41.983366+00:00 + python-feedgen + + + [bitcoin-dev] death to the mempool, long live the mempool lisa neigut + 2021-10-26T02:56:00.000Z + + + ZmnSCPxj + 2021-10-26T08:02:00.000Z + + + eric + 2021-10-26T08:31:00.000Z + + + ZmnSCPxj + 2021-10-26T08:56:00.000Z + + + darosior + 2021-10-26T14:09:00.000Z + + + Pieter Wuille + 2021-10-26T16:26:00.000Z + + + ZmnSCPxj + 2021-10-26T16:38:00.000Z + + + Gloria Zhao + 2021-10-26T18:16:00.000Z + + + Antoine Riard + 2021-10-26T23:44:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-27T08:44:00.000Z + + + Peter Todd + 2021-10-27T20:01:00.000Z + + + yanmaani + 2021-10-27T23:05:00.000Z + + + ZmnSCPxj + 2021-10-28T01:04:00.000Z + + + ZmnSCPxj + 2021-11-03T10:12:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - death to the mempool, long live the mempool - 2023-08-02T05:08:02.506243+00:00 + 2025-09-26T16:03:41.984885+00:00 - In recent discussions on the bitcoin-dev mailing list, there has been a proposal to eliminate the mempool and instead have users submit their transactions directly to mining pools. This idea has sparked debate among developers and experts in the Bitcoin community.One argument in favor of removing the mempool is that it would greatly reduce the bandwidth requirement for running a node and keep transaction intentionality private until confirmed. It is suggested that this would naturally resolve current issues related to package relay and replace-by-fee (RBF) rules. However, critics argue that removing the mempool would complicate solo mining and make BetterHash proposals more difficult. They also point out that it deviates from the security model of Bitcoin and exposes the network to potential denial-of-service (DoS) attacks.Another concern raised is the potential for centralization and higher barriers to entry if users are required to submit transactions directly to mining pools. Proponents of the proposal suggest that direct communication between block template construction venues and transaction proposers could provide a venue for direct feedback on acceptable feerates, making transaction confirmation timelines less variable and allowing block producers to enforce their own minimum security budget. Critics argue that this information can already be communicated over HTTP and that removing the mempool would only reinvent its purpose.The discussion also touches on the issue of dynamic, trust-minimized discovery of mining endpoints. There is a concern that a static list of endpoints could create artificial barriers to entry and lead to centralization. One defense mechanism currently used in Bitcoin Core is selecting outbound peers based on different subnets, but replicating this mechanism for mining endpoints could downgrade the mining competition. The consensus seems to be that while opting out of transaction broadcasting is acceptable, the mempool will always be necessary to maintain a decentralized and trust-minimized system.In addition to the proposal to eliminate the mempool, there are other suggestions being discussed. These include using an anonymous communication network such as Tor for submitting transactions directly to mining pools, implementing an overlay network to relay miner-incentive compatible transactions, and finding alternative solutions such as weak blocks to address the concerns related to the mempool.Overall, the discussions highlight the importance of maintaining a decentralized and trust-minimized system in Bitcoin while avoiding artificial barriers to entry and centralization vectors. The proposal to eliminate the mempool has sparked debate, with arguments for and against its removal based on various considerations such as bandwidth requirements, transaction intentionality, solo mining, BetterHash proposals, security budgets, and DoS attacks.The current design of Bitcoin's transaction pool is being discussed by Lisa and ZmnSCPxj. ZmnSCPxj suggests using gossiping mining endpoints instead of transactions to improve anonymity and reduce global bandwidth usage. However, this method may be more expensive than having a persistent identity. Anonymity in transactions is considered important, but there are potential limitations in contacting all miners globally to confirm transactions.The Bitcoin Protocol Discussion mailing list has been discussing the possibility of eliminating the mempool, which stores unconfirmed transactions. Instead, it has been proposed that users should submit their transactions directly to mining pools through an anonymous communication network like Tor. This would reduce the bandwidth requirement for running a node and keep the intentionality of transactions private until confirmed. However, it would complicate solo mining and make BetterHash proposals more difficult. It would also require miners to identify themselves, potentially compromising anonymity.Eliminating the mempool would greatly reduce the bandwidth requirement for running a node and resolve issues with package relay and RBF rules. However, it would complicate solo mining and make BetterHash proposals harder to implement. The mining set should ideally be anonymous to prevent state co-option of mines and attacks with sufficient hashpower. The objection to this proposal is that it requires miners to identify themselves, although many miners already do so. P2Pool would not work well in this model, and non-side fees serve as an anonymity layer, where neither the miner nor the transactor needs to know each other's identity.Removing the mempool and allowing users to submit transactions directly to mining pools over an anonymous communication network like Tor would greatly reduce the bandwidth requirement for running a node and maintain the privacy of transactions until they are confirmed. However, it would complicate solo mining and make BetterHash proposals more challenging. A direct communication channel between block template construction venues and transaction proposers would allow for direct feedback on acceptable feerates, making transaction confirmation timelines less variable and providing block producers with a mechanism to enforce their own minimum security budget. Initial feerate estimation would need to be based on published blocks or direct interactions with block producers.In summary, there are ongoing discussions about eliminating the mempool and having users submit transactions directly to mining pools over an anonymous communication network like Tor. While this would reduce bandwidth requirements and maintain transaction privacy, it could complicate solo mining and make BetterHash proposals more difficult. The importance of anonymity in transactions and the need for miners to look like potential miners on the network for improved security are also emphasized. However 2021-11-03T10:12:57+00:00 + In recent discussions on the bitcoin-dev mailing list, there has been a proposal to eliminate the mempool and instead have users submit their transactions directly to mining pools. This idea has sparked debate among developers and experts in the Bitcoin community.One argument in favor of removing the mempool is that it would greatly reduce the bandwidth requirement for running a node and keep transaction intentionality private until confirmed. It is suggested that this would naturally resolve current issues related to package relay and replace-by-fee (RBF) rules. However, critics argue that removing the mempool would complicate solo mining and make BetterHash proposals more difficult. They also point out that it deviates from the security model of Bitcoin and exposes the network to potential denial-of-service (DoS) attacks.Another concern raised is the potential for centralization and higher barriers to entry if users are required to submit transactions directly to mining pools. Proponents of the proposal suggest that direct communication between block template construction venues and transaction proposers could provide a venue for direct feedback on acceptable feerates, making transaction confirmation timelines less variable and allowing block producers to enforce their own minimum security budget. Critics argue that this information can already be communicated over HTTP and that removing the mempool would only reinvent its purpose.The discussion also touches on the issue of dynamic, trust-minimized discovery of mining endpoints. There is a concern that a static list of endpoints could create artificial barriers to entry and lead to centralization. One defense mechanism currently used in Bitcoin Core is selecting outbound peers based on different subnets, but replicating this mechanism for mining endpoints could downgrade the mining competition. The consensus seems to be that while opting out of transaction broadcasting is acceptable, the mempool will always be necessary to maintain a decentralized and trust-minimized system.In addition to the proposal to eliminate the mempool, there are other suggestions being discussed. These include using an anonymous communication network such as Tor for submitting transactions directly to mining pools, implementing an overlay network to relay miner-incentive compatible transactions, and finding alternative solutions such as weak blocks to address the concerns related to the mempool.Overall, the discussions highlight the importance of maintaining a decentralized and trust-minimized system in Bitcoin while avoiding artificial barriers to entry and centralization vectors. The proposal to eliminate the mempool has sparked debate, with arguments for and against its removal based on various considerations such as bandwidth requirements, transaction intentionality, solo mining, BetterHash proposals, security budgets, and DoS attacks.The current design of Bitcoin's transaction pool is being discussed by Lisa and ZmnSCPxj. ZmnSCPxj suggests using gossiping mining endpoints instead of transactions to improve anonymity and reduce global bandwidth usage. However, this method may be more expensive than having a persistent identity. Anonymity in transactions is considered important, but there are potential limitations in contacting all miners globally to confirm transactions.The Bitcoin Protocol Discussion mailing list has been discussing the possibility of eliminating the mempool, which stores unconfirmed transactions. Instead, it has been proposed that users should submit their transactions directly to mining pools through an anonymous communication network like Tor. This would reduce the bandwidth requirement for running a node and keep the intentionality of transactions private until confirmed. However, it would complicate solo mining and make BetterHash proposals more difficult. It would also require miners to identify themselves, potentially compromising anonymity.Eliminating the mempool would greatly reduce the bandwidth requirement for running a node and resolve issues with package relay and RBF rules. However, it would complicate solo mining and make BetterHash proposals harder to implement. The mining set should ideally be anonymous to prevent state co-option of mines and attacks with sufficient hashpower. The objection to this proposal is that it requires miners to identify themselves, although many miners already do so. P2Pool would not work well in this model, and non-side fees serve as an anonymity layer, where neither the miner nor the transactor needs to know each other's identity.Removing the mempool and allowing users to submit transactions directly to mining pools over an anonymous communication network like Tor would greatly reduce the bandwidth requirement for running a node and maintain the privacy of transactions until they are confirmed. However, it would complicate solo mining and make BetterHash proposals more challenging. A direct communication channel between block template construction venues and transaction proposers would allow for direct feedback on acceptable feerates, making transaction confirmation timelines less variable and providing block producers with a mechanism to enforce their own minimum security budget. Initial feerate estimation would need to be based on published blocks or direct interactions with block producers.In summary, there are ongoing discussions about eliminating the mempool and having users submit transactions directly to mining pools over an anonymous communication network like Tor. While this would reduce bandwidth requirements and maintain transaction privacy, it could complicate solo mining and make BetterHash proposals more difficult. The importance of anonymity in transactions and the need for miners to look like potential miners on the network for improved security are also emphasized. However - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml b/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml index 0040f80feb..8846de7447 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) - 2025-09-26T14:21:15.183476+00:00 + 2025-09-26T15:29:40.538755+00:00 python-feedgen Peter Todd 2022-10-20 22:52:03+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) - 2025-09-26T14:21:15.183618+00:00 + 2025-09-26T15:29:40.538903+00:00 2022-10-20T22:52:03+00:00 John Carvalho expresses concerns about replace-by-fee (RBF) and its potential negative impact on Bitcoin transactions. Although only a small percentage of transactions currently use RBF, the risk it poses is immeasurable. Transactions can be replaced without warning, making it difficult for merchants to effectively monitor and enforce acceptance of zero-conf (0conf) transactions.Carvalho argues that responsible 0conf acceptance is rational and trusting, as it mitigates exposure to double-spends and limits their size per block. He suggests that occasional double-spending is less costly than experiencing delayed checkout processes. However, if the remaining 71% of transactions also become subject to replaceability, relying on ignoring the risk becomes an unsustainable approach.The fact remains that merchants cannot rely on having seen all transactions being considered by miners for their block templates, nor can they guarantee receiving replacements before the original transaction is included in a block. The unstable gentlemen's agreement of "first-seen" is bound to fail eventually. Additionally, propping up the illusion of reliable payment promises hampers price discovery of blockspace and complicates protocol development.To address this, the context proposes converging on the inevitable outcome and facilitating replaceability for all transactions. This would involve reassessing business approaches in light of Bitcoin's natural modus operandi and embracing the uncertainty of the gossip system. By doing so, the band-aid can be ripped off rather than perpetually suffering from uncertainty.Peter Todd counters Carvalho's concerns by highlighting the use of RBF in his OpenTimestamps calendars for optimal fee discovery. Replacements account for approximately 95% of OpenTimestamps transactions mined. Todd also notes that at least 97.21% of hashing power supports opt-in RBF. He questions whether this indicates that almost all hashing power is irrational.Todd further mentions that Electrum has implemented an undo button using RBF successfully. Additionally, rejecting blocks containing double-spends could lead to severe consensus problems, despite the fact that it should be implemented.In summary, the context delves into the debate surrounding 0conf acceptance and RBF assurances in Bitcoin transactions. Carvalho argues for responsible 0conf acceptance, highlighting the risks of RBF and the potential impact on merchants. Todd counters with examples of successful RBF implementations and questions the rationality of opposing its use. The context ultimately raises the question of which approach, preferring blocks with replaced transactions or rejecting them, is more likely for the node set. diff --git a/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 2d7ccb38a2..8c62942647 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -2,7 +2,7 @@ 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:20:43.106885+00:00 + 2025-09-26T15:29:34.181876+00:00 python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -81,10 +81,11 @@ + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:20:43.107104+00:00 + 2025-09-26T15:29:34.182055+00:00 2023-03-13T16:38:25+00:00 On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to diff --git a/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 8888512508..9b16ba77c2 100644 --- a/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -2,7 +2,7 @@ 2 Combined summary - On a new community process to specify covenants - 2025-09-26T14:20:45.254287+00:00 + 2025-09-26T15:29:36.297707+00:00 python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -105,10 +105,11 @@ + 2 Combined summary - On a new community process to specify covenants - 2025-09-26T14:20:45.254467+00:00 + 2025-09-26T15:29:36.297874+00:00 2022-10-07T15:33:12+00:00 The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest diff --git a/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml b/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml index 44d313982a..a20eee8776 100644 --- a/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml +++ b/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml @@ -2,7 +2,7 @@ 2 Combined summary - On mempool policy consistency - 2025-09-26T14:20:30.199403+00:00 + 2025-09-26T15:29:29.953882+00:00 python-feedgen email at yancy.lol 2022-11-10 14:38:27+00:00 @@ -137,10 +137,11 @@ + 2 Combined summary - On mempool policy consistency - 2025-09-26T14:20:30.199636+00:00 + 2025-09-26T15:29:29.954060+00:00 2022-11-10T14:38:27+00:00 The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases. The discussion also touched upon diff --git a/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml index cb9019a4d4..7d9d3b59f8 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml @@ -2,7 +2,7 @@ 2 Combined summary - Packaged Transaction Relay - 2025-09-26T14:21:06.612499+00:00 + 2025-09-26T15:29:38.417333+00:00 python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - Packaged Transaction Relay - 2025-09-26T14:21:06.612658+00:00 + 2025-09-26T15:29:38.417519+00:00 2022-10-10T22:05:38+00:00 The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. diff --git a/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml b/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml index c0526faafd..6132e74098 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml @@ -2,7 +2,7 @@ 2 Combined summary - Trustless Address Server ? Outsourcing handing out addresses - 2025-09-26T14:20:36.693810+00:00 + 2025-09-26T15:29:32.066230+00:00 python-feedgen Ruben Somsen 2022-10-01 10:18:49+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Trustless Address Server ? Outsourcing handing out addresses - 2025-09-26T14:20:36.693972+00:00 + 2025-09-26T15:29:32.066384+00:00 2022-10-01T10:18:49+00:00 In an email exchange on the bitcoin-dev mailing list, Ruben and Peter discussed various topics related to Bitcoin addresses. Ruben suggested that distributing xpubs could potentially reduce the gap limit for generated addresses since there would be less reason to expect a gap if those addresses are used by the same person. He shared a link to a related thread for further reference.Peter contributed to the discussion by highlighting some points worth considering. He mentioned that handing out xpubs can create a quadratic gap limit problem, where wallets need to scan multiple xpubs and their receive addresses. However, in the Lightning network, this issue can be avoided by utilizing Lightning addresses that employ plus addresses. This alternative approach proves to be effective in addressing the problem.Another topic of discussion was the need for an expiry date on layer 1 addresses to ensure that the receiver still possesses the corresponding keys. Peter pointed out that the Lightning network offers a solution to this concern as well.Furthermore, the conversation delved into the possibility of using a deterministic path that doesn't separate receive and change addresses. Satoshi's original wallet concept proposed an ever-growing key pool with a 100 address gap, which may serve as a potential solution to the gap limit problem.As the discussion continued, the idea of incorporating invoice functionality into wallets arose. This feature would allow wallets to issue fresh addresses even if they haven't been used, while also providing a configurable gap limit. Additionally, embedding a sunset date in the address format, similar to PGP keys, was suggested as a means to enable address expiry for layer 1 addresses.Overall, these discussions surrounding xpubs, invoice functionality, and address expiration are crucial considerations for businesses and individuals engaged in Bitcoin transactions. The Lightning network presents viable solutions to some of these concerns, and concepts such as an ever-growing key pool and configurable gap limits show promise in addressing the gap limit problem. diff --git a/static/bitcoin-dev/Sept_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml b/static/bitcoin-dev/Sept_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml index 30345ddb3d..48e67b7f05 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Attack by modifying non-segwit transactions after segwit is accepted ? - 2023-08-01T18:59:18.023773+00:00 + 2025-09-26T16:00:40.513122+00:00 + python-feedgen Johnson Lau 2016-09-01 11:29:29+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Attack by modifying non-segwit transactions after segwit is accepted ? - 2023-08-01T18:59:18.024770+00:00 + 2025-09-26T16:00:40.513287+00:00 - In a recent discussion on Reddit, Johnson Lau clarified that there is no real attack in the segwit code and explained how a check in the code can prevent potential vulnerabilities. The subject of the thread had a question mark, indicating that clarification was being sought from the community rather than asserting the existence of a vulnerability. The complexity of the segwit code was acknowledged by Sergio Demian Lerner, with key parts of the consensus code spread across source files.Johnson Lau's clarifications were appreciated by the community, and he emphasized that adding witness data to a non-segwit script is invalid according to consensus. He shared a pull request that detects such violations early and bans the peer. Another approach proposed by Lau is to run the scripts of all incoming transactions, which is feasible as the unspent transaction outputs (utxos) have already been fetched, making validation easier.The consensus in the Bitcoin community is that adding witness data to a non-segwit script is considered invalid. This consensus is highlighted in a code snippet on Github's bitcoin repository. A new pull request has been made to detect any violations of this consensus early and ban the peer responsible. Additionally, another suggested approach is to run the scripts of all incoming transactions, taking advantage of the fact that utxos have already been fetched during the validation process.The potential for malicious nodes to modify non-segwit transactions after segwit activation was discussed in a recent thread on Bitcoin Improvement Proposals (BIP). It was suggested that a malicious node could re-format a non-segwit transaction into a segwit transaction with up to 400 Kbytes of segwit witness program data, resulting in both transactions having the same hash. However, due to low fees per byte, such a modified transaction would likely not be properly relayed by the network. An attacker could still modify the original transaction by adding segwit witness program data up to the point of relaying the transaction, successfully preventing it from being mined.Another concern is that an attacker could encode arbitrary data, such as virus signatures or illegal content, into passing non-segwit transactions. One proposed solution is to increase the transaction version to 3 for segwit transactions, ensuring that a non-segwit transaction cannot be converted into a segwit transaction without changing the transaction hash. However, this solution does not address all potential problems, as transactions with a mixture of segwit and non-segwit inputs could still be vulnerable to the same attack, even if they are version 3.To mitigate these issues, a simple check could be added to the IsStandardTX() function to prevent witness programs from having a stack element length greater than the maximum script element size (MAX_SCRIPT_ELEMENT_SIZE). However, a more long-term solution would be to introduce a field for each input or the entire transaction that specifies the maximum size of the witness stack in bytes (maxWitnessSize).Overall, the discussion revolves around the complexities of the segwit code and various approaches to prevent potential attacks or vulnerabilities. It underscores the importance of raising questions and seeking clarification from the community when necessary. The provided links to relevant code and pull requests serve as valuable references for further exploration of the topic. 2016-09-01T11:29:29+00:00 + In a recent discussion on Reddit, Johnson Lau clarified that there is no real attack in the segwit code and explained how a check in the code can prevent potential vulnerabilities. The subject of the thread had a question mark, indicating that clarification was being sought from the community rather than asserting the existence of a vulnerability. The complexity of the segwit code was acknowledged by Sergio Demian Lerner, with key parts of the consensus code spread across source files.Johnson Lau's clarifications were appreciated by the community, and he emphasized that adding witness data to a non-segwit script is invalid according to consensus. He shared a pull request that detects such violations early and bans the peer. Another approach proposed by Lau is to run the scripts of all incoming transactions, which is feasible as the unspent transaction outputs (utxos) have already been fetched, making validation easier.The consensus in the Bitcoin community is that adding witness data to a non-segwit script is considered invalid. This consensus is highlighted in a code snippet on Github's bitcoin repository. A new pull request has been made to detect any violations of this consensus early and ban the peer responsible. Additionally, another suggested approach is to run the scripts of all incoming transactions, taking advantage of the fact that utxos have already been fetched during the validation process.The potential for malicious nodes to modify non-segwit transactions after segwit activation was discussed in a recent thread on Bitcoin Improvement Proposals (BIP). It was suggested that a malicious node could re-format a non-segwit transaction into a segwit transaction with up to 400 Kbytes of segwit witness program data, resulting in both transactions having the same hash. However, due to low fees per byte, such a modified transaction would likely not be properly relayed by the network. An attacker could still modify the original transaction by adding segwit witness program data up to the point of relaying the transaction, successfully preventing it from being mined.Another concern is that an attacker could encode arbitrary data, such as virus signatures or illegal content, into passing non-segwit transactions. One proposed solution is to increase the transaction version to 3 for segwit transactions, ensuring that a non-segwit transaction cannot be converted into a segwit transaction without changing the transaction hash. However, this solution does not address all potential problems, as transactions with a mixture of segwit and non-segwit inputs could still be vulnerable to the same attack, even if they are version 3.To mitigate these issues, a simple check could be added to the IsStandardTX() function to prevent witness programs from having a stack element length greater than the maximum script element size (MAX_SCRIPT_ELEMENT_SIZE). However, a more long-term solution would be to introduce a field for each input or the entire transaction that specifies the maximum size of the witness stack in bytes (maxWitnessSize).Overall, the discussion revolves around the complexities of the segwit code and various approaches to prevent potential attacks or vulnerabilities. It underscores the importance of raising questions and seeking clarification from the community when necessary. The provided links to relevant code and pull requests serve as valuable references for further exploration of the topic. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_BIP-2-revival-and-rework.xml b/static/bitcoin-dev/Sept_2016/combined_BIP-2-revival-and-rework.xml index eb8cb123f6..9fb1ec2e11 100644 --- a/static/bitcoin-dev/Sept_2016/combined_BIP-2-revival-and-rework.xml +++ b/static/bitcoin-dev/Sept_2016/combined_BIP-2-revival-and-rework.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 2 revival and rework - 2023-08-01T19:05:44.160816+00:00 + 2025-09-26T16:00:51.258358+00:00 + python-feedgen Tom Zander 2016-10-16 14:56:36+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP 2 revival and rework - 2023-08-01T19:05:44.160816+00:00 + 2025-09-26T16:00:51.258556+00:00 - In a discussion on whether work can be released under public domain and CC-BY-SA, Marco Falke and Tom Zander had differing views. Zander believed that it is not possible to dual-license something under both CC-BY-SA and public domain because all licenses are based on having copyright, whereas public domain means the lack of copyright. Zander preferred copyleft licenses for BIPs. Tom Zander suggested that BIPs should be licensed as public domain with a CC-BY option. It was pointed out that while BIP 1 requires public domain or OPL, it does not forbid other licenses. Similarly, BIP 2 allows for other acceptable licenses but does not recommend them. Despite the goal of no longer allowing public domain as the only copyright option, BIP 2 does not forbid releasing work under public domain in jurisdictions where it is recognized as legal. Many BIP authors have previously chosen public domain as the only option.On October 15, 2016, Tom Zander and Marco Falke discussed the licensing of BIPs. Zander had dual-licensed BIP 134 under OPL and CC-BY-SA for future acceptance of CC-BY-SA without needing permission from all authors to remove the OPL. Falke pointed out that BIP 2 does not allow public domain as the only copyright option, to which Zander responded that public domain was never the only option.In an email exchange between Tom Zander and Luke Dashjr, they discussed licensing options for BIPs. Zander suggested public domain (CC0) or a CC-BY option, while Dashjr added MIT/BSD licenses. Dashjr explained that BIP 1 only allows OPL and public domain, so BIP 2 can be available under OPL until it activates. Dashjr clarified that CC0 and public domain are different. Dashjr was asked to reach out to the community to ensure BIP 2 has been heard and discussed. France and Germany do not recognize public domain, while GPL is valid anywhere copyright laws exist.On October 15, 2016, a discussion took place on the Bitcoin development mailing list regarding the licensing of BIPs. Marco Falke suggested licensing BIPs under CC0 with a CC-BY option, while Tom Zander disagreed and suggested a requirement for "Share alike" and an optional "Attribution." It was argued that more restrictive licenses are not suitable for BIPs and that the BIP repository is not the place to promote open access. BIP 2 allows for such licenses but does not recommend them. Clarity around proposed changes and reasoning was encouraged. The discussion concluded with the suggestion to move forward with BIP 2 if there were no objections.In a conversation on the Bitcoin Development mailing list about licensing for BIPs, it was suggested that "Share alike" be required and "Attribution" be optional. However, it was pointed out that there is no Creative Commons license option that requires Share Alike and allows Attribution as an option. CC0, MIT/BSD, or CC-BY were proposed as suitable licenses for BIPs. The suitability of more restrictive licenses and promoting open access in the BIP repository were also discussed. BIP 2 allows for such licenses but does not recommend them. The email thread concluded with the suggestion to move forward with BIP 2 if there were no objections.Luke Dashjr announced that the Open Publication License (OPL) will no longer be acceptable for BIPs. He recommended replacing OPL with one or two Creative Commons licenses, with the choice between CCO and BY-SA licenses alongside public domain. The Open Publication License, created in 1999, was superseded by Creative Commons licenses. Luke-jr made updates to BIP 2, replacing BIP 1, and introduced changes such as the acceptance of non-image auxiliary files, required email addresses for authors, and disallowing Markdown format. The updated BIP 2 was open for review with the aim of completion by Christmas. 2016-10-16T14:56:36+00:00 + In a discussion on whether work can be released under public domain and CC-BY-SA, Marco Falke and Tom Zander had differing views. Zander believed that it is not possible to dual-license something under both CC-BY-SA and public domain because all licenses are based on having copyright, whereas public domain means the lack of copyright. Zander preferred copyleft licenses for BIPs. Tom Zander suggested that BIPs should be licensed as public domain with a CC-BY option. It was pointed out that while BIP 1 requires public domain or OPL, it does not forbid other licenses. Similarly, BIP 2 allows for other acceptable licenses but does not recommend them. Despite the goal of no longer allowing public domain as the only copyright option, BIP 2 does not forbid releasing work under public domain in jurisdictions where it is recognized as legal. Many BIP authors have previously chosen public domain as the only option.On October 15, 2016, Tom Zander and Marco Falke discussed the licensing of BIPs. Zander had dual-licensed BIP 134 under OPL and CC-BY-SA for future acceptance of CC-BY-SA without needing permission from all authors to remove the OPL. Falke pointed out that BIP 2 does not allow public domain as the only copyright option, to which Zander responded that public domain was never the only option.In an email exchange between Tom Zander and Luke Dashjr, they discussed licensing options for BIPs. Zander suggested public domain (CC0) or a CC-BY option, while Dashjr added MIT/BSD licenses. Dashjr explained that BIP 1 only allows OPL and public domain, so BIP 2 can be available under OPL until it activates. Dashjr clarified that CC0 and public domain are different. Dashjr was asked to reach out to the community to ensure BIP 2 has been heard and discussed. France and Germany do not recognize public domain, while GPL is valid anywhere copyright laws exist.On October 15, 2016, a discussion took place on the Bitcoin development mailing list regarding the licensing of BIPs. Marco Falke suggested licensing BIPs under CC0 with a CC-BY option, while Tom Zander disagreed and suggested a requirement for "Share alike" and an optional "Attribution." It was argued that more restrictive licenses are not suitable for BIPs and that the BIP repository is not the place to promote open access. BIP 2 allows for such licenses but does not recommend them. Clarity around proposed changes and reasoning was encouraged. The discussion concluded with the suggestion to move forward with BIP 2 if there were no objections.In a conversation on the Bitcoin Development mailing list about licensing for BIPs, it was suggested that "Share alike" be required and "Attribution" be optional. However, it was pointed out that there is no Creative Commons license option that requires Share Alike and allows Attribution as an option. CC0, MIT/BSD, or CC-BY were proposed as suitable licenses for BIPs. The suitability of more restrictive licenses and promoting open access in the BIP repository were also discussed. BIP 2 allows for such licenses but does not recommend them. The email thread concluded with the suggestion to move forward with BIP 2 if there were no objections.Luke Dashjr announced that the Open Publication License (OPL) will no longer be acceptable for BIPs. He recommended replacing OPL with one or two Creative Commons licenses, with the choice between CCO and BY-SA licenses alongside public domain. The Open Publication License, created in 1999, was superseded by Creative Commons licenses. Luke-jr made updates to BIP 2, replacing BIP 1, and introduced changes such as the acceptance of non-image auxiliary files, required email addresses for authors, and disallowing Markdown format. The updated BIP 2 was open for review with the aim of completion by Christmas. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml b/static/bitcoin-dev/Sept_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml index ca7ad5a6db..94500d0515 100644 --- a/static/bitcoin-dev/Sept_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml +++ b/static/bitcoin-dev/Sept_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft: OP_CHECKBLOCKATHEIGHT - 2023-08-01T19:04:16.255801+00:00 + 2025-09-26T16:00:38.362603+00:00 + python-feedgen Nathan Cook 2016-10-05 02:15:36+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - BIP draft: OP_CHECKBLOCKATHEIGHT - 2023-08-01T19:04:16.255801+00:00 + 2025-09-26T16:00:38.362773+00:00 - A proposal has been made for a new opcode, OP_CHECKBLOCKATHEIGHT, in the Bitcoin scripting system. This opcode aims to tackle the problem of re-issuing bitcoin transactions when the coins they spend have been conflicted or double-spent. The proposal sparked a discussion among developers on the bitcoin-dev mailing list.Some developers expressed concerns about the complexity and potential risks of the opcode. They argued that the added complexity may not be worth the reward of protecting Bitcoiners from untrusted creditors. There were also concerns about the impact on fungibility and the risk of invalidation caused by blockchain reorganizations.Luke Dashjr, the developer who proposed the opcode, provided examples to illustrate how it could solve the problem of double-spending. One example involved Alice sending Bob BTC using a specific UTXO, but Fred double-spends that UTXO, invalidating Alice's transfer. Without the new opcode, Alice could send Bob a different UTXO, but there is a risk of both UTXOs being mined, resulting in Bob receiving more BTC than intended. With the new opcode, Alice can create a transaction that is only valid in the blockchain where Fred's double-spend has been confirmed. If that block is reorganized out, the transaction becomes invalid, ensuring that Bob receives only the original UTXO or a revised transaction if the double-spend is confirmed again.The discussion also touched upon other aspects related to the proposed opcode. There were suggestions to prevent overuse of the opcode and enforce a maximum survivable reorg to ensure sensible handling of exposed coins. Concerns were raised about the impact on mempool handling and the potential for persistent chain forks.Overall, the proposed opcode aims to address the issue of double-spending and conflicts in bitcoin transactions. It introduces a new way for users to create transactions that are only valid in specific blockchain scenarios, ensuring that the intended recipient receives the correct amount of BTC without the risk of loss due to blockchain reorganizations. However, there are ongoing discussions and debates among developers about the complexity and potential risks associated with implementing this opcode.The proposal has been put forward by Luke-Jr, who is seeking feedback from the community on whether this approach is a good idea. It is currently uncertain whether this proposal will be accepted and implemented by the Bitcoin community. However, if accepted, the proposed opcode could potentially provide a solution to the issue of double-spending that has plagued the Bitcoin network in the past. Overall, this BIP presents an interesting and innovative approach to addressing the problem of double-spending in the Bitcoin network. While its acceptance and implementation are yet to be determined, it is worth considering as a potential solution to this long-standing issue. 2016-10-05T02:15:36+00:00 + A proposal has been made for a new opcode, OP_CHECKBLOCKATHEIGHT, in the Bitcoin scripting system. This opcode aims to tackle the problem of re-issuing bitcoin transactions when the coins they spend have been conflicted or double-spent. The proposal sparked a discussion among developers on the bitcoin-dev mailing list.Some developers expressed concerns about the complexity and potential risks of the opcode. They argued that the added complexity may not be worth the reward of protecting Bitcoiners from untrusted creditors. There were also concerns about the impact on fungibility and the risk of invalidation caused by blockchain reorganizations.Luke Dashjr, the developer who proposed the opcode, provided examples to illustrate how it could solve the problem of double-spending. One example involved Alice sending Bob BTC using a specific UTXO, but Fred double-spends that UTXO, invalidating Alice's transfer. Without the new opcode, Alice could send Bob a different UTXO, but there is a risk of both UTXOs being mined, resulting in Bob receiving more BTC than intended. With the new opcode, Alice can create a transaction that is only valid in the blockchain where Fred's double-spend has been confirmed. If that block is reorganized out, the transaction becomes invalid, ensuring that Bob receives only the original UTXO or a revised transaction if the double-spend is confirmed again.The discussion also touched upon other aspects related to the proposed opcode. There were suggestions to prevent overuse of the opcode and enforce a maximum survivable reorg to ensure sensible handling of exposed coins. Concerns were raised about the impact on mempool handling and the potential for persistent chain forks.Overall, the proposed opcode aims to address the issue of double-spending and conflicts in bitcoin transactions. It introduces a new way for users to create transactions that are only valid in specific blockchain scenarios, ensuring that the intended recipient receives the correct amount of BTC without the risk of loss due to blockchain reorganizations. However, there are ongoing discussions and debates among developers about the complexity and potential risks associated with implementing this opcode.The proposal has been put forward by Luke-Jr, who is seeking feedback from the community on whether this approach is a good idea. It is currently uncertain whether this proposal will be accepted and implemented by the Bitcoin community. However, if accepted, the proposed opcode could potentially provide a solution to the issue of double-spending that has plagued the Bitcoin network in the past. Overall, this BIP presents an interesting and innovative approach to addressing the problem of double-spending in the Bitcoin network. While its acceptance and implementation are yet to be determined, it is worth considering as a potential solution to this long-standing issue. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_Completing-the-retirement-of-the-alert-system.xml b/static/bitcoin-dev/Sept_2016/combined_Completing-the-retirement-of-the-alert-system.xml index 963bed508c..b0038c4917 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Completing-the-retirement-of-the-alert-system.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Completing-the-retirement-of-the-alert-system.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Completing the retirement of the alert system - 2023-08-01T19:00:35.339275+00:00 + 2025-09-26T16:00:36.212775+00:00 + python-feedgen Gregory Maxwell 2016-09-10 15:36:38+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Completing the retirement of the alert system - 2023-08-01T19:00:35.339275+00:00 + 2025-09-26T16:00:36.212936+00:00 - In a Bitcoin development discussion, Johnson Lau suggested publishing the private key a few months after the final alert. Andrew C questioned why they would wait so long to publish it and suggested publishing it a few days after the final alert instead. However, another participant in the discussion responded that they needed to ensure the revocation message was widely distributed before making the private key public.The context of this conversation is unclear, but it is likely related to discussions around potential security vulnerabilities in the Bitcoin network. There are several possible reasons why Lau may have suggested waiting to publish the key. One explanation could be that it allows time for any remaining users who have not updated their software to do so before the key is made public. Another possibility is that it gives developers time to create patches or other solutions to address any issues that may arise after the alert is disabled. Additionally, waiting a few months could help ensure that all nodes on the network have had a chance to disable the alert and are no longer affected by its presence.Bitcoin Core has removed the alert system, which was a centralized facility that allowed trusted parties to send messages to be displayed in wallet software and remotely trigger the software to stop transacting. The system had some potential uses but also had issues that made it problematic. It was a frequent source of misunderstanding about the security model and effective governance. Furthermore, the system was not scalable to different software vendors, and no one could tell who created a message. Additionally, there was good reason to believe that the key was compromised. Due to these issues, the alert system has been deactivated, and Gregory Maxwell via Bitcoin-dev plans to send a triggering alert in the future and disclose the private key in public to eliminate any further potential of reputation attacks and diminish the risk of misunderstanding the key as some special trusted source of authority.Overall, the email chain and discussions highlight the importance of careful planning and communication when it comes to managing security risks in complex systems like Bitcoin. It is crucial to address potential vulnerabilities and ensure the widespread distribution of important messages before implementing changes or disclosing sensitive information. The removal of the alert system and the plans for deactivating the key demonstrate a proactive approach to protecting the integrity and reputation of the Bitcoin network. 2016-09-10T15:36:38+00:00 + In a Bitcoin development discussion, Johnson Lau suggested publishing the private key a few months after the final alert. Andrew C questioned why they would wait so long to publish it and suggested publishing it a few days after the final alert instead. However, another participant in the discussion responded that they needed to ensure the revocation message was widely distributed before making the private key public.The context of this conversation is unclear, but it is likely related to discussions around potential security vulnerabilities in the Bitcoin network. There are several possible reasons why Lau may have suggested waiting to publish the key. One explanation could be that it allows time for any remaining users who have not updated their software to do so before the key is made public. Another possibility is that it gives developers time to create patches or other solutions to address any issues that may arise after the alert is disabled. Additionally, waiting a few months could help ensure that all nodes on the network have had a chance to disable the alert and are no longer affected by its presence.Bitcoin Core has removed the alert system, which was a centralized facility that allowed trusted parties to send messages to be displayed in wallet software and remotely trigger the software to stop transacting. The system had some potential uses but also had issues that made it problematic. It was a frequent source of misunderstanding about the security model and effective governance. Furthermore, the system was not scalable to different software vendors, and no one could tell who created a message. Additionally, there was good reason to believe that the key was compromised. Due to these issues, the alert system has been deactivated, and Gregory Maxwell via Bitcoin-dev plans to send a triggering alert in the future and disclose the private key in public to eliminate any further potential of reputation attacks and diminish the risk of misunderstanding the key as some special trusted source of authority.Overall, the email chain and discussions highlight the importance of careful planning and communication when it comes to managing security risks in complex systems like Bitcoin. It is crucial to address potential vulnerabilities and ensure the widespread distribution of important messages before implementing changes or disclosing sensitive information. The removal of the alert system and the plans for deactivating the key demonstrate a proactive approach to protecting the integrity and reputation of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_Interpreting-nTime-for-the-purpose-of-Bitcoin-attested-timestamps.xml b/static/bitcoin-dev/Sept_2016/combined_Interpreting-nTime-for-the-purpose-of-Bitcoin-attested-timestamps.xml index aaa50bd44c..b9edf4ec08 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Interpreting-nTime-for-the-purpose-of-Bitcoin-attested-timestamps.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Interpreting-nTime-for-the-purpose-of-Bitcoin-attested-timestamps.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Interpreting nTime for the purpose of Bitcoin-attested timestamps - 2023-08-01T19:01:15.049485+00:00 + 2025-09-26T16:00:49.144381+00:00 + python-feedgen Tom Harding 2016-09-19 19:53:46+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Interpreting nTime for the purpose of Bitcoin-attested timestamps - 2023-08-01T19:01:15.049485+00:00 + 2025-09-26T16:00:49.144568+00:00 - In an email conversation, Peter Todd corrected his suggestion regarding the catch-up formula and provided a new probability formula to determine whether honest miners can build a chain N blocks long before dishonest miners. The new formula is CDF[Erlang(N, q) - Erlang(N, 1-q), 0]. He also offered assistance with numeric calculations. A digital signature was attached to the email.On bitcoin-dev, Tom Harding pointed out that the probability of dishonest miners finding N blocks in a row immediately differs from the probability of them building a chain N blocks long, considering the random walk. In response, Peter Todd suggested using Satoshi's formula from bitcoin.pdf, section 11, which yields different results. If a timestamp contains only a block height instead of actual block headers, there is no risk if the Bitcoin node is in sync with the most-work chain. However, if the verifier is not in sync, an attacker can sybil attack the verifier's node to make them believe that blocks with invalid timestamps are part of the most-work chain. This case is similar to a payee being sybil attacked, requiring the same analysis. It is important to note that timestamps should not include block headers of allegedly confirming blocks, as this is a weak proof due to the ease of creating a block. OpenTimestamps does not include block headers in timestamps, but it is worth mentioning explicitly.In a message on bitcoin-dev, Peter Todd discusses the probability of dishonest miners finding N blocks in a row immediately. He explains the need for the probability of building a chain N blocks long, taking the random-walk into account. He suggests using Satoshi's formula from bitcoin.pdf, section 11, which produces different results compared to the previous method. A q value of .5 is considered totally insecure as both factions will eventually possess a chain of length N anchored at x during the wild reorg melee.The discussion revolves around timestamps in OpenTimestamps. One person suggests considering earlier blocks, while another argues that timestamps are proofs of existence prior to a specific time and cannot have a "wrong order" in timestamp proofs. OpenTimestamps verifies plausible dates for various use cases, such as timestamped git commits. An example is provided with the date on the git commit, a date for the PGP signature, and a third date for the Bitcoin timestamp. Peter Todd's contact information is given at the end of the email.The author proposes a scheme for interpreting the nTime fields in block headers for timestamping purposes using the Bitcoin blockchain. The purpose is to provide evidence of a message's existence before a certain point in time. The algorithm defines time T as the maximum nTime out of the N blocks confirming the timestamp, including the first block committing the timestamp. Max_offset represents the maximum expected nTime offset from an honest miner. Dishonest miners can create an invalid timestamp if they find all N blocks, but if an honest miner finds any block, the nTime field will be set correctly. UI considerations include not displaying timestamps until local time surpasses the timestamp and rounding up the timestamp to the nearest day for display. 2016-09-19T19:53:46+00:00 + In an email conversation, Peter Todd corrected his suggestion regarding the catch-up formula and provided a new probability formula to determine whether honest miners can build a chain N blocks long before dishonest miners. The new formula is CDF[Erlang(N, q) - Erlang(N, 1-q), 0]. He also offered assistance with numeric calculations. A digital signature was attached to the email.On bitcoin-dev, Tom Harding pointed out that the probability of dishonest miners finding N blocks in a row immediately differs from the probability of them building a chain N blocks long, considering the random walk. In response, Peter Todd suggested using Satoshi's formula from bitcoin.pdf, section 11, which yields different results. If a timestamp contains only a block height instead of actual block headers, there is no risk if the Bitcoin node is in sync with the most-work chain. However, if the verifier is not in sync, an attacker can sybil attack the verifier's node to make them believe that blocks with invalid timestamps are part of the most-work chain. This case is similar to a payee being sybil attacked, requiring the same analysis. It is important to note that timestamps should not include block headers of allegedly confirming blocks, as this is a weak proof due to the ease of creating a block. OpenTimestamps does not include block headers in timestamps, but it is worth mentioning explicitly.In a message on bitcoin-dev, Peter Todd discusses the probability of dishonest miners finding N blocks in a row immediately. He explains the need for the probability of building a chain N blocks long, taking the random-walk into account. He suggests using Satoshi's formula from bitcoin.pdf, section 11, which produces different results compared to the previous method. A q value of .5 is considered totally insecure as both factions will eventually possess a chain of length N anchored at x during the wild reorg melee.The discussion revolves around timestamps in OpenTimestamps. One person suggests considering earlier blocks, while another argues that timestamps are proofs of existence prior to a specific time and cannot have a "wrong order" in timestamp proofs. OpenTimestamps verifies plausible dates for various use cases, such as timestamped git commits. An example is provided with the date on the git commit, a date for the PGP signature, and a third date for the Bitcoin timestamp. Peter Todd's contact information is given at the end of the email.The author proposes a scheme for interpreting the nTime fields in block headers for timestamping purposes using the Bitcoin blockchain. The purpose is to provide evidence of a message's existence before a certain point in time. The algorithm defines time T as the maximum nTime out of the N blocks confirming the timestamp, including the first block committing the timestamp. Max_offset represents the maximum expected nTime offset from an honest miner. Dishonest miners can create an invalid timestamp if they find all N blocks, but if an honest miner finds any block, the nTime field will be set correctly. UI considerations include not displaying timestamps until local time surpasses the timestamp and rounding up the timestamp to the nearest day for display. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml index cf303e3e20..9441eab84b 100644 --- a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml +++ b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH - 2023-08-01T18:56:33.083218+00:00 + 2025-09-26T16:00:46.994558+00:00 + python-feedgen Russell O'Connor 2016-09-05 14:55:10+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH - 2023-08-01T18:56:33.083218+00:00 + 2025-09-26T16:00:46.994737+00:00 - Suppose we have a marginal fee rate of 50 satoshis per byte. Reducing the size of the witness data by 1 byte is equivalent to a replace by fee that increases the fee by 50 satoshis. In both cases, miners get an extra potential of 50 satoshis in revenue. Replacing witness data with smaller witness data can pay for its own relay cost as much as RBF can, simply by requiring that the smaller witness be small enough to cover the same RBF threshold. BIP125 and mempool eviction both require the replacing transaction to have a higher fee, to compensate for the cost of relaying the replaced transaction(s).Johnson Lau, a member of the bitcoin-dev community, has proposed a restriction for segwit OP_IF argument as a policy. He is seeking more feedback from users of OP_IF to ACK or NACK his proposal. It is expected that Lightning network would use OP_IF frequently. Rusty, another member of the community, mentions that his current scripts use OP_IF and OP_NOTIF only after OP_EQUAL, except for one place where they use OP_EQUAL...OP_EQUAL...OP_ADD OP_IF. However, he notes that there will be no effect on the c-lightning implementation either way.The Bitcoin script validity rules are proposed to change in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts. This would result in the argument for OP_IF and OP_NOTIF being exactly an empty vector or 0x01, or the script evaluation fails immediately. The policy has received a few concept ACKs. A BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts. The proposed changes affect the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts. This is a softfork on top of BIP141. It is enforced as a relay policy by the reference client since the first release of BIP141. Users must not create P2WSH scripts that are incompatible with this BIP to avoid risks of fund loss.In a bitcoin-dev email, Sergio Demian Lerner raised concerns about transactions sent to IoT devices, which may be rejected if their witness program is too large for the device's implementation-imposed limit. This can result in the loss of bitcoins as the private key is stored on the device, rendering it unable to accept the cloned transaction. Lerner suggests invalidating transactions with a higher witness size than expected by the sender. The design of segwit means that resource constrained devices don't need to receive witness data to verify lite-client merkle-path proofs, which are useless for lite-clients anyway.In a discussion on the bitcoin-dev mailing list, Sergio Demian Lerner suggested that the real problem with witness data size is that it is not signed. However, Gregory Maxwell pointed out that this is not possible for the general case as you may not know the witness size in advance. Maxwell believes fees are not the problem, but rather the fact that the maximum witness size may be changed by a miner which could cause issues for devices like IoT or side-chains that have certain restrictions on transaction sizes they can accept. He proposes that if the witness size is higher than the expected size by the sender, the transaction becomes invalid.The issue at hand is that witness data size is not signed, leading to potential malleability issues and problems for systems with hard limits on the size of witness programs they can accept. A proposed solution is to soft-fork and add an opcode OP_PROGSIZE that pushes the size of the segwit program being evaluated onto the stack, which would allow scripts to take action based on the size. This would prevent an attacker from creating a clone of a transaction with a witness ECDSA signature longer than 0x50 bytes. The discussion also touches on workarounds for current behavior and the need to enforce MINIMALIF in some cases, with the suggestion to make it a relay policy first before considering a softfork.On August 17, 2016, Luke Dashjr and Johnson Lau discussed a workaround for the issue of malleability in Bitcoin transactions. The suggested code to replicate the original behavior was deemed ugly by Dashjr, who argued that it was unnecessary in most real-world use cases. He proposed simplifying the code by replacing "OP_SIZE OP_IF" with "OP_SIZE OP_0NOTEQUAL OP_IF", as OP_SIZE must return a valid MINIMALDATA number. However, Lau noted that 2016-09-05T14:55:10+00:00 + Suppose we have a marginal fee rate of 50 satoshis per byte. Reducing the size of the witness data by 1 byte is equivalent to a replace by fee that increases the fee by 50 satoshis. In both cases, miners get an extra potential of 50 satoshis in revenue. Replacing witness data with smaller witness data can pay for its own relay cost as much as RBF can, simply by requiring that the smaller witness be small enough to cover the same RBF threshold. BIP125 and mempool eviction both require the replacing transaction to have a higher fee, to compensate for the cost of relaying the replaced transaction(s).Johnson Lau, a member of the bitcoin-dev community, has proposed a restriction for segwit OP_IF argument as a policy. He is seeking more feedback from users of OP_IF to ACK or NACK his proposal. It is expected that Lightning network would use OP_IF frequently. Rusty, another member of the community, mentions that his current scripts use OP_IF and OP_NOTIF only after OP_EQUAL, except for one place where they use OP_EQUAL...OP_EQUAL...OP_ADD OP_IF. However, he notes that there will be no effect on the c-lightning implementation either way.The Bitcoin script validity rules are proposed to change in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts. This would result in the argument for OP_IF and OP_NOTIF being exactly an empty vector or 0x01, or the script evaluation fails immediately. The policy has received a few concept ACKs. A BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts. The proposed changes affect the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts. This is a softfork on top of BIP141. It is enforced as a relay policy by the reference client since the first release of BIP141. Users must not create P2WSH scripts that are incompatible with this BIP to avoid risks of fund loss.In a bitcoin-dev email, Sergio Demian Lerner raised concerns about transactions sent to IoT devices, which may be rejected if their witness program is too large for the device's implementation-imposed limit. This can result in the loss of bitcoins as the private key is stored on the device, rendering it unable to accept the cloned transaction. Lerner suggests invalidating transactions with a higher witness size than expected by the sender. The design of segwit means that resource constrained devices don't need to receive witness data to verify lite-client merkle-path proofs, which are useless for lite-clients anyway.In a discussion on the bitcoin-dev mailing list, Sergio Demian Lerner suggested that the real problem with witness data size is that it is not signed. However, Gregory Maxwell pointed out that this is not possible for the general case as you may not know the witness size in advance. Maxwell believes fees are not the problem, but rather the fact that the maximum witness size may be changed by a miner which could cause issues for devices like IoT or side-chains that have certain restrictions on transaction sizes they can accept. He proposes that if the witness size is higher than the expected size by the sender, the transaction becomes invalid.The issue at hand is that witness data size is not signed, leading to potential malleability issues and problems for systems with hard limits on the size of witness programs they can accept. A proposed solution is to soft-fork and add an opcode OP_PROGSIZE that pushes the size of the segwit program being evaluated onto the stack, which would allow scripts to take action based on the size. This would prevent an attacker from creating a clone of a transaction with a witness ECDSA signature longer than 0x50 bytes. The discussion also touches on workarounds for current behavior and the need to enforce MINIMALIF in some cases, with the suggestion to make it a relay policy first before considering a softfork.On August 17, 2016, Luke Dashjr and Johnson Lau discussed a workaround for the issue of malleability in Bitcoin transactions. The suggested code to replicate the original behavior was deemed ugly by Dashjr, who argued that it was unnecessary in most real-world use cases. He proposed simplifying the code by replacing "OP_SIZE OP_IF" with "OP_SIZE OP_0NOTEQUAL OP_IF", as OP_SIZE must return a valid MINIMALDATA number. However, Lau noted that - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-dummy-stack-element-malleability.xml b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-dummy-stack-element-malleability.xml index 6c4b878532..73526827d2 100644 --- a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-dummy-stack-element-malleability.xml +++ b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-dummy-stack-element-malleability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP: Dealing with dummy stack element malleability - 2023-08-01T19:00:17.209421+00:00 + 2025-09-26T16:00:29.762858+00:00 + python-feedgen Johnson Lau 2016-09-04 12:29:37+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - New BIP: Dealing with dummy stack element malleability - 2023-08-01T19:00:17.210423+00:00 + 2025-09-26T16:00:29.763023+00:00 - The discussion revolves around the bundling of two independent softforks in one release, raising concerns about increased testing and maintenance burdens. Testing is required for four scenarios: both softforks not activated, only NULLDUMMY activated, only SEGWIT activated, and both activated. A significant percentage of miners are hard-coding the block version number, which poses risks to the softfork transition as miners may not enforce what they signal. Bundling two independent softforks would double the risks, with NULLDUMMY alone deemed not worth the associated risks.On September 2, 2016, at 1:10 PM, Tom Harding via bitcoin-dev questioned the rationale behind bundling the two independent softforks together, suggesting that miners should have the opportunity to vote on them separately. The proposed BIP (Bitcoin Improvement Proposal) by Johnson Lau, introduced on September 1st, 2016 at 9:40 PM, suggests deploying a BIP using "version bits" BIP9 with the name "segwit" and using bit 1, employing the same parameters as BIP141 and BIP143. However, concerns were raised regarding why this fix should be bundled with segwit and whether independent voting should be allowed, as this fix has value beyond segwit.On September 2, 2016, Johnson Lau announced the deployment of BIP9 using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The BIP9 starttime and timeout for Bitcoin mainnet are still to be determined, while for Bitcoin testnet, the starttime is midnight May 1, 2016 UTC, and the timeout is midnight May 1, 2017 UTC. The reference client has been generating compatible signatures since its inception, and the null dummy rule has been enforced as relay policy by the reference client since v0.10.0. No transactions violating this requirement have been added to the chain since at least August 2015. It should be noted that for all scriptPubKey types in actual use, non-compliant signatures can easily be converted into compliant ones, except for cases where conversion is not possible.The proposed changes to the Bitcoin transaction validity rules are outlined in this BIP, aimed at addressing the malleability issue of extra stack elements for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Signature malleability allows any relay node on the network to alter the signature in transactions without requiring access to relevant private keys, posing a security concern. The "NULLDUMMY" consensus rule is introduced to address this issue, requiring the dummy element to be an empty byte array, resulting in false evaluation if anything else is used. This BIP will be deployed using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The reference client has been generating compatible signatures from the beginning, and the null dummy rule has been enforced as relay policy by the reference client since v0.10.0. An implementation for the reference client can be found at https://github.com/bitcoin/bitcoin/pull/8636.In summary, the discussion highlights concerns about bundling two independent softforks together, increasing testing and maintenance burdens. Questions were raised regarding the need for independent voting and whether the proposed fix has value beyond segwit. Johnson Lau announced the deployment of BIP9 using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The proposed changes aim to address the malleability issue of extra stack elements for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY through the introduction of the "NULLDUMMY" consensus rule. The reference client has been generating compatible signatures and enforcing the null dummy rule since v0.10.0, with no transactions violating the requirement added to the chain since at least August 2015. 2016-09-04T12:29:37+00:00 + The discussion revolves around the bundling of two independent softforks in one release, raising concerns about increased testing and maintenance burdens. Testing is required for four scenarios: both softforks not activated, only NULLDUMMY activated, only SEGWIT activated, and both activated. A significant percentage of miners are hard-coding the block version number, which poses risks to the softfork transition as miners may not enforce what they signal. Bundling two independent softforks would double the risks, with NULLDUMMY alone deemed not worth the associated risks.On September 2, 2016, at 1:10 PM, Tom Harding via bitcoin-dev questioned the rationale behind bundling the two independent softforks together, suggesting that miners should have the opportunity to vote on them separately. The proposed BIP (Bitcoin Improvement Proposal) by Johnson Lau, introduced on September 1st, 2016 at 9:40 PM, suggests deploying a BIP using "version bits" BIP9 with the name "segwit" and using bit 1, employing the same parameters as BIP141 and BIP143. However, concerns were raised regarding why this fix should be bundled with segwit and whether independent voting should be allowed, as this fix has value beyond segwit.On September 2, 2016, Johnson Lau announced the deployment of BIP9 using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The BIP9 starttime and timeout for Bitcoin mainnet are still to be determined, while for Bitcoin testnet, the starttime is midnight May 1, 2016 UTC, and the timeout is midnight May 1, 2017 UTC. The reference client has been generating compatible signatures since its inception, and the null dummy rule has been enforced as relay policy by the reference client since v0.10.0. No transactions violating this requirement have been added to the chain since at least August 2015. It should be noted that for all scriptPubKey types in actual use, non-compliant signatures can easily be converted into compliant ones, except for cases where conversion is not possible.The proposed changes to the Bitcoin transaction validity rules are outlined in this BIP, aimed at addressing the malleability issue of extra stack elements for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Signature malleability allows any relay node on the network to alter the signature in transactions without requiring access to relevant private keys, posing a security concern. The "NULLDUMMY" consensus rule is introduced to address this issue, requiring the dummy element to be an empty byte array, resulting in false evaluation if anything else is used. This BIP will be deployed using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The reference client has been generating compatible signatures from the beginning, and the null dummy rule has been enforced as relay policy by the reference client since v0.10.0. An implementation for the reference client can be found at https://github.com/bitcoin/bitcoin/pull/8636.In summary, the discussion highlights concerns about bundling two independent softforks together, increasing testing and maintenance burdens. Questions were raised regarding the need for independent voting and whether the proposed fix has value beyond segwit. Johnson Lau announced the deployment of BIP9 using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The proposed changes aim to address the malleability issue of extra stack elements for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY through the introduction of the "NULLDUMMY" consensus rule. The reference client has been generating compatible signatures and enforcing the null dummy rule since v0.10.0, with no transactions violating the requirement added to the chain since at least August 2015. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Low-S-values-signatures.xml b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Low-S-values-signatures.xml index 702df09009..fe94304380 100644 --- a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Low-S-values-signatures.xml +++ b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Low-S-values-signatures.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP: Low S values signatures - 2023-08-01T18:53:25.651454+00:00 + 2025-09-26T16:00:34.063107+00:00 + python-feedgen Johnson Lau 2016-09-02 08:28:14+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - New BIP: Low S values signatures - 2023-08-01T18:53:25.652447+00:00 + 2025-09-26T16:00:34.063279+00:00 - BIP146 proposes changes to the Bitcoin transaction validity rules in order to address signature malleability related to ECDSA signature encoding. This malleability allows relay nodes on the network to alter signatures without needing access to private keys. The BIP introduces two new rules: LOW_S and NULLFAIL. LOW_S restricts the S value inside ECDSA signatures to be at most half of the curve order, with strict DER encoding. If a signature fails the Low S value check and is not an empty byte array, the entire script will evaluate to false immediately. NULLFAIL requires that if an OP_CHECKSIG returns a FALSE value, the relevant signature must be an empty byte array. If an OP_CHECKMULTISIG returns a FALSE value, all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays. The NULLDUMMY rule has been removed from BIP146 and will become another softfork implemented along with segwit. This revision of BIP146 adds the newly implemented NULLFAIL rules which should cover all special cases. The LOW_S softfork may be deployed later due to some undocumented behavior discovered. However, NULLFAIL will be implemented as a policy rule in 0.13.1, but the softfork won't be deployed in 0.13.1.Recently, the BIP146 was updated to include NULLDUMMY as part of the softfork. The update can be found on the Github page of Bitcoin Improvement Proposals (BIPs). This trivial softfork aims to fix malleability related to the extra stack element consumed by CHECKMULTISIG(VERIFY). It is considered important as it prevents attackers from replacing the stack element with any value, which could have serious implications. The inclusion of NULLDUMMY in BIP146 addresses this issue and enhances the security of the cryptocurrency system. This update demonstrates the continuous improvement made to the Bitcoin protocol to enhance security and prevent malicious attacks.On August 16, 2016, there was a discussion between Luke Dashjr and Johnson Lau regarding the ECDSA verification process for signatures passed to operators like OP_CHECKSIG and OP_CHECKMULTISIG. These operators perform verifications on pubkey/signature pairs in reverse order from the top of the stack. If a signature fails the IsLowDERSignature check, it is not processed. However, there is ambiguity in the reference to "the IsLowDERSignature check" as it is not clearly defined. Dashjr points out that the IsLowDERSignature function in Bitcoin Core is not directly called, but he will clarify this.A new Bitcoin Improvement Proposal (BIP) has been proposed to make low S value signatures a consensus rule. The proposal aims to restrict signatures to using low S values to fix malleability issues. ECDSA signatures are malleable, but restricting the S value helps prevent invalidation by taking the negative of the number S. The BIP states that every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY must use an S value between certain limits with strict DER encoding. The BIP will be deployed using version bits BIP9, likely in v0.13.1. The implementation for the reference client can be found on Github. This proposal also reduces transaction malleability, providing additional benefits to the Bitcoin system. 2016-09-02T08:28:14+00:00 + BIP146 proposes changes to the Bitcoin transaction validity rules in order to address signature malleability related to ECDSA signature encoding. This malleability allows relay nodes on the network to alter signatures without needing access to private keys. The BIP introduces two new rules: LOW_S and NULLFAIL. LOW_S restricts the S value inside ECDSA signatures to be at most half of the curve order, with strict DER encoding. If a signature fails the Low S value check and is not an empty byte array, the entire script will evaluate to false immediately. NULLFAIL requires that if an OP_CHECKSIG returns a FALSE value, the relevant signature must be an empty byte array. If an OP_CHECKMULTISIG returns a FALSE value, all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays. The NULLDUMMY rule has been removed from BIP146 and will become another softfork implemented along with segwit. This revision of BIP146 adds the newly implemented NULLFAIL rules which should cover all special cases. The LOW_S softfork may be deployed later due to some undocumented behavior discovered. However, NULLFAIL will be implemented as a policy rule in 0.13.1, but the softfork won't be deployed in 0.13.1.Recently, the BIP146 was updated to include NULLDUMMY as part of the softfork. The update can be found on the Github page of Bitcoin Improvement Proposals (BIPs). This trivial softfork aims to fix malleability related to the extra stack element consumed by CHECKMULTISIG(VERIFY). It is considered important as it prevents attackers from replacing the stack element with any value, which could have serious implications. The inclusion of NULLDUMMY in BIP146 addresses this issue and enhances the security of the cryptocurrency system. This update demonstrates the continuous improvement made to the Bitcoin protocol to enhance security and prevent malicious attacks.On August 16, 2016, there was a discussion between Luke Dashjr and Johnson Lau regarding the ECDSA verification process for signatures passed to operators like OP_CHECKSIG and OP_CHECKMULTISIG. These operators perform verifications on pubkey/signature pairs in reverse order from the top of the stack. If a signature fails the IsLowDERSignature check, it is not processed. However, there is ambiguity in the reference to "the IsLowDERSignature check" as it is not clearly defined. Dashjr points out that the IsLowDERSignature function in Bitcoin Core is not directly called, but he will clarify this.A new Bitcoin Improvement Proposal (BIP) has been proposed to make low S value signatures a consensus rule. The proposal aims to restrict signatures to using low S values to fix malleability issues. ECDSA signatures are malleable, but restricting the S value helps prevent invalidation by taking the negative of the number S. The BIP states that every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY must use an S value between certain limits with strict DER encoding. The BIP will be deployed using version bits BIP9, likely in v0.13.1. The implementation for the reference client can be found on Github. This proposal also reduces transaction malleability, providing additional benefits to the Bitcoin system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_On-going-work-Coin-Selection-Simulation.xml b/static/bitcoin-dev/Sept_2016/combined_On-going-work-Coin-Selection-Simulation.xml index 004216b96c..88d391ea48 100644 --- a/static/bitcoin-dev/Sept_2016/combined_On-going-work-Coin-Selection-Simulation.xml +++ b/static/bitcoin-dev/Sept_2016/combined_On-going-work-Coin-Selection-Simulation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On-going work: Coin Selection Simulation - 2023-08-01T19:02:53.385142+00:00 + 2025-09-26T16:00:31.909188+00:00 + python-feedgen Murch 2016-10-21 14:09:57+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - On-going work: Coin Selection Simulation - 2023-08-01T19:02:53.385142+00:00 + 2025-09-26T16:00:31.909336+00:00 - Murch, a Master's thesis student, has developed a Coin Selection Simulator and re-implemented multiple coin selection strategies of prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin). He invites interested parties to take a look at his work, which includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation. Murch has analyzed the Coin Selection problem and created a framework to simulate wallet behavior on the basis of a sequence of payments. He plans to publish the simulation code around Scaling Bitcoin or after he turns in his thesis.Murch also addresses a question from Daniel Weigl regarding why Mycelium generates a very big UTXO set for 5460sat. Murch explains that his simulation of the Mycelium coin selection adds small change outputs to the fee but got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Therefore, the results in the table might be slightly too big, but likely indicative of the actual Mycelium behavior. Murch assumes that Mycelium doesn't create small change outputs but rather hardly ever spends them when received. Murch believes that Mycelium appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up.A researcher, Murch, has analyzed the Coin Selection problem and re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. As part of this research, Murch created a framework to simulate wallet behavior on the basis of a sequence of payments. The simulation results are presented in a two-page description along with three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Murch also invited feedback and requested another sequence of incoming and outgoing payment amounts to run the simulation on. In response to Murch's email, Daniel Weigl, from Mycelium, inquired about the behavior of Mycelium coin selection algorithm. Murch clarified that Mycelium selects UTXO in a FIFO approach, but prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems to be the likely reason for Mycelium's small UTXO build-up. BreadWallet uses a very similar FIFO approach, but doesn't prune which causes their average UTXO set to be much smaller. A balanced approach between these two approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, who is compiling his Master's thesis about Coin Selection, has created a framework to simulate wallet behavior on the basis of a sequence of payments. He re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF containing a two-page description of his ongoing work includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Daniel Weigl asked about Mycelium's large UTXO set for 5460sat (=TransactionUtils.MINIMUM_OUTPUT_VALUE). Murch replied that his simulation did add small change outputs to the fee, but he got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Murch corrected the boundary in his simulation now and will update his simulation results before Scaling Bitcoin. Regarding Mycelium, Murch stated that it doesn't create small change outputs but rather hardly ever spends them when received. It appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up. A balanced approach between BreadWallet's and Mycelium's approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, a researcher, has compiled his Master's thesis about Coin Selection and his presentation proposal to Scaling Bitcoin has been accepted. In his thesis, he analyzed the Coin Selection problem, created a framework to simulate wallet behavior on the basis of a sequence of payments, and re-implemented multiple coin selection strategies of prominent Bitcoin wallets such as Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF contains a two-page 2016-10-21T14:09:57+00:00 + Murch, a Master's thesis student, has developed a Coin Selection Simulator and re-implemented multiple coin selection strategies of prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin). He invites interested parties to take a look at his work, which includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation. Murch has analyzed the Coin Selection problem and created a framework to simulate wallet behavior on the basis of a sequence of payments. He plans to publish the simulation code around Scaling Bitcoin or after he turns in his thesis.Murch also addresses a question from Daniel Weigl regarding why Mycelium generates a very big UTXO set for 5460sat. Murch explains that his simulation of the Mycelium coin selection adds small change outputs to the fee but got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Therefore, the results in the table might be slightly too big, but likely indicative of the actual Mycelium behavior. Murch assumes that Mycelium doesn't create small change outputs but rather hardly ever spends them when received. Murch believes that Mycelium appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up.A researcher, Murch, has analyzed the Coin Selection problem and re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. As part of this research, Murch created a framework to simulate wallet behavior on the basis of a sequence of payments. The simulation results are presented in a two-page description along with three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Murch also invited feedback and requested another sequence of incoming and outgoing payment amounts to run the simulation on. In response to Murch's email, Daniel Weigl, from Mycelium, inquired about the behavior of Mycelium coin selection algorithm. Murch clarified that Mycelium selects UTXO in a FIFO approach, but prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems to be the likely reason for Mycelium's small UTXO build-up. BreadWallet uses a very similar FIFO approach, but doesn't prune which causes their average UTXO set to be much smaller. A balanced approach between these two approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, who is compiling his Master's thesis about Coin Selection, has created a framework to simulate wallet behavior on the basis of a sequence of payments. He re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF containing a two-page description of his ongoing work includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Daniel Weigl asked about Mycelium's large UTXO set for 5460sat (=TransactionUtils.MINIMUM_OUTPUT_VALUE). Murch replied that his simulation did add small change outputs to the fee, but he got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Murch corrected the boundary in his simulation now and will update his simulation results before Scaling Bitcoin. Regarding Mycelium, Murch stated that it doesn't create small change outputs but rather hardly ever spends them when received. It appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up. A balanced approach between BreadWallet's and Mycelium's approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, a researcher, has compiled his Master's thesis about Coin Selection and his presentation proposal to Scaling Bitcoin has been accepted. In his thesis, he analyzed the Coin Selection problem, created a framework to simulate wallet behavior on the basis of a sequence of payments, and re-implemented multiple coin selection strategies of prominent Bitcoin wallets such as Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF contains a two-page - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_Proposed-BIP-1-change-removing-OPL-licensing-option-.xml b/static/bitcoin-dev/Sept_2016/combined_Proposed-BIP-1-change-removing-OPL-licensing-option-.xml index e451349585..4558224f67 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Proposed-BIP-1-change-removing-OPL-licensing-option-.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Proposed-BIP-1-change-removing-OPL-licensing-option-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed BIP-1 change removing OPL licensing option. - 2023-08-01T19:05:11.027398+00:00 + 2025-09-26T16:00:27.618264+00:00 + python-feedgen Peter Todd 2016-09-27 19:17:07+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Proposed BIP-1 change removing OPL licensing option. - 2023-08-01T19:05:11.027398+00:00 + 2025-09-26T16:00:27.618401+00:00 - In a Bitcoin developer email thread, Peter Todd expressed concerns about the Open Patent License (OPL) being more restrictive than the Bitcoin Core license and its potential impact on shipping documentation with code. He acknowledged that different licenses for documentation and code are common practice but emphasized that the issue lies in the OPL's significant restrictions. Peter suggested considering Luke's BIP2 revival proposal as a more formal solution. Tom, in response, recommended dual-licensing documentation with a code-oriented license if it includes example code. He also announced that his own BIP is now dual-licensed under the Creative Commons license. Peter appreciated the suggestion and agreed that CC-BY-SA is a suitable license for this purpose.A revision to BIP-1 proposes removing the option to license work under the OPL. The OPL contains clauses that allow licensors to prohibit print publication and creation of modified versions without their approval. These attribution requirements are considered too restrictive by Debian, leading them to not consider the OPL acceptable for works included in their distribution. Only two BIPs, BIP145 and BIP134, have used the OPL. It is noted that the OPL is significantly more restrictive than the Bitcoin Core license, which poses challenges if documentation cannot be shipped with the code.The proposal to revise BIP-1 aims to eliminate the option to license work under the OPL due to its problematic clauses. Instead, it suggests incorporating a permissive 2-clause BSD license as an alternative. The author of the proposal questions whether those involved in the project were aware of these clauses when including them. They believe that the OPL hinders a transparent, public, and collaborative process for developing interoperability standards. The project that created the OPL has recommended using Creative Commons licenses since 2007 as a more suitable alternative. 2016-09-27T19:17:07+00:00 + In a Bitcoin developer email thread, Peter Todd expressed concerns about the Open Patent License (OPL) being more restrictive than the Bitcoin Core license and its potential impact on shipping documentation with code. He acknowledged that different licenses for documentation and code are common practice but emphasized that the issue lies in the OPL's significant restrictions. Peter suggested considering Luke's BIP2 revival proposal as a more formal solution. Tom, in response, recommended dual-licensing documentation with a code-oriented license if it includes example code. He also announced that his own BIP is now dual-licensed under the Creative Commons license. Peter appreciated the suggestion and agreed that CC-BY-SA is a suitable license for this purpose.A revision to BIP-1 proposes removing the option to license work under the OPL. The OPL contains clauses that allow licensors to prohibit print publication and creation of modified versions without their approval. These attribution requirements are considered too restrictive by Debian, leading them to not consider the OPL acceptable for works included in their distribution. Only two BIPs, BIP145 and BIP134, have used the OPL. It is noted that the OPL is significantly more restrictive than the Bitcoin Core license, which poses challenges if documentation cannot be shipped with the code.The proposal to revise BIP-1 aims to eliminate the option to license work under the OPL due to its problematic clauses. Instead, it suggests incorporating a permissive 2-clause BSD license as an alternative. The author of the proposal questions whether those involved in the project were aware of these clauses when including them. They believe that the OPL hinders a transparent, public, and collaborative process for developing interoperability standards. The project that created the OPL has recommended using Creative Commons licenses since 2007 as a more suitable alternative. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_Requesting-BIP-assignment-Flexible-Transactions-.xml b/static/bitcoin-dev/Sept_2016/combined_Requesting-BIP-assignment-Flexible-Transactions-.xml index a14af295a0..fff950434c 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Requesting-BIP-assignment-Flexible-Transactions-.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Requesting-BIP-assignment-Flexible-Transactions-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Requesting BIP assignment; Flexible Transactions. - 2023-08-01T19:02:14.906564+00:00 + 2025-09-26T16:00:42.661554+00:00 + python-feedgen Tom 2016-09-23 13:17:52+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Requesting BIP assignment; Flexible Transactions. - 2023-08-01T19:02:14.907564+00:00 + 2025-09-26T16:00:42.661721+00:00 - There are ongoing discussions in the Bitcoin community about options for serializing transactions. Two options being considered are Protocol Buffers (protobuf) and Compact Message Format (CMF). CMF is already used in Bitcoin Classic transactions and offers advantages such as reusing var-int parsing and better error reporting. Additionally, CMF is more compact and requires less tool support than protobuf.There is a suggestion to use Protobuf based on a BIP (Bitcoin Improvement Proposal), as it is compact, binary, and flexible. The payment protocol already uses Protobuf, making it an attractive option for further implementation. Protobuf also has good tool support.In an email exchange between Peter Todd and Tom, the issue of serializing transactions in a certain order is discussed. Tom believes that if the order of tokens is not fixed, it could lead to multiple interpretations of data, which is not allowed. Peter Todd suggests using a "Some/None" flag to mark whether optional data has been omitted, instead of fixed token orders. This suggestion is already addressed in the spec, which uses a generic concept where each field is given a name. Peter Todd also suggests extending the merkle tree down into transaction inputs and outputs.Tom, a member of the bitcoin-dev mailing list, requests a BIP number for his Flexible Transactions (FT) specification. He is advised to open a pull request on the bitcoin/bips repository after further discussion. The new version of 'script' (version 2) simplifies the data signed to be equivalent to the transaction-id. However, some functionality is lost, leading to questions about replacing SIGHASH_SINGLE and SIGHASH_ANYONECANPAY. It is suggested to add the ability to use only a hash of the prevout's scriptPubKey in the input. The token ScriptVersion is currently not allowed, but addressing block-malleability by extending the merkle tree to include the hash of v4 transactions alone is proposed.In another bitcoin-dev email thread, Tom discusses the serialization order of tokens in transactions and the need for a fixed order to avoid multiple interpretations. He suggests using a flag for optional data. Compatibility with existing software and extending the merkle tree into transaction inputs and outputs are also discussed.Tom formally requests the assignment of a BIP number for his FT spec, titled "Flexible Transactions." The proposal aims to make Bitcoin's transactions more flexible and easier to extend while fixing malleability issues and resolving technical debt. It introduces a new version number (4) and defines the use of Compact Message Format (CMF) for data following the version bytes. The proposal allows for new features to be added more cleanly in the future and shows that signatures can be removed from transactions with minimal software upgrades. The proposal specifies the serialization order for well-formatted transactions and includes changes to Bitcoin-script. The reference implementation can be found in Bitcoin Classic beta releases, but the deployment process is yet to be determined. 2016-09-23T13:17:52+00:00 + There are ongoing discussions in the Bitcoin community about options for serializing transactions. Two options being considered are Protocol Buffers (protobuf) and Compact Message Format (CMF). CMF is already used in Bitcoin Classic transactions and offers advantages such as reusing var-int parsing and better error reporting. Additionally, CMF is more compact and requires less tool support than protobuf.There is a suggestion to use Protobuf based on a BIP (Bitcoin Improvement Proposal), as it is compact, binary, and flexible. The payment protocol already uses Protobuf, making it an attractive option for further implementation. Protobuf also has good tool support.In an email exchange between Peter Todd and Tom, the issue of serializing transactions in a certain order is discussed. Tom believes that if the order of tokens is not fixed, it could lead to multiple interpretations of data, which is not allowed. Peter Todd suggests using a "Some/None" flag to mark whether optional data has been omitted, instead of fixed token orders. This suggestion is already addressed in the spec, which uses a generic concept where each field is given a name. Peter Todd also suggests extending the merkle tree down into transaction inputs and outputs.Tom, a member of the bitcoin-dev mailing list, requests a BIP number for his Flexible Transactions (FT) specification. He is advised to open a pull request on the bitcoin/bips repository after further discussion. The new version of 'script' (version 2) simplifies the data signed to be equivalent to the transaction-id. However, some functionality is lost, leading to questions about replacing SIGHASH_SINGLE and SIGHASH_ANYONECANPAY. It is suggested to add the ability to use only a hash of the prevout's scriptPubKey in the input. The token ScriptVersion is currently not allowed, but addressing block-malleability by extending the merkle tree to include the hash of v4 transactions alone is proposed.In another bitcoin-dev email thread, Tom discusses the serialization order of tokens in transactions and the need for a fixed order to avoid multiple interpretations. He suggests using a flag for optional data. Compatibility with existing software and extending the merkle tree into transaction inputs and outputs are also discussed.Tom formally requests the assignment of a BIP number for his FT spec, titled "Flexible Transactions." The proposal aims to make Bitcoin's transactions more flexible and easier to extend while fixing malleability issues and resolving technical debt. It introduces a new version number (4) and defines the use of Compact Message Format (CMF) for data following the version bytes. The proposal allows for new features to be added more cleanly in the future and shows that signatures can be removed from transactions with minimal software upgrades. The proposal specifies the serialization order for well-formatted transactions and includes changes to Bitcoin-script. The reference implementation can be found in Bitcoin Classic beta releases, but the deployment process is yet to be determined. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml b/static/bitcoin-dev/Sept_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml index 57bb48274e..1c621de6d4 100644 --- a/static/bitcoin-dev/Sept_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml +++ b/static/bitcoin-dev/Sept_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ScalingBitcoin 2015: Retarget - Call For Proposals Now Open - 2023-08-01T18:48:10.467162+00:00 + 2025-09-26T16:00:25.472532+00:00 + python-feedgen Matt Corallo 2016-09-01 00:56:08+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - ScalingBitcoin 2015: Retarget - Call For Proposals Now Open - 2023-08-01T18:48:10.467162+00:00 + 2025-09-26T16:00:25.472667+00:00 - The Scaling Bitcoin 2016: Retarget conference has extended its deadline for submissions to September 9th. This year, the conference is offering rolling acceptance in an effort to respond to most proposals before September 23rd. The conference defines "scaling" broadly, encompassing topics such as improving Bitcoin throughput, layer 2 ideas, security and privacy, incentives and fee structures, testing, simulation and modeling, network resilience and latency, fungibility, anti-spam measures, block size proposals, and mining concerns.The Call for Proposals (CFP) was opened on August 2nd and can be found on the scalingbitcoin.org website. Interested parties who wish to submit their proposals have until September 2nd to do so. After the submission deadline, applicants will be notified of their acceptance status by September 23rd. The Scaling Bitcoin 2016: Retarget conference will take place in Milan on October 8th and 9th. For more information and to access the CFP, interested individuals can visit the scalingbitcoin.org website. 2016-09-01T00:56:08+00:00 + The Scaling Bitcoin 2016: Retarget conference has extended its deadline for submissions to September 9th. This year, the conference is offering rolling acceptance in an effort to respond to most proposals before September 23rd. The conference defines "scaling" broadly, encompassing topics such as improving Bitcoin throughput, layer 2 ideas, security and privacy, incentives and fee structures, testing, simulation and modeling, network resilience and latency, fungibility, anti-spam measures, block size proposals, and mining concerns.The Call for Proposals (CFP) was opened on August 2nd and can be found on the scalingbitcoin.org website. Interested parties who wish to submit their proposals have until September 2nd to do so. After the submission deadline, applicants will be notified of their acceptance status by September 23rd. The Scaling Bitcoin 2016: Retarget conference will take place in Milan on October 8th and 9th. For more information and to access the CFP, interested individuals can visit the scalingbitcoin.org website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_Simple-tx-ID-malleability-fix-opcode-proposal-OP-TXHASHVERIFY.xml b/static/bitcoin-dev/Sept_2016/combined_Simple-tx-ID-malleability-fix-opcode-proposal-OP-TXHASHVERIFY.xml index 8fbce822d0..aa9408eedb 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Simple-tx-ID-malleability-fix-opcode-proposal-OP-TXHASHVERIFY.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Simple-tx-ID-malleability-fix-opcode-proposal-OP-TXHASHVERIFY.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY - 2023-08-01T19:00:49.596515+00:00 + 2025-09-26T16:00:44.846311+00:00 + python-feedgen Nick ODell 2016-09-17 22:34:43+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY - 2023-08-01T19:00:49.596515+00:00 + 2025-09-26T16:00:44.846494+00:00 - Rune K. Svendsen has proposed a solution to address transaction ID malleability in the bitcoin-dev mailing list. The solution involves introducing a new opcode called OP_TXHASHVERIFY. This opcode would only work if added as the very first operation in a scriptSig. If the hash of the transaction with all OP_TXHASHVERIFY operations removed does not match what has been pushed on the stack, the operation will be aborted.To protect against tx ID malleability, one would need to calculate the tx ID of the transaction and add "0x32 $TX_HASH OP_TXHASHVERIFY" to the beginning of the scriptSig for each input they wish to protect. This solution adds 34 bytes per input. However, it is considered a simple and valuable solution until something better becomes available, such as Segwit.Matt Corallo pointed out that the tx hash in the construction is not signed, which means someone could manipulate a transaction by updating the hash in the scriptSig. Another issue raised by Nick is the circular dependency between Hash1 and Hash2. Rune replied that there is a solution, but it complicates the operation.Overall, the proposed solution by Rune K. Svendsen offers a way to create transactions that are immune to transaction ID malleability. It involves adding a new opcode called OP_TXHASHVERIFY to the scriptSig. Although there are some concerns raised, the solution is seen as valuable in addressing tx ID malleability until a better solution, like Segwit, becomes available. Feedback on the proposal is requested. 2016-09-17T22:34:43+00:00 + Rune K. Svendsen has proposed a solution to address transaction ID malleability in the bitcoin-dev mailing list. The solution involves introducing a new opcode called OP_TXHASHVERIFY. This opcode would only work if added as the very first operation in a scriptSig. If the hash of the transaction with all OP_TXHASHVERIFY operations removed does not match what has been pushed on the stack, the operation will be aborted.To protect against tx ID malleability, one would need to calculate the tx ID of the transaction and add "0x32 $TX_HASH OP_TXHASHVERIFY" to the beginning of the scriptSig for each input they wish to protect. This solution adds 34 bytes per input. However, it is considered a simple and valuable solution until something better becomes available, such as Segwit.Matt Corallo pointed out that the tx hash in the construction is not signed, which means someone could manipulate a transaction by updating the hash in the scriptSig. Another issue raised by Nick is the circular dependency between Hash1 and Hash2. Rune replied that there is a solution, but it complicates the operation.Overall, the proposed solution by Rune K. Svendsen offers a way to create transactions that are immune to transaction ID malleability. It involves adding a new opcode called OP_TXHASHVERIFY to the scriptSig. Although there are some concerns raised, the solution is seen as valuable in addressing tx ID malleability until a better solution, like Segwit, becomes available. Feedback on the proposal is requested. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_-BIP-Proposal-Token-Protocol-Specification.xml b/static/bitcoin-dev/Sept_2017/combined_-BIP-Proposal-Token-Protocol-Specification.xml index f7aa82cf19..648a9dda43 100644 --- a/static/bitcoin-dev/Sept_2017/combined_-BIP-Proposal-Token-Protocol-Specification.xml +++ b/static/bitcoin-dev/Sept_2017/combined_-BIP-Proposal-Token-Protocol-Specification.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - [BIP Proposal] Token Protocol Specification - 2023-08-01T21:45:42.893863+00:00 - - Alex Kravets 2017-09-08 08:06:01+00:00 - - - Luca Venturini 2017-09-06 19:25:16+00:00 - - - Luke Dashjr 2017-09-06 18:58:44+00:00 - - - Luca Venturini 2017-09-06 18:32:47+00:00 - - - Luca Venturini 2017-09-06 15:44:47+00:00 - + 2025-09-26T15:49:11.467424+00:00 + python-feedgen + + + [bitcoin-dev] [BIP Proposal] Token Protocol Specification Luca Venturini + 2017-09-06T15:44:00.000Z + + + Luca Venturini + 2017-09-06T18:32:00.000Z + + + Luke Dashjr + 2017-09-06T18:58:00.000Z + + + Luca Venturini + 2017-09-06T19:25:00.000Z + + + Alex Kravets + 2017-09-08T08:06:00.000Z + + - python-feedgen + 2 Combined summary - [BIP Proposal] Token Protocol Specification - 2023-08-01T21:45:42.893863+00:00 + 2025-09-26T15:49:11.468101+00:00 - Luca Venturini has proposed a protocol for managing digital assets, or tokens, on the Bitcoin blockchain. The protocol allows bitcoin transactions to be interpreted as operations related to tokens and provides plausible deniability for both issuers and users. Tokens can be managed using any existing Bitcoin wallet without the need for a dedicated one.The protocol enables atomic buy and sell transactions between tokens and Bitcoin, as well as between different types of tokens. Tokens can be infinitely split into parts with no specified number of decimals, and token issuance involves various types of transactions such as offering issuance, split and join, and atomic exchange transactions.In a use case scenario, Alice, Bob, Charlie, and Daniel start a company and issue tokens. Shareholders can freely resell their shares to others. Transactions are made to distribute shares to recipients and facilitate sales between shareholders.The protocol is designed based on the structure of sorted outputs in a Bitcoin transaction. Token generation is determined by the sum of signals of all outputs, with the last output having the power to generate new tokens. Tokens are assigned to outputs based on their signal value.The document explains the transaction format for token issuance and transfer, including those generated from split and join transactions. It also introduces atomic exchange transactions where tokens and bitcoins can be exchanged simultaneously in a single transaction.Cross-token atomic transactions allow for the exchange of tokens between parties, even if they have different values. Guidelines are provided for managing tokens using any existing wallet, including the use of consolidated wallets. Tokens can be generated, transferred, and closed using specific methods.Technical notes are included on consolidated wallets, UTXOs, and transactions. A reference implementation will be provided once the protocol is reviewed and accepted by the community.Luca responds to feedback on his protocol, clarifying that plausible deniability is a property of the protocol that will be approved as a BIP. Wallets that manage tokens will be available, but vanity addresses are not mandatory for plausible deniability. Sending bitcoin along with tokens is straightforward, and the state of tokens is fully contained in the Bitcoin blockchain.Luca addresses concerns about consolidation, memorable names for tokens, and plausible deniability. He explains that small outputs are not necessary since bitcoin value is transferred along with token value. The design aims to reduce UTXOs, and there is no need for a special wallet.The proposal highlights that the protocol allows for atomic buy and sell transactions between tokens, Bitcoin, and different types of tokens. It does not require dedicated wallets or verification nodes and minimizes blockchain pollution.Tokens are stored in unspent Bitcoin outputs and can have multiple names, including vanity token names. Tokens are never burned or deleted, and issuance chains ensure no duplicate tokens are issued.The document provides detailed explanations of token offering issuance, atomic exchange, and cross-token atomic transactions. It outlines the formats and rules for assigning tokens to outputs and describes split and join transactions for creating new tokens or splitting existing ones.Users can prove to be the issuer by signing a message using the Bitcoin protocol. A reference implementation will be included once the protocol is reviewed and accepted by the community. 2017-09-08T08:06:01+00:00 + Luca Venturini has proposed a protocol for managing digital assets, or tokens, on the Bitcoin blockchain. The protocol allows bitcoin transactions to be interpreted as operations related to tokens and provides plausible deniability for both issuers and users. Tokens can be managed using any existing Bitcoin wallet without the need for a dedicated one.The protocol enables atomic buy and sell transactions between tokens and Bitcoin, as well as between different types of tokens. Tokens can be infinitely split into parts with no specified number of decimals, and token issuance involves various types of transactions such as offering issuance, split and join, and atomic exchange transactions.In a use case scenario, Alice, Bob, Charlie, and Daniel start a company and issue tokens. Shareholders can freely resell their shares to others. Transactions are made to distribute shares to recipients and facilitate sales between shareholders.The protocol is designed based on the structure of sorted outputs in a Bitcoin transaction. Token generation is determined by the sum of signals of all outputs, with the last output having the power to generate new tokens. Tokens are assigned to outputs based on their signal value.The document explains the transaction format for token issuance and transfer, including those generated from split and join transactions. It also introduces atomic exchange transactions where tokens and bitcoins can be exchanged simultaneously in a single transaction.Cross-token atomic transactions allow for the exchange of tokens between parties, even if they have different values. Guidelines are provided for managing tokens using any existing wallet, including the use of consolidated wallets. Tokens can be generated, transferred, and closed using specific methods.Technical notes are included on consolidated wallets, UTXOs, and transactions. A reference implementation will be provided once the protocol is reviewed and accepted by the community.Luca responds to feedback on his protocol, clarifying that plausible deniability is a property of the protocol that will be approved as a BIP. Wallets that manage tokens will be available, but vanity addresses are not mandatory for plausible deniability. Sending bitcoin along with tokens is straightforward, and the state of tokens is fully contained in the Bitcoin blockchain.Luca addresses concerns about consolidation, memorable names for tokens, and plausible deniability. He explains that small outputs are not necessary since bitcoin value is transferred along with token value. The design aims to reduce UTXOs, and there is no need for a special wallet.The proposal highlights that the protocol allows for atomic buy and sell transactions between tokens, Bitcoin, and different types of tokens. It does not require dedicated wallets or verification nodes and minimizes blockchain pollution.Tokens are stored in unspent Bitcoin outputs and can have multiple names, including vanity token names. Tokens are never burned or deleted, and issuance chains ensure no duplicate tokens are issued.The document provides detailed explanations of token offering issuance, atomic exchange, and cross-token atomic transactions. It outlines the formats and rules for assigning tokens to outputs and describes split and join transactions for creating new tokens or splitting existing ones.Users can prove to be the issuer by signing a message using the Bitcoin protocol. A reference implementation will be included once the protocol is reviewed and accepted by the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_-Compressed-headers-stream.xml b/static/bitcoin-dev/Sept_2017/combined_-Compressed-headers-stream.xml index cbb837a94b..77951bdc12 100644 --- a/static/bitcoin-dev/Sept_2017/combined_-Compressed-headers-stream.xml +++ b/static/bitcoin-dev/Sept_2017/combined_-Compressed-headers-stream.xml @@ -1,47 +1,75 @@ - + 2 - Combined summary - "Compressed" headers stream - 2023-08-01T21:30:19.625066+00:00 - - Gregory Maxwell 2017-12-13 00:12:45+00:00 - - - Gregory Maxwell 2017-12-13 00:01:32+00:00 - - - Suhas Daftuar 2017-12-12 21:07:11+00:00 - - - Gregory Maxwell 2017-12-11 23:11:24+00:00 - - - Tier Nolan 2017-12-11 22:41:50+00:00 - - - Jim Posen 2017-12-11 21:56:08+00:00 - - - Gregory Maxwell 2017-12-11 21:04:01+00:00 - - - Jim Posen 2017-12-11 20:40:00+00:00 - - - Peter Todd 2017-09-04 14:10:17+00:00 - - - Greg Sanders 2017-08-28 16:26:48+00:00 - - - Riccardo Casatta 2017-08-28 16:25:01+00:00 - - - Greg Sanders 2017-08-28 16:13:11+00:00 - - - Riccardo Casatta 2017-08-28 15:50:23+00:00 - + Combined summary - "Compressed" headers stream + 2025-09-26T15:48:25.169489+00:00 + python-feedgen + + + Riccardo Casatta + 2017-08-28T15:50:00.000Z + + + Greg Sanders + 2017-08-28T16:13:00.000Z + + + Riccardo Casatta + 2017-08-28T16:25:00.000Z + + + Greg Sanders + 2017-08-28T16:26:00.000Z + + + [bitcoin-dev] Fwd: " Gregory Maxwell + 2017-08-28T17:12:00.000Z + + + Kalle Rosenbaum + 2017-08-28T17:54:00.000Z + + + Peter Todd + 2017-09-04T14:06:00.000Z + + + Peter Todd + 2017-09-04T14:10:00.000Z + + + [bitcoin-dev] "Compressed" headers stream Jim Posen + 2017-12-11T20:40:00.000Z + + + Gregory Maxwell + 2017-12-11T21:04:00.000Z + + + Jim Posen + 2017-12-11T21:56:00.000Z + + + Tier Nolan + 2017-12-11T22:41:00.000Z + + + Gregory Maxwell + 2017-12-11T23:11:00.000Z + + + Suhas Daftuar + 2017-12-12T21:07:00.000Z + + + Gregory Maxwell + 2017-12-13T00:01:00.000Z + + + Gregory Maxwell + 2017-12-13T00:12:00.000Z + + @@ -55,13 +83,13 @@ - python-feedgen + 2 - Combined summary - "Compressed" headers stream - 2023-08-01T21:30:19.625066+00:00 + Combined summary - "Compressed" headers stream + 2025-09-26T15:48:25.171383+00:00 - In a recent discussion among Bitcoin developers, Suhas Daftuar and Gregory Maxwell proposed the introduction of a new 'cmpctheaders'/'getcmpcthdrs' message pair for syncing, while keeping the existing 'headers'/'getheaders' messages unchanged. The idea is to never use 'getheaders' messages when communicating with upgraded peers and only use 'headers' messages for potentially announcing new blocks. Peers would fetch headers based on a weak heuristic where they fetch first from those with the tip at the highest difficulty and then work backwards. This proposal also mentions the possibility of changing the interface. [source]Another topic of discussion among Bitcoin developers is the inclusion of nBits in p2p messages without requiring the consensus-correct calculation of nBits. The purpose is to calculate the work on a chain as an anti-DoS measure. It is suggested that nBits could be included in any messages where the value is ambiguous, such as with the first header in a message and whenever it changes from the previous header's nBits. The serialization of existing messages should not be changed, so a new 'cmpctheaders'/'getcmpcthdrs' message pair could be introduced for syncing using this new message type. When communicating with upgraded peers, 'getheaders' messages would never be used, and only 'headers' messages would be used for potentially announcing new blocks. The splitting off of headers chain-sync functionality to a new message pair is seen as a nice side-effect benefit in the long run. [source]Tier Nolan shared a method called "high hash highway" in a Bitcoin-dev discussion, which allows compact proofs of total Proof-of-Work (POW). However, it was deemed off-topic as it provides no security without additional consensus enforced commitments. [source]Jim Posen proposed omitting nBits entirely in Bitcoin headers to save an extra 4 bytes. However, this could lead to more complexity in the validation code. As a compromise, Posen suggested using a one-byte flag to indicate the difference since the last header and stealing bits from the exponent to indicate mode. This approach would save three of the four bytes. Posen also proposed parallel header fetching, where nodes could request the lowest N hashes between two heights on the main chain and receive pairs of {height, header} for the N headers with the lowest hash in the specified range. [source]There is a proposal to reduce the bandwidth needed for Bitcoin header messages by removing the nBits field, which contains difficulty information. The proposal has received criticism for being too dependent on specific validation rules of the Bitcoin protocol. However, supporters argue that omitting nBits saves bytes and is worth the extra complexity in validation code. The discussion also covers the need to encode leading bits of prev, which are used as an extra nonce for miners. While some altcoins have already changed their header structures, making the proposed change possibly incompatible, supporters argue that it would be worth it to competitively advance Bitcoin. Additionally, the possibility of parallel header fetching to optimize header download is discussed. [source]In a Bitcoin-dev mailing list discussion, Greg Sanders raised a question about the use-case of timestamping in Bitcoin. Peter Todd responded by explaining that timestamping can be more vulnerable to malicious miners than financial applications due to the lack of a financial feedback loop. He also noted that timestamping is a non-financial piggy-back application that does not directly interact with the Bitcoin economy beyond a trivial number of timestamp transactions. [source]Riccardo Casatta proposed an optimization for transmitting Bitcoin block headers in a recent email on the Bitcoin-dev mailing list. The proposal suggests that after the first header, subsequent headers need not transmit the previous hash as the receiver can compute it by double hashing the previous header. This optimization could save about 40% bandwidth in a long stream of headers. Casatta believes this optimization could be particularly useful in instances where full node security isn't feasible, such as when dealing with private databases that require timestamping. He also suggests using fixed position chunks in an HTTP API to leverage HTTP caching and speed up synchronization for new clients. [source]In the Bitcoin-dev email thread, Jim Posen expressed his dislike of making the net header encoding dependent on specific header validation rules used by Bitcoin. He proposed a one-byte flag on each header to indicate what was included, suggesting that nBits does not need to be sent even with other consensus rules since it is more or less necessarily a strict function of the prior headers. Posen believes that another >18% reduction in size beyond the removal of prev is significant and should not be ignored. However, Prev omission itself is not compatible, and Posen suggests that if there is a Bitcoin hardfork, it would recover the necessary bits from prev to use as an extra nonce for miners. Many altcoins have also changed their header structures, so even if the proposed change is altcoin incompatible, it should still be considered. Changing the serialization of 2017-12-13T00:12:45+00:00 + In a recent discussion among Bitcoin developers, Suhas Daftuar and Gregory Maxwell proposed the introduction of a new 'cmpctheaders'/'getcmpcthdrs' message pair for syncing, while keeping the existing 'headers'/'getheaders' messages unchanged. The idea is to never use 'getheaders' messages when communicating with upgraded peers and only use 'headers' messages for potentially announcing new blocks. Peers would fetch headers based on a weak heuristic where they fetch first from those with the tip at the highest difficulty and then work backwards. This proposal also mentions the possibility of changing the interface. [source]Another topic of discussion among Bitcoin developers is the inclusion of nBits in p2p messages without requiring the consensus-correct calculation of nBits. The purpose is to calculate the work on a chain as an anti-DoS measure. It is suggested that nBits could be included in any messages where the value is ambiguous, such as with the first header in a message and whenever it changes from the previous header's nBits. The serialization of existing messages should not be changed, so a new 'cmpctheaders'/'getcmpcthdrs' message pair could be introduced for syncing using this new message type. When communicating with upgraded peers, 'getheaders' messages would never be used, and only 'headers' messages would be used for potentially announcing new blocks. The splitting off of headers chain-sync functionality to a new message pair is seen as a nice side-effect benefit in the long run. [source]Tier Nolan shared a method called "high hash highway" in a Bitcoin-dev discussion, which allows compact proofs of total Proof-of-Work (POW). However, it was deemed off-topic as it provides no security without additional consensus enforced commitments. [source]Jim Posen proposed omitting nBits entirely in Bitcoin headers to save an extra 4 bytes. However, this could lead to more complexity in the validation code. As a compromise, Posen suggested using a one-byte flag to indicate the difference since the last header and stealing bits from the exponent to indicate mode. This approach would save three of the four bytes. Posen also proposed parallel header fetching, where nodes could request the lowest N hashes between two heights on the main chain and receive pairs of {height, header} for the N headers with the lowest hash in the specified range. [source]There is a proposal to reduce the bandwidth needed for Bitcoin header messages by removing the nBits field, which contains difficulty information. The proposal has received criticism for being too dependent on specific validation rules of the Bitcoin protocol. However, supporters argue that omitting nBits saves bytes and is worth the extra complexity in validation code. The discussion also covers the need to encode leading bits of prev, which are used as an extra nonce for miners. While some altcoins have already changed their header structures, making the proposed change possibly incompatible, supporters argue that it would be worth it to competitively advance Bitcoin. Additionally, the possibility of parallel header fetching to optimize header download is discussed. [source]In a Bitcoin-dev mailing list discussion, Greg Sanders raised a question about the use-case of timestamping in Bitcoin. Peter Todd responded by explaining that timestamping can be more vulnerable to malicious miners than financial applications due to the lack of a financial feedback loop. He also noted that timestamping is a non-financial piggy-back application that does not directly interact with the Bitcoin economy beyond a trivial number of timestamp transactions. [source]Riccardo Casatta proposed an optimization for transmitting Bitcoin block headers in a recent email on the Bitcoin-dev mailing list. The proposal suggests that after the first header, subsequent headers need not transmit the previous hash as the receiver can compute it by double hashing the previous header. This optimization could save about 40% bandwidth in a long stream of headers. Casatta believes this optimization could be particularly useful in instances where full node security isn't feasible, such as when dealing with private databases that require timestamping. He also suggests using fixed position chunks in an HTTP API to leverage HTTP caching and speed up synchronization for new clients. [source]In the Bitcoin-dev email thread, Jim Posen expressed his dislike of making the net header encoding dependent on specific header validation rules used by Bitcoin. He proposed a one-byte flag on each header to indicate what was included, suggesting that nBits does not need to be sent even with other consensus rules since it is more or less necessarily a strict function of the prior headers. Posen believes that another >18% reduction in size beyond the removal of prev is significant and should not be ignored. However, Prev omission itself is not compatible, and Posen suggests that if there is a Bitcoin hardfork, it would recover the necessary bits from prev to use as an extra nonce for miners. Many altcoins have also changed their header structures, so even if the proposed change is altcoin incompatible, it should still be considered. Changing the serialization of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_2-softforks-to-cut-the-blockchain-and-IBD-time.xml b/static/bitcoin-dev/Sept_2017/combined_2-softforks-to-cut-the-blockchain-and-IBD-time.xml index 7b947ef433..abb9794b09 100644 --- a/static/bitcoin-dev/Sept_2017/combined_2-softforks-to-cut-the-blockchain-and-IBD-time.xml +++ b/static/bitcoin-dev/Sept_2017/combined_2-softforks-to-cut-the-blockchain-and-IBD-time.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - 2 softforks to cut the blockchain and IBD time - 2023-08-01T21:52:03.122157+00:00 - - Tier Nolan 2017-09-13 09:09:52+00:00 - - - michele terzi 2017-09-12 22:58:35+00:00 - + 2025-09-26T15:49:00.907667+00:00 + python-feedgen + + + [bitcoin-dev] 2 softforks to cut the blockchain and IBD time michele terzi + 2017-09-12T22:58:00.000Z + + + Tier Nolan + 2017-09-13T09:09:00.000Z + + - python-feedgen + 2 Combined summary - 2 softforks to cut the blockchain and IBD time - 2023-08-01T21:52:03.122157+00:00 + 2025-09-26T15:49:00.908083+00:00 - The proposal put forward suggests a new method to synchronize nodes with the Bitcoin blockchain, offering advantages such as faster syncing, reduced disk space usage, and the option for slow downloading of remaining blocks. This would be achieved through the implementation of new protocol messages that facilitate requesting and sending the UTXO set. A new services bit called NODE_NETWORK_RECENT would indicate if a node possesses all blocks since the most recent snapshot. To prevent network partitions caused by re-orgs, soft checkpoints are proposed. Security concerns are addressed in the proposal, stating that soft forks are inherently backward compatible and cannot result in coin theft. In order to maintain archive nodes, it is recommended that blocks should not be deleted unless they are at least three years old. Additionally, there should be a setting to specify the maximum amount of disk space utilized. The proposal highlights the importance of maintaining archive nodes to avoid network splits and ensure agreement on new network rules.Bitcoin's decentralization is hindered by the increasing size of the blockchain, which currently stands at 160GB. This discourages new participants from joining the network. To tackle this issue, two softforks are suggested. The first involves hashing a snapshot of the UTXO set periodically, while the second entails writing the UTXO hash in the consensus code after a certain time period, creating a new genesis block. These softforks offer benefits like faster syncing for new nodes, reduced disk space requirements for full non-pruning nodes, increased difficulty for future chain analysis, and a frozen old history in one new genesis block to prevent reorgs prior to that point. Ancillary advantages include cleaning up outdated consensus code.However, there are drawbacks to consider, including the consumption of a small amount of space on the blockchain, the need for every node to perform calculations, and the inability of full nodes with old software to sync with the existing network. To address security concerns, thorough testing and inspection of the proposed softforks will be conducted, with the process divided into two separate steps to allow for community testing. Once the first softfork is locked in, any mismatches in hashes would be easily identifiable.In summary, the proposed softforks aim to address the issue of Bitcoin's growing blockchain size, enabling easier synchronization and participation for new nodes while maintaining security measures. 2017-09-13T09:09:52+00:00 + The proposal put forward suggests a new method to synchronize nodes with the Bitcoin blockchain, offering advantages such as faster syncing, reduced disk space usage, and the option for slow downloading of remaining blocks. This would be achieved through the implementation of new protocol messages that facilitate requesting and sending the UTXO set. A new services bit called NODE_NETWORK_RECENT would indicate if a node possesses all blocks since the most recent snapshot. To prevent network partitions caused by re-orgs, soft checkpoints are proposed. Security concerns are addressed in the proposal, stating that soft forks are inherently backward compatible and cannot result in coin theft. In order to maintain archive nodes, it is recommended that blocks should not be deleted unless they are at least three years old. Additionally, there should be a setting to specify the maximum amount of disk space utilized. The proposal highlights the importance of maintaining archive nodes to avoid network splits and ensure agreement on new network rules.Bitcoin's decentralization is hindered by the increasing size of the blockchain, which currently stands at 160GB. This discourages new participants from joining the network. To tackle this issue, two softforks are suggested. The first involves hashing a snapshot of the UTXO set periodically, while the second entails writing the UTXO hash in the consensus code after a certain time period, creating a new genesis block. These softforks offer benefits like faster syncing for new nodes, reduced disk space requirements for full non-pruning nodes, increased difficulty for future chain analysis, and a frozen old history in one new genesis block to prevent reorgs prior to that point. Ancillary advantages include cleaning up outdated consensus code.However, there are drawbacks to consider, including the consumption of a small amount of space on the blockchain, the need for every node to perform calculations, and the inability of full nodes with old software to sync with the existing network. To address security concerns, thorough testing and inspection of the proposed softforks will be conducted, with the process divided into two separate steps to allow for community testing. Once the first softfork is locked in, any mismatches in hashes would be easily identifiable.In summary, the proposed softforks aim to address the issue of Bitcoin's growing blockchain size, enabling easier synchronization and participation for new nodes while maintaining security measures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Address-expiration-times-should-be-added-to-BIP-173.xml b/static/bitcoin-dev/Sept_2017/combined_Address-expiration-times-should-be-added-to-BIP-173.xml index 993ba70ba4..8d3fba1e54 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Address-expiration-times-should-be-added-to-BIP-173.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Address-expiration-times-should-be-added-to-BIP-173.xml @@ -1,92 +1,151 @@ - + 2 Combined summary - Address expiration times should be added to BIP-173 - 2023-08-01T21:56:58.706358+00:00 - - Gregory Maxwell 2017-09-29 17:25:18+00:00 - - - Peter Todd 2017-09-29 13:52:03+00:00 - - - Andreas Schildbach 2017-09-29 12:45:32+00:00 - - - Peter Todd 2017-09-29 09:55:37+00:00 - - - Andreas Schildbach 2017-09-29 08:44:11+00:00 - - - Sjors Provoost 2017-09-29 07:18:06+00:00 - - - Peter Todd 2017-09-29 02:18:46+00:00 - - - Gregory Maxwell 2017-09-29 02:06:54+00:00 - - - Peter Todd 2017-09-29 01:50:48+00:00 - - - Peter Todd 2017-09-29 01:45:43+00:00 - - - Luke Dashjr 2017-09-28 16:59:26+00:00 - - - Sjors Provoost 2017-09-28 15:45:47+00:00 - - - Andreas Schildbach 2017-09-28 15:06:56+00:00 - - - Sjors Provoost 2017-09-28 14:41:42+00:00 - - - Andreas Schildbach 2017-09-28 14:13:48+00:00 - - - Sjors Provoost 2017-09-28 12:43:05+00:00 - - - Andreas Schildbach 2017-09-28 10:09:59+00:00 - - - Gregory Maxwell 2017-09-28 00:58:30+00:00 - - - Gregory Maxwell 2017-09-28 00:22:13+00:00 - - - Peter Todd 2017-09-27 21:33:07+00:00 - - - Peter Todd 2017-09-27 21:20:18+00:00 - - - Peter Todd 2017-09-27 21:15:50+00:00 - - - CryptAxe 2017-09-27 20:19:48+00:00 - - - CryptAxe 2017-09-27 20:11:09+00:00 - - - Chris Priest 2017-09-27 19:35:33+00:00 - - - Mark Friedenbach 2017-09-27 19:03:44+00:00 - - - CryptAxe 2017-09-27 18:15:20+00:00 - - - Peter Todd 2017-09-27 16:06:54+00:00 - + 2025-09-26T15:49:07.230133+00:00 + python-feedgen + + + [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd + 2017-09-27T16:06:00.000Z + + + CryptAxe + 2017-09-27T18:15:00.000Z + + + Mark Friedenbach + 2017-09-27T19:03:00.000Z + + + Chris Priest + 2017-09-27T19:35:00.000Z + + + CryptAxe + 2017-09-27T20:11:00.000Z + + + CryptAxe + 2017-09-27T20:19:00.000Z + + + Nick Pudar + 2017-09-27T20:23:00.000Z + + + Mark Friedenbach + 2017-09-27T21:09:00.000Z + + + Peter Todd + 2017-09-27T21:15:00.000Z + + + Peter Todd + 2017-09-27T21:20:00.000Z + + + Peter Todd + 2017-09-27T21:33:00.000Z + + + Gregory Maxwell + 2017-09-28T00:22:00.000Z + + + Gregory Maxwell + 2017-09-28T00:58:00.000Z + + + Andreas Schildbach + 2017-09-28T10:09:00.000Z + + + Sjors Provoost + 2017-09-28T12:43:00.000Z + + + Andreas Schildbach + 2017-09-28T14:13:00.000Z + + + Sjors Provoost + 2017-09-28T14:41:00.000Z + + + Andreas Schildbach + 2017-09-28T15:06:00.000Z + + + Sjors Provoost + 2017-09-28T15:45:00.000Z + + + Luke Dashjr + 2017-09-28T16:59:00.000Z + + + [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd + 2017-09-29T01:45:00.000Z + + + Peter Todd + 2017-09-29T01:50:00.000Z + + + Gregory Maxwell + 2017-09-29T02:06:00.000Z + + + Peter Todd + 2017-09-29T02:18:00.000Z + + + [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks Peter Todd + 2017-09-29T02:55:00.000Z + + + Omar Shibli + 2017-09-29T04:21:00.000Z + + + Sjors Provoost + 2017-09-29T07:18:00.000Z + + + Andreas Schildbach + 2017-09-29T08:44:00.000Z + + + Peter Todd + 2017-09-29T09:55:00.000Z + + + Andreas Schildbach + 2017-09-29T12:45:00.000Z + + + Tomas + 2017-09-29T13:14:00.000Z + + + Peter Todd + 2017-09-29T13:52:00.000Z + + + Gregory Maxwell + 2017-09-29T17:25:00.000Z + + + Aymeric Vitte + 2017-09-29T17:40:00.000Z + + + Andreas Schildbach + 2017-09-30T15:33:00.000Z + + @@ -115,13 +174,13 @@ - python-feedgen + 2 Combined summary - Address expiration times should be added to BIP-173 - 2023-08-01T21:56:58.707358+00:00 + 2025-09-26T15:49:07.233682+00:00 - In a recent email exchange on the bitcoin-dev mailing list, concerns were raised about the security and attention to detail of Coinbase. It was discovered that their payment protocol SSL certificate had expired for several months, and this lack of communication from Coinbase regarding the issue has left some users feeling uneasy.Andreas Schildbach and Peter Todd engaged in a discussion about the use of payment protocol in Bitcoin addresses. Schildbach claimed that most merchant transactions and person-to-person transactions between Bitcoin wallet users use the payment protocol, while Todd disagreed, stating that he hadn't seen it used in ages.The idea of adding an expiration time to Bitcoin addresses was proposed by Peter Todd in the email thread. While Andreas Schildbach argued that the payment protocol already has an expiration time, Todd pointed out that it hasn't been widely adopted and doesn't cover all the use cases addressed by Bitcoin addresses. The discussion also touched on the potential downsides of making transactions invalid after the fact, including privacy concerns and the possibility of miners gaming the system.Another topic of discussion was the inclusion of the amount in Bitcoin addresses to prevent errors in payments. Todd suggested embedding the amount in the address checksum or in the address itself to ensure the correct amount is sent before the transaction proceeds.Gregory Maxwell and Peter Todd discussed the issue of address reuse, agreeing that it is a problem for privacy and operational reasons. However, they felt that adding features like dates and explicit amounts to address formats would be challenging and could slow down adoption due to debates over encodings and software requirements. They also mentioned the complexity of implementing multiple optional expiration dates and the potential for mismatched dates.Andreas Schildbach suggested that Bitcoin addresses should have an expiration time, even though the payment protocol already has this feature. Peter Todd supported the idea and shared his contact information with the recipients of the email.The discussion on the bitcoin-dev mailing list also delved into the compatibility of BIP-70 payment requests with bech32, a new address format introduced in Bitcoin SegWit. There were concerns about wallets being able to parse the expiry date from the script without violating the BIP70 specification. The conversation also touched on the complexity of having multiple optional expiration dates and the potential confusion caused by embedding amounts in addresses.In conclusion, the email exchanges on the bitcoin-dev mailing list covered various topics related to the security and functionality of Bitcoin addresses and payment protocols. The discussions highlighted concerns about the expiration time of addresses, the inclusion of amounts in addresses, the issue of address reuse, and the compatibility of different address formats with payment requests. The conversations provided insights into the challenges and considerations involved in implementing these features and improving the usability of Bitcoin transactions.Bitcoin developer Peter Todd has proposed adding an expiration time to the new BIP173 address format to address the issue of reusing old addresses. This practice can cause privacy and operational problems for services like exchanges. Todd suggests that wallets should consider addresses invalid as a destination for funds after the expiration time is reached. He also acknowledges that the concept of addresses is flawed and suggests they should be more like "payment codes" with short validity periods. Two options for resolution are suggested: hour or month. Hour resolution would provide up to 1914 years, while month resolution would provide up to 5458 years. Both options work well at the UI level, but hour-level precision could help reduce risks for services like exchanges. However, the proposal raises concerns about UI and terminology, which need to be addressed. Todd concludes by stating that every address should have an expiry and no address should be considered valid longer than the anticipated lifetime of the underlying cryptosystem. 2017-09-29T17:25:18+00:00 + In a recent email exchange on the bitcoin-dev mailing list, concerns were raised about the security and attention to detail of Coinbase. It was discovered that their payment protocol SSL certificate had expired for several months, and this lack of communication from Coinbase regarding the issue has left some users feeling uneasy.Andreas Schildbach and Peter Todd engaged in a discussion about the use of payment protocol in Bitcoin addresses. Schildbach claimed that most merchant transactions and person-to-person transactions between Bitcoin wallet users use the payment protocol, while Todd disagreed, stating that he hadn't seen it used in ages.The idea of adding an expiration time to Bitcoin addresses was proposed by Peter Todd in the email thread. While Andreas Schildbach argued that the payment protocol already has an expiration time, Todd pointed out that it hasn't been widely adopted and doesn't cover all the use cases addressed by Bitcoin addresses. The discussion also touched on the potential downsides of making transactions invalid after the fact, including privacy concerns and the possibility of miners gaming the system.Another topic of discussion was the inclusion of the amount in Bitcoin addresses to prevent errors in payments. Todd suggested embedding the amount in the address checksum or in the address itself to ensure the correct amount is sent before the transaction proceeds.Gregory Maxwell and Peter Todd discussed the issue of address reuse, agreeing that it is a problem for privacy and operational reasons. However, they felt that adding features like dates and explicit amounts to address formats would be challenging and could slow down adoption due to debates over encodings and software requirements. They also mentioned the complexity of implementing multiple optional expiration dates and the potential for mismatched dates.Andreas Schildbach suggested that Bitcoin addresses should have an expiration time, even though the payment protocol already has this feature. Peter Todd supported the idea and shared his contact information with the recipients of the email.The discussion on the bitcoin-dev mailing list also delved into the compatibility of BIP-70 payment requests with bech32, a new address format introduced in Bitcoin SegWit. There were concerns about wallets being able to parse the expiry date from the script without violating the BIP70 specification. The conversation also touched on the complexity of having multiple optional expiration dates and the potential confusion caused by embedding amounts in addresses.In conclusion, the email exchanges on the bitcoin-dev mailing list covered various topics related to the security and functionality of Bitcoin addresses and payment protocols. The discussions highlighted concerns about the expiration time of addresses, the inclusion of amounts in addresses, the issue of address reuse, and the compatibility of different address formats with payment requests. The conversations provided insights into the challenges and considerations involved in implementing these features and improving the usability of Bitcoin transactions.Bitcoin developer Peter Todd has proposed adding an expiration time to the new BIP173 address format to address the issue of reusing old addresses. This practice can cause privacy and operational problems for services like exchanges. Todd suggests that wallets should consider addresses invalid as a destination for funds after the expiration time is reached. He also acknowledges that the concept of addresses is flawed and suggests they should be more like "payment codes" with short validity periods. Two options for resolution are suggested: hour or month. Hour resolution would provide up to 1914 years, while month resolution would provide up to 5458 years. Both options work well at the UI level, but hour-level precision could help reduce risks for services like exchanges. However, the proposal raises concerns about UI and terminology, which need to be addressed. Todd concludes by stating that every address should have an expiry and no address should be considered valid longer than the anticipated lifetime of the underlying cryptosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_An-explanation-and-justification-of-the-tail-call-and-MBV-approach-to-MAST.xml b/static/bitcoin-dev/Sept_2017/combined_An-explanation-and-justification-of-the-tail-call-and-MBV-approach-to-MAST.xml index 9fa1e9ec2f..813422ca90 100644 --- a/static/bitcoin-dev/Sept_2017/combined_An-explanation-and-justification-of-the-tail-call-and-MBV-approach-to-MAST.xml +++ b/static/bitcoin-dev/Sept_2017/combined_An-explanation-and-justification-of-the-tail-call-and-MBV-approach-to-MAST.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - An explanation and justification of the tail-call and MBV approach to MAST - 2023-08-01T21:54:33.675027+00:00 - - Andreas M. Antonopoulos 2017-09-21 00:15:37+00:00 - - - Mark Friedenbach 2017-09-20 22:51:39+00:00 - + 2025-09-26T15:48:58.819631+00:00 + python-feedgen + + + [bitcoin-dev] An explanation and justification of the tail-call and MBV approach to MAST Mark Friedenbach + 2017-09-20T22:51:00.000Z + + + Andreas M. Antonopoulos + 2017-09-21T00:15:00.000Z + + - python-feedgen + 2 Combined summary - An explanation and justification of the tail-call and MBV approach to MAST - 2023-08-01T21:54:33.675027+00:00 + 2025-09-26T15:48:58.820053+00:00 - In this article, the use of Merklized Abstract Syntax Trees (MAST) in Bitcoin is explored. The author begins by discussing the execution of Pay-to-Script Hash (P2SH) and how it can be generalized beyond a single redeem script. The concept of implicit tail-call execution semantics is introduced, allowing for safe recursion by running scripts to the end. The article explains how this approach can be used to achieve MAST and how the MERKLEBRANCHVERIFY opcode simplifies the process.The MERKLEBRANCHVERIFY opcode is used to prove that a public key is part of a set used to construct a Merkle hash tree and checks its signature. This enables verification of any monotone Boolean function over combinations of public keys, making it applicable to various use cases. The author emphasizes the importance of permission-less innovation in Bitcoin consensus features and suggests using modularity and composition of simple yet powerful tools like MERKLEBRANCHVERIFY and single tail-call recursion to construct MAST with minimal changes to the consensus code.The article concludes by mentioning the efficiency gain of adopting a MAST template but recommends deploying MBV, tail-call, and overhauling the CHECKSIG operator before tackling an ideal MAST-supporting witness type. The author highlights the clear explanation provided on the MERKLEBRANCHVERIFY opcode and tail-call execution semantics, which are crucial for achieving MAST in Bitcoin.In recent weeks, developers have been educated on the MERKLEBRANCHVERIFY opcode and tail-call execution semantics, but there are concerns about the clarity of concepts presented in the Bitcoin Improvement Proposals (BIPs). The limitations of P2SH are discussed, and macro-op fusion is introduced as a way to generalize it. The article also touches on MAST with tail-call alone or general recursion.The author supports permission-less innovation and advocates for simplicity, modularity, and the ability of different tools to work together in Bitcoin consensus features. They propose that the primitives of tail-call and MAST enable complex features with minimal changes to the consensus code, allowing for unrestricted innovation. These primitives can be combined with other modular features to support various use cases beyond vanilla MAST.The article mentions multiple potential use cases for the proposed features, including honeypot bounties, split proofs, Wuille-Maxwell tree signatures, delegation, signature-time commitment, and reusable Lamport keys. The author argues against rigid templates that require workarounds for each future innovation and instead supports small, modular, incremental, and reusable changes that create a platform for innovation.Overall, the article provides a comprehensive explanation of the MERKLEBRANCHVERIFY opcode and tail-call execution semantics, highlighting their importance in achieving MAST in Bitcoin. It emphasizes the need for permission-less innovation and proposes the use of simple yet powerful tools to construct MAST while minimizing changes to the consensus code. 2017-09-21T00:15:37+00:00 + In this article, the use of Merklized Abstract Syntax Trees (MAST) in Bitcoin is explored. The author begins by discussing the execution of Pay-to-Script Hash (P2SH) and how it can be generalized beyond a single redeem script. The concept of implicit tail-call execution semantics is introduced, allowing for safe recursion by running scripts to the end. The article explains how this approach can be used to achieve MAST and how the MERKLEBRANCHVERIFY opcode simplifies the process.The MERKLEBRANCHVERIFY opcode is used to prove that a public key is part of a set used to construct a Merkle hash tree and checks its signature. This enables verification of any monotone Boolean function over combinations of public keys, making it applicable to various use cases. The author emphasizes the importance of permission-less innovation in Bitcoin consensus features and suggests using modularity and composition of simple yet powerful tools like MERKLEBRANCHVERIFY and single tail-call recursion to construct MAST with minimal changes to the consensus code.The article concludes by mentioning the efficiency gain of adopting a MAST template but recommends deploying MBV, tail-call, and overhauling the CHECKSIG operator before tackling an ideal MAST-supporting witness type. The author highlights the clear explanation provided on the MERKLEBRANCHVERIFY opcode and tail-call execution semantics, which are crucial for achieving MAST in Bitcoin.In recent weeks, developers have been educated on the MERKLEBRANCHVERIFY opcode and tail-call execution semantics, but there are concerns about the clarity of concepts presented in the Bitcoin Improvement Proposals (BIPs). The limitations of P2SH are discussed, and macro-op fusion is introduced as a way to generalize it. The article also touches on MAST with tail-call alone or general recursion.The author supports permission-less innovation and advocates for simplicity, modularity, and the ability of different tools to work together in Bitcoin consensus features. They propose that the primitives of tail-call and MAST enable complex features with minimal changes to the consensus code, allowing for unrestricted innovation. These primitives can be combined with other modular features to support various use cases beyond vanilla MAST.The article mentions multiple potential use cases for the proposed features, including honeypot bounties, split proofs, Wuille-Maxwell tree signatures, delegation, signature-time commitment, and reusable Lamport keys. The author argues against rigid templates that require workarounds for each future innovation and instead supports small, modular, incremental, and reusable changes that create a platform for innovation.Overall, the article provides a comprehensive explanation of the MERKLEBRANCHVERIFY opcode and tail-call execution semantics, highlighting their importance in achieving MAST in Bitcoin. It emphasizes the need for permission-less innovation and proposes the use of simple yet powerful tools to construct MAST while minimizing changes to the consensus code. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml b/static/bitcoin-dev/Sept_2017/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml index 7a240b4c19..93a7169dfd 100644 --- a/static/bitcoin-dev/Sept_2017/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml +++ b/static/bitcoin-dev/Sept_2017/combined_BIP-proposal-Dandelion-Privacy-Preserving-Transaction-Propagation.xml @@ -1,41 +1,47 @@ - + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 - - Giulia Fanti 2018-07-08 12:50:43+00:00 - - - Gregory Maxwell 2018-06-26 05:20:02+00:00 - - - Bradley Denby 2018-06-26 00:12:02+00:00 - - - Pieter Wuille 2018-06-12 01:05:14+00:00 - - - Bradley Denby 2018-06-11 14:31:09+00:00 - - - Pieter Wuille 2018-06-06 04:01:00+00:00 - - - Bradley Denby 2018-06-04 20:29:50+00:00 - - - Bradley Denby 2018-05-10 12:59:12+00:00 - - - Giulia Fanti 2017-09-21 02:10:29+00:00 - - - Gregory Maxwell 2017-06-13 01:00:50+00:00 - - - Andrew Miller 2017-06-12 14:46:23+00:00 - + 2025-09-26T15:48:54.637523+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation Bradley Denby + 2018-05-10T12:59:00.000Z + + + Bradley Denby + 2018-06-04T20:29:00.000Z + + + Pieter Wuille + 2018-06-06T04:01:00.000Z + + + Bradley Denby + 2018-06-11T14:31:00.000Z + + + Pieter Wuille + 2018-06-12T01:05:00.000Z + + + Bradley Denby + 2018-06-26T00:12:00.000Z + + + Gregory Maxwell + 2018-06-26T05:20:00.000Z + + + Neudecker, Till (TM) + 2018-07-05T14:50:00.000Z + + + Giulia Fanti + 2018-07-08T12:50:00.000Z + + @@ -47,13 +53,13 @@ - python-feedgen + 2 Combined summary - BIP proposal - Dandelion: Privacy Preserving Transaction Propagation - 2023-08-01T21:01:09.684056+00:00 + 2025-09-26T15:48:54.638747+00:00 - The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality 2018-07-08T12:50:43+00:00 + The Dandelion project is a privacy-enhancing solution for Bitcoin users that aims to provide formal anonymity guarantees. It prevents deanonymization of the network by routing transactions over a randomly selected path before diffusion. The team has completed additional theoretical analysis and simulations, built a working prototype, and written detailed documentation for the new implementation.They recommend 'per-inbound-edge' routing during the stem phase to block fingerprint attacks. The team also addresses concerns about periodic route shuffling interval, black-hole attacks, and the probabilistic nature of their guarantees.A discussion on the deployment of Dandelion relays suggests choosing relays regardless of whether they support Dandelion or not. Wallets may have a configuration option for stem forwarding, which will initially be hidden and set to off. The team believes this approach is sufficient to select Dandelion-capable out-peers without harm. They plan to prioritize writing a clearer specification for node behavior in the BIP.Pieter Wuille and Bradley Denby discuss Dandelion node behavior and raise concerns about malicious nodes exploiting routing decisions based on self-reported features. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. Stem orphans can be resolved by re-broadcasting previous unfluffed transactions or waiting for the fluff phase. They also caution against making routing decisions based on claims made by peer nodes.The Dandelion team receives feedback from Pieter Wuille and plans to prioritize writing a clearer specification for node behavior in the BIP. They recommend not allowing fee filters from peers to influence route choice and suggest automatically fluffing or applying fee filters in the stempool. They address stem orphans and advise against biasing the peer selection code. On the implementation side, they apply the same logic to the stempool as the mempool.Bradley Denby proposes the Dandelion protocol as a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The team has developed a working prototype and written detailed documentation for the implementation. Pieter Wuille raises concerns about the need for clearer node behavior descriptions and the protocol's interaction with other elements of the Bitcoin ecosystem.The Dandelion project aims to provide greater anonymity for Bitcoin users by routing transactions through multiple nodes. The team has built a working prototype, conducted theoretical analysis and simulations, and written detailed documentation. They recommend using Tor for targeted deanonymization concerns but see Dandelion as a "public health" fix. The team plans to prioritize writing a clearer specification for node behavior in the BIP.Researchers have developed the Dandelion protocol to enhance privacy for Bitcoin users. Transactions are routed over a randomly selected path before diffusion to prevent deanonymization attacks. The team has completed additional analysis, simulations, and documentation. They address routing during the stem phase, deployment of Dandelion relays, and the influence of fee filters on route choice. The team also discusses stem orphans and the importance of clear node behavior descriptions.The Dandelion project proposes a modification to Bitcoin's transaction propagation mechanism to enhance privacy. They have developed a new variant called Per-Incoming-Edge routing and addressed intersection attacks. Concerns are raised about the Mempool Embargo approach and an alternative construction is proposed. An experiment comparing learning rates under diffusion and Dandelion is included.A preliminary implementation and BIP for Dandelion have been developed. The proposal aims to obscure the original source IP of each transaction and defend against attackers trying to learn nodes involved in the stem phase. Concerns about information leaks and handling chains of unconfirmed stem transactions are raised. The transition from stem to fluff phase is under-specified. An alternative construction is suggested to improve anonymity set during the transition phase.A group of developers has introduced a preliminary implementation and Bitcoin Improvement Proposal (BIP) for Dandelion, a privacy-enhancing modification to Bitcoin's transaction propagation mechanism. The aim is to increase the anonymity set by obscuring the original source IP of each transaction. The proposed two-phase approach involves the "stem" phase and the "fluff" phase.During the stem phase, transactions are relayed to a single peer by each node. This process improves the anonymity set as capable nodes take on the role of the last stem hop. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves similarly to ordinary transaction flooding or diffusion.The developers have included several new design ideas in their proposal. They have introduced a stronger attacker model to defend against an attacker actively trying to learn which nodes were involved in the stem phase. This approach, called "Mempool Embargo," ensures that a node receiving a stem phase transaction behaves as if it never heard of it until it receives it from someone else or a random timer elapses.The team is also working on ensuring robustness, as they believe the privacy benefit should not come at the expense of propagation quality - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml b/static/bitcoin-dev/Sept_2017/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml index 12082d794d..2131020617 100644 --- a/static/bitcoin-dev/Sept_2017/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml +++ b/static/bitcoin-dev/Sept_2017/combined_BIP-proposal-Pay-to-Contract-BIP43-Application.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - BIP proposal, Pay to Contract BIP43 Application - 2023-08-01T21:26:35.599175+00:00 - - ZmnSCPxj 2019-03-12 07:05:37+00:00 - - - Omar Shibli 2019-03-12 05:53:45+00:00 - - - Omar Shibli 2017-09-01 07:16:41+00:00 - - - omar shibli 2017-08-15 16:40:36+00:00 - - - Gregory Maxwell 2017-08-15 05:12:11+00:00 - - - omar shibli 2017-08-14 06:05:35+00:00 - + 2025-09-26T15:48:52.520844+00:00 + python-feedgen + + + [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application omar shibli + 2017-08-14T06:05:00.000Z + + + Gregory Maxwell + 2017-08-15T05:12:00.000Z + + + omar shibli + 2017-08-15T16:40:00.000Z + + + Omar Shibli + 2017-09-01T07:16:00.000Z + + + Omar Shibli + 2019-03-12T05:53:00.000Z + + + ZmnSCPxj + 2019-03-12T07:05:00.000Z + + - python-feedgen + 2 Combined summary - BIP proposal, Pay to Contract BIP43 Application - 2023-08-01T21:26:35.600176+00:00 + 2025-09-26T15:48:52.521683+00:00 - The email conversation revolves around a proposed method for embedding cryptographic signatures into public keys based on HD Wallets - BIP32. ZmnSCPxj raised concerns about the possibility of an attacker finding two contracts whose derivations alias each other and the possibility of multiple contracting systems. Omar Shibli responded to Gregory Maxwell's feedback with some fixes which he submitted on Github. Omar Shibli further expressed his opinion that the security fix was redundant. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey.In August 2017, Omar Shibli shared his method for embedding cryptographic signatures into a public key based on HD Wallets - BIP32, in a trade finance application. He proposed defining various levels in BIP32 path to compute child public keys and addresses. He also provided an example of contract commitment address computation. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey. Gregory also pointed out that the proposal did not address durability issues. Omar Shibli updated the BIP to address Gregory's concerns.The email thread includes a message from Omar Shibli expressing his appreciation for Gregory Maxwell's work in the FOSS ecosystem, particularly in Bitcoin and Blockstream. He also submitted fixes to Gregory's concerns regarding a security fix patch in the CKD function (BIP32) and requested his review. In another email, Omar shared an updated draft of a BIP specifying the multiparty key derivation scheme for the pay-to-contract protocol and sought feedback. Gregory had previously raised concerns about the security of the construction and durability issues which were not addressed in the proposal. Omar clarified the application of the construction, provided an example and updated the BIP to address Gregory's concerns. The full BIP draft is available on GitHub.A team has developed a basic trade finance application to conduct transactions using the Homomorphic Payment Addresses and the Pay-to-Contract Protocol paper. They have generalised it and made it BIP43 complaint. The team defines levels in BIP32 path as m / purpose' / coin_type' / contract_id' / *. Contract_id is an arbitrary number within the valid range of indices. Then, they define contract base as following prefix: m / purpose' / coin_type' / contract_id'. Contract commitment address is computed by hashing a document with a cryptographic hash function of your choice (e.g. Blake2), mapping the hash to partial derivation path and computing child public key by chaining the derivation path from step 2 with contract base. Payment address funds could be reclaimed only if the customer_contract_signature is provided by the customer. In terms of durability, their app is pretty simple at this point, they don't store anything, they let customer download and manage the files.The construction appears to be completely insecure, according to Gregory Maxwell. He believes that this is because the pubkey is easily manipulated. The team updated the BIP to explicitly specify the multiparty key derivation scheme, which they hope will address Maxwell's concerns. The BIP draft can be found on GitHub. Omar, from the team, thanks Gregory for his feedback and welcomes any further feedback.The email conversation is about a method to embed cryptographic signatures into public keys based on HD Wallets - BIP32. The application uses two cryptographic signatures from both sides for practical purposes. The proposed construction includes contract base, payment base, and payment address which can only be reclaimed by the customer_contract_signature. The current application is not very durable as it doesn't store anything, instead, the customer downloads and manages the files. Gregory Maxwell raises concerns about the security of the construction, its applications, and durability issues. Omar Shibli describes an abstract idea where levels are defined in BIP32 path, contract_id is an arbitrary number within valid indices and contract commitment address is computed using a cryptographic hash function. He also provides an example to illustrate the process. The full BIP draft is available on GitHub, and they seek feedback to develop a standard.A developer named Omar Shibli has proposed a new method for conducting transactions using the Homomorphic Payment Addresses and Pay-to-Contract Protocol, which uses the homomorphic property of elliptic curve encryption to achieve payment. The proposal defines levels in BIP32 path and contract commitment address that is computed by hashing a document with a cryptographic hash function, partitioning the array into parts, converting each part to an integer in decimal format, and joining all strings with a slash. The proposal does not address security concerns around payment to contracts or durability issues when losing funds if the exact contract is lost. There is no standard specification on how to conduct such transactions in cyberspace, but developers hope this proposal will result in a standard for the benefit of the community. The full BIP draft can be found at the provided link.The pay-to-contract protocol 2019-03-12T07:05:37+00:00 + The email conversation revolves around a proposed method for embedding cryptographic signatures into public keys based on HD Wallets - BIP32. ZmnSCPxj raised concerns about the possibility of an attacker finding two contracts whose derivations alias each other and the possibility of multiple contracting systems. Omar Shibli responded to Gregory Maxwell's feedback with some fixes which he submitted on Github. Omar Shibli further expressed his opinion that the security fix was redundant. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey.In August 2017, Omar Shibli shared his method for embedding cryptographic signatures into a public key based on HD Wallets - BIP32, in a trade finance application. He proposed defining various levels in BIP32 path to compute child public keys and addresses. He also provided an example of contract commitment address computation. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey. Gregory also pointed out that the proposal did not address durability issues. Omar Shibli updated the BIP to address Gregory's concerns.The email thread includes a message from Omar Shibli expressing his appreciation for Gregory Maxwell's work in the FOSS ecosystem, particularly in Bitcoin and Blockstream. He also submitted fixes to Gregory's concerns regarding a security fix patch in the CKD function (BIP32) and requested his review. In another email, Omar shared an updated draft of a BIP specifying the multiparty key derivation scheme for the pay-to-contract protocol and sought feedback. Gregory had previously raised concerns about the security of the construction and durability issues which were not addressed in the proposal. Omar clarified the application of the construction, provided an example and updated the BIP to address Gregory's concerns. The full BIP draft is available on GitHub.A team has developed a basic trade finance application to conduct transactions using the Homomorphic Payment Addresses and the Pay-to-Contract Protocol paper. They have generalised it and made it BIP43 complaint. The team defines levels in BIP32 path as m / purpose' / coin_type' / contract_id' / *. Contract_id is an arbitrary number within the valid range of indices. Then, they define contract base as following prefix: m / purpose' / coin_type' / contract_id'. Contract commitment address is computed by hashing a document with a cryptographic hash function of your choice (e.g. Blake2), mapping the hash to partial derivation path and computing child public key by chaining the derivation path from step 2 with contract base. Payment address funds could be reclaimed only if the customer_contract_signature is provided by the customer. In terms of durability, their app is pretty simple at this point, they don't store anything, they let customer download and manage the files.The construction appears to be completely insecure, according to Gregory Maxwell. He believes that this is because the pubkey is easily manipulated. The team updated the BIP to explicitly specify the multiparty key derivation scheme, which they hope will address Maxwell's concerns. The BIP draft can be found on GitHub. Omar, from the team, thanks Gregory for his feedback and welcomes any further feedback.The email conversation is about a method to embed cryptographic signatures into public keys based on HD Wallets - BIP32. The application uses two cryptographic signatures from both sides for practical purposes. The proposed construction includes contract base, payment base, and payment address which can only be reclaimed by the customer_contract_signature. The current application is not very durable as it doesn't store anything, instead, the customer downloads and manages the files. Gregory Maxwell raises concerns about the security of the construction, its applications, and durability issues. Omar Shibli describes an abstract idea where levels are defined in BIP32 path, contract_id is an arbitrary number within valid indices and contract commitment address is computed using a cryptographic hash function. He also provides an example to illustrate the process. The full BIP draft is available on GitHub, and they seek feedback to develop a standard.A developer named Omar Shibli has proposed a new method for conducting transactions using the Homomorphic Payment Addresses and Pay-to-Contract Protocol, which uses the homomorphic property of elliptic curve encryption to achieve payment. The proposal defines levels in BIP32 path and contract commitment address that is computed by hashing a document with a cryptographic hash function, partitioning the array into parts, converting each part to an integer in decimal format, and joining all strings with a slash. The proposal does not address security concerns around payment to contracts or durability issues when losing funds if the exact contract is lost. There is no standard specification on how to conduct such transactions in cyberspace, but developers hope this proposal will result in a standard for the benefit of the community. The full BIP draft can be found at the provided link.The pay-to-contract protocol - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_BIP49-Derivation-scheme-changes.xml b/static/bitcoin-dev/Sept_2017/combined_BIP49-Derivation-scheme-changes.xml index 4d72a173ac..5150674819 100644 --- a/static/bitcoin-dev/Sept_2017/combined_BIP49-Derivation-scheme-changes.xml +++ b/static/bitcoin-dev/Sept_2017/combined_BIP49-Derivation-scheme-changes.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - BIP49 Derivation scheme changes - 2023-08-01T21:42:39.503945+00:00 - - Dan Libby 2017-09-06 07:19:31+00:00 - - - shiva sitamraju 2017-09-06 05:20:31+00:00 - - - Thomas Voegtlin 2017-09-05 16:33:00+00:00 - - - Pavol Rusnak 2017-09-05 15:41:37+00:00 - - - shiva sitamraju 2017-09-05 07:10:15+00:00 - - - Thomas Voegtlin 2017-09-03 05:19:12+00:00 - - - shiva sitamraju 2017-08-30 07:24:13+00:00 - + 2025-09-26T15:49:09.326690+00:00 + python-feedgen + + + [bitcoin-dev] BIP49 Derivation scheme changes shiva sitamraju + 2017-08-30T07:24:00.000Z + + + Thomas Voegtlin + 2017-09-03T05:19:00.000Z + + + shiva sitamraju + 2017-09-05T07:10:00.000Z + + + Pavol Rusnak + 2017-09-05T15:41:00.000Z + + + Thomas Voegtlin + 2017-09-05T16:33:00.000Z + + + shiva sitamraju + 2017-09-06T05:20:00.000Z + + + Dan Libby + 2017-09-06T07:19:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - BIP49 Derivation scheme changes - 2023-08-01T21:42:39.503945+00:00 + 2025-09-26T15:49:09.327596+00:00 - In a discussion on the bitcoin-dev mailing list, the topic of recovering a wallet using seed words was brought up. It was noted that there is no distinction between seed words for segwit and non-segwit wallets, leading to the discovery of both m/44' and m/49' accounts. However, constantly monitoring both accounts for transactions was considered an undesirable solution. The conversation also touched on the issue of XPUB Derivation, which has not been addressed in the BIP yet. The inability to differentiate between xpub from m/44' or m/49' was identified as problematic, affecting functionalities such as importing xpub as a watch-only wallet and displaying balance/generating merchant addresses. The author of tools hd-wallet-addrs and hd-wallet-derive expressed agreement and suggested finding a way for xpub/xprv to encode their absolute path in the wallet for easier reading by tools. Another email exchange on the bitcoin-dev mailing list involved a user asking Thomas Voegtlin about the need for a different version for P2WPKH nested in BIP16 P2SH compared to P2WPKH. The user questioned if both would generate the same Bitcoin address in txout and be part of the same wallet account. Pavol Rusnak responded, expressing support for both proposals and urging the group to reach a decision soon. The discussion then moved on to proposed changes to the BIP32 serialization format, with Thomas suggesting the use of letters z, y, and z combined with pub/prv to indicate three types of keys, while Luke Dashjr favored utilizing a child number field. In a separate thread, Chris Stewart raised concerns about sidechain headers on mainchain and potential issues with invalid transactions impacting the consensus valid chain constructed by sidechain miners. He recommended incentivizing miners to collaborate by extending the coinbase maturity period on the sidechain beyond 288. Thomas later shared his own proposal for three different versions of P2WPKH nested in BIP16 P2SH for testnet and mainnet.On September 5th, 2017, Shiva Sitamraju expressed gratitude on the Bitcoin development mailing list for a procedure outlined in Electrum's documentation related to seed phrases. They questioned the value of following BIP49 and suggested proposing an alternative structure similar to Electrum. Changes to the BIP32 serialization format were proposed to differentiate segwit xpub/xprv, with new version bytes resulting in base58 prefixes and network types. The use of letters z, y, and z combined with pub/prv for three types of keys was suggested due to the existence of native and nested segwit output scripts. Testnet could utilize t, u, and v as prefixes. Shiva Sitamraju also shared four keys related to segwit mainnet and testnet.In a bitcoin-dev mailing list thread discussing scaling solutions and fee reduction, various proposals were put forward. Cserveny Tamas suggested splitting the chain, Thomas Guyot-Sionnest argued for reducing complexity without compromising security if confirmation is adjusted accordingly, and Tom Zander believed that the limit of blockchain is determined by technology and will continue to evolve. Timestamping in Bitcoin was brought up, highlighting its vulnerability to malicious miners due to the lack of a financial feedback loop. Concerns were raised about using compact SPV proofs for timestamping in OpenTimestamps, citing potential security issues and the need for further analysis.The discussion concluded with the acknowledgment that Segwit wallet seed words have a distinct format incompatible with previous wallet seed words. It was noted that Electrum has already addressed this issue by defining a structure for Segwit wallet seed words in their documentation. The writer of the message proposed breaking backwards compatibility in BIP49 due to issues with recovering wallets using seed words. They suggested creating new segwit m/49' wallets by default, with the option to choose non-segwit from advanced options. The format of segwit wallet seed words would encode the information that the wallet is segwit. Another concern raised was the lack of differentiation between xpub from m/44' and m/49', affecting functionalities like importing xpub as a watch-only wallet and displaying balance/generating merchant addresses. The writer invited thoughts on these suggestions. 2017-09-06T07:19:31+00:00 + In a discussion on the bitcoin-dev mailing list, the topic of recovering a wallet using seed words was brought up. It was noted that there is no distinction between seed words for segwit and non-segwit wallets, leading to the discovery of both m/44' and m/49' accounts. However, constantly monitoring both accounts for transactions was considered an undesirable solution. The conversation also touched on the issue of XPUB Derivation, which has not been addressed in the BIP yet. The inability to differentiate between xpub from m/44' or m/49' was identified as problematic, affecting functionalities such as importing xpub as a watch-only wallet and displaying balance/generating merchant addresses. The author of tools hd-wallet-addrs and hd-wallet-derive expressed agreement and suggested finding a way for xpub/xprv to encode their absolute path in the wallet for easier reading by tools. Another email exchange on the bitcoin-dev mailing list involved a user asking Thomas Voegtlin about the need for a different version for P2WPKH nested in BIP16 P2SH compared to P2WPKH. The user questioned if both would generate the same Bitcoin address in txout and be part of the same wallet account. Pavol Rusnak responded, expressing support for both proposals and urging the group to reach a decision soon. The discussion then moved on to proposed changes to the BIP32 serialization format, with Thomas suggesting the use of letters z, y, and z combined with pub/prv to indicate three types of keys, while Luke Dashjr favored utilizing a child number field. In a separate thread, Chris Stewart raised concerns about sidechain headers on mainchain and potential issues with invalid transactions impacting the consensus valid chain constructed by sidechain miners. He recommended incentivizing miners to collaborate by extending the coinbase maturity period on the sidechain beyond 288. Thomas later shared his own proposal for three different versions of P2WPKH nested in BIP16 P2SH for testnet and mainnet.On September 5th, 2017, Shiva Sitamraju expressed gratitude on the Bitcoin development mailing list for a procedure outlined in Electrum's documentation related to seed phrases. They questioned the value of following BIP49 and suggested proposing an alternative structure similar to Electrum. Changes to the BIP32 serialization format were proposed to differentiate segwit xpub/xprv, with new version bytes resulting in base58 prefixes and network types. The use of letters z, y, and z combined with pub/prv for three types of keys was suggested due to the existence of native and nested segwit output scripts. Testnet could utilize t, u, and v as prefixes. Shiva Sitamraju also shared four keys related to segwit mainnet and testnet.In a bitcoin-dev mailing list thread discussing scaling solutions and fee reduction, various proposals were put forward. Cserveny Tamas suggested splitting the chain, Thomas Guyot-Sionnest argued for reducing complexity without compromising security if confirmation is adjusted accordingly, and Tom Zander believed that the limit of blockchain is determined by technology and will continue to evolve. Timestamping in Bitcoin was brought up, highlighting its vulnerability to malicious miners due to the lack of a financial feedback loop. Concerns were raised about using compact SPV proofs for timestamping in OpenTimestamps, citing potential security issues and the need for further analysis.The discussion concluded with the acknowledgment that Segwit wallet seed words have a distinct format incompatible with previous wallet seed words. It was noted that Electrum has already addressed this issue by defining a structure for Segwit wallet seed words in their documentation. The writer of the message proposed breaking backwards compatibility in BIP49 due to issues with recovering wallets using seed words. They suggested creating new segwit m/49' wallets by default, with the option to choose non-segwit from advanced options. The format of segwit wallet seed words would encode the information that the wallet is segwit. Another concern raised was the lack of differentiation between xpub from m/44' and m/49', affecting functionalities like importing xpub as a watch-only wallet and displaying balance/generating merchant addresses. The writer invited thoughts on these suggestions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Bitcoin-Assistance.xml b/static/bitcoin-dev/Sept_2017/combined_Bitcoin-Assistance.xml index bbfe53a168..f38222bc46 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Bitcoin-Assistance.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Bitcoin-Assistance.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Bitcoin Assistance - 2023-08-01T21:55:47.122548+00:00 - - Tim Ruffing 2017-09-27 22:41:24+00:00 - - - Gregory Maxwell 2017-09-27 22:21:12+00:00 - - - Gregory Maxwell 2017-09-27 22:06:58+00:00 - - - Tim Ruffing 2017-09-27 21:54:09+00:00 - - - Cory Fields 2017-09-27 21:20:26+00:00 - - - Omar Shibli 2017-09-26 13:12:48+00:00 - - - Radcliffe, Mark 2017-09-25 21:53:40+00:00 - + 2025-09-26T15:49:19.883881+00:00 + python-feedgen + + + [bitcoin-dev] Bitcoin Assistance Radcliffe, Mark + 2017-09-25T21:53:00.000Z + + + Omar Shibli + 2017-09-26T13:12:00.000Z + + + Cory Fields + 2017-09-27T21:20:00.000Z + + + Tim Ruffing + 2017-09-27T21:54:00.000Z + + + Gregory Maxwell + 2017-09-27T22:06:00.000Z + + + Gregory Maxwell + 2017-09-27T22:21:00.000Z + + + Tim Ruffing + 2017-09-27T22:41:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Assistance - 2023-08-01T21:55:47.122548+00:00 + 2025-09-26T15:49:19.884855+00:00 - On September 27, 2017, concerns were raised on the bitcoin-dev mailing list regarding possible violations of the CC BY-SA license in some icons listed as "License: MIT" in the Bitcoin Core software. Tim Ruffing expressed these concerns and questioned the licensing of the icons. In response to this, Gregory Maxwell clarified that the icons had been re-licensed by the copyright holder and provided a link to the commit where this change was made. He also suggested using the `git log -p` command in the future to easily locate specific changes in files.In another discussion on the same mailing list, Cory Fields addressed the licensing of an alternative to the modulo reduction. He referenced a comment in cuckoocache.h, which explained a well-known technique used in fixed point signal processing. The purpose of the comment was to provide clarity for those who were confused by the code in another project. The link to the site was added after the code as it provided helpful information about the technique used.Cory Fields initiated a discussion on the bitcoin-dev mailing list regarding the licensing of bitcoin's GUI SVG icons. He pointed out that the default behavior of inkscape, the software used to create the icons, is to contain an XML tag with a link to creativecommons.org. This may have led to the mistaken belief that the icons were licensed under CC. It was clarified that all icons not created by the team are listed in contrib/debian/copyright and are actually public domain. There was also a mistake in the current documentation, which listed the icons as "Expat" while they were previously listed as "CC BY-SA". Additionally, some icons listed as "MIT" could potentially be a violation of the CC BY-SA license.Cory Fields reviewed the licenses used in various files for the Bitcoin Core project. The Apache License 2.0 is used by bindings that allow other applications to use libsecp256k1 from Java, while the Boost Software License 1.0 is used by Bitcoin Core. The BSD 2-clause "Simplified" License was not found in any files. The BSD 3-clause "New" or "Revised" License comes from leveldb, a database software used by Bitcoin Core. Some non-upstream files are used in the leveldb tree to provide Windows support. Creative Commons Attribution Share Alike 3.0 seems to be the default behavior of inkscape, which was used to create GUI svg icons. However, all icons not created by the team are listed in contrib/debian/copyright and are classified as expat/public domain. The Expat License is similar to the MIT License. Debian packaging resources are licensed gplv2+. The macdeploy script, used to create DMG files for macOS, is licensed under gplv3. Authproxy.py, a python script used in the test suite, is licensed lgpl v2.1+. There are two m4 files with a macro that builds code, but they are only used in the build process. Licenses for "A fast alternative to the modulo reduction" and atomic by Timm Kosse are referenced in comments but not actually used in the code. Finally, clang-format-diff.py, a python script optionally used by developers to clean up code changes, is licensed under the University of Illinois/NCSA Open Source License. The licensing of Bitcoin Core has been examined by Black Duck Software, who conducted a scan of the code for open source licenses. The scan revealed that the code base includes code licensed under various licenses, such as Apache License 2.0, Boost Software License 1.0, and MIT License, among others. It was noted that some of these licenses may be incompatible with each other, such as code licensed under the Apache Software License version 2 and GPLv2. Mark Radcliffe, a lawyer, has requested to communicate with the individuals who manage the Bitcoin Core codebase to gain insight into how contributions are managed. He will be presenting in a webinar with Black Duck Software on Blockchain on September 28. It is important to note that the components of the Bitcoin protocol (node, miner, wallet) can use different licenses as long as they are well structured and have well-defined and encapsulated APIs.In conclusion, there were concerns raised about the licensing of icons in the Bitcoin Core software, which were addressed by the copyright holder through re-licensing. Discussions also took place regarding the licensing of an alternative to the modulo reduction technique and the GUI SVG icons. Cory Fields provided information on the licenses used in various files within the Bitcoin Core project. Black Duck Software conducted a scan of the codebase and found that it includes code licensed under various licenses. A lawyer has expressed interest in discussing the management of contributions with the Bitcoin Core team and will be participating in a webinar on Blockchain with Black Duck Software. 2017-09-27T22:41:24+00:00 + On September 27, 2017, concerns were raised on the bitcoin-dev mailing list regarding possible violations of the CC BY-SA license in some icons listed as "License: MIT" in the Bitcoin Core software. Tim Ruffing expressed these concerns and questioned the licensing of the icons. In response to this, Gregory Maxwell clarified that the icons had been re-licensed by the copyright holder and provided a link to the commit where this change was made. He also suggested using the `git log -p` command in the future to easily locate specific changes in files.In another discussion on the same mailing list, Cory Fields addressed the licensing of an alternative to the modulo reduction. He referenced a comment in cuckoocache.h, which explained a well-known technique used in fixed point signal processing. The purpose of the comment was to provide clarity for those who were confused by the code in another project. The link to the site was added after the code as it provided helpful information about the technique used.Cory Fields initiated a discussion on the bitcoin-dev mailing list regarding the licensing of bitcoin's GUI SVG icons. He pointed out that the default behavior of inkscape, the software used to create the icons, is to contain an XML tag with a link to creativecommons.org. This may have led to the mistaken belief that the icons were licensed under CC. It was clarified that all icons not created by the team are listed in contrib/debian/copyright and are actually public domain. There was also a mistake in the current documentation, which listed the icons as "Expat" while they were previously listed as "CC BY-SA". Additionally, some icons listed as "MIT" could potentially be a violation of the CC BY-SA license.Cory Fields reviewed the licenses used in various files for the Bitcoin Core project. The Apache License 2.0 is used by bindings that allow other applications to use libsecp256k1 from Java, while the Boost Software License 1.0 is used by Bitcoin Core. The BSD 2-clause "Simplified" License was not found in any files. The BSD 3-clause "New" or "Revised" License comes from leveldb, a database software used by Bitcoin Core. Some non-upstream files are used in the leveldb tree to provide Windows support. Creative Commons Attribution Share Alike 3.0 seems to be the default behavior of inkscape, which was used to create GUI svg icons. However, all icons not created by the team are listed in contrib/debian/copyright and are classified as expat/public domain. The Expat License is similar to the MIT License. Debian packaging resources are licensed gplv2+. The macdeploy script, used to create DMG files for macOS, is licensed under gplv3. Authproxy.py, a python script used in the test suite, is licensed lgpl v2.1+. There are two m4 files with a macro that builds code, but they are only used in the build process. Licenses for "A fast alternative to the modulo reduction" and atomic by Timm Kosse are referenced in comments but not actually used in the code. Finally, clang-format-diff.py, a python script optionally used by developers to clean up code changes, is licensed under the University of Illinois/NCSA Open Source License. The licensing of Bitcoin Core has been examined by Black Duck Software, who conducted a scan of the code for open source licenses. The scan revealed that the code base includes code licensed under various licenses, such as Apache License 2.0, Boost Software License 1.0, and MIT License, among others. It was noted that some of these licenses may be incompatible with each other, such as code licensed under the Apache Software License version 2 and GPLv2. Mark Radcliffe, a lawyer, has requested to communicate with the individuals who manage the Bitcoin Core codebase to gain insight into how contributions are managed. He will be presenting in a webinar with Black Duck Software on Blockchain on September 28. It is important to note that the components of the Bitcoin protocol (node, miner, wallet) can use different licenses as long as they are well structured and have well-defined and encapsulated APIs.In conclusion, there were concerns raised about the licensing of icons in the Bitcoin Core software, which were addressed by the copyright holder through re-licensing. Discussions also took place regarding the licensing of an alternative to the modulo reduction technique and the GUI SVG icons. Cory Fields provided information on the licenses used in various files within the Bitcoin Core project. Black Duck Software conducted a scan of the codebase and found that it includes code licensed under various licenses. A lawyer has expressed interest in discussing the management of contributions with the Bitcoin Core team and will be participating in a webinar on Blockchain with Black Duck Software. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Fast-Merkle-Trees.xml b/static/bitcoin-dev/Sept_2017/combined_Fast-Merkle-Trees.xml index 48d2d0371d..c883bd35ae 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Fast-Merkle-Trees.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Fast-Merkle-Trees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fast Merkle Trees - 2023-08-01T21:50:13.813968+00:00 + 2025-09-26T15:48:33.560112+00:00 + python-feedgen Johnson Lau 2017-09-12 11:44:48+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Fast Merkle Trees - 2023-08-01T21:50:13.814969+00:00 + 2025-09-26T15:48:33.560258+00:00 - In an email exchange on the bitcoin-dev mailing list, Mark Friedenbach discussed a potential attack on Bitcoin's hash trees. The attack involves creating a script that appears safe but is actually controlled by the attacker. Friedenbach presented two possible scripts and suggested modifying the scheme to use a different initialization vector (IV) for hash tree updates to prevent such attacks. However, another user responded with an example of a MAST branch that requires only a few bytes of collision, indicating that the attack may not be as difficult as initially thought.The email thread also discusses the vulnerability of third-party scripts in general. The attack described involves finding a collision between innocuous and malign scripts using different hash functions. Friedenbach explained the procedure for getting a collision and suggested that multi-party wallet level protocols should require a 'delinearization' step to prove the safety of a construct.In response to Russell O'Connor's query about a security breach in the Bitcoin Improvement Proposal (BIP) tree structure, Friedenbach expressed uncertainty about the possibility of conducting the attack described using the specified tree structure. He believes that breaking SHA256 completely would be necessary to accomplish the attack. O'Connor expressed concern about the lack of distinction between leaf nodes and internal nodes in the design, which could lead to vulnerabilities. He suggested using a different IV for the fast hash of internal nodes to mitigate this risk.Peter Todd agreed with O'Connor's proposal for a fast hash for internal nodes, but cautioned against creating new hash functions using custom IVs. He suggested using bog-standard SHA256 with a fixed first block to allow optimized implementations to start with a fixed midstate. Todd clarified that using custom IVs results in a hash function equivalent to prefixing the data with the padded version of the fixed string and using a regular SHA256 hash.The design of fast Merkle trees does not distinguish between leaf nodes and internal nodes, allowing for validation of paths longer than 32 branches. However, this lack of distinction poses a security risk. O'Connor demonstrated how counterparty could include specially crafted "scripts" masquerading as leaves, allowing them to reveal malicious code at a deeper level. O'Connor suggested using a fixed IV value for the fast hash of internal nodes to address this vulnerability.In a recent email, O'Connor proposed that the fast hash for internal nodes should use a fixed value that is the SHA-256 hash of a fixed string. However, it is noted that new hash functions should generally not be created by using custom IVs. Instead, bog-standard SHA256 should be used with a fixed first block.Overall, the discussions revolve around the potential attack on Bitcoin's hash trees, the vulnerability of third-party scripts, and the need for modifications in the design of fast Merkle trees to prevent attacks and address security risks. The provided links contain additional information and code related to these topics. 2017-09-12T11:44:48+00:00 + In an email exchange on the bitcoin-dev mailing list, Mark Friedenbach discussed a potential attack on Bitcoin's hash trees. The attack involves creating a script that appears safe but is actually controlled by the attacker. Friedenbach presented two possible scripts and suggested modifying the scheme to use a different initialization vector (IV) for hash tree updates to prevent such attacks. However, another user responded with an example of a MAST branch that requires only a few bytes of collision, indicating that the attack may not be as difficult as initially thought.The email thread also discusses the vulnerability of third-party scripts in general. The attack described involves finding a collision between innocuous and malign scripts using different hash functions. Friedenbach explained the procedure for getting a collision and suggested that multi-party wallet level protocols should require a 'delinearization' step to prove the safety of a construct.In response to Russell O'Connor's query about a security breach in the Bitcoin Improvement Proposal (BIP) tree structure, Friedenbach expressed uncertainty about the possibility of conducting the attack described using the specified tree structure. He believes that breaking SHA256 completely would be necessary to accomplish the attack. O'Connor expressed concern about the lack of distinction between leaf nodes and internal nodes in the design, which could lead to vulnerabilities. He suggested using a different IV for the fast hash of internal nodes to mitigate this risk.Peter Todd agreed with O'Connor's proposal for a fast hash for internal nodes, but cautioned against creating new hash functions using custom IVs. He suggested using bog-standard SHA256 with a fixed first block to allow optimized implementations to start with a fixed midstate. Todd clarified that using custom IVs results in a hash function equivalent to prefixing the data with the padded version of the fixed string and using a regular SHA256 hash.The design of fast Merkle trees does not distinguish between leaf nodes and internal nodes, allowing for validation of paths longer than 32 branches. However, this lack of distinction poses a security risk. O'Connor demonstrated how counterparty could include specially crafted "scripts" masquerading as leaves, allowing them to reveal malicious code at a deeper level. O'Connor suggested using a fixed IV value for the fast hash of internal nodes to address this vulnerability.In a recent email, O'Connor proposed that the fast hash for internal nodes should use a fixed value that is the SHA-256 hash of a fixed string. However, it is noted that new hash functions should generally not be created by using custom IVs. Instead, bog-standard SHA256 should be used with a fixed first block.Overall, the discussions revolve around the potential attack on Bitcoin's hash trees, the vulnerability of third-party scripts, and the need for modifications in the design of fast Merkle trees to prevent attacks and address security risks. The provided links contain additional information and code related to these topics. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Fwd-Compressed-headers-stream.xml b/static/bitcoin-dev/Sept_2017/combined_Fwd-Compressed-headers-stream.xml index b31437055d..0303aa0908 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Fwd-Compressed-headers-stream.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Fwd-Compressed-headers-stream.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Fwd: "Compressed" headers stream - 2023-08-01T21:31:35.396695+00:00 + Combined summary - Fwd: "Compressed" headers stream + 2025-09-26T15:48:48.301651+00:00 + python-feedgen Peter Todd 2017-09-04 14:06:44+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 - Combined summary - Fwd: "Compressed" headers stream - 2023-08-01T21:31:35.396695+00:00 + Combined summary - Fwd: "Compressed" headers stream + 2025-09-26T15:48:48.301810+00:00 - In a discussion on the bitcoin-dev mailing list, Gregory Maxwell highlighted various methods to reduce the number of bytes required for block headers. These techniques involve minimizing changes to the bits field, setting the timestamp to be slightly higher than the previous one, and recognizing that the block version is typically one of the last few. However, these improvements offer only a constant factor reduction in size.The compact SPV proofs, outlined in the appendix of the sidechains whitepaper, introduce logarithmic scaling proofs but solely validate total work, not validity. OpenTimestamps aims to establish a framework for trusted validity attestations, as timestamping via proof-of-work presents security concerns due to the potential manipulation of block times by miners. It is crucial to comprehend the associated risks before implementing compact SPV proofs. Additionally, there may be an opportunity to enhance initial download bandwidth by including a known-good sum-merkle-tree tip hash with the software.Riccardo Casatta expressed his belief in an email to bitcoin-dev that Bitcoin headers represent the most vital data globally, with an anticipated increase in demand. He proposed optimizing transmitted data when sending a continuous stream of block headers by eliminating the transmission of previous hashes after the first header. The receiver can calculate the previous hash by double hashing the previous header, which is necessary for verifying the proof of work. This approach could potentially save approximately 40% in bandwidth when transmitting a lengthy sequence of block headers.However, another participant in the discussion countered this suggestion by mentioning alternative ways to reduce bytes in the block headers field, such as avoiding changes to the bits field every 2016 blocks or only including the timestamp if it surpasses the median of the last 11 blocks. These optimizations also provide only a constant factor reduction in size. The contributor recommended exploring the compact SPV proofs described in the appendix of the sidechains whitepaper for logarithmic scaling proofs. 2017-09-04T14:06:44+00:00 + In a discussion on the bitcoin-dev mailing list, Gregory Maxwell highlighted various methods to reduce the number of bytes required for block headers. These techniques involve minimizing changes to the bits field, setting the timestamp to be slightly higher than the previous one, and recognizing that the block version is typically one of the last few. However, these improvements offer only a constant factor reduction in size.The compact SPV proofs, outlined in the appendix of the sidechains whitepaper, introduce logarithmic scaling proofs but solely validate total work, not validity. OpenTimestamps aims to establish a framework for trusted validity attestations, as timestamping via proof-of-work presents security concerns due to the potential manipulation of block times by miners. It is crucial to comprehend the associated risks before implementing compact SPV proofs. Additionally, there may be an opportunity to enhance initial download bandwidth by including a known-good sum-merkle-tree tip hash with the software.Riccardo Casatta expressed his belief in an email to bitcoin-dev that Bitcoin headers represent the most vital data globally, with an anticipated increase in demand. He proposed optimizing transmitted data when sending a continuous stream of block headers by eliminating the transmission of previous hashes after the first header. The receiver can calculate the previous hash by double hashing the previous header, which is necessary for verifying the proof of work. This approach could potentially save approximately 40% in bandwidth when transmitting a lengthy sequence of block headers.However, another participant in the discussion countered this suggestion by mentioning alternative ways to reduce bytes in the block headers field, such as avoiding changes to the bits field every 2016 blocks or only including the timestamp if it surpasses the median of the last 11 blocks. These optimizations also provide only a constant factor reduction in size. The contributor recommended exploring the compact SPV proofs described in the appendix of the sidechains whitepaper for logarithmic scaling proofs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Fwd-Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml b/static/bitcoin-dev/Sept_2017/combined_Fwd-Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml index 948318e155..676c75de2b 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Fwd-Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Fwd-Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs) - 2023-08-01T21:50:51.676783+00:00 + 2025-09-26T15:48:46.187568+00:00 + python-feedgen ZmnSCPxj 2017-09-10 05:33:06+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs) - 2023-08-01T21:50:51.676783+00:00 + 2025-09-26T15:48:46.187734+00:00 - In an email exchange, Bitcoin developers Paul and ZmnSCPxj discuss the concept of sidechains with merge mining and WT^ validity voting. Paul expresses concern that this approach would cause sidechain headers on mainchain (SHOM) to become mere extension blocks and inherit negative properties. He also disagrees with the idea that the power to determine the validity of a sidechain should rest with the economic majority rather than the miners, as he believes a 51% miner-group could manipulate transactions. However, ZmnSCPxj argues that if a miner rejects a bribe to prioritize their desired hash on the sidechain, it implies they value their hash more than the bribe. They both agree that some miners prioritize short-term profits over long-term interests, based on observations in Bcash and Bitcoin.The discussion also delves into the vulnerability of SHOM sidechains to collapse from theft attempts. While potential thieves may be disincentivized by understanding the dollar-auction irrationality, the problem lies in relying on rational behavior from thieves. Additionally, Paul raises concerns about the weakness of the side-to-main peg in SHOM and suggests that capping withdrawals further weakens its usefulness. They explore the possibility of deploying sidechains initially as federated pegs, with a potential transition to drivechain/sidechain-headers-on-mainchain at a later stage. This transition would involve moving controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes. Sergio supports this idea, but Paul sees it as a lack of faith in the design. Both parties agree that sidechains should only be softforked and never hardforked.The email thread also touches upon the mechanism supporting sidechains, which can facilitate any financial system, including centralized non-blockchain systems. ZmnSCPxj emphasizes the importance of not allowing permissioned methods for starting sidechains, while expressing support for an economic bond or proof-of-burn as a starting point. The discussion concludes with references to the specification for WT^ layout and available documentation on the topic.Overall, the email exchange presents both agreements and disagreements related to sidechains, highlighting concerns about regression to extension blocks, control over validity, miner behavior, security vulnerabilities, side-to-main peg strength, deployment strategies, and the inclusivity of different financial systems. 2017-09-10T05:33:06+00:00 + In an email exchange, Bitcoin developers Paul and ZmnSCPxj discuss the concept of sidechains with merge mining and WT^ validity voting. Paul expresses concern that this approach would cause sidechain headers on mainchain (SHOM) to become mere extension blocks and inherit negative properties. He also disagrees with the idea that the power to determine the validity of a sidechain should rest with the economic majority rather than the miners, as he believes a 51% miner-group could manipulate transactions. However, ZmnSCPxj argues that if a miner rejects a bribe to prioritize their desired hash on the sidechain, it implies they value their hash more than the bribe. They both agree that some miners prioritize short-term profits over long-term interests, based on observations in Bcash and Bitcoin.The discussion also delves into the vulnerability of SHOM sidechains to collapse from theft attempts. While potential thieves may be disincentivized by understanding the dollar-auction irrationality, the problem lies in relying on rational behavior from thieves. Additionally, Paul raises concerns about the weakness of the side-to-main peg in SHOM and suggests that capping withdrawals further weakens its usefulness. They explore the possibility of deploying sidechains initially as federated pegs, with a potential transition to drivechain/sidechain-headers-on-mainchain at a later stage. This transition would involve moving controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes. Sergio supports this idea, but Paul sees it as a lack of faith in the design. Both parties agree that sidechains should only be softforked and never hardforked.The email thread also touches upon the mechanism supporting sidechains, which can facilitate any financial system, including centralized non-blockchain systems. ZmnSCPxj emphasizes the importance of not allowing permissioned methods for starting sidechains, while expressing support for an economic bond or proof-of-burn as a starting point. The discussion concludes with references to the specification for WT^ layout and available documentation on the topic.Overall, the email exchange presents both agreements and disagreements related to sidechains, highlighting concerns about regression to extension blocks, control over validity, miner behavior, security vulnerabilities, side-to-main peg strength, deployment strategies, and the inclusivity of different financial systems. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Horizontal-scaling-of-blockchain.xml b/static/bitcoin-dev/Sept_2017/combined_Horizontal-scaling-of-blockchain.xml index 040ac049cd..ae672500a8 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Horizontal-scaling-of-blockchain.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Horizontal-scaling-of-blockchain.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Horizontal scaling of blockchain - 2023-08-01T21:43:37.629456+00:00 - - Tom Zander 2017-09-02 21:13:57+00:00 - - - Thomas Guyot-Sionnest 2017-09-01 19:40:44+00:00 - - - Cserveny Tamas 2017-09-01 18:15:53+00:00 - - - Thomas Guyot-Sionnest 2017-09-01 17:24:56+00:00 - - - Lucas Clemente Vella 2017-09-01 17:15:10+00:00 - - - Tom Zander 2017-09-01 13:12:18+00:00 - - - Cserveny Tamas 2017-09-01 12:47:08+00:00 - + 2025-09-26T15:49:21.976525+00:00 + python-feedgen + + + [bitcoin-dev] Horizontal scaling of blockchain Cserveny Tamas + 2017-09-01T12:47:00.000Z + + + Tom Zander + 2017-09-01T13:12:00.000Z + + + Lucas Clemente Vella + 2017-09-01T17:15:00.000Z + + + Thomas Guyot-Sionnest + 2017-09-01T17:24:00.000Z + + + Cserveny Tamas + 2017-09-01T18:15:00.000Z + + + Thomas Guyot-Sionnest + 2017-09-01T19:40:00.000Z + + + Tom Zander + 2017-09-02T21:13:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Horizontal scaling of blockchain - 2023-08-01T21:43:37.629456+00:00 + 2025-09-26T15:49:21.977395+00:00 - Cserveny Tamas has expressed concern about the exponential growth in Bitcoin transactions and the resulting increase in waiting times and fees. He believes that increasing the block size from 1MB to 4MB and eventually 40MB is necessary to address this issue. However, Tom Zander disagrees and argues that successful products will always push the limits of technology. He cites examples like YouTube and Netflix as proof of this. In a discussion on the Bitcoin-dev mailing list, Tamas suggests that the only way to scale with increasing traffic and lower fees is by either increasing the block size or reducing complexity, although the latter may compromise security. Another member of the discussion disagrees with the idea that reducing complexity would be less secure as long as confirmation is adjusted accordingly. They argue that increasing the number of confirmations can make it just as secure. They also suggest that considering the average hash rate over 60 blocks instead of 6 can actually enhance security.The discussion centers around the scalability issues of the Bitcoin network. The current system is described as single-threaded, where one block being found renders other blocks worthless. To scale with increasing traffic, the options are increasing the block size or reducing complexity, which is seen as less secure. One potential solution proposed is splitting the chain, effectively increasing the block size without the added hashing and validation overhead. This approach could keep the block size at 1-2mb for a longer period of time, with new partitions being added on a schedule. However, more specific details are needed to fully evaluate its effectiveness compared to other systems like IOTA.A response to a statement suggesting that the current Bitcoin chain is single-threaded argues that this is not true since the introduction of xthin/compactblocks. These technologies have removed the bottleneck, allowing for continuous parallel validation of transactions. However, it is pointed out that the original statement may refer to the entire distributed system behaving as a single-threaded computation, similar to how IOTA operates. The benefits of this approach are difficult to assess without more specific details. It is also mentioned that distributing the task of validating transactions versus reducing difficulty could be advantageous, and the Lightning network may offer instant validation with smaller fees.Another message thread clarifies that the current Bitcoin chain is not single-threaded due to the introduction of xthin/compactblocks. These technologies enable continuous parallel validation of transactions. However, it is noted that the original statement might refer to the behavior of the entire distributed system, which is closer to what IOTA uses. More information is needed to evaluate the benefits of this approach.In another discussion on the Bitcoin-dev mailing list, Tamas raises concerns about miners adding capacity to the network, arguing that it only increases their share of block rewards without improving transaction speed. However, it is pointed out that increasing block size does increase the throughput speed of transactions and does not affect the block reward. Tamas also suggests that raising fees in the future due to decreasing block rewards would be inevitable, but this has not been observed. Additionally, Tamas claims that the current chain is effectively single-threaded, a claim refuted by Tom Zander. With the introduction of xthin/compactblocks, the network bottleneck has been eliminated, allowing for continuous parallel validation of transactions. Zander provides further insights on his blog and vlog channels.The writer considers various options for scaling the blockchain. One problem is that adding more miners only increases their share of block rewards without improving transaction speed. The current chain is described as single-threaded, so horizontal scaling could be a viable solution if the problem can be partitioned. The number of partitions would start low but could increase over time. Two alternatives for partitioning keys are mentioned: ordering on inputs or ordering on transaction IDs. Both methods would impact block rewards and complexity, which would need adjustment. The activation of partitions could be done gradually according to a schedule. Creating new partitions would be easy, but closing them might be more complex in the case of transaction-partitioned transactions. The writer acknowledges that there are pros and cons to both partition keys and seeks opinions on the matter. 2017-09-02T21:13:57+00:00 + Cserveny Tamas has expressed concern about the exponential growth in Bitcoin transactions and the resulting increase in waiting times and fees. He believes that increasing the block size from 1MB to 4MB and eventually 40MB is necessary to address this issue. However, Tom Zander disagrees and argues that successful products will always push the limits of technology. He cites examples like YouTube and Netflix as proof of this. In a discussion on the Bitcoin-dev mailing list, Tamas suggests that the only way to scale with increasing traffic and lower fees is by either increasing the block size or reducing complexity, although the latter may compromise security. Another member of the discussion disagrees with the idea that reducing complexity would be less secure as long as confirmation is adjusted accordingly. They argue that increasing the number of confirmations can make it just as secure. They also suggest that considering the average hash rate over 60 blocks instead of 6 can actually enhance security.The discussion centers around the scalability issues of the Bitcoin network. The current system is described as single-threaded, where one block being found renders other blocks worthless. To scale with increasing traffic, the options are increasing the block size or reducing complexity, which is seen as less secure. One potential solution proposed is splitting the chain, effectively increasing the block size without the added hashing and validation overhead. This approach could keep the block size at 1-2mb for a longer period of time, with new partitions being added on a schedule. However, more specific details are needed to fully evaluate its effectiveness compared to other systems like IOTA.A response to a statement suggesting that the current Bitcoin chain is single-threaded argues that this is not true since the introduction of xthin/compactblocks. These technologies have removed the bottleneck, allowing for continuous parallel validation of transactions. However, it is pointed out that the original statement may refer to the entire distributed system behaving as a single-threaded computation, similar to how IOTA operates. The benefits of this approach are difficult to assess without more specific details. It is also mentioned that distributing the task of validating transactions versus reducing difficulty could be advantageous, and the Lightning network may offer instant validation with smaller fees.Another message thread clarifies that the current Bitcoin chain is not single-threaded due to the introduction of xthin/compactblocks. These technologies enable continuous parallel validation of transactions. However, it is noted that the original statement might refer to the behavior of the entire distributed system, which is closer to what IOTA uses. More information is needed to evaluate the benefits of this approach.In another discussion on the Bitcoin-dev mailing list, Tamas raises concerns about miners adding capacity to the network, arguing that it only increases their share of block rewards without improving transaction speed. However, it is pointed out that increasing block size does increase the throughput speed of transactions and does not affect the block reward. Tamas also suggests that raising fees in the future due to decreasing block rewards would be inevitable, but this has not been observed. Additionally, Tamas claims that the current chain is effectively single-threaded, a claim refuted by Tom Zander. With the introduction of xthin/compactblocks, the network bottleneck has been eliminated, allowing for continuous parallel validation of transactions. Zander provides further insights on his blog and vlog channels.The writer considers various options for scaling the blockchain. One problem is that adding more miners only increases their share of block rewards without improving transaction speed. The current chain is described as single-threaded, so horizontal scaling could be a viable solution if the problem can be partitioned. The number of partitions would start low but could increase over time. Two alternatives for partitioning keys are mentioned: ordering on inputs or ordering on transaction IDs. Both methods would impact block rewards and complexity, which would need adjustment. The activation of partitions could be done gradually according to a schedule. Creating new partitions would be easy, but closing them might be more complex in the case of transaction-partitioned transactions. The writer acknowledges that there are pros and cons to both partition keys and seeks opinions on the matter. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml b/static/bitcoin-dev/Sept_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml index 5c4c4a0763..6778af0361 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Merkle-branch-verification-tail-call-semantics-for-generalized-MAST.xml @@ -1,59 +1,167 @@ - + 2 Combined summary - Merkle branch verification & tail-call semantics for generalized MAST - 2023-08-01T21:47:30.334441+00:00 - - Luke Dashjr 2017-11-04 07:59:07+00:00 - - - Mark Friedenbach 2017-11-01 15:08:46+00:00 - - - Luke Dashjr 2017-11-01 08:43:48+00:00 - - - Mark Friedenbach 2017-10-28 04:40:01+00:00 - - - Russell O'Connor 2017-10-02 17:15:38+00:00 - - - Mark Friedenbach 2017-09-30 23:51:49+00:00 - - - Luke Dashjr 2017-09-30 23:23:32+00:00 - - - Mark Friedenbach 2017-09-19 00:46:30+00:00 - - - Peter Todd 2017-09-13 09:41:07+00:00 - - - Karl Johan Alm 2017-09-12 23:27:36+00:00 - - - Mark Friedenbach 2017-09-12 19:57:10+00:00 - - - Johnson Lau 2017-09-12 08:55:59+00:00 - - - Bryan Bishop 2017-09-12 02:13:24+00:00 - - - Mark Friedenbach 2017-09-12 02:03:42+00:00 - - - Adán Sánchez de Pedro Crespo 2017-09-11 20:37:55+00:00 - - - Johnson Lau 2017-09-08 09:21:22+00:00 - - - Mark Friedenbach 2017-09-07 00:38:55+00:00 - + 2025-09-26T15:48:50.424392+00:00 + python-feedgen + + + [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Mark Friedenbach + 2017-09-07T00:38:00.000Z + + + Johnson Lau + 2017-09-08T09:21:00.000Z + + + Adán Sánchez de Pedro Crespo + 2017-09-11T20:37:00.000Z + + + Mark Friedenbach + 2017-09-12T02:03:00.000Z + + + Bryan Bishop + 2017-09-12T02:13:00.000Z + + + Johnson Lau + 2017-09-12T08:55:00.000Z + + + Mark Friedenbach + 2017-09-12T19:57:00.000Z + + + Karl Johan Alm + 2017-09-12T23:27:00.000Z + + + Peter Todd + 2017-09-13T09:41:00.000Z + + + Mark Friedenbach + 2017-09-19T00:46:00.000Z + + + [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Luke Dashjr + 2017-09-19T03:09:00.000Z + + + Mark Friedenbach + 2017-09-19T07:33:00.000Z + + + [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Johnson Lau + 2017-09-20T05:13:00.000Z + + + Mark Friedenbach + 2017-09-20T19:29:00.000Z + + + Johnson Lau + 2017-09-21T03:58:00.000Z + + + Luke Dashjr + 2017-09-21T04:11:00.000Z + + + Johnson Lau + 2017-09-21T08:02:00.000Z + + + Luke Dashjr + 2017-09-21T16:33:00.000Z + + + Johnson Lau + 2017-09-21T17:38:00.000Z + + + Sergio Demian Lerner + 2017-09-22T20:32:00.000Z + + + Mark Friedenbach + 2017-09-22T21:11:00.000Z + + + Sergio Demian Lerner + 2017-09-22T21:32:00.000Z + + + Mark Friedenbach + 2017-09-22T21:39:00.000Z + + + Sergio Demian Lerner + 2017-09-22T21:54:00.000Z + + + Mark Friedenbach + 2017-09-22T22:07:00.000Z + + + Pieter Wuille + 2017-09-22T22:09:00.000Z + + + [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Luke Dashjr + 2017-09-30T23:23:00.000Z + + + Mark Friedenbach + 2017-09-30T23:51:00.000Z + + + Russell O'Connor + 2017-10-02T17:15:00.000Z + + + Mark Friedenbach + 2017-10-28T04:40:00.000Z + + + Luke Dashjr + 2017-11-01T08:43:00.000Z + + + Mark Friedenbach + 2017-11-01T15:08:00.000Z + + + Luke Dashjr + 2017-11-04T07:59:00.000Z + + + [bitcoin-dev] maximum block height on transaction Erik Aronesty + 2021-04-09T08:15:00.000Z + + + Russell O'Connor + 2021-04-09T11:39:00.000Z + + + Jeremy + 2021-04-09T15:54:00.000Z + + + Billy Tetrud + 2021-04-12T20:04:00.000Z + + + ZmnSCPxj + 2021-04-16T04:24:00.000Z + + + ZmnSCPxj + 2021-05-03T02:30:00.000Z + + @@ -71,13 +179,13 @@ - python-feedgen + 2 Combined summary - Merkle branch verification & tail-call semantics for generalized MAST - 2023-08-01T21:47:30.334441+00:00 + 2025-09-26T15:48:50.428719+00:00 - During a discussion on the bitcoin-dev mailing list, Mark Friedenbach and Johnson Lau discussed the use of OP_CHECKSIGADD and its vulnerability to Denial of Service (DoS) attacks. Friedenbach suggested using a new witness version instead, but Lau raised concerns about potential slowness. They debated design decisions for a new witness version, including tree signatures and MAST. The use of limits to prevent DoS attacks was also discussed, with Friedenbach proposing committing the total validation cost as the first witness stack item. He argued that the cost of implementing such changes would be worth it. Friedenbach also proposed an alternative solution involving removing certain lines of code from interpreter.cpp. Both proposals had different pros and cons and should not be purposefully restricted to compare head to head.Friedenbach apologized for the delay in responding to emails due to a cold. Lau had pointed out that tail-call execution semantics require an "unclean stack", which is invalid in BIP141. A new witness version could be used instead. Friedenbach disagreed with the current SigOp counting method used by Bitcoin, suggesting a single linear metric that combines all factors with appropriate coefficients. He proposed having the witness commit to the maximum resources consumed by validation of the spend of the coin. Maintaining static analysability for global limits was deemed important to prevent attacks on relay and mining nodes. There was also a suggestion to re-evaluate the need for counting SigOps other than for legacy consensus rule compliance. Witness script versioning was noted to be fully compatible with P2SH and BIP173. The minimal BIP114 solution could involve hiding scripts in a hash. A repository containing the latest implementation of BIP 114 can be found on GitHub.The email thread also included discussions about tail-call execution semantics, unclosed stacks, SigOp counting, and witness script versioning. Friedenbach highlighted an error regarding an "unclean stack" in a participant's comment. This mistake was also pointed out at the recent CoreDev meetup. The complexity of the BIP114 implementation was questioned, and there was a query regarding the availability of a repository for the latest BIP 114 implementation. Links to the original BIP114 and its revised versions were provided.In another discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed two new features to be added to the Bitcoin protocol via soft-fork activation. These features are MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics. MBV allows script authors to force redemption to use values selected from a pre-determined set committed to in the scriptPubKey, without revealing unused elements in the set for enhanced privacy and smaller script sizes. Tail-call execution semantics allow a single level of recursion into a subscript, providing properties similar to P2SH while being more flexible. Friedenbach believed that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects.During a discussion about the MAST proposal, there was a suggestion to have different opcodes for single vs multi-element MBV for script analysis purposes. However, it was countered that static analysability can be maintained if the script encodes the number of elements as an integer push to the top of the stack immediately before the opcode. Mark Friedenbach was assigned the task of investigating an ideal serialization format for a multi-element proof, which is the only thing holding back a multi-element MBV proposal. The discussion also touched on tail-call semantics, script version upgrades, and other related issues.Overall, Mark Friedenbach has proposed two new features, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics, to be added to the Bitcoin protocol. These features provide enhanced privacy, smaller script sizes, and flexibility in script execution. Friedenbach believes that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects. 2017-11-04T07:59:07+00:00 + During a discussion on the bitcoin-dev mailing list, Mark Friedenbach and Johnson Lau discussed the use of OP_CHECKSIGADD and its vulnerability to Denial of Service (DoS) attacks. Friedenbach suggested using a new witness version instead, but Lau raised concerns about potential slowness. They debated design decisions for a new witness version, including tree signatures and MAST. The use of limits to prevent DoS attacks was also discussed, with Friedenbach proposing committing the total validation cost as the first witness stack item. He argued that the cost of implementing such changes would be worth it. Friedenbach also proposed an alternative solution involving removing certain lines of code from interpreter.cpp. Both proposals had different pros and cons and should not be purposefully restricted to compare head to head.Friedenbach apologized for the delay in responding to emails due to a cold. Lau had pointed out that tail-call execution semantics require an "unclean stack", which is invalid in BIP141. A new witness version could be used instead. Friedenbach disagreed with the current SigOp counting method used by Bitcoin, suggesting a single linear metric that combines all factors with appropriate coefficients. He proposed having the witness commit to the maximum resources consumed by validation of the spend of the coin. Maintaining static analysability for global limits was deemed important to prevent attacks on relay and mining nodes. There was also a suggestion to re-evaluate the need for counting SigOps other than for legacy consensus rule compliance. Witness script versioning was noted to be fully compatible with P2SH and BIP173. The minimal BIP114 solution could involve hiding scripts in a hash. A repository containing the latest implementation of BIP 114 can be found on GitHub.The email thread also included discussions about tail-call execution semantics, unclosed stacks, SigOp counting, and witness script versioning. Friedenbach highlighted an error regarding an "unclean stack" in a participant's comment. This mistake was also pointed out at the recent CoreDev meetup. The complexity of the BIP114 implementation was questioned, and there was a query regarding the availability of a repository for the latest BIP 114 implementation. Links to the original BIP114 and its revised versions were provided.In another discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed two new features to be added to the Bitcoin protocol via soft-fork activation. These features are MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics. MBV allows script authors to force redemption to use values selected from a pre-determined set committed to in the scriptPubKey, without revealing unused elements in the set for enhanced privacy and smaller script sizes. Tail-call execution semantics allow a single level of recursion into a subscript, providing properties similar to P2SH while being more flexible. Friedenbach believed that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects.During a discussion about the MAST proposal, there was a suggestion to have different opcodes for single vs multi-element MBV for script analysis purposes. However, it was countered that static analysability can be maintained if the script encodes the number of elements as an integer push to the top of the stack immediately before the opcode. Mark Friedenbach was assigned the task of investigating an ideal serialization format for a multi-element proof, which is the only thing holding back a multi-element MBV proposal. The discussion also touched on tail-call semantics, script version upgrades, and other related issues.Overall, Mark Friedenbach has proposed two new features, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution semantics, to be added to the Bitcoin protocol. These features provide enhanced privacy, smaller script sizes, and flexibility in script execution. Friedenbach believes that the implementation of these features is simple enough and the use cases compelling enough for a BIP 8/9 rollout. Feedback and discussions have led to modifications and improvements to the proposals, but further thought is required on some aspects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Minutia-in-CT-for-Bitcoin-Was-SF-proposal-prohibit-unspendable-outputs-with-amount-0.xml b/static/bitcoin-dev/Sept_2017/combined_Minutia-in-CT-for-Bitcoin-Was-SF-proposal-prohibit-unspendable-outputs-with-amount-0.xml index f5a553177b..18c0c881c2 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Minutia-in-CT-for-Bitcoin-Was-SF-proposal-prohibit-unspendable-outputs-with-amount-0.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Minutia-in-CT-for-Bitcoin-Was-SF-proposal-prohibit-unspendable-outputs-with-amount-0.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Minutia in CT for Bitcoin. Was: SF proposal: prohibit unspendable outputs with amount=0 - 2023-08-01T21:52:21.715677+00:00 - - Peter Todd 2017-09-13 10:03:28+00:00 - - - Gregory Maxwell 2017-09-13 09:39:28+00:00 - + 2025-09-26T15:49:02.997056+00:00 + python-feedgen + + + [bitcoin-dev] Minutia in CT for Bitcoin. Was: SF proposal: prohibit unspendable outputs with amount=0 Gregory Maxwell + 2017-09-13T09:39:00.000Z + + + Peter Todd + 2017-09-13T10:03:00.000Z + + - python-feedgen + 2 Combined summary - Minutia in CT for Bitcoin. Was: SF proposal: prohibit unspendable outputs with amount=0 - 2023-08-01T21:52:21.715677+00:00 + 2025-09-26T15:49:02.997574+00:00 - In a bitcoin-dev email thread, Gregory Maxwell raised the issue of pool inputs being non-reorg safe and whether there is a solution to this problem without implementing a maturity limit for shielded to unshielded. The problem arises from the fact that CT signatures do not sign which pool input they're using. One possible solution suggested was to have miners add the exact CT pool input, which would reduce the reorg risk to double-spends. However, this approach may not be practical as wallets would randomly select the input. The current best solution proposed is to support unshielded coins in the shielded space as well. This means that users can "use" CT even with unshielded outputs, ensuring that the non-reorg safety issue is not a problem. The proposal suggests transitioning out of the pool only when paying to a legacy wallet. If this support is gradually phased in and the pool is only used after wallets have adopted it, the occurrence of transitioning out of the pool would be rare, making a maturity limit less significant.In a related bitcoin-dev thread, Peter Todd discussed spending CT-shielded outputs to unshielded outputs and addressed the issue of pool inputs being gratuitously non-reorg safe. To compensate for the zero value of the CT-shielded outputs, one or more outputs from the CT pool are spent, with any change assigned to a CT-pool output. However, this approach poses a problem as the pool inputs are not reorg safe.The proposed solution, once again, is to support unshielded coins in the shielded space. By doing so, the transition out of the pool would only occur when paying to a legacy wallet. It is suggested that if support for this transition is gradually introduced and the pool is only utilized long after wallets have adapted to receiving payments in it, the need for a maturity limit would be minimized.Both discussions conclude with the question of whether there is a better solution to the problem at hand, indicating that further exploration and brainstorming are needed in order to find the most effective resolution. 2017-09-13T10:03:28+00:00 + In a bitcoin-dev email thread, Gregory Maxwell raised the issue of pool inputs being non-reorg safe and whether there is a solution to this problem without implementing a maturity limit for shielded to unshielded. The problem arises from the fact that CT signatures do not sign which pool input they're using. One possible solution suggested was to have miners add the exact CT pool input, which would reduce the reorg risk to double-spends. However, this approach may not be practical as wallets would randomly select the input. The current best solution proposed is to support unshielded coins in the shielded space as well. This means that users can "use" CT even with unshielded outputs, ensuring that the non-reorg safety issue is not a problem. The proposal suggests transitioning out of the pool only when paying to a legacy wallet. If this support is gradually phased in and the pool is only used after wallets have adopted it, the occurrence of transitioning out of the pool would be rare, making a maturity limit less significant.In a related bitcoin-dev thread, Peter Todd discussed spending CT-shielded outputs to unshielded outputs and addressed the issue of pool inputs being gratuitously non-reorg safe. To compensate for the zero value of the CT-shielded outputs, one or more outputs from the CT pool are spent, with any change assigned to a CT-pool output. However, this approach poses a problem as the pool inputs are not reorg safe.The proposed solution, once again, is to support unshielded coins in the shielded space. By doing so, the transition out of the pool would only occur when paying to a legacy wallet. It is suggested that if support for this transition is gradually introduced and the pool is only utilized long after wallets have adapted to receiving payments in it, the need for a maturity limit would be minimized.Both discussions conclude with the question of whether there is a better solution to the problem at hand, indicating that further exploration and brainstorming are needed in order to find the most effective resolution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_P2WPKH-Scripts-P2PKH-Addresses-and-Uncompressed-Public-Keys.xml b/static/bitcoin-dev/Sept_2017/combined_P2WPKH-Scripts-P2PKH-Addresses-and-Uncompressed-Public-Keys.xml index 0654112a33..3b0cf97f52 100644 --- a/static/bitcoin-dev/Sept_2017/combined_P2WPKH-Scripts-P2PKH-Addresses-and-Uncompressed-Public-Keys.xml +++ b/static/bitcoin-dev/Sept_2017/combined_P2WPKH-Scripts-P2PKH-Addresses-and-Uncompressed-Public-Keys.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys - 2023-08-01T21:29:19.658245+00:00 - - Peter Todd 2017-09-04 13:51:35+00:00 - - - Johnson Lau 2017-08-29 03:30:07+00:00 - - - Mark Friedenbach 2017-08-28 21:33:52+00:00 - - - Alex Nagy 2017-08-28 20:55:47+00:00 - - - Alex Nagy 2017-08-28 15:29:31+00:00 - + 2025-09-26T15:48:29.355992+00:00 + python-feedgen + + + [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys Alex Nagy + 2017-08-28T15:29:00.000Z + + + [bitcoin-dev] Fwd: " Gregory Maxwell + 2017-08-28T17:06:00.000Z + + + [bitcoin-dev] " Alex Nagy + 2017-08-28T20:55:00.000Z + + + Mark Friedenbach + 2017-08-28T21:33:00.000Z + + + Johnson Lau + 2017-08-29T03:30:00.000Z + + + Peter Todd + 2017-09-04T13:51:00.000Z + + - python-feedgen + 2 Combined summary - P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys - 2023-08-01T21:29:19.658245+00:00 + 2025-09-26T15:48:29.356800+00:00 - In a recent discussion on the bitcoin-dev mailing list, there was a question raised about whether native P2WPKH scripts should only be used in redeem scripts or if they could also be encoded in TxOuts. The purpose of this would be to save space in transactions with multiple outputs. Gregory Maxwell responded by saying that native P2WPKH and P2WSH are indeed valid and identifiable even when encoded in TxOuts. However, he cautioned against assuming that the recipient understands this new format. If someone wants to utilize this method to save space, they should first request a new BIP173 address from the recipient instead of converting a P2PKH address without consent.Another topic that came up in the Bitcoin-dev forum discussion was whether Bob can safely issue native P2WPKH outputs to Alice if she provides him with a specific address. The answer to this question is no, and it does not matter whether the address is compressed or uncompressed. If Alice provides Bob with a specific address, she is essentially stating that she will only accept payment to the scriptPubKey associated with that address. Any payment made to a different scriptPubKey may not be recognized by Alice.In an email exchange between Alex Nagy and Gregory Maxwell, the question was posed about whether Bob can issue native P2WPKH outputs to Alice if she gives him the address 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a. Gregory's response was that it is not possible to pay someone to a script pubkey that they have not specified. Attempting to construct an alternative script pubkey would be akin to burying a check in a locked safe labeled "danger radioactive" in someone's backyard. While there have been instances where wallets displayed outputs they didn't generate but could spend, these cases are considered flaws and cannot be relied upon for all situations. Furthermore, if uncompressed keys are used, it could render the payment unspendable.The context also mentions that Alice has a P2PKH address derived from an uncompressed public key. However, BIPs 141 and 143 state that P2WPKH scripts can only be derived from compressed public keys. Due to this restriction, if Alice were to provide Bob with her P2PKH address, he would not be able to safely issue native P2WPKH outputs to her because he would have no way of knowing whether her P2PKH address represents a compressed or uncompressed public key. The existing P2PKH address format is generally considered unsafe to use with SegWit since it allows for addresses derived from uncompressed public keys. Transactions that violate the rule of using compressed public keys in P2WPKH and P2WSH will not be relayed or mined by default, as stated in BIP143. To avoid potential loss of funds in the future, users should refrain from using uncompressed keys in version 0 witness programs. 2017-09-04T13:51:35+00:00 + In a recent discussion on the bitcoin-dev mailing list, there was a question raised about whether native P2WPKH scripts should only be used in redeem scripts or if they could also be encoded in TxOuts. The purpose of this would be to save space in transactions with multiple outputs. Gregory Maxwell responded by saying that native P2WPKH and P2WSH are indeed valid and identifiable even when encoded in TxOuts. However, he cautioned against assuming that the recipient understands this new format. If someone wants to utilize this method to save space, they should first request a new BIP173 address from the recipient instead of converting a P2PKH address without consent.Another topic that came up in the Bitcoin-dev forum discussion was whether Bob can safely issue native P2WPKH outputs to Alice if she provides him with a specific address. The answer to this question is no, and it does not matter whether the address is compressed or uncompressed. If Alice provides Bob with a specific address, she is essentially stating that she will only accept payment to the scriptPubKey associated with that address. Any payment made to a different scriptPubKey may not be recognized by Alice.In an email exchange between Alex Nagy and Gregory Maxwell, the question was posed about whether Bob can issue native P2WPKH outputs to Alice if she gives him the address 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a. Gregory's response was that it is not possible to pay someone to a script pubkey that they have not specified. Attempting to construct an alternative script pubkey would be akin to burying a check in a locked safe labeled "danger radioactive" in someone's backyard. While there have been instances where wallets displayed outputs they didn't generate but could spend, these cases are considered flaws and cannot be relied upon for all situations. Furthermore, if uncompressed keys are used, it could render the payment unspendable.The context also mentions that Alice has a P2PKH address derived from an uncompressed public key. However, BIPs 141 and 143 state that P2WPKH scripts can only be derived from compressed public keys. Due to this restriction, if Alice were to provide Bob with her P2PKH address, he would not be able to safely issue native P2WPKH outputs to her because he would have no way of knowing whether her P2PKH address represents a compressed or uncompressed public key. The existing P2PKH address format is generally considered unsafe to use with SegWit since it allows for addresses derived from uncompressed public keys. Transactions that violate the rule of using compressed public keys in P2WPKH and P2WSH will not be relayed or mined by default, as stated in BIP143. To avoid potential loss of funds in the future, users should refrain from using uncompressed keys in version 0 witness programs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Paper-Wallet-support-in-bitcoin-core.xml b/static/bitcoin-dev/Sept_2017/combined_Paper-Wallet-support-in-bitcoin-core.xml index 0425a05b1e..a9a1167bcd 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Paper-Wallet-support-in-bitcoin-core.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Paper-Wallet-support-in-bitcoin-core.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Paper Wallet support in bitcoin-core - 2023-08-01T21:59:12.195304+00:00 - - Aymeric Vitte 2017-09-30 23:51:12+00:00 - - - Jonas Schnelli 2017-09-30 21:14:44+00:00 - - - Aymeric Vitte 2017-09-30 11:10:45+00:00 - - - Adam Ritter 2017-09-30 09:35:05+00:00 - - - Sjors Provoost 2017-09-30 07:36:46+00:00 - - - Dan Libby 2017-09-30 07:06:42+00:00 - - - Jonas Schnelli 2017-09-30 04:49:52+00:00 - - - Dan Libby 2017-09-29 22:19:46+00:00 - - - Dan Libby 2017-09-29 22:13:47+00:00 - - - Sjors Provoost 2017-09-29 20:21:48+00:00 - - - Dan Libby 2017-09-29 20:13:59+00:00 - - - Dan Libby 2017-09-29 19:34:57+00:00 - - - Andrew Johnson 2017-09-29 18:07:26+00:00 - - - Dan Libby 2017-09-29 17:29:17+00:00 - + 2025-09-26T15:49:26.187753+00:00 + python-feedgen + + + [bitcoin-dev] Paper Wallet support in bitcoin-core Dan Libby + 2017-09-29T17:29:00.000Z + + + Andrew Johnson + 2017-09-29T18:07:00.000Z + + + Dan Libby + 2017-09-29T19:34:00.000Z + + + Dan Libby + 2017-09-29T20:13:00.000Z + + + Sjors Provoost + 2017-09-29T20:21:00.000Z + + + Dan Libby + 2017-09-29T22:13:00.000Z + + + Dan Libby + 2017-09-29T22:19:00.000Z + + + Jonas Schnelli + 2017-09-30T04:49:00.000Z + + + Dan Libby + 2017-09-30T07:06:00.000Z + + + Sjors Provoost + 2017-09-30T07:36:00.000Z + + + Adam Ritter + 2017-09-30T09:35:00.000Z + + + Aymeric Vitte + 2017-09-30T11:10:00.000Z + + + Jonas Schnelli + 2017-09-30T21:14:00.000Z + + + Aymeric Vitte + 2017-09-30T23:51:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Paper Wallet support in bitcoin-core - 2023-08-01T21:59:12.195304+00:00 + 2025-09-26T15:49:26.189469+00:00 - The Bitcoin-dev mailing list has been discussing concerns about the security of the Bitcoin Core wallet, specifically regarding key generation and storage. The proposal suggests creating a simple offline module to serve as a "wallet" and allow users to conduct transactions offline before sending them to the network. However, this process is complicated and unfinished, requiring users to be somewhat online. The use of paper wallets is deemed insecure due to address reuse and unclear spending procedures. Printer buffers also pose a problem. To improve security, it is suggested that certain RPCs be removed from bitcoin-core. Trust is highlighted as an important factor, with increasing demand for hardware wallets due to a lack of trust in current operating systems and CPUs. While there are no existing solutions to address all the issues, improving security is a priority.Currently, the Bitcoin Core wallet shares the same process and memory space with the full node, making it less than ideal. There is limited support for offline signing, except for the rawtx API. The proposed RPC call would generate a key/address that is not stored in the internal wallet, allowing users to store it offline or use it as they wish. However, concerns are raised about paper wallets being insecure and the need to trust additional software outside of Bitcoin Core. The removal of certain RPCs from Bitcoin Core is being considered. Private keys should be generated and used on trusted offline hardware/os, with encrypted backups and a footgun-safe restore process. While there are currently no existing solutions, efforts should be made to address these concerns.The author raises concerns about the security of private keys and the difficulty of managing them. They suggest generating and using keys on trusted offline hardware/os. Backups should be encrypted and the restore process should be footgun-safe. The author also questions the effectiveness of proposals like BIP39 and suggests exploring existing solutions. GitHub pages showcasing simple wallets for Bitcoin and Zcash, as well as a dynamic blocklist for torrents and anti-spies, are provided as references.An individual proposes extending the Glacier Protocol and using BIP45 Multisig HD Wallets instead of multisig addresses. They emphasize generating and using private keys on trusted offline hardware/os. Paper wallets are considered unsafe and insecure. Backups should be encrypted and the restore process should be footgun-safe. The individual suggests using bitcoin-core-dev or GitHub for submissions.Luke Dashjr and Jonas Schnelli agree that paper wallets are unsafe and insecure. Schnelli believes private keys should be generated and used offline on trusted hardware and OS, with encrypted backups and a secure restore process. There is uncertainty about the trade-off between security and usability. It is suggested that individual wallets should decide.In the discussion, it is agreed that client implementations should be directed to the bitcoin-core-dev mailing list or GitHub. Concerns are raised about BIP39 plaintext paper backups. Private keys should be generated and used offline on trusted hardware and OS. The proposed RPC call would generate a key/address not stored in the internal wallet. Trust is a crucial factor, and users should be able to view or export private keys. Backups should be encrypted and footgun-safe.The proposal suggests adding paper wallet functionality to bitcoin-core software through a new RPC call. However, concerns are raised about the security of paper wallets and the need to generate them in an air-gapped environment. The author recommends using bitcoin-core on a dedicated offline machine for key generation. They also suggest including a modal dialog in the QT UI to inform users about the lack of security when generating paper wallets online. The proposed API is simple to implement and provides enough functionality for developers and advanced users. Further steps could include generating an external HD wallet seed and GUI functionality in bitcoin-qt for easy paper wallet generation.Dan Libby proposes adding paper wallet functionality to bitcoin-core software. He suggests a new RPC call to generate Bitcoin addresses and private keys for receiving payments. This eliminates the need for third-party software and provides a more secure option. The proposed API is simple to implement and can be used by developers or advanced users. Further steps could include generating an external HD wallet seed and GUI functionality in bitcoin-qt for easy paper wallet generation.Andrew Johnson raises concerns about generating paper wallets from online machines, suggesting that bitcoin-core should be installed on a dedicated offline machine for key generation. He recommends informing users through a modal dialog in the QT UI about the lack of security when generating paper wallets online. The prompt must be accepted before providing the requested keys.The proposal suggests adding paper wallet functionality to bitcoin-core software through a new RPC call. This would eliminate the need for third-party tools and provide a more secure option. To address concerns about generating paper wallets from online machines, it is suggested that any UI in QT include a modal dialog informing users about the lack of security. The proposed API is simple to implement and provides enough functionality for developers and advanced users. Further steps could include an RPC call to generate an external HD wallet seed and GUI functionality in bitcoin-qt for easy paper wallet generation. 2017-09-30T23:51:12+00:00 + The Bitcoin-dev mailing list has been discussing concerns about the security of the Bitcoin Core wallet, specifically regarding key generation and storage. The proposal suggests creating a simple offline module to serve as a "wallet" and allow users to conduct transactions offline before sending them to the network. However, this process is complicated and unfinished, requiring users to be somewhat online. The use of paper wallets is deemed insecure due to address reuse and unclear spending procedures. Printer buffers also pose a problem. To improve security, it is suggested that certain RPCs be removed from bitcoin-core. Trust is highlighted as an important factor, with increasing demand for hardware wallets due to a lack of trust in current operating systems and CPUs. While there are no existing solutions to address all the issues, improving security is a priority.Currently, the Bitcoin Core wallet shares the same process and memory space with the full node, making it less than ideal. There is limited support for offline signing, except for the rawtx API. The proposed RPC call would generate a key/address that is not stored in the internal wallet, allowing users to store it offline or use it as they wish. However, concerns are raised about paper wallets being insecure and the need to trust additional software outside of Bitcoin Core. The removal of certain RPCs from Bitcoin Core is being considered. Private keys should be generated and used on trusted offline hardware/os, with encrypted backups and a footgun-safe restore process. While there are currently no existing solutions, efforts should be made to address these concerns.The author raises concerns about the security of private keys and the difficulty of managing them. They suggest generating and using keys on trusted offline hardware/os. Backups should be encrypted and the restore process should be footgun-safe. The author also questions the effectiveness of proposals like BIP39 and suggests exploring existing solutions. GitHub pages showcasing simple wallets for Bitcoin and Zcash, as well as a dynamic blocklist for torrents and anti-spies, are provided as references.An individual proposes extending the Glacier Protocol and using BIP45 Multisig HD Wallets instead of multisig addresses. They emphasize generating and using private keys on trusted offline hardware/os. Paper wallets are considered unsafe and insecure. Backups should be encrypted and the restore process should be footgun-safe. The individual suggests using bitcoin-core-dev or GitHub for submissions.Luke Dashjr and Jonas Schnelli agree that paper wallets are unsafe and insecure. Schnelli believes private keys should be generated and used offline on trusted hardware and OS, with encrypted backups and a secure restore process. There is uncertainty about the trade-off between security and usability. It is suggested that individual wallets should decide.In the discussion, it is agreed that client implementations should be directed to the bitcoin-core-dev mailing list or GitHub. Concerns are raised about BIP39 plaintext paper backups. Private keys should be generated and used offline on trusted hardware and OS. The proposed RPC call would generate a key/address not stored in the internal wallet. Trust is a crucial factor, and users should be able to view or export private keys. Backups should be encrypted and footgun-safe.The proposal suggests adding paper wallet functionality to bitcoin-core software through a new RPC call. However, concerns are raised about the security of paper wallets and the need to generate them in an air-gapped environment. The author recommends using bitcoin-core on a dedicated offline machine for key generation. They also suggest including a modal dialog in the QT UI to inform users about the lack of security when generating paper wallets online. The proposed API is simple to implement and provides enough functionality for developers and advanced users. Further steps could include generating an external HD wallet seed and GUI functionality in bitcoin-qt for easy paper wallet generation.Dan Libby proposes adding paper wallet functionality to bitcoin-core software. He suggests a new RPC call to generate Bitcoin addresses and private keys for receiving payments. This eliminates the need for third-party software and provides a more secure option. The proposed API is simple to implement and can be used by developers or advanced users. Further steps could include generating an external HD wallet seed and GUI functionality in bitcoin-qt for easy paper wallet generation.Andrew Johnson raises concerns about generating paper wallets from online machines, suggesting that bitcoin-core should be installed on a dedicated offline machine for key generation. He recommends informing users through a modal dialog in the QT UI about the lack of security when generating paper wallets online. The prompt must be accepted before providing the requested keys.The proposal suggests adding paper wallet functionality to bitcoin-core software through a new RPC call. This would eliminate the need for third-party tools and provide a more secure option. To address concerns about generating paper wallets from online machines, it is suggested that any UI in QT include a modal dialog informing users about the lack of security. The proposed API is simple to implement and provides enough functionality for developers and advanced users. Further steps could include an RPC call to generate an external HD wallet seed and GUI functionality in bitcoin-qt for easy paper wallet generation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32-wallets.xml b/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32-wallets.xml index fdd5a39c6f..d405604c75 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32-wallets.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32-wallets.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - Proposal: Extended serialization format for BIP-32 wallets - 2023-08-01T21:46:12.451769+00:00 - - Thomas Voegtlin 2017-09-07 20:39:17+00:00 - - - Pavol Rusnak 2017-09-07 20:00:05+00:00 - - - Andreas Schildbach 2017-09-07 19:35:49+00:00 - - - Pavol Rusnak 2017-09-07 18:38:37+00:00 - - - Peter Todd 2017-09-07 18:09:02+00:00 - - - Peter Todd 2017-09-07 18:02:56+00:00 - - - Jonas Schnelli 2017-09-07 16:47:16+00:00 - - - Pavol Rusnak 2017-09-07 16:37:19+00:00 - - - Kabuto Samourai 2017-09-07 16:33:09+00:00 - - - Kabuto Samourai 2017-09-07 16:30:06+00:00 - - - Pavol Rusnak 2017-09-07 16:25:30+00:00 - - - Pavol Rusnak 2017-09-07 16:23:13+00:00 - - - Thomas Voegtlin 2017-09-07 04:29:32+00:00 - - - Kabuto Samourai 2017-09-07 03:52:57+00:00 - - - Pavol Rusnak 2017-09-06 22:29:23+00:00 - + 2025-09-26T15:48:35.652646+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets Pavol Rusnak + 2017-09-06T22:29:00.000Z + + + Kabuto Samourai + 2017-09-07T03:52:00.000Z + + + Thomas Voegtlin + 2017-09-07T04:29:00.000Z + + + Pavol Rusnak + 2017-09-07T16:23:00.000Z + + + Pavol Rusnak + 2017-09-07T16:25:00.000Z + + + Kabuto Samourai + 2017-09-07T16:30:00.000Z + + + Kabuto Samourai + 2017-09-07T16:33:00.000Z + + + Pavol Rusnak + 2017-09-07T16:37:00.000Z + + + Jonas Schnelli + 2017-09-07T16:47:00.000Z + + + Peter Todd + 2017-09-07T18:02:00.000Z + + + Peter Todd + 2017-09-07T18:09:00.000Z + + + Pavol Rusnak + 2017-09-07T18:38:00.000Z + + + Andreas Schildbach + 2017-09-07T19:35:00.000Z + + + Pavol Rusnak + 2017-09-07T20:00:00.000Z + + + Thomas Voegtlin + 2017-09-07T20:39:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - Proposal: Extended serialization format for BIP-32 wallets - 2023-08-01T21:46:12.452767+00:00 + 2025-09-26T15:48:35.654298+00:00 - In a discussion on the bitcoin-dev mailing list, Pavol Rusnak proposed adding an additional byte field called OutputType for wallets that do not follow BIP43. The field would have three options: P2PKH output type, P2WPKH-in-P2SH output type, and native Segwit output type. However, Thomas Voegtlin raised concerns about the visibility of this field for users. Voegtlin argued that the flag for segwit xpub/xprv in Electrum should be user visible to ensure all cosigners agree on the script type used to derive addresses. Andreas Schildbach and Pavol Rusnak discussed the issue of exported public key depth in Bitcoin Wallet. They agreed that the path should always be present if a chain is limited to a certain script type. However, there may be cases where script types are mixed on one chain, and in such cases, the field should be omitted, and the wallet needs to scan for all known types.In another discussion, Jonas Schnelli and Pavol Rusnak explored the possibility of reducing the resolution for a field in order to save space. They considered using week-level or month-level resolution, which would allow them to use just 16 bits for the field. Schnelli also questioned whether it would make sense to have special depth bytes that directly imply it's a BIP44 master key. However, Rusnak didn't see any good reason to do this unless they wanted to save some bytes. The email exchange focused on finding ways to optimize space usage while maintaining privacy and ease of use for wallets.The discussion on the bitcoin-dev mailing list revolved around using a block height or a timestamp for XPUB. It was pointed out that block height depends on the chain, while XPUB is not tied to any particular chain/coin. Some cryptocurrencies use directed acyclic graph (DAG) instead of blockchain for storing transactions, making it unclear what number to use as a block height. However, all blockchains contain timestamps in their blocks, which can be used for XPUB. The author expressed interest in hearing about a blockchain that does not occupy our spacetime continuum.Pavol Rusnak proposed a change to BIP32 version bytes for SegWit wallets. The proposal suggests using 13 or 16 bits to represent the birthday of private keys and rounding down to the beginning of the week when the key was created. It also proposes creating special depth bytes that directly imply it's a BIP44 master key and adding a version bit for future extensions. Jonas Schnelli suggested reducing the resolution for the field if necessary for privacy reasons. The email exchange focused on optimizing space usage while maintaining privacy and ease of use for wallets.The discussion on the bitcoin-dev mailing list raised the issue of including a birthday field in the blockchain. SPV wallet developers have been wanting this for years as it helps with the initial scan by only downloading blocks after the birthday. Test vectors were requested to be added for the inclusion of the birthday field. Minor grammar and spelling errors were also noted, which will be addressed at a later stage.The inclusion of a birthday field in SPV wallets was discussed between Kabuto Samourai and Pavol Rusnak. This development would aid with initial scans, allowing an SPV wallet to only download blocks from the blockchain after its birthday. Test vectors were requested and minor grammar and spelling errors were pointed out, which will be addressed later.Thomas Voegtlin proposed adding another byte field called OutputType for wallets that do not follow BIP43. The field would include options for P2PKH output type, P2WPKH-in-P2SH output type, and native Segwit output type. Concerns were raised about the visibility of this field for users, and suggestions were made to improve user visibility. Pavol Rusnak proposed a change to bip32 version bytes for SegWit, which was shared on GitHub. The proposal aims to extend BIP32 and improve it further. Feedback and comments are welcome. 2017-09-07T20:39:17+00:00 + In a discussion on the bitcoin-dev mailing list, Pavol Rusnak proposed adding an additional byte field called OutputType for wallets that do not follow BIP43. The field would have three options: P2PKH output type, P2WPKH-in-P2SH output type, and native Segwit output type. However, Thomas Voegtlin raised concerns about the visibility of this field for users. Voegtlin argued that the flag for segwit xpub/xprv in Electrum should be user visible to ensure all cosigners agree on the script type used to derive addresses. Andreas Schildbach and Pavol Rusnak discussed the issue of exported public key depth in Bitcoin Wallet. They agreed that the path should always be present if a chain is limited to a certain script type. However, there may be cases where script types are mixed on one chain, and in such cases, the field should be omitted, and the wallet needs to scan for all known types.In another discussion, Jonas Schnelli and Pavol Rusnak explored the possibility of reducing the resolution for a field in order to save space. They considered using week-level or month-level resolution, which would allow them to use just 16 bits for the field. Schnelli also questioned whether it would make sense to have special depth bytes that directly imply it's a BIP44 master key. However, Rusnak didn't see any good reason to do this unless they wanted to save some bytes. The email exchange focused on finding ways to optimize space usage while maintaining privacy and ease of use for wallets.The discussion on the bitcoin-dev mailing list revolved around using a block height or a timestamp for XPUB. It was pointed out that block height depends on the chain, while XPUB is not tied to any particular chain/coin. Some cryptocurrencies use directed acyclic graph (DAG) instead of blockchain for storing transactions, making it unclear what number to use as a block height. However, all blockchains contain timestamps in their blocks, which can be used for XPUB. The author expressed interest in hearing about a blockchain that does not occupy our spacetime continuum.Pavol Rusnak proposed a change to BIP32 version bytes for SegWit wallets. The proposal suggests using 13 or 16 bits to represent the birthday of private keys and rounding down to the beginning of the week when the key was created. It also proposes creating special depth bytes that directly imply it's a BIP44 master key and adding a version bit for future extensions. Jonas Schnelli suggested reducing the resolution for the field if necessary for privacy reasons. The email exchange focused on optimizing space usage while maintaining privacy and ease of use for wallets.The discussion on the bitcoin-dev mailing list raised the issue of including a birthday field in the blockchain. SPV wallet developers have been wanting this for years as it helps with the initial scan by only downloading blocks after the birthday. Test vectors were requested to be added for the inclusion of the birthday field. Minor grammar and spelling errors were also noted, which will be addressed at a later stage.The inclusion of a birthday field in SPV wallets was discussed between Kabuto Samourai and Pavol Rusnak. This development would aid with initial scans, allowing an SPV wallet to only download blocks from the blockchain after its birthday. Test vectors were requested and minor grammar and spelling errors were pointed out, which will be addressed later.Thomas Voegtlin proposed adding another byte field called OutputType for wallets that do not follow BIP43. The field would include options for P2PKH output type, P2WPKH-in-P2SH output type, and native Segwit output type. Concerns were raised about the visibility of this field for users, and suggestions were made to improve user visibility. Pavol Rusnak proposed a change to bip32 version bytes for SegWit, which was shared on GitHub. The proposal aims to extend BIP32 and improve it further. Feedback and comments are welcome. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32.xml b/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32.xml index 684ead212b..59deef71e8 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: Extended serialization format for BIP-32 - 2023-08-01T21:50:34.851343+00:00 + 2025-09-26T15:48:37.770818+00:00 + python-feedgen shiva sitamraju 2017-09-12 12:06:40+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Proposal: Extended serialization format for BIP-32 - 2023-08-01T21:50:34.851343+00:00 + 2025-09-26T15:48:37.770971+00:00 - The Bitcoin-dev mailing list recently had two discussions. The first discussion focused on Merkle branch verification and tail-call semantics for generalized MAST. Johnson Lau and Mark Friedenbach discussed the design concerns, including the use of "unclean stake" which is invalid in BIP141. They also discussed SigOp counting and suggested a unified global limit that combines all factors. In the second discussion, Thomas Voegtlin proposed an extended serialization format for BIP-32 wallets. Shiva Sitamraju expressed concerns about the privacy implications of the birth-date field and the complete derivation path. Thomas replied that different versions do not have the same address as per bip173. The debate also included whether the OutputType field should be present only if depth==0x00 or at all times. Andreas Schildbach, Pavol Rusnak, and Thomas Voegtlin shared their opinions on the issue.Another discussion focused on Mark Friedenbach's proposal to update the fast Merkle-tree spec to use a different IV. This would prevent attacks where innocent scripts could be replaced by malicious ones. The attack requires a collision between double-SHA256(innocuous) and fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) || r1) || r0).There was also talk about whether to add an extended serialization format for BIP-32 wallets. Suggestions were made to add an OutputType field for wallets that do not follow BIP43, while others suggested omitting the field in cases where script types are mixed. Thomas Voegtlin suggested that this value should be user visible, as users need to combine several master public keys when creating wallets with multisig scripts.It was noted that good security for Bitcoin is not defined by constant upgrading, and efforts should be put into backporting fixes/workarounds. Altcoin maintainers were encouraged to contribute back to their upstream to help keep up with security fixes. Sergio Demian Lerner mentioned the policy of publishing vulnerabilities in Bitcoin only after more than 80% of the nodes have upgraded.Overall, the discussions on the Bitcoin-dev mailing list covered various topics such as Merkle branch verification, tail-call semantics, serialization format for BIP-32 wallets, trust in scripts, and preventing attacks on MAST policy. Different perspectives were shared, and suggestions were made to improve the design and security of Bitcoin. 2017-09-12T12:06:40+00:00 + The Bitcoin-dev mailing list recently had two discussions. The first discussion focused on Merkle branch verification and tail-call semantics for generalized MAST. Johnson Lau and Mark Friedenbach discussed the design concerns, including the use of "unclean stake" which is invalid in BIP141. They also discussed SigOp counting and suggested a unified global limit that combines all factors. In the second discussion, Thomas Voegtlin proposed an extended serialization format for BIP-32 wallets. Shiva Sitamraju expressed concerns about the privacy implications of the birth-date field and the complete derivation path. Thomas replied that different versions do not have the same address as per bip173. The debate also included whether the OutputType field should be present only if depth==0x00 or at all times. Andreas Schildbach, Pavol Rusnak, and Thomas Voegtlin shared their opinions on the issue.Another discussion focused on Mark Friedenbach's proposal to update the fast Merkle-tree spec to use a different IV. This would prevent attacks where innocent scripts could be replaced by malicious ones. The attack requires a collision between double-SHA256(innocuous) and fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) || r1) || r0).There was also talk about whether to add an extended serialization format for BIP-32 wallets. Suggestions were made to add an OutputType field for wallets that do not follow BIP43, while others suggested omitting the field in cases where script types are mixed. Thomas Voegtlin suggested that this value should be user visible, as users need to combine several master public keys when creating wallets with multisig scripts.It was noted that good security for Bitcoin is not defined by constant upgrading, and efforts should be put into backporting fixes/workarounds. Altcoin maintainers were encouraged to contribute back to their upstream to help keep up with security fixes. Sergio Demian Lerner mentioned the policy of publishing vulnerabilities in Bitcoin only after more than 80% of the nodes have upgraded.Overall, the discussions on the Bitcoin-dev mailing list covered various topics such as Merkle branch verification, tail-call semantics, serialization format for BIP-32 wallets, trust in scripts, and preventing attacks on MAST policy. Different perspectives were shared, and suggestions were made to improve the design and security of Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Proposal-bip32-version-bytes-for-segwit-scripts.xml b/static/bitcoin-dev/Sept_2017/combined_Proposal-bip32-version-bytes-for-segwit-scripts.xml index 00e7a32301..35681295e3 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Proposal-bip32-version-bytes-for-segwit-scripts.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Proposal-bip32-version-bytes-for-segwit-scripts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: bip32 version bytes for segwit scripts - 2023-08-01T21:44:44.550021+00:00 + 2025-09-26T15:49:28.299577+00:00 + python-feedgen Luke Dashjr 2017-09-07 19:02:17+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Proposal: bip32 version bytes for segwit scripts - 2023-08-01T21:44:44.550021+00:00 + 2025-09-26T15:49:28.299745+00:00 - On September 5th, 2017, a discussion took place on the Bitcoin-dev forum regarding the serialization format of HD seeds. Kabuto Samourai addressed a possible miscommunication between Luke and Thomas regarding the encoding of {x,y,z}{pub,prv} distinctions when exporting a root master HD seed. They argued that this encoding is unnecessary as the root seed should derive all paths for all coins. However, they suggested that changing the serialization version bytes is appropriate and essential when exporting/importing an account-level seed for watch-only and receive address generation to avoid loss of funds. Luke proposed revisiting a proposal he made in March that handles not only simple HD seeds but also multisig HD and similar cases.Pavol Rusnak, the CTO of SatoshiLabs, suggested using a child number field instead of a fingerprint in the serialization format. He believed that it would be desirable to use the same seed for all different script formats. If he were designing the format today, he would drop the fingerprint and expand the child number to the full BIP32 path. The benefit of this proposal is that the depth already exists, so it is known how long the BIP32 path would be. The proposal included using 4 byte version bytes, 1 byte depth, depth * 4 bytes bip32 path, 32 bytes, and 33 bytes.The email thread also discussed expanding the number of version prefixes to eliminate ambiguity regarding P2SH scripts. Thomas Voegtlin expressed concerns about reaching consensus and the need for extra safeguards if this change were to be implemented. He proposed the "xyz" proposal as a simpler solution that would require minimal changes to existing software. However, Kabuto argued that separating P2SH from P2PKH may not have strong benefits due to the infinite possibilities of P2SH scripts.Another proposal was made to develop a new standard based on Bech32 for including the key or wallet birthdate. Thomas Voegtlin suggested using additional version bytes to indicate the type of output script used with the public keys. He recommended that this change should be visible to users, and he proposed prefixes such as xpub/xprv for P2PKH or P2SH, ypub/yprv for (P2WPKH or P2WSH) nested in P2SH, and zpub/zprv for P2WPKH or P2WSH. It was argued that xpub/xprv serialization should not be used to encode how these keys are used, but the existence of version bytes used to signal whether keys will be used on testnet or mainnet goes against this argument. Without signaling the script type in the version bytes, developers might resort to using "dirtier tricks" such as the bip32 child number field in combination with bip43/bip44/bip49.In the ongoing debates within the Bitcoin development community, Luke Dashjr suggested using the same seed for all different script formats, while Thomas Voegtlin disagreed with this view. Voegtlin argued that wallets must implement all script formats to ensure users can recover their funds from their mnemonic seed. He also disagreed with Dashjr's statement that xpub/xprv are already being used for both P2PKH and P2SH, highlighting that this has resulted in users receiving coins on addresses they do not control.The discussion also touched upon the use of xpub/xprv serialization to encode how keys are used. Voegtlin argued that this should be done instead of just considering it a format for keys. Dashjr, on the other hand, suggested using the child number field instead of version bytes for signaling the script type. The conversation shed light on the ongoing debates regarding key management and storage practices within the Bitcoin development community.In a forum post, Thomas Voegtlin provided a table of different prefixes and their corresponding descriptions related to P2PKH or P2SH and (P2WPKH or P2WSH) nested in P2SH. Pavol Rusnak, as the CTO of SatoshiLabs, responded to an argument regarding xpub/xprv serialization, stating that he was fine with it, but it is unclear which specific proposal he was referring to.The recommendation for BIP32 extended public/private keys is to use version bytes that indicate the user-visible xpub/xprv prefix. Different version bytes are suggested for other networks, such as tpub/tprv for testnet. The proposed changes aim to inform the receiving utility about the exact derivation method used for pubkeys, ensuring that third parties handling xpubs do not require additional information from users. The ongoing discussions reflect efforts to improve key management and storage practices while considering the challenges faced by wallet implementations and the need for consensus within the Bitcoin development community. 2017-09-07T19:02:17+00:00 + On September 5th, 2017, a discussion took place on the Bitcoin-dev forum regarding the serialization format of HD seeds. Kabuto Samourai addressed a possible miscommunication between Luke and Thomas regarding the encoding of {x,y,z}{pub,prv} distinctions when exporting a root master HD seed. They argued that this encoding is unnecessary as the root seed should derive all paths for all coins. However, they suggested that changing the serialization version bytes is appropriate and essential when exporting/importing an account-level seed for watch-only and receive address generation to avoid loss of funds. Luke proposed revisiting a proposal he made in March that handles not only simple HD seeds but also multisig HD and similar cases.Pavol Rusnak, the CTO of SatoshiLabs, suggested using a child number field instead of a fingerprint in the serialization format. He believed that it would be desirable to use the same seed for all different script formats. If he were designing the format today, he would drop the fingerprint and expand the child number to the full BIP32 path. The benefit of this proposal is that the depth already exists, so it is known how long the BIP32 path would be. The proposal included using 4 byte version bytes, 1 byte depth, depth * 4 bytes bip32 path, 32 bytes, and 33 bytes.The email thread also discussed expanding the number of version prefixes to eliminate ambiguity regarding P2SH scripts. Thomas Voegtlin expressed concerns about reaching consensus and the need for extra safeguards if this change were to be implemented. He proposed the "xyz" proposal as a simpler solution that would require minimal changes to existing software. However, Kabuto argued that separating P2SH from P2PKH may not have strong benefits due to the infinite possibilities of P2SH scripts.Another proposal was made to develop a new standard based on Bech32 for including the key or wallet birthdate. Thomas Voegtlin suggested using additional version bytes to indicate the type of output script used with the public keys. He recommended that this change should be visible to users, and he proposed prefixes such as xpub/xprv for P2PKH or P2SH, ypub/yprv for (P2WPKH or P2WSH) nested in P2SH, and zpub/zprv for P2WPKH or P2WSH. It was argued that xpub/xprv serialization should not be used to encode how these keys are used, but the existence of version bytes used to signal whether keys will be used on testnet or mainnet goes against this argument. Without signaling the script type in the version bytes, developers might resort to using "dirtier tricks" such as the bip32 child number field in combination with bip43/bip44/bip49.In the ongoing debates within the Bitcoin development community, Luke Dashjr suggested using the same seed for all different script formats, while Thomas Voegtlin disagreed with this view. Voegtlin argued that wallets must implement all script formats to ensure users can recover their funds from their mnemonic seed. He also disagreed with Dashjr's statement that xpub/xprv are already being used for both P2PKH and P2SH, highlighting that this has resulted in users receiving coins on addresses they do not control.The discussion also touched upon the use of xpub/xprv serialization to encode how keys are used. Voegtlin argued that this should be done instead of just considering it a format for keys. Dashjr, on the other hand, suggested using the child number field instead of version bytes for signaling the script type. The conversation shed light on the ongoing debates regarding key management and storage practices within the Bitcoin development community.In a forum post, Thomas Voegtlin provided a table of different prefixes and their corresponding descriptions related to P2PKH or P2SH and (P2WPKH or P2WSH) nested in P2SH. Pavol Rusnak, as the CTO of SatoshiLabs, responded to an argument regarding xpub/xprv serialization, stating that he was fine with it, but it is unclear which specific proposal he was referring to.The recommendation for BIP32 extended public/private keys is to use version bytes that indicate the user-visible xpub/xprv prefix. Different version bytes are suggested for other networks, such as tpub/tprv for testnet. The proposed changes aim to inform the receiving utility about the exact derivation method used for pubkeys, ensuring that third parties handling xpubs do not require additional information from users. The ongoing discussions reflect efforts to improve key management and storage practices while considering the challenges faced by wallet implementations and the need for consensus within the Bitcoin development community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Rebatable-fees-incentive-safe-fee-markets.xml b/static/bitcoin-dev/Sept_2017/combined_Rebatable-fees-incentive-safe-fee-markets.xml index 4d9aa83456..e6a6ac2cee 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Rebatable-fees-incentive-safe-fee-markets.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Rebatable-fees-incentive-safe-fee-markets.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - Rebatable fees & incentive-safe fee markets - 2023-08-01T21:58:19.103704+00:00 - - Gregory Maxwell 2017-09-30 08:54:57+00:00 - - - Jorge Timón 2017-09-30 03:55:58+00:00 - - - Jorge Timón 2017-09-30 03:53:00+00:00 - - - Gregory Maxwell 2017-09-30 00:47:54+00:00 - - - Mark Friedenbach 2017-09-29 15:22:14+00:00 - - - Alex Morcos 2017-09-29 12:50:20+00:00 - - - Daniele Pinna 2017-09-29 10:43:22+00:00 - - - Anthony Towns 2017-09-29 04:45:56+00:00 - - - Mark Friedenbach 2017-09-29 03:30:27+00:00 - - - Peter Todd 2017-09-29 03:02:25+00:00 - - - Mark Friedenbach 2017-09-29 02:45:02+00:00 - - - Nathan Wilcox 2017-09-29 02:17:05+00:00 - - - Peter Todd 2017-09-29 02:10:33+00:00 - - - Nathan Wilcox 2017-09-29 02:09:13+00:00 - - - Peter Todd 2017-09-29 02:02:27+00:00 - - - Matt Corallo 2017-09-29 01:53:55+00:00 - - - Mark Friedenbach 2017-09-29 01:06:29+00:00 - + 2025-09-26T15:49:30.410223+00:00 + python-feedgen + + + [bitcoin-dev] Rebatable fees & incentive-safe fee markets Mark Friedenbach + 2017-09-29T01:06:00.000Z + + + Matt Corallo + 2017-09-29T01:53:00.000Z + + + Peter Todd + 2017-09-29T02:02:00.000Z + + + Nathan Wilcox + 2017-09-29T02:09:00.000Z + + + Peter Todd + 2017-09-29T02:10:00.000Z + + + Nathan Wilcox + 2017-09-29T02:17:00.000Z + + + Mark Friedenbach + 2017-09-29T02:45:00.000Z + + + Peter Todd + 2017-09-29T03:02:00.000Z + + + Mark Friedenbach + 2017-09-29T03:30:00.000Z + + + Anthony Towns + 2017-09-29T04:45:00.000Z + + + Daniele Pinna + 2017-09-29T10:43:00.000Z + + + Alex Morcos + 2017-09-29T12:50:00.000Z + + + Mark Friedenbach + 2017-09-29T15:22:00.000Z + + + Gregory Maxwell + 2017-09-30T00:47:00.000Z + + + Jorge Timón + 2017-09-30T03:53:00.000Z + + + Jorge Timón + 2017-09-30T03:55:00.000Z + + + Gregory Maxwell + 2017-09-30T08:54:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - Rebatable fees & incentive-safe fee markets - 2023-08-01T21:58:19.103704+00:00 + 2025-09-26T15:49:30.412084+00:00 - The article "Redesigning Bitcoin's fee market" argues that the current auction model for transaction fees in bitcoin is not effective in achieving the maximum clearing price and preventing strategic bidding behavior. The authors propose a shift to a "pay lowest winning bid" model, where all transactions would pay only the smallest fee rate paid by any transaction in the block.This proposed model could be implemented through a soft-fork and offers several benefits. It would eliminate the need for fee estimation mechanisms and adjust transaction fees accordingly. Additionally, it would allow for pre-signed transactions to provide sufficient fees for confirmation without overpaying. It would also enable explicit fees in multi-party transaction creation protocols and allow applications with expensive network access to pay reasonable fees.In this new model, transactions would have the option to specify an implicit fee as well as one or more explicit rebateable fees. The fee rate of a transaction would be calculated as the combined implicit and rebateable fee divided by the size/weight of the transaction. The smallest fee rate of any non-coinbase transaction in the block would be considered the marginal fee rate.For each transaction or transaction group, the required fee would be calculated based on the marginal fee rate and the size/weight of the transaction. Any excess implicit fee would be added to the miner's fee tally, while the remaining dust would be added to the implicit fee tally. Rebateable fees would contribute proportionally towards meeting the marginal fee requirement if the implicit fee falls short. If there is still a remaining balance equal to or greater than the dust threshold in a specific rebateable fee, an output is required in the coinbase to pay the remaining fee to a scriptPubKey.The miner would build a transaction claiming all explicit fees and include a zero-valued null/data output to forward the fees to the coinbase. The miner would be allowed to claim the subsidy, the miner's fee tally, and the explicit fee tally for themselves in the coinbase. The coinbase would also need to contain all rebated fees above the dust threshold.A variant of this proposal suggests carrying forward the excess non-rebateable fees from block to block and allowing the miner to claim some average of past fees. This feature, called "rebateable fees," has the potential to improve the efficiency and fairness of Bitcoin's transaction fee market.Overall, this proposal aims to redesign bitcoin's fee market by implementing a "pay lowest winning bid" model and introducing rebateable fees. It would establish the marginal fee rate for each block and provide smoother fee adjustments or other incentives for efficient and fair transaction processing. However, there are still concerns and questions that need to be addressed regarding the user experience and simplicity of implementation. 2017-09-30T08:54:57+00:00 + The article "Redesigning Bitcoin's fee market" argues that the current auction model for transaction fees in bitcoin is not effective in achieving the maximum clearing price and preventing strategic bidding behavior. The authors propose a shift to a "pay lowest winning bid" model, where all transactions would pay only the smallest fee rate paid by any transaction in the block.This proposed model could be implemented through a soft-fork and offers several benefits. It would eliminate the need for fee estimation mechanisms and adjust transaction fees accordingly. Additionally, it would allow for pre-signed transactions to provide sufficient fees for confirmation without overpaying. It would also enable explicit fees in multi-party transaction creation protocols and allow applications with expensive network access to pay reasonable fees.In this new model, transactions would have the option to specify an implicit fee as well as one or more explicit rebateable fees. The fee rate of a transaction would be calculated as the combined implicit and rebateable fee divided by the size/weight of the transaction. The smallest fee rate of any non-coinbase transaction in the block would be considered the marginal fee rate.For each transaction or transaction group, the required fee would be calculated based on the marginal fee rate and the size/weight of the transaction. Any excess implicit fee would be added to the miner's fee tally, while the remaining dust would be added to the implicit fee tally. Rebateable fees would contribute proportionally towards meeting the marginal fee requirement if the implicit fee falls short. If there is still a remaining balance equal to or greater than the dust threshold in a specific rebateable fee, an output is required in the coinbase to pay the remaining fee to a scriptPubKey.The miner would build a transaction claiming all explicit fees and include a zero-valued null/data output to forward the fees to the coinbase. The miner would be allowed to claim the subsidy, the miner's fee tally, and the explicit fee tally for themselves in the coinbase. The coinbase would also need to contain all rebated fees above the dust threshold.A variant of this proposal suggests carrying forward the excess non-rebateable fees from block to block and allowing the miner to claim some average of past fees. This feature, called "rebateable fees," has the potential to improve the efficiency and fairness of Bitcoin's transaction fee market.Overall, this proposal aims to redesign bitcoin's fee market by implementing a "pay lowest winning bid" model and introducing rebateable fees. It would establish the marginal fee rate for each block and provide smoother fee adjustments or other incentives for efficient and fair transaction processing. However, there are still concerns and questions that need to be addressed regarding the user experience and simplicity of implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Responsible-disclosure-of-bugs.xml b/static/bitcoin-dev/Sept_2017/combined_Responsible-disclosure-of-bugs.xml index 998737039f..5713f2f3e2 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Responsible-disclosure-of-bugs.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Responsible-disclosure-of-bugs.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - Responsible disclosure of bugs - 2023-08-01T21:51:45.406790+00:00 - - Sergio Demian Lerner 2017-09-22 19:53:46+00:00 - - - Nathan Wilcox 2017-09-22 02:00:31+00:00 - - - Anthony Towns 2017-09-14 05:27:40+00:00 - - - Gregory Maxwell 2017-09-12 17:57:32+00:00 - - - Gregory Maxwell 2017-09-12 17:41:42+00:00 - - - Simon Liu 2017-09-12 16:10:18+00:00 - - - Bryan Bishop 2017-09-12 05:18:14+00:00 - - - Sergio Demian Lerner 2017-09-12 04:49:34+00:00 - - - Anthony Towns 2017-09-12 04:47:58+00:00 - - - Anthony Towns 2017-09-12 03:37:03+00:00 - - - Gregory Maxwell 2017-09-11 18:29:46+00:00 - - - Daniel Stadulis 2017-09-11 17:43:52+00:00 - - - Alex Morcos 2017-09-11 11:34:33+00:00 - - - Anthony Towns 2017-09-11 02:15:07+00:00 - - - CryptAxe 2017-09-10 23:28:18+00:00 - - - Matt Corallo 2017-09-10 23:02:36+00:00 - - - Simon Liu 2017-09-10 22:03:48+00:00 - + 2025-09-26T15:48:39.886956+00:00 + python-feedgen + + + [bitcoin-dev] Responsible disclosure of bugs Simon Liu + 2017-09-10T22:03:00.000Z + + + Matt Corallo + 2017-09-10T23:02:00.000Z + + + CryptAxe + 2017-09-10T23:28:00.000Z + + + Anthony Towns + 2017-09-11T02:15:00.000Z + + + Alex Morcos + 2017-09-11T11:34:00.000Z + + + Daniel Stadulis + 2017-09-11T17:43:00.000Z + + + Gregory Maxwell + 2017-09-11T18:29:00.000Z + + + Anthony Towns + 2017-09-12T03:37:00.000Z + + + Anthony Towns + 2017-09-12T04:47:00.000Z + + + Sergio Demian Lerner + 2017-09-12T04:49:00.000Z + + + Bryan Bishop + 2017-09-12T05:18:00.000Z + + + Simon Liu + 2017-09-12T16:10:00.000Z + + + Gregory Maxwell + 2017-09-12T17:41:00.000Z + + + Gregory Maxwell + 2017-09-12T17:57:00.000Z + + + Anthony Towns + 2017-09-14T05:27:00.000Z + + + Nathan Wilcox + 2017-09-22T02:00:00.000Z + + + Sergio Demian Lerner + 2017-09-22T19:53:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - Responsible disclosure of bugs - 2023-08-01T21:51:45.406790+00:00 + 2025-09-26T15:48:39.888792+00:00 - The bitcoin-dev mailing list has been discussing the current policy for disclosing vulnerabilities in Bitcoin. The policy involves reporting vulnerabilities to security at bitcoincore.org, patching critical issues immediately, and releasing minimal details about the vulnerability to delay attacks. Non-critical vulnerabilities are dealt with through patching and reviewing in the ordinary flow of development.Some modifications to the policy have been suggested during the discussion. One suggestion is to disclose vulnerability details after 95% of nodes have upgraded and fixes have been released for at least 6 months, instead of the current threshold of >80% node deployment. It is also proposed that vulnerabilities should be tracked using standard CVE codes. Another proposed modification is early disclosure to zero or more altcoin developers, allowing for closer coordination to minimize economic damage. There is also discussion about using a global timeout for vulnerability disclosure.Concerns have been raised about documenting the security policy, as it may give attackers an advantage in finding weak points. However, many participants believe that the benefits of disclosing vulnerabilities outweigh the risks. In addition to the discussion on vulnerability disclosure, there are other related topics being discussed, including concerns about researchers' inability to report vulnerabilities in altcoins, the responsibility to defend all types of users and software from threats, and the need for a clarification of the current policy regarding publication of vulnerabilities in Bitcoin.The discussion highlights the importance of having a clear and well-defined policy for disclosing vulnerabilities in Bitcoin, while also considering the potential risks and benefits of such disclosures.Another topic of discussion on the mailing list is the challenges of disclosing vulnerabilities in altcoins that are running old, unpatched forks of Bitcoin Core. Concerns have been expressed about the difficulty of disclosing issues without putting people at risk. Suggestions have been made for reasonable approaches to address this issue, such as patching clients and altcoins derived from Bitcoin Core for known vulnerabilities. The decentralized nature of the network poses a challenge in ensuring everyone updates, and ideas like a timeout period for vulnerabilities have been proposed.A responsible disclosure timeline has also been suggested, where vulnerabilities are reported privately and details are shared with a small group of trusted users before releasing official fixes. This proposal takes into consideration the potential risks of sharing vulnerability information with altcoin developers who may not behave responsibly. It is emphasized that good security for Bitcoin is not defined by constant upgrading but by knowing that the definition of money has not changed. Not disclosing vulnerability information can create a false sense of security and discourage good security practices.The discussion also highlights the outdated list of Bitcoin Common Vulnerabilities and Exposures (CVEs), with no new CVEs posted for almost three years except for one without publicly available information. The mailing list encourages further discussion on the topic of Bitcoin and CVEs to find reasonable approaches to address the issue of altcoins running old, unpatched forks of Bitcoin Core and ensure responsible disclosure and patching for the benefit of end-users. 2017-09-22T19:53:46+00:00 + The bitcoin-dev mailing list has been discussing the current policy for disclosing vulnerabilities in Bitcoin. The policy involves reporting vulnerabilities to security at bitcoincore.org, patching critical issues immediately, and releasing minimal details about the vulnerability to delay attacks. Non-critical vulnerabilities are dealt with through patching and reviewing in the ordinary flow of development.Some modifications to the policy have been suggested during the discussion. One suggestion is to disclose vulnerability details after 95% of nodes have upgraded and fixes have been released for at least 6 months, instead of the current threshold of >80% node deployment. It is also proposed that vulnerabilities should be tracked using standard CVE codes. Another proposed modification is early disclosure to zero or more altcoin developers, allowing for closer coordination to minimize economic damage. There is also discussion about using a global timeout for vulnerability disclosure.Concerns have been raised about documenting the security policy, as it may give attackers an advantage in finding weak points. However, many participants believe that the benefits of disclosing vulnerabilities outweigh the risks. In addition to the discussion on vulnerability disclosure, there are other related topics being discussed, including concerns about researchers' inability to report vulnerabilities in altcoins, the responsibility to defend all types of users and software from threats, and the need for a clarification of the current policy regarding publication of vulnerabilities in Bitcoin.The discussion highlights the importance of having a clear and well-defined policy for disclosing vulnerabilities in Bitcoin, while also considering the potential risks and benefits of such disclosures.Another topic of discussion on the mailing list is the challenges of disclosing vulnerabilities in altcoins that are running old, unpatched forks of Bitcoin Core. Concerns have been expressed about the difficulty of disclosing issues without putting people at risk. Suggestions have been made for reasonable approaches to address this issue, such as patching clients and altcoins derived from Bitcoin Core for known vulnerabilities. The decentralized nature of the network poses a challenge in ensuring everyone updates, and ideas like a timeout period for vulnerabilities have been proposed.A responsible disclosure timeline has also been suggested, where vulnerabilities are reported privately and details are shared with a small group of trusted users before releasing official fixes. This proposal takes into consideration the potential risks of sharing vulnerability information with altcoin developers who may not behave responsibly. It is emphasized that good security for Bitcoin is not defined by constant upgrading but by knowing that the definition of money has not changed. Not disclosing vulnerability information can create a false sense of security and discourage good security practices.The discussion also highlights the outdated list of Bitcoin Common Vulnerabilities and Exposures (CVEs), with no new CVEs posted for almost three years except for one without publicly available information. The mailing list encourages further discussion on the topic of Bitcoin and CVEs to find reasonable approaches to address the issue of altcoins running old, unpatched forks of Bitcoin Core and ensure responsible disclosure and patching for the benefit of end-users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Revising-BIP-2-to-expand-editorial-authority.xml b/static/bitcoin-dev/Sept_2017/combined_Revising-BIP-2-to-expand-editorial-authority.xml index be3369e486..11d9f1d77f 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Revising-BIP-2-to-expand-editorial-authority.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Revising-BIP-2-to-expand-editorial-authority.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Revising BIP 2 to expand editorial authority - 2023-08-01T21:57:27.697559+00:00 - - Peter Todd 2017-09-29 01:52:00+00:00 - - - Christian Decker 2017-09-28 12:43:19+00:00 - - - Jean-Paul Kogelman 2017-09-27 21:00:35+00:00 - - - Sjors Provoost 2017-09-27 20:20:54+00:00 - - - Bryan Bishop 2017-09-27 19:01:40+00:00 - - - Luke Dashjr 2017-09-27 18:56:26+00:00 - + 2025-09-26T15:48:44.068915+00:00 + python-feedgen + + + [bitcoin-dev] Revising BIP 2 to expand editorial authority Luke Dashjr + 2017-09-27T18:56:00.000Z + + + Bryan Bishop + 2017-09-27T19:01:00.000Z + + + Sjors Provoost + 2017-09-27T20:20:00.000Z + + + Jean-Paul Kogelman + 2017-09-27T21:00:00.000Z + + + Christian Decker + 2017-09-28T12:43:00.000Z + + + Peter Todd + 2017-09-29T01:52:00.000Z + + - python-feedgen + 2 Combined summary - Revising BIP 2 to expand editorial authority - 2023-08-01T21:57:27.698593+00:00 + 2025-09-26T15:48:44.069771+00:00 - In a discussion on the bitcoin-dev mailing list, there were proposals to modify BIP 2 in order to allow editors to merge changes without involving the authors. Luke Dashjr suggested this modification, but concerns were raised by Bryan Bishop and Sjors Provoost about the potential impact of even minor revisions on the meaning of the text. Bishop recommended mentioning edits in the changelog or indicating that primary authors have not reviewed the suggested changes. The suggestion was also made to have the BIP editor sign and timestamp all changes for clarity on who made the change.There was a suggestion by cdecker to have a sign-off mechanism for changes to BIPs, expanding beyond just the original author(s) to involve 2-3 community members attesting that the meaning of the BIP did not change. However, Dashjr's proposal to modify BIP 2 to allow editors to merge changes without involving the authors was met with concern from Bishop, who emphasized the need for caution due to the potential impact of even minor revisions on the meaning of the text. Bishop recommended mentioning edits in the changelog or ensuring readers are aware that primary authors have not reviewed the suggested changes. The discussion highlighted the importance of careful consideration when making changes to BIPs, as small alterations can have significant impacts on the meaning of the text.Dashjr's proposal to modify BIP 2 to allow editors to merge changes without involving authors was also discussed in a bitcoin-dev mailing list thread. However, Provoost expressed concerns about the potential for even minor revisions to change the meaning of the text. He suggested exercising caution by mentioning edits in the changelog or giving authors a week to object before merging. One possible solution proposed was to @mention authors in the PR and give them time to review suggested changes. No official conclusion was reached in the forum thread regarding this matter.Another member of the bitcoin-dev community, Bryan Bishop, raised concerns about the potential impact of even minor revisions on the meaning of the text in BIPs. He suggested exercising caution and proposed mentioning any edits in the changelog or notifying primary authors before merging changes. Sjors Provoost also suggested @mentioning authors in the PR and giving them a week to object before merging. However, no official conclusion was reached in the forum thread.Luke Dashjr proposed modifying BIP 2 to allow editors to merge changes without involving authors in the bitcoin-dev community. However, Bryan Bishop warned that even minor revisions could have a strange impact on the meaning of the text and suggested exercising caution. He proposed mentioning edits in the changelog or notifying the primary authors before merging. Sjors Provoost suggested @mentioning authors in the PR and giving them a week to object before merging. No official conclusion was reached in the forum thread.Luke Dashjr has proposed modifying BIP 2 to allow editors to merge changes without involving authors. However, there are concerns that even minor revisions could potentially change the meaning of the text, so caution is recommended. Bryan Bishop suggests mentioning edits in the changelog or providing notification to the primary authors before merging. Sjors Provoost suggests @mentioning authors in the PR and allowing them a week to object before merging. The discussion has not yet reached a conclusion on this matter.The BIPs repository often receives pull requests for spelling corrections and other editorial changes that are obvious to merge. Currently, the process requires authors of affected BIPs to acknowledge these changes, which is considered inefficient and unnecessary for such minor revisions. Luke Dashjr suggests modifying BIP 2 to allow editors to merge these types of changes without involving the authors. While it is noted that strictly speaking, BIP 2 should not be changed now that it is Active, an exception is deemed reasonable for a minor revision. A draft Pull Request (PR) for the proposed modification to BIP 2 has been prepared and can be found on Github at https://github.com/bitcoin/bips/pull/596. Those who oppose this change have been requested to voice their concerns within the next month. 2017-09-29T01:52:00+00:00 + In a discussion on the bitcoin-dev mailing list, there were proposals to modify BIP 2 in order to allow editors to merge changes without involving the authors. Luke Dashjr suggested this modification, but concerns were raised by Bryan Bishop and Sjors Provoost about the potential impact of even minor revisions on the meaning of the text. Bishop recommended mentioning edits in the changelog or indicating that primary authors have not reviewed the suggested changes. The suggestion was also made to have the BIP editor sign and timestamp all changes for clarity on who made the change.There was a suggestion by cdecker to have a sign-off mechanism for changes to BIPs, expanding beyond just the original author(s) to involve 2-3 community members attesting that the meaning of the BIP did not change. However, Dashjr's proposal to modify BIP 2 to allow editors to merge changes without involving the authors was met with concern from Bishop, who emphasized the need for caution due to the potential impact of even minor revisions on the meaning of the text. Bishop recommended mentioning edits in the changelog or ensuring readers are aware that primary authors have not reviewed the suggested changes. The discussion highlighted the importance of careful consideration when making changes to BIPs, as small alterations can have significant impacts on the meaning of the text.Dashjr's proposal to modify BIP 2 to allow editors to merge changes without involving authors was also discussed in a bitcoin-dev mailing list thread. However, Provoost expressed concerns about the potential for even minor revisions to change the meaning of the text. He suggested exercising caution by mentioning edits in the changelog or giving authors a week to object before merging. One possible solution proposed was to @mention authors in the PR and give them time to review suggested changes. No official conclusion was reached in the forum thread regarding this matter.Another member of the bitcoin-dev community, Bryan Bishop, raised concerns about the potential impact of even minor revisions on the meaning of the text in BIPs. He suggested exercising caution and proposed mentioning any edits in the changelog or notifying primary authors before merging changes. Sjors Provoost also suggested @mentioning authors in the PR and giving them a week to object before merging. However, no official conclusion was reached in the forum thread.Luke Dashjr proposed modifying BIP 2 to allow editors to merge changes without involving authors in the bitcoin-dev community. However, Bryan Bishop warned that even minor revisions could have a strange impact on the meaning of the text and suggested exercising caution. He proposed mentioning edits in the changelog or notifying the primary authors before merging. Sjors Provoost suggested @mentioning authors in the PR and giving them a week to object before merging. No official conclusion was reached in the forum thread.Luke Dashjr has proposed modifying BIP 2 to allow editors to merge changes without involving authors. However, there are concerns that even minor revisions could potentially change the meaning of the text, so caution is recommended. Bryan Bishop suggests mentioning edits in the changelog or providing notification to the primary authors before merging. Sjors Provoost suggests @mentioning authors in the PR and allowing them a week to object before merging. The discussion has not yet reached a conclusion on this matter.The BIPs repository often receives pull requests for spelling corrections and other editorial changes that are obvious to merge. Currently, the process requires authors of affected BIPs to acknowledge these changes, which is considered inefficient and unnecessary for such minor revisions. Luke Dashjr suggests modifying BIP 2 to allow editors to merge these types of changes without involving the authors. While it is noted that strictly speaking, BIP 2 should not be changed now that it is Active, an exception is deemed reasonable for a minor revision. A draft Pull Request (PR) for the proposed modification to BIP 2 has been prepared and can be found on Github at https://github.com/bitcoin/bips/pull/596. Those who oppose this change have been requested to voice their concerns within the next month. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_SF-proposal-prohibit-unspendable-outputs-with-amount-0.xml b/static/bitcoin-dev/Sept_2017/combined_SF-proposal-prohibit-unspendable-outputs-with-amount-0.xml index 5a31763b6e..a2d37980d1 100644 --- a/static/bitcoin-dev/Sept_2017/combined_SF-proposal-prohibit-unspendable-outputs-with-amount-0.xml +++ b/static/bitcoin-dev/Sept_2017/combined_SF-proposal-prohibit-unspendable-outputs-with-amount-0.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - SF proposal: prohibit unspendable outputs with amount=0 - 2023-08-01T21:45:19.661193+00:00 - - Gregory Maxwell 2017-09-13 09:34:37+00:00 - - - Peter Todd 2017-09-13 09:24:34+00:00 - - - Jorge Timón 2017-09-09 21:11:57+00:00 - - - Peter Todd 2017-09-07 18:00:14+00:00 - - - Tier Nolan 2017-09-07 10:31:41+00:00 - - - Hampus Sjöberg 2017-09-07 09:56:19+00:00 - - - CryptAxe 2017-09-07 03:41:49+00:00 - - - Adam Back 2017-09-07 01:29:55+00:00 - - - CryptAxe 2017-09-06 23:54:03+00:00 - - - Tier Nolan 2017-09-06 22:20:02+00:00 - - - Jorge Timón 2017-09-05 21:51:45+00:00 - + 2025-09-26T15:49:13.554282+00:00 + python-feedgen + + + [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 Jorge Timón + 2017-09-05T21:51:00.000Z + + + Tier Nolan + 2017-09-06T22:20:00.000Z + + + CryptAxe + 2017-09-06T23:54:00.000Z + + + Adam Back + 2017-09-07T01:29:00.000Z + + + CryptAxe + 2017-09-07T03:41:00.000Z + + + Hampus Sjöberg + 2017-09-07T09:56:00.000Z + + + Tier Nolan + 2017-09-07T10:31:00.000Z + + + Peter Todd + 2017-09-07T18:00:00.000Z + + + Jorge Timón + 2017-09-09T21:11:00.000Z + + + Peter Todd + 2017-09-13T09:24:00.000Z + + + Gregory Maxwell + 2017-09-13T09:34:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - SF proposal: prohibit unspendable outputs with amount=0 - 2023-08-01T21:45:19.661193+00:00 + 2025-09-26T15:49:13.555611+00:00 - In a recent discussion on the bitcoin-dev mailing list, Peter Todd expressed his opinion that dropping zero value outputs is not worth the cost-benefit tradeoff. He believes that it is a needless loss of flexibility and suggests that something similar could be done for increased precision in the case of nanobitcoin. However, he acknowledges that requiring a minimum value may become meaningful if the value of 1e-8 btc becomes high enough to reduce a miner's ability to spam up the network.The email thread also discusses the implementation of Confidential Transactions (CT) as a softfork in Bitcoin. CT transactions only differ from regular transactions by proving that the sum of input values is greater than or equal to the sum of output values through a CT proof, without revealing the actual sums. To ensure each CT transaction's sum of inputs and outputs is valid, a pool of "shielded" outputs with an unknown value is proposed. There are three main cases for spending these shielded outputs: spending unshielded outputs to CT-shielded outputs, spending CT-shielded outputs to unshielded outputs, and spending CT-shielded outputs to CT-shielded outputs. The third case may result in extra outputs and consume a significant percentage of blockchain space if shielded-to-shielded transactions are common. However, the benefit of this implementation is almost trivial compared to its cost, hence the proposed tradeoff does not make sense.Jorge Timón proposed a solution for spamming attacks on the UTXO, where creating 0-value outputs that are spendable could remain in the UTXO indefinitely. The proposal is to require at least 1 satoshi per output, which Todd believes has minimal cost for spammers and does not justify making future upgrades more complex. Todd also believes that TXO commitments and Bram's related work will make UTXO growth a non-issue in the future. Therefore, he rejects the proposal.There is a discussion about timelocked transactions and their potential risks. If a timelocked transaction has a zero value input and the SF (soft fork) happens, that transaction would become unspendable. The keys to the outputs may also be lost or the co-signer may refuse to cooperate. There are objections to long term timelocked transactions, but it is recommended that any timelocked transactions should use forms that are popular. Any change which makes some transactions invalid should be opt-in and only apply to new transaction version numbers. If a timelocked transaction has an undefined version number, little can be done about it. However, if the version number is defined and in-use, transactions should not suddenly lose validity. A refusal to commit to this rule makes long term locktime use much more risky. There is also a discussion about allowing spendable outputs with null amounts and whether there is any reason or use case to keep allowing them.The discussion on the bitcoin-dev mailing list has raised questions regarding the feasibility of forbidding 0 satoshi outputs and inputs. It was pointed out that this would complicate a divisibility increase softfork, particularly with regards to Felix's confidential transactions. The blinding and unblinding transactions would have to be created with minimal output values. However, it was suggested that a change to the blinding scriptPubKey could allow for the use of 0 value outputs. The pattern used by Felix Weiss' BIP for Confidential Transactions depends on or is tidier with 0-value outputs. It was also noted that as long as unspendable outputs (OP_RETURN outputs for example) are still allowed with amount=0, there should not be an issue for anything. There was a proposal to create a BIP to require at least 1 satoshi per output to prevent spendable outputs with null amounts in them.On September 7, 2017, CryptAxe via bitcoin-dev expressed that unspendable outputs with amount=0 are still allowed and hence not an issue. Whereas Jorge Timón via bitcoin-dev stated that the creation of 0-value outputs that are spendable can potentially stay in utxo forever. He also added that requiring at least 1 satoshi per output would be better than the current situation although it wouldn't do much against a spam attack to the utxo. Jorge Timón further questioned if there was any reason or use case to keep allowing spendable outputs with null amounts in them, and if not, he was happy to create a BIP code for this. It is important to note that the pattern used by Felix Weiss' BIP for Confidential Transactions is tidier with 0-value outputs.In a Bitcoin-dev mailing list, Jorge Timón raised a concern regarding the creation of 0-value outputs that are spendable and can potentially stay in the unspent transaction output (UTXO) forever. Timón suggested that requiring at least 1 satoshi per output may be slightly better than the current situation, although it doesn't do much 2017-09-13T09:34:37+00:00 + In a recent discussion on the bitcoin-dev mailing list, Peter Todd expressed his opinion that dropping zero value outputs is not worth the cost-benefit tradeoff. He believes that it is a needless loss of flexibility and suggests that something similar could be done for increased precision in the case of nanobitcoin. However, he acknowledges that requiring a minimum value may become meaningful if the value of 1e-8 btc becomes high enough to reduce a miner's ability to spam up the network.The email thread also discusses the implementation of Confidential Transactions (CT) as a softfork in Bitcoin. CT transactions only differ from regular transactions by proving that the sum of input values is greater than or equal to the sum of output values through a CT proof, without revealing the actual sums. To ensure each CT transaction's sum of inputs and outputs is valid, a pool of "shielded" outputs with an unknown value is proposed. There are three main cases for spending these shielded outputs: spending unshielded outputs to CT-shielded outputs, spending CT-shielded outputs to unshielded outputs, and spending CT-shielded outputs to CT-shielded outputs. The third case may result in extra outputs and consume a significant percentage of blockchain space if shielded-to-shielded transactions are common. However, the benefit of this implementation is almost trivial compared to its cost, hence the proposed tradeoff does not make sense.Jorge Timón proposed a solution for spamming attacks on the UTXO, where creating 0-value outputs that are spendable could remain in the UTXO indefinitely. The proposal is to require at least 1 satoshi per output, which Todd believes has minimal cost for spammers and does not justify making future upgrades more complex. Todd also believes that TXO commitments and Bram's related work will make UTXO growth a non-issue in the future. Therefore, he rejects the proposal.There is a discussion about timelocked transactions and their potential risks. If a timelocked transaction has a zero value input and the SF (soft fork) happens, that transaction would become unspendable. The keys to the outputs may also be lost or the co-signer may refuse to cooperate. There are objections to long term timelocked transactions, but it is recommended that any timelocked transactions should use forms that are popular. Any change which makes some transactions invalid should be opt-in and only apply to new transaction version numbers. If a timelocked transaction has an undefined version number, little can be done about it. However, if the version number is defined and in-use, transactions should not suddenly lose validity. A refusal to commit to this rule makes long term locktime use much more risky. There is also a discussion about allowing spendable outputs with null amounts and whether there is any reason or use case to keep allowing them.The discussion on the bitcoin-dev mailing list has raised questions regarding the feasibility of forbidding 0 satoshi outputs and inputs. It was pointed out that this would complicate a divisibility increase softfork, particularly with regards to Felix's confidential transactions. The blinding and unblinding transactions would have to be created with minimal output values. However, it was suggested that a change to the blinding scriptPubKey could allow for the use of 0 value outputs. The pattern used by Felix Weiss' BIP for Confidential Transactions depends on or is tidier with 0-value outputs. It was also noted that as long as unspendable outputs (OP_RETURN outputs for example) are still allowed with amount=0, there should not be an issue for anything. There was a proposal to create a BIP to require at least 1 satoshi per output to prevent spendable outputs with null amounts in them.On September 7, 2017, CryptAxe via bitcoin-dev expressed that unspendable outputs with amount=0 are still allowed and hence not an issue. Whereas Jorge Timón via bitcoin-dev stated that the creation of 0-value outputs that are spendable can potentially stay in utxo forever. He also added that requiring at least 1 satoshi per output would be better than the current situation although it wouldn't do much against a spam attack to the utxo. Jorge Timón further questioned if there was any reason or use case to keep allowing spendable outputs with null amounts in them, and if not, he was happy to create a BIP code for this. It is important to note that the pattern used by Felix Weiss' BIP for Confidential Transactions is tidier with 0-value outputs.In a Bitcoin-dev mailing list, Jorge Timón raised a concern regarding the creation of 0-value outputs that are spendable and can potentially stay in the unspent transaction output (UTXO) forever. Timón suggested that requiring at least 1 satoshi per output may be slightly better than the current situation, although it doesn't do much - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml b/static/bitcoin-dev/Sept_2017/combined_Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml index d1aec252ed..44d74b717d 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml @@ -1,31 +1,54 @@ - + 2 Combined summary - Sidechain headers on mainchain (unification of drivechains and spv proofs) - 2023-08-01T21:44:05.360002+00:00 - - Chris Stewart 2017-09-08 20:14:30+00:00 - - - ZmnSCPxj 2017-09-05 23:32:17+00:00 - - - Chris Stewart 2017-09-05 17:06:32+00:00 - - - ZmnSCPxj 2017-09-05 08:21:59+00:00 - + 2025-09-26T15:49:24.094489+00:00 + python-feedgen + + + [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs) ZmnSCPxj + 2017-09-05T08:21:00.000Z + + + Chris Stewart + 2017-09-05T17:06:00.000Z + + + ZmnSCPxj + 2017-09-05T23:32:00.000Z + + + Chris Stewart + 2017-09-08T20:14:00.000Z + + + [bitcoin-dev] Fwd: " Paul Sztorc + 2017-09-09T15:33:00.000Z + + + ZmnSCPxj + 2017-09-10T05:32:00.000Z + + + ZmnSCPxj + 2017-09-10T05:33:00.000Z + + + [bitcoin-dev] Fw: " ZmnSCPxj + 2017-09-15T04:34:00.000Z + + - python-feedgen + 2 Combined summary - Sidechain headers on mainchain (unification of drivechains and spv proofs) - 2023-08-01T21:44:05.361043+00:00 + 2025-09-26T15:49:24.095503+00:00 - The article examines the use of side-to-side pegs in blockchain technology, specifically focusing on the OP_WITHDRAWPROOFVERIFY for sidechain-headers-on-mainchain approach. This method allows for the transfer of value from the mainchain to a sidechain, with the sidechain committing to a sidechain address. It eliminates the need for reorg proofs by allowing the mainchain to track the extension of the sidechain in real-time, enabling sidechainers to detect fraud and prevent invalid forks. The creation of new sidecoins for free is also discussed, with an emphasis on the need to ensure that lockboxes containing sidecoins are not valid WT. The sidechain allows for the arbitrary creation of sidecoins in lockboxes, but precautions must be taken to prevent a single WT from unlocking multiple lockboxes.The article explores how a main-to-side peg works, where a lockbox is created on Esschain and then spent with a scriptSig that pays out to a selected Bitcoin P2SH address. Challenges faced by side-to-side pegs are highlighted, particularly in the event of the economic majority deciding to kill Esschain due to security issues or other factors. Thieves can exploit this situation by packing an invalid Esschain block full of invalid WT to other chains, which is made possible through enabled side-to-side pegs. While side-to-side pegs offer better liquidity and quick arbitrage between sidechains without relying on the mainchain, they also increase the potential for attacks on sidechains.The email addresses the issue of sidechain forks and how the mainchain determines the validity of the longest chain. Sidechain headers are embedded in the mainchain block's coinbase, allowing mainchain fullnodes to validate the rule of "longest work chain." However, if the merkle tree hash provided contains an invalid transaction, the mainchain nodes may mistakenly consider the longest work chain as valid and eliminate any consensus valid chain that sidechain miners are constructing. To prevent this, the email suggests extending the coinbase maturity period on the sidechain beyond 288 blocks to incentivize sidechain miners to collaborate and extend the chain together.The proposed solution for sidechains involves integrating drivechains, blind merged mining, and SPV proofs. The author recommends using miner voting instead of large SPV proofs to control the unlocking of mainchain funds in a sidechain. Merged mining is proposed to maintain mainchain security in sidechain mining. The concept of "sidechain headers in mainchain" is introduced, where the sidechain header chain is embedded directly in the mainchain. This eliminates the need for presenting new data to the mainchain through SPV proofs, with reorg proofs suggested as a means to invalidate previous SPV proofs.Concerns about centralization risks if sidechain miners are required to check the sidechain in full are raised. A possible solution is to validate SPV proofs on the mainchain without trusting anyone or running sidechain software. The proposal aims to address issues with drivechains failing due to the potential for a group with over 51% of mainchain miners to steal sidechain lockboxes. The process of creating a sidechain involves the creation of a data structure containing various information, including sidechain block height, side-to-main peg pointer, links to other forks of the same sidechain ID, and the top block header hash of the sidechain. Mainchain nodes create and update this data structure based on the extension of the sidechain. Multiple forks of a sidechain are tracked, and mainchain fullnodes validate side-to-main transfers without the need for running sidechain software.Mainchain miners can act as protectors for sidechains by being paid in sidechain funds and using OP_BRIBEVERIFY. The number 288, mentioned throughout the article, is a parameter that can be subject to debate. 2017-09-08T20:14:30+00:00 + The article examines the use of side-to-side pegs in blockchain technology, specifically focusing on the OP_WITHDRAWPROOFVERIFY for sidechain-headers-on-mainchain approach. This method allows for the transfer of value from the mainchain to a sidechain, with the sidechain committing to a sidechain address. It eliminates the need for reorg proofs by allowing the mainchain to track the extension of the sidechain in real-time, enabling sidechainers to detect fraud and prevent invalid forks. The creation of new sidecoins for free is also discussed, with an emphasis on the need to ensure that lockboxes containing sidecoins are not valid WT. The sidechain allows for the arbitrary creation of sidecoins in lockboxes, but precautions must be taken to prevent a single WT from unlocking multiple lockboxes.The article explores how a main-to-side peg works, where a lockbox is created on Esschain and then spent with a scriptSig that pays out to a selected Bitcoin P2SH address. Challenges faced by side-to-side pegs are highlighted, particularly in the event of the economic majority deciding to kill Esschain due to security issues or other factors. Thieves can exploit this situation by packing an invalid Esschain block full of invalid WT to other chains, which is made possible through enabled side-to-side pegs. While side-to-side pegs offer better liquidity and quick arbitrage between sidechains without relying on the mainchain, they also increase the potential for attacks on sidechains.The email addresses the issue of sidechain forks and how the mainchain determines the validity of the longest chain. Sidechain headers are embedded in the mainchain block's coinbase, allowing mainchain fullnodes to validate the rule of "longest work chain." However, if the merkle tree hash provided contains an invalid transaction, the mainchain nodes may mistakenly consider the longest work chain as valid and eliminate any consensus valid chain that sidechain miners are constructing. To prevent this, the email suggests extending the coinbase maturity period on the sidechain beyond 288 blocks to incentivize sidechain miners to collaborate and extend the chain together.The proposed solution for sidechains involves integrating drivechains, blind merged mining, and SPV proofs. The author recommends using miner voting instead of large SPV proofs to control the unlocking of mainchain funds in a sidechain. Merged mining is proposed to maintain mainchain security in sidechain mining. The concept of "sidechain headers in mainchain" is introduced, where the sidechain header chain is embedded directly in the mainchain. This eliminates the need for presenting new data to the mainchain through SPV proofs, with reorg proofs suggested as a means to invalidate previous SPV proofs.Concerns about centralization risks if sidechain miners are required to check the sidechain in full are raised. A possible solution is to validate SPV proofs on the mainchain without trusting anyone or running sidechain software. The proposal aims to address issues with drivechains failing due to the potential for a group with over 51% of mainchain miners to steal sidechain lockboxes. The process of creating a sidechain involves the creation of a data structure containing various information, including sidechain block height, side-to-main peg pointer, links to other forks of the same sidechain ID, and the top block header hash of the sidechain. Mainchain nodes create and update this data structure based on the extension of the sidechain. Multiple forks of a sidechain are tracked, and mainchain fullnodes validate side-to-main transfers without the need for running sidechain software.Mainchain miners can act as protectors for sidechains by being paid in sidechain funds and using OP_BRIBEVERIFY. The number 288, mentioned throughout the article, is a parameter that can be subject to debate. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Sidechains-Mainstake.xml b/static/bitcoin-dev/Sept_2017/combined_Sidechains-Mainstake.xml index 641ded3b41..84d044a71b 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Sidechains-Mainstake.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Sidechains-Mainstake.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Sidechains: Mainstake - 2023-08-01T21:54:53.725792+00:00 - - ZmnSCPxj 2017-09-26 22:38:59+00:00 - - - Chris Stewart 2017-09-26 17:51:50+00:00 - - - ZmnSCPxj 2017-09-23 01:49:11+00:00 - + 2025-09-26T15:48:31.445778+00:00 + python-feedgen + + + [bitcoin-dev] Sidechains: Mainstake ZmnSCPxj + 2017-09-23T01:49:00.000Z + + + Chris Stewart + 2017-09-26T17:51:00.000Z + + + ZmnSCPxj + 2017-09-26T22:38:00.000Z + + - python-feedgen + 2 Combined summary - Sidechains: Mainstake - 2023-08-01T21:54:53.725792+00:00 + 2025-09-26T15:48:31.446299+00:00 - ZmnSCPxj's proposed sidechain scheme aims to give the economic majority control of sidechains without relying on miners as representatives. This proposal claims to have improved features compared to drivechains, making it even harder for a 51% mainchain miner to steal funds. According to ZmnSCPxj, the proposal requires months of broadcasting intent to steal or locking funds for an entire week-long theft, thereby increasing the difficulty for a mainchain miner to execute a theft.One concern raised in the context is the possibility of the stake winner disappearing, which could halt progress on the sidechain temporarily. The stake winner is only valid for a specific mainchain block, and if they fail to publish a sidechain header on that block, the mainchain block will not contain any sidechain header. This issue could slow down the sidechain, resulting in missed opportunities for the stake winner to earn sidechain fees.Another issue discussed is the weak mitigation against a mainchain miner attack. In the proposed scheme, a mainchain miner with over 50% hashpower can block the creation of sidechain mainstake UTXOs except its own and eventually steal them at no cost. To mitigate this, a possible solution suggested is to nest mainstake outputs in p2wsh/p2sh scripts. However, there are concerns about relocking the stake with this approach.The context also mentions a hybrid approach that might work depending on the definition of "creation." If it refers only to the initial creation of the utxo and not subsequent OP_STAKEVERIFY change outputs, this strategy could prevent the lottery from including the UTXO. As a result, it would be unable to become a stake winner or publish a sidechain block header until the lock time.Furthermore, the context raises the issue of a stake winner disappearing or a miner creating the illusion of their disappearance through censorship. This scenario would result in transaction fees being lost.In summary, ZmnSCPxj's proposed sidechain scheme claims to offer improved features compared to drivechains, making it more difficult for a 51% mainchain miner to steal funds. However, there are concerns about the stake winner disappearing, weak mitigation against a mainchain miner attack, and issues with the suggested solution of nesting mainstake outputs in p2wsh/p2sh scripts. The context also highlights the need for careful consideration and evaluation of potential flaws in the proposal. 2017-09-26T22:38:59+00:00 + ZmnSCPxj's proposed sidechain scheme aims to give the economic majority control of sidechains without relying on miners as representatives. This proposal claims to have improved features compared to drivechains, making it even harder for a 51% mainchain miner to steal funds. According to ZmnSCPxj, the proposal requires months of broadcasting intent to steal or locking funds for an entire week-long theft, thereby increasing the difficulty for a mainchain miner to execute a theft.One concern raised in the context is the possibility of the stake winner disappearing, which could halt progress on the sidechain temporarily. The stake winner is only valid for a specific mainchain block, and if they fail to publish a sidechain header on that block, the mainchain block will not contain any sidechain header. This issue could slow down the sidechain, resulting in missed opportunities for the stake winner to earn sidechain fees.Another issue discussed is the weak mitigation against a mainchain miner attack. In the proposed scheme, a mainchain miner with over 50% hashpower can block the creation of sidechain mainstake UTXOs except its own and eventually steal them at no cost. To mitigate this, a possible solution suggested is to nest mainstake outputs in p2wsh/p2sh scripts. However, there are concerns about relocking the stake with this approach.The context also mentions a hybrid approach that might work depending on the definition of "creation." If it refers only to the initial creation of the utxo and not subsequent OP_STAKEVERIFY change outputs, this strategy could prevent the lottery from including the UTXO. As a result, it would be unable to become a stake winner or publish a sidechain block header until the lock time.Furthermore, the context raises the issue of a stake winner disappearing or a miner creating the illusion of their disappearance through censorship. This scenario would result in transaction fees being lost.In summary, ZmnSCPxj's proposed sidechain scheme claims to offer improved features compared to drivechains, making it more difficult for a 51% mainchain miner to steal funds. However, there are concerns about the stake winner disappearing, weak mitigation against a mainchain miner attack, and issues with the suggested solution of nesting mainstake outputs in p2wsh/p2sh scripts. The context also highlights the need for careful consideration and evaluation of potential flaws in the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_Why-the-BIP-72-Payment-Protocol-URI-Standard-is-Insecure-Against-MITM-Attacks.xml b/static/bitcoin-dev/Sept_2017/combined_Why-the-BIP-72-Payment-Protocol-URI-Standard-is-Insecure-Against-MITM-Attacks.xml index f006c03da5..ac29cd04fc 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Why-the-BIP-72-Payment-Protocol-URI-Standard-is-Insecure-Against-MITM-Attacks.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Why-the-BIP-72-Payment-Protocol-URI-Standard-is-Insecure-Against-MITM-Attacks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks - 2023-08-01T21:58:36.470807+00:00 + 2025-09-26T15:49:15.670350+00:00 + python-feedgen Andreas Schildbach 2017-09-30 15:33:01+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks - 2023-08-01T21:58:36.470807+00:00 + 2025-09-26T15:49:15.670512+00:00 - The BIP-70 payment protocol used through BIP-72 URI's has been a topic of debate due to security concerns. Payment QR codes do not cryptographically commit to the identity of the merchant, allowing hijackers to redirect payments if they acquire an SSL certificate that a wallet accepts. However, HTTPS assumes secure certificates. Instead of using the payment protocol, some prefer to email or print bitcoin addresses on invoices.There is a need for a new BIP to replace BIP-72, which is considered dangerous in its current form. The current https principles are seen as outdated, particularly the concept of certificates tied to a domain. The author suggests evolving it into certificates tied to an entityID managed by a blockchain system. The author also argues against specifying things for Bitcoin like the web, as browsers can do better.Using the payment protocol means paying to a secure endpoint rather than an address. It offers benefits such as preventing address reuse, eliminating the need for mempool synchronization among non-miners, and improving privacy by enabling light clients to know when a transaction is coming in. Implementing the payment protocol widely is key to scaling.The BIP-70 payment protocol has overhead and requires back and forth communication, making it less preferable compared to emailing or printing bitcoin addresses. The BIP-72 URI's used by the payment protocol are insecure, as payment QR codes do not commit to the merchant's identity. This allows a man-in-the-middle attacker to redirect payments. Deprecating BIP-72 and introducing a new BIP is necessary.Wallets should use the bitcoin address for integrity checks to mitigate risk. The BIP could be enhanced by deriving the bitcoin address from the merchant pub key and hash, enabling independent generation of addresses by both customers and merchants. Wallets may discard important information when using the payment protocol, giving MITM attackers another chance to redirect payments. Off-the-shelf SSL libraries with infrequently updated root certificates are commonly used by wallets.In conclusion, the BIP-70 payment protocol has security concerns and requires improvement. BIP-72 should be deprecated and replaced with a new BIP. Android Wallet for Bitcoin includes a parameter that adds a hash commitment to the payment request, but it is not part of the standard itself. The discussion on the Bitcoin development mailing list highlights the need for addressing these issues. 2017-09-30T15:33:01+00:00 + The BIP-70 payment protocol used through BIP-72 URI's has been a topic of debate due to security concerns. Payment QR codes do not cryptographically commit to the identity of the merchant, allowing hijackers to redirect payments if they acquire an SSL certificate that a wallet accepts. However, HTTPS assumes secure certificates. Instead of using the payment protocol, some prefer to email or print bitcoin addresses on invoices.There is a need for a new BIP to replace BIP-72, which is considered dangerous in its current form. The current https principles are seen as outdated, particularly the concept of certificates tied to a domain. The author suggests evolving it into certificates tied to an entityID managed by a blockchain system. The author also argues against specifying things for Bitcoin like the web, as browsers can do better.Using the payment protocol means paying to a secure endpoint rather than an address. It offers benefits such as preventing address reuse, eliminating the need for mempool synchronization among non-miners, and improving privacy by enabling light clients to know when a transaction is coming in. Implementing the payment protocol widely is key to scaling.The BIP-70 payment protocol has overhead and requires back and forth communication, making it less preferable compared to emailing or printing bitcoin addresses. The BIP-72 URI's used by the payment protocol are insecure, as payment QR codes do not commit to the merchant's identity. This allows a man-in-the-middle attacker to redirect payments. Deprecating BIP-72 and introducing a new BIP is necessary.Wallets should use the bitcoin address for integrity checks to mitigate risk. The BIP could be enhanced by deriving the bitcoin address from the merchant pub key and hash, enabling independent generation of addresses by both customers and merchants. Wallets may discard important information when using the payment protocol, giving MITM attackers another chance to redirect payments. Off-the-shelf SSL libraries with infrequently updated root certificates are commonly used by wallets.In conclusion, the BIP-70 payment protocol has security concerns and requires improvement. BIP-72 should be deprecated and replaced with a new BIP. Android Wallet for Bitcoin includes a parameter that adds a hash commitment to the payment request, but it is not part of the standard itself. The discussion on the Bitcoin development mailing list highlights the need for addressing these issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_cleanstack-alt-stack-softfork-improvements-Was-Merkle-branch-verification-tail-call-semantics-for-generalized-MAST-.xml b/static/bitcoin-dev/Sept_2017/combined_cleanstack-alt-stack-softfork-improvements-Was-Merkle-branch-verification-tail-call-semantics-for-generalized-MAST-.xml index 1a465fd806..2b092c5f63 100644 --- a/static/bitcoin-dev/Sept_2017/combined_cleanstack-alt-stack-softfork-improvements-Was-Merkle-branch-verification-tail-call-semantics-for-generalized-MAST-.xml +++ b/static/bitcoin-dev/Sept_2017/combined_cleanstack-alt-stack-softfork-improvements-Was-Merkle-branch-verification-tail-call-semantics-for-generalized-MAST-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) - 2023-08-01T21:54:12.251453+00:00 + 2025-09-26T15:49:05.110222+00:00 + python-feedgen Luke Dashjr 2017-09-21 16:33:16+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) - 2023-08-01T21:54:12.251453+00:00 + 2025-09-26T15:49:05.110374+00:00 - On September 21, 2017, a discussion took place regarding the understanding of SigAgg, a softfork that aggregates signatures on bitcoin transactions. The possibility of old clients comprehending the aggregation produced by new clients was debated. It was suggested that more witness space could be utilized to store (pubkey, message) pairs, enabling old clients to understand the aggregation. However, this approach was deemed counterproductive as it defeated the purpose of aggregation.It was clarified that since SigAgg is a softfork, old clients would not be able to understand it. An alternative solution was proposed, which involved implying stack items if the Script engine is designed to support it upfront. This would allow the engine to behave as if it were non-verify while maintaining backward compatibility. When questioned about how an OP_MUL could be derived from an OP_NOP, it was explained that new clients would execute it as an OP_MUL and inject pops/pushes when sending the transaction to older clients. This suggested approach would likely need to be part of a MAST-like softfork to be feasible.Johnson Lau addressed the issue of OP_RETURNTRUE not working well with signature aggregation in a message on the Bitcoin development mailing list. Signature aggregation combines (pubkey, message) pairs in a transaction and verifies them with one signature. However, for old nodes, the script terminates at OP_RETURNTRUE, thereby preventing the collection of the (pubkey, message) pair. Lau proposed transforming OP_RETURNTRUE into OP_17 via a softfork. This would enable new nodes to collect the (pubkey, message) pair and attempt to aggregate it with other pairs, potentially resulting in a hardfork.Luke Dashjr countered that this issue should be addressed by signature aggregation itself, rather than relying on modifying OP_RETURNTRUE. Dashjr suggested setting up signature aggregation upfront and having the Script verify the inclusion of keys in the aggregation. Another suggestion made by Dashjr was to create any opcode with an OP_NOP. For instance, if an OP_MUL is desired, an OP_MULVERIFY could be introduced, which would verify if the 3rd stack item is the product of the top 2 stack items.During the discussion session, the idea of maintaining tail-call semantics through the use of the alt stack for transferring arguments to the policy script was proposed. Additionally, a question arose regarding whether this could be considered a bug in the cleanstack rule. The participants also deliberated on the notion of replacing all NOPs and unallocated opcodes with a new OP_RETURNTRUE implementation in future versions of Script. This would cause the program to immediately exit, potentially performing semantic checks on the remaining script. The advantage of this approach is that it allows for softforking in any new opcode, not limited to the -VERIFY opcode variants that have been introduced. Old nodes would always succeed immediately upon encountering an undefined opcode, granting the new opcode the ability to perform any action from that point onward. It should be noted that while this approach is similar to CVE-2010-5141, it shouldn't be exploitable as signatures are no longer treated as scripts themselves. 2017-09-21T16:33:16+00:00 + On September 21, 2017, a discussion took place regarding the understanding of SigAgg, a softfork that aggregates signatures on bitcoin transactions. The possibility of old clients comprehending the aggregation produced by new clients was debated. It was suggested that more witness space could be utilized to store (pubkey, message) pairs, enabling old clients to understand the aggregation. However, this approach was deemed counterproductive as it defeated the purpose of aggregation.It was clarified that since SigAgg is a softfork, old clients would not be able to understand it. An alternative solution was proposed, which involved implying stack items if the Script engine is designed to support it upfront. This would allow the engine to behave as if it were non-verify while maintaining backward compatibility. When questioned about how an OP_MUL could be derived from an OP_NOP, it was explained that new clients would execute it as an OP_MUL and inject pops/pushes when sending the transaction to older clients. This suggested approach would likely need to be part of a MAST-like softfork to be feasible.Johnson Lau addressed the issue of OP_RETURNTRUE not working well with signature aggregation in a message on the Bitcoin development mailing list. Signature aggregation combines (pubkey, message) pairs in a transaction and verifies them with one signature. However, for old nodes, the script terminates at OP_RETURNTRUE, thereby preventing the collection of the (pubkey, message) pair. Lau proposed transforming OP_RETURNTRUE into OP_17 via a softfork. This would enable new nodes to collect the (pubkey, message) pair and attempt to aggregate it with other pairs, potentially resulting in a hardfork.Luke Dashjr countered that this issue should be addressed by signature aggregation itself, rather than relying on modifying OP_RETURNTRUE. Dashjr suggested setting up signature aggregation upfront and having the Script verify the inclusion of keys in the aggregation. Another suggestion made by Dashjr was to create any opcode with an OP_NOP. For instance, if an OP_MUL is desired, an OP_MULVERIFY could be introduced, which would verify if the 3rd stack item is the product of the top 2 stack items.During the discussion session, the idea of maintaining tail-call semantics through the use of the alt stack for transferring arguments to the policy script was proposed. Additionally, a question arose regarding whether this could be considered a bug in the cleanstack rule. The participants also deliberated on the notion of replacing all NOPs and unallocated opcodes with a new OP_RETURNTRUE implementation in future versions of Script. This would cause the program to immediately exit, potentially performing semantic checks on the remaining script. The advantage of this approach is that it allows for softforking in any new opcode, not limited to the -VERIFY opcode variants that have been introduced. Old nodes would always succeed immediately upon encountering an undefined opcode, granting the new opcode the ability to perform any action from that point onward. It should be noted that while this approach is similar to CVE-2010-5141, it shouldn't be exploitable as signatures are no longer treated as scripts themselves. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_hypothetical-Could-soft-forks-be-prevented-.xml b/static/bitcoin-dev/Sept_2017/combined_hypothetical-Could-soft-forks-be-prevented-.xml index 46f3022768..4c6e05e826 100644 --- a/static/bitcoin-dev/Sept_2017/combined_hypothetical-Could-soft-forks-be-prevented-.xml +++ b/static/bitcoin-dev/Sept_2017/combined_hypothetical-Could-soft-forks-be-prevented-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - hypothetical: Could soft-forks be prevented? - 2023-08-01T21:52:43.536907+00:00 + 2025-09-26T15:49:17.784040+00:00 + python-feedgen Daniel Wilczynski 2017-09-18 06:40:18+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - hypothetical: Could soft-forks be prevented? - 2023-08-01T21:52:43.536907+00:00 + 2025-09-26T15:49:17.784185+00:00 - In a discussion on the bitcoin-dev mailing list, the topic of preventing soft forks in cryptocurrency software is explored. Daniel Wilczynski suggests that built-in wipeout protection would be a better solution to protect the majority from threatening a minority with a wipeout in the event of a soft fork scenario. This can be achieved through automated consensus critical checkpoints or other mechanisms. However, implementing built-in wipeout protection would turn soft forks into hard forks.The conversation also delves into the possibility of creating an un-soft-forkable cryptocurrency. Andrew Poelstra suggests that designing for maximal fungibility and transaction structures that minimize interaction with the blockchain could minimize the surface for transaction censorship. Simone Bronzini proposes a simple cryptocurrency where only the public key and amount are indicated in the transaction output, but acknowledges that it could still potentially be soft-forked. The primary goal of this thought experiment is to prevent new functionality from being added arbitrarily.ZmnSCPxj argues that it is impossible to prevent soft forks entirely. They provide examples of anyone-can-spend scripts that are currently disallowed from propagation but could still be included in a block by a miner. ZmnSCPxj also notes the possibility of miners running secret soft-forking code. The only way to prevent soft forks is to hard fork against them. Adam Back expresses concern about the potential manipulation of consensus rule changes through political means. He seeks solutions to prevent the tyranny of the majority that could undermine network-wide consensus rule changes.The article mentions that soft forks create a new class of transactions that interact with DAOs. Ethereum, for example, can't soft fork and always has to hard fork. Dan Libby is interested in the possibility of a cryptocurrency with immutable consensus rules. Soft forks rely on anyone-can-spend transactions, and removing them could effectively prevent soft forks. It is also possible to programmatically avoid/ban soft forks.The discussion on preventing soft forks continues, with Adam Back and ZmnSCPxj pointing out the practical challenges of banning anyone-can-spend outputs and the possibility of miners running soft-forking code secretly. Soft forks apply further restrictions on Bitcoin, while hard forks do not. The only way to prevent a soft fork is to hard fork against it. The goal of creating an un-soft-forkable cryptocurrency is discussed, but it is noted that preventing new functionality may be the primary objective of this thought experiment.In conclusion, preventing soft forks entirely is considered impractical, as there are too many potential scriptPubKey options. Soft forks can apply further restrictions on a cryptocurrency, and miners can run soft-forking code without the rest of the community knowing. Hard forking against a soft fork is the only way to prevent it. The possibility of creating a cryptocurrency with immutable consensus rules is explored, with considerations for fungibility and minimizing interaction with the blockchain. However, the feasibility of preventing soft forks and the practicality of implementing these ideas are also questioned. 2017-09-18T06:40:18+00:00 + In a discussion on the bitcoin-dev mailing list, the topic of preventing soft forks in cryptocurrency software is explored. Daniel Wilczynski suggests that built-in wipeout protection would be a better solution to protect the majority from threatening a minority with a wipeout in the event of a soft fork scenario. This can be achieved through automated consensus critical checkpoints or other mechanisms. However, implementing built-in wipeout protection would turn soft forks into hard forks.The conversation also delves into the possibility of creating an un-soft-forkable cryptocurrency. Andrew Poelstra suggests that designing for maximal fungibility and transaction structures that minimize interaction with the blockchain could minimize the surface for transaction censorship. Simone Bronzini proposes a simple cryptocurrency where only the public key and amount are indicated in the transaction output, but acknowledges that it could still potentially be soft-forked. The primary goal of this thought experiment is to prevent new functionality from being added arbitrarily.ZmnSCPxj argues that it is impossible to prevent soft forks entirely. They provide examples of anyone-can-spend scripts that are currently disallowed from propagation but could still be included in a block by a miner. ZmnSCPxj also notes the possibility of miners running secret soft-forking code. The only way to prevent soft forks is to hard fork against them. Adam Back expresses concern about the potential manipulation of consensus rule changes through political means. He seeks solutions to prevent the tyranny of the majority that could undermine network-wide consensus rule changes.The article mentions that soft forks create a new class of transactions that interact with DAOs. Ethereum, for example, can't soft fork and always has to hard fork. Dan Libby is interested in the possibility of a cryptocurrency with immutable consensus rules. Soft forks rely on anyone-can-spend transactions, and removing them could effectively prevent soft forks. It is also possible to programmatically avoid/ban soft forks.The discussion on preventing soft forks continues, with Adam Back and ZmnSCPxj pointing out the practical challenges of banning anyone-can-spend outputs and the possibility of miners running soft-forking code secretly. Soft forks apply further restrictions on Bitcoin, while hard forks do not. The only way to prevent a soft fork is to hard fork against it. The goal of creating an un-soft-forkable cryptocurrency is discussed, but it is noted that preventing new functionality may be the primary objective of this thought experiment.In conclusion, preventing soft forks entirely is considered impractical, as there are too many potential scriptPubKey options. Soft forks can apply further restrictions on a cryptocurrency, and miners can run soft-forking code without the rest of the community knowing. Hard forking against a soft fork is the only way to prevent it. The possibility of creating a cryptocurrency with immutable consensus rules is explored, with considerations for fungibility and minimizing interaction with the blockchain. However, the feasibility of preventing soft forks and the practicality of implementing these ideas are also questioned. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_idea-post-bitcoin-side-chain-implementation.xml b/static/bitcoin-dev/Sept_2017/combined_idea-post-bitcoin-side-chain-implementation.xml index 954dde046e..263ba07aaf 100644 --- a/static/bitcoin-dev/Sept_2017/combined_idea-post-bitcoin-side-chain-implementation.xml +++ b/static/bitcoin-dev/Sept_2017/combined_idea-post-bitcoin-side-chain-implementation.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - idea post: bitcoin side chain implementation - 2023-08-01T21:55:13.404920+00:00 - - Patrick Sharp 2017-09-26 01:15:09+00:00 - - - ZmnSCPxj 2017-09-26 00:35:39+00:00 - - - Patrick Sharp 2017-09-26 00:07:12+00:00 - - - ZmnSCPxj 2017-09-26 00:01:10+00:00 - - - CryptAxe 2017-09-25 22:58:52+00:00 - - - Patrick Sharp 2017-09-25 21:53:30+00:00 - + 2025-09-26T15:48:56.728723+00:00 + python-feedgen + + + [bitcoin-dev] idea post: bitcoin side chain implementation Patrick Sharp + 2017-09-25T21:53:00.000Z + + + CryptAxe + 2017-09-25T22:58:00.000Z + + + ZmnSCPxj + 2017-09-26T00:01:00.000Z + + + Patrick Sharp + 2017-09-26T00:07:00.000Z + + + ZmnSCPxj + 2017-09-26T00:35:00.000Z + + + Patrick Sharp + 2017-09-26T01:15:00.000Z + + - python-feedgen + 2 Combined summary - idea post: bitcoin side chain implementation - 2023-08-01T21:55:13.404920+00:00 + 2025-09-26T15:48:56.729560+00:00 - In a discussion about sidechains, a user named Patrick proposes the idea of a non-official sidechain that would distribute rewards and allow users to share their burden. However, another user named ZmnSCPxj points out that most sidechain proposals use merge mining for security similar to the main chain. ZmnSCPxj suggests "blind" merge mining or publishing entire sidechain block headers on the main chain to achieve this. He also recommends calling this system "sharding" instead of "sidechain" as sharding requires protection against double-spending. After being enlightened about lightning network, pruning, and sharding, Patrick withdraws his proposal realizing that these technologies accomplish what he had set out to do.ZmnSCPxj discusses the security issues of non-official chains and explains why merge mining is commonly used in sidechain proposals. He suggests using the term "sharding" for future systems that include part of the reward for parity between all chains. He acknowledges that sharding a distributed ledger while ensuring correct operation is difficult and provides a link to an article by Peter Todd on why scaling Bitcoin with sharding is hard. ZmnSCPxj advises that building a sidechain capable of sharding would be a good course of action once an acceptable sidechain-enabling proposal is agreed upon by the majority of Bitcoin Core developers.The context also mentions the lack of security in non-official chains due to a lack of miners and users' reluctance to use them. However, they are considered useful for developing and testing concepts. The possibility of building an external proof-of-concept sidechain of side chains to achieve official reward splitting chains with equal security is discussed. Elements and Drivechains are mentioned as possible solutions, but no further information is provided.Patrick Sharp proposes a Bitcoin side chain implementation that would be officially supported and built by official bitcoin software. The chains would have an identifier in the block header, and each address would be assigned to a chain via (address) mod (number of chains). Transaction fees would be split between chains if an address sends to another chain. The chains would come into being through a fork or split, and every 2016 blocks, if some percentage of blocks on any chain are larger than a specified amount, all chains would increment their power value and fork on their block. However, it is noted that sidechains were originally designed to add and prototype new features to Bitcoin, not to increase the effective block size. For scaling, the Lightning Network is considered a superior solution as it keeps most transactions off-chain.Overall, the conversation revolves around the proposal of a non-official sidechain, the security issues of non-official chains, the use of merge mining in sidechain proposals, the concept of sharding, and the scaling solutions such as the Lightning Network. 2017-09-26T01:15:09+00:00 + In a discussion about sidechains, a user named Patrick proposes the idea of a non-official sidechain that would distribute rewards and allow users to share their burden. However, another user named ZmnSCPxj points out that most sidechain proposals use merge mining for security similar to the main chain. ZmnSCPxj suggests "blind" merge mining or publishing entire sidechain block headers on the main chain to achieve this. He also recommends calling this system "sharding" instead of "sidechain" as sharding requires protection against double-spending. After being enlightened about lightning network, pruning, and sharding, Patrick withdraws his proposal realizing that these technologies accomplish what he had set out to do.ZmnSCPxj discusses the security issues of non-official chains and explains why merge mining is commonly used in sidechain proposals. He suggests using the term "sharding" for future systems that include part of the reward for parity between all chains. He acknowledges that sharding a distributed ledger while ensuring correct operation is difficult and provides a link to an article by Peter Todd on why scaling Bitcoin with sharding is hard. ZmnSCPxj advises that building a sidechain capable of sharding would be a good course of action once an acceptable sidechain-enabling proposal is agreed upon by the majority of Bitcoin Core developers.The context also mentions the lack of security in non-official chains due to a lack of miners and users' reluctance to use them. However, they are considered useful for developing and testing concepts. The possibility of building an external proof-of-concept sidechain of side chains to achieve official reward splitting chains with equal security is discussed. Elements and Drivechains are mentioned as possible solutions, but no further information is provided.Patrick Sharp proposes a Bitcoin side chain implementation that would be officially supported and built by official bitcoin software. The chains would have an identifier in the block header, and each address would be assigned to a chain via (address) mod (number of chains). Transaction fees would be split between chains if an address sends to another chain. The chains would come into being through a fork or split, and every 2016 blocks, if some percentage of blocks on any chain are larger than a specified amount, all chains would increment their power value and fork on their block. However, it is noted that sidechains were originally designed to add and prototype new features to Bitcoin, not to increase the effective block size. For scaling, the Lightning Network is considered a superior solution as it keeps most transactions off-chain.Overall, the conversation revolves around the proposal of a non-official sidechain, the security issues of non-official chains, the use of merge mining in sidechain proposals, the concept of sharding, and the scaling solutions such as the Lightning Network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_idea-post-trimming-and-demurrage.xml b/static/bitcoin-dev/Sept_2017/combined_idea-post-trimming-and-demurrage.xml index 33d3d547c5..c17467b759 100644 --- a/static/bitcoin-dev/Sept_2017/combined_idea-post-trimming-and-demurrage.xml +++ b/static/bitcoin-dev/Sept_2017/combined_idea-post-trimming-and-demurrage.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - idea post: trimming and demurrage - 2023-08-01T21:56:03.519814+00:00 - - ZmnSCPxj 2017-09-26 07:50:42+00:00 - - - Алексей Мутовкин 2017-09-26 07:10:43+00:00 - - - Patrick Sharp 2017-09-26 01:33:25+00:00 - - - ZmnSCPxj 2017-09-25 23:34:32+00:00 - - - Richard Hein 2017-09-25 23:30:23+00:00 - - - Aymeric Vitte 2017-09-25 22:43:02+00:00 - - - Patrick Sharp 2017-09-25 21:54:16+00:00 - + 2025-09-26T15:48:41.981708+00:00 + python-feedgen + + + [bitcoin-dev] idea post: trimming and demurrage Patrick Sharp + 2017-09-25T21:54:00.000Z + + + Aymeric Vitte + 2017-09-25T22:43:00.000Z + + + Richard Hein + 2017-09-25T23:30:00.000Z + + + ZmnSCPxj + 2017-09-25T23:34:00.000Z + + + Patrick Sharp + 2017-09-26T01:33:00.000Z + + + Алексей Мутовкин + 2017-09-26T07:10:00.000Z + + + ZmnSCPxj + 2017-09-26T07:50:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - idea post: trimming and demurrage - 2023-08-01T21:56:03.520813+00:00 + 2025-09-26T15:48:41.982805+00:00 - Patrick Sharp, a recent computer science graduate, proposed the implementation of trimming and demurrage in Bitcoin. He argued that without some sort of limit on the maximum length or size of the blockchain, it becomes unsustainable in the long run and more centralized as it becomes unwieldy. Trimming old blocks whose transactions are now spent holds no real value and takes up real-world space that incurs cost.To address this issue, Sharp proposed limiting the blockchain length to either 2^18 blocks (slightly less than five years) or 2^19 blocks (slightly less than ten years). Each time a block is mined, the oldest block(s) beyond this limit would be trimmed from the chain, and its unspent transactions would be included in the reward of the mined block. This proposal aims to keep the costs of miners balanced with the costs of users.However, ZmnSCPxj responded by stating that demurrage is impossible in Bitcoin due to the already implemented OP_CHECKLOCKTIMEVERIFY opcode. This opcode requires that a certain block height or date has passed before an output can be spent. It can be used to make an "in trust for" address, where spending of that address is disallowed. ZmnSCPxj suggests putting such additional features as demurrage in a sidechain rather than on the mainchain.In response to ZmnSCPxj's suggestions, Patrick Sharp thanked everyone for their responses and withdrew his proposal for the time being. He also suggested storing the hash of the current or previous UTXOs in the block header so that pruned nodes can verify their UTXOs are accurate without having to check the full chain. Additionally, he mentioned the possibility of including a snapshot of the UTXOs every x blocks.Overall, the discussion on the Bitcoin-dev mailing list revolved around the proposal of demurrage and trimming of old blocks to ensure the sustainability and balance of the blockchain. Different viewpoints were presented, with ZmnSCPxj suggesting alternative approaches such as sidechains. Patrick Sharp acknowledged the feedback and offered additional ideas for consideration. 2017-09-26T07:50:42+00:00 + Patrick Sharp, a recent computer science graduate, proposed the implementation of trimming and demurrage in Bitcoin. He argued that without some sort of limit on the maximum length or size of the blockchain, it becomes unsustainable in the long run and more centralized as it becomes unwieldy. Trimming old blocks whose transactions are now spent holds no real value and takes up real-world space that incurs cost.To address this issue, Sharp proposed limiting the blockchain length to either 2^18 blocks (slightly less than five years) or 2^19 blocks (slightly less than ten years). Each time a block is mined, the oldest block(s) beyond this limit would be trimmed from the chain, and its unspent transactions would be included in the reward of the mined block. This proposal aims to keep the costs of miners balanced with the costs of users.However, ZmnSCPxj responded by stating that demurrage is impossible in Bitcoin due to the already implemented OP_CHECKLOCKTIMEVERIFY opcode. This opcode requires that a certain block height or date has passed before an output can be spent. It can be used to make an "in trust for" address, where spending of that address is disallowed. ZmnSCPxj suggests putting such additional features as demurrage in a sidechain rather than on the mainchain.In response to ZmnSCPxj's suggestions, Patrick Sharp thanked everyone for their responses and withdrew his proposal for the time being. He also suggested storing the hash of the current or previous UTXOs in the block header so that pruned nodes can verify their UTXOs are accurate without having to check the full chain. Additionally, he mentioned the possibility of including a snapshot of the UTXOs every x blocks.Overall, the discussion on the Bitcoin-dev mailing list revolved around the proposal of demurrage and trimming of old blocks to ensure the sustainability and balance of the blockchain. Different viewpoints were presented, with ZmnSCPxj suggesting alternative approaches such as sidechains. Patrick Sharp acknowledged the feedback and offered additional ideas for consideration. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2017/combined_proposal-extend-WIF-format-for-segwit.xml b/static/bitcoin-dev/Sept_2017/combined_proposal-extend-WIF-format-for-segwit.xml index 9b3bfedc4c..36141b92b3 100644 --- a/static/bitcoin-dev/Sept_2017/combined_proposal-extend-WIF-format-for-segwit.xml +++ b/static/bitcoin-dev/Sept_2017/combined_proposal-extend-WIF-format-for-segwit.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - proposal: extend WIF format for segwit - 2023-08-01T21:53:22.351002+00:00 - - Karl-Johan Alm 2018-04-10 02:54:08+00:00 - - - Karl Johan Alm 2018-04-04 06:06:19+00:00 - - - Mark Friedenbach 2017-09-17 15:36:48+00:00 - - - AJ West 2017-09-17 14:42:52+00:00 - - - Thomas Voegtlin 2017-09-17 08:10:17+00:00 - - - Pieter Wuille 2017-09-17 02:29:41+00:00 - - - Thomas Voegtlin 2017-09-15 08:55:37+00:00 - + 2025-09-26T15:48:27.268826+00:00 + python-feedgen + + + [bitcoin-dev] proposal: extend WIF format for segwit Thomas Voegtlin + 2017-09-15T08:55:00.000Z + + + Pieter Wuille + 2017-09-17T02:29:00.000Z + + + Thomas Voegtlin + 2017-09-17T08:10:00.000Z + + + AJ West + 2017-09-17T14:42:00.000Z + + + Mark Friedenbach + 2017-09-17T15:36:00.000Z + + + Karl Johan Alm + 2018-04-04T06:06:00.000Z + + + Karl-Johan Alm + 2018-04-10T02:54:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - proposal: extend WIF format for segwit - 2023-08-01T21:53:22.351002+00:00 + 2025-09-26T15:48:27.269669+00:00 - The proposed Bitcoin Improvement Proposal (BIP XXX) aims to extend the private key format in order to specify the type of public key it corresponds to. Currently, when importing a private key, the wallet has to assume all possible types of public keys, resulting in the need to track each alternative. The proposal suggests adding new values to the table to indicate the type of public key associated with the private key, such as P2PKH, P2WPKH, and P2SH. This extension would allow wallets to track only the specific corresponding public key when importing a private key.The motivation behind this proposal is the presence of various types of public keys that can be associated with a given private key, such as legacy formats and SegWit formats. The existing private key format lacks the ability to specify which type of public key was used, leading to ambiguity and the need for wallets to try all possible scripts. The proposed extension seeks to address this issue by providing a clear indication of the type of public key associated with a private key.The compatibility of the Bech32 and Wallet Import Format (WIF) payload format is discussed in the Bitcoin-dev mailing list. The ambiguity of the current WIF format is causing obstacles for the release of a SegWit-capable version of Electrum. Two options are presented: either disable private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or define a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Other wallet developers are asked about their plans for exporting private keys used in SegWit scripts in the current WIF format.In the discussion, user AJ West raises concerns about whether wallet software should attempt to error-correct private keys. Thomas Voegtlin, the developer of Electrum, responds to Pieter Wuille's comment on checksum computation for the Bech32 format, stating that the ambiguity in the WIF format is holding him back from releasing a SegWit-capable version of Electrum. Voegtlin believes it is unacceptable to use the current WIF format with SegWit scripts and suggests either disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon or defining his own WIF extension for Electrum. He seeks input from other wallet developers, particularly Core.Pieter Wuille, a Bitcoin Core developer, expresses concerns about the ambiguity of the Wallet Import Format (WIF) when used with Segregated Witness (SegWit) scripts. He argues that the current WIF format is not suitable for use with SegWit scripts and could create technological debt by requiring wallets to try all possible scripts. He suggests two options: disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or defining a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Wuille seeks information on the plans of other wallet developers, especially Core.Thomas Voegtlin proposes using a bech32 format for private keys if they are to be used with a bech32 address. However, he is unsure if such a format has already been proposed. Meanwhile, Pieter has been working on an "extended bech32" format with a stronger checksum protection compared to the normal bech32 format. This extended format is particularly useful for private keys since there is no option to ask the receiver for a corrected version. Although this task is low priority, significant computation work is required to find a good checksum.The Wallet Import Format (WIF) is a representation of private keys for Bitcoin. The current WIF format appends a 0x01 byte after the raw private key when used with a compressed public key, allowing wallets to associate a single Bitcoin address with a WIF key. However, extending the semantics of that byte to signal segwit scripts would be useful, as these scripts result in different addresses. Proposals suggest adding new bytes to WIF for segwit script embedded in P2SH and native segwit script. It is not necessary to use distinct bytes for certain types as the P2SH script is not known anyway. Additionally, a bech32 format can be used for private keys intended for use with a bech32 address. It is important to note that this proposal will not result in a visible change at the beginning of the string, similar to the compressed/uncompressed indicator. However, improvements to this aspect may be made in the future. These proposed changes to WIF are similar to the {x,y,z}{pub,prv} proposal for bip32 extended keys.In conclusion, the proposed BIP aims to extend the private 2018-04-10T02:54:08+00:00 + The proposed Bitcoin Improvement Proposal (BIP XXX) aims to extend the private key format in order to specify the type of public key it corresponds to. Currently, when importing a private key, the wallet has to assume all possible types of public keys, resulting in the need to track each alternative. The proposal suggests adding new values to the table to indicate the type of public key associated with the private key, such as P2PKH, P2WPKH, and P2SH. This extension would allow wallets to track only the specific corresponding public key when importing a private key.The motivation behind this proposal is the presence of various types of public keys that can be associated with a given private key, such as legacy formats and SegWit formats. The existing private key format lacks the ability to specify which type of public key was used, leading to ambiguity and the need for wallets to try all possible scripts. The proposed extension seeks to address this issue by providing a clear indication of the type of public key associated with a private key.The compatibility of the Bech32 and Wallet Import Format (WIF) payload format is discussed in the Bitcoin-dev mailing list. The ambiguity of the current WIF format is causing obstacles for the release of a SegWit-capable version of Electrum. Two options are presented: either disable private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or define a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Other wallet developers are asked about their plans for exporting private keys used in SegWit scripts in the current WIF format.In the discussion, user AJ West raises concerns about whether wallet software should attempt to error-correct private keys. Thomas Voegtlin, the developer of Electrum, responds to Pieter Wuille's comment on checksum computation for the Bech32 format, stating that the ambiguity in the WIF format is holding him back from releasing a SegWit-capable version of Electrum. Voegtlin believes it is unacceptable to use the current WIF format with SegWit scripts and suggests either disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon or defining his own WIF extension for Electrum. He seeks input from other wallet developers, particularly Core.Pieter Wuille, a Bitcoin Core developer, expresses concerns about the ambiguity of the Wallet Import Format (WIF) when used with Segregated Witness (SegWit) scripts. He argues that the current WIF format is not suitable for use with SegWit scripts and could create technological debt by requiring wallets to try all possible scripts. He suggests two options: disabling private key export in Electrum SegWit wallets until a common WIF extension is agreed upon, or defining a new WIF extension specifically for Electrum. While defining a new format makes sense for certain aspects, it may not be ideal for WIF as it is primarily used to import/sweep keys from other wallets. Wuille seeks information on the plans of other wallet developers, especially Core.Thomas Voegtlin proposes using a bech32 format for private keys if they are to be used with a bech32 address. However, he is unsure if such a format has already been proposed. Meanwhile, Pieter has been working on an "extended bech32" format with a stronger checksum protection compared to the normal bech32 format. This extended format is particularly useful for private keys since there is no option to ask the receiver for a corrected version. Although this task is low priority, significant computation work is required to find a good checksum.The Wallet Import Format (WIF) is a representation of private keys for Bitcoin. The current WIF format appends a 0x01 byte after the raw private key when used with a compressed public key, allowing wallets to associate a single Bitcoin address with a WIF key. However, extending the semantics of that byte to signal segwit scripts would be useful, as these scripts result in different addresses. Proposals suggest adding new bytes to WIF for segwit script embedded in P2SH and native segwit script. It is not necessary to use distinct bytes for certain types as the P2SH script is not known anyway. Additionally, a bech32 format can be used for private keys intended for use with a bech32 address. It is important to note that this proposal will not result in a visible change at the beginning of the string, similar to the compressed/uncompressed indicator. However, improvements to this aspect may be made in the future. These proposed changes to WIF are similar to the {x,y,z}{pub,prv} proposal for bip32 extended keys.In conclusion, the proposed BIP aims to extend the private - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_-bitcoin-core-dev-Bitcoin-Core-update-notice.xml b/static/bitcoin-dev/Sept_2018/combined_-bitcoin-core-dev-Bitcoin-Core-update-notice.xml index 179b4c8703..dccc9a733d 100644 --- a/static/bitcoin-dev/Sept_2018/combined_-bitcoin-core-dev-Bitcoin-Core-update-notice.xml +++ b/static/bitcoin-dev/Sept_2018/combined_-bitcoin-core-dev-Bitcoin-Core-update-notice.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [bitcoin-core-dev] Bitcoin Core update notice - 2023-08-01T23:54:34.321051+00:00 + 2025-09-26T15:55:58.837936+00:00 + python-feedgen Gregory Maxwell 2018-09-22 04:59:53+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [bitcoin-core-dev] Bitcoin Core update notice - 2023-08-01T23:54:34.321051+00:00 + 2025-09-26T15:55:58.838079+00:00 - In a recent Bitcoin-dev mailing list, a user expressed concerns about the hype surrounding the need to upgrade to Bitcoin Core version 0.16.3 immediately. Another user clarified that the bugfix has already been backported to earlier versions and that the announcement on the Bitcoin Core site is clear. However, it is still recommended to upgrade to the latest version to avoid potential issues. Running older versions can lead to network exploitable crashes, which can result in double-spends and long valid forks. The recommendation to upgrade to the latest version comes from the need to protect people from harm.The bug fix for CVE-2018-17144 was released in Bitcoin Core version 0.16.3. This update is highly recommended for all network participants. The patch can also be backported to earlier versions, but the backported versions are still undergoing the Gitian build process and have not been released yet. There has been some hype and hysteria surrounding the immediate upgrade to version 0.16.3, which has been discussed on forums and Reddit. However, efforts to correct this misinformation have not been seen yet.For those who build from source, the fixed versions of the 0.14, 0.15, 0.16, 0.17, and master branches are available on GitHub. Despite the availability of the bugfix in earlier versions and the option to build from source, the urgency to upgrade to version 0.16.3 has not been addressed adequately, and there is a lack of effort to correct the misinformation being spread on forums and Reddit. 2018-09-22T04:59:53+00:00 + In a recent Bitcoin-dev mailing list, a user expressed concerns about the hype surrounding the need to upgrade to Bitcoin Core version 0.16.3 immediately. Another user clarified that the bugfix has already been backported to earlier versions and that the announcement on the Bitcoin Core site is clear. However, it is still recommended to upgrade to the latest version to avoid potential issues. Running older versions can lead to network exploitable crashes, which can result in double-spends and long valid forks. The recommendation to upgrade to the latest version comes from the need to protect people from harm.The bug fix for CVE-2018-17144 was released in Bitcoin Core version 0.16.3. This update is highly recommended for all network participants. The patch can also be backported to earlier versions, but the backported versions are still undergoing the Gitian build process and have not been released yet. There has been some hype and hysteria surrounding the immediate upgrade to version 0.16.3, which has been discussed on forums and Reddit. However, efforts to correct this misinformation have not been seen yet.For those who build from source, the fixed versions of the 0.14, 0.15, 0.16, 0.17, and master branches are available on GitHub. Despite the availability of the bugfix in earlier versions and the option to build from source, the urgency to upgrade to version 0.16.3 has not been addressed adequately, and there is a lack of effort to correct the misinformation being spread on forums and Reddit. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_-bitcoin-discuss-Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml b/static/bitcoin-dev/Sept_2018/combined_-bitcoin-discuss-Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml index 7a9c6ca752..e117bc2056 100644 --- a/static/bitcoin-dev/Sept_2018/combined_-bitcoin-discuss-Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml +++ b/static/bitcoin-dev/Sept_2018/combined_-bitcoin-discuss-Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [bitcoin-discuss] Proposal to replace full blockchain with recent history plus UTXO Set - 2023-08-01T23:55:18.805205+00:00 + 2025-09-26T15:56:15.840605+00:00 + python-feedgen CryptAxe 2018-09-26 00:00:03+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [bitcoin-discuss] Proposal to replace full blockchain with recent history plus UTXO Set - 2023-08-01T23:55:18.805205+00:00 + 2025-09-26T15:56:15.840750+00:00 - The Bitcoin mailing list recently discussed a proposal to replace the full blockchain with a UTXO (Unspent Transaction Output) set. This idea suggests that a UTXO block set type could be appended onto the valid chain at certain intervals, containing only the validated UTXO set up to a specific height. By doing this, full nodes would be relieved of the need to store the entire blockchain, leading to significant storage savings and making it easier to run a full node.However, implementing this proposal has consensus implications, and there are some bugs that need to be addressed. The email provides links to an implementation of UTXO loading as well as a script for the open-source Game-of-Life software Golly. In addition, a video was shared demonstrating the game playing out into an apron-shaped image.To encourage participation, the author of the proposal offers a reward of $50 worth of bitcoin to anyone who can provide them with a UTXO Set from the bitcoin client. The goal is to create a recognizable checkpoint for the Bitcoin blockchain, which would facilitate the adoption of full nodes by more people in the future.Overall, the proposal aims to improve the efficiency of running full nodes by replacing the full blockchain with a UTXO set recognizable at a certain block height. This could potentially save storage space and make it easier for more individuals to participate in the Bitcoin network. 2018-09-26T00:00:03+00:00 + The Bitcoin mailing list recently discussed a proposal to replace the full blockchain with a UTXO (Unspent Transaction Output) set. This idea suggests that a UTXO block set type could be appended onto the valid chain at certain intervals, containing only the validated UTXO set up to a specific height. By doing this, full nodes would be relieved of the need to store the entire blockchain, leading to significant storage savings and making it easier to run a full node.However, implementing this proposal has consensus implications, and there are some bugs that need to be addressed. The email provides links to an implementation of UTXO loading as well as a script for the open-source Game-of-Life software Golly. In addition, a video was shared demonstrating the game playing out into an apron-shaped image.To encourage participation, the author of the proposal offers a reward of $50 worth of bitcoin to anyone who can provide them with a UTXO Set from the bitcoin client. The goal is to create a recognizable checkpoint for the Bitcoin blockchain, which would facilitate the adoption of full nodes by more people in the future.Overall, the proposal aims to improve the efficiency of running full nodes by replacing the full blockchain with a UTXO set recognizable at a certain block height. This could potentially save storage space and make it easier for more individuals to participate in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_A-BIP-proposal-for-transactions-that-are-cancellable-.xml b/static/bitcoin-dev/Sept_2018/combined_A-BIP-proposal-for-transactions-that-are-cancellable-.xml index cf2a0cd04b..f32a2b95cc 100644 --- a/static/bitcoin-dev/Sept_2018/combined_A-BIP-proposal-for-transactions-that-are-cancellable-.xml +++ b/static/bitcoin-dev/Sept_2018/combined_A-BIP-proposal-for-transactions-that-are-cancellable-.xml @@ -1,41 +1,55 @@ - + 2 Combined summary - A BIP proposal for transactions that are 'cancellable' - 2023-08-01T23:53:30.514715+00:00 - - TUCCI Sara 2018-09-07 13:47:17+00:00 - - - Brandon Smith 2018-09-07 12:51:35+00:00 - - - Alejandro Ranchal Pedrosa 2018-09-07 07:12:40+00:00 - - - Alejandro Ranchal Pedrosa 2018-09-07 07:07:25+00:00 - - - Terry McLaughlin 2018-09-07 05:02:29+00:00 - - - Brandon Smith 2018-09-06 20:32:44+00:00 - - - Matt Corallo 2018-09-06 16:33:38+00:00 - - - vizeet srivastava 2018-09-06 16:14:59+00:00 - - - Gregory Maxwell 2018-09-06 15:16:34+00:00 - - - Matt Corallo 2018-09-06 13:31:58+00:00 - - - Alejandro Ranchal Pedrosa 2018-09-06 09:19:24+00:00 - + 2025-09-26T15:56:09.461318+00:00 + python-feedgen + + + [bitcoin-dev] A BIP proposal for transactions that are 'cancellable' Alejandro Ranchal Pedrosa + 2018-09-06T09:19:00.000Z + + + Matt Corallo + 2018-09-06T13:31:00.000Z + + + Gregory Maxwell + 2018-09-06T15:16:00.000Z + + + vizeet srivastava + 2018-09-06T16:14:00.000Z + + + Matt Corallo + 2018-09-06T16:33:00.000Z + + + Brandon Smith + 2018-09-06T20:32:00.000Z + + + Terry McLaughlin + 2018-09-07T05:02:00.000Z + + + Alejandro Ranchal Pedrosa + 2018-09-07T07:07:00.000Z + + + Alejandro Ranchal Pedrosa + 2018-09-07T07:12:00.000Z + + + Brandon Smith + 2018-09-07T12:51:00.000Z + + + TUCCI Sara + 2018-09-07T13:47:00.000Z + + @@ -47,13 +61,13 @@ - python-feedgen + 2 Combined summary - A BIP proposal for transactions that are 'cancellable' - 2023-08-01T23:53:30.514715+00:00 + 2025-09-26T15:56:09.462731+00:00 - Alejandro Ranchal Pedrosa has proposed studying the possibility of canceling Bitcoin transactions from the user's point of view. He suggests a model for user-agents and quantifies the potential satisfaction that users can obtain. Brandon Smith responds to the proposal, highlighting the need to ensure that existing wallets and users are not vulnerable to scams or delays in transaction processing. He suggests alternative approaches such as Lightning, improved fee estimation, and improved mempool eviction/re-propagation resistance.Another proposal by Alejandro Ranchal Pedrosa suggests enhancing OP_CHECKSEQUENCEVERIFY to allow outputs that are spendable by different parties at different times. Brandon Smith raises concerns about the complexity of implementing such a solution and the potential vulnerabilities it may introduce. He emphasizes the importance of protecting existing wallets and users from malicious actors.The discussion also involves the extension of OP_CSV and/or OP_CLTV to allow and interpret negative values, which would enable time-based invalidation of transactions. Matt Corallo proposes a multisig option with a locktime pre-signed transaction as an alternative approach. The proposal is still under discussion, and a BIP is being prepared.Gregory Maxwell responds to a proposal for non-monotone validity events in Bitcoin transactions, explaining that such functionality has been deemed harmful in the past due to the potential destruction of coins without dishonest actions. He argues that there is no compelling use case for non-monotone validity events once the negative effects are addressed.The email exchange includes references to previous discussions on similar topics and links to papers discussing the proposals. The authors are seeking feedback and discussion before formally proposing the BIPs. 2018-09-07T13:47:17+00:00 + Alejandro Ranchal Pedrosa has proposed studying the possibility of canceling Bitcoin transactions from the user's point of view. He suggests a model for user-agents and quantifies the potential satisfaction that users can obtain. Brandon Smith responds to the proposal, highlighting the need to ensure that existing wallets and users are not vulnerable to scams or delays in transaction processing. He suggests alternative approaches such as Lightning, improved fee estimation, and improved mempool eviction/re-propagation resistance.Another proposal by Alejandro Ranchal Pedrosa suggests enhancing OP_CHECKSEQUENCEVERIFY to allow outputs that are spendable by different parties at different times. Brandon Smith raises concerns about the complexity of implementing such a solution and the potential vulnerabilities it may introduce. He emphasizes the importance of protecting existing wallets and users from malicious actors.The discussion also involves the extension of OP_CSV and/or OP_CLTV to allow and interpret negative values, which would enable time-based invalidation of transactions. Matt Corallo proposes a multisig option with a locktime pre-signed transaction as an alternative approach. The proposal is still under discussion, and a BIP is being prepared.Gregory Maxwell responds to a proposal for non-monotone validity events in Bitcoin transactions, explaining that such functionality has been deemed harmful in the past due to the potential destruction of coins without dishonest actions. He argues that there is no compelling use case for non-monotone validity events once the negative effects are addressed.The email exchange includes references to previous discussions on similar topics and links to papers discussing the proposals. The authors are seeking feedback and discussion before formally proposing the BIPs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_BIP-sighash-noinput.xml b/static/bitcoin-dev/Sept_2018/combined_BIP-sighash-noinput.xml index 43f6d8d1b4..0c31509e71 100644 --- a/static/bitcoin-dev/Sept_2018/combined_BIP-sighash-noinput.xml +++ b/static/bitcoin-dev/Sept_2018/combined_BIP-sighash-noinput.xml @@ -1,110 +1,147 @@ - + 2 Combined summary - BIP sighash_noinput - 2023-08-01T22:58:34.573011+00:00 - - Jonas Nick 2018-09-26 20:40:02+00:00 - - - Johnson Lau 2018-09-26 19:45:49+00:00 - - - Jonas Nick 2018-09-26 09:36:57+00:00 - - - Christian Decker 2018-07-13 11:07:48+00:00 - - - fred savage 2018-07-13 09:50:47+00:00 - - - Rusty Russell 2018-07-13 00:04:14+00:00 - - - ZmnSCPxj 2018-07-11 07:43:49+00:00 - - - Peter Todd 2018-07-09 09:41:39+00:00 - - - vv01f 2018-07-05 08:18:44+00:00 - - - fred savage 2018-07-04 18:08:43+00:00 - - - Gregory Maxwell 2018-07-03 23:45:22+00:00 - - - Luke Dashjr 2018-07-03 12:13:44+00:00 - - - Christian Decker 2018-07-03 12:05:09+00:00 - - - William Casarin 2018-07-03 11:54:37+00:00 - - - ZmnSCPxj 2018-07-03 06:58:36+00:00 - - - Peter Todd 2018-07-03 05:21:00+00:00 - - - Rusty Russell 2018-07-03 04:56:53+00:00 - - - Gregory Maxwell 2018-07-02 18:11:54+00:00 - - - Christian Decker 2018-05-15 14:28:22+00:00 - - - Anthony Towns 2018-05-14 09:23:29+00:00 - - - Christian Decker 2018-05-10 14:12:21+00:00 - - - Rusty Russell 2018-05-09 23:04:58+00:00 - - - Olaoluwa Osuntokun 2018-05-09 23:01:39+00:00 - - - Anthony Towns 2018-05-08 14:40:21+00:00 - - - Olaoluwa Osuntokun 2018-05-07 23:47:23+00:00 - - - Bram Cohen 2018-05-07 20:51:11+00:00 - - - Christian Decker 2018-05-07 19:40:46+00:00 - - - ZmnSCPxj 2018-05-04 14:25:46+00:00 - - - Christian Decker 2018-05-04 11:09:09+00:00 - - - ZmnSCPxj 2018-05-04 09:15:41+00:00 - - - Christian Decker 2018-05-01 17:32:32+00:00 - - - Russell O'Connor 2018-05-01 16:58:37+00:00 - - - Dario Sneidermanis 2018-04-30 18:25:42+00:00 - - - Christian Decker 2018-04-30 16:29:53+00:00 - + 2025-09-26T15:55:56.684289+00:00 + python-feedgen + + + [bitcoin-dev] BIP sighash_noinput Christian Decker + 2018-04-30T16:29:00.000Z + + + Dario Sneidermanis + 2018-04-30T18:25:00.000Z + + + Russell O'Connor + 2018-05-01T16:58:00.000Z + + + Christian Decker + 2018-05-01T17:32:00.000Z + + + ZmnSCPxj + 2018-05-04T09:15:00.000Z + + + Christian Decker + 2018-05-04T11:09:00.000Z + + + ZmnSCPxj + 2018-05-04T14:25:00.000Z + + + Christian Decker + 2018-05-07T19:40:00.000Z + + + Bram Cohen + 2018-05-07T20:51:00.000Z + + + [bitcoin-dev] " Olaoluwa Osuntokun + 2018-05-07T23:47:00.000Z + + + [bitcoin-dev] " Anthony Towns + 2018-05-08T14:40:00.000Z + + + Olaoluwa Osuntokun + 2018-05-09T23:01:00.000Z + + + Rusty Russell + 2018-05-09T23:04:00.000Z + + + Christian Decker + 2018-05-10T14:12:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2018-05-14T09:23:00.000Z + + + Christian Decker + 2018-05-15T14:28:00.000Z + + + Gregory Maxwell + 2018-07-02T18:11:00.000Z + + + Rusty Russell + 2018-07-03T04:56:00.000Z + + + Peter Todd + 2018-07-03T05:21:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2018-07-03T06:58:00.000Z + + + William Casarin + 2018-07-03T11:54:00.000Z + + + Christian Decker + 2018-07-03T12:05:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Luke Dashjr + 2018-07-03T12:13:00.000Z + + + Gregory Maxwell + 2018-07-03T23:45:00.000Z + + + fred savage + 2018-07-04T18:08:00.000Z + + + vv01f + 2018-07-05T08:18:00.000Z + + + Peter Todd + 2018-07-09T09:41:00.000Z + + + ZmnSCPxj + 2018-07-11T07:43:00.000Z + + + Rusty Russell + 2018-07-13T00:04:00.000Z + + + fred savage + 2018-07-13T09:50:00.000Z + + + Christian Decker + 2018-07-13T11:07:00.000Z + + + Jonas Nick + 2018-09-26T09:36:00.000Z + + + Johnson Lau + 2018-09-26T19:45:00.000Z + + + Jonas Nick + 2018-09-26T20:40:00.000Z + + @@ -139,13 +176,13 @@ - python-feedgen + 2 Combined summary - BIP sighash_noinput - 2023-08-01T22:58:34.573011+00:00 + 2025-09-26T15:55:56.688029+00:00 - The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions. Laolu emphasizes the importance of making the proposal small 2018-09-26T20:40:02+00:00 + The discussion on the bitcoin-dev mailing list revolves around the use of the NOINPUT flag in Bitcoin transactions. The main topic of discussion is whether or not to sign the sequence of other inputs in addition to the nSequence of the same input in BIP143.Jonas Nick suggests that NOINPUT should zero out the hashSequence for consistency with ANYONECANPAY, but this would create problems when using eltoo update scripts with OP_CSV. Eltoo update transactions have two branches (update and settlement), and removing OP_CSV could allow them to be taprootified.The settlement branch is a 2-of-2 multisig with a relative timelock using OP_CSV. Both parties' signatures are required to spend the update transaction, which can be signed with SINGLE since it doesn't use relative timelocks. However, there is a catch that hashSequence includes the sequence numbers of all transaction inputs.This can be solved by zeroing out the hashSequence whenever NOINPUT is combined with SINGLE. The modification to the current NOINPUT implementation has been provided. Although this approach has some downsides, such as not being able to rebind to an output with an OP_CSV that requires a larger sequence number unless signed with SIGHASH_SINGLE, it makes eltoo unilateral closes taprootifiable.On the other hand, the use of the SIGHASH_NOINPUT flag is causing concern for several reasons. Firstly, it allows for address reuse, which cannot be prevented due to the push payment nature of Bitcoin. Secondly, average users who rely on the GUI may not understand the technicalities happening behind the scenes. Additionally, as Lightning Network is not validated by the community, a user could manipulate their own node to require SIGHASH_NOINPUT as a condition of the channel, which poses risks for under-the-hood raw transaction risks where a transaction can be signed, but then allow the outs to alter value using a different opcode. This could be abused by a counterparty just editing it so that one party gets nothing and the other gets everything. Finally, allowing certain things to change after signing brings back malleability for those that use a TXID to identify if a transaction has been confirmed.There are also discussions on the naming of the SIGHASH_NOINPUT flag. Some suggest changing the name to "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to reflect its potential insecurity for traditional applications where third-party payments to an address can occur. However, others argue that address reuse is undefined behavior and nobody should assume that it is safe or works.Overall, the discussions revolve around finding the right balance between taprootifiability and security in Bitcoin transactions, particularly with regards to the use of the NOINPUT and SIGHASH_NOINPUT flags.Christian Decker has proposed a new sighash flag called `SIGHASH_NOINPUT` on the bitcoin-dev mailing list. This flag removes the commitment to the previous transaction input. However, there are concerns about its security and potential risks for wallets that might unknowingly use it.Gregory Maxwell suggests changing the name of the flag to something like "SIGHASH_REPLAY_VULNERABLE" or "SIGHASH_WEAK_REPLAYABLE" to better reflect its vulnerability. Rusty Russell supports this suggestion, proposing "REUSE_VULNERABLE" as a name to scare people away from using it.The discussion revolves around the use of `SIGHASH_NOINPUT` and its potential risks. It is suggested that this flag should only be used in special protocols where the risk of reusing addresses is unlikely. There is concern about losing funds when a third party reuses a script pubkey, as funds can be lost when a troublemaker shows up. The risk is magnified because the third party address reuser has no way of knowing if this sighash flag has been or will be used with a particular scriptpubkey. The best mitigation strategy is to ensure that anyone using this flag fully understands the consequences.The discussion also includes considerations about signing with `SIGHASH_NOINPUT` versus signing with `SIGHASH_NONE`. It is more likely that wallets will sign things with `SIGHASH_NOINPUT` when using Lightning v2. There is a suggestion to limit or drop support for `SIGHASH_NONE` for segwit v1 addresses. It is also mentioned that having a separate opcode would have clean semantics but would use up NOP-codes. Additionally, there is a dependency on taproot that is not yet finalized.Laolu Osuntokun, a Bitcoin developer, expresses excitement over the resurrection of the no_input feature in Bitcoin. They suggest introducing a new sighash flag alongside no_input that could include additional flexible sighash flags. They propose a new CHECKSIG operator that would consume an available noop opcode. This approach allows developers to modify scripts within the context of merklized script executions. Laolu emphasizes the importance of making the proposal small - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Extending-BIP174-for-HTLCs.xml b/static/bitcoin-dev/Sept_2018/combined_Extending-BIP174-for-HTLCs.xml index 63668dc529..308054638d 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Extending-BIP174-for-HTLCs.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Extending-BIP174-for-HTLCs.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Extending BIP174 for HTLCs - 2023-08-01T23:53:16.253419+00:00 - - Pieter Wuille 2018-09-04 16:57:28+00:00 - - - Alex Bosworth 2018-09-04 03:24:01+00:00 - + 2025-09-26T15:55:52.403253+00:00 + python-feedgen + + + [bitcoin-dev] Extending BIP174 for HTLCs Alex Bosworth + 2018-09-04T03:24:00.000Z + + + Pieter Wuille + 2018-09-04T16:57:00.000Z + + - python-feedgen + 2 Combined summary - Extending BIP174 for HTLCs - 2023-08-01T23:53:16.253419+00:00 + 2025-09-26T15:55:52.403731+00:00 - A recent proposal has been discussed on the bitcoin-dev mailing list regarding the addition of fields to the Partially Signed Bitcoin Transactions (PSBT) format tag. The purpose of this proposal is to support Hash Time-Locked Contracts (HTLCs) within the PSBT format. One suggestion put forward is to include two new fields in PSBT: a preimage request field and a revealed preimage field. The proposed workflow involves an updater recognizing an output/script that requires a preimage and subsequently adding a preimage request field to the input. This would be followed by a signer who knows the preimage adding a preimage field after verifying the secret. Finally, a compatible finalizer would combine all signatures and preimages into a final scriptSig/witness stack.However, the proposal acknowledges that dealing with multiple possible satisfactions could complicate matters, particularly when there are numerous combinations to consider. As an alternative approach, it has been suggested to use an easily-parsable subset of script, which includes elements such as and/or/threshold/pubkey/locktimes/hashlocks, instead of modifying the PSBT. The author of the proposal intends to provide more information on this topic soon.The author of the proposal has been actively working on HTLC scripts and has been experimenting with a format tag for Bitcoin Improvement Proposal 174 (BIP 174) to support them. The proposed format entails adding a new input type that defines elements to be inserted in the final p2sh/p2wsh stack, such as preimage or refund path flags. The process begins with the creation of a blank PSBT, which is then updated with redeem/witness scripts, sighashes, and partial signatures. Additional stack elements are attached for non-signature elements, followed by finalization to generate the final scriptSig and/or witness. Finally, the signed transaction is extracted for broadcasting.The author acknowledges that this approach may be overly generic and seeks to know if anyone else has considered utilizing PSBTs in an HTLC context. 2018-09-04T16:57:28+00:00 + A recent proposal has been discussed on the bitcoin-dev mailing list regarding the addition of fields to the Partially Signed Bitcoin Transactions (PSBT) format tag. The purpose of this proposal is to support Hash Time-Locked Contracts (HTLCs) within the PSBT format. One suggestion put forward is to include two new fields in PSBT: a preimage request field and a revealed preimage field. The proposed workflow involves an updater recognizing an output/script that requires a preimage and subsequently adding a preimage request field to the input. This would be followed by a signer who knows the preimage adding a preimage field after verifying the secret. Finally, a compatible finalizer would combine all signatures and preimages into a final scriptSig/witness stack.However, the proposal acknowledges that dealing with multiple possible satisfactions could complicate matters, particularly when there are numerous combinations to consider. As an alternative approach, it has been suggested to use an easily-parsable subset of script, which includes elements such as and/or/threshold/pubkey/locktimes/hashlocks, instead of modifying the PSBT. The author of the proposal intends to provide more information on this topic soon.The author of the proposal has been actively working on HTLC scripts and has been experimenting with a format tag for Bitcoin Improvement Proposal 174 (BIP 174) to support them. The proposed format entails adding a new input type that defines elements to be inserted in the final p2sh/p2wsh stack, such as preimage or refund path flags. The process begins with the creation of a blank PSBT, which is then updated with redeem/witness scripts, sighashes, and partial signatures. Additional stack elements are attached for non-signature elements, followed by finalization to generate the final scriptSig and/or witness. Finally, the signed transaction is extracted for broadcasting.The author acknowledges that this approach may be overly generic and seeks to know if anyone else has considered utilizing PSBTs in an HTLC context. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Fwd-bitcoin-core-dev-On-the-initial-notice-of-CVE-2018-17144.xml b/static/bitcoin-dev/Sept_2018/combined_Fwd-bitcoin-core-dev-On-the-initial-notice-of-CVE-2018-17144.xml index 2b72abfdd8..78440212ef 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Fwd-bitcoin-core-dev-On-the-initial-notice-of-CVE-2018-17144.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Fwd-bitcoin-core-dev-On-the-initial-notice-of-CVE-2018-17144.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Fwd: [bitcoin-core-dev] On the initial notice of CVE-2018-17144 - 2023-08-01T23:55:07.308379+00:00 - - Gregory Maxwell 2018-09-22 20:49:04+00:00 - - - sickpig at gmail.com 2018-09-22 19:22:20+00:00 - - - Bryan Bishop 2018-09-22 17:54:12+00:00 - + 2025-09-26T15:55:50.289083+00:00 + python-feedgen + + + [bitcoin-dev] Fwd: [bitcoin-core-dev] On the initial notice of CVE-2018-17144 Bryan Bishop + 2018-09-22T17:54:00.000Z + + + sickpig + 2018-09-22T19:22:00.000Z + + + Gregory Maxwell + 2018-09-22T20:49:00.000Z + + - python-feedgen + 2 Combined summary - Fwd: [bitcoin-core-dev] On the initial notice of CVE-2018-17144 - 2023-08-01T23:55:07.308379+00:00 + 2025-09-26T15:55:50.289654+00:00 - Andrea Suisani's claim on Twitter that the report by awemany was about an inflation bug is challenged by sickpig in an email thread. Sickpig suggests that Andrea may have misunderstood the tweet and did not read it properly. The tweet referenced a Reddit post where awemany included a timestamped note about BitcoinABC not checking for duplicate inputs, which could create money out of thin air. This note was submitted before the report email was sent. Gregory argues that the report explicitly stated that inflation was not possible because the node crashed. Furthermore, awemany mentioned in the report that the code seems to prevent monetary inflation. It is speculated that awemany prioritized informing Core about the identified DoS vector rather than exploring the idea of creating coins out of thin air.The discovered bug in Bitcoin Core and Bitcoin ABC can be exploited by miners, potentially inflating the cryptocurrency's supply. Awemany reported this vulnerability via email, although it is not classified as an inflation bug. Instead, it poses a problem by causing nodes to crash, necessitating a software update. The issue arises from the lack of duplicate input checks in CheckBlock, only being performed when transactions are accepted into the mempool. This allows transactions to bypass the mempool when included in a block. An assertion in SpendCoins appears to prevent the most severe outcome of monetary inflation by crashing the node. Despite existing in both clients, the vulnerability has not been exploited so far.To address doubts within the community regarding the authenticity of awemany's email, Gregory Maxwell shared the full text online. An updated version has been released, but many nodes may remain vulnerable until they apply the patch. Users of Bitcoin Core and Bitcoin ABC are strongly advised to upgrade to the latest version promptly. The patch for Core involves changes to its net_processing.cpp, validation.cpp, and tx_verify.cpp files. Notably, lines of code have been removed from the ProcessGetBlockData function in net_processing.cpp, which previously sent transaction messages to peers. Similarly, lines of code have been removed from the ProcessGetData function, which responded to peers' requests for transaction data. In both cases, vNotFound entries were added if no response was required or if the requested transaction was not in the mempool. Additionally, assertions in the SpendCoins and UpdateCoins functions in validation.cpp have been commented out. Lastly, a patch has been provided for Core, modifying the CheckTransaction function to skip the duplicate input check.Upgrading to the latest version of Bitcoin Core and Bitcoin ABC is crucial to mitigate potential vulnerabilities caused by this bug. 2018-09-22T20:49:04+00:00 + Andrea Suisani's claim on Twitter that the report by awemany was about an inflation bug is challenged by sickpig in an email thread. Sickpig suggests that Andrea may have misunderstood the tweet and did not read it properly. The tweet referenced a Reddit post where awemany included a timestamped note about BitcoinABC not checking for duplicate inputs, which could create money out of thin air. This note was submitted before the report email was sent. Gregory argues that the report explicitly stated that inflation was not possible because the node crashed. Furthermore, awemany mentioned in the report that the code seems to prevent monetary inflation. It is speculated that awemany prioritized informing Core about the identified DoS vector rather than exploring the idea of creating coins out of thin air.The discovered bug in Bitcoin Core and Bitcoin ABC can be exploited by miners, potentially inflating the cryptocurrency's supply. Awemany reported this vulnerability via email, although it is not classified as an inflation bug. Instead, it poses a problem by causing nodes to crash, necessitating a software update. The issue arises from the lack of duplicate input checks in CheckBlock, only being performed when transactions are accepted into the mempool. This allows transactions to bypass the mempool when included in a block. An assertion in SpendCoins appears to prevent the most severe outcome of monetary inflation by crashing the node. Despite existing in both clients, the vulnerability has not been exploited so far.To address doubts within the community regarding the authenticity of awemany's email, Gregory Maxwell shared the full text online. An updated version has been released, but many nodes may remain vulnerable until they apply the patch. Users of Bitcoin Core and Bitcoin ABC are strongly advised to upgrade to the latest version promptly. The patch for Core involves changes to its net_processing.cpp, validation.cpp, and tx_verify.cpp files. Notably, lines of code have been removed from the ProcessGetBlockData function in net_processing.cpp, which previously sent transaction messages to peers. Similarly, lines of code have been removed from the ProcessGetData function, which responded to peers' requests for transaction data. In both cases, vNotFound entries were added if no response was required or if the requested transaction was not in the mempool. Additionally, assertions in the SpendCoins and UpdateCoins functions in validation.cpp have been commented out. Lastly, a patch has been provided for Core, modifying the CheckTransaction function to skip the duplicate input check.Upgrading to the latest version of Bitcoin Core and Bitcoin ABC is crucial to mitigate potential vulnerabilities caused by this bug. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Guiding-transaction-fees-towards-a-more-censorship-resistant-outcome.xml b/static/bitcoin-dev/Sept_2018/combined_Guiding-transaction-fees-towards-a-more-censorship-resistant-outcome.xml index 308f90b13c..812a7ed96a 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Guiding-transaction-fees-towards-a-more-censorship-resistant-outcome.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Guiding-transaction-fees-towards-a-more-censorship-resistant-outcome.xml @@ -1,23 +1,32 @@ - + 2 Combined summary - Guiding transaction fees towards a more censorship resistant outcome - 2023-08-01T23:52:24.726261+00:00 - - Ruben Somsen 2018-09-06 17:35:24+00:00 - - - Ruben Somsen 2018-09-01 17:26:54+00:00 - + 2025-09-26T15:56:00.953289+00:00 + python-feedgen + + + [bitcoin-dev] Guiding transaction fees towards a more censorship resistant outcome Ruben Somsen + 2018-09-01T17:26:00.000Z + + + Damian Williamson + 2018-09-06T08:48:00.000Z + + + Ruben Somsen + 2018-09-06T17:35:00.000Z + + - python-feedgen + 2 Combined summary - Guiding transaction fees towards a more censorship resistant outcome - 2023-08-01T23:52:24.727255+00:00 + 2025-09-26T15:56:00.953874+00:00 - Ruben Somsen, in a recent post on the bitcoin-dev mailing list, discussed the idea of guiding transaction fees towards a more censorship-resistant outcome. He noted that when a user creates a transaction with a fee attached, they are incentivizing miners to add this transaction to the blockchain. The task is usually not very specific -- as long as it ends up in a valid chain with the most Proof-of-Work, miners get paid.However, transactions from Bitcoin Core are slightly more specific about what they ask miners to do. Every transaction is only valid at a block height that is one higher than the last block. BIP 115 by Luke-jr is even more specific and enables users to create transactions that are only valid if they are mined on top of a specific block. Coinjoin, which combines payments of multiple users into a single transaction, can be seen as yet another method for users to be more specific.This brings us to a theoretical scenario where every block contains only a single coinjoin transaction, the validity of which depends on the inclusion of a specific previous block, and the block reward is negligible compared to transaction fees. In this scenario, if miners wish to undo a specific transaction that happened two blocks ago, they would have to create three empty blocks (receiving negligible compensation) in order to overtake the longest chain. While not easy to achieve in practice (e.g. resolving natural forks becomes more complicated), it demonstrates that users can become more empowered than they are today, benefitting censorship resistance.Ruben suggested that such line of thinking may inspire further ideas in this direction. He also pointed out that fee pressure towards censorship resistance happens naturally if the system provides anonymity. If the target transaction that miners wish to censor is indistinguishable from other anonymous transactions, then miners will have no choice but to censor every anonymous transaction, so the end result is very similar to what he imagined linking transactions would do. 2018-09-06T17:35:24+00:00 + Ruben Somsen, in a recent post on the bitcoin-dev mailing list, discussed the idea of guiding transaction fees towards a more censorship-resistant outcome. He noted that when a user creates a transaction with a fee attached, they are incentivizing miners to add this transaction to the blockchain. The task is usually not very specific -- as long as it ends up in a valid chain with the most Proof-of-Work, miners get paid.However, transactions from Bitcoin Core are slightly more specific about what they ask miners to do. Every transaction is only valid at a block height that is one higher than the last block. BIP 115 by Luke-jr is even more specific and enables users to create transactions that are only valid if they are mined on top of a specific block. Coinjoin, which combines payments of multiple users into a single transaction, can be seen as yet another method for users to be more specific.This brings us to a theoretical scenario where every block contains only a single coinjoin transaction, the validity of which depends on the inclusion of a specific previous block, and the block reward is negligible compared to transaction fees. In this scenario, if miners wish to undo a specific transaction that happened two blocks ago, they would have to create three empty blocks (receiving negligible compensation) in order to overtake the longest chain. While not easy to achieve in practice (e.g. resolving natural forks becomes more complicated), it demonstrates that users can become more empowered than they are today, benefitting censorship resistance.Ruben suggested that such line of thinking may inspire further ideas in this direction. He also pointed out that fee pressure towards censorship resistance happens naturally if the system provides anonymity. If the target transaction that miners wish to censor is indistinguishable from other anonymous transactions, then miners will have no choice but to censor every anonymous transaction, so the end result is very similar to what he imagined linking transactions would do. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Multisignature-for-bip-schnorr.xml b/static/bitcoin-dev/Sept_2018/combined_Multisignature-for-bip-schnorr.xml index 6f38e4a3c7..12f41d7119 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Multisignature-for-bip-schnorr.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Multisignature-for-bip-schnorr.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Multisignature for bip-schnorr - 2023-08-01T23:42:34.157571+00:00 - - nakagat 2018-09-12 06:00:17+00:00 - - - Jonas Nick 2018-09-07 08:11:56+00:00 - - - nakagat 2018-08-31 05:22:54+00:00 - - - Erik Aronesty 2018-08-29 11:28:56+00:00 - - - nakagat 2018-08-07 06:35:58+00:00 - + 2025-09-26T15:56:13.693912+00:00 + python-feedgen + + + [bitcoin-dev] Multisignature for bip-schnorr nakagat + 2018-08-07T06:35:00.000Z + + + Erik Aronesty + 2018-08-29T11:28:00.000Z + + + nakagat + 2018-08-31T05:22:00.000Z + + + Jonas Nick + 2018-09-07T08:11:00.000Z + + + nakagat + 2018-09-12T06:00:00.000Z + + - python-feedgen + 2 Combined summary - Multisignature for bip-schnorr - 2023-08-01T23:42:34.157571+00:00 + 2025-09-26T15:56:13.694697+00:00 - A developer named Nakagawa has posted a multisignature procedure using bip-schnorr on the bitcoin-dev mailing list. However, Jonas Nick has pointed out that the writeup appears to be vulnerable to key cancellation attacks. This is because the aggregated public key is simply the sum of public keys without any proof of knowledge of individual secret keys. As a result, an attacker can choose their key in such a way that they can sign alone without requiring the other party's partial signature.To address this vulnerability, Jonas suggests a secure key aggregation scheme described in the MuSig paper. He provides a link to the paper for reference. Nakagawa has also written a new text addressing the issue and includes a link to it for review and feedback. In addition, the original text on multisignatures and threshold signatures is linked for further information.Furthermore, Nakagawa has developed a t-of-k threshold signature procedure using bip-schnorr and is seeking feedback on it. The code for this implementation can be found on Github. Additionally, the original code for both multisignatures and threshold signatures using bip-schnorr is available on Github as well.The post requesting feedback on the multisignature procedure was made on August 13, 2018. While the method is considered cool, it has been pointed out that there are a lot of online steps involved and it does not function as a threshold system. However, it is suggested that using a shamir scheme can solve these issues and prevent birthday attacks. A Medium article explaining this solution is provided as a reference.In conclusion, Nakagawa has shared a multisignature procedure using bip-schnorr but has received feedback about its vulnerability to key cancellation attacks. Suggestions have been made to use a secure key aggregation scheme described in the MuSig paper. Nakagawa has also developed a t-of-k threshold signature procedure and is seeking feedback on both implementations. Links to the relevant code and documentation are provided for review. 2018-09-12T06:00:17+00:00 + A developer named Nakagawa has posted a multisignature procedure using bip-schnorr on the bitcoin-dev mailing list. However, Jonas Nick has pointed out that the writeup appears to be vulnerable to key cancellation attacks. This is because the aggregated public key is simply the sum of public keys without any proof of knowledge of individual secret keys. As a result, an attacker can choose their key in such a way that they can sign alone without requiring the other party's partial signature.To address this vulnerability, Jonas suggests a secure key aggregation scheme described in the MuSig paper. He provides a link to the paper for reference. Nakagawa has also written a new text addressing the issue and includes a link to it for review and feedback. In addition, the original text on multisignatures and threshold signatures is linked for further information.Furthermore, Nakagawa has developed a t-of-k threshold signature procedure using bip-schnorr and is seeking feedback on it. The code for this implementation can be found on Github. Additionally, the original code for both multisignatures and threshold signatures using bip-schnorr is available on Github as well.The post requesting feedback on the multisignature procedure was made on August 13, 2018. While the method is considered cool, it has been pointed out that there are a lot of online steps involved and it does not function as a threshold system. However, it is suggested that using a shamir scheme can solve these issues and prevent birthday attacks. A Medium article explaining this solution is provided as a reference.In conclusion, Nakagawa has shared a multisignature procedure using bip-schnorr but has received feedback about its vulnerability to key cancellation attacks. Suggestions have been made to use a secure key aggregation scheme described in the MuSig paper. Nakagawa has also developed a t-of-k threshold signature procedure and is seeking feedback on both implementations. Links to the relevant code and documentation are provided for review. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Overhauled-BIP151.xml b/static/bitcoin-dev/Sept_2018/combined_Overhauled-BIP151.xml index d796846970..549e7fbb2c 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Overhauled-BIP151.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Overhauled-BIP151.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Overhauled BIP151 - 2023-08-01T23:53:00.951443+00:00 - - Tim Ruffing 2018-09-07 13:00:08+00:00 - - - Jonas Schnelli 2018-09-07 08:34:13+00:00 - - - Gregory Maxwell 2018-09-07 02:31:15+00:00 - - - Tim Ruffing 2018-09-06 23:23:21+00:00 - - - Eric Voskuil 2018-09-04 01:37:30+00:00 - - - Jonas Schnelli 2018-09-03 12:16:19+00:00 - + 2025-09-26T15:56:22.254313+00:00 + python-feedgen + + + [bitcoin-dev] Overhauled BIP151 Jonas Schnelli + 2018-09-03T12:16:00.000Z + + + Eric Voskuil + 2018-09-04T01:37:00.000Z + + + Tim Ruffing + 2018-09-06T23:23:00.000Z + + + Gregory Maxwell + 2018-09-07T02:31:00.000Z + + + Jonas Schnelli + 2018-09-07T08:34:00.000Z + + + Tim Ruffing + 2018-09-07T13:00:00.000Z + + - python-feedgen + 2 Combined summary - Overhauled BIP151 - 2023-08-01T23:53:00.951443+00:00 + 2025-09-26T15:56:22.255186+00:00 - In a discussion about improving the confidentiality of Tor, Gregory Maxwell suggested that the current implementation provides "no confidentiality at all." He proposed using BIP151 to add some long-term confidentiality hedge. The conversation then turned to the potential adoption of NewHope, with concerns raised over its difficulty to implement. However, people already make claims regarding Bitcoin's post-quantum security and this should not be an argument against improving security.The participants discussed the proposed BIP151 encryption for Bitcoin peer-to-peer protocol. They agree that obfuscating the key exchange is important but achieving DPI robustness is out of scope. They suggest using TOR with OBFS4 and deterministic rekeying rules to address all-or-none censorship situations. The proposed encryption adds robustness to the threat model at low costs and low risks. They also discuss the use of chacha20-poly1305 and padding to hide message length without much overhead. They suggest using short IDs instead of ASCII commands for small messages that are used often. The conversation highlights the need for clearer specifications in the BIP, including what to do if MAC verification fails, how to handle even keys, and how to form a 64-bit nonce from one or two uint32. Pseudocode could help clarify some of these issues.In a bitcoin-dev discussion, the topic of improving privacy and security in Bitcoin's peer-to-peer (p2p) connections was brought up. One suggestion was to use an ECDH key exchange with an encoding of public keys that provides indistinguishability from random bitstrings. However, this would require writing new cryptographic code and may not actually improve security as Bitcoin traffic is easily identifiable by its traffic patterns. Another proposal was to enhance BIP151, which currently does not add any long-term confidentiality for p2p connections running over Tor. This could be achieved by adding some level of confidentiality hedge. The discussion also touched on the need to improve key derivation to prevent an attacker from creating a situation where two peers think they're in the same session, but they're not. Finally, there was disagreement over whether improving security would hinder adoption or give people a false sense of security.In a discussion about the Bitcoin protocol, the idea of using a shared secret to avoid issues with signaling re-keying in the length field was proposed. The contributory key model was also discussed, but it was determined that an attack form was not possible. There was debate around the use of deterministic rekeying rules versus different policies, which could lead to fingerprinting implementations. It was suggested that using a cipher suite that effectively "rekeyed" every message would be preferable, but there are no well-analyzed authenticated encryption modes with this property. When it comes to choosing between AES-GCM and ChaCha20/Poly1305, both are reasonable choices, but on devices without hardware AES/clmul constant time AES-GCM is very slow compared to ChaCha20/Poly1305. The possibility of padding to hide message length without too much overhead was suggested, but it was noted that it could only be done at the message level. Writing things in stone to avoid complexity and fingerprinting was deemed impractical, as new proposals for messages where the overhead matters are upcoming. "May negotiate" was introduced to avoid a debate about who assigned numbers from the limited space in the future. Encryption can kill external analyzers, but logging traffic is still possible. Lastly, there was a debate about whether the re-keying must be done after every 1GB of data sent or received, with the consensus being that it should just read "sent" instead of "sent or received."The author of the message has commented on various aspects of Bitcoin's security and suggested improvements. The post-quantum key exchange is considered overkill and may hinder adoption. Instead, it is suggested to have a simple ECDH key exchange with an encoding of public keys that provides indistinguishability from random bitstrings. A better key derivation method is proposed to avoid issues such as an attacker rerandomizing public keys. Deterministic rekeying rules are preferred over signaling re-keying in the length field as signal bits can be flipped by attackers. The lack of clarity in some areas of the protocol is pointed out, and suggestions for improvement are provided. Pseudocode is suggested to help understand the protocol better.Jonas Schnelli has proposed an overhaul of the BIP151 specification for Bitcoin, which he believes could be further optimized. A new proposal draft is available on GitHub and includes several changes, such as a pure 32-byte-per-side "pseudorandom" key exchange that happens before anything else, the removal of the multi-message envelope, and the introduction of a NODE_ENCRYPTED service bit. The length of a packet now uses a 3-byte integer with 23 available bits, and there is an introduction of short-command-ID, which results in some v2 messages requiring less bandwidth than v1. Schnelli has also suggested 2018-09-07T13:00:08+00:00 + In a discussion about improving the confidentiality of Tor, Gregory Maxwell suggested that the current implementation provides "no confidentiality at all." He proposed using BIP151 to add some long-term confidentiality hedge. The conversation then turned to the potential adoption of NewHope, with concerns raised over its difficulty to implement. However, people already make claims regarding Bitcoin's post-quantum security and this should not be an argument against improving security.The participants discussed the proposed BIP151 encryption for Bitcoin peer-to-peer protocol. They agree that obfuscating the key exchange is important but achieving DPI robustness is out of scope. They suggest using TOR with OBFS4 and deterministic rekeying rules to address all-or-none censorship situations. The proposed encryption adds robustness to the threat model at low costs and low risks. They also discuss the use of chacha20-poly1305 and padding to hide message length without much overhead. They suggest using short IDs instead of ASCII commands for small messages that are used often. The conversation highlights the need for clearer specifications in the BIP, including what to do if MAC verification fails, how to handle even keys, and how to form a 64-bit nonce from one or two uint32. Pseudocode could help clarify some of these issues.In a bitcoin-dev discussion, the topic of improving privacy and security in Bitcoin's peer-to-peer (p2p) connections was brought up. One suggestion was to use an ECDH key exchange with an encoding of public keys that provides indistinguishability from random bitstrings. However, this would require writing new cryptographic code and may not actually improve security as Bitcoin traffic is easily identifiable by its traffic patterns. Another proposal was to enhance BIP151, which currently does not add any long-term confidentiality for p2p connections running over Tor. This could be achieved by adding some level of confidentiality hedge. The discussion also touched on the need to improve key derivation to prevent an attacker from creating a situation where two peers think they're in the same session, but they're not. Finally, there was disagreement over whether improving security would hinder adoption or give people a false sense of security.In a discussion about the Bitcoin protocol, the idea of using a shared secret to avoid issues with signaling re-keying in the length field was proposed. The contributory key model was also discussed, but it was determined that an attack form was not possible. There was debate around the use of deterministic rekeying rules versus different policies, which could lead to fingerprinting implementations. It was suggested that using a cipher suite that effectively "rekeyed" every message would be preferable, but there are no well-analyzed authenticated encryption modes with this property. When it comes to choosing between AES-GCM and ChaCha20/Poly1305, both are reasonable choices, but on devices without hardware AES/clmul constant time AES-GCM is very slow compared to ChaCha20/Poly1305. The possibility of padding to hide message length without too much overhead was suggested, but it was noted that it could only be done at the message level. Writing things in stone to avoid complexity and fingerprinting was deemed impractical, as new proposals for messages where the overhead matters are upcoming. "May negotiate" was introduced to avoid a debate about who assigned numbers from the limited space in the future. Encryption can kill external analyzers, but logging traffic is still possible. Lastly, there was a debate about whether the re-keying must be done after every 1GB of data sent or received, with the consensus being that it should just read "sent" instead of "sent or received."The author of the message has commented on various aspects of Bitcoin's security and suggested improvements. The post-quantum key exchange is considered overkill and may hinder adoption. Instead, it is suggested to have a simple ECDH key exchange with an encoding of public keys that provides indistinguishability from random bitstrings. A better key derivation method is proposed to avoid issues such as an attacker rerandomizing public keys. Deterministic rekeying rules are preferred over signaling re-keying in the length field as signal bits can be flipped by attackers. The lack of clarity in some areas of the protocol is pointed out, and suggestions for improvement are provided. Pseudocode is suggested to help understand the protocol better.Jonas Schnelli has proposed an overhaul of the BIP151 specification for Bitcoin, which he believes could be further optimized. A new proposal draft is available on GitHub and includes several changes, such as a pure 32-byte-per-side "pseudorandom" key exchange that happens before anything else, the removal of the multi-message envelope, and the introduction of a NODE_ENCRYPTED service bit. The length of a packet now uses a 3-byte integer with 23 available bits, and there is an introduction of short-command-ID, which results in some v2 messages requiring less bandwidth than v1. Schnelli has also suggested - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml b/static/bitcoin-dev/Sept_2018/combined_Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml index cb373b0833..e154151bb9 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Proposal to replace full blockchain with recent history plus UTXO Set - 2023-08-01T23:54:47.860579+00:00 - - Dave Scotese 2018-09-25 15:47:28+00:00 - - - Dave Scotese 2018-09-22 01:49:47+00:00 - + 2025-09-26T15:56:07.345045+00:00 + python-feedgen + + + [bitcoin-dev] Proposal to replace full blockchain with recent history plus UTXO Set Dave Scotese + 2018-09-22T01:49:00.000Z + + + Dave Scotese + 2018-09-25T15:47:00.000Z + + - python-feedgen + 2 Combined summary - Proposal to replace full blockchain with recent history plus UTXO Set - 2023-08-01T23:54:47.860579+00:00 + 2025-09-26T15:56:07.345549+00:00 - Dave Scotese has come up with an idea to relieve full nodes from the burden of storing the entire blockchain. His proposal suggests that if a UTXO set at a specific block height is recognized by humans and agreed upon by enough people, then the blockchain up to that point can be discarded. To test this concept, he offers $50 worth of bitcoin to anyone who can provide him with a UTXO set from the Bitcoin client.In addition to his idea, Dave shares a memorable experience he created using the game of life on block 542322 of the Bitcoin blockchain. However, there were incorrect references on both imgur and pastebin, and he clarifies that the correct block is 542322. He also encourages more people to run full nodes without the hassle of long waits and excessive storage space as the blockchain continues to grow.The author emphasizes the importance of trust in third parties, explaining that large composite groups are generally trusted to prevent any small group or individual from profiting through cheating. They welcome any concerns or offers of help regarding their proposal.To further incentivize participation, Dave offers $50 of bitcoin to anyone who can provide the UTXO set required to create a recognizable checkpoint for the Bitcoin blockchain. Additionally, they offer another $50 to anyone who runs Golly, an open-source Game-of-Life software, and shares a video of the game playing out into the apron-shaped image.In conclusion, Dave envisions a future where more people will run full nodes without the inconvenience of long wait times and extensive storage requirements. This vision may become a reality in a few decades, once the blockchain has grown to a few terabytes while the UTXO set remains just a few gigabytes. 2018-09-25T15:47:28+00:00 + Dave Scotese has come up with an idea to relieve full nodes from the burden of storing the entire blockchain. His proposal suggests that if a UTXO set at a specific block height is recognized by humans and agreed upon by enough people, then the blockchain up to that point can be discarded. To test this concept, he offers $50 worth of bitcoin to anyone who can provide him with a UTXO set from the Bitcoin client.In addition to his idea, Dave shares a memorable experience he created using the game of life on block 542322 of the Bitcoin blockchain. However, there were incorrect references on both imgur and pastebin, and he clarifies that the correct block is 542322. He also encourages more people to run full nodes without the hassle of long waits and excessive storage space as the blockchain continues to grow.The author emphasizes the importance of trust in third parties, explaining that large composite groups are generally trusted to prevent any small group or individual from profiting through cheating. They welcome any concerns or offers of help regarding their proposal.To further incentivize participation, Dave offers $50 of bitcoin to anyone who can provide the UTXO set required to create a recognizable checkpoint for the Bitcoin blockchain. Additionally, they offer another $50 to anyone who runs Golly, an open-source Game-of-Life software, and shares a video of the game playing out into the apron-shaped image.In conclusion, Dave envisions a future where more people will run full nodes without the inconvenience of long wait times and extensive storage requirements. This vision may become a reality in a few decades, once the blockchain has grown to a few terabytes while the UTXO set remains just a few gigabytes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_RFC-BIP-322-Generic-Signed-Message-Format.xml b/static/bitcoin-dev/Sept_2018/combined_RFC-BIP-322-Generic-Signed-Message-Format.xml index e5a56cb71c..f82685a689 100644 --- a/static/bitcoin-dev/Sept_2018/combined_RFC-BIP-322-Generic-Signed-Message-Format.xml +++ b/static/bitcoin-dev/Sept_2018/combined_RFC-BIP-322-Generic-Signed-Message-Format.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - RFC: BIP 322: Generic Signed Message Format - 2023-08-01T23:53:49.325127+00:00 - - Karl-Johan Alm 2018-09-12 07:56:25+00:00 - - - Karl-Johan Alm 2018-09-11 04:41:57+00:00 - + 2025-09-26T15:56:24.384116+00:00 + python-feedgen + + + [bitcoin-dev] RFC: BIP 322: Generic Signed Message Format Karl-Johan Alm + 2018-09-11T04:41:00.000Z + + + Karl-Johan Alm + 2018-09-12T07:56:00.000Z + + - python-feedgen + 2 Combined summary - RFC: BIP 322: Generic Signed Message Format - 2023-08-01T23:53:49.325127+00:00 + 2025-09-26T15:56:24.384537+00:00 - The proposal to extend the existing sign/verifymessage format in Bitcoin has been updated. The new proposal, called the Generic Signed Message Format, can be found at this link: https://github.com/kallewoof/bips/blob/bip-generic-signmessage/bip-0322.mediawiki. One major aspect of the feedback received was whether proofs should be given as transactions or not. Using the transaction format offers advantages such as compatibility with existing HSMs and easier incorporation into existing software. It also provides forward compatibility with bitcoin extensions like mimblewimble and confidential transactions, as well as compatibility with HSMs regardless of whether a transaction or a message is being signed. However, there are drawbacks to using the transaction format. For example, if a challenger convinces a prover to sign a message that corresponds to an actual transaction, there could be danger. Unupgraded software may also struggle to differentiate between message signing and transaction signing. Additionally, hardware wallets that display the contents of the transaction during signing may experience a less user-friendly experience. HSMs also do not support the transaction format or upgrading, which is intentional.There is some debate over whether an "OP_MESSAGEONLY" opcode should be introduced, but the priority is addressing the aforementioned issues first. The proposal introduces a new structure called SignatureProof, which serves as a simple serializable scriptSig & witnessProgram container. This structure defines two actions: "Sign" and "Verify." It is important to note that this new proposal is not backwards compatible with the legacy signmessage/verifymessage specification. However, it can still be used with legacy addresses (1...) without any problems.The goal of this proposal is to create a more generalized variant of the sign/verifymessage format by relying on the script verification mechanism in Bitcoin itself. By doing so, the format can accommodate various types of addresses beyond just P2PKH (1...) addresses. This would allow for greater flexibility without burdening implementers, who likely already have access to Bitcoin Script interpreters.The Generic Signed Message Format specification provides detailed steps for signing and verifying messages. It also has the potential to handle proof of funds using the message prefix "POF:" followed by a newline-terminated string and a series of hex-encoded transaction ID:vout pairs.It is important to note that the proposal is still in the draft stage, and no comments have been posted yet. The document is licensed under the Creative Commons CC0 1.0 Universal license. At this time, the reference implementation is not available, and this section of the proposal remains to be completed. 2018-09-12T07:56:25+00:00 + The proposal to extend the existing sign/verifymessage format in Bitcoin has been updated. The new proposal, called the Generic Signed Message Format, can be found at this link: https://github.com/kallewoof/bips/blob/bip-generic-signmessage/bip-0322.mediawiki. One major aspect of the feedback received was whether proofs should be given as transactions or not. Using the transaction format offers advantages such as compatibility with existing HSMs and easier incorporation into existing software. It also provides forward compatibility with bitcoin extensions like mimblewimble and confidential transactions, as well as compatibility with HSMs regardless of whether a transaction or a message is being signed. However, there are drawbacks to using the transaction format. For example, if a challenger convinces a prover to sign a message that corresponds to an actual transaction, there could be danger. Unupgraded software may also struggle to differentiate between message signing and transaction signing. Additionally, hardware wallets that display the contents of the transaction during signing may experience a less user-friendly experience. HSMs also do not support the transaction format or upgrading, which is intentional.There is some debate over whether an "OP_MESSAGEONLY" opcode should be introduced, but the priority is addressing the aforementioned issues first. The proposal introduces a new structure called SignatureProof, which serves as a simple serializable scriptSig & witnessProgram container. This structure defines two actions: "Sign" and "Verify." It is important to note that this new proposal is not backwards compatible with the legacy signmessage/verifymessage specification. However, it can still be used with legacy addresses (1...) without any problems.The goal of this proposal is to create a more generalized variant of the sign/verifymessage format by relying on the script verification mechanism in Bitcoin itself. By doing so, the format can accommodate various types of addresses beyond just P2PKH (1...) addresses. This would allow for greater flexibility without burdening implementers, who likely already have access to Bitcoin Script interpreters.The Generic Signed Message Format specification provides detailed steps for signing and verifying messages. It also has the potential to handle proof of funds using the message prefix "POF:" followed by a newline-terminated string and a series of hex-encoded transaction ID:vout pairs.It is important to note that the proposal is still in the draft stage, and no comments have been posted yet. The document is licensed under the Creative Commons CC0 1.0 Universal license. At this time, the reference implementation is not available, and this section of the proposal remains to be completed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_SIGHASH2-for-version-1-witness-programme.xml b/static/bitcoin-dev/Sept_2018/combined_SIGHASH2-for-version-1-witness-programme.xml index d83fb447f7..23c0b6279e 100644 --- a/static/bitcoin-dev/Sept_2018/combined_SIGHASH2-for-version-1-witness-programme.xml +++ b/static/bitcoin-dev/Sept_2018/combined_SIGHASH2-for-version-1-witness-programme.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 - - Christian Decker 2018-09-03 13:53:33+00:00 - - - Johnson Lau 2018-08-31 07:42:07+00:00 - - - Christian Decker 2018-08-30 20:51:15+00:00 - - - Johnson Lau 2018-08-30 20:38:06+00:00 - - - Gregory Maxwell 2018-07-02 18:23:48+00:00 - - - Johnson Lau 2018-06-01 18:45:57+00:00 - - - Russell O'Connor 2018-06-01 18:15:32+00:00 - - - Johnson Lau 2018-06-01 17:03:05+00:00 - - - Russell O'Connor 2018-06-01 15:03:46+00:00 - - - Johnson Lau 2018-05-31 18:35:41+00:00 - + 2025-09-26T15:56:17.988616+00:00 + python-feedgen + + + [bitcoin-dev] SIGHASH2 for version 1 witness programme Johnson Lau + 2018-05-31T18:35:00.000Z + + + Russell O'Connor + 2018-06-01T15:03:00.000Z + + + Johnson Lau + 2018-06-01T17:03:00.000Z + + + Russell O'Connor + 2018-06-01T18:15:00.000Z + + + Johnson Lau + 2018-06-01T18:45:00.000Z + + + Gregory Maxwell + 2018-07-02T18:23:00.000Z + + + Johnson Lau + 2018-08-30T20:38:00.000Z + + + Christian Decker + 2018-08-30T20:51:00.000Z + + + Johnson Lau + 2018-08-31T07:42:00.000Z + + + Christian Decker + 2018-09-03T13:53:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - SIGHASH2 for version 1 witness programme - 2023-08-01T23:21:30.159480+00:00 + 2025-09-26T15:56:17.989816+00:00 - A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. 2018-09-03T13:53:33+00:00 + A new proposal called SIGHASH2 has been introduced to simplify the existing SIGHASH and the BIP118 SIGHASH_NOINPUT. The format of SIGHASH2 includes bit flags that denote various values, such as the type of hash and the fees. The proposal aims to save block space by using a more efficient DER format for signatures. It builds upon previous proposals like Taproot and Graftroot.The SIGHASH2 format introduces several new features, including the decoupling of INPUT and SEQUENCE, which allows for optional signing of fees and optimization of signature size. Feedback is being sought on whether certain parameters should be committed to scriptCode and/or scriptPubKey, whether LASTOUTPUT and DUALOUTPUT should be added, and whether a fully flexible way to sign a subset of outputs is desired.The proposed SIGHASH2 format provides equivalent values for other SIGHASH schemes, such as Legacy/BIP143 ALL and SINGLE with matching output. The motivation behind these changes includes the need for compact signatures and increased flexibility.It is important to note that the proposal for SIGHASH2 falls under BIP YYY and is a soft-fork, ensuring backward compatibility. The deployment details are yet to be determined, but the reference implementation can be found on GitHub.In another email conversation, Johnson Lau discusses possible improvements to Bitcoin's serialization process. He questions the use of Double SHA256 and suggests the possibility of replacing it with Single SHA256. The conversation also explores the placement of `sigversion` in the format and its length, with Lau suggesting it should be at the beginning for pre-computation and optimization purposes. The idea of adding a separate opcode for CHECKSIGFROMSTACK is also discussed, along with the effectiveness of putting a 64-byte constant at the beginning of SHA256.Overall, these proposals and discussions highlight ongoing efforts to improve the security, flexibility, and efficiency of Bitcoin transactions. Feedback and contributions from the Bitcoin community are essential for further development and implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_SLIP-0039-Shamir-s-Secret-Sharing-for-Mnemonic-Codes.xml b/static/bitcoin-dev/Sept_2018/combined_SLIP-0039-Shamir-s-Secret-Sharing-for-Mnemonic-Codes.xml index b71f345c9e..59ceebcdec 100644 --- a/static/bitcoin-dev/Sept_2018/combined_SLIP-0039-Shamir-s-Secret-Sharing-for-Mnemonic-Codes.xml +++ b/static/bitcoin-dev/Sept_2018/combined_SLIP-0039-Shamir-s-Secret-Sharing-for-Mnemonic-Codes.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes - 2023-08-01T23:54:21.912176+00:00 - - Andrew Kozlik 2018-09-26 13:44:16+00:00 - - - Andrew Kozlik 2018-09-26 12:12:40+00:00 - - - Ignacio Berrozpe 2018-09-24 19:49:08+00:00 - - - vizeet srivastava 2018-09-22 04:54:24+00:00 - - - Christopher Allen 2018-09-21 19:29:33+00:00 - - - Andrew Kozlik 2018-09-20 16:19:56+00:00 - + 2025-09-26T15:55:54.528000+00:00 + python-feedgen + + + [bitcoin-dev] SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes Andrew Kozlik + 2018-09-20T16:19:00.000Z + + + Christopher Allen + 2018-09-21T19:29:00.000Z + + + vizeet srivastava + 2018-09-22T04:54:00.000Z + + + Ignacio Berrozpe + 2018-09-24T19:49:00.000Z + + + Andrew Kozlik + 2018-09-26T12:12:00.000Z + + + Andrew Kozlik + 2018-09-26T13:44:00.000Z + + - python-feedgen + 2 Combined summary - SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes - 2023-08-01T23:54:21.913175+00:00 + 2025-09-26T15:55:54.528867+00:00 - Andrew Kozlik, a member of the TREZOR team, has proposed a new specification for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing (SSS) scheme. Ignacio Berrozpe, who previously proposed a similar concept of splitting Bitcoin private keys into shares using BIP-0039 mnemonic words, commented on Kozlik's proposal. He suggested standardizing the encoding format, splitting the pre-master secret into shares, and deriving the master secret from the pre-master secret under the same proposal. Berrozpe also raised concerns about migrating existing legacy private keys encoded into BIP-0039 or stored in other formats securely into an encoded SSS shares schema.Kozlik responded that their intention is to standardize the encoding format, split the pre-master secret into shares, and derive the master secret from the pre-master secret in a single document. However, only one of the four proposed master secret derivation functions will be selected for the final version. Kozlik also mentioned that three of the four proposed master secret derivation functions are symmetric, allowing users to migrate any existing master secret, including a BIP-0039 mnemonic, to the new scheme.A developer is currently working on a specification for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme and seeks feedback from the Bitcoin development community. The developer specifically requests input on the "Master secret derivation functions" section of the document, which proposes various solutions. Although some technical details have yet to be fully specified, they will be completed once the high-level design is settled. Christopher Allen expressed interest in the proposal, as it relates to his previous work on improving mnemonic word lists. He posed several questions regarding the design of the scheme, including discussions on standardizing a Shamir Secret Sharing Scheme and mitigating adversarial problems associated with recovery of a SSS.Ignacio Berrozpe reached out to Andrew Kozlik via bitcoin-dev to comment on the proposal for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme. Berrozpe suggested that hardware wallet providers like Trezor could offer a more secure alternative to existing BIP-0039 private key backups by utilizing SSS shares encoded directly with BIP-0039 mnemonics. He asked Kozlik if he planned to standardize different topics under the same proposal and how to deal with existing legacy private keys already encoded into BIP-0039 or stored in other formats securely migrating them into an encoded SSS shares schema. Kozlik responded by sharing the high-level design of the new specification and seeking feedback, particularly on the "Master secret derivation functions" section. Kozlik acknowledged that some technical details are yet to be specified but assured they would be completed once the high-level design is finalized. The document is still a work in progress, and Kozlik is interested in receiving input from the community.A new specification is being developed for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme. The developer is seeking feedback on the design, specifically on the "Master secret derivation functions" section, which proposes different solutions. The document is currently a work in progress, and once the high-level design is settled, the remaining technical details will be specified. Christopher Allen and various companies and communities have shown interest in the proposal. Allen has raised questions about standardizing a Shamir Secret Sharing Scheme and suggested incorporating the Lightning Network community's ability to have a birthday in the seed. Additionally, he proposed using a filtered word list inspired by iambic pentameter poetry for improved memorability.The development of a new specification for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme is underway. The document, available on Github, seeks feedback from the community, with a focus on the "Master secret derivation functions" section. Various companies and communities, including #RebootingWebOfTrust, have expressed interest in standardizing the Shamir Secret Sharing Scheme. Discussions can be held on the mailing list or issues in the SLIPS repo. Potential adversarial problems during recovery of a SSS, such as impersonation and MitM attacks causing potential DOS attacks, should be considered. The Lightning Network community has added the ability to have a birthday in the seed for improved scanning of the blockchain for keys. Chris Vickery's work on mnemonic word lists, including an iambic pentameter poetry-inspired word list filtered for memorability, can be incorporated into the criteria for replication. 2018-09-26T13:44:16+00:00 + Andrew Kozlik, a member of the TREZOR team, has proposed a new specification for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing (SSS) scheme. Ignacio Berrozpe, who previously proposed a similar concept of splitting Bitcoin private keys into shares using BIP-0039 mnemonic words, commented on Kozlik's proposal. He suggested standardizing the encoding format, splitting the pre-master secret into shares, and deriving the master secret from the pre-master secret under the same proposal. Berrozpe also raised concerns about migrating existing legacy private keys encoded into BIP-0039 or stored in other formats securely into an encoded SSS shares schema.Kozlik responded that their intention is to standardize the encoding format, split the pre-master secret into shares, and derive the master secret from the pre-master secret in a single document. However, only one of the four proposed master secret derivation functions will be selected for the final version. Kozlik also mentioned that three of the four proposed master secret derivation functions are symmetric, allowing users to migrate any existing master secret, including a BIP-0039 mnemonic, to the new scheme.A developer is currently working on a specification for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme and seeks feedback from the Bitcoin development community. The developer specifically requests input on the "Master secret derivation functions" section of the document, which proposes various solutions. Although some technical details have yet to be fully specified, they will be completed once the high-level design is settled. Christopher Allen expressed interest in the proposal, as it relates to his previous work on improving mnemonic word lists. He posed several questions regarding the design of the scheme, including discussions on standardizing a Shamir Secret Sharing Scheme and mitigating adversarial problems associated with recovery of a SSS.Ignacio Berrozpe reached out to Andrew Kozlik via bitcoin-dev to comment on the proposal for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme. Berrozpe suggested that hardware wallet providers like Trezor could offer a more secure alternative to existing BIP-0039 private key backups by utilizing SSS shares encoded directly with BIP-0039 mnemonics. He asked Kozlik if he planned to standardize different topics under the same proposal and how to deal with existing legacy private keys already encoded into BIP-0039 or stored in other formats securely migrating them into an encoded SSS shares schema. Kozlik responded by sharing the high-level design of the new specification and seeking feedback, particularly on the "Master secret derivation functions" section. Kozlik acknowledged that some technical details are yet to be specified but assured they would be completed once the high-level design is finalized. The document is still a work in progress, and Kozlik is interested in receiving input from the community.A new specification is being developed for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme. The developer is seeking feedback on the design, specifically on the "Master secret derivation functions" section, which proposes different solutions. The document is currently a work in progress, and once the high-level design is settled, the remaining technical details will be specified. Christopher Allen and various companies and communities have shown interest in the proposal. Allen has raised questions about standardizing a Shamir Secret Sharing Scheme and suggested incorporating the Lightning Network community's ability to have a birthday in the seed. Additionally, he proposed using a filtered word list inspired by iambic pentameter poetry for improved memorability.The development of a new specification for splitting BIP-32 master seeds into multiple mnemonics using Shamir's secret sharing scheme is underway. The document, available on Github, seeks feedback from the community, with a focus on the "Master secret derivation functions" section. Various companies and communities, including #RebootingWebOfTrust, have expressed interest in standardizing the Shamir Secret Sharing Scheme. Discussions can be held on the mailing list or issues in the SLIPS repo. Potential adversarial problems during recovery of a SSS, such as impersonation and MitM attacks causing potential DOS attacks, should be considered. The Lightning Network community has added the ability to have a birthday in the seed for improved scanning of the blockchain for keys. Chris Vickery's work on mnemonic word lists, including an iambic pentameter poetry-inspired word list filtered for memorability, can be incorporated into the criteria for replication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Schnorr-signatures-BIP.xml b/static/bitcoin-dev/Sept_2018/combined_Schnorr-signatures-BIP.xml index f9fcd92c8f..43d36f646f 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Schnorr-signatures-BIP.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Schnorr-signatures-BIP.xml @@ -1,101 +1,135 @@ - + 2 Combined summary - Schnorr signatures BIP - 2023-08-01T23:34:39.972386+00:00 - - Russell O'Connor 2018-09-20 21:12:42+00:00 - - - Andrew Poelstra 2018-09-14 14:38:02+00:00 - - - Erik Aronesty 2018-09-13 20:20:36+00:00 - - - Andrew Poelstra 2018-09-13 18:46:50+00:00 - - - Erik Aronesty 2018-09-11 18:30:13+00:00 - - - Gregory Maxwell 2018-09-11 17:51:01+00:00 - - - Erik Aronesty 2018-09-11 17:37:59+00:00 - - - Gregory Maxwell 2018-09-11 17:27:09+00:00 - - - Erik Aronesty 2018-09-11 17:20:01+00:00 - - - Gregory Maxwell 2018-09-11 17:00:25+00:00 - - - Erik Aronesty 2018-09-11 16:34:11+00:00 - - - Gregory Maxwell 2018-09-05 15:35:14+00:00 - - - Erik Aronesty 2018-09-05 13:14:55+00:00 - - - Andrew Poelstra 2018-09-05 13:05:59+00:00 - - - Erik Aronesty 2018-09-05 12:26:14+00:00 - - - Andrew Poelstra 2018-09-03 00:05:18+00:00 - - - Erik Aronesty 2018-08-29 12:09:36+00:00 - - - Andrew Poelstra 2018-08-12 16:37:35+00:00 - - - Tim Ruffing 2018-08-06 21:12:48+00:00 - - - Russell O'Connor 2018-08-06 14:00:59+00:00 - - - Anthony Towns 2018-08-06 08:39:25+00:00 - - - Russell O'Connor 2018-08-05 14:33:52+00:00 - - - Russell O'Connor 2018-08-04 12:22:28+00:00 - - - Pieter Wuille 2018-07-14 21:20:48+00:00 - - - Sjors Provoost 2018-07-14 15:42:58+00:00 - - - Russell O'Connor 2018-07-08 14:36:16+00:00 - - - Артём Литвинович 2018-07-07 02:47:40+00:00 - - - Gregory Maxwell 2018-07-06 22:01:32+00:00 - - - Gregory Maxwell 2018-07-06 22:00:28+00:00 - - - Russell O'Connor 2018-07-06 21:05:03+00:00 - - - Pieter Wuille 2018-07-06 18:08:34+00:00 - + 2025-09-26T15:55:48.170949+00:00 + python-feedgen + + + [bitcoin-dev] Schnorr signatures BIP Pieter Wuille + 2018-07-06T18:08:00.000Z + + + Russell O'Connor + 2018-07-06T21:05:00.000Z + + + Gregory Maxwell + 2018-07-06T22:00:00.000Z + + + Gregory Maxwell + 2018-07-06T22:01:00.000Z + + + Артём Литвинович + 2018-07-07T02:47:00.000Z + + + Russell O'Connor + 2018-07-08T14:36:00.000Z + + + Sjors Provoost + 2018-07-14T15:42:00.000Z + + + Pieter Wuille + 2018-07-14T21:20:00.000Z + + + Russell O'Connor + 2018-08-04T12:22:00.000Z + + + Russell O'Connor + 2018-08-05T14:33:00.000Z + + + Anthony Towns + 2018-08-06T08:39:00.000Z + + + Russell O'Connor + 2018-08-06T14:00:00.000Z + + + Tim Ruffing + 2018-08-06T21:12:00.000Z + + + Andrew Poelstra + 2018-08-12T16:37:00.000Z + + + Erik Aronesty + 2018-08-29T12:09:00.000Z + + + Andrew Poelstra + 2018-09-03T00:05:00.000Z + + + Erik Aronesty + 2018-09-05T12:26:00.000Z + + + Andrew Poelstra + 2018-09-05T13:05:00.000Z + + + Erik Aronesty + 2018-09-05T13:14:00.000Z + + + Gregory Maxwell + 2018-09-05T15:35:00.000Z + + + Erik Aronesty + 2018-09-11T16:34:00.000Z + + + Gregory Maxwell + 2018-09-11T17:00:00.000Z + + + Erik Aronesty + 2018-09-11T17:20:00.000Z + + + Gregory Maxwell + 2018-09-11T17:27:00.000Z + + + Erik Aronesty + 2018-09-11T17:37:00.000Z + + + Gregory Maxwell + 2018-09-11T17:51:00.000Z + + + Erik Aronesty + 2018-09-11T18:30:00.000Z + + + Andrew Poelstra + 2018-09-13T18:46:00.000Z + + + Erik Aronesty + 2018-09-13T20:20:00.000Z + + + Andrew Poelstra + 2018-09-14T14:38:00.000Z + + + Russell O'Connor + 2018-09-20T21:12:00.000Z + + @@ -127,13 +161,13 @@ - python-feedgen + 2 Combined summary - Schnorr signatures BIP - 2023-08-01T23:34:39.972386+00:00 + 2025-09-26T15:55:48.174061+00:00 - Pieter Wuille's proposal for a BIP (Bitcoin Improvement Proposal) aims to introduce 64-byte elliptic curve Schnorr signatures into the Bitcoin development community. This draft specification is an important step towards standardizing the signature scheme, although it does not directly address consensus rules or aggregation. Wuille plans to collaborate with others to create production-ready reference implementations and conduct tests using the proposed scheme. It is also noted that this signature scheme may have applications beyond the scope of Bitcoin.In the discussion surrounding the proposal, Andrew Poelstra clarifies that M-of-N threshold MuSig signatures can be created for any values of M and N. By combining Schnorr signatures with Pedersen Secret Sharing, a secure interactive threshold signature scheme can be achieved, ensuring that signatures can only be produced by predetermined sets of signers. Poelstra also mentions that he has implemented the combination of MuSig and VSS (Verifiable Secret Sharing) in his code. However, there are unanswered questions raised by Erik Aronesty regarding building up threshold signatures via concatenation.The discussion further explores the topic of threshold signatures in the context of Bitcoin. The paper suggests using M-of-N signatures to validate one of the permutations of M that signed. It acknowledges that Musig, which is M-of-M, is prone to loss if a key is lost or a participant aborts during signing. However, it is possible to create M-of-N threshold MuSig signatures for any M and N, as demonstrated in an implementation shared on GitHub. Erik Aronesty raises concerns about Bitcoin releasing a multisig scheme that encourages loss, but it is clarified that there is currently no proposal for a non-redistributable multisig solution.Erik Aronesty discusses the security advantages of a redistributable threshold system and raises concerns about an M-1 rogue-key attack. Gregory Maxwell responds by explaining the possibility of constructing a 2-of-2 signature by adding keys and carrying out an attack using interpolation. The Musig paper describes a delinearization technique to prevent such attacks, but Erik Aronesty has not tested whether the R,s version is susceptible to these attacks.The author of a Medium article responds to feedback from Gregory Maxwell and clarifies that they switched to the Medium platform to edit and improve their work. They mention that no research has been done on the R,s version and explain that an M-1 rogue-key attack would require attacking either the hash function or the Discrete Logarithm Problem (DLP), neither of which gives an advantage to someone with M-1 keys. However, Gregory Maxwell suggests that the author may be ignoring unfavorable feedback.In another instance, Erik Aronesty reposts a broken scheme on Bitcointalk, but there is no response to the original post. This scheme raises concerns about security and functionality. In contrast, Musig is presented as a secure and functional multisig solution. Pieter Wuille suggests implementing a CAS (Compare and Swap) mechanism for precise communication in both directions.The discussion revolves around an M-of-N Bitcoin multisig scheme, with some questioning why there is so much debate around it. Others point out flaws in the scheme and express confusion caused by the person promoting it.In an email exchange, Erik Aronesty asks why his M-of-N Bitcoin multisig scheme is referred to as FUD (Fear, Uncertainty, and Doubt). Andrew Poelstra explains that Aronesty's scheme doesn't work, despite being repeatedly told so, and that Aronesty continues to post incomplete and incoherent versions of it. Poelstra states that Aronesty's scheme is broken.The FUD surrounding a specific Bitcoin multisig scheme is deemed unnecessary. The M-of-N shared public key is generated in advance, and signature fragments can be generated offline without communication between participants. Andrew Poelstra clarifies that there are no non-interactive Schnorr signatures.In the same email exchange, Erik Aronesty notes that his spec cannot be used directly with a Shamir scheme for single-round threshold multisigs. Andrew Poelstra clarifies that (R,s) schemes can still be used online if participants publish the R(share).In various discussions and exchanges, questions are raised regarding the implementation and encoding of public and private keys in the proposed Schnorr signature scheme. Various suggestions and clarifications are provided to address these concerns.There is also a discussion about the optimal order of inputs for hashing in ECDSA signatures, with arguments for both nonce-first and message-first approaches. The debate touches on security benefits, standard hash function design, and optimization techniques.Overall, the context encompasses proposals, discussions, clarifications, and concerns related to implementing 64-byte elliptic curve Schnorr signatures in Bitcoin, including threshold signatures and multisig schemes. 2018-09-20T21:12:42+00:00 + Pieter Wuille's proposal for a BIP (Bitcoin Improvement Proposal) aims to introduce 64-byte elliptic curve Schnorr signatures into the Bitcoin development community. This draft specification is an important step towards standardizing the signature scheme, although it does not directly address consensus rules or aggregation. Wuille plans to collaborate with others to create production-ready reference implementations and conduct tests using the proposed scheme. It is also noted that this signature scheme may have applications beyond the scope of Bitcoin.In the discussion surrounding the proposal, Andrew Poelstra clarifies that M-of-N threshold MuSig signatures can be created for any values of M and N. By combining Schnorr signatures with Pedersen Secret Sharing, a secure interactive threshold signature scheme can be achieved, ensuring that signatures can only be produced by predetermined sets of signers. Poelstra also mentions that he has implemented the combination of MuSig and VSS (Verifiable Secret Sharing) in his code. However, there are unanswered questions raised by Erik Aronesty regarding building up threshold signatures via concatenation.The discussion further explores the topic of threshold signatures in the context of Bitcoin. The paper suggests using M-of-N signatures to validate one of the permutations of M that signed. It acknowledges that Musig, which is M-of-M, is prone to loss if a key is lost or a participant aborts during signing. However, it is possible to create M-of-N threshold MuSig signatures for any M and N, as demonstrated in an implementation shared on GitHub. Erik Aronesty raises concerns about Bitcoin releasing a multisig scheme that encourages loss, but it is clarified that there is currently no proposal for a non-redistributable multisig solution.Erik Aronesty discusses the security advantages of a redistributable threshold system and raises concerns about an M-1 rogue-key attack. Gregory Maxwell responds by explaining the possibility of constructing a 2-of-2 signature by adding keys and carrying out an attack using interpolation. The Musig paper describes a delinearization technique to prevent such attacks, but Erik Aronesty has not tested whether the R,s version is susceptible to these attacks.The author of a Medium article responds to feedback from Gregory Maxwell and clarifies that they switched to the Medium platform to edit and improve their work. They mention that no research has been done on the R,s version and explain that an M-1 rogue-key attack would require attacking either the hash function or the Discrete Logarithm Problem (DLP), neither of which gives an advantage to someone with M-1 keys. However, Gregory Maxwell suggests that the author may be ignoring unfavorable feedback.In another instance, Erik Aronesty reposts a broken scheme on Bitcointalk, but there is no response to the original post. This scheme raises concerns about security and functionality. In contrast, Musig is presented as a secure and functional multisig solution. Pieter Wuille suggests implementing a CAS (Compare and Swap) mechanism for precise communication in both directions.The discussion revolves around an M-of-N Bitcoin multisig scheme, with some questioning why there is so much debate around it. Others point out flaws in the scheme and express confusion caused by the person promoting it.In an email exchange, Erik Aronesty asks why his M-of-N Bitcoin multisig scheme is referred to as FUD (Fear, Uncertainty, and Doubt). Andrew Poelstra explains that Aronesty's scheme doesn't work, despite being repeatedly told so, and that Aronesty continues to post incomplete and incoherent versions of it. Poelstra states that Aronesty's scheme is broken.The FUD surrounding a specific Bitcoin multisig scheme is deemed unnecessary. The M-of-N shared public key is generated in advance, and signature fragments can be generated offline without communication between participants. Andrew Poelstra clarifies that there are no non-interactive Schnorr signatures.In the same email exchange, Erik Aronesty notes that his spec cannot be used directly with a Shamir scheme for single-round threshold multisigs. Andrew Poelstra clarifies that (R,s) schemes can still be used online if participants publish the R(share).In various discussions and exchanges, questions are raised regarding the implementation and encoding of public and private keys in the proposed Schnorr signature scheme. Various suggestions and clarifications are provided to address these concerns.There is also a discussion about the optimal order of inputs for hashing in ECDSA signatures, with arguments for both nonce-first and message-first approaches. The debate touches on security benefits, standard hash function design, and optimization techniques.Overall, the context encompasses proposals, discussions, clarifications, and concerns related to implementing 64-byte elliptic curve Schnorr signatures in Bitcoin, including threshold signatures and multisig schemes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Selfish-Mining-Prevention.xml b/static/bitcoin-dev/Sept_2018/combined_Selfish-Mining-Prevention.xml index 0ab1eaa4c0..50a704cd9e 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Selfish-Mining-Prevention.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Selfish-Mining-Prevention.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Selfish Mining Prevention - 2023-08-01T23:52:07.453237+00:00 + 2025-09-26T15:56:20.135707+00:00 + python-feedgen Andrew 2018-09-18 20:26:16+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Selfish Mining Prevention - 2023-08-01T23:52:07.453237+00:00 + 2025-09-26T15:56:20.135890+00:00 - The conversation on the Bitcoin-dev mailing list focused on the 51% problem and potential solutions. Zawy expressed concerns about Andrew's proposal, suggesting that using an average of 144 past blocks to determine a certain parameter could help reduce mining fluctuations. He also mentioned the possibility of issuing too many or too few coins depending on the long-term rise of this parameter. Zawy proposed increasing difficulty instead of reward as an alternative solution, but Eric disagreed, stating that SHA256 is ASIC-friendly, making it difficult for prime number computations to switch quickly to Bitcoin mining.Zawy clarified that his post was addressing not only selfish mining and 51% attacks but also other types of attacks that aim to drive away mining competition. He suggested giving users more control over how their fees are spent by allocating a portion of fees to miners based on hashrate conditions and returning the remaining part to users for future fee payments.Eric mentioned that merge mining could help smooth out hashrate fluctuations, but even without merge mining, there might not necessarily be a destructive feedback loop. The share of a miner's hash power is determined by capital investment rather than the newness of the investment. Higher efficiency mining does not reduce energy consumption, and proof-of-memory (space) shifts energy costs to hardware manufacture and shipment.Users have the ability to set a target hashrate for Bitcoin mining, and as long as the hashrate is rising, miners will gradually receive reserve fees. If the hashrate remains stable or decreases, users get the reserve fees back. However, there is a limit on the hashrate for each level of mining rewards based on demand. Once the hashrate becomes sufficiently large, new miners may not join due to their small share of the hashrate.Merge mining and proof of space are seen as potentially efficient methods in the future, although educating people to use fewer resources falls outside the scope of the Bitcoin software protocol.The 51% problem is a significant concern in the world of cryptocurrency. It amplifies oscillations and motivates miners to exacerbate the problem until a limit is reached. Solutions to this problem include selfish mining prevention and pollution, but these are not actively discussed in the Bitcoin community. Another solution is to increase difficulty instead of reward, which would have a similar effect from a miner's perspective. Andrew proposed a solution involving "reserve fees" that would be paid to miners if the hashrate rises, aiming to prevent selfish mining and other attacks.Damian Williamson expressed concerns about incentivizing increased global resource consumption and its potential harm to the environment. However, Andrew argued that centralization of energy does more harm than total energy consumption and suggested that Bitcoin could help decentralize power and potentially reduce global energy usage.Andrew's proposal for selfish mining prevention involves adding "reserve fees" to transactions. Users can specify a fraction of the fee to be held in reserve for a certain period. If the hashrate rises, the reserve fees will be paid to miners, incentivizing them to maintain a stable hashrate and avoid driving out competition. Damian emphasized the importance of stifling greed and making mining more decentralized and competitive. He suggested approaches unrelated to Andrew's proposal that focus on addressing greed. While Andrew agreed that preventing greed should be a priority, he believes his proposal can work well alongside a dynamic difficulty adjustment algorithm.Andrew proposed adding "reserve fees" to Bitcoin mining as a solution to prevent selfish mining attacks and collusion. These reserve fees would be a fraction of the total fee held in reserve for a specific period. If the hashrate increases, the reserve fees would be paid to miners, encouraging them to maintain a stable hashrate and avoid driving out competition. This proposal requires a soft fork and is voluntary for users. The validation resource requirements for this change are small, and it would be especially important as fees become more significant in the future.Andrew's proposal for selfish mining prevention involves adding "reserve fees" to transactions. The reserve fees would be a fraction of the total fee that is held in reserve for a specific period. If the hashrate rises, the reserve fees will be paid to miners, incentivizing them to maintain a stable hashrate and avoid driving out competition. This proposal is voluntary and requires a soft fork. While there are concerns about increased global resource consumption, Andrew argues that centralization of energy does more harm than total energy consumption and that Bitcoin could help decentralize power and potentially decrease global energy usage.Damian Williamson expressed concerns about the proposed solution incentivizing increased global resource consumption and its potential harm to the environment. He emphasized the need to stifle greed and make mining more decentralized and competitive. Damian suggested focusing on approaches unrelated to Andrew's proposal that address greed. Although Andrew agreed with the importance of preventing greed, he believes his proposal can work well alongside a dynamic difficulty adjustment algorithm.Another developer, Eric, suggested an alternative solution called Helper Blocks, which assigns one satoshi from the unspent transaction output set with the ability 2018-09-18T20:26:16+00:00 + The conversation on the Bitcoin-dev mailing list focused on the 51% problem and potential solutions. Zawy expressed concerns about Andrew's proposal, suggesting that using an average of 144 past blocks to determine a certain parameter could help reduce mining fluctuations. He also mentioned the possibility of issuing too many or too few coins depending on the long-term rise of this parameter. Zawy proposed increasing difficulty instead of reward as an alternative solution, but Eric disagreed, stating that SHA256 is ASIC-friendly, making it difficult for prime number computations to switch quickly to Bitcoin mining.Zawy clarified that his post was addressing not only selfish mining and 51% attacks but also other types of attacks that aim to drive away mining competition. He suggested giving users more control over how their fees are spent by allocating a portion of fees to miners based on hashrate conditions and returning the remaining part to users for future fee payments.Eric mentioned that merge mining could help smooth out hashrate fluctuations, but even without merge mining, there might not necessarily be a destructive feedback loop. The share of a miner's hash power is determined by capital investment rather than the newness of the investment. Higher efficiency mining does not reduce energy consumption, and proof-of-memory (space) shifts energy costs to hardware manufacture and shipment.Users have the ability to set a target hashrate for Bitcoin mining, and as long as the hashrate is rising, miners will gradually receive reserve fees. If the hashrate remains stable or decreases, users get the reserve fees back. However, there is a limit on the hashrate for each level of mining rewards based on demand. Once the hashrate becomes sufficiently large, new miners may not join due to their small share of the hashrate.Merge mining and proof of space are seen as potentially efficient methods in the future, although educating people to use fewer resources falls outside the scope of the Bitcoin software protocol.The 51% problem is a significant concern in the world of cryptocurrency. It amplifies oscillations and motivates miners to exacerbate the problem until a limit is reached. Solutions to this problem include selfish mining prevention and pollution, but these are not actively discussed in the Bitcoin community. Another solution is to increase difficulty instead of reward, which would have a similar effect from a miner's perspective. Andrew proposed a solution involving "reserve fees" that would be paid to miners if the hashrate rises, aiming to prevent selfish mining and other attacks.Damian Williamson expressed concerns about incentivizing increased global resource consumption and its potential harm to the environment. However, Andrew argued that centralization of energy does more harm than total energy consumption and suggested that Bitcoin could help decentralize power and potentially reduce global energy usage.Andrew's proposal for selfish mining prevention involves adding "reserve fees" to transactions. Users can specify a fraction of the fee to be held in reserve for a certain period. If the hashrate rises, the reserve fees will be paid to miners, incentivizing them to maintain a stable hashrate and avoid driving out competition. Damian emphasized the importance of stifling greed and making mining more decentralized and competitive. He suggested approaches unrelated to Andrew's proposal that focus on addressing greed. While Andrew agreed that preventing greed should be a priority, he believes his proposal can work well alongside a dynamic difficulty adjustment algorithm.Andrew proposed adding "reserve fees" to Bitcoin mining as a solution to prevent selfish mining attacks and collusion. These reserve fees would be a fraction of the total fee held in reserve for a specific period. If the hashrate increases, the reserve fees would be paid to miners, encouraging them to maintain a stable hashrate and avoid driving out competition. This proposal requires a soft fork and is voluntary for users. The validation resource requirements for this change are small, and it would be especially important as fees become more significant in the future.Andrew's proposal for selfish mining prevention involves adding "reserve fees" to transactions. The reserve fees would be a fraction of the total fee that is held in reserve for a specific period. If the hashrate rises, the reserve fees will be paid to miners, incentivizing them to maintain a stable hashrate and avoid driving out competition. This proposal is voluntary and requires a soft fork. While there are concerns about increased global resource consumption, Andrew argues that centralization of energy does more harm than total energy consumption and that Bitcoin could help decentralize power and potentially decrease global energy usage.Damian Williamson expressed concerns about the proposed solution incentivizing increased global resource consumption and its potential harm to the environment. He emphasized the need to stifle greed and make mining more decentralized and competitive. Damian suggested focusing on approaches unrelated to Andrew's proposal that address greed. Although Andrew agreed with the importance of preventing greed, he believes his proposal can work well alongside a dynamic difficulty adjustment algorithm.Another developer, Eric, suggested an alternative solution called Helper Blocks, which assigns one satoshi from the unspent transaction output set with the ability - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Suggestion-for-a-universal-bitcoin-value-scale.xml b/static/bitcoin-dev/Sept_2018/combined_Suggestion-for-a-universal-bitcoin-value-scale.xml index 9f7f1fcb34..63fd6c4e15 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Suggestion-for-a-universal-bitcoin-value-scale.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Suggestion-for-a-universal-bitcoin-value-scale.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Suggestion for a universal bitcoin value scale - 2023-08-01T23:43:45.667818+00:00 - - Clark Moody 2018-09-12 14:54:15+00:00 - - - damgaard.martin at gmail.com 2018-09-12 06:32:10+00:00 - - - Karl-Johan Alm 2018-09-12 06:13:56+00:00 - - - rhavar at protonmail.com 2018-08-20 23:36:14+00:00 - - - damgaard.martin at gmail.com 2018-08-19 14:21:55+00:00 - - - Rodolfo Novak 2018-08-19 11:42:13+00:00 - - - damgaard.martin at gmail.com 2018-08-18 20:10:04+00:00 - + 2025-09-26T15:56:11.579709+00:00 + python-feedgen + + + [bitcoin-dev] Suggestion for a universal bitcoin value scale damgaard.martin + 2018-08-18T20:10:00.000Z + + + Rodolfo Novak + 2018-08-19T11:42:00.000Z + + + damgaard.martin + 2018-08-19T14:21:00.000Z + + + rhavar + 2018-08-20T23:36:00.000Z + + + Karl-Johan Alm + 2018-09-12T06:13:00.000Z + + + damgaard.martin + 2018-09-12T06:32:00.000Z + + + Clark Moody + 2018-09-12T14:54:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Suggestion for a universal bitcoin value scale - 2023-08-01T23:43:45.667818+00:00 + 2025-09-26T15:56:11.580689+00:00 - In a bitcoin-dev mailing list thread, Clark shares his opinion on the use of Bitcoin on the street. He emphasizes the importance of observing how local wallet software displays bitcoin amounts and suggests letting the standards write themselves over time. Clark acknowledges that the units debate has been ongoing for as long as he has known about Bitcoin, but most tools currently display standard bitcoin amounts.In response to an earlier suggestion for a universal bitcoin value color scale, Karl-Johan Alm raises concerns about the potential for it to be a new attack vector. Martin Damgaard, the author of the initial suggestion, later retracts it due to this feedback and other good remarks. The email thread provides formats for the attached document, including .rtf, .pdf, and .docx.Martin Damgaard, unfamiliar with normal BIP procedures, proposes a universal bitcoin value color scale in an email thread on the Bitcoin Protocol Discussion. His suggestion aims to address the decimal problem identified by the BIP 176 proposal. However, Karl-Johan Alm points out that such a system could be a potential attack vector, as something could be colored to appear as more than it really is if everyone started using this system. After receiving feedback and realizing the immature nature of his suggestion, Damgaard retracts his initial proposal. He thanks the group and expresses all the best wishes. The email thread includes the attached document in three different formats.The email discusses a proposal for a universal bitcoin value color scale to address the issue of dealing with small amounts in the bitcoin denomination. While the idea may be helpful, the author believes that it is not a good solution, as many services or wallets are unlikely to adopt it due to its potential impact on design and cumbersome typing. Instead, the author suggests using BIP76 (Bits Denomination), which has been successful with people of varying levels of familiarity. Additionally, the author proposes writing the bitcoin denomination to 8 decimal places (e.g., 0.00001100 BTC) for improved readability. The email includes an attachment containing the proposal in three different formats.Martin Damgaard, unfamiliar with BIP procedures, contributes to the Bitcoin community by suggesting a universal bitcoin value color scale to address the decimal problem identified by Jimmy Song's BIP 176 proposal. Adán Sánchez de Pedro Crespo suggests that Martin submit his work as a markdown document published somewhere with version control, such as GitHub, to facilitate contributions from others. Martin creates a GitHub version of his suggestion and collects comments on the first version in a remarks-file. He plans to create a new version incorporating the different comments and welcomes help from interested contributors.The context discusses the use of colors in user experience (UX) design and their expected meanings, such as red indicating an error and green indicating a possible action. However, the use of colors can also create issues with legibility for text and accessibility for colorblind individuals. In an email to the bitcoin-dev mailing list, Martin Damgaard suggests a universal bitcoin value color scale to address the decimal problem identified in BIP 176. He acknowledges his unfamiliarity with BIP procedures but follows the example set by Jimmy Song in creating a similar proposal. The attached document is provided in three different formats.Martin Damgaard makes a suggestion to the bitcoin-dev mailing list, proposing a universal bitcoin value color scale to address the decimal problem identified in BIP 176 by Jimmy Song. While he admits his unfamiliarity with normal BIP procedures, he provides his suggestion in three different formats (rtf, pdf, and docx) for the convenience of the recipients. The attached files are available for review, and Martin hopes that the bitcoin-dev community will find his contribution useful. 2018-09-12T14:54:15+00:00 + In a bitcoin-dev mailing list thread, Clark shares his opinion on the use of Bitcoin on the street. He emphasizes the importance of observing how local wallet software displays bitcoin amounts and suggests letting the standards write themselves over time. Clark acknowledges that the units debate has been ongoing for as long as he has known about Bitcoin, but most tools currently display standard bitcoin amounts.In response to an earlier suggestion for a universal bitcoin value color scale, Karl-Johan Alm raises concerns about the potential for it to be a new attack vector. Martin Damgaard, the author of the initial suggestion, later retracts it due to this feedback and other good remarks. The email thread provides formats for the attached document, including .rtf, .pdf, and .docx.Martin Damgaard, unfamiliar with normal BIP procedures, proposes a universal bitcoin value color scale in an email thread on the Bitcoin Protocol Discussion. His suggestion aims to address the decimal problem identified by the BIP 176 proposal. However, Karl-Johan Alm points out that such a system could be a potential attack vector, as something could be colored to appear as more than it really is if everyone started using this system. After receiving feedback and realizing the immature nature of his suggestion, Damgaard retracts his initial proposal. He thanks the group and expresses all the best wishes. The email thread includes the attached document in three different formats.The email discusses a proposal for a universal bitcoin value color scale to address the issue of dealing with small amounts in the bitcoin denomination. While the idea may be helpful, the author believes that it is not a good solution, as many services or wallets are unlikely to adopt it due to its potential impact on design and cumbersome typing. Instead, the author suggests using BIP76 (Bits Denomination), which has been successful with people of varying levels of familiarity. Additionally, the author proposes writing the bitcoin denomination to 8 decimal places (e.g., 0.00001100 BTC) for improved readability. The email includes an attachment containing the proposal in three different formats.Martin Damgaard, unfamiliar with BIP procedures, contributes to the Bitcoin community by suggesting a universal bitcoin value color scale to address the decimal problem identified by Jimmy Song's BIP 176 proposal. Adán Sánchez de Pedro Crespo suggests that Martin submit his work as a markdown document published somewhere with version control, such as GitHub, to facilitate contributions from others. Martin creates a GitHub version of his suggestion and collects comments on the first version in a remarks-file. He plans to create a new version incorporating the different comments and welcomes help from interested contributors.The context discusses the use of colors in user experience (UX) design and their expected meanings, such as red indicating an error and green indicating a possible action. However, the use of colors can also create issues with legibility for text and accessibility for colorblind individuals. In an email to the bitcoin-dev mailing list, Martin Damgaard suggests a universal bitcoin value color scale to address the decimal problem identified in BIP 176. He acknowledges his unfamiliarity with BIP procedures but follows the example set by Jimmy Song in creating a similar proposal. The attached document is provided in three different formats.Martin Damgaard makes a suggestion to the bitcoin-dev mailing list, proposing a universal bitcoin value color scale to address the decimal problem identified in BIP 176 by Jimmy Song. While he admits his unfamiliarity with normal BIP procedures, he provides his suggestion in three different formats (rtf, pdf, and docx) for the convenience of the recipients. The attached files are available for review, and Martin hopes that the bitcoin-dev community will find his contribution useful. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_Testnet3-Reest.xml b/static/bitcoin-dev/Sept_2018/combined_Testnet3-Reest.xml index 13ccc04f30..f4ae8e18f2 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Testnet3-Reest.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Testnet3-Reest.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Testnet3 Reest - 2023-08-01T23:45:31.105467+00:00 - - Karl-Johan Alm 2018-09-05 03:00:39+00:00 - - - rhavar at protonmail.com 2018-09-01 14:47:53+00:00 - - - Gregory Maxwell 2018-08-31 00:06:06+00:00 - - - Johnson Lau 2018-08-30 20:44:25+00:00 - - - Jimmy Song 2018-08-30 20:36:16+00:00 - - - Peter Todd 2018-08-30 20:02:39+00:00 - - - shiva sitamraju 2018-08-30 07:28:42+00:00 - + 2025-09-26T15:56:03.070830+00:00 + python-feedgen + + + [bitcoin-dev] Testnet3 Reest shiva sitamraju + 2018-08-30T07:28:00.000Z + + + Peter Todd + 2018-08-30T20:02:00.000Z + + + Jimmy Song + 2018-08-30T20:36:00.000Z + + + Johnson Lau + 2018-08-30T20:44:00.000Z + + + Gregory Maxwell + 2018-08-31T00:06:00.000Z + + + rhavar + 2018-09-01T14:47:00.000Z + + + Karl-Johan Alm + 2018-09-05T03:00:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Testnet3 Reest - 2023-08-01T23:45:31.105467+00:00 + 2025-09-26T15:56:03.071795+00:00 - Gregory Maxwell, a developer at Bitcoin core, has been working on increasing the size of blockindex objects in memory to accommodate signed testnet mode. However, this approach did not prove successful as it increased the size of objects even when not in signed testnet mode. An alternative solution proposed by jtimon involves turning one of the fields, such as the merkel root, into a union with a pointer to a look-aside block index used only in signed block testnet mode. A new implementation is currently being worked on, which includes a global mapping of block hash to signature that is (de)serialized in the block header. The code for this implementation can be found on GitHub.Ryan, a contributor to the bitcoin-dev mailing list, suggested implementing small blocks on testnet to simulate a fee-market-like situation. However, there are concerns about how long the current situation of testnet spam and full blocks will last. Gregory Maxwell proposed creating a signed blocks testnet with a structured reorg pattern as an alternative to the current testnet. This would serve as a middle ground between regtest and a full testnet, providing useful testing opportunities without being subject to the network's whims. Concerns were raised about the increased memory usage due to the larger size of blockindex objects, but this could potentially be addressed by turning one of the fields into a union with a pointer to a look-aside block index.The idea of a signed blocks testnet with a predictable structured reorg pattern was proposed as an alternative to having two testnets with different block sizes. The current testnet is considered too stable when some instability is desired, and too unstable when stability is needed. A signed blocks testnet would provide a middle ground between regtest and a full testnet, allowing for more controlled testing opportunities. Although patches were previously developed for such a testnet in Bitcoin core, concerns about increased memory usage have been raised. However, turning one of the fields into a union with a pointer to a look-aside block index used only in signed block testnet mode could potentially address this issue.On the bitcoin-dev mailing list, a user named shiva sitamraju asked about a potential reset for testnet in the next release due to its length and long sync time. Peter Todd disagreed with this suggestion and advocated for testnet to be a larger blockchain than mainnet to identify size-related issues first. He also suggested using regtest as an alternative for testing, as private regtest blockchains offer better control over block creation. There was a proposal for having two testnets simultaneously, with one having a smaller block size for faster testing. However, Peter Todd favored the idea of a larger testnet. While a public testnet remains useful for referencing transactions in articles, there are various alternatives available for testing purposes, including regtest and private blockchains.In response to a user's question about the lack of multiple testnets, Peter Todd suggested having a larger blockchain for testing instead of resetting the current testnet. He also recommended using regtest as an alternative, as it allows for easy setup and control over block creation. The user mentioned that the current testnet is over 1.4 million blocks long and takes at least 48 hours to fully sync.In an email to the Bitcoin development mailing list, a user raised concerns about the increasing length of the Testnet, which now stands at 1,411,795 blocks, and the significant time required for a full sync. They inquired about the possibility of a reset in the next release or any reasons not to do so. Another member of the mailing list argued in favor of keeping Testnet as a larger blockchain than mainnet to identify size-related issues early on. They also suggested using regtest as a more suitable alternative for testing, as it offers easy setup and better control over block creation. The email was signed by Shiva S, the CEO of Blockonomics, a company specializing in decentralized and permissionless payments.The sender of the message is seeking information regarding the potential for a testnet reset in the next release or any reasons against it. They highlight that the current testnet's length and sync time are causing delays and increased disk overheads for testing purposes. The email is signed by Shiva S, the CEO of Blockonomics, and includes links to their Telegram group and Welcome Guide for further engagement. 2018-09-05T03:00:39+00:00 + Gregory Maxwell, a developer at Bitcoin core, has been working on increasing the size of blockindex objects in memory to accommodate signed testnet mode. However, this approach did not prove successful as it increased the size of objects even when not in signed testnet mode. An alternative solution proposed by jtimon involves turning one of the fields, such as the merkel root, into a union with a pointer to a look-aside block index used only in signed block testnet mode. A new implementation is currently being worked on, which includes a global mapping of block hash to signature that is (de)serialized in the block header. The code for this implementation can be found on GitHub.Ryan, a contributor to the bitcoin-dev mailing list, suggested implementing small blocks on testnet to simulate a fee-market-like situation. However, there are concerns about how long the current situation of testnet spam and full blocks will last. Gregory Maxwell proposed creating a signed blocks testnet with a structured reorg pattern as an alternative to the current testnet. This would serve as a middle ground between regtest and a full testnet, providing useful testing opportunities without being subject to the network's whims. Concerns were raised about the increased memory usage due to the larger size of blockindex objects, but this could potentially be addressed by turning one of the fields into a union with a pointer to a look-aside block index.The idea of a signed blocks testnet with a predictable structured reorg pattern was proposed as an alternative to having two testnets with different block sizes. The current testnet is considered too stable when some instability is desired, and too unstable when stability is needed. A signed blocks testnet would provide a middle ground between regtest and a full testnet, allowing for more controlled testing opportunities. Although patches were previously developed for such a testnet in Bitcoin core, concerns about increased memory usage have been raised. However, turning one of the fields into a union with a pointer to a look-aside block index used only in signed block testnet mode could potentially address this issue.On the bitcoin-dev mailing list, a user named shiva sitamraju asked about a potential reset for testnet in the next release due to its length and long sync time. Peter Todd disagreed with this suggestion and advocated for testnet to be a larger blockchain than mainnet to identify size-related issues first. He also suggested using regtest as an alternative for testing, as private regtest blockchains offer better control over block creation. There was a proposal for having two testnets simultaneously, with one having a smaller block size for faster testing. However, Peter Todd favored the idea of a larger testnet. While a public testnet remains useful for referencing transactions in articles, there are various alternatives available for testing purposes, including regtest and private blockchains.In response to a user's question about the lack of multiple testnets, Peter Todd suggested having a larger blockchain for testing instead of resetting the current testnet. He also recommended using regtest as an alternative, as it allows for easy setup and control over block creation. The user mentioned that the current testnet is over 1.4 million blocks long and takes at least 48 hours to fully sync.In an email to the Bitcoin development mailing list, a user raised concerns about the increasing length of the Testnet, which now stands at 1,411,795 blocks, and the significant time required for a full sync. They inquired about the possibility of a reset in the next release or any reasons not to do so. Another member of the mailing list argued in favor of keeping Testnet as a larger blockchain than mainnet to identify size-related issues early on. They also suggested using regtest as a more suitable alternative for testing, as it offers easy setup and better control over block creation. The email was signed by Shiva S, the CEO of Blockonomics, a company specializing in decentralized and permissionless payments.The sender of the message is seeking information regarding the potential for a testnet reset in the next release or any reasons against it. They highlight that the current testnet's length and sync time are causing delays and increased disk overheads for testing purposes. The email is signed by Shiva S, the CEO of Blockonomics, and includes links to their Telegram group and Welcome Guide for further engagement. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_URI-scheme-with-optional-bech32-address.xml b/static/bitcoin-dev/Sept_2018/combined_URI-scheme-with-optional-bech32-address.xml index 0d1addea30..50c8b62c27 100644 --- a/static/bitcoin-dev/Sept_2018/combined_URI-scheme-with-optional-bech32-address.xml +++ b/static/bitcoin-dev/Sept_2018/combined_URI-scheme-with-optional-bech32-address.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - URI scheme with optional bech32 address - 2023-08-01T23:40:49.773167+00:00 + 2025-09-26T15:55:46.016991+00:00 + python-feedgen shiva sitamraju 2018-09-25 06:59:48+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - URI scheme with optional bech32 address - 2023-08-01T23:40:49.773167+00:00 + 2025-09-26T15:55:46.017144+00:00 - A proposal has been shared on Reddit regarding the adoption of bech32 QR codes in the Bitcoin network. While QR code adoption is considered important, bech32 QR codes are not backward compatible, leading many merchants and exchanges to opt for P2SH address QR codes instead. The proposed solution suggests using a URI format that includes both bech32 and P2SH address options. This would allow wallets to autopay using the lower transaction fee associated with bech32 addresses.The rationale behind this proposal is to increase the usage of bech32, which would create a network effect and potentially lead to widespread adoption of bech32 QR codes. To implement this solution, a team of developers is working on a walleting application capable of generating bech32 and P2WPKH-nested-in-P2SH addresses.One challenge faced by the team is that the payee cannot know in advance the technological capabilities of the payer. To address this, the proposal suggests encoding both bech32 and P2SH addresses in a Bitcoin URI. Legacy wallets would only see the P2SH address, while new wallets would be able to see and use the bech32 address for transactions.To maintain compatibility with BIP21, the 'path' field of the URI can be used for the P2WPKH-nested-in-P2SH address, while a new field (e.g., 'bech32') can be introduced for the bech32 address. It is assumed that wallets utilizing this scheme would monitor incoming transactions on both addresses. The order of attributes in the URI should not matter, as clients would check all attributes with the same name. However, it remains unclear if there are any precedents for the multiple use of an attribute in URI schemes.The team acknowledges that their proposal may not be entirely novel and asks if anyone has already proposed something similar. They also seek feedback on any major drawbacks to their proposal. 2018-09-25T06:59:48+00:00 + A proposal has been shared on Reddit regarding the adoption of bech32 QR codes in the Bitcoin network. While QR code adoption is considered important, bech32 QR codes are not backward compatible, leading many merchants and exchanges to opt for P2SH address QR codes instead. The proposed solution suggests using a URI format that includes both bech32 and P2SH address options. This would allow wallets to autopay using the lower transaction fee associated with bech32 addresses.The rationale behind this proposal is to increase the usage of bech32, which would create a network effect and potentially lead to widespread adoption of bech32 QR codes. To implement this solution, a team of developers is working on a walleting application capable of generating bech32 and P2WPKH-nested-in-P2SH addresses.One challenge faced by the team is that the payee cannot know in advance the technological capabilities of the payer. To address this, the proposal suggests encoding both bech32 and P2SH addresses in a Bitcoin URI. Legacy wallets would only see the P2SH address, while new wallets would be able to see and use the bech32 address for transactions.To maintain compatibility with BIP21, the 'path' field of the URI can be used for the P2WPKH-nested-in-P2SH address, while a new field (e.g., 'bech32') can be introduced for the bech32 address. It is assumed that wallets utilizing this scheme would monitor incoming transactions on both addresses. The order of attributes in the URI should not matter, as clients would check all attributes with the same name. However, it remains unclear if there are any precedents for the multiple use of an attribute in URI schemes.The team acknowledges that their proposal may not be entirely novel and asks if anyone has already proposed something similar. They also seek feedback on any major drawbacks to their proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2018/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml b/static/bitcoin-dev/Sept_2018/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml index c9829603dd..3123d2ff08 100644 --- a/static/bitcoin-dev/Sept_2018/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml +++ b/static/bitcoin-dev/Sept_2018/combined_bustapay-BIP-a-practical-sender-receiver-coinjoin-protocol.xml @@ -1,53 +1,71 @@ - + 2 Combined summary - bustapay BIP :: a practical sender/receiver coinjoin protocol - 2023-08-01T23:47:19.394119+00:00 - - James MacWhyte 2019-01-30 20:58:03+00:00 - - - ZmnSCPxj 2019-01-30 08:34:46+00:00 - - - rhavar at protonmail.com 2019-01-30 02:46:47+00:00 - - - James MacWhyte 2019-01-30 02:06:30+00:00 - - - Adam Gibson 2019-01-28 13:19:09+00:00 - - - ZmnSCPxj 2019-01-28 04:14:41+00:00 - - - rhavar at protonmail.com 2019-01-27 22:11:47+00:00 - - - James MacWhyte 2019-01-27 19:42:03+00:00 - - - rhavar at protonmail.com 2019-01-27 19:24:11+00:00 - - - Adam Gibson 2019-01-27 12:20:54+00:00 - - - rhavar at protonmail.com 2019-01-27 07:36:59+00:00 - - - Adam Gibson 2019-01-25 14:47:34+00:00 - - - rhavar at protonmail.com 2018-09-10 15:49:29+00:00 - - - Sjors Provoost 2018-09-10 12:30:46+00:00 - - - rhavar at protonmail.com 2018-08-30 20:24:58+00:00 - + 2025-09-26T15:56:05.228696+00:00 + python-feedgen + + + [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol rhavar + 2018-08-30T20:24:00.000Z + + + Sjors Provoost + 2018-09-10T12:30:00.000Z + + + rhavar + 2018-09-10T15:49:00.000Z + + + Adam Gibson + 2019-01-25T14:47:00.000Z + + + rhavar + 2019-01-27T07:36:00.000Z + + + Adam Gibson + 2019-01-27T12:20:00.000Z + + + rhavar + 2019-01-27T19:24:00.000Z + + + James MacWhyte + 2019-01-27T19:42:00.000Z + + + rhavar + 2019-01-27T22:11:00.000Z + + + ZmnSCPxj + 2019-01-28T04:14:00.000Z + + + Adam Gibson + 2019-01-28T13:19:00.000Z + + + James MacWhyte + 2019-01-30T02:06:00.000Z + + + rhavar + 2019-01-30T02:46:00.000Z + + + ZmnSCPxj + 2019-01-30T08:34:00.000Z + + + James MacWhyte + 2019-01-30T20:58:00.000Z + + @@ -63,13 +81,13 @@ - python-feedgen + 2 Combined summary - bustapay BIP :: a practical sender/receiver coinjoin protocol - 2023-08-01T23:47:19.395084+00:00 + 2025-09-26T15:56:05.230519+00:00 - The conversation revolves around the potential attack on a transaction template and the weaknesses identified in the proposed protocol. The sender suggests that refusing to sign the final transaction can still propagate the template transaction, but the real attack would be if the sender double-spends it before propagation. The receiver acknowledges the weaknesses and agrees that there may not be a better solution. They also understand that implementers unable to integrate signing and UTXO validation are unlikely to implement this feature.Another discussion focuses on the issues faced by a "PayJoin-only" merchant who repeatedly uses a single UTXO. This could lead to an imbalance of funds violating UIH2. To avoid this, it is suggested to have a mix of PayJoin and non-PayJoin transactions. The concept of Bustapay is introduced, which allows for PayJoin transactions with a single UTXO. However, repeated use of the same UTXO can still suggest a naive approach. A heuristic is proposed to randomly flip coins for each UTXO owned to determine when to use PayJoin or not, although no formal analysis has been conducted.James MacWhyte expresses concerns about the complexity of the Bustapay spec and questions the effectiveness of the anti-spy feature. He suggests simplifying the protocol by dropping the signing requirement in the first step. However, he acknowledges the transaction malleability issues that may arise. MacWhyte concludes that the only viable way to use Bustapay with increased privacy would be to pay the first part of the invoice in lightning and then pay the rest with Bustapay, but admits that this approach has too many moving parts and implementation difficulties.ZmnSCPxj proposes solutions to address the UIH2 issue, suggesting standard coin selection algorithms and the inclusion of contributed inputs. AdamISZ raises concerns about mismatched input sizes and the concentration of funds in a single UTXO. Belcher suggests having a mix of PayJoin and non-PayJoin transactions to avoid violating UIH2.The conversation also discusses the steganographic hiding of transaction ownership and the adoption of the PayJoin protocol. Members debate the practicality and complexity of the protocol, as well as the need for versioning and inclusion of PSBT/BIP174. The importance of explicit transaction details like version and locktime is also debated.The implementation of Bustapay is discussed, including its integration into BtcPayServer and the need for a standardized format for moving UTXOs between wallets. Concerns are raised about wallets violating standards and the need for uniformity in Bitcoin transactions.Ryan Havar acknowledges mistakes in his recent BIP 0079 proposal and agrees with Adam Gibson's opinion on steganographic hiding of transaction inputs. He suggests better support for moving UTXOs between wallets through a standardized format. Adam emphasizes the need for consensus on protocols, versioning, and the inclusion of PSBT/BIP174. He suggests avoiding unnecessary inputs and making the payjoin transaction appear as an ordinary payment. Adam also highlights the value of being explicit about simple things like transaction version and locktime.In conclusion, the discussions revolve around the potential attacks, weaknesses, and proposed solutions in the Bustapay protocol. There are debates on issues such as the concentration of funds, UIH2, steganographic hiding, standardization, and protocol versioning. The importance of simplifying the process, ensuring privacy, and protecting both senders and receivers is emphasized.Ryan and Adam Gibson discussed the standardization of PayJoin as a transaction that breaks the assumption of common ownership of transaction inputs. They talked about various aspects such as protocol versioning, using PSBT/BIP174, version/locktime, and avoiding non-payment "Unnecessary Input Heuristic."The proposal, known as Bustapay, aims to address fungibility concerns and blockchain analysis by creating indistinguishable Bitcoin transactions. The sender creates a fully valid, signed "template transaction" and gives it to the receiver through an HTTP POST request. The receiver adds their own input and increases the output that pays themselves by the contributed input amount. The partial transaction is then sent back to the sender to sign and propagated on the Bitcoin network by the receiver.Implementing Bustapay payments requires receivers to be aware of implementation notes, including checking if the transaction is suitable for the mempool with testmempoolaccept in Bitcoin Core 0.17. Sending applications should validate the HTTP response to ensure no unexpected changes have been made to the transaction.A proposal has been suggested to standardize the Bustapay protocol, which allows for hiding transaction information and increasing privacy. Steganographic hiding is considered worth pursuing, as Joinmarket and Samourai have already begun implementing the protocol. The aim is to create a cross-wallet standard that can be included in projects like BTCPayServer. Generic comments on protocol versioning, naming conventions, and the need for x-wallet compatibility standards are discussed.The Bustapay payment system involves several steps 2019-01-30T20:58:03+00:00 + The conversation revolves around the potential attack on a transaction template and the weaknesses identified in the proposed protocol. The sender suggests that refusing to sign the final transaction can still propagate the template transaction, but the real attack would be if the sender double-spends it before propagation. The receiver acknowledges the weaknesses and agrees that there may not be a better solution. They also understand that implementers unable to integrate signing and UTXO validation are unlikely to implement this feature.Another discussion focuses on the issues faced by a "PayJoin-only" merchant who repeatedly uses a single UTXO. This could lead to an imbalance of funds violating UIH2. To avoid this, it is suggested to have a mix of PayJoin and non-PayJoin transactions. The concept of Bustapay is introduced, which allows for PayJoin transactions with a single UTXO. However, repeated use of the same UTXO can still suggest a naive approach. A heuristic is proposed to randomly flip coins for each UTXO owned to determine when to use PayJoin or not, although no formal analysis has been conducted.James MacWhyte expresses concerns about the complexity of the Bustapay spec and questions the effectiveness of the anti-spy feature. He suggests simplifying the protocol by dropping the signing requirement in the first step. However, he acknowledges the transaction malleability issues that may arise. MacWhyte concludes that the only viable way to use Bustapay with increased privacy would be to pay the first part of the invoice in lightning and then pay the rest with Bustapay, but admits that this approach has too many moving parts and implementation difficulties.ZmnSCPxj proposes solutions to address the UIH2 issue, suggesting standard coin selection algorithms and the inclusion of contributed inputs. AdamISZ raises concerns about mismatched input sizes and the concentration of funds in a single UTXO. Belcher suggests having a mix of PayJoin and non-PayJoin transactions to avoid violating UIH2.The conversation also discusses the steganographic hiding of transaction ownership and the adoption of the PayJoin protocol. Members debate the practicality and complexity of the protocol, as well as the need for versioning and inclusion of PSBT/BIP174. The importance of explicit transaction details like version and locktime is also debated.The implementation of Bustapay is discussed, including its integration into BtcPayServer and the need for a standardized format for moving UTXOs between wallets. Concerns are raised about wallets violating standards and the need for uniformity in Bitcoin transactions.Ryan Havar acknowledges mistakes in his recent BIP 0079 proposal and agrees with Adam Gibson's opinion on steganographic hiding of transaction inputs. He suggests better support for moving UTXOs between wallets through a standardized format. Adam emphasizes the need for consensus on protocols, versioning, and the inclusion of PSBT/BIP174. He suggests avoiding unnecessary inputs and making the payjoin transaction appear as an ordinary payment. Adam also highlights the value of being explicit about simple things like transaction version and locktime.In conclusion, the discussions revolve around the potential attacks, weaknesses, and proposed solutions in the Bustapay protocol. There are debates on issues such as the concentration of funds, UIH2, steganographic hiding, standardization, and protocol versioning. The importance of simplifying the process, ensuring privacy, and protecting both senders and receivers is emphasized.Ryan and Adam Gibson discussed the standardization of PayJoin as a transaction that breaks the assumption of common ownership of transaction inputs. They talked about various aspects such as protocol versioning, using PSBT/BIP174, version/locktime, and avoiding non-payment "Unnecessary Input Heuristic."The proposal, known as Bustapay, aims to address fungibility concerns and blockchain analysis by creating indistinguishable Bitcoin transactions. The sender creates a fully valid, signed "template transaction" and gives it to the receiver through an HTTP POST request. The receiver adds their own input and increases the output that pays themselves by the contributed input amount. The partial transaction is then sent back to the sender to sign and propagated on the Bitcoin network by the receiver.Implementing Bustapay payments requires receivers to be aware of implementation notes, including checking if the transaction is suitable for the mempool with testmempoolaccept in Bitcoin Core 0.17. Sending applications should validate the HTTP response to ensure no unexpected changes have been made to the transaction.A proposal has been suggested to standardize the Bustapay protocol, which allows for hiding transaction information and increasing privacy. Steganographic hiding is considered worth pursuing, as Joinmarket and Samourai have already begun implementing the protocol. The aim is to create a cross-wallet standard that can be included in projects like BTCPayServer. Generic comments on protocol versioning, naming conventions, and the need for x-wallet compatibility standards are discussed.The Bustapay payment system involves several steps - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_-BIP-able-idea-Regular-testnet-reset.xml b/static/bitcoin-dev/Sept_2019/combined_-BIP-able-idea-Regular-testnet-reset.xml index e05851570c..9cb3261027 100644 --- a/static/bitcoin-dev/Sept_2019/combined_-BIP-able-idea-Regular-testnet-reset.xml +++ b/static/bitcoin-dev/Sept_2019/combined_-BIP-able-idea-Regular-testnet-reset.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - [BIP-able idea] Regular testnet reset - 2023-08-02T01:20:33.392005+00:00 - - Bryan Bishop 2019-09-15 13:49:30+00:00 - - - Emil Engler 2019-09-13 23:57:12+00:00 - + 2025-09-26T15:39:00.928033+00:00 + python-feedgen + + + [bitcoin-dev] [BIP-able idea] Regular testnet reset Emil Engler + 2019-09-13T23:57:00.000Z + + + Bryan Bishop + 2019-09-15T13:49:00.000Z + + - python-feedgen + 2 Combined summary - [BIP-able idea] Regular testnet reset - 2023-08-02T01:20:33.393057+00:00 + 2025-09-26T15:39:00.928423+00:00 - In a recent discussion on the Bitcoin Developer mailing list, Emil Engler proposed the concept of regularly resetting the testnet. This idea had previously been brought up and feedback was provided back in June 2019. However, new information has now been shared regarding signet, an alternative to testnet. Emil Engler is considering writing a Bitcoin Improvement Proposal (BIP) about regularly resetting the testnet on a scheduled basis. The main premise behind this idea is to use every 210,000 blocks as the genesis of a completely new chain, essentially forgetting the old chain and ensuring that no chain can ever be longer than 210,000 blocks. However, there are several challenges associated with implementing this idea. One major concern is how to make it work with testnet3, which may require a hardfork. Another consideration is whether it would be feasible to change the chain while Bitcoin Core is running. Moreover, there may be valid concerns about potential planned attacks causing the chain to branch into multiple chains at each reset.Emil Engler is actively seeking feedback on this proposal, hoping to gather insights and perspectives from the community. The email provided links to previous discussions and additional material related to this topic, allowing recipients to delve deeper into the subject matter. 2019-09-15T13:49:30+00:00 + In a recent discussion on the Bitcoin Developer mailing list, Emil Engler proposed the concept of regularly resetting the testnet. This idea had previously been brought up and feedback was provided back in June 2019. However, new information has now been shared regarding signet, an alternative to testnet. Emil Engler is considering writing a Bitcoin Improvement Proposal (BIP) about regularly resetting the testnet on a scheduled basis. The main premise behind this idea is to use every 210,000 blocks as the genesis of a completely new chain, essentially forgetting the old chain and ensuring that no chain can ever be longer than 210,000 blocks. However, there are several challenges associated with implementing this idea. One major concern is how to make it work with testnet3, which may require a hardfork. Another consideration is whether it would be feasible to change the chain while Bitcoin Core is running. Moreover, there may be valid concerns about potential planned attacks causing the chain to branch into multiple chains at each reset.Emil Engler is actively seeking feedback on this proposal, hoping to gather insights and perspectives from the community. The email provided links to previous discussions and additional material related to this topic, allowing recipients to delve deeper into the subject matter. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_Block-Batch-Filters-for-Light-Clients.xml b/static/bitcoin-dev/Sept_2019/combined_Block-Batch-Filters-for-Light-Clients.xml index c8e17fc1a0..0a71bbe095 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Block-Batch-Filters-for-Light-Clients.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Block-Batch-Filters-for-Light-Clients.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block Batch Filters for Light Clients - 2023-08-02T01:21:33.512882+00:00 + 2025-09-26T15:38:56.744385+00:00 + python-feedgen Jonas Schnelli 2019-10-11 15:44:54+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Block Batch Filters for Light Clients - 2023-08-02T01:21:33.512882+00:00 + 2025-09-26T15:38:56.744547+00:00 - The conversation discusses the limitations of BIP 157 compared to BIP 37 in terms of applying filters to mempool and checking zero confirmation transactions. The light client can only process unconfirmed transactions by loading the entire mempool transaction flow, which raises concerns about DOS and fingerprinting. To address this, a possible solution is suggested, which involves retrieving a complete compact filter of the entire mempool using a maximum size ordered by feerate. This filter could be dynamically constructed and updated based on time intervals rather than every new transaction in the mempool. The process includes generating a mempool filter, connecting to the peer, requesting the filter, processing it for relevant transactions, and sending getdata for those transactions. After the initial retrieve, the light client inspects all new transactions received from peers (filterless unconfirmed tx detection). Alternatively, the mempool filter can be requested again after a timeout if the previous process consumes too much bandwidth. The goal is to make the light client process more efficient without compromising privacy and security.The Block Batch Filters draft has been improved, unlocking the ability to filter unconfirmed transactions for SPV nodes using BIP 157 instead of BIP 37, which had privacy leaks. This allows light clients that refused to use BIP 37 to process unconfirmed transactions by loading the entire mempool transaction flow. Additionally, the Mempool Transaction Filters draft proposes a future consensus layer soft-fork to incorporate block filters commitment into block validation rules, protecting light nodes from payment hiding attacks. This method also reduces bandwidth consumption compared to block filters and downloading full blocks for affected addresses.The updated version of the draft for BIP block batch filters can be found on the Bitaps Github page. It includes changes such as a return to Golomb coding and a simpler, more effective schema implementation. The total filter size is smaller than BIP 158, with estimated savings of over 20%. The filter is deterministic and could potentially be committed as a commitment in coinbase transactions in the future. The GCS parameters are flexible to maintain necessary FPS, and the filter has been split into two parts - unique elements and duplicated elements - with the latter encoded more effectively. However, there are still questions about the optimal range for batch, the need for SIP hash instead of using the first 64 bits from pub key/script hash, and whether unique/duplicated elements should be downloaded separately or if filter types should be added for these purposes. Feedback and discussions on these topics are welcome.Aleksey Karpov also shared a draft of a BIP for compact probabilistic block filters as an alternative to BIP 158. While BIP 158 has a low false positive rate, a higher false positive rate filter could achieve lower bandwidth while syncing the blockchain. However, BIP 158 does not support filter batching due to the design of its parameters for siphash and Golomb coding. The proposed alternative uses delta coding and splits data into two bit string sequences, compressing the second sequence with two rounds of the Huffman algorithm. This method has an effectiveness rate of about 98% compared to Golomb with optimal parameters. Batching block filters significantly reduces their size, and separating filters by address type allows lite clients to avoid downloading redundant information without compromising privacy. The recommended strategy for lite client filters download is to get the biggest filter (smallest blocks/size rate) for a blocks range, then, in case of a positive test, get medium filters to reduce the blocks range, followed by getting block filters for the affected range and downloading affected blocks over TOR. An implementation in Python can be found on GitHub.Tamas Blummer also shared his thoughts on the use of filters in deciding whether to download newly announced blocks. He believes that whole chain scans would be better served with plain sequential reads in map-reduce style. Many clients do not care about filters for blocks before the birth date of their wallet's keys, so they skip over the majority of history, resulting in greater savings than any aggregate filter. Blummer wishes for a filter commitment as it could unlock more utility than marginal savings through a more elaborate design.In conclusion, there are ongoing developments and discussions regarding the limitations of BIP 157, the improvements to the Block Batch Filters draft, and the proposed alternative compact probabilistic block filters. The aim is to make the light client process more efficient while ensuring privacy and security. Feedback and input on these matters are encouraged. 2019-10-11T15:44:54+00:00 + The conversation discusses the limitations of BIP 157 compared to BIP 37 in terms of applying filters to mempool and checking zero confirmation transactions. The light client can only process unconfirmed transactions by loading the entire mempool transaction flow, which raises concerns about DOS and fingerprinting. To address this, a possible solution is suggested, which involves retrieving a complete compact filter of the entire mempool using a maximum size ordered by feerate. This filter could be dynamically constructed and updated based on time intervals rather than every new transaction in the mempool. The process includes generating a mempool filter, connecting to the peer, requesting the filter, processing it for relevant transactions, and sending getdata for those transactions. After the initial retrieve, the light client inspects all new transactions received from peers (filterless unconfirmed tx detection). Alternatively, the mempool filter can be requested again after a timeout if the previous process consumes too much bandwidth. The goal is to make the light client process more efficient without compromising privacy and security.The Block Batch Filters draft has been improved, unlocking the ability to filter unconfirmed transactions for SPV nodes using BIP 157 instead of BIP 37, which had privacy leaks. This allows light clients that refused to use BIP 37 to process unconfirmed transactions by loading the entire mempool transaction flow. Additionally, the Mempool Transaction Filters draft proposes a future consensus layer soft-fork to incorporate block filters commitment into block validation rules, protecting light nodes from payment hiding attacks. This method also reduces bandwidth consumption compared to block filters and downloading full blocks for affected addresses.The updated version of the draft for BIP block batch filters can be found on the Bitaps Github page. It includes changes such as a return to Golomb coding and a simpler, more effective schema implementation. The total filter size is smaller than BIP 158, with estimated savings of over 20%. The filter is deterministic and could potentially be committed as a commitment in coinbase transactions in the future. The GCS parameters are flexible to maintain necessary FPS, and the filter has been split into two parts - unique elements and duplicated elements - with the latter encoded more effectively. However, there are still questions about the optimal range for batch, the need for SIP hash instead of using the first 64 bits from pub key/script hash, and whether unique/duplicated elements should be downloaded separately or if filter types should be added for these purposes. Feedback and discussions on these topics are welcome.Aleksey Karpov also shared a draft of a BIP for compact probabilistic block filters as an alternative to BIP 158. While BIP 158 has a low false positive rate, a higher false positive rate filter could achieve lower bandwidth while syncing the blockchain. However, BIP 158 does not support filter batching due to the design of its parameters for siphash and Golomb coding. The proposed alternative uses delta coding and splits data into two bit string sequences, compressing the second sequence with two rounds of the Huffman algorithm. This method has an effectiveness rate of about 98% compared to Golomb with optimal parameters. Batching block filters significantly reduces their size, and separating filters by address type allows lite clients to avoid downloading redundant information without compromising privacy. The recommended strategy for lite client filters download is to get the biggest filter (smallest blocks/size rate) for a blocks range, then, in case of a positive test, get medium filters to reduce the blocks range, followed by getting block filters for the affected range and downloading affected blocks over TOR. An implementation in Python can be found on GitHub.Tamas Blummer also shared his thoughts on the use of filters in deciding whether to download newly announced blocks. He believes that whole chain scans would be better served with plain sequential reads in map-reduce style. Many clients do not care about filters for blocks before the birth date of their wallet's keys, so they skip over the majority of history, resulting in greater savings than any aggregate filter. Blummer wishes for a filter commitment as it could unlock more utility than marginal savings through a more elaborate design.In conclusion, there are ongoing developments and discussions regarding the limitations of BIP 157, the improvements to the Block Batch Filters draft, and the proposed alternative compact probabilistic block filters. The aim is to make the light client process more efficient while ensuring privacy and security. Feedback and input on these matters are encouraged. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_Continuing-the-discussion-about-noinput-anyprevout.xml b/static/bitcoin-dev/Sept_2019/combined_Continuing-the-discussion-about-noinput-anyprevout.xml index 722807ecb7..9cb648f4d2 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Continuing-the-discussion-about-noinput-anyprevout.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Continuing-the-discussion-about-noinput-anyprevout.xml @@ -1,77 +1,155 @@ - + 2 Combined summary - Continuing the discussion about noinput / anyprevout - 2023-08-02T01:23:46.150383+00:00 - - Anthony Towns 2019-10-05 10:06:15+00:00 - - - Christian Decker 2019-10-03 11:08:29+00:00 - - - Christian Decker 2019-10-03 10:30:03+00:00 - - - Christian Decker 2019-10-03 10:01:58+00:00 - - - Christian Decker 2019-10-03 09:57:05+00:00 - - - Christian Decker 2019-10-03 09:42:00+00:00 - - - ZmnSCPxj 2019-10-03 03:07:55+00:00 - - - Anthony Towns 2019-10-03 01:47:58+00:00 - - - s7r 2019-10-02 15:11:25+00:00 - - - ZmnSCPxj 2019-10-02 02:03:43+00:00 - - - Anthony Towns 2019-10-01 15:59:29+00:00 - - - ZmnSCPxj 2019-10-01 15:42:08+00:00 - - - ZmnSCPxj 2019-10-01 15:35:34+00:00 - - - Chris Stewart 2019-10-01 15:14:56+00:00 - - - Anthony Towns 2019-10-01 14:45:48+00:00 - - - Ethan Heilman 2019-10-01 14:27:21+00:00 - - - Christian Decker 2019-10-01 14:26:39+00:00 - - - Christian Decker 2019-10-01 14:20:25+00:00 - - - ZmnSCPxj 2019-10-01 13:31:49+00:00 - - - Chris Stewart 2019-10-01 12:23:47+00:00 - - - ZmnSCPxj 2019-09-30 23:28:43+00:00 - - - ZmnSCPxj 2019-09-30 16:00:35+00:00 - - - Christian Decker 2019-09-30 13:23:56+00:00 - + 2025-09-26T15:39:03.076827+00:00 + python-feedgen + + + [bitcoin-dev] Continuing the discussion about noinput / anyprevout Christian Decker + 2019-09-30T13:23:00.000Z + + + ZmnSCPxj + 2019-09-30T16:00:00.000Z + + + ZmnSCPxj + 2019-09-30T23:28:00.000Z + + + Chris Stewart + 2019-10-01T12:23:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2019-10-01T13:31:00.000Z + + + Christian Decker + 2019-10-01T14:20:00.000Z + + + Christian Decker + 2019-10-01T14:26:00.000Z + + + Ethan Heilman + 2019-10-01T14:27:00.000Z + + + Anthony Towns + 2019-10-01T14:45:00.000Z + + + Chris Stewart + 2019-10-01T15:14:00.000Z + + + ZmnSCPxj + 2019-10-01T15:35:00.000Z + + + ZmnSCPxj + 2019-10-01T15:42:00.000Z + + + [bitcoin-dev] " Anthony Towns + 2019-10-01T15:59:00.000Z + + + ZmnSCPxj + 2019-10-02T02:03:00.000Z + + + [bitcoin-dev] " s7r + 2019-10-02T15:11:00.000Z + + + [bitcoin-dev] [Lightning-dev] " Anthony Towns + 2019-10-03T01:47:00.000Z + + + ZmnSCPxj + 2019-10-03T03:07:00.000Z + + + Christian Decker + 2019-10-03T09:42:00.000Z + + + Christian Decker + 2019-10-03T09:57:00.000Z + + + Christian Decker + 2019-10-03T10:01:00.000Z + + + Christian Decker + 2019-10-03T10:30:00.000Z + + + Christian Decker + 2019-10-03T11:08:00.000Z + + + [bitcoin-dev] OP_CAT was " Ethan Heilman + 2019-10-03T15:05:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2019-10-03T23:42:00.000Z + + + Ethan Heilman + 2019-10-04T00:48:00.000Z + + + Jeremy + 2019-10-04T05:02:00.000Z + + + ZmnSCPxj + 2019-10-04T07:00:00.000Z + + + Peter Todd + 2019-10-04T11:15:00.000Z + + + Jeremy + 2019-10-04T18:33:00.000Z + + + Jeremy + 2019-10-04T18:40:00.000Z + + + Anthony Towns + 2019-10-05T10:06:00.000Z + + + Peter Todd + 2019-10-05T15:49:00.000Z + + + Lloyd Fournier + 2019-10-06T07:02:00.000Z + + + ZmnSCPxj + 2019-10-06T08:46:00.000Z + + + Peter Todd + 2019-10-06T09:12:00.000Z + + + Andrew Poelstra + 2019-10-09T16:56:00.000Z + + @@ -95,13 +173,13 @@ - python-feedgen + 2 Combined summary - Continuing the discussion about noinput / anyprevout - 2023-08-02T01:23:46.150383+00:00 + 2025-09-26T15:39:03.080378+00:00 - In a Bitcoin development mailing list, there have been discussions about various proposals and ideas related to the implementation of new opcodes and public key types. One proposal suggests creating an opcode called `OP_CHECKSIG_WITHOUT_INPUT` that would ignore any `SIGHASH` flags on a signature. Another member suggests encoding the new code in a tapscript public key type. The discussions revolve around the benefits and drawbacks of these proposals for off-chain protocols, particularly for eltoo.There is also a discussion about the usefulness of noinput/anyprevoutanyscript/anyprevout and their potential impact on off-chain protocol designs. While there is general agreement on the adoption of these proposals, concerns are raised about the potential misuse of no_input by bad wallet designers. However, it is suggested that there are simpler ways to cut corners and that good wallet options will always be available.The discussions also touch upon the advantages and disadvantages of chaperone signatures and output tagging/explicit opt-in. Some developers believe that the downsides of chaperone signatures outweigh their benefits, as they require additional code complexity. Output tagging is also seen as potentially negatively impacting the anonymity set of taproot transactions.Efforts are made to merge proposals such as BIP-118 and bip-anyprevout, but chaperone signatures and output tagging are suggested to be part of the discussion of security alternatives rather than the initial specification. It is emphasized that making core code simpler and handling potential issues in higher-level non-consensus code is preferable.In another Bitcoin development discussion, the idea of creating a new opcode called `OP_CHECKSIG_WITHOUT_INPUT` as an alternative to `SIGHASH_NOINPUT` is proposed. However, it is pointed out that there wouldn't be much difference between creating a new opcode and making a new tapscript public key type. The discussions explore the pros and cons of each approach, considering factors such as design space, potential bikeshedding, and signature verification modalities.The discussions also touch upon the proposal of output tagging as a solution for transaction malleability. While some developers see it as a viable solution, others oppose it because it goes against the uniformity of unspent Taproot outputs and may impose additional costs in terms of transaction complexity and anonymity.There are also discussions about the implementation of Decker-Russell-Osuntokun and its potential use cases. Suggestions are made regarding the use of trigger transactions, plain bip-schnorr-signed outputs, and off-chain payment networks to increase anonymity sets and ensure security.Overall, the discussions aim to find optimal solutions for off-chain protocol designs while considering factors such as security, simplicity, and usability.The author of the email expresses concerns about the potential risks associated with the introduction of SIGHASH_NOINPUT in the Bitcoin protocol, particularly in relation to address reuse. They highlight that if a digital signature from a cold storage address with a SIGHASH_NOINPUT signature is replayed on the blockchain, it could lead to fund loss. This becomes especially problematic if the second signing path that uses SIGHASH_NOINPUT gets mixed up with the first signing path that controls an exchange's on-chain funds.Despite these risks, SIGHASH_NOINPUT is seen as a valuable tool for off-chain protocols like Lightning, but it would require large economic entities such as exchanges to have a separate signing path using SIGHASH_NOINPUT to keep on-chain and off-chain hot wallet signing procedures distinct. The author also raises concerns about introducing more complexities into the protocol and suggests disallowing the use of SIGHASH protocols with unexpected behavior.The article discusses two proposals, BIP-118 and bip-anyprevout, which aim to allow rebinding of transactions to new outputs. However, there are still unclear points regarding the dangers of SIGHASH_NOINPUT and chaperone signatures. Chaperone signatures ensure there is no third-party malleability of transactions but have downsides such as additional size and the possibility of protocols using a globally known privkey. Output tagging is proposed as a way to disincentivize non-smart-contract cases by making output scripts unaddressable, potentially creating two domains: one for user-addressable destinations and one for contracts.Christian Decker, a developer at Blockstream, proposes "eltoo" transactions as a means to significantly reduce costs associated with using the Lightning Network. While these transactions are less flexible, they could replace existing ones in the Lightning Network, enabling almost instant and low-cost Bitcoin payments. Decker also suggests using output tagging and chaperone signatures alongside eltoo transactions to enhance security and efficiency.The email proposes the creation of a new opcode, OP_CHECKSIG_WITHOUT_INPUT, equivalent to SIGHASH_NOINPUT, which would be embedded in a Taproot script. This opcode would ignore any SIGHASH flags on a signature and instead hash the current transaction without input references before checking it against the signature. The author questions why there is less 2019-10-05T10:06:15+00:00 + In a Bitcoin development mailing list, there have been discussions about various proposals and ideas related to the implementation of new opcodes and public key types. One proposal suggests creating an opcode called `OP_CHECKSIG_WITHOUT_INPUT` that would ignore any `SIGHASH` flags on a signature. Another member suggests encoding the new code in a tapscript public key type. The discussions revolve around the benefits and drawbacks of these proposals for off-chain protocols, particularly for eltoo.There is also a discussion about the usefulness of noinput/anyprevoutanyscript/anyprevout and their potential impact on off-chain protocol designs. While there is general agreement on the adoption of these proposals, concerns are raised about the potential misuse of no_input by bad wallet designers. However, it is suggested that there are simpler ways to cut corners and that good wallet options will always be available.The discussions also touch upon the advantages and disadvantages of chaperone signatures and output tagging/explicit opt-in. Some developers believe that the downsides of chaperone signatures outweigh their benefits, as they require additional code complexity. Output tagging is also seen as potentially negatively impacting the anonymity set of taproot transactions.Efforts are made to merge proposals such as BIP-118 and bip-anyprevout, but chaperone signatures and output tagging are suggested to be part of the discussion of security alternatives rather than the initial specification. It is emphasized that making core code simpler and handling potential issues in higher-level non-consensus code is preferable.In another Bitcoin development discussion, the idea of creating a new opcode called `OP_CHECKSIG_WITHOUT_INPUT` as an alternative to `SIGHASH_NOINPUT` is proposed. However, it is pointed out that there wouldn't be much difference between creating a new opcode and making a new tapscript public key type. The discussions explore the pros and cons of each approach, considering factors such as design space, potential bikeshedding, and signature verification modalities.The discussions also touch upon the proposal of output tagging as a solution for transaction malleability. While some developers see it as a viable solution, others oppose it because it goes against the uniformity of unspent Taproot outputs and may impose additional costs in terms of transaction complexity and anonymity.There are also discussions about the implementation of Decker-Russell-Osuntokun and its potential use cases. Suggestions are made regarding the use of trigger transactions, plain bip-schnorr-signed outputs, and off-chain payment networks to increase anonymity sets and ensure security.Overall, the discussions aim to find optimal solutions for off-chain protocol designs while considering factors such as security, simplicity, and usability.The author of the email expresses concerns about the potential risks associated with the introduction of SIGHASH_NOINPUT in the Bitcoin protocol, particularly in relation to address reuse. They highlight that if a digital signature from a cold storage address with a SIGHASH_NOINPUT signature is replayed on the blockchain, it could lead to fund loss. This becomes especially problematic if the second signing path that uses SIGHASH_NOINPUT gets mixed up with the first signing path that controls an exchange's on-chain funds.Despite these risks, SIGHASH_NOINPUT is seen as a valuable tool for off-chain protocols like Lightning, but it would require large economic entities such as exchanges to have a separate signing path using SIGHASH_NOINPUT to keep on-chain and off-chain hot wallet signing procedures distinct. The author also raises concerns about introducing more complexities into the protocol and suggests disallowing the use of SIGHASH protocols with unexpected behavior.The article discusses two proposals, BIP-118 and bip-anyprevout, which aim to allow rebinding of transactions to new outputs. However, there are still unclear points regarding the dangers of SIGHASH_NOINPUT and chaperone signatures. Chaperone signatures ensure there is no third-party malleability of transactions but have downsides such as additional size and the possibility of protocols using a globally known privkey. Output tagging is proposed as a way to disincentivize non-smart-contract cases by making output scripts unaddressable, potentially creating two domains: one for user-addressable destinations and one for contracts.Christian Decker, a developer at Blockstream, proposes "eltoo" transactions as a means to significantly reduce costs associated with using the Lightning Network. While these transactions are less flexible, they could replace existing ones in the Lightning Network, enabling almost instant and low-cost Bitcoin payments. Decker also suggests using output tagging and chaperone signatures alongside eltoo transactions to enhance security and efficiency.The email proposes the creation of a new opcode, OP_CHECKSIG_WITHOUT_INPUT, equivalent to SIGHASH_NOINPUT, which would be embedded in a Taproot script. This opcode would ignore any SIGHASH flags on a signature and instead hash the current transaction without input references before checking it against the signature. The author questions why there is less - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_Draft-BIP-for-SNICKER.xml b/static/bitcoin-dev/Sept_2019/combined_Draft-BIP-for-SNICKER.xml index 6bf21f3c01..128aa0af77 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Draft-BIP-for-SNICKER.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Draft-BIP-for-SNICKER.xml @@ -1,38 +1,51 @@ - + 2 Combined summary - Draft BIP for SNICKER - 2023-08-02T01:18:16.750104+00:00 - - AdamISZ 2019-11-23 12:43:27+00:00 - - - popo 2019-11-22 14:57:10+00:00 - - - AdamISZ 2019-11-22 14:02:56+00:00 - - - Riccardo Casatta 2019-11-06 16:52:06+00:00 - - - AdamISZ 2019-10-22 13:21:00+00:00 - - - SomberNight 2019-10-21 15:04:59+00:00 - - - Riccardo Casatta 2019-10-21 11:00:26+00:00 - - - David A. Harding 2019-10-21 00:06:08+00:00 - - - SomberNight 2019-10-20 00:29:25+00:00 - - - AdamISZ 2019-09-01 13:46:57+00:00 - + 2025-09-26T15:39:09.383120+00:00 + python-feedgen + + + [bitcoin-dev] Draft BIP for SNICKER AdamISZ + 2019-09-01T13:46:00.000Z + + + SomberNight + 2019-10-20T00:29:00.000Z + + + David A. Harding + 2019-10-21T00:06:00.000Z + + + Riccardo Casatta + 2019-10-21T11:00:00.000Z + + + SomberNight + 2019-10-21T15:04:00.000Z + + + AdamISZ + 2019-10-22T13:21:00.000Z + + + Riccardo Casatta + 2019-11-06T16:52:00.000Z + + + AdamISZ + 2019-11-22T14:02:00.000Z + + + popo + 2019-11-22T14:57:00.000Z + + + AdamISZ + 2019-11-23T12:43:00.000Z + + @@ -43,13 +56,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for SNICKER - 2023-08-02T01:18:16.750104+00:00 + 2025-09-26T15:39:09.384336+00:00 - The SNICKER proposal aims to provide increased privacy benefits over traditional coinjoin in Bitcoin. It suggests a two-party coinjoin implementation that trades off size for convenience and low effort. However, there are no privacy guarantees, and frequent two-party mixes can degrade blockchain analysis. The proposal involves specialized entities as Proposers, with only the Receiver requiring zero effort. Coinjoin breaks the common input ownership heuristic, and the delinking effect of equal-sized outputs of the same scriptpubkey type is valuable.The discussion on the bitcoin-dev mailing list revolves around the issue of watch-only wallets and the key tweak (`c` as per draft BIP) required for effective coinjoin functionality. Classic watch-only use cases are incompatible with SNICKER, but recovering from zero information and monitoring in real-time as new SNICKER transactions arrive are possible. The `c` values could be sent from the hot to the cold wallets without changing the cold's security model.The email exchange discusses the complexity and cost implications of adding second-stage transactions to SNICKER. It aligns with CoinJoinXT and segwit ideas but may not be implemented. The watch-only issue is addressed, emphasizing the need to keep the key tweak secret to the proposer and receiver. AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer are also mentioned. The discussions have been useful in exploring the potential benefits and limitations of SNICKER.Riccardo Casatta proposes a solution to the watch-only issue in CoinJoin transactions, suggesting the creation of a separate encrypted transaction along with the CoinJoin transaction. AdamISZ responds that adding this complexity may not be feasible due to cost implications. The key tweak `c` must be known by the proposer and receiver but not by anyone else, making it incompatible with classic watch-only use cases. However, sending `c` values from the hot wallet to the cold wallet is possible without changing the cold's security model. The discussions highlight the challenges related to watch-only wallets and the security considerations for Receiver from a Proposer.The SNICKER protocol's recovery process is necessary for wallet recovery, requiring communication between the hot and cold wallets. Monitoring a wallet in real-time with no privkey access is incompatible with this, but hot/cold monitoring is feasible if desired. Ongoing address discovery is required for many use cases of watch-only wallets, which would break without SNICKER's functionality.The implementation of SNICKER in Electrum for the "Receiver" role is discussed, highlighting the incompatibility with watch-only wallets. Interaction with the cold wallet is required, and a recovery procedure is proposed. The candidate transactions can be transferred to the cold wallet using means like USB drives or QR codes, and the cold wallet can perform the necessary steps using its private keys. This process may need to be repeated for subsequent SNICKER rounds.The SNICKER proposal aims to break common chain-analysis assumptions and provide increased privacy benefits. However, it is incompatible with watch-only wallets. Users must choose between using xpubs or participating in SNICKER coinjoins as a Receiver during wallet creation. Adjustments to the scheme are unclear, as the key tweak `c` must be known only by the coinjoin participants.A draft BIP for the SNICKER proposal has been shared, highlighting its ease of implementation for wallet developers. However, there is uncertainty on transaction and encryption specifications.The author of the context has implemented the algorithm used by Electrum, but there are concerns regarding its validity. The author is seeking feedback on their draft to address these concerns. It is important to note that the specific details of the algorithm used by Electrum are not provided in the context. However, the fact that the author has attempted to replicate it suggests that it may play a significant role in their work. To gain a better understanding of the algorithm and its implications, it would be helpful to review the feedback and suggestions provided by others. By incorporating this feedback into their draft, the author can strengthen their work and potentially address any doubts or uncertainties surrounding the algorithm's efficacy. In conclusion, the author has implemented an algorithm similar to the one used by Electrum, but there are doubts about its reliability. The author seeks feedback on their draft to ensure the accuracy and effectiveness of their work. Reviewing the algorithm and considering the feedback received will aid in improving the overall quality and validity of the author's implementation. 2019-11-23T12:43:27+00:00 + The SNICKER proposal aims to provide increased privacy benefits over traditional coinjoin in Bitcoin. It suggests a two-party coinjoin implementation that trades off size for convenience and low effort. However, there are no privacy guarantees, and frequent two-party mixes can degrade blockchain analysis. The proposal involves specialized entities as Proposers, with only the Receiver requiring zero effort. Coinjoin breaks the common input ownership heuristic, and the delinking effect of equal-sized outputs of the same scriptpubkey type is valuable.The discussion on the bitcoin-dev mailing list revolves around the issue of watch-only wallets and the key tweak (`c` as per draft BIP) required for effective coinjoin functionality. Classic watch-only use cases are incompatible with SNICKER, but recovering from zero information and monitoring in real-time as new SNICKER transactions arrive are possible. The `c` values could be sent from the hot to the cold wallets without changing the cold's security model.The email exchange discusses the complexity and cost implications of adding second-stage transactions to SNICKER. It aligns with CoinJoinXT and segwit ideas but may not be implemented. The watch-only issue is addressed, emphasizing the need to keep the key tweak secret to the proposer and receiver. AES-GCM vs AES-CBC and the security of the construction for a Receiver from a Proposer are also mentioned. The discussions have been useful in exploring the potential benefits and limitations of SNICKER.Riccardo Casatta proposes a solution to the watch-only issue in CoinJoin transactions, suggesting the creation of a separate encrypted transaction along with the CoinJoin transaction. AdamISZ responds that adding this complexity may not be feasible due to cost implications. The key tweak `c` must be known by the proposer and receiver but not by anyone else, making it incompatible with classic watch-only use cases. However, sending `c` values from the hot wallet to the cold wallet is possible without changing the cold's security model. The discussions highlight the challenges related to watch-only wallets and the security considerations for Receiver from a Proposer.The SNICKER protocol's recovery process is necessary for wallet recovery, requiring communication between the hot and cold wallets. Monitoring a wallet in real-time with no privkey access is incompatible with this, but hot/cold monitoring is feasible if desired. Ongoing address discovery is required for many use cases of watch-only wallets, which would break without SNICKER's functionality.The implementation of SNICKER in Electrum for the "Receiver" role is discussed, highlighting the incompatibility with watch-only wallets. Interaction with the cold wallet is required, and a recovery procedure is proposed. The candidate transactions can be transferred to the cold wallet using means like USB drives or QR codes, and the cold wallet can perform the necessary steps using its private keys. This process may need to be repeated for subsequent SNICKER rounds.The SNICKER proposal aims to break common chain-analysis assumptions and provide increased privacy benefits. However, it is incompatible with watch-only wallets. Users must choose between using xpubs or participating in SNICKER coinjoins as a Receiver during wallet creation. Adjustments to the scheme are unclear, as the key tweak `c` must be known only by the coinjoin participants.A draft BIP for the SNICKER proposal has been shared, highlighting its ease of implementation for wallet developers. However, there is uncertainty on transaction and encryption specifications.The author of the context has implemented the algorithm used by Electrum, but there are concerns regarding its validity. The author is seeking feedback on their draft to address these concerns. It is important to note that the specific details of the algorithm used by Electrum are not provided in the context. However, the fact that the author has attempted to replicate it suggests that it may play a significant role in their work. To gain a better understanding of the algorithm and its implications, it would be helpful to review the feedback and suggestions provided by others. By incorporating this feedback into their draft, the author can strengthen their work and potentially address any doubts or uncertainties surrounding the algorithm's efficacy. In conclusion, the author has implemented an algorithm similar to the one used by Electrum, but there are doubts about its reliability. The author seeks feedback on their draft to ensure the accuracy and effectiveness of their work. Reviewing the algorithm and considering the feedback received will aid in improving the overall quality and validity of the author's implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_Introcing-a-side-memory-network-to-bitcoin-for-ads.xml b/static/bitcoin-dev/Sept_2019/combined_Introcing-a-side-memory-network-to-bitcoin-for-ads.xml index c4bb081262..373384b820 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Introcing-a-side-memory-network-to-bitcoin-for-ads.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Introcing-a-side-memory-network-to-bitcoin-for-ads.xml @@ -1,27 +1,33 @@ - + 2 Combined summary - Introcing a side memory network to bitcoin for ads - 2023-08-02T01:20:48.847434+00:00 - - ZmnSCPxj 2019-09-18 04:41:15+00:00 - - - ZmnSCPxj 2019-09-17 01:54:41+00:00 - - - Tamas Blummer 2019-09-14 13:21:28+00:00 - + 2025-09-26T15:38:50.414304+00:00 + python-feedgen + + + [bitcoin-dev] Introcing a side memory network to bitcoin for ads Tamas Blummer + 2019-09-14T13:21:00.000Z + + + ZmnSCPxj + 2019-09-17T01:54:00.000Z + + + ZmnSCPxj + 2019-09-18T04:41:00.000Z + + - python-feedgen + 2 Combined summary - Introcing a side memory network to bitcoin for ads - 2023-08-02T01:20:48.847434+00:00 + 2025-09-26T15:38:50.414870+00:00 - Defiads is a side memory network built on top of Rust open source tools and designed to serve decentralized finance applications. It enables the distribution of advertisements, order books, coinjoin proposals, and more. The network consists of defiads nodes that maintain a shared 1GB memory pool of current ads. Each node replicates ads to other nodes as long as there are bitcoins locked to it on the Bitcoin network using the pay-to-contract protocol. Ads are evicted from the pool once the locked coins become spendable again.Advertisements in Defiads are ranked based on the ratio of used space divided by the locked bitcoins. Only the top 1GB of this ranked list is replicated among the nodes. Users can read ads by starting their own defiads process and querying the content through the JSON-RPC API. To place ads, users must deposit bitcoins into their defiads node's wallet, prepare an ad with category, abstract, and content, lock some of the bitcoins to it for a limited term of advertisement, and withdraw the coins after the ad expires.Defiads connects to both the Bitcoin network and its own peer-to-peer network. It only needs a fraction of the information on the Bitcoin blockchain and operates as an SPV (Simplified Payment Verification) node. The wallet of the defiads node is compatible with popular wallets such as TREZOR, Ledger, Greenwallet, etc., that support BIP38, BIP44, BIP48, BIP84 key generation standards.The synchronization of the ads pool among peers in the defiads network is achieved using Invertible Bloom Lookup Tables. However, it is advised not to use real bitcoins on the network yet, as it is still in its early stages and currently connected to the Bitcoin test network. Discovery of the network is not available, so users need to know a peer in the network to see ads other than their own.In the future, if the use of defiads becomes popular and the 1GB pool becomes tight, users may have to compete for its use. Those who do not have enough bitcoins to lock may pay others to lock their bitcoins, enabling them to fund advertisements. This could give rise to Bitcoin's first truly riskless interest rate market. Tamas Blummer, the creator of defiads, hopes that someone will build a user-friendly UI on top of the JSON-RPC API. 2019-09-18T04:41:15+00:00 + Defiads is a side memory network built on top of Rust open source tools and designed to serve decentralized finance applications. It enables the distribution of advertisements, order books, coinjoin proposals, and more. The network consists of defiads nodes that maintain a shared 1GB memory pool of current ads. Each node replicates ads to other nodes as long as there are bitcoins locked to it on the Bitcoin network using the pay-to-contract protocol. Ads are evicted from the pool once the locked coins become spendable again.Advertisements in Defiads are ranked based on the ratio of used space divided by the locked bitcoins. Only the top 1GB of this ranked list is replicated among the nodes. Users can read ads by starting their own defiads process and querying the content through the JSON-RPC API. To place ads, users must deposit bitcoins into their defiads node's wallet, prepare an ad with category, abstract, and content, lock some of the bitcoins to it for a limited term of advertisement, and withdraw the coins after the ad expires.Defiads connects to both the Bitcoin network and its own peer-to-peer network. It only needs a fraction of the information on the Bitcoin blockchain and operates as an SPV (Simplified Payment Verification) node. The wallet of the defiads node is compatible with popular wallets such as TREZOR, Ledger, Greenwallet, etc., that support BIP38, BIP44, BIP48, BIP84 key generation standards.The synchronization of the ads pool among peers in the defiads network is achieved using Invertible Bloom Lookup Tables. However, it is advised not to use real bitcoins on the network yet, as it is still in its early stages and currently connected to the Bitcoin test network. Discovery of the network is not available, so users need to know a peer in the network to see ads other than their own.In the future, if the use of defiads becomes popular and the 1GB pool becomes tight, users may have to compete for its use. Those who do not have enough bitcoins to lock may pay others to lock their bitcoins, enabling them to fund advertisements. This could give rise to Bitcoin's first truly riskless interest rate market. Tamas Blummer, the creator of defiads, hopes that someone will build a user-friendly UI on top of the JSON-RPC API. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_New-BIP-for-p2p-messages-state-enabling-reconciliation-based-protocols-Erlay-.xml b/static/bitcoin-dev/Sept_2019/combined_New-BIP-for-p2p-messages-state-enabling-reconciliation-based-protocols-Erlay-.xml index 78c54dff96..7a3717189f 100644 --- a/static/bitcoin-dev/Sept_2019/combined_New-BIP-for-p2p-messages-state-enabling-reconciliation-based-protocols-Erlay-.xml +++ b/static/bitcoin-dev/Sept_2019/combined_New-BIP-for-p2p-messages-state-enabling-reconciliation-based-protocols-Erlay-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - New BIP for p2p messages/state enabling reconciliation-based protocols (Erlay) - 2023-08-02T01:22:12.452040+00:00 - - Rusty Russell 2019-09-27 02:08:27+00:00 - - - Gleb Naumenko 2019-09-25 11:28:00+00:00 - + 2025-09-26T15:38:52.504529+00:00 + python-feedgen + + + [bitcoin-dev] New BIP for p2p messages/state enabling reconciliation-based protocols (Erlay) Gleb Naumenko + 2019-09-25T11:28:00.000Z + + + Rusty Russell + 2019-09-27T02:08:00.000Z + + - python-feedgen + 2 Combined summary - New BIP for p2p messages/state enabling reconciliation-based protocols (Erlay) - 2023-08-02T01:22:12.452040+00:00 + 2025-09-26T15:38:52.504952+00:00 - In an email exchange, Rusty provides feedback on a draft that outlines low-level specifications for a reconciliation-based transaction announcement protocol. He questions the use of the term "requirements" in reference to data and suggests that actors have requirements instead. Additionally, Rusty seeks clarification on how to encode q, a coefficient used to estimate set difference. He also requests clarification on whether it's one or two sets of truncated IDs per peer. Furthermore, he recommends removing the phrase "To the best of our knowledge," from a statement about PinSketch being more bandwidth efficient than IBLT since he has implemented and experimented with IBLT and found it to be worse.The proposed specification includes salted short transaction IDs, which are necessary for efficient reconciliation. It also demonstrates how to compute sketches based on these IDs using simple Python scripts. Additionally, the specification introduces wtxid-based truncated transaction IDs, which can save a significant fraction of bandwidth. Agreeing on this specification would allow for the integration of more bandwidth-efficient relay protocols, such as Erlay.To prevent transmitting duplicate transactions, an extra round has been added where two parties explicitly map 32-bit short IDs to 128-bit truncated IDs. The draft provides all the necessary background information to understand the proposed work. It also specifies all the messages required for an efficient reconciliation-based protocol, along with new state variables necessary for the protocol's operation.Interested parties are encouraged to thoroughly read and review the draft. The proposed specification has the potential to significantly improve efficiency in transaction announcement protocols, making it an important development for the cryptocurrency community. 2019-09-27T02:08:27+00:00 + In an email exchange, Rusty provides feedback on a draft that outlines low-level specifications for a reconciliation-based transaction announcement protocol. He questions the use of the term "requirements" in reference to data and suggests that actors have requirements instead. Additionally, Rusty seeks clarification on how to encode q, a coefficient used to estimate set difference. He also requests clarification on whether it's one or two sets of truncated IDs per peer. Furthermore, he recommends removing the phrase "To the best of our knowledge," from a statement about PinSketch being more bandwidth efficient than IBLT since he has implemented and experimented with IBLT and found it to be worse.The proposed specification includes salted short transaction IDs, which are necessary for efficient reconciliation. It also demonstrates how to compute sketches based on these IDs using simple Python scripts. Additionally, the specification introduces wtxid-based truncated transaction IDs, which can save a significant fraction of bandwidth. Agreeing on this specification would allow for the integration of more bandwidth-efficient relay protocols, such as Erlay.To prevent transmitting duplicate transactions, an extra round has been added where two parties explicitly map 32-bit short IDs to 128-bit truncated IDs. The draft provides all the necessary background information to understand the proposed work. It also specifies all the messages required for an efficient reconciliation-based protocol, along with new state variables necessary for the protocol's operation.Interested parties are encouraged to thoroughly read and review the draft. The proposed specification has the potential to significantly improve efficiency in transaction announcement protocols, making it an important development for the cryptocurrency community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_PoW-fraud-proofs-without-a-soft-fork.xml b/static/bitcoin-dev/Sept_2019/combined_PoW-fraud-proofs-without-a-soft-fork.xml index 814f183795..9a97733f48 100644 --- a/static/bitcoin-dev/Sept_2019/combined_PoW-fraud-proofs-without-a-soft-fork.xml +++ b/static/bitcoin-dev/Sept_2019/combined_PoW-fraud-proofs-without-a-soft-fork.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - PoW fraud proofs without a soft fork - 2023-08-02T01:20:23.514810+00:00 - - David A. Harding 2019-09-16 16:48:21+00:00 - - - Ruben Somsen 2019-09-11 04:58:57+00:00 - - - ZmnSCPxj 2019-09-09 06:58:12+00:00 - - - Ruben Somsen 2019-09-09 06:53:28+00:00 - - - Dragi Bucukovski 2019-09-09 04:47:17+00:00 - - - ZmnSCPxj 2019-09-09 04:14:07+00:00 - - - Ruben Somsen 2019-09-08 03:39:28+00:00 - + 2025-09-26T15:38:58.838087+00:00 + python-feedgen + + + [bitcoin-dev] PoW fraud proofs without a soft fork Ruben Somsen + 2019-09-08T03:39:00.000Z + + + ZmnSCPxj + 2019-09-09T04:14:00.000Z + + + Dragi Bucukovski + 2019-09-09T04:47:00.000Z + + + Ruben Somsen + 2019-09-09T06:53:00.000Z + + + ZmnSCPxj + 2019-09-09T06:58:00.000Z + + + Ruben Somsen + 2019-09-11T04:58:00.000Z + + + David A. Harding + 2019-09-16T16:48:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - PoW fraud proofs without a soft fork - 2023-08-02T01:20:23.515800+00:00 + 2025-09-26T15:38:58.839011+00:00 - Ruben Somsen suggested using Tadge Dryja's utreexo work for implementing PoW fraud proofs in Bitcoin without a soft fork. However, Dave pointed out some potential issues with this approach. One concern is that the worst-case size of UTXO entries that need to be communicated can be over 200 MB, which could lead to DoS attacks on honest SPV clients by lying peers. Another issue is that nodes providing fraud proofs will require significant additional system resources and might be rare, making it easier to eclipse attack an SPV client relying on these proofs. Additionally, SPV clients currently do not implement all the consensus checks that full nodes perform, and even if fraud proofs are widely deployed, retraining SPV users to wait for higher confirmation counts may be necessary.In a discussion between Ruben and ZmnSCPxj, the security differences between committing or not committing the utreexo hash into a block were debated. While Ruben argued that there is no security difference, ZmnSCPxj countered that invalid inflation can fool SPV nodes while full nodes remain unaffected. Ruben agreed but clarified that his goal was to establish that committing the hash adds no security. He also mentioned other weaknesses of SPVs compared to full nodes, such as reliance on a network of utreexo-supporting full nodes, the need for at least one honest block to be mined, and slower consensus due to requiring honest minority participation.ZmnSCPxj highlighted the distinction between full nodes and SPVs during a sybil attack. In such an attack, a full node will stall, mistakenly thinking that the blockchain has no more miners, while an SPV will follow the false blockchain. ZmnSCPxj recommended that automated payment processing systems using full nodes refuse incoming payments during a sybil attack, generating warnings about the possibility of an attack. Implementing a timeout system could alert higher-layer management systems if a full node is unable to see a new block for an extended period. However, automated payment processing systems using SPVs with PoW fraud proofs may not detect a sybil attack, making them vulnerable to double-spending and false payments.The overall discussion revolves around the security concerns related to Sybil attacks on the Bitcoin blockchain. The comparison highlights the differences in behavior between full nodes and SPVs during such attacks, as well as the potential vulnerabilities of automated payment processing systems. The implementation of PoW fraud proofs without a soft fork using utreexo is also discussed, addressing both the committed and non-committed versions and their implications on security and bandwidth. 2019-09-16T16:48:21+00:00 + Ruben Somsen suggested using Tadge Dryja's utreexo work for implementing PoW fraud proofs in Bitcoin without a soft fork. However, Dave pointed out some potential issues with this approach. One concern is that the worst-case size of UTXO entries that need to be communicated can be over 200 MB, which could lead to DoS attacks on honest SPV clients by lying peers. Another issue is that nodes providing fraud proofs will require significant additional system resources and might be rare, making it easier to eclipse attack an SPV client relying on these proofs. Additionally, SPV clients currently do not implement all the consensus checks that full nodes perform, and even if fraud proofs are widely deployed, retraining SPV users to wait for higher confirmation counts may be necessary.In a discussion between Ruben and ZmnSCPxj, the security differences between committing or not committing the utreexo hash into a block were debated. While Ruben argued that there is no security difference, ZmnSCPxj countered that invalid inflation can fool SPV nodes while full nodes remain unaffected. Ruben agreed but clarified that his goal was to establish that committing the hash adds no security. He also mentioned other weaknesses of SPVs compared to full nodes, such as reliance on a network of utreexo-supporting full nodes, the need for at least one honest block to be mined, and slower consensus due to requiring honest minority participation.ZmnSCPxj highlighted the distinction between full nodes and SPVs during a sybil attack. In such an attack, a full node will stall, mistakenly thinking that the blockchain has no more miners, while an SPV will follow the false blockchain. ZmnSCPxj recommended that automated payment processing systems using full nodes refuse incoming payments during a sybil attack, generating warnings about the possibility of an attack. Implementing a timeout system could alert higher-layer management systems if a full node is unable to see a new block for an extended period. However, automated payment processing systems using SPVs with PoW fraud proofs may not detect a sybil attack, making them vulnerable to double-spending and false payments.The overall discussion revolves around the security concerns related to Sybil attacks on the Bitcoin blockchain. The comparison highlights the differences in behavior between full nodes and SPVs during such attacks, as well as the potential vulnerabilities of automated payment processing systems. The implementation of PoW fraud proofs without a soft fork using utreexo is also discussed, addressing both the committed and non-committed versions and their implications on security and bandwidth. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_Reconciling-the-off-chain-and-on-chain-models-with-eltoo.xml b/static/bitcoin-dev/Sept_2019/combined_Reconciling-the-off-chain-and-on-chain-models-with-eltoo.xml index 5e73b08221..1b48eaedc8 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Reconciling-the-off-chain-and-on-chain-models-with-eltoo.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Reconciling-the-off-chain-and-on-chain-models-with-eltoo.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Reconciling the off-chain and on-chain models with eltoo - 2023-08-02T01:20:06.465414+00:00 - - Christian Decker 2019-09-19 10:26:13+00:00 - - - ZmnSCPxj 2019-09-19 02:01:54+00:00 - - - Christian Decker 2019-09-18 13:44:47+00:00 - - - ZmnSCPxj 2019-09-18 05:28:38+00:00 - - - ZmnSCPxj 2019-09-10 01:28:04+00:00 - - - ZmnSCPxj 2019-09-06 14:32:38+00:00 - - - Christian Decker 2019-09-06 13:18:03+00:00 - + 2025-09-26T15:39:05.199043+00:00 + python-feedgen + + + [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo Christian Decker + 2019-09-06T13:18:00.000Z + + + ZmnSCPxj + 2019-09-06T14:32:00.000Z + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2019-09-10T01:28:00.000Z + + + ZmnSCPxj + 2019-09-18T05:28:00.000Z + + + Christian Decker + 2019-09-18T13:44:00.000Z + + + ZmnSCPxj + 2019-09-19T02:01:00.000Z + + + Christian Decker + 2019-09-19T10:26:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Reconciling the off-chain and on-chain models with eltoo - 2023-08-02T01:20:06.465414+00:00 + 2025-09-26T15:39:05.199940+00:00 - The discussion revolves around the challenges and potential solutions in multi-party off-chain mechanisms, specifically focusing on the Lightning Network. One proposed idea is to include an escape hatch in the scripts that allows spending any output attached to the settlement transaction by n-1 participants. However, careful design is necessary to prevent Sybil attacks, as the requirement for n-of-n signatures aims to prevent such attacks. The discussion also highlights the complexity of implementing uncooperative splice-outs and the limited benefits they offer.The participants suggest various solutions to address issues such as uncooperative membership change, fees for each update, privacy concerns, and liveness. Ideas include creating a new mechanism within the mechanism layer, playing a game with duplicate updates, using Tor to disassociate IP addresses from signers, and incorporating mix mechanisms to disassociate funds ownership from identity. Additionally, suggestions are made for cooperative closing of channels, membership changes, and addressing mining rewards, difficulty adjustment, and transaction fees.ZmnSCPxj proposes a future scenario where single-signer ownership of coins on-chain is less common, and instead, people are share-owners of coins. Concepts such as cooperative close, membership change, balance change, uncooperative close, and uncooperative membership change are discussed. The use of eltoo update scheme is also explored, which offers advantages over LN-Penalty for multiple party channels and commonly used types of scripts. The concept involves batched multi-party loop-in/out and the possibility of creating a new mechanism-within-mechanism layer.The email discusses the concept of transaction cut-through and its relevance to offchain systems. It explains how a transaction can be sent to participants, who can then agree to sign a new state with certain changes. Onchain enforcement can be triggered if there is disagreement. The writer also notes the importance of absolute timelocks in contracts and the need for transactions to be signed under 'SIGHASH_NOINPUT' in the offchain update mechanism. The Poon-Dryja system is considered straightforward to implement, while Decker-Russell-Osuntokun is praised as cool.The recently published proof-of-concept of eltoo on signet prompts a discussion on how to build this system. The clean separation of protocol layers provided by eltoo is seen as beneficial for simplifying reasoning and building more complex functionality. The update mechanism in eltoo does not complicate other layers like the penalty update mechanism does, allowing for focused development. Christian suggests using transactions as a means to represent off-chain negotiations and applying them to the off-chain state via cut-through. This approach offers advantages such as reusing existing tools and facilitating experimentation. Overall, Christian believes that eltoo enables the creation of a nicely layered protocol stack that improves flexibility and simplifies security reasoning. 2019-09-19T10:26:13+00:00 + The discussion revolves around the challenges and potential solutions in multi-party off-chain mechanisms, specifically focusing on the Lightning Network. One proposed idea is to include an escape hatch in the scripts that allows spending any output attached to the settlement transaction by n-1 participants. However, careful design is necessary to prevent Sybil attacks, as the requirement for n-of-n signatures aims to prevent such attacks. The discussion also highlights the complexity of implementing uncooperative splice-outs and the limited benefits they offer.The participants suggest various solutions to address issues such as uncooperative membership change, fees for each update, privacy concerns, and liveness. Ideas include creating a new mechanism within the mechanism layer, playing a game with duplicate updates, using Tor to disassociate IP addresses from signers, and incorporating mix mechanisms to disassociate funds ownership from identity. Additionally, suggestions are made for cooperative closing of channels, membership changes, and addressing mining rewards, difficulty adjustment, and transaction fees.ZmnSCPxj proposes a future scenario where single-signer ownership of coins on-chain is less common, and instead, people are share-owners of coins. Concepts such as cooperative close, membership change, balance change, uncooperative close, and uncooperative membership change are discussed. The use of eltoo update scheme is also explored, which offers advantages over LN-Penalty for multiple party channels and commonly used types of scripts. The concept involves batched multi-party loop-in/out and the possibility of creating a new mechanism-within-mechanism layer.The email discusses the concept of transaction cut-through and its relevance to offchain systems. It explains how a transaction can be sent to participants, who can then agree to sign a new state with certain changes. Onchain enforcement can be triggered if there is disagreement. The writer also notes the importance of absolute timelocks in contracts and the need for transactions to be signed under 'SIGHASH_NOINPUT' in the offchain update mechanism. The Poon-Dryja system is considered straightforward to implement, while Decker-Russell-Osuntokun is praised as cool.The recently published proof-of-concept of eltoo on signet prompts a discussion on how to build this system. The clean separation of protocol layers provided by eltoo is seen as beneficial for simplifying reasoning and building more complex functionality. The update mechanism in eltoo does not complicate other layers like the penalty update mechanism does, allowing for focused development. Christian suggests using transactions as a means to represent off-chain negotiations and applying them to the off-chain state via cut-through. This approach offers advantages such as reusing existing tools and facilitating experimentation. Overall, Christian believes that eltoo enables the creation of a nicely layered protocol stack that improves flexibility and simplifies security reasoning. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_Taproot-proposal.xml b/static/bitcoin-dev/Sept_2019/combined_Taproot-proposal.xml index 81198c47fd..594527bf6b 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Taproot-proposal.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Taproot-proposal.xml @@ -1,80 +1,107 @@ - + 2 Combined summary - Taproot proposal - 2023-08-02T00:47:13.477592+00:00 - - Pieter Wuille 2019-09-18 21:21:56+00:00 - - - ZmnSCPxj 2019-09-17 04:09:50+00:00 - - - Greg Sanders 2019-09-16 16:18:35+00:00 - - - Pieter Wuille 2019-08-09 18:29:55+00:00 - - - Elichai Turkel 2019-08-09 14:58:58+00:00 - - - Russell O'Connor 2019-06-28 11:16:46+00:00 - - - Anthony Towns 2019-06-28 09:49:37+00:00 - - - Russell O'Connor 2019-06-27 00:08:01+00:00 - - - Russell O'Connor 2019-05-23 02:32:26+00:00 - - - Pieter Wuille 2019-05-23 02:06:42+00:00 - - - John Newbery 2019-05-22 14:14:44+00:00 - - - Russell O'Connor 2019-05-21 17:20:32+00:00 - - - ZmnSCPxj 2019-05-18 17:51:16+00:00 - - - ZmnSCPxj 2019-05-10 05:38:52+00:00 - - - Johnson Lau 2019-05-09 16:56:57+00:00 - - - Pieter Wuille 2019-05-08 23:06:51+00:00 - - - Luke Dashjr 2019-05-08 13:10:17+00:00 - - - ZmnSCPxj 2019-05-08 05:16:03+00:00 - - - Anthony Towns 2019-05-08 04:49:28+00:00 - - - ZmnSCPxj 2019-05-08 04:37:37+00:00 - - - ZmnSCPxj 2019-05-08 03:44:29+00:00 - - - Sjors Provoost 2019-05-07 20:42:58+00:00 - - - Luke Dashjr 2019-05-06 20:17:09+00:00 - - - Pieter Wuille 2019-05-06 17:57:57+00:00 - + 2025-09-26T15:38:54.624846+00:00 + python-feedgen + + + [bitcoin-dev] Taproot proposal Pieter Wuille + 2019-05-06T17:57:00.000Z + + + Luke Dashjr + 2019-05-06T20:17:00.000Z + + + Sjors Provoost + 2019-05-07T20:42:00.000Z + + + ZmnSCPxj + 2019-05-08T03:44:00.000Z + + + ZmnSCPxj + 2019-05-08T04:37:00.000Z + + + Anthony Towns + 2019-05-08T04:49:00.000Z + + + ZmnSCPxj + 2019-05-08T05:16:00.000Z + + + Luke Dashjr + 2019-05-08T13:10:00.000Z + + + Pieter Wuille + 2019-05-08T23:06:00.000Z + + + Johnson Lau + 2019-05-09T16:56:00.000Z + + + ZmnSCPxj + 2019-05-10T05:38:00.000Z + + + ZmnSCPxj + 2019-05-18T17:51:00.000Z + + + Russell O'Connor + 2019-05-21T17:20:00.000Z + + + John Newbery + 2019-05-22T14:14:00.000Z + + + Pieter Wuille + 2019-05-23T02:06:00.000Z + + + Russell O'Connor + 2019-05-23T02:32:00.000Z + + + Russell O'Connor + 2019-06-27T00:08:00.000Z + + + Anthony Towns + 2019-06-28T09:49:00.000Z + + + Russell O'Connor + 2019-06-28T11:16:00.000Z + + + Elichai Turkel + 2019-08-09T14:58:00.000Z + + + Pieter Wuille + 2019-08-09T18:29:00.000Z + + + Greg Sanders + 2019-09-16T16:18:00.000Z + + + ZmnSCPxj + 2019-09-17T04:09:00.000Z + + + Pieter Wuille + 2019-09-18T21:21:00.000Z + + @@ -99,13 +126,13 @@ - python-feedgen + 2 Combined summary - Taproot proposal - 2023-08-02T00:47:13.477592+00:00 + 2025-09-26T15:38:54.627367+00:00 - Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown. This technique offers improved privacy and can be useful for setting up Pedersen commitments.Another topic of conversation revolves around signing an additional 2019-09-18T21:21:56+00:00 + Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown. This technique offers improved privacy and can be useful for setting up Pedersen commitments.Another topic of conversation revolves around signing an additional - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_Timelocks-and-Lightning-on-MimbleWimble.xml b/static/bitcoin-dev/Sept_2019/combined_Timelocks-and-Lightning-on-MimbleWimble.xml index d14957af41..35ee6d3447 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Timelocks-and-Lightning-on-MimbleWimble.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Timelocks-and-Lightning-on-MimbleWimble.xml @@ -1,32 +1,43 @@ - + 2 Combined summary - Timelocks and Lightning on MimbleWimble - 2023-08-02T01:21:16.863413+00:00 - - Andrew Poelstra 2019-09-20 12:22:20+00:00 - - - ZmnSCPxj 2019-09-20 05:14:59+00:00 - - - Lloyd Fournier 2019-09-19 18:54:34+00:00 - - - John Tromp 2019-09-19 15:47:12+00:00 - - - ZmnSCPxj 2019-09-19 15:15:00+00:00 - - - John Tromp 2019-09-19 11:16:36+00:00 - - - Martin Schwarz 2019-09-19 08:39:00+00:00 - - - ZmnSCPxj 2019-09-19 07:52:11+00:00 - + 2025-09-26T15:39:07.290262+00:00 + python-feedgen + + + [bitcoin-dev] Timelocks and Lightning on MimbleWimble ZmnSCPxj + 2019-09-19T07:52:00.000Z + + + Martin Schwarz + 2019-09-19T08:39:00.000Z + + + John Tromp + 2019-09-19T11:16:00.000Z + + + ZmnSCPxj + 2019-09-19T15:15:00.000Z + + + John Tromp + 2019-09-19T15:47:00.000Z + + + Lloyd Fournier + 2019-09-19T18:54:00.000Z + + + ZmnSCPxj + 2019-09-20T05:14:00.000Z + + + Andrew Poelstra + 2019-09-20T12:22:00.000Z + + @@ -35,13 +46,13 @@ - python-feedgen + 2 Combined summary - Timelocks and Lightning on MimbleWimble - 2023-08-02T01:21:16.863413+00:00 + 2025-09-26T15:39:07.291193+00:00 - In a recent discussion on Bitcoin development, various aspects of the pre-signed nlocktime transaction double spend technique were explored. It was noted that this technique only works with locktime (absolute time locks) and not with sequence numbers (relative time locks). However, Antoine Riard argued that relative locktimes already function as expected, according to BIP68, and suggested that once Schnorr is implemented, it would be possible to do lightning on Bitcoin without any script. There was also a discussion about the "magic shrinking blockchain" property in implementing relative locktimes. It was observed that this property does not apply to kernels, as all the kernels need to be validated to validate the current UTXO set. It was proposed that if Schnorr-like signatures were used, the signatures and the Pedersen-commitment-to-0 could be aggregated into a single signature and Pedersen-commitment-to-0. However, it was mentioned that sinking signatures or partial aggregation of signatures for absolute-locktime kernels does not seem possible with relative locktime kernels. The Grin "Elder channel" design was discussed as being similar to eltoo but offering some bandwidth savings compared to the Poon-Dryja design.In another post on the bitcoin-dev mailing list, ZmnSCPxj discussed the challenges of implementing Lightning and similar off-chain protocols on MimbleWimble. While MimbleWimble's "magical shrinking blockchain" eliminates the need to validate already-spent outputs, it creates a problem for validating relative locktimes necessary for off-chain updates and indefinite-lifetime channel constructions. ZmnSCPxj suggests that while MimbleWimble supports 2-of-2 with Schnorr and other homomorphic signatures, which can be used to implement HTLC-like constructs and impose relative locktimes using simple nSequence, the lack of OP_CHECKSEQUENCEVERIFY makes enforcing them difficult. Furthermore, the lack of relative locktime in MimbleWimble poses challenges for practical off-chain updateable cryptocurrency systems, as timeout mechanisms are necessary. ZmnSCPxj acknowledges that the inclusion of relative lock heights is possible in MimbleWimble, as demonstrated by Grin and Beam, but notes that this would contribute to blockchain size and affect pruneability. Despite these challenges, ZmnSCPxj believes that a MimbleWimble blockchain can still support offchain updateable cryptocurrency systems.Overall, the lack of relative locktime, rather than the absence of SCRIPT, is identified as the main obstacle preventing Lightning-over-MimbleWimble. The post provides links to relevant proposals and designs related to the incorporation of relative lock heights in MimbleWimble. 2019-09-20T12:22:20+00:00 + In a recent discussion on Bitcoin development, various aspects of the pre-signed nlocktime transaction double spend technique were explored. It was noted that this technique only works with locktime (absolute time locks) and not with sequence numbers (relative time locks). However, Antoine Riard argued that relative locktimes already function as expected, according to BIP68, and suggested that once Schnorr is implemented, it would be possible to do lightning on Bitcoin without any script. There was also a discussion about the "magic shrinking blockchain" property in implementing relative locktimes. It was observed that this property does not apply to kernels, as all the kernels need to be validated to validate the current UTXO set. It was proposed that if Schnorr-like signatures were used, the signatures and the Pedersen-commitment-to-0 could be aggregated into a single signature and Pedersen-commitment-to-0. However, it was mentioned that sinking signatures or partial aggregation of signatures for absolute-locktime kernels does not seem possible with relative locktime kernels. The Grin "Elder channel" design was discussed as being similar to eltoo but offering some bandwidth savings compared to the Poon-Dryja design.In another post on the bitcoin-dev mailing list, ZmnSCPxj discussed the challenges of implementing Lightning and similar off-chain protocols on MimbleWimble. While MimbleWimble's "magical shrinking blockchain" eliminates the need to validate already-spent outputs, it creates a problem for validating relative locktimes necessary for off-chain updates and indefinite-lifetime channel constructions. ZmnSCPxj suggests that while MimbleWimble supports 2-of-2 with Schnorr and other homomorphic signatures, which can be used to implement HTLC-like constructs and impose relative locktimes using simple nSequence, the lack of OP_CHECKSEQUENCEVERIFY makes enforcing them difficult. Furthermore, the lack of relative locktime in MimbleWimble poses challenges for practical off-chain updateable cryptocurrency systems, as timeout mechanisms are necessary. ZmnSCPxj acknowledges that the inclusion of relative lock heights is possible in MimbleWimble, as demonstrated by Grin and Beam, but notes that this would contribute to blockchain size and affect pruneability. Despite these challenges, ZmnSCPxj believes that a MimbleWimble blockchain can still support offchain updateable cryptocurrency systems.Overall, the lack of relative locktime, rather than the absence of SCRIPT, is identified as the main obstacle preventing Lightning-over-MimbleWimble. The post provides links to relevant proposals and designs related to the incorporation of relative lock heights in MimbleWimble. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2019/combined_Transcripts-from-Scaling-Bitcoin-2019.xml b/static/bitcoin-dev/Sept_2019/combined_Transcripts-from-Scaling-Bitcoin-2019.xml index 2227118ece..e03fb2ea84 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Transcripts-from-Scaling-Bitcoin-2019.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Transcripts-from-Scaling-Bitcoin-2019.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Transcripts from Scaling Bitcoin 2019 - 2023-08-02T01:20:58.802384+00:00 - - ZmnSCPxj 2019-09-18 04:33:46+00:00 - - - Bryan Bishop 2019-09-16 14:29:05+00:00 - + 2025-09-26T15:39:11.474390+00:00 + python-feedgen + + + [bitcoin-dev] Transcripts from Scaling Bitcoin 2019 Bryan Bishop + 2019-09-16T14:29:00.000Z + + + ZmnSCPxj + 2019-09-18T04:33:00.000Z + + - python-feedgen + 2 Combined summary - Transcripts from Scaling Bitcoin 2019 - 2023-08-02T01:20:58.802384+00:00 + 2025-09-26T15:39:11.474850+00:00 - The Scaling Bitcoin 2019 Tel Aviv conference provided a wealth of information for bitcoin developers. Bryan Bishop received an email expressing gratitude for the transcripts of talks from the conference. The training materials covered a range of topics including foundation topics, developing Bitcoin Core, Lightning network, and upgrades.In the foundation topics section, discussions focused on bitcoin data structures, blockchain design patterns, hardware wallet design best practices, and privacy concepts. Developers learned about various aspects of Bitcoin Core development in the Developing Bitcoin Core section, such as the bitcoin core functional test framework, debugging bitcoin, rebroadcasting, signet, and wallet architecture. The Lightning Network section covered topics like routing, sphinx and onion routing, and topology.The conference also delved into upgrades related to bitcoin, including accumulators, Taproot, BIP-securethebag, erlay, secure-fountain-architecture, elastic-block-caps, plasma cash, prism, and proof-of-necessary-work. Discussions centered around threshold scriptless scripts, scriptless lotteries, and the progress of zero-knowledge proofs towards trustless snarks. Private information retrieval methods for lightweight clients were explored, as well as scaling oblivious read-write techniques. Additional topics included zerolink-sudoku, txprobe, atomic multi-channel updates, payment channel recovery with seeds, and anonymous atomic locks.Overall, the conference provided valuable insights and knowledge for bitcoin developers. The availability of transcripts for all talks ensured that attendees could refer back to the information presented. With discussions covering foundation topics, Bitcoin Core development, Lightning network, and various upgrades, the conference was beneficial for anyone interested in bitcoin development. 2019-09-18T04:33:46+00:00 + The Scaling Bitcoin 2019 Tel Aviv conference provided a wealth of information for bitcoin developers. Bryan Bishop received an email expressing gratitude for the transcripts of talks from the conference. The training materials covered a range of topics including foundation topics, developing Bitcoin Core, Lightning network, and upgrades.In the foundation topics section, discussions focused on bitcoin data structures, blockchain design patterns, hardware wallet design best practices, and privacy concepts. Developers learned about various aspects of Bitcoin Core development in the Developing Bitcoin Core section, such as the bitcoin core functional test framework, debugging bitcoin, rebroadcasting, signet, and wallet architecture. The Lightning Network section covered topics like routing, sphinx and onion routing, and topology.The conference also delved into upgrades related to bitcoin, including accumulators, Taproot, BIP-securethebag, erlay, secure-fountain-architecture, elastic-block-caps, plasma cash, prism, and proof-of-necessary-work. Discussions centered around threshold scriptless scripts, scriptless lotteries, and the progress of zero-knowledge proofs towards trustless snarks. Private information retrieval methods for lightweight clients were explored, as well as scaling oblivious read-write techniques. Additional topics included zerolink-sudoku, txprobe, atomic multi-channel updates, payment channel recovery with seeds, and anonymous atomic locks.Overall, the conference provided valuable insights and knowledge for bitcoin developers. The availability of transcripts for all talks ensured that attendees could refer back to the information presented. With discussions covering foundation topics, Bitcoin Core development, Lightning network, and various upgrades, the conference was beneficial for anyone interested in bitcoin development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_A-Replacement-for-RBF-and-CPFP-Non-Destructive-TXID-Dependencies-for-Fee-Sponsoring.xml b/static/bitcoin-dev/Sept_2020/combined_A-Replacement-for-RBF-and-CPFP-Non-Destructive-TXID-Dependencies-for-Fee-Sponsoring.xml index c3a0b42a09..860a4bf400 100644 --- a/static/bitcoin-dev/Sept_2020/combined_A-Replacement-for-RBF-and-CPFP-Non-Destructive-TXID-Dependencies-for-Fee-Sponsoring.xml +++ b/static/bitcoin-dev/Sept_2020/combined_A-Replacement-for-RBF-and-CPFP-Non-Destructive-TXID-Dependencies-for-Fee-Sponsoring.xml @@ -1,65 +1,87 @@ - + 2 Combined summary - A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring - 2023-08-02T02:40:53.369506+00:00 - - Dmitry Petukhov 2020-09-24 04:22:56+00:00 - - - Jeremy 2020-09-23 22:10:22+00:00 - - - Suhas Daftuar 2020-09-22 18:05:13+00:00 - - - Antoine Riard 2020-09-22 13:52:55+00:00 - - - ArmchairCryptologist 2020-09-22 06:24:40+00:00 - - - Antoine Riard 2020-09-21 23:40:44+00:00 - - - Jeremy 2020-09-21 16:27:09+00:00 - - - David A. Harding 2020-09-21 14:52:21+00:00 - - - Antoine Riard 2020-09-20 23:10:23+00:00 - - - Jeremy 2020-09-19 19:46:25+00:00 - - - Antoine Riard 2020-09-19 19:13:56+00:00 - - - Antoine Riard 2020-09-19 18:39:41+00:00 - - - David A. Harding 2020-09-19 17:24:17+00:00 - - - Jeremy 2020-09-19 16:30:56+00:00 - - - Jeremy 2020-09-19 16:16:25+00:00 - - - nopara73 2020-09-19 15:01:07+00:00 - - - David A. Harding 2020-09-19 13:37:16+00:00 - - - Cory Fields 2020-09-19 01:39:16+00:00 - - - Jeremy 2020-09-19 00:51:39+00:00 - + 2025-09-26T15:32:33.453718+00:00 + python-feedgen + + + [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring Jeremy + 2020-09-19T00:51:00.000Z + + + Cory Fields + 2020-09-19T01:39:00.000Z + + + David A. Harding + 2020-09-19T13:37:00.000Z + + + nopara73 + 2020-09-19T15:01:00.000Z + + + Jeremy + 2020-09-19T16:16:00.000Z + + + Jeremy + 2020-09-19T16:30:00.000Z + + + David A. Harding + 2020-09-19T17:24:00.000Z + + + Antoine Riard + 2020-09-19T18:39:00.000Z + + + Antoine Riard + 2020-09-19T19:13:00.000Z + + + Jeremy + 2020-09-19T19:46:00.000Z + + + Antoine Riard + 2020-09-20T23:10:00.000Z + + + David A. Harding + 2020-09-21T14:52:00.000Z + + + Jeremy + 2020-09-21T16:27:00.000Z + + + Antoine Riard + 2020-09-21T23:40:00.000Z + + + ArmchairCryptologist + 2020-09-22T06:24:00.000Z + + + Antoine Riard + 2020-09-22T13:52:00.000Z + + + Suhas Daftuar + 2020-09-22T18:05:00.000Z + + + Jeremy + 2020-09-23T22:10:00.000Z + + + Dmitry Petukhov + 2020-09-24T04:22:00.000Z + + @@ -79,13 +101,13 @@ - python-feedgen + 2 Combined summary - A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring - 2023-08-02T02:40:53.369506+00:00 + 2025-09-26T15:32:33.456119+00:00 - The email thread discusses a proposed change to Bitcoin's transaction relay rules that introduces an "inverse timelock" mechanism for sponsor transactions. These sponsor transactions can be pre-signed and used to sponsor other transactions within the last 100 blocks, but after 100 blocks, the sponsor transaction becomes invalid. This proposal has raised skepticism as it goes against the principle that once a transaction is valid, it should not become invalid later. The author suggests improving the current policy rules for Child-Pays-for-Parent (CPFP) as an alternative to introducing a consensus change.There are discussions about the limitations and challenges of CPFP-based protocols, including chain bloat issues and difficulties with recursive use. The author suggests that emulating the behavior of sponsors in a transaction graph could be a viable alternative. However, they also acknowledge that a consensus change for sponsor transactions would be more robust and fixable in case of new attacks. They suggest implementing limitations and restrictions to mitigate concerns about pinning and recursive behavior.The conversation also addresses the issue of feerate in multi-party protocols using pre-signed transactions. There are concerns that the feerate may change between creation and broadcast, causing problems if the feerate is too low for the transaction to propagate across network mempools. The suggestion is made to evaluate the feerate of the entire package of transactions as a whole to ensure acceptance by the network. Concerns are also raised about low fee sponsored transactions being evicted from mempools due to fee pressure. The requirement that the sponsor's entry must be present in the mempool is seen as creating a catch-22 situation, and the suggestion is made to revise this requirement while still allowing Replace-by-Fee (RBF) to work.The discussion also touches on the issue of concurrent states being pinned in a sponsor mechanism. It is suggested to change the sponsor vectors to point to input outpoints instead of transaction IDs to address this issue. The conversation highlights the need to consider feerate and package relay in solving pinning issues, as well as the challenges and potential solutions related to malleability and protocol flexibility.A draft proposal has been shared with Bitcoin Devs for a mechanism to replace Child Pays For Parent (CPFP) and Replace By Fee (RBF) for increasing fees on transactions in the mempool. The proposal aims to create a fully abstracted primitive that requires no special structure from an underlying transaction to increase fees and confirm transactions. However, there are concerns about creatively combining vectors to provoke mempool partitions. A further softfork proposal regarding sighash malleability is required for the security semantic for Lightning type of protocols. The proposal suggests a general-purpose mechanism for expressing non-destructive dependencies on specific transactions that can be used to sponsor fees of remote transactions.The proposal restricts the mempool policy to ensure a subset of behavior sufficient to replace CPFP and RBF for fee bumping. The final output of a transaction is used as a location to attach metadata for transaction validation. In addition, a new feature has been introduced in the Bitcoin mempool that allows third-party fees to be attached to arbitrary transactions. There are limitations imposed on the Sponsor Vector to prevent garbage sponsors.Future policy work may involve inserting sponsors into a special sponsor pool with an eviction policy to track low fee transactions that cannot enter the mempool initially. A reference implementation demonstrating these rules is available but has not been audited for correctness.In a separate email conversation, concerns about potential attacks using the Bitcoin mempool pinning mechanism are raised. Two policies are suggested to prevent such attacks: restricting the size of sponsoring transactions or limiting the number of inputs and outputs in a sponsoring transaction. The conversation also discusses the implementation in the Bitcoin reference implementation and suggests policies to eliminate certain attacks.Another conversation addresses questions about the impact of implementing RBF/CPFP on Bitcoin transaction privacy. The speaker believes that there are reasons why it wouldn't worsen privacy and highlights the benefits of using RBF/CPFP.Overall, the proposed mechanism aims to replace CPFP and RBF for fee bumping in Bitcoin transactions. It provides a general specification for inter-transaction dependencies and restricts the mempool policy while allowing third parties to attach fees to arbitrary transactions. 2020-09-24T04:22:56+00:00 + The email thread discusses a proposed change to Bitcoin's transaction relay rules that introduces an "inverse timelock" mechanism for sponsor transactions. These sponsor transactions can be pre-signed and used to sponsor other transactions within the last 100 blocks, but after 100 blocks, the sponsor transaction becomes invalid. This proposal has raised skepticism as it goes against the principle that once a transaction is valid, it should not become invalid later. The author suggests improving the current policy rules for Child-Pays-for-Parent (CPFP) as an alternative to introducing a consensus change.There are discussions about the limitations and challenges of CPFP-based protocols, including chain bloat issues and difficulties with recursive use. The author suggests that emulating the behavior of sponsors in a transaction graph could be a viable alternative. However, they also acknowledge that a consensus change for sponsor transactions would be more robust and fixable in case of new attacks. They suggest implementing limitations and restrictions to mitigate concerns about pinning and recursive behavior.The conversation also addresses the issue of feerate in multi-party protocols using pre-signed transactions. There are concerns that the feerate may change between creation and broadcast, causing problems if the feerate is too low for the transaction to propagate across network mempools. The suggestion is made to evaluate the feerate of the entire package of transactions as a whole to ensure acceptance by the network. Concerns are also raised about low fee sponsored transactions being evicted from mempools due to fee pressure. The requirement that the sponsor's entry must be present in the mempool is seen as creating a catch-22 situation, and the suggestion is made to revise this requirement while still allowing Replace-by-Fee (RBF) to work.The discussion also touches on the issue of concurrent states being pinned in a sponsor mechanism. It is suggested to change the sponsor vectors to point to input outpoints instead of transaction IDs to address this issue. The conversation highlights the need to consider feerate and package relay in solving pinning issues, as well as the challenges and potential solutions related to malleability and protocol flexibility.A draft proposal has been shared with Bitcoin Devs for a mechanism to replace Child Pays For Parent (CPFP) and Replace By Fee (RBF) for increasing fees on transactions in the mempool. The proposal aims to create a fully abstracted primitive that requires no special structure from an underlying transaction to increase fees and confirm transactions. However, there are concerns about creatively combining vectors to provoke mempool partitions. A further softfork proposal regarding sighash malleability is required for the security semantic for Lightning type of protocols. The proposal suggests a general-purpose mechanism for expressing non-destructive dependencies on specific transactions that can be used to sponsor fees of remote transactions.The proposal restricts the mempool policy to ensure a subset of behavior sufficient to replace CPFP and RBF for fee bumping. The final output of a transaction is used as a location to attach metadata for transaction validation. In addition, a new feature has been introduced in the Bitcoin mempool that allows third-party fees to be attached to arbitrary transactions. There are limitations imposed on the Sponsor Vector to prevent garbage sponsors.Future policy work may involve inserting sponsors into a special sponsor pool with an eviction policy to track low fee transactions that cannot enter the mempool initially. A reference implementation demonstrating these rules is available but has not been audited for correctness.In a separate email conversation, concerns about potential attacks using the Bitcoin mempool pinning mechanism are raised. Two policies are suggested to prevent such attacks: restricting the size of sponsoring transactions or limiting the number of inputs and outputs in a sponsoring transaction. The conversation also discusses the implementation in the Bitcoin reference implementation and suggests policies to eliminate certain attacks.Another conversation addresses questions about the impact of implementing RBF/CPFP on Bitcoin transaction privacy. The speaker believes that there are reasons why it wouldn't worsen privacy and highlights the benefits of using RBF/CPFP.Overall, the proposed mechanism aims to replace CPFP and RBF for fee bumping in Bitcoin transactions. It provides a general specification for inter-transaction dependencies and restricts the mempool policy while allowing third parties to attach fees to arbitrary transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml b/static/bitcoin-dev/Sept_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml index 7be2120d05..851807aa1e 100644 --- a/static/bitcoin-dev/Sept_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml +++ b/static/bitcoin-dev/Sept_2020/combined_BIP-OP-CHECKTEMPLATEVERIFY.xml @@ -1,53 +1,55 @@ - + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.880650+00:00 - - Jeremy 2020-09-03 17:47:35+00:00 - - - Jeremy 2020-09-03 17:34:15+00:00 - - - Dmitry Petukhov 2020-09-03 14:42:23+00:00 - - - Dmitry Petukhov 2020-06-08 06:05:45+00:00 - - - Jeremy 2020-06-07 22:45:16+00:00 - - - Joachim Strömbergson 2020-06-07 16:51:10+00:00 - - - ZmnSCPxj 2020-02-15 00:24:37+00:00 - - - Jeremy 2020-02-14 19:16:26+00:00 - - - Dmitry Petukhov 2020-02-14 11:18:26+00:00 - - - Jeremy 2019-12-19 20:08:03+00:00 - - - Jeremy 2019-12-13 23:06:59+00:00 - - - Jeremy 2019-12-11 00:37:59+00:00 - - - Jeremy 2019-11-28 19:59:42+00:00 - - - Russell O'Connor 2019-11-27 21:32:51+00:00 - - - Jeremy 2019-11-26 01:50:40+00:00 - + 2025-09-26T15:32:31.331302+00:00 + python-feedgen + + + Dmitry Petukhov + 2020-02-14T11:18:00.000Z + + + Jeremy + 2020-02-14T19:16:00.000Z + + + ZmnSCPxj + 2020-02-15T00:24:00.000Z + + + Joachim Strömbergson + 2020-06-07T16:51:00.000Z + + + Jeremy + 2020-06-07T22:45:00.000Z + + + Dmitry Petukhov + 2020-06-08T06:05:00.000Z + + + [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation Jeremy + 2020-06-08T06:43:00.000Z + + + Dmitry Petukhov + 2020-06-08T07:15:00.000Z + + + Dmitry Petukhov + 2020-09-03T14:42:00.000Z + + + Jeremy + 2020-09-03T17:34:00.000Z + + + Jeremy + 2020-09-03T17:47:00.000Z + + @@ -63,13 +65,13 @@ - python-feedgen + 2 Combined summary - BIP OP_CHECKTEMPLATEVERIFY - 2023-08-02T01:36:12.881652+00:00 + 2025-09-26T15:32:31.332686+00:00 - In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast 2020-09-03T17:47:35+00:00 + In a discussion between Jeremy Rubin and Dmitry Petukhov, the concept of an "inverse timelock" was explored. The idea involves a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it can only be spent along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the revocation UTXO is spent, the covenant path that commits to having it in the inputs becomes unspendable, constituting an "inverse timelock." CTV does not enable this because it does not commit to the inputs, leading to a hash cycle for predicting the output's TXID. However, setting up this scheme requires an ordering around when the tx intended to be the inverse lock is set up before creating the tx using it.On September 3, 2020, Dmitry Petukhov proposed an idea for an "inverse timelock" that could be made almost-certainly automatic. This would involve a revocation UTXO becoming anyone-can-spend after a timeout and bearing some non-dust amount. Before the timelock expiration, it would only be spendable along with the covenant-locked 'main' UTXO via a signature or mutual covenant. After the timeout expires, a multitude of entities would be incentivized to spend this UTXO because it would be free money for them. It would likely be spent by a miner who could replace the spending transaction with their own and claim the amount. Once the revocation UTXO is spent, the covenant path that commits to having it in the inputs would become unspendable, effectively constituting an "inverse timelock."However, CTV does not enable this because it does not commit to the inputs. Otherwise, there would be a hash cycle for predicting the output's TXID.The context discusses a proposed feature called "inverse timelock" that incentivizes spending a revocation UTXO after a timeout, making it unspendable. This feature has potential use cases in various covenant schemes like trustless lending and access-revocable vaults. The ability to commit to scriptSig of a non-segwit input could also be used for on-chain control of spending authorization, effectively revoking the ability to spend a certain input via CTV path, and alternate spending paths should be used.The implications of this feature on Bitcoin's behavior during reorgs were discussed, with some arguing that new rules violating certain principles should be introduced cautiously. A draft of changes for CTV was prepared but has not been updated yet, leaving time for further feedback.A member of the bitcoin-dev group, Jeremy, proposed a new way to contribute fees to another transaction chain as an observer. This method can help solve issues related to application-DoS attacks beyond child-pays-for-parent (CTV). He has a design for this idea but is not ready to share it yet. Another member suggested the 'Pay for neighbor' (PFN) transaction, where a transaction that is not directly a child of another transaction can pay fees for other transactions. It would be like a "ghost child" transaction and could only be mined after its "ghost parents" are confirmed. The PFN transaction would require a hard fork, but Anthony Towns suggested making it a soft fork by putting the txids of the ghost parents into taproot annex. If some of the ghost parents are confirmed, the miners can get more fees than necessary, similar to CPFP. The mempool code needs to adjust the relationships between parent/child transactions for this ghost relationship idea. However, there could be complications regarding the transaction package size, which requires further analysis.Recently, there have been some refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY and the name has been changed. The opcode specification has also been changed to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead. It permits future soft-fork updates to loosen or remove "constexpr" restrictions. RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. In terms of today's scenario, exchanges can do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. Exchanges pay reasonable fees for the transactions so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Business wallets (like exchanges) are able to credit deposits from CTV trees without requiring full expansion. For long-dated futures, most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis and mempool broadcast - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_Default-Signet-Custom-Signets-and-Resetting-Testnet.xml b/static/bitcoin-dev/Sept_2020/combined_Default-Signet-Custom-Signets-and-Resetting-Testnet.xml index becacf5d27..11334ff89a 100644 --- a/static/bitcoin-dev/Sept_2020/combined_Default-Signet-Custom-Signets-and-Resetting-Testnet.xml +++ b/static/bitcoin-dev/Sept_2020/combined_Default-Signet-Custom-Signets-and-Resetting-Testnet.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Default Signet, Custom Signets and Resetting Testnet - 2023-08-02T02:38:56.976981+00:00 - - Matt Corallo 2020-09-14 02:11:32+00:00 - - - Michael Folkson 2020-08-29 10:14:50+00:00 - + 2025-09-26T15:32:27.069821+00:00 + python-feedgen + + + [bitcoin-dev] Default Signet, Custom Signets and Resetting Testnet Michael Folkson + 2020-08-29T10:14:00.000Z + + + Matt Corallo + 2020-09-14T02:11:00.000Z + + - python-feedgen + 2 Combined summary - Default Signet, Custom Signets and Resetting Testnet - 2023-08-02T02:38:56.976981+00:00 + 2025-09-26T15:32:27.070320+00:00 - The Bitcoin Core has announced that Signet PR 18267 is now in an advanced stage of review, and they are encouraging additional code review and testing. However, there are some meta questions surrounding Signets that need to be discussed outside of the Bitcoin Core repo to ensure that everyone's testing needs are being met.The first question raised is whether there should be one "default" Signet for specific purposes or if multiple custom Signets should exist. The argument for a "default" Signet with a network effect is that it would provide a staging ground for testing proposed soft forks and prevent splintered Signet networks with different combinations of proposed soft forks enabled. However, there would have to be a formal understanding of at what stage a proposed soft fork should be enabled on the "default" Signet. This could present challenges if soft forks are enabled and then change or get updated.The second question raised is who should have keys to sign each new block on the "default" Signet assuming it exists. Currently, it is a 1-of-2 multisig with Kalle Alm and AJ Towns having keys. However, it was suggested on IRC that there should be at least one additional key present in the EU/US timezone so blocks can continue to be mined during an Asia-Pacific outage.The third question raised is regarding concerns from some in the community that testnet will be replaced by Signet. Michael Folkson assures that testnet will continue as long as someone out there is mining testnet blocks. However, there is a question of whether testnet needs to be reset since it was last reset in 2012. Assuming Signet is successful, there will be less testing on testnet, but certain testing use cases will still prefer testnet. It has been argued that testnet should be a large chain to stress test certain scenarios, and in that case, we may not want to reset testnet.Michael encourages thoughts, feedback, and questions from the Bitcoin community to ensure that everyone's testing needs are being considered. While there is a closed issue on the Bitcoin Core repo for prior conversation, it is ideal for discussions outside of Bitcoin Core to take place on the mailing list or on IRC. 2020-09-14T02:11:32+00:00 + The Bitcoin Core has announced that Signet PR 18267 is now in an advanced stage of review, and they are encouraging additional code review and testing. However, there are some meta questions surrounding Signets that need to be discussed outside of the Bitcoin Core repo to ensure that everyone's testing needs are being met.The first question raised is whether there should be one "default" Signet for specific purposes or if multiple custom Signets should exist. The argument for a "default" Signet with a network effect is that it would provide a staging ground for testing proposed soft forks and prevent splintered Signet networks with different combinations of proposed soft forks enabled. However, there would have to be a formal understanding of at what stage a proposed soft fork should be enabled on the "default" Signet. This could present challenges if soft forks are enabled and then change or get updated.The second question raised is who should have keys to sign each new block on the "default" Signet assuming it exists. Currently, it is a 1-of-2 multisig with Kalle Alm and AJ Towns having keys. However, it was suggested on IRC that there should be at least one additional key present in the EU/US timezone so blocks can continue to be mined during an Asia-Pacific outage.The third question raised is regarding concerns from some in the community that testnet will be replaced by Signet. Michael Folkson assures that testnet will continue as long as someone out there is mining testnet blocks. However, there is a question of whether testnet needs to be reset since it was last reset in 2012. Assuming Signet is successful, there will be less testing on testnet, but certain testing use cases will still prefer testnet. It has been argued that testnet should be a large chain to stress test certain scenarios, and in that case, we may not want to reset testnet.Michael encourages thoughts, feedback, and questions from the Bitcoin community to ensure that everyone's testing needs are being considered. While there is a closed issue on the Bitcoin Core repo for prior conversation, it is ideal for discussions outside of Bitcoin Core to take place on the mailing list or on IRC. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap.xml b/static/bitcoin-dev/Sept_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap.xml index 782006aa61..02644b0b82 100644 --- a/static/bitcoin-dev/Sept_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap.xml +++ b/static/bitcoin-dev/Sept_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap.xml @@ -1,74 +1,107 @@ - + 2 Combined summary - Detailed protocol design for routed multi-transaction CoinSwap - 2023-08-02T02:33:40.925726+00:00 - - seid Mohammed 2020-09-06 03:06:52+00:00 - - - ZmnSCPxj 2020-09-05 02:45:00+00:00 - - - ZmnSCPxj 2020-09-05 02:29:18+00:00 - - - Antoine Riard 2020-09-05 01:10:36+00:00 - - - Antoine Riard 2020-09-05 01:07:15+00:00 - - - ZmnSCPxj 2020-09-03 23:39:02+00:00 - - - Chris Belcher 2020-09-03 10:50:57+00:00 - - - ZmnSCPxj 2020-09-03 09:45:53+00:00 - - - Chris Belcher 2020-09-03 09:00:00+00:00 - - - ZmnSCPxj 2020-08-30 13:38:11+00:00 - - - Chris Belcher 2020-08-29 22:03:09+00:00 - - - ZmnSCPxj 2020-08-25 03:16:05+00:00 - - - Antoine Riard 2020-08-24 19:30:05+00:00 - - - ZmnSCPxj 2020-08-22 01:09:35+00:00 - - - Chris Belcher 2020-08-21 09:47:31+00:00 - - - ZmnSCPxj 2020-08-21 04:20:23+00:00 - - - Chris Belcher 2020-08-20 22:37:35+00:00 - - - Chris Belcher 2020-08-20 22:15:34+00:00 - - - ZmnSCPxj 2020-08-20 21:38:16+00:00 - - - Nadav Kohen 2020-08-20 15:28:56+00:00 - - - ZmnSCPxj 2020-08-20 11:17:07+00:00 - - - Chris Belcher 2020-08-11 12:05:57+00:00 - + 2025-09-26T15:32:35.633008+00:00 + python-feedgen + + + [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap Chris Belcher + 2020-08-11T12:05:00.000Z + + + ZmnSCPxj + 2020-08-20T11:17:00.000Z + + + Nadav Kohen + 2020-08-20T15:28:00.000Z + + + ZmnSCPxj + 2020-08-20T21:38:00.000Z + + + Chris Belcher + 2020-08-20T22:15:00.000Z + + + Chris Belcher + 2020-08-20T22:37:00.000Z + + + ZmnSCPxj + 2020-08-21T04:20:00.000Z + + + Chris Belcher + 2020-08-21T09:47:00.000Z + + + ZmnSCPxj + 2020-08-22T01:09:00.000Z + + + Antoine Riard + 2020-08-24T19:30:00.000Z + + + ZmnSCPxj + 2020-08-25T03:16:00.000Z + + + Chris Belcher + 2020-08-29T22:03:00.000Z + + + ZmnSCPxj + 2020-08-30T13:38:00.000Z + + + Chris Belcher + 2020-09-03T09:00:00.000Z + + + ZmnSCPxj + 2020-09-03T09:45:00.000Z + + + Chris Belcher + 2020-09-03T10:50:00.000Z + + + ZmnSCPxj + 2020-09-03T23:39:00.000Z + + + Antoine Riard + 2020-09-05T01:07:00.000Z + + + Antoine Riard + 2020-09-05T01:10:00.000Z + + + ZmnSCPxj + 2020-09-05T02:29:00.000Z + + + ZmnSCPxj + 2020-09-05T02:45:00.000Z + + + seid Mohammed + 2020-09-06T03:06:00.000Z + + + [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium Chris Belcher + 2020-10-03T10:36:00.000Z + + + ZmnSCPxj + 2020-10-03T13:31:00.000Z + + @@ -91,13 +124,13 @@ - python-feedgen + 2 Combined summary - Detailed protocol design for routed multi-transaction CoinSwap - 2023-08-02T02:33:40.926761+00:00 + 2025-09-26T15:32:35.635760+00:00 - to create multisig addresses, and funds were locked into these addresses. Contract transactions were created to transfer funds using timelocks or hash preimage values. Various vulnerabilities in the protocol were identified, such as fee model vulnerability and transaction pinning vulnerability. Proposed solutions included using anchor outputs in contract transactions and separating timelock and hashlock cases into separate transactions. The implementation of CoinSwap involved broadcasting and mining contract transactions, waiting for timeouts, and using hash preimage values to retrieve funds. Parties paid their own miner fees in timeout failure cases, and anti-DOS features were implemented to prevent attacks.The email exchanges also discussed the usage of relative and absolute locktimes in contract transactions with Scriptless Script, specifically Pointlock transactions. Absolute locktimes allowed participants to define their fee ranges without negotiation. Private key turnover was suggested to reduce funding lockup time for multi-hop swaps, and diagrams were provided to illustrate different scenarios.The CoinSwap protocol aimed to improve privacy by allowing users to swap Bitcoin without revealing amounts or addresses. Multiple transactions were used in a single CoinSwap to avoid amount correlation. Makers only knew their previous and next transactions, while the taker knew the entire route. Funding transactions paid into 2-of-2 multisig addresses, and contract transactions transferred coins to a contract that could be spent with timelocks or hash preimage values. Vulnerabilities such as pinning scenarios and theft attempts were addressed through various solutions, including watchtowers to guard CoinSwaps and prevent theft attempts.The implementation of CoinSwap for privacy and fungibility was being worked on by Chris Belcher. The protocol included multi-transaction CoinSwaps, routed CoinSwaps, liquidity markets, private key handover, and fidelity bonds. Contract transactions played a crucial role, and vulnerabilities and proposed solutions were discussed. Absolute timelocks, watchtowers, and split UTXOs were proposed to enhance the protocol. Relative timelocks, DOS-resistance, and deviations from the protocol were also addressed.In an email exchange between Nadav and ZmnSCPxj, concerns about the security of a proposed public key scheme for Bitcoin transactions were discussed. The main concern was the potential for the taker to steal funds by manipulating the nonce point used in the transaction. ZmnSCPxj clarified that the taker must provide the actual value of the nonce to the maker, eliminating the need for the maker to trust the taker's calculations. The discussion then shifted towards the use of 2p-ECDSA for privacy protection in CoinSwap transactions. While ZmnSCPxj argued that using OP_CHECKMULTISIG instead of 2p-ECDSA would remove most of the privacy advantages, he acknowledged the possibility of implementing OP_CHECKMULTISIG first and adding 2p-ECDSA later. Nadav agreed but emphasized the significant privacy benefits of singlesig anonymity sets.The implementation of CoinSwap involved two parties, the taker and maker, exchanging coins through atomic cross-chain trading. The protocol started with the taker broadcasting a funding transaction to a 2-of-2 multisig address and creating HTLCs specifying amounts and addresses. The maker signed the HTLCs, creating contract transactions that were not broadcast but exchanged between the parties. The EC tweak trick could be used to reduce round trips required for agreeing on public keys. Concerns were raised about a possible attack by a malicious taker who intentionally aborts the swap, causing makers to lose more money than the attacker. Parties needed to be prepared to respond to contract transactions at all times, as the outputs of the funding transactions could remain unspent indefinitely.ZmnSCPxj raised concerns about the security of CoinSwap, particularly regarding the taker providing the nonce 'p' to the maker, which could potentially lead to fund theft. He suggested using 2p-ECDSA to address this issue. Additionally, he emphasized the importance of hiding among larger singlesig anonymity sets and discussed the use of HTLCs in open-coded SCRIPTs for increased privacy.Nadav raised concerns about the proposed CoinSwap protocol on the bitcoin-dev mailing list, particularly regarding the generation of signatures for HTLCs from the pubkey used in Bitcoin transactions. He suggested the use of Zero Knowledge Proof of Knowledge (ZKPoK) or a different key implementation like MuSig. The email also explored the advantages of direct connections to Alice over CoinJoin and potential leaks in CoinSwap. Makers having no incentive to pay fees and takers setting limits on maker's transactions were mentioned. Contract transactions that spend from the 2-of-2 multisig outputs were explained, with staggered timelocks to allow for recovery in case of malicious actions. The EC tweak trick was highlighted as a way to reduce one round trip when agreeing on public keys.The email thread provided insights into the proposed CoinSwap protocol and its potential deviations. It highlighted the use of multi-transaction CoinSwaps, routed CoinSwaps, 2020-09-06T03:06:52+00:00 + to create multisig addresses, and funds were locked into these addresses. Contract transactions were created to transfer funds using timelocks or hash preimage values. Various vulnerabilities in the protocol were identified, such as fee model vulnerability and transaction pinning vulnerability. Proposed solutions included using anchor outputs in contract transactions and separating timelock and hashlock cases into separate transactions. The implementation of CoinSwap involved broadcasting and mining contract transactions, waiting for timeouts, and using hash preimage values to retrieve funds. Parties paid their own miner fees in timeout failure cases, and anti-DOS features were implemented to prevent attacks.The email exchanges also discussed the usage of relative and absolute locktimes in contract transactions with Scriptless Script, specifically Pointlock transactions. Absolute locktimes allowed participants to define their fee ranges without negotiation. Private key turnover was suggested to reduce funding lockup time for multi-hop swaps, and diagrams were provided to illustrate different scenarios.The CoinSwap protocol aimed to improve privacy by allowing users to swap Bitcoin without revealing amounts or addresses. Multiple transactions were used in a single CoinSwap to avoid amount correlation. Makers only knew their previous and next transactions, while the taker knew the entire route. Funding transactions paid into 2-of-2 multisig addresses, and contract transactions transferred coins to a contract that could be spent with timelocks or hash preimage values. Vulnerabilities such as pinning scenarios and theft attempts were addressed through various solutions, including watchtowers to guard CoinSwaps and prevent theft attempts.The implementation of CoinSwap for privacy and fungibility was being worked on by Chris Belcher. The protocol included multi-transaction CoinSwaps, routed CoinSwaps, liquidity markets, private key handover, and fidelity bonds. Contract transactions played a crucial role, and vulnerabilities and proposed solutions were discussed. Absolute timelocks, watchtowers, and split UTXOs were proposed to enhance the protocol. Relative timelocks, DOS-resistance, and deviations from the protocol were also addressed.In an email exchange between Nadav and ZmnSCPxj, concerns about the security of a proposed public key scheme for Bitcoin transactions were discussed. The main concern was the potential for the taker to steal funds by manipulating the nonce point used in the transaction. ZmnSCPxj clarified that the taker must provide the actual value of the nonce to the maker, eliminating the need for the maker to trust the taker's calculations. The discussion then shifted towards the use of 2p-ECDSA for privacy protection in CoinSwap transactions. While ZmnSCPxj argued that using OP_CHECKMULTISIG instead of 2p-ECDSA would remove most of the privacy advantages, he acknowledged the possibility of implementing OP_CHECKMULTISIG first and adding 2p-ECDSA later. Nadav agreed but emphasized the significant privacy benefits of singlesig anonymity sets.The implementation of CoinSwap involved two parties, the taker and maker, exchanging coins through atomic cross-chain trading. The protocol started with the taker broadcasting a funding transaction to a 2-of-2 multisig address and creating HTLCs specifying amounts and addresses. The maker signed the HTLCs, creating contract transactions that were not broadcast but exchanged between the parties. The EC tweak trick could be used to reduce round trips required for agreeing on public keys. Concerns were raised about a possible attack by a malicious taker who intentionally aborts the swap, causing makers to lose more money than the attacker. Parties needed to be prepared to respond to contract transactions at all times, as the outputs of the funding transactions could remain unspent indefinitely.ZmnSCPxj raised concerns about the security of CoinSwap, particularly regarding the taker providing the nonce 'p' to the maker, which could potentially lead to fund theft. He suggested using 2p-ECDSA to address this issue. Additionally, he emphasized the importance of hiding among larger singlesig anonymity sets and discussed the use of HTLCs in open-coded SCRIPTs for increased privacy.Nadav raised concerns about the proposed CoinSwap protocol on the bitcoin-dev mailing list, particularly regarding the generation of signatures for HTLCs from the pubkey used in Bitcoin transactions. He suggested the use of Zero Knowledge Proof of Knowledge (ZKPoK) or a different key implementation like MuSig. The email also explored the advantages of direct connections to Alice over CoinJoin and potential leaks in CoinSwap. Makers having no incentive to pay fees and takers setting limits on maker's transactions were mentioned. Contract transactions that spend from the 2-of-2 multisig outputs were explained, with staggered timelocks to allow for recovery in case of malicious actions. The EC tweak trick was highlighted as a way to reduce one round trip when agreeing on public keys.The email thread provided insights into the proposed CoinSwap protocol and its potential deviations. It highlighted the use of multi-transaction CoinSwaps, routed CoinSwaps, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_Floating-Point-Nakamoto-Consensus.xml b/static/bitcoin-dev/Sept_2020/combined_Floating-Point-Nakamoto-Consensus.xml index 041694782b..6652548449 100644 --- a/static/bitcoin-dev/Sept_2020/combined_Floating-Point-Nakamoto-Consensus.xml +++ b/static/bitcoin-dev/Sept_2020/combined_Floating-Point-Nakamoto-Consensus.xml @@ -1,77 +1,103 @@ - + 2 Combined summary - Floating-Point Nakamoto Consensus - 2023-08-02T02:42:52.955847+00:00 - - yanmaani at cock.li 2020-10-15 16:02:09+00:00 - - - Mike Brooks 2020-10-10 01:26:07+00:00 - - - Mike Brooks 2020-10-10 00:59:31+00:00 - - - Bob McElrath 2020-10-08 18:43:00+00:00 - - - Mike Brooks 2020-10-04 15:58:58+00:00 - - - Mike Brooks 2020-10-01 19:26:01+00:00 - - - Larry Ruane 2020-10-01 16:42:27+00:00 - - - ZmnSCPxj 2020-10-01 06:47:01+00:00 - - - ZmnSCPxj 2020-10-01 01:36:35+00:00 - - - Mike Brooks 2020-09-30 23:53:25+00:00 - - - ZmnSCPxj 2020-09-30 23:44:59+00:00 - - - Mike Brooks 2020-09-30 06:37:47+00:00 - - - ZmnSCPxj 2020-09-30 06:31:41+00:00 - - - Mike Brooks 2020-09-29 16:00:12+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2020-09-29 03:10:36+00:00 - - - Franck Royer 2020-09-29 01:51:03+00:00 - - - Mike Brooks 2020-09-26 11:09:23+00:00 - - - David A. Harding 2020-09-26 10:11:23+00:00 - - - Mike Brooks 2020-09-25 17:35:36+00:00 - - - Jeremy 2020-09-25 16:33:14+00:00 - - - Mike Brooks 2020-09-25 16:04:11+00:00 - - - bitcoin ml 2020-09-25 15:18:17+00:00 - - - Mike Brooks 2020-09-24 19:40:46+00:00 - + 2025-09-26T15:32:29.211602+00:00 + python-feedgen + + + [bitcoin-dev] Floating-Point Nakamoto Consensus Mike Brooks + 2020-09-24T19:40:00.000Z + + + bitcoin ml + 2020-09-25T15:18:00.000Z + + + Mike Brooks + 2020-09-25T16:04:00.000Z + + + Jeremy + 2020-09-25T16:33:00.000Z + + + Mike Brooks + 2020-09-25T17:35:00.000Z + + + David A. Harding + 2020-09-26T10:11:00.000Z + + + Mike Brooks + 2020-09-26T11:09:00.000Z + + + Franck Royer + 2020-09-29T01:51:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2020-09-29T03:10:00.000Z + + + Mike Brooks + 2020-09-29T16:00:00.000Z + + + ZmnSCPxj + 2020-09-30T06:31:00.000Z + + + Mike Brooks + 2020-09-30T06:37:00.000Z + + + ZmnSCPxj + 2020-09-30T23:44:00.000Z + + + Mike Brooks + 2020-09-30T23:53:00.000Z + + + ZmnSCPxj + 2020-10-01T01:36:00.000Z + + + ZmnSCPxj + 2020-10-01T06:47:00.000Z + + + Larry Ruane + 2020-10-01T16:42:00.000Z + + + Mike Brooks + 2020-10-01T19:26:00.000Z + + + Mike Brooks + 2020-10-04T15:58:00.000Z + + + Bob McElrath + 2020-10-08T18:43:00.000Z + + + Mike Brooks + 2020-10-10T00:59:00.000Z + + + Mike Brooks + 2020-10-10T01:26:00.000Z + + + yanmaani + 2020-10-15T16:02:00.000Z + + @@ -95,13 +121,13 @@ - python-feedgen + 2 Combined summary - Floating-Point Nakamoto Consensus - 2023-08-02T02:42:52.955847+00:00 + 2025-09-26T15:32:29.214233+00:00 - The proposal of Floating-Point Nakamoto Consensus (FPNC) aims to improve the network by avoiding ambiguity and enabling determinism. It assigns floating-point fitness values to blocks, giving miners two valid options when mining a block with high rewards but close fitness to the minimum. Miners can either build on top of that block or replace it, with increasing probability as the block subsidy decreases. While this incentivizes reorgs, the author argues that adding more precision can prevent confusion and allow for immediate decision-making without waiting for chain extensions. The proposal is not related to SegWit but can be implemented in any blockchain using Nakamoto Consensus. A complete implementation of FPNC is available in the provided links.The article discusses vulnerabilities in Nakamoto Consensus and proposes a solution called Floating-Point Nakamoto Consensus. This solution increases the cost of replacing the current winning block, making it harder for adversaries to create a hard fork and disrupt the network. The author emphasizes the need for fully decentralized solutions to Byzantine fault-injection and disagreements. Floating-Point Nakamoto Consensus prevents re-org chains from going beyond a single block, expediting consensus formation. The dominant chain is incentivized, eroding support for weaker chains. The article concludes that any blockchain using Nakamoto Consensus can be modified to use Floating-Point Nakamoto Consensus.In an email thread, Lord James HRMH suggests adding more bits of precision to avoid confusion in selecting the highest-work chain. Waiting for further chain extension may not be necessary if the network can immediately decide based on higher proof of work and greater precision. The email also discusses the threat model of an eclipse attack and how malicious miners can manipulate disagreement in the network. The attacker keeps the disagreement open until their transactions are validated on the honest chain, replacing it with the chain generated by dishonest miners.The article explains how Floating-Point Nakamoto Consensus improves consensus generation by introducing a fitness test. The most recently formed block with the highest local fitness score is preferred, eroding support for weaker chains. A soft fork can be used to implement Floating-Point Nakamoto Consensus, allowing patched and non-patched nodes to coexist. The article concludes that any blockchain using Nakamoto Consensus can be modified to use a fitness constraint like Floating-Point Nakamoto Consensus.The author discusses the use of work and fitness in Bitcoin consensus. Work is an unbiased estimator of computational effort, while fitness introduces bias without additional valuable information. The question of introducing the historic block hash as a consensus-critical parameter is argued against, as it adds unnecessary randomness to chain selection. The author argues that delaying or preempting messages is cheaper than producing better fitness scores, creating a race condition. The article also mentions ongoing malicious mining campaigns and proposes solutions to mitigate them.In an email exchange, Larry Ruane shares his open-source POW network mining simulator that simulates Bitcoin's POW and can be modified for variations. Mike suggests actively pinging nodes running weaker blocks to inform them of new blocks. Larry's project receives praise, and Mike plans to provide a PR. The GitHub link for Larry's project is included.The context of another conversation involves an exploit condition in Bitcoin's network. The speaker responds to Mike's argument, highlighting the unlikelihood of certain conditions and the need for more time before disclosure of exploits. They emphasize the importance of security fundamentals and the risks of change in Bitcoin.In a separate email conversation, ZmnSCPxj raises concerns about growing disagreement in mining capacity and the need to avoid ambiguity in consensus. They discuss an exploit that was reported to the Bitcoin-core security team and cannot be fixed by Floating-Point Nakamoto Consensus. The need for more time before disclosure is highlighted, along with the importance of sensible disclosure policies.Overall, the articles and conversations discuss vulnerabilities in Nakamoto Consensus, propose solutions like Floating-Point Nakamoto Consensus, and address various threat models and exploits in Bitcoin's network. 2020-10-15T16:02:09+00:00 + The proposal of Floating-Point Nakamoto Consensus (FPNC) aims to improve the network by avoiding ambiguity and enabling determinism. It assigns floating-point fitness values to blocks, giving miners two valid options when mining a block with high rewards but close fitness to the minimum. Miners can either build on top of that block or replace it, with increasing probability as the block subsidy decreases. While this incentivizes reorgs, the author argues that adding more precision can prevent confusion and allow for immediate decision-making without waiting for chain extensions. The proposal is not related to SegWit but can be implemented in any blockchain using Nakamoto Consensus. A complete implementation of FPNC is available in the provided links.The article discusses vulnerabilities in Nakamoto Consensus and proposes a solution called Floating-Point Nakamoto Consensus. This solution increases the cost of replacing the current winning block, making it harder for adversaries to create a hard fork and disrupt the network. The author emphasizes the need for fully decentralized solutions to Byzantine fault-injection and disagreements. Floating-Point Nakamoto Consensus prevents re-org chains from going beyond a single block, expediting consensus formation. The dominant chain is incentivized, eroding support for weaker chains. The article concludes that any blockchain using Nakamoto Consensus can be modified to use Floating-Point Nakamoto Consensus.In an email thread, Lord James HRMH suggests adding more bits of precision to avoid confusion in selecting the highest-work chain. Waiting for further chain extension may not be necessary if the network can immediately decide based on higher proof of work and greater precision. The email also discusses the threat model of an eclipse attack and how malicious miners can manipulate disagreement in the network. The attacker keeps the disagreement open until their transactions are validated on the honest chain, replacing it with the chain generated by dishonest miners.The article explains how Floating-Point Nakamoto Consensus improves consensus generation by introducing a fitness test. The most recently formed block with the highest local fitness score is preferred, eroding support for weaker chains. A soft fork can be used to implement Floating-Point Nakamoto Consensus, allowing patched and non-patched nodes to coexist. The article concludes that any blockchain using Nakamoto Consensus can be modified to use a fitness constraint like Floating-Point Nakamoto Consensus.The author discusses the use of work and fitness in Bitcoin consensus. Work is an unbiased estimator of computational effort, while fitness introduces bias without additional valuable information. The question of introducing the historic block hash as a consensus-critical parameter is argued against, as it adds unnecessary randomness to chain selection. The author argues that delaying or preempting messages is cheaper than producing better fitness scores, creating a race condition. The article also mentions ongoing malicious mining campaigns and proposes solutions to mitigate them.In an email exchange, Larry Ruane shares his open-source POW network mining simulator that simulates Bitcoin's POW and can be modified for variations. Mike suggests actively pinging nodes running weaker blocks to inform them of new blocks. Larry's project receives praise, and Mike plans to provide a PR. The GitHub link for Larry's project is included.The context of another conversation involves an exploit condition in Bitcoin's network. The speaker responds to Mike's argument, highlighting the unlikelihood of certain conditions and the need for more time before disclosure of exploits. They emphasize the importance of security fundamentals and the risks of change in Bitcoin.In a separate email conversation, ZmnSCPxj raises concerns about growing disagreement in mining capacity and the need to avoid ambiguity in consensus. They discuss an exploit that was reported to the Bitcoin-core security team and cannot be fixed by Floating-Point Nakamoto Consensus. The need for more time before disclosure is highlighted, along with the importance of sensible disclosure policies.Overall, the articles and conversations discuss vulnerabilities in Nakamoto Consensus, propose solutions like Floating-Point Nakamoto Consensus, and address various threat models and exploits in Bitcoin's network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_Is-BIP32-s-chain-code-needed-.xml b/static/bitcoin-dev/Sept_2020/combined_Is-BIP32-s-chain-code-needed-.xml index a18f993fc4..c2b33ee359 100644 --- a/static/bitcoin-dev/Sept_2020/combined_Is-BIP32-s-chain-code-needed-.xml +++ b/static/bitcoin-dev/Sept_2020/combined_Is-BIP32-s-chain-code-needed-.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Is BIP32's chain code needed? - 2023-08-02T02:44:44.304146+00:00 - - Adam Back 2020-10-17 09:14:59+00:00 - - - Pieter Wuille 2020-10-16 21:41:07+00:00 - - - Christopher Allen 2020-10-05 20:34:48+00:00 - - - Lloyd Fournier 2020-10-05 02:49:48+00:00 - - - Leonardo Comandini 2020-09-29 17:34:28+00:00 - + 2025-09-26T15:32:39.825185+00:00 + python-feedgen + + + [bitcoin-dev] Is BIP32's chain code needed? Leonardo Comandini + 2020-09-29T17:34:00.000Z + + + Lloyd Fournier + 2020-10-05T02:49:00.000Z + + + Christopher Allen + 2020-10-05T20:34:00.000Z + + + Pieter Wuille + 2020-10-16T21:41:00.000Z + + + Adam Back + 2020-10-17T09:14:00.000Z + + - python-feedgen + 2 Combined summary - Is BIP32's chain code needed? - 2023-08-02T02:44:44.304146+00:00 + 2025-09-26T15:32:39.825941+00:00 - In a discussion on the bitcoin-dev mailing list, Leonardo Comandini questions the necessity of the chain code in BIP32. He argues that the additional entropy provided by the chain code is not needed and intends to demonstrate this through a schematic of BIP32 operations. Pieter Wuille, in response, provides historical context on how the chain code ended up being included in BIP32. He explains that BIP32 was inspired by Alan Reiner's Armory software, which had a different key derivation scheme that included a chain code. The chain code allowed for the derivation of multiple "chains" of keys from the same key pair. BIP32 improved upon this by enabling random access into the derived keys and hierarchical derivation with a sub-"chain code" for every subkey.Wuille defends the inclusion of the chain code in BIP32 by stating that xpubs require more protection than public keys alone and that the chain code adds an extra layer of security. Additionally, using a chain code prevents entropy reduction through repeated hashing. However, he acknowledges that from a cryptographic standpoint, the chain code is not necessary and only has practical advantages.The discussion also touches on interoperability and avoiding vendor lock-in. While compromises have been made in the past regarding the amount of entropy used, recent proposals such as SLIP-39 and Lightning Labs' seed mnemonics have raised concerns about interoperability and lock-in issues. The Blockchain Commons and a community of airgapped wallet developers have developed a specification called SSKR, which uses the same seed-to-master key technique as BIP32 to address these concerns.Leonardo Comandini further presents his alternative proposal for key derivation without the chain code. He provides a schematic of BIP32 operations and highlights the advantages of his proposed scheme, including shorter backups for keys and user-friendly backup for child keys. The proposed scheme also allows for mnemonics for subaccount keys. Comandini references various hash functions and provides links to BIP32, BIP39, and a pay-to-contract scheme for more information.Another contributor in the discussion acknowledges that there is no fundamental flaw with Comandini's proposal but admits they haven't spent much time developing wallets.The author of another post argues that the chain code in BIP32 is not necessary and provides a schematic of BIP32 operations to compare with an alternative proposal. The post introduces private and public child derivation formulae, as well as the corresponding chain codes. The post then presents an alternative proposal for derivation without the chain code, using a strong hash function 'h' to convert its output to an integer. This alternative proposal claims to have the same properties as BIP32 and allows for mnemonics for subaccount keys. References [1]-[3] are provided for further information. 2020-10-17T09:14:59+00:00 + In a discussion on the bitcoin-dev mailing list, Leonardo Comandini questions the necessity of the chain code in BIP32. He argues that the additional entropy provided by the chain code is not needed and intends to demonstrate this through a schematic of BIP32 operations. Pieter Wuille, in response, provides historical context on how the chain code ended up being included in BIP32. He explains that BIP32 was inspired by Alan Reiner's Armory software, which had a different key derivation scheme that included a chain code. The chain code allowed for the derivation of multiple "chains" of keys from the same key pair. BIP32 improved upon this by enabling random access into the derived keys and hierarchical derivation with a sub-"chain code" for every subkey.Wuille defends the inclusion of the chain code in BIP32 by stating that xpubs require more protection than public keys alone and that the chain code adds an extra layer of security. Additionally, using a chain code prevents entropy reduction through repeated hashing. However, he acknowledges that from a cryptographic standpoint, the chain code is not necessary and only has practical advantages.The discussion also touches on interoperability and avoiding vendor lock-in. While compromises have been made in the past regarding the amount of entropy used, recent proposals such as SLIP-39 and Lightning Labs' seed mnemonics have raised concerns about interoperability and lock-in issues. The Blockchain Commons and a community of airgapped wallet developers have developed a specification called SSKR, which uses the same seed-to-master key technique as BIP32 to address these concerns.Leonardo Comandini further presents his alternative proposal for key derivation without the chain code. He provides a schematic of BIP32 operations and highlights the advantages of his proposed scheme, including shorter backups for keys and user-friendly backup for child keys. The proposed scheme also allows for mnemonics for subaccount keys. Comandini references various hash functions and provides links to BIP32, BIP39, and a pay-to-contract scheme for more information.Another contributor in the discussion acknowledges that there is no fundamental flaw with Comandini's proposal but admits they haven't spent much time developing wallets.The author of another post argues that the chain code in BIP32 is not necessary and provides a schematic of BIP32 operations to compare with an alternative proposal. The post introduces private and public child derivation formulae, as well as the corresponding chain codes. The post then presents an alternative proposal for derivation without the chain code, using a strong hash function 'h' to convert its output to an integer. This alternative proposal claims to have the same properties as BIP32 and allows for mnemonics for subaccount keys. References [1]-[3] are provided for further information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_Statechain-coinswap-assigning-blame-for-failure-in-a-two-stage-transfer-protocol-.xml b/static/bitcoin-dev/Sept_2020/combined_Statechain-coinswap-assigning-blame-for-failure-in-a-two-stage-transfer-protocol-.xml index 58769586bb..ae3362f7d4 100644 --- a/static/bitcoin-dev/Sept_2020/combined_Statechain-coinswap-assigning-blame-for-failure-in-a-two-stage-transfer-protocol-.xml +++ b/static/bitcoin-dev/Sept_2020/combined_Statechain-coinswap-assigning-blame-for-failure-in-a-two-stage-transfer-protocol-.xml @@ -1,35 +1,47 @@ - + 2 Combined summary - Statechain coinswap: assigning blame for failure in a two-stage transfer protocol. - 2023-08-02T02:39:39.216141+00:00 - - ZmnSCPxj 2020-09-24 00:19:48+00:00 - - - Tom Trevethan 2020-09-22 15:32:06+00:00 - - - ZmnSCPxj 2020-09-22 01:00:43+00:00 - - - Karl 2020-09-21 22:18:44+00:00 - - - Tom Trevethan 2020-09-21 21:52:28+00:00 - - - ZmnSCPxj 2020-09-21 01:14:29+00:00 - - - Tom Trevethan 2020-09-21 00:54:47+00:00 - - - ZmnSCPxj 2020-09-16 01:04:29+00:00 - - - Tom Trevethan 2020-09-13 22:14:50+00:00 - + 2025-09-26T15:32:37.733914+00:00 + python-feedgen + + + [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol Tom Trevethan + 2020-09-13T22:14:00.000Z + + + ZmnSCPxj + 2020-09-16T01:04:00.000Z + + + Tom Trevethan + 2020-09-21T00:54:00.000Z + + + ZmnSCPxj + 2020-09-21T01:14:00.000Z + + + Tom Trevethan + 2020-09-21T21:52:00.000Z + + + Karl + 2020-09-21T22:18:00.000Z + + + ZmnSCPxj + 2020-09-22T01:00:00.000Z + + + Tom Trevethan + 2020-09-22T15:32:00.000Z + + + ZmnSCPxj + 2020-09-24T00:19:00.000Z + + @@ -39,13 +51,13 @@ - python-feedgen + 2 Combined summary - Statechain coinswap: assigning blame for failure in a two-stage transfer protocol. - 2023-08-02T02:39:39.216141+00:00 + 2025-09-26T15:32:37.735112+00:00 - The conversation between Tom and ZmnSCPxj focuses on the security of statechains and compares them to other trust-minimized protocols such as TumbleBit and Wasabi. Statechains aim to replicate the speed of a centralized mixer while making theft more difficult, providing proof of ownership/theft and privacy guarantees. However, ZmnSCPxj argues that the slowness of other protocols is due to gathering enough participants for anonymity, rather than security. They suggest that if the statechain entity itself does not participate, a waiting period would still be necessary to gather enough participants, defeating the goal of speed. Furthermore, if the statechain entity does participate, it can outright steal funds. ZmnSCPxj suggests that the SwapMarket plan by Chris Belcher may provide better security with fewer confirmations of transactions.The discussion between Tom and ZmnSCPxj revolves around the security risks of non-custodial solutions. While Tom emphasizes the importance of non-custodiality for trust minimization and avoiding regulatory implications, ZmnSCPxj highlights the technical risks associated with it. They compare the security of a solution using a Secure Enclave (SE) for mixing protocols to other trust-minimized protocols like TumbleBit or Wasabi. ZmnSCPxj points out that even with an honest SE, hardware corruption can lead to the recovery of old private keys and violation of trust assumptions. They suggest withdrawing after every round and seeking multiple SEs to reduce risks. ZmnSCPxj concludes that while the SE solution may be superior in terms of block space, it is inferior in financial security.In a technical discussion on non-custodiality, ZmnSCPxj argues that trust minimization is the main objective, along with legal and regulatory implications. They suggest avoiding the term "custodial" and focusing on technical risks instead. ZmnSCPxj states that a service is non-custodial if it performs the protocol as specified, but there is still a risk of theft due to corrupted hardware. They highlight that older solutions like TumbleBit or Wasabi cannot lead to outright theft of coins even with cooperation from previous participants. ZmnSCPxj suggests that multiple mixing rounds under the proposed solution increase the risk of theft and withdrawing after each round would be better risk-wise.A team is designing an off-chain coin-swap protocol to work with the statechain implementation. The objective is to enable users to transact peer-to-peer off-chain, mixing their coins for privacy while remaining in custody of their assets. The swapping service, or conductor, would coordinate the swap among a group of statecoins without having control over the coins. To ensure privacy, a blind signature scheme similar to zerolink protocol would be used. However, assigning blame in case of a failed multi-party coinswap is challenging. One potential solution is for each sender to generate a zero-knowledge proof to assign blame, but this may add computational burden to user wallets. The team welcomes comments and is open to providing more details.The conversation between Tom and ZmnSCPxj discusses the concept of non-custodiality and its implications. Tom argues that non-custodiality is important for trust minimization and avoiding regulatory issues. ZmnSCPxj agrees but points out the technical risks involved. They suggest that a service is considered non-custodial if it follows the protocol specifications, but the risk of theft remains due to corrupted hardware. They compare this to other solutions like TumbleBit or Wasabi that cannot lead to the outright theft of coins. ZmnSCPxj highlights the increased exposure to theft with multiple rounds of the proposed solution and suggests withdrawing after each round for better risk management.The conversation revolves around the proposed protocol called 'statecoin'. It is a UTXO that can be transferred off-chain and requires trust in the Secure Enclave (SE). While the scheme offers advantages like faster and cheaper transactions, there are concerns about custodiality. ZmnSCPxj argues that if users have to trust the SE to not steal funds, it is not truly non-custodial. They argue that the main point of non-custodiality is trust minimization. They also discuss the statecoin scheme proposed by Tom, which involves a 2-of-2 UTXO between the owner and the SE. However, ZmnSCPxj points out that a corrupted SE can collude with other participants to take control of the coin and prevent the user from spending it freely.The email thread discusses the design of an off-chain coin-swap protocol for statecoins. The goal is to enable peer-to-peer off-chain transactions while ensuring coins remain in the custody of their owners. The swapping service, or conductor, does not have custody of the coins but coordinates the swap among statecoins. A blind signature scheme similar to zerolink protocol is used for privacy. Assigning blame in case of failed swaps is a challenge, and potential solutions 2020-09-24T00:19:48+00:00 + The conversation between Tom and ZmnSCPxj focuses on the security of statechains and compares them to other trust-minimized protocols such as TumbleBit and Wasabi. Statechains aim to replicate the speed of a centralized mixer while making theft more difficult, providing proof of ownership/theft and privacy guarantees. However, ZmnSCPxj argues that the slowness of other protocols is due to gathering enough participants for anonymity, rather than security. They suggest that if the statechain entity itself does not participate, a waiting period would still be necessary to gather enough participants, defeating the goal of speed. Furthermore, if the statechain entity does participate, it can outright steal funds. ZmnSCPxj suggests that the SwapMarket plan by Chris Belcher may provide better security with fewer confirmations of transactions.The discussion between Tom and ZmnSCPxj revolves around the security risks of non-custodial solutions. While Tom emphasizes the importance of non-custodiality for trust minimization and avoiding regulatory implications, ZmnSCPxj highlights the technical risks associated with it. They compare the security of a solution using a Secure Enclave (SE) for mixing protocols to other trust-minimized protocols like TumbleBit or Wasabi. ZmnSCPxj points out that even with an honest SE, hardware corruption can lead to the recovery of old private keys and violation of trust assumptions. They suggest withdrawing after every round and seeking multiple SEs to reduce risks. ZmnSCPxj concludes that while the SE solution may be superior in terms of block space, it is inferior in financial security.In a technical discussion on non-custodiality, ZmnSCPxj argues that trust minimization is the main objective, along with legal and regulatory implications. They suggest avoiding the term "custodial" and focusing on technical risks instead. ZmnSCPxj states that a service is non-custodial if it performs the protocol as specified, but there is still a risk of theft due to corrupted hardware. They highlight that older solutions like TumbleBit or Wasabi cannot lead to outright theft of coins even with cooperation from previous participants. ZmnSCPxj suggests that multiple mixing rounds under the proposed solution increase the risk of theft and withdrawing after each round would be better risk-wise.A team is designing an off-chain coin-swap protocol to work with the statechain implementation. The objective is to enable users to transact peer-to-peer off-chain, mixing their coins for privacy while remaining in custody of their assets. The swapping service, or conductor, would coordinate the swap among a group of statecoins without having control over the coins. To ensure privacy, a blind signature scheme similar to zerolink protocol would be used. However, assigning blame in case of a failed multi-party coinswap is challenging. One potential solution is for each sender to generate a zero-knowledge proof to assign blame, but this may add computational burden to user wallets. The team welcomes comments and is open to providing more details.The conversation between Tom and ZmnSCPxj discusses the concept of non-custodiality and its implications. Tom argues that non-custodiality is important for trust minimization and avoiding regulatory issues. ZmnSCPxj agrees but points out the technical risks involved. They suggest that a service is considered non-custodial if it follows the protocol specifications, but the risk of theft remains due to corrupted hardware. They compare this to other solutions like TumbleBit or Wasabi that cannot lead to the outright theft of coins. ZmnSCPxj highlights the increased exposure to theft with multiple rounds of the proposed solution and suggests withdrawing after each round for better risk management.The conversation revolves around the proposed protocol called 'statecoin'. It is a UTXO that can be transferred off-chain and requires trust in the Secure Enclave (SE). While the scheme offers advantages like faster and cheaper transactions, there are concerns about custodiality. ZmnSCPxj argues that if users have to trust the SE to not steal funds, it is not truly non-custodial. They argue that the main point of non-custodiality is trust minimization. They also discuss the statecoin scheme proposed by Tom, which involves a 2-of-2 UTXO between the owner and the SE. However, ZmnSCPxj points out that a corrupted SE can collude with other participants to take control of the coin and prevent the user from spending it freely.The email thread discusses the design of an off-chain coin-swap protocol for statecoins. The goal is to enable peer-to-peer off-chain transactions while ensuring coins remain in the custody of their owners. The swapping service, or conductor, does not have custody of the coins but coordinates the swap among statecoins. A blind signature scheme similar to zerolink protocol is used for privacy. Assigning blame in case of failed swaps is a challenge, and potential solutions - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_Suggestion-Solve-year-2106-problem-by-taking-timestamps-mod-2-32.xml b/static/bitcoin-dev/Sept_2020/combined_Suggestion-Solve-year-2106-problem-by-taking-timestamps-mod-2-32.xml index ea40240cff..0c16df2a7c 100644 --- a/static/bitcoin-dev/Sept_2020/combined_Suggestion-Solve-year-2106-problem-by-taking-timestamps-mod-2-32.xml +++ b/static/bitcoin-dev/Sept_2020/combined_Suggestion-Solve-year-2106-problem-by-taking-timestamps-mod-2-32.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 - 2023-08-02T02:41:11.701704+00:00 - - Pieter Wuille 2020-10-16 21:58:20+00:00 - - - yanmaani at cock.li 2020-09-19 12:36:47+00:00 - + 2025-09-26T15:32:46.126367+00:00 + python-feedgen + + + [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 yanmaani + 2020-09-19T12:36:00.000Z + + + Pieter Wuille + 2020-10-16T21:58:00.000Z + + - python-feedgen + 2 Combined summary - Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 - 2023-08-02T02:41:11.701704+00:00 + 2025-09-26T15:32:46.126788+00:00 - In a Bitcoin-dev email thread, user yanmaani has suggested an amendment to the timestamp rules in the Bitcoin network. Currently, there are certain rules in place for block timestamps - they must not be lower than the median of the last 11 blocks, greater than the current time plus two hours, or greater than 2^32, which would cause Bitcoin to "die" around February 7th, 2106.Yanmaani's proposed solution involves treating block headers as having a 64-bit timestamp. The requirement is that the difference between the timestamp and the median timestamp of the past 11 blocks should be at least one and at most 2^32. To achieve this, the higher 32 bits of the timestamp are set equal to the median of the past 11 blocks on deserialization. If this violates the rule mentioned above, it is set one higher.User Pieter believes that Yanmaani's solution is in line with what will eventually be addressed and thinks it may be worth considering as a BIP (Bitcoin Improvement Proposal) in the future.Currently, Bitcoin faces a problem with its timestamp rules. There are restrictions that prevent the block timestamp from being lower than the median of the last 11 blocks, greater than the current time plus two hours, or greater than 2^32. This means that if no timestamp below 2^32 exceeds the median of the last 11 blocks, Bitcoin would "die" on or about February 7, 2106.One proposed solution to this problem is to change the rules so that the block timestamp plus k*2^32 may not be lower than the median of the last 11 blocks and may not be greater than the current time plus two hours. It is important to note that k is an integer with the same value for the calculations of both Rule 1 and Rule 2. However, this solution would cause a hardfork in 2106, approximately 85.5 years from now, and it is expected that 95% of nodes would have updated by then.Another proposed solution is to use 64-bit timestamps. However, this would break compatibility with other software that has specific expectations of header fields, such as ASICs' firmware. Furthermore, this solution would cause a hardfork before the date of timestamp overflow, making it less appropriate.It remains to be seen whether Yanmaani's idea is worth considering as a BIP. This discussion highlights the challenges faced by Bitcoin in relation to its timestamp rules and the potential solutions that could be explored in order to address these issues. 2020-10-16T21:58:20+00:00 + In a Bitcoin-dev email thread, user yanmaani has suggested an amendment to the timestamp rules in the Bitcoin network. Currently, there are certain rules in place for block timestamps - they must not be lower than the median of the last 11 blocks, greater than the current time plus two hours, or greater than 2^32, which would cause Bitcoin to "die" around February 7th, 2106.Yanmaani's proposed solution involves treating block headers as having a 64-bit timestamp. The requirement is that the difference between the timestamp and the median timestamp of the past 11 blocks should be at least one and at most 2^32. To achieve this, the higher 32 bits of the timestamp are set equal to the median of the past 11 blocks on deserialization. If this violates the rule mentioned above, it is set one higher.User Pieter believes that Yanmaani's solution is in line with what will eventually be addressed and thinks it may be worth considering as a BIP (Bitcoin Improvement Proposal) in the future.Currently, Bitcoin faces a problem with its timestamp rules. There are restrictions that prevent the block timestamp from being lower than the median of the last 11 blocks, greater than the current time plus two hours, or greater than 2^32. This means that if no timestamp below 2^32 exceeds the median of the last 11 blocks, Bitcoin would "die" on or about February 7, 2106.One proposed solution to this problem is to change the rules so that the block timestamp plus k*2^32 may not be lower than the median of the last 11 blocks and may not be greater than the current time plus two hours. It is important to note that k is an integer with the same value for the calculations of both Rule 1 and Rule 2. However, this solution would cause a hardfork in 2106, approximately 85.5 years from now, and it is expected that 95% of nodes would have updated by then.Another proposed solution is to use 64-bit timestamps. However, this would break compatibility with other software that has specific expectations of header fields, such as ASICs' firmware. Furthermore, this solution would cause a hardfork before the date of timestamp overflow, making it less appropriate.It remains to be seen whether Yanmaani's idea is worth considering as a BIP. This discussion highlights the challenges faced by Bitcoin in relation to its timestamp rules and the potential solutions that could be explored in order to address these issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_Taproot-and-graftroot-complexity.xml b/static/bitcoin-dev/Sept_2020/combined_Taproot-and-graftroot-complexity.xml index e41019458a..bc8836f3c8 100644 --- a/static/bitcoin-dev/Sept_2020/combined_Taproot-and-graftroot-complexity.xml +++ b/static/bitcoin-dev/Sept_2020/combined_Taproot-and-graftroot-complexity.xml @@ -1,35 +1,83 @@ - + 2 Combined summary - Taproot (and graftroot) complexity - 2023-08-02T01:50:21.179250+00:00 - - Lloyd Fournier 2020-09-20 03:23:28+00:00 - - - Jay Berg 2020-09-19 12:52:51+00:00 - - - Jay Berg 2020-09-19 08:46:12+00:00 - - - Jay Berg 2020-09-19 07:13:40+00:00 - - - ZmnSCPxj 2020-02-10 06:27:24+00:00 - - - Anthony Towns 2020-02-10 00:20:11+00:00 - - - Antoine Riard 2020-02-09 22:32:41+00:00 - - - Matt Corallo 2020-02-09 20:40:27+00:00 - - - Bryan Bishop 2020-02-09 20:19:55+00:00 - + 2025-09-26T15:32:44.035208+00:00 + python-feedgen + + + [bitcoin-dev] Taproot (and graftroot) complexity Bryan Bishop + 2020-02-09T20:19:00.000Z + + + [bitcoin-dev] An alternative deployment path for taproot technology (Re: Taproot (and graftroot) complexity) Bryan Bishop + 2020-02-09T20:22:00.000Z + + + [bitcoin-dev] Taproot public NUMS optimization " Bryan Bishop + 2020-02-09T20:24:00.000Z + + + [bitcoin-dev] Taproot (and graftroot) complexity Matt Corallo + 2020-02-09T20:40:00.000Z + + + [bitcoin-dev] Taproot (and graftroot) complexity (reflowed) Bryan Bishop + 2020-02-09T20:47:00.000Z + + + Antoine Riard + 2020-02-09T22:32:00.000Z + + + David A. Harding + 2020-02-10T00:15:00.000Z + + + [bitcoin-dev] Taproot (and graftroot) complexity Anthony Towns + 2020-02-10T00:20:00.000Z + + + ZmnSCPxj + 2020-02-10T06:27:00.000Z + + + Jonas Nick + 2020-02-10T16:28:00.000Z + + + Jeremy + 2020-02-14T20:07:00.000Z + + + Jeremy + 2020-02-14T21:21:00.000Z + + + David A. Harding + 2020-02-14T22:36:00.000Z + + + Pieter Wuille + 2020-02-18T23:29:00.000Z + + + Jay Berg + 2020-09-19T07:13:00.000Z + + + Jay Berg + 2020-09-19T08:46:00.000Z + + + Jay Berg + 2020-09-19T12:52:00.000Z + + + Lloyd Fournier + 2020-09-20T03:23:00.000Z + + @@ -39,13 +87,13 @@ - python-feedgen + 2 Combined summary - Taproot (and graftroot) complexity - 2023-08-02T01:50:21.179250+00:00 + 2025-09-26T15:32:44.037181+00:00 - In an email exchange within the bitcoin-dev community, LL and Jay Berg discussed the security and privacy implications of reusing keys in Taproot. LL stated that there is not much difference in security or privacy, and the advice to avoid key reuse remains the same. Jay Berg, new to bitcoin-dev, asked if reusing keys acts differently in Taproot compared to Pay-to-PubKey-Hash. The conversation referred to a thread about Taproot complexity started by Anthony Towns on February 10, 2020.The creation of UTXOs in Taproot allows for indistinguishable spends as long as keys are not reused. Reusing keys may have security and privacy implications, but it is unclear whether it has different implications in Taproot compared to Pay-to-PubKey-Hash. The use of the same public key to create the same address remains the same in both cases. The question raised is whether there are worse security and privacy implications when reusing public keys with Taproot.ZmnSCPxj presented an argument related to Taproot in a message to the group. He explained how most scripts in use have a pre-determined set of participants represented by pubkeys, and Taproot allows for the union of these participants as the keypath branch. This provides privacy and reduced onchain fees when all participants sign a transaction using the keypath spend. Taproot can be beneficial for complex contracts and protocols, offering privacy and transaction size benefits.The discussion on the bitcoin-dev mailing list focused on the development and benefits of Taproot. It allows wallets to change recovery options if a key is lost and offers advantages such as reduced onchain fees. Graftroot was also mentioned but not proposed due to incomplete documentation. The benefits of Taproot include preserving anonymity sets even after spending. However, concerns were raised about the merit of Taproot compared to alternatives and the development process.Privacy concerns regarding Taproot design were also discussed. It was suggested that users may care more about privacy when contesting a close of a channel, and timelocks were identified as a privacy leak. The optimization for the common case of N of N opt-out in the protocol was highlighted as beneficial for user privacy and advanced functionality.Bryan Bishop questioned the Taproot upgrade, specifically the assumption about the frequency and likelihood of the signature case over the script case. Matt Corallo clarified that optimization for the common N of N case encourages developers to make this possibility a reality, enhancing user privacy for advanced scripting systems.A group of anonymous developers expressed concerns about the Taproot upgrade and its development. They questioned the probability assumption of the N of N case and its comparison to script paths. Privacy concerns were raised, suggesting alternative designs with MAST that offer more privacy. The developers proposed solutions such as allowing the witness type to be either a MAST hash or a schnorr key and separate soft-forks for Merkle Branch Witnesses and Schnorr Signatures.The developers emphasized their duty to raise these concerns and suggestions for the benefit of the community. Despite concerns, Taproot is viewed as a good midway point to release the feature and move forward. 2020-09-20T03:23:28+00:00 + In an email exchange within the bitcoin-dev community, LL and Jay Berg discussed the security and privacy implications of reusing keys in Taproot. LL stated that there is not much difference in security or privacy, and the advice to avoid key reuse remains the same. Jay Berg, new to bitcoin-dev, asked if reusing keys acts differently in Taproot compared to Pay-to-PubKey-Hash. The conversation referred to a thread about Taproot complexity started by Anthony Towns on February 10, 2020.The creation of UTXOs in Taproot allows for indistinguishable spends as long as keys are not reused. Reusing keys may have security and privacy implications, but it is unclear whether it has different implications in Taproot compared to Pay-to-PubKey-Hash. The use of the same public key to create the same address remains the same in both cases. The question raised is whether there are worse security and privacy implications when reusing public keys with Taproot.ZmnSCPxj presented an argument related to Taproot in a message to the group. He explained how most scripts in use have a pre-determined set of participants represented by pubkeys, and Taproot allows for the union of these participants as the keypath branch. This provides privacy and reduced onchain fees when all participants sign a transaction using the keypath spend. Taproot can be beneficial for complex contracts and protocols, offering privacy and transaction size benefits.The discussion on the bitcoin-dev mailing list focused on the development and benefits of Taproot. It allows wallets to change recovery options if a key is lost and offers advantages such as reduced onchain fees. Graftroot was also mentioned but not proposed due to incomplete documentation. The benefits of Taproot include preserving anonymity sets even after spending. However, concerns were raised about the merit of Taproot compared to alternatives and the development process.Privacy concerns regarding Taproot design were also discussed. It was suggested that users may care more about privacy when contesting a close of a channel, and timelocks were identified as a privacy leak. The optimization for the common case of N of N opt-out in the protocol was highlighted as beneficial for user privacy and advanced functionality.Bryan Bishop questioned the Taproot upgrade, specifically the assumption about the frequency and likelihood of the signature case over the script case. Matt Corallo clarified that optimization for the common N of N case encourages developers to make this possibility a reality, enhancing user privacy for advanced scripting systems.A group of anonymous developers expressed concerns about the Taproot upgrade and its development. They questioned the probability assumption of the N of N case and its comparison to script paths. Privacy concerns were raised, suggesting alternative designs with MAST that offer more privacy. The developers proposed solutions such as allowing the witness type to be either a MAST hash or a schnorr key and separate soft-forks for Merkle Branch Witnesses and Schnorr Signatures.The developers emphasized their duty to raise these concerns and suggestions for the benefit of the community. Despite concerns, Taproot is viewed as a good midway point to release the feature and move forward. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2020/combined_reviving-op-difficulty.xml b/static/bitcoin-dev/Sept_2020/combined_reviving-op-difficulty.xml index 1754e8c094..a99145477b 100644 --- a/static/bitcoin-dev/Sept_2020/combined_reviving-op-difficulty.xml +++ b/static/bitcoin-dev/Sept_2020/combined_reviving-op-difficulty.xml @@ -1,47 +1,63 @@ - + 2 Combined summary - reviving op_difficulty - 2023-08-02T02:37:38.474787+00:00 - - Jeremy 2020-09-02 18:27:00+00:00 - - - Thomas Hartman 2020-09-02 14:40:28+00:00 - - - Thomas Hartman 2020-09-01 20:07:21+00:00 - - - David A. Harding 2020-08-22 16:46:20+00:00 - - - Thomas Hartman 2020-08-19 23:32:25+00:00 - - - Thomas Hartman 2020-08-19 21:15:08+00:00 - - - ZmnSCPxj 2020-08-17 23:14:00+00:00 - - - Tier Nolan 2020-08-17 21:55:04+00:00 - - - Thomas Hartman 2020-08-17 19:48:27+00:00 - - - ZmnSCPxj 2020-08-17 05:04:42+00:00 - - - Anthony Towns 2020-08-16 22:29:23+00:00 - - - Tier Nolan 2020-08-16 18:59:25+00:00 - - - Thomas Hartman 2020-08-16 15:41:30+00:00 - + 2025-09-26T15:32:41.919236+00:00 + python-feedgen + + + [bitcoin-dev] reviving op_difficulty Thomas Hartman + 2020-08-16T15:41:00.000Z + + + Tier Nolan + 2020-08-16T18:59:00.000Z + + + Anthony Towns + 2020-08-16T22:29:00.000Z + + + ZmnSCPxj + 2020-08-17T05:04:00.000Z + + + Thomas Hartman + 2020-08-17T19:48:00.000Z + + + Tier Nolan + 2020-08-17T21:55:00.000Z + + + ZmnSCPxj + 2020-08-17T23:14:00.000Z + + + Thomas Hartman + 2020-08-19T21:15:00.000Z + + + Thomas Hartman + 2020-08-19T23:32:00.000Z + + + David A. Harding + 2020-08-22T16:46:00.000Z + + + Thomas Hartman + 2020-09-01T20:07:00.000Z + + + Thomas Hartman + 2020-09-02T14:40:00.000Z + + + Jeremy + 2020-09-02T18:27:00.000Z + + @@ -55,13 +71,13 @@ - python-feedgen + 2 Combined summary - reviving op_difficulty - 2023-08-02T02:37:38.474787+00:00 + 2025-09-26T15:32:41.920755+00:00 - In a recent bitcoin-dev mailing list discussion, there have been proposals and discussions regarding the implementation of difficulty futures in Bitcoin. Tamas Blummer had initially proposed an additional opcode for enabling Bitcoin difficulty futures, but Jeremy Rubin introduced an alternate scheme that does not require changes to the Bitcoin protocol. This scheme takes advantage of the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposal involves creating conflicting spends from a multisig, with different nLockTime values based on the current height or time. Depending on the subsequent change in hashrate, either Alice or Bob will receive their payment first. This method can be embedded in a taproot commitment using OP_CLTV or OP_CSV instead of nLockTime.Thomas Hartman expressed admiration for Powswap, a platform that allows users to bet on the future hash rate of the Bitcoin network without protocol changes. However, he raised concerns about watchtowers to prevent fund sweeping by the losing party and the impact on lightning channels. Hartman also suggested the possibility of betting on specific time slices and difficulty thresholds using Powswap. Currently, Powswap only creates contracts from the current time to the future, but Hartman proposed creating synthetic hashrate binaries by subtracting the time from the current time to B from the time from the current time to A. He also questioned the feasibility of betting on the first six blocks after retarget being found under an hour and the new difficulty exceeding a certain threshold.The community mourned the loss of Tamas Blummer, a developer who proposed the opcode for Bitcoin difficulty futures. Jeremy Rubin's scheme was introduced as an alternative method that does not require protocol changes and leverages the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposed scheme is compatible with off-chain commitments and can be embedded in a taproot commitment using OP_CLTV or OP_CSV. The author of the discussion proposed using a packed difficulty target instead of using op_diff to calculate the ratio, and expressed their satisfaction with not having to deal with floating point numbers.Tier Nolan proposed a new method for speculation contracts that considers the ratio between future and current difficulty instead of difficulty itself. This ratio can be obtained from packed representations already included in blocks. Nolan provided an example using the current and last difficulties and targets, demonstrating how op_diff could return the ratio for ticks instead of difficulty.The discussion explored the creation of difficulty futures instruments using Taproot MAST and op_diff. The proposed idea involved creating partial versions of difficulty futures funded by Bob and spendable by Alice after a certain number of blocks. A payment from Alice to Bob with a hash lock was also suggested to enable this process. While it would be simpler to have all outputs in the same transaction, the proposed construction requires two signatures for the hash-branch to ensure specific contract payouts.In another email thread, a solution to binary payouts was discussed. Taproot MAST was suggested as an option, and another proposal involved paying outputs based on the diff value using division and binary operators. The payout would be enabled or disabled based on the value of D. This solution has logarithmic performance in terms of the number of ticks.Taproot MAST was mentioned again as a potential solution to enable difficulty futures instruments. The proposal focused on creating partial versions of difficulty futures funded by one party and spendable by another party after a certain period of time. A hash lock on the payment with a preimage secret was suggested to ensure the correct execution of the contract. The goal is to eventually implement this with lightning and high-frequency trading.Thomas Hartman proposed adding an opcode called "op_difficulty" to enable binary options on difficulty futures. However, another approach suggested using taproot's annex concept to create restrictions based on specific difficulty values or ranges. Participants would deposit into a UTXO and construct signed payouts timelocked for the future date. The payouts would go to different parties depending on the predicted difficulty range. Specifying an exact value for the difficulty was considered better for privacy, but it would require multiple signatures for pre-signed payouts.The discussion also touched upon the concept of binary options and pseudo-continuous futures. It was suggested that any opcode can be considered a binary option, but creating numerous outputs with different thresholds is necessary for a pseudo-continuous future. Taproot MAST was mentioned as a way to improve this method by generating fresh keypairs and tapleaf scripts.Another proposal for enabling binary options on difficulty futures involved using an operation called "op_difficulty" or taproot's annex concept. The protocol design included participants depositing into a UTXO and constructing signed payouts timelocked for the future date. The payouts would be based on specific difficulty values or ranges. The use of an exact difficulty value was considered better for blockchain size and privacy, although it would require multiple signatures for pre-signed payouts.Lastly, the idea of adding a single op_difficulty operation to enable binary options on difficulty 2020-09-02T18:27:00+00:00 + In a recent bitcoin-dev mailing list discussion, there have been proposals and discussions regarding the implementation of difficulty futures in Bitcoin. Tamas Blummer had initially proposed an additional opcode for enabling Bitcoin difficulty futures, but Jeremy Rubin introduced an alternate scheme that does not require changes to the Bitcoin protocol. This scheme takes advantage of the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposal involves creating conflicting spends from a multisig, with different nLockTime values based on the current height or time. Depending on the subsequent change in hashrate, either Alice or Bob will receive their payment first. This method can be embedded in a taproot commitment using OP_CLTV or OP_CSV instead of nLockTime.Thomas Hartman expressed admiration for Powswap, a platform that allows users to bet on the future hash rate of the Bitcoin network without protocol changes. However, he raised concerns about watchtowers to prevent fund sweeping by the losing party and the impact on lightning channels. Hartman also suggested the possibility of betting on specific time slices and difficulty thresholds using Powswap. Currently, Powswap only creates contracts from the current time to the future, but Hartman proposed creating synthetic hashrate binaries by subtracting the time from the current time to B from the time from the current time to A. He also questioned the feasibility of betting on the first six blocks after retarget being found under an hour and the new difficulty exceeding a certain threshold.The community mourned the loss of Tamas Blummer, a developer who proposed the opcode for Bitcoin difficulty futures. Jeremy Rubin's scheme was introduced as an alternative method that does not require protocol changes and leverages the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposed scheme is compatible with off-chain commitments and can be embedded in a taproot commitment using OP_CLTV or OP_CSV. The author of the discussion proposed using a packed difficulty target instead of using op_diff to calculate the ratio, and expressed their satisfaction with not having to deal with floating point numbers.Tier Nolan proposed a new method for speculation contracts that considers the ratio between future and current difficulty instead of difficulty itself. This ratio can be obtained from packed representations already included in blocks. Nolan provided an example using the current and last difficulties and targets, demonstrating how op_diff could return the ratio for ticks instead of difficulty.The discussion explored the creation of difficulty futures instruments using Taproot MAST and op_diff. The proposed idea involved creating partial versions of difficulty futures funded by Bob and spendable by Alice after a certain number of blocks. A payment from Alice to Bob with a hash lock was also suggested to enable this process. While it would be simpler to have all outputs in the same transaction, the proposed construction requires two signatures for the hash-branch to ensure specific contract payouts.In another email thread, a solution to binary payouts was discussed. Taproot MAST was suggested as an option, and another proposal involved paying outputs based on the diff value using division and binary operators. The payout would be enabled or disabled based on the value of D. This solution has logarithmic performance in terms of the number of ticks.Taproot MAST was mentioned again as a potential solution to enable difficulty futures instruments. The proposal focused on creating partial versions of difficulty futures funded by one party and spendable by another party after a certain period of time. A hash lock on the payment with a preimage secret was suggested to ensure the correct execution of the contract. The goal is to eventually implement this with lightning and high-frequency trading.Thomas Hartman proposed adding an opcode called "op_difficulty" to enable binary options on difficulty futures. However, another approach suggested using taproot's annex concept to create restrictions based on specific difficulty values or ranges. Participants would deposit into a UTXO and construct signed payouts timelocked for the future date. The payouts would go to different parties depending on the predicted difficulty range. Specifying an exact value for the difficulty was considered better for privacy, but it would require multiple signatures for pre-signed payouts.The discussion also touched upon the concept of binary options and pseudo-continuous futures. It was suggested that any opcode can be considered a binary option, but creating numerous outputs with different thresholds is necessary for a pseudo-continuous future. Taproot MAST was mentioned as a way to improve this method by generating fresh keypairs and tapleaf scripts.Another proposal for enabling binary options on difficulty futures involved using an operation called "op_difficulty" or taproot's annex concept. The protocol design included participants depositing into a UTXO and constructing signed payouts timelocked for the future date. The payouts would be based on specific difficulty values or ranges. The use of an exact difficulty value was considered better for blockchain size and privacy, although it would require multiple signatures for pre-signed payouts.Lastly, the idea of adding a single op_difficulty operation to enable binary options on difficulty - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_BIP-extensions.xml b/static/bitcoin-dev/Sept_2021/combined_BIP-extensions.xml index 8aced68bb3..fa9c74a1cd 100644 --- a/static/bitcoin-dev/Sept_2021/combined_BIP-extensions.xml +++ b/static/bitcoin-dev/Sept_2021/combined_BIP-extensions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP extensions - 2023-08-02T04:46:57.051124+00:00 + 2025-09-26T16:02:40.758878+00:00 + python-feedgen Anthony Towns 2021-09-15 14:34:54+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP extensions - 2023-08-02T04:46:57.052124+00:00 + 2025-09-26T16:02:40.759012+00:00 - The discussion among Bitcoin developers on the bitcoin-dev mailing list revolves around the status of Bitcoin Improvement Proposals (BIPs). While some developers argue that BIPs become "standards" once incorporated into the Bitcoin ecosystem, others disagree, stating that calling them "standards" could be misleading. They emphasize that a proposal remains a proposal until accepted as a standard by the community.The debate then shifts to improving BIPs. One proposed solution is creating BIP extensions instead of modifying existing ones long after review, which can lead to contention. BIP extensions are separate proposals that extend an existing BIP. However, concerns are raised that this approach may hinder the BIP process and encourage contentiousness.As an alternative, it is suggested to separate draft BIPs from those in Active/Final status. A new BIP would be marked as a "Draft" until authors are satisfied with the text, at which point it becomes a Final status BIP without modification. The suggestion is to avoid making modifications outside of drafts unless absolutely necessary. Only minor updates should be allowed, such as adding additional info in Acknowledgements or See also sections, including Superseded-By links, and updating specific tables designed for updates.In conclusion, the focus of the discussion is on ensuring comprehensive evaluation and review of proposals before accepting them as standards within the Bitcoin ecosystem. Some developers propose creating BIP extensions to minimize contention, while others advocate for separating draft BIPs from those in Active/Final status, limiting modifications, and allowing only minor updates.A member named Michael Folkson is advocating for a revision to BIP 2, which is being discussed in the "BIP process meeting" thread. The plan is to modify pull request #1015 or another relevant pull request based on collective decisions.Karl-Johan Alm proposes that changes to BIPs of the second and third type should be done as BIP extensions. These extensions are independent proposals that do not require approval from the original author. By opting for extensions instead of modifying existing BIPs long after review, the community can be assured that a BIP will mostly remain unchanged. This approach allows modifications to be judged solely on their merits and provides a path to propose changes even if authors become inactive.Bitcoin Improvement Proposals (BIPs) start as ideas and are discussed on the BIPs repository list before being assigned a number by editors and merged. Once widely supported, a BIP becomes a standard. BIPs may be modified for spelling errors, clarifications, or to add missing content such as an activation strategy. Changes falling into the second and third categories should be done as BIP extensions, unless they are free from contention. These extensions are considered independent proposals and do not require the original author's approval. An extension that extends a BIP XXX is referred to as BIP-XXX-Y.Karl-Johan Alm proposes changes to BIPs to be made as BIP extensions in an email to the bitcoin-dev mailing list. He suggests that this approach gives the community confidence that a BIP will mostly remain unchanged and enables evaluations of modifications based on their merits alone. It also provides a pathway to propose modifications even if authors become inactive. Federico Berrone supports Alm's proposal and recommends adding additional information separately to declutter BIPs and enhance proposal comprehension without modifying the original proposal. 2021-09-15T14:34:54+00:00 + The discussion among Bitcoin developers on the bitcoin-dev mailing list revolves around the status of Bitcoin Improvement Proposals (BIPs). While some developers argue that BIPs become "standards" once incorporated into the Bitcoin ecosystem, others disagree, stating that calling them "standards" could be misleading. They emphasize that a proposal remains a proposal until accepted as a standard by the community.The debate then shifts to improving BIPs. One proposed solution is creating BIP extensions instead of modifying existing ones long after review, which can lead to contention. BIP extensions are separate proposals that extend an existing BIP. However, concerns are raised that this approach may hinder the BIP process and encourage contentiousness.As an alternative, it is suggested to separate draft BIPs from those in Active/Final status. A new BIP would be marked as a "Draft" until authors are satisfied with the text, at which point it becomes a Final status BIP without modification. The suggestion is to avoid making modifications outside of drafts unless absolutely necessary. Only minor updates should be allowed, such as adding additional info in Acknowledgements or See also sections, including Superseded-By links, and updating specific tables designed for updates.In conclusion, the focus of the discussion is on ensuring comprehensive evaluation and review of proposals before accepting them as standards within the Bitcoin ecosystem. Some developers propose creating BIP extensions to minimize contention, while others advocate for separating draft BIPs from those in Active/Final status, limiting modifications, and allowing only minor updates.A member named Michael Folkson is advocating for a revision to BIP 2, which is being discussed in the "BIP process meeting" thread. The plan is to modify pull request #1015 or another relevant pull request based on collective decisions.Karl-Johan Alm proposes that changes to BIPs of the second and third type should be done as BIP extensions. These extensions are independent proposals that do not require approval from the original author. By opting for extensions instead of modifying existing BIPs long after review, the community can be assured that a BIP will mostly remain unchanged. This approach allows modifications to be judged solely on their merits and provides a path to propose changes even if authors become inactive.Bitcoin Improvement Proposals (BIPs) start as ideas and are discussed on the BIPs repository list before being assigned a number by editors and merged. Once widely supported, a BIP becomes a standard. BIPs may be modified for spelling errors, clarifications, or to add missing content such as an activation strategy. Changes falling into the second and third categories should be done as BIP extensions, unless they are free from contention. These extensions are considered independent proposals and do not require the original author's approval. An extension that extends a BIP XXX is referred to as BIP-XXX-Y.Karl-Johan Alm proposes changes to BIPs to be made as BIP extensions in an email to the bitcoin-dev mailing list. He suggests that this approach gives the community confidence that a BIP will mostly remain unchanged and enables evaluations of modifications based on their merits alone. It also provides a pathway to propose modifications even if authors become inactive. Federico Berrone supports Alm's proposal and recommends adding additional information separately to declutter BIPs and enhance proposal comprehension without modifying the original proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_BIP-process-meeting-Tuesday-September-14th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml b/static/bitcoin-dev/Sept_2021/combined_BIP-process-meeting-Tuesday-September-14th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml index 72ce99ae54..f21c238023 100644 --- a/static/bitcoin-dev/Sept_2021/combined_BIP-process-meeting-Tuesday-September-14th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml +++ b/static/bitcoin-dev/Sept_2021/combined_BIP-process-meeting-Tuesday-September-14th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC - 2023-08-02T04:40:28.864461+00:00 + 2025-09-26T16:02:47.083024+00:00 + python-feedgen Michael Folkson 2021-09-14 15:43:59+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC - 2023-08-02T04:40:28.864461+00:00 + 2025-09-26T16:02:47.083163+00:00 - The bitcoin-dev mailing list is currently discussing ways to enhance the Bitcoin Improvement Proposal (BIP) process. Prayank suggests that BIPs are proposals shared on the mailing list and anyone can create directories for them. They propose documenting a proposal, opening a pull request in the bitcoin/bips repository, assigning a number, and merging it before sharing it on the mailing list. Michael recommends using the Git version control system in the repository for easier editing and revision. He also suggests using bots to notify maintainers and contributors of pull requests. Additionally, he suggests creating a BIP Gallery with text and image galleries to promote engagement with the BIP process.The discussion also touches upon the perception of authority and the use of the same organization on GitHub, which some find misleading. ACKs/NACKs are deemed important in discussions related to proposals. The goal is to provide clarity and improve software while maintaining the current state of affairs.Further suggestions include using the Git version control system instead of relying solely on the mailing list for edits and revisions. It is proposed to create a BIP directory linking to proposals shared on the mailing list, allowing updates without altering the original post. Concerns about having a central repository for BIPs are addressed by emphasizing the limited ability of BIP editors to unilaterally merge contentious code changes. A bot in the bitcoin/bips repository could help notify maintainers and contributors regarding pull requests.A previous attempt at a BIP Gallery was made but was not well-received by many. However, an informational BIP could complement the standard BIP for new implementers or casual readers.In summary, the ongoing discussion on the bitcoin-dev mailing list focuses on improving the BIP process. Suggestions include utilizing the Git version control system, creating a BIP directory, and implementing a bot for notifications. The idea of a BIP Gallery is explored, and there are considerations regarding authority perception and the use of the same organization on GitHub. The ultimate objective is to enhance clarity and software development while maintaining the existing framework. 2021-09-14T15:43:59+00:00 + The bitcoin-dev mailing list is currently discussing ways to enhance the Bitcoin Improvement Proposal (BIP) process. Prayank suggests that BIPs are proposals shared on the mailing list and anyone can create directories for them. They propose documenting a proposal, opening a pull request in the bitcoin/bips repository, assigning a number, and merging it before sharing it on the mailing list. Michael recommends using the Git version control system in the repository for easier editing and revision. He also suggests using bots to notify maintainers and contributors of pull requests. Additionally, he suggests creating a BIP Gallery with text and image galleries to promote engagement with the BIP process.The discussion also touches upon the perception of authority and the use of the same organization on GitHub, which some find misleading. ACKs/NACKs are deemed important in discussions related to proposals. The goal is to provide clarity and improve software while maintaining the current state of affairs.Further suggestions include using the Git version control system instead of relying solely on the mailing list for edits and revisions. It is proposed to create a BIP directory linking to proposals shared on the mailing list, allowing updates without altering the original post. Concerns about having a central repository for BIPs are addressed by emphasizing the limited ability of BIP editors to unilaterally merge contentious code changes. A bot in the bitcoin/bips repository could help notify maintainers and contributors regarding pull requests.A previous attempt at a BIP Gallery was made but was not well-received by many. However, an informational BIP could complement the standard BIP for new implementers or casual readers.In summary, the ongoing discussion on the bitcoin-dev mailing list focuses on improving the BIP process. Suggestions include utilizing the Git version control system, creating a BIP directory, and implementing a bot for notifications. The idea of a BIP Gallery is explored, and there are considerations regarding authority perception and the use of the same organization on GitHub. The ultimate objective is to enhance clarity and software development while maintaining the existing framework. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml b/static/bitcoin-dev/Sept_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml index 73e3ed905a..0a3537b8dc 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Braidpool: Proposal for a decentralised mining pool - 2023-08-02T04:38:29.528678+00:00 + 2025-09-26T16:02:17.584553+00:00 + python-feedgen pool2win 2021-09-13 08:03:42+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Braidpool: Proposal for a decentralised mining pool - 2023-08-02T04:38:29.528678+00:00 + 2025-09-26T16:02:17.584699+00:00 - The issue of a malicious miner cheating other miners of their reward is discussed in the context. The problem arises as the bitcoin block is used as the sentinel to mark the shares from DAG that need to be rewarded. A proposed solution is to have the hub broadcast a "sentinel" to mark out the point in logical time up to which shares will be rewarded.A proposal is made to reward miners for creating valid blocks, but concerns are raised about rogue miners avoiding referencing other miners' shares to keep rewards for themselves. Two methods are suggested for resolving conflicts between conflicting versions of the DAG: using the longest chain or the one with more work. However, both methods present issues such as the potential for bad hashers to create low-difficulty shares and then mine and publish higher-difficulty shares without sharing the reward.In an email exchange, questions are raised about the proposal that every share can reference multiple previous shares. Concerns are expressed about rogue miners not referencing any shares from other miners to avoid sharing the reward. Doubts are also raised about how conflicts between different valid states will be resolved.A discussion on the Bitcoin-dev mailing list focuses on the centralization of Braidpool's payout server, which is seen as a single point of failure. Suggestions are made to use multiple hubs to reduce the risk of a single point of failure. One idea presented is a Lightning model where multiple hubs offer liquidity to the network, and the winning hasher elects one of the hubs to receive the payout. It is acknowledged that getting something working now may be more beneficial than waiting for a perfect solution.ZmnSCPxj points out that Braidpool's payout server remains a single central point of failure despite claims of using Tor hidden service to protect against DDoS attacks. Multiple hubs are suggested as a preferable solution, with Chris Belcher's proposal for using payment channels mentioned as a potential construction for multiple hubs. It is acknowledged that more ideas for decentralization may emerge as Braidpool is built.The benefits of Stratum v2 and its comparison to other mining methods are discussed. It is noted that mining pools still have the ability to reject negotiations and censor payments. Suggestions are made to use Stratum v2 in combination with other technologies, such as discreet log contracts.Braidpool is viewed as an improvement to P2Pool in making a peer-to-peer pool work on a larger scale. It offers transparent views of shares received by the pool, allowing miners to verify reward calculations. It also offers payouts over a one-way channel, unlike P2Pool. Braidpool prepares for future attacks on centralized mining pools while attracting miners to the platform now.In a discussion on centralized mining control and payment censorship, concerns are raised about the control of transaction selection and potential censorship. The use of Lightning Network (LN) for payouts is suggested as a way to mitigate these issues, but the advantages of Braidpool over an idealized version of centralized mining with independent transaction selection are questioned.A comparison is made between a decentralized mining pool using BetterHash or Stratum v2 with LN-based payouts and a centralized mining pool. The advantages of a decentralized pool are highlighted, including the ability for miners to choose their own transactions and prevent any single entity from having control over the selection process.Pool2win proposes a decentralized solution to the problems faced by P2Pool. The proposal aims to provide lower variance for smaller miners and enable a futures market for hash rates. The solution uses a DAG of shares replicated at all miners to compute rewards, with payouts made via one-way payment channels by an anonymous hub communicating through Tor's hidden services. Comparisons to Stratum v2 are not provided.The Pool2Win team develops Braidpool, a decentralized mining pool aimed at overcoming issues faced by P2Pool and enabling a futures market for hash rates. The pool offers lower variance for smaller miners, allows miners to build their own blocks, and provides transparent views of shares received by the pool. Rewards are paid out via one-way payment channels using Tor's hidden services to prevent cheating. The team also provides details on trading hash rate. The ultimate goal is to provide a more efficient and fair mining experience while contributing to Bitcoin's decentralization. 2021-09-13T08:03:42+00:00 + The issue of a malicious miner cheating other miners of their reward is discussed in the context. The problem arises as the bitcoin block is used as the sentinel to mark the shares from DAG that need to be rewarded. A proposed solution is to have the hub broadcast a "sentinel" to mark out the point in logical time up to which shares will be rewarded.A proposal is made to reward miners for creating valid blocks, but concerns are raised about rogue miners avoiding referencing other miners' shares to keep rewards for themselves. Two methods are suggested for resolving conflicts between conflicting versions of the DAG: using the longest chain or the one with more work. However, both methods present issues such as the potential for bad hashers to create low-difficulty shares and then mine and publish higher-difficulty shares without sharing the reward.In an email exchange, questions are raised about the proposal that every share can reference multiple previous shares. Concerns are expressed about rogue miners not referencing any shares from other miners to avoid sharing the reward. Doubts are also raised about how conflicts between different valid states will be resolved.A discussion on the Bitcoin-dev mailing list focuses on the centralization of Braidpool's payout server, which is seen as a single point of failure. Suggestions are made to use multiple hubs to reduce the risk of a single point of failure. One idea presented is a Lightning model where multiple hubs offer liquidity to the network, and the winning hasher elects one of the hubs to receive the payout. It is acknowledged that getting something working now may be more beneficial than waiting for a perfect solution.ZmnSCPxj points out that Braidpool's payout server remains a single central point of failure despite claims of using Tor hidden service to protect against DDoS attacks. Multiple hubs are suggested as a preferable solution, with Chris Belcher's proposal for using payment channels mentioned as a potential construction for multiple hubs. It is acknowledged that more ideas for decentralization may emerge as Braidpool is built.The benefits of Stratum v2 and its comparison to other mining methods are discussed. It is noted that mining pools still have the ability to reject negotiations and censor payments. Suggestions are made to use Stratum v2 in combination with other technologies, such as discreet log contracts.Braidpool is viewed as an improvement to P2Pool in making a peer-to-peer pool work on a larger scale. It offers transparent views of shares received by the pool, allowing miners to verify reward calculations. It also offers payouts over a one-way channel, unlike P2Pool. Braidpool prepares for future attacks on centralized mining pools while attracting miners to the platform now.In a discussion on centralized mining control and payment censorship, concerns are raised about the control of transaction selection and potential censorship. The use of Lightning Network (LN) for payouts is suggested as a way to mitigate these issues, but the advantages of Braidpool over an idealized version of centralized mining with independent transaction selection are questioned.A comparison is made between a decentralized mining pool using BetterHash or Stratum v2 with LN-based payouts and a centralized mining pool. The advantages of a decentralized pool are highlighted, including the ability for miners to choose their own transactions and prevent any single entity from having control over the selection process.Pool2win proposes a decentralized solution to the problems faced by P2Pool. The proposal aims to provide lower variance for smaller miners and enable a futures market for hash rates. The solution uses a DAG of shares replicated at all miners to compute rewards, with payouts made via one-way payment channels by an anonymous hub communicating through Tor's hidden services. Comparisons to Stratum v2 are not provided.The Pool2Win team develops Braidpool, a decentralized mining pool aimed at overcoming issues faced by P2Pool and enabling a futures market for hash rates. The pool offers lower variance for smaller miners, allows miners to build their own blocks, and provides transparent views of shares received by the pool. Rewards are paid out via one-way payment channels using Tor's hidden services to prevent cheating. The team also provides details on trading hash rate. The ultimate goal is to provide a more efficient and fair mining experience while contributing to Bitcoin's decentralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Clarification-on-the-use-of-getblocktemplate-RPC-method-.xml b/static/bitcoin-dev/Sept_2021/combined_Clarification-on-the-use-of-getblocktemplate-RPC-method-.xml index 923f209558..d7c038b29f 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Clarification-on-the-use-of-getblocktemplate-RPC-method-.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Clarification-on-the-use-of-getblocktemplate-RPC-method-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Clarification on the use of getblocktemplate RPC method. - 2023-08-02T04:46:17.286382+00:00 - - Luke Dashjr 2021-09-09 17:36:17+00:00 - - - Mike Rosset 2021-09-09 12:54:18+00:00 - + 2025-09-26T16:02:13.357787+00:00 + python-feedgen + + + [bitcoin-dev] Clarification on the use of getblocktemplate RPC method Mike Rosset + 2021-09-09T12:54:00.000Z + + + Luke Dashjr + 2021-09-09T17:36:00.000Z + + - python-feedgen + 2 Combined summary - Clarification on the use of getblocktemplate RPC method. - 2023-08-02T04:46:17.286382+00:00 + 2025-09-26T16:02:13.358236+00:00 - Mike Rosset, a developer, reached out to the bitcoin-dev mailing list for assistance with inconsistencies he encountered while experimenting with Bitcoin using GNU Guile Scheme. He had created a toy Bitcoin miner and was trying to generate templates for the Merkle root by concatenating transactions data. However, he faced difficulty in creating the coinbase transaction as the json cointbasetxn field was missing in getblocktemplate.In his request for help, Mike shared a test template response data and a modified version of the merkle python reference script from the Bitcoin wiki page. Although he was able to replicate a Merkle root hash (c5fff939f628a04428c080ed5bd7cd9bc0b4722b2522743049adb18213adf28a), it didn't include the coinbase transaction.Mike, who had recently developed an interest in the bitcoin protocol, had been using GNU Guile Scheme to experiment with it. However, he found inconsistencies in the documentation provided on https://en.bitcoin.it/wiki/Getblocktemplate regarding the creation of the Merkle root using templates. According to his understanding, the coinbase transaction should have the transactions data concatenated before generating the Merkle root. However, since getblocktemplate lacked the json cointbasetxn field, he was uncertain how to create a coinbase transaction without it.To resolve this issue, Mike sought guidance in acquiring the coinbase transaction and ensuring that the Merkle roots generated by his Python and Guile implementations matched. He wanted to sanitize his process in Guile by incorporating a coinbase transaction, thus aligning it with the Python implementation.Overall, Mike's objective was to replicate the Merkle root hash (c5fff939f628a04428c080ed5bd7cd9bc0b4722b2522743049adb18213adf28a) using the test data in Guile, while also ensuring that the coinbase transaction was included and that both the Python and Guile Merkle roots matched. 2021-09-09T17:36:17+00:00 + Mike Rosset, a developer, reached out to the bitcoin-dev mailing list for assistance with inconsistencies he encountered while experimenting with Bitcoin using GNU Guile Scheme. He had created a toy Bitcoin miner and was trying to generate templates for the Merkle root by concatenating transactions data. However, he faced difficulty in creating the coinbase transaction as the json cointbasetxn field was missing in getblocktemplate.In his request for help, Mike shared a test template response data and a modified version of the merkle python reference script from the Bitcoin wiki page. Although he was able to replicate a Merkle root hash (c5fff939f628a04428c080ed5bd7cd9bc0b4722b2522743049adb18213adf28a), it didn't include the coinbase transaction.Mike, who had recently developed an interest in the bitcoin protocol, had been using GNU Guile Scheme to experiment with it. However, he found inconsistencies in the documentation provided on https://en.bitcoin.it/wiki/Getblocktemplate regarding the creation of the Merkle root using templates. According to his understanding, the coinbase transaction should have the transactions data concatenated before generating the Merkle root. However, since getblocktemplate lacked the json cointbasetxn field, he was uncertain how to create a coinbase transaction without it.To resolve this issue, Mike sought guidance in acquiring the coinbase transaction and ensuring that the Merkle roots generated by his Python and Guile implementations matched. He wanted to sanitize his process in Guile by incorporating a coinbase transaction, thus aligning it with the Python implementation.Overall, Mike's objective was to replicate the Merkle root hash (c5fff939f628a04428c080ed5bd7cd9bc0b4722b2522743049adb18213adf28a) using the test data in Guile, while also ensuring that the coinbase transaction was included and that both the Python and Guile Merkle roots matched. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Drivechain-BIP-300-and-301.xml b/static/bitcoin-dev/Sept_2021/combined_Drivechain-BIP-300-and-301.xml index dba9585a94..6044ecb7d2 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Drivechain-BIP-300-and-301.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Drivechain-BIP-300-and-301.xml @@ -1,39 +1,48 @@ - + 2 Combined summary - Drivechain: BIP 300 and 301 - 2023-08-02T04:40:01.727250+00:00 - - ZmnSCPxj 2021-09-07 09:37:43+00:00 - - - Prayank 2021-09-03 10:07:55+00:00 - - - Prayank 2021-09-03 09:47:45+00:00 - - - ZmnSCPxj 2021-09-02 21:02:55+00:00 - - - Erik Aronesty 2021-09-02 20:20:21+00:00 - - - Prayank 2021-09-02 17:11:22+00:00 - + 2025-09-26T16:02:23.864012+00:00 + python-feedgen + + + [bitcoin-dev] Drivechain: BIP 300 and 301 Prayank + 2021-09-02T17:11:00.000Z + + + Erik Aronesty + 2021-09-02T20:20:00.000Z + + + ZmnSCPxj + 2021-09-02T21:02:00.000Z + + + Prayank + 2021-09-03T09:47:00.000Z + + + Prayank + 2021-09-03T10:07:00.000Z + + + ZmnSCPxj + 2021-09-07T09:37:00.000Z + + - python-feedgen + 2 Combined summary - Drivechain: BIP 300 and 301 - 2023-08-02T04:40:01.728250+00:00 + 2025-09-26T16:02:23.864880+00:00 - The conversation revolves around the scalability of blockchains and the use of sidechains to prototype new features for blockchain scaling. The idea is to create a federated sidechain as a demonstration and eventually integrate it into the Bitcoin blockchain. Sidechains can be utilized for smart contracts, which are limited on the Bitcoin Layer1, without affecting the base layer. It is mentioned that increasing the Drivechain security parameter can lead to slower sidechain->mainchain withdrawals, acting as a bottleneck for transfer amounts. The requirements for running a node on different sidechains differ, but the Lightning Network (LN) is expected to remain easy to install and maintain.There is a discussion regarding whether Stacks qualifies as a Bitcoin sidechain. It is argued that Stacks is not a sidechain since it has its own native token, which is not pegged to BTC and was premined. While Stacks utilizes Bitcoin as a storage and broadcast medium, some believe that its marketing contains misinformation that does not ultimately benefit Bitcoin.An email exchange between Prayank and ZmnSCPxj explores the distinctions between federated sidechains and Drivechains. Federated sidechains are custodial and rely on a predetermined signing set, while Drivechains employ mainchain miners as custodians. The security parameter in Drivechains affects the ease with which sidechain funds can be confiscated by a 51% attacker, resulting in slower sidechain->mainchain withdrawals. It is suggested that creating a federation with developer friends may be a better option for prototyping new features on sidechains. Rather than creating more blockchains, an alternative solution proposed is a 2-of-2 federation with atomic swap mechanisms, similar to the Lightning Network. Links to information on LND, Liquid, and Rootstock are provided as well.The conversation highlights the contrast between federated sidechains and Drivechains. Federated sidechains are custodial with a fixed signing set, potentially allowing the federation to abscond with the funds. In contrast, Drivechain custody is held by mainchain miners. However, a 51% attacker can confiscate sidechain funds, leading to slower sidechain->mainchain withdrawals and creating a bottleneck for transfer amounts. To counter the risk of confiscation, a "nuclear option" is proposed, where mainchain full nodes are upgraded to ignore historical blocks created by the 51% attacker. It is emphasized that if sidechains are intended for prototyping new features, it is better to create a federation with friends rather than utilizing a large and inefficient data structure like blockchain.The email thread also discusses the proposal for Drivechain in Bitcoin and associated BIPs. Concerns are expressed about the misaligned incentives that may encourage theft and "bad behavior." However, there is no apparent risk to the network itself. Stacks is mentioned as an alternative to Drivechain, capable of achieving similar goals. A comparison is made between Lightning-compatible Mimblewimble and Drivechain, with the former deemed more important for global-scale payments and improved fungibility, which cannot be safely implemented via Drivechain. The email thread provides links to articles, videos, and discussions covering Bitcoin's security, transactions, fees, critiques of Drivechain, and the differences between RSK and Ethereum. The author shares their personal opinion that sidechain projects should be encouraged. Furthermore, the thread addresses misleading information found on a website regarding Bitcoin and Ethereum's blocks mined, UTXO model, and failed transactions paying fees on Ethereum daily.Additionally, the article compares Liquid and Lightning, focusing on their trust models and on-ramps/off-ramps. It also discusses the security of Bitcoin and expected fees on layer 1 due to Drivechain. A Medium post is referenced, highlighting similarities and differences between RSK and Ethereum. A video by Paul Sztorc examines fees in relation to LN, Liquid, and Rootstock. A question on Bitcoin Stackexchange seeks clarification on Bitcoin transactions with layer 2 projects. Two critiques of Drivechain are mentioned on the project website, although the author disagrees with some points. The author expresses a preference for discussing these topics on forums rather than Twitter to avoid misinformation. They further express support for sidechain projects and curiosity about Drivechain. Lastly, improvements that impact fees such as Segwit, Layer 2, Batching, UTXO consolidation, Fee estimation, Coin selection, Exchanges, Wallets, etc. are mentioned. 2021-09-07T09:37:43+00:00 + The conversation revolves around the scalability of blockchains and the use of sidechains to prototype new features for blockchain scaling. The idea is to create a federated sidechain as a demonstration and eventually integrate it into the Bitcoin blockchain. Sidechains can be utilized for smart contracts, which are limited on the Bitcoin Layer1, without affecting the base layer. It is mentioned that increasing the Drivechain security parameter can lead to slower sidechain->mainchain withdrawals, acting as a bottleneck for transfer amounts. The requirements for running a node on different sidechains differ, but the Lightning Network (LN) is expected to remain easy to install and maintain.There is a discussion regarding whether Stacks qualifies as a Bitcoin sidechain. It is argued that Stacks is not a sidechain since it has its own native token, which is not pegged to BTC and was premined. While Stacks utilizes Bitcoin as a storage and broadcast medium, some believe that its marketing contains misinformation that does not ultimately benefit Bitcoin.An email exchange between Prayank and ZmnSCPxj explores the distinctions between federated sidechains and Drivechains. Federated sidechains are custodial and rely on a predetermined signing set, while Drivechains employ mainchain miners as custodians. The security parameter in Drivechains affects the ease with which sidechain funds can be confiscated by a 51% attacker, resulting in slower sidechain->mainchain withdrawals. It is suggested that creating a federation with developer friends may be a better option for prototyping new features on sidechains. Rather than creating more blockchains, an alternative solution proposed is a 2-of-2 federation with atomic swap mechanisms, similar to the Lightning Network. Links to information on LND, Liquid, and Rootstock are provided as well.The conversation highlights the contrast between federated sidechains and Drivechains. Federated sidechains are custodial with a fixed signing set, potentially allowing the federation to abscond with the funds. In contrast, Drivechain custody is held by mainchain miners. However, a 51% attacker can confiscate sidechain funds, leading to slower sidechain->mainchain withdrawals and creating a bottleneck for transfer amounts. To counter the risk of confiscation, a "nuclear option" is proposed, where mainchain full nodes are upgraded to ignore historical blocks created by the 51% attacker. It is emphasized that if sidechains are intended for prototyping new features, it is better to create a federation with friends rather than utilizing a large and inefficient data structure like blockchain.The email thread also discusses the proposal for Drivechain in Bitcoin and associated BIPs. Concerns are expressed about the misaligned incentives that may encourage theft and "bad behavior." However, there is no apparent risk to the network itself. Stacks is mentioned as an alternative to Drivechain, capable of achieving similar goals. A comparison is made between Lightning-compatible Mimblewimble and Drivechain, with the former deemed more important for global-scale payments and improved fungibility, which cannot be safely implemented via Drivechain. The email thread provides links to articles, videos, and discussions covering Bitcoin's security, transactions, fees, critiques of Drivechain, and the differences between RSK and Ethereum. The author shares their personal opinion that sidechain projects should be encouraged. Furthermore, the thread addresses misleading information found on a website regarding Bitcoin and Ethereum's blocks mined, UTXO model, and failed transactions paying fees on Ethereum daily.Additionally, the article compares Liquid and Lightning, focusing on their trust models and on-ramps/off-ramps. It also discusses the security of Bitcoin and expected fees on layer 1 due to Drivechain. A Medium post is referenced, highlighting similarities and differences between RSK and Ethereum. A video by Paul Sztorc examines fees in relation to LN, Liquid, and Rootstock. A question on Bitcoin Stackexchange seeks clarification on Bitcoin transactions with layer 2 projects. Two critiques of Drivechain are mentioned on the project website, although the author disagrees with some points. The author expresses a preference for discussing these topics on forums rather than Twitter to avoid misinformation. They further express support for sidechain projects and curiosity about Drivechain. Lastly, improvements that impact fees such as Segwit, Layer 2, Batching, UTXO consolidation, Fee estimation, Coin selection, Exchanges, Wallets, etc. are mentioned. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Enc-Bitcoin-cold-hardwallet-with-proof-of-creation-.xml b/static/bitcoin-dev/Sept_2021/combined_Enc-Bitcoin-cold-hardwallet-with-proof-of-creation-.xml index 059f438e91..f07a9e16b2 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Enc-Bitcoin-cold-hardwallet-with-proof-of-creation-.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Enc-Bitcoin-cold-hardwallet-with-proof-of-creation-.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Enc: Bitcoin cold hardwallet with (proof of creation) - 2023-08-02T04:52:54.949677+00:00 - - ZmnSCPxj 2021-09-29 21:59:16+00:00 - - - trilemabtc 2021-09-29 17:10:04+00:00 - + 2025-09-26T16:02:49.170880+00:00 + python-feedgen + + + [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation) trilemabtc + 2021-09-29T17:10:00.000Z + + + ZmnSCPxj + 2021-09-29T21:59:00.000Z + + - python-feedgen + 2 Combined summary - Enc: Bitcoin cold hardwallet with (proof of creation) - 2023-08-02T04:52:54.949677+00:00 + 2025-09-26T16:02:49.171295+00:00 - The author of this message proposes an idea for a hardwallet that offers a solution to make funds unseizable using proof of creation through a key file. The concept revolves around the creator being the only person who can reveal the private keys, thus ensuring the security of the funds. The author explains that the basic idea is to combine the private key on the device with a private key generated from the key file, creating a simple 2-of-2 setup. To generate the Bitcoin address, the software would generate a private key from the key file provided by the user and tweak the device pubkey accordingly. In order to spend from the address, both the key file and the device need to be combined. The author mentions that the device can be configured with random entropy separately from the key file, reducing the risk of malware accessing both the entropy and the key file. It's worth noting that the author does not recommend or mention the use of brainwallets, even for keyfiles. The author emphasizes the importance of security and provides a link to a Github directory where further details about the project can be found. Although the author admits not being a developer, they believe that all the necessary elements to execute the project already exist. The message also includes a PGP signature for added security, and no HTML attachment was included. 2021-09-29T21:59:16+00:00 + The author of this message proposes an idea for a hardwallet that offers a solution to make funds unseizable using proof of creation through a key file. The concept revolves around the creator being the only person who can reveal the private keys, thus ensuring the security of the funds. The author explains that the basic idea is to combine the private key on the device with a private key generated from the key file, creating a simple 2-of-2 setup. To generate the Bitcoin address, the software would generate a private key from the key file provided by the user and tweak the device pubkey accordingly. In order to spend from the address, both the key file and the device need to be combined. The author mentions that the device can be configured with random entropy separately from the key file, reducing the risk of malware accessing both the entropy and the key file. It's worth noting that the author does not recommend or mention the use of brainwallets, even for keyfiles. The author emphasizes the importance of security and provides a link to a Github directory where further details about the project can be found. Although the author admits not being a developer, they believe that all the necessary elements to execute the project already exist. The message also includes a PGP signature for added security, and no HTML attachment was included. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml b/static/bitcoin-dev/Sept_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml index edbed065d9..509d93b925 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Exploring-limiting-transaction-output-amount-as-a-function-of-total-input-value.xml @@ -1,65 +1,39 @@ - + 2 Combined summary - Exploring: limiting transaction output amount as a function of total input value - 2023-08-02T04:27:02.335436+00:00 - - Zac Greenwood 2021-09-01 15:15:30+00:00 - - - ZmnSCPxj 2021-08-31 14:22:29+00:00 - - - Zac Greenwood 2021-08-31 14:09:04+00:00 - - - ZmnSCPxj 2021-08-31 09:00:15+00:00 - - - Zac Greenwood 2021-08-30 14:43:30+00:00 - - - ZmnSCPxj 2021-08-16 11:48:43+00:00 - - - Zac Greenwood 2021-08-16 11:17:19+00:00 - - - ZmnSCPxj 2021-08-14 01:50:45+00:00 - - - Zac Greenwood 2021-08-13 11:02:14+00:00 - - - ZmnSCPxj 2021-08-10 02:17:47+00:00 - - - Billy Tetrud 2021-08-10 00:41:12+00:00 - - - Zac Greenwood 2021-08-05 14:22:12+00:00 - - - Billy Tetrud 2021-08-05 06:39:34+00:00 - - - Zac Greenwood 2021-08-04 10:48:44+00:00 - - - Billy Tetrud 2021-08-03 18:12:28+00:00 - - - Zac Greenwood 2021-08-02 09:32:36+00:00 - - - Billy Tetrud 2021-08-02 04:40:47+00:00 - - - Zac Greenwood 2021-08-01 08:09:26+00:00 - - - Zac Greenwood 2021-07-31 20:01:49+00:00 - + 2025-09-26T16:02:38.643344+00:00 + python-feedgen + + + [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood + 2021-08-01T08:09:00.000Z + + + Zac Greenwood + 2021-08-02T09:32:00.000Z + + + Billy Tetrud + 2021-08-03T18:12:00.000Z + + + Zac Greenwood + 2021-08-04T10:48:00.000Z + + + Billy Tetrud + 2021-08-05T06:39:00.000Z + + + Zac Greenwood + 2021-08-05T14:22:00.000Z + + + Billy Tetrud + 2021-08-10T00:41:00.000Z + + @@ -79,13 +53,13 @@ - python-feedgen + 2 Combined summary - Exploring: limiting transaction output amount as a function of total input value - 2023-08-02T04:27:02.335436+00:00 + 2025-09-26T16:02:38.644211+00:00 - The email thread discusses the implementation of a rate-limiting algorithm in a privacy-preserving manner. The proposed algorithm involves creating an output at a specific block height [h0] that serves as input and limits the maximum amount that can be sent. This rule is permanent and always copied over to a change output. At another block height [h1], a transaction occurs, spending a certain amount [h1_spent]. The payment output created at [h1] is not restricted, while the change output must be encumbered with a second transaction occurring at another block height [h2], spending a certain amount [h2_spent]. However, implementing this algorithm in a privacy-preserving way poses challenges, as it reduces the anonymity set for everyone and makes the payment and change outputs identifiable on-chain. The author suggests using clever MAST-fu in covenant schemes to address these challenges. Several proposals for such covenant schemes exist, but none have gained significant traction.In their email exchange, Zac and ZmnSCPxj discuss the potential reduction of privacy in a proposal due to the introduction of a new type of transaction. This would decrease the anonymity set for everyone and result in identifiable payment and change outputs. Zac proposes using clever MAST-fu to resolve these issues but lacks the technical skills to determine if it's possible. ZmnSCPxj directs Zac towards covenant efforts with MAST-integration developed by aj and RubenSomsen. While various proposals exist, ZmnSCPxj cannot pinpoint one that seems likely to gain significant traction.Zac expresses concerns about the privacy implications of a proposed algorithm that requires a new type of transaction and encumbered change outputs. ZmnSCPxj explains that this proposal would reduce privacy by decreasing the anonymity set for everyone, making payment and change outputs identifiable, and requiring visible on-chain specifics regarding how the output is encumbered. Zac believes that the functionality should not justify the privacy reductions unless these concerns can be addressed. ZmnSCPxj provides further details about the challenges involved in implementing the proposal, including explicit flagging and data storage requirements for each output. These challenges make implementation without consensus code changes difficult, but dropping the "change outputs must also be rate-limited" requirement could improve privacy and ease implementation.ZmnSCPxj's email discusses the potential costs and benefits of implementing a proposal. One issue is the need for explicit visibility to implement the "change outputs must also be rate-limited" requirement. Two options, allocating new SegWit versions or using anyone-can-spend `scriptPubKey` templates, have drawbacks related to privacy concerns. Another challenge is storing data with each output, which increases the size of stored outputs. Ideally, outputs should only contain commitments rather than actual data. However, explicit tagging is necessary to ensure rate-limiting of change outputs, which adds to the amount of data required. The residual limit also needs to be kept with the output. Dropping the "change outputs must also be rate-limited" requirement would address some gaps in the proposal but reduce privacy. Overall, the email highlights various challenges and considerations for implementing this proposal.Zac and ZmnSCPxj discuss the functionality of limiting the amount spent from an address within a certain timeframe. Zac proposes implementing consensus changes to support this functionality, while ZmnSCPxj suggests using covenant opcodes instead. However, there are multiple proposals with overlapping abilities and tradeoffs, potentially leading to disagreements. Zac requests more information on what is needed to implement his unmodified proposal so that the community can assess the cost versus the benefits. He acknowledges that consensus changes take years but believes it is essential to explore the appetite for the proposed functionality and possible technical solutions.Zac and ZmnSCPxj agree on the importance of determining whether the proposed functionality can be implemented without consensus changes. ZmnSCPxj presents a technical counterproposal that explores an implementation on top of the existing Bitcoin system. They discuss the differences between the proposals, highlighting significant gaps. Zac believes that the counterproposal does not meet the basic requirements of the original proposal and prefers implementing consensus changes to support the functionality. They suggest looking into covenant opcodes as an alternative to the counterproposal, as they closely align with one of the motivating examples for covenants. The conversation emphasizes the need to address the gaps between the proposals.In their conversation, Zac proposes functionality that allows control of a coin using two private keys, with spending limited over time for one key and unrestricted for the other. ZmnSCPxj presents a counterproposal using `nSequence` in relative-locktime mode but acknowledges its disadvantages, including obviousness and limits on the number of windows. Zac argues that implementing consensus changes to support the proposed functionality would be preferable over the counterproposal. However, ZmnSCPxj contends that the functionality can be implemented using `nSequence`-in-relative-locktime-mode without any consensus changes. They agree that the functionality is 2021-09-01T15:15:30+00:00 + The email thread discusses the implementation of a rate-limiting algorithm in a privacy-preserving manner. The proposed algorithm involves creating an output at a specific block height [h0] that serves as input and limits the maximum amount that can be sent. This rule is permanent and always copied over to a change output. At another block height [h1], a transaction occurs, spending a certain amount [h1_spent]. The payment output created at [h1] is not restricted, while the change output must be encumbered with a second transaction occurring at another block height [h2], spending a certain amount [h2_spent]. However, implementing this algorithm in a privacy-preserving way poses challenges, as it reduces the anonymity set for everyone and makes the payment and change outputs identifiable on-chain. The author suggests using clever MAST-fu in covenant schemes to address these challenges. Several proposals for such covenant schemes exist, but none have gained significant traction.In their email exchange, Zac and ZmnSCPxj discuss the potential reduction of privacy in a proposal due to the introduction of a new type of transaction. This would decrease the anonymity set for everyone and result in identifiable payment and change outputs. Zac proposes using clever MAST-fu to resolve these issues but lacks the technical skills to determine if it's possible. ZmnSCPxj directs Zac towards covenant efforts with MAST-integration developed by aj and RubenSomsen. While various proposals exist, ZmnSCPxj cannot pinpoint one that seems likely to gain significant traction.Zac expresses concerns about the privacy implications of a proposed algorithm that requires a new type of transaction and encumbered change outputs. ZmnSCPxj explains that this proposal would reduce privacy by decreasing the anonymity set for everyone, making payment and change outputs identifiable, and requiring visible on-chain specifics regarding how the output is encumbered. Zac believes that the functionality should not justify the privacy reductions unless these concerns can be addressed. ZmnSCPxj provides further details about the challenges involved in implementing the proposal, including explicit flagging and data storage requirements for each output. These challenges make implementation without consensus code changes difficult, but dropping the "change outputs must also be rate-limited" requirement could improve privacy and ease implementation.ZmnSCPxj's email discusses the potential costs and benefits of implementing a proposal. One issue is the need for explicit visibility to implement the "change outputs must also be rate-limited" requirement. Two options, allocating new SegWit versions or using anyone-can-spend `scriptPubKey` templates, have drawbacks related to privacy concerns. Another challenge is storing data with each output, which increases the size of stored outputs. Ideally, outputs should only contain commitments rather than actual data. However, explicit tagging is necessary to ensure rate-limiting of change outputs, which adds to the amount of data required. The residual limit also needs to be kept with the output. Dropping the "change outputs must also be rate-limited" requirement would address some gaps in the proposal but reduce privacy. Overall, the email highlights various challenges and considerations for implementing this proposal.Zac and ZmnSCPxj discuss the functionality of limiting the amount spent from an address within a certain timeframe. Zac proposes implementing consensus changes to support this functionality, while ZmnSCPxj suggests using covenant opcodes instead. However, there are multiple proposals with overlapping abilities and tradeoffs, potentially leading to disagreements. Zac requests more information on what is needed to implement his unmodified proposal so that the community can assess the cost versus the benefits. He acknowledges that consensus changes take years but believes it is essential to explore the appetite for the proposed functionality and possible technical solutions.Zac and ZmnSCPxj agree on the importance of determining whether the proposed functionality can be implemented without consensus changes. ZmnSCPxj presents a technical counterproposal that explores an implementation on top of the existing Bitcoin system. They discuss the differences between the proposals, highlighting significant gaps. Zac believes that the counterproposal does not meet the basic requirements of the original proposal and prefers implementing consensus changes to support the functionality. They suggest looking into covenant opcodes as an alternative to the counterproposal, as they closely align with one of the motivating examples for covenants. The conversation emphasizes the need to address the gaps between the proposals.In their conversation, Zac proposes functionality that allows control of a coin using two private keys, with spending limited over time for one key and unrestricted for the other. ZmnSCPxj presents a counterproposal using `nSequence` in relative-locktime mode but acknowledges its disadvantages, including obviousness and limits on the number of windows. Zac argues that implementing consensus changes to support the proposed functionality would be preferable over the counterproposal. However, ZmnSCPxj contends that the functionality can be implemented using `nSequence`-in-relative-locktime-mode without any consensus changes. They agree that the functionality is - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Human-readable-checksum-verification-code-to-avoid-errors-on-BTC-public-addresses.xml b/static/bitcoin-dev/Sept_2021/combined_Human-readable-checksum-verification-code-to-avoid-errors-on-BTC-public-addresses.xml index 0e287df402..7bceb8cca0 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Human-readable-checksum-verification-code-to-avoid-errors-on-BTC-public-addresses.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Human-readable-checksum-verification-code-to-avoid-errors-on-BTC-public-addresses.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Human readable checksum (verification code) to avoid errors on BTC public addresses - 2023-08-02T04:36:53.862644+00:00 - - ts 2021-09-03 05:08:42+00:00 - - - Marek Palatinus 2021-08-31 08:47:26+00:00 - - - ts 2021-08-31 02:17:07+00:00 - - - ts 2021-08-31 02:16:00+00:00 - - - Pieter Wuille 2021-08-29 14:42:07+00:00 - - - Pieter Wuille 2021-08-29 14:24:48+00:00 - - - ts 2021-08-28 21:17:35+00:00 - - - ts 2021-08-21 04:52:26+00:00 - - - ts 2021-08-21 04:52:16+00:00 - - - Karl 2021-08-19 21:05:28+00:00 - - - Christopher Allen 2021-08-19 17:37:29+00:00 - - - ts 2021-08-19 17:02:38+00:00 - - - ZmnSCPxj 2021-08-16 10:34:36+00:00 - - - ts 2021-08-16 04:23:25+00:00 - + 2025-09-26T16:02:21.775835+00:00 + python-feedgen + + + [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses ts + 2021-08-16T04:23:00.000Z + + + ZmnSCPxj + 2021-08-16T10:34:00.000Z + + + ts + 2021-08-19T17:02:00.000Z + + + Christopher Allen + 2021-08-19T17:37:00.000Z + + + Karl + 2021-08-19T21:05:00.000Z + + + ts + 2021-08-21T04:52:00.000Z + + + ts + 2021-08-21T04:52:00.000Z + + + ts + 2021-08-28T21:17:00.000Z + + + Pieter Wuille + 2021-08-29T14:24:00.000Z + + + Pieter Wuille + 2021-08-29T14:42:00.000Z + + + ts + 2021-08-31T02:16:00.000Z + + + ts + 2021-08-31T02:17:00.000Z + + + Marek Palatinus + 2021-08-31T08:47:00.000Z + + + ts + 2021-09-03T05:08:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Human readable checksum (verification code) to avoid errors on BTC public addresses - 2023-08-02T04:36:53.862644+00:00 + 2025-09-26T16:02:21.777548+00:00 - One solution to reduce the probability of performing transactions to the wrong address is to match the DC (destination checksum) from the receiving address. This implementation is relatively simple, but it requires agreement on a checksum standard for generating the code. Once this standard is established, developers of wallets and exchanges can begin implementing it.To encourage fast adoption, it would be helpful to have a catchy name for this code, such as "human readable checksum," "verification code," or "4DC." This solution could potentially be used for all other coins and networks, although it is ideal for each to have its own checksum algorithm. This would prevent funds from being sent to the wrong network, especially in cases where the address standard is the same, like with BTC and BCH.The hope is that Bitcoin can lead the way in implementing this solution and serve as an example for other coins and networks to follow suit. By adopting this method, the likelihood of mistakenly sending transactions to the wrong address can be greatly reduced. 2021-09-03T05:08:42+00:00 + One solution to reduce the probability of performing transactions to the wrong address is to match the DC (destination checksum) from the receiving address. This implementation is relatively simple, but it requires agreement on a checksum standard for generating the code. Once this standard is established, developers of wallets and exchanges can begin implementing it.To encourage fast adoption, it would be helpful to have a catchy name for this code, such as "human readable checksum," "verification code," or "4DC." This solution could potentially be used for all other coins and networks, although it is ideal for each to have its own checksum algorithm. This would prevent funds from being sent to the wrong network, especially in cases where the address standard is the same, like with BTC and BCH.The hope is that Bitcoin can lead the way in implementing this solution and serve as an example for other coins and networks to follow suit. By adopting this method, the likelihood of mistakenly sending transactions to the wrong address can be greatly reduced. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml b/static/bitcoin-dev/Sept_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml index 7480e0536e..98d641e843 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml @@ -1,27 +1,29 @@ - + 2 Combined summary - Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin - 2023-08-02T04:51:01.569843+00:00 - - Jeremy 2021-09-24 07:27:03+00:00 - - - Anthony Towns 2021-09-18 11:37:40+00:00 - - - Jeremy 2021-09-17 16:58:45+00:00 - + 2025-09-26T16:02:32.217804+00:00 + python-feedgen + + + [bitcoin-dev] [Lightning-dev] " ZmnSCPxj + 2021-09-21T02:11:00.000Z + + + Jeremy + 2021-09-24T07:27:00.000Z + + - python-feedgen + 2 Combined summary - Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin - 2023-08-02T04:51:01.569843+00:00 + 2025-09-26T16:02:32.218230+00:00 - John Law has shared his responses regarding btc-iids on his Github repository. He suggests responding to him through Github issue or similar platforms. The link to his Github repo is https://github.com/JohnLaw2/btc-iids.In an alternative proposal to BIP-118, John Law introduces Inherited IDs (IIDs), a new method that involves adding a resettable "structural" transaction ID called an "iid" to each UTXO. With IIDs, input transactions can be identified when signing, allowing for valid signatures even if the transaction details change but not its structure. The proposal also includes a tagging system using segwit v2 outputs to identify tagged outputs.The proposal also presents a protocol called "2stage" that enables fast closing of channels with two participants. However, this protocol is not applicable to more than two participants due to the risk of collusion. To address this limitation, invalidation trees are introduced to update the split of funds between groups of participants in channel factories. This introduces a tradeoff between the number of updates allowed, the time available to notice and correct a proposed close, and the initial extraction time for funds from the factory. A hierarchy of update transactions is proposed to reduce delays significantly.The IID proposal is compared to eltoo and statechains, with a focus on two-party channels. In uncooperative cases, the multisig iid factories approach requires log(n) transactions for the invalidation tree and log(n) time for delay to prevent the publication of invalidated states. On the other hand, eltoo requires one transaction and one block after the user notices, along with a fixed CSV delay. Lightning networks face challenges with layered commitments in both the delays while waiting for potential rejection in 2stage and the invalidation tree delays in factory construction.Implementing the "iid" concept would necessitate adding information to the UTXO database, resulting in a potential 1.4GB increase. However, iid transactions are expected to be infrequent and short-lived. The proposal is also compared to using ANYPREVOUT, which simulates the construction of IIDs without requiring additional changes beyond those needed for introducing ANYPREVOUT.In summary, the Inherited IDs (IIDs) proposal by John Law offers an alternative to BIP-118, introducing a new method that adds resettable "iid" transaction IDs to UTXOs. The proposal includes a tagging system and a protocol called "2stage" for fast channel closing. It also introduces invalidation trees for channel factories and suggests a hierarchy of update transactions to reduce delays. Implementing IIDs would require adding information to the UTXO database, potentially increasing its size. The proposal is compared to eltoo and statechains, with acknowledgments given to Ruben Somsen and Jeremy Rubin for their helpful comments and Bob McElrath for his original brainstorming that led to the creation of the IID concept. References to related resources such as BIP-118, eltoo, Bitcoin Lightning Network, and scalable funding of Bitcoin micropayment channel networks are provided. 2021-09-24T07:27:03+00:00 + John Law has shared his responses regarding btc-iids on his Github repository. He suggests responding to him through Github issue or similar platforms. The link to his Github repo is https://github.com/JohnLaw2/btc-iids.In an alternative proposal to BIP-118, John Law introduces Inherited IDs (IIDs), a new method that involves adding a resettable "structural" transaction ID called an "iid" to each UTXO. With IIDs, input transactions can be identified when signing, allowing for valid signatures even if the transaction details change but not its structure. The proposal also includes a tagging system using segwit v2 outputs to identify tagged outputs.The proposal also presents a protocol called "2stage" that enables fast closing of channels with two participants. However, this protocol is not applicable to more than two participants due to the risk of collusion. To address this limitation, invalidation trees are introduced to update the split of funds between groups of participants in channel factories. This introduces a tradeoff between the number of updates allowed, the time available to notice and correct a proposed close, and the initial extraction time for funds from the factory. A hierarchy of update transactions is proposed to reduce delays significantly.The IID proposal is compared to eltoo and statechains, with a focus on two-party channels. In uncooperative cases, the multisig iid factories approach requires log(n) transactions for the invalidation tree and log(n) time for delay to prevent the publication of invalidated states. On the other hand, eltoo requires one transaction and one block after the user notices, along with a fixed CSV delay. Lightning networks face challenges with layered commitments in both the delays while waiting for potential rejection in 2stage and the invalidation tree delays in factory construction.Implementing the "iid" concept would necessitate adding information to the UTXO database, resulting in a potential 1.4GB increase. However, iid transactions are expected to be infrequent and short-lived. The proposal is also compared to using ANYPREVOUT, which simulates the construction of IIDs without requiring additional changes beyond those needed for introducing ANYPREVOUT.In summary, the Inherited IDs (IIDs) proposal by John Law offers an alternative to BIP-118, introducing a new method that adds resettable "iid" transaction IDs to UTXOs. The proposal includes a tagging system and a protocol called "2stage" for fast channel closing. It also introduces invalidation trees for channel factories and suggests a hierarchy of update transactions to reduce delays. Implementing IIDs would require adding information to the UTXO database, potentially increasing its size. The proposal is compared to eltoo and statechains, with acknowledgments given to Ruben Somsen and Jeremy Rubin for their helpful comments and Bob McElrath for his original brainstorming that led to the creation of the IID concept. References to related resources such as BIP-118, eltoo, Bitcoin Lightning Network, and scalable funding of Bitcoin micropayment channel networks are provided. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml b/static/bitcoin-dev/Sept_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml index af01d37ac0..70fcd8ddf4 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Mock-introducing-vulnerability-in-important-Bitcoin-projects.xml @@ -1,50 +1,67 @@ - + 2 Combined summary - Mock introducing vulnerability in important Bitcoin projects - 2023-08-02T04:51:41.971421+00:00 - - Anthony Towns 2022-08-19 03:09:46+00:00 - - - Prayank 2021-11-18 20:29:24+00:00 - - - ZmnSCPxj 2021-10-04 03:59:34+00:00 - - - Luke Dashjr 2021-10-03 21:33:43+00:00 - - - Manuel Costa 2021-10-03 09:11:53+00:00 - - - Prayank 2021-10-02 09:19:37+00:00 - - - Ryan Grant 2021-10-01 20:15:56+00:00 - - - Prayank 2021-10-01 15:55:15+00:00 - - - ZmnSCPxj 2021-10-01 12:27:19+00:00 - - - Prayank 2021-10-01 03:03:00+00:00 - - - Ruben Somsen 2021-09-30 20:36:08+00:00 - - - Prayank 2021-09-27 23:19:40+00:00 - - - ZmnSCPxj 2021-09-27 10:13:02+00:00 - - - Prayank 2021-09-27 01:52:41+00:00 - + 2025-09-26T16:02:11.267599+00:00 + python-feedgen + + + [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects Prayank + 2021-09-27T01:52:00.000Z + + + ZmnSCPxj + 2021-09-27T10:13:00.000Z + + + Prayank + 2021-09-27T23:19:00.000Z + + + Ruben Somsen + 2021-09-30T20:36:00.000Z + + + Prayank + 2021-10-01T03:03:00.000Z + + + ZmnSCPxj + 2021-10-01T12:27:00.000Z + + + Prayank + 2021-10-01T15:55:00.000Z + + + Ryan Grant + 2021-10-01T20:15:00.000Z + + + Prayank + 2021-10-02T09:19:00.000Z + + + Manuel Costa + 2021-10-03T09:11:00.000Z + + + Luke Dashjr + 2021-10-03T21:33:00.000Z + + + ZmnSCPxj + 2021-10-04T03:59:00.000Z + + + Prayank + 2021-11-18T20:29:00.000Z + + + Anthony Towns + 2022-08-19T03:09:00.000Z + + @@ -59,13 +76,13 @@ - python-feedgen + 2 Combined summary - Mock introducing vulnerability in important Bitcoin projects - 2023-08-02T04:51:41.971421+00:00 + 2025-09-26T16:02:11.269164+00:00 - In November 2021, Prayank announced an exercise to test the review process in three Bitcoin projects: Bitcoin Core, LND, and Bisq. They created a salted hash for the username and planned to create pull requests over the next six months. If vulnerabilities were caught during the review process, they would publicly announce them, but if not, they would privately reveal them later. However, after nine months, there has been no public report on the exercise, leaving it unclear whether any vulnerabilities have been introduced.The email conversation emphasizes the importance of regularly testing and verifying the review process in open-source Bitcoin projects. One participant suggests using commit messages with specific requirements to test the process against attacks. Another participant proposes that developers should be forced to opt-in to practice rounds of testing, as they cannot opt-out of potential real-world attacks. The email concludes by emphasizing the importance of independent thought during the review process.ZmnSCPxj suggests improving the review process to prevent attacks and waste contributors' time. They propose a scheme involving commit messages with specific requirements and the option for developers to opt-out of the study. However, they note that developers cannot opt out of potential NSA attacks.A discussion thread raises concerns about potential attempts to introduce vulnerabilities into Bitcoin Core codebase. Some proposals suggest a "Red Team exercise" to test the system's resilience. Others argue for improving the review process instead. The proposed exercise would involve public precommitments collected at ceremonial intervals, with community approval granted for the inserted security flaws.The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes are proposed, including a sortition system. The ideal process involves one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The process includes public precommitments and the use of block hashes as a random oracle.The post proposes a scheme to improve security in Bitcoin development using a sortition system. The scheme involves public precommitments collected at ceremonial intervals, with hash1 being a sortition ticket and hash2 being a public precommitment. The random oracle could be block hashes, and the red-team-concurrency difficulty parameter could control the selection process. The developer would have community approval to opportunistically insert a security flaw.The proposed exercise aims to improve the reputation factor and review attention for new pull requests. It suggests a secret sortition system to encourage more developers to participate without harming their reputation. The scheme includes public precommitments collected at ceremonial intervals and a red-team-concurrency difficulty parameter.The email exchange between Prayank and ZmnSCPxj discusses the importance of review processes in open-source Bitcoin projects. They agree on the necessity of reviews to catch vulnerabilities and caution against using unmerged PRs in production without careful review. Prayank proposes an exercise to test the review process by introducing vulnerability-adding PRs, while ZmnSCPxj emphasizes the need for private handling of any vulnerabilities found.The email discussion highlights the importance of review processes for ensuring security in Bitcoin development. The group agrees that relying on reviews is better for security and discusses the value of testing vulnerabilities in the review process. They propose a plan to create pseudonyms and introduce vulnerability-adding PRs to targets to test the review processes. The plan includes inserting random numbers among the commitments and publicly praising successful reviews.Prayank's proposal to conduct an exercise to study vulnerabilities in Bitcoin projects is met with caution. Ruben Somsen advises getting approval from contributors before proceeding to avoid causing mistrust and extra work for existing contributors. Prayank emphasizes reviewing pull requests based on code rather than author claims and asks whether trusting authors or having a good review process is better for security. They mention several Bitcoin projects they plan to test and note that x00 will assist them in the exercise.Prayank proposes an exercise to study vulnerabilities in Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating new GitHub accounts, studying issues in various Bitcoin projects, preparing pull requests to introduce vulnerabilities, and documenting the results. x00 will assist Prayank in this exercise, which has no fixed completion date.The email thread discusses introducing vulnerabilities in Bitcoin projects and observing how maintainers and reviewers respond. Ruben Somsen advises caution and suggests obtaining approval from contributors beforehand. ZmnSCPxj proposes a method using hash names and randomized salt as precommitments. They also highlight the potential impact on existing contributors and refer to a similar event in the Linux community.Prayank proposes an exercise to introduce vulnerabilities in Bitcoin projects and document the responses of maintainers and reviewers. They plan to create new GitHub accounts, study issues in various Bitcoin projects, and prepare pull requests to introduce vulnerabilities. They mention x00 as someone who will assist them in the exercise.In an email exchange, Prayank proposes an exercise to introduce vulnerabilities in various important Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating 2022-08-19T03:09:46+00:00 + In November 2021, Prayank announced an exercise to test the review process in three Bitcoin projects: Bitcoin Core, LND, and Bisq. They created a salted hash for the username and planned to create pull requests over the next six months. If vulnerabilities were caught during the review process, they would publicly announce them, but if not, they would privately reveal them later. However, after nine months, there has been no public report on the exercise, leaving it unclear whether any vulnerabilities have been introduced.The email conversation emphasizes the importance of regularly testing and verifying the review process in open-source Bitcoin projects. One participant suggests using commit messages with specific requirements to test the process against attacks. Another participant proposes that developers should be forced to opt-in to practice rounds of testing, as they cannot opt-out of potential real-world attacks. The email concludes by emphasizing the importance of independent thought during the review process.ZmnSCPxj suggests improving the review process to prevent attacks and waste contributors' time. They propose a scheme involving commit messages with specific requirements and the option for developers to opt-out of the study. However, they note that developers cannot opt out of potential NSA attacks.A discussion thread raises concerns about potential attempts to introduce vulnerabilities into Bitcoin Core codebase. Some proposals suggest a "Red Team exercise" to test the system's resilience. Others argue for improving the review process instead. The proposed exercise would involve public precommitments collected at ceremonial intervals, with community approval granted for the inserted security flaws.The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes are proposed, including a sortition system. The ideal process involves one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The process includes public precommitments and the use of block hashes as a random oracle.The post proposes a scheme to improve security in Bitcoin development using a sortition system. The scheme involves public precommitments collected at ceremonial intervals, with hash1 being a sortition ticket and hash2 being a public precommitment. The random oracle could be block hashes, and the red-team-concurrency difficulty parameter could control the selection process. The developer would have community approval to opportunistically insert a security flaw.The proposed exercise aims to improve the reputation factor and review attention for new pull requests. It suggests a secret sortition system to encourage more developers to participate without harming their reputation. The scheme includes public precommitments collected at ceremonial intervals and a red-team-concurrency difficulty parameter.The email exchange between Prayank and ZmnSCPxj discusses the importance of review processes in open-source Bitcoin projects. They agree on the necessity of reviews to catch vulnerabilities and caution against using unmerged PRs in production without careful review. Prayank proposes an exercise to test the review process by introducing vulnerability-adding PRs, while ZmnSCPxj emphasizes the need for private handling of any vulnerabilities found.The email discussion highlights the importance of review processes for ensuring security in Bitcoin development. The group agrees that relying on reviews is better for security and discusses the value of testing vulnerabilities in the review process. They propose a plan to create pseudonyms and introduce vulnerability-adding PRs to targets to test the review processes. The plan includes inserting random numbers among the commitments and publicly praising successful reviews.Prayank's proposal to conduct an exercise to study vulnerabilities in Bitcoin projects is met with caution. Ruben Somsen advises getting approval from contributors before proceeding to avoid causing mistrust and extra work for existing contributors. Prayank emphasizes reviewing pull requests based on code rather than author claims and asks whether trusting authors or having a good review process is better for security. They mention several Bitcoin projects they plan to test and note that x00 will assist them in the exercise.Prayank proposes an exercise to study vulnerabilities in Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating new GitHub accounts, studying issues in various Bitcoin projects, preparing pull requests to introduce vulnerabilities, and documenting the results. x00 will assist Prayank in this exercise, which has no fixed completion date.The email thread discusses introducing vulnerabilities in Bitcoin projects and observing how maintainers and reviewers respond. Ruben Somsen advises caution and suggests obtaining approval from contributors beforehand. ZmnSCPxj proposes a method using hash names and randomized salt as precommitments. They also highlight the potential impact on existing contributors and refer to a similar event in the Linux community.Prayank proposes an exercise to introduce vulnerabilities in Bitcoin projects and document the responses of maintainers and reviewers. They plan to create new GitHub accounts, study issues in various Bitcoin projects, and prepare pull requests to introduce vulnerabilities. They mention x00 as someone who will assist them in the exercise.In an email exchange, Prayank proposes an exercise to introduce vulnerabilities in various important Bitcoin projects and observe the responses of maintainers and reviewers. The exercise involves creating - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Note-on-Sequence-Lock-Upgrades-Defect.xml b/static/bitcoin-dev/Sept_2021/combined_Note-on-Sequence-Lock-Upgrades-Defect.xml index a5bebdf798..a9755e72bd 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Note-on-Sequence-Lock-Upgrades-Defect.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Note-on-Sequence-Lock-Upgrades-Defect.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Note on Sequence Lock Upgrades Defect - 2023-08-02T04:40:16.815145+00:00 - - Jeremy 2021-09-09 01:04:53+00:00 - - - Antoine Riard 2021-09-09 00:02:45+00:00 - - - darosior 2021-09-06 06:16:44+00:00 - - - Jeremy 2021-09-06 03:17:17+00:00 - - - David A. Harding 2021-09-06 02:35:25+00:00 - - - Jeremy 2021-09-05 03:19:57+00:00 - - - Jeremy 2021-09-04 03:32:19+00:00 - + 2025-09-26T16:02:19.683744+00:00 + python-feedgen + + + [bitcoin-dev] Note on Sequence Lock Upgrades Defect Jeremy + 2021-09-04T03:32:00.000Z + + + Jeremy + 2021-09-05T03:19:00.000Z + + + David A. Harding + 2021-09-06T02:35:00.000Z + + + Jeremy + 2021-09-06T03:17:00.000Z + + + darosior + 2021-09-06T06:16:00.000Z + + + Antoine Riard + 2021-09-09T00:02:00.000Z + + + Jeremy + 2021-09-09T01:04:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Note on Sequence Lock Upgrades Defect - 2023-08-02T04:40:16.816144+00:00 + 2025-09-26T16:02:19.684665+00:00 - Jeremy Rubin has proposed a patch to fix a flaw in the Sequence lock implementation related to upgradability. The flaw is that the current mempool policies signaling are not separated from consensus data, which can cause problems for L2 nodes and counterparties who want to update their mempool policies non-interactively. Jeremy suggests introducing a new field to signal policy through p2p packages, but notes that this could be vulnerable to tampering by malicious peers.The discussion also revolves around the implications of taking back the `nSequence` field for consensus-semantic sounds. It is argued that this could deprive the application-layer from a discrete, zero-cost payload, while increasing the price of such applications if they still relay application-specific data through the p2p network. Different types of policy deployments are distinguished: loosening changes, tightening changes, and new feature introductions. Loosening changes do not require much ecosystem coordination, whereas flag day activations might make sense for tightening changes to create a higher level of commitment by the base layer software.Regarding the proposed policy change in #22871, the suggestion is to deploy full-rbf first, give time for higher applications to free up the `nSequence` field, and then start discouraging its usage. The user warns against reversing the process and asking for Bitcoin applications/higher layers to update first, as it could result in never making the change. Introducing discouragement waivers would move away from the policy design principle of separating mempool policies signaling from consensus data.In addition to Jeremy's proposed patch, other discussions revolve around using tx.version=2 for new nSequence rules and whether transactions with a version less than 2 are supported. There is also a discussion about the sequence values used by wallet implementations and whether any numbers besides 0xfffffffd are expected to be broadcastable with the DISABLE flag set. The advantages of using 0xfffffffd versus just 0 are debated, and the consensus on common usage is unclear.Overall, Jeremy Rubin's patch aims to fix a flaw in the Sequence lock implementation related to upgradability. The proposal includes separating mempool policies signaling from consensus data, introducing a new field for policy signaling through p2p packages, and deploying changes in a phased manner to ensure smooth policy deployment without disrupting existing applications. 2021-09-09T01:04:53+00:00 + Jeremy Rubin has proposed a patch to fix a flaw in the Sequence lock implementation related to upgradability. The flaw is that the current mempool policies signaling are not separated from consensus data, which can cause problems for L2 nodes and counterparties who want to update their mempool policies non-interactively. Jeremy suggests introducing a new field to signal policy through p2p packages, but notes that this could be vulnerable to tampering by malicious peers.The discussion also revolves around the implications of taking back the `nSequence` field for consensus-semantic sounds. It is argued that this could deprive the application-layer from a discrete, zero-cost payload, while increasing the price of such applications if they still relay application-specific data through the p2p network. Different types of policy deployments are distinguished: loosening changes, tightening changes, and new feature introductions. Loosening changes do not require much ecosystem coordination, whereas flag day activations might make sense for tightening changes to create a higher level of commitment by the base layer software.Regarding the proposed policy change in #22871, the suggestion is to deploy full-rbf first, give time for higher applications to free up the `nSequence` field, and then start discouraging its usage. The user warns against reversing the process and asking for Bitcoin applications/higher layers to update first, as it could result in never making the change. Introducing discouragement waivers would move away from the policy design principle of separating mempool policies signaling from consensus data.In addition to Jeremy's proposed patch, other discussions revolve around using tx.version=2 for new nSequence rules and whether transactions with a version less than 2 are supported. There is also a discussion about the sequence values used by wallet implementations and whether any numbers besides 0xfffffffd are expected to be broadcastable with the DISABLE flag set. The advantages of using 0xfffffffd versus just 0 are debated, and the consensus on common usage is unclear.Overall, Jeremy Rubin's patch aims to fix a flaw in the Sequence lock implementation related to upgradability. The proposal includes separating mempool policies signaling from consensus data, introducing a new field for policy signaling through p2p packages, and deploying changes in a phased manner to ensure smooth policy deployment without disrupting existing applications. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Proposal-Auto-shutdown-as-5-year-fork-window.xml b/static/bitcoin-dev/Sept_2021/combined_Proposal-Auto-shutdown-as-5-year-fork-window.xml index 48b12e5fae..cba7ed9406 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Proposal-Auto-shutdown-as-5-year-fork-window.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Proposal-Auto-shutdown-as-5-year-fork-window.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Proposal: Auto-shutdown as 5-year fork window - 2023-08-02T04:46:36.052441+00:00 - - vjudeu at gazeta.pl 2021-09-12 19:38:47+00:00 - - - James Lu 2021-09-12 15:26:44+00:00 - + 2025-09-26T16:02:25.959328+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Auto-shutdown as 5-year fork window James Lu + 2021-09-12T15:26:00.000Z + + + vjudeu + 2021-09-12T19:38:00.000Z + + - python-feedgen + 2 Combined summary - Proposal: Auto-shutdown as 5-year fork window - 2023-08-02T04:46:36.052441+00:00 + 2025-09-26T16:02:25.959786+00:00 - Bitcoin-compatible client software can be customized by users, but there is no guarantee that others will adopt or shut down their versions. Miners often use custom software for mining blocks and pools, and there are multiple clients compatible with consensus other than the Bitcoin Core. To ensure backward compatibility, the Bitcoin community generally implements changes through soft-forks. Even "evil soft-forks" are considered preferable to hard-forks.On September 12th, 2021, James Lu proposed a change via bitcoin-dev that would automatically shut down a full node if MTP-11 (Median Time Past) exceeds five years from the release date of the current software version. The aim of this proposed code is to provide a grace period of around five years for the community to upgrade to a new version capable of executing a new hard fork while maintaining consensus, as long as the change implemented is non-controversial.The implementation of this code would enforce the shutdown of a full node if the MTP-11 timeframe surpasses five years since the software release. By doing so, it ensures that all nodes within the network are running on the latest version of the software, promoting uniformity and consensus among participants. This measure aims to facilitate smooth transitions and upgrades in the Bitcoin network, ultimately enhancing its overall efficiency and functionality. 2021-09-12T19:38:47+00:00 + Bitcoin-compatible client software can be customized by users, but there is no guarantee that others will adopt or shut down their versions. Miners often use custom software for mining blocks and pools, and there are multiple clients compatible with consensus other than the Bitcoin Core. To ensure backward compatibility, the Bitcoin community generally implements changes through soft-forks. Even "evil soft-forks" are considered preferable to hard-forks.On September 12th, 2021, James Lu proposed a change via bitcoin-dev that would automatically shut down a full node if MTP-11 (Median Time Past) exceeds five years from the release date of the current software version. The aim of this proposed code is to provide a grace period of around five years for the community to upgrade to a new version capable of executing a new hard fork while maintaining consensus, as long as the change implemented is non-controversial.The implementation of this code would enforce the shutdown of a full node if the MTP-11 timeframe surpasses five years since the software release. By doing so, it ensures that all nodes within the network are running on the latest version of the software, promoting uniformity and consensus among participants. This measure aims to facilitate smooth transitions and upgrades in the Bitcoin network, ultimately enhancing its overall efficiency and functionality. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Proposal-Package-Mempool-Accept-and-Package-RBF.xml b/static/bitcoin-dev/Sept_2021/combined_Proposal-Package-Mempool-Accept-and-Package-RBF.xml index 5d924a9bff..f4fbd6c202 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Proposal-Package-Mempool-Accept-and-Package-RBF.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Proposal-Package-Mempool-Accept-and-Package-RBF.xml @@ -1,56 +1,75 @@ - + 2 Combined summary - Proposal: Package Mempool Accept and Package RBF - 2023-08-02T04:48:13.719007+00:00 - - darosior 2021-10-14 10:48:55+00:00 - - - Gloria Zhao 2021-09-29 11:56:24+00:00 - - - Antoine Riard 2021-09-28 22:59:11+00:00 - - - Bastien TEINTURIER 2021-09-27 07:15:18+00:00 - - - Antoine Riard 2021-09-26 21:10:14+00:00 - - - Gloria Zhao 2021-09-23 15:36:02+00:00 - - - Antoine Riard 2021-09-23 04:29:39+00:00 - - - Gloria Zhao 2021-09-22 13:26:14+00:00 - - - Bastien TEINTURIER 2021-09-22 07:10:38+00:00 - - - Gloria Zhao 2021-09-21 16:42:33+00:00 - - - Bastien TEINTURIER 2021-09-21 15:18:28+00:00 - - - Gloria Zhao 2021-09-21 11:18:31+00:00 - - - Gloria Zhao 2021-09-20 15:10:14+00:00 - - - Bastien TEINTURIER 2021-09-20 09:19:38+00:00 - - - Antoine Riard 2021-09-19 23:16:45+00:00 - - - Gloria Zhao 2021-09-16 07:51:25+00:00 - + 2025-09-26T16:02:36.522816+00:00 + python-feedgen + + + [bitcoin-dev] Proposal: Package Mempool Accept and Package RBF Gloria Zhao + 2021-09-16T07:51:00.000Z + + + Antoine Riard + 2021-09-19T23:16:00.000Z + + + Bastien TEINTURIER + 2021-09-20T09:19:00.000Z + + + Gloria Zhao + 2021-09-20T15:10:00.000Z + + + Gloria Zhao + 2021-09-21T11:18:00.000Z + + + Bastien TEINTURIER + 2021-09-21T15:18:00.000Z + + + Gloria Zhao + 2021-09-21T16:42:00.000Z + + + Bastien TEINTURIER + 2021-09-22T07:10:00.000Z + + + Gloria Zhao + 2021-09-22T13:26:00.000Z + + + Antoine Riard + 2021-09-23T04:29:00.000Z + + + Gloria Zhao + 2021-09-23T15:36:00.000Z + + + Antoine Riard + 2021-09-26T21:10:00.000Z + + + Bastien TEINTURIER + 2021-09-27T07:15:00.000Z + + + Antoine Riard + 2021-09-28T22:59:00.000Z + + + Gloria Zhao + 2021-09-29T11:56:00.000Z + + + darosior + 2021-10-14T10:48:00.000Z + + @@ -67,13 +86,13 @@ - python-feedgen + 2 Combined summary - Proposal: Package Mempool Accept and Package RBF - 2023-08-02T04:48:13.719007+00:00 + 2025-09-26T16:02:36.524558+00:00 - The email thread on the bitcoin-dev mailing list discusses various aspects of the proposed package relay for Bitcoin Core. The discussions revolve around package acceptance rules, deduplication, and topologies. There is a debate on the logical order of the proposed checks and whether only the package RBF should apply. The limitations on topology are also discussed, with some suggesting a conservative approach of deploying during a first phase of 1-parent/1-child.Gloria Zhao and Antoine Riard discuss the proposed implementation of package relay for Bitcoin. They cover topics such as the removal of transactions already in the mempool during package submission, evaluation of fee rates for packages, and how replacements will work. They also discuss potential issues with multi-parent-1-child packages and their use in fee-bumping replaceable transactions. They mention the possibility of implementing a "witness replacement" project alongside package mempool acceptance.There is a discussion about the rules for Package Replace-by-Fee (RBF) in Bitcoin. The proposal includes conditions such as having a higher ancestor score than the original transactions, not including new unconfirmed inputs unless they were included in the original transactions, and having a total fee higher than the replaced transactions. The package feerate must be higher than the replaced transactions by at least the minimum relay feerate, and the package cannot replace more than 100 mempool transactions.The conversations aim to improve the efficiency and security of Bitcoin's mempool. There are concerns about Lightning developers who may not be aware of mempool subtleties and suggestions to constrain L2 design space using a 1-parent + 1-child model. The discussions cover various scenarios, including batched fee-bumping, mempool conflicts, and multi-commitment-broadcast-as-one-package. The goal is to make fee-bumping tools more powerful for users while maintaining transaction safety.There are proposals for changes to Bitcoin Core's mempool policy to enable package validation for package relay. The proposed policy allows for packages with multiple parents and one child to be validated together, improving fee-bumping tools for time-sensitive transactions. The proposal also introduces the concept of Package Mempool Accept, which includes changes to mempool validation logic, policy, and transaction relay to propagate transactions with the highest package feerates to miners.The discussions also touch on potential risks and safety concerns related to package acceptance and replacements. Concerns are raised about CPFP batching for Lightning Network time-sensitive closure and the possibility of malicious transactions delaying transaction propagation and confirmation within the same package. There is a focus on ensuring better utilization of block space while maintaining transaction safety.Overall, these discussions aim to enhance the transaction process in the Bitcoin network by optimizing validation, propagation, and fee-bumping tools. The proposals and debates explore various aspects of package acceptance, replacement-by-fee rules, and topology limitations. The goal is to improve efficiency, security, and flexibility for users and applications like Lightning.The Bitcoin Core development team has proposed a new system called package relay to improve transaction validation and propagation. This system allows for the creation of packages consisting of multiple parents and one child, which aids in fee estimations and transaction relay. The proposal introduces package feerate, which considers modified fees and virtual size of all transactions in the package. It also sets limitations on fee-bumping to prevent DoS vectors and ensures that replacement transactions have an ancestor score at least as high as the original ones. The package relay system has implications for Lightning Network (LN) requirements and other Layer 2 protocols/applications. It is suggested to deploy it in a phased manner to improve second-layer safety. The proposed system enables CPFP within packages and provides fee-bumping tools for users. To test the submission logic, Package Mempool Accept initially uses RPC. Fee-related checks use the package feerate, and parents can replace mempool transactions, but the child cannot. The bitcoin-dev mailing list has discussed the proposal, exploring differences from BIP125 and addressing potential scenarios and FAQs.Overall, the package relay system aims to improve package validation and relay in Bitcoin Core without requiring consensus or P2P protocol changes. It allows for better propagation of high-feerate transactions, more powerful fee-bumping tools for users, and adjustments to fees at broadcast time for Layer 2 applications. The proposed changes include modifications to mempool policy, allowing for packages with multiple parents and one child, and using the total package feerate instead of individual feerates. The author provides a draft implementation of the proposal and clarifies terminology and existing rules. However, there are limitations, such as the package not being able to replace more than 100 mempool transactions and not being able to contain already-confirmed transactions. 2021-10-14T10:48:55+00:00 + The email thread on the bitcoin-dev mailing list discusses various aspects of the proposed package relay for Bitcoin Core. The discussions revolve around package acceptance rules, deduplication, and topologies. There is a debate on the logical order of the proposed checks and whether only the package RBF should apply. The limitations on topology are also discussed, with some suggesting a conservative approach of deploying during a first phase of 1-parent/1-child.Gloria Zhao and Antoine Riard discuss the proposed implementation of package relay for Bitcoin. They cover topics such as the removal of transactions already in the mempool during package submission, evaluation of fee rates for packages, and how replacements will work. They also discuss potential issues with multi-parent-1-child packages and their use in fee-bumping replaceable transactions. They mention the possibility of implementing a "witness replacement" project alongside package mempool acceptance.There is a discussion about the rules for Package Replace-by-Fee (RBF) in Bitcoin. The proposal includes conditions such as having a higher ancestor score than the original transactions, not including new unconfirmed inputs unless they were included in the original transactions, and having a total fee higher than the replaced transactions. The package feerate must be higher than the replaced transactions by at least the minimum relay feerate, and the package cannot replace more than 100 mempool transactions.The conversations aim to improve the efficiency and security of Bitcoin's mempool. There are concerns about Lightning developers who may not be aware of mempool subtleties and suggestions to constrain L2 design space using a 1-parent + 1-child model. The discussions cover various scenarios, including batched fee-bumping, mempool conflicts, and multi-commitment-broadcast-as-one-package. The goal is to make fee-bumping tools more powerful for users while maintaining transaction safety.There are proposals for changes to Bitcoin Core's mempool policy to enable package validation for package relay. The proposed policy allows for packages with multiple parents and one child to be validated together, improving fee-bumping tools for time-sensitive transactions. The proposal also introduces the concept of Package Mempool Accept, which includes changes to mempool validation logic, policy, and transaction relay to propagate transactions with the highest package feerates to miners.The discussions also touch on potential risks and safety concerns related to package acceptance and replacements. Concerns are raised about CPFP batching for Lightning Network time-sensitive closure and the possibility of malicious transactions delaying transaction propagation and confirmation within the same package. There is a focus on ensuring better utilization of block space while maintaining transaction safety.Overall, these discussions aim to enhance the transaction process in the Bitcoin network by optimizing validation, propagation, and fee-bumping tools. The proposals and debates explore various aspects of package acceptance, replacement-by-fee rules, and topology limitations. The goal is to improve efficiency, security, and flexibility for users and applications like Lightning.The Bitcoin Core development team has proposed a new system called package relay to improve transaction validation and propagation. This system allows for the creation of packages consisting of multiple parents and one child, which aids in fee estimations and transaction relay. The proposal introduces package feerate, which considers modified fees and virtual size of all transactions in the package. It also sets limitations on fee-bumping to prevent DoS vectors and ensures that replacement transactions have an ancestor score at least as high as the original ones. The package relay system has implications for Lightning Network (LN) requirements and other Layer 2 protocols/applications. It is suggested to deploy it in a phased manner to improve second-layer safety. The proposed system enables CPFP within packages and provides fee-bumping tools for users. To test the submission logic, Package Mempool Accept initially uses RPC. Fee-related checks use the package feerate, and parents can replace mempool transactions, but the child cannot. The bitcoin-dev mailing list has discussed the proposal, exploring differences from BIP125 and addressing potential scenarios and FAQs.Overall, the package relay system aims to improve package validation and relay in Bitcoin Core without requiring consensus or P2P protocol changes. It allows for better propagation of high-feerate transactions, more powerful fee-bumping tools for users, and adjustments to fees at broadcast time for Layer 2 applications. The proposed changes include modifications to mempool policy, allowing for packages with multiple parents and one child, and using the total package feerate instead of individual feerates. The author provides a draft implementation of the proposal and clarifies terminology and existing rules. However, there are limitations, such as the package not being able to replace more than 100 mempool transactions and not being able to contain already-confirmed transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Proposal-for-a-few-IANA-mime-types-related-to-Bitcoin.xml b/static/bitcoin-dev/Sept_2021/combined_Proposal-for-a-few-IANA-mime-types-related-to-Bitcoin.xml index 1b3a8eb26b..b119e3a082 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Proposal-for-a-few-IANA-mime-types-related-to-Bitcoin.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Proposal-for-a-few-IANA-mime-types-related-to-Bitcoin.xml @@ -1,29 +1,39 @@ - + 2 Combined summary - Proposal for a few IANA mime-types related to Bitcoin - 2023-08-02T04:39:09.961743+00:00 - - Dr Maxim Orlovsky 2021-09-02 10:52:13+00:00 - - - Peter D. Gray 2021-09-01 13:39:30+00:00 - - - Christopher Allen 2021-08-31 20:02:44+00:00 - - - Andrew Chow 2021-08-31 19:46:55+00:00 - - - Peter D. Gray 2021-08-31 19:18:00+00:00 - - - Christopher Allen 2021-08-31 19:01:23+00:00 - - - Peter D. Gray 2021-08-31 18:27:41+00:00 - + 2025-09-26T16:02:30.131902+00:00 + python-feedgen + + + [bitcoin-dev] Proposal for a few IANA mime-types related to Bitcoin Peter D. Gray + 2021-08-31T18:27:00.000Z + + + Christopher Allen + 2021-08-31T19:01:00.000Z + + + Peter D. Gray + 2021-08-31T19:18:00.000Z + + + Andrew Chow + 2021-08-31T19:46:00.000Z + + + Christopher Allen + 2021-08-31T20:02:00.000Z + + + Peter D. Gray + 2021-09-01T13:39:00.000Z + + + Dr Maxim Orlovsky + 2021-09-02T10:52:00.000Z + + @@ -31,13 +41,13 @@ - python-feedgen + 2 Combined summary - Proposal for a few IANA mime-types related to Bitcoin - 2023-08-02T04:39:09.961743+00:00 + 2025-09-26T16:02:30.132750+00:00 - In a recent discussion on the Bitcoin-dev mailing list, Peter D. Gray proposed registering three new MIME media types with the Internet Assigned Numbers Authority (IANA) for Bitcoin-related content. The proposed media types are bitcoin/psbt, bitcoin/txn, and bitcoin/uri. However, Andrew Chow expressed doubts about the feasibility of registering these MIME types due to the limited number of accepted top-level types and the requirements for registration in the Standards tree. Chow explained that the best tree for the MIME type would be the Standards tree, but it requires registration either associated with an IETF specification or registered by a recognized standards-related organization. Since Bitcoin does not have a recognized standards organization, Chow suggested ignoring the IANA and declaring useful "mime types" in a new BIP that can be agreed upon within the Bitcoin community. Maxim Orlovsky from LNP/BP Standards Association expressed willingness to write the draft of the proposed BIP. Peter acknowledged Andrew's concerns and suggested writing an independent submission RFC for the proposed MIME types. He provided details on the proposed MIME types, including their descriptions and potential uses. He also indicated that they could be useful beyond web servers, such as in NFC (NDEF records) where shorter length is critical. Peter noted that while some MIME types were proposed in BIP-71, they were unrelated to the proposed ones and were never registered.In conclusion, Peter proposed new MIME types for Bitcoin-related content. While there were concerns about the registration process, a new BIP will be drafted to declare these useful "mime types" and agree upon their usage within the Bitcoin community. 2021-09-02T10:52:13+00:00 + In a recent discussion on the Bitcoin-dev mailing list, Peter D. Gray proposed registering three new MIME media types with the Internet Assigned Numbers Authority (IANA) for Bitcoin-related content. The proposed media types are bitcoin/psbt, bitcoin/txn, and bitcoin/uri. However, Andrew Chow expressed doubts about the feasibility of registering these MIME types due to the limited number of accepted top-level types and the requirements for registration in the Standards tree. Chow explained that the best tree for the MIME type would be the Standards tree, but it requires registration either associated with an IETF specification or registered by a recognized standards-related organization. Since Bitcoin does not have a recognized standards organization, Chow suggested ignoring the IANA and declaring useful "mime types" in a new BIP that can be agreed upon within the Bitcoin community. Maxim Orlovsky from LNP/BP Standards Association expressed willingness to write the draft of the proposed BIP. Peter acknowledged Andrew's concerns and suggested writing an independent submission RFC for the proposed MIME types. He provided details on the proposed MIME types, including their descriptions and potential uses. He also indicated that they could be useful beyond web servers, such as in NFC (NDEF records) where shorter length is critical. Peter noted that while some MIME types were proposed in BIP-71, they were unrelated to the proposed ones and were never registered.In conclusion, Peter proposed new MIME types for Bitcoin-related content. While there were concerns about the registration process, a new BIP will be drafted to declare these useful "mime types" and agree upon their usage within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml b/static/bitcoin-dev/Sept_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml index dc4c324a11..53005a0c0e 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reminder on the Purpose of BIPs - 2023-08-02T03:42:08.191963+00:00 + 2025-09-26T16:02:15.470247+00:00 + python-feedgen Prayank 2021-09-15 09:50:34+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Reminder on the Purpose of BIPs - 2023-08-02T03:42:08.191963+00:00 + 2025-09-26T16:02:15.470404+00:00 - During a recent meeting, the suggestion to decentralize the Bitcoin Improvement Proposals (BIPs) process was made in response to the lack of participation and discussion. The proposal aims to create multiple BIP directories to reduce dependency on one repository or a few individuals. While documentation is important, the focus should be on implementation.An example was given to demonstrate this point. Greg Maxwell proposed a solution to the mirroring issue of decentralized BIPs. He suggested assigning each BIP a genesis transaction ID that moves in time on the blockchain and mirrors the evolution in Git using commit hashes. This would provide a definitive HEAD of a BIP and its history, which can be reconstructed from any one transaction. Commit trees can be mirrored and hosted on popular sites like Github or Gitlab. The proposal also includes assigning BIP numbers in the Bitcoin repository and requiring spending money on transactions to prevent sybil attacks.David A. Harding recommended changes to the BIP process. His recommendations include adding more BIP editors, seeking the resignation of Luke Dashjr as BIP editor, and treating protocol documents outside the BIPs repository as first-class BIP documentation. He proposed an alternative to the BIPs system where anyone writing protocol documentation can post their idea to the mailing list and assign themselves a unique decentralized identifier starting with "bip-". Implementations of BIPs would link to the relevant protocol documentation. Harding's proposal aims to address issues such as users considering documents in the BIPs repo as authoritative and development teams wanting control over their own documentation.Matt Corallo criticized the BIP process, calling it a failure. W.J. van der Laan suggested decentralizing the process and adding more editors to address the bottleneck in open pull requests. Corallo also expressed frustration towards the community for irrational debates and ignoring input. The debate highlighted the need for a more decentralized approach to the BIP process.Luke Dashjr responded to accusations of deliberately refusing changes to BIPs. He denied the claims and stated that he follows the currently-defined process neutrally, despite being harassed by certain advocates. Dashjr proposed adding Kalle Alm as a BIP editor, but Antoine Riard suggested that the BIP editorship should have its own repository and follow procedural forms.Overall, there is ongoing discussion and debate about the BIP process and how it can be improved to better serve the Bitcoin community.In recent years, there has been a significant increase in the use of artificial intelligence (AI) in various industries. AI is a branch of computer science that focuses on creating intelligent machines capable of performing tasks that typically require human intelligence. It involves the development of algorithms and models that allow computers to learn from and adapt to data.One industry that has greatly benefited from the use of AI is healthcare. AI has the potential to revolutionize healthcare by improving diagnosis, treatment, and patient care. For example, AI algorithms can analyze large amounts of medical data to identify patterns and make predictions, helping doctors make more accurate diagnoses and develop personalized treatment plans. AI can also be used to monitor patients remotely, providing timely intervention and reducing the need for hospital visits.Another area where AI is making a significant impact is transportation. Self-driving cars, powered by AI technology, have the potential to reduce accidents and improve road safety. These cars are equipped with sensors and cameras that allow them to navigate and make decisions based on real-time data. AI algorithms enable the car to interpret the environment and react accordingly, ensuring a smooth and safe ride.AI is also being used in the finance industry to automate processes and enhance decision-making. For instance, AI-powered chatbots can assist customers with basic banking tasks, such as checking account balances or transferring funds. AI algorithms can also analyze financial data to detect fraud and identify investment opportunities. Additionally, AI can help financial institutions streamline operations and improve customer service through personalized recommendations.The retail industry has also embraced AI to enhance customer experience and optimize business operations. AI-powered recommendation systems analyze customer preferences and behavior to provide personalized product suggestions. This not only improves customer satisfaction but also increases sales. AI can also be used to automate inventory management, pricing strategies, and supply chain optimization, leading to cost savings and improved efficiency.In conclusion, AI is revolutionizing various industries, including healthcare, transportation, finance, and retail. Its ability to analyze large amounts of data, make predictions, and automate processes is transforming how these industries operate. As AI technology continues to advance, it is expected to have an even greater impact in the future, driving innovation and improving efficiency across multiple sectors. 2021-09-15T09:50:34+00:00 + During a recent meeting, the suggestion to decentralize the Bitcoin Improvement Proposals (BIPs) process was made in response to the lack of participation and discussion. The proposal aims to create multiple BIP directories to reduce dependency on one repository or a few individuals. While documentation is important, the focus should be on implementation.An example was given to demonstrate this point. Greg Maxwell proposed a solution to the mirroring issue of decentralized BIPs. He suggested assigning each BIP a genesis transaction ID that moves in time on the blockchain and mirrors the evolution in Git using commit hashes. This would provide a definitive HEAD of a BIP and its history, which can be reconstructed from any one transaction. Commit trees can be mirrored and hosted on popular sites like Github or Gitlab. The proposal also includes assigning BIP numbers in the Bitcoin repository and requiring spending money on transactions to prevent sybil attacks.David A. Harding recommended changes to the BIP process. His recommendations include adding more BIP editors, seeking the resignation of Luke Dashjr as BIP editor, and treating protocol documents outside the BIPs repository as first-class BIP documentation. He proposed an alternative to the BIPs system where anyone writing protocol documentation can post their idea to the mailing list and assign themselves a unique decentralized identifier starting with "bip-". Implementations of BIPs would link to the relevant protocol documentation. Harding's proposal aims to address issues such as users considering documents in the BIPs repo as authoritative and development teams wanting control over their own documentation.Matt Corallo criticized the BIP process, calling it a failure. W.J. van der Laan suggested decentralizing the process and adding more editors to address the bottleneck in open pull requests. Corallo also expressed frustration towards the community for irrational debates and ignoring input. The debate highlighted the need for a more decentralized approach to the BIP process.Luke Dashjr responded to accusations of deliberately refusing changes to BIPs. He denied the claims and stated that he follows the currently-defined process neutrally, despite being harassed by certain advocates. Dashjr proposed adding Kalle Alm as a BIP editor, but Antoine Riard suggested that the BIP editorship should have its own repository and follow procedural forms.Overall, there is ongoing discussion and debate about the BIP process and how it can be improved to better serve the Bitcoin community.In recent years, there has been a significant increase in the use of artificial intelligence (AI) in various industries. AI is a branch of computer science that focuses on creating intelligent machines capable of performing tasks that typically require human intelligence. It involves the development of algorithms and models that allow computers to learn from and adapt to data.One industry that has greatly benefited from the use of AI is healthcare. AI has the potential to revolutionize healthcare by improving diagnosis, treatment, and patient care. For example, AI algorithms can analyze large amounts of medical data to identify patterns and make predictions, helping doctors make more accurate diagnoses and develop personalized treatment plans. AI can also be used to monitor patients remotely, providing timely intervention and reducing the need for hospital visits.Another area where AI is making a significant impact is transportation. Self-driving cars, powered by AI technology, have the potential to reduce accidents and improve road safety. These cars are equipped with sensors and cameras that allow them to navigate and make decisions based on real-time data. AI algorithms enable the car to interpret the environment and react accordingly, ensuring a smooth and safe ride.AI is also being used in the finance industry to automate processes and enhance decision-making. For instance, AI-powered chatbots can assist customers with basic banking tasks, such as checking account balances or transferring funds. AI algorithms can also analyze financial data to detect fraud and identify investment opportunities. Additionally, AI can help financial institutions streamline operations and improve customer service through personalized recommendations.The retail industry has also embraced AI to enhance customer experience and optimize business operations. AI-powered recommendation systems analyze customer preferences and behavior to provide personalized product suggestions. This not only improves customer satisfaction but also increases sales. AI can also be used to automate inventory management, pricing strategies, and supply chain optimization, leading to cost savings and improved efficiency.In conclusion, AI is revolutionizing various industries, including healthcare, transportation, finance, and retail. Its ability to analyze large amounts of data, make predictions, and automate processes is transforming how these industries operate. As AI technology continues to advance, it is expected to have an even greater impact in the future, driving innovation and improving efficiency across multiple sectors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Removing-the-Dust-Limit.xml b/static/bitcoin-dev/Sept_2021/combined_Removing-the-Dust-Limit.xml index 4cbc05258f..15b4c0c4c3 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Removing-the-Dust-Limit.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Removing-the-Dust-Limit.xml @@ -1,119 +1,151 @@ - + 2 Combined summary - Removing the Dust Limit - 2023-08-02T04:31:39.825006+00:00 - - vjudeu at gazeta.pl 2022-03-12 13:02:24+00:00 - - - ZmnSCPxj 2021-10-08 22:47:11+00:00 - - - ZmnSCPxj 2021-10-08 10:38:50+00:00 - - - shymaa arafat 2021-10-08 07:44:59+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 10:35:16+00:00 - - - ZmnSCPxj 2021-10-07 10:01:53+00:00 - - - shymaa arafat 2021-10-07 09:13:33+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 08:34:17+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-10-07 08:17:40+00:00 - - - ZmnSCPxj 2021-10-07 04:52:01+00:00 - - - Erik Aronesty 2021-10-01 13:40:06+00:00 - - - Pieter Wuille 2021-09-30 22:07:08+00:00 - - - LORD HIS EXCELLENCY JAMES HRMH 2021-08-30 03:31:56+00:00 - - - shymaa arafat 2021-08-27 09:07:35+00:00 - - - Billy Tetrud 2021-08-26 21:21:25+00:00 - - - ZmnSCPxj 2021-08-21 03:10:46+00:00 - - - shymaa arafat 2021-08-20 05:45:31+00:00 - - - Jeremy 2021-08-20 04:51:31+00:00 - - - shymaa arafat 2021-08-18 19:06:30+00:00 - - - Anthony Towns 2021-08-12 22:03:39+00:00 - - - ZmnSCPxj 2021-08-11 00:46:36+00:00 - - - Antoine Riard 2021-08-10 22:37:48+00:00 - - - Charlie Lee 2021-08-10 18:39:39+00:00 - - - ZmnSCPxj 2021-08-10 11:37:37+00:00 - - - David A. Harding 2021-08-10 06:14:41+00:00 - - - Billy Tetrud 2021-08-10 05:44:04+00:00 - - - Jeremy 2021-08-10 05:04:07+00:00 - - - Billy Tetrud 2021-08-10 00:30:02+00:00 - - - Antoine Riard 2021-08-09 13:22:28+00:00 - - - Karl 2021-08-09 11:58:03+00:00 - - - Prayank 2021-08-09 10:25:50+00:00 - - - Jeremy 2021-08-08 23:07:27+00:00 - - - Jeremy 2021-08-08 22:46:26+00:00 - - - David A. Harding 2021-08-08 21:51:01+00:00 - - - Oleg Andreev 2021-08-08 21:41:32+00:00 - - - Matt Corallo 2021-08-08 21:14:23+00:00 - - - Jeremy 2021-08-08 18:52:55+00:00 - + 2025-09-26T16:02:34.332913+00:00 + python-feedgen + + + [bitcoin-dev] Removing the Dust Limit Jeremy + 2021-08-08T18:52:00.000Z + + + Matt Corallo + 2021-08-08T21:14:00.000Z + + + Oleg Andreev + 2021-08-08T21:41:00.000Z + + + [bitcoin-dev] [Lightning-dev] " David A. Harding + 2021-08-08T21:51:00.000Z + + + Jeremy + 2021-08-08T22:46:00.000Z + + + Jeremy + 2021-08-08T23:07:00.000Z + + + [bitcoin-dev] " Prayank + 2021-08-09T10:25:00.000Z + + + Karl + 2021-08-09T11:58:00.000Z + + + Antoine Riard + 2021-08-09T13:22:00.000Z + + + Billy Tetrud + 2021-08-10T00:30:00.000Z + + + Jeremy + 2021-08-10T05:04:00.000Z + + + Billy Tetrud + 2021-08-10T05:44:00.000Z + + + David A. Harding + 2021-08-10T06:14:00.000Z + + + ZmnSCPxj + 2021-08-10T11:37:00.000Z + + + Charlie Lee + 2021-08-10T18:39:00.000Z + + + Antoine Riard + 2021-08-10T22:37:00.000Z + + + ZmnSCPxj + 2021-08-11T00:46:00.000Z + + + Anthony Towns + 2021-08-12T22:03:00.000Z + + + Jeremy + 2021-08-20T04:51:00.000Z + + + shymaa arafat + 2021-08-20T05:45:00.000Z + + + ZmnSCPxj + 2021-08-21T03:10:00.000Z + + + Billy Tetrud + 2021-08-26T21:21:00.000Z + + + shymaa arafat + 2021-08-27T09:07:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-08-30T03:31:00.000Z + + + Pieter Wuille + 2021-09-30T22:07:00.000Z + + + Erik Aronesty + 2021-10-01T13:40:00.000Z + + + ZmnSCPxj + 2021-10-07T04:52:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T08:17:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T08:34:00.000Z + + + shymaa arafat + 2021-10-07T09:13:00.000Z + + + ZmnSCPxj + 2021-10-07T10:01:00.000Z + + + LORD HIS EXCELLENCY JAMES HRMH + 2021-10-07T10:35:00.000Z + + + shymaa arafat + 2021-10-08T07:44:00.000Z + + + ZmnSCPxj + 2021-10-08T10:38:00.000Z + + + ZmnSCPxj + 2021-10-08T22:47:00.000Z + + @@ -151,13 +183,13 @@ - python-feedgen + 2 Combined summary - Removing the Dust Limit - 2023-08-02T04:31:39.825967+00:00 + 2025-09-26T16:02:34.336766+00:00 - Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees. However, this short-term incentive is countered by concerns about spam and dust fingerprinting attacks.In conclusion, 2022-03-12T13:02:24+00:00 + Jeremy Rubin and Matt are engaged in an ongoing debate about whether to remove the dust limit in Bitcoin. Jeremy argues in favor of removing the limit, presenting five reasons to support his stance.Firstly, he believes that removing the limit would enable new types of transactions and applications to be created. This would provide users with more flexibility in creating outputs for various purposes, including smart contracts.Secondly, Jeremy suggests that dust outputs can be utilized in various authentication and delegation smart contracts. By allowing dust-sized outputs, developers can leverage them in innovative ways to enhance functionality and expand the capabilities of the Bitcoin network.Furthermore, Jeremy proposes that thinly divisible colored coin protocols could utilize satoshis as value markers for transactions. This would allow for more efficient handling of colored coins within the Bitcoin ecosystem.He also argues that treating fund transfers agnostically would simplify regulatory classification of channels. By not imposing restrictions on the value of unspent transaction outputs (UTXOs), it becomes easier to categorize transactions from a regulatory standpoint.Lastly, Jeremy acknowledges concerns about dust being spam and dust fingerprinting attacks. However, he believes that these issues are preventable with proper measures in place.On the other hand, Matt raises concerns about the externality of the UTXO set size. He suggests implementing a relay policy to address this issue but acknowledges that hardcoding prices or feerates is undesirable. One possible solution he suggests is giving transactions a size or weight bonus/penalty, although he acknowledges the challenges in implementing this correctly.There is also a proposal to make all dust transactions invalid by some nodes. The author questions whether this would require a consensus change and suggests an alternative approach of keeping dust transactions in secondary storage for full nodes and using separate Merkle Trees for bridge servers. However, the author fails to see how this would reduce processing compared to outright rejecting all dust transactions.To find a compromise, it is suggested to keep dust transactions in secondary storage for full nodes and have a separate Merkle Tree for bridge servers. This would improve performance on bridge servers and reduce the risk of exhausting a node with denial-of-service (DoS) attacks. The goal of this proposal is to decrease the amount of dust in the UTXO set, while also considering worst-case behavior for resistance against attacks.Another perspective is presented by Lord His Excellency James HRMH, who argues against restricting the value of UTXOs in one's own wallet. They suggest transferring the value of any dust UTXO to the fee. Additionally, they propose rounding transaction values and sending the additional rounded amount to the recipient. They dismiss concerns about slow validation due to the dust set of UTXOs, suggesting that the solution lies in building a faster database.ZmnSCPxj suggests storing dust UTXOs in a separate Merkle tree or structure to reduce CPU cost. However, they caution that this technique may worsen worst-case CPU cost and time if secondary storage sacrifices speed for increased capacity per satoshi.The discussion also explores the idea of lightweight nodes that ignore dust-sized outputs but still validate proof-of-work and other transactions. Concerns are raised about how such nodes would treat transactions that spend multiple dust UTXOs, as they do not store dust UTXOs and cannot determine if the UTXO being spent is dust or invalid.David Harding argues that increasing the UTXO set size through dust outputs leads to increased validation work for full nodes, resulting in higher costs for miners and centralization of mining. A relay policy is proposed to discourage economically irrational behavior. The argument against colored coin protocols on the Bitcoin chain is presented, highlighting the little benefit for tokens with a trusted issuer. The feasibility of confidential transactions without compromising privacy is discussed, suggesting the use of range proofs.Pieter Wuille comments on David Harding's presentation, agreeing with the need for a relay policy to avoid economically irrational behavior. He disagrees with colored coin protocols on the Bitcoin chain, as they compete with using Bitcoin for BTC. Pieter expresses hesitancy to worsen scalability for misguided use.The conversations also address the impact of the dust limit on the Lightning Network, including price discovery issues and the cost of writing on the UTXO set in a distributed system. Different perspectives are presented regarding the handling of dust-sized outputs in Lightning Network channels and their impact on feerates and network topology.In terms of Bitcoin's design, ZmnSCPxj proposes a softforkable solution involving a non-Confidential Transactions (CT) block and a separately-committed CT block. This design allows for unconditional privacy and computational soundness when transferring funds between the legacy non-CT block and the CT block.The email thread also explores the potential value of dust in Bitcoin transactions and the challenges associated with its handling. The existence of a dust limit incentivizes miners to mine dust outputs due to their lower maintenance costs compared to immediate fees. However, this short-term incentive is countered by concerns about spam and dust fingerprinting attacks.In conclusion, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Reorgs-on-SigNet-Looking-for-feedback-on-approach-and-parameters.xml b/static/bitcoin-dev/Sept_2021/combined_Reorgs-on-SigNet-Looking-for-feedback-on-approach-and-parameters.xml index b1e8c81059..38c3e149e5 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Reorgs-on-SigNet-Looking-for-feedback-on-approach-and-parameters.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Reorgs-on-SigNet-Looking-for-feedback-on-approach-and-parameters.xml @@ -1,62 +1,83 @@ - + 2 Combined summary - Reorgs on SigNet - Looking for feedback on approach and parameters - 2023-08-02T04:41:16.248558+00:00 - - Anthony Towns 2021-10-15 04:41:50+00:00 - - - Matt Corallo 2021-09-15 15:24:43+00:00 - - - Anthony Towns 2021-09-14 04:56:10+00:00 - - - Matt Corallo 2021-09-13 16:24:29+00:00 - - - Michael Folkson 2021-09-13 12:30:31+00:00 - - - Matt Corallo 2021-09-13 05:33:24+00:00 - - - Greg Sanders 2021-09-12 14:54:33+00:00 - - - vjudeu at gazeta.pl 2021-09-12 14:29:08+00:00 - - - Anthony Towns 2021-09-12 07:53:05+00:00 - - - David A. Harding 2021-09-10 20:00:05+00:00 - - - Matt Corallo 2021-09-10 19:22:00+00:00 - - - Michael Folkson 2021-09-10 19:00:39+00:00 - - - Matt Corallo 2021-09-10 18:24:15+00:00 - - - Michael Folkson 2021-09-10 13:05:40+00:00 - - - Matt Corallo 2021-09-10 00:50:08+00:00 - - - Anthony Towns 2021-09-08 07:59:04+00:00 - - - Jeremy 2021-09-07 16:44:17+00:00 - - - 0xB10C 2021-09-07 16:07:47+00:00 - + 2025-09-26T16:02:44.965539+00:00 + python-feedgen + + + [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters 0xB10C + 2021-09-07T16:07:00.000Z + + + Jeremy + 2021-09-07T16:44:00.000Z + + + Anthony Towns + 2021-09-08T07:59:00.000Z + + + Matt Corallo + 2021-09-10T00:50:00.000Z + + + Michael Folkson + 2021-09-10T13:05:00.000Z + + + Matt Corallo + 2021-09-10T18:24:00.000Z + + + Michael Folkson + 2021-09-10T19:00:00.000Z + + + Matt Corallo + 2021-09-10T19:22:00.000Z + + + David A. Harding + 2021-09-10T20:00:00.000Z + + + Anthony Towns + 2021-09-12T07:53:00.000Z + + + vjudeu + 2021-09-12T14:29:00.000Z + + + Greg Sanders + 2021-09-12T14:54:00.000Z + + + Matt Corallo + 2021-09-13T05:33:00.000Z + + + Michael Folkson + 2021-09-13T12:30:00.000Z + + + Matt Corallo + 2021-09-13T16:24:00.000Z + + + Anthony Towns + 2021-09-14T04:56:00.000Z + + + Matt Corallo + 2021-09-15T15:24:00.000Z + + + Anthony Towns + 2021-10-15T04:41:00.000Z + + @@ -75,13 +96,13 @@ - python-feedgen + 2 Combined summary - Reorgs on SigNet - Looking for feedback on approach and parameters - 2023-08-02T04:41:16.249560+00:00 + 2025-09-26T16:02:44.967524+00:00 - The discussion on the Bitcoin Signet revolved around simplifying testing and addressing re-org behavior. The aim of Signet is to replicate mainnet as closely as possible, allowing software to use it without modification. However, there were suggestions for improving the simulation of mainnet behavior.One proposal suggested having existing block producers generate new keys and only sign reorgs with those keys. This would give users the option to accept signatures from both sets of keys or only non-reorg keys, providing a more reliable simulation of mainnet behavior. Importantly, this suggestion wouldn't require users to sign blocks themselves.There was a debate about the frequency of reorgs on the default Signet. Some argued for more regular reorgs (e.g., every 8 hours) to test applications' ability to withstand different flavors of re-orgs. Others believed that making reorgs too frequent would deviate significantly from mainnet behavior and recommended testing normal mainnet behavior before focusing on reorgs.Another proposal was to introduce a version bit for blocks, requiring users to sign blocks. However, the added complexity of this approach was questioned, as the default Signet currently leaves block signing to network block signers. It was suggested that a flag set via a configuration argument could be used instead, with no-reorgs or 8-hour re-orgs as the default.To further resemble mainnet, the random generation of batches of transactions to fill up blocks and create a fee market was proposed. This would facilitate testing features like RBF and Lightning unhappy paths on the default Signet in the future.The discussions also explored various aspects related to reorgs on Signet. One proposal suggested using a version bit flag for blocks that won't end up in the most work chain, giving users the choice to opt-out of reorgs. The frequency and depth of reorgs were debated, with suggestions for frequent reorgs (e.g., every block) or less frequent ones (e.g., once per week). The depth of reorgs was considered, with different depths serving different testing purposes. It was proposed that the depth of reorgs be deterministically random within a minimum and maximum range based on block hash or nonce.Two scenarios were suggested for testing reorg handling: a race between two chains and a chain rollback scenario. Questions arose regarding the frequency of reorgs on the default Signet and how engineers currently test their applications' reorg handling.Developers sought feedback on implementing support for planned chain reorganizations in Signet. Two scenarios were proposed: races between chains and chain rollbacks. Users would have the option to opt-out of reorgs by setting a version bit flag on affected blocks. The frequency and depth of reorgs would depend on user needs, considering users across different time zones. The first step would be to implement the race scenario and set up a public test-Signet. If there is interest, chain rollbacks could be implemented, and conflicting transactions could be included in the branches.Overall, the discussions aimed to find the best approach to simulate mainnet behavior while providing an easy testing environment for applications. Feedback from developers and users was crucial in determining the optimal parameters for reorgs and ensuring a reliable testing environment for Bitcoin developers. 2021-10-15T04:41:50+00:00 + The discussion on the Bitcoin Signet revolved around simplifying testing and addressing re-org behavior. The aim of Signet is to replicate mainnet as closely as possible, allowing software to use it without modification. However, there were suggestions for improving the simulation of mainnet behavior.One proposal suggested having existing block producers generate new keys and only sign reorgs with those keys. This would give users the option to accept signatures from both sets of keys or only non-reorg keys, providing a more reliable simulation of mainnet behavior. Importantly, this suggestion wouldn't require users to sign blocks themselves.There was a debate about the frequency of reorgs on the default Signet. Some argued for more regular reorgs (e.g., every 8 hours) to test applications' ability to withstand different flavors of re-orgs. Others believed that making reorgs too frequent would deviate significantly from mainnet behavior and recommended testing normal mainnet behavior before focusing on reorgs.Another proposal was to introduce a version bit for blocks, requiring users to sign blocks. However, the added complexity of this approach was questioned, as the default Signet currently leaves block signing to network block signers. It was suggested that a flag set via a configuration argument could be used instead, with no-reorgs or 8-hour re-orgs as the default.To further resemble mainnet, the random generation of batches of transactions to fill up blocks and create a fee market was proposed. This would facilitate testing features like RBF and Lightning unhappy paths on the default Signet in the future.The discussions also explored various aspects related to reorgs on Signet. One proposal suggested using a version bit flag for blocks that won't end up in the most work chain, giving users the choice to opt-out of reorgs. The frequency and depth of reorgs were debated, with suggestions for frequent reorgs (e.g., every block) or less frequent ones (e.g., once per week). The depth of reorgs was considered, with different depths serving different testing purposes. It was proposed that the depth of reorgs be deterministically random within a minimum and maximum range based on block hash or nonce.Two scenarios were suggested for testing reorg handling: a race between two chains and a chain rollback scenario. Questions arose regarding the frequency of reorgs on the default Signet and how engineers currently test their applications' reorg handling.Developers sought feedback on implementing support for planned chain reorganizations in Signet. Two scenarios were proposed: races between chains and chain rollbacks. Users would have the option to opt-out of reorgs by setting a version bit flag on affected blocks. The frequency and depth of reorgs would depend on user needs, considering users across different time zones. The first step would be to implement the race scenario and set up a public test-Signet. If there is interest, chain rollbacks could be implemented, and conflicting transactions could be included in the branches.Overall, the discussions aimed to find the best approach to simulate mainnet behavior while providing an easy testing environment for applications. Feedback from developers and users was crucial in determining the optimal parameters for reorgs and ensuring a reliable testing environment for Bitcoin developers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Storing-the-Merkle-Tree-in-a-compact-way.xml b/static/bitcoin-dev/Sept_2021/combined_Storing-the-Merkle-Tree-in-a-compact-way.xml index 0fbb254323..e663a23a75 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Storing-the-Merkle-Tree-in-a-compact-way.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Storing-the-Merkle-Tree-in-a-compact-way.xml @@ -1,23 +1,28 @@ - + 2 Combined summary - Storing the Merkle Tree in a compact way - 2023-08-02T04:46:27.874422+00:00 - - shymaa arafat 2021-09-16 15:05:24+00:00 - - - shymaa arafat 2021-09-11 03:00:12+00:00 - + 2025-09-26T16:02:28.045507+00:00 + python-feedgen + + + [bitcoin-dev] Storing the Merkle Tree in a compact way shymaa arafat + 2021-09-11T03:00:00.000Z + + + [bitcoin-dev] [Lightning-dev] " shymaa arafat + 2021-09-16T15:05:00.000Z + + - python-feedgen + 2 Combined summary - Storing the Merkle Tree in a compact way - 2023-08-02T04:46:27.874422+00:00 + 2025-09-26T16:02:28.046039+00:00 - The Utreexo project has been exploring ways to address storage space and traversing issues in the UTXOS Merkle Tree/forest. Currently, storing N internal nodes requires 2N pointers, along with an additional pointer in the leaves special nodes for different traversing options. To overcome this problem, a simple idea has been proposed to eliminate all pointers by using a 2D array with variable row sizes.In this approach, each row of the 2D array, denoted as R[j], has a length of N/2^j. For example, when N=8 nodes, R[0] contains elements from 0 to 7, R[1] contains elements from 8 to 11, R[2] contains elements 12 and 13, and R[3] contains element 14. This way, the total storage required is just 2N-1 nodes, eliminating the need for pointers.Traversing the Merkle Tree becomes more efficient with the right formula. The formula involves fetching proof[i] through pseudo-code, which determines whether to add or subtract 1 from i based on the direction. After determining the direction, the sibling node is added, followed by the rest of the nodes through a loop. This iterative approach transforms a recursion into an iteration, making it applicable to any Merkle Tree.This idea of compressing the Merkle Tree has potential applications in saving storage space and improving traversing efficiency. For a more detailed explanation, lecture notes and a video link are provided, along with a discussion by Shymaa M Arafat on the BitcoinTalk forum. 2021-09-16T15:05:24+00:00 + The Utreexo project has been exploring ways to address storage space and traversing issues in the UTXOS Merkle Tree/forest. Currently, storing N internal nodes requires 2N pointers, along with an additional pointer in the leaves special nodes for different traversing options. To overcome this problem, a simple idea has been proposed to eliminate all pointers by using a 2D array with variable row sizes.In this approach, each row of the 2D array, denoted as R[j], has a length of N/2^j. For example, when N=8 nodes, R[0] contains elements from 0 to 7, R[1] contains elements from 8 to 11, R[2] contains elements 12 and 13, and R[3] contains element 14. This way, the total storage required is just 2N-1 nodes, eliminating the need for pointers.Traversing the Merkle Tree becomes more efficient with the right formula. The formula involves fetching proof[i] through pseudo-code, which determines whether to add or subtract 1 from i based on the direction. After determining the direction, the sibling node is added, followed by the rest of the nodes through a loop. This iterative approach transforms a recursion into an iteration, making it applicable to any Merkle Tree.This idea of compressing the Merkle Tree has potential applications in saving storage space and improving traversing efficiency. For a more detailed explanation, lecture notes and a video link are provided, along with a discussion by Shymaa M Arafat on the BitcoinTalk forum. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml b/static/bitcoin-dev/Sept_2021/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml index ac679703c6..47bf6468d1 100644 --- a/static/bitcoin-dev/Sept_2021/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml +++ b/static/bitcoin-dev/Sept_2021/combined_TAPLEAF-UPDATE-VERIFY-covenant-opcode.xml @@ -1,59 +1,79 @@ - + 2 Combined summary - TAPLEAF_UPDATE_VERIFY covenant opcode - 2023-08-02T04:43:31.285155+00:00 - - Tim Ruffing 2022-07-08 19:52:12+00:00 - - - Billy Tetrud 2021-10-29 15:47:12+00:00 - - - Olaoluwa Osuntokun 2021-09-23 00:29:18+00:00 - - - Antoine Riard 2021-09-22 01:40:16+00:00 - - - Anthony Towns 2021-09-20 14:52:46+00:00 - - - Antoine Riard 2021-09-18 14:11:10+00:00 - - - Anthony Towns 2021-09-15 06:50:51+00:00 - - - Antoine Riard 2021-09-12 23:37:56+00:00 - - - Anthony Towns 2021-09-11 03:26:44+00:00 - - - Anthony Towns 2021-09-10 07:42:19+00:00 - - - Antoine Riard 2021-09-10 04:12:24+00:00 - - - Jeremy 2021-09-09 19:26:37+00:00 - - - Jeremy 2021-09-09 15:54:25+00:00 - - - darosior 2021-09-09 12:56:10+00:00 - - - Matt Corallo 2021-09-09 09:16:12+00:00 - - - Anthony Towns 2021-09-09 06:53:30+00:00 - - - Anthony Towns 2021-09-09 06:41:38+00:00 - + 2025-09-26T16:02:51.314215+00:00 + python-feedgen + + + [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode Anthony Towns + 2021-09-09T06:41:00.000Z + + + Anthony Towns + 2021-09-09T06:53:00.000Z + + + Matt Corallo + 2021-09-09T09:16:00.000Z + + + darosior + 2021-09-09T12:56:00.000Z + + + Jeremy + 2021-09-09T15:54:00.000Z + + + Jeremy + 2021-09-09T19:26:00.000Z + + + Antoine Riard + 2021-09-10T04:12:00.000Z + + + Anthony Towns + 2021-09-10T07:42:00.000Z + + + Anthony Towns + 2021-09-11T03:26:00.000Z + + + Antoine Riard + 2021-09-12T23:37:00.000Z + + + Anthony Towns + 2021-09-15T06:50:00.000Z + + + Antoine Riard + 2021-09-18T14:11:00.000Z + + + Anthony Towns + 2021-09-20T14:52:00.000Z + + + Antoine Riard + 2021-09-22T01:40:00.000Z + + + Olaoluwa Osuntokun + 2021-09-23T00:29:00.000Z + + + Billy Tetrud + 2021-10-29T15:47:00.000Z + + + Tim Ruffing + 2022-07-08T19:52:00.000Z + + @@ -71,13 +91,13 @@ - python-feedgen + 2 Combined summary - TAPLEAF_UPDATE_VERIFY covenant opcode - 2023-08-02T04:43:31.285155+00:00 + 2025-09-26T16:02:51.316190+00:00 - In the context of Taproot and off-chain contract transactions, the conversation revolves around proposing new opcodes and discussing various optimizations and security concerns. One proposal is for a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV), which would allow for updating the internal public key, specifying a new step for the merkle path, and removing scripts or merkle path steps. The author suggests modifying the proposal to obtain the script from the annex, making it more powerful and allowing for dynamic script updates. This modification would require the addition of an OP_PUSH_ANNEX opcode.The discussion also touches on the issue of utxos interacting with each other and proposes the use of a fixed ID to identify contracts. This would allow transactions to spend/interact with a contract without needing to know the set of active utxos where that contract lives. Nodes would need to maintain an extra index into the UTXO set, but this can be alleviated with a utreexo-like solution.Another topic of discussion is the design and implementation of specific capabilities for off-chain contract transactions. Suggestions include splitting funds between multiple parties, selective withdrawals based on time or conditions, and using opcodes like IN_OUT_AMOUNT to specify authorized withdrawal ranges for hot wallets. Security concerns, such as replay attacks and trust in counterparty cooperation, are also addressed.The conversation explores different ways to optimize Taproot's smart contract capabilities while maintaining security and reliability. The MERKLESUB opcode is discussed, highlighting its ability to refer to non-corresponding outputs but lacking certain abilities like adding branches or preserving current scripts. Trade-offs and potential solutions are proposed, including extending the signature digest algorithm and introducing a new opcode.Overall, the participants show a deep understanding of the technical complexities involved in designing and implementing off-chain contract transactions. They discuss various proposals, optimizations, and security considerations to enhance the functionality and usability of Taproot and off-chain contracts on the Bitcoin network.Anthony Towns discusses Taproot and proposes splitting the discussion into two parts. The first part focuses on improving the functionality and efficiency of transactions using Taproot scripts. This involves updating a UTXO by changing the taproot tree using a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV). This enables the creation of more complex covenants that limit hot wallet withdrawals, protect funds with both hot and cold wallet keys, and verify that funds are being appropriately retained in the updated scriptPubKey.The second part of the discussion addresses more efficient and private one-in, one-out transactions within a pooled fund represented by a UTXO. However, this method requires everyone in the pool to be online to sign via the key path, which can limit the number of people who can reasonably be included in a pool before there's a breakdown. This enables joint funding of ventures, where participants put BTC into a pooled UTXO, ready to finalize the purchase of land while having the ability to reclaim their funds if the deal falls through.Despite these advantages, both proposals have limitations. The first proposal cannot tweak scripts in areas of the merkle tree that it cannot see, while the second proposal requires all members of the pool to be online to sign via the key path. Bitcoin developer AJ Towns believes that these limitations could be simulated with CAT and CHECKSIGFROMSTACK but introducing dedicated opcodes for this functionality would make the feature easier to use correctly and cheap and efficient for both wallets and nodes to validate.In addition to the discussion on Taproot, Anthony Towns also addresses other aspects related to Taproot implementation. He suggests upgrading ADD, SUB, and the comparison operators to support 64-bit values to resolve issues with complicated calculations. He also discusses TLUV, which controls how spending scripts can change between input sPK and output sPK, and proposes a script for implementing the release/locked/available vault construct. Furthermore, he explores the issue of TLUV's parity in taproot addresses and suggests various approaches to solve it.The context also mentions constructing hashes programmatically using "OP_CAT" or similar functionality, allowing for interesting behavior such as adding oneself to a pool if they contribute at least 10 BTC. However, using templates is necessary when constructing a new script programmatically to ensure efficiency. There is a caveat that people could bypass covenant constraints if allowed to add arbitrary opcodes.Towns further discusses the pooled scheme and updating the internal pubkey, which becomes complicated due to the use of 32-byte x-only pubkeys for the scriptPubKey and the internal public key. He provides an example scenario where removing a participant from the pool might result in switching the scriptPubKey, causing potential issues with key path spends.Overall, the context provides a detailed discussion of various aspects of Taproot and potential issues that may arise when constructing a new script programmatically. While Towns proposes solutions to these issues, there are still caveats to consider. The article concludes by suggesting that dedicated opcodes for this functionality would make 2022-07-08T19:52:12+00:00 + In the context of Taproot and off-chain contract transactions, the conversation revolves around proposing new opcodes and discussing various optimizations and security concerns. One proposal is for a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV), which would allow for updating the internal public key, specifying a new step for the merkle path, and removing scripts or merkle path steps. The author suggests modifying the proposal to obtain the script from the annex, making it more powerful and allowing for dynamic script updates. This modification would require the addition of an OP_PUSH_ANNEX opcode.The discussion also touches on the issue of utxos interacting with each other and proposes the use of a fixed ID to identify contracts. This would allow transactions to spend/interact with a contract without needing to know the set of active utxos where that contract lives. Nodes would need to maintain an extra index into the UTXO set, but this can be alleviated with a utreexo-like solution.Another topic of discussion is the design and implementation of specific capabilities for off-chain contract transactions. Suggestions include splitting funds between multiple parties, selective withdrawals based on time or conditions, and using opcodes like IN_OUT_AMOUNT to specify authorized withdrawal ranges for hot wallets. Security concerns, such as replay attacks and trust in counterparty cooperation, are also addressed.The conversation explores different ways to optimize Taproot's smart contract capabilities while maintaining security and reliability. The MERKLESUB opcode is discussed, highlighting its ability to refer to non-corresponding outputs but lacking certain abilities like adding branches or preserving current scripts. Trade-offs and potential solutions are proposed, including extending the signature digest algorithm and introducing a new opcode.Overall, the participants show a deep understanding of the technical complexities involved in designing and implementing off-chain contract transactions. They discuss various proposals, optimizations, and security considerations to enhance the functionality and usability of Taproot and off-chain contracts on the Bitcoin network.Anthony Towns discusses Taproot and proposes splitting the discussion into two parts. The first part focuses on improving the functionality and efficiency of transactions using Taproot scripts. This involves updating a UTXO by changing the taproot tree using a new opcode called "TAPLEAF_UPDATE_VERIFY" (TLUV). This enables the creation of more complex covenants that limit hot wallet withdrawals, protect funds with both hot and cold wallet keys, and verify that funds are being appropriately retained in the updated scriptPubKey.The second part of the discussion addresses more efficient and private one-in, one-out transactions within a pooled fund represented by a UTXO. However, this method requires everyone in the pool to be online to sign via the key path, which can limit the number of people who can reasonably be included in a pool before there's a breakdown. This enables joint funding of ventures, where participants put BTC into a pooled UTXO, ready to finalize the purchase of land while having the ability to reclaim their funds if the deal falls through.Despite these advantages, both proposals have limitations. The first proposal cannot tweak scripts in areas of the merkle tree that it cannot see, while the second proposal requires all members of the pool to be online to sign via the key path. Bitcoin developer AJ Towns believes that these limitations could be simulated with CAT and CHECKSIGFROMSTACK but introducing dedicated opcodes for this functionality would make the feature easier to use correctly and cheap and efficient for both wallets and nodes to validate.In addition to the discussion on Taproot, Anthony Towns also addresses other aspects related to Taproot implementation. He suggests upgrading ADD, SUB, and the comparison operators to support 64-bit values to resolve issues with complicated calculations. He also discusses TLUV, which controls how spending scripts can change between input sPK and output sPK, and proposes a script for implementing the release/locked/available vault construct. Furthermore, he explores the issue of TLUV's parity in taproot addresses and suggests various approaches to solve it.The context also mentions constructing hashes programmatically using "OP_CAT" or similar functionality, allowing for interesting behavior such as adding oneself to a pool if they contribute at least 10 BTC. However, using templates is necessary when constructing a new script programmatically to ensure efficiency. There is a caveat that people could bypass covenant constraints if allowed to add arbitrary opcodes.Towns further discusses the pooled scheme and updating the internal pubkey, which becomes complicated due to the use of 32-byte x-only pubkeys for the scriptPubKey and the internal public key. He provides an example scenario where removing a participant from the pool might result in switching the scriptPubKey, causing potential issues with key path spends.Overall, the context provides a detailed discussion of various aspects of Taproot and potential issues that may arise when constructing a new script programmatically. While Towns proposes solutions to these issues, there are still caveats to consider. The article concludes by suggesting that dedicated opcodes for this functionality would make - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2021/combined_Test-cases-for-Taproot-signature-message.xml b/static/bitcoin-dev/Sept_2021/combined_Test-cases-for-Taproot-signature-message.xml index c1b06393cc..150831d109 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Test-cases-for-Taproot-signature-message.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Test-cases-for-Taproot-signature-message.xml @@ -1,35 +1,43 @@ - + 2 Combined summary - Test cases for Taproot signature message - 2023-08-02T04:50:14.059947+00:00 - - Giacomo Caironi 2021-10-06 20:35:51+00:00 - - - Giacomo Caironi 2021-09-18 11:32:28+00:00 - - - Riccardo Casatta 2021-09-17 07:07:48+00:00 - - - Pieter Wuille 2021-09-16 22:30:19+00:00 - - - Giacomo Caironi 2021-09-16 21:36:48+00:00 - + 2025-09-26T16:02:42.849656+00:00 + python-feedgen + + + [bitcoin-dev] Test cases for Taproot signature message Giacomo Caironi + 2021-09-16T21:36:00.000Z + + + Pieter Wuille + 2021-09-16T22:30:00.000Z + + + Riccardo Casatta + 2021-09-17T07:07:00.000Z + + + Giacomo Caironi + 2021-09-18T11:32:00.000Z + + + Giacomo Caironi + 2021-10-06T20:35:00.000Z + + - python-feedgen + 2 Combined summary - Test cases for Taproot signature message - 2023-08-02T04:50:14.059947+00:00 + 2025-09-26T16:02:42.850372+00:00 - A pull request has been opened for the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The pull request is related to a discussion between Giacomo Caironi and Pieter Wuille on the bitcoin-dev mailing list.Caironi had created three test cases for the SigMsg function in a python implementation of bitcoin signature messages, but he was unsure if they were correct. He had also noted that the documentation and test vectors for Taproot signature message were not as clear as those for Segwit signature message.Wuille agreed with Caironi's observations and explained that BIP 341 defines a common message function for Taproot and Segwit, which is then built up for key path spending and tapscript spending respectively. While this could have been a separate BIP, it would not have been a very clean separation. Wuille did not support changing this at the moment given the state of deployment of the BIPs, but he acknowledged that the documentation/vectors could be improved in the existing documents.Caironi had also pointed out that the test vectors for Taproot were not atomic and did not target a specific part of the code, making debugging difficult. Wuille agreed and suggested that test vectors for certain P2TR scriptPubKeys, derived from certain internal keys and script trees, could be useful for developers of signing code. Wuille welcomed Caironi's offer to write test cases for Taproot and offered to help integrate them in Bitcoin Core and the BIPs.The sender created three test cases for the SigMsg function, which can be found at a provided link. The tests cover most of the function but do not include the ext_flag, so they are only applicable to taproot key paths. If one wants to test script paths, they would need to implement more than this function and use the official test vector. The sender requests that someone review the test cases.In a separate email, Giacomo Caironi complains about the lack of documentation for Taproot signature messages compared to Segwit signature messages in BIPs. The signature message function is defined in BIP 341, while the test vectors are in a different BIP 341, making it confusing.Pieter Wuille responds by clarifying that there is no separate BIP for the signature message function because it is different for BIP341 and BIP342. The common part could have been a separate BIP, but given the state of deployment, he does not support changing it at this point. He suggests improving existing documentation/vectors instead.Giacomo Caironi also notes that the test vectors for Taproot have no documentation and are not atomic, making it difficult to debug when something goes wrong. Pieter Wuille agrees and notes that the existing tests are intended for verifying an implementation against and ensuring future code changes don't break anything. While the existing tests have higher coverage than the Segwit tests, they are not useful as documentation. Pieter Wuille suggests writing test vectors aimed at helping debugging issues, such as the sighash code or P2TR scriptPubKeys derived from internal keys and script trees.A developer named Riccardo Casatta has written the Rust implementation of Bitcoin signature messages and created some test vectors to double-check. These test vectors can be found on GitHub.Meanwhile, Giacomo Caironi has worked on a Python implementation of Bitcoin signature messages and noticed that there is better documentation for Segwit signature message than Taproot. He suggests creating a different BIP only for Taproot signature message instead of defining it in BIP 341 and keeping the test vectors in a different BIP. The test vectors for Taproot have no documentation and are not atomic, which makes debugging difficult. In contrast, BIP 143 provides hash preimages for debugging the function in Segwit signature hash. Caironi is willing to write the test cases for Taproot if his idea is accepted. This is his first time contributing to Bitcoin and he apologizes if he wrote something wrong due to English being his second language.On September 16th, 2021, Giacomo Caironi posted on bitcoin-dev forum regarding the documentation of Taproot signature message. He found that Segwit signature messaging had better documentation than Taproot. According to Caironi, Segwit signature message has its own BIP with test cases while Taproot's signature message function is defined in BIP 341 and the test vectors are in a different BIP (also 341). Caironi suggested creating a separate BIP for Taproot signature message like Segwit.Pieter Wuille responded by mentioning that there is no separate BIP for the signature message function as the message function is different for BIP341 and BIP342. Wuille suggested that the existing documentation/vectors can be improved in the existing documents instead of creating a separate BIP.Caironi also brought up the issue of test vectors for Taproot having no documentation and not being atomic, which can 2021-10-06T20:35:51+00:00 + A pull request has been opened for the Bitcoin Improvement Proposals (BIPs) repository on GitHub. The pull request is related to a discussion between Giacomo Caironi and Pieter Wuille on the bitcoin-dev mailing list.Caironi had created three test cases for the SigMsg function in a python implementation of bitcoin signature messages, but he was unsure if they were correct. He had also noted that the documentation and test vectors for Taproot signature message were not as clear as those for Segwit signature message.Wuille agreed with Caironi's observations and explained that BIP 341 defines a common message function for Taproot and Segwit, which is then built up for key path spending and tapscript spending respectively. While this could have been a separate BIP, it would not have been a very clean separation. Wuille did not support changing this at the moment given the state of deployment of the BIPs, but he acknowledged that the documentation/vectors could be improved in the existing documents.Caironi had also pointed out that the test vectors for Taproot were not atomic and did not target a specific part of the code, making debugging difficult. Wuille agreed and suggested that test vectors for certain P2TR scriptPubKeys, derived from certain internal keys and script trees, could be useful for developers of signing code. Wuille welcomed Caironi's offer to write test cases for Taproot and offered to help integrate them in Bitcoin Core and the BIPs.The sender created three test cases for the SigMsg function, which can be found at a provided link. The tests cover most of the function but do not include the ext_flag, so they are only applicable to taproot key paths. If one wants to test script paths, they would need to implement more than this function and use the official test vector. The sender requests that someone review the test cases.In a separate email, Giacomo Caironi complains about the lack of documentation for Taproot signature messages compared to Segwit signature messages in BIPs. The signature message function is defined in BIP 341, while the test vectors are in a different BIP 341, making it confusing.Pieter Wuille responds by clarifying that there is no separate BIP for the signature message function because it is different for BIP341 and BIP342. The common part could have been a separate BIP, but given the state of deployment, he does not support changing it at this point. He suggests improving existing documentation/vectors instead.Giacomo Caironi also notes that the test vectors for Taproot have no documentation and are not atomic, making it difficult to debug when something goes wrong. Pieter Wuille agrees and notes that the existing tests are intended for verifying an implementation against and ensuring future code changes don't break anything. While the existing tests have higher coverage than the Segwit tests, they are not useful as documentation. Pieter Wuille suggests writing test vectors aimed at helping debugging issues, such as the sighash code or P2TR scriptPubKeys derived from internal keys and script trees.A developer named Riccardo Casatta has written the Rust implementation of Bitcoin signature messages and created some test vectors to double-check. These test vectors can be found on GitHub.Meanwhile, Giacomo Caironi has worked on a Python implementation of Bitcoin signature messages and noticed that there is better documentation for Segwit signature message than Taproot. He suggests creating a different BIP only for Taproot signature message instead of defining it in BIP 341 and keeping the test vectors in a different BIP. The test vectors for Taproot have no documentation and are not atomic, which makes debugging difficult. In contrast, BIP 143 provides hash preimages for debugging the function in Segwit signature hash. Caironi is willing to write the test cases for Taproot if his idea is accepted. This is his first time contributing to Bitcoin and he apologizes if he wrote something wrong due to English being his second language.On September 16th, 2021, Giacomo Caironi posted on bitcoin-dev forum regarding the documentation of Taproot signature message. He found that Segwit signature messaging had better documentation than Taproot. According to Caironi, Segwit signature message has its own BIP with test cases while Taproot's signature message function is defined in BIP 341 and the test vectors are in a different BIP (also 341). Caironi suggested creating a separate BIP for Taproot signature message like Segwit.Pieter Wuille responded by mentioning that there is no separate BIP for the signature message function as the message function is different for BIP341 and BIP342. Wuille suggested that the existing documentation/vectors can be improved in the existing documents instead of creating a separate BIP.Caironi also brought up the issue of test vectors for Taproot having no documentation and not being atomic, which can - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml b/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml index 8cb1e7f9cf..c0bf402cce 100644 --- a/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml +++ b/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2025-09-26T14:20:21.674234+00:00 + 2025-09-26T15:27:50.414334+00:00 python-feedgen Craig Raw 2022-09-26 08:23:18+00:00 @@ -85,10 +85,11 @@ + 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2025-09-26T14:20:21.674427+00:00 + 2025-09-26T15:27:50.414535+00:00 2022-09-26T08:23:18+00:00 The proposed standard aims to create a defined format for transferring labels that users have applied to transactions, addresses, inputs, or outputs in their wallets. The format uses the comma-separated values (CSV) format, which is widely supported. Each record in the CSV file consists of two fields: the reference to a transaction, address, input, or output, and the label applied to that reference. The proposal suggests using ZIP compression for the CSV file, with optional AES encryption.Some feedback on the proposal includes suggestions for improvements, such as adding a version byte to the header line, making the header line mandatory, and using an unsigned 32-bit integer for the second column. There are also suggestions to remove the optional encryption feature and not include input and output types in the export to avoid privacy leaks. Instead, commentators suggest adding a third column for item type identification.Despite disagreement on the use of CSV as a standard format, the goal of the proposal is to create a standardized format for importing and exporting wallet labels. The proposed format is a simple two-column CSV file, aiming to make label management more accessible to users and ensure compatibility between different wallet implementations. Feedback on the proposal is appreciated, and further improvements may be made based on the feedback received.The use of CSV for transferring labels between wallet applications is motivated by its wide accessibility and integration with existing processes and tools like Excel. However, there is some disagreement about using CSV, with suggestions to use JSON instead due to concerns about CSV compatibility and parsing effort. Despite this disagreement, the proposal aims to create a standard for importing and exporting labels from a wallet, regardless of the chosen data format.The proposal specifies a two-column CSV format, where the first column contains the reference to a transaction, address, input, or output, and the second column contains the label. The CSV file can be compressed using ZIP and optionally encrypted using AES. Importing applications may truncate labels if necessary, while exporting applications may omit records with no labels or labels of zero length.The proposal seeks to make label management accessible to users without technical expertise and reduce file size while ensuring compatibility. The discussion on the Bitcoin-dev mailing list provides insight into ongoing development work on the Bitcoin protocol and the collaborative nature of the Bitcoin development community.There is some disagreement about using CSV as the standard format for transferring labels, with suggestions to use JSON instead. One commenter suggests including descriptors in the format for advanced users. In response to a question about SLIP-0015, it is stated that SLIP-0015 has different design goals and limitations compared to the proposed BIP.The proposal allows for ZIP compression and optional AES encryption of the CSV file. The password for encryption should be the textual representation of the wallet's extended public key. The aim of this proposal is to create a standard for exporting and importing labels from a wallet, avoiding lock-in to a specific application, and making label management accessible to non-technical users.Feedback on the proposal is requested, and a reference implementation is yet to be determined. Suggestions for additions and changes to the format include adding a version byte, making the header line mandatory, requiring double quotes around the label, and writing a more robust importer algorithm. The proposal aims to standardize the export and import of labels using a simple CSV format. diff --git a/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 52942a9564..1bc22ff5c4 100644 --- a/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -2,7 +2,7 @@ 2 Combined summary - On a new community process to specify covenants - 2025-09-26T14:20:06.769538+00:00 + 2025-09-26T15:27:46.114195+00:00 python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -105,10 +105,11 @@ + 2 Combined summary - On a new community process to specify covenants - 2025-09-26T14:20:06.769730+00:00 + 2025-09-26T15:27:46.114395+00:00 2022-10-07T15:33:12+00:00 The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest diff --git a/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml index c6e5aabe75..d87b68c34d 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml @@ -2,7 +2,7 @@ 2 Combined summary - Packaged Transaction Relay - 2025-09-26T14:20:23.821984+00:00 + 2025-09-26T15:27:52.561312+00:00 python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - Packaged Transaction Relay - 2025-09-26T14:20:23.822159+00:00 + 2025-09-26T15:27:52.561508+00:00 2022-10-10T22:05:38+00:00 The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. diff --git a/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml b/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml index 34ff6940ec..24f9196a03 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml @@ -2,7 +2,7 @@ 2 Combined summary - Transcript: Online Socratic on MuSig2 - 2025-09-26T14:19:53.928963+00:00 + 2025-09-26T15:27:43.963988+00:00 python-feedgen Michael Folkson 2022-09-12 16:00:52+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Transcript: Online Socratic on MuSig2 - 2025-09-26T14:19:53.929118+00:00 + 2025-09-26T15:27:43.964122+00:00 2022-09-12T16:00:52+00:00 In a conversation between Ali Sherief and Michael Folkson, the issue of theft and online connectivity with signature generation is discussed. Michael explains that generating a signature requires private keys, which raises concerns about security and theft. However, he suggests that using multisig arrangements can prevent loss of funds in case of theft of a single private key. Additionally, he mentions that key aggregation multisig increases interactivity requirements.Michael clarifies that while there isn't a concept of a "lite node" in signature generation, it makes more sense in the realm of verification. He gives an example of Liquid, where currently 11 signatures go onchain when funds are moved. However, if Liquid used a key aggregation scheme like FROST, only a single signature would be required onchain. He also suggests the possibility of increasing the number of signatures or implementing a nested MuSig/FROST scheme for added security.Ali contacts Michael regarding the detailed and comprehensive Socratic transcript, which covers various problems including theft and offline issues. Ali inquires if any research has been done that doesn't involve a trade-off between theft and online connectivity. While ROAST and Liquid provide solutions, they rely on centralized nodes. Ali proposes the idea of decentralizing federated nodes into "lite nodes" managed by each service wanting payment, creating a threshold signature from multiple subscribers paying simultaneously.On August 11th, an online Socratic session was held featuring Tim Ruffing and Elizabeth Crites, discussing topics related to MuSig(2), FROST, ROAST, and more. The transcript of the session can be found on btctranscripts.com, and the video is available on YouTube. A reading list has also been compiled, containing resources on MuSig(2), FROST, and ROAST. During the discussion, participants covered various subjects, including BIP340, handling x-only public keys in MuSig2, the proposed TLUV covenant opcode, the history and improvements of MuSig, comparisons between MuSig2 and FROST for multisig schemes, the absence of proofs of possession in MuSig2, and the current state of the draft MuSig2 BIP.Although the session was lengthy (approximately 2.5 hours), it offered valuable insights into these topics, making the transcript or video useful for anyone interested in the discussed subjects. Jonas Nick also tweeted that the MuSig2 BIP is nearing a stable version 1.0, which will be beneficial for those implementing it. All relevant sources and links have been provided for further reference. diff --git a/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml b/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml index 434f0f9c6e..7624edd444 100644 --- a/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml +++ b/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml @@ -2,7 +2,7 @@ 2 Combined summary - joinstr: coinjoin implementation using nostr - 2025-09-26T14:20:17.411360+00:00 + 2025-09-26T15:27:48.263868+00:00 python-feedgen alicexbt 2022-09-10 10:17:37+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - joinstr: coinjoin implementation using nostr - 2025-09-26T14:20:17.411525+00:00 + 2025-09-26T15:27:48.264041+00:00 2022-09-10T10:17:37+00:00 A developer named alicexbt has created a proof-of-concept python script to implement coinjoin using nostr, a decentralized network based on cryptographic keypairs. This implementation utilizes several Bitcoin Core wallet and RPC commands and requires the python-nostr library for coordination between peers. The process involves 5 peers coordinating to create, sign, and broadcast a coinjoin transaction. Each step of the process is published as an event using a nostr relay, and users can use multiple relays simultaneously to avoid trusting a single relay. However, there is a vulnerability of denial of service in the implementation, where a malicious user can register multiple outputs with the same secret, causing an ongoing free denial of service attack without attribution or defense.To address this issue, PR #24058 (basic support BIP-322) can be implemented to add proof of ownership. Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, they can send `txid:out` with a message signed with the address, verify using `verifymessage`, and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO. The cryptographic scheme mentioned as an alternative to blind signatures isn't implemented yet, as it requires a NIP and at least one relay using it.The author plans to continue developing coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. Custom relays are supported by Nostr, examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. The author will run a free and open nostr relay for this project and try to fix the DoS issues before a mainnet version is released for the python script (for nerds) and android app (for all users).The email is sent using Proton Mail secure email, and the author invites opinions on the experiment. The email thread is part of the bitcoin-dev mailing list hosted by lists.linuxfoundation.org. The author credits Fiatjaf, Andrew Chow, Jeff Thibault, and existing coinjoin implementations for their contributions. The author also mentions the creation of an Android app for joinstr in the coming week.Overall, the developer's message provides insights into a coinjoin implementation using Nostr, the challenges and limitations of the current system, and potential improvements to make it more secure. The email includes relevant links to GitHub repositories and provides event IDs and a Coinjoin transaction ID for reference. From 6077c09aa50a84efa426e4ab663793d8cc6f7e55 Mon Sep 17 00:00:00 2001 From: urvishp80 Date: Sat, 11 Oct 2025 22:21:09 +0000 Subject: [PATCH 4/5] Updated XML files with threading structure (threading update only) for years 2012-2025 --- ...ed_Adding-request-reply-id-in-messages.xml | 13 ++-- .../combined_Announcement-libcoin.xml | 13 ++-- .../combined_Announcing-the-IFEX-Project.xml | 13 ++-- .../April_2012/combined_BIP-31.xml | 13 ++-- ...-to-improve-the-availability-of-blocks.xml | 13 ++-- ...TX-fill-or-kill-deterministic-behavior.xml | 13 ++-- .../combined_Network-version-increase.xml | 13 ++-- ...Signature-Blocks-and-URI-Sign-Requests.xml | 13 ++-- .../combined_Trusted-identities.xml | 13 ++-- .../combined_new-bitcoin-org-clients-page.xml | 13 ++-- .../combined_A-mining-pool-at-46-.xml | 13 ++-- .../combined_Anti-DoS-for-tx-replacement.xml | 13 ++-- .../combined_BIP21-bitcoin-URIs-and-HTML5.xml | 13 ++-- ...mbined_Bitcoin-meets-the-Semantic-Web-.xml | 13 ++-- ...combined_Cold-Signing-Payment-Requests.xml | 13 ++-- ...ombined_DOS-Attacks-on-bitcoin-client-.xml | 13 ++-- ...ined_Fwd-Service-bits-for-pruned-nodes.xml | 13 ++-- ...allet-as-part-of-Google-Summer-of-Code.xml | 13 ++-- ...mbined_Integration-testing-for-BitCoin.xml | 13 ++-- .../combined_On-going-data-spam.xml | 13 ++-- ...message-verifymessage-to-P2SH-multisig.xml | 13 ++-- ...mbined_Sending-Bitcoins-using-RSA-keys.xml | 13 ++-- ...combined_Service-bits-for-pruned-nodes.xml | 13 ++-- ...torage-in-txouts-The-Ultimate-Solution.xml | 13 ++-- ...ed_Who-is-creating-non-DER-signatures-.xml | 13 ++-- .../combined_bitcoin-pull-requests.xml | 13 ++-- .../April_2013/combined_bitcoinj-0-8.xml | 13 ++-- ...llet-root-key-with-optional-encryption.xml | 13 ++-- .../combined_-bits-Unit-of-account.xml | 17 ++--- ...s-using-replace-by-fee-and-game-theory.xml | 13 ++-- ...PV-proofs-via-block-header-commitments.xml | 13 ++-- ...t-Atomic-Cross-Chain-Transfer-Protocol.xml | 13 ++-- .../combined_BIP-Hash-Locked-Transaction.xml | 13 ++-- .../combined_BIP-Selector-Script.xml | 13 ++-- ...0071-media-type-registration-with-IANA.xml | 13 ++-- ...P32-wallet-structure-in-use-Remove-it-.xml | 17 ++--- .../combined_Bitcoin-Core-Nightly-Builds.xml | 13 ++-- ...ind-in-background-mode-for-SPV-wallets.xml | 13 ++-- ...-of-3-transaction-signing-in-Bitcoind-.xml | 13 ++-- .../April_2014/combined_Chain-pruning.xml | 13 ++-- ...llocation-to-discourage-Finney-attacks.xml | 13 ++-- ...ed_Compatibility-Bitcoin-Qt-with-Tails.xml | 13 ++-- .../combined_Detailed-gitian-build-guide.xml | 13 ++-- ...elopment-Roadmap-of-Bitcoin-Core-0-9-2.xml | 13 ++-- ...-a-lot-easier-than-most-people-realise.xml | 13 ++-- ...e-authentication-using-Bitcoin-address.xml | 13 ++-- ...d_Economics-of-information-propagation.xml | 13 ++-- ...elf-escrow-for-high-value-transactions.xml | 13 ++-- ...ayment-protocol-BIP-0070-and-BIP-0072-.xml | 13 ++-- ...eedback-request-colored-coins-protocol.xml | 13 ++-- ...ned_Finite-monetary-supply-for-Bitcoin.xml | 13 ++-- .../combined_Mailing-list-abuse.xml | 13 ++-- ...32-structure-for-P2SH-multisig-wallets.xml | 13 ++-- .../combined_New-BIP32-structure.xml | 13 ++-- ..._Okay-time-to-bring-up-bitcoin-bitcoin.xml | 13 ++-- ...Secret-Sharing-of-Bitcoin-private-keys.xml | 13 ++-- .../combined_Proof-of-Stake-branch-.xml | 13 ++-- ...oposal-for-extra-nonce-in-block-header.xml | 13 ++-- ...sal-to-change-payment-protocol-signing.xml | 13 ++-- ...d-Payment-Verification-for-Smartphones.xml | 13 ++-- ...Standardizing-OP-RETURN-message-format.xml | 13 ++-- .../April_2014/combined_Timed-testing.xml | 13 ++-- ...ed_Translators-Needed-for-Bitcoin-Core.xml | 13 ++-- ...mbined_Tree-chains-preliminary-summary.xml | 13 ++-- .../combined_Ubuntu-LTS-Packaging-.xml | 13 ++-- .../combined_Update-alert-false-positives.xml | 13 ++-- ...-wallet-in-Windows-XP-or-drop-support-.xml | 13 ++-- .../combined_Why-are-we-bleeding-nodes-.xml | 13 ++-- ...w-internet-when-running-Bitcoin-nodes-.xml | 13 ++-- ...-wallet-in-Windows-XP-or-drop-support-.xml | 13 ++-- .../combined_please-check-my-debug-log.xml | 13 ++-- ...ombined_question-about-ProcessMessage-.xml | 13 ++-- ...ure-assigned-bitcoin-address-directory.xml | 13 ++-- ...s-a-service-and-proof-of-local-storage.xml | 17 ++--- ...-95-threshold-for-transaction-versions.xml | 13 ++-- ...e-0-10-1-release-candidate-2-available.xml | 13 ++-- .../combined_Bitcoin-core-0-11-planning.xml | 13 ++-- .../combined_Build-your-own-nHashType.xml | 13 ++-- ...regtest-specific-setgenerate-behaviour.xml | 13 ++-- .../April_2015/combined_DevCore-London.xml | 13 ++-- ...ned_Double-spending-and-replace-by-fee.xml | 13 ++-- .../combined_Fwd-Reusable-payment-codes.xml | 13 ++-- ...od-bitcoin-script-decompiler-in-Python.xml | 13 ++-- ...e-logarithm-problem-on-elliptic-curves.xml | 13 ++-- .../April_2015/combined_Proof-of-Payment.xml | 13 ++-- ...CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml | 13 ++-- ...n-Multisignature-Deterministic-Wallets.xml | 13 ++-- .../combined_Reusable-payment-codes.xml | 13 ++-- .../April_2015/combined_Where-do-I-start-.xml | 13 ++-- .../April_2016/combined_AsicBoost.xml | 5 +- ...ned_BIP-CPRKV-Check-private-key-verify.xml | 5 +- ...e-0-12-1-release-candidate-1-available.xml | 5 +- .../combined_Proposal-to-update-BIP-32.xml | 5 +- ...p2p-authentication-and-encryption-BIPs.xml | 5 +- ...and-multi-sender-coinjoin-transactions.xml | 5 +- ...and-understand-softforks-and-hardforks.xml | 5 +- ...ert-attack-on-the-Bitcoin-POW-function.xml | 5 +- ...bits-extension-with-guaranteed-lock-in.xml | 5 +- ...ension-block-proposal-by-Jeffrey-et-al.xml | 5 +- ...entness-status-of-the-pruned-relatives.xml | 5 +- ...fork-proposal-from-last-week-s-meeting.xml | 5 +- ...ion-protocol-and-decentralized-storage.xml | 5 +- .../combined_Fee-estimates-and-RBF.xml | 5 +- ...-2021-Taproot-Activation-Meeting-Notes.xml | 5 +- ...mbined_Reminder-on-the-Purpose-of-BIPs.xml | 5 +- ...ng-on-IRC-Tuesday-13th-April-19-00-UTC.xml | 5 +- ...ed_maximum-block-height-on-transaction.xml | 5 +- ...ting-transitory-soft-forks-e-g-for-CTV.xml | 5 +- ...cally-reverting-transitory-soft-forks-.xml | 5 +- ...us-soft-fork-activations-are-attempted.xml | 5 +- ...Bitcoin-fungibility-and-inscribed-sats.xml | 5 +- .../combined_BIP-35-add-mempool-message.xml | 13 ++-- .../Aug_2012/combined_BIP-Custom-Services.xml | 13 ++-- .../combined_Bloom-Filter-Implementation.xml | 13 ++-- ...2459-block-merkle-calculation-exploit-.xml | 13 ++-- ...r-SPV-clients-mempool-getdata-commands.xml | 13 ++-- .../combined_The-Bitcoin-Testing-Project.xml | 13 ++-- .../combined_Version-0-7-release-planning.xml | 13 ++-- .../combined_Android-key-rotation.xml | 13 ++-- .../Aug_2013/combined_BIP-32-5.xml | 13 ++-- ...ned_BitMail-sf-net-encrypted-p2p-email.xml | 13 ++-- ...combined_Bloom-io-attack-effectiveness.xml | 13 ++-- .../combined_Combining-bloom-filters-.xml | 13 ++-- .../combined_Gavin-s-post-0-9-TODO-list-.xml | 13 ++-- .../combined_HTTP-REST-API-for-bitcoind.xml | 13 ++-- ...ined_Idea-for-new-payment-protocol-PKI.xml | 13 ++-- .../Aug_2013/combined_LevelDB-in-master.xml | 13 ++-- ...ned_Making-bitcoin-traceability-harder.xml | 13 ++-- ...riate-XDG-menu-category-for-bitcoin-qt.xml | 13 ++-- .../Aug_2013/combined_NODE-BLOOM-BIP.xml | 13 ++-- ...et-linkable-address-format-Re-request-.xml | 17 ++--- ...combined_Payment-Protocol-BIP-70-71-72.xml | 13 ++-- ...ined_Preparing-for-the-Cryptopocalypse.xml | 13 ++-- ...posal-remove-getwork-RPC-from-bitcoind.xml | 17 ++--- ...ombined_SPV-client-in-pure-JavaScript-.xml | 13 ++-- .../Aug_2013/combined_Safe-auto-updating.xml | 13 ++-- ...-factor-wallet-with-one-time-passwords.xml | 13 ++-- .../Aug_2013/combined_Version-0-9-goals.xml | 13 ++-- ...as-issued-by-a-specific-person-company.xml | 13 ++-- .../Aug_2013/combined_btc-name-server.xml | 13 ++-- ..._-ANN-High-speed-Bitcoin-Relay-Network.xml | 13 ++-- ...ed_Another-weird-transaction-question-.xml | 13 ++-- .../combined_BIP-Custodial-Identities.xml | 13 ++-- .../Aug_2014/combined_BIP32-invalidation.xml | 13 ++-- ...urpose-code-for-voting-pool-HD-wallets.xml | 13 ++-- ...CoinJoin-without-trusted-third-parties.xml | 13 ++-- ...mbined_How-to-create-a-pull-tester-JAR.xml | 13 ++-- .../Aug_2014/combined_Miners-MiTM.xml | 13 ++-- ...VICES-and-advertising-related-services.xml | 13 ++-- ...combined_Outbound-connections-rotation.xml | 13 ++-- ...Secret-Sharing-of-Bitcoin-private-keys.xml | 13 ++-- ...ined_Proposal-Encrypt-bitcoin-messages.xml | 13 ++-- ...ses-was-Outbound-connections-rotation-.xml | 13 ++-- .../Aug_2014/combined_RIP-Hal-Finney.xml | 13 ++-- .../combined_Reconsidering-github.xml | 13 ++-- ...edundant-tx-data-in-blocks-on-the-wire.xml | 13 ++-- ...19-5-orphaned-blocks-at-height-197-324.xml | 13 ++-- ...mbined_Tree-chains-preliminary-summary.xml | 13 ++-- ...coind-startted-with-flushwallet-false-.xml | 13 ++-- ...d_deterministic-transaction-expiration.xml | 13 ++-- ...d_standardize-on-bitcoin-signed-ecies-.xml | 13 ++-- ...Size-Limit-new-research-paper-suggests.xml | 17 ++--- ...opcode-for-relative-locktime-Btc-Drak-.xml | 13 ++-- ...VERIFY-An-opcode-for-relative-locktime.xml | 13 ++-- ...nsensus-rules-changes-soft-hard-forks-.xml | 13 ++-- ...e-between-BIP101-and-Pieter-s-proposal.xml | 13 ++-- ...an-all-agree-on-to-increase-block-size.xml | 13 ++-- ...crease-the-incentive-of-running-a-node.xml | 13 ++-- ...s-related-to-not-rising-the-block-size.xml | 13 ++-- ...cerns-related-to-rising-the-block-size.xml | 13 ++-- ...iculty-depending-on-relative-blocksize.xml | 13 ++-- ...ive-chain-support-for-payment-protocol.xml | 13 ++-- .../combined_Annoucing-Not-BitcoinXT.xml | 13 ++-- ...-Fees-with-Data-Discussion-Draft-0-2-9.xml | 13 ++-- ...-Fees-with-Data-Discussion-Draft-0-2-9.xml | 13 ++-- ...-as-endpoint-for-locktime-calculations.xml | 13 ++-- .../combined_BIP-draft-Hardfork-bit.xml | 13 ++-- ...d_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml | 13 ++-- ...al-for-implementing-AML-KYC-in-bitcoin.xml | 13 ++-- ...ed_Bitcoin-Core-versus-XT-observations.xml | 13 ++-- .../Aug_2015/combined_Bitcoin-XT-0-11A.xml | 13 ++-- .../Aug_2015/combined_Bitcoin-XT-Fork.xml | 13 ++-- ...-system-has-significant-privacy-leaks-.xml | 13 ++-- ...on-t-we-have-an-experimental-hardfork-.xml | 13 ++-- ...ck-size-following-technological-growth.xml | 13 ++-- .../combined_Block-size-hard-fork.xml | 13 ++-- ...-size-implementation-using-Game-Theory.xml | 13 ++-- ...-possible-solution-to-set-minimum-size.xml | 13 ++-- ...ty-Workshop-Sept-12-13-Montreal-Canada.xml | 13 ++-- ...rations-due-to-XT-Not-BitcoinXT-miners.xml | 13 ++-- .../Aug_2015/combined_Censorship.xml | 13 ++-- ...lock-size-retargeting-algorithm-draft-.xml | 13 ++-- ...-nTime-vs-median-time-vs-block-nHeight.xml | 13 ++-- ...oughts-about-all-BIPs-on-this-website-.xml | 13 ++-- ...BIP-fixed-schedule-block-size-increase.xml | 13 ++-- ...coin-Block-Size-Max-Cap-BIP-1xx-Draft-.xml | 13 ++-- ...-Controlled-Bitcoin-Block-Size-Max-Cap.xml | 13 ++-- .../combined_ERRATA-CORRIGE-Short-Theorem.xml | 13 ++-- ...nomic-majority-vote-by-splitting-coins.xml | 13 ++-- .../combined_Eli-Dourado-on-governance-.xml | 17 ++--- ...t-few-big-blocks-with-OP-CSV-and-BIP68.xml | 13 ++-- ...ned_Fees-and-the-block-finding-process.xml | 13 ++-- ...ombined_Future-Of-Bitcoin-Cores-Wallet.xml | 13 ++-- ...ck-size-following-technological-growth.xml | 13 ++-- ...ze-proves-that-computers-should-decide.xml | 13 ++-- ...ea-Efficient-bitcoin-block-propagation.xml | 13 ++-- ...he-transactions-second-Bitcoin-allows-.xml | 13 ++-- .../combined_Incentives-to-run-full-nodes.xml | 13 ++-- ...ing-SPV-nodes-to-pay-for-data-requests.xml | 13 ++-- ...t-chains-to-test-different-block-sizes.xml | 13 ++-- ...itory-was-Bitcoin-Core-and-hard-forks-.xml | 13 ++-- ...0KB-blocks-and-resorting-to-SPV-mining.xml | 13 ++-- .../Aug_2015/combined_Minimum-Block-Size.xml | 13 ++-- ..._Off-chain-transactions-and-miner-fees.xml | 13 ++-- ...ges-in-Uncapped-Block-Size-Fee-Markets.xml | 13 ++-- ...acy-Questionnaire-Mid-Year-2015-report.xml | 13 ++-- ...roposal-Disable-digests-on-bitcoin-dev.xml | 13 ++-- ...pend-on-other-unconfirmed-transactions.xml | 13 ++-- .../combined_Questiosn-about-BIP100.xml | 13 ++-- .../combined_RE-Visualizations-of-Votes.xml | 13 ++-- ...nconfirmed-transactions-with-a-bounty-.xml | 13 ++-- ...-URI-scheme-for-Blockchain-exploration.xml | 13 ++-- ...ned_Revisiting-NODE-BLOOM-Proposed-BIP.xml | 13 ++-- ...s-mailing-list-was-Re-Bitcoin-XT-Fork-.xml | 13 ++-- ...eviously-proposed-exotic-SIGHASH-types.xml | 13 ++-- .../Aug_2015/combined_Splitting-BIPs.xml | 13 ++-- ...ion-and-the-consensus-block-size-limit.xml | 13 ++-- ...-almost-certainly-not-the-real-Satoshi.xml | 13 ++-- ...se-of-tx-version-field-in-BIP62-and-68.xml | 13 ++-- ...ned_Uniquely-identifying-forked-chains.xml | 13 ++-- ...bined_Unlimited-Max-Blocksize-reprise-.xml | 13 ++-- .../combined_Variable-Block-Size-Proposal.xml | 13 ++-- .../combined_Visualizations-of-Votes.xml | 13 ++-- .../combined_Voting-BIP-100-Question-Etc-.xml | 13 ++-- .../combined_Voting-by-locking-coins.xml | 13 ++-- .../Aug_2015/combined_What-Lightning-Is.xml | 13 ++-- ...rary-anti-spam-measure-isn-t-temporary.xml | 13 ++-- ...reeze-of-the-current-protocol-version-.xml | 13 ++-- ...g-up-the-block-size-debate-with-voting.xml | 13 ++-- .../combined_Your-Gmaxwell-exchange.xml | 13 ++-- .../combined_bitcoin-dev-list-etiquette.xml | 13 ++-- ...tion-fails-if-used-in-multiple-threads.xml | 13 ++-- .../bitcoin-dev/Aug_2015/combined_trust.xml | 13 ++-- ...combined_-Changing-the-blocksize-limit.xml | 5 +- ...transactions-after-segwit-is-accepted-.xml | 5 +- .../Aug_2016/combined_Authentication-BIP.xml | 5 +- .../bitcoin-dev/Aug_2016/combined_BIP-151.xml | 5 +- ...IP-Number-Request-Addresses-over-Audio.xml | 5 +- ...combined_BIP-Number-Request-Open-Asset.xml | 5 +- ...-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml | 5 +- .../combined_BIP-clearing-house-addresses.xml | 5 +- .../combined_BIP-draft-HTLC-transactions.xml | 5 +- ...orched-Earth-Doublespending-Protection.xml | 5 +- .../Aug_2016/combined_Fees-and-Accounts.xml | 5 +- ...ntire-content-of-on-chain-transactions.xml | 5 +- ...ed_General-bitcoin-users-mailing-list-.xml | 5 +- .../combined_Hardware-Wallet-Standard.xml | 5 +- ...ntire-content-of-on-chain-transactions.xml | 5 +- ...-IF-and-OP-NOTIF-malleability-in-P2WSH.xml | 5 +- ...mbined_New-BIP-Low-S-values-signatures.xml | 5 +- ...5-Retarget-Call-For-Proposals-Now-Open.xml | 5 +- ...tatus-updates-for-BIP-9-68-112-and-113.xml | 5 +- ...combined_Fwd-Compressed-headers-stream.xml | 5 +- ...in-the-setting-of-blockchain-hardforks.xml | 5 +- ...ing-the-Scalability-Problem-on-Bitcoin.xml | 5 +- ..._UTXO-growth-scaling-solution-proposal.xml | 5 +- .../combined_Claiming-an-OP-RETURN-Prefix.xml | 5 +- ...-around-to-fixing-the-timewarp-attack-.xml | 5 +- ...oposal-for-a-decentralised-mining-pool.xml | 5 +- ...A-method-for-BIP322-signing-delegation.xml | 5 +- ...erivation-Paths-in-a-Single-Descriptor.xml | 5 +- ...P-Proposal-Wallet-Labels-Export-Format.xml | 5 +- ...e-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml | 5 +- .../combined_New-Silent-Payment-version.xml | 5 +- ...community-process-to-specify-covenants.xml | 5 +- .../combined_Regarding-BIP322-edge-cases.xml | 5 +- ...ngly-Tail-Emission-Is-Not-Inflationary.xml | 5 +- ...tr-coinjoin-implementation-using-nostr.xml | 5 +- ...ed_BIP-for-Serverless-Payjoin-AdamISZ-.xml | 5 +- .../combined_Concern-about-Inscriptions-.xml | 5 +- ...ncern-about-Inscriptions-ashneverdawn-.xml | 5 +- ...t-4-pools-is-mining-full-RBF-right-now.xml | 5 +- ...Pull-req-to-enable-Full-RBF-by-default.xml | 5 +- ...-arbitrary-limits-on-OP-Return-outputs.xml | 5 +- ...-accounts-should-be-labels-not-numbers.xml | 13 ++-- ...gation-Demurrage-based-Chain-Vacuuming.xml | 13 ++-- ..._Has-anyone-compiled-under-MacOS-10-8-.xml | 13 ++-- .../Dec_2012/combined_Multiwallet-support.xml | 13 ++-- ...ol-Proposal-Invoices-Payments-Receipts.xml | 13 ++-- ...dmap-to-getting-users-onto-SPV-clients.xml | 13 ++-- ...terministic-Keys-Alternative-to-BIP-32.xml | 13 ++-- ...estnet3-difficulty-transition-problem-.xml | 13 ++-- .../Dec_2012/combined_Zero-length-scripts.xml | 13 ++-- ...t-master-seed-with-optional-encryption.xml | 13 ++-- ...ed_-unSYSTEM-DarkWallet-Best-Practices.xml | 13 ++-- .../combined_0-8-6-release-candidate-1.xml | 13 ++-- .../Dec_2013/combined_Access-to-Mempool.xml | 13 ++-- ...IP-proposal-Authenticated-prefix-trees.xml | 13 ++-- ...oin-development-Digest-Vol-31-Issue-25.xml | 13 ++-- ...oin-development-Digest-Vol-31-Issue-41.xml | 13 ++-- ...oin-difficulty-sanity-check-suggestion.xml | 13 ++-- ...ned_Coin-Control-Send-crash-on-MacOS-X.xml | 13 ++-- .../combined_DarkWallet-Best-Practices.xml | 13 ++-- ...-server-for-bitcoin-org-your-thoughts-.xml | 13 ++-- ...ombined_Dual-elliptic-curve-algorithms.xml | 13 ++-- .../Dec_2013/combined_Fees-UI-warning.xml | 13 ++-- ...combined_Floating-fees-and-SPV-clients.xml | 13 ++-- ...-exciting-opportunity-in-bitcoin-space.xml | 13 ++-- ...voidance-and-P2P-connection-encryption.xml | 13 ++-- .../Dec_2013/combined_Merge-mining.xml | 13 ++-- ...d_Message-Signing-based-authentication.xml | 13 ++-- ...ombined_Monetary-Authority-for-Bitcoin.xml | 13 ++-- ...tive-source-for-BIPs-to-git-repository.xml | 13 ++-- .../combined_Peer-Discovery-and-Overlay.xml | 13 ++-- ...ty-based-mining-variable-block-reward-.xml | 13 ++-- ...ction-script-process-for-forked-chains.xml | 13 ++-- ...-easy-way-to-restore-wallet-dat-backup.xml | 13 ++-- .../Dec_2013/combined_Temporary-fee-fix.xml | 13 ++-- .../combined_Testnet-block-explorer.xml | 13 ++-- .../Dec_2013/combined_bitcoin-qt.xml | 13 ++-- .../combined_ACK-NACK-utACK-Concept-ACK-.xml | 17 ++--- .../Dec_2014/combined_Area-of-Focus.xml | 13 ++-- .../combined_BIP-Voluntary-deposit-bonds.xml | 13 ++-- ...bined_BitCoin-TPB-P2P-Currency-Torrent.xml | 13 ++-- .../Dec_2014/combined_Cartographer.xml | 13 ++-- ...f-clients-in-Bitcoin-P2P-network-paper.xml | 13 ++-- ...ain-with-proof-of-burn-on-parent-chain.xml | 13 ++-- ...evelopment-processes-and-reddit-charms.xml | 13 ++-- ...d_Reading-List-for-Getting-Up-to-Speed.xml | 13 ++-- ...an-CHECKLOCKTIMEVERIFY-can-t-be-merged.xml | 13 ++-- .../combined_Serialised-P2SH-HD-chains.xml | 13 ++-- ...ecord-straight-on-Proof-of-Publication.xml | 13 ++-- ...of-Publication-and-Anti-Replay-Oracles.xml | 13 ++-- ...f-Publication-and-Anti-Replay-Oracles-.xml | 13 ++-- ...compression-of-Blocks-and-Transactions.xml | 13 ++-- ...ft-Decentralized-Improvement-Proposals.xml | 13 ++-- .../Dec_2015/combined_-Subsidy-fraud-.xml | 17 ++--- ...-format-for-segregated-witness-or-not-.xml | 13 ++-- ...mplementation-of-BIP102-as-a-softfork-.xml | 13 ++-- ...ined_BIP-9-style-version-bits-for-txns.xml | 13 ++-- .../Dec_2015/combined_BIP-numbers.xml | 13 ++-- ...conomics-user-preparation-moral-hazard.xml | 13 ++-- ...lockchain-verification-flag-BIP-draft-.xml | 13 ++-- ...city-increases-for-the-Bitcoin-system-.xml | 13 ++-- ...ant-UTXOs-without-confiscating-bitcoin.xml | 13 ++-- ...serve-the-value-of-coins-after-a-fork-.xml | 13 ++-- ...e-blocksize-as-a-generalized-softfork-.xml | 13 ++-- .../combined_On-the-security-of-softforks.xml | 13 ++-- ...d_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml | 13 ++-- .../combined_Scaling-by-Partitioning.xml | 13 ++-- .../combined_Segregated-Witness-BIPs.xml | 13 ++-- ..._Segregated-Witness-features-wish-list.xml | 13 ++-- ...ness-in-the-context-of-Scaling-Bitcoin.xml | 13 ++-- ...ption-has-very-small-block-size-effect.xml | 13 ++-- ...ed-witnesses-and-validationless-mining.xml | 13 ++-- ...pts-from-the-Scaling-Bitcoin-workshops.xml | 13 ++-- ...d-BIP-Draft-Turing-Pseudo-Completeness.xml | 13 ++-- ...-by-block-height-instead-of-block-time.xml | 13 ++-- ...oft-fork-modifying-just-SignatureHash-.xml | 13 ++-- ...ed-to-fix-the-block-withholding-attack.xml | 13 ++-- ...mplementation-of-BIP102-as-a-softfork-.xml | 13 ++-- .../Dec_2016/combined_Bitcoin-Currency.xml | 5 +- ...ental-network-with-a-new-header-format.xml | 5 +- ...same-way-we-do-difficulty-aka-Block75-.xml | 5 +- ...ultisig-with-hashes-instead-of-pubkeys.xml | 5 +- ...mbined_New-BIP-Hardfork-warning-system.xml | 5 +- .../combined_Planned-Obsolescence.xml | 5 +- ...-failures-was-Re-Planned-Obsolescence-.xml | 5 +- ...d-increasing-security-at-the-same-time.xml | 5 +- ...ndar-Review-of-Smart-Contract-Concepts.xml | 5 +- ...dar-What-s-Smart-about-Smart-Contracts.xml | 5 +- .../Dec_2021/combined_A-fee-bumping-model.xml | 5 +- ...o-conf-apps-in-immediate-danger-angus-.xml | 5 +- ...RBF-Zero-conf-apps-in-immediate-danger.xml | 5 +- ...ed_Pseudocode-for-robust-tail-emission.xml | 5 +- ...ined_bitcoin-dev-Digest-Vol-91-Issue-5.xml | 5 +- ...-listening-nodes-are-running-full-rbf-.xml | 5 +- .../combined_0-5-2-tag-in-github-.xml | 13 ++-- .../combined_Announcement-libcoin.xml | 13 ++-- ...hing-to-chat-about-today-at-21-00-UTC-.xml | 13 ++-- .../bitcoin-dev/Feb_2012/combined_BIP-13.xml | 13 ++-- ...ed_BIP-20-Rejected-process-for-BIP-21N.xml | 13 ++-- .../combined_BIP16-17-replacement.xml | 13 ++-- .../combined_BitcoinQt-eating-100-CPU.xml | 13 ++-- .../combined_Building-BDB-on-MingW.xml | 13 ++-- ...d_Duplicate-transactions-vulnerability.xml | 13 ++-- ...d_IRC-meeting-Tuesday-Feb-14-21-00-UTC.xml | 13 ++-- ...gnature-transaction-support-in-the-GUI.xml | 13 ++-- ...combined_Scaling-at-the-end-user-level.xml | 13 ++-- ...d_Version-0-6-release-candidate-1-plan.xml | 13 ++-- .../combined_getmemorypool-BIP-process.xml | 13 ++-- ...AD-now-supports-boost-1-47-please-test.xml | 13 ++-- .../combined_off-topic-bitcoin-forum-.xml | 13 ++-- .../Feb_2013/combined_0-8-0rc1-status.xml | 13 ++-- ...kchain-as-root-CA-for-payment-protocol.xml | 13 ++-- ...combined_Draft-BIP-for-Bloom-filtering.xml | 13 ++-- .../combined_Fidelity-bonded-ledgers.xml | 13 ++-- ...ks-make-delibrate-orphan-mining-costly.xml | 13 ++-- ...ned_Implementing-trading-across-chains.xml | 13 ++-- ...ule-modifications-into-the-block-chain.xml | 13 ++-- ...ined_Key-retirement-and-key-compromise.xml | 13 ++-- ...-RETURN-for-marking-unspendable-txouts.xml | 13 ++-- ...BIP-proposal-Dealing-with-malleability.xml | 13 ++-- ...ng-IBE-Re-Bait-for-reusable-addresses-.xml | 13 ++-- .../combined_BIP70-Canceling-Payments.xml | 13 ++-- ...nsion-to-allow-for-identity-delegation.xml | 13 ++-- .../combined_BIP70-proposed-changes.xml | 13 ++-- ...mbined_Base-32-error-correction-coding.xml | 13 ++-- ...splitting-blockchain-engine-and-wallet.xml | 13 ++-- ...e-with-honest-pricing-and-market-depth.xml | 13 ++-- ...ed-consensus-system-upgrade-procedures.xml | 13 ++-- ...BIP-0070-to-support-recurring-payments.xml | 13 ++-- .../Feb_2014/combined_Fee-drop.xml | 13 ++-- ...splitting-blockchain-engine-and-wallet.xml | 13 ++-- ..._Malleability-and-MtGox-s-announcement.xml | 13 ++-- .../combined_MtGox-blames-bitcoin.xml | 13 ++-- ...d_On-OP-RETURN-in-upcoming-0-9-release.xml | 13 ++-- .../combined_On-OP-RETURN-in-upcoming-0-9.xml | 13 ++-- ...ent-Protocol-for-Face-to-face-Payments.xml | 13 ++-- .../combined_Testnet-block-explorer.xml | 13 ++-- ...json-API-gettx-raw-newbie-questions-2-.xml | 13 ++-- ...2sh-bip39-and-payment-protocol-support.xml | 13 ++-- .../Feb_2014/combined_getpeerinfo-results.xml | 13 ++-- ...m-inputs-sum-outputs-newbie-questions-.xml | 13 ++-- ...oftfork-proposal-Strict-DER-signatures.xml | 13 ++-- ...-script-hash-multi-signature-addresses.xml | 13 ++-- .../Feb_2015/combined_Bitcoin-ATM.xml | 13 ++-- .../combined_Bitcoin-Core-0-10-0-released.xml | 13 ++-- ...combined_Bitcoin-Core-0-10-0rc4-tagged.xml | 13 ++-- ...Bitcoin-Core-0-9-4-not-on-bitcoin-org-.xml | 13 ++-- ...-offline-payments-implementer-feedback.xml | 13 ++-- .../combined_Export-format-for-xpub.xml | 13 ++-- ...ute-Bitcoin-can-handle-as-it-is-today-.xml | 13 ++-- ...ain-with-proof-of-burn-on-parent-chain.xml | 13 ++-- ...cise-type-information-in-API-reference.xml | 13 ++-- ...P-protocol-for-multisignature-payments.xml | 13 ++-- ...i-client-is-a-fork-past-0-10-possible-.xml | 13 ++-- ...-miner-s-signature-in-the-block-header.xml | 13 ++-- ...s-Bluetooth-LE-transfer-of-Payment-URI.xml | 13 ++-- ...ed_Proposal-to-address-Bitcoin-malware.xml | 13 ++-- ...d_Providing-Payment-Request-within-URI.xml | 13 ++-- ...cussion-Improved-HD-wallet-generation-.xml | 13 ++-- ...hybrid-PoW-PoS-enhancement-for-Bitcoin.xml | 13 ++-- ...n-one-click-purchase-at-all-merchants-.xml | 13 ++-- ...Re-Proposal-to-address-Bitcoin-malware.xml | 13 ++-- ...on-and-bitcoin-URI-Scheme-Improvements.xml | 13 ++-- ...uble-Spend-Deprecation-Window-Proposal.xml | 13 ++-- ...mbined_What-s-what-with-addr-relaying-.xml | 13 ++-- ...le-spend-Re-replace-by-fee-v0-10-0rc4-.xml | 13 ++-- .../combined_bloom-filtering-privacy.xml | 13 ++-- ...ses-using-the-least-significant-digits.xml | 13 ++-- .../combined_replace-by-fee-v0-10-0rc4.xml | 13 ++-- ...t-ambiguous-serialization-consequences.xml | 13 ++-- ...ro-value-OP-RETURN-in-Payment-Protocol.xml | 5 +- ...BIP-Proposal-New-feefilter-p2p-message.xml | 5 +- ...er-header-format-and-bigger-block-size.xml | 5 +- ...ned_BIP-CPRKV-Check-private-key-verify.xml | 5 +- .../Feb_2016/combined_BIP-Final-status.xml | 5 +- ...Status-comments-and-copyright-licenses.xml | 5 +- ...rd-fork-opt-in-mechanism-for-SPV-nodes.xml | 5 +- ...crease-block-size-limit-to-2-megabytes.xml | 5 +- ...p-some-misconceptions-about-full-nodes.xml | 5 +- ...with-a-pre-generated-UTXO-set-database.xml | 5 +- .../Feb_2016/combined_Hardfork-bit-BIP.xml | 5 +- ...tched-INVs-to-reduce-full-node-traffic.xml | 5 +- ...Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml | 5 +- ..._On-Hardforks-in-the-Context-of-SegWit.xml | 5 +- .../combined_Pre-BIP-Growth-Soft-hardfork.xml | 5 +- ...on-regarding-Confidential-Transactions.xml | 5 +- ...eterogeneous-Input-Script-Transactions.xml | 5 +- ..._SIGHASH-NOINPUT-in-Segregated-Witness.xml | 5 +- .../Feb_2016/combined_SegWit-GBT-updates.xml | 5 +- ...pgrade-Procedures-Block-Extension-Data.xml | 5 +- ...fork-fix-for-block-withholding-attacks.xml | 5 +- ...sful-Zero-Knowledge-Contingent-Payment.xml | 5 +- ...ee-Month-bitcoin-dev-Moderation-Review.xml | 5 +- .../combined_Generalized-Commitments.xml | 5 +- ...ned_Possible-change-to-the-MIT-license.xml | 5 +- ...thoughts-on-removing-timestamps-in-PoW.xml | 5 +- ...Simple-Proof-of-Reserves-Transactions-.xml | 5 +- ...hardware-wallets-and-airgapped-signers.xml | 5 +- ...oot-and-graftroot-complexity-reflowed-.xml | 5 +- ...n-Re-Taproot-and-graftroot-complexity-.xml | 5 +- .../Feb_2021/combined_Taproot-NACK.xml | 5 +- ...vation-meeting-on-lockinontimeout-LOT-.xml | 5 +- ...tralized-BIP-47-payment-code-directory.xml | 5 +- ...CKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml | 5 +- ...ntentious-soft-fork-activation-attempt.xml | 5 +- ...ECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml | 5 +- .../Feb_2022/combined_Why-CTV-why-now-.xml | 5 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 5 +- ...ed_Pseudocode-for-robust-tail-emission.xml | 5 +- ...mbined_Purely-off-chain-coin-colouring.xml | 5 +- ...ombined_All-pre-BIP-BIPs-are-not-valid.xml | 13 ++-- .../combined_Alternative-to-OP-EVAL.xml | 13 ++-- .../Jan_2012/combined_BIP-0020-URI-Scheme.xml | 13 ++-- .../Jan_2012/combined_BIP-12-16-17.xml | 13 ++-- ...ed_BIP-20-Rejected-process-for-BIP-21N.xml | 13 ++-- .../combined_BIP-21-modification-BIP-20-.xml | 13 ++-- .../Jan_2012/combined_BIP-Submission.xml | 13 ++-- .../combined_BIP16-17-replacement.xml | 13 ++-- ...CAddrMan-Stochastic-IP-address-manager.xml | 13 ++-- .../Jan_2012/combined_ECC-Signature-Issue.xml | 13 ++-- .../bitcoin-dev/Jan_2012/combined_Fuzzer-.xml | 13 ++-- .../Jan_2012/combined_Fw-Quote-on-BIP-16.xml | 13 ++-- .../Jan_2012/combined_GetBlocksToMaturity.xml | 13 ++-- ...ing-21-00-UTC-bitcoin-dev-Freenode-IRC.xml | 13 ++-- .../combined_Pull-748-pay-to-script-hash.xml | 13 ++-- .../Jan_2012/combined_Quote-on-BIP-16.xml | 13 ++-- ...ombined_bitcoin-org-SOPA-PIPA-blackout.xml | 13 ++-- ...ees-reduce-initial-download-bandwidth-.xml | 17 ++--- .../Jan_2012/combined_some-feedbacks.xml | 13 ++-- .../combined_BitCoin-and-MinorFs-AppArmor.xml | 13 ++-- ...combined_Draft-BIP-for-Bloom-filtering.xml | 13 ++-- ...e-key-for-testnet-genesis-block-public.xml | 13 ++-- .../Jan_2013/combined_Testnet-DNS-seed.xml | 13 ++-- ...ng-IBE-Re-Bait-for-reusable-addresses-.xml | 13 ++-- ...An-idea-for-alternative-payment-scheme.xml | 13 ++-- ...IP-proposal-Authenticated-prefix-trees.xml | 13 ++-- ...NA-for-bitcoin-cryptocoin-port-numbers.xml | 13 ++-- .../Jan_2014/combined_BIP0039-Final-call.xml | 13 ++-- .../Jan_2014/combined_BIP70-71-issue-RFD.xml | 13 ++-- .../combined_BIP70-PaymentACK-semantics.xml | 13 ++-- ...ned_BIP70-message-delivery-reliability.xml | 13 ++-- .../combined_Bait-for-reusable-addresses.xml | 13 ++-- ...d_Bitcoin-Core-0-9rc1-release-schedule.xml | 13 ++-- ...-with-hash-only-blocks-to-improve-tps-.xml | 13 ++-- ...-server-for-bitcoin-org-your-thoughts-.xml | 13 ++-- ...with-linking-payment-requests-via-href.xml | 13 ++-- ...BIP-0070-to-support-recurring-payments.xml | 13 ++-- ...ock-chain-in-an-untrusted-environment-.xml | 13 ++-- .../Jan_2014/combined_Happy-new-year-.xml | 13 ++-- ...-exciting-opportunity-in-bitcoin-space.xml | 13 ++-- .../Jan_2014/combined_Merge-mining.xml | 13 ++-- ...ent-Protocol-for-Face-to-face-Payments.xml | 13 ++-- ...protocol-and-reliable-Payment-messages.xml | 13 ++-- .../combined_Privacy-and-blockchain-data.xml | 13 ++-- .../Jan_2014/combined_Stealth-Addresses.xml | 13 ++-- ...-Payments-Sample-Code-Proof-of-Concept.xml | 13 ++-- ...onal-fee-for-transactions-without-fees.xml | 13 ++-- ...ombined_The-insecurity-of-merge-mining.xml | 13 ++-- .../bitcoin-dev/Jan_2014/combined_Tor-SPV.xml | 13 ++-- ...ress-spv-privacy-Re-Stealth-Addresses-.xml | 13 ++-- ...oftfork-proposal-Strict-DER-signatures.xml | 13 ++-- ...ombined_A-look-back-and-a-look-forward.xml | 13 ++-- .../combined_BIP-Voluntary-deposit-bonds.xml | 13 ++-- ...-Google-Protocol-Buffers-for-encoding-.xml | 13 ++-- ...ment-channels-with-CHECKLOCKTIMEVERIFY.xml | 13 ++-- ...f-clients-in-Bitcoin-P2P-network-paper.xml | 13 ++-- ...nt-Payments-using-the-Bitcoin-protocol.xml | 13 ++-- ...ute-Bitcoin-can-handle-as-it-is-today-.xml | 13 ++-- ...P-protocol-for-multisignature-payments.xml | 13 ++-- ...ompatible-causes-blockchain-rejection-.xml | 13 ++-- ...ed_Proposal-to-address-Bitcoin-malware.xml | 13 ++-- ...ined_Re-enabling-simple-tx-replacement.xml | 13 ++-- .../combined_SIGHASH-WITHINPUTVALUE.xml | 13 ++-- .../combined_Securing-wallet-on-paper.xml | 13 ++-- ...allet-software-custodial-relationships.xml | 13 ++-- ...of-Publication-and-Anti-Replay-Oracles.xml | 13 ++-- ...Bitcoin-is-and-isn-t-like-the-Internet.xml | 13 ++-- ...ic-keys-for-p2sh-multisig-transactions.xml | 13 ++-- ...ro-value-OP-RETURN-in-Payment-Protocol.xml | 5 +- ...ined_-BIP-Draft-BIP-Acceptance-Process.xml | 5 +- ...ft-Decentralized-Improvement-Proposals.xml | 5 +- ...mplementation-of-BIP102-as-a-softfork-.xml | 5 +- .../combined_BIP-Classification-Process.xml | 5 +- ...lock-nr-2016-for-hard-fork-activation-.xml | 5 +- ...e-0-12-0-release-candidate-1-available.xml | 5 +- ...city-increases-for-the-Bitcoin-system-.xml | 5 +- .../Jan_2016/combined_Fee-smoothing.xml | 5 +- ...mbined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml | 5 +- ...e-blocksize-as-a-generalized-softfork-.xml | 5 +- .../combined_Libconsensus-phase-2.xml | 5 +- ...BIP-editor-and-request-for-information.xml | 5 +- .../Jan_2016/combined_SegWit-GBT-updates.xml | 5 +- .../combined_SegWit-testnet-is-live.xml | 5 +- ...ned_Segregated-Witness-App-Development.xml | 5 +- .../combined_Segregated-Witness-BIPs.xml | 5 +- ...ed-witnesses-and-validationless-mining.xml | 5 +- ...pgrade-Procedures-Block-Extension-Data.xml | 5 +- ...ee-Month-bitcoin-dev-Moderation-Review.xml | 5 +- ...about-80-bit-collision-attacks-or-not-.xml | 5 +- ...mbined_What-is-OpenSSL-still-used-for-.xml | 5 +- .../combined_nSequence-multiple-uses.xml | 5 +- ...tion-serialization-would-it-be-useful-.xml | 5 +- ..._Anti-transaction-replay-in-a-hardfork.xml | 5 +- ...torical-and-future-projections-t-khan-.xml | 5 +- ...ombined_Bitcoin-Classic-1-2-0-released.xml | 5 +- ...ransaction-version-number-to-be-varint.xml | 5 +- ...ined_Extension-block-softfork-proposal.xml | 5 +- ...ental-network-with-a-new-header-format.xml | 5 +- .../combined_Mutli-push-op-return.xml | 5 +- .../combined_Script-Abuse-Potential-.xml | 5 +- ...ombined_Transaction-Replacement-by-Fee.xml | 5 +- .../combined_2-step-confirmation-system.xml | 5 +- ...untary-Fork-Split-Proposal-Chaofan-Li-.xml | 5 +- ...labs-secret-shared-private-key-scheme-.xml | 5 +- ...emove-word-from-BIP39-English-wordlist.xml | 5 +- ...Transaction-Merging-bip125-relaxation-.xml | 5 +- ...dlc-dev-CTV-dramatically-improves-DLCs.xml | 5 +- .../Jan_2022/combined_CTV-BIP-review.xml | 5 +- ...ntentious-soft-fork-activation-attempt.xml | 5 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 5 +- ...ed_Pseudocode-for-robust-tail-emission.xml | 5 +- ...Future-of-the-bitcoin-dev-mailing-list.xml | 5 +- .../combined_UTXO-checkpoint-transactions.xml | 5 +- .../combined_Accepting-broken-QRcodes.xml | 13 ++-- .../combined_Announcement-libcoin.xml | 13 ++-- .../combined_BIP-22-getmemorypool.xml | 13 ++-- ...ned_BIP-34-Block-v2-Height-in-Coinbase.xml | 13 ++-- .../combined_Bitcoin-Wallet-for-Android.xml | 13 ++-- .../combined_Bitcoin-script-opcode-counts.xml | 13 ++-- ...ombined_Coinbase-script-parse-failures.xml | 13 ++-- ...orms-using-Vagrant-VirtualBox-GH-1597-.xml | 13 ++-- .../combined_LevelDB-benchmarking.xml | 13 ++-- ...P-commands-for-diagnostics-SPV-clients.xml | 13 ++-- ...n-the-reference-client-ultraprune-mode.xml | 13 ++-- ...combined_Random-order-for-clients-page.xml | 13 ++-- ...Reconsidering-block-version-number-use.xml | 13 ++-- .../July_2012/combined_Scalability-issues.xml | 13 ++-- .../combined_Signing-release-binaries.xml | 13 ++-- .../combined_bitcoin-org-remove-hackathon.xml | 13 ++-- ...s-invalid-script-in-script-valid-json-.xml | 13 ++-- ...t-master-seed-with-optional-encryption.xml | 13 ++-- ...-for-private-keys-with-birth-timestamp.xml | 13 ++-- ...itcoin-list-BitMail-p2p-Email-0-1-beta.xml | 13 ++-- .../combined_Anti-DoS-for-tx-replacement.xml | 13 ++-- .../combined_BitMail-p2p-Email-0-1-beta.xml | 13 ++-- .../combined_Distributing-low-POW-headers.xml | 13 ++-- ...Endianness-was-Linux-packaging-letter-.xml | 13 ++-- .../combined_HTTP-REST-API-for-bitcoind.xml | 13 ++-- ...bined_Introducing-BitcoinKit-framework.xml | 13 ++-- .../combined_Linux-packaging-letter.xml | 13 ++-- ...ombined_Litecoin-v0-8-3-7-audit-report.xml | 13 ++-- .../combined_Opcode-whitelist-for-P2SH-.xml | 13 ++-- ...combined_Payment-Protocol-BIP-70-71-72.xml | 13 ++-- ...-default-desktop-client-on-bitcoin-org.xml | 13 ++-- ...itcoin-against-network-wide-DoS-attack.xml | 13 ++-- ...-for-slides-for-defeating-trojans-talk.xml | 17 ++--- ...ined_Reward-for-P2SH-IsStandard-patch-.xml | 13 ++-- .../July_2013/combined_SPV-bitcoind-.xml | 13 ++-- ...-was-Introducing-BitcoinKit-framework-.xml | 13 ++-- .../July_2013/combined_Tor-and-Bitcoin.xml | 13 ++-- ...-factor-wallet-with-one-time-passwords.xml | 13 ++-- ...in-only-alt-coin-with-either-or-mining.xml | 13 ++-- ...centralized-Multi-sig-and-Simulfunding.xml | 13 ++-- ...On-behalf-of-BIP-70-extension-proposal.xml | 17 ++--- .../July_2014/combined_ASIC-proof-mining.xml | 13 ++-- ...or-node-accepting-only-Bitcoin-traffic.xml | 13 ++-- ...ned_Abusive-and-broken-bitcoin-seeders.xml | 13 ++-- .../combined_Anyone-still-using-SOCKS4-.xml | 13 ++-- ...ombined_BIP-38-NFC-normalisation-issue.xml | 13 ++-- ...ombined_Bitcoin-Protocol-Specification.xml | 13 ++-- ...ed_Bitcoin-address-TTL-key-expiration-.xml | 13 ++-- ...ment-testing-where-to-get-Wallet-code-.xml | 13 ++-- .../combined_Building-BDB-on-MingW.xml | 13 ++-- .../combined_Building-from-git-on-OSX.xml | 13 ++-- .../combined_Decentralizing-ming.xml | 13 ++-- ...combined_Draft-BIP-for-geutxos-message.xml | 13 ++-- .../combined_Mining-Hashrate-Caps.xml | 13 ++-- .../combined_Pay-to-MultiScript-hash-.xml | 13 ++-- ...ent-Protocol-for-Face-to-face-Payments.xml | 13 ++-- .../combined_Policy-for-DNS-seeds.xml | 13 ++-- ...ating-test-cases-for-block-CheckBlock-.xml | 13 ++-- ..._Self-dependency-transaction-question-.xml | 13 ++-- ...bined_Signature-with-negative-integer-.xml | 13 ++-- .../combined_Small-update-to-BIP-62.xml | 13 ++-- ...edundant-tx-data-in-blocks-on-the-wire.xml | 13 ++-- .../bitcoin-dev/July_2014/combined_Time.xml | 13 ++-- ...ed_Trickle-and-transaction-propogation.xml | 13 ++-- ...nsensus-rules-changes-soft-hard-forks-.xml | 13 ++-- ...sed-Compromise-to-the-Block-Size-Limit.xml | 13 ++-- ...e-between-BIP101-and-Pieter-s-proposal.xml | 13 ++-- ...ction-of-bloated-blocks-by-full-nodes-.xml | 13 ++-- ...s-advantages-for-full-node-not-mining-.xml | 13 ++-- ...mit-solution-dynamic-block-size-limit-.xml | 13 ++-- ...-102-kick-the-can-down-the-road-to-2MB.xml | 13 ++-- .../July_2015/combined_BIP-68-Questions.xml | 13 ++-- .../combined_BIP-68-Relative-Locktime-bug.xml | 13 ++-- ...ned_BIP-Draft-Minimum-Viable-TXIn-Hash.xml | 13 ++-- .../combined_BIP-Process-and-Votes.xml | 13 ++-- ...ort-Term-Use-Addresses-for-Scalability.xml | 13 ++-- .../combined_BIP-draft-Hardfork-bit.xml | 13 ++-- .../combined_BIP-for-Proof-of-Payment.xml | 13 ++-- ...ned_BIP0074-Draft-Dynamic-Rate-Lookup-.xml | 13 ++-- .../combined_Bitcoin-Core-0-11-0-released.xml | 13 ++-- .../combined_Bitcoin-Core-and-hard-forks.xml | 13 ++-- .../combined_Bitcoin-Node-Speed-Test.xml | 13 ++-- ...d_Bitcoin-Perceptions-and-Expectations.xml | 13 ++-- ...dmap-2015-or-If-We-Do-Nothing-Analysis.xml | 17 ++--- .../July_2015/combined_Bitcoin-governance.xml | 13 ++-- ...ck-size-following-technological-growth.xml | 13 ++-- ...rs-who-relay-rejected-replacement-txs-.xml | 13 ++-- ...-nTime-vs-median-time-vs-block-nHeight.xml | 13 ++-- .../combined_Defining-a-min-spec.xml | 13 ++-- ...nsensus-bug-indirectly-solved-by-BIP66.xml | 13 ++-- ...really-need-a-mempool-for-relay-nodes-.xml | 13 ++-- ...BIP-fixed-schedule-block-size-increase.xml | 13 ++-- .../combined_Electrum-Server-Speed-Test.xml | 13 ++-- ...saction-size-to-mitigate-CVE-2013-2292.xml | 13 ++-- ...invalid-blocks-due-to-BIP66-violations.xml | 13 ++-- ...t-chains-to-test-different-block-sizes.xml | 13 ++-- ...itory-was-Bitcoin-Core-and-hard-forks-.xml | 13 ++-- .../combined_List-of-approved-pools.xml | 13 ++-- .../combined_LockUnspent-not-working-bug-.xml | 13 ++-- ...GPG-Archives-Breakage-TODO-mirrors-etc.xml | 13 ++-- ...ombined_Making-Electrum-more-anonymous.xml | 13 ++-- ...ined_Mempool-Expected-Byte-Stay-policy.xml | 17 ++--- ...ure-from-non-uniform-propagation-speed.xml | 13 ++-- ...ined_Process-for-BIP-number-allocation.xml | 13 ++-- ...d_Proposal-extend-bip70-with-OpenAlias.xml | 13 ++-- ...-Proposal-extend-bip70-with-OpenAlias-.xml | 13 ++-- ...ee-market-from-a-worried-local-trader-.xml | 13 ++-- ...fee-market-from-a-worried-local-trader.xml | 13 ++-- ...nconfirmed-transactions-with-a-bounty-.xml | 13 ++-- ...age-address-derivation-based-on-BIP-43.xml | 13 ++-- ...reveals-a-problematic-incentive-issue-.xml | 13 ++-- ...uble-spending-unconfirmed-transactions.xml | 13 ++-- ...lity-and-other-Bitcoin-inconveniences-.xml | 13 ++-- ...ability-announcements-for-Bitcoin-Core.xml | 13 ++-- ...rary-anti-spam-measure-isn-t-temporary.xml | 13 ++-- ...orary-anti-spam-measure-isn-ttemporary.xml | 13 ++-- ...ombined_Why-not-Child-Pays-For-Parent-.xml | 13 ++-- .../combined_BIP-151-use-of-HMAC-SHA512.xml | 5 +- .../July_2016/combined_BIP-151.xml | 5 +- ...combined_BIP-Number-Request-Open-Asset.xml | 5 +- .../combined_BIP-draft-HTLC-transactions.xml | 5 +- ...ombined_BIP-proposal-derived-mnemonics.xml | 5 +- ...Critical-Parts-of-Segwit-by-Peter-Todd.xml | 5 +- ...d_Holdup-on-Block-Alerts-Fraud-Proofs-.xml | 5 +- ...bined_Merkle-trees-and-mountain-ranges.xml | 5 +- ...d_Reasons-to-add-sync-flags-to-Bitcoin.xml | 5 +- ...tatus-updates-for-BIP-9-68-112-and-113.xml | 5 +- .../combined_Drivechain-RfD-Follow-Up.xml | 5 +- ..._UTXO-growth-scaling-solution-proposal.xml | 5 +- ...d_Updating-the-Scaling-Roadmap-Update-.xml | 5 +- ...ned_how-to-disable-segwit-in-my-build-.xml | 5 +- .../combined_Generalised-taproot.xml | 5 +- ...RI-scheme-with-optional-bech32-address.xml | 5 +- ...ECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml | 5 +- ...erivation-Paths-in-a-Single-Descriptor.xml | 5 +- ...community-process-to-specify-covenants.xml | 5 +- ...ngly-Tail-Emission-Is-Not-Inflationary.xml | 5 +- ...ncern-about-Inscriptions-ashneverdawn-.xml | 5 +- ...Pull-req-to-enable-Full-RBF-by-default.xml | 5 +- ...combined_0-6-x-detachdb-in-wrong-place.xml | 13 ++-- ...fter-compressed-pubkeys-hybrid-pubkeys.xml | 13 ++-- .../combined_BIP22-getmemorypool.xml | 13 ++-- .../combined_Berlin-Bitcoin-Hackathon.xml | 13 ++-- ..._Bootstrapping-full-nodes-post-pruning.xml | 13 ++-- ...Defeating-the-block-withholding-attack.xml | 13 ++-- ...orcing-inflation-rules-for-SPV-clients.xml | 13 ++-- ...ts-in-the-future-Blockchain-management.xml | 13 ++-- .../combined_LevelDB-benchmarking.xml | 13 ++-- ...eanup-on-exit-safe-coredump-backtrace-.xml | 13 ++-- .../combined_Near-term-scalability.xml | 13 ++-- ...P-commands-for-diagnostics-SPV-clients.xml | 13 ++-- ...P-command-and-response-getcmds-cmdlist.xml | 13 ++-- ...ed_RPC-and-signals-processing-priority.xml | 13 ++-- ...Raw-Transaction-RPC-calls-for-bitcoind.xml | 13 ++-- ..._SatoshiDice-and-Near-term-scalability.xml | 13 ++-- ...stion-for-Simplifying-development-work.xml | 13 ++-- .../combined_Tor-hidden-service-support.xml | 13 ++-- ...ain-Compression-w-trust-free-lite-node.xml | 13 ++-- ...in-Compression-w-trust-free-lite-nodes.xml | 13 ++-- .../combined_Wallet-related-bug-.xml | 13 ++-- ...oin-Qt-bitcoind-version-0-8-3-released.xml | 13 ++-- ...mbined_Bitcoin-addresses-opaque-or-not.xml | 13 ++-- ...ombined_Blockchain-alternative-storage.xml | 13 ++-- .../June_2013/combined_CTxIn-nSequence.xml | 13 ++-- .../combined_Decentralizing-mining.xml | 13 ++-- ...n-Bitcoin-due-to-Client-versions-0-8-1.xml | 13 ++-- ...nting-batch-processing-for-blocknotify.xml | 13 ++-- ..._Missing-fRelayTxes-in-version-message.xml | 13 ++-- ...combined_Missing-fRelayTxes-in-version.xml | 13 ++-- ...nkable-address-format-Payment-Protocol.xml | 17 ++--- ...-default-desktop-client-on-bitcoin-org.xml | 13 ++-- ...ksize-limit-with-proof-of-stake-voting.xml | 13 ++-- ...end-outputs-unspendable-for-100-blocks.xml | 13 ++-- ...ty-with-known-trusted-escrow-services-.xml | 13 ++-- ...ublic-key-base58-check-address-prefix-.xml | 13 ++-- ..._address-collision-and-undependability.xml | 13 ++-- ..._is-there-a-way-to-do-bitcoin-staging-.xml | 13 ++-- ...hanging-Units-with-status-bar-control-.xml | 13 ++-- ...n-Core-version-0-9-2-has-been-released.xml | 13 ++-- ...not-be-compiled-without-assertions-NOT.xml | 17 ++--- ...s-using-replace-by-fee-and-game-theory.xml | 13 ++-- ...bout-the-small-number-of-bitcoin-nodes.xml | 13 ++-- ...d_Another-uninitialized-memory-problem.xml | 13 ++-- .../combined_Anyone-still-using-SOCKS4-.xml | 13 ++-- ...ned_BIP38-Encrypted-Address-Discussion.xml | 13 ++-- ...sage-another-Proposed-BIP-70-extension.xml | 13 ++-- ...0-9-2-release-candidate-1-is-available.xml | 13 ++-- ...ombined_Bitcoin-Protocol-Specification.xml | 13 ++-- ...-miner-heads-up-getwork-RPC-going-away.xml | 17 ++--- ...ning-pools-AND-reduce-payoff-variance-.xml | 13 ++-- .../June_2014/combined_Bloom-bait.xml | 13 ++-- ...combined_CoinJoin-bounty-fund-question.xml | 13 ++-- .../June_2014/combined_DNS-seeds-unstable.xml | 13 ++-- ...alized-instant-confirmation-guarantees.xml | 13 ++-- ...mbined_Future-Feature-Proposal-getgist.xml | 13 ++-- .../combined_Going-to-tag-0-9-2-final.xml | 13 ++-- ...ncentivizing-the-running-of-full-nodes.xml | 13 ++-- ...at-to-do-if-SHA256d-is-actually-broken.xml | 13 ++-- .../combined_NODE-BLOOM-service-bit.xml | 13 ++-- ...bined_PSA-Please-sign-your-git-commits.xml | 13 ++-- ...ent-Protocol-for-Face-to-face-Payments.xml | 13 ++-- ...ned_Plans-to-separate-wallet-from-core.xml | 13 ++-- ...ttack-Keeping-unconfirmed-transactions.xml | 13 ++-- ...te-8-service-bits-for-experimental-use.xml | 13 ++-- ...IsStandard-rules-for-P2SH-transactions.xml | 13 ++-- ...roving-Bitcoin-mining-decentralization.xml | 13 ++-- .../combined_Proposed-BIP-70-extension.xml | 13 ++-- ...mbined_Wallet-nLockTime-best-practices.xml | 13 ++-- ...ards-compatible-proto-buffer-extension.xml | 13 ++-- ...seed-bitcoin-petertodd-org-is-up-again.xml | 13 ++-- ...acement-signalled-via-sequence-numbers.xml | 13 ++-- ...nsensus-rules-changes-soft-hard-forks-.xml | 13 ++-- ...ut-and-output-ordering-in-transactions.xml | 13 ++-- ...-RFC-IBLT-block-testing-implementation.xml | 13 ++-- ...sed-Compromise-to-the-Block-Size-Limit.xml | 13 ++-- ...ction-of-bloated-blocks-by-full-nodes-.xml | 13 ++-- ...ed_Address-Expiration-to-Prevent-Reuse.xml | 13 ++-- ...ate-HD-path-structure-BIP-blog-or-wat-.xml | 13 ++-- ...ull-Replace-by-Fee-deployment-schedule.xml | 13 ++-- .../combined_BIP-Process-and-Votes.xml | 13 ++-- .../combined_BIP-for-Proof-of-Payment.xml | 13 ++-- ...d_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml | 13 ++-- .../June_2015/combined_Bip-32-Question.xml | 13 ++-- ...lobally-aware-global-consensus-network.xml | 13 ++-- ...orkaround-Bitcoin-is-Like-Windows-3-11.xml | 13 ++-- ...ck-size-to-a-static-8MB-and-help-do-it.xml | 13 ++-- ...ve-Commit-Access-from-Other-Developers.xml | 13 ++-- ...ction-replacement-via-sequence-numbers.xml | 13 ++-- .../June_2015/combined_DevCore-London.xml | 13 ++-- ...BIP-fixed-schedule-block-size-increase.xml | 13 ++-- ...F2Pool-has-enabled-full-replace-by-fee.xml | 13 ++-- ...ned_FYI-Mailing-List-Move-Preparations.xml | 13 ++-- ..._Fwd-Block-Size-Increase-Requirements-.xml | 13 ++-- ...d_Fwd-Block-Size-Increase-Requirements.xml | 13 ++-- .../combined_Hard-fork-via-miner-vote.xml | 13 ++-- ...-trustworthy-enough-to-host-this-list-.xml | 13 ++-- .../June_2015/combined_Just-FYI.xml | 13 ++-- ...xing-of-Transaction-Inputs-and-Outputs.xml | 13 ++-- ...-proposals-from-FellowTraveler-Monetas.xml | 13 ++-- ...GPG-Archives-Breakage-TODO-mirrors-etc.xml | 13 ++-- ...ned_Mailman-incompatibility-with-DKIM-.xml | 13 ++-- ...Max-Block-Size-Simple-Voting-Procedure.xml | 13 ++-- ...ned_Membership-disabled-due-to-bounces.xml | 13 ++-- ...ensus-dynamic-block-size-re-targetting.xml | 13 ++-- ...suggestions-for-this-block-size-debate.xml | 13 ++-- ...itcoin-Core-node-soon-to-support-BIP66.xml | 13 ++-- ...ure-from-non-uniform-propagation-speed.xml | 13 ++-- ...am-attack-against-the-block-size-limit.xml | 13 ++-- ...pam-attack-against-the-blocksize-limit.xml | 13 ++-- ..._Ninki-Wallet-view-on-blocksize-debate.xml | 13 ++-- .../June_2015/combined_Original-Vision.xml | 13 ++-- ...rough-graceful-degradation-to-SPV-mode.xml | 13 ++-- ...Dev-List-to-a-Neutral-Competent-Entity.xml | 13 ++-- ...d_Proposal-SPV-Fee-Discovery-mechanism.xml | 13 ++-- ...alternatives-to-the-20MB-step-function.xml | 13 ++-- ...Proposed-alternatives-to-the-20MB-step.xml | 13 ++-- ...egarding-transactions-with-NLOCKTIME-0.xml | 13 ++-- ...age-address-derivation-based-on-BIP-43.xml | 13 ++-- .../June_2015/combined_Remove-Us-Please.xml | 13 ++-- .../combined_Reusable-payment-codes.xml | 13 ++-- ...ombined_Scaling-Bitcoin-with-Subchains.xml | 13 ++-- .../bitcoin-dev/June_2015/combined_Test.xml | 13 ++-- .../combined_The-Bitcoin-Node-Market.xml | 13 ++-- .../combined_The-need-for-larger-blocks.xml | 13 ++-- ...nterparty-Coinkite-Darkwallet-Viacoin-.xml | 13 ++-- ...ability-announcements-for-Bitcoin-Core.xml | 13 ++-- ...ed_User-vote-in-blocksize-through-fees.xml | 13 ++-- .../combined_Various-block-size-proposals.xml | 13 ++-- .../combined_Version-bits-proposal.xml | 13 ++-- ...ed_Welcome-to-the-new-Bitcoin-Dev-List.xml | 13 ++-- ...hy-do-we-need-a-MAX-BLOCK-SIZE-at-all-.xml | 13 ++-- ...k-size-to-a-static-8MB-and-help-do-it-.xml | 13 ++-- .../combined_comments-on-BIP-100.xml | 13 ++-- ...ve-Commit-Access-from-Other-Developers.xml | 13 ++-- ...n-XT-code-fork-non-consensus-hard-fork.xml | 13 ++-- ...-block-size-increase-extension-blocks-.xml | 13 ++-- ...k-block-size-increase-extensionblocks-.xml | 13 ++-- .../bitcoin-dev/June_2015/combined_test-2.xml | 13 ++-- .../bitcoin-dev/June_2015/combined_test-3.xml | 13 ++-- .../June_2015/combined_test-post.xml | 13 ++-- .../June_2016/combined_BIP-151-MITM.xml | 5 +- .../combined_BIP-151-use-of-HMAC-SHA512.xml | 5 +- .../June_2016/combined_BIP-151.xml | 5 +- .../combined_BIP-draft-Memo-server.xml | 5 +- ...xtension-of-witness-program-definition.xml | 5 +- ...he-State-Machine-Approach-to-Consensus.xml | 5 +- ...Critical-Parts-of-Segwit-by-Peter-Todd.xml | 5 +- ...re-proposed-BIP-extensions-to-BIP-0070.xml | 5 +- ...bined_Merkle-trees-and-mountain-ranges.xml | 5 +- ...r-P2WPKH-nested-in-P2SH-based-accounts.xml | 5 +- .../combined_Drivechain-RfD-Follow-Up.xml | 5 +- ...eer-to-peer-message-transport-protocol.xml | 5 +- ...ined_bitcoin-dev-Digest-Vol-49-Issue-8.xml | 5 +- ...CKTEMPLATEVERIFY-Fee-Bumping-Operation.xml | 5 +- ...ased-accumulators-with-quick-insertion.xml | 5 +- ...ed_Opinion-on-proof-of-stake-in-future.xml | 5 +- ...Trinary-Version-Signaling-for-softfork.xml | 5 +- .../combined_Packaged-Transaction-Relay.xml | 5 +- ...ps-does-not-linearize-its-transactions.xml | 5 +- ...ined_bitcoin-dev-Digest-Vol-85-Issue-4.xml | 5 +- ...at-layer-1-with-client-side-validation.xml | 5 +- ...combined_postr-p2n-payjoin-using-nostr.xml | 5 +- ...ension-for-Manual-Seed-Phrase-Creation.xml | 5 +- ...bined_0-7-merge-recommendations-status.xml | 13 ++-- ...ish-translation-for-vulnerability-page.xml | 13 ++-- .../combined_Adding-a-pong-message.xml | 13 ++-- ...g-callback-hooks-to-the-satoshi-client.xml | 13 ++-- .../combined_Announcement-libcoin.xml | 13 ++-- ...il-1-BIP16-switchover-time-is-definite.xml | 13 ++-- .../combined_BIP-16-changes-list-inside-.xml | 13 ++-- .../March_2012/combined_BIP-18-or-not-.xml | 13 ++-- ...d_Duplicate-transactions-vulnerability.xml | 13 ++-- ...combined_Fwd-Proposal-for-a-new-opcode.xml | 13 ++-- ...ined_JSON-RPC-is-BIP-territory-or-not-.xml | 13 ++-- .../combined_P2SH-status-update.xml | 13 ++-- .../combined_Proposal-for-a-new-opcode.xml | 13 ++-- .../combined_getmemorypool-BIP-process.xml | 13 ++-- ...CH-Change-recommended-fee-to-0-001-BTC.xml | 13 ++-- .../March_2013/combined_0-8-1-ideas.xml | 13 ++-- .../March_2013/combined_0-8-1-plan.xml | 13 ++-- ...d_A-bitcoin-UDP-P2P-protocol-extension.xml | 13 ++-- ...ed_Blocking-uneconomical-UTXO-creation.xml | 13 ++-- ...d_Blocksize-and-off-chain-transactions.xml | 13 ++-- ...g-the-fee-on-already-sent-transactions.xml | 13 ++-- ...ined_Key-retirement-and-key-compromise.xml | 13 ++-- .../combined_Large-blocks-and-censorship.xml | 13 ++-- .../March_2013/combined_Ok-to-use-0-8-x-.xml | 13 ++-- .../March_2013/combined_Secure-download.xml | 13 ++-- .../combined_Some-PR-preparation.xml | 13 ++-- ...pcoming-network-event-block-v2-lock-in.xml | 13 ++-- ...-on-large-number-of-tx-block-fork-risk.xml | 13 ++-- ...ck-verification-for-faster-UI-testing-.xml | 13 ++-- ...llet-root-key-with-optional-encryption.xml | 13 ++-- .../combined_0-9-0-release-candidate-two.xml | 13 ++-- .../March_2014/combined_0-9-0rc3-tagged.xml | 13 ++-- ...-is-there-a-way-to-do-bitcoin-staging-.xml | 13 ++-- .../combined_BIP-70-and-OP-RETURN.xml | 13 ++-- .../combined_BIP-70-refund-field.xml | 13 ++-- ...nsion-to-allow-for-identity-delegation.xml | 13 ++-- .../combined_BIP70-proposed-changes.xml | 13 ++-- ...bined_Best-practices-for-dust-remining.xml | 13 ++-- ...-for-W3C-Payments-Workshop-March-24-25.xml | 13 ++-- .../combined_Bitcoin-wiki-is-down.xml | 13 ++-- ...e-with-honest-pricing-and-market-depth.xml | 13 ++-- .../March_2014/combined_Dust-recycling.xml | 13 ++-- .../combined_Electrum-1-9-8-release.xml | 13 ++-- .../combined_External-IP-Address.xml | 13 ++-- .../combined_Fake-PGP-key-for-Gavin.xml | 13 ++-- ...itcoin-0-9-0-doesn-t-work-on-old-Linux.xml | 13 ++-- ...ems-via-double-spending-replace-by-fee.xml | 13 ++-- ...ed_Instant-contactless-payments-IsoDep.xml | 13 ++-- .../combined_Instant-contactless-payments.xml | 13 ++-- ...ing-with-ECC-addition-Oracle-protocol-.xml | 13 ++-- .../combined_Multisign-payment-protocol-.xml | 13 ++-- .../combined_New-BIP32-structure.xml | 13 ++-- ...l-attack-that-can-recover-Bitcoin-keys.xml | 13 ++-- .../March_2014/combined_New-to-this-list.xml | 13 ++-- ...ombined_Payment-Protocol-Hash-Comments.xml | 13 ++-- ...ent-Protocol-for-Face-to-face-Payments.xml | 13 ++-- ...ftware-and-PIN-to-generate-private-key.xml | 13 ++-- ...dback-on-certificate-validation-errors.xml | 13 ++-- .../combined_Post-to-list-request.xml | 13 ++-- ...Secret-Sharing-of-Bitcoin-private-keys.xml | 13 ++-- ...d_Procedure-for-non-tech-contributions.xml | 13 ++-- ...d_Process-for-getting-a-patch-aproved-.xml | 13 ++-- .../March_2014/combined_Stealth-Addresses.xml | 13 ++-- ...den-temporary-drop-in-reachable-nodes-.xml | 13 ++-- ...mbined_Tree-chains-preliminary-summary.xml | 13 ++-- ...0021-and-bip-0072-ambiguities-mistakes.xml | 13 ++-- ...ned_moving-the-default-display-to-mbtc.xml | 13 ++-- ...n2-3-interface-to-the-Bitcoin-protocol.xml | 13 ++-- ...ure-assigned-bitcoin-address-directory.xml | 13 ++-- ...ic-keys-for-p2sh-multisig-transactions.xml | 13 ++-- ...s-a-service-and-proof-of-local-storage.xml | 17 ++--- ...ed_Address-Expiration-to-Prevent-Reuse.xml | 13 ++-- ...mbined_Are-Instant-Confirmations-safe-.xml | 13 ++-- ...tandard-multi-signature-P2SH-addresses.xml | 13 ++-- .../combined_BIP32-Index-Randomisation.xml | 13 ++-- ...-Google-Protocol-Buffers-for-encoding-.xml | 13 ++-- ...-offline-payments-implementer-feedback.xml | 13 ++-- ...twork-disruption-as-a-service-startups.xml | 17 ++--- ...ned_Double-spending-and-replace-by-fee.xml | 13 ++-- .../combined_Electrum-2-0-has-been-tagged.xml | 13 ++-- ...-to-transaction-origination-harvesting.xml | 13 ++-- ...s-on-the-viability-of-the-Factom-token.xml | 13 ++-- ...enges-for-Bitcoin-and-Cryptocurrencies.xml | 13 ++-- ...i-client-is-a-fork-past-0-10-possible-.xml | 13 ++-- .../March_2015/combined_Proof-of-Payment.xml | 13 ++-- ...CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml | 13 ++-- .../March_2015/combined_Testnet3.xml | 13 ++-- .../combined_Useless-Address-attack-.xml | 13 ++-- ...combined_bip44-GPG-identities-POC-demo.xml | 13 ++-- .../combined_replace-by-fee-v0-10-0rc4.xml | 13 ++-- .../combined_BIP-2-promotion-to-Final.xml | 5 +- ...Status-comments-and-copyright-licenses.xml | 5 +- .../combined_BIP147-minor-error.xml | 5 +- ...ned_BIP75-Out-of-Band-Address-Exchange.xml | 5 +- ...ntees-Strong-not-Eventual-Consistency-.xml | 5 +- ...dfork-to-fix-difficulty-drop-algorithm.xml | 5 +- ...acy-Questionnaire-Mid-Year-2015-report.xml | 5 +- ...median-block-size-adaptive-block-size-.xml | 5 +- ...ned_Proposed-BIP-extension-to-BIP-0070.xml | 5 +- ...bined_Proposed-release-schedule-0-13-0.xml | 5 +- ...combined_Services-bit-for-xthin-blocks.xml | 5 +- ...ned_bitcoin-dev-Digest-Vol-10-Issue-13.xml | 5 +- ...onsensus-rule-change-for-TX-fee-safety.xml | 5 +- ...p2p-authentication-and-encryption-BIPs.xml | 5 +- ...fork-proposal-from-last-week-s-meeting.xml | 5 +- ...ement-for-pseudonymous-BIP-submissions.xml | 5 +- ...ed_Unique-node-identifiers-and-BIP150-.xml | 5 +- ...n-blockheader-stratum-mining-configure.xml | 5 +- ...P-Proposal-The-Great-Consensus-Cleanup.xml | 5 +- ...P-Proposal-The-Great-Consensus-Cleanup.xml | 5 +- .../March_2019/combined_Signet.xml | 5 +- .../combined_Block-solving-slowdown.xml | 5 +- ...hardware-wallets-and-airgapped-signers.xml | 5 +- ...-Datastore-for-Energy-Efficient-Mining.xml | 5 +- ...-2021-Taproot-Activation-Meeting-Notes.xml | 5 +- ...A-Taproot-loss-of-quantum-protections-.xml | 5 +- ...t-Hierarchy-for-Deterministic-Wallets-.xml | 5 +- .../March_2021/combined_Taproot-NACK.xml | 5 +- ...root-activation-proposal-Speedy-Trial-.xml | 5 +- ...vation-meeting-on-lockinontimeout-LOT-.xml | 5 +- ...tralized-BIP-47-payment-code-directory.xml | 5 +- ...CKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml | 5 +- ...Bitcoin-fungibility-and-inscribed-sats.xml | 5 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 5 +- .../March_2023/combined_Minimum-fees.xml | 5 +- ...ree-Relay-Attack-Exploiting-RBF-Rule-6.xml | 5 +- .../combined_BIP-33-Stratized-Nodes.xml | 13 ++-- ...combined_IPv6-bitcoin-support-now-live.xml | 13 ++-- ...scovery-was-Re-BIP-33-Stratized-Nodes-.xml | 13 ++-- ...t-when-individual-tx-used-as-coinbase-.xml | 13 ++-- .../combined_Punishing-empty-blocks-.xml | 13 ++-- .../combined_URI-Handling-in-Bitcoin-Qt.xml | 13 ++-- .../combined_new-bitcoin-org-clients-page.xml | 13 ++-- .../May_2013/combined_-no-subject-.xml | 13 ++-- .../May_2013/combined_0-8-2-branch.xml | 13 ++-- ...-2rc1-testnet-datadir-behavior-changed.xml | 13 ++-- ...ding-via-conflicting-transactions-easy.xml | 13 ++-- ...combined_32-vs-64-bit-timestamp-fields.xml | 13 ++-- ...by-fee-implementation-is-now-available.xml | 13 ++-- ...mbined_Automated-Weekly-Testnet-Alerts.xml | 13 ++-- .../combined_BIP-0021-idea-sendmany.xml | 13 ++-- .../bitcoin-dev/May_2013/combined_BIP0032.xml | 13 ++-- .../combined_BIP21-bitcoin-URIs-and-HTML5.xml | 13 ++-- ...de-your-PGP-fingerprint-in-your-slides.xml | 13 ++-- ...combined_Cold-Signing-Payment-Requests.xml | 13 ++-- .../combined_Decentralizing-mining.xml | 13 ++-- ...ets-was-Service-bits-for-pruned-nodes-.xml | 13 ++-- .../combined_Double-Spend-Notification.xml | 13 ++-- ...ined_Fwd-Service-bits-for-pruned-nodes.xml | 13 ++-- ...nting-batch-processing-for-blocknotify.xml | 13 ++-- .../combined_Modularizing-Bitcoin.xml | 13 ++-- ...version-packet-protocol-version-70001-.xml | 13 ++-- ...combined_Service-bits-for-pruned-nodes.xml | 13 ++-- .../combined_Tentitive-port-for-FreeBSD.xml | 13 ++-- ...chains-payment-protocol-and-elsewhere-.xml | 13 ++-- ...to-support-secp256r1-but-not-secp256k1.xml | 13 ++-- ...evocability-Re-ecash-and-revocability-.xml | 13 ++-- ...bitcoin-taint-unilateral-revocability-.xml | 13 ++-- ..._is-there-a-way-to-do-bitcoin-staging-.xml | 13 ++-- ...-netsplits-was-Discovery-addr-packets-.xml | 13 ++-- ...sh-bitcoin-Re-Coinbase-TxOut-Hashcash-.xml | 13 ++-- ...-qt-gripes-moving-BTC-off-specific-key.xml | 13 ++-- ...hanging-Units-with-status-bar-control-.xml | 13 ++-- .../combined_-bits-Unit-of-account.xml | 17 ++--- .../May_2014/combined_-no-subject-.xml | 13 ++-- ...-for-reducing-0-conf-double-spend-risk.xml | 13 ++-- ...bout-the-small-number-of-bitcoin-nodes.xml | 13 ++-- ...ross-site-requests-of-payment-requests.xml | 13 ++-- .../combined_Announcing-the-Statoshi-fork.xml | 13 ++-- ...combined_BIP70-implementation-guidance.xml | 13 ++-- .../combined_BIP70-proposed-changes.xml | 13 ++-- ...n-Cooperative-Proof-of-Stake-whitpaper.xml | 13 ++-- .../combined_Bitcoin-Core-Nightly-Builds.xml | 13 ++-- .../combined_Bitcoin-Fee-Formula-Proposal.xml | 13 ++-- ...ombined_Bitcoin-Protocol-Specification.xml | 13 ++-- ...ind-in-background-mode-for-SPV-wallets.xml | 13 ++-- ...otocol-and-Bonneau-s-Kickbacks-problem.xml | 13 ++-- .../May_2014/combined_Bug-in-key-cpp.xml | 13 ++-- ...ombined_Bug-with-handing-of-OP-RETURN-.xml | 13 ++-- ...ed_Compatibility-Bitcoin-Qt-with-Tails.xml | 13 ++-- ...ined_Cut-through-propagation-of-blocks.xml | 13 ++-- .../May_2014/combined_DNS-seeds-unstable.xml | 13 ++-- ...Developer-documentation-on-bitcoin-org.xml | 13 ++-- .../combined_ECDH-in-the-payment-protocol.xml | 13 ++-- ...bined_PSA-Please-sign-your-git-commits.xml | 13 ++-- .../May_2014/combined_Paper-Currency.xml | 13 ++-- .../combined_Prenumbered-BIP-naming.xml | 13 ++-- ...Secret-Sharing-of-Bitcoin-private-keys.xml | 13 ++-- ...oposal-for-extra-nonce-in-block-header.xml | 13 ++-- ...egtest-Address-Version-Change-Proposal.xml | 13 ++-- ...-a-virus-signature-into-the-blockchain.xml | 13 ++-- ...ed_Translators-Needed-for-Bitcoin-Core.xml | 13 ++-- .../combined_Why-are-we-bleeding-nodes-.xml | 13 ++-- ...n-social-contracts-was-Paper-Currency-.xml | 13 ++-- ...d-minor-bug-in-wallet-and-possible-fix.xml | 13 ++-- ...ned_moving-the-default-display-to-mbtc.xml | 13 ++-- .../May_2014/combined_patents-.xml | 13 ++-- .../combined_statoshi-info-is-now-live.xml | 13 ++-- ...seed-bitcoin-petertodd-org-is-up-again.xml | 13 ++-- .../combined_we-can-all-relax-now.xml | 13 ++-- ...arket-Trustless-Federated-Marketplaces.xml | 13 ++-- ...mbined_-BIP-Normalized-Transaction-IDs.xml | 13 ++-- ...e-Fwd-Block-Size-Increase-Requirements.xml | 13 ++-- ...reducing-the-size-of-the-UTXO-database.xml | 13 ++-- ...-even-without-a-block-size-limit-2013-.xml | 13 ++-- ...he-network-with-OP-CHECKLOCKTIMEVERIFY.xml | 13 ++-- ...-script-hash-multi-signature-addresses.xml | 13 ++-- ...e-0-10-1-release-candidate-2-available.xml | 13 ++-- .../combined_Bitcoin-Core-0-10-2-released.xml | 13 ++-- .../combined_Bitcoin-Survey-Paper.xml | 13 ++-- .../combined_Bitcoin-core-0-11-planning.xml | 13 ++-- ...oin-development-Digest-Vol-48-Issue-41.xml | 13 ++-- .../May_2015/combined_Bitcoin-transaction.xml | 13 ++-- ...bined_Block-Size-Increase-Requirements.xml | 13 ++-- .../May_2015/combined_Block-Size-Increase.xml | 13 ++-- ...LTV-opcode-allocation-long-term-plans-.xml | 13 ++-- .../May_2015/combined_ChainDB-Whitepaper.xml | 13 ++-- ...ction-replacement-via-sequence-numbers.xml | 13 ++-- ...savings-by-using-replace-by-fee-30-90-.xml | 13 ++-- ...ombined_First-Seen-Safe-Replace-by-Fee.xml | 13 ++-- ...d_Fwd-Block-Size-Increase-Requirements.xml | 13 ++-- .../combined_Long-term-mining-incentives.xml | 13 ++-- ...Max-Block-Size-Simple-Voting-Procedure.xml | 13 ++-- .../combined_Mechanics-of-a-hard-fork.xml | 13 ++-- ...eplace-by-fee-for-Bitcoin-Core-v0-10-1.xml | 13 ++-- .../May_2015/combined_No-Bitcoin-For-You.xml | 13 ++-- ...oin-Privacy-Project-Spring-2015-Report.xml | 13 ++-- ...measured-response-to-save-Bitcoin-Core.xml | 13 ++-- ...ed-additional-options-for-pruned-nodes.xml | 13 ++-- ...alternatives-to-the-20MB-step-function.xml | 13 ++-- ...-alternatives-to-the-20MB-stepfunction.xml | 13 ++-- ...d-of-increasing-the-maximum-block-size.xml | 13 ++-- ...CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml | 13 ++-- ..._Removing-transaction-data-from-blocks.xml | 13 ++-- ...ombined_Scaling-Bitcoin-with-Subchains.xml | 13 ++-- ...bined_Solution-for-Block-Size-Increase.xml | 13 ++-- .../combined_Version-bits-proposal.xml | 13 ++-- .../May_2015/combined_Virtual-Notary-.xml | 13 ++-- ...ined_Zero-Conf-for-Full-Node-Discovery.xml | 13 ++-- ...-alternatives-to-the-20MB-stepfunction.xml | 13 ++-- ...combined_BIP-Number-Request-Open-Asset.xml | 5 +- .../May_2016/combined_BIP-OP-PRANDOM.xml | 5 +- ...mbined_Bip44-extension-for-P2SH-P2WSH-.xml | 5 +- .../combined_Compact-Block-Relay-BIP.xml | 5 +- .../combined_Making-AsicBoost-irrelevant.xml | 5 +- ...th-Low-Latency-Delayed-TXO-Commitments.xml | 5 +- .../combined_Proposal-to-update-BIP-32.xml | 5 +- ...eterogeneous-Input-Script-Transactions.xml | 5 +- ...p2p-authentication-and-encryption-BIPs.xml | 5 +- ...and-multi-sender-coinjoin-transactions.xml | 5 +- ...ension-block-proposal-by-Jeffrey-et-al.xml | 5 +- ...mbined_Non-confirming-block-signalling.xml | 5 +- ...discuss-Checkpoints-in-the-Blockchain-.xml | 5 +- ...-bets-without-an-oracle-and-3rd-party-.xml | 5 +- ...sus-protocol-immutability-is-a-feature.xml | 5 +- .../combined_Fee-estimates-and-RBF.xml | 5 +- ...ed_Opinion-on-proof-of-stake-in-future.xml | 5 +- ...-9-minutes-to-save-90-of-mining-energy.xml | 5 +- ...ed_maximum-block-height-on-transaction.xml | 5 +- ...us-soft-fork-activations-are-attempted.xml | 5 +- ...-Taproot-transactions-from-full-nodes-.xml | 5 +- .../May_2023/combined_tx-max-fee.xml | 5 +- ...ension-for-Manual-Seed-Phrase-Creation.xml | 5 +- ...oin-C-based-bitcoin-library-and-client.xml | 13 ++-- ...combined_Draft-BIP-for-Bloom-filtering.xml | 13 ++-- ...bined_Electrum-security-model-concerns.xml | 13 ++-- ..._Has-anyone-compiled-under-MacOS-10-8-.xml | 13 ++-- ..._IRC-meeting-agenda-18-00-UTC-Thursday.xml | 13 ++-- ...ol-Proposal-Invoices-Payments-Receipts.xml | 13 ++-- ..._-ANN-High-speed-Bitcoin-Relay-Network.xml | 13 ++-- ...odes-to-prevent-them-from-being-banned.xml | 13 ++-- ...tcoind-whitelist-nodes-against-banning.xml | 13 ++-- ...t-master-seed-with-optional-encryption.xml | 13 ++-- ...ck-size-and-why-transaction-fees-are-8.xml | 13 ++-- ...combined_Auto-generated-miner-backbone.xml | 13 ++-- .../bitcoin-dev/Nov_2013/combined_BIP-38.xml | 13 ++-- ...tch-to-raise-selfish-mining-threshold-.xml | 13 ++-- .../Nov_2013/combined_BIP39-word-list.xml | 13 ++-- .../combined_Bitcoin-Network-Simulator.xml | 13 ++-- ...lock-data-a-better-merge-mine-standard.xml | 13 ++-- ...a-f-bounty-fork-rate-average-blocksize.xml | 13 ++-- ...nding-the-Payment-Protocol-with-vCards.xml | 13 ++-- ...d_Message-Signing-based-authentication.xml | 13 ++-- .../combined_Network-propagation-speeds.xml | 13 ++-- ...o-low-or-transactions-8-times-too-big-.xml | 13 ++-- ...ombined_Possible-Solution-To-SM-Attack.xml | 13 ++-- .../combined_Proposal-to-replace-BIP0039.xml | 13 ++-- ...Revisiting-the-BIPS-process-a-proposal.xml | 13 ++-- .../combined_Testnet-under-attack-.xml | 13 ++-- ...t-is-Satoshi-0-8-99-Gangnam-Style-2-1-.xml | 13 ++-- ...f-safe-tx-replacement-replace-for-fee-.xml | 13 ++-- static/bitcoin-dev/Nov_2013/combined_idea.xml | 13 ++-- ..._is-there-a-way-to-do-bitcoin-staging-.xml | 13 ++-- ...ned_moving-the-default-display-to-mbtc.xml | 13 ++-- .../combined_we-can-all-relax-now.xml | 13 ++-- ...65-and-OP-CHECKLOCKTIMEVERIFY-inquiry-.xml | 13 ++-- ...ined_BIP-draft-Auxiliary-Header-Format.xml | 13 ++-- ...bined_BIP62-and-future-script-upgrades.xml | 13 ++-- .../Nov_2014/combined_Bug-in-genbuild-sh-.xml | 13 ++-- .../combined_DS-Deprecation-Window.xml | 13 ++-- ...f-clients-in-Bitcoin-P2P-network-paper.xml | 13 ++-- ...ing-the-OP-RETURN-maximum-payload-size.xml | 13 ++-- ...ses-was-Outbound-connections-rotation-.xml | 13 ++-- .../Nov_2014/combined_Running-a-full-node.xml | 13 ++-- ...RIPT-VERIFY-STRICTENC-and-CHECKSIG-NOT.xml | 13 ++-- ...s-critical-code-the-SIGHASH-SINGLE-bug.xml | 13 ++-- ...ined_Update-on-mobile-2-factor-wallets.xml | 13 ++-- .../combined_bitcoind-as-a-library.xml | 13 ++-- ...-is-there-a-way-to-do-bitcoin-staging-.xml | 13 ++-- ...compression-of-Blocks-and-Transactions.xml | 13 ++-- ...mbined_-BIP-Normalized-transaction-IDs.xml | 13 ++-- .../combined_-BIP-OP-CHECKPRIVPUBPAIR.xml | 13 ++-- ...ch-Switching-Bitcoin-Core-to-sqlite-db.xml | 13 ++-- ...aggregate-limits-and-fee-determination.xml | 13 ++-- .../combined_Ads-on-bitcoin-org-website.xml | 13 ++-- ...e-name-for-CHECKSEQUENCEVERIFY-BIP112-.xml | 13 ++-- ...ncing-Jonas-Schnelli-as-GUI-maintainer.xml | 13 ++-- ...ime-past-is-a-HARDfork-not-a-softfork-.xml | 13 ++-- ...ard-halving-with-max-block-size-of-32M.xml | 13 ++-- .../combined_BIP-proposal-Max-block-size.xml | 13 ++-- ...d-level-granularity-doesn-t-make-sense.xml | 13 ++-- .../combined_Bitcoin-Core-0-11-2-released.xml | 13 ++-- .../combined_Bitcoin-NG-whitepaper-.xml | 13 ++-- ...roposals-for-Scaling-Bitcoin-Hong-Kong.xml | 13 ++-- ...ty-requirements-for-hard-or-soft-forks.xml | 13 ++-- .../combined_Contradiction-in-BIP65-text-.xml | 13 ++-- ...g-with-OP-IF-and-OP-NOTIF-malleability.xml | 13 ++-- ...c-Hierarchical-Deterministic-Key-Trees.xml | 13 ++-- ...luate-block-size-increase-suggestions-.xml | 13 ++-- ...ard-Inputs-or-Coalescing-Transactions-.xml | 17 ++--- ...d_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml | 13 ++-- ...-URI-scheme-for-Blockchain-exploration.xml | 13 ++-- ...ping-up-with-bitcoin-core-engineering-.xml | 13 ++-- ...sstream-Compression-of-Blocks-and-Tx-s.xml | 13 ++-- ..._Upcoming-Transaction-Priority-Changes.xml | 13 ++-- ...PFP-as-consensus-critical-for-Full-RBF.xml | 13 ++-- ...stream-Compression-of-Blocks-and-Tx-s-.xml | 17 ++--- ...or-Support-for-Datastream-Compression-.xml | 17 ++--- ...uest-to-use-service-bit-28-for-testing.xml | 13 ++-- ...-security-assumptions-re-cost-metrics-.xml | 13 ++-- ...bined_-BIP-Proposal-Buried-Deployments.xml | 5 +- ...n-arbitrary-and-or-combination-of-keys.xml | 5 +- ...as-Re-BIP-Proposal-Buried-Deployments-.xml | 5 +- .../combined_Flexible-Transactions-.xml | 5 +- ...enants-with-OP-CHECKSIGFROMSTACKVERIFY.xml | 5 +- ...Unlimited-Node-Deals-With-Large-Blocks.xml | 5 +- .../combined_Simplicity-proposal-Jets-.xml | 5 +- ...LIP-0039-better-multi-language-support.xml | 5 +- ...y-full-node-implementation-Any-advice-.xml | 5 +- .../Nov_2021/combined_A-fee-bumping-model.xml | 5 +- ...-publish-unconfirmed-transactions-How-.xml | 5 +- ...ned_bitcoinj-fork-with-Taproot-support.xml | 5 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 5 +- ...combined_On-mempool-policy-consistency.xml | 5 +- ...-BIP-125-Rule-3-Pinning-with-nLockTime.xml | 5 +- ...-Taproot-transactions-from-full-nodes-.xml | 5 +- ...Future-of-the-bitcoin-dev-mailing-list.xml | 5 +- ...-by-Letting-Transactions-Expire-Safely.xml | 5 +- ...mbined_Purely-off-chain-coin-colouring.xml | 5 +- ...ed_bitcoin-dev-Digest-Vol-102-Issue-15.xml | 5 +- ...tion-and-misaligned-incentive-concerns.xml | 5 +- ...-release-candidate-1-ready-for-testing.xml | 13 ++-- .../Oct_2012/combined_0-7-1-release.xml | 13 ++-- .../combined_Bitcoin-Testing-Project.xml | 13 ++-- ...combined_Draft-BIP-for-Bloom-filtering.xml | 13 ++-- ...bined_Electrum-security-model-concerns.xml | 13 ++-- ...ombined_Fwd-Re-Bitcoin-Testing-Project.xml | 13 ++-- ...ned_Hosting-of-compiled-bitcoin-client.xml | 13 ++-- .../Oct_2012/combined_On-bitcoin-testing.xml | 13 ++-- .../combined_Payment-protocol-thoughts.xml | 13 ++-- ..._Post-0-7-1-tree-freeze-for-ultraprune.xml | 13 ++-- ..._Public-key-and-signature-malleability.xml | 13 ++-- ...combined_Ultraprune-merged-in-mainline.xml | 13 ++-- ...mbined_performance-testing-for-bitcoin.xml | 13 ++-- ...s-actually-really-simple-and-readable-.xml | 17 ++--- .../combined_0-8-5-with-libsecp256k1.xml | 13 ++-- ...tique-of-bitcoin-open-source-community.xml | 13 ++-- ...ibrary-Bitcoin-SCI-weak-key-generation.xml | 13 ++-- ...store-and-non-network-transaction-fees.xml | 17 ++--- .../bitcoin-dev/Oct_2013/combined_BIP-38.xml | 13 ++-- ...code-for-generating-deterministic-keys.xml | 13 ++-- .../Oct_2013/combined_BIP39-word-list.xml | 13 ++-- ...mbined_Bitcoin-meets-the-Semantic-Web-.xml | 13 ++-- .../Oct_2013/combined_Code-review.xml | 13 ++-- ..._Feedback-requested-reject-p2p-message.xml | 17 ++--- ...combined_Identity-protocol-observation.xml | 13 ++-- .../combined_Making-fee-estimation-better.xml | 13 ++-- ...bined_Payment-protocol-for-onion-URLs-.xml | 13 ++-- .../combined_Proposal-to-replace-BIP0039.xml | 13 ++-- ...Revisiting-the-BIPS-process-a-proposal.xml | 13 ++-- .../combined_bitcoind-stops-responding.xml | 13 ++-- ...contracts-possible-use-case-yes-or-no-.xml | 13 ++-- ..._is-there-a-way-to-do-bitcoin-staging-.xml | 13 ++-- ...und-vs-fix-Re-0-8-5-with-libsecp256k1-.xml | 13 ++-- .../Oct_2013/combined_on-CDB-Rewrite-.xml | 13 ++-- ...m-being-spent-until-an-expiration-time.xml | 13 ++-- .../combined_About-watch-only-addresses.xml | 13 ++-- .../Oct_2014/combined_BIP-process.xml | 13 ++-- ...ned_Bitcoin-Core-0-10-release-schedule.xml | 13 ++-- .../combined_DS-Deprecation-Window.xml | 13 ++-- ...Death-by-halving-pro-active-proposals-.xml | 13 ++-- ...ined_Decreasing-block-propagation-time.xml | 13 ++-- ...Named-Curve-Registry-adding-secp256k1-.xml | 13 ++-- .../combined_Fwd-death-by-halving.xml | 13 ++-- ..._Increasing-regularity-of-block-times-.xml | 13 ++-- .../Oct_2014/combined_Malleable-booleans.xml | 13 ++-- ...oposal-for-extra-nonce-in-block-header.xml | 13 ++-- .../combined_Proposed-BIP-status-changes.xml | 13 ++-- ...-first-synchronization-in-Bitcoin-Core.xml | 13 ++-- ...-policy-estimation-code-fee-estimates-.xml | 13 ++-- ...ut-the-Gentoo-Luke-jr-censorship-issue.xml | 13 ++-- ...in-Freeze-on-Transaction-Attack-FRONT-.xml | 13 ++-- ...on-and-bitcoin-URI-Scheme-Improvements.xml | 13 ++-- .../Oct_2014/combined_bitcoinj-0-12.xml | 13 ++-- ...ombined_cryptographic-review-requested.xml | 13 ++-- .../Oct_2014/combined_death-by-halving.xml | 13 ++-- ...-is-there-a-way-to-do-bitcoin-staging-.xml | 13 ++-- ...mbined_-BIP-Normalized-transaction-IDs.xml | 13 ++-- .../Oct_2015/combined_-no-subject-.xml | 13 ++-- ...ch-Switching-Bitcoin-Core-to-sqlite-db.xml | 13 ++-- ...e-0-11-1-release-candidate-2-available.xml | 13 ++-- ...d_Bitcoin-Core-0-12-0-release-schedule.xml | 13 ++-- .../combined_Bitcoin-NG-whitepaper-.xml | 13 ++-- ...-multiple-addresses-without-using-URLs.xml | 13 ++-- ...ed_Bitcoin-network-simulation-testing-.xml | 13 ++-- ...d-more-usecases-to-motivate-the-change.xml | 13 ++-- ...ty-requirements-for-hard-or-soft-forks.xml | 13 ++-- ...-fees-and-bitcoin-days-into-one-number.xml | 13 ++-- ...et-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml | 13 ++-- .../Oct_2015/combined_Design-Competition.xml | 13 ++-- ...potentially-altering-the-PoW-algorithm.xml | 13 ++-- ...d-Bitcoin-Core-0-12-0-release-schedule.xml | 13 ++-- .../combined_Incentives-to-run-full-nodes.xml | 13 ++-- ...et-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml | 13 ++-- ...ghtning-Network-s-effect-on-miner-fees.xml | 13 ++-- .../bitcoin-dev/Oct_2015/combined_Liquid.xml | 13 ++-- ...ed_Mailing-List-Moderation-Now-Active-.xml | 13 ++-- .../Oct_2015/combined_Memory-leaks-.xml | 13 ++-- ...arn-who-coined-the-term-SPV-is-Satoshi.xml | 13 ++-- ...ture-for-P2SH-multisig-wallets-BIP-45-.xml | 13 ++-- ...sed-list-moderation-policy-and-conduct.xml | 13 ++-- ...pend-on-other-unconfirmed-transactions.xml | 13 ++-- .../combined_Public-Debate-Challenge.xml | 13 ++-- .../combined_Reusable-payment-codes.xml | 13 ++-- ...ned_The-new-obfuscation-patch-GetStats.xml | 13 ++-- ...ut-the-soft-hard-fork-technical-debate.xml | 13 ++-- ...nbits-BIP-009-minor-revision-proposal-.xml | 13 ++-- ...hy-not-checkpointing-the-transactions-.xml | 13 ++-- ...et-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml | 13 ++-- .../combined_merged-multisig-inputs.xml | 13 ++-- .../Oct_2015/combined_on-rough-consensus.xml | 13 ++-- .../Oct_2016/combined_-no-subject-.xml | 5 +- ...d_1-Year-bitcoin-dev-Moderation-Review.xml | 5 +- .../Oct_2016/combined_About-ASICBoost.xml | 5 +- .../combined_BIP-2-revival-and-rework.xml | 5 +- ...mbined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml | 5 +- ...of-Blockchains-and-facilitate-scaling-.xml | 5 +- ...-unfounded-confidence-to-Bitcoin-users.xml | 5 +- ..._Defensive-Patent-License-Offer-Notice.xml | 5 +- ...rivechain-proposal-using-OP-COUNT-ACKS.xml | 5 +- ...n-going-work-Coin-Selection-Simulation.xml | 5 +- ...combined_Start-time-for-BIP141-segwit-.xml | 5 +- .../combined_The-Soft-Fork-Deception.xml | 5 +- ...or-paying-for-a-common-good-for-miners.xml | 5 +- ...ned_bitcoin-dev-Digest-Vol-29-Issue-21.xml | 5 +- ...ned_bitcoin-dev-Digest-Vol-29-Issue-24.xml | 5 +- .../Oct_2018/combined_Generalised-taproot.xml | 5 +- ..._Block-Batch-Filters-for-Light-Clients.xml | 5 +- ...he-discussion-about-noinput-anyprevout.xml | 5 +- ...d-multi-transaction-CoinSwap-appendium.xml | 5 +- ...ned_Progress-on-Miner-Withholding-FPNC.xml | 5 +- ...BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml | 5 +- .../combined_Taproot-testnet-wallet.xml | 5 +- ...Wednesday-s-second-BIP-process-meeting.xml | 5 +- ...or-a-rational-one-re-rbf-Jeremy-Rubin-.xml | 5 +- ...ckage-RBF-againstpackage-limit-pinning.xml | 5 +- ...community-process-to-specify-covenants.xml | 5 +- ...combined_On-mempool-policy-consistency.xml | 5 +- .../combined_Packaged-Transaction-Relay.xml | 5 +- ...rver-Outsourcing-handing-out-addresses.xml | 5 +- ...-by-Letting-Transactions-Expire-Safely.xml | 5 +- .../combined_Proposed-BIP-for-OP-CAT.xml | 5 +- ...hannel-reserve-for-mobile-wallet-users.xml | 5 +- .../combined_Announcement-libcoin.xml | 13 ++-- .../combined_Atomic-coin-swapping-.xml | 13 ++-- .../combined_Bitcoin-Testing-Project.xml | 13 ++-- ...e-backlog-of-transactions-building-up-.xml | 13 ++-- ...ed_Segmented-Block-Relaying-BIP-draft-.xml | 13 ++-- ...-blockchain-db-and-wallet-to-two-dirs-.xml | 13 ++-- ...store-and-non-network-transaction-fees.xml | 17 ++--- ...code-for-generating-deterministic-keys.xml | 13 ++-- .../combined_Blockchain-archival.xml | 13 ++-- ...combined_Faster-databases-than-LevelDB.xml | 13 ++-- .../bitcoin-dev/Sept_2013/combined_GB-V04.xml | 13 ++-- ...riate-XDG-menu-category-for-bitcoin-qt.xml | 13 ++-- .../combined_New-Output-Script-Type.xml | 13 ++-- ...combined_Payment-Protocol-BIP-70-71-72.xml | 13 ++-- ...Social-network-integration-brainstorm-.xml | 13 ++-- ...Social-network-integration-brainstorm-.xml | 13 ++-- ...rors-on-start-from-Bitcoin-qt-Bitcoind.xml | 13 ++-- .../combined_bitcoind-stops-responding.xml | 13 ++-- ...contracts-possible-use-case-yes-or-no-.xml | 13 ++-- .../Sept_2013/combined_the-XBT.xml | 13 ++-- ...n-Bitcoin-Core-0-9-3-has-been-released.xml | 13 ++-- ...urpose-code-for-voting-pool-HD-wallets.xml | 13 ++-- .../combined_BIP72-amendment-proposal.xml | 13 ++-- ...coin-development-Digest-Vol-40-Issue-9.xml | 13 ++-- ...ng-at-all-signed-by-Satoshi-s-PGP-key-.xml | 13 ++-- ...e-coinbase-transaction-id-Why-is-that-.xml | 13 ++-- ...sStandard-rules-for-P2SH-transactions-.xml | 13 ++-- ...ol-Proposal-Invoices-Payments-Receipts.xml | 13 ++-- ...lision-mode-for-Multisig-BIP32-Wallets.xml | 17 ++--- ...SPV-clients-and-relaying-double-spends.xml | 13 ++-- .../combined_Small-update-to-BIP-62.xml | 13 ++-- ...ombined_cryptographic-review-requested.xml | 13 ++-- ...combined_replace-by-fee-v0-9-3-release.xml | 13 ++-- ...ined_-BIP-Draft-BIP-Acceptance-Process.xml | 13 ++-- ...P-Proposal-New-sendheaders-p2p-message.xml | 17 ++--- ...l-Version-bits-with-timeout-and-delay-.xml | 13 ++-- ...VERIFY-An-opcode-for-relative-locktime.xml | 13 ++-- ...dev-Weekly-Development-Meeting-Minutes.xml | 13 ++-- ...or-Bitcoin-as-stated-in-original-email.xml | 13 ++-- ...via-a-hidden-firewall-in-the-cable-box.xml | 13 ++-- ...n-nodes-via-utilizing-private-subnets-.xml | 13 ++-- ...iculty-depending-on-relative-blocksize.xml | 13 ++-- .../Sept_2015/combined_BIP-100-repo.xml | 13 ++-- .../combined_BIP-100-specification.xml | 13 ++-- ...d_Bitcoin-Core-0-12-0-release-schedule.xml | 13 ++-- ...Destroyed-as-block-selection-heuristic.xml | 13 ++-- .../combined_Bitcoin-mining-idea.xml | 13 ++-- ...-w64-dev-has-no-installation-candidate.xml | 13 ++-- ...Questions-about-Gitian-and-other-stuff.xml | 13 ++-- .../Sept_2015/combined_Design-Competition.xml | 13 ++-- ...to-the-block-size-BIP-draft-discussion.xml | 13 ++-- .../combined_ERRATA-CORRIGE-Short-Theorem.xml | 13 ++-- .../combined_Fill-or-kill-transaction.xml | 13 ++-- ...Hash-of-UTXO-set-as-consensus-critical.xml | 13 ++-- ...locksize-Communication-Through-Markets.xml | 13 ++-- ...ined_Instant-exchange-rates-URI-scheme.xml | 13 ++-- ...re-to-be-two-chains-after-a-hard-fork-.xml | 13 ++-- ...et-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml | 13 ++-- ...tations-to-grow-from-its-fertile-ashes.xml | 13 ++-- ...ensus-and-bitcoin-development-process-.xml | 13 ++-- .../combined_Named-Bitcoin-Addresses.xml | 13 ++-- ...-bitcoin-dev-list-admin-and-list-noise.xml | 13 ++-- ...pen-Block-Chain-Licence-BIP-xxxx-Draft.xml | 13 ++-- ...ombined_Problem-compiling-bitcoin-core.xml | 13 ++-- ...l-to-add-the-bitcoin-symbol-to-Unicode.xml | 68 +++++++++++-------- ...-01-to-use-a-PR-for-request-assignment.xml | 13 ++-- ...pend-on-other-unconfirmed-transactions.xml | 13 ++-- ...hristmas-modest-blocksize-max-increase.xml | 13 ++-- ...-URI-scheme-for-Blockchain-exploration.xml | 13 ++-- ...age-address-derivation-based-on-BIP-43.xml | 13 ++-- ...caling-Bitcoin-conference-micro-report.xml | 13 ++-- ...eviously-proposed-exotic-SIGHASH-types.xml | 13 ++-- ...-new-block-propagation-on-Merkle-trees.xml | 13 ++-- ...eme-for-signing-and-verifying-messages.xml | 13 ++-- ...nbits-BIP-009-minor-revision-proposal-.xml | 13 ++-- .../combined_Weak-block-thoughts-.xml | 13 ++-- ...y-development-meetings-on-IRC-schedule.xml | 13 ++-- ...ned_Weekly-development-meetings-on-IRC.xml | 13 ++-- ...another-blocklimit-proposal-compromise.xml | 13 ++-- .../combined_Your-Gmaxwell-exchange.xml | 13 ++-- ...ombined_block-size-pay-with-difficulty.xml | 13 ++-- ...sensus-and-bitcoin-development-process.xml | 13 ++-- .../Sept_2015/combined_push-tx-fuzzing.xml | 13 ++-- ...-on-OSX-and-Arch-Linux-should-be-fixed.xml | 13 ++-- ...transactions-after-segwit-is-accepted-.xml | 5 +- .../combined_BIP-2-revival-and-rework.xml | 5 +- ...mbined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml | 5 +- ...ing-the-retirement-of-the-alert-system.xml | 5 +- ...purpose-of-Bitcoin-attested-timestamps.xml | 5 +- ...-IF-and-OP-NOTIF-malleability-in-P2WSH.xml | 5 +- ...-with-dummy-stack-element-malleability.xml | 5 +- ...mbined_New-BIP-Low-S-values-signatures.xml | 5 +- ...n-going-work-Coin-Selection-Simulation.xml | 5 +- ...-change-removing-OPL-licensing-option-.xml | 5 +- ...-BIP-assignment-Flexible-Transactions-.xml | 5 +- ...5-Retarget-Call-For-Proposals-Now-Open.xml | 5 +- ...ty-fix-opcode-proposal-OP-TXHASHVERIFY.xml | 5 +- .../Sept_2017/combined_Fast-Merkle-Trees.xml | 5 +- ...combined_Fwd-Compressed-headers-stream.xml | 5 +- ...ication-of-drivechains-and-spv-proofs-.xml | 5 +- ...tended-serialization-format-for-BIP-32.xml | 5 +- ...bip32-version-bytes-for-segwit-scripts.xml | 5 +- ...ndard-is-Insecure-Against-MITM-Attacks.xml | 5 +- ...l-call-semantics-for-generalized-MAST-.xml | 5 +- ...hetical-Could-soft-forks-be-prevented-.xml | 5 +- ...in-core-dev-Bitcoin-Core-update-notice.xml | 5 +- ...hain-with-recent-history-plus-UTXO-Set.xml | 5 +- .../combined_Selfish-Mining-Prevention.xml | 5 +- ...RI-scheme-with-optional-bech32-address.xml | 5 +- ..._Block-Batch-Filters-for-Light-Clients.xml | 5 +- .../Sept_2021/combined_BIP-extensions.xml | 5 +- ...th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml | 5 +- ...oposal-for-a-decentralised-mining-pool.xml | 5 +- ...mbined_Reminder-on-the-Purpose-of-BIPs.xml | 5 +- ...P-Proposal-Wallet-Labels-Export-Format.xml | 5 +- ...community-process-to-specify-covenants.xml | 5 +- .../combined_Packaged-Transaction-Relay.xml | 5 +- ...d_Transcript-Online-Socratic-on-MuSig2.xml | 5 +- ...tr-coinjoin-implementation-using-nostr.xml | 5 +- .../combined_Concern-about-Inscriptions-.xml | 5 +- 1512 files changed, 9248 insertions(+), 7723 deletions(-) diff --git a/static/bitcoin-dev/April_2012/combined_Adding-request-reply-id-in-messages.xml b/static/bitcoin-dev/April_2012/combined_Adding-request-reply-id-in-messages.xml index 14091b8d14..9481100302 100644 --- a/static/bitcoin-dev/April_2012/combined_Adding-request-reply-id-in-messages.xml +++ b/static/bitcoin-dev/April_2012/combined_Adding-request-reply-id-in-messages.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Adding request/reply id in messages - 2023-08-01T03:26:12.873195+00:00 + 2025-10-11T21:47:57.386732+00:00 + python-feedgen Wladimir 2012-04-13 06:30:49+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Adding request/reply id in messages - 2023-08-01T03:26:12.874194+00:00 + 2025-10-11T21:47:57.386904+00:00 - Amidst an email conversation regarding a proposed improvement to the Bitcoin protocol, the author of the proposal defends it against claims that it would make the protocol more stateful. They argue that each reply is only the result of the current request and does not introduce new session information. On the other hand, another individual suggests that there is still state involved in the proposal, as certain commands require keeping track of previous requests. However, the author counters this argument by stating that many of the described commands already have a natural nonce and do not require additional administration.The proposed change in question focuses on distinguishing between replies and spontaneous notifications from the other peer, with all state still being tracked locally on the client side. The author is confused as to why the proposal would be seen as making the protocol more stateful, as each reply is simply a result of the current request and does not introduce new session information. Additionally, the proposed change does not directly improve peers that do not answer requests, but rather enables easier implementation of this improvement when all peers are running the modified code.The proposal aims to add a new "requestid" field in messages as a part of improving blockchain downloading. This addition would provide context information to help distinguish between responses to "getblocks" requests and spontaneous "inv" notifications. However, some members of the email conversation express concerns about the change. They argue that stateless protocols are easier to implement and prove correct, and they worry about the potential costs and vulnerabilities associated with relying on external parties for state maintenance. Despite these concerns, the discussion emphasizes the importance of ensuring the reliability and security of the Bitcoin network.In the email exchange, Christian Bodt proposes a bitcoin protocol improvement that involves adding a request/reply ID in all messages. This is intended to facilitate robust blockchain downloading by providing better handling of response and request messages. However, Jeff Garzik disagrees with the proposal, stating that the problems mentioned can be addressed without adding "requestid" fields. He argues that stateless protocols are easier to implement and prove correct, and he cautions against relying on external parties for state maintenance due to the potential for exploitation.The context also mentions a patch for modifying the behavior of the Bitcoin protocol related to making a second "getblocks" request. This modification always results in one "inv" reply with [0-500] elements and removes the filtering on previously transmitted block invs. The patch can be found on the GitHub repository of the Bitcoin project.In another email exchange between Pieter Wuille and Gavin Andresen, the topic of adding request/reply ID to all messages in the Bitcoin protocol is discussed. While Andresen sees it as a reasonable improvement, Wuille points out that the Bitcoin P2P protocol is mostly stateless, which enhances its security. Wuille suggests the addition of a "denied" message instead, to indicate when a client is unwilling to answer and report transactions not accepted into the memory pool.Gavin Andresen posts on the bitcoin developers' mailing list about the proposed improvement suggested by Christian Bodt. The proposal involves adding a request/reply ID in all messages similar to the "checksum" field. Andresen finds the proposal reasonable and seeks others' opinions. However, Pieter Wuille notes that the Bitcoin P2P protocol is not fully request-reply based, making the proposed change less intuitive. Wuille suggests including an additional "denied" message to indicate an unwillingness to answer and report rejected transactions.Christian Bodt from France proposes a Bitcoin protocol improvement by adding a "request/reply id" field in all messages. This aims to facilitate robust blockchain downloading by providing context information. Christian has already implemented a prototype of this proposal and shares it for reference. The discussion surrounding this proposal arises from reading the PONG BIP and observing a similar nonce field, leading to uncertainty about the necessity of the nonce field with the presence of request/reply ids. 2012-04-13T06:30:49+00:00 + Amidst an email conversation regarding a proposed improvement to the Bitcoin protocol, the author of the proposal defends it against claims that it would make the protocol more stateful. They argue that each reply is only the result of the current request and does not introduce new session information. On the other hand, another individual suggests that there is still state involved in the proposal, as certain commands require keeping track of previous requests. However, the author counters this argument by stating that many of the described commands already have a natural nonce and do not require additional administration.The proposed change in question focuses on distinguishing between replies and spontaneous notifications from the other peer, with all state still being tracked locally on the client side. The author is confused as to why the proposal would be seen as making the protocol more stateful, as each reply is simply a result of the current request and does not introduce new session information. Additionally, the proposed change does not directly improve peers that do not answer requests, but rather enables easier implementation of this improvement when all peers are running the modified code.The proposal aims to add a new "requestid" field in messages as a part of improving blockchain downloading. This addition would provide context information to help distinguish between responses to "getblocks" requests and spontaneous "inv" notifications. However, some members of the email conversation express concerns about the change. They argue that stateless protocols are easier to implement and prove correct, and they worry about the potential costs and vulnerabilities associated with relying on external parties for state maintenance. Despite these concerns, the discussion emphasizes the importance of ensuring the reliability and security of the Bitcoin network.In the email exchange, Christian Bodt proposes a bitcoin protocol improvement that involves adding a request/reply ID in all messages. This is intended to facilitate robust blockchain downloading by providing better handling of response and request messages. However, Jeff Garzik disagrees with the proposal, stating that the problems mentioned can be addressed without adding "requestid" fields. He argues that stateless protocols are easier to implement and prove correct, and he cautions against relying on external parties for state maintenance due to the potential for exploitation.The context also mentions a patch for modifying the behavior of the Bitcoin protocol related to making a second "getblocks" request. This modification always results in one "inv" reply with [0-500] elements and removes the filtering on previously transmitted block invs. The patch can be found on the GitHub repository of the Bitcoin project.In another email exchange between Pieter Wuille and Gavin Andresen, the topic of adding request/reply ID to all messages in the Bitcoin protocol is discussed. While Andresen sees it as a reasonable improvement, Wuille points out that the Bitcoin P2P protocol is mostly stateless, which enhances its security. Wuille suggests the addition of a "denied" message instead, to indicate when a client is unwilling to answer and report transactions not accepted into the memory pool.Gavin Andresen posts on the bitcoin developers' mailing list about the proposed improvement suggested by Christian Bodt. The proposal involves adding a request/reply ID in all messages similar to the "checksum" field. Andresen finds the proposal reasonable and seeks others' opinions. However, Pieter Wuille notes that the Bitcoin P2P protocol is not fully request-reply based, making the proposed change less intuitive. Wuille suggests including an additional "denied" message to indicate an unwillingness to answer and report rejected transactions.Christian Bodt from France proposes a Bitcoin protocol improvement by adding a "request/reply id" field in all messages. This aims to facilitate robust blockchain downloading by providing context information. Christian has already implemented a prototype of this proposal and shares it for reference. The discussion surrounding this proposal arises from reading the PONG BIP and observing a similar nonce field, leading to uncertainty about the necessity of the nonce field with the presence of request/reply ids. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_Announcement-libcoin.xml b/static/bitcoin-dev/April_2012/combined_Announcement-libcoin.xml index 8ec33e056b..13ca4d9014 100644 --- a/static/bitcoin-dev/April_2012/combined_Announcement-libcoin.xml +++ b/static/bitcoin-dev/April_2012/combined_Announcement-libcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.669593+00:00 + 2025-10-11T21:48:12.254793+00:00 + python-feedgen Martinx - ジェームズ 2012-09-12 23:27:32+00:00 @@ -207,13 +208,13 @@ - python-feedgen + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.670592+00:00 + 2025-10-11T21:48:12.255002+00:00 - In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, 2012-09-12T23:27:32+00:00 + In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_Announcing-the-IFEX-Project.xml b/static/bitcoin-dev/April_2012/combined_Announcing-the-IFEX-Project.xml index f9e7ac9ac0..7c4f680b43 100644 --- a/static/bitcoin-dev/April_2012/combined_Announcing-the-IFEX-Project.xml +++ b/static/bitcoin-dev/April_2012/combined_Announcing-the-IFEX-Project.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Announcing the IFEX Project - 2023-08-01T03:26:54.647274+00:00 + 2025-10-11T21:47:55.262321+00:00 + python-feedgen Gary Rowe 2012-04-13 10:16:07+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Announcing the IFEX Project - 2023-08-01T03:26:54.647274+00:00 + 2025-10-11T21:47:55.262524+00:00 - A project called XChange has been developed to create a unified API for accessing financial exchanges, starting with Bitcoin exchanges like MtGox and Intersango. The goal of the project is to expand its support to other exchanges in the future. However, one challenge faced by the XChange team is that each exchange has its own data model and protocol. To address this, they aim to provide a reference implementation to guide exchanges in publishing their data.In addition to XChange, there is also the Internet Financial EXchange (IFEX) Project, which aims to enhance interoperability between various financial settlement systems. This includes both conventional and digital currencies, alternative financial communities, and financial service providers. The IFEX Protocol, still under development, seeks to establish a standard protocol for transaction and settlement path negotiation involving any financial instruments, currencies, or assets. The objective is to facilitate better connectivity, reduce settlement fees, enable real-time redundant financial routing, and handle arbitrary instruments, currencies, or assets.The IFEX Project offers a broader and more inclusive scope compared to existing vendor-specific APIs and conventional finance industry networking protocols. It does not aim to be a currency or settlement network itself, but rather a mechanism for bridging them. The project hopes to move towards an open-source implementation of the IFEX protocol that can work with major and emerging settlement networks.To further enhance interoperability, the IFEX Project has proposed the IIBAN Proposal (v1), which introduces a 13-character identifier for financial endpoint identification. This identifier, available on the project's website, is theoretically compatible with conventional banking infrastructure in Europe and other countries. By providing this identifier, the project aims to allocate identifiers in a democratic manner for the benefit of the community.Overall, both the XChange project and the IFEX Project aim to improve interoperability and connectivity within the financial ecosystem. While XChange focuses on creating a unified API for accessing financial exchanges, the IFEX Project aims to establish a standard protocol for transaction and settlement path negotiation across various financial systems. The hope is that these initiatives will lead to better connectivity, lower settlement fees, and more efficient handling of financial instruments, currencies, and assets for the benefit of all stakeholders in the community. 2012-04-13T10:16:07+00:00 + A project called XChange has been developed to create a unified API for accessing financial exchanges, starting with Bitcoin exchanges like MtGox and Intersango. The goal of the project is to expand its support to other exchanges in the future. However, one challenge faced by the XChange team is that each exchange has its own data model and protocol. To address this, they aim to provide a reference implementation to guide exchanges in publishing their data.In addition to XChange, there is also the Internet Financial EXchange (IFEX) Project, which aims to enhance interoperability between various financial settlement systems. This includes both conventional and digital currencies, alternative financial communities, and financial service providers. The IFEX Protocol, still under development, seeks to establish a standard protocol for transaction and settlement path negotiation involving any financial instruments, currencies, or assets. The objective is to facilitate better connectivity, reduce settlement fees, enable real-time redundant financial routing, and handle arbitrary instruments, currencies, or assets.The IFEX Project offers a broader and more inclusive scope compared to existing vendor-specific APIs and conventional finance industry networking protocols. It does not aim to be a currency or settlement network itself, but rather a mechanism for bridging them. The project hopes to move towards an open-source implementation of the IFEX protocol that can work with major and emerging settlement networks.To further enhance interoperability, the IFEX Project has proposed the IIBAN Proposal (v1), which introduces a 13-character identifier for financial endpoint identification. This identifier, available on the project's website, is theoretically compatible with conventional banking infrastructure in Europe and other countries. By providing this identifier, the project aims to allocate identifiers in a democratic manner for the benefit of the community.Overall, both the XChange project and the IFEX Project aim to improve interoperability and connectivity within the financial ecosystem. While XChange focuses on creating a unified API for accessing financial exchanges, the IFEX Project aims to establish a standard protocol for transaction and settlement path negotiation across various financial systems. The hope is that these initiatives will lead to better connectivity, lower settlement fees, and more efficient handling of financial instruments, currencies, and assets for the benefit of all stakeholders in the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_BIP-31.xml b/static/bitcoin-dev/April_2012/combined_BIP-31.xml index e30e351114..3bd58dea83 100644 --- a/static/bitcoin-dev/April_2012/combined_BIP-31.xml +++ b/static/bitcoin-dev/April_2012/combined_BIP-31.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 31 - 2023-08-01T03:25:41.622490+00:00 + 2025-10-11T21:48:01.634996+00:00 + python-feedgen Jeff Garzik 2012-04-11 17:00:25+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP 31 - 2023-08-01T03:25:41.622490+00:00 + 2025-10-11T21:48:01.635145+00:00 - During a discussion on April 11, 2012, Luke-Jr and Mike Hearn debated the implementation of a Bitcoin Improvement Proposal (BIP) for the pong message. Mike shared a link to BIP 0031 on the en.bitcoin.it wiki, which outlined rules for handling the pong message. However, Luke-Jr had previously suggested using protocol version bump 60001 instead. In reference to this, Pull #1081 was mentioned as making some revisions along these lines.On the same day, Mike Hearn emailed Jeff Garzik about the BIP for the pong message. The email included a link to the Bitcoin Improvement Proposals (BIP) wiki page. Although the exact context of the message is unclear, it seems that there was a discussion regarding the protocol version bump, specifically whether to adopt the value 60001.Jeff requested a BIP related to the pong message, and the provided link directed to the Bitcoin Wiki, where BIP 0031 was described in detail. This proposal outlined specific rules for handling the pong message, which serves to check if a connection between two nodes is still active. The BIP included comprehensive technical specifications and guidelines for implementing these rules. Adhering to these standards ensures compatibility among Bitcoin implementations, ultimately enhancing the network's overall quality and reliability. 2012-04-11T17:00:25+00:00 + During a discussion on April 11, 2012, Luke-Jr and Mike Hearn debated the implementation of a Bitcoin Improvement Proposal (BIP) for the pong message. Mike shared a link to BIP 0031 on the en.bitcoin.it wiki, which outlined rules for handling the pong message. However, Luke-Jr had previously suggested using protocol version bump 60001 instead. In reference to this, Pull #1081 was mentioned as making some revisions along these lines.On the same day, Mike Hearn emailed Jeff Garzik about the BIP for the pong message. The email included a link to the Bitcoin Improvement Proposals (BIP) wiki page. Although the exact context of the message is unclear, it seems that there was a discussion regarding the protocol version bump, specifically whether to adopt the value 60001.Jeff requested a BIP related to the pong message, and the provided link directed to the Bitcoin Wiki, where BIP 0031 was described in detail. This proposal outlined specific rules for handling the pong message, which serves to check if a connection between two nodes is still active. The BIP included comprehensive technical specifications and guidelines for implementing these rules. Adhering to these standards ensures compatibility among Bitcoin implementations, ultimately enhancing the network's overall quality and reliability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_BIP-to-improve-the-availability-of-blocks.xml b/static/bitcoin-dev/April_2012/combined_BIP-to-improve-the-availability-of-blocks.xml index a68a31d2a9..8165edbc8a 100644 --- a/static/bitcoin-dev/April_2012/combined_BIP-to-improve-the-availability-of-blocks.xml +++ b/static/bitcoin-dev/April_2012/combined_BIP-to-improve-the-availability-of-blocks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP to improve the availability of blocks - 2023-08-01T03:27:44.714263+00:00 + 2025-10-11T21:48:03.757475+00:00 + python-feedgen Peter Vessenes 2012-04-30 20:54:37+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP to improve the availability of blocks - 2023-08-01T03:27:44.714263+00:00 + 2025-10-11T21:48:03.757648+00:00 - The discussion in this context revolves around a proposal to improve the availability of blocks in Bitcoin. One member proposes adding a checksum for the blocks to save bandwidth among behaving nodes, but another argues that bandwidth is not the bottleneck of the Bitcoin system and it is the immense time needed to validate the blockchain. Clients should never send blocks first, but always an inv packet, then request the block.Amir Taaki, a bitcoin developer, stated that the proposed Bitcoin Improvement Proposal (BIP) to improve the availability of blocks is an optimization that is not needed because bandwidth is not the bottleneck of the Bitcoin system. He also stated that clients should never send blocks first and this change will cause disruption and bring little benefit. On the other hand, Rebroad suggested adding a hash to the block header to enable nodes to reject an already downloaded block, which would aid in saving bandwidth among well-behaving nodes.Wladimir noted that it would make sense for clients to be able to reject blocks they already have, but there would be no need for a BIP if you want to somehow fetch the block chain outside the bitcoin protocol. It could be downloaded from some http server or passed along on a USB stick. Currently, nodes with restrictive or slow internet have options such as going via a tor proxy; however, the problem with multiple receptions of the same block still occurs due to latency. If one is behind such a slow internet connection and concerned about every bit of bandwidth, it is better to run a lightweight node like Electrum.The email thread discusses a proposal to improve the availability of blocks in the Bitcoin system. The proposal suggests advertising hash in addition to the size in the header block, which would help nodes reject downloads if they already have a matching block to save bandwidth. Wladimir agrees that it would make sense for clients to be able to reject blocks they already have. However, he points out that introducing a new feature like this can cause maintenance and compatibility issues.Another part of the proposal is to allow nodes to request upload and download blocks that have already been partially downloaded. However, Wladimir thinks that introducing a BIP for this is unnecessary as users can simply download the blockchain from an HTTP server or pass it along on a USB stick. He suggests that running a lightweight node like Electrum could be a better option for those with restrictive or slow internet connections.In a forum discussion on SourceForge, Rebroad proposed adding hash advertisements in the header of a block, which would help nodes determine if they want to reject a download. This proposal could aid in saving bandwidth among behaving nodes. Rebroad also suggested modifying existing methods or adding a new method to allow nodes to request upload and download partially downloaded blocks. This would help nodes obtain the blockchain who have restrictive ISPs, especially if they are being served on port 80 or 443. Another option for those with slow or restrictive internet is to run a lightweight node like Electrum. However, Wladimir pointed out that even with partial blocks, the download will still be substantial.The proposal put forth by Ed to Bitcoin developers is to extend the protocol to allow partial block download and upload for people with intermittent or restricted internet connectivity. The proposal suggests adding the hash along with the size in the header of a block, which would help nodes determine whether they want to reject the download if they already have the same block. This addition could save bandwidth amongst behaving nodes. The other part of the proposal is to allow nodes to request the upload and download of blocks that have already been partially downloaded, which can be done by modifying existing methods of upload and download or by adding a new method, possibly using HTTP/HTTPS or similar methods. This could help nodes obtain the blockchain if they have restrictive ISPs, especially if it's served on ports 80 or 443. Moreover, web caches could keep caches of the blockchain, making it more widely available. Currently, nodes with restrictive or slow internet have some options, such as going via a tor proxy, but there are problems with multiple receptions of the same block due to latency. In conclusion, Ed's proposal aims to make the blockchain more accessible to nodes with limited internet connectivity while also saving bandwidth among nodes. 2012-04-30T20:54:37+00:00 + The discussion in this context revolves around a proposal to improve the availability of blocks in Bitcoin. One member proposes adding a checksum for the blocks to save bandwidth among behaving nodes, but another argues that bandwidth is not the bottleneck of the Bitcoin system and it is the immense time needed to validate the blockchain. Clients should never send blocks first, but always an inv packet, then request the block.Amir Taaki, a bitcoin developer, stated that the proposed Bitcoin Improvement Proposal (BIP) to improve the availability of blocks is an optimization that is not needed because bandwidth is not the bottleneck of the Bitcoin system. He also stated that clients should never send blocks first and this change will cause disruption and bring little benefit. On the other hand, Rebroad suggested adding a hash to the block header to enable nodes to reject an already downloaded block, which would aid in saving bandwidth among well-behaving nodes.Wladimir noted that it would make sense for clients to be able to reject blocks they already have, but there would be no need for a BIP if you want to somehow fetch the block chain outside the bitcoin protocol. It could be downloaded from some http server or passed along on a USB stick. Currently, nodes with restrictive or slow internet have options such as going via a tor proxy; however, the problem with multiple receptions of the same block still occurs due to latency. If one is behind such a slow internet connection and concerned about every bit of bandwidth, it is better to run a lightweight node like Electrum.The email thread discusses a proposal to improve the availability of blocks in the Bitcoin system. The proposal suggests advertising hash in addition to the size in the header block, which would help nodes reject downloads if they already have a matching block to save bandwidth. Wladimir agrees that it would make sense for clients to be able to reject blocks they already have. However, he points out that introducing a new feature like this can cause maintenance and compatibility issues.Another part of the proposal is to allow nodes to request upload and download blocks that have already been partially downloaded. However, Wladimir thinks that introducing a BIP for this is unnecessary as users can simply download the blockchain from an HTTP server or pass it along on a USB stick. He suggests that running a lightweight node like Electrum could be a better option for those with restrictive or slow internet connections.In a forum discussion on SourceForge, Rebroad proposed adding hash advertisements in the header of a block, which would help nodes determine if they want to reject a download. This proposal could aid in saving bandwidth among behaving nodes. Rebroad also suggested modifying existing methods or adding a new method to allow nodes to request upload and download partially downloaded blocks. This would help nodes obtain the blockchain who have restrictive ISPs, especially if they are being served on port 80 or 443. Another option for those with slow or restrictive internet is to run a lightweight node like Electrum. However, Wladimir pointed out that even with partial blocks, the download will still be substantial.The proposal put forth by Ed to Bitcoin developers is to extend the protocol to allow partial block download and upload for people with intermittent or restricted internet connectivity. The proposal suggests adding the hash along with the size in the header of a block, which would help nodes determine whether they want to reject the download if they already have the same block. This addition could save bandwidth amongst behaving nodes. The other part of the proposal is to allow nodes to request the upload and download of blocks that have already been partially downloaded, which can be done by modifying existing methods of upload and download or by adding a new method, possibly using HTTP/HTTPS or similar methods. This could help nodes obtain the blockchain if they have restrictive ISPs, especially if it's served on ports 80 or 443. Moreover, web caches could keep caches of the blockchain, making it more widely available. Currently, nodes with restrictive or slow internet have some options, such as going via a tor proxy, but there are problems with multiple receptions of the same block due to latency. In conclusion, Ed's proposal aims to make the blockchain more accessible to nodes with limited internet connectivity while also saving bandwidth among nodes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_Bitcoin-TX-fill-or-kill-deterministic-behavior.xml b/static/bitcoin-dev/April_2012/combined_Bitcoin-TX-fill-or-kill-deterministic-behavior.xml index 81f5762dad..771bc354a1 100644 --- a/static/bitcoin-dev/April_2012/combined_Bitcoin-TX-fill-or-kill-deterministic-behavior.xml +++ b/static/bitcoin-dev/April_2012/combined_Bitcoin-TX-fill-or-kill-deterministic-behavior.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin TX fill-or-kill deterministic behavior - 2023-08-01T03:26:37.215016+00:00 + 2025-10-11T21:48:10.130761+00:00 + python-feedgen Jeff Garzik 2012-04-15 15:17:04+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Bitcoin TX fill-or-kill deterministic behavior - 2023-08-01T03:26:37.215016+00:00 + 2025-10-11T21:48:10.130951+00:00 - On April 12, 2012, bitcoin developers Jorge Timón and Jeff Garzik discussed the issue of dropped transactions in Bitcoin. Garzik proposed several solutions, including adding a field called expiration_block to the transaction, which would determine when the transaction should be dropped from the memory pool. Timón suggested an alternative approach, but Garzik argued against it.In another email conversation, Garzik and others discussed the idea of direct payee-to-payer communication. The original design of Bitcoin had envisioned using pay-to-IP address mode for payments, but it was removed due to its unreliability and privacy concerns. There was a suggestion to use a separate protocol for direct communication, and it was noted that Bitcoin Wallet for Android already supported this feature.Pieter Wuille and Garzik discussed how an HTTP derivative could simplify mobile payments, firewalled scenarios, and client-merchant communications. Pieter recommended reading a GitHub gist on the topic.In a forum discussion, Garzik raised concerns about direct payer-payer communication with merchants and proposed using a separate protocol for such transactions. It was noted that the original Bitcoin design involved direct communication between participants, but things had evolved differently. Garzik suggested using an HTTP derivative for better mobile payments and client-merchant communications.A conversation between Mike Hearn and Garzik explored the concept of chain transactions, network fee requirements, and market-based fees. They discussed the idea of passing transactions outside of the broadcast network and only broadcasting them when there's a lack of trust between sender and recipient. They also agreed that more direct communication between payee and payer is needed, but it should be done through a separate protocol.Garzik suggested that transactions should expire if they don't make it into a block. He criticized the current fee system as an "ugly hack" and suggested sending transactions directly to merchants or using an instant-payments layer on top of the Bitcoin block chain.Improvements to the Bitcoin protocol were discussed, including having transactions expire if they are not accepted by miners. The user experience of attaching fees to transactions was considered negative, and merchants handling fee calculations themselves was suggested as a solution. This would require a minor change to how fees are calculated in the memory pool.Garzik expressed concerns about the non-deterministic nature of transactions in Bitcoin and proposed removing transactions from the memory pool if they haven't made it into a block for a couple of days. He also suggested a change in the transaction announcement protocol to include the block the user wants to base on, which would protect against double spends and make expiry from the memory pool easier.There were discussions about users exploiting the behavior of creating transactions that they know will get stuck and expire. It was compared to canceling zero-conf transactions, and the possibility of detecting and flagging such transactions was mentioned.The proposal to remove transactions from the memory pool after a specific period of time aims to make Bitcoin transactions more deterministic and predictable for users. While there are concerns about potential exploitation, this change could lead to better wallet/coin recovery and resending options for expired transactions.Overall, the discussions focused on improving the predictability, efficiency, and user experience of Bitcoin transactions through various proposals and considerations. 2012-04-15T15:17:04+00:00 + On April 12, 2012, bitcoin developers Jorge Timón and Jeff Garzik discussed the issue of dropped transactions in Bitcoin. Garzik proposed several solutions, including adding a field called expiration_block to the transaction, which would determine when the transaction should be dropped from the memory pool. Timón suggested an alternative approach, but Garzik argued against it.In another email conversation, Garzik and others discussed the idea of direct payee-to-payer communication. The original design of Bitcoin had envisioned using pay-to-IP address mode for payments, but it was removed due to its unreliability and privacy concerns. There was a suggestion to use a separate protocol for direct communication, and it was noted that Bitcoin Wallet for Android already supported this feature.Pieter Wuille and Garzik discussed how an HTTP derivative could simplify mobile payments, firewalled scenarios, and client-merchant communications. Pieter recommended reading a GitHub gist on the topic.In a forum discussion, Garzik raised concerns about direct payer-payer communication with merchants and proposed using a separate protocol for such transactions. It was noted that the original Bitcoin design involved direct communication between participants, but things had evolved differently. Garzik suggested using an HTTP derivative for better mobile payments and client-merchant communications.A conversation between Mike Hearn and Garzik explored the concept of chain transactions, network fee requirements, and market-based fees. They discussed the idea of passing transactions outside of the broadcast network and only broadcasting them when there's a lack of trust between sender and recipient. They also agreed that more direct communication between payee and payer is needed, but it should be done through a separate protocol.Garzik suggested that transactions should expire if they don't make it into a block. He criticized the current fee system as an "ugly hack" and suggested sending transactions directly to merchants or using an instant-payments layer on top of the Bitcoin block chain.Improvements to the Bitcoin protocol were discussed, including having transactions expire if they are not accepted by miners. The user experience of attaching fees to transactions was considered negative, and merchants handling fee calculations themselves was suggested as a solution. This would require a minor change to how fees are calculated in the memory pool.Garzik expressed concerns about the non-deterministic nature of transactions in Bitcoin and proposed removing transactions from the memory pool if they haven't made it into a block for a couple of days. He also suggested a change in the transaction announcement protocol to include the block the user wants to base on, which would protect against double spends and make expiry from the memory pool easier.There were discussions about users exploiting the behavior of creating transactions that they know will get stuck and expire. It was compared to canceling zero-conf transactions, and the possibility of detecting and flagging such transactions was mentioned.The proposal to remove transactions from the memory pool after a specific period of time aims to make Bitcoin transactions more deterministic and predictable for users. While there are concerns about potential exploitation, this change could lead to better wallet/coin recovery and resending options for expired transactions.Overall, the discussions focused on improving the predictability, efficiency, and user experience of Bitcoin transactions through various proposals and considerations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_Network-version-increase.xml b/static/bitcoin-dev/April_2012/combined_Network-version-increase.xml index 3738337736..bfd75d2e6c 100644 --- a/static/bitcoin-dev/April_2012/combined_Network-version-increase.xml +++ b/static/bitcoin-dev/April_2012/combined_Network-version-increase.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Network version increase - 2023-08-01T03:25:11.430592+00:00 + 2025-10-11T21:48:14.389580+00:00 + python-feedgen Wladimir 2012-04-02 16:42:54+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Network version increase - 2023-08-01T03:25:11.430592+00:00 + 2025-10-11T21:48:14.389741+00:00 - On April 2, 2012, a discussion was initiated by Jeff Garzik about the current numbering scheme being used, which stands at 60000. Pieter Wuille proposed two options for the future numbering scheme: either incrementing the number by one for every change or performing a "cleanup" to 100000 and then starting from there. Jeff Garzik voiced his preference for having 100000 as the baseline frozen protocol. Wladimir agreed with the idea of incrementing the number by one for now and not getting ahead of themselves.During an email thread on the same day, Pieter Wuille sought opinions on a numbering scheme. The current value being used was 60000, and the two options proposed were either incrementing the number by one for every change or performing a cleanup to 100000 before incrementing further. Jeff Garzik expressed his preference for having 100000 as the baseline or a frozen protocol.Meanwhile, Mike Hearn submitted a pull request to add a pong message in response to a ping. This change requires an upgrade of the network protocol version number, which has been independent from the version numbers of the reference client since BIP14. The current version number is 60000. Pieter is seeking opinions on whether to simply increase the number by one for every change or perform a cleanup and start incrementing from 100000. 2012-04-02T16:42:54+00:00 + On April 2, 2012, a discussion was initiated by Jeff Garzik about the current numbering scheme being used, which stands at 60000. Pieter Wuille proposed two options for the future numbering scheme: either incrementing the number by one for every change or performing a "cleanup" to 100000 and then starting from there. Jeff Garzik voiced his preference for having 100000 as the baseline frozen protocol. Wladimir agreed with the idea of incrementing the number by one for now and not getting ahead of themselves.During an email thread on the same day, Pieter Wuille sought opinions on a numbering scheme. The current value being used was 60000, and the two options proposed were either incrementing the number by one for every change or performing a cleanup to 100000 before incrementing further. Jeff Garzik expressed his preference for having 100000 as the baseline or a frozen protocol.Meanwhile, Mike Hearn submitted a pull request to add a pong message in response to a ping. This change requires an upgrade of the network protocol version number, which has been independent from the version numbers of the reference client since BIP14. The current version number is 60000. Pieter is seeking opinions on whether to simply increase the number by one for every change or perform a cleanup and start incrementing from 100000. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_Signature-Blocks-and-URI-Sign-Requests.xml b/static/bitcoin-dev/April_2012/combined_Signature-Blocks-and-URI-Sign-Requests.xml index 00628d3e4f..104edd32b6 100644 --- a/static/bitcoin-dev/April_2012/combined_Signature-Blocks-and-URI-Sign-Requests.xml +++ b/static/bitcoin-dev/April_2012/combined_Signature-Blocks-and-URI-Sign-Requests.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Signature Blocks and URI Sign Requests - 2023-08-01T03:25:30.459743+00:00 + 2025-10-11T21:47:59.512737+00:00 + python-feedgen Michael Grønager 2012-04-04 08:35:12+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Signature Blocks and URI Sign Requests - 2023-08-01T03:25:30.459743+00:00 + 2025-10-11T21:47:59.512889+00:00 - The email conversations discuss various proposals and concerns related to improving security measures in Bitcoin transactions. Wladimir suggests signing preformatted messages from sites to enhance transaction security. The proposed approach involves creating a 512-bit data structure by taking the sha512 of a document and then taking ripemd160 of hash512. This procedure prevents malicious sites from tricking users into signing transactions spending their own coins.There is also a discussion about the importance of multi-sig technology in Bitcoin transactions. Alan Reiner expresses concern about the complexity of executing multi-sig transactions and suggests that BIP 10 (or successor) is critical for the success of multi-sig. Wladimir agrees with the need for simpler execution of multi-sig and proposes defining URL signing/authentication to make P2SH easier and less involved. He also highlights the issue of URL size limit and suggests a solution to pass the address where the message can be retrieved.In another conversation, Alan Reiner clarifies that his proposal is not about changing the Bitcoin protocol itself but rather an intermediate data format that allows users to sign messages with their existing Bitcoin identities. There are discussions on whether to extend existing standards like PGP/EC or create a new solution. The focus is on simplicity and caution when considering changes to the Bitcoin protocol.Gavin Andresen suggests extending existing standards instead of reinventing the wheel. He questions whether signature blocks or BIP-10 transactions could be encoded using S/MIME or a "sign a message" standard. The aim is to leverage the work already done by the IETF and ensure interoperability between different implementations.Peter Vessenes emphasizes the need for simplicity in protocol design and warns against adding unnecessary complexity. He suggests a one-year required discussion period for non-security changes to the blockchain protocol and highlights the dangers of cruft over a long period of time.Luke-Jr expresses concerns about adding too many features to Bitcoin and believes that signing messages should be limited to logging into a website. There are discussions on using PGP/EC for signing and verifying messages, but Wladimir cautions against adding unnecessary features and complexity to Bitcoin.Overall, the conversations highlight the importance of improving security measures in Bitcoin transactions while considering simplicity, interoperability, and avoiding unnecessary complexity. The need for standard solutions, like BIP 10, URL signing/authentication, and extending existing standards, is emphasized throughout the discussions. 2012-04-04T08:35:12+00:00 + The email conversations discuss various proposals and concerns related to improving security measures in Bitcoin transactions. Wladimir suggests signing preformatted messages from sites to enhance transaction security. The proposed approach involves creating a 512-bit data structure by taking the sha512 of a document and then taking ripemd160 of hash512. This procedure prevents malicious sites from tricking users into signing transactions spending their own coins.There is also a discussion about the importance of multi-sig technology in Bitcoin transactions. Alan Reiner expresses concern about the complexity of executing multi-sig transactions and suggests that BIP 10 (or successor) is critical for the success of multi-sig. Wladimir agrees with the need for simpler execution of multi-sig and proposes defining URL signing/authentication to make P2SH easier and less involved. He also highlights the issue of URL size limit and suggests a solution to pass the address where the message can be retrieved.In another conversation, Alan Reiner clarifies that his proposal is not about changing the Bitcoin protocol itself but rather an intermediate data format that allows users to sign messages with their existing Bitcoin identities. There are discussions on whether to extend existing standards like PGP/EC or create a new solution. The focus is on simplicity and caution when considering changes to the Bitcoin protocol.Gavin Andresen suggests extending existing standards instead of reinventing the wheel. He questions whether signature blocks or BIP-10 transactions could be encoded using S/MIME or a "sign a message" standard. The aim is to leverage the work already done by the IETF and ensure interoperability between different implementations.Peter Vessenes emphasizes the need for simplicity in protocol design and warns against adding unnecessary complexity. He suggests a one-year required discussion period for non-security changes to the blockchain protocol and highlights the dangers of cruft over a long period of time.Luke-Jr expresses concerns about adding too many features to Bitcoin and believes that signing messages should be limited to logging into a website. There are discussions on using PGP/EC for signing and verifying messages, but Wladimir cautions against adding unnecessary features and complexity to Bitcoin.Overall, the conversations highlight the importance of improving security measures in Bitcoin transactions while considering simplicity, interoperability, and avoiding unnecessary complexity. The need for standard solutions, like BIP 10, URL signing/authentication, and extending existing standards, is emphasized throughout the discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_Trusted-identities.xml b/static/bitcoin-dev/April_2012/combined_Trusted-identities.xml index b31fa19c41..448ef9e5e5 100644 --- a/static/bitcoin-dev/April_2012/combined_Trusted-identities.xml +++ b/static/bitcoin-dev/April_2012/combined_Trusted-identities.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Trusted identities - 2023-08-01T03:27:13.924161+00:00 + 2025-10-11T21:48:08.007188+00:00 + python-feedgen Alan Reiner 2012-04-26 18:00:59+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Trusted identities - 2023-08-01T03:27:13.924161+00:00 + 2025-10-11T21:48:08.007386+00:00 - In a discussion on the Bitcoin network's implementation of replacement transactions, it was confirmed that the feature is currently disabled. Transactions with lock-time in the future and non-maximum sequence number are accepted into nodes' memory pools but will not be included in any block until locktime expires. The "replacement" mechanism is also disabled, meaning that although nodes accept replaceable transactions, they do not allow them to be replaced except for one time by injecting a final transaction into the blockchain.In a 2012 email thread on the Bitcoin-development mailing list, Peter Todd proposed the idea of using the public nature of the blockchain to create trusted identities. He suggested that individuals could establish trust in their bitcoin address identity by creating transactions with large and equal fees, incurring a cost to themselves. This would serve as proof of their trustworthiness and deter double spending. If someone breaks their promise, their signed transaction can be published, destroying the value needed to create their trusted identity. Todd compared this system to a distributed green address system, which would make sybil attacks more difficult as it requires a significant amount of coins to pretend to be multiple identities. He also mentioned the potential use of this system for creating a distributed anonymizer, where bids from trusted identities are accepted.In another email exchange, Peter Vessenes suggested that CoinLab publish a metric for the cost of subverting multiple transactions with 90% probability to better understand the number. They discussed various ways to double-spend in Bitcoin, including using multiple VPS's with different IP addresses and flooding the network faster with multiple nodes. Trusted identities were considered as a way to prevent sybil attacks and provide guarantees of behavior from nodes. The amount of confirmation needed for large-volume transactions was also discussed, noting that increased difficulty shortens the safe time for such transactions. They also inquired about the current implementation of replacement transactions.To summarize, the public nature of the blockchain can be utilized to create trusted identities for financial transactions. By valuing and throwing away resources, individuals can establish trust in their bitcoin address identity. This creates a distributed green address system that allows other users to accept zero-confirmation transactions based on this trust. The system can also be used for a distributed anonymizer, where bids from trusted identities are accepted. This approach makes sybil attacks more difficult and strengthens the Bitcoin network. The current implementation of replacement transactions is disabled, but transactions with lock-time in the future and non-maximum sequence number are accepted into nodes' memory pools and will be included in blocks after locktime expires. 2012-04-26T18:00:59+00:00 + In a discussion on the Bitcoin network's implementation of replacement transactions, it was confirmed that the feature is currently disabled. Transactions with lock-time in the future and non-maximum sequence number are accepted into nodes' memory pools but will not be included in any block until locktime expires. The "replacement" mechanism is also disabled, meaning that although nodes accept replaceable transactions, they do not allow them to be replaced except for one time by injecting a final transaction into the blockchain.In a 2012 email thread on the Bitcoin-development mailing list, Peter Todd proposed the idea of using the public nature of the blockchain to create trusted identities. He suggested that individuals could establish trust in their bitcoin address identity by creating transactions with large and equal fees, incurring a cost to themselves. This would serve as proof of their trustworthiness and deter double spending. If someone breaks their promise, their signed transaction can be published, destroying the value needed to create their trusted identity. Todd compared this system to a distributed green address system, which would make sybil attacks more difficult as it requires a significant amount of coins to pretend to be multiple identities. He also mentioned the potential use of this system for creating a distributed anonymizer, where bids from trusted identities are accepted.In another email exchange, Peter Vessenes suggested that CoinLab publish a metric for the cost of subverting multiple transactions with 90% probability to better understand the number. They discussed various ways to double-spend in Bitcoin, including using multiple VPS's with different IP addresses and flooding the network faster with multiple nodes. Trusted identities were considered as a way to prevent sybil attacks and provide guarantees of behavior from nodes. The amount of confirmation needed for large-volume transactions was also discussed, noting that increased difficulty shortens the safe time for such transactions. They also inquired about the current implementation of replacement transactions.To summarize, the public nature of the blockchain can be utilized to create trusted identities for financial transactions. By valuing and throwing away resources, individuals can establish trust in their bitcoin address identity. This creates a distributed green address system that allows other users to accept zero-confirmation transactions based on this trust. The system can also be used for a distributed anonymizer, where bids from trusted identities are accepted. This approach makes sybil attacks more difficult and strengthens the Bitcoin network. The current implementation of replacement transactions is disabled, but transactions with lock-time in the future and non-maximum sequence number are accepted into nodes' memory pools and will be included in blocks after locktime expires. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2012/combined_new-bitcoin-org-clients-page.xml b/static/bitcoin-dev/April_2012/combined_new-bitcoin-org-clients-page.xml index d9adfeaf0e..aedd1125ef 100644 --- a/static/bitcoin-dev/April_2012/combined_new-bitcoin-org-clients-page.xml +++ b/static/bitcoin-dev/April_2012/combined_new-bitcoin-org-clients-page.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - new bitcoin.org clients page - 2023-08-01T03:29:16.874507+00:00 + 2025-10-11T21:48:05.881494+00:00 + python-feedgen Jorge Timón 2012-05-03 10:25:48+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - new bitcoin.org clients page - 2023-08-01T03:29:16.874507+00:00 + 2025-10-11T21:48:05.881704+00:00 - In a discussion on the Freicoin forum, Andreas Schildbach suggested adding Bitcoin Wallet to the list of smartphone clients. Jorge Timón responded with concerns about the slowness of cell phone apps. Schildbach explained that Bitcoin Wallet is just as fast as any other client after the initial blockchain update. The advantage is that users are not dependent on any server.In an email conversation, Schildbach suggested adding Bitcoin Wallet to the list of cell phone apps. Jorge raised concerns about slowness, but Schildbach clarified that it works just as fast as other clients. On May 3, 2012, Schildbach requested adding Bitcoin Wallet to the list of smartphone clients.An article titled "Reply-To" Munging Considered Harmful discusses the negative effects of changing the "Reply-To" field in email messages. The author argues against this practice, noting potential confusion and loss of important information. The author suggests leaving the original "Reply-To" field intact for clear communication.In an email exchange, Jeff Garzik expresses concerns about Bitcoin.org being too centralized. He proposes creating an independently managed website for Bitcoin clients. The conversation also mentions different Bitcoin clients, their requirements, design, and availability.The email thread discusses the ordering of Bitcoin clients on bitcoin.org. Discussions become messy, and Amir Taaki decides the ordering to prevent exploitation. Gary Rowe proposes simple descriptions for each client, including details like required blockchains and development language. The conversation digresses into email etiquette and issues related to group emails. The thread ends with announcements for a security virtual conference and links to the Bitcoin-development mailing list.The email thread focuses on the comparison of Bitcoin clients such as Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet. Each client is described in terms of requirements, design, availability, and programming language. There is also a discussion on email etiquette and the harmful effects of "Reply-To" munging. The conversation ends with announcements for a security virtual conference and links to the Bitcoin-development mailing list.In an email thread, members discuss creating a webpage for less technically-inclined Bitcoin users. Different Bitcoin clients like Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet are described in terms of requirements, design, and availability. Email etiquette and issues related to group emails are also discussed. The thread ends with a promotion for a live security virtual conference.The email conversation proposes creating a simple webpage for new Bitcoin users, discussing different Bitcoin clients like Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet. Email etiquette is also discussed, along with a link to an article about "Reply-To" munging. The conversation ends with announcements for a live security virtual conference and links to the Bitcoin-development mailing list.The email conversation suggests changes to the Bitcoin.org clients page for better user experience. Different Bitcoin clients are discussed, including their requirements, design, and availability. The conversation also touches on email etiquette and issues related to group emails. The email ends with an invitation to a live security virtual conference.The context discusses various email conversations and exchanges regarding different topics related to email functionality, Bitcoin clients, and the Bitcoin.org website. In one conversation, a writer expresses frustration with default email options when group emailing. They mention using Yahoo mail for spam and mailing lists and finding it difficult to access the 'reply all' option. Jeff Garzik suggests using "Reply to All," but the writer explains its limitations. The conversation also touches on the harmful effects of "Reply-To" Munging.Another email exchange discusses the best way to respond to group emails. Using the "Reply to All" function is recommended, but it can lead to cluttered threads if people don't trim their responses. Using the "reply to" function is suggested as an alternative to ensure only intended recipients receive the response.Bitcoin.org is described as a resource for learning about Bitcoin. Different Bitcoin client options are discussed, including Bitcoin-Qt, MultiBit, Armory, and Electrum, each with their own features and benefits. The importance of language support and sync-up times for these clients is also mentioned.The discussion on running the Bitcoin.org page focuses on maintaining a theme per client while keeping descriptions less technical. The suggestion is made to provide neutral descriptions that highlight strengths and weaknesses and evolve them based on user and developer feedback. Links to client websites and platforms are provided in the descriptions.The conversation between Alan and Mike Hearn clarifies that Bitcoin-Qt was written by Wladimir, not Satoshi Nakamoto. Feedback on descriptions and language support for Bitcoin clients is exchanged. The goal is to provide objective information for users to make informed decisions.There is a mention of changing the initial start time for blockchain sync-up on normal systems and reducing the sync-up time. The importance of refining the system for optimal performance is emphasized.The discussion on the Bitcoin.org clients page involves creating descriptions for each client that emphasize 2012-05-03T10:25:48+00:00 + In a discussion on the Freicoin forum, Andreas Schildbach suggested adding Bitcoin Wallet to the list of smartphone clients. Jorge Timón responded with concerns about the slowness of cell phone apps. Schildbach explained that Bitcoin Wallet is just as fast as any other client after the initial blockchain update. The advantage is that users are not dependent on any server.In an email conversation, Schildbach suggested adding Bitcoin Wallet to the list of cell phone apps. Jorge raised concerns about slowness, but Schildbach clarified that it works just as fast as other clients. On May 3, 2012, Schildbach requested adding Bitcoin Wallet to the list of smartphone clients.An article titled "Reply-To" Munging Considered Harmful discusses the negative effects of changing the "Reply-To" field in email messages. The author argues against this practice, noting potential confusion and loss of important information. The author suggests leaving the original "Reply-To" field intact for clear communication.In an email exchange, Jeff Garzik expresses concerns about Bitcoin.org being too centralized. He proposes creating an independently managed website for Bitcoin clients. The conversation also mentions different Bitcoin clients, their requirements, design, and availability.The email thread discusses the ordering of Bitcoin clients on bitcoin.org. Discussions become messy, and Amir Taaki decides the ordering to prevent exploitation. Gary Rowe proposes simple descriptions for each client, including details like required blockchains and development language. The conversation digresses into email etiquette and issues related to group emails. The thread ends with announcements for a security virtual conference and links to the Bitcoin-development mailing list.The email thread focuses on the comparison of Bitcoin clients such as Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet. Each client is described in terms of requirements, design, availability, and programming language. There is also a discussion on email etiquette and the harmful effects of "Reply-To" munging. The conversation ends with announcements for a security virtual conference and links to the Bitcoin-development mailing list.In an email thread, members discuss creating a webpage for less technically-inclined Bitcoin users. Different Bitcoin clients like Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet are described in terms of requirements, design, and availability. Email etiquette and issues related to group emails are also discussed. The thread ends with a promotion for a live security virtual conference.The email conversation proposes creating a simple webpage for new Bitcoin users, discussing different Bitcoin clients like Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet. Email etiquette is also discussed, along with a link to an article about "Reply-To" munging. The conversation ends with announcements for a live security virtual conference and links to the Bitcoin-development mailing list.The email conversation suggests changes to the Bitcoin.org clients page for better user experience. Different Bitcoin clients are discussed, including their requirements, design, and availability. The conversation also touches on email etiquette and issues related to group emails. The email ends with an invitation to a live security virtual conference.The context discusses various email conversations and exchanges regarding different topics related to email functionality, Bitcoin clients, and the Bitcoin.org website. In one conversation, a writer expresses frustration with default email options when group emailing. They mention using Yahoo mail for spam and mailing lists and finding it difficult to access the 'reply all' option. Jeff Garzik suggests using "Reply to All," but the writer explains its limitations. The conversation also touches on the harmful effects of "Reply-To" Munging.Another email exchange discusses the best way to respond to group emails. Using the "Reply to All" function is recommended, but it can lead to cluttered threads if people don't trim their responses. Using the "reply to" function is suggested as an alternative to ensure only intended recipients receive the response.Bitcoin.org is described as a resource for learning about Bitcoin. Different Bitcoin client options are discussed, including Bitcoin-Qt, MultiBit, Armory, and Electrum, each with their own features and benefits. The importance of language support and sync-up times for these clients is also mentioned.The discussion on running the Bitcoin.org page focuses on maintaining a theme per client while keeping descriptions less technical. The suggestion is made to provide neutral descriptions that highlight strengths and weaknesses and evolve them based on user and developer feedback. Links to client websites and platforms are provided in the descriptions.The conversation between Alan and Mike Hearn clarifies that Bitcoin-Qt was written by Wladimir, not Satoshi Nakamoto. Feedback on descriptions and language support for Bitcoin clients is exchanged. The goal is to provide objective information for users to make informed decisions.There is a mention of changing the initial start time for blockchain sync-up on normal systems and reducing the sync-up time. The importance of refining the system for optimal performance is emphasized.The discussion on the Bitcoin.org clients page involves creating descriptions for each client that emphasize - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_A-mining-pool-at-46-.xml b/static/bitcoin-dev/April_2013/combined_A-mining-pool-at-46-.xml index 3bd2fe8585..f6d6847352 100644 --- a/static/bitcoin-dev/April_2013/combined_A-mining-pool-at-46-.xml +++ b/static/bitcoin-dev/April_2013/combined_A-mining-pool-at-46-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A mining pool at 46% - 2023-08-01T04:36:59.133255+00:00 + 2025-10-11T22:21:00.759004+00:00 + python-feedgen Daryl Tucker 2013-04-08 12:32:30+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - A mining pool at 46% - 2023-08-01T04:36:59.134256+00:00 + 2025-10-11T22:21:00.759185+00:00 - BTC Guild, a prominent Bitcoin mining pool, has proposed a plan to mitigate the risk of malicious attacks on the network. The plan was developed in response to concerns raised by Bitcoin users regarding BTC Guild's significant share of the network, which currently stands at over 40%. If BTC Guild's share surpasses certain thresholds, the proposed measures will be implemented. For instance, if BTC Guild's share reaches 45% or higher, getwork based pools will be removed within 24 hours. Moreover, PPS fees will be raised from 5% to 7%, and PPLNS fees will be increased from 3% to 4% if the share exceeds 40% again. Nevertheless, these fees will be reduced once the pool drops below 40% for more than 72 hours. To ensure the successful execution of the plan, users are expected to actively participate by offering their comments and inquiries on the related forum thread.In an email exchange from April 5th, 2013, Melvin Carvalho discussed the risks associated with double spending in blockchain technology. He specifically raised concerns about the difficulty of rectifying chain vandalism caused by deliberately triggering bugs or inserting illegal data into the chain. This conversation emphasized the importance of addressing vulnerabilities in the underlying technology and increasing the cost for potential attackers engaging in malicious activities.In another email exchange, Mike Hearn argued that attacking Bitcoin's network would ultimately be counterproductive due to the permanent record it would leave behind and the likelihood of miners abandoning the pool responsible for the attack. However, Robert expressed concerns about detecting such attacks, highlighting the limited ability to identify the pool responsible based solely on the source IP disseminating the new block. Additionally, even if end miners discovered the double-spending blocks, they would not necessarily attribute them to the pool operator. Robert suggested that the pool owner could avoid reputational damage by channeling the double-spend blocks through previously unknown IPs repeatedly.In a separate conversation, Melvin Carvalho expressed concerns about a mining pool reaching a 46% share and the potential for a 51% attack. Mike Hearn responded by noting that double-spending against confirmed transactions could occur before reaching the 51% threshold. He also mentioned other risks, such as vandalizing the blockchain or manipulating the price downwards. Hearn proposed alternative mining protocols that enable pooling without allowing the pool operator to select which transactions go into the block. Carvalho previously suggested that a decentralized pool would prevent a 51% attack, but it was pointed out that the pool owner still has control over block composition. The discussion explored the challenges of coordinating a 51% attack through random non-colliding nonces and the possibility of creating one random number and incrementing from there. As Bitcoin's market cap grows, the incentives to manipulate the market are expected to increase. The community acknowledged the limitations of p2pool in dealing with FPGA/ASIC hardware but emphasized that the market would ultimately determine the preferred algorithm, while the community could review and prioritize different mining protocols based on their associated risks.A message thread from April 5th, 2013, touched on the growth and challenges faced by p2pool. Mike Hearn expressed his belief that p2pool had not been growing for a considerable time and struggled with FPGA/ASIC hardware. However, another participant clarified that p2pool worked well with FPGAs and was utilized by one of the largest FPGA farms. The issue lay with BFL FPGA miners and Avalon's latency. The stability of p2pool was affected when ASICminer started mining on BTC Guild and the first Avalons were shipped, leading to a significant network increase. The discussion concluded with a reminder to support individuals working on infrastructure and ensure they have the necessary resources to continue providing free services. It was highlighted that assumptions about these contributors being wealthy Bitcoin veterans were often incorrect.In an email to the Bitcoin development mailing list, Melvin Carvalho expressed concerns about a mining pool reaching 46%, although he acknowledged that the estimates on blockchain.info might not be entirely accurate. The conversation shifted towards the risk of a 51% attack, with Carvalho suggesting that a decentralized pool would prevent such an attack. However, it was highlighted that none of the pools listed on blockchain.info were genuinely decentralized and that pool owners had control over block composition. The primary threat did not lie in pool owners acting maliciously but rather in their systems being hacked or subjected to coercion. Coordinating a 51% attack by the owner might be nearly impossible due to random non-colliding nonces, but miners' propensity for entrusting their hash power to questionable parties without considering the risks was emphasized. It was crucial to understand the nature of the threat, as someone with a significant amount of hash power could replace confirmed blocks with an alternative chain containing different transactions, enabling them to reclaim previously irreversible funds. Even an attacker with only 40% of the hash power could reverse six confirmations with a roughly 2013-04-08T12:32:30+00:00 + BTC Guild, a prominent Bitcoin mining pool, has proposed a plan to mitigate the risk of malicious attacks on the network. The plan was developed in response to concerns raised by Bitcoin users regarding BTC Guild's significant share of the network, which currently stands at over 40%. If BTC Guild's share surpasses certain thresholds, the proposed measures will be implemented. For instance, if BTC Guild's share reaches 45% or higher, getwork based pools will be removed within 24 hours. Moreover, PPS fees will be raised from 5% to 7%, and PPLNS fees will be increased from 3% to 4% if the share exceeds 40% again. Nevertheless, these fees will be reduced once the pool drops below 40% for more than 72 hours. To ensure the successful execution of the plan, users are expected to actively participate by offering their comments and inquiries on the related forum thread.In an email exchange from April 5th, 2013, Melvin Carvalho discussed the risks associated with double spending in blockchain technology. He specifically raised concerns about the difficulty of rectifying chain vandalism caused by deliberately triggering bugs or inserting illegal data into the chain. This conversation emphasized the importance of addressing vulnerabilities in the underlying technology and increasing the cost for potential attackers engaging in malicious activities.In another email exchange, Mike Hearn argued that attacking Bitcoin's network would ultimately be counterproductive due to the permanent record it would leave behind and the likelihood of miners abandoning the pool responsible for the attack. However, Robert expressed concerns about detecting such attacks, highlighting the limited ability to identify the pool responsible based solely on the source IP disseminating the new block. Additionally, even if end miners discovered the double-spending blocks, they would not necessarily attribute them to the pool operator. Robert suggested that the pool owner could avoid reputational damage by channeling the double-spend blocks through previously unknown IPs repeatedly.In a separate conversation, Melvin Carvalho expressed concerns about a mining pool reaching a 46% share and the potential for a 51% attack. Mike Hearn responded by noting that double-spending against confirmed transactions could occur before reaching the 51% threshold. He also mentioned other risks, such as vandalizing the blockchain or manipulating the price downwards. Hearn proposed alternative mining protocols that enable pooling without allowing the pool operator to select which transactions go into the block. Carvalho previously suggested that a decentralized pool would prevent a 51% attack, but it was pointed out that the pool owner still has control over block composition. The discussion explored the challenges of coordinating a 51% attack through random non-colliding nonces and the possibility of creating one random number and incrementing from there. As Bitcoin's market cap grows, the incentives to manipulate the market are expected to increase. The community acknowledged the limitations of p2pool in dealing with FPGA/ASIC hardware but emphasized that the market would ultimately determine the preferred algorithm, while the community could review and prioritize different mining protocols based on their associated risks.A message thread from April 5th, 2013, touched on the growth and challenges faced by p2pool. Mike Hearn expressed his belief that p2pool had not been growing for a considerable time and struggled with FPGA/ASIC hardware. However, another participant clarified that p2pool worked well with FPGAs and was utilized by one of the largest FPGA farms. The issue lay with BFL FPGA miners and Avalon's latency. The stability of p2pool was affected when ASICminer started mining on BTC Guild and the first Avalons were shipped, leading to a significant network increase. The discussion concluded with a reminder to support individuals working on infrastructure and ensure they have the necessary resources to continue providing free services. It was highlighted that assumptions about these contributors being wealthy Bitcoin veterans were often incorrect.In an email to the Bitcoin development mailing list, Melvin Carvalho expressed concerns about a mining pool reaching 46%, although he acknowledged that the estimates on blockchain.info might not be entirely accurate. The conversation shifted towards the risk of a 51% attack, with Carvalho suggesting that a decentralized pool would prevent such an attack. However, it was highlighted that none of the pools listed on blockchain.info were genuinely decentralized and that pool owners had control over block composition. The primary threat did not lie in pool owners acting maliciously but rather in their systems being hacked or subjected to coercion. Coordinating a 51% attack by the owner might be nearly impossible due to random non-colliding nonces, but miners' propensity for entrusting their hash power to questionable parties without considering the risks was emphasized. It was crucial to understand the nature of the threat, as someone with a significant amount of hash power could replace confirmed blocks with an alternative chain containing different transactions, enabling them to reclaim previously irreversible funds. Even an attacker with only 40% of the hash power could reverse six confirmations with a roughly - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Anti-DoS-for-tx-replacement.xml b/static/bitcoin-dev/April_2013/combined_Anti-DoS-for-tx-replacement.xml index 2d4a8b48ab..9e8225cddd 100644 --- a/static/bitcoin-dev/April_2013/combined_Anti-DoS-for-tx-replacement.xml +++ b/static/bitcoin-dev/April_2013/combined_Anti-DoS-for-tx-replacement.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Anti DoS for tx replacement - 2023-08-01T04:40:35.555673+00:00 + 2025-10-11T22:20:48.011478+00:00 + python-feedgen Peter Todd 2013-07-18 16:09:54+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Anti DoS for tx replacement - 2023-08-01T04:40:35.556670+00:00 + 2025-10-11T22:20:48.011649+00:00 - In an email exchange on July 18, 2013, Peter Todd suggests using the OP_DEPTH instruction to eliminate the risk of funds getting stuck in limbo. This opcode returns the current depth of the script's execution stack and can validate certain operations. However, Jeff Garzik raises concerns about scripts no longer being stateless due to the introduction of OP_DEPTH.Jeremy Spilman proposes a negotiation between the user and Arbitration Provider (AP) to determine escrow amounts, fee payments, and the duration of funds being tied if the AP doesn't close the channel. The implementation of OP_DEPTH can be done as part of a script v2 using the soft-fork mechanism outlined by Peter Todd. It is also suggested that MAST support should be implemented at the same time.A member on the Bitcoin-development mailing list commends Jeremy and Peter for creating a design that does not rely on replacement to work. This approach is seen as a solution to scalability issues without compromising security. However, Jeremy points out that the proposal could still have malleability weaknesses, where a miner changing the TxID of TX1 could invalidate the user's refund.The proposed sequence for Bitcoin channels involves multiple steps, such as creating unsigned transactions, negotiating escrow amounts, and setting lock times. The alternative to transaction replacement is having a trusted third party close the channel based on the latest transaction sent by the user. Concerns are raised about attackers and the need for mutual defense actions.Gavin Andresen suggests weakening the non-standard test to allow a window of time before transactions are deemed untrustworthy. He also mentions other technical issues that need to be addressed, such as implementing a memory-limited pool and child-pays-for-parent fees.Discussions about denial-of-service (DoS) attacks include proposals to incorporate bandwidth into contracts and implement fidelity bonds for security guarantees. The processing speed of ECDSA on modern cores and the possibility of double-spending in Bitcoin are also mentioned.In another email exchange, Peter Todd discusses the limitations and potential issues with transaction replacement on the Bitcoin network. Mike Hearn suggests ways to mitigate DoS attacks related to transaction replacement, such as limiting the number of chances for each input to do a replacement. The importance of protecting against DoS attacks without sacrificing features is debated.John Dillon questions Gavin Andresen's stance on Bitcoin security, while others defend his efforts to resist DoS attacks and improve testing and payment protocol implementation. The concept of high-frequency trading using transaction replacement is discussed, along with proposals to mitigate associated risks.Mike Hearn proposes a way to mitigate the risks of transaction replacement, suggesting that handling DoS as a prioritization problem and allowing someone to force CPU/bandwidth usage without disrupting normal transactions.The discussion on re-activating the replacement feature on Bitcoin's main network includes suggestions for developers to utilize and build apps demonstrating its usefulness and developing prototypes before re-activation. 2013-07-18T16:09:54+00:00 + In an email exchange on July 18, 2013, Peter Todd suggests using the OP_DEPTH instruction to eliminate the risk of funds getting stuck in limbo. This opcode returns the current depth of the script's execution stack and can validate certain operations. However, Jeff Garzik raises concerns about scripts no longer being stateless due to the introduction of OP_DEPTH.Jeremy Spilman proposes a negotiation between the user and Arbitration Provider (AP) to determine escrow amounts, fee payments, and the duration of funds being tied if the AP doesn't close the channel. The implementation of OP_DEPTH can be done as part of a script v2 using the soft-fork mechanism outlined by Peter Todd. It is also suggested that MAST support should be implemented at the same time.A member on the Bitcoin-development mailing list commends Jeremy and Peter for creating a design that does not rely on replacement to work. This approach is seen as a solution to scalability issues without compromising security. However, Jeremy points out that the proposal could still have malleability weaknesses, where a miner changing the TxID of TX1 could invalidate the user's refund.The proposed sequence for Bitcoin channels involves multiple steps, such as creating unsigned transactions, negotiating escrow amounts, and setting lock times. The alternative to transaction replacement is having a trusted third party close the channel based on the latest transaction sent by the user. Concerns are raised about attackers and the need for mutual defense actions.Gavin Andresen suggests weakening the non-standard test to allow a window of time before transactions are deemed untrustworthy. He also mentions other technical issues that need to be addressed, such as implementing a memory-limited pool and child-pays-for-parent fees.Discussions about denial-of-service (DoS) attacks include proposals to incorporate bandwidth into contracts and implement fidelity bonds for security guarantees. The processing speed of ECDSA on modern cores and the possibility of double-spending in Bitcoin are also mentioned.In another email exchange, Peter Todd discusses the limitations and potential issues with transaction replacement on the Bitcoin network. Mike Hearn suggests ways to mitigate DoS attacks related to transaction replacement, such as limiting the number of chances for each input to do a replacement. The importance of protecting against DoS attacks without sacrificing features is debated.John Dillon questions Gavin Andresen's stance on Bitcoin security, while others defend his efforts to resist DoS attacks and improve testing and payment protocol implementation. The concept of high-frequency trading using transaction replacement is discussed, along with proposals to mitigate associated risks.Mike Hearn proposes a way to mitigate the risks of transaction replacement, suggesting that handling DoS as a prioritization problem and allowing someone to force CPU/bandwidth usage without disrupting normal transactions.The discussion on re-activating the replacement feature on Bitcoin's main network includes suggestions for developers to utilize and build apps demonstrating its usefulness and developing prototypes before re-activation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_BIP21-bitcoin-URIs-and-HTML5.xml b/static/bitcoin-dev/April_2013/combined_BIP21-bitcoin-URIs-and-HTML5.xml index e2b5869c1f..951ee9b943 100644 --- a/static/bitcoin-dev/April_2013/combined_BIP21-bitcoin-URIs-and-HTML5.xml +++ b/static/bitcoin-dev/April_2013/combined_BIP21-bitcoin-URIs-and-HTML5.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP21 bitcoin URIs and HTML5 - 2023-08-01T04:42:27.320613+00:00 + 2025-10-11T22:20:33.139176+00:00 + python-feedgen Mike Hearn 2013-05-02 12:53:38+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - BIP21 bitcoin URIs and HTML5 - 2023-08-01T04:42:27.320613+00:00 + 2025-10-11T22:20:33.139365+00:00 - In an email conversation on April 24, 2013, Gavin Andresen and Ian discussed errors in the BIP21 spec for bitcoin: URIs. Gavin inquired about the process for amending the BIP and suggested fixing the issues without creating a new one. This approach was supported by Gregory Maxwell, as long as the corrections were not gratuitously incompatible.HTML5 now allows web apps to register themselves for handling URI schemes, including the bitcoin: URI used in the payment protocol. However, there is a whitelist of acceptable schemes for security reasons. The good news is that bitcoin has been added to the whitelist by Hixie, and browsers should soon be able to accept bitcoin as a web-app handleable protocol scheme.Ian identified errors in the BIP21 spec, including missing character set definition, undefined separator, incorrect syntax, and referencing "pchar" without definition. The process for amending the BIP was questioned, with suggestions of creating a new BIP or fixing the errors in place due to their exotic nature. No consensus has been reached yet.Additionally, the IETF URL specs are being replaced by http://url.spec.whatwg.org/ for Web purposes. Improvement of the URL spec is encouraged, as it is important for the value proposition of the Web. 2013-05-02T12:53:38+00:00 + In an email conversation on April 24, 2013, Gavin Andresen and Ian discussed errors in the BIP21 spec for bitcoin: URIs. Gavin inquired about the process for amending the BIP and suggested fixing the issues without creating a new one. This approach was supported by Gregory Maxwell, as long as the corrections were not gratuitously incompatible.HTML5 now allows web apps to register themselves for handling URI schemes, including the bitcoin: URI used in the payment protocol. However, there is a whitelist of acceptable schemes for security reasons. The good news is that bitcoin has been added to the whitelist by Hixie, and browsers should soon be able to accept bitcoin as a web-app handleable protocol scheme.Ian identified errors in the BIP21 spec, including missing character set definition, undefined separator, incorrect syntax, and referencing "pchar" without definition. The process for amending the BIP was questioned, with suggestions of creating a new BIP or fixing the errors in place due to their exotic nature. No consensus has been reached yet.Additionally, the IETF URL specs are being replaced by http://url.spec.whatwg.org/ for Web purposes. Improvement of the URL spec is encouraged, as it is important for the value proposition of the Web. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Bitcoin-meets-the-Semantic-Web-.xml b/static/bitcoin-dev/April_2013/combined_Bitcoin-meets-the-Semantic-Web-.xml index ddd3566128..b9b5581823 100644 --- a/static/bitcoin-dev/April_2013/combined_Bitcoin-meets-the-Semantic-Web-.xml +++ b/static/bitcoin-dev/April_2013/combined_Bitcoin-meets-the-Semantic-Web-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin meets the Semantic Web.... - 2023-08-01T04:35:32.733838+00:00 + 2025-10-11T22:20:52.261960+00:00 + python-feedgen Melvin Carvalho 2013-10-11 11:27:49+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Bitcoin meets the Semantic Web.... - 2023-08-01T04:35:32.733838+00:00 + 2025-10-11T22:20:52.262130+00:00 - Melvin Carvalho is working on porting crypto currencies to the semantic web, allowing new types of innovation and spreading bitcoin information to a wider audience. The first step is to create a "vocabulary" for bitcoin, which is like a dictionary of terms that can be put down in a machine-readable standard called RDF. To do this, he asks if anyone has worked on this before or if there is a human readable "glossary" for bitcoin that he could take text from. He has made a start on creating the vocabulary and is hosting it at https://w3id.org/cc.During a discussion on April 1st, 2013 about hosting schemas for Bitcoin on the internet, Melvin Carvalho suggested using bitcoin.org, but noted that it lacked https and Github does not allow for setting mime types. Another participant in the discussion suggested using a subdomain such as schema.bitcoin.org to point to an independently run server for the files. The suggestion was made to address the issue of security and effective management of the files.In an email exchange between Harald Schilly and Melvin Carvalho on April 1, 2013, the discussion centered around creating a "vocabulary" for Bitcoin. Schilly suggested checking existing databases like OKFN and searching for existing vocabularies for payments rather than reinventing it. He provided links to various payment protocols such as http://schema.org/PaymentMethod, http://www.heppnetz.de/ontologies/goodrelations/v1#PayPal, and http://lov.okfn.org/dataset/lov/search/#s=payment. Carvalho was already familiar with most of this work and planned to reuse as much as possible, but some terms would be Bitcoin specific. He found https://en.bitcoin.it/wiki/Bitcoin_glossary and wondered where to host it. Schilly gave three ideas for hosting: bitcoin.org, w3id.org, and bitcoin.it wiki.The use case for modeling all crypto currencies, starting with bitcoin, is that a publisher would like to link their web page content or app to a bitcoin address so that donations can be received by those who have enjoyed their work. The model will be something like URI -> crypto-currency-address -> bitcoin-address and the folks at w3id.org have offered to use their permanent identifier switchboard, then redirect to a locked-down vocabulary. As an implementer, one simply needs to add a single rel= tag to their markup. In a web page or HTML5 app, one can use href="bitcoin:1234....". For litecoins (coming soon), one can use href="....">. It's just a small step to start with but can allow all sorts of entities to start accepting bitcoin in a way that complies with the W3C best practices. Melvin will be improving and extending this over time and feedback or help is welcome.In conclusion, Melvin Carvalho is working on porting crypto currencies to the semantic web by creating a vocabulary for bitcoin in machine-readable format. He is seeking input and assistance from others who have experience in this area. During discussions, suggestions were made to host the schemas for Bitcoin on independent servers to address security concerns. Additionally, existing databases such as OKFN were recommended to search for established vocabularies for payments. The ultimate goal is to enable web pages and apps to link to bitcoin addresses for receiving donations, thereby promoting wider acceptance of bitcoin. 2013-10-11T11:27:49+00:00 + Melvin Carvalho is working on porting crypto currencies to the semantic web, allowing new types of innovation and spreading bitcoin information to a wider audience. The first step is to create a "vocabulary" for bitcoin, which is like a dictionary of terms that can be put down in a machine-readable standard called RDF. To do this, he asks if anyone has worked on this before or if there is a human readable "glossary" for bitcoin that he could take text from. He has made a start on creating the vocabulary and is hosting it at https://w3id.org/cc.During a discussion on April 1st, 2013 about hosting schemas for Bitcoin on the internet, Melvin Carvalho suggested using bitcoin.org, but noted that it lacked https and Github does not allow for setting mime types. Another participant in the discussion suggested using a subdomain such as schema.bitcoin.org to point to an independently run server for the files. The suggestion was made to address the issue of security and effective management of the files.In an email exchange between Harald Schilly and Melvin Carvalho on April 1, 2013, the discussion centered around creating a "vocabulary" for Bitcoin. Schilly suggested checking existing databases like OKFN and searching for existing vocabularies for payments rather than reinventing it. He provided links to various payment protocols such as http://schema.org/PaymentMethod, http://www.heppnetz.de/ontologies/goodrelations/v1#PayPal, and http://lov.okfn.org/dataset/lov/search/#s=payment. Carvalho was already familiar with most of this work and planned to reuse as much as possible, but some terms would be Bitcoin specific. He found https://en.bitcoin.it/wiki/Bitcoin_glossary and wondered where to host it. Schilly gave three ideas for hosting: bitcoin.org, w3id.org, and bitcoin.it wiki.The use case for modeling all crypto currencies, starting with bitcoin, is that a publisher would like to link their web page content or app to a bitcoin address so that donations can be received by those who have enjoyed their work. The model will be something like URI -> crypto-currency-address -> bitcoin-address and the folks at w3id.org have offered to use their permanent identifier switchboard, then redirect to a locked-down vocabulary. As an implementer, one simply needs to add a single rel= tag to their markup. In a web page or HTML5 app, one can use href="bitcoin:1234....". For litecoins (coming soon), one can use href="....">. It's just a small step to start with but can allow all sorts of entities to start accepting bitcoin in a way that complies with the W3C best practices. Melvin will be improving and extending this over time and feedback or help is welcome.In conclusion, Melvin Carvalho is working on porting crypto currencies to the semantic web by creating a vocabulary for bitcoin in machine-readable format. He is seeking input and assistance from others who have experience in this area. During discussions, suggestions were made to host the schemas for Bitcoin on independent servers to address security concerns. Additionally, existing databases such as OKFN were recommended to search for established vocabularies for payments. The ultimate goal is to enable web pages and apps to link to bitcoin addresses for receiving donations, thereby promoting wider acceptance of bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Cold-Signing-Payment-Requests.xml b/static/bitcoin-dev/April_2013/combined_Cold-Signing-Payment-Requests.xml index f946985a03..389e516e12 100644 --- a/static/bitcoin-dev/April_2013/combined_Cold-Signing-Payment-Requests.xml +++ b/static/bitcoin-dev/April_2013/combined_Cold-Signing-Payment-Requests.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Cold Signing Payment Requests - 2023-08-01T04:43:53.582572+00:00 + 2025-10-11T22:20:54.390177+00:00 + python-feedgen Peter Todd 2013-05-06 21:29:59+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Cold Signing Payment Requests - 2023-08-01T04:43:53.582572+00:00 + 2025-10-11T22:20:54.390381+00:00 - In a series of email exchanges, discussions surrounding the security and functionality of Bitcoin payment protocols are explored. One concern is the potential risks associated with compromised web servers and the need to protect refund addresses. It is suggested that archiving key documentation on archive.org could help ward off potential patent threats in the future. The challenges faced by merchants regarding missed payments and server vulnerabilities are also discussed.The threat of malware-compromised hosts and the potential redirection of payments is another area of concern. The complexities involved in handling errors during payment posting and the need for secure channels to obtain cryptographic identities are examined. Code review and testing for version updates are highlighted as a bottleneck in the development process. Suggestions are made for protecting pay-to addresses in case of web server compromise, such as using different types of certificates and encoding pubKeys or fingerprints.The limitations of SSL PKI and the challenges of obtaining a more trusted payment request signing key than an SSL key are covered. The difficulties in implementing offline intermediate certificates are also discussed. The proposal to sign payment requests with keys kept offline is considered, with debates on the feasibility and effectiveness of chaining custom certificates onto SSL certificates.Another discussion on bitcointalk.org suggests using x509 certificates to sign Payment Requests to enhance verification and prevent address tampering. However, generating live Payment Requests exposes the signing key to potential theft. A solution is proposed involving a two-tier certificate system, where a 'parent' certificate is kept offline and a 'child' certificate is used for live signing. This approach ensures that the payer can verify the address in the payment request belongs to the intended recipient.To implement this solution, the Payment Protocol utilizes x509 certificates to sign payment requests, allowing wallets to display metadata from the certificate. However, the key used to sign these requests is vulnerable to theft. To mitigate this risk, the proposed two-tier certificate system is explained, where the parent certificate is kept offline and the child certificate is used for live signing on the payment server.While this solution offers improved security, there is a need for established conventions to identify which certificate is the 'most trusted' and which is the 'less trusted'. Alternative ideas are needed for better identification. However, if merchants can keep the key used for signing the address offline, several benefits can be gained, such as enhanced verification and protection against address tampering. 2013-05-06T21:29:59+00:00 + In a series of email exchanges, discussions surrounding the security and functionality of Bitcoin payment protocols are explored. One concern is the potential risks associated with compromised web servers and the need to protect refund addresses. It is suggested that archiving key documentation on archive.org could help ward off potential patent threats in the future. The challenges faced by merchants regarding missed payments and server vulnerabilities are also discussed.The threat of malware-compromised hosts and the potential redirection of payments is another area of concern. The complexities involved in handling errors during payment posting and the need for secure channels to obtain cryptographic identities are examined. Code review and testing for version updates are highlighted as a bottleneck in the development process. Suggestions are made for protecting pay-to addresses in case of web server compromise, such as using different types of certificates and encoding pubKeys or fingerprints.The limitations of SSL PKI and the challenges of obtaining a more trusted payment request signing key than an SSL key are covered. The difficulties in implementing offline intermediate certificates are also discussed. The proposal to sign payment requests with keys kept offline is considered, with debates on the feasibility and effectiveness of chaining custom certificates onto SSL certificates.Another discussion on bitcointalk.org suggests using x509 certificates to sign Payment Requests to enhance verification and prevent address tampering. However, generating live Payment Requests exposes the signing key to potential theft. A solution is proposed involving a two-tier certificate system, where a 'parent' certificate is kept offline and a 'child' certificate is used for live signing. This approach ensures that the payer can verify the address in the payment request belongs to the intended recipient.To implement this solution, the Payment Protocol utilizes x509 certificates to sign payment requests, allowing wallets to display metadata from the certificate. However, the key used to sign these requests is vulnerable to theft. To mitigate this risk, the proposed two-tier certificate system is explained, where the parent certificate is kept offline and the child certificate is used for live signing on the payment server.While this solution offers improved security, there is a need for established conventions to identify which certificate is the 'most trusted' and which is the 'less trusted'. Alternative ideas are needed for better identification. However, if merchants can keep the key used for signing the address offline, several benefits can be gained, such as enhanced verification and protection against address tampering. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_DOS-Attacks-on-bitcoin-client-.xml b/static/bitcoin-dev/April_2013/combined_DOS-Attacks-on-bitcoin-client-.xml index 02c9424d3c..fad5914933 100644 --- a/static/bitcoin-dev/April_2013/combined_DOS-Attacks-on-bitcoin-client-.xml +++ b/static/bitcoin-dev/April_2013/combined_DOS-Attacks-on-bitcoin-client-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DOS-Attacks on bitcoin-client? - 2023-08-01T04:37:36.856433+00:00 + 2025-10-11T22:21:05.006998+00:00 + python-feedgen Jeff Garzik 2013-04-08 05:42:39+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - DOS-Attacks on bitcoin-client? - 2023-08-01T04:37:36.856433+00:00 + 2025-10-11T22:21:05.007149+00:00 - Jeff Garzik, former Bitcoin Core employee and current CEO of Bloq, suggests using the blockchain torrent to reduce download bandwidth from P2P networks. The Bitcoin blockchain data torrent can be found on the Bitcointalk forum and is a useful tool for those looking to offload their download bandwidth (source).On April 7th, 2013, a user named Scott Howard raised concerns about the lack of throttling mechanism in the reference client used for downloading the entire blockchain from peers. This issue caused users to quickly consume their bandwidth. Howard suggested that users try Quality of Service (QoS) on their routers or use the -nolisten command line flag to avoid this problem (source). Another user named Oliver responded, stating that he had successfully downloaded the blockchain again after making a clean start due to the new database structure. He expressed gratitude towards Scott Howard for his quick help and said he would return if the issue occurred again (source).Oliver Egginger, a user of the Bitcoin-qt client version 0.8.1, reported to the developers that he occasionally experiences an excessive amount of traffic from other nodes while using the client. Although he has not had time to thoroughly investigate the issue, he has noticed it using tshark. In response, the developers mentioned that many new users are utilizing the reference client, which downloads the whole blockchain from peers without a throttling mechanism. They recommend trying QoS on the router or using the -nolisten command line flag to prevent excessive bandwidth consumption. The -nolisten option allows for transaction relaying without serving the entire blockchain. They also mentioned a related GitHub issue for further information (source).In his inquiry, Oliver seeks information about Distributed Denial-of-Service (DDoS) attacks, as he suspects it may be related to the large amounts of traffic from other nodes. He mentions occasionally restarting the client in the hopes of avoiding the node causing the traffic (source). 2013-04-08T05:42:39+00:00 + Jeff Garzik, former Bitcoin Core employee and current CEO of Bloq, suggests using the blockchain torrent to reduce download bandwidth from P2P networks. The Bitcoin blockchain data torrent can be found on the Bitcointalk forum and is a useful tool for those looking to offload their download bandwidth (source).On April 7th, 2013, a user named Scott Howard raised concerns about the lack of throttling mechanism in the reference client used for downloading the entire blockchain from peers. This issue caused users to quickly consume their bandwidth. Howard suggested that users try Quality of Service (QoS) on their routers or use the -nolisten command line flag to avoid this problem (source). Another user named Oliver responded, stating that he had successfully downloaded the blockchain again after making a clean start due to the new database structure. He expressed gratitude towards Scott Howard for his quick help and said he would return if the issue occurred again (source).Oliver Egginger, a user of the Bitcoin-qt client version 0.8.1, reported to the developers that he occasionally experiences an excessive amount of traffic from other nodes while using the client. Although he has not had time to thoroughly investigate the issue, he has noticed it using tshark. In response, the developers mentioned that many new users are utilizing the reference client, which downloads the whole blockchain from peers without a throttling mechanism. They recommend trying QoS on the router or using the -nolisten command line flag to prevent excessive bandwidth consumption. The -nolisten option allows for transaction relaying without serving the entire blockchain. They also mentioned a related GitHub issue for further information (source).In his inquiry, Oliver seeks information about Distributed Denial-of-Service (DDoS) attacks, as he suspects it may be related to the large amounts of traffic from other nodes. He mentions occasionally restarting the client in the hopes of avoiding the node causing the traffic (source). - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Fwd-Service-bits-for-pruned-nodes.xml b/static/bitcoin-dev/April_2013/combined_Fwd-Service-bits-for-pruned-nodes.xml index 0f725f2928..a292b088c0 100644 --- a/static/bitcoin-dev/April_2013/combined_Fwd-Service-bits-for-pruned-nodes.xml +++ b/static/bitcoin-dev/April_2013/combined_Fwd-Service-bits-for-pruned-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Service bits for pruned nodes - 2023-08-01T04:47:47.414158+00:00 + 2025-10-11T22:20:41.641323+00:00 + python-feedgen Andy Parkins 2013-05-01 14:34:27+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Fwd: Service bits for pruned nodes - 2023-08-01T04:47:47.414158+00:00 + 2025-10-11T22:20:41.641496+00:00 - On May 1, 2013, Jeff Garzik proposed the idea of a generalized HTTP REST query protocol in an email. He acknowledged that it was off-topic for the current thread but suggested discussing it separately. In the same email, he provided a link to a pull request he wrote for an HTTP REST interface that downloads an encrypted wallet backup. Dr. Andy Parkins responded to Garzik's email, expressing his belief that Garzik was behind the state-of-the-art and should trust the development team's plans. They then discussed the storage format for Bitcoin protocol blocks. Garzik argued for storing blocks in their native P2P wire protocol format, while Parkins suggested parsing and separating blocks into database fields instead of duplicating bitcoind. Garzik noted that Parkins' proposal would require expanding blocks from their native form into a larger form, which would be extra work for clients downloading blocks. Garzik also mentioned that they had previously discussed an HTTP query interface as a separate topic.In another email thread, Garzik defended the storage format of Bitcoin protocol blocks, stating that it was the most efficient and supported format for multiple applications. A member of the group proposed adding support for more Bitcoin-protocol-oriented HTTP requests to allow any client to supply the same interface. Garzik disagreed, saying that this would require a whole new client interface and was outside the scope of an efficient HTTP protocol for downloading blocks. The member then suggested adding another thread listening for HTTP requests, but Garzik disagreed again.Garzik and Parkins had a conversation about the storage format for Bitcoin protocol blocks. Garzik suggested using the format currently used by bitcoind, arguing that it was a generic format supported in multiple applications. Parkins felt this was too specific to bitcoind and proposed supporting more bitcoin-protocol-oriented HTTP requests. He suggested using URLs for block, transaction, orphaned transaction, peers, and peer requests. Garzik responded that Parkins' proposal was closer to a full P2P rewrite over HTTP or a proxy thereof. They also discussed finding the ideal domain name for caching content and enhancing bitcoind to respond to HTTP.On April 30, 2013, Garzik suggested using the format currently used by bitcoind for raw data storage. He recommended adding a small metadata download and serving raw block files. Parkins disagreed, stating that this approach was not generic and too closely tied to bitcoind's current storage format. Instead, he proposed adding support for more bitcoin-protocol-oriented HTTP requests. This would create a block explorer's raw mode in every bitcoind, making it easier for light clients to find the block containing a particular transaction. Parkins also requested support for HTTP POST/PUT of signed transactions and block announcements.In response to a suggestion for an HTTP/HTTPS protocol for block downloading, Garzik expressed support for finding new ways to store and transmit blocks. However, he mentioned issues with large files when using HTTP and emphasized the need for well-defined HTTP-retrievable layout with proper headers for web caches to function properly. Garzik suggested using bitcoind's format for raw data, limiting the size to below 1GB, and adding a small metadata download to serve the raw block files. 2013-05-01T14:34:27+00:00 + On May 1, 2013, Jeff Garzik proposed the idea of a generalized HTTP REST query protocol in an email. He acknowledged that it was off-topic for the current thread but suggested discussing it separately. In the same email, he provided a link to a pull request he wrote for an HTTP REST interface that downloads an encrypted wallet backup. Dr. Andy Parkins responded to Garzik's email, expressing his belief that Garzik was behind the state-of-the-art and should trust the development team's plans. They then discussed the storage format for Bitcoin protocol blocks. Garzik argued for storing blocks in their native P2P wire protocol format, while Parkins suggested parsing and separating blocks into database fields instead of duplicating bitcoind. Garzik noted that Parkins' proposal would require expanding blocks from their native form into a larger form, which would be extra work for clients downloading blocks. Garzik also mentioned that they had previously discussed an HTTP query interface as a separate topic.In another email thread, Garzik defended the storage format of Bitcoin protocol blocks, stating that it was the most efficient and supported format for multiple applications. A member of the group proposed adding support for more Bitcoin-protocol-oriented HTTP requests to allow any client to supply the same interface. Garzik disagreed, saying that this would require a whole new client interface and was outside the scope of an efficient HTTP protocol for downloading blocks. The member then suggested adding another thread listening for HTTP requests, but Garzik disagreed again.Garzik and Parkins had a conversation about the storage format for Bitcoin protocol blocks. Garzik suggested using the format currently used by bitcoind, arguing that it was a generic format supported in multiple applications. Parkins felt this was too specific to bitcoind and proposed supporting more bitcoin-protocol-oriented HTTP requests. He suggested using URLs for block, transaction, orphaned transaction, peers, and peer requests. Garzik responded that Parkins' proposal was closer to a full P2P rewrite over HTTP or a proxy thereof. They also discussed finding the ideal domain name for caching content and enhancing bitcoind to respond to HTTP.On April 30, 2013, Garzik suggested using the format currently used by bitcoind for raw data storage. He recommended adding a small metadata download and serving raw block files. Parkins disagreed, stating that this approach was not generic and too closely tied to bitcoind's current storage format. Instead, he proposed adding support for more bitcoin-protocol-oriented HTTP requests. This would create a block explorer's raw mode in every bitcoind, making it easier for light clients to find the block containing a particular transaction. Parkins also requested support for HTTP POST/PUT of signed transactions and block announcements.In response to a suggestion for an HTTP/HTTPS protocol for block downloading, Garzik expressed support for finding new ways to store and transmit blocks. However, he mentioned issues with large files when using HTTP and emphasized the need for well-defined HTTP-retrievable layout with proper headers for web caches to function properly. Garzik suggested using bitcoind's format for raw data, limiting the size to below 1GB, and adding a small metadata download to serve the raw block files. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Hardware-BitCoin-wallet-as-part-of-Google-Summer-of-Code.xml b/static/bitcoin-dev/April_2013/combined_Hardware-BitCoin-wallet-as-part-of-Google-Summer-of-Code.xml index 903c689a84..59ff6fc6cb 100644 --- a/static/bitcoin-dev/April_2013/combined_Hardware-BitCoin-wallet-as-part-of-Google-Summer-of-Code.xml +++ b/static/bitcoin-dev/April_2013/combined_Hardware-BitCoin-wallet-as-part-of-Google-Summer-of-Code.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hardware BitCoin wallet as part of Google Summer of Code - 2023-08-01T04:47:23.266132+00:00 + 2025-10-11T22:20:58.637297+00:00 + python-feedgen Michael Gronager 2013-04-29 16:50:59+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Hardware BitCoin wallet as part of Google Summer of Code - 2023-08-01T04:47:23.266132+00:00 + 2025-10-11T22:20:58.637463+00:00 - Crypto Stick, an open-source USB key for encryption and secure authentication, has been accepted as a mentor organization for Google Summer of Code (GSOC) 2013. One of their project ideas is to develop a physical Bitcoin wallet based on the Smart Card Wallet concept. This project aims to create a hardware wallet that can securely store private keys for Bitcoin transactions. However, there are certain challenges that need to be addressed. Peter Todd, a member of the Bitcoin-development mailing list, highlighted the need for a display on hardware Bitcoin wallets. This display would allow the wallet to show where the coins being signed are being sent. Additionally, support for the upcoming payment protocol would be necessary to verify that the address is actually the intended recipient's address.The current Crypto Stick hardware does not have a button for user interaction, which further complicates the development of a physical Bitcoin wallet. Todd acknowledged that PGP smart cards and USB keys already face similar problems, but the consequences of signing the wrong document are usually less severe than sending funds to a thief. Despite these challenges, Todd expressed excitement at the possibility of adding ECC key support to the Crypto Stick in the future.The original post in the Bitcoin-development mailing list included a link to the opencryptotoken project, which offers ECC capabilities and is based on an Atmel microcontroller. The suggestion was made that adding a display to the Crypto Stick would be straightforward using this project as a reference.In addition to the discussion on the development of a physical Bitcoin wallet, the email thread also included a promotion for New Relic, a SaaS-based application performance monitoring service. This promotion was unrelated to the main topic of conversation.Overall, the development of a physical Bitcoin wallet using the Crypto Stick as a base presents both technical challenges and exciting possibilities for enhancing the security and usability of hardware wallets. Interested students can apply for this project through Google Melange until May 3rd, and if accepted, will receive mentoring and financial support from Google. 2013-04-29T16:50:59+00:00 + Crypto Stick, an open-source USB key for encryption and secure authentication, has been accepted as a mentor organization for Google Summer of Code (GSOC) 2013. One of their project ideas is to develop a physical Bitcoin wallet based on the Smart Card Wallet concept. This project aims to create a hardware wallet that can securely store private keys for Bitcoin transactions. However, there are certain challenges that need to be addressed. Peter Todd, a member of the Bitcoin-development mailing list, highlighted the need for a display on hardware Bitcoin wallets. This display would allow the wallet to show where the coins being signed are being sent. Additionally, support for the upcoming payment protocol would be necessary to verify that the address is actually the intended recipient's address.The current Crypto Stick hardware does not have a button for user interaction, which further complicates the development of a physical Bitcoin wallet. Todd acknowledged that PGP smart cards and USB keys already face similar problems, but the consequences of signing the wrong document are usually less severe than sending funds to a thief. Despite these challenges, Todd expressed excitement at the possibility of adding ECC key support to the Crypto Stick in the future.The original post in the Bitcoin-development mailing list included a link to the opencryptotoken project, which offers ECC capabilities and is based on an Atmel microcontroller. The suggestion was made that adding a display to the Crypto Stick would be straightforward using this project as a reference.In addition to the discussion on the development of a physical Bitcoin wallet, the email thread also included a promotion for New Relic, a SaaS-based application performance monitoring service. This promotion was unrelated to the main topic of conversation.Overall, the development of a physical Bitcoin wallet using the Crypto Stick as a base presents both technical challenges and exciting possibilities for enhancing the security and usability of hardware wallets. Interested students can apply for this project through Google Melange until May 3rd, and if accepted, will receive mentoring and financial support from Google. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Integration-testing-for-BitCoin.xml b/static/bitcoin-dev/April_2013/combined_Integration-testing-for-BitCoin.xml index 567f99e149..0a5dfe9b07 100644 --- a/static/bitcoin-dev/April_2013/combined_Integration-testing-for-BitCoin.xml +++ b/static/bitcoin-dev/April_2013/combined_Integration-testing-for-BitCoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Integration testing for BitCoin - 2023-08-01T04:37:20.972200+00:00 + 2025-10-11T22:20:50.137033+00:00 + python-feedgen Adam Ritter 2013-04-07 13:50:01+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Integration testing for BitCoin - 2023-08-01T04:37:20.973195+00:00 + 2025-10-11T22:20:50.137217+00:00 - Adam Ritter and Gregory Maxwell, members of the Bitcoin community, have discussed the importance of integration testing for Bitcoin's future development. Ritter emphasized the need to make the code more stable and test attack scenarios, refactoring, and extending code. Maxwell suggested calling these tests "system tests" and recommended using blocktester, a system based on BitcoinJ that simulates a peer against a slightly instrumented copy of Bitcoin (d/-qt). Blocktester runs complicated network scenarios and tests the boundaries of blockchain validation protocol rules, and is used as part of the automated tests on every proposed patch to the reference software.Integration tests are also necessary in bitcoinj to exercise the wallet code. In the past, unit tests were not realistic enough and did not simulate real network scenarios, resulting in bugs. Integration tests should handle re-orgs correctly and update the wallet properly in all cases. Additionally, a standalone tool that stress-tests the system would be useful to catch bugs earlier. This tool could randomly generate chains of transactions and could be written using bitcoinj or the raw transaction APIs on bitcoind.Blocktester, developed by Matt Corallo, is used for system testing in BitcoinJ. It simulates a peer against a slightly instrumented copy of Bitcoin(d/-qt) and tests complicated network scenarios while boundary testing many rules of the blockchain validation protocol. These tests are run as part of the automated tests on every proposed patch to the reference software, and pulltester comments on GitHub requests and produces logs.There is also a public secondary test network called 'testnet', which operates the same as the production network except it allows mining low difficulty blocks to prevent it from going for long times without blocks. Most of the testing work has focused on validating blockchain behavior because it has serious systemic risk, but measuring the JSON-RPC behavior is also interesting.Adam Ritter expressed concerns about the lack of integration tests for Bitcoin and the need to make the code more stable. Gregory Maxwell preferred calling these tests system tests and shared the use of blocktester in BitcoinJ to simulate network scenarios and test blockchain validation protocol rules. These tests are run as part of automated tests on every proposed patch to the reference software. Additionally, a public secondary test network called Testnet is available for testing purposes. Most of the testing work has been focused on validating blockchain behavior due to its systemic risk. The proposed integration testing aims to make the code easier to refactor and extend while ensuring it doesn't break the overall behavior of the client. It will also allow testing of attack scenarios and support multiple coins without breaking the original BitCoin protocol. The implementation will use the JSON-RPC interface and be written in C++, with the second implementation leveraging the BitCoin code directly by refactoring the client as a library. Dependency injection will be used for time and verifying mined blocks to enable faster running of tests without using real CPU power for mining. 2013-04-07T13:50:01+00:00 + Adam Ritter and Gregory Maxwell, members of the Bitcoin community, have discussed the importance of integration testing for Bitcoin's future development. Ritter emphasized the need to make the code more stable and test attack scenarios, refactoring, and extending code. Maxwell suggested calling these tests "system tests" and recommended using blocktester, a system based on BitcoinJ that simulates a peer against a slightly instrumented copy of Bitcoin (d/-qt). Blocktester runs complicated network scenarios and tests the boundaries of blockchain validation protocol rules, and is used as part of the automated tests on every proposed patch to the reference software.Integration tests are also necessary in bitcoinj to exercise the wallet code. In the past, unit tests were not realistic enough and did not simulate real network scenarios, resulting in bugs. Integration tests should handle re-orgs correctly and update the wallet properly in all cases. Additionally, a standalone tool that stress-tests the system would be useful to catch bugs earlier. This tool could randomly generate chains of transactions and could be written using bitcoinj or the raw transaction APIs on bitcoind.Blocktester, developed by Matt Corallo, is used for system testing in BitcoinJ. It simulates a peer against a slightly instrumented copy of Bitcoin(d/-qt) and tests complicated network scenarios while boundary testing many rules of the blockchain validation protocol. These tests are run as part of the automated tests on every proposed patch to the reference software, and pulltester comments on GitHub requests and produces logs.There is also a public secondary test network called 'testnet', which operates the same as the production network except it allows mining low difficulty blocks to prevent it from going for long times without blocks. Most of the testing work has focused on validating blockchain behavior because it has serious systemic risk, but measuring the JSON-RPC behavior is also interesting.Adam Ritter expressed concerns about the lack of integration tests for Bitcoin and the need to make the code more stable. Gregory Maxwell preferred calling these tests system tests and shared the use of blocktester in BitcoinJ to simulate network scenarios and test blockchain validation protocol rules. These tests are run as part of automated tests on every proposed patch to the reference software. Additionally, a public secondary test network called Testnet is available for testing purposes. Most of the testing work has been focused on validating blockchain behavior due to its systemic risk. The proposed integration testing aims to make the code easier to refactor and extend while ensuring it doesn't break the overall behavior of the client. It will also allow testing of attack scenarios and support multiple coins without breaking the original BitCoin protocol. The implementation will use the JSON-RPC interface and be written in C++, with the second implementation leveraging the BitCoin code directly by refactoring the client as a library. Dependency injection will be used for time and verifying mined blocks to enable faster running of tests without using real CPU power for mining. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_On-going-data-spam.xml b/static/bitcoin-dev/April_2013/combined_On-going-data-spam.xml index eb4956af90..1bbba6fdfd 100644 --- a/static/bitcoin-dev/April_2013/combined_On-going-data-spam.xml +++ b/static/bitcoin-dev/April_2013/combined_On-going-data-spam.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On-going data spam - 2023-08-01T04:38:30.399739+00:00 + 2025-10-11T22:20:37.395446+00:00 + python-feedgen Mike Hearn 2013-04-09 19:43:33+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - On-going data spam - 2023-08-01T04:38:30.399739+00:00 + 2025-10-11T22:20:37.395596+00:00 - In an email conversation on the Bitcoin-development mailing list, Gregory Maxwell and Caleb James DeLisle discussed the potential impact of anti-virus software on Bitcoin's testnet chain. They explored the consequences of AV software on web browser caches and file corruption. Caleb suggested contacting an AV company to inquire about the smallest amount of data they have a signature on. Gregory tested the testnet chain with the EICAR test string and found that most AV tools do not scan big binary files of unknown types. However, he proposed implementing storage scrambling if needed. The thread also included a link to Precog, a next-generation analytics platform for data science.Caleb James DeLisle initiated an email conversation regarding how anti-virus software might respond to certain streams of bytes sent across a TCP socket or persisted to disk. The use of the EICAR test string on the testnet chain revealed that most AV tools do not scan large binary files of unknown types. Storage scrambling was suggested as a solution, where each node would pick a random word to XOR their stored data with.The discussion on the Bitcoin-development mailing list involved various topics related to the use of blockchains. Mike Hearn argued that defining "abuse" in economic terms could exclude legitimate uses and proposed solutions to discourage the use of blockchains for illegal content. Backwards compatibility and the issue of uneconomical outputs in Bitcoin transactions were also discussed. Jeff Garzik expressed openness towards a blacklist for Bitcoin transactions but emphasized the importance of openness in its implementation. The potential problem of spammers encoding harmful content within the blockchain was acknowledged, leading to the consideration of mitigation efforts.Mike Hearn and Jeff Garzik engaged in an email exchange discussing the issue of uneconomical outputs in Bitcoin transactions. The proposed patch to address this issue lacked a clear definition of what constitutes an uneconomical output, but it was deemed acceptable by Hearn. Backwards compatibility problems were highlighted, and the payment protocol work was suggested as a prerequisite for addressing this issue.The conversation on the Bitcoin-development mailing list focused on the problem of uneconomical outputs in Bitcoin transactions. Developers agreed that such outputs should be made non-standard but faced challenges in defining what is considered uneconomical. The proposed patch lacked a clear concept, and concerns about backwards compatibility were raised. The discussion was postponed until the completion of the payment protocol work.Jeff Garzik expressed openness towards a blacklist for Bitcoin transactions if done openly. He emphasized that storing large data transactions is not the primary purpose of Bitcoin. The consensus among developers was to make uneconomical outputs non-standard and implement metrics and heuristics to address the issue. One suggestion was to block uneconomic UTXO creation as a stopgap solution to data spam.Mike Hearn highlighted the root problem with Bitcoin, which is the assumption that the blockchain will always be a free, uncensorable, and permanent data structure. Legal issues and the need to host blocks forever were identified as challenges. Solutions such as charging for access to older parts of the chain and serving up blocks encrypted under a random key were proposed to discourage abuse and incentivize node hosting.The importance of consistent uptimes of nodes when bringing up a new node, especially on low-bandwidth connections, was mentioned. The absence of blacklists was suggested as an option for those who want to store and serve the chain without any cost. However, different approaches may be adopted by others.The discussion on the Bitcoin-development mailing list revolved around the issue of invalid addresses being exploited within the system. Suggestions were made to mitigate this issue through the implementation of blacklists and Bloom filtering, although concerns were raised about their effectiveness. The potential extraction of illegal content from the blockchain by law enforcement forensic tools was also discussed.Peter Todd and Mike Hearn discussed potential hacks to the Bitcoin protocol in an email exchange. Hearn proposed a solution to prevent spamming by serving blocks encrypted under a random key, but Todd raised concerns about its dependency on consistent uptimes of other nodes. The conversation also touched on the use of Bloom filtering and the idea of blacklists for abusive transactions, with Todd opposing the use of blacklists altogether.A Reddit user reported attempts to upload various forms of data into the Bitcoin blockchain, including the entire AMIBIOS source code, Wikileaks data, GPG encrypted files, and hidden wiki cp/jb sections. Links were provided to addresses used for encryption, and discussions surrounding the storage of data on the Litecoin chain were also mentioned.These conversations and discussions provide insights into various technical and philosophical aspects related to Bitcoin's development, the impact of anti-virus software, the challenges of uneconomical outputs in transactions, the potential need for blacklists, and the storage of data on the blockchain. 2013-04-09T19:43:33+00:00 + In an email conversation on the Bitcoin-development mailing list, Gregory Maxwell and Caleb James DeLisle discussed the potential impact of anti-virus software on Bitcoin's testnet chain. They explored the consequences of AV software on web browser caches and file corruption. Caleb suggested contacting an AV company to inquire about the smallest amount of data they have a signature on. Gregory tested the testnet chain with the EICAR test string and found that most AV tools do not scan big binary files of unknown types. However, he proposed implementing storage scrambling if needed. The thread also included a link to Precog, a next-generation analytics platform for data science.Caleb James DeLisle initiated an email conversation regarding how anti-virus software might respond to certain streams of bytes sent across a TCP socket or persisted to disk. The use of the EICAR test string on the testnet chain revealed that most AV tools do not scan large binary files of unknown types. Storage scrambling was suggested as a solution, where each node would pick a random word to XOR their stored data with.The discussion on the Bitcoin-development mailing list involved various topics related to the use of blockchains. Mike Hearn argued that defining "abuse" in economic terms could exclude legitimate uses and proposed solutions to discourage the use of blockchains for illegal content. Backwards compatibility and the issue of uneconomical outputs in Bitcoin transactions were also discussed. Jeff Garzik expressed openness towards a blacklist for Bitcoin transactions but emphasized the importance of openness in its implementation. The potential problem of spammers encoding harmful content within the blockchain was acknowledged, leading to the consideration of mitigation efforts.Mike Hearn and Jeff Garzik engaged in an email exchange discussing the issue of uneconomical outputs in Bitcoin transactions. The proposed patch to address this issue lacked a clear definition of what constitutes an uneconomical output, but it was deemed acceptable by Hearn. Backwards compatibility problems were highlighted, and the payment protocol work was suggested as a prerequisite for addressing this issue.The conversation on the Bitcoin-development mailing list focused on the problem of uneconomical outputs in Bitcoin transactions. Developers agreed that such outputs should be made non-standard but faced challenges in defining what is considered uneconomical. The proposed patch lacked a clear concept, and concerns about backwards compatibility were raised. The discussion was postponed until the completion of the payment protocol work.Jeff Garzik expressed openness towards a blacklist for Bitcoin transactions if done openly. He emphasized that storing large data transactions is not the primary purpose of Bitcoin. The consensus among developers was to make uneconomical outputs non-standard and implement metrics and heuristics to address the issue. One suggestion was to block uneconomic UTXO creation as a stopgap solution to data spam.Mike Hearn highlighted the root problem with Bitcoin, which is the assumption that the blockchain will always be a free, uncensorable, and permanent data structure. Legal issues and the need to host blocks forever were identified as challenges. Solutions such as charging for access to older parts of the chain and serving up blocks encrypted under a random key were proposed to discourage abuse and incentivize node hosting.The importance of consistent uptimes of nodes when bringing up a new node, especially on low-bandwidth connections, was mentioned. The absence of blacklists was suggested as an option for those who want to store and serve the chain without any cost. However, different approaches may be adopted by others.The discussion on the Bitcoin-development mailing list revolved around the issue of invalid addresses being exploited within the system. Suggestions were made to mitigate this issue through the implementation of blacklists and Bloom filtering, although concerns were raised about their effectiveness. The potential extraction of illegal content from the blockchain by law enforcement forensic tools was also discussed.Peter Todd and Mike Hearn discussed potential hacks to the Bitcoin protocol in an email exchange. Hearn proposed a solution to prevent spamming by serving blocks encrypted under a random key, but Todd raised concerns about its dependency on consistent uptimes of other nodes. The conversation also touched on the use of Bloom filtering and the idea of blacklists for abusive transactions, with Todd opposing the use of blacklists altogether.A Reddit user reported attempts to upload various forms of data into the Bitcoin blockchain, including the entire AMIBIOS source code, Wikileaks data, GPG encrypted files, and hidden wiki cp/jb sections. Links were provided to addresses used for encryption, and discussions surrounding the storage of data on the Litecoin chain were also mentioned.These conversations and discussions provide insights into various technical and philosophical aspects related to Bitcoin's development, the impact of anti-virus software, the challenges of uneconomical outputs in transactions, the potential need for blacklists, and the storage of data on the blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_RFC-extend-signmessage-verifymessage-to-P2SH-multisig.xml b/static/bitcoin-dev/April_2013/combined_RFC-extend-signmessage-verifymessage-to-P2SH-multisig.xml index 8f0de21cd3..19c704e75d 100644 --- a/static/bitcoin-dev/April_2013/combined_RFC-extend-signmessage-verifymessage-to-P2SH-multisig.xml +++ b/static/bitcoin-dev/April_2013/combined_RFC-extend-signmessage-verifymessage-to-P2SH-multisig.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC: extend signmessage/verifymessage to P2SH multisig - 2023-08-01T04:39:29.847450+00:00 + 2025-10-11T22:20:43.765453+00:00 + python-feedgen Alan Reiner 2013-04-14 18:24:34+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - RFC: extend signmessage/verifymessage to P2SH multisig - 2023-08-01T04:39:29.847450+00:00 + 2025-10-11T22:20:43.765591+00:00 - Peter Todd and Alan Reiner have discussed the need to add an ASCII-armored format for message signing. This new format will encode the signed message next to the signature, eliminating any ambiguity about what was signed. The primary purpose of this format is to allow users to copy an ASCII-armored block of text into the client app and receive a pop-up window displaying the message along with a valid signature from a specific address. The format to follow for this implementation is RFC2440, section 7 "Cleartext signature framework". In another discussion between Luke-Jr and Peter Todd, Todd suggests extending the functionality of signmessage/verifymessage to support messages signed by multiple keys or P2SH multisig addresses. However, Luke-Jr suggests that HD wallet changes should be figured out first to avoid signing with the same private key twice. He proposes creating a new address format that represents a chain of keys instead of just one key or combination of keys. Todd agrees with this suggestion and mentions that he has an application where multisig signmessage would be useful.In an email exchange on April 14, 2013, Peter Todd suggests extending the signmessage/verifymessage feature to support messages signed by multiple keys or P2SH multisig addresses. However, he emphasizes the importance of figuring out HD wallet changes before making these extensions to ensure privacy and safety. Todd suggests creating a new address format that represents a chain of keys rather than one key or combination of keys to avoid signing with the same private key twice.The current signmessage/verifymessage feature only supports messages signed by a single key. However, it is proposed to extend this feature to support messages signed by multiple keys or P2SH multisig addresses. rpc.cpp:signmessage() returns the output of SignCompact(), which uses a header byte format to mark the signs of the various keys for key recovery. For multisig signmessage signatures, each signature or key can be in the form of sig, compressed key, or uncompressed key. All pubkeys must be provided even if they are not used for a specific signature to reconstruct the P2SH address. The encoding/decoding process for this format is code-intensive but keeps the size to a minimum. The format is backward compatible, and new signatures can be easily distinguished from old ones. In addition, signing incomplete signatures on messages can be handled by converting pubkeys to signatures, and the RPC signmessage command can be extended with an optional "existing signature" option. 2013-04-14T18:24:34+00:00 + Peter Todd and Alan Reiner have discussed the need to add an ASCII-armored format for message signing. This new format will encode the signed message next to the signature, eliminating any ambiguity about what was signed. The primary purpose of this format is to allow users to copy an ASCII-armored block of text into the client app and receive a pop-up window displaying the message along with a valid signature from a specific address. The format to follow for this implementation is RFC2440, section 7 "Cleartext signature framework". In another discussion between Luke-Jr and Peter Todd, Todd suggests extending the functionality of signmessage/verifymessage to support messages signed by multiple keys or P2SH multisig addresses. However, Luke-Jr suggests that HD wallet changes should be figured out first to avoid signing with the same private key twice. He proposes creating a new address format that represents a chain of keys instead of just one key or combination of keys. Todd agrees with this suggestion and mentions that he has an application where multisig signmessage would be useful.In an email exchange on April 14, 2013, Peter Todd suggests extending the signmessage/verifymessage feature to support messages signed by multiple keys or P2SH multisig addresses. However, he emphasizes the importance of figuring out HD wallet changes before making these extensions to ensure privacy and safety. Todd suggests creating a new address format that represents a chain of keys rather than one key or combination of keys to avoid signing with the same private key twice.The current signmessage/verifymessage feature only supports messages signed by a single key. However, it is proposed to extend this feature to support messages signed by multiple keys or P2SH multisig addresses. rpc.cpp:signmessage() returns the output of SignCompact(), which uses a header byte format to mark the signs of the various keys for key recovery. For multisig signmessage signatures, each signature or key can be in the form of sig, compressed key, or uncompressed key. All pubkeys must be provided even if they are not used for a specific signature to reconstruct the P2SH address. The encoding/decoding process for this format is code-intensive but keeps the size to a minimum. The format is backward compatible, and new signatures can be easily distinguished from old ones. In addition, signing incomplete signatures on messages can be handled by converting pubkeys to signatures, and the RPC signmessage command can be extended with an optional "existing signature" option. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Sending-Bitcoins-using-RSA-keys.xml b/static/bitcoin-dev/April_2013/combined_Sending-Bitcoins-using-RSA-keys.xml index 0975c785d6..c7482136f8 100644 --- a/static/bitcoin-dev/April_2013/combined_Sending-Bitcoins-using-RSA-keys.xml +++ b/static/bitcoin-dev/April_2013/combined_Sending-Bitcoins-using-RSA-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Sending Bitcoins using RSA keys - 2023-08-01T04:43:06.783074+00:00 + 2025-10-11T22:20:39.517949+00:00 + python-feedgen Melvin Carvalho 2013-04-27 14:14:42+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Sending Bitcoins using RSA keys - 2023-08-01T04:43:06.783074+00:00 + 2025-10-11T22:20:39.518119+00:00 - The discussion in the thread revolves around finding a method to bring together Bitcoin and RSA key pairs. The problem scenario presented is that Alice wants to send 1 BTC to Bob, but both of them possess RSA key pairs and lack public Bitcoin addresses. One proposed solution involves utilizing Bob's WebID to create entropy, which generates a BTC address with an ECDSA key pair. The coins are then sent to this address, and the seed is encrypted with Bob's public key for his decryption. This allows Bob to recreate the wallet and use it to spend the coins. This approach aims to merge the web paradigm and cryptocurrency paradigm into one extensive ecosystem.Another suggestion proposes exporting a private key for a new address generated by the bitcoin client and encrypting it with GPG. The encrypted key can then be sent to Bob for importation into his wallet. However, this method still relies on trust between the parties and does not provide a payment mechanism. The objective is to automate the process of integrating the RSA key community with Bitcoin to make it more accessible for GPG users who may lack a Bitcoin wallet or address.Craig, a user in the forum, questions the potential benefits of using a dance for Bitcoin transactions compared to existing methods. He argues that generating a new address and exporting the private key is a simpler and more straightforward mechanism than the initial proposal. Craig emphasizes that only one key needs to be sent instead of an entire wallet. Additionally, he clarifies that the original proposal does not function as a payment mechanism but rather as a means for two trusting parties to send Bitcoins without relying on the Bitcoin network. In both methods, joint custody of the BTCs is maintained until Bob uses them for spending on another address under his control.Melvin Carvalho contributes to the discussion by highlighting the possibility of unifying digital payments of Bitcoin and other services like Payswarm and WebID. With Bitcoin using ECDSA and GPG, while Payswarm/WebID primarily utilizing RSA, it is feasible to bring these two worlds together, enabling the transmission of bitcoins over WebID or Payswarm. The solution presented involves Alice using Bob's WebID and encrypting it with her private key to create entropy. This message is then employed as the seed to generate a Bitcoin address with an ECDSA key pair. Subsequently, Alice sends coins to this address and encrypts the seed again, this time with Bob's public key. By decrypting the seed using his private key, Bob can recreate the wallet and spend the coins. Melvin believes that this approach has the potential to merge the web paradigm and crypto-currency paradigm into one unified system. 2013-04-27T14:14:42+00:00 + The discussion in the thread revolves around finding a method to bring together Bitcoin and RSA key pairs. The problem scenario presented is that Alice wants to send 1 BTC to Bob, but both of them possess RSA key pairs and lack public Bitcoin addresses. One proposed solution involves utilizing Bob's WebID to create entropy, which generates a BTC address with an ECDSA key pair. The coins are then sent to this address, and the seed is encrypted with Bob's public key for his decryption. This allows Bob to recreate the wallet and use it to spend the coins. This approach aims to merge the web paradigm and cryptocurrency paradigm into one extensive ecosystem.Another suggestion proposes exporting a private key for a new address generated by the bitcoin client and encrypting it with GPG. The encrypted key can then be sent to Bob for importation into his wallet. However, this method still relies on trust between the parties and does not provide a payment mechanism. The objective is to automate the process of integrating the RSA key community with Bitcoin to make it more accessible for GPG users who may lack a Bitcoin wallet or address.Craig, a user in the forum, questions the potential benefits of using a dance for Bitcoin transactions compared to existing methods. He argues that generating a new address and exporting the private key is a simpler and more straightforward mechanism than the initial proposal. Craig emphasizes that only one key needs to be sent instead of an entire wallet. Additionally, he clarifies that the original proposal does not function as a payment mechanism but rather as a means for two trusting parties to send Bitcoins without relying on the Bitcoin network. In both methods, joint custody of the BTCs is maintained until Bob uses them for spending on another address under his control.Melvin Carvalho contributes to the discussion by highlighting the possibility of unifying digital payments of Bitcoin and other services like Payswarm and WebID. With Bitcoin using ECDSA and GPG, while Payswarm/WebID primarily utilizing RSA, it is feasible to bring these two worlds together, enabling the transmission of bitcoins over WebID or Payswarm. The solution presented involves Alice using Bob's WebID and encrypting it with her private key to create entropy. This message is then employed as the seed to generate a Bitcoin address with an ECDSA key pair. Subsequently, Alice sends coins to this address and encrypts the seed again, this time with Bob's public key. By decrypting the seed using his private key, Bob can recreate the wallet and spend the coins. Melvin believes that this approach has the potential to merge the web paradigm and crypto-currency paradigm into one unified system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Service-bits-for-pruned-nodes.xml b/static/bitcoin-dev/April_2013/combined_Service-bits-for-pruned-nodes.xml index eba09a5946..3340848a23 100644 --- a/static/bitcoin-dev/April_2013/combined_Service-bits-for-pruned-nodes.xml +++ b/static/bitcoin-dev/April_2013/combined_Service-bits-for-pruned-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Service bits for pruned nodes - 2023-08-01T04:46:14.421991+00:00 + 2025-10-11T22:21:07.130765+00:00 + python-feedgen Ricardo Filipe 2013-05-16 16:23:23+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Service bits for pruned nodes - 2023-08-01T04:46:14.422988+00:00 + 2025-10-11T22:21:07.130932+00:00 - In 2013, discussions were taking place within the Bitcoin network regarding the storage and replication of historic data. One proposal suggested allowing users to choose which parts of the blockchain to store, but concerns were raised about the lack of copies of the data. An alternative suggestion was made to randomly store chunks of data based on available space, prioritizing the "N most recent" chunks for more replicas. However, Jeff Garzik argued against this idea, warning that it could make the blockchain vulnerable to DoS attacks on one part of the Distributed Hash Table (DHT), potentially causing the entire chain to break.Another topic of discussion focused on optimizing peer discovery mechanisms in the Bitcoin network. The current methods, such as DNS seeds, a fixed list, and IRC discovery, were not deemed effective for overall peer discovery. Several alternative means of peer discovery were suggested, including search engines, IPv4 scanning, and anycast peers. Mike Hearn proposed extending the DNS seeding protocol to allow queries that return only nodes matching specific requirements. However, concerns were raised about DNS caching and the risk of sudden traffic influx at one set of nodes if a large ISP caches a response.The concept of pruning nodes, which validate and relay blocks without keeping all historic blocks, was also explored. Pieter Wuille suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. This would ensure synchronization between new and old nodes. Although there was general support for this proposal, potential issues related to snapshotting and UTXO snapshots were raised.The possibility of using BitTorrent technology in the Bitcoin network was considered. It was suggested that clients could analyze the distribution of parts to maintain high availability of the entire blockchain. However, caution was advised due to concerns about centralized trackers and expensive DHTs. Gregory Maxwell dismissed the idea, arguing that tracker-less torrents didn't work well in practice and that integrating BitTorrent technology into Bitcoin would require additional software and opening more ports.In an email conversation, John Dillon proposed using BitTorrent to address the issue of storage capacity in Bitcoin. However, objections were raised regarding the ineffectiveness and susceptibility to DoS attacks of tracker-less torrents. Integrating a DHT capable BitTorrent client was seen as a complicating factor that would require extra software. Instead, it was suggested to add the ability for nodes to advertise what parts of the blockchain they have and revise the address message format to support I2P peers.The discussion emphasized the importance of having sufficient copies of historic data by splitting Bitcoin into ranges. While nodes may be willing to contribute storage space, without a proper structure in place, they would not be able to do so effectively. Suggestions were made to integrate a DHT capable BitTorrent client or call out to a library to solve the problem of nodes finding each other to obtain the data. It was also proposed to use Bitcoin to bootstrap the BitTorrent DHT.Mike Hearn and Pieter Wuille had a conversation about the flexibility of node pruning in Bitcoin. They agreed that nodes should be able to choose their own ranges to keep rather than having fixed intervals. Pieter suggested adding new fields to the addr message to advertise the height at which nodes prune. However, he acknowledged that propagation speed might be slow with this method due to the number of IPs circulating. They also discussed separating the responsibilities of relay/validation and serving historic data, suggesting separate service bits for each. The behavior of old nodes connecting to new nodes and the use case for NODE_VALIDATE were also discussed.Pieter Wuille proposed the idea of pruning nodes that do not keep historic blocks. He suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. NODE_VALIDATE would relay and validate recent blocks and transactions but only answer getdata requests for those. NODE_BLOCKS_2016 could be queried for the last 2016 blocks without guaranteeing relaying or validating new blocks and transactions. The NODE_NETWORK bit would imply NODE_VALIDATE and ensure the availability of all historic blocks. Pieter plans to write a BIP to formalize this proposal. 2013-05-16T16:23:23+00:00 + In 2013, discussions were taking place within the Bitcoin network regarding the storage and replication of historic data. One proposal suggested allowing users to choose which parts of the blockchain to store, but concerns were raised about the lack of copies of the data. An alternative suggestion was made to randomly store chunks of data based on available space, prioritizing the "N most recent" chunks for more replicas. However, Jeff Garzik argued against this idea, warning that it could make the blockchain vulnerable to DoS attacks on one part of the Distributed Hash Table (DHT), potentially causing the entire chain to break.Another topic of discussion focused on optimizing peer discovery mechanisms in the Bitcoin network. The current methods, such as DNS seeds, a fixed list, and IRC discovery, were not deemed effective for overall peer discovery. Several alternative means of peer discovery were suggested, including search engines, IPv4 scanning, and anycast peers. Mike Hearn proposed extending the DNS seeding protocol to allow queries that return only nodes matching specific requirements. However, concerns were raised about DNS caching and the risk of sudden traffic influx at one set of nodes if a large ISP caches a response.The concept of pruning nodes, which validate and relay blocks without keeping all historic blocks, was also explored. Pieter Wuille suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. This would ensure synchronization between new and old nodes. Although there was general support for this proposal, potential issues related to snapshotting and UTXO snapshots were raised.The possibility of using BitTorrent technology in the Bitcoin network was considered. It was suggested that clients could analyze the distribution of parts to maintain high availability of the entire blockchain. However, caution was advised due to concerns about centralized trackers and expensive DHTs. Gregory Maxwell dismissed the idea, arguing that tracker-less torrents didn't work well in practice and that integrating BitTorrent technology into Bitcoin would require additional software and opening more ports.In an email conversation, John Dillon proposed using BitTorrent to address the issue of storage capacity in Bitcoin. However, objections were raised regarding the ineffectiveness and susceptibility to DoS attacks of tracker-less torrents. Integrating a DHT capable BitTorrent client was seen as a complicating factor that would require extra software. Instead, it was suggested to add the ability for nodes to advertise what parts of the blockchain they have and revise the address message format to support I2P peers.The discussion emphasized the importance of having sufficient copies of historic data by splitting Bitcoin into ranges. While nodes may be willing to contribute storage space, without a proper structure in place, they would not be able to do so effectively. Suggestions were made to integrate a DHT capable BitTorrent client or call out to a library to solve the problem of nodes finding each other to obtain the data. It was also proposed to use Bitcoin to bootstrap the BitTorrent DHT.Mike Hearn and Pieter Wuille had a conversation about the flexibility of node pruning in Bitcoin. They agreed that nodes should be able to choose their own ranges to keep rather than having fixed intervals. Pieter suggested adding new fields to the addr message to advertise the height at which nodes prune. However, he acknowledged that propagation speed might be slow with this method due to the number of IPs circulating. They also discussed separating the responsibilities of relay/validation and serving historic data, suggesting separate service bits for each. The behavior of old nodes connecting to new nodes and the use case for NODE_VALIDATE were also discussed.Pieter Wuille proposed the idea of pruning nodes that do not keep historic blocks. He suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. NODE_VALIDATE would relay and validate recent blocks and transactions but only answer getdata requests for those. NODE_BLOCKS_2016 could be queried for the last 2016 blocks without guaranteeing relaying or validating new blocks and transactions. The NODE_NETWORK bit would imply NODE_VALIDATE and ensure the availability of all historic blocks. Pieter plans to write a BIP to formalize this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_To-prevent-arbitrary-data-storage-in-txouts-The-Ultimate-Solution.xml b/static/bitcoin-dev/April_2013/combined_To-prevent-arbitrary-data-storage-in-txouts-The-Ultimate-Solution.xml index e139c008c1..d019294f36 100644 --- a/static/bitcoin-dev/April_2013/combined_To-prevent-arbitrary-data-storage-in-txouts-The-Ultimate-Solution.xml +++ b/static/bitcoin-dev/April_2013/combined_To-prevent-arbitrary-data-storage-in-txouts-The-Ultimate-Solution.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - To prevent arbitrary data storage in txouts — The Ultimate Solution - 2023-08-01T04:39:10.716166+00:00 + 2025-10-11T22:20:56.513026+00:00 + python-feedgen Peter Todd 2013-04-11 11:27:08+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - To prevent arbitrary data storage in txouts — The Ultimate Solution - 2023-08-01T04:39:10.717128+00:00 + 2025-10-11T22:20:56.513207+00:00 - On April 10, 2013, Peter Todd proposed changing the transaction hash algorithm to extend the Merkle tree into the transaction outputs/inputs. This change would allow for pruning transactions bit by bit and still serving nodes requesting proof of their unspent transaction output (UTXO) without causing difficulties for spending old UTXOs. Jorge Timón expressed agreement with the proposal but questioned potential opposition. Todd himself raised concerns about the technical risks involved in implementing UTXO fraud proofs.In an email conversation between Gregory Maxwell and Peter Todd, they discussed the difficulty of paying additional funds to a random transaction output seen on the blockchain. Todd noted that this could create a strange situation, but Maxwell saw it as a positive property. Todd warned against getting too hopeful, as he expected blockchain.info to keep a publicly accessible database that could still allow payments to random transaction outputs.Another email exchange from 2013, involving Peter Todd and an unknown individual, discussed the odd side-effect of making it difficult to pay further funds to a random transaction output. Both parties agreed that while strange, it was not necessarily a bad thing. The unknown individual mentioned previously lamenting the lack of knowledge on how to achieve this property.In a discussion between Peter Todd and Gregory Maxwell, they explored the possibility of using P2SH addresses to provide the full 256 bits. They suggested keeping the address length at 160 bits and proposed a new scriptPubKey. They concluded that there was no need to change the address type if new software could be written to check for both forms of transaction output. However, this approach could make it challenging to pay further funds to a random transaction output.In an email conversation involving Robert Backhaus and others, they discussed the use of P2SH addresses in Bitcoin. Backhaus inquired about storing P2SH addresses and expressed appreciation for the ability to create date stamps without storing data in the blockchain. It was confirmed that P2SH addresses did not prevent value commitment but only prevented data storage. It was also noted that storing data in values incurred exponential computational costs.On the Bitcoin-development mailing list, Gregory Maxwell proposed a change to the Bitcoin protocol involving a new address type called P2SH^2. This new address type would be a hash of a P2SH address, and its inclusion would eliminate non-prunable locations for users to store data in the blockchain. Maxwell suggested implementing a relay rule and introducing a block discouragement rule to ensure proper usage of P2SH^2 addresses. This proposal allowed for interesting uses such as creating date stamps while preventing data storage.In an email conversation between Peter Todd and Gregory Maxwell, they discussed the topic of data stuffing in Bitcoin. Maxwell proposed using Hash160 for P2SH addresses and introducing a new address type, P2SH^2, to restrict data stuffing to brute forcing hash collisions. They also discussed changing the transaction hash algorithm to extend the Merkle tree into the transaction outputs/inputs through a hard fork. This change would enable pruning transactions bit by bit while still serving nodes requesting proof of their UTXO.Gregory Maxwell sent an email to the Bitcoin-development mailing list discussing a possible solution to data stuffing. He proposed creating a new address type, P2SH^2, which would be a hash of a P2SH address. This approach would limit data stuffing to brute forcing hash collisions. Maxwell suggested defining P2SH^2 addresses and implementing a relay rule to verify the inner P2SH address. If miners mined P2SH^2 addresses without relaying the P2SH address, a block discouragement rule could be introduced. This change would eliminate non-prunable locations for data storage in the blockchain.In summary, various email exchanges and discussions from 2013 explored proposals and solutions related to the Bitcoin protocol. These included changing the transaction hash algorithm, using P2SH addresses, introducing a new address type (P2SH^2), and addressing the issue of data stuffing. The goal was to improve transaction pruning, prevent data storage in non-prunable locations, and enable interesting use cases while ensuring proper usage of addresses. 2013-04-11T11:27:08+00:00 + On April 10, 2013, Peter Todd proposed changing the transaction hash algorithm to extend the Merkle tree into the transaction outputs/inputs. This change would allow for pruning transactions bit by bit and still serving nodes requesting proof of their unspent transaction output (UTXO) without causing difficulties for spending old UTXOs. Jorge Timón expressed agreement with the proposal but questioned potential opposition. Todd himself raised concerns about the technical risks involved in implementing UTXO fraud proofs.In an email conversation between Gregory Maxwell and Peter Todd, they discussed the difficulty of paying additional funds to a random transaction output seen on the blockchain. Todd noted that this could create a strange situation, but Maxwell saw it as a positive property. Todd warned against getting too hopeful, as he expected blockchain.info to keep a publicly accessible database that could still allow payments to random transaction outputs.Another email exchange from 2013, involving Peter Todd and an unknown individual, discussed the odd side-effect of making it difficult to pay further funds to a random transaction output. Both parties agreed that while strange, it was not necessarily a bad thing. The unknown individual mentioned previously lamenting the lack of knowledge on how to achieve this property.In a discussion between Peter Todd and Gregory Maxwell, they explored the possibility of using P2SH addresses to provide the full 256 bits. They suggested keeping the address length at 160 bits and proposed a new scriptPubKey. They concluded that there was no need to change the address type if new software could be written to check for both forms of transaction output. However, this approach could make it challenging to pay further funds to a random transaction output.In an email conversation involving Robert Backhaus and others, they discussed the use of P2SH addresses in Bitcoin. Backhaus inquired about storing P2SH addresses and expressed appreciation for the ability to create date stamps without storing data in the blockchain. It was confirmed that P2SH addresses did not prevent value commitment but only prevented data storage. It was also noted that storing data in values incurred exponential computational costs.On the Bitcoin-development mailing list, Gregory Maxwell proposed a change to the Bitcoin protocol involving a new address type called P2SH^2. This new address type would be a hash of a P2SH address, and its inclusion would eliminate non-prunable locations for users to store data in the blockchain. Maxwell suggested implementing a relay rule and introducing a block discouragement rule to ensure proper usage of P2SH^2 addresses. This proposal allowed for interesting uses such as creating date stamps while preventing data storage.In an email conversation between Peter Todd and Gregory Maxwell, they discussed the topic of data stuffing in Bitcoin. Maxwell proposed using Hash160 for P2SH addresses and introducing a new address type, P2SH^2, to restrict data stuffing to brute forcing hash collisions. They also discussed changing the transaction hash algorithm to extend the Merkle tree into the transaction outputs/inputs through a hard fork. This change would enable pruning transactions bit by bit while still serving nodes requesting proof of their UTXO.Gregory Maxwell sent an email to the Bitcoin-development mailing list discussing a possible solution to data stuffing. He proposed creating a new address type, P2SH^2, which would be a hash of a P2SH address. This approach would limit data stuffing to brute forcing hash collisions. Maxwell suggested defining P2SH^2 addresses and implementing a relay rule to verify the inner P2SH address. If miners mined P2SH^2 addresses without relaying the P2SH address, a block discouragement rule could be introduced. This change would eliminate non-prunable locations for data storage in the blockchain.In summary, various email exchanges and discussions from 2013 explored proposals and solutions related to the Bitcoin protocol. These included changing the transaction hash algorithm, using P2SH addresses, introducing a new address type (P2SH^2), and addressing the issue of data stuffing. The goal was to improve transaction pruning, prevent data storage in non-prunable locations, and enable interesting use cases while ensuring proper usage of addresses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_Who-is-creating-non-DER-signatures-.xml b/static/bitcoin-dev/April_2013/combined_Who-is-creating-non-DER-signatures-.xml index b32c344f0c..497d1444d7 100644 --- a/static/bitcoin-dev/April_2013/combined_Who-is-creating-non-DER-signatures-.xml +++ b/static/bitcoin-dev/April_2013/combined_Who-is-creating-non-DER-signatures-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Who is creating non-DER signatures? - 2023-08-01T04:37:55.852445+00:00 + 2025-10-11T22:20:35.260759+00:00 + python-feedgen Pieter Wuille 2013-04-15 11:51:02+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Who is creating non-DER signatures? - 2023-08-01T04:37:55.852445+00:00 + 2025-10-11T22:20:35.260923+00:00 - In April 2013, Bitcoin developer Gregory Maxwell raised concerns about the network's ability to handle transactions due to non-standard encodings. A patch was implemented to enforce strict encodings for accepting transactions into the memory pool, but it was expected that some non-standard transactions would still make it into blocks until miners and nodes upgraded their software. The plan was to schedule a soft forking change once the rate of non-standard encodings in the blockchain decreased significantly. The current rules for acceptance into the memory pool include strict encoding rules for evaluated scripts and compressed or uncompressed public keys, with no support for the non-standard "hybrid" encoding. Signatures must also be strictly DER-encoded without padding.Pieter Wuille discussed the issue of network rules regarding transaction generators in 2013. He noted that not accepting them into memory pools would make it difficult for buggy clients creating transactions to get confirmations. Although only 0.6% of transactions were affected by these rules at the time, Wuille emphasized that the potential harm could be significant depending on how these transactions were created. He suggested posting a transaction normalizer tool to help users fix their transactions without needing assistance from developers.In an email dated April 7, 2013, Wuille informed the Bitcoin community that he had monitored transactions over the past few weeks and found that 9641 of them contained at least one non-standard signature. He provided a link to a list of the top addresses associated with these transactions and requested information about their owners or software usage. Wuille acknowledged the difficulty of reducing this number without significant effort and proposed not accepting these transactions into memory pools as a first step. However, this would make it very challenging for the buggy clients creating such transactions to obtain any confirmations.In another email thread, Mike Hearn requested more information on the invalid signatures. Wuille replied, stating that the majority of invalid signatures had negative R or S values, which are interpreted as unsigned by OpenSSL. Some signatures also had excessively padded R or S values when it was not necessary, and a few had incorrect length markers in the beginning.To address the dependence on OpenSSL and ensure strict adherence to DER-encoded signatures, Wuille proposed introducing a rule to make non-standard signatures invalid. This would require all clients on the network to stop creating such signatures. In his monitoring of transactions, he found that 9641 of them contained at least one non-standard signature. He urged anyone with knowledge of the top addresses associated with these transactions to come forward with information about their owners or software usage. 2013-04-15T11:51:02+00:00 + In April 2013, Bitcoin developer Gregory Maxwell raised concerns about the network's ability to handle transactions due to non-standard encodings. A patch was implemented to enforce strict encodings for accepting transactions into the memory pool, but it was expected that some non-standard transactions would still make it into blocks until miners and nodes upgraded their software. The plan was to schedule a soft forking change once the rate of non-standard encodings in the blockchain decreased significantly. The current rules for acceptance into the memory pool include strict encoding rules for evaluated scripts and compressed or uncompressed public keys, with no support for the non-standard "hybrid" encoding. Signatures must also be strictly DER-encoded without padding.Pieter Wuille discussed the issue of network rules regarding transaction generators in 2013. He noted that not accepting them into memory pools would make it difficult for buggy clients creating transactions to get confirmations. Although only 0.6% of transactions were affected by these rules at the time, Wuille emphasized that the potential harm could be significant depending on how these transactions were created. He suggested posting a transaction normalizer tool to help users fix their transactions without needing assistance from developers.In an email dated April 7, 2013, Wuille informed the Bitcoin community that he had monitored transactions over the past few weeks and found that 9641 of them contained at least one non-standard signature. He provided a link to a list of the top addresses associated with these transactions and requested information about their owners or software usage. Wuille acknowledged the difficulty of reducing this number without significant effort and proposed not accepting these transactions into memory pools as a first step. However, this would make it very challenging for the buggy clients creating such transactions to obtain any confirmations.In another email thread, Mike Hearn requested more information on the invalid signatures. Wuille replied, stating that the majority of invalid signatures had negative R or S values, which are interpreted as unsigned by OpenSSL. Some signatures also had excessively padded R or S values when it was not necessary, and a few had incorrect length markers in the beginning.To address the dependence on OpenSSL and ensure strict adherence to DER-encoded signatures, Wuille proposed introducing a rule to make non-standard signatures invalid. This would require all clients on the network to stop creating such signatures. In his monitoring of transactions, he found that 9641 of them contained at least one non-standard signature. He urged anyone with knowledge of the top addresses associated with these transactions to come forward with information about their owners or software usage. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_bitcoin-pull-requests.xml b/static/bitcoin-dev/April_2013/combined_bitcoin-pull-requests.xml index fa024ee3e3..342dc8b060 100644 --- a/static/bitcoin-dev/April_2013/combined_bitcoin-pull-requests.xml +++ b/static/bitcoin-dev/April_2013/combined_bitcoin-pull-requests.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin pull requests - 2023-08-01T04:36:24.308600+00:00 + 2025-10-11T22:20:45.887818+00:00 + python-feedgen Mike Hearn 2013-04-04 10:04:22+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - bitcoin pull requests - 2023-08-01T04:36:24.308600+00:00 + 2025-10-11T22:20:45.888028+00:00 - The email conversation revolves around the security measures in Bitcoin and its repositories. Mike Hearn suggests using automatic updates with threshold signatures for bitcoinj based wallets, combined with regular audits for new user downloads to ensure developer integrity. Grarpamp agrees that hardware is important for security but warns that it must be trusted and have secure crypto exchanges with the host. The discussion then moves onto repository integrity, with both parties agreeing that it needs improvement. They note that oddity detection and alerting should be implemented to prevent potential malicious actions from going unnoticed. Finally, they acknowledge that open-source security still has a long way to go, but progress is being made.The author's hope for bitcoinj based wallets is to have automatic updates with threshold signatures, combined with regular audits of initial downloads for new users. This would result in a safe system that is immune to rogue developers. The use of hardware security modules (HSM) for multisig addresses is suggested, but the author notes that it is only effective if the crypto is done within the hardware and the hardware can be trusted. Repository integrity is also discussed as a general problem applicable to many things, and the need for strong repo structures is highlighted for better auditing of the BTC codebase. The lack of verification structures in some repos is noted, along with issues of filesystems that accept bitrot. The need for oddity detection and alerting in repository security is also emphasized. Finally, the author suggests that improvements in these areas could bring about a stronger audit trail for the open-source world in the future.Hardware encryption is only effective if it's integrated properly. Fingerprint readers, for example, are often insecure because they present raw fingerprint scans to software instead of hashing them internally for better security. Multisig addresses are a step in the right direction, requiring transactions to be signed off by a hardware security module (HSM). Although repository integrity is important, Bitcoin specialists should focus on improving Bitcoin security measures while other experts work on improving repository security overall. One way to improve repositories is with oddity detection and alerting. Some repos have weak internal verification structures and are susceptible to bitrot. However, some people are working toward better tools and migrating things to create a more secure and auditable open-source world.The context discusses the impossibility of eliminating the risk of downloading a trojaned client for Bitcoin. Even with a secure passphrase, a hacked Windows box will allow the hacker to spend the coins as easily as the owner. Additionally, secondary remote spendauth sigs into the network chain will be similarly compromised. Securely hashchecking the trojaned client is also difficult from cracked userspace on a hacked dll/kernel with uefi backdoor and a trojaned hasher. The author suggests that it's easier for a few developers to meet in person to init and sig a new repo than to try fixing the world's userland and users. This way, something verifiable can be obtained back to the root.Gavin Andresen emphasizes the need to prioritize the safety of users' bitcoins even if their bitcoin software is compromised. He suggests eliminating the risk of a bad bitcoin-qt.exe entirely as a possible single point of failure instead of worrying about unlikely scenarios such as a timing attack in between ACKs/pulls. By doing so, one can ensure that users are protected and their bitcoins remain secure. Andresen's statement highlights the significance of focusing on security measures when it comes to dealing with cryptocurrencies.The author of a post discusses the importance of reading code when acknowledging it. They mention that signing commits, like in the Linux kernel, is important but reading the code is even more crucial. The author also wonders if there is a possibility for a race to occur just before they click "pull" where someone could sneakily rebase the branch to something evil. In response to this concern, the author suggests looking into monotone.ca, which integrates crypto and review primitives into the workflow and has reliable network distribution models that work well over things like Tor. They note that once you have the crypto, the human risk factors such as rogue, password, and cracks become harder to deal with.In an email conversation between Wladimir and Jeff Garzik on April 2, 2013, a suggestion was made to start gpg signing commits for Bitcoin like the Linux kernel. However, it was pointed out that this would rule out using GitHub for merging without manual steps. Jeff Garzik acknowledged this but noted that he personally reads the code before approving it, which is more important than the author. He also expressed concern about the possibility of a race where someone uploads an innocent branch, creates a pull request, and then rebases the branch to something evil just before the merge. Jeff Garzik is affiliated with exMULTI, Inc.The email thread discusses the feasibility of a SHA-1 collision attack to insert a malicious pull request into the Bitcoin code repository. The discussion includes the possibility of using gpg signing commits like the Linux kernel, which 2013-04-04T10:04:22+00:00 + The email conversation revolves around the security measures in Bitcoin and its repositories. Mike Hearn suggests using automatic updates with threshold signatures for bitcoinj based wallets, combined with regular audits for new user downloads to ensure developer integrity. Grarpamp agrees that hardware is important for security but warns that it must be trusted and have secure crypto exchanges with the host. The discussion then moves onto repository integrity, with both parties agreeing that it needs improvement. They note that oddity detection and alerting should be implemented to prevent potential malicious actions from going unnoticed. Finally, they acknowledge that open-source security still has a long way to go, but progress is being made.The author's hope for bitcoinj based wallets is to have automatic updates with threshold signatures, combined with regular audits of initial downloads for new users. This would result in a safe system that is immune to rogue developers. The use of hardware security modules (HSM) for multisig addresses is suggested, but the author notes that it is only effective if the crypto is done within the hardware and the hardware can be trusted. Repository integrity is also discussed as a general problem applicable to many things, and the need for strong repo structures is highlighted for better auditing of the BTC codebase. The lack of verification structures in some repos is noted, along with issues of filesystems that accept bitrot. The need for oddity detection and alerting in repository security is also emphasized. Finally, the author suggests that improvements in these areas could bring about a stronger audit trail for the open-source world in the future.Hardware encryption is only effective if it's integrated properly. Fingerprint readers, for example, are often insecure because they present raw fingerprint scans to software instead of hashing them internally for better security. Multisig addresses are a step in the right direction, requiring transactions to be signed off by a hardware security module (HSM). Although repository integrity is important, Bitcoin specialists should focus on improving Bitcoin security measures while other experts work on improving repository security overall. One way to improve repositories is with oddity detection and alerting. Some repos have weak internal verification structures and are susceptible to bitrot. However, some people are working toward better tools and migrating things to create a more secure and auditable open-source world.The context discusses the impossibility of eliminating the risk of downloading a trojaned client for Bitcoin. Even with a secure passphrase, a hacked Windows box will allow the hacker to spend the coins as easily as the owner. Additionally, secondary remote spendauth sigs into the network chain will be similarly compromised. Securely hashchecking the trojaned client is also difficult from cracked userspace on a hacked dll/kernel with uefi backdoor and a trojaned hasher. The author suggests that it's easier for a few developers to meet in person to init and sig a new repo than to try fixing the world's userland and users. This way, something verifiable can be obtained back to the root.Gavin Andresen emphasizes the need to prioritize the safety of users' bitcoins even if their bitcoin software is compromised. He suggests eliminating the risk of a bad bitcoin-qt.exe entirely as a possible single point of failure instead of worrying about unlikely scenarios such as a timing attack in between ACKs/pulls. By doing so, one can ensure that users are protected and their bitcoins remain secure. Andresen's statement highlights the significance of focusing on security measures when it comes to dealing with cryptocurrencies.The author of a post discusses the importance of reading code when acknowledging it. They mention that signing commits, like in the Linux kernel, is important but reading the code is even more crucial. The author also wonders if there is a possibility for a race to occur just before they click "pull" where someone could sneakily rebase the branch to something evil. In response to this concern, the author suggests looking into monotone.ca, which integrates crypto and review primitives into the workflow and has reliable network distribution models that work well over things like Tor. They note that once you have the crypto, the human risk factors such as rogue, password, and cracks become harder to deal with.In an email conversation between Wladimir and Jeff Garzik on April 2, 2013, a suggestion was made to start gpg signing commits for Bitcoin like the Linux kernel. However, it was pointed out that this would rule out using GitHub for merging without manual steps. Jeff Garzik acknowledged this but noted that he personally reads the code before approving it, which is more important than the author. He also expressed concern about the possibility of a race where someone uploads an innocent branch, creates a pull request, and then rebases the branch to something evil just before the merge. Jeff Garzik is affiliated with exMULTI, Inc.The email thread discusses the feasibility of a SHA-1 collision attack to insert a malicious pull request into the Bitcoin code repository. The discussion includes the possibility of using gpg signing commits like the Linux kernel, which - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2013/combined_bitcoinj-0-8.xml b/static/bitcoin-dev/April_2013/combined_bitcoinj-0-8.xml index b57e55f275..43abc70e64 100644 --- a/static/bitcoin-dev/April_2013/combined_bitcoinj-0-8.xml +++ b/static/bitcoin-dev/April_2013/combined_bitcoinj-0-8.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoinj 0.8 - 2023-08-01T04:38:50.359614+00:00 + 2025-10-11T22:21:02.881956+00:00 + python-feedgen Mike Hearn 2013-04-10 10:02:09+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - bitcoinj 0.8 - 2023-08-01T04:38:50.359614+00:00 + 2025-10-11T22:21:02.882115+00:00 - In a discussion thread, Mike Hearn explains that all mails he sends are signed automatically by Gmail using either the gmail.com consumer key or the google.com corporate key. The Gmail DKIM keys are considered safer than any key he could create/maintain. His ability to sign mail as hearn at google.com is controlled by hardware second factors and various other intense security systems. However, Andy Parkins points out that Hearn didn't sign his email and suggests that it is not yet secure.On Tuesday 09 April 2013, Mike Hearn provided instructions on how to obtain bitcoinj 0.8 from the source git via a secure manner. The instructions involve checking out the source from git and running specific commands. However, Dr. Andy Parkins raises concerns about the security of the message due to Hearn not signing his email.Bitcoinj 0.8, a Java library for writing Bitcoin applications, has been released. It includes support for both simplified and full verification. The release features an SPV implementation that competes with centralized solutions in terms of performance. Wallet setup for new users is now completed in just a few seconds. Bug fixes, optimizations, and minor API improvements make up the majority of the changes in this release. Notable additions include encryption of private keys in the wallet using an AES key derived using scrypt, improved performance with the new SPVBlockStore, and a tool for creating lists of block header checkpoints. Bloom-filtering capable nodes are now queried for transactions at startup, allowing users to receive payments that were not confirmed yet even if their wallet was not running at the time. Various static analysis warnings have been addressed, and event listeners now run unlocked except for transaction confidence listeners. Core objects have been converted to use cycle detecting locks. DNS seeds are now supported for testnet, and exceptions thrown during peer message processing can be caught and processed using PeerEventListener.Some changes have been made to specific components of the library. IrcDiscovery has been deprecated, and BoundedOverheadBlockStore has been replaced by SPVBlockStore. The Derby based block store has been deleted, and the static NetworkParameters methods now vend singleton objects. WalletEventListener.onCoinsSent is no longer triggered when a transaction sends to self without changing the balance.There are known issues with the release. Transaction confidence listeners still run with the wallet lock held, which can cause unexpected lock inversions in certain situations. The Wallet expects to store all transactions, including spent transactions, in memory which may lead to RAM constraints on older devices. Additionally, there are some bugs that can cause the wallet to enter an inconsistent state in rare scenarios. 2013-04-10T10:02:09+00:00 + In a discussion thread, Mike Hearn explains that all mails he sends are signed automatically by Gmail using either the gmail.com consumer key or the google.com corporate key. The Gmail DKIM keys are considered safer than any key he could create/maintain. His ability to sign mail as hearn at google.com is controlled by hardware second factors and various other intense security systems. However, Andy Parkins points out that Hearn didn't sign his email and suggests that it is not yet secure.On Tuesday 09 April 2013, Mike Hearn provided instructions on how to obtain bitcoinj 0.8 from the source git via a secure manner. The instructions involve checking out the source from git and running specific commands. However, Dr. Andy Parkins raises concerns about the security of the message due to Hearn not signing his email.Bitcoinj 0.8, a Java library for writing Bitcoin applications, has been released. It includes support for both simplified and full verification. The release features an SPV implementation that competes with centralized solutions in terms of performance. Wallet setup for new users is now completed in just a few seconds. Bug fixes, optimizations, and minor API improvements make up the majority of the changes in this release. Notable additions include encryption of private keys in the wallet using an AES key derived using scrypt, improved performance with the new SPVBlockStore, and a tool for creating lists of block header checkpoints. Bloom-filtering capable nodes are now queried for transactions at startup, allowing users to receive payments that were not confirmed yet even if their wallet was not running at the time. Various static analysis warnings have been addressed, and event listeners now run unlocked except for transaction confidence listeners. Core objects have been converted to use cycle detecting locks. DNS seeds are now supported for testnet, and exceptions thrown during peer message processing can be caught and processed using PeerEventListener.Some changes have been made to specific components of the library. IrcDiscovery has been deprecated, and BoundedOverheadBlockStore has been replaced by SPVBlockStore. The Derby based block store has been deleted, and the static NetworkParameters methods now vend singleton objects. WalletEventListener.onCoinsSent is no longer triggered when a transaction sends to self without changing the balance.There are known issues with the release. Transaction confidence listeners still run with the wallet lock held, which can cause unexpected lock inversions in certain situations. The Wallet expects to store all transactions, including spent transactions, in memory which may lead to RAM constraints on older devices. Additionally, there are some bugs that can cause the wallet to enter an inconsistent state in rare scenarios. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-root-key-with-optional-encryption.xml b/static/bitcoin-dev/April_2014/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-root-key-with-optional-encryption.xml index 52fba66020..03a2338642 100644 --- a/static/bitcoin-dev/April_2014/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-root-key-with-optional-encryption.xml +++ b/static/bitcoin-dev/April_2014/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-root-key-with-optional-encryption.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption - 2023-08-01T07:55:43.899157+00:00 + 2025-10-11T21:35:56.802270+00:00 + python-feedgen William Yager 2014-04-24 19:39:52+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption - 2023-08-01T07:55:43.900240+00:00 + 2025-10-11T21:35:56.802532+00:00 - The Bitcoin community has updated its specification to include front-loading all the key pre-stretching, as suggested by Gmaxwell. This update is designed to allow more powerful devices like laptops and mobile phones to handle the key-stretching process on their own, while weaker devices can outsource it to more capable devices. The updated spec includes a minimum of 8192 rounds of salted PBKDF2-HMAC-SHA512 for password protection, even when key-stretching is outsourced. The spec has been updated to remove the Scrypt dependency and add new key derivation functions and plausible deniability.There are concerns about potential password cracking if StrongH calculation is outsourced, but it is emphasized that the key material would still remain safe even if the password is exposed. Adjustments can be made to make password recovery more expensive if users are concerned about this vulnerability.The feasibility of using PBKDF2-HMAC-SHA512 for encryption in storage wallets is discussed. It is noted that this method is easy to implement on devices with limited RAM and can run at reasonable speeds on slow processors. Even if it takes several minutes to encrypt/decrypt, it is considered acceptable for one-time activities such as printing a cold wallet or importing an encrypted wallet into a phone. The deterministic time it takes allows for the addition of a progress bar to the user interface.The idea of using semi-trusted devices, like desktop PCs, for key stretching work in wallets is proposed. Concerns are raised about the security implications if a compromised computer is involved in the process. However, a compromise is reached with the inclusion of PBKDF2-HMAC-SHA512 based KDFs, which can run on memory-constrained devices and slow processors while still providing sufficient security.A bloom filter is proposed for typo checking and plausible deniability in a BIP. It is optimized for two elements and catches 99.9975% of typos while allowing for two different passwords. However, it is noted that this doesn't qualify as true plausible deniability as there are always at least two passwords. The conversation also covers the outsourcing of the KDF and the importance of using the specified algorithms to maintain compatibility.Discussions also touch on the integration of the BIP39 word list into Bitcoinj, timestamping and checksums, entropy length options, cross-wallet compatibility, and the benefits of a new specification over BIP 0038 and BIP 0039. It is suggested that BIP 0039 should not limit improvements on BIP 0038. The email thread concludes with links to a book on graph databases and the Bitcoin-development mailing list.In an email exchange, Jean-Paul Kogelman compared his proposal to BIP 39, highlighting the differences between the two. BIP 39 offers a list of words instead of using case-sensitive letters and numbers. It also supports different lengths of entropy, contrary to the belief that it only supports 12 words. Additionally, BIP 39 lacks a genesis date field, password typo detection, user-selectable KDF, and encourages the use of custom word lists.Kogelman announced updates to his spec, including removing Scrypt dependency, adding new KDFs, and plausible deniability. Pavol Rusnak mentioned BIP-0039, which offers an easy list of words, fixed length of entropy, no genesis date field, lack of password typo detection, no user-selectable KDF, inability to outsource KDF computation, and allows implementers to use their own word lists.On December 3rd, 2014, Kogelman shared the updates made in the spec, incorporating the requested features and removing Scrypt dependency. He also mentioned BIP-0039 as a related Bitcoin Improvement Proposal and provided a link to it.Kogelman proposed a method for encoding and encrypting Bitcoin HD Wallet root keys. The proposal includes encoding methodologies, encrypted and unencrypted wallet prefixes, verification information, salting, user-selectable KDF, second password option for plausible deniability, and prefix changes for alt-chains. The proposal provides KDF functions, date field for faster blockchain transaction search, derivation of master key from root key using SHA512, password encryption steps, bloom filter creation and verification methods, Python reference implementation, and test vectors.The context includes a list of public addresses, private extended keys, public extended keys, encrypted values, and creation dates for various test scenarios. Each scenario has different information such as root key, clear key, password, second password, associated public addresses, private extended keys, and public extended keys. Tests were conducted to generate multiple keys and public addresses using different KDFs, some with additional password encryption.The proposal includes updated wording, computation changes using PBKDF2-HMAC-SHA512, moving the KDF field, adding plausible deniability, new KDFs, entropy field in encrypted version, checksum field renamed to bloom field 2014-04-24T19:39:52+00:00 + The Bitcoin community has updated its specification to include front-loading all the key pre-stretching, as suggested by Gmaxwell. This update is designed to allow more powerful devices like laptops and mobile phones to handle the key-stretching process on their own, while weaker devices can outsource it to more capable devices. The updated spec includes a minimum of 8192 rounds of salted PBKDF2-HMAC-SHA512 for password protection, even when key-stretching is outsourced. The spec has been updated to remove the Scrypt dependency and add new key derivation functions and plausible deniability.There are concerns about potential password cracking if StrongH calculation is outsourced, but it is emphasized that the key material would still remain safe even if the password is exposed. Adjustments can be made to make password recovery more expensive if users are concerned about this vulnerability.The feasibility of using PBKDF2-HMAC-SHA512 for encryption in storage wallets is discussed. It is noted that this method is easy to implement on devices with limited RAM and can run at reasonable speeds on slow processors. Even if it takes several minutes to encrypt/decrypt, it is considered acceptable for one-time activities such as printing a cold wallet or importing an encrypted wallet into a phone. The deterministic time it takes allows for the addition of a progress bar to the user interface.The idea of using semi-trusted devices, like desktop PCs, for key stretching work in wallets is proposed. Concerns are raised about the security implications if a compromised computer is involved in the process. However, a compromise is reached with the inclusion of PBKDF2-HMAC-SHA512 based KDFs, which can run on memory-constrained devices and slow processors while still providing sufficient security.A bloom filter is proposed for typo checking and plausible deniability in a BIP. It is optimized for two elements and catches 99.9975% of typos while allowing for two different passwords. However, it is noted that this doesn't qualify as true plausible deniability as there are always at least two passwords. The conversation also covers the outsourcing of the KDF and the importance of using the specified algorithms to maintain compatibility.Discussions also touch on the integration of the BIP39 word list into Bitcoinj, timestamping and checksums, entropy length options, cross-wallet compatibility, and the benefits of a new specification over BIP 0038 and BIP 0039. It is suggested that BIP 0039 should not limit improvements on BIP 0038. The email thread concludes with links to a book on graph databases and the Bitcoin-development mailing list.In an email exchange, Jean-Paul Kogelman compared his proposal to BIP 39, highlighting the differences between the two. BIP 39 offers a list of words instead of using case-sensitive letters and numbers. It also supports different lengths of entropy, contrary to the belief that it only supports 12 words. Additionally, BIP 39 lacks a genesis date field, password typo detection, user-selectable KDF, and encourages the use of custom word lists.Kogelman announced updates to his spec, including removing Scrypt dependency, adding new KDFs, and plausible deniability. Pavol Rusnak mentioned BIP-0039, which offers an easy list of words, fixed length of entropy, no genesis date field, lack of password typo detection, no user-selectable KDF, inability to outsource KDF computation, and allows implementers to use their own word lists.On December 3rd, 2014, Kogelman shared the updates made in the spec, incorporating the requested features and removing Scrypt dependency. He also mentioned BIP-0039 as a related Bitcoin Improvement Proposal and provided a link to it.Kogelman proposed a method for encoding and encrypting Bitcoin HD Wallet root keys. The proposal includes encoding methodologies, encrypted and unencrypted wallet prefixes, verification information, salting, user-selectable KDF, second password option for plausible deniability, and prefix changes for alt-chains. The proposal provides KDF functions, date field for faster blockchain transaction search, derivation of master key from root key using SHA512, password encryption steps, bloom filter creation and verification methods, Python reference implementation, and test vectors.The context includes a list of public addresses, private extended keys, public extended keys, encrypted values, and creation dates for various test scenarios. Each scenario has different information such as root key, clear key, password, second password, associated public addresses, private extended keys, and public extended keys. Tests were conducted to generate multiple keys and public addresses using different KDFs, some with additional password encryption.The proposal includes updated wording, computation changes using PBKDF2-HMAC-SHA512, moving the KDF field, adding plausible deniability, new KDFs, entropy field in encrypted version, checksum field renamed to bloom field - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_-bits-Unit-of-account.xml b/static/bitcoin-dev/April_2014/combined_-bits-Unit-of-account.xml index ca56d5b74d..dbc8ce91e6 100644 --- a/static/bitcoin-dev/April_2014/combined_-bits-Unit-of-account.xml +++ b/static/bitcoin-dev/April_2014/combined_-bits-Unit-of-account.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - "bits": Unit of account - 2023-08-01T08:50:32.136441+00:00 + Combined summary - "bits": Unit of account + 2025-10-11T21:36:05.309366+00:00 + python-feedgen Gordon Mohr 2014-05-05 22:33:37+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 - Combined summary - "bits": Unit of account - 2023-08-01T08:50:32.137483+00:00 + Combined summary - "bits": Unit of account + 2025-10-11T21:36:05.309629+00:00 - In an email thread from April 2014, the Bitcoin development mailing list discussed possible names for smaller units of bitcoin. Mike Caldwell suggested "bit" as a short, memorable, and pronounceable option. However, it was noted that "bit" phonetically collides with slang for phallus in French and means "louse" in Turkish. Justin A proposed "ubit," pronounced "YOU-bit," representing 1e-6 bitcoin, which ties visually to the metric micro and leaves the required 2 decimal places. The discussion also considered using a letter before "bit," such as "ebit" or "xbit," the latter being XBT. Despite these suggestions, some believed that no term for smaller units had yet established itself.The conversation focused on finding a culturally neutral term for a unit representing 1e-6 bitcoin. The suggestion of "ubit" was made, but concerns were raised about the pronunciation and potential confusion with the term "XBT." Culturally neutral names were preferred to avoid invoking specific cultural references. It was pointed out that "bit" has conflicting meanings in different languages. Some participants believed that terms for smaller units would arise naturally over time. The email also included information on joining the Bitcoin development mailing list and a link to a free book on graph databases.The discussion emphasized the importance of finding a culturally neutral name for smaller units of bitcoin. Suggestions included "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about using the term "bit" due to its conflicting meanings in different languages. It was mentioned that terms for smaller units would likely establish themselves over time. Additionally, a link to a free book on graph databases was provided.The email conversation highlighted the need for a culturally neutral term for smaller units of bitcoin. The discussion included suggestions such as "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about the conflicting meanings of "bit" in different languages. The importance of avoiding cultural references in the name was emphasized. The conversation also included information on joining the Bitcoin development mailing list and a link to a free book on graph databases.The discussion revolved around finding a culturally neutral term for smaller units of bitcoin. Suggestions included "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about the conflicting meanings of "bit" in different languages. Some participants believed that terms for smaller units would arise naturally over time. The email also included a link to a free book on graph databases and information on joining the Bitcoin development mailing list.The discussion on Bitcoin denominations has been ongoing since 2013, with suggestions for alternative units such as XBT and bits. Some members of the community support the idea of using "bits" as a new unit of measurement for Bitcoin, while others have concerns about the term being too overloaded. Armory, a Bitcoin wallet, has started integrating alternative units, but more work is needed. Alan Reiner, the founder of Armory, supports the use of "microbitcoin" as a default unit but is unsure about the name "bits." Tamas Blummer suggests taking the discussion to wallet developers rather than engineers. Rob Golding proposes offering users the option to denominate Bitcoin currency in a unit called a bit, where one bitcoin equals one million bits and one bit equals 100 satoshis.The email thread among members of the Bitcoin-development mailing list discusses the proposal to introduce a new unit of account called "bits." The proposal suggests that one bitcoin would equal one million bits and one bit would equal 100 satoshis. Some members express concern about introducing a new prefix, while others argue that it may not be necessary given the existing divisions in u/mBTC. There are also concerns about confusion for average users and potential errors in transactions. Tamas Blummer suggests bringing the discussion to wallet developers, and Rob Golding recommends using satoshis instead of bits for simplicity.The discussion highlights the divergent views within the Bitcoin community regarding changes to the system. Some believe convention changes should apply to all clients, while others argue that these discussions should involve wallet developers. Ultimately, any decision on denomination would require consensus among stakeholders in the Bitcoin ecosystem.The proposal to denominate Bitcoin currency in units called bits has sparked debate among Bitcoin developers. Some argue that the term "bit" is already used in computer science and could cause confusion. Others suggest that people can choose other divisions if they prefer or use satoshis for simplicity. The discussion includes suggestions to bring the topic to wallet developers and concerns about potential errors in transactions.To address the issue of decimal problems in Bitcoin transactions, a proposal has been made to introduce a new unit called "bit." One bitcoin would equal one million bits, and one bit would equal 100 satoshis. This proposal aims to simplify the process and make it easier for users to understand. Further discussions on this topic can be 2014-05-05T22:33:37+00:00 + In an email thread from April 2014, the Bitcoin development mailing list discussed possible names for smaller units of bitcoin. Mike Caldwell suggested "bit" as a short, memorable, and pronounceable option. However, it was noted that "bit" phonetically collides with slang for phallus in French and means "louse" in Turkish. Justin A proposed "ubit," pronounced "YOU-bit," representing 1e-6 bitcoin, which ties visually to the metric micro and leaves the required 2 decimal places. The discussion also considered using a letter before "bit," such as "ebit" or "xbit," the latter being XBT. Despite these suggestions, some believed that no term for smaller units had yet established itself.The conversation focused on finding a culturally neutral term for a unit representing 1e-6 bitcoin. The suggestion of "ubit" was made, but concerns were raised about the pronunciation and potential confusion with the term "XBT." Culturally neutral names were preferred to avoid invoking specific cultural references. It was pointed out that "bit" has conflicting meanings in different languages. Some participants believed that terms for smaller units would arise naturally over time. The email also included information on joining the Bitcoin development mailing list and a link to a free book on graph databases.The discussion emphasized the importance of finding a culturally neutral name for smaller units of bitcoin. Suggestions included "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about using the term "bit" due to its conflicting meanings in different languages. It was mentioned that terms for smaller units would likely establish themselves over time. Additionally, a link to a free book on graph databases was provided.The email conversation highlighted the need for a culturally neutral term for smaller units of bitcoin. The discussion included suggestions such as "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about the conflicting meanings of "bit" in different languages. The importance of avoiding cultural references in the name was emphasized. The conversation also included information on joining the Bitcoin development mailing list and a link to a free book on graph databases.The discussion revolved around finding a culturally neutral term for smaller units of bitcoin. Suggestions included "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about the conflicting meanings of "bit" in different languages. Some participants believed that terms for smaller units would arise naturally over time. The email also included a link to a free book on graph databases and information on joining the Bitcoin development mailing list.The discussion on Bitcoin denominations has been ongoing since 2013, with suggestions for alternative units such as XBT and bits. Some members of the community support the idea of using "bits" as a new unit of measurement for Bitcoin, while others have concerns about the term being too overloaded. Armory, a Bitcoin wallet, has started integrating alternative units, but more work is needed. Alan Reiner, the founder of Armory, supports the use of "microbitcoin" as a default unit but is unsure about the name "bits." Tamas Blummer suggests taking the discussion to wallet developers rather than engineers. Rob Golding proposes offering users the option to denominate Bitcoin currency in a unit called a bit, where one bitcoin equals one million bits and one bit equals 100 satoshis.The email thread among members of the Bitcoin-development mailing list discusses the proposal to introduce a new unit of account called "bits." The proposal suggests that one bitcoin would equal one million bits and one bit would equal 100 satoshis. Some members express concern about introducing a new prefix, while others argue that it may not be necessary given the existing divisions in u/mBTC. There are also concerns about confusion for average users and potential errors in transactions. Tamas Blummer suggests bringing the discussion to wallet developers, and Rob Golding recommends using satoshis instead of bits for simplicity.The discussion highlights the divergent views within the Bitcoin community regarding changes to the system. Some believe convention changes should apply to all clients, while others argue that these discussions should involve wallet developers. Ultimately, any decision on denomination would require consensus among stakeholders in the Bitcoin ecosystem.The proposal to denominate Bitcoin currency in units called bits has sparked debate among Bitcoin developers. Some argue that the term "bit" is already used in computer science and could cause confusion. Others suggest that people can choose other divisions if they prefer or use satoshis for simplicity. The discussion includes suggestions to bring the topic to wallet developers and concerns about potential errors in transactions.To address the issue of decimal problems in Bitcoin transactions, a proposal has been made to introduce a new unit called "bit." One bitcoin would equal one million bits, and one bit would equal 100 satoshis. This proposal aims to simplify the process and make it easier for users to understand. Further discussions on this topic can be - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_0-confirmation-txs-using-replace-by-fee-and-game-theory.xml b/static/bitcoin-dev/April_2014/combined_0-confirmation-txs-using-replace-by-fee-and-game-theory.xml index fdd427c934..35a19d6b08 100644 --- a/static/bitcoin-dev/April_2014/combined_0-confirmation-txs-using-replace-by-fee-and-game-theory.xml +++ b/static/bitcoin-dev/April_2014/combined_0-confirmation-txs-using-replace-by-fee-and-game-theory.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0 confirmation txs using replace-by-fee and game theory - 2023-08-01T08:58:18.899247+00:00 + 2025-10-11T21:36:35.035438+00:00 + python-feedgen Isidor Zeuner 2014-06-19 03:47:17+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - 0 confirmation txs using replace-by-fee and game theory - 2023-08-01T08:58:18.899247+00:00 + 2025-10-11T21:36:35.035587+00:00 - Chris Pacia expressed his disapproval of a proposed payment system that requires users to have double the funds they need for a purchase, calling it an "ugly hack." He argues that not everyone will have the extra funds available, making it inconvenient to use the system. However, it was noted that the scheme would not be mandatory, and users could still opt to wait for confirmations or rely on existing trust.Mike Hearn responded to concerns about double spend attacks on Bitcoin, stating that the risk of getting caught and blacklisted makes it unlikely for attackers to attempt such an attack. He acknowledges that a dishonest mining pool could potentially execute a double spend attack for a fee, but this would not be feasible for high-value items due to the need to wait for block confirmation. The concern lies with opportunistic attackers who try to take back a portion of their transaction every time they make a purchase. The number of such opportunists and the hashrate a dishonest pool can attract remains to be seen.Double spending is when a person spends the same digital currency twice, but Bitcoin has been designed to prevent this. Successfully double spending does not result in getting money back, but rather being chased down by a shopkeeper or being blacklisted. The concern arises when one could actually double spend, and the only thing preventing them from doing so is Bitcoin's technology.Chris Pacia suggested an idea for Bitcoin transactions to prevent double spending. The proposed method involves the customer signing a transaction and walking out of the shop with their purchase. They would then immediately sign and broadcast a double-spend transaction with a higher fee. The POS computer would detect the double spend and sound the shoplifting alarm. While some complications exist with this scheme, Pacia believes that the number of people who would attempt this irrational method is lower than those who would shoplift traditionally.Mike Hearn raises a concern about fraudulent double-spending activities in payment networks. He questions the possibility of a customer buying a phone on contract and paying an artificially lower price, then double-spending by paying double the lower price. However, he suggests that nearly all payment systems have the same issue of needing to enforce contracts out-of-band.Bitcoin's relevance should not be compared to a theoretical perfect peer-to-peer system but rather to traditional bank notes and credit cards. While Bitcoin may not be the ideal instant peer-to-peer serialization mechanism, it still holds value and relevance in the current financial landscape. Bitcoin faces challenges in terms of proof of work, but this does not diminish its significance.The proposed scheme to discourage Finney attacks by charging the maximum double spending fee possible does not solve the problem. Chris Pacia prefers the hassle of a green address notary instead. There are also complications with the scheme, such as needing to double balances and what happens if a shop is selling something on contract.A discussion on replace-by-fee and child-pays-for-parent addresses the success rate of double spends. It is suggested that these policies would significantly reduce the risk of double spending. However, there are concerns about sybil attacks and the requirement of online private keys to sign replacements. Enforcing hashing visibility of block contents can help detect double spends and make them beneficial for decentralization.Jorge Timón proposed a solution for 0 confirmation transactions, but Peter Todd conducted an experiment suggesting that double spending frequently works without miners using replace-by-fee. Todd argues that only confirmations are solid evidence that a transaction has reached mining power. Enforcing hasher visibility of the blocks they are mining allows any hasher to detect a double spend.The proposed scheme to discourage Finney attacks does not fully address the issue, and a better solution is suggested. The discussion also explores the concept of 0 confirmation transactions and their feasibility with replace-by-fee policies. 2014-06-19T03:47:17+00:00 + Chris Pacia expressed his disapproval of a proposed payment system that requires users to have double the funds they need for a purchase, calling it an "ugly hack." He argues that not everyone will have the extra funds available, making it inconvenient to use the system. However, it was noted that the scheme would not be mandatory, and users could still opt to wait for confirmations or rely on existing trust.Mike Hearn responded to concerns about double spend attacks on Bitcoin, stating that the risk of getting caught and blacklisted makes it unlikely for attackers to attempt such an attack. He acknowledges that a dishonest mining pool could potentially execute a double spend attack for a fee, but this would not be feasible for high-value items due to the need to wait for block confirmation. The concern lies with opportunistic attackers who try to take back a portion of their transaction every time they make a purchase. The number of such opportunists and the hashrate a dishonest pool can attract remains to be seen.Double spending is when a person spends the same digital currency twice, but Bitcoin has been designed to prevent this. Successfully double spending does not result in getting money back, but rather being chased down by a shopkeeper or being blacklisted. The concern arises when one could actually double spend, and the only thing preventing them from doing so is Bitcoin's technology.Chris Pacia suggested an idea for Bitcoin transactions to prevent double spending. The proposed method involves the customer signing a transaction and walking out of the shop with their purchase. They would then immediately sign and broadcast a double-spend transaction with a higher fee. The POS computer would detect the double spend and sound the shoplifting alarm. While some complications exist with this scheme, Pacia believes that the number of people who would attempt this irrational method is lower than those who would shoplift traditionally.Mike Hearn raises a concern about fraudulent double-spending activities in payment networks. He questions the possibility of a customer buying a phone on contract and paying an artificially lower price, then double-spending by paying double the lower price. However, he suggests that nearly all payment systems have the same issue of needing to enforce contracts out-of-band.Bitcoin's relevance should not be compared to a theoretical perfect peer-to-peer system but rather to traditional bank notes and credit cards. While Bitcoin may not be the ideal instant peer-to-peer serialization mechanism, it still holds value and relevance in the current financial landscape. Bitcoin faces challenges in terms of proof of work, but this does not diminish its significance.The proposed scheme to discourage Finney attacks by charging the maximum double spending fee possible does not solve the problem. Chris Pacia prefers the hassle of a green address notary instead. There are also complications with the scheme, such as needing to double balances and what happens if a shop is selling something on contract.A discussion on replace-by-fee and child-pays-for-parent addresses the success rate of double spends. It is suggested that these policies would significantly reduce the risk of double spending. However, there are concerns about sybil attacks and the requirement of online private keys to sign replacements. Enforcing hashing visibility of block contents can help detect double spends and make them beneficial for decentralization.Jorge Timón proposed a solution for 0 confirmation transactions, but Peter Todd conducted an experiment suggesting that double spending frequently works without miners using replace-by-fee. Todd argues that only confirmations are solid evidence that a transaction has reached mining power. Enforcing hasher visibility of the blocks they are mining allows any hasher to detect a double spend.The proposed scheme to discourage Finney attacks does not fully address the issue, and a better solution is suggested. The discussion also explores the concept of 0 confirmation transactions and their feasibility with replace-by-fee policies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_About-Compact-SPV-proofs-via-block-header-commitments.xml b/static/bitcoin-dev/April_2014/combined_About-Compact-SPV-proofs-via-block-header-commitments.xml index 26783cecd8..54b0ca2905 100644 --- a/static/bitcoin-dev/April_2014/combined_About-Compact-SPV-proofs-via-block-header-commitments.xml +++ b/static/bitcoin-dev/April_2014/combined_About-Compact-SPV-proofs-via-block-header-commitments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - About Compact SPV proofs via block header commitments - 2023-08-01T09:04:33.186737+00:00 + 2025-10-11T21:35:29.186788+00:00 + python-feedgen Mark Friedenbach 2014-04-28 17:29:46+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - About Compact SPV proofs via block header commitments - 2023-08-01T09:04:33.186737+00:00 + 2025-10-11T21:35:29.186965+00:00 - In an email conversation between Sergio Lerner and a recipient, the discussion revolves around the periodic connection to an honest node during a potential attack. Lerner believes that the loss of this connection should be assumed during an attack, while the recipient argues that SPV proofs have broader applications and can detect non-51% attacks with existing tools. The recipient suggests that back-link commitments and compact SPV proofs can achieve the same results with fewer messages, less bandwidth, and equal security. Mark Friedenbach and Sergio Lerner discuss the security assumptions of Simplified Payment Verification (SPV) nodes, with Friedenbach suggesting that back-link block-history commitments can allow for a binary search to find common ancestors and trust the intermediate links. Peter Todd counters that assumptions about honest peers are necessary for computing economic arguments correctly. They also discuss different definitions of SPV proofs, with Lerner defining it as a sequence of bits establishing a block as part of the best-chain, and Friedenbach defining it as a sequence of bits establishing the ancestor of a block and the cost of creating a fake proof. The community does not have an official definition of "SPV proof", but SPV nodes generally trust the most-work chain based on economic arguments. In another email exchange, Friedenbach defines SPV proofs as a succinct sequence of bits that can establish connectivity and proof of work between two blocks, while Sergio argues for his own definition. The emails propose ways to construct SPV proofs using back-link commitments and discuss the use case of an SPV client coming online and asking peers for parent blocks until a last common parent is found. The proposal addresses the problem of parallel synchronized attacks and suggests assuming at least one peer is honest. It concludes with a proposed use case where an SPV client retrieves compact non-interactive proofs-of-inclusion for its transactions without downloading every intervening block header. 2014-04-28T17:29:46+00:00 + In an email conversation between Sergio Lerner and a recipient, the discussion revolves around the periodic connection to an honest node during a potential attack. Lerner believes that the loss of this connection should be assumed during an attack, while the recipient argues that SPV proofs have broader applications and can detect non-51% attacks with existing tools. The recipient suggests that back-link commitments and compact SPV proofs can achieve the same results with fewer messages, less bandwidth, and equal security. Mark Friedenbach and Sergio Lerner discuss the security assumptions of Simplified Payment Verification (SPV) nodes, with Friedenbach suggesting that back-link block-history commitments can allow for a binary search to find common ancestors and trust the intermediate links. Peter Todd counters that assumptions about honest peers are necessary for computing economic arguments correctly. They also discuss different definitions of SPV proofs, with Lerner defining it as a sequence of bits establishing a block as part of the best-chain, and Friedenbach defining it as a sequence of bits establishing the ancestor of a block and the cost of creating a fake proof. The community does not have an official definition of "SPV proof", but SPV nodes generally trust the most-work chain based on economic arguments. In another email exchange, Friedenbach defines SPV proofs as a succinct sequence of bits that can establish connectivity and proof of work between two blocks, while Sergio argues for his own definition. The emails propose ways to construct SPV proofs using back-link commitments and discuss the use case of an SPV client coming online and asking peers for parent blocks until a last common parent is found. The proposal addresses the problem of parallel synchronized attacks and suggests assuming at least one peer is honest. It concludes with a proposed use case where an SPV client retrieves compact non-interactive proofs-of-inclusion for its transactions without downloading every intervening block header. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_BIP-Draft-Atomic-Cross-Chain-Transfer-Protocol.xml b/static/bitcoin-dev/April_2014/combined_BIP-Draft-Atomic-Cross-Chain-Transfer-Protocol.xml index fefe0d6945..4938e71343 100644 --- a/static/bitcoin-dev/April_2014/combined_BIP-Draft-Atomic-Cross-Chain-Transfer-Protocol.xml +++ b/static/bitcoin-dev/April_2014/combined_BIP-Draft-Atomic-Cross-Chain-Transfer-Protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Draft: Atomic Cross Chain Transfer Protocol - 2023-08-01T09:09:21.063921+00:00 + 2025-10-11T21:35:50.434310+00:00 + python-feedgen Tier Nolan 2014-04-30 23:02:41+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP Draft: Atomic Cross Chain Transfer Protocol - 2023-08-01T09:09:21.063921+00:00 + 2025-10-11T21:35:50.434493+00:00 - In a recent update, the author has released a new version of the protocol for trading between testnet and mainnet. This updated version simplifies the process by only requiring non-standard transactions on one network. The next step is to implement a TCP/RPC server that will facilitate the trading between the two networks. Importantly, the new version allows for timeouts of less than 24 hours.In response to Tier Nolan's question, Luke Dashjr explained that the names TX1 and TX2 originated from the original thread where the idea was first outlined. He updated the names as per the suggestion. Furthermore, Dashjr clarified that the bail-in transactions are only signed by one party and kept secret until the refund/payout transactions are properly signed. This approach helps mitigate malleability risks. The refund principle used in this protocol is similar to that of payment channels.Regarding the implementation and testing of the system, the author stated that it is still in draft mode. Although there is an existing (almost) implementation of the system, a full implementation is the next step. In response to Dashjr's recommendation of changing the protocol from JSON-RPC to some extension of the Payment Protocol, the author expressed agreement to explore this possibility.In an email exchange on April 30, 2014, Dashjr requested meaningful identifiers instead of using TX0, TX1, etc., and the names were updated accordingly. It was emphasized that the bail-in transactions are only signed by one party and kept secret until the refund/payout transactions are properly signed, with a third party acting as a safeguard against malleability risks. The full implementation of the system was planned, although there was already an available implementation. The purpose of OP_EQUAL_VERIFY in TX4 was clarified as a typo. Dashjr suggested separate BIPs for the exchange itself and the protocol to negotiate it, and also recommended compressed keys to discourage the use of uncompressed ones. Additionally, the use of MIME was proposed as an alternative to JSON-RPC for the protocol.On April 30, 2014, Tier Nolan created a BIP in response to high demand for cross-chain atomic transfers. The proposed sequence of signing transactions, labeled TX0, TX1, and TX2, requires both parties to sign before the transaction can be completed. However, concerns were raised about the feasibility of this proposal, particularly with regards to the potential for one party to walk away or hold the funds hostage after signing TX0 but before signing TX2. The purpose of OP_EQUAL_VERIFY in TX4 remains unclear. Nolan's suggestion to use JSON-RPC for negotiation and compressed keys to discourage the use of uncompressed ones is being considered. It is also suggested that separate BIPs should be created for the exchange itself and the protocol used to negotiate the exchange.Overall, the BIP for cross-chain atomic transfers has garnered significant attention and offers a simplified approach through hash locking. Interested individuals can find the full BIP on GitHub, which includes codes for OP_HASH160 OP_EQUAL_VERIFY [public key] OP_CHECKSIG and OP_HASH160 OP_EQUAL_VERIFY OP_N [public key 1] ... [public key m] OP_M OP_CHECK_MULTISIG. 2014-04-30T23:02:41+00:00 + In a recent update, the author has released a new version of the protocol for trading between testnet and mainnet. This updated version simplifies the process by only requiring non-standard transactions on one network. The next step is to implement a TCP/RPC server that will facilitate the trading between the two networks. Importantly, the new version allows for timeouts of less than 24 hours.In response to Tier Nolan's question, Luke Dashjr explained that the names TX1 and TX2 originated from the original thread where the idea was first outlined. He updated the names as per the suggestion. Furthermore, Dashjr clarified that the bail-in transactions are only signed by one party and kept secret until the refund/payout transactions are properly signed. This approach helps mitigate malleability risks. The refund principle used in this protocol is similar to that of payment channels.Regarding the implementation and testing of the system, the author stated that it is still in draft mode. Although there is an existing (almost) implementation of the system, a full implementation is the next step. In response to Dashjr's recommendation of changing the protocol from JSON-RPC to some extension of the Payment Protocol, the author expressed agreement to explore this possibility.In an email exchange on April 30, 2014, Dashjr requested meaningful identifiers instead of using TX0, TX1, etc., and the names were updated accordingly. It was emphasized that the bail-in transactions are only signed by one party and kept secret until the refund/payout transactions are properly signed, with a third party acting as a safeguard against malleability risks. The full implementation of the system was planned, although there was already an available implementation. The purpose of OP_EQUAL_VERIFY in TX4 was clarified as a typo. Dashjr suggested separate BIPs for the exchange itself and the protocol to negotiate it, and also recommended compressed keys to discourage the use of uncompressed ones. Additionally, the use of MIME was proposed as an alternative to JSON-RPC for the protocol.On April 30, 2014, Tier Nolan created a BIP in response to high demand for cross-chain atomic transfers. The proposed sequence of signing transactions, labeled TX0, TX1, and TX2, requires both parties to sign before the transaction can be completed. However, concerns were raised about the feasibility of this proposal, particularly with regards to the potential for one party to walk away or hold the funds hostage after signing TX0 but before signing TX2. The purpose of OP_EQUAL_VERIFY in TX4 remains unclear. Nolan's suggestion to use JSON-RPC for negotiation and compressed keys to discourage the use of uncompressed ones is being considered. It is also suggested that separate BIPs should be created for the exchange itself and the protocol used to negotiate the exchange.Overall, the BIP for cross-chain atomic transfers has garnered significant attention and offers a simplified approach through hash locking. Interested individuals can find the full BIP on GitHub, which includes codes for OP_HASH160 OP_EQUAL_VERIFY [public key] OP_CHECKSIG and OP_HASH160 OP_EQUAL_VERIFY OP_N [public key 1] ... [public key m] OP_M OP_CHECK_MULTISIG. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_BIP-Hash-Locked-Transaction.xml b/static/bitcoin-dev/April_2014/combined_BIP-Hash-Locked-Transaction.xml index 535a191479..8d68fb3c46 100644 --- a/static/bitcoin-dev/April_2014/combined_BIP-Hash-Locked-Transaction.xml +++ b/static/bitcoin-dev/April_2014/combined_BIP-Hash-Locked-Transaction.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP - Hash Locked Transaction - 2023-08-01T09:01:02.525198+00:00 + 2025-10-11T21:36:49.933388+00:00 + python-feedgen Tier Nolan 2014-04-26 11:31:44+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - BIP - Hash Locked Transaction - 2023-08-01T09:01:02.525198+00:00 + 2025-10-11T21:36:49.933564+00:00 - In April 2014, Jorge Timón proposed a change to the "IsStandard" script, suggesting replacing the "AcceptToMemoryPool" function with an "IsStandard(scriptPubKey, scriptSig)" method. The proposal aimed to simplify the standard script check process by checking for pattern matches. The idea of implementing a generic Policy interface that extends to StandardPolicy was also discussed, which would allow miners to implement their own policies without starting from scratch. Peter Todd and Tier Nolan discussed Bitcoin Improvement Proposals (BIPs), with Todd suggesting examining how the isStandard() rules could be removed instead of creating new format-specific types. Todd proposed a whitelist of low-risk opcodes as a compromise. Todd acknowledged that removing isStandard() would be a bigger change than adding one new type. Gregory Maxwell and Peter Todd discussed the implementation of oracles in transactions. They suggested using EC public points instead of hash-locked transactions for oracles. This approach allows the oracle to prove ownership by signing a challenge message and conceals the purpose of the oracle from itself. Maxwell proposed a BIP to examine the possibility of removing the IsStandard() rules. Sigops and Luke-Jr's accept non-standard patch were also mentioned in the discussion.Peter Todd discussed his research on implementing oracles in blockchain transactions, suggesting that using ECC secret keys revealed by the oracle is a better method than hash-locked transactions. The transaction can include keys derived from the oracle keys, blinding the oracle to the purposes it is being used for. The use of EC public points for oracles was agreed upon, and Reality Keys was referenced as an example.Alex Mizrahi suggested an approach where an oracle associates a hash with each possible outcome and reveals a preimage to unlock the transaction. Peter Todd noted that revealing ECC secret keys works better in every case except for larger transactions.On April 25, 2014, Luke-Jr commented on a BIP, expressing that he thought it was useless and could not be made secure. The BIP involved hash locking to release the coin on another chain. Luke-Jr clarified that the hash locking is required for the particular protocol.Tier Nolan proposed a new system for atomic cross-chain transfers, involving hash-locking outputs where a user needs to provide x corresponding to hash(x) to spend an output. This system would link two chains together. Nolan suggested embedding this system into a P2SH output as an add-on to standard transactions. Luke expressed skepticism about the proposal, stating that he believed it couldn't be made secure. 2014-04-26T11:31:44+00:00 + In April 2014, Jorge Timón proposed a change to the "IsStandard" script, suggesting replacing the "AcceptToMemoryPool" function with an "IsStandard(scriptPubKey, scriptSig)" method. The proposal aimed to simplify the standard script check process by checking for pattern matches. The idea of implementing a generic Policy interface that extends to StandardPolicy was also discussed, which would allow miners to implement their own policies without starting from scratch. Peter Todd and Tier Nolan discussed Bitcoin Improvement Proposals (BIPs), with Todd suggesting examining how the isStandard() rules could be removed instead of creating new format-specific types. Todd proposed a whitelist of low-risk opcodes as a compromise. Todd acknowledged that removing isStandard() would be a bigger change than adding one new type. Gregory Maxwell and Peter Todd discussed the implementation of oracles in transactions. They suggested using EC public points instead of hash-locked transactions for oracles. This approach allows the oracle to prove ownership by signing a challenge message and conceals the purpose of the oracle from itself. Maxwell proposed a BIP to examine the possibility of removing the IsStandard() rules. Sigops and Luke-Jr's accept non-standard patch were also mentioned in the discussion.Peter Todd discussed his research on implementing oracles in blockchain transactions, suggesting that using ECC secret keys revealed by the oracle is a better method than hash-locked transactions. The transaction can include keys derived from the oracle keys, blinding the oracle to the purposes it is being used for. The use of EC public points for oracles was agreed upon, and Reality Keys was referenced as an example.Alex Mizrahi suggested an approach where an oracle associates a hash with each possible outcome and reveals a preimage to unlock the transaction. Peter Todd noted that revealing ECC secret keys works better in every case except for larger transactions.On April 25, 2014, Luke-Jr commented on a BIP, expressing that he thought it was useless and could not be made secure. The BIP involved hash locking to release the coin on another chain. Luke-Jr clarified that the hash locking is required for the particular protocol.Tier Nolan proposed a new system for atomic cross-chain transfers, involving hash-locking outputs where a user needs to provide x corresponding to hash(x) to spend an output. This system would link two chains together. Nolan suggested embedding this system into a P2SH output as an add-on to standard transactions. Luke expressed skepticism about the proposal, stating that he believed it couldn't be made secure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_BIP-Selector-Script.xml b/static/bitcoin-dev/April_2014/combined_BIP-Selector-Script.xml index 776dbbc579..a3a68cbe5e 100644 --- a/static/bitcoin-dev/April_2014/combined_BIP-Selector-Script.xml +++ b/static/bitcoin-dev/April_2014/combined_BIP-Selector-Script.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP - Selector Script - 2023-08-01T09:00:41.141042+00:00 + 2025-10-11T21:35:37.682333+00:00 + python-feedgen Mark Friedenbach 2014-04-26 17:00:23+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP - Selector Script - 2023-08-01T09:00:41.141042+00:00 + 2025-10-11T21:35:37.682515+00:00 - The discussion revolves around the need for standardization and interoperability between software in Bitcoin. While miners have the freedom to decide their own inclusion rules, it is generally accepted that transactions should be updated in the reference client to increase their chances of being accepted. There is ongoing discussion about a softfork to redo the Script language, but this will take time before it can be implemented.In an email conversation, Tier Nolan suggests that a BIP may not be necessary for cross-chain systems unless transactions are accepted in all chains. Luke Dashjr explains that BIPs are meant to define standards for interoperability, but they do not force nodes to adopt any specific policy. However, a BIP for cross-chain trading could help convince nodes to relay the transactions. It is also noted that fixing the malleability issue is crucial for secure transfers.In April 2014, Tier Nolan raises a concern about the lack of use cases defined in a Bitcoin Improvement Proposal (BIP). The response clarifies that the specification was simply unclear and that one use case would suffice. The proposal aims to allow spending to be controlled by the publication of information in another transaction, ensuring atomic completion of transactions.Peter Todd warns that P2SH redeemScripts have a size limit of 520 bytes, which may pose limitations for complex transactions. However, he notes that these transactions can already be mined into blocks and is not a protocol change. The email exchange also includes an advertisement for eXo Platform, a collaboration tool.Tier Nolan proposes a BIP to allow spenders to choose one of multiple standard scripts for spending outputs as part of the atomic cross-chain transfer protocol. Luke-Jr suggests that one use case should be enough and discusses the difficulty of getting non-standard transactions confirmed on other coins. He also recommends fixing the malleability issue for secure transfers and suggests the possibility of a future BIP for cross-chain transfers.In an email thread, Luke-Jr suggests linking to a GitHub repository instead of the current link provided. Peter Todd points out the size limit of P2SH redeemScripts. The email is signed with a digital signature.The proposed BIP allows spenders to choose from multiple standard scripts for spending outputs in the atomic cross-chain transfer protocol. It also suggests requiring P2SH and potentially implementing "Multi-P2SH" through a soft fork. The benefits of this change would be similar to MAST, but it would require further development and consensus. 2014-04-26T17:00:23+00:00 + The discussion revolves around the need for standardization and interoperability between software in Bitcoin. While miners have the freedom to decide their own inclusion rules, it is generally accepted that transactions should be updated in the reference client to increase their chances of being accepted. There is ongoing discussion about a softfork to redo the Script language, but this will take time before it can be implemented.In an email conversation, Tier Nolan suggests that a BIP may not be necessary for cross-chain systems unless transactions are accepted in all chains. Luke Dashjr explains that BIPs are meant to define standards for interoperability, but they do not force nodes to adopt any specific policy. However, a BIP for cross-chain trading could help convince nodes to relay the transactions. It is also noted that fixing the malleability issue is crucial for secure transfers.In April 2014, Tier Nolan raises a concern about the lack of use cases defined in a Bitcoin Improvement Proposal (BIP). The response clarifies that the specification was simply unclear and that one use case would suffice. The proposal aims to allow spending to be controlled by the publication of information in another transaction, ensuring atomic completion of transactions.Peter Todd warns that P2SH redeemScripts have a size limit of 520 bytes, which may pose limitations for complex transactions. However, he notes that these transactions can already be mined into blocks and is not a protocol change. The email exchange also includes an advertisement for eXo Platform, a collaboration tool.Tier Nolan proposes a BIP to allow spenders to choose one of multiple standard scripts for spending outputs as part of the atomic cross-chain transfer protocol. Luke-Jr suggests that one use case should be enough and discusses the difficulty of getting non-standard transactions confirmed on other coins. He also recommends fixing the malleability issue for secure transfers and suggests the possibility of a future BIP for cross-chain transfers.In an email thread, Luke-Jr suggests linking to a GitHub repository instead of the current link provided. Peter Todd points out the size limit of P2SH redeemScripts. The email is signed with a digital signature.The proposed BIP allows spenders to choose from multiple standard scripts for spending outputs in the atomic cross-chain transfer protocol. It also suggests requiring P2SH and potentially implementing "Multi-P2SH" through a soft fork. The benefits of this change would be similar to MAST, but it would require further development and consensus. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_BIP0071-media-type-registration-with-IANA.xml b/static/bitcoin-dev/April_2014/combined_BIP0071-media-type-registration-with-IANA.xml index 3df3a56104..c2bd29adf7 100644 --- a/static/bitcoin-dev/April_2014/combined_BIP0071-media-type-registration-with-IANA.xml +++ b/static/bitcoin-dev/April_2014/combined_BIP0071-media-type-registration-with-IANA.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP0071 media type registration with IANA - 2023-08-01T09:04:13.796877+00:00 + 2025-10-11T21:36:13.804140+00:00 + python-feedgen Jannis Froese 2014-04-26 21:16:48+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP0071 media type registration with IANA - 2023-08-01T09:04:13.796877+00:00 + 2025-10-11T21:36:13.804298+00:00 - During a discussion on Bitcoin's registration as a vendor, Mike Hearn expressed doubts about its feasibility since Bitcoin is not considered a vendor. However, according to RFC 6838, the Bitcoin Foundation or Gavin himself could register a vendor tree for Bitcoin. This would involve obtaining the subtree named vdn.bitcoin, which should not pose any problems. Despite this possibility, there was skepticism regarding the need to pursue this registration, as the chances of a string collision are low and the current mime types were deemed sufficient. It seemed that registering as a vendor was more about adhering to proper procedures than anything else.In an email sent to the Bitcoin-development mailing list, Ross Nicoll raised concerns about the MIME types in BIP0071. He pointed out that these MIME types are not IANA registered and are unlikely to be accepted in their current state. Ross referred to the latest RFC on media type registration, which imposes restrictions on what can be included in the default "application/" namespace. The preference is for it to be an ISO standard or similar. However, Ross suggested that alternative options, such as using vendor namespaces, might be more feasible. He cited the example of Powerpoint 2007's "application/vnd.openxmlformats-officedocument.presentationml.presentation" as a potential model. As a solution, Ross proposed registering a Bitcoin vendor namespace with IANA and allocating specific MIME types for Bitcoin-related purposes, such as "application/vnd.bitcoin.payment.request", "application/vnd.bitcoin.payment.payment", and "application/vnd.bitcoin.payment.ack". Despite Ross's suggestion, some participants in the thread expressed doubt about the viability of this approach due to Bitcoin not being traditionally considered a vendor. Additionally, the likelihood of a string collision occurring is extremely low, and the current mime types were seen as adequate. Ross sought feedback from the group on his proposal. 2014-04-26T21:16:48+00:00 + During a discussion on Bitcoin's registration as a vendor, Mike Hearn expressed doubts about its feasibility since Bitcoin is not considered a vendor. However, according to RFC 6838, the Bitcoin Foundation or Gavin himself could register a vendor tree for Bitcoin. This would involve obtaining the subtree named vdn.bitcoin, which should not pose any problems. Despite this possibility, there was skepticism regarding the need to pursue this registration, as the chances of a string collision are low and the current mime types were deemed sufficient. It seemed that registering as a vendor was more about adhering to proper procedures than anything else.In an email sent to the Bitcoin-development mailing list, Ross Nicoll raised concerns about the MIME types in BIP0071. He pointed out that these MIME types are not IANA registered and are unlikely to be accepted in their current state. Ross referred to the latest RFC on media type registration, which imposes restrictions on what can be included in the default "application/" namespace. The preference is for it to be an ISO standard or similar. However, Ross suggested that alternative options, such as using vendor namespaces, might be more feasible. He cited the example of Powerpoint 2007's "application/vnd.openxmlformats-officedocument.presentationml.presentation" as a potential model. As a solution, Ross proposed registering a Bitcoin vendor namespace with IANA and allocating specific MIME types for Bitcoin-related purposes, such as "application/vnd.bitcoin.payment.request", "application/vnd.bitcoin.payment.payment", and "application/vnd.bitcoin.payment.ack". Despite Ross's suggestion, some participants in the thread expressed doubt about the viability of this approach due to Bitcoin not being traditionally considered a vendor. Additionally, the likelihood of a string collision occurring is extremely low, and the current mime types were seen as adequate. Ross sought feedback from the group on his proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_BIP32-wallet-structure-in-use-Remove-it-.xml b/static/bitcoin-dev/April_2014/combined_BIP32-wallet-structure-in-use-Remove-it-.xml index 6d569b5ee3..1b8c720910 100644 --- a/static/bitcoin-dev/April_2014/combined_BIP32-wallet-structure-in-use-Remove-it-.xml +++ b/static/bitcoin-dev/April_2014/combined_BIP32-wallet-structure-in-use-Remove-it-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - BIP32 "wallet structure" in use? Remove it? - 2023-08-01T09:00:19.965295+00:00 + Combined summary - BIP32 "wallet structure" in use? Remove it? + 2025-10-11T21:35:52.557953+00:00 + python-feedgen Jeff Garzik 2014-04-26 16:03:31+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 - Combined summary - BIP32 "wallet structure" in use? Remove it? - 2023-08-01T09:00:19.965295+00:00 + Combined summary - BIP32 "wallet structure" in use? Remove it? + 2025-10-11T21:35:52.558126+00:00 - The email conversation between Gregory Maxwell and Jim discusses the possibility of creating a lowest common denominator for wallet interoperability in Bitcoin. Jim is concerned about losing intra-client HD compatibility for BIP32 wallets, which could result in vendor lock-in for users. Gregory argues that achieving interoperability at this level is not possible in general, except as an explicit compatibility feature. He points out that the structure of the derivation defines and constrains functionality, so wallets cannot be structure compatible unless they have the same features and behavior with respect to key management.Gregory suggests that supporting a compatibility mode where a wallet has just a subset of features that work when loaded into different systems could be possible but doubts that it would be widely used. He believes that heavily constraining functionality to achieve interoperability is too high a price to pay. He also argues that calling it "vendor lock-in" is overblown because users can transfer their funds if they want to change wallets. The discussion also involves Jeff Garzik, a Bitcoin core developer and open-source evangelist.In another email conversation between Pavol Rusnak and Tier Nolan, the topic of importing an unknown wallet is discussed. Tier Nolan suggests having a defined way to import such wallets, but Pavol Rusnak dismisses it as impossible due to the lack of knowledge about the wallet's structure. Pieter, who is part of the conversation, proposes a solution by defining something like "BIP44 import-compatible" to guarantee not losing any funds when importing even if the application doesn't support all BIP44 features.In a discussion thread from 2014, Tier Nolan suggests that having a defined way to import an unknown wallet could be a solution. However, another participant disagrees and states that there is no way to import a wallet if its structure is not known. They explain that it may be possible to find all the addresses for a root seed given a blockchain, but this would not work if the keyspace is almost infinite due to the potential variability of the wallet hierarchy.Tamas Blummer responds to Tier Nolan's suggestion and states that it is possible to discover any funds associated with a seed, provided there are set limits to the gap of address use, depth of hierarchy, and gap in use of parallel branches. He recommends using limits of 20, 6, and 0 respectively. Tamas notes that there is already a gap in parallel branches that fails with BIP64 as it starts with m/64'/... without having m/63'.In another email conversation between Tamas Blummer and Tier Nolan, they discuss the possibility of discovering any funds associated with a seed. Blummer suggests that this is possible given set limits including gap of address use, depth of hierarchy, and gap in use of parallel branches. Nolan suggests having a defined way to import an unknown wallet and defining gap space and search ordering. They agree that given a blockchain and a root seed, it should be possible to find all the addresses for that root seed regardless of the wallet hierarchy used.The conversation between Bitcoin developers Gregory Maxwell and Thomas Voegtlin revolves around the idea of wallet interoperability. Maxwell argues that achieving full wallet interoperability is not possible without heavily constraining functionality, which would hinder progress and innovation in developing new features. He suggests that a compatibility mode where a wallet has a subset of features could be supported. Voegtlin agrees with Maxwell's stance, stating that the cost of interoperability is too high and partial compatibility could result in users being unable to recover all their funds when using another wallet. The challenges involved in making a wallet portable between systems, including key management and metadata handling, are also discussed.A comment is made on Github regarding the BIP43 pull request, which aims to add a "purpose" of 0' for single account wallets. This will allow for backwards compatibility and interoperability for existing single account BIP32 implementations. However, it would require a new BIP and wouldn't follow the BIP43 recommendation unless BIP0 is obtained. Mike Hearn questions the future popularity of cloning wallets between devices and suggests that people may want to use different UIs to access the same wallets, which would require sharing key trees. However, full-blown wallet metadata sync would also be needed, resulting in a complex compatibility matrix.The discussion revolves around the potential popularity of cloning wallets between devices in the future. Currently, there is no provision for sharing a wallet between different platforms, and users have to choose one or manually split their funds. However, many people would prefer using different UIs to access the same wallets, which can be achieved by sharing key trees and full-blown wallet metadata sync. A complex compatibility matrix may emerge as a result.In an email exchange, Jim expresses concern over the potential loss of intra-client HD compatibility for BIP32 wallets, which could affect millions of users in the next year. He suggests creating an "HD Basic" lowest common denominator for interoperability, which would allow entry-level users to 2014-04-26T16:03:31+00:00 + The email conversation between Gregory Maxwell and Jim discusses the possibility of creating a lowest common denominator for wallet interoperability in Bitcoin. Jim is concerned about losing intra-client HD compatibility for BIP32 wallets, which could result in vendor lock-in for users. Gregory argues that achieving interoperability at this level is not possible in general, except as an explicit compatibility feature. He points out that the structure of the derivation defines and constrains functionality, so wallets cannot be structure compatible unless they have the same features and behavior with respect to key management.Gregory suggests that supporting a compatibility mode where a wallet has just a subset of features that work when loaded into different systems could be possible but doubts that it would be widely used. He believes that heavily constraining functionality to achieve interoperability is too high a price to pay. He also argues that calling it "vendor lock-in" is overblown because users can transfer their funds if they want to change wallets. The discussion also involves Jeff Garzik, a Bitcoin core developer and open-source evangelist.In another email conversation between Pavol Rusnak and Tier Nolan, the topic of importing an unknown wallet is discussed. Tier Nolan suggests having a defined way to import such wallets, but Pavol Rusnak dismisses it as impossible due to the lack of knowledge about the wallet's structure. Pieter, who is part of the conversation, proposes a solution by defining something like "BIP44 import-compatible" to guarantee not losing any funds when importing even if the application doesn't support all BIP44 features.In a discussion thread from 2014, Tier Nolan suggests that having a defined way to import an unknown wallet could be a solution. However, another participant disagrees and states that there is no way to import a wallet if its structure is not known. They explain that it may be possible to find all the addresses for a root seed given a blockchain, but this would not work if the keyspace is almost infinite due to the potential variability of the wallet hierarchy.Tamas Blummer responds to Tier Nolan's suggestion and states that it is possible to discover any funds associated with a seed, provided there are set limits to the gap of address use, depth of hierarchy, and gap in use of parallel branches. He recommends using limits of 20, 6, and 0 respectively. Tamas notes that there is already a gap in parallel branches that fails with BIP64 as it starts with m/64'/... without having m/63'.In another email conversation between Tamas Blummer and Tier Nolan, they discuss the possibility of discovering any funds associated with a seed. Blummer suggests that this is possible given set limits including gap of address use, depth of hierarchy, and gap in use of parallel branches. Nolan suggests having a defined way to import an unknown wallet and defining gap space and search ordering. They agree that given a blockchain and a root seed, it should be possible to find all the addresses for that root seed regardless of the wallet hierarchy used.The conversation between Bitcoin developers Gregory Maxwell and Thomas Voegtlin revolves around the idea of wallet interoperability. Maxwell argues that achieving full wallet interoperability is not possible without heavily constraining functionality, which would hinder progress and innovation in developing new features. He suggests that a compatibility mode where a wallet has a subset of features could be supported. Voegtlin agrees with Maxwell's stance, stating that the cost of interoperability is too high and partial compatibility could result in users being unable to recover all their funds when using another wallet. The challenges involved in making a wallet portable between systems, including key management and metadata handling, are also discussed.A comment is made on Github regarding the BIP43 pull request, which aims to add a "purpose" of 0' for single account wallets. This will allow for backwards compatibility and interoperability for existing single account BIP32 implementations. However, it would require a new BIP and wouldn't follow the BIP43 recommendation unless BIP0 is obtained. Mike Hearn questions the future popularity of cloning wallets between devices and suggests that people may want to use different UIs to access the same wallets, which would require sharing key trees. However, full-blown wallet metadata sync would also be needed, resulting in a complex compatibility matrix.The discussion revolves around the potential popularity of cloning wallets between devices in the future. Currently, there is no provision for sharing a wallet between different platforms, and users have to choose one or manually split their funds. However, many people would prefer using different UIs to access the same wallets, which can be achieved by sharing key trees and full-blown wallet metadata sync. A complex compatibility matrix may emerge as a result.In an email exchange, Jim expresses concern over the potential loss of intra-client HD compatibility for BIP32 wallets, which could affect millions of users in the next year. He suggests creating an "HD Basic" lowest common denominator for interoperability, which would allow entry-level users to - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Bitcoin-Core-Nightly-Builds.xml b/static/bitcoin-dev/April_2014/combined_Bitcoin-Core-Nightly-Builds.xml index 694593c5fc..d4b34de659 100644 --- a/static/bitcoin-dev/April_2014/combined_Bitcoin-Core-Nightly-Builds.xml +++ b/static/bitcoin-dev/April_2014/combined_Bitcoin-Core-Nightly-Builds.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core Nightly Builds - 2023-08-01T08:46:53.051562+00:00 + 2025-10-11T21:36:24.419638+00:00 + python-feedgen Warren Togami Jr. 2014-05-22 02:28:56+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core Nightly Builds - 2023-08-01T08:46:53.051562+00:00 + 2025-10-11T21:36:24.419802+00:00 - Bitcoin Core developers are preparing to release version 0.9.2, which will primarily focus on bug fixes, cleanup, and translation updates. This upcoming release is expected to be available in a few weeks from the announcement made by Warren Togami Jr. on April 16, 2014. In order to ensure a smooth and polished release, power users are encouraged to test the master branch using unofficial nightly builds. By doing so, they can help identify any bugs and provide valuable feedback to the developers.Notably, the Bitcoin Core team has made significant progress in improving the development process for Mac users. Thanks to the efforts of Cory Fields, deterministic builds for MacOS X are now available. This means that users on MacOS X can also benefit from the latest updates and contribute to the testing and improvement of the software.Furthermore, translators are urged to take advantage of the latest code to identify and translate any strings that need attention before the next stable release. This will ensure that the software is accessible to users worldwide and language barriers are minimized.For more information on the upcoming release and how to get involved in testing and translation efforts, interested individuals can visit the BitcoinTalk forum at the provided link (https://bitcointalk.org/index.php?topic=571414.0). The forum post by Warren Togami Jr. contains detailed information about the plans for version 0.9.2 and the ways in which users can contribute to its success. 2014-05-22T02:28:56+00:00 + Bitcoin Core developers are preparing to release version 0.9.2, which will primarily focus on bug fixes, cleanup, and translation updates. This upcoming release is expected to be available in a few weeks from the announcement made by Warren Togami Jr. on April 16, 2014. In order to ensure a smooth and polished release, power users are encouraged to test the master branch using unofficial nightly builds. By doing so, they can help identify any bugs and provide valuable feedback to the developers.Notably, the Bitcoin Core team has made significant progress in improving the development process for Mac users. Thanks to the efforts of Cory Fields, deterministic builds for MacOS X are now available. This means that users on MacOS X can also benefit from the latest updates and contribute to the testing and improvement of the software.Furthermore, translators are urged to take advantage of the latest code to identify and translate any strings that need attention before the next stable release. This will ensure that the software is accessible to users worldwide and language barriers are minimized.For more information on the upcoming release and how to get involved in testing and translation efforts, interested individuals can visit the BitcoinTalk forum at the provided link (https://bitcointalk.org/index.php?topic=571414.0). The forum post by Warren Togami Jr. contains detailed information about the plans for version 0.9.2 and the ways in which users can contribute to its success. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Bitcoind-in-background-mode-for-SPV-wallets.xml b/static/bitcoin-dev/April_2014/combined_Bitcoind-in-background-mode-for-SPV-wallets.xml index bb99faa272..96e6fb6231 100644 --- a/static/bitcoin-dev/April_2014/combined_Bitcoind-in-background-mode-for-SPV-wallets.xml +++ b/static/bitcoin-dev/April_2014/combined_Bitcoind-in-background-mode-for-SPV-wallets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoind-in-background mode for SPV wallets - 2023-08-01T08:41:56.947412+00:00 + 2025-10-11T21:35:22.766045+00:00 + python-feedgen Tier Nolan 2014-05-04 21:11:27+00:00 @@ -199,13 +200,13 @@ - python-feedgen + 2 Combined summary - Bitcoind-in-background mode for SPV wallets - 2023-08-01T08:41:56.948412+00:00 + 2025-10-11T21:35:22.766261+00:00 - In an email exchange between Bitcoin Core developer Mike Hearn and Wladimir J. van der Laan, they discuss the issue of incompatibility between wallets and nodes. Hearn suggests optimizing the NAT tunneling code, adding diagnostic features to the GUI, and implementing STUN support to address the problem of users not keeping their computers switched on all the time. Van der Laan agrees with Hearn's proposal but suggests creating a separate "node control" user interface instead of controlling the node from the wallet. However, he acknowledges that initially people may not know when or why to install this separate interface, so he suggests packaging it with wallets.Another topic discussed on the Bitcoin-development mailing list is the need to improve reachability for bitcoind instances. Slush suggests implementing a self-test feature and IPv6 tunneling to enhance reachability. Gregory Maxwell argues that existing implementations are inefficient, but he believes that improvements in implementation can address the low resource requirements of the protocol. The main constraint with home devices is not their power but the fact that people no longer keep computers switched on all the time. Suggestions to address this issue include optimizing NAT tunneling code, adding diagnostic features to the GUI, and implementing STUN support.Tamas Blummer and Wladimir have an email conversation about SPV wallets and the need for a lightweight bitcoin router or "core" that can be easily deployed anywhere. Blummer suggests that the index should be specific to added features and the subset of the blockchain relevant to the wallet. He also proposes serving headers as default, with the option to configure storing and serving full blocks based on bandwidth and available space. Wladimir agrees with these suggestions and proposes adding an RPC call for an "address -> utxo" query. They also discuss integrating the torrent download of bootstrap.dat into bitcoind to improve synchronization.Mark Friedenbach mentions that there is a reasonable pathway to do everything in-protocol without introducing external dependencies. He implemented headers first, which saturates residential broadband and copes with unreliable peers.In an email thread from April 9, 2014, slush and Laszlo discuss the slow deployment of IPv6 and ways to make instances IPv6-reachable automatically. Teredo is mentioned as a potential solution, but security settings need to be considered. Laszlo suggests adding an IPv6 checkbox in the settings with a link to an explanation or a built-in checker for reachability.There is a need for a lightweight bitcoin router or "core" that can be easily deployed anywhere. Bundling core with SPV clients would not improve anything as it would make the computer unusable every time the wallet is started. Instead, converting hidden nodes to publicly reachable nodes may be a more effective way to attract fresh instances. Wladimir proposes an interface to bitcoind to allow 'running with full node', which could benefit other clients as well.In an email exchange, slush suggests integrating the torrent download of bootstrap.dat into bitcoind to improve synchronization. Wladimir suggests parallel block download instead of involving BitTorrent.The Bitcoin-development mailing list discusses various ways to improve the Bitcoin network. Marek suggests integrating the torrent download of bootstrap.dat into bitcoind to attract more users. Slush suggests finding ways to expose existing bitcoind instances to the internet or provide self-tests for reachability. Gregory Maxwell emphasizes the need for improvements in existing implementations. Justus Ranvier challenges claims about resource usage, suggesting that full nodes can be operated with fewer resources than current implementations use.In an email thread, Thomas Voegtlin and Gregory Maxwell discuss the resource usage of Electrum and the potential for adding an RPC call for an "address to utxo" query. Wladimir also contributes to the conversation.Gregory Maxwell denies claims about a broken incentive model and argues that full nodes can be operated with fewer resources than current implementations use. He refers to archives of the mailing list where more people confirm the resource usage problem than deny it.Justus Ranvier suggests changing the network design if the security relies on a flawed incentive model. However, others argue that suitable software improvements can reduce resource requirements for running a full node. The main cost would be setting up the system, which bundling could potentially resolve.In an email exchange, Wladimir expresses concern over the lack of resources being volunteered to support the Bitcoin network. Justus Ranvier suggests a solution to quickly add more nodes and separate the wallet from Bitcoin Core. Wladimir welcomes pull requests for solutions.On April 9th, 2014, Wladimir proposes adding an option to popular SPV wallets to run a bitcoind process in the background to address the decrease in the number of full nodes.In an email conversation, Tamas Blummer suggests that the Simplified Payment Verification (SPV) is a sufficient API to a trusted node to build sophisticated features that are not offered by the core. He also mentions the need for a lightweight bitcoin 2014-05-04T21:11:27+00:00 + In an email exchange between Bitcoin Core developer Mike Hearn and Wladimir J. van der Laan, they discuss the issue of incompatibility between wallets and nodes. Hearn suggests optimizing the NAT tunneling code, adding diagnostic features to the GUI, and implementing STUN support to address the problem of users not keeping their computers switched on all the time. Van der Laan agrees with Hearn's proposal but suggests creating a separate "node control" user interface instead of controlling the node from the wallet. However, he acknowledges that initially people may not know when or why to install this separate interface, so he suggests packaging it with wallets.Another topic discussed on the Bitcoin-development mailing list is the need to improve reachability for bitcoind instances. Slush suggests implementing a self-test feature and IPv6 tunneling to enhance reachability. Gregory Maxwell argues that existing implementations are inefficient, but he believes that improvements in implementation can address the low resource requirements of the protocol. The main constraint with home devices is not their power but the fact that people no longer keep computers switched on all the time. Suggestions to address this issue include optimizing NAT tunneling code, adding diagnostic features to the GUI, and implementing STUN support.Tamas Blummer and Wladimir have an email conversation about SPV wallets and the need for a lightweight bitcoin router or "core" that can be easily deployed anywhere. Blummer suggests that the index should be specific to added features and the subset of the blockchain relevant to the wallet. He also proposes serving headers as default, with the option to configure storing and serving full blocks based on bandwidth and available space. Wladimir agrees with these suggestions and proposes adding an RPC call for an "address -> utxo" query. They also discuss integrating the torrent download of bootstrap.dat into bitcoind to improve synchronization.Mark Friedenbach mentions that there is a reasonable pathway to do everything in-protocol without introducing external dependencies. He implemented headers first, which saturates residential broadband and copes with unreliable peers.In an email thread from April 9, 2014, slush and Laszlo discuss the slow deployment of IPv6 and ways to make instances IPv6-reachable automatically. Teredo is mentioned as a potential solution, but security settings need to be considered. Laszlo suggests adding an IPv6 checkbox in the settings with a link to an explanation or a built-in checker for reachability.There is a need for a lightweight bitcoin router or "core" that can be easily deployed anywhere. Bundling core with SPV clients would not improve anything as it would make the computer unusable every time the wallet is started. Instead, converting hidden nodes to publicly reachable nodes may be a more effective way to attract fresh instances. Wladimir proposes an interface to bitcoind to allow 'running with full node', which could benefit other clients as well.In an email exchange, slush suggests integrating the torrent download of bootstrap.dat into bitcoind to improve synchronization. Wladimir suggests parallel block download instead of involving BitTorrent.The Bitcoin-development mailing list discusses various ways to improve the Bitcoin network. Marek suggests integrating the torrent download of bootstrap.dat into bitcoind to attract more users. Slush suggests finding ways to expose existing bitcoind instances to the internet or provide self-tests for reachability. Gregory Maxwell emphasizes the need for improvements in existing implementations. Justus Ranvier challenges claims about resource usage, suggesting that full nodes can be operated with fewer resources than current implementations use.In an email thread, Thomas Voegtlin and Gregory Maxwell discuss the resource usage of Electrum and the potential for adding an RPC call for an "address to utxo" query. Wladimir also contributes to the conversation.Gregory Maxwell denies claims about a broken incentive model and argues that full nodes can be operated with fewer resources than current implementations use. He refers to archives of the mailing list where more people confirm the resource usage problem than deny it.Justus Ranvier suggests changing the network design if the security relies on a flawed incentive model. However, others argue that suitable software improvements can reduce resource requirements for running a full node. The main cost would be setting up the system, which bundling could potentially resolve.In an email exchange, Wladimir expresses concern over the lack of resources being volunteered to support the Bitcoin network. Justus Ranvier suggests a solution to quickly add more nodes and separate the wallet from Bitcoin Core. Wladimir welcomes pull requests for solutions.On April 9th, 2014, Wladimir proposes adding an option to popular SPV wallets to run a bitcoind process in the background to address the decrease in the number of full nodes.In an email conversation, Tamas Blummer suggests that the Simplified Payment Verification (SPV) is a sufficient API to a trusted node to build sophisticated features that are not offered by the core. He also mentions the need for a lightweight bitcoin - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Bug-in-2-of-3-transaction-signing-in-Bitcoind-.xml b/static/bitcoin-dev/April_2014/combined_Bug-in-2-of-3-transaction-signing-in-Bitcoind-.xml index e1b1cf68c6..552653fdd6 100644 --- a/static/bitcoin-dev/April_2014/combined_Bug-in-2-of-3-transaction-signing-in-Bitcoind-.xml +++ b/static/bitcoin-dev/April_2014/combined_Bug-in-2-of-3-transaction-signing-in-Bitcoind-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bug in 2-of-3 transaction signing in Bitcoind? - 2023-08-01T08:45:20.080850+00:00 + 2025-10-11T21:35:39.806474+00:00 + python-feedgen Matt Whitlock 2014-04-15 16:45:52+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Bug in 2-of-3 transaction signing in Bitcoind? - 2023-08-01T08:45:20.080850+00:00 + 2025-10-11T21:35:39.806634+00:00 - On April 15th, 2014, Chris Beams inquired about the availability of a source for a versatile tool that could encode, decode, hash, and derive keys. The author of the tool expressed their intent to open-source it but mentioned the need to address any remaining issues before doing so. The tool had multiple functionalities, including encoding and decoding in various formats, disassembling hex scripts, hashing using different algorithms, deriving private and public keys, and encrypting and decrypting private keys. The author also created another tool called chaintool, which allowed for tasks such as initializing cache files, adding or removing public keys or seeds, listing keys and seeds, synchronizing with the blockchain, and creating transactions.In an email exchange on the same day, Mike Belshe recommended btcd, the Go implementation of bitcoind, due to its superior error and diagnostic messages. The conversation also involved Matt Whitlock discussing a C++ tool developed by his team. This tool provided key and address conversions, hash functions, encoding and decoding, script disassembly, BIP38 encryption/decryption, Shamir Secret Sharing, transaction building, and signing. The tool included its own wallet and UTXO cache, which synced with bitcoind's block data files. It could generate multi-sig P2SH addresses from public seeds, allowing testing by sending Bitcoin to those addresses and then creating and signing transactions. The tool was lauded for its user-friendly nature and simple command-line syntax.Another email thread highlighted Mike Hearn's recommendation of using btcd for debugging multi-sig transactions. During a discussion about a rejected transaction, Matt Whitlock clarified that once a transaction is in the blockchain, it cannot be accepted again to avoid double-spending. However, they had encountered difficulties getting a 2-of-3 transaction accepted. They were investigating why the transaction had been previously accepted without their knowledge. The email thread also included a promotion for a free book on Graph Databases.In April 2014, Mike Hearn described a peculiar incident where a transaction had been accepted into the blockchain but subsequent attempts to have it accepted failed. They were attempting to get a 2-of-3 transaction accepted for hours, but it was rejected by various platforms. It seemed that the transaction had already been accepted without their awareness. They were starting over to reproduce the success or failure of the transaction.Apologies were made on the Bitcoin-development mailing list for a redundant message posted after realizing that the debug.log had already indicated that the inputs were already spent. Pieter Wuille responded, stating that the first input appeared to have been spent by a similar transaction. Mike Hearn recommended checking the debug.log for the reason behind the rejection. An advertisement for a book on Graph Databases was shared in the same email thread.On April 15, 2014, Mike Hearn sent an email to the Bitcoin-development mailing list regarding a rejected transaction. He advised reviewing the debug.log to understand why the transaction was rejected. The rejection occurred because the first input had already been spent by a similar transaction. Mike suggested that version 0.9 should provide more detailed reasons for rejections. Additionally, he provided a link to download a free book called "Graph Databases," which offers guidance on graph databases and their applications.To diagnose the reason for rejection, it is recommended to consult the debug.log file, which contains comprehensive information about any errors or issues that may have occurred. Although an HTML attachment was mentioned in the original context, its relevance to the issue is unclear. Thoroughly reviewing all available information and resources is crucial for proper problem diagnosis.The user's attempt to redeem a 2-of-3 multisig P2SH output using a raw transaction is discussed. The address associated with the output and the transaction ID are provided. A raw transaction is created to spend the output, followed by its decoding for completeness. The transaction is signed using 2 of 3 keys. However, when attempting to transmit the transaction, it is rejected by the network, without specific details regarding the cause of rejection. This context pertains to a Bitcoin transaction, highlighting essential information about the raw data, inputs, and outputs involved in the process. 2014-04-15T16:45:52+00:00 + On April 15th, 2014, Chris Beams inquired about the availability of a source for a versatile tool that could encode, decode, hash, and derive keys. The author of the tool expressed their intent to open-source it but mentioned the need to address any remaining issues before doing so. The tool had multiple functionalities, including encoding and decoding in various formats, disassembling hex scripts, hashing using different algorithms, deriving private and public keys, and encrypting and decrypting private keys. The author also created another tool called chaintool, which allowed for tasks such as initializing cache files, adding or removing public keys or seeds, listing keys and seeds, synchronizing with the blockchain, and creating transactions.In an email exchange on the same day, Mike Belshe recommended btcd, the Go implementation of bitcoind, due to its superior error and diagnostic messages. The conversation also involved Matt Whitlock discussing a C++ tool developed by his team. This tool provided key and address conversions, hash functions, encoding and decoding, script disassembly, BIP38 encryption/decryption, Shamir Secret Sharing, transaction building, and signing. The tool included its own wallet and UTXO cache, which synced with bitcoind's block data files. It could generate multi-sig P2SH addresses from public seeds, allowing testing by sending Bitcoin to those addresses and then creating and signing transactions. The tool was lauded for its user-friendly nature and simple command-line syntax.Another email thread highlighted Mike Hearn's recommendation of using btcd for debugging multi-sig transactions. During a discussion about a rejected transaction, Matt Whitlock clarified that once a transaction is in the blockchain, it cannot be accepted again to avoid double-spending. However, they had encountered difficulties getting a 2-of-3 transaction accepted. They were investigating why the transaction had been previously accepted without their knowledge. The email thread also included a promotion for a free book on Graph Databases.In April 2014, Mike Hearn described a peculiar incident where a transaction had been accepted into the blockchain but subsequent attempts to have it accepted failed. They were attempting to get a 2-of-3 transaction accepted for hours, but it was rejected by various platforms. It seemed that the transaction had already been accepted without their awareness. They were starting over to reproduce the success or failure of the transaction.Apologies were made on the Bitcoin-development mailing list for a redundant message posted after realizing that the debug.log had already indicated that the inputs were already spent. Pieter Wuille responded, stating that the first input appeared to have been spent by a similar transaction. Mike Hearn recommended checking the debug.log for the reason behind the rejection. An advertisement for a book on Graph Databases was shared in the same email thread.On April 15, 2014, Mike Hearn sent an email to the Bitcoin-development mailing list regarding a rejected transaction. He advised reviewing the debug.log to understand why the transaction was rejected. The rejection occurred because the first input had already been spent by a similar transaction. Mike suggested that version 0.9 should provide more detailed reasons for rejections. Additionally, he provided a link to download a free book called "Graph Databases," which offers guidance on graph databases and their applications.To diagnose the reason for rejection, it is recommended to consult the debug.log file, which contains comprehensive information about any errors or issues that may have occurred. Although an HTML attachment was mentioned in the original context, its relevance to the issue is unclear. Thoroughly reviewing all available information and resources is crucial for proper problem diagnosis.The user's attempt to redeem a 2-of-3 multisig P2SH output using a raw transaction is discussed. The address associated with the output and the transaction ID are provided. A raw transaction is created to spend the output, followed by its decoding for completeness. The transaction is signed using 2 of 3 keys. However, when attempting to transmit the transaction, it is rejected by the network, without specific details regarding the cause of rejection. This context pertains to a Bitcoin transaction, highlighting essential information about the raw data, inputs, and outputs involved in the process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Chain-pruning.xml b/static/bitcoin-dev/April_2014/combined_Chain-pruning.xml index 7f33edc4ed..58063c1fbb 100644 --- a/static/bitcoin-dev/April_2014/combined_Chain-pruning.xml +++ b/static/bitcoin-dev/April_2014/combined_Chain-pruning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Chain pruning - 2023-08-01T08:44:30.223786+00:00 + 2025-10-11T21:36:47.810139+00:00 + python-feedgen Gregory Maxwell 2014-04-10 22:33:36+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Chain pruning - 2023-08-01T08:44:30.224790+00:00 + 2025-10-11T21:36:47.810330+00:00 - The email thread and forum discussions revolve around various proposals and ideas for improving the storage and distribution of the blockchain. One suggestion is to form "superblocks" that are chained together, which would allow participants with limited resources to serve full portions of the blockchain. However, it is noted that the block chain mostly consists of random bytes that do not compress well, making this proposal challenging to implement.Another proposal discussed is the possibility of nodes compressing and storing earlier transaction sets as archive sets to conserve disk space and network activity. The idea is that nodes could serve up these archive sets conditionally, with only a certain number open at any given time while the others remain compressed on disk. This would allow nodes to have all full transactions but still not respond about every possible transaction. The archival process could be based on a rotational request period or done periodically. Clients would have to piece together archive sets from different nodes if there aren't enough archive nodes to cover the entire chain.The concept of a fixed range for nodes that host all history is also explored. The suggestion is to burn the node implementation, block data, and live operating system on a read-only medium, allowing for the distribution of 'pieces of history' in a self-contained form. This would be useful when nodes that host all history become rare. Peer selection would involve seeking nodes that have the least rarity in the ranges they offer, rather than preferring to fetch blocks from someone with a large range if they are one of only a few nodes with that range.In a separate forum discussion, the idea of having a static node that only serves a fixed range of blocks, such as the first 100000 blocks or a specific range like block 100000-200000, is proposed. The main concern raised is why a node would not follow the consensus, as verifying blocks is relatively cheap and bandwidth is necessary for serving historic blocks. It is suggested that nodes should keep the most recent blocks for reorgs and add the fixed range they serve. Peer selection should prioritize nodes that offer the needed blocks and have the least rarity in the ranges they provide.The discussion then shifts to chain pruning, with the argument that it is more practical to specify blocks to keep in terms of megabytes rather than time, as nodes have resource constraints. A new addr field is proposed to specify how many blocks from the chain head are stored, and nodes can connect to check if their chain head minus the number of blocks stored is higher than the current chain height. If so, a getaddr request would be made to find nodes storing far enough back.Overall, these discussions highlight the ongoing efforts to find efficient storage and distribution solutions for the blockchain, taking into account factors such as compression, resource constraints, and peer selection. The proposals and ideas presented aim to address the challenges posed by the size and nature of the blockchain while ensuring the integrity and accessibility of its data. 2014-04-10T22:33:36+00:00 + The email thread and forum discussions revolve around various proposals and ideas for improving the storage and distribution of the blockchain. One suggestion is to form "superblocks" that are chained together, which would allow participants with limited resources to serve full portions of the blockchain. However, it is noted that the block chain mostly consists of random bytes that do not compress well, making this proposal challenging to implement.Another proposal discussed is the possibility of nodes compressing and storing earlier transaction sets as archive sets to conserve disk space and network activity. The idea is that nodes could serve up these archive sets conditionally, with only a certain number open at any given time while the others remain compressed on disk. This would allow nodes to have all full transactions but still not respond about every possible transaction. The archival process could be based on a rotational request period or done periodically. Clients would have to piece together archive sets from different nodes if there aren't enough archive nodes to cover the entire chain.The concept of a fixed range for nodes that host all history is also explored. The suggestion is to burn the node implementation, block data, and live operating system on a read-only medium, allowing for the distribution of 'pieces of history' in a self-contained form. This would be useful when nodes that host all history become rare. Peer selection would involve seeking nodes that have the least rarity in the ranges they offer, rather than preferring to fetch blocks from someone with a large range if they are one of only a few nodes with that range.In a separate forum discussion, the idea of having a static node that only serves a fixed range of blocks, such as the first 100000 blocks or a specific range like block 100000-200000, is proposed. The main concern raised is why a node would not follow the consensus, as verifying blocks is relatively cheap and bandwidth is necessary for serving historic blocks. It is suggested that nodes should keep the most recent blocks for reorgs and add the fixed range they serve. Peer selection should prioritize nodes that offer the needed blocks and have the least rarity in the ranges they provide.The discussion then shifts to chain pruning, with the argument that it is more practical to specify blocks to keep in terms of megabytes rather than time, as nodes have resource constraints. A new addr field is proposed to specify how many blocks from the chain head are stored, and nodes can connect to check if their chain head minus the number of blocks stored is higher than the current chain height. If so, a getaddr request would be made to find nodes storing far enough back.Overall, these discussions highlight the ongoing efforts to find efficient storage and distribution solutions for the blockchain, taking into account factors such as compression, resource constraints, and peer selection. The proposals and ideas presented aim to address the challenges posed by the size and nature of the blockchain while ensuring the integrity and accessibility of its data. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Coinbase-reallocation-to-discourage-Finney-attacks.xml b/static/bitcoin-dev/April_2014/combined_Coinbase-reallocation-to-discourage-Finney-attacks.xml index ae12264cfb..059de796cc 100644 --- a/static/bitcoin-dev/April_2014/combined_Coinbase-reallocation-to-discourage-Finney-attacks.xml +++ b/static/bitcoin-dev/April_2014/combined_Coinbase-reallocation-to-discourage-Finney-attacks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Coinbase reallocation to discourage Finney attacks - 2023-08-01T08:57:21.196856+00:00 + 2025-10-11T21:36:43.540093+00:00 + python-feedgen Jameson Lopp 2014-04-30 17:13:50+00:00 @@ -359,13 +360,13 @@ - python-feedgen + 2 Combined summary - Coinbase reallocation to discourage Finney attacks - 2023-08-01T08:57:21.199855+00:00 + 2025-10-11T21:36:43.540413+00:00 - In a series of email exchanges, various individuals express their perspectives on Bitcoin's ability to act as a long-term store of value and its relationship with human politics. Troy Benjegerdes raises concern about the unpredictable behavior of buyers and sellers, arguing that if the rules of Bitcoin are not responsive to real human needs, it becomes worthless as a store of value. Jameson Lopp disagrees, stating that Bitcoin was never intended to be a stable long-term store of value. Gareth Williams believes that Bitcoin is an elegant embodiment of artificially contrived mathematical rules, which should not be undermined by introducing unpredictable elements like human politics.Mike Hearn enters into conversations discussing the relevance of attackers in the Bitcoin network. He refers to Satoshi Nakamoto's white paper and argues that attackers are relevant to the design of the system, but not necessarily to running a node. The disagreement lies in whether Bitcoin is a democratic or trustless system. One participant believes Bitcoin is meant to be trustless, while another argues for a democratic system where voting is not required for decision-making within the network.The discussion continues with Mike Hearn discussing the importance of miners and nodes following the protocol. He distinguishes between rejecting a block at validation (which is the protocol working as intended) and reinterpreting a validated block (which undermines Bitcoin's validation and proof-of-work). The notion of attackers in the Bitcoin network is debated, with Gareth Williams asserting that Bitcoin should work correctly regardless of how someone considers themselves.The conversation also touches on the concept of Bitcoin as an embodiment of natural mathematical law versus artificially contrived mathematical rules. Some argue that Bitcoin is an elegant embodiment of useful mathematical rules, while others caution against introducing human politics that may undermine these rules. The topic of confiscating balances and proposals to implement such features are rejected, as they are seen as malicious attempts or economic illiteracy that endanger Bitcoin users.There are discussions on hashpower control in Bitcoin and the risks associated with Finney attackers. The trustless nature of Bitcoin is debated, with Gareth Williams arguing that it is a perfect trustless mathematical machine, while others suggest a shift towards a more democratic system. The importance of considering costs and benefits in discussions about changes to Bitcoin is emphasized.The author acknowledges that Bitcoin is a piece of software that encodes rules to run a community and recognizes the ongoing debate on what changes are acceptable within the social contract. The question of whether Bitcoin's users want a system that evolves or remains unchanged will likely differ on a case-by-case basis. The author also discusses the importance of a strong group consensus in protecting one's money from confiscation and highlights the significance of following simple mathematical rules to prevent theft.Overall, the context provides insights into various perspectives on Bitcoin's role as a long-term store of value, the relevance of attackers, the trustlessness of the system, the importance of consensus, and the potential risks and benefits of introducing changes to the protocol.In a series of email conversations, several individuals discussed the concept of "honest miners" and the prevention of double-spending in Bitcoin transactions. Gregory Maxwell argued that miners do not prevent double-spending but rather ignore it, while Mike Hearn defined honest miners as those who work to prevent double-spends. Jorge Timón proposed two categories of miners: "stupid miners" who decide on transactions based on reception times and "smart miners" who maximize their revenue while respecting protocol rules. The discussion also touched on the possibility of deleting or reallocating coinbases to discourage double spending, with some arguing against destroying money and suggesting reallocation instead.The conversation also delved into the trustworthiness of miners and whether they can be considered "trusted parties" in a decentralized system. Maxwell believed that miners should not be trusted individually, while another individual disagreed, stating that Bitcoin could tolerate some dishonest miners but not all of them. They also discussed proposals for improving the Bitcoin blockchain, such as preventing theft and ensuring corrupt miners do not get paid for services they did not provide.The potential consequences of double spending in Bitcoin transactions were explored in another email conversation between Mike Hearn and Dr. Andy Parkins. While Hearn suggested that occasional attempts at double spending may not cause harm, Parkins argued that widespread double spending could lead to a significant increase in fraudulent activity. This highlights the challenges facing the adoption and use of cryptocurrencies like Bitcoin in terms of security and trust.Different approaches to preventing double spending were discussed, including the Proof-of-Work (PoW) approach and the use of trusted third parties (TTPs). The advantages and disadvantages of each approach were debated, with the proposal of hybrid systems that combine PoW-based blockchains for settlements and TTP-based payment systems for small-value transactions. This would address scalability issues and retain the benefits of both approaches.Various proposals for improving the Bitcoin blockchain were mentioned, such as the use of coinbase scriptSigs for voting purposes and the establishment of a transaction "proof of publication" chain. The latter idea involved adding each transaction 2014-04-30T17:13:50+00:00 + In a series of email exchanges, various individuals express their perspectives on Bitcoin's ability to act as a long-term store of value and its relationship with human politics. Troy Benjegerdes raises concern about the unpredictable behavior of buyers and sellers, arguing that if the rules of Bitcoin are not responsive to real human needs, it becomes worthless as a store of value. Jameson Lopp disagrees, stating that Bitcoin was never intended to be a stable long-term store of value. Gareth Williams believes that Bitcoin is an elegant embodiment of artificially contrived mathematical rules, which should not be undermined by introducing unpredictable elements like human politics.Mike Hearn enters into conversations discussing the relevance of attackers in the Bitcoin network. He refers to Satoshi Nakamoto's white paper and argues that attackers are relevant to the design of the system, but not necessarily to running a node. The disagreement lies in whether Bitcoin is a democratic or trustless system. One participant believes Bitcoin is meant to be trustless, while another argues for a democratic system where voting is not required for decision-making within the network.The discussion continues with Mike Hearn discussing the importance of miners and nodes following the protocol. He distinguishes between rejecting a block at validation (which is the protocol working as intended) and reinterpreting a validated block (which undermines Bitcoin's validation and proof-of-work). The notion of attackers in the Bitcoin network is debated, with Gareth Williams asserting that Bitcoin should work correctly regardless of how someone considers themselves.The conversation also touches on the concept of Bitcoin as an embodiment of natural mathematical law versus artificially contrived mathematical rules. Some argue that Bitcoin is an elegant embodiment of useful mathematical rules, while others caution against introducing human politics that may undermine these rules. The topic of confiscating balances and proposals to implement such features are rejected, as they are seen as malicious attempts or economic illiteracy that endanger Bitcoin users.There are discussions on hashpower control in Bitcoin and the risks associated with Finney attackers. The trustless nature of Bitcoin is debated, with Gareth Williams arguing that it is a perfect trustless mathematical machine, while others suggest a shift towards a more democratic system. The importance of considering costs and benefits in discussions about changes to Bitcoin is emphasized.The author acknowledges that Bitcoin is a piece of software that encodes rules to run a community and recognizes the ongoing debate on what changes are acceptable within the social contract. The question of whether Bitcoin's users want a system that evolves or remains unchanged will likely differ on a case-by-case basis. The author also discusses the importance of a strong group consensus in protecting one's money from confiscation and highlights the significance of following simple mathematical rules to prevent theft.Overall, the context provides insights into various perspectives on Bitcoin's role as a long-term store of value, the relevance of attackers, the trustlessness of the system, the importance of consensus, and the potential risks and benefits of introducing changes to the protocol.In a series of email conversations, several individuals discussed the concept of "honest miners" and the prevention of double-spending in Bitcoin transactions. Gregory Maxwell argued that miners do not prevent double-spending but rather ignore it, while Mike Hearn defined honest miners as those who work to prevent double-spends. Jorge Timón proposed two categories of miners: "stupid miners" who decide on transactions based on reception times and "smart miners" who maximize their revenue while respecting protocol rules. The discussion also touched on the possibility of deleting or reallocating coinbases to discourage double spending, with some arguing against destroying money and suggesting reallocation instead.The conversation also delved into the trustworthiness of miners and whether they can be considered "trusted parties" in a decentralized system. Maxwell believed that miners should not be trusted individually, while another individual disagreed, stating that Bitcoin could tolerate some dishonest miners but not all of them. They also discussed proposals for improving the Bitcoin blockchain, such as preventing theft and ensuring corrupt miners do not get paid for services they did not provide.The potential consequences of double spending in Bitcoin transactions were explored in another email conversation between Mike Hearn and Dr. Andy Parkins. While Hearn suggested that occasional attempts at double spending may not cause harm, Parkins argued that widespread double spending could lead to a significant increase in fraudulent activity. This highlights the challenges facing the adoption and use of cryptocurrencies like Bitcoin in terms of security and trust.Different approaches to preventing double spending were discussed, including the Proof-of-Work (PoW) approach and the use of trusted third parties (TTPs). The advantages and disadvantages of each approach were debated, with the proposal of hybrid systems that combine PoW-based blockchains for settlements and TTP-based payment systems for small-value transactions. This would address scalability issues and retain the benefits of both approaches.Various proposals for improving the Bitcoin blockchain were mentioned, such as the use of coinbase scriptSigs for voting purposes and the establishment of a transaction "proof of publication" chain. The latter idea involved adding each transaction - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Compatibility-Bitcoin-Qt-with-Tails.xml b/static/bitcoin-dev/April_2014/combined_Compatibility-Bitcoin-Qt-with-Tails.xml index 5af3d2414b..1b58b6235d 100644 --- a/static/bitcoin-dev/April_2014/combined_Compatibility-Bitcoin-Qt-with-Tails.xml +++ b/static/bitcoin-dev/April_2014/combined_Compatibility-Bitcoin-Qt-with-Tails.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Compatibility Bitcoin-Qt with Tails - 2023-08-01T09:02:17.758649+00:00 + 2025-10-11T21:36:20.175282+00:00 + python-feedgen Wladimir 2014-05-02 18:28:18+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Compatibility Bitcoin-Qt with Tails - 2023-08-01T09:02:17.758649+00:00 + 2025-10-11T21:36:20.175509+00:00 - On May 2, 2014, Kristov Atlas confirmed that a dev binary runs smoothly in the latest version of Tails, v1.0, which was tested by him. Wladimir assured that the usual Linux binary would be compatible when incorporated into the next release of Bitcoin Core, but he mentioned the possibility of adding a binary linked to Qt 5.x for newer distributions at some point. Compatibility remains their primary concern. Earlier on April 30th, 2014, Kristov Atlas reported an issue with a binary built by Wladimir where the GUI segfaulted after choosing the default datadir. However, Wladimir fixed the issue and created a new test build which is available for download from visucore.com. This dev binary was confirmed to run smoothly in Tails v1.0 by Kristov Atlas. It is unclear whether this will make the usual Linux binary compatible or if there will be a special binary just for systems running the older Qt.In another email sent on April 26, 2014, Kristov Atlas thanked Wladimir for building a binary to fix the initial problem with Qt, but mentioned that after choosing the default datadir, it still segfaulted. Wladimir addressed this issue and made a new test build available for download. The details of the fix can be found on GitHub at https://github.com/bitcoin/bitcoin/pull/4094. The new test build can be downloaded from https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz, with signatures available at https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz.sig.The context also includes a sample terminal output for the latest Tails operating system version 0.23. The user encountered errors when attempting to run the bitcoin-qt command, including "Bus::open: Can not get ibus-daemon's address," "IBusInputContext::createInputContext: no connection to ibus-daemon," and "sendto: Operation not permitted." Additionally, a "Segmentation fault" error occurred when running the command with a proxy. The user requested a traceback from Wladimir, the creator of Bitcoin.In an email exchange between Wladimir and Kristov, Wladimir mentioned modifying the gitian build to work with Qt 4.6 instead of Qt 4.8 in a pull request. He provided a test build of master with the updated gitian descriptor that should work on Debian Squeeze/Tails Linux. Kristov confirmed that the initial problem with Qt was resolved and he was able to load the GUI to choose his datadir. However, after selecting the default datadir, it segfaulted. The "sendto: Operation not permitted" message indicated that Core couldn't connect to the internet without going through Tails' Tor SOCKS proxy. When Kristov specified the SOCKS proxy through the command-line, there was a brief flash of the GUI before it segfaulted again. The "Bus::open" and "IBusInputContext::createInputContext" messages were considered atypical and might be related to the segfault. Lastly, in an email conversation between Kristov Atlas and Warren Togami Jr. on April 23, 2014, Kristov shared that he had modified the gitian build to use Qt 4.6 instead of 4.8, aiming to make it compatible with Tails/Debian Squeeze. He provided a link to a test build of master with the updated gitian descriptor that should work on Debian Squeeze / Tails Linux, along with the links to download the bitcoin-qt executables. 2014-05-02T18:28:18+00:00 + On May 2, 2014, Kristov Atlas confirmed that a dev binary runs smoothly in the latest version of Tails, v1.0, which was tested by him. Wladimir assured that the usual Linux binary would be compatible when incorporated into the next release of Bitcoin Core, but he mentioned the possibility of adding a binary linked to Qt 5.x for newer distributions at some point. Compatibility remains their primary concern. Earlier on April 30th, 2014, Kristov Atlas reported an issue with a binary built by Wladimir where the GUI segfaulted after choosing the default datadir. However, Wladimir fixed the issue and created a new test build which is available for download from visucore.com. This dev binary was confirmed to run smoothly in Tails v1.0 by Kristov Atlas. It is unclear whether this will make the usual Linux binary compatible or if there will be a special binary just for systems running the older Qt.In another email sent on April 26, 2014, Kristov Atlas thanked Wladimir for building a binary to fix the initial problem with Qt, but mentioned that after choosing the default datadir, it still segfaulted. Wladimir addressed this issue and made a new test build available for download. The details of the fix can be found on GitHub at https://github.com/bitcoin/bitcoin/pull/4094. The new test build can be downloaded from https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz, with signatures available at https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz.sig.The context also includes a sample terminal output for the latest Tails operating system version 0.23. The user encountered errors when attempting to run the bitcoin-qt command, including "Bus::open: Can not get ibus-daemon's address," "IBusInputContext::createInputContext: no connection to ibus-daemon," and "sendto: Operation not permitted." Additionally, a "Segmentation fault" error occurred when running the command with a proxy. The user requested a traceback from Wladimir, the creator of Bitcoin.In an email exchange between Wladimir and Kristov, Wladimir mentioned modifying the gitian build to work with Qt 4.6 instead of Qt 4.8 in a pull request. He provided a test build of master with the updated gitian descriptor that should work on Debian Squeeze/Tails Linux. Kristov confirmed that the initial problem with Qt was resolved and he was able to load the GUI to choose his datadir. However, after selecting the default datadir, it segfaulted. The "sendto: Operation not permitted" message indicated that Core couldn't connect to the internet without going through Tails' Tor SOCKS proxy. When Kristov specified the SOCKS proxy through the command-line, there was a brief flash of the GUI before it segfaulted again. The "Bus::open" and "IBusInputContext::createInputContext" messages were considered atypical and might be related to the segfault. Lastly, in an email conversation between Kristov Atlas and Warren Togami Jr. on April 23, 2014, Kristov shared that he had modified the gitian build to use Qt 4.6 instead of 4.8, aiming to make it compatible with Tails/Debian Squeeze. He provided a link to a test build of master with the updated gitian descriptor that should work on Debian Squeeze / Tails Linux, along with the links to download the bitcoin-qt executables. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Detailed-gitian-build-guide.xml b/static/bitcoin-dev/April_2014/combined_Detailed-gitian-build-guide.xml index ee37f2f9d8..1af0b84664 100644 --- a/static/bitcoin-dev/April_2014/combined_Detailed-gitian-build-guide.xml +++ b/static/bitcoin-dev/April_2014/combined_Detailed-gitian-build-guide.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Detailed gitian build guide - 2023-08-01T08:32:25.073172+00:00 + 2025-10-11T21:36:56.309816+00:00 + python-feedgen devrandom 2014-04-03 16:01:58+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Detailed gitian build guide - 2023-08-01T08:32:25.073172+00:00 + 2025-10-11T21:36:56.309982+00:00 - In a conversation between Wladimir and Miron/devrandom, the topic of discussion is building a basic virtual machine using Gitian for gitian builds. Devrandom asks if the process can be scripted, to which Wladimir replies that it can probably be done using vmbuilder or vagrant, as suggested by Nick Simpson. However, the purpose of providing exact steps is to allow anyone to follow them without needing scripting languages. The aim is to avoid ending up with a gitian-builder-that-builds-a-gitian-builder. While some parts may be scripted, Wladimir hopes that over time, Gitian itself will become easier to use and set up, requiring fewer steps. The ultimate goal is to make it easier for newcomers to get started with Gitian.In an email exchange between Wladimir and devrandom, Wladimir provides instructions on creating a basic virtual machine for gitian builds. The emphasis is on providing an exact guide that anyone can follow without scripting. Although automation is possible for certain aspects, Wladimir hopes that Gitian will improve in usability, reducing the number of steps needed.On April 2, 2014, Wladimir announces that he is working on a guide to install and set up a Debian VM for gitian building. The purpose of this guide is to simplify the process for people getting started with gitian builds. Wladimir shares the link to the rendered version of the guide on Github and invites comments and patches. He also encourages anyone facing problems while following the guide to inform him. Miron responds to Wladimir's email expressing admiration.Wladimir's guide aims to assist people in installing and setting up a Debian VM for gitian building. This guide can be used on any operating system that has VirtualBox. The intention behind this guide is to make it easier for individuals to begin with gitian builds. The rendered version of the guide can be found at https://github.com/laanwj/bitcoin/blob/2014_04_debian_gitian_build_doc/doc/gitian-building.md. Feedback and contributions in the form of comments and patches are welcome, and users are encouraged to inform Wladimir if they encounter any issues while following the guide. 2014-04-03T16:01:58+00:00 + In a conversation between Wladimir and Miron/devrandom, the topic of discussion is building a basic virtual machine using Gitian for gitian builds. Devrandom asks if the process can be scripted, to which Wladimir replies that it can probably be done using vmbuilder or vagrant, as suggested by Nick Simpson. However, the purpose of providing exact steps is to allow anyone to follow them without needing scripting languages. The aim is to avoid ending up with a gitian-builder-that-builds-a-gitian-builder. While some parts may be scripted, Wladimir hopes that over time, Gitian itself will become easier to use and set up, requiring fewer steps. The ultimate goal is to make it easier for newcomers to get started with Gitian.In an email exchange between Wladimir and devrandom, Wladimir provides instructions on creating a basic virtual machine for gitian builds. The emphasis is on providing an exact guide that anyone can follow without scripting. Although automation is possible for certain aspects, Wladimir hopes that Gitian will improve in usability, reducing the number of steps needed.On April 2, 2014, Wladimir announces that he is working on a guide to install and set up a Debian VM for gitian building. The purpose of this guide is to simplify the process for people getting started with gitian builds. Wladimir shares the link to the rendered version of the guide on Github and invites comments and patches. He also encourages anyone facing problems while following the guide to inform him. Miron responds to Wladimir's email expressing admiration.Wladimir's guide aims to assist people in installing and setting up a Debian VM for gitian building. This guide can be used on any operating system that has VirtualBox. The intention behind this guide is to make it easier for individuals to begin with gitian builds. The rendered version of the guide can be found at https://github.com/laanwj/bitcoin/blob/2014_04_debian_gitian_build_doc/doc/gitian-building.md. Feedback and contributions in the form of comments and patches are welcome, and users are encouraged to inform Wladimir if they encounter any issues while following the guide. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Development-Roadmap-of-Bitcoin-Core-0-9-2.xml b/static/bitcoin-dev/April_2014/combined_Development-Roadmap-of-Bitcoin-Core-0-9-2.xml index f4b7dec43e..2cb9ca09dc 100644 --- a/static/bitcoin-dev/April_2014/combined_Development-Roadmap-of-Bitcoin-Core-0-9-2.xml +++ b/static/bitcoin-dev/April_2014/combined_Development-Roadmap-of-Bitcoin-Core-0-9-2.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Development Roadmap of Bitcoin Core 0.9.2 - 2023-08-01T08:54:13.388812+00:00 + 2025-10-11T21:35:33.434961+00:00 + python-feedgen Wladimir 2014-04-25 20:47:31+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Development Roadmap of Bitcoin Core 0.9.2 - 2023-08-01T08:54:13.388812+00:00 + 2025-10-11T21:35:33.435150+00:00 - Tails 1.1, based on Wheezy, is set to release on June 10th according to an email exchange between Kristov Atlas and Wladimir. The release date was confirmed by a link to the Tails website. Tails is a live operating system designed for privacy and anonymity while using the internet. It is based on Debian GNU/Linux and can be run from a USB drive, DVD, or SD card. Tails 1.1 promises to include enhancements and bug fixes, with improved security features and performance.In another email exchange, Wladimir and Warren Togami Jr. discuss the need for a cut-off point regarding the use of old stable distributions on the desktop. Warren suggests using 4.7 or 4.8 as the cut-off point, as Qt 4.6, which is currently used by Tails, is considered ancient. They also discuss the compatibility of Bitcoin-Qt on different systems, including Tails, which is a mostly stateless Linux distribution for privacy applications. Building Bitcoin-Qt from source in Tails is not straightforward due to the lack of development tools. The group discusses possible solutions, such as building against the 4.6 Qt headers instead of statically building, which may result in the loss of some GUI features but could improve compatibility.Gregory Maxwell also joins the conversation and suggests that Tails users usually cannot build Bitcoin-Qt from source. He mentions the idea of having a separate static QT binary just for these cases. Warren agrees that statically linking QT on Linux should generally be avoided due to theming issues. They suggest that the build process could dump out a separate extra static QT binary, which would require less maintenance than addressing questions and complaints about it.Warren Togami Jr. and Kristov Atlas discuss the compatibility of the latest nightly build with Tails/Debian Squeeze in an email exchange. Warren clarifies that while bitcoind works on most distributions, bitcoin-qt may not work due to qt-4.6. He emphasizes the priority of making bitcoind work on as many distributions as possible, as older stable distributions are typically headless. Building Bitcoin-Qt from source is the only option for users who need it on an incompatible system. Kristov points out that Bitcoin-Qt 0.8.6 works fine on Tails and suggests building in Debian Squeeze and transplanting that, highlighting the importance of supporting Tails as a Linux distribution.Warren also posts on the Bitcoin-Translators mailing list, suggesting developers communicate with translators when new translations are needed. The Bitcoin Core developers plan to release version 0.9.2, focusing on bug fixes and translation updates. The development roadmap includes a feature and string freeze starting in three weeks from the date of the announcement. Non-developers and translators can get involved in testing unofficial deterministic nightly builds. Transifex is used to coordinate translations, with English language source strings synchronized periodically. A String Freeze will be declared prior to the release to allow translators enough time to translate new or modified source strings. Laanwj proposes a strategy for dealing with future releases where translations for both diverged stable and master branches can be kept simultaneously in Transifex. 2014-04-25T20:47:31+00:00 + Tails 1.1, based on Wheezy, is set to release on June 10th according to an email exchange between Kristov Atlas and Wladimir. The release date was confirmed by a link to the Tails website. Tails is a live operating system designed for privacy and anonymity while using the internet. It is based on Debian GNU/Linux and can be run from a USB drive, DVD, or SD card. Tails 1.1 promises to include enhancements and bug fixes, with improved security features and performance.In another email exchange, Wladimir and Warren Togami Jr. discuss the need for a cut-off point regarding the use of old stable distributions on the desktop. Warren suggests using 4.7 or 4.8 as the cut-off point, as Qt 4.6, which is currently used by Tails, is considered ancient. They also discuss the compatibility of Bitcoin-Qt on different systems, including Tails, which is a mostly stateless Linux distribution for privacy applications. Building Bitcoin-Qt from source in Tails is not straightforward due to the lack of development tools. The group discusses possible solutions, such as building against the 4.6 Qt headers instead of statically building, which may result in the loss of some GUI features but could improve compatibility.Gregory Maxwell also joins the conversation and suggests that Tails users usually cannot build Bitcoin-Qt from source. He mentions the idea of having a separate static QT binary just for these cases. Warren agrees that statically linking QT on Linux should generally be avoided due to theming issues. They suggest that the build process could dump out a separate extra static QT binary, which would require less maintenance than addressing questions and complaints about it.Warren Togami Jr. and Kristov Atlas discuss the compatibility of the latest nightly build with Tails/Debian Squeeze in an email exchange. Warren clarifies that while bitcoind works on most distributions, bitcoin-qt may not work due to qt-4.6. He emphasizes the priority of making bitcoind work on as many distributions as possible, as older stable distributions are typically headless. Building Bitcoin-Qt from source is the only option for users who need it on an incompatible system. Kristov points out that Bitcoin-Qt 0.8.6 works fine on Tails and suggests building in Debian Squeeze and transplanting that, highlighting the importance of supporting Tails as a Linux distribution.Warren also posts on the Bitcoin-Translators mailing list, suggesting developers communicate with translators when new translations are needed. The Bitcoin Core developers plan to release version 0.9.2, focusing on bug fixes and translation updates. The development roadmap includes a feature and string freeze starting in three weeks from the date of the announcement. Non-developers and translators can get involved in testing unofficial deterministic nightly builds. Transifex is used to coordinate translations, with English language source strings synchronized periodically. A String Freeze will be declared prior to the release to allow translators enough time to translate new or modified source strings. Laanwj proposes a strategy for dealing with future releases where translations for both diverged stable and master branches can be kept simultaneously in Transifex. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Double-spending-unconfirmed-transactions-is-a-lot-easier-than-most-people-realise.xml b/static/bitcoin-dev/April_2014/combined_Double-spending-unconfirmed-transactions-is-a-lot-easier-than-most-people-realise.xml index 1e5833c043..92bbf7082b 100644 --- a/static/bitcoin-dev/April_2014/combined_Double-spending-unconfirmed-transactions-is-a-lot-easier-than-most-people-realise.xml +++ b/static/bitcoin-dev/April_2014/combined_Double-spending-unconfirmed-transactions-is-a-lot-easier-than-most-people-realise.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Double-spending unconfirmed transactions is a lot easier than most people realise - 2023-08-01T08:54:50.526641+00:00 + 2025-10-11T21:35:35.558335+00:00 + python-feedgen Simon Barber 2014-04-24 00:42:20+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Double-spending unconfirmed transactions is a lot easier than most people realise - 2023-08-01T08:54:50.527678+00:00 + 2025-10-11T21:35:35.558492+00:00 - The goal of miners in the Bitcoin network is to maximize profits. However, there is a discussion on whether a network that prioritizes transaction certainty and values 0-confirm transactions would be more valuable for bitcoins. Rational miners are expected to want to collaborate to reduce the possibilities for double spend attacks. The rational miner wants to be rewarded with something spendable like cash on a 1-minute network, rather than something spendable on a 15-minute network. There is a prisoner's dilemma involved in this decision.In an email exchange between Matt Whitlock and Tom Harding, the possibility of a network where transaction submitters consider their transactions unchangeable upon transmission is discussed. Tom Harding believes that such a network has a chance to work. However, Matt Whitlock argues that miners' primary goal is to maximize profits, and if enabling replace-by-fee can achieve this, they will do it regardless of the consequences. The question is raised whether the fees gained from helping people double-spend their coffee supplier outweigh the benefits of ensuring that digital cash functions like traditional cash.On April 22, 2014, Jan Møller and another individual discuss the difficulty in executing a double-spend after an original transaction. It is noted that sending a non-standard transaction to Eligius would normally work, but in this particular case with LuckyBit, it would not because LuckyBit is directly connected to Eligius and Eligius relays non-standard transactions. However, Jan Møller points out that double-spending every bet would defeat the purpose of the action.The prevention of 0-confirmation respends in the bitcoin network is still a challenge, with no complete solution proposed. Partial solutions have been suggested to move towards a network with simple rules where certainty does not disappear immediately below the time of 1 confirmation. A network where transaction submitters consider their transactions unchangeable upon transmission, and the goal is to confirm only transactions with unseen UTXOs, provides a chance for such a network. If respend attempts are broadcast widely, then after a time on the order of transaction propagation time, double-spending transactions can occur.A real-world example is provided using LuckyBit, a gambling service, to demonstrate how a double-spend occurs. The double-spend was mined by Eligius, which blacklists certain transactions. LuckyBit has added case-specific code to reject transactions with known blacklisted outputs.The difficulty in sending a double-spend after the original transaction is discussed. It is suggested that sending a non-standard transaction to Eligius would normally work, but in this particular case, it is not possible. The reason for this is not explicitly stated. The connection between LuckyBit and Eligius, as well as Eligius relaying non-standard transactions, is questioned.The discussion focuses on the possibility of double spending and how it can be prevented, with a focus on business models and incentives. Two potential solutions to move towards a more secure network are presented. A real-world double-spend experiment is described, using an attack on gambling site LuckyBit. The attacker used a replace-by-fee patch and submitted the double-spend transaction directly to the Eligius pool. The author emphasizes the need for effective countermeasures such as blacklisting and off-chain transactions to prevent automated attacks. The email signature provides information about Jeff Garzik, a Bitcoin core developer and open-source evangelist at BitPay Inc.In summary, the context revolves around the goal of a network where transactions are considered unchangeable upon transmission and only confirm transactions that have not yet been seen in final transactions' inputs. There is a discussion on whether such a network can succeed, considering the goals of miners to maximize profits. The difficulty in executing a double-spend after an original transaction is explored, along with potential solutions to prevent double-spending. A real-world example of a double-spend attack on LuckyBit is provided, emphasizing the need for countermeasures. 2014-04-24T00:42:20+00:00 + The goal of miners in the Bitcoin network is to maximize profits. However, there is a discussion on whether a network that prioritizes transaction certainty and values 0-confirm transactions would be more valuable for bitcoins. Rational miners are expected to want to collaborate to reduce the possibilities for double spend attacks. The rational miner wants to be rewarded with something spendable like cash on a 1-minute network, rather than something spendable on a 15-minute network. There is a prisoner's dilemma involved in this decision.In an email exchange between Matt Whitlock and Tom Harding, the possibility of a network where transaction submitters consider their transactions unchangeable upon transmission is discussed. Tom Harding believes that such a network has a chance to work. However, Matt Whitlock argues that miners' primary goal is to maximize profits, and if enabling replace-by-fee can achieve this, they will do it regardless of the consequences. The question is raised whether the fees gained from helping people double-spend their coffee supplier outweigh the benefits of ensuring that digital cash functions like traditional cash.On April 22, 2014, Jan Møller and another individual discuss the difficulty in executing a double-spend after an original transaction. It is noted that sending a non-standard transaction to Eligius would normally work, but in this particular case with LuckyBit, it would not because LuckyBit is directly connected to Eligius and Eligius relays non-standard transactions. However, Jan Møller points out that double-spending every bet would defeat the purpose of the action.The prevention of 0-confirmation respends in the bitcoin network is still a challenge, with no complete solution proposed. Partial solutions have been suggested to move towards a network with simple rules where certainty does not disappear immediately below the time of 1 confirmation. A network where transaction submitters consider their transactions unchangeable upon transmission, and the goal is to confirm only transactions with unseen UTXOs, provides a chance for such a network. If respend attempts are broadcast widely, then after a time on the order of transaction propagation time, double-spending transactions can occur.A real-world example is provided using LuckyBit, a gambling service, to demonstrate how a double-spend occurs. The double-spend was mined by Eligius, which blacklists certain transactions. LuckyBit has added case-specific code to reject transactions with known blacklisted outputs.The difficulty in sending a double-spend after the original transaction is discussed. It is suggested that sending a non-standard transaction to Eligius would normally work, but in this particular case, it is not possible. The reason for this is not explicitly stated. The connection between LuckyBit and Eligius, as well as Eligius relaying non-standard transactions, is questioned.The discussion focuses on the possibility of double spending and how it can be prevented, with a focus on business models and incentives. Two potential solutions to move towards a more secure network are presented. A real-world double-spend experiment is described, using an attack on gambling site LuckyBit. The attacker used a replace-by-fee patch and submitted the double-spend transaction directly to the Eligius pool. The author emphasizes the need for effective countermeasures such as blacklisting and off-chain transactions to prevent automated attacks. The email signature provides information about Jeff Garzik, a Bitcoin core developer and open-source evangelist at BitPay Inc.In summary, the context revolves around the goal of a network where transactions are considered unchangeable upon transmission and only confirm transactions that have not yet been seen in final transactions' inputs. There is a discussion on whether such a network can succeed, considering the goals of miners to maximize profits. The difficulty in executing a double-spend after an original transaction is explored, along with potential solutions to prevent double-spending. A real-world example of a double-spend attack on LuckyBit is provided, emphasizing the need for countermeasures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Draft-BIP-for-seamless-website-authentication-using-Bitcoin-address.xml b/static/bitcoin-dev/April_2014/combined_Draft-BIP-for-seamless-website-authentication-using-Bitcoin-address.xml index 44afda3503..d4c7d141d8 100644 --- a/static/bitcoin-dev/April_2014/combined_Draft-BIP-for-seamless-website-authentication-using-Bitcoin-address.xml +++ b/static/bitcoin-dev/April_2014/combined_Draft-BIP-for-seamless-website-authentication-using-Bitcoin-address.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP for seamless website authentication using Bitcoin address - 2023-08-01T08:34:04.741406+00:00 + 2025-10-11T21:36:15.927967+00:00 + python-feedgen Eric Larchevêque 2014-04-22 08:57:18+00:00 @@ -111,13 +112,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for seamless website authentication using Bitcoin address - 2023-08-01T08:34:04.741406+00:00 + 2025-10-11T21:36:15.928166+00:00 - The development of BitID has made progress with a working wallet prototype based on Android Bitcoin Wallet. A short video demonstration is available for those interested in the user flow.By default, each new first auth request creates and saves a new address (SQRL-like), which could be based on BIP32 but works without it. This requires adding metadata to addresses as described in the link provided. The development also offers fields for decentralized 2FA as well as "pay as guest" checkout in conjunction with BIP70 payment request.In a discussion about client-side certificates, Jan Moller notes that safely storing and backing up secrets has been a challenge. He suggests using a mechanism similar to BIP32 for generating a parallel hierarchy for authentication purposes. Client side certificates have never gained popularity due to the difficulty in safely storing and backing up secrets. The use of two different mechanisms for managing secrets is not necessary. While using a Bitcoin address for authentication may link funds with identity, a mechanism for generating a hierarchy of private keys from a master seed has been agreed upon for authentication purposes.The issue of users not installing plugins was discussed in an email conversation between Mike Hearn and Jeff Garzik. Jeff warned against making generalizations as it depends on the product's value. However, he noted that based on personal observations and data from Mozilla and other browsers, most users do not install plugins except for Flash.In an email conversation between Eric Larchevêque and Jeff Garzik, they both agreed that while it is cool to do bitcoin and PGP in a client, only 0.01% of users actually install plugins.In an email thread, Troy Benjegerdes proposed using a Bitcoin address as a persistent identity key. Ricardo Filipe agrees with this idea but wonders if a multisig seed would work instead. Eric Martindale responds, cautioning that implementing such a proposal could have significant implications for the economics of cryptofinance. In a discussion thread, Troy Benjegerdes proposed the use of Bitcoin addresses as a persistent identity key, suggesting that it could become the "killer app" for Bitcoin adoption.A proposed BIP has been put forth by Eric Larchevêque as a way to authenticate users with one Bitcoin address from their wallet. Currently, services require users' Bitcoin addresses and request an email/password to store it. However, if a standard protocol is not established, it would be difficult to envision a pure Bitcoin locker rental or booking hotel rooms via Bitcoin and opening the door through the paying address.The discussion revolves around the usage of plugins for TREZOR and how it can pose a problem if people are reluctant to install them. However, the author mentions that browsers can handle the process without the need for a plugin. The main focus of the conversation is on making the sign-up and login process for Bitcoin ecosystem websites and apps more user-friendly.In an email exchange, Mike Hearn expressed concern about the use of a web plugin for TREZOR. Marek responded by stating that they saw the plugin as a temporary solution and hoped to eliminate it once there was a way to communicate with USB HID directly from the browser.The conversation revolves around the use of TREZOR for web authentication purposes. While TREZOR requires a web plugin, it is not mandatory as browsers have the capability to create private keys and upload public parts seamlessly for the user. Upgrades can be made in key management. Slush's main comments on BIP were not to use bitcoin addresses directly and not to encourage services to use "login" for financial purposes.In an email conversation between Eric Larchevêque and slush, they discuss the idea of using TREZOR for web authentication purposes. Slush suggests not to use Bitcoin addresses directly and to avoid encouraging services to use this login for financial purposes. He also advises using some function to generate another private/public key from the bitcoin seed/private key to avoid leaking bitcoin-related data to websites. In response, Eric raises the question of risks associated with using your Bitcoin address as an authentication key.The article discusses the issue of authentication on websites with Bitcoin. It questions whether a login system is necessary and argues that very few websites would want to authenticate with only a Bitcoin address, as there would be no way to email the user or retrieve data if the wallet is lost. However, having a standard protocol for authentication could lead to new use cases such as physical locker rental or booking hotel rooms via Bitcoin. The author acknowledges potential issues with shared transactions and losing phones but believes that leveraging existing tools such as client certificates could help overcome these challenges.In an email conversation, Mike Hearn expresses doubt that Bitcoin addresses can replace passwords as a means of authentication. Lombrozo acknowledges the objections but mentions having at least two enthusiastic wallets interested in implementing the protocol. They also discuss the idea of starting privately.The author discusses the potential security risks of using a shared spend/CoinJoin type transaction in Bitcoin, as it could allow anyone who 2014-04-22T08:57:18+00:00 + The development of BitID has made progress with a working wallet prototype based on Android Bitcoin Wallet. A short video demonstration is available for those interested in the user flow.By default, each new first auth request creates and saves a new address (SQRL-like), which could be based on BIP32 but works without it. This requires adding metadata to addresses as described in the link provided. The development also offers fields for decentralized 2FA as well as "pay as guest" checkout in conjunction with BIP70 payment request.In a discussion about client-side certificates, Jan Moller notes that safely storing and backing up secrets has been a challenge. He suggests using a mechanism similar to BIP32 for generating a parallel hierarchy for authentication purposes. Client side certificates have never gained popularity due to the difficulty in safely storing and backing up secrets. The use of two different mechanisms for managing secrets is not necessary. While using a Bitcoin address for authentication may link funds with identity, a mechanism for generating a hierarchy of private keys from a master seed has been agreed upon for authentication purposes.The issue of users not installing plugins was discussed in an email conversation between Mike Hearn and Jeff Garzik. Jeff warned against making generalizations as it depends on the product's value. However, he noted that based on personal observations and data from Mozilla and other browsers, most users do not install plugins except for Flash.In an email conversation between Eric Larchevêque and Jeff Garzik, they both agreed that while it is cool to do bitcoin and PGP in a client, only 0.01% of users actually install plugins.In an email thread, Troy Benjegerdes proposed using a Bitcoin address as a persistent identity key. Ricardo Filipe agrees with this idea but wonders if a multisig seed would work instead. Eric Martindale responds, cautioning that implementing such a proposal could have significant implications for the economics of cryptofinance. In a discussion thread, Troy Benjegerdes proposed the use of Bitcoin addresses as a persistent identity key, suggesting that it could become the "killer app" for Bitcoin adoption.A proposed BIP has been put forth by Eric Larchevêque as a way to authenticate users with one Bitcoin address from their wallet. Currently, services require users' Bitcoin addresses and request an email/password to store it. However, if a standard protocol is not established, it would be difficult to envision a pure Bitcoin locker rental or booking hotel rooms via Bitcoin and opening the door through the paying address.The discussion revolves around the usage of plugins for TREZOR and how it can pose a problem if people are reluctant to install them. However, the author mentions that browsers can handle the process without the need for a plugin. The main focus of the conversation is on making the sign-up and login process for Bitcoin ecosystem websites and apps more user-friendly.In an email exchange, Mike Hearn expressed concern about the use of a web plugin for TREZOR. Marek responded by stating that they saw the plugin as a temporary solution and hoped to eliminate it once there was a way to communicate with USB HID directly from the browser.The conversation revolves around the use of TREZOR for web authentication purposes. While TREZOR requires a web plugin, it is not mandatory as browsers have the capability to create private keys and upload public parts seamlessly for the user. Upgrades can be made in key management. Slush's main comments on BIP were not to use bitcoin addresses directly and not to encourage services to use "login" for financial purposes.In an email conversation between Eric Larchevêque and slush, they discuss the idea of using TREZOR for web authentication purposes. Slush suggests not to use Bitcoin addresses directly and to avoid encouraging services to use this login for financial purposes. He also advises using some function to generate another private/public key from the bitcoin seed/private key to avoid leaking bitcoin-related data to websites. In response, Eric raises the question of risks associated with using your Bitcoin address as an authentication key.The article discusses the issue of authentication on websites with Bitcoin. It questions whether a login system is necessary and argues that very few websites would want to authenticate with only a Bitcoin address, as there would be no way to email the user or retrieve data if the wallet is lost. However, having a standard protocol for authentication could lead to new use cases such as physical locker rental or booking hotel rooms via Bitcoin. The author acknowledges potential issues with shared transactions and losing phones but believes that leveraging existing tools such as client certificates could help overcome these challenges.In an email conversation, Mike Hearn expresses doubt that Bitcoin addresses can replace passwords as a means of authentication. Lombrozo acknowledges the objections but mentions having at least two enthusiastic wallets interested in implementing the protocol. They also discuss the idea of starting privately.The author discusses the potential security risks of using a shared spend/CoinJoin type transaction in Bitcoin, as it could allow anyone who - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Economics-of-information-propagation.xml b/static/bitcoin-dev/April_2014/combined_Economics-of-information-propagation.xml index c89ebd3f18..7db5ec993d 100644 --- a/static/bitcoin-dev/April_2014/combined_Economics-of-information-propagation.xml +++ b/static/bitcoin-dev/April_2014/combined_Economics-of-information-propagation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Economics of information propagation - 2023-08-01T08:53:30.521068+00:00 + 2025-10-11T21:35:44.056192+00:00 + python-feedgen Peter Todd 2014-04-23 15:05:55+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Economics of information propagation - 2023-08-01T08:53:30.521068+00:00 + 2025-10-11T21:35:44.056373+00:00 - The email thread discusses various topics related to Bitcoin, including the validation of blocks and updating UTXO sets. One suggestion is to mine on top of just a block header, which allows small miners to receive early alerts about new blocks and work more efficiently on empty blocks. However, there are concerns about the security implications of this approach as it relies on presuming the correctness of new headers without full block verification.The conversation also explores ways to improve block propagation times. Suggestions include distributing partial proofs of work and priming memory pools with transactions, as well as allowing peers to request transaction hashes and download only unknown transactions. However, the potential benefits of these approaches have not been fully analyzed yet.Determining the primacy of a block is another topic discussed. The current system is based on the time at which the "block" message is received, but there is a suggestion to use headers-first propagation, which determines primacy based on the time the block header is received. Concerns are raised about the incentive for large pools to publish large blocks and increase propagation delays, potentially harming smaller miners.The email thread also touches on the need for a name for smaller units of Bitcoin. Suggestions like "bit" and "ubit" have been made, but concerns about cultural connotations are raised. The term "ubit" pronounced as "YOU-bit" is proposed as a representation of 1e-6 bitcoin.Lastly, the email includes a PGP signature and a promotional link to download eXo Platform, an open-source intranet software for building collaboration platforms. The author encourages readers to start their own social network using the software and turn their intranet into a collaboration platform. The email also provides a link to the Bitcoin-development mailing list for further discussion about Bitcoin development.In a separate discussion, Jonathan Levin, a post-graduate economist, is conducting research on the incentives of mining in Bitcoin. He is interested in understanding the impact of these incentives on the transaction fee market. Levin argues that the marginal cost for miners is not derived from validating signatures and including them in blocks but rather from the increased probability of orphaned blocks due to slower propagation. He seeks analytical solutions to gain a deeper understanding of this issue.Levin's analysis utilizes empirical data, but he finds it concerning that propagation delays result in increasing returns to higher shares of hashing power, which may incentivize large pools to publish large blocks and increase orphan rates for small miners with limited bandwidth or connectivity.The Bitcoin community also debates using "bits" as a unit of account. Some argue that "credit" would be more suitable, considering that Bitcoin is not a credit-based system. The importance of culturally neutral terminologies is emphasized to avoid invoking cultural references in naming conventions.Within the email thread, Oliver Egginger points out the lack of a commonly accepted term for smaller units of Bitcoin. He suggests that this may not be a problem as terms tend to arise naturally. However, Justin A proposes the term "ubit" to represent 1e-6 bitcoin. The discussion concludes with an advertisement for eXo Platform software, along with mentions of a free O'Reilly book on graph databases and information about building an enterprise intranet.Overall, these discussions highlight the complex incentives in Bitcoin mining, the potential impact of propagation delays, and the ongoing debate surrounding unit names and cultural neutrality in the Bitcoin community. 2014-04-23T15:05:55+00:00 + The email thread discusses various topics related to Bitcoin, including the validation of blocks and updating UTXO sets. One suggestion is to mine on top of just a block header, which allows small miners to receive early alerts about new blocks and work more efficiently on empty blocks. However, there are concerns about the security implications of this approach as it relies on presuming the correctness of new headers without full block verification.The conversation also explores ways to improve block propagation times. Suggestions include distributing partial proofs of work and priming memory pools with transactions, as well as allowing peers to request transaction hashes and download only unknown transactions. However, the potential benefits of these approaches have not been fully analyzed yet.Determining the primacy of a block is another topic discussed. The current system is based on the time at which the "block" message is received, but there is a suggestion to use headers-first propagation, which determines primacy based on the time the block header is received. Concerns are raised about the incentive for large pools to publish large blocks and increase propagation delays, potentially harming smaller miners.The email thread also touches on the need for a name for smaller units of Bitcoin. Suggestions like "bit" and "ubit" have been made, but concerns about cultural connotations are raised. The term "ubit" pronounced as "YOU-bit" is proposed as a representation of 1e-6 bitcoin.Lastly, the email includes a PGP signature and a promotional link to download eXo Platform, an open-source intranet software for building collaboration platforms. The author encourages readers to start their own social network using the software and turn their intranet into a collaboration platform. The email also provides a link to the Bitcoin-development mailing list for further discussion about Bitcoin development.In a separate discussion, Jonathan Levin, a post-graduate economist, is conducting research on the incentives of mining in Bitcoin. He is interested in understanding the impact of these incentives on the transaction fee market. Levin argues that the marginal cost for miners is not derived from validating signatures and including them in blocks but rather from the increased probability of orphaned blocks due to slower propagation. He seeks analytical solutions to gain a deeper understanding of this issue.Levin's analysis utilizes empirical data, but he finds it concerning that propagation delays result in increasing returns to higher shares of hashing power, which may incentivize large pools to publish large blocks and increase orphan rates for small miners with limited bandwidth or connectivity.The Bitcoin community also debates using "bits" as a unit of account. Some argue that "credit" would be more suitable, considering that Bitcoin is not a credit-based system. The importance of culturally neutral terminologies is emphasized to avoid invoking cultural references in naming conventions.Within the email thread, Oliver Egginger points out the lack of a commonly accepted term for smaller units of Bitcoin. He suggests that this may not be a problem as terms tend to arise naturally. However, Justin A proposes the term "ubit" to represent 1e-6 bitcoin. The discussion concludes with an advertisement for eXo Platform software, along with mentions of a free O'Reilly book on graph databases and information about building an enterprise intranet.Overall, these discussions highlight the complex incentives in Bitcoin mining, the potential impact of propagation delays, and the ongoing debate surrounding unit names and cultural neutrality in the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Eliminating-double-spends-with-two-party-self-escrow-for-high-value-transactions.xml b/static/bitcoin-dev/April_2014/combined_Eliminating-double-spends-with-two-party-self-escrow-for-high-value-transactions.xml index 4ac897ed10..ca7788d308 100644 --- a/static/bitcoin-dev/April_2014/combined_Eliminating-double-spends-with-two-party-self-escrow-for-high-value-transactions.xml +++ b/static/bitcoin-dev/April_2014/combined_Eliminating-double-spends-with-two-party-self-escrow-for-high-value-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Eliminating double-spends with two-party self-escrow for high value transactions - 2023-08-01T09:03:56.526175+00:00 + 2025-10-11T21:36:07.433854+00:00 + python-feedgen Peter Todd 2014-04-26 19:37:59+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Eliminating double-spends with two-party self-escrow for high value transactions - 2023-08-01T09:03:56.526175+00:00 + 2025-10-11T21:36:07.434050+00:00 - Peter Todd proposed a mechanism similar to Jeremy Spilman's micropayment channel for a single payment. The seller would only release the goods once they received a valid transaction signed by the buyer sending the escrowed funds. This prevents the buyer from always requesting a refund. Reddit user RubenSomsen suggested a similar idea on Mycelium, where users can temporarily lock their bitcoins in a 2-of-2 transaction with a potential buyer before meeting.The concern with this proposed mechanism is whether wallet UIs can handle it without being too complicated for users, potentially leading them to switch to a more user-friendly option. However, there may be a way to present it in a slick and intuitive manner.In 2014, Mike Hearn proposed a mechanism for Bitcoin transactions involving an escrow service. Similar to Todd's proposal, sellers would only release goods once they had received a valid transaction signed by the buyer sending the escrowed funds. This proposal was also similar to Spilman's micropayment channel.When it comes to online shopping, the concern of buyers always requesting refunds has been addressed by e-commerce platforms and marketplaces through return policies. These policies have specific time frames for returns and track the frequency of returns, with the ability to suspend accounts if necessary. Retailers also utilize customer reviews and ratings to help consumers make informed decisions before purchasing. Some payment methods, like PayPal, offer buyer protection programs for eligible purchases. Overall, e-commerce platforms and retailers have taken steps to minimize the risk of frequent refunds through clear return policies, customer reviews, and buyer protection programs.In high-value transactions, existing escrow solutions take advantage of the fact that funds will be sent before they actually are. For example, Localbitcoins allows sellers to escrow their funds prior to release to the buyer. With nLockTime, a third-party escrow agent is not required. Instead, the buyer signs a refund transaction that unlocks at a future time before sending the funds to the escrow address. Mycelium's Local Trader functionality already includes communication between buyers and sellers, and it can be extended to self-escrow. Transaction malleability is an issue that needs to be addressed, and adding a third-party escrow to the two-party escrow can be a measure to manually release locked funds if malleability is a problem. Additionally, a future soft-fork like Pieter Wuille's BIP62 can eliminate malleability. 2014-04-26T19:37:59+00:00 + Peter Todd proposed a mechanism similar to Jeremy Spilman's micropayment channel for a single payment. The seller would only release the goods once they received a valid transaction signed by the buyer sending the escrowed funds. This prevents the buyer from always requesting a refund. Reddit user RubenSomsen suggested a similar idea on Mycelium, where users can temporarily lock their bitcoins in a 2-of-2 transaction with a potential buyer before meeting.The concern with this proposed mechanism is whether wallet UIs can handle it without being too complicated for users, potentially leading them to switch to a more user-friendly option. However, there may be a way to present it in a slick and intuitive manner.In 2014, Mike Hearn proposed a mechanism for Bitcoin transactions involving an escrow service. Similar to Todd's proposal, sellers would only release goods once they had received a valid transaction signed by the buyer sending the escrowed funds. This proposal was also similar to Spilman's micropayment channel.When it comes to online shopping, the concern of buyers always requesting refunds has been addressed by e-commerce platforms and marketplaces through return policies. These policies have specific time frames for returns and track the frequency of returns, with the ability to suspend accounts if necessary. Retailers also utilize customer reviews and ratings to help consumers make informed decisions before purchasing. Some payment methods, like PayPal, offer buyer protection programs for eligible purchases. Overall, e-commerce platforms and retailers have taken steps to minimize the risk of frequent refunds through clear return policies, customer reviews, and buyer protection programs.In high-value transactions, existing escrow solutions take advantage of the fact that funds will be sent before they actually are. For example, Localbitcoins allows sellers to escrow their funds prior to release to the buyer. With nLockTime, a third-party escrow agent is not required. Instead, the buyer signs a refund transaction that unlocks at a future time before sending the funds to the escrow address. Mycelium's Local Trader functionality already includes communication between buyers and sellers, and it can be extended to self-escrow. Transaction malleability is an issue that needs to be addressed, and adding a third-party escrow to the two-party escrow can be a measure to manually release locked funds if malleability is a problem. Additionally, a future soft-fork like Pieter Wuille's BIP62 can eliminate malleability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Error-handling-in-payment-protocol-BIP-0070-and-BIP-0072-.xml b/static/bitcoin-dev/April_2014/combined_Error-handling-in-payment-protocol-BIP-0070-and-BIP-0072-.xml index d4d1b0ca0b..cb841112a4 100644 --- a/static/bitcoin-dev/April_2014/combined_Error-handling-in-payment-protocol-BIP-0070-and-BIP-0072-.xml +++ b/static/bitcoin-dev/April_2014/combined_Error-handling-in-payment-protocol-BIP-0070-and-BIP-0072-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Error handling in payment protocol (BIP-0070 and BIP-0072) - 2023-08-01T09:01:46.225934+00:00 + 2025-10-11T21:35:54.680651+00:00 + python-feedgen Kevin Greene 2014-04-27 07:53:25+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Error handling in payment protocol (BIP-0070 and BIP-0072) - 2023-08-01T09:01:46.225934+00:00 + 2025-10-11T21:35:54.680828+00:00 - In a discussion about payment requests, Ross Nicoll expressed caution regarding the security implications of embedding files into the payment request. He noted that even file formats that are presumed safe, such as images, have had security issues in the past. Mike Hearn responded by pointing out that PaymentRequests are limited to 50,000 bytes and that he couldn't think of a reason why payment messages would need to be any bigger than that.Ross suggested embedding the PaymentRequest directly into web pages via the <object> tag in the longer term, which could eliminate the need for BIP0072 and potentially improve user interface integration. However, this would require browser plugins. It's important to keep in mind that links don't always come embedded in html and that native mobile apps also need to be considered in discussions about payment requests.The concern of embedding files into payment requests is due to the security implications it may have. Even file formats like images that are considered safe have had security issues in the past. In response to this, Ross suggests embedding PaymentRequest directly into web pages using the <iframe> tag, which could potentially eliminate the need for BIP0072 and improve user interface integration. However, this approach would require browser plugins.Mike Hearn believes that the current size limit of 50,000 bytes for PaymentRequests should be sufficient. While it might be nice to have images and other visual elements in payment requests to make UIs look prettier, the current size limit should be enough.The PaymentRequests are restricted to 50,000 bytes and there seems to be no reason for payment messages to exceed that limit. If anyone thinks otherwise, they can submit a pull request to the existing BIP. It is suggested that 50kb should be sufficient at present even though it would be good to have images and visuals in payment requests for better user interface in the future.In an email correspondence, Ross suggests standardization for error handling as positive for consistency of user experience. While Gavin Andresen agrees with the need for consistency, he also believes that wallet software should be free to do whatever gives the user the best experience. Ross has taken the main points and created two pull requests (BIP-0070 and BIP-0072) on GitHub for further feedback.The main area of concern is handling unexpected problems while sending the Payment message or receiving the corresponding PaymentACK message. For transport failures or 500 status codes, the client retries after a delay of 30-60 seconds, while for 400 status codes, the request should not be repeated, and the user should be alerted with a copy of the Payment message saved to be resent later. For 300 status codes, it is considered safe to follow redirects. On the merchant's side, Ross suggests that Payment messages should have a fixed maximum size of 10MB and a defined maximum time to wait to avoid DDoS via connection holding. Gavin suggests that PaymentRequests are limited to 50,000 bytes, which seems practical. Regarding repeatedly receiving the same Payment message, Gavin thinks this should be left to implementations to work out. Lastly, there is a potential timing issue with transactions if a merchant system wants to see confirmation of a transaction before sending a PaymentACK. Gavin believes this is not a good idea since the user should get feedback right away, and waiting more than a second or three to get "your payment has been received and is being processed" is terrible UI.Gavin Andresen raises concerns about handling unexpected problems while sending or receiving Payment messages. He proposes that for any transport failure or non-200 HTTP status code, the client should retry after a delay of 30-60 seconds. For 400 status codes, the request should not be repeated, and the user should be alerted with a copy of the Payment message saved to be resent later. Regarding redirect and similar status codes, it is considered safe to follow redirects and referencing whatever RFCs defines how to fetch URLs would be the best way to do this. For merchant systems, Payment messages should have a maximum size of 50,000 bytes, and a defined maximum time to wait to avoid DDoS via connection holding might be useful too. Gavin suggests that merchant systems should handle repeatedly receiving the same Payment message, and return an equivalent (if not identical) PaymentACK to each. Lastly, Gavin wonders about potential timing issues with transactions; if a merchant system wants to see confirmation of a transaction before sending a PaymentACK, he thinks it's not a good idea as the user should get feedback right away.In an email thread from 2014, J Ross Nicoll expressed concern about the lack of specificity on handling error states in the payment protocol specifications. He proposed that for any transport failure or non-200 HTTP status code while sending the Payment message, the client should retry after a delay of 30-60 seconds. For 400 status codes, the request should not be repeated, and as such the user should be alerted and a 2014-04-27T07:53:25+00:00 + In a discussion about payment requests, Ross Nicoll expressed caution regarding the security implications of embedding files into the payment request. He noted that even file formats that are presumed safe, such as images, have had security issues in the past. Mike Hearn responded by pointing out that PaymentRequests are limited to 50,000 bytes and that he couldn't think of a reason why payment messages would need to be any bigger than that.Ross suggested embedding the PaymentRequest directly into web pages via the <object> tag in the longer term, which could eliminate the need for BIP0072 and potentially improve user interface integration. However, this would require browser plugins. It's important to keep in mind that links don't always come embedded in html and that native mobile apps also need to be considered in discussions about payment requests.The concern of embedding files into payment requests is due to the security implications it may have. Even file formats like images that are considered safe have had security issues in the past. In response to this, Ross suggests embedding PaymentRequest directly into web pages using the <iframe> tag, which could potentially eliminate the need for BIP0072 and improve user interface integration. However, this approach would require browser plugins.Mike Hearn believes that the current size limit of 50,000 bytes for PaymentRequests should be sufficient. While it might be nice to have images and other visual elements in payment requests to make UIs look prettier, the current size limit should be enough.The PaymentRequests are restricted to 50,000 bytes and there seems to be no reason for payment messages to exceed that limit. If anyone thinks otherwise, they can submit a pull request to the existing BIP. It is suggested that 50kb should be sufficient at present even though it would be good to have images and visuals in payment requests for better user interface in the future.In an email correspondence, Ross suggests standardization for error handling as positive for consistency of user experience. While Gavin Andresen agrees with the need for consistency, he also believes that wallet software should be free to do whatever gives the user the best experience. Ross has taken the main points and created two pull requests (BIP-0070 and BIP-0072) on GitHub for further feedback.The main area of concern is handling unexpected problems while sending the Payment message or receiving the corresponding PaymentACK message. For transport failures or 500 status codes, the client retries after a delay of 30-60 seconds, while for 400 status codes, the request should not be repeated, and the user should be alerted with a copy of the Payment message saved to be resent later. For 300 status codes, it is considered safe to follow redirects. On the merchant's side, Ross suggests that Payment messages should have a fixed maximum size of 10MB and a defined maximum time to wait to avoid DDoS via connection holding. Gavin suggests that PaymentRequests are limited to 50,000 bytes, which seems practical. Regarding repeatedly receiving the same Payment message, Gavin thinks this should be left to implementations to work out. Lastly, there is a potential timing issue with transactions if a merchant system wants to see confirmation of a transaction before sending a PaymentACK. Gavin believes this is not a good idea since the user should get feedback right away, and waiting more than a second or three to get "your payment has been received and is being processed" is terrible UI.Gavin Andresen raises concerns about handling unexpected problems while sending or receiving Payment messages. He proposes that for any transport failure or non-200 HTTP status code, the client should retry after a delay of 30-60 seconds. For 400 status codes, the request should not be repeated, and the user should be alerted with a copy of the Payment message saved to be resent later. Regarding redirect and similar status codes, it is considered safe to follow redirects and referencing whatever RFCs defines how to fetch URLs would be the best way to do this. For merchant systems, Payment messages should have a maximum size of 50,000 bytes, and a defined maximum time to wait to avoid DDoS via connection holding might be useful too. Gavin suggests that merchant systems should handle repeatedly receiving the same Payment message, and return an equivalent (if not identical) PaymentACK to each. Lastly, Gavin wonders about potential timing issues with transactions; if a merchant system wants to see confirmation of a transaction before sending a PaymentACK, he thinks it's not a good idea as the user should get feedback right away.In an email thread from 2014, J Ross Nicoll expressed concern about the lack of specificity on handling error states in the payment protocol specifications. He proposed that for any transport failure or non-200 HTTP status code while sending the Payment message, the client should retry after a delay of 30-60 seconds. For 400 status codes, the request should not be repeated, and as such the user should be alerted and a - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Feedback-request-colored-coins-protocol.xml b/static/bitcoin-dev/April_2014/combined_Feedback-request-colored-coins-protocol.xml index 9ad407297a..eee94b3f3c 100644 --- a/static/bitcoin-dev/April_2014/combined_Feedback-request-colored-coins-protocol.xml +++ b/static/bitcoin-dev/April_2014/combined_Feedback-request-colored-coins-protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Feedback request: colored coins protocol - 2023-08-01T08:35:02.875329+00:00 + 2025-10-11T21:35:24.941304+00:00 + python-feedgen Flavien Charlon 2014-04-11 12:51:10+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Feedback request: colored coins protocol - 2023-08-01T08:35:02.875329+00:00 + 2025-10-11T21:35:24.941512+00:00 - The email thread discusses the limitation of OP_RETURN's 40 bytes on the number of colored outputs per transaction. The author suggests using a compact format (LEB128) for the asset quantity of each output to mitigate this issue. The approach works well for small amounts of colored coins, but applications like sending dividends in colored coins may require splitting into several smaller transactions. The author believes that it is an acceptable limitation.In response to a comment suggesting that what was being done was no longer colored coins, the author explains that the difference between colored coins and Mastercoin is that colored coins are linked to transaction outputs, while Mastercoin has a notion of address balances. The explicit dependencies of colored coins allow for reliance on SPV, which is not the case with Mastercoin. The author concludes by reiterating the limitation of OP_RETURN size for some applications.The conversation revolves around whether or not a certain project is still using colored coins. The difference between colored coin model and Mastercoin model is explained as colored coins being linked to transaction outputs while Mastercoin has a notion of address balances. Colored coin model's explicit dependencies allow for reliance on SPV, whereas this is not the case with Mastercoin. The approach being described is similar to the original colored coins model in most aspects, but OP_RETURN size limitations can pose problems for some applications. The suggestion is made to look into Counterparty or Mastercoin instead.In an email conversation on October 4th, 2014, Flavien Charlon discusses the issue with using padding to solve asset quantity problems when issuing shares. He suggests that explicitly encoding the asset quantity of every output in the OP_RETURN output is a better solution. This way, whether one is issuing 1 share or 100 trillion, they never need to pay more than 540 satoshis. The person responding to Charlon suggests that what he is doing may no longer be considered colored coins and recommends looking into Counterparty or Mastercoin.Decentralized networks may make it more appropriate to emit fewer shares, as 2 billion shares backed by coloured coins makes less sense than a more conservative number. However, if a company has already created a significant number of shares, then a coloured coin can represent a bundle of shares, with another coloured coin instrument emitted for smaller investors unwilling to deal in terms of bundled shares. Coloured coins have benefits but also constraints that are not difficult to live with. Flavien Charlon suggests that the asset quantity of every output is explicitly encoded in the OP_RETURN output, so whether you are issuing 1 share or 100 trillion, you never need to pay more than 540 satoshis.The email thread discusses the concern with requiring a large BTC capital for issuing coloring coins. The sender is modifying the specification to address it and will post an update when finished. The proposed solution is to encode the asset quantity of every output in the OP_RETURN output. This way, whether one is issuing 1 share or 100 trillion shares, they never need to pay more than 540 satoshis. The recipient of the email argues that using padding is still quite simple, and there are only a few extra lines of code required to handle it. He suggests that it solves the problem once and for all, whereas the proposed solution would create inconvenience for end-users. He also points out that creating different denominations of colored coins would be much more complex and wouldn't work practically.The author of the text is discussing the complexity of adding padding to colored coins, stating that it only requires a few extra lines of code. They argue against an alternative proposal of creating different denominations of colored coins for different share amounts, citing the practicality issue of sending fractional amounts. The author questions why one would prefer to push the complexity to higher levels and create inconvenience for users rather than simply adding a small amount of code to the color kernel. They conclude by stating they will not argue further on the topic.In this context, the discussion is about the use of colored coins to represent shares in a company. The issue at hand is that when buying shares, the buyer may also have to purchase some amount of Bitcoin, which can be inconvenient. One suggestion is to use different colored coins to represent different numbers of shares, like dollar bills of different denominations. It is noted that a proper application layer/UI could hide this from the user and reduce the need for padding. The protocol should remain as simple as possible, and if a UI can work around the issue, it may not be worth complicating the protocol. The dust rule, which sets a minimum transaction value, may disappear one day, rendering the padding parameter useless. The conversation then turns to the idea of listing gold plates on a company's balance sheet. It is clarified that the gold plates are an asset for the owner of the share, not the company itself. The use of gold plates to represent shares raises questions about whether the company is raising capital or selling gold. It is suggested 2014-04-11T12:51:10+00:00 + The email thread discusses the limitation of OP_RETURN's 40 bytes on the number of colored outputs per transaction. The author suggests using a compact format (LEB128) for the asset quantity of each output to mitigate this issue. The approach works well for small amounts of colored coins, but applications like sending dividends in colored coins may require splitting into several smaller transactions. The author believes that it is an acceptable limitation.In response to a comment suggesting that what was being done was no longer colored coins, the author explains that the difference between colored coins and Mastercoin is that colored coins are linked to transaction outputs, while Mastercoin has a notion of address balances. The explicit dependencies of colored coins allow for reliance on SPV, which is not the case with Mastercoin. The author concludes by reiterating the limitation of OP_RETURN size for some applications.The conversation revolves around whether or not a certain project is still using colored coins. The difference between colored coin model and Mastercoin model is explained as colored coins being linked to transaction outputs while Mastercoin has a notion of address balances. Colored coin model's explicit dependencies allow for reliance on SPV, whereas this is not the case with Mastercoin. The approach being described is similar to the original colored coins model in most aspects, but OP_RETURN size limitations can pose problems for some applications. The suggestion is made to look into Counterparty or Mastercoin instead.In an email conversation on October 4th, 2014, Flavien Charlon discusses the issue with using padding to solve asset quantity problems when issuing shares. He suggests that explicitly encoding the asset quantity of every output in the OP_RETURN output is a better solution. This way, whether one is issuing 1 share or 100 trillion, they never need to pay more than 540 satoshis. The person responding to Charlon suggests that what he is doing may no longer be considered colored coins and recommends looking into Counterparty or Mastercoin.Decentralized networks may make it more appropriate to emit fewer shares, as 2 billion shares backed by coloured coins makes less sense than a more conservative number. However, if a company has already created a significant number of shares, then a coloured coin can represent a bundle of shares, with another coloured coin instrument emitted for smaller investors unwilling to deal in terms of bundled shares. Coloured coins have benefits but also constraints that are not difficult to live with. Flavien Charlon suggests that the asset quantity of every output is explicitly encoded in the OP_RETURN output, so whether you are issuing 1 share or 100 trillion, you never need to pay more than 540 satoshis.The email thread discusses the concern with requiring a large BTC capital for issuing coloring coins. The sender is modifying the specification to address it and will post an update when finished. The proposed solution is to encode the asset quantity of every output in the OP_RETURN output. This way, whether one is issuing 1 share or 100 trillion shares, they never need to pay more than 540 satoshis. The recipient of the email argues that using padding is still quite simple, and there are only a few extra lines of code required to handle it. He suggests that it solves the problem once and for all, whereas the proposed solution would create inconvenience for end-users. He also points out that creating different denominations of colored coins would be much more complex and wouldn't work practically.The author of the text is discussing the complexity of adding padding to colored coins, stating that it only requires a few extra lines of code. They argue against an alternative proposal of creating different denominations of colored coins for different share amounts, citing the practicality issue of sending fractional amounts. The author questions why one would prefer to push the complexity to higher levels and create inconvenience for users rather than simply adding a small amount of code to the color kernel. They conclude by stating they will not argue further on the topic.In this context, the discussion is about the use of colored coins to represent shares in a company. The issue at hand is that when buying shares, the buyer may also have to purchase some amount of Bitcoin, which can be inconvenient. One suggestion is to use different colored coins to represent different numbers of shares, like dollar bills of different denominations. It is noted that a proper application layer/UI could hide this from the user and reduce the need for padding. The protocol should remain as simple as possible, and if a UI can work around the issue, it may not be worth complicating the protocol. The dust rule, which sets a minimum transaction value, may disappear one day, rendering the padding parameter useless. The conversation then turns to the idea of listing gold plates on a company's balance sheet. It is clarified that the gold plates are an asset for the owner of the share, not the company itself. The use of gold plates to represent shares raises questions about whether the company is raising capital or selling gold. It is suggested - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Finite-monetary-supply-for-Bitcoin.xml b/static/bitcoin-dev/April_2014/combined_Finite-monetary-supply-for-Bitcoin.xml index 99dfd49ce9..db4d0de1c1 100644 --- a/static/bitcoin-dev/April_2014/combined_Finite-monetary-supply-for-Bitcoin.xml +++ b/static/bitcoin-dev/April_2014/combined_Finite-monetary-supply-for-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Finite monetary supply for Bitcoin - 2023-08-01T08:31:47.284201+00:00 + 2025-10-11T21:36:26.543654+00:00 + python-feedgen Gregory Maxwell 2014-04-05 17:29:49+00:00 @@ -111,13 +112,13 @@ - python-feedgen + 2 Combined summary - Finite monetary supply for Bitcoin - 2023-08-01T08:31:47.284201+00:00 + 2025-10-11T21:36:26.543870+00:00 - The context revolves around a proposal made by Pieter Wuille to turn Bitcoin into a limited-supply currency. The proposal was posted on the Bitcoin-development mailing list on April 1, 2014, and a draft BIP (Bitcoin Improvement Proposal) was provided. Wuille believes that the current subsidy schedule of Bitcoin is no longer acceptable and argues that it is worth exploring this idea. He cites Dogecoin as an example of how easy it is to make such changes and thinks that Bitcoin should demonstrate its commitment to adopting innovative features like non-inflation.However, without more information, it is difficult to assess the validity of the proposal or its potential impact on Bitcoin. The statement raises concerns about a proposal that could potentially harm Bitcoin and attributes it to a Google employee. It is worth noting that Google has been involved in exploring blockchain technology and developing tools for decentralized applications, but it is unclear how this relates to Bitcoin specifically.Overall, the proposal by Pieter Wuille has sparked discussions and comments on the Bitcoin-development mailing list. Wuille encourages feedback on his proposal, and the full text can be found on GitHub at https://gist.github.com/sipa/9920696. 2014-04-05T17:29:49+00:00 + The context revolves around a proposal made by Pieter Wuille to turn Bitcoin into a limited-supply currency. The proposal was posted on the Bitcoin-development mailing list on April 1, 2014, and a draft BIP (Bitcoin Improvement Proposal) was provided. Wuille believes that the current subsidy schedule of Bitcoin is no longer acceptable and argues that it is worth exploring this idea. He cites Dogecoin as an example of how easy it is to make such changes and thinks that Bitcoin should demonstrate its commitment to adopting innovative features like non-inflation.However, without more information, it is difficult to assess the validity of the proposal or its potential impact on Bitcoin. The statement raises concerns about a proposal that could potentially harm Bitcoin and attributes it to a Google employee. It is worth noting that Google has been involved in exploring blockchain technology and developing tools for decentralized applications, but it is unclear how this relates to Bitcoin specifically.Overall, the proposal by Pieter Wuille has sparked discussions and comments on the Bitcoin-development mailing list. Wuille encourages feedback on his proposal, and the full text can be found on GitHub at https://gist.github.com/sipa/9920696. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Mailing-list-abuse.xml b/static/bitcoin-dev/April_2014/combined_Mailing-list-abuse.xml index 1d0a9937db..655b47b428 100644 --- a/static/bitcoin-dev/April_2014/combined_Mailing-list-abuse.xml +++ b/static/bitcoin-dev/April_2014/combined_Mailing-list-abuse.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mailing list abuse - 2023-08-01T08:53:43.848398+00:00 + 2025-10-11T21:35:41.930414+00:00 + python-feedgen Rodney Morris 2014-04-21 06:02:21+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Mailing list abuse - 2023-08-01T08:53:43.848398+00:00 + 2025-10-11T21:35:41.930577+00:00 - In an email exchange on April 21, 2014, Rodney Morris raised a question about the proper procedure for handling situations where someone quotes an entire digest for the sake of a few lines of content. He further questioned whether this behavior could be classified as abuse and whether others were bothered by it. The specific mailing list or forum to which this email was sent is not specified.Wladimir responded to Rodney's query, stating that he would not categorize this behavior as abuse unless it was done intentionally. Instead of publicly complaining on the mailing list, Wladimir suggested privately asking the person involved about their quoting practices. By addressing the issue personally, it would provide an opportunity for clarification and understanding.Acknowledging Wladimir's feedback, Rodney expressed his gratitude for the response and explained that he noticed this issue more frequently due to primarily accessing the list on a mobile device. It is evident that Rodney sought guidance on how to handle the situation effectively and was open to understanding different perspectives on the matter.Overall, the email exchange highlights Rodney's concern about the practice of quoting an entire digest for only a few lines of content. Wladimir's response emphasizes the importance of addressing the issue privately with the individual involved rather than resorting to public complaints. Rodney's acknowledgment of the feedback and explanation of his own circumstances further adds context to the discussion. 2014-04-21T06:02:21+00:00 + In an email exchange on April 21, 2014, Rodney Morris raised a question about the proper procedure for handling situations where someone quotes an entire digest for the sake of a few lines of content. He further questioned whether this behavior could be classified as abuse and whether others were bothered by it. The specific mailing list or forum to which this email was sent is not specified.Wladimir responded to Rodney's query, stating that he would not categorize this behavior as abuse unless it was done intentionally. Instead of publicly complaining on the mailing list, Wladimir suggested privately asking the person involved about their quoting practices. By addressing the issue personally, it would provide an opportunity for clarification and understanding.Acknowledging Wladimir's feedback, Rodney expressed his gratitude for the response and explained that he noticed this issue more frequently due to primarily accessing the list on a mobile device. It is evident that Rodney sought guidance on how to handle the situation effectively and was open to understanding different perspectives on the matter.Overall, the email exchange highlights Rodney's concern about the practice of quoting an entire digest for only a few lines of content. Wladimir's response emphasizes the importance of addressing the issue privately with the individual involved rather than resorting to public complaints. Rodney's acknowledgment of the feedback and explanation of his own circumstances further adds context to the discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_New-BIP32-structure-for-P2SH-multisig-wallets.xml b/static/bitcoin-dev/April_2014/combined_New-BIP32-structure-for-P2SH-multisig-wallets.xml index 86f7e7db86..67d1861f40 100644 --- a/static/bitcoin-dev/April_2014/combined_New-BIP32-structure-for-P2SH-multisig-wallets.xml +++ b/static/bitcoin-dev/April_2014/combined_New-BIP32-structure-for-P2SH-multisig-wallets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP32 structure for P2SH multisig wallets - 2023-08-01T09:03:33.563527+00:00 + 2025-10-11T21:35:20.642816+00:00 + python-feedgen Jeff Garzik 2014-04-28 01:37:00+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - New BIP32 structure for P2SH multisig wallets - 2023-08-01T09:03:33.564531+00:00 + 2025-10-11T21:35:20.642986+00:00 - In an email exchange between Thomas Voegtlin and Jeff Garzik, the issue of standardization of public keys in the redeem script was discussed. Voegtlin suggested that the public keys should be sorted in a standardized order to prevent the p2sh address from depending on their order. Garzik agreed with this solution, mentioning that it had already been implemented in some wallets.The discussion revolves around using a shared branch or separate branches for generating receiving addresses in a 2-of-2 multisig wallet. The issue with using one shared branch is that two cosigners could end up distributing the same address, which can be problematic. However, if each cosigner has their own unique seed and key hierarchy, then there is no shared branch. Instead, every address generated by either party is a 2-of-2 address using private seeds k1 and k2. In an email conversation, Mike Hearn discussed the use of HD wallets for cosigners and why a separate branch is necessary for each cosigner. Hearn suggests using regular HD wallets and swapping watching keys to avoid generating the same address and receiving simultaneous payments. By separating branches and having each cosigner use only one branch, this problem can be eliminated. The purpose of the cosigner_index is to prevent race conditions when receiving payments.In another email exchange, Mike Hearn proposed swapping watching keys instead of giving individuals a cosigner index since they all have unique root keys. Another individual agreed with this suggestion. The only standardization necessary may be the order of public keys in the redeem script to ensure that the p2sh address does not depend on the order of pubkeys.Manuel Araoz, part of the team that developed Copay, a multisignature P2SH HD wallet, shared their approach to a new standard for the structure of branches in such wallets. Each party generates their own extended master keypair and shares the extended purpose’ public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys, and then generate the multisig script and the corresponding p2sh address. All parties must be able to generate all public keys, and transaction creation and signing requires communication between parties.The team building the multisignature P2SH HD wallet called Copay has shared their approach for a new standard in response to discussions on standardizing the structure for branches. Each cosigner generates their own extended master keypair and shares the extended purpose' public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys. They do this by deriving the public key in each of the different trees, but using the same path. One of the n cosigners wants to receive a payment to the shared wallet. He knows the last used index in his own branch because only he generates addresses there. Thus, he can generate the public keys for all of the others using the next index and calculate the needed script for the address. When creating a transaction, first one of the parties creates a Transaction Proposal. This is a transaction that spends some output stored in any of the p2sh multisig addresses (corresponding to any of the copayers' branches). This proposal is sent to the other parties, who decide if they want to sign. If they approve the proposal, they can generate their needed private key for that specific address (using the same path that generated the public key in that address, but deriving the private key instead), and sign it. Once the proposal reaches m signatures, any cosigner can broadcast it to the network, becoming final.The team building the multisignature P2SH HD wallet has shared their approach to address generation and transaction signing for a multisig HD wallet. They have proposed the use of BIP43, with levels defined as m / purpose' / cosigner_index / change / address_index. Each level has a special meaning, including the index of the party creating the address, whether it is for change or receive address, and addresses numbered from index 0 in sequentially increasing manner. The team's high-level description of their wallet involves each party generating their own extended master keypair and sharing the extended purpose' public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys. In the receive address case, only one of the n cosigners generates addresses and knows the last used index in his own branch, while in the change address case, one of the n cosigners wants to create an outgoing payment, for which he'll need a change address. When creating a transaction, one of the parties creates a Transaction Proposal which is sent to the other parties who decide if they want to sign it. Once the proposal reaches m signatures, any cosigner can broadcast it to the network.There are still some questions left unanswered by the team, including whether cosigners 2014-04-28T01:37:00+00:00 + In an email exchange between Thomas Voegtlin and Jeff Garzik, the issue of standardization of public keys in the redeem script was discussed. Voegtlin suggested that the public keys should be sorted in a standardized order to prevent the p2sh address from depending on their order. Garzik agreed with this solution, mentioning that it had already been implemented in some wallets.The discussion revolves around using a shared branch or separate branches for generating receiving addresses in a 2-of-2 multisig wallet. The issue with using one shared branch is that two cosigners could end up distributing the same address, which can be problematic. However, if each cosigner has their own unique seed and key hierarchy, then there is no shared branch. Instead, every address generated by either party is a 2-of-2 address using private seeds k1 and k2. In an email conversation, Mike Hearn discussed the use of HD wallets for cosigners and why a separate branch is necessary for each cosigner. Hearn suggests using regular HD wallets and swapping watching keys to avoid generating the same address and receiving simultaneous payments. By separating branches and having each cosigner use only one branch, this problem can be eliminated. The purpose of the cosigner_index is to prevent race conditions when receiving payments.In another email exchange, Mike Hearn proposed swapping watching keys instead of giving individuals a cosigner index since they all have unique root keys. Another individual agreed with this suggestion. The only standardization necessary may be the order of public keys in the redeem script to ensure that the p2sh address does not depend on the order of pubkeys.Manuel Araoz, part of the team that developed Copay, a multisignature P2SH HD wallet, shared their approach to a new standard for the structure of branches in such wallets. Each party generates their own extended master keypair and shares the extended purpose’ public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys, and then generate the multisig script and the corresponding p2sh address. All parties must be able to generate all public keys, and transaction creation and signing requires communication between parties.The team building the multisignature P2SH HD wallet called Copay has shared their approach for a new standard in response to discussions on standardizing the structure for branches. Each cosigner generates their own extended master keypair and shares the extended purpose' public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys. They do this by deriving the public key in each of the different trees, but using the same path. One of the n cosigners wants to receive a payment to the shared wallet. He knows the last used index in his own branch because only he generates addresses there. Thus, he can generate the public keys for all of the others using the next index and calculate the needed script for the address. When creating a transaction, first one of the parties creates a Transaction Proposal. This is a transaction that spends some output stored in any of the p2sh multisig addresses (corresponding to any of the copayers' branches). This proposal is sent to the other parties, who decide if they want to sign. If they approve the proposal, they can generate their needed private key for that specific address (using the same path that generated the public key in that address, but deriving the private key instead), and sign it. Once the proposal reaches m signatures, any cosigner can broadcast it to the network, becoming final.The team building the multisignature P2SH HD wallet has shared their approach to address generation and transaction signing for a multisig HD wallet. They have proposed the use of BIP43, with levels defined as m / purpose' / cosigner_index / change / address_index. Each level has a special meaning, including the index of the party creating the address, whether it is for change or receive address, and addresses numbered from index 0 in sequentially increasing manner. The team's high-level description of their wallet involves each party generating their own extended master keypair and sharing the extended purpose' public key with the others, which is stored encrypted. When generating an address, each party can independently generate the N needed public keys. In the receive address case, only one of the n cosigners generates addresses and knows the last used index in his own branch, while in the change address case, one of the n cosigners wants to create an outgoing payment, for which he'll need a change address. When creating a transaction, one of the parties creates a Transaction Proposal which is sent to the other parties who decide if they want to sign it. Once the proposal reaches m signatures, any cosigner can broadcast it to the network.There are still some questions left unanswered by the team, including whether cosigners - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_New-BIP32-structure.xml b/static/bitcoin-dev/April_2014/combined_New-BIP32-structure.xml index 914e8fff22..24069d2203 100644 --- a/static/bitcoin-dev/April_2014/combined_New-BIP32-structure.xml +++ b/static/bitcoin-dev/April_2014/combined_New-BIP32-structure.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP32 structure - 2023-08-01T08:08:37.970792+00:00 + 2025-10-11T21:36:41.409664+00:00 + python-feedgen Thomas Voegtlin 2014-04-24 08:15:18+00:00 @@ -403,13 +404,13 @@ - python-feedgen + 2 Combined summary - New BIP32 structure - 2023-08-01T08:08:37.974781+00:00 + 2025-10-11T21:36:41.410090+00:00 - In a series of email exchanges among Bitcoin developers, discussions and debates took place regarding the implementation and compatibility of BIP64 with BIP32. Pavol Rusnak argued that clients should be able to specify which subwallet they are accessing to ensure compatibility. However, he stated that calling these clients BIP64 compatible would be inaccurate if they cannot distinguish between subwallets and keep coins apart. There were differing views on the restrictiveness of BIP64, with some developers asserting that most end users do not need subwallet support.Developers also discussed the behavior of software that scans all accounts specified by BIP64 without providing user interface options to distinguish them or keep the coins apart. Marek explained that mixing funds across accounts is not compliant with the spec, and the wallet should never mix coins across different accounts. Pieter Wuille questioned the need for mixing funds between accounts, as it was seen as a niche requirement.Furthermore, conversations revolved around storing wallet birth time and importing clients. Tamas Blummer suggested appending key birth to key serialization in xprv, while modifying the serialization format was considered a potential solution. The goal was to find a solution that fit all requirements, but developers had differing opinions.Discussions also touched on the standardization of wallet structures, the importance of compatibility, and the challenges of achieving a single system that is compatible across multiple platforms. Developers emphasized the need for a standard structure for sharing wallets, with debates about the best way to store seeds and master nodes. There were disagreements on specific aspects of implementation, but the overall goal was to improve functionality and meet the needs of different users.There were suggestions to use one seed across different chains with separate master nodes derived by replacing "Bitcoin seed" with something chain-specific. Another suggestion was to have each encoded node, including master nodes, with a chain-specific serialization magic. It was debated whether using "cointype" in the bip32 path was necessary, but it was seen as an elegant solution for a single backup that can handle all coins with one master.The discussions also addressed the need for compatibility and standardization among wallet software. The importance of having a single system compatible over a large number of systems was emphasized. However, there were disagreements on implementing BIP64 fully or not at all, as using only a subset of the specification could confuse users.In conclusion, the conversations among Bitcoin developers revolved around the implementation and compatibility of BIP64 with BIP32, the need for standard structures in sharing wallets, and the challenges of achieving compatibility across multiple platforms. There were differing views on various aspects, such as the restrictiveness of BIP64 and the necessity of multiple subwallets. The discussions highlighted the ongoing efforts to find the best solutions and improve the functionality of Bitcoin wallets.During discussions in March 2014, Bitcoin developers focused on improving the structure of Bitcoin Improvement Proposal (BIP) and Bitcoin wallets. One suggestion was to increase the number of unused addresses available in lightweight or server-based wallets and count the number of unused addresses since the beginning instead of using a "gap limit." Bandwidth issues for Electrum and Mycelium were also addressed, with proposals to pre-generate a larger lookahead region and request more data at once.The topic of altcoins was brought up, with Testnet being highlighted as an important one. Different methods of identifying altcoins were discussed, such as using a hash of certain words or maintaining a directory of magic numbers. The purpose of the "reserved" feature in Bitcoin was questioned, and it was confirmed that it was intended for multisig addresses.Andreas Schildbach initiated a discussion on finding a better structure for Bitcoin wallets, emphasizing the need for interoperability and addressing bandwidth limitations. Distinguishing between merchant and regular user accounts was proposed, and a BIP32 wallet structure (/m/cointype/reserved'/account'/change/n) was suggested by Mike Hearn. Interoperability between wallets was deemed important, although metadata might be necessary alongside the hierarchical structure.At the Inside Bitcoin Conference in Berlin, developers debated the standardization of BIP32 wallet structures. They discussed the use of hierarchy and suggested using a hash of certain words instead of a directory of magic numbers. Armory Technologies announced plans to implement multi-sig/linked wallets, allowing users to switch to new apps without losing their coin history. Discouraging the use of a common root keychain for multiple keys in the same P2SH address was recommended.Discussions continued in March 2014 to create a compatible BIP32 wallet structure for different wallets. Mike Hearn proposed a new structure (/m/cointype/reserved'/account'/change/n) that was agreed upon by Thomas V and Marek. The structure aimed to meet users' needs while allowing flexibility. The topic of altcoins was also discussed, considering the potential larger trade volume of altcoins compared to Bitcoin.The ongoing discussion among Bitcoin developers focused on achieving better structure for 2014-04-24T08:15:18+00:00 + In a series of email exchanges among Bitcoin developers, discussions and debates took place regarding the implementation and compatibility of BIP64 with BIP32. Pavol Rusnak argued that clients should be able to specify which subwallet they are accessing to ensure compatibility. However, he stated that calling these clients BIP64 compatible would be inaccurate if they cannot distinguish between subwallets and keep coins apart. There were differing views on the restrictiveness of BIP64, with some developers asserting that most end users do not need subwallet support.Developers also discussed the behavior of software that scans all accounts specified by BIP64 without providing user interface options to distinguish them or keep the coins apart. Marek explained that mixing funds across accounts is not compliant with the spec, and the wallet should never mix coins across different accounts. Pieter Wuille questioned the need for mixing funds between accounts, as it was seen as a niche requirement.Furthermore, conversations revolved around storing wallet birth time and importing clients. Tamas Blummer suggested appending key birth to key serialization in xprv, while modifying the serialization format was considered a potential solution. The goal was to find a solution that fit all requirements, but developers had differing opinions.Discussions also touched on the standardization of wallet structures, the importance of compatibility, and the challenges of achieving a single system that is compatible across multiple platforms. Developers emphasized the need for a standard structure for sharing wallets, with debates about the best way to store seeds and master nodes. There were disagreements on specific aspects of implementation, but the overall goal was to improve functionality and meet the needs of different users.There were suggestions to use one seed across different chains with separate master nodes derived by replacing "Bitcoin seed" with something chain-specific. Another suggestion was to have each encoded node, including master nodes, with a chain-specific serialization magic. It was debated whether using "cointype" in the bip32 path was necessary, but it was seen as an elegant solution for a single backup that can handle all coins with one master.The discussions also addressed the need for compatibility and standardization among wallet software. The importance of having a single system compatible over a large number of systems was emphasized. However, there were disagreements on implementing BIP64 fully or not at all, as using only a subset of the specification could confuse users.In conclusion, the conversations among Bitcoin developers revolved around the implementation and compatibility of BIP64 with BIP32, the need for standard structures in sharing wallets, and the challenges of achieving compatibility across multiple platforms. There were differing views on various aspects, such as the restrictiveness of BIP64 and the necessity of multiple subwallets. The discussions highlighted the ongoing efforts to find the best solutions and improve the functionality of Bitcoin wallets.During discussions in March 2014, Bitcoin developers focused on improving the structure of Bitcoin Improvement Proposal (BIP) and Bitcoin wallets. One suggestion was to increase the number of unused addresses available in lightweight or server-based wallets and count the number of unused addresses since the beginning instead of using a "gap limit." Bandwidth issues for Electrum and Mycelium were also addressed, with proposals to pre-generate a larger lookahead region and request more data at once.The topic of altcoins was brought up, with Testnet being highlighted as an important one. Different methods of identifying altcoins were discussed, such as using a hash of certain words or maintaining a directory of magic numbers. The purpose of the "reserved" feature in Bitcoin was questioned, and it was confirmed that it was intended for multisig addresses.Andreas Schildbach initiated a discussion on finding a better structure for Bitcoin wallets, emphasizing the need for interoperability and addressing bandwidth limitations. Distinguishing between merchant and regular user accounts was proposed, and a BIP32 wallet structure (/m/cointype/reserved'/account'/change/n) was suggested by Mike Hearn. Interoperability between wallets was deemed important, although metadata might be necessary alongside the hierarchical structure.At the Inside Bitcoin Conference in Berlin, developers debated the standardization of BIP32 wallet structures. They discussed the use of hierarchy and suggested using a hash of certain words instead of a directory of magic numbers. Armory Technologies announced plans to implement multi-sig/linked wallets, allowing users to switch to new apps without losing their coin history. Discouraging the use of a common root keychain for multiple keys in the same P2SH address was recommended.Discussions continued in March 2014 to create a compatible BIP32 wallet structure for different wallets. Mike Hearn proposed a new structure (/m/cointype/reserved'/account'/change/n) that was agreed upon by Thomas V and Marek. The structure aimed to meet users' needs while allowing flexibility. The topic of altcoins was also discussed, considering the potential larger trade volume of altcoins compared to Bitcoin.The ongoing discussion among Bitcoin developers focused on achieving better structure for - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Okay-time-to-bring-up-bitcoin-bitcoin.xml b/static/bitcoin-dev/April_2014/combined_Okay-time-to-bring-up-bitcoin-bitcoin.xml index d92414d9e1..d0d771aa29 100644 --- a/static/bitcoin-dev/April_2014/combined_Okay-time-to-bring-up-bitcoin-bitcoin.xml +++ b/static/bitcoin-dev/April_2014/combined_Okay-time-to-bring-up-bitcoin-bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Okay, time to bring up bitcoin/bitcoin - 2023-08-01T08:32:05.435058+00:00 + 2025-10-11T21:36:30.790644+00:00 + python-feedgen Kevin 2014-04-02 16:57:20+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Okay, time to bring up bitcoin/bitcoin - 2023-08-01T08:32:05.435058+00:00 + 2025-10-11T21:36:30.790842+00:00 - On April 2, 2014, Kevin shared a link to his project on the Bitcoin-development mailing list. However, the link he provided led to a suspicious phishing site. Some members of the mailing list questioned the legitimacy of Kevin's project, while others suggested that he may have accidentally linked to the wrong website. Laszlo Hanyecz speculated that Kevin's use of speech to text or other assistive technology may have caused him to write "U R L" instead of "URL." Jud eventually pointed out the correct repository location for Kevin's project at https://github.com/kjsisco/bitcoin/tree/patch-1.Kevin expressed frustration at the confusion surrounding his project and assured the others that he was not engaged in phishing. He promised to register a domain for his project and create a proper webpage to avoid further confusion. In subsequent messages, Kevin defended his project, stating that it was serious and urged people to look at it to start an open dialog about it. Ricardo Filipe requested the correct URL of Kevin's project, which was resolved with the correct link being provided by Jud.There was discussion about the possibility of the phishing link being accidentally shared by someone with a similar username. Jeff Garzik criticized Kevin's choice of URL, calling it a phishing attempt. However, Kevin defended himself, stating that his project was serious and he wanted it connected with the Bitcoin core. He acknowledged the need to register a domain for his project to avoid confusion and emphasized that he would never set up a phishing link.Laszlo Hanyecz reported that the website www.githubb.com, associated with the IP addresses announced by AS53665, resolved to a malware site. This information should be taken into consideration when accessing websites associated with this AS number. The conversation also touched on online privacy and the importance of email encryption.In conclusion, Kevin shared a link to his forked project from Bitcoin core and invited feedback. There were concerns about the legitimacy of the link and suspicions of it being a phishing attempt. Kevin defended his project, stating that it was serious and urged open dialogue about it. The conversation also included discussions about online privacy and the presence of malware on certain websites. 2014-04-02T16:57:20+00:00 + On April 2, 2014, Kevin shared a link to his project on the Bitcoin-development mailing list. However, the link he provided led to a suspicious phishing site. Some members of the mailing list questioned the legitimacy of Kevin's project, while others suggested that he may have accidentally linked to the wrong website. Laszlo Hanyecz speculated that Kevin's use of speech to text or other assistive technology may have caused him to write "U R L" instead of "URL." Jud eventually pointed out the correct repository location for Kevin's project at https://github.com/kjsisco/bitcoin/tree/patch-1.Kevin expressed frustration at the confusion surrounding his project and assured the others that he was not engaged in phishing. He promised to register a domain for his project and create a proper webpage to avoid further confusion. In subsequent messages, Kevin defended his project, stating that it was serious and urged people to look at it to start an open dialog about it. Ricardo Filipe requested the correct URL of Kevin's project, which was resolved with the correct link being provided by Jud.There was discussion about the possibility of the phishing link being accidentally shared by someone with a similar username. Jeff Garzik criticized Kevin's choice of URL, calling it a phishing attempt. However, Kevin defended himself, stating that his project was serious and he wanted it connected with the Bitcoin core. He acknowledged the need to register a domain for his project to avoid confusion and emphasized that he would never set up a phishing link.Laszlo Hanyecz reported that the website www.githubb.com, associated with the IP addresses announced by AS53665, resolved to a malware site. This information should be taken into consideration when accessing websites associated with this AS number. The conversation also touched on online privacy and the importance of email encryption.In conclusion, Kevin shared a link to his forked project from Bitcoin core and invited feedback. There were concerns about the legitimacy of the link and suspicions of it being a phishing attempt. Kevin defended his project, stating that it was serious and urged open dialogue about it. The conversation also included discussions about online privacy and the presence of malware on certain websites. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml b/static/bitcoin-dev/April_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml index bdae5cf2a5..aac935a08c 100644 --- a/static/bitcoin-dev/April_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml +++ b/static/bitcoin-dev/April_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys - 2023-08-01T08:17:21.054953+00:00 + 2025-10-11T21:36:52.061053+00:00 + python-feedgen Nikita Schmidt 2014-08-14 19:23:16+00:00 @@ -363,13 +364,13 @@ - python-feedgen + 2 Combined summary - Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys - 2023-08-01T08:17:21.055952+00:00 + 2025-10-11T21:36:52.061421+00:00 - Jan Møller, in an email exchange, expressed his opinion that the current format of the Shared Secret Sharing (SSS) standard is over-engineered. He suggested that only the long format makes sense from a user experience standpoint and proposed that it is only slightly longer than the short version. After no objections were raised, the draft was revised to address this concern.The new version of the SSS standard allows for the shared secret to be encoded in various forms, such as SIPA or BIP38, instead of just a plain private key. This change has several benefits, including not needing to modify the specification for different types of content and encoding metadata together with the secret. The underlying field of the standard was also changed to GF(256), which is more advantageous for dealing with secrets of arbitrary length.To solve the issue of variable length and lack of control over the Base58 prefix, the magic prefix was moved outside of the Base58 encoded content. The application identifier 'SSS-' was introduced, followed by the Base58 encoding of the share. This change may be mildly controversial, and alternatives could be considered.A Java implementation of BIPSS based on a GF2^8 implementation can be found on Github. The use of three encoding formats in the SSS standard is considered over-engineered, with the long format being the only necessary option from a user experience perspective. A fork of Matt's proposal converted to GF(2^8) is also available on Github, which includes changes like allocating only six application/version bytes and using SHA-256 hash functions.The inclusion of a specific flag for testnet in SSS and BIP32 was discussed in email exchanges. It was agreed that such flags are unnecessary since they are not used for sending addresses. The convention so far has been to include a 'version' identifier to identify the purpose of the data, such as network meaning.There was a debate about the importance of testnet in Bitcoin Improvement Proposals (BIPs). Some argued that testnet exists for public testing involving multiple people and services, while others saw it as a tool for certain types of testing. It was noted that testnet is not normally addressed in BIPs, except for soft fork BIPs with compressed deployment schedules on testnet.The serialization of keys when using test chains was discussed, with some expressing that distinguishing serialization of keys is unnecessary. The difference between testnet and mainnet was emphasized as separate from bitcoin vs altcoin, but few altcoins understood this distinction.The issue of encoding the chain in WIF and BIP32 was debated, with some suggesting that it should be ignored as legacy. New BIPs should no longer carry this forward.Discussions also took place regarding the encoding of N-of-M shares. Suggestions were made to encode N-of-M in one byte and to use a bias of -1 for M encoding. Test vectors were updated accordingly.Tamas Blummer expressed his opinion that extra encoding for testnet is not necessary compared to many alt chains. He suggested that BIPs should remain chain agnostic.In an email exchange between Jan Møller and Gregory Maxwell, Møller expressed his concerns about BIP38 and suggested using Shamir's Secret Sharing instead. It is unclear if Møller provided a list of concerns about BIP38 or offered to do so upon request.Tamas Blummer argued that the wide variety of available chains supersedes the notion of main and testnet. He believes that what altcoins do is their own business and outside the scope of a BIP. He also questioned the need for a separate encoding for Bitcoin testnet private keys.Overall, the discussions revolved around simplifying the SSS standard, considering the use cases for testnet and altchains, and debating the encoding of keys and chains in various contexts.The complexity of using the binary extension field of GF(2^8) for secret sharing and data integrity applications was discussed. Some suggested that big-integer operations may be more practical, while others argued that implementing a complex system with many individually testable parts is easier than implementing a single complex part. Gregory Maxwell's implementation of his Bitcoin Improvement Proposal (BIP) is in C++ and uses the GMP library for big-integer arithmetic.There was a debate about the potential risks of obfuscating the parameters of the secret sharing process. Some expressed concerns about users accidentally mixing different types of fragments or distributing too many, which can lead to insecurity or difficulty in restoring their wallets. However, it was acknowledged that attackers may still be able to figure out the information despite the obfuscation.Matt Whitlock proposed an obfuscation method for the secret sharing process but ultimately decided against it based on the consensus of others. Alan Reiner disagreed with this tradeoff, stating that obfuscating something already considered secure at the expense of usability is not beneficial. He argued that it is more important for users to understand what 2014-08-14T19:23:16+00:00 + Jan Møller, in an email exchange, expressed his opinion that the current format of the Shared Secret Sharing (SSS) standard is over-engineered. He suggested that only the long format makes sense from a user experience standpoint and proposed that it is only slightly longer than the short version. After no objections were raised, the draft was revised to address this concern.The new version of the SSS standard allows for the shared secret to be encoded in various forms, such as SIPA or BIP38, instead of just a plain private key. This change has several benefits, including not needing to modify the specification for different types of content and encoding metadata together with the secret. The underlying field of the standard was also changed to GF(256), which is more advantageous for dealing with secrets of arbitrary length.To solve the issue of variable length and lack of control over the Base58 prefix, the magic prefix was moved outside of the Base58 encoded content. The application identifier 'SSS-' was introduced, followed by the Base58 encoding of the share. This change may be mildly controversial, and alternatives could be considered.A Java implementation of BIPSS based on a GF2^8 implementation can be found on Github. The use of three encoding formats in the SSS standard is considered over-engineered, with the long format being the only necessary option from a user experience perspective. A fork of Matt's proposal converted to GF(2^8) is also available on Github, which includes changes like allocating only six application/version bytes and using SHA-256 hash functions.The inclusion of a specific flag for testnet in SSS and BIP32 was discussed in email exchanges. It was agreed that such flags are unnecessary since they are not used for sending addresses. The convention so far has been to include a 'version' identifier to identify the purpose of the data, such as network meaning.There was a debate about the importance of testnet in Bitcoin Improvement Proposals (BIPs). Some argued that testnet exists for public testing involving multiple people and services, while others saw it as a tool for certain types of testing. It was noted that testnet is not normally addressed in BIPs, except for soft fork BIPs with compressed deployment schedules on testnet.The serialization of keys when using test chains was discussed, with some expressing that distinguishing serialization of keys is unnecessary. The difference between testnet and mainnet was emphasized as separate from bitcoin vs altcoin, but few altcoins understood this distinction.The issue of encoding the chain in WIF and BIP32 was debated, with some suggesting that it should be ignored as legacy. New BIPs should no longer carry this forward.Discussions also took place regarding the encoding of N-of-M shares. Suggestions were made to encode N-of-M in one byte and to use a bias of -1 for M encoding. Test vectors were updated accordingly.Tamas Blummer expressed his opinion that extra encoding for testnet is not necessary compared to many alt chains. He suggested that BIPs should remain chain agnostic.In an email exchange between Jan Møller and Gregory Maxwell, Møller expressed his concerns about BIP38 and suggested using Shamir's Secret Sharing instead. It is unclear if Møller provided a list of concerns about BIP38 or offered to do so upon request.Tamas Blummer argued that the wide variety of available chains supersedes the notion of main and testnet. He believes that what altcoins do is their own business and outside the scope of a BIP. He also questioned the need for a separate encoding for Bitcoin testnet private keys.Overall, the discussions revolved around simplifying the SSS standard, considering the use cases for testnet and altchains, and debating the encoding of keys and chains in various contexts.The complexity of using the binary extension field of GF(2^8) for secret sharing and data integrity applications was discussed. Some suggested that big-integer operations may be more practical, while others argued that implementing a complex system with many individually testable parts is easier than implementing a single complex part. Gregory Maxwell's implementation of his Bitcoin Improvement Proposal (BIP) is in C++ and uses the GMP library for big-integer arithmetic.There was a debate about the potential risks of obfuscating the parameters of the secret sharing process. Some expressed concerns about users accidentally mixing different types of fragments or distributing too many, which can lead to insecurity or difficulty in restoring their wallets. However, it was acknowledged that attackers may still be able to figure out the information despite the obfuscation.Matt Whitlock proposed an obfuscation method for the secret sharing process but ultimately decided against it based on the consensus of others. Alan Reiner disagreed with this tradeoff, stating that obfuscating something already considered secure at the expense of usability is not beneficial. He argued that it is more important for users to understand what - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Proof-of-Stake-branch-.xml b/static/bitcoin-dev/April_2014/combined_Proof-of-Stake-branch-.xml index a50b485f2c..e0ba184aae 100644 --- a/static/bitcoin-dev/April_2014/combined_Proof-of-Stake-branch-.xml +++ b/static/bitcoin-dev/April_2014/combined_Proof-of-Stake-branch-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proof-of-Stake branch? - 2023-08-01T08:59:18.763306+00:00 + 2025-10-11T21:35:48.309425+00:00 + python-feedgen Alex Mizrahi 2014-04-28 12:03:54+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Proof-of-Stake branch? - 2023-08-01T08:59:18.763306+00:00 + 2025-10-11T21:35:48.309577+00:00 - Vitalik Buterin discussed the concept of a "punitive proof-of-stake algorithm" in an article on the Ethereum blog. This idea has been previously mentioned in discussions about PPCoin and Etlase2's Decrit design. Mark Friedenbach raised concerns about the lack of stake in proof-of-stake mining, which could lead to double-spends. Gareth Williams suggested using fraud proofs to mitigate this issue, while Friedenbach argued that it would still reduce to proof-of-work mining. The discussion took place on the bitcoin-development mailing list in April 2014.Stephen Reed proposed creating a Bitcoin branch to research the best proof-of-stake implementations. He conducted a poll on bitcointalk.org, showing minority support for Bitcoin proof-of-stake. Reed aims to develop, test, and document proof-of-stake while addressing its vulnerabilities transparently. Some members of the community, including Mark Friedenbach, have proposed protocols involving proof of stake mechanisms. However, replacing proof-of-work with proof-of-stake encounters problems due to the lack of stakes involved.There was also a discussion about the compatibility of proof-of-stake blockchains with the sidechain/two-way peg system invented by Greg Maxwell. The author plans to explore this concept and merge-mining support, examining ideas from PPC, NXT, and whitepapers to create a Bitcoin implementation without wasteful proof-of-work. The author suggests that coin age is a good starting point and proposes a reference peer-to-peer pool for fair distribution of mining rewards. A Proof-of-Stake Bitcoin project thread will be established on Bitcointalk for technical discussion and the creation of a list of principles.In addition, Stephen Reed proposed the creation of a Bitcoin branch as a sandboxed testbed for researching the best proof-of-stake implementations. He conducted a poll on Bitcointalk, which showed some minority support for Bitcoin proof-of-stake. Reed's goal is to develop, test, and document proof-of-stake while exploring vulnerabilities and fixing them transparently. He suggests calling the project 'bitstake' to differentiate it from Bitcoin.Lastly, Gmail has been spamfoldering emails from Yahoo due to DMARC enforcement, making it incompatible with Sourceforge mailing lists. Two solutions are suggested: not using Yahoo or stopping the use of Sourceforge mailing list software. There is also a discussion about the compatibility of alternate decentralized consensus algorithms with the sidechain/two-way peg system in Bitcoin. The author suggests that if alternate consensus algorithms cannot retain compatibility, altcoin experiments with different proof models may have limited interoperability as sidechains. 2014-04-28T12:03:54+00:00 + Vitalik Buterin discussed the concept of a "punitive proof-of-stake algorithm" in an article on the Ethereum blog. This idea has been previously mentioned in discussions about PPCoin and Etlase2's Decrit design. Mark Friedenbach raised concerns about the lack of stake in proof-of-stake mining, which could lead to double-spends. Gareth Williams suggested using fraud proofs to mitigate this issue, while Friedenbach argued that it would still reduce to proof-of-work mining. The discussion took place on the bitcoin-development mailing list in April 2014.Stephen Reed proposed creating a Bitcoin branch to research the best proof-of-stake implementations. He conducted a poll on bitcointalk.org, showing minority support for Bitcoin proof-of-stake. Reed aims to develop, test, and document proof-of-stake while addressing its vulnerabilities transparently. Some members of the community, including Mark Friedenbach, have proposed protocols involving proof of stake mechanisms. However, replacing proof-of-work with proof-of-stake encounters problems due to the lack of stakes involved.There was also a discussion about the compatibility of proof-of-stake blockchains with the sidechain/two-way peg system invented by Greg Maxwell. The author plans to explore this concept and merge-mining support, examining ideas from PPC, NXT, and whitepapers to create a Bitcoin implementation without wasteful proof-of-work. The author suggests that coin age is a good starting point and proposes a reference peer-to-peer pool for fair distribution of mining rewards. A Proof-of-Stake Bitcoin project thread will be established on Bitcointalk for technical discussion and the creation of a list of principles.In addition, Stephen Reed proposed the creation of a Bitcoin branch as a sandboxed testbed for researching the best proof-of-stake implementations. He conducted a poll on Bitcointalk, which showed some minority support for Bitcoin proof-of-stake. Reed's goal is to develop, test, and document proof-of-stake while exploring vulnerabilities and fixing them transparently. He suggests calling the project 'bitstake' to differentiate it from Bitcoin.Lastly, Gmail has been spamfoldering emails from Yahoo due to DMARC enforcement, making it incompatible with Sourceforge mailing lists. Two solutions are suggested: not using Yahoo or stopping the use of Sourceforge mailing list software. There is also a discussion about the compatibility of alternate decentralized consensus algorithms with the sidechain/two-way peg system in Bitcoin. The author suggests that if alternate consensus algorithms cannot retain compatibility, altcoin experiments with different proof models may have limited interoperability as sidechains. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Proposal-for-extra-nonce-in-block-header.xml b/static/bitcoin-dev/April_2014/combined_Proposal-for-extra-nonce-in-block-header.xml index 97f4b25cc5..37d2b2c5f1 100644 --- a/static/bitcoin-dev/April_2014/combined_Proposal-for-extra-nonce-in-block-header.xml +++ b/static/bitcoin-dev/April_2014/combined_Proposal-for-extra-nonce-in-block-header.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal for extra nonce in block header - 2023-08-01T09:05:29.704021+00:00 + 2025-10-11T21:36:45.673698+00:00 + python-feedgen Timo Hanke 2014-10-18 18:25:59+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Proposal for extra nonce in block header - 2023-08-01T09:05:29.705063+00:00 + 2025-10-11T21:36:45.673957+00:00 - In 2014, Timo Hanke proposed a Bitcoin Improvement Proposal (BIP) to address the issue of miners finding cheap and non-standard ways to generate new work in the Bitcoin protocol. The proposal suggests reassigning two bytes from the version field of the block header to a new extra nonce field. This would allow miners to create new work without altering the transaction tree while protecting the version and timestamp fields in the block header.Currently, the extra nonce is part of the coinbase field of the generation transaction, which is always the first transaction of a block. By incrementing the extra nonce, a miner has to hash the coinbase transaction and recalculate the left-most branch of the merkle tree all the way to the merkle root. However, as the cost of pre-hashing decreases with the advancement of ASIC technology, miners are incentivized to find cheaper ways to create new work.The proposal suggests reducing the range of version numbers from 2^32 to 2^16 and designating the third and fourth bytes of the block header as legitimate space for an extra nonce. This would significantly reduce the incentive for miners to abuse the shortened version number. Additionally, this change would greatly reduce the bandwidth requirements of a blind pool protocol, as only the block header would need to be submitted to the miner.Old versions of the client will still accept blocks with the new extra nonce arrangement but will alert the user to upgrade. There is no need to introduce a new block version number or phase out old block versions. Overall, this proposal aims to provide miners with a cost-effective method of creating new work while maintaining the integrity of the Bitcoin protocol. 2014-10-18T18:25:59+00:00 + In 2014, Timo Hanke proposed a Bitcoin Improvement Proposal (BIP) to address the issue of miners finding cheap and non-standard ways to generate new work in the Bitcoin protocol. The proposal suggests reassigning two bytes from the version field of the block header to a new extra nonce field. This would allow miners to create new work without altering the transaction tree while protecting the version and timestamp fields in the block header.Currently, the extra nonce is part of the coinbase field of the generation transaction, which is always the first transaction of a block. By incrementing the extra nonce, a miner has to hash the coinbase transaction and recalculate the left-most branch of the merkle tree all the way to the merkle root. However, as the cost of pre-hashing decreases with the advancement of ASIC technology, miners are incentivized to find cheaper ways to create new work.The proposal suggests reducing the range of version numbers from 2^32 to 2^16 and designating the third and fourth bytes of the block header as legitimate space for an extra nonce. This would significantly reduce the incentive for miners to abuse the shortened version number. Additionally, this change would greatly reduce the bandwidth requirements of a blind pool protocol, as only the block header would need to be submitted to the miner.Old versions of the client will still accept blocks with the new extra nonce arrangement but will alert the user to upgrade. There is no need to introduce a new block version number or phase out old block versions. Overall, this proposal aims to provide miners with a cost-effective method of creating new work while maintaining the integrity of the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Proposal-to-change-payment-protocol-signing.xml b/static/bitcoin-dev/April_2014/combined_Proposal-to-change-payment-protocol-signing.xml index 22911957c2..f99f06470f 100644 --- a/static/bitcoin-dev/April_2014/combined_Proposal-to-change-payment-protocol-signing.xml +++ b/static/bitcoin-dev/April_2014/combined_Proposal-to-change-payment-protocol-signing.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal to change payment protocol signing - 2023-08-01T09:08:36.116319+00:00 + 2025-10-11T21:36:22.297197+00:00 + python-feedgen Gavin 2014-04-29 19:12:49+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Proposal to change payment protocol signing - 2023-08-01T09:08:36.116319+00:00 + 2025-10-11T21:36:22.297412+00:00 - Gavin Andresen, a core Bitcoin developer, initiated a discussion regarding the clarification of how BIP70 signs payment requests. The issue was about the signature field before signing, and Andresen suggested that instead of setting the signature to an empty string, it should be cleared so that it is not serialized at all. He said that this type of mistake is why BIPs take a while before being declared 'Final.'BIP70 is already in use with over a hundred paid requests, but Andresen believes that changes need to be made now, while it is still a 'Draft.' The email also includes a link to a free automated cross-browser testing platform.In an email exchange discussing the Bitcoin Improvement Proposal (BIP) 70, Mike Hearn argues that changing the signature field now would be too difficult and cause chaos for early adopters. He suggests that setting the signature field to an empty byte array is fine, as the payment protocol is already being implemented by various wallets and companies such as BitPay and Coinbase. Ryan X. Charles, a software engineer at BitPay, is included in the email thread. The email ends with a promotional message for automated cross-browser testing.The argument is about the implementation of the payment protocol in several wallets, including BitPay and Coinbase. The author argues that setting an empty byte array is fine and changing such a basic thing at this point would cause chaos for early adopters, punishing them instead of rewarding them. They believe that accepting BIP 70 and moving on would be the best course of action. The adoption of the payment protocol is seen as vulnerable at this stage and any changes could seriously hurt it.Gavin Andresen, a developer of Bitcoin Improvement Proposals (BIPs), has called for clarification on how to sign payment requests in BIP70. There is currently a discussion on Github regarding the issue of what to do with the signature field before signing. The current code sets the signature to an empty string, but Andresen believes this is a mistake and should instead clear the signature field so that it is not serialized at all. Andresen is seeking input from those who have implemented the payment protocol in order to change the spec and reference implementation while BIP70 is still in draft status. He notes that this type of mistake is why BIPs take time before being declared as "Final." 2014-04-29T19:12:49+00:00 + Gavin Andresen, a core Bitcoin developer, initiated a discussion regarding the clarification of how BIP70 signs payment requests. The issue was about the signature field before signing, and Andresen suggested that instead of setting the signature to an empty string, it should be cleared so that it is not serialized at all. He said that this type of mistake is why BIPs take a while before being declared 'Final.'BIP70 is already in use with over a hundred paid requests, but Andresen believes that changes need to be made now, while it is still a 'Draft.' The email also includes a link to a free automated cross-browser testing platform.In an email exchange discussing the Bitcoin Improvement Proposal (BIP) 70, Mike Hearn argues that changing the signature field now would be too difficult and cause chaos for early adopters. He suggests that setting the signature field to an empty byte array is fine, as the payment protocol is already being implemented by various wallets and companies such as BitPay and Coinbase. Ryan X. Charles, a software engineer at BitPay, is included in the email thread. The email ends with a promotional message for automated cross-browser testing.The argument is about the implementation of the payment protocol in several wallets, including BitPay and Coinbase. The author argues that setting an empty byte array is fine and changing such a basic thing at this point would cause chaos for early adopters, punishing them instead of rewarding them. They believe that accepting BIP 70 and moving on would be the best course of action. The adoption of the payment protocol is seen as vulnerable at this stage and any changes could seriously hurt it.Gavin Andresen, a developer of Bitcoin Improvement Proposals (BIPs), has called for clarification on how to sign payment requests in BIP70. There is currently a discussion on Github regarding the issue of what to do with the signature field before signing. The current code sets the signature to an empty string, but Andresen believes this is a mistake and should instead clear the signature field so that it is not serialized at all. Andresen is seeking input from those who have implemented the payment protocol in order to change the spec and reference implementation while BIP70 is still in draft status. He notes that this type of mistake is why BIPs take time before being declared as "Final." - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_SmartSPV-A-better-Simplified-Payment-Verification-for-Smartphones.xml b/static/bitcoin-dev/April_2014/combined_SmartSPV-A-better-Simplified-Payment-Verification-for-Smartphones.xml index 5be8f026ae..7426e6bcc2 100644 --- a/static/bitcoin-dev/April_2014/combined_SmartSPV-A-better-Simplified-Payment-Verification-for-Smartphones.xml +++ b/static/bitcoin-dev/April_2014/combined_SmartSPV-A-better-Simplified-Payment-Verification-for-Smartphones.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SmartSPV – A better Simplified Payment Verification for Smartphones - 2023-08-01T08:59:38.707667+00:00 + 2025-10-11T21:36:11.679905+00:00 + python-feedgen Gregory Maxwell 2014-04-25 04:59:39+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - SmartSPV – A better Simplified Payment Verification for Smartphones - 2023-08-01T08:59:38.708660+00:00 + 2025-10-11T21:36:11.680060+00:00 - In an email conversation between Sergio Lerner and Mike Hearn, the issue of handling 17K block headers a day in NimbleCoin currency's SPV mode was discussed. Lerner proposed a variation of the standard headers-only SPV mode called SmartSPV, which he believes could also be implemented by BitcoinJ for Bitcoin. This variation allows a smartphone to maintain a fairly accurate state of the wallet balance without downloading all the missing headers, while also conserving battery life and time.Lerner explained that with the freedom to specify and control the headers, SPV evaluations of work can have log(n) scaling. He provided a link to a mail archive discussion where this concept was further explained. Additionally, to address the issue of headers in reverse, Lerner referred to a wiki page on reverse header-fetching sync authored by Gmaxwell. This page offers ideas and insights on how to handle header syncing more efficiently.NimbleCoin is a new cryptocurrency that utilizes the FastBlock5 protocol to achieve near-instant payments. Due to merged mining, each block header can be as large as 700 bytes. However, when bandwidth is limited or clients are disconnected from the internet for extended periods, SmartSPV becomes crucial. In Smart-SPV mode, if a client is missing block headers, two actions occur simultaneously: the client starts downloading block headers from the last one solved backward, and it also begins downloading the block headers from the first missing header forward. While catching up with the missing blocks, the wallet balance may not be entirely reliable. However, any new confirmed payment received or made will increase and reflect the balance.The concept of live blocks and live transactions is introduced in this context. A live block is flagged as "LIVE" and this flag is permanently stored with the block. A live transaction refers to a transaction included in a live block. When a live transaction is confirmed by six blocks flagged as "LIVE," it is considered mature. All mature transactions, including those in blocks rooted at the last checkpoint and finishing in the last live block, are scanned and used to compute the wallet balance.Despite potential orphaned branches, the wallet acknowledges and processes payments correctly because it always modifies the balance according to mature transactions. As long as the SPV client clock is accurately synchronized, the Smart-SPV protocol does not pose any additional security risks beyond the known limitations of SPV. 2014-04-25T04:59:39+00:00 + In an email conversation between Sergio Lerner and Mike Hearn, the issue of handling 17K block headers a day in NimbleCoin currency's SPV mode was discussed. Lerner proposed a variation of the standard headers-only SPV mode called SmartSPV, which he believes could also be implemented by BitcoinJ for Bitcoin. This variation allows a smartphone to maintain a fairly accurate state of the wallet balance without downloading all the missing headers, while also conserving battery life and time.Lerner explained that with the freedom to specify and control the headers, SPV evaluations of work can have log(n) scaling. He provided a link to a mail archive discussion where this concept was further explained. Additionally, to address the issue of headers in reverse, Lerner referred to a wiki page on reverse header-fetching sync authored by Gmaxwell. This page offers ideas and insights on how to handle header syncing more efficiently.NimbleCoin is a new cryptocurrency that utilizes the FastBlock5 protocol to achieve near-instant payments. Due to merged mining, each block header can be as large as 700 bytes. However, when bandwidth is limited or clients are disconnected from the internet for extended periods, SmartSPV becomes crucial. In Smart-SPV mode, if a client is missing block headers, two actions occur simultaneously: the client starts downloading block headers from the last one solved backward, and it also begins downloading the block headers from the first missing header forward. While catching up with the missing blocks, the wallet balance may not be entirely reliable. However, any new confirmed payment received or made will increase and reflect the balance.The concept of live blocks and live transactions is introduced in this context. A live block is flagged as "LIVE" and this flag is permanently stored with the block. A live transaction refers to a transaction included in a live block. When a live transaction is confirmed by six blocks flagged as "LIVE," it is considered mature. All mature transactions, including those in blocks rooted at the last checkpoint and finishing in the last live block, are scanned and used to compute the wallet balance.Despite potential orphaned branches, the wallet acknowledges and processes payments correctly because it always modifies the balance according to mature transactions. As long as the SPV client clock is accurately synchronized, the Smart-SPV protocol does not pose any additional security risks beyond the known limitations of SPV. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Standardizing-OP-RETURN-message-format.xml b/static/bitcoin-dev/April_2014/combined_Standardizing-OP-RETURN-message-format.xml index 20aa33602d..e9ab7d09e7 100644 --- a/static/bitcoin-dev/April_2014/combined_Standardizing-OP-RETURN-message-format.xml +++ b/static/bitcoin-dev/April_2014/combined_Standardizing-OP-RETURN-message-format.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Standardizing OP_RETURN message format - 2023-08-01T08:34:22.081585+00:00 + 2025-10-11T21:36:18.051086+00:00 + python-feedgen Peter Todd 2014-04-06 10:37:32+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Standardizing OP_RETURN message format - 2023-08-01T08:34:22.081585+00:00 + 2025-10-11T21:36:18.051258+00:00 - Maciej Trebacz has proposed a process called BIP (Bitcoin Improvement Proposal) to standardize OP_RETURN transactions in order to enhance interoperability between services. The aim is to create a common, extensible protocol that can be utilized by anyone. The suggested generic format for these transactions would consist of OP_RETURN OP_PUSHDATA[length] {2-byte message type} {data}. The author also proposes a list of message types that can be parsed by everyone, ensuring openness. However, caution is advised against making it easy for third parties to determine the purpose of OP_RETURN messages, as this could potentially lead to censorship. It is also noted that it may be necessary to consider alternative options to OP_RETURN, as its future form is uncertain.In an email conversation dated April 6th, 2014, Maciej Trebacz discusses a method for destroying coins through a Proof of Burn transaction. This involves sending all the coins as fees to miners, effectively removing them from circulation. However, the author points out that for those who only require a dummy output for an all fee transaction, there is no need for a PUSH at all.The author's main proposal is to establish standardized OP_RETURN transactions by creating a common and extensible protocol that can be adopted by anyone. Currently, there are no specific guidelines for crafting these transactions, resulting in each individual implementing their own approach. By introducing a standard format with a list of message types that can be universally parsed, the author aims to address this issue. The success of such a standard relies on it being an open format, hence the suggestion for it to be incorporated into a BIP. Furthermore, the author expresses interest in contributing additional ideas for these types of messages and seeks clarification on whether they can be included with other BIPs if they are written. 2014-04-06T10:37:32+00:00 + Maciej Trebacz has proposed a process called BIP (Bitcoin Improvement Proposal) to standardize OP_RETURN transactions in order to enhance interoperability between services. The aim is to create a common, extensible protocol that can be utilized by anyone. The suggested generic format for these transactions would consist of OP_RETURN OP_PUSHDATA[length] {2-byte message type} {data}. The author also proposes a list of message types that can be parsed by everyone, ensuring openness. However, caution is advised against making it easy for third parties to determine the purpose of OP_RETURN messages, as this could potentially lead to censorship. It is also noted that it may be necessary to consider alternative options to OP_RETURN, as its future form is uncertain.In an email conversation dated April 6th, 2014, Maciej Trebacz discusses a method for destroying coins through a Proof of Burn transaction. This involves sending all the coins as fees to miners, effectively removing them from circulation. However, the author points out that for those who only require a dummy output for an all fee transaction, there is no need for a PUSH at all.The author's main proposal is to establish standardized OP_RETURN transactions by creating a common and extensible protocol that can be adopted by anyone. Currently, there are no specific guidelines for crafting these transactions, resulting in each individual implementing their own approach. By introducing a standard format with a list of message types that can be universally parsed, the author aims to address this issue. The success of such a standard relies on it being an open format, hence the suggestion for it to be incorporated into a BIP. Furthermore, the author expresses interest in contributing additional ideas for these types of messages and seeks clarification on whether they can be included with other BIPs if they are written. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Timed-testing.xml b/static/bitcoin-dev/April_2014/combined_Timed-testing.xml index 9b408361ea..2df69fec04 100644 --- a/static/bitcoin-dev/April_2014/combined_Timed-testing.xml +++ b/static/bitcoin-dev/April_2014/combined_Timed-testing.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Timed testing - 2023-08-01T08:47:56.434738+00:00 + 2025-10-11T21:36:09.555803+00:00 + python-feedgen Jorge Timón 2014-04-17 17:43:35+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Timed testing - 2023-08-01T08:47:56.434738+00:00 + 2025-10-11T21:36:09.555986+00:00 - The author of the email expresses gratitude for the explanations provided on using regtest to reproduce example scenarios. They decide that a private mode would not be useful for testing and will work on private chains separately from bitcoind without creating a pull request. The author brings up Sipa's complaints about regtest being too specific and suggests that some behaviors should be specified as independent parameters instead of chainparams attributes. They propose implementing the blocktime parameter as an independent parameter without the need for a new mode.In an email exchange between Jorge Timón and Gavin Andresen, they discussed the implementation of a new mode in Bitcoind. Timón suggested that the private mode only makes sense if it's useful enough for network attack simulations, which is still an open question. Andresen responded by proposing that the same effect could be achieved with -regtest by controlling node connectivity. He provided a simulation method where two nodes are started, connected to each other, and mine a -regtest chain they both agree on. After restarting them so they're not connected, one node mines normally while the other simulates an attack. To simulate launching the attack, they are connected together again, and the two chains compete to see what happens.Running a private server involves various processes like listening to the p2p network for incoming transactions, validating them and organizing mempool, performing transaction selection, and relaying blocks to auditors. These processes are not tested in a reindex. However, a reindex can give an optimistic upper bound if one wants to measure validation performance. If someone wants to measure the number of peak tps that could be processed without taking block sides or network latency into account, they can simply reindex or replay the chain. This process has been done many times before according to Mike Hearn who asked this question on April 17th, 2014.In an email exchange on April 17th, 2014, Mike Hearn asked how to measure validation performance, specifically the number of peak transactions per second (TPS) that could be processed. It was suggested that reindexing and replaying the chain would provide an accurate measurement, which had been done many times before. The timedtest mode was considered unnecessary, except for the blocktime parameter defaulting to zero. ChainParams' bool MineBlocksOnDemand() may be refactored into a parameter, possibly genproclimit, allowing periodic block generation and generation on demand to use the same regtest mode. A new mode would only make sense if the -private mode is useful enough for network attack simulations. However, this remains an open question.To measure validation performance and get the number of peak TPS (transactions per second) without considering block sides or network latency, reindexing or replaying the chain can be done. This process has been carried out multiple times by others in the past.In a communication dated April 17, 2014, Gavin Andresen asked about the difference between running in -regtest mode and running in -timedtest mode, which generates a new block automatically every second instead of having to manually request one. The response was that there is no difference, and that perhaps the value in creating a new mode is not enough to justify it. However, the proposed -private mode could provide a way to simulate proof of work attacks. The author asks questions about simulating a pow race situation without actually doing any pow and how to measure validation performance to get the number of peak tps that can be processed without taking block size or network latency into account. The author wonders if anyone has tried these things before.Jorge Timón, a Bitcoin developer, has shared his implementation of a new testing mode that produces blocks periodically. The code is available on GitHub and can be used to run simulations with different mining policies and stress tests for performance bottlenecks. Timón aims to implement the concept of private chains described in Freimarkets for hardfork or double-spend attack simulations without calculating any pow, and he seeks feedback from Bitcoin developers on how invasive this would be to Bitcoin's source code. He believes that if done properly, it could result in more readable code.In a thread on the Bitcoin Development mailing list, Gavin Andresen questioned the validity of using the -regtest mode in Bitcoin nodes to generate blocks after a few seconds. He asked how this was different from just running in -regtest mode and requesting the nodes to create a block after a short period of time. The discussion revolved around the potential implications of this approach, with some suggesting that it could lead to reduced security and increased vulnerability to attacks. Others argued that it could be useful for testing purposes, but only if done carefully and with appropriate safeguards in place. Overall, the conversation highlighted the need for caution and careful consideration when experimenting with new approaches to Bitcoin development.A new testing mode for Bitcoin has been implemented which produces blocks periodically and can be accessed on GitHub. The testing mode is 2014-04-17T17:43:35+00:00 + The author of the email expresses gratitude for the explanations provided on using regtest to reproduce example scenarios. They decide that a private mode would not be useful for testing and will work on private chains separately from bitcoind without creating a pull request. The author brings up Sipa's complaints about regtest being too specific and suggests that some behaviors should be specified as independent parameters instead of chainparams attributes. They propose implementing the blocktime parameter as an independent parameter without the need for a new mode.In an email exchange between Jorge Timón and Gavin Andresen, they discussed the implementation of a new mode in Bitcoind. Timón suggested that the private mode only makes sense if it's useful enough for network attack simulations, which is still an open question. Andresen responded by proposing that the same effect could be achieved with -regtest by controlling node connectivity. He provided a simulation method where two nodes are started, connected to each other, and mine a -regtest chain they both agree on. After restarting them so they're not connected, one node mines normally while the other simulates an attack. To simulate launching the attack, they are connected together again, and the two chains compete to see what happens.Running a private server involves various processes like listening to the p2p network for incoming transactions, validating them and organizing mempool, performing transaction selection, and relaying blocks to auditors. These processes are not tested in a reindex. However, a reindex can give an optimistic upper bound if one wants to measure validation performance. If someone wants to measure the number of peak tps that could be processed without taking block sides or network latency into account, they can simply reindex or replay the chain. This process has been done many times before according to Mike Hearn who asked this question on April 17th, 2014.In an email exchange on April 17th, 2014, Mike Hearn asked how to measure validation performance, specifically the number of peak transactions per second (TPS) that could be processed. It was suggested that reindexing and replaying the chain would provide an accurate measurement, which had been done many times before. The timedtest mode was considered unnecessary, except for the blocktime parameter defaulting to zero. ChainParams' bool MineBlocksOnDemand() may be refactored into a parameter, possibly genproclimit, allowing periodic block generation and generation on demand to use the same regtest mode. A new mode would only make sense if the -private mode is useful enough for network attack simulations. However, this remains an open question.To measure validation performance and get the number of peak TPS (transactions per second) without considering block sides or network latency, reindexing or replaying the chain can be done. This process has been carried out multiple times by others in the past.In a communication dated April 17, 2014, Gavin Andresen asked about the difference between running in -regtest mode and running in -timedtest mode, which generates a new block automatically every second instead of having to manually request one. The response was that there is no difference, and that perhaps the value in creating a new mode is not enough to justify it. However, the proposed -private mode could provide a way to simulate proof of work attacks. The author asks questions about simulating a pow race situation without actually doing any pow and how to measure validation performance to get the number of peak tps that can be processed without taking block size or network latency into account. The author wonders if anyone has tried these things before.Jorge Timón, a Bitcoin developer, has shared his implementation of a new testing mode that produces blocks periodically. The code is available on GitHub and can be used to run simulations with different mining policies and stress tests for performance bottlenecks. Timón aims to implement the concept of private chains described in Freimarkets for hardfork or double-spend attack simulations without calculating any pow, and he seeks feedback from Bitcoin developers on how invasive this would be to Bitcoin's source code. He believes that if done properly, it could result in more readable code.In a thread on the Bitcoin Development mailing list, Gavin Andresen questioned the validity of using the -regtest mode in Bitcoin nodes to generate blocks after a few seconds. He asked how this was different from just running in -regtest mode and requesting the nodes to create a block after a short period of time. The discussion revolved around the potential implications of this approach, with some suggesting that it could lead to reduced security and increased vulnerability to attacks. Others argued that it could be useful for testing purposes, but only if done carefully and with appropriate safeguards in place. Overall, the conversation highlighted the need for caution and careful consideration when experimenting with new approaches to Bitcoin development.A new testing mode for Bitcoin has been implemented which produces blocks periodically and can be accessed on GitHub. The testing mode is - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Translators-Needed-for-Bitcoin-Core.xml b/static/bitcoin-dev/April_2014/combined_Translators-Needed-for-Bitcoin-Core.xml index dd40be6b7a..df20347e55 100644 --- a/static/bitcoin-dev/April_2014/combined_Translators-Needed-for-Bitcoin-Core.xml +++ b/static/bitcoin-dev/April_2014/combined_Translators-Needed-for-Bitcoin-Core.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Translators Needed for Bitcoin Core - 2023-08-01T08:57:32.656260+00:00 + 2025-10-11T21:36:54.186939+00:00 + python-feedgen Warren Togami Jr. 2014-05-11 06:32:18+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Translators Needed for Bitcoin Core - 2023-08-01T08:57:32.656260+00:00 + 2025-10-11T21:36:54.187086+00:00 - The Bitcoin project is looking for volunteers to help improve translations in multiple languages for the upcoming release of Bitcoin Core 0.9.2. Native non-English speakers are encouraged to join Transifex, a platform for collaborative translation, to clean up and refine the translations. These translations will not only be used for Bitcoin, but also for Litecoin. Volunteers can try out the nightly builds of Bitcoin Core as it progresses towards the 0.9.2 release, although it is advised not to use these builds for their production wallet. Additionally, volunteers should join the Translator mailing list to stay updated on when translations are needed for Bitcoin. They will also receive notifications if other Bitcoin Project materials in Transifex require translations, such as bitcoin.org.Even individuals who do not speak other languages can still contribute by directing others who are fluent in different languages to the translation page. This way, they can help ensure that the translations are accurate and comprehensive. The feature freeze for Bitcoin Core 0.9.2 is set for May 13th, 2014, so now is the perfect time for interested volunteers to get involved and make a difference in improving the language support for Bitcoin and Litecoin. 2014-05-11T06:32:18+00:00 + The Bitcoin project is looking for volunteers to help improve translations in multiple languages for the upcoming release of Bitcoin Core 0.9.2. Native non-English speakers are encouraged to join Transifex, a platform for collaborative translation, to clean up and refine the translations. These translations will not only be used for Bitcoin, but also for Litecoin. Volunteers can try out the nightly builds of Bitcoin Core as it progresses towards the 0.9.2 release, although it is advised not to use these builds for their production wallet. Additionally, volunteers should join the Translator mailing list to stay updated on when translations are needed for Bitcoin. They will also receive notifications if other Bitcoin Project materials in Transifex require translations, such as bitcoin.org.Even individuals who do not speak other languages can still contribute by directing others who are fluent in different languages to the translation page. This way, they can help ensure that the translations are accurate and comprehensive. The feature freeze for Bitcoin Core 0.9.2 is set for May 13th, 2014, so now is the perfect time for interested volunteers to get involved and make a difference in improving the language support for Bitcoin and Litecoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Tree-chains-preliminary-summary.xml b/static/bitcoin-dev/April_2014/combined_Tree-chains-preliminary-summary.xml index e53dfcd9d6..6e52a51539 100644 --- a/static/bitcoin-dev/April_2014/combined_Tree-chains-preliminary-summary.xml +++ b/static/bitcoin-dev/April_2014/combined_Tree-chains-preliminary-summary.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Tree-chains preliminary summary - 2023-08-01T08:01:59.097124+00:00 + 2025-10-11T21:35:58.926408+00:00 + python-feedgen Gregory Sanders 2014-08-03 17:23:07+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Tree-chains preliminary summary - 2023-08-01T08:01:59.097124+00:00 + 2025-10-11T21:35:58.926579+00:00 - In the Bitcoin community, discussions are taking place regarding the need to maintain a friendly and professional environment on the mailing list. Some members suggest implementing a moderation policy or negative reinforcement to discourage hostile behavior and promote collaboration and constructive discussions.One topic of conversation is scalability in the Bitcoin network. Peter Todd argues that Bitcoin doesn't scale effectively due to the bandwidth required to update the UTXO set, leading to scaling issues. On the other hand, Gavin Andresen disagrees and refers to Satoshi's original thoughts on scaling, envisioning a large number of mining nodes and lightweight SPV users. However, Todd points out that the low number of mining pools is due to miners finding it unfeasible to mine on their own. He proposes tree chains as a solution to decentralization and scalability.Merged mining is also discussed, with some expressing concerns about draining the pegging pool and potential attacks. However, others argue that merged mining can indirectly solve scalability problems. Additionally, there is a conversation about reducing dependence on miner validation through the use of ZK-SNARKS.Overall, these conversations highlight different perspectives within the Bitcoin community on topics such as scalability, decentralization, and the importance of maintaining a friendly and professional environment for technical discussions. There are ongoing debates and proposed solutions to address these issues, but further research and testing will be necessary to ensure the security and integrity of the network. 2014-08-03T17:23:07+00:00 + In the Bitcoin community, discussions are taking place regarding the need to maintain a friendly and professional environment on the mailing list. Some members suggest implementing a moderation policy or negative reinforcement to discourage hostile behavior and promote collaboration and constructive discussions.One topic of conversation is scalability in the Bitcoin network. Peter Todd argues that Bitcoin doesn't scale effectively due to the bandwidth required to update the UTXO set, leading to scaling issues. On the other hand, Gavin Andresen disagrees and refers to Satoshi's original thoughts on scaling, envisioning a large number of mining nodes and lightweight SPV users. However, Todd points out that the low number of mining pools is due to miners finding it unfeasible to mine on their own. He proposes tree chains as a solution to decentralization and scalability.Merged mining is also discussed, with some expressing concerns about draining the pegging pool and potential attacks. However, others argue that merged mining can indirectly solve scalability problems. Additionally, there is a conversation about reducing dependence on miner validation through the use of ZK-SNARKS.Overall, these conversations highlight different perspectives within the Bitcoin community on topics such as scalability, decentralization, and the importance of maintaining a friendly and professional environment for technical discussions. There are ongoing debates and proposed solutions to address these issues, but further research and testing will be necessary to ensure the security and integrity of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Ubuntu-LTS-Packaging-.xml b/static/bitcoin-dev/April_2014/combined_Ubuntu-LTS-Packaging-.xml index 436d62fbbe..b21ebb94f1 100644 --- a/static/bitcoin-dev/April_2014/combined_Ubuntu-LTS-Packaging-.xml +++ b/static/bitcoin-dev/April_2014/combined_Ubuntu-LTS-Packaging-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ubuntu LTS Packaging? - 2023-08-01T08:44:44.874562+00:00 + 2025-10-11T21:36:32.913915+00:00 + python-feedgen Oliver Egginger 2014-04-12 16:33:16+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Ubuntu LTS Packaging? - 2023-08-01T08:44:44.874562+00:00 + 2025-10-11T21:36:32.914074+00:00 - Oliver Egginger reached out to Matt Corallo on April 12th, 2014 regarding an issue with his dynamically-linked-to-openssl builds. Matt responded by stating that the version of 0.9.1 was up to date and did not change anything for these builds. Oliver apologized for the trouble and expressed gratitude for Matt's assistance.In an email exchange on the same day, Oliver inquired about updates regarding a LiveCD for hot/cold wallet management on Ubuntu LTS basis. He provided a link to the Bitcoin Launchpad page and mentioned that he decided to maintain his own repository for the project due to the need for timely updates, particularly for critical vulnerabilities. Luke clarified that the mailing list is for development purposes only and suggested that the latest relevant version for packaging is 0.9.0, which can be found in the PPA that Oliver linked.Oliver also inquired about any updates regarding Bitcoin and shared a link to the official website. Wladimir replied that the only alteration in version 0.9.1 was OpenSSL's dependency version used in the binary gitian builds. However, the PPA build is reliant on the operating system OpenSSL, so upgrading it should suffice.In summary, Oliver Egginger is developing a LiveCD for hot/cold wallet management based on Ubuntu LTS. He is looking for timely updates to address critical vulnerabilities. To do this, he has decided to maintain his own repository for the project. Oliver has shared a link to his project on Launchpad and is open to suggestions for better alternatives. 2014-04-12T16:33:16+00:00 + Oliver Egginger reached out to Matt Corallo on April 12th, 2014 regarding an issue with his dynamically-linked-to-openssl builds. Matt responded by stating that the version of 0.9.1 was up to date and did not change anything for these builds. Oliver apologized for the trouble and expressed gratitude for Matt's assistance.In an email exchange on the same day, Oliver inquired about updates regarding a LiveCD for hot/cold wallet management on Ubuntu LTS basis. He provided a link to the Bitcoin Launchpad page and mentioned that he decided to maintain his own repository for the project due to the need for timely updates, particularly for critical vulnerabilities. Luke clarified that the mailing list is for development purposes only and suggested that the latest relevant version for packaging is 0.9.0, which can be found in the PPA that Oliver linked.Oliver also inquired about any updates regarding Bitcoin and shared a link to the official website. Wladimir replied that the only alteration in version 0.9.1 was OpenSSL's dependency version used in the binary gitian builds. However, the PPA build is reliant on the operating system OpenSSL, so upgrading it should suffice.In summary, Oliver Egginger is developing a LiveCD for hot/cold wallet management based on Ubuntu LTS. He is looking for timely updates to address critical vulnerabilities. To do this, he has decided to maintain his own repository for the project. Oliver has shared a link to his project on Launchpad and is open to suggestions for better alternatives. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Update-alert-false-positives.xml b/static/bitcoin-dev/April_2014/combined_Update-alert-false-positives.xml index 12455a77d6..ebd2e1fbf8 100644 --- a/static/bitcoin-dev/April_2014/combined_Update-alert-false-positives.xml +++ b/static/bitcoin-dev/April_2014/combined_Update-alert-false-positives.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Update alert false positives - 2023-08-01T08:48:10.328502+00:00 + 2025-10-11T21:36:03.185512+00:00 + python-feedgen Jameson Lopp 2014-04-19 22:41:43+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Update alert false positives - 2023-08-01T08:48:10.328502+00:00 + 2025-10-11T21:36:03.185672+00:00 - Oliver Egginger reported that the bitcoin-qt alert system is causing unnecessary alerts on many systems, which can be frightening for normal users. The alert is related to the Heartbleed vulnerability in OpenSSL and is generated based on the client's version number. The issue seems to be specific to the Ubuntu bitcoin ppa, which is dynamically linked to OpenSSL, unlike the binaries available from bitcoin.org. This means that users with static linking are also being notified, even though they are not affected by the vulnerability. Patrick responded to the mailing list, explaining that there is currently no way to notify only users with dynamic linking without also notifying those with static linking. This limitation in the alert system is causing confusion and panic among users. Oliver suggested that if possible, the message should be turned off to prevent further false positives and harmful workarounds.Jameson added to the conversation, informing everyone that Matt has pushed out new builds to the Ubuntu PPA. This suggests that the issue should resolve itself shortly as the new builds will likely address the unnecessary alerts. The email thread concludes with two links provided for further information. The first link leads to a free guide called "Graph Databases" by O'Reilly Books, which could be useful for those interested in learning more about graph databases. The second link directs users to the Bitcoin-development mailing list on SourceForge, where they can find additional discussions and updates related to Bitcoin development. 2014-04-19T22:41:43+00:00 + Oliver Egginger reported that the bitcoin-qt alert system is causing unnecessary alerts on many systems, which can be frightening for normal users. The alert is related to the Heartbleed vulnerability in OpenSSL and is generated based on the client's version number. The issue seems to be specific to the Ubuntu bitcoin ppa, which is dynamically linked to OpenSSL, unlike the binaries available from bitcoin.org. This means that users with static linking are also being notified, even though they are not affected by the vulnerability. Patrick responded to the mailing list, explaining that there is currently no way to notify only users with dynamic linking without also notifying those with static linking. This limitation in the alert system is causing confusion and panic among users. Oliver suggested that if possible, the message should be turned off to prevent further false positives and harmful workarounds.Jameson added to the conversation, informing everyone that Matt has pushed out new builds to the Ubuntu PPA. This suggests that the issue should resolve itself shortly as the new builds will likely address the unnecessary alerts. The email thread concludes with two links provided for further information. The first link leads to a free guide called "Graph Databases" by O'Reilly Books, which could be useful for those interested in learning more about graph databases. The second link directs users to the Bitcoin-development mailing list on SourceForge, where they can find additional discussions and updates related to Bitcoin development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Warning-message-when-running-wallet-in-Windows-XP-or-drop-support-.xml b/static/bitcoin-dev/April_2014/combined_Warning-message-when-running-wallet-in-Windows-XP-or-drop-support-.xml index c063d07cc7..b9d932ca19 100644 --- a/static/bitcoin-dev/April_2014/combined_Warning-message-when-running-wallet-in-Windows-XP-or-drop-support-.xml +++ b/static/bitcoin-dev/April_2014/combined_Warning-message-when-running-wallet-in-Windows-XP-or-drop-support-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Warning message when running wallet in Windows XP (or drop support?) - 2023-08-01T08:46:25.988875+00:00 + 2025-10-11T21:35:46.182330+00:00 + python-feedgen Wladimir 2014-04-17 07:39:33+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Warning message when running wallet in Windows XP (or drop support?) - 2023-08-01T08:46:25.988875+00:00 + 2025-10-11T21:35:46.182536+00:00 - There were discussions within the Bitcoin community about the security and support of Windows XP as a platform for Bitcoin Core. It was noted that Windows XP was no longer considered secure enough, especially for internet banking and running Bitcoin wallets. Microsoft had ended support for XP, leaving it vulnerable to known remote root compromises and other threats.The discussion included suggestions for warning users about the risks of using an outdated operating system and implementing added security measures such as hardware security modules or multisig secured wallets. Some argued that it didn't make sense to support an OS platform that Microsoft no longer supported themselves. Others believed that it was safe to run Bitcoin Core as a full node on XP, but caution should be taken when using the wallet functionality.The discussion also raised concerns about potential warnings being seen as behavior modification tactics and comparisons were made to Apple's practices of invalidating accessories with software updates. Overall, the importance of security and careful consideration in the development of cryptocurrency technologies was emphasized.During a discussion among Bitcoin developers, the security of running Bitcoin wallets on Windows XP was raised as a concern. Microsoft had stopped providing security patches for XP, leaving it vulnerable to remote exploits. Even banks were warning customers against using XP for online banking due to its lack of security. The question arose whether Bitcoin wallet software should drop support for XP, potentially compromising the network's security. However, there was hesitation as many computers in China and Russia still used XP, and dropping support could result in a loss of nodes.In an email exchange, Kevin questioned the security of XP and mentioned a warning. It was confirmed that Windows XP is no longer maintained and should not be used to safeguard money. Microsoft had issued a warning on their website regarding the end of support for XP. A suggestion was made to have Bitcoin Core detect when running on XP and warn users about the associated risks.On the Bitcoin-development mailing list, Wladimir expressed concern about the security of running a Bitcoin wallet on XP. He noted that his bank warned against doing internet banking on XP and questioned whether it was safe to store wallet keys on the outdated operating system. The discussion revolved around whether to warn users and allow them to continue or redirect them to a message on bitcoin.org highlighting the dangers of using XP. Dropping XP support completely could lead to a decrease in nodes, particularly in countries like China and Russia where XP was still widely used. Other wallet software maintainers were also asked about their plans regarding XP support.In an email exchange between Melvin Carvalho and Wladimir, the issue of using XP with a Trezor hardware wallet was discussed. Wladimir stated that this was a rare case since security-conscious individuals who purchased a Trezor would not use XP. However, he acknowledged that malware could still compromise users even with a Trezor on an XP system. Wladimir proposed adding a warning message in the 0.9.2 release, urging users to upgrade to a more secure operating system like Windows 8.1. He also suggested dropping XP support entirely in the next major release, 0.10.0.In summary, the security of using Windows XP for online banking and Bitcoin wallet storage was questioned due to Microsoft's discontinuation of support. Suggestions were made to warn users about the risks or redirect them to a message on bitcoin.org. However, dropping XP support completely could result in a loss of nodes, especially in China and Russia. The decision to drop XP support was not finalized, and other wallet software maintainers were considering their options as well. 2014-04-17T07:39:33+00:00 + There were discussions within the Bitcoin community about the security and support of Windows XP as a platform for Bitcoin Core. It was noted that Windows XP was no longer considered secure enough, especially for internet banking and running Bitcoin wallets. Microsoft had ended support for XP, leaving it vulnerable to known remote root compromises and other threats.The discussion included suggestions for warning users about the risks of using an outdated operating system and implementing added security measures such as hardware security modules or multisig secured wallets. Some argued that it didn't make sense to support an OS platform that Microsoft no longer supported themselves. Others believed that it was safe to run Bitcoin Core as a full node on XP, but caution should be taken when using the wallet functionality.The discussion also raised concerns about potential warnings being seen as behavior modification tactics and comparisons were made to Apple's practices of invalidating accessories with software updates. Overall, the importance of security and careful consideration in the development of cryptocurrency technologies was emphasized.During a discussion among Bitcoin developers, the security of running Bitcoin wallets on Windows XP was raised as a concern. Microsoft had stopped providing security patches for XP, leaving it vulnerable to remote exploits. Even banks were warning customers against using XP for online banking due to its lack of security. The question arose whether Bitcoin wallet software should drop support for XP, potentially compromising the network's security. However, there was hesitation as many computers in China and Russia still used XP, and dropping support could result in a loss of nodes.In an email exchange, Kevin questioned the security of XP and mentioned a warning. It was confirmed that Windows XP is no longer maintained and should not be used to safeguard money. Microsoft had issued a warning on their website regarding the end of support for XP. A suggestion was made to have Bitcoin Core detect when running on XP and warn users about the associated risks.On the Bitcoin-development mailing list, Wladimir expressed concern about the security of running a Bitcoin wallet on XP. He noted that his bank warned against doing internet banking on XP and questioned whether it was safe to store wallet keys on the outdated operating system. The discussion revolved around whether to warn users and allow them to continue or redirect them to a message on bitcoin.org highlighting the dangers of using XP. Dropping XP support completely could lead to a decrease in nodes, particularly in countries like China and Russia where XP was still widely used. Other wallet software maintainers were also asked about their plans regarding XP support.In an email exchange between Melvin Carvalho and Wladimir, the issue of using XP with a Trezor hardware wallet was discussed. Wladimir stated that this was a rare case since security-conscious individuals who purchased a Trezor would not use XP. However, he acknowledged that malware could still compromise users even with a Trezor on an XP system. Wladimir proposed adding a warning message in the 0.9.2 release, urging users to upgrade to a more secure operating system like Windows 8.1. He also suggested dropping XP support entirely in the next major release, 0.10.0.In summary, the security of using Windows XP for online banking and Bitcoin wallet storage was questioned due to Microsoft's discontinuation of support. Suggestions were made to warn users about the risks or redirect them to a message on bitcoin.org. However, dropping XP support completely could result in a loss of nodes, especially in China and Russia. The decision to drop XP support was not finalized, and other wallet software maintainers were considering their options as well. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_Why-are-we-bleeding-nodes-.xml b/static/bitcoin-dev/April_2014/combined_Why-are-we-bleeding-nodes-.xml index 42bedff940..f0fc216613 100644 --- a/static/bitcoin-dev/April_2014/combined_Why-are-we-bleeding-nodes-.xml +++ b/static/bitcoin-dev/April_2014/combined_Why-are-we-bleeding-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why are we bleeding nodes? - 2023-08-01T08:36:54.156883+00:00 + 2025-10-11T21:36:01.050214+00:00 + python-feedgen Jeff Garzik 2014-05-20 20:22:27+00:00 @@ -283,13 +284,13 @@ - python-feedgen + 2 Combined summary - Why are we bleeding nodes? - 2023-08-01T08:36:54.158932+00:00 + 2025-10-11T21:36:01.050466+00:00 - The discussion revolved around the possibility of extending the Bitcoin protocol to support UDP transport. This would enable NAT traversal and allow more people to run effective nodes. Jeff Garzik, a Bitcoin core developer, had already spec'd out the UDP traversal of the P2P protocol and deemed it reasonable. Andy Alness, a software engineer at Coinbase, suggested reinventing TCP over UDP to handle blocks and large transactions. There was also discussion about the potential for a blockchain fork due to network split and how mining interests in China would make arrangements to circumvent the Great Firewall of China.In May 2014, China updated its firewall blocking Bitcoin sites and pools, leading to concerns about a possible blockchain fork. The discussion also covered the resource requirements and associated costs of running a full node for Bitcoin. Some users reported high bandwidth usage and costs, while others argued that the requirements were within the capabilities of casual users. There was also a discussion about simplifying Bitcoin wallets and making them more user-friendly, as well as improving block fetching capabilities for better performance.The email conversations and forum discussions highlighted various aspects of the Bitcoin network, including UDP transport, NAT traversal, blockchain forks, mining interests in China, resource requirements of running a node, wallet usability, multi-sig security, and block fetching capabilities. There were also suggestions to advertise node capabilities in a more fine-grained manner using service bits. Tamas Blummer expressed concerns about extreme load hot-spotting and resource usage caused by a binary archive bit for an archive node. He proposed extending the addr messages to indicate a range of blocks served and returning a bitmap of pruned/full blocks.The discussions also focused on the challenges of running a full node for Bitcoin, including the resource requirements of bandwidth and disk space. Implementations such as headers-first and chain pruning were suggested to reduce the load and storage consumption. Concerns were raised about the decreasing number of Bitcoin nodes and suggestions were made to gather data on why people were ceasing to run nodes. The importance of improving the user experience of running Bitcoin was emphasized, as well as the potential risks associated with third-party services. Overall, the discussions demonstrated ongoing efforts to address the scalability and usability challenges of the Bitcoin network. 2014-05-20T20:22:27+00:00 + The discussion revolved around the possibility of extending the Bitcoin protocol to support UDP transport. This would enable NAT traversal and allow more people to run effective nodes. Jeff Garzik, a Bitcoin core developer, had already spec'd out the UDP traversal of the P2P protocol and deemed it reasonable. Andy Alness, a software engineer at Coinbase, suggested reinventing TCP over UDP to handle blocks and large transactions. There was also discussion about the potential for a blockchain fork due to network split and how mining interests in China would make arrangements to circumvent the Great Firewall of China.In May 2014, China updated its firewall blocking Bitcoin sites and pools, leading to concerns about a possible blockchain fork. The discussion also covered the resource requirements and associated costs of running a full node for Bitcoin. Some users reported high bandwidth usage and costs, while others argued that the requirements were within the capabilities of casual users. There was also a discussion about simplifying Bitcoin wallets and making them more user-friendly, as well as improving block fetching capabilities for better performance.The email conversations and forum discussions highlighted various aspects of the Bitcoin network, including UDP transport, NAT traversal, blockchain forks, mining interests in China, resource requirements of running a node, wallet usability, multi-sig security, and block fetching capabilities. There were also suggestions to advertise node capabilities in a more fine-grained manner using service bits. Tamas Blummer expressed concerns about extreme load hot-spotting and resource usage caused by a binary archive bit for an archive node. He proposed extending the addr messages to indicate a range of blocks served and returning a bitmap of pruned/full blocks.The discussions also focused on the challenges of running a full node for Bitcoin, including the resource requirements of bandwidth and disk space. Implementations such as headers-first and chain pruning were suggested to reduce the load and storage consumption. Concerns were raised about the decreasing number of Bitcoin nodes and suggestions were made to gather data on why people were ceasing to run nodes. The importance of improving the user experience of running Bitcoin was emphasized, as well as the potential risks associated with third-party services. Overall, the discussions demonstrated ongoing efforts to address the scalability and usability challenges of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_have-there-been-complains-about-network-congestion-router-crashes-slow-internet-when-running-Bitcoin-nodes-.xml b/static/bitcoin-dev/April_2014/combined_have-there-been-complains-about-network-congestion-router-crashes-slow-internet-when-running-Bitcoin-nodes-.xml index bce82cffb4..57bd8eb0d3 100644 --- a/static/bitcoin-dev/April_2014/combined_have-there-been-complains-about-network-congestion-router-crashes-slow-internet-when-running-Bitcoin-nodes-.xml +++ b/static/bitcoin-dev/April_2014/combined_have-there-been-complains-about-network-congestion-router-crashes-slow-internet-when-running-Bitcoin-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - have there been complains about network congestion? (router crashes, slow internet when running Bitcoin nodes) - 2023-08-01T08:39:29.444017+00:00 + 2025-10-11T21:36:37.158562+00:00 + python-feedgen Angel Leon 2014-04-08 17:33:18+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - have there been complains about network congestion? (router crashes, slow internet when running Bitcoin nodes) - 2023-08-01T08:39:29.444017+00:00 + 2025-10-11T21:36:37.158730+00:00 - In a conversation about the possibility of having multiple network transports for Bitcoin, Wladimir van der Laan, the lead developer of Bitcoin Core, addresses concerns about the impact of high traffic on Bitcoin nodes. He assures that the default maximum amount of connections is 125, which should not be a problem for even cheap home routers. Furthermore, Bitcoin does not use UDP, so there are no issues with it. However, filling up a home DSL or cable modem's send buffer with outgoing data is possible and could cause delays in interactive traffic. Throttling to prevent this is planned but postponed until parallel block download is implemented. To improve network performance, Wladimir suggests starting with benchmarking and analysis to identify areas for improvement.The conversation also discusses the issues faced by the bittorrent community and how they were solved with uTP. These issues included home routers crashing or slowing down when their NAT pin-hole tables overflowed due to many TCP connections, as well as home DSL or cable modems experiencing delays in interactive traffic due to filled-up send buffers. The bittorrent community resolved these problems with uTP, which implements a congestion window algorithm for better performance. However, the conversation acknowledges the potential risks of introducing an own UDP network stack, such as inadvertent bugs or backdoors. It suggests that there can be multiple network transports for Bitcoin, encouraging someone to build an alternative transport protocol to gateway to and explore useful possibilities.Another aspect discussed is the issue of network performance. Matt Whitlock suggests that the real problem lies in people not knowing how to configure their routers correctly. He explains that Bitcoind only saturates the upstream link when transferring files using SCP because the router interprets the "maximize throughput" flag in the IP "type of service" field as meaning low priority, causing the SCP transfers to get stalled behind Bitcoind. Other activities like email, web browsing, instant messaging, and SSH do not experience degradation regardless of Bitcoind's activity. Matt proposes moving the packet queue from the cable modem to the router for intelligent decisions about packet priority and reordering to enhance network performance. He also argues that µTP reinvents the wheel with greater overhead in userspace, suggesting that proper quality of service (QoS) negates the need for it. The conversation emphasizes the importance of correctly configuring routers for optimal network performance.Overall, the author questions whether the traffic on a Bitcoin node will lead to problems for home routers and modems. They highlight issues like crashing or slowing down due to NAT pin-hole table overflow, UDP traffic, and filled-up send buffers causing delays in interactive traffic. The author suggests that these issues were successfully tackled by the bittorrent community with uTP, which utilizes a congestion window algorithm. Implementing uTP could potentially greatly improve the performance of the Bitcoin network. A link is provided for further information about uTP. 2014-04-08T17:33:18+00:00 + In a conversation about the possibility of having multiple network transports for Bitcoin, Wladimir van der Laan, the lead developer of Bitcoin Core, addresses concerns about the impact of high traffic on Bitcoin nodes. He assures that the default maximum amount of connections is 125, which should not be a problem for even cheap home routers. Furthermore, Bitcoin does not use UDP, so there are no issues with it. However, filling up a home DSL or cable modem's send buffer with outgoing data is possible and could cause delays in interactive traffic. Throttling to prevent this is planned but postponed until parallel block download is implemented. To improve network performance, Wladimir suggests starting with benchmarking and analysis to identify areas for improvement.The conversation also discusses the issues faced by the bittorrent community and how they were solved with uTP. These issues included home routers crashing or slowing down when their NAT pin-hole tables overflowed due to many TCP connections, as well as home DSL or cable modems experiencing delays in interactive traffic due to filled-up send buffers. The bittorrent community resolved these problems with uTP, which implements a congestion window algorithm for better performance. However, the conversation acknowledges the potential risks of introducing an own UDP network stack, such as inadvertent bugs or backdoors. It suggests that there can be multiple network transports for Bitcoin, encouraging someone to build an alternative transport protocol to gateway to and explore useful possibilities.Another aspect discussed is the issue of network performance. Matt Whitlock suggests that the real problem lies in people not knowing how to configure their routers correctly. He explains that Bitcoind only saturates the upstream link when transferring files using SCP because the router interprets the "maximize throughput" flag in the IP "type of service" field as meaning low priority, causing the SCP transfers to get stalled behind Bitcoind. Other activities like email, web browsing, instant messaging, and SSH do not experience degradation regardless of Bitcoind's activity. Matt proposes moving the packet queue from the cable modem to the router for intelligent decisions about packet priority and reordering to enhance network performance. He also argues that µTP reinvents the wheel with greater overhead in userspace, suggesting that proper quality of service (QoS) negates the need for it. The conversation emphasizes the importance of correctly configuring routers for optimal network performance.Overall, the author questions whether the traffic on a Bitcoin node will lead to problems for home routers and modems. They highlight issues like crashing or slowing down due to NAT pin-hole table overflow, UDP traffic, and filled-up send buffers causing delays in interactive traffic. The author suggests that these issues were successfully tackled by the bittorrent community with uTP, which utilizes a congestion window algorithm. Implementing uTP could potentially greatly improve the performance of the Bitcoin network. A link is provided for further information about uTP. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_mid-term-bitcoin-security-Re-Warning-message-when-running-wallet-in-Windows-XP-or-drop-support-.xml b/static/bitcoin-dev/April_2014/combined_mid-term-bitcoin-security-Re-Warning-message-when-running-wallet-in-Windows-XP-or-drop-support-.xml index 4da485295e..ec60e85980 100644 --- a/static/bitcoin-dev/April_2014/combined_mid-term-bitcoin-security-Re-Warning-message-when-running-wallet-in-Windows-XP-or-drop-support-.xml +++ b/static/bitcoin-dev/April_2014/combined_mid-term-bitcoin-security-Re-Warning-message-when-running-wallet-in-Windows-XP-or-drop-support-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - mid-term bitcoin security (Re: Warning message when running wallet in Windows XP (or drop support?)) - 2023-08-01T08:46:38.826225+00:00 + 2025-10-11T21:35:27.064199+00:00 + python-feedgen Justus Ranvier 2014-04-18 14:39:14+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - mid-term bitcoin security (Re: Warning message when running wallet in Windows XP (or drop support?)) - 2023-08-01T08:46:38.826225+00:00 + 2025-10-11T21:35:27.064362+00:00 - In an email exchange on April 16th, 2014, Adam Back proposed rebranding Bitcoin addresses as "invoice numbers" to prevent double payments. This suggestion was supported by Jeff Garzik, who pointed out that BitPay already uses similar language. The discussion then shifted towards the need for enhanced security measures, such as air-gaps and zero-trust ecosystems.The author of the email thread emphasized the importance of online privacy and encouraged the use of email encryption whenever possible. They also suggested several security measures, including real-time auditability, type 2/type 3 exchanges based on atomic-swap, trustless escrow, and mass production of trezors.Address substitution via an untrusted network/user and a weak site with 1 million lines of Swiss-cheese security app-store was identified as a potential issue. To address this, the author recommended address authentication using the Trust-On-First-Use (TOFU) approach. They proposed a simple native TOFU format, such as Alan Reiner's multiplier * base approach or the IBE address proposal.The discussion concluded with a debate about whether XP with a Trezor would work fine and the consideration of dropping XP support in the next major release. Overall, the email exchange covered various topics related to Bitcoin addresses, security measures, and the importance of online privacy. 2014-04-18T14:39:14+00:00 + In an email exchange on April 16th, 2014, Adam Back proposed rebranding Bitcoin addresses as "invoice numbers" to prevent double payments. This suggestion was supported by Jeff Garzik, who pointed out that BitPay already uses similar language. The discussion then shifted towards the need for enhanced security measures, such as air-gaps and zero-trust ecosystems.The author of the email thread emphasized the importance of online privacy and encouraged the use of email encryption whenever possible. They also suggested several security measures, including real-time auditability, type 2/type 3 exchanges based on atomic-swap, trustless escrow, and mass production of trezors.Address substitution via an untrusted network/user and a weak site with 1 million lines of Swiss-cheese security app-store was identified as a potential issue. To address this, the author recommended address authentication using the Trust-On-First-Use (TOFU) approach. They proposed a simple native TOFU format, such as Alan Reiner's multiplier * base approach or the IBE address proposal.The discussion concluded with a debate about whether XP with a Trezor would work fine and the consideration of dropping XP support in the next major release. Overall, the email exchange covered various topics related to Bitcoin addresses, security measures, and the importance of online privacy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_please-check-my-debug-log.xml b/static/bitcoin-dev/April_2014/combined_please-check-my-debug-log.xml index 3b374c2bee..728b9b1fab 100644 --- a/static/bitcoin-dev/April_2014/combined_please-check-my-debug-log.xml +++ b/static/bitcoin-dev/April_2014/combined_please-check-my-debug-log.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - please check my debug.log - 2023-08-01T09:08:54.869721+00:00 + 2025-10-11T21:36:28.666953+00:00 + python-feedgen Mike Hearn 2014-04-29 14:15:10+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - please check my debug.log - 2023-08-01T09:08:54.869721+00:00 + 2025-10-11T21:36:28.667112+00:00 - On April 29, 2014, Eugen Leitl set up some bitcoind nodes to assist the network and requested feedback on their performance. Leitl shared a debug.log from a node that had been running for a day and another that was recently restarted. Both logs revealed errors, warnings, and information about transactions and connections.The log from the node running for a day displayed various messages regarding transactions and peers. It also mentioned receiving traffic from bitcoinj clients when nodes were left active for extended periods. Additionally, the log included version numbers and the number of blocks associated with different clients, such as Satoshi:0.8.5, Satoshi:0.9.0, bitcoinseeder:0.01, Dain 0.0.1, and Snoopy:0.1.Furthermore, the log contained timestamps, sample numbers, and offsets, providing time data for each message received by the Bitcoin node. The nTimeOffset consistently showed +0 minutes across all cases.In the second log, which documented the process after restarting a node, details about loading blockchain data, wallet, and rescanning tasks were recorded. Similar to the first log, this log also showed messages about adding and connecting to peers, as well as receiving version messages from different clients.Notable IP addresses mentioned in the logs include 213.239.218.20:45277, 84.126.227.120:8333, and 91.66.153.44:8333. Various versions of Bitcoin were referenced, such as /Satoshi:0.8.6/, Dain 0.0.1, and /getaddr.bitnodes.io:0.1/.The log concluded with a message promoting automated cross-browser testing for Selenium tests and provided a link to sign up for free. Additionally, the email included information about the Bitcoin-development mailing list along with links for subscription and unsubscription.Overall, the logs provided insight into the functionality of the bitcoind nodes and their interactions with network peers. The author sought feedback on any issues or improvements based on the information provided in the logs. 2014-04-29T14:15:10+00:00 + On April 29, 2014, Eugen Leitl set up some bitcoind nodes to assist the network and requested feedback on their performance. Leitl shared a debug.log from a node that had been running for a day and another that was recently restarted. Both logs revealed errors, warnings, and information about transactions and connections.The log from the node running for a day displayed various messages regarding transactions and peers. It also mentioned receiving traffic from bitcoinj clients when nodes were left active for extended periods. Additionally, the log included version numbers and the number of blocks associated with different clients, such as Satoshi:0.8.5, Satoshi:0.9.0, bitcoinseeder:0.01, Dain 0.0.1, and Snoopy:0.1.Furthermore, the log contained timestamps, sample numbers, and offsets, providing time data for each message received by the Bitcoin node. The nTimeOffset consistently showed +0 minutes across all cases.In the second log, which documented the process after restarting a node, details about loading blockchain data, wallet, and rescanning tasks were recorded. Similar to the first log, this log also showed messages about adding and connecting to peers, as well as receiving version messages from different clients.Notable IP addresses mentioned in the logs include 213.239.218.20:45277, 84.126.227.120:8333, and 91.66.153.44:8333. Various versions of Bitcoin were referenced, such as /Satoshi:0.8.6/, Dain 0.0.1, and /getaddr.bitnodes.io:0.1/.The log concluded with a message promoting automated cross-browser testing for Selenium tests and provided a link to sign up for free. Additionally, the email included information about the Bitcoin-development mailing list along with links for subscription and unsubscription.Overall, the logs provided insight into the functionality of the bitcoind nodes and their interactions with network peers. The author sought feedback on any issues or improvements based on the information provided in the logs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_question-about-ProcessMessage-.xml b/static/bitcoin-dev/April_2014/combined_question-about-ProcessMessage-.xml index df71744526..f8fa381bf4 100644 --- a/static/bitcoin-dev/April_2014/combined_question-about-ProcessMessage-.xml +++ b/static/bitcoin-dev/April_2014/combined_question-about-ProcessMessage-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - question about ProcessMessage() - 2023-08-01T08:47:15.348586+00:00 + 2025-10-11T21:36:39.285390+00:00 + python-feedgen Matthieu Riou 2014-04-17 18:00:04+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - question about ProcessMessage() - 2023-08-01T08:47:15.348586+00:00 + 2025-10-11T21:36:39.285544+00:00 - The email thread revolves around a specific line of code in the main.cpp file on Github's Bitcoin repository. The initial inquiry seeks clarification about the purpose of a line that checks if 'vAddr.size()' is greater than an unknown quantity. In response, it is explained that this line flags a peer as having no more addresses to learn from. Furthermore, it is mentioned that a prior check ensures that peers sending more than 1000 addresses are disallowed to prevent flooding. Additionally, the email states that 'pfrom->fGetAddr' is only allowed when 'vAddr.size()==1000'.Moving on to the main.cpp file itself, there is a function called ProcessMessage(). Within this function, there exists a line of code that checks if the size of a vector called vAddr is equal to 1000. If the condition is met, the function will return. However, the question arises as to whether the variable pfrom->fGetAddr can be true only when the size of vAddr is 1000. Unfortunately, the answer to this question could not be found in the list archive.Consequently, it remains unclear what the purpose of pfrom->fGetAddr is and how it relates to the size of the vAddr vector. To obtain a definitive answer, it may be necessary to examine other parts of the code or seek input from other developers. Overall, there appears to be a concern regarding the behavior of the ProcessMessage() function and its interaction with the vAddr vector and the pfrom->fGetAddr variable. Further investigation is warranted to fully comprehend the issue at hand and find a suitable solution.To conclude the discussion, a link to a book about graph databases is shared. This resource may prove helpful in gaining a deeper understanding of the topic under consideration. 2014-04-17T18:00:04+00:00 + The email thread revolves around a specific line of code in the main.cpp file on Github's Bitcoin repository. The initial inquiry seeks clarification about the purpose of a line that checks if 'vAddr.size()' is greater than an unknown quantity. In response, it is explained that this line flags a peer as having no more addresses to learn from. Furthermore, it is mentioned that a prior check ensures that peers sending more than 1000 addresses are disallowed to prevent flooding. Additionally, the email states that 'pfrom->fGetAddr' is only allowed when 'vAddr.size()==1000'.Moving on to the main.cpp file itself, there is a function called ProcessMessage(). Within this function, there exists a line of code that checks if the size of a vector called vAddr is equal to 1000. If the condition is met, the function will return. However, the question arises as to whether the variable pfrom->fGetAddr can be true only when the size of vAddr is 1000. Unfortunately, the answer to this question could not be found in the list archive.Consequently, it remains unclear what the purpose of pfrom->fGetAddr is and how it relates to the size of the vAddr vector. To obtain a definitive answer, it may be necessary to examine other parts of the code or seek input from other developers. Overall, there appears to be a concern regarding the behavior of the ProcessMessage() function and its interaction with the vAddr vector and the pfrom->fGetAddr variable. Further investigation is warranted to fully comprehend the issue at hand and find a suitable solution.To conclude the discussion, a link to a book about graph databases is shared. This resource may prove helpful in gaining a deeper understanding of the topic under consideration. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2014/combined_secure-assigned-bitcoin-address-directory.xml b/static/bitcoin-dev/April_2014/combined_secure-assigned-bitcoin-address-directory.xml index 07eadc55cf..073575a8ab 100644 --- a/static/bitcoin-dev/April_2014/combined_secure-assigned-bitcoin-address-directory.xml +++ b/static/bitcoin-dev/April_2014/combined_secure-assigned-bitcoin-address-directory.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - secure assigned bitcoin address directory - 2023-08-01T08:30:54.658130+00:00 + 2025-10-11T21:35:31.308857+00:00 + python-feedgen Mike Hearn 2014-04-02 12:01:51+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - secure assigned bitcoin address directory - 2023-08-01T08:30:54.658130+00:00 + 2025-10-11T21:35:31.309045+00:00 - On the Bitcointalk forum, a discussion has emerged regarding the accessibility and verification of vanity addresses. Some users expressed an interest in making their vanity addresses easily accessible to others while also ensuring ownership verification. However, the current method of signing addresses and posting them on forums is deemed insecure.To address this concern, the possibility of utilizing PGP keyservers was raised. However, it was noted that this approach would only be suitable for single vanity addresses, limiting its effectiveness for multiple addresses.As a potential solution, the concept of webfinger was proposed. Webfinger would allow servers of businesses to confirm and validate ownership of specific addresses. This method holds promise for ensuring secure access and verification of vanity addresses.It remains uncertain if there are any existing plans or initiatives that specifically cater to this use case. The mention of BIP70, which involves Certificate Authorities, was made in relation to addressing this issue. However, it is unclear whether this solution fully resolves the problem at hand.Overall, the email thread showcased ongoing conversations and ideas among developers in the Bitcoin space, exploring various approaches to enhance security and improve the efficiency of Bitcoin transactions.For further information and insights on this topic, readers are encouraged to explore the provided links to the relevant discussions on the Bitcointalk forum. 2014-04-02T12:01:51+00:00 + On the Bitcointalk forum, a discussion has emerged regarding the accessibility and verification of vanity addresses. Some users expressed an interest in making their vanity addresses easily accessible to others while also ensuring ownership verification. However, the current method of signing addresses and posting them on forums is deemed insecure.To address this concern, the possibility of utilizing PGP keyservers was raised. However, it was noted that this approach would only be suitable for single vanity addresses, limiting its effectiveness for multiple addresses.As a potential solution, the concept of webfinger was proposed. Webfinger would allow servers of businesses to confirm and validate ownership of specific addresses. This method holds promise for ensuring secure access and verification of vanity addresses.It remains uncertain if there are any existing plans or initiatives that specifically cater to this use case. The mention of BIP70, which involves Certificate Authorities, was made in relation to addressing this issue. However, it is unclear whether this solution fully resolves the problem at hand.Overall, the email thread showcased ongoing conversations and ideas among developers in the Bitcoin space, exploring various approaches to enhance security and improve the efficiency of Bitcoin transactions.For further information and insights on this topic, readers are encouraged to explore the provided links to the relevant discussions on the Bitcointalk forum. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_-network-disruption-as-a-service-and-proof-of-local-storage.xml b/static/bitcoin-dev/April_2015/combined_-network-disruption-as-a-service-and-proof-of-local-storage.xml index a7cfb30dd5..564b85a134 100644 --- a/static/bitcoin-dev/April_2015/combined_-network-disruption-as-a-service-and-proof-of-local-storage.xml +++ b/static/bitcoin-dev/April_2015/combined_-network-disruption-as-a-service-and-proof-of-local-storage.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - "network disruption as a service" and proof of local storage - 2023-08-01T12:04:00.763556+00:00 + Combined summary - "network disruption as a service" and proof of local storage + 2025-10-11T22:11:31.161790+00:00 + python-feedgen Sergio Lerner 2015-04-01 02:34:56+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 - Combined summary - "network disruption as a service" and proof of local storage - 2023-08-01T12:04:00.763556+00:00 + Combined summary - "network disruption as a service" and proof of local storage + 2025-10-11T22:11:31.161903+00:00 - The protocol described in the given context aims to enable a node to prove to another peer that it is storing a local copy of a public file, such as the blockchain, without requiring additional resources. This is achieved through the use of asymmetric-time-encoding, which encodes the blockchain in a way that takes significantly more time to write than to read.There are two protocols proposed to prove local possession. The first protocol involves both the prover and verifier paying a small cost. In this protocol, the verifier sends a seed to the prover, who must respond with the hash of the decrypted blocks within a certain time limit. The second protocol requires the prover to pay a higher cost, while the verifier pays a negligible cost. In this case, the verifier chooses a seed and pre-computes the encrypted blocks derived from the seed using the prover's IP. The seed is then sent to the prover, who must respond with the hash of the encrypted blocks within a certain time limit.These protocols can be made available by the client under different states. New nodes are initially only allowed to request protocol 2, and once they have completed it, they are permitted to periodically perform protocol 1. It is also possible to restrict the challenge-response to a specific portion of the blockchain.One of the key advantages of this proposal over GMaxwell's proposal is that each peer only needs to build a single table, which represents the encrypted blockchain. This means that it could still be possible for a single peer to establish thousands of connections to the network. Additionally, Sergio's proposal allows for a larger time gap between a good peer and a malicious peer by selecting a larger p value. However, it is important to note that an attacker's IP can be easily detected, and measures can be taken to restrict the challenge-response to a specific portion of the blockchain.In the context of the Bitcoin network, the problem of pseudo-nodes is a significant concern. One potential solution to this issue is requiring each peer to demonstrate resource consumption before being allowed to connect to other peers. Gmaxwell proposed Proof of Storage as a solution, while Sergio introduced the protocol called "Proof of Local Storage." Unlike Gmaxwell's proposal, Proof of Local Storage does not require additional data storage and allows peers to prove that they are maintaining a full copy of the blockchain.Overall, the discussions revolve around finding ways to improve blockchain resiliency through proof of storage, ensuring more full nodes on the network, and detecting non-full nodes with less computation. The proposed protocols aim to provide a reliable mechanism for discerning a local copy's existence without imposing substantial encoding costs. 2015-04-01T02:34:56+00:00 + The protocol described in the given context aims to enable a node to prove to another peer that it is storing a local copy of a public file, such as the blockchain, without requiring additional resources. This is achieved through the use of asymmetric-time-encoding, which encodes the blockchain in a way that takes significantly more time to write than to read.There are two protocols proposed to prove local possession. The first protocol involves both the prover and verifier paying a small cost. In this protocol, the verifier sends a seed to the prover, who must respond with the hash of the decrypted blocks within a certain time limit. The second protocol requires the prover to pay a higher cost, while the verifier pays a negligible cost. In this case, the verifier chooses a seed and pre-computes the encrypted blocks derived from the seed using the prover's IP. The seed is then sent to the prover, who must respond with the hash of the encrypted blocks within a certain time limit.These protocols can be made available by the client under different states. New nodes are initially only allowed to request protocol 2, and once they have completed it, they are permitted to periodically perform protocol 1. It is also possible to restrict the challenge-response to a specific portion of the blockchain.One of the key advantages of this proposal over GMaxwell's proposal is that each peer only needs to build a single table, which represents the encrypted blockchain. This means that it could still be possible for a single peer to establish thousands of connections to the network. Additionally, Sergio's proposal allows for a larger time gap between a good peer and a malicious peer by selecting a larger p value. However, it is important to note that an attacker's IP can be easily detected, and measures can be taken to restrict the challenge-response to a specific portion of the blockchain.In the context of the Bitcoin network, the problem of pseudo-nodes is a significant concern. One potential solution to this issue is requiring each peer to demonstrate resource consumption before being allowed to connect to other peers. Gmaxwell proposed Proof of Storage as a solution, while Sergio introduced the protocol called "Proof of Local Storage." Unlike Gmaxwell's proposal, Proof of Local Storage does not require additional data storage and allows peers to prove that they are maintaining a full copy of the blockchain.Overall, the discussions revolve around finding ways to improve blockchain resiliency through proof of storage, ensuring more full nodes on the network, and detecting non-full nodes with less computation. The proposed protocols aim to provide a reliable mechanism for discerning a local copy's existence without imposing substantial encoding costs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_75-95-threshold-for-transaction-versions.xml b/static/bitcoin-dev/April_2015/combined_75-95-threshold-for-transaction-versions.xml index c037bff064..154ecf5381 100644 --- a/static/bitcoin-dev/April_2015/combined_75-95-threshold-for-transaction-versions.xml +++ b/static/bitcoin-dev/April_2015/combined_75-95-threshold-for-transaction-versions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 75%/95% threshold for transaction versions - 2023-08-01T12:15:01.226168+00:00 + 2025-10-11T22:11:41.789568+00:00 + python-feedgen Oleg Andreev 2015-04-28 10:17:27+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - 75%/95% threshold for transaction versions - 2023-08-01T12:15:01.227164+00:00 + 2025-10-11T22:11:41.789779+00:00 - In an email exchange between s7r and Pieter Wuille, the issue of transaction malleability in Bitcoin is discussed. S7r expresses his intention to build a Bitcoin contract that relies on non-malleable transactions through coinjoin, pre-signed transactions with nLockTime, and Pay-to-Script-Hash (P2SH). However, he is confused about who has the ability to alter a txid without invalidating the transaction and whether these three pieces of the Bitcoin protocol will be supported in future transaction or block versions.Pieter responds by asking s7r what problem he is trying to solve, pointing out that BIP62's approach to protecting v1 transactions from malleability would require changing every wallet software if v3 transactions were forced. S7r eventually acknowledges that his suggestion may complicate things and recognizes that there may be a valid reason why BIP62 does not touch v1 transactions.The email conversation also touches on the idea of adding a consensus rule for transaction versions in Bitcoin. The proposed rule would mark previous transaction versions as non-standard or invalid if a certain version appears in at least 75% or 95% of the latest 1000 blocks. Currently, there is no enforcement related to transaction versions in the network. BIP62 introduces a newer optional transaction version but does not deem previous v1 versions as non-standard or invalid. This means that bitcoin core treats both v1 and v2/v3 transactions as standard and relays/mines them with the same priority, regardless of the transaction version.The discussion further explores the possibility of skipping version 2 and directly transitioning to version 3 for transactions and blocks. The provided link leads to a Bitcoin StackExchange post regarding BIP62 and its implementation status. The author of the post proposes adding a consensus rule similar to the one for blocks to transaction versions. This rule would label previous transaction versions as non-standard or invalid if a certain version appears in more than 75% or 95% of transactions in the latest 1000 blocks. Currently, the consensus standard is v1 with no enforcement related to transaction versions. BIP62 requires v2 transactions but does not consider previous v1 transactions as non-standard or invalid. Bitcoin core treats both v1 and v2/v3 transactions as standard and relays/mines them with equal priority, regardless of the transaction version. The author poses the question of whether adding this proposed rule could cause any issues or affect functionality. Additionally, it is mentioned that BIP62 introduces a newer transaction version that directly jumps to v3, bypassing v2. 2015-04-28T10:17:27+00:00 + In an email exchange between s7r and Pieter Wuille, the issue of transaction malleability in Bitcoin is discussed. S7r expresses his intention to build a Bitcoin contract that relies on non-malleable transactions through coinjoin, pre-signed transactions with nLockTime, and Pay-to-Script-Hash (P2SH). However, he is confused about who has the ability to alter a txid without invalidating the transaction and whether these three pieces of the Bitcoin protocol will be supported in future transaction or block versions.Pieter responds by asking s7r what problem he is trying to solve, pointing out that BIP62's approach to protecting v1 transactions from malleability would require changing every wallet software if v3 transactions were forced. S7r eventually acknowledges that his suggestion may complicate things and recognizes that there may be a valid reason why BIP62 does not touch v1 transactions.The email conversation also touches on the idea of adding a consensus rule for transaction versions in Bitcoin. The proposed rule would mark previous transaction versions as non-standard or invalid if a certain version appears in at least 75% or 95% of the latest 1000 blocks. Currently, there is no enforcement related to transaction versions in the network. BIP62 introduces a newer optional transaction version but does not deem previous v1 versions as non-standard or invalid. This means that bitcoin core treats both v1 and v2/v3 transactions as standard and relays/mines them with the same priority, regardless of the transaction version.The discussion further explores the possibility of skipping version 2 and directly transitioning to version 3 for transactions and blocks. The provided link leads to a Bitcoin StackExchange post regarding BIP62 and its implementation status. The author of the post proposes adding a consensus rule similar to the one for blocks to transaction versions. This rule would label previous transaction versions as non-standard or invalid if a certain version appears in more than 75% or 95% of transactions in the latest 1000 blocks. Currently, the consensus standard is v1 with no enforcement related to transaction versions. BIP62 requires v2 transactions but does not consider previous v1 transactions as non-standard or invalid. Bitcoin core treats both v1 and v2/v3 transactions as standard and relays/mines them with equal priority, regardless of the transaction version. The author poses the question of whether adding this proposed rule could cause any issues or affect functionality. Additionally, it is mentioned that BIP62 introduces a newer transaction version that directly jumps to v3, bypassing v2. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Bitcoin-Core-0-10-1-release-candidate-2-available.xml b/static/bitcoin-dev/April_2015/combined_Bitcoin-Core-0-10-1-release-candidate-2-available.xml index d71fddc54d..6cbf3030cc 100644 --- a/static/bitcoin-dev/April_2015/combined_Bitcoin-Core-0-10-1-release-candidate-2-available.xml +++ b/static/bitcoin-dev/April_2015/combined_Bitcoin-Core-0-10-1-release-candidate-2-available.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.10.1 release candidate 2 available - 2023-08-01T12:13:42.768921+00:00 + 2025-10-11T22:11:43.912622+00:00 + python-feedgen Wladimir J. van der Laan 2015-05-14 09:18:26+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.10.1 release candidate 2 available - 2023-08-01T12:13:42.768921+00:00 + 2025-10-11T22:11:43.912758+00:00 - Bitcoin Core version 0.10.2rc1 binaries are now available for download from bitcoin.org. This release is a minor update that primarily addresses a bug affecting Windows users with non-ASCII characters in their data directory. Additionally, the release includes translation updates. Users who did not encounter any issues with the previous version, 0.10.1, do not need to upgrade.For those interested, preliminary release notes for version 0.10.2 can be found on Github under the signed tag. Release candidates like this one serve as test runs for new releases. If no critical problems are discovered, this release candidate will be tagged as version 0.10.2. Any bugs encountered should be reported using the issue tracker on Github.In related news, Bitcoin Core 0.10.1rc2 executables have been uploaded to bitcoin.org for testing purposes. The source code can be found in git under the tag 'v0.10.1rc2'. The sole change in this release candidate compared to rc1 is a fix by Gavin Andresen, which ensures consistent mempool behavior during block-reorganizations. Wladimir expressed gratitude to everyone who participated in the gitian build process. 2015-05-14T09:18:26+00:00 + Bitcoin Core version 0.10.2rc1 binaries are now available for download from bitcoin.org. This release is a minor update that primarily addresses a bug affecting Windows users with non-ASCII characters in their data directory. Additionally, the release includes translation updates. Users who did not encounter any issues with the previous version, 0.10.1, do not need to upgrade.For those interested, preliminary release notes for version 0.10.2 can be found on Github under the signed tag. Release candidates like this one serve as test runs for new releases. If no critical problems are discovered, this release candidate will be tagged as version 0.10.2. Any bugs encountered should be reported using the issue tracker on Github.In related news, Bitcoin Core 0.10.1rc2 executables have been uploaded to bitcoin.org for testing purposes. The source code can be found in git under the tag 'v0.10.1rc2'. The sole change in this release candidate compared to rc1 is a fix by Gavin Andresen, which ensures consistent mempool behavior during block-reorganizations. Wladimir expressed gratitude to everyone who participated in the gitian build process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Bitcoin-core-0-11-planning.xml b/static/bitcoin-dev/April_2015/combined_Bitcoin-core-0-11-planning.xml index 97b0e87258..15b2325436 100644 --- a/static/bitcoin-dev/April_2015/combined_Bitcoin-core-0-11-planning.xml +++ b/static/bitcoin-dev/April_2015/combined_Bitcoin-core-0-11-planning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin core 0.11 planning - 2023-08-01T12:19:46.279240+00:00 + 2025-10-11T22:11:50.296146+00:00 + python-feedgen Wladimir 2015-05-11 15:00:03+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Bitcoin core 0.11 planning - 2023-08-01T12:19:46.279240+00:00 + 2025-10-11T22:11:50.296280+00:00 - In an email dated April 28, 2015, Wladimir J. van der Laan proposed a schedule for the release of version 0.11 of Bitcoin Core. The proposed schedule includes a soft translation string freeze on May 1, opening Transifex translations for 0.11, and finalizing and closing translation for 0.9. The feature and string freeze is scheduled for May 15. On June 1, the plan is to split off the 0.11 branch, tag and release 0.11.0rc1, and start merging for 0.12 on the master branch. The target is to release 0.11.0 final on July 1. Unlike previous releases, the intention is to be more strict about the dates. However, it is acknowledged that last-minute critical issues may affect the planning. It is also stated that the release will not be held up for features, and anything that does not make it to 0.11 will be postponed to the next release scheduled for the end of the year.In another email, it is mentioned that the soonest implementation of CHECKLOCKTIMEVERIFY on Bitcoin will be around summer 2016. This feature has already been adopted on Viacoin and a few other altcoins. To accelerate the adoption of CHECKLOCKTIMEVERIFY, it is suggested to release a v0.12 with just a CLTV soft-fork as soon as the BIP66 softfork triggers. The main reason for accelerating CLTV is scalability, as it provides robust fixes for scalability issues. It is noted that payment channel schemes can start with Jeremy Spilman's scheme and later transition to CLTV, but this would require writing extra code that may later become deprecated.The proposed schedule for the release of version 0.11 has been shared with the community. The deadline for the soft translation string freeze, opening Transifex translations for 0.11, and finalizing and closing translation for 0.9 is set for May 1. The feature and string freeze will take place on May 15. On June 1, the plan is to split off the 0.11 branch, tag and release 0.11.0rc1, and start merging for 0.12 on the master branch. The aim is to release 0.11.0 final on July 1. While there is an intention to be more strict about the dates, it is acknowledged that last-minute critical issues could impact the planning. However, the release will not be delayed for features, and anything that does not make it to 0.11 will be postponed to the next release scheduled for the end of the year. 2015-05-11T15:00:03+00:00 + In an email dated April 28, 2015, Wladimir J. van der Laan proposed a schedule for the release of version 0.11 of Bitcoin Core. The proposed schedule includes a soft translation string freeze on May 1, opening Transifex translations for 0.11, and finalizing and closing translation for 0.9. The feature and string freeze is scheduled for May 15. On June 1, the plan is to split off the 0.11 branch, tag and release 0.11.0rc1, and start merging for 0.12 on the master branch. The target is to release 0.11.0 final on July 1. Unlike previous releases, the intention is to be more strict about the dates. However, it is acknowledged that last-minute critical issues may affect the planning. It is also stated that the release will not be held up for features, and anything that does not make it to 0.11 will be postponed to the next release scheduled for the end of the year.In another email, it is mentioned that the soonest implementation of CHECKLOCKTIMEVERIFY on Bitcoin will be around summer 2016. This feature has already been adopted on Viacoin and a few other altcoins. To accelerate the adoption of CHECKLOCKTIMEVERIFY, it is suggested to release a v0.12 with just a CLTV soft-fork as soon as the BIP66 softfork triggers. The main reason for accelerating CLTV is scalability, as it provides robust fixes for scalability issues. It is noted that payment channel schemes can start with Jeremy Spilman's scheme and later transition to CLTV, but this would require writing extra code that may later become deprecated.The proposed schedule for the release of version 0.11 has been shared with the community. The deadline for the soft translation string freeze, opening Transifex translations for 0.11, and finalizing and closing translation for 0.9 is set for May 1. The feature and string freeze will take place on May 15. On June 1, the plan is to split off the 0.11 branch, tag and release 0.11.0rc1, and start merging for 0.12 on the master branch. The aim is to release 0.11.0 final on July 1. While there is an intention to be more strict about the dates, it is acknowledged that last-minute critical issues could impact the planning. However, the release will not be delayed for features, and anything that does not make it to 0.11 will be postponed to the next release scheduled for the end of the year. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Build-your-own-nHashType.xml b/static/bitcoin-dev/April_2015/combined_Build-your-own-nHashType.xml index 398c6c2acd..ed458683a3 100644 --- a/static/bitcoin-dev/April_2015/combined_Build-your-own-nHashType.xml +++ b/static/bitcoin-dev/April_2015/combined_Build-your-own-nHashType.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Build your own nHashType - 2023-08-01T12:13:04.750429+00:00 + 2025-10-11T22:11:37.533842+00:00 + python-feedgen Peter Todd 2015-04-18 23:33:52+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Build your own nHashType - 2023-08-01T12:13:04.750429+00:00 + 2025-10-11T22:11:37.533994+00:00 - In a discussion on #bitcoin-wizards, Bitcoin Core developer Mike Hearn suggests using OP_CODESEPARATOR to implement efficient payword schemes. He also mentions that early on, this feature allowed for after-the-fact signing delegation. However, the feature was removed without thorough consideration. Satoshi believed in one implementation and put CODESEPARATOR into the scriptSig/scriptPubKey concatenation, making it necessary to opt-in for that feature's use. Without the mis-matched ENDIF, users cannot delegate signing authority after the fact. Stephen Morse proposes a change in nHashType to specify what is serialized for the signature hash, reducing malleability and allowing hardware wallets to sign securely without downloading or processing each transaction. Concerns are raised about creating too many options, leading to a choose-your-own-adventure scenario. The author suggests that eliminating txin txid enables covenants, which are payments that constrain future payments. There are discussions about auto-forwarding, with suggestions to reorder serialization to avoid bottlenecks and the use of CODESEPARATOR to sign code as part of verifying the signature. Jeff Garzik responds to a question about slow transaction verification speed, highlighting issues such as slower propagation, increased node workload, and opportunities for attacks. Peter Todd proposes mechanisms to improve CHECKSIG efficiency. The possibility of auto forwarding and replay attacks is debated, with suggestions to put previous scriptPubKey and output value at the end of serialized transactions. The bottleneck of hashing transaction data once per input is questioned for large transactions. An email exchange between Stephen Morse and Jeff Garzik discusses the potential issues of slow transaction verification speed and the bottleneck for mobile devices. Another conversation between Mike and Stephen explores changing sighash flags for Bitcoin transactions, addressing concerns about practicality, security, and the need to avoid unnecessary hashing. Finally, a proposal is made to allow transaction signers to specify what is serialized for the signature hash, aiming to make malleability a non-issue and enable secure signing for hardware wallets. The proposal can be found on Github, and feedback is welcome. 2015-04-18T23:33:52+00:00 + In a discussion on #bitcoin-wizards, Bitcoin Core developer Mike Hearn suggests using OP_CODESEPARATOR to implement efficient payword schemes. He also mentions that early on, this feature allowed for after-the-fact signing delegation. However, the feature was removed without thorough consideration. Satoshi believed in one implementation and put CODESEPARATOR into the scriptSig/scriptPubKey concatenation, making it necessary to opt-in for that feature's use. Without the mis-matched ENDIF, users cannot delegate signing authority after the fact. Stephen Morse proposes a change in nHashType to specify what is serialized for the signature hash, reducing malleability and allowing hardware wallets to sign securely without downloading or processing each transaction. Concerns are raised about creating too many options, leading to a choose-your-own-adventure scenario. The author suggests that eliminating txin txid enables covenants, which are payments that constrain future payments. There are discussions about auto-forwarding, with suggestions to reorder serialization to avoid bottlenecks and the use of CODESEPARATOR to sign code as part of verifying the signature. Jeff Garzik responds to a question about slow transaction verification speed, highlighting issues such as slower propagation, increased node workload, and opportunities for attacks. Peter Todd proposes mechanisms to improve CHECKSIG efficiency. The possibility of auto forwarding and replay attacks is debated, with suggestions to put previous scriptPubKey and output value at the end of serialized transactions. The bottleneck of hashing transaction data once per input is questioned for large transactions. An email exchange between Stephen Morse and Jeff Garzik discusses the potential issues of slow transaction verification speed and the bottleneck for mobile devices. Another conversation between Mike and Stephen explores changing sighash flags for Bitcoin transactions, addressing concerns about practicality, security, and the need to avoid unnecessary hashing. Finally, a proposal is made to allow transaction signers to specify what is serialized for the signature hash, aiming to make malleability a non-issue and enable secure signing for hardware wallets. The proposal can be found on Github, and feedback is welcome. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Deprecating-Bitcoin-Core-s-regtest-specific-setgenerate-behaviour.xml b/static/bitcoin-dev/April_2015/combined_Deprecating-Bitcoin-Core-s-regtest-specific-setgenerate-behaviour.xml index c5beef616d..aad462f9c0 100644 --- a/static/bitcoin-dev/April_2015/combined_Deprecating-Bitcoin-Core-s-regtest-specific-setgenerate-behaviour.xml +++ b/static/bitcoin-dev/April_2015/combined_Deprecating-Bitcoin-Core-s-regtest-specific-setgenerate-behaviour.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Deprecating Bitcoin Core's regtest-specific `setgenerate` behaviour - 2023-08-01T12:14:08.814579+00:00 + 2025-10-11T22:11:48.171696+00:00 + python-feedgen Sean Gilligan 2015-04-12 22:36:12+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Deprecating Bitcoin Core's regtest-specific `setgenerate` behaviour - 2023-08-01T12:14:08.814579+00:00 + 2025-10-11T22:11:48.171849+00:00 - Pieter Wuille, a developer at Bitcoin Core, has recently announced that the special meaning of the `setgenerate` RPC call for -regtest will be deprecated and replaced with a separate RPC call called `generate`. This decision comes as part of an effort by Bitcoin Core developers to make improvements and updates to the software.The change is not expected to affect any production functionality and the developers are known for being conservative when it comes to altering RPC behavior. However, they are open to understanding if there are any software or users who require compatibility with the old behavior before proceeding with the switch.In light of this announcement, the bitcoin.org developer documentation will need to be revised and updated to reflect the upcoming change. This is important to ensure that users and developers have accurate and up-to-date information about the RPC calls and their functionalities.Sean, a Java RPC client and Groovy/Spock functional tests writer, supports the idea of introducing a separate `generate` or `generateblocks` call. However, he points out that in order to maintain compatibility with both the current stable and unstable versions of Bitcoin Core, as well as the Omni Core fork, additional code will need to be written to check the RPC server version.Overall, the deprecation of the `setgenerate` RPC call's special meaning for -regtest and its replacement with a separate RPC call `generate` marks a significant change in the Bitcoin Core software. Developers are seeking feedback from users and software providers to ensure a smooth transition while keeping compatibility in mind. The bitcoin.org developer documentation will be updated accordingly to reflect these changes and provide accurate guidance to the community. 2015-04-12T22:36:12+00:00 + Pieter Wuille, a developer at Bitcoin Core, has recently announced that the special meaning of the `setgenerate` RPC call for -regtest will be deprecated and replaced with a separate RPC call called `generate`. This decision comes as part of an effort by Bitcoin Core developers to make improvements and updates to the software.The change is not expected to affect any production functionality and the developers are known for being conservative when it comes to altering RPC behavior. However, they are open to understanding if there are any software or users who require compatibility with the old behavior before proceeding with the switch.In light of this announcement, the bitcoin.org developer documentation will need to be revised and updated to reflect the upcoming change. This is important to ensure that users and developers have accurate and up-to-date information about the RPC calls and their functionalities.Sean, a Java RPC client and Groovy/Spock functional tests writer, supports the idea of introducing a separate `generate` or `generateblocks` call. However, he points out that in order to maintain compatibility with both the current stable and unstable versions of Bitcoin Core, as well as the Omni Core fork, additional code will need to be written to check the RPC server version.Overall, the deprecation of the `setgenerate` RPC call's special meaning for -regtest and its replacement with a separate RPC call `generate` marks a significant change in the Bitcoin Core software. Developers are seeking feedback from users and software providers to ensure a smooth transition while keeping compatibility in mind. The bitcoin.org developer documentation will be updated accordingly to reflect these changes and provide accurate guidance to the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_DevCore-London.xml b/static/bitcoin-dev/April_2015/combined_DevCore-London.xml index fc81355c7a..5ff780accc 100644 --- a/static/bitcoin-dev/April_2015/combined_DevCore-London.xml +++ b/static/bitcoin-dev/April_2015/combined_DevCore-London.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DevCore London - 2023-08-01T12:13:17.868828+00:00 + 2025-10-11T22:11:56.667598+00:00 + python-feedgen Mike Hearn 2015-06-02 14:20:47+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - DevCore London - 2023-08-01T12:13:17.868828+00:00 + 2025-10-11T22:11:56.667748+00:00 - Former Bitcoin developer Mike Hearn has made his tutorial talk from DevCore 2015 available on the website. The tutorial provides detailed instructions on building a timestamping smart contracts app in just 30 minutes. It covers various aspects such as customizing the wallet-template app, constructing a complex multi-stage SPV proof of blockchain inclusion, saving and verifying proof files, binding transaction confidence state to the user interface, and creating a Mac DMG bundle with a custom icon.Hearn also announced an upcoming event called DevCore London, where he and other developers will be present to run a hackathon/workshop type event. During this event, Hearn will showcase a live coding session where he will write a decentralized cross-platform Tor supporting document timestamping app using OP_RETURN outputs. The app will have a user-friendly GUI and will be developed on stage within a span of 30 minutes.The event is open to the public and will take place at etc.venues St Paul's on April 15th. Apart from Hearn, attendees will include Gavin, Wladimir, Corey, and an unnamed individual. In the afternoon, the unnamed individual will host a hackathon/workshop event with a focus on contracts, although other topics will also be covered. The event aims to demonstrate the ease of writing contract apps in recent years. It promises to provide a hands-on experience for real developers rather than just being a platform for discussions. 2015-06-02T14:20:47+00:00 + Former Bitcoin developer Mike Hearn has made his tutorial talk from DevCore 2015 available on the website. The tutorial provides detailed instructions on building a timestamping smart contracts app in just 30 minutes. It covers various aspects such as customizing the wallet-template app, constructing a complex multi-stage SPV proof of blockchain inclusion, saving and verifying proof files, binding transaction confidence state to the user interface, and creating a Mac DMG bundle with a custom icon.Hearn also announced an upcoming event called DevCore London, where he and other developers will be present to run a hackathon/workshop type event. During this event, Hearn will showcase a live coding session where he will write a decentralized cross-platform Tor supporting document timestamping app using OP_RETURN outputs. The app will have a user-friendly GUI and will be developed on stage within a span of 30 minutes.The event is open to the public and will take place at etc.venues St Paul's on April 15th. Apart from Hearn, attendees will include Gavin, Wladimir, Corey, and an unnamed individual. In the afternoon, the unnamed individual will host a hackathon/workshop event with a focus on contracts, although other topics will also be covered. The event aims to demonstrate the ease of writing contract apps in recent years. It promises to provide a hands-on experience for real developers rather than just being a platform for discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Double-spending-and-replace-by-fee.xml b/static/bitcoin-dev/April_2015/combined_Double-spending-and-replace-by-fee.xml index 26c18f7a02..41a52a62ec 100644 --- a/static/bitcoin-dev/April_2015/combined_Double-spending-and-replace-by-fee.xml +++ b/static/bitcoin-dev/April_2015/combined_Double-spending-and-replace-by-fee.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Double spending and replace by fee - 2023-08-01T12:11:41.865487+00:00 + 2025-10-11T22:11:58.789782+00:00 + python-feedgen Peter Todd 2015-04-21 11:37:14+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Double spending and replace by fee - 2023-08-01T12:11:41.865487+00:00 + 2025-10-11T22:11:58.789943+00:00 - In a 2015 email thread, Adrian Macneil from Coinbase expressed concern about the impact of the proposed Replace-by-Fee (RBF) protocol on Bitcoin. He discussed with Coinbase the potential difficulty in pitching Bitcoin as an alternative to credit card payments for large merchants due to their reliance on the current first-seen mempool behavior. Macneil raised questions about Coinbase's contractual obligations regarding zeroconf transactions, their double-spend losses history, and their plans to move away from dependency on "first-seen" mempool policy.Peter Todd challenged Adrian to provide a list of companies that actually rely on first-seen mempool behavior. Meanwhile, Mike Hearn shared two blog posts related to RBF and double spending mitigations. The first post argued against RBF-SE, highlighting its potential harm to Bitcoin. The second post explored techniques such as risk analysis, payment channels, countersigning by a trusted third party, remote attestation, ID verification, waiting for confirmations, and punishment of double spending blocks to make double spending more difficult.The email thread also included a promotional message about the Go Parallel Website, a platform sponsored by Intel and developed in partnership with Slashdot Media. This website focuses on parallel software development and offers various resources like thought leadership blogs, news, videos, case studies, tutorials, and more.On the Bitcoin-development mailing list, Mike Hearn wrote two blog posts discussing replace by fee and double-spending mitigations. The first article, titled "Replace by Fee Scorched Earth, a Counter Argument," presents arguments against RBF-SE, emphasizing its potential harm to Bitcoin. The second post, titled "Double Spending and How to Make It Harder," summarizes instances of double spending against merchants and suggests techniques to mitigate this risk. These techniques include risk analysis, payment channels, countersigning by a trusted third party, remote attestation, ID verification, waiting for confirmations, and punishment of double spending blocks. The posts are considered valuable and interesting to those interested in the topic.The author acknowledges that their views may not be exhaustive or unbiased but hopes that their thoughts will provide useful insights for readers interested in replace-by-fee and double-spending mitigations. 2015-04-21T11:37:14+00:00 + In a 2015 email thread, Adrian Macneil from Coinbase expressed concern about the impact of the proposed Replace-by-Fee (RBF) protocol on Bitcoin. He discussed with Coinbase the potential difficulty in pitching Bitcoin as an alternative to credit card payments for large merchants due to their reliance on the current first-seen mempool behavior. Macneil raised questions about Coinbase's contractual obligations regarding zeroconf transactions, their double-spend losses history, and their plans to move away from dependency on "first-seen" mempool policy.Peter Todd challenged Adrian to provide a list of companies that actually rely on first-seen mempool behavior. Meanwhile, Mike Hearn shared two blog posts related to RBF and double spending mitigations. The first post argued against RBF-SE, highlighting its potential harm to Bitcoin. The second post explored techniques such as risk analysis, payment channels, countersigning by a trusted third party, remote attestation, ID verification, waiting for confirmations, and punishment of double spending blocks to make double spending more difficult.The email thread also included a promotional message about the Go Parallel Website, a platform sponsored by Intel and developed in partnership with Slashdot Media. This website focuses on parallel software development and offers various resources like thought leadership blogs, news, videos, case studies, tutorials, and more.On the Bitcoin-development mailing list, Mike Hearn wrote two blog posts discussing replace by fee and double-spending mitigations. The first article, titled "Replace by Fee Scorched Earth, a Counter Argument," presents arguments against RBF-SE, emphasizing its potential harm to Bitcoin. The second post, titled "Double Spending and How to Make It Harder," summarizes instances of double spending against merchants and suggests techniques to mitigate this risk. These techniques include risk analysis, payment channels, countersigning by a trusted third party, remote attestation, ID verification, waiting for confirmations, and punishment of double spending blocks. The posts are considered valuable and interesting to those interested in the topic.The author acknowledges that their views may not be exhaustive or unbiased but hopes that their thoughts will provide useful insights for readers interested in replace-by-fee and double-spending mitigations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Fwd-Reusable-payment-codes.xml b/static/bitcoin-dev/April_2015/combined_Fwd-Reusable-payment-codes.xml index 5fb491b11d..9a928b0b5f 100644 --- a/static/bitcoin-dev/April_2015/combined_Fwd-Reusable-payment-codes.xml +++ b/static/bitcoin-dev/April_2015/combined_Fwd-Reusable-payment-codes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Reusable payment codes - 2023-08-01T12:19:22.577263+00:00 + 2025-10-11T22:11:46.045119+00:00 + python-feedgen Justus Ranvier 2015-04-25 00:22:30+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Fwd: Reusable payment codes - 2023-08-01T12:19:22.577263+00:00 + 2025-10-11T22:11:46.045253+00:00 - The discussion revolves around the use of x co-ordinate instead of hash of the secret while computing Diffie Hellman secret as an alternative to DarkWallet-style stealth addresses. The author suggests that using the x value directly avoids the need for a check to make sure that the hash is valid for secp256k1. A link shared in the email contains an RFC for a new type of Bitcoin address called a "payment code", which provides useful features such as positively identifying senders to recipients and automatically providing for transaction refunds.Payment codes can be publicly advertised and associated with a real-life identity without causing a loss of financial privacy. Compared to stealth addresses, payment codes require less blockchain data storage, requiring 65 bytes of OP_RETURN data per sender-recipient pair, while stealth addresses require 40 bytes per transaction. The author has updated a proposal by incorporating feedback, which can be found on GitHub. The proposal involves using payment codes as a messaging layer and providing a Heartbleed-free payment protocol.However, there are concerns about privacy leaks and the compatibility with multisignature. The author optimized for non-reliance on third-party services and the ability to recover spendable funds from a seed backup, resulting in tradeoffs. Payment codes could be used by merchants to positively identify customers and provide refund capabilities automatically. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer, making thefts easier.The ability to prove that withdrawals are sent to a positively-identified party might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. The email conversation discusses a proposal to use a constantly reused address as a messaging layer, which may undermine the privacy of the idea. The output associated with notification transactions would require special handling to avoid privacy leaks and would require mixing or being donated to miners as a transaction fee. Payment codes are suggested as an alternative solution, which can positively identify customers and provide refund capabilities in a merchant-customer relationship. However, payment codes could be more expensive to compute and are incompatible with multisignature. The proposal optimized for non-reliance on third-party services and a guaranteed ability to recover spendable funds from a seed backup. It is suggested that there are enough benefits to make them worthwhile, particularly for bitcoin businesses in some jurisdictions to move out of money transmitter territory. 2015-04-25T00:22:30+00:00 + The discussion revolves around the use of x co-ordinate instead of hash of the secret while computing Diffie Hellman secret as an alternative to DarkWallet-style stealth addresses. The author suggests that using the x value directly avoids the need for a check to make sure that the hash is valid for secp256k1. A link shared in the email contains an RFC for a new type of Bitcoin address called a "payment code", which provides useful features such as positively identifying senders to recipients and automatically providing for transaction refunds.Payment codes can be publicly advertised and associated with a real-life identity without causing a loss of financial privacy. Compared to stealth addresses, payment codes require less blockchain data storage, requiring 65 bytes of OP_RETURN data per sender-recipient pair, while stealth addresses require 40 bytes per transaction. The author has updated a proposal by incorporating feedback, which can be found on GitHub. The proposal involves using payment codes as a messaging layer and providing a Heartbleed-free payment protocol.However, there are concerns about privacy leaks and the compatibility with multisignature. The author optimized for non-reliance on third-party services and the ability to recover spendable funds from a seed backup, resulting in tradeoffs. Payment codes could be used by merchants to positively identify customers and provide refund capabilities automatically. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer, making thefts easier.The ability to prove that withdrawals are sent to a positively-identified party might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. The email conversation discusses a proposal to use a constantly reused address as a messaging layer, which may undermine the privacy of the idea. The output associated with notification transactions would require special handling to avoid privacy leaks and would require mixing or being donated to miners as a transaction fee. Payment codes are suggested as an alternative solution, which can positively identify customers and provide refund capabilities in a merchant-customer relationship. However, payment codes could be more expensive to compute and are incompatible with multisignature. The proposal optimized for non-reliance on third-party services and a guaranteed ability to recover spendable funds from a seed backup. It is suggested that there are enough benefits to make them worthwhile, particularly for bitcoin businesses in some jurisdictions to move out of money transmitter territory. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Looking-for-a-good-bitcoin-script-decompiler-in-Python.xml b/static/bitcoin-dev/April_2015/combined_Looking-for-a-good-bitcoin-script-decompiler-in-Python.xml index bd2f8b5529..fda1a9010e 100644 --- a/static/bitcoin-dev/April_2015/combined_Looking-for-a-good-bitcoin-script-decompiler-in-Python.xml +++ b/static/bitcoin-dev/April_2015/combined_Looking-for-a-good-bitcoin-script-decompiler-in-Python.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Looking for a good bitcoin script decompiler in Python - 2023-08-01T12:20:15.036093+00:00 + 2025-10-11T22:11:29.034858+00:00 + python-feedgen Jeff Garzik 2015-04-29 23:27:19+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Looking for a good bitcoin script decompiler in Python - 2023-08-01T12:20:15.036093+00:00 + 2025-10-11T22:11:29.035001+00:00 - In an email chain on the Bitcoin-development mailing list on April 29, 2015, a sender requested recommendations for a Python script that could generate op codes from the hash of locking and unlocking transaction scripts. The purpose for this script was not specified in the email. However, Richard Moore, the founder of Genetic Mistakes Software Inc., responded to the email with a recommendation. He suggested using his library called pycoind, which can be imported using "import pycoind". Moore provided a link to the library on GitHub at https://github.com/ricmoo/pycoind. He also gave an example of how to use the library by utilizing the Tokenizer function, which would output the op codes for a given hex string. It is worth noting that Jeff Garzik, a Bitcoin core developer and open source evangelist, signed off on the email chain. Additionally, the email included an advertisement for server and application monitoring software, although it was unrelated to the request for the Python script. 2015-04-29T23:27:19+00:00 + In an email chain on the Bitcoin-development mailing list on April 29, 2015, a sender requested recommendations for a Python script that could generate op codes from the hash of locking and unlocking transaction scripts. The purpose for this script was not specified in the email. However, Richard Moore, the founder of Genetic Mistakes Software Inc., responded to the email with a recommendation. He suggested using his library called pycoind, which can be imported using "import pycoind". Moore provided a link to the library on GitHub at https://github.com/ricmoo/pycoind. He also gave an example of how to use the library by utilizing the Tokenizer function, which would output the op codes for a given hex string. It is worth noting that Jeff Garzik, a Bitcoin core developer and open source evangelist, signed off on the email chain. Additionally, the email included an advertisement for server and application monitoring software, although it was unrelated to the request for the Python script. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_PAPER-New-algorithm-for-the-discrete-logarithm-problem-on-elliptic-curves.xml b/static/bitcoin-dev/April_2015/combined_PAPER-New-algorithm-for-the-discrete-logarithm-problem-on-elliptic-curves.xml index 9078ec1edc..eaa8f2fc78 100644 --- a/static/bitcoin-dev/April_2015/combined_PAPER-New-algorithm-for-the-discrete-logarithm-problem-on-elliptic-curves.xml +++ b/static/bitcoin-dev/April_2015/combined_PAPER-New-algorithm-for-the-discrete-logarithm-problem-on-elliptic-curves.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - PAPER: New algorithm for the discrete logarithm problem on elliptic curves - 2023-08-01T12:12:17.997124+00:00 + 2025-10-11T22:12:00.915258+00:00 + python-feedgen Brian Hoffman 2015-04-07 22:15:36+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - PAPER: New algorithm for the discrete logarithm problem on elliptic curves - 2023-08-01T12:12:17.997124+00:00 + 2025-10-11T22:12:00.915437+00:00 - On April 7, 2015, Jean-Paul Kogelman sent an email apologizing for a false alarm and spamming on the Bitcoin-development mailing list hosted by SourceForge. The email contained a link to a research paper discussing a new algorithm for the Discrete Logarithm Problem (DLP) in cryptography. This algorithm was shared on Reddit, where users debated its potential impact on Bitcoin's security. Although the paper itself did not mention Bitcoin or any specific cryptographic system, concerns were raised about the implications of this algorithm on the security of such systems.In addition to the false alarm email, the original context message from 'jp' included a link to a PDF document titled "Efficient Zero-Knowledge Contingent Payments in Cryptocurrencies with Applications to Bitcoin." Published in 2015 and hosted on the International Association for Cryptologic Research (IACR) ePrint archive, this research paper presents a method for creating efficient zero-knowledge contingent payments using cryptocurrencies like Bitcoin. The authors explain how their method can be utilized to create smart contracts that only execute under certain conditions, without revealing additional information about the parties involved.Overall, while the initial context message lacked detail, the linked research paper offers insights into the world of cryptocurrency and the potential applications of smart contracts. 2015-04-07T22:15:36+00:00 + On April 7, 2015, Jean-Paul Kogelman sent an email apologizing for a false alarm and spamming on the Bitcoin-development mailing list hosted by SourceForge. The email contained a link to a research paper discussing a new algorithm for the Discrete Logarithm Problem (DLP) in cryptography. This algorithm was shared on Reddit, where users debated its potential impact on Bitcoin's security. Although the paper itself did not mention Bitcoin or any specific cryptographic system, concerns were raised about the implications of this algorithm on the security of such systems.In addition to the false alarm email, the original context message from 'jp' included a link to a PDF document titled "Efficient Zero-Knowledge Contingent Payments in Cryptocurrencies with Applications to Bitcoin." Published in 2015 and hosted on the International Association for Cryptologic Research (IACR) ePrint archive, this research paper presents a method for creating efficient zero-knowledge contingent payments using cryptocurrencies like Bitcoin. The authors explain how their method can be utilized to create smart contracts that only execute under certain conditions, without revealing additional information about the parties involved.Overall, while the initial context message lacked detail, the linked research paper offers insights into the world of cryptocurrency and the potential applications of smart contracts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Proof-of-Payment.xml b/static/bitcoin-dev/April_2015/combined_Proof-of-Payment.xml index b372b0fff7..c2a5dea35f 100644 --- a/static/bitcoin-dev/April_2015/combined_Proof-of-Payment.xml +++ b/static/bitcoin-dev/April_2015/combined_Proof-of-Payment.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proof of Payment - 2023-08-01T12:01:55.202198+00:00 + 2025-10-11T22:11:54.545180+00:00 + python-feedgen Jorge Timón 2015-04-28 12:53:58+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Proof of Payment - 2023-08-01T12:01:55.202198+00:00 + 2025-10-11T22:11:54.545326+00:00 - In the context, a new idea called Proof of Payment (PoP) has been proposed by Kalle Rosenbaum to provide proof that a payment has been made. This concept can be applied in various scenarios such as pre-paid hotel rooms, online video rental services, ad-signs, and lotteries. PoP is unique because it can be generated on demand and is only usable once to prevent theft issues. It is also capable of creating PoP for any payment regardless of script type.The author discusses the current methods of proving payment, including BIP0070 and signing messages with private keys. However, the author believes that these methods have limitations. To address this, the author introduces the data structure and process for PoP. This involves generating a request from the server to the wallet, identifying the transaction, creating an unsigned PoP, signing the UPoP to create PoP, sending PoP to the destination, and validating it.The format of PoP and security issues are also addressed in the context. Potential interception of PoP requests and stealing of PoP are identified as potential concerns. The importance of maintaining the security of wallets after they have been emptied is emphasized. Further work to be done includes extending BIP0070 for PoPs, defining an extension for BIP0021 to support PoP requests, implementing a proof-of-concept, and proposing BIPs for the different parts.In addition, the context mentions the concept of Anonymous Credentials, which provides privacy for service usage while maintaining accountability for payment. The issuance of Anonymous Credentials is not atomic with payment transactions, but proof of payment can be used in court if the credentials are not issued. The Zerocoin developers have also published a paper on a blockchain version of Distributed Anonymous Credentials, with a link provided for additional information.Overall, the proposal of Proof of Payment (PoP) aims to offer a reliable method for proving that a payment has been made, with various use cases and desirable properties discussed. The context also highlights the need for further development and implementation of PoP-related protocols and extensions. 2015-04-28T12:53:58+00:00 + In the context, a new idea called Proof of Payment (PoP) has been proposed by Kalle Rosenbaum to provide proof that a payment has been made. This concept can be applied in various scenarios such as pre-paid hotel rooms, online video rental services, ad-signs, and lotteries. PoP is unique because it can be generated on demand and is only usable once to prevent theft issues. It is also capable of creating PoP for any payment regardless of script type.The author discusses the current methods of proving payment, including BIP0070 and signing messages with private keys. However, the author believes that these methods have limitations. To address this, the author introduces the data structure and process for PoP. This involves generating a request from the server to the wallet, identifying the transaction, creating an unsigned PoP, signing the UPoP to create PoP, sending PoP to the destination, and validating it.The format of PoP and security issues are also addressed in the context. Potential interception of PoP requests and stealing of PoP are identified as potential concerns. The importance of maintaining the security of wallets after they have been emptied is emphasized. Further work to be done includes extending BIP0070 for PoPs, defining an extension for BIP0021 to support PoP requests, implementing a proof-of-concept, and proposing BIPs for the different parts.In addition, the context mentions the concept of Anonymous Credentials, which provides privacy for service usage while maintaining accountability for payment. The issuance of Anonymous Credentials is not atomic with payment transactions, but proof of payment can be used in court if the credentials are not issued. The Zerocoin developers have also published a paper on a blockchain version of Distributed Anonymous Credentials, with a link provided for additional information.Overall, the proposal of Proof of Payment (PoP) aims to offer a reliable method for proving that a payment has been made, with various use cases and desirable properties discussed. The context also highlights the need for further development and implementation of PoP-related protocols and extensions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml b/static/bitcoin-dev/April_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml index da4d81be46..5b8a48ffab 100644 --- a/static/bitcoin-dev/April_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml +++ b/static/bitcoin-dev/April_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) - 2023-08-01T12:06:55.534846+00:00 + 2025-10-11T22:11:33.284970+00:00 + python-feedgen Tier Nolan 2015-05-06 22:09:59+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) - 2023-08-01T12:06:55.535908+00:00 + 2025-10-11T22:11:33.285124+00:00 - Several proposals and ideas were discussed by Bitcoin developers regarding the implementation of new opcodes and changes to the Bitcoin scripting system. One proposal was the addition of CHECKLOCKTIMEVERIFY (CLTV), which would make a transaction output unspendable until a certain point in the future. Another proposal suggested increasing the transaction version to achieve a similar outcome. Developers expressed concerns about changing the semantics of nSequence and the potential impact on previously valid transactions. Mark Friedenbach proposed an nSequence-based RCLTV proposal that was already reorg safe. Peter Todd and Matt Corallo discussed the idea of adding OP_RELATIVECHECKLOCKTIMEVERIFY (RCLTV) opcode, acknowledging its drawbacks but highlighting its usefulness for certain protocols. The conversations also touched on time-based locks and the potential incentive issues with mining. Timón proposed a new softfork rule to enforce setting the nHeight of CTxIn to the correct height. Discussions also revolved around implementing RCLTV and OP_MATURITY for more secure transactions against reorganization. In March 2015, Matt Corallo proposed requiring locktime to be at least N plus the input's height. Zooko preferred relative CHECKLOCKTIMEVERIFY over absolute CHECKLOCKTIMEVERIFY due to concerns about "race conditions."The article discusses the use of the CHECKLOCKTIMEVERIFY opcode in Bitcoin scripts and its applications. Despite challenges such as exposing script information and enforcing mempool invariants during reorganizations, CHECKLOCKTIMEVERIFY can be used in non-interactive time-locked refunds, two-factor wallets, and micropayment channels. Two-factor wallets utilize 2-of-2 multisig scriptPubKeys, allowing users to spend funds without the cooperation of the service by waiting for the expiry time. The article also addresses vulnerabilities in Bitcoin protocols and suggests solutions. It analyzes micropayment channels and proposes using the same scriptPubKey as the two-factor wallet example to solve issues with refund transactions. The PayPub protocol for trustless payments for information is discussed, highlighting a flaw in the existing implementation that can be addressed with scriptPubKeys. The challenge of proving sacrifices of coins to mining fees is mentioned, and CHECKLOCKTIMEVERIFY is suggested as a solution to discourage mining centralization. Finally, the article suggests replacing the nLockTime field entirely with a per-signature capability that would serve as proof of spendability. Detailed specifications and references are provided for these proposed solutions. 2015-05-06T22:09:59+00:00 + Several proposals and ideas were discussed by Bitcoin developers regarding the implementation of new opcodes and changes to the Bitcoin scripting system. One proposal was the addition of CHECKLOCKTIMEVERIFY (CLTV), which would make a transaction output unspendable until a certain point in the future. Another proposal suggested increasing the transaction version to achieve a similar outcome. Developers expressed concerns about changing the semantics of nSequence and the potential impact on previously valid transactions. Mark Friedenbach proposed an nSequence-based RCLTV proposal that was already reorg safe. Peter Todd and Matt Corallo discussed the idea of adding OP_RELATIVECHECKLOCKTIMEVERIFY (RCLTV) opcode, acknowledging its drawbacks but highlighting its usefulness for certain protocols. The conversations also touched on time-based locks and the potential incentive issues with mining. Timón proposed a new softfork rule to enforce setting the nHeight of CTxIn to the correct height. Discussions also revolved around implementing RCLTV and OP_MATURITY for more secure transactions against reorganization. In March 2015, Matt Corallo proposed requiring locktime to be at least N plus the input's height. Zooko preferred relative CHECKLOCKTIMEVERIFY over absolute CHECKLOCKTIMEVERIFY due to concerns about "race conditions."The article discusses the use of the CHECKLOCKTIMEVERIFY opcode in Bitcoin scripts and its applications. Despite challenges such as exposing script information and enforcing mempool invariants during reorganizations, CHECKLOCKTIMEVERIFY can be used in non-interactive time-locked refunds, two-factor wallets, and micropayment channels. Two-factor wallets utilize 2-of-2 multisig scriptPubKeys, allowing users to spend funds without the cooperation of the service by waiting for the expiry time. The article also addresses vulnerabilities in Bitcoin protocols and suggests solutions. It analyzes micropayment channels and proposes using the same scriptPubKey as the two-factor wallet example to solve issues with refund transactions. The PayPub protocol for trustless payments for information is discussed, highlighting a flaw in the existing implementation that can be addressed with scriptPubKeys. The challenge of proving sacrifices of coins to mining fees is mentioned, and CHECKLOCKTIMEVERIFY is suggested as a solution to discourage mining centralization. Finally, the article suggests replacing the nLockTime field entirely with a per-signature capability that would serve as proof of spendability. Detailed specifications and references are provided for these proposed solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Request-For-Discussion-BIP-number-Multi-Currency-Hierarchy-For-Use-In-Multisignature-Deterministic-Wallets.xml b/static/bitcoin-dev/April_2015/combined_Request-For-Discussion-BIP-number-Multi-Currency-Hierarchy-For-Use-In-Multisignature-Deterministic-Wallets.xml index b2c34dd1c7..aa6cbe6c29 100644 --- a/static/bitcoin-dev/April_2015/combined_Request-For-Discussion-BIP-number-Multi-Currency-Hierarchy-For-Use-In-Multisignature-Deterministic-Wallets.xml +++ b/static/bitcoin-dev/April_2015/combined_Request-For-Discussion-BIP-number-Multi-Currency-Hierarchy-For-Use-In-Multisignature-Deterministic-Wallets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets - 2023-08-01T12:12:46.670263+00:00 + 2025-10-11T22:11:39.659829+00:00 + python-feedgen Vertoe Qhor 2015-04-16 13:11:01+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Request For Discussion / BIP number - Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets - 2023-08-01T12:12:46.670263+00:00 + 2025-10-11T22:11:39.659989+00:00 - A potential Bitcoin Improvement Proposal (BIP) called "Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets" has been proposed. The proposal aims to create a hierarchical structure for multi-currency wallets based on multisig, allowing users to generate any desired currency without requiring multiple extended public keys (xpubs). The proposal suggests sticking the coin type on the public derivation side of things so that users can generate litecoin or darkcoin multisigs without permission. However, there are concerns about the uniqueness of this proposal, as it seems similar to BIP 44 but with rearranged fields.The discussion also involves Alan Reiner's proposal for multisig address generation. His scheme is similar to BIP45 but collapses the "cosigner_index" and "change" fields into a single field with a different formula. William Swanson prefers BIP45's approach of giving each field its own dedicated purpose. He also discusses Airbitz's ideal HD tree structure, which would be BIP 44 plus some "no-collision" logic. Reiner explains his "no-collision" scheme for multi-signature wallets, which adds new internal and external chains without modifying the key tree structure. However, there is a debate about whether to add more levels to the key tree or more chains to the wallet.The email exchange continues with discussions about the benefits of a "cosigner_index" branch in multi-signature wallets. This branch ensures that different parties using a multi-sig wallet can accept payments from different sources but generate different addresses, adding privacy without additional cost. This structure allows for compatibility between XPUB's generated by different multi-sig wallets.The proposal for a multi-currency hierarchy in multisignature deterministic wallets is under discussion. Some argue that it is an appropriate proposal given BIP-0044's description of a multi-currency hierarchy, while others question if it improves Bitcoin and whether it should be assigned a BIP number. There are suggestions to use the existing BIP 44 hierarchy with additional conventions, and concerns about whether the proposal offers any advantages over BIP 44's structure.The proposal suggests a hierarchical structure for multi-currency wallets based on multisig, allowing users to generate different currencies without requiring multiple extended public keys. It aims to improve usability for altcoins but has raised questions about its relevance as a Bitcoin Improvement Proposal. There is ongoing debate about the benefits of the proposal and its potential impact on existing hierarchies like BIP 44.The potential Bitcoin Improvement Proposal (BIP) called "Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets" has been uploaded to Github for discussion and possible assignment of a BIP number. Some participants question the necessity of the proposal and suggest using the existing BIP 44 hierarchy with additional conventions. Others argue that the proposal improves altcoin usability but may not be relevant as a BIP for Bitcoin. The author seeks further discussion and feedback on the proposal.In summary, there are ongoing discussions about proposals for multi-currency and multisignature wallets. The proposed solutions aim to address the limitations of current systems and provide more flexibility and privacy for users. However, there are debates about the uniqueness and necessity of these proposals, as well as their compatibility with existing hierarchies. Participants in the discussions are seeking more clarification and feedback before deciding on assigning BIP numbers or implementing the proposed solutions. 2015-04-16T13:11:01+00:00 + A potential Bitcoin Improvement Proposal (BIP) called "Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets" has been proposed. The proposal aims to create a hierarchical structure for multi-currency wallets based on multisig, allowing users to generate any desired currency without requiring multiple extended public keys (xpubs). The proposal suggests sticking the coin type on the public derivation side of things so that users can generate litecoin or darkcoin multisigs without permission. However, there are concerns about the uniqueness of this proposal, as it seems similar to BIP 44 but with rearranged fields.The discussion also involves Alan Reiner's proposal for multisig address generation. His scheme is similar to BIP45 but collapses the "cosigner_index" and "change" fields into a single field with a different formula. William Swanson prefers BIP45's approach of giving each field its own dedicated purpose. He also discusses Airbitz's ideal HD tree structure, which would be BIP 44 plus some "no-collision" logic. Reiner explains his "no-collision" scheme for multi-signature wallets, which adds new internal and external chains without modifying the key tree structure. However, there is a debate about whether to add more levels to the key tree or more chains to the wallet.The email exchange continues with discussions about the benefits of a "cosigner_index" branch in multi-signature wallets. This branch ensures that different parties using a multi-sig wallet can accept payments from different sources but generate different addresses, adding privacy without additional cost. This structure allows for compatibility between XPUB's generated by different multi-sig wallets.The proposal for a multi-currency hierarchy in multisignature deterministic wallets is under discussion. Some argue that it is an appropriate proposal given BIP-0044's description of a multi-currency hierarchy, while others question if it improves Bitcoin and whether it should be assigned a BIP number. There are suggestions to use the existing BIP 44 hierarchy with additional conventions, and concerns about whether the proposal offers any advantages over BIP 44's structure.The proposal suggests a hierarchical structure for multi-currency wallets based on multisig, allowing users to generate different currencies without requiring multiple extended public keys. It aims to improve usability for altcoins but has raised questions about its relevance as a Bitcoin Improvement Proposal. There is ongoing debate about the benefits of the proposal and its potential impact on existing hierarchies like BIP 44.The potential Bitcoin Improvement Proposal (BIP) called "Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets" has been uploaded to Github for discussion and possible assignment of a BIP number. Some participants question the necessity of the proposal and suggest using the existing BIP 44 hierarchy with additional conventions. Others argue that the proposal improves altcoin usability but may not be relevant as a BIP for Bitcoin. The author seeks further discussion and feedback on the proposal.In summary, there are ongoing discussions about proposals for multi-currency and multisignature wallets. The proposed solutions aim to address the limitations of current systems and provide more flexibility and privacy for users. However, there are debates about the uniqueness and necessity of these proposals, as well as their compatibility with existing hierarchies. Participants in the discussions are seeking more clarification and feedback before deciding on assigning BIP numbers or implementing the proposed solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Reusable-payment-codes.xml b/static/bitcoin-dev/April_2015/combined_Reusable-payment-codes.xml index 66adf5b092..54f468be57 100644 --- a/static/bitcoin-dev/April_2015/combined_Reusable-payment-codes.xml +++ b/static/bitcoin-dev/April_2015/combined_Reusable-payment-codes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reusable payment codes - 2023-08-01T12:16:22.615116+00:00 + 2025-10-11T22:11:35.409736+00:00 + python-feedgen Justus Ranvier 2015-10-23 15:57:14+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Reusable payment codes - 2023-08-01T12:16:22.615116+00:00 + 2025-10-11T22:11:35.409913+00:00 - In October 2015, there was a discussion on the bitcoin-dev mailing list about Bitcoin Improvement Proposal (BIP) version 1. Luke Dashjr disagreed with adopting the proposal as is because multi-push OP_RETURN outputs were not standard transactions and could not be relied upon for network relay. He suggested waiting for additional capabilities to be deployed in the network before specifying a version 2 payment code. Justus Ranvier argued that version 1 payment codes were designed to be deployable without requiring network-level changes and acknowledged that multi-push OP_RETURN outputs would be standard in v0.12.0 of Bitcoin.Luke Dashjr expressed concerns about the "notification address" requirement in a proposal, as it would lead to address reuse and blockchain spam. He suggested using a single zero-value OP_RETURN output with two pushes instead. Justus Ranvier acknowledged that this portion of the proposal was not ideal but emphasized the goal of making the proposal usable on as many mobile/light wallets as possible. Dashjr argued that BIPs should not be designed around current software and that software upgrades are necessary regardless.There was also an email exchange regarding BIP 63, where Peter Todd expressed his inclination to shelve work on it due to other priorities. Several people offered to send donations to advance the BIP, but no donation address was posted. Todd suggested that someone else could take up the work if interested.Justus Ranvier shared an RFC on April 24, 2015, for a new type of Bitcoin address called a payment code. Payment codes are SPV-friendly alternatives to stealth addresses that positively identify senders to recipients and require less blockchain data storage. They can be publicly advertised without compromising financial privacy. Luke Dashjr expressed concerns about the "notification address" requirement in the proposal, suggesting an alternative approach using a single zero-value OP_RETURN output with two pushes.The concept of identity in relation to payment codes was discussed, with the understanding that it refers to a specific extended public/private key pair rather than conventional personal information. The discussion also touched on privacy concerns in SPV clients and suggested measures such as connecting exclusively through Tor and using varying bloom filters to enhance privacy.Brian Deery expressed worries about payment codes, particularly regarding the explicit tying of identities to them and the potential for identity linkage in bloom filter clients. There were suggestions for improving privacy in SPV clients by using multiple peers, filtering subsets of addresses, and varying the addresses being monitored.One of the main challenges with payment codes is that they rely on making dust payments to a constantly reused address, which undermines the privacy it aims to provide. This method also doubles the data sent for one-time anonymous donations. To address these issues, Brian suggests some ideas such as using even or odd DER encoding to save bytes and deriving the chain value from the x value to save more bytes. Another suggestion is to encode the "x value" into the signature's R value to make the transaction appear like a standard bitcoin transaction and eliminate the need for op_return.In terms of privacy, Brian proposes the concept of a common meeting point where the receiver of the payment code would trial-decode all payment codes sent to a pre-specified dead drop address, such as a charity address. This would require more effort from the receiver but would provide privacy regarding the number of people interacting with them.The proposed payment code scheme establishes a shared chain once and does not require reestablishment, improving upon the stealth address proposal. However, there is no solution presented for scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses.Overall, payment codes offer SPV-friendly alternatives to stealth addresses with features like sender identification and automatic transaction refunds. They require less blockchain data storage compared to stealth addresses but face challenges in terms of privacy and data efficiency. The provided link contains an RFC detailing the payment code proposal. 2015-10-23T15:57:14+00:00 + In October 2015, there was a discussion on the bitcoin-dev mailing list about Bitcoin Improvement Proposal (BIP) version 1. Luke Dashjr disagreed with adopting the proposal as is because multi-push OP_RETURN outputs were not standard transactions and could not be relied upon for network relay. He suggested waiting for additional capabilities to be deployed in the network before specifying a version 2 payment code. Justus Ranvier argued that version 1 payment codes were designed to be deployable without requiring network-level changes and acknowledged that multi-push OP_RETURN outputs would be standard in v0.12.0 of Bitcoin.Luke Dashjr expressed concerns about the "notification address" requirement in a proposal, as it would lead to address reuse and blockchain spam. He suggested using a single zero-value OP_RETURN output with two pushes instead. Justus Ranvier acknowledged that this portion of the proposal was not ideal but emphasized the goal of making the proposal usable on as many mobile/light wallets as possible. Dashjr argued that BIPs should not be designed around current software and that software upgrades are necessary regardless.There was also an email exchange regarding BIP 63, where Peter Todd expressed his inclination to shelve work on it due to other priorities. Several people offered to send donations to advance the BIP, but no donation address was posted. Todd suggested that someone else could take up the work if interested.Justus Ranvier shared an RFC on April 24, 2015, for a new type of Bitcoin address called a payment code. Payment codes are SPV-friendly alternatives to stealth addresses that positively identify senders to recipients and require less blockchain data storage. They can be publicly advertised without compromising financial privacy. Luke Dashjr expressed concerns about the "notification address" requirement in the proposal, suggesting an alternative approach using a single zero-value OP_RETURN output with two pushes.The concept of identity in relation to payment codes was discussed, with the understanding that it refers to a specific extended public/private key pair rather than conventional personal information. The discussion also touched on privacy concerns in SPV clients and suggested measures such as connecting exclusively through Tor and using varying bloom filters to enhance privacy.Brian Deery expressed worries about payment codes, particularly regarding the explicit tying of identities to them and the potential for identity linkage in bloom filter clients. There were suggestions for improving privacy in SPV clients by using multiple peers, filtering subsets of addresses, and varying the addresses being monitored.One of the main challenges with payment codes is that they rely on making dust payments to a constantly reused address, which undermines the privacy it aims to provide. This method also doubles the data sent for one-time anonymous donations. To address these issues, Brian suggests some ideas such as using even or odd DER encoding to save bytes and deriving the chain value from the x value to save more bytes. Another suggestion is to encode the "x value" into the signature's R value to make the transaction appear like a standard bitcoin transaction and eliminate the need for op_return.In terms of privacy, Brian proposes the concept of a common meeting point where the receiver of the payment code would trial-decode all payment codes sent to a pre-specified dead drop address, such as a charity address. This would require more effort from the receiver but would provide privacy regarding the number of people interacting with them.The proposed payment code scheme establishes a shared chain once and does not require reestablishment, improving upon the stealth address proposal. However, there is no solution presented for scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses.Overall, payment codes offer SPV-friendly alternatives to stealth addresses with features like sender identification and automatic transaction refunds. They require less blockchain data storage compared to stealth addresses but face challenges in terms of privacy and data efficiency. The provided link contains an RFC detailing the payment code proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2015/combined_Where-do-I-start-.xml b/static/bitcoin-dev/April_2015/combined_Where-do-I-start-.xml index 04c4ce650f..b847bc1d3f 100644 --- a/static/bitcoin-dev/April_2015/combined_Where-do-I-start-.xml +++ b/static/bitcoin-dev/April_2015/combined_Where-do-I-start-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Where do I start? - 2023-08-01T12:15:15.368816+00:00 + 2025-10-11T22:11:52.420801+00:00 + python-feedgen Thomas Kerin 2015-04-30 15:50:34+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Where do I start? - 2023-08-01T12:15:15.368816+00:00 + 2025-10-11T22:11:52.420959+00:00 - If you're interested in learning Java and Bitcoin, the sender suggests checking out the bitcoinj project on GitHub, which is a Java implementation of the Bitcoin protocol. They also mention an Android bitcoin wallet based on bitcoinj that could be helpful. The sender provides links to the bitcoinj GitHub page and bitcoin.org's pages on bitcoin for developers and developer documentation. In response to a beginner's question on understanding the Bitcoin protocol and becoming a good developer, Jorge Timón suggests improving tests and documentation while reading code. Mike Hearn adds that while tasks in Bitcoin Core can be complicated, there are more straightforward projects available, particularly those involving wallet apps. They mention that the highest priority tasks in Bitcoin Core can be found on the issue tracker.When asked about lacking areas in Bitcoin Core, Mike Hearn mentions that it depends on the person's interests. He suggests improving tests and documentation, and recommends checking the issue tracker to see the highest priority tasks. For those interested in more straightforward projects, he suggests looking into wallet apps. The email also includes information about BPM Camp, a virtual workshop on process modeling best practices with Bonita BPM.A CS student named Gabe Appleton seeks advice on their upcoming research project related to Bitcoin Core. They ask for guidance on areas they can contribute with their bachelor's degree and where to start. They inquire about potential areas of improvement for Bitcoin Core or if it would be better to focus on creating something new for the ecosystem. The email also contains an HTML attachment and an advertisement for BPM Camp, a free virtual workshop on process modeling best practices with Bonita BPM. 2015-04-30T15:50:34+00:00 + If you're interested in learning Java and Bitcoin, the sender suggests checking out the bitcoinj project on GitHub, which is a Java implementation of the Bitcoin protocol. They also mention an Android bitcoin wallet based on bitcoinj that could be helpful. The sender provides links to the bitcoinj GitHub page and bitcoin.org's pages on bitcoin for developers and developer documentation. In response to a beginner's question on understanding the Bitcoin protocol and becoming a good developer, Jorge Timón suggests improving tests and documentation while reading code. Mike Hearn adds that while tasks in Bitcoin Core can be complicated, there are more straightforward projects available, particularly those involving wallet apps. They mention that the highest priority tasks in Bitcoin Core can be found on the issue tracker.When asked about lacking areas in Bitcoin Core, Mike Hearn mentions that it depends on the person's interests. He suggests improving tests and documentation, and recommends checking the issue tracker to see the highest priority tasks. For those interested in more straightforward projects, he suggests looking into wallet apps. The email also includes information about BPM Camp, a virtual workshop on process modeling best practices with Bonita BPM.A CS student named Gabe Appleton seeks advice on their upcoming research project related to Bitcoin Core. They ask for guidance on areas they can contribute with their bachelor's degree and where to start. They inquire about potential areas of improvement for Bitcoin Core or if it would be better to focus on creating something new for the ecosystem. The email also contains an HTML attachment and an advertisement for BPM Camp, a free virtual workshop on process modeling best practices with Bonita BPM. - + \ No newline at end of file diff --git a/static/bitcoin-dev/April_2016/combined_AsicBoost.xml b/static/bitcoin-dev/April_2016/combined_AsicBoost.xml index 5b0e1464d7..4ce8e7ea25 100644 --- a/static/bitcoin-dev/April_2016/combined_AsicBoost.xml +++ b/static/bitcoin-dev/April_2016/combined_AsicBoost.xml @@ -2,7 +2,7 @@ 2 Combined summary - AsicBoost - 2025-09-26T15:37:30.393594+00:00 + 2025-10-11T21:47:33.928067+00:00 python-feedgen Timo Hanke 2016-04-08 20:58:57+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - AsicBoost - 2025-09-26T15:37:30.393730+00:00 + 2025-10-11T21:47:33.928240+00:00 2016-04-08T20:58:57+00:00 On April 1, 2016, Timo Hanke announced a new algorithmic improvement to the Bitcoin mining process called AsicBoost. This improvement, outlined in a white paper, aims to reduce power consumption and increase mining efficiency by optimizing the Bitcoin mining algorithm. It can be applied to all types of mining hardware and chip designs.However, concerns have been raised about centralization due to the patenting of this improvement. Depending on the licensing model used, one manufacturer could potentially have exclusive rights, leading to greater centralization of mining power. Peter Todd has expressed concern over this issue and questioned how equal opportunity access to the improvement will be ensured for all ASIC designers and manufacturers.There is also debate regarding whether AsicBoost is purely a software-based improvement or if it can be utilized by modifying hardware. Marek Palatinus believes it is a software thing that cannot be detected from outside if a miner uses it or not. However, Mustafa Al-Bassam suggests that if the algorithm is patented in certain countries like China, it could lead to a geographical decentralization of miners.Despite the potential for patenting mining algorithms in specific countries, many argue that it would be ultimately pointless due to Bitcoin's decentralized nature and international economy. Additionally, the patenting of AsicBoost could cause a sudden increase in Bitcoin mines in countries where the algorithm is not patented, leading to a geographical decentralization of miners from countries like China.Overall, the announcement of AsicBoost by Timo Hanke has sparked discussions about its potential impact on mining efficiency, centralization concerns, and geographic decentralization of miners. The white paper describing the improvement can be found at http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf. diff --git a/static/bitcoin-dev/April_2016/combined_BIP-CPRKV-Check-private-key-verify.xml b/static/bitcoin-dev/April_2016/combined_BIP-CPRKV-Check-private-key-verify.xml index d2a61742a1..111f2a2f48 100644 --- a/static/bitcoin-dev/April_2016/combined_BIP-CPRKV-Check-private-key-verify.xml +++ b/static/bitcoin-dev/April_2016/combined_BIP-CPRKV-Check-private-key-verify.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP CPRKV: Check private key verify - 2025-09-26T15:37:36.732364+00:00 + 2025-10-11T21:47:40.384003+00:00 python-feedgen jl2012 at xbt.hk 2016-04-18 19:03:07+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - BIP CPRKV: Check private key verify - 2025-09-26T15:37:36.732543+00:00 + 2025-10-11T21:47:40.384160+00:00 2016-04-18T19:03:07+00:00 In a recent proposal on the bitcoin-dev mailing list, there was a suggestion to remove the OP_CHECKPRIVPUBPAIR opcode and replace it with OP_CAT and OP_CHECKSIGVERIFY. This proposal involves two parties, Bob and Alice, agreeing upon a random secret nonce, k, and calculating r in the same way as signing a transaction. The script consists of various operations such as SIZE, ADD, SWAP, CAT, CECHKSIGVERIFY, and CHECKSIG. This proposal is deemed useful for the lightning network. It is mentioned that a patch to the reference client may be coded up, but segregated witness is likely to take priority for soft-fork slot usage.On February 29th, 2016, Mats Jerratsch shared a link to a discussion on the bitcoin-dev mailing list from November 2015 regarding a Bitcoin Improvement Proposal (BIP) for Schnorr signatures. Jerratsch noted that this proposal is relevant to the Lightning Network and asked if there was a demand for coding up a patch to the reference client. However, it is also mentioned that segregated witness might be taking up any potential soft-fork slot.Another discussion on the bitcoin-dev mailing list revolves around the usefulness of a certain feature for the Lightning Network. This feature involves the creation of a non-standard script to execute a payment in an altcoin without requiring a new opcode. However, it is noted that this method will only work for coins that allow non-standard scripts, as it violates the standard output script assumption. There was initial focus on maintaining standard scripts on the altcoin, but the non-standard script approach is considered an improvement over the cut and choose method.In a previous email conversation on February 12, 2016, the possibility of creating a new opcode for an altcoin was discussed. However, it was later determined that the altcoin would only accept standard output scripts. As a result, the suggestion of paying to a non-standard script instead was considered an improvement over the previous method of cut and choose. It is mentioned that this approach would only work for coins that allow non-standard scripts. The focus then shifted to maintaining standard scripts on the altcoin.A new BIP draft proposed by Tier Nolan via the bitcoin-dev mailing list discusses using CLTV for cross-chain transfers. Many altcoins do not support CLTV, making the transfer insecure. Therefore, the proposed protocol doesn't require any new opcode and uses cut and choose to allow commitments to publish private keys. However, it is acknowledged that this protocol is clunky and not entirely secure. The proposed protocol involves four steps where Bob trades bitcoins for altcoins with Alice. The BIP CPRKV, Check Private Key Verify, allows outputs to be locked until a private key is published that matches a given public key. The BIP CPRKV is available on GitHub, and the email sender ensured the safety of their computer.The email conversation also explores the possibility of increasing the sigop count for a NOP without using segwit. It is determined that this would be a soft fork, as it makes previously allowed actions disallowed. The increased sigop count would be valid under both old and new rules, without requiring specific support on the altcoin. This allows the Bitcoin network to act as a trusted third party for safe use of channels on the altcoin, despite its malleability issues and lack of OP_CHECKLOCKTIMEVERIFY. In regards to seg-witness, the ideal scenario would be repurposing OP_NOP3 to work in both old and new scripts.Overall, these discussions among Bitcoin developers highlight various proposals and considerations regarding the use of CLTV for cross-chain transfers, the introduction of new opcodes, the improvement of scripting for the lightning network, and the potential impact on soft-fork slot usage. diff --git a/static/bitcoin-dev/April_2016/combined_Bitcoin-Core-0-12-1-release-candidate-1-available.xml b/static/bitcoin-dev/April_2016/combined_Bitcoin-Core-0-12-1-release-candidate-1-available.xml index 97e72ff1d5..ff95e06eb7 100644 --- a/static/bitcoin-dev/April_2016/combined_Bitcoin-Core-0-12-1-release-candidate-1-available.xml +++ b/static/bitcoin-dev/April_2016/combined_Bitcoin-Core-0-12-1-release-candidate-1-available.xml @@ -2,7 +2,7 @@ 2 Combined summary - Bitcoin Core 0.12.1 release candidate 1 available - 2025-09-26T15:37:32.505000+00:00 + 2025-10-11T21:47:36.137233+00:00 python-feedgen Wladimir J. van der Laan 2016-04-11 09:12:13+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Bitcoin Core 0.12.1 release candidate 1 available - 2025-09-26T15:37:32.505128+00:00 + 2025-10-11T21:47:36.137425+00:00 2016-04-11T09:12:13+00:00 Wladimir J. van der Laan has released an updated version of Bitcoin Core, rc2, following the previous release candidate, rc1, being deemed "DOA" in meeting minutes from Thursday. The binaries for the updated version can be found at https://bitcoin.org/bin/bitcoin-core-0.12.1/test.rc2/, while the source code is available on Github at https://github.com/bitcoin/bitcoin/tree/v0.12.1rc2.This new release candidate, 0.12.1rc2, includes the BIP9, BIP68, and BIP112 softfork, along with various bugfixes and updated translations. Detailed release notes for this version can be accessed at https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md. It is important to note that release candidates serve as test versions for releases, and if no critical problems are discovered, this release candidate will become the official 0.12.1 release.Additionally, the previous release candidate, 0.12.1rc1, is also available for testing purposes. The binaries for this version can be downloaded from https://bitcoin.org/bin/bitcoin-core-0.12.1/test.rc2/, and the corresponding source code can be found on Github under the signed tag at https://github.com/bitcoin/bitcoin/tree/v0.12.1rc1. The 0.12.1rc1 release candidate includes the BIP9, BIP68, and BIP112 softfork, bugfixes, and updated translations. Preliminary release notes for this version can be accessed at https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md.As with any software, it is important to report any bugs or issues encountered during testing. Users can report bugs using the issue tracker on Github at https://github.com/bitcoin/bitcoin/issues. By actively engaging with the Bitcoin community and contributing to bug reporting, users can help improve the quality and stability of future releases. diff --git a/static/bitcoin-dev/April_2016/combined_Proposal-to-update-BIP-32.xml b/static/bitcoin-dev/April_2016/combined_Proposal-to-update-BIP-32.xml index 675bb55fc0..7dcd4f195d 100644 --- a/static/bitcoin-dev/April_2016/combined_Proposal-to-update-BIP-32.xml +++ b/static/bitcoin-dev/April_2016/combined_Proposal-to-update-BIP-32.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposal to update BIP-32 - 2025-09-26T15:37:34.617840+00:00 + 2025-10-11T21:47:38.259001+00:00 python-feedgen Gregory Maxwell 2016-05-08 11:09:45+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Proposal to update BIP-32 - 2025-09-26T15:37:34.618013+00:00 + 2025-10-11T21:47:38.259185+00:00 2016-05-08T11:09:45+00:00 On May 8, 2016, Pavol Rusnak reached out to the bitcoin-dev mailing list seeking Sipa's opinion on a proposed fix. Marek Palatinus also requested Sipa's input and expressed support for the proposal. However, since Sipa had not been active on the mailing list, he did not receive the message.In an email exchange between Eric Lombrozo and Jochen Hoenicke, they discussed the probability of a specific case of BIP32 triggering. They concluded that the likelihood of it happening is incredibly small at 2^-128. While many have been using BIP32 for years, some app developers feel that dealing with this level of complexity is not worth the effort. However, if handling the case is easy to implement and isolate in program flow, Lombrozo would be in favor of implementing a solution. The idea is to handle the problem in the library so app developers don't have to worry about missing addresses or ignore the issue. This could be achieved by having the library retry instead of returning an error.On April 21, 2016, Eric Lombrozo raised a concern on bitcoin-dev regarding the handling of cases where the BIP-32 derivation path is invalid. This issue is further complicated by limited software performing these checks. Additionally, even if a check is performed, handling the exception can be challenging as skipping may not always be an option. The motivation behind addressing this issue is to enable BIP-32 usage for non-secp256k1 curves such as the NIST P-256 curve with a chance of 2^-32. An example of an invalid BIP-32 path was found by Jochen at m/28578'/33941 derived from a hexadecimal seed.Jochen Hoenicke proposed an update to BIP-32, suggesting that if the computed hash is larger or equal to the prime or 0, the node should be considered invalid and skipped in the BIP-32 tree. He recommended modifying the procedure by repeating the hashing with slightly different input data until a valid private key is found. This way, the library will always return a valid node for all paths. Jochen believes that the chance of this affecting anyone is less than 10^-30 and that backward compatibility issues are minimal. However, many app developers feel that dealing with this complexity may not be worth the effort. Nevertheless, if the handling of this case is simple to implement and isolate in the program flow, Jochen is in favor of making changes.The proposal suggests updating BIP-32 to make it easier for developers to use. Currently, the specification requires all callers of CKDpriv or CKDpub to check for errors when the computed hash is larger or equal to the prime or zero, and handle these errors appropriately. This places an additional burden on application developers instead of being able to handle it within the BIP-32 library. Furthermore, it is unclear how to proceed if an intermediate node is missing. The suggestion is to repeat the hashing with slightly different input data until a valid private key is found. This approach ensures that the library always returns a valid node for all paths, avoiding issues encountered with the original version. The proposal also includes suggestions for updating the derivation functions and root node derivation from the seed. While there may be minimal backward compatibility issues, the author believes that the benefits of the update outweigh any potential consequences. The post concludes with questions regarding how to update the BIP and which algorithm is preferred for implementation. diff --git a/static/bitcoin-dev/April_2016/combined_p2p-authentication-and-encryption-BIPs.xml b/static/bitcoin-dev/April_2016/combined_p2p-authentication-and-encryption-BIPs.xml index 311142a598..f281f51422 100644 --- a/static/bitcoin-dev/April_2016/combined_p2p-authentication-and-encryption-BIPs.xml +++ b/static/bitcoin-dev/April_2016/combined_p2p-authentication-and-encryption-BIPs.xml @@ -2,7 +2,7 @@ 2 Combined summary - p2p authentication and encryption BIPs - 2025-09-26T15:37:28.284156+00:00 + 2025-10-11T21:47:31.804790+00:00 python-feedgen Jonas Schnelli 2016-05-25 09:36:24+00:00 @@ -97,10 +97,11 @@ + 2 Combined summary - p2p authentication and encryption BIPs - 2025-09-26T15:37:28.284351+00:00 + 2025-10-11T21:47:31.804949+00:00 2016-05-25T09:36:24+00:00 The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, diff --git a/static/bitcoin-dev/April_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml b/static/bitcoin-dev/April_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml index 673f15a456..f2b8e2802f 100644 --- a/static/bitcoin-dev/April_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml +++ b/static/bitcoin-dev/April_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - segwit subsidy and multi-sender (coinjoin) transactions - 2025-09-26T15:37:26.173862+00:00 + 2025-10-11T21:47:29.682859+00:00 python-feedgen Peter Todd 2016-05-03 02:05:11+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - segwit subsidy and multi-sender (coinjoin) transactions - 2025-09-26T15:37:26.173998+00:00 + 2025-10-11T21:47:29.683047+00:00 2016-05-03T02:05:11+00:00 Kristov Atlas, a developer, has shared a sample of 16 transaction IDs from the BitcoinTalk thread on JoinMarket. These transactions reveal an average ratio of 1.38 outputs to inputs. Atlas points out that this situation is unsustainable because eventually the change needs to be combined again or else the unspent transaction outputs (UTXOs) will not get spent. However, the advantage of segwit discount for CoinJoin transactions is that it makes spending UTXOs cheaper and recovers funds that would otherwise be lost to dust.In a discussion on bitcoin-dev about the impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones, Kristov Atlas raises the question of whether this subsidy serves as a financial disincentive against CoinJoin transactions. It is noted that CoinJoin transactions do not necessitate any specific behavior that would be affected by this subsidy. Normal transactions spend a coin and create a payment of a specified amount along with change, and CoinJoins are no different in this regard. While users may sometimes split their outputs to enhance privacy, resulting in the "more outputs" effect, this alone does not increase costs under segwit. The total cost for a user to create an output paying themselves includes both the cost of creation and the eventual cost of spending it. Segwit's cost calculation improvements shift some relative cost from spending to creation, but the same users pay for both. It is important to consider where other transactions are when evaluating the output to input ratio for self-sends. For example, in block 409711, there is an average of 1.4647 outputs per input, although this figure varies across different blocks.Regarding the sample of the 16 transaction IDs posted in the JoinMarket thread on BitcoinTalk, which showed an average ratio of 1.38 outputs to inputs, it is pointed out that it is strange to state this as a fact right after providing data that disproves it. The author also requests that people refrain from discussing Schnorr signatures since they are not currently part of any immediate roadmap. However, it is mentioned that Schnorr signatures for Bitcoin have been in development for years and are one of the first proposed uses of segwit versioning. Schnorr multisignature signature aggregates would significantly reduce the cost of CoinJoin transactions, and if there were any disincentive, it would be eliminated by planned use of segwit versioning.The impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones has raised questions. This subsidy makes signature data, which does not affect the size of the unspent transaction output (UTXO) set, 75% cheaper than data that does impact the UTXO set size. The expectation is that users will prefer transactions that minimize the impact on the UTXO set in order to reduce fees, and developers will design new features that also minimize this impact. While this could potentially act as a disincentive against CoinJoin transactions, it remains unclear if there is any evidence to support this claim. It is worth noting that traditional CoinJoin transactions typically create around two UTXOs for every one they consume, unless address reuse is involved. The author emphasizes that they do not wish to discuss Schnorr signatures in replies, as they are not currently part of any immediate roadmap. diff --git a/static/bitcoin-dev/April_2017/combined_A-different-approach-to-define-and-understand-softforks-and-hardforks.xml b/static/bitcoin-dev/April_2017/combined_A-different-approach-to-define-and-understand-softforks-and-hardforks.xml index 920cb78880..12da892711 100644 --- a/static/bitcoin-dev/April_2017/combined_A-different-approach-to-define-and-understand-softforks-and-hardforks.xml +++ b/static/bitcoin-dev/April_2017/combined_A-different-approach-to-define-and-understand-softforks-and-hardforks.xml @@ -2,7 +2,7 @@ 2 Combined summary - A different approach to define and understand softforks and hardforks - 2025-09-26T15:46:23.101364+00:00 + 2025-10-11T21:57:20.636440+00:00 python-feedgen Matt Corallo 2017-04-07 10:14:07+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - A different approach to define and understand softforks and hardforks - 2025-09-26T15:46:23.101546+00:00 + 2025-10-11T21:57:20.636671+00:00 2017-04-07T10:14:07+00:00 In a recent email on the bitcoin-dev mailing list, Johnson Lau has proposed a redefinition of the terminology surrounding hard and soft forks. Instead of focusing on changes to block validity, Lau suggests defining these terms based on software upgrade necessity and difficulty. Under this new system, soft forks would refer to consensus rule changes that non-upgraded software can still use, while hard forks would require upgraded software for proper functionality. Lau introduces the concept of "hardfork-ness," which represents a continuum between the two types of forks.According to Lau, this notion of hardfork-ness can be applied to various components of the Bitcoin network, including mining nodes, non-mining full nodes, fully validating wallets, and fake SPV wallets. The level of hardfork-ness can also be influenced by the costs associated with running a border node. For instance, certain consensus rule changes like BIP34, 65, 66, and CSV have minimal resource requirements, resulting in low hardfork-ness. On the other hand, proposals such as the extension block proposal pose high hardfork-ness for wallets because legacy wallets may experience sudden invalidation of transactions and need to resign them without any intention of double spending.Lau delves into other interesting scenarios, such as soft-hardforks, which entail miners mining empty blocks with zero rewards and placing the transaction merkle tree in the legacy coinbase. Although technically classified as softforks in terms of block validity, they function more like hardforks in practice. Additionally, Lau highlights the distinction between technically softforks, such as on-chain KYC, blacklist implementation, and account freezing, and their significant disruptive impact on user experience, making them akin to hardforks.Moreover, Lau emphasizes that both the Lightning Network and side chains do not necessitate consensus rule changes and have the potential to introduce new features without any hardfork-ness. These innovations offer opportunities for enhanced functionality within the Bitcoin ecosystem.Overall, Lau's proposal aims to redefine the terminology surrounding hard and soft forks based on software upgrade necessity and difficulty, introducing the concept of hardfork-ness as a continuum between the two. This approach allows for a more nuanced understanding of the impact and implications of various consensus rule changes within the Bitcoin network. diff --git a/static/bitcoin-dev/April_2017/combined_BIP-proposal-Inhibiting-a-covert-attack-on-the-Bitcoin-POW-function.xml b/static/bitcoin-dev/April_2017/combined_BIP-proposal-Inhibiting-a-covert-attack-on-the-Bitcoin-POW-function.xml index 1696ab312e..55a184ae9a 100644 --- a/static/bitcoin-dev/April_2017/combined_BIP-proposal-Inhibiting-a-covert-attack-on-the-Bitcoin-POW-function.xml +++ b/static/bitcoin-dev/April_2017/combined_BIP-proposal-Inhibiting-a-covert-attack-on-the-Bitcoin-POW-function.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP proposal: Inhibiting a covert attack on the Bitcoin POW function - 2025-09-26T15:45:49.421199+00:00 + 2025-10-11T21:57:14.229113+00:00 python-feedgen Erik Aronesty 2017-04-07 13:28:13+00:00 @@ -185,10 +185,11 @@ + 2 Combined summary - BIP proposal: Inhibiting a covert attack on the Bitcoin POW function - 2025-09-26T15:45:49.421495+00:00 + 2025-10-11T21:57:14.229369+00:00 2017-04-07T13:28:13+00:00 The discussion surrounding ASICBOOST and other mining optimizations in the Bitcoin community revolves around ethical implications, technical details, and potential impacts. One argument is that ASICBOOST reduces the amount of work needed to prove a certain amount of work has been done in Bitcoin's Proof of Work, but it is debated whether this qualifies as an attack. The debate also raises concerns about the ethical implications of keeping optimizations for oneself and how they could discourage growth and improvement of the Bitcoin protocol.There is a debate about implementing a system to invalidate covert ASICBOOST, with some miners resisting due to potential loss of mining revenue. The difficulty of implementing such a change is acknowledged, as it involves invalidating hardware or optimized bits. The concept of burn, which occurs regardless of successful mining, is also discussed, with suggestions of a burn-network to prevent burns by blocking transactions other than one's own. However, this approach is seen as weak, and there is no intention to roll back the blockchain like in the DAO fork.The discussion also focuses on Bitmain's claims regarding ASICBOOST support and the need for independent verification. There are proposals to inhibit covert attacks on the Bitcoin Proof of Work function, with scrutiny due to conflicts with other proposals. The feasibility and potential benefits of optimization techniques involving partial hash collisions in Merkle roots are examined, along with their compatibility with the stratum mining protocol.Concerns are raised about the incentive created by ASICBOOST to make blocks smaller, which is undesirable for the Bitcoin network. The complexity of the Proof of Work algorithm and the potential for unique optimizations that can be patented are also discussed. Simplifying the algorithm is suggested as a way to prevent hidden or unexpected optimizations. The conversation highlights the various viewpoints on ASICBOOST and its impact, with some arguing for its elimination to prevent unfair advantages and maintain network security, while others raise ethical concerns and potential negative impact on miners.Gregory Maxwell proposes updates to the Bitcoin protocol to inhibit covert forms of ASICBOOST mining, citing the reduction in work required and potential harm to the system. The ongoing conflict between Bitmain and Bitcoin developers over the use of ASICBOOST is compared to the DAO hack. There are arguments for and against blocking ASICBOOST, with some emphasizing the need for strong justification before changing the blockchain rules.Discussions also touch on other topics, such as potential security flaws in Bitcoin and proposals for soft fork solutions. A BIP draft is proposed to address ASICBOOST mining, aiming to inhibit covert usage that interferes with protocol improvements. Gregory Maxwell proposes a solution to a potential security problem caused by a design oversight in the proof of work function, suggesting a new consensus rule to prevent covert attacks.Overall, these discussions show ongoing efforts to address vulnerabilities, improve the Bitcoin protocol, and find a balance between fairness, network security, and the interests of miners. Proposed rules aim to sunset when no longer necessary and address potential vulnerabilities associated with non-covert forms. diff --git a/static/bitcoin-dev/April_2017/combined_Draft-BIP-Version-bits-extension-with-guaranteed-lock-in.xml b/static/bitcoin-dev/April_2017/combined_Draft-BIP-Version-bits-extension-with-guaranteed-lock-in.xml index feb77df33e..5efeb357a2 100644 --- a/static/bitcoin-dev/April_2017/combined_Draft-BIP-Version-bits-extension-with-guaranteed-lock-in.xml +++ b/static/bitcoin-dev/April_2017/combined_Draft-BIP-Version-bits-extension-with-guaranteed-lock-in.xml @@ -2,7 +2,7 @@ 2 Combined summary - Draft BIP: Version bits extension with guaranteed lock-in - 2025-09-26T15:46:06.262756+00:00 + 2025-10-11T21:57:18.511530+00:00 python-feedgen Kekcoin 2017-04-18 12:37:29+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - Draft BIP: Version bits extension with guaranteed lock-in - 2025-09-26T15:46:06.262918+00:00 + 2025-10-11T21:57:18.511658+00:00 2017-04-18T12:37:29+00:00 The proposed uaversionbits aims to simplify the activation process of BIP9 by introducing a boolean flag to ensure lock-in of a BIP9 deployment by the timeout. This allows for user-activated soft forks that can be activated early by the hash power. However, one criticism is the lack of a back-out procedure if a critical flaw is found after activation. To address this, the author suggests using a second version bit as an abandonment vote, which would require sufficient hashpower to abandon the protocol change. This changes the dynamic from BIP9's "opt-in" system to an "opt-out" system, still governed by hashpower but less susceptible to minority miner veto.In an email exchange between two individuals, it was challenged whether a misconfiguration could result in a stopped chain. The respondent clarified that this statement is only true for BIP9 soft forks. They explained that if rule changes are made at different times from the chain with the most work, there could be subjective hardfork-ness. This occurs when miners create blocks that the economic majority accepts despite having less restrictive rules than other chains. The segwit soft fork narrows the definition of a nonstandard transaction, and any block with a transaction violating cleanstack on a non-segwit chain would likely be considered malicious. However, they acknowledged that future forks may restrict more common things. In response to the suggestion of notifying users when a newly activated soft fork rule causes a block to be rejected, the respondent suggested that clients could make these decisions themselves.A discussion on the Bitcoin-dev mailing list revolved around the failure mode of a user's misconfiguration of nTimeout, which could result in a stopped chain. Praxeology Guy pointed out that this claim is incorrect since BIP9 only applies to soft forks and not hard forks. To have a stopped chain with a soft fork, a user must adopt more stringent rules while someone maliciously creates an invalid block that is valid to older nodes, and no miner ever mines a different block at the height of the block in question. Praxeology Guy also suggested that users should be notified when a newly activated more stringent soft fork rule causes a block to be rejected, as it could serve as an excellent trigger to enable replay attack prevention.The importance of understanding and properly configuring nTimeout to avoid potential issues with blockchain progress is highlighted. It is suggested that if less-sophisticated users are given these configuration settings, any chaintip progress failures resulting from them should be displayed prominently. Clear and visible notifications when such failures occur are emphasized, particularly for users who may not be as familiar with the technology.A proposal to orphan valid old blocks has been deemed unnecessary. The "lockinontimeout" variable has been extracted so that the same method can be used in future softfork proposals instead of hardcoding a special case hack for SegWit. Users are suggested to have the ability to set this variable in a configuration file, along with the "nTimeout" in "src/chainparams.cpp". This would allow users to expedite when a softfork becomes active on their node when combined with "lockinontimeout". Developers like the Core team could provide more conservative values in the program, while community members such as miners and nodes who feel strongly about SegWit could either compile their own settings or use a popular configuration file if available.The proposed BIP is an extension to BIP9 that introduces an additional activation parameter to guarantee the activation of backward-compatible changes, or soft forks. It aims to simplify the original uaversionbits proposal by introducing a boolean flag to ensure lock-in of a BIP9 deployment by the timeout. This combines optional flag day activation with BIP9, allowing for user-activated soft forks that can be activated early by the hash power. The specification adds a new per-chain deployment parameter to the existing BIP9 specification. A reference implementation of the proposed BIP is available on GitHub, and the document is licensed under BSD 3-clause and Creative Commons CC0 1.0 Universal. diff --git a/static/bitcoin-dev/April_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml b/static/bitcoin-dev/April_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml index c6730ba283..dd2511003a 100644 --- a/static/bitcoin-dev/April_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml +++ b/static/bitcoin-dev/April_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml @@ -2,7 +2,7 @@ 2 Combined summary - Extension block proposal by Jeffrey et al - 2025-09-26T15:45:47.303195+00:00 + 2025-10-11T21:57:12.105049+00:00 python-feedgen Christopher Jeffrey 2017-05-10 01:19:30+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - Extension block proposal by Jeffrey et al - 2025-09-26T15:45:47.303363+00:00 + 2025-10-11T21:57:12.105259+00:00 2017-05-10T01:19:30+00:00 A proposal has been made for an extension block that would allow atomic swaps between Bitcoin and Xbitcoin. However, there are concerns about the maturity rule and its impact on legacy wallets. Christopher Jeffrey suggests revising the extension block code to coexist with mainchain segwit and require exiting outputs to only be witness programs. This would mitigate the issue assuming most segwit-supporting wallets implement this rule before the activation of segwit.There is also discussion about allowing direct exit payments to legacy addresses and the lock-up period for exiting outputs. One solution is to add a maturity requirement for exiting outputs, but this would make non-upgraded wallets unusable. Another solution is to move all exiting outputs to the coinbase, but this would deteriorate user experience and essentially become a hardfork. It is suggested that switching to witness programs only and requiring exiting outputs to be witness programs may be a good balance between fungibility and backward-compatibility.The proposal also addresses the issue of making return outputs transparent to unupgraded wallets. The proposed solution is to send them to something non-standard today. The mainchain segwit is important in enabling atomic swaps between Bitcoin and Xbitcoin. The extension block specification/code is being revised to coexist with mainchain segwit and require exiting outputs to only be witness programs.In another discussion, Olaoluwa Osuntokun analyzes the xblock proposal and focuses on the sub-proposal for Lightning Network (LN) safety enhancement. The proposal involves a block-size decrease for each open channel within the network, which reserves space for honest parties to punish dishonest channel counter parties. There is also a proposal for a Pre-Allocated Smart-contract Dispute Arena (PASDA) to address systematic risks in the LN. However, the system has not been fully specified and evaluated yet.Overall, the discussions revolve around the proposed extension block, its compatibility with segwit, the issue of direct exit payments to legacy addresses, and the need for a balance between fungibility and backward-compatibility. The proposal also introduces additional safety measures for Lightning Network (LN) and blockchain availability in case of channel disputes.The writer of the context raises concerns about a new Bitcoin Improvement Proposal (BIP) and expresses disappointment that their proposal was not given more consideration. They criticize the lack of specificity in the proposed approach to resolving transaction malleability and suggest changes to how the merkle root is calculated. Additionally, they question whether direct exit payment to legacy addresses should be allowed and propose limiting the number of soft-fork upgrades, increasing the points for witness v0 outputs, and setting a higher dust threshold.A work-in-progress extension block proposal has been introduced by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. The proposal is available on Github and aims to increase bitcoin transaction throughput without altering existing consensus rules. However, the writer argues that extension blocks create additional complexity compared to other proposals and can potentially create two classes of "full nodes," leaving some insecure. They also mention potential issues with the maximum extension size and the validity of output script code in extension blocks.The Witness Vector specification details that every 73 bytes in the serialized witness vector is worth one additional point, but it doesn't explain why this number was chosen. The writer emphasizes the importance of submitting BIPs in MediaWiki format and for discussion on the bitcoin-dev mailing list rather than social media and news outlets. They assert that extension blocks are more like a hard-fork rather than a soft-fork and highlight the potential legal implications of BIPs not being recognized in certain jurisdictions.The UTXO set behaves fundamentally differently with the extension block proposal, but mostly in a compatible manner. Canonical blocks containing entering outputs must have an extension block commitment, even if it contains all zeroes. The writer suggests adding a special message to the genesis resolution transaction and mentions the possibility of including a witness vector using BIP141 transaction serialization within the extended transaction vector. They also note the enforcement of a consensus dust threshold within the extension block.The deployment name for this specification is "extblk" and appears as "!extblk" in GBT. The writer points out that while the start time for the deactivation deployment is mentioned, there is no information about the timeout or how to continue the extension block. They critique the lack of clarity and specificity in the new BIP and propose alternative solutions. Finally, they caution against specifying policy in BIPs and comment on the potential negative effects of deactivating unused chains. diff --git a/static/bitcoin-dev/April_2017/combined_Guessing-the-spentness-status-of-the-pruned-relatives.xml b/static/bitcoin-dev/April_2017/combined_Guessing-the-spentness-status-of-the-pruned-relatives.xml index 37b8ad7abb..f7ce98d284 100644 --- a/static/bitcoin-dev/April_2017/combined_Guessing-the-spentness-status-of-the-pruned-relatives.xml +++ b/static/bitcoin-dev/April_2017/combined_Guessing-the-spentness-status-of-the-pruned-relatives.xml @@ -2,7 +2,7 @@ 2 Combined summary - Guessing the spentness status of the pruned relatives - 2025-09-26T15:45:40.918868+00:00 + 2025-10-11T21:57:09.967159+00:00 python-feedgen Bram Cohen 2017-04-03 03:13:52+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - Guessing the spentness status of the pruned relatives - 2025-09-26T15:45:40.919007+00:00 + 2025-10-11T21:57:09.967314+00:00 2017-04-03T03:13:52+00:00 The scalability of Bitcoin transactions was discussed on the bitcoin-dev mailing list. It was noted that using spentness bits scales linearly compared to swapping digest leafs with empties, which can scale logarithmically but increases storage requirements. The limitation of 8 to 12 layers corresponds to an MMR proof length of 512 to 768 bytes if a 32-byte hash and spentness bits are used. However, making memory commitments smaller would increase CPU requirements and proof size. Full nodes can cache the top layers or remember a root per block to make proofs smaller.Using spentness bits in merkle tree hashes has limitations. Increasing the DLH_REQUIRED beyond 8 has diminishing returns. With a 32-byte hash and spentness bits, pruning is limited to 8 to 12 layers, resulting in an MMR proof length of 512 to 768 bytes. The growth rate of the MMR depends on the number of txos added. Adding 12E6 delayed utxo only txos per year leads to a growth of about 1.5MB (or 5MB) per year, while adding 200E6 txos per year leads to a growth of about 27.5MB (or 80MB) per year. This puts a limit on potential gains through pruning. Increasing the block size may require switching from spentness bits to changing digest nodes to empty nodes.In a discussion between Bram Cohen and Praxeology Guy, the idea of "The TXO bitfield" was presented. This idea suggests changing how the MMR data is modified on spend by moving from changing leaf nodes to changing a node closer to the root. This allows for commitments on the entire TXO set. However, Praxeology Guy still prefers the MMR structure if only UTxOs are added after a long delay. The index changes when delayed additions happen. Bram Cohen appreciated the idea and clarified that it is different from the Patricia Tree for bitcoin txos.Bram Cohen shared his approach to research and development, emphasizing the exploration of interesting ideas and collaboration before making decisions. He expressed his reservations about the Patricia Tree for bitcoin txos, stating that it may be too much work compared to other options. However, he clarified that he wasn't saying the design is bad or won't work but that he personally isn't interested in it at this time.The use of MMR data structure for transaction output (TXO) commitments was discussed in a Bitcoin development discussion. It was suggested that wallets should only keep information relevant to their own spendable coins and maintain the changing MMR proof for their old coins. However, wallets need to know the spentness status of close relatives in the MMR tree to construct a valid MMR proof. An alternative solution called the TXO bitfield was proposed, which would allow wallets to track only the proof of position of their TXO, avoiding the need to keep track of other data.In an email thread, a user suggested committed bloom filters as a solution to similar issues without needing a growing list of spent outputs. Praxeology Guy argued that wallets still need to know the spentness status of close relatives in the MMR tree to construct a valid MMR proof. Bitcoin nodes could keep a spentness status list to address this issue and prevent DoS attacks. However, there was some confusion in the email subject.In summary, the discussion on the scalability of Bitcoin transactions focused on the use of spentness bits and the limitations of the MMR data structure. Different proposals, such as the TXO bitfield and committed bloom filters, were put forward to address the challenges of tracking spent outputs and constructing valid proofs. Bram Cohen emphasized the importance of exploring ideas and collaborating in the research and development process. diff --git a/static/bitcoin-dev/April_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml b/static/bitcoin-dev/April_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml index 6b50bffc04..fb77a57b66 100644 --- a/static/bitcoin-dev/April_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml +++ b/static/bitcoin-dev/April_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml @@ -2,7 +2,7 @@ 2 Combined summary - Hard fork proposal from last week's meeting - 2025-09-26T15:46:04.147963+00:00 + 2025-10-11T21:57:16.357303+00:00 python-feedgen Staf Verhaegen 2017-04-02 19:12:06+00:00 @@ -329,10 +329,11 @@ + 2 Combined summary - Hard fork proposal from last week's meeting - 2025-09-26T15:46:04.148241+00:00 + 2025-10-11T21:57:16.357674+00:00 2017-04-02T19:12:06+00:00 The Bitcoin community has been engaged in ongoing discussions about the scalability of Bitcoin and the balance between on-chain scaling and layer two scaling. Some members argue that on-chain bandwidth should be available for layer two scaling to thrive and propose exploring sharding solutions. However, others emphasize the importance of individuals running full nodes on personal computers for security and challenge this assertion.The scalability of processing transactions in a distributed system like Bitcoin is a significant challenge. While network speeds have improved, there is still a debate about raising the block size limit. Some participants believe it is possible but risky, while others suggest waiting until SegWit activates before considering any additional increases.Running full nodes on personal computers is seen as crucial for the security of Bitcoin. There are discussions about the feasibility of running nodes and potential alternatives such as lightweight clients, zero-knowledge proofs, and hardware wallets. Maintaining the security of the Bitcoin network is highly dependent on personal computers.The importance of low node costs and the consequences of high transaction fees are also discussed. Some argue that a true fee-market is needed, where miners can choose to make blocks smaller to increase fees. However, increasing transaction fees may allow other cryptocurrencies to gain market share for low-value use cases. The market will continue to innovate solutions when there is profit to be made.The ongoing debate over block size increases involves different factions with differing opinions. It is crucial to carefully consider the impact on node costs and the potential burden on archival nodes. Before making any changes to the block size, implementing fixes and conducting studies are important steps.Overall, the Bitcoin community is actively discussing the scalability of Bitcoin, the importance of individuals running full nodes on personal computers for security, and the ongoing debate over on-chain scaling versus layer two scaling. The cost implications of running a node capable of handling massive transaction volumes are also being considered. In order to address these challenges and ensure the growth and security of Bitcoin, the community is exploring various solutions and technologies. diff --git a/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage.xml b/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage.xml index c5e12e604c..b3d84992d4 100644 --- a/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage.xml +++ b/static/bitcoin-dev/April_2021/combined_BIPs-notarization-protocol-and-decentralized-storage.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIPs - notarization protocol and decentralized storage - 2025-09-26T15:44:35.771836+00:00 + 2025-10-11T21:56:57.212645+00:00 python-feedgen Luke Dashjr 2021-04-25 18:29:21+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - BIPs - notarization protocol and decentralized storage - 2025-09-26T15:44:35.771990+00:00 + 2025-10-11T21:56:57.212779+00:00 2021-04-25T18:29:21+00:00 During a discussion on Bitcoin development, the topic of decentralized storage for Bitcoin projects was brought up. Prayank suggested that instead of using a Bitcoin Improvement Proposal (BIP), it may be more appropriate to create a Lightning Network (LN) project. Luke added to the conversation by suggesting that LN should actually consist of a collection of BIPs, highlighting the need for further standardization proposals.Prayank emphasized the importance of implementation or proof of concept code in the BIP, and proposed that it could just be an LN project instead. They shared some relevant links related to decentralized storage, including bkiac/tarnhelm and ElementsProject/filebazaar. Prayank explained that their idea of decentralized storage for Bitcoin projects involves using torrents for files and communication with Tor. They also suggested the inclusion of an easy-to-use API for saving, reading, editing, etc., specifically for Bitcoin projects utilizing torrents. Payments through the Lightning Network would only be involved when spamming becomes an issue.Christopher expressed agreement with Prayank's suggestion of defining an API for both proposals and keeping it in a separate document from the BIPs. He also agreed with Prayank's opinion on the use of Tor. Christopher mentioned that he has been using the BIP format for his proposals, including the one being discussed, as well as other BIPs he is currently working on. However, he expressed openness to changing the format if it is decided that there is a better one for these BIPs. Christopher also brought up the incentivized moderation protocol, which is mentioned in the BIP under consideration.The writer of the context is conducting research on decentralized storage for a Bitcoin project and expresses interest in the concept. They suggest that including implementation or proof of concept code in the BIP would have been preferable, but since it involves the Lightning Network, it could potentially be its own LN project. The writer provides two links, bkiac/tarnhelm and ElementsProject/filebazaar, as potentially helpful resources for Christopher. They also explain their belief that decentralized storage utilizing torrents with Tor can be beneficial for Bitcoin projects. The writer proposes the creation of an easy-to-use API for various functions in Bitcoin projects using torrents, with payments through the Lightning Network only being involved when spamming becomes a concern. Additionally, they share a link to a project called JoinMarket-Org/joinmarket-clientserver/issues/415, which explores similar options. diff --git a/static/bitcoin-dev/April_2021/combined_Fee-estimates-and-RBF.xml b/static/bitcoin-dev/April_2021/combined_Fee-estimates-and-RBF.xml index 49334697a4..17d71da447 100644 --- a/static/bitcoin-dev/April_2021/combined_Fee-estimates-and-RBF.xml +++ b/static/bitcoin-dev/April_2021/combined_Fee-estimates-and-RBF.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fee estimates and RBF - 2025-09-26T15:45:01.041516+00:00 + 2025-10-11T21:57:07.836621+00:00 python-feedgen ZmnSCPxj 2021-05-18 13:10:12+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Fee estimates and RBF - 2025-09-26T15:45:01.041704+00:00 + 2025-10-11T21:57:07.836812+00:00 2021-05-18T13:10:12+00:00 Implementing Replace-By-Fee (RBF) in financial code presents challenges in exception handling and testing reorgs. Thorough testing is necessary, but code with many branches due to handling exceptions is difficult to cover completely. C-lightning supports RBF, but potential edge cases may cause mishandling of replaced transactions and loss of onchain funds. The combination of RBF and Child-Pays-for-Parent (CPFP) has yet to be explored fully, with potential use cases like the maker-taker model requiring careful exception handling.In a discussion on Bitcoin Stack Exchange, Jeremy and ZmnSCPxj share their thoughts on fee estimation. The recent CVE related to RBF by Antoine Riard and the differences between RBF implementation in Bitcoin Core and btcd are also discussed. However, the reasoning behind not implementing inherited signalling in Bitcoin Core remains unclear.In an email exchange, ZmnSCPxj and Prayank discuss engineering issues related to a full RBF wallet. While ZmnSCPxj believes a true full-RBF wallet should be the goal, he acknowledges the engineering challenges. He explains the process of a true full-RBF wallet and warns about race conditions when miners find new blocks while fees are being bumped. The wallet needs to track "pending spends" and correlate them with actual transactions. ZmnSCPxj also notes that spending unconfirmed inputs may not be safe due to conflicting transactions. Engineering issues pose significant challenges in achieving a true full-RBF wallet.The author of the message agrees that a "true" full-RBF wallet should be the goal for every on-chain wallet but notes the difficulties in achieving this. They explain how some wallets handle unconfirmed inputs and the simplification of database design. To achieve a true full-RBF wallet, the wallet must keep track of pending spends and correlate them with actual transactions. The author admits they have not considered all factors related to this issue.Jeremy Rubin shares a link with Prayank explaining the concept of a "fee-only" wallet. This feature allows users to arrange fee bumps using a separate wallet without disturbing on-chain dependents. It can be cheaper than RBF since users are not subject to the feerate improvement rule. Rubin suggests creating a market via LN for transaction inclusion by a particular date. Prayank raises concerns about different estimations used in wallets and proposes a three-step approach: showing mempool stats, leaving the fee rate decision to the user, and using RBF algorithms for automated bidding.In an email exchange, Jeremy Rubin shares a post on Bitcoin-dev related to background services. He highlights the potential of a separate fee-only wallet for arranging fee bumps without disturbing on-chain dependents. He suggests it could be cheaper than RBF and discusses the idea of creating a market for transaction inclusion. Prayank discusses different fee estimations and suggests sharing mempool stats and allowing users to decide the fee rate. He proposes using RBF algorithms and wonders if the proposed approach would work offline.The writer begins with personal well-being and recovery from COVID-19 before discussing Bitcoin transactions and fee estimations. They question the use of different estimations and propose showing mempool stats and allowing users to decide on the fee rate. They compare this to estimating buy orders in the BTCUSD orderbook. The writer finds current estimations misleading and suggests a three-step approach, including RBF algorithms for automated bidding. They seek input on the proposed approach and provide an example of replacing transactions with different fee rates even when offline. diff --git a/static/bitcoin-dev/April_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml b/static/bitcoin-dev/April_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml index 8bec6b2da4..a255bc6ede 100644 --- a/static/bitcoin-dev/April_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml +++ b/static/bitcoin-dev/April_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml @@ -2,7 +2,7 @@ 2 Combined summary - March 23rd 2021 Taproot Activation Meeting Notes - 2025-09-26T15:44:42.088276+00:00 + 2025-10-11T21:57:01.460037+00:00 python-feedgen Anthony Towns 2021-04-08 11:11:06+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - March 23rd 2021 Taproot Activation Meeting Notes - 2025-09-26T15:44:42.088472+00:00 + 2025-10-11T21:57:01.460208+00:00 2021-04-08T11:11:06+00:00 In recent discussions on the bitcoin-dev mailing list, the focus has been on establishing developer and user consensus for Bitcoin. One suggestion is to create a contingency plan for a chain split, which some argue is good preparation. However, others believe that this approach does not address the underlying issue of consensus. The ideal scenario would allow users to download any version of bitcoind and run it with default settings, confident in the validity of their payments. Third-party explorers can track invalid chains, but these measures are only useful after a split has occurred. The risk of a split is higher during an attack on Bitcoin. Suggestions like lockinontimeout have been made, but they are not seen as the ideal solution. Businesses accepting Bitcoin payments need to know what software to run to stay in consensus with the network. Streamlining the consensus-building process is crucial. One possible solution is to implement an approach dealing with miners who don't upgrade to enforce a soft-fork quickly.Another thread discussed the Signet-based Taproot activation proposal. Different opinions were expressed regarding whether to use a Lot=false compromise or embrace brinkmanship tooling. Some argued that de-escalation in the strategy toolkit makes Bitcoin stronger, while others disagreed and emphasized the lack of agreement on a grand plan. Downsides of using LOT=true were mentioned, including dropping blocks from apathetic miners and the risk of a split. However, tracking economic majority is already possible based on previous experiences. The disagreement continued regarding the normalization of brinkmanship, with some members highlighting the need to optimize for a reliable Bitcoin and avoid strife.Claus Ehrenberg suggested that Taproot should be activated if either miners or users decide for it, with a chain split as the fairest way to resolve conflicts. Rusty Russell proposed the Speedy Trial approach, pretending that miners were not asked, and letting users ultimately decide. Preparation for a UASF branch along with ST was also discussed.The Bitcoin development community discussed the implementation of Taproot and parameter selection for an upcoming release. They targeted a May 1st release date and discussed the use of block heights or MTP for signaling periods. The team considered the advantages and disadvantages of each approach and adjusted the timing and other parameters based on preferences and technical considerations.Jeremy Rubin accused Michael Folkson of being disingenuous in his response and disagreed with his rejection of MTP-based ST. Folkson expressed his preference for consistent use of block heights and rejected the idea of using a mix of block heights and MTP in the same activation mechanism.Overall, the discussions revolve around finding the best approach to establish consensus for Bitcoin, activate Taproot, and handle potential challenges such as chain splits and miners failing to upgrade. The community aims to optimize the decision-making process, ensure payment validity, and strengthen the Bitcoin network.During a recent meeting on the activation mechanism for Taproot, there was a discussion about using block heights consistently or a mix of block heights and MTP. Michael Folkson preferred consistent use of block heights and disagreed with using a mix. The meeting also addressed the use of a speedy trial variant, which received no new objections. However, there was uncertainty about Rusty Russell's objection and whether it remains if sufficiently addressed.There was no consensus reached on selecting between block heights and MTP. Parameter selection discussions included targeting a May 1st release, specific start and stop times, and activation height proposals. It was agreed that November 15th should remain a target date, with limited belief that the release could be stretched into June if necessary.Simultaneous User Activated Soft Fork (UASF) was also discussed, with luke-jr suggesting that a UASF client must be able to release before the Taproot client. However, this sentiment was not shared by others, and it was agreed that a UASF can proceed independently of Taproot. Additionally, luke-jr objected to using MTP in combination with Taproot, while Jeremy Rubin objected to using block heights, citing concerns about avoiding contentious forks. diff --git a/static/bitcoin-dev/April_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml b/static/bitcoin-dev/April_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml index 18a1d3cdca..84e7723acf 100644 --- a/static/bitcoin-dev/April_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml +++ b/static/bitcoin-dev/April_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml @@ -2,7 +2,7 @@ 2 Combined summary - Reminder on the Purpose of BIPs - 2025-09-26T15:44:39.970908+00:00 + 2025-10-11T21:56:59.336541+00:00 python-feedgen Prayank 2021-09-15 09:50:34+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - Reminder on the Purpose of BIPs - 2025-09-26T15:44:39.971054+00:00 + 2025-10-11T21:56:59.336700+00:00 2021-09-15T09:50:34+00:00 During a recent meeting, the suggestion to decentralize the Bitcoin Improvement Proposals (BIPs) process was made in response to the lack of participation and discussion. The proposal aims to create multiple BIP directories to reduce dependency on one repository or a few individuals. While documentation is important, the focus should be on implementation.An example was given to demonstrate this point. Greg Maxwell proposed a solution to the mirroring issue of decentralized BIPs. He suggested assigning each BIP a genesis transaction ID that moves in time on the blockchain and mirrors the evolution in Git using commit hashes. This would provide a definitive HEAD of a BIP and its history, which can be reconstructed from any one transaction. Commit trees can be mirrored and hosted on popular sites like Github or Gitlab. The proposal also includes assigning BIP numbers in the Bitcoin repository and requiring spending money on transactions to prevent sybil attacks.David A. Harding recommended changes to the BIP process. His recommendations include adding more BIP editors, seeking the resignation of Luke Dashjr as BIP editor, and treating protocol documents outside the BIPs repository as first-class BIP documentation. He proposed an alternative to the BIPs system where anyone writing protocol documentation can post their idea to the mailing list and assign themselves a unique decentralized identifier starting with "bip-". Implementations of BIPs would link to the relevant protocol documentation. Harding's proposal aims to address issues such as users considering documents in the BIPs repo as authoritative and development teams wanting control over their own documentation.Matt Corallo criticized the BIP process, calling it a failure. W.J. van der Laan suggested decentralizing the process and adding more editors to address the bottleneck in open pull requests. Corallo also expressed frustration towards the community for irrational debates and ignoring input. The debate highlighted the need for a more decentralized approach to the BIP process.Luke Dashjr responded to accusations of deliberately refusing changes to BIPs. He denied the claims and stated that he follows the currently-defined process neutrally, despite being harassed by certain advocates. Dashjr proposed adding Kalle Alm as a BIP editor, but Antoine Riard suggested that the BIP editorship should have its own repository and follow procedural forms.Overall, there is ongoing discussion and debate about the BIP process and how it can be improved to better serve the Bitcoin community.In recent years, there has been a significant increase in the use of artificial intelligence (AI) in various industries. AI is a branch of computer science that focuses on creating intelligent machines capable of performing tasks that typically require human intelligence. It involves the development of algorithms and models that allow computers to learn from and adapt to data.One industry that has greatly benefited from the use of AI is healthcare. AI has the potential to revolutionize healthcare by improving diagnosis, treatment, and patient care. For example, AI algorithms can analyze large amounts of medical data to identify patterns and make predictions, helping doctors make more accurate diagnoses and develop personalized treatment plans. AI can also be used to monitor patients remotely, providing timely intervention and reducing the need for hospital visits.Another area where AI is making a significant impact is transportation. Self-driving cars, powered by AI technology, have the potential to reduce accidents and improve road safety. These cars are equipped with sensors and cameras that allow them to navigate and make decisions based on real-time data. AI algorithms enable the car to interpret the environment and react accordingly, ensuring a smooth and safe ride.AI is also being used in the finance industry to automate processes and enhance decision-making. For instance, AI-powered chatbots can assist customers with basic banking tasks, such as checking account balances or transferring funds. AI algorithms can also analyze financial data to detect fraud and identify investment opportunities. Additionally, AI can help financial institutions streamline operations and improve customer service through personalized recommendations.The retail industry has also embraced AI to enhance customer experience and optimize business operations. AI-powered recommendation systems analyze customer preferences and behavior to provide personalized product suggestions. This not only improves customer satisfaction but also increases sales. AI can also be used to automate inventory management, pricing strategies, and supply chain optimization, leading to cost savings and improved efficiency.In conclusion, AI is revolutionizing various industries, including healthcare, transportation, finance, and retail. Its ability to analyze large amounts of data, make predictions, and automate processes is transforming how these industries operate. As AI technology continues to advance, it is expected to have an even greater impact in the future, driving innovation and improving efficiency across multiple sectors. diff --git a/static/bitcoin-dev/April_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-13th-April-19-00-UTC.xml b/static/bitcoin-dev/April_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-13th-April-19-00-UTC.xml index f77c213771..1dd31fb35c 100644 --- a/static/bitcoin-dev/April_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-13th-April-19-00-UTC.xml +++ b/static/bitcoin-dev/April_2021/combined_Taproot-activation-meeting-on-IRC-Tuesday-13th-April-19-00-UTC.xml @@ -2,7 +2,7 @@ 2 Combined summary - Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC - 2025-09-26T15:44:58.927693+00:00 + 2025-10-11T21:57:05.711881+00:00 python-feedgen Billy Tetrud 2021-04-12 19:39:13+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC - 2025-09-26T15:44:58.927869+00:00 + 2025-10-11T21:57:05.712061+00:00 2021-04-12T19:39:13+00:00 BitcoinMechanic has announced an upcoming Taproot activation meeting on Tuesday, April 13th at 19:00 UTC. The purpose of the meeting is to ratify the Taproot activation plan that was previously discussed in a meeting held on March 16th. This plan, also known as 2021-03 Plan Y, will be the main focus of the upcoming meeting.While there was no consensus reached on the LOT parameter, there appears to be agreement on other parameters, such as BIP8. Additionally, there is sufficient support for LOT=True to proceed with activation safely. Miners will have a period of 18 months to signal and accelerate the activation process. If they fail to do so, Taproot will activate regardless.The activation plan aims to ensure the eventual lock-in of Taproot with the least possibility of a chain split. This is important as the majority of the economy is running on Taproot. The channel for ongoing discussion related to Taproot activation remains open 24/7, allowing participants to engage in discussions even outside of the scheduled meeting time. To facilitate communication, a web chat client is available for use.Michael Folkson, a key figure in the Bitcoin community, has expressed his intention to attend the Taproot activation meeting. He encourages other reviewers to carefully review Core PR #21377. In the event that this pull request is merged into Core, Folkson recommends any alternative release to be fully compatible with the activation parameters outlined in Core.The meeting organized by Bitcoin Mechanic will also cover discussions on an alternative release to Core with Taproot activation code. It will involve deciding when Core should no longer be considered in the process. Detailed contact information for Michael Folkson is provided for further inquiries or correspondence.Interested parties can find the meeting details sent via email by Bitcoin Mechanic, using ProtonMail Secure Email. A summary of the previous meeting is also available through the provided link, offering additional context for those interested in the Taproot activation discussions. diff --git a/static/bitcoin-dev/April_2021/combined_maximum-block-height-on-transaction.xml b/static/bitcoin-dev/April_2021/combined_maximum-block-height-on-transaction.xml index 14e7d0a5a0..3e280c1899 100644 --- a/static/bitcoin-dev/April_2021/combined_maximum-block-height-on-transaction.xml +++ b/static/bitcoin-dev/April_2021/combined_maximum-block-height-on-transaction.xml @@ -2,7 +2,7 @@ 2 Combined summary - maximum block height on transaction - 2025-09-26T15:44:46.286344+00:00 + 2025-10-11T21:57:03.584930+00:00 python-feedgen ZmnSCPxj 2021-05-03 02:30:07+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - maximum block height on transaction - 2025-09-26T15:44:46.286506+00:00 + 2025-10-11T21:57:03.585129+00:00 2021-05-03T02:30:07+00:00 The email thread on the bitcoin-dev mailing list discusses the issue of increasing CPU usage and code complexity when adding a field or opcode to transactions. It proposes a solution involving a "hidden" field in a transaction with a default value compatible with pre-softfork rules, along with an opcode that manipulates this field. Additionally, the proposal suggests implementing a maximum block height on transactions using a new field and opcode. This functionality allows users to be safely offline at the time of timeout in any complicated timeout-based contract. However, it also increases risk for the contractor holding lien on the hashlock branch in a two-participant contract, making the proposal less significant improvement to Bitcoin.Satoshi's statement about the inability to safely implement OP_BLOCKNUMBER is brought up in the discussion. One user suggests that software could be written to warn users about edge cases, arguing that if a person waits for 6 blocks before accepting a transaction as confirmed, there should be no likely scenario where any finalized transaction needs to be reverted. They believe that any transaction with 5 or fewer confirmations should be considered fair game for reversal. The possibility of buggy software is not seen as a good reason to block an opcode. Another user suggests using two transactions, one with a desired expiry at H and another with nlocktime H, to accomplish the goal of a rough expiry. After a timeout, participants in the first transaction can cancel the action using the second transaction. However, limiting the maximum block height for a specific transaction would have the same problem as cited above for OP_BLOCKNUMBER. A third user asks if there is any way to specify a maximum block height on a transaction and considers it useful. The discussion emphasizes the risks and limitations of implementing OP_BLOCKNUMBER. It is noted that limiting the maximum block height for a specific transaction would face the same problem as OP_BLOCKNUMBER in the event of a blockchain reorganization. Instead, nTimeLock is suggested as an alternative solution. nTimeLock is an open transaction that can be replaced with new versions until the deadline. It could be used to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. While nTimeLock is not currently enabled or used, the support for its implementation is available.In response to the discussion, a user suggests accomplishing a rough goal by using tx A with a desired expiry at H and then using tx B with nlocktime H and creating outputs equivalent to inputs. After a timeout, participants in tx A can cancel the action using tx B. However, the effectiveness of this approach depends on the use case and further clarification is needed.The possibility of specifying a maximum block height on a transaction is raised during a discussion on the bitcoin-dev mailing list. However, it is pointed out that such a feature would encounter the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorganization. As an alternative, nTimeLock is suggested. This open transaction can be replaced with new versions until the deadline, and the highest version at the deadline is recorded. It can be utilized for escrow transactions that automatically lock and proceed unless revoked before the deadline. Although nTimeLock is not currently enabled or used, the necessary support exists for its future implementation.A user on the Bitcoin development mailing list inquires about the possibility of specifying a maximum block height for a transaction. However, it is noted that implementing such a feature would present the same issue as the OP_BLOCKNUMBER transaction, which becomes invalid during a blockchain reorganization. Instead, an alternative option called nTimeLock is proposed. nTimeLock allows for an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is then recorded. This feature could be used for escrow transactions that automatically lock and proceed unless revoked before the deadline. While nTimeLock is not currently enabled or used, the necessary support exists for its implementation in the future.The inquiry regarding the possibility of specifying a maximum block height on a transaction is raised by a user. However, it is pointed out that this feature would face the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorg. An alternative suggestion is made to use nTimeLock, which is an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is recorded. This feature could be useful for creating escrow transactions that automatically lock and go through unless revoked before the deadline. While nTimeLock is currently not enabled or used, the support for its implementation is available. In conclusion, the discussions on the bitcoin-dev mailing list revolve around the issue of increasing CPU usage and code complexity when adding fields or opcodes to transactions. Various suggestions and alternatives are proposed, such as using hidden fields, implementing a maximum block height, and utilizing nTimeLock. The limitations of implementing OP_BLOCKNUMBER and the potential risks associated with each solution are thoroughly examined. Ultimately, any modification to diff --git a/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml b/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml index 2f25ea7884..1728a283a9 100644 --- a/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml +++ b/static/bitcoin-dev/April_2022/combined_Automatically-reverting-transitory-soft-forks-e-g-for-CTV.xml @@ -2,7 +2,7 @@ 2 Combined summary - Automatically reverting ("transitory") soft forks, e.g. for CTV - 2025-09-26T15:51:02.969283+00:00 + 2025-10-11T21:58:26.579627+00:00 python-feedgen ZmnSCPxj 2022-04-25 05:12:10+00:00 @@ -110,10 +110,11 @@ + 2 Combined summary - Automatically reverting ("transitory") soft forks, e.g. for CTV - 2025-09-26T15:51:02.969465+00:00 + 2025-10-11T21:58:26.579807+00:00 2022-04-25T05:12:10+00:00 In an email thread discussing the implementation of new features or opcodes in Bitcoin SCRIPT, a proposal is made to use real-world funds to prove demand. This involves using Smart Contracts Unchained and creating a mapping from Bitcoin SCRIPT opcodes to micro-opcodes. While this approach demonstrates real demand, there are concerns about security erosion and reliance on a federation. The possibility of reverting activated soft forks is discussed, but it is suggested that reverting without disrupting the network may not be possible. Concerns about specific covenant designs being discussed without actual implementations or sample usages are raised, with a suggestion to address this issue in the short-term. The focus of the discussion shifts to the implementation of covenants in Bitcoin, with arguments for and against CTV as the preferred design. The difficulty in choosing the "best" covenant design is acknowledged, along with the challenges and risks associated with doing a fork in Bitcoin. The lack of serious proposals other than CTV is noted, highlighting its simplicity and positive reviews. The potential uses of covenants, particularly vaults, are discussed, with CTV seen as a low-risk way to implement them. However, there is recognition of the need for more general covenant abilities and the time and effort required for their development. The practicality and utility of various covenant proposals are debated, with a preference for CTV due to its low-risk approach to vaulting. The criteria for adding a covenant to Bitcoin are outlined, including demonstrated use cases, alignment with Bitcoin's design, technical feasibility, and a well-reviewed implementation. The possibility of reverting to earlier consensus rules is also mentioned. The ongoing discussion about covenant designs is highlighted, with a lack of serious proposals other than CTV. The challenges of finding a preferable alternative and the need for complete specifications and tooling are discussed. Concerns about the long-term nature of CTV's use cases and its compatibility with a sunset period are raised. The suggestion is made to use CTV for most of the deployment to demonstrate real-world usage and convince others to make it permanent. Bitcoin developers discuss the best way to implement covenant functionality in Bitcoin, with no clear consensus on the best design. More data about user demand and usage is deemed necessary. The proposal of a transitory soft fork to activate different covenant designs is met with concerns about safety risks and recursion. Criticisms of CTV are discussed, including concerns about usage, maintenance burden, and the lack of consensus around concrete proposals for covenants. The need for real usage data and optimizing for demonstrated needs is emphasized. The risk and cost of doing a fork and the suggestion of adding "technical community consensus" as a factor in the process are also mentioned. The viability of the proposed BIP119 CTV is debated, with considerations of usage, maintenance burden, and consensus within the technical community. The importance of maintaining Bitcoin's culture of security and careful design is stressed. The possibility of modifying the witness discount in SegWit transactions through an additional soft fork is suggested, but concerns about potential confiscation of funds are raised. The variant of Speedy Trial being used and accusations of efforts to sabotage parallel UASF initiatives are also discussed. The importance of advocacy and improving logic is emphasized. The question of whether changes made by already activated soft forks can be reverted is raised, with suggestions for potential solutions. Concerns about increased weight making transactions invalid and criticism of the variant of Speedy Trial being used are expressed. The idea of making CTV an automatically reverting consensus change with an option to renew after five years is proposed. This allows experimentation with new features without permanent commitment. However, concerns about usage, maintenance burden, and the risk of losing money and potential miner censorship near the reversion date are raised. Alternative ways to activate CTV, such as a UASF client compatible with a speedy trial release, are suggested. The importance of allowing users to decide and preventing miner veto power is emphasized. Despite the downsides, an automatically reverting soft fork provides the opportunity to experiment with new features.The Bitcoin community expresses concerns about the future use of CTV due to maintenance and security issues. The proposal to automatically revert CTV as a consensus change after five years is discussed, allowing for experimentation without permanent commitment. However, there are potential risks such as the loss of funds and potential miner censorship. Further discussions on CTV are anticipated. A proposal is made to address criticisms against CTV by making it an automatically reverting consensus change with an option to renew, allowing for experimentation without permanent commitment. However, concerns about risks and potential miner censorship remain. Further discussions on CTV are expected. diff --git a/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml b/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml index dc60a21433..4e7139b7a6 100644 --- a/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml +++ b/static/bitcoin-dev/April_2022/combined_Vaulting-Was-Automatically-reverting-transitory-soft-forks-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Vaulting (Was: Automatically reverting ("transitory") soft forks) - 2025-09-26T15:51:07.201964+00:00 + 2025-10-11T21:58:30.831901+00:00 python-feedgen Billy Tetrud 2022-04-28 23:51:31+00:00 @@ -50,10 +50,11 @@ + 2 Combined summary - Vaulting (Was: Automatically reverting ("transitory") soft forks) - 2025-09-26T15:51:07.202111+00:00 + 2025-10-11T21:58:30.832073+00:00 2022-04-28T23:51:31+00:00 The discussion on the bitcoin-dev mailing list revolves around the benefits and tradeoffs of using multisig versus a wallet vault. Nadav Ivgi highlights the primary benefit of a vault, which is the ability to keep primary wallet keys in deep cold storage for enhanced security. On the other hand, Billy Tetrud argues that the purpose of a wallet vault is to gain the security of a multisig wallet without having to sign using as many keys. The conversation also delves into the COV proposal in MES, which allows users to check if an output's scriptPubKey matches the corresponding script item from the stack, while accommodating wildcard values. Signing the transaction with the hot wallet key removes third-party malleability.The discussions explore different setups and approaches to securing Bitcoin transactions. The use of a warmer model for covenant-encumbered two-step spending with more frequently used keys is suggested, while keeping primary keys in deep cold storage for increased security. The viability of a CTV vault where the hot key signer is a multisig is discussed, with some arguing that it does not offer the advantages of either wallet type. The COV proposal in MES allows checking if the output's scriptPubKey matches the corresponding script item from the stack, with wildcard values available. However, the signing of the transaction with the hot wallet key eliminates malleability issues.The conversation also touches on the limitations and risks associated with different vault schemes. The theft of a hot wallet key is highlighted as a security concern in CTV-based vaults, as it may not be immediately apparent that the key has been stolen. The MES vault scheme is compared to the CTV vault, with the former offering more advantages for managing payments through a vault. Fee management and less constrained covenant designs are identified as areas that could benefit from further exploration.In addition, there are discussions about the limitations and potential solutions to security issues in vault proposals. The theft of a hot key and the possibility of waiting for the user to unvault their funds are identified as concerns. Alternative solutions such as the OP_BEFOREBLOCKVERIFY opcode and encoding transactions with OP_POS and OP_CD are proposed. The MES vault design is mentioned as one that commits to the destination address during unvaulting, but this requires a less constrained covenant design. The CTV vault is acknowledged as potentially containing the damage from a hot key theft more effectively, but fee management remains an issue.Overall, the discussions highlight the advantages and disadvantages of different wallet vault setups and COV proposals in MES. The focus is on security concerns, risk management, and exploring alternative approaches to address limitations. diff --git a/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml b/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml index 0c8af9ddc7..05888c5952 100644 --- a/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml +++ b/static/bitcoin-dev/April_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml @@ -2,7 +2,7 @@ 2 Combined summary - What to do when contentious soft fork activations are attempted - 2025-09-26T15:51:05.086175+00:00 + 2025-10-11T21:58:28.705275+00:00 python-feedgen Jorge Timón 2022-05-07 01:57:39+00:00 @@ -46,10 +46,11 @@ + 2 Combined summary - What to do when contentious soft fork activations are attempted - 2025-09-26T15:51:05.086316+00:00 + 2025-10-11T21:58:28.705475+00:00 2022-05-07T01:57:39+00:00 The email conversation between Jorge Timón and John Tromp on the Bitcoin-dev mailing list has sparked a discussion on irony. Timón accused Tromp of making personal attacks against Andreas Antonopoulos for his opinions on bip8. However, Tromp pointed out that Timón himself had made a personal attack by calling Jeremy ignorant about bip8. This led to a discussion on how ironic it is that people who base their arguments on personal attacks are also the ones who complain the most about personal attacks.In a separate discussion on the bitcoin-dev mailing list, Jorge Timón questioned a claim made by Russell O'Connor about the design of Speedy Trial (ST). Timón found the claim strange and stated that the grace period for slower activation after lock-in was added to address concerns raised by people who disliked the proposal. However, he still believed that speedy trial was a bad proposal due to incorrect analysis. O'Connor responded by quoting his own blog post where he clarified that the design of speedy trial was not based on any activation philosophy about failing fast.In another email exchange, Jorge Timón suggested that it is unnecessary to personally attack Andreas for his opinions. He argued that the only reason Jeremy Rubin does not like BIP8 is because he is ignorant about it and has not reviewed it enough. However, John Tromp pointed out the irony in equating 'clueless about BIP119' with a personal attack and then calling Jeremy ignorant about BIP8. The conversation seems to revolve around differences of opinion regarding different Bitcoin Improvement Proposals (BIPs).In a separate email thread, Ryan Grant defends the OP_CTV covenant proposal after Jorge Timón questioned Andreas' criticism. Ryan argues that OP_CTV covenants cannot restrict any address that the sender does not control and criticizes Andreas for not code-reviewing BIP119 or the pull request. Ryan believes that Andreas did not look into the reason why the proposed client was safe and would not cause a chain split. The conversation also references Russell O'Connor's explanation for how Speedy Trials arose in the consensus process and how it was designed.The email threads also touch upon the concept of covenants in Bitcoin and the contributions made by individuals towards it. There is a mention of Bip8 and the importance of being open-minded to understand its analysis. The discussions revolve around the need for education, avoiding personal attacks, addressing misinformation, and looking at technical details when discussing contentious soft forks and covenant proposals.Michael Folkson expresses his thoughts on the recent attempt to activate a contentious soft fork and questions what should be done differently if such attempts happen again. He believes that it is unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split and suggests there should be a personal cost to dissuade them from trying it again. Folkson acknowledges that Bitcoin is a permissionless network and no authority can stop such attempts, but hopes that people will actively resist and prevent the network from being fundamentally broken.Overall, the email exchanges and threads highlight discussions on irony, differences of opinion regarding Bitcoin Improvement Proposals, the design of Speedy Trial, criticism of covenant proposals, addressing misinformation, and the recent attempt to activate a contentious soft fork. The conversations emphasize the importance of education, avoiding personal attacks, and considering technical details when discussing contentious topics in the Bitcoin community. diff --git a/static/bitcoin-dev/April_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml b/static/bitcoin-dev/April_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml index 59754b704e..85f84a3f85 100644 --- a/static/bitcoin-dev/April_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml +++ b/static/bitcoin-dev/April_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml @@ -2,7 +2,7 @@ 2 Combined summary - Bitcoin fungibility and inscribed sats - 2025-09-26T14:28:10.042709+00:00 + 2025-10-11T21:53:20.449466+00:00 python-feedgen Kree Love 2023-04-20 23:06:17+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Bitcoin fungibility and inscribed sats - 2025-09-26T14:28:10.042863+00:00 + 2025-10-11T21:53:20.449636+00:00 2023-04-20T23:06:17+00:00 In a detailed message, the author shares their personal journey with Bitcoin, starting from late 2010 when they saw it as an electronic cash system. However, they express concern about the current state of Bitcoin, noting that it has become more of an electronic asset rather than a peer-to-peer cash system due to regulation and artificially limited block sizes causing network congestion and high fees.The author also highlights the challenges faced in improving fungibility, citing regulatory hostility towards protocols like CoinJoin. They emphasize the importance of practical applications and global usability for Bitcoin to maintain its status as a global currency, despite pressure from governments, industrial lobbies, and cartels.Furthermore, the author believes that Non-Fungible Tokens (NFTs) distract from the ongoing efforts to ensure the safety and stability of Bitcoin as a reserve currency. However, they clarify that NFTs do not affect the fungibility of Bitcoin itself, as there is no token standard being used. These sats or UTXOs can be sold as regular Bitcoin on exchanges and consolidated for use like any other Bitcoin.The issue of Bitcoin fungibility is acknowledged as debatable by the author, who is actively working on implementing a coinjoin feature to prevent censorship of post-mix UTXOs on certain exchanges. They also mention the existence of the Ordinals theory, where some users believe in it and strive to understand how Bitcoin works.Developers are mentioned as being interested in building various things around Bitcoin, including BIP, DEX, libraries, and projects implementing PSBT. The author acknowledges not living in a first-world country and not attending bitdevs but expresses their desire for Bitcoin to be accessible to all.In conclusion, the author urges people to freely use Bitcoin without changing consensus rules, as this approach will ultimately benefit Bitcoin. The message was sent using Proton Mail secure email. diff --git a/static/bitcoin-dev/Aug_2012/combined_BIP-35-add-mempool-message.xml b/static/bitcoin-dev/Aug_2012/combined_BIP-35-add-mempool-message.xml index a1b055352f..2e9c4b0b6e 100644 --- a/static/bitcoin-dev/Aug_2012/combined_BIP-35-add-mempool-message.xml +++ b/static/bitcoin-dev/Aug_2012/combined_BIP-35-add-mempool-message.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 35: add mempool message - 2023-08-01T03:53:02.038128+00:00 + 2025-10-11T22:13:36.572966+00:00 + python-feedgen Jeff Garzik 2012-08-17 16:51:33+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP 35: add mempool message - 2023-08-01T03:53:02.038128+00:00 + 2025-10-11T22:13:36.573152+00:00 - Pieter Wuille and Jeff Garzik were engaged in a discussion regarding the issue of returning an empty "inv" in the Bitcoin P2P system. Jeff suggested that it is generally better to do something unconditionally rather than generate a response under certain conditions. However, Pieter disagreed and argued that returning an empty "inv" is a strange way of replying to an empty mempool because Bitcoin P2P is not a request-response protocol and "inv" messages are only sent where there are inventory items to send.In response to Pieter's point, Jeff updated the 'mempool' branch to not return "inv" if the mempool is empty. Pieter then suggested using MSG_MEMTX instead of returning an empty "inv" to confirm the transmission of the mempool is complete. However, Jeff disagreed and suggested sending a ping(nonce) instead.The discussion also touched on the topic of message types and requests for mempool contents. It was suggested that MSG_TX is fine, but it's better to request it explicitly to allow the connecting peer to configure a bloom filter before requesting mempool contents. The limitations of mobile clients were also considered, with the agreement that support for downloading the entire mempool contents at startup should not be implemented until bloom filtering is done.The conversation further delved into the concept of returning a response unconditionally and its role in feature probing and discovery. Pieter emphasized that returning a response unconditionally has little to do with feature probing or discovery but serves as a clear indication that processing is complete for each invocation.Another aspect discussed was the implementation of a new inv_type, MSG_MEMTX, which could help with distinguishing incoming "getdata" requests. This would enable querying the right storage immediately and assist with things like DoS scoring.The conversation between Pieter and Jeff also touched on the allocation of an extra service bit for the memory pool refill command. Currently, feature discovery is enabled by checking two "version" message attributes: protocol version >= 60002 and NODE_NETWORK bit set in nServices. Pieter suggested allocating an extra service bit to allow mempool-providing services to be discovered before connecting to them.In summary, the discussion revolved around the issues of returning an empty "inv" in the Bitcoin P2P system, the use of MSG_MEMTX and ping(nonce) for confirming the transmission of the mempool, the handling of message types and requests for mempool contents, and the allocation of an extra service bit for the memory pool refill command. The aim was to find the most efficient ways to handle these aspects while considering the limitations of mobile clients and ensuring clear and reliable responses. 2012-08-17T16:51:33+00:00 + Pieter Wuille and Jeff Garzik were engaged in a discussion regarding the issue of returning an empty "inv" in the Bitcoin P2P system. Jeff suggested that it is generally better to do something unconditionally rather than generate a response under certain conditions. However, Pieter disagreed and argued that returning an empty "inv" is a strange way of replying to an empty mempool because Bitcoin P2P is not a request-response protocol and "inv" messages are only sent where there are inventory items to send.In response to Pieter's point, Jeff updated the 'mempool' branch to not return "inv" if the mempool is empty. Pieter then suggested using MSG_MEMTX instead of returning an empty "inv" to confirm the transmission of the mempool is complete. However, Jeff disagreed and suggested sending a ping(nonce) instead.The discussion also touched on the topic of message types and requests for mempool contents. It was suggested that MSG_TX is fine, but it's better to request it explicitly to allow the connecting peer to configure a bloom filter before requesting mempool contents. The limitations of mobile clients were also considered, with the agreement that support for downloading the entire mempool contents at startup should not be implemented until bloom filtering is done.The conversation further delved into the concept of returning a response unconditionally and its role in feature probing and discovery. Pieter emphasized that returning a response unconditionally has little to do with feature probing or discovery but serves as a clear indication that processing is complete for each invocation.Another aspect discussed was the implementation of a new inv_type, MSG_MEMTX, which could help with distinguishing incoming "getdata" requests. This would enable querying the right storage immediately and assist with things like DoS scoring.The conversation between Pieter and Jeff also touched on the allocation of an extra service bit for the memory pool refill command. Currently, feature discovery is enabled by checking two "version" message attributes: protocol version >= 60002 and NODE_NETWORK bit set in nServices. Pieter suggested allocating an extra service bit to allow mempool-providing services to be discovered before connecting to them.In summary, the discussion revolved around the issues of returning an empty "inv" in the Bitcoin P2P system, the use of MSG_MEMTX and ping(nonce) for confirming the transmission of the mempool, the handling of message types and requests for mempool contents, and the allocation of an extra service bit for the memory pool refill command. The aim was to find the most efficient ways to handle these aspects while considering the limitations of mobile clients and ensuring clear and reliable responses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2012/combined_BIP-Custom-Services.xml b/static/bitcoin-dev/Aug_2012/combined_BIP-Custom-Services.xml index 13deec11a1..00e24ce6ab 100644 --- a/static/bitcoin-dev/Aug_2012/combined_BIP-Custom-Services.xml +++ b/static/bitcoin-dev/Aug_2012/combined_BIP-Custom-Services.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: Custom Services - 2023-08-01T03:52:14.730040+00:00 + 2025-10-11T22:13:47.199648+00:00 + python-feedgen Stefan Thomas 2012-08-13 20:00:36+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP: Custom Services - 2023-08-01T03:52:14.731041+00:00 + 2025-10-11T22:13:47.199781+00:00 - BitcoinJS is implementing a Distributed Hash Table (DHT) to store a user-defined percentage of the blockchain index locally, with any missed data being resolved through network queries. This feature allows users to run BitcoinJS nodes of varying sizes, providing equal querying capabilities without the need to download the entire blockchain. The DHT network is extensible, allowing for the inclusion of decentralized pool protocols. The aim of this implementation is to make it easier to incorporate custom services into the standard protocol and encourage compatibility with Bitcoin's mechanisms. However, there may be resistance to adding extra functionality to the core Bitcoin network.In August 2012, Jeff Garzik discussed the need for basic rules on extending the P2P command set, as some cases require introduction mechanisms. Stefan Thomas proposed a solution to announce custom protocol extensions, addressing the limitation of using up the available NODE_* flags. Jeff Garzik responded with alternative suggestions, including modifying 'version' and introducing a new "getcaps" command. However, gmaxwell highlighted the issue of discovering and utilizing these capabilities effectively. Jeff emphasized the importance of establishing rules for extending the P2P command set, considering that clients will inevitably implement their own commands.Discussions have taken place regarding the addition of extra functionality to the core Bitcoin network. It is anticipated that there will be opposition to this idea, leading individuals to create separate P2P networks for new applications by reusing existing code with different peer discovery seeds. For instance, if someone wants to develop a language translation app requiring floodfill broadcasting of invalid transactions, an independent network may be more suitable. A more thorough exploration of use cases is needed to determine the feasibility of incorporating additional functionality into the core Bitcoin network.Stefan Thomas has devised a standardized approach to announce custom protocol extensions without depleting the available NODE_* flags. Recognizing the limited capacity provided by the current mechanism, Stefan's solution can be found on his BIP draft page on the Bitcoin wiki. Feedback from Amir Taaki, Mike Hearn, and Pieter Wuille has contributed to refining this solution. A separate BIP addressing peer exchange for custom services has been separated from Stefan's proposal and will undergo further refinement before submission. 2012-08-13T20:00:36+00:00 + BitcoinJS is implementing a Distributed Hash Table (DHT) to store a user-defined percentage of the blockchain index locally, with any missed data being resolved through network queries. This feature allows users to run BitcoinJS nodes of varying sizes, providing equal querying capabilities without the need to download the entire blockchain. The DHT network is extensible, allowing for the inclusion of decentralized pool protocols. The aim of this implementation is to make it easier to incorporate custom services into the standard protocol and encourage compatibility with Bitcoin's mechanisms. However, there may be resistance to adding extra functionality to the core Bitcoin network.In August 2012, Jeff Garzik discussed the need for basic rules on extending the P2P command set, as some cases require introduction mechanisms. Stefan Thomas proposed a solution to announce custom protocol extensions, addressing the limitation of using up the available NODE_* flags. Jeff Garzik responded with alternative suggestions, including modifying 'version' and introducing a new "getcaps" command. However, gmaxwell highlighted the issue of discovering and utilizing these capabilities effectively. Jeff emphasized the importance of establishing rules for extending the P2P command set, considering that clients will inevitably implement their own commands.Discussions have taken place regarding the addition of extra functionality to the core Bitcoin network. It is anticipated that there will be opposition to this idea, leading individuals to create separate P2P networks for new applications by reusing existing code with different peer discovery seeds. For instance, if someone wants to develop a language translation app requiring floodfill broadcasting of invalid transactions, an independent network may be more suitable. A more thorough exploration of use cases is needed to determine the feasibility of incorporating additional functionality into the core Bitcoin network.Stefan Thomas has devised a standardized approach to announce custom protocol extensions without depleting the available NODE_* flags. Recognizing the limited capacity provided by the current mechanism, Stefan's solution can be found on his BIP draft page on the Bitcoin wiki. Feedback from Amir Taaki, Mike Hearn, and Pieter Wuille has contributed to refining this solution. A separate BIP addressing peer exchange for custom services has been separated from Stefan's proposal and will undergo further refinement before submission. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2012/combined_Bloom-Filter-Implementation.xml b/static/bitcoin-dev/Aug_2012/combined_Bloom-Filter-Implementation.xml index 5aff82bc78..f76fa37cb7 100644 --- a/static/bitcoin-dev/Aug_2012/combined_Bloom-Filter-Implementation.xml +++ b/static/bitcoin-dev/Aug_2012/combined_Bloom-Filter-Implementation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bloom Filter Implementation - 2023-08-01T03:52:41.441098+00:00 + 2025-10-11T22:13:38.696943+00:00 + python-feedgen Mike Hearn 2012-08-15 10:07:14+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bloom Filter Implementation - 2023-08-01T03:52:41.441098+00:00 + 2025-10-11T22:13:38.697131+00:00 - The writer of the message expresses gratitude and provides feedback on the suggestion to update the filter after every block download. They argue that this would negatively affect performance gains by causing a round-trip. Instead, they propose a solution to do bulk getblocks on hundreds/thousands of blocks at a time, allowing data to stream in.To save bandwidth and network round-trips, the writer suggests using a class called CLiteMerkleTx and a class called CMerkleBlock. These classes include variables such as nVersion, hashPrevBlock, hashMerkleRoot, nTime, nBits, nNonce, and vMatchedTxns, and provide transactions immediately in the block.The author mentions implementing a new bloom filter and block relay type in response to the "New P2P commands for diagnostics, SPV clients" thread. This implementation enables faster relay for clients with transactions in the memory pool. SPV clients can request that all future MSG_TX inv messages and blocks are filtered by sending a filterload message with a serialized bloom filter.Nodes can add particular data blocks to the filter using filteradd messages (not recommended for anonymity) and disable filtering on a node's connection until re-enabled by calling filterclear. The filter matches transactions with script data elements in either a scriptPubKey or scriptSig, spends an input whose COutPoint is in the filter, has a hash in the filter, or has a script data element in a prevout's scriptPubKey. Matching of prevouts only occurs on free txes, not those in blocks.The writer advises SPV clients to update the remote node's filter before requesting a block, if necessary, to ensure it includes the hash of any transaction that would not otherwise match the filter. This allows the node to know when its transactions are included in blocks.While the author is not keen on requiring SPV nodes to constantly update the filter when they learn about new transactions, they believe it is not worth loading all prevouts when a node is in IBD to fix the issue.For those interested, the branch of this implementation can be found at https://github.com/TheBlueMatt/bitcoin/compare/master...bloom. 2012-08-15T10:07:14+00:00 + The writer of the message expresses gratitude and provides feedback on the suggestion to update the filter after every block download. They argue that this would negatively affect performance gains by causing a round-trip. Instead, they propose a solution to do bulk getblocks on hundreds/thousands of blocks at a time, allowing data to stream in.To save bandwidth and network round-trips, the writer suggests using a class called CLiteMerkleTx and a class called CMerkleBlock. These classes include variables such as nVersion, hashPrevBlock, hashMerkleRoot, nTime, nBits, nNonce, and vMatchedTxns, and provide transactions immediately in the block.The author mentions implementing a new bloom filter and block relay type in response to the "New P2P commands for diagnostics, SPV clients" thread. This implementation enables faster relay for clients with transactions in the memory pool. SPV clients can request that all future MSG_TX inv messages and blocks are filtered by sending a filterload message with a serialized bloom filter.Nodes can add particular data blocks to the filter using filteradd messages (not recommended for anonymity) and disable filtering on a node's connection until re-enabled by calling filterclear. The filter matches transactions with script data elements in either a scriptPubKey or scriptSig, spends an input whose COutPoint is in the filter, has a hash in the filter, or has a script data element in a prevout's scriptPubKey. Matching of prevouts only occurs on free txes, not those in blocks.The writer advises SPV clients to update the remote node's filter before requesting a block, if necessary, to ensure it includes the hash of any transaction that would not otherwise match the filter. This allows the node to know when its transactions are included in blocks.While the author is not keen on requiring SPV nodes to constantly update the filter when they learn about new transactions, they believe it is not worth loading all prevouts when a node is in IBD to fix the issue.For those interested, the branch of this implementation can be found at https://github.com/TheBlueMatt/bitcoin/compare/master...bloom. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2012/combined_Full-Disclosure-CVE-2012-2459-block-merkle-calculation-exploit-.xml b/static/bitcoin-dev/Aug_2012/combined_Full-Disclosure-CVE-2012-2459-block-merkle-calculation-exploit-.xml index 8d8e9b5024..00842deea3 100644 --- a/static/bitcoin-dev/Aug_2012/combined_Full-Disclosure-CVE-2012-2459-block-merkle-calculation-exploit-.xml +++ b/static/bitcoin-dev/Aug_2012/combined_Full-Disclosure-CVE-2012-2459-block-merkle-calculation-exploit-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Full Disclosure: CVE-2012-2459 (block merkle calculation exploit) - 2023-08-01T03:53:19.357020+00:00 + 2025-10-11T22:13:45.076449+00:00 + python-feedgen Mike Hearn 2012-08-22 08:10:29+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Full Disclosure: CVE-2012-2459 (block merkle calculation exploit) - 2023-08-01T03:53:19.357020+00:00 + 2025-10-11T22:13:45.076595+00:00 - After a responsible disclosure of a vulnerability, Gavin made a commit to update the code with more information. However, the commit only mentions a denial-of-service (DoS) attack without providing further details. It is important to note the vulnerability of the Merkle hash function within the code as well.The vulnerability in unpatched Bitcoin installations allows for a permanent wedge at the current highest block. This is achieved by caching orphan blocks in a disk-backed database. Attackers can exploit this vulnerability by sending a valid block that eventually makes it into the blockchain and then making it invalid by duplicating one of the transactions while preserving the Merkle root. The attacker does not need to mine their own block but can mutate an existing block and pass it on to peers after listening for one.In addition, the vulnerability also enables attackers to hijack large miners and exchanges, resulting in double-spend attacks until miners realize they have been forked and fix their bitcoind. Attackers can target specific blocks they want orphaned by performing this attack on a majority of miners using the "tip" block they want to be orphaned. To mitigate this risk, Eloipool has attempted to produce blocks with transaction counts that are powers of two, as such blocks cannot be used for an attack against vulnerable clients.Furthermore, a flaw has been discovered in the Merkle hash implementation used by Bitcoin to calculate the Merkle root in a block header. This flaw allows an attacker to construct multiple lists of hashes that map to the same Merkle root. Consequently, two blocks can be created with the same block hash, but one will be valid while the other is invalid. This attack can be executed on unpatched Bitcoin installations, leading to a permanent wedge at the current highest block due to the caching of orphan blocks in the disk-backed database.When a victim receives the invalid block, it will be cached on disk, processed, and subsequently rejected as invalid. Re-requesting the block will not even be attempted because Bitcoin believes it already has the block, considering it has one with the same hash. To address this issue, Gavin Andresen implemented a rejection of blocks with duplicate transactions in CheckBlock, preventing them from being cached at all. 2012-08-22T08:10:29+00:00 + After a responsible disclosure of a vulnerability, Gavin made a commit to update the code with more information. However, the commit only mentions a denial-of-service (DoS) attack without providing further details. It is important to note the vulnerability of the Merkle hash function within the code as well.The vulnerability in unpatched Bitcoin installations allows for a permanent wedge at the current highest block. This is achieved by caching orphan blocks in a disk-backed database. Attackers can exploit this vulnerability by sending a valid block that eventually makes it into the blockchain and then making it invalid by duplicating one of the transactions while preserving the Merkle root. The attacker does not need to mine their own block but can mutate an existing block and pass it on to peers after listening for one.In addition, the vulnerability also enables attackers to hijack large miners and exchanges, resulting in double-spend attacks until miners realize they have been forked and fix their bitcoind. Attackers can target specific blocks they want orphaned by performing this attack on a majority of miners using the "tip" block they want to be orphaned. To mitigate this risk, Eloipool has attempted to produce blocks with transaction counts that are powers of two, as such blocks cannot be used for an attack against vulnerable clients.Furthermore, a flaw has been discovered in the Merkle hash implementation used by Bitcoin to calculate the Merkle root in a block header. This flaw allows an attacker to construct multiple lists of hashes that map to the same Merkle root. Consequently, two blocks can be created with the same block hash, but one will be valid while the other is invalid. This attack can be executed on unpatched Bitcoin installations, leading to a permanent wedge at the current highest block due to the caching of orphan blocks in the disk-backed database.When a victim receives the invalid block, it will be cached on disk, processed, and subsequently rejected as invalid. Re-requesting the block will not even be attempted because Bitcoin believes it already has the block, considering it has one with the same hash. To address this issue, Gavin Andresen implemented a rejection of blocks with duplicate transactions in CheckBlock, preventing them from being cached at all. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2012/combined_Protocol-changes-for-SPV-clients-mempool-getdata-commands.xml b/static/bitcoin-dev/Aug_2012/combined_Protocol-changes-for-SPV-clients-mempool-getdata-commands.xml index 497fdc20e1..df799a30c8 100644 --- a/static/bitcoin-dev/Aug_2012/combined_Protocol-changes-for-SPV-clients-mempool-getdata-commands.xml +++ b/static/bitcoin-dev/Aug_2012/combined_Protocol-changes-for-SPV-clients-mempool-getdata-commands.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Protocol changes for SPV clients: mempool, getdata commands - 2023-08-01T03:52:24.108243+00:00 + 2025-10-11T22:13:49.322162+00:00 + python-feedgen Wladimir 2012-08-14 04:55:35+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Protocol changes for SPV clients: mempool, getdata commands - 2023-08-01T03:52:24.108243+00:00 + 2025-10-11T22:13:49.322329+00:00 - In the context provided, Jeff Garzik has suggested a small change to the protocol for the upcoming release of satoshi client v0.7. The proposed change involves adding a 'mempool' P2P command and extending the 'getdata' behavior. Wladimir fully supports the changes but suggests creating a small Bitcoin Improvement Proposal (BIP) for consistency and documentation purposes.The proposal aims to add a new command called 'mempool' to the satoshi client v0.7. This addition would benefit simplified payment verification (SPV) clients by providing them access to the memory pool. It would also allow diagnostics and miner download capabilities. Additionally, the 'getdata' behavior would be extended to include any memory pool transaction. This change would relax a previous restriction on the 'getdata' behavior.Although the proposal does not necessarily require a BIP, Jeff Garzik has offered to write one if deemed necessary. This step would ensure consistency and provide documentation for other client developers. Overall, the proposed changes aim to enhance the functionality and accessibility of the satoshi client v0.7. 2012-08-14T04:55:35+00:00 + In the context provided, Jeff Garzik has suggested a small change to the protocol for the upcoming release of satoshi client v0.7. The proposed change involves adding a 'mempool' P2P command and extending the 'getdata' behavior. Wladimir fully supports the changes but suggests creating a small Bitcoin Improvement Proposal (BIP) for consistency and documentation purposes.The proposal aims to add a new command called 'mempool' to the satoshi client v0.7. This addition would benefit simplified payment verification (SPV) clients by providing them access to the memory pool. It would also allow diagnostics and miner download capabilities. Additionally, the 'getdata' behavior would be extended to include any memory pool transaction. This change would relax a previous restriction on the 'getdata' behavior.Although the proposal does not necessarily require a BIP, Jeff Garzik has offered to write one if deemed necessary. This step would ensure consistency and provide documentation for other client developers. Overall, the proposed changes aim to enhance the functionality and accessibility of the satoshi client v0.7. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2012/combined_The-Bitcoin-Testing-Project.xml b/static/bitcoin-dev/Aug_2012/combined_The-Bitcoin-Testing-Project.xml index 3380cf2439..d5c8d1acaa 100644 --- a/static/bitcoin-dev/Aug_2012/combined_The-Bitcoin-Testing-Project.xml +++ b/static/bitcoin-dev/Aug_2012/combined_The-Bitcoin-Testing-Project.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The Bitcoin Testing Project - 2023-08-01T03:51:32.926847+00:00 + 2025-10-11T22:13:42.954207+00:00 + python-feedgen steve 2012-08-03 00:19:17+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - The Bitcoin Testing Project - 2023-08-01T03:51:32.926847+00:00 + 2025-10-11T22:13:42.954400+00:00 - Steve suggests the creation of a small starter suite of tests that can be incorporated into Bitcoin Improvement Proposals (BIPs) and shown to the community. He recommends using the Bettermeans platform to facilitate the process of creating, reviewing, and updating tests, despite having encountered issues with it losing work. Steve provides links to his existing work, including general acceptance tests and installation and wallet tests, as well as a wiki space he has been utilizing. He acknowledges that the terminology he used needs improvement and expresses an interest in keeping the tests informal, although he recognizes that this contradicts their purpose. To reduce the need for vetting tests, Steve proposes emulating Bettermeans' BIP and voting mechanism.In response to Steve's message, Gary suggests the creation of a starter suite of tests for the blockchain and proposes incorporating them through BIPs, ensuring that they are thoroughly reviewed and updated before being included in a reference. Steve proposes using Mantis Bug Tracker (MantisBT) as a platform for testing, citing its versatility and industry-standard status. He draws a comparison between the testing process for Bitcoin and that of games in the gaming industry. Steve believes that publishing TRC/TCR tests will allow third-party developers to assess their compatibility with the blockchain and previous/future versions. He shares his experience in setting up a Microsoft Xbox European certification department, establishing QA departments, conducting testing cycles on military spec comms equipment, and identifying vulnerabilities in software such as Office, Quicktime, IE, and FF.Steve expresses a desire to move away from Bettermeans and adopt a voting/hierarchy style from Bettermeans for Mantis and test workflow. He discloses that he suffers from fast-cycling type two bipolar disorder but assures that he manages it well with medication. Additionally, Steve holds SCE clearance and mentions having a full MSDN and Technet license, along with various machines that can be used for automated testing and testing different setups. 2012-08-03T00:19:17+00:00 + Steve suggests the creation of a small starter suite of tests that can be incorporated into Bitcoin Improvement Proposals (BIPs) and shown to the community. He recommends using the Bettermeans platform to facilitate the process of creating, reviewing, and updating tests, despite having encountered issues with it losing work. Steve provides links to his existing work, including general acceptance tests and installation and wallet tests, as well as a wiki space he has been utilizing. He acknowledges that the terminology he used needs improvement and expresses an interest in keeping the tests informal, although he recognizes that this contradicts their purpose. To reduce the need for vetting tests, Steve proposes emulating Bettermeans' BIP and voting mechanism.In response to Steve's message, Gary suggests the creation of a starter suite of tests for the blockchain and proposes incorporating them through BIPs, ensuring that they are thoroughly reviewed and updated before being included in a reference. Steve proposes using Mantis Bug Tracker (MantisBT) as a platform for testing, citing its versatility and industry-standard status. He draws a comparison between the testing process for Bitcoin and that of games in the gaming industry. Steve believes that publishing TRC/TCR tests will allow third-party developers to assess their compatibility with the blockchain and previous/future versions. He shares his experience in setting up a Microsoft Xbox European certification department, establishing QA departments, conducting testing cycles on military spec comms equipment, and identifying vulnerabilities in software such as Office, Quicktime, IE, and FF.Steve expresses a desire to move away from Bettermeans and adopt a voting/hierarchy style from Bettermeans for Mantis and test workflow. He discloses that he suffers from fast-cycling type two bipolar disorder but assures that he manages it well with medication. Additionally, Steve holds SCE clearance and mentions having a full MSDN and Technet license, along with various machines that can be used for automated testing and testing different setups. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2012/combined_Version-0-7-release-planning.xml b/static/bitcoin-dev/Aug_2012/combined_Version-0-7-release-planning.xml index 278a8a1bfb..3353a9ce99 100644 --- a/static/bitcoin-dev/Aug_2012/combined_Version-0-7-release-planning.xml +++ b/static/bitcoin-dev/Aug_2012/combined_Version-0-7-release-planning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Version 0.7 release planning - 2023-08-01T03:51:57.299873+00:00 + 2025-10-11T22:13:40.820069+00:00 + python-feedgen Geir Harald Hansen 2012-08-12 07:59:56+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Version 0.7 release planning - 2023-08-01T03:51:57.300875+00:00 + 2025-10-11T22:13:40.820223+00:00 - In a conversation between Wladimir and Geir on August 11th, 2012, they discuss the issue of duplicate strings in translations. Wladimir explains that duplicate strings are not problematic because some strings are used multiple times in the program and may be translated differently based on context. He mentions that Qt translator automatically fills duplicates, while Transifex requires copy and paste. They also discuss using UPnP to map the listening port in bitcoin-qt, with Wladimir forgetting about a compiler flag for this feature.Geir reports that the most common support request he receives at his pool is from users who withdraw coins but cannot see them in their wallet because it is not up-to-date with the block chain. To address this, Wladimir adds a red warning in the balances when the block chain is out of date in version 0.7 of bitcoin-qt to prevent confusion. They also mention that there have been subtle changes made to the English base messages, such as capitalization or punctuation, which can be annoying for translators. However, there is no way to update all translations when the English base message changes without triggering re-translation, and Transifex does not have that option. They note that there were new duplicated strings, but explain that duplicate strings are not a problem since they can be translated differently based on context. Qt translator fills duplicates automatically, while it is unclear if Transifex has the same option.Geir suggests adding a feature to the bitcoin-qt GUI to make it more obvious to users why they can't see new transactions in their wallets. They also discuss the default settings for using UPnP to map the listening port, clarifying that the default depends on compiler flags. They mention that Jeff Garzik proposed a checkpoint release for Bitcoin, noting that there were no major landmark features but several small modifications that would make it useful. Gavin Andresen, one of the core developers, responds that he has no objections to a rc1 happening before he returns from vacation.On August 2, 2012, Jeff Garzik calls for a todo list for version 0.7 of the bitcoin software. Several branches are accepted for inclusion in this version, including addnode optimization and access via RPC, transitioning to requiring block height in block coinbases, making IPv6 support optional again, and getblocktemplate. Other features such as adding a 'mempool' P2P command, extending 'getdata' behavior, and adding prioritisetransaction JSON-RPC method are also deemed appropriate. Testing is still needed for certain features, such as "Child-pays-for-parent / Add transaction fee later" and relaying blocks as a preview before checking transactions. The author also expresses concern that the Bitcoin-Qt client should have a distinct name to avoid confusion with the overall Bitcoin software.Overall, the Bitcoin developers are planning to release a new version of the software soon. The changes are not very significant but aim to create a checkpoint release. Suggestions for improvements include updates to translations, address groupings RPC, extending 'getdata' behavior, addnode optimization, parallelization opportunities, optional IPv6 support, and more. Developers are encouraged to contribute directly to the release notes if they feel there is missing information. 2012-08-12T07:59:56+00:00 + In a conversation between Wladimir and Geir on August 11th, 2012, they discuss the issue of duplicate strings in translations. Wladimir explains that duplicate strings are not problematic because some strings are used multiple times in the program and may be translated differently based on context. He mentions that Qt translator automatically fills duplicates, while Transifex requires copy and paste. They also discuss using UPnP to map the listening port in bitcoin-qt, with Wladimir forgetting about a compiler flag for this feature.Geir reports that the most common support request he receives at his pool is from users who withdraw coins but cannot see them in their wallet because it is not up-to-date with the block chain. To address this, Wladimir adds a red warning in the balances when the block chain is out of date in version 0.7 of bitcoin-qt to prevent confusion. They also mention that there have been subtle changes made to the English base messages, such as capitalization or punctuation, which can be annoying for translators. However, there is no way to update all translations when the English base message changes without triggering re-translation, and Transifex does not have that option. They note that there were new duplicated strings, but explain that duplicate strings are not a problem since they can be translated differently based on context. Qt translator fills duplicates automatically, while it is unclear if Transifex has the same option.Geir suggests adding a feature to the bitcoin-qt GUI to make it more obvious to users why they can't see new transactions in their wallets. They also discuss the default settings for using UPnP to map the listening port, clarifying that the default depends on compiler flags. They mention that Jeff Garzik proposed a checkpoint release for Bitcoin, noting that there were no major landmark features but several small modifications that would make it useful. Gavin Andresen, one of the core developers, responds that he has no objections to a rc1 happening before he returns from vacation.On August 2, 2012, Jeff Garzik calls for a todo list for version 0.7 of the bitcoin software. Several branches are accepted for inclusion in this version, including addnode optimization and access via RPC, transitioning to requiring block height in block coinbases, making IPv6 support optional again, and getblocktemplate. Other features such as adding a 'mempool' P2P command, extending 'getdata' behavior, and adding prioritisetransaction JSON-RPC method are also deemed appropriate. Testing is still needed for certain features, such as "Child-pays-for-parent / Add transaction fee later" and relaying blocks as a preview before checking transactions. The author also expresses concern that the Bitcoin-Qt client should have a distinct name to avoid confusion with the overall Bitcoin software.Overall, the Bitcoin developers are planning to release a new version of the software soon. The changes are not very significant but aim to create a checkpoint release. Suggestions for improvements include updates to translations, address groupings RPC, extending 'getdata' behavior, addnode optimization, parallelization opportunities, optional IPv6 support, and more. Developers are encouraged to contribute directly to the release notes if they feel there is missing information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Android-key-rotation.xml b/static/bitcoin-dev/Aug_2013/combined_Android-key-rotation.xml index 3e69035c2d..00859d73fa 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Android-key-rotation.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Android-key-rotation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Android key rotation - 2023-08-01T05:36:49.413346+00:00 + 2025-10-11T21:32:17.789648+00:00 + python-feedgen Andreas M. Antonopoulos 2013-08-11 18:21:28+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Android key rotation - 2023-08-01T05:36:49.413346+00:00 + 2025-10-11T21:32:17.789841+00:00 - A major security issue has been identified in the Android implementation of the Java SecureRandom class, as highlighted by Mike Hearn in an email sent on August 11, 2013. This vulnerability affects the generation of private keys on Android phones and tablets, making them weak and susceptible to theft. The problem arises from colliding R values in some signatures, which allows unauthorized access to private keys and subsequent theft of funds.To address this issue, an update for the Bitcoin Wallet app has been developed. This update bypasses the system's SecureRandom implementation and instead reads directly from /dev/urandom, which is believed to be functioning correctly. Importantly, users do not need to take any manual action, as the re-keying process is automated and controlled by Andreas through a percentage throttle. This feature enables him to slow down the process if the memory pool load becomes too high.A fixed APK (Android Application Package) is available for download, and Andreas plans to release it to beta testing soon. Additionally, other wallet maintainers have been notified about the issue and are working on similar updates for their applications. Once a reasonable number of users have completed testing the automated re-keying process, the updated version will be released on the Play Store. All users will receive a notification regarding the new version, and some may even be upgraded automatically.In order to provide further information and clarification on the issue, there is a request for an audio interview to be conducted for the Let's Talk Bitcoin show. This interview will explain the vulnerability and its workaround/resolution in detail. The public security alert on Bitcoin.org contains additional details about the issue, along with a link to download the fixed APK.Overall, the vulnerabilities in the Android implementation of the Java SecureRandom class pose a significant threat to Bitcoin users. However, steps have been taken to mitigate these risks through the development of an updated version of the Bitcoin Wallet app. The involvement of Andreas and other wallet maintainers ensures that similar updates are being worked on to protect users' funds. 2013-08-11T18:21:28+00:00 + A major security issue has been identified in the Android implementation of the Java SecureRandom class, as highlighted by Mike Hearn in an email sent on August 11, 2013. This vulnerability affects the generation of private keys on Android phones and tablets, making them weak and susceptible to theft. The problem arises from colliding R values in some signatures, which allows unauthorized access to private keys and subsequent theft of funds.To address this issue, an update for the Bitcoin Wallet app has been developed. This update bypasses the system's SecureRandom implementation and instead reads directly from /dev/urandom, which is believed to be functioning correctly. Importantly, users do not need to take any manual action, as the re-keying process is automated and controlled by Andreas through a percentage throttle. This feature enables him to slow down the process if the memory pool load becomes too high.A fixed APK (Android Application Package) is available for download, and Andreas plans to release it to beta testing soon. Additionally, other wallet maintainers have been notified about the issue and are working on similar updates for their applications. Once a reasonable number of users have completed testing the automated re-keying process, the updated version will be released on the Play Store. All users will receive a notification regarding the new version, and some may even be upgraded automatically.In order to provide further information and clarification on the issue, there is a request for an audio interview to be conducted for the Let's Talk Bitcoin show. This interview will explain the vulnerability and its workaround/resolution in detail. The public security alert on Bitcoin.org contains additional details about the issue, along with a link to download the fixed APK.Overall, the vulnerabilities in the Android implementation of the Java SecureRandom class pose a significant threat to Bitcoin users. However, steps have been taken to mitigate these risks through the development of an updated version of the Bitcoin Wallet app. The involvement of Andreas and other wallet maintainers ensures that similar updates are being worked on to protect users' funds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_BIP-32-5.xml b/static/bitcoin-dev/Aug_2013/combined_BIP-32-5.xml index c5570f37ec..31259f5d77 100644 --- a/static/bitcoin-dev/Aug_2013/combined_BIP-32-5.xml +++ b/static/bitcoin-dev/Aug_2013/combined_BIP-32-5.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 32.5 - 2023-08-01T05:39:01.173960+00:00 + 2025-10-11T21:32:41.167687+00:00 + python-feedgen Gregory Maxwell 2013-08-20 08:35:29+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP 32.5 - 2023-08-01T05:39:01.173960+00:00 + 2025-10-11T21:32:41.167851+00:00 - In August 2013, Gregory Maxwell proposed the creation of a BIP32 addendum to provide recommendations for signing in blockchain technology. He highlighted an ongoing issue with duplicated keys in blockchain.info's mywallet and discussed it with Pieter, who supported the idea. The aim was to create a BIP document outlining these recommendations.The author argues for the removal of the "CS-PRNG" component from signing, as it does not add value and hampers deterministic signing. However, the CS-PRNG is still necessary for generating the root master key of an HD wallet, which poses a potential vulnerability if the single invocation of the CS-PRNG is weak. To mitigate this risk, the author suggests collecting entropy over time through multiple invocations or sources. Additionally, compromised DSA signatures were isolated incidents, whereas a weak key in the BIP32 root could be more damaging. To enhance protection, the author proposes using smartphone sensors to provide additional entropy. Overall, the author advocates for minimizing the use of CS-PRNGs whenever possible and implementing best practices to reduce reliance on them.In an email conversation from August 2013, Bitcoin developer Mike Hearn raised concerns about analyzing hardware wallets and questioned their necessity if one already trusts their computer. Another participant expressed mistrust in both hardware wallets and computers. The discussion also touched on the absence of multisig support in the initial version of TREZOR and the challenges of implementing P2SH support for sending payments through Android wallets.A proposal has been made to create a Bitcoin Improvement Proposal (BIP) that standardizes the selection of K, recommends a specific deterministic DSA derandomization procedure, and promotes the use of even S values in signatures. By adopting these changes, complete test vectors in signing can be achieved, ensuring confidence in the absence of random number-related weaknesses in signing implementations. While concerns exist about using a less-reviewed cryptographic construct, the author suggests that the industry's movement towards derandomized DSA diminishes this issue. If positively reviewed, a new BIP incorporating these recommendations would be implemented.The author suggests a BIP32 addendum to provide specific deterministic recommendations for DSA derandomization procedures. Employing fully deterministic signatures would enable comprehensive test vectors in signing and uncover potential misbehavior in maliciously modified hardware wallets, even without insecure K values. The primary arguments against derandomizing DSA involve FIPS conformance and concerns about using less-reviewed cryptographic constructs. Nonetheless, the industry is gravitating towards derandomized DSA due to its identified hazards. The author recommends implementing a procedure for using only even S values in signatures to eliminate mutability in transactions. While existing signatures can undergo post-processing for this purpose, it is generally preferable to incorporate it during the signing process. 2013-08-20T08:35:29+00:00 + In August 2013, Gregory Maxwell proposed the creation of a BIP32 addendum to provide recommendations for signing in blockchain technology. He highlighted an ongoing issue with duplicated keys in blockchain.info's mywallet and discussed it with Pieter, who supported the idea. The aim was to create a BIP document outlining these recommendations.The author argues for the removal of the "CS-PRNG" component from signing, as it does not add value and hampers deterministic signing. However, the CS-PRNG is still necessary for generating the root master key of an HD wallet, which poses a potential vulnerability if the single invocation of the CS-PRNG is weak. To mitigate this risk, the author suggests collecting entropy over time through multiple invocations or sources. Additionally, compromised DSA signatures were isolated incidents, whereas a weak key in the BIP32 root could be more damaging. To enhance protection, the author proposes using smartphone sensors to provide additional entropy. Overall, the author advocates for minimizing the use of CS-PRNGs whenever possible and implementing best practices to reduce reliance on them.In an email conversation from August 2013, Bitcoin developer Mike Hearn raised concerns about analyzing hardware wallets and questioned their necessity if one already trusts their computer. Another participant expressed mistrust in both hardware wallets and computers. The discussion also touched on the absence of multisig support in the initial version of TREZOR and the challenges of implementing P2SH support for sending payments through Android wallets.A proposal has been made to create a Bitcoin Improvement Proposal (BIP) that standardizes the selection of K, recommends a specific deterministic DSA derandomization procedure, and promotes the use of even S values in signatures. By adopting these changes, complete test vectors in signing can be achieved, ensuring confidence in the absence of random number-related weaknesses in signing implementations. While concerns exist about using a less-reviewed cryptographic construct, the author suggests that the industry's movement towards derandomized DSA diminishes this issue. If positively reviewed, a new BIP incorporating these recommendations would be implemented.The author suggests a BIP32 addendum to provide specific deterministic recommendations for DSA derandomization procedures. Employing fully deterministic signatures would enable comprehensive test vectors in signing and uncover potential misbehavior in maliciously modified hardware wallets, even without insecure K values. The primary arguments against derandomizing DSA involve FIPS conformance and concerns about using less-reviewed cryptographic constructs. Nonetheless, the industry is gravitating towards derandomized DSA due to its identified hazards. The author recommends implementing a procedure for using only even S values in signatures to eliminate mutability in transactions. While existing signatures can undergo post-processing for this purpose, it is generally preferable to incorporate it during the signing process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_BitMail-sf-net-encrypted-p2p-email.xml b/static/bitcoin-dev/Aug_2013/combined_BitMail-sf-net-encrypted-p2p-email.xml index bd5b03d5eb..694e19c82f 100644 --- a/static/bitcoin-dev/Aug_2013/combined_BitMail-sf-net-encrypted-p2p-email.xml +++ b/static/bitcoin-dev/Aug_2013/combined_BitMail-sf-net-encrypted-p2p-email.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BitMail.sf.net - encrypted p2p email - 2023-08-01T05:36:31.473055+00:00 + 2025-10-11T21:32:26.280159+00:00 + python-feedgen The Doctor 2013-08-14 17:02:47+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BitMail.sf.net - encrypted p2p email - 2023-08-01T05:36:31.473055+00:00 + 2025-10-11T21:32:26.280295+00:00 - On August 13, 2013, in a message on the Bitcoin-development mailing list, The Doctor mistakenly mixed up BitMail with BitMessage. BitMail is a distinct software and can be found at http://bitmail.sf.net. The Doctor's PGP key is 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1, and his website is https://drwho.virtadpt.net/. The Doctor's message was GPG signed using version 2.0.20 of GnuPG for verification.During this email thread, another member corrected the mistaken reference to BitMail and provided a link to BitMail's website, which offers secure encrypted peer-to-peer email services. The member also mentioned that there were security analyses available for BitMessage in various forums, but they had not been reviewed due to limited compute cycles. The signature of the message contained links to Project Byzantium, a developer project, and The Doctor's personal website. Additionally, the email included an advertisement for AppDynamics Lite, a troubleshooting tool for Java and .NET code.In a message dated August 9, 2013, Randolph D. asked if anyone had tested the secure encrypted peer-to-peer email service found at http://bitmail.sf.net. The Doctor, who is the developer of Project Byzantium, responded stating that they have not tested it recently due to its CPU and network intensity, which could potentially harm the user's needs. They recommended reading the security analyses of BitMessage but admitted that they hadn't had the time to review them yet. The security analyses can be found at https://bitmessage.org/forum/index.php?topic=1666.0 and http://www.reddit.com/r/bitmessage/comments/1fwyx7/a_security_analysis_of_bitmessage/. The Doctor signed off with their PGP key and a link to their website.In a brief message, someone named Wendell pleaded with Jesus to stop something. The message was posted on grabhive.com and linked to a Twitter account and a GPG key.Lastly, Bitmail is a secure encrypted peer-to-peer email service that has been tested by users. It can be accessed through http://bitmail.sf.net. The SVN link for Spot-On-Code, which is related to Bitmail, can be found at svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code. Additionally, the commit browser for Spot-On-Code can be viewed at http://sourceforge.net/p/spot-on/code/commit_browser. 2013-08-14T17:02:47+00:00 + On August 13, 2013, in a message on the Bitcoin-development mailing list, The Doctor mistakenly mixed up BitMail with BitMessage. BitMail is a distinct software and can be found at http://bitmail.sf.net. The Doctor's PGP key is 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1, and his website is https://drwho.virtadpt.net/. The Doctor's message was GPG signed using version 2.0.20 of GnuPG for verification.During this email thread, another member corrected the mistaken reference to BitMail and provided a link to BitMail's website, which offers secure encrypted peer-to-peer email services. The member also mentioned that there were security analyses available for BitMessage in various forums, but they had not been reviewed due to limited compute cycles. The signature of the message contained links to Project Byzantium, a developer project, and The Doctor's personal website. Additionally, the email included an advertisement for AppDynamics Lite, a troubleshooting tool for Java and .NET code.In a message dated August 9, 2013, Randolph D. asked if anyone had tested the secure encrypted peer-to-peer email service found at http://bitmail.sf.net. The Doctor, who is the developer of Project Byzantium, responded stating that they have not tested it recently due to its CPU and network intensity, which could potentially harm the user's needs. They recommended reading the security analyses of BitMessage but admitted that they hadn't had the time to review them yet. The security analyses can be found at https://bitmessage.org/forum/index.php?topic=1666.0 and http://www.reddit.com/r/bitmessage/comments/1fwyx7/a_security_analysis_of_bitmessage/. The Doctor signed off with their PGP key and a link to their website.In a brief message, someone named Wendell pleaded with Jesus to stop something. The message was posted on grabhive.com and linked to a Twitter account and a GPG key.Lastly, Bitmail is a secure encrypted peer-to-peer email service that has been tested by users. It can be accessed through http://bitmail.sf.net. The SVN link for Spot-On-Code, which is related to Bitmail, can be found at svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code. Additionally, the commit browser for Spot-On-Code can be viewed at http://sourceforge.net/p/spot-on/code/commit_browser. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Bloom-io-attack-effectiveness.xml b/static/bitcoin-dev/Aug_2013/combined_Bloom-io-attack-effectiveness.xml index 048eda834c..f968f581da 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Bloom-io-attack-effectiveness.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Bloom-io-attack-effectiveness.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bloom io attack effectiveness - 2023-08-01T05:40:29.585825+00:00 + 2025-10-11T21:32:39.043274+00:00 + python-feedgen Wendell 2013-08-19 21:57:06+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Bloom io attack effectiveness - 2023-08-01T05:40:29.585825+00:00 + 2025-10-11T21:32:39.043464+00:00 - In an email exchange from August 2013, John Dillon expressed his support for decentralization and questioned Gavin's target of 10,000 full nodes, believing it to be too few for a distributed system. He also brought up the idea of partial UTXO sets, wondering if they were being ignored and urging for a separate thread to discuss the topic. Wendell agreed with John's points and asked for any GitHub links related to the subject. John criticized Gavin's priorities, specifically the payment protocol's lack of options beyond SSL certified merchants and the absence of a safe way to get money into wallets. He mentioned his own pull request for decentralization and asked which way Gavin planned on voting.In another email conversation, Peter Todd suggested that SPV peers should be deprioritized since they don't contribute back to the network. He proposed a scoring function for node importance, which would prioritize the nodes he connected to over nodes that connected to him to prevent attacks. He also suggested using subsets and considering the active duration of connections. To address I/O exhaustion, a patch should include a thread pool for load requests and a background process for load/parse/filter operations. The network thread message loop would be adjusted to receive futures/callbacks/closure objects with scores of the node. The handling of "getdata" would call a function that requests a load of a block from disk and runs a closure when finished. The function that takes a CBlockIndex and yields a future would add the new task to the job queue(s) and sort the queue using the scoring function. This approach would prioritize good nodes over bad nodes for disk I/O.In their email exchange, Gavin Andresen and Peter Todd discussed the importance of Simplified Payment Verification (SPV) peers to the growth of Bitcoin. Peter argued that SPV peers are more important than nodes because many lightweight devices rely on them. He suggested that SPV peers should be allowed to contribute back to the network with spare bandwidth for decentralization. Gavin was criticized for his priorities regarding the payment protocol, which only included options for SSL certified merchants. The exchange ended with a question about how Gavin planned to vote on Peter's decentralization pull request.Gavin Andresen argued that SPV peers are incredibly important to the growth of Bitcoin and should not be heavily deprioritized. He stated that Bitcoin would be just fine with 10,000 full nodes as the backbone of the network, but would be nothing without support for lightweight SPV devices. He preferred the decentralized SPV model over the Electrum model where lightweight devices rely solely on a full node. However, he emphasized the importance of maintaining consensus and security while serving SPV peers. Measures such as requiring a bitcointalk account or a small fee for an account could limit abuse. Supporting SPV peers while ensuring consensus and security is crucial.In a recent statement, Peter suggested deprioritizing SPV peers if they don't contribute back to the network. However, Gavin argued that SPV peers are vital to Bitcoin's growth and should not be deprioritized. Prioritizing SPV peers and supporting their growth is essential for the healthy development of Bitcoin.The writer of a post conducted tests with a variant of attack and discovered that it is easy to saturate a node's disk IO bandwidth, rendering it useless to its peers. The writer plans to repeat the attack by distributing it from multiple peers to make it indistinguishable from SPV wallets rescanning the chain for old transactions. Since SPV peers do not contribute back to the network, the writer suggests deprioritizing them and serving them only with spare resources. The challenge is finding a limited resource that can prioritize SPV nodes over attackers. Time and transaction fees have limitations, so other solutions need to be explored. 2013-08-19T21:57:06+00:00 + In an email exchange from August 2013, John Dillon expressed his support for decentralization and questioned Gavin's target of 10,000 full nodes, believing it to be too few for a distributed system. He also brought up the idea of partial UTXO sets, wondering if they were being ignored and urging for a separate thread to discuss the topic. Wendell agreed with John's points and asked for any GitHub links related to the subject. John criticized Gavin's priorities, specifically the payment protocol's lack of options beyond SSL certified merchants and the absence of a safe way to get money into wallets. He mentioned his own pull request for decentralization and asked which way Gavin planned on voting.In another email conversation, Peter Todd suggested that SPV peers should be deprioritized since they don't contribute back to the network. He proposed a scoring function for node importance, which would prioritize the nodes he connected to over nodes that connected to him to prevent attacks. He also suggested using subsets and considering the active duration of connections. To address I/O exhaustion, a patch should include a thread pool for load requests and a background process for load/parse/filter operations. The network thread message loop would be adjusted to receive futures/callbacks/closure objects with scores of the node. The handling of "getdata" would call a function that requests a load of a block from disk and runs a closure when finished. The function that takes a CBlockIndex and yields a future would add the new task to the job queue(s) and sort the queue using the scoring function. This approach would prioritize good nodes over bad nodes for disk I/O.In their email exchange, Gavin Andresen and Peter Todd discussed the importance of Simplified Payment Verification (SPV) peers to the growth of Bitcoin. Peter argued that SPV peers are more important than nodes because many lightweight devices rely on them. He suggested that SPV peers should be allowed to contribute back to the network with spare bandwidth for decentralization. Gavin was criticized for his priorities regarding the payment protocol, which only included options for SSL certified merchants. The exchange ended with a question about how Gavin planned to vote on Peter's decentralization pull request.Gavin Andresen argued that SPV peers are incredibly important to the growth of Bitcoin and should not be heavily deprioritized. He stated that Bitcoin would be just fine with 10,000 full nodes as the backbone of the network, but would be nothing without support for lightweight SPV devices. He preferred the decentralized SPV model over the Electrum model where lightweight devices rely solely on a full node. However, he emphasized the importance of maintaining consensus and security while serving SPV peers. Measures such as requiring a bitcointalk account or a small fee for an account could limit abuse. Supporting SPV peers while ensuring consensus and security is crucial.In a recent statement, Peter suggested deprioritizing SPV peers if they don't contribute back to the network. However, Gavin argued that SPV peers are vital to Bitcoin's growth and should not be deprioritized. Prioritizing SPV peers and supporting their growth is essential for the healthy development of Bitcoin.The writer of a post conducted tests with a variant of attack and discovered that it is easy to saturate a node's disk IO bandwidth, rendering it useless to its peers. The writer plans to repeat the attack by distributing it from multiple peers to make it indistinguishable from SPV wallets rescanning the chain for old transactions. Since SPV peers do not contribute back to the network, the writer suggests deprioritizing them and serving them only with spare resources. The challenge is finding a limited resource that can prioritize SPV nodes over attackers. Time and transaction fees have limitations, so other solutions need to be explored. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Combining-bloom-filters-.xml b/static/bitcoin-dev/Aug_2013/combined_Combining-bloom-filters-.xml index 128bb3ad0c..60cc221648 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Combining-bloom-filters-.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Combining-bloom-filters-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Combining bloom filters? - 2023-08-01T05:39:43.668315+00:00 + 2025-10-11T21:32:02.918723+00:00 + python-feedgen Pieter Wuille 2013-08-17 14:15:31+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Combining bloom filters? - 2023-08-01T05:39:43.669326+00:00 + 2025-10-11T21:32:02.918885+00:00 - In an email thread on the Bitcoin-development mailing list, Jeff Garzik asked whether it is possible to combine two bloom filters created by different wallets into a single filter. Pieter Wuille responded that, assuming both filters use the same seed and number of hash functions, combining them would result in a worse filter if they were already optimal for their given false positive rate.Bitcoinj's BloomFilter class allows for the combination of two filters under certain conditions. The filters must have the same parameters, including tweak, size, and hash count. A user posed a question on whether or not bloom filter A' and B' could be combined to form a single bloom filter C', to which Jeff Garzik, Senior Software Engineer and open source evangelist at BitPay, responded. This feature can be useful for wallet users who want to combine their filters for greater efficiency.The question posed by Jeff Garzik revolves around the possibility of merging two separate bloom filters built by different wallets. Specifically, wallet A builds bloom filter A' and wallet B builds bloom filter B'. The query is whether these two filters can be combined to form a single bloom filter C'. A bloom filter is a space-efficient probabilistic data structure that is used to test whether an element is a member of a set. It works by using a bit array where each bit has a random hash function associated with it. When an item is added to the filter, its hash value is calculated and the corresponding bits are set to 1. To check if an element is in the set, its hash value is calculated again and the corresponding bits are checked. If any of the bits are 0, then the element is definitely not in the set. Otherwise, it may or may not be in the set.The concept of merging bloom filters is not new and has been explored before. One approach is to simply OR the bit arrays of the two filters together. However, this may lead to false positives since the resulting filter will have more bits set to 1 than either of the individual filters. Another approach is to use a weighted union of the two filters, where the probability of a false positive is minimized.In conclusion, Jeff Garzik's question about merging bloom filters relates to the possibility of combining two distinct filters built by different wallets. Bloom filters are probabilistic data structures that use bit arrays and hash functions to determine if an element is in a set. Merging bloom filters can be done by OR-ing their bit arrays or by using a weighted union to minimize false positives. Additionally, the email thread also includes a promotional message for AppDynamics Lite, a troubleshooting tool designed for Java and .NET code, providing code-level detail for bottlenecks in production. 2013-08-17T14:15:31+00:00 + In an email thread on the Bitcoin-development mailing list, Jeff Garzik asked whether it is possible to combine two bloom filters created by different wallets into a single filter. Pieter Wuille responded that, assuming both filters use the same seed and number of hash functions, combining them would result in a worse filter if they were already optimal for their given false positive rate.Bitcoinj's BloomFilter class allows for the combination of two filters under certain conditions. The filters must have the same parameters, including tweak, size, and hash count. A user posed a question on whether or not bloom filter A' and B' could be combined to form a single bloom filter C', to which Jeff Garzik, Senior Software Engineer and open source evangelist at BitPay, responded. This feature can be useful for wallet users who want to combine their filters for greater efficiency.The question posed by Jeff Garzik revolves around the possibility of merging two separate bloom filters built by different wallets. Specifically, wallet A builds bloom filter A' and wallet B builds bloom filter B'. The query is whether these two filters can be combined to form a single bloom filter C'. A bloom filter is a space-efficient probabilistic data structure that is used to test whether an element is a member of a set. It works by using a bit array where each bit has a random hash function associated with it. When an item is added to the filter, its hash value is calculated and the corresponding bits are set to 1. To check if an element is in the set, its hash value is calculated again and the corresponding bits are checked. If any of the bits are 0, then the element is definitely not in the set. Otherwise, it may or may not be in the set.The concept of merging bloom filters is not new and has been explored before. One approach is to simply OR the bit arrays of the two filters together. However, this may lead to false positives since the resulting filter will have more bits set to 1 than either of the individual filters. Another approach is to use a weighted union of the two filters, where the probability of a false positive is minimized.In conclusion, Jeff Garzik's question about merging bloom filters relates to the possibility of combining two distinct filters built by different wallets. Bloom filters are probabilistic data structures that use bit arrays and hash functions to determine if an element is in a set. Merging bloom filters can be done by OR-ing their bit arrays or by using a weighted union to minimize false positives. Additionally, the email thread also includes a promotional message for AppDynamics Lite, a troubleshooting tool designed for Java and .NET code, providing code-level detail for bottlenecks in production. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Gavin-s-post-0-9-TODO-list-.xml b/static/bitcoin-dev/Aug_2013/combined_Gavin-s-post-0-9-TODO-list-.xml index 8bb60168bf..abe2bfe24b 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Gavin-s-post-0-9-TODO-list-.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Gavin-s-post-0-9-TODO-list-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Gavin's post-0.9 TODO list... - 2023-08-01T05:38:37.704362+00:00 + 2025-10-11T21:32:11.415756+00:00 + python-feedgen Mike Hearn 2013-08-19 09:16:12+00:00 @@ -111,13 +112,13 @@ - python-feedgen + 2 Combined summary - Gavin's post-0.9 TODO list... - 2023-08-01T05:38:37.705351+00:00 + 2025-10-11T21:32:11.415961+00:00 - In an email conversation on August 16, 2013, Peter Todd discussed the vulnerabilities of Simplified Payment Verification (SPV) nodes in Bitcoin. According to Todd, SPV honeypots can attract a disproportionate percentage of the total SPV population and be used to harm SPV nodes by dropping transactions deterministically or degrading the capacity of honest nodes. He suggested that creating fake transactions with the same scriptPubKeys and amounts as the dropped ones could lock users out of their money. Todd also raised concerns about bitcoinj's protection against peers flooding users with useless unconfirmed transactions that match the bloom filter.Warren Togami Jr. suggested a method to mitigate DoS attacks on Bitcoin nodes by limiting the number of TCP connections from a single IP address or subnet using an iptables firewall-based example. However, this method is too complicated for most people to deploy and may block legitimate connections. Peter Todd suggested the application of IP diversity tests for outgoing connections to incoming connections as the code is already available.Mike Hearn proposed the development of an anti-Denial of Service (DoS) framework for Bitcoin. This framework would include measures to make it easier for people to contribute back to the network, such as allowing SPV nodes with spare bandwidth to relay whole blocks to reduce the load on full-nodes. Additionally, SPV peers with bandwidth could do bloom filtering on behalf of peers that don't have spare bandwidth. Making it easier to run a full node was also suggested, and partial mode was proposed as the way to go here. Finally, possession proof needs to be created to prevent miners from mining blocks with fee paying transactions without actually having the full UTXO set.The email thread discusses the need for anti-DoS measures in Bitcoin. Warren Togami suggests using source IP or subnet connection limits to make it more expensive for attackers to use a single host to exhaust a target node's resources. This measure would be easy to audit and improve the current situation where there are no limits. However, it does not eliminate the risk of a network-wide connection exhaustion attack by a determined attacker.Mike Hearn suggests automated heuristic driven prioritization as a better long-term solution to anti-DoS measures. Meanwhile, Gavin Andresen lists three non-0.9 codes he is working on, including smarter fee handling, "first double-spend" relaying and alerting, and whitepapers on increasing or removing the 1MB block size limit.Gavin Andresen also mentioned his plans for development in the Bitcoin network. He is working on three non-0.9 code projects: smarter fee handling on the client side, "first double-spend" relaying and alerting for low-value transactions, and whitepapers addressing the need to increase or remove the 1MB block size limit. He generated scatter-plots and histograms to gain insight into miner policies regarding transaction fees versus priorities.The email thread highlights concerns and developments regarding the security and scalability of the Bitcoin network. The community is actively working on implementing anti-DoS measures and exploring ways to increase the block size limit while ensuring decentralization and network integrity. 2013-08-19T09:16:12+00:00 + In an email conversation on August 16, 2013, Peter Todd discussed the vulnerabilities of Simplified Payment Verification (SPV) nodes in Bitcoin. According to Todd, SPV honeypots can attract a disproportionate percentage of the total SPV population and be used to harm SPV nodes by dropping transactions deterministically or degrading the capacity of honest nodes. He suggested that creating fake transactions with the same scriptPubKeys and amounts as the dropped ones could lock users out of their money. Todd also raised concerns about bitcoinj's protection against peers flooding users with useless unconfirmed transactions that match the bloom filter.Warren Togami Jr. suggested a method to mitigate DoS attacks on Bitcoin nodes by limiting the number of TCP connections from a single IP address or subnet using an iptables firewall-based example. However, this method is too complicated for most people to deploy and may block legitimate connections. Peter Todd suggested the application of IP diversity tests for outgoing connections to incoming connections as the code is already available.Mike Hearn proposed the development of an anti-Denial of Service (DoS) framework for Bitcoin. This framework would include measures to make it easier for people to contribute back to the network, such as allowing SPV nodes with spare bandwidth to relay whole blocks to reduce the load on full-nodes. Additionally, SPV peers with bandwidth could do bloom filtering on behalf of peers that don't have spare bandwidth. Making it easier to run a full node was also suggested, and partial mode was proposed as the way to go here. Finally, possession proof needs to be created to prevent miners from mining blocks with fee paying transactions without actually having the full UTXO set.The email thread discusses the need for anti-DoS measures in Bitcoin. Warren Togami suggests using source IP or subnet connection limits to make it more expensive for attackers to use a single host to exhaust a target node's resources. This measure would be easy to audit and improve the current situation where there are no limits. However, it does not eliminate the risk of a network-wide connection exhaustion attack by a determined attacker.Mike Hearn suggests automated heuristic driven prioritization as a better long-term solution to anti-DoS measures. Meanwhile, Gavin Andresen lists three non-0.9 codes he is working on, including smarter fee handling, "first double-spend" relaying and alerting, and whitepapers on increasing or removing the 1MB block size limit.Gavin Andresen also mentioned his plans for development in the Bitcoin network. He is working on three non-0.9 code projects: smarter fee handling on the client side, "first double-spend" relaying and alerting for low-value transactions, and whitepapers addressing the need to increase or remove the 1MB block size limit. He generated scatter-plots and histograms to gain insight into miner policies regarding transaction fees versus priorities.The email thread highlights concerns and developments regarding the security and scalability of the Bitcoin network. The community is actively working on implementing anti-DoS measures and exploring ways to increase the block size limit while ensuring decentralization and network integrity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_HTTP-REST-API-for-bitcoind.xml b/static/bitcoin-dev/Aug_2013/combined_HTTP-REST-API-for-bitcoind.xml index 4ba20419dc..ae71cbc7c9 100644 --- a/static/bitcoin-dev/Aug_2013/combined_HTTP-REST-API-for-bitcoind.xml +++ b/static/bitcoin-dev/Aug_2013/combined_HTTP-REST-API-for-bitcoind.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - HTTP REST API for bitcoind - 2023-08-01T05:22:02.236718+00:00 + 2025-10-11T21:32:36.916497+00:00 + python-feedgen Rune Kjær Svendsen 2013-08-10 20:30:46+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - HTTP REST API for bitcoind - 2023-08-01T05:22:02.236718+00:00 + 2025-10-11T21:32:36.916733+00:00 - The conversation revolves around implementing an HTTP REST wrapper around bitcoind's RPC interface in Python. The goal is to create a simple HTTP server that can translate HTTP GET requests into relevant RPC request and respond with the required data. There is a discussion about adding usual HTTP authentication/SSL stuff to the REST API so that SPV users could decide to run their own instance of the API. It was suggested that a trusted party could set up the server for users of Bitcoin Wallet. However, it was argued that anyone who wants HTTP authentication or TLS can wrap it with nginx or something similar and put appropriate restrictions in place on incoming requests to keep it secure.In an email exchange between Andreas Schildbach and Mark, they propose adding HTTP authentication/SSL to the REST API so that SPV users can run their own instance of the API or a trusted party can set up a server. Andreas suggests he would be willing to set it up for users of Bitcoin Wallet. Pieter Wuille expresses concern about the security risks and potential DoS risks associated with exposing an HTTP-based interface publicly. On the other hand, Michael argues that there are benefits to having a REST interface that is exposed publicly. While there is support for the HTTP interface, it is suggested that it be used only for trusted local applications and debugging.Andy Parkins suggests reducing the blockchain storage requirement for SPV clients to allow more nodes to participate in the network and reduce the load on full nodes. Peter Todd proposes a "Partial UTXO" mode where miners don't need to keep the entire chain as long as they don't mine transactions spending unverified UTXOs. They discuss the security risks of relying on unauthenticated UTXO data and the need for UTXO commitments. They also discuss the difference between SPV and full security and the benefits of fetching blocks by transactions.In another conversation between Andreas Schildbach and Pieter Wuille, they discuss the possibility of adding HTTP authentication/SSL to the REST API for SPV users to run their own instance or for trusted parties to set up servers. Wuille expresses concern about the security risks and potential DoS risks of exposing the HTTP-based interface publicly. He suggests that the HTTP interface should only be used for trusted local applications and debugging.Peter Todd proposes exposing the UTXO set of a given address to enable SPV wallets to sweep previously unknown private keys. However, this is deemed undesirable due to increased resource usage and vulnerability to DoS attacks. Todd suggests adding HTTP authentication/SSL to the REST API instead. They also discuss the use of address-indexed UXTOs and the issues with relying on unauthenticated data. They consider paper wallets as a potential solution but note some inherent problems.The conversation discusses the use of REST API for SPV clients, the benefits of reducing the blockchain storage requirement, and the security risks associated with exposing an HTTP-based interface publicly. The discussion also covers the need for authenticated UTXO data and the challenges of maintaining a headers-only blockchain. There is debate about the involvement of the blockchain in verifying transactions and the importance of the UTXO set. Finally, there is a suggestion to add a new URL to trace the providence of any transaction without needing to maintain the entire chain.In a discussion on the Bitcoin development mailing list, the addition of a URL for tracing the providence of any transaction without maintaining the entire blockchain was suggested. This feature would be beneficial for Simplified Payment Verification (SPV) clients. However, it was clarified that no such index is maintained by default and enabling "-txindex" is necessary to access it.Another proposal was made to expose the Unspent Transaction Output (UTXO) set of a given address. While this would be useful for SPV wallets to sweep previously unknown private keys, it was noted that there is currently no way to authenticate this data, which could potentially lead to fraudulent transactions.Jeff Garzik proposed the addition of an HTTP REST API for bitcoind, which would provide external access to transaction, address, and block indices. This would enable decentralized block explorer capabilities. The first two implemented API calls allow for simple queries based on block or transaction hash. The aim of this interface is to provide unauthenticated, public blockchain information, with no plans to add wallet interfacing or manipulation via this API.A recent pull request on Github further supports the implementation of the HTTP REST API for bitcoind. It suggests adding features like Accept and Accept-Encoding headers, as well as an API version number in the URL. Additionally, having APIs corresponding to Bitcoin addr and version messages would be helpful for certain use cases.Overall, the goal of the proposed HTTP REST API is to provide easy access to unauthenticated, public blockchain information. It does not include wallet interfacing or manipulation capabilities and has received positive feedback from developers interested in utilizing the API for their projects. 2013-08-10T20:30:46+00:00 + The conversation revolves around implementing an HTTP REST wrapper around bitcoind's RPC interface in Python. The goal is to create a simple HTTP server that can translate HTTP GET requests into relevant RPC request and respond with the required data. There is a discussion about adding usual HTTP authentication/SSL stuff to the REST API so that SPV users could decide to run their own instance of the API. It was suggested that a trusted party could set up the server for users of Bitcoin Wallet. However, it was argued that anyone who wants HTTP authentication or TLS can wrap it with nginx or something similar and put appropriate restrictions in place on incoming requests to keep it secure.In an email exchange between Andreas Schildbach and Mark, they propose adding HTTP authentication/SSL to the REST API so that SPV users can run their own instance of the API or a trusted party can set up a server. Andreas suggests he would be willing to set it up for users of Bitcoin Wallet. Pieter Wuille expresses concern about the security risks and potential DoS risks associated with exposing an HTTP-based interface publicly. On the other hand, Michael argues that there are benefits to having a REST interface that is exposed publicly. While there is support for the HTTP interface, it is suggested that it be used only for trusted local applications and debugging.Andy Parkins suggests reducing the blockchain storage requirement for SPV clients to allow more nodes to participate in the network and reduce the load on full nodes. Peter Todd proposes a "Partial UTXO" mode where miners don't need to keep the entire chain as long as they don't mine transactions spending unverified UTXOs. They discuss the security risks of relying on unauthenticated UTXO data and the need for UTXO commitments. They also discuss the difference between SPV and full security and the benefits of fetching blocks by transactions.In another conversation between Andreas Schildbach and Pieter Wuille, they discuss the possibility of adding HTTP authentication/SSL to the REST API for SPV users to run their own instance or for trusted parties to set up servers. Wuille expresses concern about the security risks and potential DoS risks of exposing the HTTP-based interface publicly. He suggests that the HTTP interface should only be used for trusted local applications and debugging.Peter Todd proposes exposing the UTXO set of a given address to enable SPV wallets to sweep previously unknown private keys. However, this is deemed undesirable due to increased resource usage and vulnerability to DoS attacks. Todd suggests adding HTTP authentication/SSL to the REST API instead. They also discuss the use of address-indexed UXTOs and the issues with relying on unauthenticated data. They consider paper wallets as a potential solution but note some inherent problems.The conversation discusses the use of REST API for SPV clients, the benefits of reducing the blockchain storage requirement, and the security risks associated with exposing an HTTP-based interface publicly. The discussion also covers the need for authenticated UTXO data and the challenges of maintaining a headers-only blockchain. There is debate about the involvement of the blockchain in verifying transactions and the importance of the UTXO set. Finally, there is a suggestion to add a new URL to trace the providence of any transaction without needing to maintain the entire chain.In a discussion on the Bitcoin development mailing list, the addition of a URL for tracing the providence of any transaction without maintaining the entire blockchain was suggested. This feature would be beneficial for Simplified Payment Verification (SPV) clients. However, it was clarified that no such index is maintained by default and enabling "-txindex" is necessary to access it.Another proposal was made to expose the Unspent Transaction Output (UTXO) set of a given address. While this would be useful for SPV wallets to sweep previously unknown private keys, it was noted that there is currently no way to authenticate this data, which could potentially lead to fraudulent transactions.Jeff Garzik proposed the addition of an HTTP REST API for bitcoind, which would provide external access to transaction, address, and block indices. This would enable decentralized block explorer capabilities. The first two implemented API calls allow for simple queries based on block or transaction hash. The aim of this interface is to provide unauthenticated, public blockchain information, with no plans to add wallet interfacing or manipulation via this API.A recent pull request on Github further supports the implementation of the HTTP REST API for bitcoind. It suggests adding features like Accept and Accept-Encoding headers, as well as an API version number in the URL. Additionally, having APIs corresponding to Bitcoin addr and version messages would be helpful for certain use cases.Overall, the goal of the proposed HTTP REST API is to provide easy access to unauthenticated, public blockchain information. It does not include wallet interfacing or manipulation capabilities and has received positive feedback from developers interested in utilizing the API for their projects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Idea-for-new-payment-protocol-PKI.xml b/static/bitcoin-dev/Aug_2013/combined_Idea-for-new-payment-protocol-PKI.xml index ac38b0d53d..2949aa3c13 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Idea-for-new-payment-protocol-PKI.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Idea-for-new-payment-protocol-PKI.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Idea for new payment protocol PKI - 2023-08-01T05:35:53.164496+00:00 + 2025-10-11T21:32:07.166309+00:00 + python-feedgen Melvin Carvalho 2013-08-09 12:18:37+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Idea for new payment protocol PKI - 2023-08-01T05:35:53.164496+00:00 + 2025-10-11T21:32:07.166535+00:00 - In an email exchange from August 2013, Wendell and Mike Hearn discussed the potential of using a blockchain-based single sign-on (SSO) system. Wendell mentioned exploring esoteric blockchain+signature-based SSO implementations as discussed by John Light and others. He has been using SSO for years using an X.509 private key in his browser with his public key referenced in his homepage. However, X.509 tends to use RSA, and bitcoin tends to use ECC for space reasons. Mike Hearn noted that Mozilla Persona, an infrastructure for web-based SSO, works by having email providers sign temporary certificates for their users, whose browsers then sign server-provided challenges to prove their email address. Despite Persona using a different type of encryption than bitcoin, an implementation is likely to be quite easy. From the user's perspective, their wallet app would embed a browser and drive it as if it were signing into a website, but stop after the user is signed into Persona and a user cert has been provisioned. It can then sign payment requests automatically. For many users, it would only require one click, making it a more convenient option than obtaining a certificate for an email address from a certificate authority (CA). Hearn also discussed the concerns and advantages of using Persona. While Persona increases reliance on trusted third parties by storing keys and passwords on Mozilla's servers or email providers, Hearn believes that Persona has the potential to improve its security and decentralization over time. Users also have the option to run their own IDP on a personal server to avoid involvement with Mozilla's servers. Hearn highlighted that DNS, although centralized, has held up well so far, and Persona integrates with Google/Yahoo SSO systems until it becomes big enough to remove centralized structures and become transparently decentralized. Furthermore, Hearn compared Persona to X.509 certificates issued by CAs. While X.509 certs can be issued for any arbitrary string, obtaining one from a CA can be challenging, making them less suitable for widespread end-user adoption compared to Persona. Despite being easier to use, Persona is not more or less centralized than other PKIs. Ultimately, the user at host pair string requires centralization via DNS, and SSL must connect to it to verify assertions, meaning that the regular SSL PKI is still present under the hood.In summary, the email exchange discussed the potential use of Persona as a blockchain-based SSO system. Persona works by having email providers sign temporary certificates for users, providing a convenient and professional user experience. While Persona increases reliance on trusted third parties, there is potential for improved security and decentralization over time. Users have the option to run their own IDP on a personal server to avoid involvement with Mozilla's servers. Compared to X.509 certificates issued by CAs, Persona offers ease of use and wider end-user adoption. 2013-08-09T12:18:37+00:00 + In an email exchange from August 2013, Wendell and Mike Hearn discussed the potential of using a blockchain-based single sign-on (SSO) system. Wendell mentioned exploring esoteric blockchain+signature-based SSO implementations as discussed by John Light and others. He has been using SSO for years using an X.509 private key in his browser with his public key referenced in his homepage. However, X.509 tends to use RSA, and bitcoin tends to use ECC for space reasons. Mike Hearn noted that Mozilla Persona, an infrastructure for web-based SSO, works by having email providers sign temporary certificates for their users, whose browsers then sign server-provided challenges to prove their email address. Despite Persona using a different type of encryption than bitcoin, an implementation is likely to be quite easy. From the user's perspective, their wallet app would embed a browser and drive it as if it were signing into a website, but stop after the user is signed into Persona and a user cert has been provisioned. It can then sign payment requests automatically. For many users, it would only require one click, making it a more convenient option than obtaining a certificate for an email address from a certificate authority (CA). Hearn also discussed the concerns and advantages of using Persona. While Persona increases reliance on trusted third parties by storing keys and passwords on Mozilla's servers or email providers, Hearn believes that Persona has the potential to improve its security and decentralization over time. Users also have the option to run their own IDP on a personal server to avoid involvement with Mozilla's servers. Hearn highlighted that DNS, although centralized, has held up well so far, and Persona integrates with Google/Yahoo SSO systems until it becomes big enough to remove centralized structures and become transparently decentralized. Furthermore, Hearn compared Persona to X.509 certificates issued by CAs. While X.509 certs can be issued for any arbitrary string, obtaining one from a CA can be challenging, making them less suitable for widespread end-user adoption compared to Persona. Despite being easier to use, Persona is not more or less centralized than other PKIs. Ultimately, the user at host pair string requires centralization via DNS, and SSL must connect to it to verify assertions, meaning that the regular SSL PKI is still present under the hood.In summary, the email exchange discussed the potential use of Persona as a blockchain-based SSO system. Persona works by having email providers sign temporary certificates for users, providing a convenient and professional user experience. While Persona increases reliance on trusted third parties, there is potential for improved security and decentralization over time. Users have the option to run their own IDP on a personal server to avoid involvement with Mozilla's servers. Compared to X.509 certificates issued by CAs, Persona offers ease of use and wider end-user adoption. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_LevelDB-in-master.xml b/static/bitcoin-dev/Aug_2013/combined_LevelDB-in-master.xml index 88562e9b82..2731d3c79e 100644 --- a/static/bitcoin-dev/Aug_2013/combined_LevelDB-in-master.xml +++ b/static/bitcoin-dev/Aug_2013/combined_LevelDB-in-master.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - LevelDB in master - 2023-08-01T05:39:23.219655+00:00 + 2025-10-11T21:32:19.911690+00:00 + python-feedgen Pieter Wuille 2013-08-17 20:53:36+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - LevelDB in master - 2023-08-01T05:39:23.219655+00:00 + 2025-10-11T21:32:19.911856+00:00 - On August 16, 2013, a pull request (#2702) was merged into the master branch of Ripple, but instead of updating to LevelDB 1.12.0, it was put on an unofficial Ripple fork of LevelDB. Vinnie had mentioned this change, but its full implications were not understood. Initially, it was believed that the "Ripple and Bitcoin fork" was just LevelDB with the necessary changes already made. However, it was later discovered that there were additional changes included in the merge.This improper merge by Ripple's fork resulted in a break in git history, causing several upstream fixes, including ones reported to the Bitcoin issue tracker, to be excluded. To address this issue, Luke-Jr pushed three branches to https://github.com/luke-jr/leveldb: bitcoin-1.5 for reference, bitcoin (included in 0.8.x), and bitcoin-up (merged with upstream LevelDB 1.12). A diff from the current master branch (Ripple LevelDB 1.12 fork) to bitcoin-up can be accessed at https://gist.github.com/luke-jr/6248543.Although the changes in the merge appeared harmless, Pieter Todd suggested reverting to a codebase that closely matched upstream LevelDB 1.12. A comparison between the bitcoin head and bitcoin-up revealed that a few patches were reverted during the merge window of version 0.9. To clean up the history of the LevelDB subtree in the http://github.com/bitcoin/leveldb repository, Pieter created a branch called bitcoin-fork and used git-subtree to create a pull request (#2907). This pull request switches the src/leveldb directory to the cleaned-up tree, listing the reverted changes in a squashed commit that corresponds to the actual diff produced by Luke-Jr.Peter Todd, who had encountered a similar issue while auditing Litecoin, commented on the situation. He noted that there are currently no tools available to audit whether a set of git patches/merges match upstream or downstream. While manually checking individual files could be done, automating this process would be beneficial.In summary, a pull request merged into the master branch of Ripple resulted in it being put on an unofficial Ripple fork of LevelDB instead of updating to LevelDB 1.12.0. This merge included additional changes beyond what was initially believed, and Ripple's improper git merge created a break in history, excluding several upstream fixes. Luke-Jr pushed three branches for reference, and a diff between the current master branch and bitcoin-up can be found via the provided link. Pieter Todd suggested reverting to a codebase closer to upstream LevelDB 1.12, and he cleaned up the history of the LevelDB subtree in the bitcoin repository. Peter Todd also highlighted the need for tools to automate the auditing of git patches/merges. 2013-08-17T20:53:36+00:00 + On August 16, 2013, a pull request (#2702) was merged into the master branch of Ripple, but instead of updating to LevelDB 1.12.0, it was put on an unofficial Ripple fork of LevelDB. Vinnie had mentioned this change, but its full implications were not understood. Initially, it was believed that the "Ripple and Bitcoin fork" was just LevelDB with the necessary changes already made. However, it was later discovered that there were additional changes included in the merge.This improper merge by Ripple's fork resulted in a break in git history, causing several upstream fixes, including ones reported to the Bitcoin issue tracker, to be excluded. To address this issue, Luke-Jr pushed three branches to https://github.com/luke-jr/leveldb: bitcoin-1.5 for reference, bitcoin (included in 0.8.x), and bitcoin-up (merged with upstream LevelDB 1.12). A diff from the current master branch (Ripple LevelDB 1.12 fork) to bitcoin-up can be accessed at https://gist.github.com/luke-jr/6248543.Although the changes in the merge appeared harmless, Pieter Todd suggested reverting to a codebase that closely matched upstream LevelDB 1.12. A comparison between the bitcoin head and bitcoin-up revealed that a few patches were reverted during the merge window of version 0.9. To clean up the history of the LevelDB subtree in the http://github.com/bitcoin/leveldb repository, Pieter created a branch called bitcoin-fork and used git-subtree to create a pull request (#2907). This pull request switches the src/leveldb directory to the cleaned-up tree, listing the reverted changes in a squashed commit that corresponds to the actual diff produced by Luke-Jr.Peter Todd, who had encountered a similar issue while auditing Litecoin, commented on the situation. He noted that there are currently no tools available to audit whether a set of git patches/merges match upstream or downstream. While manually checking individual files could be done, automating this process would be beneficial.In summary, a pull request merged into the master branch of Ripple resulted in it being put on an unofficial Ripple fork of LevelDB instead of updating to LevelDB 1.12.0. This merge included additional changes beyond what was initially believed, and Ripple's improper git merge created a break in history, excluding several upstream fixes. Luke-Jr pushed three branches for reference, and a diff between the current master branch and bitcoin-up can be found via the provided link. Pieter Todd suggested reverting to a codebase closer to upstream LevelDB 1.12, and he cleaned up the history of the LevelDB subtree in the bitcoin repository. Peter Todd also highlighted the need for tools to automate the auditing of git patches/merges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Making-bitcoin-traceability-harder.xml b/static/bitcoin-dev/Aug_2013/combined_Making-bitcoin-traceability-harder.xml index 6b03ed4798..5a37f86203 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Making-bitcoin-traceability-harder.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Making-bitcoin-traceability-harder.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Making bitcoin traceability harder - 2023-08-01T05:41:28.039053+00:00 + 2025-10-11T21:32:22.033983+00:00 + python-feedgen Faré 2013-08-21 15:10:55+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Making bitcoin traceability harder - 2023-08-01T05:41:28.039053+00:00 + 2025-10-11T21:32:22.034135+00:00 - Bitcoin developers are facing a shortage of testers and full-time contributors, leading to delays in implementing new functionality. In August 2013, Bitcoin developer Luke-Jr highlighted the need for more developers and suggested that people could contribute by testing existing features rather than adding new ones.Addressing the issue of privacy, Luke-Jr emphasized the importance of using single-use addresses. He explained that keeping change amounts as powers of two would harm privacy and potentially upset users. To address transaction fees, he proposed that they could be paid separately through small-bucket transactions.Luke-Jr acknowledged that it is already recommended to use a unique payment address for each transaction. However, he noted that merchants might consider using multiple addresses or coins as a privacy extension, although he questioned if it was urgent enough to be worthwhile.In response to a user's suggestion, the developers agreed that addresses should only be used once to enhance privacy and minimize the ability to trace transactions. They appreciated ideas such as using power-of-two amounts for transactions but cautioned that it may not necessarily improve privacy.While the use of unique payment addresses for each transaction is considered best practice, Bitcoin-Qt's "Receive coins" tab could be improved to discourage address reuse. The idea of merchants using multiple addresses or coins for a single payment was seen as a potential privacy extension, but it was not deemed an urgent issue.Another letter to bitcoin developers proposed enforcing discipline by trading only power-of-two amounts of satoshis in use-once wallets, except for public donation addresses. This approach aims to make tracking harder by reducing the ability to trace who does what. Although the specific discipline may not be the best implementation, the letter suggests that some form of discipline should be enforced to enhance tracing difficulties.The letter also suggests that merchants generate new addresses for each transaction, and customers send appropriately sized buckets of satoshis to each address. Establishing a standard way to specify an amount and a list of addresses as a payment target may require higher resolution QR codes. It is mentioned that this idea has been previously considered, but it is unclear if it was accepted or rejected. 2013-08-21T15:10:55+00:00 + Bitcoin developers are facing a shortage of testers and full-time contributors, leading to delays in implementing new functionality. In August 2013, Bitcoin developer Luke-Jr highlighted the need for more developers and suggested that people could contribute by testing existing features rather than adding new ones.Addressing the issue of privacy, Luke-Jr emphasized the importance of using single-use addresses. He explained that keeping change amounts as powers of two would harm privacy and potentially upset users. To address transaction fees, he proposed that they could be paid separately through small-bucket transactions.Luke-Jr acknowledged that it is already recommended to use a unique payment address for each transaction. However, he noted that merchants might consider using multiple addresses or coins as a privacy extension, although he questioned if it was urgent enough to be worthwhile.In response to a user's suggestion, the developers agreed that addresses should only be used once to enhance privacy and minimize the ability to trace transactions. They appreciated ideas such as using power-of-two amounts for transactions but cautioned that it may not necessarily improve privacy.While the use of unique payment addresses for each transaction is considered best practice, Bitcoin-Qt's "Receive coins" tab could be improved to discourage address reuse. The idea of merchants using multiple addresses or coins for a single payment was seen as a potential privacy extension, but it was not deemed an urgent issue.Another letter to bitcoin developers proposed enforcing discipline by trading only power-of-two amounts of satoshis in use-once wallets, except for public donation addresses. This approach aims to make tracking harder by reducing the ability to trace who does what. Although the specific discipline may not be the best implementation, the letter suggests that some form of discipline should be enforced to enhance tracing difficulties.The letter also suggests that merchants generate new addresses for each transaction, and customers send appropriately sized buckets of satoshis to each address. Establishing a standard way to specify an amount and a list of addresses as a payment target may require higher resolution QR codes. It is mentioned that this idea has been previously considered, but it is unclear if it was accepted or rejected. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_More-appropriate-XDG-menu-category-for-bitcoin-qt.xml b/static/bitcoin-dev/Aug_2013/combined_More-appropriate-XDG-menu-category-for-bitcoin-qt.xml index ccb1b42a90..cf6f119890 100644 --- a/static/bitcoin-dev/Aug_2013/combined_More-appropriate-XDG-menu-category-for-bitcoin-qt.xml +++ b/static/bitcoin-dev/Aug_2013/combined_More-appropriate-XDG-menu-category-for-bitcoin-qt.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - More appropriate XDG menu category for bitcoin-qt - 2023-08-01T05:33:47.583262+00:00 + 2025-10-11T21:32:30.527709+00:00 + python-feedgen Kip Warner 2013-09-15 18:28:19+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - More appropriate XDG menu category for bitcoin-qt - 2023-08-01T05:33:47.583262+00:00 + 2025-10-11T21:32:30.527889+00:00 - In September 2013, Matt Corallo announced the release of version 0.8.5 of Bitcoin, after a delay for which he apologized. This new version included a new category and could be downloaded from the Bitcoin Github repository. Kip Warner, a software engineer, expressed gratitude to Matt for the update and shared his contact information, with a preference for OpenPGP encrypted/signed mail.Following this, Kip Warner proposed refining the "Office" category in the bitcoin-qt application's XDG desktop integration to "Finance" in a mailing list post. He pointed out that XDG's menu specification allowed for such a modification. Although acknowledging his limited knowledge of Git, he suggested modifying the line in bitcoin-qt.desktop to read "Categories=Office;Finance;" However, he did not provide a patch himself.In response, Matt announced the pull request at https://github.com/bitcoin/bitcoin/pull/2999, which included the implementation of the new category. The discussion regarding this change took place on the Bitcoin-development mailing list.The bitcoin-qt application's XDG desktop integration currently places itself under the "Office" menu category on certain desktop environments. However, there is a suggestion to refine this categorization to "Finance" based on XDG's menu specification. This would allow for a more specific classification. The proposed modification to the bitcoin-qt.desktop file is to include the line "Categories=Office;Finance." The author of the proposal apologized for not providing the patch himself due to his limited knowledge of Git. 2013-09-15T18:28:19+00:00 + In September 2013, Matt Corallo announced the release of version 0.8.5 of Bitcoin, after a delay for which he apologized. This new version included a new category and could be downloaded from the Bitcoin Github repository. Kip Warner, a software engineer, expressed gratitude to Matt for the update and shared his contact information, with a preference for OpenPGP encrypted/signed mail.Following this, Kip Warner proposed refining the "Office" category in the bitcoin-qt application's XDG desktop integration to "Finance" in a mailing list post. He pointed out that XDG's menu specification allowed for such a modification. Although acknowledging his limited knowledge of Git, he suggested modifying the line in bitcoin-qt.desktop to read "Categories=Office;Finance;" However, he did not provide a patch himself.In response, Matt announced the pull request at https://github.com/bitcoin/bitcoin/pull/2999, which included the implementation of the new category. The discussion regarding this change took place on the Bitcoin-development mailing list.The bitcoin-qt application's XDG desktop integration currently places itself under the "Office" menu category on certain desktop environments. However, there is a suggestion to refine this categorization to "Finance" based on XDG's menu specification. This would allow for a more specific classification. The proposed modification to the bitcoin-qt.desktop file is to include the line "Categories=Office;Finance." The author of the proposal apologized for not providing the patch himself due to his limited knowledge of Git. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_NODE-BLOOM-BIP.xml b/static/bitcoin-dev/Aug_2013/combined_NODE-BLOOM-BIP.xml index 81e46b3209..dd8154a5ca 100644 --- a/static/bitcoin-dev/Aug_2013/combined_NODE-BLOOM-BIP.xml +++ b/static/bitcoin-dev/Aug_2013/combined_NODE-BLOOM-BIP.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - NODE_BLOOM BIP - 2023-08-01T05:40:01.527535+00:00 + 2025-10-11T21:32:47.546112+00:00 + python-feedgen Peter Todd 2013-08-18 23:11:09+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - NODE_BLOOM BIP - 2023-08-01T05:40:01.527535+00:00 + 2025-10-11T21:32:47.546247+00:00 - In August 2013, Gavin Andresen and Mike had an email conversation discussing the idea of a NODE_BLOOM service bit and persistent node-specific identifiers. Gavin expressed concerns about making certain parts of the protocol optional, as it could have negative effects on privacy and decentralization. He also pointed out that adding more bits would require extensive testing by QA teams. However, they agreed that options were necessary for contributing to relaying and network health, and edge cases like disabling bloom filtering would still be tested.During the same discussion, Mike argued against making Bloom filtering optional, stating that it is not a lossless function and making every possible feature optional is not smart design. He drew a comparison to BitTorrent, where making re-sharing optional would hinder optimal functionality. This suggests that certain features should be mandatory for optimal operation.Both Mike and Gavin opposed the proposed NODE_BLOOM service bit and agreed that making different parts of the protocol optional would have negative consequences. Gavin specifically mentioned his opposition to the NODE_BLOOM bit and stated that he doesn't know much about NODE_BLOCK bits either. They emphasized the importance of privacy and decentralization in the Bitcoin protocol.The author of the email is opposing a proposed BIP called "NODE_BLOOM service bit," which aims to extend BIP 37 by introducing a service bit for Bloom filters. The author argues against making every possible feature optional and notes that there are currently no nodes that cannot support this feature. The proposed BIP suggests using the protocol bit NODE_BLOOM to explicitly advertise support for Bloom filters. It also proposes backward compatibility and specifies that nodes not supporting Bloom filters should disconnect peers who send Bloom filter-related messages. The proposal also suggests that DNS seeds and other discovery mechanisms support specifying required services. The document is in the public domain, and a reference implementation can be found on GitHub.In summary, this context discusses a proposal for a new BIP called "NODE_BLOOM service bit," which aims to extend BIP 37 by introducing a protocol bit for advertising support for Bloom filters. The discussion involves arguments against making parts of the protocol optional, concerns about privacy and decentralization, and the proposed changes for improving the granularity of services provided by nodes to the public. 2013-08-18T23:11:09+00:00 + In August 2013, Gavin Andresen and Mike had an email conversation discussing the idea of a NODE_BLOOM service bit and persistent node-specific identifiers. Gavin expressed concerns about making certain parts of the protocol optional, as it could have negative effects on privacy and decentralization. He also pointed out that adding more bits would require extensive testing by QA teams. However, they agreed that options were necessary for contributing to relaying and network health, and edge cases like disabling bloom filtering would still be tested.During the same discussion, Mike argued against making Bloom filtering optional, stating that it is not a lossless function and making every possible feature optional is not smart design. He drew a comparison to BitTorrent, where making re-sharing optional would hinder optimal functionality. This suggests that certain features should be mandatory for optimal operation.Both Mike and Gavin opposed the proposed NODE_BLOOM service bit and agreed that making different parts of the protocol optional would have negative consequences. Gavin specifically mentioned his opposition to the NODE_BLOOM bit and stated that he doesn't know much about NODE_BLOCK bits either. They emphasized the importance of privacy and decentralization in the Bitcoin protocol.The author of the email is opposing a proposed BIP called "NODE_BLOOM service bit," which aims to extend BIP 37 by introducing a service bit for Bloom filters. The author argues against making every possible feature optional and notes that there are currently no nodes that cannot support this feature. The proposed BIP suggests using the protocol bit NODE_BLOOM to explicitly advertise support for Bloom filters. It also proposes backward compatibility and specifies that nodes not supporting Bloom filters should disconnect peers who send Bloom filter-related messages. The proposal also suggests that DNS seeds and other discovery mechanisms support specifying required services. The document is in the public domain, and a reference implementation can be found on GitHub.In summary, this context discusses a proposal for a new BIP called "NODE_BLOOM service bit," which aims to extend BIP 37 by introducing a protocol bit for advertising support for Bloom filters. The discussion involves arguments against making parts of the protocol optional, concerns about privacy and decentralization, and the proposed changes for improving the granularity of services provided by nodes to the public. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Optional-wallet-linkable-address-format-Re-request-.xml b/static/bitcoin-dev/Aug_2013/combined_Optional-wallet-linkable-address-format-Re-request-.xml index ee85539d4e..70cedae25e 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Optional-wallet-linkable-address-format-Re-request-.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Optional-wallet-linkable-address-format-Re-request-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Optional "wallet-linkable" address format (Re-request) - 2023-08-01T05:36:10.860931+00:00 + Combined summary - Optional "wallet-linkable" address format (Re-request) + 2025-10-11T21:32:28.407539+00:00 + python-feedgen Gavin Andresen 2013-08-09 21:51:00+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 - Combined summary - Optional "wallet-linkable" address format (Re-request) - 2023-08-01T05:36:10.860931+00:00 + Combined summary - Optional "wallet-linkable" address format (Re-request) + 2025-10-11T21:32:28.407708+00:00 - The discussion on the Bitcoin-development mailing list revolves around the payment protocol and alternate address serialization. The payment protocol is designed to be easily extensible and can include additional fields like "publickey" and "multiplier" in the PaymentDetails or Output messages. This allows the server to send more information to the wallet software. The alternate address serialization proposed in the discussion aims to provide better security by preserving privacy and allowing the sender to send reliable payment addresses without the risk of MITM attacks or compromise.Developers are implementing multi-chain ideas, which require significant effort to support compared to the simple alternate encoding. This may pose challenges for developers of lightweight clients and add extra burden on users to manage their wallets. BIP 32 specifies how to use the first three tree levels (M/i/j/k), but it does not cover the generation of multiple receive chains or separate ledgers and balances. The developers discuss various proposals for generating and receiving payments into BIP32-style addresses, including passing Kpar and cpar or using static public keys for persistent identity and security.In the discussion, Alan Reiner suggests an alternate address serialization that can be safely ignored by others and supports independent address chains for individual relationships. Mike Hearn mentions that the payment protocol is locked down for v1 and suggests an extension to send payment requests containing public keys+chain codes for push-style payments without recipient interaction. Jeremy Spilman proposes sharing the public key and chain code from [m/i'/0] for receiving payments at [m/i'/0/k]. The discussion also explores the idea of using static public keys for persistent identity and security. The developers agree that if designing for long-term relationships, a mechanism for generating address chains could be built in to eliminate the need for further communication after the initial exchange. They also discuss the possibility of supporting separate ledgers and balances for sub-wallets. The email exchange highlights the importance of balancing developer complexity and interface complexity while achieving the desired functionality. The goal is to improve security and convenience without complicating the wallet. 2013-08-09T21:51:00+00:00 + The discussion on the Bitcoin-development mailing list revolves around the payment protocol and alternate address serialization. The payment protocol is designed to be easily extensible and can include additional fields like "publickey" and "multiplier" in the PaymentDetails or Output messages. This allows the server to send more information to the wallet software. The alternate address serialization proposed in the discussion aims to provide better security by preserving privacy and allowing the sender to send reliable payment addresses without the risk of MITM attacks or compromise.Developers are implementing multi-chain ideas, which require significant effort to support compared to the simple alternate encoding. This may pose challenges for developers of lightweight clients and add extra burden on users to manage their wallets. BIP 32 specifies how to use the first three tree levels (M/i/j/k), but it does not cover the generation of multiple receive chains or separate ledgers and balances. The developers discuss various proposals for generating and receiving payments into BIP32-style addresses, including passing Kpar and cpar or using static public keys for persistent identity and security.In the discussion, Alan Reiner suggests an alternate address serialization that can be safely ignored by others and supports independent address chains for individual relationships. Mike Hearn mentions that the payment protocol is locked down for v1 and suggests an extension to send payment requests containing public keys+chain codes for push-style payments without recipient interaction. Jeremy Spilman proposes sharing the public key and chain code from [m/i'/0] for receiving payments at [m/i'/0/k]. The discussion also explores the idea of using static public keys for persistent identity and security. The developers agree that if designing for long-term relationships, a mechanism for generating address chains could be built in to eliminate the need for further communication after the initial exchange. They also discuss the possibility of supporting separate ledgers and balances for sub-wallets. The email exchange highlights the importance of balancing developer complexity and interface complexity while achieving the desired functionality. The goal is to improve security and convenience without complicating the wallet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Payment-Protocol-BIP-70-71-72.xml b/static/bitcoin-dev/Aug_2013/combined_Payment-Protocol-BIP-70-71-72.xml index 7a7a28f17f..8f51480e5c 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Payment-Protocol-BIP-70-71-72.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Payment-Protocol-BIP-70-71-72.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol: BIP 70, 71, 72 - 2023-08-01T05:29:54.664873+00:00 + 2025-10-11T21:32:24.157068+00:00 + python-feedgen Peter Todd 2013-09-26 06:37:19+00:00 @@ -171,13 +172,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol: BIP 70, 71, 72 - 2023-08-01T05:29:54.664873+00:00 + 2025-10-11T21:32:24.157279+00:00 - In a series of discussions among Bitcoin developers, various topics related to payment protocols, wallet functionality, and the use of URIs for transactions were explored. One topic of discussion was the potential for a Man-in-the-Middle (MITM) attack on the HTTPS protocol, which could exploit flaws in the SSL PKI infrastructure and harm Bitcoin. It was suggested that implementing a payment protocol using the SSL PKI infrastructure could help identify weaknesses and motivate improvements.The possibility of MITM attacks in the context of Bitcoin URIs was also raised, with some companies using data loss prevention products with MITM capability. While the incentive for governments or large corporations to carry out such attacks may be low, detecting transactions could be more useful than meddling with them. Difficulties in using QR codes, especially under low light conditions, were also discussed, prompting suggestions for alternative approaches such as short URLs.The conversation touched on the security risks related to certificate authorities and MITM attacks, with HTTPS being seen as protective against certain attacks but not those involving scanning QR codes in person. The need for trust in HTTPS was debated, with one developer arguing that seeing a partner in person should eliminate the need for a certificate. However, concerns about the subversion of certificate authorities and the potential theft of funds due to broken certificates were also raised.Developers explored ways to make QR codes more scannable and reduce their size. Suggestions included changing parameters and exploring the use of BIP70 once available. The importance of HTTPS and the potential benefits of using the payments protocol were emphasized.The flexibility of the BIP72 specification was updated to allow for more options in processing transactions. Existing point-of-sale systems were identified as potential beneficiaries of the payments protocol, although concerns were raised about compatibility issues. The debate over Bitcoin URIs and the potential advantages of payment URIs was discussed, with considerations for proper payment infrastructure and the inclusion of 'SHOULDs' and 'MAYs' instead of 'MUSTs' in the specification.Additional discussions centered on wallet functionality, including concerns about wallets without P2P protocol support and the handling of locked inputs. The responsibility of confirming transactions and preventing their announcement to the network was also debated.Overall, these discussions demonstrate the ongoing development and considerations within the Bitcoin community regarding payment protocols, wallet functionality, and the use of URIs for transactions. Various suggestions were made to enhance security, improve scannability, and ensure backward compatibility. 2013-09-26T06:37:19+00:00 + In a series of discussions among Bitcoin developers, various topics related to payment protocols, wallet functionality, and the use of URIs for transactions were explored. One topic of discussion was the potential for a Man-in-the-Middle (MITM) attack on the HTTPS protocol, which could exploit flaws in the SSL PKI infrastructure and harm Bitcoin. It was suggested that implementing a payment protocol using the SSL PKI infrastructure could help identify weaknesses and motivate improvements.The possibility of MITM attacks in the context of Bitcoin URIs was also raised, with some companies using data loss prevention products with MITM capability. While the incentive for governments or large corporations to carry out such attacks may be low, detecting transactions could be more useful than meddling with them. Difficulties in using QR codes, especially under low light conditions, were also discussed, prompting suggestions for alternative approaches such as short URLs.The conversation touched on the security risks related to certificate authorities and MITM attacks, with HTTPS being seen as protective against certain attacks but not those involving scanning QR codes in person. The need for trust in HTTPS was debated, with one developer arguing that seeing a partner in person should eliminate the need for a certificate. However, concerns about the subversion of certificate authorities and the potential theft of funds due to broken certificates were also raised.Developers explored ways to make QR codes more scannable and reduce their size. Suggestions included changing parameters and exploring the use of BIP70 once available. The importance of HTTPS and the potential benefits of using the payments protocol were emphasized.The flexibility of the BIP72 specification was updated to allow for more options in processing transactions. Existing point-of-sale systems were identified as potential beneficiaries of the payments protocol, although concerns were raised about compatibility issues. The debate over Bitcoin URIs and the potential advantages of payment URIs was discussed, with considerations for proper payment infrastructure and the inclusion of 'SHOULDs' and 'MAYs' instead of 'MUSTs' in the specification.Additional discussions centered on wallet functionality, including concerns about wallets without P2P protocol support and the handling of locked inputs. The responsibility of confirming transactions and preventing their announcement to the network was also debated.Overall, these discussions demonstrate the ongoing development and considerations within the Bitcoin community regarding payment protocols, wallet functionality, and the use of URIs for transactions. Various suggestions were made to enhance security, improve scannability, and ensure backward compatibility. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Preparing-for-the-Cryptopocalypse.xml b/static/bitcoin-dev/Aug_2013/combined_Preparing-for-the-Cryptopocalypse.xml index b8d3e7856e..114b6fa490 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Preparing-for-the-Cryptopocalypse.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Preparing-for-the-Cryptopocalypse.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Preparing for the Cryptopocalypse - 2023-08-01T05:34:42.611872+00:00 + 2025-10-11T21:32:05.042934+00:00 + python-feedgen Mike Hearn 2013-08-06 11:09:38+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Preparing for the Cryptopocalypse - 2023-08-01T05:34:42.612872+00:00 + 2025-10-11T21:32:05.043079+00:00 - Bitcoin currently does not use post-quantum schemes due to their poor space/bandwidth usage properties. However, post-QC schemes based on Regev's LWE assumption are becoming more competitive with traditional schemes. The improvement in technology suggests that by the time quantum computing becomes a real problem, we could have devices with better capabilities.In an email exchange, Peter Vessenes discusses the security of digital signature schemes with a colleague. He mentions that NTRU is one of the few NIST-recommended post-quantum resistant algorithms, but also notes that Lamport signatures are simpler, faster, and intuitively secure under both classical and quantum computation. However, Lamport signatures have poor space/bandwidth usage properties, making them unsuitable for use in Bitcoin. Vessenes questions the claim that elliptic curve cryptography (ECC) is significantly more secure than RSA, considering the problems underlying these encryption methods are related. There are concerns about breakthroughs that could give index-calculus level performance for general elliptic curves.The discussion revolves around the comparison of ECDLP and RSA/factoring problems in light of quantum computing. The relationship between the two problems is said to be the same from the perspective of quantum computers, but it is unclear whether this relationship holds outside the realm of QCs. NTRU, a lattice-based algorithm, is discussed as an option for layering on Bitcoin from a crypto standpoint, although its signature algorithm was broken last year. Lamport signatures are suggested as alternatives if they are ever broken.In a conversation between Peter Vessenes and someone else, Vessenes discusses the possibility of layering NTRU onto Bitcoin. Despite the broken NTRUsign algorithm, Vessenes believes that it could still be acceptable for Bitcoin as long as only one signature is created per key. If NTRUsign fails, there are alternatives such as Lamport signatures.Jeffrey Hoffstein, one of the creators of NTRU, informs Peter that it is one of the few NIST-recommended quantum computing-resistant algorithms. They discuss the possibility of layering NTRU onto Bitcoin, and Peter believes it can be relatively easy to achieve. However, there are still other questions beyond cryptography that need to be addressed.A member of the Bitcoin development mailing list expresses skepticism regarding the superiority of elliptic curve cryptography (ECC) over RSA. He posits that factoring and discrete logarithm problem (DLP) are intimately related in quantum computing, meaning breaking one could lead to breaking the other. It is unclear whether this relationship holds outside of quantum computing. Despite his skepticism, he acknowledges a good presentation on advances in cryptography but is not convinced that ECC is the solution.A recent presentation about advances in cryptography covers various aspects of the field, including its history, modern cryptographic techniques, and their applications in the digital landscape. The presentation explains symmetric and asymmetric key encryption, hashing for data integrity, and modern techniques like elliptic curve cryptography, homomorphic encryption, and post-quantum cryptography. It also discusses practical applications such as secure email communication, messaging, file sharing, and online payments with examples of popular tools and protocols. Overall, it provides a comprehensive overview of cryptography's importance in securing digital communication. 2013-08-06T11:09:38+00:00 + Bitcoin currently does not use post-quantum schemes due to their poor space/bandwidth usage properties. However, post-QC schemes based on Regev's LWE assumption are becoming more competitive with traditional schemes. The improvement in technology suggests that by the time quantum computing becomes a real problem, we could have devices with better capabilities.In an email exchange, Peter Vessenes discusses the security of digital signature schemes with a colleague. He mentions that NTRU is one of the few NIST-recommended post-quantum resistant algorithms, but also notes that Lamport signatures are simpler, faster, and intuitively secure under both classical and quantum computation. However, Lamport signatures have poor space/bandwidth usage properties, making them unsuitable for use in Bitcoin. Vessenes questions the claim that elliptic curve cryptography (ECC) is significantly more secure than RSA, considering the problems underlying these encryption methods are related. There are concerns about breakthroughs that could give index-calculus level performance for general elliptic curves.The discussion revolves around the comparison of ECDLP and RSA/factoring problems in light of quantum computing. The relationship between the two problems is said to be the same from the perspective of quantum computers, but it is unclear whether this relationship holds outside the realm of QCs. NTRU, a lattice-based algorithm, is discussed as an option for layering on Bitcoin from a crypto standpoint, although its signature algorithm was broken last year. Lamport signatures are suggested as alternatives if they are ever broken.In a conversation between Peter Vessenes and someone else, Vessenes discusses the possibility of layering NTRU onto Bitcoin. Despite the broken NTRUsign algorithm, Vessenes believes that it could still be acceptable for Bitcoin as long as only one signature is created per key. If NTRUsign fails, there are alternatives such as Lamport signatures.Jeffrey Hoffstein, one of the creators of NTRU, informs Peter that it is one of the few NIST-recommended quantum computing-resistant algorithms. They discuss the possibility of layering NTRU onto Bitcoin, and Peter believes it can be relatively easy to achieve. However, there are still other questions beyond cryptography that need to be addressed.A member of the Bitcoin development mailing list expresses skepticism regarding the superiority of elliptic curve cryptography (ECC) over RSA. He posits that factoring and discrete logarithm problem (DLP) are intimately related in quantum computing, meaning breaking one could lead to breaking the other. It is unclear whether this relationship holds outside of quantum computing. Despite his skepticism, he acknowledges a good presentation on advances in cryptography but is not convinced that ECC is the solution.A recent presentation about advances in cryptography covers various aspects of the field, including its history, modern cryptographic techniques, and their applications in the digital landscape. The presentation explains symmetric and asymmetric key encryption, hashing for data integrity, and modern techniques like elliptic curve cryptography, homomorphic encryption, and post-quantum cryptography. It also discusses practical applications such as secure email communication, messaging, file sharing, and online payments with examples of popular tools and protocols. Overall, it provides a comprehensive overview of cryptography's importance in securing digital communication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Proposal-remove-getwork-RPC-from-bitcoind.xml b/static/bitcoin-dev/Aug_2013/combined_Proposal-remove-getwork-RPC-from-bitcoind.xml index 59ddd35179..aef213ed20 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Proposal-remove-getwork-RPC-from-bitcoind.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Proposal-remove-getwork-RPC-from-bitcoind.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Proposal: remove "getwork" RPC from bitcoind - 2023-08-01T05:41:10.522292+00:00 + Combined summary - Proposal: remove "getwork" RPC from bitcoind + 2025-10-11T21:32:34.779501+00:00 + python-feedgen Wladimir 2013-08-22 15:30:13+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 - Combined summary - Proposal: remove "getwork" RPC from bitcoind - 2023-08-01T05:41:10.522292+00:00 + Combined summary - Proposal: remove "getwork" RPC from bitcoind + 2025-10-11T21:32:34.779670+00:00 - The Bitcoin development community has proposed removing the getwork API and replacing it with a more decentralized and efficient alternative called getblocktemplate. This suggestion has raised concerns about the impact on individual novice miners and the potential favoring of pool operators and private mining interests. However, it has been noted that getblocktemplate offers everything that getwork does and more, making it a better choice for mining. The consensus among the community is to remove getwork but replace it with a proper getblocktemplate miner, such as Luke's bfgminer, to ensure the provision of a full network node. This change aims to address technical problems and provide a more efficient and decentralized mining solution.The proposal to remove the getwork RPC from Bitcoind is driven by its declining usage. Currently, most users on the mainnet utilize pools instead of directly connecting to Bitcoind via getwork. For those who do solo mine, they communicate with Bitcoind through a pool server using getblocktemplate or other methods. Solo mining on the mainnet using getwork has been found to result in delays and issues. While getwork may still work on the testnet, there are alternative options available, such as open-source pool servers or p2pool. As a result, supporting getwork is no longer necessary. Jeff Garzik, a Senior Software Engineer at BitPay, has proposed the removal of getwork and is seeking feedback to ensure important use cases are not overlooked.In August 2013, there was strong opposition to the removal of getwork from Frank F., who argued that getwork was crucial for maintaining the peer-to-peer nature of Bitcoin. He believed that removing getwork would favor pool operators and private mining interests, potentially leading to a monopolistic or cartel model. Frank also expressed concern about denying novice miners the ability to mine at a small scale, which could have negative consequences for Bitcoin's future. In response, Pieter clarified that getblocktemplate addressed the technical issues of getwork and offered even more decentralization-friendly features.In conclusion, while the removal of getwork could lead Bitcoin towards a monopolistic model, it is argued that getblocktemplate provides the same functionality and more. Instead of completely abandoning getwork, efforts should be made to address and fix its technical problems. This would ensure a more efficient and decentralized mining solution for the Bitcoin network. 2013-08-22T15:30:13+00:00 + The Bitcoin development community has proposed removing the getwork API and replacing it with a more decentralized and efficient alternative called getblocktemplate. This suggestion has raised concerns about the impact on individual novice miners and the potential favoring of pool operators and private mining interests. However, it has been noted that getblocktemplate offers everything that getwork does and more, making it a better choice for mining. The consensus among the community is to remove getwork but replace it with a proper getblocktemplate miner, such as Luke's bfgminer, to ensure the provision of a full network node. This change aims to address technical problems and provide a more efficient and decentralized mining solution.The proposal to remove the getwork RPC from Bitcoind is driven by its declining usage. Currently, most users on the mainnet utilize pools instead of directly connecting to Bitcoind via getwork. For those who do solo mine, they communicate with Bitcoind through a pool server using getblocktemplate or other methods. Solo mining on the mainnet using getwork has been found to result in delays and issues. While getwork may still work on the testnet, there are alternative options available, such as open-source pool servers or p2pool. As a result, supporting getwork is no longer necessary. Jeff Garzik, a Senior Software Engineer at BitPay, has proposed the removal of getwork and is seeking feedback to ensure important use cases are not overlooked.In August 2013, there was strong opposition to the removal of getwork from Frank F., who argued that getwork was crucial for maintaining the peer-to-peer nature of Bitcoin. He believed that removing getwork would favor pool operators and private mining interests, potentially leading to a monopolistic or cartel model. Frank also expressed concern about denying novice miners the ability to mine at a small scale, which could have negative consequences for Bitcoin's future. In response, Pieter clarified that getblocktemplate addressed the technical issues of getwork and offered even more decentralization-friendly features.In conclusion, while the removal of getwork could lead Bitcoin towards a monopolistic model, it is argued that getblocktemplate provides the same functionality and more. Instead of completely abandoning getwork, efforts should be made to address and fix its technical problems. This would ensure a more efficient and decentralized mining solution for the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_SPV-client-in-pure-JavaScript-.xml b/static/bitcoin-dev/Aug_2013/combined_SPV-client-in-pure-JavaScript-.xml index 6a8634d1d5..224e9c1ba0 100644 --- a/static/bitcoin-dev/Aug_2013/combined_SPV-client-in-pure-JavaScript-.xml +++ b/static/bitcoin-dev/Aug_2013/combined_SPV-client-in-pure-JavaScript-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SPV client in pure JavaScript? - 2023-08-01T05:35:31.687089+00:00 + 2025-10-11T21:32:45.424627+00:00 + python-feedgen Chris Double 2013-08-13 05:26:50+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - SPV client in pure JavaScript? - 2023-08-01T05:35:31.687089+00:00 + 2025-10-11T21:32:45.424791+00:00 - In an email thread dated August 10, 2013, Mike Hearn mentioned that Chrome apps/extensions can establish raw TCP socket connections using the API introduced by Google in November 2012. He provided a link to the blog where this API is explained. The W3C has also proposed a Raw Sockets specification that includes TCP sockets. Firefox OS has an API under discussion that could be part of this standardization effort. This suggests that a standardized approach for establishing raw TCP socket connections may emerge in the future.In an email conversation on August 9, 2013, Wendell expressed his excitement over a demo application called "wally". However, Jeff Garzik clarified that the application is just a command line client to prove a technology. The main development is taking place in platforms like "node-libcoin" where a wallet platform is being developed. BitPay is committed to the blockchain engine side of bitcoind while also catering to the enterprise wallet needs which do not necessarily align with standard bitcoind wallet. The future use of bitcoin in large enterprises requires advanced features such as multi-sig, P2SH etc. Managers, CEOs, and other functionaries at corporations may have their own wallets/keyrings and cooperate to sign large value, high security bitcoin multi-sig transactions.In a discussion thread, Jeff Garzik mentioned that BitPay is working on a wallet using node.js JavaScript called wally. Wendell from GrabHive asked how BitPay is going to put this wallet to use. Wendell asked about whether an SPV wallet could be built entirely in JavaScript and how it could be safely distributed for use. Jeff Garzik replied that BitPay was working on a similar project called wally using node.js JavaScript instead of browser JavaScript. The software is open source and available on GitHub.Packaged app pages always load locally, providing independence from the network. Once installed, users have full control over the app's lifecycle and can quickly open, close or fully uninstall them. These apps are launched and maintained from within Chrome itself, making them more similar to native apps. Technical stuff could be made to work within the context of the limited API, thereby making it an interesting and user-friendly way to distribute Bitcoin wallets. Additionally, Chrome apps/extensions can make raw TCP socket connections. Packaged apps provide support for USB access which HTML5 may not support anytime soon.Chrome apps and extensions can make raw TCP socket connections using the TCP Listen API, although they are not standard APIs. HTML5 is unlikely to support USB access anytime soon, but packaged Chrome apps do. Packaged apps have their own windows, run offline, and are more similar to native apps. Code that runs inside NativeClient has the same access level as JavaScript, but it is a way to do things faster. Chrome for mobile does not do apps at the moment, and users are still limited by the APIs Chrome exposes. Wendell suggests using special browser features and bundling them in an app platform like Chrome. Mike Hearn believes that this approach uses Chrome as the app platform instead of a JVM, which assumes that more users have Chrome than a JVM. However, users who do not have Chrome would probably hesitate to install an entire browser to run a wallet app. Hearn also believes that using JavaScript outside the browser results in less safety, performance, features, and mature tools compared to languages/platforms designed for it.NativeClient code has the same access level as JavaScript and can be used to execute things faster. Chrome app distribution via the Chrome store is a viable option, but it has its pros and cons. The APIs Chrome exposes are a strict subset of what a real OS provides, limiting what users can do with the app. Wendell suggests using special browser features to bundle the wallet in Chrome, but Mike Hearn says that a web app cannot make raw TCP socket connections due to restrictions. However, browser-specific things like extensions or installable apps can give code greater access permissions, essentially using Chrome as an app platform instead of a JVM. But, this means that users would need to install an entire browser to run the wallet app, which could deter some. Mike does not find this design compelling because JavaScript is less safe, performs worse, has fewer features, and lacks mature tools compared to other languages/platforms.The conversation is about creating a wallet application that would be usable on the web. While it's possible to use JavaScript for this purpose, building a wallet in a web app presents challenges because web apps aren't allowed to make raw TCP socket connections. One potential solution is using browser-specific features like extensions or "installable apps" to give code greater access permissions. Chrome has a "Native Client" plug-in that could be used for an SPV implementation, but this goes off-topic from the original subject. The challenge with using Chrome as an app platform instead of a JVM is that users who don't have Chrome installed may not want to install it solely to run a wallet app 2013-08-13T05:26:50+00:00 + In an email thread dated August 10, 2013, Mike Hearn mentioned that Chrome apps/extensions can establish raw TCP socket connections using the API introduced by Google in November 2012. He provided a link to the blog where this API is explained. The W3C has also proposed a Raw Sockets specification that includes TCP sockets. Firefox OS has an API under discussion that could be part of this standardization effort. This suggests that a standardized approach for establishing raw TCP socket connections may emerge in the future.In an email conversation on August 9, 2013, Wendell expressed his excitement over a demo application called "wally". However, Jeff Garzik clarified that the application is just a command line client to prove a technology. The main development is taking place in platforms like "node-libcoin" where a wallet platform is being developed. BitPay is committed to the blockchain engine side of bitcoind while also catering to the enterprise wallet needs which do not necessarily align with standard bitcoind wallet. The future use of bitcoin in large enterprises requires advanced features such as multi-sig, P2SH etc. Managers, CEOs, and other functionaries at corporations may have their own wallets/keyrings and cooperate to sign large value, high security bitcoin multi-sig transactions.In a discussion thread, Jeff Garzik mentioned that BitPay is working on a wallet using node.js JavaScript called wally. Wendell from GrabHive asked how BitPay is going to put this wallet to use. Wendell asked about whether an SPV wallet could be built entirely in JavaScript and how it could be safely distributed for use. Jeff Garzik replied that BitPay was working on a similar project called wally using node.js JavaScript instead of browser JavaScript. The software is open source and available on GitHub.Packaged app pages always load locally, providing independence from the network. Once installed, users have full control over the app's lifecycle and can quickly open, close or fully uninstall them. These apps are launched and maintained from within Chrome itself, making them more similar to native apps. Technical stuff could be made to work within the context of the limited API, thereby making it an interesting and user-friendly way to distribute Bitcoin wallets. Additionally, Chrome apps/extensions can make raw TCP socket connections. Packaged apps provide support for USB access which HTML5 may not support anytime soon.Chrome apps and extensions can make raw TCP socket connections using the TCP Listen API, although they are not standard APIs. HTML5 is unlikely to support USB access anytime soon, but packaged Chrome apps do. Packaged apps have their own windows, run offline, and are more similar to native apps. Code that runs inside NativeClient has the same access level as JavaScript, but it is a way to do things faster. Chrome for mobile does not do apps at the moment, and users are still limited by the APIs Chrome exposes. Wendell suggests using special browser features and bundling them in an app platform like Chrome. Mike Hearn believes that this approach uses Chrome as the app platform instead of a JVM, which assumes that more users have Chrome than a JVM. However, users who do not have Chrome would probably hesitate to install an entire browser to run a wallet app. Hearn also believes that using JavaScript outside the browser results in less safety, performance, features, and mature tools compared to languages/platforms designed for it.NativeClient code has the same access level as JavaScript and can be used to execute things faster. Chrome app distribution via the Chrome store is a viable option, but it has its pros and cons. The APIs Chrome exposes are a strict subset of what a real OS provides, limiting what users can do with the app. Wendell suggests using special browser features to bundle the wallet in Chrome, but Mike Hearn says that a web app cannot make raw TCP socket connections due to restrictions. However, browser-specific things like extensions or installable apps can give code greater access permissions, essentially using Chrome as an app platform instead of a JVM. But, this means that users would need to install an entire browser to run the wallet app, which could deter some. Mike does not find this design compelling because JavaScript is less safe, performs worse, has fewer features, and lacks mature tools compared to other languages/platforms.The conversation is about creating a wallet application that would be usable on the web. While it's possible to use JavaScript for this purpose, building a wallet in a web app presents challenges because web apps aren't allowed to make raw TCP socket connections. One potential solution is using browser-specific features like extensions or "installable apps" to give code greater access permissions. Chrome has a "Native Client" plug-in that could be used for an SPV implementation, but this goes off-topic from the original subject. The challenge with using Chrome as an app platform instead of a JVM is that users who don't have Chrome installed may not want to install it solely to run a wallet app - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Safe-auto-updating.xml b/static/bitcoin-dev/Aug_2013/combined_Safe-auto-updating.xml index 02baed467e..4be8b0e455 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Safe-auto-updating.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Safe-auto-updating.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Safe auto-updating - 2023-08-01T05:34:56.228075+00:00 + 2025-10-11T21:32:13.544171+00:00 + python-feedgen Mike Hearn 2013-08-07 08:41:54+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Safe auto-updating - 2023-08-01T05:34:56.229027+00:00 + 2025-10-11T21:32:13.544332+00:00 - In response to Wendell's query, members of the Bitcoin-development mailing list provide suggestions and recommendations for implementing an auto-updater in Hive's wallet app. One proposed solution involves using a distributor public key hardcoded in the software, where client software only trusts signed data from that key. The private key for this data should be kept offline, and when executing an upgrade, new checksums are signed offline and uploaded to the distribution server. Even if the server is compromised, the client-side software will not accept a bogus checksum because it won't bear the right signature.The discussion also highlights the importance of including digital signing in package authentication, rather than relying solely on a checksum. It is noted that a compromised host can change both the checksum and binaries undetectably. However, if there is a signature made by a key that is not kept on the host, it is impossible to fake a valid binary. This suggestion aims to enhance security and minimize damage in case of compromise.Additionally, the conversation mentions the possibility of implementing a revocation process in the event of the offline key being compromised. This process would involve broadcasting a revocation that forces clients to start rejecting updates from that key. If a compromise is detected, users will receive a warning to manually upgrade the software through trusted channels.While discussing auto-updaters, the thread veers off-topic briefly, with someone sharing information about getting SQL databases under version control. The email thread ends with links provided to the SQL database version control and Bitcoin-development mailing list for further reference. 2013-08-07T08:41:54+00:00 + In response to Wendell's query, members of the Bitcoin-development mailing list provide suggestions and recommendations for implementing an auto-updater in Hive's wallet app. One proposed solution involves using a distributor public key hardcoded in the software, where client software only trusts signed data from that key. The private key for this data should be kept offline, and when executing an upgrade, new checksums are signed offline and uploaded to the distribution server. Even if the server is compromised, the client-side software will not accept a bogus checksum because it won't bear the right signature.The discussion also highlights the importance of including digital signing in package authentication, rather than relying solely on a checksum. It is noted that a compromised host can change both the checksum and binaries undetectably. However, if there is a signature made by a key that is not kept on the host, it is impossible to fake a valid binary. This suggestion aims to enhance security and minimize damage in case of compromise.Additionally, the conversation mentions the possibility of implementing a revocation process in the event of the offline key being compromised. This process would involve broadcasting a revocation that forces clients to start rejecting updates from that key. If a compromise is detected, users will receive a warning to manually upgrade the software through trusted channels.While discussing auto-updaters, the thread veers off-topic briefly, with someone sharing information about getting SQL databases under version control. The email thread ends with links provided to the SQL database version control and Bitcoin-development mailing list for further reference. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Two-factor-wallet-with-one-time-passwords.xml b/static/bitcoin-dev/Aug_2013/combined_Two-factor-wallet-with-one-time-passwords.xml index 0772c2ff83..ead3500588 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Two-factor-wallet-with-one-time-passwords.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Two-factor-wallet-with-one-time-passwords.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Two factor wallet with one-time-passwords - 2023-08-01T05:26:19.294015+00:00 + 2025-10-11T21:32:43.300532+00:00 + python-feedgen Peter Todd 2013-08-08 18:20:14+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Two factor wallet with one-time-passwords - 2023-08-01T05:26:19.294015+00:00 + 2025-10-11T21:32:43.300711+00:00 - In a mailing list conversation, Peter Todd discusses the importance of careful handling of incoming funds in a multi-party wallet to prevent attackers from deceiving users into sending funds to the wrong address. He suggests that funds sent to the wallet should be divided into separate authorization amounts by all parties involved in authorizing outgoing payments. Todd also mentions that providing customers with a physical private key, such as on a sheet of paper, could be legally desirable for transferring large amounts of Bitcoin.Todd further explains that with multi-factor wallets, the customer provides one or more keys, while the final key is given to them on a sheet of paper with instructions to scan it on their phone via a QR code. Another method could involve using one-time passwords, with the final approval done over the phone by sharing certain "magic words" with the customer to unlock their funds. Although there is still a risk of funds being locked due to an error, there isn't a financial incentive for it to happen. Todd expresses disappointment that OP_EVAL was not implemented, as it would have allowed customers to provide a P2SH script to easily unlock funds.On July 28, 2013, a discussion was held on the Bitcoin development mailing list regarding minor scripting language additions to implement merklized abstract syntax tree (MAST) support. Peter Todd proposed a version where scriptPubKey's can be reused by verifying the path. He also highlighted the drawback of large storage requirements for wallets. In response, another user suggested that the size of the table deriving which H(nonce) is selected for a given txid:vout can be significantly smaller, and nested IF statements can be replaced by creating the merkle tree over the tuples [i,H(nonce_i)] and proving that the provided nonce_i matched the precommitted tree.The author introduces a new implementation of P2SH outputs that allows for the reuse of scriptPubKeys. This implementation involves a merklized abstract syntax tree (MAST) and the use of short 6-word strings as authorization for payment. However, one disadvantage is the large storage requirements for wallets. Nonetheless, both tables can be stored in a distributed hash table in the cloud without compromising security. The security level remains at 2^64, making it difficult for attackers to find a 64-bit pre-image.Gavin Andresen proposed a new design for a wallet that utilizes two-factor authentication through one-time passwords with a third-party service to counter-sign 2-of-2 protected wallets. However, involving a third-party introduces privacy and availability risks. An alternate design eliminates the need for a third-party and offers other advantages and disadvantages. In this design, the user has a wallet with separate balances for savings and day-to-day spending. Transactions from the day-to-day balance do not require authorization, but spending from the savings balance necessitates the use of one-time passwords. When the day-to-day balance becomes low, the user can authorize the movement of discrete multiples of a specific amount from savings to spending using one one-time password per multiple being moved. Savings utilize P2SH outputs that match HASH160 EQUALVERIFY CHECKSIG spent with pubkey/seckey generated deterministically using a counter-based one-time password scheme. Nonces are generated deterministically using RFC2289, and a security level of 64 bits is considered sufficient.It is interesting to note that in certain cases, it may be preferable to have authorization solely focused on spending without any additional involvement. In such cases, the party acting as an oracle does not need to know where the funds are going and can even authorize the spend in advance without two-way communication, potentially prior to the funds being received in the first place. Funding the wallet requires the participation of all parties involved in authorizing an outgoing payment. Additionally, the protection only works if funds sent to the wallet are divided into the discrete authorization amounts desired by the user. These systems, aimed at fund splitting, require further research and development, as they have not received as much attention as payment protocols between customers and merchants. The basic idea is to have multiple devices participate in generating a payment request that is somehow signed. For fund splitting, the request can specify that the funds are paid to multiple transaction outputs simultaneously. 2013-08-08T18:20:14+00:00 + In a mailing list conversation, Peter Todd discusses the importance of careful handling of incoming funds in a multi-party wallet to prevent attackers from deceiving users into sending funds to the wrong address. He suggests that funds sent to the wallet should be divided into separate authorization amounts by all parties involved in authorizing outgoing payments. Todd also mentions that providing customers with a physical private key, such as on a sheet of paper, could be legally desirable for transferring large amounts of Bitcoin.Todd further explains that with multi-factor wallets, the customer provides one or more keys, while the final key is given to them on a sheet of paper with instructions to scan it on their phone via a QR code. Another method could involve using one-time passwords, with the final approval done over the phone by sharing certain "magic words" with the customer to unlock their funds. Although there is still a risk of funds being locked due to an error, there isn't a financial incentive for it to happen. Todd expresses disappointment that OP_EVAL was not implemented, as it would have allowed customers to provide a P2SH script to easily unlock funds.On July 28, 2013, a discussion was held on the Bitcoin development mailing list regarding minor scripting language additions to implement merklized abstract syntax tree (MAST) support. Peter Todd proposed a version where scriptPubKey's can be reused by verifying the path. He also highlighted the drawback of large storage requirements for wallets. In response, another user suggested that the size of the table deriving which H(nonce) is selected for a given txid:vout can be significantly smaller, and nested IF statements can be replaced by creating the merkle tree over the tuples [i,H(nonce_i)] and proving that the provided nonce_i matched the precommitted tree.The author introduces a new implementation of P2SH outputs that allows for the reuse of scriptPubKeys. This implementation involves a merklized abstract syntax tree (MAST) and the use of short 6-word strings as authorization for payment. However, one disadvantage is the large storage requirements for wallets. Nonetheless, both tables can be stored in a distributed hash table in the cloud without compromising security. The security level remains at 2^64, making it difficult for attackers to find a 64-bit pre-image.Gavin Andresen proposed a new design for a wallet that utilizes two-factor authentication through one-time passwords with a third-party service to counter-sign 2-of-2 protected wallets. However, involving a third-party introduces privacy and availability risks. An alternate design eliminates the need for a third-party and offers other advantages and disadvantages. In this design, the user has a wallet with separate balances for savings and day-to-day spending. Transactions from the day-to-day balance do not require authorization, but spending from the savings balance necessitates the use of one-time passwords. When the day-to-day balance becomes low, the user can authorize the movement of discrete multiples of a specific amount from savings to spending using one one-time password per multiple being moved. Savings utilize P2SH outputs that match HASH160 EQUALVERIFY CHECKSIG spent with pubkey/seckey generated deterministically using a counter-based one-time password scheme. Nonces are generated deterministically using RFC2289, and a security level of 64 bits is considered sufficient.It is interesting to note that in certain cases, it may be preferable to have authorization solely focused on spending without any additional involvement. In such cases, the party acting as an oracle does not need to know where the funds are going and can even authorize the spend in advance without two-way communication, potentially prior to the funds being received in the first place. Funding the wallet requires the participation of all parties involved in authorizing an outgoing payment. Additionally, the protection only works if funds sent to the wallet are divided into the discrete authorization amounts desired by the user. These systems, aimed at fund splitting, require further research and development, as they have not received as much attention as payment protocols between customers and merchants. The basic idea is to have multiple devices participate in generating a payment request that is somehow signed. For fund splitting, the request can specify that the funds are paid to multiple transaction outputs simultaneously. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Version-0-9-goals.xml b/static/bitcoin-dev/Aug_2013/combined_Version-0-9-goals.xml index 08d517fcff..05de79b389 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Version-0-9-goals.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Version-0-9-goals.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Version 0.9 goals - 2023-08-01T05:37:14.581013+00:00 + 2025-10-11T21:32:32.653093+00:00 + python-feedgen Wendell 2013-08-15 21:12:59+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Version 0.9 goals - 2023-08-01T05:37:14.581013+00:00 + 2025-10-11T21:32:32.653232+00:00 - In an email conversation, Mike Hearn discussed the implementation of bitcoinj and BitPay taking the lead to promote it. Someone volunteered to add payment protocol support to bitcoinj, and if that doesn't work out, Mike has old code from 2012 that he could update. They hope to release updates for Bitcoin Wallet or MultiBit once bitcoinj has support. BitPay wants to be a leader in supporting the protocol, so they plan to coordinate release dates.There are plans to add payment protocol support into the v1 firmware of Trezor, a hardware wallet. It is believed that Multibit will be the first wallet compatible with Trezor and also supporting payment protocol. Supporting HD wallets is seen as the trickiest part, but progress has been made by Gary and Matija. A basic HD wallet implementation can be done if necessary.In another email exchange, Wladimir expressed agreement with implementing payment protocol, autotools, and a Qt5 build. There were reservations about coin control due to its introduction of statefulness into the wallet model, but as long as the issues are resolved, it can be included. Pieter mentioned that coin control can be helpful in understanding the difference between the high-level abstraction of the wallet and the implementation of individual coins.Gavin Andresen sent an email discussing the upcoming release of Bitcoin version 0.9. Payment Protocol support was ready to be added to the release, along with other features like sipa's "headers first" initial block download optimization and coin control. Wladimir agreed with the inclusion of Payment Protocol, autotools, and Qt5 build, but expressed reservations about coin control.Gavin further discussed the final release of Bitcoin 0.9 and listed the issues that needed to be addressed. He plans on spending time on code review and working on code that may not make it into the 0.9 release. One member provided positive feedback on the email.The developers of Trezor confirmed their plan to support payment protocol in their hardware wallet, calling it a "missing piece in absolute security." They are unsure if it will be included in the initial release or added later through a firmware update.In another email exchange, Pieter, Matt, and the author discussed the success of a new optimization technique called headers first. They also emphasized the importance of shipping payment protocol support in multiple clients simultaneously to make a strong statement. They hope to release updates for Bitcoin Wallet or MultiBit once bitcoinj has support. BitPay expressed interest in being a leader in supporting the protocol.Gavin Andresen announced that they are close to a 0.9 "feature freeze" and listed several items he wants to see included in the final release, including Payment Protocol support, the headers first optimization, and coin control. He plans to spend time on code review and helping with pull requests.Overall, these email exchanges highlight the efforts being made to implement payment protocol support in various Bitcoin clients and hardware wallets. The goal is to ensure maximum impact by coordinating release dates and involving big merchants like BitPay. There are discussions about the challenges and benefits of features like HD wallets, coin control, and optimization techniques. Gavin Andresen is actively involved in the development process, aiming to include important features in the upcoming Bitcoin 0.9 release. 2013-08-15T21:12:59+00:00 + In an email conversation, Mike Hearn discussed the implementation of bitcoinj and BitPay taking the lead to promote it. Someone volunteered to add payment protocol support to bitcoinj, and if that doesn't work out, Mike has old code from 2012 that he could update. They hope to release updates for Bitcoin Wallet or MultiBit once bitcoinj has support. BitPay wants to be a leader in supporting the protocol, so they plan to coordinate release dates.There are plans to add payment protocol support into the v1 firmware of Trezor, a hardware wallet. It is believed that Multibit will be the first wallet compatible with Trezor and also supporting payment protocol. Supporting HD wallets is seen as the trickiest part, but progress has been made by Gary and Matija. A basic HD wallet implementation can be done if necessary.In another email exchange, Wladimir expressed agreement with implementing payment protocol, autotools, and a Qt5 build. There were reservations about coin control due to its introduction of statefulness into the wallet model, but as long as the issues are resolved, it can be included. Pieter mentioned that coin control can be helpful in understanding the difference between the high-level abstraction of the wallet and the implementation of individual coins.Gavin Andresen sent an email discussing the upcoming release of Bitcoin version 0.9. Payment Protocol support was ready to be added to the release, along with other features like sipa's "headers first" initial block download optimization and coin control. Wladimir agreed with the inclusion of Payment Protocol, autotools, and Qt5 build, but expressed reservations about coin control.Gavin further discussed the final release of Bitcoin 0.9 and listed the issues that needed to be addressed. He plans on spending time on code review and working on code that may not make it into the 0.9 release. One member provided positive feedback on the email.The developers of Trezor confirmed their plan to support payment protocol in their hardware wallet, calling it a "missing piece in absolute security." They are unsure if it will be included in the initial release or added later through a firmware update.In another email exchange, Pieter, Matt, and the author discussed the success of a new optimization technique called headers first. They also emphasized the importance of shipping payment protocol support in multiple clients simultaneously to make a strong statement. They hope to release updates for Bitcoin Wallet or MultiBit once bitcoinj has support. BitPay expressed interest in being a leader in supporting the protocol.Gavin Andresen announced that they are close to a 0.9 "feature freeze" and listed several items he wants to see included in the final release, including Payment Protocol support, the headers first optimization, and coin control. He plans to spend time on code review and helping with pull requests.Overall, these email exchanges highlight the efforts being made to implement payment protocol support in various Bitcoin clients and hardware wallets. The goal is to ensure maximum impact by coordinating release dates and involving big merchants like BitPay. There are discussions about the challenges and benefits of features like HD wallets, coin control, and optimization techniques. Gavin Andresen is actively involved in the development process, aiming to include important features in the upcoming Bitcoin 0.9 release. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_Way-to-tell-that-transaction-was-issued-by-a-specific-person-company.xml b/static/bitcoin-dev/Aug_2013/combined_Way-to-tell-that-transaction-was-issued-by-a-specific-person-company.xml index dd384268cd..03659026c5 100644 --- a/static/bitcoin-dev/Aug_2013/combined_Way-to-tell-that-transaction-was-issued-by-a-specific-person-company.xml +++ b/static/bitcoin-dev/Aug_2013/combined_Way-to-tell-that-transaction-was-issued-by-a-specific-person-company.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Way to tell that transaction was issued by a specific person/company - 2023-08-01T05:41:44.831206+00:00 + 2025-10-11T21:32:09.288898+00:00 + python-feedgen Gregory Maxwell 2013-08-23 06:55:32+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Way to tell that transaction was issued by a specific person/company - 2023-08-01T05:41:44.831206+00:00 + 2025-10-11T21:32:09.289027+00:00 - In a 2013 email conversation, Maciej Trebacz proposed a feature to Bitcoin that would allow multiple addresses to be signed with a single private key and include the signature in a transaction. This feature would be beneficial for reputable wallet services as it would enable transactions that require zero confirmations from the other party, ensuring the transaction is from a trusted source that won't attempt double spending. However, another party in the conversation opposed this proposal, citing concerns about privacy implications.The second party argued that adding such a feature would increase transaction size and fees, while also requiring additional effort from other parties to transmit, process, and store the information indefinitely. Furthermore, implementing this feature would expose the identity of one of the transaction parties to the entire world, compromising the privacy of all involved. Privacy in Bitcoin relies on pseudonymous identities in each transaction, which gives it an advantage over centralized payment systems. The second party suggested using the payment protocol instead, as it can provide additional metadata and signatures without compromising privacy. Alternatively, providing users with a signmessaged txid can serve as a promise to pay without the need for highly public communication.Currently, the Bitcoin protocol does not support including arbitrary data in transactions, as this would make them non-standard and unrelatable by clients. As a result, if a user has multiple addresses, they cannot sign them with a single private key and include the signature in the transaction. However, it is suggested that a reputable wallet service could issue transactions requiring zero confirmations by adding a signature to demonstrate trustworthiness, similar to Mt.Gox's "green address."To implement this feature without forking the chain, it is proposed to add support for specific scripts in the protocol. These scripts should not exceed 34 bytes, and further definition is required for their use. While there may be other mechanisms within the Bitcoin protocol that could achieve this, the idea raises the question of whether such a feature should be considered and added to the protocol. 2013-08-23T06:55:32+00:00 + In a 2013 email conversation, Maciej Trebacz proposed a feature to Bitcoin that would allow multiple addresses to be signed with a single private key and include the signature in a transaction. This feature would be beneficial for reputable wallet services as it would enable transactions that require zero confirmations from the other party, ensuring the transaction is from a trusted source that won't attempt double spending. However, another party in the conversation opposed this proposal, citing concerns about privacy implications.The second party argued that adding such a feature would increase transaction size and fees, while also requiring additional effort from other parties to transmit, process, and store the information indefinitely. Furthermore, implementing this feature would expose the identity of one of the transaction parties to the entire world, compromising the privacy of all involved. Privacy in Bitcoin relies on pseudonymous identities in each transaction, which gives it an advantage over centralized payment systems. The second party suggested using the payment protocol instead, as it can provide additional metadata and signatures without compromising privacy. Alternatively, providing users with a signmessaged txid can serve as a promise to pay without the need for highly public communication.Currently, the Bitcoin protocol does not support including arbitrary data in transactions, as this would make them non-standard and unrelatable by clients. As a result, if a user has multiple addresses, they cannot sign them with a single private key and include the signature in the transaction. However, it is suggested that a reputable wallet service could issue transactions requiring zero confirmations by adding a signature to demonstrate trustworthiness, similar to Mt.Gox's "green address."To implement this feature without forking the chain, it is proposed to add support for specific scripts in the protocol. These scripts should not exceed 34 bytes, and further definition is required for their use. While there may be other mechanisms within the Bitcoin protocol that could achieve this, the idea raises the question of whether such a feature should be considered and added to the protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2013/combined_btc-name-server.xml b/static/bitcoin-dev/Aug_2013/combined_btc-name-server.xml index 603941f2e5..d97c886b94 100644 --- a/static/bitcoin-dev/Aug_2013/combined_btc-name-server.xml +++ b/static/bitcoin-dev/Aug_2013/combined_btc-name-server.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - btc name server - 2023-08-01T05:34:15.903864+00:00 + 2025-10-11T21:32:15.668048+00:00 + python-feedgen Jay F 2013-08-03 03:18:31+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - btc name server - 2023-08-01T05:34:15.903864+00:00 + 2025-10-11T21:32:15.668182+00:00 - In an email thread from August 2, 2013, Chris Evans proposes the idea of implementing a name server in the Bitcoin client software that would allow users to assign aliases to wallet IDs. This would enable them to use human-readable names instead of long alphanumeric strings to represent their wallet public key address. The concept is aimed at making it easier for individuals to remember and recall their wallet IDs.However, Rick Wesson raises the concern that there would be no support for using DNS as a mapping tool for names to numbers. Despite this limitation, the Namecoin blockchain's id/ and a/ namespace has been utilized by several actors for storing bitmessage IDs and Bitcoin addresses. Namecoin itself is designed to provide secure identity management, domain name registration, and decentralized data storage through blockchain technology. It also functions as a merge-mined sidechain of Bitcoin, allowing miners to simultaneously mine both chains without additional effort.The email exchange includes a link to an article discussing how to put SQL databases under version control. This suggests that steps can be taken to incorporate version control for SQL databases, similar to the standard practice for application code.Luke, another participant in the discussion, points out that addresses are not intended to be remembered but rather used electronically or through QR codes as single-use destinations for transactions. While Chris's idea of assigning aliases to wallet IDs may seem helpful, Luke argues that Bitcoin already has mechanisms like PGP (Pretty Good Privacy) for person/wallet identity. Additionally, Gavin has been working on a new Payment Protocol that allows users to publish a URI for a website, enabling multiple payments to be made using the same link. Therefore, it appears that Chris's proposed solution has already been addressed by these existing mechanisms.Overall, while the idea of having aliases for wallet IDs may initially appear beneficial, it is ultimately deemed unnecessary given the current mechanisms available for addressing and identity purposes within the Bitcoin ecosystem. 2013-08-03T03:18:31+00:00 + In an email thread from August 2, 2013, Chris Evans proposes the idea of implementing a name server in the Bitcoin client software that would allow users to assign aliases to wallet IDs. This would enable them to use human-readable names instead of long alphanumeric strings to represent their wallet public key address. The concept is aimed at making it easier for individuals to remember and recall their wallet IDs.However, Rick Wesson raises the concern that there would be no support for using DNS as a mapping tool for names to numbers. Despite this limitation, the Namecoin blockchain's id/ and a/ namespace has been utilized by several actors for storing bitmessage IDs and Bitcoin addresses. Namecoin itself is designed to provide secure identity management, domain name registration, and decentralized data storage through blockchain technology. It also functions as a merge-mined sidechain of Bitcoin, allowing miners to simultaneously mine both chains without additional effort.The email exchange includes a link to an article discussing how to put SQL databases under version control. This suggests that steps can be taken to incorporate version control for SQL databases, similar to the standard practice for application code.Luke, another participant in the discussion, points out that addresses are not intended to be remembered but rather used electronically or through QR codes as single-use destinations for transactions. While Chris's idea of assigning aliases to wallet IDs may seem helpful, Luke argues that Bitcoin already has mechanisms like PGP (Pretty Good Privacy) for person/wallet identity. Additionally, Gavin has been working on a new Payment Protocol that allows users to publish a URI for a website, enabling multiple payments to be made using the same link. Therefore, it appears that Chris's proposed solution has already been addressed by these existing mechanisms.Overall, while the idea of having aliases for wallet IDs may initially appear beneficial, it is ultimately deemed unnecessary given the current mechanisms available for addressing and identity purposes within the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_-ANN-High-speed-Bitcoin-Relay-Network.xml b/static/bitcoin-dev/Aug_2014/combined_-ANN-High-speed-Bitcoin-Relay-Network.xml index 1d0ee987c5..27101ab71b 100644 --- a/static/bitcoin-dev/Aug_2014/combined_-ANN-High-speed-Bitcoin-Relay-Network.xml +++ b/static/bitcoin-dev/Aug_2014/combined_-ANN-High-speed-Bitcoin-Relay-Network.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [ANN] High-speed Bitcoin Relay Network - 2023-08-01T06:29:55.353699+00:00 + 2025-10-11T22:00:10.765965+00:00 + python-feedgen Matt Corallo 2014-08-03 00:56:54+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - [ANN] High-speed Bitcoin Relay Network - 2023-08-01T06:29:55.353699+00:00 + 2025-10-11T22:00:10.766155+00:00 - To improve the efficiency and speed of relaying Bitcoin data, users can now peer with public relay nodes. These relay nodes are located in different regions such as us-west, us-east, eu, au, or jpy. To connect to a relay node, users need to add "public.REGION.relay.mattcorallo.com" to their addnode list.Each relay node can be connected to either port 8334 or 8335, with the former only relaying blocks and the latter relaying both blocks and transactions. While the relay nodes do perform some data verification to prevent Denial of Service attacks (DoS), they do not fully verify the data they are relaying. Therefore, it is crucial for users to never mine a block based solely on a relayed block without conducting their own thorough verification using a bitcoin validator.The relay nodes do not follow the standard inv-getdata-tx/block flow; instead, they relay transactions and blocks immediately after performing cursory verification. It is important to understand that the relay nodes are not meant to replace the standard P2P network but rather to complement it. They are designed to augment the existing network and should not be relied upon to ensure that users never miss any data. There may be instances where the relay nodes fail to relay certain transactions. Furthermore, if a user disconnects and then reconnects, any missed data will not be sent again by the relay nodes. Therefore, it is still advisable to have peers on the standard P2P network.For important node operators such as merchants, exchanges, and large miners who wish to have access to relay nodes with fewer peers, there is a form available on the website to request additional domain names. The source code for the relay nodes can be found on GitHub, allowing users to review and contribute to their development.Users are encouraged to provide feedback, voice concerns, or make suggestions by emailing bitcoin-peering at mattcorallo.com. This helps in improving the relay node system and addressing any issues that may arise. 2014-08-03T00:56:54+00:00 + To improve the efficiency and speed of relaying Bitcoin data, users can now peer with public relay nodes. These relay nodes are located in different regions such as us-west, us-east, eu, au, or jpy. To connect to a relay node, users need to add "public.REGION.relay.mattcorallo.com" to their addnode list.Each relay node can be connected to either port 8334 or 8335, with the former only relaying blocks and the latter relaying both blocks and transactions. While the relay nodes do perform some data verification to prevent Denial of Service attacks (DoS), they do not fully verify the data they are relaying. Therefore, it is crucial for users to never mine a block based solely on a relayed block without conducting their own thorough verification using a bitcoin validator.The relay nodes do not follow the standard inv-getdata-tx/block flow; instead, they relay transactions and blocks immediately after performing cursory verification. It is important to understand that the relay nodes are not meant to replace the standard P2P network but rather to complement it. They are designed to augment the existing network and should not be relied upon to ensure that users never miss any data. There may be instances where the relay nodes fail to relay certain transactions. Furthermore, if a user disconnects and then reconnects, any missed data will not be sent again by the relay nodes. Therefore, it is still advisable to have peers on the standard P2P network.For important node operators such as merchants, exchanges, and large miners who wish to have access to relay nodes with fewer peers, there is a form available on the website to request additional domain names. The source code for the relay nodes can be found on GitHub, allowing users to review and contribute to their development.Users are encouraged to provide feedback, voice concerns, or make suggestions by emailing bitcoin-peering at mattcorallo.com. This helps in improving the relay node system and addressing any issues that may arise. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Another-weird-transaction-question-.xml b/static/bitcoin-dev/Aug_2014/combined_Another-weird-transaction-question-.xml index 821c305c0c..9b804285d1 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Another-weird-transaction-question-.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Another-weird-transaction-question-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Another weird transaction question... - 2023-08-01T10:13:56.786228+00:00 + 2025-10-11T22:00:02.267080+00:00 + python-feedgen Peter Todd 2014-08-13 18:10:32+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Another weird transaction question... - 2023-08-01T10:13:56.786228+00:00 + 2025-10-11T22:00:02.267225+00:00 - On 13th August 2014, Richard Moore raised a query regarding the acceptance of invalid public keys and the significance of the 0x00 prefix in a multisig output script. Seeking clarification, he posted his question in an email. Another user advised him to refer to the Bitcoin Core script test cases and examine the source code for further insights. The user also mentioned that the Bitcoin protocol does not consider the validity of public keys. Notably, the email was signed off with a PGP signature.Meanwhile, RicMoo, the founder of Genetic Mistakes Software, made an intriguing discovery. He came across a transaction in the blockchain that featured an output script containing a public key. Seeking clarification on the permissibility and handling of invalid public keys, RicMoo decided to verify the blockchain himself using his own implementation. It's worth mentioning that the transaction had already been verified by a legitimate client. 2014-08-13T18:10:32+00:00 + On 13th August 2014, Richard Moore raised a query regarding the acceptance of invalid public keys and the significance of the 0x00 prefix in a multisig output script. Seeking clarification, he posted his question in an email. Another user advised him to refer to the Bitcoin Core script test cases and examine the source code for further insights. The user also mentioned that the Bitcoin protocol does not consider the validity of public keys. Notably, the email was signed off with a PGP signature.Meanwhile, RicMoo, the founder of Genetic Mistakes Software, made an intriguing discovery. He came across a transaction in the blockchain that featured an output script containing a public key. Seeking clarification on the permissibility and handling of invalid public keys, RicMoo decided to verify the blockchain himself using his own implementation. It's worth mentioning that the transaction had already been verified by a legitimate client. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_BIP-Custodial-Identities.xml b/static/bitcoin-dev/Aug_2014/combined_BIP-Custodial-Identities.xml index 8c5d2dc4ae..6b3bb8191d 100644 --- a/static/bitcoin-dev/Aug_2014/combined_BIP-Custodial-Identities.xml +++ b/static/bitcoin-dev/Aug_2014/combined_BIP-Custodial-Identities.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: Custodial Identities - 2023-08-01T10:16:41.436485+00:00 + 2025-10-11T22:00:23.516490+00:00 + python-feedgen 21E14 2014-08-21 02:32:29+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP: Custodial Identities - 2023-08-01T10:16:41.436485+00:00 + 2025-10-11T22:00:23.516624+00:00 - The author of this message is proposing the creation of an optional identity layer for Bitcoin called Custodial Identities. This layer would be managed by a Bitcoin Assigned Custodial Identities Authority (BACIA), which would delegate Custodial Identity Spaces to Regional Bitcoin Custodial Identity Registries (RBCIRs). Similar to how Regional Internet Registries manage the allocation of Internet number resources, the BACIA would oversee global Custodial Identity allocation.A Bitcoin Custodial Identity (BCI) account address would consist of a Custodial Identifier allocated by the BACIA/RBCIRs, similar to a bank's routing number, and an account address like an account number. This proposal suggests that Custodial Identities could be applied to coinbase transactions as well, providing further incentive to keep nodes honest or enabling a recovery mechanism in catastrophic failure events.One benefit of implementing Custodial Identities is that custodians would provide account addresses out of unused address space, reducing the likelihood of address collisions and serving as a psychological barrier to adoption. Additionally, the proposal suggests that custodial to non-custodial transactions could behave similarly to the unspent transaction output (UTXO) of a coinbase transaction, based on open market competition.The main purpose of Bitcoin Custodial Identities is to allow for dispute resolution in the legal system for transactions in the BCI address space. By injecting Custodial Identities into the blockchain, the proposal aims to create greater transparency and accountability in transactions. The author believes that there are many applications beyond dispute resolution for Custodial Identities if they can be seamlessly integrated into the blockchain as easily as providing 1-of-2 public keys.The proposal is open for feedback and discussion on the mailing list, inviting input from the community. 2014-08-21T02:32:29+00:00 + The author of this message is proposing the creation of an optional identity layer for Bitcoin called Custodial Identities. This layer would be managed by a Bitcoin Assigned Custodial Identities Authority (BACIA), which would delegate Custodial Identity Spaces to Regional Bitcoin Custodial Identity Registries (RBCIRs). Similar to how Regional Internet Registries manage the allocation of Internet number resources, the BACIA would oversee global Custodial Identity allocation.A Bitcoin Custodial Identity (BCI) account address would consist of a Custodial Identifier allocated by the BACIA/RBCIRs, similar to a bank's routing number, and an account address like an account number. This proposal suggests that Custodial Identities could be applied to coinbase transactions as well, providing further incentive to keep nodes honest or enabling a recovery mechanism in catastrophic failure events.One benefit of implementing Custodial Identities is that custodians would provide account addresses out of unused address space, reducing the likelihood of address collisions and serving as a psychological barrier to adoption. Additionally, the proposal suggests that custodial to non-custodial transactions could behave similarly to the unspent transaction output (UTXO) of a coinbase transaction, based on open market competition.The main purpose of Bitcoin Custodial Identities is to allow for dispute resolution in the legal system for transactions in the BCI address space. By injecting Custodial Identities into the blockchain, the proposal aims to create greater transparency and accountability in transactions. The author believes that there are many applications beyond dispute resolution for Custodial Identities if they can be seamlessly integrated into the blockchain as easily as providing 1-of-2 public keys.The proposal is open for feedback and discussion on the mailing list, inviting input from the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_BIP32-invalidation.xml b/static/bitcoin-dev/Aug_2014/combined_BIP32-invalidation.xml index 45b3ea4aad..8401b9ccbf 100644 --- a/static/bitcoin-dev/Aug_2014/combined_BIP32-invalidation.xml +++ b/static/bitcoin-dev/Aug_2014/combined_BIP32-invalidation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP32 - invalidation - 2023-08-01T10:13:13.598052+00:00 + 2025-10-11T22:00:00.143053+00:00 + python-feedgen Eric Lombrozo 2014-08-10 01:20:09+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP32 - invalidation - 2023-08-01T10:13:13.598052+00:00 + 2025-10-11T22:00:00.143199+00:00 - The email conversation revolves around a proposed change in the bitcoin specification, specifically regarding the security concerns associated with this change. The change involves assigning I_L := I_L mod n when I_L >= n, which is deemed less secure due to its potential impact on the selection of private keys and the elimination of provable security equal to random keys.One major concern raised is the incompatibility between the proposed change and existing implementations of the specification. This incompatibility could lead users to mistakenly believe that their keys are worthless or result in the loss of funds when they are unable to spend them. It is also highlighted that other parties who have invested time and effort into producing correct and compatible implementations would be inconvenienced by this change.Furthermore, the proposed change would create an uneven distribution of private keys, which is considered objectively less secure. This imbalance could pose a significant vulnerability if an incorrect implementation reflects a large group of keys to a small number of values.The email emphasizes the importance of handling corner cases in cryptographic software. Examples of such corner cases include dealing with point at infinity cases, zero-value signatures (which could potentially leak the private key), and adding colinear points. While it is acknowledged that some implementations may not currently check for these cases, it is stressed that addressing them is crucial for ensuring the overall security of the system.It is noted that the bignum modulo operation required for the proposed change may present complexities and potential layering issues. Therefore, it may not be readily available for implementation.The email concludes by suggesting that individuals who are unprepared to handle these complications should refrain from writing this type of software and leave it to those who are better equipped to address the security concerns effectively.In addition to the discussion surrounding the proposed change, the email also mentions a separate post by another author proposing a modification to the BIP32 protocol regarding invalidation of nodes. The current protocol suggests proceeding with the next value for i if a resulting key is invalid. However, the author suggests changing this to assigning I_L := I_L mod n in all three cases of public CKD, private CKD, and master key generation. This change aims to simplify the implementation of skipping logic when marking a key as invalid and potentially encourage more implementations to check for invalid keys.The author acknowledges that there are still scenarios where a key may be invalid, such as when I_L = 0 or ki = 0 or ki = inf. However, these situations are considered to have a low probability of occurring. The author seeks input from others regarding any security concerns related to this proposed change. 2014-08-10T01:20:09+00:00 + The email conversation revolves around a proposed change in the bitcoin specification, specifically regarding the security concerns associated with this change. The change involves assigning I_L := I_L mod n when I_L >= n, which is deemed less secure due to its potential impact on the selection of private keys and the elimination of provable security equal to random keys.One major concern raised is the incompatibility between the proposed change and existing implementations of the specification. This incompatibility could lead users to mistakenly believe that their keys are worthless or result in the loss of funds when they are unable to spend them. It is also highlighted that other parties who have invested time and effort into producing correct and compatible implementations would be inconvenienced by this change.Furthermore, the proposed change would create an uneven distribution of private keys, which is considered objectively less secure. This imbalance could pose a significant vulnerability if an incorrect implementation reflects a large group of keys to a small number of values.The email emphasizes the importance of handling corner cases in cryptographic software. Examples of such corner cases include dealing with point at infinity cases, zero-value signatures (which could potentially leak the private key), and adding colinear points. While it is acknowledged that some implementations may not currently check for these cases, it is stressed that addressing them is crucial for ensuring the overall security of the system.It is noted that the bignum modulo operation required for the proposed change may present complexities and potential layering issues. Therefore, it may not be readily available for implementation.The email concludes by suggesting that individuals who are unprepared to handle these complications should refrain from writing this type of software and leave it to those who are better equipped to address the security concerns effectively.In addition to the discussion surrounding the proposed change, the email also mentions a separate post by another author proposing a modification to the BIP32 protocol regarding invalidation of nodes. The current protocol suggests proceeding with the next value for i if a resulting key is invalid. However, the author suggests changing this to assigning I_L := I_L mod n in all three cases of public CKD, private CKD, and master key generation. This change aims to simplify the implementation of skipping logic when marking a key as invalid and potentially encourage more implementations to check for invalid keys.The author acknowledges that there are still scenarios where a key may be invalid, such as when I_L = 0 or ki = 0 or ki = inf. However, these situations are considered to have a low probability of occurring. The author seeks input from others regarding any security concerns related to this proposed change. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_BIP43-Purpose-code-for-voting-pool-HD-wallets.xml b/static/bitcoin-dev/Aug_2014/combined_BIP43-Purpose-code-for-voting-pool-HD-wallets.xml index b6e84e6739..f61413df09 100644 --- a/static/bitcoin-dev/Aug_2014/combined_BIP43-Purpose-code-for-voting-pool-HD-wallets.xml +++ b/static/bitcoin-dev/Aug_2014/combined_BIP43-Purpose-code-for-voting-pool-HD-wallets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP43 Purpose code for voting pool HD wallets - 2023-08-01T10:16:06.974259+00:00 + 2025-10-11T21:59:58.014217+00:00 + python-feedgen Bryan Bishop 2014-09-26 02:32:44+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP43 Purpose code for voting pool HD wallets - 2023-08-01T10:16:06.974259+00:00 + 2025-10-11T21:59:58.014384+00:00 - In September 2014, Gregory Maxwell sent an email seeking feedback on a proposal regarding the attachment of files through sourceforge. However, non-subscribed users faced difficulties accessing the file due to an HTTP 500 error. Bryan's contact information was also included in the email.Alan, in a Bitcoin-development mailing list, expressed support for BIP43 and suggested the addition of a "Purpose" node to identify different tree structures in a wallet file. He proposed a non-hardened first-layer derivation for common trees and a "No-collision mode" for multisig BIP32 trees. These changes could be implemented by modifying the BIP43 "Purpose" index and allowing wallet software to recognize and react to the Purpose node for various tree structures. Alan believed that adding an extra layer between the root and the important tree nodes would provide flexibility to BIP32 as a whole.Gregory Maxwell discussed the broken process of the BIP (Bitcoin Improvement Proposals) process, specifically regarding informational BIPs. He argued that proposals requiring action from others should not be grouped with purely informational proposals. Maxwell clarified that the informational BIPs were only proposed to support the intent of BIP43. Justus Ranvier was included in the email chain, and his public key ID was provided.On August 19, 2014, Justus Ranvier sent an email attaching two draft information BIPs. He requested feedback from the recipients both privately and on the list. No additional commentary was provided in the email.The HD multisig structure to be used for Bitcoin wallets used in voting pools will reserve two purpose codes. Two draft information BIPs were documented - one for wallets suitable for storing bulk bitcoin deposits and another for storing colored coin deposits. The primary difference is that bulk deposit wallets use cold storage and allow significant administrative overhead, while colored coin wallets do not use cold storage because they must be generated on the fly. The email mentioned an HTML attachment, but no details were provided about its content. Justus Ranvier signed off the message with his public key ID. 2014-09-26T02:32:44+00:00 + In September 2014, Gregory Maxwell sent an email seeking feedback on a proposal regarding the attachment of files through sourceforge. However, non-subscribed users faced difficulties accessing the file due to an HTTP 500 error. Bryan's contact information was also included in the email.Alan, in a Bitcoin-development mailing list, expressed support for BIP43 and suggested the addition of a "Purpose" node to identify different tree structures in a wallet file. He proposed a non-hardened first-layer derivation for common trees and a "No-collision mode" for multisig BIP32 trees. These changes could be implemented by modifying the BIP43 "Purpose" index and allowing wallet software to recognize and react to the Purpose node for various tree structures. Alan believed that adding an extra layer between the root and the important tree nodes would provide flexibility to BIP32 as a whole.Gregory Maxwell discussed the broken process of the BIP (Bitcoin Improvement Proposals) process, specifically regarding informational BIPs. He argued that proposals requiring action from others should not be grouped with purely informational proposals. Maxwell clarified that the informational BIPs were only proposed to support the intent of BIP43. Justus Ranvier was included in the email chain, and his public key ID was provided.On August 19, 2014, Justus Ranvier sent an email attaching two draft information BIPs. He requested feedback from the recipients both privately and on the list. No additional commentary was provided in the email.The HD multisig structure to be used for Bitcoin wallets used in voting pools will reserve two purpose codes. Two draft information BIPs were documented - one for wallets suitable for storing bulk bitcoin deposits and another for storing colored coin deposits. The primary difference is that bulk deposit wallets use cold storage and allow significant administrative overhead, while colored coin wallets do not use cold storage because they must be generated on the fly. The email mentioned an HTML attachment, but no details were provided about its content. Justus Ranvier signed off the message with his public key ID. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_CoinShuffle-decentralized-CoinJoin-without-trusted-third-parties.xml b/static/bitcoin-dev/Aug_2014/combined_CoinShuffle-decentralized-CoinJoin-without-trusted-third-parties.xml index c663b6def4..62b8199000 100644 --- a/static/bitcoin-dev/Aug_2014/combined_CoinShuffle-decentralized-CoinJoin-without-trusted-third-parties.xml +++ b/static/bitcoin-dev/Aug_2014/combined_CoinShuffle-decentralized-CoinJoin-without-trusted-third-parties.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CoinShuffle: decentralized CoinJoin without trusted third parties - 2023-08-01T10:11:08.502872+00:00 + 2025-10-11T22:00:29.893444+00:00 + python-feedgen Mark Friedenbach 2014-08-11 17:06:48+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - CoinShuffle: decentralized CoinJoin without trusted third parties - 2023-08-01T10:11:08.503910+00:00 + 2025-10-11T22:00:29.893589+00:00 - The discussion revolves around the requirement to ensure validity at a certain level and how it can constrain the use cases of protocol implementations. It is mentioned that parties can generate chained transactions on unconfirmed transactions, which can be difficult to do safely but may be safe or desirable in some circumstances. Clients are recommended to validate the inputs to a shuffle they are participating in, depending on the client type. SPV clients without servers can use getUTXO or verify the validity of the transaction that created the input designated for mixing. A signed transaction that spends the money can also convince even SPV clients that a participant with these inputs is trying to cheat. However, lite clients cannot perform this check, making the protocol vulnerable to DoS attacks. An alternative solution is to have participants submit the merkle proof for the input, but this requires inputs to have at least one confirmation.The efficacy of coinjoin is discussed, with concerns raised about the input potentially being spent already, which would make it invalid. In such cases, a signed transaction that spends the money would be sufficient to convince even SPV clients that the participant with these inputs is cheating. However, getutxo cannot return the spending transaction as the UTXO set doesn't record this information. The divergence can be detected if enough peers are honest, but if all peers are lying and the attacker controls the internet connection, it wouldn't make much difference as they could swallow the transaction being broadcasted. Ultimately, if peers think a TXO is spent and refuse to relay transactions that spend them, there is not much that can be done, even in the non-SPV context. The ability to reach at least one peer who believes in the same world is crucial.The conversation explores the possibility of using lightweight clients in a protocol. The worst-case scenario for these clients is that a transaction will not confirm, leading to a DoS attack. For clients relying on servers, it is reasonable to trust these servers to prevent such attacks. However, for SPV clients without servers, alternative solutions like getUTXO or verifying the validity of the transaction designated for mixing need to be considered. The only remaining issue would be if the input has already been spent, but one honest client with full information can provide a signed transaction that spends the money, convincing even SPV clients that the participant with this input is cheating. Merkle proofs for inputs are also discussed, but they require at least one confirmation. Overall, a policy for lightweight clients needs to be established to ensure the security of the protocol.A group of researchers in Germany has proposed CoinShuffle, a decentralized protocol for CoinJoin that allows for mixing coins among users to improve anonymity. CoinShuffle provides a clever way to create a CoinJoin transaction without the need for trusted third parties. The advantage of CoinJoin over mixing with a server or trusted party is that nobody can steal coins. Each user can check if the transaction sends enough coins to their fresh output address, and if not, refuse to sign the transaction. CoinShuffle ensures anonymity by eliminating the need for a server to know which input addresses belong to which output addresses. It is secure against thefts and robust against denial-of-service attacks. The protocol requires only public-key encryption and signatures, making it efficient and compatible with the current Bitcoin system without requiring changes to the protocol. While a proof-of-concept implementation is available, it is insecure and not well-written. The researchers plan to develop a full, open-source implementation and welcome help in the process, including design, coding, and feedback.In an email exchange between Sergio Lerner and Tim, the possibility of de-anonymizing the first party in a protocol is discussed. Sergio suggests that the second party can de-anonymize the first party, but Tim disagrees, stating that the second party doesn't know how the other parties shuffled the outputs as it doesn't have their decryption keys.The issue of decentralization in a shuffle protocol is raised in an email exchange between Sergio and Tim Ruffing. Direct connections to a randomly elected leader responsible for broadcasts or overlay networks like distributed hash tables are suggested as possible solutions. The issue of Sybil attacks is also discussed, with suggestions to divide users into individual groups and ensure that the assignment cannot be influenced by the attacker. Various methods for setting up initial pools of participants are mentioned, including using peer-to-peer networks like Bitcoin or chans in Bitmessage. Combining several pools and using information from friends are also proposed as solutions. While there is no perfect solution, several proposals work well enough if implemented correctly.Tim Ruffing expresses concerns about the decentralization and security of CoinShuffle, questioning how users can securely communicate with each other and prevent Sybil attacks. He does not see how CoinShuffle offers a solution to these problems. The provided website offers a technical overview of CoinShuffle but does not address Ruffing's concerns.CoinShuffle, a decentralized and secure mixing protocol, is a topic of 2014-08-11T17:06:48+00:00 + The discussion revolves around the requirement to ensure validity at a certain level and how it can constrain the use cases of protocol implementations. It is mentioned that parties can generate chained transactions on unconfirmed transactions, which can be difficult to do safely but may be safe or desirable in some circumstances. Clients are recommended to validate the inputs to a shuffle they are participating in, depending on the client type. SPV clients without servers can use getUTXO or verify the validity of the transaction that created the input designated for mixing. A signed transaction that spends the money can also convince even SPV clients that a participant with these inputs is trying to cheat. However, lite clients cannot perform this check, making the protocol vulnerable to DoS attacks. An alternative solution is to have participants submit the merkle proof for the input, but this requires inputs to have at least one confirmation.The efficacy of coinjoin is discussed, with concerns raised about the input potentially being spent already, which would make it invalid. In such cases, a signed transaction that spends the money would be sufficient to convince even SPV clients that the participant with these inputs is cheating. However, getutxo cannot return the spending transaction as the UTXO set doesn't record this information. The divergence can be detected if enough peers are honest, but if all peers are lying and the attacker controls the internet connection, it wouldn't make much difference as they could swallow the transaction being broadcasted. Ultimately, if peers think a TXO is spent and refuse to relay transactions that spend them, there is not much that can be done, even in the non-SPV context. The ability to reach at least one peer who believes in the same world is crucial.The conversation explores the possibility of using lightweight clients in a protocol. The worst-case scenario for these clients is that a transaction will not confirm, leading to a DoS attack. For clients relying on servers, it is reasonable to trust these servers to prevent such attacks. However, for SPV clients without servers, alternative solutions like getUTXO or verifying the validity of the transaction designated for mixing need to be considered. The only remaining issue would be if the input has already been spent, but one honest client with full information can provide a signed transaction that spends the money, convincing even SPV clients that the participant with this input is cheating. Merkle proofs for inputs are also discussed, but they require at least one confirmation. Overall, a policy for lightweight clients needs to be established to ensure the security of the protocol.A group of researchers in Germany has proposed CoinShuffle, a decentralized protocol for CoinJoin that allows for mixing coins among users to improve anonymity. CoinShuffle provides a clever way to create a CoinJoin transaction without the need for trusted third parties. The advantage of CoinJoin over mixing with a server or trusted party is that nobody can steal coins. Each user can check if the transaction sends enough coins to their fresh output address, and if not, refuse to sign the transaction. CoinShuffle ensures anonymity by eliminating the need for a server to know which input addresses belong to which output addresses. It is secure against thefts and robust against denial-of-service attacks. The protocol requires only public-key encryption and signatures, making it efficient and compatible with the current Bitcoin system without requiring changes to the protocol. While a proof-of-concept implementation is available, it is insecure and not well-written. The researchers plan to develop a full, open-source implementation and welcome help in the process, including design, coding, and feedback.In an email exchange between Sergio Lerner and Tim, the possibility of de-anonymizing the first party in a protocol is discussed. Sergio suggests that the second party can de-anonymize the first party, but Tim disagrees, stating that the second party doesn't know how the other parties shuffled the outputs as it doesn't have their decryption keys.The issue of decentralization in a shuffle protocol is raised in an email exchange between Sergio and Tim Ruffing. Direct connections to a randomly elected leader responsible for broadcasts or overlay networks like distributed hash tables are suggested as possible solutions. The issue of Sybil attacks is also discussed, with suggestions to divide users into individual groups and ensure that the assignment cannot be influenced by the attacker. Various methods for setting up initial pools of participants are mentioned, including using peer-to-peer networks like Bitcoin or chans in Bitmessage. Combining several pools and using information from friends are also proposed as solutions. While there is no perfect solution, several proposals work well enough if implemented correctly.Tim Ruffing expresses concerns about the decentralization and security of CoinShuffle, questioning how users can securely communicate with each other and prevent Sybil attacks. He does not see how CoinShuffle offers a solution to these problems. The provided website offers a technical overview of CoinShuffle but does not address Ruffing's concerns.CoinShuffle, a decentralized and secure mixing protocol, is a topic of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_How-to-create-a-pull-tester-JAR.xml b/static/bitcoin-dev/Aug_2014/combined_How-to-create-a-pull-tester-JAR.xml index a4ef26aaab..192d0bb0d5 100644 --- a/static/bitcoin-dev/Aug_2014/combined_How-to-create-a-pull-tester-JAR.xml +++ b/static/bitcoin-dev/Aug_2014/combined_How-to-create-a-pull-tester-JAR.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - How to create a pull tester JAR - 2023-08-01T10:10:27.251904+00:00 + 2025-10-11T22:00:25.637664+00:00 + python-feedgen Jorge Timón 2014-08-06 10:01:39+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - How to create a pull tester JAR - 2023-08-01T10:10:27.251904+00:00 + 2025-10-11T22:00:25.637817+00:00 - The pull tester entry point for the bitcoinj library can be found on GitHub. However, it is mentioned that the library will soon have a new namespace from com.google.bitcoin to org.bitcoinj, which means the provided link may break in the future. Additionally, the code itself is not considered ideal as it involves copy/paste coding and will be refactored soon by Matt. Therefore, anyone planning to add tests to the framework should coordinate with Matt to avoid conflicts with the ongoing refactor/rewrite process.In an email dated August 5th, 2014, Mike Hearn discussed the default package repository used by Maven, stating that it was not protected by SSL until recently. He mentioned that a new release with SSL as the default setting would be coming soon. He also filed a wishlist item on https://jira.codehaus.org/browse/MNG-5672 and a bug report on https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1352418 regarding this issue.The email thread provides instructions for creating a pull tester JAR. It requires a Java Development Kit (JDK) version 6 or higher, Apache Maven, and git. To build the JAR, one needs to clone bitcoinj from git master and run the command "mvn -DskipTests package". This will download the necessary libraries, compile the code, and create a bundled executable JAR file called core/target/pull-tests.jar. The JAR file can be used with the QA scripts in the bitcoin core qa/pull-tester directory or run directly using specific commands. It is emphasized that the same version of javac and bitcoinj should be used to easily reproduce the JARs.Recently, it was discovered that Maven's default package repository was not protected by SSL until a few days ago. Although it is now available via SSL, users need to inform Maven about the new URL before running 'mvn'. In the future, Maven will release a new version where SSL is the default setting. For now, users can save the provided settings.xml file to their path ~/.m2/ to ensure secure access to the central repository. The settings.xml file includes information on the two repositories, one being the newly secured 'securecentral' and the other being 'central', which still uses the unsecured URL. Both repositories have the 'enabled' tag set to true.The author also offers to provide a pull-tests.jar from their local machine if anyone needs it. 2014-08-06T10:01:39+00:00 + The pull tester entry point for the bitcoinj library can be found on GitHub. However, it is mentioned that the library will soon have a new namespace from com.google.bitcoin to org.bitcoinj, which means the provided link may break in the future. Additionally, the code itself is not considered ideal as it involves copy/paste coding and will be refactored soon by Matt. Therefore, anyone planning to add tests to the framework should coordinate with Matt to avoid conflicts with the ongoing refactor/rewrite process.In an email dated August 5th, 2014, Mike Hearn discussed the default package repository used by Maven, stating that it was not protected by SSL until recently. He mentioned that a new release with SSL as the default setting would be coming soon. He also filed a wishlist item on https://jira.codehaus.org/browse/MNG-5672 and a bug report on https://bugs.launchpad.net/ubuntu/+source/maven/+bug/1352418 regarding this issue.The email thread provides instructions for creating a pull tester JAR. It requires a Java Development Kit (JDK) version 6 or higher, Apache Maven, and git. To build the JAR, one needs to clone bitcoinj from git master and run the command "mvn -DskipTests package". This will download the necessary libraries, compile the code, and create a bundled executable JAR file called core/target/pull-tests.jar. The JAR file can be used with the QA scripts in the bitcoin core qa/pull-tester directory or run directly using specific commands. It is emphasized that the same version of javac and bitcoinj should be used to easily reproduce the JARs.Recently, it was discovered that Maven's default package repository was not protected by SSL until a few days ago. Although it is now available via SSL, users need to inform Maven about the new URL before running 'mvn'. In the future, Maven will release a new version where SSL is the default setting. For now, users can save the provided settings.xml file to their path ~/.m2/ to ensure secure access to the central repository. The settings.xml file includes information on the two repositories, one being the newly secured 'securecentral' and the other being 'central', which still uses the unsecured URL. Both repositories have the 'enabled' tag set to true.The author also offers to provide a pull-tests.jar from their local machine if anyone needs it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Miners-MiTM.xml b/static/bitcoin-dev/Aug_2014/combined_Miners-MiTM.xml index bb237b1a03..63daf05ad8 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Miners-MiTM.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Miners-MiTM.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Miners MiTM - 2023-08-01T10:11:26.114298+00:00 + 2025-10-11T21:59:55.888998+00:00 + python-feedgen Troy Benjegerdes 2014-08-09 19:39:54+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Miners MiTM - 2023-08-01T10:11:26.114298+00:00 + 2025-10-11T21:59:55.889171+00:00 - In response to Pedro's concerns, Luke Dashjr explains that this is not new news and that BFGMiner and Eloipool have already taken steps to protect against it. He also states that no Bitcoin pools have deployed these measures yet and that the target has always been scamcoins. Another individual suggests that referring to other cryptocurrencies as "scamcoins" is part of an organized effort to marginalize competitors. They believe that the BGP hijacks may be testing the system for future use.The conversation then shifts to the topic of TLS and its potential as a protection method for pool servers. Jeff Garzik raises concerns about the possibility of a denial-of-service (DoS) attack if TLS is enabled. He suggests using a more lightweight solution like mutual CHAP to prevent client payout redirection and server impersonation. The discussion also touches on the legal issues that may arise with RedHat/Fedora if simple ECDSA signatures were used.Mike Hearn adds to the conversation by questioning the use of SSL and certificate validation in Bitcoin mining. He argues that there are better mechanisms, such as using ECDSA keys, to authenticate miners and pools. However, he notes that there is currently no economic incentive to implement these mechanisms and that security patches will continue to be necessary as long as the cost of man-in-the-middle fraud is lower than the cost of implementing real cryptography.The context also mentions the importance of SSL for financial services and the surprising fact that it is not universally used. It is noted that SSL is necessary for secure online banking and email usage.Overall, the discussion revolves around the need for protection in Bitcoin mining traffic and the potential vulnerabilities that exist in current methods. Various ideas and concerns are raised by Bitcoin developers and open source evangelists, highlighting the ongoing efforts to improve security in the Bitcoin ecosystem. 2014-08-09T19:39:54+00:00 + In response to Pedro's concerns, Luke Dashjr explains that this is not new news and that BFGMiner and Eloipool have already taken steps to protect against it. He also states that no Bitcoin pools have deployed these measures yet and that the target has always been scamcoins. Another individual suggests that referring to other cryptocurrencies as "scamcoins" is part of an organized effort to marginalize competitors. They believe that the BGP hijacks may be testing the system for future use.The conversation then shifts to the topic of TLS and its potential as a protection method for pool servers. Jeff Garzik raises concerns about the possibility of a denial-of-service (DoS) attack if TLS is enabled. He suggests using a more lightweight solution like mutual CHAP to prevent client payout redirection and server impersonation. The discussion also touches on the legal issues that may arise with RedHat/Fedora if simple ECDSA signatures were used.Mike Hearn adds to the conversation by questioning the use of SSL and certificate validation in Bitcoin mining. He argues that there are better mechanisms, such as using ECDSA keys, to authenticate miners and pools. However, he notes that there is currently no economic incentive to implement these mechanisms and that security patches will continue to be necessary as long as the cost of man-in-the-middle fraud is lower than the cost of implementing real cryptography.The context also mentions the importance of SSL for financial services and the surprising fact that it is not universally used. It is noted that SSL is necessary for secure online banking and email usage.Overall, the discussion revolves around the need for protection in Bitcoin mining traffic and the potential vulnerabilities that exist in current methods. Various ideas and concerns are raised by Bitcoin developers and open source evangelists, highlighting the ongoing efforts to improve security in the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_NODE-EXT-SERVICES-and-advertising-related-services.xml b/static/bitcoin-dev/Aug_2014/combined_NODE-EXT-SERVICES-and-advertising-related-services.xml index 9057535615..5fddd96ca2 100644 --- a/static/bitcoin-dev/Aug_2014/combined_NODE-EXT-SERVICES-and-advertising-related-services.xml +++ b/static/bitcoin-dev/Aug_2014/combined_NODE-EXT-SERVICES-and-advertising-related-services.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - NODE_EXT_SERVICES and advertising related services - 2023-08-01T10:12:50.941598+00:00 + 2025-10-11T22:00:27.768808+00:00 + python-feedgen Mike Hearn 2014-08-08 13:55:42+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - NODE_EXT_SERVICES and advertising related services - 2023-08-01T10:12:50.941598+00:00 + 2025-10-11T22:00:27.768987+00:00 - The discussion revolves around the possibility of having bitcoind listen on a separate port for connections from plugins. This would allow for easier management and enhanced security. The suggestion is made to use a UNIX socket instead of a TCP port, especially in scenarios where services are distributed across multiple machines.Implementing an external application or script for certain Bitcoin functions, such as 'getutxos', is also discussed. It is noted that while this could be useful for some tasks, others may require more work if implemented externally. However, information can still be queried back over RPC.The author proposes a solution where useful services like -txindex or the nLockTime storage facility can be added by having any program connect to bitcoind as normal and send "registersrv" with the necessary information. An additional standalone program can bridge this mechanism to run a shell command for specific messages.ZeroMQ, a lightweight message routing system, is mentioned as a potential plug-in for capturing precise points where a block was accepted internally. It can make P2P messages available to other applications through subscription.The categorization of block indexes in Bitcoin Wallet for Android is discussed, with the proposal to add categories instead of a single bit to enable faster and more efficient autodiscovery.There is a conversation about delegating processing of unknown messages to an external process, allowing a P2P node to be composed of separate programs. Bitcoind would act as a router through a local interprocess message bus, with ZeroMQ suggested as a suitable choice.The idea of generic service advertisement mechanisms is supported, but it is emphasized that nothing makes the proposal more focused than the existing service bits. Another email thread discusses the inclusion of advertisements in the P2P protocol, with differing opinions on whether this should be allowed. The importance of using service bits solely for advertising services on the P2P network is emphasized.In an email exchange between Wladimir and Mike Hearn, the use of service bits to advertise services on a different port is discussed. Wladimir argues against this, stating that service bits are meant for advertising services on the P2P network only and not open for discussion. The importance of having a mechanism to connect to an external service, especially when the advertised service does not have a fixed port, is highlighted.Another email exchange between Wladimir and Christian Decker focuses on the inclusion of advertisements in the P2P protocol. Christian suggests using an external network for advertising external services, but Wladimir explains that service bits are reserved for advertising services on the P2P network and proposes a mechanism to connect to external services.In conclusion, the discussions revolve around various proposals and ideas related to enhancing the functionality and flexibility of bitcoind through the use of separate ports for plugins, implementing external applications or scripts for specific Bitcoin functions, utilizing ZeroMQ as a lightweight message routing system, and exploring the categorization of block indexes in Bitcoin Wallet for Android. The conversations also touch upon the importance of maintaining the integrity and purpose of service bits in the P2P protocol and finding mechanisms to connect to external services efficiently.The suggestion from Mike Hearn in August 2014 was to continue using the existing extension mechanism until service bits start running out. This is because there is currently no shortage of service bits, allowing users to determine the services a node supports without having to connect to each one individually. By utilizing the current system, developers can add new features and functionality without impacting the core functions of the system.Using the existing extension mechanism offers flexibility and adaptability in a rapidly changing technological landscape. It also saves time and resources by avoiding the need to create an entirely new system. However, it is important to manage service bits effectively to avoid wastage or duplication. Proper monitoring and allocation of service bits are necessary to prevent conflicts or errors in the system.The Bitcoin community does not require all functionality to be built into bitcoind for a decentralized network. BitPay's insight open source block explorer API project runs on top of bitcoind and provides other services at the same IP address. This creates a decentralized network of nodes running a full node and an insight server. By querying multiple insight servers from different operators, users can avoid relying solely on BitPay's insight server and verify the results independently.To implement this in a generic way, the NODE_EXT_SERVICES is advertised through the "addr" P2P message. Nodes recognizing this bit can connect to the node and query a services list using the "getextsrv" P2P message. Services can only advertise added services if they are at the same IP address being advertised.Jeff Garzik, a Bitcoin core developer, states that this proposal is not fully developed but rather serves as a starting point for discussion. He emphasizes that implementing all services within bitcoind is unnecessary.In conclusion, the suggestion to continue using the existing extension mechanism until service bits start running out is a practical approach. It allows for flexibility, adaptability, and 2014-08-08T13:55:42+00:00 + The discussion revolves around the possibility of having bitcoind listen on a separate port for connections from plugins. This would allow for easier management and enhanced security. The suggestion is made to use a UNIX socket instead of a TCP port, especially in scenarios where services are distributed across multiple machines.Implementing an external application or script for certain Bitcoin functions, such as 'getutxos', is also discussed. It is noted that while this could be useful for some tasks, others may require more work if implemented externally. However, information can still be queried back over RPC.The author proposes a solution where useful services like -txindex or the nLockTime storage facility can be added by having any program connect to bitcoind as normal and send "registersrv" with the necessary information. An additional standalone program can bridge this mechanism to run a shell command for specific messages.ZeroMQ, a lightweight message routing system, is mentioned as a potential plug-in for capturing precise points where a block was accepted internally. It can make P2P messages available to other applications through subscription.The categorization of block indexes in Bitcoin Wallet for Android is discussed, with the proposal to add categories instead of a single bit to enable faster and more efficient autodiscovery.There is a conversation about delegating processing of unknown messages to an external process, allowing a P2P node to be composed of separate programs. Bitcoind would act as a router through a local interprocess message bus, with ZeroMQ suggested as a suitable choice.The idea of generic service advertisement mechanisms is supported, but it is emphasized that nothing makes the proposal more focused than the existing service bits. Another email thread discusses the inclusion of advertisements in the P2P protocol, with differing opinions on whether this should be allowed. The importance of using service bits solely for advertising services on the P2P network is emphasized.In an email exchange between Wladimir and Mike Hearn, the use of service bits to advertise services on a different port is discussed. Wladimir argues against this, stating that service bits are meant for advertising services on the P2P network only and not open for discussion. The importance of having a mechanism to connect to an external service, especially when the advertised service does not have a fixed port, is highlighted.Another email exchange between Wladimir and Christian Decker focuses on the inclusion of advertisements in the P2P protocol. Christian suggests using an external network for advertising external services, but Wladimir explains that service bits are reserved for advertising services on the P2P network and proposes a mechanism to connect to external services.In conclusion, the discussions revolve around various proposals and ideas related to enhancing the functionality and flexibility of bitcoind through the use of separate ports for plugins, implementing external applications or scripts for specific Bitcoin functions, utilizing ZeroMQ as a lightweight message routing system, and exploring the categorization of block indexes in Bitcoin Wallet for Android. The conversations also touch upon the importance of maintaining the integrity and purpose of service bits in the P2P protocol and finding mechanisms to connect to external services efficiently.The suggestion from Mike Hearn in August 2014 was to continue using the existing extension mechanism until service bits start running out. This is because there is currently no shortage of service bits, allowing users to determine the services a node supports without having to connect to each one individually. By utilizing the current system, developers can add new features and functionality without impacting the core functions of the system.Using the existing extension mechanism offers flexibility and adaptability in a rapidly changing technological landscape. It also saves time and resources by avoiding the need to create an entirely new system. However, it is important to manage service bits effectively to avoid wastage or duplication. Proper monitoring and allocation of service bits are necessary to prevent conflicts or errors in the system.The Bitcoin community does not require all functionality to be built into bitcoind for a decentralized network. BitPay's insight open source block explorer API project runs on top of bitcoind and provides other services at the same IP address. This creates a decentralized network of nodes running a full node and an insight server. By querying multiple insight servers from different operators, users can avoid relying solely on BitPay's insight server and verify the results independently.To implement this in a generic way, the NODE_EXT_SERVICES is advertised through the "addr" P2P message. Nodes recognizing this bit can connect to the node and query a services list using the "getextsrv" P2P message. Services can only advertise added services if they are at the same IP address being advertised.Jeff Garzik, a Bitcoin core developer, states that this proposal is not fully developed but rather serves as a starting point for discussion. He emphasizes that implementing all services within bitcoind is unnecessary.In conclusion, the suggestion to continue using the existing extension mechanism until service bits start running out is a practical approach. It allows for flexibility, adaptability, and - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Outbound-connections-rotation.xml b/static/bitcoin-dev/Aug_2014/combined_Outbound-connections-rotation.xml index b82d7acbbb..7d9c80f501 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Outbound-connections-rotation.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Outbound-connections-rotation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Outbound connections rotation - 2023-08-01T10:14:21.742745+00:00 + 2025-10-11T22:00:21.394239+00:00 + python-feedgen Gregory Maxwell 2014-08-18 23:20:54+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Outbound connections rotation - 2023-08-01T10:14:21.743751+00:00 + 2025-10-11T22:00:21.394406+00:00 - In August 2014, Ivan Pustogarov discussed how Bitcoin peers maintain a history of forwarded addresses to prevent retransmission. However, there was some confusion in the conversation, and Pustogarov apologized for any misunderstandings. The attack discussed involves an attacker obtaining potential IP addresses of clients and spamming the network with this list. The attacker can clear the retransmission history by reconnecting after each spam round. This attack was described in detail on cryptolux.org and discussed on bitcointalk.org.Pustogarov proposed a solution to address this attack by periodically rotating outbound connections every 2-10 minutes. Each NATed client connects to the network through 8 entry peers and advertises its public IP address to them. An attacker can use this information to map out connections. However, Gregory Maxwell questioned Pustogarov's statement that an attacker with no peers would learn nothing about the Bitcoin network.The attack involves an attacker listening to transactions on the Bitcoin network and recording the first 8-10 peers that forward each transaction. This allows the attacker to link together different Bitcoin addresses and learn the IP of the client. The 8 entry peers are unique per client, so users sharing the same IP can be distinguished. Outbound connections are rotated from time to time due to remote disconnections, but the initial connections prefer nodes that were up recently.Pustogarov expressed concern about attackers without peers linking Bitcoin addresses and learning client IPs. The recipient of the email was confused about how this would be possible without any peers. Pustogarov explained that the unique 8 entry peers per client allow distinguishing users with the same IP. The discussion also touched on the rotation of outbound connections and the need for privacy through broadcasting over tor or i2p.In a Bitcoin-development mailing list conversation, Pustogarov proposed periodic rotation of outbound connections to improve network knowledge and make it stronger against partitioning. However, Maxwell disagreed, stating that constant outbound peers can prevent attackers from gaining strong evidence about transaction origin. It was recommended to broadcast over tor or i2p for privacy.Pustogarov initiated a discussion on the periodic rotation of outbound connections to improve network knowledge and make it stronger against partitioning. However, one recipient noted that rotating peers excessively is unnecessary and suggested broadcasting over tor or i2p for privacy.The periodic rotation of outbound connections aims to mitigate risks associated with 8 entry nodes uniquely identifying users. Attackers can link different blockchain addresses using this information. The proposed solution recommends periodic rotation to blur the fingerprint over time. Bitcoin clients advertise their public IP addresses, allowing attackers to deanonymize clients. The corresponding pull request is #4723, and more details can be found at cryptolux.org.In conclusion, Pustogarov's proposal for periodic rotation of outbound connections aims to address the risk of attackers linking Bitcoin addresses and learning client IPs. The discussion highlights the need for privacy through broadcasting over tor or i2p. 2014-08-18T23:20:54+00:00 + In August 2014, Ivan Pustogarov discussed how Bitcoin peers maintain a history of forwarded addresses to prevent retransmission. However, there was some confusion in the conversation, and Pustogarov apologized for any misunderstandings. The attack discussed involves an attacker obtaining potential IP addresses of clients and spamming the network with this list. The attacker can clear the retransmission history by reconnecting after each spam round. This attack was described in detail on cryptolux.org and discussed on bitcointalk.org.Pustogarov proposed a solution to address this attack by periodically rotating outbound connections every 2-10 minutes. Each NATed client connects to the network through 8 entry peers and advertises its public IP address to them. An attacker can use this information to map out connections. However, Gregory Maxwell questioned Pustogarov's statement that an attacker with no peers would learn nothing about the Bitcoin network.The attack involves an attacker listening to transactions on the Bitcoin network and recording the first 8-10 peers that forward each transaction. This allows the attacker to link together different Bitcoin addresses and learn the IP of the client. The 8 entry peers are unique per client, so users sharing the same IP can be distinguished. Outbound connections are rotated from time to time due to remote disconnections, but the initial connections prefer nodes that were up recently.Pustogarov expressed concern about attackers without peers linking Bitcoin addresses and learning client IPs. The recipient of the email was confused about how this would be possible without any peers. Pustogarov explained that the unique 8 entry peers per client allow distinguishing users with the same IP. The discussion also touched on the rotation of outbound connections and the need for privacy through broadcasting over tor or i2p.In a Bitcoin-development mailing list conversation, Pustogarov proposed periodic rotation of outbound connections to improve network knowledge and make it stronger against partitioning. However, Maxwell disagreed, stating that constant outbound peers can prevent attackers from gaining strong evidence about transaction origin. It was recommended to broadcast over tor or i2p for privacy.Pustogarov initiated a discussion on the periodic rotation of outbound connections to improve network knowledge and make it stronger against partitioning. However, one recipient noted that rotating peers excessively is unnecessary and suggested broadcasting over tor or i2p for privacy.The periodic rotation of outbound connections aims to mitigate risks associated with 8 entry nodes uniquely identifying users. Attackers can link different blockchain addresses using this information. The proposed solution recommends periodic rotation to blur the fingerprint over time. Bitcoin clients advertise their public IP addresses, allowing attackers to deanonymize clients. The corresponding pull request is #4723, and more details can be found at cryptolux.org.In conclusion, Pustogarov's proposal for periodic rotation of outbound connections aims to address the risk of attackers linking Bitcoin addresses and learning client IPs. The discussion highlights the need for privacy through broadcasting over tor or i2p. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml b/static/bitcoin-dev/Aug_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml index bdae5cf2a5..8b4c87a598 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys - 2023-08-01T08:17:21.054953+00:00 + 2025-10-11T22:00:32.027770+00:00 + python-feedgen Nikita Schmidt 2014-08-14 19:23:16+00:00 @@ -363,13 +364,13 @@ - python-feedgen + 2 Combined summary - Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys - 2023-08-01T08:17:21.055952+00:00 + 2025-10-11T22:00:32.028048+00:00 - Jan Møller, in an email exchange, expressed his opinion that the current format of the Shared Secret Sharing (SSS) standard is over-engineered. He suggested that only the long format makes sense from a user experience standpoint and proposed that it is only slightly longer than the short version. After no objections were raised, the draft was revised to address this concern.The new version of the SSS standard allows for the shared secret to be encoded in various forms, such as SIPA or BIP38, instead of just a plain private key. This change has several benefits, including not needing to modify the specification for different types of content and encoding metadata together with the secret. The underlying field of the standard was also changed to GF(256), which is more advantageous for dealing with secrets of arbitrary length.To solve the issue of variable length and lack of control over the Base58 prefix, the magic prefix was moved outside of the Base58 encoded content. The application identifier 'SSS-' was introduced, followed by the Base58 encoding of the share. This change may be mildly controversial, and alternatives could be considered.A Java implementation of BIPSS based on a GF2^8 implementation can be found on Github. The use of three encoding formats in the SSS standard is considered over-engineered, with the long format being the only necessary option from a user experience perspective. A fork of Matt's proposal converted to GF(2^8) is also available on Github, which includes changes like allocating only six application/version bytes and using SHA-256 hash functions.The inclusion of a specific flag for testnet in SSS and BIP32 was discussed in email exchanges. It was agreed that such flags are unnecessary since they are not used for sending addresses. The convention so far has been to include a 'version' identifier to identify the purpose of the data, such as network meaning.There was a debate about the importance of testnet in Bitcoin Improvement Proposals (BIPs). Some argued that testnet exists for public testing involving multiple people and services, while others saw it as a tool for certain types of testing. It was noted that testnet is not normally addressed in BIPs, except for soft fork BIPs with compressed deployment schedules on testnet.The serialization of keys when using test chains was discussed, with some expressing that distinguishing serialization of keys is unnecessary. The difference between testnet and mainnet was emphasized as separate from bitcoin vs altcoin, but few altcoins understood this distinction.The issue of encoding the chain in WIF and BIP32 was debated, with some suggesting that it should be ignored as legacy. New BIPs should no longer carry this forward.Discussions also took place regarding the encoding of N-of-M shares. Suggestions were made to encode N-of-M in one byte and to use a bias of -1 for M encoding. Test vectors were updated accordingly.Tamas Blummer expressed his opinion that extra encoding for testnet is not necessary compared to many alt chains. He suggested that BIPs should remain chain agnostic.In an email exchange between Jan Møller and Gregory Maxwell, Møller expressed his concerns about BIP38 and suggested using Shamir's Secret Sharing instead. It is unclear if Møller provided a list of concerns about BIP38 or offered to do so upon request.Tamas Blummer argued that the wide variety of available chains supersedes the notion of main and testnet. He believes that what altcoins do is their own business and outside the scope of a BIP. He also questioned the need for a separate encoding for Bitcoin testnet private keys.Overall, the discussions revolved around simplifying the SSS standard, considering the use cases for testnet and altchains, and debating the encoding of keys and chains in various contexts.The complexity of using the binary extension field of GF(2^8) for secret sharing and data integrity applications was discussed. Some suggested that big-integer operations may be more practical, while others argued that implementing a complex system with many individually testable parts is easier than implementing a single complex part. Gregory Maxwell's implementation of his Bitcoin Improvement Proposal (BIP) is in C++ and uses the GMP library for big-integer arithmetic.There was a debate about the potential risks of obfuscating the parameters of the secret sharing process. Some expressed concerns about users accidentally mixing different types of fragments or distributing too many, which can lead to insecurity or difficulty in restoring their wallets. However, it was acknowledged that attackers may still be able to figure out the information despite the obfuscation.Matt Whitlock proposed an obfuscation method for the secret sharing process but ultimately decided against it based on the consensus of others. Alan Reiner disagreed with this tradeoff, stating that obfuscating something already considered secure at the expense of usability is not beneficial. He argued that it is more important for users to understand what 2014-08-14T19:23:16+00:00 + Jan Møller, in an email exchange, expressed his opinion that the current format of the Shared Secret Sharing (SSS) standard is over-engineered. He suggested that only the long format makes sense from a user experience standpoint and proposed that it is only slightly longer than the short version. After no objections were raised, the draft was revised to address this concern.The new version of the SSS standard allows for the shared secret to be encoded in various forms, such as SIPA or BIP38, instead of just a plain private key. This change has several benefits, including not needing to modify the specification for different types of content and encoding metadata together with the secret. The underlying field of the standard was also changed to GF(256), which is more advantageous for dealing with secrets of arbitrary length.To solve the issue of variable length and lack of control over the Base58 prefix, the magic prefix was moved outside of the Base58 encoded content. The application identifier 'SSS-' was introduced, followed by the Base58 encoding of the share. This change may be mildly controversial, and alternatives could be considered.A Java implementation of BIPSS based on a GF2^8 implementation can be found on Github. The use of three encoding formats in the SSS standard is considered over-engineered, with the long format being the only necessary option from a user experience perspective. A fork of Matt's proposal converted to GF(2^8) is also available on Github, which includes changes like allocating only six application/version bytes and using SHA-256 hash functions.The inclusion of a specific flag for testnet in SSS and BIP32 was discussed in email exchanges. It was agreed that such flags are unnecessary since they are not used for sending addresses. The convention so far has been to include a 'version' identifier to identify the purpose of the data, such as network meaning.There was a debate about the importance of testnet in Bitcoin Improvement Proposals (BIPs). Some argued that testnet exists for public testing involving multiple people and services, while others saw it as a tool for certain types of testing. It was noted that testnet is not normally addressed in BIPs, except for soft fork BIPs with compressed deployment schedules on testnet.The serialization of keys when using test chains was discussed, with some expressing that distinguishing serialization of keys is unnecessary. The difference between testnet and mainnet was emphasized as separate from bitcoin vs altcoin, but few altcoins understood this distinction.The issue of encoding the chain in WIF and BIP32 was debated, with some suggesting that it should be ignored as legacy. New BIPs should no longer carry this forward.Discussions also took place regarding the encoding of N-of-M shares. Suggestions were made to encode N-of-M in one byte and to use a bias of -1 for M encoding. Test vectors were updated accordingly.Tamas Blummer expressed his opinion that extra encoding for testnet is not necessary compared to many alt chains. He suggested that BIPs should remain chain agnostic.In an email exchange between Jan Møller and Gregory Maxwell, Møller expressed his concerns about BIP38 and suggested using Shamir's Secret Sharing instead. It is unclear if Møller provided a list of concerns about BIP38 or offered to do so upon request.Tamas Blummer argued that the wide variety of available chains supersedes the notion of main and testnet. He believes that what altcoins do is their own business and outside the scope of a BIP. He also questioned the need for a separate encoding for Bitcoin testnet private keys.Overall, the discussions revolved around simplifying the SSS standard, considering the use cases for testnet and altchains, and debating the encoding of keys and chains in various contexts.The complexity of using the binary extension field of GF(2^8) for secret sharing and data integrity applications was discussed. Some suggested that big-integer operations may be more practical, while others argued that implementing a complex system with many individually testable parts is easier than implementing a single complex part. Gregory Maxwell's implementation of his Bitcoin Improvement Proposal (BIP) is in C++ and uses the GMP library for big-integer arithmetic.There was a debate about the potential risks of obfuscating the parameters of the secret sharing process. Some expressed concerns about users accidentally mixing different types of fragments or distributing too many, which can lead to insecurity or difficulty in restoring their wallets. However, it was acknowledged that attackers may still be able to figure out the information despite the obfuscation.Matt Whitlock proposed an obfuscation method for the secret sharing process but ultimately decided against it based on the consensus of others. Alan Reiner disagreed with this tradeoff, stating that obfuscating something already considered secure at the expense of usability is not beneficial. He argued that it is more important for users to understand what - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Proposal-Encrypt-bitcoin-messages.xml b/static/bitcoin-dev/Aug_2014/combined_Proposal-Encrypt-bitcoin-messages.xml index b8c9a67996..3703f3187d 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Proposal-Encrypt-bitcoin-messages.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Proposal-Encrypt-bitcoin-messages.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: Encrypt bitcoin messages - 2023-08-01T10:15:00.966381+00:00 + 2025-10-11T22:00:15.012644+00:00 + python-feedgen Peter Todd 2014-08-23 22:51:38+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - Proposal: Encrypt bitcoin messages - 2023-08-01T10:15:00.966381+00:00 + 2025-10-11T22:00:15.012881+00:00 - In a discussion about the security of the Bitcoin network and the role of encryption, it was mentioned that packet sizes and timings can potentially reveal valuable information. However, Peter emphasized the importance of using encryption as an additional layer of security. He recommended utilizing Tor support to encrypt inter-node traffic by default, citing its effectiveness. The debate around encrypting transport methods in Bitcoin led to differing opinions. Some argued against encryption, claiming that it could make it easier for attackers to perform man-in-the-middle attacks. Instead, they suggested using HMAC for protocol message authentication. The consensus, however, seemed to be that the risk/reward payoff for implementing encryption is not worthwhile. Nonetheless, alternatives such as Tor or VPN services were mentioned for nodes requiring a higher level of security.The discussion also touched upon the idea of encrypting communications between nodes in the Bitcoin network. It was agreed that all nodes require a high level of security. Suggestions included using Tor or VPN services instead of encryption. Concerns were raised about recent vulnerabilities in OpenSSL. Gregory Maxwell expressed his belief that not having TLS had helped avoid several emergency scale vulnerabilities. Johnathan Corgan proposed using HMAC for the protocol messages instead of the current checksum. The use of TLS was debated, with concerns regarding its attack surface and vulnerabilities in major implementations. Justus Ranvier suggested using TLS with self-signed certificates, but Gregory Maxwell disagreed.There were suggestions for Bitcoin Core to generate public/private key pairs and share the public keys with peers. However, concerns were raised about securely sharing public keys and avoiding man-in-the-middle attacks. The use of SSH fingerprint and self-signed certificates with TLS was also proposed.Overall, the discussion emphasized the importance of secure communication protocols in Bitcoin Core and the need to find a balance between security and practicality. 2014-08-23T22:51:38+00:00 + In a discussion about the security of the Bitcoin network and the role of encryption, it was mentioned that packet sizes and timings can potentially reveal valuable information. However, Peter emphasized the importance of using encryption as an additional layer of security. He recommended utilizing Tor support to encrypt inter-node traffic by default, citing its effectiveness. The debate around encrypting transport methods in Bitcoin led to differing opinions. Some argued against encryption, claiming that it could make it easier for attackers to perform man-in-the-middle attacks. Instead, they suggested using HMAC for protocol message authentication. The consensus, however, seemed to be that the risk/reward payoff for implementing encryption is not worthwhile. Nonetheless, alternatives such as Tor or VPN services were mentioned for nodes requiring a higher level of security.The discussion also touched upon the idea of encrypting communications between nodes in the Bitcoin network. It was agreed that all nodes require a high level of security. Suggestions included using Tor or VPN services instead of encryption. Concerns were raised about recent vulnerabilities in OpenSSL. Gregory Maxwell expressed his belief that not having TLS had helped avoid several emergency scale vulnerabilities. Johnathan Corgan proposed using HMAC for the protocol messages instead of the current checksum. The use of TLS was debated, with concerns regarding its attack surface and vulnerabilities in major implementations. Justus Ranvier suggested using TLS with self-signed certificates, but Gregory Maxwell disagreed.There were suggestions for Bitcoin Core to generate public/private key pairs and share the public keys with peers. However, concerns were raised about securely sharing public keys and avoiding man-in-the-middle attacks. The use of SSH fingerprint and self-signed certificates with TLS was also proposed.Overall, the discussion emphasized the importance of secure communication protocols in Bitcoin Core and the need to find a balance between security and practicality. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Proposal-PoW-based-throttling-of-addresses-was-Outbound-connections-rotation-.xml b/static/bitcoin-dev/Aug_2014/combined_Proposal-PoW-based-throttling-of-addresses-was-Outbound-connections-rotation-.xml index a98033466a..6d25f02635 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Proposal-PoW-based-throttling-of-addresses-was-Outbound-connections-rotation-.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Proposal-PoW-based-throttling-of-addresses-was-Outbound-connections-rotation-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: PoW-based throttling of addresses (was: Outbound connections rotation) - 2023-08-01T10:17:22.140245+00:00 + 2025-10-11T22:00:04.391550+00:00 + python-feedgen Isidor Zeuner 2014-11-27 03:29:24+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Proposal: PoW-based throttling of addresses (was: Outbound connections rotation) - 2023-08-01T10:17:22.140245+00:00 + 2025-10-11T22:00:04.391706+00:00 - The conversation between Mike and Isidor revolves around the impact of DKIM and PoW/hash-cash in email businesses. Isidor argues that bulk mailing companies use destination DKIM toggling to reduce CPU usage, but this may become impractical when using Bitcoin over Tor. He also challenges Mike's statement on humans not caring about delays but their source, suggesting that users do notice slow website or mobile wallet performance and avoid them. Mike counters that Tor is a separate issue and notifying users of anomalies would be unhelpful since they cannot take actionable decisions. They agree that the solution to a privacy-attacking DoS attack is to not use Tor at all, while solving an attack on the entire Bitcoin network is much more challenging.A former employee considers DKIM as a cheap and irrelevant aspect in the email business. Proof of Work (PoW) has not effectively deterred spamming efforts as it confuses bulk mail with spam. Slow website performance does matter to humans as it negatively impacts revenue. PoW tokens can be useful in a shared toolbox if nodes cannot prioritize connections, but if all users are subjected to PoW, it could lead to game over. Tor should be considered separately from the DoS problem, and users generally do not care about technical jargon like peer-to-peer networks or Tor. The solution to a privacy-attacking DoS attack is to avoid using Tor, while solving an attack on the entire Bitcoin network is more complex.The discussion centers on using PoW to combat DoS attacks in cryptocurrencies. PoW has been recognized since the days of "hashcash" before cryptocurrencies existed. However, it did not work well against bots, who have more patience than humans. DKIM, another PoW approach, is disliked by bulk mailer operators due to the CPU burden it creates. Nevertheless, users see it as advantageous for identifying participants. In cryptocurrencies, PoW can be used to combat DoS without compromising user identification. Allowing users to prove their dedication through a connecting PoW challenge can help them navigate a DoS-imposed partial outage. Nodes can utilize measures such as scaling up connection PoW, throttling the connection on the work queue, and throttling the IP on the work queue to throttle misbehaving clients. However, proper tuning of these measures is crucial to minimize the impact on well-behaving users.It is important to avoid misclassifying reasonable behavior as harmful to prevent unintended consequences. Big sites often suffer DoS attacks due to accidental bad software updates or unexpected press-driven growth. Users should be notified when unusual events occur. Approaches like cookies and Proof of UTXO provide additional possibilities to deduce user identity, making them less ideal for maintaining privacy. The use of PoW as a defense against DoS attacks has been recognized since the pre-cryptocurrency days of "hashcash." However, scoring connections and distinguishing bots from humans remains a challenge. Human PoWs in the form of CAPTCHAs also prove ineffective. Concerns about using cookies to link connections and deanonymize users are mitigated by the likelihood of DoS attacks being driven by botnets. Proof of UTXO presents another way to rank users, but it carries CPU imbalances that can be leveled out with a small PoW cost.Isidor proposes a PoW-based approach to prevent DoS attacks on Tor exit nodes for Bitcoin. He suggests that only misbehaving clients should be required to do the PoW, making it harder for attackers to sustain their attacks. Mike suggests that work prioritization and queueing mechanisms, along with finding ways to distinguish "good" clients from "bad" ones, are the correct solutions. However, preserving privacy while implementing these measures poses challenges. Isidor proposes having both options available - allowing those who can solve the anti-DoS PoW to connect, albeit slower, while those who prefer weaker clients can sacrifice privacy for connectivity using cookies.The article discusses the difficulty of addressing DoS attacks on Tor exit nodes used for connecting to Bitcoin. Requiring all clients to perform complicated work wouldn't solve the issue and would make weak clients vulnerable while attackers' botnets solve PoWs. The article suggests implementing work prioritization and queueing mechanisms to distinguish "good" clients from "bad" ones. However, maintaining privacy during this process is challenging. Requiring clients to present a cookie during resource exhaustion events to prove their longevity and allow them to jump the queue may be a long-term solution.To improve privacy when posting transactions using unrelated inputs, the article suggests using only the same set of nodes for subsequent transactions with the same input addresses. This approach mirrors how Tor uses different circuits for connecting to different hosts. Completely banning Tor exit nodes may not be the best solution, but throttling them using a PoW-based access control scheme could be more effective. Scaling up the connecting difficulty for misbehaving addresses would discourage DoS attacks on Tor exit nodes for Bitcoin connectivity. Additionally, this approach can 2014-11-27T03:29:24+00:00 + The conversation between Mike and Isidor revolves around the impact of DKIM and PoW/hash-cash in email businesses. Isidor argues that bulk mailing companies use destination DKIM toggling to reduce CPU usage, but this may become impractical when using Bitcoin over Tor. He also challenges Mike's statement on humans not caring about delays but their source, suggesting that users do notice slow website or mobile wallet performance and avoid them. Mike counters that Tor is a separate issue and notifying users of anomalies would be unhelpful since they cannot take actionable decisions. They agree that the solution to a privacy-attacking DoS attack is to not use Tor at all, while solving an attack on the entire Bitcoin network is much more challenging.A former employee considers DKIM as a cheap and irrelevant aspect in the email business. Proof of Work (PoW) has not effectively deterred spamming efforts as it confuses bulk mail with spam. Slow website performance does matter to humans as it negatively impacts revenue. PoW tokens can be useful in a shared toolbox if nodes cannot prioritize connections, but if all users are subjected to PoW, it could lead to game over. Tor should be considered separately from the DoS problem, and users generally do not care about technical jargon like peer-to-peer networks or Tor. The solution to a privacy-attacking DoS attack is to avoid using Tor, while solving an attack on the entire Bitcoin network is more complex.The discussion centers on using PoW to combat DoS attacks in cryptocurrencies. PoW has been recognized since the days of "hashcash" before cryptocurrencies existed. However, it did not work well against bots, who have more patience than humans. DKIM, another PoW approach, is disliked by bulk mailer operators due to the CPU burden it creates. Nevertheless, users see it as advantageous for identifying participants. In cryptocurrencies, PoW can be used to combat DoS without compromising user identification. Allowing users to prove their dedication through a connecting PoW challenge can help them navigate a DoS-imposed partial outage. Nodes can utilize measures such as scaling up connection PoW, throttling the connection on the work queue, and throttling the IP on the work queue to throttle misbehaving clients. However, proper tuning of these measures is crucial to minimize the impact on well-behaving users.It is important to avoid misclassifying reasonable behavior as harmful to prevent unintended consequences. Big sites often suffer DoS attacks due to accidental bad software updates or unexpected press-driven growth. Users should be notified when unusual events occur. Approaches like cookies and Proof of UTXO provide additional possibilities to deduce user identity, making them less ideal for maintaining privacy. The use of PoW as a defense against DoS attacks has been recognized since the pre-cryptocurrency days of "hashcash." However, scoring connections and distinguishing bots from humans remains a challenge. Human PoWs in the form of CAPTCHAs also prove ineffective. Concerns about using cookies to link connections and deanonymize users are mitigated by the likelihood of DoS attacks being driven by botnets. Proof of UTXO presents another way to rank users, but it carries CPU imbalances that can be leveled out with a small PoW cost.Isidor proposes a PoW-based approach to prevent DoS attacks on Tor exit nodes for Bitcoin. He suggests that only misbehaving clients should be required to do the PoW, making it harder for attackers to sustain their attacks. Mike suggests that work prioritization and queueing mechanisms, along with finding ways to distinguish "good" clients from "bad" ones, are the correct solutions. However, preserving privacy while implementing these measures poses challenges. Isidor proposes having both options available - allowing those who can solve the anti-DoS PoW to connect, albeit slower, while those who prefer weaker clients can sacrifice privacy for connectivity using cookies.The article discusses the difficulty of addressing DoS attacks on Tor exit nodes used for connecting to Bitcoin. Requiring all clients to perform complicated work wouldn't solve the issue and would make weak clients vulnerable while attackers' botnets solve PoWs. The article suggests implementing work prioritization and queueing mechanisms to distinguish "good" clients from "bad" ones. However, maintaining privacy during this process is challenging. Requiring clients to present a cookie during resource exhaustion events to prove their longevity and allow them to jump the queue may be a long-term solution.To improve privacy when posting transactions using unrelated inputs, the article suggests using only the same set of nodes for subsequent transactions with the same input addresses. This approach mirrors how Tor uses different circuits for connecting to different hosts. Completely banning Tor exit nodes may not be the best solution, but throttling them using a PoW-based access control scheme could be more effective. Scaling up the connecting difficulty for misbehaving addresses would discourage DoS attacks on Tor exit nodes for Bitcoin connectivity. Additionally, this approach can - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_RIP-Hal-Finney.xml b/static/bitcoin-dev/Aug_2014/combined_RIP-Hal-Finney.xml index 024cc230fc..cff1babade 100644 --- a/static/bitcoin-dev/Aug_2014/combined_RIP-Hal-Finney.xml +++ b/static/bitcoin-dev/Aug_2014/combined_RIP-Hal-Finney.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RIP Hal Finney - 2023-08-01T10:18:17.536259+00:00 + 2025-10-11T21:59:53.766720+00:00 + python-feedgen Oliver Egginger 2014-08-29 09:29:56+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - RIP Hal Finney - 2023-08-01T10:18:17.536259+00:00 + 2025-10-11T21:59:53.766889+00:00 - On August 28, 2014, the death of Hal Finney was announced by Matt Corallo. Although the writer did not personally know him, he expressed sadness upon hearing the news. Hal Finney had previously written a post on Bitcoin Talk in 2013, discussing his battle with ALS, which served as an inspiration to many. Oliver, recognizing Hal Finney's inspiring character and his significant work and contributions, paid tribute to him.Hal Finney was a well-known figure in the cypherpunk community and his passing on Tuesday marked a great loss. His involvement in the early days of Bitcoin and PGP (Pretty Good Privacy) played a crucial role in their development. The cypherpunk movement greatly appreciated his contributions. Matt shared the news on an Extropy chat forum and encouraged everyone to take a moment to express gratitude to Hal for everything he had done for the community.It is worth noting that Hal Finney's body is being cryogenically preserved, a process that involves freezing the body in the hopes of future revival or repair. This decision reflects his desire for a potential future where medical advancements could potentially cure his condition. 2014-08-29T09:29:56+00:00 + On August 28, 2014, the death of Hal Finney was announced by Matt Corallo. Although the writer did not personally know him, he expressed sadness upon hearing the news. Hal Finney had previously written a post on Bitcoin Talk in 2013, discussing his battle with ALS, which served as an inspiration to many. Oliver, recognizing Hal Finney's inspiring character and his significant work and contributions, paid tribute to him.Hal Finney was a well-known figure in the cypherpunk community and his passing on Tuesday marked a great loss. His involvement in the early days of Bitcoin and PGP (Pretty Good Privacy) played a crucial role in their development. The cypherpunk movement greatly appreciated his contributions. Matt shared the news on an Extropy chat forum and encouraged everyone to take a moment to express gratitude to Hal for everything he had done for the community.It is worth noting that Hal Finney's body is being cryogenically preserved, a process that involves freezing the body in the hopes of future revival or repair. This decision reflects his desire for a potential future where medical advancements could potentially cure his condition. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Reconsidering-github.xml b/static/bitcoin-dev/Aug_2014/combined_Reconsidering-github.xml index 6140f41519..cbe155d90c 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Reconsidering-github.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Reconsidering-github.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reconsidering github - 2023-08-01T10:15:48.875984+00:00 + 2025-10-11T22:00:19.269033+00:00 + python-feedgen Odinn Cyberguerrilla 2014-08-30 03:33:52+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - Reconsidering github - 2023-08-01T10:15:48.876983+00:00 + 2025-10-11T22:00:19.269246+00:00 - In an email thread from August 2014, concerns were raised about the dependency of Bitcoin on GitHub and the need for secure alternatives. Troy Benjegerdes expressed his skepticism about trusting his financial future to software written by a group that cannot even organize their own hosting and security measures. However, another member of the thread pointed out that the integrity of repositories is protected by digital signatures and cryptographic hashes, regardless of their location.Jeff Garzik also suggested moving away from GitHub for Bitcoin Core's issues and git repo. He argued that GitHub was a centralized service and proposed mirroring the primary repo on bitcoin.org and GitHub for each push. However, Wladimir disagreed, stating that GitHub had a low barrier to entry for contributors and switching platforms would make contributions more difficult. He also mentioned the manpower required for self-hosting and the migration of current issues and pulls.In response to the discussion, Bryan Bishop suggested a smaller first step of mirroring the git repository on bitcoin.org before making any changes. This would be a necessary step towards switching the primary repository. Jeff Garzik had emphasized that if Bitcoin Core has a working workflow elsewhere, changing the repository's location should not be a leap of faith.The conversation highlighted the need for secure alternatives to GitHub for Bitcoin's sustainability. It was suggested that code review and bug tracking could be moved elsewhere, with JetBrains developing Upsource as a code review and repository exploration tool designed for self-hosting. However, some argued that regardless of the repository's location, the security of the software is ensured through digital signatures and cryptographic hashes.Overall, while there were discussions about moving away from GitHub for Bitcoin Core, there were differing opinions on the feasibility and benefits of such a move. The convenience and low barrier to entry offered by GitHub were highlighted, but concerns about centralization and security were also raised. 2014-08-30T03:33:52+00:00 + In an email thread from August 2014, concerns were raised about the dependency of Bitcoin on GitHub and the need for secure alternatives. Troy Benjegerdes expressed his skepticism about trusting his financial future to software written by a group that cannot even organize their own hosting and security measures. However, another member of the thread pointed out that the integrity of repositories is protected by digital signatures and cryptographic hashes, regardless of their location.Jeff Garzik also suggested moving away from GitHub for Bitcoin Core's issues and git repo. He argued that GitHub was a centralized service and proposed mirroring the primary repo on bitcoin.org and GitHub for each push. However, Wladimir disagreed, stating that GitHub had a low barrier to entry for contributors and switching platforms would make contributions more difficult. He also mentioned the manpower required for self-hosting and the migration of current issues and pulls.In response to the discussion, Bryan Bishop suggested a smaller first step of mirroring the git repository on bitcoin.org before making any changes. This would be a necessary step towards switching the primary repository. Jeff Garzik had emphasized that if Bitcoin Core has a working workflow elsewhere, changing the repository's location should not be a leap of faith.The conversation highlighted the need for secure alternatives to GitHub for Bitcoin's sustainability. It was suggested that code review and bug tracking could be moved elsewhere, with JetBrains developing Upsource as a code review and repository exploration tool designed for self-hosting. However, some argued that regardless of the repository's location, the security of the software is ensured through digital signatures and cryptographic hashes.Overall, while there were discussions about moving away from GitHub for Bitcoin Core, there were differing opinions on the feasibility and benefits of such a move. The convenience and low barrier to entry offered by GitHub were highlighted, but concerns about centralization and security were also raised. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Squashing-redundant-tx-data-in-blocks-on-the-wire.xml b/static/bitcoin-dev/Aug_2014/combined_Squashing-redundant-tx-data-in-blocks-on-the-wire.xml index 89953ce9ad..3f888032ec 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Squashing-redundant-tx-data-in-blocks-on-the-wire.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Squashing-redundant-tx-data-in-blocks-on-the-wire.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Squashing redundant tx data in blocks on the wire - 2023-08-01T09:47:20.622686+00:00 + 2025-10-11T21:59:49.519783+00:00 + python-feedgen Kaz Wesley 2014-08-01 01:00:06+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - Squashing redundant tx data in blocks on the wire - 2023-08-01T09:47:20.623685+00:00 + 2025-10-11T21:59:49.519972+00:00 - In an email exchange, Gregory Maxwell and Kaz Wesley discussed the possibility of developing a rule to avoid false negatives or excessive storage requirements. Kaz is working on a prototype that will provide data on the false-positive-missing-tx rate using a "remember-last-N" approach. They explored various upgrades to this rule, including learning dropped transactions through mempool syncing or specifying the rule explicitly with priority scripts.The idea of mempool synchronization raised concerns about transaction expiration. Gregory also mentioned the benefits of channel memory sparseblocks and FEC-based mempool synchronization. While implementing FEC at block forwarding time can minimize latency with multiple peers, they agreed that starting with a simple approach would be best.The discussion continued as Kaz Wesley questioned the need to solve the problem of missing transactions since the current protocol already exchanges necessary information. However, false positives and false negatives are still concerns when dealing with multiple peers. Kaz suggested that channel memory sparseblocks could achieve most of the possible bandwidth savings, and FEC-based mempool synchronization could reset the channel memory to the mutual mempool state. This would provide similar benefits to FEC-based block forwarding. The suggestion of using part of a cryptographic permutation as the key was also mentioned as a way to transmit new unknown keys without adding overhead.In another email exchange, Kaz Wesley emphasized the communication overhead of transmitting a transaction list. He proposed a method using forward error correcting (FEC) code data to fill in missing transactions without prior knowledge. Kaz acknowledged that sending 100% of the missing amount can save time if the transport is unordered. The suggestion of using part of a cryptographic permutation as the key was again mentioned as a way to avoid overhead for unknown transactions.On July 31, 2014, Gregory Maxwell and Kaz Wesley discussed the communication overhead of transmitting a transaction list. The current approach of sending 32 bits per transaction was deemed inefficient compared to a simpler approach. Gregory explained the use of non-syndromic forward error correcting code data to minimize overhead. However, it was noted that knowing the sizes and orders of the transactions is essential for this approach to be effective.Kaz Wesley suggested a method for retrieving missing transactions using forward error correcting (FEC) code data in an email conversation. This involved sending slightly larger non-syndromic FEC code data based on estimated missing data. The missing blocks could then be recovered using the FEC code. Wesley provided further details on how to implement this method effectively.The discussion touched on the practicality of set reconciliation for condensed block exchange. It was acknowledged that requesting missing transaction keys would require a round trip, making it costly for exchanging transactions not mutually known. Instead, remembering transmitted invs along connections was deemed effective for reducing bytes and CPU cycles. The current protocol already provides mutual knowledge, allowing for efficient block exchange. The implementation of inv-history-tracking and sparseblock messages were mentioned as improvements. Compact descriptions of block tx inclusion and ordering policies could eliminate overhead for known and unknown transactions. Efficient mempool synchronization and mempool exchange were also discussed to enhance channel-memory sparseblocks and prevent sybil attacks.Gavin Andresen expressed his thoughts on incentivizing nodes to propagate transactions in an email thread. He suggested rewarding nodes for propagating transactions since most transaction data has already been propagated. Wladimir proposed starting the set synchronization process when a miner begins working on a specific block. This would prepare peers for the actual block broadcast, which would only consist of the header and coinbase transaction.In a conversation, Emin Gün Sirer and another individual discussed minimizing data transfer in cryptocurrency mining. The round complexity was seen as crucial, with Yaron's non-interactive scheme being praised for its lack of overhead. Forward error correction (FEC) was suggested but acknowledged to still have some overhead. The multithreading of the client was considered the best approach, although the potential applicability of Yaron's work was noted.Emin Gün Sirer discussed a problem similar to set reconciliation and the importance of minimizing data transfer. The round complexity was highlighted, and a previous proposal to use FEC for low data transfer was mentioned. However, it was acknowledged that FEC schemes are complex and add metadata overhead.A new technique for solving the set reconciliation problem was described in a Cornell paper. This approach aimed to reduce communication complexity between peers and eliminate overhead. Set reconciliation was compared to Bloom filters, with the former being more efficient and non-interactive. The author invited interested parties to apply this technique to the Bitcoin p2p protocol.Kaz Wesley proposed an additional proposal involving sparse blocks and ultra-fast block validation (UFBV). This would incentivize ahead-of-block transaction propagation and make the new-block process more efficient for miners. The benefits of these changes were emphasized, but they only applied when transactions were seen in advance. Jeff Garzik, a Bitcoin core developer, was mentioned as being involved with BitPay, Inc.In a discussion on the Bitcoin-development mailing list, Kaz Wesley proposed that peers should exchange mempool priority policies and 2014-08-01T01:00:06+00:00 + In an email exchange, Gregory Maxwell and Kaz Wesley discussed the possibility of developing a rule to avoid false negatives or excessive storage requirements. Kaz is working on a prototype that will provide data on the false-positive-missing-tx rate using a "remember-last-N" approach. They explored various upgrades to this rule, including learning dropped transactions through mempool syncing or specifying the rule explicitly with priority scripts.The idea of mempool synchronization raised concerns about transaction expiration. Gregory also mentioned the benefits of channel memory sparseblocks and FEC-based mempool synchronization. While implementing FEC at block forwarding time can minimize latency with multiple peers, they agreed that starting with a simple approach would be best.The discussion continued as Kaz Wesley questioned the need to solve the problem of missing transactions since the current protocol already exchanges necessary information. However, false positives and false negatives are still concerns when dealing with multiple peers. Kaz suggested that channel memory sparseblocks could achieve most of the possible bandwidth savings, and FEC-based mempool synchronization could reset the channel memory to the mutual mempool state. This would provide similar benefits to FEC-based block forwarding. The suggestion of using part of a cryptographic permutation as the key was also mentioned as a way to transmit new unknown keys without adding overhead.In another email exchange, Kaz Wesley emphasized the communication overhead of transmitting a transaction list. He proposed a method using forward error correcting (FEC) code data to fill in missing transactions without prior knowledge. Kaz acknowledged that sending 100% of the missing amount can save time if the transport is unordered. The suggestion of using part of a cryptographic permutation as the key was again mentioned as a way to avoid overhead for unknown transactions.On July 31, 2014, Gregory Maxwell and Kaz Wesley discussed the communication overhead of transmitting a transaction list. The current approach of sending 32 bits per transaction was deemed inefficient compared to a simpler approach. Gregory explained the use of non-syndromic forward error correcting code data to minimize overhead. However, it was noted that knowing the sizes and orders of the transactions is essential for this approach to be effective.Kaz Wesley suggested a method for retrieving missing transactions using forward error correcting (FEC) code data in an email conversation. This involved sending slightly larger non-syndromic FEC code data based on estimated missing data. The missing blocks could then be recovered using the FEC code. Wesley provided further details on how to implement this method effectively.The discussion touched on the practicality of set reconciliation for condensed block exchange. It was acknowledged that requesting missing transaction keys would require a round trip, making it costly for exchanging transactions not mutually known. Instead, remembering transmitted invs along connections was deemed effective for reducing bytes and CPU cycles. The current protocol already provides mutual knowledge, allowing for efficient block exchange. The implementation of inv-history-tracking and sparseblock messages were mentioned as improvements. Compact descriptions of block tx inclusion and ordering policies could eliminate overhead for known and unknown transactions. Efficient mempool synchronization and mempool exchange were also discussed to enhance channel-memory sparseblocks and prevent sybil attacks.Gavin Andresen expressed his thoughts on incentivizing nodes to propagate transactions in an email thread. He suggested rewarding nodes for propagating transactions since most transaction data has already been propagated. Wladimir proposed starting the set synchronization process when a miner begins working on a specific block. This would prepare peers for the actual block broadcast, which would only consist of the header and coinbase transaction.In a conversation, Emin Gün Sirer and another individual discussed minimizing data transfer in cryptocurrency mining. The round complexity was seen as crucial, with Yaron's non-interactive scheme being praised for its lack of overhead. Forward error correction (FEC) was suggested but acknowledged to still have some overhead. The multithreading of the client was considered the best approach, although the potential applicability of Yaron's work was noted.Emin Gün Sirer discussed a problem similar to set reconciliation and the importance of minimizing data transfer. The round complexity was highlighted, and a previous proposal to use FEC for low data transfer was mentioned. However, it was acknowledged that FEC schemes are complex and add metadata overhead.A new technique for solving the set reconciliation problem was described in a Cornell paper. This approach aimed to reduce communication complexity between peers and eliminate overhead. Set reconciliation was compared to Bloom filters, with the former being more efficient and non-interactive. The author invited interested parties to apply this technique to the Bitcoin p2p protocol.Kaz Wesley proposed an additional proposal involving sparse blocks and ultra-fast block validation (UFBV). This would incentivize ahead-of-block transaction propagation and make the new-block process more efficient for miners. The benefits of these changes were emphasized, but they only applied when transactions were seen in advance. Jeff Garzik, a Bitcoin core developer, was mentioned as being involved with BitPay, Inc.In a discussion on the Bitcoin-development mailing list, Kaz Wesley proposed that peers should exchange mempool priority policies and - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Synchronization-19-5-orphaned-blocks-at-height-197-324.xml b/static/bitcoin-dev/Aug_2014/combined_Synchronization-19-5-orphaned-blocks-at-height-197-324.xml index 8343e36e30..4c50926c4b 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Synchronization-19-5-orphaned-blocks-at-height-197-324.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Synchronization-19-5-orphaned-blocks-at-height-197-324.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Synchronization: 19.5 % orphaned blocks at height 197'324 - 2023-08-01T10:13:34.636634+00:00 + 2025-10-11T21:59:51.643685+00:00 + python-feedgen Pieter Wuille 2014-08-10 18:07:54+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Synchronization: 19.5 % orphaned blocks at height 197'324 - 2023-08-01T10:13:34.636634+00:00 + 2025-10-11T21:59:51.643844+00:00 - In an email conversation on August 10, 2014, Bob McElrath discussed a hardware problem that can cause synchronization in the blockchain to fail. Although mentioned as a separate issue, he advised considering it. Another email from mbde at bitwatch.co raised concerns about a high number of orphaned blocks during synchronization and questioned if this could be due to malicious parties generating low difficulty block chains not part of the main chain. Orphaned blocks are common during synchronization when the blocks are further ahead in the chain than the user's current synchronization progress. A solution called headers-first synchronization was proposed, which verifies the headers first and then downloads blocks from multiple peers in parallel without order consideration. However, this solution is not yet production-ready.The email thread revolved around a synchronization issue faced by the user while running a new node. The user reported observing 38,447 orphaned blocks, accounting for approximately 19.5% of their progress at a height of 197,324 blocks. They expressed concerns about the high number and questioned the possibility of malicious parties creating non-main chain block chains with low difficulty to slow down the sync process. Detailed information regarding the build and version used was provided, along with a compressed debug.log file for further analysis. Jeff Garzik, a Bitcoin core developer, responded to the thread and mentioned ongoing work on the "headers first synchronization" category. Until completion, he suggested downloading bootstrap.dat via torrent.To address the synchronization issue, Bob McElrath explained that Bitcoin is sensitive to hardware problems such as single bit flips in memory or computation. He recommended running a Python script attached to the email to check for sha256 mismatches. The script repeatedly runs sha256 on random data and displays a message if a mismatch is found. Under-clocking the CPU and RAM was suggested as a potential solution for hardware-related issues. The email also included links to the build and version information, as well as the compressed debug.log file and Python script mentioned earlier.In summary, the email thread discussed a synchronization issue faced by the user while running a new node. The user observed a high number of orphaned blocks, expressed concerns about possible malicious activity, and provided build and version details along with a compressed debug.log file. Suggestions were made to address hardware-related issues and a solution called headers-first synchronization was proposed but not yet ready for production. Jeff Garzik recommended downloading bootstrap.dat via torrent until the synchronization issue is resolved. 2014-08-10T18:07:54+00:00 + In an email conversation on August 10, 2014, Bob McElrath discussed a hardware problem that can cause synchronization in the blockchain to fail. Although mentioned as a separate issue, he advised considering it. Another email from mbde at bitwatch.co raised concerns about a high number of orphaned blocks during synchronization and questioned if this could be due to malicious parties generating low difficulty block chains not part of the main chain. Orphaned blocks are common during synchronization when the blocks are further ahead in the chain than the user's current synchronization progress. A solution called headers-first synchronization was proposed, which verifies the headers first and then downloads blocks from multiple peers in parallel without order consideration. However, this solution is not yet production-ready.The email thread revolved around a synchronization issue faced by the user while running a new node. The user reported observing 38,447 orphaned blocks, accounting for approximately 19.5% of their progress at a height of 197,324 blocks. They expressed concerns about the high number and questioned the possibility of malicious parties creating non-main chain block chains with low difficulty to slow down the sync process. Detailed information regarding the build and version used was provided, along with a compressed debug.log file for further analysis. Jeff Garzik, a Bitcoin core developer, responded to the thread and mentioned ongoing work on the "headers first synchronization" category. Until completion, he suggested downloading bootstrap.dat via torrent.To address the synchronization issue, Bob McElrath explained that Bitcoin is sensitive to hardware problems such as single bit flips in memory or computation. He recommended running a Python script attached to the email to check for sha256 mismatches. The script repeatedly runs sha256 on random data and displays a message if a mismatch is found. Under-clocking the CPU and RAM was suggested as a potential solution for hardware-related issues. The email also included links to the build and version information, as well as the compressed debug.log file and Python script mentioned earlier.In summary, the email thread discussed a synchronization issue faced by the user while running a new node. The user observed a high number of orphaned blocks, expressed concerns about possible malicious activity, and provided build and version details along with a compressed debug.log file. Suggestions were made to address hardware-related issues and a solution called headers-first synchronization was proposed but not yet ready for production. Jeff Garzik recommended downloading bootstrap.dat via torrent until the synchronization issue is resolved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_Tree-chains-preliminary-summary.xml b/static/bitcoin-dev/Aug_2014/combined_Tree-chains-preliminary-summary.xml index e53dfcd9d6..3c8ab44611 100644 --- a/static/bitcoin-dev/Aug_2014/combined_Tree-chains-preliminary-summary.xml +++ b/static/bitcoin-dev/Aug_2014/combined_Tree-chains-preliminary-summary.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Tree-chains preliminary summary - 2023-08-01T08:01:59.097124+00:00 + 2025-10-11T22:00:06.519675+00:00 + python-feedgen Gregory Sanders 2014-08-03 17:23:07+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Tree-chains preliminary summary - 2023-08-01T08:01:59.097124+00:00 + 2025-10-11T22:00:06.519849+00:00 - In the Bitcoin community, discussions are taking place regarding the need to maintain a friendly and professional environment on the mailing list. Some members suggest implementing a moderation policy or negative reinforcement to discourage hostile behavior and promote collaboration and constructive discussions.One topic of conversation is scalability in the Bitcoin network. Peter Todd argues that Bitcoin doesn't scale effectively due to the bandwidth required to update the UTXO set, leading to scaling issues. On the other hand, Gavin Andresen disagrees and refers to Satoshi's original thoughts on scaling, envisioning a large number of mining nodes and lightweight SPV users. However, Todd points out that the low number of mining pools is due to miners finding it unfeasible to mine on their own. He proposes tree chains as a solution to decentralization and scalability.Merged mining is also discussed, with some expressing concerns about draining the pegging pool and potential attacks. However, others argue that merged mining can indirectly solve scalability problems. Additionally, there is a conversation about reducing dependence on miner validation through the use of ZK-SNARKS.Overall, these conversations highlight different perspectives within the Bitcoin community on topics such as scalability, decentralization, and the importance of maintaining a friendly and professional environment for technical discussions. There are ongoing debates and proposed solutions to address these issues, but further research and testing will be necessary to ensure the security and integrity of the network. 2014-08-03T17:23:07+00:00 + In the Bitcoin community, discussions are taking place regarding the need to maintain a friendly and professional environment on the mailing list. Some members suggest implementing a moderation policy or negative reinforcement to discourage hostile behavior and promote collaboration and constructive discussions.One topic of conversation is scalability in the Bitcoin network. Peter Todd argues that Bitcoin doesn't scale effectively due to the bandwidth required to update the UTXO set, leading to scaling issues. On the other hand, Gavin Andresen disagrees and refers to Satoshi's original thoughts on scaling, envisioning a large number of mining nodes and lightweight SPV users. However, Todd points out that the low number of mining pools is due to miners finding it unfeasible to mine on their own. He proposes tree chains as a solution to decentralization and scalability.Merged mining is also discussed, with some expressing concerns about draining the pegging pool and potential attacks. However, others argue that merged mining can indirectly solve scalability problems. Additionally, there is a conversation about reducing dependence on miner validation through the use of ZK-SNARKS.Overall, these conversations highlight different perspectives within the Bitcoin community on topics such as scalability, decentralization, and the importance of maintaining a friendly and professional environment for technical discussions. There are ongoing debates and proposed solutions to address these issues, but further research and testing will be necessary to ensure the security and integrity of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_What-is-the-danger-if-bitcoind-startted-with-flushwallet-false-.xml b/static/bitcoin-dev/Aug_2014/combined_What-is-the-danger-if-bitcoind-startted-with-flushwallet-false-.xml index 438142e6da..d91f99f3ef 100644 --- a/static/bitcoin-dev/Aug_2014/combined_What-is-the-danger-if-bitcoind-startted-with-flushwallet-false-.xml +++ b/static/bitcoin-dev/Aug_2014/combined_What-is-the-danger-if-bitcoind-startted-with-flushwallet-false-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - What is the danger if bitcoind startted with -flushwallet=false ? - 2023-08-01T10:13:47.751301+00:00 + 2025-10-11T22:00:08.643757+00:00 + python-feedgen Wladimir 2014-08-13 20:29:28+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - What is the danger if bitcoind startted with -flushwallet=false ? - 2023-08-01T10:13:47.751301+00:00 + 2025-10-11T22:00:08.643910+00:00 - In August 2014, a user named 潘庆庆 reached out to the Bitcoind community via email, questioning why the '-flushwallet' option is set to true by default. They had disabled it and noticed a significant reduction in IO, but encountered a problem when all their coins were lost in testnet after a crash. Wladimir, a member of the community, explained that disabling flushwallet means the wallet is not periodically flushed, which increases the likelihood of the wallet database being inconsistent if the process abruptly stops due to a crash or unexpected power outage. This inconsistency can lead to failure during the processing of log files, requiring manual recovery. Given the critical nature of the wallet, it is advised not to disable this option.A user named Qing Qing Pan from okcoin.com shared their experience with reducing the IO of bitcoind by using the "-flushwallet=false" option. They observed a significant reduction in IO after enabling it. However, they raised concerns about why the flushwallet option is true by default and whether there are any risks associated with closing the flush wallet thread. Pan also mentioned losing all their coins in testnet after a crash with the "-flushwallet=false" setting, prompting them to question if this was due to the absence of a flush wallet thread. These inquiries shed light on the default settings of the flushwallet option and its potential impact on the security of Bitcoin transactions. 2014-08-13T20:29:28+00:00 + In August 2014, a user named 潘庆庆 reached out to the Bitcoind community via email, questioning why the '-flushwallet' option is set to true by default. They had disabled it and noticed a significant reduction in IO, but encountered a problem when all their coins were lost in testnet after a crash. Wladimir, a member of the community, explained that disabling flushwallet means the wallet is not periodically flushed, which increases the likelihood of the wallet database being inconsistent if the process abruptly stops due to a crash or unexpected power outage. This inconsistency can lead to failure during the processing of log files, requiring manual recovery. Given the critical nature of the wallet, it is advised not to disable this option.A user named Qing Qing Pan from okcoin.com shared their experience with reducing the IO of bitcoind by using the "-flushwallet=false" option. They observed a significant reduction in IO after enabling it. However, they raised concerns about why the flushwallet option is true by default and whether there are any risks associated with closing the flush wallet thread. Pan also mentioned losing all their coins in testnet after a crash with the "-flushwallet=false" setting, prompting them to question if this was due to the absence of a flush wallet thread. These inquiries shed light on the default settings of the flushwallet option and its potential impact on the security of Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_deterministic-transaction-expiration.xml b/static/bitcoin-dev/Aug_2014/combined_deterministic-transaction-expiration.xml index 4af51874be..0b01846d0c 100644 --- a/static/bitcoin-dev/Aug_2014/combined_deterministic-transaction-expiration.xml +++ b/static/bitcoin-dev/Aug_2014/combined_deterministic-transaction-expiration.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - deterministic transaction expiration - 2023-08-01T10:10:05.905319+00:00 + 2025-10-11T22:00:12.888929+00:00 + python-feedgen Kaz Wesley 2014-08-08 18:42:35+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - deterministic transaction expiration - 2023-08-01T10:10:05.905319+00:00 + 2025-10-11T22:00:12.889136+00:00 - During a discussion on the Bitcoin-development mailing list in 2014, several proposals were made to address various issues related to transaction expiration and the use of nLockTime. One suggestion was to add a new IsStandard rule that rejects transactions with an nLockTime more than N blocks behind the current tip. However, it was pointed out that transaction creation time and transaction publish-to-outside-world time are not always the same, so this rule may not be effective in all cases.Another proposal involved setting nLockTime to the current height by default in newly created transactions. This would discourage fee-sniping and help in case of reorg. There was also discussion about implementing a janitor mechanism to purge mempool of transactions more than N blocks behind the current height.In a separate email exchange, there was a debate about whether the transmission of merkle data in transactions is necessary or if it can be derived from the transaction data itself. One participant argued that validators need to know certain information, such as expiry, which is hidden behind the merkle root in the transaction. They questioned how validators could make decisions without this information.The developers also discussed the possibility of creating a new field or parallel transaction format to deal with pre-consensus mempool behavior without requiring a fork or protocol revision. Various ideas were proposed, including creating a "network TX" with digitally signed information that is discarded before reaching miners, and using a merkle radix tree to commit fields in an extensible and provable way. The goal was to avoid changing the existing transaction format in a hard-fork, which was seen as disruptive.There were also discussions about the potential impact of adding an nExpiry field to the transaction format. Some participants argued that it should be included with the transaction as part of the network and on-disk data structures for proper validation, while others suggested packaging it in some sort of envelope container. The efficiency and compatibility of different approaches were debated.Overall, the discussions focused on finding solutions to improve transaction expiration and mempool behavior without causing disruptions or breaking existing functionality. Different ideas and perspectives were presented, highlighting the complexity of implementing changes in the Bitcoin network.The lack of transaction lifetime management in the network's mempools is hindering some mempool exchange. To address this issue, a proposal has been made to add finite and predictable lifespans to transactions in mempools using nLockTime and a new standardness rule. This proposal can be implemented in stages and would not necessarily require a soft fork, avoiding problems with reorgs.The first stage of the proposal involves setting nLockTime to the current height by default in newly created transactions. Once users have upgraded to clients that set nLockTime, transactions without nLockTime will be discouraged, and a slightly higher fee may be required for relay. Relay of transactions without an nLockTime will then be rate-limited, which alone may achieve discouragement.In the next stage, a new IsStandard rule will be added, rejecting transactions with an nLockTime more than N blocks behind the current tip. This means that transactions will stop being relayed and drop out of mempools a fixed number of blocks from their creation. Once that window has passed, the sender's wallet could begin to expect that the transaction will not be confirmed.Despite concerns that someone may circumvent this IsStandard() rule by submitting "expired" transactions directly to miners with suitable policies, a user who needs to get their original "expired" transaction confirmed could still do so by submitting it directly to a miner with suitable policies.Overall, the proposal aims to add transaction lifetime management to the network's mempools to improve mempool exchange. By implementing stages such as setting nLockTime by default, discouraging transactions without nLockTime, rate-limiting relay of such transactions, and adding an IsStandard rule, the proposed solution provides a way to ensure finite and predictable lifespans for transactions. 2014-08-08T18:42:35+00:00 + During a discussion on the Bitcoin-development mailing list in 2014, several proposals were made to address various issues related to transaction expiration and the use of nLockTime. One suggestion was to add a new IsStandard rule that rejects transactions with an nLockTime more than N blocks behind the current tip. However, it was pointed out that transaction creation time and transaction publish-to-outside-world time are not always the same, so this rule may not be effective in all cases.Another proposal involved setting nLockTime to the current height by default in newly created transactions. This would discourage fee-sniping and help in case of reorg. There was also discussion about implementing a janitor mechanism to purge mempool of transactions more than N blocks behind the current height.In a separate email exchange, there was a debate about whether the transmission of merkle data in transactions is necessary or if it can be derived from the transaction data itself. One participant argued that validators need to know certain information, such as expiry, which is hidden behind the merkle root in the transaction. They questioned how validators could make decisions without this information.The developers also discussed the possibility of creating a new field or parallel transaction format to deal with pre-consensus mempool behavior without requiring a fork or protocol revision. Various ideas were proposed, including creating a "network TX" with digitally signed information that is discarded before reaching miners, and using a merkle radix tree to commit fields in an extensible and provable way. The goal was to avoid changing the existing transaction format in a hard-fork, which was seen as disruptive.There were also discussions about the potential impact of adding an nExpiry field to the transaction format. Some participants argued that it should be included with the transaction as part of the network and on-disk data structures for proper validation, while others suggested packaging it in some sort of envelope container. The efficiency and compatibility of different approaches were debated.Overall, the discussions focused on finding solutions to improve transaction expiration and mempool behavior without causing disruptions or breaking existing functionality. Different ideas and perspectives were presented, highlighting the complexity of implementing changes in the Bitcoin network.The lack of transaction lifetime management in the network's mempools is hindering some mempool exchange. To address this issue, a proposal has been made to add finite and predictable lifespans to transactions in mempools using nLockTime and a new standardness rule. This proposal can be implemented in stages and would not necessarily require a soft fork, avoiding problems with reorgs.The first stage of the proposal involves setting nLockTime to the current height by default in newly created transactions. Once users have upgraded to clients that set nLockTime, transactions without nLockTime will be discouraged, and a slightly higher fee may be required for relay. Relay of transactions without an nLockTime will then be rate-limited, which alone may achieve discouragement.In the next stage, a new IsStandard rule will be added, rejecting transactions with an nLockTime more than N blocks behind the current tip. This means that transactions will stop being relayed and drop out of mempools a fixed number of blocks from their creation. Once that window has passed, the sender's wallet could begin to expect that the transaction will not be confirmed.Despite concerns that someone may circumvent this IsStandard() rule by submitting "expired" transactions directly to miners with suitable policies, a user who needs to get their original "expired" transaction confirmed could still do so by submitting it directly to a miner with suitable policies.Overall, the proposal aims to add transaction lifetime management to the network's mempools to improve mempool exchange. By implementing stages such as setting nLockTime by default, discouraging transactions without nLockTime, rate-limiting relay of such transactions, and adding an IsStandard rule, the proposed solution provides a way to ensure finite and predictable lifespans for transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2014/combined_standardize-on-bitcoin-signed-ecies-.xml b/static/bitcoin-dev/Aug_2014/combined_standardize-on-bitcoin-signed-ecies-.xml index 37b9ee4d58..f74f6aab28 100644 --- a/static/bitcoin-dev/Aug_2014/combined_standardize-on-bitcoin-signed-ecies-.xml +++ b/static/bitcoin-dev/Aug_2014/combined_standardize-on-bitcoin-signed-ecies-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - standardize on bitcoin signed ecies ? - 2023-08-01T10:18:06.207665+00:00 + 2025-10-11T22:00:17.145286+00:00 + python-feedgen Gregory Maxwell 2014-08-27 01:08:02+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - standardize on bitcoin signed ecies ? - 2023-08-01T10:18:06.207665+00:00 + 2025-10-11T22:00:17.145465+00:00 - In 2014, a user named Mem Wallet proposed a standardized PGP-style message for Bitcoin transactions in an email thread. The proposal aimed to allow users to send signed encrypted messages using only public and private Bitcoin keys. However, using the same keys for signing and encryption is generally considered bad practice due to security concerns. Implementing encryption in Bitcoin software has proven to be difficult in the past, with previous attempts being flawed and insecure.The author of the email expressed doubts about the proposal receiving adequate review and highlighted the significant security concerns and implementation challenges that need to be addressed. Despite this, the Bitcoin community continues to discuss the potential benefits of creating a standardized PGP-style message protocol.If implemented, the protocol would enable users to encrypt messages with their private key and decrypt them with their public key, ensuring that only the intended recipient can read the message. This would add an extra layer of security to Bitcoin transactions, as users could include important information such as payment instructions or addresses in an encrypted message.Supporters of the proposal argue that it could improve the privacy and security of Bitcoin transactions. However, others remain skeptical of its usefulness. Nevertheless, the proposal showcases the ongoing efforts within the Bitcoin community to enhance the functionality and security of the network. 2014-08-27T01:08:02+00:00 + In 2014, a user named Mem Wallet proposed a standardized PGP-style message for Bitcoin transactions in an email thread. The proposal aimed to allow users to send signed encrypted messages using only public and private Bitcoin keys. However, using the same keys for signing and encryption is generally considered bad practice due to security concerns. Implementing encryption in Bitcoin software has proven to be difficult in the past, with previous attempts being flawed and insecure.The author of the email expressed doubts about the proposal receiving adequate review and highlighted the significant security concerns and implementation challenges that need to be addressed. Despite this, the Bitcoin community continues to discuss the potential benefits of creating a standardized PGP-style message protocol.If implemented, the protocol would enable users to encrypt messages with their private key and decrypt them with their public key, ensuring that only the intended recipient can read the message. This would add an extra layer of security to Bitcoin transactions, as users could include important information such as payment instructions or addresses in an encrypted message.Supporters of the proposal argue that it could improve the privacy and security of Bitcoin transactions. However, others remain skeptical of its usefulness. Nevertheless, the proposal showcases the ongoing efforts within the Bitcoin community to enhance the functionality and security of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_-A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit-new-research-paper-suggests.xml b/static/bitcoin-dev/Aug_2015/combined_-A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit-new-research-paper-suggests.xml index 264e727c88..4a2306d798 100644 --- a/static/bitcoin-dev/Aug_2015/combined_-A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit-new-research-paper-suggests.xml +++ b/static/bitcoin-dev/Aug_2015/combined_-A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit-new-research-paper-suggests.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests - 2023-08-01T14:55:25.049188+00:00 + Combined summary - "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests + 2025-10-11T22:05:57.287590+00:00 + python-feedgen Daniele Pinna 2015-08-30 21:02:48+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 - Combined summary - "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests - 2023-08-01T14:55:25.049188+00:00 + Combined summary - "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests + 2025-10-11T22:05:57.287789+00:00 - The email exchanges and discussions on the bitcoin-dev mailing list revolve around various aspects of Bitcoin mining, block size, fee markets, and security. One important result is that an individual miner's profit per block is maximized at a finite block size Q* if Shannon Entropy is communicated during the block solution announcement. This result shows how a minimum fee density exists, preventing miners from creating spam blocks for free.However, concerns are raised about the lower bound of expected revenue being surpassed, potentially leading to unhealthy fee markets. It is also noted that larger hash rates provide a profitability advantage but are outside the scope of the previous point. Gmaxwell's theorem challenges the work by suggesting that centralization pressures will always be present due to the increasing marginal profit curve of miner hashrate.Further discussions explore the modeling of propagation characteristics, orphan rate in mining, and the impact of block size on fees and spam costs. The paper by Peter R titled "A Transaction Fee Market Exists Without a Block Size Limit" examines the cost of producing large spam blocks and demonstrates that a block size limit is not necessary to ensure a functioning fee market. However, questions are raised about mining cartels and the size of the UTXO set.Ideas are proposed for a futures market in block size and a prediction market to determine the new block size based on the current BLK/BTC price. The complexity and security issues of such markets are debated, and the involvement of Bitcoin.org in running the exchange is suggested. Various participants express their opinions on these ideas, discussing the necessity of decentralization, security concerns, and potential improvements or complications introduced by these markets.The Flexcap idea is also mentioned as an alternative to giving miners complete control over block sizes, aiming to achieve similar effects without negative side-effects like cartelization and selfish mining. Different levels of security and consensus rules are emphasized when considering proposals.The discussion in August 2015 focuses on the existence of a fee market for Bitcoin and the possibility of improving the matching mechanism between supply and demand. The concept of a prediction market involving informed participants is proposed, with the technical implementation left for further consideration.The research paper by Peter R provides insights into the rational selection of transactions by miners to maximize their profit and introduces block space supply and mempool demand curves. It argues that an unhealthy fee market cannot exist due to the need for fast information communication. The paper also raises questions related to mining cartels and the UTXO set size.Throughout the discussions, caution is advised when conducting research in the politically charged and controversial field of block size limits. The importance of expertise and knowledge beyond Bitcoin is emphasized, and suggestions are made to avoid drama-filled posts on public platforms.Overall, these email exchanges and discussions shed light on important aspects of Bitcoin mining, block size, fee markets, and security, highlighting the complexities and challenges involved in these areas.In a recent discussion on the bitcoin-dev mailing list, Gavin Andresen and Dave Hudson debated the possibility of block makers orphaning their own blocks. Hudson argued that a block maker does not orphan its own blocks, while Andresen disagreed, stating that two hashing units could find solutions in the time it takes to communicate that solution to the rest of the hashing units. This led to a discussion about the advantages of putting hashing power physically close together, with Andresen suggesting it as a topic for another paper.However, this discussion took a contentious turn when someone accused Andresen of deliberately lying and toxic conduct, urging him to leave the development mailing list discussion. The post highlighted the importance of seeking expert opinions before publishing to avoid controversy and mentioned that immature behavior by developers can be detrimental to the development mailing list discussions.Another topic discussed on the bitcoin-dev mailing list was a research paper shared by Peter R titled "A Transaction Fee Market Exists Without a Block Size Limit." The paper argues that a block size limit is not necessary for a functioning fee market due to the orphaning cost. It presents useful charts, including the cost to produce large spam blocks. However, the paper raises questions about mining cartels and the size of the UTXO set. It introduces the block space supply curve and the mempool demand curve, which represent the cost for a miner to supply block space and the fees offered by transactions in the mempool, respectively. The paper explains how these curves relate to classical economics' supply and demand curves and proves that producing the quantity of block space indicated by their intersection point maximizes the miner's profit. It also shows that an unhealthy fee market requiring communication at an arbitrarily fast rate cannot exist. The paper considers the conditions under which a rational miner would produce big, small, or empty blocks and estimates the cost of a spam attack.Overall, these discussions on the bitcoin-dev mailing list highlight the importance of seeking expert opinions, avoiding toxic conduct, and considering various factors in the development of Bitcoin, such as orphaning blocks and the need for a block size limit to ensure a functioning fee market. 2015-08-30T21:02:48+00:00 + The email exchanges and discussions on the bitcoin-dev mailing list revolve around various aspects of Bitcoin mining, block size, fee markets, and security. One important result is that an individual miner's profit per block is maximized at a finite block size Q* if Shannon Entropy is communicated during the block solution announcement. This result shows how a minimum fee density exists, preventing miners from creating spam blocks for free.However, concerns are raised about the lower bound of expected revenue being surpassed, potentially leading to unhealthy fee markets. It is also noted that larger hash rates provide a profitability advantage but are outside the scope of the previous point. Gmaxwell's theorem challenges the work by suggesting that centralization pressures will always be present due to the increasing marginal profit curve of miner hashrate.Further discussions explore the modeling of propagation characteristics, orphan rate in mining, and the impact of block size on fees and spam costs. The paper by Peter R titled "A Transaction Fee Market Exists Without a Block Size Limit" examines the cost of producing large spam blocks and demonstrates that a block size limit is not necessary to ensure a functioning fee market. However, questions are raised about mining cartels and the size of the UTXO set.Ideas are proposed for a futures market in block size and a prediction market to determine the new block size based on the current BLK/BTC price. The complexity and security issues of such markets are debated, and the involvement of Bitcoin.org in running the exchange is suggested. Various participants express their opinions on these ideas, discussing the necessity of decentralization, security concerns, and potential improvements or complications introduced by these markets.The Flexcap idea is also mentioned as an alternative to giving miners complete control over block sizes, aiming to achieve similar effects without negative side-effects like cartelization and selfish mining. Different levels of security and consensus rules are emphasized when considering proposals.The discussion in August 2015 focuses on the existence of a fee market for Bitcoin and the possibility of improving the matching mechanism between supply and demand. The concept of a prediction market involving informed participants is proposed, with the technical implementation left for further consideration.The research paper by Peter R provides insights into the rational selection of transactions by miners to maximize their profit and introduces block space supply and mempool demand curves. It argues that an unhealthy fee market cannot exist due to the need for fast information communication. The paper also raises questions related to mining cartels and the UTXO set size.Throughout the discussions, caution is advised when conducting research in the politically charged and controversial field of block size limits. The importance of expertise and knowledge beyond Bitcoin is emphasized, and suggestions are made to avoid drama-filled posts on public platforms.Overall, these email exchanges and discussions shed light on important aspects of Bitcoin mining, block size, fee markets, and security, highlighting the complexities and challenges involved in these areas.In a recent discussion on the bitcoin-dev mailing list, Gavin Andresen and Dave Hudson debated the possibility of block makers orphaning their own blocks. Hudson argued that a block maker does not orphan its own blocks, while Andresen disagreed, stating that two hashing units could find solutions in the time it takes to communicate that solution to the rest of the hashing units. This led to a discussion about the advantages of putting hashing power physically close together, with Andresen suggesting it as a topic for another paper.However, this discussion took a contentious turn when someone accused Andresen of deliberately lying and toxic conduct, urging him to leave the development mailing list discussion. The post highlighted the importance of seeking expert opinions before publishing to avoid controversy and mentioned that immature behavior by developers can be detrimental to the development mailing list discussions.Another topic discussed on the bitcoin-dev mailing list was a research paper shared by Peter R titled "A Transaction Fee Market Exists Without a Block Size Limit." The paper argues that a block size limit is not necessary for a functioning fee market due to the orphaning cost. It presents useful charts, including the cost to produce large spam blocks. However, the paper raises questions about mining cartels and the size of the UTXO set. It introduces the block space supply curve and the mempool demand curve, which represent the cost for a miner to supply block space and the fees offered by transactions in the mempool, respectively. The paper explains how these curves relate to classical economics' supply and demand curves and proves that producing the quantity of block space indicated by their intersection point maximizes the miner's profit. It also shows that an unhealthy fee market requiring communication at an arbitrarily fast rate cannot exist. The paper considers the conditions under which a rational miner would produce big, small, or empty blocks and estimates the cost of a spam attack.Overall, these discussions on the bitcoin-dev mailing list highlight the importance of seeking expert opinions, avoiding toxic conduct, and considering various factors in the development of Bitcoin, such as orphaning blocks and the need for a block size limit to ensure a functioning fee market. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime-Btc-Drak-.xml b/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime-Btc-Drak-.xml index 9256764b90..ac3483fb24 100644 --- a/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime-Btc-Drak-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime-Btc-Drak-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime (Btc Drak) - 2023-08-01T15:13:39.868202+00:00 + 2025-10-11T22:07:09.558428+00:00 + python-feedgen Matt Corallo 2015-08-13 16:36:07+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime (Btc Drak) - 2023-08-01T15:13:39.868202+00:00 + 2025-10-11T22:07:09.558554+00:00 - In an email thread from August 13, 2015, Nicolas Dorier expressed his desire to have a proposal combining BIP68, CLTV, and CSV. He believed that if BIP68 was included in the next fork, implementing CSV would be an easy decision. Dorier also inquired about any competing RCLTV proposals that did not rely on BIP68 for information. In response, Matt explained that all such proposals had been abandoned because the current proposal appeared to be a better idea. However, he encouraged anyone to revive or create a new proposal.Dorier's suggestion was to implement CSV (CHECKSEQUENCEVERIFY) alongside CLTV (CHECKLOCKTIMEVERIFY) and BIP68 (relative lock-time). He believed that if BIP68 was included in the next fork, implementing CSV would be straightforward. However, there was uncertainty about whether there were any competing proposals for RCLTV (Relative CHECKLOCKTIMEVERIFY) that did not depend on BIP68 for information. The availability of information on this topic seemed limited. 2015-08-13T16:36:07+00:00 + In an email thread from August 13, 2015, Nicolas Dorier expressed his desire to have a proposal combining BIP68, CLTV, and CSV. He believed that if BIP68 was included in the next fork, implementing CSV would be an easy decision. Dorier also inquired about any competing RCLTV proposals that did not rely on BIP68 for information. In response, Matt explained that all such proposals had been abandoned because the current proposal appeared to be a better idea. However, he encouraged anyone to revive or create a new proposal.Dorier's suggestion was to implement CSV (CHECKSEQUENCEVERIFY) alongside CLTV (CHECKLOCKTIMEVERIFY) and BIP68 (relative lock-time). He believed that if BIP68 was included in the next fork, implementing CSV would be straightforward. However, there was uncertainty about whether there were any competing proposals for RCLTV (Relative CHECKLOCKTIMEVERIFY) that did not depend on BIP68 for information. The availability of information on this topic seemed limited. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime.xml b/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime.xml index 0d1aac36a8..fd68d24f41 100644 --- a/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime.xml +++ b/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime - 2023-08-01T15:11:20.666401+00:00 + 2025-10-11T22:05:29.671006+00:00 + python-feedgen Rusty Russell 2015-09-18 01:21:19+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime - 2023-08-01T15:11:20.667398+00:00 + 2025-10-11T22:05:29.671214+00:00 - In a discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed changing the rules regarding sequence numbers in Bitcoin transactions. He created two new repositories, one of which inverts the sequence number and interprets it as a fixed-point number, allowing for up to five-year relative lock times using blocks or up to approximately two-year relative lock times using seconds. The other repository inverts the sequence number with nSequence=1 meaning one block relative lock-height and nSequence=LOCKTIME_THRESHOLD meaning one second relative lock-height. Friedenbach also discussed the maximum time required for relative lock-times, suggesting a maximum of one year. He questioned whether there are any use cases that would require more than a year of lock time.Rusty Russell agreed with Friedenbach's suggestion and emphasized simplicity. He mentioned that reserving the remaining half of the number space for future purposes and leaving the top two bits for those who are paranoid would be a good approach.Eric Lombrozo commented that he would prefer replacing the entire nSequence field with an explicit relative lock-time with clear semantics.Gregory Maxwell suggested representing one block with more than one increment to leave additional space for future signaling or allow higher resolution numbers for a share chain commitment.In another discussion, Rusty Russell proposed an IsStandard() rule that would ensure nSequence is either 0xFFFFFFFF or 0 to avoid issues with soft forks. However, it was pointed out that this rule is not necessary since BIP68 is not active for version 1 transactions and no existing wallets would be affected.There was also a discussion on transaction finality and the proposal code named BIP112. It was suggested to use the "sequence" field instead of the "version" field, as it is associated with transaction finality. It was also mentioned that chaining transactions and extending the relative locktime could be a way to delay confirmation in cases where the clock start is uncertain.Overall, the discussions revolved around improving sequence numbers and relative lock-times in Bitcoin transactions, considering different use cases and future implications.In a discussion on the bitcoin-dev mailing list, Gregory Maxwell proposed the idea of representing one block with more than one increment, which would provide additional space for future signaling or higher resolution numbers for a sharechain commitment. However, there had been no prior discussion of this idea. Another participant in the thread suggested using 600 increments to make it more similar to timestamps. The discussion also touched on the inversion of nSequence and preserving existing semantics in Bitcoin transactions.Tom Harding posted a message regarding an idea for preserving existing semantics in a Bitcoin transaction, but another member requested clarification as they couldn't follow the logic. Mark Friedenbach expressed his indifference towards the issue of bit inversion and explained that he implemented it to preserve existing semantics, even if they were not commonly used. Jorge Timón raised an issue with this implementation on GitHub, and a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core was announced.Joseph Poon and Mark Friedenbach discussed the inversion of nSequence in mempool transaction selection via email. Poon mentioned his indifference to the issue but expressed concern about technical debt and noted that transactions with shorter relative locks have higher priority. The group ultimately agreed to remove the inversion for ease of use and mental calculation.The bitcoin-dev community engaged in a discussion regarding a proposed change to the Bitcoin Improvement Proposals. The proposal involved changing how transactions are selected in the mempool to prioritize those with shorter relative locks. Some developers were indifferent to the issue, while others expressed concern over technical debt. Joseph Poon suggested noting the information for those who wish to write code for mempool transaction selection, regardless of their opinion.Btc Drak provided an update on the bitcoin-dev mailing list regarding a new pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core. The pull request can be found on Github, labeled as pull request number 179. Another pull request for a BIP was also submitted and can be found on Github, labeled as pull request number 6564.The writer expressed their displeasure towards the inversion of nSequence to preserve existing semantics. They argued that these semantics were not enforceable by consensus and suggested using nMaturity instead. The writer emphasized the importance of moving forward without technical debt and believed that clearer documentation could be achieved through this decision.The context discussed the assumed malleability-fix CHECKSIG2 version of lightning, which allows for outsourcing monitoring and response to bad behavior. It was noted that this requires users' wallets to be online. The proposal also mentioned the need for mitigations against a systemic supervillain attack but did not include provisions for it. The scenario of a hub turning evil and cheating its users out of their bonds was discussed, along with potential ways to protect against such behavior. However, automating the process and determining reasonable metrics proved challenging.Joseph Poon suggested that Lightning needs mitigations for a systemic supervillain attack, while Mark Friedenbach didn't think the risk 2015-09-18T01:21:19+00:00 + In a discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed changing the rules regarding sequence numbers in Bitcoin transactions. He created two new repositories, one of which inverts the sequence number and interprets it as a fixed-point number, allowing for up to five-year relative lock times using blocks or up to approximately two-year relative lock times using seconds. The other repository inverts the sequence number with nSequence=1 meaning one block relative lock-height and nSequence=LOCKTIME_THRESHOLD meaning one second relative lock-height. Friedenbach also discussed the maximum time required for relative lock-times, suggesting a maximum of one year. He questioned whether there are any use cases that would require more than a year of lock time.Rusty Russell agreed with Friedenbach's suggestion and emphasized simplicity. He mentioned that reserving the remaining half of the number space for future purposes and leaving the top two bits for those who are paranoid would be a good approach.Eric Lombrozo commented that he would prefer replacing the entire nSequence field with an explicit relative lock-time with clear semantics.Gregory Maxwell suggested representing one block with more than one increment to leave additional space for future signaling or allow higher resolution numbers for a share chain commitment.In another discussion, Rusty Russell proposed an IsStandard() rule that would ensure nSequence is either 0xFFFFFFFF or 0 to avoid issues with soft forks. However, it was pointed out that this rule is not necessary since BIP68 is not active for version 1 transactions and no existing wallets would be affected.There was also a discussion on transaction finality and the proposal code named BIP112. It was suggested to use the "sequence" field instead of the "version" field, as it is associated with transaction finality. It was also mentioned that chaining transactions and extending the relative locktime could be a way to delay confirmation in cases where the clock start is uncertain.Overall, the discussions revolved around improving sequence numbers and relative lock-times in Bitcoin transactions, considering different use cases and future implications.In a discussion on the bitcoin-dev mailing list, Gregory Maxwell proposed the idea of representing one block with more than one increment, which would provide additional space for future signaling or higher resolution numbers for a sharechain commitment. However, there had been no prior discussion of this idea. Another participant in the thread suggested using 600 increments to make it more similar to timestamps. The discussion also touched on the inversion of nSequence and preserving existing semantics in Bitcoin transactions.Tom Harding posted a message regarding an idea for preserving existing semantics in a Bitcoin transaction, but another member requested clarification as they couldn't follow the logic. Mark Friedenbach expressed his indifference towards the issue of bit inversion and explained that he implemented it to preserve existing semantics, even if they were not commonly used. Jorge Timón raised an issue with this implementation on GitHub, and a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core was announced.Joseph Poon and Mark Friedenbach discussed the inversion of nSequence in mempool transaction selection via email. Poon mentioned his indifference to the issue but expressed concern about technical debt and noted that transactions with shorter relative locks have higher priority. The group ultimately agreed to remove the inversion for ease of use and mental calculation.The bitcoin-dev community engaged in a discussion regarding a proposed change to the Bitcoin Improvement Proposals. The proposal involved changing how transactions are selected in the mempool to prioritize those with shorter relative locks. Some developers were indifferent to the issue, while others expressed concern over technical debt. Joseph Poon suggested noting the information for those who wish to write code for mempool transaction selection, regardless of their opinion.Btc Drak provided an update on the bitcoin-dev mailing list regarding a new pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core. The pull request can be found on Github, labeled as pull request number 179. Another pull request for a BIP was also submitted and can be found on Github, labeled as pull request number 6564.The writer expressed their displeasure towards the inversion of nSequence to preserve existing semantics. They argued that these semantics were not enforceable by consensus and suggested using nMaturity instead. The writer emphasized the importance of moving forward without technical debt and believed that clearer documentation could be achieved through this decision.The context discussed the assumed malleability-fix CHECKSIG2 version of lightning, which allows for outsourcing monitoring and response to bad behavior. It was noted that this requires users' wallets to be online. The proposal also mentioned the need for mitigations against a systemic supervillain attack but did not include provisions for it. The scenario of a hub turning evil and cheating its users out of their bonds was discussed, along with potential ways to protect against such behavior. However, automating the process and determining reasonable metrics proved challenging.Joseph Poon suggested that Lightning needs mitigations for a systemic supervillain attack, while Mark Friedenbach didn't think the risk - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml b/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml index 0091024b9b..d8fe59f1a3 100644 --- a/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks) - 2023-08-01T13:27:52.323460+00:00 + 2025-10-11T22:06:29.180115+00:00 + python-feedgen Jorge Timón 2015-08-29 21:21:05+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks) - 2023-08-01T13:27:52.323460+00:00 + 2025-10-11T22:06:29.180260+00:00 - A discussion thread on GitHub regarding a draft BIP (Bitcoin Improvement Proposal) has been moved to the mailing list due to GitHub not being specified for high-level discussions in BIP001. The original poster raises concerns about the structure and wording of the proposal, suggesting it be slimmed down and simplified, with some history lessons removed. The author of the proposal requests more specific suggestions before taking action. There is a question about a separate BIP for "code forks," clarified as beyond the scope of this BIP. It is noted that spell checking has not been followed for any BIP. The current label of the proposal is "informational | process" but may change based on appropriateness. The proposal contains code for an uncontroversial hard fork example to set a precedent. However, a proposal for a "patch into core as a module that hard forks can use in the future" requires further clarification.On July 31, 2015, Thomas Kerin via bitcoin-dev expresses the belief that a document should exist prior to assigning a BIP number. While there was an initial document, alterations were made after the BIP number was assigned. The author apologizes for breaking the previous link and provides a new one. The code is also available on Github. A separate mailing list discussion is ongoing regarding activation thresholds related to this BIP. The assumption of the BIP is that miners will upgrade after a defined starting block height, and once a 95% threshold is reached, the hard fork takes effect. After the first block is buried, the check can be replaced by redefining the threshold height instead of the height when miners started voting.Jorge Timón requests a BIP number from Greg Maxwell on the bitcoin-dev mailing list for discussions about deploying uncontroversial hard forks in one place. The proposed timewarp fix could be coded as a soft fork instead of a hard fork, requiring all blocks to be within one day of the median of the previous 11 blocks. Tier Nolan suggests this would protect against the exploit. Another proposal suggests that the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Nolan believes a hard fork is necessary to fix the issue "right," especially for demonstrating a non-controversial hard fork.Discussions revolve around obtaining miner confirmation on uncontroversial hard forks and whether to use nHeight, nMedianTime, or just nTime. A BIP number is requested to concentrate discussions on deploying uncontroversial hard forks in one place. One proposal for a timewarp fix suggests all blocks should be within 1 day of the median of the previous 11 blocks, adding a condition at the other end. Another proposal suggests the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Fixing the issue "right" would likely require a hard fork, particularly for demonstrating a non-controversial hard fork.In an email conversation, Jorge Timón suggests a soft fork solution to the timewarp exploit, proposing that all blocks should be within one day of the median of the previous 11 blocks, with a condition added at the other end. While not a total fix, it would protect against the exploit. A stricter soft fork would require the two blocks in question to have the same timestamp, ensuring the off by 1 and correct value yield the same result. Timón believes a hard fork is necessary to fix the issue "right," especially when demonstrating a non-controversial hard fork.Tier Nolan suggests fixing the "off by 1 bug" through a soft fork in an email thread on June 21, 2015. This suggestion is made in the context of demonstrating how a non-controversial hard fork works. The timewarp fix discussed in the thread could potentially be coded as a soft fork instead of a hard fork. However, it is unclear if there were any other candidates for addressing the issue.There is a discussion about an off by 1 bug and its potential fix through a soft fork. The focus is primarily on demonstrating how a non-controversial hard fork operates, with the bug solution being of lesser importance.The author seeks feedback to create an informational BIP on deploying hard forks. It is specified that the discussion only pertains to hard forks and soft forks in an abstract manner, excluding block size issues. Block size changes are used as examples due to lack of alternatives, but non-blocksize-related examples for the same cases are welcomed. The author encourages suggestions and input on terminology. The full text can be found on the author's Github page at https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org. 2015-08-29T21:21:05+00:00 + A discussion thread on GitHub regarding a draft BIP (Bitcoin Improvement Proposal) has been moved to the mailing list due to GitHub not being specified for high-level discussions in BIP001. The original poster raises concerns about the structure and wording of the proposal, suggesting it be slimmed down and simplified, with some history lessons removed. The author of the proposal requests more specific suggestions before taking action. There is a question about a separate BIP for "code forks," clarified as beyond the scope of this BIP. It is noted that spell checking has not been followed for any BIP. The current label of the proposal is "informational | process" but may change based on appropriateness. The proposal contains code for an uncontroversial hard fork example to set a precedent. However, a proposal for a "patch into core as a module that hard forks can use in the future" requires further clarification.On July 31, 2015, Thomas Kerin via bitcoin-dev expresses the belief that a document should exist prior to assigning a BIP number. While there was an initial document, alterations were made after the BIP number was assigned. The author apologizes for breaking the previous link and provides a new one. The code is also available on Github. A separate mailing list discussion is ongoing regarding activation thresholds related to this BIP. The assumption of the BIP is that miners will upgrade after a defined starting block height, and once a 95% threshold is reached, the hard fork takes effect. After the first block is buried, the check can be replaced by redefining the threshold height instead of the height when miners started voting.Jorge Timón requests a BIP number from Greg Maxwell on the bitcoin-dev mailing list for discussions about deploying uncontroversial hard forks in one place. The proposed timewarp fix could be coded as a soft fork instead of a hard fork, requiring all blocks to be within one day of the median of the previous 11 blocks. Tier Nolan suggests this would protect against the exploit. Another proposal suggests that the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Nolan believes a hard fork is necessary to fix the issue "right," especially for demonstrating a non-controversial hard fork.Discussions revolve around obtaining miner confirmation on uncontroversial hard forks and whether to use nHeight, nMedianTime, or just nTime. A BIP number is requested to concentrate discussions on deploying uncontroversial hard forks in one place. One proposal for a timewarp fix suggests all blocks should be within 1 day of the median of the previous 11 blocks, adding a condition at the other end. Another proposal suggests the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Fixing the issue "right" would likely require a hard fork, particularly for demonstrating a non-controversial hard fork.In an email conversation, Jorge Timón suggests a soft fork solution to the timewarp exploit, proposing that all blocks should be within one day of the median of the previous 11 blocks, with a condition added at the other end. While not a total fix, it would protect against the exploit. A stricter soft fork would require the two blocks in question to have the same timestamp, ensuring the off by 1 and correct value yield the same result. Timón believes a hard fork is necessary to fix the issue "right," especially when demonstrating a non-controversial hard fork.Tier Nolan suggests fixing the "off by 1 bug" through a soft fork in an email thread on June 21, 2015. This suggestion is made in the context of demonstrating how a non-controversial hard fork works. The timewarp fix discussed in the thread could potentially be coded as a soft fork instead of a hard fork. However, it is unclear if there were any other candidates for addressing the issue.There is a discussion about an off by 1 bug and its potential fix through a soft fork. The focus is primarily on demonstrating how a non-controversial hard fork operates, with the bug solution being of lesser importance.The author seeks feedback to create an informational BIP on deploying hard forks. It is specified that the discussion only pertains to hard forks and soft forks in an abstract manner, excluding block size issues. Block size changes are used as examples due to lack of alternatives, but non-blocksize-related examples for the same cases are welcomed. The author encourages suggestions and input on terminology. The full text can be found on the author's Github page at https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_A-compromise-between-BIP101-and-Pieter-s-proposal.xml b/static/bitcoin-dev/Aug_2015/combined_A-compromise-between-BIP101-and-Pieter-s-proposal.xml index b2b023f0a5..2d4b002e27 100644 --- a/static/bitcoin-dev/Aug_2015/combined_A-compromise-between-BIP101-and-Pieter-s-proposal.xml +++ b/static/bitcoin-dev/Aug_2015/combined_A-compromise-between-BIP101-and-Pieter-s-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A compromise between BIP101 and Pieter's proposal - 2023-08-01T14:50:35.700912+00:00 + 2025-10-11T22:07:52.149568+00:00 + python-feedgen Dave Scotese 2015-08-02 22:07:22+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - A compromise between BIP101 and Pieter's proposal - 2023-08-01T14:50:35.700912+00:00 + 2025-10-11T22:07:52.149728+00:00 - The email thread discusses proposed changes to the block size and deployment period for Bitcoin. One party suggests a starting date for the block size 30 days after 75% miner support but not before January 12, 2016. The block size will gradually increase over 16 months until it reaches 8MB on May 11, 2017. Chinese miners agree with this proposal. However, there is disagreement on whether we can currently handle larger blocks. Security concerns related to trusting miners are also discussed. Another member proposes a more gradual approach to the block size increase with a longer grace period. Pieter Wuille raises the question of what would have happened if Bitcoin had started with 8MB blocks. He suggests a compromise between BIP101 and BIP103 with a gradual increase in block size based on technology growth. The text discusses various solutions for internet service and the need for independent full nodes to maintain decentralization. Adam Back expresses concern about the trustworthiness of data-center operators and highlights the importance of understanding decentralization. The argument for decentralization security and the reality of trusting data centers are discussed. The decentralized nature of data centers and hosting providers is highlighted, as well as the difficulty for authorities to conduct widescale attacks on nodes. The email thread also discusses the security reality of hosting anything intended to be secure via decentralization or hosting in general and proposes a compromise between BIP101 and BIP103. The proposal suggests gradual growth in the block size over time and the importance of a fee market and the value of secondary layers.The article discusses the challenges of running a full node for Bitcoin in countries with repressive governments. The author argues that trusting data centers to run verified code without being hacked and responsive to court orders is delusional. Data center operators are bound to follow laws, including NSLs and gag orders, which could compromise the security of Bitcoin. However, one could establish multiple full nodes all over the world, including in offshore VPS, to ensure decentralization and avoid geopolitical risks. The email thread discusses the issue of trust in data centers and their ability to run verified code, avoid being hacked, filter traffic, and respond to court orders without notifying users. The reality of data center security breaches and policy attacks is highlighted with references to Snowden disclosures and the need for awareness of security. A compromise proposal is presented regarding the block size limit increase in Bitcoin, with details on initiation, starting date, and gradual increase in block size over a period of 16 months. The rationale behind each parameter is explained, including SSD price reduction and global bandwidth growth predictions. The author also comments on the need for a fee market but cautions against excessive fee pressure at this time when the block reward is still the main income source for miners. Finally, the author emphasizes the importance of increasing the underlying settlement system's capacity before building secondary layers such as Lightning Network.The email proposes a compromise between Gavin's BIP101 and Pieter's proposal, BIP103. The author suggests initiation through BIP34 style voting with support from 750 out of the last 1000 blocks and using the "hardfork bit" mechanism. The starting date is proposed to be 30 days after 75% miner support but not before 2016-01-12 00:00 UTC. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by 1.414213 by every 2^23 seconds until exactly 8MB is reached on 2017-05-11. After 8MB is reached, the block size will be increased by 6.714% every 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or double every 2.9 years, or +27.67% per year. The final cap is set at 4096MB on 2042-11-17.The author suggests a faster growth in the beginning to normalize the block size and a new optimal size based on current adoption and technology. They also agree that Bitcoin needs a fee market, but the fee pressure must not be too high at this moment as the block reward is still the miner's main income source. The author respects everyone building secondary layers over the blockchain. However, they believe that if the underlying settlement system does not have enough capacity, any secondary layer built on it will fall apart. Finally, the value of secondary layers primarily comes from instant confirmation, not scarcity of block space. 2015-08-02T22:07:22+00:00 + The email thread discusses proposed changes to the block size and deployment period for Bitcoin. One party suggests a starting date for the block size 30 days after 75% miner support but not before January 12, 2016. The block size will gradually increase over 16 months until it reaches 8MB on May 11, 2017. Chinese miners agree with this proposal. However, there is disagreement on whether we can currently handle larger blocks. Security concerns related to trusting miners are also discussed. Another member proposes a more gradual approach to the block size increase with a longer grace period. Pieter Wuille raises the question of what would have happened if Bitcoin had started with 8MB blocks. He suggests a compromise between BIP101 and BIP103 with a gradual increase in block size based on technology growth. The text discusses various solutions for internet service and the need for independent full nodes to maintain decentralization. Adam Back expresses concern about the trustworthiness of data-center operators and highlights the importance of understanding decentralization. The argument for decentralization security and the reality of trusting data centers are discussed. The decentralized nature of data centers and hosting providers is highlighted, as well as the difficulty for authorities to conduct widescale attacks on nodes. The email thread also discusses the security reality of hosting anything intended to be secure via decentralization or hosting in general and proposes a compromise between BIP101 and BIP103. The proposal suggests gradual growth in the block size over time and the importance of a fee market and the value of secondary layers.The article discusses the challenges of running a full node for Bitcoin in countries with repressive governments. The author argues that trusting data centers to run verified code without being hacked and responsive to court orders is delusional. Data center operators are bound to follow laws, including NSLs and gag orders, which could compromise the security of Bitcoin. However, one could establish multiple full nodes all over the world, including in offshore VPS, to ensure decentralization and avoid geopolitical risks. The email thread discusses the issue of trust in data centers and their ability to run verified code, avoid being hacked, filter traffic, and respond to court orders without notifying users. The reality of data center security breaches and policy attacks is highlighted with references to Snowden disclosures and the need for awareness of security. A compromise proposal is presented regarding the block size limit increase in Bitcoin, with details on initiation, starting date, and gradual increase in block size over a period of 16 months. The rationale behind each parameter is explained, including SSD price reduction and global bandwidth growth predictions. The author also comments on the need for a fee market but cautions against excessive fee pressure at this time when the block reward is still the main income source for miners. Finally, the author emphasizes the importance of increasing the underlying settlement system's capacity before building secondary layers such as Lightning Network.The email proposes a compromise between Gavin's BIP101 and Pieter's proposal, BIP103. The author suggests initiation through BIP34 style voting with support from 750 out of the last 1000 blocks and using the "hardfork bit" mechanism. The starting date is proposed to be 30 days after 75% miner support but not before 2016-01-12 00:00 UTC. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by 1.414213 by every 2^23 seconds until exactly 8MB is reached on 2017-05-11. After 8MB is reached, the block size will be increased by 6.714% every 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or double every 2.9 years, or +27.67% per year. The final cap is set at 4096MB on 2042-11-17.The author suggests a faster growth in the beginning to normalize the block size and a new optimal size based on current adoption and technology. They also agree that Bitcoin needs a fee market, but the fee pressure must not be too high at this moment as the block reward is still the miner's main income source. The author respects everyone building secondary layers over the blockchain. However, they believe that if the underlying settlement system does not have enough capacity, any secondary layer built on it will fall apart. Finally, the value of secondary layers primarily comes from instant confirmation, not scarcity of block space. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_A-reason-we-can-all-agree-on-to-increase-block-size.xml b/static/bitcoin-dev/Aug_2015/combined_A-reason-we-can-all-agree-on-to-increase-block-size.xml index 78da95d1ae..9bdbcc993c 100644 --- a/static/bitcoin-dev/Aug_2015/combined_A-reason-we-can-all-agree-on-to-increase-block-size.xml +++ b/static/bitcoin-dev/Aug_2015/combined_A-reason-we-can-all-agree-on-to-increase-block-size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A reason we can all agree on to increase block size - 2023-08-01T14:53:20.851423+00:00 + 2025-10-11T22:06:05.792160+00:00 + python-feedgen Jorge Timón 2015-08-04 10:53:07+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - A reason we can all agree on to increase block size - 2023-08-01T14:53:20.851423+00:00 + 2025-10-11T22:06:05.792377+00:00 - Increasing the block size in Bitcoin is a topic of debate and concern. Some argue that it would not be a problem, but others worry about the centralization of mining power and potential political manipulation by the Chinese government. To address this, suggestions include miners outside of China pointing to different pools and building more farms in smaller countries with cheap electricity. However, it is important to consider the risks associated with larger blocks, such as a higher likelihood of consensus forks that require manual intervention. Security should be prioritized over greater throughput, and efforts should focus on fixing issues that can lead to these incidents rather than increasing block size.The debate over block size is not just about technical requirements and security; it also has political implications as it affects all users of Bitcoin. The incentives of Bitcoin guide decisions throughout the system, from miners to merchants and users. Critics argue that limiting the block size would give the Chinese government centralized control over the cryptocurrency's hashing power. This, combined with Chinese mining dominance and the development of new laws on backdoor hardware and software, raises concerns about the future of Bitcoin.In response to views on "Chinese Miners," one user highlights the importance of diversity in opinion and mining within the Bitcoin community. They encourage those who wish to mine Bitcoin to invest in the necessary capital and technical resources. They seek input from Jim Phillips on colluding miner attacks mentioned in Joseph Poon and Thaddeus Dryja's "Lightning network" paper, aiming to move the discussion beyond anti-Chinese rhetoric.Jim Phillips previously expressed concern about the centralization of Bitcoin hashing power in China. He attributes this to factors like cheap ASIC chips, subsidized electricity, and natural cooling. While China controls 57% of all mined Bitcoins, they face a disadvantage in terms of bandwidth connectivity. Increasing the block size could further harm their competitiveness. Jim suggests utilizing the ample bandwidth available in most parts of the free world to decentralize Bitcoin mining and reduce Chinese government control. He includes a quote from David Ogilvy and reminds readers to think twice before printing.The Chinese government's control extends to various aspects of the country's "capitalist" enterprises, including the production of ASIC chips used in Bitcoin mining. Chinese miners benefit from advantages like cheap or free electricity, natural cooling, and accessible ASIC chips. As a result, the top four Chinese miners currently control more than half of all mined Bitcoins. However, their limited connectivity with the rest of the world poses a challenge. Restricting block size would only serve to consolidate Chinese government control over Bitcoin hashing power. It is imperative for the free world to leverage its extensive bandwidth and work towards decentralizing Bitcoin mining to mitigate this issue. 2015-08-04T10:53:07+00:00 + Increasing the block size in Bitcoin is a topic of debate and concern. Some argue that it would not be a problem, but others worry about the centralization of mining power and potential political manipulation by the Chinese government. To address this, suggestions include miners outside of China pointing to different pools and building more farms in smaller countries with cheap electricity. However, it is important to consider the risks associated with larger blocks, such as a higher likelihood of consensus forks that require manual intervention. Security should be prioritized over greater throughput, and efforts should focus on fixing issues that can lead to these incidents rather than increasing block size.The debate over block size is not just about technical requirements and security; it also has political implications as it affects all users of Bitcoin. The incentives of Bitcoin guide decisions throughout the system, from miners to merchants and users. Critics argue that limiting the block size would give the Chinese government centralized control over the cryptocurrency's hashing power. This, combined with Chinese mining dominance and the development of new laws on backdoor hardware and software, raises concerns about the future of Bitcoin.In response to views on "Chinese Miners," one user highlights the importance of diversity in opinion and mining within the Bitcoin community. They encourage those who wish to mine Bitcoin to invest in the necessary capital and technical resources. They seek input from Jim Phillips on colluding miner attacks mentioned in Joseph Poon and Thaddeus Dryja's "Lightning network" paper, aiming to move the discussion beyond anti-Chinese rhetoric.Jim Phillips previously expressed concern about the centralization of Bitcoin hashing power in China. He attributes this to factors like cheap ASIC chips, subsidized electricity, and natural cooling. While China controls 57% of all mined Bitcoins, they face a disadvantage in terms of bandwidth connectivity. Increasing the block size could further harm their competitiveness. Jim suggests utilizing the ample bandwidth available in most parts of the free world to decentralize Bitcoin mining and reduce Chinese government control. He includes a quote from David Ogilvy and reminds readers to think twice before printing.The Chinese government's control extends to various aspects of the country's "capitalist" enterprises, including the production of ASIC chips used in Bitcoin mining. Chinese miners benefit from advantages like cheap or free electricity, natural cooling, and accessible ASIC chips. As a result, the top four Chinese miners currently control more than half of all mined Bitcoins. However, their limited connectivity with the rest of the world poses a challenge. Restricting block size would only serve to consolidate Chinese government control over Bitcoin hashing power. It is imperative for the free world to leverage its extensive bandwidth and work towards decentralizing Bitcoin mining to mitigate this issue. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_A-solution-to-increase-the-incentive-of-running-a-node.xml b/static/bitcoin-dev/Aug_2015/combined_A-solution-to-increase-the-incentive-of-running-a-node.xml index b1dd1d201f..0cca23429d 100644 --- a/static/bitcoin-dev/Aug_2015/combined_A-solution-to-increase-the-incentive-of-running-a-node.xml +++ b/static/bitcoin-dev/Aug_2015/combined_A-solution-to-increase-the-incentive-of-running-a-node.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A solution to increase the incentive of running a node - 2023-08-01T15:33:58.232758+00:00 + 2025-10-11T22:05:48.788854+00:00 + python-feedgen Sergio Demian Lerner 2015-08-21 21:12:17+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - A solution to increase the incentive of running a node - 2023-08-01T15:33:58.232758+00:00 + 2025-10-11T22:05:48.789029+00:00 - In an email exchange, Sergio proposes a solution to prove ownership of blockchain through asymmetric-time functions and discusses his work on a transaction system called DAGCoin. He mentions that the draft will be sent to Hector for analysis or may be published altogether. Meanwhile, Tamas Blummer responds to Jameson Lopp's idea about the incentives for running a node in Bitcoin. He acknowledges the indirect incentives such as having a local copy of the validated blockchain data and supporting the network. In a heterogeneous environment, validating oneself becomes more valuable, especially during hard forks. Pooled mining became possible due to the homogenous nature of the network.The discussion on validating Bitcoin transactions involves Jameson Lopp asking if there is a way to check the validity of a transaction without access to blockchain data. Some basic checks such as ensuring it's not a double-spend and that signatures match pubkeys are necessary. As an SPV node, one can request unconfirmed transactions from connected peers, but this does not guarantee inclusion in the blockchain. Nodes should accept the first proof-of-work for a transaction and discard any subsequent ones received.In an email exchange between Hector Chu and Jameson Lopp, they discuss the use of SPV and validation of unconfirmed transactions. Lopp mentions that using SPV is only for checking the validity of transactions in the blockchain. Chu proposes nodes to validate transactions that are unconfirmed and commit to the validation by doing a proof of work on them. Lopp raises concerns about the increase in data size for each transaction, which could create more contention for block space. Chu suggests stipulating that coinbase fields only hold space for a single pubkey, reducing the extra data size.In August 2015, Jameson Lopp proposes a technical solution to allow a node operator to prove they are running an honest full node that hosts the entire blockchain. He mentions the PseudoNode project on GitHub and emphasizes the importance of validating transactions to prove the honesty of a full node.The failure of consensus on how to fix the design flaw in Bitcoin's block size is discussed. Satoshi Nakamoto suggests better incentives for users to run nodes instead of relying solely on altruism. The incentives for running a node may not be obvious to the average user, but they are indirectly present. There are thoughts on improving Bitcoin to incentivize more people to run nodes and prevent centralization. Mining and transaction validation should be inseparable, and rewards should go to those running the network. Decentralization of nodes is encouraged to be closer to the location of real transaction origination.In summary, the discussions revolve around proposals for proving ownership of blockchain, the incentives for running a node in Bitcoin, validating transactions, the increase in data size for each transaction, and the need for incentivizing full node operators. The failure of consensus on fixing the block size design flaw and the importance of decentralization are also highlighted. 2015-08-21T21:12:17+00:00 + In an email exchange, Sergio proposes a solution to prove ownership of blockchain through asymmetric-time functions and discusses his work on a transaction system called DAGCoin. He mentions that the draft will be sent to Hector for analysis or may be published altogether. Meanwhile, Tamas Blummer responds to Jameson Lopp's idea about the incentives for running a node in Bitcoin. He acknowledges the indirect incentives such as having a local copy of the validated blockchain data and supporting the network. In a heterogeneous environment, validating oneself becomes more valuable, especially during hard forks. Pooled mining became possible due to the homogenous nature of the network.The discussion on validating Bitcoin transactions involves Jameson Lopp asking if there is a way to check the validity of a transaction without access to blockchain data. Some basic checks such as ensuring it's not a double-spend and that signatures match pubkeys are necessary. As an SPV node, one can request unconfirmed transactions from connected peers, but this does not guarantee inclusion in the blockchain. Nodes should accept the first proof-of-work for a transaction and discard any subsequent ones received.In an email exchange between Hector Chu and Jameson Lopp, they discuss the use of SPV and validation of unconfirmed transactions. Lopp mentions that using SPV is only for checking the validity of transactions in the blockchain. Chu proposes nodes to validate transactions that are unconfirmed and commit to the validation by doing a proof of work on them. Lopp raises concerns about the increase in data size for each transaction, which could create more contention for block space. Chu suggests stipulating that coinbase fields only hold space for a single pubkey, reducing the extra data size.In August 2015, Jameson Lopp proposes a technical solution to allow a node operator to prove they are running an honest full node that hosts the entire blockchain. He mentions the PseudoNode project on GitHub and emphasizes the importance of validating transactions to prove the honesty of a full node.The failure of consensus on how to fix the design flaw in Bitcoin's block size is discussed. Satoshi Nakamoto suggests better incentives for users to run nodes instead of relying solely on altruism. The incentives for running a node may not be obvious to the average user, but they are indirectly present. There are thoughts on improving Bitcoin to incentivize more people to run nodes and prevent centralization. Mining and transaction validation should be inseparable, and rewards should go to those running the network. Decentralization of nodes is encouraged to be closer to the location of real transaction origination.In summary, the discussions revolve around proposals for proving ownership of blockchain, the incentives for running a node in Bitcoin, validating transactions, the increase in data size for each transaction, and the need for incentivizing full node operators. The failure of consensus on fixing the block size design flaw and the importance of decentralization are also highlighted. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_A-summary-list-of-all-concerns-related-to-not-rising-the-block-size.xml b/static/bitcoin-dev/Aug_2015/combined_A-summary-list-of-all-concerns-related-to-not-rising-the-block-size.xml index e8bcb28926..6530278c3d 100644 --- a/static/bitcoin-dev/Aug_2015/combined_A-summary-list-of-all-concerns-related-to-not-rising-the-block-size.xml +++ b/static/bitcoin-dev/Aug_2015/combined_A-summary-list-of-all-concerns-related-to-not-rising-the-block-size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A summary list of all concerns related to not rising the block size - 2023-08-01T15:08:49.499889+00:00 + 2025-10-11T22:05:10.523113+00:00 + python-feedgen Ahmed Zsales 2015-08-20 21:29:30+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - A summary list of all concerns related to not rising the block size - 2023-08-01T15:08:49.499889+00:00 + 2025-10-11T22:05:10.523293+00:00 - The context discusses the potential consequences of not increasing the hard limit on block size in Bitcoin. One concern is that an influx of new users and transactions could cause blocks to constantly be full, resulting in a backlog of transactions that grows indefinitely. This could lead to people losing faith in Bitcoin and eventually its demise. However, changing the block size limit requires a fork, which takes too long. If the limit had been increased earlier, mining pools could have quickly adjusted their own soft limits.There are risks associated with increasing the block size limit, such as the transaction fee market taking longer to develop. However, the alternative of not increasing the limit risks the death of Bitcoin. The main topic of discussion should not be transaction fees, but rather concerns about rising fees causing lowest fee transactions to become unreliable and people migrating to systems with lower fees. There are also software problems independent of the concrete block size that need to be solved, such as Bitcoin Core's unbounded mempool size and the lack of a good way to increase the fee of a slow transaction without creating a conflicting spend replacement.Ashley Holman expressed concerns about the security of the Bitcoin blockchain as a function of block size. She assumed that hash rate is correlated with revenue generated from mining, and total revenue from fees as a function of block size should follow a curve. On one extreme of the curve, if blocks are too big, fee revenue tends towards 0 due to lack of competition for block space. However, every miner has its own mining policy, and they can choose to delay including transactions based on their fee + first seen, creating a time-based fee market. This allows users to pay high fees for quick confirmation or low fees for slower confirmation times, even if the block capacity is unbounded.The author of the context expresses concern about security (hash rate) as a function of block size. They assume that hash rate is correlated with revenue from mining, and the total revenue from fees as a function of block size should follow a curve. The curve should have a sweet spot where fee revenue is maximized, but it should change as demand for block space changes. Not scaling the block size as demand grows could result in forfeiting potential miner revenue and hence security. However, decentralization should be the primary concern.Jorge Timon suggests that concerns about block size can be classified into two groups. The first group includes potential indirect consequences of rising fees, such as unreliable lowest fee transactions and migration to systems with lower fees. The second group consists of software problems independent of concrete block size that need to be solved, often specific to Bitcoin Core. These problems include Bitcoin Core's unbounded mempool size and the lack of a good way to increase the fee of a slow transaction without creating a conflicting spend replacement.The rise in fees is a major concern as it can reduce the utility of Bitcoin, make some use cases nonviable, discourage experimentation with new use cases, and make Bitcoin more vulnerable to regulation by hindering its user base from growing. Slowing usage growth decreases the likelihood of having enough transactions to fund the network via transaction fees. There are several concerns regarding the future of Bitcoin. One concern is that nodes may choke up on a backlog of transactions, leading to losses for Bitcoin-based businesses and a potential flight of users to other cryptocurrencies. Another concern is that network unreliability could cause the exchange rate to decline, potentially leading traders to stop speculation altogether. Additionally, there is a fear that Bitcoin may become like a cargo cult, where believers wait for certain events to occur, but individuals refuse to expand the current infrastructure due to security concerns. This fear suggests that if the runway (infrastructure) is not expanded, Bitcoin may suffer while another cryptocurrency takes its place.The concerns regarding rising fees in Bitcoin can be classified into two main groups. The first group includes potential indirect consequences of the rise in fees, such as the unreliability of currently free transactions and the migration of users to systems with lower fees. The second group consists of software problems independent of concrete block size that need to be solved anyway, often specific to Bitcoin Core. These problems include an unbounded mempool size that can cause crashes and the lack of a good way to increase transaction fees without double spending, which is blocked by most nodes following Bitcoin Core's default policy. The author invites readers to suggest more concerns for these categories and other categories they think may exist. 2015-08-20T21:29:30+00:00 + The context discusses the potential consequences of not increasing the hard limit on block size in Bitcoin. One concern is that an influx of new users and transactions could cause blocks to constantly be full, resulting in a backlog of transactions that grows indefinitely. This could lead to people losing faith in Bitcoin and eventually its demise. However, changing the block size limit requires a fork, which takes too long. If the limit had been increased earlier, mining pools could have quickly adjusted their own soft limits.There are risks associated with increasing the block size limit, such as the transaction fee market taking longer to develop. However, the alternative of not increasing the limit risks the death of Bitcoin. The main topic of discussion should not be transaction fees, but rather concerns about rising fees causing lowest fee transactions to become unreliable and people migrating to systems with lower fees. There are also software problems independent of the concrete block size that need to be solved, such as Bitcoin Core's unbounded mempool size and the lack of a good way to increase the fee of a slow transaction without creating a conflicting spend replacement.Ashley Holman expressed concerns about the security of the Bitcoin blockchain as a function of block size. She assumed that hash rate is correlated with revenue generated from mining, and total revenue from fees as a function of block size should follow a curve. On one extreme of the curve, if blocks are too big, fee revenue tends towards 0 due to lack of competition for block space. However, every miner has its own mining policy, and they can choose to delay including transactions based on their fee + first seen, creating a time-based fee market. This allows users to pay high fees for quick confirmation or low fees for slower confirmation times, even if the block capacity is unbounded.The author of the context expresses concern about security (hash rate) as a function of block size. They assume that hash rate is correlated with revenue from mining, and the total revenue from fees as a function of block size should follow a curve. The curve should have a sweet spot where fee revenue is maximized, but it should change as demand for block space changes. Not scaling the block size as demand grows could result in forfeiting potential miner revenue and hence security. However, decentralization should be the primary concern.Jorge Timon suggests that concerns about block size can be classified into two groups. The first group includes potential indirect consequences of rising fees, such as unreliable lowest fee transactions and migration to systems with lower fees. The second group consists of software problems independent of concrete block size that need to be solved, often specific to Bitcoin Core. These problems include Bitcoin Core's unbounded mempool size and the lack of a good way to increase the fee of a slow transaction without creating a conflicting spend replacement.The rise in fees is a major concern as it can reduce the utility of Bitcoin, make some use cases nonviable, discourage experimentation with new use cases, and make Bitcoin more vulnerable to regulation by hindering its user base from growing. Slowing usage growth decreases the likelihood of having enough transactions to fund the network via transaction fees. There are several concerns regarding the future of Bitcoin. One concern is that nodes may choke up on a backlog of transactions, leading to losses for Bitcoin-based businesses and a potential flight of users to other cryptocurrencies. Another concern is that network unreliability could cause the exchange rate to decline, potentially leading traders to stop speculation altogether. Additionally, there is a fear that Bitcoin may become like a cargo cult, where believers wait for certain events to occur, but individuals refuse to expand the current infrastructure due to security concerns. This fear suggests that if the runway (infrastructure) is not expanded, Bitcoin may suffer while another cryptocurrency takes its place.The concerns regarding rising fees in Bitcoin can be classified into two main groups. The first group includes potential indirect consequences of the rise in fees, such as the unreliability of currently free transactions and the migration of users to systems with lower fees. The second group consists of software problems independent of concrete block size that need to be solved anyway, often specific to Bitcoin Core. These problems include an unbounded mempool size that can cause crashes and the lack of a good way to increase transaction fees without double spending, which is blocked by most nodes following Bitcoin Core's default policy. The author invites readers to suggest more concerns for these categories and other categories they think may exist. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_A-summary-list-of-all-concerns-related-to-rising-the-block-size.xml b/static/bitcoin-dev/Aug_2015/combined_A-summary-list-of-all-concerns-related-to-rising-the-block-size.xml index f0a27908f8..d7ab0f49de 100644 --- a/static/bitcoin-dev/Aug_2015/combined_A-summary-list-of-all-concerns-related-to-rising-the-block-size.xml +++ b/static/bitcoin-dev/Aug_2015/combined_A-summary-list-of-all-concerns-related-to-rising-the-block-size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A summary list of all concerns related to rising the block size - 2023-08-01T15:09:10.775623+00:00 + 2025-10-11T22:05:53.039071+00:00 + python-feedgen Jorge Timón 2015-08-14 22:01:04+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - A summary list of all concerns related to rising the block size - 2023-08-01T15:09:10.775623+00:00 + 2025-10-11T22:05:53.039263+00:00 - In an email exchange on the Bitcoin-dev mailing list, Thomas Zander and Jorge Timon discussed concerns about increasing the Bitcoin block size limit. Zander emphasized the need to identify and address the risks associated with a block size increase before implementing any changes to the network. He acknowledged that Bitcoin's Lightning Network (LN) was developed to handle the network's growth, but argued that it would not be able to cater to all use cases such as remittances and cross-border purchases. Therefore, both LN and bigger blocks are necessary. Zander proposed discussing the potential risks of raising the block size in one thread while creating another thread to discuss why the block size should be increased. He encouraged contributors to think about the risks, even if they were confident that they weren't a concern at the current scale, as understanding and estimating these risks would be beneficial for future increases.In response to a question about "develop-by-concerns," the speaker shared a link to an article that highlighted the importance of setting goals and developing roadmaps to achieve those goals. The article argued against reactive management and advocated for a strategic approach where businesses identify their concerns and devise plans to address them. By setting clear goals and creating roadmaps, businesses can make informed decisions about implementing changes and timing them appropriately.The debate over the maximum block size in Bitcoin has uncovered a significant disagreement. While some argue that increasing the block size could result in further centralization of mining, others present formal proofs to dispute this claim. However, there are valid concerns related to increasing the block size. These include the potential worsening of mining centralization and the risk of government control enforcing transaction censorship, which could render certain use cases reliant on a decentralized chain impractical. Moreover, reversible transactions may face proportional fees instead of flat ones, impacting use cases like remittance. Another concern is that consistently avoiding the limit could lead to minimal minimum fees, currently set at zero. If fees and the block reward do not increase sufficiently, the subsidy block reward may eventually become inadequate to maintain the system's irreversibility. Noncompetitive block creation policies by miners and the emergence of unsustainable Bitcoin businesses are also possible outcomes. Lastly, misleading marketing around "free transactions bitcoin" may misguide users, causing frustration when they discover the unsustainability of this feature and the unreliability of free transactions. In light of these concerns, increasing the block size could have negative consequences for the Bitcoin network. 2015-08-14T22:01:04+00:00 + In an email exchange on the Bitcoin-dev mailing list, Thomas Zander and Jorge Timon discussed concerns about increasing the Bitcoin block size limit. Zander emphasized the need to identify and address the risks associated with a block size increase before implementing any changes to the network. He acknowledged that Bitcoin's Lightning Network (LN) was developed to handle the network's growth, but argued that it would not be able to cater to all use cases such as remittances and cross-border purchases. Therefore, both LN and bigger blocks are necessary. Zander proposed discussing the potential risks of raising the block size in one thread while creating another thread to discuss why the block size should be increased. He encouraged contributors to think about the risks, even if they were confident that they weren't a concern at the current scale, as understanding and estimating these risks would be beneficial for future increases.In response to a question about "develop-by-concerns," the speaker shared a link to an article that highlighted the importance of setting goals and developing roadmaps to achieve those goals. The article argued against reactive management and advocated for a strategic approach where businesses identify their concerns and devise plans to address them. By setting clear goals and creating roadmaps, businesses can make informed decisions about implementing changes and timing them appropriately.The debate over the maximum block size in Bitcoin has uncovered a significant disagreement. While some argue that increasing the block size could result in further centralization of mining, others present formal proofs to dispute this claim. However, there are valid concerns related to increasing the block size. These include the potential worsening of mining centralization and the risk of government control enforcing transaction censorship, which could render certain use cases reliant on a decentralized chain impractical. Moreover, reversible transactions may face proportional fees instead of flat ones, impacting use cases like remittance. Another concern is that consistently avoiding the limit could lead to minimal minimum fees, currently set at zero. If fees and the block reward do not increase sufficiently, the subsidy block reward may eventually become inadequate to maintain the system's irreversibility. Noncompetitive block creation policies by miners and the emergence of unsustainable Bitcoin businesses are also possible outcomes. Lastly, misleading marketing around "free transactions bitcoin" may misguide users, causing frustration when they discover the unsustainability of this feature and the unreliability of free transactions. In light of these concerns, increasing the block size could have negative consequences for the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Adjusted-difficulty-depending-on-relative-blocksize.xml b/static/bitcoin-dev/Aug_2015/combined_Adjusted-difficulty-depending-on-relative-blocksize.xml index 65acaeabe5..97115eccdf 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Adjusted-difficulty-depending-on-relative-blocksize.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Adjusted-difficulty-depending-on-relative-blocksize.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Adjusted difficulty depending on relative blocksize - 2023-08-01T15:13:59.755806+00:00 + 2025-10-11T22:05:19.035324+00:00 + python-feedgen Tom Harding 2015-09-09 19:53:10+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Adjusted difficulty depending on relative blocksize - 2023-08-01T15:13:59.755806+00:00 + 2025-10-11T22:05:19.035497+00:00 - The discussion on the bitcoin-dev mailing list revolves around the "flexcap" proposal by Greg Maxwell and Mark Friedenbach, which suggests adjusting the difficulty of mining Bitcoin based on the relative size of individual blocks to the average block size of the previous period. The concern is that any change in difficulty that is not in response to observed block production rate will unavoidably change the money supply schedule. Changing the reward can reduce the time-frame of the effect, but there is still an impact. The proposal aims to increase the block size as usage grows, but this would also result in longer confirmation times.There are concerns about possible attacks on the system and the impact on miners who invest in equipment to mine the blocks. It is suggested that dynamically adjusting the maximum block size would be simpler than fluctuating the difficulty based on transaction volume and fees paid. There is also a question raised about whether rich individuals and institutions could manipulate the difficulty by buying or selling BTC, affecting the exchange rate and miners' profitability.In response to the proposal, Jakob Rönnbäck suggests adjusting the difficulty of individual blocks based on their relative size to the average block size of the previous difficulty period. This would allow for an increase in block size as usage grows, but it would also result in longer confirmation times. Anthony Towns argues against this suggestion, stating that dynamically adjusting the maximum block size would be simpler. He raises concerns about potential attacks on the system and double-spends.The conversation includes references to the flexcap proposal by Greg Maxwell and Mark Friedenbach, which was discussed on the Bitcoin Development mailing list in May 2015. Adam Back provides links to the discussion threads for further reference. Jakob Rönnbäck expresses gratitude for finding the information he was looking for.Overall, the discussion centers around the idea of adjusting the difficulty and block size in response to changes in usage and transaction volume. There are various concerns and suggestions raised regarding the feasibility and potential impacts of these proposals. The conversation takes place on the bitcoin-dev mailing list, which is a platform for developers to discuss technical issues concerning Bitcoin. 2015-09-09T19:53:10+00:00 + The discussion on the bitcoin-dev mailing list revolves around the "flexcap" proposal by Greg Maxwell and Mark Friedenbach, which suggests adjusting the difficulty of mining Bitcoin based on the relative size of individual blocks to the average block size of the previous period. The concern is that any change in difficulty that is not in response to observed block production rate will unavoidably change the money supply schedule. Changing the reward can reduce the time-frame of the effect, but there is still an impact. The proposal aims to increase the block size as usage grows, but this would also result in longer confirmation times.There are concerns about possible attacks on the system and the impact on miners who invest in equipment to mine the blocks. It is suggested that dynamically adjusting the maximum block size would be simpler than fluctuating the difficulty based on transaction volume and fees paid. There is also a question raised about whether rich individuals and institutions could manipulate the difficulty by buying or selling BTC, affecting the exchange rate and miners' profitability.In response to the proposal, Jakob Rönnbäck suggests adjusting the difficulty of individual blocks based on their relative size to the average block size of the previous difficulty period. This would allow for an increase in block size as usage grows, but it would also result in longer confirmation times. Anthony Towns argues against this suggestion, stating that dynamically adjusting the maximum block size would be simpler. He raises concerns about potential attacks on the system and double-spends.The conversation includes references to the flexcap proposal by Greg Maxwell and Mark Friedenbach, which was discussed on the Bitcoin Development mailing list in May 2015. Adam Back provides links to the discussion threads for further reference. Jakob Rönnbäck expresses gratitude for finding the information he was looking for.Overall, the discussion centers around the idea of adjusting the difficulty and block size in response to changes in usage and transaction volume. There are various concerns and suggestions raised regarding the feasibility and potential impacts of these proposals. The conversation takes place on the bitcoin-dev mailing list, which is a platform for developers to discuss technical issues concerning Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Alternative-chain-support-for-payment-protocol.xml b/static/bitcoin-dev/Aug_2015/combined_Alternative-chain-support-for-payment-protocol.xml index b8de658da0..6263cf0de5 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Alternative-chain-support-for-payment-protocol.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Alternative-chain-support-for-payment-protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Alternative chain support for payment protocol - 2023-08-01T15:05:06.053679+00:00 + 2025-10-11T22:05:33.918694+00:00 + python-feedgen Jorge Timón 2015-08-10 19:49:23+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Alternative chain support for payment protocol - 2023-08-01T15:05:06.053679+00:00 + 2025-10-11T22:05:33.918857+00:00 - In a discussion on the bitcoin-dev forum, there was a proposal by Ross Nicoll to make the genesis field "repeated" in order to specify all potential networks. However, this idea faced opposition as it was argued that the chain ID needs to be unique for proper fork detection. The discussion revolved around finding a solution that ensures the uniqueness of the chain ID while still allowing for multiple potential networks. It was pointed out that not all genesis blocks are unique, with Litecoin and Feathercoin sharing the same one. However, this is considered a design flaw in Feathercoin and does not apply to Bitcoin.The topic then shifted towards Regtest, which is a testchain similar to testnet2 and testnet3. Testchains allow for the support of multiple chains using CChainParams. The discussion clarified that BIPs are specifically for Bitcoin improvements and anything that only improves altcoins is outside the scope of a BIP. However, it was suggested that an extension allowing payment directly on the sidechain could address the need for payments made in bitcoins on a sidechain, potentially solving two problems at once. The conversation also touched upon the similarities between payment protocol testchains, sidechains, and altcoins, noting that focusing on testchains would be sufficient if sidechains and altcoins are out of scope.Luke Dashjr proposed adding an optional "genesis" field to Bitcoin transactions that contains the SHA-256 hash of the genesis block of the network the request belongs to. This field would serve the purpose of identifying chains without the need for a central registry. However, it was brought to his attention that genesis blocks are not necessarily unique, and using the most recent block hash instead could provide fork detection, although it may also expose if a merchant is on the wrong fork. Dashjr mentioned that genesis hash collisions might be acceptable, and the server should reject any attempt to pay on the wrong chain. He also suggested that this proposal could address the need for payments made in bitcoins on a sidechain, potentially encompassing both Bitcoin improvements and altcoins.In an email exchange between Ross Nicoll and Luke Dashjr, they discussed the limitations of BIP 70 in supporting different testnets and alternative coins. Ross proposed adding a new optional "genesis" field to identify chains without a central registry. However, Luke pointed out that genesis blocks are not necessarily unique. They also touched upon using the most recent block hash for fork detection, albeit with the drawback of potentially advertising if a merchant is on the wrong fork. Ross emphasized the importance of avoiding future problems with the proposal. Luke reminded him that BIPs are specifically for Bitcoin improvements, but suggested that the proposal could address the need for payments made in bitcoins on a sidechain by allowing payment directly on the sidechain at the customer's choice.The developers have been discussing how to support side or alt-chains in BIP70, the payment protocol for Bitcoin. One possible solution suggested is the bip44 coin type registry, which would add an optional coin type field to PaymentRequest and serialize incompatible PaymentDetails to the serialized_payment_details field. However, concerns were raised regarding human-meaningful identifiers and name collisions. The idea of using the genesis hash as an alternative to short names was proposed. The discussion also highlighted the differences between altcoins derived from BTC and those developed differently. A visualization tool called Map of Coins was provided to further illustrate the variations among alt-coins.On August 10, 2015, Mike Hearn stated that BIP 70 is immutable and can only be extended. There was a suggestion to make exceptions for regtest mode, but it was argued that treating all supported chains the same way in the code would be simpler. It was mentioned that the dedicated chain ID for regtest mode is unnecessary outside of a developer machine where the ID does not matter.The context includes related commits from #6382, which includes a closed pull request (PR) and discussions on adding the chainID field and supporting regtest in BIP70. The author suggests unifying all testnets to use "testnet3" as the network string but acknowledges that it would require modifying BIP70. The discussion also mentions the differences between altcoins, sidechains, and testchains. It is suggested that adding new testchains should be made easier rather than harder. There is also a suggestion to use the genesis hash as the network name, although this may involve lookups to identify the request's purpose.Overall, the proposal put forth by Ross Nicoll aims to address the limitations of the current BIP 70 protocol by adding an optional "genesis" field that contains the SHA-256 hash of the genesis block of the network. This will enable unique identification of chains without the need for a central registry. The proposal received initial feedback and if there are no major objections, it will be raised as a BIP. Additionally, the context discusses the challenges of supporting side or alt-chains in BIP 70 and suggests using 2015-08-10T19:49:23+00:00 + In a discussion on the bitcoin-dev forum, there was a proposal by Ross Nicoll to make the genesis field "repeated" in order to specify all potential networks. However, this idea faced opposition as it was argued that the chain ID needs to be unique for proper fork detection. The discussion revolved around finding a solution that ensures the uniqueness of the chain ID while still allowing for multiple potential networks. It was pointed out that not all genesis blocks are unique, with Litecoin and Feathercoin sharing the same one. However, this is considered a design flaw in Feathercoin and does not apply to Bitcoin.The topic then shifted towards Regtest, which is a testchain similar to testnet2 and testnet3. Testchains allow for the support of multiple chains using CChainParams. The discussion clarified that BIPs are specifically for Bitcoin improvements and anything that only improves altcoins is outside the scope of a BIP. However, it was suggested that an extension allowing payment directly on the sidechain could address the need for payments made in bitcoins on a sidechain, potentially solving two problems at once. The conversation also touched upon the similarities between payment protocol testchains, sidechains, and altcoins, noting that focusing on testchains would be sufficient if sidechains and altcoins are out of scope.Luke Dashjr proposed adding an optional "genesis" field to Bitcoin transactions that contains the SHA-256 hash of the genesis block of the network the request belongs to. This field would serve the purpose of identifying chains without the need for a central registry. However, it was brought to his attention that genesis blocks are not necessarily unique, and using the most recent block hash instead could provide fork detection, although it may also expose if a merchant is on the wrong fork. Dashjr mentioned that genesis hash collisions might be acceptable, and the server should reject any attempt to pay on the wrong chain. He also suggested that this proposal could address the need for payments made in bitcoins on a sidechain, potentially encompassing both Bitcoin improvements and altcoins.In an email exchange between Ross Nicoll and Luke Dashjr, they discussed the limitations of BIP 70 in supporting different testnets and alternative coins. Ross proposed adding a new optional "genesis" field to identify chains without a central registry. However, Luke pointed out that genesis blocks are not necessarily unique. They also touched upon using the most recent block hash for fork detection, albeit with the drawback of potentially advertising if a merchant is on the wrong fork. Ross emphasized the importance of avoiding future problems with the proposal. Luke reminded him that BIPs are specifically for Bitcoin improvements, but suggested that the proposal could address the need for payments made in bitcoins on a sidechain by allowing payment directly on the sidechain at the customer's choice.The developers have been discussing how to support side or alt-chains in BIP70, the payment protocol for Bitcoin. One possible solution suggested is the bip44 coin type registry, which would add an optional coin type field to PaymentRequest and serialize incompatible PaymentDetails to the serialized_payment_details field. However, concerns were raised regarding human-meaningful identifiers and name collisions. The idea of using the genesis hash as an alternative to short names was proposed. The discussion also highlighted the differences between altcoins derived from BTC and those developed differently. A visualization tool called Map of Coins was provided to further illustrate the variations among alt-coins.On August 10, 2015, Mike Hearn stated that BIP 70 is immutable and can only be extended. There was a suggestion to make exceptions for regtest mode, but it was argued that treating all supported chains the same way in the code would be simpler. It was mentioned that the dedicated chain ID for regtest mode is unnecessary outside of a developer machine where the ID does not matter.The context includes related commits from #6382, which includes a closed pull request (PR) and discussions on adding the chainID field and supporting regtest in BIP70. The author suggests unifying all testnets to use "testnet3" as the network string but acknowledges that it would require modifying BIP70. The discussion also mentions the differences between altcoins, sidechains, and testchains. It is suggested that adding new testchains should be made easier rather than harder. There is also a suggestion to use the genesis hash as the network name, although this may involve lookups to identify the request's purpose.Overall, the proposal put forth by Ross Nicoll aims to address the limitations of the current BIP 70 protocol by adding an optional "genesis" field that contains the SHA-256 hash of the genesis block of the network. This will enable unique identification of chains without the need for a central registry. The proposal received initial feedback and if there are no major objections, it will be raised as a BIP. Additionally, the context discusses the challenges of supporting side or alt-chains in BIP 70 and suggests using - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Annoucing-Not-BitcoinXT.xml b/static/bitcoin-dev/Aug_2015/combined_Annoucing-Not-BitcoinXT.xml index 03769e7b61..6ff59176f3 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Annoucing-Not-BitcoinXT.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Annoucing-Not-BitcoinXT.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Annoucing Not-BitcoinXT - 2023-08-01T15:25:26.394190+00:00 + 2025-10-11T22:05:08.395183+00:00 + python-feedgen Jorge Timón 2015-08-19 09:47:22+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Annoucing Not-BitcoinXT - 2023-08-01T15:25:26.395224+00:00 + 2025-10-11T22:05:08.395385+00:00 - The email exchanges discussed various concerns and debates within the Bitcoin community, particularly regarding governance, block size increase, hostility, censorship, and the risks associated with hard forking. One topic of concern was the issue of governance and decision-making within the community. Some argued that decentralized currencies like Bitcoin should not be governed by centralized entities. Suggestions were made to separate libconsensus from Bitcoin Core to ensure decentralization. However, there were concerns about the potential consequences of hard forks and the fear of schism.The controversy surrounding the block size increase proposal for Bitcoin-XT was also discussed among developers. While some believed that a larger block size was necessary to accommodate increasing transactions, others warned of the negative impact it could have on the network. The issue was divisive because it required a hard fork, which is more difficult to implement than a soft fork. There were concerns that the debate could devolve into a "fork war" that would harm the network's stability. This highlighted the need for better governance within the Bitcoin community.Another topic of discussion was the issue of hostility within the Bitcoin community. There were discussions about the possibility of "enemies" waiting for Bitcoin to collapse and the importance of assuming the best intentions of others to find common ground. The role of psychological warfare agents and their potential impact on decentralization enthusiasts was also mentioned. The email thread emphasized the need for civility and understanding in resolving issues and highlighted the complexities of the Bitcoin community.In another email exchange, the ongoing block size debate was discussed. One developer believed that the core issue was not about block size but rather the perception of core developers being obstructionist. The PR battle surrounding the block size debate was seen as playing into the hands of one side. The complexity of the block size issue and the risk associated with attempting a hard fork in a politically divisive environment were highlighted. Cooperation and understanding different priorities and preferences were emphasized.The issue of hard forking in Bitcoin was also addressed in an email conversation. Different viewpoints were presented, with some advocating for total decentralization and others supporting guided decentralization. Concerns about the risks associated with a hard fork and the potential for a "fork war" were raised. The importance of well-argued thoughts rather than fear, uncertainty, and doubt (FUD) or flaming was emphasized.Overall, these email exchanges provided insights into the various viewpoints, concerns, and debates within the Bitcoin community. The issues of governance, block size increase, hostility, censorship, and the risks associated with hard forking were discussed. The conversations highlighted the complexities and challenges faced by the community and emphasized the need for civility, understanding, and reliable processes for decision-making and hard forks to occur.There was also a caution expressed by Eric Lombrozo, a Bitcoin developer, regarding proposed changes to the Bitcoin protocol. Lombrozo believed that attempting a hard fork in such a politically divisive environment could lead to serious problems and cause a rift within the Bitcoin community. He suggested testing any changes on a less controversial issue before risking billions of dollars' worth of assets. Others argued that competition is healthy and that Bitcoin's stability should not depend on the good will of anyone.The author of the context advocated for constructive actions instead of anger and disrespect between Bitcoin Core and Bitcoin XT supporters. They criticized developers and their supporters for trying to stay in power and stifling alternative opinions. The fear displayed by developers was seen as indicative of their real intentions.A version called Not-BitcoinXT was announced on GitHub, aiming to maintain the current block size until a "real technical consensus" is reached. There were concerns about individuals attempting to control the use of Bitcoin and resorting to name-calling, censorship, and sabotage of the XT switch. Despite these tactics, the author believed that history would eventually overcome those who try to control Bitcoin.The message also discussed the creation of Not-BitcoinXT and issues with interference between miners running XT and those running Not-BitcoinXT. Additionally, an advertisement for VFEmail's Metadata Mitigator service was included, which offers privacy features for emails, including protection against the NSA. VFEmail offered lifetime accounts for a one-time fee of $24.95, as well as commercial and bulk mail options. 2015-08-19T09:47:22+00:00 + The email exchanges discussed various concerns and debates within the Bitcoin community, particularly regarding governance, block size increase, hostility, censorship, and the risks associated with hard forking. One topic of concern was the issue of governance and decision-making within the community. Some argued that decentralized currencies like Bitcoin should not be governed by centralized entities. Suggestions were made to separate libconsensus from Bitcoin Core to ensure decentralization. However, there were concerns about the potential consequences of hard forks and the fear of schism.The controversy surrounding the block size increase proposal for Bitcoin-XT was also discussed among developers. While some believed that a larger block size was necessary to accommodate increasing transactions, others warned of the negative impact it could have on the network. The issue was divisive because it required a hard fork, which is more difficult to implement than a soft fork. There were concerns that the debate could devolve into a "fork war" that would harm the network's stability. This highlighted the need for better governance within the Bitcoin community.Another topic of discussion was the issue of hostility within the Bitcoin community. There were discussions about the possibility of "enemies" waiting for Bitcoin to collapse and the importance of assuming the best intentions of others to find common ground. The role of psychological warfare agents and their potential impact on decentralization enthusiasts was also mentioned. The email thread emphasized the need for civility and understanding in resolving issues and highlighted the complexities of the Bitcoin community.In another email exchange, the ongoing block size debate was discussed. One developer believed that the core issue was not about block size but rather the perception of core developers being obstructionist. The PR battle surrounding the block size debate was seen as playing into the hands of one side. The complexity of the block size issue and the risk associated with attempting a hard fork in a politically divisive environment were highlighted. Cooperation and understanding different priorities and preferences were emphasized.The issue of hard forking in Bitcoin was also addressed in an email conversation. Different viewpoints were presented, with some advocating for total decentralization and others supporting guided decentralization. Concerns about the risks associated with a hard fork and the potential for a "fork war" were raised. The importance of well-argued thoughts rather than fear, uncertainty, and doubt (FUD) or flaming was emphasized.Overall, these email exchanges provided insights into the various viewpoints, concerns, and debates within the Bitcoin community. The issues of governance, block size increase, hostility, censorship, and the risks associated with hard forking were discussed. The conversations highlighted the complexities and challenges faced by the community and emphasized the need for civility, understanding, and reliable processes for decision-making and hard forks to occur.There was also a caution expressed by Eric Lombrozo, a Bitcoin developer, regarding proposed changes to the Bitcoin protocol. Lombrozo believed that attempting a hard fork in such a politically divisive environment could lead to serious problems and cause a rift within the Bitcoin community. He suggested testing any changes on a less controversial issue before risking billions of dollars' worth of assets. Others argued that competition is healthy and that Bitcoin's stability should not depend on the good will of anyone.The author of the context advocated for constructive actions instead of anger and disrespect between Bitcoin Core and Bitcoin XT supporters. They criticized developers and their supporters for trying to stay in power and stifling alternative opinions. The fear displayed by developers was seen as indicative of their real intentions.A version called Not-BitcoinXT was announced on GitHub, aiming to maintain the current block size until a "real technical consensus" is reached. There were concerns about individuals attempting to control the use of Bitcoin and resorting to name-calling, censorship, and sabotage of the XT switch. Despite these tactics, the author believed that history would eventually overcome those who try to control Bitcoin.The message also discussed the creation of Not-BitcoinXT and issues with interference between miners running XT and those running Not-BitcoinXT. Additionally, an advertisement for VFEmail's Metadata Mitigator service was included, which offers privacy features for emails, including protection against the NSA. VFEmail offered lifetime accounts for a one-time fee of $24.95, as well as commercial and bulk mail options. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_BIP-104-Replace-Transaction-Fees-with-Data-Discussion-Draft-0-2-9.xml b/static/bitcoin-dev/Aug_2015/combined_BIP-104-Replace-Transaction-Fees-with-Data-Discussion-Draft-0-2-9.xml index f60a75876d..7dcf40ab3e 100644 --- a/static/bitcoin-dev/Aug_2015/combined_BIP-104-Replace-Transaction-Fees-with-Data-Discussion-Draft-0-2-9.xml +++ b/static/bitcoin-dev/Aug_2015/combined_BIP-104-Replace-Transaction-Fees-with-Data-Discussion-Draft-0-2-9.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9 - 2023-08-01T15:27:24.377300+00:00 + 2025-10-11T22:07:30.831881+00:00 + python-feedgen Ahmed Zsales 2015-08-17 23:57:52+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9 - 2023-08-01T15:27:24.377300+00:00 + 2025-10-11T22:07:30.832061+00:00 - On August 17, 2015, Ahmed Zsales proposed a long-term solution to replace mining rewards and transaction fees in the Bitcoin community. The proposal, titled BIP [104], was initially a discussion draft. However, Btc Drak pointed out that individuals cannot assign BIP numbers and must follow the format of "BIP-myproposal." Ahmed Zsales updated the proposal accordingly and removed the reference to self-ascribed numbers.Privacy issues were also addressed in the proposal, as confirmed by Angel Leon. Peter Todd made a public remark on Twitter about the proposal, adding the term "data mining" to its title. Despite the potentially disparaging tone, Ahmed Zsales thanked Peter Todd for his contribution. Interestingly, Peter Todd's tweet was posted on Twitter itself, a platform known for aggregating and selling data to data miners. Twitter has generated significant revenue from this practice, earning $48 million from data sales in 2014 with a 95% year-on-year growth rate. In fact, Twitter has invested $130 million in acquiring a data mining business to further expand this profitable aspect of their operations.The communication thread on the bitcoin-dev mailing list revolves around Ahmed Zsales' proposal for a long-term solution to replace mining rewards and transaction fees. The provided link leads to the discussion draft of BIP [104], which is open for feedback. Btc Drak highlights the importance of adhering to the correct format for assigning BIP numbers, while Angel Leon confirms that privacy concerns have been addressed in the proposal.The conversation then delves into the idea of adding more data to Bitcoin transactions to fill blocks faster. However, one participant expresses skepticism, arguing that this approach forces users to choose between paying transaction fees or including transaction-related data. They contend that this would compromise user privacy, a fundamental reason why people use Bitcoin. Additionally, they argue that since the data would be stored on the blockchain, there would be no need for users to pay miners for it.Another point of contention raised by the participant is the proposed change from the MIT license to a different one. They believe such a change would be unrealistic and incompatible with the Bitcoin ecosystem. Instead, they suggest that this proposal may find more acceptance in a different cryptocurrency community where users are more open to substantial changes. Furthermore, they caution that deviating from the MIT license could lead to conflicts that would render Bitcoin unusable for many organizations.The discussion initiates with a query regarding self-assigning bip numbers, which relates to the Bitcoin Improvement Proposal system. The email thread also mentions that the big data analysis market was valued at $125 billion in 2015 by IDC. As the Bitcoin blockchain continues to replace existing payment systems and attract millions or even hundreds of millions of users, the value of the data within the blockchain increases. This makes it attractive to data analytics businesses and blockchain start-ups. However, concerns arise that this proposal might transform Bitcoin into the most Orwellian form of money, contradicting initiatives like CoinJoin. Ultimately, the speaker doubts that the Bitcoin community will embrace this idea.The conversation further explores the proposal for a long-term solution to replace mining rewards and transaction fees, referred to as BIP [104]. The draft is still in the discussion phase. There is a discussion about whether increasing block sizes would allow for more transactions per block, consequently collecting more fees and distributing costs among a larger user base, thus keeping transaction fees low. However, some express concern that increasing block sizes might hinder those without access to cheap or free power from supplementing mining revenue through transaction fees. Moreover, larger block sizes may become necessary to compensate for halved coinbase rewards. Overall, the proposal and the concerns surrounding block size contribute to ongoing discussions about the future economic model of Bitcoin.In summary, Ahmed Zsales proposed a long-term solution to replace mining rewards and transaction fees in the Bitcoin community. The proposal, known as BIP [104], was initially a discussion draft. Feedback on the proposal is encouraged, and the discussion thread provides various perspectives on the feasibility and implications of the proposed changes. 2015-08-17T23:57:52+00:00 + On August 17, 2015, Ahmed Zsales proposed a long-term solution to replace mining rewards and transaction fees in the Bitcoin community. The proposal, titled BIP [104], was initially a discussion draft. However, Btc Drak pointed out that individuals cannot assign BIP numbers and must follow the format of "BIP-myproposal." Ahmed Zsales updated the proposal accordingly and removed the reference to self-ascribed numbers.Privacy issues were also addressed in the proposal, as confirmed by Angel Leon. Peter Todd made a public remark on Twitter about the proposal, adding the term "data mining" to its title. Despite the potentially disparaging tone, Ahmed Zsales thanked Peter Todd for his contribution. Interestingly, Peter Todd's tweet was posted on Twitter itself, a platform known for aggregating and selling data to data miners. Twitter has generated significant revenue from this practice, earning $48 million from data sales in 2014 with a 95% year-on-year growth rate. In fact, Twitter has invested $130 million in acquiring a data mining business to further expand this profitable aspect of their operations.The communication thread on the bitcoin-dev mailing list revolves around Ahmed Zsales' proposal for a long-term solution to replace mining rewards and transaction fees. The provided link leads to the discussion draft of BIP [104], which is open for feedback. Btc Drak highlights the importance of adhering to the correct format for assigning BIP numbers, while Angel Leon confirms that privacy concerns have been addressed in the proposal.The conversation then delves into the idea of adding more data to Bitcoin transactions to fill blocks faster. However, one participant expresses skepticism, arguing that this approach forces users to choose between paying transaction fees or including transaction-related data. They contend that this would compromise user privacy, a fundamental reason why people use Bitcoin. Additionally, they argue that since the data would be stored on the blockchain, there would be no need for users to pay miners for it.Another point of contention raised by the participant is the proposed change from the MIT license to a different one. They believe such a change would be unrealistic and incompatible with the Bitcoin ecosystem. Instead, they suggest that this proposal may find more acceptance in a different cryptocurrency community where users are more open to substantial changes. Furthermore, they caution that deviating from the MIT license could lead to conflicts that would render Bitcoin unusable for many organizations.The discussion initiates with a query regarding self-assigning bip numbers, which relates to the Bitcoin Improvement Proposal system. The email thread also mentions that the big data analysis market was valued at $125 billion in 2015 by IDC. As the Bitcoin blockchain continues to replace existing payment systems and attract millions or even hundreds of millions of users, the value of the data within the blockchain increases. This makes it attractive to data analytics businesses and blockchain start-ups. However, concerns arise that this proposal might transform Bitcoin into the most Orwellian form of money, contradicting initiatives like CoinJoin. Ultimately, the speaker doubts that the Bitcoin community will embrace this idea.The conversation further explores the proposal for a long-term solution to replace mining rewards and transaction fees, referred to as BIP [104]. The draft is still in the discussion phase. There is a discussion about whether increasing block sizes would allow for more transactions per block, consequently collecting more fees and distributing costs among a larger user base, thus keeping transaction fees low. However, some express concern that increasing block sizes might hinder those without access to cheap or free power from supplementing mining revenue through transaction fees. Moreover, larger block sizes may become necessary to compensate for halved coinbase rewards. Overall, the proposal and the concerns surrounding block size contribute to ongoing discussions about the future economic model of Bitcoin.In summary, Ahmed Zsales proposed a long-term solution to replace mining rewards and transaction fees in the Bitcoin community. The proposal, known as BIP [104], was initially a discussion draft. Feedback on the proposal is encouraged, and the discussion thread provides various perspectives on the feasibility and implications of the proposed changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_BIP-10X-Replace-Transaction-Fees-with-Data-Discussion-Draft-0-2-9.xml b/static/bitcoin-dev/Aug_2015/combined_BIP-10X-Replace-Transaction-Fees-with-Data-Discussion-Draft-0-2-9.xml index c1b6602909..847973e740 100644 --- a/static/bitcoin-dev/Aug_2015/combined_BIP-10X-Replace-Transaction-Fees-with-Data-Discussion-Draft-0-2-9.xml +++ b/static/bitcoin-dev/Aug_2015/combined_BIP-10X-Replace-Transaction-Fees-with-Data-Discussion-Draft-0-2-9.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 10X: Replace Transaction Fees with Data, Discussion Draft 0.2.9 - 2023-08-01T15:39:42.100348+00:00 + 2025-10-11T22:07:32.954362+00:00 + python-feedgen Ahmed Zsales 2015-08-24 12:57:46+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP 10X: Replace Transaction Fees with Data, Discussion Draft 0.2.9 - 2023-08-01T15:39:42.100348+00:00 + 2025-10-11T22:07:32.954516+00:00 - Ahmed Zsales responded to Adam Back's concerns about privacy in Bitcoin transactions, stating that anonymity is not something they would compromise. They have no intention of creating tools that analyze individual transaction details, but rather aggregate data that can be useful for businesses. Ahmed gave examples of how aggregated data from Bitcoin transactions could benefit small businesses in areas such as inventory planning, marketing budgets, and logistics.He highlighted the potential for accessing global, national, and regional industry data figures that are typically only available to large businesses due to the high costs of research. Ahmed also suggested using the block chain ledger as a valuable database to support Bitcoin's security infrastructure and address growing bandwidth challenges.Adam Back expressed confusion about the proposed monetization model and its potential impact on fungibility and planned Bitcoin improvements. He suggested that policy relating to identity for authorization should be handled at the payment protocol layer.Despite these concerns, Ahmed welcomed feedback on the proposal and stated that technical content would be increasing in the future, while discussion content would be removed. He then introduced BIP 104, a long-term solution to replace mining rewards and transaction fees. The working draft of BIP 104 has been updated based on public and private feedback, including clarifications on replacing the Coinbase subsidy and supplementing transaction fees. It also includes references to creating global, national, and regional Bitcoin Price Indices.The idealized requirements for this proposal are cryptographic fungibility and policy relating to identity for authorization at the payment protocol layer. Ahmed mentioned that the payment protocol is already being used and that the Lightning protocol ensures that data goes point-to-point, making it less visible for big data analytic monetization. However, there are concerns that this proposal may conflict with fungibility and planned Bitcoin improvements in the mid-term. 2015-08-24T12:57:46+00:00 + Ahmed Zsales responded to Adam Back's concerns about privacy in Bitcoin transactions, stating that anonymity is not something they would compromise. They have no intention of creating tools that analyze individual transaction details, but rather aggregate data that can be useful for businesses. Ahmed gave examples of how aggregated data from Bitcoin transactions could benefit small businesses in areas such as inventory planning, marketing budgets, and logistics.He highlighted the potential for accessing global, national, and regional industry data figures that are typically only available to large businesses due to the high costs of research. Ahmed also suggested using the block chain ledger as a valuable database to support Bitcoin's security infrastructure and address growing bandwidth challenges.Adam Back expressed confusion about the proposed monetization model and its potential impact on fungibility and planned Bitcoin improvements. He suggested that policy relating to identity for authorization should be handled at the payment protocol layer.Despite these concerns, Ahmed welcomed feedback on the proposal and stated that technical content would be increasing in the future, while discussion content would be removed. He then introduced BIP 104, a long-term solution to replace mining rewards and transaction fees. The working draft of BIP 104 has been updated based on public and private feedback, including clarifications on replacing the Coinbase subsidy and supplementing transaction fees. It also includes references to creating global, national, and regional Bitcoin Price Indices.The idealized requirements for this proposal are cryptographic fungibility and policy relating to identity for authorization at the payment protocol layer. Ahmed mentioned that the payment protocol is already being used and that the Lightning protocol ensures that data goes point-to-point, making it less visible for big data analytic monetization. However, there are concerns that this proposal may conflict with fungibility and planned Bitcoin improvements in the mid-term. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_BIP-Using-Median-time-past-as-endpoint-for-locktime-calculations.xml b/static/bitcoin-dev/Aug_2015/combined_BIP-Using-Median-time-past-as-endpoint-for-locktime-calculations.xml index 447e91ab1c..8afd01e41b 100644 --- a/static/bitcoin-dev/Aug_2015/combined_BIP-Using-Median-time-past-as-endpoint-for-locktime-calculations.xml +++ b/static/bitcoin-dev/Aug_2015/combined_BIP-Using-Median-time-past-as-endpoint-for-locktime-calculations.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: Using Median time-past as endpoint for locktime calculations - 2023-08-01T15:29:05.658834+00:00 + 2025-10-11T22:05:42.414802+00:00 + python-feedgen jl2012 at xbt.hk 2015-08-28 15:27:23+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BIP: Using Median time-past as endpoint for locktime calculations - 2023-08-01T15:29:05.658834+00:00 + 2025-10-11T22:05:42.414983+00:00 - A proposed solution has been suggested to address the problem with minimal changes to the current softfork logic. This solution allows for all features described in sipa's Version bits BIP. The solution involves setting the xVersion equal to nVersion AND 0b10000000000000000000000000011000, and miners supporting BIP65 will set xVersion to 8 or greater. If a sufficient number of blocks have an xVersion greater than or equal to 8, invalid blocks with xVersion 8 or greater will be rejected. Alternatively, if a higher percentage of blocks have an xVersion greater than or equal to 8, all blocks with xVersion will be rejected. However, it was noted that the proposed solution still uses up a version bit unnecessarily, as it rejects blocks with nVersion=0b001...000. Alternative solutions were also discussed, including Peter Todd's stateless nVersion bits w/ time-expiration proposal and the implementation of the original stateful nVersion bits proposal. The former only leads to a hard-fork if a soft-fork is rejected by the deadline, while the latter carries higher risk due to the complexity of tracking soft-fork state.Btc Drak has made updates to BIP 113 and credited Gregory Maxwell. He also made changes to BIPS 112 and 113 to reflect the amended deployment strategy. There is a discussion about the issue caused by Bitcoin XT, which produces blocks with nVersion=0b001...111. One suggestion is to apply a mask and trigger the soft-fork on nVersion >= 0b0...100 == 4, with miners producing blocks with nVersion=0b0...1000. However, this approach still uses up a version bit and rejects blocks with nVersion=0b001...000, resulting in a hard-fork. Another proposal is Peter Todd's stateless nVersion bits w/ time-expiration, which only leads to a hard-fork if a soft-fork is rejected by the deadline. Another alternative is to implement the original stateful nVersion bits proposal, but this carries higher risk due to the complexity of tracking soft-fork state.In a discussion in 2013, concerns were raised about miners manipulating nLockTime with time-based locks. Several solutions were proposed, including using the last block's ntime instead of the current one or enforcing nLockTime based on the previous block timestamp. However, these solutions had their own drawbacks. The idea of timestamping was seen as the best solution, as it allowed all users to set their clocks to what the majority of hashing power thinks nTime is, avoiding manipulation. BIP 113 was assigned number 113 and updated accordingly with credits given to Gregory Maxwell. In another conversation, developers discussed the trade-offs between setting nLockTime to the minimum time or adding a constant offset. It was noted that without timestamping, nodes can experience consensus failures. The conclusion was that minimum time is likely the best option if hash power is well-distributed. This conversation took place on July 16th, 2013.A discussion in July 2013 focused on the issue of nLockTime and time-based locks creating negative incentives for miners. Various proposals were put forth, including using the last block's ntime instead of the current one or enforcing nLockTime based on the previous block timestamp. However, these solutions had their own drawbacks. Timestamping was seen as a potential solution, but it introduced new risks such as an inflation attack. Ultimately, there was no good incentive to set nTime accurately other than miners rejecting blocks, which sabotages the purpose of nLockTime. Another conversation discussed the use of "min" as a potential solution to consensus failure, provided that hashpower is well distributed. The context also includes an email signature and attachment that cannot be further analyzed or contextualized.A user has submitted a pull request for the median-past timelock BIP on GitHub and asks for a link to the related discussion. Peter Todd responds, acknowledging Gregory Maxwell for the idea and giving credit to Mark Friedenbach for designing and authoring the reference implementation. Thomas Kerin is credited as the author of the BIP document. The email also includes a PGP signature.In an email thread on the bitcoin-dev mailing list, Peter Todd acknowledges an oversight in editing and requests a link to a discussion about incentives related to nTime. He states that Gregory Maxwell should receive credit for the idea discussed between him and Luke-Jr. Todd offers to search for the link for historical interest.The email thread discusses a Bitcoin Improvement Proposal authored by Thomas Kerin and with Mark Friedenbach designing and authoring the reference implementation. However, Peter Todd clarifies that Gregory Maxwell actually came up with the idea during a discussion about incentives related to nTime on #bitcoin-dev or #bitcoin-wizards. Todd believes that Maxwell deserves credit for the idea and will try to find a 2015-08-28T15:27:23+00:00 + A proposed solution has been suggested to address the problem with minimal changes to the current softfork logic. This solution allows for all features described in sipa's Version bits BIP. The solution involves setting the xVersion equal to nVersion AND 0b10000000000000000000000000011000, and miners supporting BIP65 will set xVersion to 8 or greater. If a sufficient number of blocks have an xVersion greater than or equal to 8, invalid blocks with xVersion 8 or greater will be rejected. Alternatively, if a higher percentage of blocks have an xVersion greater than or equal to 8, all blocks with xVersion will be rejected. However, it was noted that the proposed solution still uses up a version bit unnecessarily, as it rejects blocks with nVersion=0b001...000. Alternative solutions were also discussed, including Peter Todd's stateless nVersion bits w/ time-expiration proposal and the implementation of the original stateful nVersion bits proposal. The former only leads to a hard-fork if a soft-fork is rejected by the deadline, while the latter carries higher risk due to the complexity of tracking soft-fork state.Btc Drak has made updates to BIP 113 and credited Gregory Maxwell. He also made changes to BIPS 112 and 113 to reflect the amended deployment strategy. There is a discussion about the issue caused by Bitcoin XT, which produces blocks with nVersion=0b001...111. One suggestion is to apply a mask and trigger the soft-fork on nVersion >= 0b0...100 == 4, with miners producing blocks with nVersion=0b0...1000. However, this approach still uses up a version bit and rejects blocks with nVersion=0b001...000, resulting in a hard-fork. Another proposal is Peter Todd's stateless nVersion bits w/ time-expiration, which only leads to a hard-fork if a soft-fork is rejected by the deadline. Another alternative is to implement the original stateful nVersion bits proposal, but this carries higher risk due to the complexity of tracking soft-fork state.In a discussion in 2013, concerns were raised about miners manipulating nLockTime with time-based locks. Several solutions were proposed, including using the last block's ntime instead of the current one or enforcing nLockTime based on the previous block timestamp. However, these solutions had their own drawbacks. The idea of timestamping was seen as the best solution, as it allowed all users to set their clocks to what the majority of hashing power thinks nTime is, avoiding manipulation. BIP 113 was assigned number 113 and updated accordingly with credits given to Gregory Maxwell. In another conversation, developers discussed the trade-offs between setting nLockTime to the minimum time or adding a constant offset. It was noted that without timestamping, nodes can experience consensus failures. The conclusion was that minimum time is likely the best option if hash power is well-distributed. This conversation took place on July 16th, 2013.A discussion in July 2013 focused on the issue of nLockTime and time-based locks creating negative incentives for miners. Various proposals were put forth, including using the last block's ntime instead of the current one or enforcing nLockTime based on the previous block timestamp. However, these solutions had their own drawbacks. Timestamping was seen as a potential solution, but it introduced new risks such as an inflation attack. Ultimately, there was no good incentive to set nTime accurately other than miners rejecting blocks, which sabotages the purpose of nLockTime. Another conversation discussed the use of "min" as a potential solution to consensus failure, provided that hashpower is well distributed. The context also includes an email signature and attachment that cannot be further analyzed or contextualized.A user has submitted a pull request for the median-past timelock BIP on GitHub and asks for a link to the related discussion. Peter Todd responds, acknowledging Gregory Maxwell for the idea and giving credit to Mark Friedenbach for designing and authoring the reference implementation. Thomas Kerin is credited as the author of the BIP document. The email also includes a PGP signature.In an email thread on the bitcoin-dev mailing list, Peter Todd acknowledges an oversight in editing and requests a link to a discussion about incentives related to nTime. He states that Gregory Maxwell should receive credit for the idea discussed between him and Luke-Jr. Todd offers to search for the link for historical interest.The email thread discusses a Bitcoin Improvement Proposal authored by Thomas Kerin and with Mark Friedenbach designing and authoring the reference implementation. However, Peter Todd clarifies that Gregory Maxwell actually came up with the idea during a discussion about incentives related to nTime on #bitcoin-dev or #bitcoin-wizards. Todd believes that Maxwell deserves credit for the idea and will try to find a - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_BIP-draft-Hardfork-bit.xml b/static/bitcoin-dev/Aug_2015/combined_BIP-draft-Hardfork-bit.xml index 6d3eba85f9..7d7d9cf9d9 100644 --- a/static/bitcoin-dev/Aug_2015/combined_BIP-draft-Hardfork-bit.xml +++ b/static/bitcoin-dev/Aug_2015/combined_BIP-draft-Hardfork-bit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft: Hardfork bit - 2023-08-01T14:34:44.209378+00:00 + 2025-10-11T22:05:16.897244+00:00 + python-feedgen jl2012 at xbt.hk 2015-08-03 08:54:27+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BIP draft: Hardfork bit - 2023-08-01T14:34:44.209378+00:00 + 2025-10-11T22:05:16.897407+00:00 - A proposal for a "hardfork bit" has been put forward on Github by jl2012. The proposal aims to address concerns faced by users of a fork where a small/near/fluctuating majority of mining power is supported. The sender of the message praises the proposal, stating that it provides a fallback mechanism for economic actors who can make a decision and say "we're doing this". However, there is uncertainty over how the proposal should be classified and what it should be called. Michael Ruddy has asked whether the latest version of the proposal is available on Github or elsewhere for easier collaboration.The receiver of the message discusses the possibility of multiple hardforks sharing the same flag block and how the coinbase message can prevent any potential ambiguity and provide additional information to the warning system of non-upgrading nodes. The receiver suggests that if there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The receiver also explains why the "version 0" idea is not compatible with the version bits voting system and introduces the hardfork bit BIP as an alternative.The possibility of multiple hardforks sharing the same flag block is slim but can happen. To avoid potential ambiguity, the coinbase message provides additional information to the warning system of non-upgrading nodes. If there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The "version 0" idea is not compatible with the version bits voting system, so a hardfork bit BIP was proposed instead. The commit hash of the BIP for the particular hard fork could be used in the coinbase message. This ensures that the BIP cannot specify itself what to put in the coinbase and allows specific hard fork BIPs to be updated without making code changes. The coinbase message is used to guard against one or more hard forks piggy-backing on another's flag block and to have a nicer message in the alerting system. A version 0 or a >1MB block proposal was also suggested for a block size limit hard fork. However, the >1MB flag block creates DoS banning problems, so it is not as appealing as a version 0 or this hard fork bit proposal. A version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. This is because we'd want to enforce the rules of the previous soft forks that had been locked in. Other than that, the version 0 idea seems pretty similar to the hard fork bit proposal because you need more context than just the block itself to determine if it's a valid flag block. These reasons were part of why the hard fork bit proposal was progressed towards.The proposal for the hard fork bit mechanism is being discussed and refined among the developers. One of the points to consider is how to include BIP-GIT-HASH of the canonical BIP on Github in the coinbase, but it is not known until the code is written. Using the commit hash of the BIP solves this issue, as the BIP cannot specify what to put in the coinbase. The proposal suggests that the hard fork bit allows BIP authors to specify a unique value within a 20-byte limit or use "BIP" in case of small coinbases or to avoid duplicate values. This proposal aims to prevent hard forks from piggy-backing on another's flag block without prior collaboration and to have a nicer message in the alerting system. Another proposal alongside this one involves using version 0 or even >1MB block in the specific case of a block size limit hard fork. However, the >1MB flag block would create DoS banning problems. It also means that older nodes do not have the chance to notice a fork is happening as they would with a version 0 or the hard fork bit proposal. The version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. While these proposals are similar, the hard fork bit proposal has more context than just the block itself to determine if it's a valid flag block.The message is a response to an inquiry about the situation where a group of miners suddenly switch their support, for example not intending to back new rules. The writer suggests that miners may be economically rational and will switch if there is a large decrease in difficulty on the original chain without a corresponding decrease in token value. The message cautions against assuming that all miners will continue to support the side they initially signaled, as they are only invested in the chain they mine for a short time until coinbase maturity. If both sides of a fork retain value, mining will redistribute itself in terms of short term profitability at every difficulty adjustment, regardless of initial signaled support for the fork. The message is signed with PGP signature version AP 2015-08-03T08:54:27+00:00 + A proposal for a "hardfork bit" has been put forward on Github by jl2012. The proposal aims to address concerns faced by users of a fork where a small/near/fluctuating majority of mining power is supported. The sender of the message praises the proposal, stating that it provides a fallback mechanism for economic actors who can make a decision and say "we're doing this". However, there is uncertainty over how the proposal should be classified and what it should be called. Michael Ruddy has asked whether the latest version of the proposal is available on Github or elsewhere for easier collaboration.The receiver of the message discusses the possibility of multiple hardforks sharing the same flag block and how the coinbase message can prevent any potential ambiguity and provide additional information to the warning system of non-upgrading nodes. The receiver suggests that if there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The receiver also explains why the "version 0" idea is not compatible with the version bits voting system and introduces the hardfork bit BIP as an alternative.The possibility of multiple hardforks sharing the same flag block is slim but can happen. To avoid potential ambiguity, the coinbase message provides additional information to the warning system of non-upgrading nodes. If there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The "version 0" idea is not compatible with the version bits voting system, so a hardfork bit BIP was proposed instead. The commit hash of the BIP for the particular hard fork could be used in the coinbase message. This ensures that the BIP cannot specify itself what to put in the coinbase and allows specific hard fork BIPs to be updated without making code changes. The coinbase message is used to guard against one or more hard forks piggy-backing on another's flag block and to have a nicer message in the alerting system. A version 0 or a >1MB block proposal was also suggested for a block size limit hard fork. However, the >1MB flag block creates DoS banning problems, so it is not as appealing as a version 0 or this hard fork bit proposal. A version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. This is because we'd want to enforce the rules of the previous soft forks that had been locked in. Other than that, the version 0 idea seems pretty similar to the hard fork bit proposal because you need more context than just the block itself to determine if it's a valid flag block. These reasons were part of why the hard fork bit proposal was progressed towards.The proposal for the hard fork bit mechanism is being discussed and refined among the developers. One of the points to consider is how to include BIP-GIT-HASH of the canonical BIP on Github in the coinbase, but it is not known until the code is written. Using the commit hash of the BIP solves this issue, as the BIP cannot specify what to put in the coinbase. The proposal suggests that the hard fork bit allows BIP authors to specify a unique value within a 20-byte limit or use "BIP" in case of small coinbases or to avoid duplicate values. This proposal aims to prevent hard forks from piggy-backing on another's flag block without prior collaboration and to have a nicer message in the alerting system. Another proposal alongside this one involves using version 0 or even >1MB block in the specific case of a block size limit hard fork. However, the >1MB flag block would create DoS banning problems. It also means that older nodes do not have the chance to notice a fork is happening as they would with a version 0 or the hard fork bit proposal. The version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. While these proposals are similar, the hard fork bit proposal has more context than just the block itself to determine if it's a valid flag block.The message is a response to an inquiry about the situation where a group of miners suddenly switch their support, for example not intending to back new rules. The writer suggests that miners may be economically rational and will switch if there is a large decrease in difficulty on the original chain without a corresponding decrease in token value. The message cautions against assuming that all miners will continue to support the side they initially signaled, as they are only invested in the chain they mine for a short time until coinbase maturity. If both sides of a fork retain value, mining will redistribute itself in terms of short term profitability at every difficulty adjustment, regardless of initial signaled support for the fork. The message is signed with PGP signature version AP - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml b/static/bitcoin-dev/Aug_2015/combined_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml index 006baa6974..3748438d2b 100644 --- a/static/bitcoin-dev/Aug_2015/combined_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml +++ b/static/bitcoin-dev/Aug_2015/combined_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP65 / CHECKLOCKTIMEVERIFY deployment - 2023-08-01T13:54:09.592100+00:00 + 2025-10-11T22:06:31.314612+00:00 + python-feedgen Pieter Wuille 2015-08-04 16:54:39+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP65 / CHECKLOCKTIMEVERIFY deployment - 2023-08-01T13:54:09.592100+00:00 + 2025-10-11T22:06:31.314757+00:00 - On June 25, 2015, Peter Todd proposed the deployment of CheckLockTimeVerify (CLTV) considering its benefits to scalability solutions. He suggested using the existing median block version mechanism for CLTV as it is well-tested and understood. Todd stated that there is no lack of consensus on this proposal. He further added that if another soft-fork is proposed prior to BIP65 enforcement, they have the option of setting in motion yet another soft-fork as the median mechanism only requires forks to be serialized in sequence. The CLTV code has been extensively reviewed in the form of the "mempool-only" pull-req, has been included in the Elements sidechain prototype by Mark Friedenbach, has been running in production on Viacoin for six months, and has a few working demos of its functionality implemented.The adoption of BIP66 is close to 95% and will soon be enforced for all blocks. This leads to the consideration of how CheckLockTimeVerify (CLTV) will be implemented, especially given its benefits to scalability solutions such as payment channels. Peter Todd, a co-author of the Version bits BIP proposal, suggests that CLTV should be deployed sooner as the implementation of the BIP proposal will be complex. The CLTV code has been extensively reviewed and tested, including running in production on Viacoin for six months. Peter Todd proposes using the existing median block version mechanism previously used for nVersion=2 and nVersion=3 soft-forks for CLTV. This approach is well-tested and understood, allowing for easy backporting to v0.10.x (even 0.9.x) with low risk for rapid deployment. If another soft-fork is proposed before BIP65 enforcement, nVersion=4 can be set in motion as the median mechanism only requires forks to be serialized in sequence. Multiple soft-forks can be "in-flight" at the same time. 2015-08-04T16:54:39+00:00 + On June 25, 2015, Peter Todd proposed the deployment of CheckLockTimeVerify (CLTV) considering its benefits to scalability solutions. He suggested using the existing median block version mechanism for CLTV as it is well-tested and understood. Todd stated that there is no lack of consensus on this proposal. He further added that if another soft-fork is proposed prior to BIP65 enforcement, they have the option of setting in motion yet another soft-fork as the median mechanism only requires forks to be serialized in sequence. The CLTV code has been extensively reviewed in the form of the "mempool-only" pull-req, has been included in the Elements sidechain prototype by Mark Friedenbach, has been running in production on Viacoin for six months, and has a few working demos of its functionality implemented.The adoption of BIP66 is close to 95% and will soon be enforced for all blocks. This leads to the consideration of how CheckLockTimeVerify (CLTV) will be implemented, especially given its benefits to scalability solutions such as payment channels. Peter Todd, a co-author of the Version bits BIP proposal, suggests that CLTV should be deployed sooner as the implementation of the BIP proposal will be complex. The CLTV code has been extensively reviewed and tested, including running in production on Viacoin for six months. Peter Todd proposes using the existing median block version mechanism previously used for nVersion=2 and nVersion=3 soft-forks for CLTV. This approach is well-tested and understood, allowing for easy backporting to v0.10.x (even 0.9.x) with low risk for rapid deployment. If another soft-fork is proposed before BIP65 enforcement, nVersion=4 can be set in motion as the median mechanism only requires forks to be serialized in sequence. Multiple soft-forks can be "in-flight" at the same time. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_BIPS-proposal-for-implementing-AML-KYC-in-bitcoin.xml b/static/bitcoin-dev/Aug_2015/combined_BIPS-proposal-for-implementing-AML-KYC-in-bitcoin.xml index 5beb619002..ebc8fbcdb4 100644 --- a/static/bitcoin-dev/Aug_2015/combined_BIPS-proposal-for-implementing-AML-KYC-in-bitcoin.xml +++ b/static/bitcoin-dev/Aug_2015/combined_BIPS-proposal-for-implementing-AML-KYC-in-bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIPS proposal for implementing AML-KYC in bitcoin - 2023-08-01T15:41:53.780178+00:00 + 2025-10-11T22:05:46.664317+00:00 + python-feedgen prabhat 2015-08-31 11:28:23+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - BIPS proposal for implementing AML-KYC in bitcoin - 2023-08-01T15:41:53.780178+00:00 + 2025-10-11T22:05:46.664527+00:00 - The email thread discusses a proposal made by Prabhat Kumar Singh on the bitcoin-dev mailing list to create an AML-KYC module for controlling the Bitcoin network and qualifying use cases in an OFAC compliant way. The proposal receives mixed feedback, with some members opposing centralized authority and advocating for decentralized principles. Others argue that implementing AML-KYC measures should be optional and sit on top of the Bitcoin protocol rather than being integrated into it. In order to enforce universal policies for anti-money laundering (AML) and know your customer (KYC) requirements, a system of third-party checkers may be necessary in each country, according to the recipient. This would involve implementing an identity verification system and additional fees for maintenance. The recipient also highlights the potential issue of individual coins becoming tainted with previous ownership details, leading to blacklists and rendering some coins worthless. Furthermore, they caution that there could be criminal liability for ineffective AML-KYC procedures.A proposal was made in 2015 by Prabhat Kumar Singh on the bitcoin-dev mailing list to create an AML-KYC module that would control the bitcoin network and qualify use cases in compliance with the Office of Foreign Assets Control (OFAC). The aim of this proposal was to regulate the flow of funds through the network and mitigate the risks associated with money laundering. The recipient includes a link to a Reddit post from 2013 that discusses similar issues with bitcoin, as well as the Bitcoin Foundation's Law and Policy Committee.The proposed AML-KYC module outlined in the document specifies how mining and transactions in sanctioned countries should follow OFAC regulations within the bitcoin network. The motivation behind this proposal is to prevent the misuse of bitcoin's vast financial power, which has the potential to fund illicit activities such as terrorism, human trafficking, drug trafficking, and rights abuse. The central idea is to establish a bitcoin account controlled by the Bitcoin Foundation, acting as a fair play party and enforcement body. To achieve this, 0-sum transactions with a Memo Flag of BLOCK or ALLOW would be conducted, with empty memo transactions having no impact. While the new consensus protocol may not be favored by some nodes for various reasons, it is seen as a means to naturally clean up the bitcoin protocol from illicit miners and users. The implementation of this proposal is currently underway. 2015-08-31T11:28:23+00:00 + The email thread discusses a proposal made by Prabhat Kumar Singh on the bitcoin-dev mailing list to create an AML-KYC module for controlling the Bitcoin network and qualifying use cases in an OFAC compliant way. The proposal receives mixed feedback, with some members opposing centralized authority and advocating for decentralized principles. Others argue that implementing AML-KYC measures should be optional and sit on top of the Bitcoin protocol rather than being integrated into it. In order to enforce universal policies for anti-money laundering (AML) and know your customer (KYC) requirements, a system of third-party checkers may be necessary in each country, according to the recipient. This would involve implementing an identity verification system and additional fees for maintenance. The recipient also highlights the potential issue of individual coins becoming tainted with previous ownership details, leading to blacklists and rendering some coins worthless. Furthermore, they caution that there could be criminal liability for ineffective AML-KYC procedures.A proposal was made in 2015 by Prabhat Kumar Singh on the bitcoin-dev mailing list to create an AML-KYC module that would control the bitcoin network and qualify use cases in compliance with the Office of Foreign Assets Control (OFAC). The aim of this proposal was to regulate the flow of funds through the network and mitigate the risks associated with money laundering. The recipient includes a link to a Reddit post from 2013 that discusses similar issues with bitcoin, as well as the Bitcoin Foundation's Law and Policy Committee.The proposed AML-KYC module outlined in the document specifies how mining and transactions in sanctioned countries should follow OFAC regulations within the bitcoin network. The motivation behind this proposal is to prevent the misuse of bitcoin's vast financial power, which has the potential to fund illicit activities such as terrorism, human trafficking, drug trafficking, and rights abuse. The central idea is to establish a bitcoin account controlled by the Bitcoin Foundation, acting as a fair play party and enforcement body. To achieve this, 0-sum transactions with a Memo Flag of BLOCK or ALLOW would be conducted, with empty memo transactions having no impact. While the new consensus protocol may not be favored by some nodes for various reasons, it is seen as a means to naturally clean up the bitcoin protocol from illicit miners and users. The implementation of this proposal is currently underway. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-Core-versus-XT-observations.xml b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-Core-versus-XT-observations.xml index 699832e188..695d4fa6d3 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-Core-versus-XT-observations.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-Core-versus-XT-observations.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core versus XT observations - 2023-08-01T15:34:24.715035+00:00 + 2025-10-11T22:06:54.685791+00:00 + python-feedgen Felipe Micaroni Lalli 2015-08-19 17:14:52+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core versus XT observations - 2023-08-01T15:34:24.715035+00:00 + 2025-10-11T22:06:54.685951+00:00 - On August 19th, 2015, Ken Friece expressed his opinion on the idea of Not-BitcoinXT in an email. He believed it was a "really terrible idea" because Mike Hearn, the creator of the XT client, had shown that he would not back down. Friece argued that the chances of Not-BitcoinXT gaining 25% of the hashrate were almost non-existent. Instead, he believed that it would only help XT reach the 75% threshold sooner and leave more people on the losing side of the fork. However, Friece acknowledged that if 25% or more of the hashpower were against XT, Not-BitcoinXT could become a significant weapon for them. Despite some dismissing it as a bad idea, it had the potential to shake the market.The blocksize issue in Bitcoin has caused uncertainty among investors and entrepreneurs. While this has been challenging for some, direct Bitcoin investors have found enjoyment in these uncertainties. The recent Greek debt crisis led to a belief that Bitcoin could be used as a replacement currency, resulting in a price spike. This presented an opportunity for the author to sell some of their coins. However, with reports of Bitcoin potentially splitting in two, the price has dropped, allowing the author to buy back their coins. It is important to consider the concept of "developer attacks" when discussing the future of Bitcoin.The ongoing debate over the block size issue has led many users to run the XT client as a vote for bigger blocks. However, if Core were to support larger blocks, most XT users would switch back to Core, causing XT to die out. In this high stakes game, XT has gone all-in, but Core still holds the better hand. Core has several scaling solutions it could adopt to satisfy XT users enough to eliminate XT. The longer Core takes to reach consensus on this matter, the stronger XT becomes.The author also points out that the mining centralization effect resulting from larger blocks is overshadowed by the greater centralization caused by the Bitcoin market price. With a total Bitcoin market cap under 5 billion at the next halving in July 2016, only the most efficient miners will survive. If the market cap does not substantially grow, the potential mining centralization with 8MB blocks in 2016 would be insignificant compared to the scenario outlined above. The blocksize issue adds uncertainty, which investors dislike and increases the likelihood of the mining nightmare scenario. The entire ecosystem needs time to adjust and grow once a Core scaling solution is adopted.In summary, Not-BitcoinXT is seen as a terrible idea by some due to Mike Hearn's unwavering stance and the slim chances of it gaining sufficient support. The blocksize issue has created uncertainty in the Bitcoin market, affecting investors and entrepreneurs. The ongoing debate between XT and Core continues, with XT users supporting bigger blocks but ready to switch back to Core if it adopts larger blocks. The potential mining centralization caused by larger blocks is overshadowed by the centralization impact of the Bitcoin market price. The ecosystem requires time to adapt and expand once a Core scaling solution is implemented. 2015-08-19T17:14:52+00:00 + On August 19th, 2015, Ken Friece expressed his opinion on the idea of Not-BitcoinXT in an email. He believed it was a "really terrible idea" because Mike Hearn, the creator of the XT client, had shown that he would not back down. Friece argued that the chances of Not-BitcoinXT gaining 25% of the hashrate were almost non-existent. Instead, he believed that it would only help XT reach the 75% threshold sooner and leave more people on the losing side of the fork. However, Friece acknowledged that if 25% or more of the hashpower were against XT, Not-BitcoinXT could become a significant weapon for them. Despite some dismissing it as a bad idea, it had the potential to shake the market.The blocksize issue in Bitcoin has caused uncertainty among investors and entrepreneurs. While this has been challenging for some, direct Bitcoin investors have found enjoyment in these uncertainties. The recent Greek debt crisis led to a belief that Bitcoin could be used as a replacement currency, resulting in a price spike. This presented an opportunity for the author to sell some of their coins. However, with reports of Bitcoin potentially splitting in two, the price has dropped, allowing the author to buy back their coins. It is important to consider the concept of "developer attacks" when discussing the future of Bitcoin.The ongoing debate over the block size issue has led many users to run the XT client as a vote for bigger blocks. However, if Core were to support larger blocks, most XT users would switch back to Core, causing XT to die out. In this high stakes game, XT has gone all-in, but Core still holds the better hand. Core has several scaling solutions it could adopt to satisfy XT users enough to eliminate XT. The longer Core takes to reach consensus on this matter, the stronger XT becomes.The author also points out that the mining centralization effect resulting from larger blocks is overshadowed by the greater centralization caused by the Bitcoin market price. With a total Bitcoin market cap under 5 billion at the next halving in July 2016, only the most efficient miners will survive. If the market cap does not substantially grow, the potential mining centralization with 8MB blocks in 2016 would be insignificant compared to the scenario outlined above. The blocksize issue adds uncertainty, which investors dislike and increases the likelihood of the mining nightmare scenario. The entire ecosystem needs time to adjust and grow once a Core scaling solution is adopted.In summary, Not-BitcoinXT is seen as a terrible idea by some due to Mike Hearn's unwavering stance and the slim chances of it gaining sufficient support. The blocksize issue has created uncertainty in the Bitcoin market, affecting investors and entrepreneurs. The ongoing debate between XT and Core continues, with XT users supporting bigger blocks but ready to switch back to Core if it adopts larger blocks. The potential mining centralization caused by larger blocks is overshadowed by the centralization impact of the Bitcoin market price. The ecosystem requires time to adapt and expand once a Core scaling solution is implemented. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XT-0-11A.xml b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XT-0-11A.xml index 6c045964d8..b2faa962ec 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XT-0-11A.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XT-0-11A.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin XT 0.11A - 2023-08-01T15:20:28.570289+00:00 + 2025-10-11T22:06:12.166520+00:00 + python-feedgen Tamas Blummer 2015-08-20 14:25:21+00:00 @@ -191,13 +192,13 @@ - python-feedgen + 2 Combined summary - Bitcoin XT 0.11A - 2023-08-01T15:20:28.571290+00:00 + 2025-10-11T22:06:12.166728+00:00 - The discussion revolves around the security of Bitcoin and the potential implications of forking the software. One aspect of Bitcoin's security is Proof of Work (POW), which relies on the actions of miners and developers. However, POW is not the sole factor in maintaining the security of Bitcoin. Other aspects such as network uptime, software development, and protocol upgrades also contribute to its security. The consensus among developers, users, and miners is crucial in ensuring secure practices.The conversation also addresses the controversy surrounding Bitcoin XT and the potential for a hard fork. While some argue that forks should be allowed due to Bitcoin's open-source nature, there are concerns about the division it may cause among users and the impact on the value of both currencies. However, despite the ongoing debate, Bitcoin's unique advantages and lack of competitors make it unlikely to die or split.Another topic discussed is the potential chaos for Simplified Payment Verification (SPV) nodes if full nodes are divided between Bitcoin Core and XT. It is noted that SPV clients rely on centralized peer servers, and if these servers only return nodes on one side of the fork, the clients will only connect to that side.The conversation also touches upon game theory tactics and the potential economic investment in Bitcoin XT. There are suggestions to separate BTC from XTBTC by moving them in transactions bigger than 1MB, although this may have consequences for the utxo size in Bitcoin XT. The overall sentiment is that Bitcoin's value cannot be decreased or killed by just two people forking the software, and the open-source nature of Bitcoin allows for forks and consensus rule changes.The discussion also explores the potential for miners to intentionally harm confidence in Bitcoin Core. It is argued that Bitcoin Core could lose confidence if over 25% of the hash power supported the XT fork. This scenario would result in a reverse soft fork where the hard fork target of 75% is reached but over 25% of the hash power does not allow the hard fork.Additionally, there is a mention of a discussion on creating a transaction larger than 1MB without requiring a fork lasting for more than 100 blocks. Suggestions include using coinbase outputs of XT blocks or Bitcoin blocks to create outputs specific to each chain.Lastly, the email exchange discusses the possibility of spamming 8mb blocks with 1 Satoshi outputs to the brainwallet "BitcoinXT" as a way to manipulate the Bitcoin network. Various methods are suggested, such as using coinbase outputs of XT blocks or Bitcoin blocks to create these outputs. However, it is noted that this method may not be entirely secure due to the potential for a large reorg on the XT chain.The debate highlights the challenges of achieving consensus in the decentralized world of cryptocurrency development. The Bitcoin community is divided over the issue of increasing the block size. Some see the proposal as necessary for scalability, while others express concerns about permanent ledger forks and the risk to people's money. Accusations of conflicts of interest and political maneuvering further complicate the discussion.There are also discussions about the potential risks of forking the Bitcoin Core project. If the proposed Bitcoin XT fork gains enough support, there could be a node war and a risk of balances in new addresses vanishing. Disagreements between the network and economic actors like exchanges and wallet services could cause a plummet in BTC value and erode confidence. The author suggests fair play alternatives like voting through coinbase scriptSig or dynamic adjustment proposed by BIP 100.The conversation also delves into the potential conflict of interest in making money off Lightning, an open-source protocol. Some argue that the block size limitation artificially creates demand for Lightning, while others believe that miners are not in direct competition with Lightning and sidechains. The debate revolves around whether Bitcoin should implement a hard fork or not, with some calling for a less contentious change to be tested first.In August 2015, concerns were raised about the control exerted over communication channels in the Bitcoin ecosystem. The admin of the main communication channels stated that they would censor any program that does not follow 51%+ hash power, leading to a lack of progress in moving Bitcoin forward. This attempt to control the conversation has been criticized as undemocratic and not in line with libertarian principles. Those who raise these issues are often labeled as "trolls," and a small group outside of the Bitcoin ecosystem has control over the majority of resources, hindering progress.There is also discussion about whether non-mining Bitcoin users have a say in protocol changes. While the economic majority should theoretically have the final say, it is difficult to measure what the majority wants precisely enough to put into an algorithm. Miners can express their vote easily by switching to a different full node implementation, while users can express their vote by switching to a different wallet. However, if the wallet is not fully validating, it would need help in the form of checkpointing. Voting via proof-of-stake is seen as a potential option, but wallet developers 2015-08-20T14:25:21+00:00 + The discussion revolves around the security of Bitcoin and the potential implications of forking the software. One aspect of Bitcoin's security is Proof of Work (POW), which relies on the actions of miners and developers. However, POW is not the sole factor in maintaining the security of Bitcoin. Other aspects such as network uptime, software development, and protocol upgrades also contribute to its security. The consensus among developers, users, and miners is crucial in ensuring secure practices.The conversation also addresses the controversy surrounding Bitcoin XT and the potential for a hard fork. While some argue that forks should be allowed due to Bitcoin's open-source nature, there are concerns about the division it may cause among users and the impact on the value of both currencies. However, despite the ongoing debate, Bitcoin's unique advantages and lack of competitors make it unlikely to die or split.Another topic discussed is the potential chaos for Simplified Payment Verification (SPV) nodes if full nodes are divided between Bitcoin Core and XT. It is noted that SPV clients rely on centralized peer servers, and if these servers only return nodes on one side of the fork, the clients will only connect to that side.The conversation also touches upon game theory tactics and the potential economic investment in Bitcoin XT. There are suggestions to separate BTC from XTBTC by moving them in transactions bigger than 1MB, although this may have consequences for the utxo size in Bitcoin XT. The overall sentiment is that Bitcoin's value cannot be decreased or killed by just two people forking the software, and the open-source nature of Bitcoin allows for forks and consensus rule changes.The discussion also explores the potential for miners to intentionally harm confidence in Bitcoin Core. It is argued that Bitcoin Core could lose confidence if over 25% of the hash power supported the XT fork. This scenario would result in a reverse soft fork where the hard fork target of 75% is reached but over 25% of the hash power does not allow the hard fork.Additionally, there is a mention of a discussion on creating a transaction larger than 1MB without requiring a fork lasting for more than 100 blocks. Suggestions include using coinbase outputs of XT blocks or Bitcoin blocks to create outputs specific to each chain.Lastly, the email exchange discusses the possibility of spamming 8mb blocks with 1 Satoshi outputs to the brainwallet "BitcoinXT" as a way to manipulate the Bitcoin network. Various methods are suggested, such as using coinbase outputs of XT blocks or Bitcoin blocks to create these outputs. However, it is noted that this method may not be entirely secure due to the potential for a large reorg on the XT chain.The debate highlights the challenges of achieving consensus in the decentralized world of cryptocurrency development. The Bitcoin community is divided over the issue of increasing the block size. Some see the proposal as necessary for scalability, while others express concerns about permanent ledger forks and the risk to people's money. Accusations of conflicts of interest and political maneuvering further complicate the discussion.There are also discussions about the potential risks of forking the Bitcoin Core project. If the proposed Bitcoin XT fork gains enough support, there could be a node war and a risk of balances in new addresses vanishing. Disagreements between the network and economic actors like exchanges and wallet services could cause a plummet in BTC value and erode confidence. The author suggests fair play alternatives like voting through coinbase scriptSig or dynamic adjustment proposed by BIP 100.The conversation also delves into the potential conflict of interest in making money off Lightning, an open-source protocol. Some argue that the block size limitation artificially creates demand for Lightning, while others believe that miners are not in direct competition with Lightning and sidechains. The debate revolves around whether Bitcoin should implement a hard fork or not, with some calling for a less contentious change to be tested first.In August 2015, concerns were raised about the control exerted over communication channels in the Bitcoin ecosystem. The admin of the main communication channels stated that they would censor any program that does not follow 51%+ hash power, leading to a lack of progress in moving Bitcoin forward. This attempt to control the conversation has been criticized as undemocratic and not in line with libertarian principles. Those who raise these issues are often labeled as "trolls," and a small group outside of the Bitcoin ecosystem has control over the majority of resources, hindering progress.There is also discussion about whether non-mining Bitcoin users have a say in protocol changes. While the economic majority should theoretically have the final say, it is difficult to measure what the majority wants precisely enough to put into an algorithm. Miners can express their vote easily by switching to a different full node implementation, while users can express their vote by switching to a different wallet. However, if the wallet is not fully validating, it would need help in the form of checkpointing. Voting via proof-of-stake is seen as a potential option, but wallet developers - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XT-Fork.xml b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XT-Fork.xml index 9215e647ab..edc50d0bec 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XT-Fork.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XT-Fork.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin XT Fork - 2023-08-01T15:23:53.730552+00:00 + 2025-10-11T22:06:03.665237+00:00 + python-feedgen odinn 2015-08-21 03:01:40+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 Combined summary - Bitcoin XT Fork - 2023-08-01T15:23:53.731555+00:00 + 2025-10-11T22:06:03.665608+00:00 - Bitcoin XT, a proposed implementation of the BIP 101 protocol, has faced criticism for being an attack on the Bitcoin network. The implementation was submitted to Bitcoin Core as a pull request, but no further review was done due to identified issues that were not fixed. Bitcoin XT aims to address scaling issues with Bitcoin, but consensus is still being sought on alternative solutions.A developer in the bitcoin community, Mike Hearn, responded to comments about Gavin Andresen bypassing the review process for his BIP 101 proposal. Hearn argued that the proposal went through months of public discussion and was submitted via the normal process with minor changes suggested by other developers. However, Peter Todd pointed out issues with the proposal, including lack of testing details and non-deterministic expiration dates.There is a notion that no one else would bypass the review process, which the author seeks to dispel. They explain that there were months of public discussion leading up to the proposal and it was submitted for review via the normal process. While some minor code layout suggestions were incorporated, Todd stated that there was no chance of the proposal being accepted. The bugs in the implementation were only found when it was reviewed by the XT community, which Bitcoin Core had ignored.In August 2015, a member of the bitcoin-dev mailing list requested the removal of an anecdote from the list, suggesting it may be more suitable for a subreddit. The original poster acknowledged their mistake and apologized for posting it on the wrong platform.A member of the libbitcoin mailing list shared an encounter with Amir Taaki during a Spanish hack meeting. Concerns about Bitcoin Core were discussed, specifically mentioning Mike Hearn and Gavin Andresen. Hearn had proposed a blacklisting scheme for Bitcoin, while Andresen's conservatism regarding changes in Bitcoin was mentioned. The writer initially trusted Andresen but later realized that Taaki's concerns were valid. The conversation also touched on the payment protocol, with disagreements between the two parties.A post on Reddit claimed that an employee of Blockstream requested the removal of Gavin Andresen from his position as chief scientist at the Bitcoin Foundation. Peter Todd supported this request, arguing that it misleads the public about Bitcoin's decision-making processes and harms its reputation. The question arises whether the request was made individually or on behalf of the company, indicating the need for planning for a potential hard fork.In an email exchange, developers discussed the separation of consensus code from commit policies in Bitcoin Core. There were differing views on whether libconsensus should be built directly out of the bitcoind repository or moved to a separate repository. Concerns were raised about maintaining consensus when individual intent diverges, and forking the libconsensus project was suggested as a solution.Eric Lombrozo expressed concern about confusion between source code forks and blockchain forks and argued for clear communication to laypeople. He highlighted the progress made towards separating consensus code through libconsensus.Concerns have been raised about Gavin Andresen's commit access for the Bitcoin Core repository, with some noting that he censored posts and deleted comments on his pull requests. The controversy surrounding his actions has led to debates about removing his privileges.The Bitcoin Core developer community is in turmoil over the release of Bitcoin XT 0.11A, a fork of the cryptocurrency created by Gavin Andresen and Mike Hearn. The release was made in response to concerns about the 1MB block limit that could prevent Bitcoin from supporting increased traffic and users. However, many claim that Andresen did not follow the correct channels in releasing this version of Bitcoin, bypassing the review process and risking a controversial hard fork deployment war.Adam Back, who is on the Bitcoin-Dev mailing list, expressed his disappointment at this move, stating that the Bitcoin XT project did not even pretend to work through the proper process involved with Bitcoin development. Additionally, Back claims that no one else was reckless enough to try to start a deployment in such a way, and warns that the damage to community reputation and collaborative environment that this all causes is optimally bad.There were discussions on the bitcoin-dev mailing list regarding warnings about the proposed hard fork of Bitcoin. Btc Drak and Adam Back claimed to have warned Gavin and Mike about the proposed 75% activation threshold for the hard fork being "optimally bad", but their warnings were ignored. Btc Drak also suggested a timeout for the deployment of the hard fork, but Gavin removed it from his proposal.The discussion on the bitcoin-dev mailing list also revolved around improving the quality and relevance of discussions, creating a separate email list for non-technical discussions, and whether or not to manually approve new subscribers to prevent potential abuses. There were debates over Satoshi's return and the impact of his opinion on the community.In August 2015, an email was sent to the bitcoin-dev mailing list from someone claiming to be Satoshi Nakamoto. In the email, Nakamoto expressed concerns about the release of Bitcoin XT 0.11A and the potential 2015-08-21T03:01:40+00:00 + Bitcoin XT, a proposed implementation of the BIP 101 protocol, has faced criticism for being an attack on the Bitcoin network. The implementation was submitted to Bitcoin Core as a pull request, but no further review was done due to identified issues that were not fixed. Bitcoin XT aims to address scaling issues with Bitcoin, but consensus is still being sought on alternative solutions.A developer in the bitcoin community, Mike Hearn, responded to comments about Gavin Andresen bypassing the review process for his BIP 101 proposal. Hearn argued that the proposal went through months of public discussion and was submitted via the normal process with minor changes suggested by other developers. However, Peter Todd pointed out issues with the proposal, including lack of testing details and non-deterministic expiration dates.There is a notion that no one else would bypass the review process, which the author seeks to dispel. They explain that there were months of public discussion leading up to the proposal and it was submitted for review via the normal process. While some minor code layout suggestions were incorporated, Todd stated that there was no chance of the proposal being accepted. The bugs in the implementation were only found when it was reviewed by the XT community, which Bitcoin Core had ignored.In August 2015, a member of the bitcoin-dev mailing list requested the removal of an anecdote from the list, suggesting it may be more suitable for a subreddit. The original poster acknowledged their mistake and apologized for posting it on the wrong platform.A member of the libbitcoin mailing list shared an encounter with Amir Taaki during a Spanish hack meeting. Concerns about Bitcoin Core were discussed, specifically mentioning Mike Hearn and Gavin Andresen. Hearn had proposed a blacklisting scheme for Bitcoin, while Andresen's conservatism regarding changes in Bitcoin was mentioned. The writer initially trusted Andresen but later realized that Taaki's concerns were valid. The conversation also touched on the payment protocol, with disagreements between the two parties.A post on Reddit claimed that an employee of Blockstream requested the removal of Gavin Andresen from his position as chief scientist at the Bitcoin Foundation. Peter Todd supported this request, arguing that it misleads the public about Bitcoin's decision-making processes and harms its reputation. The question arises whether the request was made individually or on behalf of the company, indicating the need for planning for a potential hard fork.In an email exchange, developers discussed the separation of consensus code from commit policies in Bitcoin Core. There were differing views on whether libconsensus should be built directly out of the bitcoind repository or moved to a separate repository. Concerns were raised about maintaining consensus when individual intent diverges, and forking the libconsensus project was suggested as a solution.Eric Lombrozo expressed concern about confusion between source code forks and blockchain forks and argued for clear communication to laypeople. He highlighted the progress made towards separating consensus code through libconsensus.Concerns have been raised about Gavin Andresen's commit access for the Bitcoin Core repository, with some noting that he censored posts and deleted comments on his pull requests. The controversy surrounding his actions has led to debates about removing his privileges.The Bitcoin Core developer community is in turmoil over the release of Bitcoin XT 0.11A, a fork of the cryptocurrency created by Gavin Andresen and Mike Hearn. The release was made in response to concerns about the 1MB block limit that could prevent Bitcoin from supporting increased traffic and users. However, many claim that Andresen did not follow the correct channels in releasing this version of Bitcoin, bypassing the review process and risking a controversial hard fork deployment war.Adam Back, who is on the Bitcoin-Dev mailing list, expressed his disappointment at this move, stating that the Bitcoin XT project did not even pretend to work through the proper process involved with Bitcoin development. Additionally, Back claims that no one else was reckless enough to try to start a deployment in such a way, and warns that the damage to community reputation and collaborative environment that this all causes is optimally bad.There were discussions on the bitcoin-dev mailing list regarding warnings about the proposed hard fork of Bitcoin. Btc Drak and Adam Back claimed to have warned Gavin and Mike about the proposed 75% activation threshold for the hard fork being "optimally bad", but their warnings were ignored. Btc Drak also suggested a timeout for the deployment of the hard fork, but Gavin removed it from his proposal.The discussion on the bitcoin-dev mailing list also revolved around improving the quality and relevance of discussions, creating a separate email list for non-technical discussions, and whether or not to manually approve new subscribers to prevent potential abuses. There were debates over Satoshi's return and the impact of his opinion on the community.In August 2015, an email was sent to the bitcoin-dev mailing list from someone claiming to be Satoshi Nakamoto. In the email, Nakamoto expressed concerns about the release of Bitcoin XT 0.11A and the potential - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XTs-Tor-IP-blacklist-downloading-system-has-significant-privacy-leaks-.xml b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XTs-Tor-IP-blacklist-downloading-system-has-significant-privacy-leaks-.xml index ca55acad7c..28dd72b630 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XTs-Tor-IP-blacklist-downloading-system-has-significant-privacy-leaks-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-XTs-Tor-IP-blacklist-downloading-system-has-significant-privacy-leaks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin XTs Tor IP blacklist downloading system has significant privacy leaks. - 2023-08-01T15:30:26.592098+00:00 + 2025-10-11T22:05:25.423751+00:00 + python-feedgen Btc Drak 2015-08-19 18:51:11+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Bitcoin XTs Tor IP blacklist downloading system has significant privacy leaks. - 2023-08-01T15:30:26.593139+00:00 + 2025-10-11T22:05:25.423903+00:00 - In August 2015, concerns were raised about Bitcoin XT's privacy issue with its automatic Tor exit node list download. The code would still download the Tor exit node list, revealing the true location of the node, if the operator neglected to explicitly set -listen=0. Peter Todd noted that this was a feature of the software and not a bug. Gregory Maxwell removed the last "call home" feature in pull-req #5161 to address this issue, replacing previous calls to getmyip.com-type services with a local peer request. The DNS seeds were also modified to avoid leaking IP address information.Despite the privacy problem, Peter Todd acknowledged that Bitcoin XT was an improvement over the first implementation as it did not completely block the node once it filled up for the first time. However, he criticized Mike Hearn for making changes in the master code that did not correspond to peer-reviewed pull-req code.A user on the Bitcoin development mailing list pointed out that Bitcoin XT had a privacy issue with its automatic Tor exit node list download. The code would still download the Tor exit node list, revealing the true location of the node, if certain conditions were met. Gregory Maxwell made changes to address this issue, but there were concerns about the lack of clarity in describing the blacklisting feature and its default enabling. The anti-DoS measures were deemed ineffective, as connections were still made over clearnet, leaking the node's real location. Denial of service attacks could also be used to crash interesting nodes and force them to restart, making new requests to the blacklist endpoint via the clearnet. Requests to the blacklisting URL also used a custom Bitcoin XT user agent, making users distinct from other internet traffic.Another message on the Bitcoin-dev mailing list highlighted the privacy implications of Bitcoin XT's blacklisting feature, which periodically downloaded lists of Tor IP addresses. Enabled by default with a switch name that downplayed its function, this feature raised concerns about user privacy. The anti-DoS measures were easily bypassed, offering no protection. Connections were made over clearnet even when using a proxy or onlynet=tor, revealing the node's real location. Denial of service attacks could crash interesting nodes and force them to restart, making new requests to the blacklist endpoint. Requests to the blacklisting URL also used a custom Bitcoin XT user agent, distinguishing users from other internet traffic.In summary, Bitcoin XT had a privacy issue with its automatic Tor exit node list download, revealing the true location of the node under certain conditions. Changes were made to address this issue, but concerns were raised about the lack of clarity in describing the blacklisting feature and its default enabling. The anti-DoS measures were deemed ineffective, as connections were still made over clearnet, leaking the node's real location. Denial of service attacks could also be used to crash interesting nodes and force them to restart, making new requests to the blacklist endpoint. Requests to the blacklisting URL also used a custom Bitcoin XT user agent, making users distinct from other internet traffic. 2015-08-19T18:51:11+00:00 + In August 2015, concerns were raised about Bitcoin XT's privacy issue with its automatic Tor exit node list download. The code would still download the Tor exit node list, revealing the true location of the node, if the operator neglected to explicitly set -listen=0. Peter Todd noted that this was a feature of the software and not a bug. Gregory Maxwell removed the last "call home" feature in pull-req #5161 to address this issue, replacing previous calls to getmyip.com-type services with a local peer request. The DNS seeds were also modified to avoid leaking IP address information.Despite the privacy problem, Peter Todd acknowledged that Bitcoin XT was an improvement over the first implementation as it did not completely block the node once it filled up for the first time. However, he criticized Mike Hearn for making changes in the master code that did not correspond to peer-reviewed pull-req code.A user on the Bitcoin development mailing list pointed out that Bitcoin XT had a privacy issue with its automatic Tor exit node list download. The code would still download the Tor exit node list, revealing the true location of the node, if certain conditions were met. Gregory Maxwell made changes to address this issue, but there were concerns about the lack of clarity in describing the blacklisting feature and its default enabling. The anti-DoS measures were deemed ineffective, as connections were still made over clearnet, leaking the node's real location. Denial of service attacks could also be used to crash interesting nodes and force them to restart, making new requests to the blacklist endpoint via the clearnet. Requests to the blacklisting URL also used a custom Bitcoin XT user agent, making users distinct from other internet traffic.Another message on the Bitcoin-dev mailing list highlighted the privacy implications of Bitcoin XT's blacklisting feature, which periodically downloaded lists of Tor IP addresses. Enabled by default with a switch name that downplayed its function, this feature raised concerns about user privacy. The anti-DoS measures were easily bypassed, offering no protection. Connections were made over clearnet even when using a proxy or onlynet=tor, revealing the node's real location. Denial of service attacks could crash interesting nodes and force them to restart, making new requests to the blacklist endpoint. Requests to the blacklisting URL also used a custom Bitcoin XT user agent, distinguishing users from other internet traffic.In summary, Bitcoin XT had a privacy issue with its automatic Tor exit node list download, revealing the true location of the node under certain conditions. Changes were made to address this issue, but concerns were raised about the lack of clarity in describing the blacklisting feature and its default enabling. The anti-DoS measures were deemed ineffective, as connections were still made over clearnet, leaking the node's real location. Denial of service attacks could also be used to crash interesting nodes and force them to restart, making new requests to the blacklist endpoint. Requests to the blacklisting URL also used a custom Bitcoin XT user agent, making users distinct from other internet traffic. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-is-an-experiment-Why-don-t-we-have-an-experimental-hardfork-.xml b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-is-an-experiment-Why-don-t-we-have-an-experimental-hardfork-.xml index f29c12e1d4..352216f591 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Bitcoin-is-an-experiment-Why-don-t-we-have-an-experimental-hardfork-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Bitcoin-is-an-experiment-Why-don-t-we-have-an-experimental-hardfork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin is an experiment. Why don't we have an experimental hardfork? - 2023-08-01T15:29:59.913844+00:00 + 2025-10-11T22:06:46.188679+00:00 + python-feedgen Jorge Timón 2015-08-19 18:33:57+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Bitcoin is an experiment. Why don't we have an experimental hardfork? - 2023-08-01T15:29:59.914905+00:00 + 2025-10-11T22:06:46.188848+00:00 - The Bitcoin community has been engaged in discussions about increasing the block size limit. One proposal suggests a block size increase to 1.5MB, with a backup plan if no consensus is reached. The backup plan involves increasing the block size to 1.5MB, 30 days after receiving 80% miner approval, but not before June 1, 2016. Developers agree to find a better solution by December 31, 2017. The debate also touched on softforks versus hardforks and the importance of upgrading full nodes. It was argued that softforks are not necessarily safer than hardforks, as demonstrated by the recent BIP66 fork. Non-upgrading full nodes were also deemed not true full nodes. The length of the grace period for a hardfork was discussed, with suggestions ranging from four months to five years. The general consensus was that many people won't update until required, making the length of the grace period important.Overall, the conversation highlighted the ongoing debate within the Bitcoin community regarding the block size limit and the best approach to increasing it. Consensus among major stakeholders, including miners, exchanges, merchants, and investors, is crucial for the success of any proposed changes to the Bitcoin network.To address the challenge of convincing enough people to switch without causing damage to the system, a proposal suggests deploying a block size limit experiment on the public global testnet blockchain. This would allow real-world testing of network lag, bandwidth constraints, and traffic bottlenecks. The objective is to demonstrate that consensus for a Bitcoin hardfork is possible, collect data for future hardforks, and relieve pressure on full blocks without affecting network performance.A backup plan has been proposed if no other consensus is reached before February 1, 2016. This backup plan involves increasing the block size to 1.5MB, 30 days after 80% miner approval, but not before June 1, 2016. A better solution is agreed upon to be found before December 31, 2017, with further debate and data collection.The rationale behind these proposals is the belief that technology has significantly improved since the current 1MB cap was set five years ago. A slight increase in block size is seen as providing valuable data for future hardforks. The proposal suggests an 80% miner approval rate to ensure sufficient mining power secures the new fork.If the community agrees with the experimental hardfork, the plan will be announced on bitcoin.org and coding of the patch will begin immediately. If no further consensus is reached, a new version of Bitcoin Core with the patch will be released on or before February 1, 2016, and everyone will be asked to upgrade immediately. The aim is to demonstrate that consensus for a Bitcoin hardfork is possible and pave the way for future hardforks. 2015-08-19T18:33:57+00:00 + The Bitcoin community has been engaged in discussions about increasing the block size limit. One proposal suggests a block size increase to 1.5MB, with a backup plan if no consensus is reached. The backup plan involves increasing the block size to 1.5MB, 30 days after receiving 80% miner approval, but not before June 1, 2016. Developers agree to find a better solution by December 31, 2017. The debate also touched on softforks versus hardforks and the importance of upgrading full nodes. It was argued that softforks are not necessarily safer than hardforks, as demonstrated by the recent BIP66 fork. Non-upgrading full nodes were also deemed not true full nodes. The length of the grace period for a hardfork was discussed, with suggestions ranging from four months to five years. The general consensus was that many people won't update until required, making the length of the grace period important.Overall, the conversation highlighted the ongoing debate within the Bitcoin community regarding the block size limit and the best approach to increasing it. Consensus among major stakeholders, including miners, exchanges, merchants, and investors, is crucial for the success of any proposed changes to the Bitcoin network.To address the challenge of convincing enough people to switch without causing damage to the system, a proposal suggests deploying a block size limit experiment on the public global testnet blockchain. This would allow real-world testing of network lag, bandwidth constraints, and traffic bottlenecks. The objective is to demonstrate that consensus for a Bitcoin hardfork is possible, collect data for future hardforks, and relieve pressure on full blocks without affecting network performance.A backup plan has been proposed if no other consensus is reached before February 1, 2016. This backup plan involves increasing the block size to 1.5MB, 30 days after 80% miner approval, but not before June 1, 2016. A better solution is agreed upon to be found before December 31, 2017, with further debate and data collection.The rationale behind these proposals is the belief that technology has significantly improved since the current 1MB cap was set five years ago. A slight increase in block size is seen as providing valuable data for future hardforks. The proposal suggests an 80% miner approval rate to ensure sufficient mining power secures the new fork.If the community agrees with the experimental hardfork, the plan will be announced on bitcoin.org and coding of the patch will begin immediately. If no further consensus is reached, a new version of Bitcoin Core with the patch will be released on or before February 1, 2016, and everyone will be asked to upgrade immediately. The aim is to demonstrate that consensus for a Bitcoin hardfork is possible and pave the way for future hardforks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Block-size-following-technological-growth.xml b/static/bitcoin-dev/Aug_2015/combined_Block-size-following-technological-growth.xml index 2b2910b646..dd42cc810b 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Block-size-following-technological-growth.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Block-size-following-technological-growth.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block size following technological growth - 2023-08-01T14:46:20.405973+00:00 + 2025-10-11T22:06:14.295059+00:00 + python-feedgen Elliot Olds 2015-08-11 05:48:17+00:00 @@ -259,13 +260,13 @@ - python-feedgen + 2 Combined summary - Block size following technological growth - 2023-08-01T14:46:20.407923+00:00 + 2025-10-11T22:06:14.295376+00:00 - In a series of email conversations, various individuals discussed the block size limit, transaction fees, and mining centralization in Bitcoin. Mike Hearn emphasized the need for a plan to handle sudden spikes in transaction demand and argued against roadblocks that could cause high fees. Elliot Olds and Jorge Timón discussed the trade-off between lower fees and mining centralization, highlighting the risks to decentralization. The concept of a fee market was debated, with concerns raised about hindering growth. Gavin Andresen engaged in multiple exchanges, discussing topics such as minimum fees, block size increase proposals, and preventing centralization.The ongoing debate regarding increasing the block size limit was discussed, with perspectives exchanged on payment demand and user satisfaction. Efforts to grow the user base through killer apps were acknowledged but considered hit and miss. Potential consequences of an oversaturated network were mentioned, emphasizing reliable transaction confirmation. In an exchange between Andresen and Pieter Wuille, they discussed competition for block space. Wuille argued for improving scalability without limiting block space supply, while Andresen believed competition was good but artificial limits were bad. Wuille disagreed but emphasized decentralized control over transactions.Andresen responded to Timón's statement about Bitcoin failing if the block size limit isn't increased, clarifying the urgency without claiming failure. Wuille disagreed with Andresen's view on competition for block space, proposing the development of a fee market. Timón appreciated a more reasonable position from Andresen and urged both sides to focus on resolving questions. Discussions touched upon the harm caused by hitting the block size limit and the need for criteria based on mining centralization. Simulating different block sizes was proposed to make informed decisions.The issue of mining centralization and block size limits were also discussed. Timón argued for a block size limit to limit mining centralization, while Hector Chu challenged Timón to provide a counter-example. Discussions highlighted the complexities surrounding block size limits and their impact on mining centralization. In a discussion about the Bitcoin network, the need for concrete timelines and larger blocks was acknowledged. Bryan Bishop proposed verifying summarizing transactions, and Andresen proposed increasing the block size limit to 2MB by 2021.Pieter proposed increasing the maximum block size to 2MB, Suhas Daftuar approved pending further thoughts, and Jameson Lopp discussed trade-offs between decentralization and growth. Timón preferred a more limited solution before adapting the block size. A post recommended waiting for improvements before adjusting the block size, expressing a preference for a more limited solution. Wuille shared a proposal for long-term scalability, requesting comments from the community.Overall, the discussions revolved around scalability in the Bitcoin network, focusing on the block size limit and potential solutions for long-term scalability. 2015-08-11T05:48:17+00:00 + In a series of email conversations, various individuals discussed the block size limit, transaction fees, and mining centralization in Bitcoin. Mike Hearn emphasized the need for a plan to handle sudden spikes in transaction demand and argued against roadblocks that could cause high fees. Elliot Olds and Jorge Timón discussed the trade-off between lower fees and mining centralization, highlighting the risks to decentralization. The concept of a fee market was debated, with concerns raised about hindering growth. Gavin Andresen engaged in multiple exchanges, discussing topics such as minimum fees, block size increase proposals, and preventing centralization.The ongoing debate regarding increasing the block size limit was discussed, with perspectives exchanged on payment demand and user satisfaction. Efforts to grow the user base through killer apps were acknowledged but considered hit and miss. Potential consequences of an oversaturated network were mentioned, emphasizing reliable transaction confirmation. In an exchange between Andresen and Pieter Wuille, they discussed competition for block space. Wuille argued for improving scalability without limiting block space supply, while Andresen believed competition was good but artificial limits were bad. Wuille disagreed but emphasized decentralized control over transactions.Andresen responded to Timón's statement about Bitcoin failing if the block size limit isn't increased, clarifying the urgency without claiming failure. Wuille disagreed with Andresen's view on competition for block space, proposing the development of a fee market. Timón appreciated a more reasonable position from Andresen and urged both sides to focus on resolving questions. Discussions touched upon the harm caused by hitting the block size limit and the need for criteria based on mining centralization. Simulating different block sizes was proposed to make informed decisions.The issue of mining centralization and block size limits were also discussed. Timón argued for a block size limit to limit mining centralization, while Hector Chu challenged Timón to provide a counter-example. Discussions highlighted the complexities surrounding block size limits and their impact on mining centralization. In a discussion about the Bitcoin network, the need for concrete timelines and larger blocks was acknowledged. Bryan Bishop proposed verifying summarizing transactions, and Andresen proposed increasing the block size limit to 2MB by 2021.Pieter proposed increasing the maximum block size to 2MB, Suhas Daftuar approved pending further thoughts, and Jameson Lopp discussed trade-offs between decentralization and growth. Timón preferred a more limited solution before adapting the block size. A post recommended waiting for improvements before adjusting the block size, expressing a preference for a more limited solution. Wuille shared a proposal for long-term scalability, requesting comments from the community.Overall, the discussions revolved around scalability in the Bitcoin network, focusing on the block size limit and potential solutions for long-term scalability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Block-size-hard-fork.xml b/static/bitcoin-dev/Aug_2015/combined_Block-size-hard-fork.xml index 3f8cb9b6c7..a0de18cf65 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Block-size-hard-fork.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Block-size-hard-fork.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block size hard fork - 2023-08-01T14:52:32.050512+00:00 + 2025-10-11T22:06:22.798689+00:00 + python-feedgen Hector Chu 2015-08-01 08:43:56+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Block size hard fork - 2023-08-01T14:52:32.050512+00:00 + 2025-10-11T22:06:22.798841+00:00 - In an email conversation between Gregory Maxwell and another individual, the possibility of intentionally causing a split in a blockchain was discussed. While intentionally splitting coins between separate forks is possible, there seems to be little incentive to do so since the coins would lose their fungibility and thus be worth less. However, it was noted that new coins and fees would be issued on both chains, which could make it difficult to avoid this fact.Transactions associated with one chain can only exist exclusively on that chain. Someone with single-chain coins can pay small amounts to many users to get their wallets to consume them and make more transactions single chain-only. Migration of miners to the bigger chain was suggested to depend on higher profits due to a higher volume of fees. However, this migration remark was considered oversimplified, as demonstrated by a hypothetical scenario where someone releases software to reassign ownership of a million unmoved coins to themselves at a certain block and then makes transactions to pay high fees. In this case, miners may not immediately move over as they would need to see the new chain gain acceptance through higher trading volume.In a bitcoin-dev email thread, Hector Chu pointed out that there is no connection between transactions and the blocks they appear in. Transactions can be received and accepted in different orders by various nodes. The blockchain resolves potential conflicting transactions by providing a globally agreed total ordering as soon as one of the forks accepts a different transaction in a conflicting set. A split occurs when transactions exist on one chain but cannot exist on the other due to the acceptance of different transactions in a conflicting set. It is possible to intentionally produce such a split to separate the existence of coins onto separate forks, similar to performing a reorg-and-respend attack on a single blockchain.New coins and fees are issued on both chains, becoming spendable after 100 blocks, and any transaction spending them can exist exclusively on one chain. Additionally, any transaction whose casual history extends from the above cases can exist only on one chain. This means that someone with single-chain coins (via a conflict or from coinbase outputs) can pay a small amount to many users to get their wallets to consume them and make more transactions single chain-only.Hector Chu also mentioned that migrating miners to a bigger chain in search of higher profits due to a higher volume of fees is an oversimplification. He provided an example where he could release a version of the software programmed to reassign ownership of a million of the earliest created unmoved coins to him at block 400k and then make a transaction to pay 5 coin/block in fees. In this situation, it may pay more in fees, but whether miners would move to this chain remains uncertain.A forum post highlighted that the discussion surrounding the potential fork of the blockchain due to larger blocks has not addressed what will happen when it occurs. The writer believes that the issue is not as significant as some suggest because transactions on the smaller chain can still appear on the larger chain, and there is nothing tying transactions to the blocks they appear in. However, miners are likely to move to the larger chain to seek higher profits due to increased fees. To prevent this from occurring, changes to the serialized format of transactions on the smaller chain have been suggested so that signatures are no longer valid across chains. Selling off the coins of the losing chain has been proposed, but doing so in the short term is not advisable as these transactions will still appear on the larger chain. 2015-08-01T08:43:56+00:00 + In an email conversation between Gregory Maxwell and another individual, the possibility of intentionally causing a split in a blockchain was discussed. While intentionally splitting coins between separate forks is possible, there seems to be little incentive to do so since the coins would lose their fungibility and thus be worth less. However, it was noted that new coins and fees would be issued on both chains, which could make it difficult to avoid this fact.Transactions associated with one chain can only exist exclusively on that chain. Someone with single-chain coins can pay small amounts to many users to get their wallets to consume them and make more transactions single chain-only. Migration of miners to the bigger chain was suggested to depend on higher profits due to a higher volume of fees. However, this migration remark was considered oversimplified, as demonstrated by a hypothetical scenario where someone releases software to reassign ownership of a million unmoved coins to themselves at a certain block and then makes transactions to pay high fees. In this case, miners may not immediately move over as they would need to see the new chain gain acceptance through higher trading volume.In a bitcoin-dev email thread, Hector Chu pointed out that there is no connection between transactions and the blocks they appear in. Transactions can be received and accepted in different orders by various nodes. The blockchain resolves potential conflicting transactions by providing a globally agreed total ordering as soon as one of the forks accepts a different transaction in a conflicting set. A split occurs when transactions exist on one chain but cannot exist on the other due to the acceptance of different transactions in a conflicting set. It is possible to intentionally produce such a split to separate the existence of coins onto separate forks, similar to performing a reorg-and-respend attack on a single blockchain.New coins and fees are issued on both chains, becoming spendable after 100 blocks, and any transaction spending them can exist exclusively on one chain. Additionally, any transaction whose casual history extends from the above cases can exist only on one chain. This means that someone with single-chain coins (via a conflict or from coinbase outputs) can pay a small amount to many users to get their wallets to consume them and make more transactions single chain-only.Hector Chu also mentioned that migrating miners to a bigger chain in search of higher profits due to a higher volume of fees is an oversimplification. He provided an example where he could release a version of the software programmed to reassign ownership of a million of the earliest created unmoved coins to him at block 400k and then make a transaction to pay 5 coin/block in fees. In this situation, it may pay more in fees, but whether miners would move to this chain remains uncertain.A forum post highlighted that the discussion surrounding the potential fork of the blockchain due to larger blocks has not addressed what will happen when it occurs. The writer believes that the issue is not as significant as some suggest because transactions on the smaller chain can still appear on the larger chain, and there is nothing tying transactions to the blocks they appear in. However, miners are likely to move to the larger chain to seek higher profits due to increased fees. To prevent this from occurring, changes to the serialized format of transactions on the smaller chain have been suggested so that signatures are no longer valid across chains. Selling off the coins of the losing chain has been proposed, but doing so in the short term is not advisable as these transactions will still appear on the larger chain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Block-size-implementation-using-Game-Theory.xml b/static/bitcoin-dev/Aug_2015/combined_Block-size-implementation-using-Game-Theory.xml index badd468bb6..aefeb07524 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Block-size-implementation-using-Game-Theory.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Block-size-implementation-using-Game-Theory.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block size implementation using Game Theory - 2023-08-01T14:59:05.195080+00:00 + 2025-10-11T22:06:41.938162+00:00 + python-feedgen jl2012 at xbt.hk 2015-08-07 05:20:21+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Block size implementation using Game Theory - 2023-08-01T14:59:05.195080+00:00 + 2025-10-11T22:06:41.938428+00:00 - In 2015, Wes Green proposed a game theory-based solution to the block size issue in Bitcoin. The suggestion was to allow miners to double the block size at any time but penalize them by taking a percentage increase in rewards from both fees and normal rewards. The remaining amount would then be rewarded to the next miner who finds a block. The proposal left the algorithm programming up to the miner.According to one response to Green's proposal, the equilibrium for the game would be to maintain the same block size. The response explained that if there were a significant backlog of fee-paying transactions with stable fees per MB, miners could either receive a fixed reward or increase the block size and earn a higher reward, factoring in the penalty. The response also suggested that having more reasonable scaling parameters would make it easier to create a fee market for Bitcoin transactions.The response provided some assumptions on fee levels to illustrate the system. For example, with 1MB blocks, free transactions and no fees would be expected. With 8MB blocks and people paying 0.1 mBTC/kB in fees, 0.8 BTC in fees per block would be acceptable. The conclusion was that miners would want to choose parameters that clear the market for block space at a price determined by their costs. However, the current problems identified were that the cost parameter was too high, resulting in low fees, and the capacity parameter was too low, causing some transactions to be dropped.The proposal aimed to resolve Bitcoin's block size issue using game theory instead of relying on projected percentage growth of bandwidth speeds and other technical factors. It suggested allowing miners to increase the block size when there is organic growth in the network, while dealing with spam attacks as they currently are. The penalty associated with increasing the block size would encourage slow growth while preserving return on equity. Additionally, this system would incentivize miners to pay attention to the blockchain size and prevent it from growing too quickly. It would also force miners to hold the entire blockchain, adding a gamification element to the process. 2015-08-07T05:20:21+00:00 + In 2015, Wes Green proposed a game theory-based solution to the block size issue in Bitcoin. The suggestion was to allow miners to double the block size at any time but penalize them by taking a percentage increase in rewards from both fees and normal rewards. The remaining amount would then be rewarded to the next miner who finds a block. The proposal left the algorithm programming up to the miner.According to one response to Green's proposal, the equilibrium for the game would be to maintain the same block size. The response explained that if there were a significant backlog of fee-paying transactions with stable fees per MB, miners could either receive a fixed reward or increase the block size and earn a higher reward, factoring in the penalty. The response also suggested that having more reasonable scaling parameters would make it easier to create a fee market for Bitcoin transactions.The response provided some assumptions on fee levels to illustrate the system. For example, with 1MB blocks, free transactions and no fees would be expected. With 8MB blocks and people paying 0.1 mBTC/kB in fees, 0.8 BTC in fees per block would be acceptable. The conclusion was that miners would want to choose parameters that clear the market for block space at a price determined by their costs. However, the current problems identified were that the cost parameter was too high, resulting in low fees, and the capacity parameter was too low, causing some transactions to be dropped.The proposal aimed to resolve Bitcoin's block size issue using game theory instead of relying on projected percentage growth of bandwidth speeds and other technical factors. It suggested allowing miners to increase the block size when there is organic growth in the network, while dealing with spam attacks as they currently are. The penalty associated with increasing the block size would encourage slow growth while preserving return on equity. Additionally, this system would incentivize miners to pay attention to the blockchain size and prevent it from growing too quickly. It would also force miners to hold the entire blockchain, adding a gamification element to the process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Block-size-possible-solution-to-set-minimum-size.xml b/static/bitcoin-dev/Aug_2015/combined_Block-size-possible-solution-to-set-minimum-size.xml index 0ee271df59..b4fb445bd5 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Block-size-possible-solution-to-set-minimum-size.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Block-size-possible-solution-to-set-minimum-size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block size possible solution - to set minimum size - 2023-08-01T15:39:26.658333+00:00 + 2025-10-11T22:07:22.328779+00:00 + python-feedgen Bdimych Bdimych 2015-08-23 14:04:27+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Block size possible solution - to set minimum size - 2023-08-01T15:39:26.658333+00:00 + 2025-10-11T22:07:22.328926+00:00 - In a discussion on the bitcoin-dev mailing list, Bdimych Bdimych raised concerns about the CoreXT fork and its vulnerability to double spending. He suggested implementing a minimum block size to prevent this issue and proposed filling the free space with zeroes and compressing them. However, Jorge Timón responded that a minimum block size would not address the problems associated with schism hardforks. He explained that miners could easily cheat the system by paying themselves multiple times within the same block, as long as they have a single matured satoshi. Jorge Timón provided a link to a previous post elaborating on this point.The main problem with the CoreXT fork is the potential for double spending, which occurs when a user spends their coins within an 8 MB block that the Core software does not accept. To address this issue, Bdimych Bdimych suggested implementing a minimum block size. This proposal involved filling the remaining free space in the block with zeroes and compressing them. While this solution may seem viable, it does not effectively tackle the challenges posed by schism hardforks.Jorge Timón argued that a minimum block size would not prevent miners from cheating the system. They could simply pay themselves multiple times within the same block, adhering to the minimum size requirement without risking anything. This flaw undermines the effectiveness of implementing a minimum block size as a preventive measure against double spending.It is worth noting that before putting forth proposals or inquiries, it is advisable to search for previous posts to ensure that the topic has not been previously discussed or addressed. By doing so, one can avoid redundancy and contribute more effectively to the conversation.In summary, the CoreXT fork faces the issue of double spending, whereby coins spent using the XT software are accepted in an 8 MB block but rejected by the Core software. To mitigate this problem, Bdimych Bdimych suggests setting a minimum block size and filling the remaining space with compressed zeroes. However, Jorge Timón argues that a minimum block size does not address the challenges of schism hardforks and can be easily exploited by miners. It is essential to conduct thorough research before participating in discussions to avoid repetition and maximize contributions. 2015-08-23T14:04:27+00:00 + In a discussion on the bitcoin-dev mailing list, Bdimych Bdimych raised concerns about the CoreXT fork and its vulnerability to double spending. He suggested implementing a minimum block size to prevent this issue and proposed filling the free space with zeroes and compressing them. However, Jorge Timón responded that a minimum block size would not address the problems associated with schism hardforks. He explained that miners could easily cheat the system by paying themselves multiple times within the same block, as long as they have a single matured satoshi. Jorge Timón provided a link to a previous post elaborating on this point.The main problem with the CoreXT fork is the potential for double spending, which occurs when a user spends their coins within an 8 MB block that the Core software does not accept. To address this issue, Bdimych Bdimych suggested implementing a minimum block size. This proposal involved filling the remaining free space in the block with zeroes and compressing them. While this solution may seem viable, it does not effectively tackle the challenges posed by schism hardforks.Jorge Timón argued that a minimum block size would not prevent miners from cheating the system. They could simply pay themselves multiple times within the same block, adhering to the minimum size requirement without risking anything. This flaw undermines the effectiveness of implementing a minimum block size as a preventive measure against double spending.It is worth noting that before putting forth proposals or inquiries, it is advisable to search for previous posts to ensure that the topic has not been previously discussed or addressed. By doing so, one can avoid redundancy and contribute more effectively to the conversation.In summary, the CoreXT fork faces the issue of double spending, whereby coins spent using the XT software are accepted in an 8 MB block but rejected by the Core software. To mitigate this problem, Bdimych Bdimych suggests setting a minimum block size and filling the remaining space with compressed zeroes. However, Jorge Timón argues that a minimum block size does not address the challenges of schism hardforks and can be easily exploited by miners. It is essential to conduct thorough research before participating in discussions to avoid repetition and maximize contributions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_CFP-Bitcoin-Scalability-Workshop-Sept-12-13-Montreal-Canada.xml b/static/bitcoin-dev/Aug_2015/combined_CFP-Bitcoin-Scalability-Workshop-Sept-12-13-Montreal-Canada.xml index 578f2f0c0e..93587c047b 100644 --- a/static/bitcoin-dev/Aug_2015/combined_CFP-Bitcoin-Scalability-Workshop-Sept-12-13-Montreal-Canada.xml +++ b/static/bitcoin-dev/Aug_2015/combined_CFP-Bitcoin-Scalability-Workshop-Sept-12-13-Montreal-Canada.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CFP Bitcoin Scalability Workshop (Sept 12-13), Montreal Canada - 2023-08-01T15:06:44.654913+00:00 + 2025-10-11T22:05:27.546139+00:00 + python-feedgen Pindar Wong 2015-08-14 09:08:46+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - CFP Bitcoin Scalability Workshop (Sept 12-13), Montreal Canada - 2023-08-01T15:06:44.655913+00:00 + 2025-10-11T22:05:27.546304+00:00 - The Bitcoin development community is organizing a pair of workshops to aid the technical consensus building process and improve the scalability and decentralized nature of the Bitcoin network. The first workshop, scheduled for September 12th-13th, 2015 in Montreal, Canada, will focus on evaluating tradeoffs and requirements for proposals to scale Bitcoin beyond its current limits. The purpose of this workshop is to raise awareness of the complex issues involved, encourage further research and testing of existing proposals, and motivate future work in this area.The second workshop, tentatively planned for late November to December in Hong Kong, will specifically address block size proposals and compare different competing proposals with experimental data. This workshop aims to present and review actual proposals for scaling Bitcoin against the requirements identified in the first workshop. Both workshops will be live-streamed, and remote participation will be facilitated via IRC for online discussions and questions.Registration for the Montreal workshop begins on August 12th, with an early-bird ticket price of $150 USD until September 3rd. Independent or academic researchers can apply for travel assistance to cover airfare and hotel fees up to $1,000 per qualified presenter who intends to give a presentation. The four underwriters of the event will jointly review applications and provide the travel subsidies for qualified presenters. Sponsors are still being accepted for the workshops.The workshops aim to facilitate the Bitcoin Improvement Proposals (BIP) process and gather technical criteria, evaluate proposals, and analyze data with academic discipline and analysis. Travel, venue details, and accommodation recommendations can be found at scalingbitcoin.org. If anyone has research relevant to Bitcoin scalability, their proposal for a presentation at the Montreal workshop would be welcomed. 2015-08-14T09:08:46+00:00 + The Bitcoin development community is organizing a pair of workshops to aid the technical consensus building process and improve the scalability and decentralized nature of the Bitcoin network. The first workshop, scheduled for September 12th-13th, 2015 in Montreal, Canada, will focus on evaluating tradeoffs and requirements for proposals to scale Bitcoin beyond its current limits. The purpose of this workshop is to raise awareness of the complex issues involved, encourage further research and testing of existing proposals, and motivate future work in this area.The second workshop, tentatively planned for late November to December in Hong Kong, will specifically address block size proposals and compare different competing proposals with experimental data. This workshop aims to present and review actual proposals for scaling Bitcoin against the requirements identified in the first workshop. Both workshops will be live-streamed, and remote participation will be facilitated via IRC for online discussions and questions.Registration for the Montreal workshop begins on August 12th, with an early-bird ticket price of $150 USD until September 3rd. Independent or academic researchers can apply for travel assistance to cover airfare and hotel fees up to $1,000 per qualified presenter who intends to give a presentation. The four underwriters of the event will jointly review applications and provide the travel subsidies for qualified presenters. Sponsors are still being accepted for the workshops.The workshops aim to facilitate the Bitcoin Improvement Proposals (BIP) process and gather technical criteria, evaluate proposals, and analyze data with academic discipline and analysis. Travel, venue details, and accommodation recommendations can be found at scalingbitcoin.org. If anyone has research relevant to Bitcoin scalability, their proposal for a presentation at the Montreal workshop would be welcomed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_CLTV-CSV-etc-deployment-considerations-due-to-XT-Not-BitcoinXT-miners.xml b/static/bitcoin-dev/Aug_2015/combined_CLTV-CSV-etc-deployment-considerations-due-to-XT-Not-BitcoinXT-miners.xml index a28a35d75e..8dde7f8223 100644 --- a/static/bitcoin-dev/Aug_2015/combined_CLTV-CSV-etc-deployment-considerations-due-to-XT-Not-BitcoinXT-miners.xml +++ b/static/bitcoin-dev/Aug_2015/combined_CLTV-CSV-etc-deployment-considerations-due-to-XT-Not-BitcoinXT-miners.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners - 2023-08-01T15:32:53.245258+00:00 + 2025-10-11T22:06:37.689704+00:00 + python-feedgen Btc Drak 2015-08-27 22:11:10+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners - 2023-08-01T15:32:53.246258+00:00 + 2025-10-11T22:06:37.689855+00:00 - In August 2015, a discussion took place on the Bitcoin-dev mailing list regarding the implementation of nVersion mask and IsSuperMajority() in the Bitcoin protocol. The proposal aimed to address issues related to different miners and soft-fork warnings. It suggested masking the nVersion bits set by XT/Not-Bitcoin-XT miners before applying the IsSuperMajority() logic. This would allow CLTV/CSV/etc. miners running Bitcoin Core to create blocks with nVersion=8, while XT/Not-Bitcoin-XT miners would advertise blocks that do not trigger the soft-fork. The proposal also mentioned the possibility of using the same masking technique for future soft forks. One developer proposed masking all bits except the 4th bit to enable concurrent voting on other fork proposals.It was clarified during the conversation that the masking would only be applied during the voting stage. Once the soft fork is fully enforced with 95% support, the nVersion will simply be >=8 without any masking. Due to the seriousness of the issues caused by Bitcoin XT, it was suggested that the original proposal should be converted into an informational BIP. As a result, BIPS 112 and 113 were modified to reflect the amended deployment strategy.Another aspect discussed was the use of nVersion bits to signal support for specific upgrade forks in the Bitcoin protocol. One proposal suggested using nVersion & 0x8 as a signal for support while keeping the consensus rule as nVersion >= 4. However, concerns were raised about potential conflicts between upgrades and the need to reject blocks with versions lower than 8 if a new upgrade is accepted by a majority of nodes. A possible solution was proposed, involving setting N (the height at which the rule is active) one year from now or so, and giving a period of time after lock that bit 8 will be kept and another period where it is guaranteed to be zero.The implementation of the proposed CLTV, CSV, etc. soft-forks faced challenges due to the presence of XT and Not-Bitcoin-XT miners. These miners produced blocks with nVersion=0x20000007, which would falsely trigger the previously suggested implementation using the IsSuperMajority() mechanism and nVersion=4 blocks. Furthermore, the XT/Not-Bitcoin-XT software lacked the implementation of fork deadlines, making it difficult to fully support the nVersion soft-fork mechanism.To address these issues, three options for the deployment of CLTV/CSV/etc. were proposed. The first option, using plain IsSuperMajority() with nVersion=4, was deemed high risk and ruled out immediately. The second option, nVersion mask with IsSuperMajority(), was recommended. This option involved masking away the nVersion bits set by XT/Not-Bitcoin-XT miners before applying the standard IsSuperMajority() logic. CLTV/CSV/etc. miners running Bitcoin Core would create blocks with nVersion=8, while XT/Not-Bitcoin-XT miners would advertise blocks that do not trigger the soft-fork. This solution allowed for soft-fork warnings to be triggered for both XT/Not-Bitcoin-XT blocks and future nVersion bits implementations, with the highest known version remaining as nVersion=8.The most complex option for deployment was the full nVersion bits implementation using flag bit #4 to trigger the fork. Compliant miners would advertise 0x20000008 initially, followed by 0x20000000 once the fork had triggered. The lowest three bits would be unusable for forks for some time, but they could eventually be recovered as XT/Not-Bitcoin-XT mining ceased.Overall, the focus should be on the proposed featureset rather than the deployment method. It is believed that versionbits, once implemented, will be essential for rolling out multiple features in parallel without waiting for activation and enforcement each time. In the absence of versionbits, the recommended approach is to use the nVersion mask with IsSuperMajority() to address the complications caused by XT and Not-Bitcoin-XT miners. 2015-08-27T22:11:10+00:00 + In August 2015, a discussion took place on the Bitcoin-dev mailing list regarding the implementation of nVersion mask and IsSuperMajority() in the Bitcoin protocol. The proposal aimed to address issues related to different miners and soft-fork warnings. It suggested masking the nVersion bits set by XT/Not-Bitcoin-XT miners before applying the IsSuperMajority() logic. This would allow CLTV/CSV/etc. miners running Bitcoin Core to create blocks with nVersion=8, while XT/Not-Bitcoin-XT miners would advertise blocks that do not trigger the soft-fork. The proposal also mentioned the possibility of using the same masking technique for future soft forks. One developer proposed masking all bits except the 4th bit to enable concurrent voting on other fork proposals.It was clarified during the conversation that the masking would only be applied during the voting stage. Once the soft fork is fully enforced with 95% support, the nVersion will simply be >=8 without any masking. Due to the seriousness of the issues caused by Bitcoin XT, it was suggested that the original proposal should be converted into an informational BIP. As a result, BIPS 112 and 113 were modified to reflect the amended deployment strategy.Another aspect discussed was the use of nVersion bits to signal support for specific upgrade forks in the Bitcoin protocol. One proposal suggested using nVersion & 0x8 as a signal for support while keeping the consensus rule as nVersion >= 4. However, concerns were raised about potential conflicts between upgrades and the need to reject blocks with versions lower than 8 if a new upgrade is accepted by a majority of nodes. A possible solution was proposed, involving setting N (the height at which the rule is active) one year from now or so, and giving a period of time after lock that bit 8 will be kept and another period where it is guaranteed to be zero.The implementation of the proposed CLTV, CSV, etc. soft-forks faced challenges due to the presence of XT and Not-Bitcoin-XT miners. These miners produced blocks with nVersion=0x20000007, which would falsely trigger the previously suggested implementation using the IsSuperMajority() mechanism and nVersion=4 blocks. Furthermore, the XT/Not-Bitcoin-XT software lacked the implementation of fork deadlines, making it difficult to fully support the nVersion soft-fork mechanism.To address these issues, three options for the deployment of CLTV/CSV/etc. were proposed. The first option, using plain IsSuperMajority() with nVersion=4, was deemed high risk and ruled out immediately. The second option, nVersion mask with IsSuperMajority(), was recommended. This option involved masking away the nVersion bits set by XT/Not-Bitcoin-XT miners before applying the standard IsSuperMajority() logic. CLTV/CSV/etc. miners running Bitcoin Core would create blocks with nVersion=8, while XT/Not-Bitcoin-XT miners would advertise blocks that do not trigger the soft-fork. This solution allowed for soft-fork warnings to be triggered for both XT/Not-Bitcoin-XT blocks and future nVersion bits implementations, with the highest known version remaining as nVersion=8.The most complex option for deployment was the full nVersion bits implementation using flag bit #4 to trigger the fork. Compliant miners would advertise 0x20000008 initially, followed by 0x20000000 once the fork had triggered. The lowest three bits would be unusable for forks for some time, but they could eventually be recovered as XT/Not-Bitcoin-XT mining ceased.Overall, the focus should be on the proposed featureset rather than the deployment method. It is believed that versionbits, once implemented, will be essential for rolling out multiple features in parallel without waiting for activation and enforcement each time. In the absence of versionbits, the recommended approach is to use the nVersion mask with IsSuperMajority() to address the complications caused by XT and Not-Bitcoin-XT miners. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Censorship.xml b/static/bitcoin-dev/Aug_2015/combined_Censorship.xml index 9d45787136..633f0b091f 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Censorship.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Censorship.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Censorship - 2023-08-01T15:37:22.943504+00:00 + 2025-10-11T22:07:03.183060+00:00 + python-feedgen hurricanewarn1 at aol.com 2015-08-31 17:00:15+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Censorship - 2023-08-01T15:37:22.943504+00:00 + 2025-10-11T22:07:03.183238+00:00 - The email thread discusses the creation of a decentralized forum that integrates the Bitcoin blockchain with every post. The sender proposes a system where most data is stored in a hash reference table and shared via a torrent-esque system to make it censorship-resistant. They express interest in contributing to the development of decentralized communication mechanisms and advocate for user-controlled moderation and filters. The centralization and censorship of the Bitcoin community are identified as inhibiting its growth, and the need for a heavily moderated forum is emphasized. The relevance of discussing cryptocurrency in technical and academic settings is also debated, with some arguing for dedicated platforms for such discussions.Another member of the bitcoin-dev mailing list expresses disappointment in what they perceive as a one-sided perspective on the platform. They argue that meta-discussions of communities have no place on the list and encourage users to create their own spaces for discussion. The topic of discussing the Bitcoin split in a technical and academic mailing list is debated, with one user arguing for a separate general discussion forum and another emphasizing the list's focus on technical discussions related to Bitcoin.The context also mentions a forum that is under attack by an unknown attacker, but despite this, people continue to post on the forum to keep it alive. The importance of the forum as a safe space for free expression is highlighted, and the resilience of the community is praised. The need for decentralized forums and the challenges they face, such as spam, abuse, overloading, and attacks, are acknowledged.The conversation also touches on the issue of centralization and censorship in popular Bitcoin forums like Reddit and Bitcointalk. The control exerted by a few individuals and the manipulation of discussions are criticized. The creation of a decentralized forum without rules or bans is proposed as a solution to protect the decentralized spirit of the Bitcoin community.The email thread raises questions about the relevance of cryptocurrency discussions in technical and academic settings and the need for dedicated platforms for such debates. It also highlights concerns about the centralization and censorship of popular Bitcoin forums and proposes solutions to create decentralized and heavily moderated forums. 2015-08-31T17:00:15+00:00 + The email thread discusses the creation of a decentralized forum that integrates the Bitcoin blockchain with every post. The sender proposes a system where most data is stored in a hash reference table and shared via a torrent-esque system to make it censorship-resistant. They express interest in contributing to the development of decentralized communication mechanisms and advocate for user-controlled moderation and filters. The centralization and censorship of the Bitcoin community are identified as inhibiting its growth, and the need for a heavily moderated forum is emphasized. The relevance of discussing cryptocurrency in technical and academic settings is also debated, with some arguing for dedicated platforms for such discussions.Another member of the bitcoin-dev mailing list expresses disappointment in what they perceive as a one-sided perspective on the platform. They argue that meta-discussions of communities have no place on the list and encourage users to create their own spaces for discussion. The topic of discussing the Bitcoin split in a technical and academic mailing list is debated, with one user arguing for a separate general discussion forum and another emphasizing the list's focus on technical discussions related to Bitcoin.The context also mentions a forum that is under attack by an unknown attacker, but despite this, people continue to post on the forum to keep it alive. The importance of the forum as a safe space for free expression is highlighted, and the resilience of the community is praised. The need for decentralized forums and the challenges they face, such as spam, abuse, overloading, and attacks, are acknowledged.The conversation also touches on the issue of centralization and censorship in popular Bitcoin forums like Reddit and Bitcointalk. The control exerted by a few individuals and the manipulation of discussions are criticized. The creation of a decentralized forum without rules or bans is proposed as a solution to protect the decentralized spirit of the Bitcoin community.The email thread raises questions about the relevance of cryptocurrency discussions in technical and academic settings and the need for dedicated platforms for such debates. It also highlights concerns about the centralization and censorship of popular Bitcoin forums and proposes solutions to create decentralized and heavily moderated forums. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Consensus-based-block-size-retargeting-algorithm-draft-.xml b/static/bitcoin-dev/Aug_2015/combined_Consensus-based-block-size-retargeting-algorithm-draft-.xml index 2624f8a9ff..a414b5ce6b 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Consensus-based-block-size-retargeting-algorithm-draft-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Consensus-based-block-size-retargeting-algorithm-draft-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Consensus based block size retargeting algorithm (draft) - 2023-08-01T15:38:57.010447+00:00 + 2025-10-11T22:05:04.142785+00:00 + python-feedgen jl2012 at xbt.hk 2015-08-31 18:50:25+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Consensus based block size retargeting algorithm (draft) - 2023-08-01T15:38:57.010447+00:00 + 2025-10-11T22:05:04.143007+00:00 - In August 2015, discussions and proposals were made regarding the block size increase in Bitcoin. Mark Friedenbach opposed giving miners the power to decide on the consensus rule for limiting mining centralization. Chris Pacia raised concerns about a collective action problem that could arise in the block size increase proposal. Btc Drak discussed a proposal for increasing the block size limit, and Matt Whitlock raised concerns about the activation mechanism of the new consensus rule.The proposal by Btc Drak aimed to address the challenges of raising the block size limit in response to increased popularity. It suggested a hard cap on block size with the ability for miners to increase or decrease it within defined parameters. The proposal also introduced the concept of paying extra difficulty to create larger blocks and calculating the average or median of the last blocks to set the new maximum block size limit. The discussion highlighted the challenges of aligning individual miner interests with the collective interest of the Bitcoin community.Another proposal discussed in the email thread suggested a cost-based approach to increasing the block size. It started with a 1-MB limit and allowed miners to vote for a maximum 10% increase or decrease in the block size limit. The proposal required a mechanism for activation of the new consensus rule.The Consensus based block size retargeting algorithm was proposed as a democratic approach to adjusting the block size limit. It aimed to prevent easy manipulation and ensure changes are made only when necessary. Miners can vote for a block size increase, and the validity of the vote is determined by meeting a difficulty target proportional to the percentage increase voted for. The maximum allowed block size is recalculated every 2016 blocks based on the average of all votes in the last 2016 blocks. The proposal addresses concerns about predetermined block size increases and the need for Bitcoin to be able to respond quickly to raising the block size limit.Overall, these discussions and proposals were focused on addressing mining centralization concerns, ensuring the sustainability and security of the Bitcoin network, and providing a democratic approach to adjusting the block size limit. 2015-08-31T18:50:25+00:00 + In August 2015, discussions and proposals were made regarding the block size increase in Bitcoin. Mark Friedenbach opposed giving miners the power to decide on the consensus rule for limiting mining centralization. Chris Pacia raised concerns about a collective action problem that could arise in the block size increase proposal. Btc Drak discussed a proposal for increasing the block size limit, and Matt Whitlock raised concerns about the activation mechanism of the new consensus rule.The proposal by Btc Drak aimed to address the challenges of raising the block size limit in response to increased popularity. It suggested a hard cap on block size with the ability for miners to increase or decrease it within defined parameters. The proposal also introduced the concept of paying extra difficulty to create larger blocks and calculating the average or median of the last blocks to set the new maximum block size limit. The discussion highlighted the challenges of aligning individual miner interests with the collective interest of the Bitcoin community.Another proposal discussed in the email thread suggested a cost-based approach to increasing the block size. It started with a 1-MB limit and allowed miners to vote for a maximum 10% increase or decrease in the block size limit. The proposal required a mechanism for activation of the new consensus rule.The Consensus based block size retargeting algorithm was proposed as a democratic approach to adjusting the block size limit. It aimed to prevent easy manipulation and ensure changes are made only when necessary. Miners can vote for a block size increase, and the validity of the vote is determined by meeting a difficulty target proportional to the percentage increase voted for. The maximum allowed block size is recalculated every 2016 blocks based on the average of all votes in the last 2016 blocks. The proposal addresses concerns about predetermined block size increases and the need for Bitcoin to be able to respond quickly to raising the block size limit.Overall, these discussions and proposals were focused on addressing mining centralization concerns, ensuring the sustainability and security of the Bitcoin network, and providing a democratic approach to adjusting the block size limit. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Consensus-fork-activation-thresholds-Block-nTime-vs-median-time-vs-block-nHeight.xml b/static/bitcoin-dev/Aug_2015/combined_Consensus-fork-activation-thresholds-Block-nTime-vs-median-time-vs-block-nHeight.xml index 6a7699197c..9a5b6d7550 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Consensus-fork-activation-thresholds-Block-nTime-vs-median-time-vs-block-nHeight.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Consensus-fork-activation-thresholds-Block-nTime-vs-median-time-vs-block-nHeight.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight - 2023-08-01T14:42:12.987100+00:00 + 2025-10-11T22:05:12.646271+00:00 + python-feedgen Jorge Timón 2015-08-05 19:29:41+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight - 2023-08-01T14:42:12.987100+00:00 + 2025-10-11T22:05:12.646443+00:00 - In a discussion on the security of bip102, Jorge Timón raises the question of whether miners' upgrade confirmation is necessary for uncontroversial hard forks. He suggests that without a strong supermajority of miner support, the fork risks attack and proposes requiring 95% approval as a minimum safety requirement. However, there is disagreement on this point. Peter Todd clarifies that a strong supermajority of miner support is needed to prevent attacks and highlights the option for miners to defeat forks without their approval, such as creating their own fork with a new consensus algorithm or attacking the unwanted chain. In August 2015, Jorge Timón sends a message to the bitcoin-dev mailing list discussing the issue of miners' upgrade confirmation for uncontroversial hard forks. The message emphasizes the need for a strong supermajority of miner support to prevent attacks and suggests requiring 95% approval as a minimum safety requirement. It also mentions Hearn's proposal of using centralized checkpoints to override PoW consensus but raises legal concerns about this option. The message suggests that miners have various options to defeat forks without their approval, including creating their own fork with a new consensus algorithm that requires them to prove they're attacking the unwanted chain. The message cites Garzik's recent 2MB blocks proposal as an example of such a design.In an email conversation, Gavin Andresen proposes using the version and timestamp fields in the block header as the simplest and best option for validating blocks. He explains that this option has advantages such as being available to SPV nodes with no change to the network protocol and allowing parallel and independent block validation. However, it has the disadvantage of not being monotonically increasing. Andresen dismisses discussions about transactions in the memory pool as a distraction and points out that blockchain reorganizations can affect the validity of transactions in the memory pool. He suggests that either median time or block timestamp can be used, but he dislikes using block height due to the uncertainty of knowing the next block time.The author discusses the challenges of defining thresholds for consensus fork activation and presents three options: block.nTime, median time, and block.nHeight. The author argues that block.nHeight's disadvantage is the least problematic but acknowledges that others may disagree. They emphasize the need for a solid criteria to decide which option to use. The author also discusses the combination of a threshold with miners' "voting" and the issues this can create when not being monotonic. Examples are provided for using height and median time to address this problem. The author further explains the example of an emergency consensus fork where the previous block index may not be available. Additionally, they present a scenario of a hardfork allowing miners to create bigger blocks based on transactions reducing the size of the UTXO. The author concludes by suggesting the establishment of a uniform threshold mechanism rather than relying on the three options depending on the fork type, advocating for a more generic solution applicable to any consensus fork. 2015-08-05T19:29:41+00:00 + In a discussion on the security of bip102, Jorge Timón raises the question of whether miners' upgrade confirmation is necessary for uncontroversial hard forks. He suggests that without a strong supermajority of miner support, the fork risks attack and proposes requiring 95% approval as a minimum safety requirement. However, there is disagreement on this point. Peter Todd clarifies that a strong supermajority of miner support is needed to prevent attacks and highlights the option for miners to defeat forks without their approval, such as creating their own fork with a new consensus algorithm or attacking the unwanted chain. In August 2015, Jorge Timón sends a message to the bitcoin-dev mailing list discussing the issue of miners' upgrade confirmation for uncontroversial hard forks. The message emphasizes the need for a strong supermajority of miner support to prevent attacks and suggests requiring 95% approval as a minimum safety requirement. It also mentions Hearn's proposal of using centralized checkpoints to override PoW consensus but raises legal concerns about this option. The message suggests that miners have various options to defeat forks without their approval, including creating their own fork with a new consensus algorithm that requires them to prove they're attacking the unwanted chain. The message cites Garzik's recent 2MB blocks proposal as an example of such a design.In an email conversation, Gavin Andresen proposes using the version and timestamp fields in the block header as the simplest and best option for validating blocks. He explains that this option has advantages such as being available to SPV nodes with no change to the network protocol and allowing parallel and independent block validation. However, it has the disadvantage of not being monotonically increasing. Andresen dismisses discussions about transactions in the memory pool as a distraction and points out that blockchain reorganizations can affect the validity of transactions in the memory pool. He suggests that either median time or block timestamp can be used, but he dislikes using block height due to the uncertainty of knowing the next block time.The author discusses the challenges of defining thresholds for consensus fork activation and presents three options: block.nTime, median time, and block.nHeight. The author argues that block.nHeight's disadvantage is the least problematic but acknowledges that others may disagree. They emphasize the need for a solid criteria to decide which option to use. The author also discusses the combination of a threshold with miners' "voting" and the issues this can create when not being monotonic. Examples are provided for using height and median time to address this problem. The author further explains the example of an emergency consensus fork where the previous block index may not be available. Additionally, they present a scenario of a hardfork allowing miners to create bigger blocks based on transactions reducing the size of the UTXO. The author concludes by suggesting the establishment of a uniform threshold mechanism rather than relying on the three options depending on the fork type, advocating for a more generic solution applicable to any consensus fork. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Core-Devs-can-you-share-your-thoughts-about-all-BIPs-on-this-website-.xml b/static/bitcoin-dev/Aug_2015/combined_Core-Devs-can-you-share-your-thoughts-about-all-BIPs-on-this-website-.xml index 5423922a62..53369c5d89 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Core-Devs-can-you-share-your-thoughts-about-all-BIPs-on-this-website-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Core-Devs-can-you-share-your-thoughts-about-all-BIPs-on-this-website-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Core Devs : can you share your thoughts about all BIPs on this website ? - 2023-08-01T15:31:39.467130+00:00 + 2025-10-11T22:06:56.809562+00:00 + python-feedgen odinn 2015-08-22 03:02:44+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Core Devs : can you share your thoughts about all BIPs on this website ? - 2023-08-01T15:31:39.467130+00:00 + 2025-10-11T22:06:56.809706+00:00 - The debate on increasing the block size of Bitcoin continues, with Antpool expressing support for an increase and willingness to switch to XT if a majority had switched. However, concerns have been raised about the influence of the Chinese state on Chinese mining and how it might pressure miners to adopt XT. It is recommended that people do not use XT and instead work towards developing consensus on alternative proposals such as BIP 100.The conversation revolves around the implications of capping the block size at 1MB, with one side arguing that it restricts the number of active users and harms the price of Bitcoin, while the other side believes that a relative tight block size may not harm Bitcoin in the middle-term. Will Madden expresses concerns about keeping the block size at 1MB, stating that it limits the number of active users and freezes the economic incentive to mine. Oliver disagrees, stating that only experienced users directly interact with the blockchain and can handle any problems that arise.The discussion then shifts to the idea of creating an information site about current outstanding BIPs, their differences, and supporting/counter statements. The website would also include opinions from Chinese pools and other major stakeholders. Peter Todd suggests that developers should explain their threat models and what should be at the root of their thinking about the block size.A group agrees that an increase in block size is necessary, suggesting 8MB as a more technically reasonable option. Chinese mining pools also express support for an increase in block size up to 8MB but do not want to upgrade to XT. Yifu Guo suggests creating an information site about the current outstanding BIPs and including supporting and counter statements regarding these proposals. The discussion also touches on the success of a 20-year plan and the hope that the current protocol and blockchain will continue, possibly with fewer users.A proposal is made to include major stakeholders like service providers and mining pools in the information site. The need for developers to explain their threat models and what should be at the root of their thinking about the block size is emphasized. In another discussion, it is suggested that analysis and options should be laid out before making any decisions on block size. A website proposed by Nicolas Dorier aims to provide a coherent view of the pros and cons of various proposals. Users can approve or disapprove of BIPs and leave comments on the website. Concerns are raised about premature judgments and potential harm to future decision-making.In conclusion, the debate on increasing the block size of Bitcoin continues, with different opinions on the implications and best approach. Some support an increase while others have concerns about specific proposals like XT. The idea of creating an information site to gather opinions and summarize differences between proposals is suggested. The importance of developers explaining their threat models and considering the root of their thinking about the block size is emphasized. The cap of 1MB on the block size is seen as limiting the number of active users and potentially harming the price of Bitcoin. The discussion also touches on the opinions of Chinese mining pools and the need for consensus among major stakeholders.Nicolas Dorier, a contributor to the Bitcoin Core project, has developed a website that displays a chart of approvals for different Bitcoin Improvement Proposals (BIPs). The purpose of the website is to encourage community participation and contribution to the project. Users can indicate their approval or disapproval of BIPs and leave comments on the website. To ensure the credibility of contributors, PGP keys are requested.During discussions about the website, concerns were raised regarding the collection of scattered PGP keys from contributors. Eric Lombrozo suggested that anyone who has made commits to the project should have a say in this matter. The conversation also touched upon improving the website's readability by grouping core developers under a separate column called "Technical Opinion."Members of the discussion recommended adding more developers, big miners, and important figures such as Nick Szabo, Meni Rosenfeld, Charlie Lee, and Mike Hearn to the website. Some members shared their PGP public keys, while others inquired about where to find these keys. The conversation took place via email and BTC Talk.Nicolas Dorier agreed to incorporate the suggestions and requested PGP public keys from the recommended individuals. The website was accessible on Azurewebsites.net and GitHub. It was created with the intention of benefiting the community and encouraging wider participation in the Bitcoin Core project. 2015-08-22T03:02:44+00:00 + The debate on increasing the block size of Bitcoin continues, with Antpool expressing support for an increase and willingness to switch to XT if a majority had switched. However, concerns have been raised about the influence of the Chinese state on Chinese mining and how it might pressure miners to adopt XT. It is recommended that people do not use XT and instead work towards developing consensus on alternative proposals such as BIP 100.The conversation revolves around the implications of capping the block size at 1MB, with one side arguing that it restricts the number of active users and harms the price of Bitcoin, while the other side believes that a relative tight block size may not harm Bitcoin in the middle-term. Will Madden expresses concerns about keeping the block size at 1MB, stating that it limits the number of active users and freezes the economic incentive to mine. Oliver disagrees, stating that only experienced users directly interact with the blockchain and can handle any problems that arise.The discussion then shifts to the idea of creating an information site about current outstanding BIPs, their differences, and supporting/counter statements. The website would also include opinions from Chinese pools and other major stakeholders. Peter Todd suggests that developers should explain their threat models and what should be at the root of their thinking about the block size.A group agrees that an increase in block size is necessary, suggesting 8MB as a more technically reasonable option. Chinese mining pools also express support for an increase in block size up to 8MB but do not want to upgrade to XT. Yifu Guo suggests creating an information site about the current outstanding BIPs and including supporting and counter statements regarding these proposals. The discussion also touches on the success of a 20-year plan and the hope that the current protocol and blockchain will continue, possibly with fewer users.A proposal is made to include major stakeholders like service providers and mining pools in the information site. The need for developers to explain their threat models and what should be at the root of their thinking about the block size is emphasized. In another discussion, it is suggested that analysis and options should be laid out before making any decisions on block size. A website proposed by Nicolas Dorier aims to provide a coherent view of the pros and cons of various proposals. Users can approve or disapprove of BIPs and leave comments on the website. Concerns are raised about premature judgments and potential harm to future decision-making.In conclusion, the debate on increasing the block size of Bitcoin continues, with different opinions on the implications and best approach. Some support an increase while others have concerns about specific proposals like XT. The idea of creating an information site to gather opinions and summarize differences between proposals is suggested. The importance of developers explaining their threat models and considering the root of their thinking about the block size is emphasized. The cap of 1MB on the block size is seen as limiting the number of active users and potentially harming the price of Bitcoin. The discussion also touches on the opinions of Chinese mining pools and the need for consensus among major stakeholders.Nicolas Dorier, a contributor to the Bitcoin Core project, has developed a website that displays a chart of approvals for different Bitcoin Improvement Proposals (BIPs). The purpose of the website is to encourage community participation and contribution to the project. Users can indicate their approval or disapproval of BIPs and leave comments on the website. To ensure the credibility of contributors, PGP keys are requested.During discussions about the website, concerns were raised regarding the collection of scattered PGP keys from contributors. Eric Lombrozo suggested that anyone who has made commits to the project should have a say in this matter. The conversation also touched upon improving the website's readability by grouping core developers under a separate column called "Technical Opinion."Members of the discussion recommended adding more developers, big miners, and important figures such as Nick Szabo, Meni Rosenfeld, Charlie Lee, and Mike Hearn to the website. Some members shared their PGP public keys, while others inquired about where to find these keys. The conversation took place via email and BTC Talk.Nicolas Dorier agreed to incorporate the suggestions and requested PGP public keys from the recommended individuals. The website was accessible on Azurewebsites.net and GitHub. It was created with the intention of benefiting the community and encouraging wider participation in the Bitcoin Core project. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml b/static/bitcoin-dev/Aug_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml index 494e11c1d1..b7205f7d7a 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP : fixed-schedule block size increase - 2023-08-01T13:34:19.646161+00:00 + 2025-10-11T22:06:35.563792+00:00 + python-feedgen odinn 2015-08-19 03:45:47+00:00 @@ -251,13 +252,13 @@ - python-feedgen + 2 Combined summary - Draft BIP : fixed-schedule block size increase - 2023-08-01T13:34:19.647154+00:00 + 2025-10-11T22:06:35.564055+00:00 - A recent release by XT author(s) has not shown any sign of moving towards an "increasing consensus" version. However, the BIP authors are working together to create something meaningful and useful. Visualizations or graphs of miner votes on BIP 100 and BIP 101 are expected. Tier Nolan suggests making available a version of XT with only block size changes to address mining pools' concerns about its experimental nature. Additionally, there is discussion about combining BIP 100 and BIP 101 to increase consensus.In an email conversation, Tier Nolan suggested that miners vote to decide the soft limit for block size. However, one member argued against it, stating that it may lead to an anti-miner hardfork instead of a softfork. The discussion also referenced BIP99 and potential scenarios for reducing the supply.A suggestion was made to create a fourth test network with large blocks from the genesis onwards instead of replacing most of Testnet with a specialized test chain. Multiple test networks using the same code were also suggested.In a discussion on the Bitcoin-dev mailing list, Ross Nicoll suggested using a minimum height as a solution for activating hardforks. However, BIP99 recommended a minimum height plus 95% mining upgrade confirmation for uncontroversial hardforks. The activation discussion for general hardforks was inconclusive.Tier Nolan proposed making a version of Bitcoin XT with only blocksize changes available to address mining pools' concerns. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes, and the consensus measuring code could be removed. Satoshi Nakamoto's original proposal for a block height comparison could be used, and the state storing code could be eliminated by using the standard "counting" upgrade system.There is discussion about combining BIP 100 and BIP 101 to increase consensus. The proposed combined version includes a miner vote threshold, a notice period or earliest start time, a block size default target set to 1 MB, a soft limit set to 1MB, and a hard limit set to 8MB with doubling every two years. Miners could leave the 1MB limit initially, but the vote is to get the option to increase the block size. Legacy clients would remain until >80% of miners vote to raise the limit and a miner produces a >1MB block.The dismissal of a formal process in Bitcoin is criticized for not properly evaluating proposed changes. Some developers believe their knowledge makes them superior to outside experts. However, this attitude can be detrimental to Bitcoin's progress. It is suggested that a well-defined and well-documented evaluation process should be introduced to ensure the safety of proposed changes.In an email exchange, Peter Todd and Gavin Andresen discuss the impact of larger blocks on miners with poor connectivity. The suggestion to rent a server on the other side of the bottleneck is countered by concerns about insecure infrastructure. The discussion also highlights the centralizing effect of mining control and the need for proposals to counter it.Gavin Andresen promised to write a BIP after implementing the increase-the-maximum-block-size code. The discussion mentions updating contact information and upcoming events.In an email conversation, Gavin Andresen discusses the analogy of a suspension bridge with limited traffic capacity and tolls increasing as demand rises. The proposed change is to expand the bridge, but careful analysis is needed. Civil engineering teaches us not to give in to political pressure until consequences are well understood.The discussion on the Bitcoin-dev mailing list focuses on the centralizing effect of miner connectivity and its impact on block propagation. Simulations show that miners with poor connectivity are negatively affected. Suggestions to work around this include renting a server on the other side of the bottleneck, but concerns about insecure infrastructure are raised. The discussion also addresses the need for proposals to counter mining centralization.Moving averages are compared to fixed growth, but they have limitations. Gavin Andresen suggests changing the default 'target' block size to the average of the last N blocks to create healthy "fee pressure" in the system.In an email conversation, Gavin Andresen and Will discuss block size. The suggestion is made to make the lazy miners' default choice grow at a slower rate than the average, which would encourage more fee pressure in the system.In 2017, Gavin Andresen put forward a Bitcoin Improvement Proposal (BIP) to increase the maximum block size from one megabyte to 8,000,000 bytes. The proposal suggests doubling the block size every two years until it reaches 8,192,000,000 bytes. To activate this change, a hash-power supermajority vote is required. This proposal allows miners, merchants, and users running full-nodes ample time to upgrade their software to support larger blocks.It's important to note that this proposed change is a hard-forking modification to the Bitcoin protocol. Therefore, anyone running code that fully validates blocks must upgrade their software before the activation time. Failure to do so may result in rejecting a 2015-08-19T03:45:47+00:00 + A recent release by XT author(s) has not shown any sign of moving towards an "increasing consensus" version. However, the BIP authors are working together to create something meaningful and useful. Visualizations or graphs of miner votes on BIP 100 and BIP 101 are expected. Tier Nolan suggests making available a version of XT with only block size changes to address mining pools' concerns about its experimental nature. Additionally, there is discussion about combining BIP 100 and BIP 101 to increase consensus.In an email conversation, Tier Nolan suggested that miners vote to decide the soft limit for block size. However, one member argued against it, stating that it may lead to an anti-miner hardfork instead of a softfork. The discussion also referenced BIP99 and potential scenarios for reducing the supply.A suggestion was made to create a fourth test network with large blocks from the genesis onwards instead of replacing most of Testnet with a specialized test chain. Multiple test networks using the same code were also suggested.In a discussion on the Bitcoin-dev mailing list, Ross Nicoll suggested using a minimum height as a solution for activating hardforks. However, BIP99 recommended a minimum height plus 95% mining upgrade confirmation for uncontroversial hardforks. The activation discussion for general hardforks was inconclusive.Tier Nolan proposed making a version of Bitcoin XT with only blocksize changes available to address mining pools' concerns. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes, and the consensus measuring code could be removed. Satoshi Nakamoto's original proposal for a block height comparison could be used, and the state storing code could be eliminated by using the standard "counting" upgrade system.There is discussion about combining BIP 100 and BIP 101 to increase consensus. The proposed combined version includes a miner vote threshold, a notice period or earliest start time, a block size default target set to 1 MB, a soft limit set to 1MB, and a hard limit set to 8MB with doubling every two years. Miners could leave the 1MB limit initially, but the vote is to get the option to increase the block size. Legacy clients would remain until >80% of miners vote to raise the limit and a miner produces a >1MB block.The dismissal of a formal process in Bitcoin is criticized for not properly evaluating proposed changes. Some developers believe their knowledge makes them superior to outside experts. However, this attitude can be detrimental to Bitcoin's progress. It is suggested that a well-defined and well-documented evaluation process should be introduced to ensure the safety of proposed changes.In an email exchange, Peter Todd and Gavin Andresen discuss the impact of larger blocks on miners with poor connectivity. The suggestion to rent a server on the other side of the bottleneck is countered by concerns about insecure infrastructure. The discussion also highlights the centralizing effect of mining control and the need for proposals to counter it.Gavin Andresen promised to write a BIP after implementing the increase-the-maximum-block-size code. The discussion mentions updating contact information and upcoming events.In an email conversation, Gavin Andresen discusses the analogy of a suspension bridge with limited traffic capacity and tolls increasing as demand rises. The proposed change is to expand the bridge, but careful analysis is needed. Civil engineering teaches us not to give in to political pressure until consequences are well understood.The discussion on the Bitcoin-dev mailing list focuses on the centralizing effect of miner connectivity and its impact on block propagation. Simulations show that miners with poor connectivity are negatively affected. Suggestions to work around this include renting a server on the other side of the bottleneck, but concerns about insecure infrastructure are raised. The discussion also addresses the need for proposals to counter mining centralization.Moving averages are compared to fixed growth, but they have limitations. Gavin Andresen suggests changing the default 'target' block size to the average of the last N blocks to create healthy "fee pressure" in the system.In an email conversation, Gavin Andresen and Will discuss block size. The suggestion is made to make the lazy miners' default choice grow at a slower rate than the average, which would encourage more fee pressure in the system.In 2017, Gavin Andresen put forward a Bitcoin Improvement Proposal (BIP) to increase the maximum block size from one megabyte to 8,000,000 bytes. The proposal suggests doubling the block size every two years until it reaches 8,192,000,000 bytes. To activate this change, a hash-power supermajority vote is required. This proposal allows miners, merchants, and users running full-nodes ample time to upgrade their software to support larger blocks.It's important to note that this proposed change is a hard-forking modification to the Bitcoin protocol. Therefore, anyone running code that fully validates blocks must upgrade their software before the activation time. Failure to do so may result in rejecting a - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Dynamically-Controlled-Bitcoin-Block-Size-Max-Cap-BIP-1xx-Draft-.xml b/static/bitcoin-dev/Aug_2015/combined_Dynamically-Controlled-Bitcoin-Block-Size-Max-Cap-BIP-1xx-Draft-.xml index b02c3f5f48..de228a3aef 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Dynamically-Controlled-Bitcoin-Block-Size-Max-Cap-BIP-1xx-Draft-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Dynamically-Controlled-Bitcoin-Block-Size-Max-Cap-BIP-1xx-Draft-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft] - 2023-08-01T15:40:50.535299+00:00 + 2025-10-11T22:06:27.056500+00:00 + python-feedgen Upal Chakraborty 2015-08-27 15:09:18+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft] - 2023-08-01T15:40:50.535299+00:00 + 2025-10-11T22:06:27.056641+00:00 - The proposal suggests replacing the fixed maximum block size with a dynamically controlled maximum block size that may increase or decrease based on various network factors. There are two proposals presented in the document. Proposal 1 depends only on the previous block size calculation, while Proposal 2 depends on both the previous block size calculation and the previous Tx fee collected by miners. The rationale behind each solution is explained in detail. The document notes that this is a hard-forking change to the Bitcoin protocol, and anyone running code that fully validates blocks must upgrade before the activation time or risk rejecting a chain containing larger-than-one-megabyte blocks. Other solutions considered are also mentioned. If consensus is achieved, deployment can be made at a future block number at which difficulty will change.A member of the bitcoin-dev mailing list, Hector Chu, proposed using CLTV (CheckLockTimeVerify) to lock coins as a better alternative to counting votes from UTXO set. However, if a soft-fork to implement CLTV is not feasible, counting votes from the UTXO set is still an acceptable option, albeit less strong evidence of commitment. Peter Todd suggested a toy example of XORing a vote with SHA256 of the entire blockchain, but it was deemed ineffective by Hector Chu.In a discussion on bitcoin-dev, Peter Todd proposed XORing votes with SHA256 of the entire blockchain as a simple toy example of voting mechanism. However, this proposal was criticized for not being effective. In response to this, another proposal was made by an unknown individual to use CLTV to lock coins (votes), which was considered to be better than the previous proposal. In case a soft-fork cannot be implemented in time, counting votes from the UTXO set is also considered to be acceptable, but it may not provide strong evidence of commitment like CLTV.In a Bitcoin development discussion, Simon Liu raised concerns about the feasibility of implementing a rule where one user can only have one vote. He asked how to prevent a user running multiple nodes. Chun Wang answered that the vote would not be counted by nodes but by bitcoin amount or coin-days, working like proof-of-stake. Peter Todd added to the discussion that to implement a vote where only users with access to a full node can vote, part of the vote would need to be determined by a non-miner-committed value calculatable by anyone with a full node. He gave an example of XORing a vote with SHA256(the entire blockchain).In a discussion on the bitcoin-dev mailing list, Simon Liu raised concerns about a voting system for users that could be exploited by those running multiple nodes. In response, it was clarified that the proposed system would not count votes based on nodes, but instead on bitcoin amount or coin-days, similar to a proof-of-stake model. It was suggested that a combination of proof-of-work and proof-of-stake would be optimal for such a system.Bitcoin is not a democracy. The proposal to vote on what goes into a particular Github repository is ultimately controlled by those with the control of that repository. Bitcoin is an anarchy by design, and people will use whatever they want. While stakeholders could be allowed to vote on the determination of the max block-size limit, it is likely to result in very low-quality results and drastically low participation, similar to rational ignorance. The default mechanism for change would be forking off altcoins and allowing the market to decide which coin is most valuable.In a discussion on the bitcoin-dev mailing list, Peter Todd proposed an idea of creating a voting mechanism in which only users with access to validating nodes would be able to vote. However, some concerns were raised regarding this proposal. One concern was that if the rule is that one user can only have one vote, how do you prevent a user running multiple nodes? Another concern was how to verify that a node is indeed a fully validating node with its own copy of the blockchain. Despite these concerns, the idea of designing a voting mechanism for Bitcoin's governance remains an interesting concept to explore.The discussion is about an approach to give the economic majority of coin holders a vote for the maximum block size. However, it is questioned what fraction of coin holders would vote and how many have the technical knowledge to make an informed choice. The comparison is made to polling Toyota truck owners on whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%, which would not result in meaningful votes from ordinary users. The idea of allowing altcoins to determine the max block-size limit through market mechanisms is mentioned as a default mechanism for change, but it is not the least painful mechanism. The voters are unlikely to cast informed votes, and the vote is likely to have little participation and low-quality results. Nonetheless, stakeholder vote is considered important to check on miners' power.In a discussion thread on Bitcoin-dev mailing list, Peter Todd proposed an approach to give the economic majority of coin holders a vote for the max blocksize. However, in 2015-08-27T15:09:18+00:00 + The proposal suggests replacing the fixed maximum block size with a dynamically controlled maximum block size that may increase or decrease based on various network factors. There are two proposals presented in the document. Proposal 1 depends only on the previous block size calculation, while Proposal 2 depends on both the previous block size calculation and the previous Tx fee collected by miners. The rationale behind each solution is explained in detail. The document notes that this is a hard-forking change to the Bitcoin protocol, and anyone running code that fully validates blocks must upgrade before the activation time or risk rejecting a chain containing larger-than-one-megabyte blocks. Other solutions considered are also mentioned. If consensus is achieved, deployment can be made at a future block number at which difficulty will change.A member of the bitcoin-dev mailing list, Hector Chu, proposed using CLTV (CheckLockTimeVerify) to lock coins as a better alternative to counting votes from UTXO set. However, if a soft-fork to implement CLTV is not feasible, counting votes from the UTXO set is still an acceptable option, albeit less strong evidence of commitment. Peter Todd suggested a toy example of XORing a vote with SHA256 of the entire blockchain, but it was deemed ineffective by Hector Chu.In a discussion on bitcoin-dev, Peter Todd proposed XORing votes with SHA256 of the entire blockchain as a simple toy example of voting mechanism. However, this proposal was criticized for not being effective. In response to this, another proposal was made by an unknown individual to use CLTV to lock coins (votes), which was considered to be better than the previous proposal. In case a soft-fork cannot be implemented in time, counting votes from the UTXO set is also considered to be acceptable, but it may not provide strong evidence of commitment like CLTV.In a Bitcoin development discussion, Simon Liu raised concerns about the feasibility of implementing a rule where one user can only have one vote. He asked how to prevent a user running multiple nodes. Chun Wang answered that the vote would not be counted by nodes but by bitcoin amount or coin-days, working like proof-of-stake. Peter Todd added to the discussion that to implement a vote where only users with access to a full node can vote, part of the vote would need to be determined by a non-miner-committed value calculatable by anyone with a full node. He gave an example of XORing a vote with SHA256(the entire blockchain).In a discussion on the bitcoin-dev mailing list, Simon Liu raised concerns about a voting system for users that could be exploited by those running multiple nodes. In response, it was clarified that the proposed system would not count votes based on nodes, but instead on bitcoin amount or coin-days, similar to a proof-of-stake model. It was suggested that a combination of proof-of-work and proof-of-stake would be optimal for such a system.Bitcoin is not a democracy. The proposal to vote on what goes into a particular Github repository is ultimately controlled by those with the control of that repository. Bitcoin is an anarchy by design, and people will use whatever they want. While stakeholders could be allowed to vote on the determination of the max block-size limit, it is likely to result in very low-quality results and drastically low participation, similar to rational ignorance. The default mechanism for change would be forking off altcoins and allowing the market to decide which coin is most valuable.In a discussion on the bitcoin-dev mailing list, Peter Todd proposed an idea of creating a voting mechanism in which only users with access to validating nodes would be able to vote. However, some concerns were raised regarding this proposal. One concern was that if the rule is that one user can only have one vote, how do you prevent a user running multiple nodes? Another concern was how to verify that a node is indeed a fully validating node with its own copy of the blockchain. Despite these concerns, the idea of designing a voting mechanism for Bitcoin's governance remains an interesting concept to explore.The discussion is about an approach to give the economic majority of coin holders a vote for the maximum block size. However, it is questioned what fraction of coin holders would vote and how many have the technical knowledge to make an informed choice. The comparison is made to polling Toyota truck owners on whether the 2017 Tacoma should increase its engine's cylinder displacement by 10%, which would not result in meaningful votes from ordinary users. The idea of allowing altcoins to determine the max block-size limit through market mechanisms is mentioned as a default mechanism for change, but it is not the least painful mechanism. The voters are unlikely to cast informed votes, and the vote is likely to have little participation and low-quality results. Nonetheless, stakeholder vote is considered important to check on miners' power.In a discussion thread on Bitcoin-dev mailing list, Peter Todd proposed an approach to give the economic majority of coin holders a vote for the max blocksize. However, in - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Dynamically-Controlled-Bitcoin-Block-Size-Max-Cap.xml b/static/bitcoin-dev/Aug_2015/combined_Dynamically-Controlled-Bitcoin-Block-Size-Max-Cap.xml index 788a061e28..0544188f5e 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Dynamically-Controlled-Bitcoin-Block-Size-Max-Cap.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Dynamically-Controlled-Bitcoin-Block-Size-Max-Cap.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dynamically Controlled Bitcoin Block Size Max Cap - 2023-08-01T15:26:54.147439+00:00 + 2025-10-11T22:07:01.057918+00:00 + python-feedgen Jorge Timón 2015-08-24 02:27:02+00:00 @@ -135,13 +136,13 @@ - python-feedgen + 2 Combined summary - Dynamically Controlled Bitcoin Block Size Max Cap - 2023-08-01T15:26:54.148440+00:00 + 2025-10-11T22:07:01.058135+00:00 - In a Bitcoin-dev forum, members discuss the potential risks and impacts of changing the maximum block size consensus rule on mining centralization. One member, Tom Harding, conducts an experiment to test the effects of large blocks on small miners and concludes that they are not disadvantaged. However, Peter Todd criticizes the experiment for not considering the actual scenario of concern.Throughout the conversation, analogies to car brakes are used to explain the risks of minority hash power partitioning in the Bitcoin network. Pieter Wuille's work on brake cylinder fatigue is referenced to highlight the potential dangers of this phenomenon.The need for a standardized metric to measure decentralization in software projects like Bitcoin is also discussed. The group suggests linking centralization pressure and the pressure to merge with big miners to an overall decentralization metric. While acknowledging the complexity of measuring decentralization, existing metrics used in political systems are suggested as a starting point.Overall, the discussion delves into the technical details and implications of the maximum block size consensus rule in Bitcoin mining. Topics covered include hash power partitioning, revenue differences between small and large miners, resistance against attacks on miners, and the need for systematic analysis of metrics to address mining centralization.In another discussion on the bitcoin-dev mailing list, the topic of maximum block size in Bitcoin is debated. The purpose of the maximum block size is argued to be preventing spam or forcing higher fees, but this approach is criticized as counterproductive.A proposal is made to address miners sabotaging block size increases by mining empty blocks. This involves adjusting the maximum block size algorithmically based on the percentage of block size found in the first 2000 of the last difficulty period. If certain thresholds are exceeded, the maximum block size is doubled or halved. This allows both miners and end-users to have their say.Another proposal suggests using the mean block size during the last 60-120 minutes as a scalability metric. If the blocks start to get full past a certain threshold, the maximum block size should be doubled for the next block. Conversely, if the mean block size goes below a certain threshold, the maximum block size allowed should be halved. This aims to accommodate unexpected organic usage peaks and maintain network efficiency.Concerns about miners sabotaging block size increases by mining empty blocks are addressed with various technical solutions. It is argued that this would not be economical as miners would lose transaction fees and switch pools. Adjusting the maximum block size based on recent block sizes with input from both miners and end-users is proposed as a solution.The overall debate focuses on finding a solution to the maximum block size controversy in Bitcoin, aiming to balance transaction volume, prevent sabotage by miners, and ensure a rational derivation of the maximum block size. The author invites comments on their proposed solutions and provides contact information for further discussion. 2015-08-24T02:27:02+00:00 + In a Bitcoin-dev forum, members discuss the potential risks and impacts of changing the maximum block size consensus rule on mining centralization. One member, Tom Harding, conducts an experiment to test the effects of large blocks on small miners and concludes that they are not disadvantaged. However, Peter Todd criticizes the experiment for not considering the actual scenario of concern.Throughout the conversation, analogies to car brakes are used to explain the risks of minority hash power partitioning in the Bitcoin network. Pieter Wuille's work on brake cylinder fatigue is referenced to highlight the potential dangers of this phenomenon.The need for a standardized metric to measure decentralization in software projects like Bitcoin is also discussed. The group suggests linking centralization pressure and the pressure to merge with big miners to an overall decentralization metric. While acknowledging the complexity of measuring decentralization, existing metrics used in political systems are suggested as a starting point.Overall, the discussion delves into the technical details and implications of the maximum block size consensus rule in Bitcoin mining. Topics covered include hash power partitioning, revenue differences between small and large miners, resistance against attacks on miners, and the need for systematic analysis of metrics to address mining centralization.In another discussion on the bitcoin-dev mailing list, the topic of maximum block size in Bitcoin is debated. The purpose of the maximum block size is argued to be preventing spam or forcing higher fees, but this approach is criticized as counterproductive.A proposal is made to address miners sabotaging block size increases by mining empty blocks. This involves adjusting the maximum block size algorithmically based on the percentage of block size found in the first 2000 of the last difficulty period. If certain thresholds are exceeded, the maximum block size is doubled or halved. This allows both miners and end-users to have their say.Another proposal suggests using the mean block size during the last 60-120 minutes as a scalability metric. If the blocks start to get full past a certain threshold, the maximum block size should be doubled for the next block. Conversely, if the mean block size goes below a certain threshold, the maximum block size allowed should be halved. This aims to accommodate unexpected organic usage peaks and maintain network efficiency.Concerns about miners sabotaging block size increases by mining empty blocks are addressed with various technical solutions. It is argued that this would not be economical as miners would lose transaction fees and switch pools. Adjusting the maximum block size based on recent block sizes with input from both miners and end-users is proposed as a solution.The overall debate focuses on finding a solution to the maximum block size controversy in Bitcoin, aiming to balance transaction volume, prevent sabotage by miners, and ensure a rational derivation of the maximum block size. The author invites comments on their proposed solutions and provides contact information for further discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_ERRATA-CORRIGE-Short-Theorem.xml b/static/bitcoin-dev/Aug_2015/combined_ERRATA-CORRIGE-Short-Theorem.xml index 4bf946c2e3..baee1a3cd8 100644 --- a/static/bitcoin-dev/Aug_2015/combined_ERRATA-CORRIGE-Short-Theorem.xml +++ b/static/bitcoin-dev/Aug_2015/combined_ERRATA-CORRIGE-Short-Theorem.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ERRATA CORRIGE + Short Theorem - 2023-08-01T15:52:27.236265+00:00 + 2025-10-11T22:05:14.770770+00:00 + python-feedgen Daniele Pinna 2015-09-01 08:52:46+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - ERRATA CORRIGE + Short Theorem - 2023-08-01T15:52:27.236265+00:00 + 2025-10-11T22:05:14.770931+00:00 - In an email exchange on the bitcoin-dev mailing list, Daniele Pinna clarified his previous assertions about the revenue per unit hash advantage for miners. He pointed out that while his paper showed a decrease in the advantage with the block reward, this does not necessarily mean that the real revenue per unit hash advantage also decreases. Pinna believes that the orphaning factor used in the calculations is incorrect or incomplete. Peter Todd agreed with Pinna's clarification and shared a link to his own math proof, which demonstrated that larger miners earn more money per unit hashing power.Peter Todd, a developer of the Bitcoin software, wrote an email in 2015 discussing his math proof that showed larger miners earn more money per unit hashing power. He provided a link to his proof and stated that he did not believe anyone was arguing otherwise. Another participant in the discussion, Dpinna, had claimed that his paper showed the advantage of larger miners decreased as the block reward diminished or total fees increased. Peter considered this claim reasonable but did not verify the math. The email exchange occurred on the bitcoin-dev mailing list.On August 30, 2015, Daniele Pinna posted a theorem on the bitcoin-dev mailing list. According to the theorem, all hashrates generate revenue per unit of hash, with larger hashrates generating more revenue. Pinna argued that an optimal hashrate exists where the average revenue for each hash in service is maximized. This balance stems from the fact that larger miners must mine larger blocks, which carry a higher orphan risk. If a large miner chooses to mine a seemingly "sub-optimal" block size identical to a smaller miner, they will both carry identical orphan risks and win identical amounts whenever they successfully mine a block. However, this contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash decreases. This theorem suggests that the marginal profit curve increases monotonically with miner hashrate. Peter Todd supported Pinna's argument by sharing a link to his own math proof, which also demonstrated that larger miners earn more money per unit hashing power. Todd disproved all conclusions of Pinna's work and emphasized that centralization pressures will always be present. The email exchange also includes a digital signature.In summary, the author presents a theorem stating that larger miners generate more revenue per unit of hash. This balance is due to the fact that larger miners must mine larger blocks, which carry a higher orphan risk. If a large miner chooses a seemingly "sub-optimal" block size identical to a smaller miner, they will earn the same revenue per unit of hash. This contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash decreases. The theorem implies that the marginal profit curve increases monotonically with miner hashrate. It disproves the author's conclusions and suggests that centralization pressures will always be present, as orphan risks favor larger hashrate miners leading to greater revenues per unit of hash. 2015-09-01T08:52:46+00:00 + In an email exchange on the bitcoin-dev mailing list, Daniele Pinna clarified his previous assertions about the revenue per unit hash advantage for miners. He pointed out that while his paper showed a decrease in the advantage with the block reward, this does not necessarily mean that the real revenue per unit hash advantage also decreases. Pinna believes that the orphaning factor used in the calculations is incorrect or incomplete. Peter Todd agreed with Pinna's clarification and shared a link to his own math proof, which demonstrated that larger miners earn more money per unit hashing power.Peter Todd, a developer of the Bitcoin software, wrote an email in 2015 discussing his math proof that showed larger miners earn more money per unit hashing power. He provided a link to his proof and stated that he did not believe anyone was arguing otherwise. Another participant in the discussion, Dpinna, had claimed that his paper showed the advantage of larger miners decreased as the block reward diminished or total fees increased. Peter considered this claim reasonable but did not verify the math. The email exchange occurred on the bitcoin-dev mailing list.On August 30, 2015, Daniele Pinna posted a theorem on the bitcoin-dev mailing list. According to the theorem, all hashrates generate revenue per unit of hash, with larger hashrates generating more revenue. Pinna argued that an optimal hashrate exists where the average revenue for each hash in service is maximized. This balance stems from the fact that larger miners must mine larger blocks, which carry a higher orphan risk. If a large miner chooses to mine a seemingly "sub-optimal" block size identical to a smaller miner, they will both carry identical orphan risks and win identical amounts whenever they successfully mine a block. However, this contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash decreases. This theorem suggests that the marginal profit curve increases monotonically with miner hashrate. Peter Todd supported Pinna's argument by sharing a link to his own math proof, which also demonstrated that larger miners earn more money per unit hashing power. Todd disproved all conclusions of Pinna's work and emphasized that centralization pressures will always be present. The email exchange also includes a digital signature.In summary, the author presents a theorem stating that larger miners generate more revenue per unit of hash. This balance is due to the fact that larger miners must mine larger blocks, which carry a higher orphan risk. If a large miner chooses a seemingly "sub-optimal" block size identical to a smaller miner, they will earn the same revenue per unit of hash. This contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash decreases. The theorem implies that the marginal profit curve increases monotonically with miner hashrate. It disproves the author's conclusions and suggests that centralization pressures will always be present, as orphan risks favor larger hashrate miners leading to greater revenues per unit of hash. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Economic-majority-vote-by-splitting-coins.xml b/static/bitcoin-dev/Aug_2015/combined_Economic-majority-vote-by-splitting-coins.xml index 2ce88b7e82..9da35e677d 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Economic-majority-vote-by-splitting-coins.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Economic-majority-vote-by-splitting-coins.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Economic majority vote by splitting coins - 2023-08-01T15:35:11.033330+00:00 + 2025-10-11T22:07:45.775627+00:00 + python-feedgen Tier Nolan 2015-08-21 11:03:36+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Economic majority vote by splitting coins - 2023-08-01T15:35:11.033330+00:00 + 2025-10-11T22:07:45.775776+00:00 - odinn expresses skepticism that most users would be able to utilize a proposal involving a BIP and soft fork. The proposal assumes that many wallets would support or recognize encumbered coins, even if not all of them do. Users would still be able to move their coins around, but only those trading between XT and Core would need wallets that support it. By consolidating BTC-Core and BTC-XT into a single output, the user can convert it back to a normal output. The purpose of this proposal is to offer a sneak preview and show which choice will give the highest BTC value.To measure the economic majority in Bitcoin, which represents the will of those who actually use Bitcoin as a payment system, contracts could be added with a soft fork like the P2SH one. This would allow the output to be spent on multiple forks, preserving the value on each until the deadline. If someone wants to propose a hard fork, they can create a new fork id and release software that implements the hard fork at a given deadline without requiring a miner vote.After the deadline, core will allow conversion of outputs that pay to the core fork-id to be converted into unencumbered outputs by the person with the core-id script. Similarly, the fork software will allow outputs that pay to the fork id to be converted. Legacy bitcoin that haven't been "split" will be spendable on both sides equally. This means that users can convert legacy bitcoin into fork-bitcoins and core-bitcoins in advance of the fork, allowing exchanges to support trading between the two.The side that trades with the most value is the one supported by the economic majority. As it becomes clear which side is going to win, the price of coins on the losing side is expected to drop. It is unlikely that the two sides would stay at exactly the same value without one side winning. Users who want to use the losing rules are free to do so, but the economic majority will have made its decision. 2015-08-21T11:03:36+00:00 + odinn expresses skepticism that most users would be able to utilize a proposal involving a BIP and soft fork. The proposal assumes that many wallets would support or recognize encumbered coins, even if not all of them do. Users would still be able to move their coins around, but only those trading between XT and Core would need wallets that support it. By consolidating BTC-Core and BTC-XT into a single output, the user can convert it back to a normal output. The purpose of this proposal is to offer a sneak preview and show which choice will give the highest BTC value.To measure the economic majority in Bitcoin, which represents the will of those who actually use Bitcoin as a payment system, contracts could be added with a soft fork like the P2SH one. This would allow the output to be spent on multiple forks, preserving the value on each until the deadline. If someone wants to propose a hard fork, they can create a new fork id and release software that implements the hard fork at a given deadline without requiring a miner vote.After the deadline, core will allow conversion of outputs that pay to the core fork-id to be converted into unencumbered outputs by the person with the core-id script. Similarly, the fork software will allow outputs that pay to the fork id to be converted. Legacy bitcoin that haven't been "split" will be spendable on both sides equally. This means that users can convert legacy bitcoin into fork-bitcoins and core-bitcoins in advance of the fork, allowing exchanges to support trading between the two.The side that trades with the most value is the one supported by the economic majority. As it becomes clear which side is going to win, the price of coins on the losing side is expected to drop. It is unlikely that the two sides would stay at exactly the same value without one side winning. Users who want to use the losing rules are free to do so, but the economic majority will have made its decision. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Eli-Dourado-on-governance-.xml b/static/bitcoin-dev/Aug_2015/combined_Eli-Dourado-on-governance-.xml index f067844eb3..e06405bc7e 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Eli-Dourado-on-governance-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Eli-Dourado-on-governance-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Eli Dourado on "governance" - 2023-08-01T14:53:41.200519+00:00 + Combined summary - Eli Dourado on "governance" + 2025-10-11T22:07:07.433615+00:00 + python-feedgen Thomas Zander 2015-08-07 16:26:32+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 - Combined summary - Eli Dourado on "governance" - 2023-08-01T14:53:41.200519+00:00 + Combined summary - Eli Dourado on "governance" + 2025-10-11T22:07:07.433748+00:00 - In August 2015, Bitcoin developers engaged in discussions regarding the use of prediction markets to address issues within the Bitcoin network. Gavin Andresen expressed his disagreement with predictions that the number of nodes in the network would decrease, stating that hardware like Raspberry PI can run a node effectively. He believed that as Bitcoin gained popularity, more users would run nodes for security reasons.However, some developers, including Eric Lombrozo and Owen, argued against using prediction markets, emphasizing the implausibility of results due to the lack of money at stake. Anthony Towns pointed out that the scicast prediction market, which provided numbers related to network hash rate, was shut down and its numbers appeared implausible.Peter Sztorc proposed a sidechain implementation using Blockstream's method, but Lombrozo advocated for using theory, empirical data, and engineering to solve problems instead of relying on prediction markets. Andresen agreed with the preliminary results from a prediction market addressing tradeoffs, while Towns found the predictions concerning the drop in node count due to increasing block sizes to be problematic.The context highlighted the impracticality of predicting outcomes through fake markets without actual financial stakes. It suggested utilizing theory, empirical data, and engineering to address Bitcoin's challenges instead. The discussion also touched upon the block size debate, with Towns suggesting a 1.5MB-2MB max block size for the next two years based on transaction volume increase. However, the lack of convincing predictions made it unclear whether importance should be given to these suggestions.Additionally, Andresen discussed the need for improved governance mechanisms in Bitcoin, proposing that groups with similar interests, such as exchanges, should come together to reach consensus on important issues rather than relying on a single representative body like the Bitcoin Foundation.In relation to this, Eli Dourado's blog post on Bitcoin governance was mentioned, supporting the idea of better communication and organization between stakeholders. The author of the context agreed with Dourado's conclusions but disagreed with the prediction regarding the number of nodes, citing the decline of general-purpose home PCs and a Business Insider report from 2015 as evidence.Overall, the context provided insights into the discussions among Bitcoin developers regarding prediction markets, block size debate, governance, and the decline in the number of nodes. It emphasized the need for reliable data-driven solutions and effective collaboration among stakeholders to address challenges and ensure the network's success. 2015-08-07T16:26:32+00:00 + In August 2015, Bitcoin developers engaged in discussions regarding the use of prediction markets to address issues within the Bitcoin network. Gavin Andresen expressed his disagreement with predictions that the number of nodes in the network would decrease, stating that hardware like Raspberry PI can run a node effectively. He believed that as Bitcoin gained popularity, more users would run nodes for security reasons.However, some developers, including Eric Lombrozo and Owen, argued against using prediction markets, emphasizing the implausibility of results due to the lack of money at stake. Anthony Towns pointed out that the scicast prediction market, which provided numbers related to network hash rate, was shut down and its numbers appeared implausible.Peter Sztorc proposed a sidechain implementation using Blockstream's method, but Lombrozo advocated for using theory, empirical data, and engineering to solve problems instead of relying on prediction markets. Andresen agreed with the preliminary results from a prediction market addressing tradeoffs, while Towns found the predictions concerning the drop in node count due to increasing block sizes to be problematic.The context highlighted the impracticality of predicting outcomes through fake markets without actual financial stakes. It suggested utilizing theory, empirical data, and engineering to address Bitcoin's challenges instead. The discussion also touched upon the block size debate, with Towns suggesting a 1.5MB-2MB max block size for the next two years based on transaction volume increase. However, the lack of convincing predictions made it unclear whether importance should be given to these suggestions.Additionally, Andresen discussed the need for improved governance mechanisms in Bitcoin, proposing that groups with similar interests, such as exchanges, should come together to reach consensus on important issues rather than relying on a single representative body like the Bitcoin Foundation.In relation to this, Eli Dourado's blog post on Bitcoin governance was mentioned, supporting the idea of better communication and organization between stakeholders. The author of the context agreed with Dourado's conclusions but disagreed with the prediction regarding the number of nodes, citing the decline of general-purpose home PCs and a Business Insider report from 2015 as evidence.Overall, the context provided insights into the discussions among Bitcoin developers regarding prediction markets, block size debate, governance, and the decline in the number of nodes. It emphasized the need for reliable data-driven solutions and effective collaboration among stakeholders to address challenges and ensure the network's success. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Encouraging-mining-of-the-first-few-big-blocks-with-OP-CSV-and-BIP68.xml b/static/bitcoin-dev/Aug_2015/combined_Encouraging-mining-of-the-first-few-big-blocks-with-OP-CSV-and-BIP68.xml index 9417c5bc6c..4122d4f492 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Encouraging-mining-of-the-first-few-big-blocks-with-OP-CSV-and-BIP68.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Encouraging-mining-of-the-first-few-big-blocks-with-OP-CSV-and-BIP68.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Encouraging mining of the first few big blocks with OP_CSV and BIP68 - 2023-08-01T15:39:47.086977+00:00 + 2025-10-11T22:07:24.452536+00:00 + python-feedgen Hector Chu 2015-08-23 19:43:36+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Encouraging mining of the first few big blocks with OP_CSV and BIP68 - 2023-08-01T15:39:47.086977+00:00 + 2025-10-11T22:07:24.452661+00:00 - In order to prevent a fork, the distribution of donation may be adjusted to reduce the incentive for a miner cartel to launch a 51% attack and collect all the money. However, it has been suggested that the market will trend lower in response to this news, with predictions that it will fall below $180 by the time of the test. 2015-08-23T19:43:36+00:00 + In order to prevent a fork, the distribution of donation may be adjusted to reduce the incentive for a miner cartel to launch a 51% attack and collect all the money. However, it has been suggested that the market will trend lower in response to this news, with predictions that it will fall below $180 by the time of the test. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Fees-and-the-block-finding-process.xml b/static/bitcoin-dev/Aug_2015/combined_Fees-and-the-block-finding-process.xml index 42eec4bbb6..fdfc1d41fc 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Fees-and-the-block-finding-process.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Fees-and-the-block-finding-process.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fees and the block-finding process - 2023-08-01T15:02:28.127567+00:00 + 2025-10-11T22:07:54.275452+00:00 + python-feedgen Will Madden 2015-08-20 14:40:50+00:00 @@ -379,13 +380,13 @@ - python-feedgen + 2 Combined summary - Fees and the block-finding process - 2023-08-01T15:02:28.128520+00:00 + 2025-10-11T22:07:54.275761+00:00 - The ongoing debate surrounding Bitcoin's block size is a topic of concern within the community. The argument against constraining block size is that it limits the number of new users and reduces Bitcoin's value. There is a suggestion to raise the block size limit to 8MB, gradually increasing it to accommodate transaction growth. However, there are still issues with solutions like Lightning Network that need to be addressed.The discussion also raises concerns about rising fees and software problems independent of block size. Some argue that these issues should be considered in the debate, while others believe the focus should be on privacy and mining centralization. The reliability of Bitcoin with regards to block size is also discussed, weighing the benefits of larger blocks against the risks of centralization and system crashes.Scalability is another ongoing debate, with discussions on micropayment channels, architectural limitations, and policy neutrality. The Lightning Network is proposed as a solution, but opinions differ on its suitability for global consensus networks. The importance of playing to Bitcoin's strengths instead of competing with traditional payment systems is emphasized.Consensus rules, utility, and risk are seen as vital in finding a balance for Bitcoin's future growth. The discussions acknowledge the challenges facing the community and the need for scalability and consensus on block size and fees. Market forces, technological improvements, and alternative architectures are also considered.Email exchanges and forum discussions highlight different perspectives on block size increases, transaction fees, censorship resistance, and policy neutrality. Clear communication and productive dialogue are emphasized to address concerns and promote understanding among community members.The context also provides insights into the ongoing debate between developers Gavin Andresen and Pieter Wuille. Andresen argues for an increase in the block size to avoid potential issues, while Wuille cautions against making decisions based on fear and advocates for off-chain systems. They discuss the trade-offs and potential consequences of raising the block size.In conclusion, the context presents a thorough overview of the ongoing discussions and debates surrounding Bitcoin's block size, off-chain transactions, and transaction fees. It emphasizes the need for improvements in blockchain technology, consensus on important issues, and clear communication within the community.There has been a debate about whether the block size of Bitcoin should be increased due to concerns that capacity will run out. One participant in this discussion, Andresen, suggested reducing the maximum block size and asked for reasons why it should or shouldn't be reduced. In an email exchange with Wuille, they discussed the potential consequences of hitting the current 1MB limit. While Andresen acknowledged that rising minimum market fees would be a concern, he believed there were other reasons to increase the block size. On the other hand, Wuille argued that demand is infinite without a fee minimum and that acting out of fear does not improve the system. They both agreed that future increases in block size should be considered if the benefits outweigh the costs.In a discussion on the bitcoin-dev mailing list, Andresen suggested that low-fee transactions can still be confirmed if one is willing to wait for blocks to be found at random intervals. However, this logic only works when the rate of transactions with a non-zero fee is below what fits in blocks. Andresen admitted uncertainty about the "market minimum fee" and how long people are willing to wait or how much memory miners will dedicate to storing transactions that won't confirm for a long time.In another thread, someone named Jorge asked Andresen when it would be a good time to let the minimum fee rise above zero. Andresen explained that if one is willing to wait an infinite amount of time, the minimum fee will always be close to zero. However, he also admitted uncertainty about the market minimum fee and factors such as waiting times and memory limitations.Overall, there are differing opinions on the need to increase the block size of Bitcoin. Some argue for it in order to support more users and transactions, while others fear potential centralization and disruption of the system. This debate highlights the tradeoffs involved and emphasizes the importance of carefully considering the benefits and costs of any changes to the block size. 2015-08-20T14:40:50+00:00 + The ongoing debate surrounding Bitcoin's block size is a topic of concern within the community. The argument against constraining block size is that it limits the number of new users and reduces Bitcoin's value. There is a suggestion to raise the block size limit to 8MB, gradually increasing it to accommodate transaction growth. However, there are still issues with solutions like Lightning Network that need to be addressed.The discussion also raises concerns about rising fees and software problems independent of block size. Some argue that these issues should be considered in the debate, while others believe the focus should be on privacy and mining centralization. The reliability of Bitcoin with regards to block size is also discussed, weighing the benefits of larger blocks against the risks of centralization and system crashes.Scalability is another ongoing debate, with discussions on micropayment channels, architectural limitations, and policy neutrality. The Lightning Network is proposed as a solution, but opinions differ on its suitability for global consensus networks. The importance of playing to Bitcoin's strengths instead of competing with traditional payment systems is emphasized.Consensus rules, utility, and risk are seen as vital in finding a balance for Bitcoin's future growth. The discussions acknowledge the challenges facing the community and the need for scalability and consensus on block size and fees. Market forces, technological improvements, and alternative architectures are also considered.Email exchanges and forum discussions highlight different perspectives on block size increases, transaction fees, censorship resistance, and policy neutrality. Clear communication and productive dialogue are emphasized to address concerns and promote understanding among community members.The context also provides insights into the ongoing debate between developers Gavin Andresen and Pieter Wuille. Andresen argues for an increase in the block size to avoid potential issues, while Wuille cautions against making decisions based on fear and advocates for off-chain systems. They discuss the trade-offs and potential consequences of raising the block size.In conclusion, the context presents a thorough overview of the ongoing discussions and debates surrounding Bitcoin's block size, off-chain transactions, and transaction fees. It emphasizes the need for improvements in blockchain technology, consensus on important issues, and clear communication within the community.There has been a debate about whether the block size of Bitcoin should be increased due to concerns that capacity will run out. One participant in this discussion, Andresen, suggested reducing the maximum block size and asked for reasons why it should or shouldn't be reduced. In an email exchange with Wuille, they discussed the potential consequences of hitting the current 1MB limit. While Andresen acknowledged that rising minimum market fees would be a concern, he believed there were other reasons to increase the block size. On the other hand, Wuille argued that demand is infinite without a fee minimum and that acting out of fear does not improve the system. They both agreed that future increases in block size should be considered if the benefits outweigh the costs.In a discussion on the bitcoin-dev mailing list, Andresen suggested that low-fee transactions can still be confirmed if one is willing to wait for blocks to be found at random intervals. However, this logic only works when the rate of transactions with a non-zero fee is below what fits in blocks. Andresen admitted uncertainty about the "market minimum fee" and how long people are willing to wait or how much memory miners will dedicate to storing transactions that won't confirm for a long time.In another thread, someone named Jorge asked Andresen when it would be a good time to let the minimum fee rise above zero. Andresen explained that if one is willing to wait an infinite amount of time, the minimum fee will always be close to zero. However, he also admitted uncertainty about the market minimum fee and factors such as waiting times and memory limitations.Overall, there are differing opinions on the need to increase the block size of Bitcoin. Some argue for it in order to support more users and transactions, while others fear potential centralization and disruption of the system. This debate highlights the tradeoffs involved and emphasizes the importance of carefully considering the benefits and costs of any changes to the block size. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Future-Of-Bitcoin-Cores-Wallet.xml b/static/bitcoin-dev/Aug_2015/combined_Future-Of-Bitcoin-Cores-Wallet.xml index 39d8ee297b..88f755da60 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Future-Of-Bitcoin-Cores-Wallet.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Future-Of-Bitcoin-Cores-Wallet.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Future Of Bitcoin-Cores Wallet - 2023-08-01T15:07:14.318292+00:00 + 2025-10-11T22:05:23.287756+00:00 + python-feedgen Jeff Garzik 2015-08-11 15:46:25+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Future Of Bitcoin-Cores Wallet - 2023-08-01T15:07:14.318292+00:00 + 2025-10-11T22:05:23.287916+00:00 - The Bitcoin Core wallet has seen a shift in development towards SPV, thin clients, and centralized web middleware, leaving the full node wallet with less attention. However, Jonas Schnelli proposes changes to make running a full node wallet more user-friendly. His suggestions include enabling pruning by default, offering flexible CPU usage, throttling block download bandwidth, participating in SPV during catch up, disabling bloom filtering, and switching from SPV to full validation when the node is in sync. Schnelli believes that implementing these changes would increase the number of participating full nodes while providing users with increased privacy and security. This approach would also serve as a counterweight against SPV/thin clients and avoid centralization in wallet development. While Schnelli acknowledges that this solution may not work on smartphones due to bandwidth and CPU constraints, he believes it could be effective for groups of people who trust each other.Schnelli has been working towards this direction for about a year and is currently developing a wallet-focused Bitcoin Core fork. His ultimate goal is to decouple the wallet and core by utilizing Bitcoin Core as a library for the wallet side. He invites other developers to join the team by reviewing concepts, criticizing ideas, or contributing code via GitHub.In a 2015 email exchange between Mike Hearn and Jonas Schnelli, they discussed the needs of bitcoin wallets. Hearn commended Schnelli's analysis but proposed a slightly different approach. He suggested supporting serving of Simplified Payment Verification (SPV) wallets from pruned storage, which would require protocol upgrades and Bitcoin Improvement Proposals (BIPs). This would benefit all SPV wallets, including those on mobile phones. Hearn also proposed creating a desktop wallet app based on bitcoinj that contains a bundled bitcoind. However, Hearn's proposal does not fully align with Schnelli's original post, which advocated for a single set of reference implementations for different components. Without eliminating bitcoin-qt in its current form, Hearn's proposal may not fully meet the spirit of Schnelli's recommendation.The message introduces an alternative approach to serving SPV wallets from pruned storage. It suggests creating a bitcoinj based desktop wallet app with a bundled bitcoind that syncs two wallets simultaneously: one from the P2P network and another from the local bitcoind via a local socket. The app would switch between using the wallet synced to P2P and the wallet synced to localhost when the latter is fully caught up, alerting the user if there are any discrepancies. This approach offers advantages over the current one, such as instant and transparent switching between local full-security mode and remote SPV security, which is beneficial for laptop users who do not run a local node all the time. Additionally, working with modern JVM tools and languages is more efficient than working with C++. For those looking to run a home server, bundling Tor and auto-registering a Tor hidden service is suggested. This would allow for defining a QR code standard to pair a wallet to an onion address, enabling any bitcoinj based wallet to sync to it. Furthermore, this setup allows for the use of a Bloom filter sized to give virtually no false positives without requiring additional indexing.Overall, the author highlights the lack of focus on Bitcoin Core's wallet development and proposes solutions to make running a full node wallet more user-friendly while increasing privacy and security. They discuss the limitations of smartphones in implementing these changes but suggest alternatives for groups of people who trust each other. The author is actively working on a wallet-focused Bitcoin Core fork and encourages collaboration and feedback from other developers. 2015-08-11T15:46:25+00:00 + The Bitcoin Core wallet has seen a shift in development towards SPV, thin clients, and centralized web middleware, leaving the full node wallet with less attention. However, Jonas Schnelli proposes changes to make running a full node wallet more user-friendly. His suggestions include enabling pruning by default, offering flexible CPU usage, throttling block download bandwidth, participating in SPV during catch up, disabling bloom filtering, and switching from SPV to full validation when the node is in sync. Schnelli believes that implementing these changes would increase the number of participating full nodes while providing users with increased privacy and security. This approach would also serve as a counterweight against SPV/thin clients and avoid centralization in wallet development. While Schnelli acknowledges that this solution may not work on smartphones due to bandwidth and CPU constraints, he believes it could be effective for groups of people who trust each other.Schnelli has been working towards this direction for about a year and is currently developing a wallet-focused Bitcoin Core fork. His ultimate goal is to decouple the wallet and core by utilizing Bitcoin Core as a library for the wallet side. He invites other developers to join the team by reviewing concepts, criticizing ideas, or contributing code via GitHub.In a 2015 email exchange between Mike Hearn and Jonas Schnelli, they discussed the needs of bitcoin wallets. Hearn commended Schnelli's analysis but proposed a slightly different approach. He suggested supporting serving of Simplified Payment Verification (SPV) wallets from pruned storage, which would require protocol upgrades and Bitcoin Improvement Proposals (BIPs). This would benefit all SPV wallets, including those on mobile phones. Hearn also proposed creating a desktop wallet app based on bitcoinj that contains a bundled bitcoind. However, Hearn's proposal does not fully align with Schnelli's original post, which advocated for a single set of reference implementations for different components. Without eliminating bitcoin-qt in its current form, Hearn's proposal may not fully meet the spirit of Schnelli's recommendation.The message introduces an alternative approach to serving SPV wallets from pruned storage. It suggests creating a bitcoinj based desktop wallet app with a bundled bitcoind that syncs two wallets simultaneously: one from the P2P network and another from the local bitcoind via a local socket. The app would switch between using the wallet synced to P2P and the wallet synced to localhost when the latter is fully caught up, alerting the user if there are any discrepancies. This approach offers advantages over the current one, such as instant and transparent switching between local full-security mode and remote SPV security, which is beneficial for laptop users who do not run a local node all the time. Additionally, working with modern JVM tools and languages is more efficient than working with C++. For those looking to run a home server, bundling Tor and auto-registering a Tor hidden service is suggested. This would allow for defining a QR code standard to pair a wallet to an onion address, enabling any bitcoinj based wallet to sync to it. Furthermore, this setup allows for the use of a Bloom filter sized to give virtually no false positives without requiring additional indexing.Overall, the author highlights the lack of focus on Bitcoin Core's wallet development and proposes solutions to make running a full node wallet more user-friendly while increasing privacy and security. They discuss the limitations of smartphones in implementing these changes but suggest alternatives for groups of people who trust each other. The author is actively working on a wallet-focused Bitcoin Core fork and encourages collaboration and feedback from other developers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Fwd-Block-size-following-technological-growth.xml b/static/bitcoin-dev/Aug_2015/combined_Fwd-Block-size-following-technological-growth.xml index c051c260fc..c4f0028897 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Fwd-Block-size-following-technological-growth.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Fwd-Block-size-following-technological-growth.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Block size following technological growth - 2023-08-01T14:58:46.899165+00:00 + 2025-10-11T22:05:21.159547+00:00 + python-feedgen Dave Scotese 2015-08-08 16:54:04+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Fwd: Block size following technological growth - 2023-08-01T14:58:46.899165+00:00 + 2025-10-11T22:05:21.159682+00:00 - In an email conversation on the bitcoin-dev mailing list, Pieter Wuille and Thomas Zander discussed the importance of running a full node in the Bitcoin ecosystem. Wuille argued that if the incentives for running a node do not outweigh the cost or difficulty, there is a problem with the system. He believed that as Bitcoin's main advantage is the lack of need for trust, increased adoption should lead to greater incentives for people to run full nodes. However, Zander disagreed, stating that not everyone needs to run a node and that the responsibility lies with the community to make it easier for those who want to.The conversation highlighted the ongoing debate about the importance of full nodes in maintaining the decentralized nature of Bitcoin. The discussion also touched on the issue of block size and its impact on running a full node. Wuille expressed concerns about the decreasing number of full nodes in the Bitcoin ecosystem and argued that as the stakes in the system increase, so should the incentives for people to verify transactions. However, Gavin Andresen disagreed and believed that people in the Bitcoin ecosystem should be free to make their own tradeoffs between trust, centralization, and convenience. He stated that block size has little to do with the decision to run a full node.The conversation emphasized the importance of full nodes in keeping the Bitcoin network secure and immune from malicious influence. It also highlighted the need for the community to ensure accessibility and ease of running a node. The debate continues within the Bitcoin community about the role of full nodes and their significance in maintaining decentralization.In another email exchange between Gavin Andresen and Pieter Wuille in August 2015, the topic of Bitcoin's block size limit was discussed. Wuille argued that increasing the block size to 8MB would make the blockchain inaccessible for low fee transactions and unreliable for medium fee transactions if there was a sudden influx of users willing to pay high fees. However, Andresen disagreed, stating that marginal transactions would be priced out and that being able to "handle" any size is not a simple question, but depends on factors like security and risk tolerance.Andresen believed that successful companies tackle problems as they arise and are willing to deploy imperfect solutions if they help solve short-term problems. In response, Wuille disagreed, stating that he didn't see a short-term problem and expressed his dislike for being forever locked at the same scale while technology evolves. He proposed finding a solution that addressed this issue.Despite consensus being against Wuille on this point, Andresen stressed the importance of finding a non-controversial solution that did not take unnecessary risks. He acknowledged that improving the scale of the system by increasing the block size may not be fundamental, but argued that "better is better." Wuille suggested that miners form Simplified Payment Verification (SPV) mining agreements to become less affected by the block size, but Andresen disagreed with this approach.Overall, the email exchange highlighted the differing perspectives on the block size limit and the need to find a solution that balances scalability, security, and consensus within the Bitcoin network. 2015-08-08T16:54:04+00:00 + In an email conversation on the bitcoin-dev mailing list, Pieter Wuille and Thomas Zander discussed the importance of running a full node in the Bitcoin ecosystem. Wuille argued that if the incentives for running a node do not outweigh the cost or difficulty, there is a problem with the system. He believed that as Bitcoin's main advantage is the lack of need for trust, increased adoption should lead to greater incentives for people to run full nodes. However, Zander disagreed, stating that not everyone needs to run a node and that the responsibility lies with the community to make it easier for those who want to.The conversation highlighted the ongoing debate about the importance of full nodes in maintaining the decentralized nature of Bitcoin. The discussion also touched on the issue of block size and its impact on running a full node. Wuille expressed concerns about the decreasing number of full nodes in the Bitcoin ecosystem and argued that as the stakes in the system increase, so should the incentives for people to verify transactions. However, Gavin Andresen disagreed and believed that people in the Bitcoin ecosystem should be free to make their own tradeoffs between trust, centralization, and convenience. He stated that block size has little to do with the decision to run a full node.The conversation emphasized the importance of full nodes in keeping the Bitcoin network secure and immune from malicious influence. It also highlighted the need for the community to ensure accessibility and ease of running a node. The debate continues within the Bitcoin community about the role of full nodes and their significance in maintaining decentralization.In another email exchange between Gavin Andresen and Pieter Wuille in August 2015, the topic of Bitcoin's block size limit was discussed. Wuille argued that increasing the block size to 8MB would make the blockchain inaccessible for low fee transactions and unreliable for medium fee transactions if there was a sudden influx of users willing to pay high fees. However, Andresen disagreed, stating that marginal transactions would be priced out and that being able to "handle" any size is not a simple question, but depends on factors like security and risk tolerance.Andresen believed that successful companies tackle problems as they arise and are willing to deploy imperfect solutions if they help solve short-term problems. In response, Wuille disagreed, stating that he didn't see a short-term problem and expressed his dislike for being forever locked at the same scale while technology evolves. He proposed finding a solution that addressed this issue.Despite consensus being against Wuille on this point, Andresen stressed the importance of finding a non-controversial solution that did not take unnecessary risks. He acknowledged that improving the scale of the system by increasing the block size may not be fundamental, but argued that "better is better." Wuille suggested that miners form Simplified Payment Verification (SPV) mining agreements to become less affected by the block size, but Andresen disagreed with this approach.Overall, the email exchange highlighted the differing perspectives on the block size limit and the need to find a solution that balances scalability, security, and consensus within the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Humans-constantly-arguing-about-bsize-proves-that-computers-should-decide.xml b/static/bitcoin-dev/Aug_2015/combined_Humans-constantly-arguing-about-bsize-proves-that-computers-should-decide.xml index c5a2d9e1c6..3df39a7c37 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Humans-constantly-arguing-about-bsize-proves-that-computers-should-decide.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Humans-constantly-arguing-about-bsize-proves-that-computers-should-decide.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Humans constantly arguing about bsize proves that computers should decide - 2023-08-01T15:24:03.948513+00:00 + 2025-10-11T22:06:16.432213+00:00 + python-feedgen Andrew 2015-08-16 10:13:51+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Humans constantly arguing about bsize proves that computers should decide - 2023-08-01T15:24:03.948513+00:00 + 2025-10-11T22:06:16.432409+00:00 - In a post shared on the bitcoin-dev mailing list on August 16, 2015, a developer named xor expressed their opinion on the ongoing argument surrounding the block size. They proposed that rather than relying on administrators to constantly adjust a given constant, it would be more effective to delegate this task to a self-adjusting system. The developer highlighted the beauty of systems that do not require human intervention, particularly when designing a decentralized peer-to-peer (P2P) network.The author of the post suggested using a function that calculates the new maximum block size based on previous block sizes or the amount of work contributed by miners. This approach aims to put an end to the ongoing debate and allow for real development to continue. By implementing an averaging function, the new maximum block size can be determined without the need for constant manual adjustments.The post was signed by xor, who is identified as a developer working for the Freenet anonymous P2P network. The author emphasized the importance of systems that operate autonomously, as they are considered more beautiful in the context of designing a decentralized P2P network. 2015-08-16T10:13:51+00:00 + In a post shared on the bitcoin-dev mailing list on August 16, 2015, a developer named xor expressed their opinion on the ongoing argument surrounding the block size. They proposed that rather than relying on administrators to constantly adjust a given constant, it would be more effective to delegate this task to a self-adjusting system. The developer highlighted the beauty of systems that do not require human intervention, particularly when designing a decentralized peer-to-peer (P2P) network.The author of the post suggested using a function that calculates the new maximum block size based on previous block sizes or the amount of work contributed by miners. This approach aims to put an end to the ongoing debate and allow for real development to continue. By implementing an averaging function, the new maximum block size can be determined without the need for constant manual adjustments.The post was signed by xor, who is identified as a developer working for the Freenet anonymous P2P network. The author emphasized the importance of systems that operate autonomously, as they are considered more beautiful in the context of designing a decentralized P2P network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Idea-Efficient-bitcoin-block-propagation.xml b/static/bitcoin-dev/Aug_2015/combined_Idea-Efficient-bitcoin-block-propagation.xml index 2f845acd97..e1212f63b5 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Idea-Efficient-bitcoin-block-propagation.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Idea-Efficient-bitcoin-block-propagation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Idea: Efficient bitcoin block propagation - 2023-08-01T14:57:27.575394+00:00 + 2025-10-11T22:05:36.041967+00:00 + python-feedgen jl2012 at xbt.hk 2015-08-07 07:14:49+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Idea: Efficient bitcoin block propagation - 2023-08-01T14:57:27.575394+00:00 + 2025-10-11T22:05:36.042139+00:00 - The discussion on the Bitcoin-dev mailing list revolved around the BlueMatt relay network. Tom Harding asked about updated documentation on the relay network and its block compression. He also inquired if the relay network relayed an invalid post-softfork block and if it contributed to the growth of a specific fork. Additionally, he asked if the relay network would validate block version numbers in the future.Gregory Maxwell and Sergio Demian Lerner responded to the discussion. Maxwell clarified that the relay network already validates block version numbers and relays valid transactions. Lerner asked for up-to-date documentation on the relay network's block compression. Maxwell explained that the network doesn't perform compression but relays transactions verified by a local node using a FIFO method. He also mentioned resource management and transaction priority for spam attacks. However, he acknowledged that there is room for improvement in managing queues and transmitting membership sets efficiently.The discussion then shifted to larger blocks and the technical implications. Maxwell emphasized the importance of efficient relay protocols and stated that the security implications of larger blocks are related to other factors besides propagation time. He also mentioned SPV mining as a fix for high orphan rates and practical issues faced by miners. The conversation concluded with the need for good monitoring and effective communication in the industry.Arnoud Kouwenhoven from Pukaki Corp discussed feedback on Bitcoin block size optimization in an email exchange. They discussed Bitcoin Core's cached validation and the security implications of larger blocks. The concept of SPV mining, which involves blinding mining on top of other pools' stratum work, was explained. The term "VFSSP" (validation free stratum subpooling) was introduced to describe this practice. Practical issues faced by miners, such as distant colocation and slow functions, were also mentioned. The email highlighted the need for better solutions and monitoring in the industry.The relay network transmission protocol was investigated to understand its workings. The network aims to solve speed of transmission, block size, and block validation issues. It includes an optimized transmission protocol that can send the entire block using only a few packets. Trust is not required in this scheme, and small improvements could greatly enhance its efficiency. The network was deployed to prevent complete centralization in response to larger blocks.Arnoud Kouwenhoven's understanding of the bitcoin relay network was discussed on the bitcoin-dev mailing list. The current version of the relay network features an optimized transmission protocol that can send the entire block in just a small number of bytes. No trust is needed in this scheme as the whole block is communicated using only a couple of packets. The efficiency of the current scheme could be improved with small enhancements or if miners created blocks in an aware manner. However, with the current maximum block size setup, there is little reason to do so. Ultimately, communication about a block can be accomplished with a small constant amount of data, regardless of the block's size. The relay network was implemented to prevent complete centralization due to larger blocks.Another proposed solution for near-instantaneous block propagation on the bitcoin network is the introduction of bitcoin-backed guarantees between miners. This would allow miners to mine on blocks that are not fully transmitted yet, leveling the playing field for miners with slower internet connections. It also enhances the network's strength by providing a mechanism to prove the order of events. However, this proposal is only suitable for a centralized trusted party and not for a decentralized system like bitcoin.The Bitcoin Relay Network (BRN) is currently used by the majority of large miners and is accessible to anyone. It has a simple protocol that can be easily modified to relay only essential information such as headers, coinbase transactions, and small amounts of other data. This method is less complex compared to a proposed solution that would introduce bitcoin-backed guarantees between miners.Arnoud Kouwenhoven of Pukaki Corp suggests implementing "Guarantee Messages" in a proposal. This would allow miners to mine on blocks that are not fully transmitted yet, reducing the impact of slow internet connections and leveling the playing field for all miners. They believe that this approach will increase mining efficiency, decrease transaction confirmation times, and strengthen the distributed nature of bitcoin.The implementation of this idea can be done as a fork of bitcoind or as a layer between the standard bitcoind and mining equipment. It could potentially be incorporated into the bitcoin core in the future if it becomes a priority. The current version of the proposal is v.0.2 and is available in both PDF and HTML formats.The proposed solution aims to introduce bitcoin-backed guarantees between miners to enhance block propagation speed on the network, even with slow internet connections or when dealing with large block sizes. This approach allows miners to start mining on blocks that are not yet fully transmitted, thereby reducing confirmation times and strengthening the decentralized nature of bitcoin.Although there may be certain nuances that need to be addressed, the authors of the proposal welcome friendly and constructive criticism. They are also committed to answering any questions to the best 2015-08-07T07:14:49+00:00 + The discussion on the Bitcoin-dev mailing list revolved around the BlueMatt relay network. Tom Harding asked about updated documentation on the relay network and its block compression. He also inquired if the relay network relayed an invalid post-softfork block and if it contributed to the growth of a specific fork. Additionally, he asked if the relay network would validate block version numbers in the future.Gregory Maxwell and Sergio Demian Lerner responded to the discussion. Maxwell clarified that the relay network already validates block version numbers and relays valid transactions. Lerner asked for up-to-date documentation on the relay network's block compression. Maxwell explained that the network doesn't perform compression but relays transactions verified by a local node using a FIFO method. He also mentioned resource management and transaction priority for spam attacks. However, he acknowledged that there is room for improvement in managing queues and transmitting membership sets efficiently.The discussion then shifted to larger blocks and the technical implications. Maxwell emphasized the importance of efficient relay protocols and stated that the security implications of larger blocks are related to other factors besides propagation time. He also mentioned SPV mining as a fix for high orphan rates and practical issues faced by miners. The conversation concluded with the need for good monitoring and effective communication in the industry.Arnoud Kouwenhoven from Pukaki Corp discussed feedback on Bitcoin block size optimization in an email exchange. They discussed Bitcoin Core's cached validation and the security implications of larger blocks. The concept of SPV mining, which involves blinding mining on top of other pools' stratum work, was explained. The term "VFSSP" (validation free stratum subpooling) was introduced to describe this practice. Practical issues faced by miners, such as distant colocation and slow functions, were also mentioned. The email highlighted the need for better solutions and monitoring in the industry.The relay network transmission protocol was investigated to understand its workings. The network aims to solve speed of transmission, block size, and block validation issues. It includes an optimized transmission protocol that can send the entire block using only a few packets. Trust is not required in this scheme, and small improvements could greatly enhance its efficiency. The network was deployed to prevent complete centralization in response to larger blocks.Arnoud Kouwenhoven's understanding of the bitcoin relay network was discussed on the bitcoin-dev mailing list. The current version of the relay network features an optimized transmission protocol that can send the entire block in just a small number of bytes. No trust is needed in this scheme as the whole block is communicated using only a couple of packets. The efficiency of the current scheme could be improved with small enhancements or if miners created blocks in an aware manner. However, with the current maximum block size setup, there is little reason to do so. Ultimately, communication about a block can be accomplished with a small constant amount of data, regardless of the block's size. The relay network was implemented to prevent complete centralization due to larger blocks.Another proposed solution for near-instantaneous block propagation on the bitcoin network is the introduction of bitcoin-backed guarantees between miners. This would allow miners to mine on blocks that are not fully transmitted yet, leveling the playing field for miners with slower internet connections. It also enhances the network's strength by providing a mechanism to prove the order of events. However, this proposal is only suitable for a centralized trusted party and not for a decentralized system like bitcoin.The Bitcoin Relay Network (BRN) is currently used by the majority of large miners and is accessible to anyone. It has a simple protocol that can be easily modified to relay only essential information such as headers, coinbase transactions, and small amounts of other data. This method is less complex compared to a proposed solution that would introduce bitcoin-backed guarantees between miners.Arnoud Kouwenhoven of Pukaki Corp suggests implementing "Guarantee Messages" in a proposal. This would allow miners to mine on blocks that are not fully transmitted yet, reducing the impact of slow internet connections and leveling the playing field for all miners. They believe that this approach will increase mining efficiency, decrease transaction confirmation times, and strengthen the distributed nature of bitcoin.The implementation of this idea can be done as a fork of bitcoind or as a layer between the standard bitcoind and mining equipment. It could potentially be incorporated into the bitcoin core in the future if it becomes a priority. The current version of the proposal is v.0.2 and is available in both PDF and HTML formats.The proposed solution aims to introduce bitcoin-backed guarantees between miners to enhance block propagation speed on the network, even with slow internet connections or when dealing with large block sizes. This approach allows miners to start mining on blocks that are not yet fully transmitted, thereby reducing confirmation times and strengthening the decentralized nature of bitcoin.Although there may be certain nuances that need to be addressed, the authors of the proposal welcome friendly and constructive criticism. They are also committed to answering any questions to the best - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_If-you-had-a-single-chance-to-double-the-transactions-second-Bitcoin-allows-.xml b/static/bitcoin-dev/Aug_2015/combined_If-you-had-a-single-chance-to-double-the-transactions-second-Bitcoin-allows-.xml index 45dc430270..89db3d5f25 100644 --- a/static/bitcoin-dev/Aug_2015/combined_If-you-had-a-single-chance-to-double-the-transactions-second-Bitcoin-allows-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_If-you-had-a-single-chance-to-double-the-transactions-second-Bitcoin-allows-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - If you had a single chance to double the transactions/second Bitcoin allows... - 2023-08-01T15:03:35.319157+00:00 + 2025-10-11T22:05:31.794890+00:00 + python-feedgen Pieter Wuille 2015-08-10 22:31:33+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - If you had a single chance to double the transactions/second Bitcoin allows... - 2023-08-01T15:03:35.320157+00:00 + 2025-10-11T22:05:31.795061+00:00 - In an email exchange on the bitcoin-dev mailing list, Sergio Demian Lerner proposed a one-time hard fork to either double the block size or reduce the block rate to half, resulting in average 5-minute blocks. Lerner argued that reducing the block interval would save real time and address the issue of long waiting periods for confirmations. However, another member, Pieter, disagreed, stating that reducing the interblock time would double propagation delay problems and have a stronger impact on mining centralization than block size. He also criticized SPV mining and its implications for security assumptions. The email also discussed the possibility of increasing the target block creation rate to reduce the fundamental mismatch between transaction creation and block discovery. Dave Hudson's arguments supported this idea, suggesting that it could reduce miner variance and potentially aid in decentralization. However, the author questioned why this idea did not gain more traction despite its logical basis. Links to original messages, Twitter posts, and analyses were provided.Another topic of discussion was the importance of reducing payment times within the minute scale. Sergio Lerner suggested working on payment channel networks to improve Bitcoin's payment time, citing examples like paying for parking where seconds matter. Multisignature notaries were proposed as a means of ensuring double-spend protection from publication to the first block confirmation.The issue of inter-block times and their impact on the Bitcoin network was further explored. The lightning network and green address-style payment escrow were mentioned as potential solutions to eliminate the need for short inter-block times. However, risks such as channel exhaustion and larger SPV proofs needed to be considered. The significance of seconds as a time scale was emphasized, highlighting the need for some variant of multisignature notaries.In conversations with Mark and Natanael, Sergio Demian Lerner discussed the importance of response time in Bitcoin transactions. Lerner acknowledged that even a few minutes could make a difference in completing a transaction, but emphasized that seconds were what truly mattered. Multisignature notaries like Greenaddress.it and the lightning network were suggested as means of ensuring double-spend protection.In another exchange with Mark Friedenbach, the benefits and drawbacks of doubling the block size or reducing the block rate were debated. Lerner argued that most users would prefer reducing the block interval to save real time, while Friedenbach highlighted the costs to SPV proofs and mining centralization associated with halving the block interval. The question was raised as to why discussions often focused on doubling the block size rather than reducing the block interval.Overall, the context delves into various perspectives on inter-block times, block size adjustments, SPV mining, and the importance of response time in Bitcoin transactions. Different viewpoints were presented, discussing the potential benefits and concerns associated with different proposals. 2015-08-10T22:31:33+00:00 + In an email exchange on the bitcoin-dev mailing list, Sergio Demian Lerner proposed a one-time hard fork to either double the block size or reduce the block rate to half, resulting in average 5-minute blocks. Lerner argued that reducing the block interval would save real time and address the issue of long waiting periods for confirmations. However, another member, Pieter, disagreed, stating that reducing the interblock time would double propagation delay problems and have a stronger impact on mining centralization than block size. He also criticized SPV mining and its implications for security assumptions. The email also discussed the possibility of increasing the target block creation rate to reduce the fundamental mismatch between transaction creation and block discovery. Dave Hudson's arguments supported this idea, suggesting that it could reduce miner variance and potentially aid in decentralization. However, the author questioned why this idea did not gain more traction despite its logical basis. Links to original messages, Twitter posts, and analyses were provided.Another topic of discussion was the importance of reducing payment times within the minute scale. Sergio Lerner suggested working on payment channel networks to improve Bitcoin's payment time, citing examples like paying for parking where seconds matter. Multisignature notaries were proposed as a means of ensuring double-spend protection from publication to the first block confirmation.The issue of inter-block times and their impact on the Bitcoin network was further explored. The lightning network and green address-style payment escrow were mentioned as potential solutions to eliminate the need for short inter-block times. However, risks such as channel exhaustion and larger SPV proofs needed to be considered. The significance of seconds as a time scale was emphasized, highlighting the need for some variant of multisignature notaries.In conversations with Mark and Natanael, Sergio Demian Lerner discussed the importance of response time in Bitcoin transactions. Lerner acknowledged that even a few minutes could make a difference in completing a transaction, but emphasized that seconds were what truly mattered. Multisignature notaries like Greenaddress.it and the lightning network were suggested as means of ensuring double-spend protection.In another exchange with Mark Friedenbach, the benefits and drawbacks of doubling the block size or reducing the block rate were debated. Lerner argued that most users would prefer reducing the block interval to save real time, while Friedenbach highlighted the costs to SPV proofs and mining centralization associated with halving the block interval. The question was raised as to why discussions often focused on doubling the block size rather than reducing the block interval.Overall, the context delves into various perspectives on inter-block times, block size adjustments, SPV mining, and the importance of response time in Bitcoin transactions. Different viewpoints were presented, discussing the potential benefits and concerns associated with different proposals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Incentives-to-run-full-nodes.xml b/static/bitcoin-dev/Aug_2015/combined_Incentives-to-run-full-nodes.xml index 9c84b71361..ed4fcde5d7 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Incentives-to-run-full-nodes.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Incentives-to-run-full-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Incentives to run full nodes - 2023-08-01T15:28:03.532194+00:00 + 2025-10-11T22:06:48.314980+00:00 + python-feedgen odinn 2015-10-04 06:59:27+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Incentives to run full nodes - 2023-08-01T15:28:03.532194+00:00 + 2025-10-11T22:06:48.315177+00:00 - In a recent discussion on the bitcoin-development mailing list, a user named Odinn brought attention to a protocol concept called ABIS that enables the decentralization and expansion of a giving economy. Odinn referenced a post from 2013 about microdonations and incentives for running full nodes. He also mentioned new developments in Bytecoin, which implemented microdonations successfully and could potentially be applied to Bitcoin. The email thread then shifted to the security of using Simplified Payment Verification (SPV) mode. Some participants argued that SPV is not secure, as Sybil attacking the IP address space is easier than acquiring hashing power to create false confirmations. However, others pointed out that the failure model is not specific to SPV and could apply to full nodes as well.Joseph Poon emphasized the vulnerability of SPV nodes compared to full nodes in an attack scenario. He explained that with SPV, it is possible to create a transaction that spends from non-existent coins and construct an SPV proof to send funds to the victim. This attack can be "overloadable" as the attacker is never out of money. In contrast, full nodes require the attacker to sign and spend real outputs they control, and there is a chance that the victim will eventually recover their funds in a reorganization. Poon also highlighted that attackers can target thousands of people simultaneously with less hashpower using SPV validation. Although he acknowledged that some threats can be mitigated, he believed that running a full node offers stronger security, especially when handling significant amounts of money.Peter Todd echoed concerns about the security of Hearn-style SPV mode and the limited effectiveness of volunteers running full nodes. He argued that Sybil attacking the IP address space is easier than acquiring enough hashing power for false confirmations, making Hearn-style SPV similar to trusting anyone with substantial hashing power. The discussion then debated whether full nodes would fare better against attackers with significant hashing power, with some suggesting that the failure model is not exclusive to SPV.Satoshi Nakamoto acknowledged in a separate discussion the changes that have occurred in the Bitcoin network since its early days, such as the unexpected impact of pooled mining on security. Balancing competition and security remains a challenge, and there is a need for better incentives for users to run nodes beyond altruism. Peter Todd argued that incentivizing full nodes is not a priority. He reiterated concerns about the security of Hearn-style SPV mode and the limited contribution of volunteers running full nodes. Todd proposed that having peers as validating nodes primarily optimizes bandwidth, while the best incentive for validation lies in immediate failure when not validating. Gregory Maxwell's proposal for blocks to commit to separate merkle trees, one valid and one invalid, was mentioned as an example of ensuring active validation. Todd's embedded consensus ideas rely on proof-of-publication and/or anti-replay functionality, with validation becoming the responsibility of individuals or trusted parties.Overall, these discussions shed light on the security challenges associated with SPV mode and the role of full nodes in enhancing Bitcoin's security. The participants recognize the need for further exploration of incentives and protocols to ensure the integrity and reliability of the network. 2015-10-04T06:59:27+00:00 + In a recent discussion on the bitcoin-development mailing list, a user named Odinn brought attention to a protocol concept called ABIS that enables the decentralization and expansion of a giving economy. Odinn referenced a post from 2013 about microdonations and incentives for running full nodes. He also mentioned new developments in Bytecoin, which implemented microdonations successfully and could potentially be applied to Bitcoin. The email thread then shifted to the security of using Simplified Payment Verification (SPV) mode. Some participants argued that SPV is not secure, as Sybil attacking the IP address space is easier than acquiring hashing power to create false confirmations. However, others pointed out that the failure model is not specific to SPV and could apply to full nodes as well.Joseph Poon emphasized the vulnerability of SPV nodes compared to full nodes in an attack scenario. He explained that with SPV, it is possible to create a transaction that spends from non-existent coins and construct an SPV proof to send funds to the victim. This attack can be "overloadable" as the attacker is never out of money. In contrast, full nodes require the attacker to sign and spend real outputs they control, and there is a chance that the victim will eventually recover their funds in a reorganization. Poon also highlighted that attackers can target thousands of people simultaneously with less hashpower using SPV validation. Although he acknowledged that some threats can be mitigated, he believed that running a full node offers stronger security, especially when handling significant amounts of money.Peter Todd echoed concerns about the security of Hearn-style SPV mode and the limited effectiveness of volunteers running full nodes. He argued that Sybil attacking the IP address space is easier than acquiring enough hashing power for false confirmations, making Hearn-style SPV similar to trusting anyone with substantial hashing power. The discussion then debated whether full nodes would fare better against attackers with significant hashing power, with some suggesting that the failure model is not exclusive to SPV.Satoshi Nakamoto acknowledged in a separate discussion the changes that have occurred in the Bitcoin network since its early days, such as the unexpected impact of pooled mining on security. Balancing competition and security remains a challenge, and there is a need for better incentives for users to run nodes beyond altruism. Peter Todd argued that incentivizing full nodes is not a priority. He reiterated concerns about the security of Hearn-style SPV mode and the limited contribution of volunteers running full nodes. Todd proposed that having peers as validating nodes primarily optimizes bandwidth, while the best incentive for validation lies in immediate failure when not validating. Gregory Maxwell's proposal for blocks to commit to separate merkle trees, one valid and one invalid, was mentioned as an example of ensuring active validation. Todd's embedded consensus ideas rely on proof-of-publication and/or anti-replay functionality, with validation becoming the responsibility of individuals or trusted parties.Overall, these discussions shed light on the security challenges associated with SPV mode and the role of full nodes in enhancing Bitcoin's security. The participants recognize the need for further exploration of incentives and protocols to ensure the integrity and reliability of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Incentivising-full-nodes-by-having-SPV-nodes-to-pay-for-data-requests.xml b/static/bitcoin-dev/Aug_2015/combined_Incentivising-full-nodes-by-having-SPV-nodes-to-pay-for-data-requests.xml index 9eec102045..f2129e60a8 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Incentivising-full-nodes-by-having-SPV-nodes-to-pay-for-data-requests.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Incentivising-full-nodes-by-having-SPV-nodes-to-pay-for-data-requests.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Incentivising full nodes by having SPV nodes to pay for data requests - 2023-08-01T14:54:01.480795+00:00 + 2025-10-11T22:07:56.401543+00:00 + python-feedgen Eric Lombrozo 2015-08-03 17:54:12+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Incentivising full nodes by having SPV nodes to pay for data requests - 2023-08-01T14:54:01.480795+00:00 + 2025-10-11T22:07:56.401696+00:00 - The current block size debate in the Bitcoin community has highlighted the issue of decreasing full nodes, leading to a "tragedy of the commons" problem. Full nodes bear the cost of validating, relaying, and storing the blockchain without receiving any financial gain. However, these nodes play a crucial role in validating transactions and preventing miner dishonesty. As more people use Simplified Payment Verification (SPV) clients, the burden on existing full nodes increases, further reducing their numbers.The technical community opposes significant block size increases as it exacerbates the problem of decentralization. While existing hardware is capable of handling larger blocks, the core issue lies in incentivizing individuals to run full nodes. Previously, there was no trustless way to compensate full nodes for their services, especially for small micropayments. However, the concept of lightning and payment channels may provide a solution.In this proposed system, full nodes could advertise their rates to SPV nodes upon connection. The SPV nodes would then have the option to agree to the fees or seek out another node with lower charges. If implemented, competition would drive down fees to levels close to the cost of running a full node, encouraging more individuals to operate full nodes and improving decentralization in the network.Luv Khemani, in a post to the bitcoin-dev mailing list, discussed the issue of full nodes and their significance in transaction validation and maintaining the integrity of the protocol. The tragedy of the commons problem arises because full nodes bear the expenses of blockchain operations while gaining no financial benefit. As a result, the percentage of full nodes in the Bitcoin network continues to decline, particularly as more users adopt SPVs. This issue is further compounded by the fact that increasing the block size would burden existing full nodes even without an increase in demand. The core concern for the technical community is the decentralization of the network, which would be worsened by drastic block size increases.Although the hardware and bandwidth required to support larger blocks are within reach for many individuals globally, the main challenge lies in creating incentives for running full nodes. Khemani suggests that payment channels and lightning could address this issue. By allowing full nodes to advertise their rates to SPVs, competition would drive fees down to a level similar to the cost of running a full node. Consequently, this would encourage more people to operate full nodes, leading to increased decentralization in the network. 2015-08-03T17:54:12+00:00 + The current block size debate in the Bitcoin community has highlighted the issue of decreasing full nodes, leading to a "tragedy of the commons" problem. Full nodes bear the cost of validating, relaying, and storing the blockchain without receiving any financial gain. However, these nodes play a crucial role in validating transactions and preventing miner dishonesty. As more people use Simplified Payment Verification (SPV) clients, the burden on existing full nodes increases, further reducing their numbers.The technical community opposes significant block size increases as it exacerbates the problem of decentralization. While existing hardware is capable of handling larger blocks, the core issue lies in incentivizing individuals to run full nodes. Previously, there was no trustless way to compensate full nodes for their services, especially for small micropayments. However, the concept of lightning and payment channels may provide a solution.In this proposed system, full nodes could advertise their rates to SPV nodes upon connection. The SPV nodes would then have the option to agree to the fees or seek out another node with lower charges. If implemented, competition would drive down fees to levels close to the cost of running a full node, encouraging more individuals to operate full nodes and improving decentralization in the network.Luv Khemani, in a post to the bitcoin-dev mailing list, discussed the issue of full nodes and their significance in transaction validation and maintaining the integrity of the protocol. The tragedy of the commons problem arises because full nodes bear the expenses of blockchain operations while gaining no financial benefit. As a result, the percentage of full nodes in the Bitcoin network continues to decline, particularly as more users adopt SPVs. This issue is further compounded by the fact that increasing the block size would burden existing full nodes even without an increase in demand. The core concern for the technical community is the decentralization of the network, which would be worsened by drastic block size increases.Although the hardware and bandwidth required to support larger blocks are within reach for many individuals globally, the main challenge lies in creating incentives for running full nodes. Khemani suggests that payment channels and lightning could address this issue. By allowing full nodes to advertise their rates to SPVs, competition would drive fees down to a level similar to the cost of running a full node. Consequently, this would encourage more people to operate full nodes, leading to increased decentralization in the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Introduce-N-testnet-chains-to-test-different-block-sizes.xml b/static/bitcoin-dev/Aug_2015/combined_Introduce-N-testnet-chains-to-test-different-block-sizes.xml index 57a8d675c5..b45db23e71 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Introduce-N-testnet-chains-to-test-different-block-sizes.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Introduce-N-testnet-chains-to-test-different-block-sizes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Introduce N testnet chains to test different block sizes - 2023-08-01T14:14:51.296657+00:00 + 2025-10-11T22:06:18.554489+00:00 + python-feedgen Jorge Timón 2015-08-19 18:30:31+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Introduce N testnet chains to test different block sizes - 2023-08-01T14:14:51.296657+00:00 + 2025-10-11T22:06:18.554619+00:00 - In a recent conversation within the Bitcoin development community, Danny Thorpe suggested deploying an uncontroversial hard fork in Bitcoin's main chain first in testnet3. Another member expressed gratitude for the suggestion and raised a question about how big-block testnet nodes would recognize each other on the peer network. Danny clarified that although these nodes share the same port and magic numbers, each testchain has a different genesis block, which means they will reject blocks from any other testchain right from the beginning. However, he mentioned that nodes can be manually connected to achieve the desired network topology for testing purposes. Danny also noted that he didn't have time to write tests and simulations himself but encouraged others to do so and offered to answer any further questions.On Github, a pull request has been created with the aim of simplifying the testing of different block sizes. If this pull request is merged, it would not only facilitate future block size changes but also encourage more people to test and simulate various consensus maximum block sizes. This, in turn, would simplify the overall work process. The creator of the pull request specifically requested that individuals refrain from discussing the block size issue itself in both the post and the pull request. The size itself is referred to as "-blocksize". Those interested can use the branch or a fork of it for testing purposes. The listed dependencies for this pull request include Chainparams: Translations, CTestNetParams, and CRegTestParams, all of which extend directly from CChainParams. As the pull request progresses and merges occur, the list of dependencies will be updated accordingly. 2015-08-19T18:30:31+00:00 + In a recent conversation within the Bitcoin development community, Danny Thorpe suggested deploying an uncontroversial hard fork in Bitcoin's main chain first in testnet3. Another member expressed gratitude for the suggestion and raised a question about how big-block testnet nodes would recognize each other on the peer network. Danny clarified that although these nodes share the same port and magic numbers, each testchain has a different genesis block, which means they will reject blocks from any other testchain right from the beginning. However, he mentioned that nodes can be manually connected to achieve the desired network topology for testing purposes. Danny also noted that he didn't have time to write tests and simulations himself but encouraged others to do so and offered to answer any further questions.On Github, a pull request has been created with the aim of simplifying the testing of different block sizes. If this pull request is merged, it would not only facilitate future block size changes but also encourage more people to test and simulate various consensus maximum block sizes. This, in turn, would simplify the overall work process. The creator of the pull request specifically requested that individuals refrain from discussing the block size issue itself in both the post and the pull request. The size itself is referred to as "-blocksize". Those interested can use the branch or a fork of it for testing purposes. The listed dependencies for this pull request include Chainparams: Translations, CTestNetParams, and CRegTestParams, all of which extend directly from CChainParams. As the pull request progresses and merges occur, the list of dependencies will be updated accordingly. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Libconsensus-separated-repository-was-Bitcoin-Core-and-hard-forks-.xml b/static/bitcoin-dev/Aug_2015/combined_Libconsensus-separated-repository-was-Bitcoin-Core-and-hard-forks-.xml index 3e71d38cdb..f67ba22b29 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Libconsensus-separated-repository-was-Bitcoin-Core-and-hard-forks-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Libconsensus-separated-repository-was-Bitcoin-Core-and-hard-forks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Libconsensus separated repository (was Bitcoin Core and hard forks) - 2023-08-01T14:31:40.955368+00:00 + 2025-10-11T22:07:15.947203+00:00 + python-feedgen Jorge Timón 2015-08-29 23:30:39+00:00 @@ -115,13 +116,13 @@ - python-feedgen + 2 Combined summary - Libconsensus separated repository (was Bitcoin Core and hard forks) - 2023-08-01T14:31:40.956377+00:00 + 2025-10-11T22:07:15.947423+00:00 - Bitcoin developer Tamas Blummer has proposed a new infrastructure for enterprise applications, emphasizing the importance of building consensus on the ledger. He believes that enterprises have the resources to solve business problems and that mainstream adoption requires their involvement. To facilitate this, Blummer suggests a slim protocol server with no wallet, RPC, or QT, but with a high-performance remoting API.The discussion also highlights the need for modularization in Bitcoin's code. Modularization allows more people to contribute and review code, reduces risks associated with changes, and enables alternative code bases without fear of consensus bugs. Contributors like Jorge Timón, Wladimir, Pieter, Cory, Jonas Schnelli, and Eric Lombrozo advocate for modularization to resolve political challenges and improve software engineering.There is a focus on separating the BIP process into distinct areas, including consensus rule change proposals, update/deployment mechanisms, hard fork proposals, soft fork proposals, peer policies, RPC, and more. The idea is to specify core protocol layers and interfaces, allowing independent improvements and convergence on a common history and state.Tamas Blummer and Jorge Timón discuss the risks and benefits of re-implementation, refactoring, and copy-pasting in Bitcoin development. Blummer argues that quality is achieved at a high cost and is difficult to maintain over generations of developers. Timón emphasizes the need for code that is not only high quality but also easy to maintain with a development team experiencing high attrition.The conversation delves into the potential implementation of a libconsensus API, which would provide a correctly implemented consensus layer accessible to all Bitcoin developers. Blummer suggests expanding libconsensus to include functions like VerifyTx, VerifyHeader, and VerifyBlock. The plan is for the C API to interface with external storage by passing a function pointer to it.Tamas Blummer discusses his goal of creating an implementation that can extract consensus rules from Bitcoin Core so that they do not need to be re-implemented. He suggests using modern tool sets and a slim API server. Matt Corallo suggests that a libconsensus should ideally have a simple API for blocks and the current chain, with the possibility of pluggable block storage. Tamas Blummer expresses his eagerness to integrate secp256k1 (c) as part of consensus. Jorge Timon highlights the importance of extracting consensus rules from Bitcoin Core to avoid the need for future re-implementations. He proposes steps to implement libconsensus in Bitcoin Core, but acknowledges the risk of consensus fork bugs during the process. Eric Voskuil disagrees with forking Bitcoin Core and suggests separating libconsensus into a separate repository. In a conversation between Wladimir J. van der Laan and Jorge Timón, they discuss the possibility of Bitcoin Core using libconsensus. Wladimir notes the risk of introducing fork bugs if the code is refactored, but expresses support for the change if this can be avoided. They also discuss the need for code review capacity and the possibility of using libsecp256k1 instead of OpenSSL.The discussion focuses on separating current-libconsensus from future-libconsensus in the Bitcoin Core code. The plan is to complete future-libconsensus that implements all consensus rules and expose more functions through its API. There are concerns about code incompatibility and the need for code review capacity. The author maintains a fork of consensus sources until they are properly isolated from the satoshi client. They express willingness to work on the project but note that fear of consensus bugs keeps people on the satoshi client.Eric Voskuil discusses the removal of the OpenSSL dependency in their stack and the activation of BIP66. The need for a separate repository for libconsensus is mentioned to ensure alternative implementations can be consensus-safe.In conclusion, there is a strong discussion about the creation and implementation of libconsensus to extract consensus rules from Bitcoin Core. The goal is to avoid re-implementations and allow for the creation of other blockchains with different rules. There are discussions about the API, pluggable block storage, and the integration of secp256k1 (c). Concerns about code compatibility, code review capacity, and OpenSSL dependency are also addressed.The goal of the Bitcoin Core codebase is to be modularized, allowing for easy swapping out of consensus rules and reducing the risk of consensus fork bugs. Mike Hearn, a Bitcoin developer, expressed his desire for Bitcoin Core to have a benevolent dictator, similar to other free software projects. This is because decentralization still requires someone to make decisions for changes to occur.In an email exchange in 2015, Jorge Timón apologized for mentioning Mike Hearn and diverting attention from the topic at hand. Timón referenced Hearn's desire for a benevolent dictator but clarified that it was not relevant to the discussion of libconsensus, which focuses on alternative implementations and the ability to fork smaller projects without relying on Bitcoin Core.Another email exchange on 2015-08-29T23:30:39+00:00 + Bitcoin developer Tamas Blummer has proposed a new infrastructure for enterprise applications, emphasizing the importance of building consensus on the ledger. He believes that enterprises have the resources to solve business problems and that mainstream adoption requires their involvement. To facilitate this, Blummer suggests a slim protocol server with no wallet, RPC, or QT, but with a high-performance remoting API.The discussion also highlights the need for modularization in Bitcoin's code. Modularization allows more people to contribute and review code, reduces risks associated with changes, and enables alternative code bases without fear of consensus bugs. Contributors like Jorge Timón, Wladimir, Pieter, Cory, Jonas Schnelli, and Eric Lombrozo advocate for modularization to resolve political challenges and improve software engineering.There is a focus on separating the BIP process into distinct areas, including consensus rule change proposals, update/deployment mechanisms, hard fork proposals, soft fork proposals, peer policies, RPC, and more. The idea is to specify core protocol layers and interfaces, allowing independent improvements and convergence on a common history and state.Tamas Blummer and Jorge Timón discuss the risks and benefits of re-implementation, refactoring, and copy-pasting in Bitcoin development. Blummer argues that quality is achieved at a high cost and is difficult to maintain over generations of developers. Timón emphasizes the need for code that is not only high quality but also easy to maintain with a development team experiencing high attrition.The conversation delves into the potential implementation of a libconsensus API, which would provide a correctly implemented consensus layer accessible to all Bitcoin developers. Blummer suggests expanding libconsensus to include functions like VerifyTx, VerifyHeader, and VerifyBlock. The plan is for the C API to interface with external storage by passing a function pointer to it.Tamas Blummer discusses his goal of creating an implementation that can extract consensus rules from Bitcoin Core so that they do not need to be re-implemented. He suggests using modern tool sets and a slim API server. Matt Corallo suggests that a libconsensus should ideally have a simple API for blocks and the current chain, with the possibility of pluggable block storage. Tamas Blummer expresses his eagerness to integrate secp256k1 (c) as part of consensus. Jorge Timon highlights the importance of extracting consensus rules from Bitcoin Core to avoid the need for future re-implementations. He proposes steps to implement libconsensus in Bitcoin Core, but acknowledges the risk of consensus fork bugs during the process. Eric Voskuil disagrees with forking Bitcoin Core and suggests separating libconsensus into a separate repository. In a conversation between Wladimir J. van der Laan and Jorge Timón, they discuss the possibility of Bitcoin Core using libconsensus. Wladimir notes the risk of introducing fork bugs if the code is refactored, but expresses support for the change if this can be avoided. They also discuss the need for code review capacity and the possibility of using libsecp256k1 instead of OpenSSL.The discussion focuses on separating current-libconsensus from future-libconsensus in the Bitcoin Core code. The plan is to complete future-libconsensus that implements all consensus rules and expose more functions through its API. There are concerns about code incompatibility and the need for code review capacity. The author maintains a fork of consensus sources until they are properly isolated from the satoshi client. They express willingness to work on the project but note that fear of consensus bugs keeps people on the satoshi client.Eric Voskuil discusses the removal of the OpenSSL dependency in their stack and the activation of BIP66. The need for a separate repository for libconsensus is mentioned to ensure alternative implementations can be consensus-safe.In conclusion, there is a strong discussion about the creation and implementation of libconsensus to extract consensus rules from Bitcoin Core. The goal is to avoid re-implementations and allow for the creation of other blockchains with different rules. There are discussions about the API, pluggable block storage, and the integration of secp256k1 (c). Concerns about code compatibility, code review capacity, and OpenSSL dependency are also addressed.The goal of the Bitcoin Core codebase is to be modularized, allowing for easy swapping out of consensus rules and reducing the risk of consensus fork bugs. Mike Hearn, a Bitcoin developer, expressed his desire for Bitcoin Core to have a benevolent dictator, similar to other free software projects. This is because decentralization still requires someone to make decisions for changes to occur.In an email exchange in 2015, Jorge Timón apologized for mentioning Mike Hearn and diverting attention from the topic at hand. Timón referenced Hearn's desire for a benevolent dictator but clarified that it was not relevant to the discussion of libconsensus, which focuses on alternative implementations and the ability to fork smaller projects without relying on Bitcoin Core.Another email exchange on - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Miners-are-struggling-with-blocks-far-smaller-than-750KB-blocks-and-resorting-to-SPV-mining.xml b/static/bitcoin-dev/Aug_2015/combined_Miners-are-struggling-with-blocks-far-smaller-than-750KB-blocks-and-resorting-to-SPV-mining.xml index ef8cf33c95..f57588d1e2 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Miners-are-struggling-with-blocks-far-smaller-than-750KB-blocks-and-resorting-to-SPV-mining.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Miners-are-struggling-with-blocks-far-smaller-than-750KB-blocks-and-resorting-to-SPV-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining - 2023-08-01T15:26:00.259025+00:00 + 2025-10-11T22:06:52.563374+00:00 + python-feedgen Timo Hanke 2015-08-20 14:27:20+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining - 2023-08-01T15:26:00.259025+00:00 + 2025-10-11T22:06:52.563525+00:00 - A member of the bitcoin-dev mailing list has expressed concern over miners producing empty blocks despite having fully verified the previous block, leading to suspicion that the mining hardware and software itself may be at fault. Empty blocks have been mined by several different pools despite there being preceding blocks as small as 50KB with 30s passing and the miner continues to mine empty blocks via SPV mining. If miners are SPV mining for a significant portion of the hashing power, all a single malicious miner has to do is mine an invalid block on purpose, let these pools SPV mine on top of them while it mines a valid block free of their competition. The impact of this could be more mining centralization, which is already too centralized today. A post on the bitcoin-dev mailing list indicates that nodes are technically capable of handling blocks larger than the current block size limit. However, data shows that even miners who have all the incentives are struggling to download and validate much smaller blocks. Empty blocks have been mined despite a non-trivial elapsed time from the previous block. This is concerning because if miners continue to SPV mine for a whole minute, a malicious miner could mine an invalid block on purpose and let these pools SPV mine on top of them while it mines a valid block free of their competition. This would lead to reorgs and many block orphans for anyone not running a full node, which could be disastrous in the XT world where Mike wants everyone to be running SPV nodes. The impact of this could be more mining centralization, which is already too centralized today. It is unclear why this is happening, and there are several steps of latency involved in the process.The author of an email to the bitcoin-dev mailing list is concerned about the capacity of miners to handle smaller blocks. The author notes that while half a million dollars in revenue may seem like a lot, it means little if running costs are also high. The author points out that there have been instances where miners have been struggling to download and validate much smaller blocks, leading to empty blocks being mined despite non-trivial elapsed time from the previous block. The author suggests that this could be due to bad mining codes or laziness on the part of miners. The author is particularly worried about the implications of miners resorting to SPV mining, as this could lead to disastrous consequences in the event of a malicious miner mining an invalid block on purpose. If these pools go out of business, it would lead to even more mining centralization which is already too centralized today. The author calls for representatives of these pools to comment on why this is happening and whether they are on Matt's relay network.The bandwidth and validating capacity of the global mining network is causing concern for bitcoin developers. Despite having all the incentives, miners are still struggling to download and validate small blocks. This is proven by empty blocks mined despite a non-trivial elapsed time from the previous block. The most glaring case is Block 370057, where despite 73 seconds elapsing and the preceding block being a mere 131KB, the miner was unable to download/validate fast enough to include transactions in their block. If miners are SPV mining for a whole minute for just fall apart as a significant portion of the hashing power SPV mines throughout. This could lead to disastrous consequences if a single malicious miner mines an invalid block on purpose and lets these pools SPV mine on top of them while it mines a valid block free of their competition. It could impact reorgs and many block orphans for anyone not running a full node, which could be disastrous, especially more so in the XT world where Mike wants everyone to be running SPV nodes.The author has been monitoring the blockchain and noticed that even miners are struggling to download and validate smaller blocks. They believe that nodes are capable of handling blocks much larger than the current block size limit, but there is no incentive to run them. The data shows empty blocks being mined despite a non-trivial elapsed time from the previous block, and some miners are continuing to mine empty blocks via SPV mining even with preceding blocks as small as 50KB. This raises concerns about the global mining network's bandwidth and validating capacity. Unless miners are intentionally mining empty blocks, which does not make sense, this issue needs to be addressed. 2015-08-20T14:27:20+00:00 + A member of the bitcoin-dev mailing list has expressed concern over miners producing empty blocks despite having fully verified the previous block, leading to suspicion that the mining hardware and software itself may be at fault. Empty blocks have been mined by several different pools despite there being preceding blocks as small as 50KB with 30s passing and the miner continues to mine empty blocks via SPV mining. If miners are SPV mining for a significant portion of the hashing power, all a single malicious miner has to do is mine an invalid block on purpose, let these pools SPV mine on top of them while it mines a valid block free of their competition. The impact of this could be more mining centralization, which is already too centralized today. A post on the bitcoin-dev mailing list indicates that nodes are technically capable of handling blocks larger than the current block size limit. However, data shows that even miners who have all the incentives are struggling to download and validate much smaller blocks. Empty blocks have been mined despite a non-trivial elapsed time from the previous block. This is concerning because if miners continue to SPV mine for a whole minute, a malicious miner could mine an invalid block on purpose and let these pools SPV mine on top of them while it mines a valid block free of their competition. This would lead to reorgs and many block orphans for anyone not running a full node, which could be disastrous in the XT world where Mike wants everyone to be running SPV nodes. The impact of this could be more mining centralization, which is already too centralized today. It is unclear why this is happening, and there are several steps of latency involved in the process.The author of an email to the bitcoin-dev mailing list is concerned about the capacity of miners to handle smaller blocks. The author notes that while half a million dollars in revenue may seem like a lot, it means little if running costs are also high. The author points out that there have been instances where miners have been struggling to download and validate much smaller blocks, leading to empty blocks being mined despite non-trivial elapsed time from the previous block. The author suggests that this could be due to bad mining codes or laziness on the part of miners. The author is particularly worried about the implications of miners resorting to SPV mining, as this could lead to disastrous consequences in the event of a malicious miner mining an invalid block on purpose. If these pools go out of business, it would lead to even more mining centralization which is already too centralized today. The author calls for representatives of these pools to comment on why this is happening and whether they are on Matt's relay network.The bandwidth and validating capacity of the global mining network is causing concern for bitcoin developers. Despite having all the incentives, miners are still struggling to download and validate small blocks. This is proven by empty blocks mined despite a non-trivial elapsed time from the previous block. The most glaring case is Block 370057, where despite 73 seconds elapsing and the preceding block being a mere 131KB, the miner was unable to download/validate fast enough to include transactions in their block. If miners are SPV mining for a whole minute for just fall apart as a significant portion of the hashing power SPV mines throughout. This could lead to disastrous consequences if a single malicious miner mines an invalid block on purpose and lets these pools SPV mine on top of them while it mines a valid block free of their competition. It could impact reorgs and many block orphans for anyone not running a full node, which could be disastrous, especially more so in the XT world where Mike wants everyone to be running SPV nodes.The author has been monitoring the blockchain and noticed that even miners are struggling to download and validate smaller blocks. They believe that nodes are capable of handling blocks much larger than the current block size limit, but there is no incentive to run them. The data shows empty blocks being mined despite a non-trivial elapsed time from the previous block, and some miners are continuing to mine empty blocks via SPV mining even with preceding blocks as small as 50KB. This raises concerns about the global mining network's bandwidth and validating capacity. Unless miners are intentionally mining empty blocks, which does not make sense, this issue needs to be addressed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Minimum-Block-Size.xml b/static/bitcoin-dev/Aug_2015/combined_Minimum-Block-Size.xml index 2c16158216..c971b762ae 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Minimum-Block-Size.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Minimum-Block-Size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Minimum Block Size - 2023-08-01T15:24:15.646765+00:00 + 2025-10-11T22:07:35.086084+00:00 + python-feedgen Jorge Timón 2015-08-17 16:18:45+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Minimum Block Size - 2023-08-01T15:24:15.646765+00:00 + 2025-10-11T22:07:35.086244+00:00 - In August 2015, a discussion on the bitcoin-dev mailing list revolved around the idea of implementing a minimum block size for Bitcoin. Levin Keller initiated the conversation by asking if anyone supported a minimum block size of 2 MB or more. However, Patrick Strateman disagreed, stating that he did not see any value in requiring a minimum block size.Jeff Garzik chimed in, pointing out that traffic levels may not always produce a minimum-sized block and that miners could collude to produce a lowered maximum block size, which he referred to as a "minimum maximum." Another concern raised was the fact that miners could pay themselves with a matured satoshi multiple times in the same block, rendering the minimum block size rule ineffective for SPV mining.Overall, the discussion did not result in any concrete conclusions or proposals regarding the implementation of a minimum block size. The topic remains complex, with no straightforward statements from most developers on specific block sizes. Workshops are being organized to address these issues, with the first workshop scheduled for September 12-13th. Interested participants can visit http://scalingbitcoin.org/ to participate in these workshops. 2015-08-17T16:18:45+00:00 + In August 2015, a discussion on the bitcoin-dev mailing list revolved around the idea of implementing a minimum block size for Bitcoin. Levin Keller initiated the conversation by asking if anyone supported a minimum block size of 2 MB or more. However, Patrick Strateman disagreed, stating that he did not see any value in requiring a minimum block size.Jeff Garzik chimed in, pointing out that traffic levels may not always produce a minimum-sized block and that miners could collude to produce a lowered maximum block size, which he referred to as a "minimum maximum." Another concern raised was the fact that miners could pay themselves with a matured satoshi multiple times in the same block, rendering the minimum block size rule ineffective for SPV mining.Overall, the discussion did not result in any concrete conclusions or proposals regarding the implementation of a minimum block size. The topic remains complex, with no straightforward statements from most developers on specific block sizes. Workshops are being organized to address these issues, with the first workshop scheduled for September 12-13th. Interested participants can visit http://scalingbitcoin.org/ to participate in these workshops. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Off-chain-transactions-and-miner-fees.xml b/static/bitcoin-dev/Aug_2015/combined_Off-chain-transactions-and-miner-fees.xml index e8c3998018..40c4e7970d 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Off-chain-transactions-and-miner-fees.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Off-chain-transactions-and-miner-fees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Off-chain transactions and miner fees - 2023-08-01T15:06:28.924916+00:00 + 2025-10-11T22:06:39.814878+00:00 + python-feedgen Thomas Zander 2015-08-10 21:16:11+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Off-chain transactions and miner fees - 2023-08-01T15:06:28.924916+00:00 + 2025-10-11T22:06:39.815077+00:00 - In August 2015, a discussion among bitcoin developers took place regarding the efficiency of the Lightning Network (LN) and whether users would be willing to pay higher fees for limited blockchain space. Some argued that grouping multiple real-world payments into one transaction on the LN could justify the higher fees, while others believed paying for unnecessary services was not a good business strategy.The belief that transaction fees are necessary to reward miners and secure the network is not universally held. It was stated that Bitcoin mining is financed by a fixed schedule of inflation and transaction fees, which differ from state inflation and are based on voluntary trade. There was also a distinction made between voluntary trade and state-controlled trade, which contributed to confusion and misunderstanding in the block size debate. Bitcoin was seen as resistant to state control and did not have a commons problem.A discussion on the time value of bitcoin took place between Anthony Towns and Hector Chu. Towns argued that the time value of bitcoin was effectively zero, as people mostly hold onto their coins hoping for appreciation. Chu countered that bitcoin could be exchanged for fiat currency and held for interest, but Towns pointed out that this strategy only works if the interest rate on the fiat account exceeds the price rise in bitcoin. Towns concluded that people were earning 0% denominated in bitcoin with a time-value of zero.The potential impact of the Lightning Network on transaction fees was discussed in multiple email exchanges. It was debated whether Lightning transactions would result in higher fees due to limited space and competition. Some argued that it would be more beneficial to pay miners rather than off-chain service providers if there were no limits. The Lightning Network was seen as raising the value of transactions on the blockchain, allowing nodes to attach larger fees to settlement transactions. However, concerns were raised about the extraction of fees from miners and the potential harm to Bitcoin's security.The conflict between rewarding miners with transaction fees and moving transactions off-chain has not been fully addressed. The Lightning Network provides nodes with fees that were previously unavailable to miners, but there are concerns about the impact on mining rewards and network security. Off-chain transactions could potentially crowd out low-value transactions on-chain. The debate continues regarding the implications of off-chain transactions and their effects on the Bitcoin ecosystem.In summary, discussions among bitcoin developers have focused on the efficiency and implications of the Lightning Network, the time value of bitcoin, and the conflict between rewarding miners and moving transactions off-chain. The potential impact on transaction fees, network security, and mining rewards has been a topic of debate within the bitcoin community. 2015-08-10T21:16:11+00:00 + In August 2015, a discussion among bitcoin developers took place regarding the efficiency of the Lightning Network (LN) and whether users would be willing to pay higher fees for limited blockchain space. Some argued that grouping multiple real-world payments into one transaction on the LN could justify the higher fees, while others believed paying for unnecessary services was not a good business strategy.The belief that transaction fees are necessary to reward miners and secure the network is not universally held. It was stated that Bitcoin mining is financed by a fixed schedule of inflation and transaction fees, which differ from state inflation and are based on voluntary trade. There was also a distinction made between voluntary trade and state-controlled trade, which contributed to confusion and misunderstanding in the block size debate. Bitcoin was seen as resistant to state control and did not have a commons problem.A discussion on the time value of bitcoin took place between Anthony Towns and Hector Chu. Towns argued that the time value of bitcoin was effectively zero, as people mostly hold onto their coins hoping for appreciation. Chu countered that bitcoin could be exchanged for fiat currency and held for interest, but Towns pointed out that this strategy only works if the interest rate on the fiat account exceeds the price rise in bitcoin. Towns concluded that people were earning 0% denominated in bitcoin with a time-value of zero.The potential impact of the Lightning Network on transaction fees was discussed in multiple email exchanges. It was debated whether Lightning transactions would result in higher fees due to limited space and competition. Some argued that it would be more beneficial to pay miners rather than off-chain service providers if there were no limits. The Lightning Network was seen as raising the value of transactions on the blockchain, allowing nodes to attach larger fees to settlement transactions. However, concerns were raised about the extraction of fees from miners and the potential harm to Bitcoin's security.The conflict between rewarding miners with transaction fees and moving transactions off-chain has not been fully addressed. The Lightning Network provides nodes with fees that were previously unavailable to miners, but there are concerns about the impact on mining rewards and network security. Off-chain transactions could potentially crowd out low-value transactions on-chain. The debate continues regarding the implications of off-chain transactions and their effects on the Bitcoin ecosystem.In summary, discussions among bitcoin developers have focused on the efficiency and implications of the Lightning Network, the time value of bitcoin, and the conflict between rewarding miners and moving transactions off-chain. The potential impact on transaction fees, network security, and mining rewards has been a topic of debate within the bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets.xml b/static/bitcoin-dev/Aug_2015/combined_On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets.xml index 4d63967194..db064cfd38 100644 --- a/static/bitcoin-dev/Aug_2015/combined_On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets.xml +++ b/static/bitcoin-dev/Aug_2015/combined_On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On the Nature of Miner Advantages in Uncapped Block Size Fee Markets - 2023-08-01T15:48:17.326551+00:00 + 2025-10-11T22:07:26.575578+00:00 + python-feedgen Matt Corallo 2015-08-30 03:56:47+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - On the Nature of Miner Advantages in Uncapped Block Size Fee Markets - 2023-08-01T15:48:17.326551+00:00 + 2025-10-11T22:07:26.575706+00:00 - The email thread discusses the effects of transaction validation caches and block compression protocols on the fee market in a scenario of uncapped block sizes. It is noted that large miners have their own network to pre-relay blocks globally, reducing relay times for transactions. The orphan risk for including a transaction can be reduced to a tiny amount by including everything in the mempool of reasonably large miners. However, this system disadvantages small miners and provides incentives for network centralization. Peter R argues that as long as block solution announcements contain information about the transactions included in a block, the fee market will remain healthy. He references the Shannon-Hartley theorem to support this claim. Matt Corallo points out that transaction validation caches and block compression protocols also need to be considered. He mentions that many large miners already have their own network for block relaying and suggests using the bitcoinrelaynetwork.org network for smaller miners. Daniele Pinna submits a paper analyzing how miner advantages scale with network and mempool properties in uncapped block sizes. The paper examines the incentivization of pooling large hashrates due to large block subsidies and increasing marginal profits. It also highlights the barrier to entry into a high-efficiency mining class that contributes to the advantage of large miners. As block subsidies decrease, this class is expected to disappear, resulting in a marginal profit structure that decreases with hashrate.The discussion raises concerns about the centralization of the network and the disadvantages faced by small miners. Transaction validation time is considered negligible, and the optimal block size is suggested to include everything in the mempool of other large miners. Peter R's argument about the healthiness of the fee market is supported by the Shannon-Hartley theorem. Daniele Pinna's submitted paper reignites consideration of a block size scaling proposal (BIP101) and addresses criticisms of Peter R's work. The email thread ends with Daniele expressing his involvement in the block size scaling proposal and his preference for BIP102 as an uncontroversial hardfork option. 2015-08-30T03:56:47+00:00 + The email thread discusses the effects of transaction validation caches and block compression protocols on the fee market in a scenario of uncapped block sizes. It is noted that large miners have their own network to pre-relay blocks globally, reducing relay times for transactions. The orphan risk for including a transaction can be reduced to a tiny amount by including everything in the mempool of reasonably large miners. However, this system disadvantages small miners and provides incentives for network centralization. Peter R argues that as long as block solution announcements contain information about the transactions included in a block, the fee market will remain healthy. He references the Shannon-Hartley theorem to support this claim. Matt Corallo points out that transaction validation caches and block compression protocols also need to be considered. He mentions that many large miners already have their own network for block relaying and suggests using the bitcoinrelaynetwork.org network for smaller miners. Daniele Pinna submits a paper analyzing how miner advantages scale with network and mempool properties in uncapped block sizes. The paper examines the incentivization of pooling large hashrates due to large block subsidies and increasing marginal profits. It also highlights the barrier to entry into a high-efficiency mining class that contributes to the advantage of large miners. As block subsidies decrease, this class is expected to disappear, resulting in a marginal profit structure that decreases with hashrate.The discussion raises concerns about the centralization of the network and the disadvantages faced by small miners. Transaction validation time is considered negligible, and the optimal block size is suggested to include everything in the mempool of other large miners. Peter R's argument about the healthiness of the fee market is supported by the Shannon-Hartley theorem. Daniele Pinna's submitted paper reignites consideration of a block size scaling proposal (BIP101) and addresses criticisms of Peter R's work. The email thread ends with Daniele expressing his involvement in the block size scaling proposal and his preference for BIP102 as an uncontroversial hardfork option. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml b/static/bitcoin-dev/Aug_2015/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml index b985c20ef0..ba5fbce0a8 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report - 2023-08-01T15:02:51.488157+00:00 + 2025-10-11T22:05:50.912551+00:00 + python-feedgen Gregory Maxwell 2016-03-01 00:57:58+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report - 2023-08-01T15:02:51.488157+00:00 + 2025-10-11T22:05:50.912690+00:00 - In the Bitcoin-dev mailing list conversation, Wei initiates a discussion on the privacy features of the Bitcoin-Qt wallet application. Kristov Atlas responds with his best guesses, highlighting key aspects of the application's privacy features.Bitcoin-Qt implements cryptographic randomization of transaction ordering, which provides maximum privacy. However, the BIP 69 recommendation could also offer the same level of privacy if universally used. The joinmarket module can be used with Bitcoin-Qt to incorporate coinjoins. Currently, there are no decentralized mixing tools available that do not harm user privacy.The article mentions that Bitcoin-Qt does not implement anti-features like donations and always maintains the highest possible FP rate. To obtain balance information, the software makes remote queries, but users can direct these queries to use Tor for all communications. All network connections are independent via Tor by default, ensuring privacy. Separate wallets are required for separate "identities".One concern raised is that an attacker could deduce that transactions come from the same client by observing transactions signed by private keys from multiple wallets. However, changing the wallet ensures that the node no longer knows any of them.The article emphasizes that reliable deletion of private data is not feasible on current hardware/OSes. Therefore, users are advised to use OS-level encryption for local privacy protection. Backups are stored locally, and there is no linkage to email or SMS.Bitcoin-Qt does not perform any external lookup related to identifying transaction senders or recipients. It connects to known p2p full nodes to bootstrap the connection to the Bitcoin p2p network. Users are recommended to run Tor to prevent identifiable traffic, except for timing/volume analysis.The application allows users to encrypt the wallet file with a password, preventing decryption of private keys without the password. Each wallet file can have its own single password for spending protection, and there is no custodianship involved. The article notes that no obvious telemetry data is being sent.Regarding the source code and building process, the application supports a deterministic build process actively audited by multiple parties who post cryptographic signatures of their duplicated builds. This ensures that users can compile the application themselves in a manner that produces an identical binary version to the distributed one.In conclusion, the email thread provides answers to various privacy and security questions related to Bitcoin-Qt. It addresses transaction formatting, mixing, donations, balance queries, network privacy, physical access, custodianship, telemetry data, and source code and building. The Open Bitcoin Privacy Project includes Bitcoin-Qt in its survey to measure wallet privacy and requests developers to answer a set of questions about how different wallets handle these aspects. 2016-03-01T00:57:58+00:00 + In the Bitcoin-dev mailing list conversation, Wei initiates a discussion on the privacy features of the Bitcoin-Qt wallet application. Kristov Atlas responds with his best guesses, highlighting key aspects of the application's privacy features.Bitcoin-Qt implements cryptographic randomization of transaction ordering, which provides maximum privacy. However, the BIP 69 recommendation could also offer the same level of privacy if universally used. The joinmarket module can be used with Bitcoin-Qt to incorporate coinjoins. Currently, there are no decentralized mixing tools available that do not harm user privacy.The article mentions that Bitcoin-Qt does not implement anti-features like donations and always maintains the highest possible FP rate. To obtain balance information, the software makes remote queries, but users can direct these queries to use Tor for all communications. All network connections are independent via Tor by default, ensuring privacy. Separate wallets are required for separate "identities".One concern raised is that an attacker could deduce that transactions come from the same client by observing transactions signed by private keys from multiple wallets. However, changing the wallet ensures that the node no longer knows any of them.The article emphasizes that reliable deletion of private data is not feasible on current hardware/OSes. Therefore, users are advised to use OS-level encryption for local privacy protection. Backups are stored locally, and there is no linkage to email or SMS.Bitcoin-Qt does not perform any external lookup related to identifying transaction senders or recipients. It connects to known p2p full nodes to bootstrap the connection to the Bitcoin p2p network. Users are recommended to run Tor to prevent identifiable traffic, except for timing/volume analysis.The application allows users to encrypt the wallet file with a password, preventing decryption of private keys without the password. Each wallet file can have its own single password for spending protection, and there is no custodianship involved. The article notes that no obvious telemetry data is being sent.Regarding the source code and building process, the application supports a deterministic build process actively audited by multiple parties who post cryptographic signatures of their duplicated builds. This ensures that users can compile the application themselves in a manner that produces an identical binary version to the distributed one.In conclusion, the email thread provides answers to various privacy and security questions related to Bitcoin-Qt. It addresses transaction formatting, mixing, donations, balance queries, network privacy, physical access, custodianship, telemetry data, and source code and building. The Open Bitcoin Privacy Project includes Bitcoin-Qt in its survey to measure wallet privacy and requests developers to answer a set of questions about how different wallets handle these aspects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Proposal-Disable-digests-on-bitcoin-dev.xml b/static/bitcoin-dev/Aug_2015/combined_Proposal-Disable-digests-on-bitcoin-dev.xml index 35a8b1d7f8..c976cd97fe 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Proposal-Disable-digests-on-bitcoin-dev.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Proposal-Disable-digests-on-bitcoin-dev.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: Disable digests on bitcoin-dev - 2023-08-01T15:53:05.425115+00:00 + 2025-10-11T22:07:18.081646+00:00 + python-feedgen Augusto Radtke 2015-08-31 23:46:32+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Proposal: Disable digests on bitcoin-dev - 2023-08-01T15:53:05.425115+00:00 + 2025-10-11T22:07:18.081777+00:00 - On September 1, 2015, Warren Togami Jr. proposed the idea of disabling the ability to subscribe with digests on the bitcoin-dev list. He argued that digests were from an earlier era of Internet history and were inconvenient for everyone because replies have the problem of breaking threads. Warren Togami suggested that people should be setting mail filters to separate list mail from other mail instead. He believed that digests were not a net-positive for the Bitcoin community and thus, the ability to use them should be turned off. Although some may find this decision annoying, it was deemed necessary for the benefit of the majority. 2015-08-31T23:46:32+00:00 + On September 1, 2015, Warren Togami Jr. proposed the idea of disabling the ability to subscribe with digests on the bitcoin-dev list. He argued that digests were from an earlier era of Internet history and were inconvenient for everyone because replies have the problem of breaking threads. Warren Togami suggested that people should be setting mail filters to separate list mail from other mail instead. He believed that digests were not a net-positive for the Bitcoin community and thus, the ability to use them should be turned off. Although some may find this decision annoying, it was deemed necessary for the benefit of the majority. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml b/static/bitcoin-dev/Aug_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml index e3d6d85bb9..80c1f674f3 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed new policy for transactions that depend on other unconfirmed transactions - 2023-08-01T15:15:59.869443+00:00 + 2025-10-11T22:06:01.541634+00:00 + python-feedgen Taariq Lewis 2015-10-08 06:10:37+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Proposed new policy for transactions that depend on other unconfirmed transactions - 2023-08-01T15:15:59.869443+00:00 + 2025-10-11T22:06:01.541815+00:00 - The proposed policy limits on unconfirmed transaction chains in Bitcoin Core are currently under discussion among developers. The existing limits for descendant packages are 1000 transactions and 2500kb total size, while for ancestor packages, the limits are 100 transactions and 900kb total size. However, there is a proposal to change these limits to 25 transactions and 100kb total size for both types of packages. It is important to note that these proposed limits are not a change to consensus rules and can be adjusted on an individual node basis in Bitcoin Core.In addition to the proposed limits on unconfirmed transaction chains, Alex Morcos has put forward a set of requirements for accepting new transactions into the mempool and relaying them. The aim of this policy is to limit the size of the mempool and ensure that a new transaction can cover the costs of any dependent transactions it may displace. Four new policy limits have been proposed, all of which can be configured using command line settings. In April and May of this year, these proposed limits would have affected less than 2% of transactions entering the mempool. However, during a stress test period, as many as 25% of transactions would have been impacted.The reason for reducing the limits on unconfirmed transaction chains is primarily due to concerns about mempool congestion and relay fee boosting attacks. The current limits for ancestor packages are 100 transactions and 900kb total size, while for descendant packages, the limits are 1000 transactions and 2500kb total size. The proposed new limits for both types of packages would be 25 transactions and 100kb total size. It is worth noting that these limits do not alter consensus rules and can be customized for each individual node using Bitcoin Core.Alex Morcos has made significant proposals to decrease the current policy limits on unconfirmed transaction chains. The existing limits for ancestor packages are 100 transactions and 900 kilobytes of total size, while for descendant packages, the limits are 1000 transactions and 2500 kilobytes of total size. The proposed new limits for both types of packages are 25 transactions and 100 kilobytes of total size. These limits can be adjusted at the command line level on each node that utilizes Bitcoin Core.To ensure a smooth and efficient transaction process, certain limits have been established. The first limit restricts transactions larger than 100 kilobytes from being accepted. This ensures that the size of transactions remains within a reasonable range. The second limit focuses on the fee rate, disallowing transactions with a fee rate equal to or less than 1 satoshi per byte. This encourages users to attach an appropriate fee, which helps prioritize their transactions. The third limit aims to prevent transaction flooding attacks by rejecting transactions that would cause the mempool's total size to exceed 300 megabytes. This safeguard protects the network from becoming overwhelmed by a large number of transactions. Lastly, the fourth limit maintains the policy that all transactions in the mempool should be mineable in the next block. To achieve this, transactions will not be accepted if the total size of all unconfirmed ancestor transactions is too large. By default, this limit is set at 1 megabyte.It is important to note that these limits would have affected less than 2% of transactions entering the mempool in April or May of this year. However, during the stress test period from July 6th to July 14th, up to 25% of the transactions would have been impacted. For those interested in the technical details, the code to implement these changes can be found in pull request 6557, which is based on pull request 6470. These pull requests contain the necessary modifications to enforce the aforementioned limits and enhance the overall transaction process. 2015-10-08T06:10:37+00:00 + The proposed policy limits on unconfirmed transaction chains in Bitcoin Core are currently under discussion among developers. The existing limits for descendant packages are 1000 transactions and 2500kb total size, while for ancestor packages, the limits are 100 transactions and 900kb total size. However, there is a proposal to change these limits to 25 transactions and 100kb total size for both types of packages. It is important to note that these proposed limits are not a change to consensus rules and can be adjusted on an individual node basis in Bitcoin Core.In addition to the proposed limits on unconfirmed transaction chains, Alex Morcos has put forward a set of requirements for accepting new transactions into the mempool and relaying them. The aim of this policy is to limit the size of the mempool and ensure that a new transaction can cover the costs of any dependent transactions it may displace. Four new policy limits have been proposed, all of which can be configured using command line settings. In April and May of this year, these proposed limits would have affected less than 2% of transactions entering the mempool. However, during a stress test period, as many as 25% of transactions would have been impacted.The reason for reducing the limits on unconfirmed transaction chains is primarily due to concerns about mempool congestion and relay fee boosting attacks. The current limits for ancestor packages are 100 transactions and 900kb total size, while for descendant packages, the limits are 1000 transactions and 2500kb total size. The proposed new limits for both types of packages would be 25 transactions and 100kb total size. It is worth noting that these limits do not alter consensus rules and can be customized for each individual node using Bitcoin Core.Alex Morcos has made significant proposals to decrease the current policy limits on unconfirmed transaction chains. The existing limits for ancestor packages are 100 transactions and 900 kilobytes of total size, while for descendant packages, the limits are 1000 transactions and 2500 kilobytes of total size. The proposed new limits for both types of packages are 25 transactions and 100 kilobytes of total size. These limits can be adjusted at the command line level on each node that utilizes Bitcoin Core.To ensure a smooth and efficient transaction process, certain limits have been established. The first limit restricts transactions larger than 100 kilobytes from being accepted. This ensures that the size of transactions remains within a reasonable range. The second limit focuses on the fee rate, disallowing transactions with a fee rate equal to or less than 1 satoshi per byte. This encourages users to attach an appropriate fee, which helps prioritize their transactions. The third limit aims to prevent transaction flooding attacks by rejecting transactions that would cause the mempool's total size to exceed 300 megabytes. This safeguard protects the network from becoming overwhelmed by a large number of transactions. Lastly, the fourth limit maintains the policy that all transactions in the mempool should be mineable in the next block. To achieve this, transactions will not be accepted if the total size of all unconfirmed ancestor transactions is too large. By default, this limit is set at 1 megabyte.It is important to note that these limits would have affected less than 2% of transactions entering the mempool in April or May of this year. However, during the stress test period from July 6th to July 14th, up to 25% of the transactions would have been impacted. For those interested in the technical details, the code to implement these changes can be found in pull request 6557, which is based on pull request 6470. These pull requests contain the necessary modifications to enforce the aforementioned limits and enhance the overall transaction process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Questiosn-about-BIP100.xml b/static/bitcoin-dev/Aug_2015/combined_Questiosn-about-BIP100.xml index f2d41adef0..09f5165ebb 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Questiosn-about-BIP100.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Questiosn-about-BIP100.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Questiosn about BIP100 - 2023-08-01T15:39:07.527763+00:00 + 2025-10-11T22:07:28.699842+00:00 + python-feedgen jl2012 at xbt.hk 2015-08-28 03:02:47+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Questiosn about BIP100 - 2023-08-01T15:39:07.527763+00:00 + 2025-10-11T22:07:28.699977+00:00 - The block size debate in the Bitcoin community has been ongoing for a long time. Jeff Garzik suggests that using the median as the block size is the most natural and logical option, as it eliminates the incentive to 51% attack. He believes that if something other than the median is used, it should be symmetrical. In response to a question about BIP 100's deployment, Garzik confirms that he is working on a technical draft and implementation, which will hopefully be presented at ScalingBitcoin.org. Currently, only the PDF of BIP 100 is publicly available. The proposal suggests allowing miners to vote on the maximum block size they will accept, with the size increasing if 70% or more of the blocks mined in the previous two weeks have voted for a larger size. When asked about the "most common floor," Garzik mentions that it could be interpreted as the 20th percentile, but there is some argument for taking the mode of several tranches. The initial deployment of BIP 100 will be in the same manner as size votes. 2015-08-28T03:02:47+00:00 + The block size debate in the Bitcoin community has been ongoing for a long time. Jeff Garzik suggests that using the median as the block size is the most natural and logical option, as it eliminates the incentive to 51% attack. He believes that if something other than the median is used, it should be symmetrical. In response to a question about BIP 100's deployment, Garzik confirms that he is working on a technical draft and implementation, which will hopefully be presented at ScalingBitcoin.org. Currently, only the PDF of BIP 100 is publicly available. The proposal suggests allowing miners to vote on the maximum block size they will accept, with the size increasing if 70% or more of the blocks mined in the previous two weeks have voted for a larger size. When asked about the "most common floor," Garzik mentions that it could be interpreted as the 20th percentile, but there is some argument for taking the mode of several tranches. The initial deployment of BIP 100 will be in the same manner as size votes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_RE-Visualizations-of-Votes.xml b/static/bitcoin-dev/Aug_2015/combined_RE-Visualizations-of-Votes.xml index 8918df6ad5..0378b7ad6b 100644 --- a/static/bitcoin-dev/Aug_2015/combined_RE-Visualizations-of-Votes.xml +++ b/static/bitcoin-dev/Aug_2015/combined_RE-Visualizations-of-Votes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RE : Visualizations of Votes - 2023-08-01T15:35:38.704613+00:00 + 2025-10-11T22:07:39.406248+00:00 + python-feedgen odinn 2015-08-21 05:25:39+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - RE : Visualizations of Votes - 2023-08-01T15:35:38.704613+00:00 + 2025-10-11T22:07:39.406431+00:00 - Nicolas Dorier, a member of the bitcoin-dev mailing list, recently suggested the idea of creating a visualization to display the percentage of votes for different proposals in pie graphs. Specifically, he wanted to compare the support for proposals such as BIP 100, BIP 101, 8MB, and BIP sipa. His intention was to visually represent the level of support for each proposal based on what is published in blocks.However, one major challenge arises from the fact that there is currently no standardized method for miners to informally vote on the BIPs they support. This lack of a formal voting process makes it difficult to gather the necessary data to create the desired visualization.In response to inquiries about formal voting, Dorier pondered the possibility of incorporating the votes into a pie chart as they become apparent in blocks. He expressed his appreciation for effective visualizations and even shared links to his own protocol concept and Keybase profile.Despite the absence of a defined voting mechanism, the author of the email expressed their willingness to display the pie chart on BIPxDevs if a vote were to exist. However, until a standard way for miners to informally vote on BIPs is established, the creation of the desired visualization remains a challenge. 2015-08-21T05:25:39+00:00 + Nicolas Dorier, a member of the bitcoin-dev mailing list, recently suggested the idea of creating a visualization to display the percentage of votes for different proposals in pie graphs. Specifically, he wanted to compare the support for proposals such as BIP 100, BIP 101, 8MB, and BIP sipa. His intention was to visually represent the level of support for each proposal based on what is published in blocks.However, one major challenge arises from the fact that there is currently no standardized method for miners to informally vote on the BIPs they support. This lack of a formal voting process makes it difficult to gather the necessary data to create the desired visualization.In response to inquiries about formal voting, Dorier pondered the possibility of incorporating the votes into a pie chart as they become apparent in blocks. He expressed his appreciation for effective visualizations and even shared links to his own protocol concept and Keybase profile.Despite the absence of a defined voting mechanism, the author of the email expressed their willingness to display the pie chart on BIPxDevs if a vote were to exist. However, until a standard way for miners to informally vote on BIPs is established, the creation of the desired visualization remains a challenge. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_REQ-BIP-Discuss-Sweep-incoming-unconfirmed-transactions-with-a-bounty-.xml b/static/bitcoin-dev/Aug_2015/combined_REQ-BIP-Discuss-Sweep-incoming-unconfirmed-transactions-with-a-bounty-.xml index 462ebcac6f..46a86905f9 100644 --- a/static/bitcoin-dev/Aug_2015/combined_REQ-BIP-Discuss-Sweep-incoming-unconfirmed-transactions-with-a-bounty-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_REQ-BIP-Discuss-Sweep-incoming-unconfirmed-transactions-with-a-bounty-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty. - 2023-08-01T14:12:37.349353+00:00 + 2025-10-11T22:05:59.410161+00:00 + python-feedgen Aaron Voisine 2015-08-26 15:28:45+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty. - 2023-08-01T14:12:37.349353+00:00 + 2025-10-11T22:05:59.410336+00:00 - Breadwallet, a Bitcoin wallet provider, has implemented the Child Pays for Parent (CPFP) feature when spending unconfirmed non-change inputs. The feature was released in May 2015 and is available on the company's Github page. Meanwhile, Dan Bryant via bitcoin-dev offered a bounty for anyone who can put a CPFP transaction creation feature into any wallet featured on the bitcoin homepage. The funds will be dispersed from a multisig address. A bounty has been offered to anyone who can add a Child Pays for Parent (CPFP) transaction creation feature to any wallet featured on the Bitcoin homepage. The funds for the bounty are being raised by donation and will be dispersed from a specific address once the bounty is claimed. The address is currently not well-funded, but donations are welcome. Proof that the multisig address is not 1 of 1 can be found on Bitcointalk.org. It seems that someone attempted to increase a transaction and succeeded in getting it approved. The hash values of the parent, child, grandchild, great-grandchild, and great-great-grandchild blocks are provided, but the position of the transaction in the block is not a priority or fee cut line.During a conversation between Aaron Voisine and an unknown person on July 9, 2015, Aaron asked if the person knew how much hashing power was using CPFP. This information would be helpful for wallet developers to determine their confirmation times when utilizing CPFP. The other person was unsure of the exact percentage but suggested that at least 4% of hashing power on the Eligius platform was using CPFP.In a Bitcoin development mailing list, Luke Dashjr corrected a misconception in a BIP proposal regarding Child Pays for Parent (CPFP) transaction selection. The proposal assumed that miners were already utilizing CPFP, but Luke clarified that while it is not included in the reference policy, some miners do use it. Aaron Voisine, co-founder and CEO of breadwallet.com, chimed in to mention how knowing the amount of hashing power being used for CPFP could be useful for wallet developers to estimate confirmation times.In a conversation between Dan Bryant and Luke, it was discussed that when Dan wrote the BIP proposal, he assumed that CPFP (Child Pays For Parent) transaction selection was already being done by miners. However, it was pointed out that this assumption was correct, but not included in the reference policy. It was stated that miners are not expected to use the reference policy as-is and some of them do use CPFP.The discussion on Bitcoin development mailing list is about child pays for parent (CPFP) and Replace-by-fee (RBF). CPFP is a transaction selection policy in which the high fee from a child transaction is used to pay for its unconfirmed parent's fee. A pull request, #1647, has been created to implement CPFP but it only addresses miner policy. Matt Whitlock argues that wallets also need to offer users a way to goose up incoming transactions for CPFP to be effective. The sweep transaction UI issue is out of scope for the BIP proposal. Dan Bryant suggests talking with wallet authors to get them interested in this feature enhancement when PR1647 commits. The risks involved if CPFP is not enabled but the sweep tx enters the mempool are discussed and how miners may take the high fee "children" but ignore the low fee "parents," leading to potential issues. Peter Todd's article outlines the two forms of RBF: the countermeasure form and the anyonecanpay form. In the countermeasure form, the spender gives the receiver a partially signed "countermeasure" transaction with juiced-up fees. In the anyonecanpay form, the spender signs the transaction with ANYONECANPAY bit allowing the receiver to add fees at will. It is clarified that a transaction that is not completely signed won't be relayed, correct, and it cannot be mined. Lastly, Dan Bryant states he will try to clean up the draft BIP to include CPFP dependencies and RBF capabilities and will outline his thoughts in a doc.In a Bitcoin-development mailing list discussion, Mark Friedenbach introduced the concept of CPFP or “child pays for parent”. This feature allows miners to prioritize transactions in a block based on the fees attached to them. A pull request from 2015, PR#1647, implemented this feature which indicated that certain trees could bloom the TX selection latency as miners would need to be more dependency aware. However, it only addressed miner policy and did not offer a user-facing side of functionality. Matt Whitlock pointed out that the BIP proposal for CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions.Mark Friedenbach has suggested a child pays for parent (CPFP) method which would require changes to the P2P layer to support RBF scorched earth. The transactions are processed individually and 2015-08-26T15:28:45+00:00 + Breadwallet, a Bitcoin wallet provider, has implemented the Child Pays for Parent (CPFP) feature when spending unconfirmed non-change inputs. The feature was released in May 2015 and is available on the company's Github page. Meanwhile, Dan Bryant via bitcoin-dev offered a bounty for anyone who can put a CPFP transaction creation feature into any wallet featured on the bitcoin homepage. The funds will be dispersed from a multisig address. A bounty has been offered to anyone who can add a Child Pays for Parent (CPFP) transaction creation feature to any wallet featured on the Bitcoin homepage. The funds for the bounty are being raised by donation and will be dispersed from a specific address once the bounty is claimed. The address is currently not well-funded, but donations are welcome. Proof that the multisig address is not 1 of 1 can be found on Bitcointalk.org. It seems that someone attempted to increase a transaction and succeeded in getting it approved. The hash values of the parent, child, grandchild, great-grandchild, and great-great-grandchild blocks are provided, but the position of the transaction in the block is not a priority or fee cut line.During a conversation between Aaron Voisine and an unknown person on July 9, 2015, Aaron asked if the person knew how much hashing power was using CPFP. This information would be helpful for wallet developers to determine their confirmation times when utilizing CPFP. The other person was unsure of the exact percentage but suggested that at least 4% of hashing power on the Eligius platform was using CPFP.In a Bitcoin development mailing list, Luke Dashjr corrected a misconception in a BIP proposal regarding Child Pays for Parent (CPFP) transaction selection. The proposal assumed that miners were already utilizing CPFP, but Luke clarified that while it is not included in the reference policy, some miners do use it. Aaron Voisine, co-founder and CEO of breadwallet.com, chimed in to mention how knowing the amount of hashing power being used for CPFP could be useful for wallet developers to estimate confirmation times.In a conversation between Dan Bryant and Luke, it was discussed that when Dan wrote the BIP proposal, he assumed that CPFP (Child Pays For Parent) transaction selection was already being done by miners. However, it was pointed out that this assumption was correct, but not included in the reference policy. It was stated that miners are not expected to use the reference policy as-is and some of them do use CPFP.The discussion on Bitcoin development mailing list is about child pays for parent (CPFP) and Replace-by-fee (RBF). CPFP is a transaction selection policy in which the high fee from a child transaction is used to pay for its unconfirmed parent's fee. A pull request, #1647, has been created to implement CPFP but it only addresses miner policy. Matt Whitlock argues that wallets also need to offer users a way to goose up incoming transactions for CPFP to be effective. The sweep transaction UI issue is out of scope for the BIP proposal. Dan Bryant suggests talking with wallet authors to get them interested in this feature enhancement when PR1647 commits. The risks involved if CPFP is not enabled but the sweep tx enters the mempool are discussed and how miners may take the high fee "children" but ignore the low fee "parents," leading to potential issues. Peter Todd's article outlines the two forms of RBF: the countermeasure form and the anyonecanpay form. In the countermeasure form, the spender gives the receiver a partially signed "countermeasure" transaction with juiced-up fees. In the anyonecanpay form, the spender signs the transaction with ANYONECANPAY bit allowing the receiver to add fees at will. It is clarified that a transaction that is not completely signed won't be relayed, correct, and it cannot be mined. Lastly, Dan Bryant states he will try to clean up the draft BIP to include CPFP dependencies and RBF capabilities and will outline his thoughts in a doc.In a Bitcoin-development mailing list discussion, Mark Friedenbach introduced the concept of CPFP or “child pays for parent”. This feature allows miners to prioritize transactions in a block based on the fees attached to them. A pull request from 2015, PR#1647, implemented this feature which indicated that certain trees could bloom the TX selection latency as miners would need to be more dependency aware. However, it only addressed miner policy and did not offer a user-facing side of functionality. Matt Whitlock pointed out that the BIP proposal for CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions.Mark Friedenbach has suggested a child pays for parent (CPFP) method which would require changes to the P2P layer to support RBF scorched earth. The transactions are processed individually and - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml b/static/bitcoin-dev/Aug_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml index dea50bb070..ade6c4e50e 100644 --- a/static/bitcoin-dev/Aug_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml +++ b/static/bitcoin-dev/Aug_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC - BIP: URI scheme for Blockchain exploration - 2023-08-01T15:44:07.597614+00:00 + 2025-10-11T22:07:13.819667+00:00 + python-feedgen Marco Pontello 2015-11-18 12:31:46+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - RFC - BIP: URI scheme for Blockchain exploration - 2023-08-01T15:44:07.597614+00:00 + 2025-10-11T22:07:13.819839+00:00 - A proposed new URI scheme for blockchain exploration has been submitted by Marco Pontello. The purpose of this URI scheme is to enable users to handle all requests for details about blocks, transactions, and addresses on a blockchain explorer with their preferred tool, whether it be a web service or a local application. Currently, Bitcoin clients typically point to an arbitrary blockchain explorer when the user looks for transaction details, and sometimes resorting to cut-and-paste is necessary. The same happens with posts and messages that reference specific transactions or blocks, if they provide links at all.The proposed URI follows a simple form: "blockchain:" followed by the block or transaction ID. The proposal suggests that keeping it simple should be practical enough, and blockchain explorers can apply the same disambiguation rules they are already using to process the usual search box. From the perspective of a wallet developer or other tool that needs to show blockchain references, using this scheme means they can simply make it a blockchain link and be done with it without worrying about any specific blockchain explorer or providing a means for the user to select one.The proposal also discusses improving the syntax of blockchain URLs. Participants suggest different approaches, such as making the chain part optional or using the "authority" component of the URL to identify the chain. There is also discussion about allowing well-known chains to register names as alternatives to the hash syntax. The use of the genesis block hash as a method for identifying a reference to a transaction is proposed, along with the idea of using name constants as a simpler alternative.Overall, the goal of the proposal is to create a standard URI scheme for blockchain exploration that all explorers would understand. This would provide users with the convenience of using their preferred explorer and simplify the process for wallet developers and other tools that need to show blockchain references. 2015-11-18T12:31:46+00:00 + A proposed new URI scheme for blockchain exploration has been submitted by Marco Pontello. The purpose of this URI scheme is to enable users to handle all requests for details about blocks, transactions, and addresses on a blockchain explorer with their preferred tool, whether it be a web service or a local application. Currently, Bitcoin clients typically point to an arbitrary blockchain explorer when the user looks for transaction details, and sometimes resorting to cut-and-paste is necessary. The same happens with posts and messages that reference specific transactions or blocks, if they provide links at all.The proposed URI follows a simple form: "blockchain:" followed by the block or transaction ID. The proposal suggests that keeping it simple should be practical enough, and blockchain explorers can apply the same disambiguation rules they are already using to process the usual search box. From the perspective of a wallet developer or other tool that needs to show blockchain references, using this scheme means they can simply make it a blockchain link and be done with it without worrying about any specific blockchain explorer or providing a means for the user to select one.The proposal also discusses improving the syntax of blockchain URLs. Participants suggest different approaches, such as making the chain part optional or using the "authority" component of the URL to identify the chain. There is also discussion about allowing well-known chains to register names as alternatives to the hash syntax. The use of the genesis block hash as a method for identifying a reference to a transaction is proposed, along with the idea of using name constants as a simpler alternative.Overall, the goal of the proposal is to create a standard URI scheme for blockchain exploration that all explorers would understand. This would provide users with the convenience of using their preferred explorer and simplify the process for wallet developers and other tools that need to show blockchain references. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Revisiting-NODE-BLOOM-Proposed-BIP.xml b/static/bitcoin-dev/Aug_2015/combined_Revisiting-NODE-BLOOM-Proposed-BIP.xml index 354e508995..b1b5463ca2 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Revisiting-NODE-BLOOM-Proposed-BIP.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Revisiting-NODE-BLOOM-Proposed-BIP.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Revisiting NODE_BLOOM: Proposed BIP - 2023-08-01T15:37:04.587931+00:00 + 2025-10-11T22:06:07.918263+00:00 + python-feedgen Eric Lombrozo 2015-08-24 18:33:40+00:00 @@ -123,13 +124,13 @@ - python-feedgen + 2 Combined summary - Revisiting NODE_BLOOM: Proposed BIP - 2023-08-01T15:37:04.587931+00:00 + 2025-10-11T22:06:07.918486+00:00 - On August 20, 2015, Peter Todd posted on the bitcoin-dev mailing list about a decrease in the number of Simplified Payment Verification (SPV) clients on his high-speed nodes. He estimated the drop to be from around 5-10% to about 1%. Another member reported having 20.4% bitcoinj connections on their own connection. The email conversation between Matt Corallo and Peter Todd discussed the risks associated with relying on seed nodes for starting nodes. They considered returning any node that responds to getaddr from DNS seeds to allow clients to connect to a few DNS seeds by name, then disconnect after selecting peers based on nServices. They also briefly mentioned the need to "shard" the blockchain but dismissed it as a future problem that did not require immediate attention.In an email thread from August 21, 2015, Peter Todd reported a DoS attack on Bitcoin XT nodes involving repeated Bloom filter requests that consumed disk IO bandwidth. The proposed BIP for disabling Bloom filtering was criticized by NACK, as it only added privacy for lightweight wallets, not node operators, and no research had been conducted on the claimed DoS attack. It was seen as creating more problems than it solved and unnecessary.The email conversation between Matt Corallo and Wladimir J. van der Laan discussed rewording the statement about NODE_BLOOM being distinct from NODE_NETWORK and the ability to advertise NODE_BLOOM without NODE_NETWORK. They agreed on acknowledging the potential usefulness of advertising NODE_BLOOM in the future but left the speculation of signaling which blocks pruned nodes have for a future BIP.The discussion on the bitcoin-dev mailing list revolved around implementing a bloom filter in Bitcoin's client/server architecture. The proposed changes included BIPs, pull requests, and discussions on DoS attacks and client/server architectures. Overall, the conversation touched on various aspects of improving filtering options within Bitcoin connections.Matt Corallo suggested adding an option to select service bits to DNS seeds and emphasized the importance of caching and proper gossip protocol participation. He believed that splitting blocks into multiples was the only solution for reasonable scalability and mentioned the need to protect miners from DoS attacks. The NODE_BLOOM service bit allows peers to explicitly advertise their support for bloom filters, addressing privacy concerns and DoS risks. Node operators should be able to disable connection bloom filtering.Peter Todd noted the decrease in Bloom filter usage as lite-SPV clients moved towards using centralized servers run by wallet authors. However, he pointed out that Mycelium lost users during a stress test when their infrastructure was overloaded, prompting their move to SPV. Jeff Garzik questioned the claim about Bloom filter usage decline, but Todd explained the drop in SPV clients and the popularity of wallets like Mycelium. He also mentioned the implementation of NODE_GETUTXO, which provides infrastructure for wallets needing bloom filters.The proposal by Matt Corallo and Peter Todd aimed to extend BIP 37 by defining the NODE_BLOOM service bit to address privacy and DoS issues associated with connection bloom filtering. It included increasing the protocol version for backward compatibility and requiring DNS seeds to support specified services. Peter Todd raised concerns about scalability and privacy issues and recommended adding a bit for more scalable designs in future upgrades.In summary, the discussion focused on the need for a service bit to advertise bloom filter support explicitly. The proposed extension to BIP 37 aimed to address privacy and DoS risks associated with connection bloom filtering, improve scalability, and enhance security in the Bitcoin network. 2015-08-24T18:33:40+00:00 + On August 20, 2015, Peter Todd posted on the bitcoin-dev mailing list about a decrease in the number of Simplified Payment Verification (SPV) clients on his high-speed nodes. He estimated the drop to be from around 5-10% to about 1%. Another member reported having 20.4% bitcoinj connections on their own connection. The email conversation between Matt Corallo and Peter Todd discussed the risks associated with relying on seed nodes for starting nodes. They considered returning any node that responds to getaddr from DNS seeds to allow clients to connect to a few DNS seeds by name, then disconnect after selecting peers based on nServices. They also briefly mentioned the need to "shard" the blockchain but dismissed it as a future problem that did not require immediate attention.In an email thread from August 21, 2015, Peter Todd reported a DoS attack on Bitcoin XT nodes involving repeated Bloom filter requests that consumed disk IO bandwidth. The proposed BIP for disabling Bloom filtering was criticized by NACK, as it only added privacy for lightweight wallets, not node operators, and no research had been conducted on the claimed DoS attack. It was seen as creating more problems than it solved and unnecessary.The email conversation between Matt Corallo and Wladimir J. van der Laan discussed rewording the statement about NODE_BLOOM being distinct from NODE_NETWORK and the ability to advertise NODE_BLOOM without NODE_NETWORK. They agreed on acknowledging the potential usefulness of advertising NODE_BLOOM in the future but left the speculation of signaling which blocks pruned nodes have for a future BIP.The discussion on the bitcoin-dev mailing list revolved around implementing a bloom filter in Bitcoin's client/server architecture. The proposed changes included BIPs, pull requests, and discussions on DoS attacks and client/server architectures. Overall, the conversation touched on various aspects of improving filtering options within Bitcoin connections.Matt Corallo suggested adding an option to select service bits to DNS seeds and emphasized the importance of caching and proper gossip protocol participation. He believed that splitting blocks into multiples was the only solution for reasonable scalability and mentioned the need to protect miners from DoS attacks. The NODE_BLOOM service bit allows peers to explicitly advertise their support for bloom filters, addressing privacy concerns and DoS risks. Node operators should be able to disable connection bloom filtering.Peter Todd noted the decrease in Bloom filter usage as lite-SPV clients moved towards using centralized servers run by wallet authors. However, he pointed out that Mycelium lost users during a stress test when their infrastructure was overloaded, prompting their move to SPV. Jeff Garzik questioned the claim about Bloom filter usage decline, but Todd explained the drop in SPV clients and the popularity of wallets like Mycelium. He also mentioned the implementation of NODE_GETUTXO, which provides infrastructure for wallets needing bloom filters.The proposal by Matt Corallo and Peter Todd aimed to extend BIP 37 by defining the NODE_BLOOM service bit to address privacy and DoS issues associated with connection bloom filtering. It included increasing the protocol version for backward compatibility and requiring DNS seeds to support specified services. Peter Todd raised concerns about scalability and privacy issues and recommended adding a bit for more scalable designs in future upgrades.In summary, the discussion focused on the need for a service bit to advertise bloom filter support explicitly. The proposed extension to BIP 37 aimed to address privacy and DoS risks associated with connection bloom filtering, improve scalability, and enhance security in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Separated-bitcoin-consensus-mailing-list-was-Re-Bitcoin-XT-Fork-.xml b/static/bitcoin-dev/Aug_2015/combined_Separated-bitcoin-consensus-mailing-list-was-Re-Bitcoin-XT-Fork-.xml index a290062600..0e9dbec099 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Separated-bitcoin-consensus-mailing-list-was-Re-Bitcoin-XT-Fork-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Separated-bitcoin-consensus-mailing-list-was-Re-Bitcoin-XT-Fork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork) - 2023-08-01T15:33:32.771042+00:00 + 2025-10-11T22:07:43.652547+00:00 + python-feedgen Bryan Bishop 2015-08-20 00:21:06+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork) - 2023-08-01T15:33:32.771042+00:00 + 2025-10-11T22:07:43.652697+00:00 - In an email exchange, Jorge Timón suggests that technical people tend to avoid noise on mailing lists while non-technical people follow the noise. Bryan Bishop responds, stating he is fine with receiving everything through a single mailing list. He likens it to reading the Wikipedia firehose of recent edits and thinks having a raw feed would be valuable for future developers. However, he also suggests that weekly summaries of research and development activity would be useful to summarize recent work.On August 20, 2015, NxtChg via bitcoin-dev revealed that Jorge Timón had made the most posts with a total of 72. Despite believing that his posts were on-topic, he acknowledged that some repetition could have been avoided. His focus has been on linking to threads or documents to make his comments shorter. However, he admitted that most of his posts centered around general consensus topics rather than specific Bitcoin Core development issues. In light of this, he apologized for setting an unplanned record. The conversation took place in the context of a discussion about separating the bitcoin-consensus and bitcoin-dev lists.It is suggested that every mailing list should have its own internal SNR discussions. In August, Jorge Timón made the most number of posts with 72, followed by Hector Chu with 36 and Thomas Zander with 32. Pieter Wuille posted 27 times, while Eric Lombrozo and Mark Friedenbach each had 24 posts. Adam Back, Btc Drak, and Peter Todd all had 18 posts while jl2012 had 17 and odinn with 16. Gavin Andresen had 15 posts while Venzen Khaosan and Michael Naber both had 12. Anthony Towns had 11 posts and Tom Harding and Gregory Maxwell each had 10. Anybody else on the mailing list had less than 10 posts in August.The Bitcoin developers, including Wladimir, Greg, Peter Todd, Pieter, and Alex Morcos, have been discussing options for improving the signal noise ratio on the bitcoin-dev list. One solution suggested was to divide it into multiple mailing lists, but it was pointed out that the less technical Bitcoin discussion list already existed in the past and nobody used it. Instead, the discussion turned toward instituting on-topic guidelines for bitcoin-dev. Gavin, Wladimir, and a few others agreed to a simple few paragraphs written by Alex Morcos, which would be posted by Wladimir. The risk of having too many lists is interested stakeholders will miss discussions. We could reduce the off-topic/noise of bitcoin-dev considerably by offloading the non-technical/academic debate to the Bitcoin list. It just needs a bit of shepherding. One proposal is to respond when something is off-topic and offer a different place for the topic. However, no one has been implementing this yet because they don't have a strong handle on what is off-topic and what isn't. Thus, it is important to establish norms which requires some relative humility, courage, and honesty.Several developers, including Wladimir, Greg, Peter Todd, Pieter, and Alex Morcos, have been discussing ways to improve the signal-to-noise ratio on the bitcoin-dev list. One proposal was to split the list into multiple mailing lists, but it was pointed out that a less technical Bitcoin discussion list already existed in the past but had not been used. The discussion moved towards instituting on-topic guidelines for bitcoin-dev instead of creating yet another mailing list. Gavin, Wladimir, and a few others agreed to a few paragraphs written by Alex Morcos, which Wladimir agreed to post. Btc Drak suggested offloading non-technical/academic debate to the bitcoin list to reduce the off-topic noise of bitcoin-dev. This would require some shepherding, and he expressed willingness to help out. It was suggested that general discussions had little use on bitcoin-dev because there were no rules to force them over to the bitcoin list. The discussion also touched on the idea of establishing two lists, but many felt that it would not make much difference as long as Bitcoin Core remained the reference client. There were questions about who the moderators for the bitcoin list were and whether sourceforge was the best platform for the list.A discussion is taking place on whether to establish two separate mailing lists for Bitcoin protocol and Bitcoin Core discussions. However, Jeff Garzik thinks that having multiple lists will not make much difference as long as Bitcoin Core remains the reference client. He also suggests that there haven't been any rules in place for -dev to force general discussion over to the Bitcoin list. Garzik believes that offloading non-technical/academic debates to the Bitcoin list could significantly reduce the off-topic/noise on the bitcoin-dev list. Additionally, he mentions that it just needs a bit of shepherding and he would be happy to help out. Finally, Garzik asks about the moderators and whether SourceForge is the best platform or 2015-08-20T00:21:06+00:00 + In an email exchange, Jorge Timón suggests that technical people tend to avoid noise on mailing lists while non-technical people follow the noise. Bryan Bishop responds, stating he is fine with receiving everything through a single mailing list. He likens it to reading the Wikipedia firehose of recent edits and thinks having a raw feed would be valuable for future developers. However, he also suggests that weekly summaries of research and development activity would be useful to summarize recent work.On August 20, 2015, NxtChg via bitcoin-dev revealed that Jorge Timón had made the most posts with a total of 72. Despite believing that his posts were on-topic, he acknowledged that some repetition could have been avoided. His focus has been on linking to threads or documents to make his comments shorter. However, he admitted that most of his posts centered around general consensus topics rather than specific Bitcoin Core development issues. In light of this, he apologized for setting an unplanned record. The conversation took place in the context of a discussion about separating the bitcoin-consensus and bitcoin-dev lists.It is suggested that every mailing list should have its own internal SNR discussions. In August, Jorge Timón made the most number of posts with 72, followed by Hector Chu with 36 and Thomas Zander with 32. Pieter Wuille posted 27 times, while Eric Lombrozo and Mark Friedenbach each had 24 posts. Adam Back, Btc Drak, and Peter Todd all had 18 posts while jl2012 had 17 and odinn with 16. Gavin Andresen had 15 posts while Venzen Khaosan and Michael Naber both had 12. Anthony Towns had 11 posts and Tom Harding and Gregory Maxwell each had 10. Anybody else on the mailing list had less than 10 posts in August.The Bitcoin developers, including Wladimir, Greg, Peter Todd, Pieter, and Alex Morcos, have been discussing options for improving the signal noise ratio on the bitcoin-dev list. One solution suggested was to divide it into multiple mailing lists, but it was pointed out that the less technical Bitcoin discussion list already existed in the past and nobody used it. Instead, the discussion turned toward instituting on-topic guidelines for bitcoin-dev. Gavin, Wladimir, and a few others agreed to a simple few paragraphs written by Alex Morcos, which would be posted by Wladimir. The risk of having too many lists is interested stakeholders will miss discussions. We could reduce the off-topic/noise of bitcoin-dev considerably by offloading the non-technical/academic debate to the Bitcoin list. It just needs a bit of shepherding. One proposal is to respond when something is off-topic and offer a different place for the topic. However, no one has been implementing this yet because they don't have a strong handle on what is off-topic and what isn't. Thus, it is important to establish norms which requires some relative humility, courage, and honesty.Several developers, including Wladimir, Greg, Peter Todd, Pieter, and Alex Morcos, have been discussing ways to improve the signal-to-noise ratio on the bitcoin-dev list. One proposal was to split the list into multiple mailing lists, but it was pointed out that a less technical Bitcoin discussion list already existed in the past but had not been used. The discussion moved towards instituting on-topic guidelines for bitcoin-dev instead of creating yet another mailing list. Gavin, Wladimir, and a few others agreed to a few paragraphs written by Alex Morcos, which Wladimir agreed to post. Btc Drak suggested offloading non-technical/academic debate to the bitcoin list to reduce the off-topic noise of bitcoin-dev. This would require some shepherding, and he expressed willingness to help out. It was suggested that general discussions had little use on bitcoin-dev because there were no rules to force them over to the bitcoin list. The discussion also touched on the idea of establishing two lists, but many felt that it would not make much difference as long as Bitcoin Core remained the reference client. There were questions about who the moderators for the bitcoin list were and whether sourceforge was the best platform for the list.A discussion is taking place on whether to establish two separate mailing lists for Bitcoin protocol and Bitcoin Core discussions. However, Jeff Garzik thinks that having multiple lists will not make much difference as long as Bitcoin Core remains the reference client. He also suggests that there haven't been any rules in place for -dev to force general discussion over to the Bitcoin list. Garzik believes that offloading non-technical/academic debates to the Bitcoin list could significantly reduce the off-topic/noise on the bitcoin-dev list. Additionally, he mentions that it just needs a bit of shepherding and he would be happy to help out. Finally, Garzik asks about the moderators and whether SourceForge is the best platform or - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Short-review-of-previously-proposed-exotic-SIGHASH-types.xml b/static/bitcoin-dev/Aug_2015/combined_Short-review-of-previously-proposed-exotic-SIGHASH-types.xml index 4a142188e7..4179677ca7 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Short-review-of-previously-proposed-exotic-SIGHASH-types.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Short-review-of-previously-proposed-exotic-SIGHASH-types.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Short review of previously-proposed exotic SIGHASH types - 2023-08-01T15:51:47.413315+00:00 + 2025-10-11T22:07:50.022007+00:00 + python-feedgen Peter Todd 2015-09-01 06:54:42+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Short review of previously-proposed exotic SIGHASH types - 2023-08-01T15:51:47.413315+00:00 + 2025-10-11T22:07:50.022187+00:00 - In a bitcoin-dev email thread, Bryan Bishop provided a review of proposed and exotic SIGHASH types. Among them was the SIGHASH_MULTIPLE and petertodd's suggestion of SIGHASH_DONT_SIGN_TXID to make OP_CODESEPARATOR more useful. Another idea presented was the "meta sighash" which involves using code to build up the signature with OP_CODESEPARATOR. The email also included a digital signature attachment from Peter Todd.On August 30th, 2015, Bryan Bishop posted a message on bitcoin-dev regarding a proposal for new SIGHASH types. The proposed types include SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, SIGHASH_WITHOUT_INPUT_TXID, SIGHASH_WITHOUT_INPUT_INDEX, SIGHASH_WITHOUT_INPUT_SEQUENCE, SIGHASH_WITHOUT_OUTPUT_SCRIPTPUBKEY, SIGHASH_WITHOUT_OUTPUT_VALUE, SIGHASH_WITHOUT_INPUTS, SIGHASH_WITHOUT_OUTPUTS, SIGHASH_WITHOUT_INPUT_SELF, SIGHASH_WITHOUT_OUTPUT_SELF, SIGHASH_WITHOUT_TX_VERSION, and SIGHASH_WITHOUT_TX_LOCKTIME. A link to the proposal can be found in the post. Another user thanks Bishop for his summary of the proposal but expresses concern that it may not allow for fine adjustment for each input and output separately, which raises questions about whether the proposal truly enables any seen or unforeseen use case of the CTransactionSignatureSerializer.There have been multiple previously-proposed and exotic SIGHASH types. Some of these include SIGHASH_MULTIPLE, SIGHASH_LIST, and SIGHASH_WITHINPUTVALUE, which were discussed on bitcointalk.org. Another proposed type is SIGHASH_NOINPUT, which is mentioned in a paper about the Lightning Network and also has commits on Github. There are also proposals for SIGHASH_NORMALIZED and SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY. Furthermore, there have been suggestions for new types such as SIGHASH_SIGN_STACK_ELEMENT, SIGHASH_DONT_SIGN_TXID, SIGHASH_DANGEROUSLYPROMISCUOUS, SIGHASH_DOUBLE, SIGHASH_NLOCKTIMEVERIFY, SIGHASH_SUM, and even SIGHASH_UNICORN. These different types could potentially be useful for different purposes. 2015-09-01T06:54:42+00:00 + In a bitcoin-dev email thread, Bryan Bishop provided a review of proposed and exotic SIGHASH types. Among them was the SIGHASH_MULTIPLE and petertodd's suggestion of SIGHASH_DONT_SIGN_TXID to make OP_CODESEPARATOR more useful. Another idea presented was the "meta sighash" which involves using code to build up the signature with OP_CODESEPARATOR. The email also included a digital signature attachment from Peter Todd.On August 30th, 2015, Bryan Bishop posted a message on bitcoin-dev regarding a proposal for new SIGHASH types. The proposed types include SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, SIGHASH_WITHOUT_INPUT_TXID, SIGHASH_WITHOUT_INPUT_INDEX, SIGHASH_WITHOUT_INPUT_SEQUENCE, SIGHASH_WITHOUT_OUTPUT_SCRIPTPUBKEY, SIGHASH_WITHOUT_OUTPUT_VALUE, SIGHASH_WITHOUT_INPUTS, SIGHASH_WITHOUT_OUTPUTS, SIGHASH_WITHOUT_INPUT_SELF, SIGHASH_WITHOUT_OUTPUT_SELF, SIGHASH_WITHOUT_TX_VERSION, and SIGHASH_WITHOUT_TX_LOCKTIME. A link to the proposal can be found in the post. Another user thanks Bishop for his summary of the proposal but expresses concern that it may not allow for fine adjustment for each input and output separately, which raises questions about whether the proposal truly enables any seen or unforeseen use case of the CTransactionSignatureSerializer.There have been multiple previously-proposed and exotic SIGHASH types. Some of these include SIGHASH_MULTIPLE, SIGHASH_LIST, and SIGHASH_WITHINPUTVALUE, which were discussed on bitcointalk.org. Another proposed type is SIGHASH_NOINPUT, which is mentioned in a paper about the Lightning Network and also has commits on Github. There are also proposals for SIGHASH_NORMALIZED and SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY. Furthermore, there have been suggestions for new types such as SIGHASH_SIGN_STACK_ELEMENT, SIGHASH_DONT_SIGN_TXID, SIGHASH_DANGEROUSLYPROMISCUOUS, SIGHASH_DOUBLE, SIGHASH_NLOCKTIMEVERIFY, SIGHASH_SUM, and even SIGHASH_UNICORN. These different types could potentially be useful for different purposes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Splitting-BIPs.xml b/static/bitcoin-dev/Aug_2015/combined_Splitting-BIPs.xml index ed6f482106..6f5336aeac 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Splitting-BIPs.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Splitting-BIPs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Splitting BIPs - 2023-08-01T15:40:10.389819+00:00 + 2025-10-11T22:05:06.272679+00:00 + python-feedgen Jorge Timón 2015-08-29 23:37:05+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Splitting BIPs - 2023-08-01T15:40:10.390814+00:00 + 2025-10-11T22:05:06.272841+00:00 - In a bitcoin-dev thread, Eric Lombrozo proposed the addition of a new attribute for Bitcoin Improvement Proposals (BIPs) that would indicate their "level". This new attribute aims to prioritize and reduce contention over disagreements within the Bitcoin development community. Lombrozo suggests that the proposed levels should include consensus (hard/soft fork), peer services, RPC, implementations, and applications. He provided an example table on his website to illustrate how this attribute might look in practice.Lombrozo also posted a draft proposal on his website, although it still requires further development in certain subsections. He explicitly welcomes comments and suggestions from the community regarding this proposal. In response to the post, Lombrozo emphasized that there are different degrees of "standard" and just because many people adopt a particular approach does not necessarily mean it is officially endorsed by other developers. To address this, he proposes modifying the current "type" attribute to reflect different levels of "standard".The email sent by Lombrozo further emphasizes the need for modifying the "type" attribute and introduces the idea of adding a new attribute to BIPs indicating their "level". The proposed levels include consensus (hard/soft fork), peer services, RPC, implementations, and applications. Lombrozo argues that disagreements can be tolerable for most things at levels below 1. He also provides a link to an example table on blockhawk.net/bitcoin-dev/bipwiki.html to demonstrate how this attribute might be implemented. If others in the community agree with this proposal, Lombrozo expresses his intention to start working on a BIP draft.Another author in the bitcoin-dev thread highlights the unnecessary contention within the Bitcoin development community over issues that do not necessarily require universal agreement. To address this, they propose the addition of an extra attribute to BIPs indicating their "level". The suggested categories for this attribute are consensus (hard/soft fork), peer services, RPC, implementations, and applications. The author provides an example table on blockhawk.net/bitcoin-dev/bipwiki.html to illustrate how this attribute might be structured. They also offer to work on a BIP draft if others support the idea.In summary, Eric Lombrozo proposed the inclusion of a new attribute in Bitcoin Improvement Proposals (BIPs) to indicate their "level". This proposal aims to prioritize and reduce contention over disagreements within the Bitcoin development community. Lombrozo suggests modifying the current "type" attribute to reflect different degrees of "standard". He provides examples and links to demonstrate the implementation of this proposal and encourages feedback from the community. Another author in the same thread supports the idea of adding an extra attribute to BIPs to address unnecessary contention within the community and offers to work on a BIP draft if there is consensus. 2015-08-29T23:37:05+00:00 + In a bitcoin-dev thread, Eric Lombrozo proposed the addition of a new attribute for Bitcoin Improvement Proposals (BIPs) that would indicate their "level". This new attribute aims to prioritize and reduce contention over disagreements within the Bitcoin development community. Lombrozo suggests that the proposed levels should include consensus (hard/soft fork), peer services, RPC, implementations, and applications. He provided an example table on his website to illustrate how this attribute might look in practice.Lombrozo also posted a draft proposal on his website, although it still requires further development in certain subsections. He explicitly welcomes comments and suggestions from the community regarding this proposal. In response to the post, Lombrozo emphasized that there are different degrees of "standard" and just because many people adopt a particular approach does not necessarily mean it is officially endorsed by other developers. To address this, he proposes modifying the current "type" attribute to reflect different levels of "standard".The email sent by Lombrozo further emphasizes the need for modifying the "type" attribute and introduces the idea of adding a new attribute to BIPs indicating their "level". The proposed levels include consensus (hard/soft fork), peer services, RPC, implementations, and applications. Lombrozo argues that disagreements can be tolerable for most things at levels below 1. He also provides a link to an example table on blockhawk.net/bitcoin-dev/bipwiki.html to demonstrate how this attribute might be implemented. If others in the community agree with this proposal, Lombrozo expresses his intention to start working on a BIP draft.Another author in the bitcoin-dev thread highlights the unnecessary contention within the Bitcoin development community over issues that do not necessarily require universal agreement. To address this, they propose the addition of an extra attribute to BIPs indicating their "level". The suggested categories for this attribute are consensus (hard/soft fork), peer services, RPC, implementations, and applications. The author provides an example table on blockhawk.net/bitcoin-dev/bipwiki.html to illustrate how this attribute might be structured. They also offer to work on a BIP draft if others support the idea.In summary, Eric Lombrozo proposed the inclusion of a new attribute in Bitcoin Improvement Proposals (BIPs) to indicate their "level". This proposal aims to prioritize and reduce contention over disagreements within the Bitcoin development community. Lombrozo suggests modifying the current "type" attribute to reflect different degrees of "standard". He provides examples and links to demonstrate the implementation of this proposal and encourages feedback from the community. Another author in the same thread supports the idea of adding an extra attribute to BIPs to address unnecessary contention within the community and offers to work on a BIP draft if there is consensus. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Superluminal-communication-and-the-consensus-block-size-limit.xml b/static/bitcoin-dev/Aug_2015/combined_Superluminal-communication-and-the-consensus-block-size-limit.xml index 15e5583222..3f15fc975e 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Superluminal-communication-and-the-consensus-block-size-limit.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Superluminal-communication-and-the-consensus-block-size-limit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Superluminal communication and the consensus block size limit - 2023-08-01T14:57:53.890040+00:00 + 2025-10-11T22:07:11.683950+00:00 + python-feedgen Tom Harding 2015-08-06 03:14:53+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Superluminal communication and the consensus block size limit - 2023-08-01T14:57:53.890040+00:00 + 2025-10-11T22:07:11.684098+00:00 - In a discussion on the bitcoin-dev mailing list, it was highlighted that Miner A has the capability to process 100 million transactions per block, while Miner B can only handle 10 million transactions per block. To bridge this gap, one suggestion put forward was for Miner B to sell ASICs and purchase CPU worth 90 million transactions. Another option proposed was to cap the block size at 10 million transactions, which would require Miner A to sell an equivalent amount of CPU and acquire ASICs. However, even with these solutions, Miner A would still maintain an advantage due to its greater financial resources compared to Miner B. This indicates that the issue of centralization in mining is more closely tied to financial capabilities rather than block size.In an email exchange between Gavin Andresen and Jorge Timón in August 2015, they delved into whether Miner A, with its higher transaction processing capacity, could continue to compete effectively against Miner B. Andresen argued that several variables play into the equation of mining profitability, including access to cheaper electricity, advanced mining hardware, affordable labor, and capital for hardware investments. He also brought up the idea of utilizing excess heat generated from mining for productive purposes, suggesting that if mining devices could be repurposed as heaters, it could potentially alter the dynamics of mining centralization. Andresen emphasized that mining should ideally remain decentralized, while considering the number of fee-paying transactions that can be included in blocks as part of the profitability equation.In another email conversation between Timón and Andresen, the question of whether Miner B can maintain competitiveness against Miner A was further explored. Andresen reiterated that various factors contribute to mining profitability, such as access to cheaper electricity, more advanced mining hardware, the ability to utilize excess heat productively, availability of affordable labor, and capital for hardware investment. Although the number of fee-paying transactions currently holds little significance, it will eventually become part of the equation for mining profitability. The goal is to encourage miners to include a substantial number of transactions in their blocks.Challenging the notion that block propagation times alone determine the usefulness of the maximum block size consensus rule in limiting mining centralization, a thought experiment was presented. This hypothetical scenario envisions the existence of superluminal communication and infinite bandwidth for everyone, eliminating the need for consideration of block propagation times. However, even under these ideal conditions, the consensus block size maximum still serves a purpose in preventing mining centralization. Assuming that miners no longer process transactions with fees below 1 satoshi, physical limitations would favor larger mining players. For instance, if Miner A can handle 100 million transactions per block while Miner B can only handle 10 million, removing the consensus maximum block size would disproportionately benefit Miner A due to its greater block rewards. Ultimately, this would lead to Miner B facing bankruptcy or ceasing mining operations. Hence, the block size maximum will always prove useful in curbing mining centralization, as there will invariably be some physical constraint that favors larger mining participants. 2015-08-06T03:14:53+00:00 + In a discussion on the bitcoin-dev mailing list, it was highlighted that Miner A has the capability to process 100 million transactions per block, while Miner B can only handle 10 million transactions per block. To bridge this gap, one suggestion put forward was for Miner B to sell ASICs and purchase CPU worth 90 million transactions. Another option proposed was to cap the block size at 10 million transactions, which would require Miner A to sell an equivalent amount of CPU and acquire ASICs. However, even with these solutions, Miner A would still maintain an advantage due to its greater financial resources compared to Miner B. This indicates that the issue of centralization in mining is more closely tied to financial capabilities rather than block size.In an email exchange between Gavin Andresen and Jorge Timón in August 2015, they delved into whether Miner A, with its higher transaction processing capacity, could continue to compete effectively against Miner B. Andresen argued that several variables play into the equation of mining profitability, including access to cheaper electricity, advanced mining hardware, affordable labor, and capital for hardware investments. He also brought up the idea of utilizing excess heat generated from mining for productive purposes, suggesting that if mining devices could be repurposed as heaters, it could potentially alter the dynamics of mining centralization. Andresen emphasized that mining should ideally remain decentralized, while considering the number of fee-paying transactions that can be included in blocks as part of the profitability equation.In another email conversation between Timón and Andresen, the question of whether Miner B can maintain competitiveness against Miner A was further explored. Andresen reiterated that various factors contribute to mining profitability, such as access to cheaper electricity, more advanced mining hardware, the ability to utilize excess heat productively, availability of affordable labor, and capital for hardware investment. Although the number of fee-paying transactions currently holds little significance, it will eventually become part of the equation for mining profitability. The goal is to encourage miners to include a substantial number of transactions in their blocks.Challenging the notion that block propagation times alone determine the usefulness of the maximum block size consensus rule in limiting mining centralization, a thought experiment was presented. This hypothetical scenario envisions the existence of superluminal communication and infinite bandwidth for everyone, eliminating the need for consideration of block propagation times. However, even under these ideal conditions, the consensus block size maximum still serves a purpose in preventing mining centralization. Assuming that miners no longer process transactions with fees below 1 satoshi, physical limitations would favor larger mining players. For instance, if Miner A can handle 100 million transactions per block while Miner B can only handle 10 million, removing the consensus maximum block size would disproportionately benefit Miner A due to its greater block rewards. Ultimately, this would lead to Miner B facing bankruptcy or ceasing mining operations. Hence, the block size maximum will always prove useful in curbing mining centralization, as there will invariably be some physical constraint that favors larger mining participants. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_That-email-was-almost-certainly-not-the-real-Satoshi.xml b/static/bitcoin-dev/Aug_2015/combined_That-email-was-almost-certainly-not-the-real-Satoshi.xml index 9d7a3b3123..4c6a66dba6 100644 --- a/static/bitcoin-dev/Aug_2015/combined_That-email-was-almost-certainly-not-the-real-Satoshi.xml +++ b/static/bitcoin-dev/Aug_2015/combined_That-email-was-almost-certainly-not-the-real-Satoshi.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - That email was almost certainly not the real Satoshi - 2023-08-01T15:27:39.781591+00:00 + 2025-10-11T22:06:50.440849+00:00 + python-feedgen Warren Togami Jr. 2015-08-17 18:54:04+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - That email was almost certainly not the real Satoshi - 2023-08-01T15:27:39.782541+00:00 + 2025-10-11T22:06:50.441034+00:00 - The server hosting vistomail.com has been described as chaotic and insecure. Jonathan Wilkins, in a message shared on the bitcoin-dev mailing list, expressed concerns about the server's security practices. He noted that it is a Plesk box with a history of dubious security and numerous open ports. Wilkins provided an nmap scan report for vistomail.com (190.97.163.93), which revealed multiple services running on the server, including MailEnable smtpd, MSRPC, RDP, Microsoft IIS httpd 7.5, and more.Wilkins speculated that the server may have been compromised by someone who is using it for their own amusement. The scan report also indicated that the server is running on a Microsoft Windows operating system, but it is unclear whether it is a general-purpose device or a phone. The details suggest that it could be running on various versions of Windows Server, Windows Professional, Windows Phone, or Windows Vista. It is uncertain whether the open ports are a result of poor security practices or if the server is intentionally set up as a honeypot. Wilkins sent the email to inform the bitcoin-dev community about the potential insecurity of the vistomail.com server and to encourage further investigation into its security measures.In summary, the server hosting vistomail.com is facing security issues, with a Plesk box and multiple services with questionable histories. The nmap scan report highlighted numerous open ports and suggested that the server is running on a Microsoft Windows operating system. It remains unclear whether the open ports are due to negligence or if the server is intentionally set up as a honeypot. Wilkins' email aimed to raise awareness within the bitcoin-dev community and prompt further investigation. 2015-08-17T18:54:04+00:00 + The server hosting vistomail.com has been described as chaotic and insecure. Jonathan Wilkins, in a message shared on the bitcoin-dev mailing list, expressed concerns about the server's security practices. He noted that it is a Plesk box with a history of dubious security and numerous open ports. Wilkins provided an nmap scan report for vistomail.com (190.97.163.93), which revealed multiple services running on the server, including MailEnable smtpd, MSRPC, RDP, Microsoft IIS httpd 7.5, and more.Wilkins speculated that the server may have been compromised by someone who is using it for their own amusement. The scan report also indicated that the server is running on a Microsoft Windows operating system, but it is unclear whether it is a general-purpose device or a phone. The details suggest that it could be running on various versions of Windows Server, Windows Professional, Windows Phone, or Windows Vista. It is uncertain whether the open ports are a result of poor security practices or if the server is intentionally set up as a honeypot. Wilkins sent the email to inform the bitcoin-dev community about the potential insecurity of the vistomail.com server and to encourage further investigation into its security measures.In summary, the server hosting vistomail.com is facing security issues, with a Plesk box and multiple services with questionable histories. The nmap scan report highlighted numerous open ports and suggested that the server is running on a Microsoft Windows operating system. It remains unclear whether the open ports are due to negligence or if the server is intentionally set up as a honeypot. Wilkins' email aimed to raise awareness within the bitcoin-dev community and prompt further investigation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_The-use-of-tx-version-field-in-BIP62-and-68.xml b/static/bitcoin-dev/Aug_2015/combined_The-use-of-tx-version-field-in-BIP62-and-68.xml index aea7e51faa..ef982d364d 100644 --- a/static/bitcoin-dev/Aug_2015/combined_The-use-of-tx-version-field-in-BIP62-and-68.xml +++ b/static/bitcoin-dev/Aug_2015/combined_The-use-of-tx-version-field-in-BIP62-and-68.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The use of tx version field in BIP62 and 68 - 2023-08-01T15:04:39.237538+00:00 + 2025-10-11T22:06:58.933974+00:00 + python-feedgen jl2012 at xbt.hk 2015-08-08 19:18:54+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - The use of tx version field in BIP62 and 68 - 2023-08-01T15:04:39.237538+00:00 + 2025-10-11T22:06:58.934124+00:00 - The author of an email suggests that the current version selection for transactions is not optimal and proposes a solution to improve it. Currently, the selection does not allow for the selective application of new consensus rules. The author's proposal is to divide the transaction version field into two parts: the higher four bits and the lower 28 bits.By dividing the transaction version field, the higher four bits would indicate which Bitcoin Improvement Proposals (BIPs) are active, while the lower 28 bits would allow for 28 independent BIPs. This would make it easier to repurpose nSequence or take advantage of malleability in the future.The author also highlights issues with certain current BIPs, such as BIP62 and BIP68, when introducing a new script system with a soft fork. These BIPs have specific rules that are applied based on the transaction version. BIP68 is activated if the highest bits of a transaction are 0000, and the third lowest bit is 1. Meanwhile, BIP62 is active if the highest bits are 0000, and the second lowest bit is 1.To address these issues, the author suggests that BIP62 and BIP68 should become mandatory for all transactions with a version number greater than or equal to 4. By adopting this change, the nSequence high bit requirement in BIP68 could be easily switched off if needed.Furthermore, by dividing the transaction version field, the low bits would allow for 28 independent BIPs, which should be sufficient for many years. Once these BIPs are exhausted, the high bits can be switched to a different number between 1-15, allowing for the redefinition of the meaning of the low bits. It is important to note that these changes may also apply to other draft BIPs with similar interpretations of the transaction version field.In conclusion, the author suggests dividing the transaction version field into two parts to improve the selection of consensus rules. This solution would address issues with certain BIPs and provide flexibility for future development. 2015-08-08T19:18:54+00:00 + The author of an email suggests that the current version selection for transactions is not optimal and proposes a solution to improve it. Currently, the selection does not allow for the selective application of new consensus rules. The author's proposal is to divide the transaction version field into two parts: the higher four bits and the lower 28 bits.By dividing the transaction version field, the higher four bits would indicate which Bitcoin Improvement Proposals (BIPs) are active, while the lower 28 bits would allow for 28 independent BIPs. This would make it easier to repurpose nSequence or take advantage of malleability in the future.The author also highlights issues with certain current BIPs, such as BIP62 and BIP68, when introducing a new script system with a soft fork. These BIPs have specific rules that are applied based on the transaction version. BIP68 is activated if the highest bits of a transaction are 0000, and the third lowest bit is 1. Meanwhile, BIP62 is active if the highest bits are 0000, and the second lowest bit is 1.To address these issues, the author suggests that BIP62 and BIP68 should become mandatory for all transactions with a version number greater than or equal to 4. By adopting this change, the nSequence high bit requirement in BIP68 could be easily switched off if needed.Furthermore, by dividing the transaction version field, the low bits would allow for 28 independent BIPs, which should be sufficient for many years. Once these BIPs are exhausted, the high bits can be switched to a different number between 1-15, allowing for the redefinition of the meaning of the low bits. It is important to note that these changes may also apply to other draft BIPs with similar interpretations of the transaction version field.In conclusion, the author suggests dividing the transaction version field into two parts to improve the selection of consensus rules. This solution would address issues with certain BIPs and provide flexibility for future development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Uniquely-identifying-forked-chains.xml b/static/bitcoin-dev/Aug_2015/combined_Uniquely-identifying-forked-chains.xml index 4aad86d65d..4837875bf3 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Uniquely-identifying-forked-chains.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Uniquely-identifying-forked-chains.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Uniquely identifying forked chains - 2023-08-01T15:42:09.022034+00:00 + 2025-10-11T22:06:33.439705+00:00 + python-feedgen Jorge Timón 2015-08-28 20:45:29+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Uniquely identifying forked chains - 2023-08-01T15:42:09.022034+00:00 + 2025-10-11T22:06:33.439865+00:00 - In August 2015, a discussion took place on the bitcoin-dev mailing list regarding the use of hash of hashes to identify blockchains. The proposal was made to use either the genesis block hash or a combination of the genesis block hash and block hashes of fork points to identify chains. This would allow for the identification of blockchain forks that are built upon the same genesis block. The proposer argued that it is inevitable that multiple chains will coexist and be actively mined at some point.The proposal suggests extending BIP99's section on schism hardforks to include this method of identifying blockchains. By using the hash of hashes, it would be possible to support forks of varying degrees, including forks of forks and forks of forks of forks, while still maintaining a fixed length chain identifier. This approach would also avoid hurting bystander users who may not be able to distinguish between different currencies or chains.While some may view this proposal as redundant, the proposer emphasized the importance of building systems redundantly to prevent potential issues that may arise from relying solely on the genesis block hash. In times where multiple chains are coexisting and actively mined, users can utilize this method to specifically identify a chain. Alternatively, if a user wants to specify "whatever chain is the longest with PoW," they can use the genesis block hash for a new chain.Overall, the discussion on identifying blockchains for Bitcoin Improvement Proposal (BIP) 21 and other relevant needs highlighted the limitations of using only the genesis block hash and proposed a more comprehensive approach using a hash of hashes. This method would provide support for various types of forks while preserving a fixed length chain identifier, ultimately allowing for the coexistence and active mining of multiple chains. 2015-08-28T20:45:29+00:00 + In August 2015, a discussion took place on the bitcoin-dev mailing list regarding the use of hash of hashes to identify blockchains. The proposal was made to use either the genesis block hash or a combination of the genesis block hash and block hashes of fork points to identify chains. This would allow for the identification of blockchain forks that are built upon the same genesis block. The proposer argued that it is inevitable that multiple chains will coexist and be actively mined at some point.The proposal suggests extending BIP99's section on schism hardforks to include this method of identifying blockchains. By using the hash of hashes, it would be possible to support forks of varying degrees, including forks of forks and forks of forks of forks, while still maintaining a fixed length chain identifier. This approach would also avoid hurting bystander users who may not be able to distinguish between different currencies or chains.While some may view this proposal as redundant, the proposer emphasized the importance of building systems redundantly to prevent potential issues that may arise from relying solely on the genesis block hash. In times where multiple chains are coexisting and actively mined, users can utilize this method to specifically identify a chain. Alternatively, if a user wants to specify "whatever chain is the longest with PoW," they can use the genesis block hash for a new chain.Overall, the discussion on identifying blockchains for Bitcoin Improvement Proposal (BIP) 21 and other relevant needs highlighted the limitations of using only the genesis block hash and proposed a more comprehensive approach using a hash of hashes. This method would provide support for various types of forks while preserving a fixed length chain identifier, ultimately allowing for the coexistence and active mining of multiple chains. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Unlimited-Max-Blocksize-reprise-.xml b/static/bitcoin-dev/Aug_2015/combined_Unlimited-Max-Blocksize-reprise-.xml index 28e8c192f4..65bcf05199 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Unlimited-Max-Blocksize-reprise-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Unlimited-Max-Blocksize-reprise-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Unlimited Max Blocksize (reprise) - 2023-08-01T15:41:15.474273+00:00 + 2025-10-11T22:07:37.281270+00:00 + python-feedgen Tom Harding 2015-08-30 21:10:18+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Unlimited Max Blocksize (reprise) - 2023-08-01T15:41:15.474273+00:00 + 2025-10-11T22:07:37.281447+00:00 - In an email conversation, Peter R and Daniele discuss the optimality of a greedy algorithm mentioned in a paper. Peter agrees with Daniele that the algorithm is asymptotically optimal in a certain case. However, Peter points out that "non-greedy" solutions to the knapsack problem are more relevant when choosing from a smaller number of items with similar sizes to the knapsack itself. Nonetheless, Peter argues that for the average transaction size and block size limit in Bitcoin, quantization effects become small, making the greedy algorithm a reasonable approximation.Tom Harding joins the discussion and informs Daniele that the optimal way to choose transactions for inclusion in a block is a knapsack problem, which is NP-complete. Tom refers to Peter R's analysis on fee markets without blocksize limits, which shows that the advantage of large miners is a side-effect of coinbase subsidization. As block rewards decrease, so will the advantages of large miners. Tom explains that larger blocksizes, as proposed by BIP100-101, aim to increase transaction fees by expanding the network's capacity and reducing mine centralization.In a bitcoin-dev mailing list, the risks of a contentious/schism hardfork are discussed. A document is shared to improve understanding of these risks. The discussion includes Peter_R's analysis on fee markets with uncapped max blocksizes, where it is noted that critiques made towards his work were not definitive. Simulations show that larger miners have advantages due to coinbase subsidization, but this advantage diminishes as block rewards become comparable to transaction fees. It is suggested that raising the max blocksize in a controlled manner can ease the transition into the fee market dynamic. The main critique of uncapped max blocksizes is the advantage that large miners have over smaller ones, but this advantage is attributed to block subsidies. Once block rewards become comparable to transaction fees, this advantage diminishes.The writer expresses concern over the acceptance of complex miner voting protocols as a hard fork option, while considering Mike and Gavin redirecting the Bitcoin protocol as risky. They believe that Peter_R's analysis on fee markets without blocksize limits should be given more weight by the community. The writer suggests controlled increases to the max blocksize to gradually transition into the fee market dynamic. They argue that advantages of large miners do not come from propagating large blocks but rather from block subsidies. As block rewards decrease, these advantages diminish. The writer hopes this matter is considered seriously, especially in the upcoming scaling workshops.Overall, the discussion revolves around the optimality of algorithms, the impact of blocksize limits on fee markets, and the advantages of large miners in the context of block rewards and transaction fees. There is a focus on the potential solutions proposed by BIP100-101 to increase transaction fees and reduce mine centralization. 2015-08-30T21:10:18+00:00 + In an email conversation, Peter R and Daniele discuss the optimality of a greedy algorithm mentioned in a paper. Peter agrees with Daniele that the algorithm is asymptotically optimal in a certain case. However, Peter points out that "non-greedy" solutions to the knapsack problem are more relevant when choosing from a smaller number of items with similar sizes to the knapsack itself. Nonetheless, Peter argues that for the average transaction size and block size limit in Bitcoin, quantization effects become small, making the greedy algorithm a reasonable approximation.Tom Harding joins the discussion and informs Daniele that the optimal way to choose transactions for inclusion in a block is a knapsack problem, which is NP-complete. Tom refers to Peter R's analysis on fee markets without blocksize limits, which shows that the advantage of large miners is a side-effect of coinbase subsidization. As block rewards decrease, so will the advantages of large miners. Tom explains that larger blocksizes, as proposed by BIP100-101, aim to increase transaction fees by expanding the network's capacity and reducing mine centralization.In a bitcoin-dev mailing list, the risks of a contentious/schism hardfork are discussed. A document is shared to improve understanding of these risks. The discussion includes Peter_R's analysis on fee markets with uncapped max blocksizes, where it is noted that critiques made towards his work were not definitive. Simulations show that larger miners have advantages due to coinbase subsidization, but this advantage diminishes as block rewards become comparable to transaction fees. It is suggested that raising the max blocksize in a controlled manner can ease the transition into the fee market dynamic. The main critique of uncapped max blocksizes is the advantage that large miners have over smaller ones, but this advantage is attributed to block subsidies. Once block rewards become comparable to transaction fees, this advantage diminishes.The writer expresses concern over the acceptance of complex miner voting protocols as a hard fork option, while considering Mike and Gavin redirecting the Bitcoin protocol as risky. They believe that Peter_R's analysis on fee markets without blocksize limits should be given more weight by the community. The writer suggests controlled increases to the max blocksize to gradually transition into the fee market dynamic. They argue that advantages of large miners do not come from propagating large blocks but rather from block subsidies. As block rewards decrease, these advantages diminish. The writer hopes this matter is considered seriously, especially in the upcoming scaling workshops.Overall, the discussion revolves around the optimality of algorithms, the impact of blocksize limits on fee markets, and the advantages of large miners in the context of block rewards and transaction fees. There is a focus on the potential solutions proposed by BIP100-101 to increase transaction fees and reduce mine centralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Variable-Block-Size-Proposal.xml b/static/bitcoin-dev/Aug_2015/combined_Variable-Block-Size-Proposal.xml index 79f4dcfd12..c11fce4365 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Variable-Block-Size-Proposal.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Variable-Block-Size-Proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Variable Block Size Proposal - 2023-08-01T15:42:18.872258+00:00 + 2025-10-11T22:06:10.042311+00:00 + python-feedgen Jorge Timón 2015-08-29 20:59:27+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Variable Block Size Proposal - 2023-08-01T15:42:18.872258+00:00 + 2025-10-11T22:06:10.042470+00:00 - In a discussion on Bitcoin block size, Jameson Lopp expresses his opinion that introducing a mandatory minimum block size is wasteful and suggests focusing on O(1) block propagation instead. He recommends the Bitcoin Relay Network as a potential solution for faster block relay. Justin M. Wray proposes a variable block size that aims to balance block propagation with long-term growth and spam attack prevention. The proposal involves calculating the average size of blocks every 2016 blocks and doubling it to set the maximum block size for the following 2016 blocks. A minimum block size of 25% of the current maximum is also introduced to ensure miners are still confirming Bitcoin transactions. All blocks must meet this minimum size to be valid, and padding will be used for blocks lacking sufficient transactions. Wray invites feedback on the proposal, highlighting the network's ability to adjust to spikes in volume and readjust accordingly. The proposal also includes measures to prevent future block-size deflation attacks. 2015-08-29T20:59:27+00:00 + In a discussion on Bitcoin block size, Jameson Lopp expresses his opinion that introducing a mandatory minimum block size is wasteful and suggests focusing on O(1) block propagation instead. He recommends the Bitcoin Relay Network as a potential solution for faster block relay. Justin M. Wray proposes a variable block size that aims to balance block propagation with long-term growth and spam attack prevention. The proposal involves calculating the average size of blocks every 2016 blocks and doubling it to set the maximum block size for the following 2016 blocks. A minimum block size of 25% of the current maximum is also introduced to ensure miners are still confirming Bitcoin transactions. All blocks must meet this minimum size to be valid, and padding will be used for blocks lacking sufficient transactions. Wray invites feedback on the proposal, highlighting the network's ability to adjust to spikes in volume and readjust accordingly. The proposal also includes measures to prevent future block-size deflation attacks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Visualizations-of-Votes.xml b/static/bitcoin-dev/Aug_2015/combined_Visualizations-of-Votes.xml index 19529e7938..908fb16277 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Visualizations-of-Votes.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Visualizations-of-Votes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Visualizations of Votes - 2023-08-01T15:35:26.987248+00:00 + 2025-10-11T22:06:20.676057+00:00 + python-feedgen Daniel Stadulis 2015-08-24 16:38:24+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Visualizations of Votes - 2023-08-01T15:35:26.987248+00:00 + 2025-10-11T22:06:20.676202+00:00 - In an email discussion on the bitcoin-dev mailing list, a user named odinn suggested the idea of creating pie charts to visually represent the percentage of votes for different Bitcoin Improvement Proposals (BIPs). This suggestion was based on the data published in blocks. However, another user responded by stating that pie charts are not an ideal tool for visualizing data and shared a link to an article explaining why bar charts are a better option. According to the article, pie charts can be misleading and difficult to interpret, while stacked or grouped bar charts offer a clearer representation of the data.On August 21, 2015, odinn posted a message on the bitcoin-dev mailing list, seeking visualizations of votes related to various BIPs. Specifically, they requested pie graphs that would show the percentage of miners voting for BIP 100, BIP 101, 8MB, and BIP sipa, based on the information published in blocks. Although odinn included a link to a website that provided insights into how developers felt about different BIPs, they were specifically interested in real-time visualizations that depict miner voting. The post was made on the bitcoin-dev mailing list, which is hosted by the Linux Foundation. No additional details were provided in the initial post.The author of the post, odinn, is seeking visualizations of votes for BIPs. They are particularly interested in pie graphs that illustrate the percentage of votes for different BIPs by miners. While they shared a link to a visualization website they liked, they noted that it only covered the opinions of developers regarding various BIPs. The author desires a visualization that accurately represents miner voting and is updated in real-time. Additionally, they included links to their own website and a protocol concept. 2015-08-24T16:38:24+00:00 + In an email discussion on the bitcoin-dev mailing list, a user named odinn suggested the idea of creating pie charts to visually represent the percentage of votes for different Bitcoin Improvement Proposals (BIPs). This suggestion was based on the data published in blocks. However, another user responded by stating that pie charts are not an ideal tool for visualizing data and shared a link to an article explaining why bar charts are a better option. According to the article, pie charts can be misleading and difficult to interpret, while stacked or grouped bar charts offer a clearer representation of the data.On August 21, 2015, odinn posted a message on the bitcoin-dev mailing list, seeking visualizations of votes related to various BIPs. Specifically, they requested pie graphs that would show the percentage of miners voting for BIP 100, BIP 101, 8MB, and BIP sipa, based on the information published in blocks. Although odinn included a link to a website that provided insights into how developers felt about different BIPs, they were specifically interested in real-time visualizations that depict miner voting. The post was made on the bitcoin-dev mailing list, which is hosted by the Linux Foundation. No additional details were provided in the initial post.The author of the post, odinn, is seeking visualizations of votes for BIPs. They are particularly interested in pie graphs that illustrate the percentage of votes for different BIPs by miners. While they shared a link to a visualization website they liked, they noted that it only covered the opinions of developers regarding various BIPs. The author desires a visualization that accurately represents miner voting and is updated in real-time. Additionally, they included links to their own website and a protocol concept. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Voting-BIP-100-Question-Etc-.xml b/static/bitcoin-dev/Aug_2015/combined_Voting-BIP-100-Question-Etc-.xml index a55b375e93..a38251b758 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Voting-BIP-100-Question-Etc-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Voting-BIP-100-Question-Etc-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Voting (BIP-100) Question, Etc. - 2023-08-01T15:09:23.254299+00:00 + 2025-10-11T22:07:20.204599+00:00 + python-feedgen Jeff Garzik 2015-08-12 16:46:38+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Voting (BIP-100) Question, Etc. - 2023-08-01T15:09:23.254299+00:00 + 2025-10-11T22:07:20.204738+00:00 - Miners are currently in the process of voting on BIP 100, which is expected to be implemented within the next two weeks. However, the exact details of the voting process for miners remain somewhat unclear. To gather more information, the author of an email sent via bitcoin-dev reaches out to the community, specifically referencing a post on Bitcoin Stack Exchange.The author's main query revolves around understanding how miners would cast their votes on BIP 100 if it were to become a viable option. While they have found some relevant information on the Bitcoin Stack Exchange post, there is uncertainty regarding the timing of when miners would actually take action and participate in the voting process.In addition to this primary question, the author poses a follow-up inquiry about the publication and acceptance of BIP 100 on GitHub. They express interest in knowing when exactly BIP 100 will be officially published and moved to the 'accepted' status on the popular code repository platform.Although the message from the author does not explicitly explain what BIP 100 entails, it is evident that their main focus lies in understanding the process of miner voting and the timeline for the publication of BIP 100. To provide further context, the author includes links to their website and Keybase profile, offering additional information about themselves. 2015-08-12T16:46:38+00:00 + Miners are currently in the process of voting on BIP 100, which is expected to be implemented within the next two weeks. However, the exact details of the voting process for miners remain somewhat unclear. To gather more information, the author of an email sent via bitcoin-dev reaches out to the community, specifically referencing a post on Bitcoin Stack Exchange.The author's main query revolves around understanding how miners would cast their votes on BIP 100 if it were to become a viable option. While they have found some relevant information on the Bitcoin Stack Exchange post, there is uncertainty regarding the timing of when miners would actually take action and participate in the voting process.In addition to this primary question, the author poses a follow-up inquiry about the publication and acceptance of BIP 100 on GitHub. They express interest in knowing when exactly BIP 100 will be officially published and moved to the 'accepted' status on the popular code repository platform.Although the message from the author does not explicitly explain what BIP 100 entails, it is evident that their main focus lies in understanding the process of miner voting and the timeline for the publication of BIP 100. To provide further context, the author includes links to their website and Keybase profile, offering additional information about themselves. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Voting-by-locking-coins.xml b/static/bitcoin-dev/Aug_2015/combined_Voting-by-locking-coins.xml index ca125a1d30..f76caaa82b 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Voting-by-locking-coins.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Voting-by-locking-coins.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Voting by locking coins - 2023-08-01T15:04:20.756325+00:00 + 2025-10-11T22:07:47.898423+00:00 + python-feedgen Hector Chu 2015-08-08 15:23:41+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Voting by locking coins - 2023-08-01T15:04:20.756325+00:00 + 2025-10-11T22:07:47.898582+00:00 - The discussion revolves around the concept of using locked coins for voting purposes. It is suggested that locking coins until a certain date for casting votes on an issue could help capture a more accurate consensus. John Dillon's proposal, shared by Peter Todd, outlines a system where users lock their coins in a specific script and their weight in the vote increases based on the duration of the lock. The proposal aims to incentivize long-term decision-making for the Bitcoin network rather than short-term gains.Hector Chu raises questions regarding the locking of coins in a vote scheme. He inquires if the coins would still be freely spendable post-vote. In response, it is explained that John Dillon's proposal aims to have the economic majority give miners permission to raise the blocksize. Making the vote costly would go against the intended design of capturing the broadest possible economic consensus.The proposal suggests using CLTV (CheckLockTimeVerify) to lock coins until the vote closes, which could be three months from the present. The weight of the vote would be determined by the number of coins locked, with the choice written in the scriptPubKey or an OP_RETURN data output. Nodes would tally the coin values for different vote options, and the choice with the highest total would be declared the winner.While this solution may not directly solve the block size issue, it offers potential choices such as maintaining the current block size, reducing it by 10%, or increasing it by 10%. The proposal also mentions the possibility of implementing weighting based on the duration of the coin lock to prevent last-minute voting from having undue influence.Overall, the discussion explores the idea of using locked coins in a voting system to encourage long-term decision-making for the Bitcoin network. The proposal provides a framework for implementing this concept, allowing users to lock their coins and have their votes weighted accordingly. 2015-08-08T15:23:41+00:00 + The discussion revolves around the concept of using locked coins for voting purposes. It is suggested that locking coins until a certain date for casting votes on an issue could help capture a more accurate consensus. John Dillon's proposal, shared by Peter Todd, outlines a system where users lock their coins in a specific script and their weight in the vote increases based on the duration of the lock. The proposal aims to incentivize long-term decision-making for the Bitcoin network rather than short-term gains.Hector Chu raises questions regarding the locking of coins in a vote scheme. He inquires if the coins would still be freely spendable post-vote. In response, it is explained that John Dillon's proposal aims to have the economic majority give miners permission to raise the blocksize. Making the vote costly would go against the intended design of capturing the broadest possible economic consensus.The proposal suggests using CLTV (CheckLockTimeVerify) to lock coins until the vote closes, which could be three months from the present. The weight of the vote would be determined by the number of coins locked, with the choice written in the scriptPubKey or an OP_RETURN data output. Nodes would tally the coin values for different vote options, and the choice with the highest total would be declared the winner.While this solution may not directly solve the block size issue, it offers potential choices such as maintaining the current block size, reducing it by 10%, or increasing it by 10%. The proposal also mentions the possibility of implementing weighting based on the duration of the coin lock to prevent last-minute voting from having undue influence.Overall, the discussion explores the idea of using locked coins in a voting system to encourage long-term decision-making for the Bitcoin network. The proposal provides a framework for implementing this concept, allowing users to lock their coins and have their votes weighted accordingly. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_What-Lightning-Is.xml b/static/bitcoin-dev/Aug_2015/combined_What-Lightning-Is.xml index c6fa6f7f80..082130c754 100644 --- a/static/bitcoin-dev/Aug_2015/combined_What-Lightning-Is.xml +++ b/static/bitcoin-dev/Aug_2015/combined_What-Lightning-Is.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - What Lightning Is - 2023-08-01T15:06:05.084552+00:00 + 2025-10-11T22:05:55.163051+00:00 + python-feedgen Simon Liu 2015-08-11 17:17:58+00:00 @@ -123,13 +124,13 @@ - python-feedgen + 2 Combined summary - What Lightning Is - 2023-08-01T15:06:05.085560+00:00 + 2025-10-11T22:05:55.163272+00:00 - The Lightning Network, a decentralized system built on top of the Bitcoin blockchain, has gained attention for its potential to revolutionize money transfers. However, one important aspect often overlooked is the need for a reliable middleman to facilitate these transactions efficiently.The Lightning Network operates by creating interconnected payment channels between users. These channels allow for instant and low-cost transactions, making it an attractive solution for scaling Bitcoin's capacity. But to establish and maintain these channels, users need a trusted intermediary, or middleman.The middleman plays a crucial role in the Lightning Network ecosystem. They help users set up payment channels with other participants and ensure smooth routing of funds between channels for efficient and secure transactions.To perform these tasks effectively, the middleman must have certain characteristics. Firstly, they need strong connections within the Lightning Network, with established channels to various users. This connectivity allows them to route payments effectively, avoiding bottlenecks and maximizing efficiency.Secondly, the middleman must have sufficient liquidity to accommodate the flow of funds through the network. This can be challenging due to Bitcoin's volatility. Nonetheless, liquidity is essential for ensuring smooth transactions within the Lightning Network.Moreover, the middleman needs a robust infrastructure to handle the demands of the network. This includes reliable servers and effective security measures to protect users' funds. Without a solid technological foundation, the middleman's role is compromised, jeopardizing the overall functionality of the Lightning Network.Recognizing the significance of the middleman is crucial. Their role as a powerful intermediary is vital for enabling efficient and secure transactions. As the Lightning Network continues to evolve and gain adoption, the middleman's role will likely become even more crucial in ensuring its success. 2015-08-11T17:17:58+00:00 + The Lightning Network, a decentralized system built on top of the Bitcoin blockchain, has gained attention for its potential to revolutionize money transfers. However, one important aspect often overlooked is the need for a reliable middleman to facilitate these transactions efficiently.The Lightning Network operates by creating interconnected payment channels between users. These channels allow for instant and low-cost transactions, making it an attractive solution for scaling Bitcoin's capacity. But to establish and maintain these channels, users need a trusted intermediary, or middleman.The middleman plays a crucial role in the Lightning Network ecosystem. They help users set up payment channels with other participants and ensure smooth routing of funds between channels for efficient and secure transactions.To perform these tasks effectively, the middleman must have certain characteristics. Firstly, they need strong connections within the Lightning Network, with established channels to various users. This connectivity allows them to route payments effectively, avoiding bottlenecks and maximizing efficiency.Secondly, the middleman must have sufficient liquidity to accommodate the flow of funds through the network. This can be challenging due to Bitcoin's volatility. Nonetheless, liquidity is essential for ensuring smooth transactions within the Lightning Network.Moreover, the middleman needs a robust infrastructure to handle the demands of the network. This includes reliable servers and effective security measures to protect users' funds. Without a solid technological foundation, the middleman's role is compromised, jeopardizing the overall functionality of the Lightning Network.Recognizing the significance of the middleman is crucial. Their role as a powerful intermediary is vital for enabling efficient and secure transactions. As the Lightning Network continues to evolve and gain adoption, the middleman's role will likely become even more crucial in ensuring its success. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-t-temporary.xml b/static/bitcoin-dev/Aug_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-t-temporary.xml index d4ce19015d..3d66a69a26 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-t-temporary.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-t-temporary.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why Satoshi's temporary anti-spam measure isn't temporary - 2023-08-01T14:38:19.363336+00:00 + 2025-10-11T22:07:05.307285+00:00 + python-feedgen Pieter Wuille 2015-08-01 21:05:10+00:00 @@ -179,13 +180,13 @@ - python-feedgen + 2 Combined summary - Why Satoshi's temporary anti-spam measure isn't temporary - 2023-08-01T14:38:19.365396+00:00 + 2025-10-11T22:07:05.307542+00:00 - The context provided encompasses several discussions and debates within the Bitcoin community. One such debate revolves around the block size limit and its impact on scalability, decentralization, and security. Mark Friedenbach proposed a solution for scaling Bitcoin through distribution with minimal trust, while Thomas Zander emphasized prioritizing security and decentralization over scalability. The conversation highlights the ongoing trade-offs between these factors.Another discussion focuses on the importance of avoiding controversial hard forks when making changes to Bitcoin. Milly Bitcoin suggested a process that includes metrics, risk analysis, mitigation strategies, goals, and roadmaps to measure proposed changes against the baseline system. Jorge Timón agreed with this approach, emphasizing the use of metrics and simulations. The conversation emphasizes the need for a systematic and data-driven approach to decision-making in the Bitcoin ecosystem.Scalability is a complex issue, with differing opinions on timing and approach. Pieter Wuille suggested waiting for Blockstream Elements to be ready before implementing a hard fork, while Gavin Andresen advocated for immediate implementation to set a precedent. They also discussed alternatives such as the Lightning Network and older payment channel designs. The conversation reflects the varying perspectives within the community.The inclusion of smart contracts and off-chain systems into Bitcoin was also debated. Gregory Maxwell and Satoshi Nakamoto discussed the feasibility of incorporating a full domain-registry database on the blockchain and the potential risks to decentralization. The conversation highlighted the need to carefully consider trade-offs between functionality and scalability.The resource requirements of running a full node were also discussed. Eric Lombrozo suggested that users who benefit from the network should contribute to its maintenance by running full nodes. However, others argued that it is not feasible for every user due to resource constraints.There are various perspectives on the trade-off between decentralization, scalability, and security. Some developers believe that increasing block size compromises decentralization, while others raise concerns about the hidden costs and security risks associated with larger blocks. The challenge lies in finding a balance that allows for scalability without compromising core principles.The importance of the original vision of Bitcoin and Satoshi Nakamoto's intentions were also debated. The increasing cost of mining and the potential ramifications for the system were discussed, as well as the need to protect decentralization and maintain Bitcoin's competitive advantages beyond just payments. The community faces challenges in balancing scalability, decentralization, and security.Another discussion focused on transaction fees, SPV wallets, the block size limit, and protocol upgrades. The author argues that transaction fees should not exceed what competitors charge, and SPV wallets are widely used and effective at detecting network forks. The conversation also explores the history and purpose of the one megabyte block size limit and the importance of validators and transaction fees.The lack of progress in addressing existing problems within the Bitcoin community was also raised. Concerns were expressed about the motivation for experts to spend time developing and testing code when it does not directly benefit them. The importance of proactively addressing technical issues to prevent larger problems was emphasized.Overall, the context provides insights into the ongoing debates and concerns within the Bitcoin community regarding block size increase, scalability, decentralization, and the decision-making process for making changes to the Bitcoin ecosystem. It highlights the complexity of these issues and the need for careful consideration of trade-offs and potential risks. 2015-08-01T21:05:10+00:00 + The context provided encompasses several discussions and debates within the Bitcoin community. One such debate revolves around the block size limit and its impact on scalability, decentralization, and security. Mark Friedenbach proposed a solution for scaling Bitcoin through distribution with minimal trust, while Thomas Zander emphasized prioritizing security and decentralization over scalability. The conversation highlights the ongoing trade-offs between these factors.Another discussion focuses on the importance of avoiding controversial hard forks when making changes to Bitcoin. Milly Bitcoin suggested a process that includes metrics, risk analysis, mitigation strategies, goals, and roadmaps to measure proposed changes against the baseline system. Jorge Timón agreed with this approach, emphasizing the use of metrics and simulations. The conversation emphasizes the need for a systematic and data-driven approach to decision-making in the Bitcoin ecosystem.Scalability is a complex issue, with differing opinions on timing and approach. Pieter Wuille suggested waiting for Blockstream Elements to be ready before implementing a hard fork, while Gavin Andresen advocated for immediate implementation to set a precedent. They also discussed alternatives such as the Lightning Network and older payment channel designs. The conversation reflects the varying perspectives within the community.The inclusion of smart contracts and off-chain systems into Bitcoin was also debated. Gregory Maxwell and Satoshi Nakamoto discussed the feasibility of incorporating a full domain-registry database on the blockchain and the potential risks to decentralization. The conversation highlighted the need to carefully consider trade-offs between functionality and scalability.The resource requirements of running a full node were also discussed. Eric Lombrozo suggested that users who benefit from the network should contribute to its maintenance by running full nodes. However, others argued that it is not feasible for every user due to resource constraints.There are various perspectives on the trade-off between decentralization, scalability, and security. Some developers believe that increasing block size compromises decentralization, while others raise concerns about the hidden costs and security risks associated with larger blocks. The challenge lies in finding a balance that allows for scalability without compromising core principles.The importance of the original vision of Bitcoin and Satoshi Nakamoto's intentions were also debated. The increasing cost of mining and the potential ramifications for the system were discussed, as well as the need to protect decentralization and maintain Bitcoin's competitive advantages beyond just payments. The community faces challenges in balancing scalability, decentralization, and security.Another discussion focused on transaction fees, SPV wallets, the block size limit, and protocol upgrades. The author argues that transaction fees should not exceed what competitors charge, and SPV wallets are widely used and effective at detecting network forks. The conversation also explores the history and purpose of the one megabyte block size limit and the importance of validators and transaction fees.The lack of progress in addressing existing problems within the Bitcoin community was also raised. Concerns were expressed about the motivation for experts to spend time developing and testing code when it does not directly benefit them. The importance of proactively addressing technical issues to prevent larger problems was emphasized.Overall, the context provides insights into the ongoing debates and concerns within the Bitcoin community regarding block size increase, scalability, decentralization, and the decision-making process for making changes to the Bitcoin ecosystem. It highlights the complexity of these issues and the need for careful consideration of trade-offs and potential risks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Will-there-be-a-freeze-of-the-current-protocol-version-.xml b/static/bitcoin-dev/Aug_2015/combined_Will-there-be-a-freeze-of-the-current-protocol-version-.xml index 913fd7bb26..ddfa943f5c 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Will-there-be-a-freeze-of-the-current-protocol-version-.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Will-there-be-a-freeze-of-the-current-protocol-version-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Will there be a freeze of the current protocol version? - 2023-08-01T15:34:53.770505+00:00 + 2025-10-11T22:05:44.539755+00:00 + python-feedgen odinn 2015-08-21 03:10:09+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Will there be a freeze of the current protocol version? - 2023-08-01T15:34:53.770505+00:00 + 2025-10-11T22:05:44.539900+00:00 - BitPay, a leading Bitcoin payment processor, has expressed its support for BIP 101, which could potentially lead to an increase in the block size limit. This development comes amid uncertainty about the future of Bitcoin and the need for further research on the current protocol version. The creation of XT, a proposed alternative implementation of Bitcoin, was driven by frustration over the slow progress of research. However, there is hope that the current block chain will continue to survive, albeit with fewer users. The email thread also includes a message from Oliver Egginger via bitcoin-dev, who raises important questions about the possibility of continuing with the old protocol version if XT prevails. One concern is whether there will be enough people to support the old nodes. Additionally, there is uncertainty about whether developers would fork a Bitcoin client to provide security updates for the old nodes. It is also unclear whether compatibility mode in XT would allow it to behave like an old Bitcoin node.The fate of smaller projects such as picocoin, which rely on the current protocol version, is also uncertain. Despite the opposition to XT expressed by the writer of the email, they acknowledge that they would fight against it as long as possible and refuse to use it themselves. The writer's preference is for a block size increase in line with something like BIP 100. 2015-08-21T03:10:09+00:00 + BitPay, a leading Bitcoin payment processor, has expressed its support for BIP 101, which could potentially lead to an increase in the block size limit. This development comes amid uncertainty about the future of Bitcoin and the need for further research on the current protocol version. The creation of XT, a proposed alternative implementation of Bitcoin, was driven by frustration over the slow progress of research. However, there is hope that the current block chain will continue to survive, albeit with fewer users. The email thread also includes a message from Oliver Egginger via bitcoin-dev, who raises important questions about the possibility of continuing with the old protocol version if XT prevails. One concern is whether there will be enough people to support the old nodes. Additionally, there is uncertainty about whether developers would fork a Bitcoin client to provide security updates for the old nodes. It is also unclear whether compatibility mode in XT would allow it to behave like an old Bitcoin node.The fate of smaller projects such as picocoin, which rely on the current protocol version, is also uncertain. Despite the opposition to XT expressed by the writer of the email, they acknowledge that they would fight against it as long as possible and refuse to use it themselves. The writer's preference is for a block size increase in line with something like BIP 100. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Wrapping-up-the-block-size-debate-with-voting.xml b/static/bitcoin-dev/Aug_2015/combined_Wrapping-up-the-block-size-debate-with-voting.xml index c6adb27247..c1daf1bd43 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Wrapping-up-the-block-size-debate-with-voting.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Wrapping-up-the-block-size-debate-with-voting.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Wrapping up the block size debate with voting - 2023-08-01T14:56:05.274804+00:00 + 2025-10-11T22:05:38.166111+00:00 + python-feedgen Will 2015-08-07 00:37:16+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Wrapping up the block size debate with voting - 2023-08-01T14:56:05.274804+00:00 + 2025-10-11T22:05:38.166291+00:00 - The proposed solution to the debate over block size in Bitcoin is to increase it by 8MB and 40% annually, with the option for miners to cap their blocks at a lower amount if necessary. This proposal aims to maintain comity and humility by acknowledging the inability to predict future trends accurately. Miners benefit from higher bitcoin prices and will limit excessive growth of blk*.dat size to avoid centralization and capture by powerful interests. The scheme is predicated on the price going higher over the extended term. Full nodes do not need to be used for propagation, and anyone can vote by coding. The proposal is seen as a reasonable compromise that can be adjusted if necessary down the road.On August 7, 2015, a question was raised on the bitcoin-dev forum regarding whether miners can unilaterally decide to change Bitcoin's protocol rules. Pieter Wuille responded stating that miners don't need to use full nodes for propagation, and they only care about whether their blocks are ultimately accepted. Additionally, full nodes have the ability to change what blocks they accept, which is known as a hard fork.The Bitcoin community is proposing a voting system to determine the future of the cryptocurrency. The proposal outlines several voter groups, including bitcoin miners, bitcoin holders, developers, exchanges, merchants and service providers, and full node operators. Blockchain-based voting would be conducted using a single transferable vote system, with voters ranking their preferences and eliminating candidates until one remains as the most popular. However, there are concerns about the criteria for eligibility in certain voter groups, and how many bitcoins equate to one vote. Technical issues also need to be addressed, such as verifying identities, collecting votes, and ensuring no double voting occurs.The email thread discusses various voting systems to be implemented in the Bitcoin development process. The Single Transferable Vote system is proposed where voters rank their preference with “1”, “2”, “3”, etc. The candidate with fewest votes is eliminated and those votes are transferred according to their second choice until only one candidate is left. Approval and Range voting are suggested as better systems for achieving a consensus. Miners can also choose what the size is subject to limits which they could do unilaterally. The outcome of voting may not necessarily be a binding decision but voters need to recognize that failing to find a middle ground could mean they get their way but they split the community. In addition, since the point is to determine parameters, there is no need to select from discrete candidates like initial new size, rate of increase, and maximum size. They are just numbers and votes could indicate what they want, and then use the median as the consensus option.The bitcoin-development mailing list has been discussing proposals for scaling the network, and a recent post suggests that it is not scientific or sensible to go straight from proposal stage to voting and implementation. The post argues that the proposals need to undergo testing and scenario simulation with published results in order for objective evaluation to be possible. Additionally, the lack of provision for scaling down in the current proposals is noted, and the potential implications of global credit contraction or natural disaster on usage, scale, decentralization, and security are discussed.In August 2015, a debate began on the Bitcoin-dev mailing list about how to make changes to Bitcoin's consensus rules. Pieter Wuille argued that Bitcoin's consensus rules are a consensus system, not a democracy, and suggested that if people want a majority to decide on a currency's economic policy, they should use fiat currencies. A proposal to wrap up the debate with voting by different stakeholder groups was presented, including miners, Bitcoin holders, developers, exchanges, merchants and service providers, and full node operators. The proposal outlined the requirements for each group to be eligible to vote, as well as the voting system, which used a single transferable vote and required voters to rank their preference. Technical issues such as double voting and multiple identities were also addressed.In a recent post on the Bitcoin-dev mailing list, Venzen suggests that it is not scientific or sensible to go from the proposal stage straight to voting and then implementation stage. Instead, proposals should be tested and scenario simulated with published results in order for objective evaluation to be made possible. Venzen argues that there is a lack of provision for scaling down in the current proposals as well. In response to this post, jl2012 proposes candidate proposals and a voting system for different stakeholder groups. The voter groups include miners, Bitcoin holders, developers, exchanges, merchants and service providers, and full nodes operators. The votes will be counted independently, and each group has its own eligibility criteria. Single transferable vote is applied, and voters are required to rank their preference with “1”, “2”, “3”, etc, or use “N” to indicate rejection of a candidate. Technical issues with the voting system are also discussed, including the need for a trusted person to verify voters' identity by email, website, or digital signature. For 2015-08-07T00:37:16+00:00 + The proposed solution to the debate over block size in Bitcoin is to increase it by 8MB and 40% annually, with the option for miners to cap their blocks at a lower amount if necessary. This proposal aims to maintain comity and humility by acknowledging the inability to predict future trends accurately. Miners benefit from higher bitcoin prices and will limit excessive growth of blk*.dat size to avoid centralization and capture by powerful interests. The scheme is predicated on the price going higher over the extended term. Full nodes do not need to be used for propagation, and anyone can vote by coding. The proposal is seen as a reasonable compromise that can be adjusted if necessary down the road.On August 7, 2015, a question was raised on the bitcoin-dev forum regarding whether miners can unilaterally decide to change Bitcoin's protocol rules. Pieter Wuille responded stating that miners don't need to use full nodes for propagation, and they only care about whether their blocks are ultimately accepted. Additionally, full nodes have the ability to change what blocks they accept, which is known as a hard fork.The Bitcoin community is proposing a voting system to determine the future of the cryptocurrency. The proposal outlines several voter groups, including bitcoin miners, bitcoin holders, developers, exchanges, merchants and service providers, and full node operators. Blockchain-based voting would be conducted using a single transferable vote system, with voters ranking their preferences and eliminating candidates until one remains as the most popular. However, there are concerns about the criteria for eligibility in certain voter groups, and how many bitcoins equate to one vote. Technical issues also need to be addressed, such as verifying identities, collecting votes, and ensuring no double voting occurs.The email thread discusses various voting systems to be implemented in the Bitcoin development process. The Single Transferable Vote system is proposed where voters rank their preference with “1”, “2”, “3”, etc. The candidate with fewest votes is eliminated and those votes are transferred according to their second choice until only one candidate is left. Approval and Range voting are suggested as better systems for achieving a consensus. Miners can also choose what the size is subject to limits which they could do unilaterally. The outcome of voting may not necessarily be a binding decision but voters need to recognize that failing to find a middle ground could mean they get their way but they split the community. In addition, since the point is to determine parameters, there is no need to select from discrete candidates like initial new size, rate of increase, and maximum size. They are just numbers and votes could indicate what they want, and then use the median as the consensus option.The bitcoin-development mailing list has been discussing proposals for scaling the network, and a recent post suggests that it is not scientific or sensible to go straight from proposal stage to voting and implementation. The post argues that the proposals need to undergo testing and scenario simulation with published results in order for objective evaluation to be possible. Additionally, the lack of provision for scaling down in the current proposals is noted, and the potential implications of global credit contraction or natural disaster on usage, scale, decentralization, and security are discussed.In August 2015, a debate began on the Bitcoin-dev mailing list about how to make changes to Bitcoin's consensus rules. Pieter Wuille argued that Bitcoin's consensus rules are a consensus system, not a democracy, and suggested that if people want a majority to decide on a currency's economic policy, they should use fiat currencies. A proposal to wrap up the debate with voting by different stakeholder groups was presented, including miners, Bitcoin holders, developers, exchanges, merchants and service providers, and full node operators. The proposal outlined the requirements for each group to be eligible to vote, as well as the voting system, which used a single transferable vote and required voters to rank their preference. Technical issues such as double voting and multiple identities were also addressed.In a recent post on the Bitcoin-dev mailing list, Venzen suggests that it is not scientific or sensible to go from the proposal stage straight to voting and then implementation stage. Instead, proposals should be tested and scenario simulated with published results in order for objective evaluation to be made possible. Venzen argues that there is a lack of provision for scaling down in the current proposals as well. In response to this post, jl2012 proposes candidate proposals and a voting system for different stakeholder groups. The voter groups include miners, Bitcoin holders, developers, exchanges, merchants and service providers, and full nodes operators. The votes will be counted independently, and each group has its own eligibility criteria. Single transferable vote is applied, and voters are required to rank their preference with “1”, “2”, “3”, etc, or use “N” to indicate rejection of a candidate. Technical issues with the voting system are also discussed, including the need for a trusted person to verify voters' identity by email, website, or digital signature. For - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_Your-Gmaxwell-exchange.xml b/static/bitcoin-dev/Aug_2015/combined_Your-Gmaxwell-exchange.xml index 6c91a03a3f..8cd34512d6 100644 --- a/static/bitcoin-dev/Aug_2015/combined_Your-Gmaxwell-exchange.xml +++ b/static/bitcoin-dev/Aug_2015/combined_Your-Gmaxwell-exchange.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Your Gmaxwell exchange - 2023-08-01T15:49:46.075445+00:00 + 2025-10-11T22:05:40.290764+00:00 + python-feedgen Justus Ranvier 2015-09-02 18:51:08+00:00 @@ -115,13 +116,13 @@ - python-feedgen + 2 Combined summary - Your Gmaxwell exchange - 2023-08-01T15:49:46.076445+00:00 + 2025-10-11T22:05:40.290976+00:00 - In an email to the bitcoin-dev mailing list, Justus Ranvier outlined three essential properties that bitcoin users should have. Firstly, they should own their bitcoins and retain exclusive control over their balances. Secondly, their fraction of the bitcoin ledger must not be diluted. Lastly, users should be able to spend their coins without requiring permission from a third party. However, these properties are only possible if the system remains decentralized. Both miner and full node over-centralization could result in permission requirements to submit transactions, transactions being reversed without consent, and dilution of users' fractions of the ledger. Without decentralization, bitcoin is just an inefficient ledger database, and all of its attractive properties are derived from spreading responsibility as widely globally as possible.In a discussion on decentralized bitcoin development, Eric Voskuil argues against the idea of forking as a means of achieving decentralization. He believes that true decentralization requires actually doing so, and that even forking is a major commitment. He also notes that common consensus check code is available in several bitcoin implementations, and that the claim that this is outrageously difficult is misleading. In response to Voskuil's comments, another participant in the discussion argues that there is no requirement for there to be multiple interpretations of the consensus code, citing the existence of libbitcoinconsensus. They question why Bitcoin's survival would be predicated on reimplementation. Finally, Voskuil acknowledges that these issues apply to Bitcoin Core as well as other implementations.In an email exchange on the Bitcoin-dev mailing list, Monarch made a comment about the difficulty of software development with regards to decentralized bitcoin development. Dave Collins responded by stating that there have not been any btcd mainnet forks since it came out of alpha and that common consensus check code is now available in several bitcoin implementations. He claims that this is just engineering work that needs to get done if Bitcoin is to survive. Monarch then clarified that his comment was not intended as an attack against any specific software but rather to highlight the difficulty of working on decentralized bitcoin development. He noted that the use of CPP and OpenSSL can make it difficult to infer behavior and that there are likely more problems lurking in the transaction environment. However, these issues affect the Satoshi client as much as other implementations and do not support the premise that alternative implementations are inherently more difficult to develop.In a discussion on the bitcoin-dev mailing list, Dave Collins was curious about btcd mainnet forks that had occurred since it came out of alpha. However, he noted that there haven't been any such forks yet, although he didn't rule out the possibility of one happening in the future. He also clarified that his point was not to attack btcd, but rather to emphasize the difficulty of software development in this space.Collins pointed out that Bitcoin Core itself had experienced actual forks on the mainnet during the same period. He acknowledged that no developer is perfect and that mistakes are bound to happen from time to time. The bigger picture, however, is that the overall development process for cryptocurrency is challenging due to the complexity of the technology involved.One of the issues with developing cryptocurrency software is that it's difficult to know what behavior is inferred by the use of CPP and OpenSSL. Collins noted that the recent DER encoding consensus failure highlighted this fact. Additionally, there are likely other problems lurking in the transaction environment, which can be easy to overlook given how complex Bitcoin script can be. Overall, the conversation underscored the challenges that developers face when working with these cutting-edge technologies.The person asking the question in this context is interested to know about the supposed btcd mainnet forks that have occurred due to a consensus failure since it came out of alpha. The answer states that there hasn't been one so far, but there might be in the future, just as it can happen with Bitcoin Core as well. A potential instance was found due to fuzzing, which prompted an audit of the code base and resulted in improved test coverage in Bitcoin Core. However, Bitcoin Core has had actual forks on mainnet during the same period.The author believes that the community needs to take the reality seriously that an infrastructure built on a single implementation is incredibly fragile and prone to unintentional hard forks regardless of the existence of alternative implementations. The absence of real disaster prevention measures for unintentional incompatibilities between different versions of the same implementation adds to this fragility. It is mentioned that several improvements such as improved test coverage and more robust and modular code have already been made after the incident and that it has not ended poorly by any means.Furthermore, the post made by Monarch via bitcoin-dev is also referred to, where they state that even heroic attempts at making consensus-compatible re-implementations have ended rather poorly. Bitcoin-ruby and btcd have collectively had numerous consensus failures, some only recently found by fuzzing the scripting environment. There are more failures than publicly disclosed, and almost any failure can be leveraged to split the network and steal money.The 2015-09-02T18:51:08+00:00 + In an email to the bitcoin-dev mailing list, Justus Ranvier outlined three essential properties that bitcoin users should have. Firstly, they should own their bitcoins and retain exclusive control over their balances. Secondly, their fraction of the bitcoin ledger must not be diluted. Lastly, users should be able to spend their coins without requiring permission from a third party. However, these properties are only possible if the system remains decentralized. Both miner and full node over-centralization could result in permission requirements to submit transactions, transactions being reversed without consent, and dilution of users' fractions of the ledger. Without decentralization, bitcoin is just an inefficient ledger database, and all of its attractive properties are derived from spreading responsibility as widely globally as possible.In a discussion on decentralized bitcoin development, Eric Voskuil argues against the idea of forking as a means of achieving decentralization. He believes that true decentralization requires actually doing so, and that even forking is a major commitment. He also notes that common consensus check code is available in several bitcoin implementations, and that the claim that this is outrageously difficult is misleading. In response to Voskuil's comments, another participant in the discussion argues that there is no requirement for there to be multiple interpretations of the consensus code, citing the existence of libbitcoinconsensus. They question why Bitcoin's survival would be predicated on reimplementation. Finally, Voskuil acknowledges that these issues apply to Bitcoin Core as well as other implementations.In an email exchange on the Bitcoin-dev mailing list, Monarch made a comment about the difficulty of software development with regards to decentralized bitcoin development. Dave Collins responded by stating that there have not been any btcd mainnet forks since it came out of alpha and that common consensus check code is now available in several bitcoin implementations. He claims that this is just engineering work that needs to get done if Bitcoin is to survive. Monarch then clarified that his comment was not intended as an attack against any specific software but rather to highlight the difficulty of working on decentralized bitcoin development. He noted that the use of CPP and OpenSSL can make it difficult to infer behavior and that there are likely more problems lurking in the transaction environment. However, these issues affect the Satoshi client as much as other implementations and do not support the premise that alternative implementations are inherently more difficult to develop.In a discussion on the bitcoin-dev mailing list, Dave Collins was curious about btcd mainnet forks that had occurred since it came out of alpha. However, he noted that there haven't been any such forks yet, although he didn't rule out the possibility of one happening in the future. He also clarified that his point was not to attack btcd, but rather to emphasize the difficulty of software development in this space.Collins pointed out that Bitcoin Core itself had experienced actual forks on the mainnet during the same period. He acknowledged that no developer is perfect and that mistakes are bound to happen from time to time. The bigger picture, however, is that the overall development process for cryptocurrency is challenging due to the complexity of the technology involved.One of the issues with developing cryptocurrency software is that it's difficult to know what behavior is inferred by the use of CPP and OpenSSL. Collins noted that the recent DER encoding consensus failure highlighted this fact. Additionally, there are likely other problems lurking in the transaction environment, which can be easy to overlook given how complex Bitcoin script can be. Overall, the conversation underscored the challenges that developers face when working with these cutting-edge technologies.The person asking the question in this context is interested to know about the supposed btcd mainnet forks that have occurred due to a consensus failure since it came out of alpha. The answer states that there hasn't been one so far, but there might be in the future, just as it can happen with Bitcoin Core as well. A potential instance was found due to fuzzing, which prompted an audit of the code base and resulted in improved test coverage in Bitcoin Core. However, Bitcoin Core has had actual forks on mainnet during the same period.The author believes that the community needs to take the reality seriously that an infrastructure built on a single implementation is incredibly fragile and prone to unintentional hard forks regardless of the existence of alternative implementations. The absence of real disaster prevention measures for unintentional incompatibilities between different versions of the same implementation adds to this fragility. It is mentioned that several improvements such as improved test coverage and more robust and modular code have already been made after the incident and that it has not ended poorly by any means.Furthermore, the post made by Monarch via bitcoin-dev is also referred to, where they state that even heroic attempts at making consensus-compatible re-implementations have ended rather poorly. Bitcoin-ruby and btcd have collectively had numerous consensus failures, some only recently found by fuzzing the scripting environment. There are more failures than publicly disclosed, and almost any failure can be leveraged to split the network and steal money.The - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_bitcoin-dev-list-etiquette.xml b/static/bitcoin-dev/Aug_2015/combined_bitcoin-dev-list-etiquette.xml index 4db2d7079f..9a1cdb67f0 100644 --- a/static/bitcoin-dev/Aug_2015/combined_bitcoin-dev-list-etiquette.xml +++ b/static/bitcoin-dev/Aug_2015/combined_bitcoin-dev-list-etiquette.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-dev list etiquette - 2023-08-01T15:34:41.420076+00:00 + 2025-10-11T22:06:24.926492+00:00 + python-feedgen Jorge Timón 2015-08-19 23:13:59+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - bitcoin-dev list etiquette - 2023-08-01T15:34:41.420076+00:00 + 2025-10-11T22:06:24.926648+00:00 - In August 2015, the bitcoin-dev community engaged in a discussion regarding the need for a Bitcoin Improvement Proposal (BIP) to address the emergence of Bitcoin XT and its potential impact on the blockchain. Bitcoin XT is a software fork of Bitcoin Core that aims to increase the block size limit of the Bitcoin network. However, this change has been controversial within the Bitcoin community due to concerns about centralization and other issues.The conversation took place on the bitcoin-dev mailing list, with members expressing varying opinions on the intersection of politics and technology in Bitcoin's development. Some argued that politics cannot be avoided and should be discussed among developers, while others felt that excessive political discussion detracts from technical discussions related to Bitcoin development.The email thread also referenced the importance of consensus and the need to address the ongoing debate within the Bitcoin community regarding scalability and the future direction of the network. It was noted that the biggest challenge facing Bitcoin at the time was not technical but political, and that until political issues were resolved, technical discussions would be purely philosophical.Amidst the discussion, Alex Morcos urged members of the bitcoin-dev community to exercise self-restraint and limit non-technical discussions on the mailing list. He emphasized the need to focus on technical development and maintain a higher signal-to-noise ratio. Morcos suggested that philosophical debates should be taken to other forums, and provided links to a Facebook group and an article discussing Bitcoin politics in New York State.Overall, the email exchange highlighted the need to acknowledge the intersection between politics and technology in Bitcoin's development, while emphasizing the importance of maintaining a focus on technical discussions within the bitcoin-dev community. The discussions revolved around the impact of Bitcoin XT on the blockchain, the challenges posed by political issues, and the call for self-restraint and a higher signal-to-noise ratio in the mailing list discussions. 2015-08-19T23:13:59+00:00 + In August 2015, the bitcoin-dev community engaged in a discussion regarding the need for a Bitcoin Improvement Proposal (BIP) to address the emergence of Bitcoin XT and its potential impact on the blockchain. Bitcoin XT is a software fork of Bitcoin Core that aims to increase the block size limit of the Bitcoin network. However, this change has been controversial within the Bitcoin community due to concerns about centralization and other issues.The conversation took place on the bitcoin-dev mailing list, with members expressing varying opinions on the intersection of politics and technology in Bitcoin's development. Some argued that politics cannot be avoided and should be discussed among developers, while others felt that excessive political discussion detracts from technical discussions related to Bitcoin development.The email thread also referenced the importance of consensus and the need to address the ongoing debate within the Bitcoin community regarding scalability and the future direction of the network. It was noted that the biggest challenge facing Bitcoin at the time was not technical but political, and that until political issues were resolved, technical discussions would be purely philosophical.Amidst the discussion, Alex Morcos urged members of the bitcoin-dev community to exercise self-restraint and limit non-technical discussions on the mailing list. He emphasized the need to focus on technical development and maintain a higher signal-to-noise ratio. Morcos suggested that philosophical debates should be taken to other forums, and provided links to a Facebook group and an article discussing Bitcoin politics in New York State.Overall, the email exchange highlighted the need to acknowledge the intersection between politics and technology in Bitcoin's development, while emphasizing the importance of maintaining a focus on technical discussions within the bitcoin-dev community. The discussions revolved around the impact of Bitcoin XT on the blockchain, the challenges posed by political issues, and the call for self-restraint and a higher signal-to-noise ratio in the mailing list discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_libconsensus-assertion-fails-if-used-in-multiple-threads.xml b/static/bitcoin-dev/Aug_2015/combined_libconsensus-assertion-fails-if-used-in-multiple-threads.xml index 3c42493f77..42ac079e02 100644 --- a/static/bitcoin-dev/Aug_2015/combined_libconsensus-assertion-fails-if-used-in-multiple-threads.xml +++ b/static/bitcoin-dev/Aug_2015/combined_libconsensus-assertion-fails-if-used-in-multiple-threads.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - libconsensus assertion fails if used in multiple threads - 2023-08-01T15:14:52.847385+00:00 + 2025-10-11T22:06:44.063035+00:00 + python-feedgen Eric Voskuil 2015-08-18 21:40:27+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - libconsensus assertion fails if used in multiple threads - 2023-08-01T15:14:52.847385+00:00 + 2025-10-11T22:06:44.063201+00:00 - In an email exchange, Tamas Blummer confirms that libconsensus is running stable within the Bits of Proof stack and its performance is close to the Java-based implementation. Cory Fields notes that Core is switching to libsecp256k1 for speed and there is no timeline for integration. Fields also disputes Blummer's claim that modern implementations validating transactions in multiple threads are affected by the OpenSSL race issue. Blummer hopes that the pull request will be included in the next release of Core and asks about the timeline for secp256k1 integration, to which Fields avoids guessing. Fields has discovered an issue in OpenSSL relating to the secp256k1 curve used by Bitcoin and other cryptocurrencies. He has prepared a patch for anyone who may encounter the issue, but since Bitcoin Core and libbitcoinconsensus are switching away from OpenSSL, it is not seen as a major problem. Blummer confirms that libconsensus works correctly within the Bits of Proof stack and its performance is close to the Java version. However, he disagrees with Fields' claim that the problem is rare in the real-world. Tamas Blummer posts on the bitcoin-dev mailing list stating that while integrating libconsensus into bits of proof, it worked well for all test cases with their Java engine and was about 50% faster on a single thread. However, an error occurred when executed on several threads simultaneously due to the lack of registration of thread callbacks as advised for OpenSSL. The integration of libconsensus into bits of proof is successful and works well with the Java engine, but an error occurs when executed on multiple threads simultaneously due to the lack of registration of thread callbacks as advised for OpenSSL. A workaround is being sought. 2015-08-18T21:40:27+00:00 + In an email exchange, Tamas Blummer confirms that libconsensus is running stable within the Bits of Proof stack and its performance is close to the Java-based implementation. Cory Fields notes that Core is switching to libsecp256k1 for speed and there is no timeline for integration. Fields also disputes Blummer's claim that modern implementations validating transactions in multiple threads are affected by the OpenSSL race issue. Blummer hopes that the pull request will be included in the next release of Core and asks about the timeline for secp256k1 integration, to which Fields avoids guessing. Fields has discovered an issue in OpenSSL relating to the secp256k1 curve used by Bitcoin and other cryptocurrencies. He has prepared a patch for anyone who may encounter the issue, but since Bitcoin Core and libbitcoinconsensus are switching away from OpenSSL, it is not seen as a major problem. Blummer confirms that libconsensus works correctly within the Bits of Proof stack and its performance is close to the Java version. However, he disagrees with Fields' claim that the problem is rare in the real-world. Tamas Blummer posts on the bitcoin-dev mailing list stating that while integrating libconsensus into bits of proof, it worked well for all test cases with their Java engine and was about 50% faster on a single thread. However, an error occurred when executed on several threads simultaneously due to the lack of registration of thread callbacks as advised for OpenSSL. The integration of libconsensus into bits of proof is successful and works well with the Java engine, but an error occurs when executed on multiple threads simultaneously due to the lack of registration of thread callbacks as advised for OpenSSL. A workaround is being sought. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2015/combined_trust.xml b/static/bitcoin-dev/Aug_2015/combined_trust.xml index 03d58df6f5..a615aacea2 100644 --- a/static/bitcoin-dev/Aug_2015/combined_trust.xml +++ b/static/bitcoin-dev/Aug_2015/combined_trust.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - trust - 2023-08-01T15:04:06.682711+00:00 + 2025-10-11T22:07:41.528712+00:00 + python-feedgen Joseph Poon 2015-08-11 04:17:53+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - trust - 2023-08-01T15:04:06.682711+00:00 + 2025-10-11T22:07:41.528870+00:00 - In a recent discussion on the bitcoin-dev mailing list, Joseph Poon addresses questions about online identification and non-cooperative hubs in relation to the Lightning Network. He explains that if a node is offline during a payment transaction, the payment can be cancelled and re-routed. However, the Lightning Network currently does not solve the key exchange problem, which requires out-of-band public-key infrastructure for user identification. Poon suggests that every transaction should have signed proof of payment to ensure that the recipient receives the funds.Poon also discusses the issue of non-cooperative hubs flooding the network and making it unusable. He explains that there are incentives for keeping the system functional through fees. If someone attempts to flood the system, they will likely end up paying substantial fees, which could be seen as an attack by those running nodes. Poon emphasizes the importance of considering various attack models.Thomas Zander challenges the belief that Bitcoin's reason for existence is to avoid trusting anyone but oneself. He argues that a trustless system is one where it is possible to trust everyone, even the untrustworthy, through high confidence in faithful behavior. Trust, in this sense, encompasses expectations of faithful behavior and blind reliance. Zander suggests that a strongly decentralized system requires this approach to avoid driving towards natural monopolies.Jorge Timón and Adam discuss how trust can be involved in different ways with Bitcoin. Timón argues that deviating from the trust-no-one path compromises Bitcoin's functionality, while Zander proposes that risks can be mitigated by having various data centers around the world where software can be run. Zander provides examples of how Bitcoin could benefit the unbanked population and emphasizes the need for larger blocks for these use cases.The concept of trust in the Bitcoin world is not binary. While some people distrust established financial systems, there are individuals within the Bitcoin sphere who need to be trusted for important tasks such as managing the Wiki and Github repository. The lightning network is often praised as a trustless system, but it still requires trust during transactions in the channel. There is confusion about the trade-offs involved in decentralization and reaching consensus, and many people may not fully understand the implications of claims about the "trustlessness" of Bitcoin.In an email conversation between Thomas Zander and Adam Back, they discuss on-chain and off-chain transactions. Back argues that Bitcoin is designed for people who are not fully comfortable trusting others with their money. However, Zander clarifies that the goal of Bitcoin is not to eliminate trust completely but rather to reduce the need for it in certain situations. Bitcoin allows users to hold money and conduct transactions without relying on centralized authorities like central banks. Zander suggests that providing security at scale may be possible with lightning-like protocols.The discussion also touches on the topic of trust in the Lightning Network proposal. Participants debate whether explicit trust and identification are necessary, and if non-cooperative hubs could flood the network. One participant argues that Lightning assumes explicit trust and ID, similar to Ripple, but this approach will not work. Another participant suggests that Lightning does not require explicit trust and that coins can end up blocked until the next in-chain broadcast. Trust takes various forms and is not a binary function, and insights from the history of money can help understand these problems.Overall, trust in the Bitcoin network is multifaceted and not black and white. While there are different levels of trust required, terms like "trustless" and "decentralized" indicate an acceptable level of trust in the system. The development of lightning-like protocols may provide increased security while maintaining scale and decentralization. It is important to consider the implications of claims about trustlessness in Bitcoin and strive for a system that allows users to trust everyone while minimizing the risks associated with trust relationships. 2015-08-11T04:17:53+00:00 + In a recent discussion on the bitcoin-dev mailing list, Joseph Poon addresses questions about online identification and non-cooperative hubs in relation to the Lightning Network. He explains that if a node is offline during a payment transaction, the payment can be cancelled and re-routed. However, the Lightning Network currently does not solve the key exchange problem, which requires out-of-band public-key infrastructure for user identification. Poon suggests that every transaction should have signed proof of payment to ensure that the recipient receives the funds.Poon also discusses the issue of non-cooperative hubs flooding the network and making it unusable. He explains that there are incentives for keeping the system functional through fees. If someone attempts to flood the system, they will likely end up paying substantial fees, which could be seen as an attack by those running nodes. Poon emphasizes the importance of considering various attack models.Thomas Zander challenges the belief that Bitcoin's reason for existence is to avoid trusting anyone but oneself. He argues that a trustless system is one where it is possible to trust everyone, even the untrustworthy, through high confidence in faithful behavior. Trust, in this sense, encompasses expectations of faithful behavior and blind reliance. Zander suggests that a strongly decentralized system requires this approach to avoid driving towards natural monopolies.Jorge Timón and Adam discuss how trust can be involved in different ways with Bitcoin. Timón argues that deviating from the trust-no-one path compromises Bitcoin's functionality, while Zander proposes that risks can be mitigated by having various data centers around the world where software can be run. Zander provides examples of how Bitcoin could benefit the unbanked population and emphasizes the need for larger blocks for these use cases.The concept of trust in the Bitcoin world is not binary. While some people distrust established financial systems, there are individuals within the Bitcoin sphere who need to be trusted for important tasks such as managing the Wiki and Github repository. The lightning network is often praised as a trustless system, but it still requires trust during transactions in the channel. There is confusion about the trade-offs involved in decentralization and reaching consensus, and many people may not fully understand the implications of claims about the "trustlessness" of Bitcoin.In an email conversation between Thomas Zander and Adam Back, they discuss on-chain and off-chain transactions. Back argues that Bitcoin is designed for people who are not fully comfortable trusting others with their money. However, Zander clarifies that the goal of Bitcoin is not to eliminate trust completely but rather to reduce the need for it in certain situations. Bitcoin allows users to hold money and conduct transactions without relying on centralized authorities like central banks. Zander suggests that providing security at scale may be possible with lightning-like protocols.The discussion also touches on the topic of trust in the Lightning Network proposal. Participants debate whether explicit trust and identification are necessary, and if non-cooperative hubs could flood the network. One participant argues that Lightning assumes explicit trust and ID, similar to Ripple, but this approach will not work. Another participant suggests that Lightning does not require explicit trust and that coins can end up blocked until the next in-chain broadcast. Trust takes various forms and is not a binary function, and insights from the history of money can help understand these problems.Overall, trust in the Bitcoin network is multifaceted and not black and white. While there are different levels of trust required, terms like "trustless" and "decentralized" indicate an acceptable level of trust in the system. The development of lightning-like protocols may provide increased security while maintaining scale and decentralization. It is important to consider the implications of claims about trustlessness in Bitcoin and strive for a system that allows users to trust everyone while minimizing the risks associated with trust relationships. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Aug_2016/combined_-Changing-the-blocksize-limit.xml b/static/bitcoin-dev/Aug_2016/combined_-Changing-the-blocksize-limit.xml index ef51682fa1..faeb99656d 100644 --- a/static/bitcoin-dev/Aug_2016/combined_-Changing-the-blocksize-limit.xml +++ b/static/bitcoin-dev/Aug_2016/combined_-Changing-the-blocksize-limit.xml @@ -2,7 +2,7 @@ 2 Combined summary - *Changing* the blocksize limit - 2025-09-26T15:30:20.731554+00:00 + 2025-10-11T21:31:45.907840+00:00 python-feedgen Peter Todd 2016-08-09 02:21:29+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - *Changing* the blocksize limit - 2025-09-26T15:30:20.731715+00:00 + 2025-10-11T21:31:45.908000+00:00 2016-08-09T02:21:29+00:00 Chris Priest, a bitcoin developer, proposed a change to the blocksize limit of Bitcoin in August 2016. The current blocksize limit is denominated in bytes, which means that miners choose transactions based on their fee/byte ratio. Transactions with many inputs require more fees as they are bigger in size. Priest believed that this was a flaw in Bitcoin and suggested a change to the blocksize limit denominated in outputs.This change would incentivize microtransactions, decrease the UTXO set, and bring data that could be used to determine how to scale Bitcoin in the future. However, his initial proposal was rejected due to requiring a database index. Priest's new proposal, called BIP131, achieves the same effect as his initial proposal without needing a database index.If the blocksize limit were removed and replaced with a "block output limit", miners would choose transactions based on maximum fee per output. This would essentially make it free to include an input to a transaction. If the blocksize limit is to be changed to a block output limit, the number should be roughly the amount of outputs found in 1MB blocks today. Blocks can be bigger than 1MB, but the extra data in the block will not result in more people using bitcoin, but rather existing users spending inputs to decrease the UTXO set.Priest's proposal would also serve to decrease the UTXO set, as there is a "minimum profitability to include an input to a transaction" which increases as blocks fill up and fees rise. Any UTXO worth less than a certain amount, such as 2 cents, is not economical to add to a transaction and is likely to never be spent. This contributes to the "UTXO bloat problem" that many people talk about as being a significant issue.In conclusion, Chris Priest's proposal to change the blocksize limit of Bitcoin to a block output limit would incentivize microtransactions, decrease the UTXO set, and bring about data that could be used to determine how to scale Bitcoin in the future. Though his initial proposal was rejected, his new proposal achieves the same effect without requiring a database index. The blocksize limit should be roughly the amount of outputs found in 1MB blocks today if this change is to be implemented. However, there are still those who oppose the change. diff --git a/static/bitcoin-dev/Aug_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml b/static/bitcoin-dev/Aug_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml index 5bcbd29348..953474a8cd 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Attack by modifying non-segwit transactions after segwit is accepted ? - 2025-09-26T15:30:01.688003+00:00 + 2025-10-11T21:31:26.758012+00:00 python-feedgen Johnson Lau 2016-09-01 11:29:29+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Attack by modifying non-segwit transactions after segwit is accepted ? - 2025-09-26T15:30:01.688132+00:00 + 2025-10-11T21:31:26.758172+00:00 2016-09-01T11:29:29+00:00 In a recent discussion on Reddit, Johnson Lau clarified that there is no real attack in the segwit code and explained how a check in the code can prevent potential vulnerabilities. The subject of the thread had a question mark, indicating that clarification was being sought from the community rather than asserting the existence of a vulnerability. The complexity of the segwit code was acknowledged by Sergio Demian Lerner, with key parts of the consensus code spread across source files.Johnson Lau's clarifications were appreciated by the community, and he emphasized that adding witness data to a non-segwit script is invalid according to consensus. He shared a pull request that detects such violations early and bans the peer. Another approach proposed by Lau is to run the scripts of all incoming transactions, which is feasible as the unspent transaction outputs (utxos) have already been fetched, making validation easier.The consensus in the Bitcoin community is that adding witness data to a non-segwit script is considered invalid. This consensus is highlighted in a code snippet on Github's bitcoin repository. A new pull request has been made to detect any violations of this consensus early and ban the peer responsible. Additionally, another suggested approach is to run the scripts of all incoming transactions, taking advantage of the fact that utxos have already been fetched during the validation process.The potential for malicious nodes to modify non-segwit transactions after segwit activation was discussed in a recent thread on Bitcoin Improvement Proposals (BIP). It was suggested that a malicious node could re-format a non-segwit transaction into a segwit transaction with up to 400 Kbytes of segwit witness program data, resulting in both transactions having the same hash. However, due to low fees per byte, such a modified transaction would likely not be properly relayed by the network. An attacker could still modify the original transaction by adding segwit witness program data up to the point of relaying the transaction, successfully preventing it from being mined.Another concern is that an attacker could encode arbitrary data, such as virus signatures or illegal content, into passing non-segwit transactions. One proposed solution is to increase the transaction version to 3 for segwit transactions, ensuring that a non-segwit transaction cannot be converted into a segwit transaction without changing the transaction hash. However, this solution does not address all potential problems, as transactions with a mixture of segwit and non-segwit inputs could still be vulnerable to the same attack, even if they are version 3.To mitigate these issues, a simple check could be added to the IsStandardTX() function to prevent witness programs from having a stack element length greater than the maximum script element size (MAX_SCRIPT_ELEMENT_SIZE). However, a more long-term solution would be to introduce a field for each input or the entire transaction that specifies the maximum size of the witness stack in bytes (maxWitnessSize).Overall, the discussion revolves around the complexities of the segwit code and various approaches to prevent potential attacks or vulnerabilities. It underscores the importance of raising questions and seeking clarification from the community when necessary. The provided links to relevant code and pull requests serve as valuable references for further exploration of the topic. diff --git a/static/bitcoin-dev/Aug_2016/combined_Authentication-BIP.xml b/static/bitcoin-dev/Aug_2016/combined_Authentication-BIP.xml index 08b1dd2263..28bb74ebd5 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Authentication-BIP.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Authentication-BIP.xml @@ -2,7 +2,7 @@ 2 Combined summary - Authentication BIP - 2025-09-26T15:30:12.270644+00:00 + 2025-10-11T21:31:37.404724+00:00 python-feedgen Jonas Schnelli 2016-08-12 12:47:31+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - Authentication BIP - 2025-09-26T15:30:12.270786+00:00 + 2025-10-11T21:31:37.404890+00:00 2016-08-12T12:47:31+00:00 The discussion revolves around the privacy protection of OpenSSH users and the comparison with Bitcoin Core. It is noted that OpenSSH does not prioritize user privacy like Bitcoin Core does. In the discussion, it is suggested that OpenSSH should allow multiple identity-keys per network interface to enhance privacy. The proposal includes using different identity-keys for each network interface. The relevant changes to the proposal can be viewed on GitHub.In the bitcoin-dev mailing list conversation, members discuss whether identity-public-keys should be tied to static IP addresses or if DNS names should be allowed. The purpose of this table is to inform clients which server ID to expect. The design aims to inhibit fingerprinting and prevent tracking unless pubkeys are published. To protect against MITM attacks, the client must know the expected server identity. The idea of allowing wildcard options is raised, but it is clarified that such nodes would not be listed and clients could request authentication without authenticating themselves. The limitation of one identity-key per listening network interface for each node is questioned, suggesting that nodes should be able to have multiple identities at a similar cost to having a large authorized keys list.Andy Schroder expresses mixed feelings about tying identity-public-keys with static IP addresses in a bitcoin-dev post and suggests supporting DNS names in addition to IP addresses. The purpose of the table remains to identify the expected server ID, while also preserving privacy in case of IP address changes. MITM attacks are prevented by ensuring the client knows the server's identity. OpenSSH is mentioned as not prioritizing user privacy like Bitcoin does. The limitation of only one identity-key per listening network interface is questioned, advocating for the ability to have multiple identities with a similar cost to managing a large authorized keys list.Jonas Schnelli raises concerns about the format of known-peers and authorized-peers files, questioning the strict tie between identity-public-keys and network identifiers due to potential spoofing. For individuals running a Bitcoin node with a dynamic IP address, secure connections back to their own node may be desired. A suggestion is made for a compromise between strict checks and wildcard options. It is unclear if different identity-keys can be used for each IPv4 interface, and one solution proposed is running two instances of bitcoind and pairing them over a local network. The disadvantage mentioned is the potential slowness when dealing with a large authorized-peers database.Jonas Schnelli proposes an authentication scheme to detect and reject MITM attacks in conjunction with BIP151. This requires building trusted connections, and the authentication process uses ECDSA without transmitting secrets. The identity-public-keys used for authentication must be shared over a different channel. Each peer supporting p2p authentication must maintain an editable "database" for authentication state until the encryption/connection terminates. Only one authentication process is allowed per connection. Peers should display/log the identity-public-key as an identity-address to users, encoded as a base58-check ripemd160(sha256) hash. diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-151.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-151.xml index 1b8ca13695..4d9fd10fdf 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-151.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-151.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 151 - 2025-09-26T15:30:03.811236+00:00 + 2025-10-11T21:31:28.882320+00:00 python-feedgen Pieter Wuille 2016-08-31 14:29:53+00:00 @@ -169,10 +169,11 @@ + 2 Combined summary - BIP 151 - 2025-09-26T15:30:03.811470+00:00 + 2025-10-11T21:31:28.882599+00:00 2016-08-31T14:29:53+00:00 In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Addresses-over-Audio.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Addresses-over-Audio.xml index d817557d76..47284e7379 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Addresses-over-Audio.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Addresses-over-Audio.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Number Request: Addresses over Audio - 2025-09-26T15:29:48.992790+00:00 + 2025-10-11T21:31:14.007502+00:00 python-feedgen Daniel Hoffman 2016-08-13 04:41:32+00:00 @@ -117,10 +117,11 @@ + 2 Combined summary - BIP Number Request: Addresses over Audio - 2025-09-26T15:29:48.993008+00:00 + 2025-10-11T21:31:14.007725+00:00 2016-08-13T04:41:32+00:00 A proposal has been put forth to create a Bitcoin Improvement Proposal (BIP) for the transmission of Bitcoin addresses over audio. This would involve encoding the binary representation of a Bitcoin address into an audible tone, allowing for easy transmission of the address. The proposal suggests including error correction mechanisms, but concerns have been raised about the efficiency of repeating the message multiple times for error recovery. As alternatives, trellis modulation or other convolutional codes have been suggested.To guide the development of this proposal, it has been recommended to study existing implementations of audio modems and consider selecting frequencies that are harmonics of each other to complicate detection due to nonlinear distortion. The Bell 202 and similar modem standards chose AFSK frequencies to minimize interference. Additionally, it has been proposed to define channel models to simulate different use cases and evaluate if the requirements have been met.Daniel Hoffman has made updates to a GitHub repository related to this proposal, providing changes and samples of both tone tables. However, a decoder is still needed to fully evaluate the viability of the proposal. Although some individuals on Reddit have expressed interest in conducting decoding experiments, the lack of a decoder means that it remains an idea rather than a formal proposal.Developing a decoder for noisy or distorted channels is expected to be the most complex part of the project and will heavily influence the design of the encoder. To assess its viability, Daniel needs to complete the entire system. Further research and experimentation are anticipated in this area.Another aspect of the proposal involves creating a standardized method for representing Bitcoin addresses over audio. The proposed protocol suggests chopping up the binary representation of the address into 4 or 2-bit chunks, depending on the quality of the audio, and generating tones based on these values. The intention is to make it easy for consumers to donate Bitcoins to podcasts they listen to. Some suggestions have been made to add additional tones to denote amounts in satoshis. However, there are considerations regarding making the signal detectable and easy to decode, while also ensuring it is pleasant to listen to and does not interfere with speech frequencies.The full specification of the BIP can be found on the proposer's GitHub page. Further research and experimentation are expected to be conducted in this area to fully evaluate the proposed method of representing Bitcoin addresses over audio. diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Open-Asset.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Open-Asset.xml index 7376e784d3..0760a102c3 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Open-Asset.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-Number-Request-Open-Asset.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Number Request: Open Asset - 2025-09-26T15:30:10.157715+00:00 + 2025-10-11T21:31:35.281912+00:00 python-feedgen Nicolas Dorier 2016-08-13 02:25:04+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - BIP Number Request: Open Asset - 2025-09-26T15:30:10.157898+00:00 + 2025-10-11T21:31:35.282055+00:00 2016-08-13T02:25:04+00:00 The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-Status-updates-including-to-Active-Final-Status-BIP-39-BIP-43-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-Status-updates-including-to-Active-Final-Status-BIP-39-BIP-43-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml index 2d964885f5..fe03d62ae3 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-Status-updates-including-to-Active-Final-Status-BIP-39-BIP-43-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-Status-updates-including-to-Active-Final-Status-BIP-39-BIP-43-BIP-44-BIP-67-BIP-111-BIP-125-BIP-130.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130 - 2025-09-26T15:29:53.218880+00:00 + 2025-10-11T21:31:18.261558+00:00 python-feedgen Pieter Wuille 2016-08-25 09:02:27+00:00 @@ -65,10 +65,11 @@ + 2 Combined summary - BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130 - 2025-09-26T15:29:53.219073+00:00 + 2025-10-11T21:31:18.261777+00:00 2016-08-25T09:02:27+00:00 The discussion on the bitcoin-dev mailing list revolves around the consideration of whether certain Bitcoin Improvement Proposals (BIPs) should be treated as final or not. BIP44, which is widely used by many wallets without any real-world issues, is suggested to be set as final despite its imperfections. Jonas Schnelli initially expresses disagreement with the development paradigm of "maybe detect funds," but later clarifies his statement. The discussion also raises concerns about the gap limits in BIP44 and the potential issues it may cause for merchants who generate multiple addresses. There is a conversation thread discussing the sequential scanning of blockchain transactions and a hypothetical scenario where a user generates 21 addresses, with only one receiving funds immediately and another receiving funds after 180 days. This scenario triggers a resize+20 of the address-lookup-window, but the wallet would need to go back 180 days to detect the transaction on the second address. The discussion ends with a question about whether there is a misunderstanding in this hypothetical scenario.Andreas Schildbach discusses the BIP44 protocol and its lack of encoding a seed birthday necessary for SPV wallets to scan from the beginning of the blockchain. However, some wallets still interoperate on this standard. The status of the protocol depends on its usage rather than its quality. Additionally, BIP43 is suggested to be made final as it only advises other BIPs on how they could do things.Jonas Schnelli raises a concern about the BIP44 Gap Limits, stating that if 20 unused addresses are found in a row, the software stops searching for used addresses beyond that point. The discussion clarifies that this does not require a transaction rescan back to the genesis block every 20 addresses and suggests starting scanning sequentially from the genesis block or a block around the time when BIP44 was written.The discussion highlights potential misdesigns in BIP39 seed phrases and BIP44 gap limits for Bitcoin wallets. The absence of a version number in BIP39 seed phrases raises questions about deriving addresses from an old seed phrase when new derivation methods are used. The BIP44 gap limit, currently set at 20, is also questioned regarding whether it requires a transaction rescan back to the genesis block every 20 addresses or if wallet recovery after BIP44's implementation is necessary for full access to a blockchain indexed by addresses. Overall, the discussion reflects concern for potential issues and limitations in the current design of Bitcoin wallets.Luke Dashjr criticizes the design of BIP39 and BIP44, stating that they are poorly designed. He mentions several reasons, including limited support in Electrum and the complexity of multiple accounts breaking the property of using the same wallet instance on different devices. He also points out inconsistencies and potential problems with BIP39 seed phrases not having a version number. He suggests separating BIP43 from BIP44 to allow for the development of a better standard.Kenneth Heutmaker raises concerns about broken Simplified Payment Verification (SPV) wallets that lack bloom filtering detection. SPV wallets connect only to nodes that support bloom filtering, and if they don't get updates, the wallet becomes outdated, causing panic among users who end up rescanning the blockchain and losing their transaction history. The discussion highlights the need for robustness against abusive peers and the challenges in achieving this due to the design of bloom filtering.BIP 111, also known as NODE_BLOOM service bit, has been implemented in Bitcoin Core and derivatives, but it is unclear if clients are using it. Multibit plans to add detection of the NODE_BLOOM bit, and SPV wallets are advised to update to respect NODE_BLOOM. The discussion emphasizes the importance of detecting the NODE_BLOOM bit to avoid issues with outdated SPV wallets and recommends the use of the new DNS seeder filter option.Luke proposes updating several BIPs to Final Status if no objections are raised, including BIP 39, 44, 67, 125, and 130. He also suggests upgrading the status of BIP 43 to Active as it guides the creation of new BIPs. Developers of Bitcoin clients are requested to comment on their software's support for BIP 111 (NODE_BLOOM service bit) and their intention to support it in the future. If any clients are already using this service bit, BIP 111 will be updated to Final Status in two weeks. diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-clearing-house-addresses.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-clearing-house-addresses.xml index 2211e58645..9f377a197b 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-clearing-house-addresses.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-clearing-house-addresses.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP clearing house addresses - 2025-09-26T15:29:55.332272+00:00 + 2025-10-11T21:31:20.386851+00:00 python-feedgen Tier Nolan 2016-08-08 11:01:57+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - BIP clearing house addresses - 2025-09-26T15:29:55.332422+00:00 + 2025-10-11T21:31:20.387037+00:00 2016-08-08T11:01:57+00:00 There is a discussion about the possibility of doing instant trades between altcoins using channels and the exchange as a hub. However, this doesn't work with fiat accounts. To eliminate counter-party risk, a "100% reserve" company could issue fiat tokens that the exchange could trade. This would ensure that investors still have their altcoins and fiat tokens even if the exchange goes down. However, there is still a risk that the token company could go bankrupt. This risk could be mitigated by requiring verified accounts to cash out tokens. The company could set up a blockchain where it signs blocks instead of mining, earning transaction fees and minting fees.Matthew Roberts discusses the usage of centralized exchanges for speculative purposes. Many users do not care about decentralization or security, but use these exchanges to enter and exit complex positions quickly. Centralized exchanges also allow for limit orders, which cannot be executed with channels. However, using channels alongside a centralized exchange can provide the benefits of a distributed exchange. Channels allow for instant funding while giving customers control over their funds. Margin account holders appreciate knowing which funds are under their control versus those held by the exchange.Centralized exchanges play an important role in the Bitcoin ecosystem by allowing efficient price discovery and improving liquidity. Decentralized exchanges may offer greater security, but they are not as efficient for speculators who need to enter and exit complex positions quickly. Erik Aronesty suggests using lightning networks for margin trading to avoid centralization. He proposes a P2P order routing system with market makers running nodes to facilitate routing and execute channel trades instantly.The conversation also touches on the topic of protecting coins in hot wallets from theft. One proposed solution is using output scripts that only allow coins to be sent to a new transaction whose output script is redeemable after several confirmations. This approach could benefit crucial services such as wallets, gambling websites, e-commerce websites, and exchange hot/cold wallets. Managing private keys is also discussed as a way to mitigate risks associated with key management. Keeping some keys offline is an important part of managing risk.The recent hack on Bitcoin has sparked discussions about creating a new address type with a reversal key and settlement layer to revoke transactions. However, this proposal conflicts with Bitcoin's design, which makes transaction reversals impossible. There are also concerns about security and the acceptance of payments from "vaults" by merchants. The author argues that hacks and losses are often due to wrong implementations or poor security practices, rather than flaws in Bitcoin's design.On the Bitcoin-dev mailing list, Matthew Roberts proposed the idea of creating a new address type with a reversal key and settlement layer to revoke transactions. However, it was pointed out that transactions are not sent from addresses, and nLockTime can be used to prevent unauthorized transactions. The discussion explores different ideas for preventing hacks and improving security, including the use of offline keys as firebreaks and the implementation of an "instant" system to prevent double spending.A proposal has been made on the bitcoin-dev mailing list to address the recent hack by creating a new address type with a reversal key and settlement layer. This would provide users with key revocation in case of a breach, as there is currently no defined process to roll back unexpected behavior in computer systems. The proposed address type would require transactions to receive N confirmations before they can't be revoked, and after that, the transaction would be "settled" and coins would become redeemable from their destination output.One of the main advantages of this proposal is that it would improve centralized exchange security by making it impossible for a hot wallet to be raided all at once. Currently, OP codes and TX types are not suitable for a secure clearing mechanism. Existing options such as Nlocktimed TXs and OP_CHECKLOCKTIMEVERIFY have limitations. The proposed settlement phase would also allow for transparent fraud prevention and auditing, as transaction progress would be publicly visible.The proposal builds upon existing background material, including a time-based clearing house proposal by Hacking Distributed and a similar idea for secure wallet design implemented using time-locked ECDSA keys by Matthew Roberts. These related ideas contribute to the development of a more robust and secure system for handling transactions.However, some members of the community argue that the proposed time-based clearing house using blockchains directly is a much better idea than the current proposal. They believe that this approach would offer greater security and efficiency when dealing with reversals and settlements.In conclusion, the discussion around creating a new address type with a reversal key and settlement layer aims to address the recent hack and provide users with key revocation in case of breaches. The proposed system would require transactions to receive N confirmations before becoming irreversible, and a settlement phase would allow for transparent fraud prevention and auditing. While the proposal builds upon existing background material and offers improvements to centralized exchange security, there are alternative ideas, such as a time-based clearing house using blockchains directly, that some members of the community consider to be a better solution. diff --git a/static/bitcoin-dev/Aug_2016/combined_BIP-draft-HTLC-transactions.xml b/static/bitcoin-dev/Aug_2016/combined_BIP-draft-HTLC-transactions.xml index 00b983a976..97443caef5 100644 --- a/static/bitcoin-dev/Aug_2016/combined_BIP-draft-HTLC-transactions.xml +++ b/static/bitcoin-dev/Aug_2016/combined_BIP-draft-HTLC-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP draft: HTLC transactions - 2025-09-26T15:30:16.500040+00:00 + 2025-10-11T21:31:41.651775+00:00 python-feedgen Johnson Lau 2016-08-17 10:00:37+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - BIP draft: HTLC transactions - 2025-09-26T15:30:16.500196+00:00 + 2025-10-11T21:31:41.651942+00:00 2016-08-17T10:00:37+00:00 On July 20, 2016, a discussion took place on the bitcoin-dev mailing list regarding Hash Time-Locked Contract (HTLC) transactions in Bitcoin. Sean Bowe requested feedback on these transactions which allow payment for the preimage of a hash, with CSV/CLTV used to recover funds if the other party is uncooperative. Luke Dashjr proposed using OP_SIZE to address the malleability issue caused by hashing the top item on the stack, and Peter Todd praised this idea.The HTLC scripts have a specific structure, starting with [HASHOP] OP_EQUAL followed by an OP_IF and an OP_ELSE, with a [TIMEOUTOP] OP_DROP in between. The script concludes with an OP_CHECKSIG. However, this design makes the scripts malleable as the top stack item can be modified without invalidating the scriptSig. Todd suggests using the OP_SIZE opcode to make it more difficult for attackers to manipulate transactions. This additional requirement involves adding OP_SIZE OP_2 OP_PICK OP_HASH160 [PUBKEYHASH] OP_EQUALVERIFY to the script.Todd also emphasizes the importance of considering different scenarios, such as malicious parties attempting double-spend attacks. The discussion delves into the vulnerabilities of HTLC transactions and provides suggestions for enhancing their security.In addition to the discussion, Sean Bowe shares his draft BIP for HTLC transactions on GitHub. Members of the community express interest in submitting a BIP to support these transactions in wallets with modifications to Bitcoin Core. An implementation of Bowe's draft BIP is currently under development. The HTLC scripts are seen as valuable for applications like the Lightning network and zero-knowledge contingent payments, as demonstrated by the author's 'pay-to-sudoku' ZKCP demo earlier in the year, which utilized the same script implemented with CLTV and SHA256. diff --git a/static/bitcoin-dev/Aug_2016/combined_Capital-Efficient-Honeypots-w-Scorched-Earth-Doublespending-Protection.xml b/static/bitcoin-dev/Aug_2016/combined_Capital-Efficient-Honeypots-w-Scorched-Earth-Doublespending-Protection.xml index 2d26fa49f6..ba81c2dbfb 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Capital-Efficient-Honeypots-w-Scorched-Earth-Doublespending-Protection.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Capital-Efficient-Honeypots-w-Scorched-Earth-Doublespending-Protection.xml @@ -2,7 +2,7 @@ 2 Combined summary - Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection - 2025-09-26T15:29:59.554648+00:00 + 2025-10-11T21:31:24.633548+00:00 python-feedgen Peter Todd 2016-08-31 20:01:14+00:00 @@ -65,10 +65,11 @@ + 2 Combined summary - Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection - 2025-09-26T15:29:59.554815+00:00 + 2025-10-11T21:31:24.633737+00:00 2016-08-31T20:01:14+00:00 In the context of the Bitcoin blockchain, securing multiple servers can be challenging. One solution is to use one private key per server, but this can be costly when there are many servers to protect. Previous proposals for using tree signatures as honeypots have not been implemented in the Bitcoin protocol. However, a viable option is to use a 2-of-2 multisig and the SIGHASH_SINGLE feature.To implement this approach, a honeypot secret key is shared among all N servers, while a discriminator secret key is kept secret. Each server creates a unique signature with SIGHASH_SINGLE, paying a token amount to a notification address. Additionally, a pre-signed signature created with the discriminator secret key is left on the associated server along with the honeypot secret key.However, using non-standard SIGHASH flags may flag the transactions involved in risk analysis at exchanges and other platforms, which could threaten the fungibility of the reward. To address this, a suggestion is made to use a pre-signed standard transaction instead. This transaction spends the honeypot output to two addresses: a per-server canary address and a change address. Importantly, the private key associated with the change address is left on the server, giving the intruder the ability to spend the change output and claim their reward.A refinement to this concept involves the use of opt-in RBF flags and CPFP-aware transaction replacement. This allows the honeypot owner to potentially recover the honeypot while still learning about the intrusion. In cases where there are attempts at double-spending, the "scorched earth" concept can be employed. A second version of the honeypot pre-signed transaction would spend the entirety of the honeypot output to fees, making it costly for the honeypot owner to double-spend. By publishing this "scorched earth" transaction, the honeypot owner's honesty is encouraged, and CPFP-aware transaction replacement becomes irrelevant.It should be noted that the complexity of these methods may discourage intruders from targeting honeypots altogether. However, the use of Bitcoin-based honeypots provides an incentive for hackers to reveal their presence and activity, ultimately enhancing security measures.Overall, by utilizing a 2-of-2 multisig and the SIGHASH_SINGLE feature, along with additional measures such as opt-in RBF flags and CPFP-aware transaction replacement, the security of multiple servers on the Bitcoin blockchain can be enhanced, providing a more efficient and effective means of protection against intrusion. Additionally, the implementation of CHECKSEQUENCEVERIFY can further ensure that the honeypot output can only be spent if transaction replacement is enabled. diff --git a/static/bitcoin-dev/Aug_2016/combined_Fees-and-Accounts.xml b/static/bitcoin-dev/Aug_2016/combined_Fees-and-Accounts.xml index a6f199d7b7..b0c0f8c6b5 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Fees-and-Accounts.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Fees-and-Accounts.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fees and Accounts - 2025-09-26T15:29:57.444434+00:00 + 2025-10-11T21:31:22.510168+00:00 python-feedgen James MacWhyte 2016-08-04 00:59:11+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Fees and Accounts - 2025-09-26T15:29:57.444612+00:00 + 2025-10-11T21:31:22.510373+00:00 2016-08-04T00:59:11+00:00 In a message posted to the bitcoin-dev mailing list, it is highlighted that many people rely on their own separate account systems and use bitcoind primarily for sending, receiving, and verifying transactions. However, it is noted that bitcoind is not intended to be a comprehensive solution for running an entire bitcoin deposit and withdrawal system; it simply provides the necessary tools for building such a system. For those in need of a pre-built solution, companies like BitGo offer platforms that can fulfill this role.The message also raises concerns about the deprecation of accounts in bitcoind. The poster explains that if they have accounts, they must ensure that account holders do not overcharge their accounts. One potential solution suggested is to use "createrawtransaction() + fundrawtransaction() + signrawtransaction()" to guarantee that the transaction can be paid by an account. However, with accounts being deprecated and no sendrawtransactionfrom() method available, the poster faces the dilemma of either constructing their own account system or presuming that the account code will not be untangled and hacking bitcoind to incorporate a sendfrom function with a fixed fee parameter that overrides the size multiplication.The absence of an integrated account system in bitcoind is deemed problematic as it hinders the effective tracking of all incoming funds to all addresses. Without accounts, bitcoind essentially functions as a person-to-person manual client, making it challenging to establish many-to-many automatic organizations on top of the platform. The poster asserts that there are likely numerous developers facing similar predicaments and warns that deprecating accounts without offering a viable alternative could discourage further bitcoin-related development.The writer identifies two key issues with bitcoind that render it unsuitable for many projects. Firstly, if accounts are present, it becomes crucial to prevent account holders from overcharging their accounts. The suggested workaround involves using "createrawtransaction() + fundrawtransaction() + signrawtransaction()" and ensuring that the transaction can be paid by an account. However, since accounts are deprecated and there is no sendrawtransactionfrom() method, the writer must either develop their own account system or hope that they can successfully modify bitcoind to include a sendfrom function with a fixed fee parameter. Secondly, without accounts, bitcoind is limited to being a person-to-person manual client, making it impossible to construct many-to-many automatic organizations on top of the platform. The writer argues against deprecating accounts as it severely restricts the usability of bitcoind for various projects. They even disclose that they ceased development related to bitcoin after encountering difficulties with transactions requiring fees and the platform's inability to handle such fees within accounts.In conclusion, the writer hopes that developers understand their concerns are genuine rather than mere trolling. They emphasize that without accounts, building many-to-many automatic organizations becomes arduous, necessitating predictable fees. While acknowledging privacy issues with using accounts for off-chain microtransactions, the writer asserts that it currently remains the most viable option. diff --git a/static/bitcoin-dev/Aug_2016/combined_Fwd-Hiding-entire-content-of-on-chain-transactions.xml b/static/bitcoin-dev/Aug_2016/combined_Fwd-Hiding-entire-content-of-on-chain-transactions.xml index dc4e949839..da3885d070 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Fwd-Hiding-entire-content-of-on-chain-transactions.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Fwd-Hiding-entire-content-of-on-chain-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fwd: Hiding entire content of on-chain transactions - 2025-09-26T15:29:42.653035+00:00 + 2025-10-11T21:31:07.637860+00:00 python-feedgen Tony Churyumoff 2016-08-10 07:53:01+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Fwd: Hiding entire content of on-chain transactions - 2025-09-26T15:29:42.653196+00:00 + 2025-10-11T21:31:07.638031+00:00 2016-08-10T07:53:01+00:00 In a 2016 email thread, James MacWhyte discusses the potential need for verification by miners to protect against duplicate spends. He mentions a scenario where Alice sends Bob a transaction and Timothy broadcasts a transaction with a random hash that references the same output. Miners are unable to verify if this is valid, resulting in Bob's money becoming useless. MacWhyte explains that a duplicate spend proof must be signed by the same user (Alice) to be considered a double spend.A new proposal has been put forward to hide the entire content of bitcoin transactions. This goes beyond previous privacy measures such as CoinJoin, ring signatures, and Confidential Transactions. The idea is to publish only the hash of inputs and outputs in the blockchain as OP_RETURN, while hiding the entire inputs and outputs. To prevent double-spends, the payer must also publish another hash known as the spend proof, which is the hash of the output being spent. The proposal suggests using a new private coin called Black Bitcoin or BBC, which can be obtained by burning regular BTC. Private transactions would require one input, one previous output, and every output would include a blinding factor.The proposal acknowledges that larger outputs may need to be split into smaller ones, and more inputs may need to be combined when sending large amounts. This could potentially cause privacy leakage, but it can be avoided by using multiple addresses and storing smaller amounts on each address. Exchanges and large merchants may accumulate large coin histories, which should be kept in mind.No hard or soft fork is required for the proposed privacy-preserving currency, BBC. It operates on top of the bitcoin blockchain using the same private keys and addresses as BTC. Each BBC transaction must be enclosed in a small BTC transaction that stores the OP_RETURNs and pays for the fees. The proposal lacks encryption, so true privacy can only be achieved when using bitcoin over Tor.In a discussion on bitcoin transaction design, concerns were raised about the proposed design of hiding entire inputs and outputs. James MacWhyte pointed out that users would need to back up entire histories of every output sent to them, rather than just backing up a single private key. Additionally, being online to receive payments could pose challenges in sending the private message containing the coin's history. Tony Churyumoff suggested using hubs to route end-to-end encrypted messages to address these concerns.Peter Todd responded to a proposal made by James MacWhyte, stating that while verifying transactions is important, preventing double-spending is a fundamental requirement of Bitcoin. He mentioned his own proposal from 2016, which focused on closed seal sets and truth lists for privacy without sacrificing the ability to prevent double-spending. diff --git a/static/bitcoin-dev/Aug_2016/combined_General-bitcoin-users-mailing-list-.xml b/static/bitcoin-dev/Aug_2016/combined_General-bitcoin-users-mailing-list-.xml index ab1bb78f28..b2753fdaa0 100644 --- a/static/bitcoin-dev/Aug_2016/combined_General-bitcoin-users-mailing-list-.xml +++ b/static/bitcoin-dev/Aug_2016/combined_General-bitcoin-users-mailing-list-.xml @@ -2,7 +2,7 @@ 2 Combined summary - General bitcoin users mailing list? - 2025-09-26T15:30:08.045052+00:00 + 2025-10-11T21:31:33.159076+00:00 python-feedgen Luke Dashjr 2016-08-14 04:22:40+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - General bitcoin users mailing list? - 2025-09-26T15:30:08.045184+00:00 + 2025-10-11T21:31:33.159247+00:00 2016-08-14T04:22:40+00:00 On August 14th, 2016, a user named Cannon sent a message to the bitcoin-dev mailing list inquiring about the existence of a mailing list specifically for general users of Bitcoin. The bitcoin-dev mailing list is primarily focused on development-related topics and Cannon was looking for a forum for non-development questions related to Bitcoin. In response to Cannon's inquiry, a link was provided leading to the bitcoin-discuss mailing list, which is intended for general discussion about Bitcoin and related technologies. This mailing list is open to anyone who wants to participate and discuss various aspects of Bitcoin that may not be directly related to development.In another email sent to the bitcoin-dev mailing list on August 13, 2016, Cannon sought information about a general users mailing list for bitcoin-related topics that do not necessarily involve development. The bitcoin-dev mailing list is specifically designed for development-related discussions, so Cannon was searching for a platform for more general conversations. In this email, Cannon included their contact information, including a PGP fingerprint, Bitmessage address, and Ricochet-IM.As a response to Cannon's inquiry, other users suggested exploring the /r/btc and /r/Bitcoin subreddits on Reddit as potential forums for more general discussions about Bitcoin.To summarize, the author of the communication posed a question regarding the existence of a mailing list for general users of Bitcoin, separate from the development-focused bitcoin-dev mailing list. They provided their contact information and were directed towards the bitcoin-discuss mailing list as well as the /r/btc and /r/Bitcoin subreddits on Reddit for broader discussions about Bitcoin. diff --git a/static/bitcoin-dev/Aug_2016/combined_Hardware-Wallet-Standard.xml b/static/bitcoin-dev/Aug_2016/combined_Hardware-Wallet-Standard.xml index 2d0048ca69..aa59010a65 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Hardware-Wallet-Standard.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Hardware-Wallet-Standard.xml @@ -2,7 +2,7 @@ 2 Combined summary - Hardware Wallet Standard - 2025-09-26T15:30:18.618203+00:00 + 2025-10-11T21:31:43.775561+00:00 python-feedgen Corey Haddad 2016-08-28 23:14:03+00:00 @@ -109,10 +109,11 @@ + 2 Combined summary - Hardware Wallet Standard - 2025-09-26T15:30:18.618389+00:00 + 2025-10-11T21:31:43.775786+00:00 2016-08-28T23:14:03+00:00 The discussion surrounding hardware wallets and their integration into Bitcoin Core revolves around several key points. One concern is the possibility of a "cosmic ray" flipping a bit during address generation, leading to lost funds. To mitigate this risk, some users generate addresses on two independent machines using different software. However, a proposed solution suggests that both a detached signer and a normal wallet should verify the correctness of generated addresses before coins are sent there. This would offer protection against losing money due to a defective hardware wallet.There is also a debate about the usefulness of a signing protocol, with some arguing that it is only valuable for hardware wallets. However, others believe that any website wanting to request public keys/signatures from users would find this protocol beneficial. The focus should not only be on servicing hardware but also on allowing users to choose their own ECDSA implementation, whether it be hardware or software.One participant in the discussion expresses concerns about defining rigid standards for hardware wallet development and integration. They argue that the TREZOR concept of a device as a server and primary source of workflow management goes against the proposal of wallet software as a workflow manager. Another member of the discussion agrees with this sentiment, stating that driving any hardware wallet from the wallet itself or from a third-party daemon implementing a URL scheme would provide better device interoperability and easier maintenance and update paths for wallets.The concept of building a standard on top of the URI protocol is seen as a limitation by some. Instead, it is suggested that high-level APIs be used to implement hardware-specific protocols and transports as plugins. This approach would make life easier for app developers without defining artificial "standards." Additionally, there are discussions about the use of smartcards in hardware wallets and the potential risks associated with blindly signing transactions. Suggestions are made to use hardware security modules (HSMs) instead of smartcards and to utilize out-of-band communication channels for validating business logic.Other topics of discussion include the use of the stdio/pipe approach versus the URI scheme for hardware wallets, the need for a clear interface between wallet and signing device, and the possibility of defining a standard on the hardware interaction layer. Finally, there is debate about the feasibility of ECC-enabled smart-cards signing Bitcoin transactions and the suggestion to add custom logic for validation to these cards.Overall, the discussions highlight the importance of security, interoperability, and ease of use when it comes to integrating hardware wallets into Bitcoin Core. The proposals and debates aim to provide improved security measures and a better user experience for Bitcoin Core users.In a Bitcoin development discussion, Thomas proposes a protocol for offline signing of transactions initiated on merchant websites. He suggests that the procedure is similar to multi-signature addresses but emphasizes the need for requesting an xpub/public key. He also mentions the importance of redeemScript and witnessScript for full validation and signing of transaction inputs. Thomas believes that his proposal allows users to provide their own xpub and leverage services provided by GreenAddress without relying on their signing code.Jochen responds to Jonas' draft and suggests that a wallet needs to connect with a hardware wallet to learn the xpubs controlled by the hardware. He highlights missing points in the specification, including the amount spent by each input and checks required for multisig change addresses. Jochen also finds the specification ambiguous for P2SH transactions and proposes a solution to clarify the inputscript.A user asks why a normal smart-card with ECC encryption cannot be used for the hardware signing component of a wallet app. Peter Todd responds, stating that ECC-enabled smart cards cannot sign the specific curve used by Bitcoin and generally only support higher-level protocols. He also mentions the security risks and blind signing associated with smart cards.Bitcoin developers discuss standardizing the hardware protocol to improve user experience. Some hardware wallets have already implemented Trezor's interface. The existing URI scheme allows disambiguation by manufacturer but lacks a way to enumerate available manufacturers or enabled wallets. The specification could have two layers - raw messages and transport mechanism. Luke-Jr argues for standardization to eliminate the need for plugin installation.Jonas receives feedback from Jochen on the draft for detached signing. Jochen suggests connecting with a hardware wallet to learn xpubs and provides additional points missing from the specification. He also proposes a solution for ambiguous inputscript in P2SH transactions.Jonas and Pavol Rusnak discuss the need for a better way to validate input amounts in Bitcoin transactions. They agree on creating a standard for new forms of transactions like SegWit and Lightning. The lack of a standard for hardware wallet interfaces has led to proprietary code additions by wallet vendors.Pavol Rusnak expresses his opinion that standardizing extended validation of inputs for current Bitcoin transactions is not sensible due to complexity. However, he suggests considering it for SegWit and Lightning transactions. He mentions TREZOR's extended validation of inputs and believes making the standard unnecessarily complicated is not worth it.The lack of a standard for desktop and mobile wallets to interact with hardware diff --git a/static/bitcoin-dev/Aug_2016/combined_Hiding-entire-content-of-on-chain-transactions.xml b/static/bitcoin-dev/Aug_2016/combined_Hiding-entire-content-of-on-chain-transactions.xml index f67cf51543..2ec3c1f86c 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Hiding-entire-content-of-on-chain-transactions.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Hiding-entire-content-of-on-chain-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - Hiding entire content of on-chain transactions - 2025-09-26T15:30:05.931123+00:00 + 2025-10-11T21:31:31.022740+00:00 python-feedgen Tony Churyumoff 2016-08-10 08:37:37+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Hiding entire content of on-chain transactions - 2025-09-26T15:30:05.931269+00:00 + 2025-10-11T21:31:31.022935+00:00 2016-08-10T08:37:37+00:00 A proposed design has been suggested to enhance the privacy of Bitcoin transactions. Unlike current methods such as CoinJoin, ring signatures, and Confidential Transactions, this proposal aims to hide the entire inputs and outputs by only publishing their hashes on the blockchain. The plaintext of inputs and outputs would be sent directly to the recipient via a private message.The main concept behind this design is to ensure that the entire inputs and outputs remain hidden while only their hashes are visible on the blockchain. To prevent double-spending, the payer also needs to publish another hash representing the output being spent. Each private payment must include a blinding factor for every output.To track the ownership of the private coin, each new owner must store its complete history. When spending the coin, the user forwards the entire history to the next owner and extends it with their own transaction. Merging coins is prohibited, but splitting them is allowed. However, to avoid excessive fragmentation, private coins must be issued in specific denominations.To issue the new private coins, regular BTC can be burned by sending it to unspendable bitcoin addresses assigned to each denomination. This burning process entitles the user to receive an equal amount of the new private coin, referred to as "black bitcoins" (BBC).After user A sends a private payment to user B, user A will know when the coin is spent by B through the spend proof. However, A will not have any knowledge about the new owner or subsequent movements of the coin. There may be concerns regarding larger outputs being split into smaller ones, potentially causing exchanges and large merchants to accumulate significant coin histories. However, using multiple addresses and storing small amounts on each address can help avoid privacy leakage.Overall, this proposed design offers increased privacy for Bitcoin transactions without requiring a hard or soft fork. It utilizes the same private keys and addresses for both BBC and the base currency BTC, allowing for seamless integration into the existing blockchain infrastructure. The author of the proposal is seeking feedback from the community but has not received any so far. The discussion continues on the bitcoin-dev mailing list, where contact information for Dr. Fabian Kopp, a member of the Institute of Distributed Systems at Ulm University in Germany, can be found. diff --git a/static/bitcoin-dev/Aug_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml b/static/bitcoin-dev/Aug_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml index 7e5b477d0e..20bfa6efe0 100644 --- a/static/bitcoin-dev/Aug_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml +++ b/static/bitcoin-dev/Aug_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml @@ -2,7 +2,7 @@ 2 Combined summary - New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH - 2025-09-26T15:30:14.384371+00:00 + 2025-10-11T21:31:39.528305+00:00 python-feedgen Russell O'Connor 2016-09-05 14:55:10+00:00 @@ -89,10 +89,11 @@ + 2 Combined summary - New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH - 2025-09-26T15:30:14.384598+00:00 + 2025-10-11T21:31:39.528558+00:00 2016-09-05T14:55:10+00:00 Suppose we have a marginal fee rate of 50 satoshis per byte. Reducing the size of the witness data by 1 byte is equivalent to a replace by fee that increases the fee by 50 satoshis. In both cases, miners get an extra potential of 50 satoshis in revenue. Replacing witness data with smaller witness data can pay for its own relay cost as much as RBF can, simply by requiring that the smaller witness be small enough to cover the same RBF threshold. BIP125 and mempool eviction both require the replacing transaction to have a higher fee, to compensate for the cost of relaying the replaced transaction(s).Johnson Lau, a member of the bitcoin-dev community, has proposed a restriction for segwit OP_IF argument as a policy. He is seeking more feedback from users of OP_IF to ACK or NACK his proposal. It is expected that Lightning network would use OP_IF frequently. Rusty, another member of the community, mentions that his current scripts use OP_IF and OP_NOTIF only after OP_EQUAL, except for one place where they use OP_EQUAL...OP_EQUAL...OP_ADD OP_IF. However, he notes that there will be no effect on the c-lightning implementation either way.The Bitcoin script validity rules are proposed to change in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts. This would result in the argument for OP_IF and OP_NOTIF being exactly an empty vector or 0x01, or the script evaluation fails immediately. The policy has received a few concept ACKs. A BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts. The proposed changes affect the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts. This is a softfork on top of BIP141. It is enforced as a relay policy by the reference client since the first release of BIP141. Users must not create P2WSH scripts that are incompatible with this BIP to avoid risks of fund loss.In a bitcoin-dev email, Sergio Demian Lerner raised concerns about transactions sent to IoT devices, which may be rejected if their witness program is too large for the device's implementation-imposed limit. This can result in the loss of bitcoins as the private key is stored on the device, rendering it unable to accept the cloned transaction. Lerner suggests invalidating transactions with a higher witness size than expected by the sender. The design of segwit means that resource constrained devices don't need to receive witness data to verify lite-client merkle-path proofs, which are useless for lite-clients anyway.In a discussion on the bitcoin-dev mailing list, Sergio Demian Lerner suggested that the real problem with witness data size is that it is not signed. However, Gregory Maxwell pointed out that this is not possible for the general case as you may not know the witness size in advance. Maxwell believes fees are not the problem, but rather the fact that the maximum witness size may be changed by a miner which could cause issues for devices like IoT or side-chains that have certain restrictions on transaction sizes they can accept. He proposes that if the witness size is higher than the expected size by the sender, the transaction becomes invalid.The issue at hand is that witness data size is not signed, leading to potential malleability issues and problems for systems with hard limits on the size of witness programs they can accept. A proposed solution is to soft-fork and add an opcode OP_PROGSIZE that pushes the size of the segwit program being evaluated onto the stack, which would allow scripts to take action based on the size. This would prevent an attacker from creating a clone of a transaction with a witness ECDSA signature longer than 0x50 bytes. The discussion also touches on workarounds for current behavior and the need to enforce MINIMALIF in some cases, with the suggestion to make it a relay policy first before considering a softfork.On August 17, 2016, Luke Dashjr and Johnson Lau discussed a workaround for the issue of malleability in Bitcoin transactions. The suggested code to replicate the original behavior was deemed ugly by Dashjr, who argued that it was unnecessary in most real-world use cases. He proposed simplifying the code by replacing "OP_SIZE OP_IF" with "OP_SIZE OP_0NOTEQUAL OP_IF", as OP_SIZE must return a valid MINIMALDATA number. However, Lau noted that diff --git a/static/bitcoin-dev/Aug_2016/combined_New-BIP-Low-S-values-signatures.xml b/static/bitcoin-dev/Aug_2016/combined_New-BIP-Low-S-values-signatures.xml index 1d682b3978..2f94ae5b67 100644 --- a/static/bitcoin-dev/Aug_2016/combined_New-BIP-Low-S-values-signatures.xml +++ b/static/bitcoin-dev/Aug_2016/combined_New-BIP-Low-S-values-signatures.xml @@ -2,7 +2,7 @@ 2 Combined summary - New BIP: Low S values signatures - 2025-09-26T15:29:51.108786+00:00 + 2025-10-11T21:31:16.132322+00:00 python-feedgen Johnson Lau 2016-09-02 08:28:14+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - New BIP: Low S values signatures - 2025-09-26T15:29:51.108972+00:00 + 2025-10-11T21:31:16.132509+00:00 2016-09-02T08:28:14+00:00 BIP146 proposes changes to the Bitcoin transaction validity rules in order to address signature malleability related to ECDSA signature encoding. This malleability allows relay nodes on the network to alter signatures without needing access to private keys. The BIP introduces two new rules: LOW_S and NULLFAIL. LOW_S restricts the S value inside ECDSA signatures to be at most half of the curve order, with strict DER encoding. If a signature fails the Low S value check and is not an empty byte array, the entire script will evaluate to false immediately. NULLFAIL requires that if an OP_CHECKSIG returns a FALSE value, the relevant signature must be an empty byte array. If an OP_CHECKMULTISIG returns a FALSE value, all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays. The NULLDUMMY rule has been removed from BIP146 and will become another softfork implemented along with segwit. This revision of BIP146 adds the newly implemented NULLFAIL rules which should cover all special cases. The LOW_S softfork may be deployed later due to some undocumented behavior discovered. However, NULLFAIL will be implemented as a policy rule in 0.13.1, but the softfork won't be deployed in 0.13.1.Recently, the BIP146 was updated to include NULLDUMMY as part of the softfork. The update can be found on the Github page of Bitcoin Improvement Proposals (BIPs). This trivial softfork aims to fix malleability related to the extra stack element consumed by CHECKMULTISIG(VERIFY). It is considered important as it prevents attackers from replacing the stack element with any value, which could have serious implications. The inclusion of NULLDUMMY in BIP146 addresses this issue and enhances the security of the cryptocurrency system. This update demonstrates the continuous improvement made to the Bitcoin protocol to enhance security and prevent malicious attacks.On August 16, 2016, there was a discussion between Luke Dashjr and Johnson Lau regarding the ECDSA verification process for signatures passed to operators like OP_CHECKSIG and OP_CHECKMULTISIG. These operators perform verifications on pubkey/signature pairs in reverse order from the top of the stack. If a signature fails the IsLowDERSignature check, it is not processed. However, there is ambiguity in the reference to "the IsLowDERSignature check" as it is not clearly defined. Dashjr points out that the IsLowDERSignature function in Bitcoin Core is not directly called, but he will clarify this.A new Bitcoin Improvement Proposal (BIP) has been proposed to make low S value signatures a consensus rule. The proposal aims to restrict signatures to using low S values to fix malleability issues. ECDSA signatures are malleable, but restricting the S value helps prevent invalidation by taking the negative of the number S. The BIP states that every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY must use an S value between certain limits with strict DER encoding. The BIP will be deployed using version bits BIP9, likely in v0.13.1. The implementation for the reference client can be found on Github. This proposal also reduces transaction malleability, providing additional benefits to the Bitcoin system. diff --git a/static/bitcoin-dev/Aug_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml b/static/bitcoin-dev/Aug_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml index 74ca3f5881..c702107296 100644 --- a/static/bitcoin-dev/Aug_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml +++ b/static/bitcoin-dev/Aug_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml @@ -2,7 +2,7 @@ 2 Combined summary - ScalingBitcoin 2015: Retarget - Call For Proposals Now Open - 2025-09-26T15:29:44.765134+00:00 + 2025-10-11T21:31:09.760665+00:00 python-feedgen Matt Corallo 2016-09-01 00:56:08+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - ScalingBitcoin 2015: Retarget - Call For Proposals Now Open - 2025-09-26T15:29:44.765291+00:00 + 2025-10-11T21:31:09.760847+00:00 2016-09-01T00:56:08+00:00 The Scaling Bitcoin 2016: Retarget conference has extended its deadline for submissions to September 9th. This year, the conference is offering rolling acceptance in an effort to respond to most proposals before September 23rd. The conference defines "scaling" broadly, encompassing topics such as improving Bitcoin throughput, layer 2 ideas, security and privacy, incentives and fee structures, testing, simulation and modeling, network resilience and latency, fungibility, anti-spam measures, block size proposals, and mining concerns.The Call for Proposals (CFP) was opened on August 2nd and can be found on the scalingbitcoin.org website. Interested parties who wish to submit their proposals have until September 2nd to do so. After the submission deadline, applicants will be notified of their acceptance status by September 23rd. The Scaling Bitcoin 2016: Retarget conference will take place in Milan on October 8th and 9th. For more information and to access the CFP, interested individuals can visit the scalingbitcoin.org website. diff --git a/static/bitcoin-dev/Aug_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml b/static/bitcoin-dev/Aug_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml index 15fcb8d71c..0eed3fdf94 100644 --- a/static/bitcoin-dev/Aug_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml +++ b/static/bitcoin-dev/Aug_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml @@ -2,7 +2,7 @@ 2 Combined summary - Status updates for BIP 9, 68, 112, and 113 - 2025-09-26T15:29:46.880010+00:00 + 2025-10-11T21:31:11.884010+00:00 python-feedgen Btc Drak 2016-08-18 23:05:59+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Status updates for BIP 9, 68, 112, and 113 - 2025-09-26T15:29:46.880165+00:00 + 2025-10-11T21:31:11.884169+00:00 2016-08-18T23:05:59+00:00 Luke Dashjr, a Bitcoin Core developer, has announced his plans to update the status of BIPs 9, 68, 112, and 113 to Final in one month. Previously, there was confusion surrounding the classification of BIP 9, as it was unclear whether it fell under the Draft/Accepted/Final or Draft/Active classification. However, Dashjr believes that since BIPs 68, 112, and 113 have already been successfully deployed, BIP 9 should now be considered an informational BIP falling under the Draft/Accepted/Final class. In order to proceed with this update, Dashjr requires at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage.The discussion surrounding BIP 9 centers around its classification as just an "Informational" BIP, despite its importance in the consensus logic. Luke Jr. argues that BIP 9 is merely informational in advising how other BIPs should deploy themselves, making it a grey area. Wladimir J. van der Laan raises concerns over such an important deployment mechanism being classified solely as an informational BIP. However, none of the authors have commented on changing the type of BIP 9, even after a month of discussion. Thus, Luke asks if anyone objects to him updating BIP 9 to Final status.Dashjr suggests that BIP 9 should be reclassified as a "Standard BIP" rather than just an informational one, as it is included as part of the BIP 68 standard. He further explains that any modifications to BIP 9 would likely require a new BIP, and soft-forks utilizing the new standard would refer to the new BIP number. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be considered as part of the Draft/Accepted/Final classification. Additionally, he highlights that BIPs 68, 112, and 113 have already been successfully deployed to the network, satisfying the requirements for both Accepted and Final status. Consequently, Dashjr proposes that all four BIPs (BIPs 9, 68, 112, and 113) should be updated to Final status within one month.To proceed with this update, Dashjr needs at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage. Peter Todd, a developer at Bitcoin, has responded with an ACK in support of the "Final" status. The discussion regarding these updates can be found on the Github BIPs repository. However, it is recommended to continue the discussion via email.In summary, Luke Dashjr plans to update the status of BIPs 9, 68, 112, and 113 to Final within one month. There is a debate surrounding the classification of BIP 9, with Dashjr suggesting it should be considered a "Standard BIP" rather than just informational. He argues that BIP 9 is included as part of the BIP 68 standard and that any modifications would likely require a new BIP. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be classified under the Draft/Accepted/Final category. To proceed with the updates, Dashjr needs sign-offs from authors of each BIP. The discussion took place on the Github BIPs repository, but further communication is recommended via email. diff --git a/static/bitcoin-dev/Aug_2017/combined_Fwd-Compressed-headers-stream.xml b/static/bitcoin-dev/Aug_2017/combined_Fwd-Compressed-headers-stream.xml index 193235c4f7..b5e5ec901d 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Fwd-Compressed-headers-stream.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Fwd-Compressed-headers-stream.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fwd: "Compressed" headers stream - 2025-09-26T15:58:51.666527+00:00 + 2025-10-11T22:11:20.518833+00:00 python-feedgen Peter Todd 2017-09-04 14:06:44+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Fwd: "Compressed" headers stream - 2025-09-26T15:58:51.666709+00:00 + 2025-10-11T22:11:20.518956+00:00 2017-09-04T14:06:44+00:00 In a discussion on the bitcoin-dev mailing list, Gregory Maxwell highlighted various methods to reduce the number of bytes required for block headers. These techniques involve minimizing changes to the bits field, setting the timestamp to be slightly higher than the previous one, and recognizing that the block version is typically one of the last few. However, these improvements offer only a constant factor reduction in size.The compact SPV proofs, outlined in the appendix of the sidechains whitepaper, introduce logarithmic scaling proofs but solely validate total work, not validity. OpenTimestamps aims to establish a framework for trusted validity attestations, as timestamping via proof-of-work presents security concerns due to the potential manipulation of block times by miners. It is crucial to comprehend the associated risks before implementing compact SPV proofs. Additionally, there may be an opportunity to enhance initial download bandwidth by including a known-good sum-merkle-tree tip hash with the software.Riccardo Casatta expressed his belief in an email to bitcoin-dev that Bitcoin headers represent the most vital data globally, with an anticipated increase in demand. He proposed optimizing transmitted data when sending a continuous stream of block headers by eliminating the transmission of previous hashes after the first header. The receiver can calculate the previous hash by double hashing the previous header, which is necessary for verifying the proof of work. This approach could potentially save approximately 40% in bandwidth when transmitting a lengthy sequence of block headers.However, another participant in the discussion countered this suggestion by mentioning alternative ways to reduce bytes in the block headers field, such as avoiding changes to the bits field every 2016 blocks or only including the timestamp if it surpasses the median of the last 11 blocks. These optimizations also provide only a constant factor reduction in size. The contributor recommended exploring the compact SPV proofs described in the appendix of the sidechains whitepaper for logarithmic scaling proofs. diff --git a/static/bitcoin-dev/Aug_2017/combined_Fwd-Lightning-in-the-setting-of-blockchain-hardforks.xml b/static/bitcoin-dev/Aug_2017/combined_Fwd-Lightning-in-the-setting-of-blockchain-hardforks.xml index 0136450cce..694bcc4dd5 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Fwd-Lightning-in-the-setting-of-blockchain-hardforks.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Fwd-Lightning-in-the-setting-of-blockchain-hardforks.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fwd: Lightning in the setting of blockchain hardforks - 2025-09-26T15:59:04.457577+00:00 + 2025-10-11T22:11:24.774712+00:00 python-feedgen Natanael 2017-08-17 13:38:26+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Fwd: Lightning in the setting of blockchain hardforks - 2025-09-26T15:59:04.457728+00:00 + 2025-10-11T22:11:24.774865+00:00 2017-08-17T13:38:26+00:00 The conversation among Bitcoin developers revolves around the issue of payment channels during hardforks. Payment channels are not a concern for hardforks like Bitcoin ABC without a malleability fix. However, in the case of a hardfork with a malleability fix, replay protection is needed to prevent problems. One possible solution is to timestamp commitments and integrate them into the channel design. By accepting only old commitments for a certain period of time, this replay protection can be reused for future hardforks. However, hardforking while having open channels presents challenges. Open channels require monitoring the blockchain, and those unaware of the hardfork or late in updating their client could have their funds stolen through old commitment transactions. The risk of retaliation is relatively low for attackers, as others can likely determine the client version. If no replay protection is implemented on the fork, open channels will need to be settled twice. If replay protection is implemented, commitments become invalid on the fork, resulting in financial losses for users.The discussion on Lightning in the context of blockchain hardforks began in an email thread between Christian Decker and Martin Schwarz. They addressed the issue of open channels during a fork, noting that if no replay protection is implemented, the last commitment can be used to close the channel. However, if replay protection is in place, commitments become invalid on the fork, leading to potential financial losses. To solve this problem, the suggestion was made to redefine chain_id as the hash of the first block of the new branch and require replay and wipe-out protection. The question of whether these requirements can be relaxed and concerns about slow block times were also raised. It was proposed that timestamping of commitments could be integrated into the channel design to address replay protection. It was acknowledged that hardforking with open channels will always be problematic, and those unaware of or late to update their client risk losing their funds.Christian Decker welcomes Martin Schwarz to the Lightning-dev mailing list and agrees with his proposal of using the first forked block as the genesis block for the forkchain to minimize disruption. In cases where channels are open during the fork, a single channel would need to be settled twice. If no replay protection is implemented, the last commitment can be used to close the channel. However, if replay protection is in place, commitments become invalid on the fork, potentially resulting in financial losses. Martin Schwarz raises the question of how Lightning can function across distinct permanent forks of a parent blockchain that share the same genesis block with hardforks branching off the Bitcoin blockchain. He suggests redefining chain_id to the hash of the first block of the new branch and requiring replay and wipe-out protection. The discussion also touches on concerns about slow block times and whether Lightning can transact on "almost frozen" block chains that experience a sudden loss of hash power. Additionally, the participants inquire about previous discussions or studies on Lightning in the context of hardforks. Bryan's contact information is provided at the end of the email thread. diff --git a/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-on-Bitcoin.xml b/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-on-Bitcoin.xml index f08ee71901..6d7ba3a86a 100644 --- a/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-on-Bitcoin.xml +++ b/static/bitcoin-dev/Aug_2017/combined_Solving-the-Scalability-Problem-on-Bitcoin.xml @@ -2,7 +2,7 @@ 2 Combined summary - Solving the Scalability Problem on Bitcoin - 2025-09-26T15:58:45.290634+00:00 + 2025-10-11T22:11:18.395501+00:00 python-feedgen Matthew Beton 2017-08-27 13:19:25+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - Solving the Scalability Problem on Bitcoin - 2025-09-26T15:58:45.290803+00:00 + 2025-10-11T22:11:18.395678+00:00 2017-08-27T13:19:25+00:00 There is a potential issue with pruning in Bitcoin, as some wallets do not fully empty when instructed to send all funds. This could lead to difficulties in pruning, as wallets with any coins left cannot be pruned. To address this, users need to be encouraged to send everything instead of leaving a small fraction. The problem with node pruning is that it is not standardized, and new nodes need to download and prune all data themselves. The blockchain size is increasing exponentially and could reach a terabyte soon. Adam Tamir Shem-Tov proposes the concept of "trusted" nodes to solve this scalability problem. However, Thomas Guyot-Sionnest argues that implementing this solution is impossible without keeping all blocks until a hard-coded checkpoint. Shem-Tov suggests combining and pruning the blockchain every 999 blocks to one block, leaving only the genesis block. The network would wait for a special "pruned block" before accepting new blocks, and the ledger would always be a maximum of 1000 blocks.In response to a query about shortening transactions in Bitcoin, changes to the hash reference system, UTXO table, and reward mechanism are proposed. The author suggests blocks should refer to the hash of the balance sheet instead of the previous block's hash and that a new signature must be placed on the shortened transaction. However, there are issues with nLockTime and non-standard transactions. These changes would affect wallets, UTXO references, and the proof of work system.The email thread discusses a proposal to solve the scalability issue in Bitcoin by combining and pruning the blockchain every 999 blocks to one block. This would limit the ledger to a maximum of 1000 blocks. The size of the blockchain is currently around 140GB and growing rapidly. Node pruning is not standardized, making it difficult for new nodes to verify data. The proposal suggests adding a Genesis Account to remove intermediate origins and make funds untraceable. However, implementing this solution is deemed impossible due to the difficulty of determining the authenticity of the blockchain midway. Saving all necessary data every 1000 blocks does not guarantee dropping older blocks.The proposal to solve the scalability issue involves combining and pruning the blockchain every 999 blocks, leaving only the genesis block. The network would wait for a "pruned block" before accepting new blocks. However, implementing this is considered impossible due to authenticity and compatibility issues. The current implementation of node pruning keeps unspent inputs and recent blocks. Adam Tamir Shem-Tov suggests trusted nodes as a solution, but Thomas Guyot-Sionnest argues against it. The size of Bitcoin's data is currently around 140GB and could reach a terabyte soon, requiring action.The author suggests combining and pruning the blockchain every 999 blocks to one block to solve the scalability issue. This pruned block would contain a summed up transaction of all transactions in the previous 999 blocks and its hash pointer would reference the genesis block. Full nodes would verify the pruned block before accepting a new block. However, implementing this solution is considered impossible due to difficulties in determining the authenticity of the blockchain midway. Node pruning currently keeps unspent inputs and recent blocks, but there are also proposals to include UTXO in some blocks. The size of Bitcoin's data is growing exponentially and action needs to be taken. diff --git a/static/bitcoin-dev/Aug_2017/combined_UTXO-growth-scaling-solution-proposal.xml b/static/bitcoin-dev/Aug_2017/combined_UTXO-growth-scaling-solution-proposal.xml index ba24ae740d..4c5b0fc55c 100644 --- a/static/bitcoin-dev/Aug_2017/combined_UTXO-growth-scaling-solution-proposal.xml +++ b/static/bitcoin-dev/Aug_2017/combined_UTXO-growth-scaling-solution-proposal.xml @@ -2,7 +2,7 @@ 2 Combined summary - UTXO growth scaling solution proposal - 2025-09-26T15:58:55.935161+00:00 + 2025-10-11T22:11:22.642730+00:00 python-feedgen Mark Friedenbach 2017-08-23 03:26:19+00:00 @@ -101,10 +101,11 @@ + 2 Combined summary - UTXO growth scaling solution proposal - 2025-09-26T15:58:55.935345+00:00 + 2025-10-11T22:11:22.642926+00:00 2017-08-23T03:26:19+00:00 Bitcoin developers are engaged in discussions about implementing features that could change the operation of Bitcoin. One proposal suggests making coins "expire" after a certain period of time, while another proposes creating a "never expire" transaction output. The potential security risks and the need for transparency and warning are also emphasized. Additionally, there is debate about implementing free transactions based on old priority rules, with suggestions including requiring the inclusion of free transactions in each block or a two-step transaction with a fee to register a UTXO refresh. However, there is no consensus on how to implement these proposals without burdening consensus rules.The threat of quantum computing to Bitcoin's security is also discussed, with suggestions for new proof-of-work algorithms, address formats, and signing protocols. Removing stale coins to prevent hacking is proposed, but there are differing opinions on whether this aligns with the principles of Bitcoin. The conversation highlights the challenges of implementing significant changes to Bitcoin, touching on issues of transparency, security, taxation, and adapting to technological advancements.Bitcoin developers are exploring solutions to address unbounded UTXO growth and ensure scalability. Proposals include burning inactive coins, implementing a minimum mining fee based on input age, and returning lost coins to miners as a fee. Limiting UTXO age in block count and invalidating UTXOs after a certain number of generations are also suggested. Some argue that limiting UTXO growth does not improve scalability, while others believe it is necessary for Bitcoin's longevity. The issue of UTXO size being critical because it cannot currently be pruned is acknowledged.A proposed solution involves using a soft fork to limit the maximum size of the UTXO set, with concerns raised about "lost" bitcoins that have not been spent for a long time. To address this, a mechanism called "luster" is suggested, where UTXOs lose value as they age. Coins continuously used in the Bitcoin economy retain value, while old coins lose value until they become valueless or reenter circulation. The proposal suggests storing the last 150 years of history in the blockchain. These proposals show promise in resolving the UTXO growth problem and scalability concerns but require considerations such as wallet software compatibility and sidechain implementation.Sidechains offer solutions to interoperability and scalability challenges in the blockchain ecosystem. They operate as separate blockchains pegged to the main blockchain, enabling asset transfer between chains and providing flexibility. Sidechains mitigate scalability issues by reducing the size of the main blockchain. However, implementing sidechains requires careful consideration of wallet software functionality and communication protocols between the main chain and sidechains. Collaboration and standardization within the blockchain community are necessary for successful integration. Sidechains have the potential to enhance blockchain functionality and address scalability concerns with the right development efforts. diff --git a/static/bitcoin-dev/Aug_2018/combined_Claiming-an-OP-RETURN-Prefix.xml b/static/bitcoin-dev/Aug_2018/combined_Claiming-an-OP-RETURN-Prefix.xml index 4cb063d077..b6d9052692 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Claiming-an-OP-RETURN-Prefix.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Claiming-an-OP-RETURN-Prefix.xml @@ -2,7 +2,7 @@ 2 Combined summary - Claiming an OP_RETURN Prefix - 2025-09-26T16:01:14.396865+00:00 + 2025-10-11T22:14:44.576335+00:00 python-feedgen Ryan Grant 2018-08-16 17:32:25+00:00 @@ -65,10 +65,11 @@ + 2 Combined summary - Claiming an OP_RETURN Prefix - 2025-09-26T16:01:14.397024+00:00 + 2025-10-11T22:14:44.576550+00:00 2018-08-16T17:32:25+00:00 In a recent conversation on the bitcoin-dev mailing list, concerns were raised about whether miners can identify transactions coming from specific software and censor them. The use of IPFS, a distributed file system, was discussed as a potential solution. It was noted that miners cannot identify transactions by their hashes until after they have already been confirmed and added to the blockchain.The discussion also touched on whether choosing not to mine transactions is considered censorship. It was argued that miners have the right to choose transactions based on their own policies, and that the system is designed to have many miners with differing policies. It was pointed out that even if transaction fees were higher, no one is obliged to accept payment for a service they don't want to provide.The topic of pruning op_return outputs was also brought up in the conversation. It was suggested that these outputs, which are not spendable, could be removed. However, it was concluded that using hash in witness script data would not be helpful and might make things worse. Recommendations were made to use pay 2 contract instead of op_return for timestamping purposes. OpenTimestamps was also recommended for actual timestamping needs. It was emphasized that op_return is used not only for timestamping but also for storing URLs and other elements that affect the hash. Batching OTS uses and IPFS directories were found to be incompatible.The possibility of miners identifying transactions from specific software and censoring them was discussed. It was acknowledged that miners could potentially censor transactions if they were able to identify them. However, it was noted that trying to inspect every OP_RETURN of every transaction would be a high-cost operation. It was also argued that choosing not to mine transactions may not be censorship economically, but politically it could be seen as such. The discussion concluded with the assertion that choosing not to mine transactions is not censorship.In a separate discussion, the use of op_return prefixes was debated. It was advised against using them due to the potential for transaction censorship. One suggestion was to remove IPFS multihash prefix information in order to minimize a miner's ability to identify transactions. Responsible ways to publish the hash, such as including it in the witness script data, were considered. However, no solid proposal for best practices has been made yet.The conversation also touched on the issue of claiming an op_return prefix. It was recommended not to use a prefix at all, as it is unnecessary from a censorship resistance and anonymity perspective. There is no formal or standard process to claim a prefix, and no existing BIP has claimed an op_return prefix.In response to a message from Lautaro Dragan, Tech Lead of Po.et, seeking guidance on using colored coins or storing data on the Bitcoin blockchain with a prefix, Luke Dashjr suggested collaborating with the authors of BIP 160 or writing a new BIP if BIP 160 is insufficient. It was emphasized that BIPs need to specify an actual protocol, not just claim a prefix.Overall, the email conversations covered various topics related to transaction censorship, op_return outputs, timestamping, and claiming op_return prefixes. Different perspectives were shared, and recommendations were made for responsible practices. diff --git a/static/bitcoin-dev/Aug_2018/combined_Getting-around-to-fixing-the-timewarp-attack-.xml b/static/bitcoin-dev/Aug_2018/combined_Getting-around-to-fixing-the-timewarp-attack-.xml index 12a1e7bfa6..208f8c7f52 100644 --- a/static/bitcoin-dev/Aug_2018/combined_Getting-around-to-fixing-the-timewarp-attack-.xml +++ b/static/bitcoin-dev/Aug_2018/combined_Getting-around-to-fixing-the-timewarp-attack-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Getting around to fixing the timewarp attack. - 2025-09-26T16:00:53.371364+00:00 + 2025-10-11T22:14:42.449699+00:00 python-feedgen Bram Cohen 2018-08-30 20:55:17+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Getting around to fixing the timewarp attack. - 2025-09-26T16:00:53.371551+00:00 + 2025-10-11T22:14:42.449871+00:00 2018-08-30T20:55:17+00:00 Bitcoin's non-overlapping difficulty calculation has been known to be vulnerable to gaming with inaccurate timestamps since 2012. This vulnerability can be fixed with a soft-fork that further constrains block timestamps, and several proposals have been suggested. One proposal being discussed is to require the timestamp of block (2016x) not smaller than its parent block by t-seconds, with 0 ≤ t ≤ infinity. Reducing the value of t is a softfork. The aim is to find a t which is small-enough-to-prohibit-time-wrap-attack but also big-enough-to-avoid-split.A chain-split would happen even without any attack if a naive fix is adopted, which requires every block (2016x) to have a timestamp not smaller than that of its parent block. This fix involves mandatory upgrade of pool software and will cause a chain split unless super-majority of miners are enforcing the new rules. The best way is to do it with something like BIP34, which also requires new pool software.Gregory Maxwell, a Bitcoin Core developer, posted on the bitcoin-dev mailing list about this issue in August 2018. He explained that the vulnerability had been known since 2012 and could be exploited to increase the rate of block production beyond the system's intentional design. Several proposals for fixing this vulnerability with a soft-fork have been suggested, but none are backwards compatible. Maxwell had put a demonstration of timewarp early in the testnet3 chain to allow people to test mitigations against it.Despite the vulnerability, there hasn't been a big priority into fixing it because it requires a majority hashrate and could easily be blocked if someone started using it. However, several proposals have been suggested that are fully compatible with existing behavior and only trigger in exceptional circumstances like a timewarp attack. Therefore, the risk of deploying these mitigations would be minimal.In light of this, Maxwell suggested asking the list if anyone else is aware of a favorite backwards compatible timewarp fix proposal they want to point out before dusting off his old fix and perhaps prematurely causing fixation on a particular approach. diff --git a/static/bitcoin-dev/Aug_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml b/static/bitcoin-dev/Aug_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml index 1ef6b265e5..cc116c0be0 100644 --- a/static/bitcoin-dev/Aug_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml +++ b/static/bitcoin-dev/Aug_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml @@ -2,7 +2,7 @@ 2 Combined summary - Braidpool: Proposal for a decentralised mining pool - 2025-09-26T15:38:21.001997+00:00 + 2025-10-11T21:48:46.261265+00:00 python-feedgen pool2win 2021-09-13 08:03:42+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - Braidpool: Proposal for a decentralised mining pool - 2025-09-26T15:38:21.002197+00:00 + 2025-10-11T21:48:46.261492+00:00 2021-09-13T08:03:42+00:00 The issue of a malicious miner cheating other miners of their reward is discussed in the context. The problem arises as the bitcoin block is used as the sentinel to mark the shares from DAG that need to be rewarded. A proposed solution is to have the hub broadcast a "sentinel" to mark out the point in logical time up to which shares will be rewarded.A proposal is made to reward miners for creating valid blocks, but concerns are raised about rogue miners avoiding referencing other miners' shares to keep rewards for themselves. Two methods are suggested for resolving conflicts between conflicting versions of the DAG: using the longest chain or the one with more work. However, both methods present issues such as the potential for bad hashers to create low-difficulty shares and then mine and publish higher-difficulty shares without sharing the reward.In an email exchange, questions are raised about the proposal that every share can reference multiple previous shares. Concerns are expressed about rogue miners not referencing any shares from other miners to avoid sharing the reward. Doubts are also raised about how conflicts between different valid states will be resolved.A discussion on the Bitcoin-dev mailing list focuses on the centralization of Braidpool's payout server, which is seen as a single point of failure. Suggestions are made to use multiple hubs to reduce the risk of a single point of failure. One idea presented is a Lightning model where multiple hubs offer liquidity to the network, and the winning hasher elects one of the hubs to receive the payout. It is acknowledged that getting something working now may be more beneficial than waiting for a perfect solution.ZmnSCPxj points out that Braidpool's payout server remains a single central point of failure despite claims of using Tor hidden service to protect against DDoS attacks. Multiple hubs are suggested as a preferable solution, with Chris Belcher's proposal for using payment channels mentioned as a potential construction for multiple hubs. It is acknowledged that more ideas for decentralization may emerge as Braidpool is built.The benefits of Stratum v2 and its comparison to other mining methods are discussed. It is noted that mining pools still have the ability to reject negotiations and censor payments. Suggestions are made to use Stratum v2 in combination with other technologies, such as discreet log contracts.Braidpool is viewed as an improvement to P2Pool in making a peer-to-peer pool work on a larger scale. It offers transparent views of shares received by the pool, allowing miners to verify reward calculations. It also offers payouts over a one-way channel, unlike P2Pool. Braidpool prepares for future attacks on centralized mining pools while attracting miners to the platform now.In a discussion on centralized mining control and payment censorship, concerns are raised about the control of transaction selection and potential censorship. The use of Lightning Network (LN) for payouts is suggested as a way to mitigate these issues, but the advantages of Braidpool over an idealized version of centralized mining with independent transaction selection are questioned.A comparison is made between a decentralized mining pool using BetterHash or Stratum v2 with LN-based payouts and a centralized mining pool. The advantages of a decentralized pool are highlighted, including the ability for miners to choose their own transactions and prevent any single entity from having control over the selection process.Pool2win proposes a decentralized solution to the problems faced by P2Pool. The proposal aims to provide lower variance for smaller miners and enable a futures market for hash rates. The solution uses a DAG of shares replicated at all miners to compute rewards, with payouts made via one-way payment channels by an anonymous hub communicating through Tor's hidden services. Comparisons to Stratum v2 are not provided.The Pool2Win team develops Braidpool, a decentralized mining pool aimed at overcoming issues faced by P2Pool and enabling a futures market for hash rates. The pool offers lower variance for smaller miners, allows miners to build their own blocks, and provides transparent views of shares received by the pool. Rewards are paid out via one-way payment channels using Tor's hidden services to prevent cheating. The team also provides details on trading hash rate. The ultimate goal is to provide a more efficient and fair mining experience while contributing to Bitcoin's decentralization. diff --git a/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml b/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml index 3ae6bc4158..aab9843712 100644 --- a/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml +++ b/static/bitcoin-dev/Aug_2022/combined_A-method-for-BIP322-signing-delegation.xml @@ -2,7 +2,7 @@ 2 Combined summary - A method for BIP322 signing delegation - 2025-09-26T15:35:26.065718+00:00 + 2025-10-11T21:44:28.981313+00:00 python-feedgen Ali Sherief 2022-08-22 07:56:12+00:00 @@ -22,10 +22,11 @@ + 2 Combined summary - A method for BIP322 signing delegation - 2025-09-26T15:35:26.065851+00:00 + 2025-10-11T21:44:28.981545+00:00 2022-08-22T07:56:12+00:00 The message discusses an edge case that BIP322 only partially solves - Proof of Payment. In P2P transactions, there is always a risk that the other party will be dishonest and deny receiving payment. This type of dispute is rampant in cryptocurrencies as it can be used as a scam attempt to extract more money from the buyer. BIP322 signed messages can prove that the UTXO(s) belong to the buyer, but not *who* it was sent to.The proposal is to use P2WSH 2-of-2 multisig to solve this problem. The script challenge consists of something like OP_SHA256 OP_EQUAL. The idea behind the scheme is to make it verifiable to the public. Alice signs a BIP322 message from a UTXO and provides one of the signatures, Bob is forced to sign another BIP322 message from his address if he wants his money, and provides another signature. Both signatures are published on the blockchain. The signatures in the Multisig transaction prove who has control of which inputs, so it can be proven who paid who.A delegation scheme for privacy purposes has been proposed that utilizes multisig to make the possible delegatees known at signing time. This would replace the message challenge of "to_spend" with a 1-of-N standard P2WPKH multisig, where N is the number of people you want to be able to create the signature, and their respective pubkeys are included in the script. The possible delegatees are fixed at signature creation time and cannot be extended by creating more transactions. The challenge solution in "to_sign" is then replaced with a witness stack containing n ... 1 0. The signature is generated as if it were for a real P2WPKH-multisig transaction.The proposal has some advantages: no recursive transactions, address verification is provable, there is no opcode or new algorithm introduced, so no soft-fork is required, and signature fraud is still impossible to carry out. There is also a major privacy advantage in that only the delegatee who actually signs the message has a revealed public key, the others' are hidden. There are some disadvantages, such as everyone knows the public keys of the delegators, so there is no privacy. However, this is possibly a non-issue in light of the signature fraud problem. Additionally, Taproot is not widely deployed in applications yet.Moreover, some people have suggested writing this delegation scheme in TapScript, which could avoid revealing the unspent public keys. Single leaf k-of-n multisig is functionally identical to "Using a single OP_CHECKSIGADD-based script" described in BIP 0342, footnote 5, but it won't hide the non-signing public keys. That leaves multi-leaf k-of-k multisig, which swells as k increases, but for the purposes of delegation, K will always be 1, because we only utilize 1-n multisig signatures as per the previous message.This post discusses a proposal for BIP322 polishing, specifically regarding delegating signatures to other scriptPubKeys for privacy purposes. Instead of using a complicated transaction scheme, the proposal suggests using a multisig approach that makes possible delegatees known at signing time. The proposal outlines steps to replace the message challenge and challenge solution with a witness stack containing n...1 0, generating the signature as if it were for a real P2WPKH-multisig transaction. The pros of this approach are outlined, including no recursive transactions and provable address verification, while the con is that public keys of delegators are known, potentially compromising privacy. Input from others is requested, particularly from luke-jr who participated in the original Github discussion on delegation.A proposal has been made to solve the delegation problem in BIP322. This solution is built on Jeremy Rubin's transaction delegation post and allows a person to delegate signing to another person. This delegation can be useful for various purposes such as Lightning Network, CoinJoin, Mixers, and Silent Payments. The delegation works by signing a preliminary transaction with specific inputs and outputs. The signed message includes the Message, Address, and Signature. BIP322 specifies that the signature is just the raw transaction format of "to_sign". The address used can represent a kind of company; it can represent a channel, a coinjoin, or a silent payment. Bech32 is used to encode the "address" to make it look like a real address.The advantages of this scheme include privacy, arbitrary number of delegations, and delegated signatures can wrap Full and Full with UTXOs signing formats. There are no disadvantages to this scheme. The FAQ section clarifies how the delegation works, how to differentiate between non-delegated and delegated signatures, and how to verify a delegated BIP322 transaction if the address-hash is private. The proposal is cc'd to Kalle for consideration. diff --git a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml index 770e920ac8..9012ba1a8d 100644 --- a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml +++ b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2025-09-26T15:35:40.880700+00:00 + 2025-10-11T21:44:43.862670+00:00 python-feedgen Dmitry Petukhov 2022-08-04 07:09:33+00:00 @@ -42,10 +42,11 @@ + 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2025-09-26T15:35:40.880846+00:00 + 2025-10-11T21:44:43.862863+00:00 2022-08-04T07:09:33+00:00 A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. The proposal uses tuples of diff --git a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml index fcd4be2604..f61f51a81c 100644 --- a/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml +++ b/static/bitcoin-dev/Aug_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2025-09-26T15:35:32.401962+00:00 + 2025-10-11T21:44:35.364472+00:00 python-feedgen Craig Raw 2022-09-26 08:23:18+00:00 @@ -86,10 +86,11 @@ + 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2025-09-26T15:35:32.402150+00:00 + 2025-10-11T21:44:35.364675+00:00 2022-09-26T08:23:18+00:00 The proposed standard aims to create a defined format for transferring labels that users have applied to transactions, addresses, inputs, or outputs in their wallets. The format uses the comma-separated values (CSV) format, which is widely supported. Each record in the CSV file consists of two fields: the reference to a transaction, address, input, or output, and the label applied to that reference. The proposal suggests using ZIP compression for the CSV file, with optional AES encryption.Some feedback on the proposal includes suggestions for improvements, such as adding a version byte to the header line, making the header line mandatory, and using an unsigned 32-bit integer for the second column. There are also suggestions to remove the optional encryption feature and not include input and output types in the export to avoid privacy leaks. Instead, commentators suggest adding a third column for item type identification.Despite disagreement on the use of CSV as a standard format, the goal of the proposal is to create a standardized format for importing and exporting wallet labels. The proposed format is a simple two-column CSV file, aiming to make label management more accessible to users and ensure compatibility between different wallet implementations. Feedback on the proposal is appreciated, and further improvements may be made based on the feedback received.The use of CSV for transferring labels between wallet applications is motivated by its wide accessibility and integration with existing processes and tools like Excel. However, there is some disagreement about using CSV, with suggestions to use JSON instead due to concerns about CSV compatibility and parsing effort. Despite this disagreement, the proposal aims to create a standard for importing and exporting labels from a wallet, regardless of the chosen data format.The proposal specifies a two-column CSV format, where the first column contains the reference to a transaction, address, input, or output, and the second column contains the label. The CSV file can be compressed using ZIP and optionally encrypted using AES. Importing applications may truncate labels if necessary, while exporting applications may omit records with no labels or labels of zero length.The proposal seeks to make label management accessible to users without technical expertise and reduce file size while ensuring compatibility. The discussion on the Bitcoin-dev mailing list provides insight into ongoing development work on the Bitcoin protocol and the collaborative nature of the Bitcoin development community.There is some disagreement about using CSV as the standard format for transferring labels, with suggestions to use JSON instead. One commenter suggests including descriptors in the format for advanced users. In response to a question about SLIP-0015, it is stated that SLIP-0015 has different design goals and limitations compared to the proposed BIP.The proposal allows for ZIP compression and optional AES encryption of the CSV file. The password for encryption should be the textual representation of the wallet's extended public key. The aim of this proposal is to create a standard for exporting and importing labels from a wallet, avoiding lock-in to a specific application, and making label management accessible to non-technical users.Feedback on the proposal is requested, and a reference implementation is yet to be determined. Suggestions for additions and changes to the format include adding a version byte, making the header line mandatory, requiring double quotes around the label, and writing a more robust importer algorithm. The proposal aims to standardize the export and import of labels using a simple CSV format. diff --git a/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml b/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml index 2efb31db2e..6b886e07c5 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Huge-wallets-make-Bitcoin-Core-unusable-Daemon-CLI-Qt-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Huge wallets make Bitcoin Core unusable (Daemon+CLI & Qt) - 2025-09-26T15:35:36.631669+00:00 + 2025-10-11T21:44:39.611869+00:00 python-feedgen Andrew Chow 2022-08-20 15:10:57+00:00 @@ -18,10 +18,11 @@ + 2 Combined summary - Huge wallets make Bitcoin Core unusable (Daemon+CLI & Qt) - 2025-09-26T15:35:36.631812+00:00 + 2025-10-11T21:44:39.612018+00:00 2022-08-20T15:10:57+00:00 A developer named Felipe Micaroni Lalli raised two questions on the bitcoin-dev mailing list regarding the optimization of Bitcoin wallet module. The first question was about optimizing a large wallet without moving funds to a new one. In response, it was suggested to use removeprunedfunds RPC which can remove old transactions and speed up balance calculations and transaction creation. The second question was about improving cache usage by putting the entire wallet in memory. However, it was clarified that the wallet is already entirely in memory. The issue with the wallet module is a known one and changing it takes significant time as it is a large module in Bitcoin Core.A user named Felipe Micaroni Lalli posted on the bitcoin-dev forum about the issue he faced with a 5-year-old production server wallet, which had 2.079.337 transactions and 446.503 generated addresses and was around 273 MB in size. The wallet's performance started to degrade exponentially, with most commands timing out. Increasing the timeout and RPC threads in the config file worsened the situation. Even after moving the wallet.dat to a fast SSD disk and increasing cache size, performance wasn't sufficient. If loaded in Bitcoin-qt, the system became unresponsive, making it difficult to use. Felipe questioned if improvements could be made or if the wallet feature should be removed altogether.To run a large Bitcoin core wallet, just call `RemovePrunedFunds` on old transactions. However, it is tricky as one has to ensure that the transaction is "safe to remove." Transactions become unsafe if they have a wallet utxo that you haven't spent or recently spent. Additionally, if transaction B spends from transaction A, removing transaction B will make the wallet think transaction A is unspent when it is not. Thus, pruning should be done depth-first.Bitcoin Core becomes almost useless for the wallet feature since the standard client is slow to sync, hard to use, and not preferred by end-users who opt for Electrum or Wasabi. It also becomes useless for servers in production, forcing them to use third-party solutions for huge wallets. The only current "solution" for huge wallets is to create a new one and send the funds there from time to time, but it can cause privacy concerns and break monitoring of old addresses.Felipe suggested caching the entire wallet in memory, but some code optimization might also be necessary. He asked whether it was possible to optimize a huge wallet without moving funds to a new one, improving cache usage, reducing wallet size, ignoring old addresses, improving I/O treatment, and CPU usage in the main thread on Bitcoin-Qt to avoid window freezing on big and huge wallets. Felipe proposed an "autoarchivehugewallets=1" feature in the file config to create a new wallet and move funds automatically. Felipe included links to several related issues and tests that he thought could be useful for developers. He also mentioned another possible bug where even after moving funds to a new wallet, the old wallet shows an old balance. Rescanblockchain command takes a long time to fix it.A user with a 5-year-old wallet, containing 2.079.337 transactions, and 446.503 generated addresses, has experienced exponential performance degradation when using the Bitcoin Core client. Most of the commands, such as "getbalance", "walletpassphrase" and "getreceivedbyaddress", timed out, while the CPU was 100% used, making the machine almost unusable. The default configuration of 16 RPC threads and 15 min timeout and some attempt calls per mi did not help. Increasing the timeout and/or the RPC threads in the config file made things worse. Loading the wallet in the "bitcoin-qt" caused everything to become unresponsive, including the system (OS/UI).This is bad because the standard client becomes almost useless for the wallet feature. Wallet Qt is already unpopular among end-users, being slow to first sync, hard to use, and not modern. It becomes useless now also for servers in production, forcing them to use third-party solutions for huge wallets. Currently, the only "solution" for huge wallets is to create a new one and send the funds there from time to time. However, this solution is not elegant and can break old address monitoring, leading to privacy concerns and unifying lots of inputs in a big and expensive transaction. The issue could also potentially become an issue if we have LN nodes that use the Bitcoin Core wallet infrastructure behind to open/close many channels for a long time.The user suggests that if moving the wallet from an HDD to an SSD improved a lot, maybe caching the entire wallet in memory could improve even more, but some code optimization is necessary. The following questions were raised: Can we "optimize" a huge wallet without moving the funds to a new one? Can we improve the cache usage somehow? Is it possible to reduce the wallet size? Can we tell the CLI to ignore old addresses? diff --git a/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml b/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml index b26cbd0d60..ee907a9d60 100644 --- a/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml +++ b/static/bitcoin-dev/Aug_2022/combined_New-Silent-Payment-version.xml @@ -2,7 +2,7 @@ 2 Combined summary - New Silent Payment version - 2025-09-26T15:35:23.950079+00:00 + 2025-10-11T21:44:26.858730+00:00 python-feedgen Ali Sherief 2022-08-22 12:55:58+00:00 @@ -18,10 +18,11 @@ + 2 Combined summary - New Silent Payment version - 2025-09-26T15:35:23.950246+00:00 + 2025-10-11T21:44:26.858923+00:00 2022-08-22T12:55:58+00:00 A new version of Bitcoin's Silent Payment implementation has been introduced through a Pull Request update (PR #24897) on the Bitcoin codebase on GitHub. This updated version improves upon the previous implementation by eliminating manual steps and introducing a new descriptor type called "sp()". This descriptor type contains exactly one key and generates a unique 'silent-payment' address.The silent payment address can be used as one of the outputs in a transaction, alongside standard addresses. The "send" RPC automatically identifies and tweaks the silent payment address. The output generated is a standard Taproot script with HRP changed from "bc" to "sp" on the mainnet or "tsp" on testnet and signet.It is important to note that the introduction of silent payments does not affect the consensus or auditability rules. These silent transactions are still included in publicly auditable blocks. The only difference is that the addresses cannot be hierarchically derived with BIP44 or any other path.Some critics have expressed concerns about the auditability of these transactions. However, Ali, the developer behind this update, explains that the silent payments are still publicly auditable and adhere to the original consensus that gave Bitcoin fungibility. Despite this explanation, some critics remain skeptical.To facilitate the review process, a step-by-step signet tutorial has been created for testers to easily test this new version. Overall, this updated version of Bitcoin's Silent Payment implementation simplifies the process of making silent payments, making it easier and more efficient for users. diff --git a/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml index db36920738..060ea917d7 100644 --- a/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Aug_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -2,7 +2,7 @@ 2 Combined summary - On a new community process to specify covenants - 2025-09-26T15:35:28.177168+00:00 + 2025-10-11T21:44:31.116862+00:00 python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -106,10 +106,11 @@ + 2 Combined summary - On a new community process to specify covenants - 2025-09-26T15:35:28.177355+00:00 + 2025-10-11T21:44:31.117024+00:00 2022-10-07T15:33:12+00:00 The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest diff --git a/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml b/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml index f641cca7ac..32b1b5d1af 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Regarding-BIP322-edge-cases.xml @@ -2,7 +2,7 @@ 2 Combined summary - Regarding BIP322 edge cases - 2025-09-26T15:35:34.516828+00:00 + 2025-10-11T21:44:37.488103+00:00 python-feedgen Ali Sherief 2022-08-11 16:56:29+00:00 @@ -34,10 +34,11 @@ + 2 Combined summary - Regarding BIP322 edge cases - 2025-09-26T15:35:34.516982+00:00 + 2025-10-11T21:44:37.488288+00:00 2022-08-11T16:56:29+00:00 The Bitcoin community is currently exploring a way for the initial signer to delegate to another scriptPubKey in order to improve privacy and compatibility with CoinJoin/Lightning. One suggestion that has been proposed is to use MAST (two Merkle branches) to achieve this. The first branch would contain the original signer's scriptPubKey, while the second branch would contain the delegated signer's scriptPubKey. It appears that all parties involved can make signatures on both the delegating and delegated keys. However, more documentation is needed to fully understand the motivation behind this requirement.In relation to OP_CHECKDATASIG, it has been discovered that this opcode already exists in Bitcoin Cash. However, proponents of BIP322 do not prioritize BCH script compatibility. In order to create an opcode called OP_CHECKDATASIG for the internal purposes of BIP322, a lengthy soft-fork would be required to modify the consensus rules. This raises the question of how Script should verify a single signature on the stack without affecting any inputs or outputs. Several suggestions have been made, including performing key recovery for legacy ECDSA and using specific output scripts to require valid signatures and public keys. Additionally, backward compatibility with Bitcoin Message and the use of opcodes like OP_RESERVED have been discussed, although introducing new opcodes may add unnecessary complexity to the Script.To address these issues, it has been proposed to introduce a hypothetical OP_CHECKDATASIG opcode that can perform ECDSA public key recovery for legacy P2PKH signing. This could be done safely within the BIP. However, in order to ensure compatibility with existing schemes, the opcode would need to be assigned a specific byte, such as OP_CHECKDATASIG. Backward compatibility is crucial, and one possible approach is to use OP_RESERVED to maintain compatibility with "Bitcoin Message". The draft of BIP322 also includes TODO items such as Silent Transactions, limiting eligible opcodes in scriptPubKeys for signing, and delegation to another scriptPubKey. Suggestions have been made, such as placing a NOP at the beginning of the script to activate proof parsing mode and using MAST for delegation.During the discussion on the bitcoin-dev mailing list, user Ali Sherief brought up several TODO items from an older version of the BIP322 draft. These items included addressing the interaction with Silent Transactions, considering whether to introduce an invalid opcode for specific proof types, and finding a solution for delegating to another scriptPubKey. Suggestions were made to limit which opcodes scriptPubKeys can use for signing by placing a NOP at the beginning of the script to activate proof parsing mode. Additionally, a subsection for Silent Transactions could be created to operate using its scriptPubKey. It was also proposed to use MAST with two Merkle branches to specify the original signer's scriptPubKey and delegated signer's scriptPubKey for delegation.BIP322 is still a work in progress, with several TODO items that need to be addressed. The Github issue/PR at https://github.com/bitcoin/bips/pull/1347 has been created to address these items. Ali shared the TODO items from an older version of the draft and suggested limiting the opcodes that scriptPubKeys can sign from, potentially by using a NOP at the beginning of the script. However, it is important to note that an opcode may not be necessary if the program can infer the source of the proof from context. For silent transactions, a suggestion has been made to create a subsection that operates using its scriptPubKey. As for the delegation to another scriptPubKey, the proposal suggests using MAST with two Merkle branches to contain both scriptPubKeys.Overall, the Bitcoin community is actively discussing various solutions to ensure backward compatibility in Bitcoin Scripting language. The lack of certain opcodes, such as OP_CHECKDATASIG, and the need for delegation to another scriptPubKey are being addressed through proposals like MAST and limited opcode usage. However, more documentation and clarification are required to fully understand the motivations behind these requirements and how they will be implemented. diff --git a/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml b/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml index facf8be17a..199b6ae1d5 100644 --- a/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml +++ b/static/bitcoin-dev/Aug_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml @@ -2,7 +2,7 @@ 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2025-09-26T15:35:38.764420+00:00 + 2025-10-11T21:44:41.736663+00:00 python-feedgen Billy Tetrud 2022-08-20 15:30:26+00:00 @@ -230,10 +230,11 @@ + 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2025-09-26T15:35:38.764697+00:00 + 2025-10-11T21:44:41.736936+00:00 2022-08-20T15:30:26+00:00 The context discusses various discussions and debates related to the functioning and security of the Bitcoin network. One aspect discussed is the concept of "free lunches" in the network, where some users benefit without contributing, while others bear the costs. It is argued that this is an unhealthy state for the financial system and may not be sustainable in the long term.One suggestion to address this issue is to remove halvings, which are events that reduce the block reward for miners, if they become destructive to the network's security. It is also mentioned that a balanced system with a low annual inflation rate is preferable to any fiat system. While widespread consensus would be ideal, it is acknowledged that a hard fork may be necessary to implement necessary changes.The feasibility of large Bitcoin holders running ASICs to secure their holdings is also discussed. The assumption is made that fees alone may not compensate for low block rewards, and therefore, large holders may mine at a loss to preserve the value of their holdings. However, it is acknowledged that this approach may not work in practice due to trust issues and the potential for betrayal.The concept of the Prisoner's Dilemma is mentioned in relation to cooperation between Bitcoin users. It is highlighted that even though cooperation may be in the best interest of both parties, mistrust and self-interest can lead to suboptimal outcomes.The importance of transaction fees in providing censorship resistance and incentivizing miners to keep the network secure is emphasized. The discussion explores different approaches, such as tying miner revenue to the total value of Bitcoin or relying solely on transaction fees.There are debates about the business model of miners who intend to censor transactions when there is no block reward. It is argued that transaction fees provide censorship resistance, and miners may prioritize high fee transactions to maximize their earnings.The role of the block reward in the functioning of the Bitcoin network is highlighted. The question is raised about whether a perpetual block subsidy should be tied to the total value of Bitcoin or if other methods should be considered to incentivize miners.The assumption of a constant rate for losses in Bitcoin is challenged, and it is argued that losses can occur at a predictable rate. The potential impact of lost coins on the overall value of Bitcoin is discussed.There are also discussions about the subjective nature of defining Bitcoin and the role of leading bodies versus individual autonomy. The importance of the capped supply and predictable issuance curve is mentioned, and tinkering with the protocol is seen as potentially inviting further subversion.The discussion revolves around the predictability of losses in tail emission. While Peter assumes that there is a rate, it is possible for losses to be at a different predictable rate. However, if there exists any fixed central tendency for the rate, tail emission will eventually become non-inflationary. There are two other factors to consider: firstly, if people improve custody faster than 1/(N(t)*P), tail emission can still be inflationary, although this seems unlikely. Secondly, the rate is somewhat stochastic, with "black swan events" like popular wallet losing keys in coding error being possible but not relevant to tail-emission being non-inflationary. However, even such events can be factored into a fixed central tendency over a long enough time period.In the discussion on whether or not to extend block rewards after the current deadline, it is noted that this is only relevant if the community agrees that it is necessary to maintain network security. It is worth noting that a mild inflation can sometimes be compensated by coin loss, which is like a bonus. The assumption of a constant coin loss rate seems unreasonable as people improve their key storage habits over time, leading to a decrease in the rate of coin loss. Additionally, there may be common causes for coin losses that result in heavily correlated losses rather than independent ones.The conversation further explores the potential implications of tail emission on the ability of individuals to access their coins. Todd clarifies that his proposal does not involve re-assigning ownership of coins and therefore does not take away anyone's ability to access their coins. The concern raised by naman naman about the ability to move coins after a long period of inactivity is addressed, with Todd stating that his article on tail emission is focused on maintaining blockchain security without causing inflation.The latest blog post by Peter Todd titled "Surprisingly, Tail Emission Is Not Inflationary" explores the concept of tail emission and its impact on the supply of Bitcoin. Todd argues that tail emission, which is a fixed reward per block that continues indefinitely, can result in a stable monetary supply rather than a monetarily inflationary one. He explains that lost coins contribute to this stability, as they are constantly being lost due to various factors such as deaths, forgotten passphrases, and accidents.The article also discusses the feasibility of implementing tail emission in Bitcoin. While other currencies like Monero have successfully implemented it, adding tail emission to Bitcoin would require convincing a substantial fraction of the Bitcoin community to support the idea. Todd suggests that diff --git a/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml b/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml index 706fba470f..3d6336742d 100644 --- a/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml +++ b/static/bitcoin-dev/Aug_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml @@ -2,7 +2,7 @@ 2 Combined summary - joinstr: coinjoin implementation using nostr - 2025-09-26T15:35:30.290173+00:00 + 2025-10-11T21:44:33.241483+00:00 python-feedgen alicexbt 2022-09-10 10:17:37+00:00 @@ -26,10 +26,11 @@ + 2 Combined summary - joinstr: coinjoin implementation using nostr - 2025-09-26T15:35:30.290351+00:00 + 2025-10-11T21:44:33.241661+00:00 2022-09-10T10:17:37+00:00 A developer named alicexbt has created a proof-of-concept python script to implement coinjoin using nostr, a decentralized network based on cryptographic keypairs. This implementation utilizes several Bitcoin Core wallet and RPC commands and requires the python-nostr library for coordination between peers. The process involves 5 peers coordinating to create, sign, and broadcast a coinjoin transaction. Each step of the process is published as an event using a nostr relay, and users can use multiple relays simultaneously to avoid trusting a single relay. However, there is a vulnerability of denial of service in the implementation, where a malicious user can register multiple outputs with the same secret, causing an ongoing free denial of service attack without attribution or defense.To address this issue, PR #24058 (basic support BIP-322) can be implemented to add proof of ownership. Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, they can send `txid:out` with a message signed with the address, verify using `verifymessage`, and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO. The cryptographic scheme mentioned as an alternative to blind signatures isn't implemented yet, as it requires a NIP and at least one relay using it.The author plans to continue developing coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. Custom relays are supported by Nostr, examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. The author will run a free and open nostr relay for this project and try to fix the DoS issues before a mainnet version is released for the python script (for nerds) and android app (for all users).The email is sent using Proton Mail secure email, and the author invites opinions on the experiment. The email thread is part of the bitcoin-dev mailing list hosted by lists.linuxfoundation.org. The author credits Fiatjaf, Andrew Chow, Jeff Thibault, and existing coinjoin implementations for their contributions. The author also mentions the creation of an Android app for joinstr in the coming week.Overall, the developer's message provides insights into a coinjoin implementation using Nostr, the challenges and limitations of the current system, and potential improvements to make it more secure. The email includes relevant links to GitHub repositories and provides event IDs and a Coinjoin transaction ID for reference. diff --git a/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin-AdamISZ-.xml b/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin-AdamISZ-.xml index 0077b20e48..2b988cf54d 100644 --- a/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin-AdamISZ-.xml +++ b/static/bitcoin-dev/Aug_2023/combined_BIP-for-Serverless-Payjoin-AdamISZ-.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP for Serverless Payjoin (AdamISZ) - 2025-09-26T14:27:42.358474+00:00 + 2025-10-11T21:49:11.758498+00:00 python-feedgen Christopher Allen 2023-08-12 01:05:06+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - BIP for Serverless Payjoin (AdamISZ) - 2025-09-26T14:27:42.358638+00:00 + 2025-10-11T21:49:11.758649+00:00 2023-08-12T01:05:06+00:00 The email discusses the interest in standardizing a protocol. The sender suggests using base64url encoding instead of base64 encoding for the psk in the URI to improve readability and avoid complexity. They express appreciation for feedback from "waxwing" and mention that they have resolved the mentioned flaws. The sender explains their decision to use a symmetric key over DH for receiver authentication to avoid additional communication rounds. They propose a solution to mitigate attacks by having the receiver share a public key of a per-request keypair. They mention the use of BIP 47 codes and ephemeral keys for enrolling multiple buffers at a relay simultaneously. The sender acknowledges the concern of relays having metadata that could be used for timing attacks and suggests a random delay based on a Poisson distribution as a mitigation. They refer to a research study by S. Ghesmati in 2020 which supports the idea of payjoin transactions. The sender expresses reluctance to require Tor for deployment and suggests considering Oblivious HTTP instead. They address the concern of timing correlation attacks and suggest a specified delay. The sender agrees that padding should be a requirement and discusses the buffer size, noting the overhead of PSBTs compared to consensus transactions. They thank the recipient, Dan, for the feedback. diff --git a/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-.xml b/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-.xml index c74a2acb1c..367dfdeebf 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Concern about "Inscriptions" - 2025-09-26T14:27:27.419078+00:00 + 2025-10-11T21:49:07.510978+00:00 python-feedgen vjudeu at gazeta.pl 2023-09-06 08:00:53+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - Concern about "Inscriptions" - 2025-09-26T14:27:27.419263+00:00 + 2025-10-11T21:49:07.511136+00:00 2023-09-06T08:00:53+00:00 The email thread discusses the concept of cut-through transactions in the Bitcoin blockchain. Cut-through involves removing inscriptions from transaction chains while preserving the payment information. It is argued that cut-through is useful for scaling when there are only a few transactions, but it becomes less efficient when all transactions need to be included. The idea of implementing cut-through is seen as a natural consequence of enabling full Replace-By-Fee (RBF) transactions, which would lead to mempool-level batching.The discussion also revolves around the impact of cut-through on inscriptions. While cut-through can prove transaction chains using cryptography, it does not eliminate the presence of transactions in the blockchain. Full archival nodes still contain all the inscription data and can provide it to those who need it. It is compared to running pruned nodes in Bitcoin, where some nodes do not store all the data but can still access it from full archival nodes.Another topic brought up in the email thread is the suggestion of reducing the blocksize limit to address concerns about blockchain size increases and promote activity on the lightning network. It is proposed that the blocksize limit may have been increased unnecessarily in the past, and now it is worth considering a smaller blocksize to encourage more usage of the lightning network. The lightning network is seen as a potential solution to handle increased transaction volume while minimizing the growth of the blockchain.Inefficiencies and costs related to proof-of-secret-key schemes are also discussed. It is mentioned that reusing k values in ECDSA allows for data encoding in both k and the entire secret key, which can be exploited for encoding data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging and expensive.The email thread includes discussions on various topics related to the Bitcoin protocol. One of these topics involves adding a proof-of-work requirement to a public key on an open relay server protocol to deter spammers or scammers. The difficulty of embedding information in a public key is mentioned, particularly when considering the need for mobile devices to generate keys quickly.The email also touches on the issue of Bitcoin script exploits and vulnerabilities caused by the insertion of arbitrary data. Two strategies, Ordisrespector and Ordislow, are proposed as potential solutions to address these vulnerabilities. Ordisrespector allows node operators to opt-in to a self-defense mechanism against aggression via inserted arbitrary data, while Ordislow increases the coercion cost of mining entities relative to cooperation cost by delaying block propagation and requiring inserted arbitrary data in blocks.The inefficiency and costliness of proof-of-secret-key schemes are highlighted, with examples of how ECDSA can be exploited to encode data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging.The email thread also delves into the topic of inscription attacks and spam prevention in the Mimblewimble protocol. It is noted that range proofs in the protocol already prove knowledge of blinding factors in Pedersen commitments, eliminating the need for additional padding to prevent the encoding of spam. Pure Mimblewimble blockchains are seen as highly resistant to inscription and spam attacks.There is a mention of a project called STAMPS that embeds image data in multisig outputs, which increases the size of the UTXO set compared to other methods. Pay-to-Contact protocols are suggested as a way to tweak a pubkey with a small blob of data, allowing for the production of a signature proving knowledge of the private key.The email raises concerns about banning arbitrary data in programming and its consequences. It is argued that if arbitrary data is banned, actors will find ways to encode their data within sets of public keys. Public key data is indistinguishable from random data, making it difficult to determine if a given public key is used for encoding data or serving its intended purpose. Examples of how governments attempt to censor internet protocols and users adapt by tunneling their data through innocent-looking channels are mentioned.The email also mentions the ongoing struggle between decentralization and centralization in the Bitcoin system. It is suggested that incrementing the cost of operating a regular Bitcoin node could lead to reduced network decentralization and vulnerability to central entity control. The central entity does not necessarily have to be a government.Overall, the email thread covers various discussions related to block sizes, blockchain size increases, lightning network usage, proof-of-secret-key schemes, inscription attacks, spam prevention, and the struggle between decentralization and centralization in the Bitcoin system. diff --git a/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml b/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml index f73ea10f85..75e697b6d4 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Concern about "Inscriptions". (ashneverdawn) - 2025-09-26T14:27:12.431601+00:00 + 2025-10-11T21:49:03.260143+00:00 python-feedgen Keagan McClelland 2023-08-02 05:58:53+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Concern about "Inscriptions". (ashneverdawn) - 2025-09-26T14:27:12.431778+00:00 + 2025-10-11T21:49:03.260298+00:00 2023-08-02T05:58:53+00:00 The debate revolves around introducing a pricing mechanism for space in the Unspent Transaction Output (UTXO) set. Currently, the UTXO set space is not priced, which causes uncertainty in classifying transactions as spam or legitimate. The UTXO set must be maintained by all nodes, including pruned nodes, making it more valuable than chain space. Introducing a pricing mechanism may lead to inscriptions disappearing as users would have to pay for their usage. However, this proposition may be controversial and offensive to some Bitcoin users. Pricing space in the UTXO set remains an open discussion. It is argued that differentiating transaction types on the network should not be done for privacy and censorship resistance. Limited blockchain resources should go to the highest bidder, based on the value they provide to the marketplace against the cost to the network. The growth rate of the blockchain is not caused by Ordinals, but rather by the limit on storage that can be added per block. diff --git a/static/bitcoin-dev/Aug_2023/combined_Full-RBF-testing-at-least-31-of-hash-power-over-at-least-4-pools-is-mining-full-RBF-right-now.xml b/static/bitcoin-dev/Aug_2023/combined_Full-RBF-testing-at-least-31-of-hash-power-over-at-least-4-pools-is-mining-full-RBF-right-now.xml index 0837f5005a..521089aaa2 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Full-RBF-testing-at-least-31-of-hash-power-over-at-least-4-pools-is-mining-full-RBF-right-now.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Full-RBF-testing-at-least-31-of-hash-power-over-at-least-4-pools-is-mining-full-RBF-right-now.xml @@ -2,7 +2,7 @@ 2 Combined summary - Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now - 2025-09-26T14:27:29.564791+00:00 + 2025-10-11T21:49:09.633887+00:00 python-feedgen Peter Todd 2023-08-16 14:02:41+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now - 2025-09-26T14:27:29.564938+00:00 + 2025-10-11T21:49:09.634027+00:00 2023-08-16T14:02:41+00:00 The email provides an update on the testing of high-fee full-RBF (Replace-by-Fee) adoption. The sender has been conducting tests by sending a high fee transaction (tx1) followed by a double spend (tx2) with an even higher fee, removing one of tx1's outputs. The propagation of each full-RBF double-spend was verified by checking the debug.log on another well-connected node.The results show that over 31% of hash power, from at least 4 different pools, is currently mining full-RBF. This finding confirms the sender's previous research based on the OTS (One-Time-Signature) calendar. The sender successfully performed full-RBF double-spends on multiple pools, including Antpool, Poolin, EMCDPool, and Binance Pool.To verify these double-spends, anyone running a full-RBF node with debug=mempool can examine their debug.log files. It is likely that Antpool, Poolin, and EMCDPool are mining full-RBF with close to 100% of their hash power, as they mined every double-spend available to them. Binance Pool, however, did not mine a full-RBF replacement on two occasions, suggesting they may be mining full-RBF with less than 100% of their hash power.In addition to the mentioned pools, KuCoinPool and ULTIMUSPOOL were found to be mining full-RBF double-spends in the sender's earlier OTS research. No data was obtained on them during this specific testing. Luxor and MARA Pool also mined blocks without mining the double-spends, indicating that they may have full-RBF fully or partially disabled.The sender provides a link to the tool used for these tests, cautioning that it was written years ago and may have bugs. The tool can be found at: https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.pyThe email concludes by mentioning the probability of success in a naive high-fee/higher-fee double-spend and highlights that research like this is time-consuming and expensive. Donations are appreciated, and the sender provides options for donating via Lightning or on-chain transactions.References:1) https://github.com/bitcoin/bitcoin/pull/281322) https://petertodd.orgDonation addresses: Lightning - https://stacker.news/petertodd, On-chain - 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv diff --git a/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml b/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml index 3820364729..4ad2182ff7 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml @@ -2,7 +2,7 @@ 2 Combined summary - Pull-req to enable Full-RBF by default - 2025-09-26T14:27:25.273602+00:00 + 2025-10-11T21:49:05.385089+00:00 python-feedgen Peter Todd 2023-08-03 12:46:40+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - Pull-req to enable Full-RBF by default - 2025-09-26T14:27:25.273740+00:00 + 2025-10-11T21:49:05.385251+00:00 2023-08-03T12:46:40+00:00 The claim that "trxs activity" is meaningless without demonstrating reliance on unconfirmed transaction acceptance is being challenged. The commenter questions the credibility of GAP600's offering of a "real-time risk engine" and "instant deposits & payments" without testing full-replace-by-fee (full-rbf) adoption themselves. They provide examples of transactions that were part of chains of replacements and question how these transactions are getting mined. The commenter requests the names of merchants using GAP600's claimed service to verify their reliance on unconfirmed transactions. They also mention reaching out to changelly.com for confirmation of their use of GAP600 but have yet to receive a response.GAP600 responds by stating they do not conduct specific assessments or research on hashing pools and that client confidentiality prevents them from disclosing their clients' names. They suggest contacting Max from Coinpaid for confirmation of their use of GAP600. They also mention that Changelly may not have fully implemented their service across all offerings. They provide contact details for further inquiries.In response to the commenter's assessment, GAP600 defends their honesty and offers evidence of their position. They state that they have provided clear access to clients to verify their statistics and offer a solution for validating full RBF adoption. They argue that the commenter's conclusions are unfounded.The author challenges the credibility of the claim that merchants relying on unconfirmed transactions exist and asks for concrete examples to support this assertion. They have reached out to Coinspaid and Changelly for confirmation but are awaiting a reply. They also query the specific services offered by Changelly that depend on unconfirmed transactions and inquire about the risk criteria set by GAP600. They suggest conducting test transactions if provided with the necessary information but refuse to provide transaction hashes to protect account owners. They question the lack of specific examples of affected businesses and dismiss payment processors as irrelevant. They mention instances of mining pools being harassed and decline to share private contact information. They suggest that if the service in question truly offered an unconfirmed transaction guarantee, they would have ample data on pools practicing full-rbf.The author provides evidence that there are no genuine examples of actual merchants accepting unconfirmed transactions. They mention that Changelly explicitly states that they do not accept unconfirmed payments. They request an example of an actual merchant accepting unconfirmed transactions.GAP600 provides statistics and feedback from Coinspaid to support their claims. They argue that the lack of impact on double spend rates suggests that the adoption of full RBF by miners is questionable. They mention that they reimburse clients for incorrect predictions of double spends. They clarify that they are not a payment processor but provide services to payment processors, merchants, and non-custodial liquidity providers.The author discusses the implementation of full Replace-By-Fee (RBF) in Bitcoin transactions and its potential negative impact on merchants and users who accept 0-conf transactions. They mention mitigation tools like GAP600 that require replacement transactions to include the original outputs. They provide statistics on the usage of GAP600 and mention their clients. They argue that the addition of a "first seen safe" rule is crucial to avoid negative consequences.The author of the context has submitted a pull request to enable full-rbf by default in Bitcoin Core. They mention several block explorers, nodes, and wallets that have enabled full-rbf. They argue that enabling full-rbf by default will address the issue of a minority of nodes relaying full-rbf replacements. They mention opposition from Bitrefill but found no evidence that they still accept unconfirmed transactions. They propose enabling full-rbf by default in Bitcoin Core and deprecating and removing BIP125 code in future releases. The context includes references to support the points made. diff --git a/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-remove-the-arbitrary-limits-on-OP-Return-outputs.xml b/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-remove-the-arbitrary-limits-on-OP-Return-outputs.xml index ad2a58245a..ba94052540 100644 --- a/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-remove-the-arbitrary-limits-on-OP-Return-outputs.xml +++ b/static/bitcoin-dev/Aug_2023/combined_Pull-req-to-remove-the-arbitrary-limits-on-OP-Return-outputs.xml @@ -2,7 +2,7 @@ 2 Combined summary - Pull-req to remove the arbitrary limits on OP_Return outputs - 2025-09-26T14:27:46.618212+00:00 + 2025-10-11T21:49:13.881776+00:00 python-feedgen Murch 2023-08-09 13:06:49+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Pull-req to remove the arbitrary limits on OP_Return outputs - 2025-09-26T14:27:46.618344+00:00 + 2025-10-11T21:49:13.881904+00:00 2023-08-09T13:06:49+00:00 The email discusses the use of OP_RETURN in the blockchain and its impact on full node operators. It seeks clarification on whether using OP_RETURN or segwit/taproot witness space would result in fewer bytes on the blockchain, specifically for small inscriptions. The writer also asks about the prunability of OP_RETURN outputs and if there are tools available for full node operators to prune this data. They mention PR 2791 by Pieter Wuille, which implements pruning of provably-unspendable outputs, including OP_RETURN outputs.The email further asks about the default setting and enabling/disabling options for unspendable output pruning. It inquires about the potential impact of pruning OP_RETURN outputs on new nodes during initial block download (IBD) and whether it would differ for pruning Taproot witness space. The author seeks clarification on the policy change's impact on full node operators, the prunability of OP_RETURN outputs, and the consequences of pruning on assisting new nodes during IBD.Sjors Provoost suggested sending an email to notify their intention of merging a pull-request that removes restrictions on OP_RETURN outputs. The rationale behind this proposal is to potentially eliminate transaction pinning vectors. The author acknowledges the concern but argues that it is a potential issue with any relaxation of standardness rules. The email provides links to further information on transaction pinning from the Bitcoin Operations Guide and Peter Todd's website. diff --git a/static/bitcoin-dev/Dec_2012/combined_BIP-32-HD-wallets-accounts-should-be-labels-not-numbers.xml b/static/bitcoin-dev/Dec_2012/combined_BIP-32-HD-wallets-accounts-should-be-labels-not-numbers.xml index 9044be346b..d2e6e410c9 100644 --- a/static/bitcoin-dev/Dec_2012/combined_BIP-32-HD-wallets-accounts-should-be-labels-not-numbers.xml +++ b/static/bitcoin-dev/Dec_2012/combined_BIP-32-HD-wallets-accounts-should-be-labels-not-numbers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 32 HD wallets, accounts should be labels not numbers - 2023-08-01T04:20:44.419452+00:00 + 2025-10-11T22:02:45.985876+00:00 + python-feedgen Pieter Wuille 2012-12-03 20:44:40+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP 32 HD wallets, accounts should be labels not numbers - 2023-08-01T04:20:44.419452+00:00 + 2025-10-11T22:02:45.986033+00:00 - In a conversation on December 3rd, 2012, Amir Taaki raised the topic of serializing points using a compressed format before hashing. Pieter Wuille responded by stating that there is no longer a need to encourage uncompressed public keys in the network as they take up more space in the blockchain without providing any additional value. He suggested that software can continue to support uncompressed keys for compatibility purposes, but it makes sense for a new standard to standardize on compressed keys. Wuille also emphasized that software should use the compressed encoding within the derivation scheme itself as there is no reason to use a different encoding. He explained that the encoding involves using 0x02 or 0x03 (depending on the parity of Y) followed by the 32-byte encoding of X. While decoding compressed public keys is slightly more complex, it is only necessary when importing an extended public key for watch-only wallets.In an email exchange between Pieter Wuille and Amir Taaki on December 3, 2012, the discussion revolved around hashed point serialization. The focus was on the compressed format used prior to the hash function, which one party found confusing. It was noted that secp256k1 is a prime field, where X has an octet string of 32 bytes (using q = curve.order) following step 2.2.1. The original email from Taaki was sent to bitcoin-development at lists.sourceforge.net and suggested labeling accounts instead of numbering them in BIP 32 HD wallets. Wuille responded by explaining that assigning incrementing numbers to accounts allows for detecting new accounts during disaster recovery. While he acknowledged the suggestion, he stated that allowing "non-standard derivations" using arbitrary strings could be added if recoverability is not a concern.In their 2012 email correspondence, Pieter Wuille, a Bitcoin Core developer, and Amir Taaki discussed the idea of allowing users to input labels instead of numbers for categorizing accounts in wallets. Taaki argued that using labels would be more practical and intuitive, while still allowing for incrementing numbers if desired. Wuille explained that the current system assigns numbers to accounts for disaster recovery purposes and detecting new accounts. He suggested the addition of "non-standard derivations" using arbitrary strings as long as it does not compromise recoverability.Overall, the suggestion is to modify the existing system to allow for the input of general category names instead of numbers when categorizing accounts. The argument is that using labels is more user-friendly while still accommodating the use of incrementing numbers if needed. 2012-12-03T20:44:40+00:00 + In a conversation on December 3rd, 2012, Amir Taaki raised the topic of serializing points using a compressed format before hashing. Pieter Wuille responded by stating that there is no longer a need to encourage uncompressed public keys in the network as they take up more space in the blockchain without providing any additional value. He suggested that software can continue to support uncompressed keys for compatibility purposes, but it makes sense for a new standard to standardize on compressed keys. Wuille also emphasized that software should use the compressed encoding within the derivation scheme itself as there is no reason to use a different encoding. He explained that the encoding involves using 0x02 or 0x03 (depending on the parity of Y) followed by the 32-byte encoding of X. While decoding compressed public keys is slightly more complex, it is only necessary when importing an extended public key for watch-only wallets.In an email exchange between Pieter Wuille and Amir Taaki on December 3, 2012, the discussion revolved around hashed point serialization. The focus was on the compressed format used prior to the hash function, which one party found confusing. It was noted that secp256k1 is a prime field, where X has an octet string of 32 bytes (using q = curve.order) following step 2.2.1. The original email from Taaki was sent to bitcoin-development at lists.sourceforge.net and suggested labeling accounts instead of numbering them in BIP 32 HD wallets. Wuille responded by explaining that assigning incrementing numbers to accounts allows for detecting new accounts during disaster recovery. While he acknowledged the suggestion, he stated that allowing "non-standard derivations" using arbitrary strings could be added if recoverability is not a concern.In their 2012 email correspondence, Pieter Wuille, a Bitcoin Core developer, and Amir Taaki discussed the idea of allowing users to input labels instead of numbers for categorizing accounts in wallets. Taaki argued that using labels would be more practical and intuitive, while still allowing for incrementing numbers if desired. Wuille explained that the current system assigns numbers to accounts for disaster recovery purposes and detecting new accounts. He suggested the addition of "non-standard derivations" using arbitrary strings as long as it does not compromise recoverability.Overall, the suggestion is to modify the existing system to allow for the input of general category names instead of numbers when categorizing accounts. The argument is that using labels is more user-friendly while still accommodating the use of incrementing numbers if needed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2012/combined_Chain-dust-mitigation-Demurrage-based-Chain-Vacuuming.xml b/static/bitcoin-dev/Dec_2012/combined_Chain-dust-mitigation-Demurrage-based-Chain-Vacuuming.xml index 90246f5337..7c11bacf89 100644 --- a/static/bitcoin-dev/Dec_2012/combined_Chain-dust-mitigation-Demurrage-based-Chain-Vacuuming.xml +++ b/static/bitcoin-dev/Dec_2012/combined_Chain-dust-mitigation-Demurrage-based-Chain-Vacuuming.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Chain dust mitigation: Demurrage based Chain Vacuuming - 2023-08-01T04:20:24.993475+00:00 + 2025-10-11T22:02:37.488363+00:00 + python-feedgen Andy Parkins 2012-12-04 09:54:38+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Chain dust mitigation: Demurrage based Chain Vacuuming - 2023-08-01T04:20:24.994508+00:00 + 2025-10-11T22:02:37.488563+00:00 - The increasing amount of "dust" in the blockchain has sparked discussions on finding a solution. Currently, 11% of unspent transaction outputs (UTXO) are 1 satoshi and 32% are less than 0.0001 BTC. This issue is mainly caused by transactions from Satoshi Dice. However, these small payments can accumulate and potentially congest the blockchain, while the associated fees make it expensive to remove them.To address this problem, a proposal suggests implementing demurrage as a means to recycle small amounts over time. Under this system, UTXOs would age out if not re-transacted, with smaller coins aging faster. For example, coins ranging from 1-99 satoshis would live for 210 blocks, while amounts greater than 1 BTC would persist indefinitely. This approach would also affect colored coins by imposing lifetimes on them.By including aged coins in block mining rewards, this recycling scheme would provide an additional incentive for miners. Consequently, no coins would be lost permanently. However, concerns have been raised about the need to re-transact coins to protect them from vultures. This concern may lead to people frantically sending coins to themselves, inadvertently expanding the blockchain rather than reducing its growth. Others have expressed disagreement with imposing hard limits and value judgments within the protocol.In a 2012 email exchange between Michael Gronager and Pieter Wuille, they debated the possibility of changing Bitcoin's policy. Gronager argued that implementing changes without proper planning would contradict users' initial expectations. He believed that any policy change would require a hard fork, necessitating 1-2 years of planning. On the other hand, Wuille disagreed, stating that miners only have control over transaction order and do not determine validity rules. Rules preventing double spending and monetary inflation intentionally exclude miner influence.The author of the post shares concerns about changing Bitcoin's policy, as it may deviate from users' original expectations. They also recognize that implementing a change would require significant planning, potentially years in advance, and necessitate a hard fork. Additionally, the author acknowledges that the economic landscape of Bitcoin may undergo substantial changes during this time.However, the author supports adjusting the mining policy to prioritize transactions that reduce the number of UTXOs. They propose modifying the relay fee so that transactions increasing the number of UTXOs incur an additional cost, while those reducing it pay less. This approach could combat dust spam and control UTXO growth. The author argues against penalizing clients for eliminating dust and suggests automatic rewriting of client software to facilitate this process.In summary, the amount of dust in the blockchain is increasing, with a significant portion of UTXOs consisting of small amounts. Demurrage has been proposed as a solution to recycle these small amounts over time. While there are concerns about changing Bitcoin's policy and the need for a hard fork, adjusting the mining policy to prioritize reducing the number of UTXOs is seen as a favorable solution. 2012-12-04T09:54:38+00:00 + The increasing amount of "dust" in the blockchain has sparked discussions on finding a solution. Currently, 11% of unspent transaction outputs (UTXO) are 1 satoshi and 32% are less than 0.0001 BTC. This issue is mainly caused by transactions from Satoshi Dice. However, these small payments can accumulate and potentially congest the blockchain, while the associated fees make it expensive to remove them.To address this problem, a proposal suggests implementing demurrage as a means to recycle small amounts over time. Under this system, UTXOs would age out if not re-transacted, with smaller coins aging faster. For example, coins ranging from 1-99 satoshis would live for 210 blocks, while amounts greater than 1 BTC would persist indefinitely. This approach would also affect colored coins by imposing lifetimes on them.By including aged coins in block mining rewards, this recycling scheme would provide an additional incentive for miners. Consequently, no coins would be lost permanently. However, concerns have been raised about the need to re-transact coins to protect them from vultures. This concern may lead to people frantically sending coins to themselves, inadvertently expanding the blockchain rather than reducing its growth. Others have expressed disagreement with imposing hard limits and value judgments within the protocol.In a 2012 email exchange between Michael Gronager and Pieter Wuille, they debated the possibility of changing Bitcoin's policy. Gronager argued that implementing changes without proper planning would contradict users' initial expectations. He believed that any policy change would require a hard fork, necessitating 1-2 years of planning. On the other hand, Wuille disagreed, stating that miners only have control over transaction order and do not determine validity rules. Rules preventing double spending and monetary inflation intentionally exclude miner influence.The author of the post shares concerns about changing Bitcoin's policy, as it may deviate from users' original expectations. They also recognize that implementing a change would require significant planning, potentially years in advance, and necessitate a hard fork. Additionally, the author acknowledges that the economic landscape of Bitcoin may undergo substantial changes during this time.However, the author supports adjusting the mining policy to prioritize transactions that reduce the number of UTXOs. They propose modifying the relay fee so that transactions increasing the number of UTXOs incur an additional cost, while those reducing it pay less. This approach could combat dust spam and control UTXO growth. The author argues against penalizing clients for eliminating dust and suggests automatic rewriting of client software to facilitate this process.In summary, the amount of dust in the blockchain is increasing, with a significant portion of UTXOs consisting of small amounts. Demurrage has been proposed as a solution to recycle these small amounts over time. While there are concerns about changing Bitcoin's policy and the need for a hard fork, adjusting the mining policy to prioritize reducing the number of UTXOs is seen as a favorable solution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2012/combined_Has-anyone-compiled-under-MacOS-10-8-.xml b/static/bitcoin-dev/Dec_2012/combined_Has-anyone-compiled-under-MacOS-10-8-.xml index be6a69091a..545873d5a7 100644 --- a/static/bitcoin-dev/Dec_2012/combined_Has-anyone-compiled-under-MacOS-10-8-.xml +++ b/static/bitcoin-dev/Dec_2012/combined_Has-anyone-compiled-under-MacOS-10-8-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Has anyone compiled under MacOS 10.8? - 2023-08-01T04:06:56.186547+00:00 + 2025-10-11T22:02:54.490127+00:00 + python-feedgen Mike Hearn 2012-12-27 16:28:59+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Has anyone compiled under MacOS 10.8? - 2023-08-01T04:06:56.186547+00:00 + 2025-10-11T22:02:54.490298+00:00 - The problem of Boost not playing nicely with default build instructions has resurfaced. It appears that there may be a compatibility issue between Boost and the default build instructions, possibly due to a switch to clang++. To address this, a magic incantation needs to be added at the top, possibly related to how qmake is being used. Running qmake like "gmake -spec macx-g++" can generate a real makefile instead of an xcode project. However, this may make gcc stricter than intended.In a related email, Mike Hearn discovered that the issue was caused by using an older version of the Qt SDK with the new MacOS version. Reinstalling Qt resolved the problem for him. However, he also mentioned that he had previously requested assistance in finding a solution, as he was unable to investigate further at the moment. He specifically asked for someone to share a recipe or solution to fix the issue.In summary, there seems to be an issue with Boost and the default build instructions, potentially related to the switch to clang++. The user who raised the concern plans to investigate further but is currently seeking help from others. They are specifically requesting a recipe or solution to fix the problem and encourage anyone with information to reach out. 2012-12-27T16:28:59+00:00 + The problem of Boost not playing nicely with default build instructions has resurfaced. It appears that there may be a compatibility issue between Boost and the default build instructions, possibly due to a switch to clang++. To address this, a magic incantation needs to be added at the top, possibly related to how qmake is being used. Running qmake like "gmake -spec macx-g++" can generate a real makefile instead of an xcode project. However, this may make gcc stricter than intended.In a related email, Mike Hearn discovered that the issue was caused by using an older version of the Qt SDK with the new MacOS version. Reinstalling Qt resolved the problem for him. However, he also mentioned that he had previously requested assistance in finding a solution, as he was unable to investigate further at the moment. He specifically asked for someone to share a recipe or solution to fix the issue.In summary, there seems to be an issue with Boost and the default build instructions, potentially related to the switch to clang++. The user who raised the concern plans to investigate further but is currently seeking help from others. They are specifically requesting a recipe or solution to fix the problem and encourage anyone with information to reach out. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2012/combined_Multiwallet-support.xml b/static/bitcoin-dev/Dec_2012/combined_Multiwallet-support.xml index 60e1b4c2a6..3424e372e2 100644 --- a/static/bitcoin-dev/Dec_2012/combined_Multiwallet-support.xml +++ b/static/bitcoin-dev/Dec_2012/combined_Multiwallet-support.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Multiwallet support - 2023-08-01T04:23:29.160427+00:00 + 2025-10-11T22:02:50.245843+00:00 + python-feedgen Eric Lombrozo 2012-12-21 18:11:21+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Multiwallet support - 2023-08-01T04:23:29.160427+00:00 + 2025-10-11T22:02:50.245982+00:00 - In a recent conversation, Eric Lombrozo proposed the idea of allowing watch-only addresses in wallets, but mentioned that this would require disabling signing and privkey export operations for watch-only addresses. To integrate this feature into bitcoin, it was suggested that multiple wallet capabilities should be added, allowing users to specify whether a wallet is a full signing wallet or a watch-only wallet upon creation.However, it was acknowledged that exposing multiple wallets via RPC (remote procedure call) could be challenging, as the existing RPC is not designed to support multiple wallets. It was proposed that a separate set of calls should be created, requiring a wallet name and passphrase (if the wallet is encrypted). To avoid breaking compatibility with existing RPC calls, the suggestion was made to have an RPC called "usewallet" that generalizes all the RPCs. Instead of deactivating RPCs that don't make sense, they would simply return an error.The developer also addressed the issue of how rpcs that don't make sense should handle errors. They suggested that these rpcs should return an error instead of being deactivated. Additionally, they mentioned that the "sendtoaddress" function on a watching wallet should return an unsigned raw transaction and a wallet-specific message indicating where to find the private key.In terms of implementation, the developer proposed adding multiple wallet capabilities and allowing users to specify the type of wallet upon creation. Disabling signing and privkey export operations for watch-only addresses is necessary, but the developer noted that disabling them only for some keys in a wallet would complicate the logic of CreateTransaction. Therefore, adding support for multiple wallets is seen as a viable solution.To expose multiple wallets via RPC, the developer acknowledged that a main wallet, which is always used as the default wallet, could be implemented. This would ensure compatibility with existing RPC calls. However, it was emphasized that proposals or suggestions on how to implement these changes are welcome, as breaking compatibility should not hinder the implementation of this desirable feature.Overall, the conversation highlighted the need to add multiple wallet capabilities, specify wallet types upon creation, and address the challenges of exposing multiple wallets via RPC. The developer sought input on how to achieve these goals while maintaining compatibility with existing functionality. 2012-12-21T18:11:21+00:00 + In a recent conversation, Eric Lombrozo proposed the idea of allowing watch-only addresses in wallets, but mentioned that this would require disabling signing and privkey export operations for watch-only addresses. To integrate this feature into bitcoin, it was suggested that multiple wallet capabilities should be added, allowing users to specify whether a wallet is a full signing wallet or a watch-only wallet upon creation.However, it was acknowledged that exposing multiple wallets via RPC (remote procedure call) could be challenging, as the existing RPC is not designed to support multiple wallets. It was proposed that a separate set of calls should be created, requiring a wallet name and passphrase (if the wallet is encrypted). To avoid breaking compatibility with existing RPC calls, the suggestion was made to have an RPC called "usewallet" that generalizes all the RPCs. Instead of deactivating RPCs that don't make sense, they would simply return an error.The developer also addressed the issue of how rpcs that don't make sense should handle errors. They suggested that these rpcs should return an error instead of being deactivated. Additionally, they mentioned that the "sendtoaddress" function on a watching wallet should return an unsigned raw transaction and a wallet-specific message indicating where to find the private key.In terms of implementation, the developer proposed adding multiple wallet capabilities and allowing users to specify the type of wallet upon creation. Disabling signing and privkey export operations for watch-only addresses is necessary, but the developer noted that disabling them only for some keys in a wallet would complicate the logic of CreateTransaction. Therefore, adding support for multiple wallets is seen as a viable solution.To expose multiple wallets via RPC, the developer acknowledged that a main wallet, which is always used as the default wallet, could be implemented. This would ensure compatibility with existing RPC calls. However, it was emphasized that proposals or suggestions on how to implement these changes are welcome, as breaking compatibility should not hinder the implementation of this desirable feature.Overall, the conversation highlighted the need to add multiple wallet capabilities, specify wallet types upon creation, and address the challenges of exposing multiple wallets via RPC. The developer sought input on how to achieve these goals while maintaining compatibility with existing functionality. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2012/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml b/static/bitcoin-dev/Dec_2012/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml index 272cc579b6..4f9c631ed5 100644 --- a/static/bitcoin-dev/Dec_2012/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml +++ b/static/bitcoin-dev/Dec_2012/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol Proposal: Invoices/Payments/Receipts - 2023-08-01T04:10:51.910113+00:00 + 2025-10-11T22:02:39.613802+00:00 + python-feedgen Vezalke 2014-09-17 19:28:08+00:00 @@ -351,13 +352,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol Proposal: Invoices/Payments/Receipts - 2023-08-01T04:10:51.912154+00:00 + 2025-10-11T22:02:39.614077+00:00 - In a series of discussions on the Bitcoin-development mailing list, various topics related to Bitcoin payment protocols were addressed. One discussion focused on the implementation of a "pass around" method, which was considered simpler and easier to implement for experts in the early stages. Another topic discussed was the launch of Crypto-Games.net, an online gambling platform designed specifically for slot machine betting using cryptocurrencies like Bitcoin, Litecoin, and Dogecoin.The need for a secure and private messaging system as the first step in implementing a payment protocol was emphasized by Stephen Pair. A proposal suggested using signed and authenticated "invoices" and "receipts" with X.509 certificates as an identity system for merchants. The proposal also covered multi-signature wallet scenarios and the use of Protocol Buffers as an encoding format.The debate between binary and text formats in the Bitcoin protocol was addressed, with arguments for both sides. The advantages of JSON for accessibility were acknowledged, but concerns were raised about maintaining field order and complexity. The discussion highlighted the lack of compelling arguments for text formats and the need for further research before making a final decision.Other discussions covered topics such as the migration to textual representation, the use of root CAs in the system, and the challenges of confirming the validity of addresses displayed on computer screens. There were also proposals for extending the protocol, handling payment failures, and ensuring the security of paying invoices with Bitcoin.Ensuring consistency and security in Bitcoin transactions is a top priority for sellers. The use of Certificate Authorities (CAs) plays a crucial role in verifying website or server identities and establishing secure connections. In a discussion on November 26, 2012, Mike Hearn emphasized the need for consistency in Bitcoin transactions and suggested supporting all CAs used by popular browsers. However, he expressed a preference for user-accepted certificates at the operating system level to address potential restrictions. The goal was to establish secure communication between users and servers.The limitations of X.509 for the web were also discussed, particularly regarding delegation and the potential undermining of the benefits of chained certificates. To enhance security for payment processors, the proposal suggests issuing a new certificate specifically for signing Bitcoin transactions. It is recommended to redefine the certificate chain part of the protocol to allow for the introduction of new minimal certificate formats with desired features. Compatibility issues may arise for old clients encountering unfamiliar invoice cert types, so the suggestion is made to include a protocol version number when downloading invoices to ensure safe utilization of new invoice features.In addition to certificate discussions, the Bitcoin development community is considering various new features for the digital currency. This includes switching from JSON to a binary format for more efficient and secure data transfer. Another proposed feature is the ability for merchants to cover transaction processing fees. Three potential methods are suggested for implementing this feature, such as adding a 'maxfee' field to the invoice, altering the transaction selection code used by Bitcoin miners, and signing Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag.Another protocol proposal involves utilizing protocol buffer-based formats for signed, authenticated "invoices" and "receipts." Invoices serve as payment requests from merchants to customers and contain outputs specifying where Bitcoins are to be sent. These invoices must include one or more DER-encoded X.509 certificates identifying the merchant, validated according to [RFC5280]. Authenticated identities are linked to invoices, which also include a description of the payment, refund details, and a cryptographically signed receipt that serves as proof-of-payment during disputes with merchants. Merchants will incorporate this proposal into their checkout process, while customers receive SignedInvoice, authorize payment, and create the Payment message, which is then submitted to the site's payment URI.After the payment transaction is validated and broadcasted, a SignedReceipt is returned, indicating either a "You win" or "You lost" memo. The Bitcoin development community is also exploring the possibility of using the Online Certificate Checking Protocol (OCSP) to check for revoked certificates. However, concerns exist regarding the effectiveness of this approach, as it may introduce delays or false-positive rejections if the OCSP endpoint experiences downtime or becomes overwhelmed.Overall, the discussions revolve around improving security and authentication in Bitcoin invoice payments, exploring different identification types, clarifying terminology, and considering alternative approaches to achieve the desired functionality. The Bitcoin development community is actively seeking feedback from other developers to refine these proposals and ensure the continued growth and security of the digital currency. 2014-09-17T19:28:08+00:00 + In a series of discussions on the Bitcoin-development mailing list, various topics related to Bitcoin payment protocols were addressed. One discussion focused on the implementation of a "pass around" method, which was considered simpler and easier to implement for experts in the early stages. Another topic discussed was the launch of Crypto-Games.net, an online gambling platform designed specifically for slot machine betting using cryptocurrencies like Bitcoin, Litecoin, and Dogecoin.The need for a secure and private messaging system as the first step in implementing a payment protocol was emphasized by Stephen Pair. A proposal suggested using signed and authenticated "invoices" and "receipts" with X.509 certificates as an identity system for merchants. The proposal also covered multi-signature wallet scenarios and the use of Protocol Buffers as an encoding format.The debate between binary and text formats in the Bitcoin protocol was addressed, with arguments for both sides. The advantages of JSON for accessibility were acknowledged, but concerns were raised about maintaining field order and complexity. The discussion highlighted the lack of compelling arguments for text formats and the need for further research before making a final decision.Other discussions covered topics such as the migration to textual representation, the use of root CAs in the system, and the challenges of confirming the validity of addresses displayed on computer screens. There were also proposals for extending the protocol, handling payment failures, and ensuring the security of paying invoices with Bitcoin.Ensuring consistency and security in Bitcoin transactions is a top priority for sellers. The use of Certificate Authorities (CAs) plays a crucial role in verifying website or server identities and establishing secure connections. In a discussion on November 26, 2012, Mike Hearn emphasized the need for consistency in Bitcoin transactions and suggested supporting all CAs used by popular browsers. However, he expressed a preference for user-accepted certificates at the operating system level to address potential restrictions. The goal was to establish secure communication between users and servers.The limitations of X.509 for the web were also discussed, particularly regarding delegation and the potential undermining of the benefits of chained certificates. To enhance security for payment processors, the proposal suggests issuing a new certificate specifically for signing Bitcoin transactions. It is recommended to redefine the certificate chain part of the protocol to allow for the introduction of new minimal certificate formats with desired features. Compatibility issues may arise for old clients encountering unfamiliar invoice cert types, so the suggestion is made to include a protocol version number when downloading invoices to ensure safe utilization of new invoice features.In addition to certificate discussions, the Bitcoin development community is considering various new features for the digital currency. This includes switching from JSON to a binary format for more efficient and secure data transfer. Another proposed feature is the ability for merchants to cover transaction processing fees. Three potential methods are suggested for implementing this feature, such as adding a 'maxfee' field to the invoice, altering the transaction selection code used by Bitcoin miners, and signing Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag.Another protocol proposal involves utilizing protocol buffer-based formats for signed, authenticated "invoices" and "receipts." Invoices serve as payment requests from merchants to customers and contain outputs specifying where Bitcoins are to be sent. These invoices must include one or more DER-encoded X.509 certificates identifying the merchant, validated according to [RFC5280]. Authenticated identities are linked to invoices, which also include a description of the payment, refund details, and a cryptographically signed receipt that serves as proof-of-payment during disputes with merchants. Merchants will incorporate this proposal into their checkout process, while customers receive SignedInvoice, authorize payment, and create the Payment message, which is then submitted to the site's payment URI.After the payment transaction is validated and broadcasted, a SignedReceipt is returned, indicating either a "You win" or "You lost" memo. The Bitcoin development community is also exploring the possibility of using the Online Certificate Checking Protocol (OCSP) to check for revoked certificates. However, concerns exist regarding the effectiveness of this approach, as it may introduce delays or false-positive rejections if the OCSP endpoint experiences downtime or becomes overwhelmed.Overall, the discussions revolve around improving security and authentication in Bitcoin invoice payments, exploring different identification types, clarifying terminology, and considering alternative approaches to achieve the desired functionality. The Bitcoin development community is actively seeking feedback from other developers to refine these proposals and ensure the continued growth and security of the digital currency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2012/combined_Roadmap-to-getting-users-onto-SPV-clients.xml b/static/bitcoin-dev/Dec_2012/combined_Roadmap-to-getting-users-onto-SPV-clients.xml index 081de6ad47..12732aadd6 100644 --- a/static/bitcoin-dev/Dec_2012/combined_Roadmap-to-getting-users-onto-SPV-clients.xml +++ b/static/bitcoin-dev/Dec_2012/combined_Roadmap-to-getting-users-onto-SPV-clients.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Roadmap to getting users onto SPV clients - 2023-08-01T04:22:31.690177+00:00 + 2025-10-11T22:02:43.861795+00:00 + python-feedgen Mike Hearn 2012-12-05 10:43:24+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Roadmap to getting users onto SPV clients - 2023-08-01T04:22:31.691177+00:00 + 2025-10-11T22:02:43.861935+00:00 - The discussion revolves around the user experience of SPV clients in the Bitcoin network. The value of a regular user's desktop machine and the risk of slowing down their system when running a full node is considered. It is suggested that having both an SPV client and a full node running in parallel could be a solution for users who want to support the network.The idea of recruiting users to run full nodes through light wallets that notice high uptime and external connectivity is proposed. A one-click install for Windows users to set up a background service for a full node is also suggested. However, it is acknowledged that better heuristics are necessary before automatically opting users in. The Tor analogy is mentioned as an example, but the technical complexity of automatically opting users in has been a challenge. Accurate recommendations are seen as a good starting point before automatic opt-ins.In an email conversation, Gary Rowe discusses the user experience of SPV clients. He emphasizes the importance of an "instant-on" experience with Bitcoin, which SPV clients provide. He believes that a great initial experience with Bitcoin reinforces users' interest and encourages them to explore further.Many users decide to install a full node out of a sense of community contribution to network security. Rowe suggests giving users control over a hybrid mode of SPV first and full node second, as Bitcoin should not be perceived as a drain on their computing resources. He also proposes distributing the client with a recent checkpoint and gradually pulling in more recent blocks to allow the client to work out-of-the-box while synchronizing with the full network.The discussion on the Bitcoin-development mailing list focuses on the user experience of the SPV client, MultiBit. There is an expectation that Bitcoin needs to surpass PayPal and credit cards to gain popularity. SPV clients offer an "instant-on" experience that encourages users to explore the economic theory behind Bitcoin. Many users choose to install a full node to contribute to the network's security. It is suggested that users should have control over using SPV or a full node, as it is their computing resources being used.However, there is a divergence of opinion on the risk of centralization by promoting SPV nodes to new users. Issues faced by users wanting to use Bitcoin are collected from Facebook, including misconceptions about Bitcoin and computer problems. Efforts to improve the Satoshi client's security and user experience are underway, but open-source development may not progress as fast as desired. Concerns regarding poor user experience and synchronization issues are raised.The email thread also discusses various issues related to user feedback and difficulties faced by new users. There is a debate on the risk of centralization by promoting SPV nodes and the importance of full nodes for network security. Efforts to improve the Bitcoin experience with full security model are suggested before considering reduced security model clients. The context mentions a tool called Rescue, which allows IT professionals to remotely access PCs and mobile devices to provide support and improve efficiency. The need for a healthy darknet of private authenticated peerings between miners and other targets to address sybil attackers is mentioned.Jim Nguyen shares user feedback collected from Facebook, highlighting difficulties with understanding Bitcoin's purpose, DEP protection, fees, and synchronization. Gregory Maxwell argues against promoting SPV nodes to new users, citing risks of centralization and the need to maintain a secure network. Wladimir suggests focusing on improving the security and stability of the Satoshi client to enhance the Bitcoin experience. The discussion concludes with a debate on balancing user experience with network security.Alan Reiner and Greg Maxwell express differing opinions on the risk of centralization through promoting SPV nodes to new users. Alan believes there is no real risk if all full nodes are full-validation, while Greg disagrees and highlights DOS attack risks. Alan emphasizes improving the Bitcoin experience without compromising decentralization, while Greg argues against promoting less capable and secure software. The debate centers around balancing user experience with network security.The author discusses the limited time window for marketing initiatives, using Linux desktops as an example. They argue that Bitcoin may have missed its first fad window but could still become the money system infrastructure. The author emphasizes the importance of having as many full nodes as possible for security and references Tor as a successful P2P network with more users than nodes. However, they believe that the trust model in Bitcoin is stronger. The author suggests maximizing investment in keeping the full node software usable and highlights the cost of switching to lite nodes.The writer argues that new ideas have a certain time frame to gain credibility and if they fail to overcome their problems within that time, people move on. They cite desktop Linux as an example of steady improvements but lack of excitement or attention. The author believes that Bitcoin should not go the same way and emphasizes the need to send a clear message to users about supporting the network. They question whether every user needs to run a full node and suggest that the Tor network's success demonstrates that having a vast number of users supported by a smaller number of committed nodes is possible.In a 2012-12-05T10:43:24+00:00 + The discussion revolves around the user experience of SPV clients in the Bitcoin network. The value of a regular user's desktop machine and the risk of slowing down their system when running a full node is considered. It is suggested that having both an SPV client and a full node running in parallel could be a solution for users who want to support the network.The idea of recruiting users to run full nodes through light wallets that notice high uptime and external connectivity is proposed. A one-click install for Windows users to set up a background service for a full node is also suggested. However, it is acknowledged that better heuristics are necessary before automatically opting users in. The Tor analogy is mentioned as an example, but the technical complexity of automatically opting users in has been a challenge. Accurate recommendations are seen as a good starting point before automatic opt-ins.In an email conversation, Gary Rowe discusses the user experience of SPV clients. He emphasizes the importance of an "instant-on" experience with Bitcoin, which SPV clients provide. He believes that a great initial experience with Bitcoin reinforces users' interest and encourages them to explore further.Many users decide to install a full node out of a sense of community contribution to network security. Rowe suggests giving users control over a hybrid mode of SPV first and full node second, as Bitcoin should not be perceived as a drain on their computing resources. He also proposes distributing the client with a recent checkpoint and gradually pulling in more recent blocks to allow the client to work out-of-the-box while synchronizing with the full network.The discussion on the Bitcoin-development mailing list focuses on the user experience of the SPV client, MultiBit. There is an expectation that Bitcoin needs to surpass PayPal and credit cards to gain popularity. SPV clients offer an "instant-on" experience that encourages users to explore the economic theory behind Bitcoin. Many users choose to install a full node to contribute to the network's security. It is suggested that users should have control over using SPV or a full node, as it is their computing resources being used.However, there is a divergence of opinion on the risk of centralization by promoting SPV nodes to new users. Issues faced by users wanting to use Bitcoin are collected from Facebook, including misconceptions about Bitcoin and computer problems. Efforts to improve the Satoshi client's security and user experience are underway, but open-source development may not progress as fast as desired. Concerns regarding poor user experience and synchronization issues are raised.The email thread also discusses various issues related to user feedback and difficulties faced by new users. There is a debate on the risk of centralization by promoting SPV nodes and the importance of full nodes for network security. Efforts to improve the Bitcoin experience with full security model are suggested before considering reduced security model clients. The context mentions a tool called Rescue, which allows IT professionals to remotely access PCs and mobile devices to provide support and improve efficiency. The need for a healthy darknet of private authenticated peerings between miners and other targets to address sybil attackers is mentioned.Jim Nguyen shares user feedback collected from Facebook, highlighting difficulties with understanding Bitcoin's purpose, DEP protection, fees, and synchronization. Gregory Maxwell argues against promoting SPV nodes to new users, citing risks of centralization and the need to maintain a secure network. Wladimir suggests focusing on improving the security and stability of the Satoshi client to enhance the Bitcoin experience. The discussion concludes with a debate on balancing user experience with network security.Alan Reiner and Greg Maxwell express differing opinions on the risk of centralization through promoting SPV nodes to new users. Alan believes there is no real risk if all full nodes are full-validation, while Greg disagrees and highlights DOS attack risks. Alan emphasizes improving the Bitcoin experience without compromising decentralization, while Greg argues against promoting less capable and secure software. The debate centers around balancing user experience with network security.The author discusses the limited time window for marketing initiatives, using Linux desktops as an example. They argue that Bitcoin may have missed its first fad window but could still become the money system infrastructure. The author emphasizes the importance of having as many full nodes as possible for security and references Tor as a successful P2P network with more users than nodes. However, they believe that the trust model in Bitcoin is stronger. The author suggests maximizing investment in keeping the full node software usable and highlights the cost of switching to lite nodes.The writer argues that new ideas have a certain time frame to gain credibility and if they fail to overcome their problems within that time, people move on. They cite desktop Linux as an example of steady improvements but lack of excitement or attention. The author believes that Bitcoin should not go the same way and emphasizes the need to send a clear message to users about supporting the network. They question whether every user needs to run a full node and suggest that the Tor network's success demonstrates that having a vast number of users supported by a smaller number of committed nodes is possible.In a - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2012/combined_String-based-Hierarchical-Deterministic-Keys-Alternative-to-BIP-32.xml b/static/bitcoin-dev/Dec_2012/combined_String-based-Hierarchical-Deterministic-Keys-Alternative-to-BIP-32.xml index 5ab883192a..5da3f10800 100644 --- a/static/bitcoin-dev/Dec_2012/combined_String-based-Hierarchical-Deterministic-Keys-Alternative-to-BIP-32.xml +++ b/static/bitcoin-dev/Dec_2012/combined_String-based-Hierarchical-Deterministic-Keys-Alternative-to-BIP-32.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - String-based Hierarchical Deterministic Keys - Alternative to BIP 32 - 2023-08-01T04:23:03.213535+00:00 + 2025-10-11T22:02:41.738767+00:00 + python-feedgen Gregory Maxwell 2012-12-05 03:50:17+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - String-based Hierarchical Deterministic Keys - Alternative to BIP 32 - 2023-08-01T04:23:03.213535+00:00 + 2025-10-11T22:02:41.738918+00:00 - In an email exchange, Watson Ladd discussed the implications of being able to spend a coin sent to an address generated by a scheme and explained that it implies being able to spend any coin generated by the same scheme. However, having only the plain ecdsa secret is not enough to spend anything but that specific address.Ladd then went on to discuss the construction of deterministic wallets, suggesting that using a stream cipher to generate random bytes for private keys in a wallet is the easiest method. However, he noted that this method does not add any additional benefits other than distinguishing transactions by sending to unique addresses, which could be done through other means.Ladd also mentioned that this type-1 deterministic wallet construction has no ability to separate address generation from spending, which is important for merchant applications and limited privacy properties of the Bitcoin system. He previously referred to this construction as one of the different derivation schemes in a forum post and highlighted BIP32's hope to use a single deterministic wallet construction.In an email conversation between Gregory Maxwell and Mike Koss, Koss proposed a new alternative to the BIP 32 proposal. His proposal was based on a hierarchical string representation, rather than hierarchy of integers as proposed in BIP 32. Koss named keys using this representation style.However, Maxwell pointed out that blindly iterating through strings is not possible, which means that Koss' proposal loses the backup recoverability property of a deterministic wallet. Maxwell also noted that both BIP 32 and Koss' proposal have a missing feature: being able to spend a coin sent to an address generated by this scheme implies being able to spend any coin generated by this scheme.Maxwell suggested that the easiest deterministic wallet construction is simply to use a stream cipher to generate random bytes used as the private keys in a wallet. Additionally, Maxwell mentioned that Koss' extended hierarchy of multipliers made him uncomfortable. On the other hand, the multipliers at each level in BIP 32 are unstructured, but the ones in the next level are products of the ones before. This creates a multiplication tree with random-looking branches.In December 2012, Mike Koss proposed an alternative to the BIP32 proposal for a deterministic wallet system based on a hierarchical string representation. He named keys using a specific format: [hd1.75491111].store.x. Pieter raised concerns that blindly iterating through strings is not realistically possible and could result in losing the backup recoverability property of a deterministic wallet. This means that if a backup is made prior to establishing a new string name, it must also have a reliable backup of the string as well. Furthermore, if the backup of strings is incomplete with the hierarchical string representation, some or all assigned coin may be lost forever.On the other hand, with the BIP32 scheme, backing up a map equating the hdwallet indexes to strings would allow for no loss of coins (only metadata) in the event of a catastrophic loss where only the original ultimate root is left.The author has created an alternative to the BIP 32 proposal, which uses a hierarchical string representation instead of an integer hierarchy. He names keys based on this system and envisions using it in services. The author has not done any work to recommend how keys would be represented directly in the client. The author is looking for feedback on any security concerns with their scheme and whether not introducing the enlarged key space that BIP 32 does represents a weakness of their scheme versus BIP 32. The author is happy to release their source code (Python) but wants to get feedback first.In response to a question about serializing points using a compressed format before going into the hash function, Pieter Wuille suggests standardizing on just compressed keys since they take less space in the blockchain and there is no additional value in uncompressed keys. The software may continue to support uncompressed keys for compatibility, but for a new standard, compressed keys make sense. The encoding itself is not hard, just 0x02 or 0x03 followed by the 32-byte encoding of X. Decoding is harder but is never needed in the derivation. Decoding compressed public keys is somewhat harder as Y must be reconstructed, but this is only necessary when someone wants to import an extended public key for watch-only wallets. 2012-12-05T03:50:17+00:00 + In an email exchange, Watson Ladd discussed the implications of being able to spend a coin sent to an address generated by a scheme and explained that it implies being able to spend any coin generated by the same scheme. However, having only the plain ecdsa secret is not enough to spend anything but that specific address.Ladd then went on to discuss the construction of deterministic wallets, suggesting that using a stream cipher to generate random bytes for private keys in a wallet is the easiest method. However, he noted that this method does not add any additional benefits other than distinguishing transactions by sending to unique addresses, which could be done through other means.Ladd also mentioned that this type-1 deterministic wallet construction has no ability to separate address generation from spending, which is important for merchant applications and limited privacy properties of the Bitcoin system. He previously referred to this construction as one of the different derivation schemes in a forum post and highlighted BIP32's hope to use a single deterministic wallet construction.In an email conversation between Gregory Maxwell and Mike Koss, Koss proposed a new alternative to the BIP 32 proposal. His proposal was based on a hierarchical string representation, rather than hierarchy of integers as proposed in BIP 32. Koss named keys using this representation style.However, Maxwell pointed out that blindly iterating through strings is not possible, which means that Koss' proposal loses the backup recoverability property of a deterministic wallet. Maxwell also noted that both BIP 32 and Koss' proposal have a missing feature: being able to spend a coin sent to an address generated by this scheme implies being able to spend any coin generated by this scheme.Maxwell suggested that the easiest deterministic wallet construction is simply to use a stream cipher to generate random bytes used as the private keys in a wallet. Additionally, Maxwell mentioned that Koss' extended hierarchy of multipliers made him uncomfortable. On the other hand, the multipliers at each level in BIP 32 are unstructured, but the ones in the next level are products of the ones before. This creates a multiplication tree with random-looking branches.In December 2012, Mike Koss proposed an alternative to the BIP32 proposal for a deterministic wallet system based on a hierarchical string representation. He named keys using a specific format: [hd1.75491111].store.x. Pieter raised concerns that blindly iterating through strings is not realistically possible and could result in losing the backup recoverability property of a deterministic wallet. This means that if a backup is made prior to establishing a new string name, it must also have a reliable backup of the string as well. Furthermore, if the backup of strings is incomplete with the hierarchical string representation, some or all assigned coin may be lost forever.On the other hand, with the BIP32 scheme, backing up a map equating the hdwallet indexes to strings would allow for no loss of coins (only metadata) in the event of a catastrophic loss where only the original ultimate root is left.The author has created an alternative to the BIP 32 proposal, which uses a hierarchical string representation instead of an integer hierarchy. He names keys based on this system and envisions using it in services. The author has not done any work to recommend how keys would be represented directly in the client. The author is looking for feedback on any security concerns with their scheme and whether not introducing the enlarged key space that BIP 32 does represents a weakness of their scheme versus BIP 32. The author is happy to release their source code (Python) but wants to get feedback first.In response to a question about serializing points using a compressed format before going into the hash function, Pieter Wuille suggests standardizing on just compressed keys since they take less space in the blockchain and there is no additional value in uncompressed keys. The software may continue to support uncompressed keys for compatibility, but for a new standard, compressed keys make sense. The encoding itself is not hard, just 0x02 or 0x03 followed by the 32-byte encoding of X. Decoding is harder but is never needed in the derivation. Decoding compressed public keys is somewhat harder as Y must be reconstructed, but this is only necessary when someone wants to import an extended public key for watch-only wallets. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2012/combined_Testnet3-difficulty-transition-problem-.xml b/static/bitcoin-dev/Dec_2012/combined_Testnet3-difficulty-transition-problem-.xml index aa72a1fcb9..5fa9878e19 100644 --- a/static/bitcoin-dev/Dec_2012/combined_Testnet3-difficulty-transition-problem-.xml +++ b/static/bitcoin-dev/Dec_2012/combined_Testnet3-difficulty-transition-problem-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Testnet3 difficulty transition problem? - 2023-08-01T04:23:44.785221+00:00 + 2025-10-11T22:02:52.367426+00:00 + python-feedgen Mike Hearn 2012-12-24 16:21:26+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Testnet3 difficulty transition problem? - 2023-08-01T04:23:44.786222+00:00 + 2025-10-11T22:02:52.367640+00:00 - In a team setting, someone confidently stated "I pushed a fix for this", indicating that they have successfully resolved an unidentified issue or bug related to software or program. The term "pushed a fix" suggests that the solution was implemented through a version control system like Git. It is unclear what exactly the problem was, but the fact that it was identified and addressed promptly is crucial for smooth system operation.On December 22, 2012, Andreas Schildbach raised a query regarding two blocks with difficulty transitions. Block 40320 had a difficulty of 1, which seemed exceptional to Schildbach as he believed this exception could not be applied to difficulty transition blocks. However, he was informed that the difficulty change is relative to the prior block's difficulty. If the penultimate block in the difficulty cycle falls under the special rule, the difficulty change will be relative to 1. This clarifies the understanding of the relationship between difficulty transitions and the special rule.Additionally, it was mentioned that a timewarp attack had been introduced to the testnet chain, but intentionally avoided as a test case in case adjustments were needed before the release of testnet3. This implies that precautions were taken to address any potential issues or vulnerabilities prior to the official release.Looking specifically at two blocks, block 38304 and block 40320, it is observed that both are difficulty transition blocks. Although these blocks should theoretically be impossible to mine due to their difficulties, block 40320 stands out with a difficulty of 1. This discrepancy in difficulty causes bitcoinj based clients to halt their blockchain progression at block 40319. This indicates that there may be additional rules or exceptions in relation to difficulty transitions that are yet to be fully understood.Overall, the information provided highlights the problem-solving abilities of the individual who pushed the fix, the clarification on difficulty transitions and the special rule, and the cautious approach taken to address potential vulnerabilities in the testnet chain. 2012-12-24T16:21:26+00:00 + In a team setting, someone confidently stated "I pushed a fix for this", indicating that they have successfully resolved an unidentified issue or bug related to software or program. The term "pushed a fix" suggests that the solution was implemented through a version control system like Git. It is unclear what exactly the problem was, but the fact that it was identified and addressed promptly is crucial for smooth system operation.On December 22, 2012, Andreas Schildbach raised a query regarding two blocks with difficulty transitions. Block 40320 had a difficulty of 1, which seemed exceptional to Schildbach as he believed this exception could not be applied to difficulty transition blocks. However, he was informed that the difficulty change is relative to the prior block's difficulty. If the penultimate block in the difficulty cycle falls under the special rule, the difficulty change will be relative to 1. This clarifies the understanding of the relationship between difficulty transitions and the special rule.Additionally, it was mentioned that a timewarp attack had been introduced to the testnet chain, but intentionally avoided as a test case in case adjustments were needed before the release of testnet3. This implies that precautions were taken to address any potential issues or vulnerabilities prior to the official release.Looking specifically at two blocks, block 38304 and block 40320, it is observed that both are difficulty transition blocks. Although these blocks should theoretically be impossible to mine due to their difficulties, block 40320 stands out with a difficulty of 1. This discrepancy in difficulty causes bitcoinj based clients to halt their blockchain progression at block 40319. This indicates that there may be additional rules or exceptions in relation to difficulty transitions that are yet to be fully understood.Overall, the information provided highlights the problem-solving abilities of the individual who pushed the fix, the clarification on difficulty transitions and the special rule, and the cautious approach taken to address potential vulnerabilities in the testnet chain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2012/combined_Zero-length-scripts.xml b/static/bitcoin-dev/Dec_2012/combined_Zero-length-scripts.xml index 786818465b..64722ea6f8 100644 --- a/static/bitcoin-dev/Dec_2012/combined_Zero-length-scripts.xml +++ b/static/bitcoin-dev/Dec_2012/combined_Zero-length-scripts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Zero-length scripts - 2023-08-01T04:23:12.934754+00:00 + 2025-10-11T22:02:48.122803+00:00 + python-feedgen gronager at mac.com 2012-12-13 09:00:55+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Zero-length scripts - 2023-08-01T04:23:12.934754+00:00 + 2025-10-11T22:02:48.122933+00:00 - In block 0000000000000159a27442ee8b7f9ffad0cd799b003eafe007de9fbb47bd6ce7, a user has discovered several transactions that have zero-length input and/or output scripts. One of the transactions in particular stands out as it contains an output script with OP_HASH256 followed by the hash of the genesisblock hash. The significance of this is that if someone can create something that, when hashed with sha256, produces the genesisblock hash, they can claim one BTC.While this task may seem straightforward, non-standard transactions are not relayed between standard clients. Therefore, only miners have the ability to create a transaction that redeems this 1BTC. It is speculated that perhaps Eligius, the entity responsible for creating that specific block, may be engaging in a Christmas game.Eric Lombrozo, upon noticing these transactions, raises questions about their legitimacy. He wonders if the protocol actually allows for the creation of transactions with zero-length scripts. Further investigation into the matter is required to determine whether these transactions adhere to the established rules and regulations of the Bitcoin network. 2012-12-13T09:00:55+00:00 + In block 0000000000000159a27442ee8b7f9ffad0cd799b003eafe007de9fbb47bd6ce7, a user has discovered several transactions that have zero-length input and/or output scripts. One of the transactions in particular stands out as it contains an output script with OP_HASH256 followed by the hash of the genesisblock hash. The significance of this is that if someone can create something that, when hashed with sha256, produces the genesisblock hash, they can claim one BTC.While this task may seem straightforward, non-standard transactions are not relayed between standard clients. Therefore, only miners have the ability to create a transaction that redeems this 1BTC. It is speculated that perhaps Eligius, the entity responsible for creating that specific block, may be engaging in a Christmas game.Eric Lombrozo, upon noticing these transactions, raises questions about their legitimacy. He wonders if the protocol actually allows for the creation of transactions with zero-length scripts. Further investigation into the matter is required to determine whether these transactions adhere to the established rules and regulations of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml b/static/bitcoin-dev/Dec_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml index 9736e9c8e1..a13ca15904 100644 --- a/static/bitcoin-dev/Dec_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml +++ b/static/bitcoin-dev/Dec_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption - 2023-08-01T05:20:12.304613+00:00 + 2025-10-11T21:46:15.296109+00:00 + python-feedgen Jean-Paul Kogelman 2013-12-26 11:48:12+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption - 2023-08-01T05:20:12.304613+00:00 + 2025-10-11T21:46:15.296274+00:00 - Jean-Paul Kogelman has updated a proposal on the Bitcointalk forum, making changes to the checksum and adding support for third-party KDF computation. The full proposal can be found at the provided link. The author of the post states that there have been no recent changes to the proposal, which includes expanding the salt, renaming the 'master seed', adding user-selectable KDF parameters, and a creation date field. They compare their proposal to BIP38 and question whether it could replace it.In response to the proposal, Mike Hearn points out that the proposal is not usable for SPV wallets unless it has a birthday. He suggests adding a UNIX time or a uint16 representing "days since birth of this specification" to solve this issue.The context discusses the usability of SPV wallets and the need for a birthday in order for them to function effectively. Without a birthday, scanning the blockchain can be slow and finding a fully indexed copy of the blockchain can be expensive and centralized. The suggestion is to add a UNIX time or a uint16 to address this problem.The document describes a method for encoding and optionally encrypting a Bitcoin HD Wallet master seed. The proposal provides two encoding methodologies in three lengths each, with one being a clear version and the other an encrypted representation. The proposed method uses various functions such as AES256Encrypt, AES256Decrypt, SHA256, RIPEMD160, scrypt, HMAC-SHA512, Base58Check, G, and N. It also includes test vectors and acknowledgements to related BIPs.In a forum discussion, Jean-Paul Kogelman proposes a Base58 encoded HD wallet master seed with optional encryption. Andreas M. Antonopoulos expresses interest in the proposal and calls it necessary and a great approach. Kogelman asks for feedback on the proposal but mentions that it is not yet in shippable form.The proposal by Jean-Paul Kogelman outlines a method for encoding and encrypting a Bitcoin HD Wallet master seed. It provides a compact representation of the master seed, making it easier to handle. A two-factor version allows for safe storage and creation of paper wallets by third parties. The proposal involves various functions and definitions and suggests modifications to BIP0038. Test vectors are provided, and acknowledgements are given to related BIPs and contributors. 2013-12-26T11:48:12+00:00 + Jean-Paul Kogelman has updated a proposal on the Bitcointalk forum, making changes to the checksum and adding support for third-party KDF computation. The full proposal can be found at the provided link. The author of the post states that there have been no recent changes to the proposal, which includes expanding the salt, renaming the 'master seed', adding user-selectable KDF parameters, and a creation date field. They compare their proposal to BIP38 and question whether it could replace it.In response to the proposal, Mike Hearn points out that the proposal is not usable for SPV wallets unless it has a birthday. He suggests adding a UNIX time or a uint16 representing "days since birth of this specification" to solve this issue.The context discusses the usability of SPV wallets and the need for a birthday in order for them to function effectively. Without a birthday, scanning the blockchain can be slow and finding a fully indexed copy of the blockchain can be expensive and centralized. The suggestion is to add a UNIX time or a uint16 to address this problem.The document describes a method for encoding and optionally encrypting a Bitcoin HD Wallet master seed. The proposal provides two encoding methodologies in three lengths each, with one being a clear version and the other an encrypted representation. The proposed method uses various functions such as AES256Encrypt, AES256Decrypt, SHA256, RIPEMD160, scrypt, HMAC-SHA512, Base58Check, G, and N. It also includes test vectors and acknowledgements to related BIPs.In a forum discussion, Jean-Paul Kogelman proposes a Base58 encoded HD wallet master seed with optional encryption. Andreas M. Antonopoulos expresses interest in the proposal and calls it necessary and a great approach. Kogelman asks for feedback on the proposal but mentions that it is not yet in shippable form.The proposal by Jean-Paul Kogelman outlines a method for encoding and encrypting a Bitcoin HD Wallet master seed. It provides a compact representation of the master seed, making it easier to handle. A two-factor version allows for safe storage and creation of paper wallets by third parties. The proposal involves various functions and definitions and suggests modifications to BIP0038. Test vectors are provided, and acknowledgements are given to related BIPs and contributors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_-unSYSTEM-DarkWallet-Best-Practices.xml b/static/bitcoin-dev/Dec_2013/combined_-unSYSTEM-DarkWallet-Best-Practices.xml index 159727c829..d186b77a86 100644 --- a/static/bitcoin-dev/Dec_2013/combined_-unSYSTEM-DarkWallet-Best-Practices.xml +++ b/static/bitcoin-dev/Dec_2013/combined_-unSYSTEM-DarkWallet-Best-Practices.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [unSYSTEM] DarkWallet Best Practices - 2023-08-01T06:52:57.327609+00:00 + 2025-10-11T21:45:54.046146+00:00 + python-feedgen Taylor Gerring 2013-12-20 17:32:57+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - [unSYSTEM] DarkWallet Best Practices - 2023-08-01T06:52:57.328667+00:00 + 2025-10-11T21:45:54.046293+00:00 - In a discussion about the problems associated with reusing Bitcoin addresses, it was suggested that generating fresh addresses from public extended keys could be a solution that would also enhance user privacy. Instead of exchanging single addresses, the exchange of extended public keys could benefit non-merchant use of Payment Protocol. The challenge lies in how to push the extended public key down to the wallet itself. There are options such as developing services to facilitate this exchange or having wallet software communicate directly through various channels like Bluetooth, AirDrop, email, BitMessage, etc. Another idea mentioned was using extended public keys from bip 32 to share multiple addresses at once, enabling regular payments without needing further addresses and assisting with P2SH where the public key is required. Implementing these ideas has the potential to improve the efficiency and security of Bitcoin transactions.The debate over whether or not to sign every commit has been extensively covered. Linus Torvalds advises against signing each commit, but Peter Todd argues that per-commit signatures are necessary due to reliance on third-party sites like Github within the Bitcoin community. The Linux development model differs from Bitcoin's, using mailing lists and trusted maintainers committing to personal trees on secure computers. Eventually, patches are merged into a release tag, which is signed. Bitcoin developers often get code directly from Github and rely on per-commit signatures for authenticity. Todd believes the focus should be on the messaging layer, suggesting the use of OpenPGP and SSL certificate authorities instead of creating new identity systems that increase the risk of MITM attacks.In an email correspondence, Mike suggests splitting multi-sig and multi-factor authentication into two separate categories. He emphasizes the value of multi-factor user authentication and distinguishes it from multi-factor signing, which adds another level of complexity. Mike proposes that wallets should require multi-factor authentication before granting access and before signing a transaction. Regarding multi-factor signing, he acknowledges that it may be too early to define but suggests that wallets should not create two keys on a single host or device and provide a way to import external public keys for use in P2SH addresses. Mike also brings up a small word-choice nit, mentioning that he had to look up the meaning of "SHALL" (which he now knows is the same as MUST). In an unrelated topic, Drak mentions that Linus advises against signing each commit and suggests incorporating his recommendation for signing tags with `git tag -s` into the spec as a MUST.On December 19, 2013, Amir Taaki shared a link about signing each commit. Linus had advised against it, but upon reading the link, it was found that his advice did not make sense. However, Drak's response suggests that Linus's recommendation for signing tags with `git tag -s` should be included in the spec as a MUST. 2013-12-20T17:32:57+00:00 + In a discussion about the problems associated with reusing Bitcoin addresses, it was suggested that generating fresh addresses from public extended keys could be a solution that would also enhance user privacy. Instead of exchanging single addresses, the exchange of extended public keys could benefit non-merchant use of Payment Protocol. The challenge lies in how to push the extended public key down to the wallet itself. There are options such as developing services to facilitate this exchange or having wallet software communicate directly through various channels like Bluetooth, AirDrop, email, BitMessage, etc. Another idea mentioned was using extended public keys from bip 32 to share multiple addresses at once, enabling regular payments without needing further addresses and assisting with P2SH where the public key is required. Implementing these ideas has the potential to improve the efficiency and security of Bitcoin transactions.The debate over whether or not to sign every commit has been extensively covered. Linus Torvalds advises against signing each commit, but Peter Todd argues that per-commit signatures are necessary due to reliance on third-party sites like Github within the Bitcoin community. The Linux development model differs from Bitcoin's, using mailing lists and trusted maintainers committing to personal trees on secure computers. Eventually, patches are merged into a release tag, which is signed. Bitcoin developers often get code directly from Github and rely on per-commit signatures for authenticity. Todd believes the focus should be on the messaging layer, suggesting the use of OpenPGP and SSL certificate authorities instead of creating new identity systems that increase the risk of MITM attacks.In an email correspondence, Mike suggests splitting multi-sig and multi-factor authentication into two separate categories. He emphasizes the value of multi-factor user authentication and distinguishes it from multi-factor signing, which adds another level of complexity. Mike proposes that wallets should require multi-factor authentication before granting access and before signing a transaction. Regarding multi-factor signing, he acknowledges that it may be too early to define but suggests that wallets should not create two keys on a single host or device and provide a way to import external public keys for use in P2SH addresses. Mike also brings up a small word-choice nit, mentioning that he had to look up the meaning of "SHALL" (which he now knows is the same as MUST). In an unrelated topic, Drak mentions that Linus advises against signing each commit and suggests incorporating his recommendation for signing tags with `git tag -s` into the spec as a MUST.On December 19, 2013, Amir Taaki shared a link about signing each commit. Linus had advised against it, but upon reading the link, it was found that his advice did not make sense. However, Drak's response suggests that Linus's recommendation for signing tags with `git tag -s` should be included in the spec as a MUST. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_0-8-6-release-candidate-1.xml b/static/bitcoin-dev/Dec_2013/combined_0-8-6-release-candidate-1.xml index 2e69f74e00..3d43c37de2 100644 --- a/static/bitcoin-dev/Dec_2013/combined_0-8-6-release-candidate-1.xml +++ b/static/bitcoin-dev/Dec_2013/combined_0-8-6-release-candidate-1.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.8.6 release candidate 1 - 2023-08-01T06:47:01.204628+00:00 + 2025-10-11T21:46:21.671111+00:00 + python-feedgen Wladimir 2013-12-10 07:47:55+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - 0.8.6 release candidate 1 - 2023-08-01T06:47:01.204628+00:00 + 2025-10-11T21:46:21.671286+00:00 - On December 9, 2013, a conversation took place between Roy Badami and Wladimir regarding the final release of a certain project. Roy mentioned that the release was not announced on a mailing list and asked if there was another list he needed to be on. He also suggested that announcements should be posted on both a mailing list and bitcointalk.org. Wladimir agreed and proposed adding a list of places to announce to the release process.Drak pointed out on the same day that the bitcoin.org website was still pointing downloads to version 0.8.5 of bitcoin. Roy explained that it made sense not to promote release candidates on the website. However, Drak mentioned that version 0.8.6 had been released and was being discussed on bitcointalk/reddit. Roy then asked if there was a mailing list he missed, expressing the importance of having announcements posted on both the mailing list and bitcointalk.org.Another user named Drak shared a link to a post on Bitcointalk.org on December 9th, asking if it was an official announcement. Jeff Garzik confirmed that it was indeed an official announcement. The content of the announcement was not mentioned, but it was noted that once information is publicly available, it cannot be controlled or prevented from being discussed.In another email conversation on December 9th, Wladimir and Drak discussed the issue of premature online file sharing. Drak suggested that no files should be placed online unless they are officially released to avoid confusion. However, Wladimir argued that once the files are uploaded, they become official releases despite any additional builds or announcements. It was also acknowledged that public availability of files cannot be stopped, leading to discussions and posts on platforms like bitcointalk.org.Gregory Maxwell and Drak had a conversation on December 9th about the release of Bitcoin version 0.8.6. Drak claimed that the version was already released and available for download on sourceforge.net, but Maxwell clarified that it had not been officially released yet and was only queued for announcement. Drak expressed concern about the release workflow and suggested that no files should be placed online unless they were the official release.On December 9th, a discussion took place regarding the release of a new project on Bitcointalk and Reddit. However, according to an email from Drak, the project had not actually been released yet as it was waiting for an independent gitian build before an announcement could be made. This contradicted previous claims that the project had already been released and was circulating online.The bitcoin.org website was brought to attention on December 9th for still pointing downloads to version 0.8.5. It was suggested that an update was needed to ensure users had access to the latest version of the software.On December 8, 2013, a minor error was found in version 0.8.6rc1 of Bitcoin, where the leveldb subtree merge was done incorrectly. Despite this, Gavin Andresen noted that it was not a showstopper bug and decided to tag and ship v0.8.6 given the lack of reports of issues from hundreds of downloads.Gavin Andresen sent an email on December 5th, 2013, requesting help in testing the 0.8.6 release candidate 1, which was available for download from SourceForge. Warren had previously found the error in the leveldb subtree merge.In summary, there were discussions about the release process, the bitcoin.org website needing an update, the availability of release candidates, and the need for coordination in announcing releases. The release of a certain project was questioned, with conflicting information about its status. 2013-12-10T07:47:55+00:00 + On December 9, 2013, a conversation took place between Roy Badami and Wladimir regarding the final release of a certain project. Roy mentioned that the release was not announced on a mailing list and asked if there was another list he needed to be on. He also suggested that announcements should be posted on both a mailing list and bitcointalk.org. Wladimir agreed and proposed adding a list of places to announce to the release process.Drak pointed out on the same day that the bitcoin.org website was still pointing downloads to version 0.8.5 of bitcoin. Roy explained that it made sense not to promote release candidates on the website. However, Drak mentioned that version 0.8.6 had been released and was being discussed on bitcointalk/reddit. Roy then asked if there was a mailing list he missed, expressing the importance of having announcements posted on both the mailing list and bitcointalk.org.Another user named Drak shared a link to a post on Bitcointalk.org on December 9th, asking if it was an official announcement. Jeff Garzik confirmed that it was indeed an official announcement. The content of the announcement was not mentioned, but it was noted that once information is publicly available, it cannot be controlled or prevented from being discussed.In another email conversation on December 9th, Wladimir and Drak discussed the issue of premature online file sharing. Drak suggested that no files should be placed online unless they are officially released to avoid confusion. However, Wladimir argued that once the files are uploaded, they become official releases despite any additional builds or announcements. It was also acknowledged that public availability of files cannot be stopped, leading to discussions and posts on platforms like bitcointalk.org.Gregory Maxwell and Drak had a conversation on December 9th about the release of Bitcoin version 0.8.6. Drak claimed that the version was already released and available for download on sourceforge.net, but Maxwell clarified that it had not been officially released yet and was only queued for announcement. Drak expressed concern about the release workflow and suggested that no files should be placed online unless they were the official release.On December 9th, a discussion took place regarding the release of a new project on Bitcointalk and Reddit. However, according to an email from Drak, the project had not actually been released yet as it was waiting for an independent gitian build before an announcement could be made. This contradicted previous claims that the project had already been released and was circulating online.The bitcoin.org website was brought to attention on December 9th for still pointing downloads to version 0.8.5. It was suggested that an update was needed to ensure users had access to the latest version of the software.On December 8, 2013, a minor error was found in version 0.8.6rc1 of Bitcoin, where the leveldb subtree merge was done incorrectly. Despite this, Gavin Andresen noted that it was not a showstopper bug and decided to tag and ship v0.8.6 given the lack of reports of issues from hundreds of downloads.Gavin Andresen sent an email on December 5th, 2013, requesting help in testing the 0.8.6 release candidate 1, which was available for download from SourceForge. Warren had previously found the error in the leveldb subtree merge.In summary, there were discussions about the release process, the bitcoin.org website needing an update, the availability of release candidates, and the need for coordination in announcing releases. The release of a certain project was questioned, with conflicting information about its status. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Access-to-Mempool.xml b/static/bitcoin-dev/Dec_2013/combined_Access-to-Mempool.xml index c7a2dd5cd2..f4d03f98ad 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Access-to-Mempool.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Access-to-Mempool.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Access to Mempool - 2023-08-01T07:07:13.581629+00:00 + 2025-10-11T21:45:58.295980+00:00 + python-feedgen Mike Hearn 2013-12-28 14:46:05+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Access to Mempool - 2023-08-01T07:07:13.581629+00:00 + 2025-10-11T21:45:58.296161+00:00 - There are commands available to access a peer's mempool state, which can be used by nodes to request the contents of a peer's memory pool. This is particularly useful for SPV clients who want to find transactions that were broadcast before they were started up but not yet confirmed. By reading a peer's mempool or persisting it in a local database, nodes can recover faster after a reboot. The latest version, 0.9, has code to save the mempool to disk.The contents of the mempool may vary depending on when the node was started and what transactions it saw at what times. However, this does not have any significant impact. Generally, if a transaction is in the mempool, it will be relayed to other nodes unless there are specific quirks with sendrawtransaction RPCs or wallet spends.It is unclear what kind of information can be obtained about a node from its mempool, and whether there are any distinguishing features that can be observed. Furthermore, it is unknown if there are transactions that can be received into one's own mempool but not forwarded, or if 'nLockTime' transactions play a role in this context.The status of this new feature, including which clients support it, remains unclear. Additionally, the author asks if there are recommended sources to compare the features implemented by different wallet software. Although several questions are raised in the context, no summary is provided. 2013-12-28T14:46:05+00:00 + There are commands available to access a peer's mempool state, which can be used by nodes to request the contents of a peer's memory pool. This is particularly useful for SPV clients who want to find transactions that were broadcast before they were started up but not yet confirmed. By reading a peer's mempool or persisting it in a local database, nodes can recover faster after a reboot. The latest version, 0.9, has code to save the mempool to disk.The contents of the mempool may vary depending on when the node was started and what transactions it saw at what times. However, this does not have any significant impact. Generally, if a transaction is in the mempool, it will be relayed to other nodes unless there are specific quirks with sendrawtransaction RPCs or wallet spends.It is unclear what kind of information can be obtained about a node from its mempool, and whether there are any distinguishing features that can be observed. Furthermore, it is unknown if there are transactions that can be received into one's own mempool but not forwarded, or if 'nLockTime' transactions play a role in this context.The status of this new feature, including which clients support it, remains unclear. Additionally, the author asks if there are recommended sources to compare the features implemented by different wallet software. Although several questions are raised in the context, no summary is provided. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_BIP-proposal-Authenticated-prefix-trees.xml b/static/bitcoin-dev/Dec_2013/combined_BIP-proposal-Authenticated-prefix-trees.xml index 5f5fe6d7a4..e28afbf3cd 100644 --- a/static/bitcoin-dev/Dec_2013/combined_BIP-proposal-Authenticated-prefix-trees.xml +++ b/static/bitcoin-dev/Dec_2013/combined_BIP-proposal-Authenticated-prefix-trees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP proposal: Authenticated prefix trees - 2023-08-01T06:54:07.665191+00:00 + 2025-10-11T21:46:08.920008+00:00 + python-feedgen Mark Friedenbach 2014-01-08 01:04:58+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: Authenticated prefix trees - 2023-08-01T06:54:07.665191+00:00 + 2025-10-11T21:46:08.920188+00:00 - On January 6th, 2014, Gregory Maxwell proposed restructuring the current unspent transaction output (UTXO) index as a Merkle tree. This change would allow nodes without access to the UTXO set to still receive transactions or blocks with prefixed proofs and check their validity.Thomas Voegtlin had developed a Python-levelDB implementation of the UTXO hash tree and suggested creating per-block indexes of all scriptPubKeys, spent or unspent, queryable via partial prefix method. In response, Peter Todd recommended thoroughly testing the implementation on Electrum and adding a C++ implementation to Bitcoin Core. He also mentioned the need for performance testing and usability assessment before any soft-fork.Thomas Voegtlin expressed appreciation for Mark Friedenbach's work on the UTXO hash tree and stated its importance for Electrum. He suggested testing different options before writing a BIP and questioned the possibility of partial prefix queries on the tree.The email thread discussed a new Merkle-compressed data structure that has applications in committed validation indices, wallet indices, document time-stamping, and merged mining. The structure is based on a binary prefix tree and has a Python and C++ implementation. The serialization format of the authenticated prefix tree was described in detail.Gregory Maxwell posted questions regarding the proposed data structure, including the structure of VARCHAR(), extradata position, and the possibility of using SHA-512/256. He raised concerns about the performance cost of validating the structure under a zero-knowledge proof.Mark Friedenbach shared a first draft of a BIP for the new data structure, discussing the nature of VARCHAR(), extradata position, and midstate compression. He mentioned that CPU performance should not be a major consideration but the cost of validating under a zero-knowledge proof should be taken into account. Prefix tree compressed applications were discussed, noting that they could only be used if all verifying nodes had all their data under the tree.Peter Todd expressed his disagreement with UTXO commitments, arguing that they forced miners and full nodes with SPV clients to store the entire UTXO set perpetually. He also raised concerns about security and trust in single confirmations.Mark Friedenbach proposed stateless validation and mining involving prefixing messages with proofs of UTxO state changes. Peter Todd disagreed with UTXO commitments and suggested taking this technology to Namecoin instead.The email exchange on December 20, 2013, discussed authenticated prefix trees and their variations. The BIPs described the application of these trees to committed indices, document time-stamping, and merged mining. Mark Friedenbach mentioned advantages and added bytes to the coinbase transaction. Peter Todd provided feedback on the code examples, suggesting leaving out Unicode.In another email, Mark proposed application-oriented BIPs related to authenticated prefix trees. Stateless validation and mining involved prefixing messages with proofs of state changes. Ultimate blockchain compression involved consensus over an address index queried by lightweight nodes. The structure of the index was an authenticated prefix tree. Mark believed these BIPs affected the interoperability of the bitcoin protocol and clients using these applications.Overall, the email thread discussed various proposals and implementations related to restructuring the UTXO index, creating authenticated prefix trees, and their applications in the bitcoin ecosystem.The article discusses the proposal of introducing additional Bitcoin Improvement Proposals (BIPs) that describe the use of an authenticated prefix tree data structure for various applications. The author questions whether the BIP can stand alone without specific changes to the protocol or end-user accessible features, as BIPs are meant to define interoperability rather than implementation details. However, they express interest in reading about BIPs that utilize the tree to achieve scalability or security benefits.Bitcoin developer Mark Friedenbach has drafted a BIP for a new Merkle-compressed data structure called the authenticated prefix tree. This data structure is ideal for encoding key-value indices that support memory-efficient proofs. It is a hybrid PATRICIA / de la Brandais tree structure that compresses non-branching nodes into a single interior node with a skip prefix. This reduces the serialized size and the number of hash operations required for updates and proof validation. The authenticated prefix tree can be used for committed validation indices, wallet indices, document time-stamping, and merged mining.The article discusses two variations of the authenticated prefix tree presented in the draft BIP, which differ in the construction of hash values for nodes and their branches. The first variation is level-compressed hashing, where the referenced child node's hash is used in the interior node's hash digest. The second variation is proof-updatable hashing, where level-compressed branches are expanded into chained single-branch internal nodes. Both variations trade computational resources for the ability to compose operational proofs.Inclusion proofs, which are pruned prefix trees, are explained in the article. The serialization of inclusion proofs and operational proofs is also discussed, including their encoding in base64 format for display and transport 2014-01-08T01:04:58+00:00 + On January 6th, 2014, Gregory Maxwell proposed restructuring the current unspent transaction output (UTXO) index as a Merkle tree. This change would allow nodes without access to the UTXO set to still receive transactions or blocks with prefixed proofs and check their validity.Thomas Voegtlin had developed a Python-levelDB implementation of the UTXO hash tree and suggested creating per-block indexes of all scriptPubKeys, spent or unspent, queryable via partial prefix method. In response, Peter Todd recommended thoroughly testing the implementation on Electrum and adding a C++ implementation to Bitcoin Core. He also mentioned the need for performance testing and usability assessment before any soft-fork.Thomas Voegtlin expressed appreciation for Mark Friedenbach's work on the UTXO hash tree and stated its importance for Electrum. He suggested testing different options before writing a BIP and questioned the possibility of partial prefix queries on the tree.The email thread discussed a new Merkle-compressed data structure that has applications in committed validation indices, wallet indices, document time-stamping, and merged mining. The structure is based on a binary prefix tree and has a Python and C++ implementation. The serialization format of the authenticated prefix tree was described in detail.Gregory Maxwell posted questions regarding the proposed data structure, including the structure of VARCHAR(), extradata position, and the possibility of using SHA-512/256. He raised concerns about the performance cost of validating the structure under a zero-knowledge proof.Mark Friedenbach shared a first draft of a BIP for the new data structure, discussing the nature of VARCHAR(), extradata position, and midstate compression. He mentioned that CPU performance should not be a major consideration but the cost of validating under a zero-knowledge proof should be taken into account. Prefix tree compressed applications were discussed, noting that they could only be used if all verifying nodes had all their data under the tree.Peter Todd expressed his disagreement with UTXO commitments, arguing that they forced miners and full nodes with SPV clients to store the entire UTXO set perpetually. He also raised concerns about security and trust in single confirmations.Mark Friedenbach proposed stateless validation and mining involving prefixing messages with proofs of UTxO state changes. Peter Todd disagreed with UTXO commitments and suggested taking this technology to Namecoin instead.The email exchange on December 20, 2013, discussed authenticated prefix trees and their variations. The BIPs described the application of these trees to committed indices, document time-stamping, and merged mining. Mark Friedenbach mentioned advantages and added bytes to the coinbase transaction. Peter Todd provided feedback on the code examples, suggesting leaving out Unicode.In another email, Mark proposed application-oriented BIPs related to authenticated prefix trees. Stateless validation and mining involved prefixing messages with proofs of state changes. Ultimate blockchain compression involved consensus over an address index queried by lightweight nodes. The structure of the index was an authenticated prefix tree. Mark believed these BIPs affected the interoperability of the bitcoin protocol and clients using these applications.Overall, the email thread discussed various proposals and implementations related to restructuring the UTXO index, creating authenticated prefix trees, and their applications in the bitcoin ecosystem.The article discusses the proposal of introducing additional Bitcoin Improvement Proposals (BIPs) that describe the use of an authenticated prefix tree data structure for various applications. The author questions whether the BIP can stand alone without specific changes to the protocol or end-user accessible features, as BIPs are meant to define interoperability rather than implementation details. However, they express interest in reading about BIPs that utilize the tree to achieve scalability or security benefits.Bitcoin developer Mark Friedenbach has drafted a BIP for a new Merkle-compressed data structure called the authenticated prefix tree. This data structure is ideal for encoding key-value indices that support memory-efficient proofs. It is a hybrid PATRICIA / de la Brandais tree structure that compresses non-branching nodes into a single interior node with a skip prefix. This reduces the serialized size and the number of hash operations required for updates and proof validation. The authenticated prefix tree can be used for committed validation indices, wallet indices, document time-stamping, and merged mining.The article discusses two variations of the authenticated prefix tree presented in the draft BIP, which differ in the construction of hash values for nodes and their branches. The first variation is level-compressed hashing, where the referenced child node's hash is used in the interior node's hash digest. The second variation is proof-updatable hashing, where level-compressed branches are expanded into chained single-branch internal nodes. Both variations trade computational resources for the ability to compose operational proofs.Inclusion proofs, which are pruned prefix trees, are explained in the article. The serialization of inclusion proofs and operational proofs is also discussed, including their encoding in base64 format for display and transport - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Bitcoin-development-Digest-Vol-31-Issue-25.xml b/static/bitcoin-dev/Dec_2013/combined_Bitcoin-development-Digest-Vol-31-Issue-25.xml index 31321bd09e..2f722d6152 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Bitcoin-development-Digest-Vol-31-Issue-25.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Bitcoin-development-Digest-Vol-31-Issue-25.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin-development Digest, Vol 31, Issue 25 - 2023-08-01T06:50:55.453848+00:00 + 2025-10-11T21:45:39.134716+00:00 + python-feedgen kjj 2013-12-10 13:18:52+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin-development Digest, Vol 31, Issue 25 - 2023-08-01T06:50:55.453848+00:00 + 2025-10-11T21:45:39.134871+00:00 - Ryan Carboni believes that the economic parameters of Bitcoin can be changed to address issues such as deflation and inflation. He argues that Austrian-defined inflation is occurring at a faster rate than desired within Bitcoin. Carboni suggests that those who disagree with him should educate themselves on how the system works instead of relying on arguments from authority.However, it is advised that Carboni take his proposal to a proper venue, such as the bitcointalk.org forums, as the mailing list where he made his comments was not intended for political discussions. Similar proposals have been discussed on the forums, making it a more suitable platform for such debates.The conversation also explores the possibility of creating a new altcoin that reflects the consensus on inflation if changing Bitcoin's inflation parameters becomes necessary. Merchants would potentially vote for this altcoin, which would likely be created when consensus shifts towards accepting inflation. It is emphasized that adding a monetary authority to Bitcoin is both impossible and undesirable, as it contradicts the implicit contract of Bitcoin being unchangeable. However, these ideas could be experimented with in new altcoins.One challenge highlighted in the discussion is the significant value fluctuations of Bitcoin, which make it difficult to use for daily transactions. While it may be challenging for an altcoin to gain acceptance due to the existing infrastructure for Bitcoin, the proposal is deemed economically sound and potentially the only solution to the speculation crisis.Lastly, it is acknowledged that the economic parameters of Bitcoin are not set in stone and that if a change becomes necessary, it will be a messy process but still possible. This implies that flexibility exists within the Bitcoin system to adapt to evolving needs and address any potential shortcomings. 2013-12-10T13:18:52+00:00 + Ryan Carboni believes that the economic parameters of Bitcoin can be changed to address issues such as deflation and inflation. He argues that Austrian-defined inflation is occurring at a faster rate than desired within Bitcoin. Carboni suggests that those who disagree with him should educate themselves on how the system works instead of relying on arguments from authority.However, it is advised that Carboni take his proposal to a proper venue, such as the bitcointalk.org forums, as the mailing list where he made his comments was not intended for political discussions. Similar proposals have been discussed on the forums, making it a more suitable platform for such debates.The conversation also explores the possibility of creating a new altcoin that reflects the consensus on inflation if changing Bitcoin's inflation parameters becomes necessary. Merchants would potentially vote for this altcoin, which would likely be created when consensus shifts towards accepting inflation. It is emphasized that adding a monetary authority to Bitcoin is both impossible and undesirable, as it contradicts the implicit contract of Bitcoin being unchangeable. However, these ideas could be experimented with in new altcoins.One challenge highlighted in the discussion is the significant value fluctuations of Bitcoin, which make it difficult to use for daily transactions. While it may be challenging for an altcoin to gain acceptance due to the existing infrastructure for Bitcoin, the proposal is deemed economically sound and potentially the only solution to the speculation crisis.Lastly, it is acknowledged that the economic parameters of Bitcoin are not set in stone and that if a change becomes necessary, it will be a messy process but still possible. This implies that flexibility exists within the Bitcoin system to adapt to evolving needs and address any potential shortcomings. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Bitcoin-development-Digest-Vol-31-Issue-41.xml b/static/bitcoin-dev/Dec_2013/combined_Bitcoin-development-Digest-Vol-31-Issue-41.xml index 496f14c460..a032d2aae9 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Bitcoin-development-Digest-Vol-31-Issue-41.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Bitcoin-development-Digest-Vol-31-Issue-41.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin-development Digest, Vol 31, Issue 41 - 2023-08-01T07:06:12.092048+00:00 + 2025-10-11T21:45:49.797029+00:00 + python-feedgen Allen Piscitello 2013-12-25 20:21:36+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin-development Digest, Vol 31, Issue 41 - 2023-08-01T07:06:12.092048+00:00 + 2025-10-11T21:45:49.797166+00:00 - In the email conversation, Ryan Carboni proposes a reduction in the difficulty of the Bitcoin network to prevent man-in-the-middle attacks. These attacks involve isolating an individual from the network and switching them to the attacker's chain. Carboni argues that such attacks are unlikely due to the significant hash power required, which would be noticed by others on the network.However, another member of the mailing list dismisses the proposal, deeming it unnecessary and potentially harmful. They suggest discussing it on Bitcointalk instead. Carboni becomes frustrated with the lack of understanding and decides to end the conversation.Carboni reiterates their point, stating that for a man-in-the-middle attack to occur with a substantial percentage of hash power, the attacker would need to target a pool or a large number of nodes. This activity would be noticeable. Furthermore, the attacker would require at least 1% of the hash power and divert it to attack one person, which is rare considering few individuals possess even a hundredth of a percent of the total hash power.To address these proposed attacks, Carboni concedes that reducing difficulty by 80% if only four blocks were mined in three days would provide sufficient protection. However, they feel their arguments are not being understood and have nothing more to add.The email concludes with a comment about the holidays. 2013-12-25T20:21:36+00:00 + In the email conversation, Ryan Carboni proposes a reduction in the difficulty of the Bitcoin network to prevent man-in-the-middle attacks. These attacks involve isolating an individual from the network and switching them to the attacker's chain. Carboni argues that such attacks are unlikely due to the significant hash power required, which would be noticed by others on the network.However, another member of the mailing list dismisses the proposal, deeming it unnecessary and potentially harmful. They suggest discussing it on Bitcointalk instead. Carboni becomes frustrated with the lack of understanding and decides to end the conversation.Carboni reiterates their point, stating that for a man-in-the-middle attack to occur with a substantial percentage of hash power, the attacker would need to target a pool or a large number of nodes. This activity would be noticeable. Furthermore, the attacker would require at least 1% of the hash power and divert it to attack one person, which is rare considering few individuals possess even a hundredth of a percent of the total hash power.To address these proposed attacks, Carboni concedes that reducing difficulty by 80% if only four blocks were mined in three days would provide sufficient protection. However, they feel their arguments are not being understood and have nothing more to add.The email concludes with a comment about the holidays. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Bitcoin-difficulty-sanity-check-suggestion.xml b/static/bitcoin-dev/Dec_2013/combined_Bitcoin-difficulty-sanity-check-suggestion.xml index 950786f565..2df5ac7199 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Bitcoin-difficulty-sanity-check-suggestion.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Bitcoin-difficulty-sanity-check-suggestion.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin difficulty sanity check suggestion - 2023-08-01T06:55:39.703944+00:00 + 2025-10-11T21:45:47.674753+00:00 + python-feedgen Matt Corallo 2013-12-24 08:34:53+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Bitcoin difficulty sanity check suggestion - 2023-08-01T06:55:39.703944+00:00 + 2025-10-11T21:45:47.674938+00:00 - Mark Friedenbach disagrees with this proposal, arguing that adjusting the difficulty could introduce security risks. He suggests alternative difficulty adjustment algorithms being explored by some alts, such as the 9-block interval, 144-block window, and Parks-McClellan FIR filter used by Freicoin to recover from a mining bubble. He believes that if such a scenario were to happen to Bitcoin, there would be sophisticated alternatives available and enough time to make the necessary changes.The conversation also touches on the safety of running Bitcoin through a proprietary dial-up network. Matt criticizes Ryan Carboni for not clarifying the attack and posting ideas without a proper understanding of the Bitcoin network. He states that it is frowned upon to suggest ideas without technical substance. The discussion takes place on the Bitcoin-development mailing list.Overall, the email conversation revolves around the potential security risks of adjusting Bitcoin's difficulty after a certain period of time. Different developers express their opinions on the matter, discussing alternative difficulty adjustment algorithms and the importance of safeguarding the network against potential attacks. 2013-12-24T08:34:53+00:00 + Mark Friedenbach disagrees with this proposal, arguing that adjusting the difficulty could introduce security risks. He suggests alternative difficulty adjustment algorithms being explored by some alts, such as the 9-block interval, 144-block window, and Parks-McClellan FIR filter used by Freicoin to recover from a mining bubble. He believes that if such a scenario were to happen to Bitcoin, there would be sophisticated alternatives available and enough time to make the necessary changes.The conversation also touches on the safety of running Bitcoin through a proprietary dial-up network. Matt criticizes Ryan Carboni for not clarifying the attack and posting ideas without a proper understanding of the Bitcoin network. He states that it is frowned upon to suggest ideas without technical substance. The discussion takes place on the Bitcoin-development mailing list.Overall, the email conversation revolves around the potential security risks of adjusting Bitcoin's difficulty after a certain period of time. Different developers express their opinions on the matter, discussing alternative difficulty adjustment algorithms and the importance of safeguarding the network against potential attacks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Coin-Control-Send-crash-on-MacOS-X.xml b/static/bitcoin-dev/Dec_2013/combined_Coin-Control-Send-crash-on-MacOS-X.xml index 0c572ccad2..d74fca7813 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Coin-Control-Send-crash-on-MacOS-X.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Coin-Control-Send-crash-on-MacOS-X.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Coin Control, Send crash on MacOS X - 2023-08-01T06:43:54.127750+00:00 + 2025-10-11T21:46:13.173633+00:00 + python-feedgen Wladimir 2013-12-04 07:02:48+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Coin Control, Send crash on MacOS X - 2023-08-01T06:43:54.127750+00:00 + 2025-10-11T21:46:13.173810+00:00 - In December 2013, Warren Togami Jr. backported patches from master and Litecoin to create a Bitcoin 0.8 client with additional features. The backported patches were successful on Linux and Win32, but a rare crash was discovered on MacOS X. This crash seemed to be related to a race condition involving SendCoinsEntry::clear(). To address this issue, Wladimir suggested that the setFocus() should be moved from clear() to a separate function called "focusPayTo". After removing both setFocus() calls that occur after clicking Send, another crash occurred within qt. Warren has been actively working on backporting patches from master and Litecoin to enhance the Bitcoin client 0.8 for Linux and Win32. However, a rare crash has recently been identified on MacOS X, specifically involving SendCoinsEntry::clear(). Toffoo and coblee were able to replicate the issue on MacOS X 10.9, while Warren encountered it on 10.6.8. The build was created using Xcode 3.2.6 on MacOS X with MacPorts qt4-mac qt-4.8.4, aiming to simulate Gavin's build environment for the 0.8.x releases. Despite Warren's attempts to build master, he encountered difficulties due to being unfamiliar with the build environment. He plans to try qt-4.8.5 next, although reproducing the crash may prove challenging. 2013-12-04T07:02:48+00:00 + In December 2013, Warren Togami Jr. backported patches from master and Litecoin to create a Bitcoin 0.8 client with additional features. The backported patches were successful on Linux and Win32, but a rare crash was discovered on MacOS X. This crash seemed to be related to a race condition involving SendCoinsEntry::clear(). To address this issue, Wladimir suggested that the setFocus() should be moved from clear() to a separate function called "focusPayTo". After removing both setFocus() calls that occur after clicking Send, another crash occurred within qt. Warren has been actively working on backporting patches from master and Litecoin to enhance the Bitcoin client 0.8 for Linux and Win32. However, a rare crash has recently been identified on MacOS X, specifically involving SendCoinsEntry::clear(). Toffoo and coblee were able to replicate the issue on MacOS X 10.9, while Warren encountered it on 10.6.8. The build was created using Xcode 3.2.6 on MacOS X with MacPorts qt4-mac qt-4.8.4, aiming to simulate Gavin's build environment for the 0.8.x releases. Despite Warren's attempts to build master, he encountered difficulties due to being unfamiliar with the build environment. He plans to try qt-4.8.5 next, although reproducing the crash may prove challenging. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_DarkWallet-Best-Practices.xml b/static/bitcoin-dev/Dec_2013/combined_DarkWallet-Best-Practices.xml index e6f1ed171d..29e38015d7 100644 --- a/static/bitcoin-dev/Dec_2013/combined_DarkWallet-Best-Practices.xml +++ b/static/bitcoin-dev/Dec_2013/combined_DarkWallet-Best-Practices.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DarkWallet Best Practices - 2023-08-01T06:52:38.055952+00:00 + 2025-10-11T21:45:26.389174+00:00 + python-feedgen Wendell 2013-12-20 06:52:51+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - DarkWallet Best Practices - 2023-08-01T06:52:38.055952+00:00 + 2025-10-11T21:45:26.389363+00:00 - In an email written by Peter Todd after the DarkWallet Hackathon in 2013, various principles and privacy measures in relation to Bitcoin were discussed. Todd highlighted the importance of avoiding address re-use, implementing basic two-party mix functionality, and encouraging trade-offs between privacy and usability in wallet software. He also emphasized the use of Tor for privacy enhancement.Decentralization was another key aspect addressed in the email. Todd suggested that wallets should allow users to set fees and respond to attacks by providing the ability to change fees per KB after initial broadcast. He also mentioned the implementation of fee estimation techniques.The article further delved into the security and integrity of Bitcoin wallet software. It explained the use of Bloom filters for SPV nodes, but cautioned about their limitations for archival blockchain data due to potential DoS attacks. Instead, prefix filters were recommended as a viable alternative.Source-code and binary integrity were highlighted as crucial, with the suggestion of using revision control systems and PGP signatures respectively. Todd urged developers to make use of PGP and participate in the web-of-trust, while also discussing SSL/Certificate authorities and multi-factor spend authorization (multisig wallets).Payment integrity through a payment protocol like BIP70 was deemed important, although concerns about its dependence on the certificate authority system were raised. The article acknowledged the challenges of making PGP more user-friendly and called for efforts to enhance the user experience.Overall, the email and article stressed the need to implement various measures in Bitcoin wallet software to enhance privacy, decentralization, security, and integrity. These included avoiding address re-use, implementing two-party mix functionality, using Tor for privacy enhancement, allowing users to set and change fees, implementing prefix filters, ensuring source-code and binary integrity, using SSL/Certificate authorities and multisig wallets, and promoting payment integrity through BIP70. The article also recognized the need to improve the user-friendliness of PGP. In a separate email conversation, Amir Taaki and others debated the merits of per-commit signatures in Bitcoin development. While Linus Torvalds cautioned against it, Taaki argued that per-commit signatures were necessary due to the nature of code dissemination on platforms like GitHub. The discussion also touched on identity systems for messaging layers, with Taaki recommending the use of existing systems like OpenPGP and SSL certificate authorities.The DarkWallet Hackathon aimed to discuss decentralized Bitcoin usage principles, focusing on privacy, education, and security. Measures such as avoiding address re-use, implementing CoinJoin, using TOR, and allowing users to set fees were recommended to protect Bitcoin users from state-level attacks. Wallet software was advised to balance privacy and usability, blur the distinctions between different nodes, mitigate DoS attacks through Bloom or prefix filters, allow transaction replacement, and support payment protocol use. Source-code and binary integrity were stressed, along with the need for multi-factor spend authorization and support for BIP70.In summary, the email and article provided comprehensive insights into the various measures that should be implemented in Bitcoin wallet software to enhance privacy, decentralization, security, and integrity. They emphasized the importance of addressing issues such as address re-use, fee setting, source-code and binary integrity, multisig wallets, and payment protocol usage. The challenges of PGP user-friendliness and the use of existing identity systems were also acknowledged. 2013-12-20T06:52:51+00:00 + In an email written by Peter Todd after the DarkWallet Hackathon in 2013, various principles and privacy measures in relation to Bitcoin were discussed. Todd highlighted the importance of avoiding address re-use, implementing basic two-party mix functionality, and encouraging trade-offs between privacy and usability in wallet software. He also emphasized the use of Tor for privacy enhancement.Decentralization was another key aspect addressed in the email. Todd suggested that wallets should allow users to set fees and respond to attacks by providing the ability to change fees per KB after initial broadcast. He also mentioned the implementation of fee estimation techniques.The article further delved into the security and integrity of Bitcoin wallet software. It explained the use of Bloom filters for SPV nodes, but cautioned about their limitations for archival blockchain data due to potential DoS attacks. Instead, prefix filters were recommended as a viable alternative.Source-code and binary integrity were highlighted as crucial, with the suggestion of using revision control systems and PGP signatures respectively. Todd urged developers to make use of PGP and participate in the web-of-trust, while also discussing SSL/Certificate authorities and multi-factor spend authorization (multisig wallets).Payment integrity through a payment protocol like BIP70 was deemed important, although concerns about its dependence on the certificate authority system were raised. The article acknowledged the challenges of making PGP more user-friendly and called for efforts to enhance the user experience.Overall, the email and article stressed the need to implement various measures in Bitcoin wallet software to enhance privacy, decentralization, security, and integrity. These included avoiding address re-use, implementing two-party mix functionality, using Tor for privacy enhancement, allowing users to set and change fees, implementing prefix filters, ensuring source-code and binary integrity, using SSL/Certificate authorities and multisig wallets, and promoting payment integrity through BIP70. The article also recognized the need to improve the user-friendliness of PGP. In a separate email conversation, Amir Taaki and others debated the merits of per-commit signatures in Bitcoin development. While Linus Torvalds cautioned against it, Taaki argued that per-commit signatures were necessary due to the nature of code dissemination on platforms like GitHub. The discussion also touched on identity systems for messaging layers, with Taaki recommending the use of existing systems like OpenPGP and SSL certificate authorities.The DarkWallet Hackathon aimed to discuss decentralized Bitcoin usage principles, focusing on privacy, education, and security. Measures such as avoiding address re-use, implementing CoinJoin, using TOR, and allowing users to set fees were recommended to protect Bitcoin users from state-level attacks. Wallet software was advised to balance privacy and usability, blur the distinctions between different nodes, mitigate DoS attacks through Bloom or prefix filters, allow transaction replacement, and support payment protocol use. Source-code and binary integrity were stressed, along with the need for multi-factor spend authorization and support for BIP70.In summary, the email and article provided comprehensive insights into the various measures that should be implemented in Bitcoin wallet software to enhance privacy, decentralization, security, and integrity. They emphasized the importance of addressing issues such as address re-use, fee setting, source-code and binary integrity, multisig wallets, and payment protocol usage. The challenges of PGP user-friendliness and the use of existing identity systems were also acknowledged. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Dedicated-server-for-bitcoin-org-your-thoughts-.xml b/static/bitcoin-dev/Dec_2013/combined_Dedicated-server-for-bitcoin-org-your-thoughts-.xml index b566d40b9b..39c9e5778a 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Dedicated-server-for-bitcoin-org-your-thoughts-.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Dedicated-server-for-bitcoin-org-your-thoughts-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dedicated server for bitcoin.org, your thoughts? - 2023-08-01T06:48:14.987945+00:00 + 2025-10-11T21:45:32.760228+00:00 + python-feedgen Troy Benjegerdes 2014-01-04 01:43:36+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 Combined summary - Dedicated server for bitcoin.org, your thoughts? - 2023-08-01T06:48:14.989944+00:00 + 2025-10-11T21:45:32.760505+00:00 - In a series of discussions, the security and integrity of Bitcoin software were explored. One key topic was the importance of checking hash values to prevent attackers from replacing parts of files. Package management systems like apt-secure were seen as useful in ensuring the integrity of software packages at the operating system level. However, there were doubts about the feasibility of binaries checking their own hash. The group concluded that promoting the use of signed .deb packages and secure package management systems would be a better approach to security.Another area of discussion was the security of Bitcoin protocol updates. Suggestions included deterministic builds, threshold signed updates, and using the blockchain for forward-validation. SSL and trusted automatic update notification were also considered. Concerns were raised about the verification of hashes in Bitcoin downloads, particularly the differences between the hashes signed by individuals and the hashes of files hosted on SourceForge. Various solutions were proposed, such as patching signatures onto gitian builds or using gitian-downloader for verifying signatures.The security and control of the bitcoin.org domain were also discussed. There were concerns about the effectiveness of SSL in protecting against attackers intercepting traffic to the server. Some argued that PGP signatures could provide stronger protection. Ownership and administration of the domain were debated, with suggestions to separate it from Github and involve the Bitcoin Foundation. Anonymity in domain registration and trust in the current registrar were also points of concern.The funding, administration, and DNS control of bitcoin.org were addressed. Suggestions were made for the Bitcoin Foundation to fund the website, but clear separation between the foundation's website and bitcoin.org was emphasized. The importance of anti-DoS measures, identifying a trustworthy administrator, and maintaining control over the domain were highlighted.The question of who should have admin rights to code projects on platforms like Github and SourceForge was raised. Some argued for giving admin rights to those who have proven trustworthiness, while others emphasized the need for decentralization and control by multiple individuals. Concerns were raised about having too many important elements of the Bitcoin project under one entity's control.The security of SSL certificates was a topic of discussion, with concerns about MITM attacks and the limitations of the CA system. The importance of offline signature verification on binaries was emphasized. Decentralization and clear ownership over key aspects of the Bitcoin project, such as admin rights, DNS control, and website hosting, were also points of concern.In a separate thread, concerns were expressed about CAs in relation to bitcoin.org. The suggestion of moving the website to a dedicated server with an SSL certificate was discussed to address the lack of encryption and potential issues with CAs. Other concerns about forward secrecy, binaries hosting/sharing, revocation, and decentralization were raised. The idea of using mirrors or other methods to further decentralize the content of bitcoin.org was proposed.Overall, the discussions highlighted the importance of verifying hash values, integrating cryptography with mainstream use, and ensuring the security and reliability of the bitcoin.org website. Various solutions and approaches were proposed, emphasizing the ongoing efforts to enhance the security of Bitcoin software. 2014-01-04T01:43:36+00:00 + In a series of discussions, the security and integrity of Bitcoin software were explored. One key topic was the importance of checking hash values to prevent attackers from replacing parts of files. Package management systems like apt-secure were seen as useful in ensuring the integrity of software packages at the operating system level. However, there were doubts about the feasibility of binaries checking their own hash. The group concluded that promoting the use of signed .deb packages and secure package management systems would be a better approach to security.Another area of discussion was the security of Bitcoin protocol updates. Suggestions included deterministic builds, threshold signed updates, and using the blockchain for forward-validation. SSL and trusted automatic update notification were also considered. Concerns were raised about the verification of hashes in Bitcoin downloads, particularly the differences between the hashes signed by individuals and the hashes of files hosted on SourceForge. Various solutions were proposed, such as patching signatures onto gitian builds or using gitian-downloader for verifying signatures.The security and control of the bitcoin.org domain were also discussed. There were concerns about the effectiveness of SSL in protecting against attackers intercepting traffic to the server. Some argued that PGP signatures could provide stronger protection. Ownership and administration of the domain were debated, with suggestions to separate it from Github and involve the Bitcoin Foundation. Anonymity in domain registration and trust in the current registrar were also points of concern.The funding, administration, and DNS control of bitcoin.org were addressed. Suggestions were made for the Bitcoin Foundation to fund the website, but clear separation between the foundation's website and bitcoin.org was emphasized. The importance of anti-DoS measures, identifying a trustworthy administrator, and maintaining control over the domain were highlighted.The question of who should have admin rights to code projects on platforms like Github and SourceForge was raised. Some argued for giving admin rights to those who have proven trustworthiness, while others emphasized the need for decentralization and control by multiple individuals. Concerns were raised about having too many important elements of the Bitcoin project under one entity's control.The security of SSL certificates was a topic of discussion, with concerns about MITM attacks and the limitations of the CA system. The importance of offline signature verification on binaries was emphasized. Decentralization and clear ownership over key aspects of the Bitcoin project, such as admin rights, DNS control, and website hosting, were also points of concern.In a separate thread, concerns were expressed about CAs in relation to bitcoin.org. The suggestion of moving the website to a dedicated server with an SSL certificate was discussed to address the lack of encryption and potential issues with CAs. Other concerns about forward secrecy, binaries hosting/sharing, revocation, and decentralization were raised. The idea of using mirrors or other methods to further decentralize the content of bitcoin.org was proposed.Overall, the discussions highlighted the importance of verifying hash values, integrating cryptography with mainstream use, and ensuring the security and reliability of the bitcoin.org website. Various solutions and approaches were proposed, emphasizing the ongoing efforts to enhance the security of Bitcoin software. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Dual-elliptic-curve-algorithms.xml b/static/bitcoin-dev/Dec_2013/combined_Dual-elliptic-curve-algorithms.xml index 9249679142..64b146c4d1 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Dual-elliptic-curve-algorithms.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Dual-elliptic-curve-algorithms.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dual elliptic curve algorithms - 2023-08-01T06:55:30.479721+00:00 + 2025-10-11T21:45:51.917722+00:00 + python-feedgen Mike Hearn 2013-12-22 22:46:00+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Dual elliptic curve algorithms - 2023-08-01T06:55:30.479721+00:00 + 2025-10-11T21:45:51.917878+00:00 - A member of the Bitcoin-development mailing list raised concerns about the dual elliptic curve algorithm mentioned in an article discussing the NSA's encryption capabilities. This algorithm is connected to Elliptic Curve DSA, which is utilized in Bitcoin. Consequently, a discussion ensued among the mailing list members regarding the security of Bitcoin's cryptography and the potential adoption of alternative algorithms.The debate revolved around whether Bitcoin should switch to a different algorithm as a precautionary measure or maintain the current one, with some arguing that the current algorithm remains secure. The consensus reached by the members was that further research and analysis are necessary before any modifications are made to Bitcoin's cryptography.To learn more about the topic, you can refer to the Bitcoin-development mailing list and the article discussing the NSA's encryption capabilities. 2013-12-22T22:46:00+00:00 + A member of the Bitcoin-development mailing list raised concerns about the dual elliptic curve algorithm mentioned in an article discussing the NSA's encryption capabilities. This algorithm is connected to Elliptic Curve DSA, which is utilized in Bitcoin. Consequently, a discussion ensued among the mailing list members regarding the security of Bitcoin's cryptography and the potential adoption of alternative algorithms.The debate revolved around whether Bitcoin should switch to a different algorithm as a precautionary measure or maintain the current one, with some arguing that the current algorithm remains secure. The consensus reached by the members was that further research and analysis are necessary before any modifications are made to Bitcoin's cryptography.To learn more about the topic, you can refer to the Bitcoin-development mailing list and the article discussing the NSA's encryption capabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Fees-UI-warning.xml b/static/bitcoin-dev/Dec_2013/combined_Fees-UI-warning.xml index b82a05e536..7ba95e0244 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Fees-UI-warning.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Fees-UI-warning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fees UI warning - 2023-08-01T06:51:49.865510+00:00 + 2025-10-11T21:45:45.552166+00:00 + python-feedgen Andreas Schildbach 2013-12-16 22:32:30+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Fees UI warning - 2023-08-01T06:51:49.865510+00:00 + 2025-10-11T21:45:45.552310+00:00 - In December 2013, a discussion took place regarding the potential dangers of badly designed software in the Bitcoin community. Mike Hearn expressed concern about the appeal of such software and suggested adding warnings to certain services. The conversation also covered topics such as Bitcoin wallet security, deterministic wallets, and the need to prevent excessive fees for Bitcoin transactions.The possibility of no longer reusing change addresses for Bitcoin transactions was discussed by Pieter Wuille and Jim. Pieter was working on implementing HD wallets and stopping address re-use in bitcoinj. It was mentioned that address re-use could be stopped on devices with sufficient memory by Q1.Hive Wallet was focused on providing a user-friendly experience and emphasized removing unnecessary elements from their platform. They aimed to automate processes and make smart design decisions. Hive Wallet urged software developers to prioritize user experience and consider automation when developing applications.Jim proposed removing the import of individual private keys in the HD version of MultiBit for safety reasons. Wladimir agreed and suggested using deterministic wallets and a "sweep" function instead. This would make regular backups optional.Jim informed Pieter via email about the removal of individual private key imports from the HD version of MultiBit. The change was made for safety reasons, although specific details were not provided. Pieter asked if this meant that the reuse of change addresses would no longer be possible.A suggestion was made to implement a confirmation box in wallets to prevent users from paying excessively high fees. Wladimir mentioned that Bitcoin-qt already displayed fee and total amount information in the confirmation dialog, making it difficult to accidentally pay a very high fee.The issue of accidental high fees in Bitcoin transactions was a topic of discussion. Drak suggested implementing a confirmation box for unusually high fees, while Jim discussed other scenarios where users may lose their Bitcoins due to mistakes. MultiBit was making changes to reduce the possibility of Bitcoin loss, such as hiding the ability to delete wallets and sending change to a separate address.The Bitcoin community discussed the issue of accidentally paying excessive fees when sending transactions. MultiBit's developer, Jim Burton, explained that one reason for such losses was a lack of understanding about change. MultiBit implemented changes to address this issue, such as hiding the ability to delete wallets and always sending change to the second address if available.Drak suggested adding a confirmation box for unusually high fees in wallets, which received approval. The box would ask users to confirm if they wanted to pay a fee that was over 10 times the default or greater than a certain percentage of the sending amount. This could help prevent accidental payment of large fees.A Reddit post suggested that implementing a confirmation box for unreasonable fees could prevent accidental payment of huge fees. Examples were given of cases where users paid significantly higher fees than necessary. Although details about how this solution would work with flexible fees needed to be clarified, it was seen as a simple way to prevent such accidents. 2013-12-16T22:32:30+00:00 + In December 2013, a discussion took place regarding the potential dangers of badly designed software in the Bitcoin community. Mike Hearn expressed concern about the appeal of such software and suggested adding warnings to certain services. The conversation also covered topics such as Bitcoin wallet security, deterministic wallets, and the need to prevent excessive fees for Bitcoin transactions.The possibility of no longer reusing change addresses for Bitcoin transactions was discussed by Pieter Wuille and Jim. Pieter was working on implementing HD wallets and stopping address re-use in bitcoinj. It was mentioned that address re-use could be stopped on devices with sufficient memory by Q1.Hive Wallet was focused on providing a user-friendly experience and emphasized removing unnecessary elements from their platform. They aimed to automate processes and make smart design decisions. Hive Wallet urged software developers to prioritize user experience and consider automation when developing applications.Jim proposed removing the import of individual private keys in the HD version of MultiBit for safety reasons. Wladimir agreed and suggested using deterministic wallets and a "sweep" function instead. This would make regular backups optional.Jim informed Pieter via email about the removal of individual private key imports from the HD version of MultiBit. The change was made for safety reasons, although specific details were not provided. Pieter asked if this meant that the reuse of change addresses would no longer be possible.A suggestion was made to implement a confirmation box in wallets to prevent users from paying excessively high fees. Wladimir mentioned that Bitcoin-qt already displayed fee and total amount information in the confirmation dialog, making it difficult to accidentally pay a very high fee.The issue of accidental high fees in Bitcoin transactions was a topic of discussion. Drak suggested implementing a confirmation box for unusually high fees, while Jim discussed other scenarios where users may lose their Bitcoins due to mistakes. MultiBit was making changes to reduce the possibility of Bitcoin loss, such as hiding the ability to delete wallets and sending change to a separate address.The Bitcoin community discussed the issue of accidentally paying excessive fees when sending transactions. MultiBit's developer, Jim Burton, explained that one reason for such losses was a lack of understanding about change. MultiBit implemented changes to address this issue, such as hiding the ability to delete wallets and always sending change to the second address if available.Drak suggested adding a confirmation box for unusually high fees in wallets, which received approval. The box would ask users to confirm if they wanted to pay a fee that was over 10 times the default or greater than a certain percentage of the sending amount. This could help prevent accidental payment of large fees.A Reddit post suggested that implementing a confirmation box for unreasonable fees could prevent accidental payment of huge fees. Examples were given of cases where users paid significantly higher fees than necessary. Although details about how this solution would work with flexible fees needed to be clarified, it was seen as a simple way to prevent such accidents. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Floating-fees-and-SPV-clients.xml b/static/bitcoin-dev/Dec_2013/combined_Floating-fees-and-SPV-clients.xml index b9019e4c23..d033612aec 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Floating-fees-and-SPV-clients.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Floating-fees-and-SPV-clients.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Floating fees and SPV clients - 2023-08-01T06:45:52.863824+00:00 + 2025-10-11T21:45:56.170142+00:00 + python-feedgen Peter Todd 2013-12-04 21:51:58+00:00 @@ -187,13 +188,13 @@ - python-feedgen + 2 Combined summary - Floating fees and SPV clients - 2023-08-01T06:45:52.864827+00:00 + 2025-10-11T21:45:56.170363+00:00 - In this email exchange, Mike Hearn and Peter Todd discuss the topic of replacing fees in Bitcoin transactions. Todd argues that replacing fees is as speculative as Hearn's original proposal, while Hearn counters by saying that his original proposal hasn't received any comments and must be uncontroversial. They also discuss the specific discussions around fee handling in the payment protocol, which is not currently used anywhere. Hearn accuses Todd of talking about fundamental changes to how all Bitcoin nodes operate, which is off-topic for this thread.Another participant in the conversation suggests that wallets should compete, and the best user experience should win. The email ends with Todd's contact information and a digital signature.In another email exchange, Peter Todd questions the validity of replace-by-fee and discusses the discussions around fee handling in the payment protocol, which is not currently used anywhere. He notes that Hearn's original proposal has not received comments, implying it is uncontroversial. However, he mentions that Todd's suggestion of a fundamental change to the behavior of all Bitcoin nodes is off-topic for the thread at hand.There is also an email exchange where Mike Hearn requested that the thread not be derailed and encouraged those who wished to discuss different methods to start a new thread. Another participant responded by stating that the concept of replace-by-fee was no less speculative than Hearn's original proposals. This exchange took place on a public mailing list and included an attached digital signature.In a forum thread, someone requested others not to deviate from the topic and stated that their statement is factually correct. They advised others to start another thread if they want to convince people about different ways of doing things.In another message, Mike Hearn discusses the issue of allow_fee and its challenges when implemented with merchants. He mentions that there is rough consensus at the dark wallet conf that replacement for fee bumping is a good thing and should be supported. He also plans on proposing it for formal inclusion in their wallet best practices guidelines.The issue of cultural norms is highlighted as complicating the implementation of allow_fee in Bitcoin transactions. Merchants expect customers to pay the sticker price, and deviating from this norm is rare. Hearn mentions that without a clean fail mechanism, there may be disputes due to payments not clearing before the exchange rate shifts. He also discusses the need for an effective payment confirmation process that can handle edge cases and cultural differences.The Bitcoin developer community discusses the implementation of features like "allowfee" and "minfee" in Bitcoin network transaction fees. The "allowfee" specification aims to provide an allowance against the purchase price for network fees, while the "minfee" specification suggests adding a minimum fee to the amount paid to cover miner's transaction fees. Wallet software must respect these specifications when calculating fees. There is consensus among the community on both proposals.The proposed specifications, 'allowfee' and 'minfee,' are being discussed in the context of Bitcoin network transaction fees. According to the 'allowfee' specification, a wallet implementation cannot reduce the amount paid for fees by more than allowfee satoshis, and transaction fees must be equal to or greater than the amount reduced. With 'minfee,' wallet software should add minfee satoshis to the amount the user pays and include at least minfee in the transaction created to pay miner's transaction fees. However, wallet software may request that the user pays more if it creates a complex transaction or judges that minfee is not sufficient for the transaction to be accepted by the network.A merchant proposes a solution to prevent unexpected high fees by including a min_fee_per_kilobyte and max_fee in PaymentDetails. The sender would agree to pay the extra fee if it exceeds the max_fee, and the interior or merchant fees would be deducted from the first output. The UI could show the payment "price" with the sum of original outputs, merchant fees (interior), and sender fees (exterior) if applicable. This allows the merchant to pay fees in most cases while not having to pay excessive fees if the sender wants to use a large transaction.In an email exchange between Mike Hearn and Taylor Gerring, they discuss the concept of fees for Bitcoin transactions. Hearn suggests creating new terminology to differentiate between interior fees (included in the price/receiver pays) and exterior fees (excluded from the price/sender pays). They also discuss the need for intuitive user interfaces to inform users about transaction fees.The challenges of navigating varying sender fees and UI implementations in wallets are mentioned. However, there are solutions available for those willing to explore them, and collaboration among wallet creators can improve the user experience.There is also a discussion on the challenges of sales tax and the US system of taxation, which can be confusing for consumers. The author suggests that collaboration and sharing best practices among wallet creators can make the user experience smoother and more intuitive.In December 2013, Mike Hearn and Gavin Andresen discussed adding a fee 2013-12-04T21:51:58+00:00 + In this email exchange, Mike Hearn and Peter Todd discuss the topic of replacing fees in Bitcoin transactions. Todd argues that replacing fees is as speculative as Hearn's original proposal, while Hearn counters by saying that his original proposal hasn't received any comments and must be uncontroversial. They also discuss the specific discussions around fee handling in the payment protocol, which is not currently used anywhere. Hearn accuses Todd of talking about fundamental changes to how all Bitcoin nodes operate, which is off-topic for this thread.Another participant in the conversation suggests that wallets should compete, and the best user experience should win. The email ends with Todd's contact information and a digital signature.In another email exchange, Peter Todd questions the validity of replace-by-fee and discusses the discussions around fee handling in the payment protocol, which is not currently used anywhere. He notes that Hearn's original proposal has not received comments, implying it is uncontroversial. However, he mentions that Todd's suggestion of a fundamental change to the behavior of all Bitcoin nodes is off-topic for the thread at hand.There is also an email exchange where Mike Hearn requested that the thread not be derailed and encouraged those who wished to discuss different methods to start a new thread. Another participant responded by stating that the concept of replace-by-fee was no less speculative than Hearn's original proposals. This exchange took place on a public mailing list and included an attached digital signature.In a forum thread, someone requested others not to deviate from the topic and stated that their statement is factually correct. They advised others to start another thread if they want to convince people about different ways of doing things.In another message, Mike Hearn discusses the issue of allow_fee and its challenges when implemented with merchants. He mentions that there is rough consensus at the dark wallet conf that replacement for fee bumping is a good thing and should be supported. He also plans on proposing it for formal inclusion in their wallet best practices guidelines.The issue of cultural norms is highlighted as complicating the implementation of allow_fee in Bitcoin transactions. Merchants expect customers to pay the sticker price, and deviating from this norm is rare. Hearn mentions that without a clean fail mechanism, there may be disputes due to payments not clearing before the exchange rate shifts. He also discusses the need for an effective payment confirmation process that can handle edge cases and cultural differences.The Bitcoin developer community discusses the implementation of features like "allowfee" and "minfee" in Bitcoin network transaction fees. The "allowfee" specification aims to provide an allowance against the purchase price for network fees, while the "minfee" specification suggests adding a minimum fee to the amount paid to cover miner's transaction fees. Wallet software must respect these specifications when calculating fees. There is consensus among the community on both proposals.The proposed specifications, 'allowfee' and 'minfee,' are being discussed in the context of Bitcoin network transaction fees. According to the 'allowfee' specification, a wallet implementation cannot reduce the amount paid for fees by more than allowfee satoshis, and transaction fees must be equal to or greater than the amount reduced. With 'minfee,' wallet software should add minfee satoshis to the amount the user pays and include at least minfee in the transaction created to pay miner's transaction fees. However, wallet software may request that the user pays more if it creates a complex transaction or judges that minfee is not sufficient for the transaction to be accepted by the network.A merchant proposes a solution to prevent unexpected high fees by including a min_fee_per_kilobyte and max_fee in PaymentDetails. The sender would agree to pay the extra fee if it exceeds the max_fee, and the interior or merchant fees would be deducted from the first output. The UI could show the payment "price" with the sum of original outputs, merchant fees (interior), and sender fees (exterior) if applicable. This allows the merchant to pay fees in most cases while not having to pay excessive fees if the sender wants to use a large transaction.In an email exchange between Mike Hearn and Taylor Gerring, they discuss the concept of fees for Bitcoin transactions. Hearn suggests creating new terminology to differentiate between interior fees (included in the price/receiver pays) and exterior fees (excluded from the price/sender pays). They also discuss the need for intuitive user interfaces to inform users about transaction fees.The challenges of navigating varying sender fees and UI implementations in wallets are mentioned. However, there are solutions available for those willing to explore them, and collaboration among wallet creators can improve the user experience.There is also a discussion on the challenges of sales tax and the US system of taxation, which can be confusing for consumers. The author suggests that collaboration and sharing best practices among wallet creators can make the user experience smoother and more intuitive.In December 2013, Mike Hearn and Gavin Andresen discussed adding a fee - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Looking-for-GREAT-C-developer-for-exciting-opportunity-in-bitcoin-space.xml b/static/bitcoin-dev/Dec_2013/combined_Looking-for-GREAT-C-developer-for-exciting-opportunity-in-bitcoin-space.xml index 36664dd354..9ffeada21d 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Looking-for-GREAT-C-developer-for-exciting-opportunity-in-bitcoin-space.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Looking-for-GREAT-C-developer-for-exciting-opportunity-in-bitcoin-space.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Looking for GREAT C++ developer for exciting opportunity in bitcoin space - 2023-08-01T07:07:33.145540+00:00 + 2025-10-11T21:46:17.418234+00:00 + python-feedgen Troy Benjegerdes 2014-01-03 05:11:28+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Looking for GREAT C++ developer for exciting opportunity in bitcoin space - 2023-08-01T07:07:33.145540+00:00 + 2025-10-11T21:46:17.418426+00:00 - A startup called Hawk Financial Group, LLC is seeking one or two experienced C++ programmers who are knowledgeable about Bitcoin internals to join their team. The startup is working on a unique merge-mined altcoin project that aims to provide a valuable service to the entire crypto-coin ecosystem. However, before revealing more details about the project, applicants are required to sign a non-compete/non-disclosure agreement.The startup is particularly interested in candidates who have previous experience in adding features to Bitcoin or related technologies. Those who have made significant contributions in this area will be given preference. Interested individuals can send an email to eduffield82@gmail.com, providing a description of their work experience. The applications will be carefully reviewed, and if deemed suitable, the startup will share their detailed plans with the applicants.In December 2013, Evan Duffield, the founder of Hawk Financial Group, LLC, had originally posted an email to the Bitcoin-development mailing list, seeking skilled C++ programmers for his startup. The goal was to create a merge-mined altcoin that would offer a unique service to the crypto-coin ecosystem. However, this announcement received criticism from Jeremie, a long-time follower of bitcoin-development, who believed that such emails were irrelevant and considered them spam. He expressed concerns that these types of emails would divert true discussions between core-devs elsewhere, making it difficult for people like him to follow them.Meanwhile, Peter Todd, an expert in the field, cautioned against the use of merge mining in altcoins. He argued that without majority or near-majority hashing power, an attacker could easily execute a 51% attack on the altcoin by reusing existing hashing power. Luke, on the other hand, disagreed with Todd's point of view. He stated that any non-scam altcoin would be safe using merged mining because it would be in the attacker's interest to invest in the altcoin rather than attacking it. Luke also mentioned that there are ways to ensure the full security of bitcoin miners even when not all participate in the altcoin.In response to Todd's concerns, he suggested hiring someone competent to analyze the idea and recommended starting a timestamping service as a potential exception to his warning. Todd was willing to discuss the matter informally but was not ready to agree to any non-compete/non-disclosure terms.Additionally, Troy Benjegerdes made a unique offer to the startup by proposing to buy their company using revenue generated by his AGPLv3 copyrighted licensed Minco.me(c) cryptographic currency. He claimed that this currency would revolutionize work by providing a guaranteed income to anyone with a Mincome(C) address, eliminating the need for traditional employment. Benjegerdes advised the startup to seek legal counsel to avoid any potential contamination of their business model with a viral copyright license. 2014-01-03T05:11:28+00:00 + A startup called Hawk Financial Group, LLC is seeking one or two experienced C++ programmers who are knowledgeable about Bitcoin internals to join their team. The startup is working on a unique merge-mined altcoin project that aims to provide a valuable service to the entire crypto-coin ecosystem. However, before revealing more details about the project, applicants are required to sign a non-compete/non-disclosure agreement.The startup is particularly interested in candidates who have previous experience in adding features to Bitcoin or related technologies. Those who have made significant contributions in this area will be given preference. Interested individuals can send an email to eduffield82@gmail.com, providing a description of their work experience. The applications will be carefully reviewed, and if deemed suitable, the startup will share their detailed plans with the applicants.In December 2013, Evan Duffield, the founder of Hawk Financial Group, LLC, had originally posted an email to the Bitcoin-development mailing list, seeking skilled C++ programmers for his startup. The goal was to create a merge-mined altcoin that would offer a unique service to the crypto-coin ecosystem. However, this announcement received criticism from Jeremie, a long-time follower of bitcoin-development, who believed that such emails were irrelevant and considered them spam. He expressed concerns that these types of emails would divert true discussions between core-devs elsewhere, making it difficult for people like him to follow them.Meanwhile, Peter Todd, an expert in the field, cautioned against the use of merge mining in altcoins. He argued that without majority or near-majority hashing power, an attacker could easily execute a 51% attack on the altcoin by reusing existing hashing power. Luke, on the other hand, disagreed with Todd's point of view. He stated that any non-scam altcoin would be safe using merged mining because it would be in the attacker's interest to invest in the altcoin rather than attacking it. Luke also mentioned that there are ways to ensure the full security of bitcoin miners even when not all participate in the altcoin.In response to Todd's concerns, he suggested hiring someone competent to analyze the idea and recommended starting a timestamping service as a potential exception to his warning. Todd was willing to discuss the matter informally but was not ready to agree to any non-compete/non-disclosure terms.Additionally, Troy Benjegerdes made a unique offer to the startup by proposing to buy their company using revenue generated by his AGPLv3 copyrighted licensed Minco.me(c) cryptographic currency. He claimed that this currency would revolutionize work by providing a guaranteed income to anyone with a Mincome(C) address, eliminating the need for traditional employment. Benjegerdes advised the startup to seek legal counsel to avoid any potential contamination of their business model with a viral copyright license. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Merge-avoidance-and-P2P-connection-encryption.xml b/static/bitcoin-dev/Dec_2013/combined_Merge-avoidance-and-P2P-connection-encryption.xml index 65392cea91..2f918bc9e3 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Merge-avoidance-and-P2P-connection-encryption.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Merge-avoidance-and-P2P-connection-encryption.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Merge avoidance and P2P connection encryption - 2023-08-01T06:51:29.978922+00:00 + 2025-10-11T21:46:00.420890+00:00 + python-feedgen Mike Hearn 2013-12-13 21:49:23+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Merge avoidance and P2P connection encryption - 2023-08-01T06:51:29.978922+00:00 + 2025-10-11T21:46:00.421063+00:00 - In a discussion about a possible use case for pastebin style hosting sites for payment requests, it is proposed that regular end-users could upload signed or unsigned payment requests to a site like payr.com. The site would then handle incrementing the iteration count on each download of the file, relieving users from having to handle it themselves. This would be particularly useful for organizations receiving multiple payment requests with different xpubkeys. Both use cases can be supported, and iteration ranges can be specified if someone wants to specify expiry in terms of number of payments rather than time.Address reuse is another topic discussed, specifically in the context of an individual providing the Bitcoin Foundation with a PaymentRequest that includes multiple outputs, each having a different xpubkey. It is suggested that the Foundation's wallet software should take care of iterating in this situation. Rotating through multiple outputs is seen as a temporary solution to address reuse, with HD wallets ultimately being the more effective solution.Integration of BIP32 and BIP70 is also mentioned in an email conversation between Mike Hearn and Gavin Andresen. The proposal suggests adding an additional xpubkey and iteration count field to each output script for improved privacy. However, this requires a backwards incompatible change to the protocol. The conversation also discusses the possibility of last-minute changes to BIP70 before wallets ship and merchant support begins. "Super addresses" from BIP32 are suggested as a way to enhance privacy in BIP70's PaymentDetails message, which allows for multiple outputs. The refund_to address in Payment could also be upgraded to a super address for increased privacy.Another email conversation proposes the implementation of "super addresses" in Bitcoin wallets, aligning with the concept of BIP32. Super addresses encourage the use of a single address instead of traditional ones, improving privacy by eliminating the need to merge coins. This concept would fit well into BIP70, allowing payments to be broken into pieces to match unspent outputs in customers' wallets. Upgrading the refund_to address in Payment to a super address is also suggested. The author believes that implementing these proposals could greatly enhance Bitcoin's privacy features.In an article aimed at a non-developer audience, Bitcoin privacy topics are discussed, including P2P connection encryption, address reuse/payment protocol, and CoinJoin and merge avoidance. The article provides insights into the importance of privacy in Bitcoin transactions and explores various methods for improving it. It also delves into the use of SSL for P2P connections and its potential benefits and limitations. The article serves as a valuable resource for those looking to better understand Bitcoin privacy and contributes to the ongoing discussion around the topic.Overall, these discussions and proposals highlight the potential for improved privacy in Bitcoin transactions through the integration of BIP32 and BIP70, the use of "super addresses," and the exploration of various privacy-enhancing features in the payment protocol. 2013-12-13T21:49:23+00:00 + In a discussion about a possible use case for pastebin style hosting sites for payment requests, it is proposed that regular end-users could upload signed or unsigned payment requests to a site like payr.com. The site would then handle incrementing the iteration count on each download of the file, relieving users from having to handle it themselves. This would be particularly useful for organizations receiving multiple payment requests with different xpubkeys. Both use cases can be supported, and iteration ranges can be specified if someone wants to specify expiry in terms of number of payments rather than time.Address reuse is another topic discussed, specifically in the context of an individual providing the Bitcoin Foundation with a PaymentRequest that includes multiple outputs, each having a different xpubkey. It is suggested that the Foundation's wallet software should take care of iterating in this situation. Rotating through multiple outputs is seen as a temporary solution to address reuse, with HD wallets ultimately being the more effective solution.Integration of BIP32 and BIP70 is also mentioned in an email conversation between Mike Hearn and Gavin Andresen. The proposal suggests adding an additional xpubkey and iteration count field to each output script for improved privacy. However, this requires a backwards incompatible change to the protocol. The conversation also discusses the possibility of last-minute changes to BIP70 before wallets ship and merchant support begins. "Super addresses" from BIP32 are suggested as a way to enhance privacy in BIP70's PaymentDetails message, which allows for multiple outputs. The refund_to address in Payment could also be upgraded to a super address for increased privacy.Another email conversation proposes the implementation of "super addresses" in Bitcoin wallets, aligning with the concept of BIP32. Super addresses encourage the use of a single address instead of traditional ones, improving privacy by eliminating the need to merge coins. This concept would fit well into BIP70, allowing payments to be broken into pieces to match unspent outputs in customers' wallets. Upgrading the refund_to address in Payment to a super address is also suggested. The author believes that implementing these proposals could greatly enhance Bitcoin's privacy features.In an article aimed at a non-developer audience, Bitcoin privacy topics are discussed, including P2P connection encryption, address reuse/payment protocol, and CoinJoin and merge avoidance. The article provides insights into the importance of privacy in Bitcoin transactions and explores various methods for improving it. It also delves into the use of SSL for P2P connections and its potential benefits and limitations. The article serves as a valuable resource for those looking to better understand Bitcoin privacy and contributes to the ongoing discussion around the topic.Overall, these discussions and proposals highlight the potential for improved privacy in Bitcoin transactions through the integration of BIP32 and BIP70, the use of "super addresses," and the exploration of various privacy-enhancing features in the payment protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Merge-mining.xml b/static/bitcoin-dev/Dec_2013/combined_Merge-mining.xml index 86e44d3dce..b67f7ff813 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Merge-mining.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Merge-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Merge mining - 2023-08-01T07:08:12.151820+00:00 + 2025-10-11T21:45:41.308803+00:00 + python-feedgen Jorge Timón 2014-01-04 10:34:55+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Merge mining - 2023-08-01T07:08:12.151820+00:00 + 2025-10-11T21:45:41.308964+00:00 - In a discussion about merge mining, David Vorick addresses the concern of a potential attack on Dogecoin. He states that if any large currency were to be attacked, it would probably be litecoin miners attacking dogecoin. However, Vorick argues that an attacker with enough control over the litecoin network to perform such an attack would likely have a vested interest in cryptocurrencies doing well. He believes that a successful attack on dogecoin would cast doubt on the entire cryptocurrency ecosystem and hurt the attacker's interests.Jorge Timón disagrees with Vorick's assumptions and suggests that some individuals within the cryptocurrency ecosystem may actually want dogecoin to disappear. The discussion ends with Timón questioning Vorick's stance on merged mining and whether or not it applies to Dogecoin.The context also highlights the use of the scrypt algorithm by Dogecoin, which is popular among cryptocurrencies. Vorick suggests that attacking a significant currency like Dogecoin would not be beneficial due to the cost and potential backlash it would cause. Moreover, he explains that an attack on a major currency would cast doubt on the entire cryptocurrency ecosystem, drop the value of Bitcoin, and affect all cryptocurrencies using the same work function as Dogecoin.The conversation raises the importance of merged mining for the security of altcoins. It is suggested that attacking a significant currency would be expensive and traumatize the whole system, causing questions to be raised and dropping the value of bitcoin as well as all cryptocurrencies using the same work function. However, with many people having access to large amounts of GPUs, there may not be much cost to conducting a 51% attack on an altcoin beyond a short-term diversion away from profitable mining.Supporting merged mining could make it less straightforward for an individual or group to carry out a 51% attack. The rational decision for a non-scam altcoin is to take advantage of merged mining to maximize security. Luke-Jr argues that using merge mining as a red flag is not entirely accurate since any non-scam altcoin is safe with merged mining. Any potential attacker would have invested in the altcoin instead of attacking it. For non-scam altcoins, the rational decision is to take advantage of merged mining to maximize security.In conclusion, the discussion revolves around the potential for a 51% attack on altcoins and the importance of merged mining for their security. The use of scrypt algorithm by Dogecoin is mentioned, along with the possibility of litecoin miners attacking dogecoin. The context highlights the potential consequences of attacking a large altcoin like Dogecoin or Bitcoin, including the drop in value of Bitcoin and the entire cryptocurrency system. The conversation also raises questions about the interests of potential attackers and the rational decision for altcoins regarding merged mining. 2014-01-04T10:34:55+00:00 + In a discussion about merge mining, David Vorick addresses the concern of a potential attack on Dogecoin. He states that if any large currency were to be attacked, it would probably be litecoin miners attacking dogecoin. However, Vorick argues that an attacker with enough control over the litecoin network to perform such an attack would likely have a vested interest in cryptocurrencies doing well. He believes that a successful attack on dogecoin would cast doubt on the entire cryptocurrency ecosystem and hurt the attacker's interests.Jorge Timón disagrees with Vorick's assumptions and suggests that some individuals within the cryptocurrency ecosystem may actually want dogecoin to disappear. The discussion ends with Timón questioning Vorick's stance on merged mining and whether or not it applies to Dogecoin.The context also highlights the use of the scrypt algorithm by Dogecoin, which is popular among cryptocurrencies. Vorick suggests that attacking a significant currency like Dogecoin would not be beneficial due to the cost and potential backlash it would cause. Moreover, he explains that an attack on a major currency would cast doubt on the entire cryptocurrency ecosystem, drop the value of Bitcoin, and affect all cryptocurrencies using the same work function as Dogecoin.The conversation raises the importance of merged mining for the security of altcoins. It is suggested that attacking a significant currency would be expensive and traumatize the whole system, causing questions to be raised and dropping the value of bitcoin as well as all cryptocurrencies using the same work function. However, with many people having access to large amounts of GPUs, there may not be much cost to conducting a 51% attack on an altcoin beyond a short-term diversion away from profitable mining.Supporting merged mining could make it less straightforward for an individual or group to carry out a 51% attack. The rational decision for a non-scam altcoin is to take advantage of merged mining to maximize security. Luke-Jr argues that using merge mining as a red flag is not entirely accurate since any non-scam altcoin is safe with merged mining. Any potential attacker would have invested in the altcoin instead of attacking it. For non-scam altcoins, the rational decision is to take advantage of merged mining to maximize security.In conclusion, the discussion revolves around the potential for a 51% attack on altcoins and the importance of merged mining for their security. The use of scrypt algorithm by Dogecoin is mentioned, along with the possibility of litecoin miners attacking dogecoin. The context highlights the potential consequences of attacking a large altcoin like Dogecoin or Bitcoin, including the drop in value of Bitcoin and the entire cryptocurrency system. The conversation also raises questions about the interests of potential attackers and the rational decision for altcoins regarding merged mining. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Message-Signing-based-authentication.xml b/static/bitcoin-dev/Dec_2013/combined_Message-Signing-based-authentication.xml index 3ee9f7c386..14cbdc8741 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Message-Signing-based-authentication.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Message-Signing-based-authentication.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Message Signing based authentication - 2023-08-01T06:22:02.845121+00:00 + 2025-10-11T21:45:34.885985+00:00 + python-feedgen Melvin Carvalho 2013-12-06 10:44:32+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Message Signing based authentication - 2023-08-01T06:22:02.846122+00:00 + 2025-10-11T21:45:34.886201+00:00 - On November 6, 2013, a discussion was held on the storage of private keys in relation to cryptocurrency. The conversation mentioned the use of Trezor, a hardware wallet for storing Bitcoin private keys. Another topic discussed was the use of Secure QR Login (SQRL), a simplified authentication system that uses QR codes.The conversation also touched on the possibility of storing crypto in the browser using NSS, but it was noted that Bitcoin's curve may not be supported due to lack of NIST approval. However, if a compelling use case is presented, it could potentially be added.In an email exchange between Johnathan Corgan and bitcoingrant, the signing of an arbitrary string by the server was discussed. Bitcoingrant suggested XORing the string with a randomly generated nonce before signing it, and passing both the nonce and signature back to the server for verification. The conversation also mentioned the little-known HTTP code 402, "Payment Required," and provided contact information and a link to Corgan Labs, which offers SDR Training and Development Services.Slush suggested that in order to replace passwords with digital signatures, the message-to-be-signed should be structured and human-readable. Slush also raised concerns about where private keys are stored, but suggested that client-side certificates can be used to solve this problem. Two methods were explained for using client-side certificates, both of which have been used by Slush for over five years.A new Message Signing based authentication method was introduced in celebration of the 5-year anniversary of the Bitcoin whitepaper. The method involves the server providing a token for the client to sign, and the client passing back the signed message and Bitcoin address for validation. A proof of concept forum utilizing this method was provided, with plans to make the source code available on Github.The security of token signing was discussed, with suggestions made to modify or structure the token to avoid unintentional signatures. The Diffie-Hellman key exchange protocol was proposed as a standard way to avoid producing unintentional signatures.The distinction between what is required and what is strongly recommended in terms of reusing EC keys and addresses for transactions was discussed. It was argued that reusing keys should be seen as a best practice rather than a protocol requirement.On November 3, 2013, Allen Piscitello shared a use case where generating a new key for a Multisig Refund Transaction was necessary. It was noted that Bitcoin as a system has always required a unique EC key and address for each transaction.In a discussion on November 2, 2013, Allen Piscitello expressed concerns about signing a refund transaction before the original transaction is broadcast. Luke-Jr commented that there is no use case for signing with an address that has already been sent coins, but it was acknowledged that there is no way to stop someone from sending to an "identity" address.The concern of signing a refund transaction before the original transaction is broadcast was raised in multiple email threads. It was suggested to require sending the full transaction instead of just a hash to ensure security. The importance of use cases being grounded in actual needs rather than laziness was emphasized.A white paper on passwordless secure login based on bitcoin/bitmessage technology has been shared by alk.org. This technology aims to create a secure login without the need for passwords. The post was signed using PGP encryption.In an email thread from November 2, 2013, Mike Hearn discussed the use of client certificates for authentication. He acknowledged that while browser manufacturers have not optimized the user experience for this method, it is still possible. Hearn cited a Mozilla Labs project as an example. However, he noted that more popular options like OAuth or Persona operate on a trusted third-party model, creating a conflict of interest since browser manufacturers are often identity providers. Hearn expressed his preference for controlling his own identity with Public Key Infrastructure (PKI), but acknowledged that major players like Facebook and webmail providers dominate the market. The email thread also included a link to a white paper on secure code signing practices for Android apps.The authentication process described in the context involves a server providing a token to the client, which is then signed by the client and sent back along with a Bitcoin address. The server then validates the message and uses the provided alias (optional) and Bitcoin address for identification. A detailed article on this authentication method can be found on the website pilif.github.io, which explores why SSL client certificates are not widely used.On November 2, 2013, a celebration was held for the 5th anniversary of the Bitcoin whitepaper. As part of the celebration, a new authentication method called Message Signing was introduced. In this method, the server provides a token for the client to sign, which is then passed back to the server along with the client's bitcoin address. The server validates the message and uses the alias and bitcoin address for identification. A proof of concept forum utilizing this authentication method 2013-12-06T10:44:32+00:00 + On November 6, 2013, a discussion was held on the storage of private keys in relation to cryptocurrency. The conversation mentioned the use of Trezor, a hardware wallet for storing Bitcoin private keys. Another topic discussed was the use of Secure QR Login (SQRL), a simplified authentication system that uses QR codes.The conversation also touched on the possibility of storing crypto in the browser using NSS, but it was noted that Bitcoin's curve may not be supported due to lack of NIST approval. However, if a compelling use case is presented, it could potentially be added.In an email exchange between Johnathan Corgan and bitcoingrant, the signing of an arbitrary string by the server was discussed. Bitcoingrant suggested XORing the string with a randomly generated nonce before signing it, and passing both the nonce and signature back to the server for verification. The conversation also mentioned the little-known HTTP code 402, "Payment Required," and provided contact information and a link to Corgan Labs, which offers SDR Training and Development Services.Slush suggested that in order to replace passwords with digital signatures, the message-to-be-signed should be structured and human-readable. Slush also raised concerns about where private keys are stored, but suggested that client-side certificates can be used to solve this problem. Two methods were explained for using client-side certificates, both of which have been used by Slush for over five years.A new Message Signing based authentication method was introduced in celebration of the 5-year anniversary of the Bitcoin whitepaper. The method involves the server providing a token for the client to sign, and the client passing back the signed message and Bitcoin address for validation. A proof of concept forum utilizing this method was provided, with plans to make the source code available on Github.The security of token signing was discussed, with suggestions made to modify or structure the token to avoid unintentional signatures. The Diffie-Hellman key exchange protocol was proposed as a standard way to avoid producing unintentional signatures.The distinction between what is required and what is strongly recommended in terms of reusing EC keys and addresses for transactions was discussed. It was argued that reusing keys should be seen as a best practice rather than a protocol requirement.On November 3, 2013, Allen Piscitello shared a use case where generating a new key for a Multisig Refund Transaction was necessary. It was noted that Bitcoin as a system has always required a unique EC key and address for each transaction.In a discussion on November 2, 2013, Allen Piscitello expressed concerns about signing a refund transaction before the original transaction is broadcast. Luke-Jr commented that there is no use case for signing with an address that has already been sent coins, but it was acknowledged that there is no way to stop someone from sending to an "identity" address.The concern of signing a refund transaction before the original transaction is broadcast was raised in multiple email threads. It was suggested to require sending the full transaction instead of just a hash to ensure security. The importance of use cases being grounded in actual needs rather than laziness was emphasized.A white paper on passwordless secure login based on bitcoin/bitmessage technology has been shared by alk.org. This technology aims to create a secure login without the need for passwords. The post was signed using PGP encryption.In an email thread from November 2, 2013, Mike Hearn discussed the use of client certificates for authentication. He acknowledged that while browser manufacturers have not optimized the user experience for this method, it is still possible. Hearn cited a Mozilla Labs project as an example. However, he noted that more popular options like OAuth or Persona operate on a trusted third-party model, creating a conflict of interest since browser manufacturers are often identity providers. Hearn expressed his preference for controlling his own identity with Public Key Infrastructure (PKI), but acknowledged that major players like Facebook and webmail providers dominate the market. The email thread also included a link to a white paper on secure code signing practices for Android apps.The authentication process described in the context involves a server providing a token to the client, which is then signed by the client and sent back along with a Bitcoin address. The server then validates the message and uses the provided alias (optional) and Bitcoin address for identification. A detailed article on this authentication method can be found on the website pilif.github.io, which explores why SSL client certificates are not widely used.On November 2, 2013, a celebration was held for the 5th anniversary of the Bitcoin whitepaper. As part of the celebration, a new authentication method called Message Signing was introduced. In this method, the server provides a token for the client to sign, which is then passed back to the server along with the client's bitcoin address. The server validates the message and uses the alias and bitcoin address for identification. A proof of concept forum utilizing this authentication method - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Monetary-Authority-for-Bitcoin.xml b/static/bitcoin-dev/Dec_2013/combined_Monetary-Authority-for-Bitcoin.xml index 75b217a452..05a2648043 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Monetary-Authority-for-Bitcoin.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Monetary-Authority-for-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Monetary Authority for Bitcoin - 2023-08-01T06:50:42.981849+00:00 + 2025-10-11T21:46:11.052809+00:00 + python-feedgen Jeff Garzik 2013-12-11 01:01:52+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Monetary Authority for Bitcoin - 2023-08-01T06:50:42.981849+00:00 + 2025-10-11T21:46:11.052972+00:00 - Bitcoin's volatility is attributed to low liquidity and the ease with which a single large player can manipulate the market. The absence of common financial tools like shorting, futures, and options further contributes to this volatility. However, it is important to note that Bitcoin's volatility is a reflection of its future acceptance, which is influenced by inherently volatile sources such as politicians' opinions and government policies. The lack of stability in Bitcoin is also due to the absence of proof-of-work from society's end, which adds to its instability. As time progresses, laws, regulations, and policies will be established, bringing more stability to Bitcoin. This stability is expected to add value to Bitcoin within the range of $0.0001 to $100,000 per coin, regardless of whether the rulings are positive or negative.Discussions surrounding the feasibility of "stablecoins" in a secure and peer-to-peer system have been deemed off-topic and unfeasible on forums. While there have been proposals for stablecoins, implementing them securely in such a system has proven challenging. Participants in these discussions suggest asking questions to understand why these proposals are unfeasible rather than dismissing critiques as closed-mindedness.In December 2013, Mike Caldwell expressed his belief that if there was a consensus that Bitcoin's inflation parameters hindered its economy, merchants could vote for changing the rules. He proposed accepting a new altcoin that would reflect the consensus on inflation. Wladimir agreed with this idea, emphasizing that Bitcoin's economic parameters are fixed and adding a monetary authority to Bitcoin is both impossible and undesirable. However, he suggested that if the lack of inflation in Bitcoin becomes problematic in day-to-day usage, a parallel chain could emerge as the de-facto cryptocurrency for spending.A conversation between Gavin Andresen and Ryan Carboni discussed the tracking of exchanges in Bitcoin. Carboni proposed hard-coding exchanges into the system or allowing miners to choose them, but Andresen highlighted the need to focus on addressing the underlying problem instead of seeking a quick solution.Ryan Carboni argued in favor of the lack of a Central Bank in Bitcoin, stating that it is a feature rather than a bug. He also emphasized that political debates should be directed elsewhere and that the bitcoin-development forum is meant for technical discussions related to Bitcoin's development.Regarding the increase in Bitcoin's money supply, Ryan Carboni contended that it would not violate the trust of those holding the currency, as many people bought Bitcoin with the expectation of its value increasing. However, Jeff Garzik mocked Carboni's proposal, indicating that it was met with widespread laughter.The conversation between Gavin Andresen and Ryan Carboni touched upon the proposal to hard-code exchanges into Bitcoin or allow miners to choose them. However, Andresen pointed out the difficulty in solving the problem associated with this proposal, comparing it to wanting a fast way to travel without addressing the challenging aspects required for it to work.The idea of relying on data from third-party sources outside the Bitcoin network received negative feedback due to the potential vulnerabilities it poses. The proposal suggested hard-coding exchanges or allowing miners to choose, but consensus among miners is crucial to avoid rejected blocks. Many people invested in Bitcoin with hopes of its value increasing compared to other currencies, rather than solely relying on its fixed money supply. Nevertheless, Ryan Carboni's proposal faced mockery and laughter for its impracticality.Ryan Carboni argued that people invest in Bitcoin expecting an increase in its value compared to other currencies, highlighting the importance of exchanges for real goods transactions. However, Jeff Garzik, who works at BitPay, Inc., mocked Carboni's proposal based on its reception.In a 2013 email exchange, Mike/Casascius proposed that if there was a consensus for accepting inflation in Bitcoin, merchants would vote for changing the rules instead of adopting another altcoin. However, Andrew Poelstra argued that any change to the inflation formula would violate the trust of those who obtained Bitcoin under the belief that its inflation algorithm would remain unchanged. Ryan Carboni disagreed and stated that many people bought Bitcoin with hopes of significant appreciation in value. Earlier, Mike/Casascius had advocated for a fixed money supply on Bitcointalk, but his ideas were met with strong opposition.A Bitcoin Improvement Proposal suggested changing Bitcoin's inflation formula to address the lack of price stability, incentivize spending, and reduce speculation. The proposal recommended hard-coding or allowing miners to choose exchanges to track. Miners would compare the cumulative percentage change in exchange prices over preceding blocks, calculating the standard deviation and excluding outliers. This proposal aimed to achieve price stability without pegging Bitcoin to a specific currency. The proposal acknowledges the need for Bitcoin to have a closed economic ecosystem and reduce month-to-month variability, discouraging the perception of it being purely speculative. 2013-12-11T01:01:52+00:00 + Bitcoin's volatility is attributed to low liquidity and the ease with which a single large player can manipulate the market. The absence of common financial tools like shorting, futures, and options further contributes to this volatility. However, it is important to note that Bitcoin's volatility is a reflection of its future acceptance, which is influenced by inherently volatile sources such as politicians' opinions and government policies. The lack of stability in Bitcoin is also due to the absence of proof-of-work from society's end, which adds to its instability. As time progresses, laws, regulations, and policies will be established, bringing more stability to Bitcoin. This stability is expected to add value to Bitcoin within the range of $0.0001 to $100,000 per coin, regardless of whether the rulings are positive or negative.Discussions surrounding the feasibility of "stablecoins" in a secure and peer-to-peer system have been deemed off-topic and unfeasible on forums. While there have been proposals for stablecoins, implementing them securely in such a system has proven challenging. Participants in these discussions suggest asking questions to understand why these proposals are unfeasible rather than dismissing critiques as closed-mindedness.In December 2013, Mike Caldwell expressed his belief that if there was a consensus that Bitcoin's inflation parameters hindered its economy, merchants could vote for changing the rules. He proposed accepting a new altcoin that would reflect the consensus on inflation. Wladimir agreed with this idea, emphasizing that Bitcoin's economic parameters are fixed and adding a monetary authority to Bitcoin is both impossible and undesirable. However, he suggested that if the lack of inflation in Bitcoin becomes problematic in day-to-day usage, a parallel chain could emerge as the de-facto cryptocurrency for spending.A conversation between Gavin Andresen and Ryan Carboni discussed the tracking of exchanges in Bitcoin. Carboni proposed hard-coding exchanges into the system or allowing miners to choose them, but Andresen highlighted the need to focus on addressing the underlying problem instead of seeking a quick solution.Ryan Carboni argued in favor of the lack of a Central Bank in Bitcoin, stating that it is a feature rather than a bug. He also emphasized that political debates should be directed elsewhere and that the bitcoin-development forum is meant for technical discussions related to Bitcoin's development.Regarding the increase in Bitcoin's money supply, Ryan Carboni contended that it would not violate the trust of those holding the currency, as many people bought Bitcoin with the expectation of its value increasing. However, Jeff Garzik mocked Carboni's proposal, indicating that it was met with widespread laughter.The conversation between Gavin Andresen and Ryan Carboni touched upon the proposal to hard-code exchanges into Bitcoin or allow miners to choose them. However, Andresen pointed out the difficulty in solving the problem associated with this proposal, comparing it to wanting a fast way to travel without addressing the challenging aspects required for it to work.The idea of relying on data from third-party sources outside the Bitcoin network received negative feedback due to the potential vulnerabilities it poses. The proposal suggested hard-coding exchanges or allowing miners to choose, but consensus among miners is crucial to avoid rejected blocks. Many people invested in Bitcoin with hopes of its value increasing compared to other currencies, rather than solely relying on its fixed money supply. Nevertheless, Ryan Carboni's proposal faced mockery and laughter for its impracticality.Ryan Carboni argued that people invest in Bitcoin expecting an increase in its value compared to other currencies, highlighting the importance of exchanges for real goods transactions. However, Jeff Garzik, who works at BitPay, Inc., mocked Carboni's proposal based on its reception.In a 2013 email exchange, Mike/Casascius proposed that if there was a consensus for accepting inflation in Bitcoin, merchants would vote for changing the rules instead of adopting another altcoin. However, Andrew Poelstra argued that any change to the inflation formula would violate the trust of those who obtained Bitcoin under the belief that its inflation algorithm would remain unchanged. Ryan Carboni disagreed and stated that many people bought Bitcoin with hopes of significant appreciation in value. Earlier, Mike/Casascius had advocated for a fixed money supply on Bitcointalk, but his ideas were met with strong opposition.A Bitcoin Improvement Proposal suggested changing Bitcoin's inflation formula to address the lack of price stability, incentivize spending, and reduce speculation. The proposal recommended hard-coding or allowing miners to choose exchanges to track. Miners would compare the cumulative percentage change in exchange prices over preceding blocks, calculating the standard deviation and excluding outliers. This proposal aimed to achieve price stability without pegging Bitcoin to a specific currency. The proposal acknowledges the need for Bitcoin to have a closed economic ecosystem and reduce month-to-month variability, discouraging the perception of it being purely speculative. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Move-authorative-source-for-BIPs-to-git-repository.xml b/static/bitcoin-dev/Dec_2013/combined_Move-authorative-source-for-BIPs-to-git-repository.xml index 9e899ad78f..9f4bcdb934 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Move-authorative-source-for-BIPs-to-git-repository.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Move-authorative-source-for-BIPs-to-git-repository.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Move authorative source for BIPs to git repository - 2023-08-01T06:46:25.676184+00:00 + 2025-10-11T21:46:06.795420+00:00 + python-feedgen Wladimir 2013-12-06 13:41:16+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Move authorative source for BIPs to git repository - 2023-08-01T06:46:25.676184+00:00 + 2025-10-11T21:46:06.795576+00:00 - In an email thread, Gavin Andresen suggests replacing Bitcoin Improvement Proposals (BIPs) on the wiki with links to Github documents. He asks Wladimir or Gregory to update BIP 0001 to include the proper process for creating and editing a BIP, as it currently does not mention the Github repo at all. The conversation revolves around the use of Github versus the wiki for storing BIP documents.Jeff Garzik argues that using Github would be better due to its primary source status and mentions a process for submitting and editing BIPs via email or pull requests on Github. Luke-Jr disagrees, fearing that replacing BIPs on the wiki with links to Github could discourage active editing of drafts. No consensus is reached, but the repository for BIP documents on Github remains active.The discussion resurfaces, prompting a review of the previous conversation before repeating the same questions. A suggestion is made to replace BIPs on the wiki with links to Github documents, with a notice that changes should be proposed on Github or mailed to the BIP editor. Luke-Jr opposes this idea, believing it would hinder active BIP draft editing. He argues against adding additional hurdles for developers already struggling to write BIPs. Jeff Garzik is identified as a Bitcoin core developer and open-source evangelist at BitPay, Inc.On December 5, 2013, Wladimir expresses concern that using Github could hinder the editing process of BIPs. Luke-Jr questions why Github would be considered a hurdle, highlighting its easy collaboration through pull requests and web interfaces. He also notes that creating a Github account is easier than obtaining and activating a wiki account. Wladimir clarifies that his concern mainly relates to already accepted BIPs, which should not be edited without discussion, while drafts can still be submitted to the wiki if desired.In December 2013, Wladimir proposes a new repository at https://github.com/bitcoin/bips for storing BIPs, which is deemed more secure than the wiki. To avoid confusion, it is suggested that BIPs on the wiki be replaced with links to Github documents and notices that any changes should be proposed on Github or mailed to the BIP editor (gmaxwell). Luke-Jr opposes this suggestion, arguing that it would stifle active BIP draft editing and create additional difficulties for some developers. He believes bigger hurdles should not be imposed.As a result, a repository is recently created at https://github.com/bitcoin/bips to store BIP documents securely. The next step is to replace the BIPs on the wiki with links to the Github documents and include a notice that changes should be proposed on Github or mailed to the BIP editor, gmaxwell. This approach aims to prevent confusion among users, and Wladimir encourages agreement on this solution. 2013-12-06T13:41:16+00:00 + In an email thread, Gavin Andresen suggests replacing Bitcoin Improvement Proposals (BIPs) on the wiki with links to Github documents. He asks Wladimir or Gregory to update BIP 0001 to include the proper process for creating and editing a BIP, as it currently does not mention the Github repo at all. The conversation revolves around the use of Github versus the wiki for storing BIP documents.Jeff Garzik argues that using Github would be better due to its primary source status and mentions a process for submitting and editing BIPs via email or pull requests on Github. Luke-Jr disagrees, fearing that replacing BIPs on the wiki with links to Github could discourage active editing of drafts. No consensus is reached, but the repository for BIP documents on Github remains active.The discussion resurfaces, prompting a review of the previous conversation before repeating the same questions. A suggestion is made to replace BIPs on the wiki with links to Github documents, with a notice that changes should be proposed on Github or mailed to the BIP editor. Luke-Jr opposes this idea, believing it would hinder active BIP draft editing. He argues against adding additional hurdles for developers already struggling to write BIPs. Jeff Garzik is identified as a Bitcoin core developer and open-source evangelist at BitPay, Inc.On December 5, 2013, Wladimir expresses concern that using Github could hinder the editing process of BIPs. Luke-Jr questions why Github would be considered a hurdle, highlighting its easy collaboration through pull requests and web interfaces. He also notes that creating a Github account is easier than obtaining and activating a wiki account. Wladimir clarifies that his concern mainly relates to already accepted BIPs, which should not be edited without discussion, while drafts can still be submitted to the wiki if desired.In December 2013, Wladimir proposes a new repository at https://github.com/bitcoin/bips for storing BIPs, which is deemed more secure than the wiki. To avoid confusion, it is suggested that BIPs on the wiki be replaced with links to Github documents and notices that any changes should be proposed on Github or mailed to the BIP editor (gmaxwell). Luke-Jr opposes this suggestion, arguing that it would stifle active BIP draft editing and create additional difficulties for some developers. He believes bigger hurdles should not be imposed.As a result, a repository is recently created at https://github.com/bitcoin/bips to store BIP documents securely. The next step is to replace the BIPs on the wiki with links to the Github documents and include a notice that changes should be proposed on Github or mailed to the BIP editor, gmaxwell. This approach aims to prevent confusion among users, and Wladimir encourages agreement on this solution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Peer-Discovery-and-Overlay.xml b/static/bitcoin-dev/Dec_2013/combined_Peer-Discovery-and-Overlay.xml index 96b721bfdd..d53ee4c892 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Peer-Discovery-and-Overlay.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Peer-Discovery-and-Overlay.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Peer Discovery and Overlay - 2023-08-01T06:55:58.838260+00:00 + 2025-10-11T21:45:28.512516+00:00 + python-feedgen Mike Hearn 2013-12-24 17:15:00+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Peer Discovery and Overlay - 2023-08-01T06:55:58.838260+00:00 + 2025-10-11T21:45:28.512695+00:00 - Warren Togami Jr. has expressed concern about the reliance of Bitcoin node addresses on DNS seeds, prompting him to sponsor BlueMatt in implementing an address database for bitcoinj. This solution aims to reduce the dependency on DNS and enhance decentralization and scalability. Peter Todd also shares concerns about the compromises that can be made through DNS seeds. The implementation of the address database is crucial not only for decentralization but also for chain pruning. The developers are eagerly awaiting the review and merging of these changes.In December 2013, Peter Todd raised concerns about the heavy reliance of bitcoinj clients on DNS seeds for node addresses, as it made them vulnerable to compromise. As a response, Warren sponsored BlueMatt to develop an address database that would decrease this reliance on DNS.Jeremy Spilman brings up the topic of returning up to 2500 addresses from 'getaddr' and questions whether clients are expected to probe the address space to connect with distant peers. The response suggests that connecting to peers at random helps keep the network structure randomized, making it unnecessary to specifically attempt to connect with far-apart peers. The conversation then delves into the discussion of discovering the entire network of peers quickly or slowly, weighing the advantages and disadvantages of both approaches. They also touch upon the vulnerability of better knowledge of the network, considering the small number of full nodes that could be targeted in a DoS attack. Additionally, they highlight the vulnerability in the current mechanism of getaddr data, which lacks a mechanism to ensure separate individuals operate the nodes. This vulnerability could allow someone to set up a small number of nodes that dominate incoming connections. The discussion concludes by emphasizing the dependence of Bitcoinj clients on DNS seeds, which can pose various risks.In another email thread from December 2013, Jeremy Spilman inquires about instances of applications abusing the 'getaddr' functionality in Bitcoin's peer-to-peer messaging system and asks for guidelines on the matter. The response suggests that a BIP proposed by Stefan Thomas, which focuses on adding custom services to the protocol, could aid in network discovery. However, it is emphasized that these services should not be used in a hostile manner. The email provides links to two relevant BIPs, one regarding custom services and sub-commands and another outlining network discovery guidelines.Overall, efforts are being made to analyze and map the Bitcoin P2P network. Questions arise regarding the selection of distant peers and the speed of discovering the entire network. The vulnerability of better knowledge of the network and the potential for abuse of the 'getaddr' functionality are also highlighted. While there is no information on past instances of abuse or clear guidelines, the suggestion of using BIPs for network discovery is provided as a possible solution. 2013-12-24T17:15:00+00:00 + Warren Togami Jr. has expressed concern about the reliance of Bitcoin node addresses on DNS seeds, prompting him to sponsor BlueMatt in implementing an address database for bitcoinj. This solution aims to reduce the dependency on DNS and enhance decentralization and scalability. Peter Todd also shares concerns about the compromises that can be made through DNS seeds. The implementation of the address database is crucial not only for decentralization but also for chain pruning. The developers are eagerly awaiting the review and merging of these changes.In December 2013, Peter Todd raised concerns about the heavy reliance of bitcoinj clients on DNS seeds for node addresses, as it made them vulnerable to compromise. As a response, Warren sponsored BlueMatt to develop an address database that would decrease this reliance on DNS.Jeremy Spilman brings up the topic of returning up to 2500 addresses from 'getaddr' and questions whether clients are expected to probe the address space to connect with distant peers. The response suggests that connecting to peers at random helps keep the network structure randomized, making it unnecessary to specifically attempt to connect with far-apart peers. The conversation then delves into the discussion of discovering the entire network of peers quickly or slowly, weighing the advantages and disadvantages of both approaches. They also touch upon the vulnerability of better knowledge of the network, considering the small number of full nodes that could be targeted in a DoS attack. Additionally, they highlight the vulnerability in the current mechanism of getaddr data, which lacks a mechanism to ensure separate individuals operate the nodes. This vulnerability could allow someone to set up a small number of nodes that dominate incoming connections. The discussion concludes by emphasizing the dependence of Bitcoinj clients on DNS seeds, which can pose various risks.In another email thread from December 2013, Jeremy Spilman inquires about instances of applications abusing the 'getaddr' functionality in Bitcoin's peer-to-peer messaging system and asks for guidelines on the matter. The response suggests that a BIP proposed by Stefan Thomas, which focuses on adding custom services to the protocol, could aid in network discovery. However, it is emphasized that these services should not be used in a hostile manner. The email provides links to two relevant BIPs, one regarding custom services and sub-commands and another outlining network discovery guidelines.Overall, efforts are being made to analyze and map the Bitcoin P2P network. Questions arise regarding the selection of distant peers and the speed of discovering the entire network. The vulnerability of better knowledge of the network and the potential for abuse of the 'getaddr' functionality are also highlighted. While there is no information on past instances of abuse or clear guidelines, the suggestion of using BIPs for network discovery is provided as a possible solution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Popularity-based-mining-variable-block-reward-.xml b/static/bitcoin-dev/Dec_2013/combined_Popularity-based-mining-variable-block-reward-.xml index 327d7faf54..772b95bf70 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Popularity-based-mining-variable-block-reward-.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Popularity-based-mining-variable-block-reward-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Popularity based mining (variable block reward) - 2023-08-01T06:51:10.208896+00:00 + 2025-10-11T21:45:37.009175+00:00 + python-feedgen Jorge Timón 2013-12-10 17:18:40+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Popularity based mining (variable block reward) - 2023-08-01T06:51:10.208896+00:00 + 2025-10-11T21:45:37.009326+00:00 - In a mailing list discussion within the Bitcoin-development group, Jan Kučera has proposed a new system for determining block rewards. The proposal suggests that each network node should independently determine the popularity of the reward based on factors like coin valuation/exchange rate and number of transactions. This approach eliminates the need for external data and allows every node to decide the reward height.However, Jameson Lopp, a software engineer at Bronto Software, expressed skepticism towards this proposal. He raised concerns about relying on factors such as coin valuation/exchange rate. Lopp mentioned that this topic has been previously discussed on Bitcointalk.The email conversation between Lopp and Kučera took place in 2013. Kučera's proposal revolved around the concept of variable block rewards for mining, where the network itself determines the reward height. Factors like coin valuation/exchange rate and number of transactions would be considered by each node to determine the popularity and set the block reward value.Kučera also suggested that this alternative mining scheme could improve exchange rate stability in a hypothetical new coin. By allowing block rewards to grow or decrease with the coin's popularity, the exchange rate would become more stable, avoiding the price increase associated with greater interest. The author believes that Bitcoin currently lacks certain fundamental features of money and behaves more like a commodity such as gold. They have observed volatility in the exchange rate and propose changes to achieve a more stable currency.The proposed system would eliminate the reliance on external data, giving each network node the freedom to determine its own reward height. Each node would evaluate popularity based on various factors, including coin valuation/exchange rate and number of transactions. If a new block is mined with a specific reward value, it would be included in the node's chain. To prevent system collapse, there would be a tolerance percentage for block reward values.The author acknowledges the possibility of being wrong and seeks feedback from developers. They are interested in knowing whether similar ideas have been discussed before and what developers' opinions are on the proposal. The email was sent by Jorge Timón from freico.in, who appears to be affiliated with the discussion. 2013-12-10T17:18:40+00:00 + In a mailing list discussion within the Bitcoin-development group, Jan Kučera has proposed a new system for determining block rewards. The proposal suggests that each network node should independently determine the popularity of the reward based on factors like coin valuation/exchange rate and number of transactions. This approach eliminates the need for external data and allows every node to decide the reward height.However, Jameson Lopp, a software engineer at Bronto Software, expressed skepticism towards this proposal. He raised concerns about relying on factors such as coin valuation/exchange rate. Lopp mentioned that this topic has been previously discussed on Bitcointalk.The email conversation between Lopp and Kučera took place in 2013. Kučera's proposal revolved around the concept of variable block rewards for mining, where the network itself determines the reward height. Factors like coin valuation/exchange rate and number of transactions would be considered by each node to determine the popularity and set the block reward value.Kučera also suggested that this alternative mining scheme could improve exchange rate stability in a hypothetical new coin. By allowing block rewards to grow or decrease with the coin's popularity, the exchange rate would become more stable, avoiding the price increase associated with greater interest. The author believes that Bitcoin currently lacks certain fundamental features of money and behaves more like a commodity such as gold. They have observed volatility in the exchange rate and propose changes to achieve a more stable currency.The proposed system would eliminate the reliance on external data, giving each network node the freedom to determine its own reward height. Each node would evaluate popularity based on various factors, including coin valuation/exchange rate and number of transactions. If a new block is mined with a specific reward value, it would be included in the node's chain. To prevent system collapse, there would be a tolerance percentage for block reward values.The author acknowledges the possibility of being wrong and seeks feedback from developers. They are interested in knowing whether similar ideas have been discussed before and what developers' opinions are on the proposal. The email was sent by Jorge Timón from freico.in, who appears to be affiliated with the discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_RFC-MERGE-transaction-script-process-for-forked-chains.xml b/static/bitcoin-dev/Dec_2013/combined_RFC-MERGE-transaction-script-process-for-forked-chains.xml index da32708e01..85cc8e9e35 100644 --- a/static/bitcoin-dev/Dec_2013/combined_RFC-MERGE-transaction-script-process-for-forked-chains.xml +++ b/static/bitcoin-dev/Dec_2013/combined_RFC-MERGE-transaction-script-process-for-forked-chains.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC: MERGE transaction/script/process for forked chains - 2023-08-01T06:52:15.215473+00:00 + 2025-10-11T21:45:30.635431+00:00 + python-feedgen Troy Benjegerdes 2013-12-18 06:03:53+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - RFC: MERGE transaction/script/process for forked chains - 2023-08-01T06:52:15.216473+00:00 + 2025-10-11T21:45:30.635611+00:00 - In a discussion on the Bitcoin mailing list, Troy Benjegerdes sought feedback on merging different forks using distributed version control systems. However, Gregory Maxwell pointed out that Bitcoin already automatically merges forks by pulling in novel non-conflicting transactions contained in the fork and including them in the next blocks.The conversation then turned to the hard upper limit for the number of coins in Bitcoin, which raises issues for miners who try to support an islanded network. A potential solution is using freicoin-like demurrage, which would impact new coinbase based on the percentage of hashing power on the other side of the fork. This proposal is complex and not as secure or reliable as initially imagined.Troy Benjegerdes discusses the concept of merging two different forks in cryptocurrency, similar to how it is done in distributed version control systems. He poses a hypothetical scenario where he and his friends are "islanded" from the rest of the internet for a week but still want to trade Bitcoin. In this scenario, a miner would look at the forked blockchain and include both chains if no double-spends were detected. However, if there is a merge conflict due to a buggy client or a transaction resulting in a double-spend before disconnect, then a MERGE request with a transaction fee sufficient to cover reconciling the double-spends would be broadcasted to incentivize miners to do extra work to merge.Luke expresses concern about the incentives of this proposal, stating that it may give miners reasons to avoid including transactions and people reason to double-spend. Additionally, the email does not address how to deal with the subsidy - whether both miners get it or not.The Bitcoin community is discussing whether a “merge” block is necessary for trading transactions offline. Transactions can be traded offline as long as there are no secretly double-spending coins that are sent to the Blockchain. When the connection to the Bitcoin network is re-established, transactions are transmitted, while any transactions that derive from the double-spent one become invalid. If any merge conflict arises, it would require human interaction, and bob and his friends broadcast a MERGE request with a transaction fee sufficient to cover reconciling the double-spends, and incentivize a miner to do some extra work to merge. There is no need for a "merge" block, as transactions can be traded offline and then transmitted when the connection to the Bitcoin network is restored.In an email thread from 2013, Troy Benjegerdes expressed his interest in receiving feedback on distributed version control systems. He specifically mentioned the usefulness of being able to merge two different forks. However, it was noted that the system already automatically merges forks by pulling in all novel non-conflicting transactions and including them in the next blocks. The context does not provide any further information on this automatic process or the specific version control system being referred to.The author seeks feedback on the equivalent of merging forks in distributed version control systems for Bitcoin or other cryptocurrencies. They pose a scenario where they are 'islanded' from the internet but still want to trade Bitcoin, and suggest that local miners could facilitate this until reconnected. The author further explains the concept of Merge transactions, wherein a miner looks at a forked blockchain and includes both chains if no double-spends exist. However, in case of a buggy client or a double-spend transaction, a merge conflict arises, requiring human intervention. To address this issue, the author suggests broadcasting a MERGE request with a transaction fee sufficient to cover reconciling the double-spends and incentivizing a miner to do extra work to merge. 2013-12-18T06:03:53+00:00 + In a discussion on the Bitcoin mailing list, Troy Benjegerdes sought feedback on merging different forks using distributed version control systems. However, Gregory Maxwell pointed out that Bitcoin already automatically merges forks by pulling in novel non-conflicting transactions contained in the fork and including them in the next blocks.The conversation then turned to the hard upper limit for the number of coins in Bitcoin, which raises issues for miners who try to support an islanded network. A potential solution is using freicoin-like demurrage, which would impact new coinbase based on the percentage of hashing power on the other side of the fork. This proposal is complex and not as secure or reliable as initially imagined.Troy Benjegerdes discusses the concept of merging two different forks in cryptocurrency, similar to how it is done in distributed version control systems. He poses a hypothetical scenario where he and his friends are "islanded" from the rest of the internet for a week but still want to trade Bitcoin. In this scenario, a miner would look at the forked blockchain and include both chains if no double-spends were detected. However, if there is a merge conflict due to a buggy client or a transaction resulting in a double-spend before disconnect, then a MERGE request with a transaction fee sufficient to cover reconciling the double-spends would be broadcasted to incentivize miners to do extra work to merge.Luke expresses concern about the incentives of this proposal, stating that it may give miners reasons to avoid including transactions and people reason to double-spend. Additionally, the email does not address how to deal with the subsidy - whether both miners get it or not.The Bitcoin community is discussing whether a “merge” block is necessary for trading transactions offline. Transactions can be traded offline as long as there are no secretly double-spending coins that are sent to the Blockchain. When the connection to the Bitcoin network is re-established, transactions are transmitted, while any transactions that derive from the double-spent one become invalid. If any merge conflict arises, it would require human interaction, and bob and his friends broadcast a MERGE request with a transaction fee sufficient to cover reconciling the double-spends, and incentivize a miner to do some extra work to merge. There is no need for a "merge" block, as transactions can be traded offline and then transmitted when the connection to the Bitcoin network is restored.In an email thread from 2013, Troy Benjegerdes expressed his interest in receiving feedback on distributed version control systems. He specifically mentioned the usefulness of being able to merge two different forks. However, it was noted that the system already automatically merges forks by pulling in all novel non-conflicting transactions and including them in the next blocks. The context does not provide any further information on this automatic process or the specific version control system being referred to.The author seeks feedback on the equivalent of merging forks in distributed version control systems for Bitcoin or other cryptocurrencies. They pose a scenario where they are 'islanded' from the internet but still want to trade Bitcoin, and suggest that local miners could facilitate this until reconnected. The author further explains the concept of Merge transactions, wherein a miner looks at a forked blockchain and includes both chains if no double-spends exist. However, in case of a buggy client or a double-spend transaction, a merge conflict arises, requiring human intervention. To address this issue, the author suggests broadcasting a MERGE request with a transaction fee sufficient to cover reconciling the double-spends and incentivizing a miner to do extra work to merge. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Suggestion-easy-way-to-restore-wallet-dat-backup.xml b/static/bitcoin-dev/Dec_2013/combined_Suggestion-easy-way-to-restore-wallet-dat-backup.xml index 0f5ee19440..57fa0b33c3 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Suggestion-easy-way-to-restore-wallet-dat-backup.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Suggestion-easy-way-to-restore-wallet-dat-backup.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Suggestion: easy way to restore wallet.dat backup - 2023-08-01T06:46:05.923573+00:00 + 2025-10-11T21:45:43.431486+00:00 + python-feedgen Casey Rodarmor 2013-12-04 05:16:18+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Suggestion: easy way to restore wallet.dat backup - 2023-08-01T06:46:05.923573+00:00 + 2025-10-11T21:45:43.431624+00:00 - The bitcoin-qt client allows users to easily backup their wallet.dat file, but restoring it is a more complicated process. Currently, users have to copy the file to the correct folder and execute "bitcoin-qt -rescan". The author of a post on bitcoin-user believes that this is part of a larger user experience (UX) problem with bitcoin-qt.To address this issue, the author suggests a document-oriented approach to wallets. This would involve making users select a location to store their wallet and automatically opening the most recent wallet when running the program. Additionally, the author proposes allowing users to open a wallet by simply double-clicking it directly in the operating system.While this approach may bring about considerations such as having multiple wallets open simultaneously, moving wallet files while they are open, and the need to periodically backup wallets, the author argues that the improved usability would outweigh these potential complications.Furthermore, the author recommends adopting BIP 32 style deterministically derived private keys from a single seed. This would eliminate some of the issues associated with wallet restoration and management.In conclusion, the author highlights the importance of making operations like wallet backup and restoration as easy as possible to encourage more people to use bitcoin. Despite posting the message on bitcoin-user, the author did not receive any replies to their suggestions. 2013-12-04T05:16:18+00:00 + The bitcoin-qt client allows users to easily backup their wallet.dat file, but restoring it is a more complicated process. Currently, users have to copy the file to the correct folder and execute "bitcoin-qt -rescan". The author of a post on bitcoin-user believes that this is part of a larger user experience (UX) problem with bitcoin-qt.To address this issue, the author suggests a document-oriented approach to wallets. This would involve making users select a location to store their wallet and automatically opening the most recent wallet when running the program. Additionally, the author proposes allowing users to open a wallet by simply double-clicking it directly in the operating system.While this approach may bring about considerations such as having multiple wallets open simultaneously, moving wallet files while they are open, and the need to periodically backup wallets, the author argues that the improved usability would outweigh these potential complications.Furthermore, the author recommends adopting BIP 32 style deterministically derived private keys from a single seed. This would eliminate some of the issues associated with wallet restoration and management.In conclusion, the author highlights the importance of making operations like wallet backup and restoration as easy as possible to encourage more people to use bitcoin. Despite posting the message on bitcoin-user, the author did not receive any replies to their suggestions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Temporary-fee-fix.xml b/static/bitcoin-dev/Dec_2013/combined_Temporary-fee-fix.xml index 551edebdb3..ad2c752aee 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Temporary-fee-fix.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Temporary-fee-fix.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Temporary fee fix - 2023-08-01T06:46:34.821468+00:00 + 2025-10-11T21:46:04.671844+00:00 + python-feedgen Wladimir 2013-12-06 08:37:55+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Temporary fee fix - 2023-08-01T06:46:34.821468+00:00 + 2025-10-11T21:46:04.672012+00:00 - In December 2013, Andreas Petersson proposed a suggestion to lower the minimum relay fee per kb in Bitcoin. Currently, the fixed fee is set at 0.1 mBTC, which has received criticism from users, with some comparing it unfavorably to bank fees. However, this proposal was deemed too risky for version 0.8.6 of Bitcoin and it was decided that the change would be implemented in version 0.9, unless the full floating fee implementation is ready and considered safe by then.The author acknowledges the need for a new fee market but highlights that until it is established, users will continue to complain about the high fixed fee. The negative reviews of Mycelium on the Google Play Store specifically mention the high fees as a negative aspect. To address these concerns in the interim, the author suggests lowering the minimum relay fee per kilobyte to alleviate user dissatisfaction. However, no concrete reasoning is provided behind the suggested amount of 0.01 mBTC. It is worth noting that banks have been observed to sometimes have lower fees than Bitcoin's current fee structure. 2013-12-06T08:37:55+00:00 + In December 2013, Andreas Petersson proposed a suggestion to lower the minimum relay fee per kb in Bitcoin. Currently, the fixed fee is set at 0.1 mBTC, which has received criticism from users, with some comparing it unfavorably to bank fees. However, this proposal was deemed too risky for version 0.8.6 of Bitcoin and it was decided that the change would be implemented in version 0.9, unless the full floating fee implementation is ready and considered safe by then.The author acknowledges the need for a new fee market but highlights that until it is established, users will continue to complain about the high fixed fee. The negative reviews of Mycelium on the Google Play Store specifically mention the high fees as a negative aspect. To address these concerns in the interim, the author suggests lowering the minimum relay fee per kilobyte to alleviate user dissatisfaction. However, no concrete reasoning is provided behind the suggested amount of 0.01 mBTC. It is worth noting that banks have been observed to sometimes have lower fees than Bitcoin's current fee structure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_Testnet-block-explorer.xml b/static/bitcoin-dev/Dec_2013/combined_Testnet-block-explorer.xml index 1de35a6868..aee6aac802 100644 --- a/static/bitcoin-dev/Dec_2013/combined_Testnet-block-explorer.xml +++ b/static/bitcoin-dev/Dec_2013/combined_Testnet-block-explorer.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Testnet block explorer - 2023-08-01T07:06:39.687518+00:00 + 2025-10-11T21:46:02.549671+00:00 + python-feedgen Matias Alejo Garcia 2014-02-16 14:49:40+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Testnet block explorer - 2023-08-01T07:06:39.687518+00:00 + 2025-10-11T21:46:02.549838+00:00 - Matías Alejo Garcia, a developer for BitPay, has invited people to contribute to the GitHub page for Bitcore and Insight. Insight is a software package that can be downloaded, installed, and used alongside a trusted bitcoind instance. It offers blockchain query capabilities through its REST/Websockets API, which is explained in the Readme document. The demo installations of live.bitcore.io and test.bitcore.io are just for demonstration purposes.Melvin Carvalho has shared information about a free software testnet explorer called test.bitcore.io, which is based on javascript/node. He also mentioned his work on a testnet explorer and the possibility of adding semantic web style markup attributes to the HTML. There is also an API for the testnet block explorer provided by biteasy.com at https://www.biteasy.com/testnet/blocks.On December 27th, 2013, Mike Hearn posted on the Bitcoin-development mailing list about the lack of a reliable testnet block explorer. He mentioned that the original blockexplorer.com was often broken, slow, and not maintained anymore. However, he provided an alternative, a new block explorer called Biteasy, which also had a REST/JSON API. Hearn noted that the coinbase transaction may not necessarily come first in the listing due to it being sorted by "time received". The Biteasy site was built using bitcoinj, and the author could be contacted on IRC with the nick damethos. Hearn also shared information on other testnet explorers such as test.bitcore.io and mentioned his plan to fork the Bitcore explorer to add semantic web style markup attributes to the HTML. He also mentioned that blockr.io planned to add testnet but could not provide an estimate on when it would happen.Eric Lombrozo has created a shell around the bitcoind JSON-RPC, along with a websockets server that provides real-time transaction and block feeds. This shell can be used with bitcoin mainnet, testnet, and alt chains. The layout of the shell is similar to blockchain.info with a bootstrap look-and-feel. Lombrozo apologized for using the css from Ben's site and offered to collaborate with anyone who could help make the styling original. However, the JSON-RPC is missing address indexing and an "unspent" API.There are other testnet explorers mentioned by Melvin Carvalho, such as http://testnet.btclook.com/ and http://test.webbtc.com/. However, these explorers are not fully functional for creating transactions due to the lack of an "unspent" API. Mike Hearn also mentioned the new block explorer at https://www.biteasy.com/testnet/blocks, which is built using bitcoinj and has a REST/JSON API. He noted that the coinbase tx may not come first in the listing as it's sorted by "time received".In summary, there are several options available for testnet block explorers. The original blockexplorer.com is often broken, slow, and not maintained anymore. However, alternatives like Biteasy and test.bitcore.io offer reliable options with REST/JSON APIs. Additionally, Eric Lombrozo has created a shell around the bitcoind JSON-RPC that provides real-time transaction and block feeds. While there are some limitations, such as missing address indexing and an "unspent" API, these explorers provide valuable tools for exploring the testnet. 2014-02-16T14:49:40+00:00 + Matías Alejo Garcia, a developer for BitPay, has invited people to contribute to the GitHub page for Bitcore and Insight. Insight is a software package that can be downloaded, installed, and used alongside a trusted bitcoind instance. It offers blockchain query capabilities through its REST/Websockets API, which is explained in the Readme document. The demo installations of live.bitcore.io and test.bitcore.io are just for demonstration purposes.Melvin Carvalho has shared information about a free software testnet explorer called test.bitcore.io, which is based on javascript/node. He also mentioned his work on a testnet explorer and the possibility of adding semantic web style markup attributes to the HTML. There is also an API for the testnet block explorer provided by biteasy.com at https://www.biteasy.com/testnet/blocks.On December 27th, 2013, Mike Hearn posted on the Bitcoin-development mailing list about the lack of a reliable testnet block explorer. He mentioned that the original blockexplorer.com was often broken, slow, and not maintained anymore. However, he provided an alternative, a new block explorer called Biteasy, which also had a REST/JSON API. Hearn noted that the coinbase transaction may not necessarily come first in the listing due to it being sorted by "time received". The Biteasy site was built using bitcoinj, and the author could be contacted on IRC with the nick damethos. Hearn also shared information on other testnet explorers such as test.bitcore.io and mentioned his plan to fork the Bitcore explorer to add semantic web style markup attributes to the HTML. He also mentioned that blockr.io planned to add testnet but could not provide an estimate on when it would happen.Eric Lombrozo has created a shell around the bitcoind JSON-RPC, along with a websockets server that provides real-time transaction and block feeds. This shell can be used with bitcoin mainnet, testnet, and alt chains. The layout of the shell is similar to blockchain.info with a bootstrap look-and-feel. Lombrozo apologized for using the css from Ben's site and offered to collaborate with anyone who could help make the styling original. However, the JSON-RPC is missing address indexing and an "unspent" API.There are other testnet explorers mentioned by Melvin Carvalho, such as http://testnet.btclook.com/ and http://test.webbtc.com/. However, these explorers are not fully functional for creating transactions due to the lack of an "unspent" API. Mike Hearn also mentioned the new block explorer at https://www.biteasy.com/testnet/blocks, which is built using bitcoinj and has a REST/JSON API. He noted that the coinbase tx may not come first in the listing as it's sorted by "time received".In summary, there are several options available for testnet block explorers. The original blockexplorer.com is often broken, slow, and not maintained anymore. However, alternatives like Biteasy and test.bitcore.io offer reliable options with REST/JSON APIs. Additionally, Eric Lombrozo has created a shell around the bitcoind JSON-RPC that provides real-time transaction and block feeds. While there are some limitations, such as missing address indexing and an "unspent" API, these explorers provide valuable tools for exploring the testnet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2013/combined_bitcoin-qt.xml b/static/bitcoin-dev/Dec_2013/combined_bitcoin-qt.xml index 0c0565e932..5c56469e35 100644 --- a/static/bitcoin-dev/Dec_2013/combined_bitcoin-qt.xml +++ b/static/bitcoin-dev/Dec_2013/combined_bitcoin-qt.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin-qt - 2023-08-01T06:55:23.641163+00:00 + 2025-10-11T21:46:19.542297+00:00 + python-feedgen Wladimir 2013-12-20 08:10:03+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - bitcoin-qt - 2023-08-01T06:55:23.641163+00:00 + 2025-10-11T21:46:19.542482+00:00 - In an email exchange on December 20, 2013, Chris Evans proposed a modification to the bitcoin.conf settings. He suggested that these settings should be editable within the app itself, rather than relying on an external editor. Additionally, he recommended making it easier to enable rpc server mode.Wladimir, in response, acknowledged the importance of testing Diapolo's pull request. This pull request aimed to enhance the options dialog and add a few options, which would benefit both Wladimir and Diapolo. However, Wladimir cautioned against creating a situation where users could inadvertently compromise security by easily modifying RPC settings.It is worth noting that the message primarily focuses on JSON-RPC, which is considered a security risk. The author emphasizes that enabling JSON-RPC should require a certain level of technical expertise. This cautionary approach aims to prevent users from unintentionally exposing themselves to potential vulnerabilities.The email also includes a PGP signature from the author, ensuring the authenticity and integrity of the message. Overall, the suggestion put forth is to allow users to edit bitcoin.conf settings directly within the app, while simultaneously simplifying the process of enabling rpc server mode. 2013-12-20T08:10:03+00:00 + In an email exchange on December 20, 2013, Chris Evans proposed a modification to the bitcoin.conf settings. He suggested that these settings should be editable within the app itself, rather than relying on an external editor. Additionally, he recommended making it easier to enable rpc server mode.Wladimir, in response, acknowledged the importance of testing Diapolo's pull request. This pull request aimed to enhance the options dialog and add a few options, which would benefit both Wladimir and Diapolo. However, Wladimir cautioned against creating a situation where users could inadvertently compromise security by easily modifying RPC settings.It is worth noting that the message primarily focuses on JSON-RPC, which is considered a security risk. The author emphasizes that enabling JSON-RPC should require a certain level of technical expertise. This cautionary approach aims to prevent users from unintentionally exposing themselves to potential vulnerabilities.The email also includes a PGP signature from the author, ensuring the authenticity and integrity of the message. Overall, the suggestion put forth is to allow users to edit bitcoin.conf settings directly within the app, while simultaneously simplifying the process of enabling rpc server mode. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_ACK-NACK-utACK-Concept-ACK-.xml b/static/bitcoin-dev/Dec_2014/combined_ACK-NACK-utACK-Concept-ACK-.xml index fe6a14e07f..2852d4ce73 100644 --- a/static/bitcoin-dev/Dec_2014/combined_ACK-NACK-utACK-Concept-ACK-.xml +++ b/static/bitcoin-dev/Dec_2014/combined_ACK-NACK-utACK-Concept-ACK-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - ACK NACK utACK "Concept ACK" - 2023-08-01T10:56:06.338307+00:00 + Combined summary - ACK NACK utACK "Concept ACK" + 2025-10-11T21:53:54.468127+00:00 + python-feedgen Wladimir 2014-12-17 08:44:45+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 - Combined summary - ACK NACK utACK "Concept ACK" - 2023-08-01T10:56:06.338307+00:00 + Combined summary - ACK NACK utACK "Concept ACK" + 2025-10-11T21:53:54.468276+00:00 - In an email thread on December 10th, 2014, Austin Walne expressed his willingness to write up some documentation based on the questions raised. He also asked for any other key terminologies that should be included in the document. It was mentioned in the same thread that Fanquake had already started working on the documentation, although it wasn't mentioned in the email exchange. A link to Fanquake's work was provided on Github. Wladimir was also a part of this conversation.In a Bitcoin development mailing list, a member named Drak asks for clarification on the use of "nit" in the context of nitpicking and how it affects consensus. Drak believes that it is used for minor complaints or preferences. In response, Jeff Garzik, a Bitcoin core developer and open source evangelist, explains the concept ACK (acknowledgement), which means agreeing with the idea and overall direction but not having reviewed the code changes nor tested it. He also provides another explanation of concept ACK as liking the idea but needing code rewriting or not having reviewed it yet. The email includes a promotion for BIRT iHub F-Type, a free enterprise-grade BIRT server.In an email exchange on December 10th, 2014, Bitcoin core developer Jeff Garzik received a message from Wladimir expressing a "Concept ACK" regarding an idea proposed. The term "Concept ACK" indicates agreement with the overall direction of the proposal but acknowledges that the code changes have not been reviewed or tested. In this case, Wladimir liked the idea but suggested that the code may need rewriting or further review before implementation. Jeff Garzik is an open-source evangelist and also works at BitPay, Inc., a company that provides bitcoin payment processing services.A user on the Bitcoin-development mailing list had requested documentation explaining key terminology used within code reviews. In response, Wladimir provided a list of abbreviations, including 'Concept ACK', 'utACK', and 'Tested ACK'. He also mentioned the term 'NACK', which means a reviewer wouldn't like the code merged, providing further explanation in the text. Wladimir expressed that a document on this would be useful as it may not be easily understood by outsiders. The user thanked Wladimir for his response and offered to draft something based on the thread.In an email thread from December 2014, Wladimir discussed the different types of acknowledgments used when reviewing code changes for the Bitcoin software. He explained that a "Concept ACK" means agreeing with the idea and direction of the change, but not having reviewed or tested the code. A "utACK" means that the reviewer has looked at the code changes, but has not tested them. Finally, a "Tested ACK" means that the reviewer has both reviewed and tested the code changes and verified their functionality. Wladimir also mentioned the use of NACK, which is a more specific rejection of a code change with an explanation provided. He suggested that a document explaining these terms would be helpful for outsiders as it can be confusing to understand the different levels of acknowledgment without context. Despite this suggestion being made before, no such document had been created at the time of the email.In a Bitcoin-development mailing list, the terms "Concept ACK," "utACK," and "Tested ACK" were discussed. "Concept ACK" means agreeing with the idea and overall direction but not reviewing the code changes nor testing it. "utACK" means reviewing the code changes, but not putting it through any testing. "Tested ACK" means reviewing the code changes and verifying the functionality/bug fix. Wladimir mentioned that he only uses bare "ACK" if there is nothing to test in the first place, for example, for documentation changes. Matt Corallo mentioned that people use "utACK" and "tested ack" when being explicit. Sergio Lerner asked if there are more acronyms and if these terms are documented somewhere.During a discussion on the Bitcoin-development mailing list, the terms "utACK" and "tested ack" were mentioned as acronyms for untested and tested acknowledgment. Sergio Lerner asked if there were any other acronyms or if these were documented somewhere. The conversation ended with a link to download BIRT iHub F-Type, which provides free enterprise-grade BIRT server technology for business reports and dashboards with interactivity and app integration, among others.In this context, it seems that Sergio is asking for clarification on a certain terminology or acronym. It is unclear what the specific term or acronym is, but Sergio is seeking to know if there are other related acronyms or if there is any documentation available. Without knowing the exact context of the conversation or topic being discussed, it is difficult to provide further information. However, it can be assumed that Sergio is looking to improve his understanding of a particular concept or jargon. It is important to note that when communicating with others, 2014-12-17T08:44:45+00:00 + In an email thread on December 10th, 2014, Austin Walne expressed his willingness to write up some documentation based on the questions raised. He also asked for any other key terminologies that should be included in the document. It was mentioned in the same thread that Fanquake had already started working on the documentation, although it wasn't mentioned in the email exchange. A link to Fanquake's work was provided on Github. Wladimir was also a part of this conversation.In a Bitcoin development mailing list, a member named Drak asks for clarification on the use of "nit" in the context of nitpicking and how it affects consensus. Drak believes that it is used for minor complaints or preferences. In response, Jeff Garzik, a Bitcoin core developer and open source evangelist, explains the concept ACK (acknowledgement), which means agreeing with the idea and overall direction but not having reviewed the code changes nor tested it. He also provides another explanation of concept ACK as liking the idea but needing code rewriting or not having reviewed it yet. The email includes a promotion for BIRT iHub F-Type, a free enterprise-grade BIRT server.In an email exchange on December 10th, 2014, Bitcoin core developer Jeff Garzik received a message from Wladimir expressing a "Concept ACK" regarding an idea proposed. The term "Concept ACK" indicates agreement with the overall direction of the proposal but acknowledges that the code changes have not been reviewed or tested. In this case, Wladimir liked the idea but suggested that the code may need rewriting or further review before implementation. Jeff Garzik is an open-source evangelist and also works at BitPay, Inc., a company that provides bitcoin payment processing services.A user on the Bitcoin-development mailing list had requested documentation explaining key terminology used within code reviews. In response, Wladimir provided a list of abbreviations, including 'Concept ACK', 'utACK', and 'Tested ACK'. He also mentioned the term 'NACK', which means a reviewer wouldn't like the code merged, providing further explanation in the text. Wladimir expressed that a document on this would be useful as it may not be easily understood by outsiders. The user thanked Wladimir for his response and offered to draft something based on the thread.In an email thread from December 2014, Wladimir discussed the different types of acknowledgments used when reviewing code changes for the Bitcoin software. He explained that a "Concept ACK" means agreeing with the idea and direction of the change, but not having reviewed or tested the code. A "utACK" means that the reviewer has looked at the code changes, but has not tested them. Finally, a "Tested ACK" means that the reviewer has both reviewed and tested the code changes and verified their functionality. Wladimir also mentioned the use of NACK, which is a more specific rejection of a code change with an explanation provided. He suggested that a document explaining these terms would be helpful for outsiders as it can be confusing to understand the different levels of acknowledgment without context. Despite this suggestion being made before, no such document had been created at the time of the email.In a Bitcoin-development mailing list, the terms "Concept ACK," "utACK," and "Tested ACK" were discussed. "Concept ACK" means agreeing with the idea and overall direction but not reviewing the code changes nor testing it. "utACK" means reviewing the code changes, but not putting it through any testing. "Tested ACK" means reviewing the code changes and verifying the functionality/bug fix. Wladimir mentioned that he only uses bare "ACK" if there is nothing to test in the first place, for example, for documentation changes. Matt Corallo mentioned that people use "utACK" and "tested ack" when being explicit. Sergio Lerner asked if there are more acronyms and if these terms are documented somewhere.During a discussion on the Bitcoin-development mailing list, the terms "utACK" and "tested ack" were mentioned as acronyms for untested and tested acknowledgment. Sergio Lerner asked if there were any other acronyms or if these were documented somewhere. The conversation ended with a link to download BIRT iHub F-Type, which provides free enterprise-grade BIRT server technology for business reports and dashboards with interactivity and app integration, among others.In this context, it seems that Sergio is asking for clarification on a certain terminology or acronym. It is unclear what the specific term or acronym is, but Sergio is seeking to know if there are other related acronyms or if there is any documentation available. Without knowing the exact context of the conversation or topic being discussed, it is difficult to provide further information. However, it can be assumed that Sergio is looking to improve his understanding of a particular concept or jargon. It is important to note that when communicating with others, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Area-of-Focus.xml b/static/bitcoin-dev/Dec_2014/combined_Area-of-Focus.xml index 8276df9982..d894a7600d 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Area-of-Focus.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Area-of-Focus.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Area of Focus - 2023-08-01T10:59:31.375636+00:00 + 2025-10-11T21:53:39.588565+00:00 + python-feedgen Will Bickford 2014-12-20 22:37:58+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Area of Focus - 2023-08-01T10:59:31.376637+00:00 + 2025-10-11T21:53:39.588759+00:00 - Jeff Garzik recommended that Will take a look at how the current tests are built in src/test, including RPC, REST, P2P, internal unit tests, and more. He suggested operating automated tests at the Qt level and joining #bitcoin-dev IRC to ask questions and read the Bitcoin wiki. The current tests only scratch the surface of what needs to be tested, so there is plenty of room for improvement in this area.There have been discussions regarding DNS seeds being blocked by ISPs because some of the hosts they pick up run Bitcoin Core nodes alongside malware-serving web servers. It is unclear how ISPs are reading the DNS seed's node list and scanning those IPs for malware before ending up blocking the DNS seed. A potential solution may be supporting a subdomain with results XORed with some constant mask to tweak the real IP. It may also be useful to add a TXT/AAAA/whatever record with a signature of the results provided by the DNSseed operator.Will Bickford expressed an interest in contributing to Bitcoin development testing and requested feedback on where he can make the most significant impact. Christian Decker added a safety check to his crawler, hoping to prevent it from being blacklisted. The Bitcoin community is currently discussing ways to address the issue of DNS seeds being blocked by ISPs due to the hosts they pick up, which often run malware or other web servers alongside. Despite the desire to maintain DNS because of its built-in anonymity network, there is a need for a potential solution that will prevent ISP's from blocking these seeds.In summary, Will Bickford is interested in contributing to Bitcoin core development, particularly in the area of testing. There are discussions about DNS seeds being blocked by ISPs due to the presence of malware-serving web servers alongside Bitcoin Core nodes. Potential solutions include supporting subdomains and adding signatures to DNS records. The Bitcoin community is actively working on addressing this issue to ensure the smooth functioning of the network. 2014-12-20T22:37:58+00:00 + Jeff Garzik recommended that Will take a look at how the current tests are built in src/test, including RPC, REST, P2P, internal unit tests, and more. He suggested operating automated tests at the Qt level and joining #bitcoin-dev IRC to ask questions and read the Bitcoin wiki. The current tests only scratch the surface of what needs to be tested, so there is plenty of room for improvement in this area.There have been discussions regarding DNS seeds being blocked by ISPs because some of the hosts they pick up run Bitcoin Core nodes alongside malware-serving web servers. It is unclear how ISPs are reading the DNS seed's node list and scanning those IPs for malware before ending up blocking the DNS seed. A potential solution may be supporting a subdomain with results XORed with some constant mask to tweak the real IP. It may also be useful to add a TXT/AAAA/whatever record with a signature of the results provided by the DNSseed operator.Will Bickford expressed an interest in contributing to Bitcoin development testing and requested feedback on where he can make the most significant impact. Christian Decker added a safety check to his crawler, hoping to prevent it from being blacklisted. The Bitcoin community is currently discussing ways to address the issue of DNS seeds being blocked by ISPs due to the hosts they pick up, which often run malware or other web servers alongside. Despite the desire to maintain DNS because of its built-in anonymity network, there is a need for a potential solution that will prevent ISP's from blocking these seeds.In summary, Will Bickford is interested in contributing to Bitcoin core development, particularly in the area of testing. There are discussions about DNS seeds being blocked by ISPs due to the presence of malware-serving web servers alongside Bitcoin Core nodes. Potential solutions include supporting subdomains and adding signatures to DNS records. The Bitcoin community is actively working on addressing this issue to ensure the smooth functioning of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_BIP-Voluntary-deposit-bonds.xml b/static/bitcoin-dev/Dec_2014/combined_BIP-Voluntary-deposit-bonds.xml index 09f015a1f8..dae64f3a8a 100644 --- a/static/bitcoin-dev/Dec_2014/combined_BIP-Voluntary-deposit-bonds.xml +++ b/static/bitcoin-dev/Dec_2014/combined_BIP-Voluntary-deposit-bonds.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: Voluntary deposit bonds - 2023-08-01T11:04:11.867695+00:00 + 2025-10-11T21:53:52.343290+00:00 + python-feedgen Peter Todd 2015-01-03 03:48:29+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - BIP: Voluntary deposit bonds - 2023-08-01T11:04:11.867695+00:00 + 2025-10-11T21:53:52.343489+00:00 - Sergio Lerner, a Bitcoin developer, has proposed a modification to the code that would allow miners to add real inputs to the coinbase transaction, instead of just pseudo-inputs. This change would enable miners to voluntarily lock funds. Lerner believes that this modification is necessary to secure the blockchain in the future when the subsidy is lowered. He argues that increasing the number of confirmation blocks could make Bitcoin less competitive with other payment networks. However, there are concerns about this proposal. Peter Todd, another Bitcoin developer, worries that it could change incentives and make it easier for individuals to pay miners to mine specific blocks rather than transactions. There are also doubts about the PowPay micropayments scheme, which may incentivize mining pools to grow larger.Gregory Maxwell and Stephen have suggested alternative ways to pay specific miners upon solving a block without risking paying other miners through pay-to-fee. Gregory suggests using Gavin's OP_EVAL, but acknowledges that it would require additional changes to overlay functionality. Stephen proposes a solution involving outputs in the coinbase transaction with nValue == 0, and applying the COINBASE_MATURITY rule only to spending coinbase outputs with non-zero value. However, this solution would still require a hard fork.In a conversation on the Bitcoin-development mailing list, Sergio expresses concern about the complexity of Bitcoin and argues that it needs to be simple for new programmers to understand and contribute to the project. He suggests that even P2SH is an abuse of the virtual machine (VM) and that Gavin's OP_EVAL should have been chosen instead. Others clarify that there is no abuse occurring and that Sergio's proposal would require an additional change to overlay functionality, which may be considered "ugly."Sergio Lerner's idea of allowing miners to lock funds by adding additional inputs to the coinbase transaction has been proposed since 2011 but hasn't been a priority until now. The motivation behind the proposal is to address potential security problems in the future as the subsidy is lowered. However, there are concerns about increasing the complexity of Bitcoin. Some suggest that a hard fork now could allow for a later implementation of a soft fork involving deposit bonds, proof-of-stake, and penalization of double-mining.Justus Ranvier explains in a discussion with Jorge Timón that allowing miners to pay themselves by adding inputs to the generation transaction is the most natural way for their customers to pay them. This method is more secure than pay-to-fee transactions because the fees cannot be claimed by another miner if the block is orphaned.In an email conversation between Justus Ranvier and Mike Hearn, they discuss the difference between adding inputs to a coinbase and having pay-to-fee transactions in a block. Ranvier points out that pay-to-fee transactions can be "stolen" by another block, whereas inputs to a generation transaction cannot be poached. This difference allows for certain services that can't be safely achieved with pay-to-fee transactions, although it's unclear what these services are.There is ongoing debate and exploration around how to optimize blockchain transactions. The proposal to add inputs to the coinbase transaction aims to improve transaction processing efficiency or reduce fees. However, it is not clear how this differs from pay-to-fee transactions, which also involve direct payment to miners. The discussion on coinbase inputs and pay-to-fee transactions is likely part of a larger conversation on improving the functionality and scalability of blockchain systems.A proposal has been made to allow miners to voluntarily lock funds by adding additional inputs to the coinbase transaction. This would require a hard fork but could potentially be included in the next scheduled hard fork, such as when the block size is increased. The code modifications needed for this proposal are minimal and involve removing code rather than adding any. It is argued that this change would not change incentives or security until a soft fork is implemented in the future. 2015-01-03T03:48:29+00:00 + Sergio Lerner, a Bitcoin developer, has proposed a modification to the code that would allow miners to add real inputs to the coinbase transaction, instead of just pseudo-inputs. This change would enable miners to voluntarily lock funds. Lerner believes that this modification is necessary to secure the blockchain in the future when the subsidy is lowered. He argues that increasing the number of confirmation blocks could make Bitcoin less competitive with other payment networks. However, there are concerns about this proposal. Peter Todd, another Bitcoin developer, worries that it could change incentives and make it easier for individuals to pay miners to mine specific blocks rather than transactions. There are also doubts about the PowPay micropayments scheme, which may incentivize mining pools to grow larger.Gregory Maxwell and Stephen have suggested alternative ways to pay specific miners upon solving a block without risking paying other miners through pay-to-fee. Gregory suggests using Gavin's OP_EVAL, but acknowledges that it would require additional changes to overlay functionality. Stephen proposes a solution involving outputs in the coinbase transaction with nValue == 0, and applying the COINBASE_MATURITY rule only to spending coinbase outputs with non-zero value. However, this solution would still require a hard fork.In a conversation on the Bitcoin-development mailing list, Sergio expresses concern about the complexity of Bitcoin and argues that it needs to be simple for new programmers to understand and contribute to the project. He suggests that even P2SH is an abuse of the virtual machine (VM) and that Gavin's OP_EVAL should have been chosen instead. Others clarify that there is no abuse occurring and that Sergio's proposal would require an additional change to overlay functionality, which may be considered "ugly."Sergio Lerner's idea of allowing miners to lock funds by adding additional inputs to the coinbase transaction has been proposed since 2011 but hasn't been a priority until now. The motivation behind the proposal is to address potential security problems in the future as the subsidy is lowered. However, there are concerns about increasing the complexity of Bitcoin. Some suggest that a hard fork now could allow for a later implementation of a soft fork involving deposit bonds, proof-of-stake, and penalization of double-mining.Justus Ranvier explains in a discussion with Jorge Timón that allowing miners to pay themselves by adding inputs to the generation transaction is the most natural way for their customers to pay them. This method is more secure than pay-to-fee transactions because the fees cannot be claimed by another miner if the block is orphaned.In an email conversation between Justus Ranvier and Mike Hearn, they discuss the difference between adding inputs to a coinbase and having pay-to-fee transactions in a block. Ranvier points out that pay-to-fee transactions can be "stolen" by another block, whereas inputs to a generation transaction cannot be poached. This difference allows for certain services that can't be safely achieved with pay-to-fee transactions, although it's unclear what these services are.There is ongoing debate and exploration around how to optimize blockchain transactions. The proposal to add inputs to the coinbase transaction aims to improve transaction processing efficiency or reduce fees. However, it is not clear how this differs from pay-to-fee transactions, which also involve direct payment to miners. The discussion on coinbase inputs and pay-to-fee transactions is likely part of a larger conversation on improving the functionality and scalability of blockchain systems.A proposal has been made to allow miners to voluntarily lock funds by adding additional inputs to the coinbase transaction. This would require a hard fork but could potentially be included in the next scheduled hard fork, such as when the block size is increased. The code modifications needed for this proposal are minimal and involve removing code rather than adding any. It is argued that this change would not change incentives or security until a soft fork is implemented in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_BitCoin-TPB-P2P-Currency-Torrent.xml b/static/bitcoin-dev/Dec_2014/combined_BitCoin-TPB-P2P-Currency-Torrent.xml index ee70b170d9..6f717ebb42 100644 --- a/static/bitcoin-dev/Dec_2014/combined_BitCoin-TPB-P2P-Currency-Torrent.xml +++ b/static/bitcoin-dev/Dec_2014/combined_BitCoin-TPB-P2P-Currency-Torrent.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BitCoin TPB, P2P Currency/Torrent - 2023-08-01T10:56:53.008234+00:00 + 2025-10-11T21:53:31.090826+00:00 + python-feedgen Parazyd 2014-12-10 17:18:31+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BitCoin TPB, P2P Currency/Torrent - 2023-08-01T10:56:53.008234+00:00 + 2025-10-11T21:53:31.090980+00:00 - The author of the email has come up with an idea to use blockchain technology as a tracker, not necessarily related to Bitcoin. Their plan involves storing magnet links in the blockchain and using micro transactions to access content torrents. This innovative approach would enable users to tip content sharers and make anonymous requests for specific content. The author is seeking opinions and potential development partners for a front-end system.However, it is important to note that the discussion of illegal content, such as that found on the Pirate Bay, may not be appropriate for this mailing list. The author also criticizes the use of spam transactions to access content, highlighting the need for a fair and open content world.The author goes on to share their journey of understanding Bitcoin from both mathematical and programming perspectives. They have become fascinated by the idea of using Bitcoin's data package to store useful messages. Inspired by the temporary shutdown of the PirateBay, which is built on open source and the freedom to share, they propose creating a peer-to-peer transfer system using Bitcoin as currency and data provider.By inserting a similar message to that of a torrent into a Bitcoin portion, users would not only be able to tip the person sharing the content but also make anonymous requests for specific content. Micro-transfers would grant users access to the content's torrent information.In order to bring their idea to life, the author invites someone experienced in working with Bitcoin algorithms to collaborate on developing a front end. They express hope that others will share their vision for a fair and open content world.The email concludes with a link to download BIRT iHub F-Type, a free enterprise-grade BIRT server. 2014-12-10T17:18:31+00:00 + The author of the email has come up with an idea to use blockchain technology as a tracker, not necessarily related to Bitcoin. Their plan involves storing magnet links in the blockchain and using micro transactions to access content torrents. This innovative approach would enable users to tip content sharers and make anonymous requests for specific content. The author is seeking opinions and potential development partners for a front-end system.However, it is important to note that the discussion of illegal content, such as that found on the Pirate Bay, may not be appropriate for this mailing list. The author also criticizes the use of spam transactions to access content, highlighting the need for a fair and open content world.The author goes on to share their journey of understanding Bitcoin from both mathematical and programming perspectives. They have become fascinated by the idea of using Bitcoin's data package to store useful messages. Inspired by the temporary shutdown of the PirateBay, which is built on open source and the freedom to share, they propose creating a peer-to-peer transfer system using Bitcoin as currency and data provider.By inserting a similar message to that of a torrent into a Bitcoin portion, users would not only be able to tip the person sharing the content but also make anonymous requests for specific content. Micro-transfers would grant users access to the content's torrent information.In order to bring their idea to life, the author invites someone experienced in working with Bitcoin algorithms to collaborate on developing a front end. They express hope that others will share their vision for a fair and open content world.The email concludes with a link to download BIRT iHub F-Type, a free enterprise-grade BIRT server. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Cartographer.xml b/static/bitcoin-dev/Dec_2014/combined_Cartographer.xml index af753f1974..2ce75ed428 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Cartographer.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Cartographer.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Cartographer - 2023-08-01T11:03:40.317249+00:00 + 2025-10-11T21:53:50.222122+00:00 + python-feedgen Mistr Bigs 2014-12-29 13:08:52+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Cartographer - 2023-08-01T11:03:40.317249+00:00 + 2025-10-11T21:53:50.222266+00:00 - Based on the given context, it can be inferred that Peter's message tone was deemed inappropriate by an outside observer in regards to a specific discussion. The observer found his sardonic tone unsuitable for furthering the conversation. However, no information is provided regarding the nature or topic of the discussion.In another message, the sender accuses Mike Hearn of attempting to introduce privacy leaks and weaknesses in the Bitcoin ecosystem. The sender questions Hearn's use of logical fallacies and suggests that his behavior is calculated and planned. Several references to Reddit threads and a YouTube video discussing Hearn's actions are included.On December 29, 2014, a conversation took place between Thomas Zander and Mike Hearn regarding the limitations of the current DNS protocol. Hearn made an ad-hominem attack, which was deemed unacceptable behavior. Thomas focused on criticizing the idea rather than engaging in personal attacks. The conversation ended with Thomas signing off using PGP encryption.Another message from December 29, 2014, discusses the limitations and problems with using DNS for Bitcoin seeding. The author argues that a simple HTTP-based protocol fixes these problems and provides better privacy. The author concludes that Cartographer is a better protocol overall.On the same date, Mike Hearn wrote about the limitations of DNS as a protocol for learning about the p2p network. He expressed concerns over the lack of privacy and the potential for censorship. He suggested a connection-oriented seed protocol as an alternative.In another message from December 28, 2014, Hearn expressed concerns over the limitations of DNS as a protocol for learning about the p2p network. The specific issues were not mentioned, but Hearn believes that DNS is not adequate for this purpose.Recently, there have been limitations faced by DNS as a protocol for learning about the p2p network. In response, a new network crawler and seed has been developed that implements a standard DNS seed with a minimal embedded DNS server. This seed can serve data using various formats, such as gzipped, timestamped digitally signed protocol buffers over HTTP. The Cartographer, written in Kotlin, is easy to learn and has no chance of any buffer/heap exploits. A client for it is available in the bitcoinj master branch.In conclusion, the given context discusses various discussions and messages related to the limitations and problems with using DNS as a protocol for learning about the p2p network. Different individuals express their concerns and suggest alternative protocols, such as Cartographer, to address these limitations. 2014-12-29T13:08:52+00:00 + Based on the given context, it can be inferred that Peter's message tone was deemed inappropriate by an outside observer in regards to a specific discussion. The observer found his sardonic tone unsuitable for furthering the conversation. However, no information is provided regarding the nature or topic of the discussion.In another message, the sender accuses Mike Hearn of attempting to introduce privacy leaks and weaknesses in the Bitcoin ecosystem. The sender questions Hearn's use of logical fallacies and suggests that his behavior is calculated and planned. Several references to Reddit threads and a YouTube video discussing Hearn's actions are included.On December 29, 2014, a conversation took place between Thomas Zander and Mike Hearn regarding the limitations of the current DNS protocol. Hearn made an ad-hominem attack, which was deemed unacceptable behavior. Thomas focused on criticizing the idea rather than engaging in personal attacks. The conversation ended with Thomas signing off using PGP encryption.Another message from December 29, 2014, discusses the limitations and problems with using DNS for Bitcoin seeding. The author argues that a simple HTTP-based protocol fixes these problems and provides better privacy. The author concludes that Cartographer is a better protocol overall.On the same date, Mike Hearn wrote about the limitations of DNS as a protocol for learning about the p2p network. He expressed concerns over the lack of privacy and the potential for censorship. He suggested a connection-oriented seed protocol as an alternative.In another message from December 28, 2014, Hearn expressed concerns over the limitations of DNS as a protocol for learning about the p2p network. The specific issues were not mentioned, but Hearn believes that DNS is not adequate for this purpose.Recently, there have been limitations faced by DNS as a protocol for learning about the p2p network. In response, a new network crawler and seed has been developed that implements a standard DNS seed with a minimal embedded DNS server. This seed can serve data using various formats, such as gzipped, timestamped digitally signed protocol buffers over HTTP. The Cartographer, written in Kotlin, is easy to learn and has no chance of any buffer/heap exploits. A client for it is available in the bitcoinj master branch.In conclusion, the given context discusses various discussions and messages related to the limitations and problems with using DNS as a protocol for learning about the p2p network. Different individuals express their concerns and suggest alternative protocols, such as Cartographer, to address these limitations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml b/static/bitcoin-dev/Dec_2014/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml index 80517cb5ce..feb999eb82 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Deanonymisation of clients in Bitcoin P2P network paper - 2023-08-01T10:41:10.355017+00:00 + 2025-10-11T21:53:28.965948+00:00 + python-feedgen Mike Hearn 2015-01-22 13:20:29+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Deanonymisation of clients in Bitcoin P2P network paper - 2023-08-01T10:41:10.356013+00:00 + 2025-10-11T21:53:28.966113+00:00 - The conversation revolves around the idea of mainstream wallets and wallets designed for cryptocurrency research sharing a common core. The speaker gives examples such as bitcoinj and discusses the use of Tor to improve Bitcoin wallet security. The potential risks and limitations of using Tor are also addressed, including connection drops and deanonymization issues.There is a suggestion to explore ways to improve synergy between Tor and Bitcoin, while maintaining their standalone functionality. The importance of prioritizing user privacy and the need for better DoS handling are emphasized. The discussion also touches on the effectiveness of connecting to Bitcoin using Tor and the concerns over users being forced off Tor via DOS attacks.The paper from the University of Luxembourg is referenced, which discusses the risks of obtaining IP addresses of clients involved in transactions on the Bitcoin network. The need for improvements in DoS handling and the separation of transaction submission and P2P networking are also mentioned. The potential vulnerabilities and trade-offs associated with tying Bitcoin to Tor too deeply are discussed.In response to a query about a paper posted on Reddit, Jeff Garzik, a Bitcoin core developer and open source evangelist, discussed an attack that can de-anonymize clients on the bitcoin network. While Garzik did not recall being contacted directly, he explained that the attack has been previously discussed and relies on certain conditions.If a user is using Tor, the attacker will attempt to kick the machine off Tor, assuming it will switch to non-Tor. However, this only applies to dual stack nodes, which are not completely anonymous as users operate from their public IP address anyway. The email thread includes a link to the paper from the University of Luxembourg, which delves into the details of the attack.A recent post on Reddit has shed light on a paper by the University of Luxembourg, which explores how attackers can compromise the anonymity of clients on the Bitcoin network. The paper examines various methods that can be employed to undermine user privacy. It is unclear whether these issues have been addressed, but it is mentioned that the core developers were informed about them before the publication of the paper. To access the full paper, interested individuals can follow the link provided in the Reddit post. 2015-01-22T13:20:29+00:00 + The conversation revolves around the idea of mainstream wallets and wallets designed for cryptocurrency research sharing a common core. The speaker gives examples such as bitcoinj and discusses the use of Tor to improve Bitcoin wallet security. The potential risks and limitations of using Tor are also addressed, including connection drops and deanonymization issues.There is a suggestion to explore ways to improve synergy between Tor and Bitcoin, while maintaining their standalone functionality. The importance of prioritizing user privacy and the need for better DoS handling are emphasized. The discussion also touches on the effectiveness of connecting to Bitcoin using Tor and the concerns over users being forced off Tor via DOS attacks.The paper from the University of Luxembourg is referenced, which discusses the risks of obtaining IP addresses of clients involved in transactions on the Bitcoin network. The need for improvements in DoS handling and the separation of transaction submission and P2P networking are also mentioned. The potential vulnerabilities and trade-offs associated with tying Bitcoin to Tor too deeply are discussed.In response to a query about a paper posted on Reddit, Jeff Garzik, a Bitcoin core developer and open source evangelist, discussed an attack that can de-anonymize clients on the bitcoin network. While Garzik did not recall being contacted directly, he explained that the attack has been previously discussed and relies on certain conditions.If a user is using Tor, the attacker will attempt to kick the machine off Tor, assuming it will switch to non-Tor. However, this only applies to dual stack nodes, which are not completely anonymous as users operate from their public IP address anyway. The email thread includes a link to the paper from the University of Luxembourg, which delves into the details of the attack.A recent post on Reddit has shed light on a paper by the University of Luxembourg, which explores how attackers can compromise the anonymity of clients on the Bitcoin network. The paper examines various methods that can be employed to undermine user privacy. It is unclear whether these issues have been addressed, but it is mentioned that the core developers were informed about them before the publication of the paper. To access the full paper, interested individuals can follow the link provided in the Reddit post. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Merged-mining-a-side-chain-with-proof-of-burn-on-parent-chain.xml b/static/bitcoin-dev/Dec_2014/combined_Merged-mining-a-side-chain-with-proof-of-burn-on-parent-chain.xml index 7f672980ab..37452f5a1d 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Merged-mining-a-side-chain-with-proof-of-burn-on-parent-chain.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Merged-mining-a-side-chain-with-proof-of-burn-on-parent-chain.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Merged mining a side chain with proof of burn on parent chain - 2023-08-01T10:56:22.654550+00:00 + 2025-10-11T21:53:56.589244+00:00 + python-feedgen Peter Todd 2015-02-06 01:34:31+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Merged mining a side chain with proof of burn on parent chain - 2023-08-01T10:56:22.655554+00:00 + 2025-10-11T21:53:56.589453+00:00 - On February 4, 2015, Isidor Zeuner asked a question about adding Zerocoin to Bitcoin. Peter Todd clarified the meaning of OP_DEPTH and suggested using OP_CHECKLOCKTIMEVERIFY instead. Tamas Blummer proposed a new mining algorithm for side chains that involves burning Bitcoins to secure them. The difficulty to mine with burn would be dynamic and imply a floating exchange rate between Bitcoin and the side coin. Alex Mizrahi discussed the vulnerability of sidechains and merged-mined chains to collusion attacks, while Peter Todd mentioned the potential for replace-by-fee-scorched-earth thinking. Tamas Blummer and Isidor Zeuner discussed the concept of Proof of Burn and its value in an email conversation. They discussed the effectiveness of Proof of Burn compared to other approaches and the complexities involved in determining the most effective approach for Bitcoin mining. Tamas Blummer also proposed the idea of burn mining side chains to enable permission-less merge mining. He expressed surprise at the lack of feedback on the idea. On 12/10/2014, Tamas Blummer outlined the Proof of Burn algorithm for side chains, which creates a real cost for following the rules and avoids sybil attacks. The algorithm requires that block transactions on the Bitcoin block chain destroy Bitcoins with an OP_RET output containing the hash of the side chain's block header. Those who want to mine the side chain assemble side chain block candidates and submit a Bitcoin transaction burning to the hash of the block candidate. The difficulty to mine with burn would be dynamic and imply a floating exchange rate between Bitcoin and the side coin. Tamas Blummer's proposed mining algorithm for side chains aims to utilize the scarce resource within the digital realm by burning Bitcoins to secure them. By utilizing burn transactions, Bitcoin miner support or consent would not be needed, creating a "merged mining" system. 2015-02-06T01:34:31+00:00 + On February 4, 2015, Isidor Zeuner asked a question about adding Zerocoin to Bitcoin. Peter Todd clarified the meaning of OP_DEPTH and suggested using OP_CHECKLOCKTIMEVERIFY instead. Tamas Blummer proposed a new mining algorithm for side chains that involves burning Bitcoins to secure them. The difficulty to mine with burn would be dynamic and imply a floating exchange rate between Bitcoin and the side coin. Alex Mizrahi discussed the vulnerability of sidechains and merged-mined chains to collusion attacks, while Peter Todd mentioned the potential for replace-by-fee-scorched-earth thinking. Tamas Blummer and Isidor Zeuner discussed the concept of Proof of Burn and its value in an email conversation. They discussed the effectiveness of Proof of Burn compared to other approaches and the complexities involved in determining the most effective approach for Bitcoin mining. Tamas Blummer also proposed the idea of burn mining side chains to enable permission-less merge mining. He expressed surprise at the lack of feedback on the idea. On 12/10/2014, Tamas Blummer outlined the Proof of Burn algorithm for side chains, which creates a real cost for following the rules and avoids sybil attacks. The algorithm requires that block transactions on the Bitcoin block chain destroy Bitcoins with an OP_RET output containing the hash of the side chain's block header. Those who want to mine the side chain assemble side chain block candidates and submit a Bitcoin transaction burning to the hash of the block candidate. The difficulty to mine with burn would be dynamic and imply a floating exchange rate between Bitcoin and the side coin. Tamas Blummer's proposed mining algorithm for side chains aims to utilize the scarce resource within the digital realm by burning Bitcoins to secure them. By utilizing burn transactions, Bitcoin miner support or consent would not be needed, creating a "merged mining" system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Open-development-processes-and-reddit-charms.xml b/static/bitcoin-dev/Dec_2014/combined_Open-development-processes-and-reddit-charms.xml index ce59a54909..ac0ee6a85b 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Open-development-processes-and-reddit-charms.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Open-development-processes-and-reddit-charms.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Open development processes and reddit charms - 2023-08-01T10:59:14.298738+00:00 + 2025-10-11T21:53:33.213875+00:00 + python-feedgen 21E14 2014-12-18 05:56:18+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Open development processes and reddit charms - 2023-08-01T10:59:14.298738+00:00 + 2025-10-11T21:53:33.214031+00:00 - The article delves into the challenges and complexities of open source development using Bitcoin Core as a case study. It highlights various aspects such as the difficulty in understanding the Bitcoin Core threading model, platform support, libification, dependency management, core data structures, DoS mitigation, and script evolution. The author suggests that addressing these challenges may be a bottleneck in the development process.The importance of openness and transparency in open source development is also discussed. The article emphasizes the need to focus on the engineers actually working on the technology rather than getting caught up in disagreements that may arise in public forums. The author encourages readers to assume good faith and pay attention to the actual work being done.Concerns about changes made during the 0.10 development cycle of Bitcoin Core are addressed. The author argues that these changes were performed responsibly, with multiple developers verifying each cosmetic change. The general direction of the work was aimed at creating a "libconsensus" library that can be used by external projects.The concept of "social debt" is introduced, referring to the added costs incurred by developers who must update their unmerged work due to constant code movement and refactoring changes. While such changes are necessary for a cleaner codebase, they can discourage developers from working on the project. The article suggests developing policies that balance the need for refactoring with the needs of developers working on more involved Bitcoin Core projects.In a recent pull request on GitHub, Wladimir highlighted the importance of consistency in code formatting. Enforcing a specific tabbing style or column width across the entire codebase is crucial for readability and maintainability. The provided link leads to the specific pull request where this issue was discussed.The lack of code janitors is identified as the biggest systemic risk for Bitcoin. Due to the complexity of the code, there needs to be a focus on readability, maintainability, and coding standards. The article suggests developing a policy that opens and closes windows for code movement and major disruptive changes, similar to a "feature freeze" in other software projects.The open source development process is also highlighted as a case study that can be reviewed periodically. Openness and transparency are considered the default practice, which means it is normal to discuss disagreements in public forums. However, competing interests can lead to conspiracy theories. In terms of technical debt, cosmetic patches such as code movement can disrupt developers working on non-trivial features, discouraging them from contributing to the project.Finding the right balance is crucial for Bitcoin Core. While refactoring is necessary, it is also anti-social in the short term. The article suggests striking a balance by developing a policy that allows for code movement and major disruptive changes within specific timeframes. This will help encourage developers to work on more involved Bitcoin Core projects.In conclusion, the article highlights the challenges faced in open source development using Bitcoin Core as an example. It emphasizes the importance of openness, transparency, and consistency in coding standards. The concept of social debt is introduced, and suggestions are made for finding a balance between refactoring and encouraging developer contributions. 2014-12-18T05:56:18+00:00 + The article delves into the challenges and complexities of open source development using Bitcoin Core as a case study. It highlights various aspects such as the difficulty in understanding the Bitcoin Core threading model, platform support, libification, dependency management, core data structures, DoS mitigation, and script evolution. The author suggests that addressing these challenges may be a bottleneck in the development process.The importance of openness and transparency in open source development is also discussed. The article emphasizes the need to focus on the engineers actually working on the technology rather than getting caught up in disagreements that may arise in public forums. The author encourages readers to assume good faith and pay attention to the actual work being done.Concerns about changes made during the 0.10 development cycle of Bitcoin Core are addressed. The author argues that these changes were performed responsibly, with multiple developers verifying each cosmetic change. The general direction of the work was aimed at creating a "libconsensus" library that can be used by external projects.The concept of "social debt" is introduced, referring to the added costs incurred by developers who must update their unmerged work due to constant code movement and refactoring changes. While such changes are necessary for a cleaner codebase, they can discourage developers from working on the project. The article suggests developing policies that balance the need for refactoring with the needs of developers working on more involved Bitcoin Core projects.In a recent pull request on GitHub, Wladimir highlighted the importance of consistency in code formatting. Enforcing a specific tabbing style or column width across the entire codebase is crucial for readability and maintainability. The provided link leads to the specific pull request where this issue was discussed.The lack of code janitors is identified as the biggest systemic risk for Bitcoin. Due to the complexity of the code, there needs to be a focus on readability, maintainability, and coding standards. The article suggests developing a policy that opens and closes windows for code movement and major disruptive changes, similar to a "feature freeze" in other software projects.The open source development process is also highlighted as a case study that can be reviewed periodically. Openness and transparency are considered the default practice, which means it is normal to discuss disagreements in public forums. However, competing interests can lead to conspiracy theories. In terms of technical debt, cosmetic patches such as code movement can disrupt developers working on non-trivial features, discouraging them from contributing to the project.Finding the right balance is crucial for Bitcoin Core. While refactoring is necessary, it is also anti-social in the short term. The article suggests striking a balance by developing a policy that allows for code movement and major disruptive changes within specific timeframes. This will help encourage developers to work on more involved Bitcoin Core projects.In conclusion, the article highlights the challenges faced in open source development using Bitcoin Core as an example. It emphasizes the importance of openness, transparency, and consistency in coding standards. The concept of social debt is introduced, and suggestions are made for finding a balance between refactoring and encouraging developer contributions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Reading-List-for-Getting-Up-to-Speed.xml b/static/bitcoin-dev/Dec_2014/combined_Reading-List-for-Getting-Up-to-Speed.xml index 217fb7ec4d..e61b87ef7b 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Reading-List-for-Getting-Up-to-Speed.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Reading-List-for-Getting-Up-to-Speed.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reading List for Getting Up to Speed - 2023-08-01T11:03:18.916578+00:00 + 2025-10-11T21:53:48.100669+00:00 + python-feedgen Will Bickford 2014-12-24 19:58:02+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Reading List for Getting Up to Speed - 2023-08-01T11:03:18.916578+00:00 + 2025-10-11T21:53:48.100844+00:00 - In an email exchange between Gregory Maxwell and Will Bickford, Bickford expressed concern about having to go through 280,000 lines of code. However, Maxwell clarified that only about 36kloc of that code was relevant, with the remaining 170kloc consisting of machine-generated code with translation strings. Maxwell recommended skimming through the smaller portion of the code, emphasizing that it was much more manageable than initially thought. The email thread was titled "In Google We Trust".Bickford, who is new to Bitcoin development, plans to share regular status updates on his blog at http://hewo.xedoloh.com/bitcoin-dev/ for others who are also starting out in Bitcoin development. Based on a sampling of code from https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp, Bickford estimated that reading the entire code base would require approximately 110 hours of his time. He asked if there was a map of the most important areas to study for new developers and automated test writers, as he believed that investing that much time into reading the code would enable him to conduct extensive testing. Bickford expressed his commitment to learning as much as he can about Bitcoin development and sharing his progress with others. 2014-12-24T19:58:02+00:00 + In an email exchange between Gregory Maxwell and Will Bickford, Bickford expressed concern about having to go through 280,000 lines of code. However, Maxwell clarified that only about 36kloc of that code was relevant, with the remaining 170kloc consisting of machine-generated code with translation strings. Maxwell recommended skimming through the smaller portion of the code, emphasizing that it was much more manageable than initially thought. The email thread was titled "In Google We Trust".Bickford, who is new to Bitcoin development, plans to share regular status updates on his blog at http://hewo.xedoloh.com/bitcoin-dev/ for others who are also starting out in Bitcoin development. Based on a sampling of code from https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp, Bickford estimated that reading the entire code base would require approximately 110 hours of his time. He asked if there was a map of the most important areas to study for new developers and automated test writers, as he believed that investing that much time into reading the code would enable him to conduct extensive testing. Bickford expressed his commitment to learning as much as he can about Bitcoin development and sharing his progress with others. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Recent-EvalScript-changes-mean-CHECKLOCKTIMEVERIFY-can-t-be-merged.xml b/static/bitcoin-dev/Dec_2014/combined_Recent-EvalScript-changes-mean-CHECKLOCKTIMEVERIFY-can-t-be-merged.xml index a92dc727b8..6f6aeeb07d 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Recent-EvalScript-changes-mean-CHECKLOCKTIMEVERIFY-can-t-be-merged.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Recent-EvalScript-changes-mean-CHECKLOCKTIMEVERIFY-can-t-be-merged.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged - 2023-08-01T10:58:48.450428+00:00 + 2025-10-11T21:53:35.338220+00:00 + python-feedgen Btc Drak 2014-12-15 21:57:27+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged - 2023-08-01T10:58:48.450428+00:00 + 2025-10-11T21:53:35.338392+00:00 - In a series of email conversations among Bitcoin core developers, concerns were raised about the process of code movement and refactoring in the modularization of Bitcoin's codebase. The current method of continuous movement and refactoring was criticized for complicating the review process and making it difficult to track changes. Jeff Garzik suggested that if the majority of code movement was done upfront, followed by simplifications and data structure work, further patches would be easier to review and apply with less impact on unrelated code. However, Cory Fields argued that minor code changes are often needed at the micro level to accommodate useful code movement, making it challenging to handle these changes separately. Another concern was raised by Peter Todd regarding the development process of the consensus critical codebase. He pointed out that the volume of changes made for the v0.10 release posed risks, especially with regard to significant consensus critical code changes. Todd highlighted pull-req #4890 as an example, which had no ACKs and only two untested utACKS. He recommended not upgrading to v0.10 due to these issues and suggested limiting the changes required for the consensus library to simple movements of code.The importance of isolating the consensus code into a separate library was emphasized, as it would make it easier to enforce change control and track consensus changes. This goal was seen as crucial for the Bitcoin Core project. Additionally, concerns were raised about the safety of changes made to the consensus critical codebase. Commit c7829ea7 was discussed, which disentangled script validation from the node state introduced by signature caching changes. Todd argued that the change was narrow and reasonable, with multiple participants and good test coverage.Garzik stressed the significance of modular code and logical organization of smaller files, particularly for consensus critical code. He compared the process to the Linux kernel, where breaking up code into smaller files was the first step towards organization and easier review. He suggested that refactoring should come in a second wave after a stable release, and the initial step should be relocating blocks of code. The Bitcoin Core project faced criticism for the frequency and speed of refactorings taking place. Concerns were raised about small edge case bugs creeping in and causing unforeseen problems. It was suggested that relocating blocks of code into smaller files should be the first step towards more modular code, with refactoring coming later. API changes were emphasized as requiring careful consideration due to their impact on compatibility.In a separate development, it was found that a significant design change made merging the CHECKLOCKTIMEVERIFY patch to master impossible. This change indicated risks taken in the refactoring of the consensus critical codebase. The lack of ACKs and untested utACKS for pull-req #4890 further raised concerns about the safety of these changes. Todd recommended not upgrading to v0.10 due to these issues and proposed limiting code changes for the consensus library to simple movements of code.Overall, the email conversations highlighted the challenges and concerns surrounding code movement and refactoring in Bitcoin's modularization process. The importance of organized and reviewer-friendly code, the need for careful consideration of changes, and the prioritization of safety were key themes discussed among the developers. 2014-12-15T21:57:27+00:00 + In a series of email conversations among Bitcoin core developers, concerns were raised about the process of code movement and refactoring in the modularization of Bitcoin's codebase. The current method of continuous movement and refactoring was criticized for complicating the review process and making it difficult to track changes. Jeff Garzik suggested that if the majority of code movement was done upfront, followed by simplifications and data structure work, further patches would be easier to review and apply with less impact on unrelated code. However, Cory Fields argued that minor code changes are often needed at the micro level to accommodate useful code movement, making it challenging to handle these changes separately. Another concern was raised by Peter Todd regarding the development process of the consensus critical codebase. He pointed out that the volume of changes made for the v0.10 release posed risks, especially with regard to significant consensus critical code changes. Todd highlighted pull-req #4890 as an example, which had no ACKs and only two untested utACKS. He recommended not upgrading to v0.10 due to these issues and suggested limiting the changes required for the consensus library to simple movements of code.The importance of isolating the consensus code into a separate library was emphasized, as it would make it easier to enforce change control and track consensus changes. This goal was seen as crucial for the Bitcoin Core project. Additionally, concerns were raised about the safety of changes made to the consensus critical codebase. Commit c7829ea7 was discussed, which disentangled script validation from the node state introduced by signature caching changes. Todd argued that the change was narrow and reasonable, with multiple participants and good test coverage.Garzik stressed the significance of modular code and logical organization of smaller files, particularly for consensus critical code. He compared the process to the Linux kernel, where breaking up code into smaller files was the first step towards organization and easier review. He suggested that refactoring should come in a second wave after a stable release, and the initial step should be relocating blocks of code. The Bitcoin Core project faced criticism for the frequency and speed of refactorings taking place. Concerns were raised about small edge case bugs creeping in and causing unforeseen problems. It was suggested that relocating blocks of code into smaller files should be the first step towards more modular code, with refactoring coming later. API changes were emphasized as requiring careful consideration due to their impact on compatibility.In a separate development, it was found that a significant design change made merging the CHECKLOCKTIMEVERIFY patch to master impossible. This change indicated risks taken in the refactoring of the consensus critical codebase. The lack of ACKs and untested utACKS for pull-req #4890 further raised concerns about the safety of these changes. Todd recommended not upgrading to v0.10 due to these issues and proposed limiting code changes for the consensus library to simple movements of code.Overall, the email conversations highlighted the challenges and concerns surrounding code movement and refactoring in Bitcoin's modularization process. The importance of organized and reviewer-friendly code, the need for careful consideration of changes, and the prioritization of safety were key themes discussed among the developers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Serialised-P2SH-HD-chains.xml b/static/bitcoin-dev/Dec_2014/combined_Serialised-P2SH-HD-chains.xml index 1e526f6803..b8b986c302 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Serialised-P2SH-HD-chains.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Serialised-P2SH-HD-chains.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Serialised P2SH HD chains - 2023-08-01T10:55:26.137353+00:00 + 2025-10-11T21:53:37.463668+00:00 + python-feedgen Luke Dashjr 2014-12-04 21:10:14+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Serialised P2SH HD chains - 2023-08-01T10:55:26.137353+00:00 + 2025-10-11T21:53:37.463815+00:00 - Jeffrey Paul inquired about the use case for generating multiple Pay-to-Script-Hash (P2SH) addresses with a single token, specifically in the context of enabling payments to individuals without them needing to have their computer on during transactions. He also questioned the assumption that multisig participants would never change their keys or cycle them. The response mentioned that the solution depends on the framework and that miners are currently limited to using only one address, even if they wanted to avoid address reuse.On December 4, 2014, Luke Dashjr raised a query about whether there was work being done on a serialization format to convey P2SH HD chains. He suggested using a simple series of tokens to generate multiple P2SH addresses paying to a multisig script. Luke-Jr explained that this serialization format could be useful when the payee is not online and could help avoid explicitly specifying scriptPubKey formats. This idea was similar to his considerations for generalized stealth addresses, which also aimed to avoid explicitly specifying scriptPubKey formats.Luke Dashjr, a Bitcoin developer, further discussed the need for a serialization format to convey P2SH HD chains for recurring payments. He proposed using a series of tokens indicating either an HD chain or literal script content to generate multiple P2SH addresses paying to a multisig script. The author also suggested the use of a bitcoin URI pointing to a payment request generating URL as a more practical option for long-term payments. It was recommended to set an expiry time for practical usage.The author mentioned the creation of a Javascript program to print minimal protobufs to base64 for multisig and regular pay to address outputs. Additionally, the author suggested building specialized one-off SPV wallets using bitcoinj and provided a video tutorial on customization. The author also discussed the possibility of creating a GUI that allows users to build a base64 encoded payment protocol request supporting HD iteration for one or more keys. This GUI could serve as a starter project and act as a watching wallet to track mining payouts over time.There was interest expressed in creating a shared HD wallet format that would allow different devices to generate new addresses using standardized HD multisig chain-description formats. However, there were still many details to be worked through before having a concrete proposal. Another individual proposed a solution involving a simple series of tokens indicating either an HD chain or literal script content to convey P2SH HD chains.A group in San Diego was working on a standardized HD multisig chain-description format that multiple wallets could understand. This format aimed to create a 2-of-3 multisig wallet using different devices running different wallet software. The chain-description file would be shared with third parties for auditing, receive-only wallets, and recurring payments. However, more details needed to be addressed before presenting a concrete proposal.Luke Dashjr's inquiry about a serialization format to convey P2SH HD chains prompted Gavin Andresen to respond, stating the need for an expiration date or means of determining if the payment recipient is still operational. Gavin referred to a previous discussion on extending the payment protocol for recurring transactions and suggested providing a URL for accessing PaymentRequests when making a payment or offering an array of PaymentRequests for future payments.In conclusion, the author seeks information on a serialization format for conveying P2SH HD chains for recurring payments. The proposal involves generating a single token to generate multiple P2SH addresses paying to a multisig script using a series of tokens indicating HD chains or literal script content. However, questions remain regarding whether this proposed solution adequately covers all reasonable use cases. 2014-12-04T21:10:14+00:00 + Jeffrey Paul inquired about the use case for generating multiple Pay-to-Script-Hash (P2SH) addresses with a single token, specifically in the context of enabling payments to individuals without them needing to have their computer on during transactions. He also questioned the assumption that multisig participants would never change their keys or cycle them. The response mentioned that the solution depends on the framework and that miners are currently limited to using only one address, even if they wanted to avoid address reuse.On December 4, 2014, Luke Dashjr raised a query about whether there was work being done on a serialization format to convey P2SH HD chains. He suggested using a simple series of tokens to generate multiple P2SH addresses paying to a multisig script. Luke-Jr explained that this serialization format could be useful when the payee is not online and could help avoid explicitly specifying scriptPubKey formats. This idea was similar to his considerations for generalized stealth addresses, which also aimed to avoid explicitly specifying scriptPubKey formats.Luke Dashjr, a Bitcoin developer, further discussed the need for a serialization format to convey P2SH HD chains for recurring payments. He proposed using a series of tokens indicating either an HD chain or literal script content to generate multiple P2SH addresses paying to a multisig script. The author also suggested the use of a bitcoin URI pointing to a payment request generating URL as a more practical option for long-term payments. It was recommended to set an expiry time for practical usage.The author mentioned the creation of a Javascript program to print minimal protobufs to base64 for multisig and regular pay to address outputs. Additionally, the author suggested building specialized one-off SPV wallets using bitcoinj and provided a video tutorial on customization. The author also discussed the possibility of creating a GUI that allows users to build a base64 encoded payment protocol request supporting HD iteration for one or more keys. This GUI could serve as a starter project and act as a watching wallet to track mining payouts over time.There was interest expressed in creating a shared HD wallet format that would allow different devices to generate new addresses using standardized HD multisig chain-description formats. However, there were still many details to be worked through before having a concrete proposal. Another individual proposed a solution involving a simple series of tokens indicating either an HD chain or literal script content to convey P2SH HD chains.A group in San Diego was working on a standardized HD multisig chain-description format that multiple wallets could understand. This format aimed to create a 2-of-3 multisig wallet using different devices running different wallet software. The chain-description file would be shared with third parties for auditing, receive-only wallets, and recurring payments. However, more details needed to be addressed before presenting a concrete proposal.Luke Dashjr's inquiry about a serialization format to convey P2SH HD chains prompted Gavin Andresen to respond, stating the need for an expiration date or means of determining if the payment recipient is still operational. Gavin referred to a previous discussion on extending the payment protocol for recurring transactions and suggested providing a URL for accessing PaymentRequests when making a payment or offering an array of PaymentRequests for future payments.In conclusion, the author seeks information on a serialization format for conveying P2SH HD chains for recurring payments. The proposal involves generating a single token to generate multiple P2SH addresses paying to a multisig script using a series of tokens indicating HD chains or literal script content. However, questions remain regarding whether this proposed solution adequately covers all reasonable use cases. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_Setting-the-record-straight-on-Proof-of-Publication.xml b/static/bitcoin-dev/Dec_2014/combined_Setting-the-record-straight-on-Proof-of-Publication.xml index a90e2e6335..fe904e342e 100644 --- a/static/bitcoin-dev/Dec_2014/combined_Setting-the-record-straight-on-Proof-of-Publication.xml +++ b/static/bitcoin-dev/Dec_2014/combined_Setting-the-record-straight-on-Proof-of-Publication.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Setting the record straight on Proof-of-Publication - 2023-08-01T10:58:22.419876+00:00 + 2025-10-11T21:53:43.839971+00:00 + python-feedgen Peter Todd 2014-12-21 06:12:20+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Setting the record straight on Proof-of-Publication - 2023-08-01T10:58:22.419876+00:00 + 2025-10-11T21:53:43.840151+00:00 - Proof-of-publication systems are gaining attention in the blockchain industry as a solution to the double-spend problem. These systems utilize various proofs, such as proof-of-receipt, proof-of-non-publication, and proof-of-membership, to ensure the integrity of transactions. One example of proof-of-publication is the Torrens Title System, which operates similarly to the Bitcoin blockchain.However, there are some misconceptions surrounding proof-of-publication that need clarification. First, it should not be mistaken for timestamping, as it involves more than just adding a timestamp to a document. Additionally, it is not easily censorable and can be made expensive if necessary. Despite these misconceptions, proof-of-publication offers a practical solution and has applications beyond just timestamping.One advantage of proof-of-publication is that it does not bloat the blockchain like other systems, avoiding significant increases in transaction fees. However, some systems do contribute to the growth of the Unspent Transaction Output (UTXO) set, which may impact fees. The use of proof-of-publication systems in Bitcoin can also have varying effects on the cryptocurrency's price, depending on the specific use-case and features introduced.While proof-of-publication systems may seem inefficient from the perspective of simplified payment verification (SPV) clients, they provide accountability for trusted third parties. They address the issue of global consensus inefficiency in Bitcoin's architecture. Some proof-of-publication systems require limited-supply tokens, but whether these tokens are considered "scamcoins" is a subjective question. They serve technical purposes in enabling secure client-side validation and do not necessarily need to appreciate in value compared to Bitcoin. Furthermore, not all use-cases of proof-of-publication involve tokens or finance.In a 2014 email exchange, Peter Todd argued that using a limited-supply token in a proof-of-publication system enables secure client-side validation. This contrasts with the alternative of 2-way-pegging, which relies on trust in miners not to steal pegged funds. However, another participant challenged the notion of "secure" and "client-side validation" going hand-in-hand. They emphasized the importance of considering a transaction valid in the wider world and highlighted the value of validated data in the blockchain for distributed consensus.In conclusion, proof-of-publication systems offer practical solutions to the double-spend problem and have various applications. Misconceptions surrounding these systems need clarification, and scalability improvements are necessary to mitigate any negative impacts on Bitcoin's price. While they may be inefficient for SPV clients, they provide accountability for trusted third parties. The use of limited-supply tokens in these systems can enable secure client-side validation, but opinions on their classification as "scamcoins" differ. It is important to note that not all proof-of-publication use-cases involve tokens or finance. 2014-12-21T06:12:20+00:00 + Proof-of-publication systems are gaining attention in the blockchain industry as a solution to the double-spend problem. These systems utilize various proofs, such as proof-of-receipt, proof-of-non-publication, and proof-of-membership, to ensure the integrity of transactions. One example of proof-of-publication is the Torrens Title System, which operates similarly to the Bitcoin blockchain.However, there are some misconceptions surrounding proof-of-publication that need clarification. First, it should not be mistaken for timestamping, as it involves more than just adding a timestamp to a document. Additionally, it is not easily censorable and can be made expensive if necessary. Despite these misconceptions, proof-of-publication offers a practical solution and has applications beyond just timestamping.One advantage of proof-of-publication is that it does not bloat the blockchain like other systems, avoiding significant increases in transaction fees. However, some systems do contribute to the growth of the Unspent Transaction Output (UTXO) set, which may impact fees. The use of proof-of-publication systems in Bitcoin can also have varying effects on the cryptocurrency's price, depending on the specific use-case and features introduced.While proof-of-publication systems may seem inefficient from the perspective of simplified payment verification (SPV) clients, they provide accountability for trusted third parties. They address the issue of global consensus inefficiency in Bitcoin's architecture. Some proof-of-publication systems require limited-supply tokens, but whether these tokens are considered "scamcoins" is a subjective question. They serve technical purposes in enabling secure client-side validation and do not necessarily need to appreciate in value compared to Bitcoin. Furthermore, not all use-cases of proof-of-publication involve tokens or finance.In a 2014 email exchange, Peter Todd argued that using a limited-supply token in a proof-of-publication system enables secure client-side validation. This contrasts with the alternative of 2-way-pegging, which relies on trust in miners not to steal pegged funds. However, another participant challenged the notion of "secure" and "client-side validation" going hand-in-hand. They emphasized the importance of considering a transaction valid in the wider world and highlighted the value of validated data in the blockchain for distributed consensus.In conclusion, proof-of-publication systems offer practical solutions to the double-spend problem and have various applications. Misconceptions surrounding these systems need clarification, and scalability improvements are necessary to mitigate any negative impacts on Bitcoin's price. While they may be inefficient for SPV clients, they provide accountability for trusted third parties. The use of limited-supply tokens in these systems can enable secure client-side validation, but opinions on their classification as "scamcoins" differ. It is important to note that not all proof-of-publication use-cases involve tokens or finance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles.xml b/static/bitcoin-dev/Dec_2014/combined_The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles.xml index 32f14b123a..33efa5453d 100644 --- a/static/bitcoin-dev/Dec_2014/combined_The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles.xml +++ b/static/bitcoin-dev/Dec_2014/combined_The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The relationship between Proof-of-Publication and Anti-Replay Oracles - 2023-08-01T11:01:08.003228+00:00 + 2025-10-11T21:53:41.713582+00:00 + python-feedgen joliver at airmail.cc 2015-01-06 11:03:47+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - The relationship between Proof-of-Publication and Anti-Replay Oracles - 2023-08-01T11:01:08.004228+00:00 + 2025-10-11T21:53:41.713762+00:00 - Peter Todd proposed a "proof-of-publication" system using OP_RETURN to embed opaque data in transactions, but faced criticism from Adam Back regarding its effectiveness. While establishing "proof-of-publication" as a universal primitive is significant, it alone does not provide sufficient indexing, validation, or exclusion capabilities. The effectiveness of this system and the number of supporters other than Peter Todd remain uncertain.In a discussion on blockchain design, the author explored layer properties such as time-stamping and namespace for constructing a decentralized PoW-chain based ecash system. Time-stamping creates an immutable stream of data with a time-ordering, while namespace adds uniqueness and first-come first-served property. The author concluded that finding improvements in the consensus critical code was challenging. Namespace attributes hold information like public keys, IP addresses, and email addresses. Proof of publication is crucial for miners to have copies of all committed data before building on top of blocks. There is a meta-incentive for bitcoin holders to help others catch up with the history, and information needs to be broadcasted due to numerous miners and full-nodes. The anti-relay term refers to the system level, and attacking the insertion logic is prevented to maintain the integrity of the merkle tree.Peter Todd shared a note about using a "proof-of-publication" system for implementing an "anti-replay" system. However, Todd argued that proof-of-(non)-publication is different from anti-replay and suggested extending the definition of proof-of-(non)-publication. He emphasized the importance of indexes and validation in cryptocurrency designs. While proof-of-(non)-publication is significant, Bitcoin also provides indexing and validation/exclusion functionalities.Various perspectives on the advantages and disadvantages of proof-of-publication markets are discussed in an email exchange. The concept of proof-of-publication allows for tradeoffs and options in connecting sellers and buyers, providing accurate price information. The term "fair" is subjective, making it challenging to define precisely. Some argue that p2p markets can exist without proof of publication, and there are other secure models beyond this concept. Third-parties may republish bids and offers to achieve better price discovery.Jorge Timón explains the advantages of proof-of-publication systems in trade scenarios. He gives an example where a seller wants to sell a unit of A for 100 units of B, and a buyer is willing to pay up to 200 Bs for 1 A. In a proof-of-publication system, the execution price is determined based on bids and asks. However, in the real world, buyers and sellers want to ensure they are connected to actual counterparts and are willing to pay a premium for that. Proof-of-publication allows for different mediums and options to meet users' needs.Paul Snow and Peter Todd discuss the relationship between anti-replay systems and proof-of-publication. Anti-replay systems prevent data repetition but do not provide information about ownership or possession. On the other hand, the blockchain can prove that a message is in the blockchain, and anyone possessing the blockchain possesses the message. They clarify that anti-replay systems are mathematical models and can be implemented in various ways.Mark Friedenbach suggests the possibility of decentralized exchanges using vanilla bitcoin if the protocol supported multiple validated assets. Peter Todd argues that non-proof-of-publication orders are insecure due to sybil attacks. They discuss an example where Alice wants to sell A for B, and Bob is willing to pay more. In a proof-of-publication system, the execution price would be fair for both parties. However, in native assets and sighash_single, miners could exploit the system, leading to unfair execution.In a discussion about new primitives, Adam Back and Peter Todd debate the security implications. Todd suggests using a trusted third party for security, while Back proposes alternative methods. They discuss the risk of sybil attacks and the implementation of double-spending punishment.Paul Snow and Peter Todd discuss the difference between anti-replay systems and proof-of-publication systems. Anti-replay prevents data repetition, while proof-of-publication proves that a message has been published without revealing its content. They clarify that the blockchain can be used to prove message presence and ownership.Peter Todd discusses the limitations of anti-replay for proof-of-publication. Anti-replay cannot determine who possesses a specific message, while proof-of-publication allows repeated entries and leaves interpretation to observers. He suggests testing publishability in an anti-replay system without actual publishing. Overall, anti-replay is insufficient for implementing proof-of-publication uses.In a discussion about decentralized exchanges, Mark Friedenbach suggests the possibility of using vanilla bitcoin with extensions for market participants to use a wider class of orders. Peter Todd argues that such orders are either based on proof-of-publication or insecure due to sybil attacks. The example of trade execution is analyzed to highlight the security concerns.These discussions provide insights into the concept of proof-of-publication, its advantages, limitations, and its role in preventing 2015-01-06T11:03:47+00:00 + Peter Todd proposed a "proof-of-publication" system using OP_RETURN to embed opaque data in transactions, but faced criticism from Adam Back regarding its effectiveness. While establishing "proof-of-publication" as a universal primitive is significant, it alone does not provide sufficient indexing, validation, or exclusion capabilities. The effectiveness of this system and the number of supporters other than Peter Todd remain uncertain.In a discussion on blockchain design, the author explored layer properties such as time-stamping and namespace for constructing a decentralized PoW-chain based ecash system. Time-stamping creates an immutable stream of data with a time-ordering, while namespace adds uniqueness and first-come first-served property. The author concluded that finding improvements in the consensus critical code was challenging. Namespace attributes hold information like public keys, IP addresses, and email addresses. Proof of publication is crucial for miners to have copies of all committed data before building on top of blocks. There is a meta-incentive for bitcoin holders to help others catch up with the history, and information needs to be broadcasted due to numerous miners and full-nodes. The anti-relay term refers to the system level, and attacking the insertion logic is prevented to maintain the integrity of the merkle tree.Peter Todd shared a note about using a "proof-of-publication" system for implementing an "anti-replay" system. However, Todd argued that proof-of-(non)-publication is different from anti-replay and suggested extending the definition of proof-of-(non)-publication. He emphasized the importance of indexes and validation in cryptocurrency designs. While proof-of-(non)-publication is significant, Bitcoin also provides indexing and validation/exclusion functionalities.Various perspectives on the advantages and disadvantages of proof-of-publication markets are discussed in an email exchange. The concept of proof-of-publication allows for tradeoffs and options in connecting sellers and buyers, providing accurate price information. The term "fair" is subjective, making it challenging to define precisely. Some argue that p2p markets can exist without proof of publication, and there are other secure models beyond this concept. Third-parties may republish bids and offers to achieve better price discovery.Jorge Timón explains the advantages of proof-of-publication systems in trade scenarios. He gives an example where a seller wants to sell a unit of A for 100 units of B, and a buyer is willing to pay up to 200 Bs for 1 A. In a proof-of-publication system, the execution price is determined based on bids and asks. However, in the real world, buyers and sellers want to ensure they are connected to actual counterparts and are willing to pay a premium for that. Proof-of-publication allows for different mediums and options to meet users' needs.Paul Snow and Peter Todd discuss the relationship between anti-replay systems and proof-of-publication. Anti-replay systems prevent data repetition but do not provide information about ownership or possession. On the other hand, the blockchain can prove that a message is in the blockchain, and anyone possessing the blockchain possesses the message. They clarify that anti-replay systems are mathematical models and can be implemented in various ways.Mark Friedenbach suggests the possibility of decentralized exchanges using vanilla bitcoin if the protocol supported multiple validated assets. Peter Todd argues that non-proof-of-publication orders are insecure due to sybil attacks. They discuss an example where Alice wants to sell A for B, and Bob is willing to pay more. In a proof-of-publication system, the execution price would be fair for both parties. However, in native assets and sighash_single, miners could exploit the system, leading to unfair execution.In a discussion about new primitives, Adam Back and Peter Todd debate the security implications. Todd suggests using a trusted third party for security, while Back proposes alternative methods. They discuss the risk of sybil attacks and the implementation of double-spending punishment.Paul Snow and Peter Todd discuss the difference between anti-replay systems and proof-of-publication systems. Anti-replay prevents data repetition, while proof-of-publication proves that a message has been published without revealing its content. They clarify that the blockchain can be used to prove message presence and ownership.Peter Todd discusses the limitations of anti-replay for proof-of-publication. Anti-replay cannot determine who possesses a specific message, while proof-of-publication allows repeated entries and leaves interpretation to observers. He suggests testing publishability in an anti-replay system without actual publishing. Overall, anti-replay is insufficient for implementing proof-of-publication uses.In a discussion about decentralized exchanges, Mark Friedenbach suggests the possibility of using vanilla bitcoin with extensions for market participants to use a wider class of orders. Peter Todd argues that such orders are either based on proof-of-publication or insecure due to sybil attacks. The example of trade execution is analyzed to highlight the security concerns.These discussions provide insights into the concept of proof-of-publication, its advantages, limitations, and its role in preventing - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2014/combined_one-show-signatures-Re-The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles-.xml b/static/bitcoin-dev/Dec_2014/combined_one-show-signatures-Re-The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles-.xml index 0972018f36..613c1a5346 100644 --- a/static/bitcoin-dev/Dec_2014/combined_one-show-signatures-Re-The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles-.xml +++ b/static/bitcoin-dev/Dec_2014/combined_one-show-signatures-Re-The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - one-show signatures (Re: The relationship between Proof-of-Publication and Anti-Replay Oracles) - 2023-08-01T11:03:07.484641+00:00 + 2025-10-11T21:53:45.964156+00:00 + python-feedgen paul snow 2014-12-22 00:56:28+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - one-show signatures (Re: The relationship between Proof-of-Publication and Anti-Replay Oracles) - 2023-08-01T11:03:07.484641+00:00 + 2025-10-11T21:53:45.964319+00:00 - In a discussion between Peter Todd and Adam Back, the possibility of preventing double-spending in Bitcoin was explored. Adam Back suggested that it is possible to define a new rule where two signatures authorize something, such as miners taking funds. He mentioned that this could work with existing ECDSA addresses and unrestricted R-value choices.However, Peter Todd argued that clever math alone is not what prevents double-spending in Bitcoin. He emphasized that it is clever economics, like the underlying principle of Bitcoin itself, that prevents double-spending. Todd cautioned against confusing people with complex equations that are not directly relevant to the fundamental principle.Todd further explained that math models reality and has no limits. Therefore, saying that math cannot prevent double-spending is equivalent to saying that it cannot be done. He believed that focusing on complex equations could potentially obscure the more important understanding that math alone cannot prevent double-spending.The conversation also touched upon the possibility of using math to prevent signing more than one message. Adam Back suggested that it may be possible to achieve this to some extent. However, Peter Todd suggested that delving into crypto math at this stage might not be necessary. Instead, he proposed using extensions to the Bitcoin scripting system to verify ECDSA signatures directly.The discussion primarily revolved around the technical aspects of implementing new rules regarding signatures and authorizations. The participants explored how these changes can be achieved within the existing framework of Bitcoin. 2014-12-22T00:56:28+00:00 + In a discussion between Peter Todd and Adam Back, the possibility of preventing double-spending in Bitcoin was explored. Adam Back suggested that it is possible to define a new rule where two signatures authorize something, such as miners taking funds. He mentioned that this could work with existing ECDSA addresses and unrestricted R-value choices.However, Peter Todd argued that clever math alone is not what prevents double-spending in Bitcoin. He emphasized that it is clever economics, like the underlying principle of Bitcoin itself, that prevents double-spending. Todd cautioned against confusing people with complex equations that are not directly relevant to the fundamental principle.Todd further explained that math models reality and has no limits. Therefore, saying that math cannot prevent double-spending is equivalent to saying that it cannot be done. He believed that focusing on complex equations could potentially obscure the more important understanding that math alone cannot prevent double-spending.The conversation also touched upon the possibility of using math to prevent signing more than one message. Adam Back suggested that it may be possible to achieve this to some extent. However, Peter Todd suggested that delving into crypto math at this stage might not be necessary. Instead, he proposed using extensions to the Bitcoin scripting system to verify ECDSA signatures directly.The discussion primarily revolved around the technical aspects of implementing new rules regarding signatures and authorizations. The participants explored how these changes can be achieved within the existing framework of Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_-BIP-Draft-Datastream-compression-of-Blocks-and-Transactions.xml b/static/bitcoin-dev/Dec_2015/combined_-BIP-Draft-Datastream-compression-of-Blocks-and-Transactions.xml index d4957b5497..64e3618942 100644 --- a/static/bitcoin-dev/Dec_2015/combined_-BIP-Draft-Datastream-compression-of-Blocks-and-Transactions.xml +++ b/static/bitcoin-dev/Dec_2015/combined_-BIP-Draft-Datastream-compression-of-Blocks-and-Transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP Draft] Datastream compression of Blocks and Transactions - 2023-08-01T16:57:46.530241+00:00 + 2025-10-11T21:43:10.334779+00:00 + python-feedgen Matt Corallo 2015-12-04 13:30:33+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - [BIP Draft] Datastream compression of Blocks and Transactions - 2023-08-01T16:57:46.531240+00:00 + 2025-10-11T21:43:10.334965+00:00 - In a Bitcoin developer mailing list, concerns were raised about the potential complexity and attack surface that may come with implementing the Lempel-Ziv (LZ) family of compressors. Despite the minor compression gain of 15 to 27%, it was suggested that syncing over slow or restrictive connections could be better addressed by a sync-over-http-via-cdn protocol. However, arguments were made in favor of compression, stating that larger data sizes benefit from better compression and that adding compression could be easily turned off if necessary.The discussion also touched on the limitations of the LZ family of compressors for binary data like the Bitcoin wire protocol. It was proposed that a custom, Bitcoin-aware compressor could achieve significantly higher compression ratios of 2X or more in some cases. However, concerns were raised about the maintainability and potential difficulties in changing the wire format later on. Despite these concerns, the idea of compressing Bitcoin was seen as an opportunity for free improvements and additional throughput without any cost.A programming challenge/contest was suggested as one way to find the best possible, Bitcoin-specific compressor. This would not only lead to potential improvements but also bring new programmers into the ecosystem. The idea of building a standardized dataset using real data from the network to test against was also discussed, allowing for measurements of proposed optimizations.Another email conversation proposed the idea of adding compression directly accessible to the network on financial software. While there were concerns about security issues, it was argued that the LZO compressor has been around for 20 years with few problems. The performance improvement through compression was shown to increase as block sizes increased, making it beneficial for transmission but not for post-processing and validating blocks.Further discussions highlighted the potential benefits of a custom, Bitcoin-specific compressor compared to the existing LZ family of compressors. While LZ compressors assign unique numbers to subsequence encounters, they are not as efficient for binary data like Bitcoin. Building a custom compressor could lead to higher compression ratios, although there are considerations regarding maintainability and potential difficulties in changing the wire format. The idea of a programming challenge/contest to find the best possible Bitcoin-specific compressor was seen as an effective way to discover the limits of compressibility and bring in new programmers.The email exchanges also addressed concerns about the security of compression libraries and the possibility of exposing them to potential attackers. Various suggestions were made, such as isolating the decompression phase and verifying block hashes through external processes or daemons.In summary, there is ongoing discussion among Bitcoin developers regarding the implementation of compression for Bitcoin data transmission. While there are concerns about complexity, attack surface, and potential security issues, there is also recognition of the potential benefits in terms of improved performance and additional throughput. The idea of a custom, Bitcoin-specific compressor has been proposed, along with the suggestion of a programming challenge/contest to find the best possible solution. Overall, the goal is to find the most efficient and secure method of compressing Bitcoin data to enhance network efficiency and scalability. 2015-12-04T13:30:33+00:00 + In a Bitcoin developer mailing list, concerns were raised about the potential complexity and attack surface that may come with implementing the Lempel-Ziv (LZ) family of compressors. Despite the minor compression gain of 15 to 27%, it was suggested that syncing over slow or restrictive connections could be better addressed by a sync-over-http-via-cdn protocol. However, arguments were made in favor of compression, stating that larger data sizes benefit from better compression and that adding compression could be easily turned off if necessary.The discussion also touched on the limitations of the LZ family of compressors for binary data like the Bitcoin wire protocol. It was proposed that a custom, Bitcoin-aware compressor could achieve significantly higher compression ratios of 2X or more in some cases. However, concerns were raised about the maintainability and potential difficulties in changing the wire format later on. Despite these concerns, the idea of compressing Bitcoin was seen as an opportunity for free improvements and additional throughput without any cost.A programming challenge/contest was suggested as one way to find the best possible, Bitcoin-specific compressor. This would not only lead to potential improvements but also bring new programmers into the ecosystem. The idea of building a standardized dataset using real data from the network to test against was also discussed, allowing for measurements of proposed optimizations.Another email conversation proposed the idea of adding compression directly accessible to the network on financial software. While there were concerns about security issues, it was argued that the LZO compressor has been around for 20 years with few problems. The performance improvement through compression was shown to increase as block sizes increased, making it beneficial for transmission but not for post-processing and validating blocks.Further discussions highlighted the potential benefits of a custom, Bitcoin-specific compressor compared to the existing LZ family of compressors. While LZ compressors assign unique numbers to subsequence encounters, they are not as efficient for binary data like Bitcoin. Building a custom compressor could lead to higher compression ratios, although there are considerations regarding maintainability and potential difficulties in changing the wire format. The idea of a programming challenge/contest to find the best possible Bitcoin-specific compressor was seen as an effective way to discover the limits of compressibility and bring in new programmers.The email exchanges also addressed concerns about the security of compression libraries and the possibility of exposing them to potential attackers. Various suggestions were made, such as isolating the decompression phase and verifying block hashes through external processes or daemons.In summary, there is ongoing discussion among Bitcoin developers regarding the implementation of compression for Bitcoin data transmission. While there are concerns about complexity, attack surface, and potential security issues, there is also recognition of the potential benefits in terms of improved performance and additional throughput. The idea of a custom, Bitcoin-specific compressor has been proposed, along with the suggestion of a programming challenge/contest to find the best possible solution. Overall, the goal is to find the most efficient and secure method of compressing Bitcoin data to enhance network efficiency and scalability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml b/static/bitcoin-dev/Dec_2015/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml index 6bfd1a5480..65b66b2084 100644 --- a/static/bitcoin-dev/Dec_2015/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml +++ b/static/bitcoin-dev/Dec_2015/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP Draft] Decentralized Improvement Proposals - 2023-08-01T17:20:15.539624+00:00 + 2025-10-11T21:42:46.968871+00:00 + python-feedgen Rusty Russell 2016-01-03 23:31:26+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - [BIP Draft] Decentralized Improvement Proposals - 2023-08-01T17:20:15.539624+00:00 + 2025-10-11T21:42:46.969049+00:00 - In a discussion on bitcoin-dev, Luke Dashjr and Tomas debated the efficiency of the specification for version bits. Tomas raised concerns about the unclear assignment of version bits in the specification, suggesting that any implementation proposing a change should be encouraged to choose a free version bit to use. Luke agreed that clarification was necessary in the BIP, or Bitcoin Improvement Proposal, and suggested that the BIP editor assign version bits like BIP numbers themselves. However, he also noted that since the number of deployed forks is low, it may not be necessary to have a more robust system. Rusty, another member of the discussion, offered to fill that role if needed.In an email exchange between Tomas and Luke on December 30, 2015, they discuss the efficiency and implementation of version bits in the context of proposing changes to the Bitcoin network. Tomas expresses concern over the inefficiency of the current system and suggests that clarification is needed for assigning version bits. Luke proposes that the BIP editor assign version bits similarly to BIP numbers. Tomas further suggests that his proposal addresses the danger of forward-incompatible changes and eliminates the possibility of a hard fork, but Luke disagrees. He points out that a hard fork can always occur as it is determined by the economy and not miners. Additionally, changes such as a PoW algorithm change could still lead to further rule changes.In a recent discussion, Tomas expressed his opinion on the inefficiency and bloatiness of a specification which appears to be a reinvention of version bits. The allocation of version bits was not clear from the specification, leading to confusion regarding the implementation of proposed changes. Tomas also addressed the issue of forward-incompatible changes by proposing a solution that prevents hard-forks from occurring, ensuring that every implementation agrees on the active set of rules even if it has not implemented them. This crucial aspect seems to be missing in the version bits proposal.In December 2015, Tomas proposed a BIP (Bitcoin Improvement Proposal) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. However, Luke criticized the motivation behind this proposal stating that BIPs are required to have a reference implementation, but it need not necessarily be for Bitcoin Core specifically. He also commented on the specification, saying that it looked like an inefficient and bloaty reinvention of version bits.Tomas van der Wansem has drafted a Bitcoin Improvement Proposal (BIP) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. The BIP can be found on GitHub. He believes that the proposal can help in decentralizing the development of the protocol and mitigate the risk of forks. He is requesting a BIP-number if the proposal is considered worthy of discussion. 2016-01-03T23:31:26+00:00 + In a discussion on bitcoin-dev, Luke Dashjr and Tomas debated the efficiency of the specification for version bits. Tomas raised concerns about the unclear assignment of version bits in the specification, suggesting that any implementation proposing a change should be encouraged to choose a free version bit to use. Luke agreed that clarification was necessary in the BIP, or Bitcoin Improvement Proposal, and suggested that the BIP editor assign version bits like BIP numbers themselves. However, he also noted that since the number of deployed forks is low, it may not be necessary to have a more robust system. Rusty, another member of the discussion, offered to fill that role if needed.In an email exchange between Tomas and Luke on December 30, 2015, they discuss the efficiency and implementation of version bits in the context of proposing changes to the Bitcoin network. Tomas expresses concern over the inefficiency of the current system and suggests that clarification is needed for assigning version bits. Luke proposes that the BIP editor assign version bits similarly to BIP numbers. Tomas further suggests that his proposal addresses the danger of forward-incompatible changes and eliminates the possibility of a hard fork, but Luke disagrees. He points out that a hard fork can always occur as it is determined by the economy and not miners. Additionally, changes such as a PoW algorithm change could still lead to further rule changes.In a recent discussion, Tomas expressed his opinion on the inefficiency and bloatiness of a specification which appears to be a reinvention of version bits. The allocation of version bits was not clear from the specification, leading to confusion regarding the implementation of proposed changes. Tomas also addressed the issue of forward-incompatible changes by proposing a solution that prevents hard-forks from occurring, ensuring that every implementation agrees on the active set of rules even if it has not implemented them. This crucial aspect seems to be missing in the version bits proposal.In December 2015, Tomas proposed a BIP (Bitcoin Improvement Proposal) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. However, Luke criticized the motivation behind this proposal stating that BIPs are required to have a reference implementation, but it need not necessarily be for Bitcoin Core specifically. He also commented on the specification, saying that it looked like an inefficient and bloaty reinvention of version bits.Tomas van der Wansem has drafted a Bitcoin Improvement Proposal (BIP) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. The BIP can be found on GitHub. He believes that the proposal can help in decentralizing the development of the protocol and mitigate the risk of forks. He is requesting a BIP-number if the proposal is considered worthy of discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_-Subsidy-fraud-.xml b/static/bitcoin-dev/Dec_2015/combined_-Subsidy-fraud-.xml index d4834bcc69..df2f70e3dd 100644 --- a/static/bitcoin-dev/Dec_2015/combined_-Subsidy-fraud-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_-Subsidy-fraud-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - "Subsidy fraud" ? - 2023-08-01T17:06:05.091964+00:00 + Combined summary - "Subsidy fraud" ? + 2025-10-11T21:43:40.075123+00:00 + python-feedgen Pieter Wuille 2015-12-09 21:43:22+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 - Combined summary - "Subsidy fraud" ? - 2023-08-01T17:06:05.091964+00:00 + Combined summary - "Subsidy fraud" ? + 2025-10-11T21:43:40.075311+00:00 - In a recent talk by Pieter Wuille, the term "subsidy fraud" was mentioned, leaving users curious about its meaning. The discussion revolved around a miner who claimed more in the coinbase's output than what was allowed by the subsidy and fees. This raised questions about the existence and significance of subsidy fraud in the world of Bitcoin and cryptocurrency.Despite conducting searches on Google and Bitcoin Wiki, the user who posted this inquiry could not find any information regarding subsidy fraud. They proceeded to suggest that if this issue is indeed well-known, it should be explained somewhere for the benefit of others.The video linked in the message features Pieter Wuille discussing various topics related to Bitcoin and blockchain technology. However, the specific explanation or definition of subsidy fraud was not provided.It remains unclear whether subsidy fraud is a widespread problem or merely a rare occurrence within the Bitcoin community. Further research may shed light on this topic and provide more information regarding subsidy fraud and its implications. 2015-12-09T21:43:22+00:00 + In a recent talk by Pieter Wuille, the term "subsidy fraud" was mentioned, leaving users curious about its meaning. The discussion revolved around a miner who claimed more in the coinbase's output than what was allowed by the subsidy and fees. This raised questions about the existence and significance of subsidy fraud in the world of Bitcoin and cryptocurrency.Despite conducting searches on Google and Bitcoin Wiki, the user who posted this inquiry could not find any information regarding subsidy fraud. They proceeded to suggest that if this issue is indeed well-known, it should be explained somewhere for the benefit of others.The video linked in the message features Pieter Wuille discussing various topics related to Bitcoin and blockchain technology. However, the specific explanation or definition of subsidy fraud was not provided.It remains unclear whether subsidy fraud is a widespread problem or merely a rare occurrence within the Bitcoin community. Further research may shed light on this topic and provide more information regarding subsidy fraud and its implications. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_A-new-payment-address-format-for-segregated-witness-or-not-.xml b/static/bitcoin-dev/Dec_2015/combined_A-new-payment-address-format-for-segregated-witness-or-not-.xml index 2e68e947f9..2c2e7d4a6e 100644 --- a/static/bitcoin-dev/Dec_2015/combined_A-new-payment-address-format-for-segregated-witness-or-not-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_A-new-payment-address-format-for-segregated-witness-or-not-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A new payment address format for segregated witness or not? - 2023-08-01T17:17:31.216565+00:00 + 2025-10-11T21:42:57.586664+00:00 + python-feedgen Tier Nolan 2015-12-21 15:48:23+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - A new payment address format for segregated witness or not? - 2023-08-01T17:17:31.216565+00:00 + 2025-10-11T21:42:57.586832+00:00 - On December 21, 2015, concerns were raised about Segregated Witness (SW) in Pay-to-Script-Hash (P2SH) by jl2012. The issue with SW in P2SH was that it required an additional push in scriptSig, which is not prunable in transmission and is counted as part of the core block size. There was confusion regarding the term "prunable in transmission," which meant that it had to be included when not sending the witnesses. However, this caused a name collision with UTXO set prunable. It was clarified that it is actually scriptPubKeys that have to be held in the UTXO database.During a discussion on the -dev IRC, the idea of a new payment address format for native segregated witness (SW) was proposed. This would involve defining a native SW address format in addition to the existing payment protocol and witness program hidden in a P2SH address options. The advantages of having a native SW address include promoting the use of native SW over less efficient SW in P2SH, allowing lower fees, being easy for wallets to implement, and being the last address format to define since SW is flexible. However, there are some disadvantages such as old wallets not being able to pay to a new address and the potential doubling of the address length due to the witness program. Both native SW and SW in P2SH are equally good as a fix for transaction malleability. However, SW in P2SH has slightly better privacy by obscuration and allows payment from any Bitcoin reference client since version 0.6.0. On the other hand, SW in P2SH requires an additional push in scriptSig, which is not prunable in transmission and is counted as part of the core block size. It also requires an additional HASH160 operation and provides 160-bit security compared to native SW's 256-bit security. Despite being less efficient, SW in P2SH still results in a likely lower transaction fee than non-SW transactions.The proposed solutions are as follows: Proposal 1 involves defining a native SW address format while still allowing people to use the payment protocol or SW in P2SH if they prefer. Proposal 2 does not require a new address format and instead requires people to use the payment protocol if they want to pay the lowest fee possible, or else use SW in P2SH.To gather input on this topic that is relevant to user experience, the speaker plans to consult merchants, exchanges, wallet developers, and users for their preferences. This consultation will help in making an informed decision regarding the adoption of a new payment address format for native segregated witness. 2015-12-21T15:48:23+00:00 + On December 21, 2015, concerns were raised about Segregated Witness (SW) in Pay-to-Script-Hash (P2SH) by jl2012. The issue with SW in P2SH was that it required an additional push in scriptSig, which is not prunable in transmission and is counted as part of the core block size. There was confusion regarding the term "prunable in transmission," which meant that it had to be included when not sending the witnesses. However, this caused a name collision with UTXO set prunable. It was clarified that it is actually scriptPubKeys that have to be held in the UTXO database.During a discussion on the -dev IRC, the idea of a new payment address format for native segregated witness (SW) was proposed. This would involve defining a native SW address format in addition to the existing payment protocol and witness program hidden in a P2SH address options. The advantages of having a native SW address include promoting the use of native SW over less efficient SW in P2SH, allowing lower fees, being easy for wallets to implement, and being the last address format to define since SW is flexible. However, there are some disadvantages such as old wallets not being able to pay to a new address and the potential doubling of the address length due to the witness program. Both native SW and SW in P2SH are equally good as a fix for transaction malleability. However, SW in P2SH has slightly better privacy by obscuration and allows payment from any Bitcoin reference client since version 0.6.0. On the other hand, SW in P2SH requires an additional push in scriptSig, which is not prunable in transmission and is counted as part of the core block size. It also requires an additional HASH160 operation and provides 160-bit security compared to native SW's 256-bit security. Despite being less efficient, SW in P2SH still results in a likely lower transaction fee than non-SW transactions.The proposed solutions are as follows: Proposal 1 involves defining a native SW address format while still allowing people to use the payment protocol or SW in P2SH if they prefer. Proposal 2 does not require a new address format and instead requires people to use the payment protocol if they want to pay the lowest fee possible, or else use SW in P2SH.To gather input on this topic that is relevant to user experience, the speaker plans to consult merchants, exchanges, wallet developers, and users for their preferences. This consultation will help in making an informed decision regarding the adoption of a new payment address format for native segregated witness. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_An-implementation-of-BIP102-as-a-softfork-.xml b/static/bitcoin-dev/Dec_2015/combined_An-implementation-of-BIP102-as-a-softfork-.xml index 5106dd4f2a..eaa55e6a4a 100644 --- a/static/bitcoin-dev/Dec_2015/combined_An-implementation-of-BIP102-as-a-softfork-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_An-implementation-of-BIP102-as-a-softfork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - An implementation of BIP102 as a softfork. - 2023-08-01T17:19:26.356499+00:00 + 2025-10-11T21:42:49.092843+00:00 + python-feedgen joe2015 at openmailbox.org 2016-01-12 03:58:13+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - An implementation of BIP102 as a softfork. - 2023-08-01T17:19:26.357464+00:00 + 2025-10-11T21:42:49.093006+00:00 - In a Bitcoin-dev mailing list, Joe2015 responded to Nick ODell's query about fee collection from transactions in the block. Joe suggested mapping the new-rules coinbase transaction into an old-rules legacy coinbase transaction, but emphasized the need for careful consideration to ensure the mapping is irreversible. Joe has redesigned the implementation and provided GitHub links for reference. The new version maps the Merkle root onto a 'legacy' coinbase transaction, effectively solving the problem with fees.The conversation on the Bitcoin-dev mailing list revolves around Joe's proposal for a "generalized soft fork." Marco Falke expresses doubts about the proposal, arguing that it contradicts the definition of a soft fork as it requires nodes to upgrade. Joe clarifies that while it may not technically be a soft fork, it possesses similar properties except for meaningful backwards compatibility for non-upgraded clients. Marco raises concerns about how non-updated nodes would verify collected fees without actual transactions at hand and suggests a hard fork as a cleaner solution. Joe acknowledges that hard forks can be cleaner but highlights the risk of network splitting between upgraded and non-upgraded clients. He argues that a "firm soft fork" could be a better option. However, Joe realizes an oversight in his proof-of-concept implementation where all transactions would have to be zero-fee due to missing fees from non-updated nodes. He suggests implicitly adding the fees or finding other solutions.Marco Falke and Joe discuss the concept of a "generalized" soft fork. Falke questions the property of a true soft fork as it requires nodes to upgrade, leaving non-upgraded nodes vulnerable to double spends. Joe suggests allowing the new rules to add fees implicitly as a solution. When Falke questions the benefits of a "generalized" soft fork over a hard fork, Joe emphasizes the risk of a network split between upgraded and non-upgraded clients and argues that a "firm" soft fork is a better option in such cases.The Bitcoin developer community is discussing a proposal called the "forced soft-fork," which would require all nodes on the network to upgrade to the latest software version. The proposal has received mixed reactions, with some considering it "crufty and hackish" while others argue that the fear of recursion is misplaced. The forced soft-fork involves a multi-levels-deep block-within-a-block approach, but proponents claim that careful planning can simplify it. While the forced soft-fork could make it easier for developers to implement new features and upgrades, concerns about its impact on the security and stability of the Bitcoin network remain.In a discussion on the bitcoin-dev mailing list, Martijn Meijering expresses concerns about blocking old clients from seeing transactions. Peter Todd warns against sending multiple transactions without knowing if the longest blockchain is being seen and suggests designing software with fee-bumping to avoid mistakes. Increasing the tx version number could potentially disrupt pre-signed transactions.Jonathan Toomim voices his opinion against a proposed approach involving multi-levels-deep block structures for generalized softforks, deeming it interesting but hackish and not deployable. Another participant suggests incorporating the forced fork concept into Bitcoin by committing to H(version + digest) in block headers. This approach would provide safety advantages over hard forks and relatively simple implementation, though it may institutionalize 51% attacks and give miners more political control.A proposal for a softfork implementation of BIP102, normally a hardfork, has been shared on the bitcoin-dev mailing list. The implementation uses a strategy pattern to address concerns with deploying a block-size increase through a hardfork. Post-fork blocks are constructed to be mapped to valid blocks under pre-fork rules, allowing post-fork miners to create a valid chain indirectly. For non-upgraded clients, the block-size limit is circumvented by moving transaction validation data "outside" of the block, while upgraded clients see an unchanged block layout with a larger block-size limit and a new interpretation of the header Merkle root encoded in the coinbase. This implementation reduces fraud risk and requires miner majority to force miner consensus.A concern has been raised about the safety of old clients not being able to see transactions due to a new transaction blocking feature. It is suggested that increasing the tx version number could prevent transactions sent from old clients from confirming. The inclusion of this idea in the code remains uncertain.Marco questions whether a proposed approach is actually a soft fork, as it requires nodes to upgrade. He argues that true soft forks don't require any node upgrades and expresses concerns about missing transactions and vulnerability to double spends for non-upgraded nodes. Marco asks if there is something he is missing about the proposal.A proof-of-concept implementation of BIP102 as a softfork has been developed under the unofficial codename BIP102s. It constructs post-fork blocks that can be mapped to valid blocks under pre-fork rules, enabling post-fork miners to create a valid chain indirectly. Non-upgraded clients see the circumvention of 2016-01-12T03:58:13+00:00 + In a Bitcoin-dev mailing list, Joe2015 responded to Nick ODell's query about fee collection from transactions in the block. Joe suggested mapping the new-rules coinbase transaction into an old-rules legacy coinbase transaction, but emphasized the need for careful consideration to ensure the mapping is irreversible. Joe has redesigned the implementation and provided GitHub links for reference. The new version maps the Merkle root onto a 'legacy' coinbase transaction, effectively solving the problem with fees.The conversation on the Bitcoin-dev mailing list revolves around Joe's proposal for a "generalized soft fork." Marco Falke expresses doubts about the proposal, arguing that it contradicts the definition of a soft fork as it requires nodes to upgrade. Joe clarifies that while it may not technically be a soft fork, it possesses similar properties except for meaningful backwards compatibility for non-upgraded clients. Marco raises concerns about how non-updated nodes would verify collected fees without actual transactions at hand and suggests a hard fork as a cleaner solution. Joe acknowledges that hard forks can be cleaner but highlights the risk of network splitting between upgraded and non-upgraded clients. He argues that a "firm soft fork" could be a better option. However, Joe realizes an oversight in his proof-of-concept implementation where all transactions would have to be zero-fee due to missing fees from non-updated nodes. He suggests implicitly adding the fees or finding other solutions.Marco Falke and Joe discuss the concept of a "generalized" soft fork. Falke questions the property of a true soft fork as it requires nodes to upgrade, leaving non-upgraded nodes vulnerable to double spends. Joe suggests allowing the new rules to add fees implicitly as a solution. When Falke questions the benefits of a "generalized" soft fork over a hard fork, Joe emphasizes the risk of a network split between upgraded and non-upgraded clients and argues that a "firm" soft fork is a better option in such cases.The Bitcoin developer community is discussing a proposal called the "forced soft-fork," which would require all nodes on the network to upgrade to the latest software version. The proposal has received mixed reactions, with some considering it "crufty and hackish" while others argue that the fear of recursion is misplaced. The forced soft-fork involves a multi-levels-deep block-within-a-block approach, but proponents claim that careful planning can simplify it. While the forced soft-fork could make it easier for developers to implement new features and upgrades, concerns about its impact on the security and stability of the Bitcoin network remain.In a discussion on the bitcoin-dev mailing list, Martijn Meijering expresses concerns about blocking old clients from seeing transactions. Peter Todd warns against sending multiple transactions without knowing if the longest blockchain is being seen and suggests designing software with fee-bumping to avoid mistakes. Increasing the tx version number could potentially disrupt pre-signed transactions.Jonathan Toomim voices his opinion against a proposed approach involving multi-levels-deep block structures for generalized softforks, deeming it interesting but hackish and not deployable. Another participant suggests incorporating the forced fork concept into Bitcoin by committing to H(version + digest) in block headers. This approach would provide safety advantages over hard forks and relatively simple implementation, though it may institutionalize 51% attacks and give miners more political control.A proposal for a softfork implementation of BIP102, normally a hardfork, has been shared on the bitcoin-dev mailing list. The implementation uses a strategy pattern to address concerns with deploying a block-size increase through a hardfork. Post-fork blocks are constructed to be mapped to valid blocks under pre-fork rules, allowing post-fork miners to create a valid chain indirectly. For non-upgraded clients, the block-size limit is circumvented by moving transaction validation data "outside" of the block, while upgraded clients see an unchanged block layout with a larger block-size limit and a new interpretation of the header Merkle root encoded in the coinbase. This implementation reduces fraud risk and requires miner majority to force miner consensus.A concern has been raised about the safety of old clients not being able to see transactions due to a new transaction blocking feature. It is suggested that increasing the tx version number could prevent transactions sent from old clients from confirming. The inclusion of this idea in the code remains uncertain.Marco questions whether a proposed approach is actually a soft fork, as it requires nodes to upgrade. He argues that true soft forks don't require any node upgrades and expresses concerns about missing transactions and vulnerability to double spends for non-upgraded nodes. Marco asks if there is something he is missing about the proposal.A proof-of-concept implementation of BIP102 as a softfork has been developed under the unofficial codename BIP102s. It constructs post-fork blocks that can be mapped to valid blocks under pre-fork rules, enabling post-fork miners to create a valid chain indirectly. Non-upgraded clients see the circumvention of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_BIP-9-style-version-bits-for-txns.xml b/static/bitcoin-dev/Dec_2015/combined_BIP-9-style-version-bits-for-txns.xml index 84be1bee47..3c3edfb167 100644 --- a/static/bitcoin-dev/Dec_2015/combined_BIP-9-style-version-bits-for-txns.xml +++ b/static/bitcoin-dev/Dec_2015/combined_BIP-9-style-version-bits-for-txns.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 9 style version bits for txns - 2023-08-01T17:05:19.632920+00:00 + 2025-10-11T21:43:12.457428+00:00 + python-feedgen Chris Priest 2015-12-08 22:27:48+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP 9 style version bits for txns - 2023-08-01T17:05:19.632920+00:00 + 2025-10-11T21:43:12.457561+00:00 - In the world of Bitcoin, transactions are received and broadcasted by nodes rather than wallets. While all wallets were initially nodes, most wallets nowadays are standalone without any specific node. In a discussion among Bitcoin developers, it was proposed that wallet developers indicate their readiness for soft forks, hard forks, or new features instead of implementing them directly. This would involve testing and validating these changes to ensure they do not break the nodes or wallet software.Chris Priest suggested splitting the version field into two parts: the first four bytes for the version number and the second four bits for transaction type. This would allow for assigning a new "type" number to any new transaction feature, which can only be implemented once the nodes support it. Vincent Truong further proposed extending/copying isSupermajority() to include a similar BIP 9 style version bit in transactions. If a majority of transactions have been sent and flagged as ready, it would indicate their readiness for implementation.The discussion highlighted that while the BIP9 mechanism applies to voting on blocks, it may not necessarily apply to transactions since they typically affect at most two parties. The flexibility of soft forks allows wallets to choose whether or not to implement new features. The proposal to split the version field and introduce a new "type" number aims to ensure readiness for change and prevent the introduction of security flaws. However, it was acknowledged that this approach could be computationally expensive for Bitcoin Core to run, suggesting that enthusiasts outside the network could monitor transactions instead.In conclusion, the discussion focused on finding ways to make the implementation of new features politically correct while ensuring readiness for change. The proposal to split the version field and incorporate a signaling mechanism through transactions aims to involve wallet developers, exchanges, and miners in the readiness process. Trust is required for miners not to jump the gun, but this approach aims to provide a fair and inclusive way for stakeholders to participate in the decision-making process. 2015-12-08T22:27:48+00:00 + In the world of Bitcoin, transactions are received and broadcasted by nodes rather than wallets. While all wallets were initially nodes, most wallets nowadays are standalone without any specific node. In a discussion among Bitcoin developers, it was proposed that wallet developers indicate their readiness for soft forks, hard forks, or new features instead of implementing them directly. This would involve testing and validating these changes to ensure they do not break the nodes or wallet software.Chris Priest suggested splitting the version field into two parts: the first four bytes for the version number and the second four bits for transaction type. This would allow for assigning a new "type" number to any new transaction feature, which can only be implemented once the nodes support it. Vincent Truong further proposed extending/copying isSupermajority() to include a similar BIP 9 style version bit in transactions. If a majority of transactions have been sent and flagged as ready, it would indicate their readiness for implementation.The discussion highlighted that while the BIP9 mechanism applies to voting on blocks, it may not necessarily apply to transactions since they typically affect at most two parties. The flexibility of soft forks allows wallets to choose whether or not to implement new features. The proposal to split the version field and introduce a new "type" number aims to ensure readiness for change and prevent the introduction of security flaws. However, it was acknowledged that this approach could be computationally expensive for Bitcoin Core to run, suggesting that enthusiasts outside the network could monitor transactions instead.In conclusion, the discussion focused on finding ways to make the implementation of new features politically correct while ensuring readiness for change. The proposal to split the version field and incorporate a signaling mechanism through transactions aims to involve wallet developers, exchanges, and miners in the readiness process. Trust is required for miners not to jump the gun, but this approach aims to provide a fair and inclusive way for stakeholders to participate in the decision-making process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_BIP-numbers.xml b/static/bitcoin-dev/Dec_2015/combined_BIP-numbers.xml index 6f34abfb0d..1d58842d2f 100644 --- a/static/bitcoin-dev/Dec_2015/combined_BIP-numbers.xml +++ b/static/bitcoin-dev/Dec_2015/combined_BIP-numbers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP numbers - 2023-08-01T17:20:56.117370+00:00 + 2025-10-11T21:43:16.709068+00:00 + python-feedgen Adrian Macneil 2015-12-31 23:30:02+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP numbers - 2023-08-01T17:20:56.117370+00:00 + 2025-10-11T21:43:16.709252+00:00 - A recent thread on the Bitcoin-dev mailing list has sparked a discussion about simplifying the process of assigning BIP (Bitcoin Improvement Proposal) numbers. The proposal suggests allowing anyone to open a pull request and use the PR # as the BIP #, thus avoiding conflicts and eliminating the need for manual assignment. However, concerns have been raised that this approach may result in some numbers going unused if PRs are opened to update existing BIPs.One user in the thread suggests that BIP numbers should only be assigned after significant adoption, in order to avoid the headaches caused by the current system. They argue that the Bitcoin consensus protocol development process is often backwards, with the code being written before the human-readable reference explaining it (the BIP). This user's perspective highlights the need for a more streamlined and efficient process for assigning BIP numbers.Marco Pontello also questions the current process of assigning BIP numbers and suggests that it should be a mere formality to avoid conflicts and BIP spamming. He notes that the current process can take months due to the lengthy PR request list and wonders if there is some historical context that he may be missing. Peter Todd responds to this concern by explaining that getting a BIP number assigned is usually one of the last steps taken by the better-known Bitcoin Core developers. He further explains that the development process itself is often backwards, with the protocol specification (code) being written first and the human-readable reference (BIP) being written afterwards.While the BIP number assignment process may appear to be a mere formality, it holds significance in providing an aura of officiality and making it easy to refer to a particular BIP. It serves as an important step in the overall process of adding a BIP to the main repository and eventual approval. However, the process can be time-consuming due to the PR request list. The reasons behind this delay may lie in some historical context that has not been fully explained in the thread. Overall, the discussion highlights the need for a more efficient and streamlined process for assigning BIP numbers to ensure the smooth development and adoption of Bitcoin improvements. 2015-12-31T23:30:02+00:00 + A recent thread on the Bitcoin-dev mailing list has sparked a discussion about simplifying the process of assigning BIP (Bitcoin Improvement Proposal) numbers. The proposal suggests allowing anyone to open a pull request and use the PR # as the BIP #, thus avoiding conflicts and eliminating the need for manual assignment. However, concerns have been raised that this approach may result in some numbers going unused if PRs are opened to update existing BIPs.One user in the thread suggests that BIP numbers should only be assigned after significant adoption, in order to avoid the headaches caused by the current system. They argue that the Bitcoin consensus protocol development process is often backwards, with the code being written before the human-readable reference explaining it (the BIP). This user's perspective highlights the need for a more streamlined and efficient process for assigning BIP numbers.Marco Pontello also questions the current process of assigning BIP numbers and suggests that it should be a mere formality to avoid conflicts and BIP spamming. He notes that the current process can take months due to the lengthy PR request list and wonders if there is some historical context that he may be missing. Peter Todd responds to this concern by explaining that getting a BIP number assigned is usually one of the last steps taken by the better-known Bitcoin Core developers. He further explains that the development process itself is often backwards, with the protocol specification (code) being written first and the human-readable reference (BIP) being written afterwards.While the BIP number assignment process may appear to be a mere formality, it holds significance in providing an aura of officiality and making it easy to refer to a particular BIP. It serves as an important step in the overall process of adding a BIP to the main repository and eventual approval. However, the process can be time-consuming due to the PR request list. The reasons behind this delay may lie in some historical context that has not been fully explained in the thread. Overall, the discussion highlights the need for a more efficient and streamlined process for assigning BIP numbers to ensure the smooth development and adoption of Bitcoin improvements. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Block-size-It-s-economics-user-preparation-moral-hazard.xml b/static/bitcoin-dev/Dec_2015/combined_Block-size-It-s-economics-user-preparation-moral-hazard.xml index 82effb2e31..60b33b101e 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Block-size-It-s-economics-user-preparation-moral-hazard.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Block-size-It-s-economics-user-preparation-moral-hazard.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block size: It's economics & user preparation & moral hazard - 2023-08-01T17:10:34.372179+00:00 + 2025-10-11T21:43:14.582029+00:00 + python-feedgen Justus Ranvier 2015-12-27 00:33:58+00:00 @@ -127,13 +128,13 @@ - python-feedgen + 2 Combined summary - Block size: It's economics & user preparation & moral hazard - 2023-08-01T17:10:34.372179+00:00 + 2025-10-11T21:43:14.582285+00:00 - Email exchanges and discussions on the bitcoin-dev mailing list are focused on hard forks and increasing the block size of Bitcoin. Bryan Bishop denies claims of stalling in deploying a hard fork and emphasizes extensive discussion about different block size proposals. However, he is accused of being condescending and banning someone from the mailing list to prevent uncomfortable questions. The other person raises concerns about stonewalling, deception, conflicts of interest, and crimes.Pieter Wuille proposes a timeframe of 6 to 12 months for an uncontroversial hard fork and suggests involving miners as an extra layer of safety. He also mentions using the Alert System and creating an "Upgrade now!" message to encourage node upgrades. Jonathan Toomim agrees that user and miner adoption for a hard fork will not be difficult but argues against giving miners the power to trigger the fork. He believes consensus should be hard to change and that visible full nodes' upgrade percentage should be considered.Discussions highlight the importance of planning ahead to avoid forced upgrades during capacity emergencies. Pieter Wuille notes that even non-controversial proposals have taken longer than expected for full node adoption. He suggests incentivizing full node upgrades when a hard fork is implemented. In another discussion, Wuille expresses concern that setting the switchover point for a hard fork at 75% consensus would result in a temporary forked off chain. A grace period of 4000 to 8000 blocks (1 to 2 months) is suggested, but slow adoption rates for uncontroversial changes are acknowledged.The role of Bitcoin Core maintainers in judging consensus for a hard fork is discussed, emphasizing the need for widespread agreement. Soft forks are seen as a viable alternative to hard forks in the short-term. The discussion also touches on the concept of the bitcoin-core release as a Schelling point in the consensus game.One email offers a Bitcoin reward for those affected by a hard fork to 2MB blocks and proposes incentivizing miners by pledging a portion of a fund. Risks and alternative methods are discussed. Another conversation focuses on math equations, the benefits and drawbacks of hard forks and soft forks, and the ongoing decision-making process to improve Bitcoin's scalability and efficiency.Jeff Garzik expresses concern about the power of the Bitcoin Core development team in deciding network consensus rules. Pieter Wuille argues for continuing what is known to work and emphasizes the need for an expected upgrade at a predictable date in the future.In discussions around Segregated Witness (SegWit), Pieter Wuille argues that robust adoption rates by up-layer ecosystem software are not required for its success. He highlights the benefits of SegWit, such as increased capacity and better security models, independent of others' adoption.The decentralization of Bitcoin gives miners the power to veto any block size increases. Users also have some power, but imposing costs on others harms themselves. Various groups like Core Devs, miners, exchanges, merchants, and customers each have their own interests and potential for influence. Changes can be made without complete agreement, but if merchants and customers switch to different software, it can have a significant impact.Pieter Wuille emphasizes that no one group is in charge of making decisions regarding Bitcoin. Consensus is important, but not always necessary. The core dev team has been given authority by the most powerful groups but can be checked if necessary. Communication about protocol changes is important to avoid confusion.The main objective in maintaining the Service is to ensure its vitality, security, decentralization, and resistance to censorship for as many Users as possible. Block size functions as a limited resource, becoming available every 10 minutes with some variability. Users, block size, and the bidding process are intertwined, with hashpower assessing block inclusion based on transaction fees. Recent changes in the mempool have introduced a floating relay fee, enhancing responsiveness to rapidly changing markets and Denial-of-Service attacks. Efforts are focused on maintaining a thriving, secure, decentralized, and censorship-resistant Service for all Users. 2015-12-27T00:33:58+00:00 + Email exchanges and discussions on the bitcoin-dev mailing list are focused on hard forks and increasing the block size of Bitcoin. Bryan Bishop denies claims of stalling in deploying a hard fork and emphasizes extensive discussion about different block size proposals. However, he is accused of being condescending and banning someone from the mailing list to prevent uncomfortable questions. The other person raises concerns about stonewalling, deception, conflicts of interest, and crimes.Pieter Wuille proposes a timeframe of 6 to 12 months for an uncontroversial hard fork and suggests involving miners as an extra layer of safety. He also mentions using the Alert System and creating an "Upgrade now!" message to encourage node upgrades. Jonathan Toomim agrees that user and miner adoption for a hard fork will not be difficult but argues against giving miners the power to trigger the fork. He believes consensus should be hard to change and that visible full nodes' upgrade percentage should be considered.Discussions highlight the importance of planning ahead to avoid forced upgrades during capacity emergencies. Pieter Wuille notes that even non-controversial proposals have taken longer than expected for full node adoption. He suggests incentivizing full node upgrades when a hard fork is implemented. In another discussion, Wuille expresses concern that setting the switchover point for a hard fork at 75% consensus would result in a temporary forked off chain. A grace period of 4000 to 8000 blocks (1 to 2 months) is suggested, but slow adoption rates for uncontroversial changes are acknowledged.The role of Bitcoin Core maintainers in judging consensus for a hard fork is discussed, emphasizing the need for widespread agreement. Soft forks are seen as a viable alternative to hard forks in the short-term. The discussion also touches on the concept of the bitcoin-core release as a Schelling point in the consensus game.One email offers a Bitcoin reward for those affected by a hard fork to 2MB blocks and proposes incentivizing miners by pledging a portion of a fund. Risks and alternative methods are discussed. Another conversation focuses on math equations, the benefits and drawbacks of hard forks and soft forks, and the ongoing decision-making process to improve Bitcoin's scalability and efficiency.Jeff Garzik expresses concern about the power of the Bitcoin Core development team in deciding network consensus rules. Pieter Wuille argues for continuing what is known to work and emphasizes the need for an expected upgrade at a predictable date in the future.In discussions around Segregated Witness (SegWit), Pieter Wuille argues that robust adoption rates by up-layer ecosystem software are not required for its success. He highlights the benefits of SegWit, such as increased capacity and better security models, independent of others' adoption.The decentralization of Bitcoin gives miners the power to veto any block size increases. Users also have some power, but imposing costs on others harms themselves. Various groups like Core Devs, miners, exchanges, merchants, and customers each have their own interests and potential for influence. Changes can be made without complete agreement, but if merchants and customers switch to different software, it can have a significant impact.Pieter Wuille emphasizes that no one group is in charge of making decisions regarding Bitcoin. Consensus is important, but not always necessary. The core dev team has been given authority by the most powerful groups but can be checked if necessary. Communication about protocol changes is important to avoid confusion.The main objective in maintaining the Service is to ensure its vitality, security, decentralization, and resistance to censorship for as many Users as possible. Block size functions as a limited resource, becoming available every 10 minutes with some variability. Users, block size, and the bidding process are intertwined, with hashpower assessing block inclusion based on transaction fees. Recent changes in the mempool have introduced a floating relay fee, enhancing responsiveness to rapidly changing markets and Denial-of-Service attacks. Efforts are focused on maintaining a thriving, secure, decentralized, and censorship-resistant Service for all Users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Blockchain-verification-flag-BIP-draft-.xml b/static/bitcoin-dev/Dec_2015/combined_Blockchain-verification-flag-BIP-draft-.xml index dde38d1c0e..e2781d649c 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Blockchain-verification-flag-BIP-draft-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Blockchain-verification-flag-BIP-draft-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Blockchain verification flag (BIP draft) - 2023-08-01T16:59:30.753039+00:00 + 2025-10-11T21:43:35.826064+00:00 + python-feedgen Gregory Maxwell 2015-12-06 06:26:15+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Blockchain verification flag (BIP draft) - 2023-08-01T16:59:30.753039+00:00 + 2025-10-11T21:43:35.826241+00:00 - In December 2015, an email chain discussed concerns about cgminer and its inability to allow a pool to revert to mining on the previous block due to chain tracking issues. The discussion proposed a potential use for a flag that would enable non-monotone mining for non-verified blocks. The email suggested adding a recommendation for this use to the draft.Another discussion focused on how SPV clients should be informed about fully validated headers without penalizing the blocks too much. It was agreed that only fully validated headers should be shared with SPV clients, but the balance between penalizing blocks and incentivizing the proposed solution was emphasized. The importance of establishing connections to multiple nodes and avoiding surprises from unverified blocks was also highlighted.The email thread also touched upon the Bitcoin Improvement Proposal (BIP) to mitigate the 'accidental selfish mining' problem. It was suggested to include a write-up explaining the problem and how the proposed solution addresses it in the BIP. Using bit 0 instead of bit 30 in the versionbits BIP and BIP101 was recommended to avoid confusion. The discussion also mentioned that SPV clients should only be informed about fully validated headers. Further deliberations on the matter were planned for the future.The propagation of new information in gossip networks was discussed, emphasizing the need to relay all information to peers promptly. The difference between a block and its header was explained, and the suggestion of including an indicator in the header to signal whether the miner has validated the chain was made. However, it was noted that accepting such proof could lead to ignoring important blocks. The potential problems with one node choosing not to validate for reduced latency were also considered.The Bitcoin community discussed the potential benefits of a Blockchain verification flag used by miners to signal complete validation of their block and preceding blocks. This was proposed as a solution to miners not verifying blocks for economic reasons, which can harm the system. However, correct use of this signaling is not enforced internally, and there are concerns about misuse and false signaling. It was recommended that non-full-node wallets refrain from counting confirmations on blocks where the flag is not set.The BIP draft-maxwell-flagverify proposed a flag for block authors to signal complete validation. The use of this flag could turn harmful validation skipping by miners into behavior beneficial to the public. However, the accuracy of the flag cannot be strongly relied upon, as miners can stop using it at any time. The motivation behind this proposal was to address vulnerabilities in thin-client wallets and improve the security of Bitcoin in the long term.Overall, the discussions focused on improving the validation process, addressing the 'accidental selfish mining' problem, and ensuring SPV clients receive accurate information while avoiding penalizing blocks excessively. 2015-12-06T06:26:15+00:00 + In December 2015, an email chain discussed concerns about cgminer and its inability to allow a pool to revert to mining on the previous block due to chain tracking issues. The discussion proposed a potential use for a flag that would enable non-monotone mining for non-verified blocks. The email suggested adding a recommendation for this use to the draft.Another discussion focused on how SPV clients should be informed about fully validated headers without penalizing the blocks too much. It was agreed that only fully validated headers should be shared with SPV clients, but the balance between penalizing blocks and incentivizing the proposed solution was emphasized. The importance of establishing connections to multiple nodes and avoiding surprises from unverified blocks was also highlighted.The email thread also touched upon the Bitcoin Improvement Proposal (BIP) to mitigate the 'accidental selfish mining' problem. It was suggested to include a write-up explaining the problem and how the proposed solution addresses it in the BIP. Using bit 0 instead of bit 30 in the versionbits BIP and BIP101 was recommended to avoid confusion. The discussion also mentioned that SPV clients should only be informed about fully validated headers. Further deliberations on the matter were planned for the future.The propagation of new information in gossip networks was discussed, emphasizing the need to relay all information to peers promptly. The difference between a block and its header was explained, and the suggestion of including an indicator in the header to signal whether the miner has validated the chain was made. However, it was noted that accepting such proof could lead to ignoring important blocks. The potential problems with one node choosing not to validate for reduced latency were also considered.The Bitcoin community discussed the potential benefits of a Blockchain verification flag used by miners to signal complete validation of their block and preceding blocks. This was proposed as a solution to miners not verifying blocks for economic reasons, which can harm the system. However, correct use of this signaling is not enforced internally, and there are concerns about misuse and false signaling. It was recommended that non-full-node wallets refrain from counting confirmations on blocks where the flag is not set.The BIP draft-maxwell-flagverify proposed a flag for block authors to signal complete validation. The use of this flag could turn harmful validation skipping by miners into behavior beneficial to the public. However, the accuracy of the flag cannot be strongly relied upon, as miners can stop using it at any time. The motivation behind this proposal was to address vulnerabilities in thin-client wallets and improve the security of Bitcoin in the long term.Overall, the discussions focused on improving the validation process, addressing the 'accidental selfish mining' problem, and ensuring SPV clients receive accurate information while avoiding penalizing blocks excessively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Capacity-increases-for-the-Bitcoin-system-.xml b/static/bitcoin-dev/Dec_2015/combined_Capacity-increases-for-the-Bitcoin-system-.xml index b05c2566f5..3909568c37 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Capacity-increases-for-the-Bitcoin-system-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Capacity-increases-for-the-Bitcoin-system-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Capacity increases for the Bitcoin system. - 2023-08-01T17:02:46.399474+00:00 + 2025-10-11T21:43:31.576165+00:00 + python-feedgen Anthony Towns 2016-01-22 09:46:18+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 Combined summary - Capacity increases for the Bitcoin system. - 2023-08-01T17:02:46.401474+00:00 + 2025-10-11T21:43:31.576466+00:00 - Recent discussions among Bitcoin developers have centered around the implementation of Segregated Witness (SegWit) in Bitcoin transactions. The focus is on increasing efficiency for pay-to-public-key-hash (p2pkh) transactions. The latest segwit code utilizes "OP_0 [hash]" to push the version and hash separately, resulting in a reduction of 5 bytes per output for p2pkh transactions. This improvement is expected to lead to an increase in p2pkh and multisig transactions.Implementing SegWit would come at a cost, with the scaling factors estimated to be 170% for p2pkh transactions and 250%-300% for multisig transactions. The effective block size for p2pkh with SegWit is estimated to be 1.7MB, while for 2/2 multisig it is 2MB. Additionally, there are two potential soft-fork improvements that could make p2pkh and multisig more space efficient: ECDSA public key recovery and Schnorr signatures.The deployment of SegWit as a hardfork is supported by some defenders as it would solve scalability problems and make Bitcoin more stable. However, they also support the softfork version of SegWit, which is currently available. The plan is to do a softfork first and then a hardfork to move the witness tree outside of the coinbase. This approach is seen as exciting and believed to accelerate the deployment of SegWit.There is a proposal called "Capacity Increases for the Bitcoin System" that aims to solve scalability issues and make Bitcoin more stable. It suggests implementing a soft-fork SegWit 4MB block, which would increase capacity and scalability. Pieter Wuille supports this plan and believes it will improve productivity and the health of the community.Discussions also took place regarding the impact of segwit-spending inputs on block size. Different scenarios were explored, and optimizations were suggested to prevent abuse. There were also discussions on various topics related to Bitcoin development, including modifications to a struct for forward compatibility and moving the height to a more accessible place.The deployment of Segregated Witness (SegWit) via soft fork or hard fork was debated, with differing opinions on the best approach. Some argued that a hard fork would simplify merge-mining and reduce the size of fraud proofs, while others had concerns about security assumptions for non-upgraded clients. The question of whether the current state of affairs is acceptable to heavy users of the Bitcoin network was also raised.Overall, these discussions focused on the potential benefits and implementation of SegWit in Bitcoin transactions. There were debates on the placement of the segwit merkle root and whether a soft fork or hard fork would be more beneficial. The community continues to work towards finding solutions to scale Bitcoin and increase its capacity.In order to increase scalability and capacity, a proposal has been made to implement a soft-fork to Bitcoin. This proposal involves separating signatures from the main block, which would bypass the current blocksize limit and offer other benefits such as enhanced safety and elimination of signature malleability problems. The implementation of this proposal could lead to a 2x capacity increase and make future capacity expansions safer and more efficient.A working implementation of this proposal can be found at https://github.com/sipa/bitcoin/commits/segwit. Additionally, efforts are being made to develop more efficient block relay techniques that would reduce propagation latency. The author also emphasizes the significance of non-bandwidth scaling mechanisms, such as transaction cut-through and bidirectional payment channels, which utilize smart contracts to increase capacity and speed. These approaches have the potential for high capacity and decentralization.There are other proposals being explored, such as flexible caps or incentive-aligned dynamic block size controls, to maintain the alignment of incentives between miners and node operators. The author also highlights the importance of being prepared to implement moderate block size increases when improvements and understanding make their risks widely acceptable compared to the risks of not deploying them.Overall, the author believes that recent progress has positioned the Bitcoin ecosystem well to address its current capacity needs while setting the stage for further improvement and evolution. 2016-01-22T09:46:18+00:00 + Recent discussions among Bitcoin developers have centered around the implementation of Segregated Witness (SegWit) in Bitcoin transactions. The focus is on increasing efficiency for pay-to-public-key-hash (p2pkh) transactions. The latest segwit code utilizes "OP_0 [hash]" to push the version and hash separately, resulting in a reduction of 5 bytes per output for p2pkh transactions. This improvement is expected to lead to an increase in p2pkh and multisig transactions.Implementing SegWit would come at a cost, with the scaling factors estimated to be 170% for p2pkh transactions and 250%-300% for multisig transactions. The effective block size for p2pkh with SegWit is estimated to be 1.7MB, while for 2/2 multisig it is 2MB. Additionally, there are two potential soft-fork improvements that could make p2pkh and multisig more space efficient: ECDSA public key recovery and Schnorr signatures.The deployment of SegWit as a hardfork is supported by some defenders as it would solve scalability problems and make Bitcoin more stable. However, they also support the softfork version of SegWit, which is currently available. The plan is to do a softfork first and then a hardfork to move the witness tree outside of the coinbase. This approach is seen as exciting and believed to accelerate the deployment of SegWit.There is a proposal called "Capacity Increases for the Bitcoin System" that aims to solve scalability issues and make Bitcoin more stable. It suggests implementing a soft-fork SegWit 4MB block, which would increase capacity and scalability. Pieter Wuille supports this plan and believes it will improve productivity and the health of the community.Discussions also took place regarding the impact of segwit-spending inputs on block size. Different scenarios were explored, and optimizations were suggested to prevent abuse. There were also discussions on various topics related to Bitcoin development, including modifications to a struct for forward compatibility and moving the height to a more accessible place.The deployment of Segregated Witness (SegWit) via soft fork or hard fork was debated, with differing opinions on the best approach. Some argued that a hard fork would simplify merge-mining and reduce the size of fraud proofs, while others had concerns about security assumptions for non-upgraded clients. The question of whether the current state of affairs is acceptable to heavy users of the Bitcoin network was also raised.Overall, these discussions focused on the potential benefits and implementation of SegWit in Bitcoin transactions. There were debates on the placement of the segwit merkle root and whether a soft fork or hard fork would be more beneficial. The community continues to work towards finding solutions to scale Bitcoin and increase its capacity.In order to increase scalability and capacity, a proposal has been made to implement a soft-fork to Bitcoin. This proposal involves separating signatures from the main block, which would bypass the current blocksize limit and offer other benefits such as enhanced safety and elimination of signature malleability problems. The implementation of this proposal could lead to a 2x capacity increase and make future capacity expansions safer and more efficient.A working implementation of this proposal can be found at https://github.com/sipa/bitcoin/commits/segwit. Additionally, efforts are being made to develop more efficient block relay techniques that would reduce propagation latency. The author also emphasizes the significance of non-bandwidth scaling mechanisms, such as transaction cut-through and bidirectional payment channels, which utilize smart contracts to increase capacity and speed. These approaches have the potential for high capacity and decentralization.There are other proposals being explored, such as flexible caps or incentive-aligned dynamic block size controls, to maintain the alignment of incentives between miners and node operators. The author also highlights the importance of being prepared to implement moderate block size increases when improvements and understanding make their risks widely acceptable compared to the risks of not deploying them.Overall, the author believes that recent progress has positioned the Bitcoin ecosystem well to address its current capacity needs while setting the stage for further improvement and evolution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Forget-dormant-UTXOs-without-confiscating-bitcoin.xml b/static/bitcoin-dev/Dec_2015/combined_Forget-dormant-UTXOs-without-confiscating-bitcoin.xml index 2eaf801043..9f3e61461a 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Forget-dormant-UTXOs-without-confiscating-bitcoin.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Forget-dormant-UTXOs-without-confiscating-bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Forget dormant UTXOs without confiscating bitcoin - 2023-08-01T17:08:49.139806+00:00 + 2025-10-11T21:43:33.700901+00:00 + python-feedgen Jeff Garzik 2015-12-21 03:34:06+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Forget dormant UTXOs without confiscating bitcoin - 2023-08-01T17:08:49.139806+00:00 + 2025-10-11T21:43:33.701130+00:00 - In a series of discussions on the bitcoin-dev mailing list, various proposals were made to address the handling of dormant unspent transaction outputs (UTXOs) in the Bitcoin network. One proposal suggested adding a consensus-critical maximum UTXO age to the protocol, where UTXOs older than that age could be dropped from the cache but would require proof to spend. Another proposal focused on creating different types of full nodes, including lite UTXO nodes that would only store UTXOs created in the past 420,000 blocks.There were concerns raised about the reversal of the useful minimization attribute of hierarchical deterministic wallets and the status of "grandfathered" UTXOs generated in 2009. It was argued that generating proofs of past transactions could help preserve the "just backup the seed" functionality. However, there were also concerns about the size of membership proofs and the trade-off between bandwidth and storage.Another proposal suggested committing to a hash for all UTXOs generated in a block after 420,000 confirmations. These UTXOs could then be permanently deleted from nodes' records. To redeem a dormant UTXO, users would need to provide additional information such as the scriptPubKey, height, UTXO value, and Merkle path to the dormant UTXO commitment.The discussions also touched on the behavior and cost of the proposed solutions, the role of archive nodes in providing UTXO data, and the challenges of including UTXO data in paper wallets. It was noted that while these proposals aimed to make the system more efficient and avoid storage problems for full nodes, there might be other more efficient proposals with similar goals.Overall, the discussions highlighted the importance of finding a balance between efficiency, security, and user experience in handling dormant UTXOs in the Bitcoin network. The proposals put forth various ideas and considerations to address this issue.In an email conversation between Chris Priest and an unknown recipient, the possibility of sweeping a paper wallet created in 2013 was discussed. The recipient explained that if one has a paper wallet with only a private key, they would need to contact a public index or synchronize the full blockchain history to find out which coins have been assigned to it and their TXids. Running a full node would eliminate the need for synchronization and make one their own archive. However, none of these cases result in a loss of data.The proposed scheme to limit the UTXO set in Bitcoin has faced criticism from some developers. This scheme would require users to contact an "archive node" before making a transaction to obtain the UTXO data, making it more difficult for people to use Bitcoin. Supporters argue that limiting the UTXO size is necessary due to the number of users on the network, but critics point out that the membership proofs required for transactions could become too large. There are differing opinions on whether this scheme would improve or worsen Bitcoin.A thread on the Bitcoin-dev mailing list raised concerns about users losing their unspent transaction outputs (UTXO) due to a change in the Bitcoin protocol. The post clarified that UTXOs would still be spendable but would require a membership proof. Users wouldn't need to store the data themselves as they could obtain it from archive nodes. Another proposal by Peter Todd suggested "STXO commitments," but there are concerns about the potential size of membership proofs. It was suggested that participants in the mailing list should avoid reflexive opposition to moderately complex ideas they don't understand to maintain the utility of the list.The idea of deleting dormant UTXOs in Bitcoin has been discussed to prevent people from forgetting about their mined bitcoins. One suggestion is to set a higher threshold for deletion, such as 80-120 years, to ensure that bitcoins are not lost forever. Alternatively, some propose that dormant UTXOs should re-enter the economy as miner fees, with one dormant UTXO mined per block. This would require a hard fork but could fund cheap transactions indefinitely and incentivize miners to hold copies of dormant UTXOs.In 2015, a proposal was made for archived UTXOs, with retrieval costs borne by the UTXO holder instead of the entire storage network. The proposal suggested that dormant UTXOs be those with 420,000 confirmations, after which they would commit to a hash for all UTXOs generated in the block X-420,000.A proposal has been made to handle dormant UTXOs in Bitcoin. UTXOs with 420,000 confirmations would be considered dormant. In each block after 420,000, a hash would be committed to for all UTXOs generated in block X-420,000. After some confirmations, nodes could safely delete the UTXO records of block X permanently. To redeem a dormant UTXO, users would need to provide scriptPubKey, height (X), and UTXO value as part of the witness, along with the Merkle 2015-12-21T03:34:06+00:00 + In a series of discussions on the bitcoin-dev mailing list, various proposals were made to address the handling of dormant unspent transaction outputs (UTXOs) in the Bitcoin network. One proposal suggested adding a consensus-critical maximum UTXO age to the protocol, where UTXOs older than that age could be dropped from the cache but would require proof to spend. Another proposal focused on creating different types of full nodes, including lite UTXO nodes that would only store UTXOs created in the past 420,000 blocks.There were concerns raised about the reversal of the useful minimization attribute of hierarchical deterministic wallets and the status of "grandfathered" UTXOs generated in 2009. It was argued that generating proofs of past transactions could help preserve the "just backup the seed" functionality. However, there were also concerns about the size of membership proofs and the trade-off between bandwidth and storage.Another proposal suggested committing to a hash for all UTXOs generated in a block after 420,000 confirmations. These UTXOs could then be permanently deleted from nodes' records. To redeem a dormant UTXO, users would need to provide additional information such as the scriptPubKey, height, UTXO value, and Merkle path to the dormant UTXO commitment.The discussions also touched on the behavior and cost of the proposed solutions, the role of archive nodes in providing UTXO data, and the challenges of including UTXO data in paper wallets. It was noted that while these proposals aimed to make the system more efficient and avoid storage problems for full nodes, there might be other more efficient proposals with similar goals.Overall, the discussions highlighted the importance of finding a balance between efficiency, security, and user experience in handling dormant UTXOs in the Bitcoin network. The proposals put forth various ideas and considerations to address this issue.In an email conversation between Chris Priest and an unknown recipient, the possibility of sweeping a paper wallet created in 2013 was discussed. The recipient explained that if one has a paper wallet with only a private key, they would need to contact a public index or synchronize the full blockchain history to find out which coins have been assigned to it and their TXids. Running a full node would eliminate the need for synchronization and make one their own archive. However, none of these cases result in a loss of data.The proposed scheme to limit the UTXO set in Bitcoin has faced criticism from some developers. This scheme would require users to contact an "archive node" before making a transaction to obtain the UTXO data, making it more difficult for people to use Bitcoin. Supporters argue that limiting the UTXO size is necessary due to the number of users on the network, but critics point out that the membership proofs required for transactions could become too large. There are differing opinions on whether this scheme would improve or worsen Bitcoin.A thread on the Bitcoin-dev mailing list raised concerns about users losing their unspent transaction outputs (UTXO) due to a change in the Bitcoin protocol. The post clarified that UTXOs would still be spendable but would require a membership proof. Users wouldn't need to store the data themselves as they could obtain it from archive nodes. Another proposal by Peter Todd suggested "STXO commitments," but there are concerns about the potential size of membership proofs. It was suggested that participants in the mailing list should avoid reflexive opposition to moderately complex ideas they don't understand to maintain the utility of the list.The idea of deleting dormant UTXOs in Bitcoin has been discussed to prevent people from forgetting about their mined bitcoins. One suggestion is to set a higher threshold for deletion, such as 80-120 years, to ensure that bitcoins are not lost forever. Alternatively, some propose that dormant UTXOs should re-enter the economy as miner fees, with one dormant UTXO mined per block. This would require a hard fork but could fund cheap transactions indefinitely and incentivize miners to hold copies of dormant UTXOs.In 2015, a proposal was made for archived UTXOs, with retrieval costs borne by the UTXO holder instead of the entire storage network. The proposal suggested that dormant UTXOs be those with 420,000 confirmations, after which they would commit to a hash for all UTXOs generated in the block X-420,000.A proposal has been made to handle dormant UTXOs in Bitcoin. UTXOs with 420,000 confirmations would be considered dormant. In each block after 420,000, a hash would be committed to for all UTXOs generated in block X-420,000. After some confirmations, nodes could safely delete the UTXO records of block X permanently. To redeem a dormant UTXO, users would need to provide scriptPubKey, height (X), and UTXO value as part of the witness, along with the Merkle - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_How-to-preserve-the-value-of-coins-after-a-fork-.xml b/static/bitcoin-dev/Dec_2015/combined_How-to-preserve-the-value-of-coins-after-a-fork-.xml index 9f8cdae52d..2eae5fb869 100644 --- a/static/bitcoin-dev/Dec_2015/combined_How-to-preserve-the-value-of-coins-after-a-fork-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_How-to-preserve-the-value-of-coins-after-a-fork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - How to preserve the value of coins after a fork. - 2023-08-01T17:21:17.303580+00:00 + 2025-10-11T21:43:25.208677+00:00 + python-feedgen Nick ODell 2015-12-30 23:13:56+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - How to preserve the value of coins after a fork. - 2023-08-01T17:21:17.303580+00:00 + 2025-10-11T21:43:25.208819+00:00 - In a conversation between Emin Gün Sirer and Peter Todd, several technical and economic criticisms of Emin's proposal for Bitcoin-United were discussed. One technical criticism was that unified miners would mine transactions on Dum first and then on Dee, which contradicted the claim that users could use Dee natively without paying fees to get a transaction into Dum. Another technical criticism raised concerns about the vulnerability of Dum if another group launched a false-flag attack against Dee. The economic criticism centered around the difficulty of reaching a compromise if there was a difference in market cap value between the chains.Peter Todd also noted that most multisig transactions are hidden behind p2sh, making it difficult to determine what keys are involved. However, he acknowledged that Bitcoin-United relies on a notion of transaction equivalence that should be immune to malleability issues and compatible with segwit. He suggested simpler and more predictable solutions for achieving consensus, such as proof of stake voting or Adam Bank's extension blocks suggestions. Overall, Peter Todd concluded that the proposal was not a good idea and that any Bitcoin United scheme would quickly diverge and fail.In the email conversation, Emin Gün Sirer discussed the notion of transaction equivalence and its susceptibility to malleability issues in Bitcoin-United. The system considers transactions equal if they consume the same inputs and result in the same outputs, regardless of miner fees. Multikey transactions are evaluated based on their inputs and outputs, allowing different sets of two keys to sign a 2-out-of-3 payment on Dum and Dee. However, Peter Todd highlighted the challenge of determining the keys involved in multisig transactions hidden behind p2sh. He suggested exploring segwit transactions, which offer a better notion of non-malleable transactions. Despite these considerations, the susceptibility to divergence and failure due to malleability issues casts doubt on the success of Bitcoin United. Simpler and more predictable solutions like proof of stake voting or Adam Bank's extension blocks may be more viable for achieving consensus.Ittay Eyal and Emin Gün Sirer introduced the technique of Bitcoin-United as a means to unite bitcoin factions following a fork. The technique aims to eliminate double-spends by transferring transactions from one chain to another and considering the intersection of transactions on both chains. Minting new coins and collecting mining fees on both chains while preserving the 21M maximum is proposed through a one-to-one correspondence between coins. This technique allows for the creation of a cohesive coin even if the core developers are split or if one fork is non-cooperative. However, questions arise regarding the preferences of native clients for one chain over the other and the impact on the value of native-A or native-B coins. The authors are actively addressing these questions but shared the Bitcoin-United idea with the community to gather feedback and offer hope for future consensus. 2015-12-30T23:13:56+00:00 + In a conversation between Emin Gün Sirer and Peter Todd, several technical and economic criticisms of Emin's proposal for Bitcoin-United were discussed. One technical criticism was that unified miners would mine transactions on Dum first and then on Dee, which contradicted the claim that users could use Dee natively without paying fees to get a transaction into Dum. Another technical criticism raised concerns about the vulnerability of Dum if another group launched a false-flag attack against Dee. The economic criticism centered around the difficulty of reaching a compromise if there was a difference in market cap value between the chains.Peter Todd also noted that most multisig transactions are hidden behind p2sh, making it difficult to determine what keys are involved. However, he acknowledged that Bitcoin-United relies on a notion of transaction equivalence that should be immune to malleability issues and compatible with segwit. He suggested simpler and more predictable solutions for achieving consensus, such as proof of stake voting or Adam Bank's extension blocks suggestions. Overall, Peter Todd concluded that the proposal was not a good idea and that any Bitcoin United scheme would quickly diverge and fail.In the email conversation, Emin Gün Sirer discussed the notion of transaction equivalence and its susceptibility to malleability issues in Bitcoin-United. The system considers transactions equal if they consume the same inputs and result in the same outputs, regardless of miner fees. Multikey transactions are evaluated based on their inputs and outputs, allowing different sets of two keys to sign a 2-out-of-3 payment on Dum and Dee. However, Peter Todd highlighted the challenge of determining the keys involved in multisig transactions hidden behind p2sh. He suggested exploring segwit transactions, which offer a better notion of non-malleable transactions. Despite these considerations, the susceptibility to divergence and failure due to malleability issues casts doubt on the success of Bitcoin United. Simpler and more predictable solutions like proof of stake voting or Adam Bank's extension blocks may be more viable for achieving consensus.Ittay Eyal and Emin Gün Sirer introduced the technique of Bitcoin-United as a means to unite bitcoin factions following a fork. The technique aims to eliminate double-spends by transferring transactions from one chain to another and considering the intersection of transactions on both chains. Minting new coins and collecting mining fees on both chains while preserving the 21M maximum is proposed through a one-to-one correspondence between coins. This technique allows for the creation of a cohesive coin even if the core developers are split or if one fork is non-cooperative. However, questions arise regarding the preferences of native clients for one chain over the other and the impact on the value of native-A or native-B coins. The authors are actively addressing these questions but shared the Bitcoin-United idea with the community to gather feedback and offer hope for future consensus. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml b/static/bitcoin-dev/Dec_2015/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml index e5abd22c8a..1d76ec8e8a 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Increasing the blocksize as a (generalized) softfork. - 2023-08-01T17:15:37.711773+00:00 + 2025-10-11T21:43:29.453033+00:00 + python-feedgen Luke Dashjr 2016-01-04 21:53:36+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Increasing the blocksize as a (generalized) softfork. - 2023-08-01T17:15:37.713836+00:00 + 2025-10-11T21:43:29.453187+00:00 - The email thread discussed the proposal of using a generalized softfork as an alternative to hard forks. Joe2015 proposed the idea, challenging the assumption that increasing the blocksize limit requires a hardfork. He introduced the concept of standard softforks, where after the fork, two potential chains exist - one valid under the new rules and old rules, and one valid under the old rules only. However, if more than 50% of the hashpower follows the new rules, the old chain is destined to be orphaned.Joe2015 then introduced the idea of a generalized softfork, which involves a transform function f(B)=B' that maps a block valid under the new rules to a block valid under the old rules. In this scenario, three chains may exist - the new chain valid under the new rules only, the mapped chain f(B3), f(B4), f(B5), and the old chain B3', B4', B5', valid under the old rules only. The Segregated Witness was given as an example of a generalized softfork, where the new block format combines the old block and witness data, and the function f() simply removes the witness data to create a valid block under the old rules.The paper then explained how to achieve arbitrary block-size increases through a generalized softfork. This proposal consisted of defining new rules for valid blocks and a transformation function f(). The new block rules were similar to the old rules but with some small changes. The function f() truncated the block so that it contained only the coinbase transaction. By combining these new rules and the transformation function, a generalized softfork could be implemented. This resulted in a new chain under the new rules, including an increased blocksize limit, which could be mapped to a valid chain under the old rules.It was noted that since all mapped blocks were empty, old clients would never see transactions confirming. The paper concluded by highlighting that increasing the blocksize limit is commonly believed to require a hardfork, but this draft demonstrated that it could be achieved using a generalized softfork. The author suggested further exploration of other types of hardforks that can be implemented as generalized softforks and the security implications that come with them. 2016-01-04T21:53:36+00:00 + The email thread discussed the proposal of using a generalized softfork as an alternative to hard forks. Joe2015 proposed the idea, challenging the assumption that increasing the blocksize limit requires a hardfork. He introduced the concept of standard softforks, where after the fork, two potential chains exist - one valid under the new rules and old rules, and one valid under the old rules only. However, if more than 50% of the hashpower follows the new rules, the old chain is destined to be orphaned.Joe2015 then introduced the idea of a generalized softfork, which involves a transform function f(B)=B' that maps a block valid under the new rules to a block valid under the old rules. In this scenario, three chains may exist - the new chain valid under the new rules only, the mapped chain f(B3), f(B4), f(B5), and the old chain B3', B4', B5', valid under the old rules only. The Segregated Witness was given as an example of a generalized softfork, where the new block format combines the old block and witness data, and the function f() simply removes the witness data to create a valid block under the old rules.The paper then explained how to achieve arbitrary block-size increases through a generalized softfork. This proposal consisted of defining new rules for valid blocks and a transformation function f(). The new block rules were similar to the old rules but with some small changes. The function f() truncated the block so that it contained only the coinbase transaction. By combining these new rules and the transformation function, a generalized softfork could be implemented. This resulted in a new chain under the new rules, including an increased blocksize limit, which could be mapped to a valid chain under the old rules.It was noted that since all mapped blocks were empty, old clients would never see transactions confirming. The paper concluded by highlighting that increasing the blocksize limit is commonly believed to require a hardfork, but this draft demonstrated that it could be achieved using a generalized softfork. The author suggested further exploration of other types of hardforks that can be implemented as generalized softforks and the security implications that come with them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_On-the-security-of-softforks.xml b/static/bitcoin-dev/Dec_2015/combined_On-the-security-of-softforks.xml index ad395bf35a..98f6036b6c 100644 --- a/static/bitcoin-dev/Dec_2015/combined_On-the-security-of-softforks.xml +++ b/static/bitcoin-dev/Dec_2015/combined_On-the-security-of-softforks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On the security of softforks - 2023-08-01T17:11:58.682448+00:00 + 2025-10-11T21:43:01.831964+00:00 + python-feedgen jl2012 2015-12-20 19:16:29+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - On the security of softforks - 2023-08-01T17:11:58.682448+00:00 + 2025-10-11T21:43:01.832144+00:00 - In a discussion on the Bitcoin developers' forum, concerns were raised about the risk of old full node wallets accepting invalid transactions according to new rules. It was argued that this risk is not significant as the receiver wallet selects what address/script to accept coins on and will upgrade to the new rules before creating an address dependent on the softfork's features. However, a scenario was presented where Mallory defrauds Bob with an invalid SegWit transaction, exploiting the fact that Bob's wallet would be looking for a specific scriptSig. It was concluded that waiting for confirmations can mitigate this issue.The discussion also touched upon the topic of misinformation and lies being circulated regarding consensus rule changes. It was suggested that such discussions should be written up as BIPs (Bitcoin Improvement Proposals) to address the misinformation. The content of the discussed BIP was not mentioned.Another discussion highlighted the potential risks associated with non-upgraded nodes accepting invalid confirmations in the case of a consensus rule change. It was noted that if a large majority of hashing power supports the new rule, the number of invalid confirmations seen by non-upgraded nodes would be minimal. However, it was emphasized that caution should be exercised when dealing with low confirmation counts and that upgrading software regularly is necessary for security.A hypothetical scenario involving Mallory defrauding Bob with an invalid SegWit transaction was discussed, emphasizing the vulnerabilities of non-upgraded nodes. The importance of upgrading mining nodes and the risks associated with unconfirmed transactions were also highlighted.The author questioned the distinction between softforks and hardforks, suggesting that softforks should have a minimum median time deployment day rather than relying on header.nTime. The discussion also addressed potential fraud scenarios involving SegWit transactions, including one where Mallory defrauds Bob. It was mentioned that 0-conf and 1-conf transactions are not safe and that the scenario described is a variation of the Finney attack.The security of softforks in Bitcoin was a central theme throughout the discussions. Different failure modes and associated risks were analyzed, highlighting the potential vulnerabilities and advantages of soft forks. The importance of full node validation, upgrading software regularly, and caution with unconfirmed transactions were emphasized. 2015-12-20T19:16:29+00:00 + In a discussion on the Bitcoin developers' forum, concerns were raised about the risk of old full node wallets accepting invalid transactions according to new rules. It was argued that this risk is not significant as the receiver wallet selects what address/script to accept coins on and will upgrade to the new rules before creating an address dependent on the softfork's features. However, a scenario was presented where Mallory defrauds Bob with an invalid SegWit transaction, exploiting the fact that Bob's wallet would be looking for a specific scriptSig. It was concluded that waiting for confirmations can mitigate this issue.The discussion also touched upon the topic of misinformation and lies being circulated regarding consensus rule changes. It was suggested that such discussions should be written up as BIPs (Bitcoin Improvement Proposals) to address the misinformation. The content of the discussed BIP was not mentioned.Another discussion highlighted the potential risks associated with non-upgraded nodes accepting invalid confirmations in the case of a consensus rule change. It was noted that if a large majority of hashing power supports the new rule, the number of invalid confirmations seen by non-upgraded nodes would be minimal. However, it was emphasized that caution should be exercised when dealing with low confirmation counts and that upgrading software regularly is necessary for security.A hypothetical scenario involving Mallory defrauding Bob with an invalid SegWit transaction was discussed, emphasizing the vulnerabilities of non-upgraded nodes. The importance of upgrading mining nodes and the risks associated with unconfirmed transactions were also highlighted.The author questioned the distinction between softforks and hardforks, suggesting that softforks should have a minimum median time deployment day rather than relying on header.nTime. The discussion also addressed potential fraud scenarios involving SegWit transactions, including one where Mallory defrauds Bob. It was mentioned that 0-conf and 1-conf transactions are not safe and that the scenario described is a variation of the Finney attack.The security of softforks in Bitcoin was a central theme throughout the discussions. Different failure modes and associated risks were analyzed, highlighting the potential vulnerabilities and advantages of soft forks. The importance of full node validation, upgrading software regularly, and caution with unconfirmed transactions were emphasized. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml b/static/bitcoin-dev/Dec_2015/combined_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml index 86148e706a..ce0d3a1048 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Opt-in Full Replace-By-Fee (Full-RBF) - 2023-08-01T16:53:18.576992+00:00 + 2025-10-11T21:42:44.841910+00:00 + python-feedgen Peter Todd 2015-12-02 09:27:39+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Opt-in Full Replace-By-Fee (Full-RBF) - 2023-08-01T16:53:18.576992+00:00 + 2025-10-11T21:42:44.842106+00:00 - A discussion on the Bitcoin-dev mailing list occurred regarding the use of Sequence for opting in. The CTxOut data structure lacks additional fields for this purpose. One suggestion was to utilize the same scheme as sighash_single, but it raises privacy concerns by exposing change address information. Another proposed option involves pre-committing via a hash and revealing it later, but this approach is complex and not easily feasible with the current transaction data structure.On November 16th, 2015, Peter Todd posted a message on bitcoin-dev discussing the use of Sequence for opting in. He pointed out that it is the only "free-form" field available for this purpose. Luke-Jr proposed opt-in per output, but the CTxOut data structure does not have extra fields for such usage. The message also mentioned questioning the use of the same scheme as sighash_single and suggested considering if input 0 has nSequence... (the rest of the sentence is not provided).Bitcoin Core developers have decided to merge the opt-in Full-RBF pull request. This new feature will enable senders to opt into full-RBF semantics for their transactions, allowing receivers to detect if the sender has done so. Transactions that do not opt-in will still retain the existing "first-seen" mempool semantics. Pending code review, this feature is expected to be included in Bitcoin Core v0.12.0. A transaction is considered to have opted into full-RBF semantics if nSequence < (2^32 - 2), indicating the possibility of the sender reissuing the transaction with a higher fee.The initial version of Replace-by-Fee (RBF) raised controversy due to concerns about double-spending. However, opt-in Full-RBF addresses these concerns by enabling receivers to differentiate between opt-in and non-opt-in transactions. The creation of the opt-in Full-RBF pull request was in response to user feedback, with users desiring more control over the fees paid for transactions. This feature allows users to increase the fee on a transaction that is taking longer than expected to confirm, without worrying about rejection by nodes that do not support RBF.Overall, the opt-in Full-RBF feature offers users greater flexibility and control over their transactions. It also addresses security concerns associated with the original RBF implementation. 2015-12-02T09:27:39+00:00 + A discussion on the Bitcoin-dev mailing list occurred regarding the use of Sequence for opting in. The CTxOut data structure lacks additional fields for this purpose. One suggestion was to utilize the same scheme as sighash_single, but it raises privacy concerns by exposing change address information. Another proposed option involves pre-committing via a hash and revealing it later, but this approach is complex and not easily feasible with the current transaction data structure.On November 16th, 2015, Peter Todd posted a message on bitcoin-dev discussing the use of Sequence for opting in. He pointed out that it is the only "free-form" field available for this purpose. Luke-Jr proposed opt-in per output, but the CTxOut data structure does not have extra fields for such usage. The message also mentioned questioning the use of the same scheme as sighash_single and suggested considering if input 0 has nSequence... (the rest of the sentence is not provided).Bitcoin Core developers have decided to merge the opt-in Full-RBF pull request. This new feature will enable senders to opt into full-RBF semantics for their transactions, allowing receivers to detect if the sender has done so. Transactions that do not opt-in will still retain the existing "first-seen" mempool semantics. Pending code review, this feature is expected to be included in Bitcoin Core v0.12.0. A transaction is considered to have opted into full-RBF semantics if nSequence < (2^32 - 2), indicating the possibility of the sender reissuing the transaction with a higher fee.The initial version of Replace-by-Fee (RBF) raised controversy due to concerns about double-spending. However, opt-in Full-RBF addresses these concerns by enabling receivers to differentiate between opt-in and non-opt-in transactions. The creation of the opt-in Full-RBF pull request was in response to user feedback, with users desiring more control over the fees paid for transactions. This feature allows users to increase the fee on a transaction that is taking longer than expected to confirm, without worrying about rejection by nodes that do not support RBF.Overall, the opt-in Full-RBF feature offers users greater flexibility and control over their transactions. It also addresses security concerns associated with the original RBF implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Scaling-by-Partitioning.xml b/static/bitcoin-dev/Dec_2015/combined_Scaling-by-Partitioning.xml index e430abd759..0768ecb005 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Scaling-by-Partitioning.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Scaling-by-Partitioning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Scaling by Partitioning - 2023-08-01T17:05:55.811394+00:00 + 2025-10-11T21:43:03.957056+00:00 + python-feedgen Bryan Bishop 2015-12-10 04:31:42+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Scaling by Partitioning - 2023-08-01T17:05:55.811394+00:00 + 2025-10-11T21:43:03.957236+00:00 - Akiva Lichtner, a developer with 20 years of experience in the payment industry, has proposed an idea for scaling Bitcoin. The proposal involves running multiple simultaneous chains, with each chain defeating double spending on only part of the coin. The coin would be partitioned by radix or modulus, and blocks would contain the number of the partition they belong to. Miners would round-robin through partitions to prevent any unfair advantage for attackers.The number of chains could increase automatically based on transaction volume. Payment recipients would need to operate a daemon for each chain, ensuring no scaling advantage. However, some believe this partitioning could be a showstopper for the idea. Akiva also discusses the potential for sharding coins and acknowledges that his proposal is not exactly scaling Bitcoin's present requirements, but rather relaxing the requirements in a way that satisfies both users and miners.In response to Akiva's proposal, Loi Luu questions the efficiency of this approach and suggests their SCP (Simple Coin-Pair) protocol as an alternative. Luu believes that sharding should localize the bandwidth used and only broadcast minimal data. However, Akiva Lichtner responds by stating that since partitions are completely segregated, there is no need for a node to work on multiple partitions simultaneously. He argues that as long as a node can work on multiple partitions in turn, attacks can still be defeated.Overall, Akiva Lichtner's proposal suggests running more than one simultaneous chain in order to scale Bitcoin. Each chain would tackle double spending on only part of the coin, with the coin being partitioned by radix or modulus. The number of chains could automatically increase based on transaction volume. However, Loi Luu questions the efficiency of this approach and suggests their SCP protocol as an alternative. Despite the differing opinions, the discussion highlights the ongoing efforts to address scalability issues in Bitcoin and the importance of considering trade-offs between decentralization and efficiency.The email exchange also touches on the concept of offloading work to clients and the linearized coin history idea. Overall, Akiva seeks expert feedback on his idea and shares a humorous anagram for Satoshi Nakamoto. 2015-12-10T04:31:42+00:00 + Akiva Lichtner, a developer with 20 years of experience in the payment industry, has proposed an idea for scaling Bitcoin. The proposal involves running multiple simultaneous chains, with each chain defeating double spending on only part of the coin. The coin would be partitioned by radix or modulus, and blocks would contain the number of the partition they belong to. Miners would round-robin through partitions to prevent any unfair advantage for attackers.The number of chains could increase automatically based on transaction volume. Payment recipients would need to operate a daemon for each chain, ensuring no scaling advantage. However, some believe this partitioning could be a showstopper for the idea. Akiva also discusses the potential for sharding coins and acknowledges that his proposal is not exactly scaling Bitcoin's present requirements, but rather relaxing the requirements in a way that satisfies both users and miners.In response to Akiva's proposal, Loi Luu questions the efficiency of this approach and suggests their SCP (Simple Coin-Pair) protocol as an alternative. Luu believes that sharding should localize the bandwidth used and only broadcast minimal data. However, Akiva Lichtner responds by stating that since partitions are completely segregated, there is no need for a node to work on multiple partitions simultaneously. He argues that as long as a node can work on multiple partitions in turn, attacks can still be defeated.Overall, Akiva Lichtner's proposal suggests running more than one simultaneous chain in order to scale Bitcoin. Each chain would tackle double spending on only part of the coin, with the coin being partitioned by radix or modulus. The number of chains could automatically increase based on transaction volume. However, Loi Luu questions the efficiency of this approach and suggests their SCP protocol as an alternative. Despite the differing opinions, the discussion highlights the ongoing efforts to address scalability issues in Bitcoin and the importance of considering trade-offs between decentralization and efficiency.The email exchange also touches on the concept of offloading work to clients and the linearized coin history idea. Overall, Akiva seeks expert feedback on his idea and shares a humorous anagram for Satoshi Nakamoto. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-BIPs.xml b/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-BIPs.xml index 620e06736e..85f3be4c04 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-BIPs.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-BIPs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segregated Witness BIPs - 2023-08-01T17:18:20.571872+00:00 + 2025-10-11T21:42:51.216318+00:00 + python-feedgen jl2012 2016-01-05 05:43:41+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Segregated Witness BIPs - 2023-08-01T17:18:20.571872+00:00 + 2025-10-11T21:42:51.216490+00:00 - The Bitcoin Improvement Proposal (BIP) process allows for changes to be suggested and implemented in the Bitcoin protocol. A new BIP has been proposed as part of the Segregated Witness (SegWit) soft fork, specifically addressing a new transaction digest algorithm for signature verification. The goal of this proposal is to minimize redundant data hashing and cover the input value by the signature.In addition to this proposal, a new BIP draft for a SW payment address format has been prepared and is awaiting BIP number assignment. This is the third BIP for SegWit, with another one being prepared by Eric Lombrozo for Peer Services. Eric Lombrozo and jl2012 have been working on these BIPs based on earlier discussions from Pieter Wuille's implementation.There are three separate BIPs being considered: Consensus BIP, Peer Services BIP, and Applications BIP. The Consensus BIP has already been submitted as a draft and covers witness structures, cost metrics and limits, scripting system (witness programs), and the soft fork mechanism. On the other hand, the Peer Services BIP will focus on relay message structures, witnesstx serialization, and other issues related to the p2p protocol such as IBD, synchronization, tx and block propagation. Lastly, the Applications BIP will address scriptPubKey encoding formats and other concerns regarding wallet interoperability.Overall, the development team is actively working on multiple BIPs related to the SegWit implementation, aiming to improve various aspects of the Bitcoin protocol. 2016-01-05T05:43:41+00:00 + The Bitcoin Improvement Proposal (BIP) process allows for changes to be suggested and implemented in the Bitcoin protocol. A new BIP has been proposed as part of the Segregated Witness (SegWit) soft fork, specifically addressing a new transaction digest algorithm for signature verification. The goal of this proposal is to minimize redundant data hashing and cover the input value by the signature.In addition to this proposal, a new BIP draft for a SW payment address format has been prepared and is awaiting BIP number assignment. This is the third BIP for SegWit, with another one being prepared by Eric Lombrozo for Peer Services. Eric Lombrozo and jl2012 have been working on these BIPs based on earlier discussions from Pieter Wuille's implementation.There are three separate BIPs being considered: Consensus BIP, Peer Services BIP, and Applications BIP. The Consensus BIP has already been submitted as a draft and covers witness structures, cost metrics and limits, scripting system (witness programs), and the soft fork mechanism. On the other hand, the Peer Services BIP will focus on relay message structures, witnesstx serialization, and other issues related to the p2p protocol such as IBD, synchronization, tx and block propagation. Lastly, the Applications BIP will address scriptPubKey encoding formats and other concerns regarding wallet interoperability.Overall, the development team is actively working on multiple BIPs related to the SegWit implementation, aiming to improve various aspects of the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-features-wish-list.xml b/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-features-wish-list.xml index 03d5bfd3bf..e67e6ec196 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-features-wish-list.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-features-wish-list.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segregated Witness features wish list - 2023-08-01T17:07:20.644244+00:00 + 2025-10-11T21:42:53.339781+00:00 + python-feedgen Jonathan Toomim 2015-12-14 12:50:51+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Segregated Witness features wish list - 2023-08-01T17:07:20.644244+00:00 + 2025-10-11T21:42:53.339994+00:00 - In the context of protocol changes, the implementation of Segregated Witness (SW) presents various opportunities to improve Bitcoin. However, it is crucial to prioritize scalability and safety when considering these changes. This means that while SW can bring about positive changes, it is essential to ensure that these changes do not compromise the system's ability to handle increased demands or compromise its overall safety.Achieving scalability and safety must take precedence over other potential benefits offered by SW. Scalability refers to the system's ability to adapt and accommodate increased demands without experiencing significant performance issues or failures. It is vital in ensuring that the system remains efficient and effective even as the user base or workload grows. Therefore, any protocol changes introduced through SW should aim to enhance the system's scalability.Another critical aspect that needs to be considered is safety. The safety of the system refers to its ability to protect data, prevent unauthorized access, and mitigate potential risks or vulnerabilities. With the increasing reliance on technology, ensuring the safety of systems has become paramount. Therefore, when implementing SW, it is essential to prioritize safety measures to safeguard sensitive information and maintain the integrity of the system.While SW may offer several opportunities for improvement, it is important to note that prioritizing scalability and safety should be the primary focus. By doing so, organizations can ensure that any protocol changes introduced through SW are sustainable, efficient, and secure. Taking a cautious approach towards SW implementation will help maximize the benefits while minimizing the risks associated with protocol changes. 2015-12-14T12:50:51+00:00 + In the context of protocol changes, the implementation of Segregated Witness (SW) presents various opportunities to improve Bitcoin. However, it is crucial to prioritize scalability and safety when considering these changes. This means that while SW can bring about positive changes, it is essential to ensure that these changes do not compromise the system's ability to handle increased demands or compromise its overall safety.Achieving scalability and safety must take precedence over other potential benefits offered by SW. Scalability refers to the system's ability to adapt and accommodate increased demands without experiencing significant performance issues or failures. It is vital in ensuring that the system remains efficient and effective even as the user base or workload grows. Therefore, any protocol changes introduced through SW should aim to enhance the system's scalability.Another critical aspect that needs to be considered is safety. The safety of the system refers to its ability to protect data, prevent unauthorized access, and mitigate potential risks or vulnerabilities. With the increasing reliance on technology, ensuring the safety of systems has become paramount. Therefore, when implementing SW, it is essential to prioritize safety measures to safeguard sensitive information and maintain the integrity of the system.While SW may offer several opportunities for improvement, it is important to note that prioritizing scalability and safety should be the primary focus. By doing so, organizations can ensure that any protocol changes introduced through SW are sustainable, efficient, and secure. Taking a cautious approach towards SW implementation will help maximize the benefits while minimizing the risks associated with protocol changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-in-the-context-of-Scaling-Bitcoin.xml b/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-in-the-context-of-Scaling-Bitcoin.xml index d4630b1a9b..fec614ac60 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-in-the-context-of-Scaling-Bitcoin.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Segregated-Witness-in-the-context-of-Scaling-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segregated Witness in the context of Scaling Bitcoin - 2023-08-01T17:11:38.617774+00:00 + 2025-10-11T21:43:06.080269+00:00 + python-feedgen Dave Scotese 2015-12-19 23:03:20+00:00 @@ -123,13 +124,13 @@ - python-feedgen + 2 Combined summary - Segregated Witness in the context of Scaling Bitcoin - 2023-08-01T17:11:38.617774+00:00 + 2025-10-11T21:43:06.080500+00:00 - The Bitcoin community is currently engaged in a debate over whether to implement Segregated Witness (SegWit) as a soft fork or pursue a hard fork block size increase. The primary proposal suggests a combination of fast BIP102 and slow SegWit, allowing for the evaluation of each implementation separately. The secondary proposal involves implementing fast SegWit alone. The discussion considers the potential gains in block size from these proposals and delves into technical details about block size limits and expected benefits.There is disagreement within the community about the deployment timeline of SegWit versus a hard fork. While some argue that SegWit will take longer to implement, others believe it can be deployed quickly once the code is ready. Concerns are raised about the slow rollout pace and complexity of SegWit, which creates two fee markets and introduces new attack surfaces. The economic and ecosystem risks associated with each proposal are also discussed, with evidence suggesting that a five-month pre-announcement is sufficient for a hard fork. However, it is noted that SegWit may not provide short-term scaling and a hard fork block size increase may better address these risks.In an email conversation, Jeff Garzik discusses the nature of Segregated Witness (SW) service, noting that it presents a blended price and basket of two goods. However, further details about these resources are not provided. The conversation focuses on SW as a solution to scaling Bitcoin and highlights its ability to address malleability issues. It is noted that SW creates two views of transactions and blocks, with newer clients seeing extended blocks while older clients see standard 1MB blocks. The roll-out pace for SW is expected to be slow due to the need for upgrades in wallet software and programmer libraries.A simple hard fork like BIP102 is considered automatically compatible with most ecosystem software, but concerns are raised about the economic complexities introduced by SW, such as creating two fee markets. SW is seen as unlikely to provide short-term scaling and poses risks related to economic policy and bidding structure. A "short term bump" hard fork block size increase is seen as addressing the risks that SW does not.The email exchange also discusses the proposed miner selection algorithm for block size increases, with Jeff Garzik mentioning that SW complicates block economics with two separate supply-limited resources. Pieter Wuille proposes defining the virtual block size to optimize fee per virtual block size. The importance of upgrading bitcoin-core and bitcoinj layers is emphasized, and it is noted that adopting SW is easier compared to a hard fork. Economic policy, game theory, bidding structure risks, and the need for improvement in the SW mining algorithm are also discussed.In conclusion, Segregated Witness (SegWit) is viewed as a solution with useful attributes but not a complete scaling solution. The discussion suggests proceeding with a "short term bump" hard fork block size increase alongside SegWit as independent tracks to address certain risks and ensure the security and scalability of the Bitcoin network. 2015-12-19T23:03:20+00:00 + The Bitcoin community is currently engaged in a debate over whether to implement Segregated Witness (SegWit) as a soft fork or pursue a hard fork block size increase. The primary proposal suggests a combination of fast BIP102 and slow SegWit, allowing for the evaluation of each implementation separately. The secondary proposal involves implementing fast SegWit alone. The discussion considers the potential gains in block size from these proposals and delves into technical details about block size limits and expected benefits.There is disagreement within the community about the deployment timeline of SegWit versus a hard fork. While some argue that SegWit will take longer to implement, others believe it can be deployed quickly once the code is ready. Concerns are raised about the slow rollout pace and complexity of SegWit, which creates two fee markets and introduces new attack surfaces. The economic and ecosystem risks associated with each proposal are also discussed, with evidence suggesting that a five-month pre-announcement is sufficient for a hard fork. However, it is noted that SegWit may not provide short-term scaling and a hard fork block size increase may better address these risks.In an email conversation, Jeff Garzik discusses the nature of Segregated Witness (SW) service, noting that it presents a blended price and basket of two goods. However, further details about these resources are not provided. The conversation focuses on SW as a solution to scaling Bitcoin and highlights its ability to address malleability issues. It is noted that SW creates two views of transactions and blocks, with newer clients seeing extended blocks while older clients see standard 1MB blocks. The roll-out pace for SW is expected to be slow due to the need for upgrades in wallet software and programmer libraries.A simple hard fork like BIP102 is considered automatically compatible with most ecosystem software, but concerns are raised about the economic complexities introduced by SW, such as creating two fee markets. SW is seen as unlikely to provide short-term scaling and poses risks related to economic policy and bidding structure. A "short term bump" hard fork block size increase is seen as addressing the risks that SW does not.The email exchange also discusses the proposed miner selection algorithm for block size increases, with Jeff Garzik mentioning that SW complicates block economics with two separate supply-limited resources. Pieter Wuille proposes defining the virtual block size to optimize fee per virtual block size. The importance of upgrading bitcoin-core and bitcoinj layers is emphasized, and it is noted that adopting SW is easier compared to a hard fork. Economic policy, game theory, bidding structure risks, and the need for improvement in the SW mining algorithm are also discussed.In conclusion, Segregated Witness (SegWit) is viewed as a solution with useful attributes but not a complete scaling solution. The discussion suggests proceeding with a "short term bump" hard fork block size increase alongside SegWit as independent tracks to address certain risks and ensure the security and scalability of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Segregated-witness-softfork-with-moderate-adoption-has-very-small-block-size-effect.xml b/static/bitcoin-dev/Dec_2015/combined_Segregated-witness-softfork-with-moderate-adoption-has-very-small-block-size-effect.xml index a9d14e7557..f07546ed61 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Segregated-witness-softfork-with-moderate-adoption-has-very-small-block-size-effect.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Segregated-witness-softfork-with-moderate-adoption-has-very-small-block-size-effect.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segregated witness softfork with moderate adoption has very small block size effect - 2023-08-01T17:13:01.547714+00:00 + 2025-10-11T21:43:23.084549+00:00 + python-feedgen Chris Priest 2015-12-20 03:37:26+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Segregated witness softfork with moderate adoption has very small block size effect - 2023-08-01T17:13:01.547714+00:00 + 2025-10-11T21:43:23.084713+00:00 - In a discussion on the Bitcoin-dev mailing list, Peter Todd highlights how the implementation of Pay-to-Script-Hash (P2SH) in wallets can be seen as a vote for an increased block size. This is because P2SH leads to smaller transactions, similar to Segregated Witness (SW). However, Todd acknowledges that SW's client-side adoption may not be as effective as a direct proof-of-stake vote and can be viewed as coercive due to lower fees being paid.Another participant, Douglas Roark, responds to concerns about the adoption rate of SW by stating that P2SH and SegWit uptake should not be conflated. Roark believes that wallet developers will recognize the value of SegWit and enable it by default, leading to widespread adoption. While optimistic about aggressive timeframes, Roark expects more conservative adoption rates. He also suggests that a 40% adoption rate within a year of deployment is possible.Santino Napolitano disagrees with the notion that client-side adoption of SW indicates a preference for larger blocks. They propose alternative methods such as attaching OP_RETURN outputs or providing hand-signed letters to explicitly state business preferences. Napolitano raises concerns about English-language measures being misleading and the significant economic activity in non-Western countries. Centralized forums like Twitter and Reddit are also seen as easily censored and manipulated. Peter Todd adds an anecdote about a Bitcoin-related product that had majority sales in non-English-speaking countries, emphasizing the need for inclusivity in consensus-building processes.In response to jl2012's calculations on the effect of a SW softfork on the total block size, Peter Todd argues that client-side adoption of SW demonstrates the ecosystem's acceptance of a blocksize increase. Another user counters by stating that SW adoption merely indicates implementers seeing greater value in it than the cost of implementation, not necessarily a preference for larger blocks. They suggest alternative ways for businesses to express their desires. Todd acknowledges that SW adoption is not as effective as a direct proof-of-stake vote but finds it to be an interesting side-effect.Another user on the mailing list expresses doubt about SW being the sole short-term solution for scalability. They believe fraud-proof systems are crucial for network security, suggesting the addition of fraud proofs to blocks to make features like committed UTXO sets less risky. While recognizing the value of solving transaction malleability, their main concern is buying time for continued usage growth while working towards eliminating the maximum block size as a consensus rule.On December 19, 2015, jl2012 calculates the effect of a SW softfork on the actual total block size. Client-side adoption is necessary for an actual blocksize increase, which can be seen as a positive sign that the ecosystem has embraced larger blocks. Although this method is not as ideal as a direct proof-of-stake vote and has some coercive elements due to lower fees, it is an intriguing side-effect.The author of the text conducts calculations on the effect of a SW softfork on the total block size. They define various terms and propose a discount factor for witness size. They present a table showing the maximum total block size based on different variables. However, they note that P2SH has only been in use for 3.5 years and accounts for only 10% of Bitcoin storage, making a 40% adoption rate for SegWit within a year over-optimistic unless transaction fees significantly increase. The author also questions whether SW should be the exclusive short-term solution for scalability.Overall, the discussions on the Bitcoin-dev mailing list touch upon the implementation and adoption rates of Pay-to-Script-Hash (P2SH) and Segregated Witness (SW), the relationship between client-side adoption and block size preferences, alternative methods for expressing desires in the Bitcoin ecosystem, concerns about scalability solutions, and calculations on the impact of SW on the total block size. 2015-12-20T03:37:26+00:00 + In a discussion on the Bitcoin-dev mailing list, Peter Todd highlights how the implementation of Pay-to-Script-Hash (P2SH) in wallets can be seen as a vote for an increased block size. This is because P2SH leads to smaller transactions, similar to Segregated Witness (SW). However, Todd acknowledges that SW's client-side adoption may not be as effective as a direct proof-of-stake vote and can be viewed as coercive due to lower fees being paid.Another participant, Douglas Roark, responds to concerns about the adoption rate of SW by stating that P2SH and SegWit uptake should not be conflated. Roark believes that wallet developers will recognize the value of SegWit and enable it by default, leading to widespread adoption. While optimistic about aggressive timeframes, Roark expects more conservative adoption rates. He also suggests that a 40% adoption rate within a year of deployment is possible.Santino Napolitano disagrees with the notion that client-side adoption of SW indicates a preference for larger blocks. They propose alternative methods such as attaching OP_RETURN outputs or providing hand-signed letters to explicitly state business preferences. Napolitano raises concerns about English-language measures being misleading and the significant economic activity in non-Western countries. Centralized forums like Twitter and Reddit are also seen as easily censored and manipulated. Peter Todd adds an anecdote about a Bitcoin-related product that had majority sales in non-English-speaking countries, emphasizing the need for inclusivity in consensus-building processes.In response to jl2012's calculations on the effect of a SW softfork on the total block size, Peter Todd argues that client-side adoption of SW demonstrates the ecosystem's acceptance of a blocksize increase. Another user counters by stating that SW adoption merely indicates implementers seeing greater value in it than the cost of implementation, not necessarily a preference for larger blocks. They suggest alternative ways for businesses to express their desires. Todd acknowledges that SW adoption is not as effective as a direct proof-of-stake vote but finds it to be an interesting side-effect.Another user on the mailing list expresses doubt about SW being the sole short-term solution for scalability. They believe fraud-proof systems are crucial for network security, suggesting the addition of fraud proofs to blocks to make features like committed UTXO sets less risky. While recognizing the value of solving transaction malleability, their main concern is buying time for continued usage growth while working towards eliminating the maximum block size as a consensus rule.On December 19, 2015, jl2012 calculates the effect of a SW softfork on the actual total block size. Client-side adoption is necessary for an actual blocksize increase, which can be seen as a positive sign that the ecosystem has embraced larger blocks. Although this method is not as ideal as a direct proof-of-stake vote and has some coercive elements due to lower fees, it is an intriguing side-effect.The author of the text conducts calculations on the effect of a SW softfork on the total block size. They define various terms and propose a discount factor for witness size. They present a table showing the maximum total block size based on different variables. However, they note that P2SH has only been in use for 3.5 years and accounts for only 10% of Bitcoin storage, making a 40% adoption rate for SegWit within a year over-optimistic unless transaction fees significantly increase. The author also questions whether SW should be the exclusive short-term solution for scalability.Overall, the discussions on the Bitcoin-dev mailing list touch upon the implementation and adoption rates of Pay-to-Script-Hash (P2SH) and Segregated Witness (SW), the relationship between client-side adoption and block size preferences, alternative methods for expressing desires in the Bitcoin ecosystem, concerns about scalability solutions, and calculations on the impact of SW on the total block size. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Segregated-witnesses-and-validationless-mining.xml b/static/bitcoin-dev/Dec_2015/combined_Segregated-witnesses-and-validationless-mining.xml index 62a9e9cf73..fd23a3101a 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Segregated-witnesses-and-validationless-mining.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Segregated-witnesses-and-validationless-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segregated witnesses and validationless mining - 2023-08-01T17:17:47.312812+00:00 + 2025-10-11T21:43:27.330115+00:00 + python-feedgen Bryan Bishop 2016-01-02 16:54:43+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Segregated witnesses and validationless mining - 2023-08-01T17:17:47.312812+00:00 + 2025-10-11T21:43:27.330223+00:00 - On December 28th, 2015, an IRC discussion took place regarding various updates related to Bitcoin. The discussion covered topics such as prior-block possession proofs, fraud proofs, non-fraud correctness proofs, commitments, and segwit. Jorge Timón requested a link to the IRC discussion in an email sent on January 2nd, 2016 at 10:37 AM. The email signature included Bryan's personal website and phone number. Peter Todd, a member of the Bitcoin-dev community, posted on January 1, 2016, asking for a link to the IRC discussion. He had previously provided updates from the same discussion in a post on December 22, 2015, but did not include any details about the discussion itself.In the IRC discussion, there was a debate about what should be required from the current block to calculate the previous block possession proof. It was suggested that the nonce could be picked arbitrarily, allowing for future soft-forks to add commitments to the current block contents. Fraud proofs were also discussed, with Pieter Wuille bringing up the idea of structuring the possession proof as a merkle tree to easily prove fraud using a merkle path.Bitcoin developer Peter Todd proposed a solution to return segregated witnesses to the status quo. This solution involves making the previous block's witness data a precondition for creating a block with transactions. This can be achieved by including the previous witness data, hashed with a different hash function than the commitment in the previous block, in the current block's coinbase txouts calculation. However, this solution may face resistance from miners currently using validationless mining techniques. To retain the possibility of validationless mining, empty blocks can be created if the previous witness data proof is omitted.Segregated witnesses separate transaction information from the information proving their legitimacy, making validationless mining more profitable. To address this issue, the protocol can be changed to require a copy of the previous block's witness data as a precondition for creating a block. This soft-fork solution aims to prevent the main code path from creating blocks without any validation. Additionally, it is proposed that adding a random selection of previous blocks to the previous witness data proof solution could address concerns about miner theft and currency inflation.In conclusion, the IRC discussion covered various topics related to Bitcoin, including possession proofs, fraud proofs, commitments, and segwit. Peter Todd proposed a solution to bring segregated witnesses back to the status quo by making the previous block's witness data a precondition for block creation. This solution may face pushback from miners using validationless mining techniques. To address this, empty blocks can be created if the previous witness data proof is omitted. The discussion also explored the potential benefits of validationless mining and solutions to address concerns about miner theft and currency inflation. 2016-01-02T16:54:43+00:00 + On December 28th, 2015, an IRC discussion took place regarding various updates related to Bitcoin. The discussion covered topics such as prior-block possession proofs, fraud proofs, non-fraud correctness proofs, commitments, and segwit. Jorge Timón requested a link to the IRC discussion in an email sent on January 2nd, 2016 at 10:37 AM. The email signature included Bryan's personal website and phone number. Peter Todd, a member of the Bitcoin-dev community, posted on January 1, 2016, asking for a link to the IRC discussion. He had previously provided updates from the same discussion in a post on December 22, 2015, but did not include any details about the discussion itself.In the IRC discussion, there was a debate about what should be required from the current block to calculate the previous block possession proof. It was suggested that the nonce could be picked arbitrarily, allowing for future soft-forks to add commitments to the current block contents. Fraud proofs were also discussed, with Pieter Wuille bringing up the idea of structuring the possession proof as a merkle tree to easily prove fraud using a merkle path.Bitcoin developer Peter Todd proposed a solution to return segregated witnesses to the status quo. This solution involves making the previous block's witness data a precondition for creating a block with transactions. This can be achieved by including the previous witness data, hashed with a different hash function than the commitment in the previous block, in the current block's coinbase txouts calculation. However, this solution may face resistance from miners currently using validationless mining techniques. To retain the possibility of validationless mining, empty blocks can be created if the previous witness data proof is omitted.Segregated witnesses separate transaction information from the information proving their legitimacy, making validationless mining more profitable. To address this issue, the protocol can be changed to require a copy of the previous block's witness data as a precondition for creating a block. This soft-fork solution aims to prevent the main code path from creating blocks without any validation. Additionally, it is proposed that adding a random selection of previous blocks to the previous witness data proof solution could address concerns about miner theft and currency inflation.In conclusion, the IRC discussion covered various topics related to Bitcoin, including possession proofs, fraud proofs, commitments, and segwit. Peter Todd proposed a solution to bring segregated witnesses back to the status quo by making the previous block's witness data a precondition for block creation. This solution may face pushback from miners using validationless mining techniques. To address this, empty blocks can be created if the previous witness data proof is omitted. The discussion also explored the potential benefits of validationless mining and solutions to address concerns about miner theft and currency inflation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Some-transcripts-from-the-Scaling-Bitcoin-workshops.xml b/static/bitcoin-dev/Dec_2015/combined_Some-transcripts-from-the-Scaling-Bitcoin-workshops.xml index 91f5a144a4..9fb0347cdb 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Some-transcripts-from-the-Scaling-Bitcoin-workshops.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Some-transcripts-from-the-Scaling-Bitcoin-workshops.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Some transcripts from the Scaling Bitcoin workshops - 2023-08-01T16:59:42.650892+00:00 + 2025-10-11T21:42:55.463302+00:00 + python-feedgen Pindar Wong 2015-12-07 07:21:58+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Some transcripts from the Scaling Bitcoin workshops - 2023-08-01T16:59:42.650892+00:00 + 2025-10-11T21:42:55.463464+00:00 - Bryan Bishop, a bitcoin developer, has shared a list of links to transcripts from the Scaling Bitcoin workshops held in Hong Kong and Montreal. These workshops covered important topics such as block size proposals, scalability, zero-knowledge proofs, and lightning network. While the transcripts may not be exact due to Bishop's typing while listening, they offer valuable insights into the discussions at the workshops.In a discussion on the bitcoin-dev mailing list, Bryan Bishop mentioned that he had diligently typed most of the words down while listening to some talks. This dedication was recognized by Johnathan Corgan, who operates Corgan Labs, a company specializing in SDR training and development services. The email exchange also includes a link to Corgan Labs' website, providing further resources for those interested in the field.The shared links lead to transcripts of talks that cover a wide range of topics related to scalability and security concerns in Bitcoin. Some of these include discussions on zero-knowledge proofs for scalability, segregated witness, block propagation data, validation costs, relay networks, and sharding the blockchain. These talks provide an opportunity to delve into the latest developments and discussions within the Bitcoin community.Overall, this context offers a valuable collection of resources for individuals seeking to learn about the advancements and ongoing conversations in the world of Bitcoin. 2015-12-07T07:21:58+00:00 + Bryan Bishop, a bitcoin developer, has shared a list of links to transcripts from the Scaling Bitcoin workshops held in Hong Kong and Montreal. These workshops covered important topics such as block size proposals, scalability, zero-knowledge proofs, and lightning network. While the transcripts may not be exact due to Bishop's typing while listening, they offer valuable insights into the discussions at the workshops.In a discussion on the bitcoin-dev mailing list, Bryan Bishop mentioned that he had diligently typed most of the words down while listening to some talks. This dedication was recognized by Johnathan Corgan, who operates Corgan Labs, a company specializing in SDR training and development services. The email exchange also includes a link to Corgan Labs' website, providing further resources for those interested in the field.The shared links lead to transcripts of talks that cover a wide range of topics related to scalability and security concerns in Bitcoin. Some of these include discussions on zero-knowledge proofs for scalability, segregated witness, block propagation data, validation costs, relay networks, and sharding the blockchain. These talks provide an opportunity to delve into the latest developments and discussions within the Bitcoin community.Overall, this context offers a valuable collection of resources for individuals seeking to learn about the advancements and ongoing conversations in the world of Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_Standard-BIP-Draft-Turing-Pseudo-Completeness.xml b/static/bitcoin-dev/Dec_2015/combined_Standard-BIP-Draft-Turing-Pseudo-Completeness.xml index ae79a4e0bf..fc2d12d845 100644 --- a/static/bitcoin-dev/Dec_2015/combined_Standard-BIP-Draft-Turing-Pseudo-Completeness.xml +++ b/static/bitcoin-dev/Dec_2015/combined_Standard-BIP-Draft-Turing-Pseudo-Completeness.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Standard BIP Draft: Turing Pseudo-Completeness - 2023-08-01T17:06:26.040598+00:00 + 2025-10-11T21:43:18.834111+00:00 + python-feedgen Emin Gün Sirer 2015-12-12 21:01:45+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Standard BIP Draft: Turing Pseudo-Completeness - 2023-08-01T17:06:26.040598+00:00 + 2025-10-11T21:43:18.834295+00:00 - In an email conversation on the Bitcoin developers mailing list, Luke Durback proposed the idea of using Bitcoin's scripting language for voting on proposals. He suggested allowing users to "mark" their BTC as being "For Proposition X" and cancel the vote as soon as the BTC is spent again. However, finding a design that would allow this has been challenging. Durback initially thought Turing completeness was necessary for this design, but later realized it was not required.Jorge Timón responded to Durback's proposal by suggesting time-locking votes and using covenants instead of recursion or Turing completeness. Timón questioned the need for Turing completeness in these use cases and asked for more concrete examples. The conversation also touched on the idea of charging fees for complex scripts and the use cases for decentralized exchanges and paying creators through Bitcoin functions.Durback mentioned the possibility of charging a fee for frequently used complicated scripts, and he proposed a decentralized exchange between colored coins that might take a small fee on each trade. However, the need for Turing completeness in these scenarios was questioned, and Timón asked for more clarity and examples.The discussion revolved around implementing a voting system using BTC as voting shares. Durback planned to add a fee for the creator of the system, but Timón pointed out that each scriptSig is only executed once with its corresponding scriptPubKey. They also briefly discussed the idea of a decentralized exchange between colored coins, with Durback suggesting a small fee on each trade. Timón noted that turing completeness is not necessary for decentralized exchange designs.Durback expressed his intention to work on developing a system for using BTC as voting shares, which he believed would be a useful and simple example requiring loops and reused functions. He also suggested charging a fee for complex systems that are used frequently. The conversation ended with Timón asking for high-level examples of the use cases they would like to support with this system.There was also a separate discussion about adding opcodes to make Script Turing Pseudo-Complete, as suggested by Wright. The proposal included adding a return stack and several new opcodes to allow for the creation of new functions, marking transactions as valid, debiting calling transactions, creating new transactions, and more. However, another member of the mailing list responded that there is no need for a BIP draft and suggested using a normal computer language with preferred algorithm libraries and development tools instead.Overall, the conversation focused on the feasibility of using Bitcoin's scripting language for voting on proposals, the potential for charging fees for complex scripts, and the use cases for decentralized exchanges and paying creators through Bitcoin functions. 2015-12-12T21:01:45+00:00 + In an email conversation on the Bitcoin developers mailing list, Luke Durback proposed the idea of using Bitcoin's scripting language for voting on proposals. He suggested allowing users to "mark" their BTC as being "For Proposition X" and cancel the vote as soon as the BTC is spent again. However, finding a design that would allow this has been challenging. Durback initially thought Turing completeness was necessary for this design, but later realized it was not required.Jorge Timón responded to Durback's proposal by suggesting time-locking votes and using covenants instead of recursion or Turing completeness. Timón questioned the need for Turing completeness in these use cases and asked for more concrete examples. The conversation also touched on the idea of charging fees for complex scripts and the use cases for decentralized exchanges and paying creators through Bitcoin functions.Durback mentioned the possibility of charging a fee for frequently used complicated scripts, and he proposed a decentralized exchange between colored coins that might take a small fee on each trade. However, the need for Turing completeness in these scenarios was questioned, and Timón asked for more clarity and examples.The discussion revolved around implementing a voting system using BTC as voting shares. Durback planned to add a fee for the creator of the system, but Timón pointed out that each scriptSig is only executed once with its corresponding scriptPubKey. They also briefly discussed the idea of a decentralized exchange between colored coins, with Durback suggesting a small fee on each trade. Timón noted that turing completeness is not necessary for decentralized exchange designs.Durback expressed his intention to work on developing a system for using BTC as voting shares, which he believed would be a useful and simple example requiring loops and reused functions. He also suggested charging a fee for complex systems that are used frequently. The conversation ended with Timón asking for high-level examples of the use cases they would like to support with this system.There was also a separate discussion about adding opcodes to make Script Turing Pseudo-Complete, as suggested by Wright. The proposal included adding a return stack and several new opcodes to allow for the creation of new functions, marking transactions as valid, debiting calling transactions, creating new transactions, and more. However, another member of the mailing list responded that there is no need for a BIP draft and suggested using a normal computer language with preferred algorithm libraries and development tools instead.Overall, the conversation focused on the feasibility of using Bitcoin's scripting language for voting on proposals, the potential for charging fees for complex scripts, and the use cases for decentralized exchanges and paying creators through Bitcoin functions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_The-increase-of-max-block-size-should-be-determined-by-block-height-instead-of-block-time.xml b/static/bitcoin-dev/Dec_2015/combined_The-increase-of-max-block-size-should-be-determined-by-block-height-instead-of-block-time.xml index 949cc5c380..93eee00410 100644 --- a/static/bitcoin-dev/Dec_2015/combined_The-increase-of-max-block-size-should-be-determined-by-block-height-instead-of-block-time.xml +++ b/static/bitcoin-dev/Dec_2015/combined_The-increase-of-max-block-size-should-be-determined-by-block-height-instead-of-block-time.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The increase of max block size should be determined by block height instead of block time - 2023-08-01T17:12:28.704891+00:00 + 2025-10-11T21:43:37.949177+00:00 + python-feedgen Peter Todd 2015-12-19 18:20:38+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - The increase of max block size should be determined by block height instead of block time - 2023-08-01T17:12:28.704891+00:00 + 2025-10-11T21:43:37.949386+00:00 - Chun Wang, a bitcoin developer, has raised concerns over the use of block time to determine the maximum block size in many Bitcoin Improvement Proposals (BIPs), including the latest BIP202. He argues that it is difficult for mining pools to issue a job with the maximum block size unknown due to the existence of ntime roll and suggests that block height would be a simpler and more elegant solution.Peter Todd, another bitcoin developer, responds by proposing that size be calculated from the median time past, which is fixed for a given block and has no dependency on the block header's nTime field.Jeff Garzik, a developer of Bitcoin, suggested a proposal for Bitcoin block size increase. He prefers height activation and one step per block (also height). Under this scheme, the size of the step-per-block increase could be decreased every 210,000 blocks at the time of reward halvings.On December 18, 2015, Jorge Timón via bitcoin-dev proposed two options to improve the Bitcoin network's block time. One option is to use nHeight while the other is to utilize the median time from the previous block.In the discussion thread, several developers are debating over the best method to determine the maximum block size in Bitcoin. One developer suggests using height activation and one step per block, while another argues for median time of the previous block. The original developer expresses interest in hearing from others about possible attacks with different approaches before diverging from the default community approach of switch-based-on-time.The discussion revolves around determining the max block size based on block height or time. Jeff Garzik prefers height activation with one step per block as it is more simple and attacks would occur around the already-heavily-watched flag day activation event, which is useful. However, he wants to hear from others about possible attacks before diverging from the default community approach of switch-based-on-time. Jorge Timón thinks median time of the previous block is better than the time of the current one and would also solve Chun Wang's concerns. He prefers heights that correspond to diff recalculation. From a code standpoint, based off height is easy. The internal version triggered on block 406,800 and each block increased by 20 bytes thereafter. It was changed to time as MTP flag day is more stable than block height.In the discussion thread, several developers are debating over the best method to determine the maximum block size in Bitcoin. One developer suggests using height activation and one step per block, while another argues for median time of the previous block.The Bitcoin community discussed the best way to trigger changes in block size limits. The initial version triggered on block height but was later changed to time, as it was believed to be more stable. There is a preference for a single flag trigger (height or time), however any combination of those will work.The discussion revolves around the simplicity of using nHeight as the preferred option for determining the max block size. Another option suggested is to use median time from the previous block which helps in knowing whether the next block should start miner confirmation or not. It is suggested that it would be nice to always pick a difficulty retarget block, and an initial height should be there in bip9 for softforks too.The latest Bitcoin Improvement Proposals (BIPs), such as BIP202, have established that the maximum block size is determined by the block time. However, from a pool's perspective, it is difficult to issue a job with a fixed ntime due to the existence of ntime roll. This makes it challenging to determine the maximum block size for issuing a job. Developers find it much simpler and more elegant to implement a function of block height instead of time for determining the maximum block size. Block height is considered a better alternative because it is easier to work with and more straightforward than time. In conclusion, while BIPs have set a precedent for the maximum block size being based on block time, there are challenges in implementing this rule for pools and developers. The use of block height is seen as a more efficient and logical alternative. 2015-12-19T18:20:38+00:00 + Chun Wang, a bitcoin developer, has raised concerns over the use of block time to determine the maximum block size in many Bitcoin Improvement Proposals (BIPs), including the latest BIP202. He argues that it is difficult for mining pools to issue a job with the maximum block size unknown due to the existence of ntime roll and suggests that block height would be a simpler and more elegant solution.Peter Todd, another bitcoin developer, responds by proposing that size be calculated from the median time past, which is fixed for a given block and has no dependency on the block header's nTime field.Jeff Garzik, a developer of Bitcoin, suggested a proposal for Bitcoin block size increase. He prefers height activation and one step per block (also height). Under this scheme, the size of the step-per-block increase could be decreased every 210,000 blocks at the time of reward halvings.On December 18, 2015, Jorge Timón via bitcoin-dev proposed two options to improve the Bitcoin network's block time. One option is to use nHeight while the other is to utilize the median time from the previous block.In the discussion thread, several developers are debating over the best method to determine the maximum block size in Bitcoin. One developer suggests using height activation and one step per block, while another argues for median time of the previous block. The original developer expresses interest in hearing from others about possible attacks with different approaches before diverging from the default community approach of switch-based-on-time.The discussion revolves around determining the max block size based on block height or time. Jeff Garzik prefers height activation with one step per block as it is more simple and attacks would occur around the already-heavily-watched flag day activation event, which is useful. However, he wants to hear from others about possible attacks before diverging from the default community approach of switch-based-on-time. Jorge Timón thinks median time of the previous block is better than the time of the current one and would also solve Chun Wang's concerns. He prefers heights that correspond to diff recalculation. From a code standpoint, based off height is easy. The internal version triggered on block 406,800 and each block increased by 20 bytes thereafter. It was changed to time as MTP flag day is more stable than block height.In the discussion thread, several developers are debating over the best method to determine the maximum block size in Bitcoin. One developer suggests using height activation and one step per block, while another argues for median time of the previous block.The Bitcoin community discussed the best way to trigger changes in block size limits. The initial version triggered on block height but was later changed to time, as it was believed to be more stable. There is a preference for a single flag trigger (height or time), however any combination of those will work.The discussion revolves around the simplicity of using nHeight as the preferred option for determining the max block size. Another option suggested is to use median time from the previous block which helps in knowing whether the next block should start miner confirmation or not. It is suggested that it would be nice to always pick a difficulty retarget block, and an initial height should be there in bip9 for softforks too.The latest Bitcoin Improvement Proposals (BIPs), such as BIP202, have established that the maximum block size is determined by the block time. However, from a pool's perspective, it is difficult to issue a job with a fixed ntime due to the existence of ntime roll. This makes it challenging to determine the maximum block size for issuing a job. Developers find it much simpler and more elegant to implement a function of block height instead of time for determining the maximum block size. Block height is considered a better alternative because it is easier to work with and more straightforward than time. In conclusion, while BIPs have set a precedent for the maximum block size being based on block time, there are challenges in implementing this rule for pools and developers. The use of block height is seen as a more efficient and logical alternative. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_We-can-trivially-fix-quadratic-CHECKSIG-with-a-simple-soft-fork-modifying-just-SignatureHash-.xml b/static/bitcoin-dev/Dec_2015/combined_We-can-trivially-fix-quadratic-CHECKSIG-with-a-simple-soft-fork-modifying-just-SignatureHash-.xml index 3d79da7a90..bbbdb922ec 100644 --- a/static/bitcoin-dev/Dec_2015/combined_We-can-trivially-fix-quadratic-CHECKSIG-with-a-simple-soft-fork-modifying-just-SignatureHash-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_We-can-trivially-fix-quadratic-CHECKSIG-with-a-simple-soft-fork-modifying-just-SignatureHash-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - We can trivially fix quadratic CHECKSIG with a simple soft-fork modifying just SignatureHash() - 2023-08-01T17:18:54.610038+00:00 + 2025-10-11T21:43:20.956309+00:00 + python-feedgen Jonathan Toomim 2015-12-29 13:00:45+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - We can trivially fix quadratic CHECKSIG with a simple soft-fork modifying just SignatureHash() - 2023-08-01T17:18:54.610038+00:00 + 2025-10-11T21:43:20.956481+00:00 - In December 2015, a discussion took place on the bitcoin-dev mailing list regarding the use of short-circuit evaluation and potential complaints that may arise. Jonathan Toomim suggested that humans possess the ability to respond to new situations without predetermined rules and algorithms, and this ability should be utilized at times. However, concerns were raised about complaints and the necessity of establishing general consensus rules as a social contract.To address these concerns, Jonathan Toomim proposed announcing the intention to perform a soft fork a couple of months before it becomes active. By doing so, they could ensure that nobody complains about the soft fork destroying their secret stash. This approach, according to Toomim, would minimize the likelihood of complaints arising.During the discussion, the possibility of someone having a timelocked big transaction with a lost private key was also brought up. Toomim considered this scenario to be unlikely, emphasizing the importance of establishing consensus rules as a social contract to prevent breaking them without exceptional circumstances.The conversation emphasized the significance of considering potential issues and establishing clear rules and communication when making changes to the bitcoin network. It highlighted the need for proactive measures to address concerns and maintain the integrity of the system.Another member of the mailing list, jl2012, expressed doubts about the scenario involving a timelocked big transaction with a lost private key. To address this concern, Peter Todd suggested telling people not to engage in such practices. He proposed a fix for the quadratic CHECK(MULTI)SIG execution time issue by limiting only SignatureHash() to return true if the transaction size is less than or equal to 100KB. This solution allowed for a future soft-fork that could properly address the hashing issue without impacting all transactions or counting sigops.Todd's proposed solution offered ease of implementation and quick deployment in case of an attack by a major miner exploiting slow-to-propagate blocks. He provided a link to related discussions for further reference.To implement a soft-fork that resolves the quadratic CHECK(MULTI)SIG execution time issue, the suggested approach is to limit SignatureHash() to return true only if the transaction size is 100KB. While this solution technically allows transactions, it prevents them from spending coins that are cryptographically secured. This fix could be deployed as a soft-fork within a matter of days, making it an effective solution in case major miners exploit slow-to-propagate blocks to harm their competitors.Overall, the discussion on the bitcoin-dev mailing list highlighted the importance of considering potential issues, establishing clear rules and communication, and implementing proactive measures to maintain the integrity of the bitcoin network. 2015-12-29T13:00:45+00:00 + In December 2015, a discussion took place on the bitcoin-dev mailing list regarding the use of short-circuit evaluation and potential complaints that may arise. Jonathan Toomim suggested that humans possess the ability to respond to new situations without predetermined rules and algorithms, and this ability should be utilized at times. However, concerns were raised about complaints and the necessity of establishing general consensus rules as a social contract.To address these concerns, Jonathan Toomim proposed announcing the intention to perform a soft fork a couple of months before it becomes active. By doing so, they could ensure that nobody complains about the soft fork destroying their secret stash. This approach, according to Toomim, would minimize the likelihood of complaints arising.During the discussion, the possibility of someone having a timelocked big transaction with a lost private key was also brought up. Toomim considered this scenario to be unlikely, emphasizing the importance of establishing consensus rules as a social contract to prevent breaking them without exceptional circumstances.The conversation emphasized the significance of considering potential issues and establishing clear rules and communication when making changes to the bitcoin network. It highlighted the need for proactive measures to address concerns and maintain the integrity of the system.Another member of the mailing list, jl2012, expressed doubts about the scenario involving a timelocked big transaction with a lost private key. To address this concern, Peter Todd suggested telling people not to engage in such practices. He proposed a fix for the quadratic CHECK(MULTI)SIG execution time issue by limiting only SignatureHash() to return true if the transaction size is less than or equal to 100KB. This solution allowed for a future soft-fork that could properly address the hashing issue without impacting all transactions or counting sigops.Todd's proposed solution offered ease of implementation and quick deployment in case of an attack by a major miner exploiting slow-to-propagate blocks. He provided a link to related discussions for further reference.To implement a soft-fork that resolves the quadratic CHECK(MULTI)SIG execution time issue, the suggested approach is to limit SignatureHash() to return true only if the transaction size is 100KB. While this solution technically allows transactions, it prevents them from spending coins that are cryptographically secured. This fix could be deployed as a soft-fork within a matter of days, making it an effective solution in case major miners exploit slow-to-propagate blocks to harm their competitors.Overall, the discussion on the bitcoin-dev mailing list highlighted the importance of considering potential issues, establishing clear rules and communication, and implementing proactive measures to maintain the integrity of the bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_We-need-to-fix-the-block-withholding-attack.xml b/static/bitcoin-dev/Dec_2015/combined_We-need-to-fix-the-block-withholding-attack.xml index f2a47fe142..f766c37eba 100644 --- a/static/bitcoin-dev/Dec_2015/combined_We-need-to-fix-the-block-withholding-attack.xml +++ b/static/bitcoin-dev/Dec_2015/combined_We-need-to-fix-the-block-withholding-attack.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - We need to fix the block withholding attack - 2023-08-01T17:14:38.131570+00:00 + 2025-10-11T21:43:08.206415+00:00 + python-feedgen Dave Scotese 2015-12-29 21:51:29+00:00 @@ -191,13 +192,13 @@ - python-feedgen + 2 Combined summary - We need to fix the block withholding attack - 2023-08-01T17:14:38.131570+00:00 + 2025-10-11T21:43:08.206602+00:00 - In a discussion among Bitcoin developers, several proposals were made to combat block withholding attacks and address concerns about decentralization and profitability in mining. One suggestion was to provide a bonus to the miner who discovers the block as a countermeasure to block withholding attacks. This would make the attacks more expensive for the attacker without greatly impacting smaller miners. The need for better mechanisms to prevent dishonest behavior in mining pools was emphasized. The profitability difference between large and small miners was identified as a major concern.A debate arose regarding the potential impact of decreasing block rewards on the overall hash rate and security of the Bitcoin network. Some argued that decreasing rewards could lead to a decrease in miner participation and compromise the network's security, while others believed that the market would adjust and the network would remain secure.There were discussions about the possibility of addressing block withholding attacks through soft forks or hard forks. A soft fork involving adding an invisible difficulty was suggested, but it was acknowledged that this approach could result in longer confirmation times, lower throughput, and lower miner revenue. Compensating for these economic shifts would require increasing block rewards and size, which would add complications to the protocol and require app migration efforts.The issue of centralization in Bitcoin mining was also raised. Large mining pools, such as GHash.IO, were mentioned as examples of pools that had approached the 51% threshold, raising concerns about their dominance in mining power. Various proposals were made to prevent centralization, including implementing measures such as a hard cap on mining pool size or incentives for smaller pools.Different solutions to block withholding attacks were discussed, including altering mining protocols to require miners to indicate their identity with a public key included in their blocks. Techniques to detect block withholding attacks were also mentioned, although specific details were not revealed due to concerns about attackers finding ways to avoid detection.During the Scaling Bitcoin conference, pool representatives expressed concerns about block withholding attacks and their potential impact on decentralization. It was noted that pools without anti-privacy KYC measures have little defense against such attacks. P2Pool, often suggested as an alternative to pools, was also found to be susceptible to block withholding and had other vulnerabilities hindering widespread adoption.Several proposals were made for addressing block withholding attacks, including a SPV-visible hardfork. Peter Todd suggested using Luke-Jr's two-stage target mechanism to fix block withholding. However, arguments were presented that block withholding attacks can be used by small pools against larger ones, although practical defenses exist for large pools.The theoretical nature of block withholding attacks was emphasized, as those with the majority of hashpower have not engaged in this behavior. Therefore, addressing block withholding attacks was considered a low priority compared to other matters.A long-term solution to block withholding attacks was proposed at the Scaling Bitcoin conference. The proposal aimed to fundamentally remove the source of contention and fix the design flaw while staying true to the spirit of Bitcoin. It involved adding disincentives for withholding blocks and considering other graph-theoretic quantities in the reward function. Concerns about vulnerabilities and technical issues with P2Pool were raised in relation to testing these ideas.In conclusion, block withholding attacks pose a significant concern for pools, especially those without anti-privacy KYC measures. Several proposals and perspectives were presented to address this issue, including bonuses for miners, altering mining protocols, and implementing SPV-visible hardforks. Practical defenses exist for large pools, but concerns about centralization and profitability remain. The theoretical nature of block withholding attacks and alternative long-term solutions were also discussed. 2015-12-29T21:51:29+00:00 + In a discussion among Bitcoin developers, several proposals were made to combat block withholding attacks and address concerns about decentralization and profitability in mining. One suggestion was to provide a bonus to the miner who discovers the block as a countermeasure to block withholding attacks. This would make the attacks more expensive for the attacker without greatly impacting smaller miners. The need for better mechanisms to prevent dishonest behavior in mining pools was emphasized. The profitability difference between large and small miners was identified as a major concern.A debate arose regarding the potential impact of decreasing block rewards on the overall hash rate and security of the Bitcoin network. Some argued that decreasing rewards could lead to a decrease in miner participation and compromise the network's security, while others believed that the market would adjust and the network would remain secure.There were discussions about the possibility of addressing block withholding attacks through soft forks or hard forks. A soft fork involving adding an invisible difficulty was suggested, but it was acknowledged that this approach could result in longer confirmation times, lower throughput, and lower miner revenue. Compensating for these economic shifts would require increasing block rewards and size, which would add complications to the protocol and require app migration efforts.The issue of centralization in Bitcoin mining was also raised. Large mining pools, such as GHash.IO, were mentioned as examples of pools that had approached the 51% threshold, raising concerns about their dominance in mining power. Various proposals were made to prevent centralization, including implementing measures such as a hard cap on mining pool size or incentives for smaller pools.Different solutions to block withholding attacks were discussed, including altering mining protocols to require miners to indicate their identity with a public key included in their blocks. Techniques to detect block withholding attacks were also mentioned, although specific details were not revealed due to concerns about attackers finding ways to avoid detection.During the Scaling Bitcoin conference, pool representatives expressed concerns about block withholding attacks and their potential impact on decentralization. It was noted that pools without anti-privacy KYC measures have little defense against such attacks. P2Pool, often suggested as an alternative to pools, was also found to be susceptible to block withholding and had other vulnerabilities hindering widespread adoption.Several proposals were made for addressing block withholding attacks, including a SPV-visible hardfork. Peter Todd suggested using Luke-Jr's two-stage target mechanism to fix block withholding. However, arguments were presented that block withholding attacks can be used by small pools against larger ones, although practical defenses exist for large pools.The theoretical nature of block withholding attacks was emphasized, as those with the majority of hashpower have not engaged in this behavior. Therefore, addressing block withholding attacks was considered a low priority compared to other matters.A long-term solution to block withholding attacks was proposed at the Scaling Bitcoin conference. The proposal aimed to fundamentally remove the source of contention and fix the design flaw while staying true to the spirit of Bitcoin. It involved adding disincentives for withholding blocks and considering other graph-theoretic quantities in the reward function. Concerns about vulnerabilities and technical issues with P2Pool were raised in relation to testing these ideas.In conclusion, block withholding attacks pose a significant concern for pools, especially those without anti-privacy KYC measures. Several proposals and perspectives were presented to address this issue, including bonuses for miners, altering mining protocols, and implementing SPV-visible hardforks. Practical defenses exist for large pools, but concerns about centralization and profitability remain. The theoretical nature of block withholding attacks and alternative long-term solutions were also discussed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2015/combined_fork-types-Re-An-implementation-of-BIP102-as-a-softfork-.xml b/static/bitcoin-dev/Dec_2015/combined_fork-types-Re-An-implementation-of-BIP102-as-a-softfork-.xml index e62d0b4ba3..e48ae2024a 100644 --- a/static/bitcoin-dev/Dec_2015/combined_fork-types-Re-An-implementation-of-BIP102-as-a-softfork-.xml +++ b/static/bitcoin-dev/Dec_2015/combined_fork-types-Re-An-implementation-of-BIP102-as-a-softfork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - fork types (Re: An implementation of BIP102 as a softfork.) - 2023-08-01T17:21:31.603399+00:00 + 2025-10-11T21:42:59.709712+00:00 + python-feedgen Bryan Bishop 2015-12-30 23:10:05+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - fork types (Re: An implementation of BIP102 as a softfork.) - 2023-08-01T17:21:31.603399+00:00 + 2025-10-11T21:42:59.709898+00:00 - In the email thread, various types of forks are discussed, with a focus on firm hard forks that allow for format changes not achievable with soft-forks. The conversation includes links to discussions about auxiliary blocks, evil soft-forks, and forced soft-forks, as well as the use of extension blocks for a soft-fork block size increase. Previous conversations touch on topics such as generalized soft-forks, bip102 forced soft-forks, and extension blocks and sidechains.One of the key points of discussion is the implementation of segregated witness (SW), which is a soft-fork designed to be compatible both backwards and forwards, similar to P2SH. Soft forks are favored over hard forks due to their ability to avoid leaving behind a weak chain that could result in financial loss. However, the email acknowledges the existence of firm hard forks that can achieve the same purpose of format changes not possible with soft-forks.The concept of extension blocks is also explored in older conversations, alongside discussions about evil forks, evil soft-forks, and extension blocks. Segregated witness is mentioned as utilizing a similar idea. Additionally, the context delves into the concept of a "forced soft-fork," explaining that it is essentially the same as an "evil fork."In relation to segregated witness, it is noted that although extension blocks demonstrate the possibility of a more general backwards and forwards compatible soft-fork, the implementation of segregated witness is simpler. The conversation also touches on the utilization of the strategy pattern to assist with code structure.Overall, the email thread provides a comprehensive exploration of various types of forks, including the distinction between soft forks and hard forks within the context of segregated witness implementation. The links shared throughout the discussion serve as valuable resources to further understand the concepts being discussed. 2015-12-30T23:10:05+00:00 + In the email thread, various types of forks are discussed, with a focus on firm hard forks that allow for format changes not achievable with soft-forks. The conversation includes links to discussions about auxiliary blocks, evil soft-forks, and forced soft-forks, as well as the use of extension blocks for a soft-fork block size increase. Previous conversations touch on topics such as generalized soft-forks, bip102 forced soft-forks, and extension blocks and sidechains.One of the key points of discussion is the implementation of segregated witness (SW), which is a soft-fork designed to be compatible both backwards and forwards, similar to P2SH. Soft forks are favored over hard forks due to their ability to avoid leaving behind a weak chain that could result in financial loss. However, the email acknowledges the existence of firm hard forks that can achieve the same purpose of format changes not possible with soft-forks.The concept of extension blocks is also explored in older conversations, alongside discussions about evil forks, evil soft-forks, and extension blocks. Segregated witness is mentioned as utilizing a similar idea. Additionally, the context delves into the concept of a "forced soft-fork," explaining that it is essentially the same as an "evil fork."In relation to segregated witness, it is noted that although extension blocks demonstrate the possibility of a more general backwards and forwards compatible soft-fork, the implementation of segregated witness is simpler. The conversation also touches on the utilization of the strategy pattern to assist with code structure.Overall, the email thread provides a comprehensive exploration of various types of forks, including the distinction between soft forks and hard forks within the context of segregated witness implementation. The links shared throughout the discussion serve as valuable resources to further understand the concepts being discussed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Dec_2016/combined_Bitcoin-Currency.xml b/static/bitcoin-dev/Dec_2016/combined_Bitcoin-Currency.xml index 5ac5551baa..d2078a7cc1 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Bitcoin-Currency.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Bitcoin-Currency.xml @@ -2,7 +2,7 @@ 2 Combined summary - Bitcoin Currency - 2025-09-26T15:53:02.673314+00:00 + 2025-10-11T21:59:24.014640+00:00 python-feedgen Henning Kopp 2016-12-14 08:00:51+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Bitcoin Currency - 2025-09-26T15:53:02.673438+00:00 + 2025-10-11T21:59:24.014790+00:00 2016-12-14T08:00:51+00:00 In a Bitcoin developer mailing list discussion, Ben West raised a question about whether there exists a specific number or ID that can uniquely determine the value of Bitcoin. Additionally, he inquired if there is any hash, address, or key that could be used to identify and claim ownership of a specific amount of Bitcoin, such as 50BTC or 20BTC.Responding to Ben's query, Henning Kopp suggested that the private key of a user might hold the answer to his question. By obtaining this private key, one could spend their Bitcoin funds and provide proof of ownership. To further expand on the topic, Henning recommended a blog post that offers insights into how the Bitcoin protocol functions. He emphasized that the usefulness of the blog post would depend on Ben's level of understanding regarding the subject matter.Henning concluded his response by sharing his contact information from Ulm University in Germany, where he works at the Institute of Distributed Systems.In a separate forum post, another user sought clarification on whether there is a unique identifier for Bitcoin value (BTC) or a method to identify specific amounts of BTC using a hash, address, or key. Essentially, the user was interested in knowing if it is possible to establish ownership of a particular quantity of BTC. diff --git a/static/bitcoin-dev/Dec_2016/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml b/static/bitcoin-dev/Dec_2016/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml index 38ffdba9f3..6a07a201d3 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml @@ -2,7 +2,7 @@ 2 Combined summary - Forcenet: an experimental network with a new header format - 2025-09-26T15:53:13.243130+00:00 + 2025-10-11T21:59:34.645232+00:00 python-feedgen Matt Corallo 2017-01-28 17:14:02+00:00 @@ -85,10 +85,11 @@ + 2 Combined summary - Forcenet: an experimental network with a new header format - 2025-09-26T15:53:13.243275+00:00 + 2025-10-11T21:59:34.645413+00:00 2017-01-28T17:14:02+00:00 The Bitcoin-dev mailing list has been discussing proposals for changes to the Bitcoin protocol. Some of the proposed changes include removing the block size limit, limiting the creation of unspent transaction outputs (UTXOs) and encouraging their spending, and implementing a smoother halving cycle for block rewards. There are also proposals for a new coinbase transaction format and a Merkle sum tree for fraud-proofing.Matt Corallo suggests minimizing header size, having only one merkle tree for transactions, and avoiding variable-length header fields. He also discusses light wallet functionality without an upgrade and the Stratum protocol. Another proposal titled "Client Side Block Filtering" suggests an alternative method of block downloading that allows clients to filter blocks based on specific criteria.Johnson Lau introduces a second version of forcenet with experimental features, including anti-tx-replay and block sighashlimit. The author of the context also creates a second version of forcenet with new experimental features, such as a new header format and anti-tx-replay. There is a discussion about the concept of a sum tree and softfork in Bitcoin, as well as the issue with redefining nSigOp in a sum tree and the proposal to combine the two costs into a unified cost.In December 2016, a discussion took place regarding the use of a timestamp beyond 4 bytes. Luke Dashjr proposed stealing a few bits from the tx nVersion through a softfork as a solution. There were also discussions about the implementation of a new merkle algorithm using a sum tree, communication with legacy nodes, and the possibility of enabling easier soft forks through a bridge node. Suggestions were made to keep hashing to a minimum and to consider an 8-byte timestamp due to the approaching year 2106.Overall, the Bitcoin-dev mailing list concludes that some proposals may not be essential for the hard fork and could be added later through a soft fork. Forcenet, an experimental network, was created to demonstrate a new header format, but some aspects have not yet been implemented. Codes for testing can be found on Github, and joining the network is possible by running "bitcoind --forcenet" and connecting to the node running at 8333.info with the default port. diff --git a/static/bitcoin-dev/Dec_2016/combined_Managing-block-size-the-same-way-we-do-difficulty-aka-Block75-.xml b/static/bitcoin-dev/Dec_2016/combined_Managing-block-size-the-same-way-we-do-difficulty-aka-Block75-.xml index dd5e11030e..c1e07e6a85 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Managing-block-size-the-same-way-we-do-difficulty-aka-Block75-.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Managing-block-size-the-same-way-we-do-difficulty-aka-Block75-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Managing block size the same way we do difficulty (aka Block75) - 2025-09-26T15:53:04.787491+00:00 + 2025-10-11T21:59:26.139545+00:00 python-feedgen Tom Harding 2016-12-19 01:42:38+00:00 @@ -101,10 +101,11 @@ + 2 Combined summary - Managing block size the same way we do difficulty (aka Block75) - 2025-09-26T15:53:04.787655+00:00 + 2025-10-11T21:59:26.139748+00:00 2016-12-19T01:42:38+00:00 In a discussion on the bitcoin-dev mailing list, participants were discussing the Block75 proposal, which allows miners to determine the maximum block size. One participant expressed concern about the linear growth proposed by Block75 and the potential for miners to manipulate their block content. James argued that allowing miners to choose the block size would incentivize them to include legitimate transactions while keeping the block small enough to propagate effectively.Another user disagreed with Andrew Johnson's assertion that an attack on the proposal would be easily detectable. They explained that intentionally orphaning a block would only make sense if 51% of the hash rate was intentionally orphaning it. The conversation also touched on the possibility of miners creating transactions to themselves and not broadcasting them to the network. However, this tactic is easily detectable by other miners who may intentionally orphan blocks that contain unknown transactions.The discussion also delved into the impact of Block75 on transaction fees. James Hilliard explained that there will always be transactions available to mine, and users can stop miners from continuously increasing block size by not sending transactions. James expressed concern that miners will increase block sizes to maximize fees, but it was clarified that Block75 is not exponential scaling and the maximum increase in the first year would be 7x.On December 11, 2016, an email thread discussed the proposed Block75 solution for scaling Bitcoin. The author argued that Block75 is not exponential scaling and would only increase by a maximum of 7x in the first year, followed by slower increases in subsequent years. Critics raised concerns about system instability and block propagation time due to dynamically increasing the maximum block size based on transaction volume.Bram Cohen compared the Block75 approach to Bitcoin Unlimited, highlighting concerns about transaction fees. However, Block75 aims to maintain transaction fees and a fee market, albeit at lower levels than current fees. The proposal offers a way to manage block size automatically without human intervention.In another discussion, t. khan introduced the concept of Block75, which focuses on keeping blocks 75% full instead of enforcing a maximum block size. Some members argued that this effectively removes the block size limit and fails to differentiate between genuine transactions and low-value spam attacks. Concerns were raised about miners imposing their own cap on block size and potential forks.Daniele Pinna asked about objective measures to estimate the probability of orphaned blocks based on network bandwidth and block size. Pieter Wuille responded by stating that models can predict orphan rates based on certain factors but noted that topology cannot be controlled.The Block75 proposal suggests adjusting the maximum block size every two weeks based on transaction volume, aiming to keep blocks at 75% total capacity over each two-week period. Concerns were raised about block propagation time, potential miner manipulation, and the need for a consensus rule on the maximum block size. Despite these concerns, Block75 provides an automated and scalable solution to manage block size. diff --git a/static/bitcoin-dev/Dec_2016/combined_Multisig-with-hashes-instead-of-pubkeys.xml b/static/bitcoin-dev/Dec_2016/combined_Multisig-with-hashes-instead-of-pubkeys.xml index 4421f15c15..6e121c764a 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Multisig-with-hashes-instead-of-pubkeys.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Multisig-with-hashes-instead-of-pubkeys.xml @@ -2,7 +2,7 @@ 2 Combined summary - Multisig with hashes instead of pubkeys - 2025-09-26T15:53:09.014644+00:00 + 2025-10-11T21:59:30.389926+00:00 python-feedgen Matthew Roberts 2016-12-23 18:21:43+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Multisig with hashes instead of pubkeys - 2025-09-26T15:53:09.014802+00:00 + 2025-10-11T21:59:30.390059+00:00 2016-12-23T18:21:43+00:00 In the field of cryptography, Lamport Signatures offer a method to sign a message solely using hash functions. This approach involves exchanging a table of hashes before signing a message and then revealing the corresponding "secrets" behind these hashes. By selectively masking the bits of the message hash, one can effectively sign specific portions of the message. Notably, Lamport Signatures are both elegant and quantum secure.However, relying solely on hashes in this scheme presents a vulnerability, as anyone could obtain these values and potentially double spend the original transaction by redirecting it to a different destination. To address this concern, a similar smart contract algorithm called "atomic cross-chain contracts" utilizes hash values for protocol-based coin swapping across blockchains while employing ECDSA public keys to prevent double-spending.In the case of Bitcoin multi-signature transactions, the use of hash values is viable, but additional protection is required to safeguard against attackers on the network. For instance, including an ECDSA public key alongside the hash values would enhance security. Nonetheless, if one desires to incorporate Lamport Signatures into their consensus system, it is necessary for the system to comprehend Lamport signature operations within the "scriptPubKey." The specific use-case for this integration remains unspecified.Addressing a user named Andrew's query regarding a scriptPubKey for conducting multisig with only participant hashes, it was pointed out that the proposed script had several issues. Firstly, performing two OP_SWAP operations consecutively would simply revert to the original state. Moreover, all the hashes generated in the script ended up hashing the same key, making it susceptible to being spent by anyone on the network. Instead, it was suggested that utilizing P2SH (Pay-to-Script-Hash) scripts would offer better security by preventing the exposure of public keys until spending occurs.To further assist Andrew, the email provided a resource link to learn more about opcodes and simulators. The poster also requested either a confirmed solution or a link to a worked-out script for the scriptSig, which is not included in the provided information. diff --git a/static/bitcoin-dev/Dec_2016/combined_New-BIP-Hardfork-warning-system.xml b/static/bitcoin-dev/Dec_2016/combined_New-BIP-Hardfork-warning-system.xml index d9e520db86..89e70a879c 100644 --- a/static/bitcoin-dev/Dec_2016/combined_New-BIP-Hardfork-warning-system.xml +++ b/static/bitcoin-dev/Dec_2016/combined_New-BIP-Hardfork-warning-system.xml @@ -2,7 +2,7 @@ 2 Combined summary - New BIP: Hardfork warning system - 2025-09-26T15:53:06.901884+00:00 + 2025-10-11T21:59:28.267548+00:00 python-feedgen Jorge Timón 2016-12-02 06:35:36+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - New BIP: Hardfork warning system - 2025-09-26T15:53:06.902060+00:00 + 2025-10-11T21:59:28.267690+00:00 2016-12-02T06:35:36+00:00 On December 2, 2016, Jorge Timón proposed a new Bitcoin Improvement Proposal (BIP) that aims to warn users of a hard fork when a block is invalid. The proposal suggests implementing a soft fork that would hold back at the best-common block between the best-valid chain and the invalid chain, forcing the user to decide whether to reject the invalid chain permanently or upgrade to a version that understands the chain as valid. The proposal also discusses the use of a prohibited bit to signal a soft-hardfork while distinguishing it from a regular hardfork. Nodes implementing this BIP would view it as a simple hardfork but intentionally provide equivalent behavior as older nodes that see it as a soft-hardfork. This proposal could potentially make it easier to resist an un-consented-to hardfork and may eliminate the need for a soft-hardfork design in the future.In a separate discussion on December 1, 2016, Johnson Lau emphasized the necessity for any Bitcoin implementation supporting a softfork to implement a hardfork warning system. Lau argued that if a generalized block header chain with non-trivial total proof-of-work is emerging and not considered a valid blockchain, a hardfork with unknown rules may be occurring. Lau proposed that wallet implementations issue warnings to users and stop processing transactions until further instructions are given. Mining implementations should also issue warnings to operators and may either stop mining or ignore the hardfork with unknown rules. Light nodes, such as wallet implementations, should observe hardfork notification bits in block headers and issue warnings to their users if any of the bits are set. Lau also noted that various types of hardforks can be detected by the warning system, including changes to the Merkle root hash field, block content validation rules, and the introduction of secondary proof-of-work.Johnson Lau's proposal involves changing consensus rules related to block nVersion and creating a concept of a generalized block header to implement a hardfork warning system for both full nodes and light nodes. The hardfork warning system is responsible for informing users that a hardfork may be happening and prompting them for further instructions. However, it does not guarantee the success of the hardfork or prevent the creation of two permanent incompatible forks. The proposal provides specifications for a block nVersion softfork and the validation of a generalized block header. It also outlines the terms used in the proposal and clarifies the limitations of the warning system.Overall, these proposals highlight the ongoing discussions within the Bitcoin community regarding the use of softforks and hardforks to introduce new features or address consensus disagreements. The implementation of a hardfork warning system aims to provide users with the necessary information and prompts to navigate potential hardfork situations effectively. diff --git a/static/bitcoin-dev/Dec_2016/combined_Planned-Obsolescence.xml b/static/bitcoin-dev/Dec_2016/combined_Planned-Obsolescence.xml index 765335c711..f399070223 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Planned-Obsolescence.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Planned-Obsolescence.xml @@ -2,7 +2,7 @@ 2 Combined summary - Planned Obsolescence - 2025-09-26T15:53:00.562333+00:00 + 2025-10-11T21:59:21.891302+00:00 python-feedgen Btc Drak 2016-12-19 06:39:46+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - Planned Obsolescence - 2025-09-26T15:53:00.562500+00:00 + 2025-10-11T21:59:21.891507+00:00 2016-12-19T06:39:46+00:00 A Bitcoin developer, Matt Corallo, is urging people to report bugs to the Bitcoin Github repository, emphasizing that if bugs aren't reported, they won't get fixed. One user, Alice Wonder, almost didn't update to version 0.13.0 due to Python errors in the test suite. She stated that she will only upgrade when the test suite works in her environment and urged others to report bugs as well. The lack of Python 3 dependency on older CentOS builds could be a reason for node operator's lack of client upgrades.Juan Garavaglia expressed concern over the significant number of node operators who do not update their clients. He mentioned that he almost did not update to version 0.13.0 due to failing python errors in the test suite, and when version 0.13.1 was released with new python errors, he decided not to upgrade at all. Garavaglia will only upgrade when the test suite works in his standard environment (CentOS) and will not run clients that have not passed the test suite.The Bitcoin community is discussing the issue of developer centralization and finding the right balance between software upgrades. Concerns were raised about nodes not applying patches, making them vulnerable to exploits, and older nodes becoming obsolete and incompatible with new upgrades, leading to network fragmentation. Planned obsolescence in new versions of Bitcoin Core node was suggested to avoid fragmentation, but others felt that this may not be the best solution as anti-features can easily be removed. Instead, users should be left to determine when to upgrade, although security updates should be encouraged. It is recognized that developers have limited resources and are unlikely to give support for older versions.The difficulty of encouraging users to upgrade their node versions to avoid compatibility issues and security vulnerabilities is being discussed. Suggestions include implementing a message system to notify users of available updates and potential risks, automatically distributing patches and updates, and introducing planned obsolescence in each new version of Bitcoin Core. However, concerns were raised about the effectiveness of these approaches and the potential for anti-features to be removed. A simpler solution would be to stop supporting older versions, as developers have limited resources and rarely fix bugs for outdated software.Juan Garavaglia has proposed implementing planned obsolescence in each new version of Bitcoin Core node software to avoid fragmentation and simplify developers' jobs. The suggestion recommends that after a new version is released, it remains valid for approximately one year before becoming obsolete and incompatible with the network. If a node does not upgrade, it will stop working instead of participating with an outdated protocol version. However, some users may remove anti-features from free software. A simpler solution, such as stopping maintenance and support for older versions, has been suggested in response to this proposal.The size of the Bitcoin network in terms of full nodes is decreasing rapidly, raising concerns about its decentralization. The lack of incentive for people to run full nodes and upgrade their clients is a major issue that has not been discussed enough. It is noted that over 30% of nodes running Bitcoin Core are using versions older than 0.13.0, indicating that many node operators do not upgrade. Introducing planned obsolescence in each new version and addressing the lack of incentives may help solve these issues.According to statistics, the majority of Bitcoin running node versions are older than 0.13.1, indicating that many node operators do not upgrade their clients. Newer versions require the same or fewer hardware resources to run compared to older versions, and introducing planned obsolescence in each new version is worth considering to avoid fragmentation and simplify the developer's job. If a node does not upgrade, it will stop working instead of participating with an outdated protocol version. diff --git a/static/bitcoin-dev/Dec_2016/combined_Python-test-suite-failures-was-Re-Planned-Obsolescence-.xml b/static/bitcoin-dev/Dec_2016/combined_Python-test-suite-failures-was-Re-Planned-Obsolescence-.xml index 7939122145..7e68e91525 100644 --- a/static/bitcoin-dev/Dec_2016/combined_Python-test-suite-failures-was-Re-Planned-Obsolescence-.xml +++ b/static/bitcoin-dev/Dec_2016/combined_Python-test-suite-failures-was-Re-Planned-Obsolescence-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Python test suite failures (was Re: Planned Obsolescence) - 2025-09-26T15:53:11.127328+00:00 + 2025-10-11T21:59:32.512848+00:00 python-feedgen Marco Falke 2016-12-21 18:33:14+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Python test suite failures (was Re: Planned Obsolescence) - 2025-09-26T15:53:11.127475+00:00 + 2025-10-11T21:59:32.512989+00:00 2016-12-21T18:33:14+00:00 The error message in question is from version 0.13.1 of Bitcoin, specifically related to the "bitcoin-util-test.py" file. The traceback indicates that the problem lies within the "bctest.py" file, where a line of code attempting to read output data from a file is causing a FileNotFoundError due to the specified file not being found in the directory. This issue was previously known on the master branch. Users encountering similar issues with the current 0.13.2 release candidate are advised to report it on the Bitcoin GitHub issues page, along with their CentOS version.In a thread on bitcoin-dev, Alice Wonder expressed her hesitation to update to version 0.13.0 of Bitcoin due to failing tests caused by Python errors. She mentioned that these issues were addressed on bitcointalk, but new Python errors arose in version 0.13.1, leading her to abandon the update entirely. When asked for more details about the encountered issues, Alice explained that the main cause was the LANG environment variable and had to set it to "en_US.utf8" before running the test suite for version 0.13.0. However, she noted that this issue was resolved in version 0.13.1. The errors in version 0.13.1 occurred during the execution of the "bitcoin-util-test.py" file, resulting in a traceback error. The error message indicated that the test failed because it couldn't find the file "./test/data/blanktx.json", resulting in an Error 1. Alice also mentioned that she builds in a clean chroot build environment to avoid linking to non-standard libraries and that the LANG environment variable typically doesn't affect software compilation. Despite these challenges, Alice reported that version 0.13.0 worked fine once the LANG variable was set to "en_US.utf8".In a post on the bitcoin-dev mailing list, Alice Wonder expressed her frustration with testing errors in Bitcoin Core updates. She nearly decided against updating to version 0.13.0 due to Python errors in the test suite, which were eventually resolved by following instructions on bitcointalk. However, she encountered new Python errors in version 0.13.1 and chose not to update until the test suite functions properly in her CentOS environment. Douglas Roark requested more information about these issues and offered assistance, suggesting that posting an issue on Github would be beneficial. diff --git a/static/bitcoin-dev/Dec_2019/combined_Reducing-energy-consumption-and-increasing-security-at-the-same-time.xml b/static/bitcoin-dev/Dec_2019/combined_Reducing-energy-consumption-and-increasing-security-at-the-same-time.xml index c19c015d9d..6a137370f2 100644 --- a/static/bitcoin-dev/Dec_2019/combined_Reducing-energy-consumption-and-increasing-security-at-the-same-time.xml +++ b/static/bitcoin-dev/Dec_2019/combined_Reducing-energy-consumption-and-increasing-security-at-the-same-time.xml @@ -2,7 +2,7 @@ 2 Combined summary - Reducing energy consumption and increasing security at the same time - 2025-09-26T16:02:09.158074+00:00 + 2025-10-11T22:15:44.087909+00:00 python-feedgen Cheng Wang 2019-12-09 09:47:49+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Reducing energy consumption and increasing security at the same time - 2025-09-26T16:02:09.158231+00:00 + 2025-10-11T22:15:44.088056+00:00 2019-12-09T09:47:49+00:00 Cheng Wang, the founder of Alephium, has introduced a novel algorithm called Proof of Linear Work (PoLW) to address the issue of high energy consumption in Proof of Work (PoW) while maintaining security. PoLW allows miners to sacrifice a portion of their coinbase rewards in exchange for weight in the block hash they produce. This approach aims to shift some of the external costs of mining, primarily energy consumption, to the internal cost of the network.In his paper, Cheng outlines two variations of the PoLW algorithm: linear PoLW and exponential PoLW. Linear PoLW is projected to reduce energy consumption by approximately 50% in equilibrium, while exponential PoLW has the potential to achieve even greater reductions. The equilibrium state ensures that the total cost of generating a new block remains equal to the maximal coinbase reward.Runchao Han had raised concerns about double spending and transaction fees in relation to PoLW. Cheng addresses these concerns by proposing a dynamic upper bound on the amount of coinbase reward miners can sacrifice, which is based on the actual mining difficulty of the recent epoch. Additionally, if the value of Bitcoin becomes comparable to gold, miners could be allowed to give up more rewards. To handle transaction fees, PoLW could eliminate the halving mechanism, as it already adjusts adaptively.Cheng emphasizes that his work is grounded in solid mathematical calculations and invites feedback and discussions. His paper can be accessed at https://github.com/alephium/research/raw/master/polw.pdf. It is worth noting that Cheng's research was inspired by a recent paper authored by Itay, Alexander, and Ittay, available at https://arxiv.org/abs/1911.04124.While Cheng acknowledges that immediate reduction of external costs in existing systems may not be feasible, the principle behind implementing PoLW is to continually increase the absolute external cost while gradually reducing its percentage in the total cost. As a result, transitioning from PoW to PoLW would lead to decreased external costs and increased internal costs, ultimately contributing to enhanced security. diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Review-of-Smart-Contract-Concepts.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Review-of-Smart-Contract-Concepts.xml index f8d508ddd6..fc196bd764 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Review-of-Smart-Contract-Concepts.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-Review-of-Smart-Contract-Concepts.xml @@ -2,7 +2,7 @@ 2 Combined summary - [Bitcoin Advent Calendar] Review of Smart Contract Concepts - 2025-09-26T15:31:19.620376+00:00 + 2025-10-11T21:32:00.795281+00:00 python-feedgen Prayank 2021-12-23 11:55:31+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - [Bitcoin Advent Calendar] Review of Smart Contract Concepts - 2025-09-26T15:31:19.620581+00:00 + 2025-10-11T21:32:00.795469+00:00 2021-12-23T11:55:31+00:00 The blog post by Jeremy Rubin explores various high-level smart contract concepts related to different opcodes or proposals. The author begins by discussing the concept of recursion in programming, also known as "Turing Complete". To help remember this concept, the author references an Indian movie titled 'Karthik calling Karthik'. Moving on, the limitations of unrolling loops are addressed, particularly when choices are introduced, leading to exponential blowup. However, the author notes that clever and careful programmers can mitigate this complexity through memoization. The author agrees with these limitations and acknowledges the possibility of optimization.The conversation then delves into the distinction between fully enumerated and open-ended contract cases. In the latter, dynamic specification of bits and pieces is permitted. An intriguing example is provided where Alice is paid 1 BTC by December 25th, 2021 Midnight, and subsequently transfers 100 tokens to one of Bob's addresses at his discretion.Towards the end of the blog post, the author shares a newfound knowledge about signing the transaction fee rate as a function of locktime. This adds another layer of understanding to the subject matter.Overall, the blog post by Jeremy Rubin covers a range of smart contract concepts, discussing recursion, limitations of unrolling loops, open-ended contract cases, and transaction fee rate signing. The author encourages readers to share their thoughts on other relevant properties. The post was published on December 4, 2021, and is accessible on rubin.io. diff --git a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-What-s-Smart-about-Smart-Contracts.xml b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-What-s-Smart-about-Smart-Contracts.xml index 0969ddc3ee..7cd87dd0c1 100644 --- a/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-What-s-Smart-about-Smart-Contracts.xml +++ b/static/bitcoin-dev/Dec_2021/combined_-Bitcoin-Advent-Calendar-What-s-Smart-about-Smart-Contracts.xml @@ -2,7 +2,7 @@ 2 Combined summary - [Bitcoin Advent Calendar] What's Smart about Smart Contracts - 2025-09-26T15:31:15.417854+00:00 + 2025-10-11T21:31:58.667527+00:00 python-feedgen Prayank 2021-12-23 09:42:02+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - [Bitcoin Advent Calendar] What's Smart about Smart Contracts - 2025-09-26T15:31:15.418020+00:00 + 2025-10-11T21:31:58.667696+00:00 2021-12-23T09:42:02+00:00 In his day 6 post, Bitcoin developer Jeremy Rubin emphasizes the importance of smart contracts as a critical precursor to securing Bitcoin's future. He addresses several differences between Bitcoin and Ethereum that impact the fee market, including block size, block limit, UTXO vs account model, failed transactions, and the need for nodes to run smart contracts. Rubin also highlights that various platforms, such as stablecoins, DEX, NFT platforms, CEX, and VCs, are all paying fees.He further discusses other factors influencing the fee market, such as darknet markets using Monero, stablecoins no longer using Omni, and the majority of transactions being related to exchanges. Additionally, he notes that new users are primarily interested in quick riches rather than technologies like DeFi that could enhance the Bitcoin ecosystem. Rubin also mentions that projects like DLCs have not yet been implemented in high-volume projects.The article explores the concept of "smart" contracts, which enforce themselves without requiring a third party. The author proposes a redesign in Bitcoin terms to include a "default branch" that automatically executes when the future block height arrives. However, the author cautions that any changes to the programming model can introduce bugs that may undermine the "smartness" of the contracts. The N-of-N rule is discussed, highlighting the challenges of decentralized coordination-free mining pools when all participants must be online. Ultimately, the article emphasizes the need to improve the hardware supporting Bitcoin to enhance its ability to facilitate value transfers.Responding to ZmnSCPxj's critique, Rubin clarifies that his discussion revolves around the community's definition of smart contracts, focusing on enhanced functionality rather than true self-enforcement. He suggests pursuing improvements in the hardware running Bitcoin to strengthen its ability to adjudicate transfers of value. Rubin also touches upon the N-of-N rule, cautioning against its exclusive use due to potential obstacles for decentralized mining pools. Instead, he advocates for enhancing Bitcoin's scalability, privacy, self-custody, and decentralization to solidify its adjudication of value transfers.In his one-a-day blog post series until Christmas, Rubin shares his insights on Bitcoin development. He acknowledges that the initial posts are more philosophical but recommends readers start from Day 6 for relevant Bitcoin development discussions. Rubin plans to post the remaining entries up to Day 10 on the platform, providing an archive of all posts at https://rubin.io/archive/. The day 6 post specifically delves into the significance of smart contracts as a crucial element in securing Bitcoin's future, rather than an afterthought following base layer improvements. diff --git a/static/bitcoin-dev/Dec_2021/combined_A-fee-bumping-model.xml b/static/bitcoin-dev/Dec_2021/combined_A-fee-bumping-model.xml index 47a84174a6..4338dda09f 100644 --- a/static/bitcoin-dev/Dec_2021/combined_A-fee-bumping-model.xml +++ b/static/bitcoin-dev/Dec_2021/combined_A-fee-bumping-model.xml @@ -2,7 +2,7 @@ 2 Combined summary - A fee-bumping model - 2025-09-26T15:31:09.126709+00:00 + 2025-10-11T21:31:56.538129+00:00 python-feedgen Peter Todd 2021-12-09 13:50:33+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - A fee-bumping model - 2025-09-26T15:31:09.126864+00:00 + 2025-10-11T21:31:56.538294+00:00 2021-12-09T13:50:33+00:00 emails discussing the topic. It also mentions the idea of creating an insurance project for the LGBTQ community in India and shares a presentation by Jack Mallers on creating derivatives to hedge fees.In summary, the discussions and articles revolve around the importance of fee-bumping strategies for the security and efficiency of protocols built on Bitcoin. The challenges of fee estimation, confirmation of transactions, and overpayments are addressed, along with proposed solutions such as presigned transactions, reserve feerates, and consolidation with fanout. The need for accurate fee estimation, policy-level mitigations, new consensus rules, and potential insurance markets are emphasized throughout the conversations and articles. diff --git a/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml b/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml index b2a8446ba3..1541d0bf4b 100644 --- a/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml +++ b/static/bitcoin-dev/Dec_2022/combined_-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger-angus-.xml @@ -2,7 +2,7 @@ 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) - 2025-09-26T15:33:07.157101+00:00 + 2025-10-11T21:42:29.963281+00:00 python-feedgen Anthony Towns 2022-12-13 12:55:08+00:00 @@ -30,10 +30,11 @@ + 2 Combined summary - [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) - 2025-09-26T15:33:07.157262+00:00 + 2025-10-11T21:42:29.963433+00:00 2022-12-13T12:55:08+00:00 The bitcoin-dev mailing list is currently engaged in a discussion about Full RBF (Replace-by-Fee) and its potential impact on mempool policy. Advocates for Full RBF argue that relying on predictable mempool policy is not advisable, as miners will always prioritize optimizing fees in the short term. This could lead to a scenario where miners advertise how to connect to their nodes, allowing those who prefer higher fee transactions to send them directly. However, this assumption is not an economic fact of life, as there are alternative options such as stablecoins or ETH that users could switch to, resulting in a substantial drop in bitcoin traffic, transaction fees, and price.The outcome of implementing Full RBF is uncertain in terms of its effect on the desirability of bitcoin and its price. The use of BTC for payments may shift towards lightning network, causing a reduction in on-chain traffic and fee income. The author emphasizes the importance of prioritizing long-term income over immediate revenue to prevent 51% attacks from becoming a dominant strategy. Consistent and predictable relay policy across nodes remains possible regardless of whether the policy follows the "first seen is final, highest fee rate wins" principle or something else. The author sees Full RBF as a way to eliminate a use-case that carries risk, ultimately strengthening Bitcoin. However, they disagree with preventing others from voluntarily taking on small risks that can be easily managed or avoided. The author clarifies that "money for enemies" refers to empowering the majority rather than an elite minority within the Bitcoin community.Regarding the claim that RBF is a fee-minimization feature, the author responds by highlighting the economics of the situation. Fees serve as a price on confirmation, and there exists an optimum price where total earnings vs price reaches a peak. RBF optimizes the discovery of this optimum price, which is desirable. However, many merchants and consumers reject opt-in-RBF, necessitating the need for full-RBF to improve price discovery of blockspace when such acceptors are prevalent. The author also disputes the implication that demand follows supply, asserting that if Bitcoin offers less utility, it will experience reduced demand regardless of its optimization for capacity saturation. The optimal state is achieved by providing the most value per blockspace per time period. Zero-conf transactions currently generate added demand for blockspace from merchants and consumers due to their qualification for zero-conf acceptance based on fee rates.A discussion on full RBF highlights its alignment with miner and user economic incentives. However, this argument can be refuted as RBF primarily serves as a fee-minimization feature, resulting in lower earnings for miners. Additionally, nodes providing replacement service and propagation incur expenses. The author emphasizes that fees are the price of confirmation and applies the concept of "price theory" where an optimum price may be lower than the prevailing market price. Therefore, RBF optimizes the discovery of this optimum price, but many zero-conf acceptors reject opt-in-RBF despite its improved price discovery. Thus, full-RBF becomes necessary in such cases.There exists a fundamental disagreement regarding Full RBF. Supporters perceive it as a means to eliminate the risk associated with zero-conf transactions, while opponents believe that relying on predictable mempool policy has worked well thus far. Those in favor argue that node policy is not a consensus rule, and changing mempool policy is essential to actively discourage zero-conf. Opponents contend that zero-conf acceptance is already widely used and valuable, and full-RBF can be discarded if the majority of node operators do not care about it. The economic incentive argument currently holds little significance, and there remains an obvious incentive for someone to attempt a double-spend attack on a zero-conf merchant. Angus suggests that accepting zero-conf changes from being tolerated with occasional issues to being strongly discouraged due to potential financial losses. For now, Angus supports running a full-RBF node, considering it a measure that strengthens Bitcoin. However, he is open to reversing his stance if a strong economic argument convinces him and other miners or users to oppose full-RBF.While many proponents of zero-conf focus on supporting Lightning as an alternative, the author argues that Lightning is not without risks and should not be solely relied upon for commercial payments. Lightning is suitable for low-value payments due to the current low-fee environment's lack of scalability. However, for high-value payments, zero-conf has never been valuable or useful and likely never will be. The author highlights instances where double-spends of zero-conf transactions without RBF have been repeatedly demonstrated, emphasizing the absence of a long-term scenario where zero-conf holds value. Although low fees may seem appealing, they incentivize network-wide surveillance, increase the burden on nodes, and promote unsustainable practices resembling a "mev" (miner-extractable value) bounty for merchants. Nevertheless, the author identifies the risk involved in waiting 20 minutes before shipping items as insignificant, with the only potential issue being a user replacing a transaction with a different destination. Even if such an event were to diff --git a/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml b/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml index ad4804b16d..887628d9b7 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Fwd-Opt-in-full-RBF-Zero-conf-apps-in-immediate-danger.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger - 2025-09-26T15:33:11.378868+00:00 + 2025-10-11T21:42:34.211062+00:00 python-feedgen Peter Todd 2022-12-06 05:03:56+00:00 @@ -14,10 +14,11 @@ + 2 Combined summary - Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger - 2025-09-26T15:33:11.379023+00:00 + 2025-10-11T21:42:34.211213+00:00 2022-12-06T05:03:56+00:00 The bitcoin-dev community is currently discussing the use of a different nVersion to signal full-rbf in multi-party transactions such as coinjoin and contracting protocols like Lightning. Originally, this option was proposed to address a DoS vector affecting these use-cases. However, alternative solutions have been developed that also solve this issue but have their own trade-offs and privacy concerns.One of the proposals suggests that multi-party protocols use a different nVersion to signal full-rbf in their transactions. However, this approach negatively impacts privacy by making it easier for bad actors to deanonymize transactions. Single-party wallets are discouraged from using this option due to complaints from services like Bitrefill about RBF transactions. Designing a protocol without harming privacy seems impossible, as it would require zeroconf services to determine whether a txout has opted into full-rbf while preventing Chainalysis services from doing the same.The decision on how to balance the interests of centralized services and other users regarding privacy tradeoffs needs to be made by the community. Another v3 proposal also presents similar privacy issues, but there may be potential ways to avoid this impact through mempool design.Antoine's message addresses Daniel, who operates a zero-conf risk analysis business. Antoine expresses concerns about the deployment of fullrbf, which could lower the cost of double-spend attacks and increase risk exposure for users. He questions the statistics on the 1.5M transactions per month received by Daniel's business, specifically asking how many are Bitcoin-only transactions excluded from zeroconf due to factors like RBF, long-chain of unconfirmed ancestors, or high value. Antoine also asks about the average feerate.Antoine shares his personal position on fullrbf deployment, as expressed in #26525, stating that there is still no consensus on deploying or removing it. He believes that before considering removing the current option from Bitcoin Core, the community needs to determine the qualification of enough economic flows at risk and the presence of a significant loss in miners' income. He also raises the question of whether the Bitcoin protocol development community should limit user choice in policy settings to preserve mining income and established use-case stability.The original technical motivation for the fullrbf option was to address a DoS vector affecting multi-party transactions like coinjoin and contracting protocols like Lightning. However, alternative solutions have been proposed since then, each with their own trade-offs and conceptual issues. Antoine provides links to previous discussions on these matters, emphasizing the potential risks associated with fullrbf deployment and the importance of balancing user choice with preserving mining income and established use-case stability. diff --git a/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml b/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml index 96bfa855a3..0cdc7ad445 100644 --- a/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml +++ b/static/bitcoin-dev/Dec_2022/combined_Pseudocode-for-robust-tail-emission.xml @@ -2,7 +2,7 @@ 2 Combined summary - Pseudocode for robust tail emission - 2025-09-26T15:33:13.490486+00:00 + 2025-10-11T21:42:36.338496+00:00 python-feedgen jk_14 at op.pl 2023-02-01 22:04:11+00:00 @@ -70,10 +70,11 @@ + 2 Combined summary - Pseudocode for robust tail emission - 2025-09-26T15:33:13.490630+00:00 + 2025-10-11T21:42:36.338653+00:00 2023-02-01T22:04:11+00:00 In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the diff --git a/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml b/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml index 0101b084d7..04eb22722d 100644 --- a/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml +++ b/static/bitcoin-dev/Dec_2022/combined_bitcoin-dev-Digest-Vol-91-Issue-5.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 91, Issue 5 - 2025-09-26T15:33:15.604949+00:00 + 2025-10-11T21:42:38.462592+00:00 python-feedgen Antoine Riard 2022-12-06 04:06:34+00:00 @@ -14,10 +14,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 91, Issue 5 - 2025-09-26T15:33:15.605122+00:00 + 2025-10-11T21:42:38.462766+00:00 2022-12-06T04:06:34+00:00 Antoine Riard has proposed the removal of the "mempoolfullrbf" feature from Bitcoin Core, citing potential impacts on various use-cases such as on-chain payments, Lightning, and coinjoins. He acknowledges that this decision should follow the same process as any code change, considering factors such as ecosystem impact and utility. While he recognizes the potential benefits for wallets and multi-party applications/contracting protocols, Antoine also sees a lowering of the technical bar for double-spends.A mempool policy design philosophy was suggested to accommodate all Bitcoin use-cases without harming network interests, but concerns remain about miner incentives and potential asymmetries in mining incomes. Antoine believes that removing the "risk-induction" feature is better for the ecosystem, as it alters security expectations for 0conf operators. He suggests that more effective usage data from merchants/service operators would be valuable.The deployment of fullrbf could increase the risk exposure for users of GAP600, a zero-conf risk analysis business integrated with payment processors/liquidity providers and merchants. This increased risk exposure may affect the acceptance of incoming zero-conf transactions. Antoine requests clarification on transaction statistics, such as the number of Bitcoin-only transactions, those excluded from zeroconf, and the average feerate.Antoine maintains his personal position on fullrbf and notes that there is no conceptual consensus within the community on deploying or removing it. He emphasizes the need to address economic flows at risk and potential loss in miners' income before removing the option from Bitcoin Core. Additionally, he questions whether user choice in policy settings should be restrained to preserve mining income and established use-case stability.The original technical motivation for the mempoolfullrbf option was to address a denial-of-service (DoS) vector affecting multi-party transactions like coinjoin and contracting protocols such as Lightning. However, alternative solutions with their own trade-offs and conceptual issues have since been devised. John Carvalho, CEO of Synonym.to, supports zero-conf support for Lightning Network adoption, as it reduces friction and allows for instant, seamless user experiences within wallets. diff --git a/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml b/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml index 9595dc5fd1..7aa81cd5e2 100644 --- a/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml +++ b/static/bitcoin-dev/Dec_2022/combined_onion-addresses-to-try-At-least-17-of-Bitcoin-Core-24-x-listening-nodes-are-running-full-rbf-.xml @@ -2,7 +2,7 @@ 2 Combined summary - onion addresses to try [At least 17% of Bitcoin Core 24.x listening nodes are running full-rbf] - 2025-09-26T15:33:09.269075+00:00 + 2025-10-11T21:42:32.086110+00:00 python-feedgen Peter Todd 2022-12-23 09:46:19+00:00 @@ -14,10 +14,11 @@ + 2 Combined summary - onion addresses to try [At least 17% of Bitcoin Core 24.x listening nodes are running full-rbf] - 2025-09-26T15:33:09.269232+00:00 + 2025-10-11T21:42:32.086262+00:00 2022-12-23T09:46:19+00:00 In a recent Bitcoin-dev thread, Peter Todd expressed his concern about the lack of easily accessible sources for onion addresses to try. However, Vasil Dimov pointed out that the issue is more complex than it seems at first glance. Dimov highlighted the fact that obtaining onion addresses is inexpensive and trying them without considering their longer-term track record can lead to problems. There is a risk of inadvertently obtaining the addresses associated with a one-time Sybil attack.To address this challenge, Dimov proposed an alternative solution – using DNS seed records instead. These addresses have been tested over extended periods, offering a higher probability of representing genuine nodes. However, Dimov mentioned that his DNS seed is not currently configured to track nodes using Tor, which limits its effectiveness in this context.On December 22, 2022, Peter Todd shared his concerns on the bitcoin-dev forum regarding the limited availability of convenient sources for onion addresses. In response to Todd's post, Vasil Dimov offered a potential solution in the form of a command that can be executed in the terminal. The command, "bitcoin-cli getnodeaddresses 0 |jq -r 'map(select(.network == "onion")) | .[].address'", could help obtain onion addresses for testing purposes.Dimov concluded his email by including a quote emphasizing the importance of living life to the fullest. diff --git a/static/bitcoin-dev/Feb_2012/combined_0-5-2-tag-in-github-.xml b/static/bitcoin-dev/Feb_2012/combined_0-5-2-tag-in-github-.xml index c42aed5a2e..2684256763 100644 --- a/static/bitcoin-dev/Feb_2012/combined_0-5-2-tag-in-github-.xml +++ b/static/bitcoin-dev/Feb_2012/combined_0-5-2-tag-in-github-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.5.2 tag in github ?? - 2023-08-01T03:16:50.683557+00:00 + 2025-10-11T22:18:14.947370+00:00 + python-feedgen Gregory Maxwell 2012-02-03 13:45:30+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - 0.5.2 tag in github ?? - 2023-08-01T03:16:50.683557+00:00 + 2025-10-11T22:18:14.947555+00:00 - In a 2012 email conversation, Aidan Thornton expressed uncertainty about the location of a specific tag for the stable version of Bitcoin's codebase. He speculated that "developer politics" may have been involved and suggested that v0.5.2 may not have been pushed to the official Github repository. However, it was clarified in response that no such politics were at play, and cuts to stable versions were always made from Luke's repository since he maintained it.Meanwhile, Michael Gronager, a director at Ceptacle, was attempting to redo a performance test of the libcoin client against the 0.5.2 Satoshi client, which had seen improvements in speed compared to version 0.4.0. However, he encountered difficulty in finding the v0.5.2 tag on Github. Aidan Thornton suggested that the tag might be located in a different repository and hinted at potential developer politics. Additionally, Michael inquired about the addition of new checkpoints and questioned if there was any policy or logic behind it, noting that the number could potentially be raised to 160000 by now.To further clarify the situation, Michael Grønager, a developer, sought to redo the performance test of the libcoin client against the 0.5.2 Satoshi client, which had experienced significant speed improvements since version 0.4.0 by not verifying signatures on early blocks. However, he was unable to locate any tag with v0.5.2 in Github's repository. Michael wondered if he was missing something or if the release had not been properly tagged. Specifically, he was searching for the number "140700," which represented the last block not verified and could be found in checkpoints.cpp. Nevertheless, he desired confirmation that this was indeed the number used in version 0.5.2. 2012-02-03T13:45:30+00:00 + In a 2012 email conversation, Aidan Thornton expressed uncertainty about the location of a specific tag for the stable version of Bitcoin's codebase. He speculated that "developer politics" may have been involved and suggested that v0.5.2 may not have been pushed to the official Github repository. However, it was clarified in response that no such politics were at play, and cuts to stable versions were always made from Luke's repository since he maintained it.Meanwhile, Michael Gronager, a director at Ceptacle, was attempting to redo a performance test of the libcoin client against the 0.5.2 Satoshi client, which had seen improvements in speed compared to version 0.4.0. However, he encountered difficulty in finding the v0.5.2 tag on Github. Aidan Thornton suggested that the tag might be located in a different repository and hinted at potential developer politics. Additionally, Michael inquired about the addition of new checkpoints and questioned if there was any policy or logic behind it, noting that the number could potentially be raised to 160000 by now.To further clarify the situation, Michael Grønager, a developer, sought to redo the performance test of the libcoin client against the 0.5.2 Satoshi client, which had experienced significant speed improvements since version 0.4.0 by not verifying signatures on early blocks. However, he was unable to locate any tag with v0.5.2 in Github's repository. Michael wondered if he was missing something or if the release had not been properly tagged. Specifically, he was searching for the number "140700," which represented the last block not verified and could be found in checkpoints.cpp. Nevertheless, he desired confirmation that this was indeed the number used in version 0.5.2. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_Announcement-libcoin.xml b/static/bitcoin-dev/Feb_2012/combined_Announcement-libcoin.xml index 8ec33e056b..693400a682 100644 --- a/static/bitcoin-dev/Feb_2012/combined_Announcement-libcoin.xml +++ b/static/bitcoin-dev/Feb_2012/combined_Announcement-libcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.669593+00:00 + 2025-10-11T22:18:19.193983+00:00 + python-feedgen Martinx - ジェームズ 2012-09-12 23:27:32+00:00 @@ -207,13 +208,13 @@ - python-feedgen + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.670592+00:00 + 2025-10-11T22:18:19.194188+00:00 - In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, 2012-09-12T23:27:32+00:00 + In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_Anything-to-chat-about-today-at-21-00-UTC-.xml b/static/bitcoin-dev/Feb_2012/combined_Anything-to-chat-about-today-at-21-00-UTC-.xml index 0a621c7f37..f4aa5c5093 100644 --- a/static/bitcoin-dev/Feb_2012/combined_Anything-to-chat-about-today-at-21-00-UTC-.xml +++ b/static/bitcoin-dev/Feb_2012/combined_Anything-to-chat-about-today-at-21-00-UTC-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Anything to chat about today at 21:00 UTC ? - 2023-08-01T03:21:05.121701+00:00 + 2025-10-11T22:18:10.699860+00:00 + python-feedgen D.H. 2012-02-28 19:33:16+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Anything to chat about today at 21:00 UTC ? - 2023-08-01T03:21:05.121701+00:00 + 2025-10-11T22:18:10.699996+00:00 - One suggestion to attract a great Windows developer is to utilize free advertising on StackOverflow for open source projects. The idea is to specifically target Windows developers through this platform. A link provided leads to a meta StackOverflow post discussing open source advertising for sidebar 1H 2012. The poster believes that with some help from the forum, it should not be difficult to get 30 votes for the advertising.Gavin Andresen, a prominent figure in the Bitcoin community, made an announcement on the #bitcoin-development IRC channel about an upcoming Tuesday IRC meeting. The meeting will cover various topics, including the duplicate coinbase attack/fix and the strategy for rolling out sipa's fix. The participants will also discuss the 0.6 release schedule and potential solutions to attract a talented Windows developer who can address ongoing issues. Additionally, the meeting will touch upon the next steps for multisignature and provide updates on who is currently working on what. 2012-02-28T19:33:16+00:00 + One suggestion to attract a great Windows developer is to utilize free advertising on StackOverflow for open source projects. The idea is to specifically target Windows developers through this platform. A link provided leads to a meta StackOverflow post discussing open source advertising for sidebar 1H 2012. The poster believes that with some help from the forum, it should not be difficult to get 30 votes for the advertising.Gavin Andresen, a prominent figure in the Bitcoin community, made an announcement on the #bitcoin-development IRC channel about an upcoming Tuesday IRC meeting. The meeting will cover various topics, including the duplicate coinbase attack/fix and the strategy for rolling out sipa's fix. The participants will also discuss the 0.6 release schedule and potential solutions to attract a talented Windows developer who can address ongoing issues. Additionally, the meeting will touch upon the next steps for multisignature and provide updates on who is currently working on what. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_BIP-13.xml b/static/bitcoin-dev/Feb_2012/combined_BIP-13.xml index 056582c8a4..fa84777fd4 100644 --- a/static/bitcoin-dev/Feb_2012/combined_BIP-13.xml +++ b/static/bitcoin-dev/Feb_2012/combined_BIP-13.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP-13 - 2023-08-01T03:18:49.304289+00:00 + 2025-10-11T22:17:57.946487+00:00 + python-feedgen Luke-Jr 2012-02-22 16:43:53+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BIP-13 - 2023-08-01T03:18:49.305281+00:00 + 2025-10-11T22:17:57.946631+00:00 - On February 22, 2012, Michael Grønager sent an email discussing SCRIPT_ADDRESS_TEST and PUBKEY_ADDRESS_TEST. The value for SCRIPT_ADDRESS_TEST was identified as 196 in decimal or (11000100) in binary. Grønager also mentioned that PUBKEY_ADDRESS_TEST had a value of 111 in decimal or (01101111) in binary. Gavin Andresen agreed with the information shared by Grønager but did not provide any additional comments.The context highlights an issue raised by Michael Gronager regarding Bitcoin Improvement Proposal (BIP) 13. Gronager attempted to implement a bitfield-based parsing of the version byte using Luke-jr's description but found it to be inconsistent with base58.h definitions. Gronager requested help from Gavin Andresen and Luke-jr to resolve this disparity and suggested consolidating discussions on the Bitcoin-dev mailing list. In response, Andresen pointed out a major flaw in Gronager's idea that could allow an attacker to create address collisions.A conversation between Gavin Andresen and another individual focused on distinguishing between the old and new schemes for base58-encoding Bitcoin addresses. It was suggested that if a 1 in 256 old address has a first-byte-of-checksum matching the new address class, the code would compare the 4-byte checksum to determine if it is a singlesig address. However, this scheme could be exploited as a major flaw. The discussion proposed implementing extensions for the next byte to improve the scheme.The context also mentions the importance of following the BIP process when proposing ideas. Steps include posting a rough draft, writing up a draft BIP, posting it for review, and requesting a BIP number from the editor. The author encourages implementing the proposed idea between steps 3 and 4.There is a discussion about the "version" portion of Bitcoin addresses being referred to as the "network id". However, it is noted that it has always been known as the "version" according to Satoshi's reference implementation. The technical background of Bitcoin addresses can be found on the Bitcoin Wiki page.On February 20, 2012, Michael Grønager suggested labeling the "version" portion of Bitcoin addresses as the "network id" to indicate the intended network and chain. However, it was pointed out that it has always been referred to as the "version" and confirmed to be the original intention. The proposal to change the label is currently being discussed on the BIP-13 wiki page.A proposal has been made to change the "network id" portion of Bitcoin addresses back to the original term "version". The proposed structure for Bitcoin addresses would reduce the possibility of using a faulty address from 1 in 4 billion to 1 in 24 million, increasing security. However, old clients would render new addresses useless while maintaining their familiar appearance. This proposal is currently under discussion on the BIP-13 wiki page. 2012-02-22T16:43:53+00:00 + On February 22, 2012, Michael Grønager sent an email discussing SCRIPT_ADDRESS_TEST and PUBKEY_ADDRESS_TEST. The value for SCRIPT_ADDRESS_TEST was identified as 196 in decimal or (11000100) in binary. Grønager also mentioned that PUBKEY_ADDRESS_TEST had a value of 111 in decimal or (01101111) in binary. Gavin Andresen agreed with the information shared by Grønager but did not provide any additional comments.The context highlights an issue raised by Michael Gronager regarding Bitcoin Improvement Proposal (BIP) 13. Gronager attempted to implement a bitfield-based parsing of the version byte using Luke-jr's description but found it to be inconsistent with base58.h definitions. Gronager requested help from Gavin Andresen and Luke-jr to resolve this disparity and suggested consolidating discussions on the Bitcoin-dev mailing list. In response, Andresen pointed out a major flaw in Gronager's idea that could allow an attacker to create address collisions.A conversation between Gavin Andresen and another individual focused on distinguishing between the old and new schemes for base58-encoding Bitcoin addresses. It was suggested that if a 1 in 256 old address has a first-byte-of-checksum matching the new address class, the code would compare the 4-byte checksum to determine if it is a singlesig address. However, this scheme could be exploited as a major flaw. The discussion proposed implementing extensions for the next byte to improve the scheme.The context also mentions the importance of following the BIP process when proposing ideas. Steps include posting a rough draft, writing up a draft BIP, posting it for review, and requesting a BIP number from the editor. The author encourages implementing the proposed idea between steps 3 and 4.There is a discussion about the "version" portion of Bitcoin addresses being referred to as the "network id". However, it is noted that it has always been known as the "version" according to Satoshi's reference implementation. The technical background of Bitcoin addresses can be found on the Bitcoin Wiki page.On February 20, 2012, Michael Grønager suggested labeling the "version" portion of Bitcoin addresses as the "network id" to indicate the intended network and chain. However, it was pointed out that it has always been referred to as the "version" and confirmed to be the original intention. The proposal to change the label is currently being discussed on the BIP-13 wiki page.A proposal has been made to change the "network id" portion of Bitcoin addresses back to the original term "version". The proposed structure for Bitcoin addresses would reduce the possibility of using a faulty address from 1 in 4 billion to 1 in 24 million, increasing security. However, old clients would render new addresses useless while maintaining their familiar appearance. This proposal is currently under discussion on the BIP-13 wiki page. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_BIP-20-Rejected-process-for-BIP-21N.xml b/static/bitcoin-dev/Feb_2012/combined_BIP-20-Rejected-process-for-BIP-21N.xml index 0aaee9de73..4498a8f46d 100644 --- a/static/bitcoin-dev/Feb_2012/combined_BIP-20-Rejected-process-for-BIP-21N.xml +++ b/static/bitcoin-dev/Feb_2012/combined_BIP-20-Rejected-process-for-BIP-21N.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 20 Rejected, process for BIP 21N - 2023-08-01T02:58:12.134772+00:00 + 2025-10-11T22:17:51.569685+00:00 + python-feedgen Matt Corallo 2012-02-04 17:15:02+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - BIP 20 Rejected, process for BIP 21N - 2023-08-01T02:58:12.135763+00:00 + 2025-10-11T22:17:51.569839+00:00 - In 2012, a discussion took place between Amir Taaki and slush on the Bitcoin-development mailing list regarding the use of satoshis instead of decimal bitcoin for BIP 21. Slush proposed using satoshis due to the difficulty of handling decimal numbers across different implementations. However, Amir argued against this idea, emphasizing that decimal numbers are widely used in HTML, URI, and other standards, and breaking with tradition would cause confusion. He also pointed out that BIP 20, which had no support from popular implementations like Bitcoin-Qt, Electrum, MultiBit, and Bitcoin-JS, was incompatible with most web standards. Therefore, he recommended rejecting BIP 20 and reaching a consensus among developers for a new standard for BIP 21.The lack of support for BIP 20 among popular implementations, especially those involving GUI projects with URI Scheme, carries significant weight in decision-making. Although Bitcoin-Qt has a majority of users, relying solely on this fact is discouraged. Instead of accepting BIP 21, which is essentially a copy of BIP 20 with some sections missing, it is suggested to reject it and establish a new standard. However, since BIP 21 is still in draft form, it is proposed that developers agree on something and present it to BlueMatt for consideration as the new BIP 21.Consensus seems to be forming on most aspects of the proposal, apart from the contentious issue of sending private keys. Furthermore, there is a discussion about including a time-to-expire field for merchants, which is seen as a beneficial idea. One of the problems with BIP 20 is its incompatibility with various web standards, such as HTML and URI, which exclusively use decimal numbers. Breaking from this convention is deemed unnecessary. While Amir acknowledges his personal preference for British English, he highlights that American English is the international standard and adherence to it is essential for consistency. Although it would be ideal if all code used a universal language like Esperanto, the reality is that we live in a world where decimals, English, Windows, and religious beliefs prevail.Overall, Amir discourages breaking with convention and suggests that developers agree on a new standard for BIP 21 through consensus-building and discussion. 2012-02-04T17:15:02+00:00 + In 2012, a discussion took place between Amir Taaki and slush on the Bitcoin-development mailing list regarding the use of satoshis instead of decimal bitcoin for BIP 21. Slush proposed using satoshis due to the difficulty of handling decimal numbers across different implementations. However, Amir argued against this idea, emphasizing that decimal numbers are widely used in HTML, URI, and other standards, and breaking with tradition would cause confusion. He also pointed out that BIP 20, which had no support from popular implementations like Bitcoin-Qt, Electrum, MultiBit, and Bitcoin-JS, was incompatible with most web standards. Therefore, he recommended rejecting BIP 20 and reaching a consensus among developers for a new standard for BIP 21.The lack of support for BIP 20 among popular implementations, especially those involving GUI projects with URI Scheme, carries significant weight in decision-making. Although Bitcoin-Qt has a majority of users, relying solely on this fact is discouraged. Instead of accepting BIP 21, which is essentially a copy of BIP 20 with some sections missing, it is suggested to reject it and establish a new standard. However, since BIP 21 is still in draft form, it is proposed that developers agree on something and present it to BlueMatt for consideration as the new BIP 21.Consensus seems to be forming on most aspects of the proposal, apart from the contentious issue of sending private keys. Furthermore, there is a discussion about including a time-to-expire field for merchants, which is seen as a beneficial idea. One of the problems with BIP 20 is its incompatibility with various web standards, such as HTML and URI, which exclusively use decimal numbers. Breaking from this convention is deemed unnecessary. While Amir acknowledges his personal preference for British English, he highlights that American English is the international standard and adherence to it is essential for consistency. Although it would be ideal if all code used a universal language like Esperanto, the reality is that we live in a world where decimals, English, Windows, and religious beliefs prevail.Overall, Amir discourages breaking with convention and suggests that developers agree on a new standard for BIP 21 through consensus-building and discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_BIP16-17-replacement.xml b/static/bitcoin-dev/Feb_2012/combined_BIP16-17-replacement.xml index b82634c0ae..298b46ada3 100644 --- a/static/bitcoin-dev/Feb_2012/combined_BIP16-17-replacement.xml +++ b/static/bitcoin-dev/Feb_2012/combined_BIP16-17-replacement.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP16/17 replacement - 2023-08-01T02:59:30.445170+00:00 + 2025-10-11T22:18:04.326747+00:00 + python-feedgen Andy Parkins 2012-02-01 14:14:08+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP16/17 replacement - 2023-08-01T02:59:30.446173+00:00 + 2025-10-11T22:18:04.326910+00:00 - On January 31, 2012, Andy Parkins proposed changes to the Bitcoin protocol. He suggested replacing the "scriptPubKey" field with a new "hashOfClaimingScript" field and adding an "unsignedParameters" array. However, he later realized that his proposal was essentially BIP16 without backward compatibility work. He suggested renaming the scriptPubKey field to "hashOfClaimingScript" and no longer running it as a script. This format of scriptPubKey would activate "version2" processing of the transaction. The scriptSig would have two fields: unsignedInitialStackBlock and scriptClaim. Parkins concluded that he now supported BIP16 as it moves towards having a literal claimScriptHash field instead of scriptPubKey.On February 1, 2012, Pieter Wuille and Dr. Andy Parkins discussed changes to the Bitcoin protocol. They noted that non-standard transactions are verified in the blockchain but are rejected when entering the memory pool due to the IsStandard() function. They also discussed the importance of upgrading to avoid seeing a fork of the chain from before the first new-style transaction if a breaking change is made to the protocol.On the same day, Andy Parkins had a discussion with Luke-Jr regarding BIP16 and BIP17. Luke-Jr claimed that both proposals were backward compatible enough for users to continue using old clients with each other, but Andy questioned this. It was explained that IsStandard() is used for accepting transactions into the memory pool, and non-standard transactions are verified in the blockchain. BIP16/17 create transactions that, when interpreted as old scripts, are valid. The only change to the protocol is that previously-valid transactions become invalid. As long as a supermajority of miners enforce the new rules, everyone can keep using their old bitcoin client.Gregory Maxwell responded on January 31, 2012, stating that nodes in Bitcoin do not need to trust the network and can validate information themselves. He argued against making breaking changes to the system as it is a zero-trust system and any change would require a client update. However, he considered BIP16/17 not to be breaking changes. The author of the original proposal disagreed but agreed that making such changes would be difficult due to resource requirements. Increasing the version number of the transaction structure was suggested as a reasonable solution.In an email conversation on January 31, 2012, Andy Parkins expressed nervousness about the ongoing debate surrounding BIP16/BIP17. Another participant explained that the differences between the options were technically obscure and generally agreed upon by technically-minded individuals. They referred to Luke's opinion tracker page, which reflects the views of core developers and informed parties. It was noted that BIP16 was the consensus path forward from earlier discussions, while BIP12 was deemed too computationally powerful. Client upgrade would be necessary to make use of new functionality, as Bitcoin is a zero-trust system and breaking changes like those proposed could not be taken lightly.Luke-Jr wrote on January 31, 2012, that there were no remaining tangible objections to BIP17. Both BIP16 and 17 were backward compatible enough for users to continue using old clients with each other. An upgrade was only required to send or receive on the new 3...-form addresses. The practical implications of both proposals could be rewritten in a format suggested by Andy, which would be backward compatible. Only version2 transactions for version2 addresses would need to be made.In another email conversation, Andy Parkins expressed his nervousness about the ongoing debate surrounding BIP17 and BIP16. He suggested that if there were objections to both proposals, then perhaps another solution would be better. He was willing to withdraw BIP17 if a better solution emerged. Both BIP16 and 17 were backward-compatible enough for users to continue using old clients with each other. Upgrades would only be necessary to send or receive new 3...-format addresses. The practical implications of both proposals could be rewritten in the suggested format, which would eliminate one of the major objections to BIP16.The author of an email expressed nervousness about suggesting an idea for a change in transactions. They proposed increasing the version number in transactions and making changes to the transaction structure. The proposal included replacing the "scriptPubKey" field with "hashOfClaimingScript" and adding an "unsignedParameters" array. The hashOfClaimingScript would be the hash of the script allowed to claim the output. The proposal invited feedback from others. 2012-02-01T14:14:08+00:00 + On January 31, 2012, Andy Parkins proposed changes to the Bitcoin protocol. He suggested replacing the "scriptPubKey" field with a new "hashOfClaimingScript" field and adding an "unsignedParameters" array. However, he later realized that his proposal was essentially BIP16 without backward compatibility work. He suggested renaming the scriptPubKey field to "hashOfClaimingScript" and no longer running it as a script. This format of scriptPubKey would activate "version2" processing of the transaction. The scriptSig would have two fields: unsignedInitialStackBlock and scriptClaim. Parkins concluded that he now supported BIP16 as it moves towards having a literal claimScriptHash field instead of scriptPubKey.On February 1, 2012, Pieter Wuille and Dr. Andy Parkins discussed changes to the Bitcoin protocol. They noted that non-standard transactions are verified in the blockchain but are rejected when entering the memory pool due to the IsStandard() function. They also discussed the importance of upgrading to avoid seeing a fork of the chain from before the first new-style transaction if a breaking change is made to the protocol.On the same day, Andy Parkins had a discussion with Luke-Jr regarding BIP16 and BIP17. Luke-Jr claimed that both proposals were backward compatible enough for users to continue using old clients with each other, but Andy questioned this. It was explained that IsStandard() is used for accepting transactions into the memory pool, and non-standard transactions are verified in the blockchain. BIP16/17 create transactions that, when interpreted as old scripts, are valid. The only change to the protocol is that previously-valid transactions become invalid. As long as a supermajority of miners enforce the new rules, everyone can keep using their old bitcoin client.Gregory Maxwell responded on January 31, 2012, stating that nodes in Bitcoin do not need to trust the network and can validate information themselves. He argued against making breaking changes to the system as it is a zero-trust system and any change would require a client update. However, he considered BIP16/17 not to be breaking changes. The author of the original proposal disagreed but agreed that making such changes would be difficult due to resource requirements. Increasing the version number of the transaction structure was suggested as a reasonable solution.In an email conversation on January 31, 2012, Andy Parkins expressed nervousness about the ongoing debate surrounding BIP16/BIP17. Another participant explained that the differences between the options were technically obscure and generally agreed upon by technically-minded individuals. They referred to Luke's opinion tracker page, which reflects the views of core developers and informed parties. It was noted that BIP16 was the consensus path forward from earlier discussions, while BIP12 was deemed too computationally powerful. Client upgrade would be necessary to make use of new functionality, as Bitcoin is a zero-trust system and breaking changes like those proposed could not be taken lightly.Luke-Jr wrote on January 31, 2012, that there were no remaining tangible objections to BIP17. Both BIP16 and 17 were backward compatible enough for users to continue using old clients with each other. An upgrade was only required to send or receive on the new 3...-form addresses. The practical implications of both proposals could be rewritten in a format suggested by Andy, which would be backward compatible. Only version2 transactions for version2 addresses would need to be made.In another email conversation, Andy Parkins expressed his nervousness about the ongoing debate surrounding BIP17 and BIP16. He suggested that if there were objections to both proposals, then perhaps another solution would be better. He was willing to withdraw BIP17 if a better solution emerged. Both BIP16 and 17 were backward-compatible enough for users to continue using old clients with each other. Upgrades would only be necessary to send or receive new 3...-format addresses. The practical implications of both proposals could be rewritten in the suggested format, which would eliminate one of the major objections to BIP16.The author of an email expressed nervousness about suggesting an idea for a change in transactions. They proposed increasing the version number in transactions and making changes to the transaction structure. The proposal included replacing the "scriptPubKey" field with "hashOfClaimingScript" and adding an "unsignedParameters" array. The hashOfClaimingScript would be the hash of the script allowed to claim the output. The proposal invited feedback from others. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_BitcoinQt-eating-100-CPU.xml b/static/bitcoin-dev/Feb_2012/combined_BitcoinQt-eating-100-CPU.xml index ec3830b788..62d4e861aa 100644 --- a/static/bitcoin-dev/Feb_2012/combined_BitcoinQt-eating-100-CPU.xml +++ b/static/bitcoin-dev/Feb_2012/combined_BitcoinQt-eating-100-CPU.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BitcoinQt eating 100% CPU - 2023-08-01T03:19:07.482324+00:00 + 2025-10-11T22:18:12.824184+00:00 + python-feedgen Luke-Jr 2012-02-23 20:33:41+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BitcoinQt eating 100% CPU - 2023-08-01T03:19:07.482324+00:00 + 2025-10-11T22:18:12.824333+00:00 - In a conversation on February 23, 2012, Gavin Andresen proposed a solution for the Mac version of Bitcoin-Qt that was not registering itself as a bitcoin URL handler. He suggested not launching the ipcThread in order to address this issue. However, there was concern about whether this would prevent the user from registering it. No further information was provided regarding the outcome of this discussion.The culprit for Bitcoin-Qt using excessive CPU was identified as line 31 in qtipcserver.cpp. Other users have reported similar issues, and one user was able to reproduce the problem on their Mac. Since the Mac version of Bitcoin-Qt does not register itself as a bitcoin URL handler, one possible solution is to not launch the ipcThread in the 0.6 release, according to Gavin Andresen.The sender of an email, Michael Grønager, addressed an issue they faced with Bitcoin-Qt. After building the latest source of the program using qt-creator on MacOSX 10.7.3 and changing the BDB version to 5.1, the program was consuming 100% CPU after initial block chain download. While the activity in debug.log appeared normal, sampling showed that most of the time in each thread was spent on various operations. The only line that seemed strange was line 31 in qtipcserver.cpp. The sender believed that this should not consume CPU either. After further investigation, the sender found that line 31 was indeed the culprit and fixed the issue by inserting `ipcShutdown()` into the ipcThread. As a result, Bitcoin-Qt now runs smoothly with around 0.9% CPU usage. The sender concluded the email by asking if anyone else had experienced similar issues.The writer of the email downloaded the latest version of bitcoin-qt (0.6 rc1) and built it on MacOSX 10.7.3 using qt-creator. However, despite there being no issues with debug.log activity, the application was using 100% CPU. The majority of time in each thread was spent on several processes. The writer found line 31 in qtipcserver.cpp to be the only strange occurrence and asked if others had encountered this issue before. 2012-02-23T20:33:41+00:00 + In a conversation on February 23, 2012, Gavin Andresen proposed a solution for the Mac version of Bitcoin-Qt that was not registering itself as a bitcoin URL handler. He suggested not launching the ipcThread in order to address this issue. However, there was concern about whether this would prevent the user from registering it. No further information was provided regarding the outcome of this discussion.The culprit for Bitcoin-Qt using excessive CPU was identified as line 31 in qtipcserver.cpp. Other users have reported similar issues, and one user was able to reproduce the problem on their Mac. Since the Mac version of Bitcoin-Qt does not register itself as a bitcoin URL handler, one possible solution is to not launch the ipcThread in the 0.6 release, according to Gavin Andresen.The sender of an email, Michael Grønager, addressed an issue they faced with Bitcoin-Qt. After building the latest source of the program using qt-creator on MacOSX 10.7.3 and changing the BDB version to 5.1, the program was consuming 100% CPU after initial block chain download. While the activity in debug.log appeared normal, sampling showed that most of the time in each thread was spent on various operations. The only line that seemed strange was line 31 in qtipcserver.cpp. The sender believed that this should not consume CPU either. After further investigation, the sender found that line 31 was indeed the culprit and fixed the issue by inserting `ipcShutdown()` into the ipcThread. As a result, Bitcoin-Qt now runs smoothly with around 0.9% CPU usage. The sender concluded the email by asking if anyone else had experienced similar issues.The writer of the email downloaded the latest version of bitcoin-qt (0.6 rc1) and built it on MacOSX 10.7.3 using qt-creator. However, despite there being no issues with debug.log activity, the application was using 100% CPU. The majority of time in each thread was spent on several processes. The writer found line 31 in qtipcserver.cpp to be the only strange occurrence and asked if others had encountered this issue before. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_Building-BDB-on-MingW.xml b/static/bitcoin-dev/Feb_2012/combined_Building-BDB-on-MingW.xml index efdb44a139..e6b1022b17 100644 --- a/static/bitcoin-dev/Feb_2012/combined_Building-BDB-on-MingW.xml +++ b/static/bitcoin-dev/Feb_2012/combined_Building-BDB-on-MingW.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Building BDB on MingW - 2023-08-01T03:19:20.624581+00:00 + 2025-10-11T22:18:21.316578+00:00 + python-feedgen neil 2014-07-14 11:27:15+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Building BDB on MingW - 2023-08-01T03:19:20.624581+00:00 + 2025-10-11T22:18:21.316708+00:00 - Based on the given context, it appears that the sender is seeking assistance in resolving an error they encountered while building Berkeley DB (BDB) on MingW. The recipient provided a link to an Oracle forum thread that suggests a solution for the issue. However, the sender followed the instructions from build-msw.txt but still faced the same problem mentioned in a Bitcointalk thread. They were able to compile it using specific flags, but when running bitcoind, it threw a DbRunRecoveryException over the DB_RUNRECOVERY flag.It seems that many people do not use MingW to compile bitcoind on Windows due to the lack of pthreads and missing functions such as strncasecmp, _strlwr, _fileno, and swprintf. Amir Taaki reached out to Wladimir for help with the issue he faced while following the build-msw.txt instructions. Amir shared a link to a Bitcointalk forum post that described his issue, but the proposed fix in that thread did not work for him. Unfortunately, the specific issue or whether Wladimir was able to provide assistance is unclear. The user encountered an issue while following the instructions in build-msw.txt to install a program. They provided a link to a forum where someone else had a similar issue. In their post, the user included their input commands and the error message they received. The error message indicates that there are two or more data types in declaration specifiers, causing the make command to fail. However, the proposed fix in the forum thread did not work for the user. 2014-07-14T11:27:15+00:00 + Based on the given context, it appears that the sender is seeking assistance in resolving an error they encountered while building Berkeley DB (BDB) on MingW. The recipient provided a link to an Oracle forum thread that suggests a solution for the issue. However, the sender followed the instructions from build-msw.txt but still faced the same problem mentioned in a Bitcointalk thread. They were able to compile it using specific flags, but when running bitcoind, it threw a DbRunRecoveryException over the DB_RUNRECOVERY flag.It seems that many people do not use MingW to compile bitcoind on Windows due to the lack of pthreads and missing functions such as strncasecmp, _strlwr, _fileno, and swprintf. Amir Taaki reached out to Wladimir for help with the issue he faced while following the build-msw.txt instructions. Amir shared a link to a Bitcointalk forum post that described his issue, but the proposed fix in that thread did not work for him. Unfortunately, the specific issue or whether Wladimir was able to provide assistance is unclear. The user encountered an issue while following the instructions in build-msw.txt to install a program. They provided a link to a forum where someone else had a similar issue. In their post, the user included their input commands and the error message they received. The error message indicates that there are two or more data types in declaration specifiers, causing the make command to fail. However, the proposed fix in the forum thread did not work for the user. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_Duplicate-transactions-vulnerability.xml b/static/bitcoin-dev/Feb_2012/combined_Duplicate-transactions-vulnerability.xml index 3dcee58ebe..3b49bdfa57 100644 --- a/static/bitcoin-dev/Feb_2012/combined_Duplicate-transactions-vulnerability.xml +++ b/static/bitcoin-dev/Feb_2012/combined_Duplicate-transactions-vulnerability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Duplicate transactions vulnerability - 2023-08-01T03:20:01.503737+00:00 + 2025-10-11T22:18:08.574923+00:00 + python-feedgen Pieter Wuille 2012-03-03 16:41:03+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Duplicate transactions vulnerability - 2023-08-01T03:20:01.503737+00:00 + 2025-10-11T22:18:08.575092+00:00 - In February 2012, a vulnerability in the Bitcoin reference client was discovered. This vulnerability allowed for duplicate transactions, although exploiting it required significant hash power and had no financial benefit for attackers. Despite this, it was still seen as a security issue that needed to be addressed promptly.To fix the vulnerability, Pieter Wuille proposed adding an additional protocol rule that would prevent blocks from containing a transaction with the same hash as a previous transaction that had not been fully spent. This proposal was detailed in BIP30, and a patch for the reference client was created and tested to ensure the attack would be impossible. Importantly, the change was designed to be backward compatible with older versions of the software.Wuille reached out to the Bitcoin community for support in adding this rule to the protocol rules. The goal was to encourage pools and miners to update their nodes without needing a lengthy coinbase-flagging procedure that could delay the implementation of the solution. Gavin Andresen expressed strong support for this proposal.However, some community members, like Robert, raised concerns and suggested modifying the rule further. They believed that there should be no duplicate transaction hashes at all and proposed preventing the inclusion of transaction hashes that already existed in the branch. Additionally, they suggested "tweaking" transactions with the same hash to avoid collision.Despite these concerns, the Bitcoin community was actively working together to find a solution to the security vulnerability and ensure the safety of the network. The proposed protocol rule aimed to prevent duplicate transactions and make the attack impossible. With consensus and support from pools and miners, the implementation of this rule could be achieved without significant delays. 2012-03-03T16:41:03+00:00 + In February 2012, a vulnerability in the Bitcoin reference client was discovered. This vulnerability allowed for duplicate transactions, although exploiting it required significant hash power and had no financial benefit for attackers. Despite this, it was still seen as a security issue that needed to be addressed promptly.To fix the vulnerability, Pieter Wuille proposed adding an additional protocol rule that would prevent blocks from containing a transaction with the same hash as a previous transaction that had not been fully spent. This proposal was detailed in BIP30, and a patch for the reference client was created and tested to ensure the attack would be impossible. Importantly, the change was designed to be backward compatible with older versions of the software.Wuille reached out to the Bitcoin community for support in adding this rule to the protocol rules. The goal was to encourage pools and miners to update their nodes without needing a lengthy coinbase-flagging procedure that could delay the implementation of the solution. Gavin Andresen expressed strong support for this proposal.However, some community members, like Robert, raised concerns and suggested modifying the rule further. They believed that there should be no duplicate transaction hashes at all and proposed preventing the inclusion of transaction hashes that already existed in the branch. Additionally, they suggested "tweaking" transactions with the same hash to avoid collision.Despite these concerns, the Bitcoin community was actively working together to find a solution to the security vulnerability and ensure the safety of the network. The proposed protocol rule aimed to prevent duplicate transactions and make the attack impossible. With consensus and support from pools and miners, the implementation of this rule could be achieved without significant delays. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_IRC-meeting-Tuesday-Feb-14-21-00-UTC.xml b/static/bitcoin-dev/Feb_2012/combined_IRC-meeting-Tuesday-Feb-14-21-00-UTC.xml index a888e6326a..99454026d6 100644 --- a/static/bitcoin-dev/Feb_2012/combined_IRC-meeting-Tuesday-Feb-14-21-00-UTC.xml +++ b/static/bitcoin-dev/Feb_2012/combined_IRC-meeting-Tuesday-Feb-14-21-00-UTC.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - IRC meeting Tuesday, Feb 14, 21:00 UTC - 2023-08-01T03:18:04.034475+00:00 + 2025-10-11T22:18:06.449782+00:00 + python-feedgen Wladimir 2012-02-14 07:23:23+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - IRC meeting Tuesday, Feb 14, 21:00 UTC - 2023-08-01T03:18:04.035467+00:00 + 2025-10-11T22:18:06.449916+00:00 - On February 14, 2012, Gavin Andresen sent an email to the Bitcoin-development mailing list inviting members to an IRC meeting on #bitcoin-dev on Freenode IRC. The purpose of the meeting was to discuss the progress towards 50% hashing power for BIP 16 support, a protocol change scheduled for February 20, and the duplicate coinbase issue. The meeting was scheduled for February 14 at 21:00 UTC. However, one member named Slush expressed concern about having the meeting on Valentine's Day, as some members had girlfriends. In response, Wladimir stated that his girlfriend hates Valentine's Day, so it was acceptable for him. Gavin jokingly suggested that after discussing technical matters, they could exchange bitcoins with addresses containing cute Valentine's Day messages.In addition to the meeting invitation, Gavin also included an advertisement for LearnDevNow, an online learning library for Microsoft developers priced at $99.99.Overall, Gavin Andresen invited members of the Bitcoin development mailing list to a meeting to discuss various topics, including the status of BIP 16 support and a protocol change scheduled for February 20. The meeting was planned for February 14 at 21:00 UTC, although there were concerns about its timing conflicting with Valentine's Day. Gavin responded humorously to these concerns and proposed exchanging bitcoins with Valentine's Day-themed addresses. 2012-02-14T07:23:23+00:00 + On February 14, 2012, Gavin Andresen sent an email to the Bitcoin-development mailing list inviting members to an IRC meeting on #bitcoin-dev on Freenode IRC. The purpose of the meeting was to discuss the progress towards 50% hashing power for BIP 16 support, a protocol change scheduled for February 20, and the duplicate coinbase issue. The meeting was scheduled for February 14 at 21:00 UTC. However, one member named Slush expressed concern about having the meeting on Valentine's Day, as some members had girlfriends. In response, Wladimir stated that his girlfriend hates Valentine's Day, so it was acceptable for him. Gavin jokingly suggested that after discussing technical matters, they could exchange bitcoins with addresses containing cute Valentine's Day messages.In addition to the meeting invitation, Gavin also included an advertisement for LearnDevNow, an online learning library for Microsoft developers priced at $99.99.Overall, Gavin Andresen invited members of the Bitcoin development mailing list to a meeting to discuss various topics, including the status of BIP 16 support and a protocol change scheduled for February 20. The meeting was planned for February 14 at 21:00 UTC, although there were concerns about its timing conflicting with Valentine's Day. Gavin responded humorously to these concerns and proposed exchanging bitcoins with Valentine's Day-themed addresses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_Multisignature-transaction-support-in-the-GUI.xml b/static/bitcoin-dev/Feb_2012/combined_Multisignature-transaction-support-in-the-GUI.xml index f26e9bc4a3..d19ce113a3 100644 --- a/static/bitcoin-dev/Feb_2012/combined_Multisignature-transaction-support-in-the-GUI.xml +++ b/static/bitcoin-dev/Feb_2012/combined_Multisignature-transaction-support-in-the-GUI.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Multisignature transaction support in the GUI - 2023-08-01T03:17:41.324283+00:00 + 2025-10-11T22:17:53.693582+00:00 + python-feedgen Aidan Thornton 2012-02-07 11:52:19+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Multisignature transaction support in the GUI - 2023-08-01T03:17:41.324283+00:00 + 2025-10-11T22:17:53.693747+00:00 - In a discussion on February 6th, 2012, the changes to BitcoinAddressValidator::MaxAddressLength and WalletModel::sendCoins were brought up. The validation of addresses is done through walletmodel->validateAddress, which calls CBitcoinAddress addressParsed(addr) and then isValid(). Both the GUI and RPC commands use CBitcoinAddress and IsValid for address validation. There was concern about whether this process would work for new addresses, but it was concluded that it should work unless BIP 16 caused any issues. The new address type, created using CScript.SetBitcoinAddress, should work with the RPC commands for sending Bitcoins. The only change needed is to MaxAddressLength, which is necessary for sending coins to multisig addresses on testnet. However, sending coins on mainnet should still work without any changes. Overall, minimal changes are required for the new address types.On February 6th, 2012, Gavin Andresen proposed two options for implementing multisig addresses. He suggested that the second option would be preferable as it would allow for more testing and fewer bug reports. However, he believed that creating multisig addresses through the GUI should wait until the next release, while enabling send-to-multisig-address through the GUI could be a simple change. Wladimir agreed with the second option, which involved changing the maximum address length and validation, but questioned whether WalletModel::sendCoins needed to be changed as well.In an email exchange on February 6th, 2012, Gavin Andresen suggested two potential solutions for addressing issues with multisig addresses. He argued that the second option would result in more thorough testing of multisig and fewer bug reports. Wladimir agreed with this approach and proposed changing the maximum address length and validation, which would be a straightforward modification. The set of allowed characters for BitcoinAddressValidator would remain the same. More advanced dialogs for constructing and adding multisig addresses to the address book could be postponed until version 0.7.0.Gavin Andresen, a Bitcoin developer, conducted tests on how the Bitcoin-Qt GUI handles multisignature transactions. He found that it can display them without any problems. However, it does not yet support sending multisig/BIP16 transactions for the main network. Gavin identified two possible paths forward: 1) Keep the GUI as-is and require multisig testing to use the RPC interface, or 2) Begin implementing multisig support in the GUI during the 0.6 release process, but only enable it for the test network. The advantage of the first path is that it would expedite the final release of version 0.6, while the advantage of the second path is that it would allow for more comprehensive testing of multisig with fewer bug reports. Gavin suggested allowing "send-to-multisig-address" through the GUI, which should be a simple change to the address validation logic. However, the creation of multisig addresses via the GUI should wait until the next release. 2012-02-07T11:52:19+00:00 + In a discussion on February 6th, 2012, the changes to BitcoinAddressValidator::MaxAddressLength and WalletModel::sendCoins were brought up. The validation of addresses is done through walletmodel->validateAddress, which calls CBitcoinAddress addressParsed(addr) and then isValid(). Both the GUI and RPC commands use CBitcoinAddress and IsValid for address validation. There was concern about whether this process would work for new addresses, but it was concluded that it should work unless BIP 16 caused any issues. The new address type, created using CScript.SetBitcoinAddress, should work with the RPC commands for sending Bitcoins. The only change needed is to MaxAddressLength, which is necessary for sending coins to multisig addresses on testnet. However, sending coins on mainnet should still work without any changes. Overall, minimal changes are required for the new address types.On February 6th, 2012, Gavin Andresen proposed two options for implementing multisig addresses. He suggested that the second option would be preferable as it would allow for more testing and fewer bug reports. However, he believed that creating multisig addresses through the GUI should wait until the next release, while enabling send-to-multisig-address through the GUI could be a simple change. Wladimir agreed with the second option, which involved changing the maximum address length and validation, but questioned whether WalletModel::sendCoins needed to be changed as well.In an email exchange on February 6th, 2012, Gavin Andresen suggested two potential solutions for addressing issues with multisig addresses. He argued that the second option would result in more thorough testing of multisig and fewer bug reports. Wladimir agreed with this approach and proposed changing the maximum address length and validation, which would be a straightforward modification. The set of allowed characters for BitcoinAddressValidator would remain the same. More advanced dialogs for constructing and adding multisig addresses to the address book could be postponed until version 0.7.0.Gavin Andresen, a Bitcoin developer, conducted tests on how the Bitcoin-Qt GUI handles multisignature transactions. He found that it can display them without any problems. However, it does not yet support sending multisig/BIP16 transactions for the main network. Gavin identified two possible paths forward: 1) Keep the GUI as-is and require multisig testing to use the RPC interface, or 2) Begin implementing multisig support in the GUI during the 0.6 release process, but only enable it for the test network. The advantage of the first path is that it would expedite the final release of version 0.6, while the advantage of the second path is that it would allow for more comprehensive testing of multisig with fewer bug reports. Gavin suggested allowing "send-to-multisig-address" through the GUI, which should be a simple change to the address validation logic. However, the creation of multisig addresses via the GUI should wait until the next release. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_Scaling-at-the-end-user-level.xml b/static/bitcoin-dev/Feb_2012/combined_Scaling-at-the-end-user-level.xml index 991b9a6ad3..169a3f1019 100644 --- a/static/bitcoin-dev/Feb_2012/combined_Scaling-at-the-end-user-level.xml +++ b/static/bitcoin-dev/Feb_2012/combined_Scaling-at-the-end-user-level.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Scaling at the end user level - 2023-08-01T03:17:56.723663+00:00 + 2025-10-11T22:18:00.075130+00:00 + python-feedgen grarpamp 2012-02-08 19:32:33+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Scaling at the end user level - 2023-08-01T03:17:56.723663+00:00 + 2025-10-11T22:18:00.075276+00:00 - In a discussion about distributing a precomputed bootstrap chain for Bitcoin, various options are proposed including using rsync or db_dump > git > db_load methods. However, some people express concerns that this approach goes against the distributed nature of Bitcoin. One suggestion is to use Git repos backed by strong hashes, with each commit representing a single block dump, and trusted entities signing at checkpoints/heights. The development of blockchain tools is seen as crucial for this approach.One user reports that their client on an old P4 computer has been idly working on building and verifying the initial chain for about a week. They question whether this is feasible for new users and inquire if any proposals have been published for distributing a precomputed bootstrap chain. The user also highlights that there is significant compression available in the index and chain.Wladimir, believed to be Bitcoin's lead developer, responds to the proposal acknowledging that he had previously suggested packaging part of the block chain. However, he notes that this could pose challenges as users would have to rely on the packager for accurate information if the imported chain is not validated. On the other hand, validating the chain would still require a significant amount of time for the user's computer.The issue of artificial slowdown linked to database file locking and flushing is discussed. It is found that the problem is not related to the age of the computer but rather how truthfully the database file is written to disk. Different operating systems seem to handle this differently, resulting in varying processing speeds. The default settings of the db lib used by Bitcoin may also play a role in this issue.Overall, the need for a more efficient method of building and verifying the initial chain is recognized. While proposals for distributing a precomputed bootstrap chain are put forward, further investigation and development of blockchain tools are needed. Additionally, the issue of database file locking and flushing is highlighted as a potential obstacle that needs to be addressed. 2012-02-08T19:32:33+00:00 + In a discussion about distributing a precomputed bootstrap chain for Bitcoin, various options are proposed including using rsync or db_dump > git > db_load methods. However, some people express concerns that this approach goes against the distributed nature of Bitcoin. One suggestion is to use Git repos backed by strong hashes, with each commit representing a single block dump, and trusted entities signing at checkpoints/heights. The development of blockchain tools is seen as crucial for this approach.One user reports that their client on an old P4 computer has been idly working on building and verifying the initial chain for about a week. They question whether this is feasible for new users and inquire if any proposals have been published for distributing a precomputed bootstrap chain. The user also highlights that there is significant compression available in the index and chain.Wladimir, believed to be Bitcoin's lead developer, responds to the proposal acknowledging that he had previously suggested packaging part of the block chain. However, he notes that this could pose challenges as users would have to rely on the packager for accurate information if the imported chain is not validated. On the other hand, validating the chain would still require a significant amount of time for the user's computer.The issue of artificial slowdown linked to database file locking and flushing is discussed. It is found that the problem is not related to the age of the computer but rather how truthfully the database file is written to disk. Different operating systems seem to handle this differently, resulting in varying processing speeds. The default settings of the db lib used by Bitcoin may also play a role in this issue.Overall, the need for a more efficient method of building and verifying the initial chain is recognized. While proposals for distributing a precomputed bootstrap chain are put forward, further investigation and development of blockchain tools are needed. Additionally, the issue of database file locking and flushing is highlighted as a potential obstacle that needs to be addressed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_Version-0-6-release-candidate-1-plan.xml b/static/bitcoin-dev/Feb_2012/combined_Version-0-6-release-candidate-1-plan.xml index e6e342a0f7..7fb622bbd7 100644 --- a/static/bitcoin-dev/Feb_2012/combined_Version-0-6-release-candidate-1-plan.xml +++ b/static/bitcoin-dev/Feb_2012/combined_Version-0-6-release-candidate-1-plan.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Version 0.6 release candidate 1 plan - 2023-08-01T03:17:18.596958+00:00 + 2025-10-11T22:18:02.198136+00:00 + python-feedgen Gavin Andresen 2012-02-07 16:14:14+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Version 0.6 release candidate 1 plan - 2023-08-01T03:17:18.597957+00:00 + 2025-10-11T22:18:02.198280+00:00 - The problem of green addresses spamming the blockchain can be addressed through a REST-ful API provided by green address providers. This API allows users to declare transactions as "green" by providing their transaction ID and credentials. Users can also check whether a transaction has been declared green by providing its ID and receiving a boolean response. However, Gavin Andresen believes that any design relying on clients recognizing two variations of a transaction is not a good idea.Luke-Jr initially raised concerns about making transactions with extra data in scriptSig non-standard on February 6, 2012. He was worried that this change could hinder the replacement of the current spammy "green address" scheme with a more sensible extra signature system. Luke-Jr also pointed out that it could negatively impact the adoption of such a system by miners. However, gmaxwell explained why this change was no longer necessary on IRC, leading Luke-Jr to withdraw his objection on February 7, 2012.In his proposal on the same day, Luke-Jr suggested making transactions with extra data in scriptSig non-standard. He expressed concern that this change could hinder the replacement of the current spammy "green address" scheme with a more sensible extra signature system. He also noted that it could significantly affect the adoption of such a system by miners. Luke-Jr questioned why the possibility of using an extra signature for non-blockchain-spam 0-confirmation transactions was being ignored. MtGox reportedly supported this plan. He asked if there was an alternative solution to the problem of green addresses spamming the blockchain. In his pull request, he proposed that stripping extra data would not have any negative impact on normal transactions, and clients creating these transactions could be written to expect the transaction ID to change or not care about it.On February 6, 2012, Gavin Andresen announced several major changes in git HEAD that were ready for wider testing. He mentioned that the best way to get extensive testing is to release binaries, and he planned to create a release candidate within the next day or two. Several pull requests, such as coinbaser (719), rpc_keepalive (568), optimize_FastGetWork (565), bugfix_client_name (715), and optimize_ToHex (562), seemed well-tested and had been part of next-test for a while. Andresen suggested that if these changes seemed too significant to add to version 0.6, they could be included in version 0.7. He also discussed a modification for making transactions with extra data in scriptSig non-standard, highlighting that it could significantly hinder the replacement of the current spammy "green address" scheme with a more sensible extra signature system. On the miner end, it could also affect the adoption of such a system. Additionally, Andresen expressed interest in including a modified version of 755, which would not vote for /P2SH/ unless -p2sh was specified. However, he did not mention what other changes were required for this. Furthermore, he wanted to pull request 787, involving CAddrMan: stochastic address manager, but it did not pass his sanity tests. He confirmed encountering at least one addr.db corruption related to this.In summary, the head of Git has announced several major changes ready for wider testing. A release candidate will be created in the next day or two, with the goal of having a month of review and testing before releasing version 0.6 with zero High Priority bugs. The proposed TODO list for the release candidate includes bug fixes, displaying multiple outputs in the GUI, and making transactions with extra data in scriptSig non-standard. Additionally, a modified version of fixing minimize to tray and not voting for /P2SH/ unless -p2sh specified will be included. The discussion thread will cover thoughts on introducing higher-level multisignature support. 2012-02-07T16:14:14+00:00 + The problem of green addresses spamming the blockchain can be addressed through a REST-ful API provided by green address providers. This API allows users to declare transactions as "green" by providing their transaction ID and credentials. Users can also check whether a transaction has been declared green by providing its ID and receiving a boolean response. However, Gavin Andresen believes that any design relying on clients recognizing two variations of a transaction is not a good idea.Luke-Jr initially raised concerns about making transactions with extra data in scriptSig non-standard on February 6, 2012. He was worried that this change could hinder the replacement of the current spammy "green address" scheme with a more sensible extra signature system. Luke-Jr also pointed out that it could negatively impact the adoption of such a system by miners. However, gmaxwell explained why this change was no longer necessary on IRC, leading Luke-Jr to withdraw his objection on February 7, 2012.In his proposal on the same day, Luke-Jr suggested making transactions with extra data in scriptSig non-standard. He expressed concern that this change could hinder the replacement of the current spammy "green address" scheme with a more sensible extra signature system. He also noted that it could significantly affect the adoption of such a system by miners. Luke-Jr questioned why the possibility of using an extra signature for non-blockchain-spam 0-confirmation transactions was being ignored. MtGox reportedly supported this plan. He asked if there was an alternative solution to the problem of green addresses spamming the blockchain. In his pull request, he proposed that stripping extra data would not have any negative impact on normal transactions, and clients creating these transactions could be written to expect the transaction ID to change or not care about it.On February 6, 2012, Gavin Andresen announced several major changes in git HEAD that were ready for wider testing. He mentioned that the best way to get extensive testing is to release binaries, and he planned to create a release candidate within the next day or two. Several pull requests, such as coinbaser (719), rpc_keepalive (568), optimize_FastGetWork (565), bugfix_client_name (715), and optimize_ToHex (562), seemed well-tested and had been part of next-test for a while. Andresen suggested that if these changes seemed too significant to add to version 0.6, they could be included in version 0.7. He also discussed a modification for making transactions with extra data in scriptSig non-standard, highlighting that it could significantly hinder the replacement of the current spammy "green address" scheme with a more sensible extra signature system. On the miner end, it could also affect the adoption of such a system. Additionally, Andresen expressed interest in including a modified version of 755, which would not vote for /P2SH/ unless -p2sh was specified. However, he did not mention what other changes were required for this. Furthermore, he wanted to pull request 787, involving CAddrMan: stochastic address manager, but it did not pass his sanity tests. He confirmed encountering at least one addr.db corruption related to this.In summary, the head of Git has announced several major changes ready for wider testing. A release candidate will be created in the next day or two, with the goal of having a month of review and testing before releasing version 0.6 with zero High Priority bugs. The proposed TODO list for the release candidate includes bug fixes, displaying multiple outputs in the GUI, and making transactions with extra data in scriptSig non-standard. Additionally, a modified version of fixing minimize to tray and not voting for /P2SH/ unless -p2sh specified will be included. The discussion thread will cover thoughts on introducing higher-level multisignature support. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_getmemorypool-BIP-process.xml b/static/bitcoin-dev/Feb_2012/combined_getmemorypool-BIP-process.xml index 25d3ac1851..3e72b03036 100644 --- a/static/bitcoin-dev/Feb_2012/combined_getmemorypool-BIP-process.xml +++ b/static/bitcoin-dev/Feb_2012/combined_getmemorypool-BIP-process.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - getmemorypool BIP process - 2023-08-01T03:21:29.402892+00:00 + 2025-10-11T22:17:49.446419+00:00 + python-feedgen Geir Harald Hansen 2012-03-04 17:49:00+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - getmemorypool BIP process - 2023-08-01T03:21:29.402892+00:00 + 2025-10-11T22:17:49.446619+00:00 - Geir Harald Hansen proposed a solution to the race condition in long polling implemented in pools. He suggested adding "longpollid" in long poll responses and for the client to include the last seen longpollid in future requests. This would allow the server to check if the client has missed any block changes. Additionally, Hansen recommended including the "height" value in the getmemorypool response so that miners can include the correct height in the coinbase. However, adding parameters to getmemorypool itself breaks compatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific again. It was suggested that some features should be optional for clients to implement, but this requires a way for clients to communicate their capabilities to the server. Lastly, it was mentioned that "noncerange" is of limited use and could result in getting the endianness wrong.In a discussion between Luke-Jr and Gavin Andresen, the limitations of using JSON-RPC for server to client calls were highlighted. Gavin pointed out that JSON-RPC and HTTP are client-server models that don't allow the server to make calls to the client, making it impractical for clients to run their own JSON-RPC server. However, Luke-Jr updated the draft to include long polling and remove assumptions of using HTTP for transport. The context also provides a link to a page about virtualization and cloud management using capacity planning, which explains how cloud computing uses virtualization to deliver computing as a service. There is also information about the Bitcoin-development mailing list with a link to sign up for it.The context mentions that there is no explicit standard way to do S->C JSON-RPC. The JSON-RPC 1.0 spec doesn't require a specific transport protocol, while the JSON-RPC 2.0 spec is transport agnostic. Plain TCP sockets are commonly used for bidirectional JSON-RPC, but they lack a standardized authentication mechanism. The use of HTTP Keep-Alive with an event system, similar to web chat applications, was suggested as a solution. It was noted that HTTP Keep-Alive works but is not widely supported among client libraries, and HTTP itself isn't designed for this type of usage. Adding challenge-response authentication and TLS support to the JSON-RPC API in the future was also mentioned.A proposal called "getmemorypool" has been submitted as part of the Bitcoin Improvement Proposal (BIP) draft by Luke-Jr. The proposal aims to improve the memory pool process for miners by providing details about unconfirmed transactions. This would help miners select transactions more efficiently for inclusion in the next block. The proposal suggests adding additional values like "longpollid" and "height" to the getmemorypool response. Geir Harald Hansen provided comments on the proposal, suggesting clarifications and making certain features optional for clients to implement. The context also mentions Stefan Thomas initiating a discussion about the use of a polling model in BIP and the interest in a "push" API using JSON-RPC over TCP.Overall, the proposed changes aim to address issues with long polling in pools, improve communication between servers and clients using JSON-RPC, and enhance the memory pool process for miners. These developments have the potential to make the Bitcoin network more efficient and secure. 2012-03-04T17:49:00+00:00 + Geir Harald Hansen proposed a solution to the race condition in long polling implemented in pools. He suggested adding "longpollid" in long poll responses and for the client to include the last seen longpollid in future requests. This would allow the server to check if the client has missed any block changes. Additionally, Hansen recommended including the "height" value in the getmemorypool response so that miners can include the correct height in the coinbase. However, adding parameters to getmemorypool itself breaks compatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific again. It was suggested that some features should be optional for clients to implement, but this requires a way for clients to communicate their capabilities to the server. Lastly, it was mentioned that "noncerange" is of limited use and could result in getting the endianness wrong.In a discussion between Luke-Jr and Gavin Andresen, the limitations of using JSON-RPC for server to client calls were highlighted. Gavin pointed out that JSON-RPC and HTTP are client-server models that don't allow the server to make calls to the client, making it impractical for clients to run their own JSON-RPC server. However, Luke-Jr updated the draft to include long polling and remove assumptions of using HTTP for transport. The context also provides a link to a page about virtualization and cloud management using capacity planning, which explains how cloud computing uses virtualization to deliver computing as a service. There is also information about the Bitcoin-development mailing list with a link to sign up for it.The context mentions that there is no explicit standard way to do S->C JSON-RPC. The JSON-RPC 1.0 spec doesn't require a specific transport protocol, while the JSON-RPC 2.0 spec is transport agnostic. Plain TCP sockets are commonly used for bidirectional JSON-RPC, but they lack a standardized authentication mechanism. The use of HTTP Keep-Alive with an event system, similar to web chat applications, was suggested as a solution. It was noted that HTTP Keep-Alive works but is not widely supported among client libraries, and HTTP itself isn't designed for this type of usage. Adding challenge-response authentication and TLS support to the JSON-RPC API in the future was also mentioned.A proposal called "getmemorypool" has been submitted as part of the Bitcoin Improvement Proposal (BIP) draft by Luke-Jr. The proposal aims to improve the memory pool process for miners by providing details about unconfirmed transactions. This would help miners select transactions more efficiently for inclusion in the next block. The proposal suggests adding additional values like "longpollid" and "height" to the getmemorypool response. Geir Harald Hansen provided comments on the proposal, suggesting clarifications and making certain features optional for clients to implement. The context also mentions Stefan Thomas initiating a discussion about the use of a polling model in BIP and the interest in a "push" API using JSON-RPC over TCP.Overall, the proposed changes aim to address issues with long polling in pools, improve communication between servers and clients using JSON-RPC, and enhance the memory pool process for miners. These developments have the potential to make the Bitcoin network more efficient and secure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_libcoin-HEAD-now-supports-boost-1-47-please-test.xml b/static/bitcoin-dev/Feb_2012/combined_libcoin-HEAD-now-supports-boost-1-47-please-test.xml index 0f9a9eab75..65b4088d92 100644 --- a/static/bitcoin-dev/Feb_2012/combined_libcoin-HEAD-now-supports-boost-1-47-please-test.xml +++ b/static/bitcoin-dev/Feb_2012/combined_libcoin-HEAD-now-supports-boost-1-47-please-test.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - libcoin (HEAD) now supports boost < 1.47 - please test - 2023-08-01T03:16:36.283930+00:00 + 2025-10-11T22:18:17.069862+00:00 + python-feedgen Luke-Jr 2012-02-02 23:27:31+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - libcoin (HEAD) now supports boost < 1.47 - please test - 2023-08-01T03:16:36.283930+00:00 + 2025-10-11T22:18:17.070007+00:00 - On February 2nd, 2012, Michael Grønager expressed frustration with the Redmond_OS_not_to_be_mentioned as it requires specific declarations for dynamic libraries. He mentioned that enabling dynamic libraries was on his to-do list but not yet supported on Windows. In order to use the dll, class definitions need to be prepended with __declspec(dllexport) during compilation and __declspec(dllimport) when used. Michael mentioned his annoyance with this requirement and explained that he has a framework to automate this using CMake, but it has not been tested for libcoin.The conversation then shifted to the issue of using static libraries, specifically boost. The user had libboost*.so files but was missing libboost*.a files. Michael acknowledged the problem and mentioned that most distributions do not have static libraries installed by default. Luke-Jr patched the code to use shared libraries instead of static libraries, which is considered best practice. CoinQt was also causing problems, but these were fixed in the patch.On February 2, 2012, Michael sent out an email requesting a test and feedback. It was discovered that the issue was caused by using static libraries instead of shared ones, which is best practice except for certain scenarios. Most distributions do not come with static libraries installed by default. CoinQt was also causing issues, but a patch was created to fix them. The patch involved commenting out lines in the CMakeLists.txt files that set Boost_USE_STATIC_LIBS and QT4_FOUND, and replacing them with the # symbol to comment them out.Michael Grønager, Director of Ceptacle, added a simplified fallback class to boost::asio::signal_set for compilation on platforms with older versions of Boost. This update allows compilation on most currently deployed Linux systems that use Boost 1.42. The root CMakeLists.txt file has also been updated to only require version 1.42. Michael acknowledges that there may be hidden errors on committers' machines and encourages testing and feedback regarding the updates. Contact information for Michael and Ceptacle can be found in his signature. 2012-02-02T23:27:31+00:00 + On February 2nd, 2012, Michael Grønager expressed frustration with the Redmond_OS_not_to_be_mentioned as it requires specific declarations for dynamic libraries. He mentioned that enabling dynamic libraries was on his to-do list but not yet supported on Windows. In order to use the dll, class definitions need to be prepended with __declspec(dllexport) during compilation and __declspec(dllimport) when used. Michael mentioned his annoyance with this requirement and explained that he has a framework to automate this using CMake, but it has not been tested for libcoin.The conversation then shifted to the issue of using static libraries, specifically boost. The user had libboost*.so files but was missing libboost*.a files. Michael acknowledged the problem and mentioned that most distributions do not have static libraries installed by default. Luke-Jr patched the code to use shared libraries instead of static libraries, which is considered best practice. CoinQt was also causing problems, but these were fixed in the patch.On February 2, 2012, Michael sent out an email requesting a test and feedback. It was discovered that the issue was caused by using static libraries instead of shared ones, which is best practice except for certain scenarios. Most distributions do not come with static libraries installed by default. CoinQt was also causing issues, but a patch was created to fix them. The patch involved commenting out lines in the CMakeLists.txt files that set Boost_USE_STATIC_LIBS and QT4_FOUND, and replacing them with the # symbol to comment them out.Michael Grønager, Director of Ceptacle, added a simplified fallback class to boost::asio::signal_set for compilation on platforms with older versions of Boost. This update allows compilation on most currently deployed Linux systems that use Boost 1.42. The root CMakeLists.txt file has also been updated to only require version 1.42. Michael acknowledges that there may be hidden errors on committers' machines and encourages testing and feedback regarding the updates. Contact information for Michael and Ceptacle can be found in his signature. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2012/combined_off-topic-bitcoin-forum-.xml b/static/bitcoin-dev/Feb_2012/combined_off-topic-bitcoin-forum-.xml index 08bd49a8a1..72e6c0d474 100644 --- a/static/bitcoin-dev/Feb_2012/combined_off-topic-bitcoin-forum-.xml +++ b/static/bitcoin-dev/Feb_2012/combined_off-topic-bitcoin-forum-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - off-topic: bitcoin-forum... - 2023-08-01T03:18:26.138172+00:00 + 2025-10-11T22:17:55.820447+00:00 + python-feedgen Daniel F 2012-02-20 02:32:34+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - off-topic: bitcoin-forum... - 2023-08-01T03:18:26.138172+00:00 + 2025-10-11T22:17:55.820636+00:00 - In 2012, a user named grarpamp created a Google Group mailing list called bitcoin-discussion. However, the group had low activity and was similar to a dead mailing list on SourceForge. Grarpamp suggested the need for a real mailing list for users that would attract a more technical crowd than forums. They also pointed out the limitations of the SourceForge list browsing interface. Grarpamp proposed changing the charter of an unused list, finding an impartial administrative home with browsable and searchable archives, and promoting it through known client lists/forums.A forum post from February 19, 2012, by grarpamp expressed frustration with the lack of a Bitcoin user mailing list and the limitations of forums. They suggested reviving the Bitcoin-list mailing list on SourceForge or creating a new one on Google Groups called Bitcoin-discussion. The user highlighted the clutter and lack of preservation in forums compared to mailing lists.In an email exchange from the same day, Michael Grønager mentioned frustration with the requirement for five posts and four hours before being able to post on a forum. Wladimir explained that this policy was implemented to prevent redundant questions from new users. However, Wladimir acknowledged that the policy was not as strict anymore and Michael should have no trouble getting whitelisted.In another conversation dated February 19, 2012, Michael Grønager commented on a "strange policy" regarding spammers. Although the context is unclear, it suggests that there were measures in place to address spamming. This highlights the ongoing challenge of combating spam and the importance of protecting online communities.In an email conversation, Michael Gronager mentioned his difficulty in posting on the BitcoinTalk forum due to not being whitelisted. He planned to apply for whitelisting and found the policy strange. Harald Schilly responded, suggesting that Michael may need to be whitelisted and provided a link to the Bitcointalk forums on whitelisting.In another conversation from February 19, 2012, Michael Gronager sought an answer to his question on the BitcoinTalk forum. He wondered if he needed to be whitelisted to post and if that was the reason for his inability to do so. The post he referred to indicated that whitelisting was necessary for posting privileges, but it is unclear if this was the exact cause of his problem.Ultimately, Michael Gronager was having trouble posting on the Bitcoin forums at bitcointalk.org. He could only reply and post on some regional forums, and there was no post or reply button on the Bitcoin dev and alternative client forums. Despite trying to create a new user, he still faced difficulties and sought assistance for a solution. 2012-02-20T02:32:34+00:00 + In 2012, a user named grarpamp created a Google Group mailing list called bitcoin-discussion. However, the group had low activity and was similar to a dead mailing list on SourceForge. Grarpamp suggested the need for a real mailing list for users that would attract a more technical crowd than forums. They also pointed out the limitations of the SourceForge list browsing interface. Grarpamp proposed changing the charter of an unused list, finding an impartial administrative home with browsable and searchable archives, and promoting it through known client lists/forums.A forum post from February 19, 2012, by grarpamp expressed frustration with the lack of a Bitcoin user mailing list and the limitations of forums. They suggested reviving the Bitcoin-list mailing list on SourceForge or creating a new one on Google Groups called Bitcoin-discussion. The user highlighted the clutter and lack of preservation in forums compared to mailing lists.In an email exchange from the same day, Michael Grønager mentioned frustration with the requirement for five posts and four hours before being able to post on a forum. Wladimir explained that this policy was implemented to prevent redundant questions from new users. However, Wladimir acknowledged that the policy was not as strict anymore and Michael should have no trouble getting whitelisted.In another conversation dated February 19, 2012, Michael Grønager commented on a "strange policy" regarding spammers. Although the context is unclear, it suggests that there were measures in place to address spamming. This highlights the ongoing challenge of combating spam and the importance of protecting online communities.In an email conversation, Michael Gronager mentioned his difficulty in posting on the BitcoinTalk forum due to not being whitelisted. He planned to apply for whitelisting and found the policy strange. Harald Schilly responded, suggesting that Michael may need to be whitelisted and provided a link to the Bitcointalk forums on whitelisting.In another conversation from February 19, 2012, Michael Gronager sought an answer to his question on the BitcoinTalk forum. He wondered if he needed to be whitelisted to post and if that was the reason for his inability to do so. The post he referred to indicated that whitelisting was necessary for posting privileges, but it is unclear if this was the exact cause of his problem.Ultimately, Michael Gronager was having trouble posting on the Bitcoin forums at bitcointalk.org. He could only reply and post on some regional forums, and there was no post or reply button on the Bitcoin dev and alternative client forums. Despite trying to create a new user, he still faced difficulties and sought assistance for a solution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_0-8-0rc1-status.xml b/static/bitcoin-dev/Feb_2013/combined_0-8-0rc1-status.xml index 1bd8262259..788d919fbf 100644 --- a/static/bitcoin-dev/Feb_2013/combined_0-8-0rc1-status.xml +++ b/static/bitcoin-dev/Feb_2013/combined_0-8-0rc1-status.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.8.0rc1 status - 2023-08-01T04:25:21.949273+00:00 + 2025-10-11T22:13:57.817539+00:00 + python-feedgen Robert Backhaus 2013-02-09 07:58:33+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - 0.8.0rc1 status - 2023-08-01T04:25:21.949273+00:00 + 2025-10-11T22:13:57.817688+00:00 - The author conducted test builds on FreeBSD using gcc and clang to build both the qt gui and command line daemon. The tests ran smoothly without any reported problems, with the author making necessary changes to include directory statements. In response to Gavin Andresen's suggestion to pull #2286 before the final release or rc2, Pieter Wuille suggests that #2243 should fix the non-determinism problem in Windows. This discussion took place on the Bitcoin-development mailing list.On February 9, 2013, Gavin Andresen discussed the need to address a non-determinism problem with Windows before the final release or rc2. He proposed pulling #2286 and creating a patch to resolve the issue. Pieter Wuille responded, expressing his belief that #2243 would solve the problem. No further details are provided regarding this conversation.In terms of the builds, the Linux builds of version 0.8.0rc1 are in good shape and can easily be reproduced using gitian. However, the Windows builds are experiencing variations with each compile and require further attention. As for the OSX build, it is in fairly good condition but still needs some work. Moving forward, the plan is to announce the release of 0.8.0rc1 with the existing binaries to facilitate more testing. Additionally, there is encouragement to perform a build check on FreeBSD 8.3 (using gcc) and 9.1 (using clang/llvm). While the author intends to test version 8.x as well, it may not be feasible within the given timeframe.On Friday, February 8, 2013, Gavin Andresen addressed the issue of varying Windows builds with each compile. He identified that the -frandom-seed flag was not being passed down into the leveldb build, resulting in two different binaries that only differed in the names of some leveldb objects. He proposed a straightforward makefile fix. Luke responded, stating that this issue had already been mostly resolved in pull #2243, which was submitted nine days earlier. However, he mentioned that whether DEBUGFLAGS should be propagated to LevelDB or not is a separate discussion.In summary, the Linux builds of version 0.8.0rc1 are easily reproducible using gitian, while the Windows builds exhibit variations due to the absence of the -frandom-seed flag in the leveldb build. The OSX build requires a pull request to compile. The plan is to announce 0.8.0rc1 with the current binaries and conduct further testing before the final release. A patch will be created to address the non-determinism issue in Windows prior to the final release or rc2. Gavin Andresen intends to sign the windows setup.exe and send out an rc1 announcement the following day. 2013-02-09T07:58:33+00:00 + The author conducted test builds on FreeBSD using gcc and clang to build both the qt gui and command line daemon. The tests ran smoothly without any reported problems, with the author making necessary changes to include directory statements. In response to Gavin Andresen's suggestion to pull #2286 before the final release or rc2, Pieter Wuille suggests that #2243 should fix the non-determinism problem in Windows. This discussion took place on the Bitcoin-development mailing list.On February 9, 2013, Gavin Andresen discussed the need to address a non-determinism problem with Windows before the final release or rc2. He proposed pulling #2286 and creating a patch to resolve the issue. Pieter Wuille responded, expressing his belief that #2243 would solve the problem. No further details are provided regarding this conversation.In terms of the builds, the Linux builds of version 0.8.0rc1 are in good shape and can easily be reproduced using gitian. However, the Windows builds are experiencing variations with each compile and require further attention. As for the OSX build, it is in fairly good condition but still needs some work. Moving forward, the plan is to announce the release of 0.8.0rc1 with the existing binaries to facilitate more testing. Additionally, there is encouragement to perform a build check on FreeBSD 8.3 (using gcc) and 9.1 (using clang/llvm). While the author intends to test version 8.x as well, it may not be feasible within the given timeframe.On Friday, February 8, 2013, Gavin Andresen addressed the issue of varying Windows builds with each compile. He identified that the -frandom-seed flag was not being passed down into the leveldb build, resulting in two different binaries that only differed in the names of some leveldb objects. He proposed a straightforward makefile fix. Luke responded, stating that this issue had already been mostly resolved in pull #2243, which was submitted nine days earlier. However, he mentioned that whether DEBUGFLAGS should be propagated to LevelDB or not is a separate discussion.In summary, the Linux builds of version 0.8.0rc1 are easily reproducible using gitian, while the Windows builds exhibit variations due to the absence of the -frandom-seed flag in the leveldb build. The OSX build requires a pull request to compile. The plan is to announce 0.8.0rc1 with the current binaries and conduct further testing before the final release. A patch will be created to address the non-determinism issue in Windows prior to the final release or rc2. Gavin Andresen intends to sign the windows setup.exe and send out an rc1 announcement the following day. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_Blockchain-as-root-CA-for-payment-protocol.xml b/static/bitcoin-dev/Feb_2013/combined_Blockchain-as-root-CA-for-payment-protocol.xml index 5496ccb65b..7e1672f98c 100644 --- a/static/bitcoin-dev/Feb_2013/combined_Blockchain-as-root-CA-for-payment-protocol.xml +++ b/static/bitcoin-dev/Feb_2013/combined_Blockchain-as-root-CA-for-payment-protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Blockchain as root CA for payment protocol - 2023-08-01T04:25:00.885958+00:00 + 2025-10-11T22:13:59.951074+00:00 + python-feedgen Rick Wesson 2013-02-11 19:39:03+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Blockchain as root CA for payment protocol - 2023-08-01T04:25:00.885958+00:00 + 2025-10-11T22:13:59.951242+00:00 - The email thread discusses the use of blockchain for establishing identities and as a "root CA" to sign arbitrary certificates. The author suggests that signing the root in the DNS tree requires more effort than building a CA off the bitcoin blockchain. To associate identifiers for payment addresses, the writer suggests putting those in DNSSEC signed records in the DNS. For routing around x.509 CAs, participation in the DANE working group in the IETF is recommended. Timo Hanke argues that DNS has lower security demands compared to payment IDs for Bitcoin. He believes that DNS data can be in a chain with a lower hash rate than Bitcoin's hash rate while payment IDs need to be in a chain with the same hash rate. However, the person he is communicating with may not be well-informed about what Namecoin does - it is a multiple namespace key-value store that can have exactly the same Proof of Work hash power as a non-parasitic system. Namecoin chose a model that allowed it to survive even if Bitcoin failed, but this is not necessary for others to do. The writer strongly recommends externalizing the costs of services without taking resources from Bitcoin currency users without their consent.In a discussion on the Bitcoin development mailing list, Timo Hanke proposed to establish an identity for a payment protocol using a new namespace rather than tying names to data like Namecoin does. Hanke suggests that DNS has a lower demand than payment ids have, and therefore, DNS data can be in a chain with a hashrate lower than Bitcoin's hashrate. Payment ids meant for Bitcoin, on the other hand, must be in a chain with equal hashrate. Hanke also discusses merging the new chain with Bitcoin's blockchain. However, he questions whether this would still be considered an alt-chain or a more efficient version of what he proposed.Peter Todd, another developer on the mailing list, suggested that creating a new system adds to the confusion for users who cannot memorize unique numbers and prefer non-unique names. Todd recommends working on Namecoin to make it more usable while adding some PKI to it using the same domain names. However, Hanke argues that Namecoin is unsuitable for his purpose and proposes using a payment base address, which he sees as a more universal identifier than a domain name. Additionally, Hanke explains the pay-to-contract principle, which means authenticated communication is not necessary when paying, so funds are never lost even if ordered from a wrong website.The developers also discuss where to store alt-chain block header hashes. Hanke initially thought of putting them in the UTXO to enable a future dedicated "hardware wallet" to validate against it. However, Todd points out that storing all the data in the UTXO would mean users need to have the entire blockchain available, which is not desirable. Ultimately, they agree that storing the alt-chain block header hashes outside the UTXO would be better.In this email conversation, Timo Hanke justifies why he does not use Namecoin or any other alt-chain to establish an identity for a payment protocol. He explains that his incoming payments will land on addresses that are derived from this identity, making it as important (security-wise) as anything else involved in the bitcoin protocol. Therefore, he would not want to have payment-ids rely on anything less than bitcoin's own blockchain. However, the person replying to him argues that creating another system is just adding to the confusion of users, who can be tricked into thinking some name snatched up by scammers in some little-used PKI system is who they are supposed to be communicating with. The person suggests that Timo should work on Namecoin and make it more usable, then add some PKI to it using the same domain names so that when they see a PKI certificate for "foo", they know it must be the same "foo" website they just visited and the same "foo at foo" they just emailed. They also suggest that Timo could register a domain name in an alt-chain, then "mine" the block by creating a suitable transaction, make sure it's the biggest fee, wait a few confirmations, and they're good to go with the same level of security as Bitcoin proper. Multiple parties can also collaborate to create the transaction, each providing and signing for an input for their portion of the total fee. Moreover, they propose a "two-step sacrifice" protocol to solve the problem of miners getting to keep the fee, making it difficult to get a block mined, or to be sure a block won't be undone later. Finally, they discuss the cost of storing the UTXO set in memory, saying that it would be better to store it in the spent outputs. They also question whether Timo's users will all want to validate some PKI certificates with the blockchain growing at a maximum rate of 55GiB/year.In a conversation from February 9th, 2013 2013-02-11T19:39:03+00:00 + The email thread discusses the use of blockchain for establishing identities and as a "root CA" to sign arbitrary certificates. The author suggests that signing the root in the DNS tree requires more effort than building a CA off the bitcoin blockchain. To associate identifiers for payment addresses, the writer suggests putting those in DNSSEC signed records in the DNS. For routing around x.509 CAs, participation in the DANE working group in the IETF is recommended. Timo Hanke argues that DNS has lower security demands compared to payment IDs for Bitcoin. He believes that DNS data can be in a chain with a lower hash rate than Bitcoin's hash rate while payment IDs need to be in a chain with the same hash rate. However, the person he is communicating with may not be well-informed about what Namecoin does - it is a multiple namespace key-value store that can have exactly the same Proof of Work hash power as a non-parasitic system. Namecoin chose a model that allowed it to survive even if Bitcoin failed, but this is not necessary for others to do. The writer strongly recommends externalizing the costs of services without taking resources from Bitcoin currency users without their consent.In a discussion on the Bitcoin development mailing list, Timo Hanke proposed to establish an identity for a payment protocol using a new namespace rather than tying names to data like Namecoin does. Hanke suggests that DNS has a lower demand than payment ids have, and therefore, DNS data can be in a chain with a hashrate lower than Bitcoin's hashrate. Payment ids meant for Bitcoin, on the other hand, must be in a chain with equal hashrate. Hanke also discusses merging the new chain with Bitcoin's blockchain. However, he questions whether this would still be considered an alt-chain or a more efficient version of what he proposed.Peter Todd, another developer on the mailing list, suggested that creating a new system adds to the confusion for users who cannot memorize unique numbers and prefer non-unique names. Todd recommends working on Namecoin to make it more usable while adding some PKI to it using the same domain names. However, Hanke argues that Namecoin is unsuitable for his purpose and proposes using a payment base address, which he sees as a more universal identifier than a domain name. Additionally, Hanke explains the pay-to-contract principle, which means authenticated communication is not necessary when paying, so funds are never lost even if ordered from a wrong website.The developers also discuss where to store alt-chain block header hashes. Hanke initially thought of putting them in the UTXO to enable a future dedicated "hardware wallet" to validate against it. However, Todd points out that storing all the data in the UTXO would mean users need to have the entire blockchain available, which is not desirable. Ultimately, they agree that storing the alt-chain block header hashes outside the UTXO would be better.In this email conversation, Timo Hanke justifies why he does not use Namecoin or any other alt-chain to establish an identity for a payment protocol. He explains that his incoming payments will land on addresses that are derived from this identity, making it as important (security-wise) as anything else involved in the bitcoin protocol. Therefore, he would not want to have payment-ids rely on anything less than bitcoin's own blockchain. However, the person replying to him argues that creating another system is just adding to the confusion of users, who can be tricked into thinking some name snatched up by scammers in some little-used PKI system is who they are supposed to be communicating with. The person suggests that Timo should work on Namecoin and make it more usable, then add some PKI to it using the same domain names so that when they see a PKI certificate for "foo", they know it must be the same "foo" website they just visited and the same "foo at foo" they just emailed. They also suggest that Timo could register a domain name in an alt-chain, then "mine" the block by creating a suitable transaction, make sure it's the biggest fee, wait a few confirmations, and they're good to go with the same level of security as Bitcoin proper. Multiple parties can also collaborate to create the transaction, each providing and signing for an input for their portion of the total fee. Moreover, they propose a "two-step sacrifice" protocol to solve the problem of miners getting to keep the fee, making it difficult to get a block mined, or to be sure a block won't be undone later. Finally, they discuss the cost of storing the UTXO set in memory, saying that it would be better to store it in the spent outputs. They also question whether Timo's users will all want to validate some PKI certificates with the blockchain growing at a maximum rate of 55GiB/year.In a conversation from February 9th, 2013 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_Draft-BIP-for-Bloom-filtering.xml b/static/bitcoin-dev/Feb_2013/combined_Draft-BIP-for-Bloom-filtering.xml index d11a8d6a99..595116e93d 100644 --- a/static/bitcoin-dev/Feb_2013/combined_Draft-BIP-for-Bloom-filtering.xml +++ b/static/bitcoin-dev/Feb_2013/combined_Draft-BIP-for-Bloom-filtering.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP for Bloom filtering - 2023-08-01T04:02:04.922697+00:00 + 2025-10-11T22:14:06.328107+00:00 + python-feedgen Mike Hearn 2013-02-20 12:44:56+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for Bloom filtering - 2023-08-01T04:02:04.922697+00:00 + 2025-10-11T22:14:06.328361+00:00 - In the provided context, the author discusses the proposal for delaying the reception of inventory messages (invs) in the Bitcoin Improvement Proposal (BIP). They realize that the current method of delaying invs is arbitrary and suggest a better approach. The proposed solution involves sending a bloom filter in the version message itself, allowing for the filter to be calculated simultaneously with establishing network connections.The author acknowledges that creating a Bloom filter is a fast process. However, they note that deterministic wallets may require multiple calculations to find the keys to scan for. Despite this potential complexity, the proposed approach of including a bloom filter in the version message allows for efficient parallel processing.Additionally, the author mentions the process of obtaining an allocated number for the BIP. They feel that this process may be excessive for their particular proposal. This demonstrates the author's consideration of the existing procedures and their awareness of the broader framework within which their suggestion exists.By addressing the issue of delaying invs and proposing an alternative method involving bloom filters, the author highlights a potential improvement to the Bitcoin protocol. Their understanding of the technical aspects and the existing processes surrounding BIPs lends credibility to their proposal. 2013-02-20T12:44:56+00:00 + In the provided context, the author discusses the proposal for delaying the reception of inventory messages (invs) in the Bitcoin Improvement Proposal (BIP). They realize that the current method of delaying invs is arbitrary and suggest a better approach. The proposed solution involves sending a bloom filter in the version message itself, allowing for the filter to be calculated simultaneously with establishing network connections.The author acknowledges that creating a Bloom filter is a fast process. However, they note that deterministic wallets may require multiple calculations to find the keys to scan for. Despite this potential complexity, the proposed approach of including a bloom filter in the version message allows for efficient parallel processing.Additionally, the author mentions the process of obtaining an allocated number for the BIP. They feel that this process may be excessive for their particular proposal. This demonstrates the author's consideration of the existing procedures and their awareness of the broader framework within which their suggestion exists.By addressing the issue of delaying invs and proposing an alternative method involving bloom filters, the author highlights a potential improvement to the Bitcoin protocol. Their understanding of the technical aspects and the existing processes surrounding BIPs lends credibility to their proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_Fidelity-bonded-ledgers.xml b/static/bitcoin-dev/Feb_2013/combined_Fidelity-bonded-ledgers.xml index 03172fc137..73e94534c4 100644 --- a/static/bitcoin-dev/Feb_2013/combined_Fidelity-bonded-ledgers.xml +++ b/static/bitcoin-dev/Feb_2013/combined_Fidelity-bonded-ledgers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fidelity-bonded ledgers - 2023-08-01T04:28:00.568420+00:00 + 2025-10-11T22:14:04.203989+00:00 + python-feedgen Peter Todd 2013-02-26 02:49:10+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Fidelity-bonded ledgers - 2023-08-01T04:28:00.568420+00:00 + 2025-10-11T22:14:04.204151+00:00 - In a post by Peter Todd, he discusses the idea of simplifying Bitcoin's transaction/scripting system by removing everything except for the transaction/scripting itself. He credits Gregory Maxwell for his ideas on incorporating unspent-chaum-token redemption op-codes into Bitcoin, which led him to develop the concept of the Fidelity-Bonded Ledger.Todd explains that while Bitcoin's transaction/scripting system can prove that a set of public keys authorized the movement of coins, it is flawed as a currency due to the double spend problem. To address this issue, Todd suggests implementing a new opcode and scriptPubKey that can provide proof of double-spend fraud to others. Individuals who can provide proof of a double-spend attempt in the blockchain would be eligible for a reward.Todd proposes that transactions should follow the same scripting system used in Bitcoin, utilizing scriptPubKeys and scriptSigs, while reusing the existing validation machinery. The optional inclusion of a block hash would further link a block into a system that detects double-spend fraud. Withdrawals from the ledger to the blockchain would involve the ledger providing the transaction, and the transaction owner spending it to an address chosen by the ledger.The detection of double-spend is not defined within the Bitcoin validation machinery. Todd presents a simplistic scriptPubKey that allows the ledger to create its own fraud proof and access the funds. However, there is a need to constrain the destination of these spent funds. Token creation and redemption can be audited by tracking the total value of all tokens issued. These tokens are essentially public keys that authorize their own redemption. Clients can demonstrate that their redemption requests have not been honored or that the value of outstanding tokens does not match up.To enforce redemptions, a special unspent txout can be introduced, which can only be spent through the creation of the requested txout, thus transferring the funds to the rightful owner. By adding a small number of opcodes to the existing scripting language, a ledger built on top of Bitcoin can be created. The honesty and performance of this ledger would be incentivized by the potential loss of value.To read the full post by Peter Todd and for further information, please refer to the following link: [link](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-February/002430.html) 2013-02-26T02:49:10+00:00 + In a post by Peter Todd, he discusses the idea of simplifying Bitcoin's transaction/scripting system by removing everything except for the transaction/scripting itself. He credits Gregory Maxwell for his ideas on incorporating unspent-chaum-token redemption op-codes into Bitcoin, which led him to develop the concept of the Fidelity-Bonded Ledger.Todd explains that while Bitcoin's transaction/scripting system can prove that a set of public keys authorized the movement of coins, it is flawed as a currency due to the double spend problem. To address this issue, Todd suggests implementing a new opcode and scriptPubKey that can provide proof of double-spend fraud to others. Individuals who can provide proof of a double-spend attempt in the blockchain would be eligible for a reward.Todd proposes that transactions should follow the same scripting system used in Bitcoin, utilizing scriptPubKeys and scriptSigs, while reusing the existing validation machinery. The optional inclusion of a block hash would further link a block into a system that detects double-spend fraud. Withdrawals from the ledger to the blockchain would involve the ledger providing the transaction, and the transaction owner spending it to an address chosen by the ledger.The detection of double-spend is not defined within the Bitcoin validation machinery. Todd presents a simplistic scriptPubKey that allows the ledger to create its own fraud proof and access the funds. However, there is a need to constrain the destination of these spent funds. Token creation and redemption can be audited by tracking the total value of all tokens issued. These tokens are essentially public keys that authorize their own redemption. Clients can demonstrate that their redemption requests have not been honored or that the value of outstanding tokens does not match up.To enforce redemptions, a special unspent txout can be introduced, which can only be spent through the creation of the requested txout, thus transferring the funds to the rightful owner. By adding a small number of opcodes to the existing scripting language, a ledger built on top of Bitcoin can be created. The honesty and performance of this ledger would be incentivized by the potential loss of value.To read the full post by Peter Todd and for further information, please refer to the following link: [link](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-February/002430.html) - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_How-small-blocks-make-delibrate-orphan-mining-costly.xml b/static/bitcoin-dev/Feb_2013/combined_How-small-blocks-make-delibrate-orphan-mining-costly.xml index baee9d0af9..1f3a3bf374 100644 --- a/static/bitcoin-dev/Feb_2013/combined_How-small-blocks-make-delibrate-orphan-mining-costly.xml +++ b/static/bitcoin-dev/Feb_2013/combined_How-small-blocks-make-delibrate-orphan-mining-costly.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - How small blocks make delibrate orphan mining costly - 2023-08-01T04:27:42.892911+00:00 + 2025-10-11T22:13:51.445534+00:00 + python-feedgen Peter Todd 2013-02-24 01:06:51+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - How small blocks make delibrate orphan mining costly - 2023-08-01T04:27:42.892911+00:00 + 2025-10-11T22:13:51.445673+00:00 - In a future where subsidies for miners are low, fees will become their main source of income. This opens up the possibility for large miners to intentionally mine a block that would orphan the current best block in order to increase their profits. However, this strategy faces limitations when there are restricted block sizes that can only accommodate a certain number of transactions.To counter this issue, the best strategy for miners is to accept the current best block and move on. However, there is a way to defeat this profit-seeking strategy by utilizing nLockTime. Clients can create their transactions with nLockTime set in such a way that only the next block can include the transaction, or even farther into the future if the transaction is not time-sensitive.By implementing nLockTime in this manner, miners would need to mine two blocks in order to gain the transactions from the block they orphaned. This puts more pressure on the block as it becomes full. Utilizing nLockTime in this way does not harm clients and actually provides benefits in the long run.Using nLockTime also helps protect clients from potential losses resulting from deliberate actions by miners. By setting nLockTime appropriately, clients can safeguard themselves against any attempts by miners to orphan blocks and claim their fees.This concept was discussed in 2013 between Peter Todd and an anonymous source. They recognized that fees would become the primary income for miners in a low-subsidy future, leading to the possibility of intentional block orphaning. While a hypothetical scenario involving a 1000BTC fee transaction was mentioned, more realistic examples could arise due to a significant number of transactions with decent fees.Concerns have been raised about slow convergence as miners compete to orphan each other's blocks instead of sniping profitable fees. However, Peter Todd pointed out that if there is already a sufficient backlog or immature nLockTime of transactions with fees exceeding the maximum block size, the incentive for miners to orphan blocks in search of more fees is greatly diminished or eliminated.In summary, the shift towards fees as the main income for miners in a low-subsidy future raises the possibility of intentional block orphaning. However, by utilizing nLockTime and creating transactions with appropriate time locks, clients can protect themselves from potential losses resulting from these actions. Furthermore, if there are already enough high-fee transactions waiting to be added to the blockchain, miners will have no reason to orphan blocks in search of additional fees. 2013-02-24T01:06:51+00:00 + In a future where subsidies for miners are low, fees will become their main source of income. This opens up the possibility for large miners to intentionally mine a block that would orphan the current best block in order to increase their profits. However, this strategy faces limitations when there are restricted block sizes that can only accommodate a certain number of transactions.To counter this issue, the best strategy for miners is to accept the current best block and move on. However, there is a way to defeat this profit-seeking strategy by utilizing nLockTime. Clients can create their transactions with nLockTime set in such a way that only the next block can include the transaction, or even farther into the future if the transaction is not time-sensitive.By implementing nLockTime in this manner, miners would need to mine two blocks in order to gain the transactions from the block they orphaned. This puts more pressure on the block as it becomes full. Utilizing nLockTime in this way does not harm clients and actually provides benefits in the long run.Using nLockTime also helps protect clients from potential losses resulting from deliberate actions by miners. By setting nLockTime appropriately, clients can safeguard themselves against any attempts by miners to orphan blocks and claim their fees.This concept was discussed in 2013 between Peter Todd and an anonymous source. They recognized that fees would become the primary income for miners in a low-subsidy future, leading to the possibility of intentional block orphaning. While a hypothetical scenario involving a 1000BTC fee transaction was mentioned, more realistic examples could arise due to a significant number of transactions with decent fees.Concerns have been raised about slow convergence as miners compete to orphan each other's blocks instead of sniping profitable fees. However, Peter Todd pointed out that if there is already a sufficient backlog or immature nLockTime of transactions with fees exceeding the maximum block size, the incentive for miners to orphan blocks in search of more fees is greatly diminished or eliminated.In summary, the shift towards fees as the main income for miners in a low-subsidy future raises the possibility of intentional block orphaning. However, by utilizing nLockTime and creating transactions with appropriate time locks, clients can protect themselves from potential losses resulting from these actions. Furthermore, if there are already enough high-fee transactions waiting to be added to the blockchain, miners will have no reason to orphan blocks in search of additional fees. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_Implementing-trading-across-chains.xml b/static/bitcoin-dev/Feb_2013/combined_Implementing-trading-across-chains.xml index 105c941e9b..2b7b2d40ac 100644 --- a/static/bitcoin-dev/Feb_2013/combined_Implementing-trading-across-chains.xml +++ b/static/bitcoin-dev/Feb_2013/combined_Implementing-trading-across-chains.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Implementing trading across chains - 2023-08-01T04:24:26.146517+00:00 + 2025-10-11T22:14:08.452290+00:00 + python-feedgen Petr Praus 2013-02-14 21:02:25+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Implementing trading across chains - 2023-08-01T04:24:26.146517+00:00 + 2025-10-11T22:14:08.452456+00:00 - In a 2013 email thread, Petr Praus discusses his plan to implement trading across chains in a P2P manner for his Master's thesis research. He clarifies that this implementation would be done as an alternative chain development and not merged back into the main Bitcoin client. Jorge Timón suggests two related projects - Colored Coins and Ripple - that could be of interest to Petr. Colored Coins allows the use of satoshis to represent smart property, shares, and IOUs of other currencies, which can be atomically traded for Bitcoin. Ripple is a concept where people who trust each other on a network can pay with IOUs transitively. Petr tries Ripple but finds that it lacks contract enforcement built-in. However, he believes that trading across chains is still a valuable feature, even if it's not included in the main client. He also mentions Open Transactions, which can do multicurrency trading but is more ambitious than what he intends to do. Petr prefers to make small changes in the mainline Bitcoin client rather than diving into something entirely new.The discussion also touches on the availability of Ripple's full node (validator) code, as only a JavaScript web client was open-sourced at the time. If trading across "chains" is possible with Ripple, users would have to wait for the release of the full node code. Nonetheless, there are plans for contracts in Ripple, as mentioned in their wiki.Overall, the email thread provides a useful discussion of various related projects and their potential applications in implementing trading across chains in a P2P manner. Petr's intention to implement this as an alternative chain development for his research is highlighted, along with the suggestions from Jorge regarding Colored Coins and Ripple. 2013-02-14T21:02:25+00:00 + In a 2013 email thread, Petr Praus discusses his plan to implement trading across chains in a P2P manner for his Master's thesis research. He clarifies that this implementation would be done as an alternative chain development and not merged back into the main Bitcoin client. Jorge Timón suggests two related projects - Colored Coins and Ripple - that could be of interest to Petr. Colored Coins allows the use of satoshis to represent smart property, shares, and IOUs of other currencies, which can be atomically traded for Bitcoin. Ripple is a concept where people who trust each other on a network can pay with IOUs transitively. Petr tries Ripple but finds that it lacks contract enforcement built-in. However, he believes that trading across chains is still a valuable feature, even if it's not included in the main client. He also mentions Open Transactions, which can do multicurrency trading but is more ambitious than what he intends to do. Petr prefers to make small changes in the mainline Bitcoin client rather than diving into something entirely new.The discussion also touches on the availability of Ripple's full node (validator) code, as only a JavaScript web client was open-sourced at the time. If trading across "chains" is possible with Ripple, users would have to wait for the release of the full node code. Nonetheless, there are plans for contracts in Ripple, as mentioned in their wiki.Overall, the email thread provides a useful discussion of various related projects and their potential applications in implementing trading across chains in a P2P manner. Petr's intention to implement this as an alternative chain development for his research is highlighted, along with the suggestions from Jorge regarding Colored Coins and Ripple. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_Incorporating-block-validation-rule-modifications-into-the-block-chain.xml b/static/bitcoin-dev/Feb_2013/combined_Incorporating-block-validation-rule-modifications-into-the-block-chain.xml index d1019b2712..a7f337831c 100644 --- a/static/bitcoin-dev/Feb_2013/combined_Incorporating-block-validation-rule-modifications-into-the-block-chain.xml +++ b/static/bitcoin-dev/Feb_2013/combined_Incorporating-block-validation-rule-modifications-into-the-block-chain.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Incorporating block validation rule modifications into the block chain - 2023-08-01T04:26:13.563428+00:00 + 2025-10-11T22:13:55.693966+00:00 + python-feedgen Peter Todd 2013-02-18 16:22:35+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Incorporating block validation rule modifications into the block chain - 2023-08-01T04:26:13.564428+00:00 + 2025-10-11T22:13:55.694148+00:00 - The discussion within the Bitcoin community revolves around the importance of maintaining blockspace scarcity and scaling limits. This is seen as crucial to drive non-trivial fees, ensure decentralization, and uphold security promises. It is emphasized that changing the maximum block size should not be taken lightly, as it is considered a significant change.In an email exchange between Raph Frank and another individual, the need for changes to be safe to enforce is highlighted. It is argued that changes based solely on consensus can increase the power of mining, which controls the majority of hashpower. Technical obstacles and moral considerations are also cited as complications in implementing arbitrary rule changes. Therefore, the likelihood of these changes being implemented is deemed low due to engineering challenges and conflicts with the economic motivations and social contract embedded within the system.Another proposal suggests making changes to the "hard" parameters within the Bitcoin protocol by adding a new field to the coinbase transaction. This process involves miners proposing changes and requiring seconding by at least six of the next ten blocks to prevent proposal death. To activate the change, a significant majority of recent or successive blocks must vote in favor, while a significant majority voting against would terminate the proposal. This method could also be used to update NOPs and incorporate signing algorithms but would require a more complex scripting language for defining opcode functions. Each new opcode change may require a version, and client implementations would adapt accordingly. These changes could be made through consensus following the guidelines set by BIP-34. 2013-02-18T16:22:35+00:00 + The discussion within the Bitcoin community revolves around the importance of maintaining blockspace scarcity and scaling limits. This is seen as crucial to drive non-trivial fees, ensure decentralization, and uphold security promises. It is emphasized that changing the maximum block size should not be taken lightly, as it is considered a significant change.In an email exchange between Raph Frank and another individual, the need for changes to be safe to enforce is highlighted. It is argued that changes based solely on consensus can increase the power of mining, which controls the majority of hashpower. Technical obstacles and moral considerations are also cited as complications in implementing arbitrary rule changes. Therefore, the likelihood of these changes being implemented is deemed low due to engineering challenges and conflicts with the economic motivations and social contract embedded within the system.Another proposal suggests making changes to the "hard" parameters within the Bitcoin protocol by adding a new field to the coinbase transaction. This process involves miners proposing changes and requiring seconding by at least six of the next ten blocks to prevent proposal death. To activate the change, a significant majority of recent or successive blocks must vote in favor, while a significant majority voting against would terminate the proposal. This method could also be used to update NOPs and incorporate signing algorithms but would require a more complex scripting language for defining opcode functions. Each new opcode change may require a version, and client implementations would adapt accordingly. These changes could be made through consensus following the guidelines set by BIP-34. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_Key-retirement-and-key-compromise.xml b/static/bitcoin-dev/Feb_2013/combined_Key-retirement-and-key-compromise.xml index 1a35ce7996..3d95280719 100644 --- a/static/bitcoin-dev/Feb_2013/combined_Key-retirement-and-key-compromise.xml +++ b/static/bitcoin-dev/Feb_2013/combined_Key-retirement-and-key-compromise.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Key retirement and key compromise - 2023-08-01T04:26:59.002770+00:00 + 2025-10-11T22:13:53.569097+00:00 + python-feedgen Roy Badami 2013-03-25 21:35:45+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Key retirement and key compromise - 2023-08-01T04:26:59.002770+00:00 + 2025-10-11T22:13:53.569254+00:00 - In a conversation between Gregory Maxwell and Roy Badami, the idea of implementing an overlay protocol to address transactions to revoked addresses in Bitcoin was discussed. This proposal aimed to make such transactions invalid, but it was noted that this would require adding more perpetual data for all validating nodes, leading to a drastic change in the rules. To tackle this problem, Roy suggested that addresses should have expiry dates to avoid maintaining revocation lists indefinitely. It was also mentioned that reusing addresses is generally not recommended, although it may be unavoidable in certain cases. In some use cases, the payment protocol could help mitigate this issue.Roy Badami proposed the concept of an overlay protocol in an email conversation from March 25, 2013. This suggestion was in response to the idea of changing rules to invalidate transactions to revoked addresses. However, another individual pointed out that even implementing an overlay protocol could be significant as it would require perpetual data to remain in fast lookup for all validating nodes. The discussion also emphasized the potential risks of reusing addresses when using Bitcoin.In 2013, Roy suggested the implementation of a "big key compromise button" for Bitcoin, which would transfer all coins to newly generated addresses automatically. However, Andrew Poelstra raised concerns about this idea, as it could expose the public key in use and potentially compromised to attackers. Realizing the need for a means to revoke an address rather than automatic transmissions, Roy proposed an address revocation protocol. This protocol would generate an error if a user tried to send coins to a revoked address. Instead of changing the rules to invalidate transactions to revoked addresses, Roy suggested the implementation of an overlay protocol. This functionality could potentially be incorporated into the payment protocol, although Roy remained unsure about this approach's effectiveness. For the protocol to be useful, it would need to be universally implemented by clients.A related idea discussed was the concept of a "dead" button. This involved sending pre-generated transactions to previously secured addresses in case of an emergency. By using a long-term storage address or set of addresses, coins could be stored and transferred to emergency storage during panic situations using signed transactions. However, if some BTC had been sent or received from the long-term storage, the panic transaction would only capture a portion of it. Nevertheless, the security requirements for the panic transaction leaking were lower than those for private keys, reducing the risk of losing all coins. This idea could be complemented by a server that monitors the blockchain for unauthorized transactions, providing an automated security layer. Opinions on the effectiveness of this approach varied in enterprise scenarios.On February 23, 2013, Roy Badami suggested creating tools to help manage key retirement and compromise for Bitcoin users. Currently, if someone suspects their keys may be compromised, they must create a new wallet and transfer their coins from the old wallet to the new one. This process is cumbersome and results in the loss of the address book and transaction history unless the old wallet is kept. To address this, Roy proposed the inclusion of a "big key compromise button" in Bitcoin. This button would automatically transfer all coins to newly generated addresses and offer the option to flag compromised or retired addresses. Roy believed that this functionality should be developed within the official client, and the first step would involve specifying the desired features. Despite the popularity of deterministic wallets, Roy preferred having a collection of keys since old keys would be regularly retired, with their balances automatically transferring to newly generated keys. Finally, Roy expressed the desire for a panic button that would enable the automatic transfer of all coins to new addresses in case of an accidental mistake like typing the passphrase into an IRC window. The Bitcoin community showed interest in developing this functionality within the official client, but determining the exact desired functionality was considered the initial step. 2013-03-25T21:35:45+00:00 + In a conversation between Gregory Maxwell and Roy Badami, the idea of implementing an overlay protocol to address transactions to revoked addresses in Bitcoin was discussed. This proposal aimed to make such transactions invalid, but it was noted that this would require adding more perpetual data for all validating nodes, leading to a drastic change in the rules. To tackle this problem, Roy suggested that addresses should have expiry dates to avoid maintaining revocation lists indefinitely. It was also mentioned that reusing addresses is generally not recommended, although it may be unavoidable in certain cases. In some use cases, the payment protocol could help mitigate this issue.Roy Badami proposed the concept of an overlay protocol in an email conversation from March 25, 2013. This suggestion was in response to the idea of changing rules to invalidate transactions to revoked addresses. However, another individual pointed out that even implementing an overlay protocol could be significant as it would require perpetual data to remain in fast lookup for all validating nodes. The discussion also emphasized the potential risks of reusing addresses when using Bitcoin.In 2013, Roy suggested the implementation of a "big key compromise button" for Bitcoin, which would transfer all coins to newly generated addresses automatically. However, Andrew Poelstra raised concerns about this idea, as it could expose the public key in use and potentially compromised to attackers. Realizing the need for a means to revoke an address rather than automatic transmissions, Roy proposed an address revocation protocol. This protocol would generate an error if a user tried to send coins to a revoked address. Instead of changing the rules to invalidate transactions to revoked addresses, Roy suggested the implementation of an overlay protocol. This functionality could potentially be incorporated into the payment protocol, although Roy remained unsure about this approach's effectiveness. For the protocol to be useful, it would need to be universally implemented by clients.A related idea discussed was the concept of a "dead" button. This involved sending pre-generated transactions to previously secured addresses in case of an emergency. By using a long-term storage address or set of addresses, coins could be stored and transferred to emergency storage during panic situations using signed transactions. However, if some BTC had been sent or received from the long-term storage, the panic transaction would only capture a portion of it. Nevertheless, the security requirements for the panic transaction leaking were lower than those for private keys, reducing the risk of losing all coins. This idea could be complemented by a server that monitors the blockchain for unauthorized transactions, providing an automated security layer. Opinions on the effectiveness of this approach varied in enterprise scenarios.On February 23, 2013, Roy Badami suggested creating tools to help manage key retirement and compromise for Bitcoin users. Currently, if someone suspects their keys may be compromised, they must create a new wallet and transfer their coins from the old wallet to the new one. This process is cumbersome and results in the loss of the address book and transaction history unless the old wallet is kept. To address this, Roy proposed the inclusion of a "big key compromise button" in Bitcoin. This button would automatically transfer all coins to newly generated addresses and offer the option to flag compromised or retired addresses. Roy believed that this functionality should be developed within the official client, and the first step would involve specifying the desired features. Despite the popularity of deterministic wallets, Roy preferred having a collection of keys since old keys would be regularly retired, with their balances automatically transferring to newly generated keys. Finally, Roy expressed the desire for a panic button that would enable the automatic transfer of all coins to new addresses in case of an accidental mistake like typing the passphrase into an IRC window. The Bitcoin community showed interest in developing this functionality within the official client, but determining the exact desired functionality was considered the initial step. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2013/combined_RFC-empty-scriptPubKeys-and-OP-RETURN-for-marking-unspendable-txouts.xml b/static/bitcoin-dev/Feb_2013/combined_RFC-empty-scriptPubKeys-and-OP-RETURN-for-marking-unspendable-txouts.xml index 79ac41e455..cb43a896cc 100644 --- a/static/bitcoin-dev/Feb_2013/combined_RFC-empty-scriptPubKeys-and-OP-RETURN-for-marking-unspendable-txouts.xml +++ b/static/bitcoin-dev/Feb_2013/combined_RFC-empty-scriptPubKeys-and-OP-RETURN-for-marking-unspendable-txouts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts - 2023-08-01T04:26:32.203091+00:00 + 2025-10-11T22:14:02.081250+00:00 + python-feedgen Mike Hearn 2013-02-13 10:00:35+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts - 2023-08-01T04:26:32.203091+00:00 + 2025-10-11T22:14:02.081456+00:00 - The OP_RETURN bug in Bitcoin was fixed by Satoshi, and it was related to how scripts were executed. In the previous system, the scripts were concatenated and run as a single unit, allowing users to set a scriptSig to OP_RETURN and make the script always evaluate to true. The fix involved moving to the current system where the two scripts are executed independently but share a stack, and only the return value of the scriptPubKey matters. The scripting system was added late in the design process and there is evidence that it was rushed, with many opcodes being disabled later.In a discussion about the fidelity bond concept, Gavin Andresen expressed his opposition to using the OP_RETURN opcode due to its history of causing bugs. Instead, he suggested using OP_FALSE or OP_INVALIDOPCODE for "unspendable" transactions. However, Todd pointed out that using anyone-can-spend transactions might lead to a "spend storm" on the network if there were suddenly a large amount of BTC sitting in unclaimed txouts. To address this, Todd proposed making empty scriptPubKeys standard and adding code so that miners would always try to spend such outputs at the same time. He also discussed various issues and potential optimization problems that could arise from implementing fidelity bonds.In an email exchange between Peter Todd and Gavin Andresen, Todd expressed his support for the fidelity bond concept but had reservations about using the OP_RETURN opcode. He suggested using OP_FALSE or OP_INVALIDOPCODE for "provably unspendable" transactions instead. He also speculated that anyone-can-spend transactions could cause a race among users to spend the available funds before others.The author of the discussion proposes two new features for the fidelity bond protocol. The first feature involves using OP_RETURN at the end of a scriptPubkey to mark an unspendable txout, ensuring immediate pruning. This is preferable to using a spendable scriptPubkey like OP_CHECKSIG, as it could lead to non-standard outputs being created and polluting the UTXO set. The second feature proposed is using an empty scriptPubkey with OP_TRUE or similar to create easily spendable outputs, increasing the incentive to scan the blockchain for sacrifices. This could be used as a way for multiple parties to collectively sign an assurance contract donating to miners. However, there are concerns about buggy custom transaction code accidentally losing funds. Feedback on both ideas is requested. 2013-02-13T10:00:35+00:00 + The OP_RETURN bug in Bitcoin was fixed by Satoshi, and it was related to how scripts were executed. In the previous system, the scripts were concatenated and run as a single unit, allowing users to set a scriptSig to OP_RETURN and make the script always evaluate to true. The fix involved moving to the current system where the two scripts are executed independently but share a stack, and only the return value of the scriptPubKey matters. The scripting system was added late in the design process and there is evidence that it was rushed, with many opcodes being disabled later.In a discussion about the fidelity bond concept, Gavin Andresen expressed his opposition to using the OP_RETURN opcode due to its history of causing bugs. Instead, he suggested using OP_FALSE or OP_INVALIDOPCODE for "unspendable" transactions. However, Todd pointed out that using anyone-can-spend transactions might lead to a "spend storm" on the network if there were suddenly a large amount of BTC sitting in unclaimed txouts. To address this, Todd proposed making empty scriptPubKeys standard and adding code so that miners would always try to spend such outputs at the same time. He also discussed various issues and potential optimization problems that could arise from implementing fidelity bonds.In an email exchange between Peter Todd and Gavin Andresen, Todd expressed his support for the fidelity bond concept but had reservations about using the OP_RETURN opcode. He suggested using OP_FALSE or OP_INVALIDOPCODE for "provably unspendable" transactions instead. He also speculated that anyone-can-spend transactions could cause a race among users to spend the available funds before others.The author of the discussion proposes two new features for the fidelity bond protocol. The first feature involves using OP_RETURN at the end of a scriptPubkey to mark an unspendable txout, ensuring immediate pruning. This is preferable to using a spendable scriptPubkey like OP_CHECKSIG, as it could lead to non-standard outputs being created and polluting the UTXO set. The second feature proposed is using an empty scriptPubkey with OP_TRUE or similar to create easily spendable outputs, increasing the incentive to scan the blockchain for sacrifices. This could be used as a way for multiple parties to collectively sign an assurance contract donating to miners. However, there are concerns about buggy custom transaction code accidentally losing funds. Feedback on both ideas is requested. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_-RFC-BIP-proposal-Dealing-with-malleability.xml b/static/bitcoin-dev/Feb_2014/combined_-RFC-BIP-proposal-Dealing-with-malleability.xml index da1a20c441..f1d14f90bb 100644 --- a/static/bitcoin-dev/Feb_2014/combined_-RFC-BIP-proposal-Dealing-with-malleability.xml +++ b/static/bitcoin-dev/Feb_2014/combined_-RFC-BIP-proposal-Dealing-with-malleability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] [BIP proposal] Dealing with malleability - 2023-08-01T07:38:17.974319+00:00 + 2025-10-11T21:28:11.098591+00:00 + python-feedgen Gregory Maxwell 2014-02-21 06:30:25+00:00 @@ -155,13 +156,13 @@ - python-feedgen + 2 Combined summary - [RFC] [BIP proposal] Dealing with malleability - 2023-08-01T07:38:17.976255+00:00 + 2025-10-11T21:28:11.098778+00:00 - The email conversations on February 20th, 2014, revolve around the support for P2SH in bitcoinj, the request for BIP numbers, the proposal to implement transaction.version=3, and the discussion on transaction malleability and potential solutions. The conversations highlight the competitive nature of the wallet market and the need for wallets to pick up features at different times. There is a consensus on proceeding with Pieter Wuille's plan to implement version 3 transactions, although it may take years for wallets to start generating them. The proposed solutions aim to address transaction malleability and provide non-malleability guarantees for clients while allowing for certain use cases of malleable transactions. The discussions also touch upon the implications of introducing new rules and versions and the potential risks and forks associated with them.One of the main concerns in the Bitcoin community is transaction malleability, which allows a third party to change the unique ID of a transaction. This issue has been a concern for some time, and various solutions have been proposed. One solution is to make version 1 transactions unmalleable and introduce a version 3 that supports malleability features. However, this would require updating all signers to be anti-malleability compatible, which could be challenging. Another proposed solution is to modify signatures to include the entire transaction, but this was deemed unnecessary and ineffective. Instead, it was suggested that the next Bitcoin version could "prettify" all relayed transactions as deterministic transactions, effectively blocking any malleability attack. There are also discussions about using static IDs or canonical transaction hash/ID (cTxID) to eliminate transaction malleability. Armory, a Bitcoin wallet software, already uses a similar approach and has not experienced malleability issues. However, there are concerns about potential security implications if consensus depends on data not hashed in the Merkle structure of a block. The proposed rules to eliminate transaction malleability are not expected to be controversial, but they may require modifications to wallet software and potentially invalidate some script functionality. It was suggested to make CHECKMULTISIG require the dummy value to be exactly equal to OP_FALSE, but concerns were raised about assuming malleability without solid knowledge of ECC signatures. Instead, it was proposed to add a new CHECKSIG mode for cases where malleability must be eliminated and focus on fixing wallet software.Pieter Wuille's proposal aims to eliminate transaction malleability over time by introducing new rules and potentially changing how transactions are handled in Bitcoin software. The proposal is open to feedback from the Bitcoin community. 2014-02-21T06:30:25+00:00 + The email conversations on February 20th, 2014, revolve around the support for P2SH in bitcoinj, the request for BIP numbers, the proposal to implement transaction.version=3, and the discussion on transaction malleability and potential solutions. The conversations highlight the competitive nature of the wallet market and the need for wallets to pick up features at different times. There is a consensus on proceeding with Pieter Wuille's plan to implement version 3 transactions, although it may take years for wallets to start generating them. The proposed solutions aim to address transaction malleability and provide non-malleability guarantees for clients while allowing for certain use cases of malleable transactions. The discussions also touch upon the implications of introducing new rules and versions and the potential risks and forks associated with them.One of the main concerns in the Bitcoin community is transaction malleability, which allows a third party to change the unique ID of a transaction. This issue has been a concern for some time, and various solutions have been proposed. One solution is to make version 1 transactions unmalleable and introduce a version 3 that supports malleability features. However, this would require updating all signers to be anti-malleability compatible, which could be challenging. Another proposed solution is to modify signatures to include the entire transaction, but this was deemed unnecessary and ineffective. Instead, it was suggested that the next Bitcoin version could "prettify" all relayed transactions as deterministic transactions, effectively blocking any malleability attack. There are also discussions about using static IDs or canonical transaction hash/ID (cTxID) to eliminate transaction malleability. Armory, a Bitcoin wallet software, already uses a similar approach and has not experienced malleability issues. However, there are concerns about potential security implications if consensus depends on data not hashed in the Merkle structure of a block. The proposed rules to eliminate transaction malleability are not expected to be controversial, but they may require modifications to wallet software and potentially invalidate some script functionality. It was suggested to make CHECKMULTISIG require the dummy value to be exactly equal to OP_FALSE, but concerns were raised about assuming malleability without solid knowledge of ECC signatures. Instead, it was proposed to add a new CHECKSIG mode for cases where malleability must be eliminated and focus on fixing wallet software.Pieter Wuille's proposal aims to eliminate transaction malleability over time by introducing new rules and potentially changing how transactions are handled in Bitcoin software. The proposal is open to feedback from the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_-space-efficient-reusable-addr-via-weil-pairing-IBE-Re-Bait-for-reusable-addresses-.xml b/static/bitcoin-dev/Feb_2014/combined_-space-efficient-reusable-addr-via-weil-pairing-IBE-Re-Bait-for-reusable-addresses-.xml index fa34731359..a31dedd023 100644 --- a/static/bitcoin-dev/Feb_2014/combined_-space-efficient-reusable-addr-via-weil-pairing-IBE-Re-Bait-for-reusable-addresses-.xml +++ b/static/bitcoin-dev/Feb_2014/combined_-space-efficient-reusable-addr-via-weil-pairing-IBE-Re-Bait-for-reusable-addresses-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses) - 2023-08-01T07:19:18.923860+00:00 + 2025-10-11T21:28:15.360477+00:00 + python-feedgen Adam Back 2014-02-02 15:26:24+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses) - 2023-08-01T07:19:18.924921+00:00 + 2025-10-11T21:28:15.360628+00:00 - The email exchange between Adam Back, Peter Todd, and Jeremy Spilman discusses the use of Identity-Based Encryption (IBE) scheme to increase privacy in transactions. The IBE scheme involves using 'filter' and 'recovery' pubkeys to encrypt a string of zeros called 'filter bait'. This bait is placed in transactions for later decryption by third parties. When enough zeros are decrypted, it is considered a filter pass and the transaction is sent to the payor. Combining IBE schemes with public prefixes can optimize results, but it reduces anonymity when combined with flow analysis. Finding a non-IBE method may be more computationally efficient and indexable. Alternative methods like one-use, stealth, or IBE addresses are also suggested.In another discussion, the focus is on securely delegating block searching by computing the private key for the IBE pub key used for that block and sending it as a query to a random node. The node can decrypt the encrypted bloom baits but cannot correlate them with other payments received by the same user. The payor needs separate pub keys for filtering and recovery. Shared secrets derived from these keys can be given to a semi-trusted third party for trial decryption of filter bait in transactions. A sufficient number of zeros in the decrypted string constitutes a filter pass, and the transaction is given to the payor. The full node uses the private key to decrypt specific bytes in transactions that match the expected layout. This decrypted byte serves as bloom bait. Both schemes can be used together, combining a short public prefix with a private filter.Adam Back also discussed reusable addresses with several people, proposing an ECC-based version to address issues of payment to bandwidth-constrained and frequently offline recipients while maintaining privacy. Bob publicly publishes three pubkeys along with a short prefix. When Alice wants to pay Bob, she creates an ephemeral keypair and derives shared secrets from Bob's pubkeys. She includes the derived pubkey in the transaction along with an encrypted prefix derived from the filter nonce and the prefix. Bob can find the transaction by giving the prefix and filter secret key to a trusted party who scans the blockchain. This method allows Bob to maintain privacy, while Ivan, the scanning party, only gains probabilistic information about possible transactions. Eve remains unaware of the Filter secret key and learns nothing from the blockchain data.The context also mentions the desire for a time-limited Filter pubkey derived from a public random beacon with different keys for each defined time interval. Identity-based cryptography is suggested as a solution where Bob publishes a master public key, allowing derivation of public keys based on the master key and the random beacon value.Adam Back proposed a proof-of-concept solution for better space efficiency and linkability defense reusable addresses using an IBE scheme. He used IBE as a building block to create a sequence of public keys with specific properties. The reusable address becomes an IBE public key, and encryption with the previous block hash serves as the "identity". A separate message for secure delegatable filtering is sent, adding encrypted bloom bait and potentially combining it with extended bloom bait for anonymity set within the block. While reusing addresses is not ideal, Adam Back's proposal aims to make address reuse more private and less likely to leak metadata.Lastly, Adam Back mentioned his idea of a space-efficient alternative to bloom filters using IBE based on weil-pairing. This allows for the delegation of decryption specific to the queried block without the node correlating with queries from the same user in other blocks. Further possibilities of delegating filtering without introducing additional complexity or using public key steganography were discussed.Overall, the discussions revolve around enhancing privacy and efficiency in blockchain transactions through various cryptographic schemes and methods. 2014-02-02T15:26:24+00:00 + The email exchange between Adam Back, Peter Todd, and Jeremy Spilman discusses the use of Identity-Based Encryption (IBE) scheme to increase privacy in transactions. The IBE scheme involves using 'filter' and 'recovery' pubkeys to encrypt a string of zeros called 'filter bait'. This bait is placed in transactions for later decryption by third parties. When enough zeros are decrypted, it is considered a filter pass and the transaction is sent to the payor. Combining IBE schemes with public prefixes can optimize results, but it reduces anonymity when combined with flow analysis. Finding a non-IBE method may be more computationally efficient and indexable. Alternative methods like one-use, stealth, or IBE addresses are also suggested.In another discussion, the focus is on securely delegating block searching by computing the private key for the IBE pub key used for that block and sending it as a query to a random node. The node can decrypt the encrypted bloom baits but cannot correlate them with other payments received by the same user. The payor needs separate pub keys for filtering and recovery. Shared secrets derived from these keys can be given to a semi-trusted third party for trial decryption of filter bait in transactions. A sufficient number of zeros in the decrypted string constitutes a filter pass, and the transaction is given to the payor. The full node uses the private key to decrypt specific bytes in transactions that match the expected layout. This decrypted byte serves as bloom bait. Both schemes can be used together, combining a short public prefix with a private filter.Adam Back also discussed reusable addresses with several people, proposing an ECC-based version to address issues of payment to bandwidth-constrained and frequently offline recipients while maintaining privacy. Bob publicly publishes three pubkeys along with a short prefix. When Alice wants to pay Bob, she creates an ephemeral keypair and derives shared secrets from Bob's pubkeys. She includes the derived pubkey in the transaction along with an encrypted prefix derived from the filter nonce and the prefix. Bob can find the transaction by giving the prefix and filter secret key to a trusted party who scans the blockchain. This method allows Bob to maintain privacy, while Ivan, the scanning party, only gains probabilistic information about possible transactions. Eve remains unaware of the Filter secret key and learns nothing from the blockchain data.The context also mentions the desire for a time-limited Filter pubkey derived from a public random beacon with different keys for each defined time interval. Identity-based cryptography is suggested as a solution where Bob publishes a master public key, allowing derivation of public keys based on the master key and the random beacon value.Adam Back proposed a proof-of-concept solution for better space efficiency and linkability defense reusable addresses using an IBE scheme. He used IBE as a building block to create a sequence of public keys with specific properties. The reusable address becomes an IBE public key, and encryption with the previous block hash serves as the "identity". A separate message for secure delegatable filtering is sent, adding encrypted bloom bait and potentially combining it with extended bloom bait for anonymity set within the block. While reusing addresses is not ideal, Adam Back's proposal aims to make address reuse more private and less likely to leak metadata.Lastly, Adam Back mentioned his idea of a space-efficient alternative to bloom filters using IBE based on weil-pairing. This allows for the delegation of decryption specific to the queried block without the node correlating with queries from the same user in other blocks. Further possibilities of delegating filtering without introducing additional complexity or using public key steganography were discussed.Overall, the discussions revolve around enhancing privacy and efficiency in blockchain transactions through various cryptographic schemes and methods. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_BIP70-Canceling-Payments.xml b/static/bitcoin-dev/Feb_2014/combined_BIP70-Canceling-Payments.xml index 45d8aeae95..6ded39ebca 100644 --- a/static/bitcoin-dev/Feb_2014/combined_BIP70-Canceling-Payments.xml +++ b/static/bitcoin-dev/Feb_2014/combined_BIP70-Canceling-Payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70: Canceling Payments - 2023-08-01T07:34:03.829394+00:00 + 2025-10-11T21:27:45.613239+00:00 + python-feedgen Andreas Schildbach 2014-02-03 21:25:53+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP70: Canceling Payments - 2023-08-01T07:34:03.829394+00:00 + 2025-10-11T21:27:45.613412+00:00 - In the context of implementing BIP70 for payment protocol in face-to-face or real-time scenarios, Christophe Biocca addresses the limitations of HTTP when it comes to sending messages such as "Cancel Payment Request" from merchants to customers. He explains that over HTTP, merchants cannot reach the customer's bitcoin wallet directly, making it impossible to send a cancellation request. Additionally, a "Reject Payment Request" is useless if the customer does not want to send the payment. To solve the issue of invalid payments, Biocca suggests that either the merchant refunds the money or the customer contacts the merchant with a signed request for fund return.Tim Tuxworth further discusses the need for a "Cancel Payment Request" and suggests that a "Reject Payment Request" may also be required in certain business scenarios. Examples provided include situations where a merchant realizes they charged the wrong amount or sent the payment request to the wrong customer, or when a customer decides to pay using an alternative method like cash or credit/debit. Tuxworth proposes that a single message could be used for both scenarios. The author of the post implemented BIP70 using combinations of QR-code or NFC plus Bluetooth and provides a link to a downloadable working preview app.In an email exchange between Tim Tuxworth and Christophe Biocca, Tuxworth questions whether BIP70 is limited to HTTP only and raises concerns about its applicability in face-to-face scenarios, real-time transactions, and socket/bluetooth connections. Biocca responds by explaining that unsolicited merchant-to-consumer messages do not work on HTTP or many other platforms, making it difficult to add them to the payment protocol. He reiterates that over HTTP, merchants cannot directly access the consumer's bitcoin wallet and sending a cancellation request is not possible. However, if the customer chooses not to send the payment, no action is needed. Biocca suggests that the unhappy path scenario with Payment Requests can be resolved by either the merchant refunding the money or the customer contacting the merchant with a signed request for fund return.To summarize, the implementation of BIP70 for payment protocol faces limitations in cancelling payments, especially in scenarios such as face-to-face transactions and real-time interactions. Over HTTP, merchants cannot reach the customer's bitcoin wallet, making it impossible to send a "Cancel Payment Request." However, if a payment becomes invalid, options include the merchant issuing a refund or the customer providing a signed request to the merchant for fund return. Tim Tuxworth emphasizes the need for a "Cancel Payment Request" message and suggests that a "Reject Payment Request" may also be necessary in various business scenarios. These scenarios include cancelling a request before payment is sent, charging the wrong amount, sending the request to the wrong customer, or using alternative payment methods like cash or credit/debit. 2014-02-03T21:25:53+00:00 + In the context of implementing BIP70 for payment protocol in face-to-face or real-time scenarios, Christophe Biocca addresses the limitations of HTTP when it comes to sending messages such as "Cancel Payment Request" from merchants to customers. He explains that over HTTP, merchants cannot reach the customer's bitcoin wallet directly, making it impossible to send a cancellation request. Additionally, a "Reject Payment Request" is useless if the customer does not want to send the payment. To solve the issue of invalid payments, Biocca suggests that either the merchant refunds the money or the customer contacts the merchant with a signed request for fund return.Tim Tuxworth further discusses the need for a "Cancel Payment Request" and suggests that a "Reject Payment Request" may also be required in certain business scenarios. Examples provided include situations where a merchant realizes they charged the wrong amount or sent the payment request to the wrong customer, or when a customer decides to pay using an alternative method like cash or credit/debit. Tuxworth proposes that a single message could be used for both scenarios. The author of the post implemented BIP70 using combinations of QR-code or NFC plus Bluetooth and provides a link to a downloadable working preview app.In an email exchange between Tim Tuxworth and Christophe Biocca, Tuxworth questions whether BIP70 is limited to HTTP only and raises concerns about its applicability in face-to-face scenarios, real-time transactions, and socket/bluetooth connections. Biocca responds by explaining that unsolicited merchant-to-consumer messages do not work on HTTP or many other platforms, making it difficult to add them to the payment protocol. He reiterates that over HTTP, merchants cannot directly access the consumer's bitcoin wallet and sending a cancellation request is not possible. However, if the customer chooses not to send the payment, no action is needed. Biocca suggests that the unhappy path scenario with Payment Requests can be resolved by either the merchant refunding the money or the customer contacting the merchant with a signed request for fund return.To summarize, the implementation of BIP70 for payment protocol faces limitations in cancelling payments, especially in scenarios such as face-to-face transactions and real-time interactions. Over HTTP, merchants cannot reach the customer's bitcoin wallet, making it impossible to send a "Cancel Payment Request." However, if a payment becomes invalid, options include the merchant issuing a refund or the customer providing a signed request to the merchant for fund return. Tim Tuxworth emphasizes the need for a "Cancel Payment Request" message and suggests that a "Reject Payment Request" may also be necessary in various business scenarios. These scenarios include cancelling a request before payment is sent, charging the wrong amount, sending the request to the wrong customer, or using alternative payment methods like cash or credit/debit. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_BIP70-extension-to-allow-for-identity-delegation.xml b/static/bitcoin-dev/Feb_2014/combined_BIP70-extension-to-allow-for-identity-delegation.xml index d7f930f30d..cd1109b138 100644 --- a/static/bitcoin-dev/Feb_2014/combined_BIP70-extension-to-allow-for-identity-delegation.xml +++ b/static/bitcoin-dev/Feb_2014/combined_BIP70-extension-to-allow-for-identity-delegation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70 extension to allow for identity delegation - 2023-08-01T07:45:08.881966+00:00 + 2025-10-11T21:27:34.970959+00:00 + python-feedgen Mike Hearn 2014-03-02 16:14:43+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP70 extension to allow for identity delegation - 2023-08-01T07:45:08.881966+00:00 + 2025-10-11T21:27:34.971129+00:00 - In a 2014 email exchange between Andreas Schildbach and Mike Hearn, concerns were raised about the deployment of a new extension for Bitcoin Improvement Proposal 70 (BIP70). Schildbach believed it was too early to implement the extension widely and questioned whether multiple Public Key Infrastructures (PKIs) could be used at once. Hearn explained that the proposal did not allow for multiple PKIs and clarified that the extension specialized and extended the existing PKI. He also argued against keeping the fix local to X.509, stating that it would sacrifice backwards compatibility.The proposed extension aims to address issues with payment processors and security risks by allowing identity delegation. It suggests creating an extended certificate that would be added to the X509Certificates message in the PaymentRequest. This new certificate would be signed by both the SSL certificate of the payment processor and their delegated ECDSA key. The proposed implementation includes an option for maximum security, where the merchant can set short expiry times on the certificates and upload a new one at the end of each period. This ensures faster resealing in case of payment processor compromise. The proposal also explores alternatives, such as using the User-Agent field or creating the extension certificate as an X.509 cert, but ultimately recommends a unique format to ensure safety.In the email conversation, Dev Random raises concerns about the technical expertise required for small businesses or individuals to perform delegation signature. One solution proposed is to create a simple GUI app that allows them to produce the ExtendedCert file, which can then be sent to the payment processor. However, for small businesses without a CA cert, there are currently no ideal solutions available. Another idea discussed is the possibility of a scheme where a merchant can be namespaced under the payment processor, requiring just one additional field - the merchant identifier. However, the exact definition of the "merchant identifier" is left unresolved. The suggestion of payment processors becoming certificate authorities themselves is also mentioned, with BitPay as an example. However, this would require significant setup and raises questions about the verification process.The current user interface (UI) may not effectively alert users to potential issues with payment processing due to a lack of authenticated fields beyond the memo field available to payment processors. One solution proposed is to include a certificate viewer in the UI, allowing advanced users to inspect the certificate for additional fields. However, this may only benefit advanced users, and there may be difficulties in getting certificate authorities to sign certificates with arbitrary data. It is considered undesirable for users to have to make special requests to their certificate authorities.In another email exchange, Mike Hearn expresses concerns about the security risks associated with payment processors that allow open signups. He warns that hackers could sign up for a payment processor under false identities and swap out payment requests, leading to potential fraud. To address this, he suggests embedding additional information in payment requests, such as specific fields defined in an extension, to be shown reliably in the user interface. The proposal faces difficulties in getting certificate authorities to allow additional fields in certificates, so a simpler solution is suggested: having a single field containing a delimited key/value string (in JSON format) that can be shown as additional lines of labeled text in the UI.The lack of identity delegation in BIP70 poses challenges for payment processors like BitPay and Coinbase, as they have to sign payment requests as themselves, resulting in a confusing UI for users. Mike Hearn proposes a simple extension that allows the creation of an extended certificate, which is similar to X.509 certificates but simpler and Bitcoin-specific. The ExtensionCert message includes an ECDSA public key from the payment processor, signature, and expiry time fields. The merchant can be namespaced under the payment processor, giving the user the correct name in the wallet UI. The memo field can optionally indicate the purpose of the cert. Dev Random suggests a solution for small businesses or individuals without technical expertise, where the payment processor certifies that the merchant generated the invoice directly on their system. The proposal emphasizes the importance of security and simplicity, considering alternatives like using the User-Agent field or creating an X.509 cert but deeming them less safe.The implementation of BIP70 highlights the need for identity delegation, which is not included in version 1. Payment processors face challenges in signing payment requests as themselves, leading to confusion in the user interface. The proposed solution involves creating an extended certificate specific to Bitcoin, called the "extension certificate." This certificate includes the ECDSA public key of the payment processor and is signed using an SSL private key. It is added to the X509Certificates message provided by the payment processor. The PaymentRequest then contains two signature fields: one using the SSL cert of the payment processor and another using the delegated ECDSA key. The proposal also addresses cases where there is no X.509 cert available and explores alternatives to customize the PaymentRequest based on client capabilities. 2014-03-02T16:14:43+00:00 + In a 2014 email exchange between Andreas Schildbach and Mike Hearn, concerns were raised about the deployment of a new extension for Bitcoin Improvement Proposal 70 (BIP70). Schildbach believed it was too early to implement the extension widely and questioned whether multiple Public Key Infrastructures (PKIs) could be used at once. Hearn explained that the proposal did not allow for multiple PKIs and clarified that the extension specialized and extended the existing PKI. He also argued against keeping the fix local to X.509, stating that it would sacrifice backwards compatibility.The proposed extension aims to address issues with payment processors and security risks by allowing identity delegation. It suggests creating an extended certificate that would be added to the X509Certificates message in the PaymentRequest. This new certificate would be signed by both the SSL certificate of the payment processor and their delegated ECDSA key. The proposed implementation includes an option for maximum security, where the merchant can set short expiry times on the certificates and upload a new one at the end of each period. This ensures faster resealing in case of payment processor compromise. The proposal also explores alternatives, such as using the User-Agent field or creating the extension certificate as an X.509 cert, but ultimately recommends a unique format to ensure safety.In the email conversation, Dev Random raises concerns about the technical expertise required for small businesses or individuals to perform delegation signature. One solution proposed is to create a simple GUI app that allows them to produce the ExtendedCert file, which can then be sent to the payment processor. However, for small businesses without a CA cert, there are currently no ideal solutions available. Another idea discussed is the possibility of a scheme where a merchant can be namespaced under the payment processor, requiring just one additional field - the merchant identifier. However, the exact definition of the "merchant identifier" is left unresolved. The suggestion of payment processors becoming certificate authorities themselves is also mentioned, with BitPay as an example. However, this would require significant setup and raises questions about the verification process.The current user interface (UI) may not effectively alert users to potential issues with payment processing due to a lack of authenticated fields beyond the memo field available to payment processors. One solution proposed is to include a certificate viewer in the UI, allowing advanced users to inspect the certificate for additional fields. However, this may only benefit advanced users, and there may be difficulties in getting certificate authorities to sign certificates with arbitrary data. It is considered undesirable for users to have to make special requests to their certificate authorities.In another email exchange, Mike Hearn expresses concerns about the security risks associated with payment processors that allow open signups. He warns that hackers could sign up for a payment processor under false identities and swap out payment requests, leading to potential fraud. To address this, he suggests embedding additional information in payment requests, such as specific fields defined in an extension, to be shown reliably in the user interface. The proposal faces difficulties in getting certificate authorities to allow additional fields in certificates, so a simpler solution is suggested: having a single field containing a delimited key/value string (in JSON format) that can be shown as additional lines of labeled text in the UI.The lack of identity delegation in BIP70 poses challenges for payment processors like BitPay and Coinbase, as they have to sign payment requests as themselves, resulting in a confusing UI for users. Mike Hearn proposes a simple extension that allows the creation of an extended certificate, which is similar to X.509 certificates but simpler and Bitcoin-specific. The ExtensionCert message includes an ECDSA public key from the payment processor, signature, and expiry time fields. The merchant can be namespaced under the payment processor, giving the user the correct name in the wallet UI. The memo field can optionally indicate the purpose of the cert. Dev Random suggests a solution for small businesses or individuals without technical expertise, where the payment processor certifies that the merchant generated the invoice directly on their system. The proposal emphasizes the importance of security and simplicity, considering alternatives like using the User-Agent field or creating an X.509 cert but deeming them less safe.The implementation of BIP70 highlights the need for identity delegation, which is not included in version 1. Payment processors face challenges in signing payment requests as themselves, leading to confusion in the user interface. The proposed solution involves creating an extended certificate specific to Bitcoin, called the "extension certificate." This certificate includes the ECDSA public key of the payment processor and is signed using an SSL private key. It is added to the X509Certificates message provided by the payment processor. The PaymentRequest then contains two signature fields: one using the SSL cert of the payment processor and another using the delegated ECDSA key. The proposal also addresses cases where there is no X.509 cert available and explores alternatives to customize the PaymentRequest based on client capabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_BIP70-proposed-changes.xml b/static/bitcoin-dev/Feb_2014/combined_BIP70-proposed-changes.xml index 8e9a817292..27b1516566 100644 --- a/static/bitcoin-dev/Feb_2014/combined_BIP70-proposed-changes.xml +++ b/static/bitcoin-dev/Feb_2014/combined_BIP70-proposed-changes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70 proposed changes - 2023-08-01T07:40:05.028127+00:00 + 2025-10-11T21:28:13.222720+00:00 + python-feedgen Alon Muroch 2014-05-06 08:22:15+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP70 proposed changes - 2023-08-01T07:40:05.028127+00:00 + 2025-10-11T21:28:13.222844+00:00 - In an email conversation, Odinn Cyberguerrilla discusses the progress of two-factor authentication and bitcoin with the Bitcoin developers Andreas Schildbach and Jeff Garzik. They are working on a decentralized authentication protocol based on bitcoin-like addresses. BitPay is also developing a new standard for authentication and hopes to establish a complete, decentralized authentication protocol with community support. Progress can be followed on their Github page. Odinn also asks about progress on a fully decentralized way of residing on one's device or devices and mentions maidsafe, a decentralized internet platform.Ryan X. Charles suggests that BitPay implement merge avoidance to increase customer and merchant privacy in the payment protocol. He also expresses concerns about X.509 encryption certificates and proposes a new standard for authentication based on bitcoin-like addresses. In another email, Ryan expresses concern about the missing concept of payment status after it has been made and suggests adding a message to return the merchant's view of the transaction status. He also recommends requiring UTC for times in the payment protocol to avoid confusion. Gavin Andresen and Andreas Schildbach provide feedback and suggest changes to BIP70.The email thread also includes discussions about X.509 certificates, the length of Bitcoin URIs, and the possibility of having a UNIX UTC timestamp field in customer payment messages. The conversation covers various technical aspects and potential improvements to the payment protocol. 2014-05-06T08:22:15+00:00 + In an email conversation, Odinn Cyberguerrilla discusses the progress of two-factor authentication and bitcoin with the Bitcoin developers Andreas Schildbach and Jeff Garzik. They are working on a decentralized authentication protocol based on bitcoin-like addresses. BitPay is also developing a new standard for authentication and hopes to establish a complete, decentralized authentication protocol with community support. Progress can be followed on their Github page. Odinn also asks about progress on a fully decentralized way of residing on one's device or devices and mentions maidsafe, a decentralized internet platform.Ryan X. Charles suggests that BitPay implement merge avoidance to increase customer and merchant privacy in the payment protocol. He also expresses concerns about X.509 encryption certificates and proposes a new standard for authentication based on bitcoin-like addresses. In another email, Ryan expresses concern about the missing concept of payment status after it has been made and suggests adding a message to return the merchant's view of the transaction status. He also recommends requiring UTC for times in the payment protocol to avoid confusion. Gavin Andresen and Andreas Schildbach provide feedback and suggest changes to BIP70.The email thread also includes discussions about X.509 certificates, the length of Bitcoin URIs, and the possibility of having a UNIX UTC timestamp field in customer payment messages. The conversation covers various technical aspects and potential improvements to the payment protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Base-32-error-correction-coding.xml b/static/bitcoin-dev/Feb_2014/combined_Base-32-error-correction-coding.xml index 41236c3750..b31a606d3d 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Base-32-error-correction-coding.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Base-32-error-correction-coding.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Base-32 error correction coding - 2023-08-01T07:41:24.513990+00:00 + 2025-10-11T21:27:51.983040+00:00 + python-feedgen Jim Paris 2014-02-24 18:29:31+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Base-32 error correction coding - 2023-08-01T07:41:24.513990+00:00 + 2025-10-11T21:27:51.983200+00:00 - This document proposes a BIP (Bitcoin Improvement Proposal) for a human-friendly base-32 serialization with error correction encoding. The proposed format aims to be useful for helpdesk-related data and future wallet backup & paper wallet serialization formats.The proposed base-32 encoding differs from the default hexadecimal or base58 encodings by including the full range of alphanumeric digits, except for the characters 0, l, v, and 2. These characters are excluded as they can easily be confused with other characters in fonts or handwriting. The proposed encoding also includes automatic correction of up to one transcription error per 31 coded digits, which corresponds to 130 bits of payload data. This means that seamless recovery from up to two transcription errors is possible as long as they occur in separate halves of the coded representation.However, Jim suggests that it may be possible to do better than just correcting single transcription errors. He proposes that the transposition of two adjacent characters or the insertion or deletion of a single character would be very common errors. To address this, he suggests interleaving the two halves of the coded representation to correct transpositions.To implement the error correction encoding, the BIP specifies the usage of Phil Zimmermann's z-base-32 encoding alphabet. This alphabet provides better resistance to transcriptive errors compared to the RFC 3548 standard. The RFC 3548 coder is used for z-base-32, but unnecessary '=' padding characters are stripped before performing the alphabet substitution.In addition to the error correction code transformation of base-32 data, the BIP also specifies a padding scheme for extending numbers or bit vectors of any length to a multiple of 5 bits suitable for base-32 encoding.The error correction encoding described in the BIP utilizes cyclic redundancy check polynomial division. This method requires 5 error correction digits per 26 digits of input, which is slightly less optimal than the theoretical optimum of 4 digits. However, this approach is much easier to implement correctly compared to non-patented error correction codes.While providing an error correction coder for base-32 data is interesting and useful in contexts where base-32 is already deployed, many applications involve encoding integers that are powers of two in length. To address this, the BIP provides a standard scheme for the encoding of any sized bitstring into a multiple of 5 bits in length, suitable for direct encoding into base-32.In summary, this BIP proposes a human-friendly base-32 serialization with error correction encoding. The proposed format includes automatic correction of transcription errors and provides better resistance to transcriptive errors compared to existing standards. It also specifies a padding scheme for extending numbers or bit vectors to a suitable length for base-32 encoding. This proposal aims to be useful for helpdesk-related data and future wallet backup & paper wallet serialization formats. 2014-02-24T18:29:31+00:00 + This document proposes a BIP (Bitcoin Improvement Proposal) for a human-friendly base-32 serialization with error correction encoding. The proposed format aims to be useful for helpdesk-related data and future wallet backup & paper wallet serialization formats.The proposed base-32 encoding differs from the default hexadecimal or base58 encodings by including the full range of alphanumeric digits, except for the characters 0, l, v, and 2. These characters are excluded as they can easily be confused with other characters in fonts or handwriting. The proposed encoding also includes automatic correction of up to one transcription error per 31 coded digits, which corresponds to 130 bits of payload data. This means that seamless recovery from up to two transcription errors is possible as long as they occur in separate halves of the coded representation.However, Jim suggests that it may be possible to do better than just correcting single transcription errors. He proposes that the transposition of two adjacent characters or the insertion or deletion of a single character would be very common errors. To address this, he suggests interleaving the two halves of the coded representation to correct transpositions.To implement the error correction encoding, the BIP specifies the usage of Phil Zimmermann's z-base-32 encoding alphabet. This alphabet provides better resistance to transcriptive errors compared to the RFC 3548 standard. The RFC 3548 coder is used for z-base-32, but unnecessary '=' padding characters are stripped before performing the alphabet substitution.In addition to the error correction code transformation of base-32 data, the BIP also specifies a padding scheme for extending numbers or bit vectors of any length to a multiple of 5 bits suitable for base-32 encoding.The error correction encoding described in the BIP utilizes cyclic redundancy check polynomial division. This method requires 5 error correction digits per 26 digits of input, which is slightly less optimal than the theoretical optimum of 4 digits. However, this approach is much easier to implement correctly compared to non-patented error correction codes.While providing an error correction coder for base-32 data is interesting and useful in contexts where base-32 is already deployed, many applications involve encoding integers that are powers of two in length. To address this, the BIP provides a standard scheme for the encoding of any sized bitstring into a multiple of 5 bits in length, suitable for direct encoding into base-32.In summary, this BIP proposes a human-friendly base-32 serialization with error correction encoding. The proposed format includes automatic correction of transcription errors and provides better resistance to transcriptive errors compared to existing standards. It also specifies a padding scheme for extending numbers or bit vectors to a suitable length for base-32 encoding. This proposal aims to be useful for helpdesk-related data and future wallet backup & paper wallet serialization formats. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Bitcoin-Core-trial-balloon-splitting-blockchain-engine-and-wallet.xml b/static/bitcoin-dev/Feb_2014/combined_Bitcoin-Core-trial-balloon-splitting-blockchain-engine-and-wallet.xml index dbdfa252c7..bb2db9e0b0 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Bitcoin-Core-trial-balloon-splitting-blockchain-engine-and-wallet.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Bitcoin-Core-trial-balloon-splitting-blockchain-engine-and-wallet.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core trial balloon: splitting blockchain engine and wallet - 2023-08-01T07:41:52.928157+00:00 + 2025-10-11T21:27:56.231436+00:00 + python-feedgen Jeff Garzik 2014-02-22 02:08:19+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core trial balloon: splitting blockchain engine and wallet - 2023-08-01T07:41:52.928157+00:00 + 2025-10-11T21:27:56.231585+00:00 - In a conversation between Dustin D. Trammell and Jeff Garzik, the concern about disk space usage when running multiple wallets that require their own copy of the blockchain was discussed. Trammell suggested running a local blockchain server or network instead to optimize disk space. Garzik, a Bitcoin core developer and open source evangelist at BitPay Inc., agreed with Trammell's concern and mentioned that he manages multiple wallets using symlink replacement.Garzik proposed running the Bitcoin Core wallet as a separate process, independent of the blockchain engine. This would involve the wallet communicating with the blockchain engine through RPC and P2P channels, effectively becoming a real SPV client. This plan has several benefits, including sandboxing wallet keys and sensitive data from the network-exposed P2P engine. It also addresses the issue of consuming excessive disk space when managing multiple wallets.Process separation was discussed as a way to increase the difficulty of accessing key data from the blockchain engine and change the attack surface. While not everyone was convinced of its effectiveness, it was agreed that process separation is necessary for sandboxing. The suggestion of using the seccomp mechanism, which whitelists syscalls and renders ptrace useless, was made to enhance security.The Bitcoin Core reference implementation can be used as a payment network access and management tool, in addition to its role as wallet software. Version 0.9 allows the bitcoind wallet to be disabled, leading to a more optimized border router profile. Recent discussions have proposed running the Bitcoin Core wallet as a separate process, communicating with the blockchain engine through existing RPC and P2P channels. This would sandbox wallet keys and sensitive data away from the network-exposed P2P engine. The preference for separate programs over forking was highlighted, especially due to Windows requiring an exec-like method for process separation. Pieter Wuille's work on headers-first sync is important for the wallet/blockchain engine split, but increased review and test bandwidth is necessary.The Bitcoin Core wallet is set to run as a separate process and binary from the blockchain engine. This separation enhances security by isolating wallet keys and sensitive data from the P2P network-exposed engine. Recent IRC discussions have proposed this development, which would involve a new IPC protocol and additional glue code. It was concluded that separate programs are preferable, and Pieter's work on headers-first sync is crucial. However, further review and testing are needed before implementing the separate-binary proposal.In the upcoming version 0.9 of Bitcoin Core, it will be possible to disable the bitcoind wallet, allowing it to be used solely for payment network access and management. This optimization reduces the process size by 40-200MB, making it suitable for a more optimized border router profile. Recent discussions have suggested running the Bitcoin Core wallet as a separate process from the blockchain engine to achieve the security goal of sandboxing wallet keys and sensitive data from the network-exposed P2P engine. While simple forking was considered, Windows requires an exec-like solution for process separation. Using separate programs with IPC (RPC + P2P) was deemed better, as modern operating systems make localhost sockets just as fast as other IPC methods. Pieter's work on headers-first sync is important for the wallet/blockchain engine split, but it necessitates increased review and test bandwidth. The final decision on the separate-binary proposal is still pending. 2014-02-22T02:08:19+00:00 + In a conversation between Dustin D. Trammell and Jeff Garzik, the concern about disk space usage when running multiple wallets that require their own copy of the blockchain was discussed. Trammell suggested running a local blockchain server or network instead to optimize disk space. Garzik, a Bitcoin core developer and open source evangelist at BitPay Inc., agreed with Trammell's concern and mentioned that he manages multiple wallets using symlink replacement.Garzik proposed running the Bitcoin Core wallet as a separate process, independent of the blockchain engine. This would involve the wallet communicating with the blockchain engine through RPC and P2P channels, effectively becoming a real SPV client. This plan has several benefits, including sandboxing wallet keys and sensitive data from the network-exposed P2P engine. It also addresses the issue of consuming excessive disk space when managing multiple wallets.Process separation was discussed as a way to increase the difficulty of accessing key data from the blockchain engine and change the attack surface. While not everyone was convinced of its effectiveness, it was agreed that process separation is necessary for sandboxing. The suggestion of using the seccomp mechanism, which whitelists syscalls and renders ptrace useless, was made to enhance security.The Bitcoin Core reference implementation can be used as a payment network access and management tool, in addition to its role as wallet software. Version 0.9 allows the bitcoind wallet to be disabled, leading to a more optimized border router profile. Recent discussions have proposed running the Bitcoin Core wallet as a separate process, communicating with the blockchain engine through existing RPC and P2P channels. This would sandbox wallet keys and sensitive data away from the network-exposed P2P engine. The preference for separate programs over forking was highlighted, especially due to Windows requiring an exec-like method for process separation. Pieter Wuille's work on headers-first sync is important for the wallet/blockchain engine split, but increased review and test bandwidth is necessary.The Bitcoin Core wallet is set to run as a separate process and binary from the blockchain engine. This separation enhances security by isolating wallet keys and sensitive data from the P2P network-exposed engine. Recent IRC discussions have proposed this development, which would involve a new IPC protocol and additional glue code. It was concluded that separate programs are preferable, and Pieter's work on headers-first sync is crucial. However, further review and testing are needed before implementing the separate-binary proposal.In the upcoming version 0.9 of Bitcoin Core, it will be possible to disable the bitcoind wallet, allowing it to be used solely for payment network access and management. This optimization reduces the process size by 40-200MB, making it suitable for a more optimized border router profile. Recent discussions have suggested running the Bitcoin Core wallet as a separate process from the blockchain engine to achieve the security goal of sandboxing wallet keys and sensitive data from the network-exposed P2P engine. While simple forking was considered, Windows requires an exec-like solution for process separation. Using separate programs with IPC (RPC + P2P) was deemed better, as modern operating systems make localhost sockets just as fast as other IPC methods. Pieter's work on headers-first sync is important for the wallet/blockchain engine split, but it necessitates increased review and test bandwidth. The final decision on the separate-binary proposal is still pending. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Decentralized-digital-asset-exchange-with-honest-pricing-and-market-depth.xml b/static/bitcoin-dev/Feb_2014/combined_Decentralized-digital-asset-exchange-with-honest-pricing-and-market-depth.xml index fb1434f4e4..81fec7ca7b 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Decentralized-digital-asset-exchange-with-honest-pricing-and-market-depth.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Decentralized-digital-asset-exchange-with-honest-pricing-and-market-depth.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Decentralized digital asset exchange with honest pricing and market depth - 2023-08-01T07:35:38.591290+00:00 + 2025-10-11T21:27:39.237790+00:00 + python-feedgen Jorge Timón 2014-03-02 19:03:06+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Decentralized digital asset exchange with honest pricing and market depth - 2023-08-01T07:35:38.591290+00:00 + 2025-10-11T21:27:39.237941+00:00 - Troy Benjegerdes requested a clear design document for developing code for trading between two blockchains. The conversation then shifted towards the importance of accurate historic market data in buying and selling commodities. Some argued that trade is the primary goal of markets, while others emphasized the significance of accurate historic data for traders. Despite the debates, Benjegerdes reiterated his request for working code for cross-chain trades and suggested addressing the historic data problem later.The discussion also touched upon the vulnerability of a Bitmessage-like network to front-running through a sybil attack. It was pointed out that marketplaces face challenges because the data they publish must be public, making them susceptible to attacks. The primary goal of markets was asserted to be trade itself rather than price discovery. While the accuracy of historic data may not be crucial, as long as personal trade data is correct and auditable, buyers and sellers can still exchange goods at a good price. In another email conversation, Peter Todd discussed the possibility of a hard fork to enable marketplaces. He expressed support for testing out the functionality of marketplaces through one-sided trade before considering any forks. Todd disagreed with the argument that a Bitmessage-like network would be easily front-run through a sybil attack. He emphasized that the primary goal of markets is trade, not price discovery. Todd also discussed the importance of accurate historic market data and proposed methods to ensure honesty in records.The context included discussions on cross-chain trading, the limitations of hard forks, and the importance of accurate historic market data. Various viewpoints were presented regarding the role of markets, the vulnerability of networks to attacks, and the need for working code for cross-chain trades. The conversations involved multiple participants who shared their perspectives on these topics.In the given context, a two-step trade mechanism is described that allows for trust-free and atomic transactions. The mechanism involves Alice creating a partial transaction with an input she controls and an output that she controls as well. She gives this partial transaction to Bob, who completes it by providing one or more inputs with a sum value of at least 1BTC and an output for the colored coins to be directed to. Bob signs his inputs with SIGHASH_ALL and broadcasts the transaction, completing the trade.This two-step trade mechanism can also be used to create a decentralized marketplace. Proof-of-publication offers a solution in this case by allowing Alice to embed her incomplete transaction as data in a second, valid transaction. Bidders like Bob can then scan the blockchain for offers with acceptable prices, and unfilled offers at any given block height provide honest information about the market historically.It is mentioned that any embedded consensus system can make use of this two-step trade mechanism as long as it is possible to create transactions where spending a single transaction output moves an asset appropriately. However, extending this mechanism to situations where more than one input needs to be spent or more than one output needs to be created is difficult.An alternative approach could be to create a mechanism where some embedded data signifies the creation of a temporary transfer txout. Spending that txout would then atomically bring about the desired change in the consensus state. This alternative approach would overcome the limitations of the current mechanism when dealing with multiple inputs or outputs. 2014-03-02T19:03:06+00:00 + Troy Benjegerdes requested a clear design document for developing code for trading between two blockchains. The conversation then shifted towards the importance of accurate historic market data in buying and selling commodities. Some argued that trade is the primary goal of markets, while others emphasized the significance of accurate historic data for traders. Despite the debates, Benjegerdes reiterated his request for working code for cross-chain trades and suggested addressing the historic data problem later.The discussion also touched upon the vulnerability of a Bitmessage-like network to front-running through a sybil attack. It was pointed out that marketplaces face challenges because the data they publish must be public, making them susceptible to attacks. The primary goal of markets was asserted to be trade itself rather than price discovery. While the accuracy of historic data may not be crucial, as long as personal trade data is correct and auditable, buyers and sellers can still exchange goods at a good price. In another email conversation, Peter Todd discussed the possibility of a hard fork to enable marketplaces. He expressed support for testing out the functionality of marketplaces through one-sided trade before considering any forks. Todd disagreed with the argument that a Bitmessage-like network would be easily front-run through a sybil attack. He emphasized that the primary goal of markets is trade, not price discovery. Todd also discussed the importance of accurate historic market data and proposed methods to ensure honesty in records.The context included discussions on cross-chain trading, the limitations of hard forks, and the importance of accurate historic market data. Various viewpoints were presented regarding the role of markets, the vulnerability of networks to attacks, and the need for working code for cross-chain trades. The conversations involved multiple participants who shared their perspectives on these topics.In the given context, a two-step trade mechanism is described that allows for trust-free and atomic transactions. The mechanism involves Alice creating a partial transaction with an input she controls and an output that she controls as well. She gives this partial transaction to Bob, who completes it by providing one or more inputs with a sum value of at least 1BTC and an output for the colored coins to be directed to. Bob signs his inputs with SIGHASH_ALL and broadcasts the transaction, completing the trade.This two-step trade mechanism can also be used to create a decentralized marketplace. Proof-of-publication offers a solution in this case by allowing Alice to embed her incomplete transaction as data in a second, valid transaction. Bidders like Bob can then scan the blockchain for offers with acceptable prices, and unfilled offers at any given block height provide honest information about the market historically.It is mentioned that any embedded consensus system can make use of this two-step trade mechanism as long as it is possible to create transactions where spending a single transaction output moves an asset appropriately. However, extending this mechanism to situations where more than one input needs to be spent or more than one output needs to be created is difficult.An alternative approach could be to create a mechanism where some embedded data signifies the creation of a temporary transfer txout. Spending that txout would then atomically bring about the desired change in the consensus state. This alternative approach would overcome the limitations of the current mechanism when dealing with multiple inputs or outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Embedded-consensus-system-upgrade-procedures.xml b/static/bitcoin-dev/Feb_2014/combined_Embedded-consensus-system-upgrade-procedures.xml index 8c9b89948a..c0cdfa460d 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Embedded-consensus-system-upgrade-procedures.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Embedded-consensus-system-upgrade-procedures.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Embedded consensus system upgrade procedures - 2023-08-01T07:34:45.365939+00:00 + 2025-10-11T21:28:17.485157+00:00 + python-feedgen Jorge Timón 2014-02-15 14:43:08+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Embedded consensus system upgrade procedures - 2023-08-01T07:34:45.365939+00:00 + 2025-10-11T21:28:17.485322+00:00 - The author proposes writing contracts like IOUs and vouchers on the blockchain, with the legal contract outside of the chain for them to be enforceable. They argue that data on the blockchain cannot represent a physical or legal entity without consensus and/or authorities in the "real world". The author also warns potential investors that investing in digital asset transfer systems is risky and losing some or all of their investment is possible. They suggest building, testing, using, and trying embedded consensus systems in court to ensure they can be explained in simple language to the decentralized local court systems.The context discusses the limitations of digital asset transfer systems, specifically tracking ownership of contested assets. The author highlights the challenge of documenting rulings from small claims court in an embedded consensus system. They stress the importance of good accounting systems that allow for reversing fraudulent transactions while maintaining a full audit trail. The author acknowledges that courts cannot legislate code and proposes model municipal and county ordinances as a solution. Additionally, the author emphasizes the need to build and test these systems to determine if they meet real-world business needs.In an email exchange between Luke-Jr and Peter Todd, they discuss the idea of upgrading the embedded consensus system with new rules. Luke-Jr argues that this would give developers too much power and establish a central authority. However, Peter Todd counters that users are not forced to upgrade unless they choose to run an operating system with automatic updates. They also discuss the challenge of including consensus from relevant legal jurisdictions when transferring assets that do not solely exist in the blockchain. Luke-Jr clarifies that the only assertion of central authority is from those who download and run the code. He believes that being able to read the code before submitting to it is an improvement over ambiguous legislation or proprietary trading algorithms.On February 9, 2014, Peter Todd expresses concerns about an embedded consensus system that could be upgraded with new rules. He believes that such a system would grant developers too much power and establish a central authority. Todd emphasizes the importance of maintaining a decentralized structure in blockchain technology to ensure security and integrity. He suggests that any changes made to the consensus system should be agreed upon by a majority of participants, rather than dictated by a central authority or a small group of developers.The problem addressed in this context is the potential for double-spending assets during a transition period where some users interpret new consensus rules while others only interpret old ones. The proposed solution is to split actions into separate "decrement" and "increment" operations to prevent double-spending and protect v1 users from being ripped off. The analogy drawn is to proof-of-work cases, and the solution is referred to as an embedded consensus system soft-fork. Colored coins technology implements this principle implicitly with miner validation. It ensures that moving transaction outputs from one owner to another results in the destruction of the colored coin from older software versions' perspective. Implementations should record in their databases the blockhash associated with transactions that affected the state of the consensus but were not yet recognized. After upgrading, these markers can be used to replay blockchain data and arrive at the new consensus. A master digest representing the state of the consensus in the database is also useful for different implementations and instances to ensure they have reached a consensus. 2014-02-15T14:43:08+00:00 + The author proposes writing contracts like IOUs and vouchers on the blockchain, with the legal contract outside of the chain for them to be enforceable. They argue that data on the blockchain cannot represent a physical or legal entity without consensus and/or authorities in the "real world". The author also warns potential investors that investing in digital asset transfer systems is risky and losing some or all of their investment is possible. They suggest building, testing, using, and trying embedded consensus systems in court to ensure they can be explained in simple language to the decentralized local court systems.The context discusses the limitations of digital asset transfer systems, specifically tracking ownership of contested assets. The author highlights the challenge of documenting rulings from small claims court in an embedded consensus system. They stress the importance of good accounting systems that allow for reversing fraudulent transactions while maintaining a full audit trail. The author acknowledges that courts cannot legislate code and proposes model municipal and county ordinances as a solution. Additionally, the author emphasizes the need to build and test these systems to determine if they meet real-world business needs.In an email exchange between Luke-Jr and Peter Todd, they discuss the idea of upgrading the embedded consensus system with new rules. Luke-Jr argues that this would give developers too much power and establish a central authority. However, Peter Todd counters that users are not forced to upgrade unless they choose to run an operating system with automatic updates. They also discuss the challenge of including consensus from relevant legal jurisdictions when transferring assets that do not solely exist in the blockchain. Luke-Jr clarifies that the only assertion of central authority is from those who download and run the code. He believes that being able to read the code before submitting to it is an improvement over ambiguous legislation or proprietary trading algorithms.On February 9, 2014, Peter Todd expresses concerns about an embedded consensus system that could be upgraded with new rules. He believes that such a system would grant developers too much power and establish a central authority. Todd emphasizes the importance of maintaining a decentralized structure in blockchain technology to ensure security and integrity. He suggests that any changes made to the consensus system should be agreed upon by a majority of participants, rather than dictated by a central authority or a small group of developers.The problem addressed in this context is the potential for double-spending assets during a transition period where some users interpret new consensus rules while others only interpret old ones. The proposed solution is to split actions into separate "decrement" and "increment" operations to prevent double-spending and protect v1 users from being ripped off. The analogy drawn is to proof-of-work cases, and the solution is referred to as an embedded consensus system soft-fork. Colored coins technology implements this principle implicitly with miner validation. It ensures that moving transaction outputs from one owner to another results in the destruction of the colored coin from older software versions' perspective. Implementations should record in their databases the blockhash associated with transactions that affected the state of the consensus but were not yet recognized. After upgrading, these markers can be used to replay blockchain data and arrive at the new consensus. A master digest representing the state of the consensus in the database is also useful for different implementations and instances to ensure they have reached a consensus. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Extension-for-BIP-0070-to-support-recurring-payments.xml b/static/bitcoin-dev/Feb_2014/combined_Extension-for-BIP-0070-to-support-recurring-payments.xml index bfbc26f74f..12db3adb54 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Extension-for-BIP-0070-to-support-recurring-payments.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Extension-for-BIP-0070-to-support-recurring-payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Extension for BIP-0070 to support recurring payments - 2023-08-01T07:31:59.306599+00:00 + 2025-10-11T21:27:41.362218+00:00 + python-feedgen Mike Hearn 2014-02-26 10:30:46+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - Extension for BIP-0070 to support recurring payments - 2023-08-01T07:31:59.306599+00:00 + 2025-10-11T21:27:41.362448+00:00 - The email thread discusses the protocol for recurring payments. It covers aspects such as contract negotiation and recurring payment details. The contract sets the payment bounds, while the wallet handles payments within those bounds. The protocol allows for flexibility in specifying payment periods and polling the merchant for pending payments. Multiple contracts can occur, such as when a customer downgrades their subscription. The protocol is designed to allow the wallet to poll the merchant for pending payments without knowing the exact payment date.Feedback from BitPay and others is sought to ensure customer requirements are met. Suggestions include making the RecurringPaymentDetails field optional, specifying periods more flexibly, documenting value constraints, and clarifying the purpose of certain identifiers. The need for a daily option and specifying recurring cycles is also discussed.The team has implemented a BIP0070 extension for recurring billing and tested it with a working prototype. They are awaiting feedback before finalizing the protocol design and merging the code. The team also considers implementing subscription cancellation and upgrade/downgrade features and seeks input on reporting errors to the wallet.The second iteration of the prototype includes subscription cancellation and upgrade/downgrade. The team has checked in both the bitcoinj and php server implementations for testing. They have extended the RecurringPaymentDetails message to accommodate subscription changes and cancellations. A unique subscription ID is used to track multiple contracts with payment bounds and validity periods. Feedback from Kevin is addressed, and suggestions are incorporated into the design.The discussion addresses reporting errors to the wallet and suggests adding a status code in PaymentRequest or using the memo field. Concerns about empty sets of outputs and bitcoin-qt's handling of PaymentRequests without outputs are raised.The proposed protocol aims to enable recurring payments through an extension of BIP-0070. It offers advantages in user control and subscription management tools in wallets. The process involves initial registration, ongoing payments, subscription changes, and cancellation. Wallets poll the merchant for due payments, support overage charges, and handle subscription changes and cancellations. The protocol is still being refined, and feedback on the high-level proposal is welcome.Missed payments are discussed, with suggestions for storing local subscription requests and making payments when the wallet app is running. Canceling subscriptions should be possible at any time, with a courtesy message sent to the merchant. Some propose a textual reminder to send money instead of automated recurring payments to add human review. The implementation of recurring payments could be supported through a Bounty or BIP. The discussion also touches on HTML5 local storage and the challenges faced by decentralized standalone wallet clients. Overall, feedback and suggestions for improvement are welcomed.Jeff Garzik, a Bitcoin core developer and open-source evangelist, emphasizes the importance of users having control over their money. He mentions that recurring payments and subscriptions are frequently requested features in the Bitcoin network but implementing them would require careful planning and execution.In 2014, Stephane Brossier proposed an extension to the Payment Protocol (bip-0070) for recurring payments in Bitcoin. This was in response to the growing popularity of the subscription economy model and the need for a protocol to address this. Stephane's open-source billing platform, Kill Bill, had developed a prototype for recurring billing in Bitcoin, which followed a workflow similar to bip-0070.The proposed workflow involves the wallet receiving a RecurringPaymentRequestAuth that describes the nature of future recurring payments. The customer is prompted by the wallet to authorize it. The wallet then polls the merchant server at specified intervals, and if the merchant issues a PaymentRequest within the accepted bounds set by the customer, the payment is made using the same process as bip-0070.Stéphane is interested in gauging the community's interest in this proposal and is willing to provide more details and implementation using bitcoinj as a wallet and Kill Bill as a merchant server. With Bitcoin becoming more mainstream, defining a protocol for recurring payments is seen as a logical step forward. 2014-02-26T10:30:46+00:00 + The email thread discusses the protocol for recurring payments. It covers aspects such as contract negotiation and recurring payment details. The contract sets the payment bounds, while the wallet handles payments within those bounds. The protocol allows for flexibility in specifying payment periods and polling the merchant for pending payments. Multiple contracts can occur, such as when a customer downgrades their subscription. The protocol is designed to allow the wallet to poll the merchant for pending payments without knowing the exact payment date.Feedback from BitPay and others is sought to ensure customer requirements are met. Suggestions include making the RecurringPaymentDetails field optional, specifying periods more flexibly, documenting value constraints, and clarifying the purpose of certain identifiers. The need for a daily option and specifying recurring cycles is also discussed.The team has implemented a BIP0070 extension for recurring billing and tested it with a working prototype. They are awaiting feedback before finalizing the protocol design and merging the code. The team also considers implementing subscription cancellation and upgrade/downgrade features and seeks input on reporting errors to the wallet.The second iteration of the prototype includes subscription cancellation and upgrade/downgrade. The team has checked in both the bitcoinj and php server implementations for testing. They have extended the RecurringPaymentDetails message to accommodate subscription changes and cancellations. A unique subscription ID is used to track multiple contracts with payment bounds and validity periods. Feedback from Kevin is addressed, and suggestions are incorporated into the design.The discussion addresses reporting errors to the wallet and suggests adding a status code in PaymentRequest or using the memo field. Concerns about empty sets of outputs and bitcoin-qt's handling of PaymentRequests without outputs are raised.The proposed protocol aims to enable recurring payments through an extension of BIP-0070. It offers advantages in user control and subscription management tools in wallets. The process involves initial registration, ongoing payments, subscription changes, and cancellation. Wallets poll the merchant for due payments, support overage charges, and handle subscription changes and cancellations. The protocol is still being refined, and feedback on the high-level proposal is welcome.Missed payments are discussed, with suggestions for storing local subscription requests and making payments when the wallet app is running. Canceling subscriptions should be possible at any time, with a courtesy message sent to the merchant. Some propose a textual reminder to send money instead of automated recurring payments to add human review. The implementation of recurring payments could be supported through a Bounty or BIP. The discussion also touches on HTML5 local storage and the challenges faced by decentralized standalone wallet clients. Overall, feedback and suggestions for improvement are welcomed.Jeff Garzik, a Bitcoin core developer and open-source evangelist, emphasizes the importance of users having control over their money. He mentions that recurring payments and subscriptions are frequently requested features in the Bitcoin network but implementing them would require careful planning and execution.In 2014, Stephane Brossier proposed an extension to the Payment Protocol (bip-0070) for recurring payments in Bitcoin. This was in response to the growing popularity of the subscription economy model and the need for a protocol to address this. Stephane's open-source billing platform, Kill Bill, had developed a prototype for recurring billing in Bitcoin, which followed a workflow similar to bip-0070.The proposed workflow involves the wallet receiving a RecurringPaymentRequestAuth that describes the nature of future recurring payments. The customer is prompted by the wallet to authorize it. The wallet then polls the merchant server at specified intervals, and if the merchant issues a PaymentRequest within the accepted bounds set by the customer, the payment is made using the same process as bip-0070.Stéphane is interested in gauging the community's interest in this proposal and is willing to provide more details and implementation using bitcoinj as a wallet and Kill Bill as a merchant server. With Bitcoin becoming more mainstream, defining a protocol for recurring payments is seen as a logical step forward. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Fee-drop.xml b/static/bitcoin-dev/Feb_2014/combined_Fee-drop.xml index 179e257e04..b6cb6bac6a 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Fee-drop.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Fee-drop.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fee drop - 2023-08-01T07:44:29.688066+00:00 + 2025-10-11T21:28:04.726176+00:00 + python-feedgen Peter Todd 2014-02-28 11:18:26+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Fee drop - 2023-08-01T07:44:29.688066+00:00 + 2025-10-11T21:28:04.726359+00:00 - The discussion revolves around the risk associated with opening a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. There is no expiration policy currently in place, which poses a DoS problem. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources, but it is annoying to do this by hand.The mempool superblock design is suggested as a solution, which keeps getting suggested. It orders the mempool with highest fee/KB first and transactions that paid less than the lowest fee/KB in a max-size mempool would not get relayed at all. However, this makes zero-conf transactions even less safe as attackers can broadcast enough transactions paying X+e fee/KB to push out the unconfirmed tx from mepools around the network and then broadcast a double-spend.In an email thread, Peter Todd raised concerns about the potential for a low-risk DDoS exploit with the implementation of a fee drop. He suggested that a memory-limited mempool prior to release could mitigate this issue. The clearance rate of new low-fee transactions is likely to be small, and in periods of high demand, there have been issues with mempool growth. Additionally, it would be easy to create large groups of low-fee transactions and cheaply double-spend them to consume network bandwidth.Todd also noted that releasing software with known and obvious DoS attack vulnerabilities that did not exist in the previous version is irresponsible. In response, Troy Benjegerdes suggested that including the change would be a good idea and asked for more information on what the DOS attack would look like so that he could trade in anticipation of the market crash. Finally, Benjegerdes commented on the advantage of Bitcoin being that people can learn from its mistakes and that it is not a one-size-fits-all fiat.A mempool janitor change has been pushed out to the Github repository of Bitcoin. The aim was to create a simple, bolt-on change without rewriting the mempool code. Metrics will be run for 48 hours on what does and does not get into the public nodes' mempools, ending Friday midnight EST.Peter Todd raised concerns about whether a memory-limited mempool would be added prior to release in order to avoid an obvious low-risk DDoS exploit. Todd believed that the network bandwidth DoS attack mitigation strategy relies on transactions that are accepted to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small. He suggested that it should be obvious to people how one can create large groups of low-fee transactions and then cheaply double-spend them with higher fee transactions to suck up network bandwidth. He also stated that releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels.Jeff Garzik, a Bitcoin core developer and open-source evangelist, signed off by providing his contact details and BitPay Inc.'s website.The context suggests a possible mitigation for flooding through discussion and process BIP, which needs further thought and analysis before being acted upon. The author presents two possibilities regarding the value of transactions with lower fees, stating that if orphan costs outweigh the value, miners may refuse to include them en-masse. Alternatively, if the total value of transactions is not outweighed by orphan costs, miners may stop including useful transactions and face pressure to change their policies. The author notes that the possibility of a DoS attack through flooding small transactions is only an issue in the first situation and is not the easiest or cheapest method of DoS attack on Bitcoin. However, the author acknowledges the need for more DoS resistance, which requires significant time spent on resource scheduling and code audits. Overall, the context highlights the importance of careful consideration and analysis before implementing any changes to mitigate potential issues.In this discussion, the concern is raised that there may be a large discrepancy between MIN_RELAY and the expected minimum fee needed for a transaction to be included in a block. The relay network uses MIN_RELAY and MIN_DUST to prevent spam, but only transactions that are added to the blockchain actually pay a fee. This creates an opportunity for lower-cost spam. The issue revolves around how close the boundary is between staying above MIN_RELAY and staying out of the blockchain.To address this issue, nodes encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. There is also a suggestion to align mempool selection with the expected block inclusion to optimize resource allocation. For example, a miner would push out cheaper transactions to make room for higher fee transactions based on max block size or orphan rate projections. It is suggested that mempool selection should consider ejecting a random transaction that paid less fees than the incoming transaction from mempool, and also consider how ejection would work with chains of unconfirmed transactions.In this email conversation, Mike Hearn discusses the 2014-02-28T11:18:26+00:00 + The discussion revolves around the risk associated with opening a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. There is no expiration policy currently in place, which poses a DoS problem. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources, but it is annoying to do this by hand.The mempool superblock design is suggested as a solution, which keeps getting suggested. It orders the mempool with highest fee/KB first and transactions that paid less than the lowest fee/KB in a max-size mempool would not get relayed at all. However, this makes zero-conf transactions even less safe as attackers can broadcast enough transactions paying X+e fee/KB to push out the unconfirmed tx from mepools around the network and then broadcast a double-spend.In an email thread, Peter Todd raised concerns about the potential for a low-risk DDoS exploit with the implementation of a fee drop. He suggested that a memory-limited mempool prior to release could mitigate this issue. The clearance rate of new low-fee transactions is likely to be small, and in periods of high demand, there have been issues with mempool growth. Additionally, it would be easy to create large groups of low-fee transactions and cheaply double-spend them to consume network bandwidth.Todd also noted that releasing software with known and obvious DoS attack vulnerabilities that did not exist in the previous version is irresponsible. In response, Troy Benjegerdes suggested that including the change would be a good idea and asked for more information on what the DOS attack would look like so that he could trade in anticipation of the market crash. Finally, Benjegerdes commented on the advantage of Bitcoin being that people can learn from its mistakes and that it is not a one-size-fits-all fiat.A mempool janitor change has been pushed out to the Github repository of Bitcoin. The aim was to create a simple, bolt-on change without rewriting the mempool code. Metrics will be run for 48 hours on what does and does not get into the public nodes' mempools, ending Friday midnight EST.Peter Todd raised concerns about whether a memory-limited mempool would be added prior to release in order to avoid an obvious low-risk DDoS exploit. Todd believed that the network bandwidth DoS attack mitigation strategy relies on transactions that are accepted to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small. He suggested that it should be obvious to people how one can create large groups of low-fee transactions and then cheaply double-spend them with higher fee transactions to suck up network bandwidth. He also stated that releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels.Jeff Garzik, a Bitcoin core developer and open-source evangelist, signed off by providing his contact details and BitPay Inc.'s website.The context suggests a possible mitigation for flooding through discussion and process BIP, which needs further thought and analysis before being acted upon. The author presents two possibilities regarding the value of transactions with lower fees, stating that if orphan costs outweigh the value, miners may refuse to include them en-masse. Alternatively, if the total value of transactions is not outweighed by orphan costs, miners may stop including useful transactions and face pressure to change their policies. The author notes that the possibility of a DoS attack through flooding small transactions is only an issue in the first situation and is not the easiest or cheapest method of DoS attack on Bitcoin. However, the author acknowledges the need for more DoS resistance, which requires significant time spent on resource scheduling and code audits. Overall, the context highlights the importance of careful consideration and analysis before implementing any changes to mitigate potential issues.In this discussion, the concern is raised that there may be a large discrepancy between MIN_RELAY and the expected minimum fee needed for a transaction to be included in a block. The relay network uses MIN_RELAY and MIN_DUST to prevent spam, but only transactions that are added to the blockchain actually pay a fee. This creates an opportunity for lower-cost spam. The issue revolves around how close the boundary is between staying above MIN_RELAY and staying out of the blockchain.To address this issue, nodes encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. There is also a suggestion to align mempool selection with the expected block inclusion to optimize resource allocation. For example, a miner would push out cheaper transactions to make room for higher fee transactions based on max block size or orphan rate projections. It is suggested that mempool selection should consider ejecting a random transaction that paid less fees than the incoming transaction from mempool, and also consider how ejection would work with chains of unconfirmed transactions.In this email conversation, Mike Hearn discusses the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Fwd-Bitcoin-Core-trial-balloon-splitting-blockchain-engine-and-wallet.xml b/static/bitcoin-dev/Feb_2014/combined_Fwd-Bitcoin-Core-trial-balloon-splitting-blockchain-engine-and-wallet.xml index 5120c52cb6..2ae26e6958 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Fwd-Bitcoin-Core-trial-balloon-splitting-blockchain-engine-and-wallet.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Fwd-Bitcoin-Core-trial-balloon-splitting-blockchain-engine-and-wallet.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Bitcoin Core trial balloon: splitting blockchain engine and wallet - 2023-08-01T07:42:17.979598+00:00 + 2025-10-11T21:27:54.107875+00:00 + python-feedgen James Hartig 2014-02-24 22:16:12+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Fwd: Bitcoin Core trial balloon: splitting blockchain engine and wallet - 2023-08-01T07:42:17.980598+00:00 + 2025-10-11T21:27:54.108043+00:00 - A software engineer named James Hartig has highlighted the benefits of using multiple wallets on the same blockchain process. He explains that this allows for cheaper processes by eliminating unused wallet functionality. Additionally, it offers users the flexibility to customize their security measures and run the wallets as the same user without SELinux or file protections. Hartig also mentions that he personally runs three different bitcoind processes on the same server to utilize multiple wallets.In a discussion thread, Wladimir suggests running the blockchain daemon as a system service with its own uid/gid and set of Apparmor/SELinux restrictions, while having the wallet daemon run as the user. This is considered the most straightforward approach. Dustin adds that making this configuration optional would be ideal, rather than forcing everyone to adopt it. In a humorous tone, he suggests punishing those who do not use his configuration with a special task force, jokingly stating that repeated offenders would lose their BitLicense. Wladimir then reminds everyone to focus on reviewing and testing pull requests related to speeding up block synchronization.In an email exchange, Wladimir reiterates his suggestion to run the blockchain daemon as a system service and the wallet daemon as the user. Dustin agrees, noting that this setup allows for sharing one blockchain daemon among multiple users and wallet processes, even if they are not on the same machine. He includes his contact information in his signature.William Yager suggests running the network part of the core as a system service, but Wladimir argues that this may not be practical for most users. He questions if William is simply arguing for the sake of it. No further context or information is provided about this email exchange.The idea of running the network part of the core as a system service is generally seen as a good idea, but it may not be feasible for most users. Instead, a suggestion is made to segregate the two processes, with the blockchain daemon running as a system service and the wallet daemon running as the user. This approach involves implementing unique uid/gid and Apparmor/SELinux restrictions. However, there is a desire to avoid complex schemes that require running things under multiple users.In a discussion about the benefits of having separate processes for the blockchain and wallet daemons in Bitcoin software, Mike Hearn points out that without sandboxing, a separate process would not offer any advantages. Implementing sandboxing in user space is both complex and expensive. Wladimir proposes the most straightforward solution of running the blockchain daemon as a system service with Apparmor/SELinux restrictions and its own uid/gid, while running the wallet daemon as the user. This configuration allows multiple users and wallet processes to share one blockchain daemon, even if they are not on the same machine. 2014-02-24T22:16:12+00:00 + A software engineer named James Hartig has highlighted the benefits of using multiple wallets on the same blockchain process. He explains that this allows for cheaper processes by eliminating unused wallet functionality. Additionally, it offers users the flexibility to customize their security measures and run the wallets as the same user without SELinux or file protections. Hartig also mentions that he personally runs three different bitcoind processes on the same server to utilize multiple wallets.In a discussion thread, Wladimir suggests running the blockchain daemon as a system service with its own uid/gid and set of Apparmor/SELinux restrictions, while having the wallet daemon run as the user. This is considered the most straightforward approach. Dustin adds that making this configuration optional would be ideal, rather than forcing everyone to adopt it. In a humorous tone, he suggests punishing those who do not use his configuration with a special task force, jokingly stating that repeated offenders would lose their BitLicense. Wladimir then reminds everyone to focus on reviewing and testing pull requests related to speeding up block synchronization.In an email exchange, Wladimir reiterates his suggestion to run the blockchain daemon as a system service and the wallet daemon as the user. Dustin agrees, noting that this setup allows for sharing one blockchain daemon among multiple users and wallet processes, even if they are not on the same machine. He includes his contact information in his signature.William Yager suggests running the network part of the core as a system service, but Wladimir argues that this may not be practical for most users. He questions if William is simply arguing for the sake of it. No further context or information is provided about this email exchange.The idea of running the network part of the core as a system service is generally seen as a good idea, but it may not be feasible for most users. Instead, a suggestion is made to segregate the two processes, with the blockchain daemon running as a system service and the wallet daemon running as the user. This approach involves implementing unique uid/gid and Apparmor/SELinux restrictions. However, there is a desire to avoid complex schemes that require running things under multiple users.In a discussion about the benefits of having separate processes for the blockchain and wallet daemons in Bitcoin software, Mike Hearn points out that without sandboxing, a separate process would not offer any advantages. Implementing sandboxing in user space is both complex and expensive. Wladimir proposes the most straightforward solution of running the blockchain daemon as a system service with Apparmor/SELinux restrictions and its own uid/gid, while running the wallet daemon as the user. This configuration allows multiple users and wallet processes to share one blockchain daemon, even if they are not on the same machine. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Malleability-and-MtGox-s-announcement.xml b/static/bitcoin-dev/Feb_2014/combined_Malleability-and-MtGox-s-announcement.xml index 6ab48c3ddc..c6d4914d7b 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Malleability-and-MtGox-s-announcement.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Malleability-and-MtGox-s-announcement.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Malleability and MtGox's announcement - 2023-08-01T07:39:20.409535+00:00 + 2025-10-11T21:28:00.478133+00:00 + python-feedgen Gregory Maxwell 2014-02-10 20:55:21+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Malleability and MtGox's announcement - 2023-08-01T07:39:20.410537+00:00 + 2025-10-11T21:28:00.478291+00:00 - In February 2014, a conversation took place regarding the issue of stalled transactions on MtGox. The discussion mentioned that if an attacker had a direct connection to MtGox, they could receive the transaction directly. However, it was not just attackers who used this script; some people also tried to fix their transactions with honest intent but ended up confusing MtGox's software.The conversation further discussed a potential attack on the Bitcoin blockchain involving renaming transaction IDs before confirmation. By doing so, an attacker could potentially add a new transaction while discarding the original as a double-spend. However, the actual problem with MtGox was that the produced transaction was poorly formatted, causing it to stall. An attacker with a direct connection to MtGox could fix the formatting and forward it normally to the network. They would then stress Gox support and refer to the original transaction ID to trick them into refunding Bitcoins to the attacker's virtual Gox-wallet. To prevent this, the new transaction should re-spend at least one of the coins from the first transaction.In September of 2014, many customers experienced stuck transactions due to MtGox spending immature coins. It was later discovered that these transactions had invalid DER encodings, which led to mutation being used to fix them. There were suspicions that someone may have been exploiting Gox's behavior by reusing already spent coins in new transactions.In a 2014 email exchange, Pieter Wuille expressed surprise at MtGox's announcement of transaction malleability, stating that it had been a known issue for years. He acknowledged that it made infrastructure interactions with Bitcoin more challenging. A question was raised about how attackers could benefit from renaming transaction IDs, fooling Gox support to refund paid Bitcoins. The questioner wondered why so many customers experienced payment defaults or delays when the attacker could double their own transaction. Pieter proposed defining a normalized transaction ID as a way to identify transactions unambiguously.Another discussion on the bitcoin-development mailing list criticized MtGox for blaming a documented bug and accused them of market manipulation. Pieter Wuille responded by noting that transaction malleability was already known and proposed a normalized transaction ID. The concern about off-list discussions and insider power was also raised, suggesting more technical details should be shared publicly. The writer called for transparent code evolution and questioned why revolutions always put the same old things back in power.A member of the Bitcoin-development mailing list expressed frustration with MtGox's lack of transparency and demanded more technical details on their scalability and usability problem. They argued that private off-list discussions were equivalent to insider trading, suggesting that releasing MtGox's code under an AGPLv3 license would solidify their position as transparent market leaders. Pieter Wuille responded by explaining the known issue of transaction malleability and proposing a normalized transaction ID. Another member emphasized that demanding access to MtGox's private code was not the solution and that customers could sue if they felt wronged.The writer expressed concern over off-list discussions and market manipulation, calling for technical details to be shared publicly. Pieter Wuille acknowledged transaction malleability as a known issue and proposed a standardized way to identify transactions. The writer called for transparency and code evolution and asked about a third-party archive of bitcointalk.org.Pieter, a Bitcoin developer, responded to MtGox's announcement about transaction malleability, noting that it had been a known issue for years. He mentioned two direct problems: wallets dealing poorly with modified txids and services using transaction IDs to detect unconfirming transactions. He proposed defining a normalized transaction ID as SHA256^2(normalized_tx + 0x01000000) to make people more aware of the issue. This proposal can be found on GitHub. 2014-02-10T20:55:21+00:00 + In February 2014, a conversation took place regarding the issue of stalled transactions on MtGox. The discussion mentioned that if an attacker had a direct connection to MtGox, they could receive the transaction directly. However, it was not just attackers who used this script; some people also tried to fix their transactions with honest intent but ended up confusing MtGox's software.The conversation further discussed a potential attack on the Bitcoin blockchain involving renaming transaction IDs before confirmation. By doing so, an attacker could potentially add a new transaction while discarding the original as a double-spend. However, the actual problem with MtGox was that the produced transaction was poorly formatted, causing it to stall. An attacker with a direct connection to MtGox could fix the formatting and forward it normally to the network. They would then stress Gox support and refer to the original transaction ID to trick them into refunding Bitcoins to the attacker's virtual Gox-wallet. To prevent this, the new transaction should re-spend at least one of the coins from the first transaction.In September of 2014, many customers experienced stuck transactions due to MtGox spending immature coins. It was later discovered that these transactions had invalid DER encodings, which led to mutation being used to fix them. There were suspicions that someone may have been exploiting Gox's behavior by reusing already spent coins in new transactions.In a 2014 email exchange, Pieter Wuille expressed surprise at MtGox's announcement of transaction malleability, stating that it had been a known issue for years. He acknowledged that it made infrastructure interactions with Bitcoin more challenging. A question was raised about how attackers could benefit from renaming transaction IDs, fooling Gox support to refund paid Bitcoins. The questioner wondered why so many customers experienced payment defaults or delays when the attacker could double their own transaction. Pieter proposed defining a normalized transaction ID as a way to identify transactions unambiguously.Another discussion on the bitcoin-development mailing list criticized MtGox for blaming a documented bug and accused them of market manipulation. Pieter Wuille responded by noting that transaction malleability was already known and proposed a normalized transaction ID. The concern about off-list discussions and insider power was also raised, suggesting more technical details should be shared publicly. The writer called for transparent code evolution and questioned why revolutions always put the same old things back in power.A member of the Bitcoin-development mailing list expressed frustration with MtGox's lack of transparency and demanded more technical details on their scalability and usability problem. They argued that private off-list discussions were equivalent to insider trading, suggesting that releasing MtGox's code under an AGPLv3 license would solidify their position as transparent market leaders. Pieter Wuille responded by explaining the known issue of transaction malleability and proposing a normalized transaction ID. Another member emphasized that demanding access to MtGox's private code was not the solution and that customers could sue if they felt wronged.The writer expressed concern over off-list discussions and market manipulation, calling for technical details to be shared publicly. Pieter Wuille acknowledged transaction malleability as a known issue and proposed a standardized way to identify transactions. The writer called for transparency and code evolution and asked about a third-party archive of bitcointalk.org.Pieter, a Bitcoin developer, responded to MtGox's announcement about transaction malleability, noting that it had been a known issue for years. He mentioned two direct problems: wallets dealing poorly with modified txids and services using transaction IDs to detect unconfirming transactions. He proposed defining a normalized transaction ID as SHA256^2(normalized_tx + 0x01000000) to make people more aware of the issue. This proposal can be found on GitHub. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_MtGox-blames-bitcoin.xml b/static/bitcoin-dev/Feb_2014/combined_MtGox-blames-bitcoin.xml index 3aa80f2071..3a78f2b909 100644 --- a/static/bitcoin-dev/Feb_2014/combined_MtGox-blames-bitcoin.xml +++ b/static/bitcoin-dev/Feb_2014/combined_MtGox-blames-bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - MtGox blames bitcoin - 2023-08-01T07:38:48.629813+00:00 + 2025-10-11T21:28:06.848974+00:00 + python-feedgen naman naman 2014-02-13 12:20:55+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - MtGox blames bitcoin - 2023-08-01T07:38:48.629813+00:00 + 2025-10-11T21:28:06.849182+00:00 - MtGox, a prominent Bitcoin exchange, has faced widespread criticism and legal action due to its faulty wallet implementation. This has sparked debates about the responsibility of MtGox versus the overall integrity of Bitcoin.The blame for the shortcomings of the wallet implementation has been attributed to MtGox, rather than Bitcoin itself. The developers explained that malleability, the process where transaction IDs can be changed, is irrelevant when it comes to basic funds safety. In order to cancel or reissue a payment without risking theft, double-spending must occur. They emphasized the importance of input tracking for cancellation cases and stated that handling mutation is necessary for support and accounting purposes, but not for cancellation security. The developers expressed a willingness to assist MtGox with technical issues and mentioned that removing malleability has been a long-term goal.The implications of this situation are significant, as they highlight the need to distinguish between the actions of specific platforms and the underlying technology they operate on. Critics argue that MtGox failed to properly secure customer funds and implement necessary safeguards. This resulted in a substantial loss of Bitcoins for many users. Legal action has ensued, with lawsuits being filed against the company for negligence and mismanagement.The incident has raised concerns about the overall security and reliability of Bitcoin exchanges, prompting calls for stricter regulations and industry standards. It serves as a cautionary tale for both users and operators within the cryptocurrency ecosystem, emphasizing the importance of thorough due diligence and proper risk management.While the fallout from MtGox's faulty wallet implementation has undoubtedly caused harm to those affected, it is crucial to recognize that the issue lies with the specific platform, rather than Bitcoin itself. This distinction is vital for maintaining trust and confidence in the wider adoption of cryptocurrencies. 2014-02-13T12:20:55+00:00 + MtGox, a prominent Bitcoin exchange, has faced widespread criticism and legal action due to its faulty wallet implementation. This has sparked debates about the responsibility of MtGox versus the overall integrity of Bitcoin.The blame for the shortcomings of the wallet implementation has been attributed to MtGox, rather than Bitcoin itself. The developers explained that malleability, the process where transaction IDs can be changed, is irrelevant when it comes to basic funds safety. In order to cancel or reissue a payment without risking theft, double-spending must occur. They emphasized the importance of input tracking for cancellation cases and stated that handling mutation is necessary for support and accounting purposes, but not for cancellation security. The developers expressed a willingness to assist MtGox with technical issues and mentioned that removing malleability has been a long-term goal.The implications of this situation are significant, as they highlight the need to distinguish between the actions of specific platforms and the underlying technology they operate on. Critics argue that MtGox failed to properly secure customer funds and implement necessary safeguards. This resulted in a substantial loss of Bitcoins for many users. Legal action has ensued, with lawsuits being filed against the company for negligence and mismanagement.The incident has raised concerns about the overall security and reliability of Bitcoin exchanges, prompting calls for stricter regulations and industry standards. It serves as a cautionary tale for both users and operators within the cryptocurrency ecosystem, emphasizing the importance of thorough due diligence and proper risk management.While the fallout from MtGox's faulty wallet implementation has undoubtedly caused harm to those affected, it is crucial to recognize that the issue lies with the specific platform, rather than Bitcoin itself. This distinction is vital for maintaining trust and confidence in the wider adoption of cryptocurrencies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_On-OP-RETURN-in-upcoming-0-9-release.xml b/static/bitcoin-dev/Feb_2014/combined_On-OP-RETURN-in-upcoming-0-9-release.xml index 503dd3bd48..e12edcfe12 100644 --- a/static/bitcoin-dev/Feb_2014/combined_On-OP-RETURN-in-upcoming-0-9-release.xml +++ b/static/bitcoin-dev/Feb_2014/combined_On-OP-RETURN-in-upcoming-0-9-release.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On OP_RETURN in upcoming 0.9 release - 2023-08-01T07:43:43.095545+00:00 + 2025-10-11T21:27:37.111586+00:00 + python-feedgen Drak 2014-02-28 20:10:32+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - On OP_RETURN in upcoming 0.9 release - 2023-08-01T07:43:43.095545+00:00 + 2025-10-11T21:27:37.111778+00:00 - On February 28th, 2014, Warren Togami Jr. emailed the Bitcoin developers mailing list to discuss the issue of transaction fees per kilobyte not accurately reflecting the actual cost to the network. He pointed out that this oversight was a flaw in the original Bitcoin design and shared a link to a GitHub commit by the Litecoin project for more information on the matter.In another email on the same day, Mark Friedenbach brought up the topic of transaction fees not compensating those who validate the blockchain. He argued that this was an externality and suggested that the existing network layer needed to be fixed. Friedenbach also encouraged users to support online privacy by implementing email encryption whenever possible.One of the emails highlighted concerns about transaction fees not covering the costs incurred by full nodes in validating the blockchain. The writer expressed worries about storing large amounts of data in the blockchain without providing compensation for full nodes. A link to a GitHub commit discussing Bitcoin's transaction fees was included in the email.An email conversation between Troy Benjegerdes and Warren Togami further explored the issue of transaction fees. Benjegerdes suggested that either transaction fees should cover any data added to the blockchain or the fee structure needed to be rethought. Togami agreed that transaction fees did not account for the actual cost to the network and identified an economic design flaw in the original Bitcoin design.The Bitcoin-development mailing list also featured suggestions from Mark Friedenbach to reduce the standard line length for regular transactions from 80 to 40 to prevent graffiti messages. He believed that no crypto-related data payload would require more than 40 bytes. Jeff Garzik supported reducing the size but proposed that regular transactions should still have the ability to include some metadata.Andreas Petersson expressed his views on using OP_RETURN and multisig transactions in the blockchain, suggesting that if users wanted to add extra data, they should use OP_RETURN as a better alternative. Petersson believed that block propagation times would have a greater impact on effective fees than dust-limit rules.An email exchange between Jeff Garzik and Jeremy Spilman discussed reducing the size of a max-sized operation push to 40 bytes. Spilman noted that the code did not enforce the most efficient encoding and suggested modifying it to strictly require no PUSHDATA.Gavin Andresen and Pavol Rusnak exchanged emails focusing on the technical aspects of Bitcoin transaction data, specifically related to reducing the standard line length to 40 bytes.The conversation between Pieter Wuille and Jeff Garzik centered around the inclusion of metadata in regular transactions. While Garzik suggested allowing some metadata, Wuille disagreed and pointed out contradictions in Garzik's statements regarding chain data storage endorsement.These emails and conversations collectively touched upon various topics such as transaction fees, data storage in the blockchain, reducing line lengths for transactions, and the inclusion of metadata in regular transactions.The forthcoming 0.9 release of Bitcoin will introduce a change making OP_RETURN standard, enabling the attachment of small amounts of metadata to transactions. However, this change has generated controversy due to concerns about the 80-byte limit on data storage. Supporters argue that this limit is based on 2x SHA256 or 1x SHA512, along with a small amount of metadata.While there are ongoing debates about the size of data storage, it is deemed important for regular transactions to be able to include some metadata. Nevertheless, there are concerns regarding the endorsement of chain data storage. It is crucial to clarify that this change does not endorse storing data in the chain but rather aims to make data less damaging.It should be noted that storing data in forever-unspendable TX outputs can lead to perpetual bloating of the UTXO. To address these concerns and ensure transparency, it is recommended that the release notes for the 0.9 release provide an explanation of this change. By offering clear communication and avoiding contradictory statements, the community can gain a better understanding of the rationale behind this update. 2014-02-28T20:10:32+00:00 + On February 28th, 2014, Warren Togami Jr. emailed the Bitcoin developers mailing list to discuss the issue of transaction fees per kilobyte not accurately reflecting the actual cost to the network. He pointed out that this oversight was a flaw in the original Bitcoin design and shared a link to a GitHub commit by the Litecoin project for more information on the matter.In another email on the same day, Mark Friedenbach brought up the topic of transaction fees not compensating those who validate the blockchain. He argued that this was an externality and suggested that the existing network layer needed to be fixed. Friedenbach also encouraged users to support online privacy by implementing email encryption whenever possible.One of the emails highlighted concerns about transaction fees not covering the costs incurred by full nodes in validating the blockchain. The writer expressed worries about storing large amounts of data in the blockchain without providing compensation for full nodes. A link to a GitHub commit discussing Bitcoin's transaction fees was included in the email.An email conversation between Troy Benjegerdes and Warren Togami further explored the issue of transaction fees. Benjegerdes suggested that either transaction fees should cover any data added to the blockchain or the fee structure needed to be rethought. Togami agreed that transaction fees did not account for the actual cost to the network and identified an economic design flaw in the original Bitcoin design.The Bitcoin-development mailing list also featured suggestions from Mark Friedenbach to reduce the standard line length for regular transactions from 80 to 40 to prevent graffiti messages. He believed that no crypto-related data payload would require more than 40 bytes. Jeff Garzik supported reducing the size but proposed that regular transactions should still have the ability to include some metadata.Andreas Petersson expressed his views on using OP_RETURN and multisig transactions in the blockchain, suggesting that if users wanted to add extra data, they should use OP_RETURN as a better alternative. Petersson believed that block propagation times would have a greater impact on effective fees than dust-limit rules.An email exchange between Jeff Garzik and Jeremy Spilman discussed reducing the size of a max-sized operation push to 40 bytes. Spilman noted that the code did not enforce the most efficient encoding and suggested modifying it to strictly require no PUSHDATA.Gavin Andresen and Pavol Rusnak exchanged emails focusing on the technical aspects of Bitcoin transaction data, specifically related to reducing the standard line length to 40 bytes.The conversation between Pieter Wuille and Jeff Garzik centered around the inclusion of metadata in regular transactions. While Garzik suggested allowing some metadata, Wuille disagreed and pointed out contradictions in Garzik's statements regarding chain data storage endorsement.These emails and conversations collectively touched upon various topics such as transaction fees, data storage in the blockchain, reducing line lengths for transactions, and the inclusion of metadata in regular transactions.The forthcoming 0.9 release of Bitcoin will introduce a change making OP_RETURN standard, enabling the attachment of small amounts of metadata to transactions. However, this change has generated controversy due to concerns about the 80-byte limit on data storage. Supporters argue that this limit is based on 2x SHA256 or 1x SHA512, along with a small amount of metadata.While there are ongoing debates about the size of data storage, it is deemed important for regular transactions to be able to include some metadata. Nevertheless, there are concerns regarding the endorsement of chain data storage. It is crucial to clarify that this change does not endorse storing data in the chain but rather aims to make data less damaging.It should be noted that storing data in forever-unspendable TX outputs can lead to perpetual bloating of the UTXO. To address these concerns and ensure transparency, it is recommended that the release notes for the 0.9 release provide an explanation of this change. By offering clear communication and avoiding contradictory statements, the community can gain a better understanding of the rationale behind this update. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_On-OP-RETURN-in-upcoming-0-9.xml b/static/bitcoin-dev/Feb_2014/combined_On-OP-RETURN-in-upcoming-0-9.xml index e489c50489..6ff5b12a1e 100644 --- a/static/bitcoin-dev/Feb_2014/combined_On-OP-RETURN-in-upcoming-0-9.xml +++ b/static/bitcoin-dev/Feb_2014/combined_On-OP-RETURN-in-upcoming-0-9.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On OP_RETURN in upcoming 0.9 - 2023-08-01T07:43:52.176851+00:00 + 2025-10-11T21:28:19.609203+00:00 + python-feedgen Mark Friedenbach 2014-02-24 22:35:57+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - On OP_RETURN in upcoming 0.9 - 2023-08-01T07:43:52.176851+00:00 + 2025-10-11T21:28:19.609357+00:00 - In a message from February 24, 2014, Tamas Blummer raises a question regarding the spam limit of at least 5430 satoshis when the script is OP_RETURN. Blummer expresses concern that it may be possible to create cheap spam through this method. In response, it is clarified that OP_RETURN outputs are provably unspendable and therefore not included in the UTXO set. The client conducts a check and handles TX_NULL_DATA outputs separately, ensuring they are not considered dust. Tamas Blummer notes that it currently costs 5430 satoshis to create an output. Wladimir, another user, responds by stating that if transactions like this are not abused and there is a need for more space, the limit can always be increased in future versions. It remains unclear whether the same spam limit applies when the script is OP_RETURN, but the original poster expresses concern about the potential for cheap spam. 2014-02-24T22:35:57+00:00 + In a message from February 24, 2014, Tamas Blummer raises a question regarding the spam limit of at least 5430 satoshis when the script is OP_RETURN. Blummer expresses concern that it may be possible to create cheap spam through this method. In response, it is clarified that OP_RETURN outputs are provably unspendable and therefore not included in the UTXO set. The client conducts a check and handles TX_NULL_DATA outputs separately, ensuring they are not considered dust. Tamas Blummer notes that it currently costs 5430 satoshis to create an output. Wladimir, another user, responds by stating that if transactions like this are not abused and there is a need for more space, the limit can always be increased in future versions. It remains unclear whether the same spam limit applies when the script is OP_RETURN, but the original poster expresses concern about the potential for cheap spam. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml b/static/bitcoin-dev/Feb_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml index 40d938ea1c..96e5079e8e 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.614614+00:00 + 2025-10-11T21:27:43.487375+00:00 + python-feedgen Alex Kotenko 2014-07-02 08:49:10+00:00 @@ -271,13 +272,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.615612+00:00 + 2025-10-11T21:27:43.487627+00:00 - In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. 2014-07-02T08:49:10+00:00 + In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_Testnet-block-explorer.xml b/static/bitcoin-dev/Feb_2014/combined_Testnet-block-explorer.xml index 13410e26a6..a2fd3a02da 100644 --- a/static/bitcoin-dev/Feb_2014/combined_Testnet-block-explorer.xml +++ b/static/bitcoin-dev/Feb_2014/combined_Testnet-block-explorer.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Testnet block explorer - 2023-08-01T07:06:39.687518+00:00 + 2025-10-11T21:27:58.355077+00:00 + python-feedgen Matias Alejo Garcia 2014-02-16 14:49:40+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Testnet block explorer - 2023-08-01T07:06:39.687518+00:00 + 2025-10-11T21:27:58.355244+00:00 - Matías Alejo Garcia, a developer for BitPay, has invited people to contribute to the GitHub page for Bitcore and Insight. Insight is a software package that can be downloaded, installed, and used alongside a trusted bitcoind instance. It offers blockchain query capabilities through its REST/Websockets API, which is explained in the Readme document. The demo installations of live.bitcore.io and test.bitcore.io are just for demonstration purposes.Melvin Carvalho has shared information about a free software testnet explorer called test.bitcore.io, which is based on javascript/node. He also mentioned his work on a testnet explorer and the possibility of adding semantic web style markup attributes to the HTML. There is also an API for the testnet block explorer provided by biteasy.com at https://www.biteasy.com/testnet/blocks.On December 27th, 2013, Mike Hearn posted on the Bitcoin-development mailing list about the lack of a reliable testnet block explorer. He mentioned that the original blockexplorer.com was often broken, slow, and not maintained anymore. However, he provided an alternative, a new block explorer called Biteasy, which also had a REST/JSON API. Hearn noted that the coinbase transaction may not necessarily come first in the listing due to it being sorted by "time received". The Biteasy site was built using bitcoinj, and the author could be contacted on IRC with the nick damethos. Hearn also shared information on other testnet explorers such as test.bitcore.io and mentioned his plan to fork the Bitcore explorer to add semantic web style markup attributes to the HTML. He also mentioned that blockr.io planned to add testnet but could not provide an estimate on when it would happen.Eric Lombrozo has created a shell around the bitcoind JSON-RPC, along with a websockets server that provides real-time transaction and block feeds. This shell can be used with bitcoin mainnet, testnet, and alt chains. The layout of the shell is similar to blockchain.info with a bootstrap look-and-feel. Lombrozo apologized for using the css from Ben's site and offered to collaborate with anyone who could help make the styling original. However, the JSON-RPC is missing address indexing and an "unspent" API.There are other testnet explorers mentioned by Melvin Carvalho, such as http://testnet.btclook.com/ and http://test.webbtc.com/. However, these explorers are not fully functional for creating transactions due to the lack of an "unspent" API. Mike Hearn also mentioned the new block explorer at https://www.biteasy.com/testnet/blocks, which is built using bitcoinj and has a REST/JSON API. He noted that the coinbase tx may not come first in the listing as it's sorted by "time received".In summary, there are several options available for testnet block explorers. The original blockexplorer.com is often broken, slow, and not maintained anymore. However, alternatives like Biteasy and test.bitcore.io offer reliable options with REST/JSON APIs. Additionally, Eric Lombrozo has created a shell around the bitcoind JSON-RPC that provides real-time transaction and block feeds. While there are some limitations, such as missing address indexing and an "unspent" API, these explorers provide valuable tools for exploring the testnet. 2014-02-16T14:49:40+00:00 + Matías Alejo Garcia, a developer for BitPay, has invited people to contribute to the GitHub page for Bitcore and Insight. Insight is a software package that can be downloaded, installed, and used alongside a trusted bitcoind instance. It offers blockchain query capabilities through its REST/Websockets API, which is explained in the Readme document. The demo installations of live.bitcore.io and test.bitcore.io are just for demonstration purposes.Melvin Carvalho has shared information about a free software testnet explorer called test.bitcore.io, which is based on javascript/node. He also mentioned his work on a testnet explorer and the possibility of adding semantic web style markup attributes to the HTML. There is also an API for the testnet block explorer provided by biteasy.com at https://www.biteasy.com/testnet/blocks.On December 27th, 2013, Mike Hearn posted on the Bitcoin-development mailing list about the lack of a reliable testnet block explorer. He mentioned that the original blockexplorer.com was often broken, slow, and not maintained anymore. However, he provided an alternative, a new block explorer called Biteasy, which also had a REST/JSON API. Hearn noted that the coinbase transaction may not necessarily come first in the listing due to it being sorted by "time received". The Biteasy site was built using bitcoinj, and the author could be contacted on IRC with the nick damethos. Hearn also shared information on other testnet explorers such as test.bitcore.io and mentioned his plan to fork the Bitcore explorer to add semantic web style markup attributes to the HTML. He also mentioned that blockr.io planned to add testnet but could not provide an estimate on when it would happen.Eric Lombrozo has created a shell around the bitcoind JSON-RPC, along with a websockets server that provides real-time transaction and block feeds. This shell can be used with bitcoin mainnet, testnet, and alt chains. The layout of the shell is similar to blockchain.info with a bootstrap look-and-feel. Lombrozo apologized for using the css from Ben's site and offered to collaborate with anyone who could help make the styling original. However, the JSON-RPC is missing address indexing and an "unspent" API.There are other testnet explorers mentioned by Melvin Carvalho, such as http://testnet.btclook.com/ and http://test.webbtc.com/. However, these explorers are not fully functional for creating transactions due to the lack of an "unspent" API. Mike Hearn also mentioned the new block explorer at https://www.biteasy.com/testnet/blocks, which is built using bitcoinj and has a REST/JSON API. He noted that the coinbase tx may not come first in the listing as it's sorted by "time received".In summary, there are several options available for testnet block explorers. The original blockexplorer.com is often broken, slow, and not maintained anymore. However, alternatives like Biteasy and test.bitcore.io offer reliable options with REST/JSON APIs. Additionally, Eric Lombrozo has created a shell around the bitcoind JSON-RPC that provides real-time transaction and block feeds. While there are some limitations, such as missing address indexing and an "unspent" API, these explorers provide valuable tools for exploring the testnet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_bitcoind-json-API-gettx-raw-newbie-questions-2-.xml b/static/bitcoin-dev/Feb_2014/combined_bitcoind-json-API-gettx-raw-newbie-questions-2-.xml index a8c2693ed9..230a1ff1a7 100644 --- a/static/bitcoin-dev/Feb_2014/combined_bitcoind-json-API-gettx-raw-newbie-questions-2-.xml +++ b/static/bitcoin-dev/Feb_2014/combined_bitcoind-json-API-gettx-raw-newbie-questions-2-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoind json API (gettx/raw) (newbie questions #2) - 2023-08-01T07:39:53.184259+00:00 + 2025-10-11T21:28:02.604288+00:00 + python-feedgen Odinn Cyberguerrilla 2014-02-18 08:17:15+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - bitcoind json API (gettx/raw) (newbie questions #2) - 2023-08-01T07:39:53.184259+00:00 + 2025-10-11T21:28:02.604457+00:00 - The sender of the email is seeking clarification on the gettx / getrawtransaction (decoded) API call and its vout array in the scriptPubKey.addresses array. They are specifically interested in understanding why the information is typed as an array when it typically only contains one address. The sender wonders if there are any cases where the array may contain more or fewer than one address, or if it is designed this way to allow for future extensibility.Additionally, the sender questions the importance of the address in spending coins, suggesting that owning the public/private key contained in the vout script is what matters. They mention their project to calculate unspent outputs and balances for all accounts and express uncertainty about any special cases that need to be considered in order to produce accurate data.In the email, the sender recommends checking out coinb.in/multisig and abis.io, although it is not clear how these resources relate to their inquiries.Overall, the sender seeks assistance in understanding the nuances of the API call and ensuring that their project accurately handles any special cases in the blockchain. 2014-02-18T08:17:15+00:00 + The sender of the email is seeking clarification on the gettx / getrawtransaction (decoded) API call and its vout array in the scriptPubKey.addresses array. They are specifically interested in understanding why the information is typed as an array when it typically only contains one address. The sender wonders if there are any cases where the array may contain more or fewer than one address, or if it is designed this way to allow for future extensibility.Additionally, the sender questions the importance of the address in spending coins, suggesting that owning the public/private key contained in the vout script is what matters. They mention their project to calculate unspent outputs and balances for all accounts and express uncertainty about any special cases that need to be considered in order to produce accurate data.In the email, the sender recommends checking out coinb.in/multisig and abis.io, although it is not clear how these resources relate to their inquiries.Overall, the sender seeks assistance in understanding the nuances of the API call and ensuring that their project accurately handles any special cases in the blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_bitcoinj-0-11-released-with-p2sh-bip39-and-payment-protocol-support.xml b/static/bitcoin-dev/Feb_2014/combined_bitcoinj-0-11-released-with-p2sh-bip39-and-payment-protocol-support.xml index ffef7325d7..d3a82bc1fb 100644 --- a/static/bitcoin-dev/Feb_2014/combined_bitcoinj-0-11-released-with-p2sh-bip39-and-payment-protocol-support.xml +++ b/static/bitcoin-dev/Feb_2014/combined_bitcoinj-0-11-released-with-p2sh-bip39-and-payment-protocol-support.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support - 2023-08-01T07:34:21.370871+00:00 + 2025-10-11T21:27:47.736875+00:00 + python-feedgen Mike Hearn 2014-02-07 10:48:17+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support - 2023-08-01T07:34:21.371877+00:00 + 2025-10-11T21:27:47.737079+00:00 - The context provided revolves around various topics related to the Bitcoin community and digital signatures. Firstly, it is mentioned that the v0.11 tag of bitcoinj has been released, signed by Andreas Schildbach's GPG key with a specific fingerprint. The commit hash for this release is also provided. Additionally, it is noted that PGP keys can be identified by short identifiers, which can cause problems.The author then discusses the issues with the release, including a truncated Git commit hash and an incomplete PGP fingerprint. It is explained that these issues can be exploited by attackers, allowing them to modify the bitcoinj source code and generate insecure private keys. The importance of using at least 128 bits to prevent such attacks is emphasized.The discussion moves on to the use of XOR in a Merkle Tree to timestamp data. Concerns are raised about the authenticity of digests at the bottom of the tree, as an attacker can create arbitrary values that XOR together into the root hash and claim that a particular value is part of the tree by providing its sibling. This issue is further illustrated with an example.The security of XOR as a digest scheme is then compared to a proper hash function. It is argued that while XOR may be easy to create collisions with, it becomes problematic when trying to timestamp data in a Merkle tree. The importance of using a proper hash function for greater security is highlighted.The email threads between Peter Todd and Mike Hearn are briefly summarized. Todd raises bonus questions for budding cryptographers and offers rewards for correct responses. The release of bitcoinj 0.11 is announced, along with some updates and improvements. The conversation includes a humorous exchange between Todd and Jeff Garzik regarding Todd's bonus question.Finally, the release of bitcoinj 0.11 is detailed, mentioning its use in various Bitcoin applications and the specific features and improvements it brings. Bug fixes, API changes, and future plans for the library are also mentioned. 2014-02-07T10:48:17+00:00 + The context provided revolves around various topics related to the Bitcoin community and digital signatures. Firstly, it is mentioned that the v0.11 tag of bitcoinj has been released, signed by Andreas Schildbach's GPG key with a specific fingerprint. The commit hash for this release is also provided. Additionally, it is noted that PGP keys can be identified by short identifiers, which can cause problems.The author then discusses the issues with the release, including a truncated Git commit hash and an incomplete PGP fingerprint. It is explained that these issues can be exploited by attackers, allowing them to modify the bitcoinj source code and generate insecure private keys. The importance of using at least 128 bits to prevent such attacks is emphasized.The discussion moves on to the use of XOR in a Merkle Tree to timestamp data. Concerns are raised about the authenticity of digests at the bottom of the tree, as an attacker can create arbitrary values that XOR together into the root hash and claim that a particular value is part of the tree by providing its sibling. This issue is further illustrated with an example.The security of XOR as a digest scheme is then compared to a proper hash function. It is argued that while XOR may be easy to create collisions with, it becomes problematic when trying to timestamp data in a Merkle tree. The importance of using a proper hash function for greater security is highlighted.The email threads between Peter Todd and Mike Hearn are briefly summarized. Todd raises bonus questions for budding cryptographers and offers rewards for correct responses. The release of bitcoinj 0.11 is announced, along with some updates and improvements. The conversation includes a humorous exchange between Todd and Jeff Garzik regarding Todd's bonus question.Finally, the release of bitcoinj 0.11 is detailed, mentioning its use in various Bitcoin applications and the specific features and improvements it brings. Bug fixes, API changes, and future plans for the library are also mentioned. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_getpeerinfo-results.xml b/static/bitcoin-dev/Feb_2014/combined_getpeerinfo-results.xml index f4fe0c766e..1b0be0197e 100644 --- a/static/bitcoin-dev/Feb_2014/combined_getpeerinfo-results.xml +++ b/static/bitcoin-dev/Feb_2014/combined_getpeerinfo-results.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - getpeerinfo results - 2023-08-01T07:42:36.669772+00:00 + 2025-10-11T21:27:49.859568+00:00 + python-feedgen Wladimir 2014-02-22 08:54:14+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - getpeerinfo results - 2023-08-01T07:42:36.669772+00:00 + 2025-10-11T21:27:49.859742+00:00 - On February 22, 2014, Ronald Hoffman encountered an issue with the "services" field in the latest source code level from Github. Specifically, when connected to his Java node server at 127.0.0.1:8333, the field appeared to be garbled. Initially, Hoffman suspected that he was sending a bad 'version' message, but when he tried using version 0.8.6, he received the correct results. This indicated that something had changed between versions 0.8.6 and 0.9.0.Recognizing the significance of the issue, Wladimir suggested creating an issue on Github to address it. Hoffman proceeded to find and fix the problem, which turned out to be a Windows inttypes.h border case. As a means of testing, Hoffman provided a link for others to use.In further discussions, Hoffman shared a conversation where he used bitcoin-cli to communicate with bitcoind (version 0.9.0), showing the "services" field as "0000000164x". Wladimir inquired about the specific git revision Hoffman was testing with, the compiler used to build it, and the platform it was running on. Additionally, Wladimir asked whether all peers in the getpeerinfo command showed up garbled or if it was just Hoffman's. When Wladimir tested getpeerinfo locally, he found that all his peers displayed the expected value of ""services" : "00000001".In summary, the latest source code level from Github revealed a garbled "services" field when connected to Bitcoind on a Java node server at 127.0.0.1:8333. Despite initially suspecting a bad 'version' message, using version 0.8.6 resulted in correct results. A comparison of the "services" field using the bitcoin-cli command getpeerinfo showed that in version 0.9.0 it appeared garbled as "0000000164x", whereas in version 0.8.6 it was "00000001". 2014-02-22T08:54:14+00:00 + On February 22, 2014, Ronald Hoffman encountered an issue with the "services" field in the latest source code level from Github. Specifically, when connected to his Java node server at 127.0.0.1:8333, the field appeared to be garbled. Initially, Hoffman suspected that he was sending a bad 'version' message, but when he tried using version 0.8.6, he received the correct results. This indicated that something had changed between versions 0.8.6 and 0.9.0.Recognizing the significance of the issue, Wladimir suggested creating an issue on Github to address it. Hoffman proceeded to find and fix the problem, which turned out to be a Windows inttypes.h border case. As a means of testing, Hoffman provided a link for others to use.In further discussions, Hoffman shared a conversation where he used bitcoin-cli to communicate with bitcoind (version 0.9.0), showing the "services" field as "0000000164x". Wladimir inquired about the specific git revision Hoffman was testing with, the compiler used to build it, and the platform it was running on. Additionally, Wladimir asked whether all peers in the getpeerinfo command showed up garbled or if it was just Hoffman's. When Wladimir tested getpeerinfo locally, he found that all his peers displayed the expected value of ""services" : "00000001".In summary, the latest source code level from Github revealed a garbled "services" field when connected to Bitcoind on a Java node server at 127.0.0.1:8333. Despite initially suspecting a bad 'version' message, using version 0.8.6 resulted in correct results. A comparison of the "services" field using the bitcoin-cli command getpeerinfo showed that in version 0.9.0 it appeared garbled as "0000000164x", whereas in version 0.8.6 it was "00000001". - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2014/combined_working-with-the-blockchain-transaction-fees-sum-inputs-sum-outputs-newbie-questions-.xml b/static/bitcoin-dev/Feb_2014/combined_working-with-the-blockchain-transaction-fees-sum-inputs-sum-outputs-newbie-questions-.xml index 87e494bfae..08f3e8dd32 100644 --- a/static/bitcoin-dev/Feb_2014/combined_working-with-the-blockchain-transaction-fees-sum-inputs-sum-outputs-newbie-questions-.xml +++ b/static/bitcoin-dev/Feb_2014/combined_working-with-the-blockchain-transaction-fees-sum-inputs-sum-outputs-newbie-questions-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - working with the blockchain: transaction fees & sum(inputs) != sum(outputs) (newbie questions) - 2023-08-01T07:39:43.354012+00:00 + 2025-10-11T21:28:08.975574+00:00 + python-feedgen Mark Friedenbach 2014-02-14 23:01:41+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - working with the blockchain: transaction fees & sum(inputs) != sum(outputs) (newbie questions) - 2023-08-01T07:39:43.354012+00:00 + 2025-10-11T21:28:08.975739+00:00 - Denis Andrejew is seeking information on how to access unspent outputs and calculate the balance for all addresses in a specific block of the blockchain. He is using bitcoind via rpc as his source of information about the blockchain. Mark Friedenbach suggests that bitcoind keeps this information in a special LevelDB database in the chainstate directory, making it easy to iterate over and obtain the list of all unspent outputs.However, Denis clarifies that he needs to be able to get the unspent outputs and calculate the balance for any particular block he is interested in, not just the current state of the blockchain. In response to Wladimir's helpful input, Denis expresses gratitude and ends his message with a quote from Mahatma Gandhi: "Be the change you want to see in the world."Bitcoin blocks contain a coinbase transaction at the beginning, which is special because it can pay coins to its outputs without having to specify an input. The total value of the outputs of the coinbase transaction cannot exceed the block value plus the fees. This is checked in ConnectBlock in the Bitcoin source code. The coinbase transaction's value is also checked on line 1731. The only transactions in which the sum of the outputs can be larger than the sum of the inputs are the coinbase transactions which cannot have inputs. The outputs from the coinbase transaction can be spent like any other output.The poster, who is new to Bitcoin development, is trying to read the blockchain to find all unspent outputs. They are using bitcoind via rpc as their source of information about the blockchain. However, they are confused about how transaction fees work, especially when there is a gap between the sum of the inputs and the sum of the outputs in a transaction. They understand that this gap is the transaction fee, but they are unsure how the miner can spend it if it is not assigned as an output of any transaction.The poster wonders if there is special code somewhere that keeps track of all the BTC not spent in all the transactions of a block and allows the miner's address to spend it, but they are unclear on the details of how this would work. They are requesting technical explanations of transaction fees and how to find them and account for them in the blockchain. They also ask what other cases might exist where the sum of the input values can be different from the sum of the output values. The only two cases the poster currently understands are "coinbase" transactions that create new coins without inputs, and transaction fees when the sum of the inputs is greater than the sum of the outputs. 2014-02-14T23:01:41+00:00 + Denis Andrejew is seeking information on how to access unspent outputs and calculate the balance for all addresses in a specific block of the blockchain. He is using bitcoind via rpc as his source of information about the blockchain. Mark Friedenbach suggests that bitcoind keeps this information in a special LevelDB database in the chainstate directory, making it easy to iterate over and obtain the list of all unspent outputs.However, Denis clarifies that he needs to be able to get the unspent outputs and calculate the balance for any particular block he is interested in, not just the current state of the blockchain. In response to Wladimir's helpful input, Denis expresses gratitude and ends his message with a quote from Mahatma Gandhi: "Be the change you want to see in the world."Bitcoin blocks contain a coinbase transaction at the beginning, which is special because it can pay coins to its outputs without having to specify an input. The total value of the outputs of the coinbase transaction cannot exceed the block value plus the fees. This is checked in ConnectBlock in the Bitcoin source code. The coinbase transaction's value is also checked on line 1731. The only transactions in which the sum of the outputs can be larger than the sum of the inputs are the coinbase transactions which cannot have inputs. The outputs from the coinbase transaction can be spent like any other output.The poster, who is new to Bitcoin development, is trying to read the blockchain to find all unspent outputs. They are using bitcoind via rpc as their source of information about the blockchain. However, they are confused about how transaction fees work, especially when there is a gap between the sum of the inputs and the sum of the outputs in a transaction. They understand that this gap is the transaction fee, but they are unsure how the miner can spend it if it is not assigned as an output of any transaction.The poster wonders if there is special code somewhere that keeps track of all the BTC not spent in all the transactions of a block and allows the miner's address to spend it, but they are unclear on the details of how this would work. They are requesting technical explanations of transaction fees and how to find them and account for them in the blockchain. They also ask what other cases might exist where the sum of the input values can be different from the sum of the output values. The only two cases the poster currently understands are "coinbase" transactions that create new coins without inputs, and transaction fees when the sum of the inputs is greater than the sum of the outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_-softfork-proposal-Strict-DER-signatures.xml b/static/bitcoin-dev/Feb_2015/combined_-softfork-proposal-Strict-DER-signatures.xml index 6d3a925b5a..5c8ea0968e 100644 --- a/static/bitcoin-dev/Feb_2015/combined_-softfork-proposal-Strict-DER-signatures.xml +++ b/static/bitcoin-dev/Feb_2015/combined_-softfork-proposal-Strict-DER-signatures.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [softfork proposal] Strict DER signatures - 2023-08-01T11:12:49.211700+00:00 + 2025-10-11T21:41:07.088963+00:00 + python-feedgen Pieter Wuille 2015-02-06 21:38:40+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - [softfork proposal] Strict DER signatures - 2023-08-01T11:12:49.211700+00:00 + 2025-10-11T21:41:07.089178+00:00 - In January 2015, Gregory Maxwell requested a BIP number and Pieter Wuille suggested BIP0066 as the response. There are currently four implementations of BIP0066 available, including one for the master and 0.10.0 versions, which have been merged and can be found on GitHub. The implementations for versions 0.9.4 and 0.8.6 can also be located on GitHub. It is important to note that the 0.8 and 0.9 versions have reduced test code due to reliance on new test framework codes in later versions, but the implementation code remains the same.On February 3, 2015, Pieter Wuille proposed a one-line change to BIP66's DERSIG that would softfork. However, he later retracted the proposal after Suhar Daftuas pointed out some uncovered edge-cases. The goal was to separate signature validation and parsing, and to avoid requiring a third return value for signature checking. A cleaner solution was proposed, which only allows an empty byte vector as an invalid signature, aligning signature validity with decoding and simplifying the implementation.In the same email thread on February 3, Gavin Andresen suggested including a change for DERSIG with other changes for version 0.10. Pieter Wuille acknowledged that it may be late for version 0.10, but releasing without the change would require additional work in future releases. The change was just two lines of code and Gavin Andresen agreed with the proposal.Wladimir suggested adding a patch to make non-standard transactions invalid in Bitcoin's 0.10 version. Pieter Wuille proposed a simpler alternative by modifying BIP66's DERSIG with a one-line change that would softfork. Implementing this change before the release of version 0.10 would prevent the need for a second softfork. The change was considered to be just two lines of code.A discussion was held regarding the implementation of a patch to make non-standard transactions invalid in BIP66. It was suggested to add the patch to BIP66's DERSIG as a simple one-line change that would softfork. However, it was deemed late for version 0.10 and hoped to tag rc4 soon. The discussion also included a sponsor from Intel and their Go Parallel Website, which offers resources for parallel software development.Pieter Wuille proposed a softfork to make non-DER signatures illegal. The draft BIP text for this proposal can be found on GitHub. Positive feedback was received from several implementers, including Amir Taak. One concern raised was the possibility of an unlocked spend with an invalidly encoded signature. In those cases, the signature could be mutated to get it mined, but it would need to already pass IsStandard rules. This issue does not cover cases where there is a chain of transactions after the unlocked transaction.In January 2015, Pieter Wuille proposed a softfork to make non-DER signatures illegal. Non-DER signatures have been non-standard since v0.8.0. Wuille provided a draft BIP text on GitHub for the proposal. He requested a BIP number for the proposal.In the email correspondence, Pieter Wuille responded to Zooko Wilcox-OHearn regarding updates made to the BIP text and code for handling invalid signatures in Bitcoin transactions. The changes were synced up with the repository code, and comments were added to the BIP text. There are still multiple ways to encode a correctly encoded but invalid signature, including the 0-length string. Pieter confirms that all branches of the new IsDERSignature() function have been tested and extra test cases have been added. However, there are still TODOs remaining for testing upgrade behavior. Lastly, Pieter fixes a missing comment in the code.In a discussion on January 25, 2015, Matt Whitlock suggested a change to the C++ code used in Bitcoin Core releases. He proposed changing the parameters of functions to be more in line with the spirit of C++. Pieter agreed with the suggestion but noted that one of the motivations for including C++ code was to match the exact code used in previous Bitcoin Core releases.On January 21, 2015, Rusty Russell sent an email addressing the issue of relying on OpenSSL for consensus rules as part of BIP 62. The plan to get rid of this risk was postponed due to unforeseen complexities. However, recent events have made it clear that a fundamental solution is necessary. Russell provided a C++ code snippet to validate signature encoding and several test cases to ensure its validity. Pieter Wuille, a Bitcoin Core developer, has proposed an improvement to the Bitcoin protocol that would replace OpenSSL with libsecp256k1. The proposal aims to provide a more fundamental solution to the problem and involves removing the dependency on OpenSSL and replacing it with the lib 2015-02-06T21:38:40+00:00 + In January 2015, Gregory Maxwell requested a BIP number and Pieter Wuille suggested BIP0066 as the response. There are currently four implementations of BIP0066 available, including one for the master and 0.10.0 versions, which have been merged and can be found on GitHub. The implementations for versions 0.9.4 and 0.8.6 can also be located on GitHub. It is important to note that the 0.8 and 0.9 versions have reduced test code due to reliance on new test framework codes in later versions, but the implementation code remains the same.On February 3, 2015, Pieter Wuille proposed a one-line change to BIP66's DERSIG that would softfork. However, he later retracted the proposal after Suhar Daftuas pointed out some uncovered edge-cases. The goal was to separate signature validation and parsing, and to avoid requiring a third return value for signature checking. A cleaner solution was proposed, which only allows an empty byte vector as an invalid signature, aligning signature validity with decoding and simplifying the implementation.In the same email thread on February 3, Gavin Andresen suggested including a change for DERSIG with other changes for version 0.10. Pieter Wuille acknowledged that it may be late for version 0.10, but releasing without the change would require additional work in future releases. The change was just two lines of code and Gavin Andresen agreed with the proposal.Wladimir suggested adding a patch to make non-standard transactions invalid in Bitcoin's 0.10 version. Pieter Wuille proposed a simpler alternative by modifying BIP66's DERSIG with a one-line change that would softfork. Implementing this change before the release of version 0.10 would prevent the need for a second softfork. The change was considered to be just two lines of code.A discussion was held regarding the implementation of a patch to make non-standard transactions invalid in BIP66. It was suggested to add the patch to BIP66's DERSIG as a simple one-line change that would softfork. However, it was deemed late for version 0.10 and hoped to tag rc4 soon. The discussion also included a sponsor from Intel and their Go Parallel Website, which offers resources for parallel software development.Pieter Wuille proposed a softfork to make non-DER signatures illegal. The draft BIP text for this proposal can be found on GitHub. Positive feedback was received from several implementers, including Amir Taak. One concern raised was the possibility of an unlocked spend with an invalidly encoded signature. In those cases, the signature could be mutated to get it mined, but it would need to already pass IsStandard rules. This issue does not cover cases where there is a chain of transactions after the unlocked transaction.In January 2015, Pieter Wuille proposed a softfork to make non-DER signatures illegal. Non-DER signatures have been non-standard since v0.8.0. Wuille provided a draft BIP text on GitHub for the proposal. He requested a BIP number for the proposal.In the email correspondence, Pieter Wuille responded to Zooko Wilcox-OHearn regarding updates made to the BIP text and code for handling invalid signatures in Bitcoin transactions. The changes were synced up with the repository code, and comments were added to the BIP text. There are still multiple ways to encode a correctly encoded but invalid signature, including the 0-length string. Pieter confirms that all branches of the new IsDERSignature() function have been tested and extra test cases have been added. However, there are still TODOs remaining for testing upgrade behavior. Lastly, Pieter fixes a missing comment in the code.In a discussion on January 25, 2015, Matt Whitlock suggested a change to the C++ code used in Bitcoin Core releases. He proposed changing the parameters of functions to be more in line with the spirit of C++. Pieter agreed with the suggestion but noted that one of the motivations for including C++ code was to match the exact code used in previous Bitcoin Core releases.On January 21, 2015, Rusty Russell sent an email addressing the issue of relying on OpenSSL for consensus rules as part of BIP 62. The plan to get rid of this risk was postponed due to unforeseen complexities. However, recent events have made it clear that a fundamental solution is necessary. Russell provided a C++ code snippet to validate signature encoding and several test cases to ensure its validity. Pieter Wuille, a Bitcoin Core developer, has proposed an improvement to the Bitcoin protocol that would replace OpenSSL with libsecp256k1. The proposal aims to provide a more fundamental solution to the problem and involves removing the dependency on OpenSSL and replacing it with the lib - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_BIP-for-deterministic-pay-to-script-hash-multi-signature-addresses.xml b/static/bitcoin-dev/Feb_2015/combined_BIP-for-deterministic-pay-to-script-hash-multi-signature-addresses.xml index 2be0c39d21..5af85102ab 100644 --- a/static/bitcoin-dev/Feb_2015/combined_BIP-for-deterministic-pay-to-script-hash-multi-signature-addresses.xml +++ b/static/bitcoin-dev/Feb_2015/combined_BIP-for-deterministic-pay-to-script-hash-multi-signature-addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP for deterministic pay-to-script-hash multi-signature addresses - 2023-08-01T11:34:38.505279+00:00 + 2025-10-11T21:40:35.210645+00:00 + python-feedgen Eric Lombrozo 2015-05-24 00:44:20+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP for deterministic pay-to-script-hash multi-signature addresses - 2023-08-01T11:34:38.505279+00:00 + 2025-10-11T21:40:35.210813+00:00 - In February 2015, a discussion took place on the Bitcoin-development mailing list regarding the lack of a specification section in a script template format created by William Swanson and Eric Lombrozo. Luke Dashjr asked if the format supported arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested that all pubkeys executed by all CHECKMULTISIG opcodes should be in canonical order, with some examples provided. However, Todd expressed concern about the rule being too restrictive and not enforced as an IsStandard() rule.The email thread discussed modifications needed for a document to be merged. The BIP being discussed is meant to derive the type of scripts encountered while doing addmultisigaddress. There was a discussion about enforcing a convention for canonical ordering of pubkeys executed by all CHECKMULTISIG opcodes, but it should not be brought into validation rules. It was suggested that wallets could opt-in to this convention for ease of recovery and interoperability reasons.Luke Dashjr and Peter Todd discussed the BIP process for deriving scripts and the need for a Specification section. They agreed that there should be a convention for ordering pubkeys executed by all CHECKMULTISIG opcodes, but it should not be enforced as a soft-fork or IsStandard() rule. Wallets can choose to follow this convention for ease of recovery and interoperability.A proposed standard called BIP44/45 aims to allow software to comply and express compatibility, making it easier for wallet software to be compatible with each other. Questions were raised about whether the specification section supports arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested a rule stating that all pubkeys executed by all CHECKMULTISIG opcodes will be in canonical order, followed by some explanatory examples. However, he noted that there is currently no standard way of discussing arbitrary scripts, so the above rule may be too restrictive in some cases.In an email conversation, Luke Dashjr inquired about the specification section of a BIP. Peter Todd suggested rewriting the BIP to state that all public keys executed by all CHECKMULTISIG opcodes would be in canonical order, with some examples provided. However, he also noted that there is currently no standard way of discussing arbitrary scripts, so this rule may not be sufficient in many cases. Peter Todd further stated that he would not want to enforce this as a soft-fork or make it an IsStandard() rule.On February 12, 2015, Thomas Kerin drafted a Bitcoin Improvement Proposal (BIP) with Jean Pierre and Ruben, describing a method to deterministically generate multi-signature transaction scripts. The proposal aims to allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. The BIP focuses on defining how public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and required signatures. Implementations that do not conform with this BIP may have compatibility issues with strictly-compliant wallets.A new Bitcoin Improvement Proposal (BIP) has been drafted to enable deterministic pay-to-script-hash multi-signature addresses through public key sorting. The BIP proposes a standard method to generate multi-signature transaction scripts and defines how the public keys must be encoded and sorted to ensure that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. This will simplify the derivation of scripts and their addresses by all parties and enable services to declare themselves as BIP compliant, working towards interoperability of services.The adoption of a sorting and encoding standard will ensure that compliant wallets produce the same P2SH address for the same given set of keys and required signature count, which is particularly beneficial for multisignature hierarchical-deterministic wallets as less state is required to set up multi-signature accounts. The proposed method requires that public keys be received in compressed form, sorted lexicographically according to their binary representation, and used in a standard multisig redeem script before being hashed according to BIP-0016 to get the P2SH address.Although the BIP is compatible with compressed keys only, it will enable implementations that adopt this standard to be cross-compatible when choosing multisig addresses. However, a group of users that are not entirely compliant could result in one participant deriving an address that the others will not recognize.The context also includes a PGP signature for cryptographic authentication, an HTML attachment that has been scrubbed, and two non-text attachments in the form of PGP keys and signatures. The purpose or content of the message is not clear from the available information, but it appears to be related to secure communication and authentication using PGP encryption and signatures. 2015-05-24T00:44:20+00:00 + In February 2015, a discussion took place on the Bitcoin-development mailing list regarding the lack of a specification section in a script template format created by William Swanson and Eric Lombrozo. Luke Dashjr asked if the format supported arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested that all pubkeys executed by all CHECKMULTISIG opcodes should be in canonical order, with some examples provided. However, Todd expressed concern about the rule being too restrictive and not enforced as an IsStandard() rule.The email thread discussed modifications needed for a document to be merged. The BIP being discussed is meant to derive the type of scripts encountered while doing addmultisigaddress. There was a discussion about enforcing a convention for canonical ordering of pubkeys executed by all CHECKMULTISIG opcodes, but it should not be brought into validation rules. It was suggested that wallets could opt-in to this convention for ease of recovery and interoperability reasons.Luke Dashjr and Peter Todd discussed the BIP process for deriving scripts and the need for a Specification section. They agreed that there should be a convention for ordering pubkeys executed by all CHECKMULTISIG opcodes, but it should not be enforced as a soft-fork or IsStandard() rule. Wallets can choose to follow this convention for ease of recovery and interoperability.A proposed standard called BIP44/45 aims to allow software to comply and express compatibility, making it easier for wallet software to be compatible with each other. Questions were raised about whether the specification section supports arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested a rule stating that all pubkeys executed by all CHECKMULTISIG opcodes will be in canonical order, followed by some explanatory examples. However, he noted that there is currently no standard way of discussing arbitrary scripts, so the above rule may be too restrictive in some cases.In an email conversation, Luke Dashjr inquired about the specification section of a BIP. Peter Todd suggested rewriting the BIP to state that all public keys executed by all CHECKMULTISIG opcodes would be in canonical order, with some examples provided. However, he also noted that there is currently no standard way of discussing arbitrary scripts, so this rule may not be sufficient in many cases. Peter Todd further stated that he would not want to enforce this as a soft-fork or make it an IsStandard() rule.On February 12, 2015, Thomas Kerin drafted a Bitcoin Improvement Proposal (BIP) with Jean Pierre and Ruben, describing a method to deterministically generate multi-signature transaction scripts. The proposal aims to allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. The BIP focuses on defining how public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and required signatures. Implementations that do not conform with this BIP may have compatibility issues with strictly-compliant wallets.A new Bitcoin Improvement Proposal (BIP) has been drafted to enable deterministic pay-to-script-hash multi-signature addresses through public key sorting. The BIP proposes a standard method to generate multi-signature transaction scripts and defines how the public keys must be encoded and sorted to ensure that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. This will simplify the derivation of scripts and their addresses by all parties and enable services to declare themselves as BIP compliant, working towards interoperability of services.The adoption of a sorting and encoding standard will ensure that compliant wallets produce the same P2SH address for the same given set of keys and required signature count, which is particularly beneficial for multisignature hierarchical-deterministic wallets as less state is required to set up multi-signature accounts. The proposed method requires that public keys be received in compressed form, sorted lexicographically according to their binary representation, and used in a standard multisig redeem script before being hashed according to BIP-0016 to get the P2SH address.Although the BIP is compatible with compressed keys only, it will enable implementations that adopt this standard to be cross-compatible when choosing multisig addresses. However, a group of users that are not entirely compliant could result in one participant deriving an address that the others will not recognize.The context also includes a PGP signature for cryptographic authentication, an HTML attachment that has been scrubbed, and two non-text attachments in the form of PGP keys and signatures. The purpose or content of the message is not clear from the available information, but it appears to be related to secure communication and authentication using PGP encryption and signatures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-ATM.xml b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-ATM.xml index c84abce419..0582e26391 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-ATM.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-ATM.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin ATM - 2023-08-01T11:50:35.227295+00:00 + 2025-10-11T21:40:52.205571+00:00 + python-feedgen Mike Hearn 2015-02-20 17:36:27+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin ATM - 2023-08-01T11:50:35.227295+00:00 + 2025-10-11T21:40:52.205699+00:00 - The email exchange begins with Fikret AKIN reaching out to an intelligent assistant, expressing his desire to enhance the Bitcoin ATM. However, the recipient of the message responds by stating that this particular mailing list is not suitable for such inquiries. The recipient explains that most Bitcoin ATMs are commercial products and do not accept contributors. Instead, they suggest that Fikret should try finding a different mailing list and contacting them directly.In addition to this information, the email provides a link where one can download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server. It is unclear how this server is related to the Bitcoin ATM or its improvement, as no further details are provided.Furthermore, the recipient offers information about the Bitcoin-development mailing list and includes a link to subscribe to it. This suggests that joining this mailing list might be a more appropriate platform for Fikret to seek suggestions and advice regarding Bitcoin ATM enhancement.Overall, Fikret AKIN seeks suggestions to improve the Bitcoin ATM and reaches out to an intelligent assistant for advice. While the exact aspects of improvement are not specified, Fikret appears to be open to various suggestions. 2015-02-20T17:36:27+00:00 + The email exchange begins with Fikret AKIN reaching out to an intelligent assistant, expressing his desire to enhance the Bitcoin ATM. However, the recipient of the message responds by stating that this particular mailing list is not suitable for such inquiries. The recipient explains that most Bitcoin ATMs are commercial products and do not accept contributors. Instead, they suggest that Fikret should try finding a different mailing list and contacting them directly.In addition to this information, the email provides a link where one can download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server. It is unclear how this server is related to the Bitcoin ATM or its improvement, as no further details are provided.Furthermore, the recipient offers information about the Bitcoin-development mailing list and includes a link to subscribe to it. This suggests that joining this mailing list might be a more appropriate platform for Fikret to seek suggestions and advice regarding Bitcoin ATM enhancement.Overall, Fikret AKIN seeks suggestions to improve the Bitcoin ATM and reaches out to an intelligent assistant for advice. While the exact aspects of improvement are not specified, Fikret appears to be open to various suggestions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-10-0-released.xml b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-10-0-released.xml index 4e39ae3f5a..34dddf288b 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-10-0-released.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-10-0-released.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.10.0 released - 2023-08-01T11:48:00.845091+00:00 + 2025-10-11T21:40:28.829679+00:00 + python-feedgen Tim Blokdijk 2015-02-17 21:47:29+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.10.0 released - 2023-08-01T11:48:00.845091+00:00 + 2025-10-11T21:40:28.829844+00:00 - Bitcoin Core has released two new versions of its software, Bitcoin Core 0.10.0 and 0.13.0, with various changes, enhancements, and bug fixes. The release of version 0.10.0 was announced on February 16, 2015 by Wladimir. Users can download the new version from the official Bitcoin website at https://bitcoin.org/bin/0.10.0/. This update brings significant improvements in performance, security, and overall functionality.One notable change in version 0.10.0 is the upgrade of the OpenSSL library to version 1.0.1m, which addresses the Heartbleed bug. Another important feature is the support for multi-wallets, allowing users to manage multiple wallets within the same installation. The peer-to-peer networking protocol has also been enhanced, improving the handling of incoming connections. Additionally, the user interface has been improved. A complete list of changes and updates can be found on the Bitcoin website.The release of Bitcoin Core 0.10.0 represents a major step forward for the Bitcoin network, enhancing both its reliability and usability. It is recommended that users upgrade to this latest version to take advantage of its new features and bug fixes.Version 0.13.0 of Bitcoin Core introduces separate flushing modes, a locking mechanism, P2P protocol and network code changes, validation changes, build system changes, wallet changes, GUI changes, and test changes. These updates are expected to provide improved stability and functionality for users.The release notes for Bitcoin Core v0.10.0 detail the changes in this version, including a new DNSseed policy and improvements to the LevelDB database. Many developers and translators have contributed to these releases, including Andreas Schildbach, Gavin Andresen, Peter Todd, and others.Overall, these updates represent significant progress for Bitcoin Core, offering users a more reliable and efficient experience. 2015-02-17T21:47:29+00:00 + Bitcoin Core has released two new versions of its software, Bitcoin Core 0.10.0 and 0.13.0, with various changes, enhancements, and bug fixes. The release of version 0.10.0 was announced on February 16, 2015 by Wladimir. Users can download the new version from the official Bitcoin website at https://bitcoin.org/bin/0.10.0/. This update brings significant improvements in performance, security, and overall functionality.One notable change in version 0.10.0 is the upgrade of the OpenSSL library to version 1.0.1m, which addresses the Heartbleed bug. Another important feature is the support for multi-wallets, allowing users to manage multiple wallets within the same installation. The peer-to-peer networking protocol has also been enhanced, improving the handling of incoming connections. Additionally, the user interface has been improved. A complete list of changes and updates can be found on the Bitcoin website.The release of Bitcoin Core 0.10.0 represents a major step forward for the Bitcoin network, enhancing both its reliability and usability. It is recommended that users upgrade to this latest version to take advantage of its new features and bug fixes.Version 0.13.0 of Bitcoin Core introduces separate flushing modes, a locking mechanism, P2P protocol and network code changes, validation changes, build system changes, wallet changes, GUI changes, and test changes. These updates are expected to provide improved stability and functionality for users.The release notes for Bitcoin Core v0.10.0 detail the changes in this version, including a new DNSseed policy and improvements to the LevelDB database. Many developers and translators have contributed to these releases, including Andreas Schildbach, Gavin Andresen, Peter Todd, and others.Overall, these updates represent significant progress for Bitcoin Core, offering users a more reliable and efficient experience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-10-0rc4-tagged.xml b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-10-0rc4-tagged.xml index 8c4ccdb4af..c0550f3b67 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-10-0rc4-tagged.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-10-0rc4-tagged.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.10.0rc4 tagged - 2023-08-01T11:24:15.798131+00:00 + 2025-10-11T21:41:04.962628+00:00 + python-feedgen Wladimir 2015-02-06 09:54:34+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.10.0rc4 tagged - 2023-08-01T11:24:15.798131+00:00 + 2025-10-11T21:41:04.962760+00:00 - On February 5th, 2015, Wladimir announced the tagging of v0.10rc4 and pushed his signatures to the gitian.sigs repository. He requested for the Gitian builders to be started, and there was a quick response with 9 gitian builders already in operation. As a result, the executables and tarball for rc4 have been uploaded to the usual place at https://bitcoin.org/bin/0.10.0/test/.The changes relative to rc3 include an increase in block download timeout base from 10 to 20 minutes, increased coverage of DERSIG edge cases, and a BIP66 changeover logic. Other changes in this release candidate are example unit tests from BIP66, a fix for priority calculation in CreateTransaction, avoidance of storing a reference passed to SignatureChecker constructors, separate SignatureChecker for CMutableTransaction, and not allowing amount changes when AmountSpinBox is read-only in Qt.There are also various other fixes and improvements in this version. Coin Control first column label was changed, there is now a sleep-wait on the genesis block during initialization with -reindex, empty byte arrays now pass CheckSignatureEncoding(), and there is a fix for the CoinControl "space" bug. Additionally, QT was fixed with broken unicode characters on osx 10.10, and new options were added such as an -rpckeepalive option to disable RPC use of HTTP persistent connections.This may be the last release candidate before the 0.10 final release. 2015-02-06T09:54:34+00:00 + On February 5th, 2015, Wladimir announced the tagging of v0.10rc4 and pushed his signatures to the gitian.sigs repository. He requested for the Gitian builders to be started, and there was a quick response with 9 gitian builders already in operation. As a result, the executables and tarball for rc4 have been uploaded to the usual place at https://bitcoin.org/bin/0.10.0/test/.The changes relative to rc3 include an increase in block download timeout base from 10 to 20 minutes, increased coverage of DERSIG edge cases, and a BIP66 changeover logic. Other changes in this release candidate are example unit tests from BIP66, a fix for priority calculation in CreateTransaction, avoidance of storing a reference passed to SignatureChecker constructors, separate SignatureChecker for CMutableTransaction, and not allowing amount changes when AmountSpinBox is read-only in Qt.There are also various other fixes and improvements in this version. Coin Control first column label was changed, there is now a sleep-wait on the genesis block during initialization with -reindex, empty byte arrays now pass CheckSignatureEncoding(), and there is a fix for the CoinControl "space" bug. Additionally, QT was fixed with broken unicode characters on osx 10.10, and new options were added such as an -rpckeepalive option to disable RPC use of HTTP persistent connections.This may be the last release candidate before the 0.10 final release. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-9-4-not-on-bitcoin-org-.xml b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-9-4-not-on-bitcoin-org-.xml index b1b03a63aa..2d5078cab6 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-9-4-not-on-bitcoin-org-.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-Core-0-9-4-not-on-bitcoin-org-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.9.4 not on bitcoin.org? - 2023-08-01T11:20:35.329105+00:00 + 2025-10-11T21:40:22.439518+00:00 + python-feedgen Gregory Maxwell 2015-02-01 20:41:35+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.9.4 not on bitcoin.org? - 2023-08-01T11:20:35.329105+00:00 + 2025-10-11T21:40:22.439658+00:00 - On February 1, 2015, a user named xor raised concerns about the release of version 0.9.4 of Bitcoin.org's binaries. They questioned the lack of a release candidate before the official release and whether it posed any danger. In response, it was explained that the changes had undergone testing by multiple individuals as part of git master. Version 0.9.4 was released specifically to address an issue that had not affected previous versions of the binaries. It was clarified that this release was a narrow bug fix backport aimed at ensuring the software continued to work for those who compiled it themselves and received system updates. Therefore, the message conveyed was that there was no cause for concern regarding the release of version 0.9.4.In a communication on Sunday, February 1st, 2015, Wladimir discussed the details of a git tag called v0.9.4. This tag was created as a workaround for a change in OpenSSL that had caused problems. However, the releases were statically built against OpenSSL, meaning there was no need to upgrade if using releases from bitcoin.org. Consequently, there were no changes made on the site. The v0.9.4 tag could be utilized by individuals building from source or distribution packages like the Ubuntu PPA, which unwisely dynamically linked OpenSSL. When asked about the presence of a release candidate before the tag, Wladimir responded that there had been no release for 0.9.4, including neither a release candidate nor anything else. He emphasized that testing and other efforts should be focused on the 0.10 release candidates.The context includes two questions: why there was no release candidate prior to the release, and whether this decision was safe. The absence of a release candidate is viewed as risky by the person asking the question. However, it remains unclear what exactly was released without a candidate version beforehand, and the decision-maker behind releasing without a candidate version is not mentioned. Additionally, an attachment in the form of a signature is included in the context, but there is no information provided regarding its relevance or connection to the rest of the text. 2015-02-01T20:41:35+00:00 + On February 1, 2015, a user named xor raised concerns about the release of version 0.9.4 of Bitcoin.org's binaries. They questioned the lack of a release candidate before the official release and whether it posed any danger. In response, it was explained that the changes had undergone testing by multiple individuals as part of git master. Version 0.9.4 was released specifically to address an issue that had not affected previous versions of the binaries. It was clarified that this release was a narrow bug fix backport aimed at ensuring the software continued to work for those who compiled it themselves and received system updates. Therefore, the message conveyed was that there was no cause for concern regarding the release of version 0.9.4.In a communication on Sunday, February 1st, 2015, Wladimir discussed the details of a git tag called v0.9.4. This tag was created as a workaround for a change in OpenSSL that had caused problems. However, the releases were statically built against OpenSSL, meaning there was no need to upgrade if using releases from bitcoin.org. Consequently, there were no changes made on the site. The v0.9.4 tag could be utilized by individuals building from source or distribution packages like the Ubuntu PPA, which unwisely dynamically linked OpenSSL. When asked about the presence of a release candidate before the tag, Wladimir responded that there had been no release for 0.9.4, including neither a release candidate nor anything else. He emphasized that testing and other efforts should be focused on the 0.10 release candidates.The context includes two questions: why there was no release candidate prior to the release, and whether this decision was safe. The absence of a release candidate is viewed as risky by the person asking the question. However, it remains unclear what exactly was released without a candidate version beforehand, and the decision-maker behind releasing without a candidate version is not mentioned. Additionally, an attachment in the form of a signature is included in the context, but there is no information provided regarding its relevance or connection to the rest of the text. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-at-POS-using-BIP70-NFC-and-offline-payments-implementer-feedback.xml b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-at-POS-using-BIP70-NFC-and-offline-payments-implementer-feedback.xml index d333b93d0b..d111641231 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Bitcoin-at-POS-using-BIP70-NFC-and-offline-payments-implementer-feedback.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Bitcoin-at-POS-using-BIP70-NFC-and-offline-payments-implementer-feedback.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback - 2023-08-01T11:54:07.905855+00:00 + 2025-10-11T21:40:54.328972+00:00 + python-feedgen Eric Voskuil 2015-03-03 00:54:18+00:00 @@ -183,13 +184,13 @@ - python-feedgen + 2 Combined summary - Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback - 2023-08-01T11:54:07.905855+00:00 + 2025-10-11T21:40:54.329214+00:00 - The email conversations revolve around various aspects of improving the bitcoin URI scheme and addressing security concerns in NFC and Bluetooth transactions. There are suggestions to add parameters to the bitcoin URI to simplify wallet development for NFC-only wallets and to improve security for Bluetooth transactions. The use of fallback addresses is debated, with some participants suggesting adding their own parameter instead. The discussion also covers the format of the Session ID, the elimination of the h= parameter, and the use of base58 encoding.There are concerns about the compromise of public keys and the potential for abuse scenarios in point-of-sale systems. The conversation explores the use of public keys via NFC or QR codes and the need for authentication of payers by payees. Reusing public keys is deemed insecure, and suggestions are made to encrypt secrets with public keys or use ephemeral keys. The debate extends to using self-signed certificates versus those signed by a Certificate Authority (CA) and the identification of customers in various scenarios.The reliability of NFC payment transfers is discussed, with suggestions to limit connection speed or run mechanisms in parallel. Compatibility issues with NFC based on the long certificate chain are also discussed, as well as concerns about enabling Bluetooth and potential solutions to turn it on programmatically. Changes to the "ack" memo field and BitPay's memo field are considered. The security risks of NFC and Bluetooth payment transactions are examined, with proposals to send a unique public key over NFC to prevent spoofing and seller impersonation. The use of public certificates versus session keys is debated, with the consensus leaning towards the former for increased security.In another email conversation, the topic of limiting Bitcoin capabilities based on Apple's product capabilities and their stance towards Bitcoin is discussed. It is suggested that Bitcoin should not be limited due to Apple's restrictions and that an Airbitz-like proposal could be implemented as a fallback. The general consensus is that Apple will likely open up NFC to developers in iOS 9 and that Apple doesn't really care about Bitcoin. The history of Bitcoin wallets being banned from the app store and then allowed back in is mentioned, with the opinion that Bitcoin is too small for Apple to be concerned about.In an email exchange on February 22, 2015, Eric Voskuil suggested encoding MAC addresses and resource names using base58 instead of base16. Another person responded, stating that Base64Url is a more efficient encoding method than Base58 and is implemented in more libraries and operating systems. They also noted that Base58 was designed for copy-typing by humans.The email conversations also discuss the security of NFC and Bluetooth communication. Concerns are raised about the privacy of NFC communication and the possibility of eavesdropping. The use of SSL/TLS for private communication over a public channel is debated, as well as the privacy implications of NFC and Bluetooth communication.Overall, the email conversations cover various aspects of implementing NFC and offline payments, proposing changes to the bitcoin payment protocol, and addressing security concerns in NFC and Bluetooth transactions. The discussions aim to improve the bitcoin URI scheme, find solutions to authentication and abuse scenarios, and ensure the security of payment transactions. 2015-03-03T00:54:18+00:00 + The email conversations revolve around various aspects of improving the bitcoin URI scheme and addressing security concerns in NFC and Bluetooth transactions. There are suggestions to add parameters to the bitcoin URI to simplify wallet development for NFC-only wallets and to improve security for Bluetooth transactions. The use of fallback addresses is debated, with some participants suggesting adding their own parameter instead. The discussion also covers the format of the Session ID, the elimination of the h= parameter, and the use of base58 encoding.There are concerns about the compromise of public keys and the potential for abuse scenarios in point-of-sale systems. The conversation explores the use of public keys via NFC or QR codes and the need for authentication of payers by payees. Reusing public keys is deemed insecure, and suggestions are made to encrypt secrets with public keys or use ephemeral keys. The debate extends to using self-signed certificates versus those signed by a Certificate Authority (CA) and the identification of customers in various scenarios.The reliability of NFC payment transfers is discussed, with suggestions to limit connection speed or run mechanisms in parallel. Compatibility issues with NFC based on the long certificate chain are also discussed, as well as concerns about enabling Bluetooth and potential solutions to turn it on programmatically. Changes to the "ack" memo field and BitPay's memo field are considered. The security risks of NFC and Bluetooth payment transactions are examined, with proposals to send a unique public key over NFC to prevent spoofing and seller impersonation. The use of public certificates versus session keys is debated, with the consensus leaning towards the former for increased security.In another email conversation, the topic of limiting Bitcoin capabilities based on Apple's product capabilities and their stance towards Bitcoin is discussed. It is suggested that Bitcoin should not be limited due to Apple's restrictions and that an Airbitz-like proposal could be implemented as a fallback. The general consensus is that Apple will likely open up NFC to developers in iOS 9 and that Apple doesn't really care about Bitcoin. The history of Bitcoin wallets being banned from the app store and then allowed back in is mentioned, with the opinion that Bitcoin is too small for Apple to be concerned about.In an email exchange on February 22, 2015, Eric Voskuil suggested encoding MAC addresses and resource names using base58 instead of base16. Another person responded, stating that Base64Url is a more efficient encoding method than Base58 and is implemented in more libraries and operating systems. They also noted that Base58 was designed for copy-typing by humans.The email conversations also discuss the security of NFC and Bluetooth communication. Concerns are raised about the privacy of NFC communication and the possibility of eavesdropping. The use of SSL/TLS for private communication over a public channel is debated, as well as the privacy implications of NFC and Bluetooth communication.Overall, the email conversations cover various aspects of implementing NFC and offline payments, proposing changes to the bitcoin payment protocol, and addressing security concerns in NFC and Bluetooth transactions. The discussions aim to improve the bitcoin URI scheme, find solutions to authentication and abuse scenarios, and ensure the security of payment transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Export-format-for-xpub.xml b/static/bitcoin-dev/Feb_2015/combined_Export-format-for-xpub.xml index 598df114f9..4af3652734 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Export-format-for-xpub.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Export-format-for-xpub.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Export format for xpub - 2023-08-01T11:21:15.115585+00:00 + 2025-10-11T21:40:56.461189+00:00 + python-feedgen Pavol Rusnak 2015-02-03 10:44:43+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Export format for xpub - 2023-08-01T11:21:15.115585+00:00 + 2025-10-11T21:40:56.461436+00:00 - In an email conversation on March 2, 2015, Andreas Schildbach and Pavol Rusnak discussed the use of keys on multiple blockchains. Initially, Schildbach stated that it is possible, but later clarified that according to BIP32, keys cannot be used on multiple blockchains. However, this issue was addressed in BIP43, which fixed the problem.Rusnak suggested using the block number as an option, but it was argued that this may not be the best choice as keys can be used on multiple blockchains. The conversation also touched on QR codes, with a suggestion for more descriptive parameters. However, it was noted that QR codes are size sensitive and saving data is a primary concern.Another discussion on March 2, 2015, involved Rusnak inquiring about the appropriate gap limit for wallets using h=bip32. The response he received was that the wallet should follow the spec, which currently has limited information on gap limits within the BIP32-hierarchy. This lack of information may lead to wallets transitioning to a more comprehensive standard in the future. Rusnak also asked about the h value for his myTREZOR wallets, and the response he received was that if it follows BIP32, h=bip32 is sufficient.Levin Keller proposed a bitcoin-pub-export protocol in an email, including parameters such as the "path" parameter. However, no specific use case was identified for it. Keller also discussed the "subchains" parameter and whether a wallet should generate receiving addresses for multiple external chains. It was concluded that using just the first chain as the external one would suffice. Keller also shared his preference for Unix timestamps or block numbers for the creation date parameter.The author of the email thread questioned the need for specific HD schemes like BIP32 or BIP44 and proposed a more general export scheme. The required parameter is the gap limit, while optional parameters include which node of the derivation chain is exported, subnodes used for external and internal purposes, and creation date. A proposed export scheme was bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]&path=[path in derivation tree]&subchains=[numbers]&creationdate=[unixtimestamp]. The author also discussed gap limits and h values for wallets.In an email exchange on February 3, 2015, Schildbach and Rusnak discussed parameterizing wallets with regards to BIPs. Schildbach stated that it would not be effective as it is impossible to predict future BIPs. Rusnak inquired about the gap limit for wallets encountering h=bip32 and the appropriate h value for myTREZOR wallets. He specified that myTREZOR wallets are essentially BIP44 wallets that produce h=bip32 xpubs with a gap limit of 20.On February 2, 2015, Rusnak proposed a change to address discovery in BIP32 and BIP44. He suggested scanning xpub/0/i and xpub/1/j chains using a gap limit G, replacing ?h=bip32 with ?t=01&g=20. However, doubts were expressed about parameterizing the process in this way, and it was suggested to use the BIP number directly.In a discussion thread on February 2, 2015, a user suggested using a human-readable date format YYYYMMDD in Bitcoin strings, but another user argued that it is unnecessary as Bitcoin deals with seconds since epoch. The user advocating for human-readable timestamps argued that it saves storage space. Suggestions were made for using an eight-character timestamp or a date format that saves two characters.Schildbach and Rusnak had a discussion on February 2, 2015, about the differences between BIP32-hierarchy and BIP44 in address discovery. Schildbach believed it was more important to describe how addresses should be discovered, while Rusnak preferred a human-readable format for creation dates.In another discussion on February 2, 2015, Schildbach stated that Bitcoin strings are not meant to be read by humans, so human-readable timestamps are unnecessary. However, Rusnak argued that having a transparent, human-readable option is beneficial and saves space in QR codes.A conversation between Rusnak and an unknown individual discussed the h=bip32 hierarchy and its application to BIP44 generated xpubs. They also discussed the creation date of wallets and the preference for a human-readable format like YYYYMMDD.Schildbach and Rusnak discussed the "h=bip32" hierarchy and its relation to xpub/0/i and xpub/1/j chains. They also mentioned that this hierarchy applies to BIP44 generated xpubs. The creation date of wallets was represented by c=123456 in seconds since epoch, but Rusnak expressed a preference for a human-readable format.Mike Hearn suggested including a proposed change in BIP43 2015-02-03T10:44:43+00:00 + In an email conversation on March 2, 2015, Andreas Schildbach and Pavol Rusnak discussed the use of keys on multiple blockchains. Initially, Schildbach stated that it is possible, but later clarified that according to BIP32, keys cannot be used on multiple blockchains. However, this issue was addressed in BIP43, which fixed the problem.Rusnak suggested using the block number as an option, but it was argued that this may not be the best choice as keys can be used on multiple blockchains. The conversation also touched on QR codes, with a suggestion for more descriptive parameters. However, it was noted that QR codes are size sensitive and saving data is a primary concern.Another discussion on March 2, 2015, involved Rusnak inquiring about the appropriate gap limit for wallets using h=bip32. The response he received was that the wallet should follow the spec, which currently has limited information on gap limits within the BIP32-hierarchy. This lack of information may lead to wallets transitioning to a more comprehensive standard in the future. Rusnak also asked about the h value for his myTREZOR wallets, and the response he received was that if it follows BIP32, h=bip32 is sufficient.Levin Keller proposed a bitcoin-pub-export protocol in an email, including parameters such as the "path" parameter. However, no specific use case was identified for it. Keller also discussed the "subchains" parameter and whether a wallet should generate receiving addresses for multiple external chains. It was concluded that using just the first chain as the external one would suffice. Keller also shared his preference for Unix timestamps or block numbers for the creation date parameter.The author of the email thread questioned the need for specific HD schemes like BIP32 or BIP44 and proposed a more general export scheme. The required parameter is the gap limit, while optional parameters include which node of the derivation chain is exported, subnodes used for external and internal purposes, and creation date. A proposed export scheme was bitcoin-pub-export:xpub[gibberish]?gaplimit=[number]&path=[path in derivation tree]&subchains=[numbers]&creationdate=[unixtimestamp]. The author also discussed gap limits and h values for wallets.In an email exchange on February 3, 2015, Schildbach and Rusnak discussed parameterizing wallets with regards to BIPs. Schildbach stated that it would not be effective as it is impossible to predict future BIPs. Rusnak inquired about the gap limit for wallets encountering h=bip32 and the appropriate h value for myTREZOR wallets. He specified that myTREZOR wallets are essentially BIP44 wallets that produce h=bip32 xpubs with a gap limit of 20.On February 2, 2015, Rusnak proposed a change to address discovery in BIP32 and BIP44. He suggested scanning xpub/0/i and xpub/1/j chains using a gap limit G, replacing ?h=bip32 with ?t=01&g=20. However, doubts were expressed about parameterizing the process in this way, and it was suggested to use the BIP number directly.In a discussion thread on February 2, 2015, a user suggested using a human-readable date format YYYYMMDD in Bitcoin strings, but another user argued that it is unnecessary as Bitcoin deals with seconds since epoch. The user advocating for human-readable timestamps argued that it saves storage space. Suggestions were made for using an eight-character timestamp or a date format that saves two characters.Schildbach and Rusnak had a discussion on February 2, 2015, about the differences between BIP32-hierarchy and BIP44 in address discovery. Schildbach believed it was more important to describe how addresses should be discovered, while Rusnak preferred a human-readable format for creation dates.In another discussion on February 2, 2015, Schildbach stated that Bitcoin strings are not meant to be read by humans, so human-readable timestamps are unnecessary. However, Rusnak argued that having a transparent, human-readable option is beneficial and saves space in QR codes.A conversation between Rusnak and an unknown individual discussed the h=bip32 hierarchy and its application to BIP44 generated xpubs. They also discussed the creation date of wallets and the preference for a human-readable format like YYYYMMDD.Schildbach and Rusnak discussed the "h=bip32" hierarchy and its relation to xpub/0/i and xpub/1/j chains. They also mentioned that this hierarchy applies to BIP44 generated xpubs. The creation date of wallets was represented by c=123456 in seconds since epoch, but Rusnak expressed a preference for a human-readable format.Mike Hearn suggested including a proposed change in BIP43 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Is-there-a-way-to-estimate-the-maximum-number-of-transactions-per-minute-Bitcoin-can-handle-as-it-is-today-.xml b/static/bitcoin-dev/Feb_2015/combined_Is-there-a-way-to-estimate-the-maximum-number-of-transactions-per-minute-Bitcoin-can-handle-as-it-is-today-.xml index 30ac39e828..6ba53a4d49 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Is-there-a-way-to-estimate-the-maximum-number-of-transactions-per-minute-Bitcoin-can-handle-as-it-is-today-.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Is-there-a-way-to-estimate-the-maximum-number-of-transactions-per-minute-Bitcoin-can-handle-as-it-is-today-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today? - 2023-08-01T11:16:08.850671+00:00 + 2025-10-11T21:41:09.214516+00:00 + python-feedgen Tom Harding 2015-02-01 06:50:41+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today? - 2023-08-01T11:16:08.850671+00:00 + 2025-10-11T21:41:09.214662+00:00 - Wladimir expresses his view on the scalability of blockchain technology, stating that while the everyone-validates-everything approach is valuable for settling larger transactions in a secure manner, it is not scalable. He argues against the idea of the whole world having to validate every small transaction, such as buying a cup of coffee or a bus ticket, by six billion others. Gavin supports this argument, emphasizing that artificially limiting transactions could cause competition to be lost. He further elaborates on this point in a blog post.The author raises concerns about two projects that could potentially increase transaction volume by up to 100 times: legal bittorrent file sales and P2P Amazon (OpenBazaar). They note that current centralized solutions like Bitpay and Coinbase are necessary to manage the expected volume until technology can handle it in a true peer-to-peer fashion. The author also questions the validity of Alipay's claim of handling up to 2.85 million transactions per minute, suggesting that scalability is a sign of popularity. They emphasize the importance of gaining users rather than focusing solely on broadcast protocols.The discussion then shifts to the scalability of Bitcoin. Concerns are raised about whether miners have enough bandwidth and CPU power to handle the increasing amount of data generated by transactions. However, it is acknowledged that scaling is a positive problem to have, and the focus should be on gaining users rather than worrying about precise broadcast protocols.In another conversation, Nick Simpson and Wladimir discuss the limitations of Bitcoin replacing all methods of payment and scalability concerns. Wladimir argues against broadcasting all transactions over one channel, highlighting the need for settling larger transactions in a secure way. He suggests that future scalable payment systems based on Bitcoin may involve off-blockchain transactions or a hierarchical/subdivided system.The writer challenges the notion that on-chain transactions are the only way to use Bitcoin and scale it. They refer to an article in MIT's Tech Review, which highlights Alipay's ability to handle a large number of transactions. The writer calculates that to handle 100,000 transactions per minute, a block size 1300 times larger than the current one would be needed. They further estimate that if double the number of transactions handled by Alipay were included, it would require around 15 gigabytes per block to be broadcast and hashed by all full nodes every ten minutes, consuming significant storage. The writer questions whether miners have sufficient bandwidth and CPU power to handle this level of scalability.In summary, the Chinese payment platform Alipay demonstrates impressive scalability, handling millions of transactions per minute. This raises concerns about Bitcoin's ability to compete with global financial services. The writer calculates that significant increases in transaction volume would require substantial adjustments to block sizes and could strain miners' bandwidth and CPU power. These scalability concerns prompt discussions on alternative approaches to scaling Bitcoin and the importance of gaining users. 2015-02-01T06:50:41+00:00 + Wladimir expresses his view on the scalability of blockchain technology, stating that while the everyone-validates-everything approach is valuable for settling larger transactions in a secure manner, it is not scalable. He argues against the idea of the whole world having to validate every small transaction, such as buying a cup of coffee or a bus ticket, by six billion others. Gavin supports this argument, emphasizing that artificially limiting transactions could cause competition to be lost. He further elaborates on this point in a blog post.The author raises concerns about two projects that could potentially increase transaction volume by up to 100 times: legal bittorrent file sales and P2P Amazon (OpenBazaar). They note that current centralized solutions like Bitpay and Coinbase are necessary to manage the expected volume until technology can handle it in a true peer-to-peer fashion. The author also questions the validity of Alipay's claim of handling up to 2.85 million transactions per minute, suggesting that scalability is a sign of popularity. They emphasize the importance of gaining users rather than focusing solely on broadcast protocols.The discussion then shifts to the scalability of Bitcoin. Concerns are raised about whether miners have enough bandwidth and CPU power to handle the increasing amount of data generated by transactions. However, it is acknowledged that scaling is a positive problem to have, and the focus should be on gaining users rather than worrying about precise broadcast protocols.In another conversation, Nick Simpson and Wladimir discuss the limitations of Bitcoin replacing all methods of payment and scalability concerns. Wladimir argues against broadcasting all transactions over one channel, highlighting the need for settling larger transactions in a secure way. He suggests that future scalable payment systems based on Bitcoin may involve off-blockchain transactions or a hierarchical/subdivided system.The writer challenges the notion that on-chain transactions are the only way to use Bitcoin and scale it. They refer to an article in MIT's Tech Review, which highlights Alipay's ability to handle a large number of transactions. The writer calculates that to handle 100,000 transactions per minute, a block size 1300 times larger than the current one would be needed. They further estimate that if double the number of transactions handled by Alipay were included, it would require around 15 gigabytes per block to be broadcast and hashed by all full nodes every ten minutes, consuming significant storage. The writer questions whether miners have sufficient bandwidth and CPU power to handle this level of scalability.In summary, the Chinese payment platform Alipay demonstrates impressive scalability, handling millions of transactions per minute. This raises concerns about Bitcoin's ability to compete with global financial services. The writer calculates that significant increases in transaction volume would require substantial adjustments to block sizes and could strain miners' bandwidth and CPU power. These scalability concerns prompt discussions on alternative approaches to scaling Bitcoin and the importance of gaining users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Merged-mining-a-side-chain-with-proof-of-burn-on-parent-chain.xml b/static/bitcoin-dev/Feb_2015/combined_Merged-mining-a-side-chain-with-proof-of-burn-on-parent-chain.xml index 255812bb04..001ca5ddb9 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Merged-mining-a-side-chain-with-proof-of-burn-on-parent-chain.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Merged-mining-a-side-chain-with-proof-of-burn-on-parent-chain.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Merged mining a side chain with proof of burn on parent chain - 2023-08-01T10:56:22.654550+00:00 + 2025-10-11T21:41:15.588046+00:00 + python-feedgen Peter Todd 2015-02-06 01:34:31+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Merged mining a side chain with proof of burn on parent chain - 2023-08-01T10:56:22.655554+00:00 + 2025-10-11T21:41:15.588235+00:00 - On February 4, 2015, Isidor Zeuner asked a question about adding Zerocoin to Bitcoin. Peter Todd clarified the meaning of OP_DEPTH and suggested using OP_CHECKLOCKTIMEVERIFY instead. Tamas Blummer proposed a new mining algorithm for side chains that involves burning Bitcoins to secure them. The difficulty to mine with burn would be dynamic and imply a floating exchange rate between Bitcoin and the side coin. Alex Mizrahi discussed the vulnerability of sidechains and merged-mined chains to collusion attacks, while Peter Todd mentioned the potential for replace-by-fee-scorched-earth thinking. Tamas Blummer and Isidor Zeuner discussed the concept of Proof of Burn and its value in an email conversation. They discussed the effectiveness of Proof of Burn compared to other approaches and the complexities involved in determining the most effective approach for Bitcoin mining. Tamas Blummer also proposed the idea of burn mining side chains to enable permission-less merge mining. He expressed surprise at the lack of feedback on the idea. On 12/10/2014, Tamas Blummer outlined the Proof of Burn algorithm for side chains, which creates a real cost for following the rules and avoids sybil attacks. The algorithm requires that block transactions on the Bitcoin block chain destroy Bitcoins with an OP_RET output containing the hash of the side chain's block header. Those who want to mine the side chain assemble side chain block candidates and submit a Bitcoin transaction burning to the hash of the block candidate. The difficulty to mine with burn would be dynamic and imply a floating exchange rate between Bitcoin and the side coin. Tamas Blummer's proposed mining algorithm for side chains aims to utilize the scarce resource within the digital realm by burning Bitcoins to secure them. By utilizing burn transactions, Bitcoin miner support or consent would not be needed, creating a "merged mining" system. 2015-02-06T01:34:31+00:00 + On February 4, 2015, Isidor Zeuner asked a question about adding Zerocoin to Bitcoin. Peter Todd clarified the meaning of OP_DEPTH and suggested using OP_CHECKLOCKTIMEVERIFY instead. Tamas Blummer proposed a new mining algorithm for side chains that involves burning Bitcoins to secure them. The difficulty to mine with burn would be dynamic and imply a floating exchange rate between Bitcoin and the side coin. Alex Mizrahi discussed the vulnerability of sidechains and merged-mined chains to collusion attacks, while Peter Todd mentioned the potential for replace-by-fee-scorched-earth thinking. Tamas Blummer and Isidor Zeuner discussed the concept of Proof of Burn and its value in an email conversation. They discussed the effectiveness of Proof of Burn compared to other approaches and the complexities involved in determining the most effective approach for Bitcoin mining. Tamas Blummer also proposed the idea of burn mining side chains to enable permission-less merge mining. He expressed surprise at the lack of feedback on the idea. On 12/10/2014, Tamas Blummer outlined the Proof of Burn algorithm for side chains, which creates a real cost for following the rules and avoids sybil attacks. The algorithm requires that block transactions on the Bitcoin block chain destroy Bitcoins with an OP_RET output containing the hash of the side chain's block header. Those who want to mine the side chain assemble side chain block candidates and submit a Bitcoin transaction burning to the hash of the block candidate. The difficulty to mine with burn would be dynamic and imply a floating exchange rate between Bitcoin and the side coin. Tamas Blummer's proposed mining algorithm for side chains aims to utilize the scarce resource within the digital realm by burning Bitcoins to secure them. By utilizing burn transactions, Bitcoin miner support or consent would not be needed, creating a "merged mining" system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_More-precise-type-information-in-API-reference.xml b/static/bitcoin-dev/Feb_2015/combined_More-precise-type-information-in-API-reference.xml index 858de7fac0..9755433945 100644 --- a/static/bitcoin-dev/Feb_2015/combined_More-precise-type-information-in-API-reference.xml +++ b/static/bitcoin-dev/Feb_2015/combined_More-precise-type-information-in-API-reference.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - More precise type information in API reference - 2023-08-01T11:48:26.964953+00:00 + 2025-10-11T21:40:33.087067+00:00 + python-feedgen Dario Teixeira 2015-02-17 18:46:17+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - More precise type information in API reference - 2023-08-01T11:48:26.965137+00:00 + 2025-10-11T21:40:33.087225+00:00 - Dario Teixeira, the primary author of Bitcoin.org JSON-RPC reference, has offered to help Dave by submitting a pull request against the docs adding the necessary type information for one RPC call. Dario suggests using OCaml-bitcoin API as a guide, which could be helpful even if someone doesn't use OCaml. To add the custom types defined in the API, they would need to add a new section to the docs, called List of Types, that lists all the custom types and their descriptions, indicating the JSON type used for serialization.In an email exchange, Dario Teixeira requested the primary author of Bitcoin.org JSON-RPC reference to provide type information in the API calls for better understanding. The author suggested submitting a pull request against the docs adding the type information needed for just one RPC call, which can later be generalized across all RPC docs. The author also provided easy editing options through GitHub and local checkout for the individual RPCs, and encouraged Dario to reach out in case of any questions or concerns.The author of OCaml-bitcoin library, Dario Teixeira, has requested Bitcoin developers to define more precisely the type information associated with each API call in the JSON-RPC reference. He believes that defining the precise set of types used in the RPC API and annotating the RPC calls in the source-code or in the API reference documentation would make writing bindings easier and less error-prone. It would also have the added advantage of better documenting the Bitcoin Core source-code itself. Teixeira acknowledges that it would not be necessary to extend this request to the deep data structures returned by some API calls. He assures that the bindings take a pragmatic stance of only processing the parameters and return results where a strong type discipline is imperative.The author has addressed a few questions raised on IRC, such as what does it matter if JSON only has a tiny set of types, why does it matter if the types are not even distinguished in the C++ source of Bitcoin Core, etc. Dario Teixeira concludes his letter by thanking the Bitcoin developers for their attention and all the work they put into Bitcoin development. He appreciates it and believes that it is not acknowledged often enough. The links to OCaml-bitcoin library, OCaml language description, Bitcoin developer reference and the type definitions created by the author have been provided in the original message.The author of OCaml-bitcoin, a library offering an OCaml interface to the official Bitcoin client API, has requested that Bitcoin developers define more precisely the type information associated with each API call in the JSON-RPC reference. This would make writing bindings easier and less prone to errors, as well as better documenting the Bitcoin Core source-code itself. The author has provided examples of the type definitions used in OCaml-bitcoin and notes that they have not been updated for Bitcoin Core 0.10 yet. The author also answered some questions raised on IRC regarding the importance of defining types, stating that deep down most programming errors are just type errors. The author concludes by thanking the Bitcoin developers for their work and expressing appreciation for their efforts. 2015-02-17T18:46:17+00:00 + Dario Teixeira, the primary author of Bitcoin.org JSON-RPC reference, has offered to help Dave by submitting a pull request against the docs adding the necessary type information for one RPC call. Dario suggests using OCaml-bitcoin API as a guide, which could be helpful even if someone doesn't use OCaml. To add the custom types defined in the API, they would need to add a new section to the docs, called List of Types, that lists all the custom types and their descriptions, indicating the JSON type used for serialization.In an email exchange, Dario Teixeira requested the primary author of Bitcoin.org JSON-RPC reference to provide type information in the API calls for better understanding. The author suggested submitting a pull request against the docs adding the type information needed for just one RPC call, which can later be generalized across all RPC docs. The author also provided easy editing options through GitHub and local checkout for the individual RPCs, and encouraged Dario to reach out in case of any questions or concerns.The author of OCaml-bitcoin library, Dario Teixeira, has requested Bitcoin developers to define more precisely the type information associated with each API call in the JSON-RPC reference. He believes that defining the precise set of types used in the RPC API and annotating the RPC calls in the source-code or in the API reference documentation would make writing bindings easier and less error-prone. It would also have the added advantage of better documenting the Bitcoin Core source-code itself. Teixeira acknowledges that it would not be necessary to extend this request to the deep data structures returned by some API calls. He assures that the bindings take a pragmatic stance of only processing the parameters and return results where a strong type discipline is imperative.The author has addressed a few questions raised on IRC, such as what does it matter if JSON only has a tiny set of types, why does it matter if the types are not even distinguished in the C++ source of Bitcoin Core, etc. Dario Teixeira concludes his letter by thanking the Bitcoin developers for their attention and all the work they put into Bitcoin development. He appreciates it and believes that it is not acknowledged often enough. The links to OCaml-bitcoin library, OCaml language description, Bitcoin developer reference and the type definitions created by the author have been provided in the original message.The author of OCaml-bitcoin, a library offering an OCaml interface to the official Bitcoin client API, has requested that Bitcoin developers define more precisely the type information associated with each API call in the JSON-RPC reference. This would make writing bindings easier and less prone to errors, as well as better documenting the Bitcoin Core source-code itself. The author has provided examples of the type definitions used in OCaml-bitcoin and notes that they have not been updated for Bitcoin Core 0.10 yet. The author also answered some questions raised on IRC regarding the importance of defining types, stating that deep down most programming errors are just type errors. The author concludes by thanking the Bitcoin developers for their work and expressing appreciation for their efforts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_New-BIP-protocol-for-multisignature-payments.xml b/static/bitcoin-dev/Feb_2015/combined_New-BIP-protocol-for-multisignature-payments.xml index 3f6a2cbda7..d436f05c59 100644 --- a/static/bitcoin-dev/Feb_2015/combined_New-BIP-protocol-for-multisignature-payments.xml +++ b/static/bitcoin-dev/Feb_2015/combined_New-BIP-protocol-for-multisignature-payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP: protocol for multisignature payments - 2023-08-01T11:16:55.045035+00:00 + 2025-10-11T21:41:02.835827+00:00 + python-feedgen Martin Habovštiak 2015-02-01 14:14:03+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - New BIP: protocol for multisignature payments - 2023-08-01T11:16:55.045035+00:00 + 2025-10-11T21:41:02.836008+00:00 - In a recent email thread, the implementation of a dispute mediation transaction protocol in bitcoinj based wallets was discussed. The author suggests creating one-off, cross-platform app-specific wallets for this purpose. However, these wallets may initially be considered specialist, requiring users to transfer funds from their general spending wallet to the dispute mediation app. The author offers guidance on implementing this protocol and proposes integrating it into general-purpose wallets in the future.The community is receptive to the idea, with Gavin Andresen emphasizing that standards should be descriptive rather than proscriptive. Mike Hearn agrees and recommends pairing a protocol specification with an implementation. Martin Habovštiak expresses interest in implementing the protocol but mentions a lack of time at present. Wallet and server-side implementations are expected to be based on existing code in languages like C++ or Python. The Crypto hackathon in Parallel Polis is suggested as a potential opportunity for implementation.Another aspect of the email exchange revolves around the importance of descriptive standards. Gavin Andresen concurs and suggests coupling protocol specifications with implementations. The original sender appreciates the feedback and commits to finding time for implementation in the future.In another discussion between Gavin Andresen and Mike Hearn, they echo the sentiment that standards should be descriptive, not prescriptive. Mike Hearn seeks feedback from the community regarding a potential implementation but does not provide specific plans.The original author intends to implement the protocol in the future but wishes to gather feedback from the community first. They believe that pairing a protocol specification with an implementation can help identify design issues and ensure user confidence and adoption.Meanwhile, in a Bitcoin-development mailing list, Martin Habovštiak shares thoughts on solving security problems faced by servers holding significant amounts of bitcoins. He proposes an extension of BIP70 that supports dynamically creating multisig transactions, with the user providing their address. Mike Hearn responds, stating that Martin's write-up resembles the high-level overview on the Bitcoin wiki. He highlights the need for implementing a wallet that supports 2-of-3 dispute mediation and the necessary tools for mediators. The BIP70 extension is seen as a smaller aspect of the project. Martin clarifies that he aimed to design a protocol to enhance usability and requests community feedback.Martin Habovštiak presents a solution for the security challenges encountered by servers holding large amounts of bitcoins, such as exchanges and markets. The proposal involves extending BIP70 to facilitate dynamic multisig transactions, with users providing their addresses. The proposal aligns with the high-level overview on https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation. Martin seeks feedback on whether this approach is suitable or if there are better alternatives. He suggests that implementing his proposed solution or a similar one in wallets would be ideal.Additionally, Martin shares the idea in a GitHub gist (https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5) and solicits community input. Another individual expresses interest in discussing their similar proposal involving generic P2SH scripts and signature requests. The email thread also includes information about the Go Parallel Website, sponsored by Intel and developed with Slashdot Media. This website serves as a hub for parallel software development resources, including blogs, news, videos, case studies, and tutorials.Overall, the email thread delves into proposals for addressing security concerns faced by servers holding substantial bitcoin amounts, accompanied by relevant links to resources related to parallel software development. 2015-02-01T14:14:03+00:00 + In a recent email thread, the implementation of a dispute mediation transaction protocol in bitcoinj based wallets was discussed. The author suggests creating one-off, cross-platform app-specific wallets for this purpose. However, these wallets may initially be considered specialist, requiring users to transfer funds from their general spending wallet to the dispute mediation app. The author offers guidance on implementing this protocol and proposes integrating it into general-purpose wallets in the future.The community is receptive to the idea, with Gavin Andresen emphasizing that standards should be descriptive rather than proscriptive. Mike Hearn agrees and recommends pairing a protocol specification with an implementation. Martin Habovštiak expresses interest in implementing the protocol but mentions a lack of time at present. Wallet and server-side implementations are expected to be based on existing code in languages like C++ or Python. The Crypto hackathon in Parallel Polis is suggested as a potential opportunity for implementation.Another aspect of the email exchange revolves around the importance of descriptive standards. Gavin Andresen concurs and suggests coupling protocol specifications with implementations. The original sender appreciates the feedback and commits to finding time for implementation in the future.In another discussion between Gavin Andresen and Mike Hearn, they echo the sentiment that standards should be descriptive, not prescriptive. Mike Hearn seeks feedback from the community regarding a potential implementation but does not provide specific plans.The original author intends to implement the protocol in the future but wishes to gather feedback from the community first. They believe that pairing a protocol specification with an implementation can help identify design issues and ensure user confidence and adoption.Meanwhile, in a Bitcoin-development mailing list, Martin Habovštiak shares thoughts on solving security problems faced by servers holding significant amounts of bitcoins. He proposes an extension of BIP70 that supports dynamically creating multisig transactions, with the user providing their address. Mike Hearn responds, stating that Martin's write-up resembles the high-level overview on the Bitcoin wiki. He highlights the need for implementing a wallet that supports 2-of-3 dispute mediation and the necessary tools for mediators. The BIP70 extension is seen as a smaller aspect of the project. Martin clarifies that he aimed to design a protocol to enhance usability and requests community feedback.Martin Habovštiak presents a solution for the security challenges encountered by servers holding large amounts of bitcoins, such as exchanges and markets. The proposal involves extending BIP70 to facilitate dynamic multisig transactions, with users providing their addresses. The proposal aligns with the high-level overview on https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation. Martin seeks feedback on whether this approach is suitable or if there are better alternatives. He suggests that implementing his proposed solution or a similar one in wallets would be ideal.Additionally, Martin shares the idea in a GitHub gist (https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5) and solicits community input. Another individual expresses interest in discussing their similar proposal involving generic P2SH scripts and signature requests. The email thread also includes information about the Go Parallel Website, sponsored by Intel and developed with Slashdot Media. This website serves as a hub for parallel software development resources, including blogs, news, videos, case studies, and tutorials.Overall, the email thread delves into proposals for addressing security concerns faced by servers holding substantial bitcoin amounts, accompanied by relevant links to resources related to parallel software development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_On-Rewriting-Bitcoin-was-Re-Libbitcoin-Satoshi-client-is-a-fork-past-0-10-possible-.xml b/static/bitcoin-dev/Feb_2015/combined_On-Rewriting-Bitcoin-was-Re-Libbitcoin-Satoshi-client-is-a-fork-past-0-10-possible-.xml index e41bd683cc..ed878462e6 100644 --- a/static/bitcoin-dev/Feb_2015/combined_On-Rewriting-Bitcoin-was-Re-Libbitcoin-Satoshi-client-is-a-fork-past-0-10-possible-.xml +++ b/static/bitcoin-dev/Feb_2015/combined_On-Rewriting-Bitcoin-was-Re-Libbitcoin-Satoshi-client-is-a-fork-past-0-10-possible-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?) - 2023-08-01T11:36:42.299486+00:00 + 2025-10-11T21:40:43.704163+00:00 + python-feedgen Eric Voskuil 2015-03-25 08:04:48+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?) - 2023-08-01T11:36:42.299486+00:00 + 2025-10-11T21:40:43.704351+00:00 - In an email exchange dated February 14th, 2015, Peter Todd expressed frustration with the lack of transparency in the soft-forking process for Bitcoin. He suggested moving the consensus critical code out of Bitcoin Core and into a standalone libconsensus library to enable a more democratic decision-making process in future soft-forks. The email ended with a humorous comment from Todd's recipient.Mike Hearn clarified during a discussion about language bindings that while the project primarily focused on Java bindings, other languages' bindings would be separate projects. It was noted that Java/JNA bindings could still be used from other languages such as Python, Ruby, Javascript, PHP, Haskell, Lisp, Smalltalk, Scala, Kotlin, Ceylon, and more obscure languages. It was considered more practical to discuss bindings to particular runtimes rather than specific languages in today's world.A user recommended using Swig, a tool for generating bindings in an automated fashion, for creating Java bindings. Once generated with Swig, bindings for other languages can be easily adjusted. Java/JNA bindings can also be used from Python, Ruby, Javascript, PHP, as well as dialects of Haskell, Lisp, Smalltalk, and lesser-known languages like Scala, Kotlin, and Ceylon. It was suggested that it makes more sense to talk about bindings to particular runtimes rather than particular languages.On February 19, 2015, Tamas Blummer responded to Bryan Bishop's comment about language bindings in a project. Blummer clarified that the language binding would be a separate and independent project, solely using the C interface of the libconsensus library. Bishop had expressed his opinion that including all possible language bindings in a project would be unproductive. However, Blummer specified that only Java bindings were intended to be included, with other languages' bindings being separate projects.Bryan Bishop expressed his disagreement with voting for the lighthouse project on February 19, 2015. He clarified that he was referring to voting by pledging on the project rather than on the mailing list. Bishop also argued against squeezing all possible language bindings into a project, stating that it would be unproductive. However, Tamas Blummer suggested that the language binding would be a separate project hosted independently and only use the C interface of the libconsensus library.On February 18, 2015, Tamas Blummer launched the Lighthouse project aimed at adding Java Language Binding to lib consensus. However, Bryan disagreed with the idea of voting and squeezing all possible language bindings into one project. Instead, he suggested exploring a solution similar to what the webkit people did by having gobject bindings. This solution allows all languages to have their own gobject bridge. Blummer's contact information can be found at http://heybryan.org/ and he can be reached at 1 512 203 0507.Tamas Blummer initiated a Lighthouse project on February 19, 2015, aimed at adding Java language binding to the core consensus library. The proposed language binding would allow JVM application developers to innovate without raising concerns about network forks through incompatible alternate protocol implementations. It would be written using lightweight, immutable, and self-contained data classes that use only language standard libraries, making it suitable for any service framework.Tamas Blummer announced the launch of the Lighthouse project to integrate Java language binding to lib consensus. According to Blummer, this will create an alternative to the border router setup in a production environment. The announcement was made on Reddit's Lighthouse Projects page and Blummer hopes that it will lead to constructive debate and voting.Troy Benjegerdes suggests treating the consensus code as a buggy and poorly defined proof-of-concept rather than holy scripture. He recommends looking at the git commit history for the consensus-critical part of the Bitcoin Core codebase as much work has been done in cleaning it up and refactoring for v0.10.0/libconsensus.Tamas Blummer explains that he is using Bitcoin Core as a border router while talking to its P2P interface. His reimplementation of consensus code helps him understand the protocol better, aids debugging, and can be used to create a side chain. He argues that the quality of the consensus code could improve significantly if the community treated it as a buggy and poorly defined proof-of-concept that just happens to actually run.In an email exchange between Tamas Blummer and Peter Todd, Blummer defends his use of Bitcoin Core as a border router and explains how the reimplementation of consensus code has helped him. Todd criticizes Blummer's work and advises him to acquire prior experience before claiming its usefulness. The conversation ends with Blummer condemning Todd's behavior and accusing him of bad-mouthing the work of others.Adam Back and Peter Todd discuss the risks of consensus rewrite experiments in maintaining strict consensus between Bitcoin Core versions. They agree that rewriting the consensus protocol should be approached cautiously to avoid contributing to centralization. 2015-03-25T08:04:48+00:00 + In an email exchange dated February 14th, 2015, Peter Todd expressed frustration with the lack of transparency in the soft-forking process for Bitcoin. He suggested moving the consensus critical code out of Bitcoin Core and into a standalone libconsensus library to enable a more democratic decision-making process in future soft-forks. The email ended with a humorous comment from Todd's recipient.Mike Hearn clarified during a discussion about language bindings that while the project primarily focused on Java bindings, other languages' bindings would be separate projects. It was noted that Java/JNA bindings could still be used from other languages such as Python, Ruby, Javascript, PHP, Haskell, Lisp, Smalltalk, Scala, Kotlin, Ceylon, and more obscure languages. It was considered more practical to discuss bindings to particular runtimes rather than specific languages in today's world.A user recommended using Swig, a tool for generating bindings in an automated fashion, for creating Java bindings. Once generated with Swig, bindings for other languages can be easily adjusted. Java/JNA bindings can also be used from Python, Ruby, Javascript, PHP, as well as dialects of Haskell, Lisp, Smalltalk, and lesser-known languages like Scala, Kotlin, and Ceylon. It was suggested that it makes more sense to talk about bindings to particular runtimes rather than particular languages.On February 19, 2015, Tamas Blummer responded to Bryan Bishop's comment about language bindings in a project. Blummer clarified that the language binding would be a separate and independent project, solely using the C interface of the libconsensus library. Bishop had expressed his opinion that including all possible language bindings in a project would be unproductive. However, Blummer specified that only Java bindings were intended to be included, with other languages' bindings being separate projects.Bryan Bishop expressed his disagreement with voting for the lighthouse project on February 19, 2015. He clarified that he was referring to voting by pledging on the project rather than on the mailing list. Bishop also argued against squeezing all possible language bindings into a project, stating that it would be unproductive. However, Tamas Blummer suggested that the language binding would be a separate project hosted independently and only use the C interface of the libconsensus library.On February 18, 2015, Tamas Blummer launched the Lighthouse project aimed at adding Java Language Binding to lib consensus. However, Bryan disagreed with the idea of voting and squeezing all possible language bindings into one project. Instead, he suggested exploring a solution similar to what the webkit people did by having gobject bindings. This solution allows all languages to have their own gobject bridge. Blummer's contact information can be found at http://heybryan.org/ and he can be reached at 1 512 203 0507.Tamas Blummer initiated a Lighthouse project on February 19, 2015, aimed at adding Java language binding to the core consensus library. The proposed language binding would allow JVM application developers to innovate without raising concerns about network forks through incompatible alternate protocol implementations. It would be written using lightweight, immutable, and self-contained data classes that use only language standard libraries, making it suitable for any service framework.Tamas Blummer announced the launch of the Lighthouse project to integrate Java language binding to lib consensus. According to Blummer, this will create an alternative to the border router setup in a production environment. The announcement was made on Reddit's Lighthouse Projects page and Blummer hopes that it will lead to constructive debate and voting.Troy Benjegerdes suggests treating the consensus code as a buggy and poorly defined proof-of-concept rather than holy scripture. He recommends looking at the git commit history for the consensus-critical part of the Bitcoin Core codebase as much work has been done in cleaning it up and refactoring for v0.10.0/libconsensus.Tamas Blummer explains that he is using Bitcoin Core as a border router while talking to its P2P interface. His reimplementation of consensus code helps him understand the protocol better, aids debugging, and can be used to create a side chain. He argues that the quality of the consensus code could improve significantly if the community treated it as a buggy and poorly defined proof-of-concept that just happens to actually run.In an email exchange between Tamas Blummer and Peter Todd, Blummer defends his use of Bitcoin Core as a border router and explains how the reimplementation of consensus code has helped him. Todd criticizes Blummer's work and advises him to acquire prior experience before claiming its usefulness. The conversation ends with Blummer condemning Todd's behavior and accusing him of bad-mouthing the work of others.Adam Back and Peter Todd discuss the risks of consensus rewrite experiments in maintaining strict consensus between Bitcoin Core versions. They agree that rewriting the consensus protocol should be approached cautiously to avoid contributing to centralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Proposal-Requiring-a-miner-s-signature-in-the-block-header.xml b/static/bitcoin-dev/Feb_2015/combined_Proposal-Requiring-a-miner-s-signature-in-the-block-header.xml index 1a08ea3b50..ba08b332d4 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Proposal-Requiring-a-miner-s-signature-in-the-block-header.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Proposal-Requiring-a-miner-s-signature-in-the-block-header.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: Requiring a miner's signature in the block header - 2023-08-01T11:25:30.269342+00:00 + 2025-10-11T21:40:58.589601+00:00 + python-feedgen Ittay 2015-02-12 13:56:02+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Proposal: Requiring a miner's signature in the block header - 2023-08-01T11:25:30.269342+00:00 + 2025-10-11T21:40:58.589746+00:00 - A proposal has been made to address the issue of centralization in mining by requiring miners to sign the block header prior to hashing. This would prevent cooperating pools of miners from controlling block rewards, as they would be controlled by disparate parties rather than the pool operator. The coinbase for the block would only pay out to the public key counterpart of the private key used to sign the block header. However, some argue that this solution may increase technical trust requirements and potentially break P2Pool.To achieve decentralised pooled mining, it is suggested to chip away at getblocktemplate support. This approach aims to work towards mining decentralisation and resolve the contradiction. The blog post titled "Mining Decentralisation - The Low Hanging Fruit" provides further insights into the measures that can be taken to achieve this goal.The issue of centralisation in mining poses potential risks to users, as pool operators could hold them hostage and change rules. To address this concern, the proposed solution suggests that each miner signs the block header before hashing, with the signature included in the data that is hashed. Additionally, the coinbase for the block would only pay out to the public key counterpart of the private key used for signing. This would prevent illegitimate earning of bitcoins by pooled hashpower and protect against double-spending attacks without sharing the private key with the whole pool.However, there are concerns about increasing technical trust requirements and the potential impact on P2Pool. Some argue that threshold signatures, also known as group signatures, could be utilized by distrusting pool miners to still work together. It is important to consider these factors when implementing any changes to mining processes.In summary, the proposal aims to address the centralization of mining by requiring miners to sign the block header before hashing and ensuring that block rewards are controlled by disparate parties rather than the pool operator. However, there are considerations regarding technical trust requirements and potential implications for P2Pool. Further exploration of decentralised pooled mining and the measures outlined in the blog post "Mining Decentralisation - The Low Hanging Fruit" could offer alternative paths to achieve mining decentralization. 2015-02-12T13:56:02+00:00 + A proposal has been made to address the issue of centralization in mining by requiring miners to sign the block header prior to hashing. This would prevent cooperating pools of miners from controlling block rewards, as they would be controlled by disparate parties rather than the pool operator. The coinbase for the block would only pay out to the public key counterpart of the private key used to sign the block header. However, some argue that this solution may increase technical trust requirements and potentially break P2Pool.To achieve decentralised pooled mining, it is suggested to chip away at getblocktemplate support. This approach aims to work towards mining decentralisation and resolve the contradiction. The blog post titled "Mining Decentralisation - The Low Hanging Fruit" provides further insights into the measures that can be taken to achieve this goal.The issue of centralisation in mining poses potential risks to users, as pool operators could hold them hostage and change rules. To address this concern, the proposed solution suggests that each miner signs the block header before hashing, with the signature included in the data that is hashed. Additionally, the coinbase for the block would only pay out to the public key counterpart of the private key used for signing. This would prevent illegitimate earning of bitcoins by pooled hashpower and protect against double-spending attacks without sharing the private key with the whole pool.However, there are concerns about increasing technical trust requirements and the potential impact on P2Pool. Some argue that threshold signatures, also known as group signatures, could be utilized by distrusting pool miners to still work together. It is important to consider these factors when implementing any changes to mining processes.In summary, the proposal aims to address the centralization of mining by requiring miners to sign the block header before hashing and ensuring that block rewards are controlled by disparate parties rather than the pool operator. However, there are considerations regarding technical trust requirements and potential implications for P2Pool. Further exploration of decentralised pooled mining and the measures outlined in the blog post "Mining Decentralisation - The Low Hanging Fruit" could offer alternative paths to achieve mining decentralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Proposal-for-P2P-Wireless-Bluetooth-LE-transfer-of-Payment-URI.xml b/static/bitcoin-dev/Feb_2015/combined_Proposal-for-P2P-Wireless-Bluetooth-LE-transfer-of-Payment-URI.xml index 7b04764491..6ba6ff5625 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Proposal-for-P2P-Wireless-Bluetooth-LE-transfer-of-Payment-URI.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Proposal-for-P2P-Wireless-Bluetooth-LE-transfer-of-Payment-URI.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI - 2023-08-01T11:24:01.650139+00:00 + 2025-10-11T21:40:24.567451+00:00 + python-feedgen Eric Voskuil 2015-02-10 17:56:39+00:00 @@ -175,13 +176,13 @@ - python-feedgen + 2 Combined summary - Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI - 2023-08-01T11:24:01.651192+00:00 + 2025-10-11T21:40:24.567635+00:00 - The conversation between Martin Habovštiak and Eric Voskuil revolves around the security and privacy concerns related to Bitcoin transactions. They discuss the use of a commit protocol for encryption and authentication, using ECDH or DH to establish authenticated and encrypted communication. The commit protocol involves sending a hash of the initiator's temporary public ECDH part, receiving the public ECDH part of the second party, and then sending the initiator's public ECDH part in open. All three messages are hashed together, and the first two bytes are used to select two words from a shared dictionary, which are displayed on the screen of both parties. These words are communicated and verified to match before proceeding with the transaction.The conversation also touches upon the need for manual verification and the possibility of differing verification strings resulting in a new address being generated, as well as the limitations and vulnerabilities of using addresses for verification. Eric expresses his concerns about smartphone platforms for secure communication and data exchange and suggests that a shared secret or trusted public key is necessary to prevent privacy loss. They agree that proximity-based communication is the best way to ensure privacy and integrity in a broadcast model, while narrowing the cast can use proximity to establish trust.The discussion also includes suggestions for preventing address reuse and maintaining secure peer-to-peer communication. Stealth addressing and interactive communication are proposed as solutions, along with the importance of proximity in ensuring the payee still has access to the private key associated with the payment address. BIP-70 is mentioned as necessary to prevent fraudulent NFC devices or replacement of a static QR code in cases where there is no person present to represent the receiver, such as in vending machine purchases.The conversation acknowledges the challenges of establishing trust and secure communication channels. Manual verification, encryption with forward secrecy, and bootstrapping trust through visual verification of the address prefix are suggested as potential solutions. However, the limitations and vulnerabilities of each method are also discussed, including the risk of MITM attacks and the difficulty of establishing secure channels over public networks.The conversation also references the RedPhone app (known as Signal on iPhone), which offers end-to-end encrypted communication and remembers public keys to simplify verification. However, Eric expresses skepticism about trusting smartphones as secure platforms.Overall, the conversation explores various approaches to enhance the security and privacy of Bitcoin transactions, while acknowledging the challenges and limitations of each method. The importance of secure communication channels, proximity-based trust establishment, and manual verification is emphasized throughout the discussion.In a discussion about the use of Bluetooth Low Energy (BLE) technology for Bitcoin transactions, concerns were raised about the potential risks of broadcasting personal information such as photos and MAC addresses in public areas. It was argued that faces are already publicly visible and Bluetooth MAC addresses are random and not useful for identification. The issue of "payment spam" was also addressed, with suggestions for requiring signed requests and blacklisting spammers as potential solutions.The conversation also touched on the feasibility of implementing BLE technology for Bitcoin Improvement Proposal (BIP), with the consensus being that it would require another wallet to implement it before becoming a BIP. There were discussions about the limitations of BLE propagation and the need to establish trust in broadcasting information. The conversation also explored ideas for faster user interfaces, including the use of wifi hotspots to trigger BLE.The debate then shifted to discussing alternative methods for P2P payments, such as using BIP70 payment requests instead of "bitcoin:" URIs. NFC technology was also discussed, but it was noted that it has clunky usability issues and is not universally supported on all devices. The conversation concluded with suggestions for a Square-style UI that combines a photo of the user with a Bluetooth MAC address to facilitate point-of-sale transactions.Overall, the conversation emphasized the importance of establishing trust in broadcasting information and explored various ideas for improving user interfaces and addressing potential privacy and security concerns in Bitcoin transactions.Airbitz has developed a protocol for wireless transfer of a URI request using open broadcast channels such as Bluetooth, Bluetooth Low Energy, or WiFi Direct. This protocol eliminates the need for QR codes, which can be cumbersome for exchanging URI requests between merchants and customers. With this protocol, the merchant simply enters the payment and waits, without requiring any alignment of devices. To address the potential security issue of copycat broadcasters trying to lure customers into sending funds to them instead of the merchant, the protocol includes a partial address in the broadcast.The proposed specification also involves Peripheral advertising over a service UUID and a BLE extended advertisement with a Scan Response containing the partial address of a bitcoin URI and a name. When the Central scans the advertisement, it may display the Scan Response in a human-readable listing using the two pieces of information. If the Central chooses this advertisement to receive the full request, it subscribes to the service and writes its own name to the Peripheral. The Peripheral acknowledges the receipt by sending a server response. The Central receives the response and immediately requests the entire bitcoin URI by issuing a read request on that characteristic. The Peripheral receives 2015-02-10T17:56:39+00:00 + The conversation between Martin Habovštiak and Eric Voskuil revolves around the security and privacy concerns related to Bitcoin transactions. They discuss the use of a commit protocol for encryption and authentication, using ECDH or DH to establish authenticated and encrypted communication. The commit protocol involves sending a hash of the initiator's temporary public ECDH part, receiving the public ECDH part of the second party, and then sending the initiator's public ECDH part in open. All three messages are hashed together, and the first two bytes are used to select two words from a shared dictionary, which are displayed on the screen of both parties. These words are communicated and verified to match before proceeding with the transaction.The conversation also touches upon the need for manual verification and the possibility of differing verification strings resulting in a new address being generated, as well as the limitations and vulnerabilities of using addresses for verification. Eric expresses his concerns about smartphone platforms for secure communication and data exchange and suggests that a shared secret or trusted public key is necessary to prevent privacy loss. They agree that proximity-based communication is the best way to ensure privacy and integrity in a broadcast model, while narrowing the cast can use proximity to establish trust.The discussion also includes suggestions for preventing address reuse and maintaining secure peer-to-peer communication. Stealth addressing and interactive communication are proposed as solutions, along with the importance of proximity in ensuring the payee still has access to the private key associated with the payment address. BIP-70 is mentioned as necessary to prevent fraudulent NFC devices or replacement of a static QR code in cases where there is no person present to represent the receiver, such as in vending machine purchases.The conversation acknowledges the challenges of establishing trust and secure communication channels. Manual verification, encryption with forward secrecy, and bootstrapping trust through visual verification of the address prefix are suggested as potential solutions. However, the limitations and vulnerabilities of each method are also discussed, including the risk of MITM attacks and the difficulty of establishing secure channels over public networks.The conversation also references the RedPhone app (known as Signal on iPhone), which offers end-to-end encrypted communication and remembers public keys to simplify verification. However, Eric expresses skepticism about trusting smartphones as secure platforms.Overall, the conversation explores various approaches to enhance the security and privacy of Bitcoin transactions, while acknowledging the challenges and limitations of each method. The importance of secure communication channels, proximity-based trust establishment, and manual verification is emphasized throughout the discussion.In a discussion about the use of Bluetooth Low Energy (BLE) technology for Bitcoin transactions, concerns were raised about the potential risks of broadcasting personal information such as photos and MAC addresses in public areas. It was argued that faces are already publicly visible and Bluetooth MAC addresses are random and not useful for identification. The issue of "payment spam" was also addressed, with suggestions for requiring signed requests and blacklisting spammers as potential solutions.The conversation also touched on the feasibility of implementing BLE technology for Bitcoin Improvement Proposal (BIP), with the consensus being that it would require another wallet to implement it before becoming a BIP. There were discussions about the limitations of BLE propagation and the need to establish trust in broadcasting information. The conversation also explored ideas for faster user interfaces, including the use of wifi hotspots to trigger BLE.The debate then shifted to discussing alternative methods for P2P payments, such as using BIP70 payment requests instead of "bitcoin:" URIs. NFC technology was also discussed, but it was noted that it has clunky usability issues and is not universally supported on all devices. The conversation concluded with suggestions for a Square-style UI that combines a photo of the user with a Bluetooth MAC address to facilitate point-of-sale transactions.Overall, the conversation emphasized the importance of establishing trust in broadcasting information and explored various ideas for improving user interfaces and addressing potential privacy and security concerns in Bitcoin transactions.Airbitz has developed a protocol for wireless transfer of a URI request using open broadcast channels such as Bluetooth, Bluetooth Low Energy, or WiFi Direct. This protocol eliminates the need for QR codes, which can be cumbersome for exchanging URI requests between merchants and customers. With this protocol, the merchant simply enters the payment and waits, without requiring any alignment of devices. To address the potential security issue of copycat broadcasters trying to lure customers into sending funds to them instead of the merchant, the protocol includes a partial address in the broadcast.The proposed specification also involves Peripheral advertising over a service UUID and a BLE extended advertisement with a Scan Response containing the partial address of a bitcoin URI and a name. When the Central scans the advertisement, it may display the Scan Response in a human-readable listing using the two pieces of information. If the Central chooses this advertisement to receive the full request, it subscribes to the service and writes its own name to the Peripheral. The Peripheral acknowledges the receipt by sending a server response. The Central receives the response and immediately requests the entire bitcoin URI by issuing a read request on that characteristic. The Peripheral receives - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Proposal-to-address-Bitcoin-malware.xml b/static/bitcoin-dev/Feb_2015/combined_Proposal-to-address-Bitcoin-malware.xml index 6bec10be5f..194e8fc2cd 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Proposal-to-address-Bitcoin-malware.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Proposal-to-address-Bitcoin-malware.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal to address Bitcoin malware - 2023-08-01T11:18:34.937889+00:00 + 2025-10-11T21:40:47.955227+00:00 + python-feedgen Eric Voskuil 2015-02-03 07:38:07+00:00 @@ -135,13 +136,13 @@ - python-feedgen + 2 Combined summary - Proposal to address Bitcoin malware - 2023-08-01T11:18:34.938888+00:00 + 2025-10-11T21:40:47.955438+00:00 - The context provided discusses the development of Bitcoin Authenticator, a desktop and mobile app aimed at addressing security concerns related to cryptocurrency transactions. The app offers out-of-band transaction verification/signing or dual transaction signing without requiring a third-party. The concept of using multisig wallets to protect against malware attacks is also discussed, where a compromised third-party would not be able to complete transactions as they only possess one private key.The conversation between Mike Hearn and Martin Habovštiak reveals that Bitcoin Authenticator was already implementing the idea of sending partially signed transactions from a computer to a smartphone. Habovštiak suggests creating a 3oo5 address with two cold storage keys on a desktop/laptop and a smartphone, along with one key using a third-party service. BitGo, CryptoCorp, and GreenAddress are mentioned as companies offering this model.The email conversation between Habovštiak and others further discusses the use of partially signed transactions from a computer to a smartphone to improve security. It suggests utilizing multisig wallets and adding more keys, including hardware wallets like Trezor and Ledger, to enhance security. The email emphasizes the importance of leaving out a third party for privacy reasons.The context highlights the increasing concern about malware targeting Bitcoin users and the need for effective security measures. Out-of-band transaction verification/signing is suggested as a method used in online banking to protect against attacks. The use of OATH-based one-time passwords (OTP) and chipTAN/cardTAN as additional security measures is also discussed.BIP70 is introduced as a safe method against Man-in-the-Browser (MitB) attacks, but questions about its sufficiency for transaction verification, especially in the case of a compromised computer, are raised. The compatibility of Trezor with BIP70 is uncertain. The security of the wallet is emphasized, and devices like TREZOR and secure wallet pairings are mentioned as examples.In a Bitcoin-development mailing list discussion, concerns about the security of Bitcoin transactions are raised. The possibility of generating an 8-digit number from a Bitcoin address to verify transactions is discussed, but there are concerns about the feasibility and potential collisions. The discussion highlights ongoing concerns about Bitcoin transaction security and the need for further development of solutions.The context also mentions the use of vanitygen for generating vanity bitcoin addresses and discusses viruses that manipulate bitcoin addresses. It suggests generating an 8-digit code for a legitimate bitcoin address as a basic mitigation measure against malware, but also acknowledges the possibility of brute-forcing the legitimate bitcoin address to generate a rogue address with the same code.Overall, the context presents various concepts and discussions related to improving the security of Bitcoin transactions, including the use of out-of-band verification, multisig wallets, hardware wallets, and additional authentication methods. The aim is to protect against malware attacks and ensure the privacy and integrity of transactions. 2015-02-03T07:38:07+00:00 + The context provided discusses the development of Bitcoin Authenticator, a desktop and mobile app aimed at addressing security concerns related to cryptocurrency transactions. The app offers out-of-band transaction verification/signing or dual transaction signing without requiring a third-party. The concept of using multisig wallets to protect against malware attacks is also discussed, where a compromised third-party would not be able to complete transactions as they only possess one private key.The conversation between Mike Hearn and Martin Habovštiak reveals that Bitcoin Authenticator was already implementing the idea of sending partially signed transactions from a computer to a smartphone. Habovštiak suggests creating a 3oo5 address with two cold storage keys on a desktop/laptop and a smartphone, along with one key using a third-party service. BitGo, CryptoCorp, and GreenAddress are mentioned as companies offering this model.The email conversation between Habovštiak and others further discusses the use of partially signed transactions from a computer to a smartphone to improve security. It suggests utilizing multisig wallets and adding more keys, including hardware wallets like Trezor and Ledger, to enhance security. The email emphasizes the importance of leaving out a third party for privacy reasons.The context highlights the increasing concern about malware targeting Bitcoin users and the need for effective security measures. Out-of-band transaction verification/signing is suggested as a method used in online banking to protect against attacks. The use of OATH-based one-time passwords (OTP) and chipTAN/cardTAN as additional security measures is also discussed.BIP70 is introduced as a safe method against Man-in-the-Browser (MitB) attacks, but questions about its sufficiency for transaction verification, especially in the case of a compromised computer, are raised. The compatibility of Trezor with BIP70 is uncertain. The security of the wallet is emphasized, and devices like TREZOR and secure wallet pairings are mentioned as examples.In a Bitcoin-development mailing list discussion, concerns about the security of Bitcoin transactions are raised. The possibility of generating an 8-digit number from a Bitcoin address to verify transactions is discussed, but there are concerns about the feasibility and potential collisions. The discussion highlights ongoing concerns about Bitcoin transaction security and the need for further development of solutions.The context also mentions the use of vanitygen for generating vanity bitcoin addresses and discusses viruses that manipulate bitcoin addresses. It suggests generating an 8-digit code for a legitimate bitcoin address as a basic mitigation measure against malware, but also acknowledges the possibility of brute-forcing the legitimate bitcoin address to generate a rogue address with the same code.Overall, the context presents various concepts and discussions related to improving the security of Bitcoin transactions, including the use of out-of-band verification, multisig wallets, hardware wallets, and additional authentication methods. The aim is to protect against malware attacks and ensure the privacy and integrity of transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Providing-Payment-Request-within-URI.xml b/static/bitcoin-dev/Feb_2015/combined_Providing-Payment-Request-within-URI.xml index 6e2527d027..47224dc2fb 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Providing-Payment-Request-within-URI.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Providing-Payment-Request-within-URI.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Providing Payment Request within URI - 2023-08-01T11:57:02.088054+00:00 + 2025-10-11T21:40:41.580038+00:00 + python-feedgen Andreas Schildbach 2015-02-26 12:11:48+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Providing Payment Request within URI - 2023-08-01T11:57:02.089091+00:00 + 2025-10-11T21:40:41.580212+00:00 - In a discussion on the benefits of using Base43 for storing binary data in QR codes, Oleg Andreev explains that Base43 is similar to other BaseX standards but uses an alphabet of 43 characters. This makes it efficient for use with QR codes as the alphabet matches the 'Alphanumeric' input mode of QR codes as closely as possible while still being allowed in URIs. In response to a question about how Base58 and Base64 compare, Andreev explains that these methods force QR codes into binary encoding, resulting in wasted space.Specifically, Base64 can take up to 6 bits per character, whereas binary has 8 bits per character, so using Base64 results in 25% wasted space. On the other hand, Base43 takes log2(43) = 5.43 bits per character, which is only a waste of 1.3% as each character uses up 5.5 bits in QR codes in 'Alphanumeric' encoding. The source for the QR code standard is provided as a link to Wikipedia.Base43 is a variation of BaseX standard, which uses an alternative alphabet comprising 43 characters. This variation is designed to facilitate the efficient storage of binary data into QR codes. The selection of this specific alphabet was made to closely match the "Alphanumeric" input mode of QR codes while still being allowed in URIs. It is unclear whether Base58 or Base64 take up more space than Base43 on QR codes. However, it is worth noting that the primary objective of using Base43 is to optimize the storage of binary data within QR codes. There may be potential gains in terms of efficiency and storage capacity by utilizing this variation of the BaseX standard.In a conversation between Oleg Andreev and Andreas Schildbach on February 24th, 2015, Oleg inquired about a standard way to put Payment Request data into bitcoin: URI or directly into QR code. The goal was to allow the device to generate a multi-output payment request on its own without relying on the server and x509 certificates. Andreas suggested that if all one wants to do is send to a custom script (without using P2SH), they should look at the InputParser.java and Qr.java files in the Bitcoin Wallet GitHub repository. He mentioned using "BITCOIN:-" plus the payment request in Base43 encoded form because it is optimized for QR codes. He noted that X509 signing or lots of outputs will make the QR code hard to scan.In a discussion on the Bitcoin mailing list, Oleg Andreev asked if there is a standard way to put payment request data into a bitcoin: URI or directly into QR code. He was looking for a way to allow a device to generate a multi-output payment request without relying on the server and x509 certificates. The goal was to have something like "bitcoin:?r=data://". Though there isn't a standard for this, he wondered if it would be a good idea to extend BIP72. In response, someone suggested using the Base43 encoding of the payment request in a QR code with "BITCOIN:-" preceding it. This approach is optimized for QR codes and should work well for simple use cases. However, X509 signing or too many outputs could make scanning the QR code difficult. Links to relevant code on GitHub were provided.In a Bitcoin mailing list, Oleg Andreev shared his thoughts on the possibility of a standard way to incorporate Payment Request data into bitcoin: URI or directly into QR codes. He suggested generating a multi-output payment request on its own without relying on a server and x509 certificates. To make it secure, no additional authentication would be needed if scanned via QR code from a POS. Andreas' wallet supports this but he advised not doing it as payment requests can get larger in the future, even without signing, and exploding the capacity of a QR code is very easy. Instead, he recommended taking a look at the Bluetooth/NFC discussion happening in a different thread. Oleg wondered if it would be a good idea to extend BIP72 if there's no standard for that.The writer is wondering if there is a standard way to put Payment Request data into bitcoin, either through a URI or directly into a QR code. The goal is to allow a device to generate a multi-output payment request without relying on a server and x509 certificates. The writer suggests using a bitcoin:?r=data:// format for this purpose. They ask if there is currently no standard for this, whether it would be a good idea to extend BIP72 in this way. 2015-02-26T12:11:48+00:00 + In a discussion on the benefits of using Base43 for storing binary data in QR codes, Oleg Andreev explains that Base43 is similar to other BaseX standards but uses an alphabet of 43 characters. This makes it efficient for use with QR codes as the alphabet matches the 'Alphanumeric' input mode of QR codes as closely as possible while still being allowed in URIs. In response to a question about how Base58 and Base64 compare, Andreev explains that these methods force QR codes into binary encoding, resulting in wasted space.Specifically, Base64 can take up to 6 bits per character, whereas binary has 8 bits per character, so using Base64 results in 25% wasted space. On the other hand, Base43 takes log2(43) = 5.43 bits per character, which is only a waste of 1.3% as each character uses up 5.5 bits in QR codes in 'Alphanumeric' encoding. The source for the QR code standard is provided as a link to Wikipedia.Base43 is a variation of BaseX standard, which uses an alternative alphabet comprising 43 characters. This variation is designed to facilitate the efficient storage of binary data into QR codes. The selection of this specific alphabet was made to closely match the "Alphanumeric" input mode of QR codes while still being allowed in URIs. It is unclear whether Base58 or Base64 take up more space than Base43 on QR codes. However, it is worth noting that the primary objective of using Base43 is to optimize the storage of binary data within QR codes. There may be potential gains in terms of efficiency and storage capacity by utilizing this variation of the BaseX standard.In a conversation between Oleg Andreev and Andreas Schildbach on February 24th, 2015, Oleg inquired about a standard way to put Payment Request data into bitcoin: URI or directly into QR code. The goal was to allow the device to generate a multi-output payment request on its own without relying on the server and x509 certificates. Andreas suggested that if all one wants to do is send to a custom script (without using P2SH), they should look at the InputParser.java and Qr.java files in the Bitcoin Wallet GitHub repository. He mentioned using "BITCOIN:-" plus the payment request in Base43 encoded form because it is optimized for QR codes. He noted that X509 signing or lots of outputs will make the QR code hard to scan.In a discussion on the Bitcoin mailing list, Oleg Andreev asked if there is a standard way to put payment request data into a bitcoin: URI or directly into QR code. He was looking for a way to allow a device to generate a multi-output payment request without relying on the server and x509 certificates. The goal was to have something like "bitcoin:?r=data://". Though there isn't a standard for this, he wondered if it would be a good idea to extend BIP72. In response, someone suggested using the Base43 encoding of the payment request in a QR code with "BITCOIN:-" preceding it. This approach is optimized for QR codes and should work well for simple use cases. However, X509 signing or too many outputs could make scanning the QR code difficult. Links to relevant code on GitHub were provided.In a Bitcoin mailing list, Oleg Andreev shared his thoughts on the possibility of a standard way to incorporate Payment Request data into bitcoin: URI or directly into QR codes. He suggested generating a multi-output payment request on its own without relying on a server and x509 certificates. To make it secure, no additional authentication would be needed if scanned via QR code from a POS. Andreas' wallet supports this but he advised not doing it as payment requests can get larger in the future, even without signing, and exploding the capacity of a QR code is very easy. Instead, he recommended taking a look at the Bluetooth/NFC discussion happening in a different thread. Oleg wondered if it would be a good idea to extend BIP72 if there's no standard for that.The writer is wondering if there is a standard way to put Payment Request data into bitcoin, either through a URI or directly into a QR code. The goal is to allow a device to generate a multi-output payment request without relying on a server and x509 certificates. The writer suggests using a bitcoin:?r=data:// format for this purpose. They ask if there is currently no standard for this, whether it would be a good idea to extend BIP72 in this way. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Request-for-a-new-BIP-number-and-discussion-Improved-HD-wallet-generation-.xml b/static/bitcoin-dev/Feb_2015/combined_Request-for-a-new-BIP-number-and-discussion-Improved-HD-wallet-generation-.xml index d6f5b063e2..6025f834e4 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Request-for-a-new-BIP-number-and-discussion-Improved-HD-wallet-generation-.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Request-for-a-new-BIP-number-and-discussion-Improved-HD-wallet-generation-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Request for a new BIP number (and discussion): Improved HD wallet generation. - 2023-08-01T11:51:10.425786+00:00 + 2025-10-11T21:41:00.713320+00:00 + python-feedgen 木ノ下じょな 2015-02-23 05:00:44+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Request for a new BIP number (and discussion): Improved HD wallet generation. - 2023-08-01T11:51:10.425786+00:00 + 2025-10-11T21:41:00.713511+00:00 - Jona, a skilled developer, has been working on projects related to data encryption and security. Recently, he updated an algorithm to include b in the derivation of a and vice versa. However, jhoenicke pointed out in the comment section that a derivation was not including b at all, making colluding derivation weak to 1 leaked descendant private node. Jona plans to write out how to compromise the parent private node with two child private nodes and the parent public node once he gets home. He hopes that writing it out will help give an understanding of any other hidden tricks.In addition to this project, Jona has put together a proposal for a new generation methodology of HD wallets, which is a modification of BIP32. He welcomes any criticism and help with making the BIP more secure. The proposal suggests managing normal private keys hierarchically instead of generating millions of keys ahead of time and storing them on USBs or similar devices. Jona believes that services like "Reality Keys" could be a perfect use case for this modification. He requests any cryptographers to review the math and see if it's sound. The link to the proposal can be found at https://gist.github.com/dabura667/875bb2c159b219c18885.Bob expresses concerns about the security of the proposed modification in an email exchange with Jona. He states that even with the modification, compromise of the longer key still compromises the entire wallet. Jona responds by explaining that as long as the keys are generated within their specifications, it is not possible to derive the associated extended private key to the ancestor extended public key.The context also includes a PGP public key block shared by Jona. This key can be used for secure communication and encryption purposes. It is sent as an attachment via email to enable secure communication between two parties without the risk of interception or eavesdropping.In an email communication on February 21, 2015, Jona thanked Pavol Rusnak for his feedback on the proposal and mentioned that they have written the Abstract and Motivation sections. The tone of the email suggests that the feedback was well-received.However, Pavol Rusnak responded that the proposal is missing Abstract and Motivation sections, which are essential to understand what the proposal aims to achieve and why. He advises against delving into technical details until these two questions are answered. Jona thanks Pavol for his feedback and asks if his English needs improvement or if there are any other comments or criticisms.The context also mentions an email exchange between Jona and Pavol Rusnak regarding the proposed modification to HD wallets. Pavol points out that the proposal is missing important sections, namely Abstract and Motivation. These sections are necessary to explain what is being achieved and why it is being done. Pavol advises against delving into technical details until these questions are answered.The context provides a glimpse into the world of secure communication and encryption, emphasizing the importance of digital security in today's interconnected world. It includes a PGP public key block, which can be used for secure communication and encryption. Additionally, there is an email containing an advertisement for BIRT iHub F-Type, a free enterprise-grade server for business reports and dashboards. Another email is from the Bitcoin-development mailing list, allowing developers to discuss issues related to the development of the Bitcoin protocol. The email includes a link to sign up for the mailing list.On February 21, 2015, Jona proposed a new generation methodology for HD wallets to the Bitcoin-development mailing list. The method is based on a modified version of BIP32, requiring accidental disclosure of two private keys to compute the master private key. Jona is open to any criticism and help with making the BIP more secure. He includes a link to a GitHub gist with pseudo code and explanations. Jona requests someone to tell him the overall step-by-step flow if the proposal is deemed worthy enough to be drafted into a BIP.Overall, the context provides information about Jona's work on data encryption and security projects, including an algorithm update and a proposal for a new generation methodology of HD wallets. It also includes email exchanges and a PGP public key block for secure communication. 2015-02-23T05:00:44+00:00 + Jona, a skilled developer, has been working on projects related to data encryption and security. Recently, he updated an algorithm to include b in the derivation of a and vice versa. However, jhoenicke pointed out in the comment section that a derivation was not including b at all, making colluding derivation weak to 1 leaked descendant private node. Jona plans to write out how to compromise the parent private node with two child private nodes and the parent public node once he gets home. He hopes that writing it out will help give an understanding of any other hidden tricks.In addition to this project, Jona has put together a proposal for a new generation methodology of HD wallets, which is a modification of BIP32. He welcomes any criticism and help with making the BIP more secure. The proposal suggests managing normal private keys hierarchically instead of generating millions of keys ahead of time and storing them on USBs or similar devices. Jona believes that services like "Reality Keys" could be a perfect use case for this modification. He requests any cryptographers to review the math and see if it's sound. The link to the proposal can be found at https://gist.github.com/dabura667/875bb2c159b219c18885.Bob expresses concerns about the security of the proposed modification in an email exchange with Jona. He states that even with the modification, compromise of the longer key still compromises the entire wallet. Jona responds by explaining that as long as the keys are generated within their specifications, it is not possible to derive the associated extended private key to the ancestor extended public key.The context also includes a PGP public key block shared by Jona. This key can be used for secure communication and encryption purposes. It is sent as an attachment via email to enable secure communication between two parties without the risk of interception or eavesdropping.In an email communication on February 21, 2015, Jona thanked Pavol Rusnak for his feedback on the proposal and mentioned that they have written the Abstract and Motivation sections. The tone of the email suggests that the feedback was well-received.However, Pavol Rusnak responded that the proposal is missing Abstract and Motivation sections, which are essential to understand what the proposal aims to achieve and why. He advises against delving into technical details until these two questions are answered. Jona thanks Pavol for his feedback and asks if his English needs improvement or if there are any other comments or criticisms.The context also mentions an email exchange between Jona and Pavol Rusnak regarding the proposed modification to HD wallets. Pavol points out that the proposal is missing important sections, namely Abstract and Motivation. These sections are necessary to explain what is being achieved and why it is being done. Pavol advises against delving into technical details until these questions are answered.The context provides a glimpse into the world of secure communication and encryption, emphasizing the importance of digital security in today's interconnected world. It includes a PGP public key block, which can be used for secure communication and encryption. Additionally, there is an email containing an advertisement for BIRT iHub F-Type, a free enterprise-grade server for business reports and dashboards. Another email is from the Bitcoin-development mailing list, allowing developers to discuss issues related to the development of the Bitcoin protocol. The email includes a link to sign up for the mailing list.On February 21, 2015, Jona proposed a new generation methodology for HD wallets to the Bitcoin-development mailing list. The method is based on a modified version of BIP32, requiring accidental disclosure of two private keys to compute the master private key. Jona is open to any criticism and help with making the BIP more secure. He includes a link to a GitHub gist with pseudo code and explanations. Jona requests someone to tell him the overall step-by-step flow if the proposal is deemed worthy enough to be drafted into a BIP.Overall, the context provides information about Jona's work on data encryption and security projects, including an algorithm update and a proposal for a new generation methodology of HD wallets. It also includes email exchanges and a PGP public key block for secure communication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Request-for-comments-on-hybrid-PoW-PoS-enhancement-for-Bitcoin.xml b/static/bitcoin-dev/Feb_2015/combined_Request-for-comments-on-hybrid-PoW-PoS-enhancement-for-Bitcoin.xml index e68e189de7..b30aa91216 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Request-for-comments-on-hybrid-PoW-PoS-enhancement-for-Bitcoin.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Request-for-comments-on-hybrid-PoW-PoS-enhancement-for-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Request for comments on hybrid PoW/PoS enhancement for Bitcoin - 2023-08-01T11:56:22.916994+00:00 + 2025-10-11T21:40:39.456198+00:00 + python-feedgen Chris Page 2015-02-25 13:43:32+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Request for comments on hybrid PoW/PoS enhancement for Bitcoin - 2023-08-01T11:56:22.916994+00:00 + 2025-10-11T21:40:39.456325+00:00 - Chris Page, a member of the Bitcoin-development mailing list, has proposed a new idea called Block Endorsement. The aim of this proposal is to enhance the security of the blockchain, increase the number of full nodes, and provide more opportunities for bitcoin distribution. The proposal suggests the implementation of a new message within the current structures.Under the Block Endorsement scheme, full nodes would verify a specific block, known as B0. A subset of these nodes would then broadcast an endorsement message endorsing the block as valid and preferred. Miners would include these endorsements in the coinbase transaction of the subsequent block, referred to as B1, sharing the block reward with endorsers of B0. To incentivize miners to include endorsement payouts, a modification to the best chain selection algorithm is required. This modification would grant a significant bonus to a block's work for each valid endorsement payout included in its coinbase transaction. Essentially, a block's work with 10 endorsements would be considered doubled for the purpose of block selection. This makes a sustained 51% attack more costly to execute.However, there are still certain aspects of the proposal that need further exploration. These include potential attack vectors and the role endorsers could play in identifying possible double-spends. Chris Page welcomes feedback on whether to proceed with implementing the proposal or recommending a new Bitcoin Improvement Proposal (BIP). Under the Block Endorsement scheme, the rewards for endorsers would amount to as much as 20% of the block reward, which would be shared evenly among all endorsers included in the coinbase. When a new block is broadcast, miners would begin assembling another block, while full nodes validate the new block. Endorsements would propagate quickly to all miners. The implementation of Block Endorsement would not only provide an incentive for more full nodes but also encourage wider adoption of Bitcoin.Despite its potential benefits, the success of the proposal hinges on the thorough exploration of potential attack vectors and the role endorsers could play in detecting double-spends. Chris Page is eager to receive feedback to refine the proposal and address any remaining gaps or concerns. 2015-02-25T13:43:32+00:00 + Chris Page, a member of the Bitcoin-development mailing list, has proposed a new idea called Block Endorsement. The aim of this proposal is to enhance the security of the blockchain, increase the number of full nodes, and provide more opportunities for bitcoin distribution. The proposal suggests the implementation of a new message within the current structures.Under the Block Endorsement scheme, full nodes would verify a specific block, known as B0. A subset of these nodes would then broadcast an endorsement message endorsing the block as valid and preferred. Miners would include these endorsements in the coinbase transaction of the subsequent block, referred to as B1, sharing the block reward with endorsers of B0. To incentivize miners to include endorsement payouts, a modification to the best chain selection algorithm is required. This modification would grant a significant bonus to a block's work for each valid endorsement payout included in its coinbase transaction. Essentially, a block's work with 10 endorsements would be considered doubled for the purpose of block selection. This makes a sustained 51% attack more costly to execute.However, there are still certain aspects of the proposal that need further exploration. These include potential attack vectors and the role endorsers could play in identifying possible double-spends. Chris Page welcomes feedback on whether to proceed with implementing the proposal or recommending a new Bitcoin Improvement Proposal (BIP). Under the Block Endorsement scheme, the rewards for endorsers would amount to as much as 20% of the block reward, which would be shared evenly among all endorsers included in the coinbase. When a new block is broadcast, miners would begin assembling another block, while full nodes validate the new block. Endorsements would propagate quickly to all miners. The implementation of Block Endorsement would not only provide an incentive for more full nodes but also encourage wider adoption of Bitcoin.Despite its potential benefits, the success of the proposal hinges on the thorough exploration of potential attack vectors and the role endorsers could play in detecting double-spends. Chris Page is eager to receive feedback to refine the proposal and address any remaining gaps or concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Standardizing-automatic-pre-negotiation-of-transaction-terms-with-BIP70-Emulating-Amazon-one-click-purchase-at-all-merchants-.xml b/static/bitcoin-dev/Feb_2015/combined_Standardizing-automatic-pre-negotiation-of-transaction-terms-with-BIP70-Emulating-Amazon-one-click-purchase-at-all-merchants-.xml index 3255571c62..7eb1d6187b 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Standardizing-automatic-pre-negotiation-of-transaction-terms-with-BIP70-Emulating-Amazon-one-click-purchase-at-all-merchants-.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Standardizing-automatic-pre-negotiation-of-transaction-terms-with-BIP70-Emulating-Amazon-one-click-purchase-at-all-merchants-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants) - 2023-08-01T11:25:10.856544+00:00 + 2025-10-11T21:40:37.333692+00:00 + python-feedgen Natanael 2015-02-10 11:58:42+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants) - 2023-08-01T11:25:10.856544+00:00 + 2025-10-11T21:40:37.333872+00:00 - The discussion revolves around finding a simple solution for Bitcoin transactions. One suggestion is the use of a browser extension, but it has limitations such as only working until browsers add native support and being limited to one device or requiring manual syncing. The proposed solution involves extra BIP70 extensions for communication between the wallet and merchant, allowing graceful degradation if the browser or wallet don't support it. Another suggestion involves using BLE to link hardware wallets with new devices, enabling secure auto-fill in situations where an untrusted machine is used.In the Bitcoin-development mailing list discussion, Mike Hearn questions the usefulness of auto-filling shipping addresses through wallets when browsers already have this functionality for credit card information. Natanael proposes a protocol that adds a tag in the HTML form to prompt the Bitcoin wallet about payment details. Additionally, he suggests using BLE to link hardware wallets with new devices for secure auto-fill. However, Hearn questions the need to hold location information in a hardware wallet if it's private enough.In an online discussion, Natanael raises concerns about mixing unrelated topics while discussing displaying shipping information on e-commerce websites. MⒶrtin suggests displaying relevant shipping information before adding items to the cart, similar to eBay. Natanael argues that displaying IP addresses isn't always reliable due to VPN or Tor usage. MⒶrtin suggests a browser extension could perform the task without involving bitcoin wallets. Natanael questions whether users would be willing to read all the displayed options, and MⒶrtin suggests a popup slider to choose the level of information to share. Natanael also suggests the system doesn't have to share raw data and provides links to anonymous credentials options. Finally, Natanael states that everything discussed is possible without involving Bitcoin and advocates following the Unix philosophy.In an email exchange, Mike Hearn discusses the use of BIP70 extensions for auto-filling shipping addresses. He suggests using HTML5 data standards instead of wallets to allow merchants to advertise shipping locations in a machine-readable format. The protocol used doesn't matter as long as it simplifies implementation. Hearn proposes adding a tag to the HTML form to prompt the Bitcoin wallet about payment details. One potential solution involves asking a hardware wallet over BLE for data, enabling secure auto-fill while minimizing trust in the browsing device.The discussion focuses on the feasibility of displaying shipping information on websites before any action is taken. IP addresses are deemed unreliable due to VPN or Tor usage. The suggestion is to prompt users with a popup slider to choose the level of information to share. Raw data doesn't need to be shared, and anonymous credentials can be used. Prompting could be delayed until the first item is added to the cart.The author discusses potential extensions to BIP70 for auto-filling shipping addresses. They question whether the wallet is the best place for this feature and suggest reusing existing data from web browsers that already have this functionality for credit card forms. A Star-Trek-like negotiation agent is proposed to standardize metadata and find the best deals. However, the author believes this project may not be suitable for BIP70 due to its current deployment and usage. Instead, they recommend exploring HTML5 data standards for merchants to advertise shipping locations.The discussion revolves around BIP70, a payment protocol for Bitcoin transactions, specifically regarding auto-filling shipping addresses. BIP70 facilitates communication between a user's wallet client and a merchant's server to agree on payment details and other terms. It ensures strong seller identity and supports non-repudiation in face-to-face or non-web scenarios. It allows the wallet/browser extension to inform users immediately if a webshop is acceptable, saving time. BIP70 is not just about payments but also about communicating the terms of the sale.A user questions the need for Bitcoin when websites like eBay display shipping information before transactions. They argue that Bitcoin is unnecessary, and a website or browser extension can handle the task without it. However, BIP70 is more than just payment; it facilitates communication of the terms of sale. For example, it allows users to know if a webshop ships to their country before filling their cart. BIP70 simplifies the shopping experience and addresses various requirements.In a discussion about Amazon's payment process, BIP70 is introduced. It involves communicating the terms of the sale between the buyer and seller before payment begins, including shipping information. By using BIP70, a wallet or browser extension can inform the buyer immediately if they can shop at a particular webshop, saving time. BIP70 improves the transaction process by providing essential information to buyers before they start filling their cart.BIP70 enables communication between a user's wallet client and a merchant's server to agree on payment details and other functionalities. However, it is currently initiated only during payment, which can lead to users not knowing certain information until after filling their cart. The implementation of BIP70 HTML tags on webshops could trigger a user's wallet 2015-02-10T11:58:42+00:00 + The discussion revolves around finding a simple solution for Bitcoin transactions. One suggestion is the use of a browser extension, but it has limitations such as only working until browsers add native support and being limited to one device or requiring manual syncing. The proposed solution involves extra BIP70 extensions for communication between the wallet and merchant, allowing graceful degradation if the browser or wallet don't support it. Another suggestion involves using BLE to link hardware wallets with new devices, enabling secure auto-fill in situations where an untrusted machine is used.In the Bitcoin-development mailing list discussion, Mike Hearn questions the usefulness of auto-filling shipping addresses through wallets when browsers already have this functionality for credit card information. Natanael proposes a protocol that adds a tag in the HTML form to prompt the Bitcoin wallet about payment details. Additionally, he suggests using BLE to link hardware wallets with new devices for secure auto-fill. However, Hearn questions the need to hold location information in a hardware wallet if it's private enough.In an online discussion, Natanael raises concerns about mixing unrelated topics while discussing displaying shipping information on e-commerce websites. MⒶrtin suggests displaying relevant shipping information before adding items to the cart, similar to eBay. Natanael argues that displaying IP addresses isn't always reliable due to VPN or Tor usage. MⒶrtin suggests a browser extension could perform the task without involving bitcoin wallets. Natanael questions whether users would be willing to read all the displayed options, and MⒶrtin suggests a popup slider to choose the level of information to share. Natanael also suggests the system doesn't have to share raw data and provides links to anonymous credentials options. Finally, Natanael states that everything discussed is possible without involving Bitcoin and advocates following the Unix philosophy.In an email exchange, Mike Hearn discusses the use of BIP70 extensions for auto-filling shipping addresses. He suggests using HTML5 data standards instead of wallets to allow merchants to advertise shipping locations in a machine-readable format. The protocol used doesn't matter as long as it simplifies implementation. Hearn proposes adding a tag to the HTML form to prompt the Bitcoin wallet about payment details. One potential solution involves asking a hardware wallet over BLE for data, enabling secure auto-fill while minimizing trust in the browsing device.The discussion focuses on the feasibility of displaying shipping information on websites before any action is taken. IP addresses are deemed unreliable due to VPN or Tor usage. The suggestion is to prompt users with a popup slider to choose the level of information to share. Raw data doesn't need to be shared, and anonymous credentials can be used. Prompting could be delayed until the first item is added to the cart.The author discusses potential extensions to BIP70 for auto-filling shipping addresses. They question whether the wallet is the best place for this feature and suggest reusing existing data from web browsers that already have this functionality for credit card forms. A Star-Trek-like negotiation agent is proposed to standardize metadata and find the best deals. However, the author believes this project may not be suitable for BIP70 due to its current deployment and usage. Instead, they recommend exploring HTML5 data standards for merchants to advertise shipping locations.The discussion revolves around BIP70, a payment protocol for Bitcoin transactions, specifically regarding auto-filling shipping addresses. BIP70 facilitates communication between a user's wallet client and a merchant's server to agree on payment details and other terms. It ensures strong seller identity and supports non-repudiation in face-to-face or non-web scenarios. It allows the wallet/browser extension to inform users immediately if a webshop is acceptable, saving time. BIP70 is not just about payments but also about communicating the terms of the sale.A user questions the need for Bitcoin when websites like eBay display shipping information before transactions. They argue that Bitcoin is unnecessary, and a website or browser extension can handle the task without it. However, BIP70 is more than just payment; it facilitates communication of the terms of sale. For example, it allows users to know if a webshop ships to their country before filling their cart. BIP70 simplifies the shopping experience and addresses various requirements.In a discussion about Amazon's payment process, BIP70 is introduced. It involves communicating the terms of the sale between the buyer and seller before payment begins, including shipping information. By using BIP70, a wallet or browser extension can inform the buyer immediately if they can shop at a particular webshop, saving time. BIP70 improves the transaction process by providing essential information to buyers before they start filling their cart.BIP70 enables communication between a user's wallet client and a merchant's server to agree on payment details and other functionalities. However, it is currently initiated only during payment, which can lead to users not knowing certain information until after filling their cart. The implementation of BIP70 HTML tags on webshops could trigger a user's wallet - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Subject-Re-Proposal-to-address-Bitcoin-malware.xml b/static/bitcoin-dev/Feb_2015/combined_Subject-Re-Proposal-to-address-Bitcoin-malware.xml index 0dbcc22dd8..ae8be1328c 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Subject-Re-Proposal-to-address-Bitcoin-malware.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Subject-Re-Proposal-to-address-Bitcoin-malware.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Subject: Re: Proposal to address Bitcoin malware - 2023-08-01T11:21:33.108198+00:00 + 2025-10-11T21:41:21.955903+00:00 + python-feedgen Eric Voskuil 2015-02-04 01:03:53+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Subject: Re: Proposal to address Bitcoin malware - 2023-08-01T11:21:33.108198+00:00 + 2025-10-11T21:41:21.956047+00:00 - The conversation on the Bitcoin-development mailing list revolves around the security of Bitcoin transactions and the use of multisig authorization. The first email thread discusses the use of multisig wallets to protect against malware. It highlights the scenario where a compromised platform leads to a loss of integrity of the private key. To overcome this, the user can send the signed transaction to a third party for the second signature, but the problem arises when the compromised platform can impersonate the user and send the transaction to the third party. The solution proposed is to send the transaction to an independent platform for verification by the user before adding the second signature.The second email thread focuses on fixing a problem with R/S length upper bounds in Bitcoin's STRICTDER validation. One solution suggested is to make signatures with too-long R or S values non-standard. Another suggestion is to add this to BIP66's DERSIG. There is no opposition to the latter option, and it is preferred by Gregory Maxwell.In the third email thread, the discussion centers around multiple factor authentication and its limitations. The independence of control is emphasized as a key factor in analyzing the security of a multiple factor system. It is cautioned that increasing user complexity without increasing integrity or privacy can mislead users. The importance of verifying Bitcoin transactions before completion is also highlighted.The conversation also explores the use of TREZOR-like devices with BIP70 support and third-party cosigning services for secure multisig authorization. The recommendation is to use small hardware devices like TREZOR and third-party cosigning services to enhance security. It is suggested that a standard for passing partially signed transactions around may be beneficial in the future, allowing users to have more options and flexibility in securing their Bitcoin holdings.Overall, the discussion delves into various aspects of Bitcoin security, including the use of multisig wallets, fixing issues with signature validation, implementing multiple factor authentication, and exploring hardware devices and cosigning services for enhanced security. The conversation aims to improve the security of Bitcoin transactions and provide users with more secure options for managing their holdings. 2015-02-04T01:03:53+00:00 + The conversation on the Bitcoin-development mailing list revolves around the security of Bitcoin transactions and the use of multisig authorization. The first email thread discusses the use of multisig wallets to protect against malware. It highlights the scenario where a compromised platform leads to a loss of integrity of the private key. To overcome this, the user can send the signed transaction to a third party for the second signature, but the problem arises when the compromised platform can impersonate the user and send the transaction to the third party. The solution proposed is to send the transaction to an independent platform for verification by the user before adding the second signature.The second email thread focuses on fixing a problem with R/S length upper bounds in Bitcoin's STRICTDER validation. One solution suggested is to make signatures with too-long R or S values non-standard. Another suggestion is to add this to BIP66's DERSIG. There is no opposition to the latter option, and it is preferred by Gregory Maxwell.In the third email thread, the discussion centers around multiple factor authentication and its limitations. The independence of control is emphasized as a key factor in analyzing the security of a multiple factor system. It is cautioned that increasing user complexity without increasing integrity or privacy can mislead users. The importance of verifying Bitcoin transactions before completion is also highlighted.The conversation also explores the use of TREZOR-like devices with BIP70 support and third-party cosigning services for secure multisig authorization. The recommendation is to use small hardware devices like TREZOR and third-party cosigning services to enhance security. It is suggested that a standard for passing partially signed transactions around may be beneficial in the future, allowing users to have more options and flexibility in securing their Bitcoin holdings.Overall, the discussion delves into various aspects of Bitcoin security, including the use of multisig wallets, fixing issues with signature validation, implementing multiple factor authentication, and exploring hardware devices and cosigning services for enhanced security. The conversation aims to improve the security of Bitcoin transactions and provide users with more secure options for managing their holdings. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Two-Proposed-BIPs-Bluetooth-Communication-and-bitcoin-URI-Scheme-Improvements.xml b/static/bitcoin-dev/Feb_2015/combined_Two-Proposed-BIPs-Bluetooth-Communication-and-bitcoin-URI-Scheme-Improvements.xml index 44da094379..6ab4955260 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Two-Proposed-BIPs-Bluetooth-Communication-and-bitcoin-URI-Scheme-Improvements.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Two-Proposed-BIPs-Bluetooth-Communication-and-bitcoin-URI-Scheme-Improvements.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements - 2023-08-01T10:27:34.037467+00:00 + 2025-10-11T21:40:45.828507+00:00 + python-feedgen Peter D. Gray 2015-02-06 19:06:07+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements - 2023-08-01T10:27:34.037467+00:00 + 2025-10-11T21:40:45.828653+00:00 - The Bitcoin community is seeking a person-to-person payment protocol for Bluetooth Low Energy (BLE) that is resistant to spoofing and vandalism. The author proposes using EC signing of nonces to develop a rock-solid P2P protocol. They suggest modifying the "commit protocol" based on RedPhone, using a 6-digit decimal confirmation code for easier display on vending machines and small screens.The verification of bitcoin payments on the breadwallet app for Apple devices is faster than on Android, possibly due to a more optimized signature verification algorithm. The slower verification process on Android may be because it is being verified in Java instead of C++, but this can potentially be fixed. X.509 cert chains are mentioned as bloated, but even with their size, the transfer time should not take several seconds over Bluetooth.Bluetooth Low Energy (BLE) is designed for always-on broadcast "beacons" with low power requirements. It is commonly used to trigger other mechanisms like classical Bluetooth or HTTPS connections. BLE can be used in Bitcoin payments to download payment requests and upload payment messages, while actual data transfer occurs over Bluetooth, Wifi, or the internet. The challenge lies in how the wallet can download the right payment request, which is a tough UI problem to solve.In an email exchange, Andreas Schildbach and Eric Voskuil discuss the advantages of Bluetooth Low Energy (BLE) over Bluetooth. BLE uses less power and has lower bandwidth but greater range and lower connection latency, making it suitable for payment purposes. However, the transfer of larger files may reduce the benefits of BLE. The size of signed payment requests can be significant, so speed is important.Andy Schroder raises concerns about discussing certain issues on the mailing list and suggests finding a more appropriate place for discussion.The proposed Bluetooth payment protocol implementation could be more secure with a lower range. BLE offers lower power usage and lower bandwidth, making it suitable for payment purposes. However, the connection may be slow when including the whole certificate chain. The author suggests improvements to the Bluetooth communication scheme and the general payment protocol.Andy Schroder introduces two proposed BIPs for implementing the payment protocol using Bluetooth connections. These proposals are modeled after Andreas Schildbach's Android Bitcoin Wallet's Bluetooth capability, which uses BLE technology. The author highlights the need for further discussion on various aspects of Bluetooth implementation. They also mention known issues that can be improved, such as inconsistency in connection header messages, unauthenticated Bluetooth connection, and lack of acknowledgement failure message in the payment protocol.The discussion explores whether BIPs should document how things should work or how they actually work. The need for informational BIPs and an efficient process for them is emphasized.SSL encryption on Bluetooth connections is suggested but considered complicated. Alternative PKIs and the issue of HTTP base failure signal are discussed. Merge avoidance and the trustworthiness of HTTPS are mentioned. The possibility of providing a full-fledged WiFi connection for customers is explored, requiring a sophisticated proxy server to allow access only to Bitcoin nodes. The dedicated blockchain radio is also discussed.In an email exchange between Mike Hearn and Andy Schroder, the issues with the existing Bluetooth payment protocol are discussed. They highlight the use of an unauthenticated Bluetooth connection and the lack of acknowledgement failure message. The conversation also touches on data storage in QR codes and the limit of offline transactions. The need for a lightweight library for ECDH key agreement and AES+HMAC encryption is mentioned. The discussion further explores the need for dedicated blockchain access and the challenges of providing a full-fledged WiFi connection.The author of this email discusses the implementation of the payment protocol using Bluetooth connections and introduces two proposed BIPs. The use of Bluetooth is important because it allows for payments to be made in areas with limited or no internet access. The proposed BIPs are based on Andreas Schildbach's Android Bitcoin Wallet's Bluetooth capability and include an additional parameter in the bitcoin: URI scheme for including a hash of the payment request.The author seeks feedback from wallet developers and others on these proposals, as widespread Bluetooth support among wallets is crucial. They provide links to copies of the proposed BIPs and a video demonstration showcasing the features using Schildbach's wallet and a fuel pump.There are known issues with the Bluetooth communication scheme and general payment protocol that the author and Andreas would like feedback on. These issues include inconsistencies in connection header messages, unauthenticated Bluetooth connections that are vulnerable to man-in-the-middle attacks, lack of acknowledgement failure message in the payment protocol, and the increasing size of QR codes when using a backwards compatible URL.Possible alternatives to the proposed solution are suggested, such as reversing the order of parameter numbers in the payment_url or creating a new payment_url_multi field for future use. The author concludes by inviting comments and suggestions from readers. 2015-02-06T19:06:07+00:00 + The Bitcoin community is seeking a person-to-person payment protocol for Bluetooth Low Energy (BLE) that is resistant to spoofing and vandalism. The author proposes using EC signing of nonces to develop a rock-solid P2P protocol. They suggest modifying the "commit protocol" based on RedPhone, using a 6-digit decimal confirmation code for easier display on vending machines and small screens.The verification of bitcoin payments on the breadwallet app for Apple devices is faster than on Android, possibly due to a more optimized signature verification algorithm. The slower verification process on Android may be because it is being verified in Java instead of C++, but this can potentially be fixed. X.509 cert chains are mentioned as bloated, but even with their size, the transfer time should not take several seconds over Bluetooth.Bluetooth Low Energy (BLE) is designed for always-on broadcast "beacons" with low power requirements. It is commonly used to trigger other mechanisms like classical Bluetooth or HTTPS connections. BLE can be used in Bitcoin payments to download payment requests and upload payment messages, while actual data transfer occurs over Bluetooth, Wifi, or the internet. The challenge lies in how the wallet can download the right payment request, which is a tough UI problem to solve.In an email exchange, Andreas Schildbach and Eric Voskuil discuss the advantages of Bluetooth Low Energy (BLE) over Bluetooth. BLE uses less power and has lower bandwidth but greater range and lower connection latency, making it suitable for payment purposes. However, the transfer of larger files may reduce the benefits of BLE. The size of signed payment requests can be significant, so speed is important.Andy Schroder raises concerns about discussing certain issues on the mailing list and suggests finding a more appropriate place for discussion.The proposed Bluetooth payment protocol implementation could be more secure with a lower range. BLE offers lower power usage and lower bandwidth, making it suitable for payment purposes. However, the connection may be slow when including the whole certificate chain. The author suggests improvements to the Bluetooth communication scheme and the general payment protocol.Andy Schroder introduces two proposed BIPs for implementing the payment protocol using Bluetooth connections. These proposals are modeled after Andreas Schildbach's Android Bitcoin Wallet's Bluetooth capability, which uses BLE technology. The author highlights the need for further discussion on various aspects of Bluetooth implementation. They also mention known issues that can be improved, such as inconsistency in connection header messages, unauthenticated Bluetooth connection, and lack of acknowledgement failure message in the payment protocol.The discussion explores whether BIPs should document how things should work or how they actually work. The need for informational BIPs and an efficient process for them is emphasized.SSL encryption on Bluetooth connections is suggested but considered complicated. Alternative PKIs and the issue of HTTP base failure signal are discussed. Merge avoidance and the trustworthiness of HTTPS are mentioned. The possibility of providing a full-fledged WiFi connection for customers is explored, requiring a sophisticated proxy server to allow access only to Bitcoin nodes. The dedicated blockchain radio is also discussed.In an email exchange between Mike Hearn and Andy Schroder, the issues with the existing Bluetooth payment protocol are discussed. They highlight the use of an unauthenticated Bluetooth connection and the lack of acknowledgement failure message. The conversation also touches on data storage in QR codes and the limit of offline transactions. The need for a lightweight library for ECDH key agreement and AES+HMAC encryption is mentioned. The discussion further explores the need for dedicated blockchain access and the challenges of providing a full-fledged WiFi connection.The author of this email discusses the implementation of the payment protocol using Bluetooth connections and introduces two proposed BIPs. The use of Bluetooth is important because it allows for payments to be made in areas with limited or no internet access. The proposed BIPs are based on Andreas Schildbach's Android Bitcoin Wallet's Bluetooth capability and include an additional parameter in the bitcoin: URI scheme for including a hash of the payment request.The author seeks feedback from wallet developers and others on these proposals, as widespread Bluetooth support among wallets is crucial. They provide links to copies of the proposed BIPs and a video demonstration showcasing the features using Schildbach's wallet and a fuel pump.There are known issues with the Bluetooth communication scheme and general payment protocol that the author and Andreas would like feedback on. These issues include inconsistencies in connection header messages, unauthenticated Bluetooth connections that are vulnerable to man-in-the-middle attacks, lack of acknowledgement failure message in the payment protocol, and the increasing size of QR codes when using a backwards compatible URL.Possible alternatives to the proposed solution are suggested, such as reversing the order of parameter numbers in the payment_url or creating a new payment_url_multi field for future use. The author concludes by inviting comments and suggestions from readers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_Update-to-Double-Spend-Deprecation-Window-Proposal.xml b/static/bitcoin-dev/Feb_2015/combined_Update-to-Double-Spend-Deprecation-Window-Proposal.xml index 37787aca24..37ed90e5c9 100644 --- a/static/bitcoin-dev/Feb_2015/combined_Update-to-Double-Spend-Deprecation-Window-Proposal.xml +++ b/static/bitcoin-dev/Feb_2015/combined_Update-to-Double-Spend-Deprecation-Window-Proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Update to Double-Spend Deprecation Window Proposal - 2023-08-01T11:24:30.978632+00:00 + 2025-10-11T21:41:11.340915+00:00 + python-feedgen Tom Harding 2015-02-09 13:37:39+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Update to Double-Spend Deprecation Window Proposal - 2023-08-01T11:24:30.978632+00:00 + 2025-10-11T21:41:11.341077+00:00 - Peter Todd has provided feedback on a proposal aiming to reduce the confirmation time of Bitcoin transactions from 10 minutes to around 30 seconds. However, Todd expressed concerns about the assumptions made in the proposal, highlighting that simply seeing or not seeing a transaction does not guarantee its validity. The author of the proposal responded by explaining that they have developed local rules to achieve a desirable outcome for the network. While the proposal addresses two specific attacks, the author remains open to learning about new attacks and flaws in existing treatments.One concern raised by Todd is the punishment of miners with imperfect connectivity, which he believes is unattainable in a decentralized system. The author argued that it is necessary to build from unavoidable imperfections when dealing with physical reality. Todd also mentioned that the proposal makes single-confirm double-spend attacks easier and puts more people at risk. However, the author disagreed, stating that the proposal effectively prevents most Finney attacks. The proposal suggests allowing transactions to mature for 15 to 30 seconds before mining them.To influence miners not to confirm double-spends after a certain time limit, an update has been introduced that changes the disincentive from a simple delay to a temporary chain work penalty. This change is crucial for the growth and stabilization of adoption. The penalty is graduated in two steps based on the respend gap, a concept first suggested by Hal Finney in 2011. The purpose of this change is to influence the miner of the block after a deprecated block, who in turn is concerned with the block after that. The double-spend deprecation window has been updated on Github to reflect this change, which is believed to be the minimum requirement to achieve the intended result. 2015-02-09T13:37:39+00:00 + Peter Todd has provided feedback on a proposal aiming to reduce the confirmation time of Bitcoin transactions from 10 minutes to around 30 seconds. However, Todd expressed concerns about the assumptions made in the proposal, highlighting that simply seeing or not seeing a transaction does not guarantee its validity. The author of the proposal responded by explaining that they have developed local rules to achieve a desirable outcome for the network. While the proposal addresses two specific attacks, the author remains open to learning about new attacks and flaws in existing treatments.One concern raised by Todd is the punishment of miners with imperfect connectivity, which he believes is unattainable in a decentralized system. The author argued that it is necessary to build from unavoidable imperfections when dealing with physical reality. Todd also mentioned that the proposal makes single-confirm double-spend attacks easier and puts more people at risk. However, the author disagreed, stating that the proposal effectively prevents most Finney attacks. The proposal suggests allowing transactions to mature for 15 to 30 seconds before mining them.To influence miners not to confirm double-spends after a certain time limit, an update has been introduced that changes the disincentive from a simple delay to a temporary chain work penalty. This change is crucial for the growth and stabilization of adoption. The penalty is graduated in two steps based on the respend gap, a concept first suggested by Hal Finney in 2011. The purpose of this change is to influence the miner of the block after a deprecated block, who in turn is concerned with the block after that. The double-spend deprecation window has been updated on Github to reflect this change, which is believed to be the minimum requirement to achieve the intended result. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_What-s-what-with-addr-relaying-.xml b/static/bitcoin-dev/Feb_2015/combined_What-s-what-with-addr-relaying-.xml index 2bae2cfb2e..753060ec3c 100644 --- a/static/bitcoin-dev/Feb_2015/combined_What-s-what-with-addr-relaying-.xml +++ b/static/bitcoin-dev/Feb_2015/combined_What-s-what-with-addr-relaying-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - What's what with addr relaying? - 2023-08-01T11:48:39.284382+00:00 + 2025-10-11T21:41:19.833115+00:00 + python-feedgen Thy Shizzle 2015-02-19 11:37:17+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - What's what with addr relaying? - 2023-08-01T11:48:39.284382+00:00 + 2025-10-11T21:41:19.833284+00:00 - The author is currently working on addr relaying for their C# Bitcoin node, Thashiznets/Lego.NET. They are in the process of wiring up their DB in Azure but are facing difficulties due to conflicting information present in two different specification documents. One of the documents fails to mention that the version message now includes a 4 byte checksum and no time in the net_addrs field. On the other hand, the second document provides this important information and also states that the heartbeat interval is 30 minutes and the disconnect interval is 90 minutes, which seems more sensible to the author. As a result, the author modifies their code based on this information.The author highlights the existence of other variations between these two specification documents and requests input from other developers who may be aware of these differences. They seek guidance on any additional variations they should be mindful of while working on addr relaying for their C# Bitcoin node.For further reference, the author provides links to the Github repository of Thashiznets/Lego.NET, the Developer Reference - Bitcoin on bitcoin.org, and the Satoshi Client Node Discovery - Bitcoin on en.bitcoin.it. These resources can provide more detailed information about the specifications and assist in resolving any discrepancies encountered during development. 2015-02-19T11:37:17+00:00 + The author is currently working on addr relaying for their C# Bitcoin node, Thashiznets/Lego.NET. They are in the process of wiring up their DB in Azure but are facing difficulties due to conflicting information present in two different specification documents. One of the documents fails to mention that the version message now includes a 4 byte checksum and no time in the net_addrs field. On the other hand, the second document provides this important information and also states that the heartbeat interval is 30 minutes and the disconnect interval is 90 minutes, which seems more sensible to the author. As a result, the author modifies their code based on this information.The author highlights the existence of other variations between these two specification documents and requests input from other developers who may be aware of these differences. They seek guidance on any additional variations they should be mindful of while working on addr relaying for their C# Bitcoin node.For further reference, the author provides links to the Github repository of Thashiznets/Lego.NET, the Developer Reference - Bitcoin on bitcoin.org, and the Satoshi Client Node Discovery - Bitcoin on en.bitcoin.it. These resources can provide more detailed information about the specifications and assist in resolving any discrepancies encountered during development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_alternate-proposal-opt-in-miner-takes-double-spend-Re-replace-by-fee-v0-10-0rc4-.xml b/static/bitcoin-dev/Feb_2015/combined_alternate-proposal-opt-in-miner-takes-double-spend-Re-replace-by-fee-v0-10-0rc4-.xml index 446ac23a3b..8b8ce9d2c4 100644 --- a/static/bitcoin-dev/Feb_2015/combined_alternate-proposal-opt-in-miner-takes-double-spend-Re-replace-by-fee-v0-10-0rc4-.xml +++ b/static/bitcoin-dev/Feb_2015/combined_alternate-proposal-opt-in-miner-takes-double-spend-Re-replace-by-fee-v0-10-0rc4-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4) - 2023-08-01T11:51:58.299162+00:00 + 2025-10-11T21:40:26.701850+00:00 + python-feedgen Mike Hearn 2015-02-23 11:03:36+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4) - 2023-08-01T11:51:58.300160+00:00 + 2025-10-11T21:40:26.702033+00:00 - During a discussion about the security of zero-confirmation (0-confirm) transactions in Bitcoin, it was highlighted that while these transactions are fast, they are not completely secure. There is a small chance that even one confirmation (1-confirm) transaction can be reversed, and an even higher chance that 0-confirms can be reversed. This raises concerns, especially for high-value transactions, as it could potentially compromise the integrity of the Bitcoin system.To address this issue, one proposed solution is to introduce a new signature type that allows miners to spend the transaction if a double-spend is detected before a 1-confirm. This additional layer of security would benefit senders, particularly in cases where accidental double-spends may occur due to hardware or software crashes. Importantly, this feature would be optional, so users are not obligated to put their high-value coins at risk.The introduction of this new signature type would be soft-forkable, as it involves a new transaction type. While long-term, more scalable solutions are desirable, it is crucial to ensure that the core network functions effectively as a stepping stone towards those solutions. 2015-02-23T11:03:36+00:00 + During a discussion about the security of zero-confirmation (0-confirm) transactions in Bitcoin, it was highlighted that while these transactions are fast, they are not completely secure. There is a small chance that even one confirmation (1-confirm) transaction can be reversed, and an even higher chance that 0-confirms can be reversed. This raises concerns, especially for high-value transactions, as it could potentially compromise the integrity of the Bitcoin system.To address this issue, one proposed solution is to introduce a new signature type that allows miners to spend the transaction if a double-spend is detected before a 1-confirm. This additional layer of security would benefit senders, particularly in cases where accidental double-spends may occur due to hardware or software crashes. Importantly, this feature would be optional, so users are not obligated to put their high-value coins at risk.The introduction of this new signature type would be soft-forkable, as it involves a new transaction type. While long-term, more scalable solutions are desirable, it is crucial to ensure that the core network functions effectively as a stepping stone towards those solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_bloom-filtering-privacy.xml b/static/bitcoin-dev/Feb_2015/combined_bloom-filtering-privacy.xml index fcc98f3d20..19dc809dbd 100644 --- a/static/bitcoin-dev/Feb_2015/combined_bloom-filtering-privacy.xml +++ b/static/bitcoin-dev/Feb_2015/combined_bloom-filtering-privacy.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bloom filtering, privacy - 2023-08-01T11:50:24.140601+00:00 + 2025-10-11T21:40:30.952892+00:00 + python-feedgen Chris Pacia 2015-02-21 18:38:05+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - bloom filtering, privacy - 2023-08-01T11:50:24.140601+00:00 + 2025-10-11T21:40:30.953068+00:00 - In an email conversation between Mike Hearn and another individual, they discuss the efficiency of querying a single node when an address in the wallet matches a block filter. Mike argues that this method is less efficient for clients in the long run, as blocks with 1500 transactions are common and Bitcoin is growing rapidly. He imagines a system 10 times larger than today's, which would result in 15,000 transactions per block. Assuming each transaction has 5 unique keys or elements, there would be 75,000 unique elements per block. With a false positive rate of 0.1%, this results in 131.63KB of extra overhead per block. Over the course of a day, this would amount to 18mb of data per day's worth of sync to pull down over the network. This amount of data may not be competitive for mobile devices even in developed countries. However, Mike argues that it doesn't matter much because anyone watching the wire close to you can still learn which transactions are yours, and anyone running a node can learn which transactions in the requested block were yours and follow the tx chain to learn which other transactions might be yours too.The conversation revolves around the efficiency of querying a single node when an address in a wallet matches the block filter. One person thinks it's efficient, while the other disagrees. The latter argues that with Bitcoin growing, there could be up to 15,000 transactions per block, each containing five unique keys/elements that might need matching. With a false-positive rate of 0.1%, this means 131.63KB per block extra overhead, which is equivalent to 18MB of data per day's worth of sync. This amount of data may not be fast enough for mobile devices and may hinder competitiveness. However, the former believes that it doesn't matter because anyone monitoring the wire close to a user knows which transactions are theirs, and running a node allows them to follow the transaction chain to figure out which other transactions might belong to them. Additionally, even if a user requests only one block from a peer, the peer knows they will eventually request more blocks since one of the transactions given was spent in that block.The discussion revolves around the efficiency of querying a single node when an address in the wallet matches the block filter, with the downside being that it relies entirely on Tor for privacy. The use of broadcasting also requires Tor for privacy in SPV clients. The conversation then moves on to receiving BIP70 payments directly and the need to query for block inclusion as an easy way to do so. A comment regarding committed bloom filters and UTXO sets is made, where the ability to verify that positive hits are correct via merkle path and false positives are not being wrongly withheld can be obtained by obtaining merkle path proof that they are not in the trie. The email concludes with a sponsored message about the BIRT iHub F-Type from Actuate and a Bitcoin-development mailing list.The conversation is focused on the topic of privacy in Bitcoin transactions. There is a discussion about the effectiveness of bloom filters and Tor against pervasive eavesdropper threat models. The speaker suggests that Bitcoin could benefit from a store-and-forward message bus with privacy and strong reliability. They mention the development of Subspace as a potential solution. The conversation also touches on the idea of wire encryption as a way to improve privacy, which the speaker sees as a more feasible option than a new PIR protocol. Overall, the conversation highlights the challenges and trade-offs involved in achieving greater privacy in Bitcoin transactions.The discussion revolves around privacy concerns for Bitcoin transactions and the use of Tor to mitigate them. The proposal is to use block bloom filters to index non-p2sh but non-simple transactions containing checksig, while still keeping the address visible. However, there are technical issues with this proposal as Bloom filtering protocol already does this server-side. Additionally, downloading per-block Bloom filter and testing against thousands of transactions in each block will not be efficient. Furthermore, a node round-trip for every block traversal must occur if the user cannot scan the chain in parallel. This latency kills performance, making it a non-starter. Although it is possible to work around this issue by ignoring OP_CHECKSIG outputs, this method does not solve any real problems. There are concerns about commercial fraudsters stealing money, but collecting Bloom filters off the wire does not help with this. Spies such as NSA/GCHQ are building databases of IP addresses to Bitcoin addresses, but requesting data from different nodes via Tor does not solve this problem either.Using Tor presents several practical issues, including booting up slowly without a warm consensus, Bitcoin Core's DoS strategy blocking all of Tor, trolls tampering with wire traffic, and the uncertainty of relying on Tor sticking around. A simpler solution would be to add opportunistic encryption to the wire protocol. Mid-term, some basic request tunneling as part of Bitcoin, that may not be Tor, could be added to 2015-02-21T18:38:05+00:00 + In an email conversation between Mike Hearn and another individual, they discuss the efficiency of querying a single node when an address in the wallet matches a block filter. Mike argues that this method is less efficient for clients in the long run, as blocks with 1500 transactions are common and Bitcoin is growing rapidly. He imagines a system 10 times larger than today's, which would result in 15,000 transactions per block. Assuming each transaction has 5 unique keys or elements, there would be 75,000 unique elements per block. With a false positive rate of 0.1%, this results in 131.63KB of extra overhead per block. Over the course of a day, this would amount to 18mb of data per day's worth of sync to pull down over the network. This amount of data may not be competitive for mobile devices even in developed countries. However, Mike argues that it doesn't matter much because anyone watching the wire close to you can still learn which transactions are yours, and anyone running a node can learn which transactions in the requested block were yours and follow the tx chain to learn which other transactions might be yours too.The conversation revolves around the efficiency of querying a single node when an address in a wallet matches the block filter. One person thinks it's efficient, while the other disagrees. The latter argues that with Bitcoin growing, there could be up to 15,000 transactions per block, each containing five unique keys/elements that might need matching. With a false-positive rate of 0.1%, this means 131.63KB per block extra overhead, which is equivalent to 18MB of data per day's worth of sync. This amount of data may not be fast enough for mobile devices and may hinder competitiveness. However, the former believes that it doesn't matter because anyone monitoring the wire close to a user knows which transactions are theirs, and running a node allows them to follow the transaction chain to figure out which other transactions might belong to them. Additionally, even if a user requests only one block from a peer, the peer knows they will eventually request more blocks since one of the transactions given was spent in that block.The discussion revolves around the efficiency of querying a single node when an address in the wallet matches the block filter, with the downside being that it relies entirely on Tor for privacy. The use of broadcasting also requires Tor for privacy in SPV clients. The conversation then moves on to receiving BIP70 payments directly and the need to query for block inclusion as an easy way to do so. A comment regarding committed bloom filters and UTXO sets is made, where the ability to verify that positive hits are correct via merkle path and false positives are not being wrongly withheld can be obtained by obtaining merkle path proof that they are not in the trie. The email concludes with a sponsored message about the BIRT iHub F-Type from Actuate and a Bitcoin-development mailing list.The conversation is focused on the topic of privacy in Bitcoin transactions. There is a discussion about the effectiveness of bloom filters and Tor against pervasive eavesdropper threat models. The speaker suggests that Bitcoin could benefit from a store-and-forward message bus with privacy and strong reliability. They mention the development of Subspace as a potential solution. The conversation also touches on the idea of wire encryption as a way to improve privacy, which the speaker sees as a more feasible option than a new PIR protocol. Overall, the conversation highlights the challenges and trade-offs involved in achieving greater privacy in Bitcoin transactions.The discussion revolves around privacy concerns for Bitcoin transactions and the use of Tor to mitigate them. The proposal is to use block bloom filters to index non-p2sh but non-simple transactions containing checksig, while still keeping the address visible. However, there are technical issues with this proposal as Bloom filtering protocol already does this server-side. Additionally, downloading per-block Bloom filter and testing against thousands of transactions in each block will not be efficient. Furthermore, a node round-trip for every block traversal must occur if the user cannot scan the chain in parallel. This latency kills performance, making it a non-starter. Although it is possible to work around this issue by ignoring OP_CHECKSIG outputs, this method does not solve any real problems. There are concerns about commercial fraudsters stealing money, but collecting Bloom filters off the wire does not help with this. Spies such as NSA/GCHQ are building databases of IP addresses to Bitcoin addresses, but requesting data from different nodes via Tor does not solve this problem either.Using Tor presents several practical issues, including booting up slowly without a warm consensus, Bitcoin Core's DoS strategy blocking all of Tor, trolls tampering with wire traffic, and the uncertainty of relying on Tor sticking around. A simpler solution would be to add opportunistic encryption to the wire protocol. Mid-term, some basic request tunneling as part of Bitcoin, that may not be Tor, could be added to - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_determining-change-addresses-using-the-least-significant-digits.xml b/static/bitcoin-dev/Feb_2015/combined_determining-change-addresses-using-the-least-significant-digits.xml index 5f6958bf6f..6b1919de0e 100644 --- a/static/bitcoin-dev/Feb_2015/combined_determining-change-addresses-using-the-least-significant-digits.xml +++ b/static/bitcoin-dev/Feb_2015/combined_determining-change-addresses-using-the-least-significant-digits.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - determining change addresses using the least significant digits - 2023-08-01T11:22:10.809773+00:00 + 2025-10-11T21:41:13.464403+00:00 + python-feedgen Gregory Maxwell 2015-02-06 18:21:09+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - determining change addresses using the least significant digits - 2023-08-01T11:22:10.809773+00:00 + 2025-10-11T21:41:13.464569+00:00 - In a discussion about Bitcoin client, Isidor Zeuner proposed a possible issue with the current functionality of hiding change addresses going back to the payer. With dynamically calculated miner fees, it may be easy for an observer to classify the output addresses because users sending payments often enter the payment amount only up to the significant digits, while the least significant digits are often zero. To handle this issue, adding a randomized offset amount to the payment amount is suggested. However, sending too much can cause issues with accounting, so another strategy proposed is to create two change outputs and make one equal to the payment amount or split the change evenly. One user suggested randomly rounding up the output when paying to a depository account, but a user interface for this feature has not been determined yet.On 2nd June 2015, Jeff Garzik responded to a query regarding adding additional inputs and outputs to increase privacy and defragment wallet. He stated that it can be done, and regular spends can resemble CoinJoin transactions and vice versa. The message ends with a note on supporting online privacy by using email encryption whenever possible and a link to learn more. Additionally, the message includes a PGP signature. There was also a non-text attachment included in the message, which is a file named "0xEAD9E623.asc" of type application/pgp-keys, with a size of 14416 bytes.The email thread discusses the possibility of adding a randomized offset amount to payment amounts to increase privacy in bitcoin wallets. The idea is one way to obfuscate payment amounts, but there have been more sophisticated ideas such as adding multiple change outputs or distributing over multiple transactions. Mike Hearn had ideas regarding obfuscation of payment amounts, which he wrote about in a blog post. It is possible to add additional inputs and outputs to defrag wallets and increase privacy simultaneously. Jeff Garzik, a Bitcoin core developer and open source evangelist at BitPay, contributed to the discussion.On February 4th, 2015, Isidor Zeuner proposed a solution to handle an issue by adding a randomized offset amount to the payment amount. However, there have been more sophisticated ideas to obfuscate the amount such as adding multiple change outputs or distributing over multiple transactions. Mike Hearn, who had some ideas about the obfuscation of payment amounts, wrote about them in a blog post. The link to his blog is provided in the email response from Wladimir.The Bitcoin client has traditionally hidden which output addresses are change addresses going back to the payer. However, with dynamically calculated miner fees, this may often be ineffective because the least significant digits will often be zero for the payment, but not for the change amount. This makes it easy for an observer to classify the output addresses. One possible approach to handle this issue would be to add a randomized offset amount to the payment amount. Another approach is to randomize the number of change outputs from transaction to transaction. By doing this, it would be possible to make change outputs that mimic real spends with a low number of s.d. It is recommended to support online privacy by using email encryption whenever possible and to learn how to do so at http://www.youtube.com/watch?v=bakOKJFtB-k.In a discussion on the Bitcoin mailing list, Isidor Zeuner brought up the issue of change addresses being visible to observers due to dynamically calculated miner fees. When a user sends a payment, they usually only enter the significant digits, leaving the least significant digits as zero. However, with dynamically calculated miner fees, this is often not the case for the change amount, making it easy for an observer to classify the output addresses. Zeuner suggested adding a randomized offset amount to the payment amount to address this issue. Another user recommended looking at Armory, which reportedly implements similar features.In the world of Bitcoin, there is a potential vulnerability that could allow anyone to classify an output address as a change address going back to the payer. This occurs due to the fact that users sending payments using the Bitcoin client will only enter the payment amount up to a certain number of significant digits, which often means that the least significant digits are zero. With dynamically calculated miner fees, this is not always the case for the change amount, making it easier for observers to classify the output addresses. To combat this issue, a possible solution would be to add a randomized offset amount to the payment amount that is small in comparison but helps to hide the change address. 2015-02-06T18:21:09+00:00 + In a discussion about Bitcoin client, Isidor Zeuner proposed a possible issue with the current functionality of hiding change addresses going back to the payer. With dynamically calculated miner fees, it may be easy for an observer to classify the output addresses because users sending payments often enter the payment amount only up to the significant digits, while the least significant digits are often zero. To handle this issue, adding a randomized offset amount to the payment amount is suggested. However, sending too much can cause issues with accounting, so another strategy proposed is to create two change outputs and make one equal to the payment amount or split the change evenly. One user suggested randomly rounding up the output when paying to a depository account, but a user interface for this feature has not been determined yet.On 2nd June 2015, Jeff Garzik responded to a query regarding adding additional inputs and outputs to increase privacy and defragment wallet. He stated that it can be done, and regular spends can resemble CoinJoin transactions and vice versa. The message ends with a note on supporting online privacy by using email encryption whenever possible and a link to learn more. Additionally, the message includes a PGP signature. There was also a non-text attachment included in the message, which is a file named "0xEAD9E623.asc" of type application/pgp-keys, with a size of 14416 bytes.The email thread discusses the possibility of adding a randomized offset amount to payment amounts to increase privacy in bitcoin wallets. The idea is one way to obfuscate payment amounts, but there have been more sophisticated ideas such as adding multiple change outputs or distributing over multiple transactions. Mike Hearn had ideas regarding obfuscation of payment amounts, which he wrote about in a blog post. It is possible to add additional inputs and outputs to defrag wallets and increase privacy simultaneously. Jeff Garzik, a Bitcoin core developer and open source evangelist at BitPay, contributed to the discussion.On February 4th, 2015, Isidor Zeuner proposed a solution to handle an issue by adding a randomized offset amount to the payment amount. However, there have been more sophisticated ideas to obfuscate the amount such as adding multiple change outputs or distributing over multiple transactions. Mike Hearn, who had some ideas about the obfuscation of payment amounts, wrote about them in a blog post. The link to his blog is provided in the email response from Wladimir.The Bitcoin client has traditionally hidden which output addresses are change addresses going back to the payer. However, with dynamically calculated miner fees, this may often be ineffective because the least significant digits will often be zero for the payment, but not for the change amount. This makes it easy for an observer to classify the output addresses. One possible approach to handle this issue would be to add a randomized offset amount to the payment amount. Another approach is to randomize the number of change outputs from transaction to transaction. By doing this, it would be possible to make change outputs that mimic real spends with a low number of s.d. It is recommended to support online privacy by using email encryption whenever possible and to learn how to do so at http://www.youtube.com/watch?v=bakOKJFtB-k.In a discussion on the Bitcoin mailing list, Isidor Zeuner brought up the issue of change addresses being visible to observers due to dynamically calculated miner fees. When a user sends a payment, they usually only enter the significant digits, leaving the least significant digits as zero. However, with dynamically calculated miner fees, this is often not the case for the change amount, making it easy for an observer to classify the output addresses. Zeuner suggested adding a randomized offset amount to the payment amount to address this issue. Another user recommended looking at Armory, which reportedly implements similar features.In the world of Bitcoin, there is a potential vulnerability that could allow anyone to classify an output address as a change address going back to the payer. This occurs due to the fact that users sending payments using the Bitcoin client will only enter the payment amount up to a certain number of significant digits, which often means that the least significant digits are zero. With dynamically calculated miner fees, this is not always the case for the change amount, making it easier for observers to classify the output addresses. To combat this issue, a possible solution would be to add a randomized offset amount to the payment amount that is small in comparison but helps to hide the change address. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_replace-by-fee-v0-10-0rc4.xml b/static/bitcoin-dev/Feb_2015/combined_replace-by-fee-v0-10-0rc4.xml index ec3ad34f3d..aad2deaec9 100644 --- a/static/bitcoin-dev/Feb_2015/combined_replace-by-fee-v0-10-0rc4.xml +++ b/static/bitcoin-dev/Feb_2015/combined_replace-by-fee-v0-10-0rc4.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - replace-by-fee v0.10.0rc4 - 2023-08-01T11:29:50.426652+00:00 + 2025-10-11T21:40:50.080626+00:00 + python-feedgen Neil Fincham 2015-03-01 19:05:39+00:00 @@ -307,13 +308,13 @@ - python-feedgen + 2 Combined summary - replace-by-fee v0.10.0rc4 - 2023-08-01T11:29:50.427648+00:00 + 2025-10-11T21:40:50.080908+00:00 - In a series of email conversations and forum discussions within the Bitcoin community, several topics related to the issue of double-spending in Bitcoin are explored. One of the main focuses is on the concept of replace-by-fee (RBF) and its potential impact on zero confirmation (0-conf) transactions. There are concerns that implementing RBF for all transactions could harm present-day Bitcoin payments and push instant transactions towards centralized services. However, there is also recognition that 0-conf transactions need a security upgrade.Jeff Garzik, a Bitcoin core developer, acknowledges the importance of secure 0-conf transactions for rapid payments but emphasizes the need for careful consideration when making changes to avoid harming the system. He suggests finding a solution that balances security and convenience. The distinction between fee replacement and output replacement in double-spending cases is discussed. It is suggested that fee replacement can be handled by relaying both conflicting transactions and letting miners choose one, while output replacement can be rewarded to a miner if they include both conflicting transactions in the same block.The conversation also delves into the ANYONECANPAY feature in Bitcoin and its potential vulnerabilities. Ways to defeat this feature through double-spending with high fees are discussed, as well as concerns about the effectiveness of the replace-by-fee patch in detecting and relaying double-spends. The importance of understanding weaknesses and limitations in order to improve the system is emphasized.The need for reversible mechanisms and decentralized solutions in payment processing technologies is highlighted. The proposal of "Solomon's spend" as a potential solution involving a hacked exchange, insurance contracts, and incentivizing miners to roll back the chain is presented. The importance of balancing security and convenience in developing payment processing technologies is emphasized.The discussions also touch on the issue of settlement times in payment systems and the benefits of reversible mechanisms built on top of Bitcoin. The suggestion is made to extend the zero-conf double-spend transaction reversal to allow senders and receivers a choice to use it or not. The need for a base currency that is non-reversible is highlighted.There are debates about the terminology used to describe the 0-conf protocol based on game theory, with suggestions to extend the zero-conf double-spend transaction reversal explicitly. The rarity of massive double-spending incidents in Bitcoin is discussed, as well as concerns about relying on moral judgments and altruism as a security model.The controversy around replace-by-fee (RBF) in Bitcoin transactions is also explored. Some argue in favor of RBF, stating that it can improve the efficiency of the transaction fee marketplace. Others raise concerns about its potential misuse and negative impact on the Bitcoin network.Overall, the discussions highlight the need for solutions to address the issue of double-spending in Bitcoin while considering the trade-offs between security, convenience, and decentralization. The importance of understanding weaknesses, improving security through penetration testing, and developing alternative solutions is emphasized.In a series of email exchanges in February 2015, the risks and limitations of relying on zero-confirmation transactions in Bitcoin were discussed. One concept that was debated was replace-by-fee (RBF), which allows users to increase the fee of a transaction after it has been sent, potentially leading to double-spending. While some considered RBF fraudulent, others saw it differently.The context emphasizes the vulnerabilities of Bitcoin, particularly for merchants who accept payments with zero confirmations. It is suggested that these merchants may be targeted by attackers. To mitigate this risk, some merchants may establish a network of trusted third parties to interact with the blockchain. However, cunning merchants could exploit this system by keeping transactions counter-signed by third parties in their wallets and passing them along without paying miner fees until someone needs to pay all the fees at once.Bitcoin's vulnerability to attacks by a large group of miners is also discussed. However, it is noted that such attacks are not directed towards Bitcoin itself but towards merchants who accept zero-confirmation payments. The possibility of proving a double spend instantly by showing conflicting transactions signed by the same party is mentioned.There is a suggestion to explore alternative solutions to address the potential unreliability of unconfirmed payments, as people may stop using Bitcoin if they become unreliable. One proposed solution is a decentralized IOU-based payment network similar to Ripple, specifically designed for "dumb and daily" payments. This would eliminate the need for zero-confirmation transactions and reduce the need to debate block size limits.The idea of collateralized multisignature notaries is introduced as an extended version of the Greenaddress.it model. This model renders unconfirmed transactions useless in the classical Bitcoin model. However, introducing trusted third parties would reintroduce the disadvantages of centralized trust.The role of miners and their incentives in Bitcoin is discussed. It is argued that miners are incentivized not to earn the most money in the next block but to maximize their return on investment. Making Bitcoin less useful would reduce the demand for mined bitcoins, resulting in a decrease in income for miners.Various email exchanges between individuals such as Tamas Bl 2015-03-01T19:05:39+00:00 + In a series of email conversations and forum discussions within the Bitcoin community, several topics related to the issue of double-spending in Bitcoin are explored. One of the main focuses is on the concept of replace-by-fee (RBF) and its potential impact on zero confirmation (0-conf) transactions. There are concerns that implementing RBF for all transactions could harm present-day Bitcoin payments and push instant transactions towards centralized services. However, there is also recognition that 0-conf transactions need a security upgrade.Jeff Garzik, a Bitcoin core developer, acknowledges the importance of secure 0-conf transactions for rapid payments but emphasizes the need for careful consideration when making changes to avoid harming the system. He suggests finding a solution that balances security and convenience. The distinction between fee replacement and output replacement in double-spending cases is discussed. It is suggested that fee replacement can be handled by relaying both conflicting transactions and letting miners choose one, while output replacement can be rewarded to a miner if they include both conflicting transactions in the same block.The conversation also delves into the ANYONECANPAY feature in Bitcoin and its potential vulnerabilities. Ways to defeat this feature through double-spending with high fees are discussed, as well as concerns about the effectiveness of the replace-by-fee patch in detecting and relaying double-spends. The importance of understanding weaknesses and limitations in order to improve the system is emphasized.The need for reversible mechanisms and decentralized solutions in payment processing technologies is highlighted. The proposal of "Solomon's spend" as a potential solution involving a hacked exchange, insurance contracts, and incentivizing miners to roll back the chain is presented. The importance of balancing security and convenience in developing payment processing technologies is emphasized.The discussions also touch on the issue of settlement times in payment systems and the benefits of reversible mechanisms built on top of Bitcoin. The suggestion is made to extend the zero-conf double-spend transaction reversal to allow senders and receivers a choice to use it or not. The need for a base currency that is non-reversible is highlighted.There are debates about the terminology used to describe the 0-conf protocol based on game theory, with suggestions to extend the zero-conf double-spend transaction reversal explicitly. The rarity of massive double-spending incidents in Bitcoin is discussed, as well as concerns about relying on moral judgments and altruism as a security model.The controversy around replace-by-fee (RBF) in Bitcoin transactions is also explored. Some argue in favor of RBF, stating that it can improve the efficiency of the transaction fee marketplace. Others raise concerns about its potential misuse and negative impact on the Bitcoin network.Overall, the discussions highlight the need for solutions to address the issue of double-spending in Bitcoin while considering the trade-offs between security, convenience, and decentralization. The importance of understanding weaknesses, improving security through penetration testing, and developing alternative solutions is emphasized.In a series of email exchanges in February 2015, the risks and limitations of relying on zero-confirmation transactions in Bitcoin were discussed. One concept that was debated was replace-by-fee (RBF), which allows users to increase the fee of a transaction after it has been sent, potentially leading to double-spending. While some considered RBF fraudulent, others saw it differently.The context emphasizes the vulnerabilities of Bitcoin, particularly for merchants who accept payments with zero confirmations. It is suggested that these merchants may be targeted by attackers. To mitigate this risk, some merchants may establish a network of trusted third parties to interact with the blockchain. However, cunning merchants could exploit this system by keeping transactions counter-signed by third parties in their wallets and passing them along without paying miner fees until someone needs to pay all the fees at once.Bitcoin's vulnerability to attacks by a large group of miners is also discussed. However, it is noted that such attacks are not directed towards Bitcoin itself but towards merchants who accept zero-confirmation payments. The possibility of proving a double spend instantly by showing conflicting transactions signed by the same party is mentioned.There is a suggestion to explore alternative solutions to address the potential unreliability of unconfirmed payments, as people may stop using Bitcoin if they become unreliable. One proposed solution is a decentralized IOU-based payment network similar to Ripple, specifically designed for "dumb and daily" payments. This would eliminate the need for zero-confirmation transactions and reduce the need to debate block size limits.The idea of collateralized multisignature notaries is introduced as an extended version of the Greenaddress.it model. This model renders unconfirmed transactions useless in the classical Bitcoin model. However, introducing trusted third parties would reintroduce the disadvantages of centralized trust.The role of miners and their incentives in Bitcoin is discussed. It is argued that miners are incentivized not to earn the most money in the next block but to maximize their return on investment. Making Bitcoin less useful would reduce the demand for mined bitcoins, resulting in a decrease in income for miners.Various email exchanges between individuals such as Tamas Bl - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2015/combined_var-int-ambiguous-serialization-consequences.xml b/static/bitcoin-dev/Feb_2015/combined_var-int-ambiguous-serialization-consequences.xml index a3f67b4e2d..921064405b 100644 --- a/static/bitcoin-dev/Feb_2015/combined_var-int-ambiguous-serialization-consequences.xml +++ b/static/bitcoin-dev/Feb_2015/combined_var-int-ambiguous-serialization-consequences.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - var_int ambiguous serialization consequences - 2023-08-01T11:20:16.574274+00:00 + 2025-10-11T21:41:17.711250+00:00 + python-feedgen Pieter Wuille 2015-02-01 15:00:39+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - var_int ambiguous serialization consequences - 2023-08-01T11:20:16.574274+00:00 + 2025-10-11T21:41:17.711437+00:00 - In a discussion about the consequences of using longer than necessary forms of var_int in Bitcoin protocol documentation, Tamas Blummer raised concerns about the potential implications. However, it was clarified by Wladimir that the topic being discussed was actually CompactSize and not VarInt. CompactSizes have redundancy in their representation, allowing the same number to be represented in up to four different byte sequences. On the other hand, VARINTs were designed without any redundancy in their representation but are currently not used anywhere in the block chain.Tamas expressed interest in the possible consequences of applying size limits to a block, specifically regarding the transaction count which is var_int but not included in the hashed header or merkle tree. He suggested that using longer than necessary forms of var_int could create variants of the same transaction message by altering the representation of txIn and txOut counts. These variants would remain valid as long as the signatures validate with the shortest form.Wladimir questioned the relevance of this concern, pointing out that non-canonical CompactSizes are forbidden. This is flagged in the serialize.h's ReadCompactSize function. Therefore, he implied that the current concern regarding longer than necessary forms of var_int may not be significant.The author, Tamas Blummer, also highlighted some potential issues that could arise from using longer than necessary forms of var_int. For example, an implementation that holds mempool by raw message hashes could be tricked into believing that a modified encoded version of the same transaction is a real double spend. Additionally, one could mine a valid block with transactions that have a different hash if they are regularly parsed and re-serialized. Furthermore, an SPV client could be confused by such a transaction as it would appear in the merkle tree proof with a different hash compared to its own serialization or the raw message.In conclusion, the discussion revolved around the use of CompactSize and VarInt in Bitcoin protocol documentation. While Tamas expressed concerns about the consequences of using longer than necessary forms of var_int, Wladimir clarified that the topic being discussed was actually CompactSize. The redundancy in CompactSize representation and the absence of VARINT usage in the block chain were highlighted. Additionally, potential implications such as creating variants of transaction messages and tricking implementations and clients were mentioned. Ultimately, both individuals signed off from the conversation. 2015-02-01T15:00:39+00:00 + In a discussion about the consequences of using longer than necessary forms of var_int in Bitcoin protocol documentation, Tamas Blummer raised concerns about the potential implications. However, it was clarified by Wladimir that the topic being discussed was actually CompactSize and not VarInt. CompactSizes have redundancy in their representation, allowing the same number to be represented in up to four different byte sequences. On the other hand, VARINTs were designed without any redundancy in their representation but are currently not used anywhere in the block chain.Tamas expressed interest in the possible consequences of applying size limits to a block, specifically regarding the transaction count which is var_int but not included in the hashed header or merkle tree. He suggested that using longer than necessary forms of var_int could create variants of the same transaction message by altering the representation of txIn and txOut counts. These variants would remain valid as long as the signatures validate with the shortest form.Wladimir questioned the relevance of this concern, pointing out that non-canonical CompactSizes are forbidden. This is flagged in the serialize.h's ReadCompactSize function. Therefore, he implied that the current concern regarding longer than necessary forms of var_int may not be significant.The author, Tamas Blummer, also highlighted some potential issues that could arise from using longer than necessary forms of var_int. For example, an implementation that holds mempool by raw message hashes could be tricked into believing that a modified encoded version of the same transaction is a real double spend. Additionally, one could mine a valid block with transactions that have a different hash if they are regularly parsed and re-serialized. Furthermore, an SPV client could be confused by such a transaction as it would appear in the merkle tree proof with a different hash compared to its own serialization or the raw message.In conclusion, the discussion revolved around the use of CompactSize and VarInt in Bitcoin protocol documentation. While Tamas expressed concerns about the consequences of using longer than necessary forms of var_int, Wladimir clarified that the topic being discussed was actually CompactSize. The redundancy in CompactSize representation and the absence of VARINT usage in the block chain were highlighted. Additionally, potential implications such as creating variants of transaction messages and tricking implementations and clients were mentioned. Ultimately, both individuals signed off from the conversation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Feb_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml b/static/bitcoin-dev/Feb_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml index 4a92ee3fbf..81d9826187 100644 --- a/static/bitcoin-dev/Feb_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml +++ b/static/bitcoin-dev/Feb_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml @@ -2,7 +2,7 @@ 2 Combined summary - [BIP Draft] Allow zero value OP_RETURN in Payment Protocol - 2025-09-26T15:40:48.249741+00:00 + 2025-10-11T21:52:03.941569+00:00 python-feedgen Toby Padilla 2016-02-02 19:22:10+00:00 @@ -101,10 +101,11 @@ + 2 Combined summary - [BIP Draft] Allow zero value OP_RETURN in Payment Protocol - 2025-09-26T15:40:48.249931+00:00 + 2025-10-11T21:52:03.941770+00:00 2016-02-02T19:22:10+00:00 In a discussion between Toby Padilla and Luke Dashjr, the use of OP_RETURN values in Bitcoin transactions is debated. Toby argues that PaymentRequests limit the use of OP_RETURN values, as they must be greater than zero, creating a pre-OP_RETURN environment. Luke counters, suggesting that coins should be burned instead of allowing zero value OP_RETURNs. However, Toby believes there is a better alternative.The conversation revolves around the limitations of PaymentRequests regarding OP_RETURN values. Toby explains that PaymentRequests allow for similar transactions as non-PaymentRequest based transactions, but with the limitation that OP_RETURN values must be greater than zero. In contrast, Luke believes that OP_RETURN can be used, but coins would need to be burned, and he sees no benefit in changing that.Toby clarifies his point by mentioning BIP70, where the key for redeeming inputs can be in the user's wallet, allowing transaction construction on another machine without needing a key. However, currently, transaction construction on another machine with zero value OP_RETURNs is not possible. Despite their disagreement, both parties acknowledge that a key is always necessary for redeeming inputs in Bitcoin transactions.On January 26, 2016, Toby sent a message to Luke discussing the encoding of data on the blockchain. Luke suggests that supporting OP_RETURN in PaymentRequests is unnecessary, but Toby argues that it is important because people may use worse methods for encoding data. Toby also mentions the difficulty of constructing a transaction with a zero value OP_RETURN without keys in an environment without keys. Luke does not understand Toby's statement.The discussion focuses on a draft proposal that has not been approved by the mailing list yet. The draft suggests accepting zero value OP_RETURN outputs in BIP70 payment requests, which were previously ignored. The author argues that this feature would be useful for encoding data on the blockchain using PaymentRequests. However, Luke strongly advises against publishing or implementing this BIP, as he sees no benefit to the network and believes it could encourage spam. He also argues that the proposed changes are detrimental and would make users unwilling participants in spam.The author responds by giving an example of how merchants can add the hash of a plain text invoice to the checkout transaction by constructing the PaymentRequest with the invoice hash in an OP_RETURN. Toby argues that merchants and Bitcoin application developers would benefit from this BIP because they can construct transactions with OP_RETURN data without needing keys. Prior to this BIP, such transactions needed to be executed within the same software. Luke questions the relevance to keys and argues that the proposed changes are not compatible with existing and future software. He concludes that implementing either BIP 70 or this draft would have severe consequences, emphasizing that losing burned bitcoins is better than having a way to avoid them.The author of a Bitcoin Improvement Proposal (BIP) warns against publishing or implementing it due to potential spam and user unwillingness. The BIP suggests allowing merchants to add plain text invoice hashes to checkout transactions using PaymentRequests with zero value OP_RETURN outputs. However, the proposal lacks wallet support for checking upfront, may encourage spam, and does not consider the relevance to keys. The proposed changes are also not backward nor forward compatible, resulting in severe consequences.The author has submitted a new BIP draft that alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. This allows wallets to participate in current and future use cases that benefit from metadata stored in OP_RETURN. Previously, OP_RETURN transactions required custom software, but now wallets can process PaymentRequests with OP_RETURN data, supporting sophisticated Bitcoin applications without prior knowledge. Merchants and Bitcoin application developers benefit from this BIP by being able to construct transactions with OP_RETURN data in a keyless environment. Without supporting this BIP, wallets that support BIP70 will allow wasteful data storage. diff --git a/static/bitcoin-dev/Feb_2016/combined_-BIP-Proposal-New-feefilter-p2p-message.xml b/static/bitcoin-dev/Feb_2016/combined_-BIP-Proposal-New-feefilter-p2p-message.xml index 8d297f66cc..7298e16021 100644 --- a/static/bitcoin-dev/Feb_2016/combined_-BIP-Proposal-New-feefilter-p2p-message.xml +++ b/static/bitcoin-dev/Feb_2016/combined_-BIP-Proposal-New-feefilter-p2p-message.xml @@ -2,7 +2,7 @@ 2 Combined summary - [BIP Proposal] New "feefilter" p2p message - 2025-09-26T15:41:28.407384+00:00 + 2025-10-11T21:52:44.321280+00:00 python-feedgen Gregory Maxwell 2016-02-17 02:43:02+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - [BIP Proposal] New "feefilter" p2p message - 2025-09-26T15:41:28.407550+00:00 + 2025-10-11T21:52:44.321474+00:00 2016-02-17T02:43:02+00:00 In a bitcoin-dev mailing list thread, developers discussed the feefilter message and its usefulness. The message is defined as a message containing an int64_t where pchCommand == "feefilter". Luke Dashjr questioned the lack of extensibility in the message, suggesting that a priorityrate filter could be interesting. However, as there are currently no plans to add an index for ancestor priority rate or create a space-limited priority mempool, a new "priorityfilt" command could be added if needed.Alex Morcos suggested the feefilter message could be useless for wallets because it is additive with a bloom filter for transactions. Transactions would only be relayed if they passed both filters, making it difficult for SPV clients to learn about their own transactions. Dashjr argued that regardless of a user's feefilter, if a transaction has too low of a rate for peers to relay, users won't learn of it. He mentioned a use case for an OR behavior where he would relay very high fee transactions or his own. However, due to the privacy disaster of bloom filters and the need for validation to relay third-party transactions, it would not be practical. Dashjr suggested that a priorityrate filter could be used as an OR instead.The Bitcoin Developer mailing list discussed the "feefilter" message and its definition as a message containing an int64_t, which raised questions about extensibility. The use of different feerate definition versions was suggested to avoid the need for a new protocol extension for every new policy.Luke Dashjr questioned the usefulness of the message for wallets due to the fact that transactions would only be relayed if they passed both the fee filter and a bloom filter. However, Alex Morcos clarified that sending feefilter messages should not reduce the number of transactions accepted into the mempool. The discussion also highlighted the issue of privacy concerns with light clients using bloom filters.In this email exchange, Luke Dashjr questions the use of an int64_t datatype for the feefilter message in Bitcoin development. He argues that it is wasteful to allocate such a large number of bits for what will likely be a small number. Additionally, he questions the lack of extensibility in the current system.Alex Morcos defends his decision by stating that the command string system already provides sufficient extensibility and that a different command name can be given to a better version of feefilter if developed later. He also notes that the 8-byte size of the message is not a significant optimization issue given the low frequency of its use compared to ping traffic. Morcos also clarifies that the feefilter is additive with a bloom filter for transactions, meaning that transactions must pass both filters to be relayed.Dashjr questions the usefulness of this for wallets, but Morcos points out that sending feefilter messages should not affect the acceptance of transactions into the mempool. The email thread ends with no further resolution on the issue.In a Bitcoin developer forum post on February 16, 2016, Alex Morcos questioned the use of the feefilter message, which is defined as a message containing an int64_t where pchCommand == "feefilter". He asked about extensibility and why 64 bits would be used for what is likely a small number. Another user, Luke, pointed out that the fee filter is additive with a bloom filter for transactions, so if an SPV client loaded a bloom filter and sent a feefilter message, transactions would only be relayed if they passed both filters. Luke indicated that this seemed to make feefilter entirely useless for wallets.A proposal has been made to add a new optional peer-to-peer (p2p) message called "feefilter" that would help to reduce unnecessary network traffic. This message would inform peers of the minimum fee below which no transactions are accepted to a node's mempool, saving them from requesting transaction ids and saving the node from requesting transactions that are not in its recentRejects filter.The feefilter message is optional and can be ignored as a protocol rule, and there is also an option to turn off sending the messages within the implementation. The draft BIP text provides an abstract, motivation, specification, considerations, backward compatibility, and implementation details.The feefilter message is designed to instruct peers not to send inv's to a node for transactions with fees below the specified fee rate, and it is meant to filter transactions that are not accepted to a node's mempool, without adversely affecting the propagation efficiency of transactions across the network.There are privacy concerns related to deanonymizing a node by broadcasting identifying information about its mempool min fee, but these concerns are addressed by quantizing the filter value broadcast with a small amount of randomness and broadcasting messages to different peers at individually randomly distributed times. The sending of feefilter messages can be disabled by unsetting the "-feefilter" option, and older clients diff --git a/static/bitcoin-dev/Feb_2016/combined_A-roadmap-to-a-better-header-format-and-bigger-block-size.xml b/static/bitcoin-dev/Feb_2016/combined_A-roadmap-to-a-better-header-format-and-bigger-block-size.xml index bb69f59f70..b289631db9 100644 --- a/static/bitcoin-dev/Feb_2016/combined_A-roadmap-to-a-better-header-format-and-bigger-block-size.xml +++ b/static/bitcoin-dev/Feb_2016/combined_A-roadmap-to-a-better-header-format-and-bigger-block-size.xml @@ -2,7 +2,7 @@ 2 Combined summary - A roadmap to a better header format and bigger block size - 2025-09-26T15:41:32.628537+00:00 + 2025-10-11T21:52:48.572782+00:00 python-feedgen jl2012 at xbt.hk 2016-02-10 04:26:03+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - A roadmap to a better header format and bigger block size - 2025-09-26T15:41:32.628670+00:00 + 2025-10-11T21:52:48.572947+00:00 2016-02-10T04:26:03+00:00 In a discussion about improving the header format and increasing the block size for Bitcoin, developer Matt Corallo supports a proposal to implement changes in stages. However, he suggests that only one hardfork should be scheduled at a time to avoid complications. Corallo agrees with most of the proposal but wants to spend more time considering Luke-Jr's header changes and also suggests adding timewarp fixes for enhanced safety and reduced disruption. It is important to note that any client designed for stage 2 should also be ready for stage 3.Another developer on the Bitcoin-dev mailing list, jl2012, proposed a 2-3 year roadmap with three stages of rule changes. Stage 1 is Segregated Witness (BIP141), which will not break any existing full or light nodes. This stage may happen in Q2-Q3 2016. Stage 2 includes fixes that will break existing full nodes but not light nodes, which may occur in Q1-Q2 2017. Stage 3 involves fixes that will break all existing full and light nodes and may take place in 2018 to 2019. An alternative roadmap suggests implementing stage 2, which will break existing full nodes and light nodes, mid-2017 or later, and stage 3, which will fix the time warp attack, in 2018 to 2019. The second proposal is considered safer in terms of safety, but the first proposal is less disruptive. It is emphasized that it is the responsibility of miners, not developers, to confirm that the supermajority of the community accepts changes in stages 2 and 3.The proposed roadmap aims to improve the header format and block size over a 2-3 year period. The objectives include making multistage rule changes, making mining easier without breaking existing hardware and the Stratum protocol, and minimizing disruption during future hardforks. Stage 1, Segregated Witness (BIP141), will not break any existing full or light nodes. Stage 2 includes several fixes that will break existing full nodes but not light nodes, such as increasing the MAX_BLOCK_SIZE and adding anti-DoS rules for non-segwit scripts. Stage 3 involves changes that will break all existing full and light nodes, including changing the header format to Luke-Jr's proposal, reclaiming unused bits in the header for mining, and fixing the time warp attack.Both proposals have their pros and cons. The first proposal offers longer upgrade times for light nodes, opt-in stages for full and light nodes, and not following the minority chain during stage 2. However, it also has the drawback of non-upgraded nodes following the old chain during stages 2 and 3, which may result in lower value. The alternative roadmap presents pros such as opt-in stages for everyone and not following the minority chain during stage 2. However, it also has the downside of a longer implementation time for stage 2 and non-upgraded nodes following the old chain during stage 3.It is reiterated that miners have a responsibility to confirm that the supermajority of the community accepts changes in stages 2 and 3. The proposals by Matt Corallo and Luke-Jr are referenced for further information. diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-CPRKV-Check-private-key-verify.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-CPRKV-Check-private-key-verify.xml index acedbd963d..ae1416eca9 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-CPRKV-Check-private-key-verify.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-CPRKV-Check-private-key-verify.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP CPRKV: Check private key verify - 2025-09-26T15:41:09.381072+00:00 + 2025-10-11T21:52:25.208243+00:00 python-feedgen jl2012 at xbt.hk 2016-04-18 19:03:07+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - BIP CPRKV: Check private key verify - 2025-09-26T15:41:09.381208+00:00 + 2025-10-11T21:52:25.208417+00:00 2016-04-18T19:03:07+00:00 In a recent proposal on the bitcoin-dev mailing list, there was a suggestion to remove the OP_CHECKPRIVPUBPAIR opcode and replace it with OP_CAT and OP_CHECKSIGVERIFY. This proposal involves two parties, Bob and Alice, agreeing upon a random secret nonce, k, and calculating r in the same way as signing a transaction. The script consists of various operations such as SIZE, ADD, SWAP, CAT, CECHKSIGVERIFY, and CHECKSIG. This proposal is deemed useful for the lightning network. It is mentioned that a patch to the reference client may be coded up, but segregated witness is likely to take priority for soft-fork slot usage.On February 29th, 2016, Mats Jerratsch shared a link to a discussion on the bitcoin-dev mailing list from November 2015 regarding a Bitcoin Improvement Proposal (BIP) for Schnorr signatures. Jerratsch noted that this proposal is relevant to the Lightning Network and asked if there was a demand for coding up a patch to the reference client. However, it is also mentioned that segregated witness might be taking up any potential soft-fork slot.Another discussion on the bitcoin-dev mailing list revolves around the usefulness of a certain feature for the Lightning Network. This feature involves the creation of a non-standard script to execute a payment in an altcoin without requiring a new opcode. However, it is noted that this method will only work for coins that allow non-standard scripts, as it violates the standard output script assumption. There was initial focus on maintaining standard scripts on the altcoin, but the non-standard script approach is considered an improvement over the cut and choose method.In a previous email conversation on February 12, 2016, the possibility of creating a new opcode for an altcoin was discussed. However, it was later determined that the altcoin would only accept standard output scripts. As a result, the suggestion of paying to a non-standard script instead was considered an improvement over the previous method of cut and choose. It is mentioned that this approach would only work for coins that allow non-standard scripts. The focus then shifted to maintaining standard scripts on the altcoin.A new BIP draft proposed by Tier Nolan via the bitcoin-dev mailing list discusses using CLTV for cross-chain transfers. Many altcoins do not support CLTV, making the transfer insecure. Therefore, the proposed protocol doesn't require any new opcode and uses cut and choose to allow commitments to publish private keys. However, it is acknowledged that this protocol is clunky and not entirely secure. The proposed protocol involves four steps where Bob trades bitcoins for altcoins with Alice. The BIP CPRKV, Check Private Key Verify, allows outputs to be locked until a private key is published that matches a given public key. The BIP CPRKV is available on GitHub, and the email sender ensured the safety of their computer.The email conversation also explores the possibility of increasing the sigop count for a NOP without using segwit. It is determined that this would be a soft fork, as it makes previously allowed actions disallowed. The increased sigop count would be valid under both old and new rules, without requiring specific support on the altcoin. This allows the Bitcoin network to act as a trusted third party for safe use of channels on the altcoin, despite its malleability issues and lack of OP_CHECKLOCKTIMEVERIFY. In regards to seg-witness, the ideal scenario would be repurposing OP_NOP3 to work in both old and new scripts.Overall, these discussions among Bitcoin developers highlight various proposals and considerations regarding the use of CLTV for cross-chain transfers, the introduction of new opcodes, the improvement of scripting for the lightning network, and the potential impact on soft-fork slot usage. diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-Final-status.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-Final-status.xml index b20d3b501d..61ce087d7e 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-Final-status.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-Final-status.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Final status - 2025-09-26T15:41:15.725530+00:00 + 2025-10-11T21:52:31.575570+00:00 python-feedgen Luke Dashjr 2016-02-08 22:57:34+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - BIP Final status - 2025-09-26T15:41:15.725664+00:00 + 2025-10-11T21:52:31.575732+00:00 2016-02-08T22:57:34+00:00 On the bitcoin-dev mailing list, Peter Todd and Luke Dashjr engaged in a discussion about upgrading five Bitcoin Improvement Proposals (BIPs) from Draft to Final status. One of these BIPs, BIP 50, was specifically addressed by Peter Todd. He suggested that referring to the March 2013 Chain Fork described in BIP 50 as a "hard fork" oversimplifies the nuances of what occurred during that fork. However, he agreed that some rephrasing of BIP 50 could be beneficial. Peter Todd also noted that despite the issues with the pre-March protocol, the May 2013 change was undoubtedly a hard fork. The proposal for the upgrade is available on GitHub and requires the acknowledgment (ACK) of the BIP champions.Luke Dashjr proposed an upgrade to five additional BIPs on February 8, 2016, seeking their approval to transition from Draft to Final status. One of these BIPs is BIP 50, which focuses on the March 2013 Chain Fork Post-Mortem written by Gavin Andresen. During the discussion, it was suggested that describing this fork as a "hard fork" might not accurately capture the situation. The rejection of the chain by version 0.7 was non-deterministic and depended on observing a specific type of reorganization. Notably, a digital signature was attached to the email exchanged during this discussion.The Bitcoin Improvement Proposals (BIPs) are currently undergoing updates, including proposed changes to the status of several BIPs. These updates are being discussed on GitHub and encompass modifications such as elevating Accepted BIPs to Final status. The proposal has been open for a week and is expected to be merged within the next week, unless any objections arise. Additionally, another proposal aims to upgrade five more BIPs, transitioning them from Draft to Final status. The champions of these BIPs have been called upon to provide their acknowledgments (ACKs). The BIPs targeted for upgrade are the March 2013 Chain Fork Post-Mortem, Fixed Length "version" Message (Relay-Transactions Field), getutxo message, Strict DER signatures, and Use "Accept" header for response type negotiation with Payment Request URLs. diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml index 119cfa7b74..4954a1f866 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Process: Status, comments, and copyright licenses - 2025-09-26T15:41:19.954945+00:00 + 2025-10-11T21:52:35.829558+00:00 python-feedgen Mustafa Al-Bassam 2016-03-10 00:37:46+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - BIP Process: Status, comments, and copyright licenses - 2025-09-26T15:41:19.955125+00:00 + 2025-10-11T21:52:35.829737+00:00 2016-03-10T00:37:46+00:00 The Bitcoin Improvement Proposals (BIPs) are currently overseen by the mailing list, which could lead to centralized control. A proposal has been made to replace the mailing list with a "public discussion medium" such as forums or conferences. Luke Dashjr has created a draft BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concern about too much control being given to those who control the mailing list and wiki.Luke Dashjr suggested keeping reviews on the mailing list while using author-chosen forums in addition to the Bitcoin Wiki. Ryan Grant questioned the process for changing the status of a BIP from Draft to Active when rough consensus is reached on the mailing list. Luke explained that the wiki page is for leaving comments after discussion is over, and all review should remain on the mailing list. He also suggested that any forum used for review should have indisputable records of moderation and user edits.Luke Dashjr has made changes to BIP 2 to reduce hard feelings during comments. He proposed that a BIP author gather new/edited comment titles and report them once a week. Mediawiki offers watchlists for this purpose, and the wiki as a whole should be verifiable.A draft BIP by Luke Dashjr provides clarification on the Status field, expands allowable licenses, and adds public comments. Feedback on the draft is welcome. BIP99 aims to establish safe deployment requirements for an uncontroversial hardfork, but the concept of "adoption consensus" needs a neutral term. Suggestions are sought to make this clearer.Dave Scotese suggested that rules and code define Bitcoin, but consensus is needed after release. Gavin Andresen expressed concern about the definition of "consensus" giving too much control to the mailing list and wiki. Suggestions to make the meaning of "consensus" clear are welcomed.Jorge Timón suggested finding another term for "consensus" in the BIP document to avoid confusion. Luke-Jr agreed and proposed using "concord rules/code" instead of "consensus rules/code".Gavin Andresen expressed concern about the definition of "consensus" in the BIP process, giving too much control to the mailing list and wiki. He added a statement clarifying that the criteria for updating the status of BIPs should not be used to oppose or reject a BIP.The overuse of the term "consensus" in various contexts has caused confusion. Suggestions for alternative terms are welcomed. Luke-Jr suggested replacing it with "nearly universal acceptance" or "ecosystem-harmonious".Luke Dashjr and Dave Scotese discussed the need for coordination among multiple applications providing their own implementations of API/RPC and corresponding BIPs. They agreed that only one application would be standard to avoid confusion. The status of a BIP and comments should be unrelated metrics. The author of a BIP should be allowed to specify other internet locations for comments, but this could potentially be abused.Luke Dashjr proposed a draft BIP that provides clarity on the Status field, expands allowable licenses, and introduces public comments. Gavin Andresen expressed concerns about the definition of "consensus" giving too much control to the mailing list and wiki.Dave Scotese addressed the question of multiple applications providing their own implementations of API/RPC and corresponding BIPs. He stated that only one such application should be standard to avoid confusion. The status of a BIP and comments should not influence each other. The author of a BIP should be allowed to specify other internet locations for comments, although this could be potentially abused.Luke Dashjr requested objections to reach consensus on formally defining consensus. Clear reasoning must be given for objections not deemed substantiated by the community. Comments on BIPs should be solicited on the bitcoin-dev mailing list and summarized fairly in the wiki. Wiki registration and monitoring should not be a required hurdle to participation.Luke Dashjr completed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. Comments and status are unrelated metrics. The author of a BIP can specify other internet locations for comments.Luke Dashjr proposed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concerns about the definition of "consensus" giving too much centralized control.Dave Scotese stated that multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. The status of a BIP and comments should not directly influence each other. The author of a BIP should be allowed to specify other internet locations for comments. Clear reasoning must be offered for objections not deemed substantiated by the community.Luke Dashjr requested objections for consensus on formally defining consensus. Comments on BIPs should be solicited on diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-draft-Hard-fork-opt-in-mechanism-for-SPV-nodes.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-draft-Hard-fork-opt-in-mechanism-for-SPV-nodes.xml index e1aac1e401..1b320c639f 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-draft-Hard-fork-opt-in-mechanism-for-SPV-nodes.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-draft-Hard-fork-opt-in-mechanism-for-SPV-nodes.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP draft: Hard fork opt-in mechanism for SPV nodes - 2025-09-26T15:41:24.181406+00:00 + 2025-10-11T21:52:40.075957+00:00 python-feedgen Luke Dashjr 2016-02-05 23:25:14+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - BIP draft: Hard fork opt-in mechanism for SPV nodes - 2025-09-26T15:41:24.181573+00:00 + 2025-10-11T21:52:40.076103+00:00 2016-02-05T23:25:14+00:00 Johnson Lau proposed a new algorithm for the transaction commitment in block header to address the issue of Simplified Payment Verification (SPV) nodes automatically following a planned hard fork without explicit opt-in consent. This proposal aims to ensure that SPV nodes will not accept any incoming transactions on a new chain without being able to verify them with the new commitment format. The proposed Bitcoin Improvement Proposal (BIP) specifies using Double-SHA256(zero|merkle_root|zero) as the commitment instead of directly committing the Merkle root to the header. This change does not alter the header structure, allowing non-upgraded SPV nodes to still verify the proof-of-work of the new chain. However, they will not accept any transactions on the new chain until further actions are taken by their operators. Additionally, SPV nodes will not accept any new transactions on the old chain either, as it has less proof-of-work.This proposal acts as a supplement to the hardfork bit BIP, which informs full and SPV nodes about a planned hard fork. Lau's proposal ensures that SPV nodes will not lose any money in a hard fork, even if they do not check the hardfork bit. While this mechanism intentionally breaks backward compatibility, non-upgraded full nodes and SPV nodes can still verify the proof-of-work of upgraded blocks.To address potential fraudulent behavior during hard forks, a fraud-proof system is proposed. This system generates compact proofs to identify invalid blocks on the blockchain, which can be verified by SPV nodes. Hard forks without malicious intentions may also be considered as "fraud" among non-upgraded nodes. With this proposal, non-upgraded SPV nodes will always believe the new chain is valid but cannot be defrauded as they will not see any incoming transactions.The proposed BIP, authored by Johnson Lau, is currently in draft mode and available in the public domain. The compatibility of this proposal may need to be evaluated on a case-by-case basis, as changing the padding value may not always be necessary and could cause unnecessary disruption. diff --git a/static/bitcoin-dev/Feb_2016/combined_BIP-proposal-Increase-block-size-limit-to-2-megabytes.xml b/static/bitcoin-dev/Feb_2016/combined_BIP-proposal-Increase-block-size-limit-to-2-megabytes.xml index 148d195515..f50b658a65 100644 --- a/static/bitcoin-dev/Feb_2016/combined_BIP-proposal-Increase-block-size-limit-to-2-megabytes.xml +++ b/static/bitcoin-dev/Feb_2016/combined_BIP-proposal-Increase-block-size-limit-to-2-megabytes.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP proposal: Increase block size limit to 2 megabytes - 2025-09-26T15:40:56.709546+00:00 + 2025-10-11T21:52:12.439266+00:00 python-feedgen Tier Nolan 2016-02-10 12:58:01+00:00 @@ -169,10 +169,11 @@ + 2 Combined summary - BIP proposal: Increase block size limit to 2 megabytes - 2025-09-26T15:40:56.709763+00:00 + 2025-10-11T21:52:12.439522+00:00 2016-02-10T12:58:01+00:00 In a discussion on the bitcoin-dev mailing list, the potential risks and uncertainties of a proposed hard fork for Bitcoin were debated. The conversation focused on the possibility of a minority fork arising if the Classic hard fork was activated with 75% acceptance, as opposed to a complete switch over. Gavin Andresen argued that based on past soft-fork adoption by miners, there would be almost no hash power left on the weaker branch of the fork. However, others pointed out the uncertainty of the situation and the need for open, honest communication within the Bitcoin community. The discussion also touched on technical parameters such as the length of time given for development work and the likelihood of Bitcoin Core pursuing a minority fork. The email exchange highlighted the importance of addressing the potential risks and uncertainties associated with any changes to the Bitcoin protocol.The debate surrounding the threshold for a block size increase in Bitcoin revolved around whether to require 75% or 95% of miners to signal their support. There were concerns that a 75% threshold could give too much power to a single large miner or mining pool, while a 20% minority could still sabotage an upgrade by voting in favor of it and then refusing to mine on the new chain. Regardless of the threshold chosen, both chains would have equal difficulty in mining blocks during the adjustment period. If a fork does occur, one branch would have 2MB blocks every 18 minutes while the other would have 1MB blocks every 22 minutes. The former branch would be able to handle more transaction volume, resulting in a higher market value for newly minted coins and incentivizing miners to switch to the more profitable 2MB branch.The email exchange also discussed the potential risks and uncertainties associated with outdated nodes. If a node is not updated, it will eventually stop receiving new blocks and funds won't be confirmed. However, if someone decides to attack the node, they could receive confirmations for a large payment, leading users to believe it is irreversibly confirmed when it's actually part of a double-spend attack. If the node is on a weaker branch of a fork, it could take up to a week to get six confirmations. Full nodes are advised to upgrade their software, but lightweight nodes may not be aware of the issue. It is suggested that DNS seeds avoid reporting nodes significantly behind the rest of the network.In terms of implementation, Gavin Andresen proposed increasing the block size limit to 2,000,000 bytes with accurate sigop counting and a high limit on signature hashing. He suggested combining these limits into a single weighted sum formula as a solution. Constructive feedback was welcomed on his proposal.The email exchange also addressed security considerations for the proposed hard fork. There were discussions about testing the change, potential rollback plans in case of false voting triggering the hard fork, and monitoring and managing security through the hard fork. It was emphasized that the Bitcoin network is self-monitoring and self-managing, and various providers such as exchanges, libraries, wallets, and pools were conducting their own testing.Overall, the email exchange shed light on the potential risks and uncertainties associated with a hard fork in Bitcoin and the need for open communication and thorough consideration of security measures.In a series of email conversations and discussions on the bitcoin-dev mailing list, various aspects of the proposed hard fork to increase the block size limit in the Bitcoin network were addressed. Gavin Andresen, Luke Dashjr, Tom Zander, and others discussed issues such as security considerations, rollback plans, monitoring and managing security, SPV wallets compatibility, and economic support for the hard fork.Andresen suggested using version bits to trigger a soft-hard fork and emphasized the importance of considering security implications. He also mentioned that monitoring and management of the network would be done by services like statoshi.info, with miners and businesses playing their roles as well.The conversation also delved into the impact of nodes being kicked out of the network, with Zander explaining that old nodes would stop receiving new blocks and funds wouldn't get confirmed until the software is upgraded. Timón raised concerns about users unknowingly confirming fraudulent payments due to being lost from the network.There were discussions regarding the need for a capacity increase and the opinions of miners and the broader community. Dashjr disagreed with the claim of broad agreement and highlighted evidence to the contrary. The difference between SPV wallets and light clients was also debated, with suggestions for addressing both in the proposed hard fork.The controversy surrounding the 28-day grace period for implementing the upgrade was discussed, with differing views on the potential impact on users and the feasibility of longer grace periods. Andresen argued that there was no evidence to support the claim that 28 days is insufficient time.The article touched on the blog posts by Andresen, which discussed the constants chosen for the proposed hard fork and their potential impact on static analysis. Dashjr expressed concerns about these changes breaking static analysis and suggested alternative approaches.There were also discussions about economic support for the hard diff --git a/static/bitcoin-dev/Feb_2016/combined_Clearing-up-some-misconceptions-about-full-nodes.xml b/static/bitcoin-dev/Feb_2016/combined_Clearing-up-some-misconceptions-about-full-nodes.xml index f9ba9d95b9..92064b78b3 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Clearing-up-some-misconceptions-about-full-nodes.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Clearing-up-some-misconceptions-about-full-nodes.xml @@ -2,7 +2,7 @@ 2 Combined summary - Clearing up some misconceptions about full nodes - 2025-09-26T15:40:52.480472+00:00 + 2025-10-11T21:52:08.188277+00:00 python-feedgen Sean Greenslade 2016-02-13 06:20:06+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Clearing up some misconceptions about full nodes - 2025-09-26T15:40:52.480630+00:00 + 2025-10-11T21:52:08.188470+00:00 2016-02-13T06:20:06+00:00 In a discussion about running full nodes on desktop systems, Patrick Shirkey expressed concerns about the viability of running a full node on a system used for other purposes. He believes that bitcoin-qt consumes a lot of CPU/GPU resources, which can be problematic for users who need to share their system resources between normal desktop workload and running a full node. However, Sean challenged this statement by stating that when running a full node in non-mining mode, the CPU load is fairly light and the GPU is not used at all. Sean also mentioned that Bitcoin is tolerant of nodes entering and leaving the network at will, and even part-time nodes help improve the network's quality.Regarding the move to a 2MB hard fork, every node will need to upgrade. Planning the rollout effect of the hard fork on the entire bitcoin ecosystem is difficult, and relying solely on press releases to encourage users to upgrade their nodes is not viable. Sean emphasized the importance of learning from past experiences and not making hard forks on a whim.Running Bitcoin-qt on a spinning hard disk can cause system responsiveness issues and disrupt the user experience. However, moving the Bitcoin data to an SSD significantly improves the user experience. After initial synchronization, Bitcoin-qt only uses a small amount of CPU to verify new blocks and transactions. Running Bitcoin-qt continuously is less painful than running it occasionally. To run a full node on a small desktop machine, it is recommended to move the Bitcoin data off spinning media onto an SSD, have plenty of RAM, and leave bitcoin-qt running all the time.The number of full nodes worldwide is unknown because not all nodes have open ports that can be probed. While there are around 5,500 full nodes with open ports, there are likely several thousand more nodes with closed ports that cannot be measured. Full nodes play a crucial role in ensuring that all of Bitcoin's rules are being followed, making it trustless and secure. It is recommended to run a full node as a wallet for increased security and privacy. Running a full node as a wallet has become easier with improved user experience and efficiency.The rollout of the 2MB hard fork on the entire bitcoin ecosystem is a complex process that cannot rely solely on press releases to encourage users to upgrade their nodes. The Pulse Audio debacle during the mid-2000s serves as a lesson in this regard. However, enabling users to move their wallets to the new blockchain at their leisure does not cause instant degradation in the ecosystem. Bitcoin "brand" loyalty ensures that users who want to explore the economic potential of the 2MB blocksize can keep their existing funds safe while testing the waters with the new blocksize. Bitcoin remains the only game in town when it comes to scale and a proven history of financial return. As the new blockchain gains momentum, the old one will eventually become obsolete but may also serve as a useful and profitable alternative.A post by Chris Belcher on the bitcoin-dev mailing list debunks some myths about full nodes. The misconception that there are only around 5,500 full nodes worldwide stems from websites that measure open ports for probing. However, not all nodes have open ports, so the actual number is likely much higher. While open-port nodes are useful for measuring bandwidth capacity, closed-port nodes are equally important for trust, security, and privacy. Running a full node as a wallet is in an individual bitcoin user's rational self-interest because it ensures that none of Bitcoin's rules have been broken and increases security against possible attacks. Full node wallets are also the most private way to use Bitcoin, as no other parties learn which Bitcoin addresses belong to the user. To enjoy the benefits of running a full node, users should use it as their wallet on hardware they control. Using cloud servers is not recommended due to concerns about trust, security, and privacy. The user experience of full node software has significantly improved since 2012, and there are several ways to run a full node as a wallet, such as using bitcoin-qt, wallet software backed by a full node, or a lightweight wallet that only connects to the user's full node. diff --git a/static/bitcoin-dev/Feb_2016/combined_Fast-bootstrapping-with-a-pre-generated-UTXO-set-database.xml b/static/bitcoin-dev/Feb_2016/combined_Fast-bootstrapping-with-a-pre-generated-UTXO-set-database.xml index 89f1faf3d3..1f44834f3a 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Fast-bootstrapping-with-a-pre-generated-UTXO-set-database.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Fast-bootstrapping-with-a-pre-generated-UTXO-set-database.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fast bootstrapping with a pre-generated UTXO-set database - 2025-09-26T15:41:30.518311+00:00 + 2025-10-11T21:52:46.445672+00:00 python-feedgen Tier Nolan 2016-02-29 11:49:57+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Fast bootstrapping with a pre-generated UTXO-set database - 2025-09-26T15:41:30.518472+00:00 + 2025-10-11T21:52:46.445830+00:00 2016-02-29T11:49:57+00:00 One proposal to enhance the efficiency of bitcoin nodes suggests building the UTXO set in reverse, starting from the newest block and working backwards. The UTXO set consists of unspent transaction outputs (UTXOs) and unfunded transaction inputs (UFTXIs). The proposed procedure involves checking each transaction in a last-to-first order. For each output, it will be checked if it is part of the UFTXI set. If it is not, the signatures will be validated, and the output will be added to the UTXO set. Each input will be added to the UFTXI set. When a transaction is received, all its inputs will be checked. If they are in the UTXO set, the transaction will be marked as confirmed; otherwise, it will be marked as having "unknown inputs." Additionally, a counter will keep track of the number of blocks validated.Transactions with unfunded inputs will be considered validated back to the block they were included in, while transactions will be considered confirmed up to their ancestor with the newest validation time. A reference client can mark transactions with six or more output confirms and 1000 or more input confirms as confirmed. Once the genesis block is reached, all transactions will be marked as confirmed and the second number can be dropped.Another proposal aims to reduce node bootstrap time and network usage by loading a pre-generated UTXO-set datafile. To achieve this, full node clients like Bitcoin-core need to provide a feature that allows freezing the UTXO-set at a specified height and linearizing it in an unspecified data-serializing format. Along with this, a serialized form of the current chain-index up to the specified height will be appended to the pre-generated UTXO-set-datafile. This combined data will be hashed using double SHA256 and signed by a group of developers who sign deterministic builds.To ensure the integrity of developer pubkeys and signatures, methods like the current gitian build must be used. Full node client implementations supporting bootstrapping from a pre-generated UTXO-set should include trusted developer pubkeys, the hash (or hashes) of the pre-generated UTXO-set-datafile(s), and n signatures of the hash(es) from a subset of developers defined earlier.New nodes can download a copy of the pre-generated UTXO-set, verify its hash against the allowed UTXO-sets, and check the ECDSA signatures from various developers. If the user accepts the number of valid signatures, the node can continue bootstrapping from the specified height. Sharing of the pre-generated UTXO-set can be done through CDNs, BitTorrent, or other file hosting solutions. Additionally, it is possible to extend the bitcoin peer-to-peer layer with features to distribute and share such a pre-generated UTXO-set. diff --git a/static/bitcoin-dev/Feb_2016/combined_Hardfork-bit-BIP.xml b/static/bitcoin-dev/Feb_2016/combined_Hardfork-bit-BIP.xml index 3d31ccb96d..d69b0ea518 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Hardfork-bit-BIP.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Hardfork-bit-BIP.xml @@ -2,7 +2,7 @@ 2 Combined summary - Hardfork bit BIP - 2025-09-26T15:41:13.611509+00:00 + 2025-10-11T21:52:29.452062+00:00 python-feedgen Anthony Towns 2016-02-08 02:44:32+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - Hardfork bit BIP - 2025-09-26T15:41:13.611664+00:00 + 2025-10-11T21:52:29.452238+00:00 2016-02-08T02:44:32+00:00 The proposal aims to address the risks associated with hardforks in the Bitcoin blockchain. Hardforks are considered difficult and risky due to the need for support from miners and supermajority support from the Bitcoin economy. This level of support is not sufficient to safely introduce hardforks. Moreover, full nodes and Simplified Payment Verification (SPV) nodes following the original consensus rules may not be aware of a hardfork's deployment. This lack of awareness can lead users to unknowingly accept devalued legacy tokens and potentially revert back to the original chain if it grows faster than the new one.To mitigate these risks, the proposal suggests a change to the semantics of the sign bit in the "version" field of Bitcoin block headers. This change introduces an explicit "point of no return" in the blockchain. The mechanism involves using the sign bit in the nVersion field as the hardfork bit. Blocks with this header bit set to 1 would be considered invalid. For a planned hardfork, there must be one and only one flag block that serves as the "point of no return." This flag block is determined either by block height or as the first block with GetMedianTimePast() greater than a specified threshold.The construction of the flag block is crucial. Nodes adhering to the original consensus rules must reject it, while nodes following the new consensus rules must reject any block that is not a flag block when it should be. To avoid confusion and unexpected behavior, a flag block should indicate the deployment of only one hardfork. Additionally, a hardfork proposal must ensure that its flag block threshold does not clash with other ongoing hardfork proposals.When a flag block for an unknown hardfork is discovered on the network, full nodes and SPV nodes should alert their users and potentially cease accepting or sending transactions. The proposed mechanism is compatible with BIP9, which employs the version bits mechanism to gauge miner support for a hardfork proposal and determine the height or time threshold of the flag block.Once the flag block is generated, a miner can choose to support either the original rules or the new rules, but not both simultaneously. This mechanism aims to provide a clearer indication of hardfork deployments in the Bitcoin blockchain while reducing the associated risks. diff --git a/static/bitcoin-dev/Feb_2016/combined_INV-overhead-and-batched-INVs-to-reduce-full-node-traffic.xml b/static/bitcoin-dev/Feb_2016/combined_INV-overhead-and-batched-INVs-to-reduce-full-node-traffic.xml index dcddd09175..21982424dc 100644 --- a/static/bitcoin-dev/Feb_2016/combined_INV-overhead-and-batched-INVs-to-reduce-full-node-traffic.xml +++ b/static/bitcoin-dev/Feb_2016/combined_INV-overhead-and-batched-INVs-to-reduce-full-node-traffic.xml @@ -2,7 +2,7 @@ 2 Combined summary - INV overhead and batched INVs to reduce full node traffic - 2025-09-26T15:41:22.068303+00:00 + 2025-10-11T21:52:37.953805+00:00 python-feedgen Jonathan Toomim 2016-02-27 09:08:22+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - INV overhead and batched INVs to reduce full node traffic - 2025-09-26T15:41:22.068486+00:00 + 2025-10-11T21:52:37.953973+00:00 2016-02-27T09:08:22+00:00 One idea to reduce the size of transaction hashes is to use a 4 to 6 byte shorthash, which would have a low chance of resulting in collision with another transaction in a large mempool. To protect against potential attacks, different salt values can be set up for each connection and a salted hash can be used instead of the full thing. This technique could potentially reduce INV traffic by 5-8x in the asymptotic case, or maybe 2-3x for a realistic case. The additional memory overhead per peer per tx would be about 12 bytes, but it would save up to 28 bytes per peer*tx of network bandwidth.In an email exchange on Feb 25, 2016, Gregory Maxwell reported that the batching feature in versions 0.10 and 0.12 of a certain software was temporarily affected, but has since been fully functional again. This feature enables the ability to batch many transactions per INV effectively. The response was prompted by examination of 0.11-series versions which rarely send out INV batches. In this examination, it was noted that about 85% of the packets had a single hash.Jonathan Toomim, a Bitcoin developer, suggested implementing an option for batched INV (inventory) on the Bitcoin network that would increase efficiency by including the hashes for two transactions in one IP packet. This would increase the INV size to 229 bytes for 64 bytes of payload, resulting in an 88.8% marginal efficiency increase for each hash after the first.He believed waiting and accumulating several hashes together before sending as a batched INV could reduce Bitcoin node traffic by a factor of 2. However, this suggestion was found to have already been implemented since the early days of Bitcoin. The batching feature was temporarily affected between the 0.10 and 0.12 versions but has been fully functional again, with one INV now managing to batch many transactions effectively. The average batching size is about 5 seconds long and usually contains around 10 transactions per INV, as seen from debug measurements. While tweaking the system may improve efficiency, it is not expected to change the asymptotic efficiency of the network.The INV scheme used by Bitcoin is very inefficient due to the overheads of TCP, IP, ethernet and ACKs. Each INV takes up to 193 bytes, with only 16.5% efficiency for each of the payloads. An improvement could be the implementation of batched INVs where the hashes for two transactions per IP packet instead of one can be included. This would increase the INV size to 229 bytes for 64 bytes of payload (88.8% efficiency) after the first hash. Waiting a short period of time to accumulate several hashes together and send them could reduce the traffic of running bitcoin nodes by a factor of 2 or more. However, if too many people used it, it could slow down the propagation of transactions across the bitcoin network slightly. This could be mitigated by choosing a different batch size for each peer based on their preferences. diff --git a/static/bitcoin-dev/Feb_2016/combined_Multi-Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml b/static/bitcoin-dev/Feb_2016/combined_Multi-Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml index 2d1111407b..85d7161aab 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Multi-Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Multi-Stage-Merge-Mine-Headers-Hard-Fork-BIP.xml @@ -2,7 +2,7 @@ 2 Combined summary - Multi-Stage Merge-Mine Headers Hard-Fork BIP - 2025-09-26T15:41:17.837329+00:00 + 2025-10-11T21:52:33.706860+00:00 python-feedgen James Hilliard 2016-02-24 11:37:10+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Multi-Stage Merge-Mine Headers Hard-Fork BIP - 2025-09-26T15:41:17.837509+00:00 + 2025-10-11T21:52:33.707005+00:00 2016-02-24T11:37:10+00:00 A proposal for a hard fork has been made, suggesting a two-stage process with a single lock-in period to implement changes to the Bitcoin header format. The goal of this hard fork is to kill off the previous chain by artificially increasing the network difficulty on the original chain. The first stage of the hard fork is designed to make it difficult to mine the 2016 blocks needed to trigger a difficulty adjustment. This stage aims to make it clear to unupgraded clients that they need to upgrade. The second stage, called the headers change stage, makes the header format incompatible with merge mining. This stage is activated approximately 50,000 blocks after the Merge Mine Stage and at the start of the 2016 block difficulty boundary.There are serious issues with pooled mining, such as block withhold attacks, which can only be fixed by making major changes to the headers format. These desirable changes can only be made in a non-merge mine compatible way. If a way to permanently disable the original chain is not implemented, there is a high risk of there being two viable chains.To activate the fork, a block version flag will be used. This flag locks in both stages simultaneously when 3900 out of the previous 4032 blocks have the version flag set. The initial hard fork is implemented using a merge mine that requires the original pre-fork chain to be mined with a generation transaction that creates no new coins and does not contain any transactions. Additionally, a consensus rule requires manipulation of ntime on the original chain to artificially increase difficulty and hold back the original chain so that all non-upgraded clients can never catch up with current time. The artificial ntime is implemented as a consensus rule for blocks in the new chain.The proposal also mentions the possibility of an attack called the "nuclear option," which could potentially knock out the main chain. To prevent this, the median time past will increase very slowly, needing to increase by 1 every 6th block. This caps the update rate and gives an increase of 4X every doubling. The new headers will not meet the difficulty, so they will likely repeat the last header. If the bitcoin chain stays at a constant difficulty, each quadrupling will take more time. After 2 weeks, there will be a 4X difficulty increase (2 weeks per difficulty period), after 10 weeks, a 16X difficulty increase (8 weeks per difficulty period), and after 42 weeks, a 256X difficulty increase (32 weeks per difficulty period).It is important to note that the proposal is still in the draft stage, and a reference implementation has yet to be created. diff --git a/static/bitcoin-dev/Feb_2016/combined_On-Hardforks-in-the-Context-of-SegWit.xml b/static/bitcoin-dev/Feb_2016/combined_On-Hardforks-in-the-Context-of-SegWit.xml index 6929757306..ca2716a6ea 100644 --- a/static/bitcoin-dev/Feb_2016/combined_On-Hardforks-in-the-Context-of-SegWit.xml +++ b/static/bitcoin-dev/Feb_2016/combined_On-Hardforks-in-the-Context-of-SegWit.xml @@ -2,7 +2,7 @@ 2 Combined summary - On Hardforks in the Context of SegWit - 2025-09-26T15:41:26.295576+00:00 + 2025-10-11T21:52:42.199683+00:00 python-feedgen Anthony Towns 2016-02-10 05:16:56+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - On Hardforks in the Context of SegWit - 2025-09-26T15:41:26.295730+00:00 + 2025-10-11T21:52:42.199860+00:00 2016-02-10T05:16:56+00:00 Bitcoin developer Matt Corallo has proposed changes to increase the extranonce space in mining, which would allow for more transaction data in the blockchain. He suggests passing a mask of nonce bytes to ASICs and rearranging the block to include additional nonce space. However, these changes are incompatible with Luke-Jr's soft-hardfork approach. Corallo also recommends making merge-mining easier and splitting the proof of work between miners and pool operators to reduce hard forks visible to lightweight clients.The Bitcoin community is discussing increasing the extranonce space to simplify mining control and move complexity back into Bitcoin Core. The proposal includes adding nonce space in the first compression function and increasing the minimum difficulty. However, some believe this adds unnecessary complexity. These changes would enable greater ASIC speeds and increased dynamic extranonce space.In an email thread, Corallo proposes increasing the extranonce space available for ASICs by setting a maximum number of bytes. Changing the minimum difficulty to six 0-bytes would reserve more space for extranonce rolling. Luke agrees with the proposal and sees no reason not to increase the minimum difficulty at the same time.The discussion also explores potential changes to Bitcoin mining hardware to reduce required logic. Suggestions include allowing the first four bytes of the previous block hash field to contain any value, which could optimize brute forcing the SHA256 midstate. However, there are concerns about strong incentives to use the version field as nonce space. Another suggestion is using leading non-zero bytes of the prevhash as additional nonce. The author concludes that closer examination of midstate optimization is necessary.A hard fork proposal is being discussed in the context of segwit. The proposal includes changing the segregated witness discount from 75% to 50%, setting the block size limit to 1.5MB, and allowing for a maximum block size of 3MB with a "network-upgraded" block size of roughly 2.1MB. The aim is to decrease the worst-case scenario while keeping the total size in line with network capacity. The proposal also addresses cost and validation concerns by limiting non-segwit inputs and potentially implementing a per-transaction limit for MAX_BLOCK_SIGOPS. Additionally, it suggests allowing any value in the first four bytes of the previous block hash field to make hardware production more competitive.To prevent significant cost blowups in transaction validation, there are restrictions on non-segwit inputs. However, this move has raised concerns about disrupting services and invalidating time-locked transactions. Other limitations, such as scriptPubKeys being limited to 100 bytes and no OP_CODESEPARATOR allowed, have also raised concerns regarding native multisig.In another email thread, Corallo proposes a hard fork outline in the context of segwit. The segregated witness discount would be changed from 75% to 50%, and the block size limit set to 1.5MB. This would result in a maximum block size of 3MB and a "network-upgraded" block size of roughly 2.1MB. Additional limits would be placed on the size of non-segwit transactions, and the first four bytes of the previous block hash field could contain any value. The proposal aims to balance efficient block space usage, low fees, and network security.The author argues that Bitcoin scaling is not an emergency and highlights mining centralization and privacy as more pressing concerns. They suggest a hard fork could be used to enforce decentralized mining pools and express concern about rising transaction fees. They provide links for further information on what constitutes a qualifying emergency and suggestions for addressing mining centralization.In a separate discussion, Simon Liu questions the rationale for offering a discount from segregated witness. Peter Todd responds that UTXO set space is more expensive for the network, leading to the discount. He emphasizes the need to consider engineering decisions and proposes a miner vote threshold for hard forks.The segregated witness discount has been changed from 75% to 50%, and the block size limit set at 1.5MB, resulting in a maximum block size of 3MB. The purpose is to offer a discount on script data while maintaining a limited maximum block size. The rationale for the discount and specific boundary limits are unclear. These changes aim to balance efficient block space usage, low fees, and network security.Bitcoin developers are discussing a hard fork to address mining centralization and privacy challenges. Hard forks should only occur in response to a major crisis agreed upon by all participants. The community has unified around roughly 2MB of transactions per block via Segregated Witness or a hard fork. Technical planning is crucial to avoid risks and protect value. Suggestions include adding decentralization pressure and switching MAX_BLOCK_SIGOPS to a per-transaction limit. Hard forks must address real threats facing Bitcoin.The Bitcoin community has unified around roughly 2MB of transactions per block via Segregated Witness or a hard fork. Implementing SegWit and planning for a safe hard fork is essential. Proposed changes include changing the segregated witness diff --git a/static/bitcoin-dev/Feb_2016/combined_Pre-BIP-Growth-Soft-hardfork.xml b/static/bitcoin-dev/Feb_2016/combined_Pre-BIP-Growth-Soft-hardfork.xml index afc6e65ae6..5b69b90e5b 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Pre-BIP-Growth-Soft-hardfork.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Pre-BIP-Growth-Soft-hardfork.xml @@ -2,7 +2,7 @@ 2 Combined summary - Pre-BIP Growth Soft-hardfork - 2025-09-26T15:41:03.045567+00:00 + 2025-10-11T21:52:18.830248+00:00 python-feedgen jl2012 at xbt.hk 2016-02-07 17:53:53+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Pre-BIP Growth Soft-hardfork - 2025-09-26T15:41:03.045717+00:00 + 2025-10-11T21:52:18.830448+00:00 2016-02-07T17:53:53+00:00 Luke Dashjr has shared a draft BIP for the Pre-BIP Growth Soft-hardfork. This BIP aims to implement proper merge-mining, as suggested by Satoshi, in order to expand the nonce space that miners can scan in-chip. It also proposes a method for safely deploying hardforks without leaving old nodes vulnerable to attack. Although the initial implementation of the BIP may be challenging, it will facilitate future hardforks.The proposal suggests including the median timestamp of the past 11 blocks after the block height in coinbase, which would serve as an activation threshold for consensus rule changes. Additionally, the BIP recommends treating witness commitment as a merge mined commitment. Miners are encouraged to ensure that the hardfork is accepted by the supermajority of the economy.The email accompanying the draft BIP discusses a specific implementation of the "nuclear option" soft fork. This involves adding fields to header 3 that can be expanded later, saving the need to immediately convert the merkle tree into a sum tree. The proposal also suggests having dedicated hard fork and soft fork counters, as well as a field for parallel soft forks. In response to hard forks, nodes would stall the chain, and the hard fork counter would determine if this action should be taken for all new hard forks going forward. If a hard fork occurs, transaction processing would be halted, and users informed. Non-upgraded miners could blacklist the hard forking block and continue mining on their own chain, while still giving users the option to accept or reject the hard fork.The author of the BIP wrote a draft a year ago, which aimed to achieve important objectives such as merge-mining, nonce space expansion, and safe deployment of hardforks. The author plans to revise and complete the BIP soon and welcomes suggestions for improvement. The link to the BIP can be found on GitHub. diff --git a/static/bitcoin-dev/Feb_2016/combined_Question-regarding-Confidential-Transactions.xml b/static/bitcoin-dev/Feb_2016/combined_Question-regarding-Confidential-Transactions.xml index 93b6e5bf4f..44ac8861b6 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Question-regarding-Confidential-Transactions.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Question-regarding-Confidential-Transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - Question regarding Confidential Transactions - 2025-09-26T15:41:05.159068+00:00 + 2025-10-11T21:52:20.953723+00:00 python-feedgen Adam Gibson 2016-02-13 16:55:31+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Question regarding Confidential Transactions - 2025-09-26T15:41:05.159202+00:00 + 2025-10-11T21:52:20.953894+00:00 2016-02-13T16:55:31+00:00 In an email conversation between Henning Kopp and Jeremy Papp, they discuss the inclusion of the blinding factor in range proofs for confidential transactions. They explore various possibilities, such as encrypting the blinding factor with the receiver's public key or using shared secret generation. They note that ECC works differently from RSA, and instead of directly encrypting with a public key, a shared secret is generated using ECDH. Adding extraneous data is not a major issue since it would likely require segwit. However, it is important to consider that the sender would need to know the recipient's unhashed public key, which is not commonly used in Bitcoin transactions due to potential vulnerabilities to quantum computers. The conversation delves into technical aspects of blinding factors and shared secrets in Bitcoin transactions.The discussion continues in an email exchange where Jeremy suggests including the blinding factor in the extra data incorporated into the ring signatures used in the range proof. He considers the range proof optional for single output transactions, as there is only one possible value that can work. However, he is uncertain about how to transmit the blinding factor. Both Jeremy and Henning agree that adding extraneous data is not a significant concern, given that its usage would likely require segwit. They also envision protecting the blinding factor from outside examination through some form of shared secret generation. However, this approach necessitates the sender knowing the recipient's unhashed public key, which differs from the usual practice in Bitcoin transactions. Henning raises a question about how the receiver can verify the amount sent to them and suggests that the receiver needs to learn the blinding factor to reveal the commit off-chain. Henning is associated with Ulm University in Germany.In response to a user's query on Bitcoin development, the responder explains that the blinding factor would be included in the extra data embedded in the ring signatures used in the range proof for confidential transactions. They highlight that the range proof is optional for single output transactions and would require segwit if utilized. Adding extraneous data is not a significant concern in this context. The responder suggests that the blinding factor would likely be safeguarded from external scrutiny through shared secret generation. However, this would entail the sender knowing the recipient's unhashed public key, which deviates from the common practice of using hashed keys. The responder expresses uncertainty about any shared secret schemes applicable to hashed keys.Henning Kopp, a researcher at Ulm University in Germany, seeks clarification on confidential transactions. He raises a question regarding how the receiver can verify the amount sent to them when the sender creates a confidential transaction and accurately selects the blinding values. While anyone can still confirm the validity of the transaction as it remains publicly verifiable, Henning believes that the receiver needs to learn the blinding factor to reveal the commit off-chain. However, he requests further explanation regarding the process. diff --git a/static/bitcoin-dev/Feb_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml b/static/bitcoin-dev/Feb_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml index 05e1bc1300..65b21fe85c 100644 --- a/static/bitcoin-dev/Feb_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml +++ b/static/bitcoin-dev/Feb_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - RFC for BIP: Best Practices for Heterogeneous Input Script Transactions - 2025-09-26T15:41:07.271107+00:00 + 2025-10-11T21:52:23.083520+00:00 python-feedgen Luke Dashjr 2016-05-26 00:00:37+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - RFC for BIP: Best Practices for Heterogeneous Input Script Transactions - 2025-09-26T15:41:07.271297+00:00 + 2025-10-11T21:52:23.083679+00:00 2016-05-26T00:00:37+00:00 On May 19, 2016, Kristov Atlas introduced a Bitcoin Improvement Proposal (BIP) known as BIP 126. This proposal suggests the implementation of Heterogenous Input Script Transactions (HITs), which allow for transactions to have multiple inputs with different scripts. It is important to note that transactions are not associated with specific Bitcoin addresses, but rather with inputs that spend from Unspent Transaction Outputs (UTXOs). Furthermore, it is uncommon for inputs to have identical scripts.The draft proposal titled "Best Practices for Heterogeneous Input Script Transactions (HITs)" aims to mitigate the negative impact on privacy and user protection protocols when transactions involve inputs with different scripts. The document outlines a set of guidelines to address the privacy concerns associated with HITs, while maximizing the effectiveness of user protection protocols. To achieve this, the specification proposes two forms of HITs: Standard form and alternate form.Standard form HIT transactions must adhere to specific rules. These rules include having an equal number of unique input/output scripts, ensuring all output scripts are unique, requiring at least one pair of outputs with equal value, and making sure the largest output in the transaction belongs to a set containing at least two identically-sized outputs. These requirements serve various purposes such as preventing address reuse, limiting the growth of the UTXO set, and optimizing behavior to make intentional HITs resemble unavoidable HITs.In cases where standard form HITs are not feasible, such as when HITs are unavoidable or the user does not possess sets of UTXOs with identical scripts, alternate form HITs can be employed. A compliant implementation can construct a transaction by finding the smallest combination of inputs whose value is equal to or greater than the desired spend. These inputs are then added to the transaction along with a spend output and change output. The process is repeated to create a second spend output and change output, with the change outputs adjusted as necessary to cover the transaction fee. The aim of this approach is to maximize the effectiveness of user-protecting protocols, minimize the adverse consequences of unavoidable HITs, and limit the impact on UTXO set growth.Non-compliant heterogenous input script transactions may be created if a user wishes to create an output larger than half the total size of their spendable outputs or if their inputs are not distributed in a manner that allows for the completion of the alternate form procedure.In conclusion, this document proposes a set of best practice guidelines to minimize the adverse privacy consequences of creating transactions with inputs composed of different scripts. The guidelines aim to maximize the effectiveness of protection protocols, minimize the negative consequences of unavoidable HITs, and limit the effect on the UTXO set growth. It defines terms related to HITs and provides rules for both standard form and alternate form HITs. The recommendations aim to enhance privacy and optimize the usage of HITs while ensuring compliance with the proposed guidelines. diff --git a/static/bitcoin-dev/Feb_2016/combined_SIGHASH-NOINPUT-in-Segregated-Witness.xml b/static/bitcoin-dev/Feb_2016/combined_SIGHASH-NOINPUT-in-Segregated-Witness.xml index c7bd53cd6b..e84faaa450 100644 --- a/static/bitcoin-dev/Feb_2016/combined_SIGHASH-NOINPUT-in-Segregated-Witness.xml +++ b/static/bitcoin-dev/Feb_2016/combined_SIGHASH-NOINPUT-in-Segregated-Witness.xml @@ -2,7 +2,7 @@ 2 Combined summary - SIGHASH_NOINPUT in Segregated Witness - 2025-09-26T15:41:00.931900+00:00 + 2025-10-11T21:52:16.707062+00:00 python-feedgen Rusty Russell 2016-02-29 00:25:53+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - SIGHASH_NOINPUT in Segregated Witness - 2025-09-26T15:41:00.932055+00:00 + 2025-10-11T21:52:16.707224+00:00 2016-02-29T00:25:53+00:00 In a discussion on the Bitcoin-dev mailing list, developers are considering a new feature that would allow for outsourced monitoring of Lightning network channels. This feature would involve three transactions: an anchor transaction, a commitment transaction, and a penalty transaction. The commitment transaction includes multiple payments and HTLCs to different parties, while the penalty transaction enables one party to take 99% of the commitment transaction's value in case of foul play. However, outsourcing the monitoring of these channels would require sending a lot of data to the chain-monitoring service.To address this issue, Joseph Poon proposed the use of a SIGHASH flag called SIGHASH_NOINPUT. This flag would allow for the inclusion of the spent outpoint's script as part of the signature, without including the outpoint being spent or the amount. This proposed flag would make it possible to write fully malleability-proof wallet software. However, Poon emphasized that the flag should only be used in SegWit transactions, as SegWit provides sufficient malleability solutions. Implementing the flag in pre-SegWit transactions would complicate matters unnecessarily.The topic of SIGHASH flags was further discussed in an email conversation between Bryan Bishop and Joseph Poon. Bryan suggested considering other types of SIGHASH flags while drafting a BIP for the new flag. Poon agreed to review those proposals and expressed interest in hearing about other sighash flags if there were clear use cases for them. However, he also mentioned concerns about replay attacks when using SIGHASH_NOINPUT, stating that SegWit resolves malleability without worrying about such attacks.Another email chain between Gregory Maxwell and Joseph Poon focused on implementing a new SegWit script type that would include fees as part of the signature. This would prevent wallets from having to download input transactions and reduce the risk of users being exposed to replay attacks. They suggested naming the new flag SIGHASH_REPLAY_VULNERABLE to emphasize its importance.Poon also discussed the idea of adding a "without-inputs SIGHASH flag" to make it easier to create transactions that spend from the same inputs as other transactions. However, he warned about the potential for replay attacks and suggested deploying a fee-committing sighash-all option to protect users.In summary, developers are considering adding new SIGHASH flags to enhance the functionality and security of SegWit transactions. These flags would allow for outsourced monitoring of Lightning network channels, prevent the need to download input transactions, and protect against replay attacks. The design of SegWit was carefully crafted to allow for safe soft-forks for future script enhancements, and developers are cautious about making unnecessary changes beyond what is necessary for a safe deployment of SegWit. diff --git a/static/bitcoin-dev/Feb_2016/combined_SegWit-GBT-updates.xml b/static/bitcoin-dev/Feb_2016/combined_SegWit-GBT-updates.xml index 067c674f32..a718b81f81 100644 --- a/static/bitcoin-dev/Feb_2016/combined_SegWit-GBT-updates.xml +++ b/static/bitcoin-dev/Feb_2016/combined_SegWit-GBT-updates.xml @@ -2,7 +2,7 @@ 2 Combined summary - SegWit GBT updates - 2025-09-26T15:40:54.592047+00:00 + 2025-10-11T21:52:10.316387+00:00 python-feedgen Luke Dashjr 2016-02-02 02:30:55+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - SegWit GBT updates - 2025-09-26T15:40:54.592179+00:00 + 2025-10-11T21:52:10.316558+00:00 2016-02-02T02:30:55+00:00 The discussion revolves around the inclusion of the "default_witness_commitment" in the standard protocol. One argument against including it is that it may lead to centralization of mining pools and make server-side implementation more susceptible to DoS attacks. However, there is also an argument for including it to simplify initial adoption and have a known-correct value to use. It is mentioned that libblkmaker can handle the heavy lifting for mining software. Ultimately, the decision to include or exclude "default_witness_commitment" depends on the specific implementation and goals.In the email exchange between Luke Dashjr and Cory Fields, they discuss the default witness commitment for GBT (GetBlockTemplate) protocol. Dashjr argues that including it could enable centralization, while Fields suggests that providing a known-working commitment would be beneficial for adoption. Dashjr expresses concerns about security and suggests leaving out the default witness commitment from the standard protocol. Fields seeks clarification on potential DoS vectors and the use of libblkmaker. Dashjr reassures that the burden on mining software is not significant and that libblkmaker can handle the heavy lifting. He also mentions the need to consider the sign bit when serializing heights and the risk of introducing bugs into working code.The conversation on February 1, 2016, between Cory Fields and Luke Dashjr delves into the use of "default_witness_commitment" within the GBT protocol. Dashjr argues against including it in the standard protocol, as it contradicts GBT's design principles by enabling and encouraging centralization. Fields raises the point that providing a known-working commitment can simplify the process. Dashjr acknowledges this but emphasizes the potential for bugs. They also discuss a bug introduced by ckpool, where a positive number was serialized as a signed one.Another discussion between Luke Dashjr and Cory Fields focuses on the omission of the "default_witness_commitment" key in the Bitcoin protocol. Fields believes that omitting it would encourage pools to build their own commitment, while Dashjr argues that it could increase vulnerability to DoS attacks. Dashjr suggests leaving it as a bitcoind-specific extension to promote adoption but recommends keeping it out of the standard protocol for now. Fields expresses concerns about the burden on mining software and the risk of bugs, but Dashjr highlights the capability of libblkmaker to handle the heavy lifting. Fields mentions fixing serialization or commitment creation bugs in mining/pool software.The email conversation discusses the absence of the "default_witness_commitment" key in the current reference implementation. The omission allows clients to create the commitment themselves instead of having it provided. However, this simplicity can encourage laziness and complicate server-side implementation, making it more vulnerable to DoS attacks. The burden on mining software increases, raising the odds of bugs. It is mentioned that serialization or commitment creation bugs related to mining/pool software have already been fixed in SegWit.Luke Dashjr has drafted a BIP for updating getblocktemplate for segregated witness. The draft does not include the "default_witness_commitment" key present in the current reference implementation. This omission allows clients to create their commitment instead of relying on provided values. However, excluding the key increases the burden on mining software and the likelihood of bugs. Cory supports this argument and plans to submit the change to the BIP, enabling mining software to handle more serialization and complex structure calculations. Links to related sources are provided.Luke-jr has announced the creation of an initial draft for a BIP regarding getblocktemplate for segregated witness. The draft is available on GitHub, and Luke-jr invites others to review and comment on the changes made, particularly with regard to sigoplimits handling. However, he notes that libblkmaker's reference implementation is currently incompatible with the "last output" rule in this BIP. Luke-jr expresses gratitude in advance for any feedback received. diff --git a/static/bitcoin-dev/Feb_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml b/static/bitcoin-dev/Feb_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml index 2ec7f4a660..47b48226ed 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml @@ -2,7 +2,7 @@ 2 Combined summary - Segwit Upgrade Procedures & Block Extension Data - 2025-09-26T15:40:58.820504+00:00 + 2025-10-11T21:52:14.571668+00:00 python-feedgen Tier Nolan 2016-02-01 19:29:32+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Segwit Upgrade Procedures & Block Extension Data - 2025-09-26T15:40:58.820678+00:00 + 2025-10-11T21:52:14.571870+00:00 2016-02-01T19:29:32+00:00 On February 1, 2016, Pieter Wuille proposed a second number push in the coinbase scriptSig, which would point to a 32-byte hash H. This push was accepted as it provided a more flexible and compact system than the current one. Concerns were raised about adding arbitrary data, so it was suggested that the data in the coinbase witness stack have a fixed number of entries depending on the block version number. This would allow for soft-forks to add new entries in the stack.Peter Todd discussed upgrade procedures related to segregated witnesses, suggesting the addition of a new service bit or bumping the protocol version. However, this solution did not address the issue of relaying more block data in the future, requiring another soft-fork upgrade. To solve this problem, Todd proposed making the witness data more extensible by using unvalidated block extension data. This involved a backward-incompatible change to the current segwit change, where the coinbase scriptSig would receive a second number push pointing to a 32-byte hash H. Todd also addressed concerns about miners using arbitrary data by suggesting a merkelized key:value mapping with collision-resistant IDs as keys.Pieter Wuille's segwit branch was discussed on the Bitcoin developers mailing list. It was suggested to add a new service bit or bump up the protocol version to only connect to peers with segwit support. The branch had a fHaveWitness flag for each connection, but BIP144 proposed changing this to a service bit. A pull request to change this to a NODE_WITNESS service bit has been made on GitHub.Peter Todd suggested adding a new service bit, NODE_SEGWIT, and/or bumping the protocol version to ensure outgoing peers only connect to peers with segwit support. He also proposed solutions for future upgrades adding new block data, such as removing the restriction on the coinbase witness containing exactly one 32-byte value. Another proposal involved hashing the contents of the coinbase witness as a merkle tree and committing them in place of the current nonce commitment. These proposals were discussed in a pull request on the segwit branch, including the idea of including the merkle path to the segwit data in the coinbase witness.The deployment of segregated witness poses a problem as nodes need witness data to function after activation. If full node adoption lags behind miner adoption, the segwit-supporting P2P network may partition and lose consensus. The issue is not yet fixed in Pieter Wuille's segwit branch, but one solution is to add a new service bit or bump the protocol version to only connect to peers with segwit support. However, if full node operators do not widely adopt segwit, the network could become more vulnerable. Future upgrades will require the relay network to upgrade, and BIP141 suggests an Extensible Commitment Structure to address this. This structure consists of a hashed linked list of consensus-critical commitments, with a redefinable nonce for future soft-forks. To allow for additional data in future soft-forks, the proposal is to remove the restriction on the coinbase witness, hash its contents as a merkle tree, and include that data in the blocksize limit. This allows all nodes to validate the data came from the miner and propagate it without risk of attack. This method is efficient as most future upgrades are expected to be additional commitments, and the additional data for each commitment is just 32 bytes. diff --git a/static/bitcoin-dev/Feb_2016/combined_Soft-fork-fix-for-block-withholding-attacks.xml b/static/bitcoin-dev/Feb_2016/combined_Soft-fork-fix-for-block-withholding-attacks.xml index 6b7faf63fb..563bc85407 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Soft-fork-fix-for-block-withholding-attacks.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Soft-fork-fix-for-block-withholding-attacks.xml @@ -2,7 +2,7 @@ 2 Combined summary - Soft fork fix for block withholding attacks - 2025-09-26T15:41:11.497034+00:00 + 2025-10-11T21:52:27.330032+00:00 python-feedgen Tier Nolan 2016-02-12 16:09:01+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Soft fork fix for block withholding attacks - 2025-09-26T15:41:11.497190+00:00 + 2025-10-11T21:52:27.330192+00:00 2016-02-12T16:09:01+00:00 The context explores the idea of designing clients to warn users about soft forks and the potential safety advantages of doing so. While the reference client can provide warnings for high Proof-of-Work (POW) soft forks, many Simplified Payment Verification (SPV) clients cannot. To address this, it is suggested to implement a delay between version number changes and rule activation. This would allow nodes to receive a warning urging them to update their software.Furthermore, the context proposes specific guidelines for increasing difficulty intervals and updating targets at each difficulty re-targetting. The aim is to eventually reach a target of zero after 64 weeks, resulting in a difficulty level that is 256 times higher than the header. By implementing these guidelines, the hope is to enhance the security and stability of the network.Additionally, the context highlights an important point about the vulnerability of block withholding attacks. A proposal to fix this issue with a soft fork was presented, but it was noted that the technique does not align with the standard definition of a soft fork used by the Bitcoin development and research community. The proposed approach may be termed a "pseudo-soft-fork" and requires further analysis to determine its effectiveness compared to a simpler hard-fork implementation.To tackle block withholding attacks, another solution is put forth in the context. This solution involves redefining the block Proof-of-Work (PoW) target to be less than the difficulty, with the last two bytes representing the target. Miners are required to include a blinded hash of the target along with additional data in the coinbase of the blocks. Importantly, miners cannot switch targets arbitrarily and must submit all shares that meet the PoW criteria. Secondary verification is delegated to the miner, who must communicate proof of their target hash in a non-hashed area of the block.This proposed solution can be deployed as a soft fork with miner opt-in triggering across multiple difficulty cycles. Initially, the last bit of the block hash must be zero, followed by the last two bits in the next cycle. This progression continues over 16 difficulty cycles to minimize significant increases in block timings. By the end of this process, the nominal difficulty would have been reduced by a factor of 2^16 (65536), while the block target makes mining each block significantly harder.The context concludes by mentioning the possibility of progressing over more difficulty cycles through clever soft fork rules, such as Vitalik's "timewalking" attacks that allow for effective granular lowering of the nominal difficulty. Critiques are welcomed regarding these proposals, demonstrating an openness to further improvements and refinements in the Bitcoin network's security and performance. diff --git a/static/bitcoin-dev/Feb_2016/combined_The-first-successful-Zero-Knowledge-Contingent-Payment.xml b/static/bitcoin-dev/Feb_2016/combined_The-first-successful-Zero-Knowledge-Contingent-Payment.xml index ab532a83dc..c89685e35d 100644 --- a/static/bitcoin-dev/Feb_2016/combined_The-first-successful-Zero-Knowledge-Contingent-Payment.xml +++ b/static/bitcoin-dev/Feb_2016/combined_The-first-successful-Zero-Knowledge-Contingent-Payment.xml @@ -2,7 +2,7 @@ 2 Combined summary - The first successful Zero-Knowledge Contingent Payment - 2025-09-26T15:40:46.136510+00:00 + 2025-10-11T21:52:01.816301+00:00 python-feedgen Tier Nolan 2016-02-26 23:56:58+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - The first successful Zero-Knowledge Contingent Payment - 2025-09-26T15:40:46.136679+00:00 + 2025-10-11T21:52:01.816524+00:00 2016-02-26T23:56:58+00:00 In February 2016, Gregory Maxwell proposed a scheme to reveal a private key in Bitcoin through a single-show-signature approach. This scheme was previously developed by Maxwell and discussed on the lightning-dev mailing list. Tier Nolan also inquired about atomic cross-chain transfers between Bitcoin and legacy altcoins, which are outdated coins with strict IsStandard() rules and no advanced script opcodes. Nolan suggested using the single-show-signature scheme he created on the Bitcoin side instead of performing an EC multiply. Discussions have been ongoing regarding atomic cross-chain transfers between Bitcoin and legacy altcoins. A legacy altcoin is defined as one with strict IsStandard() rules and lacking advanced script opcodes. To transfer funds, Bob must prove that he has a private key that matches his public key. This can be achieved through a cut-and-choose scheme that uses a fee to ensure attackers lose money on average. However, this scheme is vulnerable to attackers who don't mind losing money as long as the target loses money too. The feasibility of using an elliptic curve multiply for this scheme is questioned. The discussion took place on the Bitcoin-dev mailing list.Gregory Maxwell successfully demonstrated a Zero-Knowledge Contingent Payment (ZKCP) transaction protocol on the Bitcoin network. This protocol allows a buyer to purchase information from a seller using Bitcoin in a private, scalable, and secure manner without relying on trust or third-party arbitration. The buyer receives the expected information only if the payment is made. ZKCP eliminates significant transactional costs and risks associated with irreversible sales across multiple jurisdictions. In a live demonstration, Gregory purchased a 16x16 Sudoku puzzle solution for 0.10 BTC from Sean Bowe of the Zcash team at Financial Cryptography 2016 in Barbados. The transfer involved two transactions, and most of the engineering work behind the ZKCP implementation was done by Sean Bowe, with support from Pieter Wuille, Gregory Maxwell, and Madars Virza.The first successful Zero-Knowledge Contingent Payment (ZKCP) on the Bitcoin network has been announced. ZKCP enables buyers to purchase information from sellers in a private, scalable, and secure manner without relying on trust or third-party arbitration. The payment is only made if the expected information is transferred. This eliminates transactional costs and risks associated with irreversible sales across multiple jurisdictions. In a demonstration, Gregory purchased a 16x16 Sudoku puzzle solution for 0.10 BTC from Sean Bowe of the Zcash team. The transfer involved two transactions, and most of the engineering work was done by Sean Bowe, with support from Pieter Wuille, Gregory Maxwell, and Madars Virza. More technical details about ZKCP can be found at the provided link. The buyer also plans to launch a ZKCP sudoku buying faucet soon. diff --git a/static/bitcoin-dev/Feb_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml b/static/bitcoin-dev/Feb_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml index 89a992a60c..0799394fb2 100644 --- a/static/bitcoin-dev/Feb_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml +++ b/static/bitcoin-dev/Feb_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml @@ -2,7 +2,7 @@ 2 Combined summary - Three Month bitcoin-dev Moderation Review - 2025-09-26T15:40:50.365567+00:00 + 2025-10-11T21:52:06.065235+00:00 python-feedgen David Vorick 2016-02-09 23:24:28+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - Three Month bitcoin-dev Moderation Review - 2025-09-26T15:40:50.365743+00:00 + 2025-10-11T21:52:06.065440+00:00 2016-02-09T23:24:28+00:00 The Bitcoin-dev mailing list recently discussed the importance of providing unique and valuable contributions to conversations. Contributors emphasized that comments should contribute to the discussion with technical details or additional relevant data, rather than simply stating agreement with a proposal. The sentiment expressed was that evidence trumps votes, and comments should provide readers with another thing to consider in favor of something beyond just the number of people who support it.In this context, various members of the mailing list shared their opinions. Dave Scotese suggested that contributors should provide additional evidence in favor of something, while Gavin offered his services as a techie and shared information about his projects Litmocracy and Meme Racing. Peter Todd and another member stressed that comments should contribute uniquely to the discussion and not simply repeat what has already been said. They proposed using a "+1" vote with an explanation that provides unique insights to the conversation.Another member, Xor, suggested allowing "+1" votes as long as a technical explanation is provided for why the person agrees. However, Peter Todd disagreed, stating that the explanation should also contribute uniquely to the conversation. Rusty Russell expressed his view that "+1s" on a list are not useful unless they carry additional information. He recommended amending the rules to clarify that "+1s" are not allowed without an explanation.In addition to discussing comments, the mailing list also addressed other issues. Dave Scotese expressed disappointment at the difficulty in accessing moderated messages and suggested having a downloadable version of these messages on the ozlabs website. Rusty Russell explained that the difficulty arises because the messages are forwarded to the bitcoin-dev-moderation mailing list, which strips them out as attachments. Rusty called for volunteers to help develop a filter to address this issue.Furthermore, Rusty Russell raised the question of what moderation should look like going forward. Xor pointed out that the original announcement of moderation had discouraged the use of "+1s" without additional information. Rusty clarified that statements like "I prefer proposal X over Y because..." or "I dislike X because..." carry more weight than simply saying "+1." The discussion highlighted the need for moderation to be information-rich and not solely focused on managing a process of indicating agreement or disagreement.Overall, the Bitcoin-dev mailing list engaged in a thoughtful discussion about the value of comments, the importance of providing unique contributions, and potential improvements to the moderation system. diff --git a/static/bitcoin-dev/Feb_2017/combined_Generalized-Commitments.xml b/static/bitcoin-dev/Feb_2017/combined_Generalized-Commitments.xml index 7d66d305e9..23db03a9c4 100644 --- a/static/bitcoin-dev/Feb_2017/combined_Generalized-Commitments.xml +++ b/static/bitcoin-dev/Feb_2017/combined_Generalized-Commitments.xml @@ -2,7 +2,7 @@ 2 Combined summary - Generalized Commitments - 2025-09-26T15:52:05.999759+00:00 + 2025-10-11T21:58:39.345753+00:00 python-feedgen Bram Cohen 2017-02-23 02:56:35+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Generalized Commitments - 2025-09-26T15:52:05.999909+00:00 + 2025-10-11T21:58:39.345883+00:00 2017-02-23T02:56:35+00:00 Peter Todd suggests that a commitment scheme should ensure that two messages cannot map to the same commitment, rather than focusing on the difficulty of finding the message given the commitment. Additionally, he mentions that commitments do not need to be of the same size and proposes a scheme where the commitment to short messages is the message itself, with only one additional bit of data added to the minimum serialized size of the commitment.However, in order to maintain uniform size for all values, two bits of security need to be sacrificed to allow for four values: terminal, middle, empty, and invalid. For a set containing a single value, the root would be that value with the two high order bits of the first byte reset to the appropriate value.In the bitcoin-dev discussion, Bram Cohen introduces the concept of 'generalized commitment' as a use-case specific approach to reduce hashing requirements. The proposal suggests that when one side of a node is empty and the other contains exactly two things, the secure hash of the child is adopted without rehashing it. This can potentially halve the amount of hashing done and increase resistance to malicious data, although it does introduce extra complexity.Cohen emphasizes that a commitment scheme only needs to ensure that two messages cannot map to the same commitment, without requiring difficulty in finding the message given the commitment. He believes that designing a scheme where the commitment to short messages is the message itself, with just one additional bit of data, could lead to overall savings, especially for situations where sub-digest-sized messages are common.Furthermore, Cohen highlights that this approach also enhances user-friendliness because programmers will be able to notice when a commitment is not effectively hiding the message. However, if message privacy is essential, an explicit nonce should be implemented instead of relying solely on the data being non-brute-forcible.Finally, Cohen mentions his increasing consideration of bit-granularity serialization schemes for these types of systems, suggesting a potential direction for future development. diff --git a/static/bitcoin-dev/Feb_2018/combined_Possible-change-to-the-MIT-license.xml b/static/bitcoin-dev/Feb_2018/combined_Possible-change-to-the-MIT-license.xml index a0c4cdb919..26b6279c51 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Possible-change-to-the-MIT-license.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Possible-change-to-the-MIT-license.xml @@ -2,7 +2,7 @@ 2 Combined summary - Possible change to the MIT license - 2025-09-26T15:39:59.883055+00:00 + 2025-10-11T21:51:08.697847+00:00 python-feedgen Damian Williamson 2018-02-14 10:09:25+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - Possible change to the MIT license - 2025-09-26T15:39:59.883226+00:00 + 2025-10-11T21:51:08.698025+00:00 2018-02-14T10:09:25+00:00 Damian Williamson expresses his disagreement with any changes to the current MIT license for Bitcoin's software, arguing that altering even a single word could have significant legal consequences. On the other hand, Cory Fields suggests focusing on copyright litigation and trademark dilution concerns while emphasizing the importance of Bitcoin's position. There is a statement from an unknown individual who disapproves of changing open source principles due to personal reasons. They emphasize the need to maintain the integrity of open source and not dilute its core values. The use of open source software follows specific principles that should not be altered according to personal preferences.Several members of the bitcoin-dev mailing list disagree with a proposed change to Bitcoin Core's license terms. They argue that this solution may not effectively address the problem of fork coins using the Bitcoin name and suggest social and marketing-based approaches instead. They also express concerns about the potential legal uncertainty and harm to Bitcoin's philosophy of being free and independent. Additionally, they argue that prohibiting the use of the name Bitcoin would be like prohibiting the use of the word "Linux" in brands based on the Linux kernel.A proposal has been raised to amend the MIT license under which Bitcoin is licensed to limit the use of the Bitcoin name by other projects unless they are fully compatible with the Bitcoin Core blockchain. This is intended to mitigate confusion among users caused by multiple hard forks. However, there are concerns about the enforceability of this amendment and its potential impact on forking older versions of Bitcoin or using existing independent blockchain implementations under the Bitcoin name.Custom open-source licenses can create compliance issues for organizations using software. Deviations from universally-accepted open-source licensing terms can lead to legal complications, necessitating approval from employers before using the software. Therefore, changes to the license may not be viable, regardless of how it is phrased. A suggestion was made to limit cryptocurrencies with the same Proof of Work, but there is opposition due to potential branding attacks.A recent discussion on the Bitcoin-dev mailing list addresses a potential license change that could impact the use of the Bitcoin name as a brand or trademark. Some argue that this change could be seen as an attack on Bitcoin's open source nature and fundamental principles. Others suggest social and marketing-based solutions rather than legal ones to address confusion caused by fork coins using the Bitcoin name. Concerns are raised about legal uncertainty and the impact on forking older versions of Bitcoin or using existing independent blockchain implementations. The challenges of balancing brand protection with free and open source software development are highlighted.The speaker agrees with opposition to changing the license due to branding attacks but suggests limiting cryptocurrencies with the same Proof of Work to ensure the stability and security of Bitcoin.Developers discuss a proposal to alter Bitcoin Core's license terms to limit liability for developers subject to lawsuits. Concerns are raised regarding who would have the right to assert an offensive claim of breached license terms. Some argue that defending against branding attacks should be social and marketing-based rather than relying on courts or governments. Frustration is expressed over ongoing FUD and scammery without an official response. Suggestions include altering the license terms or using trademarks, but there are concerns about legal uncertainty and being unable to mention Bitcoin.The proposed solution to disincentivize fork coins from using the word Bitcoin by altering the license terms is met with criticism. It is argued that a social or marketing-based defense would be more effective since the problem is social and marketing-based. Bitcoin should not rely on courts or governments to defend itself against attacks. Trademarks are suggested as an alternative solution, but there are concerns about legal uncertainty and the impact on forking older versions of Bitcoin or using existing independent blockchain implementations. Being unable to mention Bitcoin is considered excessive, and the license does not affect blockchain data.Bitcoin is facing a branding attack by fork coins, and suggestions to alter the license terms to disincentivize their use of the word Bitcoin are met with criticism. A social or marketing-based defense is proposed as more effective, and Bitcoin should not rely on courts or governments for defense. Trademarks are suggested as an alternative solution, but concerns about legal uncertainty and compatibility with older versions are raised. Being unable to mention Bitcoin is seen as excessive, and the license does not affect blockchain data.The ongoing branding attack on Bitcoin by fork coins prompts discussions about possible solutions. Altering the license terms is suggested, but its effectiveness is questioned without an entity using court systems. A social or marketing-based defense is proposed, emphasizing that Bitcoin should not rely on courts or governments. Trademarks are also suggested, but concerns about legal uncertainty and compatibility with older versions arise. Frustration over unanswered FUD and scammery is expressed.Bitcoin is facing a branding attack by fork coins, and altering the license terms to disincentivize their use of the word "Bitcoin" is proposed. However, it may not be effective without an entity using court systems. A social or marketing-based defense is argued to be more appropriate, and Bitcoin should not rely on courts or diff --git a/static/bitcoin-dev/Feb_2018/combined_Some-thoughts-on-removing-timestamps-in-PoW.xml b/static/bitcoin-dev/Feb_2018/combined_Some-thoughts-on-removing-timestamps-in-PoW.xml index 2f215660b4..8049cbca63 100644 --- a/static/bitcoin-dev/Feb_2018/combined_Some-thoughts-on-removing-timestamps-in-PoW.xml +++ b/static/bitcoin-dev/Feb_2018/combined_Some-thoughts-on-removing-timestamps-in-PoW.xml @@ -2,7 +2,7 @@ 2 Combined summary - Some thoughts on removing timestamps in PoW - 2025-09-26T15:40:18.784351+00:00 + 2025-10-11T21:51:10.823424+00:00 python-feedgen Tao Effect 2018-02-21 21:58:10+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - Some thoughts on removing timestamps in PoW - 2025-09-26T15:40:18.784504+00:00 + 2025-10-11T21:51:10.823582+00:00 2018-02-21T21:58:10+00:00 The email conversation explores the idea of modifying the Bitcoin blockchain to address concerns about state checkpoints and full node verification. The proposal suggests creating a new protocol that solves these issues rather than being limited by Bitcoin's current design constraints. However, Damian Williamson raises concerns that new full nodes may not have complete knowledge of utxo's if large sections of the blockchain are skipped during verification.Another proposal suggests removing timestamps from the Bitcoin blockchain's difficulty adjustment algorithm. The author argues that timestamps may be unnecessary for the blockchain to operate with the same level of security. Under this proposal, miners would have the freedom to mine blocks of any difficulty they choose, up to a certain maximum deviation. This could incentivize powerful miners to raise the difficulty and remove competitors. While timestamps could still be included in blocks, they would no longer represent anything significant other than metadata about when the block was produced.This alternative difficulty adjustment algorithm carries some risks, including potential centralization pressures. To mitigate these risks, two solutions are proposed. One is introducing state checkpoints into the chain itself, which would allow full nodes to skip verification of large sections of historical data when booting up. The other solution is implementing a sharded protocol that uses a sufficiently different Proof-of-Work (PoW) algorithm. These mitigations aim to address concerns about centralization pressures on both miners and full nodes.A member of the Bitcoin community suggests that the Y% difficulty adjustment should still be calculated through an averaging of a certain number N of past blocks. This suggestion aims to prevent a network halt caused by two lucky high difficulty blocks in a row. They also propose a logarithmic scaling reward function based on past average difficulty and the total number of mined coins. This function could discourage mining blocks with excessively large difficulties while still maintaining the 21 million coin cap.While these proposals generate discussions within the Bitcoin community, it is important to note that there are no concrete plans mentioned to modify Bitcoin in the thread. Greg Slepak, the author of the article, suggests that attempting to make these changes to the existing Bitcoin blockchain would be a non-starter and proposes forking to a new coin as an alternative.In summary, Greg Slepak questions the necessity of timestamps in Bitcoin's blockchain and proposes an alternative difficulty adjustment algorithm. This algorithm ties the number of coins issued per block directly to the difficulty of the block. However, implementing such a system may introduce risks, including centralization pressures on miners and full nodes. Mitigations such as state checkpoints and a sharded protocol using a different PoW algorithm are suggested. While these proposals generate discussions, there are no concrete plans mentioned to modify Bitcoin in the thread. Greg Slepak ultimately suggests forking to a new coin instead of modifying the existing Bitcoin blockchain. diff --git a/static/bitcoin-dev/Feb_2019/combined_NIH-warning-was-Re-BIP-Proposal-Simple-Proof-of-Reserves-Transactions-.xml b/static/bitcoin-dev/Feb_2019/combined_NIH-warning-was-Re-BIP-Proposal-Simple-Proof-of-Reserves-Transactions-.xml index 148f123028..bee3ecab92 100644 --- a/static/bitcoin-dev/Feb_2019/combined_NIH-warning-was-Re-BIP-Proposal-Simple-Proof-of-Reserves-Transactions-.xml +++ b/static/bitcoin-dev/Feb_2019/combined_NIH-warning-was-Re-BIP-Proposal-Simple-Proof-of-Reserves-Transactions-.xml @@ -2,7 +2,7 @@ 2 Combined summary - NIH warning (was Re: [BIP Proposal] Simple Proof-of-Reserves Transactions) - 2025-09-26T15:48:23.075383+00:00 + 2025-10-11T21:57:44.060479+00:00 python-feedgen William Casarin 2019-02-17 18:00:32+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - NIH warning (was Re: [BIP Proposal] Simple Proof-of-Reserves Transactions) - 2025-09-26T15:48:23.075555+00:00 + 2025-10-11T21:57:44.060649+00:00 2019-02-17T18:00:32+00:00 Developer Pavol Rusnak has praised the use of Protocol Buffers in Trezor, despite the risk of adding an exotic dependency to a software project. He argues that Protocol Buffers are easy to work with and have many interoperable implementations in various languages. However, there are discussions about whether people are moving away from Protocol Buffers in favor of FlatBuffers. Another developer named Will suggests providing custom format to protobuf conversion tools, allowing users who prefer not to include large dependencies to convert it into their preferred format.On 15/02/2019, Luke Dashjr discussed the proposed proof-file format, which aims to provide a standard way to combine multiple proofs and associated metadata. The specification for this format is in Protocol Buffers. Despite some concerns about using Protocol Buffers, Pavol "stick" Rusnak believes that it is not risky because of its interoperable implementations in all possible languages and its ease of use. He compares it to the PSBT format, which was almost as complex as protobuf but proprietary to Bitcoin, hindering adoption. He believes that if Protocol Buffers had been used since the beginning, there would have been much more usage of the PSBT format already. Overall, Protocol Buffers have proven to be a successful choice for Trezor. diff --git a/static/bitcoin-dev/Feb_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml b/static/bitcoin-dev/Feb_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml index 113c7c139e..e19b837a49 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml @@ -2,7 +2,7 @@ 2 Combined summary - Nonce blinding protocol for hardware wallets and airgapped signers - 2025-09-26T15:51:09.317089+00:00 + 2025-10-11T21:58:32.957160+00:00 python-feedgen Dustin Dettmer 2020-03-02 20:01:51+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Nonce blinding protocol for hardware wallets and airgapped signers - 2025-09-26T15:51:09.317226+00:00 + 2025-10-11T21:58:32.957378+00:00 2020-03-02T20:01:51+00:00 Stepan Snigirev has proposed a protocol for signing messages using an air-gapped computer or hardware wallet in the Bitcoin development mailing list. This comes in response to the acknowledgment that these devices can be compromised through supply chain attacks or malicious firmware updates. The proposed protocol aims to reduce the attack surface by involving additional entropy from the host. The protocol requires the host to pick a random number `n` and send its hash along with the message `m` to the signer. The signer calculates a nonce `k` and sends the corresponding point `R=kG` to the host, committing to the chosen nonce. The preimage `n` is then sent to the signer, who tweaks the nonce by this number and signs the message. The signed message is sent back to the host, who verifies that the public point in the signature is tweaked by `n`.Extensions to the protocol are also suggested by Snigirev. One extension involves the use of multiple hosts, where all hosts don't trust each other and the signer. In this case, hosts can concatenate hashes and preimages to add external entropy to the nonce. Another extension involves the use of a stateless random signer. If the signer wants to generate a nonce non-deterministically but doesn't have the ability to store it, they can send back meta-information to the host that would help regenerate the same nonce later.The proposed protocol can be implemented for PSBT using key-value pairs added to BIP-174. These include keys such as {PSBT_IN_EXT_NONCE_HASH}|{pubkey} for sha256(n1)|sha256(n2)|..., {PSBT_IN_NONCE_COMMITMENT}|{pubkey} for the 33-byte R point, {PSBT_IN_NONCE_SIGNER_METADATA}|{pubkey} for any value, and {PSBT_IN_EXT_NONCE_PREIMAGE}|{pubkey} for n1|n2|....Marko expresses gratitude for the implementation of a protocol for PSBT anti-nonce covert channel and backports the scheme to ECDSA in the secp256k1 library. He suggests using the generalized sign-to-contract scheme in PSBT, where the final nonce is computed as `k' = k + H(k*G, n)` instead of `k'=k+n`. Proprietary fields or key-value pairs can be added to BIP-174 depending on the interest of others. Careful verification against the state stored by the host for the PSBT is necessary to avoid implementation mistakes and private key leakage.The writer appreciates the initiative of implementing and releasing a protocol inspired by a blog post. The protocol was implemented in the secp256k1 library for Schnorr sigs and backported to ECDSA for current transactions. Proof of concepts were made to verify its effectiveness. The generalized sign-to-contract scheme was used in these implementations, with the final nonce computed as `k' = k + H(k*G, n)`. However, caution is advised when implementing the protocol with an air-gapped signer, as wrong implementation could lead to private key leaks. Guidelines and best practices to avoid pitfalls are requested.When generating a digital signature, it is unsafe to use only the message and private key. Instead, all data from the host should be used to create a nonce. Multiple blinding factors can also be used. If completely random nonces cannot be gathered due to insufficient entropy, any available source of entropy can be mixed into the nonce generation function. Glitch attacks, where two identical messages produce different signatures due to a flipped bit in the message, can be prevented by including a monotonic counter in the nonce generation function. The Yubikey had a problem with RNG initialization that caused private key leakage, so it's recommended to avoid pure RNG-generated nonces.The compromise of hardware wallets and air-gapped computers is discussed, highlighting the risks of supply chain attacks and malicious firmware updates. The proposed protocol aims to address these concerns by involving additional entropy from the host in the signing process. It is noted that using a deterministic scheme with only the message and privkey would be unsafe in certain scenarios. To prevent targeted attacks, it's recommended to derive the nonce from the message, `sha256(n)`, and the privkey mixed together using a suitable hashing function. While completely random nonces are ideal, resource limitations may prevent their use.Stepan Snigirev proposes a protocol to prevent the compromise of hardware wallets or air-gapped computers used for signing transactions. The protocol involves the host picking a random number and sending its hash along with the message to the signer, who computes a nonce and commits to it by sending the corresponding point to the host. The preimage is then sent back to the signer, who tweaks the nonce and signs the message. The host verifies that the public point in the signature is tweaked by the same amount. If the signer wants to generate a nonce non-determin diff --git a/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity-reflowed-.xml b/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity-reflowed-.xml index 901d4576a5..114503b73f 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity-reflowed-.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Taproot-and-graftroot-complexity-reflowed-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Taproot (and graftroot) complexity (reflowed) - 2025-09-26T15:51:34.508695+00:00 + 2025-10-11T21:58:37.216690+00:00 python-feedgen Pieter Wuille 2020-02-18 23:29:21+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - Taproot (and graftroot) complexity (reflowed) - 2025-09-26T15:51:34.508859+00:00 + 2025-10-11T21:58:37.216840+00:00 2020-02-18T23:29:21+00:00 Pieter Wuille emphasized the significance of Taproot in incentivizing protocols and implementations that utilize the key path, maximizing privacy and appealing to a broader range of users. He argued against having a separate MAST-no-Taproot spending type, as it would reduce incentives for those who don't prioritize spending policy privacy in building key-path-spendable protocols. Wuille also mentioned alternative options for cheap verification constructions but noted that they disregard incentives for privacy, which could negatively impact fungibility and overall system effectiveness.In a Bitcoin-dev thread, Jeremy questioned whether using Schnorr + Merkle Branch without Taproot optimization is equivalent. Dave responded that it is only true if all parties construct their merkle tree with a single `OP_CHECKSIG` as one of the top leaves. However, Taproot standardizes the position of the all-parties-agree condition, leading to a larger anonymity set and easier participation by pure single-sig users. Despite taproot scriptPubKeys being larger than P2WPKH scriptPubKeys, the witness data is considerably smaller, incentivizing receivers to demand P2TR payments even if spenders are reluctant to pay the extra 12 vbytes per output. Dave provided rough estimates for various PubKeys and witness data types. He concluded by stating that this branch of the discussion reiterates points covered two years ago.A group of anonymous developers expressed concerns about the development and deployment of Taproot, proposing an alternate path and suggesting modifications to its specification. They argue that Taproot is essentially the same as using Schnorr signatures separately, but combining them assumes specific use cases and probability distributions. The developers propose separate soft-forks for Merkle Branch Witnesses based on Taproot and Schnorr Signatures, followed by a separate soft-fork enabling Taproot and Graftroot. They believe this conservative approach allows for real-world protocol engineering experience to validate the Taproot frequency assumption. The group suggests modifying Taproot's specification by adding a rule for the Taproot Public NUMS Optimization, which includes attempting to hash the witness stack and using a NUMS point only when a single-use nonce can be sent. They advocate for careful consideration of Taproot's benefits compared to simpler alternatives and incremental improvements.Another group of anonymous developers raised concerns about the deployment of Taproot in Bitcoin and questioned its benefits over simpler alternatives. They discussed Taproot's efficiency, privacy implications, and the wisdom of including multiple features into Bitcoin simultaneously. They proposed an alternate deployment path involving separate soft-forks for Merkle Branch Witnesses based on Taproot and Schnorr Signatures, followed by a separate soft-fork enabling Taproot and Graftroot. The group also suggested modifications to Taproot's specification, such as allowing the witness type to be either a MAST hash or a Schnorr key, and evaluating delegated scripts using a P2SH-like semantic. They emphasized the importance of considering the actual use cases and probability distributions for Taproot's assumptions.In a recent bitcoin-dev discussion, it was confirmed that Taproot is more private than bare MAST and Schnorr when used separately. When combined with schnorr, Taproot enables various transaction types that represent a majority of spends seen on the blockchain throughout Bitcoin's history, optimizing them for anonymity set inclusion. While there is an overhead to the size of inputs, optimizations can allow for the creation of large anonymity sets. Encouraging script-path spenders to find mutually-agreed contract resolutions can further minimize blockchain use and increase the anonymity set. The discussion also highlighted the prevalence of single-sig, n-of-n, and k-of-n (for small n) transactions, supporting the assumption that Taproot with a key will be more common than script cases.A group of anonymous developers expressed concerns regarding the deployment of Taproot in Bitcoin, advocating for a careful evaluation of its benefits compared to simpler primitives. They proposed an alternative deployment path and modifications to Taproot's specification. Their concerns encompassed efficiency, privacy, and the need for incremental improvements that can work together. The group emphasized the importance of considering their suggestions and engaging in community dialogue. diff --git a/static/bitcoin-dev/Feb_2020/combined_Taproot-public-NUMS-optimization-Re-Taproot-and-graftroot-complexity-.xml b/static/bitcoin-dev/Feb_2020/combined_Taproot-public-NUMS-optimization-Re-Taproot-and-graftroot-complexity-.xml index 612c3aaf17..0743efca06 100644 --- a/static/bitcoin-dev/Feb_2020/combined_Taproot-public-NUMS-optimization-Re-Taproot-and-graftroot-complexity-.xml +++ b/static/bitcoin-dev/Feb_2020/combined_Taproot-public-NUMS-optimization-Re-Taproot-and-graftroot-complexity-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity) - 2025-09-26T15:51:21.918210+00:00 + 2025-10-11T21:58:35.092961+00:00 python-feedgen Jeremy 2020-02-14 21:21:15+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity) - 2025-09-26T15:51:21.918379+00:00 + 2025-10-11T21:58:35.093122+00:00 2020-02-14T21:21:15+00:00 A group of anonymous developers have proposed a modification to the Taproot specification in BIP-341 to optimize its public NUMS and enhance privacy. The proposal suggests removing the need for public NUMS and introducing bare MAST (Merkleized Abstract Syntax Trees) to prevent the leakage of metadata from different public NUMS. The use of a NUMS point in Taproot can still be maintained for greater anonymity, but it is recommended only when a single-use nonce can be sent. Private NUMS are noted to provide more privacy benefits with a minimal impact on the likelihood of losing funds.The proposal has garnered support as well as alternative responses from the developer community. Suggestions include implementing a discounting rule for the Public NUMS or modifying the leaf version portion of C[0] to denote Public NUMS and avoid including the point explicitly. These discussions are being conducted under pseudonyms to keep the focus on technical issues rather than personal politics.In addition to the proposed modification, the group of developers discusses the design merits of Taproot compared to simpler alternatives. They also propose an alternative path for deploying the technologies described in BIP-340, BIP-341, and BIP-342.It is highlighted that using a NUMS point in Taproot may decrease privacy if the points differ across applications, potentially allowing for wallet fingerprinting. Therefore, the recommendation is to use the NUMS point only when a single-use nonce can be sent, ensuring that it cannot be distinguished from a normal Taproot by third parties unaware of the setup.Overall, the goal of the anonymous developer group is to contribute to finding the best way forward with Taproot, without causing division within the community. diff --git a/static/bitcoin-dev/Feb_2021/combined_Taproot-NACK.xml b/static/bitcoin-dev/Feb_2021/combined_Taproot-NACK.xml index c4eebd6d2c..831485fd1c 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Taproot-NACK.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Taproot-NACK.xml @@ -2,7 +2,7 @@ 2 Combined summary - Taproot NACK - 2025-09-26T15:54:56.864439+00:00 + 2025-10-11T22:02:56.615644+00:00 python-feedgen DA Williamson 2021-03-18 01:10:38+00:00 @@ -149,10 +149,11 @@ + 2 Combined summary - Taproot NACK - 2025-09-26T15:54:56.864655+00:00 + 2025-10-11T22:02:56.615848+00:00 2021-03-18T01:10:38+00:00 The email thread on the bitcoin-dev mailing list revolves around discussions about privacy concerns related to Bitcoin transactions and the proposed Taproot protocol change. LORD HIS EXCELLENCY JAMES HRMH expresses concerns about increased privacy and potential obfuscation of transactions, which could lead to government bans. However, other members argue that Taproot does not increase privacy beyond current techniques like coinjoin, payjoin, and lightning. The importance of maintaining transparency in the blockchain while still allowing for privacy is emphasized.The conversation also touches on the affiliation of LORD HIS EXCELLENCY JAMES HRMH with a Bitcoin mixer service, raising questions about their motivations and potential conflicts of interest. The need for proper disclosure when discussing transaction privacy is highlighted.Another member named Damian A. James Williamson, associated with Willtech, shares contact information but does not provide specific advice or information about projects. The intention behind the email is unclear.The debate centers around striking a balance between privacy and security with transparency and accountability in Bitcoin transactions. Various perspectives are shared, including the value proposition of Bitcoin, the availability of privacy suitable for cash, and the implications of obfuscating transactions on government bans.Overall, the email thread covers topics such as consensus, censorship resistance, fraud prevention, privacy techniques, and the presence of a disruptive troll on the bitcoin-dev mailing list. It provides insights into various perspectives and approaches within the Bitcoin community. diff --git a/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml b/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml index 2d356a0699..b775916192 100644 --- a/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml +++ b/static/bitcoin-dev/Feb_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Yesterday's Taproot activation meeting on lockinontimeout (LOT) - 2025-09-26T15:55:03.334011+00:00 + 2025-10-11T22:02:58.749209+00:00 python-feedgen Ariel Lorenzo-Luaces 2021-03-02 18:32:00+00:00 @@ -173,10 +173,11 @@ + 2 Combined summary - Yesterday's Taproot activation meeting on lockinontimeout (LOT) - 2025-09-26T15:55:03.334231+00:00 + 2025-10-11T22:02:58.749452+00:00 2021-03-02T18:32:00+00:00 The Bitcoin community is currently engaged in discussions about the activation of Taproot, a proposed soft-fork upgrade for the network. The activation method itself has raised concerns about the risk of chain splits and the potential impact on consensus. One suggestion to minimize this risk is to release a version of Bitcoin Core that requires users to choose between activating Taproot with LOT=true or LOT=false. However, there are debates about whether giving miners too much control over consensus could set a problematic precedent.Bitcoin Core developer Matt Corallo emphasized the long-standing policy of not including options that could harm users, explaining that the role of Bitcoin Core developers is to recommend technically sound and consensus-supported courses of action. While users are free to run their own software, he doesn't anticipate that the minority advocating for certain options on platforms like Twitter will have sufficient influence to sustain their choices if they find themselves on a chain with no blocks.The ongoing debate on the activation mechanism for Taproot includes discussions about whether to set the lock-in on timeout (LOT) parameter to true or false. Various viewpoints have been expressed, with some participants arguing for LOT=true and others suggesting LOT=false. Michael Folkson, who summarized the outcomes of a Taproot activation meeting, concluded that there was no overwhelming consensus but noted stronger opposition to LOT=true from Bitcoin Core contributors and Lightning developers. Based on this, he recommended proposing LOT=false as the activation parameter.However, the decision-making process is still ongoing, and code review of the Bitcoin Core PR #19573 is scheduled for February 23rd. While there are diverging opinions on the best course of action, the goal remains to activate Taproot as early as possible while minimizing risks and ensuring broad consensus within the Bitcoin community.It's worth noting that an activation mechanism is a consensus change that can be contentious. Therefore, it's important to engage in open discussions and prepare for different scenarios without being antagonistic or destructive. The Bitcoin community aims to find a resolution that aligns with the collective interest and avoids detrimental outcomes.The activation of Taproot has sparked debates within the Bitcoin community. Some members suggest setting LOT=false to minimize the risk, while others propose allowing users to make the choice themselves. There is disagreement on which option is safer, with arguments made for both LOT=true and LOT=false.During a recent meeting on Taproot activation, there was majority support for LOT=false over LOT=true. However, concerns were raised about the representativeness of the meeting, as only around 100 people attended. Despite this, it is recommended to propose LOT=false in order to finalize Taproot activation parameters and propose them to the community.It is emphasized that users are not forced to upgrade to any particular software version, and there is a possibility that only a small number of people will run LOT=true while others delay their upgrade. The goal is to avoid a chain split and falling out of consensus.The Bitcoin community acknowledges the importance of open discussions and preparation for worst-case scenarios in order to build secure systems. A code review of Bitcoin Core PR #19573 is scheduled, and participants are thanked for engaging productively and in good faith.Overall, the Bitcoin community is actively discussing the activation of Taproot and considering the potential risks and benefits. The debate centers around whether to set LOT to true or false, with arguments made for both options. The community aims to reach a consensus and activate Taproot in a way that minimizes risks and ensures the long-term growth and security of the ecosystem.The ongoing debate on the activation of Taproot continues, with different perspectives on the implementation and consensus rules. Software complexity and infrastructure limitations have been raised as challenges. The proposal for a LOT=true option in Bitcoin Core has faced opposition, leading to the recommendation of proposing LOT=false. Communication, agreement, and avoiding forced-signaling via forks are emphasized. Multiple forks and alternative implementations are suggested to enhance decentralization. The aim is to activate Taproot as early as possible while considering consensus and technical soundness.In the recent meeting on Taproot activation, arguments for both LOT=true and LOT=false were discussed. While there was no overwhelming consensus, there was more opposition against LOT=true among Bitcoin Core contributors, Lightning developers, and other community members. Some mining pools expressed a preference for LOT=false. It was decided to propose LOT=false at this time, considering the aim of activating the Taproot soft fork as early as possible.Matt Corallo emphasized the importance of communication and agreement in the activation process. He suggested that if there is broad consensus for Taproot but some miners fail to upgrade, a flag day activation could be considered instead of a UASF/BIP8-style fork, which carries additional risks. The tradeoffs of a BIP8(false, ∞) option were also discussed, with suggestions for maintaining multiple forks of Bitcoin Core to enhance decentralization.The practicality of implementing a LOT=false option in Bitcoin Core was questioned due to the software complexity involved. Bitcoin Core's long-standing policy is not to ship options that diff --git a/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml b/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml index 9de6d20b16..f227a3ccb2 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Decentralized-BIP-47-payment-code-directory.xml @@ -2,7 +2,7 @@ 2 Combined summary - Decentralized BIP 47 payment code directory - 2025-09-26T16:02:59.788263+00:00 + 2025-10-11T22:17:06.939507+00:00 python-feedgen Prayank 2022-03-02 04:45:58+00:00 @@ -18,10 +18,11 @@ + 2 Combined summary - Decentralized BIP 47 payment code directory - 2025-09-26T16:02:59.788506+00:00 + 2025-10-11T22:17:06.939652+00:00 2022-03-02T04:45:58+00:00 In a conversation between Peter and Prayank, Prayank introduces a newer version (v3 and v4) of BIP47, which has been proposed on GitHub. This version aims to solve the toxic change issue and seems like an improvement. Prayank explains that using an xpub does not provide anonymity because anyone who has access to the xpub, including platforms or hackers, can identify one's payments. However, using a payment code allows for public association without revealing the payment identifier on the blockchain, making it difficult for others to determine if funds have been received. Prayank also suggests a rust library that can assist application developers in implementing BIP47 into different bitcoin projects.The OpenBitcoinPrivacyProject has proposed a newer version of BIP47, v3 and v4, which addresses certain issues present in the previous version. The new version eliminates the toxic change issue by modifying the notification from Alice to Bob as a transaction from Alice to herself, functioning as a bare 1 of 3 multisig. Two pubkeys represent Alice's payment code and Bob's payment identifier. This change incurs a one-time overhead of 64 bytes for the two pubkeys, which is spread out over the lifespan of the relationship between Alice and Bob. Additionally, the first economic payment from Alice to Bob can be included with the notification transaction. Payment codes can be recovered from the bip32 seed without requiring extra backups. The new version is already being used in production with Samourai wallet. BIP47 v3 enables Alice to receive Bob's address without exposing her IP/identity to Charlie. Charlie can observe Alice receiving the payment code material from Bob but cannot determine if Alice proceeded to make a payment to Bob. Unlike an xpub, this method ensures privacy even if the xpub is shared with a crowdfunding platform, as the platform or any potential hackers cannot identify the payments made by Alice. By using the payment code, individuals can publicly associate themselves with their payment code without revealing if they have received funds, as the payment code is not visible on the blockchain.Twitter has seen discussions about BIP47 and its potential to enhance privacy. However, some developers argue that it merely adds spam to the Bitcoin network without providing any actual improvements. Additionally, the only existing implementation of BIP47 is Paynym, a centralized payment code directory managed by Samourai wallet, raising concerns regarding privacy and security. To address these concerns, the author suggests utilizing TXT records and domains. They present a proof of concept using GNS (GNU Name Service) to create a payment code for Alice, adding it as a TXT record with an expiry date, and verifying it. The author also proposes using `gnunet-publish` as a replacement for notification transactions. These solutions could potentially help users avoid sharing their bitcoin addresses on social media platforms when receiving donations. In addition to these suggestions, the author provides links to related resources, including a Q&A on accepting donations correctly and a new proposal addressing privacy concerns. diff --git a/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml b/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml index 21960fb29b..bf46b4091a 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml @@ -2,7 +2,7 @@ 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2025-09-26T16:03:08.242841+00:00 + 2025-10-11T22:17:15.446164+00:00 python-feedgen Paul Sztorc 2022-03-04 20:06:50+00:00 @@ -94,10 +94,11 @@ + 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2025-09-26T16:03:08.243032+00:00 + 2025-10-11T22:17:15.446379+00:00 2022-03-04T20:06:50+00:00 In an email exchange on the bitcoin-dev mailing list, Billy Tetrud discusses sidechains and their potential to address the issue of a less-secure altcoin dominating Bitcoin. While he acknowledges some merits of sidechains in this scenario, Tetrud points out that they do not completely solve the problem. He raises concerns about a sidechain cutting off the main chain and whether it would be in the best interest of enough people. Tetrud also explores the benefits and drawbacks of largeblock sidechains compared to other payment systems like Visa and Lightning. Various tradeoffs, such as onboarding, payment speed, micropayments, fees, and contribution to layer 1 security budget, are considered. Tetrud concludes that if a layer 2 is harmless, its existence can be justified by one net benefit for some users.Another discussion revolves around the size of commitments needed for sidechains and channel factories. User ZmnSCPxj suggests a solution to reduce on-chain bytes by utilizing tweaks in the miner's key and unused TapScript. This eliminates the need for separate commitments and reduces data requirements. Additionally, sidechains can push zero bytes on-chain by using OP_RETURN inside TapScript for checking purposes.The conversation centers around the potential dominance of a sidechain over Bitcoin and how it could prevent an altcoin from dominating. The consensus is that having all chains, centralized and decentralized, in the same monetary unit ensures the decentralized chain always exists without interference from monetary network effects. However, it is argued that a sidechain cannot exist without its main chain, and if it becomes too popular, people may stop using the main chain altogether. The discussion also compares the benefits of a largeblock sidechain to Visa and Lightning and considers the burden on Bitcoin-only nodes. The potential advantages to users of a largeblock sidechain are discussed, including lower fees and more decentralization. The idea of sweeping fiat transactions into a largeblock sidechain is also explored.Another conversation between Billy Tetrud and Paul focuses on the use of sidechains in Bitcoin. Billy proposes that all chains, decentralized and centralized, being in the same monetary unit ensures the existence of the decentralized chain without interference from network effects. Paul disagrees, stating that sidechains cannot exist without their main chain and gives an example using a zcash sidechain. They also discuss the merits of largeblock sidechains and how they can allow users to easily sweep fiat transactions into the BTC universe. Paul believes that largeblock sidechains would not burden Bitcoin Core full nodes.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin scalability, sidechains, network effects, and the security of Lightning Network and Drivechains. Participants argue that sidechains are necessary to prevent people from switching entirely to altcoins, which could be heavily exploited by attackers. Another participant suggests that having all chains in the same monetary unit guarantees the existence of the decentralized chain. The discussion delves into the security risks of LN channel factories and compares the security of LN and Drivechains. The participants emphasize the importance of separating the onboarding rate from the payment rate for designing different structures.The email exchange on the bitcoin-dev mailing list centers around the use of recursive covenants and their potential impact on Bitcoin. The discussion explores implementing techniques like Drivechains using recursive covenants. While concerns about negative effects on Bitcoin or the user base are raised, it is suggested that separate soft forks can be used to add recursive covenants if consensus is reached. The rejection of Drivechains in Bitcoin is also discussed, with arguments made against their implementation due to their distinct security model and potential block size increase. However, proponents argue that Drivechains could have a positive impact and should be given a chance. The debate includes discussions on miner censorship, block size increase, and the need for consensus changes. Paul Sztorc responds to the rejection of Drivechains, stating that there is no strong incentive for mainchain miners and sidechain validators to merge their businesses. He refutes claims that Drivechains would degrade security and believes that Drivechain was ahead of its time and will eventually be adopted. Other discussions revolve around encumbrances and restrictions on spend from covenants, the potential harm to the fungibility of UTXOs, and the shift in risk models. Some argue that introducing different risk models can be damaging to fungibility, while others believe that being able to reject certain coins is at the heart of Bitcoin's security. The email exchanges highlight the ongoing debates and considerations surrounding recursive covenants, Drivechains, and their potential impact on Bitcoin.In a recent email to the Bitcoin-dev mailing list, Jeremy Rubin raises concerns about proposals enabling more "featureful" covenants by adding additional computation into bitcoin script. They emphasize the importance of limiting operations in bitcoin script to "verification" rather than "computation" whenever possible. The author expresses uncertainty about these proposals and fears that opcodes like OP_CAT and OP_TX introduce unnecessary complexity into the script. However, diff --git a/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml b/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml index 02788b7715..7fa8d6ca60 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml @@ -2,7 +2,7 @@ 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2025-09-26T16:03:06.128132+00:00 + 2025-10-11T22:17:13.311875+00:00 python-feedgen Billy Tetrud 2022-02-22 12:57:15+00:00 @@ -86,10 +86,11 @@ + 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2025-09-26T16:03:06.128321+00:00 + 2025-10-11T22:17:13.312065+00:00 2022-02-22T12:57:15+00:00 In a recent discussion about Bitcoin scaling, there was disagreement over whether it should be done rapidly or not. Some argue that scaling should not be delayed to keep fees high, suggesting that if higher fees are needed, the block size can be lowered or the default minimum relay fee rate increased. They also question the belief that the Lightning Network is the main cause of low fees and argue that delaying scaling would harm Bitcoin's growth.On the other hand, others argue that new use cases for on-chain transactions may compete with existing users for limited blockchain space. This situation has been compared to the saying "nobody goes there anymore, it's too crowded." The discussion also touched upon the issue of invoking Satoshi's opinions in present-day discussions. One participant objected to assumptions about the founder of Bitcoin, arguing that Satoshi is more than just a pseudonym and will live on forever. However, another participant objected to the invocation of Satoshi in general, suggesting that if he wants to participate in Bitcoin development today, he can speak for himself. They added that if Satoshi refuses to participate, his opinion is irrelevant. In an email exchange posted on a Bitcoin forum, Prayank objects to ZmnSCPxj's invocation of Satoshi, stating that he cares about Satoshi's opinions, especially regarding subsidies. ZmnSCPxj counters by arguing that if Satoshi refuses to participate in Bitcoin development today, it doesn't matter what his opinion is. He asserts that Satoshi is dead and Bitcoin lives on without him. Prayank objects to this assumption, insisting that Satoshi is more than just a pseudonym and will live on forever. Both parties acknowledge that they are considering the various arguments being presented.In another post, ZmnSCPxj mentions that improvements like the Taproot upgrade can reduce activity on the blockchain and increase functionality without requiring an increase in block size. The Taproot upgrade offers features such as Schnorr multisignatures, MAST, `SIGHASH_ANYPREVOUT`, and `OP_CTV`, which reduce block size usage for complex contracts, enable offchain updateable multiparty cryptocurrency systems, and allow transactional cut-through without immediate output publication. ZmnSCPxj believes that these upgrades enhance Bitcoin's functionality and provide opportunities to use the blockchain in a different way.There is also a discussion about the expansion of use-cases in Ethereum potentially harming Bitcoin by fueling future contentious blocksize debates due to high on-chain fees. However, the counterargument is that fees will be the incentives for miners as subsidy decreases, and it will depend on the demand for block space. Additionally, if this is the reason to stop or delay improvements in Bitcoin, it may apply to Taproot as well. A proposal for a lightning-compatible mimblewimble+dandelion on-chain soft fork is mentioned as a way to reduce transaction size, improve privacy, and move more small transactions off-chain. However, it is suggested that this should not be released for another two years as timing is crucial for Bitcoin innovation.Furthermore, there is a discussion about the lack of compelling use-cases beneficial to all users, with some shared use cases being considered too narrow. The Drivechains use-case is deemed harmful to the security of Bitcoin as a whole. It is argued that the new uses for on-chain transactions mentioned as a use-case could harm existing users by competing for limited blockchain space. As a result, it is concluded that any core consensus changes to the Bitcoin system must be carefully evaluated against the risks.In the Bitcoin developer community, there is a debate about the readiness and potential risks of implementing the proposed consensus change known as OP_CTV. Some developers argue for its activation in a few months, while others express skepticism and call for more testing and research. Other soft fork proposals, such as BIP 118 focusing on eltoo payment channels, are also discussed. Concerns are raised about rushing through consensus changes without thorough examination and community support. Skeptics emphasize the need for technical discussions and engagement to address potential issues. Despite differing opinions, there is a general agreement that implementing a soft fork within the next few months is feasible with proper precautions. The discussion highlights the importance of responsible decision-making and avoiding contentious activation attempts. IRC workshops on BIP 119 are mentioned as a resource for engaging with skeptics on technical concerns. diff --git a/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml b/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml index 912d231f5e..fef6a7a87e 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml @@ -2,7 +2,7 @@ 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2025-09-26T16:03:04.014333+00:00 + 2025-10-11T22:17:11.187930+00:00 python-feedgen Anthony Towns 2022-02-03 06:17:14+00:00 @@ -78,10 +78,11 @@ + 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2025-09-26T16:03:04.014531+00:00 + 2025-10-11T22:17:11.188101+00:00 2022-02-03T06:17:14+00:00 In a recent discussion on the bitcoin-dev mailing list, the topic of enabling covenants in Bitcoin Script was explored. One suggestion involved using the "2 2 CHECKMULTISIG" multisig approach to enforce KYC by requiring funds to be deposited and signed with a government key. The idea of using recursive covenants to create non-terminating computations was also discussed. This concept was originally mentioned in a tweet by Ethan Heilman and later elaborated on in a post by Andrew Poelstra.The discussion also delved into the question of whether Turing completeness should be banned in Bitcoin Script. ZmnSCPxj argued for allowing total Turing-completeness but banning partial Turing-completeness. However, it was acknowledged that banning non-terminating computation for cross-transaction computations would be infeasible. Recursive covenants were identified as a way to write universal computations, and banning source code manipulation would essentially mean banning the manipulation of strings of bytes, which is fundamental to Bitcoin Script.ZmnSCPxj further explained the concept of substructural recursion rules and copattern matching in total functional languages, which ensure termination of recursion. They compared recursive covenants in Bitcoin to codata types in total functional languages, emphasizing the need for Bitcoin SCRIPT to be provably terminating.Jeremy Rubin raised concerns about the potential dangers of evil multisig covenants and the possibility of mining centralization leading to censorship. The discussion also touched on the usefulness of the CSFS opcode and the relationship between OP_CAT and covenants. It was suggested that more direct approaches like OP_TWEAK or UPDATETAPLEAF could be better for implementing covenants.The conversation also addressed the need for separate programs to operate ants and the encoding of state in other parts of the transaction. The idea of adding OP_TWEAK and convenience opcodes for building Taproot Merkle trees was proposed.The discussion on enabling covenants highlighted concerns about transaction and block validation for nodes, ensuring bounded resource requirements and clear evaluation costs. It was noted that while enabling covenants could allow for complex machines that manipulate funds on the blockchain, simple Script programs can be validated and scrutinized to mitigate potential risks. The addition of OP_CHECKSIGFROMSTACK opcode and upper bounds on recursions were suggested as possible solutions.Overall, the discussion emphasized the need for careful consideration of enabling covenants, balancing functionality with validation costs and ensuring the safety and integrity of the Bitcoin network.The ongoing discussion on enabling covenants in Bitcoin has seen arguments against them losing weight as more research is conducted. Multisig wallets alone can enable recursive covenants, such as when a government requires funds to be deposited into a multisig that can only be spent if certain conditions are met. This approach is already being used in permissioned systems like Liquid. While there are ways to escape from recursive covenants, they are not fundamentally different from consensus-enforced covenants. Therefore, multisig-based covenants should be considered in the ongoing discussions about enabling covenants in Bitcoin.Recent research has reduced the weight of arguments against covenants, as AJ's point has further weakened anti-covenant arguments. Multisig alone can enable recursive covenants, as a government can deposit funds into a multisig wallet that requires certain conditions to be met for spending. This process is more efficient than explicit covenants and is already being used in systems like Liquid. The difference between escaping from recursive covenants and consensus-enforced covenants seems to be in procedure and difficulty rather than a fundamental difference.The discussion around enabling covenants is centered on whether OP_CAT should be allowed or not. Multisig wallets can enable recursive covenants, as a government can require funds to be deposited into a multisig that follows certain rules. This approach is already used by Liquid and BTC-on-Ethereum tokens. Escaping from this type of recursive covenant would require a change in signing policy. However, escaping any consensus-enforced covenant would require a hard fork. This difference seems to be more procedural and difficulty-based.Russell O'Connor raised concerns about recursive covenants and the implications of enabling OP_CAT. He initially suggested that such worries should be left for OP_TWEAK, but later acknowledged that recursive covenants could still be created by sneaking state into UTXO amounts or sibling outputs accessed via txid. This highlights the importance of avoiding giving too much power. However, altcoins already exist and some are worse, making full EVM support possible.In an email thread, Russell O'Connor discussed the topic of enabling covenants, specifically recursive covenants that require OP_TWEAK. He expressed concern about simulating this operation with CHECKSIG(FROMSTACK), but later noted that recursive covenants could still be created using a fixed scriptpubkey by sneaking state into UTXO amounts or sibling outputs accessed via txid diff --git a/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml b/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml index 7a0a672ea3..c3bb593517 100644 --- a/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml +++ b/static/bitcoin-dev/Feb_2022/combined_Why-CTV-why-now-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Why CTV, why now? - 2025-09-26T16:03:01.899312+00:00 + 2025-10-11T22:17:09.065467+00:00 python-feedgen Jeremy Rubin 2022-02-02 01:43:38+00:00 @@ -14,10 +14,11 @@ + 2 Combined summary - Why CTV, why now? - 2025-09-26T16:03:01.899469+00:00 + 2025-10-11T22:17:09.065625+00:00 2022-02-02T01:43:38+00:00 Anthony Towns shared a script template on the Bitcoin-dev mailing list that can be used to simulate CTV (Covenants) on the Liquid blockchain using new element opcodes. Although this approach is less efficient than having a dedicated opcode, it can be effective for many useful applications. The script template involves several INSPECT and SHA256 opcodes, which are used to determine the spending transaction's txid.If the NUMINPUTS is greater than one, there is a need to limit the usage of other inputs, which would be specific to the application being developed. Anthony believes that this emulation might be compatible with confidential assets/values but is uncertain. He also suggests that a similar approach using CHECKSIGFROMSTACK instead of "EQUAL" could be used to construct APO-style signatures on elements/liquid. However, he advises wrapping the output inspection blocks with "INSPECTNUMOUTPUTS GREATERTHAN IF .. ENDIF" and starting with "PUSH[FakeAPOSig] SHA256 DUP SHA256INITIALIZE SHA256UPDATE" to avoid potential misuse in a different context.Anthony notes that the Liquid network, which currently has approximately $120M worth of BTC and $36M worth of USDT, is not congested and does not have many lightning channels built on top of it. As a result, the vaulting application appears to be the most interesting one to build on top of Liquid at present. This suggests that there may be a justification for exploring vault-related work on the Liquid blockchain. Real experience with CTV-like constructs is expected to provide valuable insights.On January 5th, Jeremy via bitcoin-dev proposed CTV as a simple covenant type with minimal validation burdens. It is designed to offer simplicity, flexibility, and power for building various useful applications. The new element opcodes make it possible to simulate CTV on the Liquid blockchain or liquid-testnet if fake money is preferred. While the script template provided in the context is not as efficient as a dedicated opcode, it can still be used when NUMINPUTS is one. In this case, the txid of the spending transaction is fixed due to taproot-only opcodes and the absence of scriptSig malleability. diff --git a/static/bitcoin-dev/Feb_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Feb_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 82c0ca0a4a..c74ddaa5c6 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -2,7 +2,7 @@ 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:36:07.411732+00:00 + 2025-10-11T22:10:44.389745+00:00 python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -81,10 +81,11 @@ + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:36:07.411900+00:00 + 2025-10-11T22:10:44.389910+00:00 2023-03-13T16:38:25+00:00 On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to diff --git a/static/bitcoin-dev/Feb_2023/combined_Pseudocode-for-robust-tail-emission.xml b/static/bitcoin-dev/Feb_2023/combined_Pseudocode-for-robust-tail-emission.xml index 891406feae..e6a0d2956b 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Pseudocode-for-robust-tail-emission.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Pseudocode-for-robust-tail-emission.xml @@ -2,7 +2,7 @@ 2 Combined summary - Pseudocode for robust tail emission - 2025-09-26T14:36:13.844578+00:00 + 2025-10-11T22:10:46.513493+00:00 python-feedgen jk_14 at op.pl 2023-02-01 22:04:11+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - Pseudocode for robust tail emission - 2025-09-26T14:36:13.844786+00:00 + 2025-10-11T22:10:46.513689+00:00 2023-02-01T22:04:11+00:00 In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the diff --git a/static/bitcoin-dev/Feb_2023/combined_Purely-off-chain-coin-colouring.xml b/static/bitcoin-dev/Feb_2023/combined_Purely-off-chain-coin-colouring.xml index c843769b1d..a800f5fa30 100644 --- a/static/bitcoin-dev/Feb_2023/combined_Purely-off-chain-coin-colouring.xml +++ b/static/bitcoin-dev/Feb_2023/combined_Purely-off-chain-coin-colouring.xml @@ -2,7 +2,7 @@ 2 Combined summary - Purely off-chain coin colouring - 2025-09-26T14:35:58.851847+00:00 + 2025-10-11T22:10:42.253453+00:00 python-feedgen vjudeu at gazeta.pl 2023-11-20 19:47:13+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - Purely off-chain coin colouring - 2025-09-26T14:35:58.851995+00:00 + 2025-10-11T22:10:42.253623+00:00 2023-11-20T19:47:13+00:00 Blockchain standardization is a key topic, with suggestions to treat signature R-values as Taproot-based public keys for consistent protocol interpretation. Another approach proposes using commitments that can push any data and nest future commitments within previous ones, ensuring they remain off-chain by starting with OP_RETURN and expressing r-values as 256-bit numbers. diff --git a/static/bitcoin-dev/Jan_2012/combined_All-pre-BIP-BIPs-are-not-valid.xml b/static/bitcoin-dev/Jan_2012/combined_All-pre-BIP-BIPs-are-not-valid.xml index 3502c03cde..75379551ec 100644 --- a/static/bitcoin-dev/Jan_2012/combined_All-pre-BIP-BIPs-are-not-valid.xml +++ b/static/bitcoin-dev/Jan_2012/combined_All-pre-BIP-BIPs-are-not-valid.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - All pre-BIP BIPs are not valid - 2023-08-01T02:55:40.884994+00:00 + 2025-10-11T21:59:07.002538+00:00 + python-feedgen Luke-Jr 2012-01-29 23:10:30+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - All pre-BIP BIPs are not valid - 2023-08-01T02:55:40.885970+00:00 + 2025-10-11T21:59:07.002685+00:00 - In a discussion on Bitcoin Improvement Proposals (BIPs), there was a disagreement about the status of BIP 20. Amir Taaki argued that BIP 20 was not accepted as final a year ago, despite Luke Dashjr's assertion to the contrary. Taaki claimed that a BIP needs to go through formalized motions in public before becoming accepted and that the URI Scheme, which BIP 20 is based on, did not go through these motions. He also mentioned that at least two implementations have objected to the standard as it is. Taaki stated that he did not know it was even accepted and invited others to submit a competing BIP to Luke's BIP 20.Matt Corallo, who was part of the discussion, agreed with Luke and pointed out that the version that was agreed upon can be seen on the Bitcoin Wiki page. He also provided links to three biased polls conducted by Luke on the Bitcointalk forum for further reference.The discussion revolved around whether BIP 20 was accepted as final a year ago. While Luke Dashjr argued that there was a consensus and multiple implementations for BIP 20 in early 2011, Amir Taaki disagreed, stating that it did not go through the proper procedures and lacked consensus-building. Taaki believed that no BIP existed before the formalized BIP process, and new BIPs are always in draft status until they meet the conditions specified in BIP 0001.Despite their disagreement, both Dashjr and Taaki agreed that it is important to focus on actual forward progress. They acknowledged that anyone can submit a competing BIP to supersede BIP 20, similar to what happened with BIP 16 and 17. The discussion highlighted conflicting views on the acceptance and status of BIP 20 and emphasized the importance of following the proper procedures in the BIP process. 2012-01-29T23:10:30+00:00 + In a discussion on Bitcoin Improvement Proposals (BIPs), there was a disagreement about the status of BIP 20. Amir Taaki argued that BIP 20 was not accepted as final a year ago, despite Luke Dashjr's assertion to the contrary. Taaki claimed that a BIP needs to go through formalized motions in public before becoming accepted and that the URI Scheme, which BIP 20 is based on, did not go through these motions. He also mentioned that at least two implementations have objected to the standard as it is. Taaki stated that he did not know it was even accepted and invited others to submit a competing BIP to Luke's BIP 20.Matt Corallo, who was part of the discussion, agreed with Luke and pointed out that the version that was agreed upon can be seen on the Bitcoin Wiki page. He also provided links to three biased polls conducted by Luke on the Bitcointalk forum for further reference.The discussion revolved around whether BIP 20 was accepted as final a year ago. While Luke Dashjr argued that there was a consensus and multiple implementations for BIP 20 in early 2011, Amir Taaki disagreed, stating that it did not go through the proper procedures and lacked consensus-building. Taaki believed that no BIP existed before the formalized BIP process, and new BIPs are always in draft status until they meet the conditions specified in BIP 0001.Despite their disagreement, both Dashjr and Taaki agreed that it is important to focus on actual forward progress. They acknowledged that anyone can submit a competing BIP to supersede BIP 20, similar to what happened with BIP 16 and 17. The discussion highlighted conflicting views on the acceptance and status of BIP 20 and emphasized the importance of following the proper procedures in the BIP process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_Alternative-to-OP-EVAL.xml b/static/bitcoin-dev/Jan_2012/combined_Alternative-to-OP-EVAL.xml index 995e218ad5..4991b2f81c 100644 --- a/static/bitcoin-dev/Jan_2012/combined_Alternative-to-OP-EVAL.xml +++ b/static/bitcoin-dev/Jan_2012/combined_Alternative-to-OP-EVAL.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Alternative to OP_EVAL - 2023-08-01T02:48:45.314516+00:00 + 2025-10-11T21:58:45.740394+00:00 + python-feedgen Stefan Thomas 2012-01-02 17:10:25+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Alternative to OP_EVAL - 2023-08-01T02:48:45.314516+00:00 + 2025-10-11T21:58:45.740571+00:00 - A proposal has been made to create a new transaction type called "pay to Script hash" that allows users to publish a short "funding address" that is the hash of an arbitrary redemption script. The proposal aims to implement this in a backward-compatible-in-the-blockchain way. It is considered a cleaner and more straightforward implementation than the previous proposal, OP_EVAL. Clients/miners will recognize this new transaction type and do additional validation.There was some discussion on whether to make the script: OP_NOP1 HASH160 EQUAL to make it easier to identify as a special transaction but the consensus was that every byte matters and code replacement would be more common. Overall, it is considered a cleaner and more straightforward implementation than OP_EVAL with no special cases.The proposal suggests making two amendments to the script. First, make the script: OP_NOP1 HASH160 EQUAL to make it extremely easy to see from the first byte that this is very likely to be a special transaction. Second, if you feel like spending another byte, make the script: OP_NOP1 and assign 1 to this special script, making this case: OP_NOP1 OP_1 HASH160 EQUAL. This proposal is cleaner than OP_EVAL and more straightforward to implement.The current proposal eliminates the static analysis properties in Bitcoin, as it can stand for any number of operations, which might be part of some piece of data and change the script that is executed by OP_EVAL at runtime. However, proponents argue that it is possible to "dry run" the script, avoiding the expensive OP_CHECKSIG operation and running only the other very cheap operations. But a dry runner cannot predict the outcome of conditional branches in the presence of an OP_CHECKSIG, so it has to either do the OP_CHECKSIG or follow both branches. This makes it too complicated to involve the protocol rules such as the sigops limit. Several proposals for OP_EVAL that allow static analysis have been suggested, such as using a fixed position reference prefix, using an execute bit on data set by an opcode, using OP_CODEHASH, using OP_CHECKEDEVAL, and using OP_HASH160 OP_EQUALVERIFY as a special sigPubKey.In a discussion about the Bitcoin script language, Joel Joonatan Kaartinen suggested restricting the number of executions of OP_EVAL allowed per transaction to prevent unlimited looping. However, roconnor at theorem.ca warned that OP_EVAL adds dangerously expressive power to the scripting language. The addition of OP_EVAL made the script language essentially Turing complete, with only an artificial limit on recursion depth preventing arbitrary computation. Despite the potential for expressive power, some consider OP_EVAL to be dangerous.In an email conversation, a person explains the significance of OP_DUP in creating looping operations and achieving Turing completeness. They also suggest that using stack operations, one can implement the SK-calculus given an OP_EVAL that allows arbitrary depth. The writer mentions the concatenative programming mailing list where people create stack languages with minimal operations that exploit similar functionality to reduce the required built-in operations. The discussion on the list is mostly about stack-based languages where programs can be pushed on the stack and executed. However, they question whether the scripting engine in bitcoin has the ability to manipulate scripts on the stack to be evaluated.In an email thread discussing alternative proposals to OP_EVAL, Alan warns against the potential consequences of injecting new, powerful functionality into over 50% of the nodes on the Bitcoin network. He suggests considering the recovery path of unanticipated problems and warns against opening up a hole that could allow someone to satisfy arbitrary scripts or create one-packet DoS/crash attacks. Alan proposes leaning towards a more conservative solution such as sandboxing the sub-scripting engine.In response to Gavin's request for an alternative to OP_EVAL, Pieter offers his proposal for OP_CHECKEDEVAL. He explains its specifications, advantages, and disadvantages. The proposal guarantees backward compatibility and static code analysis but disallows dynamic interaction with serialized scripts.In this email thread, the discussion revolves around the rollout of OP_EVAL on the Bitcoin network. The concern is that delaying the rollout may encourage people to postpone thoroughly reviewing and testing for a couple of months, leading to delays. It is suggested that OP_EVAL should first be released on testnet to build real-life applications and adjust it if issues arise before deploying it on mainnet. There is also a conversation about static analysis and how miners may want to do more static analysis besides standard transaction types. However, until someone smarter than Gavin Andresen has done a deep analysis of Script and all of its opcodes, the standard transaction types and the standard types extended with OP_EVAL are easy to reason about. In practice, it is not believed that EVAL as proposed is a danger. Finally, there is a discussion about rolling out just BIP 11 (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and delaying EVAL rollout on the main network.On December 29, 2011, a discussion took 2012-01-02T17:10:25+00:00 + A proposal has been made to create a new transaction type called "pay to Script hash" that allows users to publish a short "funding address" that is the hash of an arbitrary redemption script. The proposal aims to implement this in a backward-compatible-in-the-blockchain way. It is considered a cleaner and more straightforward implementation than the previous proposal, OP_EVAL. Clients/miners will recognize this new transaction type and do additional validation.There was some discussion on whether to make the script: OP_NOP1 HASH160 EQUAL to make it easier to identify as a special transaction but the consensus was that every byte matters and code replacement would be more common. Overall, it is considered a cleaner and more straightforward implementation than OP_EVAL with no special cases.The proposal suggests making two amendments to the script. First, make the script: OP_NOP1 HASH160 EQUAL to make it extremely easy to see from the first byte that this is very likely to be a special transaction. Second, if you feel like spending another byte, make the script: OP_NOP1 and assign 1 to this special script, making this case: OP_NOP1 OP_1 HASH160 EQUAL. This proposal is cleaner than OP_EVAL and more straightforward to implement.The current proposal eliminates the static analysis properties in Bitcoin, as it can stand for any number of operations, which might be part of some piece of data and change the script that is executed by OP_EVAL at runtime. However, proponents argue that it is possible to "dry run" the script, avoiding the expensive OP_CHECKSIG operation and running only the other very cheap operations. But a dry runner cannot predict the outcome of conditional branches in the presence of an OP_CHECKSIG, so it has to either do the OP_CHECKSIG or follow both branches. This makes it too complicated to involve the protocol rules such as the sigops limit. Several proposals for OP_EVAL that allow static analysis have been suggested, such as using a fixed position reference prefix, using an execute bit on data set by an opcode, using OP_CODEHASH, using OP_CHECKEDEVAL, and using OP_HASH160 OP_EQUALVERIFY as a special sigPubKey.In a discussion about the Bitcoin script language, Joel Joonatan Kaartinen suggested restricting the number of executions of OP_EVAL allowed per transaction to prevent unlimited looping. However, roconnor at theorem.ca warned that OP_EVAL adds dangerously expressive power to the scripting language. The addition of OP_EVAL made the script language essentially Turing complete, with only an artificial limit on recursion depth preventing arbitrary computation. Despite the potential for expressive power, some consider OP_EVAL to be dangerous.In an email conversation, a person explains the significance of OP_DUP in creating looping operations and achieving Turing completeness. They also suggest that using stack operations, one can implement the SK-calculus given an OP_EVAL that allows arbitrary depth. The writer mentions the concatenative programming mailing list where people create stack languages with minimal operations that exploit similar functionality to reduce the required built-in operations. The discussion on the list is mostly about stack-based languages where programs can be pushed on the stack and executed. However, they question whether the scripting engine in bitcoin has the ability to manipulate scripts on the stack to be evaluated.In an email thread discussing alternative proposals to OP_EVAL, Alan warns against the potential consequences of injecting new, powerful functionality into over 50% of the nodes on the Bitcoin network. He suggests considering the recovery path of unanticipated problems and warns against opening up a hole that could allow someone to satisfy arbitrary scripts or create one-packet DoS/crash attacks. Alan proposes leaning towards a more conservative solution such as sandboxing the sub-scripting engine.In response to Gavin's request for an alternative to OP_EVAL, Pieter offers his proposal for OP_CHECKEDEVAL. He explains its specifications, advantages, and disadvantages. The proposal guarantees backward compatibility and static code analysis but disallows dynamic interaction with serialized scripts.In this email thread, the discussion revolves around the rollout of OP_EVAL on the Bitcoin network. The concern is that delaying the rollout may encourage people to postpone thoroughly reviewing and testing for a couple of months, leading to delays. It is suggested that OP_EVAL should first be released on testnet to build real-life applications and adjust it if issues arise before deploying it on mainnet. There is also a conversation about static analysis and how miners may want to do more static analysis besides standard transaction types. However, until someone smarter than Gavin Andresen has done a deep analysis of Script and all of its opcodes, the standard transaction types and the standard types extended with OP_EVAL are easy to reason about. In practice, it is not believed that EVAL as proposed is a danger. Finally, there is a discussion about rolling out just BIP 11 (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and delaying EVAL rollout on the main network.On December 29, 2011, a discussion took - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_BIP-0020-URI-Scheme.xml b/static/bitcoin-dev/Jan_2012/combined_BIP-0020-URI-Scheme.xml index fb5365239f..d5cd0ca894 100644 --- a/static/bitcoin-dev/Jan_2012/combined_BIP-0020-URI-Scheme.xml +++ b/static/bitcoin-dev/Jan_2012/combined_BIP-0020-URI-Scheme.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 0020: URI Scheme - 2023-08-01T02:54:45.607408+00:00 + 2025-10-11T21:58:54.242166+00:00 + python-feedgen Andreas Schildbach 2012-01-28 16:32:15+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP 0020: URI Scheme - 2023-08-01T02:54:45.607408+00:00 + 2025-10-11T21:58:54.242372+00:00 - In a forum post from January 2012, it was noted that Bitcoin Improvement Proposal (BIP) 21 had already been implemented in many clients throughout 2011. However, Bitcoin-Qt was lagging behind and considered not relevant. Bitcoin Wallet for Android only implemented parts of the specification, leaving out certain notations and parameters. The "send" feature was also not yet implemented.A discussion about Bitcoin transactions took place, with Wladimir stating that the subset implemented by bitcoin-qt allows for the description of all desirable transactions. He argued that the rest of the specification is redundant and unnecessary. Luke-Jr mentioned that the version on the wiki for BIP 20 contained extraneous information not implemented in Bitcoin-Qt. Wladimir declined to reopen the debate, citing a biased poll and lack of links to Luke-Jr's version.On the Bitcoin mailing list, there was a discussion about the implementation of BIP 20, a proposal for a uniform payment protocol. The original poster claimed that BIP 20 had been implemented in many Bitcoin clients since 2011 and had recently been added to Bitcoin-Qt for system URI handling. Another participant disagreed, stating that the version on the wiki had extraneous information and was not implemented in Bitcoin-Qt due to a vote against it during the specification process. The original poster responded by accusing the other participant of losing a biased poll and claimed that there were no links to their version of BIP 20.A member of the bitcoin-list at bluematt.me mentioned that Bitcoin-Qt had implemented drag-and-drop and system URI handling, but this was not new as many clients had already done so in 2011. They also pointed out that the version of BIP 20 on the wiki contained extraneous information that was voted against during the specification process.BIP 20, an old URI scheme, had been finalized according to BIP 1 standards in late January 2011. However, the version on the wiki included unnecessary information that was explicitly voted against during the specification process. Amir Taaki suggested revisiting the URI scheme for revision and eventually moving BIP 20 to replaced/superseded status after P2SH is deployed.Amir Taaki mentioned that BIP 0020, an old URI scheme, had been given draft status, although it had already been finalized according to BIP 1 standards since late January 2011. He proposed revisiting the URI scheme for revision once P2SH is deployed and eventually replacing or superseding BIP 20.BIP 0020, the old URI scheme, is currently in draft status. The decision to move it to accepted status or not is unclear, as there was a discussion last year that the speaker does not have enough information about. However, the speaker believes that having a re-decision on the matter is healthy, even if it was accepted last year, as it is important to have a standardization process before having a standard. BIP 0020 remains in draft status until there is a general agreement. 2012-01-28T16:32:15+00:00 + In a forum post from January 2012, it was noted that Bitcoin Improvement Proposal (BIP) 21 had already been implemented in many clients throughout 2011. However, Bitcoin-Qt was lagging behind and considered not relevant. Bitcoin Wallet for Android only implemented parts of the specification, leaving out certain notations and parameters. The "send" feature was also not yet implemented.A discussion about Bitcoin transactions took place, with Wladimir stating that the subset implemented by bitcoin-qt allows for the description of all desirable transactions. He argued that the rest of the specification is redundant and unnecessary. Luke-Jr mentioned that the version on the wiki for BIP 20 contained extraneous information not implemented in Bitcoin-Qt. Wladimir declined to reopen the debate, citing a biased poll and lack of links to Luke-Jr's version.On the Bitcoin mailing list, there was a discussion about the implementation of BIP 20, a proposal for a uniform payment protocol. The original poster claimed that BIP 20 had been implemented in many Bitcoin clients since 2011 and had recently been added to Bitcoin-Qt for system URI handling. Another participant disagreed, stating that the version on the wiki had extraneous information and was not implemented in Bitcoin-Qt due to a vote against it during the specification process. The original poster responded by accusing the other participant of losing a biased poll and claimed that there were no links to their version of BIP 20.A member of the bitcoin-list at bluematt.me mentioned that Bitcoin-Qt had implemented drag-and-drop and system URI handling, but this was not new as many clients had already done so in 2011. They also pointed out that the version of BIP 20 on the wiki contained extraneous information that was voted against during the specification process.BIP 20, an old URI scheme, had been finalized according to BIP 1 standards in late January 2011. However, the version on the wiki included unnecessary information that was explicitly voted against during the specification process. Amir Taaki suggested revisiting the URI scheme for revision and eventually moving BIP 20 to replaced/superseded status after P2SH is deployed.Amir Taaki mentioned that BIP 0020, an old URI scheme, had been given draft status, although it had already been finalized according to BIP 1 standards since late January 2011. He proposed revisiting the URI scheme for revision once P2SH is deployed and eventually replacing or superseding BIP 20.BIP 0020, the old URI scheme, is currently in draft status. The decision to move it to accepted status or not is unclear, as there was a discussion last year that the speaker does not have enough information about. However, the speaker believes that having a re-decision on the matter is healthy, even if it was accepted last year, as it is important to have a standardization process before having a standard. BIP 0020 remains in draft status until there is a general agreement. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_BIP-12-16-17.xml b/static/bitcoin-dev/Jan_2012/combined_BIP-12-16-17.xml index a086d056cf..e4c21dd4e5 100644 --- a/static/bitcoin-dev/Jan_2012/combined_BIP-12-16-17.xml +++ b/static/bitcoin-dev/Jan_2012/combined_BIP-12-16-17.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP-12, 16, 17 - 2023-08-01T02:54:58.059374+00:00 + 2025-10-11T21:58:41.479474+00:00 + python-feedgen Andy Parkins 2012-01-30 10:57:54+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP-12, 16, 17 - 2023-08-01T02:54:58.059374+00:00 + 2025-10-11T21:58:41.479629+00:00 - In January 2012, Dr. Andy Parkins proposed the idea of adding more information to a Bitcoin address by cannibalizing its checksum. This proposal aims to prevent users from mistaking two different addresses and creating non-redeemable transactions. The base58 encoding used for Bitcoin addresses has spare capacity, as the longest address is converted into 34 symbols. However, there are still unused bits available that can be added without changing the number of symbols in the address.While this proposal is an idea, it may not be feasible or beneficial. The author of the message is addressing Bitcoiners and discussing various BIP (Bitcoin Improvement Proposal) suggestions for enabling multisignature transactions. However, they express frustration that the discussion is happening in multiple forums and IRC channels.The author presents some issues with BIP-16, specifically lines 265-269 in the reference implementation. They argue that this implementation breaks the purpose of the network ID by tying additional information into an address as a hack. In their previous argument for BIP-12 implementation, they expressed that this notification on an address level is not necessary and should not be introduced.Instead, the author suggests cannibalizing more information from the checksum if additional information is needed in a Bitcoin address. Currently, the checksum is four bytes, but it could be reduced to two or three bytes without affecting the current meaning of the network ID. This approach would achieve the same goal of preventing mistaken addresses and non-redeemable transactions.Although the author sees BIP-17 as a step forward, they agree with Gavin's note on one of the forums that it behaves differently in input and output scripts, indicating that further work is needed. 2012-01-30T10:57:54+00:00 + In January 2012, Dr. Andy Parkins proposed the idea of adding more information to a Bitcoin address by cannibalizing its checksum. This proposal aims to prevent users from mistaking two different addresses and creating non-redeemable transactions. The base58 encoding used for Bitcoin addresses has spare capacity, as the longest address is converted into 34 symbols. However, there are still unused bits available that can be added without changing the number of symbols in the address.While this proposal is an idea, it may not be feasible or beneficial. The author of the message is addressing Bitcoiners and discussing various BIP (Bitcoin Improvement Proposal) suggestions for enabling multisignature transactions. However, they express frustration that the discussion is happening in multiple forums and IRC channels.The author presents some issues with BIP-16, specifically lines 265-269 in the reference implementation. They argue that this implementation breaks the purpose of the network ID by tying additional information into an address as a hack. In their previous argument for BIP-12 implementation, they expressed that this notification on an address level is not necessary and should not be introduced.Instead, the author suggests cannibalizing more information from the checksum if additional information is needed in a Bitcoin address. Currently, the checksum is four bytes, but it could be reduced to two or three bytes without affecting the current meaning of the network ID. This approach would achieve the same goal of preventing mistaken addresses and non-redeemable transactions.Although the author sees BIP-17 as a step forward, they agree with Gavin's note on one of the forums that it behaves differently in input and output scripts, indicating that further work is needed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_BIP-20-Rejected-process-for-BIP-21N.xml b/static/bitcoin-dev/Jan_2012/combined_BIP-20-Rejected-process-for-BIP-21N.xml index cf72ff0f8a..286ef4075b 100644 --- a/static/bitcoin-dev/Jan_2012/combined_BIP-20-Rejected-process-for-BIP-21N.xml +++ b/static/bitcoin-dev/Jan_2012/combined_BIP-20-Rejected-process-for-BIP-21N.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 20 Rejected, process for BIP 21N - 2023-08-01T02:58:12.134772+00:00 + 2025-10-11T21:58:43.614418+00:00 + python-feedgen Matt Corallo 2012-02-04 17:15:02+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - BIP 20 Rejected, process for BIP 21N - 2023-08-01T02:58:12.135763+00:00 + 2025-10-11T21:58:43.614595+00:00 - In 2012, a discussion took place between Amir Taaki and slush on the Bitcoin-development mailing list regarding the use of satoshis instead of decimal bitcoin for BIP 21. Slush proposed using satoshis due to the difficulty of handling decimal numbers across different implementations. However, Amir argued against this idea, emphasizing that decimal numbers are widely used in HTML, URI, and other standards, and breaking with tradition would cause confusion. He also pointed out that BIP 20, which had no support from popular implementations like Bitcoin-Qt, Electrum, MultiBit, and Bitcoin-JS, was incompatible with most web standards. Therefore, he recommended rejecting BIP 20 and reaching a consensus among developers for a new standard for BIP 21.The lack of support for BIP 20 among popular implementations, especially those involving GUI projects with URI Scheme, carries significant weight in decision-making. Although Bitcoin-Qt has a majority of users, relying solely on this fact is discouraged. Instead of accepting BIP 21, which is essentially a copy of BIP 20 with some sections missing, it is suggested to reject it and establish a new standard. However, since BIP 21 is still in draft form, it is proposed that developers agree on something and present it to BlueMatt for consideration as the new BIP 21.Consensus seems to be forming on most aspects of the proposal, apart from the contentious issue of sending private keys. Furthermore, there is a discussion about including a time-to-expire field for merchants, which is seen as a beneficial idea. One of the problems with BIP 20 is its incompatibility with various web standards, such as HTML and URI, which exclusively use decimal numbers. Breaking from this convention is deemed unnecessary. While Amir acknowledges his personal preference for British English, he highlights that American English is the international standard and adherence to it is essential for consistency. Although it would be ideal if all code used a universal language like Esperanto, the reality is that we live in a world where decimals, English, Windows, and religious beliefs prevail.Overall, Amir discourages breaking with convention and suggests that developers agree on a new standard for BIP 21 through consensus-building and discussion. 2012-02-04T17:15:02+00:00 + In 2012, a discussion took place between Amir Taaki and slush on the Bitcoin-development mailing list regarding the use of satoshis instead of decimal bitcoin for BIP 21. Slush proposed using satoshis due to the difficulty of handling decimal numbers across different implementations. However, Amir argued against this idea, emphasizing that decimal numbers are widely used in HTML, URI, and other standards, and breaking with tradition would cause confusion. He also pointed out that BIP 20, which had no support from popular implementations like Bitcoin-Qt, Electrum, MultiBit, and Bitcoin-JS, was incompatible with most web standards. Therefore, he recommended rejecting BIP 20 and reaching a consensus among developers for a new standard for BIP 21.The lack of support for BIP 20 among popular implementations, especially those involving GUI projects with URI Scheme, carries significant weight in decision-making. Although Bitcoin-Qt has a majority of users, relying solely on this fact is discouraged. Instead of accepting BIP 21, which is essentially a copy of BIP 20 with some sections missing, it is suggested to reject it and establish a new standard. However, since BIP 21 is still in draft form, it is proposed that developers agree on something and present it to BlueMatt for consideration as the new BIP 21.Consensus seems to be forming on most aspects of the proposal, apart from the contentious issue of sending private keys. Furthermore, there is a discussion about including a time-to-expire field for merchants, which is seen as a beneficial idea. One of the problems with BIP 20 is its incompatibility with various web standards, such as HTML and URI, which exclusively use decimal numbers. Breaking from this convention is deemed unnecessary. While Amir acknowledges his personal preference for British English, he highlights that American English is the international standard and adherence to it is essential for consistency. Although it would be ideal if all code used a universal language like Esperanto, the reality is that we live in a world where decimals, English, Windows, and religious beliefs prevail.Overall, Amir discourages breaking with convention and suggests that developers agree on a new standard for BIP 21 through consensus-building and discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_BIP-21-modification-BIP-20-.xml b/static/bitcoin-dev/Jan_2012/combined_BIP-21-modification-BIP-20-.xml index dc78c55a3d..c973115884 100644 --- a/static/bitcoin-dev/Jan_2012/combined_BIP-21-modification-BIP-20-.xml +++ b/static/bitcoin-dev/Jan_2012/combined_BIP-21-modification-BIP-20-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 21 (modification BIP 20) - 2023-08-01T02:56:29.300010+00:00 + 2025-10-11T21:59:02.753272+00:00 + python-feedgen Cameron Garnham 2012-01-31 13:20:10+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - BIP 21 (modification BIP 20) - 2023-08-01T02:56:29.300010+00:00 + 2025-10-11T21:59:02.753504+00:00 - In a series of email conversations in 2012, various aspects of the Bitcoin Improvement Proposal (BIP) 21 and BIP 20 are discussed. Gavin Andresen expresses his preference for BIP 21, stating that "simpler is better." He also supports the idea of signing and dating URIs but suggests waiting for consensus around BIP 21 before pursuing it.The discussion revolves around the treatment of unknown URL parameters and the need for future backward-compatible changes.Wladimir believes that unknown URL parameters should be ignored, as this is standard practice, but acknowledges that certain parameters may need to be refused to maintain compatibility. Gary Rowe and Pieter agree that simplicity is best, with Rowe suggesting that the "expires" field is more important than a block number. They discuss the need for defining standards upfront and the inclusion of optional fields in BIP 21.The discussion also touches on the 'send' parameter and the 'version' parameter in BIP 21, with questions raised about their practical use and how clients should handle them. The email exchange includes proposals, modifications, and opinions from various individuals, including Matt Corallo, Andreas Schildbach, Amir Taaki, and Luke-Jr.The concept of a signed URI is discussed as a way to protect consumers against fraudulent sellers. However, concerns are raised about the potential for attackers to replace the URI with their own fraudulent address. The MultiBit team proposes adding an "expires" field to the BIP 21 proposal to allow merchants to issue Bitcoin URIs with a defined expiration period.The email exchanges also mention the differences between BIP 20 and BIP 21, with Gary Rowe arguing that BIP 21 reduces complexity for end clients. There is a debate about the representation of the "amount" field in Bitcoin transactions, with BIP 21 requiring decimal notation while BIP 20 allows alternative representations. The MultiBit team expresses support for BIP 21 and clarifies that they will not be supporting Tonal Bitcoins.The discussions highlight the need for practical use cases, clarity in parameter definitions, and forward compatibility in BIPs. The email exchanges include links to forum posts and websites for further information on proposals and modifications.Matt Corallo has proposed a modification to BIP 20, which removes the non-decimal number related components. The modification can be found on the Bitcoin wiki page for BIP 0021. In an email, the author is being requested to become a champion for the submitted BIP.At present, GUI client implementations such as MultiBit or Bitcoin-Qt are being queried about their support for either BIP 20 or BIP 21. GUIs that have implemented the URI scheme are given more importance in this evaluation process. The objective is to establish a general consensus regarding the preferred BIP. Any objections to this approach are welcomed.In addition to the discussion on BIP support, the email also includes an advertisement for an online learning library for Microsoft developers. 2012-01-31T13:20:10+00:00 + In a series of email conversations in 2012, various aspects of the Bitcoin Improvement Proposal (BIP) 21 and BIP 20 are discussed. Gavin Andresen expresses his preference for BIP 21, stating that "simpler is better." He also supports the idea of signing and dating URIs but suggests waiting for consensus around BIP 21 before pursuing it.The discussion revolves around the treatment of unknown URL parameters and the need for future backward-compatible changes.Wladimir believes that unknown URL parameters should be ignored, as this is standard practice, but acknowledges that certain parameters may need to be refused to maintain compatibility. Gary Rowe and Pieter agree that simplicity is best, with Rowe suggesting that the "expires" field is more important than a block number. They discuss the need for defining standards upfront and the inclusion of optional fields in BIP 21.The discussion also touches on the 'send' parameter and the 'version' parameter in BIP 21, with questions raised about their practical use and how clients should handle them. The email exchange includes proposals, modifications, and opinions from various individuals, including Matt Corallo, Andreas Schildbach, Amir Taaki, and Luke-Jr.The concept of a signed URI is discussed as a way to protect consumers against fraudulent sellers. However, concerns are raised about the potential for attackers to replace the URI with their own fraudulent address. The MultiBit team proposes adding an "expires" field to the BIP 21 proposal to allow merchants to issue Bitcoin URIs with a defined expiration period.The email exchanges also mention the differences between BIP 20 and BIP 21, with Gary Rowe arguing that BIP 21 reduces complexity for end clients. There is a debate about the representation of the "amount" field in Bitcoin transactions, with BIP 21 requiring decimal notation while BIP 20 allows alternative representations. The MultiBit team expresses support for BIP 21 and clarifies that they will not be supporting Tonal Bitcoins.The discussions highlight the need for practical use cases, clarity in parameter definitions, and forward compatibility in BIPs. The email exchanges include links to forum posts and websites for further information on proposals and modifications.Matt Corallo has proposed a modification to BIP 20, which removes the non-decimal number related components. The modification can be found on the Bitcoin wiki page for BIP 0021. In an email, the author is being requested to become a champion for the submitted BIP.At present, GUI client implementations such as MultiBit or Bitcoin-Qt are being queried about their support for either BIP 20 or BIP 21. GUIs that have implemented the URI scheme are given more importance in this evaluation process. The objective is to establish a general consensus regarding the preferred BIP. Any objections to this approach are welcomed.In addition to the discussion on BIP support, the email also includes an advertisement for an online learning library for Microsoft developers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_BIP-Submission.xml b/static/bitcoin-dev/Jan_2012/combined_BIP-Submission.xml index a51ccef376..ba8796c6c3 100644 --- a/static/bitcoin-dev/Jan_2012/combined_BIP-Submission.xml +++ b/static/bitcoin-dev/Jan_2012/combined_BIP-Submission.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Submission - 2023-08-01T02:53:41.914817+00:00 + 2025-10-11T21:59:11.263009+00:00 + python-feedgen Gavin Andresen 2012-01-16 21:22:54+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP Submission - 2023-08-01T02:53:41.914817+00:00 + 2025-10-11T21:59:11.263143+00:00 - During a discussion about the OP_ADD function in Bitcoin, it has come to light that the function has a limitation of only allowing 4-byte operands. Any changes to this limitation would require either a hard blockchain split or an entire network upgrade. In response to this limitation, user Ben Reeves has submitted a draft Bitcoin Improvement Proposal (BIP).This proposed BIP serves as an alternative to BIP 16, also known as "/P2SH/". Reeves has named his draft "BIP M of 2 DRAFT", and it is available for review on the Bitcoin Wiki page. In order to gather feedback and comments from the community, Reeves has requested input on his proposed BIP.By exploring this alternative proposal, users have the opportunity to contribute their thoughts and insights regarding the current limitations of the OP_ADD function in Bitcoin. It is important to note that any potential changes to address this limitation would necessitate careful consideration due to the impact they would have on the blockchain and the need for a possible hard fork or network-wide upgrade.Therefore, interested parties are encouraged to examine the details of Reeves' draft BIP on the Bitcoin Wiki page and provide their valuable feedback and comments. This collaborative effort will help shape the future development and improvement of Bitcoin's functionality. 2012-01-16T21:22:54+00:00 + During a discussion about the OP_ADD function in Bitcoin, it has come to light that the function has a limitation of only allowing 4-byte operands. Any changes to this limitation would require either a hard blockchain split or an entire network upgrade. In response to this limitation, user Ben Reeves has submitted a draft Bitcoin Improvement Proposal (BIP).This proposed BIP serves as an alternative to BIP 16, also known as "/P2SH/". Reeves has named his draft "BIP M of 2 DRAFT", and it is available for review on the Bitcoin Wiki page. In order to gather feedback and comments from the community, Reeves has requested input on his proposed BIP.By exploring this alternative proposal, users have the opportunity to contribute their thoughts and insights regarding the current limitations of the OP_ADD function in Bitcoin. It is important to note that any potential changes to address this limitation would necessitate careful consideration due to the impact they would have on the blockchain and the need for a possible hard fork or network-wide upgrade.Therefore, interested parties are encouraged to examine the details of Reeves' draft BIP on the Bitcoin Wiki page and provide their valuable feedback and comments. This collaborative effort will help shape the future development and improvement of Bitcoin's functionality. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_BIP16-17-replacement.xml b/static/bitcoin-dev/Jan_2012/combined_BIP16-17-replacement.xml index d9183fbee5..e709a62dda 100644 --- a/static/bitcoin-dev/Jan_2012/combined_BIP16-17-replacement.xml +++ b/static/bitcoin-dev/Jan_2012/combined_BIP16-17-replacement.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP16/17 replacement - 2023-08-01T02:59:30.445170+00:00 + 2025-10-11T21:59:00.626700+00:00 + python-feedgen Andy Parkins 2012-02-01 14:14:08+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP16/17 replacement - 2023-08-01T02:59:30.446173+00:00 + 2025-10-11T21:59:00.626851+00:00 - On January 31, 2012, Andy Parkins proposed changes to the Bitcoin protocol. He suggested replacing the "scriptPubKey" field with a new "hashOfClaimingScript" field and adding an "unsignedParameters" array. However, he later realized that his proposal was essentially BIP16 without backward compatibility work. He suggested renaming the scriptPubKey field to "hashOfClaimingScript" and no longer running it as a script. This format of scriptPubKey would activate "version2" processing of the transaction. The scriptSig would have two fields: unsignedInitialStackBlock and scriptClaim. Parkins concluded that he now supported BIP16 as it moves towards having a literal claimScriptHash field instead of scriptPubKey.On February 1, 2012, Pieter Wuille and Dr. Andy Parkins discussed changes to the Bitcoin protocol. They noted that non-standard transactions are verified in the blockchain but are rejected when entering the memory pool due to the IsStandard() function. They also discussed the importance of upgrading to avoid seeing a fork of the chain from before the first new-style transaction if a breaking change is made to the protocol.On the same day, Andy Parkins had a discussion with Luke-Jr regarding BIP16 and BIP17. Luke-Jr claimed that both proposals were backward compatible enough for users to continue using old clients with each other, but Andy questioned this. It was explained that IsStandard() is used for accepting transactions into the memory pool, and non-standard transactions are verified in the blockchain. BIP16/17 create transactions that, when interpreted as old scripts, are valid. The only change to the protocol is that previously-valid transactions become invalid. As long as a supermajority of miners enforce the new rules, everyone can keep using their old bitcoin client.Gregory Maxwell responded on January 31, 2012, stating that nodes in Bitcoin do not need to trust the network and can validate information themselves. He argued against making breaking changes to the system as it is a zero-trust system and any change would require a client update. However, he considered BIP16/17 not to be breaking changes. The author of the original proposal disagreed but agreed that making such changes would be difficult due to resource requirements. Increasing the version number of the transaction structure was suggested as a reasonable solution.In an email conversation on January 31, 2012, Andy Parkins expressed nervousness about the ongoing debate surrounding BIP16/BIP17. Another participant explained that the differences between the options were technically obscure and generally agreed upon by technically-minded individuals. They referred to Luke's opinion tracker page, which reflects the views of core developers and informed parties. It was noted that BIP16 was the consensus path forward from earlier discussions, while BIP12 was deemed too computationally powerful. Client upgrade would be necessary to make use of new functionality, as Bitcoin is a zero-trust system and breaking changes like those proposed could not be taken lightly.Luke-Jr wrote on January 31, 2012, that there were no remaining tangible objections to BIP17. Both BIP16 and 17 were backward compatible enough for users to continue using old clients with each other. An upgrade was only required to send or receive on the new 3...-form addresses. The practical implications of both proposals could be rewritten in a format suggested by Andy, which would be backward compatible. Only version2 transactions for version2 addresses would need to be made.In another email conversation, Andy Parkins expressed his nervousness about the ongoing debate surrounding BIP17 and BIP16. He suggested that if there were objections to both proposals, then perhaps another solution would be better. He was willing to withdraw BIP17 if a better solution emerged. Both BIP16 and 17 were backward-compatible enough for users to continue using old clients with each other. Upgrades would only be necessary to send or receive new 3...-format addresses. The practical implications of both proposals could be rewritten in the suggested format, which would eliminate one of the major objections to BIP16.The author of an email expressed nervousness about suggesting an idea for a change in transactions. They proposed increasing the version number in transactions and making changes to the transaction structure. The proposal included replacing the "scriptPubKey" field with "hashOfClaimingScript" and adding an "unsignedParameters" array. The hashOfClaimingScript would be the hash of the script allowed to claim the output. The proposal invited feedback from others. 2012-02-01T14:14:08+00:00 + On January 31, 2012, Andy Parkins proposed changes to the Bitcoin protocol. He suggested replacing the "scriptPubKey" field with a new "hashOfClaimingScript" field and adding an "unsignedParameters" array. However, he later realized that his proposal was essentially BIP16 without backward compatibility work. He suggested renaming the scriptPubKey field to "hashOfClaimingScript" and no longer running it as a script. This format of scriptPubKey would activate "version2" processing of the transaction. The scriptSig would have two fields: unsignedInitialStackBlock and scriptClaim. Parkins concluded that he now supported BIP16 as it moves towards having a literal claimScriptHash field instead of scriptPubKey.On February 1, 2012, Pieter Wuille and Dr. Andy Parkins discussed changes to the Bitcoin protocol. They noted that non-standard transactions are verified in the blockchain but are rejected when entering the memory pool due to the IsStandard() function. They also discussed the importance of upgrading to avoid seeing a fork of the chain from before the first new-style transaction if a breaking change is made to the protocol.On the same day, Andy Parkins had a discussion with Luke-Jr regarding BIP16 and BIP17. Luke-Jr claimed that both proposals were backward compatible enough for users to continue using old clients with each other, but Andy questioned this. It was explained that IsStandard() is used for accepting transactions into the memory pool, and non-standard transactions are verified in the blockchain. BIP16/17 create transactions that, when interpreted as old scripts, are valid. The only change to the protocol is that previously-valid transactions become invalid. As long as a supermajority of miners enforce the new rules, everyone can keep using their old bitcoin client.Gregory Maxwell responded on January 31, 2012, stating that nodes in Bitcoin do not need to trust the network and can validate information themselves. He argued against making breaking changes to the system as it is a zero-trust system and any change would require a client update. However, he considered BIP16/17 not to be breaking changes. The author of the original proposal disagreed but agreed that making such changes would be difficult due to resource requirements. Increasing the version number of the transaction structure was suggested as a reasonable solution.In an email conversation on January 31, 2012, Andy Parkins expressed nervousness about the ongoing debate surrounding BIP16/BIP17. Another participant explained that the differences between the options were technically obscure and generally agreed upon by technically-minded individuals. They referred to Luke's opinion tracker page, which reflects the views of core developers and informed parties. It was noted that BIP16 was the consensus path forward from earlier discussions, while BIP12 was deemed too computationally powerful. Client upgrade would be necessary to make use of new functionality, as Bitcoin is a zero-trust system and breaking changes like those proposed could not be taken lightly.Luke-Jr wrote on January 31, 2012, that there were no remaining tangible objections to BIP17. Both BIP16 and 17 were backward compatible enough for users to continue using old clients with each other. An upgrade was only required to send or receive on the new 3...-form addresses. The practical implications of both proposals could be rewritten in a format suggested by Andy, which would be backward compatible. Only version2 transactions for version2 addresses would need to be made.In another email conversation, Andy Parkins expressed his nervousness about the ongoing debate surrounding BIP17 and BIP16. He suggested that if there were objections to both proposals, then perhaps another solution would be better. He was willing to withdraw BIP17 if a better solution emerged. Both BIP16 and 17 were backward-compatible enough for users to continue using old clients with each other. Upgrades would only be necessary to send or receive new 3...-format addresses. The practical implications of both proposals could be rewritten in the suggested format, which would eliminate one of the major objections to BIP16.The author of an email expressed nervousness about suggesting an idea for a change in transactions. They proposed increasing the version number in transactions and making changes to the transaction structure. The proposal included replacing the "scriptPubKey" field with "hashOfClaimingScript" and adding an "unsignedParameters" array. The hashOfClaimingScript would be the hash of the script allowed to claim the output. The proposal invited feedback from others. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_CAddrMan-Stochastic-IP-address-manager.xml b/static/bitcoin-dev/Jan_2012/combined_CAddrMan-Stochastic-IP-address-manager.xml index 9ff9a19ed0..3144c70d92 100644 --- a/static/bitcoin-dev/Jan_2012/combined_CAddrMan-Stochastic-IP-address-manager.xml +++ b/static/bitcoin-dev/Jan_2012/combined_CAddrMan-Stochastic-IP-address-manager.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CAddrMan: Stochastic IP address manager - 2023-08-01T02:57:15.639973+00:00 + 2025-10-11T21:58:56.377304+00:00 + python-feedgen Michael Hendricks 2012-01-31 15:07:16+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - CAddrMan: Stochastic IP address manager - 2023-08-01T02:57:15.639973+00:00 + 2025-10-11T21:58:56.377520+00:00 - To address the weakness of potential Sybil attacks in the context of IPv6, a developer has devised a new design. This design involves maintaining two tables: one for addresses that have had actual connections and another for untried/new addresses. Both tables are divided into limited-size buckets.In the first table, addresses with actual connections are assigned to a small number of buckets based on their address range (/16 for IPv4). This ensures that attackers cannot have numerous active nodes within the same /16 range. The second table handles untried/new addresses. These addresses are placed in buckets determined by the address range the information came from, rather than the address itself. This further prevents attackers from easily manipulating the cache.To enhance efficiency, all crucial decisions such as address selection, bucket placement, and entry eviction are randomized with biases. The selection of buckets is determined through a cryptographic hash using a secret key, ensuring behavior is deterministically randomized.An implementation of this design can be found in pull request 787 on GitHub. However, further testing and improvements are required. The developer welcomes test reports, comments, constructive criticism, suggestions, and improvements to refine the design and ensure its effectiveness against Sybil attacks.In another discussion, Gavin Andresen suggests removing the IRC bootstrapping mechanism from Bitcoin. He believes that removing it would reduce code complexity and prevent reports of Bitcoin being tagged as malware by ISPs. Gavin proposes disabling the mechanism by default in version 0.6 and completely removing it before version 0.7 if there are no issues.The email thread also touches on the topic of Sybil attacks. It is mentioned that an attacker with control over 60% of the network's nodes would have a 1.7% chance of success in a Sybil attack if a client has eight connections to the network. However, nodes that accept incoming connections are less vulnerable, as the probability of success decreases exponentially with the number of connections. To mitigate the risk of Sybil attacks, a command-line option for increasing the maximum number of outbound connections is suggested.Additionally, the discussion highlights the importance of having multiple mechanisms for bootstrapping the Bitcoin network to prevent blocking. It is noted that relying solely on DNS and hardcoded seed nodes leaves the network susceptible to being blocked. Suggestions are made to allow users to add nodes/addr.txt as an alternative mechanism. The potential removal of IRC bootstrapping is also considered, with the suggestion to fix the protocol's weaknesses if it remains, or remove it altogether.Overall, the email exchanges discuss various aspects of the Bitcoin network, including the potential risks of Sybil attacks, the need for efficient address management, the consideration of removing the IRC bootstrapping mechanism, and the importance of having multiple mechanisms to prevent blocking. Feedback and suggestions for improvement are encouraged to ensure the continued development and security of the Bitcoin network. 2012-01-31T15:07:16+00:00 + To address the weakness of potential Sybil attacks in the context of IPv6, a developer has devised a new design. This design involves maintaining two tables: one for addresses that have had actual connections and another for untried/new addresses. Both tables are divided into limited-size buckets.In the first table, addresses with actual connections are assigned to a small number of buckets based on their address range (/16 for IPv4). This ensures that attackers cannot have numerous active nodes within the same /16 range. The second table handles untried/new addresses. These addresses are placed in buckets determined by the address range the information came from, rather than the address itself. This further prevents attackers from easily manipulating the cache.To enhance efficiency, all crucial decisions such as address selection, bucket placement, and entry eviction are randomized with biases. The selection of buckets is determined through a cryptographic hash using a secret key, ensuring behavior is deterministically randomized.An implementation of this design can be found in pull request 787 on GitHub. However, further testing and improvements are required. The developer welcomes test reports, comments, constructive criticism, suggestions, and improvements to refine the design and ensure its effectiveness against Sybil attacks.In another discussion, Gavin Andresen suggests removing the IRC bootstrapping mechanism from Bitcoin. He believes that removing it would reduce code complexity and prevent reports of Bitcoin being tagged as malware by ISPs. Gavin proposes disabling the mechanism by default in version 0.6 and completely removing it before version 0.7 if there are no issues.The email thread also touches on the topic of Sybil attacks. It is mentioned that an attacker with control over 60% of the network's nodes would have a 1.7% chance of success in a Sybil attack if a client has eight connections to the network. However, nodes that accept incoming connections are less vulnerable, as the probability of success decreases exponentially with the number of connections. To mitigate the risk of Sybil attacks, a command-line option for increasing the maximum number of outbound connections is suggested.Additionally, the discussion highlights the importance of having multiple mechanisms for bootstrapping the Bitcoin network to prevent blocking. It is noted that relying solely on DNS and hardcoded seed nodes leaves the network susceptible to being blocked. Suggestions are made to allow users to add nodes/addr.txt as an alternative mechanism. The potential removal of IRC bootstrapping is also considered, with the suggestion to fix the protocol's weaknesses if it remains, or remove it altogether.Overall, the email exchanges discuss various aspects of the Bitcoin network, including the potential risks of Sybil attacks, the need for efficient address management, the consideration of removing the IRC bootstrapping mechanism, and the importance of having multiple mechanisms to prevent blocking. Feedback and suggestions for improvement are encouraged to ensure the continued development and security of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_ECC-Signature-Issue.xml b/static/bitcoin-dev/Jan_2012/combined_ECC-Signature-Issue.xml index c5f63039fc..8d160ec7b2 100644 --- a/static/bitcoin-dev/Jan_2012/combined_ECC-Signature-Issue.xml +++ b/static/bitcoin-dev/Jan_2012/combined_ECC-Signature-Issue.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ECC Signature Issue - 2023-08-01T02:53:56.214072+00:00 + 2025-10-11T21:58:52.112607+00:00 + python-feedgen Brautigam Róbert 2012-01-27 18:19:54+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - ECC Signature Issue - 2023-08-01T02:53:56.214072+00:00 + 2025-10-11T21:58:52.112756+00:00 - A user named Brautigam Róbert encountered an issue with BouncyCastle while verifying a signature. Dave Hook from Bouncycastle explained that one of the ASN1 encoded integers in the signature was negative, which is not valid for a point on a curve. To fix this, the integer needs to be converted to a positive value by padding it with a zero byte. Both the official C++ client and the bitcoinj implementation use BouncyCastle, but the latter fails to verify the transaction, suggesting a potential issue with BouncyCastle.Mike Hearn and Robert discuss the discrepancy between the official client and Bitcoinj's verification of a transaction. Robert clarifies that Bitcoinj is an SPV implementation and does not actually verify signatures. However, he tests the mentioned transaction's signature using hardwired code and data obtained from debugging the official client. He notes that all previous transactions work correctly, indicating that the data and test code are likely correct. Despite using an older version of bitcoinj, Robert doubts that it would affect ECC verification. He requests someone else to independently verify the transaction using BouncyCastle and openssl to see if they encounter the same issue. Robert tried both BouncyCastle 140 and the newest 1.46 versions, but both failed.In summary, the official Bitcoin client successfully verifies a transaction, while the Bitcoinj implementation fails to do so. This suggests a potential problem with BouncyCastle, which is used by both implementations. It is important to note that Bitcoinj is an SPV implementation and does not verify signatures. A developer working on a Java implementation of Bitcoin reports that the signature verification fails for a specific transaction, even though it was successful for all preceding transactions. The developer suspects that the issue may be related to BouncyCastle and requests assistance in double-checking their code. 2012-01-27T18:19:54+00:00 + A user named Brautigam Róbert encountered an issue with BouncyCastle while verifying a signature. Dave Hook from Bouncycastle explained that one of the ASN1 encoded integers in the signature was negative, which is not valid for a point on a curve. To fix this, the integer needs to be converted to a positive value by padding it with a zero byte. Both the official C++ client and the bitcoinj implementation use BouncyCastle, but the latter fails to verify the transaction, suggesting a potential issue with BouncyCastle.Mike Hearn and Robert discuss the discrepancy between the official client and Bitcoinj's verification of a transaction. Robert clarifies that Bitcoinj is an SPV implementation and does not actually verify signatures. However, he tests the mentioned transaction's signature using hardwired code and data obtained from debugging the official client. He notes that all previous transactions work correctly, indicating that the data and test code are likely correct. Despite using an older version of bitcoinj, Robert doubts that it would affect ECC verification. He requests someone else to independently verify the transaction using BouncyCastle and openssl to see if they encounter the same issue. Robert tried both BouncyCastle 140 and the newest 1.46 versions, but both failed.In summary, the official Bitcoin client successfully verifies a transaction, while the Bitcoinj implementation fails to do so. This suggests a potential problem with BouncyCastle, which is used by both implementations. It is important to note that Bitcoinj is an SPV implementation and does not verify signatures. A developer working on a Java implementation of Bitcoin reports that the signature verification fails for a specific transaction, even though it was successful for all preceding transactions. The developer suspects that the issue may be related to BouncyCastle and requests assistance in double-checking their code. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_Fuzzer-.xml b/static/bitcoin-dev/Jan_2012/combined_Fuzzer-.xml index da33226f5e..df403bd19b 100644 --- a/static/bitcoin-dev/Jan_2012/combined_Fuzzer-.xml +++ b/static/bitcoin-dev/Jan_2012/combined_Fuzzer-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fuzzer? - 2023-08-01T02:54:09.217480+00:00 + 2025-10-11T21:59:19.767155+00:00 + python-feedgen Gavin Andresen 2012-01-26 15:32:33+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Fuzzer? - 2023-08-01T02:54:09.217480+00:00 + 2025-10-11T21:59:19.767286+00:00 - Gavin Andresen has created a transaction fuzzer on Github specifically designed for stress-testing BIP 16. This fuzzer can be utilized by using the send* RPC commands to obtain one or more transaction IDs. By running a script that repeatedly calls relayfuzzed with a nonce/txid, it is possible to observe how connected peers react to all the fuzzy 'inv/tx' protocol messages.Although the primary purpose of the fuzzer is to stress-test BIP 16, Gavin mentions that there are several other useful features that could be added to it. He openly welcomes patches and contributions from others in order to further enhance the fuzzer's capabilities. Additionally, Gavin reveals that he plans to add block fuzzing to the fuzzer in the future.The sender of the message is interested in acquiring information about the currently developed fuzzer. They express their intention to create their own fuzzer for libbitcoin if no existing solution is available. The sender specifies that they are looking for a simple fuzzer that can perform tasks such as setting the previous block hash, setting the current target, starting hashing, and connecting and sending to a specified host (e.g localhost). While they believe that building such a fuzzer should be straightforward, they still seek additional details regarding its implementation. 2012-01-26T15:32:33+00:00 + Gavin Andresen has created a transaction fuzzer on Github specifically designed for stress-testing BIP 16. This fuzzer can be utilized by using the send* RPC commands to obtain one or more transaction IDs. By running a script that repeatedly calls relayfuzzed with a nonce/txid, it is possible to observe how connected peers react to all the fuzzy 'inv/tx' protocol messages.Although the primary purpose of the fuzzer is to stress-test BIP 16, Gavin mentions that there are several other useful features that could be added to it. He openly welcomes patches and contributions from others in order to further enhance the fuzzer's capabilities. Additionally, Gavin reveals that he plans to add block fuzzing to the fuzzer in the future.The sender of the message is interested in acquiring information about the currently developed fuzzer. They express their intention to create their own fuzzer for libbitcoin if no existing solution is available. The sender specifies that they are looking for a simple fuzzer that can perform tasks such as setting the previous block hash, setting the current target, starting hashing, and connecting and sending to a specified host (e.g localhost). While they believe that building such a fuzzer should be straightforward, they still seek additional details regarding its implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_Fw-Quote-on-BIP-16.xml b/static/bitcoin-dev/Jan_2012/combined_Fw-Quote-on-BIP-16.xml index e54ccee3c3..e4822d20af 100644 --- a/static/bitcoin-dev/Jan_2012/combined_Fw-Quote-on-BIP-16.xml +++ b/static/bitcoin-dev/Jan_2012/combined_Fw-Quote-on-BIP-16.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fw: Quote on BIP 16 - 2023-08-01T02:55:29.062079+00:00 + 2025-10-11T21:58:49.988051+00:00 + python-feedgen Luke-Jr 2012-01-29 14:40:01+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Fw: Quote on BIP 16 - 2023-08-01T02:55:29.062079+00:00 + 2025-10-11T21:58:49.988210+00:00 - During a conversation on January 29, 2012, Gavin Andresen and Amir Taaki discussed an alternative design for multisig addresses. The proposed method involved using a different approach than CHECKMULTISIG to create the "m of n" condition. Instead, it would include a byte indicating the transaction type and the 20-byte hashes of each public key involved. While this solution could potentially address issues with maximum-sigops-per-block, it had drawbacks such as the need for a new bitcoin address for every new transaction type and resulting in long addresses. In an email exchange, Amir Taaki questioned how a specific bitcoin address could be so small. Gavin Andresen explained that this was due to the alternative design for multisig addresses, which did not use CHECKMULTISIG and instead included a byte indicating the transaction type and the 20-byte hashes of each public key involved. This design aimed to overcome issues with maximum-sigops-per-block. However, the impracticality of creating a new bitcoin address for each transaction type deterred its widespread adoption despite its advantages. 2012-01-29T14:40:01+00:00 + During a conversation on January 29, 2012, Gavin Andresen and Amir Taaki discussed an alternative design for multisig addresses. The proposed method involved using a different approach than CHECKMULTISIG to create the "m of n" condition. Instead, it would include a byte indicating the transaction type and the 20-byte hashes of each public key involved. While this solution could potentially address issues with maximum-sigops-per-block, it had drawbacks such as the need for a new bitcoin address for every new transaction type and resulting in long addresses. In an email exchange, Amir Taaki questioned how a specific bitcoin address could be so small. Gavin Andresen explained that this was due to the alternative design for multisig addresses, which did not use CHECKMULTISIG and instead included a byte indicating the transaction type and the 20-byte hashes of each public key involved. This design aimed to overcome issues with maximum-sigops-per-block. However, the impracticality of creating a new bitcoin address for each transaction type deterred its widespread adoption despite its advantages. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_GetBlocksToMaturity.xml b/static/bitcoin-dev/Jan_2012/combined_GetBlocksToMaturity.xml index df407eb608..40076eadd0 100644 --- a/static/bitcoin-dev/Jan_2012/combined_GetBlocksToMaturity.xml +++ b/static/bitcoin-dev/Jan_2012/combined_GetBlocksToMaturity.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - GetBlocksToMaturity - 2023-08-01T02:54:19.404539+00:00 + 2025-10-11T21:59:04.878308+00:00 + python-feedgen Amir Taaki 2012-01-27 16:37:05+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - GetBlocksToMaturity - 2023-08-01T02:54:19.404539+00:00 + 2025-10-11T21:59:04.878477+00:00 - Amir Taaki suggests that the reason for adding 20 confirmations is likely to ensure that transactions are accepted by the network when sent out and to prevent potential network partitions causing another fork to get built up. At around 20 confirmations, it can be reasonably assumed that the rest of the network also has 100 confirmations off the original mined block. However, at 100 confirms, there may be a chain ahead of everyone else or a temporary network partition (islanding) that causes another fork to get built up, leading to not everyone having 100 confirms.This email raises an important question about the decision to add 20 confirmations to COINBASE_MATURITY. It suggests that Satoshi may have overestimated the number of competing races between mined blocks, which led to the implementation of this measure. Taaki speculates that the goal may have been to ensure that transactions are widely accepted by the network before being considered fully confirmed.Overall, this email highlights the intricacies of the Bitcoin protocol and the factors that influence the confirmation process. It brings attention to the potential risks and considerations involved in determining the appropriate number of confirmations needed for a transaction to be considered secure. The discussion initiated by Taaki prompts further examination of the rationale behind COINBASE_MATURITY and its implications for the overall security and stability of the Bitcoin network. 2012-01-27T16:37:05+00:00 + Amir Taaki suggests that the reason for adding 20 confirmations is likely to ensure that transactions are accepted by the network when sent out and to prevent potential network partitions causing another fork to get built up. At around 20 confirmations, it can be reasonably assumed that the rest of the network also has 100 confirmations off the original mined block. However, at 100 confirms, there may be a chain ahead of everyone else or a temporary network partition (islanding) that causes another fork to get built up, leading to not everyone having 100 confirms.This email raises an important question about the decision to add 20 confirmations to COINBASE_MATURITY. It suggests that Satoshi may have overestimated the number of competing races between mined blocks, which led to the implementation of this measure. Taaki speculates that the goal may have been to ensure that transactions are widely accepted by the network before being considered fully confirmed.Overall, this email highlights the intricacies of the Bitcoin protocol and the factors that influence the confirmation process. It brings attention to the potential risks and considerations involved in determining the appropriate number of confirmations needed for a transaction to be considered secure. The discussion initiated by Taaki prompts further examination of the rationale behind COINBASE_MATURITY and its implications for the overall security and stability of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_Meeting-21-00-UTC-bitcoin-dev-Freenode-IRC.xml b/static/bitcoin-dev/Jan_2012/combined_Meeting-21-00-UTC-bitcoin-dev-Freenode-IRC.xml index 17c72f0609..0d8beb6a18 100644 --- a/static/bitcoin-dev/Jan_2012/combined_Meeting-21-00-UTC-bitcoin-dev-Freenode-IRC.xml +++ b/static/bitcoin-dev/Jan_2012/combined_Meeting-21-00-UTC-bitcoin-dev-Freenode-IRC.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Meeting 21:00 UTC #bitcoin-dev Freenode IRC - 2023-08-01T02:51:22.027302+00:00 + 2025-10-11T21:59:17.638941+00:00 + python-feedgen Matt Corallo 2012-01-02 21:24:12+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Meeting 21:00 UTC #bitcoin-dev Freenode IRC - 2023-08-01T02:51:22.027302+00:00 + 2025-10-11T21:59:17.639073+00:00 - Amir Taaki has sent out an email announcing a meeting to discuss the new OP_EVAL changes coming to Bitcoin. The purpose of the meeting is to prevent fragmentation and ensure harmony among projects by providing a platform for proposing and debating concepts and algorithms. The goal is to have weekly meetings, which will make Bitcoin development and the system more accessible. To facilitate discussions, a wiki page will be created before each meeting where participants can add talking points throughout the week. After the meeting, a log of the discussion will be posted online, and a summary will be typed for the community at large on bitcoinmedia.com.The meeting is scheduled to take place on Freenode IRC #bitcoin-dev from 21:00 to 22:00 UTC (16:00 New York time). It is expected that the meeting will not exceed one hour to avoid off-topic discussions. The hope is that having a regular, scheduled platform will allow for better coordination and collaboration among Bitcoin projects.In addition to the meeting details, the email also mentions Citrix VDI-in-a-Box, which is a solution for delivering seamless and secure access to virtual desktops. 2012-01-02T21:24:12+00:00 + Amir Taaki has sent out an email announcing a meeting to discuss the new OP_EVAL changes coming to Bitcoin. The purpose of the meeting is to prevent fragmentation and ensure harmony among projects by providing a platform for proposing and debating concepts and algorithms. The goal is to have weekly meetings, which will make Bitcoin development and the system more accessible. To facilitate discussions, a wiki page will be created before each meeting where participants can add talking points throughout the week. After the meeting, a log of the discussion will be posted online, and a summary will be typed for the community at large on bitcoinmedia.com.The meeting is scheduled to take place on Freenode IRC #bitcoin-dev from 21:00 to 22:00 UTC (16:00 New York time). It is expected that the meeting will not exceed one hour to avoid off-topic discussions. The hope is that having a regular, scheduled platform will allow for better coordination and collaboration among Bitcoin projects.In addition to the meeting details, the email also mentions Citrix VDI-in-a-Box, which is a solution for delivering seamless and secure access to virtual desktops. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_Pull-748-pay-to-script-hash.xml b/static/bitcoin-dev/Jan_2012/combined_Pull-748-pay-to-script-hash.xml index 30eb5049d3..9af8f9f092 100644 --- a/static/bitcoin-dev/Jan_2012/combined_Pull-748-pay-to-script-hash.xml +++ b/static/bitcoin-dev/Jan_2012/combined_Pull-748-pay-to-script-hash.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pull 748 pay to script hash - 2023-08-01T02:51:41.383013+00:00 + 2025-10-11T21:58:58.504295+00:00 + python-feedgen Pieter Wuille 2012-01-08 16:12:16+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Pull 748 pay to script hash - 2023-08-01T02:51:41.383013+00:00 + 2025-10-11T21:58:58.504448+00:00 - In a discussion on January 7, 2012, Gavin Andresen and Pieter discussed the compressed-public-keys patch. Pieter mentioned that he had added some unit tests but Gavin was unsure if the patch had been pulled. They went on to discuss how compressed public keys interact with pay-to-script-hash to make ECDSA denial-of-service attacks less expensive and how transaction fees need to be reconsidered before releasing version 0.6. Compressed public keys are smaller and more CPU intensive to verify than regular public keys. It is suggested that the fee policy should be tweaked to deter attackers from using compressed public keys and 1-of-3 CHECKMULTISIG transactions for denial-of-service attacks.The purpose of counting the number of sig ops after executing a script in ConnectInputs is to ensure compliance with the rule that "a block shall not contain more than MAX_BLOCK_SIGOPS (20,000)". This rule applies to both the old and new ways of counting sig ops, which involves looking at scriptPubKeys and pay-to-script-hash scripts in the scriptSig. However, there is concern that this counting may be too late in the process. To address this, further refactoring of ConnectInputs is suggested, including the addition of FetchInputs() and AreInputsStandard() functions.Gavin Andresen suggests reverting an old pull and then re-requesting it to make it easier to see the real changes regarding the purpose of counting the number of sig ops after executing a script in ConnectInputs. He notes that there were one major merge and eight commits to fix bugs or tweak things. In order to facilitate code review, Gavin updates his gavinandresen/master GitHub branch to the state of the tree just before the OP_EVAL merge. The changes can be viewed at https://github.com/gavinandresen/bitcoin-git/compare/master...pay_to_script_hash. There are unrelated 0.6 pulls in those changes as well, but it should be obvious what is what.Additionally, a comparison is being made between a defunct OP_EVAL proposal and the current pay to script hash proposal. The comparison is based on reading a diff of the two proposals, which can be found at https://github.com/bitcoin/bitcoin/pull/748/files. It is suggested that for code review purposes, it would be more beneficial to revert the old pull and re-request it, simplifying the process of identifying the actual changes made between the two proposals. 2012-01-08T16:12:16+00:00 + In a discussion on January 7, 2012, Gavin Andresen and Pieter discussed the compressed-public-keys patch. Pieter mentioned that he had added some unit tests but Gavin was unsure if the patch had been pulled. They went on to discuss how compressed public keys interact with pay-to-script-hash to make ECDSA denial-of-service attacks less expensive and how transaction fees need to be reconsidered before releasing version 0.6. Compressed public keys are smaller and more CPU intensive to verify than regular public keys. It is suggested that the fee policy should be tweaked to deter attackers from using compressed public keys and 1-of-3 CHECKMULTISIG transactions for denial-of-service attacks.The purpose of counting the number of sig ops after executing a script in ConnectInputs is to ensure compliance with the rule that "a block shall not contain more than MAX_BLOCK_SIGOPS (20,000)". This rule applies to both the old and new ways of counting sig ops, which involves looking at scriptPubKeys and pay-to-script-hash scripts in the scriptSig. However, there is concern that this counting may be too late in the process. To address this, further refactoring of ConnectInputs is suggested, including the addition of FetchInputs() and AreInputsStandard() functions.Gavin Andresen suggests reverting an old pull and then re-requesting it to make it easier to see the real changes regarding the purpose of counting the number of sig ops after executing a script in ConnectInputs. He notes that there were one major merge and eight commits to fix bugs or tweak things. In order to facilitate code review, Gavin updates his gavinandresen/master GitHub branch to the state of the tree just before the OP_EVAL merge. The changes can be viewed at https://github.com/gavinandresen/bitcoin-git/compare/master...pay_to_script_hash. There are unrelated 0.6 pulls in those changes as well, but it should be obvious what is what.Additionally, a comparison is being made between a defunct OP_EVAL proposal and the current pay to script hash proposal. The comparison is based on reading a diff of the two proposals, which can be found at https://github.com/bitcoin/bitcoin/pull/748/files. It is suggested that for code review purposes, it would be more beneficial to revert the old pull and re-request it, simplifying the process of identifying the actual changes made between the two proposals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_Quote-on-BIP-16.xml b/static/bitcoin-dev/Jan_2012/combined_Quote-on-BIP-16.xml index 53f49be7be..aac80d92e1 100644 --- a/static/bitcoin-dev/Jan_2012/combined_Quote-on-BIP-16.xml +++ b/static/bitcoin-dev/Jan_2012/combined_Quote-on-BIP-16.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Quote on BIP 16 - 2023-08-01T02:55:20.130286+00:00 + 2025-10-11T21:58:47.864261+00:00 + python-feedgen Gregory Maxwell 2012-01-29 08:14:06+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Quote on BIP 16 - 2023-08-01T02:55:20.130286+00:00 + 2025-10-11T21:58:47.864442+00:00 - The email thread discusses the potential abuse of plain multi-sig and whether it should be considered standard. However, it is important to differentiate between multi-sig addresses and P2S with multi-sig output scripts in general. The size of unprunable transaction outputs is currently not an issue, but there are arguments against multi-sig outputs. Negotiated escrow arrangements can work either way, but P2SH is still better for these types of transactions for two reasons. Firstly, reasonable anti-spam behavior may make it difficult to create large output scripts. Secondly, P2SH allows for the use of a separate escrow-maker tool, providing uncoupling between clients paying into escrow and support for escrow transactions in that client.Amir Taaki quoted Gavin's argument regarding the controversy surrounding bitcoin addresses longer than 70 characters. Gavin argued that very long addresses are not workable due to difficulties in copying and pasting, scanning, and upgrading website or database code that deals with bitcoin addresses. He suggested that a P2SH scheme might be necessary for 70-byte long addresses. Alan expressed concern over the implementation of BIP 13/16/17 and proposed that multi-sig should be available as a fallback option. However, gmaxwell expressed concerns about the potential abuse of plain multi-sig, suggesting it may not be considered standard. Alan acknowledged that copy and pasting may not be a big deal for him, but recognized that regular users may struggle with copying long strings.In a conversation between Amir Taaki and Gavin Andresen, the possibility of having a 70-byte long address without using a P2SH scheme was questioned. Gavin clarified that P2SH eliminates the need for such long addresses. P2SH reduces output sizes to the minimum without inflating total data size, making it more efficient than P2S. P2S, which involves encoding the full script specification instead of just its hash, results in much longer addresses and has several problems such as vulnerability to invisible substitution and enlarged transactions fees.Amir Taaki discussed the size of compressed pubkeys, noting that each pubkey is 33 bytes. When combined with other elements, such as the address version and checksum, the total size becomes 72 bytes. However, base58 encoding is necessary to obtain an address from these bytes, resulting in a 99 character long address.Gavin expressed concerns over creating very long Bitcoin addresses that exceed 70 characters, highlighting difficulties in copying, pasting, scanning, generating QR codes, and upgrading website or database code. He argued that there is a rough consensus that very-long addresses are not workable. The issue relates to the current P2SH scheme used for multisig transactions, which limits the length of the redeem script. This raises the question of how a 70-byte long address would be possible without using the P2SH scheme. The debate underscores the importance of usability in the adoption and use of cryptocurrencies, as longer addresses may pose challenges for users and developers. 2012-01-29T08:14:06+00:00 + The email thread discusses the potential abuse of plain multi-sig and whether it should be considered standard. However, it is important to differentiate between multi-sig addresses and P2S with multi-sig output scripts in general. The size of unprunable transaction outputs is currently not an issue, but there are arguments against multi-sig outputs. Negotiated escrow arrangements can work either way, but P2SH is still better for these types of transactions for two reasons. Firstly, reasonable anti-spam behavior may make it difficult to create large output scripts. Secondly, P2SH allows for the use of a separate escrow-maker tool, providing uncoupling between clients paying into escrow and support for escrow transactions in that client.Amir Taaki quoted Gavin's argument regarding the controversy surrounding bitcoin addresses longer than 70 characters. Gavin argued that very long addresses are not workable due to difficulties in copying and pasting, scanning, and upgrading website or database code that deals with bitcoin addresses. He suggested that a P2SH scheme might be necessary for 70-byte long addresses. Alan expressed concern over the implementation of BIP 13/16/17 and proposed that multi-sig should be available as a fallback option. However, gmaxwell expressed concerns about the potential abuse of plain multi-sig, suggesting it may not be considered standard. Alan acknowledged that copy and pasting may not be a big deal for him, but recognized that regular users may struggle with copying long strings.In a conversation between Amir Taaki and Gavin Andresen, the possibility of having a 70-byte long address without using a P2SH scheme was questioned. Gavin clarified that P2SH eliminates the need for such long addresses. P2SH reduces output sizes to the minimum without inflating total data size, making it more efficient than P2S. P2S, which involves encoding the full script specification instead of just its hash, results in much longer addresses and has several problems such as vulnerability to invisible substitution and enlarged transactions fees.Amir Taaki discussed the size of compressed pubkeys, noting that each pubkey is 33 bytes. When combined with other elements, such as the address version and checksum, the total size becomes 72 bytes. However, base58 encoding is necessary to obtain an address from these bytes, resulting in a 99 character long address.Gavin expressed concerns over creating very long Bitcoin addresses that exceed 70 characters, highlighting difficulties in copying, pasting, scanning, generating QR codes, and upgrading website or database code. He argued that there is a rough consensus that very-long addresses are not workable. The issue relates to the current P2SH scheme used for multisig transactions, which limits the length of the redeem script. This raises the question of how a 70-byte long address would be possible without using the P2SH scheme. The debate underscores the importance of usability in the adoption and use of cryptocurrencies, as longer addresses may pose challenges for users and developers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_bitcoin-org-SOPA-PIPA-blackout.xml b/static/bitcoin-dev/Jan_2012/combined_bitcoin-org-SOPA-PIPA-blackout.xml index 826dd7b3f6..040ca96b75 100644 --- a/static/bitcoin-dev/Jan_2012/combined_bitcoin-org-SOPA-PIPA-blackout.xml +++ b/static/bitcoin-dev/Jan_2012/combined_bitcoin-org-SOPA-PIPA-blackout.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin.org SOPA/PIPA blackout - 2023-08-01T02:53:30.642929+00:00 + 2025-10-11T21:59:13.388610+00:00 + python-feedgen Peter Vessenes 2012-01-17 19:03:36+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - bitcoin.org SOPA/PIPA blackout - 2023-08-01T02:53:30.643948+00:00 + 2025-10-11T21:59:13.388807+00:00 - The discussion surrounding the issue of SOPA and PIPA and its potential impact on Bitcoin is a prominent topic. While the bills are not specifically aimed at Bitcoin, they could have adverse effects on the cryptocurrency. The DMCA already poses challenges for publishing blocks online under a DMCA request, but SOPA would allow the US to globally cut access to offending sites. Companies with a stake in Bitcoin are taking the threat seriously.The bitcoin-development mailing list was created as a platform for technical discussions. However, there have been exchanges regarding the relevance of SOPA discussions on the list. Some members argue for staying focused on technical topics and avoiding political issues, while others express opinions about censorship and free speech. The inclusion of links to an online learning library for Microsoft developers further diversifies the conversation.The mailing list for bitcoin development is deemed an inappropriate forum for discussing political or religious matters. A recent email thread delves into the topic of censorship and free speech, with conflicting viewpoints expressed. The email also includes a link to an article promoting traditional mass and criticizing modernity. Such proselytizing is frowned upon in the mailing list. Additionally, an advertisement for LearnDevNow, an online learning library for Microsoft developers, is featured in the email.The importance of free speech is highlighted by Jorge Timón, who argues that it is a basic principle of freedom and democracy. However, there is an opposing view that considers censorship to be good while free speech and democracy are evil. This viewpoint suggests that idolizing liberty is also evil and that backward morals are worse than a political issue. An article by Bishop Sanborn is suggested for further reading on the topic.There are concerns about user trust in Bitcoin being harmed by a blackout. Spammers advertising malicious software pose a threat to user trust, but the author is open to making statements or displaying banners. It is noted that SOPA contains requirements that may adversely affect Bitcoin services businesses and limit their operations. Miners and mining pools located in the US could be ordered not to process transactions containing the addresses of targeted infringing sites. The author emphasizes that staying informed and involved is crucial because anything that imposes new barriers is a threat to everyone.Amir Taaki expresses the opinion that Wikipedia has a greater need to remain neutral and apolitical than Bitcoin. Supporters of this view suggest that Bitcoin-related websites should join the blackout protest against SOPA. However, there are concerns about alienating users and the perception of centralization within the Bitcoin community.The proposed internet censorship laws pose a risk to Bitcoin and its community. Criminalization of users and developers could have serious consequences. While stopping these specific laws may not solve the underlying issue, taking action against them is important for protecting free speech. The dependence of Bitcoin on a globally connected internet further underscores the significance of this issue. Standing up against censorship is necessary to defend freedom and democracy.The controversy surrounding censorship on Wikipedia is discussed, with arguments against it becoming a political organization. However, the focus is on the principles of free speech and democracy rather than left or right politics. The impact of censorship on Bitcoin is highlighted by Gregory, emphasizing the need to protect free speech across all online platforms.The potential impact of SOPA and PIPA on Bitcoin is addressed. New requirements for payment networks could adversely affect Bitcoin services businesses. Miners and mining pools located in the US could be ordered not to process transactions involving targeted infringing sites. The importance of opposing these laws and defending basic principles of freedom and democracy is emphasized.The debate within the Bitcoin community regarding the SOPA/PIPA blackout reveals differing opinions. Some argue that SOPA threatens Bitcoin directly and advocate for participating in the blackout protest alongside other websites. Others believe Bitcoin should remain apolitical to avoid alienating users. There is no clear consensus on whether Bitcoin.org should take a political stance.Alan Reiner argues that internet censorship legislation does not directly affect Bitcoin and its community. He suggests that imposing a single purpose on all Bitcoin users would hinder widespread adoption. The discussion addresses the broader issue of differing perspectives on what Bitcoin represents.The debate surrounding Bitcoin.org's potential participation in the SOPA/PIPA blackout reveals conflicting views. Some argue for maintaining neutrality, while others believe that SOPA/PIPA directly threatens Bitcoin and advocate for a blackout protest. Concerns about alienating users and difficulty reaching a consensus are raised.The issue of whether Bitcoin should take a political stand on the SOPA/PIPA blackout is discussed. Some argue that the blackout is crucial as it strikes at the core of Bitcoin's philosophy. Others believe that Bitcoin should remain apolitical to avoid centralization and accommodate heavily-invested users. A light response is suggested if any action is taken.The impact of internet censorship on Bitcoin is discussed in an email exchange between Gregory Maxwell and Wladimir. Wladimir expresses concern about the threat to Bitcoin if people do not stand up for their rights. Gregory points out that few individuals care about loading specific URLs, suggesting that an informative 2012-01-17T19:03:36+00:00 + The discussion surrounding the issue of SOPA and PIPA and its potential impact on Bitcoin is a prominent topic. While the bills are not specifically aimed at Bitcoin, they could have adverse effects on the cryptocurrency. The DMCA already poses challenges for publishing blocks online under a DMCA request, but SOPA would allow the US to globally cut access to offending sites. Companies with a stake in Bitcoin are taking the threat seriously.The bitcoin-development mailing list was created as a platform for technical discussions. However, there have been exchanges regarding the relevance of SOPA discussions on the list. Some members argue for staying focused on technical topics and avoiding political issues, while others express opinions about censorship and free speech. The inclusion of links to an online learning library for Microsoft developers further diversifies the conversation.The mailing list for bitcoin development is deemed an inappropriate forum for discussing political or religious matters. A recent email thread delves into the topic of censorship and free speech, with conflicting viewpoints expressed. The email also includes a link to an article promoting traditional mass and criticizing modernity. Such proselytizing is frowned upon in the mailing list. Additionally, an advertisement for LearnDevNow, an online learning library for Microsoft developers, is featured in the email.The importance of free speech is highlighted by Jorge Timón, who argues that it is a basic principle of freedom and democracy. However, there is an opposing view that considers censorship to be good while free speech and democracy are evil. This viewpoint suggests that idolizing liberty is also evil and that backward morals are worse than a political issue. An article by Bishop Sanborn is suggested for further reading on the topic.There are concerns about user trust in Bitcoin being harmed by a blackout. Spammers advertising malicious software pose a threat to user trust, but the author is open to making statements or displaying banners. It is noted that SOPA contains requirements that may adversely affect Bitcoin services businesses and limit their operations. Miners and mining pools located in the US could be ordered not to process transactions containing the addresses of targeted infringing sites. The author emphasizes that staying informed and involved is crucial because anything that imposes new barriers is a threat to everyone.Amir Taaki expresses the opinion that Wikipedia has a greater need to remain neutral and apolitical than Bitcoin. Supporters of this view suggest that Bitcoin-related websites should join the blackout protest against SOPA. However, there are concerns about alienating users and the perception of centralization within the Bitcoin community.The proposed internet censorship laws pose a risk to Bitcoin and its community. Criminalization of users and developers could have serious consequences. While stopping these specific laws may not solve the underlying issue, taking action against them is important for protecting free speech. The dependence of Bitcoin on a globally connected internet further underscores the significance of this issue. Standing up against censorship is necessary to defend freedom and democracy.The controversy surrounding censorship on Wikipedia is discussed, with arguments against it becoming a political organization. However, the focus is on the principles of free speech and democracy rather than left or right politics. The impact of censorship on Bitcoin is highlighted by Gregory, emphasizing the need to protect free speech across all online platforms.The potential impact of SOPA and PIPA on Bitcoin is addressed. New requirements for payment networks could adversely affect Bitcoin services businesses. Miners and mining pools located in the US could be ordered not to process transactions involving targeted infringing sites. The importance of opposing these laws and defending basic principles of freedom and democracy is emphasized.The debate within the Bitcoin community regarding the SOPA/PIPA blackout reveals differing opinions. Some argue that SOPA threatens Bitcoin directly and advocate for participating in the blackout protest alongside other websites. Others believe Bitcoin should remain apolitical to avoid alienating users. There is no clear consensus on whether Bitcoin.org should take a political stance.Alan Reiner argues that internet censorship legislation does not directly affect Bitcoin and its community. He suggests that imposing a single purpose on all Bitcoin users would hinder widespread adoption. The discussion addresses the broader issue of differing perspectives on what Bitcoin represents.The debate surrounding Bitcoin.org's potential participation in the SOPA/PIPA blackout reveals conflicting views. Some argue for maintaining neutrality, while others believe that SOPA/PIPA directly threatens Bitcoin and advocate for a blackout protest. Concerns about alienating users and difficulty reaching a consensus are raised.The issue of whether Bitcoin should take a political stand on the SOPA/PIPA blackout is discussed. Some argue that the blackout is crucial as it strikes at the core of Bitcoin's philosophy. Others believe that Bitcoin should remain apolitical to avoid centralization and accommodate heavily-invested users. A light response is suggested if any action is taken.The impact of internet censorship on Bitcoin is discussed in an email exchange between Gregory Maxwell and Wladimir. Wladimir expresses concern about the threat to Bitcoin if people do not stand up for their rights. Gregory points out that few individuals care about loading specific URLs, suggesting that an informative - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_does-stubbing-off-Merkle-trees-reduce-initial-download-bandwidth-.xml b/static/bitcoin-dev/Jan_2012/combined_does-stubbing-off-Merkle-trees-reduce-initial-download-bandwidth-.xml index e1b5a6ed0a..f1a92ab39a 100644 --- a/static/bitcoin-dev/Jan_2012/combined_does-stubbing-off-Merkle-trees-reduce-initial-download-bandwidth-.xml +++ b/static/bitcoin-dev/Jan_2012/combined_does-stubbing-off-Merkle-trees-reduce-initial-download-bandwidth-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - does "stubbing" off Merkle trees reduce initial download bandwidth? - 2023-08-01T02:51:11.262429+00:00 + Combined summary - does "stubbing" off Merkle trees reduce initial download bandwidth? + 2025-10-11T21:59:09.127967+00:00 + python-feedgen Mike Hearn 2012-01-05 23:30:16+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 - Combined summary - does "stubbing" off Merkle trees reduce initial download bandwidth? - 2023-08-01T02:51:11.262429+00:00 + Combined summary - does "stubbing" off Merkle trees reduce initial download bandwidth? + 2025-10-11T21:59:09.128112+00:00 - In this discussion, two topics are explored: transaction pruning and simplified payment verification (SPV) mode. Transaction pruning, also known as "stubbing," focuses on saving disk space without affecting the initial chain download bandwidth or time. On the other hand, SPV clients can download only chain headers with no bodies, which reduces the setup time. However, this method still requires regular signed checkpoints from a trusted developer and a circular block store for bounded overheads.The merkle tree remains useful in SPV clients as it allows them to receive only transactions of interest while maintaining similar assurances to downloading full blocks. Contrary to popular belief, SPV clients do not rely on the "number of blocks on top" to determine validity. Instead, they look for the best available chain. If an SPV node has access to the P2P network and is communicating with a user, it can be defrauded as long as it dominates the network's hash power through a 51% attack. However, once the network dominance ends, the correct chain will catch up, exposing the fraud to the SPV user.In a conversation between Gregory Maxwell and an unknown person on January 2, 2012, they discuss the potential of using a Bitcoin transaction to double-spend coins. The unknown person suggests that if a node controls the private keys for a transaction and it makes it into the chain, the transaction can be assumed unspent after being buried in a few blocks. However, Gregory raises concerns about attackers using a faked block sequence to target multiple clients with several double-spend transactions in the first faked block. This would spread the cost over multiple attacks. Simply checking the transaction value may not be sufficient, and determining the difficulty for those blocks adds further complexity.In an email conversation dated January 2, 2012, Elden Tyrell and Christian Decker discuss the necessity of full blocks to detect usable inputs for future outgoing transactions. Tyrell believes that a paranoid client cannot confirm receipt of coins without an unstubbed copy of the entire chain, ensuring that incoming coins haven't already been spent. However, Decker disagrees, stating that if a node controls the private keys and the transaction makes it into the chain, it can be safely assumed unspent after being buried in a few blocks. This concept is at the core of Simplified Payment Verification (SPV) nodes. Decker suggests that the system could be extended to allow SPV nodes to perform this function for transactions that aren't their own.In another conversation between Christian Decker and an individual, it is discussed that full blocks are necessary to detect usable inputs for future outgoing transactions. A paranoid client requires an unstubbed copy of the entire blockchain to confirm receipt of coins because incoming coins may have already been spent. While a stubbed chain can be used for other actions, such as sending coins, confirmation of receipt necessitates the full unstubbed chain.For a newly created wallet, downloading the chain with transactions is not necessary initially, as it only has new key-pairs and no incoming transactions. However, later on, full blocks would be required to detect usable inputs for future outgoing transactions. Validating the chain itself can be done without the transactions, as long as the very last blocks are verified. Satoshi's paper mentions reducing storage requirements by deleting spent transaction outputs, but this technique does not reduce the bandwidth needed for the initial chain download by a high-security client that doesn't trust its peers. A paranoid client booting up for the first time needs an unstubbed chain to ensure each transaction's inputs are unspent and their sum exceeds the outputs (unless it's a coinbase). By accepting stubbed blocks only when the sum of difficulties in subsequent blocks exceeds a certain number N, the cost of attacking the client can be made prohibitively expensive by selecting a large enough N.While Satoshi's paper suggests reducing storage requirements by deleting spent transaction outputs, this technique does not address the bandwidth needed for the initial chain download by a high-security client that doesn't trust its peers. The validation rule for blocks in the blockchain is to trust the longest valid chain. A block is considered valid if each transaction's inputs are unspent and their sum exceeds the outputs, unless it's a coinbase. Stubbed out transactions lacking inputs and being non-coinbases cannot undergo this validation process. Therefore, a paranoid client starting up for the first time requires an unstubbed chain. However, by accepting stubbed blocks only when the sum of difficulties in subsequent blocks exceeds a certain number N, the client can be protected from attacks by choosing a sufficiently large N. It's important to note that these techniques aim to reduce storage requirements rather than the initial chain download bandwidth for a high-security client that distrusts its peers. 2012-01-05T23:30:16+00:00 + In this discussion, two topics are explored: transaction pruning and simplified payment verification (SPV) mode. Transaction pruning, also known as "stubbing," focuses on saving disk space without affecting the initial chain download bandwidth or time. On the other hand, SPV clients can download only chain headers with no bodies, which reduces the setup time. However, this method still requires regular signed checkpoints from a trusted developer and a circular block store for bounded overheads.The merkle tree remains useful in SPV clients as it allows them to receive only transactions of interest while maintaining similar assurances to downloading full blocks. Contrary to popular belief, SPV clients do not rely on the "number of blocks on top" to determine validity. Instead, they look for the best available chain. If an SPV node has access to the P2P network and is communicating with a user, it can be defrauded as long as it dominates the network's hash power through a 51% attack. However, once the network dominance ends, the correct chain will catch up, exposing the fraud to the SPV user.In a conversation between Gregory Maxwell and an unknown person on January 2, 2012, they discuss the potential of using a Bitcoin transaction to double-spend coins. The unknown person suggests that if a node controls the private keys for a transaction and it makes it into the chain, the transaction can be assumed unspent after being buried in a few blocks. However, Gregory raises concerns about attackers using a faked block sequence to target multiple clients with several double-spend transactions in the first faked block. This would spread the cost over multiple attacks. Simply checking the transaction value may not be sufficient, and determining the difficulty for those blocks adds further complexity.In an email conversation dated January 2, 2012, Elden Tyrell and Christian Decker discuss the necessity of full blocks to detect usable inputs for future outgoing transactions. Tyrell believes that a paranoid client cannot confirm receipt of coins without an unstubbed copy of the entire chain, ensuring that incoming coins haven't already been spent. However, Decker disagrees, stating that if a node controls the private keys and the transaction makes it into the chain, it can be safely assumed unspent after being buried in a few blocks. This concept is at the core of Simplified Payment Verification (SPV) nodes. Decker suggests that the system could be extended to allow SPV nodes to perform this function for transactions that aren't their own.In another conversation between Christian Decker and an individual, it is discussed that full blocks are necessary to detect usable inputs for future outgoing transactions. A paranoid client requires an unstubbed copy of the entire blockchain to confirm receipt of coins because incoming coins may have already been spent. While a stubbed chain can be used for other actions, such as sending coins, confirmation of receipt necessitates the full unstubbed chain.For a newly created wallet, downloading the chain with transactions is not necessary initially, as it only has new key-pairs and no incoming transactions. However, later on, full blocks would be required to detect usable inputs for future outgoing transactions. Validating the chain itself can be done without the transactions, as long as the very last blocks are verified. Satoshi's paper mentions reducing storage requirements by deleting spent transaction outputs, but this technique does not reduce the bandwidth needed for the initial chain download by a high-security client that doesn't trust its peers. A paranoid client booting up for the first time needs an unstubbed chain to ensure each transaction's inputs are unspent and their sum exceeds the outputs (unless it's a coinbase). By accepting stubbed blocks only when the sum of difficulties in subsequent blocks exceeds a certain number N, the cost of attacking the client can be made prohibitively expensive by selecting a large enough N.While Satoshi's paper suggests reducing storage requirements by deleting spent transaction outputs, this technique does not address the bandwidth needed for the initial chain download by a high-security client that doesn't trust its peers. The validation rule for blocks in the blockchain is to trust the longest valid chain. A block is considered valid if each transaction's inputs are unspent and their sum exceeds the outputs, unless it's a coinbase. Stubbed out transactions lacking inputs and being non-coinbases cannot undergo this validation process. Therefore, a paranoid client starting up for the first time requires an unstubbed chain. However, by accepting stubbed blocks only when the sum of difficulties in subsequent blocks exceeds a certain number N, the client can be protected from attacks by choosing a sufficiently large N. It's important to note that these techniques aim to reduce storage requirements rather than the initial chain download bandwidth for a high-security client that distrusts its peers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2012/combined_some-feedbacks.xml b/static/bitcoin-dev/Jan_2012/combined_some-feedbacks.xml index 3c6295f832..8962bd5653 100644 --- a/static/bitcoin-dev/Jan_2012/combined_some-feedbacks.xml +++ b/static/bitcoin-dev/Jan_2012/combined_some-feedbacks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - some feedbacks - 2023-08-01T02:51:54.175943+00:00 + 2025-10-11T21:59:15.513543+00:00 + python-feedgen Pieter Wuille 2012-01-15 15:22:27+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - some feedbacks - 2023-08-01T02:51:54.175943+00:00 + 2025-10-11T21:59:15.513695+00:00 - Roger Pack, a Bitcoin client user, has given feedback on his experience with the software. He recommends that the client should prompt users to set a password for their wallets upon startup. He was also confused when the wallet encryption feature did not prompt on startup as he had assumed. Additionally, Roger suggests that the client could display a message informing users about the hours of synchronization required before they can use the software. Another user responds by asking if there is interest in implementing a "first-use wizard" to enhance the user experience.Roger Pack further reports experiencing crashes on startup after synchronizing with the network on the OS X client. He offers to provide a backtrace if he can reproduce the issue. Lastly, he notes difficulty in creating new posts or replies on the Bitcoin forum, which may be limited to certain boards for new users.In a separate post, the writer expresses their struggle in finding the "create new post" link on the forum and decides to leave their feedback here instead. They provide three suggestions for the client's developers. Firstly, they suggest that the client should ask users if they want to set a password to encrypt their wallet when they first start it up. Secondly, the OS X client consistently crashes on startup after synchronization. Lastly, the writer is unable to reply or create new posts on the forum. They offer to provide a backtrace if they are able to reproduce the error. 2012-01-15T15:22:27+00:00 + Roger Pack, a Bitcoin client user, has given feedback on his experience with the software. He recommends that the client should prompt users to set a password for their wallets upon startup. He was also confused when the wallet encryption feature did not prompt on startup as he had assumed. Additionally, Roger suggests that the client could display a message informing users about the hours of synchronization required before they can use the software. Another user responds by asking if there is interest in implementing a "first-use wizard" to enhance the user experience.Roger Pack further reports experiencing crashes on startup after synchronizing with the network on the OS X client. He offers to provide a backtrace if he can reproduce the issue. Lastly, he notes difficulty in creating new posts or replies on the Bitcoin forum, which may be limited to certain boards for new users.In a separate post, the writer expresses their struggle in finding the "create new post" link on the forum and decides to leave their feedback here instead. They provide three suggestions for the client's developers. Firstly, they suggest that the client should ask users if they want to set a password to encrypt their wallet when they first start it up. Secondly, the OS X client consistently crashes on startup after synchronization. Lastly, the writer is unable to reply or create new posts on the forum. They offer to provide a backtrace if they are able to reproduce the error. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2013/combined_BitCoin-and-MinorFs-AppArmor.xml b/static/bitcoin-dev/Jan_2013/combined_BitCoin-and-MinorFs-AppArmor.xml index 0253b2cb7d..895758d465 100644 --- a/static/bitcoin-dev/Jan_2013/combined_BitCoin-and-MinorFs-AppArmor.xml +++ b/static/bitcoin-dev/Jan_2013/combined_BitCoin-and-MinorFs-AppArmor.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BitCoin and MinorFs/AppArmor - 2023-08-01T02:19:19.502235+00:00 + 2025-10-11T21:56:08.312210+00:00 + python-feedgen Rob Meijer 2013-01-10 17:41:21+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BitCoin and MinorFs/AppArmor - 2023-08-01T02:19:19.502782+00:00 + 2025-10-11T21:56:08.312382+00:00 - In an email thread from September 3, 2011, Rob Meijer announced the initial set of specifications for a rewrite of MinorFS. He expressed disappointment in receiving no response to his previous post about interest in using this updated version with Bitcoin on systems that support AppArmor like Ubuntu and OpenSuse. However, others in the thread expressed their interest in this update. One individual stated that more strict privilege separation between applications would be necessary for Ubuntu if they want to keep up with Android and MacOSX. They noted that this has been needed for a while and would be useful for any private data managed by applications running as the same user, such as SSH, browsers, and PGP. The discussion then turned to security measures, with one participant noting that wallet encryption is useful but not a substitute for OS-level protection. In response to Rob's announcement, an individual asked if it was necessary to rewrite the entire thing from scratch and questioned whether it could be compared to the Android model which uses a UID per application/user. They wondered if layering security on top of current UNIX/ACL permissions would be sufficient without needing another filesystem altogether.Rob Meijer proposed an updated version of MinorFs, a least authority based set of filesystems that could be used by Bitcoin on systems that support AppArmor like Ubuntu and OpenSuse. The purpose is to give pseudo-persistent processes their own private but decomposable and delegatable piece of filesystem storage, which is suitable for applications that want to protect user data such as Bitcoin wallets from malware running under the same UID as that user. Currently, wallet encryption is a simpler solution for end-users than MinorFs. Rob Meijer is trying to get specifications together for rewriting MinorFs in Python that would make it easier and more natural for application developers who want to protect user data. However, there are some concerns about whether MinorFs can work without changes to Bitcoin and if not, what is the minimal amount of changes needed. Additionally, there are questions about whether MinorFs would help secure the wallet on a server, maybe even an insecure VPS. Moreover, there is no guarantee that MinorFs will never corrupt the wallet; hence, it is essential to find out the proper way to do backups. Given that Bitcoin could benefit most from what MinorFs has to offer, Rob Meijer asked Bitcoin developers to think about what attributes from the current granularity level should be kept, what attributes should be dropped, and what properties should be added to arrive at an 'id' that is the best fit for granularity of persistent private storage for Bitcoin. He also welcomes all input that helps him accommodate Bitcoin developer needs so that code to use MinorFs where available can be added to Bitcoin.The author of a least authority based set of filesystems named MinorFs, Rob Meijer, is looking to update the system for use by bitcoin on systems that support AppArmor. Although there has been little interest in an updated version, Meijer has created a set of proposed specifications for a rewrite of MinorFs and is open to suggestions. The current granularity level of MinorFs is hard fixed to that of the 'pseudo persistent process'. Meijer believes that the next version should take an approach that better suits common development languages and practices. He is seeking input from bitcoin developers to create an 'id' that is the best fit for granularity of persistent private storage for bitcoin. Meijer wants to accommodate bitcoin developer needs so that code to use MinorFs where available can be added to bitcoin.A few years ago, Rob wrote a set of filesystems called MinorFs. It worked closely with AppArmor to give "pseudo persistent processes" their own private but decomposable and delegatable piece of filesystem storage. Currently, only one perfect fit for MinorFs exists, which is the stack AppArmor/MinorFs/E-language-persistent-application. However, some close fits, like running ssh without a passphrase, require lots of manual fiddling by the user to get working.Rob is trying to rewrite MinorFs in Python in a way that would make it easy and natural for application developers who want their application to protect user data from mallware running under the same uid as that user, such as bitcoin wallets. Currently, minorfs granularity is hard fixed to that of the "pseudo persistent process," and that granularity is determined in the pseudo persistent process link.Using pseudo persistent processes results in file-system storage that follows almost all of the modeling principles of the object capability model. Rob expects that Bitcoin, openssh, chrome, Firefox, or any other application that would benefit from what MinorFs provides will not be rewritten in E. Therefore, the next version of MinorFs should take an approach that better suits common development languages and practices, abandoning the purity of its least authority model.Rob wants Bitcoin developers to think about what attributes from the current granularity level should be kept, what attributes should be dropped, and what properties should be added to arrive at an "id" that 2013-01-10T17:41:21+00:00 + In an email thread from September 3, 2011, Rob Meijer announced the initial set of specifications for a rewrite of MinorFS. He expressed disappointment in receiving no response to his previous post about interest in using this updated version with Bitcoin on systems that support AppArmor like Ubuntu and OpenSuse. However, others in the thread expressed their interest in this update. One individual stated that more strict privilege separation between applications would be necessary for Ubuntu if they want to keep up with Android and MacOSX. They noted that this has been needed for a while and would be useful for any private data managed by applications running as the same user, such as SSH, browsers, and PGP. The discussion then turned to security measures, with one participant noting that wallet encryption is useful but not a substitute for OS-level protection. In response to Rob's announcement, an individual asked if it was necessary to rewrite the entire thing from scratch and questioned whether it could be compared to the Android model which uses a UID per application/user. They wondered if layering security on top of current UNIX/ACL permissions would be sufficient without needing another filesystem altogether.Rob Meijer proposed an updated version of MinorFs, a least authority based set of filesystems that could be used by Bitcoin on systems that support AppArmor like Ubuntu and OpenSuse. The purpose is to give pseudo-persistent processes their own private but decomposable and delegatable piece of filesystem storage, which is suitable for applications that want to protect user data such as Bitcoin wallets from malware running under the same UID as that user. Currently, wallet encryption is a simpler solution for end-users than MinorFs. Rob Meijer is trying to get specifications together for rewriting MinorFs in Python that would make it easier and more natural for application developers who want to protect user data. However, there are some concerns about whether MinorFs can work without changes to Bitcoin and if not, what is the minimal amount of changes needed. Additionally, there are questions about whether MinorFs would help secure the wallet on a server, maybe even an insecure VPS. Moreover, there is no guarantee that MinorFs will never corrupt the wallet; hence, it is essential to find out the proper way to do backups. Given that Bitcoin could benefit most from what MinorFs has to offer, Rob Meijer asked Bitcoin developers to think about what attributes from the current granularity level should be kept, what attributes should be dropped, and what properties should be added to arrive at an 'id' that is the best fit for granularity of persistent private storage for Bitcoin. He also welcomes all input that helps him accommodate Bitcoin developer needs so that code to use MinorFs where available can be added to Bitcoin.The author of a least authority based set of filesystems named MinorFs, Rob Meijer, is looking to update the system for use by bitcoin on systems that support AppArmor. Although there has been little interest in an updated version, Meijer has created a set of proposed specifications for a rewrite of MinorFs and is open to suggestions. The current granularity level of MinorFs is hard fixed to that of the 'pseudo persistent process'. Meijer believes that the next version should take an approach that better suits common development languages and practices. He is seeking input from bitcoin developers to create an 'id' that is the best fit for granularity of persistent private storage for bitcoin. Meijer wants to accommodate bitcoin developer needs so that code to use MinorFs where available can be added to bitcoin.A few years ago, Rob wrote a set of filesystems called MinorFs. It worked closely with AppArmor to give "pseudo persistent processes" their own private but decomposable and delegatable piece of filesystem storage. Currently, only one perfect fit for MinorFs exists, which is the stack AppArmor/MinorFs/E-language-persistent-application. However, some close fits, like running ssh without a passphrase, require lots of manual fiddling by the user to get working.Rob is trying to rewrite MinorFs in Python in a way that would make it easy and natural for application developers who want their application to protect user data from mallware running under the same uid as that user, such as bitcoin wallets. Currently, minorfs granularity is hard fixed to that of the "pseudo persistent process," and that granularity is determined in the pseudo persistent process link.Using pseudo persistent processes results in file-system storage that follows almost all of the modeling principles of the object capability model. Rob expects that Bitcoin, openssh, chrome, Firefox, or any other application that would benefit from what MinorFs provides will not be rewritten in E. Therefore, the next version of MinorFs should take an approach that better suits common development languages and practices, abandoning the purity of its least authority model.Rob wants Bitcoin developers to think about what attributes from the current granularity level should be kept, what attributes should be dropped, and what properties should be added to arrive at an "id" that - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2013/combined_Draft-BIP-for-Bloom-filtering.xml b/static/bitcoin-dev/Jan_2013/combined_Draft-BIP-for-Bloom-filtering.xml index d11a8d6a99..86738d5803 100644 --- a/static/bitcoin-dev/Jan_2013/combined_Draft-BIP-for-Bloom-filtering.xml +++ b/static/bitcoin-dev/Jan_2013/combined_Draft-BIP-for-Bloom-filtering.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP for Bloom filtering - 2023-08-01T04:02:04.922697+00:00 + 2025-10-11T21:56:12.561740+00:00 + python-feedgen Mike Hearn 2013-02-20 12:44:56+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for Bloom filtering - 2023-08-01T04:02:04.922697+00:00 + 2025-10-11T21:56:12.561982+00:00 - In the provided context, the author discusses the proposal for delaying the reception of inventory messages (invs) in the Bitcoin Improvement Proposal (BIP). They realize that the current method of delaying invs is arbitrary and suggest a better approach. The proposed solution involves sending a bloom filter in the version message itself, allowing for the filter to be calculated simultaneously with establishing network connections.The author acknowledges that creating a Bloom filter is a fast process. However, they note that deterministic wallets may require multiple calculations to find the keys to scan for. Despite this potential complexity, the proposed approach of including a bloom filter in the version message allows for efficient parallel processing.Additionally, the author mentions the process of obtaining an allocated number for the BIP. They feel that this process may be excessive for their particular proposal. This demonstrates the author's consideration of the existing procedures and their awareness of the broader framework within which their suggestion exists.By addressing the issue of delaying invs and proposing an alternative method involving bloom filters, the author highlights a potential improvement to the Bitcoin protocol. Their understanding of the technical aspects and the existing processes surrounding BIPs lends credibility to their proposal. 2013-02-20T12:44:56+00:00 + In the provided context, the author discusses the proposal for delaying the reception of inventory messages (invs) in the Bitcoin Improvement Proposal (BIP). They realize that the current method of delaying invs is arbitrary and suggest a better approach. The proposed solution involves sending a bloom filter in the version message itself, allowing for the filter to be calculated simultaneously with establishing network connections.The author acknowledges that creating a Bloom filter is a fast process. However, they note that deterministic wallets may require multiple calculations to find the keys to scan for. Despite this potential complexity, the proposed approach of including a bloom filter in the version message allows for efficient parallel processing.Additionally, the author mentions the process of obtaining an allocated number for the BIP. They feel that this process may be excessive for their particular proposal. This demonstrates the author's consideration of the existing procedures and their awareness of the broader framework within which their suggestion exists.By addressing the issue of delaying invs and proposing an alternative method involving bloom filters, the author highlights a potential improvement to the Bitcoin protocol. Their understanding of the technical aspects and the existing processes surrounding BIPs lends credibility to their proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2013/combined_Proposal-make-the-private-key-for-testnet-genesis-block-public.xml b/static/bitcoin-dev/Jan_2013/combined_Proposal-make-the-private-key-for-testnet-genesis-block-public.xml index 984b71ce24..90752d695c 100644 --- a/static/bitcoin-dev/Jan_2013/combined_Proposal-make-the-private-key-for-testnet-genesis-block-public.xml +++ b/static/bitcoin-dev/Jan_2013/combined_Proposal-make-the-private-key-for-testnet-genesis-block-public.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: make the private key for testnet genesis block public - 2023-08-01T04:23:57.338596+00:00 + 2025-10-11T21:56:06.189625+00:00 + python-feedgen Gavin Andresen 2013-01-14 18:31:59+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Proposal: make the private key for testnet genesis block public - 2023-08-01T04:23:57.339607+00:00 + 2025-10-11T21:56:06.189788+00:00 - During a discussion about the testnet3 genesis block, Gavin Andresen mentioned that the only differences between the testnet3 and main network genesis blocks are the timestamp and nonce. He explained that while the coinbase of testnet3 pays to the same public key as the main network, he does not have the private key for it. However, he suggested that it would be a good idea to implement this change for the future testnet4.In an email exchange between Peter Todd and Jeff Garzik, Todd proposed that on the testnet, individuals should be given the opportunity to test their code's ability to handle attempts to spend the genesis block coinbase and other transactions made to the genesis block address. He argued that since Satoshi may still possess the key to the genesis block, he could potentially create such a situation himself. Garzik acknowledged Todd's suggestion.The author of the email also supported Todd's proposal, emphasizing that allowing people to test how their code handles attempts to spend the genesis block coinbase and other transactions on the testnet would be beneficial. The author pointed out that there is a possibility that Satoshi still holds the key and could potentially cause such a situation. To address this, the author requested Gavin, who might have the private key for testnet3's coinbase, to either release it or fix the issue for the eventual testnet4. The author noted that although this case could be tested on a private testnet, it would be more advantageous if individuals were compelled to test it against their will. 2013-01-14T18:31:59+00:00 + During a discussion about the testnet3 genesis block, Gavin Andresen mentioned that the only differences between the testnet3 and main network genesis blocks are the timestamp and nonce. He explained that while the coinbase of testnet3 pays to the same public key as the main network, he does not have the private key for it. However, he suggested that it would be a good idea to implement this change for the future testnet4.In an email exchange between Peter Todd and Jeff Garzik, Todd proposed that on the testnet, individuals should be given the opportunity to test their code's ability to handle attempts to spend the genesis block coinbase and other transactions made to the genesis block address. He argued that since Satoshi may still possess the key to the genesis block, he could potentially create such a situation himself. Garzik acknowledged Todd's suggestion.The author of the email also supported Todd's proposal, emphasizing that allowing people to test how their code handles attempts to spend the genesis block coinbase and other transactions on the testnet would be beneficial. The author pointed out that there is a possibility that Satoshi still holds the key and could potentially cause such a situation. To address this, the author requested Gavin, who might have the private key for testnet3's coinbase, to either release it or fix the issue for the eventual testnet4. The author noted that although this case could be tested on a private testnet, it would be more advantageous if individuals were compelled to test it against their will. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2013/combined_Testnet-DNS-seed.xml b/static/bitcoin-dev/Jan_2013/combined_Testnet-DNS-seed.xml index 30abecaa8e..2f76faa2f3 100644 --- a/static/bitcoin-dev/Jan_2013/combined_Testnet-DNS-seed.xml +++ b/static/bitcoin-dev/Jan_2013/combined_Testnet-DNS-seed.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Testnet DNS seed - 2023-08-01T04:24:14.802369+00:00 + 2025-10-11T21:56:10.435987+00:00 + python-feedgen Pieter Wuille 2013-01-27 16:18:43+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Testnet DNS seed - 2023-08-01T04:24:14.802369+00:00 + 2025-10-11T21:56:10.436143+00:00 - In an email conversation, Peter Todd discusses the contents of seed.txt, a dumpfile produced by bitcoin-seeder that contains information about non-banned IP addresses that have connected to Bitcoin. He mentions having a script prepared to combine data from multiple seed.txt files into a pnSeed[] array C source code and plans to add it to the repository.Todd and Jeff Garzik discuss the possibility of running a seed node on an Amazon EC2 micro instance. However, IPv4 is currently supported, but not IPv6, and there is no Tor setup yet. Todd intends to run the node indefinitely as it is relatively cheap at $7.5/month and offers to provide a machine image copy to others. They also talk about updating the pnSeed list, which is outdated. Todd suggests a scripted process to transform Pieter's seeds.txt into pnSeed[], filtering it with SORB's dynamic IP list and adding an expiry time of one year for transparency and easy maintenance.They further discuss the dedicated Amazon EC2 micro instance, with Todd stating that he can set up IPv6 and Tor if there is demand. Garzik suggests having at least one more person contribute a testnet seed to the list and keeping IRC enabled. Todd notes that the pnSeed list is out of date and proposes transforming Pieter's seeds.txt into pnSeed[] as an alternative. The duration of Todd's plan to run the instance is unknown but expects it to continue indefinitely if there is interest.The author has set up a testnet DNS seed using Pieter Wuille's bitcoin-seeder on an Amazon EC2 micro instance. Currently, only IPv4 is supported due to EC2's lack of IPv6 support, and Tor hasn't been set up yet, but the author can do so if there is demand. The next step is to create a new strTestNetDNSSeed in the Satoshi client and would prefer another person to contribute a testnet seed to the list. Enabling IRC is also recommended. Additionally, the author mentions that the pnSeed list is outdated and asks Pieter if he has written any start/stop/monitoring scripts for the seeder. The modifications made by the author can be found at git://github.com/petertodd/bitcoin-seeder.git in the "testnet" branch, with intentions to send a pull request after testing. 2013-01-27T16:18:43+00:00 + In an email conversation, Peter Todd discusses the contents of seed.txt, a dumpfile produced by bitcoin-seeder that contains information about non-banned IP addresses that have connected to Bitcoin. He mentions having a script prepared to combine data from multiple seed.txt files into a pnSeed[] array C source code and plans to add it to the repository.Todd and Jeff Garzik discuss the possibility of running a seed node on an Amazon EC2 micro instance. However, IPv4 is currently supported, but not IPv6, and there is no Tor setup yet. Todd intends to run the node indefinitely as it is relatively cheap at $7.5/month and offers to provide a machine image copy to others. They also talk about updating the pnSeed list, which is outdated. Todd suggests a scripted process to transform Pieter's seeds.txt into pnSeed[], filtering it with SORB's dynamic IP list and adding an expiry time of one year for transparency and easy maintenance.They further discuss the dedicated Amazon EC2 micro instance, with Todd stating that he can set up IPv6 and Tor if there is demand. Garzik suggests having at least one more person contribute a testnet seed to the list and keeping IRC enabled. Todd notes that the pnSeed list is out of date and proposes transforming Pieter's seeds.txt into pnSeed[] as an alternative. The duration of Todd's plan to run the instance is unknown but expects it to continue indefinitely if there is interest.The author has set up a testnet DNS seed using Pieter Wuille's bitcoin-seeder on an Amazon EC2 micro instance. Currently, only IPv4 is supported due to EC2's lack of IPv6 support, and Tor hasn't been set up yet, but the author can do so if there is demand. The next step is to create a new strTestNetDNSSeed in the Satoshi client and would prefer another person to contribute a testnet seed to the list. Enabling IRC is also recommended. Additionally, the author mentions that the pnSeed list is outdated and asks Pieter if he has written any start/stop/monitoring scripts for the seeder. The modifications made by the author can be found at git://github.com/petertodd/bitcoin-seeder.git in the "testnet" branch, with intentions to send a pull request after testing. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_-space-efficient-reusable-addr-via-weil-pairing-IBE-Re-Bait-for-reusable-addresses-.xml b/static/bitcoin-dev/Jan_2014/combined_-space-efficient-reusable-addr-via-weil-pairing-IBE-Re-Bait-for-reusable-addresses-.xml index 2bf57617ad..11582cda55 100644 --- a/static/bitcoin-dev/Jan_2014/combined_-space-efficient-reusable-addr-via-weil-pairing-IBE-Re-Bait-for-reusable-addresses-.xml +++ b/static/bitcoin-dev/Jan_2014/combined_-space-efficient-reusable-addr-via-weil-pairing-IBE-Re-Bait-for-reusable-addresses-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses) - 2023-08-01T07:19:18.923860+00:00 + 2025-10-11T22:03:53.998152+00:00 + python-feedgen Adam Back 2014-02-02 15:26:24+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses) - 2023-08-01T07:19:18.924921+00:00 + 2025-10-11T22:03:53.998282+00:00 - The email exchange between Adam Back, Peter Todd, and Jeremy Spilman discusses the use of Identity-Based Encryption (IBE) scheme to increase privacy in transactions. The IBE scheme involves using 'filter' and 'recovery' pubkeys to encrypt a string of zeros called 'filter bait'. This bait is placed in transactions for later decryption by third parties. When enough zeros are decrypted, it is considered a filter pass and the transaction is sent to the payor. Combining IBE schemes with public prefixes can optimize results, but it reduces anonymity when combined with flow analysis. Finding a non-IBE method may be more computationally efficient and indexable. Alternative methods like one-use, stealth, or IBE addresses are also suggested.In another discussion, the focus is on securely delegating block searching by computing the private key for the IBE pub key used for that block and sending it as a query to a random node. The node can decrypt the encrypted bloom baits but cannot correlate them with other payments received by the same user. The payor needs separate pub keys for filtering and recovery. Shared secrets derived from these keys can be given to a semi-trusted third party for trial decryption of filter bait in transactions. A sufficient number of zeros in the decrypted string constitutes a filter pass, and the transaction is given to the payor. The full node uses the private key to decrypt specific bytes in transactions that match the expected layout. This decrypted byte serves as bloom bait. Both schemes can be used together, combining a short public prefix with a private filter.Adam Back also discussed reusable addresses with several people, proposing an ECC-based version to address issues of payment to bandwidth-constrained and frequently offline recipients while maintaining privacy. Bob publicly publishes three pubkeys along with a short prefix. When Alice wants to pay Bob, she creates an ephemeral keypair and derives shared secrets from Bob's pubkeys. She includes the derived pubkey in the transaction along with an encrypted prefix derived from the filter nonce and the prefix. Bob can find the transaction by giving the prefix and filter secret key to a trusted party who scans the blockchain. This method allows Bob to maintain privacy, while Ivan, the scanning party, only gains probabilistic information about possible transactions. Eve remains unaware of the Filter secret key and learns nothing from the blockchain data.The context also mentions the desire for a time-limited Filter pubkey derived from a public random beacon with different keys for each defined time interval. Identity-based cryptography is suggested as a solution where Bob publishes a master public key, allowing derivation of public keys based on the master key and the random beacon value.Adam Back proposed a proof-of-concept solution for better space efficiency and linkability defense reusable addresses using an IBE scheme. He used IBE as a building block to create a sequence of public keys with specific properties. The reusable address becomes an IBE public key, and encryption with the previous block hash serves as the "identity". A separate message for secure delegatable filtering is sent, adding encrypted bloom bait and potentially combining it with extended bloom bait for anonymity set within the block. While reusing addresses is not ideal, Adam Back's proposal aims to make address reuse more private and less likely to leak metadata.Lastly, Adam Back mentioned his idea of a space-efficient alternative to bloom filters using IBE based on weil-pairing. This allows for the delegation of decryption specific to the queried block without the node correlating with queries from the same user in other blocks. Further possibilities of delegating filtering without introducing additional complexity or using public key steganography were discussed.Overall, the discussions revolve around enhancing privacy and efficiency in blockchain transactions through various cryptographic schemes and methods. 2014-02-02T15:26:24+00:00 + The email exchange between Adam Back, Peter Todd, and Jeremy Spilman discusses the use of Identity-Based Encryption (IBE) scheme to increase privacy in transactions. The IBE scheme involves using 'filter' and 'recovery' pubkeys to encrypt a string of zeros called 'filter bait'. This bait is placed in transactions for later decryption by third parties. When enough zeros are decrypted, it is considered a filter pass and the transaction is sent to the payor. Combining IBE schemes with public prefixes can optimize results, but it reduces anonymity when combined with flow analysis. Finding a non-IBE method may be more computationally efficient and indexable. Alternative methods like one-use, stealth, or IBE addresses are also suggested.In another discussion, the focus is on securely delegating block searching by computing the private key for the IBE pub key used for that block and sending it as a query to a random node. The node can decrypt the encrypted bloom baits but cannot correlate them with other payments received by the same user. The payor needs separate pub keys for filtering and recovery. Shared secrets derived from these keys can be given to a semi-trusted third party for trial decryption of filter bait in transactions. A sufficient number of zeros in the decrypted string constitutes a filter pass, and the transaction is given to the payor. The full node uses the private key to decrypt specific bytes in transactions that match the expected layout. This decrypted byte serves as bloom bait. Both schemes can be used together, combining a short public prefix with a private filter.Adam Back also discussed reusable addresses with several people, proposing an ECC-based version to address issues of payment to bandwidth-constrained and frequently offline recipients while maintaining privacy. Bob publicly publishes three pubkeys along with a short prefix. When Alice wants to pay Bob, she creates an ephemeral keypair and derives shared secrets from Bob's pubkeys. She includes the derived pubkey in the transaction along with an encrypted prefix derived from the filter nonce and the prefix. Bob can find the transaction by giving the prefix and filter secret key to a trusted party who scans the blockchain. This method allows Bob to maintain privacy, while Ivan, the scanning party, only gains probabilistic information about possible transactions. Eve remains unaware of the Filter secret key and learns nothing from the blockchain data.The context also mentions the desire for a time-limited Filter pubkey derived from a public random beacon with different keys for each defined time interval. Identity-based cryptography is suggested as a solution where Bob publishes a master public key, allowing derivation of public keys based on the master key and the random beacon value.Adam Back proposed a proof-of-concept solution for better space efficiency and linkability defense reusable addresses using an IBE scheme. He used IBE as a building block to create a sequence of public keys with specific properties. The reusable address becomes an IBE public key, and encryption with the previous block hash serves as the "identity". A separate message for secure delegatable filtering is sent, adding encrypted bloom bait and potentially combining it with extended bloom bait for anonymity set within the block. While reusing addresses is not ideal, Adam Back's proposal aims to make address reuse more private and less likely to leak metadata.Lastly, Adam Back mentioned his idea of a space-efficient alternative to bloom filters using IBE based on weil-pairing. This allows for the delegation of decryption specific to the queried block without the node correlating with queries from the same user in other blocks. Further possibilities of delegating filtering without introducing additional complexity or using public key steganography were discussed.Overall, the discussions revolve around enhancing privacy and efficiency in blockchain transactions through various cryptographic schemes and methods. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_An-idea-for-alternative-payment-scheme.xml b/static/bitcoin-dev/Jan_2014/combined_An-idea-for-alternative-payment-scheme.xml index 44ed24ac8a..9dc9eb0a9e 100644 --- a/static/bitcoin-dev/Jan_2014/combined_An-idea-for-alternative-payment-scheme.xml +++ b/static/bitcoin-dev/Jan_2014/combined_An-idea-for-alternative-payment-scheme.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - An idea for alternative payment scheme - 2023-08-01T07:10:55.609045+00:00 + 2025-10-11T22:03:11.502243+00:00 + python-feedgen Peter Todd 2014-01-03 20:39:39+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - An idea for alternative payment scheme - 2023-08-01T07:10:55.609045+00:00 + 2025-10-11T22:03:11.502444+00:00 - In an email exchange, Adam Back and Nadav discuss a proposal for a payment scheme using key derivation. This proposal aims to address the limitation of lack of Simple Payment Verification (SPV) compatibility by allowing the recipient to test each payment or the sender to send the derivation key out of band. Adam believes that this proposal has the potential to be more SPV compatible compared to other alternatives. He suggests using prefix filters to receive unlimited unrelated payments with a fixed bandwidth/anonymity set size tradeoff.Adam also points out that approaches such as BIP38 with UI's for creating a new address for every payment have drawbacks. They either increase bandwidth consumption, decrease anonymity set size, or result in lost payments. He acknowledges that most of the bitcoin infrastructure currently uses the bitcoin broadcast channel as the communication channel, which supports payer and payee not being simultaneously online. However, he emphasizes the importance of ensuring that the key is not lost and subsequent data loss events do not result in the loss of money for the recipient.In response to Nadav's suggestion, another user named Gregory Maxwell introduces a different payment scheme. In this scheme, the payee publishes two public keys and the payer picks a k value for signatures. The payer pays to a pubkey derived from multiplying PP2*k with r in the first signature or in an OP_RETURN additional output. The payer advises the payee that PP+(pp2_secret*r) can be redeemed. This scheme offers advantages such as funds not being lost if the payer's computer crashes and complete confidentiality. However, there are downsides, including breaking deterministic DSA unless an OP_RETURN is used.The message also discusses deterministic signatures, which involve generating an ECDSA k value using a private key and HMAC construction. The buyer could generate a random number from a root key, allowing them to recreate their receipts. However, storing the master root on the buyer's computer is necessary. The writer suggests that the payment protocol should already have a similar mechanism.Nadav's proposed payment scheme involves the payer deriving addresses using a random "receipt number" and the payee's master public key. The payer pays to this derived address and sends the receipt to the payee, who derives a private key with it and adds it to their wallet. This scheme offers increased privacy by avoiding address reuse and is asynchronous. It can be used as a replacement for cases where re-used addresses are the most viable solution. The receipt serves as proof of payment, and if the master is known, the payer can prove the payment to a third-party. However, losing the receipt numbers means losing access to funds, and a better-defined channel for sending the receipt to the payee would be beneficial.Overall, the proposed payment schemes aim to improve SPV compatibility, privacy, and convenience in Bitcoin transactions. They introduce various approaches such as key derivation, prefix filters, and deterministic signatures. While they have advantages, there are also limitations and considerations to address. 2014-01-03T20:39:39+00:00 + In an email exchange, Adam Back and Nadav discuss a proposal for a payment scheme using key derivation. This proposal aims to address the limitation of lack of Simple Payment Verification (SPV) compatibility by allowing the recipient to test each payment or the sender to send the derivation key out of band. Adam believes that this proposal has the potential to be more SPV compatible compared to other alternatives. He suggests using prefix filters to receive unlimited unrelated payments with a fixed bandwidth/anonymity set size tradeoff.Adam also points out that approaches such as BIP38 with UI's for creating a new address for every payment have drawbacks. They either increase bandwidth consumption, decrease anonymity set size, or result in lost payments. He acknowledges that most of the bitcoin infrastructure currently uses the bitcoin broadcast channel as the communication channel, which supports payer and payee not being simultaneously online. However, he emphasizes the importance of ensuring that the key is not lost and subsequent data loss events do not result in the loss of money for the recipient.In response to Nadav's suggestion, another user named Gregory Maxwell introduces a different payment scheme. In this scheme, the payee publishes two public keys and the payer picks a k value for signatures. The payer pays to a pubkey derived from multiplying PP2*k with r in the first signature or in an OP_RETURN additional output. The payer advises the payee that PP+(pp2_secret*r) can be redeemed. This scheme offers advantages such as funds not being lost if the payer's computer crashes and complete confidentiality. However, there are downsides, including breaking deterministic DSA unless an OP_RETURN is used.The message also discusses deterministic signatures, which involve generating an ECDSA k value using a private key and HMAC construction. The buyer could generate a random number from a root key, allowing them to recreate their receipts. However, storing the master root on the buyer's computer is necessary. The writer suggests that the payment protocol should already have a similar mechanism.Nadav's proposed payment scheme involves the payer deriving addresses using a random "receipt number" and the payee's master public key. The payer pays to this derived address and sends the receipt to the payee, who derives a private key with it and adds it to their wallet. This scheme offers increased privacy by avoiding address reuse and is asynchronous. It can be used as a replacement for cases where re-used addresses are the most viable solution. The receipt serves as proof of payment, and if the master is known, the payer can prove the payment to a third-party. However, losing the receipt numbers means losing access to funds, and a better-defined channel for sending the receipt to the payee would be beneficial.Overall, the proposed payment schemes aim to improve SPV compatibility, privacy, and convenience in Bitcoin transactions. They introduce various approaches such as key derivation, prefix filters, and deterministic signatures. While they have advantages, there are also limitations and considerations to address. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_BIP-proposal-Authenticated-prefix-trees.xml b/static/bitcoin-dev/Jan_2014/combined_BIP-proposal-Authenticated-prefix-trees.xml index 44f5013046..3fdd73f8ef 100644 --- a/static/bitcoin-dev/Jan_2014/combined_BIP-proposal-Authenticated-prefix-trees.xml +++ b/static/bitcoin-dev/Jan_2014/combined_BIP-proposal-Authenticated-prefix-trees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP proposal: Authenticated prefix trees - 2023-08-01T06:54:07.665191+00:00 + 2025-10-11T22:03:43.376116+00:00 + python-feedgen Mark Friedenbach 2014-01-08 01:04:58+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - BIP proposal: Authenticated prefix trees - 2023-08-01T06:54:07.665191+00:00 + 2025-10-11T22:03:43.376281+00:00 - On January 6th, 2014, Gregory Maxwell proposed restructuring the current unspent transaction output (UTXO) index as a Merkle tree. This change would allow nodes without access to the UTXO set to still receive transactions or blocks with prefixed proofs and check their validity.Thomas Voegtlin had developed a Python-levelDB implementation of the UTXO hash tree and suggested creating per-block indexes of all scriptPubKeys, spent or unspent, queryable via partial prefix method. In response, Peter Todd recommended thoroughly testing the implementation on Electrum and adding a C++ implementation to Bitcoin Core. He also mentioned the need for performance testing and usability assessment before any soft-fork.Thomas Voegtlin expressed appreciation for Mark Friedenbach's work on the UTXO hash tree and stated its importance for Electrum. He suggested testing different options before writing a BIP and questioned the possibility of partial prefix queries on the tree.The email thread discussed a new Merkle-compressed data structure that has applications in committed validation indices, wallet indices, document time-stamping, and merged mining. The structure is based on a binary prefix tree and has a Python and C++ implementation. The serialization format of the authenticated prefix tree was described in detail.Gregory Maxwell posted questions regarding the proposed data structure, including the structure of VARCHAR(), extradata position, and the possibility of using SHA-512/256. He raised concerns about the performance cost of validating the structure under a zero-knowledge proof.Mark Friedenbach shared a first draft of a BIP for the new data structure, discussing the nature of VARCHAR(), extradata position, and midstate compression. He mentioned that CPU performance should not be a major consideration but the cost of validating under a zero-knowledge proof should be taken into account. Prefix tree compressed applications were discussed, noting that they could only be used if all verifying nodes had all their data under the tree.Peter Todd expressed his disagreement with UTXO commitments, arguing that they forced miners and full nodes with SPV clients to store the entire UTXO set perpetually. He also raised concerns about security and trust in single confirmations.Mark Friedenbach proposed stateless validation and mining involving prefixing messages with proofs of UTxO state changes. Peter Todd disagreed with UTXO commitments and suggested taking this technology to Namecoin instead.The email exchange on December 20, 2013, discussed authenticated prefix trees and their variations. The BIPs described the application of these trees to committed indices, document time-stamping, and merged mining. Mark Friedenbach mentioned advantages and added bytes to the coinbase transaction. Peter Todd provided feedback on the code examples, suggesting leaving out Unicode.In another email, Mark proposed application-oriented BIPs related to authenticated prefix trees. Stateless validation and mining involved prefixing messages with proofs of state changes. Ultimate blockchain compression involved consensus over an address index queried by lightweight nodes. The structure of the index was an authenticated prefix tree. Mark believed these BIPs affected the interoperability of the bitcoin protocol and clients using these applications.Overall, the email thread discussed various proposals and implementations related to restructuring the UTXO index, creating authenticated prefix trees, and their applications in the bitcoin ecosystem.The article discusses the proposal of introducing additional Bitcoin Improvement Proposals (BIPs) that describe the use of an authenticated prefix tree data structure for various applications. The author questions whether the BIP can stand alone without specific changes to the protocol or end-user accessible features, as BIPs are meant to define interoperability rather than implementation details. However, they express interest in reading about BIPs that utilize the tree to achieve scalability or security benefits.Bitcoin developer Mark Friedenbach has drafted a BIP for a new Merkle-compressed data structure called the authenticated prefix tree. This data structure is ideal for encoding key-value indices that support memory-efficient proofs. It is a hybrid PATRICIA / de la Brandais tree structure that compresses non-branching nodes into a single interior node with a skip prefix. This reduces the serialized size and the number of hash operations required for updates and proof validation. The authenticated prefix tree can be used for committed validation indices, wallet indices, document time-stamping, and merged mining.The article discusses two variations of the authenticated prefix tree presented in the draft BIP, which differ in the construction of hash values for nodes and their branches. The first variation is level-compressed hashing, where the referenced child node's hash is used in the interior node's hash digest. The second variation is proof-updatable hashing, where level-compressed branches are expanded into chained single-branch internal nodes. Both variations trade computational resources for the ability to compose operational proofs.Inclusion proofs, which are pruned prefix trees, are explained in the article. The serialization of inclusion proofs and operational proofs is also discussed, including their encoding in base64 format for display and transport 2014-01-08T01:04:58+00:00 + On January 6th, 2014, Gregory Maxwell proposed restructuring the current unspent transaction output (UTXO) index as a Merkle tree. This change would allow nodes without access to the UTXO set to still receive transactions or blocks with prefixed proofs and check their validity.Thomas Voegtlin had developed a Python-levelDB implementation of the UTXO hash tree and suggested creating per-block indexes of all scriptPubKeys, spent or unspent, queryable via partial prefix method. In response, Peter Todd recommended thoroughly testing the implementation on Electrum and adding a C++ implementation to Bitcoin Core. He also mentioned the need for performance testing and usability assessment before any soft-fork.Thomas Voegtlin expressed appreciation for Mark Friedenbach's work on the UTXO hash tree and stated its importance for Electrum. He suggested testing different options before writing a BIP and questioned the possibility of partial prefix queries on the tree.The email thread discussed a new Merkle-compressed data structure that has applications in committed validation indices, wallet indices, document time-stamping, and merged mining. The structure is based on a binary prefix tree and has a Python and C++ implementation. The serialization format of the authenticated prefix tree was described in detail.Gregory Maxwell posted questions regarding the proposed data structure, including the structure of VARCHAR(), extradata position, and the possibility of using SHA-512/256. He raised concerns about the performance cost of validating the structure under a zero-knowledge proof.Mark Friedenbach shared a first draft of a BIP for the new data structure, discussing the nature of VARCHAR(), extradata position, and midstate compression. He mentioned that CPU performance should not be a major consideration but the cost of validating under a zero-knowledge proof should be taken into account. Prefix tree compressed applications were discussed, noting that they could only be used if all verifying nodes had all their data under the tree.Peter Todd expressed his disagreement with UTXO commitments, arguing that they forced miners and full nodes with SPV clients to store the entire UTXO set perpetually. He also raised concerns about security and trust in single confirmations.Mark Friedenbach proposed stateless validation and mining involving prefixing messages with proofs of UTxO state changes. Peter Todd disagreed with UTXO commitments and suggested taking this technology to Namecoin instead.The email exchange on December 20, 2013, discussed authenticated prefix trees and their variations. The BIPs described the application of these trees to committed indices, document time-stamping, and merged mining. Mark Friedenbach mentioned advantages and added bytes to the coinbase transaction. Peter Todd provided feedback on the code examples, suggesting leaving out Unicode.In another email, Mark proposed application-oriented BIPs related to authenticated prefix trees. Stateless validation and mining involved prefixing messages with proofs of state changes. Ultimate blockchain compression involved consensus over an address index queried by lightweight nodes. The structure of the index was an authenticated prefix tree. Mark believed these BIPs affected the interoperability of the bitcoin protocol and clients using these applications.Overall, the email thread discussed various proposals and implementations related to restructuring the UTXO index, creating authenticated prefix trees, and their applications in the bitcoin ecosystem.The article discusses the proposal of introducing additional Bitcoin Improvement Proposals (BIPs) that describe the use of an authenticated prefix tree data structure for various applications. The author questions whether the BIP can stand alone without specific changes to the protocol or end-user accessible features, as BIPs are meant to define interoperability rather than implementation details. However, they express interest in reading about BIPs that utilize the tree to achieve scalability or security benefits.Bitcoin developer Mark Friedenbach has drafted a BIP for a new Merkle-compressed data structure called the authenticated prefix tree. This data structure is ideal for encoding key-value indices that support memory-efficient proofs. It is a hybrid PATRICIA / de la Brandais tree structure that compresses non-branching nodes into a single interior node with a skip prefix. This reduces the serialized size and the number of hash operations required for updates and proof validation. The authenticated prefix tree can be used for committed validation indices, wallet indices, document time-stamping, and merged mining.The article discusses two variations of the authenticated prefix tree presented in the draft BIP, which differ in the construction of hash values for nodes and their branches. The first variation is level-compressed hashing, where the referenced child node's hash is used in the interior node's hash digest. The second variation is proof-updatable hashing, where level-compressed branches are expanded into chained single-branch internal nodes. Both variations trade computational resources for the ability to compose operational proofs.Inclusion proofs, which are pruned prefix trees, are explained in the article. The serialization of inclusion proofs and operational proofs is also discussed, including their encoding in base64 format for display and transport - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_BIP-register-with-IANA-for-bitcoin-cryptocoin-port-numbers.xml b/static/bitcoin-dev/Jan_2014/combined_BIP-register-with-IANA-for-bitcoin-cryptocoin-port-numbers.xml index fdea71d65e..1233b89c21 100644 --- a/static/bitcoin-dev/Jan_2014/combined_BIP-register-with-IANA-for-bitcoin-cryptocoin-port-numbers.xml +++ b/static/bitcoin-dev/Jan_2014/combined_BIP-register-with-IANA-for-bitcoin-cryptocoin-port-numbers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: register with IANA for bitcoin/cryptocoin port numbers - 2023-08-01T07:10:32.713510+00:00 + 2025-10-11T22:03:15.753946+00:00 + python-feedgen Wladimir 2014-01-03 08:16:55+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP: register with IANA for bitcoin/cryptocoin port numbers - 2023-08-01T07:10:32.714510+00:00 + 2025-10-11T22:03:15.754080+00:00 - The discussion revolves around the use of ports for Bitcoin, with a suggestion to have separate ports for the main network and the test network. It is argued that since these networks are entirely separate, there is no logic in multiplexing them. If conservation is a concern, the testnet port can be forgone. In case the port is already in use, Bitcoin can run on any other available port and announce it. The convenience argument is also questioned since most users don't specify nodes and can specify a port when necessary. The reservation of ports by alt coins is not a concern for Bitcoin, and it may be feasible for Bitcoin to allocate one or two ports for its use.On January 2, 2014, Troy Benjegerdes sent an email with three questions regarding Bitcoin. The first question asks why Bitcoin typically runs on port 8333. The second question is about Bitcoin's absence from the Internet Assigned Numbers Authority (IANA) website's list of service names and port numbers. Lastly, Benjegerdes inquires about how someone from the Bitcoin Foundation can fill out a form to request an assigned port. Although the reasons behind these questions are unclear, they shed light on the technical aspects of Bitcoin and its utilization of ports. In response to the questions, it is mentioned that a request for an assignment for Bitcoin has been made, but the details of who made the request and its success are unknown. Overall, the email provides insight into the technical details of Bitcoin and the process for obtaining an assigned port. However, further context is needed to fully grasp the significance of these questions and their underlying motivations.In another email dated January 3, 2014, Troy Benjegerdes poses several inquiries related to Bitcoin's usage of port 8333 and its absence from the IANA registry. He asks about the procedure for someone from the Bitcoin Foundation to fill out a form requesting an assigned port and the process for new cryptocurrencies to acquire default port numbers and P2P network identifier 'magic numbers'. IANA usually registers ports with conservation in mind, and currently, two unassigned ports (8333 and 18333) are available. While having separate ports for the main net and test net would be ideal, only one may be granted due to conservation considerations. The possibility of multiplexing traffic over a single port is also raised. The email includes a list of other assigned and unassigned ports, highlighting the potential concerns that may arise if a multitude of alternative coins reserve ports.In summary, questions have been raised regarding Bitcoin's port number and its visibility on IANA's website. The reasons behind Bitcoin's use of port 8333 remain unknown, and its absence from the IANA registry raises confusion about its legitimacy. Additionally, inquiries have been made about the process for someone from the Bitcoin Foundation to request an assigned port through IANA's form. Furthermore, the procedure for new cryptocurrencies to obtain default port numbers and P2P network identifier 'magic numbers' is being questioned. Addressing these issues is essential to clarify Bitcoin's status and provide guidance for future cryptocurrencies. 2014-01-03T08:16:55+00:00 + The discussion revolves around the use of ports for Bitcoin, with a suggestion to have separate ports for the main network and the test network. It is argued that since these networks are entirely separate, there is no logic in multiplexing them. If conservation is a concern, the testnet port can be forgone. In case the port is already in use, Bitcoin can run on any other available port and announce it. The convenience argument is also questioned since most users don't specify nodes and can specify a port when necessary. The reservation of ports by alt coins is not a concern for Bitcoin, and it may be feasible for Bitcoin to allocate one or two ports for its use.On January 2, 2014, Troy Benjegerdes sent an email with three questions regarding Bitcoin. The first question asks why Bitcoin typically runs on port 8333. The second question is about Bitcoin's absence from the Internet Assigned Numbers Authority (IANA) website's list of service names and port numbers. Lastly, Benjegerdes inquires about how someone from the Bitcoin Foundation can fill out a form to request an assigned port. Although the reasons behind these questions are unclear, they shed light on the technical aspects of Bitcoin and its utilization of ports. In response to the questions, it is mentioned that a request for an assignment for Bitcoin has been made, but the details of who made the request and its success are unknown. Overall, the email provides insight into the technical details of Bitcoin and the process for obtaining an assigned port. However, further context is needed to fully grasp the significance of these questions and their underlying motivations.In another email dated January 3, 2014, Troy Benjegerdes poses several inquiries related to Bitcoin's usage of port 8333 and its absence from the IANA registry. He asks about the procedure for someone from the Bitcoin Foundation to fill out a form requesting an assigned port and the process for new cryptocurrencies to acquire default port numbers and P2P network identifier 'magic numbers'. IANA usually registers ports with conservation in mind, and currently, two unassigned ports (8333 and 18333) are available. While having separate ports for the main net and test net would be ideal, only one may be granted due to conservation considerations. The possibility of multiplexing traffic over a single port is also raised. The email includes a list of other assigned and unassigned ports, highlighting the potential concerns that may arise if a multitude of alternative coins reserve ports.In summary, questions have been raised regarding Bitcoin's port number and its visibility on IANA's website. The reasons behind Bitcoin's use of port 8333 remain unknown, and its absence from the IANA registry raises confusion about its legitimacy. Additionally, inquiries have been made about the process for someone from the Bitcoin Foundation to request an assigned port through IANA's form. Furthermore, the procedure for new cryptocurrencies to obtain default port numbers and P2P network identifier 'magic numbers' is being questioned. Addressing these issues is essential to clarify Bitcoin's status and provide guidance for future cryptocurrencies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_BIP0039-Final-call.xml b/static/bitcoin-dev/Jan_2014/combined_BIP0039-Final-call.xml index f2caf88bdb..3ed8c251af 100644 --- a/static/bitcoin-dev/Jan_2014/combined_BIP0039-Final-call.xml +++ b/static/bitcoin-dev/Jan_2014/combined_BIP0039-Final-call.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP0039: Final call - 2023-08-01T07:18:08.632044+00:00 + 2025-10-11T22:03:32.757994+00:00 + python-feedgen Thomas Voegtlin 2014-01-24 16:47:21+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - BIP0039: Final call - 2023-08-01T07:18:08.633048+00:00 + 2025-10-11T22:03:32.758149+00:00 - The team behind Trezor, a popular hardware wallet for storing cryptocurrencies, is seeking feedback on the current draft of their firmware. They are specifically requesting final comments from users and developers who are using another BIP39-compatible client. The goal is to ensure that the firmware meets the necessary standards and addresses any potential issues before its official release. There are concerns about the potential for users to lose money due to fat-fingering the mnemonic sentence. The team is aware of this issue but has not yet found a satisfactory solution. Peter Todd expressed his concern about the security of the proposal and questioned whether any wallets had already implemented BIP39 in this way. The email also mentioned the implementation of BIP39 in Trezor and bitcoinj (Multibit), which have expressed interest in bip39 and seem to be going in the direction of using their own wordlists.Another topic discussed in the email thread was proper Unicode handling in Bitcoin. It was suggested that Unicode canonicalization should be performed before any text hits the crypto code to prevent accessibility issues for users who may switch input methods or machines. Overall, the community is actively working on improving the BIP39 proposal and addressing concerns raised by members.To facilitate the feedback process, the team has made the draft available on their GitHub page, where interested parties can review it in detail and provide their input. By soliciting feedback from the community, Trezor aims to create a more robust and user-friendly product that meets the needs of its users. 2014-01-24T16:47:21+00:00 + The team behind Trezor, a popular hardware wallet for storing cryptocurrencies, is seeking feedback on the current draft of their firmware. They are specifically requesting final comments from users and developers who are using another BIP39-compatible client. The goal is to ensure that the firmware meets the necessary standards and addresses any potential issues before its official release. There are concerns about the potential for users to lose money due to fat-fingering the mnemonic sentence. The team is aware of this issue but has not yet found a satisfactory solution. Peter Todd expressed his concern about the security of the proposal and questioned whether any wallets had already implemented BIP39 in this way. The email also mentioned the implementation of BIP39 in Trezor and bitcoinj (Multibit), which have expressed interest in bip39 and seem to be going in the direction of using their own wordlists.Another topic discussed in the email thread was proper Unicode handling in Bitcoin. It was suggested that Unicode canonicalization should be performed before any text hits the crypto code to prevent accessibility issues for users who may switch input methods or machines. Overall, the community is actively working on improving the BIP39 proposal and addressing concerns raised by members.To facilitate the feedback process, the team has made the draft available on their GitHub page, where interested parties can review it in detail and provide their input. By soliciting feedback from the community, Trezor aims to create a more robust and user-friendly product that meets the needs of its users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_BIP70-71-issue-RFD.xml b/static/bitcoin-dev/Jan_2014/combined_BIP70-71-issue-RFD.xml index 3d7edde637..cc0ac3049a 100644 --- a/static/bitcoin-dev/Jan_2014/combined_BIP70-71-issue-RFD.xml +++ b/static/bitcoin-dev/Jan_2014/combined_BIP70-71-issue-RFD.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70/71 issue, RFD - 2023-08-01T07:20:27.876420+00:00 + 2025-10-11T22:03:00.876585+00:00 + python-feedgen Gavin 2014-01-27 02:05:31+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP70/71 issue, RFD - 2023-08-01T07:20:27.876420+00:00 + 2025-10-11T22:03:00.876713+00:00 - Andreas Schildbach, a Bitcoin developer, encountered an issue with the protobuf format while experimenting with BIP70/71 (payment protocol) usage in face to face payments. Protobufs are not self-delimiting. This means if you're reading from an undelimited stream, you will read endlessly because you don't know how much to read. The current BIP70 implementations probably work because they're reading either from a file or from an HTTP resource which sets the Content-Length header. However, the Content-Length header is optional, and there are many kinds of streams that don't have this built-in delimiting mechanism.Andreas suggests using delimited I/O for PaymentRequest, Payment, and PaymentACK messages that write the size of the message as a varint before writing the data. Nonetheless, this leading varint is an incompatible change and would need to be added to the spec. Bluetooth, Wifi Direct, HTTP request/responses via broken proxies, smoke signals, basically anything that is a stream rather than a file can be affected by this problem. NFC NDEF and QR codes are not affected, so we can skip the delimiter for these mediums.Andreas Schildbach, an experienced developer in the Bitcoin industry, wrote an email to the Bitcoin development mailing list on January 26, 2014. In this email, he discussed his experimentation with BIP70/71 (payment protocol) usage in face-to-face payments. He highlighted an issue with the protobuf format and noted that Protobufs are not self-delimiting. This means that if you're reading from an undelimited stream, you will read endlessly because you don't know how much to read. The current BIP70 implementations probably work because they're reading either from a file or from an HTTP resource which sets the Content-Length header. However, the Content-Length header is optional, and also there are many kinds of streams that don't have this built-in delimiting mechanism.The Java protobuf API solves this by offering delimited I/O like payment.writeDelimitedTo(os).Schildbach suggested that it might be a good idea to apply this to all messages if any, but he specifically encountered this with PaymentMessage and PaymentACK. He further explained that if it turns out we need to retrofit messages with length prefixes, we would have to restart with new mime-types since the nature of prefixes being always at the start rules out simply incrementing a protocol version number.Mike Hearn, another member of the Bitcoin development community, responded to Schildbach's email. Hearn agreed with Schildbach's suggestion, saying that for "binding" the payment protocol to those transports, they should indeed use protobuf varint length prefixes. However, he noted that it's unnecessary for all cases and suggested skipping the delimiter for NFC NDEF and QR codes. Hearn also mentioned that unless Gavin feels it'd be better to be consistent everywhere and is willing to change the spec and code - as far as he knows though they're trying to ship 0.9rc1 soonish.The email thread concluded with a link to CenturyLink Cloud's services and the Bitcoin-development mailing list details.This email thread discusses the issue of using BIP70/71 (payment protocol) in face-to-face payments. The problem encountered is that protobufs are not self-delimiting, meaning that if one is reading from an undelimited stream, they may read endlessly because they don't know how much to read. Current BIP70 implementations work because they're either reading from a file or from an HTTP resource that sets the Content-Length header. However, the Content-Length header is optional and many types of streams don't have this built-in delimiting mechanism. The Java protobuf API solves this by offering delimited I/O, which writes the size of the message as a varint before writing the data. This leading varint is an incompatible change and would need to be added to the spec. The issue was encountered specifically with PaymentMessage and PaymentACK, but it might be a good idea to apply this to all messages if any. It's open for discussion.In a message to the Bitcoin-development mailing list dated 26th January, 2014, Andreas Schildbach reported an issue with the protobuf format when experimenting with BIP70/71 payment protocol usage in face-to-face payments. Protobufs are not self-delimiting, meaning that if reading from an undelimited stream, one would read endlessly because they don't know how much to read. The current BIP70 implementations probably work because they're reading either from a file or from an HTTP resource which sets the Content-Length header. However, the Content-Length header is optional, and also there are many kinds of streams that don't have this built-in delimiting mechanism. The Java protobuf API solves this by offering delimited I/O, like payment.writeDelimitedTo(os), which writes the size of the message as 2014-01-27T02:05:31+00:00 + Andreas Schildbach, a Bitcoin developer, encountered an issue with the protobuf format while experimenting with BIP70/71 (payment protocol) usage in face to face payments. Protobufs are not self-delimiting. This means if you're reading from an undelimited stream, you will read endlessly because you don't know how much to read. The current BIP70 implementations probably work because they're reading either from a file or from an HTTP resource which sets the Content-Length header. However, the Content-Length header is optional, and there are many kinds of streams that don't have this built-in delimiting mechanism.Andreas suggests using delimited I/O for PaymentRequest, Payment, and PaymentACK messages that write the size of the message as a varint before writing the data. Nonetheless, this leading varint is an incompatible change and would need to be added to the spec. Bluetooth, Wifi Direct, HTTP request/responses via broken proxies, smoke signals, basically anything that is a stream rather than a file can be affected by this problem. NFC NDEF and QR codes are not affected, so we can skip the delimiter for these mediums.Andreas Schildbach, an experienced developer in the Bitcoin industry, wrote an email to the Bitcoin development mailing list on January 26, 2014. In this email, he discussed his experimentation with BIP70/71 (payment protocol) usage in face-to-face payments. He highlighted an issue with the protobuf format and noted that Protobufs are not self-delimiting. This means that if you're reading from an undelimited stream, you will read endlessly because you don't know how much to read. The current BIP70 implementations probably work because they're reading either from a file or from an HTTP resource which sets the Content-Length header. However, the Content-Length header is optional, and also there are many kinds of streams that don't have this built-in delimiting mechanism.The Java protobuf API solves this by offering delimited I/O like payment.writeDelimitedTo(os).Schildbach suggested that it might be a good idea to apply this to all messages if any, but he specifically encountered this with PaymentMessage and PaymentACK. He further explained that if it turns out we need to retrofit messages with length prefixes, we would have to restart with new mime-types since the nature of prefixes being always at the start rules out simply incrementing a protocol version number.Mike Hearn, another member of the Bitcoin development community, responded to Schildbach's email. Hearn agreed with Schildbach's suggestion, saying that for "binding" the payment protocol to those transports, they should indeed use protobuf varint length prefixes. However, he noted that it's unnecessary for all cases and suggested skipping the delimiter for NFC NDEF and QR codes. Hearn also mentioned that unless Gavin feels it'd be better to be consistent everywhere and is willing to change the spec and code - as far as he knows though they're trying to ship 0.9rc1 soonish.The email thread concluded with a link to CenturyLink Cloud's services and the Bitcoin-development mailing list details.This email thread discusses the issue of using BIP70/71 (payment protocol) in face-to-face payments. The problem encountered is that protobufs are not self-delimiting, meaning that if one is reading from an undelimited stream, they may read endlessly because they don't know how much to read. Current BIP70 implementations work because they're either reading from a file or from an HTTP resource that sets the Content-Length header. However, the Content-Length header is optional and many types of streams don't have this built-in delimiting mechanism. The Java protobuf API solves this by offering delimited I/O, which writes the size of the message as a varint before writing the data. This leading varint is an incompatible change and would need to be added to the spec. The issue was encountered specifically with PaymentMessage and PaymentACK, but it might be a good idea to apply this to all messages if any. It's open for discussion.In a message to the Bitcoin-development mailing list dated 26th January, 2014, Andreas Schildbach reported an issue with the protobuf format when experimenting with BIP70/71 payment protocol usage in face-to-face payments. Protobufs are not self-delimiting, meaning that if reading from an undelimited stream, one would read endlessly because they don't know how much to read. The current BIP70 implementations probably work because they're reading either from a file or from an HTTP resource which sets the Content-Length header. However, the Content-Length header is optional, and also there are many kinds of streams that don't have this built-in delimiting mechanism. The Java protobuf API solves this by offering delimited I/O, like payment.writeDelimitedTo(os), which writes the size of the message as - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_BIP70-PaymentACK-semantics.xml b/static/bitcoin-dev/Jan_2014/combined_BIP70-PaymentACK-semantics.xml index 420896b939..1d6c605fa7 100644 --- a/static/bitcoin-dev/Jan_2014/combined_BIP70-PaymentACK-semantics.xml +++ b/static/bitcoin-dev/Jan_2014/combined_BIP70-PaymentACK-semantics.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70: PaymentACK semantics - 2023-08-01T07:21:51.614337+00:00 + 2025-10-11T22:03:02.999887+00:00 + python-feedgen Christophe Biocca 2014-01-31 16:21:59+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - BIP70: PaymentACK semantics - 2023-08-01T07:21:51.614337+00:00 + 2025-10-11T22:03:03.000050+00:00 - The discussion revolves around the issues faced by merchants using the refund or memo feature in Bitcoin Core. Merchants need to provide an alternate route for delivering this information before the transaction is made, rendering these fields useless and removing the ability to rely on the payment protocol being bidirectional.Various solutions are suggested, such as sending refund/memo fields as part of the initial request or response to PaymentRequest/PaymentDetails. However, these options require significant changes to the protocol.In an email thread, Jeremy Spilman suggests separating the issues of obtaining refund/memo fields and determining how transactions are broadcasted, retried, locked, and double-spent. He believes that the first issue can be solved without fully specifying behavior for the second.Chuck proposes a solution where customers send unsigned transactions and only the hashes of the fully signed transactions until the merchant acknowledges the unsigned versions. This ensures that the merchant can monitor the network for delivery of the signed transaction.Gavin Andresen and Jeff Garzik discuss the intent of Bitcoin's payment protocol, which is to give customers a great experience. However, there is a concern about the refund or memo feature, where merchants need an alternative route for delivering that information before the transaction is made.Pieter suggests measures to prevent a transaction from being broadcast without the payment delivered, such as attempting to send the payment to a specified payment_uri and making a reasonable attempt to deliver the payment when a transaction is broadcast. Once a paymentACK has been received, the client is no longer responsible for broadcasting the transaction.The conversation also covers the topic of broadcasting transactions in CoinJoin. It is agreed that broadcasting should only be necessary if the payment fails due to the imperfect fungibility of bitcoins. Delaying the broadcast of a transaction after inputs are signed can add complexity to implementation. Some wallets may not broadcast at all and instead try to submit via the payment URL. The goal is to achieve payment atomicity, where the customer losing control of funds is atomic with respect to the payment going through.Overall, the discussions focus on ensuring that merchants cannot act maliciously, finding ways to reliably obtain refund/memo fields, and determining responsibility for broadcasting transactions. The participants suggest various solutions and propose changes to the protocol to enhance the user experience and prevent fraudulent activities.In January 2014, Mike Hearn raised a question regarding whether the wallet should broadcast a transaction to the bitcoin network when it receives an ACK or if it should assume that the merchant server will handle it. He also suggested the inclusion of an error code field in future versions of Bitcoin to differentiate between failed/rejected submissions and successful ones beyond the freeform memo field. Hearn included a link to CenturyLink Cloud, emphasizing its role as a leader in enterprise cloud services.Currently, there is no way to distinguish between a failed or rejected submission and a successful one beyond the freeform memo field. Having an error code field in future versions would be beneficial for troubleshooting and identifying the cause of failed submissions. This addition could potentially save time and resources by enabling more efficient issue resolution.Gavin Andresen discussed the purpose of PaymentACK in payment processing. Its main function is to reassure customers that their payment request has been received and will be processed accordingly. If the payment request is found to be incorrect or invalid, a PaymentACK with a message indicating the problem should be sent as a response.One participant questioned whether it was necessary to always respond with an ack, even in problematic cases, to which Andresen clarified that an ack should always be sent. However, the participant suggested that the specification should explicitly state that sending a nack would result in connection closure without an ack. Additionally, they proposed renaming PaymentACK to PaymentResponse for greater clarity.Andreas Schildbach and Gavin Andresen discussed the purpose of PaymentACK in an email exchange. The BIP70 specification briefly explains that it is sent from the merchant's server to the bitcoin wallet in response to a Payment message. Its purpose is to provide reassurance to customers that their payment request has been received and will be processed (or not). If the payment is invalid or syntactically incorrect, a PaymentACK with a message indicating the problem should be sent.It is not recommended to wait for payment confirmation before sending an ACK, but waiting a few seconds to detect a potential double-spend attempt is acceptable. The BIP intentionally does not specify how long it may take to receive an ACK, but the goal is to provide customers with reassurance that their payment is being processed.The BIP70 specification provides limited information about what a PaymentACK signifies in response to a Payment message. It is unclear whether it indicates receipt of a syntactically correct payment, validity of the payment, or both. There is also uncertainty about how long an Acknowledgement can be delayed until all payment conditions are met. However, it is advised against keeping an HTTP or Bluetooth connection open for an extended period while awaiting blockchain confirmation. 2014-01-31T16:21:59+00:00 + The discussion revolves around the issues faced by merchants using the refund or memo feature in Bitcoin Core. Merchants need to provide an alternate route for delivering this information before the transaction is made, rendering these fields useless and removing the ability to rely on the payment protocol being bidirectional.Various solutions are suggested, such as sending refund/memo fields as part of the initial request or response to PaymentRequest/PaymentDetails. However, these options require significant changes to the protocol.In an email thread, Jeremy Spilman suggests separating the issues of obtaining refund/memo fields and determining how transactions are broadcasted, retried, locked, and double-spent. He believes that the first issue can be solved without fully specifying behavior for the second.Chuck proposes a solution where customers send unsigned transactions and only the hashes of the fully signed transactions until the merchant acknowledges the unsigned versions. This ensures that the merchant can monitor the network for delivery of the signed transaction.Gavin Andresen and Jeff Garzik discuss the intent of Bitcoin's payment protocol, which is to give customers a great experience. However, there is a concern about the refund or memo feature, where merchants need an alternative route for delivering that information before the transaction is made.Pieter suggests measures to prevent a transaction from being broadcast without the payment delivered, such as attempting to send the payment to a specified payment_uri and making a reasonable attempt to deliver the payment when a transaction is broadcast. Once a paymentACK has been received, the client is no longer responsible for broadcasting the transaction.The conversation also covers the topic of broadcasting transactions in CoinJoin. It is agreed that broadcasting should only be necessary if the payment fails due to the imperfect fungibility of bitcoins. Delaying the broadcast of a transaction after inputs are signed can add complexity to implementation. Some wallets may not broadcast at all and instead try to submit via the payment URL. The goal is to achieve payment atomicity, where the customer losing control of funds is atomic with respect to the payment going through.Overall, the discussions focus on ensuring that merchants cannot act maliciously, finding ways to reliably obtain refund/memo fields, and determining responsibility for broadcasting transactions. The participants suggest various solutions and propose changes to the protocol to enhance the user experience and prevent fraudulent activities.In January 2014, Mike Hearn raised a question regarding whether the wallet should broadcast a transaction to the bitcoin network when it receives an ACK or if it should assume that the merchant server will handle it. He also suggested the inclusion of an error code field in future versions of Bitcoin to differentiate between failed/rejected submissions and successful ones beyond the freeform memo field. Hearn included a link to CenturyLink Cloud, emphasizing its role as a leader in enterprise cloud services.Currently, there is no way to distinguish between a failed or rejected submission and a successful one beyond the freeform memo field. Having an error code field in future versions would be beneficial for troubleshooting and identifying the cause of failed submissions. This addition could potentially save time and resources by enabling more efficient issue resolution.Gavin Andresen discussed the purpose of PaymentACK in payment processing. Its main function is to reassure customers that their payment request has been received and will be processed accordingly. If the payment request is found to be incorrect or invalid, a PaymentACK with a message indicating the problem should be sent as a response.One participant questioned whether it was necessary to always respond with an ack, even in problematic cases, to which Andresen clarified that an ack should always be sent. However, the participant suggested that the specification should explicitly state that sending a nack would result in connection closure without an ack. Additionally, they proposed renaming PaymentACK to PaymentResponse for greater clarity.Andreas Schildbach and Gavin Andresen discussed the purpose of PaymentACK in an email exchange. The BIP70 specification briefly explains that it is sent from the merchant's server to the bitcoin wallet in response to a Payment message. Its purpose is to provide reassurance to customers that their payment request has been received and will be processed (or not). If the payment is invalid or syntactically incorrect, a PaymentACK with a message indicating the problem should be sent.It is not recommended to wait for payment confirmation before sending an ACK, but waiting a few seconds to detect a potential double-spend attempt is acceptable. The BIP intentionally does not specify how long it may take to receive an ACK, but the goal is to provide customers with reassurance that their payment is being processed.The BIP70 specification provides limited information about what a PaymentACK signifies in response to a Payment message. It is unclear whether it indicates receipt of a syntactically correct payment, validity of the payment, or both. There is also uncertainty about how long an Acknowledgement can be delayed until all payment conditions are met. However, it is advised against keeping an HTTP or Bluetooth connection open for an extended period while awaiting blockchain confirmation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_BIP70-message-delivery-reliability.xml b/static/bitcoin-dev/Jan_2014/combined_BIP70-message-delivery-reliability.xml index 226057f115..bc5895507d 100644 --- a/static/bitcoin-dev/Jan_2014/combined_BIP70-message-delivery-reliability.xml +++ b/static/bitcoin-dev/Jan_2014/combined_BIP70-message-delivery-reliability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70 message delivery reliability - 2023-08-01T07:33:42.801502+00:00 + 2025-10-11T22:03:47.622860+00:00 + python-feedgen Mike Hearn 2014-01-30 12:38:10+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - BIP70 message delivery reliability - 2023-08-01T07:33:42.802511+00:00 + 2025-10-11T22:03:47.623032+00:00 - The conversation revolves around the handling of transactions and payments in Bitcoinj. Mike Hearn explains that transactions are only committed to the wallet if the server accepts the Payment message and acknowledges it. However, Pieter Wuille states that this is not what is suggested or required by the specification, nor is it currently implemented in Bitcoin core master.Chuck expresses concerns about failure situations and emphasizes the importance of addressing these issues now rather than trying to patch solutions later. He suggests invalidating all transactions in the Payment message by broadcasting a send-to-self transaction as soon as possible to prevent an indeterminate wallet balance. Chuck also discusses the potential for merchants to force transactions into the user's wallet without an acknowledgement, resulting in the user paying without receiving an ACK.The conversation highlights the need for careful consideration of the current implementation's weaknesses and addressing them before evolving the protocol further. They discuss the use of arbitrators in Bitcoin transactions and potential trust issues with third parties. Suggestions are made to add signing to PaymentACK and other measures to address this issue in the future.Chuck and another party discuss the importance of addressing failure situations in the Bitcoin Core and bitcoinj protocols. They propose making minor changes now to prevent potential problems from arising later. Chuck identifies the delivery of the Payment message as a major hole in the implementation, suggesting that the protocol should do everything possible to prevent transactions from confirming without the payment message being delivered.In a conversation between Chuck and Mike Hearn, they discuss the Bitcoin Payment Protocol (PP) and the need for backwards compatibility in any changes made. Chuck emphasizes the importance of discussing failure situations now to avoid having to patch solutions later. He raises concerns about the current PP description and proposes making changes to address potential issues with the delivery of the Payment message. The conversation also touches on the use of arbitrators in payment transactions and the potential for merchants to lie or manipulate transactions.The conversation between Chuck and an unnamed individual centers around the implementation of Bitcoin Core and bitcoinj protocols. They discuss the importance of backwards compatibility in any changes made. They propose using a receipt including PaymentRequest and transactions as proof of payment, and suggest adding features such as ECDH key agreements and refunding addresses. They also emphasize the importance of the customer signing the message with the private key of the refund address. The conversation concludes with plans to evolve the PaymentRequest/Payment/PaymentACK protocol with backwards compatible upgrades.Peter (sipa) recommends forwarding a post to the mailing list for further discussion. The author of the post raises questions about BIP70 message delivery and the value of the PaymentACK message. The author suggests that if PaymentACK is never delivered, a receipt including PaymentRequest and transactions would suffice as proof of payment. The author proposes a slightly improved protocol, outlining required steps and optional steps. The proposed protocol includes measures to provide redundancy and verify transactions. The author seeks thoughts on the proposed protocol. 2014-01-30T12:38:10+00:00 + The conversation revolves around the handling of transactions and payments in Bitcoinj. Mike Hearn explains that transactions are only committed to the wallet if the server accepts the Payment message and acknowledges it. However, Pieter Wuille states that this is not what is suggested or required by the specification, nor is it currently implemented in Bitcoin core master.Chuck expresses concerns about failure situations and emphasizes the importance of addressing these issues now rather than trying to patch solutions later. He suggests invalidating all transactions in the Payment message by broadcasting a send-to-self transaction as soon as possible to prevent an indeterminate wallet balance. Chuck also discusses the potential for merchants to force transactions into the user's wallet without an acknowledgement, resulting in the user paying without receiving an ACK.The conversation highlights the need for careful consideration of the current implementation's weaknesses and addressing them before evolving the protocol further. They discuss the use of arbitrators in Bitcoin transactions and potential trust issues with third parties. Suggestions are made to add signing to PaymentACK and other measures to address this issue in the future.Chuck and another party discuss the importance of addressing failure situations in the Bitcoin Core and bitcoinj protocols. They propose making minor changes now to prevent potential problems from arising later. Chuck identifies the delivery of the Payment message as a major hole in the implementation, suggesting that the protocol should do everything possible to prevent transactions from confirming without the payment message being delivered.In a conversation between Chuck and Mike Hearn, they discuss the Bitcoin Payment Protocol (PP) and the need for backwards compatibility in any changes made. Chuck emphasizes the importance of discussing failure situations now to avoid having to patch solutions later. He raises concerns about the current PP description and proposes making changes to address potential issues with the delivery of the Payment message. The conversation also touches on the use of arbitrators in payment transactions and the potential for merchants to lie or manipulate transactions.The conversation between Chuck and an unnamed individual centers around the implementation of Bitcoin Core and bitcoinj protocols. They discuss the importance of backwards compatibility in any changes made. They propose using a receipt including PaymentRequest and transactions as proof of payment, and suggest adding features such as ECDH key agreements and refunding addresses. They also emphasize the importance of the customer signing the message with the private key of the refund address. The conversation concludes with plans to evolve the PaymentRequest/Payment/PaymentACK protocol with backwards compatible upgrades.Peter (sipa) recommends forwarding a post to the mailing list for further discussion. The author of the post raises questions about BIP70 message delivery and the value of the PaymentACK message. The author suggests that if PaymentACK is never delivered, a receipt including PaymentRequest and transactions would suffice as proof of payment. The author proposes a slightly improved protocol, outlining required steps and optional steps. The proposed protocol includes measures to provide redundancy and verify transactions. The author seeks thoughts on the proposed protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Bait-for-reusable-addresses.xml b/static/bitcoin-dev/Jan_2014/combined_Bait-for-reusable-addresses.xml index 1ba675cfbd..9e4eefe50c 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Bait-for-reusable-addresses.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Bait-for-reusable-addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bait for reusable addresses - 2023-08-01T07:16:54.593883+00:00 + 2025-10-11T22:03:39.130820+00:00 + python-feedgen Mike Hearn 2014-01-24 23:15:56+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Bait for reusable addresses - 2023-08-01T07:16:54.594889+00:00 + 2025-10-11T22:03:39.130995+00:00 - The conversation centers around the need for better privacy options and reducing computational overhead for users. One proposed solution is to set up a UTXO-only full node at home, which can be accessed through a hidden service hosted on Tor. The user's smartphone acts as a web client for the wallet running at home, providing a secure and private connection. This setup offers the same usability as SPV, with zero privacy trade-off for push notifications of relevant transactions.The use of prefixes in blockchain payments is discussed, particularly in relation to network flow analysis. Clustering schemes make it easier for attackers with blockchain data to perform network flow analysis, while making it harder for those with query logs from running nodes. Reusable addresses are useful but lack SPV-like network characteristics and privacy. Payment protocols and client-side certificates could provide additional identity frameworks on top of TOFU addresses, improving privacy.The brittleness of SPV privacy parameters is highlighted by Mike Hearn, who suggests implementing bandwidth modes and monitoring to address this issue. Peter Todd supports the idea of providing users with better options to enhance privacy. Gregory Maxwell proposes the concept of "bloom bait" to differentiate transactions, but it has privacy concerns. Another suggestion is incorporating optional bait in an address, allowing for indexed searching of transactions. However, the amount of extra data required and the chance of miner-committed indexes are yet to be determined.The challenges with reusable addresses are explained, as they create overhead for full nodes and even more significant overheads for SPV nodes. Solutions such as giving blinding private keys to servers have privacy and indexability issues. Bloom bait is considered problematic due to its effect on network privacy. An alternative proposal involves including optional bait in an address, with the server indexing it and returning matching transactions to the client. This approach falls under a class of solutions related to locally decodable error-correcting codes.In conclusion, the conversation highlights the need for improved privacy options and reduced computational overhead in blockchain transactions. Various proposals and ideas are presented, including setting up UTXO-only full nodes, using prefixes in payment analysis, and incorporating optional bait in addresses. The challenges and potential solutions for reusable addresses are also discussed, emphasizing the importance of providing users with better options for privacy while maintaining network characteristics. 2014-01-24T23:15:56+00:00 + The conversation centers around the need for better privacy options and reducing computational overhead for users. One proposed solution is to set up a UTXO-only full node at home, which can be accessed through a hidden service hosted on Tor. The user's smartphone acts as a web client for the wallet running at home, providing a secure and private connection. This setup offers the same usability as SPV, with zero privacy trade-off for push notifications of relevant transactions.The use of prefixes in blockchain payments is discussed, particularly in relation to network flow analysis. Clustering schemes make it easier for attackers with blockchain data to perform network flow analysis, while making it harder for those with query logs from running nodes. Reusable addresses are useful but lack SPV-like network characteristics and privacy. Payment protocols and client-side certificates could provide additional identity frameworks on top of TOFU addresses, improving privacy.The brittleness of SPV privacy parameters is highlighted by Mike Hearn, who suggests implementing bandwidth modes and monitoring to address this issue. Peter Todd supports the idea of providing users with better options to enhance privacy. Gregory Maxwell proposes the concept of "bloom bait" to differentiate transactions, but it has privacy concerns. Another suggestion is incorporating optional bait in an address, allowing for indexed searching of transactions. However, the amount of extra data required and the chance of miner-committed indexes are yet to be determined.The challenges with reusable addresses are explained, as they create overhead for full nodes and even more significant overheads for SPV nodes. Solutions such as giving blinding private keys to servers have privacy and indexability issues. Bloom bait is considered problematic due to its effect on network privacy. An alternative proposal involves including optional bait in an address, with the server indexing it and returning matching transactions to the client. This approach falls under a class of solutions related to locally decodable error-correcting codes.In conclusion, the conversation highlights the need for improved privacy options and reduced computational overhead in blockchain transactions. Various proposals and ideas are presented, including setting up UTXO-only full nodes, using prefixes in payment analysis, and incorporating optional bait in addresses. The challenges and potential solutions for reusable addresses are also discussed, emphasizing the importance of providing users with better options for privacy while maintaining network characteristics. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Bitcoin-Core-0-9rc1-release-schedule.xml b/static/bitcoin-dev/Jan_2014/combined_Bitcoin-Core-0-9rc1-release-schedule.xml index eae3f1154d..8227a90d7d 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Bitcoin-Core-0-9rc1-release-schedule.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Bitcoin-Core-0-9rc1-release-schedule.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.9rc1 release schedule - 2023-08-01T07:17:24.722819+00:00 + 2025-10-11T22:03:28.506464+00:00 + python-feedgen Wladimir 2014-01-23 11:10:34+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.9rc1 release schedule - 2023-08-01T07:17:24.723824+00:00 + 2025-10-11T22:03:28.506662+00:00 - In an email exchange dated January 19, 2014, Wladimir expressed concern over the lack of (auto)tests for pull #1647, which had received comments expressing a need for such tests. However, there was no response from Luke or anyone else regarding who would be responsible for addressing these comments. Wladimir then requested that someone give pull #1647 its final push by addressing the comments so that it could be integrated in the 0.9 release.Jeff Garzik opened a discussion about luke-jr's pull request for CPfP, which remains open due to disagreements on code changes. The consensus is that the feature is useful but controversial, and auto tests are needed. Wladimir asked Luke if he would address the comments or if anyone else was working on it.A pull request for CPfP by luke-jr is considered useful as it closes the gap between Bitcoin transaction fees and the willingness of the receiver to pay a fee. Mark Friedenbach pointed out the pull request, and Jeff Garzik signed off on the email.Wladimir responded to Odinn Cyberguerrilla's concerns about issues with the blockchain and microdonations not being addressed. He asked for pull requests to address these issues and stated that if Odinn's organization did not contribute, it should not be surprising that the issues did not make it into the Bitcoin codebase.The importance of the Child-Pays-For-Parent (CPFP) feature in the 0.9 version of the blockchain.info wallet was discussed. Mark Friedenbach stressed its importance, as people have lost money without it. Jeff Garzik also expressed support for CPFP but noted disagreements on implementation details. The email included an advertisement for CenturyLink Cloud and a link to join the Bitcoin-development mailing list.The conversation is unrelated to a summary, with the author clarifying they are not a doge dev and that their message was meant as a joke. They discuss pull requests and microdonations not being facilitated enough, suggesting developers will handle them. They mention collaboration on a bitcoin project that may implement aspects of the ABIS concept. The author hopes their message made the reader laugh and wonders how they ended up on the dogecoin-development list.The discussion revolves around merging CPFP in upstream, with disagreements on edge case handling and implementation details preventing the merger. Luke-Jr claims the proposals are well-tested and stable, but Wladimir believes more reviewers and testers are needed before merging due to controversial proposals affecting mining/consensus. Jeff Garzik is also part of the conversation.On January 17, 2014, Jeff Garzik expressed a desire to see CPFP in upstream, but there are disagreements on edge case handling and implementation details. However, there are no fundamental objections to merging the feature.The context emphasizes the importance of Child Pays for Parent (CPFP) in Bitcoin transactions, explaining how it prevents lost funds. BitPay wants to see CPFP merged upstream, but disagreements on implementation details hinder the process.In an email exchange, Wladimir and Luke-Jr discuss GitHub pull requests for bitcoin/bitcoin. Luke-Jr shares a link to well-tested and stable code changes, while Wladimir mentions that some proposals are controversial and need more reviewers and testers before merging.Luke-Jr shares a link to a Github pull request containing improvements that are well-tested and stable. However, one improvement requires a rebase and input from jgarzik and himself. Luke-Jr expresses concerns about other improvements affecting mining/consensus and wants more reviewers and testers to acknowledge them.Wladimir announces plans for the upcoming 0.9rc1 release, inviting users to contribute and report any bugs. Luke-Jr submits code changes that are well-tested and stable.There is an issue with the Bitcoin master branch causing problems with leveldb. A workaround has been suggested, and the team is preparing for the 0.9rc1 release in February 2014. They are seeking input from the community on open issues. 2014-01-23T11:10:34+00:00 + In an email exchange dated January 19, 2014, Wladimir expressed concern over the lack of (auto)tests for pull #1647, which had received comments expressing a need for such tests. However, there was no response from Luke or anyone else regarding who would be responsible for addressing these comments. Wladimir then requested that someone give pull #1647 its final push by addressing the comments so that it could be integrated in the 0.9 release.Jeff Garzik opened a discussion about luke-jr's pull request for CPfP, which remains open due to disagreements on code changes. The consensus is that the feature is useful but controversial, and auto tests are needed. Wladimir asked Luke if he would address the comments or if anyone else was working on it.A pull request for CPfP by luke-jr is considered useful as it closes the gap between Bitcoin transaction fees and the willingness of the receiver to pay a fee. Mark Friedenbach pointed out the pull request, and Jeff Garzik signed off on the email.Wladimir responded to Odinn Cyberguerrilla's concerns about issues with the blockchain and microdonations not being addressed. He asked for pull requests to address these issues and stated that if Odinn's organization did not contribute, it should not be surprising that the issues did not make it into the Bitcoin codebase.The importance of the Child-Pays-For-Parent (CPFP) feature in the 0.9 version of the blockchain.info wallet was discussed. Mark Friedenbach stressed its importance, as people have lost money without it. Jeff Garzik also expressed support for CPFP but noted disagreements on implementation details. The email included an advertisement for CenturyLink Cloud and a link to join the Bitcoin-development mailing list.The conversation is unrelated to a summary, with the author clarifying they are not a doge dev and that their message was meant as a joke. They discuss pull requests and microdonations not being facilitated enough, suggesting developers will handle them. They mention collaboration on a bitcoin project that may implement aspects of the ABIS concept. The author hopes their message made the reader laugh and wonders how they ended up on the dogecoin-development list.The discussion revolves around merging CPFP in upstream, with disagreements on edge case handling and implementation details preventing the merger. Luke-Jr claims the proposals are well-tested and stable, but Wladimir believes more reviewers and testers are needed before merging due to controversial proposals affecting mining/consensus. Jeff Garzik is also part of the conversation.On January 17, 2014, Jeff Garzik expressed a desire to see CPFP in upstream, but there are disagreements on edge case handling and implementation details. However, there are no fundamental objections to merging the feature.The context emphasizes the importance of Child Pays for Parent (CPFP) in Bitcoin transactions, explaining how it prevents lost funds. BitPay wants to see CPFP merged upstream, but disagreements on implementation details hinder the process.In an email exchange, Wladimir and Luke-Jr discuss GitHub pull requests for bitcoin/bitcoin. Luke-Jr shares a link to well-tested and stable code changes, while Wladimir mentions that some proposals are controversial and need more reviewers and testers before merging.Luke-Jr shares a link to a Github pull request containing improvements that are well-tested and stable. However, one improvement requires a rebase and input from jgarzik and himself. Luke-Jr expresses concerns about other improvements affecting mining/consensus and wants more reviewers and testers to acknowledge them.Wladimir announces plans for the upcoming 0.9rc1 release, inviting users to contribute and report any bugs. Luke-Jr submits code changes that are well-tested and stable.There is an issue with the Bitcoin master branch causing problems with leveldb. A workaround has been suggested, and the team is preparing for the 0.9rc1 release in February 2014. They are seeking input from the community on open issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Combining-big-transactions-with-hash-only-blocks-to-improve-tps-.xml b/static/bitcoin-dev/Jan_2014/combined_Combining-big-transactions-with-hash-only-blocks-to-improve-tps-.xml index e32dae3c78..004fd9840f 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Combining-big-transactions-with-hash-only-blocks-to-improve-tps-.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Combining-big-transactions-with-hash-only-blocks-to-improve-tps-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Combining big transactions with hash-only blocks to improve tps. - 2023-08-01T07:18:50.241680+00:00 + 2025-10-11T22:03:34.882299+00:00 + python-feedgen Christophe Biocca 2014-01-22 22:20:58+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Combining big transactions with hash-only blocks to improve tps. - 2023-08-01T07:18:50.241680+00:00 + 2025-10-11T22:03:34.882502+00:00 - On January 22, 2014, Bitcoin developer Jorge Timón proposed two optimizations to improve the transaction processing rate and anonymity of the network. The first optimization involves keeping only hashes of transactions in a block, reducing redundancy and keeping block propagation time from increasing. By keeping only hashes in a block, it allows for 50tps in a 1MiB block. This method also removes redundancy since every transaction has to be transmitted only once. The second optimization is CoinJoin, which allows many people to send coins with one transaction, thus increasing the effective transaction rate. For example, a limit of 50 KiB allows for a CoinJoin transaction between 170 participants, allowing for 50 tps * 170 effective transactions/tx = 8500 tps in a 1MiB block. However, CoinJoin requires collaboration between many users in real-time, which can induce delays that can take some time. By using a bigger CoinJoin user base for online payments (with smaller fees) and a smaller one for POS payments (with larger fees), this issue can be resolved.The author of the article suggests two optimizations that can improve tps while maintaining anonymity of the network. The first optimization is to keep only the transaction hashes in a block, thereby reducing redundancy and keeping the block size small and easy to propagate. The second optimization involves using CoinJoin to merge transactions from many users for online shopping and banking, which increases the effective transaction rate considerably. However, it requires collaboration between many users in real-time, which induces delays that are unsuitable for POS payments. The author proposes a new type of transaction called Jumbo transactions to serve as a fallback where CoinJoin is not applicable. Jumbo transactions remove the CoinJoin-induced delays while keeping transaction sizes big. The author provides a detailed algorithm for implementing Jumbo transactions, which includes a Jumbo pubkey hash to prevent modification of the transaction. Although Jumbo transactions do not mix coins and thus do not increase anonymity of the network, they offer many benefits such as no wait time for every participant to sign the transaction, backward compatibility with the current transaction system, and more suitable for POS payments. Finally, the author cites several references regarding block propagation time, Bitcoin privacy, and electronic cash system.The proposal to improve transaction per second (tps) by combining big transactions with hash-only blocks is presented in a post by bc. The proposal suggests keeping only hashes of transactions included in a block, transferring all tx separately, using CoinJoin to merge transactions from many users for online shopping and banking, and using jumbo transactions as a fallback for applications where CoinJoin is inappropriate. By keeping only hashes in a block, the current 1MB block can contain about 31000tx = 50tps instead of 3300tx = 5.5tps. This method allows achieving more tps without increasing the block propagation time, which is critical for mining decentralization. CoinJoin is used to allow many people to send coins with one transaction, increasing the effective transaction rate considerably. For example, if the transaction size limit is 50KB, it allows for a CoinJoin transaction between 170 participants. So for a block of 1MB, it would allow for 8500tps. There would be an incentive for users to use CoinJoin by default, lower tx fees per effective transaction, which would greatly increase the anonymity of the network.Jumbo transactions type proposed as a backup when CoinJoin is not applicable. It would remove the CoinJoin-induced delays while keeping transaction sizes big. Jumbo pubkey prevents the transaction from being modified. A service that collects transactions from clients and publishes them as a Jumbo transaction joins the transaction. Transaction joiner sends a Jumbo pubkey hash to the client. The client creates a transaction, includes a Jumbo pubkey hash, and signs it. The transaction joiner waits until there are enough transactions and releases a Jumbo transaction to the network. Jumbo transactions do not mix coins, so anonymity of the network is not increased. There would be an incentive to use this transaction type by default compared to CoinJoin. To mitigate this problem, the Jumbo transaction size limit can be lower than CoinJoin, making fees for these transactions higher, thus creating an incentive to use them only when necessary. The proposal suggests using a bigger CoinJoin user base for online payments with smaller fees and a smaller one for POS payments with larger fees.The author proposes a method to combine big transactions with hash-only blocks to improve the transaction per second (tps). This combines two techniques, one is including only hashes in a block to speed up the network, and the other is using CoinJoin to improve privacy. Keeping only transaction hashes in a block removes redundancy and allows for more consistent bandwidth utilization. Assuming a block size of 1MB and a limit of 50KB for transaction size, it allows for a CoinJoin transaction between 170 participants and an effective transaction rate of 8500 tps. However 2014-01-22T22:20:58+00:00 + On January 22, 2014, Bitcoin developer Jorge Timón proposed two optimizations to improve the transaction processing rate and anonymity of the network. The first optimization involves keeping only hashes of transactions in a block, reducing redundancy and keeping block propagation time from increasing. By keeping only hashes in a block, it allows for 50tps in a 1MiB block. This method also removes redundancy since every transaction has to be transmitted only once. The second optimization is CoinJoin, which allows many people to send coins with one transaction, thus increasing the effective transaction rate. For example, a limit of 50 KiB allows for a CoinJoin transaction between 170 participants, allowing for 50 tps * 170 effective transactions/tx = 8500 tps in a 1MiB block. However, CoinJoin requires collaboration between many users in real-time, which can induce delays that can take some time. By using a bigger CoinJoin user base for online payments (with smaller fees) and a smaller one for POS payments (with larger fees), this issue can be resolved.The author of the article suggests two optimizations that can improve tps while maintaining anonymity of the network. The first optimization is to keep only the transaction hashes in a block, thereby reducing redundancy and keeping the block size small and easy to propagate. The second optimization involves using CoinJoin to merge transactions from many users for online shopping and banking, which increases the effective transaction rate considerably. However, it requires collaboration between many users in real-time, which induces delays that are unsuitable for POS payments. The author proposes a new type of transaction called Jumbo transactions to serve as a fallback where CoinJoin is not applicable. Jumbo transactions remove the CoinJoin-induced delays while keeping transaction sizes big. The author provides a detailed algorithm for implementing Jumbo transactions, which includes a Jumbo pubkey hash to prevent modification of the transaction. Although Jumbo transactions do not mix coins and thus do not increase anonymity of the network, they offer many benefits such as no wait time for every participant to sign the transaction, backward compatibility with the current transaction system, and more suitable for POS payments. Finally, the author cites several references regarding block propagation time, Bitcoin privacy, and electronic cash system.The proposal to improve transaction per second (tps) by combining big transactions with hash-only blocks is presented in a post by bc. The proposal suggests keeping only hashes of transactions included in a block, transferring all tx separately, using CoinJoin to merge transactions from many users for online shopping and banking, and using jumbo transactions as a fallback for applications where CoinJoin is inappropriate. By keeping only hashes in a block, the current 1MB block can contain about 31000tx = 50tps instead of 3300tx = 5.5tps. This method allows achieving more tps without increasing the block propagation time, which is critical for mining decentralization. CoinJoin is used to allow many people to send coins with one transaction, increasing the effective transaction rate considerably. For example, if the transaction size limit is 50KB, it allows for a CoinJoin transaction between 170 participants. So for a block of 1MB, it would allow for 8500tps. There would be an incentive for users to use CoinJoin by default, lower tx fees per effective transaction, which would greatly increase the anonymity of the network.Jumbo transactions type proposed as a backup when CoinJoin is not applicable. It would remove the CoinJoin-induced delays while keeping transaction sizes big. Jumbo pubkey prevents the transaction from being modified. A service that collects transactions from clients and publishes them as a Jumbo transaction joins the transaction. Transaction joiner sends a Jumbo pubkey hash to the client. The client creates a transaction, includes a Jumbo pubkey hash, and signs it. The transaction joiner waits until there are enough transactions and releases a Jumbo transaction to the network. Jumbo transactions do not mix coins, so anonymity of the network is not increased. There would be an incentive to use this transaction type by default compared to CoinJoin. To mitigate this problem, the Jumbo transaction size limit can be lower than CoinJoin, making fees for these transactions higher, thus creating an incentive to use them only when necessary. The proposal suggests using a bigger CoinJoin user base for online payments with smaller fees and a smaller one for POS payments with larger fees.The author proposes a method to combine big transactions with hash-only blocks to improve the transaction per second (tps). This combines two techniques, one is including only hashes in a block to speed up the network, and the other is using CoinJoin to improve privacy. Keeping only transaction hashes in a block removes redundancy and allows for more consistent bandwidth utilization. Assuming a block size of 1MB and a limit of 50KB for transaction size, it allows for a CoinJoin transaction between 170 participants and an effective transaction rate of 8500 tps. However - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Dedicated-server-for-bitcoin-org-your-thoughts-.xml b/static/bitcoin-dev/Jan_2014/combined_Dedicated-server-for-bitcoin-org-your-thoughts-.xml index 62afe21261..652080de14 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Dedicated-server-for-bitcoin-org-your-thoughts-.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Dedicated-server-for-bitcoin-org-your-thoughts-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dedicated server for bitcoin.org, your thoughts? - 2023-08-01T06:48:14.987945+00:00 + 2025-10-11T22:03:13.626249+00:00 + python-feedgen Troy Benjegerdes 2014-01-04 01:43:36+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 Combined summary - Dedicated server for bitcoin.org, your thoughts? - 2023-08-01T06:48:14.989944+00:00 + 2025-10-11T22:03:13.626543+00:00 - In a series of discussions, the security and integrity of Bitcoin software were explored. One key topic was the importance of checking hash values to prevent attackers from replacing parts of files. Package management systems like apt-secure were seen as useful in ensuring the integrity of software packages at the operating system level. However, there were doubts about the feasibility of binaries checking their own hash. The group concluded that promoting the use of signed .deb packages and secure package management systems would be a better approach to security.Another area of discussion was the security of Bitcoin protocol updates. Suggestions included deterministic builds, threshold signed updates, and using the blockchain for forward-validation. SSL and trusted automatic update notification were also considered. Concerns were raised about the verification of hashes in Bitcoin downloads, particularly the differences between the hashes signed by individuals and the hashes of files hosted on SourceForge. Various solutions were proposed, such as patching signatures onto gitian builds or using gitian-downloader for verifying signatures.The security and control of the bitcoin.org domain were also discussed. There were concerns about the effectiveness of SSL in protecting against attackers intercepting traffic to the server. Some argued that PGP signatures could provide stronger protection. Ownership and administration of the domain were debated, with suggestions to separate it from Github and involve the Bitcoin Foundation. Anonymity in domain registration and trust in the current registrar were also points of concern.The funding, administration, and DNS control of bitcoin.org were addressed. Suggestions were made for the Bitcoin Foundation to fund the website, but clear separation between the foundation's website and bitcoin.org was emphasized. The importance of anti-DoS measures, identifying a trustworthy administrator, and maintaining control over the domain were highlighted.The question of who should have admin rights to code projects on platforms like Github and SourceForge was raised. Some argued for giving admin rights to those who have proven trustworthiness, while others emphasized the need for decentralization and control by multiple individuals. Concerns were raised about having too many important elements of the Bitcoin project under one entity's control.The security of SSL certificates was a topic of discussion, with concerns about MITM attacks and the limitations of the CA system. The importance of offline signature verification on binaries was emphasized. Decentralization and clear ownership over key aspects of the Bitcoin project, such as admin rights, DNS control, and website hosting, were also points of concern.In a separate thread, concerns were expressed about CAs in relation to bitcoin.org. The suggestion of moving the website to a dedicated server with an SSL certificate was discussed to address the lack of encryption and potential issues with CAs. Other concerns about forward secrecy, binaries hosting/sharing, revocation, and decentralization were raised. The idea of using mirrors or other methods to further decentralize the content of bitcoin.org was proposed.Overall, the discussions highlighted the importance of verifying hash values, integrating cryptography with mainstream use, and ensuring the security and reliability of the bitcoin.org website. Various solutions and approaches were proposed, emphasizing the ongoing efforts to enhance the security of Bitcoin software. 2014-01-04T01:43:36+00:00 + In a series of discussions, the security and integrity of Bitcoin software were explored. One key topic was the importance of checking hash values to prevent attackers from replacing parts of files. Package management systems like apt-secure were seen as useful in ensuring the integrity of software packages at the operating system level. However, there were doubts about the feasibility of binaries checking their own hash. The group concluded that promoting the use of signed .deb packages and secure package management systems would be a better approach to security.Another area of discussion was the security of Bitcoin protocol updates. Suggestions included deterministic builds, threshold signed updates, and using the blockchain for forward-validation. SSL and trusted automatic update notification were also considered. Concerns were raised about the verification of hashes in Bitcoin downloads, particularly the differences between the hashes signed by individuals and the hashes of files hosted on SourceForge. Various solutions were proposed, such as patching signatures onto gitian builds or using gitian-downloader for verifying signatures.The security and control of the bitcoin.org domain were also discussed. There were concerns about the effectiveness of SSL in protecting against attackers intercepting traffic to the server. Some argued that PGP signatures could provide stronger protection. Ownership and administration of the domain were debated, with suggestions to separate it from Github and involve the Bitcoin Foundation. Anonymity in domain registration and trust in the current registrar were also points of concern.The funding, administration, and DNS control of bitcoin.org were addressed. Suggestions were made for the Bitcoin Foundation to fund the website, but clear separation between the foundation's website and bitcoin.org was emphasized. The importance of anti-DoS measures, identifying a trustworthy administrator, and maintaining control over the domain were highlighted.The question of who should have admin rights to code projects on platforms like Github and SourceForge was raised. Some argued for giving admin rights to those who have proven trustworthiness, while others emphasized the need for decentralization and control by multiple individuals. Concerns were raised about having too many important elements of the Bitcoin project under one entity's control.The security of SSL certificates was a topic of discussion, with concerns about MITM attacks and the limitations of the CA system. The importance of offline signature verification on binaries was emphasized. Decentralization and clear ownership over key aspects of the Bitcoin project, such as admin rights, DNS control, and website hosting, were also points of concern.In a separate thread, concerns were expressed about CAs in relation to bitcoin.org. The suggestion of moving the website to a dedicated server with an SSL certificate was discussed to address the lack of encryption and potential issues with CAs. Other concerns about forward secrecy, binaries hosting/sharing, revocation, and decentralization were raised. The idea of using mirrors or other methods to further decentralize the content of bitcoin.org was proposed.Overall, the discussions highlighted the importance of verifying hash values, integrating cryptography with mainstream use, and ensuring the security and reliability of the bitcoin.org website. Various solutions and approaches were proposed, emphasizing the ongoing efforts to enhance the security of Bitcoin software. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Experiment-with-linking-payment-requests-via-href.xml b/static/bitcoin-dev/Jan_2014/combined_Experiment-with-linking-payment-requests-via-href.xml index b21e590c0d..b4b8ec61c6 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Experiment-with-linking-payment-requests-via-href.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Experiment-with-linking-payment-requests-via-href.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Experiment with linking payment requests via href - 2023-08-01T07:30:53.294855+00:00 + 2025-10-11T22:03:05.124495+00:00 + python-feedgen Mike Hearn 2014-01-27 21:47:55+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Experiment with linking payment requests via href - 2023-08-01T07:30:53.294855+00:00 + 2025-10-11T22:03:05.124651+00:00 - In certain situations, using a file approach to download and open a Bitcoin URI may be the most suitable option. However, this method requires an extra click using a download manager, which can be inconvenient for some users. To address this issue, a Bitcoin URI with r= parameter can eliminate the need for the additional click. However, it may not always be applicable, especially when sending payment requests through messaging apps or email attachments.During a conversation between Andreas Schildbach and an unidentified individual, it was proposed that using .bitcoinpaymentrequest files with the appropriate MIME type would be preferable over packing a file into a URL. Andreas agreed to implement this suggestion. However, he encountered difficulties when attempting to use this method. Both Chrome and the AOSP browser insisted on handling the link with their respective download managers, necessitating an extra click. Furthermore, Firefox ignored the click altogether. It is worth noting that the download manager was a separate component that could not be updated with the browser. Despite registering the correct MIME type and setting the MIME type of the href, Andreas faced this challenge. He provided a link to the href on http://wallet.schildbach.de, which redirects to Gavin's generator. Although Andreas did not attempt using suffixes, he assumed they would behave similarly. Seeking assistance, he asked for suggestions regarding alternative approaches to try. 2014-01-27T21:47:55+00:00 + In certain situations, using a file approach to download and open a Bitcoin URI may be the most suitable option. However, this method requires an extra click using a download manager, which can be inconvenient for some users. To address this issue, a Bitcoin URI with r= parameter can eliminate the need for the additional click. However, it may not always be applicable, especially when sending payment requests through messaging apps or email attachments.During a conversation between Andreas Schildbach and an unidentified individual, it was proposed that using .bitcoinpaymentrequest files with the appropriate MIME type would be preferable over packing a file into a URL. Andreas agreed to implement this suggestion. However, he encountered difficulties when attempting to use this method. Both Chrome and the AOSP browser insisted on handling the link with their respective download managers, necessitating an extra click. Furthermore, Firefox ignored the click altogether. It is worth noting that the download manager was a separate component that could not be updated with the browser. Despite registering the correct MIME type and setting the MIME type of the href, Andreas faced this challenge. He provided a link to the href on http://wallet.schildbach.de, which redirects to Gavin's generator. Although Andreas did not attempt using suffixes, he assumed they would behave similarly. Seeking assistance, he asked for suggestions regarding alternative approaches to try. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Extension-for-BIP-0070-to-support-recurring-payments.xml b/static/bitcoin-dev/Jan_2014/combined_Extension-for-BIP-0070-to-support-recurring-payments.xml index 7bce268418..1ed72d7c95 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Extension-for-BIP-0070-to-support-recurring-payments.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Extension-for-BIP-0070-to-support-recurring-payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Extension for BIP-0070 to support recurring payments - 2023-08-01T07:31:59.306599+00:00 + 2025-10-11T22:03:07.249818+00:00 + python-feedgen Mike Hearn 2014-02-26 10:30:46+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - Extension for BIP-0070 to support recurring payments - 2023-08-01T07:31:59.306599+00:00 + 2025-10-11T22:03:07.249988+00:00 - The email thread discusses the protocol for recurring payments. It covers aspects such as contract negotiation and recurring payment details. The contract sets the payment bounds, while the wallet handles payments within those bounds. The protocol allows for flexibility in specifying payment periods and polling the merchant for pending payments. Multiple contracts can occur, such as when a customer downgrades their subscription. The protocol is designed to allow the wallet to poll the merchant for pending payments without knowing the exact payment date.Feedback from BitPay and others is sought to ensure customer requirements are met. Suggestions include making the RecurringPaymentDetails field optional, specifying periods more flexibly, documenting value constraints, and clarifying the purpose of certain identifiers. The need for a daily option and specifying recurring cycles is also discussed.The team has implemented a BIP0070 extension for recurring billing and tested it with a working prototype. They are awaiting feedback before finalizing the protocol design and merging the code. The team also considers implementing subscription cancellation and upgrade/downgrade features and seeks input on reporting errors to the wallet.The second iteration of the prototype includes subscription cancellation and upgrade/downgrade. The team has checked in both the bitcoinj and php server implementations for testing. They have extended the RecurringPaymentDetails message to accommodate subscription changes and cancellations. A unique subscription ID is used to track multiple contracts with payment bounds and validity periods. Feedback from Kevin is addressed, and suggestions are incorporated into the design.The discussion addresses reporting errors to the wallet and suggests adding a status code in PaymentRequest or using the memo field. Concerns about empty sets of outputs and bitcoin-qt's handling of PaymentRequests without outputs are raised.The proposed protocol aims to enable recurring payments through an extension of BIP-0070. It offers advantages in user control and subscription management tools in wallets. The process involves initial registration, ongoing payments, subscription changes, and cancellation. Wallets poll the merchant for due payments, support overage charges, and handle subscription changes and cancellations. The protocol is still being refined, and feedback on the high-level proposal is welcome.Missed payments are discussed, with suggestions for storing local subscription requests and making payments when the wallet app is running. Canceling subscriptions should be possible at any time, with a courtesy message sent to the merchant. Some propose a textual reminder to send money instead of automated recurring payments to add human review. The implementation of recurring payments could be supported through a Bounty or BIP. The discussion also touches on HTML5 local storage and the challenges faced by decentralized standalone wallet clients. Overall, feedback and suggestions for improvement are welcomed.Jeff Garzik, a Bitcoin core developer and open-source evangelist, emphasizes the importance of users having control over their money. He mentions that recurring payments and subscriptions are frequently requested features in the Bitcoin network but implementing them would require careful planning and execution.In 2014, Stephane Brossier proposed an extension to the Payment Protocol (bip-0070) for recurring payments in Bitcoin. This was in response to the growing popularity of the subscription economy model and the need for a protocol to address this. Stephane's open-source billing platform, Kill Bill, had developed a prototype for recurring billing in Bitcoin, which followed a workflow similar to bip-0070.The proposed workflow involves the wallet receiving a RecurringPaymentRequestAuth that describes the nature of future recurring payments. The customer is prompted by the wallet to authorize it. The wallet then polls the merchant server at specified intervals, and if the merchant issues a PaymentRequest within the accepted bounds set by the customer, the payment is made using the same process as bip-0070.Stéphane is interested in gauging the community's interest in this proposal and is willing to provide more details and implementation using bitcoinj as a wallet and Kill Bill as a merchant server. With Bitcoin becoming more mainstream, defining a protocol for recurring payments is seen as a logical step forward. 2014-02-26T10:30:46+00:00 + The email thread discusses the protocol for recurring payments. It covers aspects such as contract negotiation and recurring payment details. The contract sets the payment bounds, while the wallet handles payments within those bounds. The protocol allows for flexibility in specifying payment periods and polling the merchant for pending payments. Multiple contracts can occur, such as when a customer downgrades their subscription. The protocol is designed to allow the wallet to poll the merchant for pending payments without knowing the exact payment date.Feedback from BitPay and others is sought to ensure customer requirements are met. Suggestions include making the RecurringPaymentDetails field optional, specifying periods more flexibly, documenting value constraints, and clarifying the purpose of certain identifiers. The need for a daily option and specifying recurring cycles is also discussed.The team has implemented a BIP0070 extension for recurring billing and tested it with a working prototype. They are awaiting feedback before finalizing the protocol design and merging the code. The team also considers implementing subscription cancellation and upgrade/downgrade features and seeks input on reporting errors to the wallet.The second iteration of the prototype includes subscription cancellation and upgrade/downgrade. The team has checked in both the bitcoinj and php server implementations for testing. They have extended the RecurringPaymentDetails message to accommodate subscription changes and cancellations. A unique subscription ID is used to track multiple contracts with payment bounds and validity periods. Feedback from Kevin is addressed, and suggestions are incorporated into the design.The discussion addresses reporting errors to the wallet and suggests adding a status code in PaymentRequest or using the memo field. Concerns about empty sets of outputs and bitcoin-qt's handling of PaymentRequests without outputs are raised.The proposed protocol aims to enable recurring payments through an extension of BIP-0070. It offers advantages in user control and subscription management tools in wallets. The process involves initial registration, ongoing payments, subscription changes, and cancellation. Wallets poll the merchant for due payments, support overage charges, and handle subscription changes and cancellations. The protocol is still being refined, and feedback on the high-level proposal is welcome.Missed payments are discussed, with suggestions for storing local subscription requests and making payments when the wallet app is running. Canceling subscriptions should be possible at any time, with a courtesy message sent to the merchant. Some propose a textual reminder to send money instead of automated recurring payments to add human review. The implementation of recurring payments could be supported through a Bounty or BIP. The discussion also touches on HTML5 local storage and the challenges faced by decentralized standalone wallet clients. Overall, feedback and suggestions for improvement are welcomed.Jeff Garzik, a Bitcoin core developer and open-source evangelist, emphasizes the importance of users having control over their money. He mentions that recurring payments and subscriptions are frequently requested features in the Bitcoin network but implementing them would require careful planning and execution.In 2014, Stephane Brossier proposed an extension to the Payment Protocol (bip-0070) for recurring payments in Bitcoin. This was in response to the growing popularity of the subscription economy model and the need for a protocol to address this. Stephane's open-source billing platform, Kill Bill, had developed a prototype for recurring billing in Bitcoin, which followed a workflow similar to bip-0070.The proposed workflow involves the wallet receiving a RecurringPaymentRequestAuth that describes the nature of future recurring payments. The customer is prompted by the wallet to authorize it. The wallet then polls the merchant server at specified intervals, and if the merchant issues a PaymentRequest within the accepted bounds set by the customer, the payment is made using the same process as bip-0070.Stéphane is interested in gauging the community's interest in this proposal and is willing to provide more details and implementation using bitcoinj as a wallet and Kill Bill as a merchant server. With Bitcoin becoming more mainstream, defining a protocol for recurring payments is seen as a logical step forward. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Getting-trusted-metrics-from-the-block-chain-in-an-untrusted-environment-.xml b/static/bitcoin-dev/Jan_2014/combined_Getting-trusted-metrics-from-the-block-chain-in-an-untrusted-environment-.xml index ad9dffdfae..aa71110d76 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Getting-trusted-metrics-from-the-block-chain-in-an-untrusted-environment-.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Getting-trusted-metrics-from-the-block-chain-in-an-untrusted-environment-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Getting trusted metrics from the block chain in an untrusted environment ? - 2023-08-01T07:14:50.502710+00:00 + 2025-10-11T22:03:30.634258+00:00 + python-feedgen Clément Elbaz 2014-01-09 17:46:05+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Getting trusted metrics from the block chain in an untrusted environment ? - 2023-08-01T07:14:50.502710+00:00 + 2025-10-11T22:03:30.634454+00:00 - In an email exchange, Clément Elbaz proposed the idea of creating a 'metric request block chain' to store structures defined as [metric request | current block number when request was made | hash of the response] instead of financial transactions. These structures are verifiable and could function similarly to a regular financial blockchain. Clément suggested that this 'metric request block chain' should not be part of the main Bitcoin protocol but could be a plugin interacting with the data managed by the fullnode bitcoin software. He also mentioned the need to pay a fee for each metrics request since they can be computationally expensive and require validation.Clément is designing a program that requires metrics computed from the Bitcoin blockchain, such as address balances or specific transaction occurrences. However, his program will run on lightweight/embedded hardware and does not have the resources to set up a trusted node alongside it. While he trusts the global Bitcoin network, he does not trust individual nodes. Therefore, Clément is seeking a way to ask an untrusted Bitcoin node to compute a 'metric request' on his behalf and have the result validated by the network. He is inquiring about any existing or in-progress projects that could fulfill this need, or if he should undertake building it himself. 2014-01-09T17:46:05+00:00 + In an email exchange, Clément Elbaz proposed the idea of creating a 'metric request block chain' to store structures defined as [metric request | current block number when request was made | hash of the response] instead of financial transactions. These structures are verifiable and could function similarly to a regular financial blockchain. Clément suggested that this 'metric request block chain' should not be part of the main Bitcoin protocol but could be a plugin interacting with the data managed by the fullnode bitcoin software. He also mentioned the need to pay a fee for each metrics request since they can be computationally expensive and require validation.Clément is designing a program that requires metrics computed from the Bitcoin blockchain, such as address balances or specific transaction occurrences. However, his program will run on lightweight/embedded hardware and does not have the resources to set up a trusted node alongside it. While he trusts the global Bitcoin network, he does not trust individual nodes. Therefore, Clément is seeking a way to ask an untrusted Bitcoin node to compute a 'metric request' on his behalf and have the result validated by the network. He is inquiring about any existing or in-progress projects that could fulfill this need, or if he should undertake building it himself. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Happy-new-year-.xml b/static/bitcoin-dev/Jan_2014/combined_Happy-new-year-.xml index ad963fbbdc..751b68f117 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Happy-new-year-.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Happy-new-year-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Happy new year! - 2023-08-01T07:10:07.627948+00:00 + 2025-10-11T22:03:22.134505+00:00 + python-feedgen Gary Rowe 2014-01-01 19:48:18+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Happy new year! - 2023-08-01T07:10:07.627948+00:00 + 2025-10-11T22:03:22.134680+00:00 - In an email thread between Melvin Carvalho and Mike Hearn on January 1, 2014, the excitement for the new year and upcoming upgrades to Bitcoin is evident. Reflecting on Bitcoin's successful year in 2013, Hearn expresses hope for a faster pace of development in the coming year. Carvalho also expresses gratitude towards Hearn and all those who contributed to Bitcoin's development. Both individuals eagerly anticipate what 2014 will bring for Bitcoin.The email contains a sponsored message for AppDynamics, which offers IT organizations visibility into application performance. Included in the message is a link to start a free trial of AppDynamics Pro. This shows that the email was not solely focused on Bitcoin, but also provided information about other services.Hearn's email, sent on January 1, 2014, emphasizes his excitement for the upcoming year in Bitcoin development. He acknowledges the exciting developments that occurred within the Bitcoin community in 2013, but notes that it was a relatively quiet year for core software upgrades. Hearn expresses his hope that this will change in 2014 and that the pace of development will increase. He wishes everyone a happy new year and expresses his enthusiasm for what lies ahead in 2014. The fact that Bitcoin was one of the 100 most searched for terms in 2013 further highlights Hearn's optimism about the future of Bitcoin.The email includes a signature advertising AppDynamics, a service that provides visibility into application performance. This indicates that Hearn may have been associated with or endorsing AppDynamics at the time the email was sent.The email was sent to the Bitcoin-development mailing list on SourceForge, suggesting that it was intended for a specific audience within the Bitcoin community.In addition to Hearn's email, another message posted by Wendell on hivewallet.com and Twitter on January 1, 2014, echoes similar sentiments. Wendell, who contributed to the development of Hive Wallet, expresses gratitude for being part of the Bitcoin community and believes that 2014 will be an amazing year. Like Hearn, he mentions that although there was significant growth in the Bitcoin community in 2013, there was little change in the core software. Both Wendell and Hearn express excitement about the potential for innovation in the coming year.Overall, despite Bitcoin's successful year in 2013, the core software development remained relatively quiet. However, individuals like Mike Hearn and Wendell are optimistic about the upgrades and progress planned for 2014. Their anticipation for a faster pace of development and enthusiasm for the future of Bitcoin is evident. 2014-01-01T19:48:18+00:00 + In an email thread between Melvin Carvalho and Mike Hearn on January 1, 2014, the excitement for the new year and upcoming upgrades to Bitcoin is evident. Reflecting on Bitcoin's successful year in 2013, Hearn expresses hope for a faster pace of development in the coming year. Carvalho also expresses gratitude towards Hearn and all those who contributed to Bitcoin's development. Both individuals eagerly anticipate what 2014 will bring for Bitcoin.The email contains a sponsored message for AppDynamics, which offers IT organizations visibility into application performance. Included in the message is a link to start a free trial of AppDynamics Pro. This shows that the email was not solely focused on Bitcoin, but also provided information about other services.Hearn's email, sent on January 1, 2014, emphasizes his excitement for the upcoming year in Bitcoin development. He acknowledges the exciting developments that occurred within the Bitcoin community in 2013, but notes that it was a relatively quiet year for core software upgrades. Hearn expresses his hope that this will change in 2014 and that the pace of development will increase. He wishes everyone a happy new year and expresses his enthusiasm for what lies ahead in 2014. The fact that Bitcoin was one of the 100 most searched for terms in 2013 further highlights Hearn's optimism about the future of Bitcoin.The email includes a signature advertising AppDynamics, a service that provides visibility into application performance. This indicates that Hearn may have been associated with or endorsing AppDynamics at the time the email was sent.The email was sent to the Bitcoin-development mailing list on SourceForge, suggesting that it was intended for a specific audience within the Bitcoin community.In addition to Hearn's email, another message posted by Wendell on hivewallet.com and Twitter on January 1, 2014, echoes similar sentiments. Wendell, who contributed to the development of Hive Wallet, expresses gratitude for being part of the Bitcoin community and believes that 2014 will be an amazing year. Like Hearn, he mentions that although there was significant growth in the Bitcoin community in 2013, there was little change in the core software. Both Wendell and Hearn express excitement about the potential for innovation in the coming year.Overall, despite Bitcoin's successful year in 2013, the core software development remained relatively quiet. However, individuals like Mike Hearn and Wendell are optimistic about the upgrades and progress planned for 2014. Their anticipation for a faster pace of development and enthusiasm for the future of Bitcoin is evident. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Looking-for-GREAT-C-developer-for-exciting-opportunity-in-bitcoin-space.xml b/static/bitcoin-dev/Jan_2014/combined_Looking-for-GREAT-C-developer-for-exciting-opportunity-in-bitcoin-space.xml index 3684281ffe..6e0767cfff 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Looking-for-GREAT-C-developer-for-exciting-opportunity-in-bitcoin-space.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Looking-for-GREAT-C-developer-for-exciting-opportunity-in-bitcoin-space.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Looking for GREAT C++ developer for exciting opportunity in bitcoin space - 2023-08-01T07:07:33.145540+00:00 + 2025-10-11T22:03:56.143553+00:00 + python-feedgen Troy Benjegerdes 2014-01-03 05:11:28+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Looking for GREAT C++ developer for exciting opportunity in bitcoin space - 2023-08-01T07:07:33.145540+00:00 + 2025-10-11T22:03:56.143727+00:00 - A startup called Hawk Financial Group, LLC is seeking one or two experienced C++ programmers who are knowledgeable about Bitcoin internals to join their team. The startup is working on a unique merge-mined altcoin project that aims to provide a valuable service to the entire crypto-coin ecosystem. However, before revealing more details about the project, applicants are required to sign a non-compete/non-disclosure agreement.The startup is particularly interested in candidates who have previous experience in adding features to Bitcoin or related technologies. Those who have made significant contributions in this area will be given preference. Interested individuals can send an email to eduffield82@gmail.com, providing a description of their work experience. The applications will be carefully reviewed, and if deemed suitable, the startup will share their detailed plans with the applicants.In December 2013, Evan Duffield, the founder of Hawk Financial Group, LLC, had originally posted an email to the Bitcoin-development mailing list, seeking skilled C++ programmers for his startup. The goal was to create a merge-mined altcoin that would offer a unique service to the crypto-coin ecosystem. However, this announcement received criticism from Jeremie, a long-time follower of bitcoin-development, who believed that such emails were irrelevant and considered them spam. He expressed concerns that these types of emails would divert true discussions between core-devs elsewhere, making it difficult for people like him to follow them.Meanwhile, Peter Todd, an expert in the field, cautioned against the use of merge mining in altcoins. He argued that without majority or near-majority hashing power, an attacker could easily execute a 51% attack on the altcoin by reusing existing hashing power. Luke, on the other hand, disagreed with Todd's point of view. He stated that any non-scam altcoin would be safe using merged mining because it would be in the attacker's interest to invest in the altcoin rather than attacking it. Luke also mentioned that there are ways to ensure the full security of bitcoin miners even when not all participate in the altcoin.In response to Todd's concerns, he suggested hiring someone competent to analyze the idea and recommended starting a timestamping service as a potential exception to his warning. Todd was willing to discuss the matter informally but was not ready to agree to any non-compete/non-disclosure terms.Additionally, Troy Benjegerdes made a unique offer to the startup by proposing to buy their company using revenue generated by his AGPLv3 copyrighted licensed Minco.me(c) cryptographic currency. He claimed that this currency would revolutionize work by providing a guaranteed income to anyone with a Mincome(C) address, eliminating the need for traditional employment. Benjegerdes advised the startup to seek legal counsel to avoid any potential contamination of their business model with a viral copyright license. 2014-01-03T05:11:28+00:00 + A startup called Hawk Financial Group, LLC is seeking one or two experienced C++ programmers who are knowledgeable about Bitcoin internals to join their team. The startup is working on a unique merge-mined altcoin project that aims to provide a valuable service to the entire crypto-coin ecosystem. However, before revealing more details about the project, applicants are required to sign a non-compete/non-disclosure agreement.The startup is particularly interested in candidates who have previous experience in adding features to Bitcoin or related technologies. Those who have made significant contributions in this area will be given preference. Interested individuals can send an email to eduffield82@gmail.com, providing a description of their work experience. The applications will be carefully reviewed, and if deemed suitable, the startup will share their detailed plans with the applicants.In December 2013, Evan Duffield, the founder of Hawk Financial Group, LLC, had originally posted an email to the Bitcoin-development mailing list, seeking skilled C++ programmers for his startup. The goal was to create a merge-mined altcoin that would offer a unique service to the crypto-coin ecosystem. However, this announcement received criticism from Jeremie, a long-time follower of bitcoin-development, who believed that such emails were irrelevant and considered them spam. He expressed concerns that these types of emails would divert true discussions between core-devs elsewhere, making it difficult for people like him to follow them.Meanwhile, Peter Todd, an expert in the field, cautioned against the use of merge mining in altcoins. He argued that without majority or near-majority hashing power, an attacker could easily execute a 51% attack on the altcoin by reusing existing hashing power. Luke, on the other hand, disagreed with Todd's point of view. He stated that any non-scam altcoin would be safe using merged mining because it would be in the attacker's interest to invest in the altcoin rather than attacking it. Luke also mentioned that there are ways to ensure the full security of bitcoin miners even when not all participate in the altcoin.In response to Todd's concerns, he suggested hiring someone competent to analyze the idea and recommended starting a timestamping service as a potential exception to his warning. Todd was willing to discuss the matter informally but was not ready to agree to any non-compete/non-disclosure terms.Additionally, Troy Benjegerdes made a unique offer to the startup by proposing to buy their company using revenue generated by his AGPLv3 copyrighted licensed Minco.me(c) cryptographic currency. He claimed that this currency would revolutionize work by providing a guaranteed income to anyone with a Mincome(C) address, eliminating the need for traditional employment. Benjegerdes advised the startup to seek legal counsel to avoid any potential contamination of their business model with a viral copyright license. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Merge-mining.xml b/static/bitcoin-dev/Jan_2014/combined_Merge-mining.xml index c5be127cc0..4f2983d75c 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Merge-mining.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Merge-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Merge mining - 2023-08-01T07:08:12.151820+00:00 + 2025-10-11T22:03:17.878037+00:00 + python-feedgen Jorge Timón 2014-01-04 10:34:55+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Merge mining - 2023-08-01T07:08:12.151820+00:00 + 2025-10-11T22:03:17.878177+00:00 - In a discussion about merge mining, David Vorick addresses the concern of a potential attack on Dogecoin. He states that if any large currency were to be attacked, it would probably be litecoin miners attacking dogecoin. However, Vorick argues that an attacker with enough control over the litecoin network to perform such an attack would likely have a vested interest in cryptocurrencies doing well. He believes that a successful attack on dogecoin would cast doubt on the entire cryptocurrency ecosystem and hurt the attacker's interests.Jorge Timón disagrees with Vorick's assumptions and suggests that some individuals within the cryptocurrency ecosystem may actually want dogecoin to disappear. The discussion ends with Timón questioning Vorick's stance on merged mining and whether or not it applies to Dogecoin.The context also highlights the use of the scrypt algorithm by Dogecoin, which is popular among cryptocurrencies. Vorick suggests that attacking a significant currency like Dogecoin would not be beneficial due to the cost and potential backlash it would cause. Moreover, he explains that an attack on a major currency would cast doubt on the entire cryptocurrency ecosystem, drop the value of Bitcoin, and affect all cryptocurrencies using the same work function as Dogecoin.The conversation raises the importance of merged mining for the security of altcoins. It is suggested that attacking a significant currency would be expensive and traumatize the whole system, causing questions to be raised and dropping the value of bitcoin as well as all cryptocurrencies using the same work function. However, with many people having access to large amounts of GPUs, there may not be much cost to conducting a 51% attack on an altcoin beyond a short-term diversion away from profitable mining.Supporting merged mining could make it less straightforward for an individual or group to carry out a 51% attack. The rational decision for a non-scam altcoin is to take advantage of merged mining to maximize security. Luke-Jr argues that using merge mining as a red flag is not entirely accurate since any non-scam altcoin is safe with merged mining. Any potential attacker would have invested in the altcoin instead of attacking it. For non-scam altcoins, the rational decision is to take advantage of merged mining to maximize security.In conclusion, the discussion revolves around the potential for a 51% attack on altcoins and the importance of merged mining for their security. The use of scrypt algorithm by Dogecoin is mentioned, along with the possibility of litecoin miners attacking dogecoin. The context highlights the potential consequences of attacking a large altcoin like Dogecoin or Bitcoin, including the drop in value of Bitcoin and the entire cryptocurrency system. The conversation also raises questions about the interests of potential attackers and the rational decision for altcoins regarding merged mining. 2014-01-04T10:34:55+00:00 + In a discussion about merge mining, David Vorick addresses the concern of a potential attack on Dogecoin. He states that if any large currency were to be attacked, it would probably be litecoin miners attacking dogecoin. However, Vorick argues that an attacker with enough control over the litecoin network to perform such an attack would likely have a vested interest in cryptocurrencies doing well. He believes that a successful attack on dogecoin would cast doubt on the entire cryptocurrency ecosystem and hurt the attacker's interests.Jorge Timón disagrees with Vorick's assumptions and suggests that some individuals within the cryptocurrency ecosystem may actually want dogecoin to disappear. The discussion ends with Timón questioning Vorick's stance on merged mining and whether or not it applies to Dogecoin.The context also highlights the use of the scrypt algorithm by Dogecoin, which is popular among cryptocurrencies. Vorick suggests that attacking a significant currency like Dogecoin would not be beneficial due to the cost and potential backlash it would cause. Moreover, he explains that an attack on a major currency would cast doubt on the entire cryptocurrency ecosystem, drop the value of Bitcoin, and affect all cryptocurrencies using the same work function as Dogecoin.The conversation raises the importance of merged mining for the security of altcoins. It is suggested that attacking a significant currency would be expensive and traumatize the whole system, causing questions to be raised and dropping the value of bitcoin as well as all cryptocurrencies using the same work function. However, with many people having access to large amounts of GPUs, there may not be much cost to conducting a 51% attack on an altcoin beyond a short-term diversion away from profitable mining.Supporting merged mining could make it less straightforward for an individual or group to carry out a 51% attack. The rational decision for a non-scam altcoin is to take advantage of merged mining to maximize security. Luke-Jr argues that using merge mining as a red flag is not entirely accurate since any non-scam altcoin is safe with merged mining. Any potential attacker would have invested in the altcoin instead of attacking it. For non-scam altcoins, the rational decision is to take advantage of merged mining to maximize security.In conclusion, the discussion revolves around the potential for a 51% attack on altcoins and the importance of merged mining for their security. The use of scrypt algorithm by Dogecoin is mentioned, along with the possibility of litecoin miners attacking dogecoin. The context highlights the potential consequences of attacking a large altcoin like Dogecoin or Bitcoin, including the drop in value of Bitcoin and the entire cryptocurrency system. The conversation also raises questions about the interests of potential attackers and the rational decision for altcoins regarding merged mining. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml b/static/bitcoin-dev/Jan_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml index 40d938ea1c..282fa44154 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.614614+00:00 + 2025-10-11T22:03:09.376188+00:00 + python-feedgen Alex Kotenko 2014-07-02 08:49:10+00:00 @@ -271,13 +272,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.615612+00:00 + 2025-10-11T22:03:09.376448+00:00 - In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. 2014-07-02T08:49:10+00:00 + In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Payment-protocol-and-reliable-Payment-messages.xml b/static/bitcoin-dev/Jan_2014/combined_Payment-protocol-and-reliable-Payment-messages.xml index 0ee15d033f..87355d8c65 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Payment-protocol-and-reliable-Payment-messages.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Payment-protocol-and-reliable-Payment-messages.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment protocol and reliable Payment messages - 2023-08-01T07:15:42.657911+00:00 + 2025-10-11T22:03:20.000788+00:00 + python-feedgen Adam Back 2014-01-14 13:18:38+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Payment protocol and reliable Payment messages - 2023-08-01T07:15:42.657911+00:00 + 2025-10-11T22:03:20.000958+00:00 - One potential flaw in the payment system involving contract hash is that it assumes the merchant will cash the funds or reimburse via the refund address. However, a rational yet abusive move for the merchant would be to let the buyer's funds sit in limbo and force the buyer to initiate a dispute. Dispute resolution may not be worth the cost, especially if the seller is anonymous or located in another country. To address this issue, it may be beneficial for the buyer to have time-stamped evidence of sending the funds to the merchant and proof that the merchant did not collect the funds. This evidence could include omission from the blockchain.The discussion revolves around fair advertising rules, particularly in the context of dynamic pricing and revocable bids in trading. The concern is that merchants may use aggressive tactics such as retracting offers after partial commitment from customers or systematic abuse of pricing mistakes. One approach is to send a payment message to the merchant who then broadcasts the transaction to claim funds, with the user relying on the merchant for retraction. Another approach is for the user to broadcast the transaction and payment message to the merchant. To prevent retraction, the transaction can be bound to the payment message using a hash function. It is noted that if a merchant systematically retracts advertised offers, it could be evidence of unfair trading leading to censure.In an email conversation on January 14, 2014, Mike Hearn posed a hypothetical question about payment requests and merchants changing their minds. The email thread discusses the legal binding of a payment request for a specified amount of time, where if the merchant changes his mind after receiving payment from the customer, it is considered problematic. The email also talks about how a payment request is legally binding, and the contract becomes valid if the customer accepts the offer by paying. It mentions that there are extreme cases covered by law that can override this process. The email concludes with questions about the relevance of an expiry time in the message and the purpose of a payment request if it's not binding.As a prospective buyer, imagine receiving an offer from a merchant that you would like to accept, but the merchant changes their mind. In most cases, if the merchant has not delivered the product or service yet, they are allowed to change their mind without any issues. The problem arises only when the merchant changes their mind after you have made the payment.In an email exchange, Pieter Wuille expressed his concerns about the possibility of a transaction being confirmed while the associated payment is not delivered. He stated that if this happens, it means that the payment transmission cannot be relied upon. However, he later acknowledged that there may be certain situations where broadcasting the transaction to the peer-to-peer network would be necessary even if the payment messages are lost. Specifically, in cases where merchants change their minds about accepting payments after a good offer has been made, broadcasting the transaction to the blockchain would allow for the presentation of confirmed payment requests in legal proceedings.The context of the conversation involves a proposal by an individual named Pieter Wuille regarding the use of a payment protocol for face-to-face payments. The proposal entails using payment requests via NFC or QR, payment messages and payment confirmations through Bluetooth. Wuille suggests that this can be done by incorporating a Bluetooth MAC address into the payment URL. The person responding to the proposal acknowledges this suggestion and expresses no issues with it.In an email exchange between Andreas Schildbach and Pieter Wuille, the two discussed the issue of ensuring that a payment is delivered with a Bitcoin transaction. Wuille proposed that if a payment URL is present, it should be encouraged to only send the payment there instead of broadcasting the transaction on the P2P network, which would minimize the risk of confirming a transaction without receiving payment. Schildbach agreed with this proposal but also noted that wallets must still be able to deal with scenarios where the payment fails even if the transaction succeeds. Wuille expressed his desire to use the payment protocol for face-to-face payments as well, using NFC or QR for payment requests and Bluetooth for payment confirmations. Schildbach was aware of this and asked what issues Wuille saw. The two also discussed the potential for HTTP failures in payments over the internet.In an email dated January 13, 2014, Pieter Wuille suggested optimizing BitcoinJ's payment URL feature by only sending payments through the URL and not broadcasting transactions on the P2P network. This would minimize the risk of a transaction confirming without the payment being received, though it cannot be guaranteed. However, another individual questioned the effectiveness of this approach, arguing that relying solely on HTTP connections could result in more failed payments due to potential issues with proxies or Bluetooth endpoints. They suggested having fallback payment URLs in case of such failures. Additionally, the proposal was noted to conflict with the use of the payment protocol for face-to-face payments, which require NFC or QR payment requests, Bluetooth messages for payment confirmation, and the inclusion of a Bluetooth MAC address in the payment URL 2014-01-14T13:18:38+00:00 + One potential flaw in the payment system involving contract hash is that it assumes the merchant will cash the funds or reimburse via the refund address. However, a rational yet abusive move for the merchant would be to let the buyer's funds sit in limbo and force the buyer to initiate a dispute. Dispute resolution may not be worth the cost, especially if the seller is anonymous or located in another country. To address this issue, it may be beneficial for the buyer to have time-stamped evidence of sending the funds to the merchant and proof that the merchant did not collect the funds. This evidence could include omission from the blockchain.The discussion revolves around fair advertising rules, particularly in the context of dynamic pricing and revocable bids in trading. The concern is that merchants may use aggressive tactics such as retracting offers after partial commitment from customers or systematic abuse of pricing mistakes. One approach is to send a payment message to the merchant who then broadcasts the transaction to claim funds, with the user relying on the merchant for retraction. Another approach is for the user to broadcast the transaction and payment message to the merchant. To prevent retraction, the transaction can be bound to the payment message using a hash function. It is noted that if a merchant systematically retracts advertised offers, it could be evidence of unfair trading leading to censure.In an email conversation on January 14, 2014, Mike Hearn posed a hypothetical question about payment requests and merchants changing their minds. The email thread discusses the legal binding of a payment request for a specified amount of time, where if the merchant changes his mind after receiving payment from the customer, it is considered problematic. The email also talks about how a payment request is legally binding, and the contract becomes valid if the customer accepts the offer by paying. It mentions that there are extreme cases covered by law that can override this process. The email concludes with questions about the relevance of an expiry time in the message and the purpose of a payment request if it's not binding.As a prospective buyer, imagine receiving an offer from a merchant that you would like to accept, but the merchant changes their mind. In most cases, if the merchant has not delivered the product or service yet, they are allowed to change their mind without any issues. The problem arises only when the merchant changes their mind after you have made the payment.In an email exchange, Pieter Wuille expressed his concerns about the possibility of a transaction being confirmed while the associated payment is not delivered. He stated that if this happens, it means that the payment transmission cannot be relied upon. However, he later acknowledged that there may be certain situations where broadcasting the transaction to the peer-to-peer network would be necessary even if the payment messages are lost. Specifically, in cases where merchants change their minds about accepting payments after a good offer has been made, broadcasting the transaction to the blockchain would allow for the presentation of confirmed payment requests in legal proceedings.The context of the conversation involves a proposal by an individual named Pieter Wuille regarding the use of a payment protocol for face-to-face payments. The proposal entails using payment requests via NFC or QR, payment messages and payment confirmations through Bluetooth. Wuille suggests that this can be done by incorporating a Bluetooth MAC address into the payment URL. The person responding to the proposal acknowledges this suggestion and expresses no issues with it.In an email exchange between Andreas Schildbach and Pieter Wuille, the two discussed the issue of ensuring that a payment is delivered with a Bitcoin transaction. Wuille proposed that if a payment URL is present, it should be encouraged to only send the payment there instead of broadcasting the transaction on the P2P network, which would minimize the risk of confirming a transaction without receiving payment. Schildbach agreed with this proposal but also noted that wallets must still be able to deal with scenarios where the payment fails even if the transaction succeeds. Wuille expressed his desire to use the payment protocol for face-to-face payments as well, using NFC or QR for payment requests and Bluetooth for payment confirmations. Schildbach was aware of this and asked what issues Wuille saw. The two also discussed the potential for HTTP failures in payments over the internet.In an email dated January 13, 2014, Pieter Wuille suggested optimizing BitcoinJ's payment URL feature by only sending payments through the URL and not broadcasting transactions on the P2P network. This would minimize the risk of a transaction confirming without the payment being received, though it cannot be guaranteed. However, another individual questioned the effectiveness of this approach, arguing that relying solely on HTTP connections could result in more failed payments due to potential issues with proxies or Bluetooth endpoints. They suggested having fallback payment URLs in case of such failures. Additionally, the proposal was noted to conflict with the use of the payment protocol for face-to-face payments, which require NFC or QR payment requests, Bluetooth messages for payment confirmation, and the inclusion of a Bluetooth MAC address in the payment URL - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Privacy-and-blockchain-data.xml b/static/bitcoin-dev/Jan_2014/combined_Privacy-and-blockchain-data.xml index 25a54e3acb..5af485be17 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Privacy-and-blockchain-data.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Privacy-and-blockchain-data.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Privacy and blockchain data - 2023-08-01T07:11:17.546554+00:00 + 2025-10-11T22:03:37.006092+00:00 + python-feedgen Peter Todd 2014-01-10 10:10:51+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Privacy and blockchain data - 2023-08-01T07:11:17.546554+00:00 + 2025-10-11T22:03:37.006232+00:00 - The email conversation revolves around the trade-off between privacy and bandwidth in Bitcoin wallets. The concept is to generate addresses with a fixed prefix, which determines the anonymity set and the associated trade-off between privacy and bandwidth throughout the wallet's lifespan. However, this method expands the potential attackers from just those monitoring SPV queries to anyone with a copy of the blockchain. To enhance privacy, it is recommended to use non-specific filters and prefixed addresses for incoming payments.Instead of matching prefix filters against unspent transaction outputs (UTXO), it is suggested to match them against all transaction outputs within blocks. This approach increases privacy but also widens the scope of potential attackers. It is worth noting that change transaction outputs should not have prefixes to prevent easy identification of spend versus change addresses in a transaction.One way to achieve a privacy/bandwidth trade-off is by generating addresses with common prefixes, where the length of the prefix determines the size of the anonymity set. However, using this method allows anyone with a copy of the blockchain to become a potential attacker, rather than just those monitoring SPV queries. The current UTXO set comprises 7.4 million unspent outputs, 2.2 million transactions with unspent outputs, and 2.1 million unique unspent scriptPubKeys. If an 8-bit prefix is used, there would be approximately 10,000 transactions in the monitored UTXO. By analyzing the different days or time-periods a user transacted, an attacker could potentially deduce their prefix. Furthermore, anyone the user transacts with would directly know their prefix, making it easier to identify spend versus change addresses in a transaction.The provided context delves into the technical aspects of Bitcoin wallets and how they handle transaction outputs while safeguarding privacy. To ensure scalability, efficiency, and privacy, the wallet keeps track of all transactions associated with scriptPubKeys without scanning the entire blockchain for relevant information. However, syncing a wallet can inadvertently disclose information about the coins owned, leaving it susceptible to attacks from both internal and global adversaries. The article outlines a threat model and highlights the objectives of maintaining privacy against such attacks.The fundamental functionalities of spending funds, receiving new funds, detecting unauthorized spends, and confirming transactions are explained. To enhance scalability and efficiency, the workload is distributed across multiple nodes at both per-block and within-block levels. Deterministic wallets, utilizing technologies like BIP32, have gained popularity due to their simple backup models. Various query schemes, such as Bloom filters, prefix filters, and cryptographically blinded schemes, are examined, while addressing potential correlation attacks and denial-of-service (DoS) attacks.The article also covers address usage, management, and generation to address the challenge of users expecting prompt notifications for new transactions, regardless of the address generated by their wallet, while still maintaining privacy. The overarching objective of the article is to provide readers with a comprehensive understanding of Bitcoin wallets and their mechanisms. 2014-01-10T10:10:51+00:00 + The email conversation revolves around the trade-off between privacy and bandwidth in Bitcoin wallets. The concept is to generate addresses with a fixed prefix, which determines the anonymity set and the associated trade-off between privacy and bandwidth throughout the wallet's lifespan. However, this method expands the potential attackers from just those monitoring SPV queries to anyone with a copy of the blockchain. To enhance privacy, it is recommended to use non-specific filters and prefixed addresses for incoming payments.Instead of matching prefix filters against unspent transaction outputs (UTXO), it is suggested to match them against all transaction outputs within blocks. This approach increases privacy but also widens the scope of potential attackers. It is worth noting that change transaction outputs should not have prefixes to prevent easy identification of spend versus change addresses in a transaction.One way to achieve a privacy/bandwidth trade-off is by generating addresses with common prefixes, where the length of the prefix determines the size of the anonymity set. However, using this method allows anyone with a copy of the blockchain to become a potential attacker, rather than just those monitoring SPV queries. The current UTXO set comprises 7.4 million unspent outputs, 2.2 million transactions with unspent outputs, and 2.1 million unique unspent scriptPubKeys. If an 8-bit prefix is used, there would be approximately 10,000 transactions in the monitored UTXO. By analyzing the different days or time-periods a user transacted, an attacker could potentially deduce their prefix. Furthermore, anyone the user transacts with would directly know their prefix, making it easier to identify spend versus change addresses in a transaction.The provided context delves into the technical aspects of Bitcoin wallets and how they handle transaction outputs while safeguarding privacy. To ensure scalability, efficiency, and privacy, the wallet keeps track of all transactions associated with scriptPubKeys without scanning the entire blockchain for relevant information. However, syncing a wallet can inadvertently disclose information about the coins owned, leaving it susceptible to attacks from both internal and global adversaries. The article outlines a threat model and highlights the objectives of maintaining privacy against such attacks.The fundamental functionalities of spending funds, receiving new funds, detecting unauthorized spends, and confirming transactions are explained. To enhance scalability and efficiency, the workload is distributed across multiple nodes at both per-block and within-block levels. Deterministic wallets, utilizing technologies like BIP32, have gained popularity due to their simple backup models. Various query schemes, such as Bloom filters, prefix filters, and cryptographically blinded schemes, are examined, while addressing potential correlation attacks and denial-of-service (DoS) attacks.The article also covers address usage, management, and generation to address the challenge of users expecting prompt notifications for new transactions, regardless of the address generated by their wallet, while still maintaining privacy. The overarching objective of the article is to provide readers with a comprehensive understanding of Bitcoin wallets and their mechanisms. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Stealth-Addresses.xml b/static/bitcoin-dev/Jan_2014/combined_Stealth-Addresses.xml index 5a92c0287f..212b4936d6 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Stealth-Addresses.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Stealth-Addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Stealth Addresses - 2023-08-01T07:12:42.080079+00:00 + 2025-10-11T22:03:24.260151+00:00 + python-feedgen Dan Carter 2014-03-06 12:23:40+00:00 @@ -307,13 +308,13 @@ - python-feedgen + 2 Combined summary - Stealth Addresses - 2023-08-01T07:12:42.081104+00:00 + 2025-10-11T22:03:24.260459+00:00 - In a series of email exchanges, developers Peter Todd and Jeremy Spilman discussed various aspects of implementing stealth addresses in Bitcoin. They discussed using a master shared secret to derive per-pubkey secrets and the possibility of adding a counter to the hash function to improve stealthiness. They also explored the use of multi-sig and P2SH outputs for better anonymity and compatibility with other wallets.In another email exchange, Spilman asked why two EC points were not used in the stealth address. Todd explained that he had implemented both pubKeys in a 2-of-2 multisig instead, to prevent false positives on the online detection key while funds are still controlled by the payer. They also discussed the process of nonce recovery with ECDH and the need for defining a reasonable stealth address spec.The conversation then shifted to integrating stealth addresses into OpenPGP keys or x.509 certs, with the aim of making them usable for P2P payments. Todd suggested replacing static address text with new 'href=bitcoin:xSTL...' URIs to encourage their usage. He also emphasized the importance of identifying the recipient and proposed adding stealth addresses to the Output message rather than the PaymentDetails field.In a separate email exchange, Spilman and Todd discussed the implementation of stealth addresses for Payment Protocol. They debated the feasibility of certain approaches, such as adding a prefix to the OP_RETURN TxOut and symmetric encryption of P. Privacy risks and potential reduced anonymity sets were considered in these discussions.Other topics covered included the under-addressed use case of non-transactional personal payments, the concept of sending "please pay me" messages, and the differences between Reiner's proposal and stealth addresses. The advantages and complexities of different payment schemes were examined, including the use of BIP32 branches and the necessity of bidirectional communication.Overall, these email exchanges shed light on the technical considerations and challenges involved in implementing stealth addresses in Bitcoin, as well as the potential use cases and benefits they offer.The scriptPubKey/transaction generation scheme known as Stealth Address is designed to allow payees to share a single, fixed address with payors. This enables efficient, private, reliable, and non-interactive fund transfers. The generated scriptPubKey must be unique globally and only spendable by the intended payee. It is essential that this method is fully deterministic so that funds can be recovered using a wallet seed and blockchain data for both the payee and the payor.Importantly, the scheme must be compatible with CoinJoin, a privacy-enhancing technique, and should not reveal any information to the payee about which transaction inputs were used to make payments to them. Additionally, it offers the flexibility to trade off anonymity set size for decreased bandwidth and CPU usage. This can be achieved by allowing the payee to specify that payments matching a short prefix, k, are acceptable.An alternative approach to increase efficiency could involve using bare OP_CHECK(MULTI)SIG outputs to hold the nonce pubkey. For multisig support, the scheme must allow for the specification of n-of-m master pubkeys using the nonce to generate derived ones.It is worth noting that addresses generated using this method will be slightly longer than standard Bitcoin addresses. 2014-03-06T12:23:40+00:00 + In a series of email exchanges, developers Peter Todd and Jeremy Spilman discussed various aspects of implementing stealth addresses in Bitcoin. They discussed using a master shared secret to derive per-pubkey secrets and the possibility of adding a counter to the hash function to improve stealthiness. They also explored the use of multi-sig and P2SH outputs for better anonymity and compatibility with other wallets.In another email exchange, Spilman asked why two EC points were not used in the stealth address. Todd explained that he had implemented both pubKeys in a 2-of-2 multisig instead, to prevent false positives on the online detection key while funds are still controlled by the payer. They also discussed the process of nonce recovery with ECDH and the need for defining a reasonable stealth address spec.The conversation then shifted to integrating stealth addresses into OpenPGP keys or x.509 certs, with the aim of making them usable for P2P payments. Todd suggested replacing static address text with new 'href=bitcoin:xSTL...' URIs to encourage their usage. He also emphasized the importance of identifying the recipient and proposed adding stealth addresses to the Output message rather than the PaymentDetails field.In a separate email exchange, Spilman and Todd discussed the implementation of stealth addresses for Payment Protocol. They debated the feasibility of certain approaches, such as adding a prefix to the OP_RETURN TxOut and symmetric encryption of P. Privacy risks and potential reduced anonymity sets were considered in these discussions.Other topics covered included the under-addressed use case of non-transactional personal payments, the concept of sending "please pay me" messages, and the differences between Reiner's proposal and stealth addresses. The advantages and complexities of different payment schemes were examined, including the use of BIP32 branches and the necessity of bidirectional communication.Overall, these email exchanges shed light on the technical considerations and challenges involved in implementing stealth addresses in Bitcoin, as well as the potential use cases and benefits they offer.The scriptPubKey/transaction generation scheme known as Stealth Address is designed to allow payees to share a single, fixed address with payors. This enables efficient, private, reliable, and non-interactive fund transfers. The generated scriptPubKey must be unique globally and only spendable by the intended payee. It is essential that this method is fully deterministic so that funds can be recovered using a wallet seed and blockchain data for both the payee and the payor.Importantly, the scheme must be compatible with CoinJoin, a privacy-enhancing technique, and should not reveal any information to the payee about which transaction inputs were used to make payments to them. Additionally, it offers the flexibility to trade off anonymity set size for decreased bandwidth and CPU usage. This can be achieved by allowing the payee to specify that payments matching a short prefix, k, are acceptable.An alternative approach to increase efficiency could involve using bare OP_CHECK(MULTI)SIG outputs to hold the nonce pubkey. For multisig support, the scheme must allow for the specification of n-of-m master pubkeys using the nonce to generate derived ones.It is worth noting that addresses generated using this method will be slightly longer than standard Bitcoin addresses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Stealth-Payments-Sample-Code-Proof-of-Concept.xml b/static/bitcoin-dev/Jan_2014/combined_Stealth-Payments-Sample-Code-Proof-of-Concept.xml index abf761c593..fdadea8e8f 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Stealth-Payments-Sample-Code-Proof-of-Concept.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Stealth-Payments-Sample-Code-Proof-of-Concept.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Stealth Payments - Sample Code / Proof of Concept - 2023-08-01T07:15:05.659532+00:00 + 2025-10-11T22:03:49.747951+00:00 + python-feedgen Jeremy Spilman 2014-01-13 14:10:14+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Stealth Payments - Sample Code / Proof of Concept - 2023-08-01T07:15:05.659532+00:00 + 2025-10-11T22:03:49.748115+00:00 - On January 13, 2014, a transaction was made on the Bitcoin TestNet, where Jeremy Spilman spent 1BTC to a stealth address. Mike Hearn questioned whether this transaction could be redeemed. Spilman shared the code he used to generate the transaction on GitHub, which was based on a private C# bitcoin implementation. The libraries used were standard Bitcoin/EC/BIP32 stuff using OpenSSL instead of BouncyCastle.During their discussion, Hearn and Spilman considered whether the 0BTC OP_RETURN transactions should be hidden from the Transaction List. They agreed that displaying "Payment received from Jeremy, 0.1 BTC" would be more appropriate than showing the transaction details. They also suggested changing the name of the address column from "Merchant" to "Recipient."Hearn proposed extending the wallet format to keep 'd2'/'Q2' unencrypted for testing purposes but not as a stand-alone private key. He expressed concern about the possibility of people detecting such payments by testing if decrypted values are points on the curve, although he was unsure about the specific risks involved.Eventually, Spilman's stealth redemption transaction was successfully sent using sendrawtransaction. He signed off for the night, concluding their discussion.In summary, the conversation on January 13, 2014, revolved around a Bitcoin transaction on the TestNet. Spilman spent 1BTC to a stealth address, prompting discussions about redeeming the transaction, hiding 0BTC OP_RETURN transactions from the Transaction List, and potential changes to the wallet format. There were also concerns about the security risks associated with detecting such payments and verifying the transactions. 2014-01-13T14:10:14+00:00 + On January 13, 2014, a transaction was made on the Bitcoin TestNet, where Jeremy Spilman spent 1BTC to a stealth address. Mike Hearn questioned whether this transaction could be redeemed. Spilman shared the code he used to generate the transaction on GitHub, which was based on a private C# bitcoin implementation. The libraries used were standard Bitcoin/EC/BIP32 stuff using OpenSSL instead of BouncyCastle.During their discussion, Hearn and Spilman considered whether the 0BTC OP_RETURN transactions should be hidden from the Transaction List. They agreed that displaying "Payment received from Jeremy, 0.1 BTC" would be more appropriate than showing the transaction details. They also suggested changing the name of the address column from "Merchant" to "Recipient."Hearn proposed extending the wallet format to keep 'd2'/'Q2' unencrypted for testing purposes but not as a stand-alone private key. He expressed concern about the possibility of people detecting such payments by testing if decrypted values are points on the curve, although he was unsure about the specific risks involved.Eventually, Spilman's stealth redemption transaction was successfully sent using sendrawtransaction. He signed off for the night, concluding their discussion.In summary, the conversation on January 13, 2014, revolved around a Bitcoin transaction on the TestNet. Spilman spent 1BTC to a stealth address, prompting discussions about redeeming the transaction, hiding 0BTC OP_RETURN transactions from the Transaction List, and potential changes to the wallet format. There were also concerns about the security risks associated with detecting such payments and verifying the transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Suggestion-allow-receivers-to-pay-optional-fee-for-transactions-without-fees.xml b/static/bitcoin-dev/Jan_2014/combined_Suggestion-allow-receivers-to-pay-optional-fee-for-transactions-without-fees.xml index a04dc6087f..2f90d1977d 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Suggestion-allow-receivers-to-pay-optional-fee-for-transactions-without-fees.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Suggestion-allow-receivers-to-pay-optional-fee-for-transactions-without-fees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Suggestion: allow receivers to pay optional fee for transactions without fees - 2023-08-01T07:17:39.630212+00:00 + 2025-10-11T22:03:26.384980+00:00 + python-feedgen Luke-Jr 2014-01-17 05:40:52+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Suggestion: allow receivers to pay optional fee for transactions without fees - 2023-08-01T07:17:39.630212+00:00 + 2025-10-11T22:03:26.385125+00:00 - In January 2014, a user named Dâniel Fraga shared his experience of receiving a small donation without any fees attached. He expressed concern that such transactions are typically rejected by miners and wondered if there was a way for the receiver to pay the fee when the sender didn't. Fraga suggested that Bitcoin-qt could warn the receiver about receiving a transaction without a fee and offer the option to attach a fee for faster confirmation.In response to Fraga's suggestion, Ben Davenport explained that there is no need for protocol changes to allow the receiver to pay a fee. He suggested creating a transaction that spends the output to oneself and attaching a fee to it. In order for miners to grab the transaction fee, they would also have to mine the original transaction. While this process may currently require manual intervention, software could be developed to simplify it.Christophe Biocca also emphasized the importance of miners recognizing and accounting for the situation of "child pays for parent patch." Currently, only eligius is running it, but proposals have been made to merge it into mainline. Biocca believed that if a transaction is relayed directly to Eligius, it would likely get mined. However, he noted that creating the transaction is considered the difficult part. Biocca further suggested that mining nodes should not be running mainline and instead set up their own customized transaction policies.Overall, the discussion highlighted the challenges associated with transactions without fees and proposed solutions to allow the receiver to pay a fee. While some ideas are already being implemented by certain miners, there is potential for further improvements in the future. 2014-01-17T05:40:52+00:00 + In January 2014, a user named Dâniel Fraga shared his experience of receiving a small donation without any fees attached. He expressed concern that such transactions are typically rejected by miners and wondered if there was a way for the receiver to pay the fee when the sender didn't. Fraga suggested that Bitcoin-qt could warn the receiver about receiving a transaction without a fee and offer the option to attach a fee for faster confirmation.In response to Fraga's suggestion, Ben Davenport explained that there is no need for protocol changes to allow the receiver to pay a fee. He suggested creating a transaction that spends the output to oneself and attaching a fee to it. In order for miners to grab the transaction fee, they would also have to mine the original transaction. While this process may currently require manual intervention, software could be developed to simplify it.Christophe Biocca also emphasized the importance of miners recognizing and accounting for the situation of "child pays for parent patch." Currently, only eligius is running it, but proposals have been made to merge it into mainline. Biocca believed that if a transaction is relayed directly to Eligius, it would likely get mined. However, he noted that creating the transaction is considered the difficult part. Biocca further suggested that mining nodes should not be running mainline and instead set up their own customized transaction policies.Overall, the discussion highlighted the challenges associated with transactions without fees and proposed solutions to allow the receiver to pay a fee. While some ideas are already being implemented by certain miners, there is potential for further improvements in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_The-insecurity-of-merge-mining.xml b/static/bitcoin-dev/Jan_2014/combined_The-insecurity-of-merge-mining.xml index 74e8efd531..0b4bd1ab05 100644 --- a/static/bitcoin-dev/Jan_2014/combined_The-insecurity-of-merge-mining.xml +++ b/static/bitcoin-dev/Jan_2014/combined_The-insecurity-of-merge-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The insecurity of merge-mining - 2023-08-01T07:09:46.713350+00:00 + 2025-10-11T22:03:51.873163+00:00 + python-feedgen Jorge Timón 2014-01-10 18:50:36+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - The insecurity of merge-mining - 2023-08-01T07:09:46.713350+00:00 + 2025-10-11T22:03:51.873306+00:00 - Peter Todd discusses the concept of merged mining and its potential impact on altcoins. He notes that there are not many mining pools available, but some altcoins like Ixcoin and Devcoin have been lucky enough to receive support from a larger pool. Todd believes that implementing yet another independent altcoin is not the solution, as there are other currencies like local currencies or colored coins that may fit their needs better without the need for extensive resources. He recommends merged mining because it is more secure for both the altcoin and Bitcoin, as well as better for the environment. However, he acknowledges that non-merged mined chains are still more popular, despite being less efficient and secure.The conversation also touches on decentralized consensus systems competing for market share and the potential for attacks from miners of established systems. The survival of altcoins like Devcoin and Ixcoin can be attributed to their luck in receiving support from larger mining pools, leading to concerns over public relations for attackers. The cost of attacking a competitor coin is high, making it unlikely for Bitcoiners to defend their currency against local currency or barter clubs. The discussion extends to the issue of merge mining being insecure and whether the harm caused to participants in the old system outweighs the benefits of the new system.Peter Todd also discusses the situation with Twister, a P2P microblogging platform that has created its own blockchain for registering usernames. He suggests that using Namecoin instead would have been a better option, as it has more support and merging mining could be a solution. However, at present, the hashing power behind Twister is minimal, making it vulnerable to attack. Todd concludes by saying that if a system does not compensate its miners adequately, it will likely be insecure.The conversation between Todd and Jorge Timón revolves around the security of altcoins versus merged mined ones. They discuss the possibility of miners attacking a competitor coin to protect their own interests and investments. They also touch on the issue of proof-of-sacrifice as a security mechanism and the viability of merge-mined altcoins. Todd argues that merge-mining is not secure, but regular mining is not much better either. Timón questions the economics of merged mining and asks for further discussion on the topic.In another discussion, Todd and Luke-Jr debate the security of merged mining. Todd raises concerns about non-majority cryptocurrencies being vulnerable to 51% attacks from attackers who can reuse existing hashing power. He argues that the value of a cryptocurrency is not equal among all miners, and attacking a currency comes with opportunity costs. Luke-Jr disagrees and believes that any non-scam altcoin is safe using merged mining, as attackers would have an incentive to invest in the altcoin instead of attacking it. They also discuss the idea of a merge-mined Zerocoin implementation and the security of Namecoin versus Litecoin.Overall, the discussions highlight the challenges and potential risks associated with merged mining and the security of altcoins. The conversations explore different perspectives on the topic and raise important considerations for the future development and adoption of cryptocurrencies.In a Bitcoin-wizards mailing list, a member suggested that tying an altcoin directly to Bitcoin's proof-of-work would protect it from a 51% attack. However, another member disagreed, pointing out that this would not prevent a 51% attack because attackers could mine a conflicting chain and there is no reasonable way to choose between the two chains without proof-of-something. Solving double spending with proof-of-publication requires a mathematically verifiable majority aligned with the interests of the crypto-coin users. Last summer, a solution was proposed that could detect an attack and determine how many bitcoins needed to be sacrificed to secure the chain.In a January 1st, 2014 email exchange between Peter Todd and Luke-Jr, they discussed the potential security issue of merge-mining for altcoins. Todd argued that merge-mining makes it easy for attackers to perform a 51% attack on altcoins with low hashing power. On the other hand, Luke-Jr disagreed, asserting that any non-scam altcoin is safe using merged mining because attackers would have an interest in investing in the altcoin rather than attacking it. He also stated that merged mining can enhance the security of non-scam altcoins. Todd countered by stating that the value of a cryptocurrency is not equal to all miners. He presented a hypothetical scenario where he creates a merge-mined Zerocoin implementation with an enforced BTC/ZTC exchange rate. In this case, some miners may not agree with enabling better privacy or their local governments may not allow it, making the system vulnerable to attack. However, if the Zerocoin scheme was implemented by embedding ZTC transactions within standard Bitcoin transactions, even without hiding them, attackers would need a 50% majority of hashing power to succeed. The trade-off would be potentially slower confirmations.During the merged mining discussion, Luke-Jr disagreed with Todd's claim that using merge 2014-01-10T18:50:36+00:00 + Peter Todd discusses the concept of merged mining and its potential impact on altcoins. He notes that there are not many mining pools available, but some altcoins like Ixcoin and Devcoin have been lucky enough to receive support from a larger pool. Todd believes that implementing yet another independent altcoin is not the solution, as there are other currencies like local currencies or colored coins that may fit their needs better without the need for extensive resources. He recommends merged mining because it is more secure for both the altcoin and Bitcoin, as well as better for the environment. However, he acknowledges that non-merged mined chains are still more popular, despite being less efficient and secure.The conversation also touches on decentralized consensus systems competing for market share and the potential for attacks from miners of established systems. The survival of altcoins like Devcoin and Ixcoin can be attributed to their luck in receiving support from larger mining pools, leading to concerns over public relations for attackers. The cost of attacking a competitor coin is high, making it unlikely for Bitcoiners to defend their currency against local currency or barter clubs. The discussion extends to the issue of merge mining being insecure and whether the harm caused to participants in the old system outweighs the benefits of the new system.Peter Todd also discusses the situation with Twister, a P2P microblogging platform that has created its own blockchain for registering usernames. He suggests that using Namecoin instead would have been a better option, as it has more support and merging mining could be a solution. However, at present, the hashing power behind Twister is minimal, making it vulnerable to attack. Todd concludes by saying that if a system does not compensate its miners adequately, it will likely be insecure.The conversation between Todd and Jorge Timón revolves around the security of altcoins versus merged mined ones. They discuss the possibility of miners attacking a competitor coin to protect their own interests and investments. They also touch on the issue of proof-of-sacrifice as a security mechanism and the viability of merge-mined altcoins. Todd argues that merge-mining is not secure, but regular mining is not much better either. Timón questions the economics of merged mining and asks for further discussion on the topic.In another discussion, Todd and Luke-Jr debate the security of merged mining. Todd raises concerns about non-majority cryptocurrencies being vulnerable to 51% attacks from attackers who can reuse existing hashing power. He argues that the value of a cryptocurrency is not equal among all miners, and attacking a currency comes with opportunity costs. Luke-Jr disagrees and believes that any non-scam altcoin is safe using merged mining, as attackers would have an incentive to invest in the altcoin instead of attacking it. They also discuss the idea of a merge-mined Zerocoin implementation and the security of Namecoin versus Litecoin.Overall, the discussions highlight the challenges and potential risks associated with merged mining and the security of altcoins. The conversations explore different perspectives on the topic and raise important considerations for the future development and adoption of cryptocurrencies.In a Bitcoin-wizards mailing list, a member suggested that tying an altcoin directly to Bitcoin's proof-of-work would protect it from a 51% attack. However, another member disagreed, pointing out that this would not prevent a 51% attack because attackers could mine a conflicting chain and there is no reasonable way to choose between the two chains without proof-of-something. Solving double spending with proof-of-publication requires a mathematically verifiable majority aligned with the interests of the crypto-coin users. Last summer, a solution was proposed that could detect an attack and determine how many bitcoins needed to be sacrificed to secure the chain.In a January 1st, 2014 email exchange between Peter Todd and Luke-Jr, they discussed the potential security issue of merge-mining for altcoins. Todd argued that merge-mining makes it easy for attackers to perform a 51% attack on altcoins with low hashing power. On the other hand, Luke-Jr disagreed, asserting that any non-scam altcoin is safe using merged mining because attackers would have an interest in investing in the altcoin rather than attacking it. He also stated that merged mining can enhance the security of non-scam altcoins. Todd countered by stating that the value of a cryptocurrency is not equal to all miners. He presented a hypothetical scenario where he creates a merge-mined Zerocoin implementation with an enforced BTC/ZTC exchange rate. In this case, some miners may not agree with enabling better privacy or their local governments may not allow it, making the system vulnerable to attack. However, if the Zerocoin scheme was implemented by embedding ZTC transactions within standard Bitcoin transactions, even without hiding them, attackers would need a 50% majority of hashing power to succeed. The trade-off would be potentially slower confirmations.During the merged mining discussion, Luke-Jr disagreed with Todd's claim that using merge - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_Tor-SPV.xml b/static/bitcoin-dev/Jan_2014/combined_Tor-SPV.xml index c403c22e1e..27ef67b6b8 100644 --- a/static/bitcoin-dev/Jan_2014/combined_Tor-SPV.xml +++ b/static/bitcoin-dev/Jan_2014/combined_Tor-SPV.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Tor / SPV - 2023-08-01T07:16:05.112231+00:00 + 2025-10-11T22:03:45.498649+00:00 + python-feedgen Mike Hearn 2014-01-16 10:25:18+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Tor / SPV - 2023-08-01T07:16:05.112231+00:00 + 2025-10-11T22:03:45.498819+00:00 - The discussion revolves around using hidden services as a more secure method of authentication and encryption for SPV wallets. One suggestion is to connect SPV nodes through Tor, which would preserve privacy and reduce the risk of MITM attacks. However, concerns are raised about the potential slowdown of the Bitcoin network if all nodes communicate over Tor. The use of anti-sybil techniques and hidden service addresses following a certain pattern are proposed to address these issues.In January 2014, different methods for identifying nodes in SPV wallets were discussed. These included querying hardcoded seed nodes, DNS lookups, and selecting nodes based on clearnet anti-sybil heuristics. Connecting to IP addresses using Tor was also suggested as a way to enhance privacy and security. The idea of nodes giving both public and private IPs to peers was questioned, and alternatives such as clearnet nodes informing about their own hidden service IDs were proposed.The goal of using Tor hidden services is not to hide P2P nodes but to provide authentication and encryption. It is suggested that 6-hop hidden service circuits may not be necessary for most nodes, and a 3-hop circuit would suffice. The use of Tor may result in network slowdowns and could potentially decrease transactions per second on the Bitcoin network. IPv4-based anti-sybil heuristics and proof-of-stake schemes on Tor are also discussed as possible improvements.A clever hack has been implemented to map Tor keys to reserved IPv6 space, allowing for hidden service addresses that can be included in addr packets. Concerns are raised about malicious nodes generating multiple hidden service keys, and suggestions are made to avoid this issue, such as clearnet nodes informing about their own hidden service IDs. The proposal to introduce a new P2P protocol command "tor?" with a service flag is made to include IPv6-ified hidden service addresses in addr messages. This would eliminate the need for nodes to give both public and private IPs to peers.The use of SSL on P2P connections to prevent passive wiretapping and sybil attacks is also discussed. While OpenSSL is considered risky, a pure Java implementation of the Tor protocol called Orchid is discovered, which could enable wallets like MultiBit and Hive to utilize Tor by default. However, the limitations of SPV wallets in verifying unconfirmed transactions and relying on peer counts are highlighted. A proposal is made to upgrade the P2P protocol with a new service flag and tor? message to identify nodes on the clearnet, allowing SPV wallets to bypass Tor if necessary. The idea is deemed implementable and secure, as Tor runs as a separate process that can be sandboxed. 2014-01-16T10:25:18+00:00 + The discussion revolves around using hidden services as a more secure method of authentication and encryption for SPV wallets. One suggestion is to connect SPV nodes through Tor, which would preserve privacy and reduce the risk of MITM attacks. However, concerns are raised about the potential slowdown of the Bitcoin network if all nodes communicate over Tor. The use of anti-sybil techniques and hidden service addresses following a certain pattern are proposed to address these issues.In January 2014, different methods for identifying nodes in SPV wallets were discussed. These included querying hardcoded seed nodes, DNS lookups, and selecting nodes based on clearnet anti-sybil heuristics. Connecting to IP addresses using Tor was also suggested as a way to enhance privacy and security. The idea of nodes giving both public and private IPs to peers was questioned, and alternatives such as clearnet nodes informing about their own hidden service IDs were proposed.The goal of using Tor hidden services is not to hide P2P nodes but to provide authentication and encryption. It is suggested that 6-hop hidden service circuits may not be necessary for most nodes, and a 3-hop circuit would suffice. The use of Tor may result in network slowdowns and could potentially decrease transactions per second on the Bitcoin network. IPv4-based anti-sybil heuristics and proof-of-stake schemes on Tor are also discussed as possible improvements.A clever hack has been implemented to map Tor keys to reserved IPv6 space, allowing for hidden service addresses that can be included in addr packets. Concerns are raised about malicious nodes generating multiple hidden service keys, and suggestions are made to avoid this issue, such as clearnet nodes informing about their own hidden service IDs. The proposal to introduce a new P2P protocol command "tor?" with a service flag is made to include IPv6-ified hidden service addresses in addr messages. This would eliminate the need for nodes to give both public and private IPs to peers.The use of SSL on P2P connections to prevent passive wiretapping and sybil attacks is also discussed. While OpenSSL is considered risky, a pure Java implementation of the Tor protocol called Orchid is discovered, which could enable wallets like MultiBit and Hive to utilize Tor by default. However, the limitations of SPV wallets in verifying unconfirmed transactions and relying on peer counts are highlighted. A proposal is made to upgrade the P2P protocol with a new service flag and tor? message to identify nodes on the clearnet, allowing SPV wallets to bypass Tor if necessary. The idea is deemed implementable and secure, as Tor runs as a separate process that can be sandboxed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2014/combined_unlinakble-static-address-spv-privacy-Re-Stealth-Addresses-.xml b/static/bitcoin-dev/Jan_2014/combined_unlinakble-static-address-spv-privacy-Re-Stealth-Addresses-.xml index 0ddca3173d..476e947399 100644 --- a/static/bitcoin-dev/Jan_2014/combined_unlinakble-static-address-spv-privacy-Re-Stealth-Addresses-.xml +++ b/static/bitcoin-dev/Jan_2014/combined_unlinakble-static-address-spv-privacy-Re-Stealth-Addresses-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - unlinakble static address? & spv-privacy (Re: Stealth Addresses) - 2023-08-01T07:16:36.140402+00:00 + 2025-10-11T22:03:41.253791+00:00 + python-feedgen Peter Todd 2014-01-24 09:17:33+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - unlinakble static address? & spv-privacy (Re: Stealth Addresses) - 2023-08-01T07:16:36.140402+00:00 + 2025-10-11T22:03:41.253935+00:00 - In a discussion about the implementation of reusable payment addresses on the blockchain, concerns were raised regarding the length indicator of the payee's address. It was suggested that the address should have a 2-byte prefix and a 1-byte number of bits representing the fixed number of bits of the prefix. This way, the payer would know how much of the address should be taken verbatim and the rest would be replaced with random data. If the number of bits is zero, a random 2-byte prefix would be put into the OP_RETURN. However, there is a concern about broken implementations copying the prefix when the number of bits is zero, potentially identifying the payee. To prevent this, the number of bits in the address was suggested to be optional.Troy Benjegerdes raised concerns about mechanisms to keep coin flows private and who would bear the cost. Peter Todd responded that the exact encoding is still undetermined, but other encodings proposed are similar or even smaller in size than a standard transaction. However, Todd did not address Benjegerdes' concerns about cost and centralization.The sender pays the fees for putting extra data into the blockchain, which aims to improve privacy for static addresses. However, this mechanism may not be used as much due to increased fees. The concern was raised about complicated mechanisms for privacy and who pays for them. It was suggested that if Bitcoin's goal is to socialize the cost of privacy, launching a 'transparencycoin' with explicit address reuse could be an alternative. This would be more distributed and have lower transaction costs for those who prioritize cheap or free services over privacy.The author of the context believes that privacy in Bitcoin is a social engineering problem. They emphasize the importance of allowing users to choose how much privacy they want to trade for computation and bandwidth. The author predicts that network flow analysis incorporating privacy features could undermine the privacy benefits of CoinJoin. They question who is marketing privacy and how to validate privacy providers, as there may be scamprivacy providers driving down the market price of privacy. The author estimates that most users do not care about abstract privacy ideals but prioritized working payments and convenience.In an email conversation between Jeremy Spilman and Adam Back, the use of a second pubKey to scan for transactions without keeping private keys in memory was discussed. Back raised concerns about the cost of DH calculation per transaction, especially for full nodes. He also noted that multiple reusable addresses would require separate calculations, potentially creating a high load on centralized services. Back further explained that using a second pubKey with high elimination probability could affect everyone's privacy. To address this, a version of the prefix computed via brute-force was proposed. Spilman argued that hash grinding of the prefix should only be used if that's how transactions are being indexed, as it does not add privacy but adds unnecessary work.In another email exchange, Jeremy Spilman discussed the difficulty of choosing the number of bits in a prefix for Bitcoin transactions. He suggested that 0 or 1 bit may be sufficient for a single user node, while a central service may require 4 or 5 bits for scalability. However, the cost of each reusable address is only a small percentage of the full node cost, making computation less of an issue except for large centralized services. Spilman emphasized that the encoded prefix should always be of constant length in all reusable addresses, and if a particular prefix is not desired, random data can be chosen for the remaining space.The privacy properties of Simplified Payment Verification (SPV) nodes were discussed in an email thread among Bitcoin developers. While full-node use of SPV has unlinkable static addresses, it poses problems for SPV nodes in finding payments directly. A workaround involving a second address and DH calculation per transaction was proposed, but it is costly for full nodes. Unlinkable static addresses were seen as having nice properties for full-node use and could help address the issue of address reuse. There was some debate over what to call these addresses, with "static address" suggested as a suitable name. The use of static addresses could also help prevent paying the wrong person by allowing users to verify ownership. Payment protocols were mentioned as another option for certifying addresses, but some argued for simpler address-level verification.Overall, there are ongoing discussions about the implementation of reusable payment addresses, concerns about privacy mechanisms and their cost, and the use of unlinkable static addresses for improved privacy in Bitcoin transactions. 2014-01-24T09:17:33+00:00 + In a discussion about the implementation of reusable payment addresses on the blockchain, concerns were raised regarding the length indicator of the payee's address. It was suggested that the address should have a 2-byte prefix and a 1-byte number of bits representing the fixed number of bits of the prefix. This way, the payer would know how much of the address should be taken verbatim and the rest would be replaced with random data. If the number of bits is zero, a random 2-byte prefix would be put into the OP_RETURN. However, there is a concern about broken implementations copying the prefix when the number of bits is zero, potentially identifying the payee. To prevent this, the number of bits in the address was suggested to be optional.Troy Benjegerdes raised concerns about mechanisms to keep coin flows private and who would bear the cost. Peter Todd responded that the exact encoding is still undetermined, but other encodings proposed are similar or even smaller in size than a standard transaction. However, Todd did not address Benjegerdes' concerns about cost and centralization.The sender pays the fees for putting extra data into the blockchain, which aims to improve privacy for static addresses. However, this mechanism may not be used as much due to increased fees. The concern was raised about complicated mechanisms for privacy and who pays for them. It was suggested that if Bitcoin's goal is to socialize the cost of privacy, launching a 'transparencycoin' with explicit address reuse could be an alternative. This would be more distributed and have lower transaction costs for those who prioritize cheap or free services over privacy.The author of the context believes that privacy in Bitcoin is a social engineering problem. They emphasize the importance of allowing users to choose how much privacy they want to trade for computation and bandwidth. The author predicts that network flow analysis incorporating privacy features could undermine the privacy benefits of CoinJoin. They question who is marketing privacy and how to validate privacy providers, as there may be scamprivacy providers driving down the market price of privacy. The author estimates that most users do not care about abstract privacy ideals but prioritized working payments and convenience.In an email conversation between Jeremy Spilman and Adam Back, the use of a second pubKey to scan for transactions without keeping private keys in memory was discussed. Back raised concerns about the cost of DH calculation per transaction, especially for full nodes. He also noted that multiple reusable addresses would require separate calculations, potentially creating a high load on centralized services. Back further explained that using a second pubKey with high elimination probability could affect everyone's privacy. To address this, a version of the prefix computed via brute-force was proposed. Spilman argued that hash grinding of the prefix should only be used if that's how transactions are being indexed, as it does not add privacy but adds unnecessary work.In another email exchange, Jeremy Spilman discussed the difficulty of choosing the number of bits in a prefix for Bitcoin transactions. He suggested that 0 or 1 bit may be sufficient for a single user node, while a central service may require 4 or 5 bits for scalability. However, the cost of each reusable address is only a small percentage of the full node cost, making computation less of an issue except for large centralized services. Spilman emphasized that the encoded prefix should always be of constant length in all reusable addresses, and if a particular prefix is not desired, random data can be chosen for the remaining space.The privacy properties of Simplified Payment Verification (SPV) nodes were discussed in an email thread among Bitcoin developers. While full-node use of SPV has unlinkable static addresses, it poses problems for SPV nodes in finding payments directly. A workaround involving a second address and DH calculation per transaction was proposed, but it is costly for full nodes. Unlinkable static addresses were seen as having nice properties for full-node use and could help address the issue of address reuse. There was some debate over what to call these addresses, with "static address" suggested as a suitable name. The use of static addresses could also help prevent paying the wrong person by allowing users to verify ownership. Payment protocols were mentioned as another option for certifying addresses, but some argued for simpler address-level verification.Overall, there are ongoing discussions about the implementation of reusable payment addresses, concerns about privacy mechanisms and their cost, and the use of unlinkable static addresses for improved privacy in Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_-softfork-proposal-Strict-DER-signatures.xml b/static/bitcoin-dev/Jan_2015/combined_-softfork-proposal-Strict-DER-signatures.xml index d5293ae352..1f2927d441 100644 --- a/static/bitcoin-dev/Jan_2015/combined_-softfork-proposal-Strict-DER-signatures.xml +++ b/static/bitcoin-dev/Jan_2015/combined_-softfork-proposal-Strict-DER-signatures.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [softfork proposal] Strict DER signatures - 2023-08-01T11:12:49.211700+00:00 + 2025-10-11T21:39:48.395642+00:00 + python-feedgen Pieter Wuille 2015-02-06 21:38:40+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - [softfork proposal] Strict DER signatures - 2023-08-01T11:12:49.211700+00:00 + 2025-10-11T21:39:48.395854+00:00 - In January 2015, Gregory Maxwell requested a BIP number and Pieter Wuille suggested BIP0066 as the response. There are currently four implementations of BIP0066 available, including one for the master and 0.10.0 versions, which have been merged and can be found on GitHub. The implementations for versions 0.9.4 and 0.8.6 can also be located on GitHub. It is important to note that the 0.8 and 0.9 versions have reduced test code due to reliance on new test framework codes in later versions, but the implementation code remains the same.On February 3, 2015, Pieter Wuille proposed a one-line change to BIP66's DERSIG that would softfork. However, he later retracted the proposal after Suhar Daftuas pointed out some uncovered edge-cases. The goal was to separate signature validation and parsing, and to avoid requiring a third return value for signature checking. A cleaner solution was proposed, which only allows an empty byte vector as an invalid signature, aligning signature validity with decoding and simplifying the implementation.In the same email thread on February 3, Gavin Andresen suggested including a change for DERSIG with other changes for version 0.10. Pieter Wuille acknowledged that it may be late for version 0.10, but releasing without the change would require additional work in future releases. The change was just two lines of code and Gavin Andresen agreed with the proposal.Wladimir suggested adding a patch to make non-standard transactions invalid in Bitcoin's 0.10 version. Pieter Wuille proposed a simpler alternative by modifying BIP66's DERSIG with a one-line change that would softfork. Implementing this change before the release of version 0.10 would prevent the need for a second softfork. The change was considered to be just two lines of code.A discussion was held regarding the implementation of a patch to make non-standard transactions invalid in BIP66. It was suggested to add the patch to BIP66's DERSIG as a simple one-line change that would softfork. However, it was deemed late for version 0.10 and hoped to tag rc4 soon. The discussion also included a sponsor from Intel and their Go Parallel Website, which offers resources for parallel software development.Pieter Wuille proposed a softfork to make non-DER signatures illegal. The draft BIP text for this proposal can be found on GitHub. Positive feedback was received from several implementers, including Amir Taak. One concern raised was the possibility of an unlocked spend with an invalidly encoded signature. In those cases, the signature could be mutated to get it mined, but it would need to already pass IsStandard rules. This issue does not cover cases where there is a chain of transactions after the unlocked transaction.In January 2015, Pieter Wuille proposed a softfork to make non-DER signatures illegal. Non-DER signatures have been non-standard since v0.8.0. Wuille provided a draft BIP text on GitHub for the proposal. He requested a BIP number for the proposal.In the email correspondence, Pieter Wuille responded to Zooko Wilcox-OHearn regarding updates made to the BIP text and code for handling invalid signatures in Bitcoin transactions. The changes were synced up with the repository code, and comments were added to the BIP text. There are still multiple ways to encode a correctly encoded but invalid signature, including the 0-length string. Pieter confirms that all branches of the new IsDERSignature() function have been tested and extra test cases have been added. However, there are still TODOs remaining for testing upgrade behavior. Lastly, Pieter fixes a missing comment in the code.In a discussion on January 25, 2015, Matt Whitlock suggested a change to the C++ code used in Bitcoin Core releases. He proposed changing the parameters of functions to be more in line with the spirit of C++. Pieter agreed with the suggestion but noted that one of the motivations for including C++ code was to match the exact code used in previous Bitcoin Core releases.On January 21, 2015, Rusty Russell sent an email addressing the issue of relying on OpenSSL for consensus rules as part of BIP 62. The plan to get rid of this risk was postponed due to unforeseen complexities. However, recent events have made it clear that a fundamental solution is necessary. Russell provided a C++ code snippet to validate signature encoding and several test cases to ensure its validity. Pieter Wuille, a Bitcoin Core developer, has proposed an improvement to the Bitcoin protocol that would replace OpenSSL with libsecp256k1. The proposal aims to provide a more fundamental solution to the problem and involves removing the dependency on OpenSSL and replacing it with the lib 2015-02-06T21:38:40+00:00 + In January 2015, Gregory Maxwell requested a BIP number and Pieter Wuille suggested BIP0066 as the response. There are currently four implementations of BIP0066 available, including one for the master and 0.10.0 versions, which have been merged and can be found on GitHub. The implementations for versions 0.9.4 and 0.8.6 can also be located on GitHub. It is important to note that the 0.8 and 0.9 versions have reduced test code due to reliance on new test framework codes in later versions, but the implementation code remains the same.On February 3, 2015, Pieter Wuille proposed a one-line change to BIP66's DERSIG that would softfork. However, he later retracted the proposal after Suhar Daftuas pointed out some uncovered edge-cases. The goal was to separate signature validation and parsing, and to avoid requiring a third return value for signature checking. A cleaner solution was proposed, which only allows an empty byte vector as an invalid signature, aligning signature validity with decoding and simplifying the implementation.In the same email thread on February 3, Gavin Andresen suggested including a change for DERSIG with other changes for version 0.10. Pieter Wuille acknowledged that it may be late for version 0.10, but releasing without the change would require additional work in future releases. The change was just two lines of code and Gavin Andresen agreed with the proposal.Wladimir suggested adding a patch to make non-standard transactions invalid in Bitcoin's 0.10 version. Pieter Wuille proposed a simpler alternative by modifying BIP66's DERSIG with a one-line change that would softfork. Implementing this change before the release of version 0.10 would prevent the need for a second softfork. The change was considered to be just two lines of code.A discussion was held regarding the implementation of a patch to make non-standard transactions invalid in BIP66. It was suggested to add the patch to BIP66's DERSIG as a simple one-line change that would softfork. However, it was deemed late for version 0.10 and hoped to tag rc4 soon. The discussion also included a sponsor from Intel and their Go Parallel Website, which offers resources for parallel software development.Pieter Wuille proposed a softfork to make non-DER signatures illegal. The draft BIP text for this proposal can be found on GitHub. Positive feedback was received from several implementers, including Amir Taak. One concern raised was the possibility of an unlocked spend with an invalidly encoded signature. In those cases, the signature could be mutated to get it mined, but it would need to already pass IsStandard rules. This issue does not cover cases where there is a chain of transactions after the unlocked transaction.In January 2015, Pieter Wuille proposed a softfork to make non-DER signatures illegal. Non-DER signatures have been non-standard since v0.8.0. Wuille provided a draft BIP text on GitHub for the proposal. He requested a BIP number for the proposal.In the email correspondence, Pieter Wuille responded to Zooko Wilcox-OHearn regarding updates made to the BIP text and code for handling invalid signatures in Bitcoin transactions. The changes were synced up with the repository code, and comments were added to the BIP text. There are still multiple ways to encode a correctly encoded but invalid signature, including the 0-length string. Pieter confirms that all branches of the new IsDERSignature() function have been tested and extra test cases have been added. However, there are still TODOs remaining for testing upgrade behavior. Lastly, Pieter fixes a missing comment in the code.In a discussion on January 25, 2015, Matt Whitlock suggested a change to the C++ code used in Bitcoin Core releases. He proposed changing the parameters of functions to be more in line with the spirit of C++. Pieter agreed with the suggestion but noted that one of the motivations for including C++ code was to match the exact code used in previous Bitcoin Core releases.On January 21, 2015, Rusty Russell sent an email addressing the issue of relying on OpenSSL for consensus rules as part of BIP 62. The plan to get rid of this risk was postponed due to unforeseen complexities. However, recent events have made it clear that a fundamental solution is necessary. Russell provided a C++ code snippet to validate signature encoding and several test cases to ensure its validity. Pieter Wuille, a Bitcoin Core developer, has proposed an improvement to the Bitcoin protocol that would replace OpenSSL with libsecp256k1. The proposal aims to provide a more fundamental solution to the problem and involves removing the dependency on OpenSSL and replacing it with the lib - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_A-look-back-and-a-look-forward.xml b/static/bitcoin-dev/Jan_2015/combined_A-look-back-and-a-look-forward.xml index 45ff80d2ea..4364259007 100644 --- a/static/bitcoin-dev/Jan_2015/combined_A-look-back-and-a-look-forward.xml +++ b/static/bitcoin-dev/Jan_2015/combined_A-look-back-and-a-look-forward.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A look back and a look forward - 2023-08-01T11:04:58.349196+00:00 + 2025-10-11T21:39:42.020852+00:00 + python-feedgen 21E14 2015-01-09 19:36:18+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - A look back and a look forward - 2023-08-01T11:04:58.349196+00:00 + 2025-10-11T21:39:42.021027+00:00 - The author of a mailing list suggests the need for an optional identity layer to address the institutionalization of Bitcoin and enable the flow of billions of dollars through it. This layer, modeled after the Internet, could potentially facilitate the migration of the legacy financial system to a more regulated sidechain with a stronger identity layer. Market forces should regulate the nexus between custodial and non-custodial address spaces, similar to current rules governing coin issuance.To defend private keys adequately for large sums of money, the development of hardware, such as minimalist secure hardware with additional policies on top, is recommended. These policies could include refusing to sign transactions without proof of identity for the target address. Recent events, like the Bitstamp hack, highlight the urgency to move forward with new technologies for securing private keys.However, while an optional identity layer may help solve security issues faced by Bitcoin exchanges, it remains unclear how it would address incidents like the Bitstamp hack where KYC (Know Your Customer) procedures were already in place. Requiring all transactions to have attached identity information would not be feasible for Bitcoin. In the long term, the proposal of minimalist secure hardware with additional policies could provide adequate defense for private keys. The lack of such hardware currently exists due to implementation lagging behind ideas, but the Bitstamp event may accelerate its development.Alex Daley has raised concerns about the potential threat of taking Bitcoin transactions backwards, using the example of Target being hacked and losing bitcoin addresses instead of credit card details. The Winklevoss Bitcoin Trust SEC filing also highlights the risk of loss, damage, or theft of bitcoins as they are appealing targets for hackers and malware distributors. The optional identity layer, modeled after the Internet, could potentially offer a solution to this issue by providing a "killer app." While collaboration and time would be required to create this Bitcoin Identity (BCI) layer, TNABC (The North American Bitcoin Conference) could serve as a platform for such collaboration. 2015-01-09T19:36:18+00:00 + The author of a mailing list suggests the need for an optional identity layer to address the institutionalization of Bitcoin and enable the flow of billions of dollars through it. This layer, modeled after the Internet, could potentially facilitate the migration of the legacy financial system to a more regulated sidechain with a stronger identity layer. Market forces should regulate the nexus between custodial and non-custodial address spaces, similar to current rules governing coin issuance.To defend private keys adequately for large sums of money, the development of hardware, such as minimalist secure hardware with additional policies on top, is recommended. These policies could include refusing to sign transactions without proof of identity for the target address. Recent events, like the Bitstamp hack, highlight the urgency to move forward with new technologies for securing private keys.However, while an optional identity layer may help solve security issues faced by Bitcoin exchanges, it remains unclear how it would address incidents like the Bitstamp hack where KYC (Know Your Customer) procedures were already in place. Requiring all transactions to have attached identity information would not be feasible for Bitcoin. In the long term, the proposal of minimalist secure hardware with additional policies could provide adequate defense for private keys. The lack of such hardware currently exists due to implementation lagging behind ideas, but the Bitstamp event may accelerate its development.Alex Daley has raised concerns about the potential threat of taking Bitcoin transactions backwards, using the example of Target being hacked and losing bitcoin addresses instead of credit card details. The Winklevoss Bitcoin Trust SEC filing also highlights the risk of loss, damage, or theft of bitcoins as they are appealing targets for hackers and malware distributors. The optional identity layer, modeled after the Internet, could potentially offer a solution to this issue by providing a "killer app." While collaboration and time would be required to create this Bitcoin Identity (BCI) layer, TNABC (The North American Bitcoin Conference) could serve as a platform for such collaboration. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_BIP-Voluntary-deposit-bonds.xml b/static/bitcoin-dev/Jan_2015/combined_BIP-Voluntary-deposit-bonds.xml index 20954bbdf4..869d85a3e9 100644 --- a/static/bitcoin-dev/Jan_2015/combined_BIP-Voluntary-deposit-bonds.xml +++ b/static/bitcoin-dev/Jan_2015/combined_BIP-Voluntary-deposit-bonds.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: Voluntary deposit bonds - 2023-08-01T11:04:11.867695+00:00 + 2025-10-11T21:40:03.281229+00:00 + python-feedgen Peter Todd 2015-01-03 03:48:29+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - BIP: Voluntary deposit bonds - 2023-08-01T11:04:11.867695+00:00 + 2025-10-11T21:40:03.281447+00:00 - Sergio Lerner, a Bitcoin developer, has proposed a modification to the code that would allow miners to add real inputs to the coinbase transaction, instead of just pseudo-inputs. This change would enable miners to voluntarily lock funds. Lerner believes that this modification is necessary to secure the blockchain in the future when the subsidy is lowered. He argues that increasing the number of confirmation blocks could make Bitcoin less competitive with other payment networks. However, there are concerns about this proposal. Peter Todd, another Bitcoin developer, worries that it could change incentives and make it easier for individuals to pay miners to mine specific blocks rather than transactions. There are also doubts about the PowPay micropayments scheme, which may incentivize mining pools to grow larger.Gregory Maxwell and Stephen have suggested alternative ways to pay specific miners upon solving a block without risking paying other miners through pay-to-fee. Gregory suggests using Gavin's OP_EVAL, but acknowledges that it would require additional changes to overlay functionality. Stephen proposes a solution involving outputs in the coinbase transaction with nValue == 0, and applying the COINBASE_MATURITY rule only to spending coinbase outputs with non-zero value. However, this solution would still require a hard fork.In a conversation on the Bitcoin-development mailing list, Sergio expresses concern about the complexity of Bitcoin and argues that it needs to be simple for new programmers to understand and contribute to the project. He suggests that even P2SH is an abuse of the virtual machine (VM) and that Gavin's OP_EVAL should have been chosen instead. Others clarify that there is no abuse occurring and that Sergio's proposal would require an additional change to overlay functionality, which may be considered "ugly."Sergio Lerner's idea of allowing miners to lock funds by adding additional inputs to the coinbase transaction has been proposed since 2011 but hasn't been a priority until now. The motivation behind the proposal is to address potential security problems in the future as the subsidy is lowered. However, there are concerns about increasing the complexity of Bitcoin. Some suggest that a hard fork now could allow for a later implementation of a soft fork involving deposit bonds, proof-of-stake, and penalization of double-mining.Justus Ranvier explains in a discussion with Jorge Timón that allowing miners to pay themselves by adding inputs to the generation transaction is the most natural way for their customers to pay them. This method is more secure than pay-to-fee transactions because the fees cannot be claimed by another miner if the block is orphaned.In an email conversation between Justus Ranvier and Mike Hearn, they discuss the difference between adding inputs to a coinbase and having pay-to-fee transactions in a block. Ranvier points out that pay-to-fee transactions can be "stolen" by another block, whereas inputs to a generation transaction cannot be poached. This difference allows for certain services that can't be safely achieved with pay-to-fee transactions, although it's unclear what these services are.There is ongoing debate and exploration around how to optimize blockchain transactions. The proposal to add inputs to the coinbase transaction aims to improve transaction processing efficiency or reduce fees. However, it is not clear how this differs from pay-to-fee transactions, which also involve direct payment to miners. The discussion on coinbase inputs and pay-to-fee transactions is likely part of a larger conversation on improving the functionality and scalability of blockchain systems.A proposal has been made to allow miners to voluntarily lock funds by adding additional inputs to the coinbase transaction. This would require a hard fork but could potentially be included in the next scheduled hard fork, such as when the block size is increased. The code modifications needed for this proposal are minimal and involve removing code rather than adding any. It is argued that this change would not change incentives or security until a soft fork is implemented in the future. 2015-01-03T03:48:29+00:00 + Sergio Lerner, a Bitcoin developer, has proposed a modification to the code that would allow miners to add real inputs to the coinbase transaction, instead of just pseudo-inputs. This change would enable miners to voluntarily lock funds. Lerner believes that this modification is necessary to secure the blockchain in the future when the subsidy is lowered. He argues that increasing the number of confirmation blocks could make Bitcoin less competitive with other payment networks. However, there are concerns about this proposal. Peter Todd, another Bitcoin developer, worries that it could change incentives and make it easier for individuals to pay miners to mine specific blocks rather than transactions. There are also doubts about the PowPay micropayments scheme, which may incentivize mining pools to grow larger.Gregory Maxwell and Stephen have suggested alternative ways to pay specific miners upon solving a block without risking paying other miners through pay-to-fee. Gregory suggests using Gavin's OP_EVAL, but acknowledges that it would require additional changes to overlay functionality. Stephen proposes a solution involving outputs in the coinbase transaction with nValue == 0, and applying the COINBASE_MATURITY rule only to spending coinbase outputs with non-zero value. However, this solution would still require a hard fork.In a conversation on the Bitcoin-development mailing list, Sergio expresses concern about the complexity of Bitcoin and argues that it needs to be simple for new programmers to understand and contribute to the project. He suggests that even P2SH is an abuse of the virtual machine (VM) and that Gavin's OP_EVAL should have been chosen instead. Others clarify that there is no abuse occurring and that Sergio's proposal would require an additional change to overlay functionality, which may be considered "ugly."Sergio Lerner's idea of allowing miners to lock funds by adding additional inputs to the coinbase transaction has been proposed since 2011 but hasn't been a priority until now. The motivation behind the proposal is to address potential security problems in the future as the subsidy is lowered. However, there are concerns about increasing the complexity of Bitcoin. Some suggest that a hard fork now could allow for a later implementation of a soft fork involving deposit bonds, proof-of-stake, and penalization of double-mining.Justus Ranvier explains in a discussion with Jorge Timón that allowing miners to pay themselves by adding inputs to the generation transaction is the most natural way for their customers to pay them. This method is more secure than pay-to-fee transactions because the fees cannot be claimed by another miner if the block is orphaned.In an email conversation between Justus Ranvier and Mike Hearn, they discuss the difference between adding inputs to a coinbase and having pay-to-fee transactions in a block. Ranvier points out that pay-to-fee transactions can be "stolen" by another block, whereas inputs to a generation transaction cannot be poached. This difference allows for certain services that can't be safely achieved with pay-to-fee transactions, although it's unclear what these services are.There is ongoing debate and exploration around how to optimize blockchain transactions. The proposal to add inputs to the coinbase transaction aims to improve transaction processing efficiency or reduce fees. However, it is not clear how this differs from pay-to-fee transactions, which also involve direct payment to miners. The discussion on coinbase inputs and pay-to-fee transactions is likely part of a larger conversation on improving the functionality and scalability of blockchain systems.A proposal has been made to allow miners to voluntarily lock funds by adding additional inputs to the coinbase transaction. This would require a hard fork but could potentially be included in the next scheduled hard fork, such as when the block size is increased. The code modifications needed for this proposal are minimal and involve removing code rather than adding any. It is argued that this change would not change incentives or security until a soft fork is implemented in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_BIP70-why-Google-Protocol-Buffers-for-encoding-.xml b/static/bitcoin-dev/Jan_2015/combined_BIP70-why-Google-Protocol-Buffers-for-encoding-.xml index 7463032ed3..59c63646bd 100644 --- a/static/bitcoin-dev/Jan_2015/combined_BIP70-why-Google-Protocol-Buffers-for-encoding-.xml +++ b/static/bitcoin-dev/Jan_2015/combined_BIP70-why-Google-Protocol-Buffers-for-encoding-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70: why Google Protocol Buffers for encoding? - 2023-08-01T11:09:13.242345+00:00 + 2025-10-11T21:39:27.139447+00:00 + python-feedgen Jorge Timón 2015-03-24 12:08:03+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - BIP70: why Google Protocol Buffers for encoding? - 2023-08-01T11:09:13.242345+00:00 + 2025-10-11T21:39:27.139658+00:00 - The Bitcoin-development mailing list discusses the idea of using the hash of the genesis block as the chain ID. One member argues that forking bitcoins and bitcoinsB with the same owners doesn't make sense and a new currency warrants defining a new chain. However, this is not a good reason to not adopt a hash of the genesis block as the chain ID. Another member raises concerns about interpreting messages on the wrong chain if there are two forked chains with different communities. The use of a central registry is also discussed as potentially harmful.A unique approach has been adopted to replace the network identifier with the genesis block hash. This replacement ensures compatibility with Bitcoin Core and altcoins without requiring a central registry. However, there is a possibility that interpreting messages on the wrong chain may still occur if there are two forked chains with different communities.A critical vulnerability in BlackPhone has been fixed, which allowed hackers to run malicious code on the handsets. Attackers only needed a phone number to compromise the devices via the Silent Text application. The vulnerability occurred during the deserialization of JSON objects and was a type confusion vulnerability. This flaw could allow an attacker to overwrite a pointer in memory. The use of C++/Java/Python protocol buffer implementations by Google for internal inter-server communication is also mentioned. Any exploit in these implementations could bypass their entire internal security system.JSON has been known to generate bugs due to the lack of type marshalling and input validation. Protobufs and msgpack have addressed this issue by including type support and input validation in their designs. Some developers argue that creating a JSON-to-schema marshall is not worthwhile since there are only three types - bytes, int, and string. They prefer coding the JSON wrapper classes by hand. Using third-party services to convert data to JSON has also been criticized as an unnecessary and high-effort solution.The conversation revolves around the implementation of BIP70, a payment protocol for Bitcoin. One person suggests using JSON+HTTPS instead of BIP70, as it would be easier and sufficient for today's use case. Another person argues that BIP70 was designed to support hardware wallets by keeping the code small. Embedding certificates in BIP70 requests allows them to be verifiable by third parties. The conversation touches on the challenges of targeting WinRT and other platforms with a single codebase, as well as the pros and cons of bundling a custom root store.The discussion is about the limitations of BIP70 and whether to allow both serializations or keep it as is. One of the goals of BIP70 was to support hardware wallets, which requires keeping the code small. Implementing JSON and HTTPS would increase cost, complexity, and decrease security. Embedding certificates in BIP70 requests makes them verifiable by third parties, providing a form of digital receipt. The conversation also discusses the challenges of implementing BIP70 on different platforms and the pros and cons of bundling a custom root store.The conversation between Mike Hearn and an unknown person discusses the limitations of BIP70 as a client-side technology. Using JSON and HTTPS is suggested as an alternative, but it would increase cost, complexity, and decrease security. Embedding certificates in BIP70 requests allows them to be verifiable by third parties and provides a form of digital receipt. The conversation also highlights the challenges of targeting different platforms with a single codebase.The burden of certificate verification in BIP70 is discussed. One person argues that using JSON and HTTPS would be easier for developers, while another person defends the use of certificates in BIP70 as necessary for verifiability by third parties. The conversation also touches on the difficulty of implementing BIP70 on certain platforms and the pros and cons of bundling a custom root store.The discussion revolves around the use of JSON and schema in BIP70. It is argued that for the number of fields in the spec, having a JSON to schema is not worthwhile. Some developers prefer coding the JSON wrapper classes by hand. The conversation also discusses the benefits of using cross-platform libraries for protobuf and the challenges of dealing with X509 certificates.In a conversation on January 28, 2015, using OS root stores for certificates is discussed. It is suggested that taking a snapshot of the Mozilla/Apple/MSFT certificate stores and loading it into the app would be a better approach. However, concerns are raised about outdated certificates and the potential vulnerability of BitcoinJ-using software if a root CA gets breached and a certificate is revoked.The burden of certificate verification in BIP70 is placed on developers, but there is no obligation to use the OS root store. Taking a snapshot of the Mozilla/Apple/MSFT certificate stores is suggested as an alternative. However, this approach can lead to outdated certificates and potential vulnerabilities. Shipping an app with its own snapshot of certificates can make the system less secure and harder to audit.The burden of certificate verification in BIP70 is discussed. Using the OS root 2015-03-24T12:08:03+00:00 + The Bitcoin-development mailing list discusses the idea of using the hash of the genesis block as the chain ID. One member argues that forking bitcoins and bitcoinsB with the same owners doesn't make sense and a new currency warrants defining a new chain. However, this is not a good reason to not adopt a hash of the genesis block as the chain ID. Another member raises concerns about interpreting messages on the wrong chain if there are two forked chains with different communities. The use of a central registry is also discussed as potentially harmful.A unique approach has been adopted to replace the network identifier with the genesis block hash. This replacement ensures compatibility with Bitcoin Core and altcoins without requiring a central registry. However, there is a possibility that interpreting messages on the wrong chain may still occur if there are two forked chains with different communities.A critical vulnerability in BlackPhone has been fixed, which allowed hackers to run malicious code on the handsets. Attackers only needed a phone number to compromise the devices via the Silent Text application. The vulnerability occurred during the deserialization of JSON objects and was a type confusion vulnerability. This flaw could allow an attacker to overwrite a pointer in memory. The use of C++/Java/Python protocol buffer implementations by Google for internal inter-server communication is also mentioned. Any exploit in these implementations could bypass their entire internal security system.JSON has been known to generate bugs due to the lack of type marshalling and input validation. Protobufs and msgpack have addressed this issue by including type support and input validation in their designs. Some developers argue that creating a JSON-to-schema marshall is not worthwhile since there are only three types - bytes, int, and string. They prefer coding the JSON wrapper classes by hand. Using third-party services to convert data to JSON has also been criticized as an unnecessary and high-effort solution.The conversation revolves around the implementation of BIP70, a payment protocol for Bitcoin. One person suggests using JSON+HTTPS instead of BIP70, as it would be easier and sufficient for today's use case. Another person argues that BIP70 was designed to support hardware wallets by keeping the code small. Embedding certificates in BIP70 requests allows them to be verifiable by third parties. The conversation touches on the challenges of targeting WinRT and other platforms with a single codebase, as well as the pros and cons of bundling a custom root store.The discussion is about the limitations of BIP70 and whether to allow both serializations or keep it as is. One of the goals of BIP70 was to support hardware wallets, which requires keeping the code small. Implementing JSON and HTTPS would increase cost, complexity, and decrease security. Embedding certificates in BIP70 requests makes them verifiable by third parties, providing a form of digital receipt. The conversation also discusses the challenges of implementing BIP70 on different platforms and the pros and cons of bundling a custom root store.The conversation between Mike Hearn and an unknown person discusses the limitations of BIP70 as a client-side technology. Using JSON and HTTPS is suggested as an alternative, but it would increase cost, complexity, and decrease security. Embedding certificates in BIP70 requests allows them to be verifiable by third parties and provides a form of digital receipt. The conversation also highlights the challenges of targeting different platforms with a single codebase.The burden of certificate verification in BIP70 is discussed. One person argues that using JSON and HTTPS would be easier for developers, while another person defends the use of certificates in BIP70 as necessary for verifiability by third parties. The conversation also touches on the difficulty of implementing BIP70 on certain platforms and the pros and cons of bundling a custom root store.The discussion revolves around the use of JSON and schema in BIP70. It is argued that for the number of fields in the spec, having a JSON to schema is not worthwhile. Some developers prefer coding the JSON wrapper classes by hand. The conversation also discusses the benefits of using cross-platform libraries for protobuf and the challenges of dealing with X509 certificates.In a conversation on January 28, 2015, using OS root stores for certificates is discussed. It is suggested that taking a snapshot of the Mozilla/Apple/MSFT certificate stores and loading it into the app would be a better approach. However, concerns are raised about outdated certificates and the potential vulnerability of BitcoinJ-using software if a root CA gets breached and a certificate is revoked.The burden of certificate verification in BIP70 is placed on developers, but there is no obligation to use the OS root store. Taking a snapshot of the Mozilla/Apple/MSFT certificate stores is suggested as an alternative. However, this approach can lead to outdated certificates and potential vulnerabilities. Shipping an app with its own snapshot of certificates can make the system less secure and harder to audit.The burden of certificate verification in BIP70 is discussed. Using the OS root - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_Bi-directional-micropayment-channels-with-CHECKLOCKTIMEVERIFY.xml b/static/bitcoin-dev/Jan_2015/combined_Bi-directional-micropayment-channels-with-CHECKLOCKTIMEVERIFY.xml index 40d254f893..101ad890a5 100644 --- a/static/bitcoin-dev/Jan_2015/combined_Bi-directional-micropayment-channels-with-CHECKLOCKTIMEVERIFY.xml +++ b/static/bitcoin-dev/Jan_2015/combined_Bi-directional-micropayment-channels-with-CHECKLOCKTIMEVERIFY.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY - 2023-08-01T11:05:36.941216+00:00 + 2025-10-11T21:39:50.519797+00:00 + python-feedgen Peter Todd 2015-01-11 22:24:47+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY - 2023-08-01T11:05:36.941216+00:00 + 2025-10-11T21:39:50.519984+00:00 - In an email conversation, Nathan Cook asks for a concrete example of scriptPubKeys/transactions using an idea proposed by an unknown individual to make the review process easier. The proposal suggests having only one channel as a deposit saver instead of opening a second payment channel in the opposite direction. They provide a link to a CLTV-using micropayment channel demo on GitHub for reference material.The email also includes an apology for not providing feedback on a protocol related to payment tree and suggests forking the existing code in bitcoinj and extending it with new functionality if one wanted to implement it. The author mentions the original Satoshi design and agrees with Gregory's phrasing that Bitcoin will likely become multi-layered over time. The proposal from GreenAddress to be a well-known signer who is trusted to not double spend is mentioned. From a miner's perspective, there are multiple schemes where they are viable if cost(fraud) is less than reward(block).Another email conversation discusses the implications of developing bi-directional micropayment channels. The focus is on the concept of zakat, a system based on trust, which contrasts with the trustless nature of bitcoin. The message provides links to further information on zakat and a traditional philanthropic historic overview. Mike Hearn shares his thoughts on the original design documented at the bottom of a wiki page and how time-locked transactions can be broadcast across the network and replaced by broadcasting a new transaction with higher sequence numbers. He discusses how miners could pick any version under the 2-of-2 channel model but disagrees with Gregory's claim that people refuse to use protocols affected by malleability. The message also promotes the website Go Parallel aimed at parallel software development.In another email conversation, Mike Hearn discusses the issue of Bitcoin's safety and the potential for malicious miners to break the system. He argues that even a small percentage of malicious miners could cause significant damage to the network. Additionally, he points out that clients cannot enforce that all versions have the same fee attached. Hearn suggests that the ideal scenario would be absolute soundness in the rules, followed by cryptographic soundness, economic soundness, and honesty soundness. However, as it is impossible to make the entire system absolutely sound or cryptographically sound, users must navigate this risk stack. Hearn also notes that one man's integrity is another man's malice, and so a risk analysis has to import the clarity of judgment, morality, coerceability, personal values, etc. of everyone in the trust chain. In order to mitigate these risks, users of Bitcoin should behave in ways that cannot be harmed by a failure to follow the rules.The design for time-locked transactions using sequence numbers was intended to allow high frequency trading between parties but could be vulnerable to attacks. Broadcasted transactions with a lock time far in the future could fill up memory and use up CPU time and bandwidth. However, there is a concern that Bitcoin must still work even if miners are malicious and willing to break things to gain more money. In this scenario, there is nothing forcing miners to include the latest version in the block chain, they could pick any version. In the 2-of-2 channel model, both parties must sign and agree on the same fee attached. It is also argued that user-friendly apps that use refunds currently do not exist, so it is uncertain whether people would refuse to use them or not depending on the prevalence of attacks which is currently unknown.In an email conversation between Mike Hearn and an unknown recipient, Hearn discussed a limitation on most existing micropayment channel ideas, stating that payments can only flow in one direction. However, he noted that the original protocol as designed by Satoshi did not have this limitation, but it has evolved this way because of ad-hoc DoS fixes over time. Hearn suggested that eventually, a different approach to handling DoS attacks based on resource prioritization and scheduling will become needed or implemented, allowing the original design to be safely brought back to life. The unknown recipient disagreed with Hearn's understanding, stating that expecting replacement to work and be enforced is completely unsafe. They added that people refuse to use protocols that are broken by refund malleability.In a Bitcoin development mailing list, Mike Hearn stated that most micropayment channel ideas have a limitation of one-way payment flow. He further added that the original protocol as designed by Satoshi had no such limitation but has evolved over time due to ad-hoc DoS fixes. He mentioned that a different approach to handling DoS attacks based on resource prioritisation and scheduling will become necessary in the future and the original design could be safely brought back to life at that point. Jeff Garzik questioned Mike's reference to the "original design" without mentioning how it was different or better. The email also included information about the Go Parallel website which is a hub for all things parallel software development.The proposed micropayment channel idea introduces a reversible payment channel that allows payments to flow in both directions by 2015-01-11T22:24:47+00:00 + In an email conversation, Nathan Cook asks for a concrete example of scriptPubKeys/transactions using an idea proposed by an unknown individual to make the review process easier. The proposal suggests having only one channel as a deposit saver instead of opening a second payment channel in the opposite direction. They provide a link to a CLTV-using micropayment channel demo on GitHub for reference material.The email also includes an apology for not providing feedback on a protocol related to payment tree and suggests forking the existing code in bitcoinj and extending it with new functionality if one wanted to implement it. The author mentions the original Satoshi design and agrees with Gregory's phrasing that Bitcoin will likely become multi-layered over time. The proposal from GreenAddress to be a well-known signer who is trusted to not double spend is mentioned. From a miner's perspective, there are multiple schemes where they are viable if cost(fraud) is less than reward(block).Another email conversation discusses the implications of developing bi-directional micropayment channels. The focus is on the concept of zakat, a system based on trust, which contrasts with the trustless nature of bitcoin. The message provides links to further information on zakat and a traditional philanthropic historic overview. Mike Hearn shares his thoughts on the original design documented at the bottom of a wiki page and how time-locked transactions can be broadcast across the network and replaced by broadcasting a new transaction with higher sequence numbers. He discusses how miners could pick any version under the 2-of-2 channel model but disagrees with Gregory's claim that people refuse to use protocols affected by malleability. The message also promotes the website Go Parallel aimed at parallel software development.In another email conversation, Mike Hearn discusses the issue of Bitcoin's safety and the potential for malicious miners to break the system. He argues that even a small percentage of malicious miners could cause significant damage to the network. Additionally, he points out that clients cannot enforce that all versions have the same fee attached. Hearn suggests that the ideal scenario would be absolute soundness in the rules, followed by cryptographic soundness, economic soundness, and honesty soundness. However, as it is impossible to make the entire system absolutely sound or cryptographically sound, users must navigate this risk stack. Hearn also notes that one man's integrity is another man's malice, and so a risk analysis has to import the clarity of judgment, morality, coerceability, personal values, etc. of everyone in the trust chain. In order to mitigate these risks, users of Bitcoin should behave in ways that cannot be harmed by a failure to follow the rules.The design for time-locked transactions using sequence numbers was intended to allow high frequency trading between parties but could be vulnerable to attacks. Broadcasted transactions with a lock time far in the future could fill up memory and use up CPU time and bandwidth. However, there is a concern that Bitcoin must still work even if miners are malicious and willing to break things to gain more money. In this scenario, there is nothing forcing miners to include the latest version in the block chain, they could pick any version. In the 2-of-2 channel model, both parties must sign and agree on the same fee attached. It is also argued that user-friendly apps that use refunds currently do not exist, so it is uncertain whether people would refuse to use them or not depending on the prevalence of attacks which is currently unknown.In an email conversation between Mike Hearn and an unknown recipient, Hearn discussed a limitation on most existing micropayment channel ideas, stating that payments can only flow in one direction. However, he noted that the original protocol as designed by Satoshi did not have this limitation, but it has evolved this way because of ad-hoc DoS fixes over time. Hearn suggested that eventually, a different approach to handling DoS attacks based on resource prioritization and scheduling will become needed or implemented, allowing the original design to be safely brought back to life. The unknown recipient disagreed with Hearn's understanding, stating that expecting replacement to work and be enforced is completely unsafe. They added that people refuse to use protocols that are broken by refund malleability.In a Bitcoin development mailing list, Mike Hearn stated that most micropayment channel ideas have a limitation of one-way payment flow. He further added that the original protocol as designed by Satoshi had no such limitation but has evolved over time due to ad-hoc DoS fixes. He mentioned that a different approach to handling DoS attacks based on resource prioritisation and scheduling will become necessary in the future and the original design could be safely brought back to life at that point. Jeff Garzik questioned Mike's reference to the "original design" without mentioning how it was different or better. The email also included information about the Go Parallel website which is a hub for all things parallel software development.The proposed micropayment channel idea introduces a reversible payment channel that allows payments to flow in both directions by - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml b/static/bitcoin-dev/Jan_2015/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml index 80517cb5ce..d3a022e91e 100644 --- a/static/bitcoin-dev/Jan_2015/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml +++ b/static/bitcoin-dev/Jan_2015/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Deanonymisation of clients in Bitcoin P2P network paper - 2023-08-01T10:41:10.355017+00:00 + 2025-10-11T21:39:29.264214+00:00 + python-feedgen Mike Hearn 2015-01-22 13:20:29+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Deanonymisation of clients in Bitcoin P2P network paper - 2023-08-01T10:41:10.356013+00:00 + 2025-10-11T21:39:29.264427+00:00 - The conversation revolves around the idea of mainstream wallets and wallets designed for cryptocurrency research sharing a common core. The speaker gives examples such as bitcoinj and discusses the use of Tor to improve Bitcoin wallet security. The potential risks and limitations of using Tor are also addressed, including connection drops and deanonymization issues.There is a suggestion to explore ways to improve synergy between Tor and Bitcoin, while maintaining their standalone functionality. The importance of prioritizing user privacy and the need for better DoS handling are emphasized. The discussion also touches on the effectiveness of connecting to Bitcoin using Tor and the concerns over users being forced off Tor via DOS attacks.The paper from the University of Luxembourg is referenced, which discusses the risks of obtaining IP addresses of clients involved in transactions on the Bitcoin network. The need for improvements in DoS handling and the separation of transaction submission and P2P networking are also mentioned. The potential vulnerabilities and trade-offs associated with tying Bitcoin to Tor too deeply are discussed.In response to a query about a paper posted on Reddit, Jeff Garzik, a Bitcoin core developer and open source evangelist, discussed an attack that can de-anonymize clients on the bitcoin network. While Garzik did not recall being contacted directly, he explained that the attack has been previously discussed and relies on certain conditions.If a user is using Tor, the attacker will attempt to kick the machine off Tor, assuming it will switch to non-Tor. However, this only applies to dual stack nodes, which are not completely anonymous as users operate from their public IP address anyway. The email thread includes a link to the paper from the University of Luxembourg, which delves into the details of the attack.A recent post on Reddit has shed light on a paper by the University of Luxembourg, which explores how attackers can compromise the anonymity of clients on the Bitcoin network. The paper examines various methods that can be employed to undermine user privacy. It is unclear whether these issues have been addressed, but it is mentioned that the core developers were informed about them before the publication of the paper. To access the full paper, interested individuals can follow the link provided in the Reddit post. 2015-01-22T13:20:29+00:00 + The conversation revolves around the idea of mainstream wallets and wallets designed for cryptocurrency research sharing a common core. The speaker gives examples such as bitcoinj and discusses the use of Tor to improve Bitcoin wallet security. The potential risks and limitations of using Tor are also addressed, including connection drops and deanonymization issues.There is a suggestion to explore ways to improve synergy between Tor and Bitcoin, while maintaining their standalone functionality. The importance of prioritizing user privacy and the need for better DoS handling are emphasized. The discussion also touches on the effectiveness of connecting to Bitcoin using Tor and the concerns over users being forced off Tor via DOS attacks.The paper from the University of Luxembourg is referenced, which discusses the risks of obtaining IP addresses of clients involved in transactions on the Bitcoin network. The need for improvements in DoS handling and the separation of transaction submission and P2P networking are also mentioned. The potential vulnerabilities and trade-offs associated with tying Bitcoin to Tor too deeply are discussed.In response to a query about a paper posted on Reddit, Jeff Garzik, a Bitcoin core developer and open source evangelist, discussed an attack that can de-anonymize clients on the bitcoin network. While Garzik did not recall being contacted directly, he explained that the attack has been previously discussed and relies on certain conditions.If a user is using Tor, the attacker will attempt to kick the machine off Tor, assuming it will switch to non-Tor. However, this only applies to dual stack nodes, which are not completely anonymous as users operate from their public IP address anyway. The email thread includes a link to the paper from the University of Luxembourg, which delves into the details of the attack.A recent post on Reddit has shed light on a paper by the University of Luxembourg, which explores how attackers can compromise the anonymity of clients on the Bitcoin network. The paper examines various methods that can be employed to undermine user privacy. It is unclear whether these issues have been addressed, but it is mentioned that the core developers were informed about them before the publication of the paper. To access the full paper, interested individuals can follow the link provided in the Reddit post. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_IMPULSE-Instant-Payments-using-the-Bitcoin-protocol.xml b/static/bitcoin-dev/Jan_2015/combined_IMPULSE-Instant-Payments-using-the-Bitcoin-protocol.xml index 0c3c279b3c..2331978f32 100644 --- a/static/bitcoin-dev/Jan_2015/combined_IMPULSE-Instant-Payments-using-the-Bitcoin-protocol.xml +++ b/static/bitcoin-dev/Jan_2015/combined_IMPULSE-Instant-Payments-using-the-Bitcoin-protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - IMPULSE: Instant Payments using the Bitcoin protocol - 2023-08-01T11:07:15.382698+00:00 + 2025-10-11T21:39:59.029762+00:00 + python-feedgen Justus Ranvier 2015-01-22 16:36:31+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - IMPULSE: Instant Payments using the Bitcoin protocol - 2023-08-01T11:07:15.382698+00:00 + 2025-10-11T21:39:59.029914+00:00 - On January 17th, 2015, Rune Kjær Svendsen shared a message expressing his concern about the lack of discussion around privacy-hostile products. He included a link to a product called Impulse, which he found on Reddit, and attached a PDF file for further information. Svendsen asked for thoughts from the community, but received no response, suggesting a reluctance to discuss privacy concerns.In an effort to promote online privacy, Svendsen also shared a YouTube video providing instructions on email encryption. The conversation then shifted to the security of user experience in the future, with discussions about payment facilitators and the potential for increased security. Tom Harding questioned if success could be defined by the appearance of "BitPay Payment Channels Accepted Here" signs in shop windows, highlighting the need for wider adoption of Bitcoin.The PDF document shared by Svendsen was titled 'Impulse - A Proposal for Reduced Bitcoin Transaction Fees and Instant Confirmations'. It outlined a proposal to improve transaction fees and confirmations by creating a network of payment channels that can route transactions between parties without the need for confirmation on the blockchain. This would allow for fast and cheap transactions while still maintaining the security of the blockchain.The purpose of impulse.is, a website shared by a Reddit user named /runeks, remains unclear. Along with the link, /runeks also shared a PDF file available on the same website - impulse.is/impulse.pdf. While it is speculated that impulse.is may be related to technology or software development, without further information, its exact nature and impact are unknown.Overall, the discussions and resources shared raise important questions about privacy, security, and the future of Bitcoin. The proposal for reduced transaction fees and instant confirmations through payment channels has the potential to address key issues facing Bitcoin. However, more information is needed to fully understand the implications of impulse.is and its associated PDF file. 2015-01-22T16:36:31+00:00 + On January 17th, 2015, Rune Kjær Svendsen shared a message expressing his concern about the lack of discussion around privacy-hostile products. He included a link to a product called Impulse, which he found on Reddit, and attached a PDF file for further information. Svendsen asked for thoughts from the community, but received no response, suggesting a reluctance to discuss privacy concerns.In an effort to promote online privacy, Svendsen also shared a YouTube video providing instructions on email encryption. The conversation then shifted to the security of user experience in the future, with discussions about payment facilitators and the potential for increased security. Tom Harding questioned if success could be defined by the appearance of "BitPay Payment Channels Accepted Here" signs in shop windows, highlighting the need for wider adoption of Bitcoin.The PDF document shared by Svendsen was titled 'Impulse - A Proposal for Reduced Bitcoin Transaction Fees and Instant Confirmations'. It outlined a proposal to improve transaction fees and confirmations by creating a network of payment channels that can route transactions between parties without the need for confirmation on the blockchain. This would allow for fast and cheap transactions while still maintaining the security of the blockchain.The purpose of impulse.is, a website shared by a Reddit user named /runeks, remains unclear. Along with the link, /runeks also shared a PDF file available on the same website - impulse.is/impulse.pdf. While it is speculated that impulse.is may be related to technology or software development, without further information, its exact nature and impact are unknown.Overall, the discussions and resources shared raise important questions about privacy, security, and the future of Bitcoin. The proposal for reduced transaction fees and instant confirmations through payment channels has the potential to address key issues facing Bitcoin. However, more information is needed to fully understand the implications of impulse.is and its associated PDF file. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_Is-there-a-way-to-estimate-the-maximum-number-of-transactions-per-minute-Bitcoin-can-handle-as-it-is-today-.xml b/static/bitcoin-dev/Jan_2015/combined_Is-there-a-way-to-estimate-the-maximum-number-of-transactions-per-minute-Bitcoin-can-handle-as-it-is-today-.xml index ea72d70bde..faeeae97c5 100644 --- a/static/bitcoin-dev/Jan_2015/combined_Is-there-a-way-to-estimate-the-maximum-number-of-transactions-per-minute-Bitcoin-can-handle-as-it-is-today-.xml +++ b/static/bitcoin-dev/Jan_2015/combined_Is-there-a-way-to-estimate-the-maximum-number-of-transactions-per-minute-Bitcoin-can-handle-as-it-is-today-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today? - 2023-08-01T11:16:08.850671+00:00 + 2025-10-11T21:39:52.652015+00:00 + python-feedgen Tom Harding 2015-02-01 06:50:41+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today? - 2023-08-01T11:16:08.850671+00:00 + 2025-10-11T21:39:52.652200+00:00 - Wladimir expresses his view on the scalability of blockchain technology, stating that while the everyone-validates-everything approach is valuable for settling larger transactions in a secure manner, it is not scalable. He argues against the idea of the whole world having to validate every small transaction, such as buying a cup of coffee or a bus ticket, by six billion others. Gavin supports this argument, emphasizing that artificially limiting transactions could cause competition to be lost. He further elaborates on this point in a blog post.The author raises concerns about two projects that could potentially increase transaction volume by up to 100 times: legal bittorrent file sales and P2P Amazon (OpenBazaar). They note that current centralized solutions like Bitpay and Coinbase are necessary to manage the expected volume until technology can handle it in a true peer-to-peer fashion. The author also questions the validity of Alipay's claim of handling up to 2.85 million transactions per minute, suggesting that scalability is a sign of popularity. They emphasize the importance of gaining users rather than focusing solely on broadcast protocols.The discussion then shifts to the scalability of Bitcoin. Concerns are raised about whether miners have enough bandwidth and CPU power to handle the increasing amount of data generated by transactions. However, it is acknowledged that scaling is a positive problem to have, and the focus should be on gaining users rather than worrying about precise broadcast protocols.In another conversation, Nick Simpson and Wladimir discuss the limitations of Bitcoin replacing all methods of payment and scalability concerns. Wladimir argues against broadcasting all transactions over one channel, highlighting the need for settling larger transactions in a secure way. He suggests that future scalable payment systems based on Bitcoin may involve off-blockchain transactions or a hierarchical/subdivided system.The writer challenges the notion that on-chain transactions are the only way to use Bitcoin and scale it. They refer to an article in MIT's Tech Review, which highlights Alipay's ability to handle a large number of transactions. The writer calculates that to handle 100,000 transactions per minute, a block size 1300 times larger than the current one would be needed. They further estimate that if double the number of transactions handled by Alipay were included, it would require around 15 gigabytes per block to be broadcast and hashed by all full nodes every ten minutes, consuming significant storage. The writer questions whether miners have sufficient bandwidth and CPU power to handle this level of scalability.In summary, the Chinese payment platform Alipay demonstrates impressive scalability, handling millions of transactions per minute. This raises concerns about Bitcoin's ability to compete with global financial services. The writer calculates that significant increases in transaction volume would require substantial adjustments to block sizes and could strain miners' bandwidth and CPU power. These scalability concerns prompt discussions on alternative approaches to scaling Bitcoin and the importance of gaining users. 2015-02-01T06:50:41+00:00 + Wladimir expresses his view on the scalability of blockchain technology, stating that while the everyone-validates-everything approach is valuable for settling larger transactions in a secure manner, it is not scalable. He argues against the idea of the whole world having to validate every small transaction, such as buying a cup of coffee or a bus ticket, by six billion others. Gavin supports this argument, emphasizing that artificially limiting transactions could cause competition to be lost. He further elaborates on this point in a blog post.The author raises concerns about two projects that could potentially increase transaction volume by up to 100 times: legal bittorrent file sales and P2P Amazon (OpenBazaar). They note that current centralized solutions like Bitpay and Coinbase are necessary to manage the expected volume until technology can handle it in a true peer-to-peer fashion. The author also questions the validity of Alipay's claim of handling up to 2.85 million transactions per minute, suggesting that scalability is a sign of popularity. They emphasize the importance of gaining users rather than focusing solely on broadcast protocols.The discussion then shifts to the scalability of Bitcoin. Concerns are raised about whether miners have enough bandwidth and CPU power to handle the increasing amount of data generated by transactions. However, it is acknowledged that scaling is a positive problem to have, and the focus should be on gaining users rather than worrying about precise broadcast protocols.In another conversation, Nick Simpson and Wladimir discuss the limitations of Bitcoin replacing all methods of payment and scalability concerns. Wladimir argues against broadcasting all transactions over one channel, highlighting the need for settling larger transactions in a secure way. He suggests that future scalable payment systems based on Bitcoin may involve off-blockchain transactions or a hierarchical/subdivided system.The writer challenges the notion that on-chain transactions are the only way to use Bitcoin and scale it. They refer to an article in MIT's Tech Review, which highlights Alipay's ability to handle a large number of transactions. The writer calculates that to handle 100,000 transactions per minute, a block size 1300 times larger than the current one would be needed. They further estimate that if double the number of transactions handled by Alipay were included, it would require around 15 gigabytes per block to be broadcast and hashed by all full nodes every ten minutes, consuming significant storage. The writer questions whether miners have sufficient bandwidth and CPU power to handle this level of scalability.In summary, the Chinese payment platform Alipay demonstrates impressive scalability, handling millions of transactions per minute. This raises concerns about Bitcoin's ability to compete with global financial services. The writer calculates that significant increases in transaction volume would require substantial adjustments to block sizes and could strain miners' bandwidth and CPU power. These scalability concerns prompt discussions on alternative approaches to scaling Bitcoin and the importance of gaining users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_New-BIP-protocol-for-multisignature-payments.xml b/static/bitcoin-dev/Jan_2015/combined_New-BIP-protocol-for-multisignature-payments.xml index 2eebb98276..a8e5d02842 100644 --- a/static/bitcoin-dev/Jan_2015/combined_New-BIP-protocol-for-multisignature-payments.xml +++ b/static/bitcoin-dev/Jan_2015/combined_New-BIP-protocol-for-multisignature-payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP: protocol for multisignature payments - 2023-08-01T11:16:55.045035+00:00 + 2025-10-11T21:39:46.270538+00:00 + python-feedgen Martin Habovštiak 2015-02-01 14:14:03+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - New BIP: protocol for multisignature payments - 2023-08-01T11:16:55.045035+00:00 + 2025-10-11T21:39:46.270730+00:00 - In a recent email thread, the implementation of a dispute mediation transaction protocol in bitcoinj based wallets was discussed. The author suggests creating one-off, cross-platform app-specific wallets for this purpose. However, these wallets may initially be considered specialist, requiring users to transfer funds from their general spending wallet to the dispute mediation app. The author offers guidance on implementing this protocol and proposes integrating it into general-purpose wallets in the future.The community is receptive to the idea, with Gavin Andresen emphasizing that standards should be descriptive rather than proscriptive. Mike Hearn agrees and recommends pairing a protocol specification with an implementation. Martin Habovštiak expresses interest in implementing the protocol but mentions a lack of time at present. Wallet and server-side implementations are expected to be based on existing code in languages like C++ or Python. The Crypto hackathon in Parallel Polis is suggested as a potential opportunity for implementation.Another aspect of the email exchange revolves around the importance of descriptive standards. Gavin Andresen concurs and suggests coupling protocol specifications with implementations. The original sender appreciates the feedback and commits to finding time for implementation in the future.In another discussion between Gavin Andresen and Mike Hearn, they echo the sentiment that standards should be descriptive, not prescriptive. Mike Hearn seeks feedback from the community regarding a potential implementation but does not provide specific plans.The original author intends to implement the protocol in the future but wishes to gather feedback from the community first. They believe that pairing a protocol specification with an implementation can help identify design issues and ensure user confidence and adoption.Meanwhile, in a Bitcoin-development mailing list, Martin Habovštiak shares thoughts on solving security problems faced by servers holding significant amounts of bitcoins. He proposes an extension of BIP70 that supports dynamically creating multisig transactions, with the user providing their address. Mike Hearn responds, stating that Martin's write-up resembles the high-level overview on the Bitcoin wiki. He highlights the need for implementing a wallet that supports 2-of-3 dispute mediation and the necessary tools for mediators. The BIP70 extension is seen as a smaller aspect of the project. Martin clarifies that he aimed to design a protocol to enhance usability and requests community feedback.Martin Habovštiak presents a solution for the security challenges encountered by servers holding large amounts of bitcoins, such as exchanges and markets. The proposal involves extending BIP70 to facilitate dynamic multisig transactions, with users providing their addresses. The proposal aligns with the high-level overview on https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation. Martin seeks feedback on whether this approach is suitable or if there are better alternatives. He suggests that implementing his proposed solution or a similar one in wallets would be ideal.Additionally, Martin shares the idea in a GitHub gist (https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5) and solicits community input. Another individual expresses interest in discussing their similar proposal involving generic P2SH scripts and signature requests. The email thread also includes information about the Go Parallel Website, sponsored by Intel and developed with Slashdot Media. This website serves as a hub for parallel software development resources, including blogs, news, videos, case studies, and tutorials.Overall, the email thread delves into proposals for addressing security concerns faced by servers holding substantial bitcoin amounts, accompanied by relevant links to resources related to parallel software development. 2015-02-01T14:14:03+00:00 + In a recent email thread, the implementation of a dispute mediation transaction protocol in bitcoinj based wallets was discussed. The author suggests creating one-off, cross-platform app-specific wallets for this purpose. However, these wallets may initially be considered specialist, requiring users to transfer funds from their general spending wallet to the dispute mediation app. The author offers guidance on implementing this protocol and proposes integrating it into general-purpose wallets in the future.The community is receptive to the idea, with Gavin Andresen emphasizing that standards should be descriptive rather than proscriptive. Mike Hearn agrees and recommends pairing a protocol specification with an implementation. Martin Habovštiak expresses interest in implementing the protocol but mentions a lack of time at present. Wallet and server-side implementations are expected to be based on existing code in languages like C++ or Python. The Crypto hackathon in Parallel Polis is suggested as a potential opportunity for implementation.Another aspect of the email exchange revolves around the importance of descriptive standards. Gavin Andresen concurs and suggests coupling protocol specifications with implementations. The original sender appreciates the feedback and commits to finding time for implementation in the future.In another discussion between Gavin Andresen and Mike Hearn, they echo the sentiment that standards should be descriptive, not prescriptive. Mike Hearn seeks feedback from the community regarding a potential implementation but does not provide specific plans.The original author intends to implement the protocol in the future but wishes to gather feedback from the community first. They believe that pairing a protocol specification with an implementation can help identify design issues and ensure user confidence and adoption.Meanwhile, in a Bitcoin-development mailing list, Martin Habovštiak shares thoughts on solving security problems faced by servers holding significant amounts of bitcoins. He proposes an extension of BIP70 that supports dynamically creating multisig transactions, with the user providing their address. Mike Hearn responds, stating that Martin's write-up resembles the high-level overview on the Bitcoin wiki. He highlights the need for implementing a wallet that supports 2-of-3 dispute mediation and the necessary tools for mediators. The BIP70 extension is seen as a smaller aspect of the project. Martin clarifies that he aimed to design a protocol to enhance usability and requests community feedback.Martin Habovštiak presents a solution for the security challenges encountered by servers holding large amounts of bitcoins, such as exchanges and markets. The proposal involves extending BIP70 to facilitate dynamic multisig transactions, with users providing their addresses. The proposal aligns with the high-level overview on https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation. Martin seeks feedback on whether this approach is suitable or if there are better alternatives. He suggests that implementing his proposed solution or a similar one in wallets would be ideal.Additionally, Martin shares the idea in a GitHub gist (https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5) and solicits community input. Another individual expresses interest in discussing their similar proposal involving generic P2SH scripts and signature requests. The email thread also includes information about the Go Parallel Website, sponsored by Intel and developed with Slashdot Media. This website serves as a hub for parallel software development resources, including blogs, news, videos, case studies, and tutorials.Overall, the email thread delves into proposals for addressing security concerns faced by servers holding substantial bitcoin amounts, accompanied by relevant links to resources related to parallel software development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_OpenSSL-1-0-0p-1-0-1k-incompatible-causes-blockchain-rejection-.xml b/static/bitcoin-dev/Jan_2015/combined_OpenSSL-1-0-0p-1-0-1k-incompatible-causes-blockchain-rejection-.xml index ced9842328..e2c6b71290 100644 --- a/static/bitcoin-dev/Jan_2015/combined_OpenSSL-1-0-0p-1-0-1k-incompatible-causes-blockchain-rejection-.xml +++ b/static/bitcoin-dev/Jan_2015/combined_OpenSSL-1-0-0p-1-0-1k-incompatible-causes-blockchain-rejection-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection. - 2023-08-01T11:06:21.826004+00:00 + 2025-10-11T21:39:35.650011+00:00 + python-feedgen Wladimir 2015-01-12 09:40:51+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection. - 2023-08-01T11:06:21.827006+00:00 + 2025-10-11T21:39:35.650200+00:00 - On January 10, 2015, Ivan Jelincic raised concerns about the vulnerability of openssl1.0.1j, specifically regarding CVE-2014-8275. However, it was determined that OpenSSL 1.0.1j is unaffected by this vulnerability, as stated in the major changes between OpenSSL 1.0.1j and OpenSSL 1.0.1k on the OpenSSL website news section.The post discusses how to address the OpenSSL vulnerability in Bitcoin. OpenSSL is a crucial cryptographic library used for SSL/TLS connections in Bitcoin. To tackle the issue, patches have been developed for the new OpenSSL versions, which can be found on stable branches 0.8, 0.9, and rc branch 0.10. The post provides links for fetching, building, and testing these patches. Users can choose the appropriate branch and follow the necessary steps to update their systems. Additionally, the post mentions the Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, which serves as a hub for parallel software development.In a message dated January 10, 2015, Gregory Maxwell announced the availability of patches to assist those building from source to cope with the new OpenSSL versions. These patches are accessible on stable branches 0.8, 0.9, and rc branch 0.10. Links are provided for downloading, building, and testing each software version. Users can simply copy and paste the provided command into their terminal and follow the instructions for Bitcoin versions 0.8, 0.9, and 0.10rc1+.In January 2015, Gregory Maxwell discussed an incompatibility issue caused by an OpenSSL update, which altered the behavior of ECDSA validation to reject signatures that were not encoded strictly. While this change is generally acceptable for most applications, it poses a challenge for Bitcoin, a consensus system where all participants must agree on the precise validity or invalidity of input data. This modification was a response to CVE-2014-8275, known as "Certificate fingerprints can be modified." It is important to note that this vulnerability is not limited to miners and affects various advanced Bitcoin protocols. In micropayment channel protocols, the receiver must validate signatures from the sender to ensure they can broadcast transactions containing those signatures in the future. If the receiver accepts a signature that the majority of hashing power deems invalid, the sender can exploit the micropayment channel timeout to recover their funds entirely, defrauding the receiver. Similar vulnerabilities may exist in non-Bitcoin protocols. The aforementioned incompatibility raises concerns about the design of OpenSSL itself in terms of consensus-critical considerations. Given Maxwell and Wuille's recent findings and the presence of CVE-2014-3570, it is recommended to migrate Bitcoin Core to libsecp256k1 in the near future. This move would provide a consensus-focused library with a well-understood design, resulting in fewer consensus problems compared to the existing OpenSSL dependency. Furthermore, it would benefit advanced protocol implementations by offering a clear dependency for consensus-critical signature evaluation.Bitcoin users have been cautioned against updating to OpenSSL 1.0.0p/1.0.1k, as it could lead to consensus forks and is incompatible with the Bitcoin system. Binaries released by Bitcoin Core from Bitcoin.org are unaffected, as are those built utilizing the gitian deterministic build system. However, if running third-party or self-compiled Bitcoin Core or an alternative implementation using OpenSSL, it is crucial not to update OpenSSL or to use a Bitcoin software containing a workaround. Tests included with Bitcoin Core in the test_bitcoin utility already identify this condition and fail. The incompatibility stems from the change in ECDSA validation behavior due to the OpenSSL update, which now strictly rejects signatures that are not encoded as required. While many applications can tolerate rejecting certain signatures, Bitcoin's consensus system necessitates agreement among participants on the exact validity or invalidity of input data. Consistency takes precedence over "correctness."To address the underlying issue of relying on software not designed or distributed for consensus use (specifically OpenSSL) for consensus-normative behavior, patches have been proposed for a targeted soft-fork to enforce strict DER compliance. This proposal utilizes a subset of BIP62. Implementing a blockchain rule for strict DER would minimize the risk of consensus inconsistencies arising from alternative signature parsing or verification implementations, simplify BIP62, and enhance the separation between cryptographic validation code and the consensus algorithm. Failure to adopt this solution may result in a persisting or potentially worsening situation in the future.It is worth noting that the relevant incompatible transactions have already been classified as non-standard on the network since the release of Bitcoin Core 0.8.0 in February 2013. Although one miner continued mining these incompatible transactions, they have been contacted and rectified their software. Therefore, a soft-fork without chain forking should be achievable. 2015-01-12T09:40:51+00:00 + On January 10, 2015, Ivan Jelincic raised concerns about the vulnerability of openssl1.0.1j, specifically regarding CVE-2014-8275. However, it was determined that OpenSSL 1.0.1j is unaffected by this vulnerability, as stated in the major changes between OpenSSL 1.0.1j and OpenSSL 1.0.1k on the OpenSSL website news section.The post discusses how to address the OpenSSL vulnerability in Bitcoin. OpenSSL is a crucial cryptographic library used for SSL/TLS connections in Bitcoin. To tackle the issue, patches have been developed for the new OpenSSL versions, which can be found on stable branches 0.8, 0.9, and rc branch 0.10. The post provides links for fetching, building, and testing these patches. Users can choose the appropriate branch and follow the necessary steps to update their systems. Additionally, the post mentions the Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, which serves as a hub for parallel software development.In a message dated January 10, 2015, Gregory Maxwell announced the availability of patches to assist those building from source to cope with the new OpenSSL versions. These patches are accessible on stable branches 0.8, 0.9, and rc branch 0.10. Links are provided for downloading, building, and testing each software version. Users can simply copy and paste the provided command into their terminal and follow the instructions for Bitcoin versions 0.8, 0.9, and 0.10rc1+.In January 2015, Gregory Maxwell discussed an incompatibility issue caused by an OpenSSL update, which altered the behavior of ECDSA validation to reject signatures that were not encoded strictly. While this change is generally acceptable for most applications, it poses a challenge for Bitcoin, a consensus system where all participants must agree on the precise validity or invalidity of input data. This modification was a response to CVE-2014-8275, known as "Certificate fingerprints can be modified." It is important to note that this vulnerability is not limited to miners and affects various advanced Bitcoin protocols. In micropayment channel protocols, the receiver must validate signatures from the sender to ensure they can broadcast transactions containing those signatures in the future. If the receiver accepts a signature that the majority of hashing power deems invalid, the sender can exploit the micropayment channel timeout to recover their funds entirely, defrauding the receiver. Similar vulnerabilities may exist in non-Bitcoin protocols. The aforementioned incompatibility raises concerns about the design of OpenSSL itself in terms of consensus-critical considerations. Given Maxwell and Wuille's recent findings and the presence of CVE-2014-3570, it is recommended to migrate Bitcoin Core to libsecp256k1 in the near future. This move would provide a consensus-focused library with a well-understood design, resulting in fewer consensus problems compared to the existing OpenSSL dependency. Furthermore, it would benefit advanced protocol implementations by offering a clear dependency for consensus-critical signature evaluation.Bitcoin users have been cautioned against updating to OpenSSL 1.0.0p/1.0.1k, as it could lead to consensus forks and is incompatible with the Bitcoin system. Binaries released by Bitcoin Core from Bitcoin.org are unaffected, as are those built utilizing the gitian deterministic build system. However, if running third-party or self-compiled Bitcoin Core or an alternative implementation using OpenSSL, it is crucial not to update OpenSSL or to use a Bitcoin software containing a workaround. Tests included with Bitcoin Core in the test_bitcoin utility already identify this condition and fail. The incompatibility stems from the change in ECDSA validation behavior due to the OpenSSL update, which now strictly rejects signatures that are not encoded as required. While many applications can tolerate rejecting certain signatures, Bitcoin's consensus system necessitates agreement among participants on the exact validity or invalidity of input data. Consistency takes precedence over "correctness."To address the underlying issue of relying on software not designed or distributed for consensus use (specifically OpenSSL) for consensus-normative behavior, patches have been proposed for a targeted soft-fork to enforce strict DER compliance. This proposal utilizes a subset of BIP62. Implementing a blockchain rule for strict DER would minimize the risk of consensus inconsistencies arising from alternative signature parsing or verification implementations, simplify BIP62, and enhance the separation between cryptographic validation code and the consensus algorithm. Failure to adopt this solution may result in a persisting or potentially worsening situation in the future.It is worth noting that the relevant incompatible transactions have already been classified as non-standard on the network since the release of Bitcoin Core 0.8.0 in February 2013. Although one miner continued mining these incompatible transactions, they have been contacted and rectified their software. Therefore, a soft-fork without chain forking should be achievable. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_Proposal-to-address-Bitcoin-malware.xml b/static/bitcoin-dev/Jan_2015/combined_Proposal-to-address-Bitcoin-malware.xml index fa3e1509ed..ef06d62750 100644 --- a/static/bitcoin-dev/Jan_2015/combined_Proposal-to-address-Bitcoin-malware.xml +++ b/static/bitcoin-dev/Jan_2015/combined_Proposal-to-address-Bitcoin-malware.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal to address Bitcoin malware - 2023-08-01T11:18:34.937889+00:00 + 2025-10-11T21:39:33.525522+00:00 + python-feedgen Eric Voskuil 2015-02-03 07:38:07+00:00 @@ -135,13 +136,13 @@ - python-feedgen + 2 Combined summary - Proposal to address Bitcoin malware - 2023-08-01T11:18:34.938888+00:00 + 2025-10-11T21:39:33.525806+00:00 - The context provided discusses the development of Bitcoin Authenticator, a desktop and mobile app aimed at addressing security concerns related to cryptocurrency transactions. The app offers out-of-band transaction verification/signing or dual transaction signing without requiring a third-party. The concept of using multisig wallets to protect against malware attacks is also discussed, where a compromised third-party would not be able to complete transactions as they only possess one private key.The conversation between Mike Hearn and Martin Habovštiak reveals that Bitcoin Authenticator was already implementing the idea of sending partially signed transactions from a computer to a smartphone. Habovštiak suggests creating a 3oo5 address with two cold storage keys on a desktop/laptop and a smartphone, along with one key using a third-party service. BitGo, CryptoCorp, and GreenAddress are mentioned as companies offering this model.The email conversation between Habovštiak and others further discusses the use of partially signed transactions from a computer to a smartphone to improve security. It suggests utilizing multisig wallets and adding more keys, including hardware wallets like Trezor and Ledger, to enhance security. The email emphasizes the importance of leaving out a third party for privacy reasons.The context highlights the increasing concern about malware targeting Bitcoin users and the need for effective security measures. Out-of-band transaction verification/signing is suggested as a method used in online banking to protect against attacks. The use of OATH-based one-time passwords (OTP) and chipTAN/cardTAN as additional security measures is also discussed.BIP70 is introduced as a safe method against Man-in-the-Browser (MitB) attacks, but questions about its sufficiency for transaction verification, especially in the case of a compromised computer, are raised. The compatibility of Trezor with BIP70 is uncertain. The security of the wallet is emphasized, and devices like TREZOR and secure wallet pairings are mentioned as examples.In a Bitcoin-development mailing list discussion, concerns about the security of Bitcoin transactions are raised. The possibility of generating an 8-digit number from a Bitcoin address to verify transactions is discussed, but there are concerns about the feasibility and potential collisions. The discussion highlights ongoing concerns about Bitcoin transaction security and the need for further development of solutions.The context also mentions the use of vanitygen for generating vanity bitcoin addresses and discusses viruses that manipulate bitcoin addresses. It suggests generating an 8-digit code for a legitimate bitcoin address as a basic mitigation measure against malware, but also acknowledges the possibility of brute-forcing the legitimate bitcoin address to generate a rogue address with the same code.Overall, the context presents various concepts and discussions related to improving the security of Bitcoin transactions, including the use of out-of-band verification, multisig wallets, hardware wallets, and additional authentication methods. The aim is to protect against malware attacks and ensure the privacy and integrity of transactions. 2015-02-03T07:38:07+00:00 + The context provided discusses the development of Bitcoin Authenticator, a desktop and mobile app aimed at addressing security concerns related to cryptocurrency transactions. The app offers out-of-band transaction verification/signing or dual transaction signing without requiring a third-party. The concept of using multisig wallets to protect against malware attacks is also discussed, where a compromised third-party would not be able to complete transactions as they only possess one private key.The conversation between Mike Hearn and Martin Habovštiak reveals that Bitcoin Authenticator was already implementing the idea of sending partially signed transactions from a computer to a smartphone. Habovštiak suggests creating a 3oo5 address with two cold storage keys on a desktop/laptop and a smartphone, along with one key using a third-party service. BitGo, CryptoCorp, and GreenAddress are mentioned as companies offering this model.The email conversation between Habovštiak and others further discusses the use of partially signed transactions from a computer to a smartphone to improve security. It suggests utilizing multisig wallets and adding more keys, including hardware wallets like Trezor and Ledger, to enhance security. The email emphasizes the importance of leaving out a third party for privacy reasons.The context highlights the increasing concern about malware targeting Bitcoin users and the need for effective security measures. Out-of-band transaction verification/signing is suggested as a method used in online banking to protect against attacks. The use of OATH-based one-time passwords (OTP) and chipTAN/cardTAN as additional security measures is also discussed.BIP70 is introduced as a safe method against Man-in-the-Browser (MitB) attacks, but questions about its sufficiency for transaction verification, especially in the case of a compromised computer, are raised. The compatibility of Trezor with BIP70 is uncertain. The security of the wallet is emphasized, and devices like TREZOR and secure wallet pairings are mentioned as examples.In a Bitcoin-development mailing list discussion, concerns about the security of Bitcoin transactions are raised. The possibility of generating an 8-digit number from a Bitcoin address to verify transactions is discussed, but there are concerns about the feasibility and potential collisions. The discussion highlights ongoing concerns about Bitcoin transaction security and the need for further development of solutions.The context also mentions the use of vanitygen for generating vanity bitcoin addresses and discusses viruses that manipulate bitcoin addresses. It suggests generating an 8-digit code for a legitimate bitcoin address as a basic mitigation measure against malware, but also acknowledges the possibility of brute-forcing the legitimate bitcoin address to generate a rogue address with the same code.Overall, the context presents various concepts and discussions related to improving the security of Bitcoin transactions, including the use of out-of-band verification, multisig wallets, hardware wallets, and additional authentication methods. The aim is to protect against malware attacks and ensure the privacy and integrity of transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_Re-enabling-simple-tx-replacement.xml b/static/bitcoin-dev/Jan_2015/combined_Re-enabling-simple-tx-replacement.xml index 2cc7d29f05..bfc25826a0 100644 --- a/static/bitcoin-dev/Jan_2015/combined_Re-enabling-simple-tx-replacement.xml +++ b/static/bitcoin-dev/Jan_2015/combined_Re-enabling-simple-tx-replacement.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Re-enabling simple tx replacement - 2023-08-01T11:04:42.650889+00:00 + 2025-10-11T21:39:31.388602+00:00 + python-feedgen Jorge Timón 2015-01-04 23:06:13+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Re-enabling simple tx replacement - 2023-08-01T11:04:42.650889+00:00 + 2025-10-11T21:39:31.388782+00:00 - On January 4, 2015, Gregory Maxwell expressed his appreciation for presenting solutions as code in an email exchange. He found it to be a useful way of communicating and wished more people would do the same. Another individual echoed this sentiment, emphasizing the value of using code for clear and concise communication. In a separate email conversation, Maxwell requested raw transaction data for a website and discovered that the issue he encountered was specific to the testnet. However, he was relieved to find that this behavior was not present on the real network.In another email exchange, Maxwell and Peter Todd discussed a problem with the behavior on testnet. Maxwell explained that non-mempooling is enforced by IsStandardTx in testnet but should be enforced elsewhere. He also mentioned that this issue does not occur on the real network. There is a pull request open on GitHub to fix this issue, and Todd provided his contact information and a digital signature.In another conversation between Maxwell and Ross Nicoll, Nicoll reported a bug related to unlocked transactions being relayed or mempooled far in advance. He shared a test case and attempted various solutions but encountered rejection or failure to include the transaction in a block. Maxwell requested the actual raw transaction and confirmed that this would be a severe bug if unlocked transactions were indeed being relayed or mempooled too early. Nicoll planned to set up nodes to investigate further.Maxwell also engaged in discussions with Nicoll regarding an issue with transaction locking in atomic cross-chain trading between Bitcoin and Dogecoin blockchains. Nicoll raised concerns about refund transactions blocking legitimate spend transactions in the memory pool. Maxwell responded by stating that unlocked transactions are not relayable until they lock. Nicoll proposed a patch on GitHub and sought feedback before creating a pull request. Maxwell expressed concerns about potential denial of service attacks, but Nicoll argued that only one replacement could take place, minimizing the risk.Finally, Nicoll shared his work on atomic cross-chain trading between Bitcoin and Dogecoin blockchains with a group of individuals. He encountered an issue where the refund transaction was blocking legitimate spend transactions from being accepted into the memory pool. Nicoll had drafted a patch to address this, but he was seeking feedback before raising a pull request due to concerns about potential discussions on GitHub. Other members of the group expressed their perspectives on the issue, including concerns about denial of service attacks.For more background information on the topic, refer to the provided link to the GitHub pull request. 2015-01-04T23:06:13+00:00 + On January 4, 2015, Gregory Maxwell expressed his appreciation for presenting solutions as code in an email exchange. He found it to be a useful way of communicating and wished more people would do the same. Another individual echoed this sentiment, emphasizing the value of using code for clear and concise communication. In a separate email conversation, Maxwell requested raw transaction data for a website and discovered that the issue he encountered was specific to the testnet. However, he was relieved to find that this behavior was not present on the real network.In another email exchange, Maxwell and Peter Todd discussed a problem with the behavior on testnet. Maxwell explained that non-mempooling is enforced by IsStandardTx in testnet but should be enforced elsewhere. He also mentioned that this issue does not occur on the real network. There is a pull request open on GitHub to fix this issue, and Todd provided his contact information and a digital signature.In another conversation between Maxwell and Ross Nicoll, Nicoll reported a bug related to unlocked transactions being relayed or mempooled far in advance. He shared a test case and attempted various solutions but encountered rejection or failure to include the transaction in a block. Maxwell requested the actual raw transaction and confirmed that this would be a severe bug if unlocked transactions were indeed being relayed or mempooled too early. Nicoll planned to set up nodes to investigate further.Maxwell also engaged in discussions with Nicoll regarding an issue with transaction locking in atomic cross-chain trading between Bitcoin and Dogecoin blockchains. Nicoll raised concerns about refund transactions blocking legitimate spend transactions in the memory pool. Maxwell responded by stating that unlocked transactions are not relayable until they lock. Nicoll proposed a patch on GitHub and sought feedback before creating a pull request. Maxwell expressed concerns about potential denial of service attacks, but Nicoll argued that only one replacement could take place, minimizing the risk.Finally, Nicoll shared his work on atomic cross-chain trading between Bitcoin and Dogecoin blockchains with a group of individuals. He encountered an issue where the refund transaction was blocking legitimate spend transactions from being accepted into the memory pool. Nicoll had drafted a patch to address this, but he was seeking feedback before raising a pull request due to concerns about potential discussions on GitHub. Other members of the group expressed their perspectives on the issue, including concerns about denial of service attacks.For more background information on the topic, refer to the provided link to the GitHub pull request. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_SIGHASH-WITHINPUTVALUE.xml b/static/bitcoin-dev/Jan_2015/combined_SIGHASH-WITHINPUTVALUE.xml index 95a9035f51..f2c9cdeaf4 100644 --- a/static/bitcoin-dev/Jan_2015/combined_SIGHASH-WITHINPUTVALUE.xml +++ b/static/bitcoin-dev/Jan_2015/combined_SIGHASH-WITHINPUTVALUE.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SIGHASH_WITHINPUTVALUE - 2023-08-01T11:15:45.461109+00:00 + 2025-10-11T21:40:01.157718+00:00 + python-feedgen slush 2015-01-23 19:19:40+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - SIGHASH_WITHINPUTVALUE - 2023-08-01T11:15:45.461109+00:00 + 2025-10-11T21:40:01.157896+00:00 - The email thread revolves around the potential risks associated with isolated signing devices without memory and discusses possible solutions to mitigate these risks. One suggestion made by Tamas Blummer is that nodes should not relay excessive fee transactions in order to reduce financial risk. While this proposal aims to address the issue, it is not a complete fix and does not provide detailed information on the specific risks or how they can be mitigated.On January 23, 2015, slush posted on the Bitcoin development mailing list about the progress and discussion surrounding the SIGHASH_WITHINPUTVALUE proposal. This proposal involves a hardfork that allows users to sign input values with the TxOut scripts, making it easier to transfer large amounts of data over communication channels. Slush highlights the relevance of this proposal as hardware wallets become more widespread. Slush mentions TREZOR as an example of a hardware wallet that streams and validates complex transactions. The proposed solution would significantly reduce the time required for signature verification, simplifying firmware and reducing security risks. However, existing coins would not be compatible with this proposal, necessitating software updates for senders to adopt new transaction methods.The proposal itself is considered non-intrusive as it does not alter TxOut scripts or tx/block parsing, except for verification purposes. Software developers are not obliged to implement the proposal unless they choose to upgrade their signers. Additionally, the proposal expands options for online-offline communication channels, improving overall security. Alan Reiner strongly encourages considering the inclusion of this proposal at some point.The writer of the email asks if there has been any progress or discussion regarding the increasing prevalence of hardware wallets. They stress the importance of finding a solution without specifying a particular one. They provide a link to a BitcoinTalk forum post and describe sitting next to a TREZOR device for 40 minutes during the streaming and validation of a complex transaction. The writer argues that finding a solution would optimize time, resources, and hardware costs, simplify firmware, and enhance security. They urge the community to collaborate in finding a widely agreed-upon solution to this real-world problem. 2015-01-23T19:19:40+00:00 + The email thread revolves around the potential risks associated with isolated signing devices without memory and discusses possible solutions to mitigate these risks. One suggestion made by Tamas Blummer is that nodes should not relay excessive fee transactions in order to reduce financial risk. While this proposal aims to address the issue, it is not a complete fix and does not provide detailed information on the specific risks or how they can be mitigated.On January 23, 2015, slush posted on the Bitcoin development mailing list about the progress and discussion surrounding the SIGHASH_WITHINPUTVALUE proposal. This proposal involves a hardfork that allows users to sign input values with the TxOut scripts, making it easier to transfer large amounts of data over communication channels. Slush highlights the relevance of this proposal as hardware wallets become more widespread. Slush mentions TREZOR as an example of a hardware wallet that streams and validates complex transactions. The proposed solution would significantly reduce the time required for signature verification, simplifying firmware and reducing security risks. However, existing coins would not be compatible with this proposal, necessitating software updates for senders to adopt new transaction methods.The proposal itself is considered non-intrusive as it does not alter TxOut scripts or tx/block parsing, except for verification purposes. Software developers are not obliged to implement the proposal unless they choose to upgrade their signers. Additionally, the proposal expands options for online-offline communication channels, improving overall security. Alan Reiner strongly encourages considering the inclusion of this proposal at some point.The writer of the email asks if there has been any progress or discussion regarding the increasing prevalence of hardware wallets. They stress the importance of finding a solution without specifying a particular one. They provide a link to a BitcoinTalk forum post and describe sitting next to a TREZOR device for 40 minutes during the streaming and validation of a complex transaction. The writer argues that finding a solution would optimize time, resources, and hardware costs, simplify firmware, and enhance security. They urge the community to collaborate in finding a widely agreed-upon solution to this real-world problem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_Securing-wallet-on-paper.xml b/static/bitcoin-dev/Jan_2015/combined_Securing-wallet-on-paper.xml index fa098126c4..c1780fdd41 100644 --- a/static/bitcoin-dev/Jan_2015/combined_Securing-wallet-on-paper.xml +++ b/static/bitcoin-dev/Jan_2015/combined_Securing-wallet-on-paper.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Securing wallet on paper - 2023-08-01T11:14:57.167814+00:00 + 2025-10-11T21:39:37.773513+00:00 + python-feedgen Pavol Rusnak 2015-01-22 09:46:26+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Securing wallet on paper - 2023-08-01T11:14:57.167814+00:00 + 2025-10-11T21:39:37.773679+00:00 - In an email conversation on January 22, 2015, U.Mutlu raised concerns about the lack of support for Hierarchical Deterministic (BIP32) wallets in Bitcoin Core. This limitation only allows one private key to be backed up per backup, which is both useless and risky. Mutlu suggested that developers should consider creating functionality for users to address this issue. Pavol Rusnak responded to Mutlu's suggestion by recommending software wallets like Electrum or Multibit, which already support Hierarchical Deterministic wallets. These wallets provide the desired functionality that Mutlu had highlighted. Building on this discussion, the author contemplates the possibility of printing a wallet's account number, in either base16 or base64 format, on paper for physical storage in a home or bank safe. The purpose behind this idea is to have a backup option in case of a computer hardware disaster. In this scenario, the user would manually input the information from the printed paper into a small converter program that would recreate the wallet file. However, to ensure security against potential bank fraud and theft, the output on paper should be encrypted, and the owner should store the encryption key separately. The author recommends that developers make this functionality available to users, allowing them to print encrypted wallet information for secure physical storage while maintaining the ability to recreate the wallet file when needed. 2015-01-22T09:46:26+00:00 + In an email conversation on January 22, 2015, U.Mutlu raised concerns about the lack of support for Hierarchical Deterministic (BIP32) wallets in Bitcoin Core. This limitation only allows one private key to be backed up per backup, which is both useless and risky. Mutlu suggested that developers should consider creating functionality for users to address this issue. Pavol Rusnak responded to Mutlu's suggestion by recommending software wallets like Electrum or Multibit, which already support Hierarchical Deterministic wallets. These wallets provide the desired functionality that Mutlu had highlighted. Building on this discussion, the author contemplates the possibility of printing a wallet's account number, in either base16 or base64 format, on paper for physical storage in a home or bank safe. The purpose behind this idea is to have a backup option in case of a computer hardware disaster. In this scenario, the user would manually input the information from the printed paper into a small converter program that would recreate the wallet file. However, to ensure security against potential bank fraud and theft, the output on paper should be encrypted, and the owner should store the encryption key separately. The author recommends that developers make this functionality available to users, allowing them to print encrypted wallet information for secure physical storage while maintaining the ability to recreate the wallet file when needed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_The-legal-risks-of-auto-updating-wallet-software-custodial-relationships.xml b/static/bitcoin-dev/Jan_2015/combined_The-legal-risks-of-auto-updating-wallet-software-custodial-relationships.xml index b41962ff07..1b8b8ab468 100644 --- a/static/bitcoin-dev/Jan_2015/combined_The-legal-risks-of-auto-updating-wallet-software-custodial-relationships.xml +++ b/static/bitcoin-dev/Jan_2015/combined_The-legal-risks-of-auto-updating-wallet-software-custodial-relationships.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The legal risks of auto-updating wallet software; custodial relationships - 2023-08-01T11:11:15.798222+00:00 + 2025-10-11T21:39:56.898925+00:00 + python-feedgen Roy Badami 2015-01-20 21:49:52+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - The legal risks of auto-updating wallet software; custodial relationships - 2023-08-01T11:11:15.798222+00:00 + 2025-10-11T21:39:56.899142+00:00 - The concept of custodial relationship in financial laws is defined as having the ability but not the right to dispose of an asset. This means that if someone leaves their window open and cash on the desk visible from the street, every passerby now has a custodial relationship with them. However, the example of a malicious software update seems more like theft rather than a true custodial relationship.The email thread discusses the concerns about the jurisdiction of wallet providers and the challenges faced in doing business. The writer urges people to move away from web wallet businesses due to constant demands for information by governments. They argue that this is no longer viable, citing the extra financial surveillance provisions passed on third party matters post-cromnibus. Instead, the author recommends moving towards peer-to-peer solutions like Core, Electrum Wallet, Mycelium, Local Trader, and Open Bazaar which avoid centralizations and do not collect user data or require identification. They also suggest auto-notifications for updates rather than auto-updating itself.Tamas Blummer suggests that the legal hurdle to force confiscation through a wallet provider might be lower if the target user is not domestic. Depending on the threat model, the incentive to force confiscation might also be lower. The email is signed by Justus Ranvier, with his public key ID provided, and includes an attachment named 0xEAD9E623.asc which is an application/pgp-keys file with a size of 17528 bytes.The discussion revolves around the difference between ownership and the ability to deal with an asset. Tamas Blummer points out that knowing the private key and owning the linked coins is not necessarily the same in front of a court as, at least in German law, there is a distinction between ‘Eigentum’ (ownership) and ‘Besitz’ (ability to deal with it). This means that being able to deal with an asset does not make one the owner. Matt Whitlock questions the common belief that Bitcoins have an owner independent from the parties who have access to the private keys that control their disposition; this notion is difficult to reconcile from a technological perspective.In a discussion on /r/bitcoin, Tamas Blummer stated that owning the private key and owning linked coins are not necessarily the same in court. He explained that in German law, "Eigentum" means ownership, while "Besitz" means the ability to deal with an asset - being able to deal with an asset does not make you its owner. Matt Whitlock responded, saying that this contradicts what is often told to newcomers in the Bitcoin community, as it suggests that Bitcoins have an owner independent of parties with access to their private keys. Peter Todd clarified that Bitcoin technology does not have a concept of "ownership," as this is a legal notion rather than a mathematical one. In other words, the law concerns itself with what should be done, not what can be done.The discussion is centered around how to prevent losses through malicious auto-updates in the wallet business. The best advice given is to create systems where as many people as possible have to sign off and review an update before it has the opportunity to spend user funds. It’s also suggested that companies should not be located in the same country as their users, or users should strongly be encouraged to get their wallet software from companies not located in the same country as them. Furthermore, one of the consequences of a custodial relationship is that some legal authority might try to force you to seize user funds. Authorities may use that power in the future if it’s made easy for them to meet those demands. Thus, it’s important to make sure that the process by which an update happens is controlled by more than one person and there are mechanisms in place to create good audit logs of how exactly an update happened. Finally, StrongCoin made it 100% clear to authorities that they and sites like them are able to seize funds at will.Tamas Blummer, a blockchain developer, highlighted the difference between ownership and ability to deal with an asset in German law. He explained that knowing the private key and owning linked coins is not necessarily the same in front of a court. In other words, being able to deal with an asset does not automatically make one the owner. This contradicts what many people believe about Bitcoin. The idea that Bitcoins have an owner independent from the parties with access to the private keys controlling their disposition, is difficult to reconcile from a technological perspective. Therefore, what newbies in the /r/bitcoin community are being told may be incorrect.In German law, there is a distinction between "Eigentum" (ownership) and "Besitz" (ability to deal with it). Having the private keys for someone else's bitcoins does not necessarily make you the owner of those coins. Possessing the ability to deal with an asset does not equate to ownership. Thus, possessing a private key does not automatically grant ownership of the associated bitcoins. This 2015-01-20T21:49:52+00:00 + The concept of custodial relationship in financial laws is defined as having the ability but not the right to dispose of an asset. This means that if someone leaves their window open and cash on the desk visible from the street, every passerby now has a custodial relationship with them. However, the example of a malicious software update seems more like theft rather than a true custodial relationship.The email thread discusses the concerns about the jurisdiction of wallet providers and the challenges faced in doing business. The writer urges people to move away from web wallet businesses due to constant demands for information by governments. They argue that this is no longer viable, citing the extra financial surveillance provisions passed on third party matters post-cromnibus. Instead, the author recommends moving towards peer-to-peer solutions like Core, Electrum Wallet, Mycelium, Local Trader, and Open Bazaar which avoid centralizations and do not collect user data or require identification. They also suggest auto-notifications for updates rather than auto-updating itself.Tamas Blummer suggests that the legal hurdle to force confiscation through a wallet provider might be lower if the target user is not domestic. Depending on the threat model, the incentive to force confiscation might also be lower. The email is signed by Justus Ranvier, with his public key ID provided, and includes an attachment named 0xEAD9E623.asc which is an application/pgp-keys file with a size of 17528 bytes.The discussion revolves around the difference between ownership and the ability to deal with an asset. Tamas Blummer points out that knowing the private key and owning the linked coins is not necessarily the same in front of a court as, at least in German law, there is a distinction between ‘Eigentum’ (ownership) and ‘Besitz’ (ability to deal with it). This means that being able to deal with an asset does not make one the owner. Matt Whitlock questions the common belief that Bitcoins have an owner independent from the parties who have access to the private keys that control their disposition; this notion is difficult to reconcile from a technological perspective.In a discussion on /r/bitcoin, Tamas Blummer stated that owning the private key and owning linked coins are not necessarily the same in court. He explained that in German law, "Eigentum" means ownership, while "Besitz" means the ability to deal with an asset - being able to deal with an asset does not make you its owner. Matt Whitlock responded, saying that this contradicts what is often told to newcomers in the Bitcoin community, as it suggests that Bitcoins have an owner independent of parties with access to their private keys. Peter Todd clarified that Bitcoin technology does not have a concept of "ownership," as this is a legal notion rather than a mathematical one. In other words, the law concerns itself with what should be done, not what can be done.The discussion is centered around how to prevent losses through malicious auto-updates in the wallet business. The best advice given is to create systems where as many people as possible have to sign off and review an update before it has the opportunity to spend user funds. It’s also suggested that companies should not be located in the same country as their users, or users should strongly be encouraged to get their wallet software from companies not located in the same country as them. Furthermore, one of the consequences of a custodial relationship is that some legal authority might try to force you to seize user funds. Authorities may use that power in the future if it’s made easy for them to meet those demands. Thus, it’s important to make sure that the process by which an update happens is controlled by more than one person and there are mechanisms in place to create good audit logs of how exactly an update happened. Finally, StrongCoin made it 100% clear to authorities that they and sites like them are able to seize funds at will.Tamas Blummer, a blockchain developer, highlighted the difference between ownership and ability to deal with an asset in German law. He explained that knowing the private key and owning linked coins is not necessarily the same in front of a court. In other words, being able to deal with an asset does not automatically make one the owner. This contradicts what many people believe about Bitcoin. The idea that Bitcoins have an owner independent from the parties with access to the private keys controlling their disposition, is difficult to reconcile from a technological perspective. Therefore, what newbies in the /r/bitcoin community are being told may be incorrect.In German law, there is a distinction between "Eigentum" (ownership) and "Besitz" (ability to deal with it). Having the private keys for someone else's bitcoins does not necessarily make you the owner of those coins. Possessing the ability to deal with an asset does not equate to ownership. Thus, possessing a private key does not automatically grant ownership of the associated bitcoins. This - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles.xml b/static/bitcoin-dev/Jan_2015/combined_The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles.xml index 11fa27db7f..0a5a9334c2 100644 --- a/static/bitcoin-dev/Jan_2015/combined_The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles.xml +++ b/static/bitcoin-dev/Jan_2015/combined_The-relationship-between-Proof-of-Publication-and-Anti-Replay-Oracles.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The relationship between Proof-of-Publication and Anti-Replay Oracles - 2023-08-01T11:01:08.003228+00:00 + 2025-10-11T21:39:39.896894+00:00 + python-feedgen joliver at airmail.cc 2015-01-06 11:03:47+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - The relationship between Proof-of-Publication and Anti-Replay Oracles - 2023-08-01T11:01:08.004228+00:00 + 2025-10-11T21:39:39.897067+00:00 - Peter Todd proposed a "proof-of-publication" system using OP_RETURN to embed opaque data in transactions, but faced criticism from Adam Back regarding its effectiveness. While establishing "proof-of-publication" as a universal primitive is significant, it alone does not provide sufficient indexing, validation, or exclusion capabilities. The effectiveness of this system and the number of supporters other than Peter Todd remain uncertain.In a discussion on blockchain design, the author explored layer properties such as time-stamping and namespace for constructing a decentralized PoW-chain based ecash system. Time-stamping creates an immutable stream of data with a time-ordering, while namespace adds uniqueness and first-come first-served property. The author concluded that finding improvements in the consensus critical code was challenging. Namespace attributes hold information like public keys, IP addresses, and email addresses. Proof of publication is crucial for miners to have copies of all committed data before building on top of blocks. There is a meta-incentive for bitcoin holders to help others catch up with the history, and information needs to be broadcasted due to numerous miners and full-nodes. The anti-relay term refers to the system level, and attacking the insertion logic is prevented to maintain the integrity of the merkle tree.Peter Todd shared a note about using a "proof-of-publication" system for implementing an "anti-replay" system. However, Todd argued that proof-of-(non)-publication is different from anti-replay and suggested extending the definition of proof-of-(non)-publication. He emphasized the importance of indexes and validation in cryptocurrency designs. While proof-of-(non)-publication is significant, Bitcoin also provides indexing and validation/exclusion functionalities.Various perspectives on the advantages and disadvantages of proof-of-publication markets are discussed in an email exchange. The concept of proof-of-publication allows for tradeoffs and options in connecting sellers and buyers, providing accurate price information. The term "fair" is subjective, making it challenging to define precisely. Some argue that p2p markets can exist without proof of publication, and there are other secure models beyond this concept. Third-parties may republish bids and offers to achieve better price discovery.Jorge Timón explains the advantages of proof-of-publication systems in trade scenarios. He gives an example where a seller wants to sell a unit of A for 100 units of B, and a buyer is willing to pay up to 200 Bs for 1 A. In a proof-of-publication system, the execution price is determined based on bids and asks. However, in the real world, buyers and sellers want to ensure they are connected to actual counterparts and are willing to pay a premium for that. Proof-of-publication allows for different mediums and options to meet users' needs.Paul Snow and Peter Todd discuss the relationship between anti-replay systems and proof-of-publication. Anti-replay systems prevent data repetition but do not provide information about ownership or possession. On the other hand, the blockchain can prove that a message is in the blockchain, and anyone possessing the blockchain possesses the message. They clarify that anti-replay systems are mathematical models and can be implemented in various ways.Mark Friedenbach suggests the possibility of decentralized exchanges using vanilla bitcoin if the protocol supported multiple validated assets. Peter Todd argues that non-proof-of-publication orders are insecure due to sybil attacks. They discuss an example where Alice wants to sell A for B, and Bob is willing to pay more. In a proof-of-publication system, the execution price would be fair for both parties. However, in native assets and sighash_single, miners could exploit the system, leading to unfair execution.In a discussion about new primitives, Adam Back and Peter Todd debate the security implications. Todd suggests using a trusted third party for security, while Back proposes alternative methods. They discuss the risk of sybil attacks and the implementation of double-spending punishment.Paul Snow and Peter Todd discuss the difference between anti-replay systems and proof-of-publication systems. Anti-replay prevents data repetition, while proof-of-publication proves that a message has been published without revealing its content. They clarify that the blockchain can be used to prove message presence and ownership.Peter Todd discusses the limitations of anti-replay for proof-of-publication. Anti-replay cannot determine who possesses a specific message, while proof-of-publication allows repeated entries and leaves interpretation to observers. He suggests testing publishability in an anti-replay system without actual publishing. Overall, anti-replay is insufficient for implementing proof-of-publication uses.In a discussion about decentralized exchanges, Mark Friedenbach suggests the possibility of using vanilla bitcoin with extensions for market participants to use a wider class of orders. Peter Todd argues that such orders are either based on proof-of-publication or insecure due to sybil attacks. The example of trade execution is analyzed to highlight the security concerns.These discussions provide insights into the concept of proof-of-publication, its advantages, limitations, and its role in preventing 2015-01-06T11:03:47+00:00 + Peter Todd proposed a "proof-of-publication" system using OP_RETURN to embed opaque data in transactions, but faced criticism from Adam Back regarding its effectiveness. While establishing "proof-of-publication" as a universal primitive is significant, it alone does not provide sufficient indexing, validation, or exclusion capabilities. The effectiveness of this system and the number of supporters other than Peter Todd remain uncertain.In a discussion on blockchain design, the author explored layer properties such as time-stamping and namespace for constructing a decentralized PoW-chain based ecash system. Time-stamping creates an immutable stream of data with a time-ordering, while namespace adds uniqueness and first-come first-served property. The author concluded that finding improvements in the consensus critical code was challenging. Namespace attributes hold information like public keys, IP addresses, and email addresses. Proof of publication is crucial for miners to have copies of all committed data before building on top of blocks. There is a meta-incentive for bitcoin holders to help others catch up with the history, and information needs to be broadcasted due to numerous miners and full-nodes. The anti-relay term refers to the system level, and attacking the insertion logic is prevented to maintain the integrity of the merkle tree.Peter Todd shared a note about using a "proof-of-publication" system for implementing an "anti-replay" system. However, Todd argued that proof-of-(non)-publication is different from anti-replay and suggested extending the definition of proof-of-(non)-publication. He emphasized the importance of indexes and validation in cryptocurrency designs. While proof-of-(non)-publication is significant, Bitcoin also provides indexing and validation/exclusion functionalities.Various perspectives on the advantages and disadvantages of proof-of-publication markets are discussed in an email exchange. The concept of proof-of-publication allows for tradeoffs and options in connecting sellers and buyers, providing accurate price information. The term "fair" is subjective, making it challenging to define precisely. Some argue that p2p markets can exist without proof of publication, and there are other secure models beyond this concept. Third-parties may republish bids and offers to achieve better price discovery.Jorge Timón explains the advantages of proof-of-publication systems in trade scenarios. He gives an example where a seller wants to sell a unit of A for 100 units of B, and a buyer is willing to pay up to 200 Bs for 1 A. In a proof-of-publication system, the execution price is determined based on bids and asks. However, in the real world, buyers and sellers want to ensure they are connected to actual counterparts and are willing to pay a premium for that. Proof-of-publication allows for different mediums and options to meet users' needs.Paul Snow and Peter Todd discuss the relationship between anti-replay systems and proof-of-publication. Anti-replay systems prevent data repetition but do not provide information about ownership or possession. On the other hand, the blockchain can prove that a message is in the blockchain, and anyone possessing the blockchain possesses the message. They clarify that anti-replay systems are mathematical models and can be implemented in various ways.Mark Friedenbach suggests the possibility of decentralized exchanges using vanilla bitcoin if the protocol supported multiple validated assets. Peter Todd argues that non-proof-of-publication orders are insecure due to sybil attacks. They discuss an example where Alice wants to sell A for B, and Bob is willing to pay more. In a proof-of-publication system, the execution price would be fair for both parties. However, in native assets and sighash_single, miners could exploit the system, leading to unfair execution.In a discussion about new primitives, Adam Back and Peter Todd debate the security implications. Todd suggests using a trusted third party for security, while Back proposes alternative methods. They discuss the risk of sybil attacks and the implementation of double-spending punishment.Paul Snow and Peter Todd discuss the difference between anti-replay systems and proof-of-publication systems. Anti-replay prevents data repetition, while proof-of-publication proves that a message has been published without revealing its content. They clarify that the blockchain can be used to prove message presence and ownership.Peter Todd discusses the limitations of anti-replay for proof-of-publication. Anti-replay cannot determine who possesses a specific message, while proof-of-publication allows repeated entries and leaves interpretation to observers. He suggests testing publishability in an anti-replay system without actual publishing. Overall, anti-replay is insufficient for implementing proof-of-publication uses.In a discussion about decentralized exchanges, Mark Friedenbach suggests the possibility of using vanilla bitcoin with extensions for market participants to use a wider class of orders. Peter Todd argues that such orders are either based on proof-of-publication or insecure due to sybil attacks. The example of trade execution is analyzed to highlight the security concerns.These discussions provide insights into the concept of proof-of-publication, its advantages, limitations, and its role in preventing - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_Why-Bitcoin-is-and-isn-t-like-the-Internet.xml b/static/bitcoin-dev/Jan_2015/combined_Why-Bitcoin-is-and-isn-t-like-the-Internet.xml index 71041a860f..2ff074e13e 100644 --- a/static/bitcoin-dev/Jan_2015/combined_Why-Bitcoin-is-and-isn-t-like-the-Internet.xml +++ b/static/bitcoin-dev/Jan_2015/combined_Why-Bitcoin-is-and-isn-t-like-the-Internet.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why Bitcoin is and isn't like the Internet - 2023-08-01T11:14:44.969498+00:00 + 2025-10-11T21:39:44.143507+00:00 + python-feedgen odinn 2015-01-21 19:44:35+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Why Bitcoin is and isn't like the Internet - 2023-08-01T11:14:44.969498+00:00 + 2025-10-11T21:39:44.143694+00:00 - Bitcoin is facing challenges in finding a suitable platform for mainstream users who are not tech-savvy. The current options of DIY security and privacy or reliance on third-party services are not efficient. Traditional banks have an advantage over third-party services as regulations and entry costs make it difficult to create a bank, ensuring minimum security levels for end users. In contrast, two programmers can create a Bitcoin wallet/platform without regulation or entry costs, posing a serious threat to user security.Attempts have been made to solve this problem using multisig solutions for 2-factor authentication/authorization, but these have not increased security. Insuring Bitcoin transactions also presents a challenge due to their irreversibility and scarcity. Premiums for insuring Bitcoin would be high. The author believes that a decentralized platform with true 2-factor authentication/authorization schemes can significantly improve personal security. This could make third-party wallet services obsolete, allowing non-technical users to use Bitcoin securely and fostering innovation.Insurance options are a major issue for Bitcoin. A disaster recovery mechanism is needed to address catastrophic failure modes. Bitcoin needs insured storage options to give confidence to early adopters holding large amounts of Bitcoin. An organization similar to ICANN could manage the physical nexus and help with Bitcoin's catastrophic failure modes. Insurance for Bitcoin holdings would involve an insurer holding enough Bitcoin to cover replacement of insured funds, with re-insurance being used to handle simultaneous claims. Large Bitcoin holders are well-positioned to engage in super-cat insurance businesses as Bitcoin becomes a major global currency.In response to a post by Joichi Ito, Director of the MIT Media Lab, discussing the similarities and differences between Bitcoin and the internet, there is a suggestion for an ICANN equivalent for Bitcoin. Alan Reiner, founder of Armory Technologies, highlights the need for insurance options to protect against loss events, including a disaster recovery mechanism. A body managing the physical nexus, similar to ICANN, could address Bitcoin's catastrophic failure modes. Insured storage options are crucial, as custodial bitcoins may be worth more than non-custodial ones. Dr. Ito is invited to join the DevCore Boston conference next month, which aims to support the future development of Bitcoin and is conveniently located near MIT. 2015-01-21T19:44:35+00:00 + Bitcoin is facing challenges in finding a suitable platform for mainstream users who are not tech-savvy. The current options of DIY security and privacy or reliance on third-party services are not efficient. Traditional banks have an advantage over third-party services as regulations and entry costs make it difficult to create a bank, ensuring minimum security levels for end users. In contrast, two programmers can create a Bitcoin wallet/platform without regulation or entry costs, posing a serious threat to user security.Attempts have been made to solve this problem using multisig solutions for 2-factor authentication/authorization, but these have not increased security. Insuring Bitcoin transactions also presents a challenge due to their irreversibility and scarcity. Premiums for insuring Bitcoin would be high. The author believes that a decentralized platform with true 2-factor authentication/authorization schemes can significantly improve personal security. This could make third-party wallet services obsolete, allowing non-technical users to use Bitcoin securely and fostering innovation.Insurance options are a major issue for Bitcoin. A disaster recovery mechanism is needed to address catastrophic failure modes. Bitcoin needs insured storage options to give confidence to early adopters holding large amounts of Bitcoin. An organization similar to ICANN could manage the physical nexus and help with Bitcoin's catastrophic failure modes. Insurance for Bitcoin holdings would involve an insurer holding enough Bitcoin to cover replacement of insured funds, with re-insurance being used to handle simultaneous claims. Large Bitcoin holders are well-positioned to engage in super-cat insurance businesses as Bitcoin becomes a major global currency.In response to a post by Joichi Ito, Director of the MIT Media Lab, discussing the similarities and differences between Bitcoin and the internet, there is a suggestion for an ICANN equivalent for Bitcoin. Alan Reiner, founder of Armory Technologies, highlights the need for insurance options to protect against loss events, including a disaster recovery mechanism. A body managing the physical nexus, similar to ICANN, could address Bitcoin's catastrophic failure modes. Insured storage options are crucial, as custodial bitcoins may be worth more than non-custodial ones. Dr. Ito is invited to join the DevCore Boston conference next month, which aims to support the future development of Bitcoin and is conveniently located near MIT. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2015/combined_convention-standard-for-sorting-public-keys-for-p2sh-multisig-transactions.xml b/static/bitcoin-dev/Jan_2015/combined_convention-standard-for-sorting-public-keys-for-p2sh-multisig-transactions.xml index 87a6f03ea6..a8d0b1d958 100644 --- a/static/bitcoin-dev/Jan_2015/combined_convention-standard-for-sorting-public-keys-for-p2sh-multisig-transactions.xml +++ b/static/bitcoin-dev/Jan_2015/combined_convention-standard-for-sorting-public-keys-for-p2sh-multisig-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - convention/standard for sorting public keys for p2sh multisig transactions - 2023-08-01T11:07:01.898565+00:00 + 2025-10-11T21:39:54.775519+00:00 + python-feedgen Jean-Pierre Rupp 2015-01-16 18:40:17+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - convention/standard for sorting public keys for p2sh multisig transactions - 2023-08-01T11:07:01.898565+00:00 + 2025-10-11T21:39:54.775666+00:00 - The email thread discusses the need for a BIP outlining how to determine multisig scripthash address. The current method assumes the set of keys and sorts them before deriving and sending funds to such an address. However, there is scope for further refinement by anticipating only compressed keys for scripts. This is because it is possible to cause confusion if one puts forward a compressed key at some time and an uncompressed key at another, even though there is no difference to the keys involved. There is agreement among the developers that there is a need for a BIP outlining this process, and the writer is building a list of implementations which currently support sorting. The email also contains a discussion about pubkeys and their representation as DER-encoded integers. The email author's PGP key is available in the attachment.In a discussion on the Bitcoin development mailing list, Matt Whitlock raises a question about the representation of pubkeys in Script. Eric Lombrozo clarifies that internally, pubkeys are DER-encoded integers, but in Script, they are represented as raw integers. Wladimir adds that OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a DER-encoded signature on the stack. He also notes that it is not helpful to consider pubkeys or hashes as integers, as they are binary blob objects with either a fixed format (DER) or a fixed size (hashes). The conversation continues with Ruben de Vries from BlockTrail providing his contact information.Ruben de Vries, CTO of BlockTrail, has suggested the need for a standard way of sorting public keys in P2SH multisig transactions. According to him, the order of public keys affects the hash and there is no agreed-upon way of sorting them. He proposes that setting a standard would make it easier for multisig services to be compatible with each other and allow importation of keys from one service to another. Although he is not suggesting forcing the order, he believes that recommending a standard would encourage new services to follow suit. Ryan from BitPay had previously brought up this issue, and Bitcore has implemented lexicographical sorting on the hex of the public key. Ruben could not find any other library with a sorting function, let alone using it by default, so Bitcore is currently his only reference. Jeff Garzik, a Bitcoin core developer and open source evangelist at BitPay, responded to Ruben's proposal, suggesting that it warrants a micro-BIP to bring everyone on the same page.In January 2015, Ruben de Vries suggested on the Bitcoin-development mailing list that a standard way of sorting public keys should be set for p2sh multisig transactions to ensure compatibility between services. He suggested using lexicographical sorting on the hex of the public key, which had already been implemented in bitcore. Jeff Garzik agreed that a micro-BIP should be created to establish a standard and get everyone on the same page. The existing BIP45 mentions "lexicographically sorting the public keys" but does not provide specific details on how this should be done.The conversation dated 14th January 2015 between Jeffrey Paul and an unknown person regarding the clarification of the raw bytes of public keys has been provided. In the conversation, Jeffrey Paul asked for clarification about the raw bytes of the public key itself, not the ascii base58 representation of the pubkey hash. The unknown person was requested to give an example of two pubkeys where raw(pubkey1) > raw(pubkey2) and base58(pubkey1) is greater than or equal to base58(pubkey2).A discussion between devrandom and Jeffrey Paul took place on January 14, 2015. Devrandom's message explained that CryptoCorp recommends to its customers to sort lexicographically by the public key bytes of the leaf public keys in the same way as BitPay does. Jeffrey Paul sought clarification if it was the raw bytes of the public key itself, not the ASCII base58 representation of the pubkey hash. He added his contact details at eeqj.com and two phone numbers for America and worldwide.Haskoin, a company in the cryptocurrency industry, follows the same method of sorting public keys as recommended by CryptoCorp. The method involves sorting the public keys lexicographically based on the bytes of their leaf public keys. This is the same approach used by BitPay. The recommendation was made in an email exchange on January 14, 2015, between devrandom and an unknown recipient. The use of public keys is essential in the functioning of cryptocurrencies. Public keys are used to receive payments, while private keys are used to authorize transactions. Sorting public keys based on their bytes simplifies the process of verifying transactions and ensures that transactions can be traced back to the correct parties. CryptoCorp was a prominent player in the cryptocurrency industry until its closure in 2015. Its recommendations regarding public key sorting were widely followed by other companies in the industry, including H 2015-01-16T18:40:17+00:00 + The email thread discusses the need for a BIP outlining how to determine multisig scripthash address. The current method assumes the set of keys and sorts them before deriving and sending funds to such an address. However, there is scope for further refinement by anticipating only compressed keys for scripts. This is because it is possible to cause confusion if one puts forward a compressed key at some time and an uncompressed key at another, even though there is no difference to the keys involved. There is agreement among the developers that there is a need for a BIP outlining this process, and the writer is building a list of implementations which currently support sorting. The email also contains a discussion about pubkeys and their representation as DER-encoded integers. The email author's PGP key is available in the attachment.In a discussion on the Bitcoin development mailing list, Matt Whitlock raises a question about the representation of pubkeys in Script. Eric Lombrozo clarifies that internally, pubkeys are DER-encoded integers, but in Script, they are represented as raw integers. Wladimir adds that OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a DER-encoded signature on the stack. He also notes that it is not helpful to consider pubkeys or hashes as integers, as they are binary blob objects with either a fixed format (DER) or a fixed size (hashes). The conversation continues with Ruben de Vries from BlockTrail providing his contact information.Ruben de Vries, CTO of BlockTrail, has suggested the need for a standard way of sorting public keys in P2SH multisig transactions. According to him, the order of public keys affects the hash and there is no agreed-upon way of sorting them. He proposes that setting a standard would make it easier for multisig services to be compatible with each other and allow importation of keys from one service to another. Although he is not suggesting forcing the order, he believes that recommending a standard would encourage new services to follow suit. Ryan from BitPay had previously brought up this issue, and Bitcore has implemented lexicographical sorting on the hex of the public key. Ruben could not find any other library with a sorting function, let alone using it by default, so Bitcore is currently his only reference. Jeff Garzik, a Bitcoin core developer and open source evangelist at BitPay, responded to Ruben's proposal, suggesting that it warrants a micro-BIP to bring everyone on the same page.In January 2015, Ruben de Vries suggested on the Bitcoin-development mailing list that a standard way of sorting public keys should be set for p2sh multisig transactions to ensure compatibility between services. He suggested using lexicographical sorting on the hex of the public key, which had already been implemented in bitcore. Jeff Garzik agreed that a micro-BIP should be created to establish a standard and get everyone on the same page. The existing BIP45 mentions "lexicographically sorting the public keys" but does not provide specific details on how this should be done.The conversation dated 14th January 2015 between Jeffrey Paul and an unknown person regarding the clarification of the raw bytes of public keys has been provided. In the conversation, Jeffrey Paul asked for clarification about the raw bytes of the public key itself, not the ascii base58 representation of the pubkey hash. The unknown person was requested to give an example of two pubkeys where raw(pubkey1) > raw(pubkey2) and base58(pubkey1) is greater than or equal to base58(pubkey2).A discussion between devrandom and Jeffrey Paul took place on January 14, 2015. Devrandom's message explained that CryptoCorp recommends to its customers to sort lexicographically by the public key bytes of the leaf public keys in the same way as BitPay does. Jeffrey Paul sought clarification if it was the raw bytes of the public key itself, not the ASCII base58 representation of the pubkey hash. He added his contact details at eeqj.com and two phone numbers for America and worldwide.Haskoin, a company in the cryptocurrency industry, follows the same method of sorting public keys as recommended by CryptoCorp. The method involves sorting the public keys lexicographically based on the bytes of their leaf public keys. This is the same approach used by BitPay. The recommendation was made in an email exchange on January 14, 2015, between devrandom and an unknown recipient. The use of public keys is essential in the functioning of cryptocurrencies. Public keys are used to receive payments, while private keys are used to authorize transactions. Sorting public keys based on their bytes simplifies the process of verifying transactions and ensures that transactions can be traced back to the correct parties. CryptoCorp was a prominent player in the cryptocurrency industry until its closure in 2015. Its recommendations regarding public key sorting were widely followed by other companies in the industry, including H - + \ No newline at end of file diff --git a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml index 62deba5512..b16c7334b8 100644 --- a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml +++ b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Allow-zero-value-OP-RETURN-in-Payment-Protocol.xml @@ -2,7 +2,7 @@ 2 Combined summary - [BIP Draft] Allow zero value OP_RETURN in Payment Protocol - 2025-09-26T15:28:28.616491+00:00 + 2025-10-11T21:29:55.268864+00:00 python-feedgen Toby Padilla 2016-02-02 19:22:10+00:00 @@ -101,10 +101,11 @@ + 2 Combined summary - [BIP Draft] Allow zero value OP_RETURN in Payment Protocol - 2025-09-26T15:28:28.616689+00:00 + 2025-10-11T21:29:55.269066+00:00 2016-02-02T19:22:10+00:00 In a discussion between Toby Padilla and Luke Dashjr, the use of OP_RETURN values in Bitcoin transactions is debated. Toby argues that PaymentRequests limit the use of OP_RETURN values, as they must be greater than zero, creating a pre-OP_RETURN environment. Luke counters, suggesting that coins should be burned instead of allowing zero value OP_RETURNs. However, Toby believes there is a better alternative.The conversation revolves around the limitations of PaymentRequests regarding OP_RETURN values. Toby explains that PaymentRequests allow for similar transactions as non-PaymentRequest based transactions, but with the limitation that OP_RETURN values must be greater than zero. In contrast, Luke believes that OP_RETURN can be used, but coins would need to be burned, and he sees no benefit in changing that.Toby clarifies his point by mentioning BIP70, where the key for redeeming inputs can be in the user's wallet, allowing transaction construction on another machine without needing a key. However, currently, transaction construction on another machine with zero value OP_RETURNs is not possible. Despite their disagreement, both parties acknowledge that a key is always necessary for redeeming inputs in Bitcoin transactions.On January 26, 2016, Toby sent a message to Luke discussing the encoding of data on the blockchain. Luke suggests that supporting OP_RETURN in PaymentRequests is unnecessary, but Toby argues that it is important because people may use worse methods for encoding data. Toby also mentions the difficulty of constructing a transaction with a zero value OP_RETURN without keys in an environment without keys. Luke does not understand Toby's statement.The discussion focuses on a draft proposal that has not been approved by the mailing list yet. The draft suggests accepting zero value OP_RETURN outputs in BIP70 payment requests, which were previously ignored. The author argues that this feature would be useful for encoding data on the blockchain using PaymentRequests. However, Luke strongly advises against publishing or implementing this BIP, as he sees no benefit to the network and believes it could encourage spam. He also argues that the proposed changes are detrimental and would make users unwilling participants in spam.The author responds by giving an example of how merchants can add the hash of a plain text invoice to the checkout transaction by constructing the PaymentRequest with the invoice hash in an OP_RETURN. Toby argues that merchants and Bitcoin application developers would benefit from this BIP because they can construct transactions with OP_RETURN data without needing keys. Prior to this BIP, such transactions needed to be executed within the same software. Luke questions the relevance to keys and argues that the proposed changes are not compatible with existing and future software. He concludes that implementing either BIP 70 or this draft would have severe consequences, emphasizing that losing burned bitcoins is better than having a way to avoid them.The author of a Bitcoin Improvement Proposal (BIP) warns against publishing or implementing it due to potential spam and user unwillingness. The BIP suggests allowing merchants to add plain text invoice hashes to checkout transactions using PaymentRequests with zero value OP_RETURN outputs. However, the proposal lacks wallet support for checking upfront, may encourage spam, and does not consider the relevance to keys. The proposed changes are also not backward nor forward compatible, resulting in severe consequences.The author has submitted a new BIP draft that alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. This allows wallets to participate in current and future use cases that benefit from metadata stored in OP_RETURN. Previously, OP_RETURN transactions required custom software, but now wallets can process PaymentRequests with OP_RETURN data, supporting sophisticated Bitcoin applications without prior knowledge. Merchants and Bitcoin application developers benefit from this BIP by being able to construct transactions with OP_RETURN data in a keyless environment. Without supporting this BIP, wallets that support BIP70 will allow wasteful data storage. diff --git a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-BIP-Acceptance-Process.xml b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-BIP-Acceptance-Process.xml index 7f275c2efa..cb03f06a04 100644 --- a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-BIP-Acceptance-Process.xml +++ b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-BIP-Acceptance-Process.xml @@ -2,7 +2,7 @@ 2 Combined summary - [BIP/Draft] BIP Acceptance Process - 2025-09-26T15:28:30.729074+00:00 + 2025-10-11T21:29:57.403906+00:00 python-feedgen Dave Scotese 2016-01-19 06:07:52+00:00 @@ -89,10 +89,11 @@ + 2 Combined summary - [BIP/Draft] BIP Acceptance Process - 2025-09-26T15:28:30.729259+00:00 + 2025-10-11T21:29:57.404106+00:00 2016-01-19T06:07:52+00:00 The current process for Bitcoin Improvement Proposals (BIPs) lacks clarity and there is a proposal to improve it. One suggestion is to have committees that review and indicate acceptance of BIPs, but there are debates and concerns surrounding this idea. Luke Dashjr argues against the committee proposal and suggests a specification based on BIP 123 instead. He questions the requirement for 1% stake for each segment of the Bitcoin ecosystem, citing privacy violations and time consumption.The proposed process aims to include more voices and gain a clearer idea of acceptance than the current process allows. The committee structures would be fluid, allowing users to reorganize at any time. However, there are debates about how different groups would prove their stake and express their positions. There is also a discussion about the definition of "accepted" and whether it should be binding on client authors. It is suggested that a BIP could be "greenlighted" by the community, but it's unclear if this would guarantee implementation.Overall, there is a need to improve the BIP process to ensure clear and fair acceptance of proposals. Some aspects of the current process need polishing, especially around "workflow states," but introducing committees may not be the best solution. The goal is to develop a process that gathers meaningful information to guide decisions without forcing anything on implementors or users. Peer review and open discussions are seen as important filtering mechanisms for proposals.It is important to note that the BIP process is separate from the implementation and adoption of proposals in Bitcoin software such as Bitcoin Core. Consensus rule changes are usually documented as BIPs, but their adoption and implementation depend on the wider ecosystem.In conclusion, the discussion highlights the need for a better process to accept BIPs in Bitcoin. Various proposals and concerns have been raised, including the role of committees, proving stake, expressing positions, and defining acceptance. The aim is to ensure a fair and transparent process that includes diverse voices and avoids unnecessary bureaucracy. diff --git a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml index a71e3b0abf..248113e90e 100644 --- a/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml +++ b/static/bitcoin-dev/Jan_2016/combined_-BIP-Draft-Decentralized-Improvement-Proposals.xml @@ -2,7 +2,7 @@ 2 Combined summary - [BIP Draft] Decentralized Improvement Proposals - 2025-09-26T15:28:24.389574+00:00 + 2025-10-11T21:29:51.016918+00:00 python-feedgen Rusty Russell 2016-01-03 23:31:26+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - [BIP Draft] Decentralized Improvement Proposals - 2025-09-26T15:28:24.389734+00:00 + 2025-10-11T21:29:51.017107+00:00 2016-01-03T23:31:26+00:00 In a discussion on bitcoin-dev, Luke Dashjr and Tomas debated the efficiency of the specification for version bits. Tomas raised concerns about the unclear assignment of version bits in the specification, suggesting that any implementation proposing a change should be encouraged to choose a free version bit to use. Luke agreed that clarification was necessary in the BIP, or Bitcoin Improvement Proposal, and suggested that the BIP editor assign version bits like BIP numbers themselves. However, he also noted that since the number of deployed forks is low, it may not be necessary to have a more robust system. Rusty, another member of the discussion, offered to fill that role if needed.In an email exchange between Tomas and Luke on December 30, 2015, they discuss the efficiency and implementation of version bits in the context of proposing changes to the Bitcoin network. Tomas expresses concern over the inefficiency of the current system and suggests that clarification is needed for assigning version bits. Luke proposes that the BIP editor assign version bits similarly to BIP numbers. Tomas further suggests that his proposal addresses the danger of forward-incompatible changes and eliminates the possibility of a hard fork, but Luke disagrees. He points out that a hard fork can always occur as it is determined by the economy and not miners. Additionally, changes such as a PoW algorithm change could still lead to further rule changes.In a recent discussion, Tomas expressed his opinion on the inefficiency and bloatiness of a specification which appears to be a reinvention of version bits. The allocation of version bits was not clear from the specification, leading to confusion regarding the implementation of proposed changes. Tomas also addressed the issue of forward-incompatible changes by proposing a solution that prevents hard-forks from occurring, ensuring that every implementation agrees on the active set of rules even if it has not implemented them. This crucial aspect seems to be missing in the version bits proposal.In December 2015, Tomas proposed a BIP (Bitcoin Improvement Proposal) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. However, Luke criticized the motivation behind this proposal stating that BIPs are required to have a reference implementation, but it need not necessarily be for Bitcoin Core specifically. He also commented on the specification, saying that it looked like an inefficient and bloaty reinvention of version bits.Tomas van der Wansem has drafted a Bitcoin Improvement Proposal (BIP) to reduce developer centralization and minimize the risk of forks introduced by implementations other than bitcoin-core. The BIP can be found on GitHub. He believes that the proposal can help in decentralizing the development of the protocol and mitigate the risk of forks. He is requesting a BIP-number if the proposal is considered worthy of discussion. diff --git a/static/bitcoin-dev/Jan_2016/combined_An-implementation-of-BIP102-as-a-softfork-.xml b/static/bitcoin-dev/Jan_2016/combined_An-implementation-of-BIP102-as-a-softfork-.xml index 2175b2fda5..23eb5af4e6 100644 --- a/static/bitcoin-dev/Jan_2016/combined_An-implementation-of-BIP102-as-a-softfork-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_An-implementation-of-BIP102-as-a-softfork-.xml @@ -2,7 +2,7 @@ 2 Combined summary - An implementation of BIP102 as a softfork. - 2025-09-26T15:28:26.505540+00:00 + 2025-10-11T21:29:53.144866+00:00 python-feedgen joe2015 at openmailbox.org 2016-01-12 03:58:13+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - An implementation of BIP102 as a softfork. - 2025-09-26T15:28:26.505722+00:00 + 2025-10-11T21:29:53.145055+00:00 2016-01-12T03:58:13+00:00 In a Bitcoin-dev mailing list, Joe2015 responded to Nick ODell's query about fee collection from transactions in the block. Joe suggested mapping the new-rules coinbase transaction into an old-rules legacy coinbase transaction, but emphasized the need for careful consideration to ensure the mapping is irreversible. Joe has redesigned the implementation and provided GitHub links for reference. The new version maps the Merkle root onto a 'legacy' coinbase transaction, effectively solving the problem with fees.The conversation on the Bitcoin-dev mailing list revolves around Joe's proposal for a "generalized soft fork." Marco Falke expresses doubts about the proposal, arguing that it contradicts the definition of a soft fork as it requires nodes to upgrade. Joe clarifies that while it may not technically be a soft fork, it possesses similar properties except for meaningful backwards compatibility for non-upgraded clients. Marco raises concerns about how non-updated nodes would verify collected fees without actual transactions at hand and suggests a hard fork as a cleaner solution. Joe acknowledges that hard forks can be cleaner but highlights the risk of network splitting between upgraded and non-upgraded clients. He argues that a "firm soft fork" could be a better option. However, Joe realizes an oversight in his proof-of-concept implementation where all transactions would have to be zero-fee due to missing fees from non-updated nodes. He suggests implicitly adding the fees or finding other solutions.Marco Falke and Joe discuss the concept of a "generalized" soft fork. Falke questions the property of a true soft fork as it requires nodes to upgrade, leaving non-upgraded nodes vulnerable to double spends. Joe suggests allowing the new rules to add fees implicitly as a solution. When Falke questions the benefits of a "generalized" soft fork over a hard fork, Joe emphasizes the risk of a network split between upgraded and non-upgraded clients and argues that a "firm" soft fork is a better option in such cases.The Bitcoin developer community is discussing a proposal called the "forced soft-fork," which would require all nodes on the network to upgrade to the latest software version. The proposal has received mixed reactions, with some considering it "crufty and hackish" while others argue that the fear of recursion is misplaced. The forced soft-fork involves a multi-levels-deep block-within-a-block approach, but proponents claim that careful planning can simplify it. While the forced soft-fork could make it easier for developers to implement new features and upgrades, concerns about its impact on the security and stability of the Bitcoin network remain.In a discussion on the bitcoin-dev mailing list, Martijn Meijering expresses concerns about blocking old clients from seeing transactions. Peter Todd warns against sending multiple transactions without knowing if the longest blockchain is being seen and suggests designing software with fee-bumping to avoid mistakes. Increasing the tx version number could potentially disrupt pre-signed transactions.Jonathan Toomim voices his opinion against a proposed approach involving multi-levels-deep block structures for generalized softforks, deeming it interesting but hackish and not deployable. Another participant suggests incorporating the forced fork concept into Bitcoin by committing to H(version + digest) in block headers. This approach would provide safety advantages over hard forks and relatively simple implementation, though it may institutionalize 51% attacks and give miners more political control.A proposal for a softfork implementation of BIP102, normally a hardfork, has been shared on the bitcoin-dev mailing list. The implementation uses a strategy pattern to address concerns with deploying a block-size increase through a hardfork. Post-fork blocks are constructed to be mapped to valid blocks under pre-fork rules, allowing post-fork miners to create a valid chain indirectly. For non-upgraded clients, the block-size limit is circumvented by moving transaction validation data "outside" of the block, while upgraded clients see an unchanged block layout with a larger block-size limit and a new interpretation of the header Merkle root encoded in the coinbase. This implementation reduces fraud risk and requires miner majority to force miner consensus.A concern has been raised about the safety of old clients not being able to see transactions due to a new transaction blocking feature. It is suggested that increasing the tx version number could prevent transactions sent from old clients from confirming. The inclusion of this idea in the code remains uncertain.Marco questions whether a proposed approach is actually a soft fork, as it requires nodes to upgrade. He argues that true soft forks don't require any node upgrades and expresses concerns about missing transactions and vulnerability to double spends for non-upgraded nodes. Marco asks if there is something he is missing about the proposal.A proof-of-concept implementation of BIP102 as a softfork has been developed under the unofficial codename BIP102s. It constructs post-fork blocks that can be mapped to valid blocks under pre-fork rules, enabling post-fork miners to create a valid chain indirectly. Non-upgraded clients see the circumvention of diff --git a/static/bitcoin-dev/Jan_2016/combined_BIP-Classification-Process.xml b/static/bitcoin-dev/Jan_2016/combined_BIP-Classification-Process.xml index f8eadd4d66..c36379eb96 100644 --- a/static/bitcoin-dev/Jan_2016/combined_BIP-Classification-Process.xml +++ b/static/bitcoin-dev/Jan_2016/combined_BIP-Classification-Process.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Classification Process - 2025-09-26T15:28:18.043226+00:00 + 2025-10-11T21:29:44.647114+00:00 python-feedgen Eric Lombrozo 2016-01-29 07:57:00+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - BIP Classification Process - 2025-09-26T15:28:18.043394+00:00 + 2025-10-11T21:29:44.647278+00:00 2016-01-29T07:57:00+00:00 According to Btc Drak, the bitter resentment over the need for consensus on non-consensus features in codebase forks is a problem. He believes that forks with non-consensus features are acceptable and desirable because they allow for more freedom in upper layers. Eric Lombrozo, a Bitcoin developer, agrees with this perspective and suggests that a better process is needed to distinguish between different layers for bitcoin modification proposals.Lombrozo gives an example of BIP64 proposed by Mike Hearn, which did not affect the consensus layer at all. Despite being disliked by many Core developers, having nodes that support BIP64 would not fundamentally break the Bitcoin network. However, the pushback from Core developers led Mike to break off from Core and create XT as his applications required BIP64 to work. Lombrozo emphasizes the importance of a process that clearly distinguishes these different layers and allows more freedom in the upper layers while requiring agreement at the consensus layer.To address this issue, Lombrozo has submitted a BIP - BIP123 - that includes all currently proposed and accepted BIPs. He urges everyone to seriously consider getting this BIP accepted as a top priority before more projects attempt to make modifications without understanding these critical distinctions. However, it is pointed out that Eric's proposal does not solve the issue related to Mike creating his own fork, as he had a non-consensus feature set that Bitcoin Core disagreed with. The creation of individual forks with different features is encouraged if there is a strong differing of technical opinions and node security concerns.In summary, the current situation with forks in the Bitcoin network could have been avoided with a better process to distinguish between different layers for bitcoin modification proposals. The example of BIP64 and Mike Hearn's creation of XT highlights the need for a clear distinction between consensus and non-consensus features. Lombrozo's BIP123 proposal aims to address this issue and includes all currently proposed and accepted BIPs. It is crucial to prioritize the acceptance of this BIP to prevent further projects from making modifications without understanding these critical distinctions. diff --git a/static/bitcoin-dev/Jan_2016/combined_Best-block-nr-2016-for-hard-fork-activation-.xml b/static/bitcoin-dev/Jan_2016/combined_Best-block-nr-2016-for-hard-fork-activation-.xml index b1846eee54..e7bd64a5ab 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Best-block-nr-2016-for-hard-fork-activation-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Best-block-nr-2016-for-hard-fork-activation-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Best (block nr % 2016) for hard fork activation? - 2025-09-26T15:28:47.647332+00:00 + 2025-10-11T21:30:14.415093+00:00 python-feedgen Peter Todd 2016-01-29 19:11:52+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Best (block nr % 2016) for hard fork activation? - 2025-09-26T15:28:47.647484+00:00 + 2025-10-11T21:30:14.415226+00:00 2016-01-29T19:11:52+00:00 In a discussion on the Bitcoin-dev mailing list, Jannes Faber raised concerns about the impact of a non-contentious hard fork on the remaining 1% chain. Peter Todd responded by discussing the risks of hard forks and suggested that activation thresholds for hard forks should be above 99%, measured over a multi-week timespan. He also mentioned that high activation thresholds could be soft-forked down later and that delaying the fork by two or three months if stragglers won't upgrade would not cause much harm. Todd emphasized that hard forks should not be controversial for social/political reasons, except in rare cases like security issues. He referred to his previous post on the technical risks of non-controversial forks.The email thread from January 29, 2016, focused on the impact of a fork during the difficulty period. The BIP9 optimization checks for new activations only during difficulty retargettings. However, it is not assumed that all implementations will follow this approach. BIP99 proposes a 95% activation threshold for uncontroversial rule changes and no miner signaling for controversial hard forks. The proposal includes simple fixes like the timewarp fix forward-ported from Freicoin 0.8. There has been limited interest in expanding the list of easy-to-implement changes. BIP99 has not faced opposition as a hardfork proposal, but it is not currently a priority. It may be classified as a BIP without code, and the hardfork proposal itself should have been separate.In another bitcoin-dev mailing list discussion, Jannes Faber expressed concerns about the effects of a hard or soft fork on non-upgraded clients, specifically regarding the 2016 blocks recalibration window. Gavin Andresen responded by stating that the timing of the fork within the difficulty period does not matter significantly. If the fork happens in the middle, the lower-power fork's difficulty will adjust slightly quicker. However, Andresen acknowledged that this scenario is unrealistic, as minority forks with single-digit percentages of hash power would cause significant delays and difficulty adjustments lasting months before normal block times are resumed. He referred to his blog post on minority branches, explaining why miners have little incentive to mine on a minority fork.The writer of the email seeks clarification on the effects of hard or soft forks, particularly related to the timing of implementing new rules and their impact on non-upgraded clients. They present four options for when to apply new rules, all related to the 2016 blocks recalibration window. The writer discusses the potential consequences of each option, particularly in the case of a contentious 75-25 hard fork, where option 4 would be best for the conservative chain. They also consider scenarios where it may be beneficial for the remaining 1% chain to never reach 2016 blocks again. The writer questions whether all possible scenarios have been considered and suggests that defining the best choice should be mandatory for any hard fork proposal, possibly through BIP9. Additionally, the writer acknowledges that the first few blocks mined after implementing new rules may not immediately adhere to the new guidelines. diff --git a/static/bitcoin-dev/Jan_2016/combined_Bitcoin-Core-0-12-0-release-candidate-1-available.xml b/static/bitcoin-dev/Jan_2016/combined_Bitcoin-Core-0-12-0-release-candidate-1-available.xml index e6e58eb576..b64a58a109 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Bitcoin-Core-0-12-0-release-candidate-1-available.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Bitcoin-Core-0-12-0-release-candidate-1-available.xml @@ -2,7 +2,7 @@ 2 Combined summary - Bitcoin Core 0.12.0 release candidate 1 available - 2025-09-26T15:28:39.189412+00:00 + 2025-10-11T21:30:05.912698+00:00 python-feedgen xor at freenetproject.org 2016-01-25 17:33:09+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Bitcoin Core 0.12.0 release candidate 1 available - 2025-09-26T15:28:39.189591+00:00 + 2025-10-11T21:30:05.912856+00:00 2016-01-25T17:33:09+00:00 On January 25, 2016, Wladimir J. van der Laan requested assistance with the release notes for Bitcoin on Github. Another user submitted a pull request to resolve the issue, including a digitally signed signature. The context discusses the minimum storage quota of 550 MiB required for pruning nodes in Bitcoin. The reason for this minimum storage quota is to allow reorgs up to 288 blocks deep even when pruning. The PGP signature at the end of the message indicates that the message has not been tampered with and was signed by the sender using their private key.The concept of pruning in the Bitcoin ecosystem is often misunderstood. Satoshi's paper refers to UTXO pruning, while Pieter Wuille's "ultraprune" has been part of Bitcoin Core for more than three years. Block pruning is not mentioned in Satoshi's paper because nodes store historical blocks merely for administrative purposes. Pruning nodes don't serve block data at all unless there is a change to the P2P protocol. To enable block pruning, a number of megabytes "to allot for raw block & undo data" must be given, with any value being intended to be safe. Very low values could delete undo data that may be necessary in a reorganization, but this is prohibited by argument checks. It is important to note that the minimum storage quota of 550 MiB is necessary for pruning nodes even if the block data is not served to other nodes.The Bitcoin Core has already implemented the pruning feature, which stores the chainstate of about 2 GB regardless of what is set for prune. The minimum theoretical value of the prune target is zero, but in practice, it is 510, so small rescans and reorgs are still possible. Clients will not let you set below the minimum of 550 MB. Pruning deletes old transaction data that moves coins around and stores only the origin and current location of unspent transactions. There is a "natural" amount of megabytes for a fully pruned blockchain, which should be defined by the final amount of unspent coins. However, the number of megabytes to allot for raw block and undo data can be configured.In a discussion regarding block pruning in Bitcoin, Wladimir J. van der Laan suggested advertising the feature in the new release notes, which was added by Marco Falke. The RC2 changelog now includes instructions on enabling block pruning by setting prune= on the command line or in bitcoin.conf, with N representing the number of MiB allotted for raw block and undo data. A user expressed confusion over the need to specify a value for N, as they believed pruning should be a boolean on/off flag that automatically computes the natural size of the dataset based on the final amount of unspent coins. They requested further explanation in the release notes, including why N must be given, a "safe" value for N, and whether there is an "auto" setting for N.On January 18, 2016, Wladimir J. van der Laan announced the first binary release that contained block pruning functionality, which had been tested in git for almost half a year. He advised users to backup their wallets regardless. The previous v0.11.0 release notes stated that block pruning was incompatible with running a wallet because block data was used for rescanning the wallet and importing keys or addresses, but this limitation was expected to be lifted in the near future. A user inquired about whether the limitation had been lifted and if the feature was considered complete, stating that the disk space reduction was a significant benefit.A user on the Bitcoin-dev mailing list inquired about the status of pruning in the upcoming release of Bitcoin Core version 0.12. Wladimir J. van der Laan confirmed that pruning has been tested for almost half a year and will be included in this release. However, he also noted that users should still backup their wallets as there is always a possibility of issues with syncing between the wallet and blockchain.On January 17, 2016, a preliminary release note for Bitcoin Core version 0.12 was posted on the Bitcoin-dev mailing list. While the main part of the release notes did not mention the re-enabling of the wallet in autoprune feature, one of the pull requests noted that it had been re-enabled. A user on the mailing list asked if pruning was now finished and if it could be safely used as an end-user. They believed that this feature would be one of the most interesting ones for users since it could help fix the issue of taking up too much disk space. The user requested that if pruning was finished, the release notes should mention that and how to enable it.Bitcoin Core version 0.12.0rc1 binaries are now available on the official website of Bitcoin. This is a release candidate for a new major version release that brings new features, bug fixes, and other improvements. The preliminary diff --git a/static/bitcoin-dev/Jan_2016/combined_Capacity-increases-for-the-Bitcoin-system-.xml b/static/bitcoin-dev/Jan_2016/combined_Capacity-increases-for-the-Bitcoin-system-.xml index 794c4be9b5..363cc3cece 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Capacity-increases-for-the-Bitcoin-system-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Capacity-increases-for-the-Bitcoin-system-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Capacity increases for the Bitcoin system. - 2025-09-26T15:29:04.554616+00:00 + 2025-10-11T21:30:31.444736+00:00 python-feedgen Anthony Towns 2016-01-22 09:46:18+00:00 @@ -229,10 +229,11 @@ + 2 Combined summary - Capacity increases for the Bitcoin system. - 2025-09-26T15:29:04.554862+00:00 + 2025-10-11T21:30:31.445010+00:00 2016-01-22T09:46:18+00:00 Recent discussions among Bitcoin developers have centered around the implementation of Segregated Witness (SegWit) in Bitcoin transactions. The focus is on increasing efficiency for pay-to-public-key-hash (p2pkh) transactions. The latest segwit code utilizes "OP_0 [hash]" to push the version and hash separately, resulting in a reduction of 5 bytes per output for p2pkh transactions. This improvement is expected to lead to an increase in p2pkh and multisig transactions.Implementing SegWit would come at a cost, with the scaling factors estimated to be 170% for p2pkh transactions and 250%-300% for multisig transactions. The effective block size for p2pkh with SegWit is estimated to be 1.7MB, while for 2/2 multisig it is 2MB. Additionally, there are two potential soft-fork improvements that could make p2pkh and multisig more space efficient: ECDSA public key recovery and Schnorr signatures.The deployment of SegWit as a hardfork is supported by some defenders as it would solve scalability problems and make Bitcoin more stable. However, they also support the softfork version of SegWit, which is currently available. The plan is to do a softfork first and then a hardfork to move the witness tree outside of the coinbase. This approach is seen as exciting and believed to accelerate the deployment of SegWit.There is a proposal called "Capacity Increases for the Bitcoin System" that aims to solve scalability issues and make Bitcoin more stable. It suggests implementing a soft-fork SegWit 4MB block, which would increase capacity and scalability. Pieter Wuille supports this plan and believes it will improve productivity and the health of the community.Discussions also took place regarding the impact of segwit-spending inputs on block size. Different scenarios were explored, and optimizations were suggested to prevent abuse. There were also discussions on various topics related to Bitcoin development, including modifications to a struct for forward compatibility and moving the height to a more accessible place.The deployment of Segregated Witness (SegWit) via soft fork or hard fork was debated, with differing opinions on the best approach. Some argued that a hard fork would simplify merge-mining and reduce the size of fraud proofs, while others had concerns about security assumptions for non-upgraded clients. The question of whether the current state of affairs is acceptable to heavy users of the Bitcoin network was also raised.Overall, these discussions focused on the potential benefits and implementation of SegWit in Bitcoin transactions. There were debates on the placement of the segwit merkle root and whether a soft fork or hard fork would be more beneficial. The community continues to work towards finding solutions to scale Bitcoin and increase its capacity.In order to increase scalability and capacity, a proposal has been made to implement a soft-fork to Bitcoin. This proposal involves separating signatures from the main block, which would bypass the current blocksize limit and offer other benefits such as enhanced safety and elimination of signature malleability problems. The implementation of this proposal could lead to a 2x capacity increase and make future capacity expansions safer and more efficient.A working implementation of this proposal can be found at https://github.com/sipa/bitcoin/commits/segwit. Additionally, efforts are being made to develop more efficient block relay techniques that would reduce propagation latency. The author also emphasizes the significance of non-bandwidth scaling mechanisms, such as transaction cut-through and bidirectional payment channels, which utilize smart contracts to increase capacity and speed. These approaches have the potential for high capacity and decentralization.There are other proposals being explored, such as flexible caps or incentive-aligned dynamic block size controls, to maintain the alignment of incentives between miners and node operators. The author also highlights the importance of being prepared to implement moderate block size increases when improvements and understanding make their risks widely acceptable compared to the risks of not deploying them.Overall, the author believes that recent progress has positioned the Bitcoin ecosystem well to address its current capacity needs while setting the stage for further improvement and evolution. diff --git a/static/bitcoin-dev/Jan_2016/combined_Fee-smoothing.xml b/static/bitcoin-dev/Jan_2016/combined_Fee-smoothing.xml index b0a76c0c84..4c91af63da 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Fee-smoothing.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Fee-smoothing.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fee smoothing - 2025-09-26T15:28:22.270068+00:00 + 2025-10-11T21:29:48.893948+00:00 python-feedgen Luzius Meisser 2016-01-28 20:16:41+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Fee smoothing - 2025-09-26T15:28:22.270246+00:00 + 2025-10-11T21:29:48.894076+00:00 2016-01-28T20:16:41+00:00 The ongoing debate around Bitcoin block size has sparked discussions among developers about proposed solutions. One developer, Warren Togami Jr., argues against a proposal like BIP100, which allows miners to vote on the block size, stating that it does not align with the marginal cost of the entire network. Instead, he suggests a flex cap mechanism that allows for block size to grow with actual demand and be based on the actual costs of miners. This mechanism can either ensure supply is based on the actual costs of miners or replace the current constant cap with a centrally planned supply curve. Togami believes the former option would lead to a competitive equilibrium with free market prices.Luzius Meisser proposes an idea where only 10% of the collected fees in a block are paid out to the miner, with the remaining 90% added to the collected fees of the next block. This creates a rolling average of collected fees from current and past blocks. However, Togami argues against mandatory sharing, as miners could take payment out-of-band and confirm transactions with little or no visible fees in the block. Meisser also suggests a flex cap solution where miners can buy additional space for an exponentially increasing fee, with the price subtracted from the collected fees and added to the reward of the next block. The amount spent by miners on additional space allows for the calculation of their marginal costs per transaction. Every 1000 blocks, the basic cap is adjusted based on whether the average fees per KB were above or below the global cost estimate.Togami suggests allowing miners to vote on block size, but warns that this could lead to a cartel among miners charging monopoly prices instead of competitive ones. He argues that the transaction fees under BIP100 would be higher than those under a flex cap mechanism based on total marginal costs of miners. He believes a holistic analysis is necessary to understand the benefits of running a full node, and increasing block sizes can make it more attractive to run a full node depending on the circumstances.In an email exchange between Luzius Meisser and Warren, the two discuss the viability of the Flex Cap approach to block size scaling in Bitcoin. Meisser agrees with the approach but emphasizes that it should not rely on significant block subsidies for long-term sustainability. Warren proposes an alternative variant of the approach, allowing miners to pay with a higher difficulty target instead of deferring subsidy to later blocks. The discussion then shifts to the suboptimality of proposals like BIP100, where the block size is subject to a vote by miners. Warren argues that this type of vote only aligns with the miner's marginal cost, rather than the marginal cost to the entire network. He believes the Flex Cap approach is superior because it has an actual cost associated with it and allows block size to grow with actual demand.The proposal of only paying out 10% of collected fees to the miner who mined the block and adding the remaining 90% to the next block's fees is debated. Concerns are raised about miners taking payment out-of-band and creating rules for transactions included in a block. The ongoing research on the Flex Cap approach could provide a viable solution to aligning miner's supply incentives with global marginal costs. Under this approach, block size can burst higher on a per-block basis if the miner is willing to defer a portion of the current block subsidy to later blocks. The proposed flex cap scheme involves miners buying additional space at an exponentially increasing fee, with the price subtracted from collected fees and added to the reward of the next block. The basic cap is adjusted every 1000 blocks based on average fees per KB compared to the global cost estimate.Another proposal to smooth the payout of fees across blocks is discussed among members of the bitcoin-dev community. The idea suggests paying out only 10% of collected fees in a block to the miner and adding the remaining 90% to the collected fees of the next block, creating a rolling average of fees. This proposal aims to reduce the marginal benefit of including additional transactions in a block, aligning incentives of individual miners with the whole network and reducing the disadvantage of mining with a slow connection. However, concerns are raised about increased orphan risk, reduced rewards, and potential incentive problems such as mining empty blocks to minimize the chance of losing fees from previous blocks. One member suggests smoothing fees between the current and subsequent 5 blocks to reduce the incentive for replacing the current tip and conducting out-of-band payments. The Flex Cap approach is also mentioned as a way to align miner's supply incentives with global marginal costs.The author proposes to smooth the payout of fees across blocks, incentivizing decentralization and supporting the establishment of a fee market. This proposal reduces the marginal benefit of including additional transactions in a block, aligns incentives of miners with the whole network, and reduces the disadvantage of mining with a slow connection. It is a step towards a free fee market where prices approach the marginal costs of transactions. However, implementing this proposal may require a hard fork diff --git a/static/bitcoin-dev/Jan_2016/combined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml b/static/bitcoin-dev/Jan_2016/combined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml index c3fc088afd..fd99208134 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Fwd-Wallet-Lock-Unlock-BIP-idea.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fwd: Wallet Lock, Unlock BIP idea - 2025-09-26T15:28:45.532338+00:00 + 2025-10-11T21:30:12.291558+00:00 python-feedgen Scott Morgan 2016-01-14 18:26:57+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Fwd: Wallet Lock, Unlock BIP idea - 2025-09-26T15:28:45.532489+00:00 + 2025-10-11T21:30:12.291679+00:00 2016-01-14T18:26:57+00:00 The writer discusses the importance of wallet encryption and suggests using third-party tools if the encryptwallet feature is not available. They acknowledge that any encryption can be broken but may not be profitable for intruders. The writer also addresses a concern about privacy ethics and proposes obfuscating information through one-way encryption in order to check if a wallet is locked without revealing a list of locked or unlocking wallets easily.The wallet provides encryption support through RPC calls like 'encryptwallet', 'walletpassphrase', and 'walletlock' to ensure that stolen wallet.dat files cannot be accessed without a passphrase. Scott Morgan has proposed a BIP to lock and unlock wallets in Bitcoin, suggesting that users could add an unlock period to their wallet, which would be confirmed like other transactions. Locked wallet transactions would not be confirmed during mining, and users would specify a wallet as unlocking by adding an unlocking date time in the blocks. This proposal differs from bip-0065, which adds a lock time to transactions that recipients must wait for before spending coins.Locking entire wallet addresses indefinitely with a specified unlock period is technically feasible but would have significant implications for the Bitcoin ecosystem. The proposed BIP aims to reduce theft by providing a method to lock and unlock wallets, although it may incur fees and slow down transaction creation and mining. Checking transactions to locked wallets could affect the price of BTC in fiat as the supply changes. Scott Morgan, a Privacy and Java evangelist, does not plan to work on the main bitcoin core but is mining to fund his company's open-source Java projects.Overall, wallet encryption is crucial for protecting wallet.dat files, and the proposed BIP offers a method to lock and unlock wallets, potentially reducing theft. However, implementing this proposal would have significant implications for the Bitcoin ecosystem. diff --git a/static/bitcoin-dev/Jan_2016/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml b/static/bitcoin-dev/Jan_2016/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml index 838132398a..d38a15040b 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Increasing-the-blocksize-as-a-generalized-softfork-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Increasing the blocksize as a (generalized) softfork. - 2025-09-26T15:29:02.440259+00:00 + 2025-10-11T21:30:29.318716+00:00 python-feedgen Luke Dashjr 2016-01-04 21:53:36+00:00 @@ -77,10 +77,11 @@ + 2 Combined summary - Increasing the blocksize as a (generalized) softfork. - 2025-09-26T15:29:02.440434+00:00 + 2025-10-11T21:30:29.318907+00:00 2016-01-04T21:53:36+00:00 The email thread discussed the proposal of using a generalized softfork as an alternative to hard forks. Joe2015 proposed the idea, challenging the assumption that increasing the blocksize limit requires a hardfork. He introduced the concept of standard softforks, where after the fork, two potential chains exist - one valid under the new rules and old rules, and one valid under the old rules only. However, if more than 50% of the hashpower follows the new rules, the old chain is destined to be orphaned.Joe2015 then introduced the idea of a generalized softfork, which involves a transform function f(B)=B' that maps a block valid under the new rules to a block valid under the old rules. In this scenario, three chains may exist - the new chain valid under the new rules only, the mapped chain f(B3), f(B4), f(B5), and the old chain B3', B4', B5', valid under the old rules only. The Segregated Witness was given as an example of a generalized softfork, where the new block format combines the old block and witness data, and the function f() simply removes the witness data to create a valid block under the old rules.The paper then explained how to achieve arbitrary block-size increases through a generalized softfork. This proposal consisted of defining new rules for valid blocks and a transformation function f(). The new block rules were similar to the old rules but with some small changes. The function f() truncated the block so that it contained only the coinbase transaction. By combining these new rules and the transformation function, a generalized softfork could be implemented. This resulted in a new chain under the new rules, including an increased blocksize limit, which could be mapped to a valid chain under the old rules.It was noted that since all mapped blocks were empty, old clients would never see transactions confirming. The paper concluded by highlighting that increasing the blocksize limit is commonly believed to require a hardfork, but this draft demonstrated that it could be achieved using a generalized softfork. The author suggested further exploration of other types of hardforks that can be implemented as generalized softforks and the security implications that come with them. diff --git a/static/bitcoin-dev/Jan_2016/combined_Libconsensus-phase-2.xml b/static/bitcoin-dev/Jan_2016/combined_Libconsensus-phase-2.xml index ae4e00dbd4..f4f7f1d268 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Libconsensus-phase-2.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Libconsensus-phase-2.xml @@ -2,7 +2,7 @@ 2 Combined summary - Libconsensus phase 2 - 2025-09-26T15:28:56.098963+00:00 + 2025-10-11T21:30:22.908174+00:00 python-feedgen Eric Voskuil 2016-01-13 22:47:44+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Libconsensus phase 2 - 2025-09-26T15:28:56.099126+00:00 + 2025-10-11T21:30:22.908370+00:00 2016-01-13T22:47:44+00:00 In an email conversation between Eric Voskuil and Jorge Timón, they discussed the development phases for a public blockchain interface. Timón plans to create a C++ interface that aligns better with Bitcoin Core internals. In the third phase, he aims to refine the storage interface by defining C interfaces using structs of function pointers instead of classes. The goal is to separate the consensus code from chain.o and coins.o so that they are not part of the consensus building package used for libbitcoinconsensus and Bitcoin Core.There was a disagreement between Timón and Luke Dashjr regarding the implementation of libbitcoinconsensus. Dashjr advocated for a storage-dependent version, while Timón believed in implementing both versions - one with a common store implementation and another allowing alternative implementations with custom storage. Timón was concerned that forcing users into a specific uniform storage would limit adoption.In a recent update, Timón shared that the goal for phase 2 of libconsensus encapsulation planning has changed. Instead of exposing only VerifyHeader(), the plan now is to build all the consensus critical code within the existing libconsensus library. This adjustment aims to make the project more feasible for a single Bitcoin Core release cycle. Timón also provided an outline for the upcoming phases, including refining the storage interfaces, renaming files, and making Bitcoin Core use libbitcoinconsensus through its generic C API.Timón discussed how exposing VerifyScript() through a C API solidified dependencies outside of the existing libbitcoinconsensus library. The plan is to gradually move all the necessary files listed in a Github pull request, and Timón encouraged others to get involved in this process.In a mailing list post, Timón further elaborated on the plan to decouple libconsensus from Bitcoin Core. The change in strategy involves building all the consensus critical code within the existing libconsensus library in phase 2. This will simplify the future exposure of VerifyHeader(), VerifyTx(), and VerifyBlock(). The subsequent phases include refining storage interfaces, renaming files, and using libbitcoinconsensus solely through its generic C API in Bitcoin Core.The work in progress branch for the project can be found on GitHub, and Timón intends to create an issue to move the necessary files one by one. They encouraged others to participate in this straightforward task that can be easily executed correctly. diff --git a/static/bitcoin-dev/Jan_2016/combined_New-BIP-editor-and-request-for-information.xml b/static/bitcoin-dev/Jan_2016/combined_New-BIP-editor-and-request-for-information.xml index 3d952f345d..76be2e8643 100644 --- a/static/bitcoin-dev/Jan_2016/combined_New-BIP-editor-and-request-for-information.xml +++ b/static/bitcoin-dev/Jan_2016/combined_New-BIP-editor-and-request-for-information.xml @@ -2,7 +2,7 @@ 2 Combined summary - New BIP editor, and request for information - 2025-09-26T15:28:51.872724+00:00 + 2025-10-11T21:30:18.663705+00:00 python-feedgen Tier Nolan 2016-01-12 00:09:46+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - New BIP editor, and request for information - 2025-09-26T15:28:51.872920+00:00 + 2025-10-11T21:30:18.663837+00:00 2016-01-12T00:09:46+00:00 In an email exchange regarding Bitcoin Improvement Proposal (BIP) 46, Luke Dashjr noticed that it was missing from the repository but had apparently been self-assigned by Tier Nolan in a previous email. Dashjr suggested that if the proposal had been officially assigned or if Nolan was still interested in pursuing it, it would make sense to keep it at BIP 46. However, Nolan responded saying that he was never officially assigned any number for the proposal and subsequent changes made the BIP obsolete.Dashjr then recommended marking the number as nonassignable to prevent confusion with archive searches, assuming that new BIP numbers would be greater than 100 anyway. He also acknowledged that he should not have used a number in the original git branch before being officially assigned it.Luke has been asked to take over as the BIP editor responsible for assigning BIP numbers. Before starting his work, he wants to ensure that there is no overlapping in the assignment of BIPs. He has requested anyone who has been assigned a BIP number or has any relevant information to respond within 24 hours if possible.Luke provided specific details about missing and soft-assigned BIPs. BIP 46 is missing from the repository but was self-soft-assigned by Tier Nolan. It seems logical to keep it at BIP 46. BIPs 80 and 81 are part of an open pull request, and it's unclear whether they were formally assigned or not. BIP 82 is officially assigned and pending, but it falls outside the scope of BIPs since it does not deal with Bitcoin. Luke suggests Justus to move it to the SLIP standard, but he will honor this assignment unless informed otherwise.BIP 100 is missing from the repository, and Luke is unsure if it was ever properly assigned. Considering that the 10x block has mostly been used for similar proposals and BIP 100 is well-established as "BIP 100," it seems logical to make this its official assignment. BIP 104 is missing from the repository, and Luke is unsure about its status. There is no actual specification in the PDF.BIP 109 was soft-assigned, but it does not fit with the rest of 10x. Luke is inclined to give it a new number outside that range unless there are objections. BIP 122 is missing from the repository, and it was self-soft-assigned by Chris Priest for "ScaleNet." There are concerns about whether testnets are appropriate for standardization, but it seems reasonable to assign it a BIP number if Chris wishes to further pursue the idea and add an actual specification to the draft.Luke has requested anyone aware of any other BIP assignments, except for BIPs 82 and 109, and those appearing in the https://github.com/bitcoin/bips repository at present, to reply to his message indicating the status of such BIPs and their assigned numbers. diff --git a/static/bitcoin-dev/Jan_2016/combined_SegWit-GBT-updates.xml b/static/bitcoin-dev/Jan_2016/combined_SegWit-GBT-updates.xml index d68f29722f..0b3944531f 100644 --- a/static/bitcoin-dev/Jan_2016/combined_SegWit-GBT-updates.xml +++ b/static/bitcoin-dev/Jan_2016/combined_SegWit-GBT-updates.xml @@ -2,7 +2,7 @@ 2 Combined summary - SegWit GBT updates - 2025-09-26T15:28:37.069919+00:00 + 2025-10-11T21:30:03.787331+00:00 python-feedgen Luke Dashjr 2016-02-02 02:30:55+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - SegWit GBT updates - 2025-09-26T15:28:37.070061+00:00 + 2025-10-11T21:30:03.787535+00:00 2016-02-02T02:30:55+00:00 The discussion revolves around the inclusion of the "default_witness_commitment" in the standard protocol. One argument against including it is that it may lead to centralization of mining pools and make server-side implementation more susceptible to DoS attacks. However, there is also an argument for including it to simplify initial adoption and have a known-correct value to use. It is mentioned that libblkmaker can handle the heavy lifting for mining software. Ultimately, the decision to include or exclude "default_witness_commitment" depends on the specific implementation and goals.In the email exchange between Luke Dashjr and Cory Fields, they discuss the default witness commitment for GBT (GetBlockTemplate) protocol. Dashjr argues that including it could enable centralization, while Fields suggests that providing a known-working commitment would be beneficial for adoption. Dashjr expresses concerns about security and suggests leaving out the default witness commitment from the standard protocol. Fields seeks clarification on potential DoS vectors and the use of libblkmaker. Dashjr reassures that the burden on mining software is not significant and that libblkmaker can handle the heavy lifting. He also mentions the need to consider the sign bit when serializing heights and the risk of introducing bugs into working code.The conversation on February 1, 2016, between Cory Fields and Luke Dashjr delves into the use of "default_witness_commitment" within the GBT protocol. Dashjr argues against including it in the standard protocol, as it contradicts GBT's design principles by enabling and encouraging centralization. Fields raises the point that providing a known-working commitment can simplify the process. Dashjr acknowledges this but emphasizes the potential for bugs. They also discuss a bug introduced by ckpool, where a positive number was serialized as a signed one.Another discussion between Luke Dashjr and Cory Fields focuses on the omission of the "default_witness_commitment" key in the Bitcoin protocol. Fields believes that omitting it would encourage pools to build their own commitment, while Dashjr argues that it could increase vulnerability to DoS attacks. Dashjr suggests leaving it as a bitcoind-specific extension to promote adoption but recommends keeping it out of the standard protocol for now. Fields expresses concerns about the burden on mining software and the risk of bugs, but Dashjr highlights the capability of libblkmaker to handle the heavy lifting. Fields mentions fixing serialization or commitment creation bugs in mining/pool software.The email conversation discusses the absence of the "default_witness_commitment" key in the current reference implementation. The omission allows clients to create the commitment themselves instead of having it provided. However, this simplicity can encourage laziness and complicate server-side implementation, making it more vulnerable to DoS attacks. The burden on mining software increases, raising the odds of bugs. It is mentioned that serialization or commitment creation bugs related to mining/pool software have already been fixed in SegWit.Luke Dashjr has drafted a BIP for updating getblocktemplate for segregated witness. The draft does not include the "default_witness_commitment" key present in the current reference implementation. This omission allows clients to create their commitment instead of relying on provided values. However, excluding the key increases the burden on mining software and the likelihood of bugs. Cory supports this argument and plans to submit the change to the BIP, enabling mining software to handle more serialization and complex structure calculations. Links to related sources are provided.Luke-jr has announced the creation of an initial draft for a BIP regarding getblocktemplate for segregated witness. The draft is available on GitHub, and Luke-jr invites others to review and comment on the changes made, particularly with regard to sigoplimits handling. However, he notes that libblkmaker's reference implementation is currently incompatible with the "last output" rule in this BIP. Luke-jr expresses gratitude in advance for any feedback received. diff --git a/static/bitcoin-dev/Jan_2016/combined_SegWit-testnet-is-live.xml b/static/bitcoin-dev/Jan_2016/combined_SegWit-testnet-is-live.xml index 8ecec44480..d231229fa9 100644 --- a/static/bitcoin-dev/Jan_2016/combined_SegWit-testnet-is-live.xml +++ b/static/bitcoin-dev/Jan_2016/combined_SegWit-testnet-is-live.xml @@ -2,7 +2,7 @@ 2 Combined summary - SegWit testnet is live - 2025-09-26T15:28:20.156804+00:00 + 2025-10-11T21:29:46.769378+00:00 python-feedgen Jameson Lopp 2016-01-08 15:35:27+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - SegWit testnet is live - 2025-09-26T15:28:20.156936+00:00 + 2025-10-11T21:29:46.769528+00:00 2016-01-08T15:35:27+00:00 BitGo, a digital asset security platform, has successfully implemented Segregated Witness (SegWit) transactions for Bitcoin. They are now waiting for the activation of SegWit on the Bitcoin network before offering support to their customers. Other companies such as BlockCypher and Breadwallet have also committed to supporting SegWit transactions in the near future. SegWit is expected to bring several benefits to the Bitcoin network, including increased capacity and improved transaction malleability.In December 2015, Eric Lombrozo announced the successful running of a segregated witness testnet called segnet. This testnet has rudimentary wallets with support already implemented. Several wallets, including mSIGNA, GreenAddress, GreenBits, Blocktrail, and NBitcoin, have committed to supporting SegWit. Breadwallet has also joined in supporting segwit. More wallets are expected to add their support soon.Interested wallet developers can contact Eric Lombrozo for development and testing on segnet. The source code for segnet can be found at sipa's Github repository, and an example signing code is available at Eric's Github repository. SegWit is expected to enable fundamental improvements to bitcoin, and its implementation is on schedule. diff --git a/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-App-Development.xml b/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-App-Development.xml index c173e2e2c1..95799c8a25 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-App-Development.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-App-Development.xml @@ -2,7 +2,7 @@ 2 Combined summary - Segregated Witness App Development - 2025-09-26T15:28:41.303195+00:00 + 2025-10-11T21:30:08.035569+00:00 python-feedgen Bryan Bishop 2016-01-19 16:31:17+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Segregated Witness App Development - 2025-09-26T15:28:41.303367+00:00 + 2025-10-11T21:30:08.035691+00:00 2016-01-19T16:31:17+00:00 During a discussion on the Bitcoin-dev mailing list, Mark Friedenbach suggested that the discussion about SegWit should be kept within the #bitcoin-dev channel to avoid fragmentation of communication channels. Bryan agreed, stating that although it may be necessary to create a new channel if the discussion becomes overwhelming, it would be preferable to keep it within the existing venue.In response to this, Eric Lombrozo has created a new IRC channel called #segwit-dev. This channel is specifically dedicated to integrating and supporting segregated witness transactions in wallets, as well as providing a platform for comments and suggestions to improve the spec. Eric extended an invitation to all members of the bitcoin-dev community who share the objective of this channel.However, some members expressed concerns about fragmenting the communication channels and associated infrastructure, such as logs and bots. They argued that discussions related to SegWit should take place in the #bitcoin-dev channel instead. Eric has informed the community about the creation of the new IRC channel, #segwit-dev, emphasizing its purpose of discussing segregated witness transactions and soliciting feedback on the spec. He encourages everyone to join the channel and actively participate in the discussions. diff --git a/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-BIPs.xml b/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-BIPs.xml index a81185f5d5..26387edf3b 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-BIPs.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Segregated-Witness-BIPs.xml @@ -2,7 +2,7 @@ 2 Combined summary - Segregated Witness BIPs - 2025-09-26T15:28:32.842024+00:00 + 2025-10-11T21:29:59.527714+00:00 python-feedgen jl2012 2016-01-05 05:43:41+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Segregated Witness BIPs - 2025-09-26T15:28:32.842196+00:00 + 2025-10-11T21:29:59.527855+00:00 2016-01-05T05:43:41+00:00 The Bitcoin Improvement Proposal (BIP) process allows for changes to be suggested and implemented in the Bitcoin protocol. A new BIP has been proposed as part of the Segregated Witness (SegWit) soft fork, specifically addressing a new transaction digest algorithm for signature verification. The goal of this proposal is to minimize redundant data hashing and cover the input value by the signature.In addition to this proposal, a new BIP draft for a SW payment address format has been prepared and is awaiting BIP number assignment. This is the third BIP for SegWit, with another one being prepared by Eric Lombrozo for Peer Services. Eric Lombrozo and jl2012 have been working on these BIPs based on earlier discussions from Pieter Wuille's implementation.There are three separate BIPs being considered: Consensus BIP, Peer Services BIP, and Applications BIP. The Consensus BIP has already been submitted as a draft and covers witness structures, cost metrics and limits, scripting system (witness programs), and the soft fork mechanism. On the other hand, the Peer Services BIP will focus on relay message structures, witnesstx serialization, and other issues related to the p2p protocol such as IBD, synchronization, tx and block propagation. Lastly, the Applications BIP will address scriptPubKey encoding formats and other concerns regarding wallet interoperability.Overall, the development team is actively working on multiple BIPs related to the SegWit implementation, aiming to improve various aspects of the Bitcoin protocol. diff --git a/static/bitcoin-dev/Jan_2016/combined_Segregated-witnesses-and-validationless-mining.xml b/static/bitcoin-dev/Jan_2016/combined_Segregated-witnesses-and-validationless-mining.xml index d15fd1ca79..b2677d3cde 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Segregated-witnesses-and-validationless-mining.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Segregated-witnesses-and-validationless-mining.xml @@ -2,7 +2,7 @@ 2 Combined summary - Segregated witnesses and validationless mining - 2025-09-26T15:29:00.327468+00:00 + 2025-10-11T21:30:27.193657+00:00 python-feedgen Bryan Bishop 2016-01-02 16:54:43+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Segregated witnesses and validationless mining - 2025-09-26T15:29:00.327632+00:00 + 2025-10-11T21:30:27.193796+00:00 2016-01-02T16:54:43+00:00 On December 28th, 2015, an IRC discussion took place regarding various updates related to Bitcoin. The discussion covered topics such as prior-block possession proofs, fraud proofs, non-fraud correctness proofs, commitments, and segwit. Jorge Timón requested a link to the IRC discussion in an email sent on January 2nd, 2016 at 10:37 AM. The email signature included Bryan's personal website and phone number. Peter Todd, a member of the Bitcoin-dev community, posted on January 1, 2016, asking for a link to the IRC discussion. He had previously provided updates from the same discussion in a post on December 22, 2015, but did not include any details about the discussion itself.In the IRC discussion, there was a debate about what should be required from the current block to calculate the previous block possession proof. It was suggested that the nonce could be picked arbitrarily, allowing for future soft-forks to add commitments to the current block contents. Fraud proofs were also discussed, with Pieter Wuille bringing up the idea of structuring the possession proof as a merkle tree to easily prove fraud using a merkle path.Bitcoin developer Peter Todd proposed a solution to return segregated witnesses to the status quo. This solution involves making the previous block's witness data a precondition for creating a block with transactions. This can be achieved by including the previous witness data, hashed with a different hash function than the commitment in the previous block, in the current block's coinbase txouts calculation. However, this solution may face resistance from miners currently using validationless mining techniques. To retain the possibility of validationless mining, empty blocks can be created if the previous witness data proof is omitted.Segregated witnesses separate transaction information from the information proving their legitimacy, making validationless mining more profitable. To address this issue, the protocol can be changed to require a copy of the previous block's witness data as a precondition for creating a block. This soft-fork solution aims to prevent the main code path from creating blocks without any validation. Additionally, it is proposed that adding a random selection of previous blocks to the previous witness data proof solution could address concerns about miner theft and currency inflation.In conclusion, the IRC discussion covered various topics related to Bitcoin, including possession proofs, fraud proofs, commitments, and segwit. Peter Todd proposed a solution to bring segregated witnesses back to the status quo by making the previous block's witness data a precondition for block creation. This solution may face pushback from miners using validationless mining techniques. To address this, empty blocks can be created if the previous witness data proof is omitted. The discussion also explored the potential benefits of validationless mining and solutions to address concerns about miner theft and currency inflation. diff --git a/static/bitcoin-dev/Jan_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml b/static/bitcoin-dev/Jan_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml index 5c2d86666e..c9784fbf87 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Segwit-Upgrade-Procedures-Block-Extension-Data.xml @@ -2,7 +2,7 @@ 2 Combined summary - Segwit Upgrade Procedures & Block Extension Data - 2025-09-26T15:28:43.416465+00:00 + 2025-10-11T21:30:10.168649+00:00 python-feedgen Tier Nolan 2016-02-01 19:29:32+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Segwit Upgrade Procedures & Block Extension Data - 2025-09-26T15:28:43.416608+00:00 + 2025-10-11T21:30:10.168789+00:00 2016-02-01T19:29:32+00:00 On February 1, 2016, Pieter Wuille proposed a second number push in the coinbase scriptSig, which would point to a 32-byte hash H. This push was accepted as it provided a more flexible and compact system than the current one. Concerns were raised about adding arbitrary data, so it was suggested that the data in the coinbase witness stack have a fixed number of entries depending on the block version number. This would allow for soft-forks to add new entries in the stack.Peter Todd discussed upgrade procedures related to segregated witnesses, suggesting the addition of a new service bit or bumping the protocol version. However, this solution did not address the issue of relaying more block data in the future, requiring another soft-fork upgrade. To solve this problem, Todd proposed making the witness data more extensible by using unvalidated block extension data. This involved a backward-incompatible change to the current segwit change, where the coinbase scriptSig would receive a second number push pointing to a 32-byte hash H. Todd also addressed concerns about miners using arbitrary data by suggesting a merkelized key:value mapping with collision-resistant IDs as keys.Pieter Wuille's segwit branch was discussed on the Bitcoin developers mailing list. It was suggested to add a new service bit or bump up the protocol version to only connect to peers with segwit support. The branch had a fHaveWitness flag for each connection, but BIP144 proposed changing this to a service bit. A pull request to change this to a NODE_WITNESS service bit has been made on GitHub.Peter Todd suggested adding a new service bit, NODE_SEGWIT, and/or bumping the protocol version to ensure outgoing peers only connect to peers with segwit support. He also proposed solutions for future upgrades adding new block data, such as removing the restriction on the coinbase witness containing exactly one 32-byte value. Another proposal involved hashing the contents of the coinbase witness as a merkle tree and committing them in place of the current nonce commitment. These proposals were discussed in a pull request on the segwit branch, including the idea of including the merkle path to the segwit data in the coinbase witness.The deployment of segregated witness poses a problem as nodes need witness data to function after activation. If full node adoption lags behind miner adoption, the segwit-supporting P2P network may partition and lose consensus. The issue is not yet fixed in Pieter Wuille's segwit branch, but one solution is to add a new service bit or bump the protocol version to only connect to peers with segwit support. However, if full node operators do not widely adopt segwit, the network could become more vulnerable. Future upgrades will require the relay network to upgrade, and BIP141 suggests an Extensible Commitment Structure to address this. This structure consists of a hashed linked list of consensus-critical commitments, with a redefinable nonce for future soft-forks. To allow for additional data in future soft-forks, the proposal is to remove the restriction on the coinbase witness, hash its contents as a merkle tree, and include that data in the blocksize limit. This allows all nodes to validate the data came from the miner and propagate it without risk of attack. This method is efficient as most future upgrades are expected to be additional commitments, and the additional data for each commitment is just 32 bytes. diff --git a/static/bitcoin-dev/Jan_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml b/static/bitcoin-dev/Jan_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml index 1dd7aba418..f451e3ebf6 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Three-Month-bitcoin-dev-Moderation-Review.xml @@ -2,7 +2,7 @@ 2 Combined summary - Three Month bitcoin-dev Moderation Review - 2025-09-26T15:28:34.955905+00:00 + 2025-10-11T21:30:01.656456+00:00 python-feedgen David Vorick 2016-02-09 23:24:28+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - Three Month bitcoin-dev Moderation Review - 2025-09-26T15:28:34.956074+00:00 + 2025-10-11T21:30:01.656626+00:00 2016-02-09T23:24:28+00:00 The Bitcoin-dev mailing list recently discussed the importance of providing unique and valuable contributions to conversations. Contributors emphasized that comments should contribute to the discussion with technical details or additional relevant data, rather than simply stating agreement with a proposal. The sentiment expressed was that evidence trumps votes, and comments should provide readers with another thing to consider in favor of something beyond just the number of people who support it.In this context, various members of the mailing list shared their opinions. Dave Scotese suggested that contributors should provide additional evidence in favor of something, while Gavin offered his services as a techie and shared information about his projects Litmocracy and Meme Racing. Peter Todd and another member stressed that comments should contribute uniquely to the discussion and not simply repeat what has already been said. They proposed using a "+1" vote with an explanation that provides unique insights to the conversation.Another member, Xor, suggested allowing "+1" votes as long as a technical explanation is provided for why the person agrees. However, Peter Todd disagreed, stating that the explanation should also contribute uniquely to the conversation. Rusty Russell expressed his view that "+1s" on a list are not useful unless they carry additional information. He recommended amending the rules to clarify that "+1s" are not allowed without an explanation.In addition to discussing comments, the mailing list also addressed other issues. Dave Scotese expressed disappointment at the difficulty in accessing moderated messages and suggested having a downloadable version of these messages on the ozlabs website. Rusty Russell explained that the difficulty arises because the messages are forwarded to the bitcoin-dev-moderation mailing list, which strips them out as attachments. Rusty called for volunteers to help develop a filter to address this issue.Furthermore, Rusty Russell raised the question of what moderation should look like going forward. Xor pointed out that the original announcement of moderation had discouraged the use of "+1s" without additional information. Rusty clarified that statements like "I prefer proposal X over Y because..." or "I dislike X because..." carry more weight than simply saying "+1." The discussion highlighted the need for moderation to be information-rich and not solely focused on managing a process of indicating agreement or disagreement.Overall, the Bitcoin-dev mailing list engaged in a thoughtful discussion about the value of comments, the importance of providing unique contributions, and potential improvements to the moderation system. diff --git a/static/bitcoin-dev/Jan_2016/combined_Time-to-worry-about-80-bit-collision-attacks-or-not-.xml b/static/bitcoin-dev/Jan_2016/combined_Time-to-worry-about-80-bit-collision-attacks-or-not-.xml index c850892fa2..4abf2020ec 100644 --- a/static/bitcoin-dev/Jan_2016/combined_Time-to-worry-about-80-bit-collision-attacks-or-not-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_Time-to-worry-about-80-bit-collision-attacks-or-not-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Time to worry about 80-bit collision attacks or not? - 2025-09-26T15:28:58.212997+00:00 + 2025-10-11T21:30:25.070023+00:00 python-feedgen Zooko Wilcox-O'Hearn 2016-01-12 23:22:17+00:00 @@ -117,10 +117,11 @@ + 2 Combined summary - Time to worry about 80-bit collision attacks or not? - 2025-09-26T15:28:58.213185+00:00 + 2025-10-11T21:30:25.070225+00:00 2016-01-12T23:22:17+00:00 Zooko, a contributor to the Bitcoin development mailing list, suggests that the thread is omitting consideration of multi-target attacks. He explains that if an attacker is happy to find a collision with any one out of a large number of potential victims, they get an advantage proportional to the number of potential victims. Therefore, it would be wise to estimate how many public keys will eventually be in use. Zooko recommends a recent blog post by DJB for more information about the "Attacker Economist" approach.It is advised to worry about 80-bit collision attacks as they are likely to cost less than $1 million in the next ten to twenty years. If one agrees to lock up funds with someone else and they control the public key, they become susceptible to these attacks. It is suggested to avoid pay-to-script-hash addresses and instead use payment protocol and "raw" multisig outputs when dealing with significant amounts of money. Alternatively, one can ask for a hierarchical deterministic (BIP32) seed and derive a public key for them to use. To ensure maximum security, one should follow security in depth and validate all input secure coding principles.In an email conversation on January 11, 2016 at 11:57 PM, Tier Nolan corrected an error in a code block on the Bitcoin development mailing list. The original script had a syntax error in the order of the parameters for CHECKSIG and OP_DROP, and Tier Nolan swapped the positions of const_pub_key and prev_hash in the script to correct it.In a discussion on the bitcoin-dev mailing list, Gavin Andresen asked about how long it would take for a 2^84 attack where the work is an ECDSA private to public key derivation. However, another participant in the discussion suggested that the EC multiply may not actually be necessary and proposed using compressed public keys and a sha256 call instead. Gavin Andresen defended the choice of SHA256D over RipeMD160 for an update to the digital currency's software in a Bitcoin developer email thread. He argued that the tradeoff between crypto strength and code complexity is important and that "the strength of the crypto is all that matters" was not security-first. Another developer disagreed and stated that code complexity shouldn't be a concern, but rather the security versus space tradeoff.Peter Todd shared his experience of raising an issue with segregated witnesses on the BIP process in response to a comment by Gavin Andresen. Todd expressed concerns that it could make validationless mining easier and more profitable. The issue was discussed on IRC, and Todd plans to write the code to implement a fix and submit it as a pull-req against the segwit branch.Gavin Andresen proposed eliminating the risk of a potential attack by having only one witness program version in a Bitcoin-dev email thread in 2016. Pieter Wuille disagreed with this suggestion and argued for maintaining Bitcoin's 128-bit security target for witness scripts. The proposal remains under discussion.In an email exchange on January 8, 2016, Gavin Andresen asked if there was a similar attack scheme possible if the network had switched to Schnorr 2-of-2 signatures. However, he quickly corrected himself and acknowledged that the scheme would still work with Schnorr.Gavin Andresen discussed the tradeoff between crypto strength and code complexity in relation to segwitness in an email thread dated January 8, 2016. He highlighted two ways of stuffing the segwitness hash into the scriptPubKey but suggested keeping the design as simple as possible. He admitted that using a 32-byte hash could compromise short-term scalability but believed it was a no-brainer.In a forum thread, Gavin Andresen responded to concerns about the security of Bitcoin's code complexity. He acknowledged the importance of a "security first" mindset but pointed out the tradeoff between crypto strength and code complexity. The message suggests ongoing discussions around the topic of Bitcoin security.Gavin Andresen asked about the timeline for a 2^84 attack on ECDSA private to public key derivation in a message. He also asked about a similar attack scheme assuming the switch to Schnorr 2-of-2 signatures.In an email exchange on the bitcoin-dev mailing list, Gavin Andresen and Pieter Wuille discuss the use of cryptography in Bitcoin. Pieter argues for using better cryptography that is up to par with security standards, while Gavin emphasizes the importance of simplicity and points out the potential vulnerabilities in the scripting language. They also discuss the security of SHA256(SHA256) over RIPEMD160(SHA256) and the implementation of segwit. The discussion revolves around collision attacks and the need for collision security to protect against such attacks. There are concerns about the vulnerability of nested hash construction RIPEMD160(SHA256()) and length extension attacks. Ethan Heilman provides an algorithm that can find targeted substrings and raises concerns about cascading the same hash function twice. The participants also discuss the security diff --git a/static/bitcoin-dev/Jan_2016/combined_What-is-OpenSSL-still-used-for-.xml b/static/bitcoin-dev/Jan_2016/combined_What-is-OpenSSL-still-used-for-.xml index c49a8576ce..162bf36b29 100644 --- a/static/bitcoin-dev/Jan_2016/combined_What-is-OpenSSL-still-used-for-.xml +++ b/static/bitcoin-dev/Jan_2016/combined_What-is-OpenSSL-still-used-for-.xml @@ -2,7 +2,7 @@ 2 Combined summary - What is OpenSSL still used for? - 2025-09-26T15:28:49.757801+00:00 + 2025-10-11T21:30:16.539955+00:00 python-feedgen Wladimir J. van der Laan 2016-01-25 11:58:29+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - What is OpenSSL still used for? - 2025-09-26T15:28:49.757968+00:00 + 2025-10-11T21:30:16.540108+00:00 2016-01-25T11:58:29+00:00 In version 0.12 of Bitcoin, the dependency on OpenSSL for signature validation has been replaced with libsecp256k1. However, OpenSSL is still being used for various other purposes such as random number generation and AES256 encryption of private keys. There are outdated pull requests to remove the OpenSSL dependency for these purposes. It is suggested that OpenSSL be kept as a dependency for SSL/X.509 in the BIP70 payment protocol. The plan is to make OpenSSL a dependency only if the GUI is enabled in the future, with most of the work already done but requiring careful testing and integration.In response to a question from Andrew about why OpenSSL is still being used, the author explains that while OpenSSL has been dropped for ECC signature validation, it is still being used for other crypto functions. Specifically, it is used for getting random numbers to randomize the ECC signing context, AES256 encryption of private keys for wallets, and SSL/X.509 for the BIP70 payment protocol for the GUI. The author suggests that the OpenSSL dependency could be removed for the first two purposes but makes sense to keep it for the BIP70 payment protocol. The author provides links to relevant pull requests related to entropy and AES. The message ends with a PGP signature.In another post on the Bitcoin-dev mailing list, Ethan Heilman asks whether libsecp256k1 is used for all cryptographic functions in Bitcoin. Douglas Roark replies that while libsecp256k1 performs the required elliptic curve operations, OpenSSL is still used for other crypto functions. Roark mentions that libsecp256k1 currently relies on an implementation of RFC 6979 instead of a PRNG, possibly for portability reasons. However, there are still some crypto functions not covered by libsecp256k1 at the API level, and for consensus-critical functionality, OpenSSL will be replaced with libsecp256k1 in the upcoming version 0.12 of Bitcoin.A discussion on the use of libsecp256k1 and OpenSSL in Bitcoin is taking place on the bitcoin-dev mailing list. It is noted that libsecp256k1 is only used for elliptic curve operations required by Bitcoin, while OpenSSL is used for all other cryptography. The use of OpenSSL's PRNG can be seen in the random.h file in the Bitcoin source code. The question arises regarding what other purposes OpenSSL serves if signature validation has been moved to libsecp256k1 in the 0.12 release notes. However, it is not clear from the given context whether a response was provided or not. diff --git a/static/bitcoin-dev/Jan_2016/combined_nSequence-multiple-uses.xml b/static/bitcoin-dev/Jan_2016/combined_nSequence-multiple-uses.xml index 99b69bb573..9ba1cdc325 100644 --- a/static/bitcoin-dev/Jan_2016/combined_nSequence-multiple-uses.xml +++ b/static/bitcoin-dev/Jan_2016/combined_nSequence-multiple-uses.xml @@ -2,7 +2,7 @@ 2 Combined summary - nSequence multiple uses - 2025-09-26T15:28:53.987925+00:00 + 2025-10-11T21:30:20.785675+00:00 python-feedgen Andrew C 2016-01-23 04:41:55+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - nSequence multiple uses - 2025-09-26T15:28:53.988082+00:00 + 2025-10-11T21:30:20.785821+00:00 2016-01-23T04:41:55+00:00 During a Bitcoin-development discussion, Andrew C brought up the topic of using nSequence in Bitcoin transactions for both locktime and opt-in Replace-by-Fee (RBF) signaling. However, he realized that there is currently no way to differentiate between these two uses. In response, Dave explained that while setting nSequence to less than MAX_INT enables locktime enforcement, opting into RBF requires setting it to less than MAX-1. To provide further information, Dave shared a link to Bitcoin Improvement Proposal 125 (BIP125).Andrew then sought clarification on whether there were any plans to change nSequence to allow for distinguishing between the different features of a transaction. He suggested utilizing version bits as a potential solution. diff --git a/static/bitcoin-dev/Jan_2017/combined_A-BIP-for-partially-signed-not-signed-raw-transaction-serialization-would-it-be-useful-.xml b/static/bitcoin-dev/Jan_2017/combined_A-BIP-for-partially-signed-not-signed-raw-transaction-serialization-would-it-be-useful-.xml index e2ce1f1bc1..e6349a65db 100644 --- a/static/bitcoin-dev/Jan_2017/combined_A-BIP-for-partially-signed-not-signed-raw-transaction-serialization-would-it-be-useful-.xml +++ b/static/bitcoin-dev/Jan_2017/combined_A-BIP-for-partially-signed-not-signed-raw-transaction-serialization-would-it-be-useful-.xml @@ -2,7 +2,7 @@ 2 Combined summary - A BIP for partially-signed/not-signed raw transaction serialization; would it be useful? - 2025-09-26T16:04:24.262957+00:00 + 2025-10-11T22:18:36.191631+00:00 python-feedgen 木ノ下じょな 2017-01-10 12:35:07+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - A BIP for partially-signed/not-signed raw transaction serialization; would it be useful? - 2025-09-26T16:04:24.263084+00:00 + 2025-10-11T22:18:36.191809+00:00 2017-01-10T12:35:07+00:00 In January 2017, Jon proposed gathering opinions before submitting a Bitcoin Improvement Proposal (BIP) to address the issue of different methodologies used for serializing partially signed multisig raw transactions. This problem was observed in projects like Electrum, Copay, Coinb.in, and Bitcoin Core. Thomas Kerin recommended that Jon should consider his previous work on a similar BIP for hardware signing and suggested using a protocol for requesting signatures, particularly suitable for BitGo and GreenAddress wallets.The context provided is a PGP public key block, which contains a long string of characters representing the actual public key and metadata about the key. This metadata includes the associated email address, creation date, and algorithm used to generate the key. PGP, or Pretty Good Privacy, is an encryption tool used for secure messaging over the internet. It requires users to generate a key pair consisting of a public and private key. The public key can be shared, while the private key must be kept secret. Messages can be encrypted using the recipient's public key, ensuring only the intended recipient can decrypt and read them.The need for a standardized specification for unsigned transactions arises from the different serialization methodologies used in partially signed multisig raw transactions and not-signed raw transactions across various projects. Jon, known as 木ノ下じょな on bitcoin-dev, has encountered similar issues with multisig support. To eliminate friction caused by these differences, a standardized specification is proposed to ensure consistent serialization of unsigned transactions. The signature section of the transaction should contain all necessary information for making the signature. The proposal aims to have all unsigned transactions follow the same form and be encoded in a way that signing applications can recognize them as unsigned.Prior to proposing a BIP, Jon sought opinions to assess the need for a standardized specification. diff --git a/static/bitcoin-dev/Jan_2017/combined_Anti-transaction-replay-in-a-hardfork.xml b/static/bitcoin-dev/Jan_2017/combined_Anti-transaction-replay-in-a-hardfork.xml index d5e0603b34..f753dc9150 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Anti-transaction-replay-in-a-hardfork.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Anti-transaction-replay-in-a-hardfork.xml @@ -2,7 +2,7 @@ 2 Combined summary - Anti-transaction replay in a hardfork - 2025-09-26T16:04:43.264909+00:00 + 2025-10-11T22:18:53.185553+00:00 python-feedgen Tom Harding 2017-01-27 22:11:02+00:00 @@ -89,10 +89,11 @@ + 2 Combined summary - Anti-transaction replay in a hardfork - 2025-09-26T16:04:43.265094+00:00 + 2025-10-11T22:18:53.185744+00:00 2017-01-27T22:11:02+00:00 The proposal discussed in the given context aims to address the issue of replay attacks during a blockchain split. A replay attack occurs when a transaction is replayed on another network, potentially causing unintended consequences. To prevent this, the proposal suggests implementing anti-replay protection as an optional feature for users on both the existing and new forks.Transactions created before the proposal was made are not protected from anti-replay, as there is no guarantee that the existing fork will survive or retain any value. However, the new fork must accept these transactions. The proposal does not require any consensus changes in the existing network to avoid unnecessary debates.In addition to preventing replay attacks, the proposal also offers a beneficial side effect of fixing a signature checking bug for non-segregated witness inputs. The rules outlined in the proposal ensure that transactions with only the existing network characteristic bit set are invalid in the new network. Time-locked transactions made before the proposal are considered valid in the new network. Conversely, transactions specifically created for the new network are invalid in the existing network.To avoid a replay of such transactions, users should first spend at least one relevant UTXO on the new network, which would invalidate the replay transaction. It is ultimately up to the designer of a hardfork to decide whether or not to implement this proposal.The size of the network characteristic byte is limited to 8 bits, but if certain networks are completely abandoned, the bits may be reused. A demo of the proposal can be found in the forcenet2 branch on GitHub. The proposal should be taken into account when creating hardfork proposals, except for trivial and uncontroversial ones.In an email exchange, Johnson Lau pointed out the difference between an opt-out system and an opt-in system. He argues that an opt-in system would require unmodified yet compatible systems to change in order to support the new network, which is self-defeating. Lau suggests that an opt-out system would make more sense for everyone involved.In another email exchange, the question of whether Alice is protected in a hardfork scenario is discussed. Lau proposes a scenario where Alice pays Bob with an old-style time-locked transaction, and after the hardfork, Bob can confirm the transaction on both networks. However, if Alice has full control, she is already protected by a proposal that does not require any protecting child transactions. If the time-locked transaction is unprotected in a 2-of-2 multisig where Bob receives the payment, Bob will receive all the money from both forks without renegotiation with Alice.In a different email discussion, Lau questions a proposal regarding the replay protection of Bitcoin transactions after a hardfork. He argues that Alice would not hold onto an old-style time-locked transaction if she doesn't control any of the UTXOs and cannot substitute the transaction for one where she does have control. Lau suggests that Bob could still confirm the time-locked transaction on both networks after the hardfork by sending the outputs to himself again with a different transaction format, making it a successful replay.In a separate conversation between Tom Harding and Johnson Lau, they discuss proposals to prevent transaction replay attacks in the event of a chain split. Lau's proposal is an opt-in approach, while Harding suggests a soft fork that supports its own hard-fork opt-out bit. They also discuss the specific changes suggested by Lau's BIP and the need for consensus changes in the existing network. They agree that their proposals are similar but differ in their approach.Overall, the proposal aims to resolve the issue of replay attacks during a blockchain split by implementing optional anti-replay protection and introducing rules for both the existing and new networks. It is important to consider this proposal when creating hardfork proposals to ensure the safety and integrity of transactions. diff --git a/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-Historical-and-future-projections-t-khan-.xml b/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-Historical-and-future-projections-t-khan-.xml index 4c8a42edb6..2b4a61666e 100644 --- a/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-Historical-and-future-projections-t-khan-.xml +++ b/static/bitcoin-dev/Jan_2017/combined_BIP-Block75-Historical-and-future-projections-t-khan-.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP - Block75 - Historical and future projections (t. khan) - 2025-09-26T16:04:26.372883+00:00 + 2025-10-11T22:18:38.323168+00:00 python-feedgen t. khan 2017-01-10 19:09:42+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - BIP - Block75 - Historical and future projections (t. khan) - 2025-09-26T16:04:26.373012+00:00 + 2025-10-11T22:18:38.323322+00:00 2017-01-10T19:09:42+00:00 Recently, there has been a discussion on the bitcoin-discuss mailing list regarding the concept of an adaptive or automatic block size. Ryan J Martin expressed concerns about this approach, stating that it may not consider the optimal economic equilibrium for transaction fees and size. He highlighted the potential negative impact on miners and users if an auto-adjusting size limit is implemented without solid code and a social benefit model in place.In response to this discussion, t.k. proposed a BIP called Block75, which aims to maintain blocks at 75% full. They used the daily average block size over the past year to estimate how Block75 would have altered the maximum block sizes. According to their estimates, if Block75 were activated today, the max block size one year from now would be 2,064KB. However, they acknowledged that this is only an estimate and welcomed alternative ways to model future behavior through the Block75 algorithm.Concerns have been raised that an auto-adjusting size limit could create unforeseen externalities for miners and users. Miners might decide to mine very small blocks to constrict supply and increase marginal fees, while users could push blocks to larger sizes, resulting in higher latency and network issues. To address these concerns, an auto-adjusting limit would require solid code with a social benefit model built-in. This model would aim to adjust to an equilibrium that maximizes benefits and minimizes costs for both miners and users, using a Marshallian surplus model.Meanwhile, the Block75 proposal suggests adjusting the maximum block size based on the average percentage fullness of the last 2016 blocks. This approach aims to keep blocks as small as possible, allow for growth, and maintain transaction fees at a level similar to May/June 2016. The proposal takes into account the substantial increase in transactions expected in the last quarter of 2017 and the changes brought about by SegWit. However, it is important to note that the max block size projections provided by Block75 are estimates, and alternative ways to model future behavior are encouraged to be tested through the Block75 algorithm. diff --git a/static/bitcoin-dev/Jan_2017/combined_Bitcoin-Classic-1-2-0-released.xml b/static/bitcoin-dev/Jan_2017/combined_Bitcoin-Classic-1-2-0-released.xml index 346b45f46c..926ea0baca 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Bitcoin-Classic-1-2-0-released.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Bitcoin-Classic-1-2-0-released.xml @@ -2,7 +2,7 @@ 2 Combined summary - Bitcoin Classic 1.2.0 released - 2025-09-26T16:04:36.918269+00:00 + 2025-10-11T22:18:46.816887+00:00 python-feedgen Chris Priest 2017-01-08 01:58:27+00:00 @@ -65,10 +65,11 @@ + 2 Combined summary - Bitcoin Classic 1.2.0 released - 2025-09-26T16:04:36.918479+00:00 + 2025-10-11T22:18:46.817043+00:00 2017-01-08T01:58:27+00:00 In leaked email conversations from January 7, 2017, members of the bitcoin-dev mailing list discussed concerns about the number of full nodes and the potential control of a majority of them. Eric Lombrozo reminded the group that the mailing list is for discussing new proposals and ideas, not rehashing old discussions. In July 2017, Eric Lombrozo criticized the release announcement of Bitcoin Classic version 1.2.0 for being incompatible with the current Bitcoin network and its consensus rules. He argued that it constituted a hard fork without safe activation and lacked evidence of community-wide consensus. Some members pointed out that Bitcoin Core had also implemented hard forks without activation or public debate.The discussion on the bitcoin-dev mailing list continued with concerns about the control of a majority of full nodes. Eric Voskuil argued that control over a majority of nodes is irrelevant because someone could easily spin up more nodes at a trivial cost. The discussion was redirected to focus on new ideas and proposals.In another email thread, Chris Priest argued that Bitcoin Classic's block format change only affects miners, not nodes or wallets. Others disagreed, stating that a decentralized system should affect everyone. The debate also touched on the potential weakness of the system if a few people control the majority of hashpower.Tom Zander sent an email stating that there is no formal activation threshold in Bitcoin Classic, but some argued that there exists an informal and practical threshold. Zander viewed Bitcoin Classic as a tool for achieving specific ends rather than a solution itself.Bitcoin Classic released version 1.2.0, which included bug fixes, performance improvements, and a decentralized block size solution. However, concerns were raised about the lack of community-wide consensus and clear labeling as a hard fork on mainnet with no safe activation. The release notes and changelog were also lacking in detail.Chris Priest stated that the fact that a few people control 75% of hashpower is a bug, not a feature.The ongoing debate between Bitcoin Classic and SegWit focused on the different approaches to block format changes. Bitcoin Classic required 75% miner adoption for activation, while Eric Lombrozo criticized its lack of compatibility with the current network and consensus rules. Tom Zander announced Bitcoin Classic version 1.2.0, highlighting the decentralized block size solution. Concerns were raised about the lack of community-wide consensus and clear labeling as a hard fork.Eric Lombrozo expressed concern over the clarity and safety of Bitcoin Classic's latest release. The release notes lacked detail, making it difficult for users to understand the changes. Tom Zander responded by stating that Bitcoin Classic is compatible with the current network and consensus rules. However, concerns remained about the lack of transparency and evidence of community-wide consensus for the hard fork.Bitcoin Classic version 1.2.0 was released with new features, bug fixes, and performance improvements. The release aimed to provide a high-quality validating node for various use cases. However, concerns were raised about the lack of community-wide consensus, clear labeling as a hard fork, and the absence of release notes and changelog in the GitHub repository.Members of the mailing list warned against posting release announcements for software that is incompatible with the current Bitcoin consensus rules. Despite this, Bitcoin Classic version 1.2.0 was released, marking a change in strategy for the company. The release included various bug fixes and performance improvements, as well as a decentralized block size solution. Bitcoin Classic aimed to provide users with a high-quality validating node and offered various projects with the beta label. More information about the release and Bitcoin Classic can be found on their GitHub page.In summary, the leaked email conversations highlighted debates about the number of full nodes and control over them. There were criticisms of Bitcoin Classic's release announcement for being incompatible with the current network and lacking community-wide consensus. Concerns were raised about the lack of transparency, clear labeling, and documentation for Bitcoin Classic's hard fork. The ongoing debate between Bitcoin Classic and SegWit centered around different approaches to block format changes. Overall, the cryptocurrency community continues to discuss these issues and the implications for the Bitcoin network.In the latest release, v1.2.0.Classic, Bitcoin users can expect a range of high-quality processes to enhance their experience. This update is designed to provide support and assistance to anyone utilizing Bitcoin. For further insight into this release and the Classic platform, a detailed video can be accessed at the following link: https://vimeo.com/192789752.The v1.2.0.Classic release aims to offer top-notch quality processes that will benefit all Bitcoin users. By implementing these improvements, the developers of Classic seek to provide enhanced functionality and efficiency for individuals involved in Bitcoin transactions. The release focuses on refining existing features and introducing new capabilities to ensure a seamless user experience.To gain a better understanding of the developments within this release, it is recommended to watch the informative video available at the provided link. This video offers diff --git a/static/bitcoin-dev/Jan_2017/combined_Changing-the-transaction-version-number-to-be-varint.xml b/static/bitcoin-dev/Jan_2017/combined_Changing-the-transaction-version-number-to-be-varint.xml index 8fc1f6ebaa..75f1791ef5 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Changing-the-transaction-version-number-to-be-varint.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Changing-the-transaction-version-number-to-be-varint.xml @@ -2,7 +2,7 @@ 2 Combined summary - Changing the transaction version number to be varint - 2025-09-26T16:04:32.710598+00:00 + 2025-10-11T22:18:44.692130+00:00 python-feedgen Johnson Lau 2017-01-26 12:57:32+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Changing the transaction version number to be varint - 2025-09-26T16:04:32.710746+00:00 + 2025-10-11T22:18:44.692268+00:00 2017-01-26T12:57:32+00:00 In January 2017, Tom Zander put forward a proposal to introduce a new transaction format for Bitcoin. The proposal suggested labeling bytes 2, 3, and 4 of the current transaction format as unused from a specific block height. It also recommended interpreting the first byte as varint, and only allowing transactions with a version number of 1 to be valid. However, there were some concerns raised about this proposal.One major issue was that implementing this change would require a hardfork, as existing nodes would not be able to deserialize the transaction. Additionally, it was pointed out that non-version 1 transactions have been permitted since v0.1, and version 2 transactions are already in use due to BIP68. Furthermore, if the proposal only affects network transfer, it would be considered a p2p protocol upgrade rather than a softfork or hardfork.The author of the proposal discusses three ways to introduce new transaction formats: through a softfork, which makes old clients unaware of the new format; through a hardfork, which requires new clients to understand the new format and leaves old clients behind; or p2p only, which has no impact on consensus. Regardless of the chosen method, the proposal states that one can introduce any new format they desire.The author also addresses the current structure of transactions, noting that the version field is always 4 bytes while the rest of the integer encoding is variable-sized. This means that bytes 2, 3, and 4 are typically set to zero. By changing the serialization of the version number to varint, each transaction would save three bytes. These bytes could then be used differently in version 1 transactions or may not be needed at all for newer formats. Another benefit of this change is that all integers in the transaction would follow the same var-int encoding, at least for FlexTrans.At present, there is no consensus rule that rejects transactions which provide false information about their version. Therefore, the proposed rule could only be implemented from a certain block height and would not apply retroactively. The suggested implementation involves labeling bytes 2, 3, and 4 as unused from the specified block height, while interpreting the first byte as varint. Additionally, a new rule would be added to only accept transactions with a version number of 1. This change could be made as a softfork.The author seeks feedback on any potential issues with this proposal. It is also worth noting that although most transactions have bytes 2, 3, and 4 set to zero, there is no transaction version defined that sets them to non-zero. For more details on the proposal, links to the Bitcoin Classic website and the author's blog and vlog are provided at the end of the context.Bitcoin Classic website: [link]Author's blog: [link]Author's vlog: [link] diff --git a/static/bitcoin-dev/Jan_2017/combined_Extension-block-softfork-proposal.xml b/static/bitcoin-dev/Jan_2017/combined_Extension-block-softfork-proposal.xml index 52403763a5..5f15443b79 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Extension-block-softfork-proposal.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Extension-block-softfork-proposal.xml @@ -2,7 +2,7 @@ 2 Combined summary - Extension block softfork proposal - 2025-09-26T16:04:30.600583+00:00 + 2025-10-11T22:18:42.569887+00:00 python-feedgen Matt Corallo 2017-01-28 00:35:55+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Extension block softfork proposal - 2025-09-26T16:04:30.600718+00:00 + 2025-10-11T22:18:42.570020+00:00 2017-01-28T00:35:55+00:00 The email discusses the controversial idea of an extension block, which would allow for more block space through a soft fork. The extension block proposal is seen as coercive because it allows transactions to occur in data that those who choose not to enforce the soft fork's rules have decided to ignore. This makes it difficult to track transaction history and identify risks based on potential censorship-enforced transactions. It also forces the entire network to trust the extension block instead of opting into a soft fork's security.The email argues that this sets a dangerous precedent, as miners may start soft-forking in sidechains, posing a significant risk. Additionally, there is a social cost associated with implementing an extension block. On a different note, the proposal describes a method for sending bitcoins from the main UTXO to an xUTXO, where people can trade inside the xblock just like in the main block.The integration of UTXO and transaction is explained in detail, including special bridging witness programs for returning transactions and fees collection in the xblock. However, sending money back from the xblock to the main block requires 100-block maturity for the returning UTXO, significantly changing the user experience.The proposal raises questions about simplifying the design without compromising security, eliminating the 100-block maturity requirement, and reducing the maturity time. To ensure that the recipient won't be paid with a returning transaction unless explicitly requested, the direction flag is suggested, which may be combined with the serialized witness version to save one byte.Overall, the proposal is presented for discussion on the bitcoin-dev mailing list. It aims to implement extra block space through a soft fork while maintaining existing security assumptions and being transparent to existing wallets. However, new wallets taking advantage of the extra block space will have a different user experience. The proposal defines terminology such as main block/tx/UTXO, extension transaction/block/UTXO, bridging witness program, integrating UTXO/transaction, returning transaction, fees collection in xblock, and xblock commitment.The proposal also acknowledges the challenge of sending money from the side chain to the main chain, but presents solutions to overcome this challenge. It raises questions about simplifying the design, eliminating the 100-block maturity requirement, and reducing the 100-block overkill. diff --git a/static/bitcoin-dev/Jan_2017/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml b/static/bitcoin-dev/Jan_2017/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml index 78778790b7..a36ee08361 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Forcenet-an-experimental-network-with-a-new-header-format.xml @@ -2,7 +2,7 @@ 2 Combined summary - Forcenet: an experimental network with a new header format - 2025-09-26T16:04:45.377016+00:00 + 2025-10-11T22:18:55.311109+00:00 python-feedgen Matt Corallo 2017-01-28 17:14:02+00:00 @@ -85,10 +85,11 @@ + 2 Combined summary - Forcenet: an experimental network with a new header format - 2025-09-26T16:04:45.377203+00:00 + 2025-10-11T22:18:55.311285+00:00 2017-01-28T17:14:02+00:00 The Bitcoin-dev mailing list has been discussing proposals for changes to the Bitcoin protocol. Some of the proposed changes include removing the block size limit, limiting the creation of unspent transaction outputs (UTXOs) and encouraging their spending, and implementing a smoother halving cycle for block rewards. There are also proposals for a new coinbase transaction format and a Merkle sum tree for fraud-proofing.Matt Corallo suggests minimizing header size, having only one merkle tree for transactions, and avoiding variable-length header fields. He also discusses light wallet functionality without an upgrade and the Stratum protocol. Another proposal titled "Client Side Block Filtering" suggests an alternative method of block downloading that allows clients to filter blocks based on specific criteria.Johnson Lau introduces a second version of forcenet with experimental features, including anti-tx-replay and block sighashlimit. The author of the context also creates a second version of forcenet with new experimental features, such as a new header format and anti-tx-replay. There is a discussion about the concept of a sum tree and softfork in Bitcoin, as well as the issue with redefining nSigOp in a sum tree and the proposal to combine the two costs into a unified cost.In December 2016, a discussion took place regarding the use of a timestamp beyond 4 bytes. Luke Dashjr proposed stealing a few bits from the tx nVersion through a softfork as a solution. There were also discussions about the implementation of a new merkle algorithm using a sum tree, communication with legacy nodes, and the possibility of enabling easier soft forks through a bridge node. Suggestions were made to keep hashing to a minimum and to consider an 8-byte timestamp due to the approaching year 2106.Overall, the Bitcoin-dev mailing list concludes that some proposals may not be essential for the hard fork and could be added later through a soft fork. Forcenet, an experimental network, was created to demonstrate a new header format, but some aspects have not yet been implemented. Codes for testing can be found on Github, and joining the network is possible by running "bitcoind --forcenet" and connecting to the node running at 8333.info with the default port. diff --git a/static/bitcoin-dev/Jan_2017/combined_Mutli-push-op-return.xml b/static/bitcoin-dev/Jan_2017/combined_Mutli-push-op-return.xml index c470bd630b..f47b61bfbb 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Mutli-push-op-return.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Mutli-push-op-return.xml @@ -2,7 +2,7 @@ 2 Combined summary - Mutli-push op_return - 2025-09-26T16:04:41.147791+00:00 + 2025-10-11T22:18:51.064750+00:00 python-feedgen Chris 2017-01-09 04:32:53+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Mutli-push op_return - 2025-09-26T16:04:41.147917+00:00 + 2025-10-11T22:18:51.064915+00:00 2017-01-09T04:32:53+00:00 The author of a script wiki is questioning whether multiple pushdatas in op_return would be considered standard. Although the code does not explicitly state that only one pushdata is allowed, the script wiki may not be up to date. The policy.cpp file on Github does not seem to limit the number of pushdatas allowed in op_return. A user named Chris asked if there would be any objections to making op_return outputs with two pushdatas standard, with the same maximum data size. In response, Luke Dashjr stated that standards (BIPs) should describe a specific use case and protocol for implementing such outputs. He also mentioned that most nodes have a default policy that allows them.On January 9, 2017, Chris proposed a question about standardizing op_return outputs with two pushdatas. Luke responded that BIPs should provide a specific use case and protocol for implementation, and most nodes already allow such outputs by default.The proposal aims to make op_return outputs with two pushdatas standard, with the same maximum data size. This is intended to facilitate tagging transactions so they can be returned by bloom filtering nodes. By using the op_return output script, transactions can be easily fetched if their tag matches a specific pattern. It seems that a significant number of nodes and miners already accept such transactions, as the first block was mined using this method. diff --git a/static/bitcoin-dev/Jan_2017/combined_Script-Abuse-Potential-.xml b/static/bitcoin-dev/Jan_2017/combined_Script-Abuse-Potential-.xml index 85577e9e4b..43a52703d0 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Script-Abuse-Potential-.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Script-Abuse-Potential-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Script Abuse Potential? - 2025-09-26T16:04:39.030411+00:00 + 2025-10-11T22:18:48.942091+00:00 python-feedgen Jeremy 2017-01-05 16:22:34+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - Script Abuse Potential? - 2025-09-26T16:04:39.030608+00:00 + 2025-10-11T22:18:48.942222+00:00 2017-01-05T16:22:34+00:00 The bitcoin-dev mailing list is currently engaged in a discussion regarding the controversial opcode OP_CAT. Some members are advocating for a direct limit on OP_CAT, while others prefer a general memory limit. Previously, OP_CAT had a limit of 5000 bytes, but it was disabled by Satoshi on August 15, 2010, and replaced with a limit of 520 bytes. There are concerns that enabling OP_CAT could potentially enable covenants, but some argue that a script with a large number of OP_2DUPs would be more concerning. The MAX_SCRIPT_ELEMENT_SIZE is set at 520 bytes, so the worst-case scenario for a script using OP_CAT would be around 10 MB. The discussion also delves into the memory usage cost of each instruction and the need to reasonably bound it. While there is debate about implementing a general memory limit, some participants argue that it is challenging to create a non-implementation dependent memory limit. The group is striving to find the best approach to prevent future memory-risky opcodes from causing issues.On January 2, 2017, a user named Steve Davis posted a question on the bitcoin-dev mailing list regarding a potential attack vector involving a specific pk_script. Jeremy Rubin responded, stating that the script would not pose a significant threat and the worst it could do is consume approximately 10 MB of memory. Johnson Lau added that a script can only contain up to 201 opcodes, and the maximum size for OP_CAT is set at 520 bytes. On January 3, 2017, Rubin reiterated his view that the elements alpha proposal to reintroduce a limited OP_CAT to 520 bytes sparked controversy. Russell O'Connor further clarified that Satoshi had implemented the OP_CAT limit of 520 bytes on August 15, 2010, when disabling OP_CAT, as the previous limit was 5000 bytes.In summary, the bitcoin-dev mailing list is currently engaged in a discussion about the opcode OP_CAT. The debate revolves around implementing a direct limit or a general memory limit for OP_CAT. Concerns exist regarding the potential enabling of covenants if OP_CAT is enabled. However, some argue that a script with numerous OP_2DUPs poses a more significant concern. The MAX_SCRIPT_ELEMENT_SIZE is set at 520 bytes, limiting the worst-case scenario to approximately 10 MB for a script utilizing OP_CAT. The discussion also touches on the memory usage cost of each instruction and the challenges of establishing a non-implementation dependent memory limit. On January 2, 2017, a user raised a question about a potential attack vector involving a specific pk_script, which Jeremy Rubin and Johnson Lau responded to. Rubin mentioned the controversy surrounding the elements alpha proposal to reintroduce a limited OP_CAT to 520 bytes, while Russell O'Connor clarified Satoshi's implementation of the 520-byte limit when disabling OP_CAT on August 15, 2010. diff --git a/static/bitcoin-dev/Jan_2017/combined_Transaction-Replacement-by-Fee.xml b/static/bitcoin-dev/Jan_2017/combined_Transaction-Replacement-by-Fee.xml index 7765f85a2f..e6719b1958 100644 --- a/static/bitcoin-dev/Jan_2017/combined_Transaction-Replacement-by-Fee.xml +++ b/static/bitcoin-dev/Jan_2017/combined_Transaction-Replacement-by-Fee.xml @@ -2,7 +2,7 @@ 2 Combined summary - Transaction Replacement by Fee - 2025-09-26T16:04:28.488939+00:00 + 2025-10-11T22:18:40.447532+00:00 python-feedgen Andrew 2017-01-28 18:34:58+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Transaction Replacement by Fee - 2025-09-26T16:04:28.489100+00:00 + 2025-10-11T22:18:40.447687+00:00 2017-01-28T18:34:58+00:00 The user in this context is attempting to get RBF (Replace-By-Fee) working on a multisig input. They set the nSequence to 0, but encountered a failure when using python-bitcoinlib to verify the script. The user is using the SignatureHash(...) method for signing instead of rpc.signrawtransaction(...). BIP125 (Bitcoin Improvement Proposal) is mentioned as the standard way to signal and a link to BIP125 is provided for further information. It is noted that some miners mine full replace-by-fee without limitations on nSequence.Peter Todd's implementation of full RBF for v0.13.2 can be found on his Github page. This implementation is identical to Bitcoin Core with the exception of removing nSequence and adding a special service bit to allow full-RBF nodes to preferentially peer with each other for propagation of replacement transactions. While it is faster to use the nSequence signaling specified in BIP-125, it is not mandatory as long as the replacement transaction can reach a full-RBF node. Contact information for Peter Todd is also provided.In a post to the bitcoin-dev mailing list, Greg Sanders explains that BIP125 is the standard way to signal for transaction replacement. The GitHub link provided contains all the necessary information to understand BIP125. Some miners mine full replace-by-fee without limitations on nSequence. Peter Todd's implementation of this feature for v0.13.2 can be found on his GitHub page, which is similar to Bitcoin Core but with the removal of nSequence and the addition of a special service bit for full-RBF node peering. Although using the nSequence signaling in BIP-125 is faster, it is not mandatory if the replacement transaction reaches a full-RBF node.An email thread on the bitcoin-dev mailing list from January 12, 2017, discusses the rules for transaction replacement in Bitcoin. The sender, Police Terror, seeks clarification on the valid ranges for sequence values in transaction inputs and whether it is possible to change outputs or add additional inputs to pay higher fees. The response suggests referencing BIP125 as the standard way to signal for transaction replacement. A GitHub link is provided for further information on BIP125. This email thread serves as a resource for individuals seeking guidance on Bitcoin transaction replacement.The sender of the message is seeking information on transaction replacement rules in Bitcoin. They specifically want to know the valid ranges for sequence values in transaction inputs and if it is possible to change outputs or add more inputs to pay a higher fee. The sender typically sets the sequence value to MAX_UINT32 and locktime to 0. They are looking for clarity on these aspects of Bitcoin and would appreciate any available resources. diff --git a/static/bitcoin-dev/Jan_2018/combined_2-step-confirmation-system.xml b/static/bitcoin-dev/Jan_2018/combined_2-step-confirmation-system.xml index 6d5df81c29..32030a5cfa 100644 --- a/static/bitcoin-dev/Jan_2018/combined_2-step-confirmation-system.xml +++ b/static/bitcoin-dev/Jan_2018/combined_2-step-confirmation-system.xml @@ -2,7 +2,7 @@ 2 Combined summary - 2 step confirmation system - 2025-09-26T15:43:47.344324+00:00 + 2025-10-11T21:54:09.351105+00:00 python-feedgen Weiwu Zhang 2018-01-30 01:23:13+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - 2 step confirmation system - 2025-09-26T15:43:47.344508+00:00 + 2025-10-11T21:54:09.351245+00:00 2018-01-30T01:23:13+00:00 The email thread addresses two major concerns surrounding Bitcoin. The first concern revolves around the fear of losing Bitcoin due to a mistake while entering the recipient's address. To tackle this issue, the suggestion is to have the beneficiary's wallet generate a signed payment request instead of just an address. By doing so, the sender would not be able to generate a payment request for the merchant as they lack the merchant's key. Additionally, another proposed solution involves sending the transaction to the beneficiary through a private channel instead of broadcasting it. In this case, the beneficiary would refrain from broadcasting the transaction if they do not receive the expected payment or if the transaction was not properly constructed according to their preferences. This method also caters to deniable payments. The second concern raised is the desire for a 2-step confirmation system when engaging with unfamiliar individuals. To address this concern, the suggestion is to utilize an escrow system with or without an arbitrator. Without an arbitrator, the resolution of the transaction typically depends on time or revealing a known hash value. With an arbitrator, a secure model can be implemented where a compromised arbitrator is only able to revert transactions and not steal funds. Importantly, none of the proposed methods require any changes to the Bitcoin network or blockchain. Wallet developers have the ability to implement these approaches independently without needing to negotiate with Bitcoin developers.While Bitcoin addresses already have a checksum to minimize input errors, there is still a risk of malware replacing the intended address with one controlled by the malware author. Therefore, verifying the correct address remains a concern. The mention of "bitcoin multisig" and "bitcoin escrow" in a Google search highlights support for these concepts within the core Bitcoin protocol. The individual expressing their concerns suggests that for deals involving less than 100 Bitcoin, it is simpler to use a trusted single-party escrow rather than dealing with the complexities of "2 of 3 multisig". In conversations with non-Bitcoin users, two primary concerns often arise. Firstly, there is a fear of losing Bitcoin if an incorrect address is entered. Secondly, there is a desire for a two-step confirmation system when engaging with unknown parties. The proposed solution involves implementing a two-step system that acts as an escrow, allowing both parties to provide final approval within a specified timeframe. This system could potentially alleviate anxiety surrounding Bitcoin transactions. The author acknowledges that the current forum may not be the ideal platform for discussing these ideas but expresses gratitude for the reader's time. diff --git a/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal-Chaofan-Li-.xml b/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal-Chaofan-Li-.xml index ad4b194c70..6f54cbbce0 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal-Chaofan-Li-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Blockchain-Voluntary-Fork-Split-Proposal-Chaofan-Li-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Blockchain Voluntary Fork (Split) Proposal (Chaofan Li) - 2025-09-26T15:43:45.231497+00:00 + 2025-10-11T21:54:07.218909+00:00 python-feedgen Chaofan Li 2018-01-30 06:20:35+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - Blockchain Voluntary Fork (Split) Proposal (Chaofan Li) - 2025-09-26T15:43:45.231661+00:00 + 2025-10-11T21:54:07.219076+00:00 2018-01-30T06:20:35+00:00 The conversation between ZmnSCPxj and Chaofan centers around the concept of fungibility in paper money and Bitcoin. They discuss how fungibility allows for the exchange of paper money with different denominations, and question whether the same principle applies to bitcoins generated from different blocks. They also ponder if bitcoins from the early blocks mined by Satoshi would have higher value if released. The idea of fungibility having a measurable value is suggested.Fungibility is explained as the principle that ensures indistinguishability in paper money, where a $10 bill is equivalent to ten $1 coins. This principle also applies to cryptocurrencies like bitcoin, thanks to mechanisms such as sidechains, SPV proof-of-work, and drivechain proof-of-voting. However, it is emphasized that proposals need to differentiate themselves from previous ones to avoid confusion.The possibility of eliminating human perception differences in money is discussed. The suggestion is made that wallets and exchanges should only display the total amount of bitcoin, rather than separating them into different types. It is explained that one valid address is automatically valid on both chains, allowing money to be sent through either chain as long as the private key is available. This means there would be no difference in the number of merchants, and exchange costs would be trivial.The conflation of mining difficulty with profitability is highlighted as erroneous. It is argued that profitability is controlled by competition, not difficulty. While the idea of equilibrium is mentioned, it is stated that even a small change in the number of merchants or human perception of money can lead to the elimination of one currency in favor of the other. The exchange cost between two currencies is seen as a disadvantage, making one currency inherently better than two.The discussion on the bitcoin-dev mailing list revolves around the distribution of miners between two similar chains. The argument that miners will be equally distributed based on mining difficulty is criticized. It is explained that mining difficulty only controls block period, not miner return on capital. Profitability is determined by competition, and miners seek the same level of profitability regardless of difficulty. The assumption that both chains have the same initial or final value is deemed unrealistic, as even the smallest change in number of merchants or human perception can lead to one chain being slightly better and gaining dominance.To achieve equilibrium, it is suggested that two chains must have comparable chain generation rates, length, and difficulty. If these conditions are not met, miners will be attracted more easily to the chain that is easier to mine, resulting in a higher chain generation rate. Eventually, equilibrium will be reached.The value of block space in Bitcoin is discussed, with emphasis on miners investing capital based on anticipation of future returns. The relationship between mining power and cryptocurrency value is debated. While one member asserts that the chain with the most mining power will have more value, another member disagrees and suggests that tokens with higher value attract more mining hash rate. This highlights the complex interplay between mining power and cryptocurrency value, which depends on various factors.The conversation also touches upon the question of how to handle mining on each chain. It is mentioned that the chain with more mining power will have greater value. Additionally, the speed and value of a chain will depend on its length, with one chain likely to be longer and faster. The proposal being discussed appears to involve a sidechain with the same protocol. diff --git a/static/bitcoin-dev/Jan_2018/combined_Plausible-Deniability-Re-Satoshilabs-secret-shared-private-key-scheme-.xml b/static/bitcoin-dev/Jan_2018/combined_Plausible-Deniability-Re-Satoshilabs-secret-shared-private-key-scheme-.xml index cf00616e21..936e292aef 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Plausible-Deniability-Re-Satoshilabs-secret-shared-private-key-scheme-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Plausible-Deniability-Re-Satoshilabs-secret-shared-private-key-scheme-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Plausible Deniability (Re: Satoshilabs secret shared private key scheme) - 2025-09-26T15:43:22.154976+00:00 + 2025-10-11T21:54:00.842061+00:00 python-feedgen Peter Todd 2018-01-13 06:11:12+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Plausible Deniability (Re: Satoshilabs secret shared private key scheme) - 2025-09-26T15:43:22.155118+00:00 + 2025-10-11T21:54:00.842219+00:00 2018-01-13T06:11:12+00:00 A member of the Bitcoin development community has suggested that encryption headers for LUKS should be written onto disks, even if they are not used. This suggestion came as part of a challenge to "plausible deniability" designers, with the aim of encrypting a 6 TB disk with pseudorandom bytes and testing what happens when the data is searched at US borders.The challenge is based on the belief that a disk filled with pseudorandom data is not inherently suspicious. Encrypted partitions that are filled and later reformatted will contain random bytes, and modern drives often implement fast secure erasure with encryption, resulting in wiped data becoming random noise. Similarly, software disk encryption schemes fill drives with random noise upon reformatting.The author of the article shares their own practice of immediately 'dd' any new hard disk or decommissioned old one with a pseudorandom byte stream, making it indistinguishable from a disk encryption setup. They challenge plausible deniability designers to 'dd' a 6TB disk with pseudorandom bytes and attempt to walk it across the US border until it gets searched.In response to a comment, the author emphasizes the importance of developing appropriate threat models, keeping security systems confidential, and increasing the popularity of network security systems to reduce suspicion. The only shield against plausibility, according to the author, is not seeming like someone who is likely to have much. Plausible deniability is seen as ineffective against sophisticated adversaries possessing both intelligence and patience.The concept of "plausible deniability" is questioned in relation to devices like Trezor. While the objective of plausible deniability is to present an acceptable alternative while hiding the actual, it can backfire by serving as evidence against the user. In legal scenarios where authorities suspect a user of having more cryptocurrency than disclosed, relying on plausible deniability may result in the user being jailed until they reveal the real password.Information does not exist in isolation, and it is crucial to have a privacy practice that leaves no suspicion of owning any Bitcoin. If a user is known or believed to own large amounts of BTC, their "decoy" wallet may provoke a realistic threat response from adversaries. Plausible deniability schemes can lead to serious consequences, as they may expose traces of other wallets on the computer, and network data could tie one's identity to their wallet.The use of "plausible deniability" is also discussed in the context of Trezor's scheme. Users could face jail time for lying to border security if their alternate passwords based on seeds are brute-forced. While passphrases can be long, most users may not fully grasp the risks involved. Instead of relying on plausible deniability, it is suggested to obviate the need for denial altogether. The post highlights that customs agents have access to cross-correlated analysis data, which could result in prolonged detention while hard drives are examined for evidence linking Trezor apps to known addresses. diff --git a/static/bitcoin-dev/Jan_2018/combined_Suggestion-to-remove-word-from-BIP39-English-wordlist.xml b/static/bitcoin-dev/Jan_2018/combined_Suggestion-to-remove-word-from-BIP39-English-wordlist.xml index cd1d92892a..0623463f95 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Suggestion-to-remove-word-from-BIP39-English-wordlist.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Suggestion-to-remove-word-from-BIP39-English-wordlist.xml @@ -2,7 +2,7 @@ 2 Combined summary - Suggestion to remove word from BIP39 English wordlist - 2025-09-26T15:43:30.530757+00:00 + 2025-10-11T21:54:02.970843+00:00 python-feedgen Alan Evans 2018-01-18 21:29:27+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Suggestion to remove word from BIP39 English wordlist - 2025-09-26T15:43:30.530918+00:00 + 2025-10-11T21:54:02.971010+00:00 2018-01-18T21:29:27+00:00 In a recent email exchange, Matthew Clancy disagreed with the notion that changing or removing a word in a mnemonic phrase is impossible. The argument against it is that the verification of an existing mnemonic requires the list, and altering one word would necessitate an alternative to BIP0039 or a complete change to a new set of 2048 English words. However, Clancy proposed a simple solution: selecting another word not on the 2048 list and agreeing by convention that it represents the same number as 'satoshi' or the original word. This alternative implementation seems feasible.The discussion on the Bitcoin development mailing list revolved around a suggestion to eliminate the word "satoshi" from the BIP39 English wordlist. The concern was that if a malicious third party discovers a word list resembling a seed, they could test every occurrence of "satoshi" to find a lead to a seed. Opponents argued that changing a word or list is impossible since the verification of an existing mnemonic relies on the list. To alter one word, an alternative to BIP0039 or a complete replacement of all the words with a new set of 2048 English words would be needed. One proposal was to use only the most common words that meet the necessary criteria.The suggestion to remove the word "satoshi" from the BIP39 English wordlist stems from the concern that it poses an unnecessary security risk. Malicious third parties could index any discovered word list and test each occurrence of "satoshi" to identify a bitcoin seed, making it easier to exploit. Some argue that the inclusion of the word does not necessarily increase the security threat, as any word list resembling a seed would be tested regardless. Nonetheless, there are supporters who believe removing "satoshi" would be a reasonable improvement. The linked wordlist provides further context.Responding to Ronald van der Meer's suggestion to remove "satoshi" from the BIP39 English wordlist, Weiwu Zhang states that the word's presence does not significantly impact the security threat. If a malicious third party finds a wordlist resembling a seed, they would test it as a bitcoin seed regardless of whether it contains "satoshi". Zhang highlights the risk lies in indexing and testing every occurrence of "satoshi" for a lead to a seed, which can be done by recycling services or through hacked accounts. Consequently, Zhang views the removal of "satoshi" from the wordlist as a reasonable improvement.A Bitcoin developer has proposed removing the word "satoshi" from the BIP39 English wordlist used for generating bitcoin wallet seeds. The suggestion arises from concerns that malicious third parties could exploit the inclusion of "satoshi" to identify a bitcoin seed. However, some argue that the security threat is minimal since determined attackers would attempt to use any word list as a seed, regardless of the presence of "satoshi". The real risk lies in attackers indexing and testing each occurrence of the word to gain access to a bitcoin wallet.Ronald van der Meer, an individual reviewing Bitcoin Improvement Proposals, has recommended removing the word "satoshi" from the BIP39 English wordlist. The objective is to make it less apparent that the phrase represents a bitcoin seed when discovered by malicious third parties. Ronald provides his email, website, Twitter account, and GPG key for secure communication. diff --git a/static/bitcoin-dev/Jan_2018/combined_Transaction-Merging-bip125-relaxation-.xml b/static/bitcoin-dev/Jan_2018/combined_Transaction-Merging-bip125-relaxation-.xml index 7aad9e7e3d..8863c05b0c 100644 --- a/static/bitcoin-dev/Jan_2018/combined_Transaction-Merging-bip125-relaxation-.xml +++ b/static/bitcoin-dev/Jan_2018/combined_Transaction-Merging-bip125-relaxation-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Transaction Merging (bip125 relaxation) - 2025-09-26T15:43:32.644387+00:00 + 2025-10-11T21:54:05.093718+00:00 python-feedgen Moral Agent 2018-01-28 18:08:33+00:00 @@ -89,10 +89,11 @@ + 2 Combined summary - Transaction Merging (bip125 relaxation) - 2025-09-26T15:43:32.644563+00:00 + 2025-10-11T21:54:05.093923+00:00 2018-01-28T18:08:33+00:00 The Bitcoin-dev mailing list has been discussing the possibility of merging multiple unconfirmed transactions. The main objective is to combine these transactions into one, removing unnecessary inputs and change, while ensuring that the merged transaction pays an equal or higher fee compared to the original transactions. However, this is currently not feasible due to the bip125 rule, which requires a significant increase in the feerate for replacement transactions. Some participants in the discussion propose modifying this rule to allow retroactive transaction merging, as it is seen as more practical than appending existing transactions.One concern raised during the discussion is the potential for relay spam and the risk of pushing other users' transactions out of the mempool if transaction merging is allowed. To address this, some suggest that wallets and exchange APIs could collaborate to consolidate in-mempool transactions. Additionally, the complexity involved in implementing smarter types of merging is discussed, along with the need to relax the rules of BIP125 to support this approach if it can be done without introducing risks.The conversation also explores the difficulty of achieving no change when using an intelligent coin selection algorithm to pay for outputs. It is noted that most transactions involve change because inputs rarely match the exact payment amount requested. However, there are ways to optimize coin selection to avoid generating change. Developers Achow101 and Murch have created code for Bitcoin Core that implements an efficient algorithm for finding solutions in these cases.Another point of discussion is the incentive compatibility of BIP125. Some argue that accepting a replacement transaction with a lower fee rate in a competitive mempool may not be rational. Originally, Peter Todd proposed requiring only an increase in fee rate for replacement transactions, but later decided on both a feerate and absolute fee increase criteria for simplicity. Gregory Maxwell clarifies that BIP125 replacement does indeed require an increase in the fee rate, and the confusion arises from the use of the term "original transactions" when there should only be one transaction in the mempool at a time.Overall, the discussion highlights the challenges and feasibility of transaction merging in the mempool. There are varying opinions on modifying the rules of BIP125 to allow for retroactive transaction merging, with concerns about potential DoS vectors and the displacement of other transactions in the mempool. The difficulty of achieving no change with intelligent coin selection algorithms is also discussed, along with the need for a clear understanding of the incentive compatibility of BIP125 replacement. Currently, there is no direct method to track merged transactions when a replaced transaction gets confirmed after a new one has been created to achieve the same goal. Although merging multiple unconfirmed transactions could result in significant savings, finding a viable solution remains an ongoing challenge. diff --git a/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml b/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml index 17e8565650..d1c372a68d 100644 --- a/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml +++ b/static/bitcoin-dev/Jan_2022/combined_-dlc-dev-CTV-dramatically-improves-DLCs.xml @@ -2,7 +2,7 @@ 2 Combined summary - [dlc-dev] CTV dramatically improves DLCs - 2025-09-26T16:02:53.432662+00:00 + 2025-10-11T22:17:00.563236+00:00 python-feedgen Jeremy 2022-01-28 16:53:40+00:00 @@ -18,10 +18,11 @@ + 2 Combined summary - [dlc-dev] CTV dramatically improves DLCs - 2025-09-26T16:02:53.432791+00:00 + 2025-10-11T22:17:00.563431+00:00 2022-01-28T16:53:40+00:00 In an email thread on the Bitcoin-dev mailing list, Thibaut Le Guilly responds to Lloyd Fournier regarding the use of CTV in the Discreet Log Contract (DLC) protocol. Thibaut agrees that CTV could simplify the protocol but raises the possibility of using the CHECKSIGFROMSTACK opcode instead. He suggests that this opcode would allow for requiring an oracle signature over the outcome without any special tricks or the need for the oracle to release a nonce in advance. However, he admits that he hasn't thoroughly studied covenant opcodes yet.Jeremy, another participant in the discussion, replies to Thibaut's message. He acknowledges that CSFS might have independent benefits in general but points out that in this specific case, CTV is only being used in the user-generated mapping of Oracle result to Transaction Outcome. Jeremy adds that if Thibaut comes up with something CSFS-based for the Oracles, it would be complimentary to the current usage of CTV.Jonas Nick chimes in by thanking Thibaut for proposing the interesting application of OP_CTV. However, Jonas mentions that this particular use case doesn't necessarily require OP_CTV and can also be achieved through other covenant constructions such as ANYPREVOUT-based covenants. These alternative constructions offer similar benefits. Specifically, the script of the Taproot leaves can be set to CHECKSIGVERIFY CHECKSIGVERIFY, where the creation of signatures has minimal computational cost. The downside of this approach is the additional overhead of 64 witness bytes compared to CTV.Overall, the email thread discusses the potential use of OP_CTV and alternative covenant constructions for DLCs. It explores the advantages and considerations of each approach, highlighting the potential benefits and trade-offs associated with different opcode choices. diff --git a/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml b/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml index 6f979c4051..052916d246 100644 --- a/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml +++ b/static/bitcoin-dev/Jan_2022/combined_CTV-BIP-review.xml @@ -2,7 +2,7 @@ 2 Combined summary - CTV BIP review - 2025-09-26T16:02:55.549094+00:00 + 2025-10-11T22:17:02.687787+00:00 python-feedgen Billy Tetrud 2022-01-21 17:36:13+00:00 @@ -54,10 +54,11 @@ + 2 Combined summary - CTV BIP review - 2025-09-26T16:02:55.549266+00:00 + 2025-10-11T22:17:02.687935+00:00 2022-01-21T17:36:13+00:00 In a recent discussion about the activation method for Bitcoin Improvement Proposal (BIP) 8 and BIP 9/ST, there was disagreement over how these proposals should be characterized. The main point of contention was whether activation required majority hash power support or not. BIP9/ST requires this support, while BIP8 does not. Billy Tetrud pointed out factual errors in LukeJr's statements about BIP8 and agreed with Michael that the discussion should be kept separate from the BIPs themselves. Tetrud suggested that BIPs should only mention what types of activation methods are possible, without advocating for any specific method.Billy Tetrud thanked Eric Lombrozo for correcting the factual errors regarding BIP8 and ST activation methods in an email exchange. While characterizing BIP8 and ST as BIP9-based or not is subjective, the central issue remains whether activation requires majority hash power support or not. The conversation on activation methods should be separate from advocating for specific methods in BIPs to reduce noise in conversations.The Bitcoin-dev mailing list had a discussion about the legal definition of covenant, which led to Jeremy expressing annoyance. In response, aj proposed a more useful definition of covenant within the context of Bitcoin. According to aj, a covenant is when the scriptPubKey of an unspent transaction output (utxo) restricts the scriptPubKey in the outputs of a transaction that spends that utxo. aj clarified that CTV and TLUV have this type of restriction, while CSV and CLTV do not. They also mentioned that "checksig" could potentially be considered a covenant if the signature used in checksig is in the scriptPubKey. The discussion also covered several topics related to BIPs and their implementation, including the burden placed on full BIP implementation, the use of Eltoo-like protocols, implementing OP_CAT or OP_SHA256STREAM in Bitcoin, language cleanups, and the review of CTV BIP.In an email thread regarding the review of CTV BIP, Michael Folkson requested Eric and Luke to refrain from discussing activation methods for future soft forks on a thread for CTV BIP review. He explained that the discussion for Taproot activation was kept separate until there was overwhelming community consensus. Eric and Luke disagreed with Michael's statements about backward compatibility of unenforced soft forks and chain splits. They argued that soft forks do not produce a chain split themselves but can disrupt if miners cause a split. However, Michael maintained that without majority hash power enforcement, soft forks are not backward compatible. There was also a disagreement between Eric and Luke about the definition of backward compatibility and the use of BIP8 for Taproot activation.In another discussion on the Bitcoin-dev mailing list, Jeremy Rubin expressed skepticism about using BIPs for specific use cases for CTV. Alex suggested having explicit application notes to provide details on how CTV can be used in specific applications while making it clear that they are not part of CTV itself. Luke Dashjr provided a detailed review of the CTV BIP, expressing concerns about its readiness and suggesting alternative approaches for certain use cases.Jeremy Rubin thanked Luke Dashjr for his review of CTV and mentioned plans for language cleanups. While he agreed with the need for BIPs for specific use cases, he was skeptical about the overall approach and suggested reviewing application-focused posts and creating a BIP describing how to build something similar to Sapio to help users think through compiling to CTV contracts. Luke Dashjr disagreed with Rubin's viewpoint, stating that CTV is not yet ready and that BIP 9 has known flaws. He questioned why congestion-controlled transactions had not been considered and suggested using Speedy Trial instead of BIP 9 for future deployments. He also discussed limitations of CHECKTEMPLATEVERIFY and proposed alternatives.Luke Dashjr and Eric Voskuil had a discussion about the compatibility of soft forks with the Bitcoin consensus protocol. Dashjr argued that soft forks are not backward compatible without hash power enforcement, while Voskuil disagreed, stating that enforcement is by users, not miners. There was a disagreement about BIP8 achieving consensus for Taproot activation, with Michael Folkson calling it a misleading statement and accusing Eric of deception.The email thread discussed the review of CTV, focusing on technical aspects. The author emphasized that personal or legal attacks on developers would not sway their opinion. They agreed with some nitpicks mentioned in the email and expressed a desire to see fully implemented BIPs before activation. They strongly opposed using BIP9, believing it to be flawed and representing an attempt to impose developer will over community consensus. The author suggested directing other technical comments to Jeremy or someone else as their research was ongoing. The email ended with the author's contact information.Eric at voskuil.org stated that the only significant difference between BIP9 and BIP8 is whether activation requires majority hash power support or not. Soft forks are diff --git a/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml b/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml index 413e8a2ca4..b7bdcc5624 100644 --- a/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml +++ b/static/bitcoin-dev/Jan_2022/combined_Stumbling-into-a-contentious-soft-fork-activation-attempt.xml @@ -2,7 +2,7 @@ 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2025-09-26T16:02:57.671138+00:00 + 2025-10-11T22:17:04.812249+00:00 python-feedgen Billy Tetrud 2022-02-22 12:57:15+00:00 @@ -86,10 +86,11 @@ + 2 Combined summary - Stumbling into a contentious soft fork activation attempt - 2025-09-26T16:02:57.671335+00:00 + 2025-10-11T22:17:04.812443+00:00 2022-02-22T12:57:15+00:00 In a recent discussion about Bitcoin scaling, there was disagreement over whether it should be done rapidly or not. Some argue that scaling should not be delayed to keep fees high, suggesting that if higher fees are needed, the block size can be lowered or the default minimum relay fee rate increased. They also question the belief that the Lightning Network is the main cause of low fees and argue that delaying scaling would harm Bitcoin's growth.On the other hand, others argue that new use cases for on-chain transactions may compete with existing users for limited blockchain space. This situation has been compared to the saying "nobody goes there anymore, it's too crowded." The discussion also touched upon the issue of invoking Satoshi's opinions in present-day discussions. One participant objected to assumptions about the founder of Bitcoin, arguing that Satoshi is more than just a pseudonym and will live on forever. However, another participant objected to the invocation of Satoshi in general, suggesting that if he wants to participate in Bitcoin development today, he can speak for himself. They added that if Satoshi refuses to participate, his opinion is irrelevant. In an email exchange posted on a Bitcoin forum, Prayank objects to ZmnSCPxj's invocation of Satoshi, stating that he cares about Satoshi's opinions, especially regarding subsidies. ZmnSCPxj counters by arguing that if Satoshi refuses to participate in Bitcoin development today, it doesn't matter what his opinion is. He asserts that Satoshi is dead and Bitcoin lives on without him. Prayank objects to this assumption, insisting that Satoshi is more than just a pseudonym and will live on forever. Both parties acknowledge that they are considering the various arguments being presented.In another post, ZmnSCPxj mentions that improvements like the Taproot upgrade can reduce activity on the blockchain and increase functionality without requiring an increase in block size. The Taproot upgrade offers features such as Schnorr multisignatures, MAST, `SIGHASH_ANYPREVOUT`, and `OP_CTV`, which reduce block size usage for complex contracts, enable offchain updateable multiparty cryptocurrency systems, and allow transactional cut-through without immediate output publication. ZmnSCPxj believes that these upgrades enhance Bitcoin's functionality and provide opportunities to use the blockchain in a different way.There is also a discussion about the expansion of use-cases in Ethereum potentially harming Bitcoin by fueling future contentious blocksize debates due to high on-chain fees. However, the counterargument is that fees will be the incentives for miners as subsidy decreases, and it will depend on the demand for block space. Additionally, if this is the reason to stop or delay improvements in Bitcoin, it may apply to Taproot as well. A proposal for a lightning-compatible mimblewimble+dandelion on-chain soft fork is mentioned as a way to reduce transaction size, improve privacy, and move more small transactions off-chain. However, it is suggested that this should not be released for another two years as timing is crucial for Bitcoin innovation.Furthermore, there is a discussion about the lack of compelling use-cases beneficial to all users, with some shared use cases being considered too narrow. The Drivechains use-case is deemed harmful to the security of Bitcoin as a whole. It is argued that the new uses for on-chain transactions mentioned as a use-case could harm existing users by competing for limited blockchain space. As a result, it is concluded that any core consensus changes to the Bitcoin system must be carefully evaluated against the risks.In the Bitcoin developer community, there is a debate about the readiness and potential risks of implementing the proposed consensus change known as OP_CTV. Some developers argue for its activation in a few months, while others express skepticism and call for more testing and research. Other soft fork proposals, such as BIP 118 focusing on eltoo payment channels, are also discussed. Concerns are raised about rushing through consensus changes without thorough examination and community support. Skeptics emphasize the need for technical discussions and engagement to address potential issues. Despite differing opinions, there is a general agreement that implementing a soft fork within the next few months is feasible with proper precautions. The discussion highlights the importance of responsible decision-making and avoiding contentious activation attempts. IRC workshops on BIP 119 are mentioned as a resource for engaging with skeptics on technical concerns. diff --git a/static/bitcoin-dev/Jan_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Jan_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 8cb796f4d1..6820f6c122 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -2,7 +2,7 @@ 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:32:01.400338+00:00 + 2025-10-11T21:57:33.414711+00:00 python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -81,10 +81,11 @@ + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:32:01.400541+00:00 + 2025-10-11T21:57:33.414924+00:00 2023-03-13T16:38:25+00:00 On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to diff --git a/static/bitcoin-dev/Jan_2023/combined_Pseudocode-for-robust-tail-emission.xml b/static/bitcoin-dev/Jan_2023/combined_Pseudocode-for-robust-tail-emission.xml index be4651c1fe..bb68128a7a 100644 --- a/static/bitcoin-dev/Jan_2023/combined_Pseudocode-for-robust-tail-emission.xml +++ b/static/bitcoin-dev/Jan_2023/combined_Pseudocode-for-robust-tail-emission.xml @@ -2,7 +2,7 @@ 2 Combined summary - Pseudocode for robust tail emission - 2025-09-26T14:32:16.319577+00:00 + 2025-10-11T21:57:35.542686+00:00 python-feedgen jk_14 at op.pl 2023-02-01 22:04:11+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - Pseudocode for robust tail emission - 2025-09-26T14:32:16.319747+00:00 + 2025-10-11T21:57:35.542866+00:00 2023-02-01T22:04:11+00:00 In a recent discussion on the bitcoin-dev mailing list, user John Tromp clarified a statement about transaction reward fees. The original claim stated that the current total reward per transaction was $63, which is three orders of magnitude higher than typical fees. However, Tromp corrected this by stating that the reward is actually only two orders of magnitude higher than current fees, which are typically over $0.50. He emphasized the importance of not exaggerating the difference.The issue of difficulty adjustment and halving in Bitcoin mining was also discussed. A conservative approach was proposed to address the problem of hashing power dropping without an average price increase within four years. This approach suggests accepting a drop in hashrate without executing any halving and waiting for the hashrate to recover, even if it takes 20 years. This would lead to the lowest possible annual inflation set by a free market. Peter Todd responded to this proposal, expressing concerns about the immediate danger of halving. He pointed out that profit margins tend towards marginal costs rather than total costs, resulting in hashing power being shut down and fees increasing dramatically, causing disruptions to many aspects, including Lightning channels.There was further discussion on the security of Bitcoin currency. Coinbase was mentioned as behaving more like a bank, and there was a mention of a nostr bot that does block updates without factoring in Coinbase. The amount of security provided by fees and coinbase rewards was debated, with fees currently making up about 13% of miner revenue. The worst-case scenario of the first global hashrate regression taking place in 2028 was also mentioned. Various proposals were made to regulate the level of taxation of parties involved and fix global hashrate regression if it occurs. The motivation of an attacker was considered, with an upper bound of approximately $350 billion. The possibility of the fee market growing superlinearly in comparison to market cap was also discussed, which would make high levels of security more realistic. The issue of deflation in Bitcoin and its differences from gold or other commodities was examined.In another discussion on the bitcoin-dev mailing list, the topic of security and fees was raised. Currently, around 13% of miner revenue comes from fees, with the majority of security coming from coinbase rewards. The question was posed regarding what size of threat would require additional security measures. Estimates were made, placing an upper bound of $350 billion per year at risk if governments viewed Bitcoin as a threat to their currencies. The cost to purchase a 50% share of bitcoin miners was estimated to be less than $7 billion, with a potential price of $800,000 per bitcoin needed to support $350 billion in security. However, if fees alone cannot maintain sufficient security, there is still time to address the issue. The importance of avoiding long-term global hashrate regression for the store of value feature was also discussed.The security of Bitcoin is currently ensured by inflation of ~1.8% and fees paid to miners. Options such as adjusting the subsidy or block size to attract more or fewer miners were suggested if fees alone are not enough to maintain security. Deflation in Bitcoin was noted to be different from gold, and a drop in network security could have complex repercussions. The difficulty-security relationship becomes less predictable over time, making it challenging to code for violations of security targets. One proposal suggests periodically adjusting the subsidy up or down through a soft or hard fork using an algorithm that calculates the average difficulty of the last 100 retargets every 210,000 blocks and compares it with the maximum of all previous values. This system waits for the recovery of network security in the case of a destructive halving and cannot be manipulated.A proposal to delay Bitcoin halving in case of a sudden drop in mining difficulty was deemed insufficient by Billy Tetrud. He argued that it wouldn't detect simple difficulty stagnation or correct the cause of hashrate decline. Tetrud proposed a change that happens in a fork every 10-30 years, where the cost in Bitcoin of the security target and acquiring a unit of hashrate would be used to calculate the necessary difficulty to maintain system security. The subsidy or block size could be adjusted to attract more or fewer miners. Another proposal by Jaroslaw involved calculating the average difficulty of the last 100 retargets and comparing it with the maximum of all previous averages before executing halving. This ensures the system cannot be manipulated and waits for network security recovery in case of destructive halving. The issue of deflation in Bitcoin and its complex nature was also discussed, considering the mechanisms of monetary inflation.A proposal has been put forward to enhance the security of the Bitcoin network by introducing a new approach. This proposal suggests using a chainwork parameter instead of the current method to ensure the network's security and prevent free riders. The chainwork difference between the beginning and end of the last 210,000 block interval will be compared to previous inter-halving intervals, making it the diff --git a/static/bitcoin-dev/Jan_2024/combined_Future-of-the-bitcoin-dev-mailing-list.xml b/static/bitcoin-dev/Jan_2024/combined_Future-of-the-bitcoin-dev-mailing-list.xml index 66f6569840..7f90be8937 100644 --- a/static/bitcoin-dev/Jan_2024/combined_Future-of-the-bitcoin-dev-mailing-list.xml +++ b/static/bitcoin-dev/Jan_2024/combined_Future-of-the-bitcoin-dev-mailing-list.xml @@ -2,7 +2,7 @@ 2 Combined summary - Future of the bitcoin-dev mailing list - 2025-09-26T14:19:32.607455+00:00 + 2025-10-11T21:28:51.502969+00:00 python-feedgen Brad Morrison 2024-01-04 13:50:51+00:00 @@ -109,10 +109,11 @@ + 2 Combined summary - Future of the bitcoin-dev mailing list - 2025-09-26T14:19:32.607648+00:00 + 2025-10-11T21:28:51.503169+00:00 2024-01-04T13:50:51+00:00 The Linux Foundation's mailing lists, primarily running on an outdated Mailman version, necessitate migration or upgrade. Nostr is proposed as a replacement due to its decentralized nature, potentially through a custom Nostr Improvement Proposal (NIP) for relay functions. diff --git a/static/bitcoin-dev/Jan_2025/combined_UTXO-checkpoint-transactions.xml b/static/bitcoin-dev/Jan_2025/combined_UTXO-checkpoint-transactions.xml index df7be47652..202e7b060c 100644 --- a/static/bitcoin-dev/Jan_2025/combined_UTXO-checkpoint-transactions.xml +++ b/static/bitcoin-dev/Jan_2025/combined_UTXO-checkpoint-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - UTXO checkpoint transactions - 2025-09-26T14:22:38.659387+00:00 + 2025-10-11T21:40:16.064755+00:00 python-feedgen Erik Aronesty 2025-01-28 17:34:00+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - UTXO checkpoint transactions - 2025-09-26T14:22:38.659514+00:00 + 2025-10-11T21:40:16.064911+00:00 2025-01-28T17:34:00+00:00 In a recent discussion on the Bitcoin Development Mailing List, a novel proposal was introduced by Eric Voskuil regarding the potential implementation of UTXO checkpoint transactions within the Bitcoin network. The primary aim of this suggestion is to enhance the synchronization process for extremely lightweight nodes, which could significantly benefit from an expedited syncing mechanism without the need to rely heavily on traditional methods that demand considerable resources and time. diff --git a/static/bitcoin-dev/July_2012/combined_Accepting-broken-QRcodes.xml b/static/bitcoin-dev/July_2012/combined_Accepting-broken-QRcodes.xml index fe67aa631f..b6daab2e97 100644 --- a/static/bitcoin-dev/July_2012/combined_Accepting-broken-QRcodes.xml +++ b/static/bitcoin-dev/July_2012/combined_Accepting-broken-QRcodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Accepting broken QRcodes - 2023-08-01T03:47:35.790177+00:00 + 2025-10-11T21:50:41.032319+00:00 + python-feedgen Gary Rowe 2012-07-16 09:32:32+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Accepting broken QRcodes - 2023-08-01T03:47:35.790177+00:00 + 2025-10-11T21:50:41.032513+00:00 - The Bitcoin-development mailing list recently had a discussion about the issue of Bitcoin URIs starting with 'bitcoin://' and the need for adherence to Bitcoin Improvement Proposal (BIP) compliance. It was noted that this URI format does not make much sense as there is no hierarchy in Bitcoin, and it goes against the flat nature of the system. The problem with accepting broken URLs is that people may never fix them, leading to fragmented de-facto standards.Andreas Schildbach shared his concern about Ben's use of QR codes that social networks cannot parse without '://' in them. He initially asked Ben to fix this issue, but when Ben stopped responding, Schildbach went ahead and added support for reading these types of URLs to bitcoinj. However, Schildbach worries that accepting broken URLs without any promise of fixing them at the source could lead to a fragmented de-facto standard.Gary Rowe suggested having more people email Ben to politely request compliance with BIP. Wladimir questioned whether Ben was the only one using broken URLs, as it seemed to be widespread already. The conversation emphasized the importance of maintaining BIP compliance and avoiding broken windows.The thread also included a link to an upcoming Live Security Virtual Conference discussing security and threat landscape changes, and how IT managers can respond. This highlights the ongoing efforts within the Bitcoin community to address issues related to interoperability and compliance.In summary, the discussion on the Bitcoin-development mailing list focused on the issue of broken Bitcoin URIs and the need for adherence to BIP compliance. Andreas Schildbach expressed concern about Ben's use of QR codes without '://' in them, and went ahead to add support for reading these types of URLs to bitcoinj. However, there are concerns about the potential fragmentation of standards if broken URLs are accepted without a commitment to fixing them. The importance of adhering to community standards and maintaining interoperability was emphasized throughout the conversation. 2012-07-16T09:32:32+00:00 + The Bitcoin-development mailing list recently had a discussion about the issue of Bitcoin URIs starting with 'bitcoin://' and the need for adherence to Bitcoin Improvement Proposal (BIP) compliance. It was noted that this URI format does not make much sense as there is no hierarchy in Bitcoin, and it goes against the flat nature of the system. The problem with accepting broken URLs is that people may never fix them, leading to fragmented de-facto standards.Andreas Schildbach shared his concern about Ben's use of QR codes that social networks cannot parse without '://' in them. He initially asked Ben to fix this issue, but when Ben stopped responding, Schildbach went ahead and added support for reading these types of URLs to bitcoinj. However, Schildbach worries that accepting broken URLs without any promise of fixing them at the source could lead to a fragmented de-facto standard.Gary Rowe suggested having more people email Ben to politely request compliance with BIP. Wladimir questioned whether Ben was the only one using broken URLs, as it seemed to be widespread already. The conversation emphasized the importance of maintaining BIP compliance and avoiding broken windows.The thread also included a link to an upcoming Live Security Virtual Conference discussing security and threat landscape changes, and how IT managers can respond. This highlights the ongoing efforts within the Bitcoin community to address issues related to interoperability and compliance.In summary, the discussion on the Bitcoin-development mailing list focused on the issue of broken Bitcoin URIs and the need for adherence to BIP compliance. Andreas Schildbach expressed concern about Ben's use of QR codes without '://' in them, and went ahead to add support for reading these types of URLs to bitcoinj. However, there are concerns about the potential fragmentation of standards if broken URLs are accepted without a commitment to fixing them. The importance of adhering to community standards and maintaining interoperability was emphasized throughout the conversation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Announcement-libcoin.xml b/static/bitcoin-dev/July_2012/combined_Announcement-libcoin.xml index 8ec33e056b..3481fa26b3 100644 --- a/static/bitcoin-dev/July_2012/combined_Announcement-libcoin.xml +++ b/static/bitcoin-dev/July_2012/combined_Announcement-libcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.669593+00:00 + 2025-10-11T21:51:06.569983+00:00 + python-feedgen Martinx - ジェームズ 2012-09-12 23:27:32+00:00 @@ -207,13 +208,13 @@ - python-feedgen + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.670592+00:00 + 2025-10-11T21:51:06.570172+00:00 - In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, 2012-09-12T23:27:32+00:00 + In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_BIP-22-getmemorypool.xml b/static/bitcoin-dev/July_2012/combined_BIP-22-getmemorypool.xml index ecb822e67e..fb75112233 100644 --- a/static/bitcoin-dev/July_2012/combined_BIP-22-getmemorypool.xml +++ b/static/bitcoin-dev/July_2012/combined_BIP-22-getmemorypool.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 22 - getmemorypool - 2023-08-01T03:51:17.533139+00:00 + 2025-10-11T21:50:32.534660+00:00 + python-feedgen Gregory Maxwell 2012-07-30 20:32:25+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP 22 - getmemorypool - 2023-08-01T03:51:17.533139+00:00 + 2025-10-11T21:50:32.534809+00:00 - In 2012, a Bitcoin Improvement Proposal (BIP) discussion arose regarding the need to split BIP into three separate proposals. This request came from Luke-jr to Amir Taaki, as other developers believed that the original proposal was too broad and covered multiple topics. The conversation took place on a mailing list, with some encouragement on IRC to push Luke-jr towards dividing the proposal. Pieter expressed objections to certain optional parts of the specification, and breaking it up would allow for their removal. It was suggested that further discussion could take place if anyone else had objections or missed the initial conversation.Amir Taaki, a British-Iranian programmer and Bitcoin developer, shared a link to the Bitcoin Improvement Proposal (BIP) 0022 on July 30, 2012. BIPs are technical documents outlining proposed changes or improvements to the Bitcoin network. Specifically, this BIP focused on the "getwork" protocol used by Bitcoin miners to request new blocks for solving. In his message, Taaki mentioned that the Pooled Mining sections of the original BIP had been relocated to a new page on the Bitcoin wiki, providing a link for easy access. This reorganization aimed to streamline the information and enhance its accessibility and comprehension for both developers and users. Overall, Taaki's message served as a simple announcement about the change in the location of Bitcoin mining-related information, accompanied by a helpful link to the relevant BIP on the Bitcoin wiki.The author of the message sought input from others regarding a proposal to split BIP 22 into three separate proposals. This suggestion stemmed from concerns that the original BIP lacked focus and covered too many topics. Although the author acknowledged that the discussion took place on IRC instead of the specified mailing list as per BIP 1, they were unsure if there had been any discussion about BIP 22 on the mailing list. Thus, the author sought input before granting permission to trim down the proposal. Admitting limited knowledge of mining, the author invited others to share their thoughts on the proposed split. The provided link directed users to Bitcoin Improvement Proposal (BIP) 22 on the Bitcoin wiki for further reference. 2012-07-30T20:32:25+00:00 + In 2012, a Bitcoin Improvement Proposal (BIP) discussion arose regarding the need to split BIP into three separate proposals. This request came from Luke-jr to Amir Taaki, as other developers believed that the original proposal was too broad and covered multiple topics. The conversation took place on a mailing list, with some encouragement on IRC to push Luke-jr towards dividing the proposal. Pieter expressed objections to certain optional parts of the specification, and breaking it up would allow for their removal. It was suggested that further discussion could take place if anyone else had objections or missed the initial conversation.Amir Taaki, a British-Iranian programmer and Bitcoin developer, shared a link to the Bitcoin Improvement Proposal (BIP) 0022 on July 30, 2012. BIPs are technical documents outlining proposed changes or improvements to the Bitcoin network. Specifically, this BIP focused on the "getwork" protocol used by Bitcoin miners to request new blocks for solving. In his message, Taaki mentioned that the Pooled Mining sections of the original BIP had been relocated to a new page on the Bitcoin wiki, providing a link for easy access. This reorganization aimed to streamline the information and enhance its accessibility and comprehension for both developers and users. Overall, Taaki's message served as a simple announcement about the change in the location of Bitcoin mining-related information, accompanied by a helpful link to the relevant BIP on the Bitcoin wiki.The author of the message sought input from others regarding a proposal to split BIP 22 into three separate proposals. This suggestion stemmed from concerns that the original BIP lacked focus and covered too many topics. Although the author acknowledged that the discussion took place on IRC instead of the specified mailing list as per BIP 1, they were unsure if there had been any discussion about BIP 22 on the mailing list. Thus, the author sought input before granting permission to trim down the proposal. Admitting limited knowledge of mining, the author invited others to share their thoughts on the proposed split. The provided link directed users to Bitcoin Improvement Proposal (BIP) 22 on the Bitcoin wiki for further reference. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_BIP-34-Block-v2-Height-in-Coinbase.xml b/static/bitcoin-dev/July_2012/combined_BIP-34-Block-v2-Height-in-Coinbase.xml index 6436de51f8..12acea11ad 100644 --- a/static/bitcoin-dev/July_2012/combined_BIP-34-Block-v2-Height-in-Coinbase.xml +++ b/static/bitcoin-dev/July_2012/combined_BIP-34-Block-v2-Height-in-Coinbase.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 34: Block v2, Height in Coinbase - 2023-08-01T03:44:42.661705+00:00 + 2025-10-11T21:51:00.191877+00:00 + python-feedgen Gregory Maxwell 2012-07-06 20:10:42+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BIP 34: Block v2, Height in Coinbase - 2023-08-01T03:44:42.661705+00:00 + 2025-10-11T21:51:00.192018+00:00 - On July 6, 2012, Gavin Andresen and an unknown individual discussed issues related to Bitcoin Improvement Proposal (BIP) 30. The individual suggested non-backwards incompatible means to solve duplication issues in BIP 30, such as mandating that a transaction refers to the first unspent pair. However, it was noted that BIP 30 only prevents the identified "really evil outcome" of duplication but does not prevent duplication itself. Rolling out the height before the BIP 30 change was considered but deemed vulnerable to rewrites, prompting the urgent implementation of the BIP 30 change.In an email exchange between Mark Friedenbach, Jeff Garzik, and Peter Vessenes, concerns were raised about non-unique transactions in Bitcoin. The existing setup without height in coinbase could lead to problems requiring workarounds and special cases. Mark proposed a solution to mandate that a transaction refers to the first unspent pair. This email thread highlights the challenges and potential solutions for dealing with non-unique transactions in Bitcoin.Bitcoin Improvement Proposal 30 (BIP 30) mandates that a new block must refer to the first unspent transaction output. This change enhances security and addresses potential future problems. It also allows developers to test using block/transaction version numbers for smooth rollout of changes, providing time to fix any arising issues. Furthermore, it simplifies determining whether an orphan chain can be part of the main chain. Overall, this change improves security and offers long-term benefits to the Bitcoin network.On July 6, 2012, Jeff Garzik and Peter Vessenes discussed a proposal related to miners. Vessenes expressed concern about adding too many requirements to the coinbase and requested further discussion on the topic. Garzik explained that without the proposed change, there may not be unique transactions and provided a link to Gavin's notes on upgrades and BIP16 lessons-learned. Vessenes thanked Garzik for the information, concluding the conversation.Another discussion between Jeff Garzik and Peter Vessenes on July 6, 2012, revolved around a proposal to add the block height to the coinbase of Bitcoin blocks. Vessenes questioned the necessity of this change and expressed concerns about overburdening the coinbase. Garzik argued that without adding the block height to the coinbase, unique transactions could be compromised. However, another participant in the discussion suggested solving these issues through non-backwards incompatible means, such as mandating that a transaction refers to the first unspent pair.In an email thread, Peter Vessenes raised questions regarding the proposal to add height in coinbase for ensuring unique transactions. He expressed worries about burdening the coinbase and called for further discussion on the topic. Jeff Garzik responded by highlighting the potential issues with non-unique transactions without including height in coinbase and shared a link to Gavin's notes on upgrades and BIP16 lessons-learned.Peter Vessenes questioned the proposal for Block v2, Height in Coinbase, requesting more discussion and reasons for making this change. He expressed concerns about imposing too many requirements on the coinbase and sought clarification on the benefits of the proposal. Jeff Garzik shared a link to the BIP 0034 wiki page, which introduces an upgrade path for versioned transactions and blocks. The proposal aims to clarify the mechanism of network consensus for upgrading transaction or block binary structures, rules, and behaviors. It also enforces block and transaction uniqueness and assists unconnected block validation. The specification includes treating transactions with a version greater than 1 as non-standard, adding height as the first item in the coinbase transaction's scriptSig, and increasing the block version to 2. Two rules, the 75% rule and the 95% rule, are outlined for rejecting invalid version 2 blocks. The proposal maintains backward compatibility, and miners are recommended to upgrade to version 2 blocks.Bitcoin Improvement Proposal 34 (BIP: 34), created by Gavin Andresen on July 6, 2012, introduces an upgrade path for versioned transactions and blocks. The proposal adds a unique nonce to newly produced coinbase transactions and updates blocks to version 2. Its goals include clarifying the mechanism of network consensus for upgrading transaction or block binary structures, rules, and behaviors, enforcing block and transaction uniqueness, and assisting unconnected block validation. The specification treats transactions with a version greater than 1 as non-standard and includes adding height as the first item in the coinbase transaction's scriptSig, as well as increasing the block version to 2. The format of the height uses serialized CScript, with the first byte indicating the number of bytes in the number, followed by the little-endian representation. The proposal also outlines the 75% rule and the 95% rule for rejecting invalid version 2 blocks. Backward compatibility is maintained, ensuring no impact on users and merchants. However, miners are strongly advised 2012-07-06T20:10:42+00:00 + On July 6, 2012, Gavin Andresen and an unknown individual discussed issues related to Bitcoin Improvement Proposal (BIP) 30. The individual suggested non-backwards incompatible means to solve duplication issues in BIP 30, such as mandating that a transaction refers to the first unspent pair. However, it was noted that BIP 30 only prevents the identified "really evil outcome" of duplication but does not prevent duplication itself. Rolling out the height before the BIP 30 change was considered but deemed vulnerable to rewrites, prompting the urgent implementation of the BIP 30 change.In an email exchange between Mark Friedenbach, Jeff Garzik, and Peter Vessenes, concerns were raised about non-unique transactions in Bitcoin. The existing setup without height in coinbase could lead to problems requiring workarounds and special cases. Mark proposed a solution to mandate that a transaction refers to the first unspent pair. This email thread highlights the challenges and potential solutions for dealing with non-unique transactions in Bitcoin.Bitcoin Improvement Proposal 30 (BIP 30) mandates that a new block must refer to the first unspent transaction output. This change enhances security and addresses potential future problems. It also allows developers to test using block/transaction version numbers for smooth rollout of changes, providing time to fix any arising issues. Furthermore, it simplifies determining whether an orphan chain can be part of the main chain. Overall, this change improves security and offers long-term benefits to the Bitcoin network.On July 6, 2012, Jeff Garzik and Peter Vessenes discussed a proposal related to miners. Vessenes expressed concern about adding too many requirements to the coinbase and requested further discussion on the topic. Garzik explained that without the proposed change, there may not be unique transactions and provided a link to Gavin's notes on upgrades and BIP16 lessons-learned. Vessenes thanked Garzik for the information, concluding the conversation.Another discussion between Jeff Garzik and Peter Vessenes on July 6, 2012, revolved around a proposal to add the block height to the coinbase of Bitcoin blocks. Vessenes questioned the necessity of this change and expressed concerns about overburdening the coinbase. Garzik argued that without adding the block height to the coinbase, unique transactions could be compromised. However, another participant in the discussion suggested solving these issues through non-backwards incompatible means, such as mandating that a transaction refers to the first unspent pair.In an email thread, Peter Vessenes raised questions regarding the proposal to add height in coinbase for ensuring unique transactions. He expressed worries about burdening the coinbase and called for further discussion on the topic. Jeff Garzik responded by highlighting the potential issues with non-unique transactions without including height in coinbase and shared a link to Gavin's notes on upgrades and BIP16 lessons-learned.Peter Vessenes questioned the proposal for Block v2, Height in Coinbase, requesting more discussion and reasons for making this change. He expressed concerns about imposing too many requirements on the coinbase and sought clarification on the benefits of the proposal. Jeff Garzik shared a link to the BIP 0034 wiki page, which introduces an upgrade path for versioned transactions and blocks. The proposal aims to clarify the mechanism of network consensus for upgrading transaction or block binary structures, rules, and behaviors. It also enforces block and transaction uniqueness and assists unconnected block validation. The specification includes treating transactions with a version greater than 1 as non-standard, adding height as the first item in the coinbase transaction's scriptSig, and increasing the block version to 2. Two rules, the 75% rule and the 95% rule, are outlined for rejecting invalid version 2 blocks. The proposal maintains backward compatibility, and miners are recommended to upgrade to version 2 blocks.Bitcoin Improvement Proposal 34 (BIP: 34), created by Gavin Andresen on July 6, 2012, introduces an upgrade path for versioned transactions and blocks. The proposal adds a unique nonce to newly produced coinbase transactions and updates blocks to version 2. Its goals include clarifying the mechanism of network consensus for upgrading transaction or block binary structures, rules, and behaviors, enforcing block and transaction uniqueness, and assisting unconnected block validation. The specification treats transactions with a version greater than 1 as non-standard and includes adding height as the first item in the coinbase transaction's scriptSig, as well as increasing the block version to 2. The format of the height uses serialized CScript, with the first byte indicating the number of bytes in the number, followed by the little-endian representation. The proposal also outlines the 75% rule and the 95% rule for rejecting invalid version 2 blocks. Backward compatibility is maintained, ensuring no impact on users and merchants. However, miners are strongly advised - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Bitcoin-Wallet-for-Android.xml b/static/bitcoin-dev/July_2012/combined_Bitcoin-Wallet-for-Android.xml index 066ef8f515..9cef3be664 100644 --- a/static/bitcoin-dev/July_2012/combined_Bitcoin-Wallet-for-Android.xml +++ b/static/bitcoin-dev/July_2012/combined_Bitcoin-Wallet-for-Android.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Wallet for Android - 2023-08-01T03:45:37.223750+00:00 + 2025-10-11T21:51:04.438957+00:00 + python-feedgen Gregory Maxwell 2012-07-09 14:12:11+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Wallet for Android - 2023-08-01T03:45:37.223750+00:00 + 2025-10-11T21:51:04.439121+00:00 - In an email thread from July 9, 2012, Gregory Maxwell expressed his concerns and actions regarding some additions made to a page. He removed the proprietary software section, a plug for blockchain.info webservices, and demoted the armory client. However, he left the android software because its source was available and had been reviewed. Maxwell also stated his criteria for listing software on the page. He believed that anything with a security model weaker than SPV should not be listed unless users could operate their own servers. Furthermore, only thin clients with a near SPV security model should be included in the list. If a server component is present in thin clients, it should be subjected to independent review. In the future, actual evidence of third-party review should exist for any software to be listed on the page.A user named Ben Reeves requested the inclusion of blockchain.info iPhone app on the clients page. The source code for this app is available under an lGPL license, which can be reviewed using https://github.com/blockchain/My-Wallet-iPhone. Additionally, the JavaScript web front end could be reviewed by using a combination of https://github.com/blockchain/My-Wallet and https://github.com/blockchain/My-Wallet-Integrity-Checker. However, Gregory Maxwell objected to including any non-reviewable client options, including centrally operated web services, on the clients page. He reverted the additions to the page and suggested that it needs to be discussed along with establishing requirements. The email was sent to the Bitcoin-development mailing list.On July 9, 2012, Amir Taaki raised concern about a recent addition to the clients page. The condition for any client to be listed on the page was that its source code should be available for review and users must be able to run it from the source code. However, Amir could not find the source code for the new client. As a result, the addition was reverted. The author of the email expressed strong opposition to including any non-reviewable client options or centrally operated web services on the page. He believed that this issue needed to be discussed alongside establishing requirements.In a discussion on proprietary software bitcoin clients, Jorge Timón expresses concern about their trustworthiness and whether or not they should be promoted on the web. He questions the potential for back doors and other hidden issues. Another participant in the discussion agrees and notes that while open-source software doesn't necessarily guarantee safety, standards of review and testing would be ideal but currently unrealistic.The conversation is about whether or not to promote bitcoin web wallets. The concern is that the wallets could contain a backdoor or other vulnerabilities, which could lead to hacking and negative media attention. The mention of "two-inch newspaper titles" suggests that the potential impact of such an event could be significant. It seems that the participants in the conversation are aware of past shortcuts taken by journalists, indicating some mistrust of media coverage regarding bitcoin security.The topic being discussed is the trustworthiness of proprietary software bitcoin clients. It is questioned if people should trust them and if the web should promote them, as they may contain a backdoor or other vulnerabilities. Andreas Schildbach suggests adding two links for each client - one for getting the binary and the other for getting the source code. Mats provides a link to the source code for Bitcoin Wallet for Android. Amir Taaki had previously suggested that all clients on the clients page must have the entire source code available for review, otherwise there should be a separate section for non-opensource clients. The email chain ends with Jorge Timón's name.The Bitcoin developers were discussing the addition of two links for each client - one for getting the binary and one for getting the source. On July 9, 2012, Amir Taaki saw that there was a section added for proprietary clients and asked if anything looked disagreeable. Mats provided the sources for the Bitcoin Wallet for Android on Google Code. Amir then asked if the source code for this client was available for review since it needed to be available for all clients on the website. Otherwise, a separate section for non-opensource clients should be created. The email also includes a link to a Live Security Virtual Conference which will cover topics related to security and threat landscape changes.Amir Taaki, a contributor to Bitcoin development, has raised questions about the availability of source code for a client on the clients page. He notes that one of the conditions for being on that page is that all clients must have their entire source code available for review and users should be able to run it from the source code. He was unable to find the source code for this particular client and suggests creating a separate section for non-open source clients if the source code cannot be made available. The email was sent to the Bitcoin-development mailing list.In a conversation between Amir Taaki and Harald, the former inquired about the availability of source code for a client. Harald confirmed that the code was available for review on 2012-07-09T14:12:11+00:00 + In an email thread from July 9, 2012, Gregory Maxwell expressed his concerns and actions regarding some additions made to a page. He removed the proprietary software section, a plug for blockchain.info webservices, and demoted the armory client. However, he left the android software because its source was available and had been reviewed. Maxwell also stated his criteria for listing software on the page. He believed that anything with a security model weaker than SPV should not be listed unless users could operate their own servers. Furthermore, only thin clients with a near SPV security model should be included in the list. If a server component is present in thin clients, it should be subjected to independent review. In the future, actual evidence of third-party review should exist for any software to be listed on the page.A user named Ben Reeves requested the inclusion of blockchain.info iPhone app on the clients page. The source code for this app is available under an lGPL license, which can be reviewed using https://github.com/blockchain/My-Wallet-iPhone. Additionally, the JavaScript web front end could be reviewed by using a combination of https://github.com/blockchain/My-Wallet and https://github.com/blockchain/My-Wallet-Integrity-Checker. However, Gregory Maxwell objected to including any non-reviewable client options, including centrally operated web services, on the clients page. He reverted the additions to the page and suggested that it needs to be discussed along with establishing requirements. The email was sent to the Bitcoin-development mailing list.On July 9, 2012, Amir Taaki raised concern about a recent addition to the clients page. The condition for any client to be listed on the page was that its source code should be available for review and users must be able to run it from the source code. However, Amir could not find the source code for the new client. As a result, the addition was reverted. The author of the email expressed strong opposition to including any non-reviewable client options or centrally operated web services on the page. He believed that this issue needed to be discussed alongside establishing requirements.In a discussion on proprietary software bitcoin clients, Jorge Timón expresses concern about their trustworthiness and whether or not they should be promoted on the web. He questions the potential for back doors and other hidden issues. Another participant in the discussion agrees and notes that while open-source software doesn't necessarily guarantee safety, standards of review and testing would be ideal but currently unrealistic.The conversation is about whether or not to promote bitcoin web wallets. The concern is that the wallets could contain a backdoor or other vulnerabilities, which could lead to hacking and negative media attention. The mention of "two-inch newspaper titles" suggests that the potential impact of such an event could be significant. It seems that the participants in the conversation are aware of past shortcuts taken by journalists, indicating some mistrust of media coverage regarding bitcoin security.The topic being discussed is the trustworthiness of proprietary software bitcoin clients. It is questioned if people should trust them and if the web should promote them, as they may contain a backdoor or other vulnerabilities. Andreas Schildbach suggests adding two links for each client - one for getting the binary and the other for getting the source code. Mats provides a link to the source code for Bitcoin Wallet for Android. Amir Taaki had previously suggested that all clients on the clients page must have the entire source code available for review, otherwise there should be a separate section for non-opensource clients. The email chain ends with Jorge Timón's name.The Bitcoin developers were discussing the addition of two links for each client - one for getting the binary and one for getting the source. On July 9, 2012, Amir Taaki saw that there was a section added for proprietary clients and asked if anything looked disagreeable. Mats provided the sources for the Bitcoin Wallet for Android on Google Code. Amir then asked if the source code for this client was available for review since it needed to be available for all clients on the website. Otherwise, a separate section for non-opensource clients should be created. The email also includes a link to a Live Security Virtual Conference which will cover topics related to security and threat landscape changes.Amir Taaki, a contributor to Bitcoin development, has raised questions about the availability of source code for a client on the clients page. He notes that one of the conditions for being on that page is that all clients must have their entire source code available for review and users should be able to run it from the source code. He was unable to find the source code for this particular client and suggests creating a separate section for non-open source clients if the source code cannot be made available. The email was sent to the Bitcoin-development mailing list.In a conversation between Amir Taaki and Harald, the former inquired about the availability of source code for a client. Harald confirmed that the code was available for review on - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Bitcoin-script-opcode-counts.xml b/static/bitcoin-dev/July_2012/combined_Bitcoin-script-opcode-counts.xml index 98296a8595..e2906aae57 100644 --- a/static/bitcoin-dev/July_2012/combined_Bitcoin-script-opcode-counts.xml +++ b/static/bitcoin-dev/July_2012/combined_Bitcoin-script-opcode-counts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin script opcode counts - 2023-08-01T03:50:23.957978+00:00 + 2025-10-11T21:50:38.909461+00:00 + python-feedgen Gregory Maxwell 2012-07-26 12:50:14+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Bitcoin script opcode counts - 2023-08-01T03:50:23.957978+00:00 + 2025-10-11T21:50:38.909617+00:00 - In a discussion thread from 2012, Mike Hearn expressed his curiosity about the use of OP_DEPTH and OP_CODESEPARATOR in Bitcoin scripts. Specifically, he wanted to see transaction IDs that were utilizing these opcodes. However, it was later discovered that all instances of OP_DEPTH were actually errors in P2Pool blocks. This was due to a bug in the software, which had been making small payments to scriptpubkey "script" unknowingly. The reason this went unnoticed for some time was because it was initially assumed to be an intentional action by a user utilizing p2sh.To fulfill the requestor's curiosity, Jeff Garzik, an American software developer associated with exMULTI, Inc., conducted a comprehensive query over the entire blockchain to inspect script opcode usage. This analysis has been made publicly available on GitHub. The query counted the number of times each opcode was used, providing data for both the main blockchain and testnet3.The data shared on GitHub by Jeff Garzik provides a detailed breakdown of how many times each opcode was used in the blockchain. The information is presented in an organized chart that lists all opcodes and their corresponding count numbers. Overall, there were 26 different opcodes used in the blockchain. The opcode with the highest frequency of use was OP_CHECKSIG, which had a count of 12,188,693. OP_DUP followed closely behind with a count of 11,699,991. While some opcodes like OP_4 and OP_NOP1 had minimal use, others like OP_PUSHDATA had a relatively high count of 32,350,369.In addition to sharing the data, Jeff Garzik also mentions his association with exMULTI, Inc. and provides his email address for further communication. 2012-07-26T12:50:14+00:00 + In a discussion thread from 2012, Mike Hearn expressed his curiosity about the use of OP_DEPTH and OP_CODESEPARATOR in Bitcoin scripts. Specifically, he wanted to see transaction IDs that were utilizing these opcodes. However, it was later discovered that all instances of OP_DEPTH were actually errors in P2Pool blocks. This was due to a bug in the software, which had been making small payments to scriptpubkey "script" unknowingly. The reason this went unnoticed for some time was because it was initially assumed to be an intentional action by a user utilizing p2sh.To fulfill the requestor's curiosity, Jeff Garzik, an American software developer associated with exMULTI, Inc., conducted a comprehensive query over the entire blockchain to inspect script opcode usage. This analysis has been made publicly available on GitHub. The query counted the number of times each opcode was used, providing data for both the main blockchain and testnet3.The data shared on GitHub by Jeff Garzik provides a detailed breakdown of how many times each opcode was used in the blockchain. The information is presented in an organized chart that lists all opcodes and their corresponding count numbers. Overall, there were 26 different opcodes used in the blockchain. The opcode with the highest frequency of use was OP_CHECKSIG, which had a count of 12,188,693. OP_DUP followed closely behind with a count of 11,699,991. While some opcodes like OP_4 and OP_NOP1 had minimal use, others like OP_PUSHDATA had a relatively high count of 32,350,369.In addition to sharing the data, Jeff Garzik also mentions his association with exMULTI, Inc. and provides his email address for further communication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Coinbase-script-parse-failures.xml b/static/bitcoin-dev/July_2012/combined_Coinbase-script-parse-failures.xml index bc7c16de50..2c53d9e673 100644 --- a/static/bitcoin-dev/July_2012/combined_Coinbase-script-parse-failures.xml +++ b/static/bitcoin-dev/July_2012/combined_Coinbase-script-parse-failures.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Coinbase script parse failures - 2023-08-01T03:50:09.081353+00:00 + 2025-10-11T21:50:47.411712+00:00 + python-feedgen Matt Corallo 2012-07-23 16:11:43+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Coinbase script parse failures - 2023-08-01T03:50:09.081353+00:00 + 2025-10-11T21:50:47.411854+00:00 - In the world of cryptocurrency, Coinbase scriptsigs play a crucial role in authorizing transactions. These scriptsigs, which are inputs used to validate transactions, contain a signature and other necessary data. While they do not need to be well-formed and are never executed, they must still meet certain requirements to be considered valid. These requirements include having a valid signature and a properly formatted public key. Failure to meet these requirements will result in the rejection of the transaction by the network.A script engine called pynode, developed by Jeff Garzik, was used to tokenize the data stream of a scriptPubKey and scriptSig without execution. During testing, Garzik discovered over 8,000 tokenization failures in the blockchain, with all of them occurring in coinbase transactions' scriptSig. The scripts used to generate these failures can be found on GitHub at https://github.com/jgarzik/pynode.It is worth noting that even though sigops in coinbase transactions are not executed and are not required to be well-formed, they are still counted. This could potentially pose an interesting attack if a miner were able to insert a byte equivalent to OP_CHECKSIG into the coinbase scriptSig, as these sigops are not counted during mining. However, it was pointed out that the content of coinbase scriptSigs is always pushed properly by default, and modifying the code would require thorough research. If any issues arise from modifying the code, it would be the responsibility of the miner.To provide further insight, Jeff Garzik shared a data dump containing invalid scripts he found in the blockchain. This dump includes information such as block numbers, transaction IDs, and parse failures of specific inputs in these transactions. It is important to note that some blocks contain multiple failed transactions while others have only one.Overall, understanding the role of Coinbase scriptsigs in the world of cryptocurrency is essential for comprehending the technical aspects of digital currency. Despite not being well-formed and never executed, these scriptsigs are a vital part of the validation process, ensuring the accuracy and security of transactions. 2012-07-23T16:11:43+00:00 + In the world of cryptocurrency, Coinbase scriptsigs play a crucial role in authorizing transactions. These scriptsigs, which are inputs used to validate transactions, contain a signature and other necessary data. While they do not need to be well-formed and are never executed, they must still meet certain requirements to be considered valid. These requirements include having a valid signature and a properly formatted public key. Failure to meet these requirements will result in the rejection of the transaction by the network.A script engine called pynode, developed by Jeff Garzik, was used to tokenize the data stream of a scriptPubKey and scriptSig without execution. During testing, Garzik discovered over 8,000 tokenization failures in the blockchain, with all of them occurring in coinbase transactions' scriptSig. The scripts used to generate these failures can be found on GitHub at https://github.com/jgarzik/pynode.It is worth noting that even though sigops in coinbase transactions are not executed and are not required to be well-formed, they are still counted. This could potentially pose an interesting attack if a miner were able to insert a byte equivalent to OP_CHECKSIG into the coinbase scriptSig, as these sigops are not counted during mining. However, it was pointed out that the content of coinbase scriptSigs is always pushed properly by default, and modifying the code would require thorough research. If any issues arise from modifying the code, it would be the responsibility of the miner.To provide further insight, Jeff Garzik shared a data dump containing invalid scripts he found in the blockchain. This dump includes information such as block numbers, transaction IDs, and parse failures of specific inputs in these transactions. It is important to note that some blocks contain multiple failed transactions while others have only one.Overall, understanding the role of Coinbase scriptsigs in the world of cryptocurrency is essential for comprehending the technical aspects of digital currency. Despite not being well-formed and never executed, these scriptsigs are a vital part of the validation process, ensuring the accuracy and security of transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Gitian-builds-on-all-platforms-using-Vagrant-VirtualBox-GH-1597-.xml b/static/bitcoin-dev/July_2012/combined_Gitian-builds-on-all-platforms-using-Vagrant-VirtualBox-GH-1597-.xml index ce49256d5c..05401313d6 100644 --- a/static/bitcoin-dev/July_2012/combined_Gitian-builds-on-all-platforms-using-Vagrant-VirtualBox-GH-1597-.xml +++ b/static/bitcoin-dev/July_2012/combined_Gitian-builds-on-all-platforms-using-Vagrant-VirtualBox-GH-1597-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Gitian builds on all platforms using Vagrant/VirtualBox (GH #1597) - 2023-08-01T03:47:22.335187+00:00 + 2025-10-11T21:50:53.789610+00:00 + python-feedgen Wladimir 2012-07-14 07:40:13+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Gitian builds on all platforms using Vagrant/VirtualBox (GH #1597) - 2023-08-01T03:47:22.335187+00:00 + 2025-10-11T21:50:53.789794+00:00 - In an email conversation between Mark Friedenbach and Wladimir, the development of Virtualbox and its significance in gitian builds is discussed. Wladimir points out that Virtualbox has lower CPU requirements and can be used on older CPUs, unlike KVM which is slower without hardware virtualization. Furthermore, KVM and Virtualbox do not function well together.Mark shares his own experience with setting up and maintaining his gitian build system, expressing difficulties in doing so. To address this problem, he created a makefile that simplifies the process. Now, performing a gitian build only requires running "cd contrib/vagrant && make" on any platform, as long as the necessary dependencies are installed. These scripts have been submitted by Mark as pull-request #1597 on Github, with the hope that others will find them useful.The email thread concludes with a mention of an exclusive live event that will delve into today's security and threat landscape, covering topics such as endpoint security, mobile security, and the latest malware threats. The email also includes links to the Bitcoin-development mailing list for further reference. 2012-07-14T07:40:13+00:00 + In an email conversation between Mark Friedenbach and Wladimir, the development of Virtualbox and its significance in gitian builds is discussed. Wladimir points out that Virtualbox has lower CPU requirements and can be used on older CPUs, unlike KVM which is slower without hardware virtualization. Furthermore, KVM and Virtualbox do not function well together.Mark shares his own experience with setting up and maintaining his gitian build system, expressing difficulties in doing so. To address this problem, he created a makefile that simplifies the process. Now, performing a gitian build only requires running "cd contrib/vagrant && make" on any platform, as long as the necessary dependencies are installed. These scripts have been submitted by Mark as pull-request #1597 on Github, with the hope that others will find them useful.The email thread concludes with a mention of an exclusive live event that will delve into today's security and threat landscape, covering topics such as endpoint security, mobile security, and the latest malware threats. The email also includes links to the Bitcoin-development mailing list for further reference. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_LevelDB-benchmarking.xml b/static/bitcoin-dev/July_2012/combined_LevelDB-benchmarking.xml index 34b9015c3c..9bb8b35d14 100644 --- a/static/bitcoin-dev/July_2012/combined_LevelDB-benchmarking.xml +++ b/static/bitcoin-dev/July_2012/combined_LevelDB-benchmarking.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - LevelDB benchmarking - 2023-08-01T03:41:23.398194+00:00 + 2025-10-11T21:50:51.663328+00:00 + python-feedgen Mike Hearn 2012-07-21 18:49:54+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - LevelDB benchmarking - 2023-08-01T03:41:23.398194+00:00 + 2025-10-11T21:50:51.663544+00:00 - Stefan has completed a task related to Bitcoin's project and raised a pull request for it. The pull request can be found on Github with the URL: https://github.com/bitcoin/bitcoin/pull/1619. It is mentioned that the author of the mikehearn/bitcoin repository has added more commits to the codebase, but it is not yet ready for a pull request. Auto-migration and migration progress UI are present, but testing with empty wallets still needs to be done. The LevelDB source is checked into the main tree, and bitcoin-qt.pro has been updated to use it. However, there are some remaining tasks, such as more testing with actual wallets and updating non-Qt makefiles. The author asks for help with testing and makefile work.In a recent discussion on the #bitcoin-dev platform, it was discovered that the CTxDB::ReadOwnerTxes code has never been used in the Bitcoin codebase, even in version 0.1.5. As a result, the author plans to delete the code when they next work on the patch.Another conversation on #bitcoin-dev suggests that Satoshi's code uses ordered access/iteration in at least one place where it looks up the "owner transactions" of a tx. However, it is unclear what that code is used for and whether it is the best solution for the problem.A Bitcoin forum post discusses the issue of block propagation times. It is mentioned that the regular network lags behind p2pool in propagating new blocks by 0-60 seconds. Optimizing IO load and threading transmission verification are suggested as important improvements. Lukes preview functionality is also seen as a useful tool in this regard.In a message, someone expresses gratitude for the information that BitcoinJS uses LevelDB but points out that LevelDB was originally designed for servers and comes from BigTable. The speaker anticipates that most Bitcoin nodes on servers will continue to be HDD based for the foreseeable future. Additionally, the speaker mentions that Satoshis code uses ordered access/iteration in at least one place, but questions whether it is the best way to solve the problem.LevelDB is discussed as an ordered data structure that is good for desktop software with multiple use cases. It was written to power IndexedDB in Chrome and uses LSM trees as a database type. However, it is mentioned that LevelDB may not be ideal for Bitcoin due to its lack of ordered access and predictable characteristics. Nonetheless, it seems to work well for the Bitcoin use case. The speaker suggests lowering the file descriptor limit or combining tables into one to address any potential issues.The problem of slow block verification and propagation is discussed, and making existing nodes faster is proposed as a solution. This does not replace moving users to SPV clients. The robustness of LevelDB is uncertain, but it has an API call to repair the database. However, the lack of infrastructure poses a concern regarding reworking bitcointools to read the LevelDB Blockchain.In an email exchange, Gavin Andresen seeks decisions from colleagues on switching to LevelDB as a replacement for bdb. They discuss the benefits and drawbacks of LevelDB, including its minimalist build system and compatibility with different operating systems. They suggest including the source code in the main Bitcoin tree and linking it statically for simplicity. They also discuss possible tweaks to the database schema during migration.Mike Hearn suggests moving away from BDB and replacing it with LevelDB in an email conversation. Gavin Andresen expresses concerns about LevelDB's obscurity, newness, and compatibility guarantees. He suggests including the source code in the main Bitcoin tree and linking it statically. Other tweaks to the DB format are also discussed.Gregory Maxwell suggests running ECDSA caching on multiple cores for linear speedup. He realizes that he may have been wrong about being IO bound in a benchmark. Gavin is expected to make decisions on whether to proceed with the work, how to deal with LevelDB's minimalist build system, and how to handle any necessary tweaks to the db format.The author changes the transaction database to Google LevelDB library and performs tests comparing it with Regular BDB. The results show that LevelDB is faster, reducing the running time from 95 minutes to 50. Signature checking remains the bottleneck. 2012-07-21T18:49:54+00:00 + Stefan has completed a task related to Bitcoin's project and raised a pull request for it. The pull request can be found on Github with the URL: https://github.com/bitcoin/bitcoin/pull/1619. It is mentioned that the author of the mikehearn/bitcoin repository has added more commits to the codebase, but it is not yet ready for a pull request. Auto-migration and migration progress UI are present, but testing with empty wallets still needs to be done. The LevelDB source is checked into the main tree, and bitcoin-qt.pro has been updated to use it. However, there are some remaining tasks, such as more testing with actual wallets and updating non-Qt makefiles. The author asks for help with testing and makefile work.In a recent discussion on the #bitcoin-dev platform, it was discovered that the CTxDB::ReadOwnerTxes code has never been used in the Bitcoin codebase, even in version 0.1.5. As a result, the author plans to delete the code when they next work on the patch.Another conversation on #bitcoin-dev suggests that Satoshi's code uses ordered access/iteration in at least one place where it looks up the "owner transactions" of a tx. However, it is unclear what that code is used for and whether it is the best solution for the problem.A Bitcoin forum post discusses the issue of block propagation times. It is mentioned that the regular network lags behind p2pool in propagating new blocks by 0-60 seconds. Optimizing IO load and threading transmission verification are suggested as important improvements. Lukes preview functionality is also seen as a useful tool in this regard.In a message, someone expresses gratitude for the information that BitcoinJS uses LevelDB but points out that LevelDB was originally designed for servers and comes from BigTable. The speaker anticipates that most Bitcoin nodes on servers will continue to be HDD based for the foreseeable future. Additionally, the speaker mentions that Satoshis code uses ordered access/iteration in at least one place, but questions whether it is the best way to solve the problem.LevelDB is discussed as an ordered data structure that is good for desktop software with multiple use cases. It was written to power IndexedDB in Chrome and uses LSM trees as a database type. However, it is mentioned that LevelDB may not be ideal for Bitcoin due to its lack of ordered access and predictable characteristics. Nonetheless, it seems to work well for the Bitcoin use case. The speaker suggests lowering the file descriptor limit or combining tables into one to address any potential issues.The problem of slow block verification and propagation is discussed, and making existing nodes faster is proposed as a solution. This does not replace moving users to SPV clients. The robustness of LevelDB is uncertain, but it has an API call to repair the database. However, the lack of infrastructure poses a concern regarding reworking bitcointools to read the LevelDB Blockchain.In an email exchange, Gavin Andresen seeks decisions from colleagues on switching to LevelDB as a replacement for bdb. They discuss the benefits and drawbacks of LevelDB, including its minimalist build system and compatibility with different operating systems. They suggest including the source code in the main Bitcoin tree and linking it statically for simplicity. They also discuss possible tweaks to the database schema during migration.Mike Hearn suggests moving away from BDB and replacing it with LevelDB in an email conversation. Gavin Andresen expresses concerns about LevelDB's obscurity, newness, and compatibility guarantees. He suggests including the source code in the main Bitcoin tree and linking it statically. Other tweaks to the DB format are also discussed.Gregory Maxwell suggests running ECDSA caching on multiple cores for linear speedup. He realizes that he may have been wrong about being IO bound in a benchmark. Gavin is expected to make decisions on whether to proceed with the work, how to deal with LevelDB's minimalist build system, and how to handle any necessary tweaks to the db format.The author changes the transaction database to Google LevelDB library and performs tests comparing it with Regular BDB. The results show that LevelDB is faster, reducing the running time from 95 minutes to 50. Signature checking remains the bottleneck. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_New-P2P-commands-for-diagnostics-SPV-clients.xml b/static/bitcoin-dev/July_2012/combined_New-P2P-commands-for-diagnostics-SPV-clients.xml index 6912d645a3..0c1ed4b1f9 100644 --- a/static/bitcoin-dev/July_2012/combined_New-P2P-commands-for-diagnostics-SPV-clients.xml +++ b/static/bitcoin-dev/July_2012/combined_New-P2P-commands-for-diagnostics-SPV-clients.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New P2P commands for diagnostics, SPV clients - 2023-08-01T03:35:39.542593+00:00 + 2025-10-11T21:50:58.058257+00:00 + python-feedgen Mike Hearn 2012-07-24 08:16:12+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - New P2P commands for diagnostics, SPV clients - 2023-08-01T03:35:39.543591+00:00 + 2025-10-11T21:50:58.058497+00:00 - In a discussion among developers on the Bitcoin mailing list, the topic of debate is combining the 'filterinit' and 'filterload' commands. These commands are used to initialize and input a serialized bloom filter table metadata and data. One developer suggests that if the 'filteradd' command does not have a compelling use case, then 'filterinit' and 'filteradd' can be dropped. The consensus is that the 'filterload' command includes all the necessary metadata required to initialize a bloom filter. However, there is a need to specify the format of how these commands arrive, particularly when a new block is found. It is suggested that input from potential users is required to determine what information they might need.The discussion also revolves around the combination of bloom filters and Simplified Payment Verification (SPV) clients. The combination is not widely used because it allows the node using the bloom filter to scan transactions and choose how much effort it wants to put into each transaction on behalf of the SPV client. A negotiation protocol would need to be specified for this to work. Despite this potential solution, it may still be too heavy for nodes and could result in overloading. In such cases, the node could simply disconnect intensive peers or refuse new connections.Another topic of discussion is the format of distributing blocks in the blockchain network. A proposal suggests using the 'invgetdatamerkleblock' command instead of the 'invgetdatablock' command. This new command includes a "merkleblock" structure that optimizes bandwidth by not re-transmitting transactions already seen in the mempool. The proposal also introduces a new command, 'getmerkletx', which returns a merkletx message for each requested transaction. Implementing this proposal could help reduce orphan blocks and spurious chain splits.Additionally, there is a discussion about the format of a project and potential user input to determine what information is necessary. One developer suggests a three-part change, including adding the 'mempool' command, syncing up nodes' mempools on startup, and changing the "block" message format. The proposed format for the "block" message aims to speed up the block propagation process and incentivize miners to upgrade.Furthermore, the discussion touches upon the needs of lightweight clients and proposes new P2P commands with associated behavior changes. These proposed commands include 'filterinit', 'filterload', 'filterclear', 'filteradd', and 'mempool'. The 'filterload' and 'filteradd' commands enable special behavior changes for 'mempool' and existing P2P commands. A lightweight client would issue the 'filterload' command, sync up with blocks, and then use the 'mempool' command to sync up to current transactions. The 'mempool' command could also be useful as a diagnostic tool, even if a bloom filter is not applied to its output.Overall, the discussions revolve around optimizing the code, streamlining protocols, improving block propagation speed, and addressing the needs of SPV clients and lightweight clients. Proposals include combining functions, specifying formats, and introducing new commands to achieve these goals. Input from potential users is considered crucial in determining the necessary information and making informed decisions. 2012-07-24T08:16:12+00:00 + In a discussion among developers on the Bitcoin mailing list, the topic of debate is combining the 'filterinit' and 'filterload' commands. These commands are used to initialize and input a serialized bloom filter table metadata and data. One developer suggests that if the 'filteradd' command does not have a compelling use case, then 'filterinit' and 'filteradd' can be dropped. The consensus is that the 'filterload' command includes all the necessary metadata required to initialize a bloom filter. However, there is a need to specify the format of how these commands arrive, particularly when a new block is found. It is suggested that input from potential users is required to determine what information they might need.The discussion also revolves around the combination of bloom filters and Simplified Payment Verification (SPV) clients. The combination is not widely used because it allows the node using the bloom filter to scan transactions and choose how much effort it wants to put into each transaction on behalf of the SPV client. A negotiation protocol would need to be specified for this to work. Despite this potential solution, it may still be too heavy for nodes and could result in overloading. In such cases, the node could simply disconnect intensive peers or refuse new connections.Another topic of discussion is the format of distributing blocks in the blockchain network. A proposal suggests using the 'invgetdatamerkleblock' command instead of the 'invgetdatablock' command. This new command includes a "merkleblock" structure that optimizes bandwidth by not re-transmitting transactions already seen in the mempool. The proposal also introduces a new command, 'getmerkletx', which returns a merkletx message for each requested transaction. Implementing this proposal could help reduce orphan blocks and spurious chain splits.Additionally, there is a discussion about the format of a project and potential user input to determine what information is necessary. One developer suggests a three-part change, including adding the 'mempool' command, syncing up nodes' mempools on startup, and changing the "block" message format. The proposed format for the "block" message aims to speed up the block propagation process and incentivize miners to upgrade.Furthermore, the discussion touches upon the needs of lightweight clients and proposes new P2P commands with associated behavior changes. These proposed commands include 'filterinit', 'filterload', 'filterclear', 'filteradd', and 'mempool'. The 'filterload' and 'filteradd' commands enable special behavior changes for 'mempool' and existing P2P commands. A lightweight client would issue the 'filterload' command, sync up with blocks, and then use the 'mempool' command to sync up to current transactions. The 'mempool' command could also be useful as a diagnostic tool, even if a bloom filter is not applied to its output.Overall, the discussions revolve around optimizing the code, streamlining protocols, improving block propagation speed, and addressing the needs of SPV clients and lightweight clients. Proposals include combining functions, specifying formats, and introducing new commands to achieve these goals. Input from potential users is considered crucial in determining the necessary information and making informed decisions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Pruning-in-the-reference-client-ultraprune-mode.xml b/static/bitcoin-dev/July_2012/combined_Pruning-in-the-reference-client-ultraprune-mode.xml index 37e57aff12..aba9ec1ab4 100644 --- a/static/bitcoin-dev/July_2012/combined_Pruning-in-the-reference-client-ultraprune-mode.xml +++ b/static/bitcoin-dev/July_2012/combined_Pruning-in-the-reference-client-ultraprune-mode.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pruning in the reference client: ultraprune mode - 2023-08-01T03:45:00.398613+00:00 + 2025-10-11T21:50:49.540524+00:00 + python-feedgen Gregory Maxwell 2012-07-06 17:19:59+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Pruning in the reference client: ultraprune mode - 2023-08-01T03:45:00.398613+00:00 + 2025-10-11T21:50:49.540694+00:00 - Pieter Wuille's performance numbers are considered conservative due to the reference client wasting time in redundant serialization and hashing operations. Profiles on ultraprune support this information, showing that it is the major time sink. Resolving this issue would significantly improve the system's performance. It is important to note that this issue is not directly related to recent proposals for pruning involving an alt chain with an index of unspent coins and addresses merged mined with the main chain, but it could be a step towards such a system.The implementation of a new block/transaction validation system called "ultraprune" has been introduced for the reference client. Instead of using a fully indexed blockchain, which was deemed wasteful, ultraprune keeps a database with only the unspent transaction outputs. This reduces the required storage for such a dataset to less than 70 MB. The stored data is kept in a BDB database file (coins.dat) with indexing and overhead, taking around 130 MB. However, additional non-indexed blocks with metadata about all stored blocks were added to compensate for various functions, such as block connections, wallet transactions, and serving the chain to other nodes.The ultraprune system allows for running a full node with significantly reduced storage requirements. Coins.dat takes up 130 MB, chain.dat occupies 40 MB, and the size of retained blocks plus approximately 12% of that is needed for undo information. Furthermore, the ultraprune system is faster, with a benchmark on a laptop showing that a full import of the blockchain took only 22 minutes. Those interested in experimenting with ultraprune can find the ultraprune branch on GitHub.Despite its advantages, ultraprune also has some drawbacks. Firstly, it is not possible to find a full transaction from its txid. Secondly, transactions that depend on unconfirmed transactions will not be rebroadcasted. Thirdly, only block download and reorganization have been somewhat tested, so caution is advised when using ultraprune. Lastly, fewer consistency checks are possible on the database, and few have been implemented.Although ultraprune is not directly related to recent pruning proposals involving an alt chain with an index of unspent coins and addresses merged mined with the main chain, it could be seen as a step towards such a system. 2012-07-06T17:19:59+00:00 + Pieter Wuille's performance numbers are considered conservative due to the reference client wasting time in redundant serialization and hashing operations. Profiles on ultraprune support this information, showing that it is the major time sink. Resolving this issue would significantly improve the system's performance. It is important to note that this issue is not directly related to recent proposals for pruning involving an alt chain with an index of unspent coins and addresses merged mined with the main chain, but it could be a step towards such a system.The implementation of a new block/transaction validation system called "ultraprune" has been introduced for the reference client. Instead of using a fully indexed blockchain, which was deemed wasteful, ultraprune keeps a database with only the unspent transaction outputs. This reduces the required storage for such a dataset to less than 70 MB. The stored data is kept in a BDB database file (coins.dat) with indexing and overhead, taking around 130 MB. However, additional non-indexed blocks with metadata about all stored blocks were added to compensate for various functions, such as block connections, wallet transactions, and serving the chain to other nodes.The ultraprune system allows for running a full node with significantly reduced storage requirements. Coins.dat takes up 130 MB, chain.dat occupies 40 MB, and the size of retained blocks plus approximately 12% of that is needed for undo information. Furthermore, the ultraprune system is faster, with a benchmark on a laptop showing that a full import of the blockchain took only 22 minutes. Those interested in experimenting with ultraprune can find the ultraprune branch on GitHub.Despite its advantages, ultraprune also has some drawbacks. Firstly, it is not possible to find a full transaction from its txid. Secondly, transactions that depend on unconfirmed transactions will not be rebroadcasted. Thirdly, only block download and reorganization have been somewhat tested, so caution is advised when using ultraprune. Lastly, fewer consistency checks are possible on the database, and few have been implemented.Although ultraprune is not directly related to recent pruning proposals involving an alt chain with an index of unspent coins and addresses merged mined with the main chain, it could be seen as a step towards such a system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Random-order-for-clients-page.xml b/static/bitcoin-dev/July_2012/combined_Random-order-for-clients-page.xml index e5fd72dfa0..3d8de6297f 100644 --- a/static/bitcoin-dev/July_2012/combined_Random-order-for-clients-page.xml +++ b/static/bitcoin-dev/July_2012/combined_Random-order-for-clients-page.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Random order for clients page - 2023-08-01T03:47:12.561253+00:00 + 2025-10-11T21:50:34.658094+00:00 + python-feedgen Daniel F 2012-07-13 15:20:58+00:00 @@ -111,13 +112,13 @@ - python-feedgen + 2 Combined summary - Random order for clients page - 2023-08-01T03:47:12.561253+00:00 + 2025-10-11T21:50:34.658276+00:00 - The discussion revolves around the best way to present a list of Bitcoin clients on bitcoin.org. The author suggests creating a page listing major and vetted clients instead of using a wiki page that may contain low-quality options. The list should be ordered based on a weighted average of features, security, and goodness for the network. The author proposes combining prose descriptions and feature matrices to give users a better understanding of each client's strengths and weaknesses.Gregory Maxwell expresses his dislike for feature matrices, arguing that they encourage "checkbox decision making" and are often biased. He believes that important infrastructure gets overlooked in favor of minor features that make nice bullet points. Instead, he suggests that users should read through all the text to understand the tradeoffs and compromises of each client.Alan Reiner thinks that feature matrices can be useful for quickly finding specific features or criteria without reading through all the text. However, Maxwell disagrees, stating that feature matrices are seldom good for decision-makers and can be biased by marketing departments. He provides an example of MyBitcoin, which would have been the dominant option based on a matrix comparison but ended up costing people a lot.Wladimir disagrees with removing the overview page or moving it to the wiki. He believes that other open-source clients deserve a mention on the Bitcoin.org page and that following links from the site is safer than searching on Google or app stores. He suggests that the reference client should remain first on the main page, but a neutral ordering could be used for alternative clients.Stefan Thomas discusses the effectiveness of feature matrices for new users. While he acknowledges that a well-designed matrix can be user-friendly, he argues that they can be unhelpful and confusing for those who are not technologically inclined. He suggests that a feature matrix could be a useful addition to the Bitcoin wiki page.The conversation also covers the difficulty in choosing an XMPP client and the potential usefulness of a wiki for listing features and differentiating aspects of each client. It is agreed that the current client page format using short pieces of text to communicate differences is easier for users to understand.One email suggests moving the project to a wiki, as it allows anyone to update information and is more up-to-date. The author argues that wikis are recognizable as community-generated, while Github-based pages tend to be dominated by developers. They suggest that bitcoin.org should educate users about the system and available options.In an email exchange between Jeff Garzik and Gregory Maxwell, they discuss the creation of a controversial page and the need for pull requests for non-trivial changes. Some people express concern about the creation of this page, fearing it would lead to useless disputes. There is a suggestion to remove the page due to the increasing cost of dealing with it.The Bitcoin community discusses the idea of having a randomized client page on Bitcoin.org. Alan Reiner disagrees with the idea, stating that it is not fair for users to have an inconsistent page that sometimes recommends less-developed solutions. Instead, he suggests creating a subjective list by someone trusted to understand what is good for users. Gregory Maxwell reveals that the original layout was not accidental, and Jim admits to being secretly pleased with MultiBit's position on the page.The discussion revolves around the notion of randomization and fairness in deciding which Bitcoin client should be displayed first on the main page of Bitcoin.org. It is suggested that someone who understands what is good for users and has familiarity with the programs should be the one to decide. This person can take input from others but ultimately make the decision based on their interpretation of what's best for Bitcoin.org users.In an email from Jim, he admits to being secretly pleased with the original layout of MultiBit's position on the Bitcoin client page. However, he also believes that it is only fair to switch around the positions. This ordering was not accidental.The article discusses the complexities of Bitcoin for new users and how the clients page on bitcoin.org does a good job of explaining the different software options available. It also addresses the issue of trust and how having the clients linked from the "mothership" of bitcoin.org gives credibility to all alternative clients. The author suggests that open source clients should be the only ones included.In an email conversation between Amir Taaki and a Bitcoin Wiki editor, they discuss whether or not to remove a page on the Wiki that lists multiple Bitcoin clients. Taaki argues that there is no reason to remove the page and emphasizes the importance of bitcoin.org as a neutral resource for the community. He recommends trying out new clients such as Electrum and MultiBit.The discussion revolves around the Bitcoin Wiki and the clients page on bitcoin.org. One argument is against the removal of controversial content on a website, as it may be influenced by internal politics rather than considering the needs of end-users. The author suggests that all information about a system should be available on its website and opposes random changes without proper channels. They advocate for a more user-focused approach to website management.In regards to the clients page 2012-07-13T15:20:58+00:00 + The discussion revolves around the best way to present a list of Bitcoin clients on bitcoin.org. The author suggests creating a page listing major and vetted clients instead of using a wiki page that may contain low-quality options. The list should be ordered based on a weighted average of features, security, and goodness for the network. The author proposes combining prose descriptions and feature matrices to give users a better understanding of each client's strengths and weaknesses.Gregory Maxwell expresses his dislike for feature matrices, arguing that they encourage "checkbox decision making" and are often biased. He believes that important infrastructure gets overlooked in favor of minor features that make nice bullet points. Instead, he suggests that users should read through all the text to understand the tradeoffs and compromises of each client.Alan Reiner thinks that feature matrices can be useful for quickly finding specific features or criteria without reading through all the text. However, Maxwell disagrees, stating that feature matrices are seldom good for decision-makers and can be biased by marketing departments. He provides an example of MyBitcoin, which would have been the dominant option based on a matrix comparison but ended up costing people a lot.Wladimir disagrees with removing the overview page or moving it to the wiki. He believes that other open-source clients deserve a mention on the Bitcoin.org page and that following links from the site is safer than searching on Google or app stores. He suggests that the reference client should remain first on the main page, but a neutral ordering could be used for alternative clients.Stefan Thomas discusses the effectiveness of feature matrices for new users. While he acknowledges that a well-designed matrix can be user-friendly, he argues that they can be unhelpful and confusing for those who are not technologically inclined. He suggests that a feature matrix could be a useful addition to the Bitcoin wiki page.The conversation also covers the difficulty in choosing an XMPP client and the potential usefulness of a wiki for listing features and differentiating aspects of each client. It is agreed that the current client page format using short pieces of text to communicate differences is easier for users to understand.One email suggests moving the project to a wiki, as it allows anyone to update information and is more up-to-date. The author argues that wikis are recognizable as community-generated, while Github-based pages tend to be dominated by developers. They suggest that bitcoin.org should educate users about the system and available options.In an email exchange between Jeff Garzik and Gregory Maxwell, they discuss the creation of a controversial page and the need for pull requests for non-trivial changes. Some people express concern about the creation of this page, fearing it would lead to useless disputes. There is a suggestion to remove the page due to the increasing cost of dealing with it.The Bitcoin community discusses the idea of having a randomized client page on Bitcoin.org. Alan Reiner disagrees with the idea, stating that it is not fair for users to have an inconsistent page that sometimes recommends less-developed solutions. Instead, he suggests creating a subjective list by someone trusted to understand what is good for users. Gregory Maxwell reveals that the original layout was not accidental, and Jim admits to being secretly pleased with MultiBit's position on the page.The discussion revolves around the notion of randomization and fairness in deciding which Bitcoin client should be displayed first on the main page of Bitcoin.org. It is suggested that someone who understands what is good for users and has familiarity with the programs should be the one to decide. This person can take input from others but ultimately make the decision based on their interpretation of what's best for Bitcoin.org users.In an email from Jim, he admits to being secretly pleased with the original layout of MultiBit's position on the Bitcoin client page. However, he also believes that it is only fair to switch around the positions. This ordering was not accidental.The article discusses the complexities of Bitcoin for new users and how the clients page on bitcoin.org does a good job of explaining the different software options available. It also addresses the issue of trust and how having the clients linked from the "mothership" of bitcoin.org gives credibility to all alternative clients. The author suggests that open source clients should be the only ones included.In an email conversation between Amir Taaki and a Bitcoin Wiki editor, they discuss whether or not to remove a page on the Wiki that lists multiple Bitcoin clients. Taaki argues that there is no reason to remove the page and emphasizes the importance of bitcoin.org as a neutral resource for the community. He recommends trying out new clients such as Electrum and MultiBit.The discussion revolves around the Bitcoin Wiki and the clients page on bitcoin.org. One argument is against the removal of controversial content on a website, as it may be influenced by internal politics rather than considering the needs of end-users. The author suggests that all information about a system should be available on its website and opposes random changes without proper channels. They advocate for a more user-focused approach to website management.In regards to the clients page - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Reconsidering-block-version-number-use.xml b/static/bitcoin-dev/July_2012/combined_Reconsidering-block-version-number-use.xml index 3f4f73a0c4..b2d7e792ce 100644 --- a/static/bitcoin-dev/July_2012/combined_Reconsidering-block-version-number-use.xml +++ b/static/bitcoin-dev/July_2012/combined_Reconsidering-block-version-number-use.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reconsidering block version number use - 2023-08-01T03:48:43.547829+00:00 + 2025-10-11T21:51:02.315534+00:00 + python-feedgen Mike Hearn 2012-07-24 08:22:25+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Reconsidering block version number use - 2023-08-01T03:48:43.547829+00:00 + 2025-10-11T21:51:02.315690+00:00 - The writer of the email argues that using nonces to increase scalability in pools may have long-term consequences. They suggest upgrading the pool or encouraging users to migrate to p2pool as a more sustainable solution. The writer questions whether a powerful server-class machine can keep up with work generation for BitForce SC devices and emphasizes the need for powerful machines to run a node eventually.Peter suggests having more nonce space with less merkle calculation to ease the workload on the pool server. This would involve reducing the number of unique transaction/coinbase sets that need to be held onto for checking old work when a solution is returned. Mike questions the necessity of more nonce bits, wondering if it is a workaround for a performance bottleneck elsewhere.In response, Peter provides details on the amount of nonce required and proposed changes for version 2 blocks. These changes would include adding the block height to the coinbase and a 1-byte version number with a 3-byte extranonce. The email also includes contact information for Peter Vessenes, CEO of CoinLab.The context discusses the need for additional nonce bits in the Bitcoin block header. The author calculates that 7 bytes of nonce would be required, equivalent to 72 petahashes or 72,000 terahashes. However, the author questions the necessity of adding more nonce bits. They wonder if a multi-core CPU can handle the merkle root re-calculation while keeping an ASIC miner fed, or if there is another performance bottleneck that needs to be addressed.On July 23, 2012, Gavin Andresen proposed bumping the coinbase transaction version number to 2 instead of the block version. However, this would require every new block to compute the percentage of the last 1,000 blocks that support the new version. There may be a problem if aggressively pruning spent transactions starts. Luke-Jr suggested using the block version as an extra nonce, which could be used by ASIC miners running at 1 TH/s per rig before the end of 2012. Jeff noticed that block 190192 has version==2 without a valid block height in the coinbase, but since it's in a part of the chain with zero other version==2 blocks, the height-in-the-coinbase rule will not be enforced.The proposal to increase the block version number to 2 is related to the coinbase transaction, not the block itself. The issue with bumping the coinbase transaction version is that it requires computing the percentage of the last 1,000 blocks that support the new version during the rollout. This can be done by storing the last 1,000 coinbases in memory or fetching them from disk. However, this may become a problem if spent transactions are aggressively pruned and the coinbase from 900 blocks back gets spent and pruned.An alternative proposal is to use the block version number as an extra nonce to accommodate the increasing number of ASIC miners. This can be done by giving 3 of the 4 block version bytes as a simple extranonce. The changes for version 2 blocks would include having the height in the coinbase and a 1-byte version number with a 3-byte extranonce. There was also an issue raised regarding block 190192 having version==2 without a valid block height in the coinbase. It was suspected that this may be due to combining the current blockheight-in-coinbase pullreq with P2Pool. However, the rules state that the height-in-the-coinbase rule will only be enforced when the chain has a super-majority, and since block 190192 is in a part of the chain with zero other version==2 blocks, the rule will not be enforced.It has been suggested that the block version number could be used as an "extra nonce" due to the anticipated increase in ASIC miners. The proposal is to use the block version for this purpose. While the current block height in coinbase addition proposes using block version 2, the protocol change is to the coinbase transaction itself. Therefore, it has been suggested to bump the coinbase transaction version number to 2 instead. There is also an issue with block 190192 having a version of 2 without a valid block height in the coinbase, which may be due to combining the current blockheight-in-coinbase pullreq with P2Pool. To address this, an exception would be required if the version==2 marker is used, and moving the version==2 to the coinbase transaction version would allow whoever makes the transaction to set the version number instead of it coming from bitcoind and the coinbase transaction coming from P2Pool or other software. 2012-07-24T08:22:25+00:00 + The writer of the email argues that using nonces to increase scalability in pools may have long-term consequences. They suggest upgrading the pool or encouraging users to migrate to p2pool as a more sustainable solution. The writer questions whether a powerful server-class machine can keep up with work generation for BitForce SC devices and emphasizes the need for powerful machines to run a node eventually.Peter suggests having more nonce space with less merkle calculation to ease the workload on the pool server. This would involve reducing the number of unique transaction/coinbase sets that need to be held onto for checking old work when a solution is returned. Mike questions the necessity of more nonce bits, wondering if it is a workaround for a performance bottleneck elsewhere.In response, Peter provides details on the amount of nonce required and proposed changes for version 2 blocks. These changes would include adding the block height to the coinbase and a 1-byte version number with a 3-byte extranonce. The email also includes contact information for Peter Vessenes, CEO of CoinLab.The context discusses the need for additional nonce bits in the Bitcoin block header. The author calculates that 7 bytes of nonce would be required, equivalent to 72 petahashes or 72,000 terahashes. However, the author questions the necessity of adding more nonce bits. They wonder if a multi-core CPU can handle the merkle root re-calculation while keeping an ASIC miner fed, or if there is another performance bottleneck that needs to be addressed.On July 23, 2012, Gavin Andresen proposed bumping the coinbase transaction version number to 2 instead of the block version. However, this would require every new block to compute the percentage of the last 1,000 blocks that support the new version. There may be a problem if aggressively pruning spent transactions starts. Luke-Jr suggested using the block version as an extra nonce, which could be used by ASIC miners running at 1 TH/s per rig before the end of 2012. Jeff noticed that block 190192 has version==2 without a valid block height in the coinbase, but since it's in a part of the chain with zero other version==2 blocks, the height-in-the-coinbase rule will not be enforced.The proposal to increase the block version number to 2 is related to the coinbase transaction, not the block itself. The issue with bumping the coinbase transaction version is that it requires computing the percentage of the last 1,000 blocks that support the new version during the rollout. This can be done by storing the last 1,000 coinbases in memory or fetching them from disk. However, this may become a problem if spent transactions are aggressively pruned and the coinbase from 900 blocks back gets spent and pruned.An alternative proposal is to use the block version number as an extra nonce to accommodate the increasing number of ASIC miners. This can be done by giving 3 of the 4 block version bytes as a simple extranonce. The changes for version 2 blocks would include having the height in the coinbase and a 1-byte version number with a 3-byte extranonce. There was also an issue raised regarding block 190192 having version==2 without a valid block height in the coinbase. It was suspected that this may be due to combining the current blockheight-in-coinbase pullreq with P2Pool. However, the rules state that the height-in-the-coinbase rule will only be enforced when the chain has a super-majority, and since block 190192 is in a part of the chain with zero other version==2 blocks, the rule will not be enforced.It has been suggested that the block version number could be used as an "extra nonce" due to the anticipated increase in ASIC miners. The proposal is to use the block version for this purpose. While the current block height in coinbase addition proposes using block version 2, the protocol change is to the coinbase transaction itself. Therefore, it has been suggested to bump the coinbase transaction version number to 2 instead. There is also an issue with block 190192 having a version of 2 without a valid block height in the coinbase, which may be due to combining the current blockheight-in-coinbase pullreq with P2Pool. To address this, an exception would be required if the version==2 marker is used, and moving the version==2 to the coinbase transaction version would allow whoever makes the transaction to set the version number instead of it coming from bitcoind and the coinbase transaction coming from P2Pool or other software. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Scalability-issues.xml b/static/bitcoin-dev/July_2012/combined_Scalability-issues.xml index e2f46f8fc7..0ba2a8d81c 100644 --- a/static/bitcoin-dev/July_2012/combined_Scalability-issues.xml +++ b/static/bitcoin-dev/July_2012/combined_Scalability-issues.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Scalability issues - 2023-08-01T03:49:52.418850+00:00 + 2025-10-11T21:50:45.286648+00:00 + python-feedgen grarpamp 2012-07-27 19:37:27+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Scalability issues - 2023-08-01T03:49:52.419853+00:00 + 2025-10-11T21:50:45.286831+00:00 - horizon, particularly for those who want to independently build, manage, and trust their own blockchain. The post also includes an advertisement for a Live Security Virtual Conference covering IT security and malware threats.In another message from 2012, a user named grarpamp expresses concern about the time it takes to build a new blockchain and keep up with incoming blocks. They suggest that there may be something wrong with the software stack and that a full sync should only take around an hour. The user acknowledges that there are scalability issues, but believes that regular hardware should still be able to keep up without any major changes to the protocol. It is unclear what specific system or software they were referring to.Michael Grønager claims that he can get a full blockchain from scratch in 45 minutes on his laptop. However, Steve, who has been doing extensive testing in this area, finds it difficult to believe and asks for additional information to help him with testing. Steve mentions that he has an extensive setup of test machines, ranging from e4300 to phenom2x6 to i5's, but it still takes him about 12-24 hours to get the entire chain. As an example, he states that on an amd e-450 with 4GB RAM and approx 3gb/s internet connection, it took him 2 hours to sync the last 5 days. He expresses his curiosity and requests Michael to provide any additional information that can help him with his testing.The conversation begins with a user suggesting that there is something wrong with the software stack of the other person's system. However, the person denies any issues and claims that it is all default install. They also mention that they have documented the platform for anyone who wants to confirm it. The discussion then moves on to the time taken for a full sync, with one person claiming that it takes an hour while the other stating that it takes only 5 seconds on their Cray system. The topic of using Tor is also brought up, with one person guessing that the blockchain download is being run through the tor-proxy. However, the other person claims that Tor is fast enough and can copy the entire 3GiB of the .bitcoin dir in 7 days off a slow hidden service and 0.5 days via exit. Encryption is also discussed, with one person claiming that encrypting the disk will not help much, while the other person argues that encryption is reasonable to expect users of bitcoin to be interested in doing. The discussion then moves on to the storage of a public blockchain and whether it is odd to encrypt it. It is argued that without detachdb, it is somehow tied to the wallet and that encrypting everything is perfectly reasonable. The use of ZFS/BTRFS is also mentioned as they verify the integrity of their data on disk. Gregory Maxwell responded to a message about scalability improvements being needed, stating that there is no need for concern as regular hardware can keep up without a hardforking change to the protocol first. This response was given in the context of a discussion on the Bitcoin-development mailing list and included a link to a live security virtual conference covering endpoint security, mobile security, and malware threats.Overall, the given context discusses various aspects related to the performance and scalability of the Bitcoin blockchain. There are discussions about the time taken for a full sync, the impact of different hardware and software setups, the use of Tor and encryption, and the challenges of scalability for regular hardware. Additionally, Gregory Maxwell provides reassurance that regular hardware can handle the demands of Bitcoin without major changes to the protocol. 2012-07-27T19:37:27+00:00 + horizon, particularly for those who want to independently build, manage, and trust their own blockchain. The post also includes an advertisement for a Live Security Virtual Conference covering IT security and malware threats.In another message from 2012, a user named grarpamp expresses concern about the time it takes to build a new blockchain and keep up with incoming blocks. They suggest that there may be something wrong with the software stack and that a full sync should only take around an hour. The user acknowledges that there are scalability issues, but believes that regular hardware should still be able to keep up without any major changes to the protocol. It is unclear what specific system or software they were referring to.Michael Grønager claims that he can get a full blockchain from scratch in 45 minutes on his laptop. However, Steve, who has been doing extensive testing in this area, finds it difficult to believe and asks for additional information to help him with testing. Steve mentions that he has an extensive setup of test machines, ranging from e4300 to phenom2x6 to i5's, but it still takes him about 12-24 hours to get the entire chain. As an example, he states that on an amd e-450 with 4GB RAM and approx 3gb/s internet connection, it took him 2 hours to sync the last 5 days. He expresses his curiosity and requests Michael to provide any additional information that can help him with his testing.The conversation begins with a user suggesting that there is something wrong with the software stack of the other person's system. However, the person denies any issues and claims that it is all default install. They also mention that they have documented the platform for anyone who wants to confirm it. The discussion then moves on to the time taken for a full sync, with one person claiming that it takes an hour while the other stating that it takes only 5 seconds on their Cray system. The topic of using Tor is also brought up, with one person guessing that the blockchain download is being run through the tor-proxy. However, the other person claims that Tor is fast enough and can copy the entire 3GiB of the .bitcoin dir in 7 days off a slow hidden service and 0.5 days via exit. Encryption is also discussed, with one person claiming that encrypting the disk will not help much, while the other person argues that encryption is reasonable to expect users of bitcoin to be interested in doing. The discussion then moves on to the storage of a public blockchain and whether it is odd to encrypt it. It is argued that without detachdb, it is somehow tied to the wallet and that encrypting everything is perfectly reasonable. The use of ZFS/BTRFS is also mentioned as they verify the integrity of their data on disk. Gregory Maxwell responded to a message about scalability improvements being needed, stating that there is no need for concern as regular hardware can keep up without a hardforking change to the protocol first. This response was given in the context of a discussion on the Bitcoin-development mailing list and included a link to a live security virtual conference covering endpoint security, mobile security, and malware threats.Overall, the given context discusses various aspects related to the performance and scalability of the Bitcoin blockchain. There are discussions about the time taken for a full sync, the impact of different hardware and software setups, the use of Tor and encryption, and the challenges of scalability for regular hardware. Additionally, Gregory Maxwell provides reassurance that regular hardware can handle the demands of Bitcoin without major changes to the protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_Signing-release-binaries.xml b/static/bitcoin-dev/July_2012/combined_Signing-release-binaries.xml index 8baed871e1..d161cf3205 100644 --- a/static/bitcoin-dev/July_2012/combined_Signing-release-binaries.xml +++ b/static/bitcoin-dev/July_2012/combined_Signing-release-binaries.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Signing release binaries - 2023-08-01T03:50:41.347418+00:00 + 2025-10-11T21:50:36.783598+00:00 + python-feedgen Peter Pauly 2012-07-30 13:02:00+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Signing release binaries - 2023-08-01T03:50:41.348382+00:00 + 2025-10-11T21:50:36.783759+00:00 - In a discussion on the Bitcoin-development mailing list from 2012, the author expresses concern about the security of the binaries available on the bitcoin.org site. They suggest that all binaries should be signed with gpg to provide an extra layer of protection against potential hacks and wallet theft. Despite developers having gpg keys, the author questions why detached gpg signatures are not already being provided for the binaries. This extra security measure is seen as crucial in safeguarding users' funds from malicious attacks.The email exchange includes a message about a Live Security Virtual Conference, which will cover the evolving security and threat landscape and how IT managers can respond. Areas of focus include endpoint security, mobile security, and the latest malware threats. The email concludes with a PGP signature using GnuPG v2.0.19 (MingW32).Specifically, in an email exchange on July 29, 2012, Mike Hearn expresses his preference for someone other than Gavin to be responsible for OS-vendor signing. While it is not clear who or what organization Hearn is referring to when he mentions "OS-vendor signing," it can be inferred that this refers to the process of certifying software for use on a particular operating system. Hearn's concerns about Gavin's involvement in this process are mentioned, but the exact reasons are not provided.The context also discusses the requirements for application signing on different operating systems. MacOS X 10.8 mandates application signing, requiring the use of a certificate issued by Apple's "identified developer" program to run unsigned apps. On the other hand, Windows does not require signing, but anti-virus systems tend to whitelist signers with a good reputation. Signing Bitcoin releases can potentially improve performance if anti-virus engines ignore file reads/writes by Bitcoin and shield from false positives. This is particularly important considering the issues in the mining tools world.To address these concerns, Mike Hearn suggests buying the signing certificates for both platforms and is willing to contribute money towards this effort. Gavin is suggested as the final signer for the process.Overall, the discussion highlights the need for improved security measures, such as gpg signatures and application signing, to protect users' funds and address potential threats in the Bitcoin ecosystem. 2012-07-30T13:02:00+00:00 + In a discussion on the Bitcoin-development mailing list from 2012, the author expresses concern about the security of the binaries available on the bitcoin.org site. They suggest that all binaries should be signed with gpg to provide an extra layer of protection against potential hacks and wallet theft. Despite developers having gpg keys, the author questions why detached gpg signatures are not already being provided for the binaries. This extra security measure is seen as crucial in safeguarding users' funds from malicious attacks.The email exchange includes a message about a Live Security Virtual Conference, which will cover the evolving security and threat landscape and how IT managers can respond. Areas of focus include endpoint security, mobile security, and the latest malware threats. The email concludes with a PGP signature using GnuPG v2.0.19 (MingW32).Specifically, in an email exchange on July 29, 2012, Mike Hearn expresses his preference for someone other than Gavin to be responsible for OS-vendor signing. While it is not clear who or what organization Hearn is referring to when he mentions "OS-vendor signing," it can be inferred that this refers to the process of certifying software for use on a particular operating system. Hearn's concerns about Gavin's involvement in this process are mentioned, but the exact reasons are not provided.The context also discusses the requirements for application signing on different operating systems. MacOS X 10.8 mandates application signing, requiring the use of a certificate issued by Apple's "identified developer" program to run unsigned apps. On the other hand, Windows does not require signing, but anti-virus systems tend to whitelist signers with a good reputation. Signing Bitcoin releases can potentially improve performance if anti-virus engines ignore file reads/writes by Bitcoin and shield from false positives. This is particularly important considering the issues in the mining tools world.To address these concerns, Mike Hearn suggests buying the signing certificates for both platforms and is willing to contribute money towards this effort. Gavin is suggested as the final signer for the process.Overall, the discussion highlights the need for improved security measures, such as gpg signatures and application signing, to protect users' funds and address potential threats in the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_bitcoin-org-remove-hackathon.xml b/static/bitcoin-dev/July_2012/combined_bitcoin-org-remove-hackathon.xml index ee7ddf1841..d2cb90d10b 100644 --- a/static/bitcoin-dev/July_2012/combined_bitcoin-org-remove-hackathon.xml +++ b/static/bitcoin-dev/July_2012/combined_bitcoin-org-remove-hackathon.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin.org - remove hackathon - 2023-08-01T03:48:08.390969+00:00 + 2025-10-11T21:50:55.933295+00:00 + python-feedgen Amir Taaki 2012-07-17 09:54:15+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - bitcoin.org - remove hackathon - 2023-08-01T03:48:08.390969+00:00 + 2025-10-11T21:50:55.933486+00:00 - The fear of advertisers' influence on the neutral content is why Wikipedia does not have advertisements. The corrupting influence is inevitable, which is why a good fun conference like the hackathon they just held should not have sponsors. In an email exchange on July 17th, 2012, Amir Taaki expressed his reluctance to sell speaker slots but acknowledged that it may become necessary in order to pay bills. He also stated that if such a situation were to arise, it would be made clear through scheduling and disclaimers that sponsored speakers were indeed sponsors.Taaki's email was in response to a discussion about the potential inclusion of sponsored speakers at events. While Taaki personally did not mind sponsored speakers, he believed that they should have somewhat relevant topics in order to prevent the event from becoming a "circlejerk."As an example, Taaki expressed interest in hearing about payments innovation outside of bitcoin.In an email thread, Jeff Garzik raised a point about the appropriateness of having a hackathon on bitcoin.org and how it seems more community-focused. However, Luke-Jr argued that the site is more community-focused anyways since developers don't use it as much as other sites like GitHub. In the same email thread, Luke-Jr suggests that Bitcoin Consultancy/Amir's contributions to development for the conference should be sufficient to ask for-profit organizations like Bitcoin Magazine for some form of pitching in. It was also discussed that material for pull requests would be preferred over mailing list emails and git push when working on the Satoshi client since it is more efficient. Additionally, it was mentioned that they lost money on the previous year's conference and are hoping to break even this year. Any profit made will go towards next year's conference and paying for things to make a better conference. They want to keep sponsorship and community parts highly separated, and speakers won't be sold a slot unless they have to pay the bills.Amir Taaki requested to remove the hackathon from bitcoin.org and replace it with a conference instead. Vladimir raised a fair point that the hackathon is appropriate for bitcoin.org as it is focused on dev-related activities, but the conference might or might not be. However, Jeff Garzik said that the conference is community-focused, so he doesn't object to it being on bitcoin.org. He also suggested using pull requests which are preferred over mailing list email and git push when working on the satoshi client.In an email dated July 15th, 2012, Amir Taaki reached out to the Bitcoin-development mailing list asking if they could remove the hackathon from the bitcoin.org website and replace it with a conference. This email was part of a chain that included a previous inquiry by Vladimir Marchenko about promoting Bitcoin Magazine on the bitcoin.org homepage. It is unclear whether or not either request was granted.Bitcoin.org is a website that provides information on Bitcoin, including news, wallets, and exchanges. However, it appears that the website also promotes private enterprises, such as Bitcoin Magazine. It is unclear why some enterprises are promoted on the site and not others. The email from Taaki includes a link to a Live Security Virtual Conference, which covers topics related to security and threat landscapes in IT management. This suggests that Taaki may have been interested in promoting this conference on the bitcoin.org website in place of the hackathon event.The request is to remove the hackathon event from bitcoin.org and replace it with a conference. It is unclear what conference is being referred to. The website bitcoin.org serves as a source of information for users interested in Bitcoin and its related events. The hackathon event is typically an event where developers come together to work on projects related to Bitcoin and other cryptocurrencies. The decision to remove the hackathon event and replace it with a conference would depend on the purpose and goals of the website. If the website is focused on providing information about Bitcoin development and innovation, then the hackathon event may be more appropriate. However, if the website is geared towards educating and informing users about the broader aspects of Bitcoin such as investment and adoption, then a conference may be more suitable.It is important to note that any changes made to the website should be done carefully and with consideration of the impact on the user experience. Additionally, it may be helpful to consult with other members of the Bitcoin community or experts in the field before making any significant changes to the website. 2012-07-17T09:54:15+00:00 + The fear of advertisers' influence on the neutral content is why Wikipedia does not have advertisements. The corrupting influence is inevitable, which is why a good fun conference like the hackathon they just held should not have sponsors. In an email exchange on July 17th, 2012, Amir Taaki expressed his reluctance to sell speaker slots but acknowledged that it may become necessary in order to pay bills. He also stated that if such a situation were to arise, it would be made clear through scheduling and disclaimers that sponsored speakers were indeed sponsors.Taaki's email was in response to a discussion about the potential inclusion of sponsored speakers at events. While Taaki personally did not mind sponsored speakers, he believed that they should have somewhat relevant topics in order to prevent the event from becoming a "circlejerk."As an example, Taaki expressed interest in hearing about payments innovation outside of bitcoin.In an email thread, Jeff Garzik raised a point about the appropriateness of having a hackathon on bitcoin.org and how it seems more community-focused. However, Luke-Jr argued that the site is more community-focused anyways since developers don't use it as much as other sites like GitHub. In the same email thread, Luke-Jr suggests that Bitcoin Consultancy/Amir's contributions to development for the conference should be sufficient to ask for-profit organizations like Bitcoin Magazine for some form of pitching in. It was also discussed that material for pull requests would be preferred over mailing list emails and git push when working on the Satoshi client since it is more efficient. Additionally, it was mentioned that they lost money on the previous year's conference and are hoping to break even this year. Any profit made will go towards next year's conference and paying for things to make a better conference. They want to keep sponsorship and community parts highly separated, and speakers won't be sold a slot unless they have to pay the bills.Amir Taaki requested to remove the hackathon from bitcoin.org and replace it with a conference instead. Vladimir raised a fair point that the hackathon is appropriate for bitcoin.org as it is focused on dev-related activities, but the conference might or might not be. However, Jeff Garzik said that the conference is community-focused, so he doesn't object to it being on bitcoin.org. He also suggested using pull requests which are preferred over mailing list email and git push when working on the satoshi client.In an email dated July 15th, 2012, Amir Taaki reached out to the Bitcoin-development mailing list asking if they could remove the hackathon from the bitcoin.org website and replace it with a conference. This email was part of a chain that included a previous inquiry by Vladimir Marchenko about promoting Bitcoin Magazine on the bitcoin.org homepage. It is unclear whether or not either request was granted.Bitcoin.org is a website that provides information on Bitcoin, including news, wallets, and exchanges. However, it appears that the website also promotes private enterprises, such as Bitcoin Magazine. It is unclear why some enterprises are promoted on the site and not others. The email from Taaki includes a link to a Live Security Virtual Conference, which covers topics related to security and threat landscapes in IT management. This suggests that Taaki may have been interested in promoting this conference on the bitcoin.org website in place of the hackathon event.The request is to remove the hackathon event from bitcoin.org and replace it with a conference. It is unclear what conference is being referred to. The website bitcoin.org serves as a source of information for users interested in Bitcoin and its related events. The hackathon event is typically an event where developers come together to work on projects related to Bitcoin and other cryptocurrencies. The decision to remove the hackathon event and replace it with a conference would depend on the purpose and goals of the website. If the website is focused on providing information about Bitcoin development and innovation, then the hackathon event may be more appropriate. However, if the website is geared towards educating and informing users about the broader aspects of Bitcoin such as investment and adoption, then a conference may be more suitable.It is important to note that any changes made to the website should be done carefully and with consideration of the impact on the user experience. Additionally, it may be helpful to consult with other members of the Bitcoin community or experts in the field before making any significant changes to the website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2012/combined_script-tests-invalid-script-in-script-valid-json-.xml b/static/bitcoin-dev/July_2012/combined_script-tests-invalid-script-in-script-valid-json-.xml index ca5f64da1e..0cd658b802 100644 --- a/static/bitcoin-dev/July_2012/combined_script-tests-invalid-script-in-script-valid-json-.xml +++ b/static/bitcoin-dev/July_2012/combined_script-tests-invalid-script-in-script-valid-json-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - script tests - invalid script in script_valid.json? - 2023-08-01T03:51:00.749287+00:00 + 2025-10-11T21:50:43.163267+00:00 + python-feedgen Matt Corallo 2012-07-31 14:39:45+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - script tests - invalid script in script_valid.json? - 2023-08-01T03:51:00.749287+00:00 + 2025-10-11T21:50:43.163453+00:00 - In a Bitcoin development mailing list discussion on July 30th, 2012, Gavin Andresen expressed the difficulty in testing check*sig functionality due to its reliance on previous unspent transactions and private keys. He welcomed any ideas for a simple data-driven format for testing. Ultraprune, which changes the block validation mechanism to only use a set of coins and the latest block pointer as state, was introduced. This state is represented by an abstract class with multiple implementations. A memory-backed coin set as state can be utilized for a testset run, with the list of coins and blocks loaded from a file.Gavin Andresen expressed interest in porting more tests into a data-driven format, including P2SH, checksig, checkmultisig, block verification, and DoS rules. However, he noted that check*sig tests are challenging because they require specific unspent transactions and private keys for testing. He welcomes brilliant ideas on a simple data-driven format. Block verification tests would be beneficial, with a collection of good and bad block chains starting from a common chain being very useful for regression testing. Andresen is willing to contribute pull requests in that direction.Stefan Thomas expressed his gratitude towards Gavin for adding data-driven test cases, emphasizing their usefulness. Jeff Garzik responded with agreement, stating that these test cases are a useful cross-platform tool. The conversation also touched upon the validity of a script involving OP_WITHIN and the addition of more data-driven test cases to bitcoin scripts.The post discusses the evaluation of a script containing three values, "1 0 1" and "WITHIN NOT". The first value (1) is tested to ensure it falls between the lower (0) and upper (1) values. This evaluates to true, resulting in a single byte of [01] being placed on the stack. The NOT operator then inverses this, resulting in a 0 byte false value of []. However, the context does not provide enough information to determine whether or not the script is valid.Overall, the discussion revolves around Gavin Andresen's interest in porting more tests to a data-driven format and his request for ideas on simplifying check*sig tests. The usefulness of data-driven test cases is acknowledged, and there is a query regarding the validity of a specific script. 2012-07-31T14:39:45+00:00 + In a Bitcoin development mailing list discussion on July 30th, 2012, Gavin Andresen expressed the difficulty in testing check*sig functionality due to its reliance on previous unspent transactions and private keys. He welcomed any ideas for a simple data-driven format for testing. Ultraprune, which changes the block validation mechanism to only use a set of coins and the latest block pointer as state, was introduced. This state is represented by an abstract class with multiple implementations. A memory-backed coin set as state can be utilized for a testset run, with the list of coins and blocks loaded from a file.Gavin Andresen expressed interest in porting more tests into a data-driven format, including P2SH, checksig, checkmultisig, block verification, and DoS rules. However, he noted that check*sig tests are challenging because they require specific unspent transactions and private keys for testing. He welcomes brilliant ideas on a simple data-driven format. Block verification tests would be beneficial, with a collection of good and bad block chains starting from a common chain being very useful for regression testing. Andresen is willing to contribute pull requests in that direction.Stefan Thomas expressed his gratitude towards Gavin for adding data-driven test cases, emphasizing their usefulness. Jeff Garzik responded with agreement, stating that these test cases are a useful cross-platform tool. The conversation also touched upon the validity of a script involving OP_WITHIN and the addition of more data-driven test cases to bitcoin scripts.The post discusses the evaluation of a script containing three values, "1 0 1" and "WITHIN NOT". The first value (1) is tested to ensure it falls between the lower (0) and upper (1) values. This evaluates to true, resulting in a single byte of [01] being placed on the stack. The NOT operator then inverses this, resulting in a 0 byte false value of []. However, the context does not provide enough information to determine whether or not the script is valid.Overall, the discussion revolves around Gavin Andresen's interest in porting more tests to a data-driven format and his request for ideas on simplifying check*sig tests. The usefulness of data-driven test cases is acknowledged, and there is a query regarding the validity of a specific script. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml b/static/bitcoin-dev/July_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml index 9736e9c8e1..44c6bd0d06 100644 --- a/static/bitcoin-dev/July_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml +++ b/static/bitcoin-dev/July_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption - 2023-08-01T05:20:12.304613+00:00 + 2025-10-11T21:51:51.196683+00:00 + python-feedgen Jean-Paul Kogelman 2013-12-26 11:48:12+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption - 2023-08-01T05:20:12.304613+00:00 + 2025-10-11T21:51:51.196827+00:00 - Jean-Paul Kogelman has updated a proposal on the Bitcointalk forum, making changes to the checksum and adding support for third-party KDF computation. The full proposal can be found at the provided link. The author of the post states that there have been no recent changes to the proposal, which includes expanding the salt, renaming the 'master seed', adding user-selectable KDF parameters, and a creation date field. They compare their proposal to BIP38 and question whether it could replace it.In response to the proposal, Mike Hearn points out that the proposal is not usable for SPV wallets unless it has a birthday. He suggests adding a UNIX time or a uint16 representing "days since birth of this specification" to solve this issue.The context discusses the usability of SPV wallets and the need for a birthday in order for them to function effectively. Without a birthday, scanning the blockchain can be slow and finding a fully indexed copy of the blockchain can be expensive and centralized. The suggestion is to add a UNIX time or a uint16 to address this problem.The document describes a method for encoding and optionally encrypting a Bitcoin HD Wallet master seed. The proposal provides two encoding methodologies in three lengths each, with one being a clear version and the other an encrypted representation. The proposed method uses various functions such as AES256Encrypt, AES256Decrypt, SHA256, RIPEMD160, scrypt, HMAC-SHA512, Base58Check, G, and N. It also includes test vectors and acknowledgements to related BIPs.In a forum discussion, Jean-Paul Kogelman proposes a Base58 encoded HD wallet master seed with optional encryption. Andreas M. Antonopoulos expresses interest in the proposal and calls it necessary and a great approach. Kogelman asks for feedback on the proposal but mentions that it is not yet in shippable form.The proposal by Jean-Paul Kogelman outlines a method for encoding and encrypting a Bitcoin HD Wallet master seed. It provides a compact representation of the master seed, making it easier to handle. A two-factor version allows for safe storage and creation of paper wallets by third parties. The proposal involves various functions and definitions and suggests modifications to BIP0038. Test vectors are provided, and acknowledgements are given to related BIPs and contributors. 2013-12-26T11:48:12+00:00 + Jean-Paul Kogelman has updated a proposal on the Bitcointalk forum, making changes to the checksum and adding support for third-party KDF computation. The full proposal can be found at the provided link. The author of the post states that there have been no recent changes to the proposal, which includes expanding the salt, renaming the 'master seed', adding user-selectable KDF parameters, and a creation date field. They compare their proposal to BIP38 and question whether it could replace it.In response to the proposal, Mike Hearn points out that the proposal is not usable for SPV wallets unless it has a birthday. He suggests adding a UNIX time or a uint16 representing "days since birth of this specification" to solve this issue.The context discusses the usability of SPV wallets and the need for a birthday in order for them to function effectively. Without a birthday, scanning the blockchain can be slow and finding a fully indexed copy of the blockchain can be expensive and centralized. The suggestion is to add a UNIX time or a uint16 to address this problem.The document describes a method for encoding and optionally encrypting a Bitcoin HD Wallet master seed. The proposal provides two encoding methodologies in three lengths each, with one being a clear version and the other an encrypted representation. The proposed method uses various functions such as AES256Encrypt, AES256Decrypt, SHA256, RIPEMD160, scrypt, HMAC-SHA512, Base58Check, G, and N. It also includes test vectors and acknowledgements to related BIPs.In a forum discussion, Jean-Paul Kogelman proposes a Base58 encoded HD wallet master seed with optional encryption. Andreas M. Antonopoulos expresses interest in the proposal and calls it necessary and a great approach. Kogelman asks for feedback on the proposal but mentions that it is not yet in shippable form.The proposal by Jean-Paul Kogelman outlines a method for encoding and encrypting a Bitcoin HD Wallet master seed. It provides a compact representation of the master seed, making it easier to handle. A two-factor version allows for safe storage and creation of paper wallets by third parties. The proposal involves various functions and definitions and suggests modifications to BIP0038. Test vectors are provided, and acknowledgements are given to related BIPs and contributors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_-RFC-Standard-for-private-keys-with-birth-timestamp.xml b/static/bitcoin-dev/July_2013/combined_-RFC-Standard-for-private-keys-with-birth-timestamp.xml index a75327e891..217bed6ae4 100644 --- a/static/bitcoin-dev/July_2013/combined_-RFC-Standard-for-private-keys-with-birth-timestamp.xml +++ b/static/bitcoin-dev/July_2013/combined_-RFC-Standard-for-private-keys-with-birth-timestamp.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] Standard for private keys with birth timestamp - 2023-08-01T05:21:00.115506+00:00 + 2025-10-11T21:51:15.071193+00:00 + python-feedgen Melvin Carvalho 2013-07-22 15:12:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [RFC] Standard for private keys with birth timestamp - 2023-08-01T05:21:00.115506+00:00 + 2025-10-11T21:51:15.071307+00:00 - On July 22, 2013, Pieter Wuille suggested a proposal to encode keys data with a birth timestamp using the "@" character. This encoding would not be incorporated into key serialization such as BIP32, as birth timestamps are typically associated with addresses rather than the keys themselves. The proposed encoding method would be particularly useful for non-extended standard serialized private keys and P2SH addresses.The choice of the "@" character as a separator was deliberate, as it is not present in commonly used encodings like base58, hex, or base64. This helps to ensure that the encoded data remains distinct and easily identifiable. However, one drawback of this approach is that there is no checksum-protection for the timestamp. Despite this, the advantage of increased genericity outweighs the potential lack of checksum protection.During discussions on the mailing list, someone suggested looking at RFC 4151, which had an idea on adding time stamps to identifiers. However, the consensus was that the loss of opacity resulting from incorporating timestamps did not justify the utility gained.In summary, the proposal put forward by Pieter Wuille suggests encoding keys data with a birth timestamp using the "@" character as a separator. This encoding method would be particularly useful for non-extended standard serialized private keys and P2SH addresses. Although there is no checksum-protection for the timestamp, the advantage of increased genericity makes this encoding method valuable. Furthermore, while suggestions were made to incorporate timestamps based on RFC 4151, the consensus was that the utility gained did not justify the loss of opacity. 2013-07-22T15:12:50+00:00 + On July 22, 2013, Pieter Wuille suggested a proposal to encode keys data with a birth timestamp using the "@" character. This encoding would not be incorporated into key serialization such as BIP32, as birth timestamps are typically associated with addresses rather than the keys themselves. The proposed encoding method would be particularly useful for non-extended standard serialized private keys and P2SH addresses.The choice of the "@" character as a separator was deliberate, as it is not present in commonly used encodings like base58, hex, or base64. This helps to ensure that the encoded data remains distinct and easily identifiable. However, one drawback of this approach is that there is no checksum-protection for the timestamp. Despite this, the advantage of increased genericity outweighs the potential lack of checksum protection.During discussions on the mailing list, someone suggested looking at RFC 4151, which had an idea on adding time stamps to identifiers. However, the consensus was that the loss of opacity resulting from incorporating timestamps did not justify the utility gained.In summary, the proposal put forward by Pieter Wuille suggests encoding keys data with a birth timestamp using the "@" character as a separator. This encoding method would be particularly useful for non-extended standard serialized private keys and P2SH addresses. Although there is no checksum-protection for the timestamp, the advantage of increased genericity makes this encoding method valuable. Furthermore, while suggestions were made to incorporate timestamps based on RFC 4151, the consensus was that the utility gained did not justify the loss of opacity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_-bitcoin-list-BitMail-p2p-Email-0-1-beta.xml b/static/bitcoin-dev/July_2013/combined_-bitcoin-list-BitMail-p2p-Email-0-1-beta.xml index 1ad524523d..8c8a14858b 100644 --- a/static/bitcoin-dev/July_2013/combined_-bitcoin-list-BitMail-p2p-Email-0-1-beta.xml +++ b/static/bitcoin-dev/July_2013/combined_-bitcoin-list-BitMail-p2p-Email-0-1-beta.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [bitcoin-list] BitMail - p2p Email 0.1. beta - 2023-08-01T05:28:27.632592+00:00 + 2025-10-11T21:51:55.442019+00:00 + python-feedgen Mike Hearn 2013-07-31 15:54:20+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [bitcoin-list] BitMail - p2p Email 0.1. beta - 2023-08-01T05:28:27.632592+00:00 + 2025-10-11T21:51:55.442153+00:00 - The discussion surrounding the Trusted Platform Module (TPM) began when a thread was accidentally posted on the wrong mailing list. The topic under discussion was the negative attention that TPM functionality had received in the past. Some attributed this negativity to the belief that TPM was pushed by a software/hardware monopoly for the purposes of digital rights management (DRM) and locking down systems. However, it was clarified that the published specifications and technologies of TPM were never intended for such uses. In fact, there has never been a TPM mode that would generally lock systems down or be useful for DRM. The approach taken by Xbox 360 would be more suitable for locking systems down for tampering or DRM.TPM is an independent security chip that becomes more useful when integrated with various components on the motherboard, BIOS, CPU, northbridge, and IOMMU. When combined, these components create a TCG-compliant TC environment that can be used for various purposes. Despite speculation that TPM could be utilized for DRM, this feature was never implemented. It was emphasized that cryptography is to DRM what TC is to DRM. The fear, uncertainty, and doubt (FUD) surrounding TPM were deemed unwarranted and undermined its potential as a cryptographic security tool.While TPMs are hardware components that provide permanent storage in the form of non-volatile random-access memory (NVRAM), they are designed to be cost-effective, resulting in slower performance. Most computers, excluding Macs, have included TPMs for quite some time. Although some motherboards may come with a TPM module header, the modules themselves are not pre-installed and may cost around $50-$100. TPM NVRAM is used to avoid wearing down the hard drive and extend its lifespan. However, the limited number of write cycles in TPM storage poses a challenge when securely deleting data. TPM NVRAM offers a solution to this issue, although it comes at a high usability cost. To achieve reliable and permanently erased data, encryption can be utilized on platters or solid-state drives (SSDs).In conclusion, TPMs serve as an essential component of computer security and are widely used across different systems. The misunderstandings surrounding their functionality were clarified, emphasizing that they were not intended for DRM purposes. Despite the low cost and limited write cycles associated with TPMs, they play a significant role in enhancing data security and extending the lifespan of storage devices. 2013-07-31T15:54:20+00:00 + The discussion surrounding the Trusted Platform Module (TPM) began when a thread was accidentally posted on the wrong mailing list. The topic under discussion was the negative attention that TPM functionality had received in the past. Some attributed this negativity to the belief that TPM was pushed by a software/hardware monopoly for the purposes of digital rights management (DRM) and locking down systems. However, it was clarified that the published specifications and technologies of TPM were never intended for such uses. In fact, there has never been a TPM mode that would generally lock systems down or be useful for DRM. The approach taken by Xbox 360 would be more suitable for locking systems down for tampering or DRM.TPM is an independent security chip that becomes more useful when integrated with various components on the motherboard, BIOS, CPU, northbridge, and IOMMU. When combined, these components create a TCG-compliant TC environment that can be used for various purposes. Despite speculation that TPM could be utilized for DRM, this feature was never implemented. It was emphasized that cryptography is to DRM what TC is to DRM. The fear, uncertainty, and doubt (FUD) surrounding TPM were deemed unwarranted and undermined its potential as a cryptographic security tool.While TPMs are hardware components that provide permanent storage in the form of non-volatile random-access memory (NVRAM), they are designed to be cost-effective, resulting in slower performance. Most computers, excluding Macs, have included TPMs for quite some time. Although some motherboards may come with a TPM module header, the modules themselves are not pre-installed and may cost around $50-$100. TPM NVRAM is used to avoid wearing down the hard drive and extend its lifespan. However, the limited number of write cycles in TPM storage poses a challenge when securely deleting data. TPM NVRAM offers a solution to this issue, although it comes at a high usability cost. To achieve reliable and permanently erased data, encryption can be utilized on platters or solid-state drives (SSDs).In conclusion, TPMs serve as an essential component of computer security and are widely used across different systems. The misunderstandings surrounding their functionality were clarified, emphasizing that they were not intended for DRM purposes. Despite the low cost and limited write cycles associated with TPMs, they play a significant role in enhancing data security and extending the lifespan of storage devices. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Anti-DoS-for-tx-replacement.xml b/static/bitcoin-dev/July_2013/combined_Anti-DoS-for-tx-replacement.xml index 6118116d52..0520d4693f 100644 --- a/static/bitcoin-dev/July_2013/combined_Anti-DoS-for-tx-replacement.xml +++ b/static/bitcoin-dev/July_2013/combined_Anti-DoS-for-tx-replacement.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Anti DoS for tx replacement - 2023-08-01T04:40:35.555673+00:00 + 2025-10-11T21:51:40.563398+00:00 + python-feedgen Peter Todd 2013-07-18 16:09:54+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Anti DoS for tx replacement - 2023-08-01T04:40:35.556670+00:00 + 2025-10-11T21:51:40.563622+00:00 - In an email exchange on July 18, 2013, Peter Todd suggests using the OP_DEPTH instruction to eliminate the risk of funds getting stuck in limbo. This opcode returns the current depth of the script's execution stack and can validate certain operations. However, Jeff Garzik raises concerns about scripts no longer being stateless due to the introduction of OP_DEPTH.Jeremy Spilman proposes a negotiation between the user and Arbitration Provider (AP) to determine escrow amounts, fee payments, and the duration of funds being tied if the AP doesn't close the channel. The implementation of OP_DEPTH can be done as part of a script v2 using the soft-fork mechanism outlined by Peter Todd. It is also suggested that MAST support should be implemented at the same time.A member on the Bitcoin-development mailing list commends Jeremy and Peter for creating a design that does not rely on replacement to work. This approach is seen as a solution to scalability issues without compromising security. However, Jeremy points out that the proposal could still have malleability weaknesses, where a miner changing the TxID of TX1 could invalidate the user's refund.The proposed sequence for Bitcoin channels involves multiple steps, such as creating unsigned transactions, negotiating escrow amounts, and setting lock times. The alternative to transaction replacement is having a trusted third party close the channel based on the latest transaction sent by the user. Concerns are raised about attackers and the need for mutual defense actions.Gavin Andresen suggests weakening the non-standard test to allow a window of time before transactions are deemed untrustworthy. He also mentions other technical issues that need to be addressed, such as implementing a memory-limited pool and child-pays-for-parent fees.Discussions about denial-of-service (DoS) attacks include proposals to incorporate bandwidth into contracts and implement fidelity bonds for security guarantees. The processing speed of ECDSA on modern cores and the possibility of double-spending in Bitcoin are also mentioned.In another email exchange, Peter Todd discusses the limitations and potential issues with transaction replacement on the Bitcoin network. Mike Hearn suggests ways to mitigate DoS attacks related to transaction replacement, such as limiting the number of chances for each input to do a replacement. The importance of protecting against DoS attacks without sacrificing features is debated.John Dillon questions Gavin Andresen's stance on Bitcoin security, while others defend his efforts to resist DoS attacks and improve testing and payment protocol implementation. The concept of high-frequency trading using transaction replacement is discussed, along with proposals to mitigate associated risks.Mike Hearn proposes a way to mitigate the risks of transaction replacement, suggesting that handling DoS as a prioritization problem and allowing someone to force CPU/bandwidth usage without disrupting normal transactions.The discussion on re-activating the replacement feature on Bitcoin's main network includes suggestions for developers to utilize and build apps demonstrating its usefulness and developing prototypes before re-activation. 2013-07-18T16:09:54+00:00 + In an email exchange on July 18, 2013, Peter Todd suggests using the OP_DEPTH instruction to eliminate the risk of funds getting stuck in limbo. This opcode returns the current depth of the script's execution stack and can validate certain operations. However, Jeff Garzik raises concerns about scripts no longer being stateless due to the introduction of OP_DEPTH.Jeremy Spilman proposes a negotiation between the user and Arbitration Provider (AP) to determine escrow amounts, fee payments, and the duration of funds being tied if the AP doesn't close the channel. The implementation of OP_DEPTH can be done as part of a script v2 using the soft-fork mechanism outlined by Peter Todd. It is also suggested that MAST support should be implemented at the same time.A member on the Bitcoin-development mailing list commends Jeremy and Peter for creating a design that does not rely on replacement to work. This approach is seen as a solution to scalability issues without compromising security. However, Jeremy points out that the proposal could still have malleability weaknesses, where a miner changing the TxID of TX1 could invalidate the user's refund.The proposed sequence for Bitcoin channels involves multiple steps, such as creating unsigned transactions, negotiating escrow amounts, and setting lock times. The alternative to transaction replacement is having a trusted third party close the channel based on the latest transaction sent by the user. Concerns are raised about attackers and the need for mutual defense actions.Gavin Andresen suggests weakening the non-standard test to allow a window of time before transactions are deemed untrustworthy. He also mentions other technical issues that need to be addressed, such as implementing a memory-limited pool and child-pays-for-parent fees.Discussions about denial-of-service (DoS) attacks include proposals to incorporate bandwidth into contracts and implement fidelity bonds for security guarantees. The processing speed of ECDSA on modern cores and the possibility of double-spending in Bitcoin are also mentioned.In another email exchange, Peter Todd discusses the limitations and potential issues with transaction replacement on the Bitcoin network. Mike Hearn suggests ways to mitigate DoS attacks related to transaction replacement, such as limiting the number of chances for each input to do a replacement. The importance of protecting against DoS attacks without sacrificing features is debated.John Dillon questions Gavin Andresen's stance on Bitcoin security, while others defend his efforts to resist DoS attacks and improve testing and payment protocol implementation. The concept of high-frequency trading using transaction replacement is discussed, along with proposals to mitigate associated risks.Mike Hearn proposes a way to mitigate the risks of transaction replacement, suggesting that handling DoS as a prioritization problem and allowing someone to force CPU/bandwidth usage without disrupting normal transactions.The discussion on re-activating the replacement feature on Bitcoin's main network includes suggestions for developers to utilize and build apps demonstrating its usefulness and developing prototypes before re-activation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_BitMail-p2p-Email-0-1-beta.xml b/static/bitcoin-dev/July_2013/combined_BitMail-p2p-Email-0-1-beta.xml index ad95b722ba..70574a2ca1 100644 --- a/static/bitcoin-dev/July_2013/combined_BitMail-p2p-Email-0-1-beta.xml +++ b/static/bitcoin-dev/July_2013/combined_BitMail-p2p-Email-0-1-beta.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BitMail - p2p Email 0.1. beta - 2023-08-01T05:27:36.990090+00:00 + 2025-10-11T21:51:38.438691+00:00 + python-feedgen Randolph D. 2013-07-31 16:11:32+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - BitMail - p2p Email 0.1. beta - 2023-08-01T05:27:36.990090+00:00 + 2025-10-11T21:51:38.438844+00:00 - BitMail is a secure peer-to-peer email service that operates without relying on a central server. It utilizes the Echo Protocol to establish a fully decentralized email network. The system incorporates features such as key/repleo exchange, chat, and instant messaging. To ensure high levels of security, BitMail implements strong end-to-end multi-encryption using PGP/AES over SSL with libgcrypt. Additionally, the platform integrates with Libspoton and employs an extra layer of security called the GB-feature for emails.One notable aspect of BitMail is its approach to data retention. Messages are stored for only one week and have size limitations. The absence of traditional addresses means that users must grant permission by sharing a small file in order to receive messages, effectively eliminating spam. To further enhance security, BitMail leverages the Trusted Platform Module (TPM) chip. This hardware-based solution securely stores cryptographic keys and other sensitive data, ensuring protection against unauthorized access. By utilizing the TPM chip, BitMail can reliably destroy keys for data that may otherwise be un-erasable, particularly on SSD devices.BitMail was developed by Adam Langley, a respected figure in the field of cryptography. The platform is written in Go and operates over Tor to provide resistance against traffic analysis. It prioritizes forward security and takes advantage of the NVRAM in a TPM chip to destroy keys, thus addressing the issue of erasing data on modern disks. These disks often employ log structured file systems and firmware remapping, making it challenging to securely delete information.However, concerns have arisen regarding a similar software called "GoldBug." Multiple posts from apparent sock accounts have been observed across various forums, including the Tor Project and GnuPG mailing lists. The similarity in names and timing of these posts raises doubts about the legitimacy of the GoldBug software. Thus, it is essential to exercise caution when considering alternative options to BitMail.In a separate email thread, Randolph D. discusses another secure peer-to-peer email system called Key/Repleo-Exchange. This system operates without a central server and uses the Echo Protocol to create a fully decentralized email network. It offers built-in chat and instant messaging functionalities, employing strong end-to-end multi-encryption with PGP/AES over SSL via libgcrypt. The integration of Libspoton enhances security, and an additional layer called the GB-feature provides added protection for emails. Notably, this system avoids data retention and does not rely on a web of trust. The software is open-source under the BSD license.Randolph D. is actively seeking someone with a server to help implement the Key/Repleo-Exchange system. However, the emergence of multiple posts from sock accounts discussing a similarly named software, GoldBug, raises concerns about its legitimacy. It is crucial to exercise caution and carefully evaluate the credibility of any alternative systems to ensure the highest level of security and privacy. 2013-07-31T16:11:32+00:00 + BitMail is a secure peer-to-peer email service that operates without relying on a central server. It utilizes the Echo Protocol to establish a fully decentralized email network. The system incorporates features such as key/repleo exchange, chat, and instant messaging. To ensure high levels of security, BitMail implements strong end-to-end multi-encryption using PGP/AES over SSL with libgcrypt. Additionally, the platform integrates with Libspoton and employs an extra layer of security called the GB-feature for emails.One notable aspect of BitMail is its approach to data retention. Messages are stored for only one week and have size limitations. The absence of traditional addresses means that users must grant permission by sharing a small file in order to receive messages, effectively eliminating spam. To further enhance security, BitMail leverages the Trusted Platform Module (TPM) chip. This hardware-based solution securely stores cryptographic keys and other sensitive data, ensuring protection against unauthorized access. By utilizing the TPM chip, BitMail can reliably destroy keys for data that may otherwise be un-erasable, particularly on SSD devices.BitMail was developed by Adam Langley, a respected figure in the field of cryptography. The platform is written in Go and operates over Tor to provide resistance against traffic analysis. It prioritizes forward security and takes advantage of the NVRAM in a TPM chip to destroy keys, thus addressing the issue of erasing data on modern disks. These disks often employ log structured file systems and firmware remapping, making it challenging to securely delete information.However, concerns have arisen regarding a similar software called "GoldBug." Multiple posts from apparent sock accounts have been observed across various forums, including the Tor Project and GnuPG mailing lists. The similarity in names and timing of these posts raises doubts about the legitimacy of the GoldBug software. Thus, it is essential to exercise caution when considering alternative options to BitMail.In a separate email thread, Randolph D. discusses another secure peer-to-peer email system called Key/Repleo-Exchange. This system operates without a central server and uses the Echo Protocol to create a fully decentralized email network. It offers built-in chat and instant messaging functionalities, employing strong end-to-end multi-encryption with PGP/AES over SSL via libgcrypt. The integration of Libspoton enhances security, and an additional layer called the GB-feature provides added protection for emails. Notably, this system avoids data retention and does not rely on a web of trust. The software is open-source under the BSD license.Randolph D. is actively seeking someone with a server to help implement the Key/Repleo-Exchange system. However, the emergence of multiple posts from sock accounts discussing a similarly named software, GoldBug, raises concerns about its legitimacy. It is crucial to exercise caution and carefully evaluate the credibility of any alternative systems to ensure the highest level of security and privacy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Distributing-low-POW-headers.xml b/static/bitcoin-dev/July_2013/combined_Distributing-low-POW-headers.xml index 16bdd1b88f..76d47c6628 100644 --- a/static/bitcoin-dev/July_2013/combined_Distributing-low-POW-headers.xml +++ b/static/bitcoin-dev/July_2013/combined_Distributing-low-POW-headers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Distributing low POW headers - 2023-08-01T05:23:49.451326+00:00 + 2025-10-11T21:51:19.315714+00:00 + python-feedgen Tier Nolan 2013-07-28 20:07:34+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Distributing low POW headers - 2023-08-01T05:23:49.451326+00:00 + 2025-10-11T21:51:19.315850+00:00 - The email thread focuses on the possibility of distributing low proof-of-work (POW) block headers in the Bitcoin network to address issues related to forks and orphan blocks. The idea is to broadcast these headers approximately once every 9 seconds, with the aim of incentivizing miners to take them into account. It is suggested that distributing headers with 1/64th of the standard POW could help make forks less likely and prevent a fork from becoming the main chain if it is within 16 mini-confirms.There are concerns regarding the impact this change may have on miners' network connections and the potential economic implications. However, it is noted that adding fields to the header is challenging, so the distribution of headers could be implemented as a coinbase extra-nonce or by hashing an auxiliary header. By broadcasting all headers, clients would be able to count orphan blocks and measure their impact.Another suggestion discussed in the email thread involves setting a threshold relative to the height of the best block to determine when orphan blocks or headers should no longer be propagated further. This change should be compatible with the Peer-to-Peer (P2P) protocol and could be based on inventories.The email also mentions that Pieter Wuille is working on allowing Bitcoin to propagate and utilize pure block headers, which would be a step towards Simplified Payment Verification (SPV) and partial UTXO mode.In a separate email exchange, Peter Todd requests equations and data justifying the "magic constants" proposed in the distribution of headers. These include broadcasting headers once every nine seconds and giving them a value worth around four times as much as a full block. The goal is to create an incentive for miners to consider headers and ensure that a fork only becomes the main chain if it is within 16 mini-confirms.The proposal suggests changes to the current behavior of relaying blocks to peers and discusses the broadcast of headers even if they do not meet full POW. It is also proposed to display a warning on the client if a fork receives more than 15% of the hashing power.The proposal further suggests changes in the rules for distinguishing between forks and a BIP (Bitcoin Improvement Proposal). These changes involve broadcasting low POW headers, using header information to decide on the longest chain, and providing advantages to this approach. The distribution of low POW headers would be based on forwarding the first block header messages that have more than 1/64 of the standard POW requirements. Each link would receive extra credit for headers received, and the POW for a block would be calculated based on these credits. By following this rule, the top fork with the most hashing power would eventually catch up and win, incentivizing all miners to comply.To determine the longest chain, each link would receive extra credit for headers received, and miners would need to maintain a short-term view of the entire header tree. As long as miners keep headers for 30-40 blocks, they are likely to have all headers back to any reasonable fork point. This allows the top fork to be considered longer, even if it has two fewer blocks. If 75% of the miners follow this rule, the top fork will eventually prevail, encouraging the other 25% to comply. Even without complete agreement on headers received, the fork with the most hashing power will naturally gain the majority of headers, resolving ties quickly.Overall, the email thread discusses various proposals and considerations aimed at improving the Bitcoin network consensus, addressing issues related to forks, orphan blocks, and miner incentives. The suggested changes involve distributing low POW headers, modifying the behavior of relaying blocks, and establishing rules for distinguishing between forks. These proposals aim to enhance the stability and security of the Bitcoin network while maintaining compatibility with existing protocols and minimizing disruptions. 2013-07-28T20:07:34+00:00 + The email thread focuses on the possibility of distributing low proof-of-work (POW) block headers in the Bitcoin network to address issues related to forks and orphan blocks. The idea is to broadcast these headers approximately once every 9 seconds, with the aim of incentivizing miners to take them into account. It is suggested that distributing headers with 1/64th of the standard POW could help make forks less likely and prevent a fork from becoming the main chain if it is within 16 mini-confirms.There are concerns regarding the impact this change may have on miners' network connections and the potential economic implications. However, it is noted that adding fields to the header is challenging, so the distribution of headers could be implemented as a coinbase extra-nonce or by hashing an auxiliary header. By broadcasting all headers, clients would be able to count orphan blocks and measure their impact.Another suggestion discussed in the email thread involves setting a threshold relative to the height of the best block to determine when orphan blocks or headers should no longer be propagated further. This change should be compatible with the Peer-to-Peer (P2P) protocol and could be based on inventories.The email also mentions that Pieter Wuille is working on allowing Bitcoin to propagate and utilize pure block headers, which would be a step towards Simplified Payment Verification (SPV) and partial UTXO mode.In a separate email exchange, Peter Todd requests equations and data justifying the "magic constants" proposed in the distribution of headers. These include broadcasting headers once every nine seconds and giving them a value worth around four times as much as a full block. The goal is to create an incentive for miners to consider headers and ensure that a fork only becomes the main chain if it is within 16 mini-confirms.The proposal suggests changes to the current behavior of relaying blocks to peers and discusses the broadcast of headers even if they do not meet full POW. It is also proposed to display a warning on the client if a fork receives more than 15% of the hashing power.The proposal further suggests changes in the rules for distinguishing between forks and a BIP (Bitcoin Improvement Proposal). These changes involve broadcasting low POW headers, using header information to decide on the longest chain, and providing advantages to this approach. The distribution of low POW headers would be based on forwarding the first block header messages that have more than 1/64 of the standard POW requirements. Each link would receive extra credit for headers received, and the POW for a block would be calculated based on these credits. By following this rule, the top fork with the most hashing power would eventually catch up and win, incentivizing all miners to comply.To determine the longest chain, each link would receive extra credit for headers received, and miners would need to maintain a short-term view of the entire header tree. As long as miners keep headers for 30-40 blocks, they are likely to have all headers back to any reasonable fork point. This allows the top fork to be considered longer, even if it has two fewer blocks. If 75% of the miners follow this rule, the top fork will eventually prevail, encouraging the other 25% to comply. Even without complete agreement on headers received, the fork with the most hashing power will naturally gain the majority of headers, resolving ties quickly.Overall, the email thread discusses various proposals and considerations aimed at improving the Bitcoin network consensus, addressing issues related to forks, orphan blocks, and miner incentives. The suggested changes involve distributing low POW headers, modifying the behavior of relaying blocks, and establishing rules for distinguishing between forks. These proposals aim to enhance the stability and security of the Bitcoin network while maintaining compatibility with existing protocols and minimizing disruptions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Endianness-was-Linux-packaging-letter-.xml b/static/bitcoin-dev/July_2013/combined_Endianness-was-Linux-packaging-letter-.xml index 8dddf9664a..3a04f8804f 100644 --- a/static/bitcoin-dev/July_2013/combined_Endianness-was-Linux-packaging-letter-.xml +++ b/static/bitcoin-dev/July_2013/combined_Endianness-was-Linux-packaging-letter-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Endianness (was: Linux packaging letter) - 2023-08-01T05:25:44.775584+00:00 + 2025-10-11T21:51:34.191901+00:00 + python-feedgen Gregory Maxwell 2013-07-24 04:09:01+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Endianness (was: Linux packaging letter) - 2023-08-01T05:25:44.775584+00:00 + 2025-10-11T21:51:34.192043+00:00 - In a series of email exchanges from July 23 and 24, 2013, several individuals discuss the protocol used for transmitting data through wires, specifically in relation to the Bitcoin codebase. Gregory Maxwell notes that the protocol is predominantly Little Endian (LE), but there is still enough Big Endian (BE) to be mindful of. The transmission order is crucial for effective communication between devices and networks. While the protocol may not be consistent across all systems, it is essential to understand and account for variations in transmission order.Wendell raises a question about the barrier to achieving endian independence in the Bitcoin codebase. In response, it is stated that there isn't a significant obstacle to achieving endian independence, and fixing the memory order to and from the wire is a common way to address endianness. However, due to the use of authenticated data structures in Bitcoin, simply swapping the byte order on input is not sufficient. Some data needs to be hashed for authentication, which requires a specific order. Luke had previously attempted to address this issue but had not yet succeeded. It appears that fixing this problem would be challenging, and without a compelling reason to do so, no progress has been made in resolving it.In another conversation on July 24, 2013, Wendell asks Luke about the presence of a substantial barrier to achieving endian independence in the Bitcoin codebase. Luke responds, mentioning an 'endian' branch in his repository but admits that it still does not work as intended. He also states that he has not yet identified why it is not functioning correctly.The discussion continues with Douglas Huff stating that attempting to package and ship big endian binaries would be negligent. This implies that prioritizing little endian compatibility is necessary for proper functionality and reliable distribution.Overall, these email exchanges highlight the importance of understanding and addressing endianness in the Bitcoin codebase. While efforts have been made to achieve endian independence, challenges remain due to the use of authenticated data structures. The need for attention to detail in communication protocols and awareness of transmission order variations is emphasized throughout the conversation. 2013-07-24T04:09:01+00:00 + In a series of email exchanges from July 23 and 24, 2013, several individuals discuss the protocol used for transmitting data through wires, specifically in relation to the Bitcoin codebase. Gregory Maxwell notes that the protocol is predominantly Little Endian (LE), but there is still enough Big Endian (BE) to be mindful of. The transmission order is crucial for effective communication between devices and networks. While the protocol may not be consistent across all systems, it is essential to understand and account for variations in transmission order.Wendell raises a question about the barrier to achieving endian independence in the Bitcoin codebase. In response, it is stated that there isn't a significant obstacle to achieving endian independence, and fixing the memory order to and from the wire is a common way to address endianness. However, due to the use of authenticated data structures in Bitcoin, simply swapping the byte order on input is not sufficient. Some data needs to be hashed for authentication, which requires a specific order. Luke had previously attempted to address this issue but had not yet succeeded. It appears that fixing this problem would be challenging, and without a compelling reason to do so, no progress has been made in resolving it.In another conversation on July 24, 2013, Wendell asks Luke about the presence of a substantial barrier to achieving endian independence in the Bitcoin codebase. Luke responds, mentioning an 'endian' branch in his repository but admits that it still does not work as intended. He also states that he has not yet identified why it is not functioning correctly.The discussion continues with Douglas Huff stating that attempting to package and ship big endian binaries would be negligent. This implies that prioritizing little endian compatibility is necessary for proper functionality and reliable distribution.Overall, these email exchanges highlight the importance of understanding and addressing endianness in the Bitcoin codebase. While efforts have been made to achieve endian independence, challenges remain due to the use of authenticated data structures. The need for attention to detail in communication protocols and awareness of transmission order variations is emphasized throughout the conversation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_HTTP-REST-API-for-bitcoind.xml b/static/bitcoin-dev/July_2013/combined_HTTP-REST-API-for-bitcoind.xml index fe18e6c63a..5f8ad1d0b4 100644 --- a/static/bitcoin-dev/July_2013/combined_HTTP-REST-API-for-bitcoind.xml +++ b/static/bitcoin-dev/July_2013/combined_HTTP-REST-API-for-bitcoind.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - HTTP REST API for bitcoind - 2023-08-01T05:22:02.236718+00:00 + 2025-10-11T21:51:46.937189+00:00 + python-feedgen Rune Kjær Svendsen 2013-08-10 20:30:46+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - HTTP REST API for bitcoind - 2023-08-01T05:22:02.236718+00:00 + 2025-10-11T21:51:46.937420+00:00 - The conversation revolves around implementing an HTTP REST wrapper around bitcoind's RPC interface in Python. The goal is to create a simple HTTP server that can translate HTTP GET requests into relevant RPC request and respond with the required data. There is a discussion about adding usual HTTP authentication/SSL stuff to the REST API so that SPV users could decide to run their own instance of the API. It was suggested that a trusted party could set up the server for users of Bitcoin Wallet. However, it was argued that anyone who wants HTTP authentication or TLS can wrap it with nginx or something similar and put appropriate restrictions in place on incoming requests to keep it secure.In an email exchange between Andreas Schildbach and Mark, they propose adding HTTP authentication/SSL to the REST API so that SPV users can run their own instance of the API or a trusted party can set up a server. Andreas suggests he would be willing to set it up for users of Bitcoin Wallet. Pieter Wuille expresses concern about the security risks and potential DoS risks associated with exposing an HTTP-based interface publicly. On the other hand, Michael argues that there are benefits to having a REST interface that is exposed publicly. While there is support for the HTTP interface, it is suggested that it be used only for trusted local applications and debugging.Andy Parkins suggests reducing the blockchain storage requirement for SPV clients to allow more nodes to participate in the network and reduce the load on full nodes. Peter Todd proposes a "Partial UTXO" mode where miners don't need to keep the entire chain as long as they don't mine transactions spending unverified UTXOs. They discuss the security risks of relying on unauthenticated UTXO data and the need for UTXO commitments. They also discuss the difference between SPV and full security and the benefits of fetching blocks by transactions.In another conversation between Andreas Schildbach and Pieter Wuille, they discuss the possibility of adding HTTP authentication/SSL to the REST API for SPV users to run their own instance or for trusted parties to set up servers. Wuille expresses concern about the security risks and potential DoS risks of exposing the HTTP-based interface publicly. He suggests that the HTTP interface should only be used for trusted local applications and debugging.Peter Todd proposes exposing the UTXO set of a given address to enable SPV wallets to sweep previously unknown private keys. However, this is deemed undesirable due to increased resource usage and vulnerability to DoS attacks. Todd suggests adding HTTP authentication/SSL to the REST API instead. They also discuss the use of address-indexed UXTOs and the issues with relying on unauthenticated data. They consider paper wallets as a potential solution but note some inherent problems.The conversation discusses the use of REST API for SPV clients, the benefits of reducing the blockchain storage requirement, and the security risks associated with exposing an HTTP-based interface publicly. The discussion also covers the need for authenticated UTXO data and the challenges of maintaining a headers-only blockchain. There is debate about the involvement of the blockchain in verifying transactions and the importance of the UTXO set. Finally, there is a suggestion to add a new URL to trace the providence of any transaction without needing to maintain the entire chain.In a discussion on the Bitcoin development mailing list, the addition of a URL for tracing the providence of any transaction without maintaining the entire blockchain was suggested. This feature would be beneficial for Simplified Payment Verification (SPV) clients. However, it was clarified that no such index is maintained by default and enabling "-txindex" is necessary to access it.Another proposal was made to expose the Unspent Transaction Output (UTXO) set of a given address. While this would be useful for SPV wallets to sweep previously unknown private keys, it was noted that there is currently no way to authenticate this data, which could potentially lead to fraudulent transactions.Jeff Garzik proposed the addition of an HTTP REST API for bitcoind, which would provide external access to transaction, address, and block indices. This would enable decentralized block explorer capabilities. The first two implemented API calls allow for simple queries based on block or transaction hash. The aim of this interface is to provide unauthenticated, public blockchain information, with no plans to add wallet interfacing or manipulation via this API.A recent pull request on Github further supports the implementation of the HTTP REST API for bitcoind. It suggests adding features like Accept and Accept-Encoding headers, as well as an API version number in the URL. Additionally, having APIs corresponding to Bitcoin addr and version messages would be helpful for certain use cases.Overall, the goal of the proposed HTTP REST API is to provide easy access to unauthenticated, public blockchain information. It does not include wallet interfacing or manipulation capabilities and has received positive feedback from developers interested in utilizing the API for their projects. 2013-08-10T20:30:46+00:00 + The conversation revolves around implementing an HTTP REST wrapper around bitcoind's RPC interface in Python. The goal is to create a simple HTTP server that can translate HTTP GET requests into relevant RPC request and respond with the required data. There is a discussion about adding usual HTTP authentication/SSL stuff to the REST API so that SPV users could decide to run their own instance of the API. It was suggested that a trusted party could set up the server for users of Bitcoin Wallet. However, it was argued that anyone who wants HTTP authentication or TLS can wrap it with nginx or something similar and put appropriate restrictions in place on incoming requests to keep it secure.In an email exchange between Andreas Schildbach and Mark, they propose adding HTTP authentication/SSL to the REST API so that SPV users can run their own instance of the API or a trusted party can set up a server. Andreas suggests he would be willing to set it up for users of Bitcoin Wallet. Pieter Wuille expresses concern about the security risks and potential DoS risks associated with exposing an HTTP-based interface publicly. On the other hand, Michael argues that there are benefits to having a REST interface that is exposed publicly. While there is support for the HTTP interface, it is suggested that it be used only for trusted local applications and debugging.Andy Parkins suggests reducing the blockchain storage requirement for SPV clients to allow more nodes to participate in the network and reduce the load on full nodes. Peter Todd proposes a "Partial UTXO" mode where miners don't need to keep the entire chain as long as they don't mine transactions spending unverified UTXOs. They discuss the security risks of relying on unauthenticated UTXO data and the need for UTXO commitments. They also discuss the difference between SPV and full security and the benefits of fetching blocks by transactions.In another conversation between Andreas Schildbach and Pieter Wuille, they discuss the possibility of adding HTTP authentication/SSL to the REST API for SPV users to run their own instance or for trusted parties to set up servers. Wuille expresses concern about the security risks and potential DoS risks of exposing the HTTP-based interface publicly. He suggests that the HTTP interface should only be used for trusted local applications and debugging.Peter Todd proposes exposing the UTXO set of a given address to enable SPV wallets to sweep previously unknown private keys. However, this is deemed undesirable due to increased resource usage and vulnerability to DoS attacks. Todd suggests adding HTTP authentication/SSL to the REST API instead. They also discuss the use of address-indexed UXTOs and the issues with relying on unauthenticated data. They consider paper wallets as a potential solution but note some inherent problems.The conversation discusses the use of REST API for SPV clients, the benefits of reducing the blockchain storage requirement, and the security risks associated with exposing an HTTP-based interface publicly. The discussion also covers the need for authenticated UTXO data and the challenges of maintaining a headers-only blockchain. There is debate about the involvement of the blockchain in verifying transactions and the importance of the UTXO set. Finally, there is a suggestion to add a new URL to trace the providence of any transaction without needing to maintain the entire chain.In a discussion on the Bitcoin development mailing list, the addition of a URL for tracing the providence of any transaction without maintaining the entire blockchain was suggested. This feature would be beneficial for Simplified Payment Verification (SPV) clients. However, it was clarified that no such index is maintained by default and enabling "-txindex" is necessary to access it.Another proposal was made to expose the Unspent Transaction Output (UTXO) set of a given address. While this would be useful for SPV wallets to sweep previously unknown private keys, it was noted that there is currently no way to authenticate this data, which could potentially lead to fraudulent transactions.Jeff Garzik proposed the addition of an HTTP REST API for bitcoind, which would provide external access to transaction, address, and block indices. This would enable decentralized block explorer capabilities. The first two implemented API calls allow for simple queries based on block or transaction hash. The aim of this interface is to provide unauthenticated, public blockchain information, with no plans to add wallet interfacing or manipulation via this API.A recent pull request on Github further supports the implementation of the HTTP REST API for bitcoind. It suggests adding features like Accept and Accept-Encoding headers, as well as an API version number in the URL. Additionally, having APIs corresponding to Bitcoin addr and version messages would be helpful for certain use cases.Overall, the goal of the proposed HTTP REST API is to provide easy access to unauthenticated, public blockchain information. It does not include wallet interfacing or manipulation capabilities and has received positive feedback from developers interested in utilizing the API for their projects. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Introducing-BitcoinKit-framework.xml b/static/bitcoin-dev/July_2013/combined_Introducing-BitcoinKit-framework.xml index af9c2dee37..3383514d03 100644 --- a/static/bitcoin-dev/July_2013/combined_Introducing-BitcoinKit-framework.xml +++ b/static/bitcoin-dev/July_2013/combined_Introducing-BitcoinKit-framework.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Introducing BitcoinKit.framework - 2023-08-01T05:18:25.019063+00:00 + 2025-10-11T21:51:17.192611+00:00 + python-feedgen Mike Hearn 2013-07-22 13:08:58+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Introducing BitcoinKit.framework - 2023-08-01T05:18:25.019063+00:00 + 2025-10-11T21:51:17.192795+00:00 - Recently, example code has been sent to Wendell and co to use CPPJVM for bitcoinj from native code. The example code is a C++ like Hello World app that can be found on Github. Further discussions regarding this topic should take place on the bitcoinj mailing list.Bitcoinj, a Java-based implementation of the Bitcoin protocol, does not download all headers but only from the last checkpoint and discards the old ones. It differs considerably from Bitcoind and will likely continue to do so in the future. The team plans to store only relevant outputs in the wallet to save memory, as some users have wallets that don't fit in RAM. They aim to use simplified payment verification (SPV) mode, which is headers-first sync without the full block sync step, replacing it with bloom/birthday-based fetching of blocks interesting to associated wallets. In SPV, the mempool needs to be disabled and there will be other small changes. Pieter Wuille is currently working on headers-first sync, which he believes is generally very useful and fixes many edge-cases block synchronization that the blockchain currently experiences. This is also a first step towards SPV mode.In a message thread from 2013, Bitcoin developer Mike Hearn expressed his approval of the idea of headers-first sync. This approach involves synchronizing only the headers of a blockchain before requesting blocks along the best chain. It is seen as a useful step towards simplified payment verification (SPV) mode, where full block syncing is replaced with a bloom-based fetching of interesting blocks for associated wallets. Although there will be more changes required for SPV mode, disabling the mempool and making small modifications, the separate headers-sync phase will be the bulk of the work.In 2010, Satoshi suggested that client-only nodes should receive full blocks so they can scan for their own transactions instead of indexing them. The initial download would only require downloading headers as there cannot be any payments before the program's first run. The code for this mode is mostly implemented and available on Github, but it's not fully finished for end-users. Client-only re-implementations would not need to implement EvalScript at all or at most just implement the five ops used by the standard transaction templates. During a discussion in San Jose, Wendell expressed interest in hiring someone to complete a patch. Pieter Wuille introduced him to Eric Lombrozo who also showed interest but has since become busy and no detailed estimate has been produced. Wendell is interested in an open discussion around adding SPV support to bitcoind and is willing to fund or co-fund the project. He encourages options whenever possible including micro-stripped-VMs and transpilation. Mike Hearn offered to send Satoshi's old SPV patch to assist with the implementation of SPV mode in bitcoind.The discussion is about extending the BitcoinKit.framework to handle the Basic SPV concept, which was originally planned by Satoshi. However, it was not completed due to several reasons such as lack of confidence in understanding the code and the risk involved in making invasive changes to core validation code. Therefore, a separate implementation was created for better risk management and to provide an object-oriented API that people could use to build a variety of apps. Additionally, the bitcoind codebase would require serious changes for mobiles beyond that required for ordinary SPV support, making it unclear if the decision to create a separate implementation was the right call. The situation is different now, with more unit tests and more people with a good understanding of the code. If someone wanted to implement SPV mode in bitcoind, they could be sent Satoshi's old patch, which indicates the basic cut lines.There are different options for implementing a native client for Bitcoin, including embedding the Java Virtual Machine (JVM) or transpiling bitcoinj to C++. While it is possible to reduce the size of the JVM to a few megabytes, it may not be necessary for desktop apps since bandwidth has improved. Portability to Android is already possible because it is Java-based, but iOS is a challenge due to Apple's restrictions on wallet apps in its App Store.One option is to rewrite bitcoinj in C++, but this is unnecessary given the existence of j2c, which does an excellent job of transpiling Java to C++. Another option is to embed the JVM and link it with the native app using a thin interface that calls into the Java code when user-visible events occur. This approach is less ambitious than transpilation but requires writing some Java code. The auto-translator javacpp can help with this.Rewriting bitcoinj in C++ or transpiling it to C++ requires a significant amount of work but could result in a stable, portable, and extendable piece of code. Embedding the JVM requires less work and can achieve good results quickly. The JVM can be bundled with the app and stripped down if necessary to reduce the download 2013-07-22T13:08:58+00:00 + Recently, example code has been sent to Wendell and co to use CPPJVM for bitcoinj from native code. The example code is a C++ like Hello World app that can be found on Github. Further discussions regarding this topic should take place on the bitcoinj mailing list.Bitcoinj, a Java-based implementation of the Bitcoin protocol, does not download all headers but only from the last checkpoint and discards the old ones. It differs considerably from Bitcoind and will likely continue to do so in the future. The team plans to store only relevant outputs in the wallet to save memory, as some users have wallets that don't fit in RAM. They aim to use simplified payment verification (SPV) mode, which is headers-first sync without the full block sync step, replacing it with bloom/birthday-based fetching of blocks interesting to associated wallets. In SPV, the mempool needs to be disabled and there will be other small changes. Pieter Wuille is currently working on headers-first sync, which he believes is generally very useful and fixes many edge-cases block synchronization that the blockchain currently experiences. This is also a first step towards SPV mode.In a message thread from 2013, Bitcoin developer Mike Hearn expressed his approval of the idea of headers-first sync. This approach involves synchronizing only the headers of a blockchain before requesting blocks along the best chain. It is seen as a useful step towards simplified payment verification (SPV) mode, where full block syncing is replaced with a bloom-based fetching of interesting blocks for associated wallets. Although there will be more changes required for SPV mode, disabling the mempool and making small modifications, the separate headers-sync phase will be the bulk of the work.In 2010, Satoshi suggested that client-only nodes should receive full blocks so they can scan for their own transactions instead of indexing them. The initial download would only require downloading headers as there cannot be any payments before the program's first run. The code for this mode is mostly implemented and available on Github, but it's not fully finished for end-users. Client-only re-implementations would not need to implement EvalScript at all or at most just implement the five ops used by the standard transaction templates. During a discussion in San Jose, Wendell expressed interest in hiring someone to complete a patch. Pieter Wuille introduced him to Eric Lombrozo who also showed interest but has since become busy and no detailed estimate has been produced. Wendell is interested in an open discussion around adding SPV support to bitcoind and is willing to fund or co-fund the project. He encourages options whenever possible including micro-stripped-VMs and transpilation. Mike Hearn offered to send Satoshi's old SPV patch to assist with the implementation of SPV mode in bitcoind.The discussion is about extending the BitcoinKit.framework to handle the Basic SPV concept, which was originally planned by Satoshi. However, it was not completed due to several reasons such as lack of confidence in understanding the code and the risk involved in making invasive changes to core validation code. Therefore, a separate implementation was created for better risk management and to provide an object-oriented API that people could use to build a variety of apps. Additionally, the bitcoind codebase would require serious changes for mobiles beyond that required for ordinary SPV support, making it unclear if the decision to create a separate implementation was the right call. The situation is different now, with more unit tests and more people with a good understanding of the code. If someone wanted to implement SPV mode in bitcoind, they could be sent Satoshi's old patch, which indicates the basic cut lines.There are different options for implementing a native client for Bitcoin, including embedding the Java Virtual Machine (JVM) or transpiling bitcoinj to C++. While it is possible to reduce the size of the JVM to a few megabytes, it may not be necessary for desktop apps since bandwidth has improved. Portability to Android is already possible because it is Java-based, but iOS is a challenge due to Apple's restrictions on wallet apps in its App Store.One option is to rewrite bitcoinj in C++, but this is unnecessary given the existence of j2c, which does an excellent job of transpiling Java to C++. Another option is to embed the JVM and link it with the native app using a thin interface that calls into the Java code when user-visible events occur. This approach is less ambitious than transpilation but requires writing some Java code. The auto-translator javacpp can help with this.Rewriting bitcoinj in C++ or transpiling it to C++ requires a significant amount of work but could result in a stable, portable, and extendable piece of code. Embedding the JVM requires less work and can achieve good results quickly. The JVM can be bundled with the app and stripped down if necessary to reduce the download - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Linux-packaging-letter.xml b/static/bitcoin-dev/July_2013/combined_Linux-packaging-letter.xml index 66a71ce6eb..3bdf0a42f1 100644 --- a/static/bitcoin-dev/July_2013/combined_Linux-packaging-letter.xml +++ b/static/bitcoin-dev/July_2013/combined_Linux-packaging-letter.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Linux packaging letter - 2023-08-01T05:25:26.478101+00:00 + 2025-10-11T21:51:25.682715+00:00 + python-feedgen John Dillon 2013-07-28 18:21:44+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Linux packaging letter - 2023-08-01T05:25:26.478101+00:00 + 2025-10-11T21:51:25.682940+00:00 - The note discussed in the context highlights the potential dangers of packaging Bitcoin node software as part of distribution package repositories. The author emphasizes the need for upstream maintainers to understand the unique testing procedures and requirements to achieve consensus before distributing the software.Bitcoin nodes implement a complex group consensus, and even subtle changes can lead to a failure to reach consensus, posing a security risk. Therefore, it is crucial that unmodified, carefully audited, and tested implementations are used by as much of the network as possible.The note also mentions the importance of using reproducible build systems to ensure that upstream binaries can be audited for backdoors. Distributors are requested to direct users to the upstream-provided binaries instead of packaging Bitcoin node software until they fully understand the testing procedures and requirements.In another post by Mike Hearn, he suggests that packagers should listen to upstreams who complain about packaging, as they may have valid concerns. He acknowledges that some people think their code is more special than it actually is but highlights the unique challenges of packaging Bitcoin due to its dependencies. Hearn suggests that providing more information about dependencies and their specific versions would help packagers better understand the reasons behind the requests and make the packaging process smoother. He emphasizes the importance of communication and cooperation between upstreams and packagers for correct and efficient packaging.Gregory Maxwell contributes to the discussion by discussing the "portability" of Bitcoin to different platforms and the need for a smaller trusted computing base for gitian. He raises awareness about the potential risks of a bug in a database library used by Bitcoin, which could create an inconsistent consensus in the network and lead to a partitioned network. Maxwell also emphasizes the value of testing on new platforms using a full systems testing harness and running regression tests to ensure the integrity of the system.The email conversation between Zooko and an unknown party discusses the potential risks associated with a consensus failure in Bitcoin. The consequences of such an event could be devastating, causing people to lose money and resulting in unpredictable social and technical ramifications. While the most extreme outcomes are unlikely, risk mitigation is crucial for the long-term viability of the system. The conversation highlights the need to navigate the risks associated with Bitcoin carefully and err on the side of caution.In an email exchange between Mike Hearn and Zooko, they discuss the issue of packaging in the software industry. Hearn expresses concerns about inconsistent quality and subtle bugs introduced by non-expert packagers. Zooko agrees and suggests that upstreams should listen to packagers who may have valuable insights. They briefly discuss alternative approaches to packaging.Zooko sends an email thanking Jeff Garzik for his work on a new digestible alternative and asks questions regarding potential risks and consequences of dependency or patch failures in Bitcoin. He expresses concerns about problematic behaviors, the possibility of double-spending attacks, and blockchain forks. The healing process for a blockchain fork is not well understood.Jeff Garzik responds by providing a link to his work-in-progress alternative and expressing interest in publishing it. He mentions his experience with Fedora packaging and aims to provide a more digestible alternative within 24 hours.The email conversation discusses the issue of packaging Bitcoin software by non-experts, leading to inconsistent quality and subtle bugs. The initial draft of a letter to package maintainers was perceived as high-handed, and subsequent versions were created to address concerns and foster cooperation. The conversation emphasizes the importance of open communication and collaboration between upstreams and packagers.Another email exchange focuses on the importance of maintaining the security and integrity of the Bitcoin package while packaging it for Debian. It discusses the use of bundled/embedded libraries, specific architecture requirements, and the significance of reproducible builds to ensure secure distribution.In a thread on the mailing list, Zooko suggests modifying the Bitcoin letter before showing it to package maintainers to avoid being perceived as high-handed. He proposes a joint letter with packagers to address concerns and foster understanding.In an email exchange, the topic of certifying Debian libraries for Bitcoin packaging is discussed. Initially, there is skepticism about the need for certification, but it is later acknowledged that certification may be necessary after all.The discussion on the mailing list focuses on the portability of repeatable build infrastructure and the importance of precise library dependencies in Bitcoin. It highlights the risks of bugfixes in external dependencies and the need for comprehensive testing to ensure the stability of the Bitcoin software ecosystem.The conversation focuses on the applicability of a Linux packaging letter to non-Linux systems like FreeBSD ports and OpenBSD ports. The author suggests that the repeatable build infrastructure is portable to mostly-POSIX-compliant systems but has not been implemented yet. The requirement for precise library dependencies is seen as awkward, and synchronous updates of multiple packages are challenging. It is considered a bug that the package builds on BE systems and then fails tests. The author emphasizes the importance of accommodating packaging issues in the master sources if people are asked not to patch.In July 2013, it was 2013-07-28T18:21:44+00:00 + The note discussed in the context highlights the potential dangers of packaging Bitcoin node software as part of distribution package repositories. The author emphasizes the need for upstream maintainers to understand the unique testing procedures and requirements to achieve consensus before distributing the software.Bitcoin nodes implement a complex group consensus, and even subtle changes can lead to a failure to reach consensus, posing a security risk. Therefore, it is crucial that unmodified, carefully audited, and tested implementations are used by as much of the network as possible.The note also mentions the importance of using reproducible build systems to ensure that upstream binaries can be audited for backdoors. Distributors are requested to direct users to the upstream-provided binaries instead of packaging Bitcoin node software until they fully understand the testing procedures and requirements.In another post by Mike Hearn, he suggests that packagers should listen to upstreams who complain about packaging, as they may have valid concerns. He acknowledges that some people think their code is more special than it actually is but highlights the unique challenges of packaging Bitcoin due to its dependencies. Hearn suggests that providing more information about dependencies and their specific versions would help packagers better understand the reasons behind the requests and make the packaging process smoother. He emphasizes the importance of communication and cooperation between upstreams and packagers for correct and efficient packaging.Gregory Maxwell contributes to the discussion by discussing the "portability" of Bitcoin to different platforms and the need for a smaller trusted computing base for gitian. He raises awareness about the potential risks of a bug in a database library used by Bitcoin, which could create an inconsistent consensus in the network and lead to a partitioned network. Maxwell also emphasizes the value of testing on new platforms using a full systems testing harness and running regression tests to ensure the integrity of the system.The email conversation between Zooko and an unknown party discusses the potential risks associated with a consensus failure in Bitcoin. The consequences of such an event could be devastating, causing people to lose money and resulting in unpredictable social and technical ramifications. While the most extreme outcomes are unlikely, risk mitigation is crucial for the long-term viability of the system. The conversation highlights the need to navigate the risks associated with Bitcoin carefully and err on the side of caution.In an email exchange between Mike Hearn and Zooko, they discuss the issue of packaging in the software industry. Hearn expresses concerns about inconsistent quality and subtle bugs introduced by non-expert packagers. Zooko agrees and suggests that upstreams should listen to packagers who may have valuable insights. They briefly discuss alternative approaches to packaging.Zooko sends an email thanking Jeff Garzik for his work on a new digestible alternative and asks questions regarding potential risks and consequences of dependency or patch failures in Bitcoin. He expresses concerns about problematic behaviors, the possibility of double-spending attacks, and blockchain forks. The healing process for a blockchain fork is not well understood.Jeff Garzik responds by providing a link to his work-in-progress alternative and expressing interest in publishing it. He mentions his experience with Fedora packaging and aims to provide a more digestible alternative within 24 hours.The email conversation discusses the issue of packaging Bitcoin software by non-experts, leading to inconsistent quality and subtle bugs. The initial draft of a letter to package maintainers was perceived as high-handed, and subsequent versions were created to address concerns and foster cooperation. The conversation emphasizes the importance of open communication and collaboration between upstreams and packagers.Another email exchange focuses on the importance of maintaining the security and integrity of the Bitcoin package while packaging it for Debian. It discusses the use of bundled/embedded libraries, specific architecture requirements, and the significance of reproducible builds to ensure secure distribution.In a thread on the mailing list, Zooko suggests modifying the Bitcoin letter before showing it to package maintainers to avoid being perceived as high-handed. He proposes a joint letter with packagers to address concerns and foster understanding.In an email exchange, the topic of certifying Debian libraries for Bitcoin packaging is discussed. Initially, there is skepticism about the need for certification, but it is later acknowledged that certification may be necessary after all.The discussion on the mailing list focuses on the portability of repeatable build infrastructure and the importance of precise library dependencies in Bitcoin. It highlights the risks of bugfixes in external dependencies and the need for comprehensive testing to ensure the stability of the Bitcoin software ecosystem.The conversation focuses on the applicability of a Linux packaging letter to non-Linux systems like FreeBSD ports and OpenBSD ports. The author suggests that the repeatable build infrastructure is portable to mostly-POSIX-compliant systems but has not been implemented yet. The requirement for precise library dependencies is seen as awkward, and synchronous updates of multiple packages are challenging. It is considered a bug that the package builds on BE systems and then fails tests. The author emphasizes the importance of accommodating packaging issues in the master sources if people are asked not to patch.In July 2013, it was - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Litecoin-v0-8-3-7-audit-report.xml b/static/bitcoin-dev/July_2013/combined_Litecoin-v0-8-3-7-audit-report.xml index 0d4d5f4222..6134a416f4 100644 --- a/static/bitcoin-dev/July_2013/combined_Litecoin-v0-8-3-7-audit-report.xml +++ b/static/bitcoin-dev/July_2013/combined_Litecoin-v0-8-3-7-audit-report.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Litecoin v0.8.3.7 audit report - 2023-08-01T05:33:34.889478+00:00 + 2025-10-11T21:51:12.947669+00:00 + python-feedgen Peter Todd 2013-07-31 22:37:29+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Litecoin v0.8.3.7 audit report - 2023-08-01T05:33:34.889478+00:00 + 2025-10-11T21:51:12.947826+00:00 - Peter Todd, a Bitcoin developer, has shared an audit report of Litecoin v0.8.3.7, which he believes might be relevant to Bitcoin. The files for the audit report can be accessed either through a zip archive or individual links provided by Peter Todd. The audit report includes a report.txt.asc file containing a SHA256 hash of 24832b4b8411f3fbcc98b96bdfaaf90f4aeac39a7fbfb491bff5a76d23859dbd. Additionally, there is a 40809aed-1b5cb086.diff file and a litecoin-0.8.3.x-code-audit-agreement.txt.asc file.The context does not provide any further information about the content of the audit report or its significance. It is also unclear what the non-text attachment called signature.asc, which is a digital signature, pertains to in relation to the audit report. The email sender's name is identified as 'peter' and their email address ends with petertodd.org. However, no other details are given about the sender or the purpose of the email. 2013-07-31T22:37:29+00:00 + Peter Todd, a Bitcoin developer, has shared an audit report of Litecoin v0.8.3.7, which he believes might be relevant to Bitcoin. The files for the audit report can be accessed either through a zip archive or individual links provided by Peter Todd. The audit report includes a report.txt.asc file containing a SHA256 hash of 24832b4b8411f3fbcc98b96bdfaaf90f4aeac39a7fbfb491bff5a76d23859dbd. Additionally, there is a 40809aed-1b5cb086.diff file and a litecoin-0.8.3.x-code-audit-agreement.txt.asc file.The context does not provide any further information about the content of the audit report or its significance. It is also unclear what the non-text attachment called signature.asc, which is a digital signature, pertains to in relation to the audit report. The email sender's name is identified as 'peter' and their email address ends with petertodd.org. However, no other details are given about the sender or the purpose of the email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Opcode-whitelist-for-P2SH-.xml b/static/bitcoin-dev/July_2013/combined_Opcode-whitelist-for-P2SH-.xml index e6a49eddbf..422fc7aaa0 100644 --- a/static/bitcoin-dev/July_2013/combined_Opcode-whitelist-for-P2SH-.xml +++ b/static/bitcoin-dev/July_2013/combined_Opcode-whitelist-for-P2SH-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Opcode whitelist for P2SH? - 2023-08-01T05:27:14.183756+00:00 + 2025-10-11T21:51:32.069792+00:00 + python-feedgen Peter Todd 2013-07-29 08:13:55+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Opcode whitelist for P2SH? - 2023-08-01T05:27:14.183756+00:00 + 2025-10-11T21:51:32.069950+00:00 - The email exchange between John Dillon and Peter Todd discusses the potential uses of non-standard transactions to implement oracles and one-time-password protection of wallet funds. The proposal suggests creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH, while retaining the existing standard whitelist for scriptPubKeys. However, it is important to retain the IsStandard() check, especially the AreInputsStandard() check, if a P2SH serialized script follows a standard form. This is because transaction mutability can affect unconfirmed transaction chains in flight.The proposal recommends considering transactions non-standard or not allowed at all in a future soft-fork if there is more than one stack item left at the end of execution. A opcode whitelist should probably be implemented to achieve this. The proposal also suggests that CHECKMULTISIG should always be zero to avoid mutability issues. The email asks for an example where imposing a one-stack-item-at-the-end-of-execution rule causes problems.In general, the email suggests that Bitcoin should have been designed so that CHECKSIG signed hashes of scriptPubKeys instead of txid:vout outputs to prevent malleability from affecting the validity of a signature. The proposal acknowledges that this would mean that signatures could be reused if scriptPubKeys were reused, but address re-use is considered a bad thing anyway.Jeff Garzik and Luke-Jr discussed creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH. John Dillon suggested dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set. However, Luke-Jr stated that some specific standard forms would still be necessary for interoperability between wallets without a much smarter solver.Luke-Jr wrote to Jeff Garzik regarding the whitelist for specific opcodes in scripts serialized using P2SH. Luke-Jr believes that this approach could be reasonable for miners, but a much smarter solver would be required for interoperability between wallets. Without this, specific standard forms would still be necessary. Current designs are based on pattern matching a script template, and Satoshi described lightweight clients as needing no script engine at all, only the ability to match patterns.In another discussion, John Dillon proposed the idea of creating a whitelist for specific opcodes in scripts serialized using P2SH. He suggested dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set. While this may be reasonable for miners, it could pose issues for interoperability between wallets. Therefore, some specific standard forms would still be necessary without a much smarter solver. However, expanding the code required to implement a wallet may be necessary.Peter Todd suggests two uses for non-standard transactions: implementing oracles and one-time-password protection of wallet funds. The oracle case would benefit from more arbitrary rules. The author recommends creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH and dropping pay-to-pubkey and pay-to-multisig. The whitelist should contain various opcodes for complex logic but avoid arithmetic operations to prevent potential problems. 2013-07-29T08:13:55+00:00 + The email exchange between John Dillon and Peter Todd discusses the potential uses of non-standard transactions to implement oracles and one-time-password protection of wallet funds. The proposal suggests creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH, while retaining the existing standard whitelist for scriptPubKeys. However, it is important to retain the IsStandard() check, especially the AreInputsStandard() check, if a P2SH serialized script follows a standard form. This is because transaction mutability can affect unconfirmed transaction chains in flight.The proposal recommends considering transactions non-standard or not allowed at all in a future soft-fork if there is more than one stack item left at the end of execution. A opcode whitelist should probably be implemented to achieve this. The proposal also suggests that CHECKMULTISIG should always be zero to avoid mutability issues. The email asks for an example where imposing a one-stack-item-at-the-end-of-execution rule causes problems.In general, the email suggests that Bitcoin should have been designed so that CHECKSIG signed hashes of scriptPubKeys instead of txid:vout outputs to prevent malleability from affecting the validity of a signature. The proposal acknowledges that this would mean that signatures could be reused if scriptPubKeys were reused, but address re-use is considered a bad thing anyway.Jeff Garzik and Luke-Jr discussed creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH. John Dillon suggested dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set. However, Luke-Jr stated that some specific standard forms would still be necessary for interoperability between wallets without a much smarter solver.Luke-Jr wrote to Jeff Garzik regarding the whitelist for specific opcodes in scripts serialized using P2SH. Luke-Jr believes that this approach could be reasonable for miners, but a much smarter solver would be required for interoperability between wallets. Without this, specific standard forms would still be necessary. Current designs are based on pattern matching a script template, and Satoshi described lightweight clients as needing no script engine at all, only the ability to match patterns.In another discussion, John Dillon proposed the idea of creating a whitelist for specific opcodes in scripts serialized using P2SH. He suggested dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set. While this may be reasonable for miners, it could pose issues for interoperability between wallets. Therefore, some specific standard forms would still be necessary without a much smarter solver. However, expanding the code required to implement a wallet may be necessary.Peter Todd suggests two uses for non-standard transactions: implementing oracles and one-time-password protection of wallet funds. The oracle case would benefit from more arbitrary rules. The author recommends creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH and dropping pay-to-pubkey and pay-to-multisig. The whitelist should contain various opcodes for complex logic but avoid arithmetic operations to prevent potential problems. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Payment-Protocol-BIP-70-71-72.xml b/static/bitcoin-dev/July_2013/combined_Payment-Protocol-BIP-70-71-72.xml index 7a7a28f17f..f622d276b3 100644 --- a/static/bitcoin-dev/July_2013/combined_Payment-Protocol-BIP-70-71-72.xml +++ b/static/bitcoin-dev/July_2013/combined_Payment-Protocol-BIP-70-71-72.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol: BIP 70, 71, 72 - 2023-08-01T05:29:54.664873+00:00 + 2025-10-11T21:51:27.806168+00:00 + python-feedgen Peter Todd 2013-09-26 06:37:19+00:00 @@ -171,13 +172,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol: BIP 70, 71, 72 - 2023-08-01T05:29:54.664873+00:00 + 2025-10-11T21:51:27.806421+00:00 - In a series of discussions among Bitcoin developers, various topics related to payment protocols, wallet functionality, and the use of URIs for transactions were explored. One topic of discussion was the potential for a Man-in-the-Middle (MITM) attack on the HTTPS protocol, which could exploit flaws in the SSL PKI infrastructure and harm Bitcoin. It was suggested that implementing a payment protocol using the SSL PKI infrastructure could help identify weaknesses and motivate improvements.The possibility of MITM attacks in the context of Bitcoin URIs was also raised, with some companies using data loss prevention products with MITM capability. While the incentive for governments or large corporations to carry out such attacks may be low, detecting transactions could be more useful than meddling with them. Difficulties in using QR codes, especially under low light conditions, were also discussed, prompting suggestions for alternative approaches such as short URLs.The conversation touched on the security risks related to certificate authorities and MITM attacks, with HTTPS being seen as protective against certain attacks but not those involving scanning QR codes in person. The need for trust in HTTPS was debated, with one developer arguing that seeing a partner in person should eliminate the need for a certificate. However, concerns about the subversion of certificate authorities and the potential theft of funds due to broken certificates were also raised.Developers explored ways to make QR codes more scannable and reduce their size. Suggestions included changing parameters and exploring the use of BIP70 once available. The importance of HTTPS and the potential benefits of using the payments protocol were emphasized.The flexibility of the BIP72 specification was updated to allow for more options in processing transactions. Existing point-of-sale systems were identified as potential beneficiaries of the payments protocol, although concerns were raised about compatibility issues. The debate over Bitcoin URIs and the potential advantages of payment URIs was discussed, with considerations for proper payment infrastructure and the inclusion of 'SHOULDs' and 'MAYs' instead of 'MUSTs' in the specification.Additional discussions centered on wallet functionality, including concerns about wallets without P2P protocol support and the handling of locked inputs. The responsibility of confirming transactions and preventing their announcement to the network was also debated.Overall, these discussions demonstrate the ongoing development and considerations within the Bitcoin community regarding payment protocols, wallet functionality, and the use of URIs for transactions. Various suggestions were made to enhance security, improve scannability, and ensure backward compatibility. 2013-09-26T06:37:19+00:00 + In a series of discussions among Bitcoin developers, various topics related to payment protocols, wallet functionality, and the use of URIs for transactions were explored. One topic of discussion was the potential for a Man-in-the-Middle (MITM) attack on the HTTPS protocol, which could exploit flaws in the SSL PKI infrastructure and harm Bitcoin. It was suggested that implementing a payment protocol using the SSL PKI infrastructure could help identify weaknesses and motivate improvements.The possibility of MITM attacks in the context of Bitcoin URIs was also raised, with some companies using data loss prevention products with MITM capability. While the incentive for governments or large corporations to carry out such attacks may be low, detecting transactions could be more useful than meddling with them. Difficulties in using QR codes, especially under low light conditions, were also discussed, prompting suggestions for alternative approaches such as short URLs.The conversation touched on the security risks related to certificate authorities and MITM attacks, with HTTPS being seen as protective against certain attacks but not those involving scanning QR codes in person. The need for trust in HTTPS was debated, with one developer arguing that seeing a partner in person should eliminate the need for a certificate. However, concerns about the subversion of certificate authorities and the potential theft of funds due to broken certificates were also raised.Developers explored ways to make QR codes more scannable and reduce their size. Suggestions included changing parameters and exploring the use of BIP70 once available. The importance of HTTPS and the potential benefits of using the payments protocol were emphasized.The flexibility of the BIP72 specification was updated to allow for more options in processing transactions. Existing point-of-sale systems were identified as potential beneficiaries of the payments protocol, although concerns were raised about compatibility issues. The debate over Bitcoin URIs and the potential advantages of payment URIs was discussed, with considerations for proper payment infrastructure and the inclusion of 'SHOULDs' and 'MAYs' instead of 'MUSTs' in the specification.Additional discussions centered on wallet functionality, including concerns about wallets without P2P protocol support and the handling of locked inputs. The responsibility of confirming transactions and preventing their announcement to the network was also debated.Overall, these discussions demonstrate the ongoing development and considerations within the Bitcoin community regarding payment protocols, wallet functionality, and the use of URIs for transactions. Various suggestions were made to enhance security, improve scannability, and ensure backward compatibility. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Proposal-MultiBit-as-default-desktop-client-on-bitcoin-org.xml b/static/bitcoin-dev/July_2013/combined_Proposal-MultiBit-as-default-desktop-client-on-bitcoin-org.xml index 403060d800..281fee9977 100644 --- a/static/bitcoin-dev/July_2013/combined_Proposal-MultiBit-as-default-desktop-client-on-bitcoin-org.xml +++ b/static/bitcoin-dev/July_2013/combined_Proposal-MultiBit-as-default-desktop-client-on-bitcoin-org.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: MultiBit as default desktop client on bitcoin.org - 2023-08-01T05:13:46.470693+00:00 + 2025-10-11T21:51:29.942308+00:00 + python-feedgen Andreas Petersson 2013-07-09 22:15:03+00:00 @@ -191,13 +192,13 @@ - python-feedgen + 2 Combined summary - Proposal: MultiBit as default desktop client on bitcoin.org - 2023-08-01T05:13:46.470693+00:00 + 2025-10-11T21:51:29.942597+00:00 - The context revolves around various discussions related to MultiBit, a Bitcoin wallet application. One topic of discussion is the concern about the security of Java and its impact on MultiBit's security. Despite these concerns, MultiBit is considered secure enough to handle money. The developer has made efforts to improve support for users by creating a dedicated support page on the website and enhancing the in-app help section. Users are directed to external resources such as bitcoin.stackexchange.com and GitHub issues for further assistance. There is also a debate about whether MultiBit should replace Bitcoin-Qt as the recommended desktop wallet app. The supporting documentation for the website can be found at https://github.com/jim618/multibit-website.In addition, there are conversations about the challenges and developments in the world of Bitcoin and its wallets. These discussions cover topics such as encryption, replace-by-fee rules, issues with Bitcoinj, adoption of Bitcoin, and making technology accessible to non-technical users. The context also touches on the features and improvements of MultiBit, including encrypted wallets, sign and verify message capabilities, stability improvements, and bug fixes. The founder of MultiBit proposes that it should become the default desktop client on bitcoin.org's "Choose your wallet" page to attract new users and introduce them to the broader Bitcoin economy.Overall, the discussions highlight the efforts made by the developer to enhance the usability and support of MultiBit, as well as the potential role of MultiBit in expanding the adoption of cryptocurrency. 2013-07-09T22:15:03+00:00 + The context revolves around various discussions related to MultiBit, a Bitcoin wallet application. One topic of discussion is the concern about the security of Java and its impact on MultiBit's security. Despite these concerns, MultiBit is considered secure enough to handle money. The developer has made efforts to improve support for users by creating a dedicated support page on the website and enhancing the in-app help section. Users are directed to external resources such as bitcoin.stackexchange.com and GitHub issues for further assistance. There is also a debate about whether MultiBit should replace Bitcoin-Qt as the recommended desktop wallet app. The supporting documentation for the website can be found at https://github.com/jim618/multibit-website.In addition, there are conversations about the challenges and developments in the world of Bitcoin and its wallets. These discussions cover topics such as encryption, replace-by-fee rules, issues with Bitcoinj, adoption of Bitcoin, and making technology accessible to non-technical users. The context also touches on the features and improvements of MultiBit, including encrypted wallets, sign and verify message capabilities, stability improvements, and bug fixes. The founder of MultiBit proposes that it should become the default desktop client on bitcoin.org's "Choose your wallet" page to attract new users and introduce them to the broader Bitcoin economy.Overall, the discussions highlight the efforts made by the developer to enhance the usability and support of MultiBit, as well as the potential role of MultiBit in expanding the adoption of cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Protecting-Bitcoin-against-network-wide-DoS-attack.xml b/static/bitcoin-dev/July_2013/combined_Protecting-Bitcoin-against-network-wide-DoS-attack.xml index 3a861d2c8a..b9b4f0143a 100644 --- a/static/bitcoin-dev/July_2013/combined_Protecting-Bitcoin-against-network-wide-DoS-attack.xml +++ b/static/bitcoin-dev/July_2013/combined_Protecting-Bitcoin-against-network-wide-DoS-attack.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Protecting Bitcoin against network-wide DoS attack - 2023-08-01T05:17:48.736138+00:00 + 2025-10-11T21:51:57.565502+00:00 + python-feedgen Peter Todd 2013-07-15 07:32:24+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Protecting Bitcoin against network-wide DoS attack - 2023-08-01T05:17:48.736138+00:00 + 2025-10-11T21:51:57.565661+00:00 - In a discussion about anti-denial of service (DoS) measures in Bitcoin, John Dillon suggests implementing measures for non-SPV-mode clients where incoming peers are required to do "useful work". This involves kicking off peers who have relayed the least fee-paying transactions and valid blocks as incoming connection slots get used up. The system aims to keep the peers who have relayed the most. Outgoing peers follow randomized logic to maintain the network's randomized structure. Peter Todd proposes adding per-node accounting once nodes have unique identifiers, which can later be used for permanent node identifiers with SSL and message signing.The Bitcoin network is vulnerable to a cheap attack due to the fact that incoming connections are limited and not subject to any criteria. An attacker can exploit this vulnerability by repeatedly querying DNS seeds for new addresses, creating enough incoming connections to overwhelm nodes and prevent them from accepting further clients. With nMaxConnections defaulting to 125 and a limit on file descriptors, stateful firewalls could also impose additional limits. The cost to the attacker is minimal, requiring only an INV message per transaction and block and some gossiped peer addresses, averaging at about 30 bytes per second. Peter estimates that an attack could be launched with just 200 well-distributed IP addresses.For SPV (Simplified Payment Verification) client attacks, attackers can pretend to be an SPV client, reducing their incoming bandwidth consumption while increasing resource usage on the node. Since bandwidth is not reusable, attackers with access to EC2 or a botnet have lower costs for bandwidth compared to users with an Android wallet on a phone. To counter this, SPV nodes need to provide a way to prove that they have sacrificed limited resources, allowing legitimate users to be distinguished from attackers. If this fails, attacks must become expensive enough to discourage script-kiddies. For non-SPV-mode clients, anti-DoS measures can be implemented by requiring peers to do "useful work". As incoming connection slots get used up, the system kicks off incoming peers who have relayed the least fee-paying transactions and valid blocks, while keeping those who have relayed the most. SPV nodes can prioritize their connection by creating high-fee transactions with their own coins during an attack. When dealing with SPV peers, nodes can consider how long it takes for another node to advertise the transactions. Future improvements can be made, such as implementing micropayment channels and coinbase probabilistic payments, which would not require blockchain transactions solely for anti-DoS purposes.To understand the impact of the attack, a demonstration would be useful. Pieter Wuille's bitcoin-seeder code could potentially be reused as it already has the required functionality to create a large number of connections. Simply running multiple instances of the code could achieve the desired effect. 2013-07-15T07:32:24+00:00 + In a discussion about anti-denial of service (DoS) measures in Bitcoin, John Dillon suggests implementing measures for non-SPV-mode clients where incoming peers are required to do "useful work". This involves kicking off peers who have relayed the least fee-paying transactions and valid blocks as incoming connection slots get used up. The system aims to keep the peers who have relayed the most. Outgoing peers follow randomized logic to maintain the network's randomized structure. Peter Todd proposes adding per-node accounting once nodes have unique identifiers, which can later be used for permanent node identifiers with SSL and message signing.The Bitcoin network is vulnerable to a cheap attack due to the fact that incoming connections are limited and not subject to any criteria. An attacker can exploit this vulnerability by repeatedly querying DNS seeds for new addresses, creating enough incoming connections to overwhelm nodes and prevent them from accepting further clients. With nMaxConnections defaulting to 125 and a limit on file descriptors, stateful firewalls could also impose additional limits. The cost to the attacker is minimal, requiring only an INV message per transaction and block and some gossiped peer addresses, averaging at about 30 bytes per second. Peter estimates that an attack could be launched with just 200 well-distributed IP addresses.For SPV (Simplified Payment Verification) client attacks, attackers can pretend to be an SPV client, reducing their incoming bandwidth consumption while increasing resource usage on the node. Since bandwidth is not reusable, attackers with access to EC2 or a botnet have lower costs for bandwidth compared to users with an Android wallet on a phone. To counter this, SPV nodes need to provide a way to prove that they have sacrificed limited resources, allowing legitimate users to be distinguished from attackers. If this fails, attacks must become expensive enough to discourage script-kiddies. For non-SPV-mode clients, anti-DoS measures can be implemented by requiring peers to do "useful work". As incoming connection slots get used up, the system kicks off incoming peers who have relayed the least fee-paying transactions and valid blocks, while keeping those who have relayed the most. SPV nodes can prioritize their connection by creating high-fee transactions with their own coins during an attack. When dealing with SPV peers, nodes can consider how long it takes for another node to advertise the transactions. Future improvements can be made, such as implementing micropayment channels and coinbase probabilistic payments, which would not require blockchain transactions solely for anti-DoS purposes.To understand the impact of the attack, a demonstration would be useful. Pieter Wuille's bitcoin-seeder code could potentially be reused as it already has the required functionality to create a large number of connections. Simply running multiple instances of the code could achieve the desired effect. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Review-for-slides-for-defeating-trojans-talk.xml b/static/bitcoin-dev/July_2013/combined_Review-for-slides-for-defeating-trojans-talk.xml index 3e2e16b6a4..d347e32651 100644 --- a/static/bitcoin-dev/July_2013/combined_Review-for-slides-for-defeating-trojans-talk.xml +++ b/static/bitcoin-dev/July_2013/combined_Review-for-slides-for-defeating-trojans-talk.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Review for slides for "defeating trojans" talk - 2023-08-01T05:17:06.586592+00:00 + Combined summary - Review for slides for "defeating trojans" talk + 2025-10-11T21:51:36.314661+00:00 + python-feedgen Mats Henricson 2013-07-12 16:46:00+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 - Combined summary - Review for slides for "defeating trojans" talk - 2023-08-01T05:17:06.587593+00:00 + Combined summary - Review for slides for "defeating trojans" talk + 2025-10-11T21:51:36.314830+00:00 - In 2013, Rob Meijer completed the first draft of his presentation slides and speaker notes for his talk titled "Defeating Trojans" at OHM2013. He used BitCoin as one of the main examples to emphasize the importance of programs like BitCoin having their own private storage apart from $HOME. To ensure that he didn't misrepresent BitCoin, he asked for someone to review his slides.Rob has completed the first draft of his slides and speaker notes for his upcoming talk on "Defeating Trojans" at OHM2013. He plans to use BitCoin as one of the main examples in his talk to highlight the importance of programs like BitCoin having their own private storage apart from $HOME. To ensure that he does not misrepresent BitCoin, Rob is requesting for someone to review his slides. He welcomes anyone who can help him by reviewing his (open office) slides, and is willing to email them for review. 2013-07-12T16:46:00+00:00 + In 2013, Rob Meijer completed the first draft of his presentation slides and speaker notes for his talk titled "Defeating Trojans" at OHM2013. He used BitCoin as one of the main examples to emphasize the importance of programs like BitCoin having their own private storage apart from $HOME. To ensure that he didn't misrepresent BitCoin, he asked for someone to review his slides.Rob has completed the first draft of his slides and speaker notes for his upcoming talk on "Defeating Trojans" at OHM2013. He plans to use BitCoin as one of the main examples in his talk to highlight the importance of programs like BitCoin having their own private storage apart from $HOME. To ensure that he does not misrepresent BitCoin, Rob is requesting for someone to review his slides. He welcomes anyone who can help him by reviewing his (open office) slides, and is willing to email them for review. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Reward-for-P2SH-IsStandard-patch-.xml b/static/bitcoin-dev/July_2013/combined_Reward-for-P2SH-IsStandard-patch-.xml index ef64607526..6b137df3b8 100644 --- a/static/bitcoin-dev/July_2013/combined_Reward-for-P2SH-IsStandard-patch-.xml +++ b/static/bitcoin-dev/July_2013/combined_Reward-for-P2SH-IsStandard-patch-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reward for P2SH IsStandard() patch. - 2023-08-01T05:17:28.270249+00:00 + 2025-10-11T21:51:49.074850+00:00 + python-feedgen John Dillon 2013-07-14 19:40:21+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Reward for P2SH IsStandard() patch. - 2023-08-01T05:17:28.270249+00:00 + 2025-10-11T21:51:49.075018+00:00 - In a mailing list conversation, Pieter Wuille and John Dillon discussed the potential benefits of using P2SH (Pay-to-Script-Hash) with an inner OP_CHECKSIG for most addresses in the long term. This implementation would save 1 byte. They suggest starting with change addresses, and they mention that bitcoinj support will assist sites like satoshidice in paying to P2SH change addresses.When it comes to multisig's P2SH overhead, the percentages for a 1-of-2, 2-of-2, and 3-of-3 are 10%, 8.6%, and 6.2% respectively. These figures are considered minor, especially if the blocksize limit is expected to be raised. However, Pieter Wuille points out that the current implementation in the reference client uses a custom script encoder for the UTXO (Unspent Transaction Output) database. This means that for "standard" address payments, there is no storage impact when using P2SH instead.The author of the message offers a reward of 1BTC for creating a patch to change IsStandard() code. The goal is to make it accept only P2SH and pubkeyhash in a raw scriptSig, allowing other forms only when used with P2SH. The issue with the current code is that it accepts up to 120 bytes of junk data as a pubkey, which allows for the injection of 240 bytes of spendable data into the UTXO set with bare OP_CHECKMULTISIG. The author emphasizes the importance of keeping the size of the UTXO set small and mentions problems with distasteful data being added to it.Gregory Maxwell proposes P2SH as an excellent solution to the problem of distasteful data, and Peter Todd explains how it can be implemented using the existing P2SH form. They plan to introduce some form of OP_RETURN soon, which will handle timestamping and similar use-cases without impacting the UTXO set. Currently, the only scriptPubKey form with significant use is checksighash, while bare pubkey is used by some miners and Deepbit due to their outdated codebase. However, this is expected to change as hardware wallets and the payment protocol become more prevalent. It is important to ensure that these protocols utilize P2SH before getting locked into multiple OP_CHECKMULTISIG implementations.Pieter Todd's timestamper currently uses OP_CHECKMULTISIG, but it can be easily changed to OP_RETURN. The implementation of P2SH can begin with change addresses, and bitcoinj support will assist sites like satoshidice in paying to P2SH change addresses. Ultimately, the overhead for multisig's P2SH (1-of-2, 2-of-2, and 3-of-3) is considered minor, especially if the blocksize limit is raised. 2013-07-14T19:40:21+00:00 + In a mailing list conversation, Pieter Wuille and John Dillon discussed the potential benefits of using P2SH (Pay-to-Script-Hash) with an inner OP_CHECKSIG for most addresses in the long term. This implementation would save 1 byte. They suggest starting with change addresses, and they mention that bitcoinj support will assist sites like satoshidice in paying to P2SH change addresses.When it comes to multisig's P2SH overhead, the percentages for a 1-of-2, 2-of-2, and 3-of-3 are 10%, 8.6%, and 6.2% respectively. These figures are considered minor, especially if the blocksize limit is expected to be raised. However, Pieter Wuille points out that the current implementation in the reference client uses a custom script encoder for the UTXO (Unspent Transaction Output) database. This means that for "standard" address payments, there is no storage impact when using P2SH instead.The author of the message offers a reward of 1BTC for creating a patch to change IsStandard() code. The goal is to make it accept only P2SH and pubkeyhash in a raw scriptSig, allowing other forms only when used with P2SH. The issue with the current code is that it accepts up to 120 bytes of junk data as a pubkey, which allows for the injection of 240 bytes of spendable data into the UTXO set with bare OP_CHECKMULTISIG. The author emphasizes the importance of keeping the size of the UTXO set small and mentions problems with distasteful data being added to it.Gregory Maxwell proposes P2SH as an excellent solution to the problem of distasteful data, and Peter Todd explains how it can be implemented using the existing P2SH form. They plan to introduce some form of OP_RETURN soon, which will handle timestamping and similar use-cases without impacting the UTXO set. Currently, the only scriptPubKey form with significant use is checksighash, while bare pubkey is used by some miners and Deepbit due to their outdated codebase. However, this is expected to change as hardware wallets and the payment protocol become more prevalent. It is important to ensure that these protocols utilize P2SH before getting locked into multiple OP_CHECKMULTISIG implementations.Pieter Todd's timestamper currently uses OP_CHECKMULTISIG, but it can be easily changed to OP_RETURN. The implementation of P2SH can begin with change addresses, and bitcoinj support will assist sites like satoshidice in paying to P2SH change addresses. Ultimately, the overhead for multisig's P2SH (1-of-2, 2-of-2, and 3-of-3) is considered minor, especially if the blocksize limit is raised. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_SPV-bitcoind-.xml b/static/bitcoin-dev/July_2013/combined_SPV-bitcoind-.xml index daeafcdb4f..6b6ba558d2 100644 --- a/static/bitcoin-dev/July_2013/combined_SPV-bitcoind-.xml +++ b/static/bitcoin-dev/July_2013/combined_SPV-bitcoind-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SPV bitcoind? - 2023-08-01T05:19:53.952040+00:00 + 2025-10-11T21:51:23.561207+00:00 + python-feedgen Mike Hearn 2013-07-17 19:32:12+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - SPV bitcoind? - 2023-08-01T05:19:53.952040+00:00 + 2025-10-11T21:51:23.561359+00:00 - In an email conversation between Mike Hearn and Andreas Schildbach, the topic of the average connection time for the Bitcoin app was discussed. Andreas explained that the current programming allows for connections to remain open for an additional two minutes after receiving a block, and eight minutes after sending or receiving a transaction. This feature is designed to give the chain time to catch up while avoiding excessive battery drain.Furthermore, the app keeps connections open as long as the screen is on and the app is in the foreground. This means that when users are actively using the app, such as on the send and request coins screens or the network monitor, the connections will remain open. Mike Hearn raised the issue of SPV wallets and their usage patterns. He suggested gathering telemetry from the Android wallet to determine how long SPV wallets typically remain open. He believes that most users only keep their wallets open to check if they have received or sent money. To gain insights into this, he proposed allowing users to opt-in to usage statistics.Andreas agreed to look into implementing the option for users to opt-in to usage statistics. This would provide valuable data on how long SPV wallets stay open and help address Mike's concerns about the number of open wallets. By gathering this information, they hope to make informed decisions regarding potential improvements, such as the idea of partial UTXO sets suggested by Mike.Overall, this conversation highlights the considerations around connection times for the Bitcoin app and the need for data on SPV wallet usage. By understanding user behavior and preferences, the developers can make informed adjustments and enhancements to ensure optimal performance and user experience. 2013-07-17T19:32:12+00:00 + In an email conversation between Mike Hearn and Andreas Schildbach, the topic of the average connection time for the Bitcoin app was discussed. Andreas explained that the current programming allows for connections to remain open for an additional two minutes after receiving a block, and eight minutes after sending or receiving a transaction. This feature is designed to give the chain time to catch up while avoiding excessive battery drain.Furthermore, the app keeps connections open as long as the screen is on and the app is in the foreground. This means that when users are actively using the app, such as on the send and request coins screens or the network monitor, the connections will remain open. Mike Hearn raised the issue of SPV wallets and their usage patterns. He suggested gathering telemetry from the Android wallet to determine how long SPV wallets typically remain open. He believes that most users only keep their wallets open to check if they have received or sent money. To gain insights into this, he proposed allowing users to opt-in to usage statistics.Andreas agreed to look into implementing the option for users to opt-in to usage statistics. This would provide valuable data on how long SPV wallets stay open and help address Mike's concerns about the number of open wallets. By gathering this information, they hope to make informed decisions regarding potential improvements, such as the idea of partial UTXO sets suggested by Mike.Overall, this conversation highlights the considerations around connection times for the Bitcoin app and the need for data on SPV wallet usage. By understanding user behavior and preferences, the developers can make informed adjustments and enhancements to ensure optimal performance and user experience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_SPV-bitcoind-was-Introducing-BitcoinKit-framework-.xml b/static/bitcoin-dev/July_2013/combined_SPV-bitcoind-was-Introducing-BitcoinKit-framework-.xml index 6563a5cb7b..8d444190b7 100644 --- a/static/bitcoin-dev/July_2013/combined_SPV-bitcoind-was-Introducing-BitcoinKit-framework-.xml +++ b/static/bitcoin-dev/July_2013/combined_SPV-bitcoind-was-Introducing-BitcoinKit-framework-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SPV bitcoind? (was: Introducing BitcoinKit.framework) - 2023-08-01T05:19:43.655338+00:00 + 2025-10-11T21:51:21.437858+00:00 + python-feedgen Peter Todd 2013-07-18 23:03:59+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - SPV bitcoind? (was: Introducing BitcoinKit.framework) - 2023-08-01T05:19:43.656337+00:00 + 2025-10-11T21:51:21.438037+00:00 - In an email conversation from 2013, Wendell expresses his willingness to write specifications and supervise/audit/advise for a few hours a week regarding a potential project. Peter Todd responds by saying he has more good ideas than he has time to implement but is considering it. He mentions that he accepted funds from John Dillon to implement replace-by-fee, but the scope of the project turned out to be bigger than originally thought. Todd suggests reviewing his git commit track record before offering anything.In an email exchange, Peter Todd discusses the possibility of implementing a new idea with Wendell Davis, who suggests that Todd may want to consider bringing in someone else to handle the programming if he lacks confidence in his skills. Davis offers Eric Lombrozo as a potential candidate for the job. Todd responds by stating that he has more good ideas than time to implement them, but admits that he is considering the project. He also mentions that he accepted funds from John Dillon to implement replace-by-fee, and suggests that anyone interested in offering bribes should look at his git commit track record. Todd notes that he has been more of an academic than a programmer.In an email exchange from 2013, Wendell proposed an idea to Peter Todd for a desktop client that would only use a fraction of available disk space. Peter responded that he has a lot of good ideas and he is considering this one. However, he joked that he would accept bribes but also explained that he had previously accepted funds from John Dillon to implement replace-by-fee. Peter suggested looking at his git commit track record before making any offers. The email also included a digital signature as an attachment.The behavior of SPV clients is considered abusive since they utilize maximum node resources with minimum cost. This, however, is not entirely true as compromised web servers are also a common occurrence and the asymmetry in node resources is biased against devices such as phones and tablets that have limited memory bandwidth. A good anti-DoS strategy should prioritize existing users over new users and old coins over new coins. In case Bitcoin suddenly becomes too popular, there must be enough nodes to support all users and some rules can be followed, such as disconnecting recent connections to long-lived connections to avoid running out of TCP sockets and preferring processing new blocks to serving old parts of the chain when disk seeks run out. It is suggested that instead of talking about DoS, we should discuss what happens if Bitcoin suddenly gets too popular and how to handle it.In an email thread discussing a more sophisticated approach to answering challenges, Peter Todd suggests using a version of H() that has a computational trap-door and is significantly faster running time than H(). He asks Adam what can be used for H', and suggests creating a set of expensive-to-compute data associated with the node's identity that can be stored once by the node but requires clients to store one set for every unique node they connect to. This can also be used as a proof-of-work to make creating lots of nodes expensive, and can incorporate blockchain data. This method can also make MITM attacks on encrypted P2P connections expensive without any form of authentication.Michael has informed Bazyli about a fresh build based on git (Xcode) and has faced an issue where the paillier and account tests were missing. Michael has asked Bazyli to comment them out in tests/CMakeLists.txt so that the coinexplorer can build without any issues. Michael has also mentioned that he has done a git push, therefore, Bazyli needs to do a git pull first before proceeding.The email is a response to a query about building Xcode projects with libcoin on Mac OSX. The sender notes that they develop mainly on Mac OSX and build Xcode projects with libcoin daily on both Mac OSX and Linux, but find building on Windows more difficult. The sender suggests that QT is not necessary and can be removed as the qt part got split out. Building clean on Mac requires OpenSSL, BDB, and Boost, which can be installed using homebrew. Latest CMake should also be used and a normal CMake Xcode call: cmake -GXcode should do the job. The sender provides some quick notes for building stuff and recommends trying coinexplorer because it splits out the wallet from the server, making it nice if you want to build a webcoin-like server. The sender does not use the wallet parts from bitcoind personally, so if there are problems with these, the sender will need to have a closer look. Additionally, the current version of libcoin adds a lot of different features and handles things quite differently compared to the first version, which was a direct refactorization of bitcoin. For example, one can look up any unspent output by script (bitcoin address) in milliseconds, which is nice for web wallets. The sender also mentions that BitcoinKit is a separate dynamic library compiled with gcc (or at least llvm pretending to be gcc) due to templates 2013-07-18T23:03:59+00:00 + In an email conversation from 2013, Wendell expresses his willingness to write specifications and supervise/audit/advise for a few hours a week regarding a potential project. Peter Todd responds by saying he has more good ideas than he has time to implement but is considering it. He mentions that he accepted funds from John Dillon to implement replace-by-fee, but the scope of the project turned out to be bigger than originally thought. Todd suggests reviewing his git commit track record before offering anything.In an email exchange, Peter Todd discusses the possibility of implementing a new idea with Wendell Davis, who suggests that Todd may want to consider bringing in someone else to handle the programming if he lacks confidence in his skills. Davis offers Eric Lombrozo as a potential candidate for the job. Todd responds by stating that he has more good ideas than time to implement them, but admits that he is considering the project. He also mentions that he accepted funds from John Dillon to implement replace-by-fee, and suggests that anyone interested in offering bribes should look at his git commit track record. Todd notes that he has been more of an academic than a programmer.In an email exchange from 2013, Wendell proposed an idea to Peter Todd for a desktop client that would only use a fraction of available disk space. Peter responded that he has a lot of good ideas and he is considering this one. However, he joked that he would accept bribes but also explained that he had previously accepted funds from John Dillon to implement replace-by-fee. Peter suggested looking at his git commit track record before making any offers. The email also included a digital signature as an attachment.The behavior of SPV clients is considered abusive since they utilize maximum node resources with minimum cost. This, however, is not entirely true as compromised web servers are also a common occurrence and the asymmetry in node resources is biased against devices such as phones and tablets that have limited memory bandwidth. A good anti-DoS strategy should prioritize existing users over new users and old coins over new coins. In case Bitcoin suddenly becomes too popular, there must be enough nodes to support all users and some rules can be followed, such as disconnecting recent connections to long-lived connections to avoid running out of TCP sockets and preferring processing new blocks to serving old parts of the chain when disk seeks run out. It is suggested that instead of talking about DoS, we should discuss what happens if Bitcoin suddenly gets too popular and how to handle it.In an email thread discussing a more sophisticated approach to answering challenges, Peter Todd suggests using a version of H() that has a computational trap-door and is significantly faster running time than H(). He asks Adam what can be used for H', and suggests creating a set of expensive-to-compute data associated with the node's identity that can be stored once by the node but requires clients to store one set for every unique node they connect to. This can also be used as a proof-of-work to make creating lots of nodes expensive, and can incorporate blockchain data. This method can also make MITM attacks on encrypted P2P connections expensive without any form of authentication.Michael has informed Bazyli about a fresh build based on git (Xcode) and has faced an issue where the paillier and account tests were missing. Michael has asked Bazyli to comment them out in tests/CMakeLists.txt so that the coinexplorer can build without any issues. Michael has also mentioned that he has done a git push, therefore, Bazyli needs to do a git pull first before proceeding.The email is a response to a query about building Xcode projects with libcoin on Mac OSX. The sender notes that they develop mainly on Mac OSX and build Xcode projects with libcoin daily on both Mac OSX and Linux, but find building on Windows more difficult. The sender suggests that QT is not necessary and can be removed as the qt part got split out. Building clean on Mac requires OpenSSL, BDB, and Boost, which can be installed using homebrew. Latest CMake should also be used and a normal CMake Xcode call: cmake -GXcode should do the job. The sender provides some quick notes for building stuff and recommends trying coinexplorer because it splits out the wallet from the server, making it nice if you want to build a webcoin-like server. The sender does not use the wallet parts from bitcoind personally, so if there are problems with these, the sender will need to have a closer look. Additionally, the current version of libcoin adds a lot of different features and handles things quite differently compared to the first version, which was a direct refactorization of bitcoin. For example, one can look up any unspent output by script (bitcoin address) in milliseconds, which is nice for web wallets. The sender also mentions that BitcoinKit is a separate dynamic library compiled with gcc (or at least llvm pretending to be gcc) due to templates - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Tor-and-Bitcoin.xml b/static/bitcoin-dev/July_2013/combined_Tor-and-Bitcoin.xml index 9c3ee2bd59..d66b9e7874 100644 --- a/static/bitcoin-dev/July_2013/combined_Tor-and-Bitcoin.xml +++ b/static/bitcoin-dev/July_2013/combined_Tor-and-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Tor and Bitcoin - 2023-08-01T05:28:06.242364+00:00 + 2025-10-11T21:51:44.812884+00:00 + python-feedgen Peter Todd 2013-07-30 20:12:50+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Tor and Bitcoin - 2023-08-01T05:28:06.242364+00:00 + 2025-10-11T21:51:44.813026+00:00 - In a 2013 email thread, Peter Todd discusses a potential improvement to Simplified Payment Verification (SPV) security. He suggests requesting the history of a given transaction output (txout), including the previous transactions that funded it. This could be done using a non-interactive proof and sampling a subset of the prior transactions. However, the infrastructure is not currently set up for this, and txids are not constructed in ways that make these proofs cheap. Peter suggests implementing this as a soft-fork in the future.The email exchange between Wendell and Peter Todd revolves around Tor and its applicability to full and SPV nodes. Peter notes that while both types of nodes can use Tor, SPV nodes are generally less safe as they rely solely on confirmations for security. He explains how an attacker can target multiple entities using SPV by creating an invalid block header with fake payments. To improve SPV security, Peter suggests requesting the history of a txout using a zero-knowledge proof and sampling a subset of the prior transactions. However, this feature is not currently available. Peter advises against trusting zero-conf transactions and recommends using Tor to preserve privacy.The discussion on Tor in Bitcoinj focuses on the need for SOCKS support and hidden peers. It is noted that Tor doesn't act as an effective man-in-the-middle for nodes connecting to hidden services. Gregory Maxwell's idea of adding .onion addresses of seed nodes alongside DNS seeds table is mentioned as a way to establish an MITM-proof channel to a trusted seed. The suggestion is that ideally, those .onion addresses would be run by the same people as the existing seeds. Bitcoin relays .onion addresses over the P2P network, providing additional peers that are MITM-resistant. There is also a mention of adding node identities in the future to prevent sybil attacks.The conversation on the Bitcoin-development mailing list centers around the need for better configurability in Tor. Jeff Garzik suggests exploring linking directly with a Tor library instead of relying on an external process. Wendell shares a Tor.framework for Cocoa developers that embeds existing tor code and reroutes internal internet communication via Tor's proxy. Some participants feel that more significant configurability is needed in Tor itself. The release of a new Tor.framework for Cocoa developers, similar to BitcoinKit, is announced by Wendell.In July 2013, Mike Hearn suggests talking directly to the Tor protocol and choosing diverse exit nodes. However, this is complicated as Tor doesn't provide a library or API. Some believe that linking directly with a Tor library would be superior to an external process. Without such a library, one must be written.The article discusses various ideas to prevent a theoretical attack on Bitcoin, including using Tor SOCKS proxy and hard-coded long-term stable hidden peers run by trusted community members. Talking directly with the Tor protocol to choose diverse exit nodes is also suggested. While the attack is theoretical, the author is not aware of any countries blocking Bitcoin. Support for SOCKS and SSL is seen as beneficial.The discussion raises the question of whether it is advisable for SPV wallets to use Tor. Mike Hearn warns about the potential risks of connecting outbound from Tor, including being logged and MITMd by exit nodes. To support Tor well in bitcoinj, hidden peers and an anti-sybil heuristic would need to be added. The comments of Gregory Maxwell on hidden service support for bitcoind are suggested as interesting to explore further. 2013-07-30T20:12:50+00:00 + In a 2013 email thread, Peter Todd discusses a potential improvement to Simplified Payment Verification (SPV) security. He suggests requesting the history of a given transaction output (txout), including the previous transactions that funded it. This could be done using a non-interactive proof and sampling a subset of the prior transactions. However, the infrastructure is not currently set up for this, and txids are not constructed in ways that make these proofs cheap. Peter suggests implementing this as a soft-fork in the future.The email exchange between Wendell and Peter Todd revolves around Tor and its applicability to full and SPV nodes. Peter notes that while both types of nodes can use Tor, SPV nodes are generally less safe as they rely solely on confirmations for security. He explains how an attacker can target multiple entities using SPV by creating an invalid block header with fake payments. To improve SPV security, Peter suggests requesting the history of a txout using a zero-knowledge proof and sampling a subset of the prior transactions. However, this feature is not currently available. Peter advises against trusting zero-conf transactions and recommends using Tor to preserve privacy.The discussion on Tor in Bitcoinj focuses on the need for SOCKS support and hidden peers. It is noted that Tor doesn't act as an effective man-in-the-middle for nodes connecting to hidden services. Gregory Maxwell's idea of adding .onion addresses of seed nodes alongside DNS seeds table is mentioned as a way to establish an MITM-proof channel to a trusted seed. The suggestion is that ideally, those .onion addresses would be run by the same people as the existing seeds. Bitcoin relays .onion addresses over the P2P network, providing additional peers that are MITM-resistant. There is also a mention of adding node identities in the future to prevent sybil attacks.The conversation on the Bitcoin-development mailing list centers around the need for better configurability in Tor. Jeff Garzik suggests exploring linking directly with a Tor library instead of relying on an external process. Wendell shares a Tor.framework for Cocoa developers that embeds existing tor code and reroutes internal internet communication via Tor's proxy. Some participants feel that more significant configurability is needed in Tor itself. The release of a new Tor.framework for Cocoa developers, similar to BitcoinKit, is announced by Wendell.In July 2013, Mike Hearn suggests talking directly to the Tor protocol and choosing diverse exit nodes. However, this is complicated as Tor doesn't provide a library or API. Some believe that linking directly with a Tor library would be superior to an external process. Without such a library, one must be written.The article discusses various ideas to prevent a theoretical attack on Bitcoin, including using Tor SOCKS proxy and hard-coded long-term stable hidden peers run by trusted community members. Talking directly with the Tor protocol to choose diverse exit nodes is also suggested. While the attack is theoretical, the author is not aware of any countries blocking Bitcoin. Support for SOCKS and SSL is seen as beneficial.The discussion raises the question of whether it is advisable for SPV wallets to use Tor. Mike Hearn warns about the potential risks of connecting outbound from Tor, including being logged and MITMd by exit nodes. To support Tor well in bitcoinj, hidden peers and an anti-sybil heuristic would need to be added. The comments of Gregory Maxwell on hidden service support for bitcoind are suggested as interesting to explore further. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_Two-factor-wallet-with-one-time-passwords.xml b/static/bitcoin-dev/July_2013/combined_Two-factor-wallet-with-one-time-passwords.xml index ba262aa981..bb48d9b098 100644 --- a/static/bitcoin-dev/July_2013/combined_Two-factor-wallet-with-one-time-passwords.xml +++ b/static/bitcoin-dev/July_2013/combined_Two-factor-wallet-with-one-time-passwords.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Two factor wallet with one-time-passwords - 2023-08-01T05:26:19.294015+00:00 + 2025-10-11T21:51:53.318977+00:00 + python-feedgen Peter Todd 2013-08-08 18:20:14+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Two factor wallet with one-time-passwords - 2023-08-01T05:26:19.294015+00:00 + 2025-10-11T21:51:53.319103+00:00 - In a mailing list conversation, Peter Todd discusses the importance of careful handling of incoming funds in a multi-party wallet to prevent attackers from deceiving users into sending funds to the wrong address. He suggests that funds sent to the wallet should be divided into separate authorization amounts by all parties involved in authorizing outgoing payments. Todd also mentions that providing customers with a physical private key, such as on a sheet of paper, could be legally desirable for transferring large amounts of Bitcoin.Todd further explains that with multi-factor wallets, the customer provides one or more keys, while the final key is given to them on a sheet of paper with instructions to scan it on their phone via a QR code. Another method could involve using one-time passwords, with the final approval done over the phone by sharing certain "magic words" with the customer to unlock their funds. Although there is still a risk of funds being locked due to an error, there isn't a financial incentive for it to happen. Todd expresses disappointment that OP_EVAL was not implemented, as it would have allowed customers to provide a P2SH script to easily unlock funds.On July 28, 2013, a discussion was held on the Bitcoin development mailing list regarding minor scripting language additions to implement merklized abstract syntax tree (MAST) support. Peter Todd proposed a version where scriptPubKey's can be reused by verifying the path. He also highlighted the drawback of large storage requirements for wallets. In response, another user suggested that the size of the table deriving which H(nonce) is selected for a given txid:vout can be significantly smaller, and nested IF statements can be replaced by creating the merkle tree over the tuples [i,H(nonce_i)] and proving that the provided nonce_i matched the precommitted tree.The author introduces a new implementation of P2SH outputs that allows for the reuse of scriptPubKeys. This implementation involves a merklized abstract syntax tree (MAST) and the use of short 6-word strings as authorization for payment. However, one disadvantage is the large storage requirements for wallets. Nonetheless, both tables can be stored in a distributed hash table in the cloud without compromising security. The security level remains at 2^64, making it difficult for attackers to find a 64-bit pre-image.Gavin Andresen proposed a new design for a wallet that utilizes two-factor authentication through one-time passwords with a third-party service to counter-sign 2-of-2 protected wallets. However, involving a third-party introduces privacy and availability risks. An alternate design eliminates the need for a third-party and offers other advantages and disadvantages. In this design, the user has a wallet with separate balances for savings and day-to-day spending. Transactions from the day-to-day balance do not require authorization, but spending from the savings balance necessitates the use of one-time passwords. When the day-to-day balance becomes low, the user can authorize the movement of discrete multiples of a specific amount from savings to spending using one one-time password per multiple being moved. Savings utilize P2SH outputs that match HASH160 EQUALVERIFY CHECKSIG spent with pubkey/seckey generated deterministically using a counter-based one-time password scheme. Nonces are generated deterministically using RFC2289, and a security level of 64 bits is considered sufficient.It is interesting to note that in certain cases, it may be preferable to have authorization solely focused on spending without any additional involvement. In such cases, the party acting as an oracle does not need to know where the funds are going and can even authorize the spend in advance without two-way communication, potentially prior to the funds being received in the first place. Funding the wallet requires the participation of all parties involved in authorizing an outgoing payment. Additionally, the protection only works if funds sent to the wallet are divided into the discrete authorization amounts desired by the user. These systems, aimed at fund splitting, require further research and development, as they have not received as much attention as payment protocols between customers and merchants. The basic idea is to have multiple devices participate in generating a payment request that is somehow signed. For fund splitting, the request can specify that the funds are paid to multiple transaction outputs simultaneously. 2013-08-08T18:20:14+00:00 + In a mailing list conversation, Peter Todd discusses the importance of careful handling of incoming funds in a multi-party wallet to prevent attackers from deceiving users into sending funds to the wrong address. He suggests that funds sent to the wallet should be divided into separate authorization amounts by all parties involved in authorizing outgoing payments. Todd also mentions that providing customers with a physical private key, such as on a sheet of paper, could be legally desirable for transferring large amounts of Bitcoin.Todd further explains that with multi-factor wallets, the customer provides one or more keys, while the final key is given to them on a sheet of paper with instructions to scan it on their phone via a QR code. Another method could involve using one-time passwords, with the final approval done over the phone by sharing certain "magic words" with the customer to unlock their funds. Although there is still a risk of funds being locked due to an error, there isn't a financial incentive for it to happen. Todd expresses disappointment that OP_EVAL was not implemented, as it would have allowed customers to provide a P2SH script to easily unlock funds.On July 28, 2013, a discussion was held on the Bitcoin development mailing list regarding minor scripting language additions to implement merklized abstract syntax tree (MAST) support. Peter Todd proposed a version where scriptPubKey's can be reused by verifying the path. He also highlighted the drawback of large storage requirements for wallets. In response, another user suggested that the size of the table deriving which H(nonce) is selected for a given txid:vout can be significantly smaller, and nested IF statements can be replaced by creating the merkle tree over the tuples [i,H(nonce_i)] and proving that the provided nonce_i matched the precommitted tree.The author introduces a new implementation of P2SH outputs that allows for the reuse of scriptPubKeys. This implementation involves a merklized abstract syntax tree (MAST) and the use of short 6-word strings as authorization for payment. However, one disadvantage is the large storage requirements for wallets. Nonetheless, both tables can be stored in a distributed hash table in the cloud without compromising security. The security level remains at 2^64, making it difficult for attackers to find a 64-bit pre-image.Gavin Andresen proposed a new design for a wallet that utilizes two-factor authentication through one-time passwords with a third-party service to counter-sign 2-of-2 protected wallets. However, involving a third-party introduces privacy and availability risks. An alternate design eliminates the need for a third-party and offers other advantages and disadvantages. In this design, the user has a wallet with separate balances for savings and day-to-day spending. Transactions from the day-to-day balance do not require authorization, but spending from the savings balance necessitates the use of one-time passwords. When the day-to-day balance becomes low, the user can authorize the movement of discrete multiples of a specific amount from savings to spending using one one-time password per multiple being moved. Savings utilize P2SH outputs that match HASH160 EQUALVERIFY CHECKSIG spent with pubkey/seckey generated deterministically using a counter-based one-time password scheme. Nonces are generated deterministically using RFC2289, and a security level of 64 bits is considered sufficient.It is interesting to note that in certain cases, it may be preferable to have authorization solely focused on spending without any additional involvement. In such cases, the party acting as an oracle does not need to know where the funds are going and can even authorize the spend in advance without two-way communication, potentially prior to the funds being received in the first place. Funding the wallet requires the participation of all parties involved in authorizing an outgoing payment. Additionally, the protection only works if funds sent to the wallet are divided into the discrete authorization amounts desired by the user. These systems, aimed at fund splitting, require further research and development, as they have not received as much attention as payment protocols between customers and merchants. The basic idea is to have multiple devices participate in generating a payment request that is somehow signed. For fund splitting, the request can specify that the funds are paid to multiple transaction outputs simultaneously. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2013/combined_libzerocoin-released-what-about-a-zerocoin-only-alt-coin-with-either-or-mining.xml b/static/bitcoin-dev/July_2013/combined_libzerocoin-released-what-about-a-zerocoin-only-alt-coin-with-either-or-mining.xml index fa3655fe62..d4ec3b74c4 100644 --- a/static/bitcoin-dev/July_2013/combined_libzerocoin-released-what-about-a-zerocoin-only-alt-coin-with-either-or-mining.xml +++ b/static/bitcoin-dev/July_2013/combined_libzerocoin-released-what-about-a-zerocoin-only-alt-coin-with-either-or-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - libzerocoin released, what about a zerocoin-only alt-coin with either-or mining - 2023-08-01T05:16:57.707740+00:00 + 2025-10-11T21:51:42.689000+00:00 + python-feedgen Peter Vessenes 2013-07-16 03:54:23+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - libzerocoin released, what about a zerocoin-only alt-coin with either-or mining - 2023-08-01T05:16:57.707740+00:00 + 2025-10-11T21:51:42.689195+00:00 - In recent discussions among Bitcoin developers, the risks associated with starting an alt-chain based on proof of work were addressed. Peter Todd expressed concerns about pool operators attacking such chains. He also mentioned the controversy surrounding sacrificing something outside of Bitcoin's chain and the appearance of new BTC. Merged-mining was brought up as a more profitable alternative, emphasizing the importance of following the rules and mining the other coin. Todd criticized those who consider something sellable for BTC as having "negative value." The concept of proof-of-sacrifice being opaque to the master blockchain was discussed, along with SCIP-based merged mining, which was deemed a dream.Jorge Timón, in an email exchange from 2013, provided his perspective on Bitcoin mining. He argued that one-way sacrifice (BTC to Zerocoin) is not controversial because it requires no modifications to Bitcoin. However, he pointed out that sacrificing something outside of Bitcoin's chain and the appearance of new BTC is indeed controversial. Timón focused on merged mining and stated that miners not participating in merged mining Namecoin are irrational agents. He also mentioned Prime Proof of Work and SCIP-based mining, highlighting variations in value for miners in different jurisdictions.Peter Vessenes discussed the issue of market liquidity for alternative currencies that do not peg to Bitcoin. He suggested automated BitcoinZerocoin P2P trading as a solution that would also enhance privacy.Luke-Jr proposed implementing a Zerocoin with no-reward/PoSacrifice merged mining during a discussion on creating an alt-coin. However, Peter Todd questioned Luke-Jr's credibility due to past involvement in 51% attacks on alt-coins. The concept of bi-directional sacrifice for Zerocoin was explained, where a Zerocoin is created by proving that a Bitcoin was sacrificed in a specific way. The potential impact of long-term Bitcoin deflation if Bitcoins are permanently sacrificed was discussed, along with the need for consensus on the Bitcoin blockchain for Zerocoin verification.Adam and John Dillon had a conversation responding to Jorge Timón's argument in favor of Zerocoin. The group discussed merged mining and the importance of the cost of mining invalid blocks. Pieter Wuille and Luke-Jr raised concerns about merge-mining's potential risk on blockchain security, particularly the possibility of miners mining invalid blocks without a cost. The assumption of mining security and the significance of having a cost associated with mining were debated.Overall, these conversations shed light on various perspectives related to Bitcoin mining, including alt-chain risks, merged mining profitability, proof-of-sacrifice, and merge mining's security implications. The discussions also touched upon liquidity, privacy, and the costs involved in mining invalid blocks. 2013-07-16T03:54:23+00:00 + In recent discussions among Bitcoin developers, the risks associated with starting an alt-chain based on proof of work were addressed. Peter Todd expressed concerns about pool operators attacking such chains. He also mentioned the controversy surrounding sacrificing something outside of Bitcoin's chain and the appearance of new BTC. Merged-mining was brought up as a more profitable alternative, emphasizing the importance of following the rules and mining the other coin. Todd criticized those who consider something sellable for BTC as having "negative value." The concept of proof-of-sacrifice being opaque to the master blockchain was discussed, along with SCIP-based merged mining, which was deemed a dream.Jorge Timón, in an email exchange from 2013, provided his perspective on Bitcoin mining. He argued that one-way sacrifice (BTC to Zerocoin) is not controversial because it requires no modifications to Bitcoin. However, he pointed out that sacrificing something outside of Bitcoin's chain and the appearance of new BTC is indeed controversial. Timón focused on merged mining and stated that miners not participating in merged mining Namecoin are irrational agents. He also mentioned Prime Proof of Work and SCIP-based mining, highlighting variations in value for miners in different jurisdictions.Peter Vessenes discussed the issue of market liquidity for alternative currencies that do not peg to Bitcoin. He suggested automated BitcoinZerocoin P2P trading as a solution that would also enhance privacy.Luke-Jr proposed implementing a Zerocoin with no-reward/PoSacrifice merged mining during a discussion on creating an alt-coin. However, Peter Todd questioned Luke-Jr's credibility due to past involvement in 51% attacks on alt-coins. The concept of bi-directional sacrifice for Zerocoin was explained, where a Zerocoin is created by proving that a Bitcoin was sacrificed in a specific way. The potential impact of long-term Bitcoin deflation if Bitcoins are permanently sacrificed was discussed, along with the need for consensus on the Bitcoin blockchain for Zerocoin verification.Adam and John Dillon had a conversation responding to Jorge Timón's argument in favor of Zerocoin. The group discussed merged mining and the importance of the cost of mining invalid blocks. Pieter Wuille and Luke-Jr raised concerns about merge-mining's potential risk on blockchain security, particularly the possibility of miners mining invalid blocks without a cost. The assumption of mining security and the significance of having a cost associated with mining were debated.Overall, these conversations shed light on various perspectives related to Bitcoin mining, including alt-chain risks, merged mining profitability, proof-of-sacrifice, and merge mining's security implications. The discussions also touched upon liquidity, privacy, and the costs involved in mining invalid blocks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_-ANN-Armory-0-92-with-Decentralized-Multi-sig-and-Simulfunding.xml b/static/bitcoin-dev/July_2014/combined_-ANN-Armory-0-92-with-Decentralized-Multi-sig-and-Simulfunding.xml index 0707dc0d8e..9506383821 100644 --- a/static/bitcoin-dev/July_2014/combined_-ANN-Armory-0-92-with-Decentralized-Multi-sig-and-Simulfunding.xml +++ b/static/bitcoin-dev/July_2014/combined_-ANN-Armory-0-92-with-Decentralized-Multi-sig-and-Simulfunding.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [ANN] Armory 0.92 with Decentralized Multi-sig and Simulfunding - 2023-08-01T10:08:42.007372+00:00 + 2025-10-11T22:04:23.758451+00:00 + python-feedgen Justus Ranvier 2014-07-31 18:33:05+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [ANN] Armory 0.92 with Decentralized Multi-sig and Simulfunding - 2023-08-01T10:08:42.007372+00:00 + 2025-10-11T22:04:23.758580+00:00 - Alan Reiner, a software developer, expressed his hope to provide an optional service to synchronize data between parties. However, before creating one’s own service, it would be better to add Bitmessage integration to provide the P2P communication layer. The author suggests that Bitmessage should be more trusted in the long term because the service created by an individual would not be their primary product or core competency.Armory has announced Lockboxes, a multi-signature transaction interface. The interface allows for decentralised multi-sig, offline signing devices and private key management. The interface is compatible with existing Armory wallets and can be used for escrow and contracts. Simultaneous funding ("simulfunding") features are included.Armory Technologies is offering to match up to 20 BTC in donations to the EFF, FSF, College Crypto Network, Chamber of Digital Commerce, and the Bitcoin Foundation. The software has been tested for over three months, and the team has been using it for the management of company funds between officers for the last two months.Multi-Signature Lockboxes are available through a full-featured interface for creating multi-signature addresses, putting money into them, and collecting signatures to spend them. Additionally, "Simulfunding" for Addresses and Lockboxes is also available through the "Multi-Sig" menu. Several upgrades have also been made to improve stability, compatibility, functionality, and usability. To support online privacy, the message concludes with a call to use email encryption whenever possible and provides a link to learn how to do so. 2014-07-31T18:33:05+00:00 + Alan Reiner, a software developer, expressed his hope to provide an optional service to synchronize data between parties. However, before creating one’s own service, it would be better to add Bitmessage integration to provide the P2P communication layer. The author suggests that Bitmessage should be more trusted in the long term because the service created by an individual would not be their primary product or core competency.Armory has announced Lockboxes, a multi-signature transaction interface. The interface allows for decentralised multi-sig, offline signing devices and private key management. The interface is compatible with existing Armory wallets and can be used for escrow and contracts. Simultaneous funding ("simulfunding") features are included.Armory Technologies is offering to match up to 20 BTC in donations to the EFF, FSF, College Crypto Network, Chamber of Digital Commerce, and the Bitcoin Foundation. The software has been tested for over three months, and the team has been using it for the management of company funds between officers for the last two months.Multi-Signature Lockboxes are available through a full-featured interface for creating multi-signature addresses, putting money into them, and collecting signatures to spend them. Additionally, "Simulfunding" for Addresses and Lockboxes is also available through the "Multi-Sig" menu. Several upgrades have also been made to improve stability, compatibility, functionality, and usability. To support online privacy, the message concludes with a call to use email encryption whenever possible and provides a link to learn how to do so. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_-On-behalf-of-BIP-70-extension-proposal.xml b/static/bitcoin-dev/July_2014/combined_-On-behalf-of-BIP-70-extension-proposal.xml index 0dba82a519..8ced04711d 100644 --- a/static/bitcoin-dev/July_2014/combined_-On-behalf-of-BIP-70-extension-proposal.xml +++ b/static/bitcoin-dev/July_2014/combined_-On-behalf-of-BIP-70-extension-proposal.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - "On behalf of" BIP 70 extension proposal - 2023-08-01T10:06:41.464636+00:00 + Combined summary - "On behalf of" BIP 70 extension proposal + 2025-10-11T22:03:58.268526+00:00 + python-feedgen Mike Hearn 2014-07-30 11:34:59+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 - Combined summary - "On behalf of" BIP 70 extension proposal - 2023-08-01T10:06:41.465639+00:00 + Combined summary - "On behalf of" BIP 70 extension proposal + 2025-10-11T22:03:58.268698+00:00 - During a conversation between Mark van Cuijk and Mike Hearn, they discussed the implementation of a new BIP for formalizing the extensions process. Mike expressed frustration with payment processors not using useful memo fields and hopes that once wallets start displaying memos in their transactions list, this will change. Mark offered to write the proposal for the new BIP but was unsure whether it should be a standalone BIP or part of BIP70. They also discussed how the extensions process should describe the proposal's process.On July 28, 2014, Mike Hearn expressed his priority with BIP70 to formalize the extensions process. He planned to write a proposal and hoped to get BitPay/Coinbase to put useful text in the memo field instead of random numbers. Although he was unsure about the process to follow, he could probably pick up writing the proposal. He questioned if the proposal should be formatted as a new BIP or part of BIP.70 and how the extensions process would describe it.In a discussion thread on the Bitcoin development mailing list, participants debated the best way for a payment processor (PP) to issue non-SSL certificates for merchant identification. One participant referred to another's idea, which suggested that a merchant should issue an extension certificate that allows the PP to act on their behalf. However, the original poster clarified that their proposal required two signatures over the payment request data, one with the X.509 certificate key for backward compatibility and one with the ECDSA public key. Another participant suggested that this was too complex and argued in favor of a simpler proposal that only required one signature using the former key. Overall, the discussion focused on balancing security concerns with backward compatibility.In an email exchange between Mark van Cuijk and Mike, they discussed the idea of a payment processor issuing non-SSL certificates for merchant identification. Mark suggests the opposite, where a merchant issues an extension cert to allow the payment processor to act on their behalf. They also discussed the choice of how to authenticate the payment processor, with Mark preferring his proposal due to backward compatibility concerns, while Mike's extended certificate system was deemed cleaner but required two separate signatures for old and new clients.In another email exchange, two individuals discuss the idea of implementing a system for verifying merchant identity in online transactions. They consider options including X.509 CAs, Payment Processors (PP), and PGP/Bitcoin-based systems for verifying the identity of the merchant. They also discuss different methods of identification and authentication, such as X.509 certificates, merchant identifiers, Twitter handles, and extended certificates. One individual suggests sticking with the X.509 system for identification of the merchant but likes the idea of a PP issuing non-SSL certificates for merchant identification. The other individual agrees that their proposals do not differ substantially and thinks that the extended certificate system is cleaner but prefers Mark's proposal because of backward compatibility concerns. They conclude by stating that someone needs to make the proposed system happen.During a user experience test, it was discovered that identifying payment processors instead of merchants could create problems. Mark proposes extending the PaymentRequest message with additional fields to authenticate the identity of the merchant, rather than the payment processor. This solution allows existing wallets to continue showing the identity of the payment processor, while wallets that understand the extension can display the identity information of the merchant. Payment processors supporting the extension may offer it as an optional service, where clients must obtain their own certificate from a CA and sign a mandate. The process may need to be repeated when either the merchant's or payment processor's certificates expire. 2014-07-30T11:34:59+00:00 + During a conversation between Mark van Cuijk and Mike Hearn, they discussed the implementation of a new BIP for formalizing the extensions process. Mike expressed frustration with payment processors not using useful memo fields and hopes that once wallets start displaying memos in their transactions list, this will change. Mark offered to write the proposal for the new BIP but was unsure whether it should be a standalone BIP or part of BIP70. They also discussed how the extensions process should describe the proposal's process.On July 28, 2014, Mike Hearn expressed his priority with BIP70 to formalize the extensions process. He planned to write a proposal and hoped to get BitPay/Coinbase to put useful text in the memo field instead of random numbers. Although he was unsure about the process to follow, he could probably pick up writing the proposal. He questioned if the proposal should be formatted as a new BIP or part of BIP.70 and how the extensions process would describe it.In a discussion thread on the Bitcoin development mailing list, participants debated the best way for a payment processor (PP) to issue non-SSL certificates for merchant identification. One participant referred to another's idea, which suggested that a merchant should issue an extension certificate that allows the PP to act on their behalf. However, the original poster clarified that their proposal required two signatures over the payment request data, one with the X.509 certificate key for backward compatibility and one with the ECDSA public key. Another participant suggested that this was too complex and argued in favor of a simpler proposal that only required one signature using the former key. Overall, the discussion focused on balancing security concerns with backward compatibility.In an email exchange between Mark van Cuijk and Mike, they discussed the idea of a payment processor issuing non-SSL certificates for merchant identification. Mark suggests the opposite, where a merchant issues an extension cert to allow the payment processor to act on their behalf. They also discussed the choice of how to authenticate the payment processor, with Mark preferring his proposal due to backward compatibility concerns, while Mike's extended certificate system was deemed cleaner but required two separate signatures for old and new clients.In another email exchange, two individuals discuss the idea of implementing a system for verifying merchant identity in online transactions. They consider options including X.509 CAs, Payment Processors (PP), and PGP/Bitcoin-based systems for verifying the identity of the merchant. They also discuss different methods of identification and authentication, such as X.509 certificates, merchant identifiers, Twitter handles, and extended certificates. One individual suggests sticking with the X.509 system for identification of the merchant but likes the idea of a PP issuing non-SSL certificates for merchant identification. The other individual agrees that their proposals do not differ substantially and thinks that the extended certificate system is cleaner but prefers Mark's proposal because of backward compatibility concerns. They conclude by stating that someone needs to make the proposed system happen.During a user experience test, it was discovered that identifying payment processors instead of merchants could create problems. Mark proposes extending the PaymentRequest message with additional fields to authenticate the identity of the merchant, rather than the payment processor. This solution allows existing wallets to continue showing the identity of the payment processor, while wallets that understand the extension can display the identity information of the merchant. Payment processors supporting the extension may offer it as an optional service, where clients must obtain their own certificate from a CA and sign a mandate. The process may need to be repeated when either the merchant's or payment processor's certificates expire. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_ASIC-proof-mining.xml b/static/bitcoin-dev/July_2014/combined_ASIC-proof-mining.xml index 9690a7d436..30cf50c0db 100644 --- a/static/bitcoin-dev/July_2014/combined_ASIC-proof-mining.xml +++ b/static/bitcoin-dev/July_2014/combined_ASIC-proof-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ASIC-proof mining - 2023-08-01T09:41:23.937038+00:00 + 2025-10-11T22:04:21.633557+00:00 + python-feedgen Odinn Cyberguerrilla 2014-07-07 06:12:42+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - ASIC-proof mining - 2023-08-01T09:41:23.937038+00:00 + 2025-10-11T22:04:21.633744+00:00 - In the world of cryptocurrency mining, the concept of a "runner up" does not exist. Instead, miners are rewarded for "near miss" solutions through pools that pay for shares that almost meet the difficulty target. The challenge lies in implementing this reward structure without miners giving up their right to block creation. Mike Hearn suggested the idea of rewarding "near miss" solutions through pools, which already exist and pay miners for shares that almost meet the difficulty target.Jorge Timón argues that algorithms are better in an application-specific device (ASD) than in a general-purpose computer. He believes that anything that can be done with software can also be done with hardware. However, he criticizes people who waste time pursuing the "anti-ASIC" myth, stating that algorithms can still be made into ASICs but will require more skilled designers and expensive fabrication. Timón suggests that keeping the algorithm simple and ASIC-easy promotes diversity in the marketplace but questions whether it is desirable to have people capable of mining who have not shown any interest.The efficiency of Proof-of-Work (POW) algorithms and their potential ASD implementation is discussed on the Bitcoin-development mailing list. One user believes that there are no algorithms that cannot be performed better in an ASD than in a general-purpose computer. Another user suggests that keeping the algorithm simple and ASIC-easy allows more people to design ASICs, leading to diversity in the marketplace. The conversation also touches on the production of competitive mining equipment and the potential dominance of entities like Intel, AMD, and IBM.Andy Parkins proposes creating an ASIC-proof proof-of-work algorithm. However, the proposal is deemed impractical due to high verification costs and limitations on mobile devices. It is suggested that simpler algorithms promote diversity in the marketplace, but it is acknowledged that specialized high-efficiency hardware for mining may still exist. Despite the limitations, the discussion surrounding these ideas is seen as important for learning and advancing the technology.The concept of a hashing algorithm called ROMix is discussed in an email exchange between Alan Reiner and Dr. Andy Parkins. ROMix stores sequential hashes into a lookup table, requiring a certain amount of RAM. The goal is to make hashing IO-hungry instead of memory hungry, but the implementation and trade-offs are still being discussed.One of the challenges in mining Bitcoin is the ability for miners to produce one hash for everybody, which does not affect the actual hash rate but makes it harder to reproduce. The difficulty adjustment algorithm ensures that blocks come at 10-minute intervals regardless of the hash rate. One possible solution to make mining "unASICable" is to use a harder algorithm or increase the size of the input data that needs hashing. Unlike an algorithm change, increasing the input size cannot be reduced by building a better ASIC.Alan Reiner suggests using the hash of a prevBlockHash||nonce as the starting point for 1,000,000 lookup operations to achieve the goal of making mining unASICable. Each previous lookup would determine which block and transaction is used for the next lookup. This method requires the entire blockchain to be available, even though only a small fraction of it is used for each "hash." Another participant suggests that involving lots of unpredictable memory accesses to a large chunk of fast memory is also unASICable. They propose deriving the data vector by the same means as a one-time pad and loading it into memory after boot. By making the vector large enough, it won't benefit from embedded RAM bandwidth/speedup, and clustering won't offer economies of scale.Andy Parkins suggests protecting against ASIC mining by making the algorithm IO-bound instead of CPU-bound. In his idea, the proof-of-work hash for a block would be the hash of "[NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]," where [ALL_PREVIOUS_BLOCKS] is 20GB and growing. This approach requires every byte of the blockchain to be fed through the hashing engine, making it IO-bound. Alan suggests using the ROMix algorithm defined by Colin Percival for this idea. It involves taking N sequential hashes and storing the results into a single N*32 byte lookup table. Applying a similar concept to Andy's idea, they can use the hash of a prevBlockHash||nonce as the starting point for 1,000,000 lookup operations to achieve what Andy describes without requiring the full 20 GB of reading on every hash.In response to the notion that it is impossible to have an ASIC-proof proof-of-work algorithm, Dr. Andy Parkins suggests that while no algorithm can exist that cannot be implemented in an ASIC, it is only true for algorithms that are CPU-bound. To protect against ASIC mining, the algorithm could be made IO-bound instead. By making the proof-of-work hash for a block the hash of "[NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]," where [ALL_PREVIOUS_BLOCKS] is 20GB and growing, every byte of the blockchain must be fed through the 2014-07-07T06:12:42+00:00 + In the world of cryptocurrency mining, the concept of a "runner up" does not exist. Instead, miners are rewarded for "near miss" solutions through pools that pay for shares that almost meet the difficulty target. The challenge lies in implementing this reward structure without miners giving up their right to block creation. Mike Hearn suggested the idea of rewarding "near miss" solutions through pools, which already exist and pay miners for shares that almost meet the difficulty target.Jorge Timón argues that algorithms are better in an application-specific device (ASD) than in a general-purpose computer. He believes that anything that can be done with software can also be done with hardware. However, he criticizes people who waste time pursuing the "anti-ASIC" myth, stating that algorithms can still be made into ASICs but will require more skilled designers and expensive fabrication. Timón suggests that keeping the algorithm simple and ASIC-easy promotes diversity in the marketplace but questions whether it is desirable to have people capable of mining who have not shown any interest.The efficiency of Proof-of-Work (POW) algorithms and their potential ASD implementation is discussed on the Bitcoin-development mailing list. One user believes that there are no algorithms that cannot be performed better in an ASD than in a general-purpose computer. Another user suggests that keeping the algorithm simple and ASIC-easy allows more people to design ASICs, leading to diversity in the marketplace. The conversation also touches on the production of competitive mining equipment and the potential dominance of entities like Intel, AMD, and IBM.Andy Parkins proposes creating an ASIC-proof proof-of-work algorithm. However, the proposal is deemed impractical due to high verification costs and limitations on mobile devices. It is suggested that simpler algorithms promote diversity in the marketplace, but it is acknowledged that specialized high-efficiency hardware for mining may still exist. Despite the limitations, the discussion surrounding these ideas is seen as important for learning and advancing the technology.The concept of a hashing algorithm called ROMix is discussed in an email exchange between Alan Reiner and Dr. Andy Parkins. ROMix stores sequential hashes into a lookup table, requiring a certain amount of RAM. The goal is to make hashing IO-hungry instead of memory hungry, but the implementation and trade-offs are still being discussed.One of the challenges in mining Bitcoin is the ability for miners to produce one hash for everybody, which does not affect the actual hash rate but makes it harder to reproduce. The difficulty adjustment algorithm ensures that blocks come at 10-minute intervals regardless of the hash rate. One possible solution to make mining "unASICable" is to use a harder algorithm or increase the size of the input data that needs hashing. Unlike an algorithm change, increasing the input size cannot be reduced by building a better ASIC.Alan Reiner suggests using the hash of a prevBlockHash||nonce as the starting point for 1,000,000 lookup operations to achieve the goal of making mining unASICable. Each previous lookup would determine which block and transaction is used for the next lookup. This method requires the entire blockchain to be available, even though only a small fraction of it is used for each "hash." Another participant suggests that involving lots of unpredictable memory accesses to a large chunk of fast memory is also unASICable. They propose deriving the data vector by the same means as a one-time pad and loading it into memory after boot. By making the vector large enough, it won't benefit from embedded RAM bandwidth/speedup, and clustering won't offer economies of scale.Andy Parkins suggests protecting against ASIC mining by making the algorithm IO-bound instead of CPU-bound. In his idea, the proof-of-work hash for a block would be the hash of "[NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]," where [ALL_PREVIOUS_BLOCKS] is 20GB and growing. This approach requires every byte of the blockchain to be fed through the hashing engine, making it IO-bound. Alan suggests using the ROMix algorithm defined by Colin Percival for this idea. It involves taking N sequential hashes and storing the results into a single N*32 byte lookup table. Applying a similar concept to Andy's idea, they can use the hash of a prevBlockHash||nonce as the starting point for 1,000,000 lookup operations to achieve what Andy describes without requiring the full 20 GB of reading on every hash.In response to the notion that it is impossible to have an ASIC-proof proof-of-work algorithm, Dr. Andy Parkins suggests that while no algorithm can exist that cannot be implemented in an ASIC, it is only true for algorithms that are CPU-bound. To protect against ASIC mining, the algorithm could be made IO-bound instead. By making the proof-of-work hash for a block the hash of "[NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]," where [ALL_PREVIOUS_BLOCKS] is 20GB and growing, every byte of the blockchain must be fed through the - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Abnormally-Large-Tor-node-accepting-only-Bitcoin-traffic.xml b/static/bitcoin-dev/July_2014/combined_Abnormally-Large-Tor-node-accepting-only-Bitcoin-traffic.xml index 75f4716a58..77cf29f07b 100644 --- a/static/bitcoin-dev/July_2014/combined_Abnormally-Large-Tor-node-accepting-only-Bitcoin-traffic.xml +++ b/static/bitcoin-dev/July_2014/combined_Abnormally-Large-Tor-node-accepting-only-Bitcoin-traffic.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Abnormally Large Tor node accepting only Bitcoin traffic - 2023-08-01T10:07:21.699021+00:00 + 2025-10-11T22:04:30.134193+00:00 + python-feedgen s7r 2014-07-28 16:13:19+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Abnormally Large Tor node accepting only Bitcoin traffic - 2023-08-01T10:07:21.699021+00:00 + 2025-10-11T22:04:30.134367+00:00 - In a Bitcoin-development mailing list, a discussion took place regarding the Sybil attack and identity issues in the bitcoin protocol. Gregory Maxwell argued that the bitcoin protocol is identityless and relies on network capacity, while Robert McKay suggested that the behavior under discussion might not be considered abuse and could improve transaction and block propagation. However, Maxwell noted that it wasn't relaying transactions or blocks to anyone with a connection.On the same mailing list, a user named s7r expressed concerns about the security risks of using bitcoin-qt on a laptop with Tor. They questioned what data a node would see if they used Tor to send or receive BTC and whether a spy node would provide any useful information.In a 2014 discussion thread, Robert McKay expressed doubts about using the term Sybil attack to describe the behavior of the Bitcoin protocol. He argued that the protocol is "identityless" and suggested that "number of sockets" would be a more appropriate measure of activity. McKay also questioned whether this behavior could be considered abuse, as it follows the rules and may even improve transaction and block propagation. However, he acknowledged that the protocol did not appear to be relaying transactions or blocks.Peter Todd reported in an email about a Bitcoin-only exit node that had no traffic leaving it. Todd suspected that the node was part of a Sybil attack attempting to hide behind a Tor exit node. However, another user disagreed, stating that there was only one IP address and suggesting that this behavior could be beneficial for transaction and block propagation.Concerns were raised about a Tor node accepting inbound Bitcoin connections and intercepting port 8333 traffic. The post suggested that someone built this custom Tor node for themselves only, for plausible deniability. The thread included links to websites listing Tor nodes by bandwidth and details about the IP address related to the Tor node.A user expressed concern about a bitcoin-only exit node that had no traffic leaving it. Multiple people confirmed that the node was connected to an abnormally large percentage of the Bitcoin network, leading to suspicions of a Sybil attack. However, another user pointed out that the lack of traffic might be due to Tor's speculative circuit building and suggested that running a Tor exit node only allowing port 8333 could be a way to contribute exit bandwidth without much risk.The "exit" flag in Tor does not necessarily mean what one might expect. Without the exit flag, it's unlikely that a Tor node will select a particular node to exit traffic unless manually configured. The reason for this is because Tor speculatively builds circuits at startup on the assumption they'll be used for web browsing. However, there are legitimate reasons why someone would run such a node, such as contributing exit bandwidth without risking getting raided by authorities.In July 2014, a Tor node accepting inbound Bitcoin connections and intercepting port 8333 traffic was discussed. It was noted that the Tor node did not have an exit flag and was not generating traffic from good-intended clients. Instead, traffic was coming from clients that had specifically added "ExitNode" to their torrc and only used that Tor instance for Bitcoin. The thread provided links to websites listing Tor nodes by bandwidth and details about the IP address associated with the Tor node.A discussion took place regarding a Tor node that was believed to be an exit node for port 8333, which is used by Bitcoin nodes. The node's details were available on websites listing Tor nodes by bandwidth, but it did not have an exit flag, making it unlikely to be selected as an exit node automatically. However, someone may have manually configured it to be an exit node. Concerns were raised about the node intercepting connections on port 8333, but it was unclear if this was actually working. The conversation also touched on the need for better incoming connection limiting for Bitcoin and mentioned a scheme with interactive proof-of-memory. The discussion took place on the Bitcoin-development mailing list.A Tor node was identified as an exit node for port 8333, which is used by Bitcoin nodes. The node's information was available on websites listing Tor nodes by bandwidth, but it did not have an exit flag. This raised concerns about the node intercepting connections on port 8333, but it was unclear if this was actually working. The conversation also discussed the need for better incoming connection limiting for Bitcoin and mentioned a possible scheme with interactive proof-of-memory. The discussion took place on the Bitcoin-development mailing list.A Tor node was found to be accepting inbound Bitcoin connections and intercepting port 8333 traffic. The node did not have an exit flag and appeared to be selectively generating traffic from clients that added "ExitNode" to their torrc and only used that Tor instance for Bitcoin. Concerns were raised about the node intercepting connections and its behavior being similar to a Sybil attack. The discussion included links to websites listing Tor nodes by bandwidth and details about the IP address associated with the Tor node. It took place on the Bitcoin-development mailing 2014-07-28T16:13:19+00:00 + In a Bitcoin-development mailing list, a discussion took place regarding the Sybil attack and identity issues in the bitcoin protocol. Gregory Maxwell argued that the bitcoin protocol is identityless and relies on network capacity, while Robert McKay suggested that the behavior under discussion might not be considered abuse and could improve transaction and block propagation. However, Maxwell noted that it wasn't relaying transactions or blocks to anyone with a connection.On the same mailing list, a user named s7r expressed concerns about the security risks of using bitcoin-qt on a laptop with Tor. They questioned what data a node would see if they used Tor to send or receive BTC and whether a spy node would provide any useful information.In a 2014 discussion thread, Robert McKay expressed doubts about using the term Sybil attack to describe the behavior of the Bitcoin protocol. He argued that the protocol is "identityless" and suggested that "number of sockets" would be a more appropriate measure of activity. McKay also questioned whether this behavior could be considered abuse, as it follows the rules and may even improve transaction and block propagation. However, he acknowledged that the protocol did not appear to be relaying transactions or blocks.Peter Todd reported in an email about a Bitcoin-only exit node that had no traffic leaving it. Todd suspected that the node was part of a Sybil attack attempting to hide behind a Tor exit node. However, another user disagreed, stating that there was only one IP address and suggesting that this behavior could be beneficial for transaction and block propagation.Concerns were raised about a Tor node accepting inbound Bitcoin connections and intercepting port 8333 traffic. The post suggested that someone built this custom Tor node for themselves only, for plausible deniability. The thread included links to websites listing Tor nodes by bandwidth and details about the IP address related to the Tor node.A user expressed concern about a bitcoin-only exit node that had no traffic leaving it. Multiple people confirmed that the node was connected to an abnormally large percentage of the Bitcoin network, leading to suspicions of a Sybil attack. However, another user pointed out that the lack of traffic might be due to Tor's speculative circuit building and suggested that running a Tor exit node only allowing port 8333 could be a way to contribute exit bandwidth without much risk.The "exit" flag in Tor does not necessarily mean what one might expect. Without the exit flag, it's unlikely that a Tor node will select a particular node to exit traffic unless manually configured. The reason for this is because Tor speculatively builds circuits at startup on the assumption they'll be used for web browsing. However, there are legitimate reasons why someone would run such a node, such as contributing exit bandwidth without risking getting raided by authorities.In July 2014, a Tor node accepting inbound Bitcoin connections and intercepting port 8333 traffic was discussed. It was noted that the Tor node did not have an exit flag and was not generating traffic from good-intended clients. Instead, traffic was coming from clients that had specifically added "ExitNode" to their torrc and only used that Tor instance for Bitcoin. The thread provided links to websites listing Tor nodes by bandwidth and details about the IP address associated with the Tor node.A discussion took place regarding a Tor node that was believed to be an exit node for port 8333, which is used by Bitcoin nodes. The node's details were available on websites listing Tor nodes by bandwidth, but it did not have an exit flag, making it unlikely to be selected as an exit node automatically. However, someone may have manually configured it to be an exit node. Concerns were raised about the node intercepting connections on port 8333, but it was unclear if this was actually working. The conversation also touched on the need for better incoming connection limiting for Bitcoin and mentioned a scheme with interactive proof-of-memory. The discussion took place on the Bitcoin-development mailing list.A Tor node was identified as an exit node for port 8333, which is used by Bitcoin nodes. The node's information was available on websites listing Tor nodes by bandwidth, but it did not have an exit flag. This raised concerns about the node intercepting connections on port 8333, but it was unclear if this was actually working. The conversation also discussed the need for better incoming connection limiting for Bitcoin and mentioned a possible scheme with interactive proof-of-memory. The discussion took place on the Bitcoin-development mailing list.A Tor node was found to be accepting inbound Bitcoin connections and intercepting port 8333 traffic. The node did not have an exit flag and appeared to be selectively generating traffic from clients that added "ExitNode" to their torrc and only used that Tor instance for Bitcoin. Concerns were raised about the node intercepting connections and its behavior being similar to a Sybil attack. The discussion included links to websites listing Tor nodes by bandwidth and details about the IP address associated with the Tor node. It took place on the Bitcoin-development mailing - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Abusive-and-broken-bitcoin-seeders.xml b/static/bitcoin-dev/July_2014/combined_Abusive-and-broken-bitcoin-seeders.xml index e1c470fa25..c8f5116eb9 100644 --- a/static/bitcoin-dev/July_2014/combined_Abusive-and-broken-bitcoin-seeders.xml +++ b/static/bitcoin-dev/July_2014/combined_Abusive-and-broken-bitcoin-seeders.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Abusive and broken bitcoin seeders - 2023-08-01T10:08:27.970436+00:00 + 2025-10-11T22:04:42.876559+00:00 + python-feedgen Jameson Lopp 2014-07-31 12:59:17+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Abusive and broken bitcoin seeders - 2023-08-01T10:08:27.970436+00:00 + 2025-10-11T22:04:42.876698+00:00 - Jameson Lopp, a Bitcoin developer, discusses the request volume and abuse on his public node at statoshi.info. He notes that his node receives a "getaddr" request every 50 seconds and sends out a low volume of "addr" messages. Lopp believes that these requests are not resource-intensive, but he is willing to add timing metrics if necessary. Mike Hearn responds by mentioning that the web has survived constant fast crawls for the past decade and suggests not worrying unless a significant amount of resources are being used. This discussion took place in July 2014 on the Bitcoin-development mailing list.The possibility of dealing with constant fast crawls is brought up, but it is noted that the web has managed to survive this for many years. Therefore, there is no immediate need for concern unless a significant amount of resources are being used to answer queries.The context involves a discussion between two individuals regarding requests seen on Jeff's public nodes. It is believed that these requests came from a crawler at IP address 148.251.238.178, which takes snapshots of the network of reachable nodes every few minutes. However, the source of the requests cannot be confirmed since there is no IP address in the log. The individual provides a sample log of a request from their crawler and explains that they want to be able to compare snapshots to track join and leave nodes. They also mention plans to improve their method by skipping new connections with currently reachable nodes while still being able to perform the comparison. Jeff Garzik reports abusive behavior on one of his public nodes, where someone is rapidly reconnecting without reason. Other seeders are also rapidly reconnecting, although with a slightly wider time window. The version message reveals Garzik's own IP address but not the abusers'. Garzik is identified as a Bitcoin core developer and open source evangelist at BitPay, Inc.The email thread discusses the issue of abusive behavior in the Bitcoin network, where certain connections are sending frequent requests. The concern is that this behavior could be used for DDoS attacks and deep scans to gather harmful information about the Bitcoin network. It is difficult to authenticate these connections, but Neil suggests blocking those that send incorrect information like IP addresses of 0.0.0.0 or the users' own IP. However, this may lead to spoofing regular clients, which is undesirable. It is clear that this issue needs to be addressed, although a solution has not been found yet.The email thread also delves into the behavior of a Bitcoin crawler software, specifically its frequency of reconnection. The author notes that the software should not reconnect more than once every 15 minutes, but there is speculation that two connections may actually be different instances. The conversation then shifts to the usefulness of the version message in determining IP addresses. It is suggested to use "-logips" to log peer IPs, although this feature was disabled by default after a specific issue. Wladimir also observes abusive behavior and questions the need for such frequent requests.In summary, Jameson Lopp discusses request volume and abuse on his public node, while Mike Hearn suggests not worrying unless a significant amount of resources are being used. The discussion involves a crawler software and concerns about abusive behavior and the lack of IP address information in the version message. Jeff Garzik reports abusive behavior on his public nodes and notes the absence of the abusers' IP addresses. The email thread explores possible solutions and highlights the need to address these issues in the Bitcoin network. 2014-07-31T12:59:17+00:00 + Jameson Lopp, a Bitcoin developer, discusses the request volume and abuse on his public node at statoshi.info. He notes that his node receives a "getaddr" request every 50 seconds and sends out a low volume of "addr" messages. Lopp believes that these requests are not resource-intensive, but he is willing to add timing metrics if necessary. Mike Hearn responds by mentioning that the web has survived constant fast crawls for the past decade and suggests not worrying unless a significant amount of resources are being used. This discussion took place in July 2014 on the Bitcoin-development mailing list.The possibility of dealing with constant fast crawls is brought up, but it is noted that the web has managed to survive this for many years. Therefore, there is no immediate need for concern unless a significant amount of resources are being used to answer queries.The context involves a discussion between two individuals regarding requests seen on Jeff's public nodes. It is believed that these requests came from a crawler at IP address 148.251.238.178, which takes snapshots of the network of reachable nodes every few minutes. However, the source of the requests cannot be confirmed since there is no IP address in the log. The individual provides a sample log of a request from their crawler and explains that they want to be able to compare snapshots to track join and leave nodes. They also mention plans to improve their method by skipping new connections with currently reachable nodes while still being able to perform the comparison. Jeff Garzik reports abusive behavior on one of his public nodes, where someone is rapidly reconnecting without reason. Other seeders are also rapidly reconnecting, although with a slightly wider time window. The version message reveals Garzik's own IP address but not the abusers'. Garzik is identified as a Bitcoin core developer and open source evangelist at BitPay, Inc.The email thread discusses the issue of abusive behavior in the Bitcoin network, where certain connections are sending frequent requests. The concern is that this behavior could be used for DDoS attacks and deep scans to gather harmful information about the Bitcoin network. It is difficult to authenticate these connections, but Neil suggests blocking those that send incorrect information like IP addresses of 0.0.0.0 or the users' own IP. However, this may lead to spoofing regular clients, which is undesirable. It is clear that this issue needs to be addressed, although a solution has not been found yet.The email thread also delves into the behavior of a Bitcoin crawler software, specifically its frequency of reconnection. The author notes that the software should not reconnect more than once every 15 minutes, but there is speculation that two connections may actually be different instances. The conversation then shifts to the usefulness of the version message in determining IP addresses. It is suggested to use "-logips" to log peer IPs, although this feature was disabled by default after a specific issue. Wladimir also observes abusive behavior and questions the need for such frequent requests.In summary, Jameson Lopp discusses request volume and abuse on his public node, while Mike Hearn suggests not worrying unless a significant amount of resources are being used. The discussion involves a crawler software and concerns about abusive behavior and the lack of IP address information in the version message. Jeff Garzik reports abusive behavior on his public nodes and notes the absence of the abusers' IP addresses. The email thread explores possible solutions and highlights the need to address these issues in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Anyone-still-using-SOCKS4-.xml b/static/bitcoin-dev/July_2014/combined_Anyone-still-using-SOCKS4-.xml index b4dc554cc9..607b773de0 100644 --- a/static/bitcoin-dev/July_2014/combined_Anyone-still-using-SOCKS4-.xml +++ b/static/bitcoin-dev/July_2014/combined_Anyone-still-using-SOCKS4-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Anyone still using SOCKS4? - 2023-08-01T09:30:05.654801+00:00 + 2025-10-11T22:04:40.751755+00:00 + python-feedgen Odinn Cyberguerrilla 2014-07-07 06:54:23+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Anyone still using SOCKS4? - 2023-08-01T09:30:05.654801+00:00 + 2025-10-11T22:04:40.751939+00:00 - In a discussion about SOCKS4 and SOCKS4a, Odinn Cyberguerrilla questioned whether SOCKS4 was designed to prevent information leaks. Wladimir clarified that while SOCKS4a supports DNS lookups on the server, it is not supported by bitcoin core. On the other hand, SOCKS5 can perform all the functions of both SOCKS4 and SOCKS4a. Wladimir encouraged contributions to SOCKS4a support if anyone is interested.The Tor project warns about SOCKS and DNS information leaks, suggesting that using SOCKS4A may be a better alternative. This warning is based on the fact that applications using SOCKS5 only provide Tor with an IP address, while applications that do DNS resolves themselves may leak information. In response to this, someone questioned the necessity of SOCKS4 and SOCKS4A. They also asked if there would be any issues with having a setting for SOCKS4A in a setup that includes Tor, Privoxy, I2P, and FoxyProxy together while running Bitcoin Core. Wladimir responded by stating that they plan on removing support for SOCKS4 in the next major release for two reasons: it would eliminate unused code paths and improve privacy as SOCKS5 allows DNS redirection. Additionally, SOCKS5 supports IPv6.In a discussion on the Bitcoin-development mailing list, Wladimir proposed removing support for SOCKS4 in the next major release. The reasons given were to remove unused code and enhance privacy by allowing DNS redirection. Another reason was that SOCKS5 supports IPv6. With no objections raised, the removal of SOCKS4 was set to proceed. The email also included a message promoting Bonita BPM Community Edition, an open source business process management suite built on Java and Eclipse.In an email dated June 11, 2014, Wladimir suggested removing support for SOCKS4 from the next major release. The reasons provided were to eliminate untested code paths and improve privacy with the use of SOCKS5, which offers DNS redirection. Additionally, SOCKS5 supports IPv6.In a recent message to the Bitcoin Core mailing list, Wladimir announced plans to remove support for SOCKS4-only proxy in the next major release. This decision was made due to the introduction of SOCKS5 in 1996 and the lack of excuses not to support it. The removal of support for SOCKS4-only proxy will eliminate outdated code paths and enhance privacy as SOCKS5 allows DNS redirection. Wladimir also inquired if anyone is currently using a SOCKS4-only proxy with Bitcoin Core. If no concerns or objections are raised, the removal of support for SOCKS4-only proxy will proceed as planned. It's important to note that this change will only impact users still utilizing SOCKS4-only proxy, while those already using SOCKS5 will not be affected. 2014-07-07T06:54:23+00:00 + In a discussion about SOCKS4 and SOCKS4a, Odinn Cyberguerrilla questioned whether SOCKS4 was designed to prevent information leaks. Wladimir clarified that while SOCKS4a supports DNS lookups on the server, it is not supported by bitcoin core. On the other hand, SOCKS5 can perform all the functions of both SOCKS4 and SOCKS4a. Wladimir encouraged contributions to SOCKS4a support if anyone is interested.The Tor project warns about SOCKS and DNS information leaks, suggesting that using SOCKS4A may be a better alternative. This warning is based on the fact that applications using SOCKS5 only provide Tor with an IP address, while applications that do DNS resolves themselves may leak information. In response to this, someone questioned the necessity of SOCKS4 and SOCKS4A. They also asked if there would be any issues with having a setting for SOCKS4A in a setup that includes Tor, Privoxy, I2P, and FoxyProxy together while running Bitcoin Core. Wladimir responded by stating that they plan on removing support for SOCKS4 in the next major release for two reasons: it would eliminate unused code paths and improve privacy as SOCKS5 allows DNS redirection. Additionally, SOCKS5 supports IPv6.In a discussion on the Bitcoin-development mailing list, Wladimir proposed removing support for SOCKS4 in the next major release. The reasons given were to remove unused code and enhance privacy by allowing DNS redirection. Another reason was that SOCKS5 supports IPv6. With no objections raised, the removal of SOCKS4 was set to proceed. The email also included a message promoting Bonita BPM Community Edition, an open source business process management suite built on Java and Eclipse.In an email dated June 11, 2014, Wladimir suggested removing support for SOCKS4 from the next major release. The reasons provided were to eliminate untested code paths and improve privacy with the use of SOCKS5, which offers DNS redirection. Additionally, SOCKS5 supports IPv6.In a recent message to the Bitcoin Core mailing list, Wladimir announced plans to remove support for SOCKS4-only proxy in the next major release. This decision was made due to the introduction of SOCKS5 in 1996 and the lack of excuses not to support it. The removal of support for SOCKS4-only proxy will eliminate outdated code paths and enhance privacy as SOCKS5 allows DNS redirection. Wladimir also inquired if anyone is currently using a SOCKS4-only proxy with Bitcoin Core. If no concerns or objections are raised, the removal of support for SOCKS4-only proxy will proceed as planned. It's important to note that this change will only impact users still utilizing SOCKS4-only proxy, while those already using SOCKS5 will not be affected. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_BIP-38-NFC-normalisation-issue.xml b/static/bitcoin-dev/July_2014/combined_BIP-38-NFC-normalisation-issue.xml index e539d86d54..89a951f85c 100644 --- a/static/bitcoin-dev/July_2014/combined_BIP-38-NFC-normalisation-issue.xml +++ b/static/bitcoin-dev/July_2014/combined_BIP-38-NFC-normalisation-issue.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 38 NFC normalisation issue - 2023-08-01T09:44:11.463764+00:00 + 2025-10-11T22:04:19.510908+00:00 + python-feedgen Andreas Schildbach 2014-07-17 11:27:57+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - BIP 38 NFC normalisation issue - 2023-08-01T09:44:11.463764+00:00 + 2025-10-11T22:04:19.511148+00:00 - Java is currently limited to 16 bits per character, while new languages may use 32 or 24 bits per character. This means that Java lacks literals for codepoints, unlike other languages. In Unicode literals, Java expresses UTF-16 encoding, which allows only 16 bits per character. However, it is possible to represent codepoint 0x010400 in UTF-16 encoding by writing "\uD801\uDC00". There has been a bug found in the Java compiler or language regarding null code points. Passphrases that contain control characters are considered invalid, and any character below U+0020 should not be allowed for UI compatibility across multiple platforms.The email messages also contain an advertisement for Black Duck Code Sight, which offers easy access to enterprise code and can search up to 200,000 lines of code. The software powers the world's largest code search on Ohloh, the Black Duck Open Hub. Additionally, there are links to the Bitcoin-development mailing list, which allows users to subscribe or unsubscribe and access archives of past messages.During a discussion about BIP38 implementation, Andreas Schildbach found a problem with the original test case. He updated bitcoinj to fix this issue and proposed a new test vector. There were issues with null characters and other weird issues lurking. Aaron Voisine recommended that instead of removing control characters from passwords, the spec should require that passwords containing control characters are invalid. He also recommended disallowing any character below U+0020 (space) for UI compatibility across multiple platforms. There were concerns about JVM-based wallets not supporting Unicode NFC and therefore suggest limiting the spec to the subset of Unicode that all popular platforms can support. It was suggested to filter ISO control characters to solve the problem.Black Duck is offering a free copy of Code Sight, the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub. With this offer, users can index and search up to 200,000 lines of code in their enterprise. The Black Duck Open Hub is one of the biggest code search engines available and provides users with an easy way to access all the code in their enterprise. Users who want fast and easy access to their code can take advantage of this free offer.The conversation revolves around the implementation of Bitcoinj code for BIP38, a bitcoin improvement proposal. Andreas Schildbach made changes to his implementation of string filtering so that it could handle SMP chars. Aaron Voisine has tested Andreas' implementation and found that it behaves exactly like in his modified testcase. Andreas suggests that they still need to filter control chars and will look into it again. He also provides a fix for bitcoinj and proposes a new test vector. The passphrase contains GREEK UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER LONG I, and PILE OF POO characters. The private key is encoded with this passphrase and produces a BIP38 key. Aaron recommends disallowing any character below U+0020 (space) and invalidating passwords containing control characters. He also offers to submit a PR once they figure out why Andreas's passphrase was different from what he got. Mike Hearn suggests limiting the spec to the subset of unicode that all popular platforms can support because Java uses 16 bit characters internally, which might not support astral planes. Andreas proposes banning/filtering ISO control characters to solve the problem. The conversation ends with a link to Black Duck Code Sight for enterprise code indexing and searching.The email thread discusses a problem in the test case of bitcoinj regarding the encoding of a private key with a given passphrase that contains control characters. Andreas Schildbach had implemented only the decoding side of BIP38 and proposed a test vector for the same. The discussion includes concerns about the accuracy of the test vector, the use of control characters and emoticons in passphrases, and the compatibility of JVM based wallets with Unicode NFC. There is also mention of the Black Duck Code Sight software.The Bitcoin protocol's BIP 38 (password-protected private keys) test vector has been under scrutiny due to a non-standard UTF-8 character (pile of poo) and discrepancies between different implementations. Control characters and whitespaces are generally not recommended in passphrases, but emoticons like pile-of-poo are acceptable as they are easily accessible on mobile keyboards. The NULL character, however, is not included in smartphone keyboards to avoid issues with null-terminated strings. Suggestions include removing the problematic test vector or using a more realistic test string.Bitcoinj recently added an implementation of BIP 38 password-protected private keys. However, there are concerns about the accuracy of the third test vector and its practicality. The NFC normalized version of the input string does not match the results of the Java Unicode normalizer, and different implementations disagree on the outcome. It is proposed to remove the test vector or use a more realistic 2014-07-17T11:27:57+00:00 + Java is currently limited to 16 bits per character, while new languages may use 32 or 24 bits per character. This means that Java lacks literals for codepoints, unlike other languages. In Unicode literals, Java expresses UTF-16 encoding, which allows only 16 bits per character. However, it is possible to represent codepoint 0x010400 in UTF-16 encoding by writing "\uD801\uDC00". There has been a bug found in the Java compiler or language regarding null code points. Passphrases that contain control characters are considered invalid, and any character below U+0020 should not be allowed for UI compatibility across multiple platforms.The email messages also contain an advertisement for Black Duck Code Sight, which offers easy access to enterprise code and can search up to 200,000 lines of code. The software powers the world's largest code search on Ohloh, the Black Duck Open Hub. Additionally, there are links to the Bitcoin-development mailing list, which allows users to subscribe or unsubscribe and access archives of past messages.During a discussion about BIP38 implementation, Andreas Schildbach found a problem with the original test case. He updated bitcoinj to fix this issue and proposed a new test vector. There were issues with null characters and other weird issues lurking. Aaron Voisine recommended that instead of removing control characters from passwords, the spec should require that passwords containing control characters are invalid. He also recommended disallowing any character below U+0020 (space) for UI compatibility across multiple platforms. There were concerns about JVM-based wallets not supporting Unicode NFC and therefore suggest limiting the spec to the subset of Unicode that all popular platforms can support. It was suggested to filter ISO control characters to solve the problem.Black Duck is offering a free copy of Code Sight, the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub. With this offer, users can index and search up to 200,000 lines of code in their enterprise. The Black Duck Open Hub is one of the biggest code search engines available and provides users with an easy way to access all the code in their enterprise. Users who want fast and easy access to their code can take advantage of this free offer.The conversation revolves around the implementation of Bitcoinj code for BIP38, a bitcoin improvement proposal. Andreas Schildbach made changes to his implementation of string filtering so that it could handle SMP chars. Aaron Voisine has tested Andreas' implementation and found that it behaves exactly like in his modified testcase. Andreas suggests that they still need to filter control chars and will look into it again. He also provides a fix for bitcoinj and proposes a new test vector. The passphrase contains GREEK UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER LONG I, and PILE OF POO characters. The private key is encoded with this passphrase and produces a BIP38 key. Aaron recommends disallowing any character below U+0020 (space) and invalidating passwords containing control characters. He also offers to submit a PR once they figure out why Andreas's passphrase was different from what he got. Mike Hearn suggests limiting the spec to the subset of unicode that all popular platforms can support because Java uses 16 bit characters internally, which might not support astral planes. Andreas proposes banning/filtering ISO control characters to solve the problem. The conversation ends with a link to Black Duck Code Sight for enterprise code indexing and searching.The email thread discusses a problem in the test case of bitcoinj regarding the encoding of a private key with a given passphrase that contains control characters. Andreas Schildbach had implemented only the decoding side of BIP38 and proposed a test vector for the same. The discussion includes concerns about the accuracy of the test vector, the use of control characters and emoticons in passphrases, and the compatibility of JVM based wallets with Unicode NFC. There is also mention of the Black Duck Code Sight software.The Bitcoin protocol's BIP 38 (password-protected private keys) test vector has been under scrutiny due to a non-standard UTF-8 character (pile of poo) and discrepancies between different implementations. Control characters and whitespaces are generally not recommended in passphrases, but emoticons like pile-of-poo are acceptable as they are easily accessible on mobile keyboards. The NULL character, however, is not included in smartphone keyboards to avoid issues with null-terminated strings. Suggestions include removing the problematic test vector or using a more realistic test string.Bitcoinj recently added an implementation of BIP 38 password-protected private keys. However, there are concerns about the accuracy of the third test vector and its practicality. The NFC normalized version of the input string does not match the results of the Java Unicode normalizer, and different implementations disagree on the outcome. It is proposed to remove the test vector or use a more realistic - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Bitcoin-Protocol-Specification.xml b/static/bitcoin-dev/July_2014/combined_Bitcoin-Protocol-Specification.xml index 30dc9a24fe..7951f6d8a7 100644 --- a/static/bitcoin-dev/July_2014/combined_Bitcoin-Protocol-Specification.xml +++ b/static/bitcoin-dev/July_2014/combined_Bitcoin-Protocol-Specification.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Protocol Specification - 2023-08-01T09:18:23.533727+00:00 + 2025-10-11T22:04:04.636824+00:00 + python-feedgen sickpig at gmail.com 2014-07-14 20:51:35+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Protocol Specification - 2023-08-01T09:18:23.533727+00:00 + 2025-10-11T22:04:04.637012+00:00 - On July 14, 2014, Mike Hearn raises the question of whether it is possible to create proper protocol specifications for Bitcoin other than the original C++ codebase. The response is affirmative, but with the caveat that previous attempts have failed due to the complexity of Bitcoin. Krzysztof Okupski and Jeff Garzik discuss renaming the document "Bitcoin Developer Specification" to "Bitcoin Developer Reference" and acknowledge its value as a description of the protocol for beginners. However, they also recognize that implementing the protocol based on the document would result in mistakes.Wladimir confirms that the resource in question has already been linked under "Additional Resources" on the developer guide. The conversation ends with a cautionary note to be careful with the usage of the word "specification".Krzysztof Okupski announces that the Bitcoin specification will now be under version control on GitHub. This move aims to increase the number of Bitcoin developers by making the system more understandable. The old link to the PDF version will also be kept updated.Matt Whitlock inquires about a specification document for Satoshi's P2P protocol, specifically how blocks and transactions are communicated over the network. A high-level guide is provided via a link to the developer guide on bitcoin.org, but it is noted that this guide is not a protocol specification. However, the Bitcoin wiki page and a forum thread on bitcointalk.org are suggested as resources for understanding the P2P protocol.Aaron Voisine shares a short description in code comments for breadwallet, and Matt Whitlock asks if anyone is working on a specification document for Satoshi's P2P protocol. Interest in understanding how blocks and transactions are communicated over the network is expressed.Isidor Zeuner shares a link to a PDF document about Bitcoin's design, and JMOlmos GMail asks if there is a translation available. Isidor suggests putting the document source under version control to facilitate tracking future protocol improvements.Krzysztof Okupski receives commendation for his work on a Bitcoin reference document, and the idea of putting the document source under version control is suggested. A request for translation assistance is made, and the email thread is sent to the Bitcoin-development mailing list.Krzysztof Okupski has created a document on Bitcoin's design that is praised as a great reference. The suggestion of putting the document source under version control is made, and Krzysztof thanks Isidor in advance for any further improvement proposals.Krzysztof Okupski posts a revised version of the Bitcoin Protocol Specification that incorporates feedback from Bitcoin Core developers and enthusiasts. He hopes the revised version will be useful to the community and welcomes additional improvement proposals.In May 2014, Krzysztof Okupski requests feedback on a Bitcoin protocol specification he has written. The purpose of the email is to improve the quality of the document and ask for suggestions and error corrections. A link to the front page of the document and contact information are provided.Overall, the context discusses various discussions and exchanges related to creating proper protocol specifications for Bitcoin, particularly the Bitcoin Developer Reference. The challenges and limitations of creating such specifications are highlighted, along with the value of the existing resources available. 2014-07-14T20:51:35+00:00 + On July 14, 2014, Mike Hearn raises the question of whether it is possible to create proper protocol specifications for Bitcoin other than the original C++ codebase. The response is affirmative, but with the caveat that previous attempts have failed due to the complexity of Bitcoin. Krzysztof Okupski and Jeff Garzik discuss renaming the document "Bitcoin Developer Specification" to "Bitcoin Developer Reference" and acknowledge its value as a description of the protocol for beginners. However, they also recognize that implementing the protocol based on the document would result in mistakes.Wladimir confirms that the resource in question has already been linked under "Additional Resources" on the developer guide. The conversation ends with a cautionary note to be careful with the usage of the word "specification".Krzysztof Okupski announces that the Bitcoin specification will now be under version control on GitHub. This move aims to increase the number of Bitcoin developers by making the system more understandable. The old link to the PDF version will also be kept updated.Matt Whitlock inquires about a specification document for Satoshi's P2P protocol, specifically how blocks and transactions are communicated over the network. A high-level guide is provided via a link to the developer guide on bitcoin.org, but it is noted that this guide is not a protocol specification. However, the Bitcoin wiki page and a forum thread on bitcointalk.org are suggested as resources for understanding the P2P protocol.Aaron Voisine shares a short description in code comments for breadwallet, and Matt Whitlock asks if anyone is working on a specification document for Satoshi's P2P protocol. Interest in understanding how blocks and transactions are communicated over the network is expressed.Isidor Zeuner shares a link to a PDF document about Bitcoin's design, and JMOlmos GMail asks if there is a translation available. Isidor suggests putting the document source under version control to facilitate tracking future protocol improvements.Krzysztof Okupski receives commendation for his work on a Bitcoin reference document, and the idea of putting the document source under version control is suggested. A request for translation assistance is made, and the email thread is sent to the Bitcoin-development mailing list.Krzysztof Okupski has created a document on Bitcoin's design that is praised as a great reference. The suggestion of putting the document source under version control is made, and Krzysztof thanks Isidor in advance for any further improvement proposals.Krzysztof Okupski posts a revised version of the Bitcoin Protocol Specification that incorporates feedback from Bitcoin Core developers and enthusiasts. He hopes the revised version will be useful to the community and welcomes additional improvement proposals.In May 2014, Krzysztof Okupski requests feedback on a Bitcoin protocol specification he has written. The purpose of the email is to improve the quality of the document and ask for suggestions and error corrections. A link to the front page of the document and contact information are provided.Overall, the context discusses various discussions and exchanges related to creating proper protocol specifications for Bitcoin, particularly the Bitcoin Developer Reference. The challenges and limitations of creating such specifications are highlighted, along with the value of the existing resources available. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Bitcoin-address-TTL-key-expiration-.xml b/static/bitcoin-dev/July_2014/combined_Bitcoin-address-TTL-key-expiration-.xml index f2b5f25d59..09fcbcbad2 100644 --- a/static/bitcoin-dev/July_2014/combined_Bitcoin-address-TTL-key-expiration-.xml +++ b/static/bitcoin-dev/July_2014/combined_Bitcoin-address-TTL-key-expiration-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin address TTL & key expiration? - 2023-08-01T09:42:22.329146+00:00 + 2025-10-11T22:04:47.135035+00:00 + python-feedgen Mike Hearn 2014-07-15 16:26:15+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Bitcoin address TTL & key expiration? - 2023-08-01T09:42:22.329146+00:00 + 2025-10-11T22:04:47.135212+00:00 - There are discussions among Bitcoin core developers regarding the limitations and insufficiency of the payment protocol in certain scenarios such as on-going payment streams and deposit addresses. While the payment protocol satisfies some use cases, there is a need to address situations where it is not feasible or suboptimal. Jeff Garzik suggests that deposits can use unique payment requests or addresses every time, especially when HD wallet details have been negotiated.There is a disagreement regarding transactions using the same Bitcoin address more than once. Luke Dashjr points out that wallets and services can already ignore such transactions, but Jeff Garzik argues that few users would appreciate their deposits being ignored. He also highlights that the payment protocol does not cover certain use cases such as on-going payment streams and deposit situations.The idea of limiting the lifetime of a Bitcoin address is suggested by Jeff Garzik. This would prevent bitcoins from being sent to an expired address. The best insertion point in the protocol for key expiration is still being discussed. Garzik believes that preventing accidental sending to an expired address, discouraging address reuse, and enabling sites to rotate ancient keys off their core systems are valuable features. However, it is noted that making transactions invalid based on specific scriptPubKey could potentially invalidate a chain of transactions during a reorg.There are also discussions about the possibility of Payment Protocol being used as the communication format for new metadata on the blockchain. This protocol aims to address scalability and efficiency challenges by providing a standardized set of messages for data exchange. While there are challenges that need to be addressed before its implementation, initiatives are already underway to make it happen.In conclusion, the discussions among Bitcoin core developers revolve around the limitations of the payment protocol, the need to address specific use cases, and the potential implementation of Payment Protocol for data communication on the blockchain. Ideas such as using unique payment requests or addresses, limiting the lifetime of Bitcoin addresses, and adopting Payment Protocol are being considered to improve the functionality and adoption of Bitcoin technology. 2014-07-15T16:26:15+00:00 + There are discussions among Bitcoin core developers regarding the limitations and insufficiency of the payment protocol in certain scenarios such as on-going payment streams and deposit addresses. While the payment protocol satisfies some use cases, there is a need to address situations where it is not feasible or suboptimal. Jeff Garzik suggests that deposits can use unique payment requests or addresses every time, especially when HD wallet details have been negotiated.There is a disagreement regarding transactions using the same Bitcoin address more than once. Luke Dashjr points out that wallets and services can already ignore such transactions, but Jeff Garzik argues that few users would appreciate their deposits being ignored. He also highlights that the payment protocol does not cover certain use cases such as on-going payment streams and deposit situations.The idea of limiting the lifetime of a Bitcoin address is suggested by Jeff Garzik. This would prevent bitcoins from being sent to an expired address. The best insertion point in the protocol for key expiration is still being discussed. Garzik believes that preventing accidental sending to an expired address, discouraging address reuse, and enabling sites to rotate ancient keys off their core systems are valuable features. However, it is noted that making transactions invalid based on specific scriptPubKey could potentially invalidate a chain of transactions during a reorg.There are also discussions about the possibility of Payment Protocol being used as the communication format for new metadata on the blockchain. This protocol aims to address scalability and efficiency challenges by providing a standardized set of messages for data exchange. While there are challenges that need to be addressed before its implementation, initiatives are already underway to make it happen.In conclusion, the discussions among Bitcoin core developers revolve around the limitations of the payment protocol, the need to address specific use cases, and the potential implementation of Payment Protocol for data communication on the blockchain. Ideas such as using unique payment requests or addresses, limiting the lifetime of Bitcoin addresses, and adopting Payment Protocol are being considered to improve the functionality and adoption of Bitcoin technology. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Bitcoin-development-testing-where-to-get-Wallet-code-.xml b/static/bitcoin-dev/July_2014/combined_Bitcoin-development-testing-where-to-get-Wallet-code-.xml index b9aaf721be..92e4d47094 100644 --- a/static/bitcoin-dev/July_2014/combined_Bitcoin-development-testing-where-to-get-Wallet-code-.xml +++ b/static/bitcoin-dev/July_2014/combined_Bitcoin-development-testing-where-to-get-Wallet-code-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin development (testing & where to get Wallet code) - 2023-08-01T10:07:58.778270+00:00 + 2025-10-11T22:04:38.628047+00:00 + python-feedgen Wladimir 2014-07-30 08:37:07+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Bitcoin development (testing & where to get Wallet code) - 2023-08-01T10:07:58.778270+00:00 + 2025-10-11T22:04:38.628208+00:00 - A developer named Caleb Roger Davis has expressed his desire to contribute to the Bitcoin community for learning purposes. He wants to contribute to unit and/or other types of tests (code), not production code. The low-level unit tests are in `src/test`, while high-level RPC tests are in `qa/rpc-tests`. There is also a java-based 'comparison tool' that tests high-level behavior with regard to the block chain. All of the wallet code is in `src/wallet.cpp` and `src/walletdb.cpp`.If the purpose is just studying, the bitcoin core wallet is not the most readable wallet code around. If Caleb wants to write a Bitcoin wallet in another language, it's better to look at SPV wallets, for example, the bitcoinj-based ones.Caleb wants to understand the Bitcoin code as much as possible from top to bottom, and for this, he can refer to https://www.bitcoin.org/en/developer-guide. He is also interested in finding the tools and frameworks he would need to understand and initially work on tests, how to run the existing tests to get code coverage and find where coverage is needed, what is the preferred IDE and full development stack, etc.If he wants to work on Bitcoin Core, a Linux box (or VM) is the best development environment. Wladimir suggests that getting started building on Windows or Mac is harder (but possible), and there is work in progress to make building the dependencies easier for those.Bitcoinj is a Java-based library that provides everything to plug together a basic SPV wallet and runs in the JVM.On 29/07/2014, Caleb Roger Davis expressed his interest in contributing to Bitcoin for learning purposes. He wanted to contribute to unit and/or other types of tests (code), not production code, understand the Bitcoin code (as much as possible from top to bottom), and write a Bitcoin wallet in another language. Caleb was interested in Clojure, a modern dialect of Lisp, and Felipe Micaroni Lalli suggested implementing Bitcoin in Clojure or Scheme. The discussion also included links to stack exchange and PGP ID, and Caleb requested direction on where to get started.The conversation between Caleb and Felipe Micaroni Lalli revolved around Bitcoin development. Caleb expressed his interest in contributing to Bitcoin development for learning purposes and asked for guidance on where to get started. He mentioned that he wanted to contribute to unit and other types of tests, understand the Bitcoin code, and write a Bitcoin wallet in another language. Felipe was also interested in implementing Bitcoin in Clojure or Scheme and shared a link to a related question on bitcoin.stackexchange.com. Caleb did not confirm whether he wanted to tackle writing Bitcoin in Clojure, but said that he wanted to create a toolkit first to learn more about how it works. The conversation ended with Caleb sharing his contact information.The email conversation is about a seasoned software developer who wants to contribute to Bitcoin for learning purposes. He wants to work on unit and/or other types of tests and understand the Bitcoin code from top to bottom. Additionally, he wants to write a Bitcoin wallet in another language. The developer needs direction on where to get started and tools and frameworks he would need to work on tests and look at the Bitcoin core and wallet code. He also wants to know if there is a separate area for core wallet development on Github and mailing lists. On a related note, Felipe Micaroni Lalli, Bitcoin Paranoid Android developer, expresses his interest in implementing Bitcoin in Clojure or Scheme and shares his PGP ID and BTC address. Caleb Roger Davis responds to the email with questions and requests for information.The writer, a seasoned software developer, seeks guidance on how to contribute to Bitcoin for learning purposes. They express interest in contributing to unit tests and understanding the Bitcoin code from top to bottom. Additionally, they would like to write a Bitcoin wallet in another language but are unsure where to get the "Bitcoin - Core Wallet" code. The writer requests information on the tools and frameworks needed to work on tests and preferred IDE and full development stack, as well as guidance on where to start looking at the Bitcoin core code and the wallet code. They inquire about whether there is a separate area for core wallet development on Github and mailing lists. The writer hopes that there is a wiki doc for new developers that would reduce their searching and experimentation time. 2014-07-30T08:37:07+00:00 + A developer named Caleb Roger Davis has expressed his desire to contribute to the Bitcoin community for learning purposes. He wants to contribute to unit and/or other types of tests (code), not production code. The low-level unit tests are in `src/test`, while high-level RPC tests are in `qa/rpc-tests`. There is also a java-based 'comparison tool' that tests high-level behavior with regard to the block chain. All of the wallet code is in `src/wallet.cpp` and `src/walletdb.cpp`.If the purpose is just studying, the bitcoin core wallet is not the most readable wallet code around. If Caleb wants to write a Bitcoin wallet in another language, it's better to look at SPV wallets, for example, the bitcoinj-based ones.Caleb wants to understand the Bitcoin code as much as possible from top to bottom, and for this, he can refer to https://www.bitcoin.org/en/developer-guide. He is also interested in finding the tools and frameworks he would need to understand and initially work on tests, how to run the existing tests to get code coverage and find where coverage is needed, what is the preferred IDE and full development stack, etc.If he wants to work on Bitcoin Core, a Linux box (or VM) is the best development environment. Wladimir suggests that getting started building on Windows or Mac is harder (but possible), and there is work in progress to make building the dependencies easier for those.Bitcoinj is a Java-based library that provides everything to plug together a basic SPV wallet and runs in the JVM.On 29/07/2014, Caleb Roger Davis expressed his interest in contributing to Bitcoin for learning purposes. He wanted to contribute to unit and/or other types of tests (code), not production code, understand the Bitcoin code (as much as possible from top to bottom), and write a Bitcoin wallet in another language. Caleb was interested in Clojure, a modern dialect of Lisp, and Felipe Micaroni Lalli suggested implementing Bitcoin in Clojure or Scheme. The discussion also included links to stack exchange and PGP ID, and Caleb requested direction on where to get started.The conversation between Caleb and Felipe Micaroni Lalli revolved around Bitcoin development. Caleb expressed his interest in contributing to Bitcoin development for learning purposes and asked for guidance on where to get started. He mentioned that he wanted to contribute to unit and other types of tests, understand the Bitcoin code, and write a Bitcoin wallet in another language. Felipe was also interested in implementing Bitcoin in Clojure or Scheme and shared a link to a related question on bitcoin.stackexchange.com. Caleb did not confirm whether he wanted to tackle writing Bitcoin in Clojure, but said that he wanted to create a toolkit first to learn more about how it works. The conversation ended with Caleb sharing his contact information.The email conversation is about a seasoned software developer who wants to contribute to Bitcoin for learning purposes. He wants to work on unit and/or other types of tests and understand the Bitcoin code from top to bottom. Additionally, he wants to write a Bitcoin wallet in another language. The developer needs direction on where to get started and tools and frameworks he would need to work on tests and look at the Bitcoin core and wallet code. He also wants to know if there is a separate area for core wallet development on Github and mailing lists. On a related note, Felipe Micaroni Lalli, Bitcoin Paranoid Android developer, expresses his interest in implementing Bitcoin in Clojure or Scheme and shares his PGP ID and BTC address. Caleb Roger Davis responds to the email with questions and requests for information.The writer, a seasoned software developer, seeks guidance on how to contribute to Bitcoin for learning purposes. They express interest in contributing to unit tests and understanding the Bitcoin code from top to bottom. Additionally, they would like to write a Bitcoin wallet in another language but are unsure where to get the "Bitcoin - Core Wallet" code. The writer requests information on the tools and frameworks needed to work on tests and preferred IDE and full development stack, as well as guidance on where to start looking at the Bitcoin core code and the wallet code. They inquire about whether there is a separate area for core wallet development on Github and mailing lists. The writer hopes that there is a wiki doc for new developers that would reduce their searching and experimentation time. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Building-BDB-on-MingW.xml b/static/bitcoin-dev/July_2014/combined_Building-BDB-on-MingW.xml index c5c7e16cae..046d8241fa 100644 --- a/static/bitcoin-dev/July_2014/combined_Building-BDB-on-MingW.xml +++ b/static/bitcoin-dev/July_2014/combined_Building-BDB-on-MingW.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Building BDB on MingW - 2023-08-01T03:19:20.624581+00:00 + 2025-10-11T22:04:49.262635+00:00 + python-feedgen neil 2014-07-14 11:27:15+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Building BDB on MingW - 2023-08-01T03:19:20.624581+00:00 + 2025-10-11T22:04:49.262787+00:00 - Based on the given context, it appears that the sender is seeking assistance in resolving an error they encountered while building Berkeley DB (BDB) on MingW. The recipient provided a link to an Oracle forum thread that suggests a solution for the issue. However, the sender followed the instructions from build-msw.txt but still faced the same problem mentioned in a Bitcointalk thread. They were able to compile it using specific flags, but when running bitcoind, it threw a DbRunRecoveryException over the DB_RUNRECOVERY flag.It seems that many people do not use MingW to compile bitcoind on Windows due to the lack of pthreads and missing functions such as strncasecmp, _strlwr, _fileno, and swprintf. Amir Taaki reached out to Wladimir for help with the issue he faced while following the build-msw.txt instructions. Amir shared a link to a Bitcointalk forum post that described his issue, but the proposed fix in that thread did not work for him. Unfortunately, the specific issue or whether Wladimir was able to provide assistance is unclear. The user encountered an issue while following the instructions in build-msw.txt to install a program. They provided a link to a forum where someone else had a similar issue. In their post, the user included their input commands and the error message they received. The error message indicates that there are two or more data types in declaration specifiers, causing the make command to fail. However, the proposed fix in the forum thread did not work for the user. 2014-07-14T11:27:15+00:00 + Based on the given context, it appears that the sender is seeking assistance in resolving an error they encountered while building Berkeley DB (BDB) on MingW. The recipient provided a link to an Oracle forum thread that suggests a solution for the issue. However, the sender followed the instructions from build-msw.txt but still faced the same problem mentioned in a Bitcointalk thread. They were able to compile it using specific flags, but when running bitcoind, it threw a DbRunRecoveryException over the DB_RUNRECOVERY flag.It seems that many people do not use MingW to compile bitcoind on Windows due to the lack of pthreads and missing functions such as strncasecmp, _strlwr, _fileno, and swprintf. Amir Taaki reached out to Wladimir for help with the issue he faced while following the build-msw.txt instructions. Amir shared a link to a Bitcointalk forum post that described his issue, but the proposed fix in that thread did not work for him. Unfortunately, the specific issue or whether Wladimir was able to provide assistance is unclear. The user encountered an issue while following the instructions in build-msw.txt to install a program. They provided a link to a forum where someone else had a similar issue. In their post, the user included their input commands and the error message they received. The error message indicates that there are two or more data types in declaration specifiers, causing the make command to fail. However, the proposed fix in the forum thread did not work for the user. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Building-from-git-on-OSX.xml b/static/bitcoin-dev/July_2014/combined_Building-from-git-on-OSX.xml index b39ca7091c..95b490d5c7 100644 --- a/static/bitcoin-dev/July_2014/combined_Building-from-git-on-OSX.xml +++ b/static/bitcoin-dev/July_2014/combined_Building-from-git-on-OSX.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Building from git on OSX - 2023-08-01T09:40:02.757142+00:00 + 2025-10-11T22:04:13.131024+00:00 + python-feedgen Angel Leon 2014-07-03 16:21:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Building from git on OSX - 2023-08-01T09:40:02.757142+00:00 + 2025-10-11T22:04:13.131164+00:00 - In a message sent on the Bitcoin-development mailing list, Gavin Andresen addressed the issue of a new dependency called libtool for those building on OSX. To resolve this problem, he recommended using either 'brew install libtool' or 'port install libtool' and directed users to refer to doc/build-osx.md for a complete list of dependencies.Specifically for development purposes, Gavin shared his own configuration options. If encountering difficulties with the libtool dependency after updating to git HEAD, he advised installing it via homebrew (brew install libtool) or port (port install libtool). The comprehensive list of dependencies can be found in doc/build-osx.md.Once libtool is installed, users should run ./autogen.sh and configure with their preferred options. Gavin provided his own configuration as an example: "./configure --disable-hardening --disable-silent-rules CXXFLAGS='-g3 -O0 -DDEBUG_LOCKORDER'". 2014-07-03T16:21:50+00:00 + In a message sent on the Bitcoin-development mailing list, Gavin Andresen addressed the issue of a new dependency called libtool for those building on OSX. To resolve this problem, he recommended using either 'brew install libtool' or 'port install libtool' and directed users to refer to doc/build-osx.md for a complete list of dependencies.Specifically for development purposes, Gavin shared his own configuration options. If encountering difficulties with the libtool dependency after updating to git HEAD, he advised installing it via homebrew (brew install libtool) or port (port install libtool). The comprehensive list of dependencies can be found in doc/build-osx.md.Once libtool is installed, users should run ./autogen.sh and configure with their preferred options. Gavin provided his own configuration as an example: "./configure --disable-hardening --disable-silent-rules CXXFLAGS='-g3 -O0 -DDEBUG_LOCKORDER'". - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Decentralizing-ming.xml b/static/bitcoin-dev/July_2014/combined_Decentralizing-ming.xml index 1e45d3751e..4f782758cd 100644 --- a/static/bitcoin-dev/July_2014/combined_Decentralizing-ming.xml +++ b/static/bitcoin-dev/July_2014/combined_Decentralizing-ming.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Decentralizing ming - 2023-08-01T09:45:39.288703+00:00 + 2025-10-11T22:04:32.257825+00:00 + python-feedgen Emin Gün Sirer 2014-07-19 00:54:36+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Decentralizing ming - 2023-08-01T09:45:39.288703+00:00 + 2025-10-11T22:04:32.258041+00:00 - In an email thread on the Bitcoin-development mailing list, the problem of set reconciliation is discussed. The goal is to reduce communication complexity between peers who have different sets of transactions in a block. A paper from Cornell proposes a scheme for achieving this through an underlying technique from the peer-to-peer/gossip literature. This approach has advantages over Bloom filters, including smaller packet sizes, non-probabilistic and non-interactive nature, and avoidance of hash collision complications. The idea is suggested to be applied to the Bitcoin p2p protocol to reduce packet size.The email thread also discusses the concept of democratizing transaction selection. Jeff Garzik suggests propagating blocks without re-propagating all transactions everyone already has, which would address the issue of large blocks being slower to relay. This would also give power back to the network at large and reduce the control of miners. Mike Hearn agrees with this suggestion and proposes finishing off getblocktemplate support in various tools to enable pooling for payout purposes without giving up control of block creation.In a conversation between Jeff Garzik and slush, it is mentioned that Satoshi Nakamoto appeared to be displeased with the early emergence of GPU mining pools. However, it is noted that Satoshi had left the project before mining pools gained traction. This historical note provides insight into Satoshi's views on GPU mining and its impact on the distribution of coins.Another message in the email thread apologizes for replying to the wrong subject line and suggests that finishing off getblocktemplate support is the best path forward for pooling without giving up control of block creation. Mike Hearn responds to Jeff's message about GPU mining and mentions Satoshi's desire for a gentlemen's agreement to postpone GPU mining as long as possible to ensure an even distribution of coins.A historical note by Jeff Garzik highlights Satoshi's dislike for the early emergence of GPU mining pools. It is mentioned that Satoshi left the project before mining pools gained traction. The email provides insight into the early days of cryptocurrency mining and attitudes towards emerging technologies within the community.In the context provided, the author discusses the concept of "acceptable" in regards to Bitcoin mining. There is disagreement on whether a 40% solution is a good idea, but the author believes it is a positive step. The more critical issue is developing technical solutions for decentralized transaction selection and SPOF-proofing mining. A historical note is provided on Satoshi's views on GPU mining pools and the potential concentration of power among a few big players. The need for technical solutions to keep Bitcoin free and open is emphasized, and various proposals are being discussed to make transaction selection more independent from hashpower. 2014-07-19T00:54:36+00:00 + In an email thread on the Bitcoin-development mailing list, the problem of set reconciliation is discussed. The goal is to reduce communication complexity between peers who have different sets of transactions in a block. A paper from Cornell proposes a scheme for achieving this through an underlying technique from the peer-to-peer/gossip literature. This approach has advantages over Bloom filters, including smaller packet sizes, non-probabilistic and non-interactive nature, and avoidance of hash collision complications. The idea is suggested to be applied to the Bitcoin p2p protocol to reduce packet size.The email thread also discusses the concept of democratizing transaction selection. Jeff Garzik suggests propagating blocks without re-propagating all transactions everyone already has, which would address the issue of large blocks being slower to relay. This would also give power back to the network at large and reduce the control of miners. Mike Hearn agrees with this suggestion and proposes finishing off getblocktemplate support in various tools to enable pooling for payout purposes without giving up control of block creation.In a conversation between Jeff Garzik and slush, it is mentioned that Satoshi Nakamoto appeared to be displeased with the early emergence of GPU mining pools. However, it is noted that Satoshi had left the project before mining pools gained traction. This historical note provides insight into Satoshi's views on GPU mining and its impact on the distribution of coins.Another message in the email thread apologizes for replying to the wrong subject line and suggests that finishing off getblocktemplate support is the best path forward for pooling without giving up control of block creation. Mike Hearn responds to Jeff's message about GPU mining and mentions Satoshi's desire for a gentlemen's agreement to postpone GPU mining as long as possible to ensure an even distribution of coins.A historical note by Jeff Garzik highlights Satoshi's dislike for the early emergence of GPU mining pools. It is mentioned that Satoshi left the project before mining pools gained traction. The email provides insight into the early days of cryptocurrency mining and attitudes towards emerging technologies within the community.In the context provided, the author discusses the concept of "acceptable" in regards to Bitcoin mining. There is disagreement on whether a 40% solution is a good idea, but the author believes it is a positive step. The more critical issue is developing technical solutions for decentralized transaction selection and SPOF-proofing mining. A historical note is provided on Satoshi's views on GPU mining pools and the potential concentration of power among a few big players. The need for technical solutions to keep Bitcoin free and open is emphasized, and various proposals are being discussed to make transaction selection more independent from hashpower. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Draft-BIP-for-geutxos-message.xml b/static/bitcoin-dev/July_2014/combined_Draft-BIP-for-geutxos-message.xml index 4903892f19..3c56aba50d 100644 --- a/static/bitcoin-dev/July_2014/combined_Draft-BIP-for-geutxos-message.xml +++ b/static/bitcoin-dev/July_2014/combined_Draft-BIP-for-geutxos-message.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP for geutxos message - 2023-08-01T09:41:41.906579+00:00 + 2025-10-11T22:04:25.886010+00:00 + python-feedgen Mike Hearn 2014-07-16 15:01:20+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for geutxos message - 2023-08-01T09:41:41.906579+00:00 + 2025-10-11T22:04:25.886179+00:00 - The conversation revolves around the Bitcoin Improvement Proposal (BIP) for querying multiple nodes and combining their answers. The proposal suggests this as a partial solution, but there are concerns raised about its security. Jeff Garzik highlights the lack of discussion on this choice in the BIP and proposes adding a warning label and documenting the weaknesses in the security considerations section. The respondent agrees to make changes and offers to send a diff with proposed modifications.In another discussion, Jeff Garzik expresses concerns about the security of querying multiple nodes and combining their answers, suggesting that it should only be used as a last resort. Mike Hearn responds by pointing out that the writeup attached to the implementation pull request covers how to secure the proposal, but acknowledges the need for improvement. There is mention of comparing this proposal to BIP 35, but it is argued that they are not comparable. The writer agrees to fix any misleading parts of the BIP.The conversation also touches on the draft BIP for 'getutxo' proposed by Mike Hearn. It mentions the usefulness of querying UTXOs and the security issue of an untrusted view. The BIP describes two new messages, 'getutxos' and 'utxos', and defines their fields. The protocol has a similar security model to Bloom filtering but lacks authentication. The writer suggests including a method to solve this security issue in the BIP.The pull request for the draft BIP for getutxo is discussed, emphasizing the purpose of performing UTXO lookups. Two new messages, 'getutxos' and 'utxos', are defined, and support can be indicated through protocol version and NODE_GETUTXO flag settings.In summary, the conversation involves discussions about the security concerns and proposed changes for the BIP on querying multiple nodes and combining their answers. It also covers the draft BIP for getutxo, highlighting its purpose and the need for addressing security issues. 2014-07-16T15:01:20+00:00 + The conversation revolves around the Bitcoin Improvement Proposal (BIP) for querying multiple nodes and combining their answers. The proposal suggests this as a partial solution, but there are concerns raised about its security. Jeff Garzik highlights the lack of discussion on this choice in the BIP and proposes adding a warning label and documenting the weaknesses in the security considerations section. The respondent agrees to make changes and offers to send a diff with proposed modifications.In another discussion, Jeff Garzik expresses concerns about the security of querying multiple nodes and combining their answers, suggesting that it should only be used as a last resort. Mike Hearn responds by pointing out that the writeup attached to the implementation pull request covers how to secure the proposal, but acknowledges the need for improvement. There is mention of comparing this proposal to BIP 35, but it is argued that they are not comparable. The writer agrees to fix any misleading parts of the BIP.The conversation also touches on the draft BIP for 'getutxo' proposed by Mike Hearn. It mentions the usefulness of querying UTXOs and the security issue of an untrusted view. The BIP describes two new messages, 'getutxos' and 'utxos', and defines their fields. The protocol has a similar security model to Bloom filtering but lacks authentication. The writer suggests including a method to solve this security issue in the BIP.The pull request for the draft BIP for getutxo is discussed, emphasizing the purpose of performing UTXO lookups. Two new messages, 'getutxos' and 'utxos', are defined, and support can be indicated through protocol version and NODE_GETUTXO flag settings.In summary, the conversation involves discussions about the security concerns and proposed changes for the BIP on querying multiple nodes and combining their answers. It also covers the draft BIP for getutxo, highlighting its purpose and the need for addressing security issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Mining-Hashrate-Caps.xml b/static/bitcoin-dev/July_2014/combined_Mining-Hashrate-Caps.xml index 23b81918e9..d1b9cbb94c 100644 --- a/static/bitcoin-dev/July_2014/combined_Mining-Hashrate-Caps.xml +++ b/static/bitcoin-dev/July_2014/combined_Mining-Hashrate-Caps.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mining Hashrate Caps - 2023-08-01T09:45:16.086685+00:00 + 2025-10-11T22:04:44.998732+00:00 + python-feedgen David A. Harding 2014-07-17 15:45:06+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Mining Hashrate Caps - 2023-08-01T09:45:16.086685+00:00 + 2025-10-11T22:04:44.998861+00:00 - GHash, one of the largest bitcoin mining pools, has made a significant commitment to address concerns over its increasing control of the network. At the Bitcoin Mining Summit, GHash announced a 40% hashrate cap, aiming to prevent the pool from gaining a majority share and potentially double-spending bitcoins. This move is seen as a step towards promoting a more decentralized mining ecosystem, which is crucial for maintaining trust in the bitcoin system.The decision by GHash comes at a time when discussions about the risks of a single entity having too much control over the network are taking place. One concern raised is the possibility of double-spending, where someone could spend the same bitcoins twice, undermining the integrity of the system. By committing to a 40% hashrate cap, GHash aims to mitigate these risks and ensure a more balanced distribution of power among mining participants.Interestingly, this news coincides with a quote from Satoshi Nakamoto, the mysterious creator of bitcoin. Nakamoto had suggested a "gentleman's agreement" to delay the GPU arms race in mining, in order to encourage wider participation and prevent monopolization of the network. While this sentiment may be considered outdated now, it reflects the ongoing tension between the desire for decentralization and the pursuit of profit and efficiency in the mining industry.These recent developments highlight the importance of continuously addressing concerns related to centralization in the bitcoin network. The commitment by GHash is a positive step towards creating a more inclusive and secure mining environment. It also demonstrates the industry's recognition of the need to balance profitability with the long-term sustainability and integrity of the bitcoin system.To further delve into the discussion surrounding these issues, Mark Friedenbach initiated a conversation on the Bitcoin-documentation mailing list. He sought an explanation as to why a 50% chance of successfully double-spending a six-confirm transaction is still considered unacceptable. David A. Harding responded, mentioning that they were working on addressing this issue for the Bitcoin.org website and provided a link to a preview of the relevant section. The thread containing the discussion was also shared, directing interested parties to join the conversation.In addition to these discussions, Melvin Carvalho shared an article on the Bitcoin-development mailing list, shedding light on GHash's commitment to the hashrate cap. The email concluded with a promotion for Black Duck Code Sight, a software that indexes and searches code lines. While unrelated to the main topic, it is worth noting as it provides information about a tool that developers may find useful in their work.Overall, the commitment by GHash to limit its hashrate and the ongoing discussions within the bitcoin community reflect the collective effort to address concerns related to centralization in mining. These developments serve as reminders of the delicate balance between decentralization and profit-driven motives in the pursuit of a secure and sustainable bitcoin network. 2014-07-17T15:45:06+00:00 + GHash, one of the largest bitcoin mining pools, has made a significant commitment to address concerns over its increasing control of the network. At the Bitcoin Mining Summit, GHash announced a 40% hashrate cap, aiming to prevent the pool from gaining a majority share and potentially double-spending bitcoins. This move is seen as a step towards promoting a more decentralized mining ecosystem, which is crucial for maintaining trust in the bitcoin system.The decision by GHash comes at a time when discussions about the risks of a single entity having too much control over the network are taking place. One concern raised is the possibility of double-spending, where someone could spend the same bitcoins twice, undermining the integrity of the system. By committing to a 40% hashrate cap, GHash aims to mitigate these risks and ensure a more balanced distribution of power among mining participants.Interestingly, this news coincides with a quote from Satoshi Nakamoto, the mysterious creator of bitcoin. Nakamoto had suggested a "gentleman's agreement" to delay the GPU arms race in mining, in order to encourage wider participation and prevent monopolization of the network. While this sentiment may be considered outdated now, it reflects the ongoing tension between the desire for decentralization and the pursuit of profit and efficiency in the mining industry.These recent developments highlight the importance of continuously addressing concerns related to centralization in the bitcoin network. The commitment by GHash is a positive step towards creating a more inclusive and secure mining environment. It also demonstrates the industry's recognition of the need to balance profitability with the long-term sustainability and integrity of the bitcoin system.To further delve into the discussion surrounding these issues, Mark Friedenbach initiated a conversation on the Bitcoin-documentation mailing list. He sought an explanation as to why a 50% chance of successfully double-spending a six-confirm transaction is still considered unacceptable. David A. Harding responded, mentioning that they were working on addressing this issue for the Bitcoin.org website and provided a link to a preview of the relevant section. The thread containing the discussion was also shared, directing interested parties to join the conversation.In addition to these discussions, Melvin Carvalho shared an article on the Bitcoin-development mailing list, shedding light on GHash's commitment to the hashrate cap. The email concluded with a promotion for Black Duck Code Sight, a software that indexes and searches code lines. While unrelated to the main topic, it is worth noting as it provides information about a tool that developers may find useful in their work.Overall, the commitment by GHash to limit its hashrate and the ongoing discussions within the bitcoin community reflect the collective effort to address concerns related to centralization in mining. These developments serve as reminders of the delicate balance between decentralization and profit-driven motives in the pursuit of a secure and sustainable bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Pay-to-MultiScript-hash-.xml b/static/bitcoin-dev/July_2014/combined_Pay-to-MultiScript-hash-.xml index d9fd4a644b..1ae1ffd70c 100644 --- a/static/bitcoin-dev/July_2014/combined_Pay-to-MultiScript-hash-.xml +++ b/static/bitcoin-dev/July_2014/combined_Pay-to-MultiScript-hash-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Pay to MultiScript hash: - 2023-08-01T09:44:52.250059+00:00 + 2025-10-11T22:04:34.381600+00:00 + python-feedgen Gregory Maxwell 2014-07-17 20:08:24+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Pay to MultiScript hash: - 2023-08-01T09:44:52.250059+00:00 + 2025-10-11T22:04:34.381774+00:00 - Jeremy has proposed a new transaction type that matches on script hashes similar to pay to script hash, but checks for one of N scripts. However, this idea is considered less flexible and efficient compared to the Merkelized Abstract Syntax Tree construction. The proposed idea was previously discussed by Tier Nolan in the "Selector Script" thread.The discussion revolves around the costs associated with implementing a new transaction type in Bitcoin's network. The proposed method is compared to P2SH, which is already analyzed by developers and working. The cost of updating everyone to relay this new transaction type is also considered, along with the cost of increasing the rate of UTXO growth versus P2SH and the implications of "default public" versus P2SH's "default private". In terms of space efficiency, publishing the script in the txout allows for easy auditing by third parties scanning the blockchain. However, this can also be accomplished by offering the script upon request out-of-band. The idea of creating a "cookbook" of useful scripts is presented.The proposal suggests doing a p2sh with a switch statement that allows selecting one of n scripts each 520 bytes long without bloating the utxo pool more than a p2sh. This could result in long-term space savings on disk for regular p2sh. Adding a "function-hash-pointer jump table / switch statement" could also save space and allow for more complicated scripts to be built.Considerations for a system like Bitcoin include the cost of upgrades and network-wide changes compared to already analyzed and working P2SH, as well as the predictability of P2SH outputs versus less predictable outputs. Updating everyone to relay new transaction types and increasing the rate of UTXO growth also add to the cost. Publishing the script in the txout allows for easy auditing, but it can also be done through out-of-band offering. The script is hash-sealed by the P2SH address, enabling perfect proof. A "cookbook" of useful scripts would help explore the power of Bitcoin scripts.A proposed method is simpler with fewer bytes for control flow, but additional costs would be in terms of chance of user error/application error, extra bytes for control flow, larger script size if scriptSig script has to store the logic for all potential permission groups, hidden-till-spent permission groups, and larger blockchain bloat overall. Blockchain analysis can actively monitor the utxo pool for known associated scripts, whereas specialty scripts assembled per group cannot. A SAT scripting language with an eval or something similar can also be added. Using a normal P2SH output with OP_IF and friends seems more straightforward when considering the costs of increased UTXO pool bloat and transaction complexity. Boolean logic with multisig groups is quite possible, and there is definitely a valid use case called "multi-multisig".The proposed method of using a 20-byte hash to represent a permission group incurs additional costs in terms of chance of user error/application error and extra bytes for control flow. However, this method allows for hidden-till-spent permission groups, reduces blockchain bloat, and enables repeated spends with groups without recalling all participants. The author suggests pushing the sigs onto the stack and having implicit orders, then doing expressions with their aliases, and being able to assign "spending groups" using a SAT scripting language with an eval. Doing boolean logic with multisig groups is quite possible, referred to as "multi-multisig".In an email conversation, Jeremy proposed a solution to express multiple ways that would incur additional costs in terms of complicated control flows. He suggested using a normal P2SH output and a script with OP_IF and friends, which seems more straightforward. However, there is an implication in terms of increased UTXO pool bloat and increased transaction complexity. Each 20-byte hash allows for a 500-byte script, and only one of the 500 byte scripts has to be permanently stored on the blockchain. Jeremy also mentioned that doing boolean logic with multisig groups is quite possible and considered it a valid use case called "multi-multisig".Jeremy Rubin proposed a new transaction type that matches on script hashes similar to pay to script hash but checks for one of N scripts. The motivation behind this idea is to create "permission groups" where multiple groups can spend a UTXO. Currently, expressing this would require additional costs in terms of complicated control flows. Therefore, Jeremy proposed the use of OP_HASH160 [20-byte-hash-value 1]...[20-byte-hash-value N] OP_N OP_MULTISCRIPTHASHVERIFY which could be spent with signatures and serialized script. While the permission group example is just one use case, there could be other interesting combinations as well. However, there is an implication in terms of increased UTXO pool bloat and increased transaction complexity. Each 20 byte hash allows for a 500 byte script, but only one of the 500 byte scripts has to be permanently stored on the 2014-07-17T20:08:24+00:00 + Jeremy has proposed a new transaction type that matches on script hashes similar to pay to script hash, but checks for one of N scripts. However, this idea is considered less flexible and efficient compared to the Merkelized Abstract Syntax Tree construction. The proposed idea was previously discussed by Tier Nolan in the "Selector Script" thread.The discussion revolves around the costs associated with implementing a new transaction type in Bitcoin's network. The proposed method is compared to P2SH, which is already analyzed by developers and working. The cost of updating everyone to relay this new transaction type is also considered, along with the cost of increasing the rate of UTXO growth versus P2SH and the implications of "default public" versus P2SH's "default private". In terms of space efficiency, publishing the script in the txout allows for easy auditing by third parties scanning the blockchain. However, this can also be accomplished by offering the script upon request out-of-band. The idea of creating a "cookbook" of useful scripts is presented.The proposal suggests doing a p2sh with a switch statement that allows selecting one of n scripts each 520 bytes long without bloating the utxo pool more than a p2sh. This could result in long-term space savings on disk for regular p2sh. Adding a "function-hash-pointer jump table / switch statement" could also save space and allow for more complicated scripts to be built.Considerations for a system like Bitcoin include the cost of upgrades and network-wide changes compared to already analyzed and working P2SH, as well as the predictability of P2SH outputs versus less predictable outputs. Updating everyone to relay new transaction types and increasing the rate of UTXO growth also add to the cost. Publishing the script in the txout allows for easy auditing, but it can also be done through out-of-band offering. The script is hash-sealed by the P2SH address, enabling perfect proof. A "cookbook" of useful scripts would help explore the power of Bitcoin scripts.A proposed method is simpler with fewer bytes for control flow, but additional costs would be in terms of chance of user error/application error, extra bytes for control flow, larger script size if scriptSig script has to store the logic for all potential permission groups, hidden-till-spent permission groups, and larger blockchain bloat overall. Blockchain analysis can actively monitor the utxo pool for known associated scripts, whereas specialty scripts assembled per group cannot. A SAT scripting language with an eval or something similar can also be added. Using a normal P2SH output with OP_IF and friends seems more straightforward when considering the costs of increased UTXO pool bloat and transaction complexity. Boolean logic with multisig groups is quite possible, and there is definitely a valid use case called "multi-multisig".The proposed method of using a 20-byte hash to represent a permission group incurs additional costs in terms of chance of user error/application error and extra bytes for control flow. However, this method allows for hidden-till-spent permission groups, reduces blockchain bloat, and enables repeated spends with groups without recalling all participants. The author suggests pushing the sigs onto the stack and having implicit orders, then doing expressions with their aliases, and being able to assign "spending groups" using a SAT scripting language with an eval. Doing boolean logic with multisig groups is quite possible, referred to as "multi-multisig".In an email conversation, Jeremy proposed a solution to express multiple ways that would incur additional costs in terms of complicated control flows. He suggested using a normal P2SH output and a script with OP_IF and friends, which seems more straightforward. However, there is an implication in terms of increased UTXO pool bloat and increased transaction complexity. Each 20-byte hash allows for a 500-byte script, and only one of the 500 byte scripts has to be permanently stored on the blockchain. Jeremy also mentioned that doing boolean logic with multisig groups is quite possible and considered it a valid use case called "multi-multisig".Jeremy Rubin proposed a new transaction type that matches on script hashes similar to pay to script hash but checks for one of N scripts. The motivation behind this idea is to create "permission groups" where multiple groups can spend a UTXO. Currently, expressing this would require additional costs in terms of complicated control flows. Therefore, Jeremy proposed the use of OP_HASH160 [20-byte-hash-value 1]...[20-byte-hash-value N] OP_N OP_MULTISCRIPTHASHVERIFY which could be spent with signatures and serialized script. While the permission group example is just one use case, there could be other interesting combinations as well. However, there is an implication in terms of increased UTXO pool bloat and increased transaction complexity. Each 20 byte hash allows for a 500 byte script, but only one of the 500 byte scripts has to be permanently stored on the - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml b/static/bitcoin-dev/July_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml index 40d938ea1c..c3fd64db6e 100644 --- a/static/bitcoin-dev/July_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml +++ b/static/bitcoin-dev/July_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.614614+00:00 + 2025-10-11T22:04:17.386006+00:00 + python-feedgen Alex Kotenko 2014-07-02 08:49:10+00:00 @@ -271,13 +272,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.615612+00:00 + 2025-10-11T22:04:17.386308+00:00 - In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. 2014-07-02T08:49:10+00:00 + In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Policy-for-DNS-seeds.xml b/static/bitcoin-dev/July_2014/combined_Policy-for-DNS-seeds.xml index 034a168ed5..c7d20f8c11 100644 --- a/static/bitcoin-dev/July_2014/combined_Policy-for-DNS-seeds.xml +++ b/static/bitcoin-dev/July_2014/combined_Policy-for-DNS-seeds.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Policy for DNS seeds - 2023-08-01T09:55:41.938892+00:00 + 2025-10-11T22:04:11.007040+00:00 + python-feedgen Matt Corallo 2014-07-22 20:01:45+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Policy for DNS seeds - 2023-08-01T09:55:41.938892+00:00 + 2025-10-11T22:04:11.007194+00:00 - The Bitcoin Core software has established a set of basic rules for the DNS seeds to minimize the level of trust required for them. These rules aim to add more DNS Seeds run by people who closely follow development and are aware of the issues involved. The expectations for DNSSeed operators include following good host security practices, maintaining control of their serving infrastructure without selling or transferring control of it, and not logging DNS queries except what is necessary for the operation of the service or urgent health of the Bitcoin network.Furthermore, the DNSseed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network. While the results may be randomized, they must not single out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed. The results may not be served with a DNS TTL of less than one minute.Operators are encouraged to publicly document the details of their operating practices, although this is not mandatory. Additionally, a reachable email contact address must be published for inquiries related to the DNSseed operation. If these expectations cannot be satisfied, the operator should discontinue providing services and contact the active Bitcoin Core development team as well as posting on bitcoin-development.It is acknowledged that behavior outside of these expectations may be reasonable in certain situations but should be discussed in advance. To ensure transparency, any deviations from the rules should be publicly discussed before implementation. Furthermore, the proposal also calls for an "Expectations for DNSSeed users" document outlining the security properties and possible attacks associated with the seeds.In conclusion, these basic rules aim to reduce the level of trust required for DNS seeds in Bitcoin Core software. They outline expectations for DNSSeed operators and call for transparency and discussion in case of any deviations. 2014-07-22T20:01:45+00:00 + The Bitcoin Core software has established a set of basic rules for the DNS seeds to minimize the level of trust required for them. These rules aim to add more DNS Seeds run by people who closely follow development and are aware of the issues involved. The expectations for DNSSeed operators include following good host security practices, maintaining control of their serving infrastructure without selling or transferring control of it, and not logging DNS queries except what is necessary for the operation of the service or urgent health of the Bitcoin network.Furthermore, the DNSseed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network. While the results may be randomized, they must not single out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed. The results may not be served with a DNS TTL of less than one minute.Operators are encouraged to publicly document the details of their operating practices, although this is not mandatory. Additionally, a reachable email contact address must be published for inquiries related to the DNSseed operation. If these expectations cannot be satisfied, the operator should discontinue providing services and contact the active Bitcoin Core development team as well as posting on bitcoin-development.It is acknowledged that behavior outside of these expectations may be reasonable in certain situations but should be discussed in advance. To ensure transparency, any deviations from the rules should be publicly discussed before implementation. Furthermore, the proposal also calls for an "Expectations for DNSSeed users" document outlining the security properties and possible attacks associated with the seeds.In conclusion, these basic rules aim to reduce the level of trust required for DNS seeds in Bitcoin Core software. They outline expectations for DNSSeed operators and call for transparency and discussion in case of any deviations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Question-on-creating-test-cases-for-block-CheckBlock-.xml b/static/bitcoin-dev/July_2014/combined_Question-on-creating-test-cases-for-block-CheckBlock-.xml index 14b520ee6a..89f14c92db 100644 --- a/static/bitcoin-dev/July_2014/combined_Question-on-creating-test-cases-for-block-CheckBlock-.xml +++ b/static/bitcoin-dev/July_2014/combined_Question-on-creating-test-cases-for-block-CheckBlock-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Question on creating test cases for block.CheckBlock() - 2023-08-01T09:55:56.466003+00:00 + 2025-10-11T22:04:00.391047+00:00 + python-feedgen Mike Hearn 2014-07-22 11:13:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Question on creating test cases for block.CheckBlock() - 2023-08-01T09:55:56.466003+00:00 + 2025-10-11T22:04:00.391174+00:00 - The author is currently working on a BIP that requires modifications to the block acceptance rules. They have two options for testing this BIP: mining blocks on the testnet or creating test cases for Bitcoin Core. The author specifically wants to create test cases for the block.CheckBlock() function by verifying 100 dynamically generated blocks.However, there are some uncertainties regarding the state of the blockchain when executing a test case. It is unclear which network (regtest, testnet3, or mainnet) the test case is configured for and what blocks are present in the blockchain. Upon investigation, the author discovered that the checkblock_tests.cpp file is the only test case available for CheckBlock(). However, this test case assumes that the mainnet is configured. To overcome this limitation, the author needs to utilize regtest, which will allow them to create blocks with a difficulty of 1.Currently, there is no infrastructure for writing blockchain unit tests. To address this issue, the pull tester has been extended as a solution. The pull tester is an app called BitcoindComparisonTool, based on bitcoinj, that builds a regtest chain and submits it to a local regtest node. This tool enables testing of reorgs and various rules by communicating with the node solely via P2P.While the pull tester provides a potential solution, there is still room for improvement. The code requires cleaning up, as copy/paste coding is prevalent. Additionally, the ease of verifying a BIP via P2P plays a crucial role in determining its feasibility. 2014-07-22T11:13:50+00:00 + The author is currently working on a BIP that requires modifications to the block acceptance rules. They have two options for testing this BIP: mining blocks on the testnet or creating test cases for Bitcoin Core. The author specifically wants to create test cases for the block.CheckBlock() function by verifying 100 dynamically generated blocks.However, there are some uncertainties regarding the state of the blockchain when executing a test case. It is unclear which network (regtest, testnet3, or mainnet) the test case is configured for and what blocks are present in the blockchain. Upon investigation, the author discovered that the checkblock_tests.cpp file is the only test case available for CheckBlock(). However, this test case assumes that the mainnet is configured. To overcome this limitation, the author needs to utilize regtest, which will allow them to create blocks with a difficulty of 1.Currently, there is no infrastructure for writing blockchain unit tests. To address this issue, the pull tester has been extended as a solution. The pull tester is an app called BitcoindComparisonTool, based on bitcoinj, that builds a regtest chain and submits it to a local regtest node. This tool enables testing of reorgs and various rules by communicating with the node solely via P2P.While the pull tester provides a potential solution, there is still room for improvement. The code requires cleaning up, as copy/paste coding is prevalent. Additionally, the ease of verifying a BIP via P2P plays a crucial role in determining its feasibility. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Self-dependency-transaction-question-.xml b/static/bitcoin-dev/July_2014/combined_Self-dependency-transaction-question-.xml index fedc2d2b6b..6cd4037940 100644 --- a/static/bitcoin-dev/July_2014/combined_Self-dependency-transaction-question-.xml +++ b/static/bitcoin-dev/July_2014/combined_Self-dependency-transaction-question-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Self-dependency transaction question... - 2023-08-01T09:42:04.398252+00:00 + 2025-10-11T22:04:06.758751+00:00 + python-feedgen Paul Lyon 2014-07-15 13:56:20+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Self-dependency transaction question... - 2023-08-01T09:42:04.398252+00:00 + 2025-10-11T22:04:06.758942+00:00 - In an email conversation, Mike from Plan99.net explains the concept of transactions in the blockchain. He mentions that all transactions in the blockchain exist on a single timeline, which is quantized into blocks. However, duplicated transactions can occur, and while Satoshi assumed that this could not happen due to everything being hash-based, it did happen at one point. To handle this, a rule change was implemented and there is now a BIP covering this new rule.Richard Moore raised a question regarding the validity of self-referencing transactions in an email sent on July 13, 2014. He asked if a transaction X whose input was X and had an output Y would result in Y being a valid UTXO (unspent transaction output) without being a generation transaction input. However, even if such a transaction did exist and was valid, it still couldn't create new coins. This is because the sum of the outputs must be less than or equal to the sum of the inputs, except for coinbase transactions. If a transaction spent its own output, the input would be completely used up by the output, leaving no balance for a second output.In the blockchain, all transactions are on a single timeline that is quantised into blocks. While it is a strict line, duplicated transactions can occur despite being hash-based. Satoshi assumed this would never happen, but duplicating coinbases is possible and was banned by a rule change. Older parts of the chain may still have this issue, so it is essential to be able to process them. A BIP exists to cover the new rule.In a conversation between Aaron Voisine and Jeff Garzik, it was confirmed that transactions (tx) must be ordered sequentially within a block and cannot reference themselves or later transactions in the same block. Garzik suggested adding a test to the suite to confirm the validity of a block containing self-referential transactions. Garzik is a Bitcoin core developer and open-source evangelist at BitPay Inc.A question was raised by Richard Moore regarding the validity of a situation he found in his Python implementation of bitcoind. Block #546's 4th transaction had its first input use its own block's 3rd transaction as an input. He asked if the 3rd transaction of a block could use the 4th transaction from the same block as an input, or are transactions processed strictly top to bottom. Additionally, he asked what would happen if a transaction was self-referencing, where a transaction X has an input of X and an output Y. Aaron Voisine responded that transactions have to be ordered sequentially within a block and since a transaction is referenced by its hash, it's practically impossible to make a self-referential transaction.A developer is working on the UTXO database for their Python implementation of bitcoind and has come across a situation they did not realize was valid. They are asking if the 3rd transaction of a block could use the 4th transaction from the same block as an input, or if transactions are processed strictly top to bottom. They also ask what would happen if a transaction was self-referencing and had an output Y, would Y be a new valid UTXO, without being a generation transaction input. 2014-07-15T13:56:20+00:00 + In an email conversation, Mike from Plan99.net explains the concept of transactions in the blockchain. He mentions that all transactions in the blockchain exist on a single timeline, which is quantized into blocks. However, duplicated transactions can occur, and while Satoshi assumed that this could not happen due to everything being hash-based, it did happen at one point. To handle this, a rule change was implemented and there is now a BIP covering this new rule.Richard Moore raised a question regarding the validity of self-referencing transactions in an email sent on July 13, 2014. He asked if a transaction X whose input was X and had an output Y would result in Y being a valid UTXO (unspent transaction output) without being a generation transaction input. However, even if such a transaction did exist and was valid, it still couldn't create new coins. This is because the sum of the outputs must be less than or equal to the sum of the inputs, except for coinbase transactions. If a transaction spent its own output, the input would be completely used up by the output, leaving no balance for a second output.In the blockchain, all transactions are on a single timeline that is quantised into blocks. While it is a strict line, duplicated transactions can occur despite being hash-based. Satoshi assumed this would never happen, but duplicating coinbases is possible and was banned by a rule change. Older parts of the chain may still have this issue, so it is essential to be able to process them. A BIP exists to cover the new rule.In a conversation between Aaron Voisine and Jeff Garzik, it was confirmed that transactions (tx) must be ordered sequentially within a block and cannot reference themselves or later transactions in the same block. Garzik suggested adding a test to the suite to confirm the validity of a block containing self-referential transactions. Garzik is a Bitcoin core developer and open-source evangelist at BitPay Inc.A question was raised by Richard Moore regarding the validity of a situation he found in his Python implementation of bitcoind. Block #546's 4th transaction had its first input use its own block's 3rd transaction as an input. He asked if the 3rd transaction of a block could use the 4th transaction from the same block as an input, or are transactions processed strictly top to bottom. Additionally, he asked what would happen if a transaction was self-referencing, where a transaction X has an input of X and an output Y. Aaron Voisine responded that transactions have to be ordered sequentially within a block and since a transaction is referenced by its hash, it's practically impossible to make a self-referential transaction.A developer is working on the UTXO database for their Python implementation of bitcoind and has come across a situation they did not realize was valid. They are asking if the 3rd transaction of a block could use the 4th transaction from the same block as an input, or if transactions are processed strictly top to bottom. They also ask what would happen if a transaction was self-referencing and had an output Y, would Y be a new valid UTXO, without being a generation transaction input. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Signature-with-negative-integer-.xml b/static/bitcoin-dev/July_2014/combined_Signature-with-negative-integer-.xml index 0fb7db5887..5dd4fb39b2 100644 --- a/static/bitcoin-dev/July_2014/combined_Signature-with-negative-integer-.xml +++ b/static/bitcoin-dev/July_2014/combined_Signature-with-negative-integer-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Signature with negative integer? - 2023-08-01T09:55:07.995291+00:00 + 2025-10-11T22:04:15.261013+00:00 + python-feedgen Gregory Maxwell 2014-07-19 07:03:35+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Signature with negative integer? - 2023-08-01T09:55:07.995291+00:00 + 2025-10-11T22:04:15.261191+00:00 - In an email dated July 18, 2014, Richard Moore reached out for assistance in understanding the input signature script of a specific transaction with the ID tx 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d. The timing of this request was opportune as there was an ongoing discussion regarding BIP0062, which was directly relevant to the issue at hand. This particular case serves as an illustration of how the lenient interpretation of invalid encoding in OpenSSL, a cryptographic library, can lead to unexpected normative rules within the Bitcoin ecosystem.It is worth noting that while more recent releases of Bitcoin core no longer relay or mine these types of transactions, they are still considered valid if they appear in blocks. To address this vulnerability, BIP62 proposes soft-forking changes that would enforce stricter limitations on DER encoding to eliminate any ambiguity. If network implementations were to adopt these changes, existing unusual transactions could be allowed to remain on a case-by-case basis, identified by their transaction IDs. Different implementations could utilize distinct DER decoding code without the risk of consensus inconsistencies, as long as they adhere to the functional equivalent of what BIP62 requires.Returning to Richard Moore's specific query, he is seeking guidance on how to obtain a positive value for the point P in the ECC library being utilized. It appears that the ECC library has encountered difficulty in verifying the point, which needs to have a positive value. The writer attempted to modify the point by applying a modulo curve.order operation, but unfortunately, this approach did not yield the desired outcome.Consequently, Richard Moore is requesting assistance in determining the proper method to acquire a positive value for point P, where Py = 0 and Py >= 0. Any guidance on this matter would be greatly appreciated. 2014-07-19T07:03:35+00:00 + In an email dated July 18, 2014, Richard Moore reached out for assistance in understanding the input signature script of a specific transaction with the ID tx 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d. The timing of this request was opportune as there was an ongoing discussion regarding BIP0062, which was directly relevant to the issue at hand. This particular case serves as an illustration of how the lenient interpretation of invalid encoding in OpenSSL, a cryptographic library, can lead to unexpected normative rules within the Bitcoin ecosystem.It is worth noting that while more recent releases of Bitcoin core no longer relay or mine these types of transactions, they are still considered valid if they appear in blocks. To address this vulnerability, BIP62 proposes soft-forking changes that would enforce stricter limitations on DER encoding to eliminate any ambiguity. If network implementations were to adopt these changes, existing unusual transactions could be allowed to remain on a case-by-case basis, identified by their transaction IDs. Different implementations could utilize distinct DER decoding code without the risk of consensus inconsistencies, as long as they adhere to the functional equivalent of what BIP62 requires.Returning to Richard Moore's specific query, he is seeking guidance on how to obtain a positive value for the point P in the ECC library being utilized. It appears that the ECC library has encountered difficulty in verifying the point, which needs to have a positive value. The writer attempted to modify the point by applying a modulo curve.order operation, but unfortunately, this approach did not yield the desired outcome.Consequently, Richard Moore is requesting assistance in determining the proper method to acquire a positive value for point P, where Py = 0 and Py >= 0. Any guidance on this matter would be greatly appreciated. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Small-update-to-BIP-62.xml b/static/bitcoin-dev/July_2014/combined_Small-update-to-BIP-62.xml index cdba788092..60706dd0cd 100644 --- a/static/bitcoin-dev/July_2014/combined_Small-update-to-BIP-62.xml +++ b/static/bitcoin-dev/July_2014/combined_Small-update-to-BIP-62.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Small update to BIP 62 - 2023-08-01T09:52:51.137865+00:00 + 2025-10-11T22:04:08.883413+00:00 + python-feedgen Pieter Wuille 2014-09-13 22:45:14+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Small update to BIP 62 - 2023-08-01T09:52:51.137865+00:00 + 2025-10-11T22:04:08.883600+00:00 - On September 8, 2014, Pieter Wuille made changes to the Bitcoin Improvement Proposal (BIP) repository, specifically altering the order of rules and adding reference documentation. He later sent another pull request on September 12, 2014, focusing on compressed or uncompressed public keys. During discussions with Gregory Maxwell, concerns were raised about the lack of specificity in rule 4 of BIP 62. Wuille agreed to address this issue by making updates to the text. The conversation also touched upon additional consensus rules and their limitations. In response, Wuille sent a new pull request for BIP 62, clarifying the limitations of the rules and reordering them.In another discussion about BIP 62, Gregory Maxwell expressed concerns about the lack of specificity in rule 4. Wuille acknowledged the issue and planned to make necessary changes. They also discussed the reordering of rules and the presence of inherently malleable scriptPubkeys. During a conversation about cryptographic protocols, Gregory Maxwell explained the properties of the DSA nonce and why duplicating the verifier's generation of k is impossible. He emphasized that attackers are not bound by protocols unless prevented and that proving a specific nonce generation scheme without revealing the private key is unreasonable. In a discussion about BIP 62, Mike Hearn questioned the necessity of rule 4. Wladimir explained that non-push operations in scriptSig can lead to malleability, which the rule aims to prevent. Aaron Voisine and Gregory Maxwell debated the effectiveness of deterministic signing and randomness-free signature systems in relation to the DSA nonce and its implications for Bitcoin transactions.Pieter Wuille sent a pull request to modify BIP 62, making two new rules mandatory for old-style transactions. He explained the rationale behind this change and stressed the importance of strict DER compliance for signatures. In a separate conversation, Wuille discussed the absence of non-DER signatures in recent blocks with an unidentified individual.Mike Hearn and Pieter discussed potential changes to Bitcoin's consensus rules, including the necessity of rule 4 and the significance of backwards compatibility. The author of the context questioned the reasoning behind rule 4 and expressed a preference for preserving compatibility until older versions are phased out. Wuille subsequently sent a pull request to modify BIP 62, removing the requirement for bug-for-bug compatibility with OpenSSL and suggesting investigating non-DER signatures in blocks before making any changes.Furthermore, Pieter Wuille, a Bitcoin Core developer, has proposed a change to the Bitcoin protocol to support Discrete Log Contracts (DLCs) on the network. DLCs are smart contracts that enable trustless, non-custodial financial agreements between parties. The proposed change introduces a new opcode, OP_DLC, which would facilitate the execution of DLCs without altering the underlying Bitcoin infrastructure. The suggested modifications also enhance the Bitcoin scripting language, enabling complex contract logic.To ensure successful implementation, Wuille is actively seeking comments and feedback from the Bitcoin community. He has shared a draft of the proposed changes on the Bitcoin development mailing list, inviting developers and stakeholders to review and provide input. By incorporating DLCs into the Bitcoin protocol, Wuille believes it will expand the possibilities of decentralized finance and smart contract applications on the network. This includes prediction markets where users can bet on real-world events and decentralized derivatives trading without centralized intermediaries. Overall, the proposal aims to enhance the functionality and versatility of the Bitcoin network through the introduction of support for Discrete Log Contracts. 2014-09-13T22:45:14+00:00 + On September 8, 2014, Pieter Wuille made changes to the Bitcoin Improvement Proposal (BIP) repository, specifically altering the order of rules and adding reference documentation. He later sent another pull request on September 12, 2014, focusing on compressed or uncompressed public keys. During discussions with Gregory Maxwell, concerns were raised about the lack of specificity in rule 4 of BIP 62. Wuille agreed to address this issue by making updates to the text. The conversation also touched upon additional consensus rules and their limitations. In response, Wuille sent a new pull request for BIP 62, clarifying the limitations of the rules and reordering them.In another discussion about BIP 62, Gregory Maxwell expressed concerns about the lack of specificity in rule 4. Wuille acknowledged the issue and planned to make necessary changes. They also discussed the reordering of rules and the presence of inherently malleable scriptPubkeys. During a conversation about cryptographic protocols, Gregory Maxwell explained the properties of the DSA nonce and why duplicating the verifier's generation of k is impossible. He emphasized that attackers are not bound by protocols unless prevented and that proving a specific nonce generation scheme without revealing the private key is unreasonable. In a discussion about BIP 62, Mike Hearn questioned the necessity of rule 4. Wladimir explained that non-push operations in scriptSig can lead to malleability, which the rule aims to prevent. Aaron Voisine and Gregory Maxwell debated the effectiveness of deterministic signing and randomness-free signature systems in relation to the DSA nonce and its implications for Bitcoin transactions.Pieter Wuille sent a pull request to modify BIP 62, making two new rules mandatory for old-style transactions. He explained the rationale behind this change and stressed the importance of strict DER compliance for signatures. In a separate conversation, Wuille discussed the absence of non-DER signatures in recent blocks with an unidentified individual.Mike Hearn and Pieter discussed potential changes to Bitcoin's consensus rules, including the necessity of rule 4 and the significance of backwards compatibility. The author of the context questioned the reasoning behind rule 4 and expressed a preference for preserving compatibility until older versions are phased out. Wuille subsequently sent a pull request to modify BIP 62, removing the requirement for bug-for-bug compatibility with OpenSSL and suggesting investigating non-DER signatures in blocks before making any changes.Furthermore, Pieter Wuille, a Bitcoin Core developer, has proposed a change to the Bitcoin protocol to support Discrete Log Contracts (DLCs) on the network. DLCs are smart contracts that enable trustless, non-custodial financial agreements between parties. The proposed change introduces a new opcode, OP_DLC, which would facilitate the execution of DLCs without altering the underlying Bitcoin infrastructure. The suggested modifications also enhance the Bitcoin scripting language, enabling complex contract logic.To ensure successful implementation, Wuille is actively seeking comments and feedback from the Bitcoin community. He has shared a draft of the proposed changes on the Bitcoin development mailing list, inviting developers and stakeholders to review and provide input. By incorporating DLCs into the Bitcoin protocol, Wuille believes it will expand the possibilities of decentralized finance and smart contract applications on the network. This includes prediction markets where users can bet on real-world events and decentralized derivatives trading without centralized intermediaries. Overall, the proposal aims to enhance the functionality and versatility of the Bitcoin network through the introduction of support for Discrete Log Contracts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Squashing-redundant-tx-data-in-blocks-on-the-wire.xml b/static/bitcoin-dev/July_2014/combined_Squashing-redundant-tx-data-in-blocks-on-the-wire.xml index 0d07276d81..fe2773b7ef 100644 --- a/static/bitcoin-dev/July_2014/combined_Squashing-redundant-tx-data-in-blocks-on-the-wire.xml +++ b/static/bitcoin-dev/July_2014/combined_Squashing-redundant-tx-data-in-blocks-on-the-wire.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Squashing redundant tx data in blocks on the wire - 2023-08-01T09:47:20.622686+00:00 + 2025-10-11T22:04:02.513873+00:00 + python-feedgen Kaz Wesley 2014-08-01 01:00:06+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - Squashing redundant tx data in blocks on the wire - 2023-08-01T09:47:20.623685+00:00 + 2025-10-11T22:04:02.514059+00:00 - In an email exchange, Gregory Maxwell and Kaz Wesley discussed the possibility of developing a rule to avoid false negatives or excessive storage requirements. Kaz is working on a prototype that will provide data on the false-positive-missing-tx rate using a "remember-last-N" approach. They explored various upgrades to this rule, including learning dropped transactions through mempool syncing or specifying the rule explicitly with priority scripts.The idea of mempool synchronization raised concerns about transaction expiration. Gregory also mentioned the benefits of channel memory sparseblocks and FEC-based mempool synchronization. While implementing FEC at block forwarding time can minimize latency with multiple peers, they agreed that starting with a simple approach would be best.The discussion continued as Kaz Wesley questioned the need to solve the problem of missing transactions since the current protocol already exchanges necessary information. However, false positives and false negatives are still concerns when dealing with multiple peers. Kaz suggested that channel memory sparseblocks could achieve most of the possible bandwidth savings, and FEC-based mempool synchronization could reset the channel memory to the mutual mempool state. This would provide similar benefits to FEC-based block forwarding. The suggestion of using part of a cryptographic permutation as the key was also mentioned as a way to transmit new unknown keys without adding overhead.In another email exchange, Kaz Wesley emphasized the communication overhead of transmitting a transaction list. He proposed a method using forward error correcting (FEC) code data to fill in missing transactions without prior knowledge. Kaz acknowledged that sending 100% of the missing amount can save time if the transport is unordered. The suggestion of using part of a cryptographic permutation as the key was again mentioned as a way to avoid overhead for unknown transactions.On July 31, 2014, Gregory Maxwell and Kaz Wesley discussed the communication overhead of transmitting a transaction list. The current approach of sending 32 bits per transaction was deemed inefficient compared to a simpler approach. Gregory explained the use of non-syndromic forward error correcting code data to minimize overhead. However, it was noted that knowing the sizes and orders of the transactions is essential for this approach to be effective.Kaz Wesley suggested a method for retrieving missing transactions using forward error correcting (FEC) code data in an email conversation. This involved sending slightly larger non-syndromic FEC code data based on estimated missing data. The missing blocks could then be recovered using the FEC code. Wesley provided further details on how to implement this method effectively.The discussion touched on the practicality of set reconciliation for condensed block exchange. It was acknowledged that requesting missing transaction keys would require a round trip, making it costly for exchanging transactions not mutually known. Instead, remembering transmitted invs along connections was deemed effective for reducing bytes and CPU cycles. The current protocol already provides mutual knowledge, allowing for efficient block exchange. The implementation of inv-history-tracking and sparseblock messages were mentioned as improvements. Compact descriptions of block tx inclusion and ordering policies could eliminate overhead for known and unknown transactions. Efficient mempool synchronization and mempool exchange were also discussed to enhance channel-memory sparseblocks and prevent sybil attacks.Gavin Andresen expressed his thoughts on incentivizing nodes to propagate transactions in an email thread. He suggested rewarding nodes for propagating transactions since most transaction data has already been propagated. Wladimir proposed starting the set synchronization process when a miner begins working on a specific block. This would prepare peers for the actual block broadcast, which would only consist of the header and coinbase transaction.In a conversation, Emin Gün Sirer and another individual discussed minimizing data transfer in cryptocurrency mining. The round complexity was seen as crucial, with Yaron's non-interactive scheme being praised for its lack of overhead. Forward error correction (FEC) was suggested but acknowledged to still have some overhead. The multithreading of the client was considered the best approach, although the potential applicability of Yaron's work was noted.Emin Gün Sirer discussed a problem similar to set reconciliation and the importance of minimizing data transfer. The round complexity was highlighted, and a previous proposal to use FEC for low data transfer was mentioned. However, it was acknowledged that FEC schemes are complex and add metadata overhead.A new technique for solving the set reconciliation problem was described in a Cornell paper. This approach aimed to reduce communication complexity between peers and eliminate overhead. Set reconciliation was compared to Bloom filters, with the former being more efficient and non-interactive. The author invited interested parties to apply this technique to the Bitcoin p2p protocol.Kaz Wesley proposed an additional proposal involving sparse blocks and ultra-fast block validation (UFBV). This would incentivize ahead-of-block transaction propagation and make the new-block process more efficient for miners. The benefits of these changes were emphasized, but they only applied when transactions were seen in advance. Jeff Garzik, a Bitcoin core developer, was mentioned as being involved with BitPay, Inc.In a discussion on the Bitcoin-development mailing list, Kaz Wesley proposed that peers should exchange mempool priority policies and 2014-08-01T01:00:06+00:00 + In an email exchange, Gregory Maxwell and Kaz Wesley discussed the possibility of developing a rule to avoid false negatives or excessive storage requirements. Kaz is working on a prototype that will provide data on the false-positive-missing-tx rate using a "remember-last-N" approach. They explored various upgrades to this rule, including learning dropped transactions through mempool syncing or specifying the rule explicitly with priority scripts.The idea of mempool synchronization raised concerns about transaction expiration. Gregory also mentioned the benefits of channel memory sparseblocks and FEC-based mempool synchronization. While implementing FEC at block forwarding time can minimize latency with multiple peers, they agreed that starting with a simple approach would be best.The discussion continued as Kaz Wesley questioned the need to solve the problem of missing transactions since the current protocol already exchanges necessary information. However, false positives and false negatives are still concerns when dealing with multiple peers. Kaz suggested that channel memory sparseblocks could achieve most of the possible bandwidth savings, and FEC-based mempool synchronization could reset the channel memory to the mutual mempool state. This would provide similar benefits to FEC-based block forwarding. The suggestion of using part of a cryptographic permutation as the key was also mentioned as a way to transmit new unknown keys without adding overhead.In another email exchange, Kaz Wesley emphasized the communication overhead of transmitting a transaction list. He proposed a method using forward error correcting (FEC) code data to fill in missing transactions without prior knowledge. Kaz acknowledged that sending 100% of the missing amount can save time if the transport is unordered. The suggestion of using part of a cryptographic permutation as the key was again mentioned as a way to avoid overhead for unknown transactions.On July 31, 2014, Gregory Maxwell and Kaz Wesley discussed the communication overhead of transmitting a transaction list. The current approach of sending 32 bits per transaction was deemed inefficient compared to a simpler approach. Gregory explained the use of non-syndromic forward error correcting code data to minimize overhead. However, it was noted that knowing the sizes and orders of the transactions is essential for this approach to be effective.Kaz Wesley suggested a method for retrieving missing transactions using forward error correcting (FEC) code data in an email conversation. This involved sending slightly larger non-syndromic FEC code data based on estimated missing data. The missing blocks could then be recovered using the FEC code. Wesley provided further details on how to implement this method effectively.The discussion touched on the practicality of set reconciliation for condensed block exchange. It was acknowledged that requesting missing transaction keys would require a round trip, making it costly for exchanging transactions not mutually known. Instead, remembering transmitted invs along connections was deemed effective for reducing bytes and CPU cycles. The current protocol already provides mutual knowledge, allowing for efficient block exchange. The implementation of inv-history-tracking and sparseblock messages were mentioned as improvements. Compact descriptions of block tx inclusion and ordering policies could eliminate overhead for known and unknown transactions. Efficient mempool synchronization and mempool exchange were also discussed to enhance channel-memory sparseblocks and prevent sybil attacks.Gavin Andresen expressed his thoughts on incentivizing nodes to propagate transactions in an email thread. He suggested rewarding nodes for propagating transactions since most transaction data has already been propagated. Wladimir proposed starting the set synchronization process when a miner begins working on a specific block. This would prepare peers for the actual block broadcast, which would only consist of the header and coinbase transaction.In a conversation, Emin Gün Sirer and another individual discussed minimizing data transfer in cryptocurrency mining. The round complexity was seen as crucial, with Yaron's non-interactive scheme being praised for its lack of overhead. Forward error correction (FEC) was suggested but acknowledged to still have some overhead. The multithreading of the client was considered the best approach, although the potential applicability of Yaron's work was noted.Emin Gün Sirer discussed a problem similar to set reconciliation and the importance of minimizing data transfer. The round complexity was highlighted, and a previous proposal to use FEC for low data transfer was mentioned. However, it was acknowledged that FEC schemes are complex and add metadata overhead.A new technique for solving the set reconciliation problem was described in a Cornell paper. This approach aimed to reduce communication complexity between peers and eliminate overhead. Set reconciliation was compared to Bloom filters, with the former being more efficient and non-interactive. The author invited interested parties to apply this technique to the Bitcoin p2p protocol.Kaz Wesley proposed an additional proposal involving sparse blocks and ultra-fast block validation (UFBV). This would incentivize ahead-of-block transaction propagation and make the new-block process more efficient for miners. The benefits of these changes were emphasized, but they only applied when transactions were seen in advance. Jeff Garzik, a Bitcoin core developer, was mentioned as being involved with BitPay, Inc.In a discussion on the Bitcoin-development mailing list, Kaz Wesley proposed that peers should exchange mempool priority policies and - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Time.xml b/static/bitcoin-dev/July_2014/combined_Time.xml index cb8a77c398..31951a5461 100644 --- a/static/bitcoin-dev/July_2014/combined_Time.xml +++ b/static/bitcoin-dev/July_2014/combined_Time.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Time - 2023-08-01T09:56:09.500369+00:00 + 2025-10-11T22:04:28.009133+00:00 + python-feedgen Troy Benjegerdes 2014-07-28 17:33:30+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Time - 2023-08-01T09:56:09.500369+00:00 + 2025-10-11T22:04:28.009280+00:00 - In a discussion on Bitcoin's blockchain technology, concerns are raised about the security of breadwallet, an iOS application for Bitcoin storage. The use of a PIN lock as a security measure is questioned, and various suggestions are made to improve it. One suggestion is to record the time of each failed PIN attempt and not allow further attempts until time has advanced past the previous attempt. Another suggestion is to use the block height instead of the timestamp for determining the delay. The security benefits of breadwallet being tamper-resistant and zero-on-tamper hardware are also questioned, with suggestions of attaching a debugger or modifying the program to ignore the block-sourced time. However, it is noted that attaching to a process on an iOS device is more difficult than changing the system time. The overall security of breadwallet is debated, with some participants expressing doubts.The conversation also touches on the use of the blockchain as a reliable time source. It is mentioned that miners have previously manipulated the timestamp to increase their gigahashes. Concerns are raised about the possibility of an application being given a fake blockchain and getting stuck in the past forever. It is suggested to use at least three block chains to obtain reliable time sources and ensure they all agree within an hour. It is also mentioned that apps can currently obtain Bitcoin-level trusted time by polling independent servers. The advantages of using the blockchain as an approximate time source are discussed, including worldwide consensus without direct trust of any player.Overall, the discussion highlights the challenges and considerations involved in designing secure PIN verification systems and utilizing the blockchain as a time source. The security of breadwallet and the potential vulnerabilities it may have are examined, while different approaches and suggestions are presented to enhance its security. 2014-07-28T17:33:30+00:00 + In a discussion on Bitcoin's blockchain technology, concerns are raised about the security of breadwallet, an iOS application for Bitcoin storage. The use of a PIN lock as a security measure is questioned, and various suggestions are made to improve it. One suggestion is to record the time of each failed PIN attempt and not allow further attempts until time has advanced past the previous attempt. Another suggestion is to use the block height instead of the timestamp for determining the delay. The security benefits of breadwallet being tamper-resistant and zero-on-tamper hardware are also questioned, with suggestions of attaching a debugger or modifying the program to ignore the block-sourced time. However, it is noted that attaching to a process on an iOS device is more difficult than changing the system time. The overall security of breadwallet is debated, with some participants expressing doubts.The conversation also touches on the use of the blockchain as a reliable time source. It is mentioned that miners have previously manipulated the timestamp to increase their gigahashes. Concerns are raised about the possibility of an application being given a fake blockchain and getting stuck in the past forever. It is suggested to use at least three block chains to obtain reliable time sources and ensure they all agree within an hour. It is also mentioned that apps can currently obtain Bitcoin-level trusted time by polling independent servers. The advantages of using the blockchain as an approximate time source are discussed, including worldwide consensus without direct trust of any player.Overall, the discussion highlights the challenges and considerations involved in designing secure PIN verification systems and utilizing the blockchain as a time source. The security of breadwallet and the potential vulnerabilities it may have are examined, while different approaches and suggestions are presented to enhance its security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2014/combined_Trickle-and-transaction-propogation.xml b/static/bitcoin-dev/July_2014/combined_Trickle-and-transaction-propogation.xml index b68cf78656..780fb9a4c3 100644 --- a/static/bitcoin-dev/July_2014/combined_Trickle-and-transaction-propogation.xml +++ b/static/bitcoin-dev/July_2014/combined_Trickle-and-transaction-propogation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Trickle and transaction propogation - 2023-08-01T09:55:26.882689+00:00 + 2025-10-11T22:04:36.505193+00:00 + python-feedgen Mike Hearn 2014-07-20 22:02:39+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Trickle and transaction propogation - 2023-08-01T09:55:26.882689+00:00 + 2025-10-11T22:04:36.505331+00:00 - The inv trickling mechanism in Bitcoin serves two main purposes: protecting users' privacy and reducing unnecessary invs between nodes. However, it also slows down transaction propagation and delays mutual knowledge of transactions between nodes. These drawbacks will become more significant as optimizations based on mutually-known transactions are developed. While trickling helps protect privacy by obscuring transaction origins, it has its limitations.To make the staggering of introducing new invs more effective, a structure similar to mapAskFor could be used to schedule staggered pushes of wallet transactions to each peer. However, this method is vulnerable to sybil attacks. To address this, a policy of ending staggering and pushing to all peers once another peer has received the transaction from elsewhere can reduce the likelihood of inv origin information being obtained by a partial sybil.In terms of redundant invs, trickling reduces the number of invs sent between nodes when they receive transactions at around the same time. To solve the who-sends-first problem, connections could have directional parity. This means that a node initiating a connection would announce its parity (even or odd), and an inv would be sent right away to peers with matching parity, but only sent against parity if a certain timeout has elapsed without the inv being received. Parity could also be specified as a mask to allow for nodes with few peers or nodes on local connections that might flood everything to each other.Currently, most users are not using the Core wallet anymore, but rather use either SPV wallets or more centralized blockchain/coinbase style gateways to the network. SPV wallets don't relay, so any transaction sent from them must be originated by that wallet. Centralized services can improve user privacy by sending transactions out via a node that isn't listening. Optimizing the network for the common use case rather than just helping Core wallet users would benefit everyone.Overall, while eliminating trickling would double inv traffic, there are more efficient solutions to the problems caused by it. The proposed techniques of push staggering and directional parity could solve these issues more efficiently and still protect user privacy. By implementing these techniques, Bitcoin can have its cake and eat it too. However, if the proposed techniques do not achieve this, removing tx trickling should be considered. 2014-07-20T22:02:39+00:00 + The inv trickling mechanism in Bitcoin serves two main purposes: protecting users' privacy and reducing unnecessary invs between nodes. However, it also slows down transaction propagation and delays mutual knowledge of transactions between nodes. These drawbacks will become more significant as optimizations based on mutually-known transactions are developed. While trickling helps protect privacy by obscuring transaction origins, it has its limitations.To make the staggering of introducing new invs more effective, a structure similar to mapAskFor could be used to schedule staggered pushes of wallet transactions to each peer. However, this method is vulnerable to sybil attacks. To address this, a policy of ending staggering and pushing to all peers once another peer has received the transaction from elsewhere can reduce the likelihood of inv origin information being obtained by a partial sybil.In terms of redundant invs, trickling reduces the number of invs sent between nodes when they receive transactions at around the same time. To solve the who-sends-first problem, connections could have directional parity. This means that a node initiating a connection would announce its parity (even or odd), and an inv would be sent right away to peers with matching parity, but only sent against parity if a certain timeout has elapsed without the inv being received. Parity could also be specified as a mask to allow for nodes with few peers or nodes on local connections that might flood everything to each other.Currently, most users are not using the Core wallet anymore, but rather use either SPV wallets or more centralized blockchain/coinbase style gateways to the network. SPV wallets don't relay, so any transaction sent from them must be originated by that wallet. Centralized services can improve user privacy by sending transactions out via a node that isn't listening. Optimizing the network for the common use case rather than just helping Core wallet users would benefit everyone.Overall, while eliminating trickling would double inv traffic, there are more efficient solutions to the problems caused by it. The proposed techniques of push staggering and directional parity could solve these issues more efficiently and still protect user privacy. By implementing these techniques, Bitcoin can have its cake and eat it too. However, if the proposed techniques do not achieve this, removing tx trickling should be considered. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml b/static/bitcoin-dev/July_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml index 0091024b9b..3223202e9f 100644 --- a/static/bitcoin-dev/July_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml +++ b/static/bitcoin-dev/July_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks) - 2023-08-01T13:27:52.323460+00:00 + 2025-10-11T22:01:31.569031+00:00 + python-feedgen Jorge Timón 2015-08-29 21:21:05+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks) - 2023-08-01T13:27:52.323460+00:00 + 2025-10-11T22:01:31.569215+00:00 - A discussion thread on GitHub regarding a draft BIP (Bitcoin Improvement Proposal) has been moved to the mailing list due to GitHub not being specified for high-level discussions in BIP001. The original poster raises concerns about the structure and wording of the proposal, suggesting it be slimmed down and simplified, with some history lessons removed. The author of the proposal requests more specific suggestions before taking action. There is a question about a separate BIP for "code forks," clarified as beyond the scope of this BIP. It is noted that spell checking has not been followed for any BIP. The current label of the proposal is "informational | process" but may change based on appropriateness. The proposal contains code for an uncontroversial hard fork example to set a precedent. However, a proposal for a "patch into core as a module that hard forks can use in the future" requires further clarification.On July 31, 2015, Thomas Kerin via bitcoin-dev expresses the belief that a document should exist prior to assigning a BIP number. While there was an initial document, alterations were made after the BIP number was assigned. The author apologizes for breaking the previous link and provides a new one. The code is also available on Github. A separate mailing list discussion is ongoing regarding activation thresholds related to this BIP. The assumption of the BIP is that miners will upgrade after a defined starting block height, and once a 95% threshold is reached, the hard fork takes effect. After the first block is buried, the check can be replaced by redefining the threshold height instead of the height when miners started voting.Jorge Timón requests a BIP number from Greg Maxwell on the bitcoin-dev mailing list for discussions about deploying uncontroversial hard forks in one place. The proposed timewarp fix could be coded as a soft fork instead of a hard fork, requiring all blocks to be within one day of the median of the previous 11 blocks. Tier Nolan suggests this would protect against the exploit. Another proposal suggests that the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Nolan believes a hard fork is necessary to fix the issue "right," especially for demonstrating a non-controversial hard fork.Discussions revolve around obtaining miner confirmation on uncontroversial hard forks and whether to use nHeight, nMedianTime, or just nTime. A BIP number is requested to concentrate discussions on deploying uncontroversial hard forks in one place. One proposal for a timewarp fix suggests all blocks should be within 1 day of the median of the previous 11 blocks, adding a condition at the other end. Another proposal suggests the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Fixing the issue "right" would likely require a hard fork, particularly for demonstrating a non-controversial hard fork.In an email conversation, Jorge Timón suggests a soft fork solution to the timewarp exploit, proposing that all blocks should be within one day of the median of the previous 11 blocks, with a condition added at the other end. While not a total fix, it would protect against the exploit. A stricter soft fork would require the two blocks in question to have the same timestamp, ensuring the off by 1 and correct value yield the same result. Timón believes a hard fork is necessary to fix the issue "right," especially when demonstrating a non-controversial hard fork.Tier Nolan suggests fixing the "off by 1 bug" through a soft fork in an email thread on June 21, 2015. This suggestion is made in the context of demonstrating how a non-controversial hard fork works. The timewarp fix discussed in the thread could potentially be coded as a soft fork instead of a hard fork. However, it is unclear if there were any other candidates for addressing the issue.There is a discussion about an off by 1 bug and its potential fix through a soft fork. The focus is primarily on demonstrating how a non-controversial hard fork operates, with the bug solution being of lesser importance.The author seeks feedback to create an informational BIP on deploying hard forks. It is specified that the discussion only pertains to hard forks and soft forks in an abstract manner, excluding block size issues. Block size changes are used as examples due to lack of alternatives, but non-blocksize-related examples for the same cases are welcomed. The author encourages suggestions and input on terminology. The full text can be found on the author's Github page at https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org. 2015-08-29T21:21:05+00:00 + A discussion thread on GitHub regarding a draft BIP (Bitcoin Improvement Proposal) has been moved to the mailing list due to GitHub not being specified for high-level discussions in BIP001. The original poster raises concerns about the structure and wording of the proposal, suggesting it be slimmed down and simplified, with some history lessons removed. The author of the proposal requests more specific suggestions before taking action. There is a question about a separate BIP for "code forks," clarified as beyond the scope of this BIP. It is noted that spell checking has not been followed for any BIP. The current label of the proposal is "informational | process" but may change based on appropriateness. The proposal contains code for an uncontroversial hard fork example to set a precedent. However, a proposal for a "patch into core as a module that hard forks can use in the future" requires further clarification.On July 31, 2015, Thomas Kerin via bitcoin-dev expresses the belief that a document should exist prior to assigning a BIP number. While there was an initial document, alterations were made after the BIP number was assigned. The author apologizes for breaking the previous link and provides a new one. The code is also available on Github. A separate mailing list discussion is ongoing regarding activation thresholds related to this BIP. The assumption of the BIP is that miners will upgrade after a defined starting block height, and once a 95% threshold is reached, the hard fork takes effect. After the first block is buried, the check can be replaced by redefining the threshold height instead of the height when miners started voting.Jorge Timón requests a BIP number from Greg Maxwell on the bitcoin-dev mailing list for discussions about deploying uncontroversial hard forks in one place. The proposed timewarp fix could be coded as a soft fork instead of a hard fork, requiring all blocks to be within one day of the median of the previous 11 blocks. Tier Nolan suggests this would protect against the exploit. Another proposal suggests that the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Nolan believes a hard fork is necessary to fix the issue "right," especially for demonstrating a non-controversial hard fork.Discussions revolve around obtaining miner confirmation on uncontroversial hard forks and whether to use nHeight, nMedianTime, or just nTime. A BIP number is requested to concentrate discussions on deploying uncontroversial hard forks in one place. One proposal for a timewarp fix suggests all blocks should be within 1 day of the median of the previous 11 blocks, adding a condition at the other end. Another proposal suggests the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Fixing the issue "right" would likely require a hard fork, particularly for demonstrating a non-controversial hard fork.In an email conversation, Jorge Timón suggests a soft fork solution to the timewarp exploit, proposing that all blocks should be within one day of the median of the previous 11 blocks, with a condition added at the other end. While not a total fix, it would protect against the exploit. A stricter soft fork would require the two blocks in question to have the same timestamp, ensuring the off by 1 and correct value yield the same result. Timón believes a hard fork is necessary to fix the issue "right," especially when demonstrating a non-controversial hard fork.Tier Nolan suggests fixing the "off by 1 bug" through a soft fork in an email thread on June 21, 2015. This suggestion is made in the context of demonstrating how a non-controversial hard fork works. The timewarp fix discussed in the thread could potentially be coded as a soft fork instead of a hard fork. However, it is unclear if there were any other candidates for addressing the issue.There is a discussion about an off by 1 bug and its potential fix through a soft fork. The focus is primarily on demonstrating how a non-controversial hard fork operates, with the bug solution being of lesser importance.The author seeks feedback to create an informational BIP on deploying hard forks. It is specified that the discussion only pertains to hard forks and soft forks in an abstract manner, excluding block size issues. Block size changes are used as examples due to lack of alternatives, but non-blocksize-related examples for the same cases are welcomed. The author encourages suggestions and input on terminology. The full text can be found on the author's Github page at https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_A-Proposed-Compromise-to-the-Block-Size-Limit.xml b/static/bitcoin-dev/July_2015/combined_A-Proposed-Compromise-to-the-Block-Size-Limit.xml index 212ef40ff7..d0aed86f46 100644 --- a/static/bitcoin-dev/July_2015/combined_A-Proposed-Compromise-to-the-Block-Size-Limit.xml +++ b/static/bitcoin-dev/July_2015/combined_A-Proposed-Compromise-to-the-Block-Size-Limit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A Proposed Compromise to the Block Size Limit - 2023-08-01T14:03:11.909501+00:00 + 2025-10-11T22:01:35.818509+00:00 + python-feedgen Tom Harding 2015-07-10 02:55:15+00:00 @@ -175,13 +176,13 @@ - python-feedgen + 2 Combined summary - A Proposed Compromise to the Block Size Limit - 2023-08-01T14:03:11.909501+00:00 + 2025-10-11T22:01:35.818714+00:00 - Gavin Andresen, an influential figure in the Bitcoin community, expressed skepticism about the use of the Lightning Network for everyday transactions. He believed that very few personal Bitcoin or dollar transactions fit the use case that the Lightning Network is designed to solve. While he acknowledged its potential for innovation in micropayments and hourly worker payments, he did not see it as a scaling solution for the current types of payments handled by the Bitcoin network. He also raised concerns about centralization, particularly with payment channels between big financial institutions.The Lightning Network is a proposed solution to the scalability problem in Bitcoin transactions. It allows participants to send and receive coins through various hub connections without on-chain settlements. Each channel has a pseudonymous identity and can be closed when funds are needed for non-lightning reasons. The network has been described as a write coalescing write cache layer for Bitcoin. However, there are significant problems with the concept of hubs, including questions about knowledge, incentives, and complexity reduction. Despite being an interesting idea, the Lightning Network is still far from actual implementation.A discussion on Bitcoin scaling took place in 2015, where Benjamin expressed concerns about naive scaling and suggested working incrementally and carefully. Adam disagreed and explained how the Lightning Network works, stating that every lightning transaction is a valid bitcoin transaction. Adam clarified that lightning is expected to be peer-to-peer like Bitcoin.Decentralization is a crucial aspect of Bitcoin, and measuring its level can be challenging. The concept of pooling protocols can help phase out artificial centralization, but claims about decentralization often lack analysis or explanation. To improve discussions on changes, it is suggested to develop a metric for measuring decentralization.The author agrees that scaling Bitcoin in a naive way could have negative outcomes but acknowledges its advantages in not changing the original system. They express skepticism towards Level2 and Lightning solutions, stating that even if money is moved within the constraints of a locked contract, it does not solve the issues with off-chain transactions. The author argues that moving between off-chain and on-chain requires liquidity and a pricing mechanism, which is a problem similar to side-chains. Additionally, off-chain transactions on an exchange are subject to KYC/AML regulations.In a forum post, Raystonn explains that nodes are limited to 133 connections, and the load is only affected by transaction rate, not by the number of connections. There have been concerns about larger blocks resulting in exponential growth of work, but this is based on a wrong assumption. Decentralization is crucial for Bitcoin's security properties, and simplistic thinking about an ever-increasing block size is destructive. Improvement can be achieved through bandwidth and relay enhancements and pooling protocols to phase out artificial centralization.In an email conversation, Jameson Lopp and Peter Todd discuss Bitcoin scaling. Lopp argues that for Bitcoin to have O(n) scaling, the number of validation nodes must remain constant with the number of users. Todd disagrees, stating that it doesn't matter what the total work of the network is, as participants only care about the resources required to run their own node. He points out that the number of nodes is inversely proportional to the number of users, which presents a significant problem. O(n^2) scaling means that as Bitcoin is adopted more widely, it becomes harder to use in a decentralized way without trusting others.Another email conversation between Peter Todd and Michael Naber addresses global network consensus in Bitcoin. Naber questions whether off-chain solutions like hub-and-spoke payment channels and the Lightning network provide global network consensus. Todd explains that these solutions are actually more efficient ways of using on-chain transactions and enable economic transactions without any blockchain transactions. He asserts that Bitcoin Core scales with O(N), and achieving O(n) scaling would require a trust-based system. Todd suggests building a trust-based system on top of Bitcoin's global consensus functionality.The discussion on the Bitcoin development mailing list revolves around the fee market and its comparison to other markets. While there is no assured quality of service in the Bitcoin fee market, this is not uncommon in other financial markets. The comparison is made to a market maker's order book, but in Bitcoin, it is difficult to know how miners are positioning themselves at any given moment. The author suggests that establishing a feedback loop through auctions with increasing increments could settle demand and supply. However, adapting supply remains a challenge for resolving capacity problems.In an email exchange, Benjamin expresses doubts about the capacity and functioning of the Bitcoin system. He argues that there is no supply and demand mechanism that would allow users to adapt fees and receive different qualities of service based on current capacity. Peter Todd counters this claim by stating that Bitcoin already operates based on supply and demand. Fees can be adapted to obtain different qualities of service depending on capacity. Todd refers Benjamin to his article on how transaction fees work for more details.Bitcoin Core aims to solve the global consensus problem, but there are ongoing discussions about raising the block size and meeting the demand for high-capacity global consensus. 2015-07-10T02:55:15+00:00 + Gavin Andresen, an influential figure in the Bitcoin community, expressed skepticism about the use of the Lightning Network for everyday transactions. He believed that very few personal Bitcoin or dollar transactions fit the use case that the Lightning Network is designed to solve. While he acknowledged its potential for innovation in micropayments and hourly worker payments, he did not see it as a scaling solution for the current types of payments handled by the Bitcoin network. He also raised concerns about centralization, particularly with payment channels between big financial institutions.The Lightning Network is a proposed solution to the scalability problem in Bitcoin transactions. It allows participants to send and receive coins through various hub connections without on-chain settlements. Each channel has a pseudonymous identity and can be closed when funds are needed for non-lightning reasons. The network has been described as a write coalescing write cache layer for Bitcoin. However, there are significant problems with the concept of hubs, including questions about knowledge, incentives, and complexity reduction. Despite being an interesting idea, the Lightning Network is still far from actual implementation.A discussion on Bitcoin scaling took place in 2015, where Benjamin expressed concerns about naive scaling and suggested working incrementally and carefully. Adam disagreed and explained how the Lightning Network works, stating that every lightning transaction is a valid bitcoin transaction. Adam clarified that lightning is expected to be peer-to-peer like Bitcoin.Decentralization is a crucial aspect of Bitcoin, and measuring its level can be challenging. The concept of pooling protocols can help phase out artificial centralization, but claims about decentralization often lack analysis or explanation. To improve discussions on changes, it is suggested to develop a metric for measuring decentralization.The author agrees that scaling Bitcoin in a naive way could have negative outcomes but acknowledges its advantages in not changing the original system. They express skepticism towards Level2 and Lightning solutions, stating that even if money is moved within the constraints of a locked contract, it does not solve the issues with off-chain transactions. The author argues that moving between off-chain and on-chain requires liquidity and a pricing mechanism, which is a problem similar to side-chains. Additionally, off-chain transactions on an exchange are subject to KYC/AML regulations.In a forum post, Raystonn explains that nodes are limited to 133 connections, and the load is only affected by transaction rate, not by the number of connections. There have been concerns about larger blocks resulting in exponential growth of work, but this is based on a wrong assumption. Decentralization is crucial for Bitcoin's security properties, and simplistic thinking about an ever-increasing block size is destructive. Improvement can be achieved through bandwidth and relay enhancements and pooling protocols to phase out artificial centralization.In an email conversation, Jameson Lopp and Peter Todd discuss Bitcoin scaling. Lopp argues that for Bitcoin to have O(n) scaling, the number of validation nodes must remain constant with the number of users. Todd disagrees, stating that it doesn't matter what the total work of the network is, as participants only care about the resources required to run their own node. He points out that the number of nodes is inversely proportional to the number of users, which presents a significant problem. O(n^2) scaling means that as Bitcoin is adopted more widely, it becomes harder to use in a decentralized way without trusting others.Another email conversation between Peter Todd and Michael Naber addresses global network consensus in Bitcoin. Naber questions whether off-chain solutions like hub-and-spoke payment channels and the Lightning network provide global network consensus. Todd explains that these solutions are actually more efficient ways of using on-chain transactions and enable economic transactions without any blockchain transactions. He asserts that Bitcoin Core scales with O(N), and achieving O(n) scaling would require a trust-based system. Todd suggests building a trust-based system on top of Bitcoin's global consensus functionality.The discussion on the Bitcoin development mailing list revolves around the fee market and its comparison to other markets. While there is no assured quality of service in the Bitcoin fee market, this is not uncommon in other financial markets. The comparison is made to a market maker's order book, but in Bitcoin, it is difficult to know how miners are positioning themselves at any given moment. The author suggests that establishing a feedback loop through auctions with increasing increments could settle demand and supply. However, adapting supply remains a challenge for resolving capacity problems.In an email exchange, Benjamin expresses doubts about the capacity and functioning of the Bitcoin system. He argues that there is no supply and demand mechanism that would allow users to adapt fees and receive different qualities of service based on current capacity. Peter Todd counters this claim by stating that Bitcoin already operates based on supply and demand. Fees can be adapted to obtain different qualities of service depending on capacity. Todd refers Benjamin to his article on how transaction fees work for more details.Bitcoin Core aims to solve the global consensus problem, but there are ongoing discussions about raising the block size and meeting the demand for high-capacity global consensus. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_A-compromise-between-BIP101-and-Pieter-s-proposal.xml b/static/bitcoin-dev/July_2015/combined_A-compromise-between-BIP101-and-Pieter-s-proposal.xml index 0172e58b0d..aeb8747a11 100644 --- a/static/bitcoin-dev/July_2015/combined_A-compromise-between-BIP101-and-Pieter-s-proposal.xml +++ b/static/bitcoin-dev/July_2015/combined_A-compromise-between-BIP101-and-Pieter-s-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A compromise between BIP101 and Pieter's proposal - 2023-08-01T14:50:35.700912+00:00 + 2025-10-11T22:02:33.227265+00:00 + python-feedgen Dave Scotese 2015-08-02 22:07:22+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - A compromise between BIP101 and Pieter's proposal - 2023-08-01T14:50:35.700912+00:00 + 2025-10-11T22:02:33.227501+00:00 - The email thread discusses proposed changes to the block size and deployment period for Bitcoin. One party suggests a starting date for the block size 30 days after 75% miner support but not before January 12, 2016. The block size will gradually increase over 16 months until it reaches 8MB on May 11, 2017. Chinese miners agree with this proposal. However, there is disagreement on whether we can currently handle larger blocks. Security concerns related to trusting miners are also discussed. Another member proposes a more gradual approach to the block size increase with a longer grace period. Pieter Wuille raises the question of what would have happened if Bitcoin had started with 8MB blocks. He suggests a compromise between BIP101 and BIP103 with a gradual increase in block size based on technology growth. The text discusses various solutions for internet service and the need for independent full nodes to maintain decentralization. Adam Back expresses concern about the trustworthiness of data-center operators and highlights the importance of understanding decentralization. The argument for decentralization security and the reality of trusting data centers are discussed. The decentralized nature of data centers and hosting providers is highlighted, as well as the difficulty for authorities to conduct widescale attacks on nodes. The email thread also discusses the security reality of hosting anything intended to be secure via decentralization or hosting in general and proposes a compromise between BIP101 and BIP103. The proposal suggests gradual growth in the block size over time and the importance of a fee market and the value of secondary layers.The article discusses the challenges of running a full node for Bitcoin in countries with repressive governments. The author argues that trusting data centers to run verified code without being hacked and responsive to court orders is delusional. Data center operators are bound to follow laws, including NSLs and gag orders, which could compromise the security of Bitcoin. However, one could establish multiple full nodes all over the world, including in offshore VPS, to ensure decentralization and avoid geopolitical risks. The email thread discusses the issue of trust in data centers and their ability to run verified code, avoid being hacked, filter traffic, and respond to court orders without notifying users. The reality of data center security breaches and policy attacks is highlighted with references to Snowden disclosures and the need for awareness of security. A compromise proposal is presented regarding the block size limit increase in Bitcoin, with details on initiation, starting date, and gradual increase in block size over a period of 16 months. The rationale behind each parameter is explained, including SSD price reduction and global bandwidth growth predictions. The author also comments on the need for a fee market but cautions against excessive fee pressure at this time when the block reward is still the main income source for miners. Finally, the author emphasizes the importance of increasing the underlying settlement system's capacity before building secondary layers such as Lightning Network.The email proposes a compromise between Gavin's BIP101 and Pieter's proposal, BIP103. The author suggests initiation through BIP34 style voting with support from 750 out of the last 1000 blocks and using the "hardfork bit" mechanism. The starting date is proposed to be 30 days after 75% miner support but not before 2016-01-12 00:00 UTC. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by 1.414213 by every 2^23 seconds until exactly 8MB is reached on 2017-05-11. After 8MB is reached, the block size will be increased by 6.714% every 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or double every 2.9 years, or +27.67% per year. The final cap is set at 4096MB on 2042-11-17.The author suggests a faster growth in the beginning to normalize the block size and a new optimal size based on current adoption and technology. They also agree that Bitcoin needs a fee market, but the fee pressure must not be too high at this moment as the block reward is still the miner's main income source. The author respects everyone building secondary layers over the blockchain. However, they believe that if the underlying settlement system does not have enough capacity, any secondary layer built on it will fall apart. Finally, the value of secondary layers primarily comes from instant confirmation, not scarcity of block space. 2015-08-02T22:07:22+00:00 + The email thread discusses proposed changes to the block size and deployment period for Bitcoin. One party suggests a starting date for the block size 30 days after 75% miner support but not before January 12, 2016. The block size will gradually increase over 16 months until it reaches 8MB on May 11, 2017. Chinese miners agree with this proposal. However, there is disagreement on whether we can currently handle larger blocks. Security concerns related to trusting miners are also discussed. Another member proposes a more gradual approach to the block size increase with a longer grace period. Pieter Wuille raises the question of what would have happened if Bitcoin had started with 8MB blocks. He suggests a compromise between BIP101 and BIP103 with a gradual increase in block size based on technology growth. The text discusses various solutions for internet service and the need for independent full nodes to maintain decentralization. Adam Back expresses concern about the trustworthiness of data-center operators and highlights the importance of understanding decentralization. The argument for decentralization security and the reality of trusting data centers are discussed. The decentralized nature of data centers and hosting providers is highlighted, as well as the difficulty for authorities to conduct widescale attacks on nodes. The email thread also discusses the security reality of hosting anything intended to be secure via decentralization or hosting in general and proposes a compromise between BIP101 and BIP103. The proposal suggests gradual growth in the block size over time and the importance of a fee market and the value of secondary layers.The article discusses the challenges of running a full node for Bitcoin in countries with repressive governments. The author argues that trusting data centers to run verified code without being hacked and responsive to court orders is delusional. Data center operators are bound to follow laws, including NSLs and gag orders, which could compromise the security of Bitcoin. However, one could establish multiple full nodes all over the world, including in offshore VPS, to ensure decentralization and avoid geopolitical risks. The email thread discusses the issue of trust in data centers and their ability to run verified code, avoid being hacked, filter traffic, and respond to court orders without notifying users. The reality of data center security breaches and policy attacks is highlighted with references to Snowden disclosures and the need for awareness of security. A compromise proposal is presented regarding the block size limit increase in Bitcoin, with details on initiation, starting date, and gradual increase in block size over a period of 16 months. The rationale behind each parameter is explained, including SSD price reduction and global bandwidth growth predictions. The author also comments on the need for a fee market but cautions against excessive fee pressure at this time when the block reward is still the main income source for miners. Finally, the author emphasizes the importance of increasing the underlying settlement system's capacity before building secondary layers such as Lightning Network.The email proposes a compromise between Gavin's BIP101 and Pieter's proposal, BIP103. The author suggests initiation through BIP34 style voting with support from 750 out of the last 1000 blocks and using the "hardfork bit" mechanism. The starting date is proposed to be 30 days after 75% miner support but not before 2016-01-12 00:00 UTC. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by 1.414213 by every 2^23 seconds until exactly 8MB is reached on 2017-05-11. After 8MB is reached, the block size will be increased by 6.714% every 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or double every 2.9 years, or +27.67% per year. The final cap is set at 4096MB on 2042-11-17.The author suggests a faster growth in the beginning to normalize the block size and a new optimal size based on current adoption and technology. They also agree that Bitcoin needs a fee market, but the fee pressure must not be too high at this moment as the block reward is still the miner's main income source. The author respects everyone building secondary layers over the blockchain. However, they believe that if the underlying settlement system does not have enough capacity, any secondary layer built on it will fall apart. Finally, the value of secondary layers primarily comes from instant confirmation, not scarcity of block space. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_A-possible-solution-for-the-block-size-limit-Detection-and-rejection-of-bloated-blocks-by-full-nodes-.xml b/static/bitcoin-dev/July_2015/combined_A-possible-solution-for-the-block-size-limit-Detection-and-rejection-of-bloated-blocks-by-full-nodes-.xml index a722da4845..973236c873 100644 --- a/static/bitcoin-dev/July_2015/combined_A-possible-solution-for-the-block-size-limit-Detection-and-rejection-of-bloated-blocks-by-full-nodes-.xml +++ b/static/bitcoin-dev/July_2015/combined_A-possible-solution-for-the-block-size-limit-Detection-and-rejection-of-bloated-blocks-by-full-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes. - 2023-08-01T14:10:55.687060+00:00 + 2025-10-11T22:02:22.603929+00:00 + python-feedgen Jeremy 2015-07-01 02:52:16+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes. - 2023-08-01T14:10:55.687060+00:00 + 2025-10-11T22:02:22.604062+00:00 - A proposal has been made to phase shift transaction fees by one block in order to prevent miners from putting in a bunch of transactions for free. The idea is that a miner would orphan a block that didn't properly reward them, making it very costly for the miner to do so. The phase can be adjusted to different amounts and spread over multiple blocks or even randomly selected at the time of mining from a pool of un-fee claimed blocks. However, this approach requires 100% mempool synchronization across all nodes on the network to reject a particular block. Otherwise, an attempted double spend could result in a fork in the network because some nodes saw it and some did not.The block size debate centers around the concern that if the block size is increased, malicious miners may publish unreasonably large "bloated" blocks. A solution proposed to detect these bloated blocks is to set a threshold by nodes on the allowable number of non-mempool transactions allowed in a solved block (e.g., maybe 50%). If a block contains more than this threshold of non-mempool transactions, it is rejected. The proposal states that if this idea works, the block size limitation could be completely removed. 2015-07-01T02:52:16+00:00 + A proposal has been made to phase shift transaction fees by one block in order to prevent miners from putting in a bunch of transactions for free. The idea is that a miner would orphan a block that didn't properly reward them, making it very costly for the miner to do so. The phase can be adjusted to different amounts and spread over multiple blocks or even randomly selected at the time of mining from a pool of un-fee claimed blocks. However, this approach requires 100% mempool synchronization across all nodes on the network to reject a particular block. Otherwise, an attempted double spend could result in a fork in the network because some nodes saw it and some did not.The block size debate centers around the concern that if the block size is increased, malicious miners may publish unreasonably large "bloated" blocks. A solution proposed to detect these bloated blocks is to set a threshold by nodes on the allowable number of non-mempool transactions allowed in a solved block (e.g., maybe 50%). If a block contains more than this threshold of non-mempool transactions, it is rejected. The proposal states that if this idea works, the block size limitation could be completely removed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_About-hardware-accelerators-advantages-for-full-node-not-mining-.xml b/static/bitcoin-dev/July_2015/combined_About-hardware-accelerators-advantages-for-full-node-not-mining-.xml index a4fedd70d7..269ff19591 100644 --- a/static/bitcoin-dev/July_2015/combined_About-hardware-accelerators-advantages-for-full-node-not-mining-.xml +++ b/static/bitcoin-dev/July_2015/combined_About-hardware-accelerators-advantages-for-full-node-not-mining-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - About hardware accelerators advantages for full-node (not mining) - 2023-08-01T14:17:51.532144+00:00 + 2025-10-11T22:02:31.104322+00:00 + python-feedgen Tier Nolan 2015-07-13 13:47:57+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - About hardware accelerators advantages for full-node (not mining) - 2023-08-01T14:17:51.532144+00:00 + 2025-10-11T22:02:31.104542+00:00 - The processor load for signature verification in Bitcoin involves several operations, including a hash function call, large number maths, and an elliptic curve operation. The longest and most time-consuming step is the elliptic curve operation, which takes about 1ms per signature on normal hardware. However, there is optimized code available that can speed up this process.The core team has created a fast CPU implementation for signature verification, which can be found at https://github.com/bitcoin/secp256k1.git. There has also been discussion about batch verification of signatures, with the potential to compute multiple signatures together. However, it is believed that using a GPU for this purpose would not be beneficial due to communication bandwidth limitations. GPU miners typically benefit from minimal information being sent to the GPU routine.The user is considering using a Jetson TK1, a GPU-powered development board, as a power-efficient full node for Bitcoin. They plan to run bitcoind on the Jetson to achieve high performance-per-watt, as running a pure-CPU implementation of bitcoind would heavily burden the CPU. The user believes that there are computationally intensive and highly parallel functions in Bitcoin that could be outsourced to a GPU. They are interested in potentially forking or contributing to these functions, but they would like to gather opinions on the feasibility of their idea and the recommended configuration before proceeding with coding. Although the user has more background in parallel programming than in the Bitcoin protocol, they want to avoid creating a messy implementation. 2015-07-13T13:47:57+00:00 + The processor load for signature verification in Bitcoin involves several operations, including a hash function call, large number maths, and an elliptic curve operation. The longest and most time-consuming step is the elliptic curve operation, which takes about 1ms per signature on normal hardware. However, there is optimized code available that can speed up this process.The core team has created a fast CPU implementation for signature verification, which can be found at https://github.com/bitcoin/secp256k1.git. There has also been discussion about batch verification of signatures, with the potential to compute multiple signatures together. However, it is believed that using a GPU for this purpose would not be beneficial due to communication bandwidth limitations. GPU miners typically benefit from minimal information being sent to the GPU routine.The user is considering using a Jetson TK1, a GPU-powered development board, as a power-efficient full node for Bitcoin. They plan to run bitcoind on the Jetson to achieve high performance-per-watt, as running a pure-CPU implementation of bitcoind would heavily burden the CPU. The user believes that there are computationally intensive and highly parallel functions in Bitcoin that could be outsourced to a GPU. They are interested in potentially forking or contributing to these functions, but they would like to gather opinions on the feasibility of their idea and the recommended configuration before proceeding with coding. Although the user has more background in parallel programming than in the Bitcoin protocol, they want to avoid creating a messy implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Another-block-size-limit-solution-dynamic-block-size-limit-.xml b/static/bitcoin-dev/July_2015/combined_Another-block-size-limit-solution-dynamic-block-size-limit-.xml index 1b59c518f7..dd8f14c2bb 100644 --- a/static/bitcoin-dev/July_2015/combined_Another-block-size-limit-solution-dynamic-block-size-limit-.xml +++ b/static/bitcoin-dev/July_2015/combined_Another-block-size-limit-solution-dynamic-block-size-limit-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Another block size limit solution - dynamic block size limit. - 2023-08-01T14:49:09.056658+00:00 + 2025-10-11T22:01:10.286478+00:00 + python-feedgen Tom Harding 2015-07-31 02:02:14+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Another block size limit solution - dynamic block size limit. - 2023-08-01T14:49:09.056658+00:00 + 2025-10-11T22:01:10.286608+00:00 - In 2015, Максим Божко put forward a proposal for the implementation of a dynamic block size limit for bitcoin. This proposal suggests adjusting the block size based on recent block sizes, giving miners the ability to determine the trajectory of block sizes. However, there are concerns that this approach could result in a decrease in the number of nodes capable of keeping up with the network, as well as a potential reduction in decentralization due to the more powerful equipment of miners.It is worth noting that discussions on this topic have taken place previously, although finding these discussions can be challenging due to the high volume of traffic on the list. For those interested in delving into the details of the proposal, a Google document has been provided in the email, which contains comprehensive information. Furthermore, Maksim Bozhko has also made it possible for individuals to provide comments on the proposal, allowing for a collaborative and inclusive approach to the discussion surrounding the implementation of a dynamic block size limit. 2015-07-31T02:02:14+00:00 + In 2015, Максим Божко put forward a proposal for the implementation of a dynamic block size limit for bitcoin. This proposal suggests adjusting the block size based on recent block sizes, giving miners the ability to determine the trajectory of block sizes. However, there are concerns that this approach could result in a decrease in the number of nodes capable of keeping up with the network, as well as a potential reduction in decentralization due to the more powerful equipment of miners.It is worth noting that discussions on this topic have taken place previously, although finding these discussions can be challenging due to the high volume of traffic on the list. For those interested in delving into the details of the proposal, a Google document has been provided in the email, which contains comprehensive information. Furthermore, Maksim Bozhko has also made it possible for individuals to provide comments on the proposal, allowing for a collaborative and inclusive approach to the discussion surrounding the implementation of a dynamic block size limit. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP-102-kick-the-can-down-the-road-to-2MB.xml b/static/bitcoin-dev/July_2015/combined_BIP-102-kick-the-can-down-the-road-to-2MB.xml index 66000b5f1b..b1c524031a 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP-102-kick-the-can-down-the-road-to-2MB.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP-102-kick-the-can-down-the-road-to-2MB.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 102 - kick the can down the road to 2MB - 2023-08-01T14:23:51.505430+00:00 + 2025-10-11T22:00:59.673110+00:00 + python-feedgen Slurms MacKenzie 2015-07-24 09:43:00+00:00 @@ -119,13 +120,13 @@ - python-feedgen + 2 Combined summary - BIP 102 - kick the can down the road to 2MB - 2023-08-01T14:23:51.505430+00:00 + 2025-10-11T22:00:59.673324+00:00 - In a discussion on the Bitcoin developer mailing list, developers debated the merits of using block height versus median time for determining maximum block size. Some argued that block height was simpler, while others suggested median time would be more "human-schedule-friendly." The conversation ended with a request to move the discussion to a separate thread regarding an uncontroversial hardfork.Peter Todd criticized Jeff Garzik's proposed 2MB hard fork patch, accusing him of pushing for better solutions with a bad patch. Garzik defended his proposal, stating that 2MB had the most consensus and could provide valuable field data. He also mentioned that the 2MB cap could serve as a fallback option if consensus couldn't be reached on a larger solution.Another discussion focused on the security implications of a supermajority of miners not supporting a proposed block size increase. Peter Todd warned that without miner support, the chain would be insecure and susceptible to attacks. He proposed a solution to prevent reorg by requiring the first block after a predetermined time to be version 0 or larger than 1MB. This approach wouldn't require additional exceptions in consensus rules but might be troublesome in coding.Peter Todd accused Jeff Garzik of proposing a bad patch to motivate others to write better solutions, but others disagreed, suggesting that Garzik may be proposing the change to spur discussion. The discussion focused on whether preventing bad patches from being proposed was beneficial or detrimental to Bitcoin's development.Peter Todd discussed concerns about the allocation of BIP numbers and expressed concerns about allocating them for "stupid ideas" to avoid gatekeeping. The discussion also touched on using block height versus time in the Bitcoin protocol, with some arguing for simplicity and others advocating for predictability through the median time mechanism. BIP102, which proposed a block size limit increase, was criticized for its design and potential risks.Luke Dashjr expressed his opinion that hard forks should require consensus among nodes rather than a majority vote among miners. Another member agreed and suggested that new hard fork proposals using a voting system may not want to establish the precedent of relying on a vote.Jeff Garzik proposed a new Bitcoin Improvement Proposal (BIP) as a backup plan to his preferred proposal (BIP 100). The BIP aimed to provide a minimum viable alternative plan if an agreement couldn't be reached on a more comprehensive solution. Chris Wardell proposed a dynamic solution to increase the block size every 100k blocks (~2 years) as a backup plan, with Ross Nicoll supporting the idea. There was also support for a temporary solution of increasing the block size to 2MB while a permanent solution is sought.In an email conversation, Tier Nolan mentioned that the block and transaction sizes are no longer linked together, allowing for greater flexibility in the Bitcoin network.Overall, there are various discussions and proposals regarding hard forks and block size increases in Bitcoin, aiming to find a solution that allows for organic growth and scalability while considering factors such as privacy, security, centralization, and transaction throughput. 2015-07-24T09:43:00+00:00 + In a discussion on the Bitcoin developer mailing list, developers debated the merits of using block height versus median time for determining maximum block size. Some argued that block height was simpler, while others suggested median time would be more "human-schedule-friendly." The conversation ended with a request to move the discussion to a separate thread regarding an uncontroversial hardfork.Peter Todd criticized Jeff Garzik's proposed 2MB hard fork patch, accusing him of pushing for better solutions with a bad patch. Garzik defended his proposal, stating that 2MB had the most consensus and could provide valuable field data. He also mentioned that the 2MB cap could serve as a fallback option if consensus couldn't be reached on a larger solution.Another discussion focused on the security implications of a supermajority of miners not supporting a proposed block size increase. Peter Todd warned that without miner support, the chain would be insecure and susceptible to attacks. He proposed a solution to prevent reorg by requiring the first block after a predetermined time to be version 0 or larger than 1MB. This approach wouldn't require additional exceptions in consensus rules but might be troublesome in coding.Peter Todd accused Jeff Garzik of proposing a bad patch to motivate others to write better solutions, but others disagreed, suggesting that Garzik may be proposing the change to spur discussion. The discussion focused on whether preventing bad patches from being proposed was beneficial or detrimental to Bitcoin's development.Peter Todd discussed concerns about the allocation of BIP numbers and expressed concerns about allocating them for "stupid ideas" to avoid gatekeeping. The discussion also touched on using block height versus time in the Bitcoin protocol, with some arguing for simplicity and others advocating for predictability through the median time mechanism. BIP102, which proposed a block size limit increase, was criticized for its design and potential risks.Luke Dashjr expressed his opinion that hard forks should require consensus among nodes rather than a majority vote among miners. Another member agreed and suggested that new hard fork proposals using a voting system may not want to establish the precedent of relying on a vote.Jeff Garzik proposed a new Bitcoin Improvement Proposal (BIP) as a backup plan to his preferred proposal (BIP 100). The BIP aimed to provide a minimum viable alternative plan if an agreement couldn't be reached on a more comprehensive solution. Chris Wardell proposed a dynamic solution to increase the block size every 100k blocks (~2 years) as a backup plan, with Ross Nicoll supporting the idea. There was also support for a temporary solution of increasing the block size to 2MB while a permanent solution is sought.In an email conversation, Tier Nolan mentioned that the block and transaction sizes are no longer linked together, allowing for greater flexibility in the Bitcoin network.Overall, there are various discussions and proposals regarding hard forks and block size increases in Bitcoin, aiming to find a solution that allows for organic growth and scalability while considering factors such as privacy, security, centralization, and transaction throughput. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP-68-Questions.xml b/static/bitcoin-dev/July_2015/combined_BIP-68-Questions.xml index f4fc22c015..312084dc2e 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP-68-Questions.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP-68-Questions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 68 Questions - 2023-08-01T14:11:47.694357+00:00 + 2025-10-11T22:01:50.681334+00:00 + python-feedgen Rusty Russell 2015-07-03 01:19:16+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP 68 Questions - 2023-08-01T14:11:47.694357+00:00 + 2025-10-11T22:01:50.681538+00:00 - Rusty Russell initially messaged Mark, stating that the code in BIP 68 compared the input's nSequence with the transaction's nLockTime. However, Rusty later admitted that he had misinterpreted the code and acknowledged his mistake. Mark promptly clarified the situation to Rusty offlist and assured him that the code was working correctly. In response, Rusty expressed his gratitude to Mark for the clarification and conveyed his satisfaction about the proper functioning of the code.The code in question pertains to BIP 68, which involves comparing the nSequence of the input with the nLockTime of the transaction. In cases where a transaction spends the output of another transaction already present in the blockchain, there is no need for a relative locktime. This is because the time of the previous transaction is already known. However, if the transaction is not yet included in the blockchain, its creation becomes problematic as the value required to set nLockTime remains unknown. Considering this predicament, Rusty sought clarification on how the functionality was intended to work. 2015-07-03T01:19:16+00:00 + Rusty Russell initially messaged Mark, stating that the code in BIP 68 compared the input's nSequence with the transaction's nLockTime. However, Rusty later admitted that he had misinterpreted the code and acknowledged his mistake. Mark promptly clarified the situation to Rusty offlist and assured him that the code was working correctly. In response, Rusty expressed his gratitude to Mark for the clarification and conveyed his satisfaction about the proper functioning of the code.The code in question pertains to BIP 68, which involves comparing the nSequence of the input with the nLockTime of the transaction. In cases where a transaction spends the output of another transaction already present in the blockchain, there is no need for a relative locktime. This is because the time of the previous transaction is already known. However, if the transaction is not yet included in the blockchain, its creation becomes problematic as the value required to set nLockTime remains unknown. Considering this predicament, Rusty sought clarification on how the functionality was intended to work. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP-68-Relative-Locktime-bug.xml b/static/bitcoin-dev/July_2015/combined_BIP-68-Relative-Locktime-bug.xml index 7b536b8c1b..a165f1d6bd 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP-68-Relative-Locktime-bug.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP-68-Relative-Locktime-bug.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 68 (Relative Locktime) bug - 2023-08-01T14:14:18.608842+00:00 + 2025-10-11T22:01:46.433063+00:00 + python-feedgen Tom Harding 2015-07-05 19:57:00+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP 68 (Relative Locktime) bug - 2023-08-01T14:14:18.608842+00:00 + 2025-10-11T22:01:46.433231+00:00 - In July 2015, Tom Harding proposed the idea of allowing an explicit relative locktime of 0 in transactions to prevent accidental finalization of the entire transaction when only intending to exclude a relative locktime on one input. Although Harding initially overlooked that other inputs can independently make the transaction non-final, the proposal still has potential benefits for certain use cases.Harding's proposal suggests shifting the semantics of nSequence in BIP 68, which currently requires at least one input to be mined ahead of its parent for a transaction to have an effective nLocktime. The proposed solution involves using MAX_INT - 1 to specify 0 relative locktime instead of 1. This change would avoid the inversion and put relative locktimes outside the realm of both the MAX_INT and MAX_INT - 1 values. It would also allow applications to avoid accidentally finalizing the whole transaction when they only meant to exclude a relative locktime on one input.Mark Friedenbach suggested that Bitcoin Core post-0.11 switch to using 0 in the sequence number field instead of MAX_INT - 1 for cases where an effective nLocktime is desired without requiring at least one input to be mined ahead of its parent.The proposal aims to fix the issue with BIP 68's use of nSequence to specify relative locktime. Currently, nSequence conditions the transaction-level locktime, making it impossible for a transaction to have an effective nLocktime without at least one input being mined ahead of its parent. Shifting the semantics so that nSequence = MAX_INT - 1 specifies 0 relative locktime instead of 1 would address this problem. The proposed change would also preserve the semantics of transactions already created with the specific nSequence value of MAX_INT - 1. Bitcoin Core may implement this change for cases where the sequence number field is set to 0.Developers on the bitcoin-dev mailing list discussed the issue of locktime in transactions and its impact on fee sniping. They also requested examples and use cases where enforced locktime would be needed in transactions with unconfirmed inputs. The conversation then focused on the use of nSequence to specify relative locktime and the need to shift its semantics to allow for an effective nLocktime without requiring mined inputs. This ongoing discussion demonstrates the efforts of bitcoin developers to enhance the functionality and security of the cryptocurrency's transaction process.Overall, Tom Harding proposed a fix for the issue of enforced lock time in transactions with unconfirmed inputs. The proposal suggests shifting the semantics of nSequence in BIP 68 to specify 0 relative locktime instead of 1. This change would address the problem of a transaction not having an effective nLocktime without requiring at least one input to be mined ahead of its parent. Bitcoin Core may implement this change to improve the transaction process. 2015-07-05T19:57:00+00:00 + In July 2015, Tom Harding proposed the idea of allowing an explicit relative locktime of 0 in transactions to prevent accidental finalization of the entire transaction when only intending to exclude a relative locktime on one input. Although Harding initially overlooked that other inputs can independently make the transaction non-final, the proposal still has potential benefits for certain use cases.Harding's proposal suggests shifting the semantics of nSequence in BIP 68, which currently requires at least one input to be mined ahead of its parent for a transaction to have an effective nLocktime. The proposed solution involves using MAX_INT - 1 to specify 0 relative locktime instead of 1. This change would avoid the inversion and put relative locktimes outside the realm of both the MAX_INT and MAX_INT - 1 values. It would also allow applications to avoid accidentally finalizing the whole transaction when they only meant to exclude a relative locktime on one input.Mark Friedenbach suggested that Bitcoin Core post-0.11 switch to using 0 in the sequence number field instead of MAX_INT - 1 for cases where an effective nLocktime is desired without requiring at least one input to be mined ahead of its parent.The proposal aims to fix the issue with BIP 68's use of nSequence to specify relative locktime. Currently, nSequence conditions the transaction-level locktime, making it impossible for a transaction to have an effective nLocktime without at least one input being mined ahead of its parent. Shifting the semantics so that nSequence = MAX_INT - 1 specifies 0 relative locktime instead of 1 would address this problem. The proposed change would also preserve the semantics of transactions already created with the specific nSequence value of MAX_INT - 1. Bitcoin Core may implement this change for cases where the sequence number field is set to 0.Developers on the bitcoin-dev mailing list discussed the issue of locktime in transactions and its impact on fee sniping. They also requested examples and use cases where enforced locktime would be needed in transactions with unconfirmed inputs. The conversation then focused on the use of nSequence to specify relative locktime and the need to shift its semantics to allow for an effective nLocktime without requiring mined inputs. This ongoing discussion demonstrates the efforts of bitcoin developers to enhance the functionality and security of the cryptocurrency's transaction process.Overall, Tom Harding proposed a fix for the issue of enforced lock time in transactions with unconfirmed inputs. The proposal suggests shifting the semantics of nSequence in BIP 68 to specify 0 relative locktime instead of 1. This change would address the problem of a transaction not having an effective nLocktime without requiring at least one input to be mined ahead of its parent. Bitcoin Core may implement this change to improve the transaction process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP-Draft-Minimum-Viable-TXIn-Hash.xml b/static/bitcoin-dev/July_2015/combined_BIP-Draft-Minimum-Viable-TXIn-Hash.xml index a4a6377842..e86580dca1 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP-Draft-Minimum-Viable-TXIn-Hash.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP-Draft-Minimum-Viable-TXIn-Hash.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Draft: Minimum Viable TXIn Hash - 2023-08-01T14:35:40.526436+00:00 + 2025-10-11T22:01:27.322580+00:00 + python-feedgen Jorge Timón 2015-07-25 22:05:28+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP Draft: Minimum Viable TXIn Hash - 2023-08-01T14:35:40.526436+00:00 + 2025-10-11T22:01:27.322716+00:00 - On July 23, 2015, Jeremy Rubin introduced a Bitcoin Improvement Proposal (BIP) aimed at reducing the number of bytes required for each transaction. This proposal, which can be found on Github, has the potential to decrease transaction sizes by approximately 12% for standard "one in two out" transactions and potentially even more for transactions with multiple input hashes.The proposed changes are intended to optimize the peer-to-peer protocol and could be implemented as a soft fork. However, Luke pointed out that more specific documentation is needed to fully understand the suggested protocol changes. Despite this, it seems that the implementation of these changes may not require a soft fork.The BIP is still in its early stages, and there are various design options available for this type of improvement. It is important to note that some people found the cultural analogy used to explain the technical process, known as the "Txid Hokey Pokey," confusing. As a result, there have been requests for a more neutral explanation of the proposed consensus change.One aspect that remains uncertain is how the introduction of a "compact tx" would result in a different hash compared to a non-compact one. This uncertainty highlights the need for further documentation and exploration of the proposed changes before they can be fully implemented.Overall, the draft BIP aims to reduce the amount of data required per transaction in order to improve efficiency within the Bitcoin network. While the proposal is still being developed, it offers the potential for significant reductions in transaction sizes, particularly for certain types of transactions. 2015-07-25T22:05:28+00:00 + On July 23, 2015, Jeremy Rubin introduced a Bitcoin Improvement Proposal (BIP) aimed at reducing the number of bytes required for each transaction. This proposal, which can be found on Github, has the potential to decrease transaction sizes by approximately 12% for standard "one in two out" transactions and potentially even more for transactions with multiple input hashes.The proposed changes are intended to optimize the peer-to-peer protocol and could be implemented as a soft fork. However, Luke pointed out that more specific documentation is needed to fully understand the suggested protocol changes. Despite this, it seems that the implementation of these changes may not require a soft fork.The BIP is still in its early stages, and there are various design options available for this type of improvement. It is important to note that some people found the cultural analogy used to explain the technical process, known as the "Txid Hokey Pokey," confusing. As a result, there have been requests for a more neutral explanation of the proposed consensus change.One aspect that remains uncertain is how the introduction of a "compact tx" would result in a different hash compared to a non-compact one. This uncertainty highlights the need for further documentation and exploration of the proposed changes before they can be fully implemented.Overall, the draft BIP aims to reduce the amount of data required per transaction in order to improve efficiency within the Bitcoin network. While the proposal is still being developed, it offers the potential for significant reductions in transaction sizes, particularly for certain types of transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP-Process-and-Votes.xml b/static/bitcoin-dev/July_2015/combined_BIP-Process-and-Votes.xml index 1279923890..61f7fcb738 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP-Process-and-Votes.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP-Process-and-Votes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Process and Votes - 2023-08-01T13:51:59.523410+00:00 + 2025-10-11T22:02:01.315179+00:00 + python-feedgen odinn 2015-07-01 22:34:01+00:00 @@ -207,13 +208,13 @@ - python-feedgen + 2 Combined summary - BIP Process and Votes - 2023-08-01T13:51:59.525411+00:00 + 2025-10-11T22:02:01.315505+00:00 - The discussion on the Bitcoin-dev mailing list revolves around the process of hard forks and soft forks in Bitcoin. One suggestion is to have regularly scheduled hard forks with cut-off dates for BIP submissions to avoid debates and disagreements. It is mentioned that there is a defined process for soft forks, but not for hard forks, which can lead to issues of consensus. The fundamental problem is the lack of agreement on the block size.There is also a discussion about users expecting changes that would require a hard fork and the responsibility of core maintainers. In response to the discussion, suggestions are made to create a living document of risks and mitigations as well as a decentralization metric to measure proposed changes. There is a proposal for a second mailing list called "bitcoin-process" to educate people about the Bitcoin process, along with a FAQ on its sign-up page. Concerns are raised about the development of a new FAQ, as it may be controlled by a small group and present unrealistic claims. Criticism is also directed towards the Bitcoin wiki, which contains incorrect information and cult-like claims.The power dynamics within the Bitcoin community are discussed, particularly between developers, miners, users, merchants, and exchanges. There is a debate over who has control over the consensus rules, and concerns are raised about veto power held by developers with minimal stake in Bitcoin holdings. The need for a formal process for making decisions and deploying controversial changes is highlighted. The discussion ends with links to the Bitcoin-dev mailing list, emphasizing the importance of community involvement in decision-making processes.In another email thread, the role of Core Maintainer in managing the Bitcoin Core project is discussed. The discussion focuses on the ethical position of taking the safest option versus the majority's preference. Concerns are raised about potential lose-lose scenarios and the lack of mechanisms for resolving disagreements.The issue of power dynamics in bitcoin development decision-making is debated, with arguments about the influence of core developers and the vulnerability of the Bitcoin software development system. Suggestions are made for developing a process that does not rely on unwritten rules or one person's decision-making power. The importance of seeking consensus and maintaining decentralization is emphasized.The discussion brings attention to the fact that the Core Maintainer does not have more power than other individuals with GitHub commit privileges. Changes to the code must reach technical consensus before being merged. The official release of Bitcoin has significant power and control, leading to lobbying efforts for changes. Concerns are raised about the lack of mechanisms for deploying controversial changes to the consensus rules.Overall, the Bitcoin developer mailing list serves as a platform for discussions on power dynamics, decision-making processes, and the maintenance of Bitcoin Core. The need for community involvement and consensus in decision-making is acknowledged, along with the challenges posed by power dynamics within the community.Another email thread discusses the process of determining the block size limit and whether there is any consensus on it. Milly Bitcoin replied that there is no agreement on the block size limit and it has become a topic of debate. She suggested that regularly scheduled hard forks could be planned with cut-off dates for BIP submissions to avoid debates over whether there should be hard forks and what should be contained within them. She also proposed adding a step after "Dev acceptance" in the BIP process to include input from merchants, exchanges, miners, and users. The goal is to find a middle ground and move forward with an agreed-upon approach. Another participant in the conversation explained that if Satoshi had stated that 1MB was part of the definition of Bitcoin, people would accept it to the same extent as they accept the 21 million coin limit. However, there is no defined process for hard forks, which can result in a mutual veto. Both sides of the block size debate argue that their position should be considered the status quo.In response to this discussion, another participant suggests creating a living document of risks and mitigations as well as a decentralization metric to measure proposed changes. They also propose the creation of a second mailing list called "bitcoin-process" to educate people about the Bitcoin process, along with a FAQ on its sign-up page. However, concerns are raised about the development of a new FAQ, as it may be controlled by a small group and present unrealistic claims. Criticism is also directed towards the Bitcoin wiki, which contains incorrect information and cult-like claims.The power dynamics within the Bitcoin community are also debated, particularly between developers, miners, users, merchants, and exchanges. There is a debate over who has control over the consensus rules, and concerns are raised about veto power held by developers with minimal stake in Bitcoin holdings. The need for a formal process for making decisions and deploying controversial changes is highlighted. The discussion ends with links to the Bitcoin-dev mailing list, emphasizing the importance of community involvement in decision-making processes.In another email thread, the role of Core Maintainer in managing the Bitcoin Core project is discussed. The discussion focuses on the ethical position of taking the safest option versus the majority's preference 2015-07-01T22:34:01+00:00 + The discussion on the Bitcoin-dev mailing list revolves around the process of hard forks and soft forks in Bitcoin. One suggestion is to have regularly scheduled hard forks with cut-off dates for BIP submissions to avoid debates and disagreements. It is mentioned that there is a defined process for soft forks, but not for hard forks, which can lead to issues of consensus. The fundamental problem is the lack of agreement on the block size.There is also a discussion about users expecting changes that would require a hard fork and the responsibility of core maintainers. In response to the discussion, suggestions are made to create a living document of risks and mitigations as well as a decentralization metric to measure proposed changes. There is a proposal for a second mailing list called "bitcoin-process" to educate people about the Bitcoin process, along with a FAQ on its sign-up page. Concerns are raised about the development of a new FAQ, as it may be controlled by a small group and present unrealistic claims. Criticism is also directed towards the Bitcoin wiki, which contains incorrect information and cult-like claims.The power dynamics within the Bitcoin community are discussed, particularly between developers, miners, users, merchants, and exchanges. There is a debate over who has control over the consensus rules, and concerns are raised about veto power held by developers with minimal stake in Bitcoin holdings. The need for a formal process for making decisions and deploying controversial changes is highlighted. The discussion ends with links to the Bitcoin-dev mailing list, emphasizing the importance of community involvement in decision-making processes.In another email thread, the role of Core Maintainer in managing the Bitcoin Core project is discussed. The discussion focuses on the ethical position of taking the safest option versus the majority's preference. Concerns are raised about potential lose-lose scenarios and the lack of mechanisms for resolving disagreements.The issue of power dynamics in bitcoin development decision-making is debated, with arguments about the influence of core developers and the vulnerability of the Bitcoin software development system. Suggestions are made for developing a process that does not rely on unwritten rules or one person's decision-making power. The importance of seeking consensus and maintaining decentralization is emphasized.The discussion brings attention to the fact that the Core Maintainer does not have more power than other individuals with GitHub commit privileges. Changes to the code must reach technical consensus before being merged. The official release of Bitcoin has significant power and control, leading to lobbying efforts for changes. Concerns are raised about the lack of mechanisms for deploying controversial changes to the consensus rules.Overall, the Bitcoin developer mailing list serves as a platform for discussions on power dynamics, decision-making processes, and the maintenance of Bitcoin Core. The need for community involvement and consensus in decision-making is acknowledged, along with the challenges posed by power dynamics within the community.Another email thread discusses the process of determining the block size limit and whether there is any consensus on it. Milly Bitcoin replied that there is no agreement on the block size limit and it has become a topic of debate. She suggested that regularly scheduled hard forks could be planned with cut-off dates for BIP submissions to avoid debates over whether there should be hard forks and what should be contained within them. She also proposed adding a step after "Dev acceptance" in the BIP process to include input from merchants, exchanges, miners, and users. The goal is to find a middle ground and move forward with an agreed-upon approach. Another participant in the conversation explained that if Satoshi had stated that 1MB was part of the definition of Bitcoin, people would accept it to the same extent as they accept the 21 million coin limit. However, there is no defined process for hard forks, which can result in a mutual veto. Both sides of the block size debate argue that their position should be considered the status quo.In response to this discussion, another participant suggests creating a living document of risks and mitigations as well as a decentralization metric to measure proposed changes. They also propose the creation of a second mailing list called "bitcoin-process" to educate people about the Bitcoin process, along with a FAQ on its sign-up page. However, concerns are raised about the development of a new FAQ, as it may be controlled by a small group and present unrealistic claims. Criticism is also directed towards the Bitcoin wiki, which contains incorrect information and cult-like claims.The power dynamics within the Bitcoin community are also debated, particularly between developers, miners, users, merchants, and exchanges. There is a debate over who has control over the consensus rules, and concerns are raised about veto power held by developers with minimal stake in Bitcoin holdings. The need for a formal process for making decisions and deploying controversial changes is highlighted. The discussion ends with links to the Bitcoin-dev mailing list, emphasizing the importance of community involvement in decision-making processes.In another email thread, the role of Core Maintainer in managing the Bitcoin Core project is discussed. The discussion focuses on the ethical position of taking the safest option versus the majority's preference - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP-Short-Term-Use-Addresses-for-Scalability.xml b/static/bitcoin-dev/July_2015/combined_BIP-Short-Term-Use-Addresses-for-Scalability.xml index 16fa828b63..edcd93eb4d 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP-Short-Term-Use-Addresses-for-Scalability.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP-Short-Term-Use-Addresses-for-Scalability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: Short Term Use Addresses for Scalability - 2023-08-01T14:29:04.113809+00:00 + 2025-10-11T22:01:57.058195+00:00 + python-feedgen Jeremy Rubin 2015-07-23 06:05:12+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - BIP: Short Term Use Addresses for Scalability - 2023-08-01T14:29:04.113809+00:00 + 2025-10-11T22:01:57.058391+00:00 - A proposed change in Bitcoin's transaction format could result in significant memory savings for the UTXO pool. Currently, a standard transaction occupies 225 bytes, but this change could potentially save up to 8.6% of space, with even greater savings for larger transactions. It is important to note that this change specifically impacts the UTXO pool's memory usage and not the overall storage size of the blockchain.However, implementing this change would require most clients to update their code, which could be a time-consuming process. Moreover, considering the modest space savings of just 10 bytes, some may question whether it is worth the effort. An alternative solution suggested by Gavin Andresen involves introducing shorter ECDSA keys, which would save more space for public keys and signatures. This approach would likely be included in the OP_MAST and require a new address type.Gavin Andresen further expressed his concerns regarding introducing a new address type, as it would necessitate widespread code changes. He argued that the potential space savings of around 5% are not significant enough to justify the extreme decrease in security, going from 2^160 to 2^80 against brute-force attacks. Instead, he proposed the use of shorter ECDSA keys, which would remain secure as long as the output value is much lower than the cost of attack.The discussion also delves into the topic of Short Term Use Addresses (STUAs) and their potential benefits. STUAs provide an incentive for reducing transaction fees, aligning with the concept that miners are paid for maintaining network security. However, there is debate about the actual savings benefit, as they may only be marginal unless margins are tight. Large players could prefer this option, while individual users may desire it. Security concerns surrounding STUAs can be mitigated by selecting LEN_PARAM during transactions to increase security. Additionally, given that these addresses are meant for short-term use only, the threat is not significant. Furthermore, STUAs offer advantages in reducing memory bloat associated with the UTXO pool.Regarding the proposal to introduce a new Bitcoin address type, Gavin Andresen and Tier Nolan both raised concerns about the challenges it poses. Nolan highlighted the need for client updates, citing the difficulties experienced during the introduction of P2SH addresses. He concluded that introducing a new address system for a modest space saving of 10 bytes, especially considering the extreme decrease in security, would not be worthwhile. Andresen echoed these sentiments, expressing his belief that introducing another Bitcoin address type is unnecessary.Jeremy Rubin contributed to the discussion by proposing a soft fork solution to increase the number of transactions per block. His proposal involves repurposing a NOP instruction with a new opcode called OP_LEFTEQUALVERIFY. This opcode would check if the leftmost L bytes of two arrays match, failing immediately if they do not, or if either array is less than L bytes, or if there are fewer than three values on the stack. Rubin acknowledges that implementing this change would require a new BIP and client updates, but it would only provide a one-time improvement in efficiency. Therefore, he suggests that this solution may not be worth the effort. Another option mentioned is using a different script engine, similar to the approach taken with P2SH.In summary, the discussions revolve around potential changes to Bitcoin's transaction format and address types. While the proposed changes could lead to memory savings in the UTXO pool, there are concerns about the effort required for widespread code updates and the trade-off between space savings and security. The debate also touches upon the benefits and considerations of Short Term Use Addresses and alternative solutions to increase the number of transactions per block. 2015-07-23T06:05:12+00:00 + A proposed change in Bitcoin's transaction format could result in significant memory savings for the UTXO pool. Currently, a standard transaction occupies 225 bytes, but this change could potentially save up to 8.6% of space, with even greater savings for larger transactions. It is important to note that this change specifically impacts the UTXO pool's memory usage and not the overall storage size of the blockchain.However, implementing this change would require most clients to update their code, which could be a time-consuming process. Moreover, considering the modest space savings of just 10 bytes, some may question whether it is worth the effort. An alternative solution suggested by Gavin Andresen involves introducing shorter ECDSA keys, which would save more space for public keys and signatures. This approach would likely be included in the OP_MAST and require a new address type.Gavin Andresen further expressed his concerns regarding introducing a new address type, as it would necessitate widespread code changes. He argued that the potential space savings of around 5% are not significant enough to justify the extreme decrease in security, going from 2^160 to 2^80 against brute-force attacks. Instead, he proposed the use of shorter ECDSA keys, which would remain secure as long as the output value is much lower than the cost of attack.The discussion also delves into the topic of Short Term Use Addresses (STUAs) and their potential benefits. STUAs provide an incentive for reducing transaction fees, aligning with the concept that miners are paid for maintaining network security. However, there is debate about the actual savings benefit, as they may only be marginal unless margins are tight. Large players could prefer this option, while individual users may desire it. Security concerns surrounding STUAs can be mitigated by selecting LEN_PARAM during transactions to increase security. Additionally, given that these addresses are meant for short-term use only, the threat is not significant. Furthermore, STUAs offer advantages in reducing memory bloat associated with the UTXO pool.Regarding the proposal to introduce a new Bitcoin address type, Gavin Andresen and Tier Nolan both raised concerns about the challenges it poses. Nolan highlighted the need for client updates, citing the difficulties experienced during the introduction of P2SH addresses. He concluded that introducing a new address system for a modest space saving of 10 bytes, especially considering the extreme decrease in security, would not be worthwhile. Andresen echoed these sentiments, expressing his belief that introducing another Bitcoin address type is unnecessary.Jeremy Rubin contributed to the discussion by proposing a soft fork solution to increase the number of transactions per block. His proposal involves repurposing a NOP instruction with a new opcode called OP_LEFTEQUALVERIFY. This opcode would check if the leftmost L bytes of two arrays match, failing immediately if they do not, or if either array is less than L bytes, or if there are fewer than three values on the stack. Rubin acknowledges that implementing this change would require a new BIP and client updates, but it would only provide a one-time improvement in efficiency. Therefore, he suggests that this solution may not be worth the effort. Another option mentioned is using a different script engine, similar to the approach taken with P2SH.In summary, the discussions revolve around potential changes to Bitcoin's transaction format and address types. While the proposed changes could lead to memory savings in the UTXO pool, there are concerns about the effort required for widespread code updates and the trade-off between space savings and security. The debate also touches upon the benefits and considerations of Short Term Use Addresses and alternative solutions to increase the number of transactions per block. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP-draft-Hardfork-bit.xml b/static/bitcoin-dev/July_2015/combined_BIP-draft-Hardfork-bit.xml index ad4e2687a5..f298748799 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP-draft-Hardfork-bit.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP-draft-Hardfork-bit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft: Hardfork bit - 2023-08-01T14:34:44.209378+00:00 + 2025-10-11T22:00:55.409455+00:00 + python-feedgen jl2012 at xbt.hk 2015-08-03 08:54:27+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - BIP draft: Hardfork bit - 2023-08-01T14:34:44.209378+00:00 + 2025-10-11T22:00:55.409597+00:00 - A proposal for a "hardfork bit" has been put forward on Github by jl2012. The proposal aims to address concerns faced by users of a fork where a small/near/fluctuating majority of mining power is supported. The sender of the message praises the proposal, stating that it provides a fallback mechanism for economic actors who can make a decision and say "we're doing this". However, there is uncertainty over how the proposal should be classified and what it should be called. Michael Ruddy has asked whether the latest version of the proposal is available on Github or elsewhere for easier collaboration.The receiver of the message discusses the possibility of multiple hardforks sharing the same flag block and how the coinbase message can prevent any potential ambiguity and provide additional information to the warning system of non-upgrading nodes. The receiver suggests that if there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The receiver also explains why the "version 0" idea is not compatible with the version bits voting system and introduces the hardfork bit BIP as an alternative.The possibility of multiple hardforks sharing the same flag block is slim but can happen. To avoid potential ambiguity, the coinbase message provides additional information to the warning system of non-upgrading nodes. If there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The "version 0" idea is not compatible with the version bits voting system, so a hardfork bit BIP was proposed instead. The commit hash of the BIP for the particular hard fork could be used in the coinbase message. This ensures that the BIP cannot specify itself what to put in the coinbase and allows specific hard fork BIPs to be updated without making code changes. The coinbase message is used to guard against one or more hard forks piggy-backing on another's flag block and to have a nicer message in the alerting system. A version 0 or a >1MB block proposal was also suggested for a block size limit hard fork. However, the >1MB flag block creates DoS banning problems, so it is not as appealing as a version 0 or this hard fork bit proposal. A version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. This is because we'd want to enforce the rules of the previous soft forks that had been locked in. Other than that, the version 0 idea seems pretty similar to the hard fork bit proposal because you need more context than just the block itself to determine if it's a valid flag block. These reasons were part of why the hard fork bit proposal was progressed towards.The proposal for the hard fork bit mechanism is being discussed and refined among the developers. One of the points to consider is how to include BIP-GIT-HASH of the canonical BIP on Github in the coinbase, but it is not known until the code is written. Using the commit hash of the BIP solves this issue, as the BIP cannot specify what to put in the coinbase. The proposal suggests that the hard fork bit allows BIP authors to specify a unique value within a 20-byte limit or use "BIP" in case of small coinbases or to avoid duplicate values. This proposal aims to prevent hard forks from piggy-backing on another's flag block without prior collaboration and to have a nicer message in the alerting system. Another proposal alongside this one involves using version 0 or even >1MB block in the specific case of a block size limit hard fork. However, the >1MB flag block would create DoS banning problems. It also means that older nodes do not have the chance to notice a fork is happening as they would with a version 0 or the hard fork bit proposal. The version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. While these proposals are similar, the hard fork bit proposal has more context than just the block itself to determine if it's a valid flag block.The message is a response to an inquiry about the situation where a group of miners suddenly switch their support, for example not intending to back new rules. The writer suggests that miners may be economically rational and will switch if there is a large decrease in difficulty on the original chain without a corresponding decrease in token value. The message cautions against assuming that all miners will continue to support the side they initially signaled, as they are only invested in the chain they mine for a short time until coinbase maturity. If both sides of a fork retain value, mining will redistribute itself in terms of short term profitability at every difficulty adjustment, regardless of initial signaled support for the fork. The message is signed with PGP signature version AP 2015-08-03T08:54:27+00:00 + A proposal for a "hardfork bit" has been put forward on Github by jl2012. The proposal aims to address concerns faced by users of a fork where a small/near/fluctuating majority of mining power is supported. The sender of the message praises the proposal, stating that it provides a fallback mechanism for economic actors who can make a decision and say "we're doing this". However, there is uncertainty over how the proposal should be classified and what it should be called. Michael Ruddy has asked whether the latest version of the proposal is available on Github or elsewhere for easier collaboration.The receiver of the message discusses the possibility of multiple hardforks sharing the same flag block and how the coinbase message can prevent any potential ambiguity and provide additional information to the warning system of non-upgrading nodes. The receiver suggests that if there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The receiver also explains why the "version 0" idea is not compatible with the version bits voting system and introduces the hardfork bit BIP as an alternative.The possibility of multiple hardforks sharing the same flag block is slim but can happen. To avoid potential ambiguity, the coinbase message provides additional information to the warning system of non-upgrading nodes. If there won't be any other hardfork proposals at the same time, the coinbase message may not be necessary. The "version 0" idea is not compatible with the version bits voting system, so a hardfork bit BIP was proposed instead. The commit hash of the BIP for the particular hard fork could be used in the coinbase message. This ensures that the BIP cannot specify itself what to put in the coinbase and allows specific hard fork BIPs to be updated without making code changes. The coinbase message is used to guard against one or more hard forks piggy-backing on another's flag block and to have a nicer message in the alerting system. A version 0 or a >1MB block proposal was also suggested for a block size limit hard fork. However, the >1MB flag block creates DoS banning problems, so it is not as appealing as a version 0 or this hard fork bit proposal. A version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. This is because we'd want to enforce the rules of the previous soft forks that had been locked in. Other than that, the version 0 idea seems pretty similar to the hard fork bit proposal because you need more context than just the block itself to determine if it's a valid flag block. These reasons were part of why the hard fork bit proposal was progressed towards.The proposal for the hard fork bit mechanism is being discussed and refined among the developers. One of the points to consider is how to include BIP-GIT-HASH of the canonical BIP on Github in the coinbase, but it is not known until the code is written. Using the commit hash of the BIP solves this issue, as the BIP cannot specify what to put in the coinbase. The proposal suggests that the hard fork bit allows BIP authors to specify a unique value within a 20-byte limit or use "BIP" in case of small coinbases or to avoid duplicate values. This proposal aims to prevent hard forks from piggy-backing on another's flag block without prior collaboration and to have a nicer message in the alerting system. Another proposal alongside this one involves using version 0 or even >1MB block in the specific case of a block size limit hard fork. However, the >1MB flag block would create DoS banning problems. It also means that older nodes do not have the chance to notice a fork is happening as they would with a version 0 or the hard fork bit proposal. The version 0 flag block would not be able to contain any transactions unless the flag block version was assumed to be that of the most recent version at the time. While these proposals are similar, the hard fork bit proposal has more context than just the block itself to determine if it's a valid flag block.The message is a response to an inquiry about the situation where a group of miners suddenly switch their support, for example not intending to back new rules. The writer suggests that miners may be economically rational and will switch if there is a large decrease in difficulty on the original chain without a corresponding decrease in token value. The message cautions against assuming that all miners will continue to support the side they initially signaled, as they are only invested in the chain they mine for a short time until coinbase maturity. If both sides of a fork retain value, mining will redistribute itself in terms of short term profitability at every difficulty adjustment, regardless of initial signaled support for the fork. The message is signed with PGP signature version AP - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP-for-Proof-of-Payment.xml b/static/bitcoin-dev/July_2015/combined_BIP-for-Proof-of-Payment.xml index 1762a9391c..2998f6e547 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP-for-Proof-of-Payment.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP-for-Proof-of-Payment.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP for Proof of Payment - 2023-08-01T13:06:47.119601+00:00 + 2025-10-11T22:01:06.041655+00:00 + python-feedgen Kalle Rosenbaum 2015-07-27 11:21:38+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - BIP for Proof of Payment - 2023-08-01T13:06:47.119601+00:00 + 2025-10-11T22:01:06.041830+00:00 - In an email exchange, Jorge Timón and Kalle Rosenbaum discuss the topic of increasing the nonce. Kalle asks if they need a bigger nonce, to which Jorge responds that he was not the one who proposed the idea. Instead, he reminds Kalle that the policy limit should not be a concern. The context does not provide any further details or background information on what the nonce is and why it might need to be increased.On July 24, 2015, Kalle Rosenbaum announced via bitcoin-dev that two new Bitcoin Improvement Proposals (BIPs) had been assigned numbers 120 and 121. The announcement prompted celebration, as the BIPs had faced challenges during the proposal process. The email thread did not provide further information on the content of the BIPs or their implications for Bitcoin development.In an email thread discussing the size of the nonce used in Proof of Payment (PoP) as outlined in Bitcoin Improvement Proposal (BIP) 120, it was noted that Bitcoin core now supports 80 bytes of data by default and does not maintain a policy limit. The BIP had assumed a limit of 40 bytes across all implementations. It was suggested that if there is a need to increase the size of the nonce, it could be done in a subsequent version of PoP. However, a longer nonce would result in bigger QR codes generated from the BIP 121 URIs, making 48 bits a good tradeoff for now. It was also mentioned that a server generating PoP requests should try to detect brute force attacks or delay the response containing the nonce by some 100ms. If PoP becomes an extension of BIP70, then there will be no size constraint on the nonce.Two Bitcoin Improvement Proposals (BIPs) have been assigned numbers 120 and 121. BIP 120 is for Proof of Payment, while BIP 121 is for a Proof of Payment URI scheme. Kalle Rosenbaum requested that these proposals be given their BIP numbers after much constructive discussion and feedback. During the discussions, Pieter Wuille raised some concerns about the Proof of Payment proposal, as it assumed that a transaction corresponds to a single payment. He suggested tracking payments instead of assigning identities to payers. However, Kalle believed that assigning a proof of payment was necessary for privacy reasons and proposed a nonce parameter in the URI, which was limited to 48 bits due to an OP_RETURN output limitation of 40 bytes.The context provided is a brief email conversation between Kalle and Pieter. Kalle thanks Pieter for his comments, but the rest of the conversation is not given. The conversation seems to be related to a reusable token that needs to be transferred to a friend. However, no information is provided on what this token is or why it needs to be transferred. It is not clear what the purpose of this conversation is and what the overall topic of discussion is.Kalle Rosenbaum has requested that proposals "Proof of Payment" and "Proof of Payment URI scheme" be assigned BIP numbers after constructive discussions, feedback, and updates. The source for both proposals can be found on GitHub. A limitation of 40 bytes for the OP_RETURN output had been discussed, and while it was suggested that a bigger nonce could be used, Kalle opted to stick with this limit due to simplifying implementation and not needing more data than 40 bytes. The Proof of Payment proposal allows for better privacy for customers who do not have to give out personal information such as an email address. It also creates a window of opportunity for thieves that is minimized since PoP is only usable once and created when needed. Different use cases will require different protection. The cost of using tokens is security, since a stolen token can be used over and over again.The discussion revolves around the Proof of Payment (PoP) feature for Bitcoin. Kalle Rosenbaum, who proposed the feature, discusses its limitations and use cases with Pieter Wuille. Rosenbaum notes that PoP allows for better privacy for customers who don't want to give out personal information such as email addresses. Wuille questions why anyone cares who paid and suggests that tracking payments rather than assigning identities to payers is a better approach. However, Rosenbaum indicates that the identity of the payer is necessary for PoP to work since the wallet used to pay must also be used to issue the PoP. The two discuss methods of sharing PoPs, including forwarding requests or transferring keys to friends' wallets. They also compare PoP to using tokens and note that tokens are reusable, whereas PoP is only usable once, which minimizes the window of opportunity for thieves.The discussion revolves around the limitation of creating a 40-byte OP_RETURN. The limitation comes from a relay policy in full nodes, not a limitation is wallet software. PoPs are not relayed on the network. The purpose of the PoP is to ensure that only the 2015-07-27T11:21:38+00:00 + In an email exchange, Jorge Timón and Kalle Rosenbaum discuss the topic of increasing the nonce. Kalle asks if they need a bigger nonce, to which Jorge responds that he was not the one who proposed the idea. Instead, he reminds Kalle that the policy limit should not be a concern. The context does not provide any further details or background information on what the nonce is and why it might need to be increased.On July 24, 2015, Kalle Rosenbaum announced via bitcoin-dev that two new Bitcoin Improvement Proposals (BIPs) had been assigned numbers 120 and 121. The announcement prompted celebration, as the BIPs had faced challenges during the proposal process. The email thread did not provide further information on the content of the BIPs or their implications for Bitcoin development.In an email thread discussing the size of the nonce used in Proof of Payment (PoP) as outlined in Bitcoin Improvement Proposal (BIP) 120, it was noted that Bitcoin core now supports 80 bytes of data by default and does not maintain a policy limit. The BIP had assumed a limit of 40 bytes across all implementations. It was suggested that if there is a need to increase the size of the nonce, it could be done in a subsequent version of PoP. However, a longer nonce would result in bigger QR codes generated from the BIP 121 URIs, making 48 bits a good tradeoff for now. It was also mentioned that a server generating PoP requests should try to detect brute force attacks or delay the response containing the nonce by some 100ms. If PoP becomes an extension of BIP70, then there will be no size constraint on the nonce.Two Bitcoin Improvement Proposals (BIPs) have been assigned numbers 120 and 121. BIP 120 is for Proof of Payment, while BIP 121 is for a Proof of Payment URI scheme. Kalle Rosenbaum requested that these proposals be given their BIP numbers after much constructive discussion and feedback. During the discussions, Pieter Wuille raised some concerns about the Proof of Payment proposal, as it assumed that a transaction corresponds to a single payment. He suggested tracking payments instead of assigning identities to payers. However, Kalle believed that assigning a proof of payment was necessary for privacy reasons and proposed a nonce parameter in the URI, which was limited to 48 bits due to an OP_RETURN output limitation of 40 bytes.The context provided is a brief email conversation between Kalle and Pieter. Kalle thanks Pieter for his comments, but the rest of the conversation is not given. The conversation seems to be related to a reusable token that needs to be transferred to a friend. However, no information is provided on what this token is or why it needs to be transferred. It is not clear what the purpose of this conversation is and what the overall topic of discussion is.Kalle Rosenbaum has requested that proposals "Proof of Payment" and "Proof of Payment URI scheme" be assigned BIP numbers after constructive discussions, feedback, and updates. The source for both proposals can be found on GitHub. A limitation of 40 bytes for the OP_RETURN output had been discussed, and while it was suggested that a bigger nonce could be used, Kalle opted to stick with this limit due to simplifying implementation and not needing more data than 40 bytes. The Proof of Payment proposal allows for better privacy for customers who do not have to give out personal information such as an email address. It also creates a window of opportunity for thieves that is minimized since PoP is only usable once and created when needed. Different use cases will require different protection. The cost of using tokens is security, since a stolen token can be used over and over again.The discussion revolves around the Proof of Payment (PoP) feature for Bitcoin. Kalle Rosenbaum, who proposed the feature, discusses its limitations and use cases with Pieter Wuille. Rosenbaum notes that PoP allows for better privacy for customers who don't want to give out personal information such as email addresses. Wuille questions why anyone cares who paid and suggests that tracking payments rather than assigning identities to payers is a better approach. However, Rosenbaum indicates that the identity of the payer is necessary for PoP to work since the wallet used to pay must also be used to issue the PoP. The two discuss methods of sharing PoPs, including forwarding requests or transferring keys to friends' wallets. They also compare PoP to using tokens and note that tokens are reusable, whereas PoP is only usable once, which minimizes the window of opportunity for thieves.The discussion revolves around the limitation of creating a 40-byte OP_RETURN. The limitation comes from a relay policy in full nodes, not a limitation is wallet software. PoPs are not relayed on the network. The purpose of the PoP is to ensure that only the - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_BIP0074-Draft-Dynamic-Rate-Lookup-.xml b/static/bitcoin-dev/July_2015/combined_BIP0074-Draft-Dynamic-Rate-Lookup-.xml index f3d52cbd8b..4ef154ff8a 100644 --- a/static/bitcoin-dev/July_2015/combined_BIP0074-Draft-Dynamic-Rate-Lookup-.xml +++ b/static/bitcoin-dev/July_2015/combined_BIP0074-Draft-Dynamic-Rate-Lookup-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP0074 Draft (Dynamic Rate Lookup) - 2023-08-01T14:22:40.443804+00:00 + 2025-10-11T22:01:01.796548+00:00 + python-feedgen David Barnes | Bitcoin Co. Ltd. 2015-07-17 15:47:24+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - BIP0074 Draft (Dynamic Rate Lookup) - 2023-08-01T14:22:40.443804+00:00 + 2025-10-11T22:01:01.796693+00:00 - A Bitcoin Improvement Proposal (BIP) has been introduced to address the issue of merchants not being able to determine the exact exchange rate they will receive when accepting Bitcoin as payment. Currently, customers are able to choose any exchange rate they prefer, making it difficult for merchants to ensure they receive the correct amount. The BIP suggests that customers' wallets should be able to determine the exact rate offered by the merchant. Merchants would generate a QR code with their address, and when customers wish to pay with Bitcoin, they would scan the QR code and pay the amount specified by the merchant. The merchant would then receive an SMS notification confirming the payment. This proposal assumes that staff members do not have any app and simply ring up the customer in their standard point-of-sale system, informing them of the fiat amount they must pay. It also assumes that the merchant intends to convert the coins to a service or exchange, and therefore needs to use the rates from that particular service or exchange. While some merchants may be willing to trust the customer, especially for small food items or repeat customers, the BIP aims to provide a more reliable method for determining the exchange rate. The BIP acknowledges that there are various services available that provide SMS notifications for Bitcoin transactions to a specific address. The BIP does not address the method by which merchants should be notified of completed payments, as this is left up to their discretion. However, it suggests that requesting dollar amounts from customers can lead to problems, whereas their proposed service would provide an SMS notification indicating that the payment has been completed, along with the amount in the fiat currency. The BIP aims to create a user-friendly solution for merchants, allowing them to accept Bitcoin without the need for extensive training or the presence of a Bitcoin enthusiast. It acknowledges that while lack of internet access may not be a major concern, the issue lies more with staff members not being properly trained on how to use apps or the internet. Even with training, staff members may forget if they haven't encountered a Bitcoin customer for some time. This conclusion is based on firsthand experience and feedback from both Bitcoin customers and merchants. In another discussion on the bitcoin-dev mailing list, it was mentioned that using arbitrary BIP numbers could cause confusion if those numbers are assigned later. David Barnes had chosen the next available number for his proposed file but stated that the number was not important and could be changed. Micha Bailey raised concerns about whether Greg had assigned the number and advised against using arbitrary numbers, particularly if they are similar to ones already assigned. Furthermore, there is a concern regarding how cashiers can verify successful payment if both they and the customer need to scan a new QR code. While Bitcoin payment notification services via SMS are available, it may not be effective in facilitating in-person Bitcoin purchases. Overall, the BIP0074 draft proposal aims to simplify Bitcoin payments at physical shop locations. It addresses the need for merchants to have an app to calculate Bitcoin payments and offers a simpler solution by allowing merchants to specify the exchange rates they are using, which customers can then verify and pay accordingly. The proposal aims to benefit businesses that do not receive enough Bitcoin transactions to justify training sessions or dedicated hardware. The complete draft proposal can be accessed through the provided GitHub link, but it should be noted that it is subject to potential changes. 2015-07-17T15:47:24+00:00 + A Bitcoin Improvement Proposal (BIP) has been introduced to address the issue of merchants not being able to determine the exact exchange rate they will receive when accepting Bitcoin as payment. Currently, customers are able to choose any exchange rate they prefer, making it difficult for merchants to ensure they receive the correct amount. The BIP suggests that customers' wallets should be able to determine the exact rate offered by the merchant. Merchants would generate a QR code with their address, and when customers wish to pay with Bitcoin, they would scan the QR code and pay the amount specified by the merchant. The merchant would then receive an SMS notification confirming the payment. This proposal assumes that staff members do not have any app and simply ring up the customer in their standard point-of-sale system, informing them of the fiat amount they must pay. It also assumes that the merchant intends to convert the coins to a service or exchange, and therefore needs to use the rates from that particular service or exchange. While some merchants may be willing to trust the customer, especially for small food items or repeat customers, the BIP aims to provide a more reliable method for determining the exchange rate. The BIP acknowledges that there are various services available that provide SMS notifications for Bitcoin transactions to a specific address. The BIP does not address the method by which merchants should be notified of completed payments, as this is left up to their discretion. However, it suggests that requesting dollar amounts from customers can lead to problems, whereas their proposed service would provide an SMS notification indicating that the payment has been completed, along with the amount in the fiat currency. The BIP aims to create a user-friendly solution for merchants, allowing them to accept Bitcoin without the need for extensive training or the presence of a Bitcoin enthusiast. It acknowledges that while lack of internet access may not be a major concern, the issue lies more with staff members not being properly trained on how to use apps or the internet. Even with training, staff members may forget if they haven't encountered a Bitcoin customer for some time. This conclusion is based on firsthand experience and feedback from both Bitcoin customers and merchants. In another discussion on the bitcoin-dev mailing list, it was mentioned that using arbitrary BIP numbers could cause confusion if those numbers are assigned later. David Barnes had chosen the next available number for his proposed file but stated that the number was not important and could be changed. Micha Bailey raised concerns about whether Greg had assigned the number and advised against using arbitrary numbers, particularly if they are similar to ones already assigned. Furthermore, there is a concern regarding how cashiers can verify successful payment if both they and the customer need to scan a new QR code. While Bitcoin payment notification services via SMS are available, it may not be effective in facilitating in-person Bitcoin purchases. Overall, the BIP0074 draft proposal aims to simplify Bitcoin payments at physical shop locations. It addresses the need for merchants to have an app to calculate Bitcoin payments and offers a simpler solution by allowing merchants to specify the exchange rates they are using, which customers can then verify and pay accordingly. The proposal aims to benefit businesses that do not receive enough Bitcoin transactions to justify training sessions or dedicated hardware. The complete draft proposal can be accessed through the provided GitHub link, but it should be noted that it is subject to potential changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Bitcoin-Core-0-11-0-released.xml b/static/bitcoin-dev/July_2015/combined_Bitcoin-Core-0-11-0-released.xml index 9a5d4e928e..e29aa77560 100644 --- a/static/bitcoin-dev/July_2015/combined_Bitcoin-Core-0-11-0-released.xml +++ b/static/bitcoin-dev/July_2015/combined_Bitcoin-Core-0-11-0-released.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.11.0 released - 2023-08-01T14:17:38.011332+00:00 + 2025-10-11T22:02:24.725820+00:00 + python-feedgen odinn 2015-07-15 11:20:19+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.11.0 released - 2023-08-01T14:17:38.011332+00:00 + 2025-10-11T22:02:24.725950+00:00 - Bitcoin Core version 0.11.0 has been released, offering new features and bug fixes. Users can report bugs using the issue tracker on Github, and the entire distribution is available as a torrent. Upgrading and downgrading should be done with caution, and it is advised to backup the data directory before downgrading.One of the notable changes in this release is the introduction of block file pruning, which allows for running a fully validating node without maintaining a copy of the raw block and undo data on disk. This feature can help reduce the storage space required for transactions and block data. However, it's important to note that block pruning is currently incompatible with running a wallet.The algorithm used for fee estimation has been improved, providing more accurate calculations for transaction fees. Additionally, new functionality has been added to create a new circuit for every peer connection when using Tor, enhancing privacy and reducing the risk of connecting to malicious or banned nodes.Various updates have been made to different aspects of the software, including configuration and command-line options, block and transaction handling, P2P protocol and network code, validation, build system, wallet, GUI, and tests. These updates aim to improve the overall functionality, performance, and security of Bitcoin Core.The release also includes several bug fixes, addressing issues such as seed nodes not being added to the list of known peers, compatibility problems with OpenSSL, and performance improvements for signature validation.Overall, Bitcoin Core version 0.11.0 offers significant improvements and enhancements to the software, providing users with a more efficient and secure experience. Users are encouraged to upgrade to this version and take advantage of the new features and bug fixes. 2015-07-15T11:20:19+00:00 + Bitcoin Core version 0.11.0 has been released, offering new features and bug fixes. Users can report bugs using the issue tracker on Github, and the entire distribution is available as a torrent. Upgrading and downgrading should be done with caution, and it is advised to backup the data directory before downgrading.One of the notable changes in this release is the introduction of block file pruning, which allows for running a fully validating node without maintaining a copy of the raw block and undo data on disk. This feature can help reduce the storage space required for transactions and block data. However, it's important to note that block pruning is currently incompatible with running a wallet.The algorithm used for fee estimation has been improved, providing more accurate calculations for transaction fees. Additionally, new functionality has been added to create a new circuit for every peer connection when using Tor, enhancing privacy and reducing the risk of connecting to malicious or banned nodes.Various updates have been made to different aspects of the software, including configuration and command-line options, block and transaction handling, P2P protocol and network code, validation, build system, wallet, GUI, and tests. These updates aim to improve the overall functionality, performance, and security of Bitcoin Core.The release also includes several bug fixes, addressing issues such as seed nodes not being added to the list of known peers, compatibility problems with OpenSSL, and performance improvements for signature validation.Overall, Bitcoin Core version 0.11.0 offers significant improvements and enhancements to the software, providing users with a more efficient and secure experience. Users are encouraged to upgrade to this version and take advantage of the new features and bug fixes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Bitcoin-Core-and-hard-forks.xml b/static/bitcoin-dev/July_2015/combined_Bitcoin-Core-and-hard-forks.xml index 093fd8de8e..cf848048ae 100644 --- a/static/bitcoin-dev/July_2015/combined_Bitcoin-Core-and-hard-forks.xml +++ b/static/bitcoin-dev/July_2015/combined_Bitcoin-Core-and-hard-forks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core and hard forks - 2023-08-01T14:28:34.174288+00:00 + 2025-10-11T22:02:09.847715+00:00 + python-feedgen Jorge Timón 2015-07-28 17:33:29+00:00 @@ -319,13 +320,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core and hard forks - 2023-08-01T14:28:34.174288+00:00 + 2025-10-11T22:02:09.848013+00:00 - The email exchange between Tom Harding and Jorge Timón centers around the role of societal adoption in Satoshi's design. Harding argues that adoption is progressing ahead of schedule, citing the exchange rate as evidence. He believes that the exchange rate is crucial to the health of the network. However, Timón disagrees and suggests that Satoshi's timetable for fee incentives can be improved upon. It is noted that communication between the two may be hindered by language barriers. The email ends with Harding sharing a saying about geniuses causing more harm than fools.The phrase "no offense taken" is discussed as a way to diffuse tension in informal conversations, but it is emphasized that it does not excuse offensive behavior. It is important to be mindful and respectful of others' feelings. Some people may find the phrase dismissive or invalidating, so it is crucial to listen to others' perspectives. The Bitcoin mailing list is mentioned as a platform for technical proposals and discussions where personal attacks are not tolerated.Peter Todd receives a warning about his Twitter activity from Alice Larson. Todd acknowledges the warning and attaches an OpenPGP signature to the email exchange. The context highlights the importance of measuring risk systematically and avoiding drama on social media platforms. Todd's behavior, which includes derogatory comments towards women and creating drama, is driving away vendors. The debate on the blocksize in the Bitcoin community has become non-technical and counterproductive. Cheap shots at vendors and name-calling have hindered consensus-building. It is necessary to engage in mature discussions and conduct real risk analysis.Pieter Wuille shares his opinion on the relationship between Bitcoin Core and consensus rules. He emphasizes the responsibility of Bitcoin Core developers to create secure software and participate in consensus discussions without central control. Wuille believes that a fee market should develop sooner rather than later and warns against delaying decisions on block size limits. He suggests that stakeholders should explain their scalability plans and calls for research on managing social issues in Bitcoin development.Jorge Timón explains that increasing the exchange rate of Bitcoin is not within their control. However, the recipient argues that developers can influence Bitcoin's value through their work. They discuss sustaining the Bitcoin system through fees and the potential negative impact of a block size limit on short-term adoption.The use of smart contracts in the cryptocurrency space allows for trustless negotiation and optimization. Quality-of-service (QoS) guarantees can be implemented through third-party bidding. Negotiating directly with miners via smart contracts is challenging due to mining processes. Jean-Paul Kogelman suggests using implicit QoS, which is simpler and closer to Bitcoin's original purpose. Miners can set fee tiers, and users choose the level of service they want. The discussion revolves around finding a solution that balances simplicity and fairness.The assumption that all nodes have similar computational resources leads to misplaced incentives in the cryptocurrency industry. Direct outsourcing of computation through cryptocurrencies would distribute tasks economically. Wallets should be assumed to have low computational resources, so third parties can shift complexity and risk. Negotiating directly with miners via smart contracts is challenging. Giving guarantees without a majority of hashing power is not possible due to mining processes.Jean-Paul Kogelman, Eric Lombrozo, and Peter Todd discuss implementing QoS guarantees in Bitcoin transactions. Kogelman suggests implicit QoS, while Lombrozo proposes using third-party services for bidding and timelocked contracts. Todd points out the difficulty of giving guarantees without majority hashing power.In a discussion on the bitcoin-dev mailing list, the topic of Quality of Service (QoS) guarantees within the Bitcoin ecosystem is explored. Jean-Paul Kogelman suggests that miners should be responsible for setting different values for transaction fees to promote a healthy fee market. Eric Lombrozo proposes using separate services that guarantee inclusion for a predetermined price and do the bidding on behalf of the user. The conversation also addresses the issue of block time variance and the impact on transaction confirmation.Kogelman argues that giving guarantees without a majority of hashing power isn't possible due to the random nature of mining. However, he believes that implementing QoS, even if not perfect, is more workable than guessing whether a transaction will end up in a block at all. Lombrozo questions the meaning of QoS in this context and highlights that transactions are either included or not, unlike a hotel where upgrades are possible.The discussion also touches upon the interference of a size cap with the QoS scheme. If miners have to start excluding transactions, they won't be able to deliver guarantees. The idea of bidding on behalf of miners through timelocked contracts is proposed as a mechanism to enforce QoS guarantees and shift complexity and risk from individual miners to third-party services.Furthermore, the conversation delves into considerations about the block size debate and its relationship to scaling the network. Eric Lombrozo argues that increasing the block size would not hinder the progress of research and development of Lightning or other technologies. However, there are concerns about security and the need for better fee market understanding before 2015-07-28T17:33:29+00:00 + The email exchange between Tom Harding and Jorge Timón centers around the role of societal adoption in Satoshi's design. Harding argues that adoption is progressing ahead of schedule, citing the exchange rate as evidence. He believes that the exchange rate is crucial to the health of the network. However, Timón disagrees and suggests that Satoshi's timetable for fee incentives can be improved upon. It is noted that communication between the two may be hindered by language barriers. The email ends with Harding sharing a saying about geniuses causing more harm than fools.The phrase "no offense taken" is discussed as a way to diffuse tension in informal conversations, but it is emphasized that it does not excuse offensive behavior. It is important to be mindful and respectful of others' feelings. Some people may find the phrase dismissive or invalidating, so it is crucial to listen to others' perspectives. The Bitcoin mailing list is mentioned as a platform for technical proposals and discussions where personal attacks are not tolerated.Peter Todd receives a warning about his Twitter activity from Alice Larson. Todd acknowledges the warning and attaches an OpenPGP signature to the email exchange. The context highlights the importance of measuring risk systematically and avoiding drama on social media platforms. Todd's behavior, which includes derogatory comments towards women and creating drama, is driving away vendors. The debate on the blocksize in the Bitcoin community has become non-technical and counterproductive. Cheap shots at vendors and name-calling have hindered consensus-building. It is necessary to engage in mature discussions and conduct real risk analysis.Pieter Wuille shares his opinion on the relationship between Bitcoin Core and consensus rules. He emphasizes the responsibility of Bitcoin Core developers to create secure software and participate in consensus discussions without central control. Wuille believes that a fee market should develop sooner rather than later and warns against delaying decisions on block size limits. He suggests that stakeholders should explain their scalability plans and calls for research on managing social issues in Bitcoin development.Jorge Timón explains that increasing the exchange rate of Bitcoin is not within their control. However, the recipient argues that developers can influence Bitcoin's value through their work. They discuss sustaining the Bitcoin system through fees and the potential negative impact of a block size limit on short-term adoption.The use of smart contracts in the cryptocurrency space allows for trustless negotiation and optimization. Quality-of-service (QoS) guarantees can be implemented through third-party bidding. Negotiating directly with miners via smart contracts is challenging due to mining processes. Jean-Paul Kogelman suggests using implicit QoS, which is simpler and closer to Bitcoin's original purpose. Miners can set fee tiers, and users choose the level of service they want. The discussion revolves around finding a solution that balances simplicity and fairness.The assumption that all nodes have similar computational resources leads to misplaced incentives in the cryptocurrency industry. Direct outsourcing of computation through cryptocurrencies would distribute tasks economically. Wallets should be assumed to have low computational resources, so third parties can shift complexity and risk. Negotiating directly with miners via smart contracts is challenging. Giving guarantees without a majority of hashing power is not possible due to mining processes.Jean-Paul Kogelman, Eric Lombrozo, and Peter Todd discuss implementing QoS guarantees in Bitcoin transactions. Kogelman suggests implicit QoS, while Lombrozo proposes using third-party services for bidding and timelocked contracts. Todd points out the difficulty of giving guarantees without majority hashing power.In a discussion on the bitcoin-dev mailing list, the topic of Quality of Service (QoS) guarantees within the Bitcoin ecosystem is explored. Jean-Paul Kogelman suggests that miners should be responsible for setting different values for transaction fees to promote a healthy fee market. Eric Lombrozo proposes using separate services that guarantee inclusion for a predetermined price and do the bidding on behalf of the user. The conversation also addresses the issue of block time variance and the impact on transaction confirmation.Kogelman argues that giving guarantees without a majority of hashing power isn't possible due to the random nature of mining. However, he believes that implementing QoS, even if not perfect, is more workable than guessing whether a transaction will end up in a block at all. Lombrozo questions the meaning of QoS in this context and highlights that transactions are either included or not, unlike a hotel where upgrades are possible.The discussion also touches upon the interference of a size cap with the QoS scheme. If miners have to start excluding transactions, they won't be able to deliver guarantees. The idea of bidding on behalf of miners through timelocked contracts is proposed as a mechanism to enforce QoS guarantees and shift complexity and risk from individual miners to third-party services.Furthermore, the conversation delves into considerations about the block size debate and its relationship to scaling the network. Eric Lombrozo argues that increasing the block size would not hinder the progress of research and development of Lightning or other technologies. However, there are concerns about security and the need for better fee market understanding before - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Bitcoin-Node-Speed-Test.xml b/static/bitcoin-dev/July_2015/combined_Bitcoin-Node-Speed-Test.xml index 82a41f979d..8529c5695f 100644 --- a/static/bitcoin-dev/July_2015/combined_Bitcoin-Node-Speed-Test.xml +++ b/static/bitcoin-dev/July_2015/combined_Bitcoin-Node-Speed-Test.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Node Speed Test - 2023-08-01T14:29:57.477609+00:00 + 2025-10-11T22:00:53.285911+00:00 + python-feedgen grarpamp 2015-07-24 03:54:31+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Node Speed Test - 2023-08-01T14:29:57.478608+00:00 + 2025-10-11T22:00:53.286093+00:00 - In a 2015 discussion on the bitcoin-dev forum, a member raised concerns about the potential discrepancies and errors that could arise from downloading a random selection of blocks from each peer. This highlighted the importance of ensuring consistency and accuracy in blockchain data for the functioning of decentralized digital currencies like Bitcoin.On the bitcoin-dev mailing list, there was a conversation about improving the speed of bitcoin node connections for syncing purposes. Matt Corallo suggested running servers around the world and testing based on closest-by-geoip to improve throughput. However, he also pointed out the potential issues with sybil resistance. Further experimentation was planned to explore possible improvements.In an email exchange, Marcel Jamin and Peter Todd discussed the idea of measuring the upload capacity of peers by downloading from them. The context or background for their discussion was not provided.Another post on the bitcoin-dev mailing list focused on testing the Bitcoin network's maximum throughput to determine if it could support a faster block rate. Nodes were randomly selected from peers.dat, and a random selection of blocks was downloaded from each peer. The results showed that 37% of connected nodes failed to upload blocks faster than 1MB/s, indicating that the network did not have sufficient bandwidth for increased block sizes. The findings also revealed that 16% of nodes uploaded blocks faster than 10MB/s. These results emphasized the challenges in increasing block sizes and the need for careful evaluation.The same topic of the network's available bandwidth for increased block sizes was discussed in another email thread. One participant mentioned Gavin's numbers, stating that 37% of nodes would fail to upload a 20MB block to a single peer in under 20 seconds. Another participant pointed out that the measurements were optimistic as they only measured download capacity, which is further reduced when sending blocks to multiple peers for reliability. It was noted that additional margin was needed to resist attack as performance is consensus-critical.A test run on the Bitcoin network was conducted to assess its ability to support a faster block rate. Randomly selected nodes were contacted, and a random selection of blocks was downloaded from each peer. The results showed that 37% of connected nodes failed to upload blocks faster than 1MB/s, while only 16% uploaded blocks faster than 10MB/s. These findings indicated that the network did not have the available bandwidth for increased block sizes. Raw data from the test can be found at http://pastebin.com/raw.php?i=6b4NuiVQ. Peter suggested running tests on a simulated network with worst-case network failures to determine the necessary safety margin.In summary, these discussions and tests highlighted the challenges and limitations in increasing block sizes in the Bitcoin network due to bandwidth constraints. The need for careful evaluation and consideration of factors such as decentralization, security, and economic incentives was emphasized. 2015-07-24T03:54:31+00:00 + In a 2015 discussion on the bitcoin-dev forum, a member raised concerns about the potential discrepancies and errors that could arise from downloading a random selection of blocks from each peer. This highlighted the importance of ensuring consistency and accuracy in blockchain data for the functioning of decentralized digital currencies like Bitcoin.On the bitcoin-dev mailing list, there was a conversation about improving the speed of bitcoin node connections for syncing purposes. Matt Corallo suggested running servers around the world and testing based on closest-by-geoip to improve throughput. However, he also pointed out the potential issues with sybil resistance. Further experimentation was planned to explore possible improvements.In an email exchange, Marcel Jamin and Peter Todd discussed the idea of measuring the upload capacity of peers by downloading from them. The context or background for their discussion was not provided.Another post on the bitcoin-dev mailing list focused on testing the Bitcoin network's maximum throughput to determine if it could support a faster block rate. Nodes were randomly selected from peers.dat, and a random selection of blocks was downloaded from each peer. The results showed that 37% of connected nodes failed to upload blocks faster than 1MB/s, indicating that the network did not have sufficient bandwidth for increased block sizes. The findings also revealed that 16% of nodes uploaded blocks faster than 10MB/s. These results emphasized the challenges in increasing block sizes and the need for careful evaluation.The same topic of the network's available bandwidth for increased block sizes was discussed in another email thread. One participant mentioned Gavin's numbers, stating that 37% of nodes would fail to upload a 20MB block to a single peer in under 20 seconds. Another participant pointed out that the measurements were optimistic as they only measured download capacity, which is further reduced when sending blocks to multiple peers for reliability. It was noted that additional margin was needed to resist attack as performance is consensus-critical.A test run on the Bitcoin network was conducted to assess its ability to support a faster block rate. Randomly selected nodes were contacted, and a random selection of blocks was downloaded from each peer. The results showed that 37% of connected nodes failed to upload blocks faster than 1MB/s, while only 16% uploaded blocks faster than 10MB/s. These findings indicated that the network did not have the available bandwidth for increased block sizes. Raw data from the test can be found at http://pastebin.com/raw.php?i=6b4NuiVQ. Peter suggested running tests on a simulated network with worst-case network failures to determine the necessary safety margin.In summary, these discussions and tests highlighted the challenges and limitations in increasing block sizes in the Bitcoin network due to bandwidth constraints. The need for careful evaluation and consideration of factors such as decentralization, security, and economic incentives was emphasized. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Bitcoin-Perceptions-and-Expectations.xml b/static/bitcoin-dev/July_2015/combined_Bitcoin-Perceptions-and-Expectations.xml index 3bad7b2ab7..d638805cae 100644 --- a/static/bitcoin-dev/July_2015/combined_Bitcoin-Perceptions-and-Expectations.xml +++ b/static/bitcoin-dev/July_2015/combined_Bitcoin-Perceptions-and-Expectations.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin, Perceptions, and Expectations - 2023-08-01T14:36:05.211867+00:00 + 2025-10-11T22:01:59.181392+00:00 + python-feedgen Thomas Kerin 2015-07-25 15:04:41+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Bitcoin, Perceptions, and Expectations - 2023-08-01T14:36:05.211867+00:00 + 2025-10-11T22:01:59.181576+00:00 - Vincent Truong, a member of the bitcoin-dev mailing list, suggests redefining the terminology used in Bitcoin transactions to improve understanding and perception. He proposes replacing "confirmations" with "settlements" to align with finance terminology and convey finality and safety. Truong also recommends using a percentage-based system or "confidence" instead of displaying a meaningless number of confirmations. He emphasizes that wallets send notifications when transactions are first seen, not when they go into a block, highlighting Bitcoin's speed compared to traditional payment methods like Visa.In a 2015 email thread, the question of how to explain to end users that a "validated" transaction can become unspendable by a mined block was raised. This concern relates to potential Finney attacks, where a miner could double-spend a transaction before it gets confirmed on the blockchain. The email emphasizes the importance of educating users about the risks associated with different validation stages and the need for continued development in the Bitcoin ecosystem to enhance security measures against such attacks.Bitcoin transactions are often labeled as "fast," but they are slower than instant Visa transactions. However, wallets send notifications when transactions are first seen, making Bitcoin still very fast. To better align with finance terminology and improve understanding, Truong suggests redefining Bitcoin terminology. The term "confirmations" could be replaced with "settlements" to indicate finality, while a percentage or "confidence" could represent the likelihood of double spending. While Bitcoin transactions may take longer than Visa, misleading language that implies a ten-minute global travel time should be avoided.The Bitcoin community is discussing the misleading nature of terms like "free," "instant," and "zero or low fees" used to describe the cryptocurrency. While Bitcoin transactions are relatively quick, these terms create unrealistic expectations. Irreversible transactions made in a peer-to-peer network do not require proportional fees due to the lack of a central authority verifying transactions. Therefore, while low fees may be acceptable, free and instant transactions are not accurate descriptors for Bitcoin. The Lightning Network is mentioned as a potential solution that could provide free and instant transactions in the future.A pull request has been made to remove misleading phrases from Bitcoin.org, such as "zero or low fees," "fast international payments," and "instant peer-to-peer transactions." Some users argue that this change breaks the social contract of what Bitcoin is intended to be, while others believe it should reflect the current system rather than past or future possibilities. The concept of free transactions does not align with the current system, making it misleading to advertise Bitcoin as such. This change has sparked discussions on platforms like Reddit, and its implementation and impact on user perception remain to be seen. 2015-07-25T15:04:41+00:00 + Vincent Truong, a member of the bitcoin-dev mailing list, suggests redefining the terminology used in Bitcoin transactions to improve understanding and perception. He proposes replacing "confirmations" with "settlements" to align with finance terminology and convey finality and safety. Truong also recommends using a percentage-based system or "confidence" instead of displaying a meaningless number of confirmations. He emphasizes that wallets send notifications when transactions are first seen, not when they go into a block, highlighting Bitcoin's speed compared to traditional payment methods like Visa.In a 2015 email thread, the question of how to explain to end users that a "validated" transaction can become unspendable by a mined block was raised. This concern relates to potential Finney attacks, where a miner could double-spend a transaction before it gets confirmed on the blockchain. The email emphasizes the importance of educating users about the risks associated with different validation stages and the need for continued development in the Bitcoin ecosystem to enhance security measures against such attacks.Bitcoin transactions are often labeled as "fast," but they are slower than instant Visa transactions. However, wallets send notifications when transactions are first seen, making Bitcoin still very fast. To better align with finance terminology and improve understanding, Truong suggests redefining Bitcoin terminology. The term "confirmations" could be replaced with "settlements" to indicate finality, while a percentage or "confidence" could represent the likelihood of double spending. While Bitcoin transactions may take longer than Visa, misleading language that implies a ten-minute global travel time should be avoided.The Bitcoin community is discussing the misleading nature of terms like "free," "instant," and "zero or low fees" used to describe the cryptocurrency. While Bitcoin transactions are relatively quick, these terms create unrealistic expectations. Irreversible transactions made in a peer-to-peer network do not require proportional fees due to the lack of a central authority verifying transactions. Therefore, while low fees may be acceptable, free and instant transactions are not accurate descriptors for Bitcoin. The Lightning Network is mentioned as a potential solution that could provide free and instant transactions in the future.A pull request has been made to remove misleading phrases from Bitcoin.org, such as "zero or low fees," "fast international payments," and "instant peer-to-peer transactions." Some users argue that this change breaks the social contract of what Bitcoin is intended to be, while others believe it should reflect the current system rather than past or future possibilities. The concept of free transactions does not align with the current system, making it misleading to advertise Bitcoin as such. This change has sparked discussions on platforms like Reddit, and its implementation and impact on user perception remain to be seen. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Bitcoin-Roadmap-2015-or-If-We-Do-Nothing-Analysis.xml b/static/bitcoin-dev/July_2015/combined_Bitcoin-Roadmap-2015-or-If-We-Do-Nothing-Analysis.xml index 3899630fd7..58e3cb6294 100644 --- a/static/bitcoin-dev/July_2015/combined_Bitcoin-Roadmap-2015-or-If-We-Do-Nothing-Analysis.xml +++ b/static/bitcoin-dev/July_2015/combined_Bitcoin-Roadmap-2015-or-If-We-Do-Nothing-Analysis.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis - 2023-08-01T14:36:31.954832+00:00 + Combined summary - Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis + 2025-10-11T22:01:20.945534+00:00 + python-feedgen Slurms MacKenzie 2015-07-25 11:19:43+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 - Combined summary - Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis - 2023-08-01T14:36:31.954832+00:00 + Combined summary - Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis + 2025-10-11T22:01:20.945691+00:00 - The author of the given context raises concerns about companies like blockchain.info and Coinbase not running full nodes to ensure proper consensus checking and security. The author argues that these companies blindly follow invalid chains and rely on their security instead of cross-checking with a full node. The author also questions if people can trust such companies in the future if the load goes higher. The lack of understanding of Bitcoin and security engineering is seen as a significant contributor to these issues.The bitcoin-dev mailing list discusses the importance of running full nodes for security purposes. Adam Back suggests that education is needed to make businesses aware of the significance of running their own full node. Peter Todd mentions that blockchain.info and Coinbase have not been running full nodes, causing issues with invalid confirmations. The need for decentralization and more layer 2 work is also highlighted to improve the system's dynamic. It is noted that major centralization-related failures will help improve understanding of the importance of full nodes.The CryptoCurrency Security Standard (CCSS) is mentioned as an open standard designed to share industry best practices. Eric invites everyone to participate in the CCSS, and the website and GitHub repository are available for contributions. The lack of running a full node by blockchain.info's wallet and block explorer is discussed, which has shown invalid data consistent with not running a full node.A discussion on the bitcoin-dev mailing list reveals that some companies with significant funding do not run a single Bitcoin Core node. It is suggested that this may be due to Core not providing the services that businesses want. It is emphasized that the decrease in node count is not necessarily related to block sizes.Adam Back expresses optimism about Bitcoin scaling and decentralization, highlighting the active work being done in these areas. He suggests a modest block size increase to facilitate the transition to layer 2. The question of whether a 1MB increase to 2MB would be considered "modest" is raised.Mike Hearn notes that large companies with funding do not run a single Bitcoin Core node, citing the lack of services provided by Core. He suggests the possibility of earning a fee by propagating a valid transaction.The article emphasizes the need for education about full nodes and their importance for security. Companies are encouraged to run their own full nodes and cross-check them to reduce risk. The need for a basic minimum bar standard and reducing custody through multisig and timelock is also mentioned. The author expresses optimism about Bitcoin scaling and decentralization, mentioning the importance of decentralization, economically dependent full nodes, and lower miner policy centralization for better scaling. Flexcap is highlighted as an interesting way to achieve economically validated scaling.In a discussion on the bitcoin-dev mailing list, it is noted that even large companies with significant funding do not run a single Bitcoin Core node open to incoming connections. Security concerns are suggested as a reason for this reluctance.Despite having a substantial amount of funding, many big companies do not run a single Bitcoin Core node. This is attributed to Core not providing the services that businesses require. The decrease in node count is seen as unrelated to block sizes.Dave Scotese raises concerns about the protocol requiring more computing power than common machines can provide, rendering them unable to run full nodes. Despite the incentive to protect wallets, major firms with funding do not appear to be running their own Bitcoin Core node.The author suggests the need for a post discussing roadmap in the bitcoin-dev mailing list. Increasing transactions per second and addressing the trend toward centralization are discussed. The issue of mining falling to a small number of businesses and common computing machines becoming inadequate for running full nodes is raised. 2015-07-25T11:19:43+00:00 + The author of the given context raises concerns about companies like blockchain.info and Coinbase not running full nodes to ensure proper consensus checking and security. The author argues that these companies blindly follow invalid chains and rely on their security instead of cross-checking with a full node. The author also questions if people can trust such companies in the future if the load goes higher. The lack of understanding of Bitcoin and security engineering is seen as a significant contributor to these issues.The bitcoin-dev mailing list discusses the importance of running full nodes for security purposes. Adam Back suggests that education is needed to make businesses aware of the significance of running their own full node. Peter Todd mentions that blockchain.info and Coinbase have not been running full nodes, causing issues with invalid confirmations. The need for decentralization and more layer 2 work is also highlighted to improve the system's dynamic. It is noted that major centralization-related failures will help improve understanding of the importance of full nodes.The CryptoCurrency Security Standard (CCSS) is mentioned as an open standard designed to share industry best practices. Eric invites everyone to participate in the CCSS, and the website and GitHub repository are available for contributions. The lack of running a full node by blockchain.info's wallet and block explorer is discussed, which has shown invalid data consistent with not running a full node.A discussion on the bitcoin-dev mailing list reveals that some companies with significant funding do not run a single Bitcoin Core node. It is suggested that this may be due to Core not providing the services that businesses want. It is emphasized that the decrease in node count is not necessarily related to block sizes.Adam Back expresses optimism about Bitcoin scaling and decentralization, highlighting the active work being done in these areas. He suggests a modest block size increase to facilitate the transition to layer 2. The question of whether a 1MB increase to 2MB would be considered "modest" is raised.Mike Hearn notes that large companies with funding do not run a single Bitcoin Core node, citing the lack of services provided by Core. He suggests the possibility of earning a fee by propagating a valid transaction.The article emphasizes the need for education about full nodes and their importance for security. Companies are encouraged to run their own full nodes and cross-check them to reduce risk. The need for a basic minimum bar standard and reducing custody through multisig and timelock is also mentioned. The author expresses optimism about Bitcoin scaling and decentralization, mentioning the importance of decentralization, economically dependent full nodes, and lower miner policy centralization for better scaling. Flexcap is highlighted as an interesting way to achieve economically validated scaling.In a discussion on the bitcoin-dev mailing list, it is noted that even large companies with significant funding do not run a single Bitcoin Core node open to incoming connections. Security concerns are suggested as a reason for this reluctance.Despite having a substantial amount of funding, many big companies do not run a single Bitcoin Core node. This is attributed to Core not providing the services that businesses require. The decrease in node count is seen as unrelated to block sizes.Dave Scotese raises concerns about the protocol requiring more computing power than common machines can provide, rendering them unable to run full nodes. Despite the incentive to protect wallets, major firms with funding do not appear to be running their own Bitcoin Core node.The author suggests the need for a post discussing roadmap in the bitcoin-dev mailing list. Increasing transactions per second and addressing the trend toward centralization are discussed. The issue of mining falling to a small number of businesses and common computing machines becoming inadequate for running full nodes is raised. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Bitcoin-governance.xml b/static/bitcoin-dev/July_2015/combined_Bitcoin-governance.xml index e2dd9647dd..2b0a290150 100644 --- a/static/bitcoin-dev/July_2015/combined_Bitcoin-governance.xml +++ b/static/bitcoin-dev/July_2015/combined_Bitcoin-governance.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin governance - 2023-08-01T14:11:37.517674+00:00 + 2025-10-11T22:01:37.943539+00:00 + python-feedgen Justus Ranvier 2015-07-01 17:28:30+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Bitcoin governance - 2023-08-01T14:11:37.518671+00:00 + 2025-10-11T22:01:37.943662+00:00 - In an email dated July 1st, 2015, Jeffrey Paul requested that discussions on a certain list be limited to the research and development of Bitcoin Core. He argued that if this was not the purpose of the list, then it was misleadingly named. Paul suggested that if Bitcoin Core development is to be considered independent from development of Bitcoin protocol, then it needs its own separate list. The email included two non-text attachments, one being a pgp-key and the other being a digital signature.There is a common misconception that the core developers of Bitcoin govern the cryptocurrency. However, it is important to note that they set standards instead of governing it. This standard is voluntary and its importance in defining consensus rules is subject to speculation. The amount of influence core developers have on Bitcoin depends on specific circumstances. It is suggested that the wording be changed to reflect the voluntary nature of this standard.The idea of governing Bitcoin through voting is futile as it would lead to the collapse of the cryptocurrency. Bitcoin operates on consensus, and attempts to impose concepts such as voting will not work. The core developers do not govern Bitcoin; they are only developers because they do not try to govern. Rather than using a centralized governance structure, Bitcoin relies on decentralized systems that depend on consensus.The co-existence of Core and XT is a step towards decentralization, with both serving as opposition parties that keep each other in check. A two-party system would enable people and businesses to cast Yes/No votes on proposed changes. Finally, the proposal to improve the voting mechanism of Bitcoin suggests adding 8-byte votes into blocks, with miners acting as sensors that collect all the noise and chatter and cast it into a vote. It is suggested that attention should be given to engineering progress on Bitcoin Core rather than subjecting everyone's email inboxes to hundreds of opinions about governance and block size without patches or simulations on an engineering mailing list.The author considers the possibility of building an effective Bitcoin governance and concludes that it is not plausible. Instead, they propose that Core and XT continue to co-exist in parallel, acting as a kind of two-party system with different people, structures, processes, and political standings, keeping each other in check. The sides' respective power will be determined by the number of nodes running and people/businesses on board. They will have to negotiate any significant change at the risk of yet another full fork.The author believes this is a step towards decentralization, proving that Bitcoin is indeed a decentralized system, and that the minority cannot impose its will. The author argues that if the sides agree now, it would be a bad thing because it would mean kicking the governance problem down the road. Instead, they propose that both sides should start thinking of themselves as opposition parties, with people and businesses ultimately deciding through a Yes/No vote on proposed changes. This new reality requires an improved voting mechanism for Bitcoin, which could include adding something like 8-byte votes into blocks, with miners serving as 'hubs,' collecting all the noise and chatter and casting it into a vote. 2015-07-01T17:28:30+00:00 + In an email dated July 1st, 2015, Jeffrey Paul requested that discussions on a certain list be limited to the research and development of Bitcoin Core. He argued that if this was not the purpose of the list, then it was misleadingly named. Paul suggested that if Bitcoin Core development is to be considered independent from development of Bitcoin protocol, then it needs its own separate list. The email included two non-text attachments, one being a pgp-key and the other being a digital signature.There is a common misconception that the core developers of Bitcoin govern the cryptocurrency. However, it is important to note that they set standards instead of governing it. This standard is voluntary and its importance in defining consensus rules is subject to speculation. The amount of influence core developers have on Bitcoin depends on specific circumstances. It is suggested that the wording be changed to reflect the voluntary nature of this standard.The idea of governing Bitcoin through voting is futile as it would lead to the collapse of the cryptocurrency. Bitcoin operates on consensus, and attempts to impose concepts such as voting will not work. The core developers do not govern Bitcoin; they are only developers because they do not try to govern. Rather than using a centralized governance structure, Bitcoin relies on decentralized systems that depend on consensus.The co-existence of Core and XT is a step towards decentralization, with both serving as opposition parties that keep each other in check. A two-party system would enable people and businesses to cast Yes/No votes on proposed changes. Finally, the proposal to improve the voting mechanism of Bitcoin suggests adding 8-byte votes into blocks, with miners acting as sensors that collect all the noise and chatter and cast it into a vote. It is suggested that attention should be given to engineering progress on Bitcoin Core rather than subjecting everyone's email inboxes to hundreds of opinions about governance and block size without patches or simulations on an engineering mailing list.The author considers the possibility of building an effective Bitcoin governance and concludes that it is not plausible. Instead, they propose that Core and XT continue to co-exist in parallel, acting as a kind of two-party system with different people, structures, processes, and political standings, keeping each other in check. The sides' respective power will be determined by the number of nodes running and people/businesses on board. They will have to negotiate any significant change at the risk of yet another full fork.The author believes this is a step towards decentralization, proving that Bitcoin is indeed a decentralized system, and that the minority cannot impose its will. The author argues that if the sides agree now, it would be a bad thing because it would mean kicking the governance problem down the road. Instead, they propose that both sides should start thinking of themselves as opposition parties, with people and businesses ultimately deciding through a Yes/No vote on proposed changes. This new reality requires an improved voting mechanism for Bitcoin, which could include adding something like 8-byte votes into blocks, with miners serving as 'hubs,' collecting all the noise and chatter and casting it into a vote. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Block-size-following-technological-growth.xml b/static/bitcoin-dev/July_2015/combined_Block-size-following-technological-growth.xml index 732ea9516f..362179cf8a 100644 --- a/static/bitcoin-dev/July_2015/combined_Block-size-following-technological-growth.xml +++ b/static/bitcoin-dev/July_2015/combined_Block-size-following-technological-growth.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block size following technological growth - 2023-08-01T14:46:20.405973+00:00 + 2025-10-11T22:01:23.068480+00:00 + python-feedgen Elliot Olds 2015-08-11 05:48:17+00:00 @@ -259,13 +260,13 @@ - python-feedgen + 2 Combined summary - Block size following technological growth - 2023-08-01T14:46:20.407923+00:00 + 2025-10-11T22:01:23.068726+00:00 - In a series of email conversations, various individuals discussed the block size limit, transaction fees, and mining centralization in Bitcoin. Mike Hearn emphasized the need for a plan to handle sudden spikes in transaction demand and argued against roadblocks that could cause high fees. Elliot Olds and Jorge Timón discussed the trade-off between lower fees and mining centralization, highlighting the risks to decentralization. The concept of a fee market was debated, with concerns raised about hindering growth. Gavin Andresen engaged in multiple exchanges, discussing topics such as minimum fees, block size increase proposals, and preventing centralization.The ongoing debate regarding increasing the block size limit was discussed, with perspectives exchanged on payment demand and user satisfaction. Efforts to grow the user base through killer apps were acknowledged but considered hit and miss. Potential consequences of an oversaturated network were mentioned, emphasizing reliable transaction confirmation. In an exchange between Andresen and Pieter Wuille, they discussed competition for block space. Wuille argued for improving scalability without limiting block space supply, while Andresen believed competition was good but artificial limits were bad. Wuille disagreed but emphasized decentralized control over transactions.Andresen responded to Timón's statement about Bitcoin failing if the block size limit isn't increased, clarifying the urgency without claiming failure. Wuille disagreed with Andresen's view on competition for block space, proposing the development of a fee market. Timón appreciated a more reasonable position from Andresen and urged both sides to focus on resolving questions. Discussions touched upon the harm caused by hitting the block size limit and the need for criteria based on mining centralization. Simulating different block sizes was proposed to make informed decisions.The issue of mining centralization and block size limits were also discussed. Timón argued for a block size limit to limit mining centralization, while Hector Chu challenged Timón to provide a counter-example. Discussions highlighted the complexities surrounding block size limits and their impact on mining centralization. In a discussion about the Bitcoin network, the need for concrete timelines and larger blocks was acknowledged. Bryan Bishop proposed verifying summarizing transactions, and Andresen proposed increasing the block size limit to 2MB by 2021.Pieter proposed increasing the maximum block size to 2MB, Suhas Daftuar approved pending further thoughts, and Jameson Lopp discussed trade-offs between decentralization and growth. Timón preferred a more limited solution before adapting the block size. A post recommended waiting for improvements before adjusting the block size, expressing a preference for a more limited solution. Wuille shared a proposal for long-term scalability, requesting comments from the community.Overall, the discussions revolved around scalability in the Bitcoin network, focusing on the block size limit and potential solutions for long-term scalability. 2015-08-11T05:48:17+00:00 + In a series of email conversations, various individuals discussed the block size limit, transaction fees, and mining centralization in Bitcoin. Mike Hearn emphasized the need for a plan to handle sudden spikes in transaction demand and argued against roadblocks that could cause high fees. Elliot Olds and Jorge Timón discussed the trade-off between lower fees and mining centralization, highlighting the risks to decentralization. The concept of a fee market was debated, with concerns raised about hindering growth. Gavin Andresen engaged in multiple exchanges, discussing topics such as minimum fees, block size increase proposals, and preventing centralization.The ongoing debate regarding increasing the block size limit was discussed, with perspectives exchanged on payment demand and user satisfaction. Efforts to grow the user base through killer apps were acknowledged but considered hit and miss. Potential consequences of an oversaturated network were mentioned, emphasizing reliable transaction confirmation. In an exchange between Andresen and Pieter Wuille, they discussed competition for block space. Wuille argued for improving scalability without limiting block space supply, while Andresen believed competition was good but artificial limits were bad. Wuille disagreed but emphasized decentralized control over transactions.Andresen responded to Timón's statement about Bitcoin failing if the block size limit isn't increased, clarifying the urgency without claiming failure. Wuille disagreed with Andresen's view on competition for block space, proposing the development of a fee market. Timón appreciated a more reasonable position from Andresen and urged both sides to focus on resolving questions. Discussions touched upon the harm caused by hitting the block size limit and the need for criteria based on mining centralization. Simulating different block sizes was proposed to make informed decisions.The issue of mining centralization and block size limits were also discussed. Timón argued for a block size limit to limit mining centralization, while Hector Chu challenged Timón to provide a counter-example. Discussions highlighted the complexities surrounding block size limits and their impact on mining centralization. In a discussion about the Bitcoin network, the need for concrete timelines and larger blocks was acknowledged. Bryan Bishop proposed verifying summarizing transactions, and Andresen proposed increasing the block size limit to 2MB by 2021.Pieter proposed increasing the maximum block size to 2MB, Suhas Daftuar approved pending further thoughts, and Jameson Lopp discussed trade-offs between decentralization and growth. Timón preferred a more limited solution before adapting the block size. A post recommended waiting for improvements before adjusting the block size, expressing a preference for a more limited solution. Wuille shared a proposal for long-term scalability, requesting comments from the community.Overall, the discussions revolved around scalability in the Bitcoin network, focusing on the block size limit and potential solutions for long-term scalability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Can-we-penalize-peers-who-relay-rejected-replacement-txs-.xml b/static/bitcoin-dev/July_2015/combined_Can-we-penalize-peers-who-relay-rejected-replacement-txs-.xml index 86f35ae7bf..95fd5ce886 100644 --- a/static/bitcoin-dev/July_2015/combined_Can-we-penalize-peers-who-relay-rejected-replacement-txs-.xml +++ b/static/bitcoin-dev/July_2015/combined_Can-we-penalize-peers-who-relay-rejected-replacement-txs-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Can we penalize peers who relay rejected replacement txs? - 2023-08-01T14:15:33.442392+00:00 + 2025-10-11T22:01:44.309408+00:00 + python-feedgen Matt Whitlock 2015-07-10 02:00:45+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Can we penalize peers who relay rejected replacement txs? - 2023-08-01T14:15:33.443392+00:00 + 2025-10-11T22:01:44.309559+00:00 - In a message sent on July 9, 2015 at 6:57 pm, Tom Harding discussed the issue of replacing transactions and how conflicts should be relayed in order for the replace-by-anything feature to work. He suggests that acting against the peer is not the solution. In response, Alex Morcos suggested tracking recently-rejected transaction IDs and not getting data from them, which Harding agreed was a good idea. However, he also noted that this approach may not necessarily reduce the load, as there are not many repeated transaction hashes among rejected replacement messages in his log.Matt Whitlock, a Bitcoin developer, reported on the bitcoin-dev mailing list that he was seeing a lot of messages in his log about replacement transactions being rejected due to their paying less in fees than the transactions they would replace. He suggested that each replacement rejection ought to penalize the peer who relayed the offending transaction and if the penalty builds up enough, then the peer could be temporarily banned. However, Alex Morcos offered a suggestion on IRC -- track recently-rejected txid's and don't getdata them. This solution is not to act against the peer.Matt Whitlock is presently running his full node with Peter Todd's full replace-by-fee patch set. Due to the ongoing spam attack, he is seeing a steady stream of these rejection messages, dozens per second at times. The link for the patch set is provided in the email. The idea proposed by Alex Morcos on IRC is to track recently-rejected txid's and don't getdata them. This can only work if conflicts are relayed, so the solution is not to act against the peer.Matt Whitlock is running his full node with Peter Todd's full replace-by-fee patch set. Due to the ongoing spam attack, Matt is seeing a steady stream of replacement transaction rejection messages which could happen legitimately from time to time. However, due to the flood of spam transactions being mostly invalid under RBF rules, he wants to cut off the flood coming into his node by temp-banning the peers who are relaying such invalid replacement transactions. By doing so, the CPU load due to Bitcoind could be reduced as presently there are periods of time in which Bitcoind is pegging a CPU core.Moreover, if enough other nodes also implement this banning rule, then we could potentially cut off the flood of spam right at the source. This would force the spammer to build and publish non-conflicting transactions to continue the attack which could eventually have their fees collected by miners, not just some non-conflicting subset of the spam. Patrick Strateman questioned the practicality of banning peers doing this but Matt did not respond to that. The link to Peter Todd's full replace-by-fee patch set has been provided in the context. 2015-07-10T02:00:45+00:00 + In a message sent on July 9, 2015 at 6:57 pm, Tom Harding discussed the issue of replacing transactions and how conflicts should be relayed in order for the replace-by-anything feature to work. He suggests that acting against the peer is not the solution. In response, Alex Morcos suggested tracking recently-rejected transaction IDs and not getting data from them, which Harding agreed was a good idea. However, he also noted that this approach may not necessarily reduce the load, as there are not many repeated transaction hashes among rejected replacement messages in his log.Matt Whitlock, a Bitcoin developer, reported on the bitcoin-dev mailing list that he was seeing a lot of messages in his log about replacement transactions being rejected due to their paying less in fees than the transactions they would replace. He suggested that each replacement rejection ought to penalize the peer who relayed the offending transaction and if the penalty builds up enough, then the peer could be temporarily banned. However, Alex Morcos offered a suggestion on IRC -- track recently-rejected txid's and don't getdata them. This solution is not to act against the peer.Matt Whitlock is presently running his full node with Peter Todd's full replace-by-fee patch set. Due to the ongoing spam attack, he is seeing a steady stream of these rejection messages, dozens per second at times. The link for the patch set is provided in the email. The idea proposed by Alex Morcos on IRC is to track recently-rejected txid's and don't getdata them. This can only work if conflicts are relayed, so the solution is not to act against the peer.Matt Whitlock is running his full node with Peter Todd's full replace-by-fee patch set. Due to the ongoing spam attack, Matt is seeing a steady stream of replacement transaction rejection messages which could happen legitimately from time to time. However, due to the flood of spam transactions being mostly invalid under RBF rules, he wants to cut off the flood coming into his node by temp-banning the peers who are relaying such invalid replacement transactions. By doing so, the CPU load due to Bitcoind could be reduced as presently there are periods of time in which Bitcoind is pegging a CPU core.Moreover, if enough other nodes also implement this banning rule, then we could potentially cut off the flood of spam right at the source. This would force the spammer to build and publish non-conflicting transactions to continue the attack which could eventually have their fees collected by miners, not just some non-conflicting subset of the spam. Patrick Strateman questioned the practicality of banning peers doing this but Matt did not respond to that. The link to Peter Todd's full replace-by-fee patch set has been provided in the context. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Consensus-fork-activation-thresholds-Block-nTime-vs-median-time-vs-block-nHeight.xml b/static/bitcoin-dev/July_2015/combined_Consensus-fork-activation-thresholds-Block-nTime-vs-median-time-vs-block-nHeight.xml index 5c71e7dd92..43155453c6 100644 --- a/static/bitcoin-dev/July_2015/combined_Consensus-fork-activation-thresholds-Block-nTime-vs-median-time-vs-block-nHeight.xml +++ b/static/bitcoin-dev/July_2015/combined_Consensus-fork-activation-thresholds-Block-nTime-vs-median-time-vs-block-nHeight.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight - 2023-08-01T14:42:12.987100+00:00 + 2025-10-11T22:00:51.161825+00:00 + python-feedgen Jorge Timón 2015-08-05 19:29:41+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight - 2023-08-01T14:42:12.987100+00:00 + 2025-10-11T22:00:51.161963+00:00 - In a discussion on the security of bip102, Jorge Timón raises the question of whether miners' upgrade confirmation is necessary for uncontroversial hard forks. He suggests that without a strong supermajority of miner support, the fork risks attack and proposes requiring 95% approval as a minimum safety requirement. However, there is disagreement on this point. Peter Todd clarifies that a strong supermajority of miner support is needed to prevent attacks and highlights the option for miners to defeat forks without their approval, such as creating their own fork with a new consensus algorithm or attacking the unwanted chain. In August 2015, Jorge Timón sends a message to the bitcoin-dev mailing list discussing the issue of miners' upgrade confirmation for uncontroversial hard forks. The message emphasizes the need for a strong supermajority of miner support to prevent attacks and suggests requiring 95% approval as a minimum safety requirement. It also mentions Hearn's proposal of using centralized checkpoints to override PoW consensus but raises legal concerns about this option. The message suggests that miners have various options to defeat forks without their approval, including creating their own fork with a new consensus algorithm that requires them to prove they're attacking the unwanted chain. The message cites Garzik's recent 2MB blocks proposal as an example of such a design.In an email conversation, Gavin Andresen proposes using the version and timestamp fields in the block header as the simplest and best option for validating blocks. He explains that this option has advantages such as being available to SPV nodes with no change to the network protocol and allowing parallel and independent block validation. However, it has the disadvantage of not being monotonically increasing. Andresen dismisses discussions about transactions in the memory pool as a distraction and points out that blockchain reorganizations can affect the validity of transactions in the memory pool. He suggests that either median time or block timestamp can be used, but he dislikes using block height due to the uncertainty of knowing the next block time.The author discusses the challenges of defining thresholds for consensus fork activation and presents three options: block.nTime, median time, and block.nHeight. The author argues that block.nHeight's disadvantage is the least problematic but acknowledges that others may disagree. They emphasize the need for a solid criteria to decide which option to use. The author also discusses the combination of a threshold with miners' "voting" and the issues this can create when not being monotonic. Examples are provided for using height and median time to address this problem. The author further explains the example of an emergency consensus fork where the previous block index may not be available. Additionally, they present a scenario of a hardfork allowing miners to create bigger blocks based on transactions reducing the size of the UTXO. The author concludes by suggesting the establishment of a uniform threshold mechanism rather than relying on the three options depending on the fork type, advocating for a more generic solution applicable to any consensus fork. 2015-08-05T19:29:41+00:00 + In a discussion on the security of bip102, Jorge Timón raises the question of whether miners' upgrade confirmation is necessary for uncontroversial hard forks. He suggests that without a strong supermajority of miner support, the fork risks attack and proposes requiring 95% approval as a minimum safety requirement. However, there is disagreement on this point. Peter Todd clarifies that a strong supermajority of miner support is needed to prevent attacks and highlights the option for miners to defeat forks without their approval, such as creating their own fork with a new consensus algorithm or attacking the unwanted chain. In August 2015, Jorge Timón sends a message to the bitcoin-dev mailing list discussing the issue of miners' upgrade confirmation for uncontroversial hard forks. The message emphasizes the need for a strong supermajority of miner support to prevent attacks and suggests requiring 95% approval as a minimum safety requirement. It also mentions Hearn's proposal of using centralized checkpoints to override PoW consensus but raises legal concerns about this option. The message suggests that miners have various options to defeat forks without their approval, including creating their own fork with a new consensus algorithm that requires them to prove they're attacking the unwanted chain. The message cites Garzik's recent 2MB blocks proposal as an example of such a design.In an email conversation, Gavin Andresen proposes using the version and timestamp fields in the block header as the simplest and best option for validating blocks. He explains that this option has advantages such as being available to SPV nodes with no change to the network protocol and allowing parallel and independent block validation. However, it has the disadvantage of not being monotonically increasing. Andresen dismisses discussions about transactions in the memory pool as a distraction and points out that blockchain reorganizations can affect the validity of transactions in the memory pool. He suggests that either median time or block timestamp can be used, but he dislikes using block height due to the uncertainty of knowing the next block time.The author discusses the challenges of defining thresholds for consensus fork activation and presents three options: block.nTime, median time, and block.nHeight. The author argues that block.nHeight's disadvantage is the least problematic but acknowledges that others may disagree. They emphasize the need for a solid criteria to decide which option to use. The author also discusses the combination of a threshold with miners' "voting" and the issues this can create when not being monotonic. Examples are provided for using height and median time to address this problem. The author further explains the example of an emergency consensus fork where the previous block index may not be available. Additionally, they present a scenario of a hardfork allowing miners to create bigger blocks based on transactions reducing the size of the UTXO. The author concludes by suggesting the establishment of a uniform threshold mechanism rather than relying on the three options depending on the fork type, advocating for a more generic solution applicable to any consensus fork. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Defining-a-min-spec.xml b/static/bitcoin-dev/July_2015/combined_Defining-a-min-spec.xml index d05990dd7a..76b1a7c74a 100644 --- a/static/bitcoin-dev/July_2015/combined_Defining-a-min-spec.xml +++ b/static/bitcoin-dev/July_2015/combined_Defining-a-min-spec.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Defining a min spec - 2023-08-01T14:11:57.586942+00:00 + 2025-10-11T22:01:29.443442+00:00 + python-feedgen Jeff Garzik 2015-07-03 10:55:30+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Defining a min spec - 2023-08-01T14:11:57.586942+00:00 + 2025-10-11T22:01:29.443592+00:00 - In an email thread, Jeremy Rubin expresses admiration for Moxie and asks about its development. The creator of Moxie responds that it is designed to be small and efficient, making it easy to audit for security. Rubin offers to work on designing a Bitcoin-specific open-hardware processor.Jean-Paul Kogelman proposes defining a minimum specification (min spec) for Bitcoin Core to reduce the risk of breaking something due to capacity problems. Rubin suggests targeting the RISC-V Rocket architecture for performance. Kogelman agrees that the metrics should be architecture agnostic and hopes to include certain open hardware platforms in the requirements. Owen Gunden supports the idea.The Bitcoin community discusses the idea of a min spec for Bitcoin Core to ensure changes do not break capacity. Performance and open hardware are emphasized for the long-term health of Bitcoin. Moxie is suggested as an alternative architecture due to its compactness and ease of auditing.Kogelman suggests a min spec for Bitcoin Core and explains that it would help determine how changes affect budgets and prevent capacity problems. He proposes working backwards from current parameters and codifying the min spec. A benchmark test could be developed to compare setups to the min spec.Kogelman proposes defining a min spec for Bitcoin Core based on current parameters. This would help reduce the risk of breaking something due to capacity problems and allow for better budget planning. Adjustments could be made as new functionality is added or optimized. A benchmark test could also be developed to compare setups to the min spec and estimate their performance. 2015-07-03T10:55:30+00:00 + In an email thread, Jeremy Rubin expresses admiration for Moxie and asks about its development. The creator of Moxie responds that it is designed to be small and efficient, making it easy to audit for security. Rubin offers to work on designing a Bitcoin-specific open-hardware processor.Jean-Paul Kogelman proposes defining a minimum specification (min spec) for Bitcoin Core to reduce the risk of breaking something due to capacity problems. Rubin suggests targeting the RISC-V Rocket architecture for performance. Kogelman agrees that the metrics should be architecture agnostic and hopes to include certain open hardware platforms in the requirements. Owen Gunden supports the idea.The Bitcoin community discusses the idea of a min spec for Bitcoin Core to ensure changes do not break capacity. Performance and open hardware are emphasized for the long-term health of Bitcoin. Moxie is suggested as an alternative architecture due to its compactness and ease of auditing.Kogelman suggests a min spec for Bitcoin Core and explains that it would help determine how changes affect budgets and prevent capacity problems. He proposes working backwards from current parameters and codifying the min spec. A benchmark test could be developed to compare setups to the min spec.Kogelman proposes defining a min spec for Bitcoin Core based on current parameters. This would help reduce the risk of breaking something due to capacity problems and allow for better budget planning. Adjustments could be made as new functionality is added or optimized. A benchmark test could also be developed to compare setups to the min spec and estimate their performance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Disclosure-consensus-bug-indirectly-solved-by-BIP66.xml b/static/bitcoin-dev/July_2015/combined_Disclosure-consensus-bug-indirectly-solved-by-BIP66.xml index 087d47b4ca..51a6943af8 100644 --- a/static/bitcoin-dev/July_2015/combined_Disclosure-consensus-bug-indirectly-solved-by-BIP66.xml +++ b/static/bitcoin-dev/July_2015/combined_Disclosure-consensus-bug-indirectly-solved-by-BIP66.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Disclosure: consensus bug indirectly solved by BIP66 - 2023-08-01T14:36:53.350752+00:00 + 2025-10-11T22:01:42.187278+00:00 + python-feedgen Mike Hearn 2015-07-29 13:48:16+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Disclosure: consensus bug indirectly solved by BIP66 - 2023-08-01T14:36:53.350752+00:00 + 2025-10-11T22:01:42.187489+00:00 - The Bitcoin development community has been discussing the replacement of OpenSSL with alternative libraries, such as secp256k1, for various uses including RPC SSL and BIP 70. Pieter and Greg have extensively tested secp256k1 and believe it to be more reliable than *SSL libraries. The consensus is that openSSL and its derivatives are not focused on consensus consistency, which can potentially cause their own bug fixes to break Bitcoin. As a result, developers suggest using alternative libraries like LibreSSL or BoringSSL instead.This change in library paves the way for non-OpenSSL signature verification in the future. The community recognizes the importance of security and continues to work towards improving Bitcoin's codebase. A recent vulnerability in OpenSSL has been solved, allowing for the possibility of replacing OpenSSL with alternatives like LibreSSL or BoringSSL.Pieter Wuille, a Bitcoin developer, recently disclosed a vulnerability that he discovered in September 2014. This vulnerability could have led to forking of the blockchain between nodes. However, when BIP66's 95% threshold was reached earlier this month, the vulnerability became unexploitable. The vulnerability specifically affected systems using OpenSSL on a 32-bit system and on 64-bit Windows systems, as well as those that use some non-OpenSSL codebases for parsing signatures.Bitcoin's signature encoding rules are ASN.1 BER encoded, which allows for many different encodings for the same data. Since Bitcoin Core 0.8, a standardness rule has been in effect that only allowed a subset of encodings (DER) for relay and mining. However, any BER encoding remained valid in the blockchain. In practice, though, BER has many edge cases that no single cryptographic codebase, including OpenSSL, Crypto++, BouncyCastle, btcec, and libsecp256k1 library, can parse correctly.The vulnerability is related to the signature encoding rules. One of the features of BER is the ability for internal structures to have a length descriptor whose size itself can be up to 126 bytes. If a transaction with a valid signature using a 5-byte length descriptor were included in the blockchain, it would be accepted by some systems and not by others, potentially resulting in a fork if it were mined into a block.Bitcoin Core 0.10.0 was released with support for BIP66, which introduced a consensus rule for strict DER signatures in the blockchain. This resolved the vulnerability and opens the possibility of using non-OpenSSL signature verification in the near future. 2015-07-29T13:48:16+00:00 + The Bitcoin development community has been discussing the replacement of OpenSSL with alternative libraries, such as secp256k1, for various uses including RPC SSL and BIP 70. Pieter and Greg have extensively tested secp256k1 and believe it to be more reliable than *SSL libraries. The consensus is that openSSL and its derivatives are not focused on consensus consistency, which can potentially cause their own bug fixes to break Bitcoin. As a result, developers suggest using alternative libraries like LibreSSL or BoringSSL instead.This change in library paves the way for non-OpenSSL signature verification in the future. The community recognizes the importance of security and continues to work towards improving Bitcoin's codebase. A recent vulnerability in OpenSSL has been solved, allowing for the possibility of replacing OpenSSL with alternatives like LibreSSL or BoringSSL.Pieter Wuille, a Bitcoin developer, recently disclosed a vulnerability that he discovered in September 2014. This vulnerability could have led to forking of the blockchain between nodes. However, when BIP66's 95% threshold was reached earlier this month, the vulnerability became unexploitable. The vulnerability specifically affected systems using OpenSSL on a 32-bit system and on 64-bit Windows systems, as well as those that use some non-OpenSSL codebases for parsing signatures.Bitcoin's signature encoding rules are ASN.1 BER encoded, which allows for many different encodings for the same data. Since Bitcoin Core 0.8, a standardness rule has been in effect that only allowed a subset of encodings (DER) for relay and mining. However, any BER encoding remained valid in the blockchain. In practice, though, BER has many edge cases that no single cryptographic codebase, including OpenSSL, Crypto++, BouncyCastle, btcec, and libsecp256k1 library, can parse correctly.The vulnerability is related to the signature encoding rules. One of the features of BER is the ability for internal structures to have a length descriptor whose size itself can be up to 126 bytes. If a transaction with a valid signature using a 5-byte length descriptor were included in the blockchain, it would be accepted by some systems and not by others, potentially resulting in a fork if it were mined into a block.Bitcoin Core 0.10.0 was released with support for BIP66, which introduced a consensus rule for strict DER signatures in the blockchain. This resolved the vulnerability and opens the possibility of using non-OpenSSL signature verification in the near future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Do-we-really-need-a-mempool-for-relay-nodes-.xml b/static/bitcoin-dev/July_2015/combined_Do-we-really-need-a-mempool-for-relay-nodes-.xml index 832818fa4c..c13bf29591 100644 --- a/static/bitcoin-dev/July_2015/combined_Do-we-really-need-a-mempool-for-relay-nodes-.xml +++ b/static/bitcoin-dev/July_2015/combined_Do-we-really-need-a-mempool-for-relay-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Do we really need a mempool? (for relay nodes) - 2023-08-01T14:24:18.190993+00:00 + 2025-10-11T22:01:52.805085+00:00 + python-feedgen Jorge Timón 2015-07-20 22:14:41+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Do we really need a mempool? (for relay nodes) - 2023-08-01T14:24:18.190993+00:00 + 2025-10-11T22:01:52.805247+00:00 - In a discussion on bitcoin-dev, Patrick Strateman suggests that relay nodes do not require a mempool but need an anti-DoS mechanism. Wallet nodes, however, can use the mempool for fee estimation. A simple cache for transaction validations could be useful for small values in -maxmempool, and a draft for this has been submitted in pull request #6448 on Github. The proposal is open for review and could potentially be rebased back to versions 0.11 and 0.10 of Bitcoin.The message discusses a proposed dynamic approach to the issue of transaction relay fees. Currently, each additional transaction relayed results in a doubling of the fee/kB and is not considered very dynamic. Instead, a more dynamic fee approach is proposed that would ratchet upward the fee/kB for each additional tx relayed. The proposal suggests that relay nodes be confirming and discarding while wallet nodes retain transactions they've relayed using a mempool. Relay nodes do not need a mempool but need some mechanism to avoid DoS issues. Wallet nodes can use the mempool to estimate fees.To mitigate DoS concerns, it is suggested that there be some per-UTXO limit on bandwidth relayed, which can be accomplished by maintaining some kind of per-UTXO record of bandwidth used. It is also mentioned that IsStandard() could be removed with an increasingly expensive "replacement" policy as a measure against DoS attacks. Miners would still want to have a mempool, but the codebase may prove simpler if it doesn't have to work double-duty for relaying as well.In a post on the Bitcoin-dev mailing list in 2015, Peter Todd discussed whether relay nodes need to keep a record of the transactions they have relayed. He concluded that they do not strictly need to, as long as some mechanism is in place to avoid DoS issues. Todd suggests that a per-UTXO limit on bandwidth relayed could be implemented by maintaining a record of weighted fee and fee/KB. This would provide an upper limit of lifetime bandwidth. Additionally, bandwidth moment-to-moment could be limited by prioritizing transactions with the highest fee/KB when reaching the bandwidth limit.The proposal also suggests that IsStandard() could be removed entirely with an increasingly expensive "replacement" policy to provide anti-DoS measures. Miners would still want to have a mempool, but simplifying the codebase for relaying could make it easier for them. This approach could potentially be used for a scalable general-purpose messaging network paid by coin ownership if the UTXO set is split up and an expiration over time policy is implemented.In summary, the discussion proposes that relay nodes do not need a mempool but require an anti-DoS mechanism. Wallet nodes can use the mempool for fee estimation. To mitigate DoS concerns, a per-UTXO limit on bandwidth relayed is suggested, which can be achieved by maintaining a record of bandwidth used. The removal of IsStandard() with an increasingly expensive "replacement" policy is proposed as a measure against DoS attacks. Miners may still want to have a mempool, but simplifying the codebase for relaying could be beneficial. 2015-07-20T22:14:41+00:00 + In a discussion on bitcoin-dev, Patrick Strateman suggests that relay nodes do not require a mempool but need an anti-DoS mechanism. Wallet nodes, however, can use the mempool for fee estimation. A simple cache for transaction validations could be useful for small values in -maxmempool, and a draft for this has been submitted in pull request #6448 on Github. The proposal is open for review and could potentially be rebased back to versions 0.11 and 0.10 of Bitcoin.The message discusses a proposed dynamic approach to the issue of transaction relay fees. Currently, each additional transaction relayed results in a doubling of the fee/kB and is not considered very dynamic. Instead, a more dynamic fee approach is proposed that would ratchet upward the fee/kB for each additional tx relayed. The proposal suggests that relay nodes be confirming and discarding while wallet nodes retain transactions they've relayed using a mempool. Relay nodes do not need a mempool but need some mechanism to avoid DoS issues. Wallet nodes can use the mempool to estimate fees.To mitigate DoS concerns, it is suggested that there be some per-UTXO limit on bandwidth relayed, which can be accomplished by maintaining some kind of per-UTXO record of bandwidth used. It is also mentioned that IsStandard() could be removed with an increasingly expensive "replacement" policy as a measure against DoS attacks. Miners would still want to have a mempool, but the codebase may prove simpler if it doesn't have to work double-duty for relaying as well.In a post on the Bitcoin-dev mailing list in 2015, Peter Todd discussed whether relay nodes need to keep a record of the transactions they have relayed. He concluded that they do not strictly need to, as long as some mechanism is in place to avoid DoS issues. Todd suggests that a per-UTXO limit on bandwidth relayed could be implemented by maintaining a record of weighted fee and fee/KB. This would provide an upper limit of lifetime bandwidth. Additionally, bandwidth moment-to-moment could be limited by prioritizing transactions with the highest fee/KB when reaching the bandwidth limit.The proposal also suggests that IsStandard() could be removed entirely with an increasingly expensive "replacement" policy to provide anti-DoS measures. Miners would still want to have a mempool, but simplifying the codebase for relaying could make it easier for them. This approach could potentially be used for a scalable general-purpose messaging network paid by coin ownership if the UTXO set is split up and an expiration over time policy is implemented.In summary, the discussion proposes that relay nodes do not need a mempool but require an anti-DoS mechanism. Wallet nodes can use the mempool for fee estimation. To mitigate DoS concerns, a per-UTXO limit on bandwidth relayed is suggested, which can be achieved by maintaining a record of bandwidth used. The removal of IsStandard() with an increasingly expensive "replacement" policy is proposed as a measure against DoS attacks. Miners may still want to have a mempool, but simplifying the codebase for relaying could be beneficial. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml b/static/bitcoin-dev/July_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml index 494e11c1d1..0ee9c4907a 100644 --- a/static/bitcoin-dev/July_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml +++ b/static/bitcoin-dev/July_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP : fixed-schedule block size increase - 2023-08-01T13:34:19.646161+00:00 + 2025-10-11T22:01:33.692603+00:00 + python-feedgen odinn 2015-08-19 03:45:47+00:00 @@ -251,13 +252,13 @@ - python-feedgen + 2 Combined summary - Draft BIP : fixed-schedule block size increase - 2023-08-01T13:34:19.647154+00:00 + 2025-10-11T22:01:33.692876+00:00 - A recent release by XT author(s) has not shown any sign of moving towards an "increasing consensus" version. However, the BIP authors are working together to create something meaningful and useful. Visualizations or graphs of miner votes on BIP 100 and BIP 101 are expected. Tier Nolan suggests making available a version of XT with only block size changes to address mining pools' concerns about its experimental nature. Additionally, there is discussion about combining BIP 100 and BIP 101 to increase consensus.In an email conversation, Tier Nolan suggested that miners vote to decide the soft limit for block size. However, one member argued against it, stating that it may lead to an anti-miner hardfork instead of a softfork. The discussion also referenced BIP99 and potential scenarios for reducing the supply.A suggestion was made to create a fourth test network with large blocks from the genesis onwards instead of replacing most of Testnet with a specialized test chain. Multiple test networks using the same code were also suggested.In a discussion on the Bitcoin-dev mailing list, Ross Nicoll suggested using a minimum height as a solution for activating hardforks. However, BIP99 recommended a minimum height plus 95% mining upgrade confirmation for uncontroversial hardforks. The activation discussion for general hardforks was inconclusive.Tier Nolan proposed making a version of Bitcoin XT with only blocksize changes available to address mining pools' concerns. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes, and the consensus measuring code could be removed. Satoshi Nakamoto's original proposal for a block height comparison could be used, and the state storing code could be eliminated by using the standard "counting" upgrade system.There is discussion about combining BIP 100 and BIP 101 to increase consensus. The proposed combined version includes a miner vote threshold, a notice period or earliest start time, a block size default target set to 1 MB, a soft limit set to 1MB, and a hard limit set to 8MB with doubling every two years. Miners could leave the 1MB limit initially, but the vote is to get the option to increase the block size. Legacy clients would remain until >80% of miners vote to raise the limit and a miner produces a >1MB block.The dismissal of a formal process in Bitcoin is criticized for not properly evaluating proposed changes. Some developers believe their knowledge makes them superior to outside experts. However, this attitude can be detrimental to Bitcoin's progress. It is suggested that a well-defined and well-documented evaluation process should be introduced to ensure the safety of proposed changes.In an email exchange, Peter Todd and Gavin Andresen discuss the impact of larger blocks on miners with poor connectivity. The suggestion to rent a server on the other side of the bottleneck is countered by concerns about insecure infrastructure. The discussion also highlights the centralizing effect of mining control and the need for proposals to counter it.Gavin Andresen promised to write a BIP after implementing the increase-the-maximum-block-size code. The discussion mentions updating contact information and upcoming events.In an email conversation, Gavin Andresen discusses the analogy of a suspension bridge with limited traffic capacity and tolls increasing as demand rises. The proposed change is to expand the bridge, but careful analysis is needed. Civil engineering teaches us not to give in to political pressure until consequences are well understood.The discussion on the Bitcoin-dev mailing list focuses on the centralizing effect of miner connectivity and its impact on block propagation. Simulations show that miners with poor connectivity are negatively affected. Suggestions to work around this include renting a server on the other side of the bottleneck, but concerns about insecure infrastructure are raised. The discussion also addresses the need for proposals to counter mining centralization.Moving averages are compared to fixed growth, but they have limitations. Gavin Andresen suggests changing the default 'target' block size to the average of the last N blocks to create healthy "fee pressure" in the system.In an email conversation, Gavin Andresen and Will discuss block size. The suggestion is made to make the lazy miners' default choice grow at a slower rate than the average, which would encourage more fee pressure in the system.In 2017, Gavin Andresen put forward a Bitcoin Improvement Proposal (BIP) to increase the maximum block size from one megabyte to 8,000,000 bytes. The proposal suggests doubling the block size every two years until it reaches 8,192,000,000 bytes. To activate this change, a hash-power supermajority vote is required. This proposal allows miners, merchants, and users running full-nodes ample time to upgrade their software to support larger blocks.It's important to note that this proposed change is a hard-forking modification to the Bitcoin protocol. Therefore, anyone running code that fully validates blocks must upgrade their software before the activation time. Failure to do so may result in rejecting a 2015-08-19T03:45:47+00:00 + A recent release by XT author(s) has not shown any sign of moving towards an "increasing consensus" version. However, the BIP authors are working together to create something meaningful and useful. Visualizations or graphs of miner votes on BIP 100 and BIP 101 are expected. Tier Nolan suggests making available a version of XT with only block size changes to address mining pools' concerns about its experimental nature. Additionally, there is discussion about combining BIP 100 and BIP 101 to increase consensus.In an email conversation, Tier Nolan suggested that miners vote to decide the soft limit for block size. However, one member argued against it, stating that it may lead to an anti-miner hardfork instead of a softfork. The discussion also referenced BIP99 and potential scenarios for reducing the supply.A suggestion was made to create a fourth test network with large blocks from the genesis onwards instead of replacing most of Testnet with a specialized test chain. Multiple test networks using the same code were also suggested.In a discussion on the Bitcoin-dev mailing list, Ross Nicoll suggested using a minimum height as a solution for activating hardforks. However, BIP99 recommended a minimum height plus 95% mining upgrade confirmation for uncontroversial hardforks. The activation discussion for general hardforks was inconclusive.Tier Nolan proposed making a version of Bitcoin XT with only blocksize changes available to address mining pools' concerns. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes, and the consensus measuring code could be removed. Satoshi Nakamoto's original proposal for a block height comparison could be used, and the state storing code could be eliminated by using the standard "counting" upgrade system.There is discussion about combining BIP 100 and BIP 101 to increase consensus. The proposed combined version includes a miner vote threshold, a notice period or earliest start time, a block size default target set to 1 MB, a soft limit set to 1MB, and a hard limit set to 8MB with doubling every two years. Miners could leave the 1MB limit initially, but the vote is to get the option to increase the block size. Legacy clients would remain until >80% of miners vote to raise the limit and a miner produces a >1MB block.The dismissal of a formal process in Bitcoin is criticized for not properly evaluating proposed changes. Some developers believe their knowledge makes them superior to outside experts. However, this attitude can be detrimental to Bitcoin's progress. It is suggested that a well-defined and well-documented evaluation process should be introduced to ensure the safety of proposed changes.In an email exchange, Peter Todd and Gavin Andresen discuss the impact of larger blocks on miners with poor connectivity. The suggestion to rent a server on the other side of the bottleneck is countered by concerns about insecure infrastructure. The discussion also highlights the centralizing effect of mining control and the need for proposals to counter it.Gavin Andresen promised to write a BIP after implementing the increase-the-maximum-block-size code. The discussion mentions updating contact information and upcoming events.In an email conversation, Gavin Andresen discusses the analogy of a suspension bridge with limited traffic capacity and tolls increasing as demand rises. The proposed change is to expand the bridge, but careful analysis is needed. Civil engineering teaches us not to give in to political pressure until consequences are well understood.The discussion on the Bitcoin-dev mailing list focuses on the centralizing effect of miner connectivity and its impact on block propagation. Simulations show that miners with poor connectivity are negatively affected. Suggestions to work around this include renting a server on the other side of the bottleneck, but concerns about insecure infrastructure are raised. The discussion also addresses the need for proposals to counter mining centralization.Moving averages are compared to fixed growth, but they have limitations. Gavin Andresen suggests changing the default 'target' block size to the average of the last N blocks to create healthy "fee pressure" in the system.In an email conversation, Gavin Andresen and Will discuss block size. The suggestion is made to make the lazy miners' default choice grow at a slower rate than the average, which would encourage more fee pressure in the system.In 2017, Gavin Andresen put forward a Bitcoin Improvement Proposal (BIP) to increase the maximum block size from one megabyte to 8,000,000 bytes. The proposal suggests doubling the block size every two years until it reaches 8,192,000,000 bytes. To activate this change, a hash-power supermajority vote is required. This proposal allows miners, merchants, and users running full-nodes ample time to upgrade their software to support larger blocks.It's important to note that this proposed change is a hard-forking modification to the Bitcoin protocol. Therefore, anyone running code that fully validates blocks must upgrade their software before the activation time. Failure to do so may result in rejecting a - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Electrum-Server-Speed-Test.xml b/static/bitcoin-dev/July_2015/combined_Electrum-Server-Speed-Test.xml index f75b668d8c..8be7555916 100644 --- a/static/bitcoin-dev/July_2015/combined_Electrum-Server-Speed-Test.xml +++ b/static/bitcoin-dev/July_2015/combined_Electrum-Server-Speed-Test.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Electrum Server Speed Test - 2023-08-01T14:34:15.543142+00:00 + 2025-10-11T22:02:16.231464+00:00 + python-feedgen Slurms MacKenzie 2015-07-23 18:26:41+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Electrum Server Speed Test - 2023-08-01T14:34:15.543142+00:00 + 2025-10-11T22:02:16.231626+00:00 - In this email exchange, Eric Voskuil seeks clarification on the Electrum Server Speed Test. He wants to know if the time taken to process into the index includes transport and/or block validation by bitcoind or if it is exclusively the time taken by Electrum Server to index a validated block. ThomasV explains that validation in bitcoind occurs before the time on the wall for electrum-server.The conversation revolves around the performance of the Electrum server software. It is mentioned that the server requires a fully indexed Bitcoin Core daemon running and produces sizable external indexes to allow SPV clients to quickly retrieve their history. The logs from the electrum-server console show that it takes approximately 3.7 minutes per megabyte of block to process into the index on a modest-high end dedicated server. Based on the current inter-block time of 9.8 minutes, an electrum-server instance running on such a server can support up to 2.64 MB block sizes before permanently falling behind the chain.There is a debate about whether this data should be used to limit the block size or improve Electrum Server's database performance. One participant suggests focusing on performance improvements rather than limiting the block size. Slurms MacKenzie provides data points indicating the processing time for an electrum-server instance running on a modest-high end dedicated server. This information suggests that improving Electrum Server's database performance may be necessary instead of holding back Bitcoin.The Electrum server software has known performance issues, including loading data one block at a time and being single-threaded on transactions within the block. To address these concerns, an alternative implementation of the Electrum server has been created. It uses mongodb as a key-value store and bitcoinj for block and transaction parsing. This implementation is heavily multithreaded and interacts with all tested clients. The recent blocks imported and their import times are available in a pastebin link, showing the usage of 347G of mongodb storage and an 8-core Intel(R) Xeon(R) CPU E5430 @ 2.66GHz for processing.The alternative implementation aims to improve the performance and efficiency of the Electrum server. It tackles the loading issues by using mongodb as a key-value store and bitcoinj for parsing blocks and transactions. In contrast, the original Electrum server requires a fully indexed Bitcoin Core daemon and produces sizable external indexes for SPV clients to retrieve their history quickly. The logs from the electrum-server console indicate that it takes approximately 3.7 minutes per megabyte of block to process into the index. An instance running on a modest-high end dedicated server can handle up to 2.64 MB block sizes before permanently falling behind the chain. These findings provide insight into the resources required for operating an Electrum server.Overall, this article presents a quantitative analysis of the Electrum server software's performance under load. It highlights the reliance on distributed servers hosted by volunteers and the need for a fully indexed Bitcoin Core daemon. The data presented demonstrates the time taken to process blocks into the index, the potential block size limits, and the file sizes generated during the operation of an Electrum server. 2015-07-23T18:26:41+00:00 + In this email exchange, Eric Voskuil seeks clarification on the Electrum Server Speed Test. He wants to know if the time taken to process into the index includes transport and/or block validation by bitcoind or if it is exclusively the time taken by Electrum Server to index a validated block. ThomasV explains that validation in bitcoind occurs before the time on the wall for electrum-server.The conversation revolves around the performance of the Electrum server software. It is mentioned that the server requires a fully indexed Bitcoin Core daemon running and produces sizable external indexes to allow SPV clients to quickly retrieve their history. The logs from the electrum-server console show that it takes approximately 3.7 minutes per megabyte of block to process into the index on a modest-high end dedicated server. Based on the current inter-block time of 9.8 minutes, an electrum-server instance running on such a server can support up to 2.64 MB block sizes before permanently falling behind the chain.There is a debate about whether this data should be used to limit the block size or improve Electrum Server's database performance. One participant suggests focusing on performance improvements rather than limiting the block size. Slurms MacKenzie provides data points indicating the processing time for an electrum-server instance running on a modest-high end dedicated server. This information suggests that improving Electrum Server's database performance may be necessary instead of holding back Bitcoin.The Electrum server software has known performance issues, including loading data one block at a time and being single-threaded on transactions within the block. To address these concerns, an alternative implementation of the Electrum server has been created. It uses mongodb as a key-value store and bitcoinj for block and transaction parsing. This implementation is heavily multithreaded and interacts with all tested clients. The recent blocks imported and their import times are available in a pastebin link, showing the usage of 347G of mongodb storage and an 8-core Intel(R) Xeon(R) CPU E5430 @ 2.66GHz for processing.The alternative implementation aims to improve the performance and efficiency of the Electrum server. It tackles the loading issues by using mongodb as a key-value store and bitcoinj for parsing blocks and transactions. In contrast, the original Electrum server requires a fully indexed Bitcoin Core daemon and produces sizable external indexes for SPV clients to retrieve their history quickly. The logs from the electrum-server console indicate that it takes approximately 3.7 minutes per megabyte of block to process into the index. An instance running on a modest-high end dedicated server can handle up to 2.64 MB block sizes before permanently falling behind the chain. These findings provide insight into the resources required for operating an Electrum server.Overall, this article presents a quantitative analysis of the Electrum server software's performance under load. It highlights the reliance on distributed servers hosted by volunteers and the need for a fully indexed Bitcoin Core daemon. The data presented demonstrates the time taken to process blocks into the index, the potential block size limits, and the file sizes generated during the operation of an Electrum server. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_For-discussion-limit-transaction-size-to-mitigate-CVE-2013-2292.xml b/static/bitcoin-dev/July_2015/combined_For-discussion-limit-transaction-size-to-mitigate-CVE-2013-2292.xml index 49371739b3..70f8f41fa6 100644 --- a/static/bitcoin-dev/July_2015/combined_For-discussion-limit-transaction-size-to-mitigate-CVE-2013-2292.xml +++ b/static/bitcoin-dev/July_2015/combined_For-discussion-limit-transaction-size-to-mitigate-CVE-2013-2292.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - For discussion: limit transaction size to mitigate CVE-2013-2292 - 2023-08-01T14:25:11.054095+00:00 + 2025-10-11T22:02:28.981174+00:00 + python-feedgen odinn 2015-07-25 00:47:51+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - For discussion: limit transaction size to mitigate CVE-2013-2292 - 2023-08-01T14:25:11.054095+00:00 + 2025-10-11T22:02:28.981323+00:00 - Gavin Andresen, the former lead developer of Bitcoin, has proposed new consensus rules to address potential CPU exhaustion denial-of-service attacks. The proposal suggests limiting the number of ECDSA signature verifications and bytes hashed per block. This change would require updates to transaction assembly and validation software. Transactions larger than 100,000 bytes have already been considered "non-standard" for years, making the proposal compatible with existing transaction-creation software. The proposal will be deployed with either BIP 100 or BIP 101.The discussion surrounding the proposal highlights the need to consider N^2 costs related to repeated hashing in checksig, which the current approach overlooks. Gavin Andresen agrees with this concern but emphasizes that counting signature operations is not as straightforward as checking transaction size. He proposes adding a field for N_SIG_OPS in transaction metadata to simplify implementation. He also suggests using SIGHASH_ANYONECANPAY instead of SIGHASH_ALL for transactions with many inputs to expedite validation. Feedback from maintainers of other full implementations is sought regarding the implementation of counting hashed bytes as a consensus rule.Another member of the bitcoin-dev group argues that limiting transaction size alone is an indirect approach that fails to address the N^2 costs. They propose a more direct approach that would be less restrictive. However, Gavin Andresen points out that accurately counting the number of signature operations is necessary and preferable to imposing a limit on transaction size.In response to concerns raised about decreasing the maximum transaction size limit, Gavin Andresen argues against adding unnecessary complexity to code for an unlikely scenario. He also clarifies that transaction size limits are unrelated to the issue being addressed in the current Bitcoin Improvement Proposal (BIP).Gavin Andresen suggests limiting the maximum size of a transaction included in a block to mitigate potential CPU exhaustion denial-of-service attacks. The proposal addresses the computation of signature hashes for OP_CHECKSIG/OP_CHECKMULTISIG, which could result in significant validation times for maliciously constructed blocks. The proposed change would limit the serialized size of a transaction to 100,000 bytes. However, concerns are raised about rendering future applications involving larger signatures unspendable. Alternative approaches include limiting the number of signature operations and making rule exceptions for certain transactions.The proposal drafted by Gavin Andresen aims to prevent a potential CPU exhaustion attack. It suggests limiting the size of a transaction included in a block to mitigate denial-of-service attacks. Sergio Demian Lerner's report on the computation of signature hashes for OP_CHECKSIG/OP_CHECKMULTISIG highlights the need for this mitigation. Transactions larger than 100,000 bytes have already been considered "non-standard," making the proposed change compatible with existing software. However, updates to transaction assembly and validation software are necessary. Alternatives to the proposal include limiting the number of signature operations or fixing the SIG opcodes. References provided include Sergio Demian Lerner's original report. 2015-07-25T00:47:51+00:00 + Gavin Andresen, the former lead developer of Bitcoin, has proposed new consensus rules to address potential CPU exhaustion denial-of-service attacks. The proposal suggests limiting the number of ECDSA signature verifications and bytes hashed per block. This change would require updates to transaction assembly and validation software. Transactions larger than 100,000 bytes have already been considered "non-standard" for years, making the proposal compatible with existing transaction-creation software. The proposal will be deployed with either BIP 100 or BIP 101.The discussion surrounding the proposal highlights the need to consider N^2 costs related to repeated hashing in checksig, which the current approach overlooks. Gavin Andresen agrees with this concern but emphasizes that counting signature operations is not as straightforward as checking transaction size. He proposes adding a field for N_SIG_OPS in transaction metadata to simplify implementation. He also suggests using SIGHASH_ANYONECANPAY instead of SIGHASH_ALL for transactions with many inputs to expedite validation. Feedback from maintainers of other full implementations is sought regarding the implementation of counting hashed bytes as a consensus rule.Another member of the bitcoin-dev group argues that limiting transaction size alone is an indirect approach that fails to address the N^2 costs. They propose a more direct approach that would be less restrictive. However, Gavin Andresen points out that accurately counting the number of signature operations is necessary and preferable to imposing a limit on transaction size.In response to concerns raised about decreasing the maximum transaction size limit, Gavin Andresen argues against adding unnecessary complexity to code for an unlikely scenario. He also clarifies that transaction size limits are unrelated to the issue being addressed in the current Bitcoin Improvement Proposal (BIP).Gavin Andresen suggests limiting the maximum size of a transaction included in a block to mitigate potential CPU exhaustion denial-of-service attacks. The proposal addresses the computation of signature hashes for OP_CHECKSIG/OP_CHECKMULTISIG, which could result in significant validation times for maliciously constructed blocks. The proposed change would limit the serialized size of a transaction to 100,000 bytes. However, concerns are raised about rendering future applications involving larger signatures unspendable. Alternative approaches include limiting the number of signature operations and making rule exceptions for certain transactions.The proposal drafted by Gavin Andresen aims to prevent a potential CPU exhaustion attack. It suggests limiting the size of a transaction included in a block to mitigate denial-of-service attacks. Sergio Demian Lerner's report on the computation of signature hashes for OP_CHECKSIG/OP_CHECKMULTISIG highlights the need for this mitigation. Transactions larger than 100,000 bytes have already been considered "non-standard," making the proposed change compatible with existing software. However, updates to transaction assembly and validation software are necessary. Alternatives to the proposal include limiting the number of signature operations or fixing the SIG opcodes. References provided include Sergio Demian Lerner's original report. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Fork-of-invalid-blocks-due-to-BIP66-violations.xml b/static/bitcoin-dev/July_2015/combined_Fork-of-invalid-blocks-due-to-BIP66-violations.xml index b8595999d1..4379a56427 100644 --- a/static/bitcoin-dev/July_2015/combined_Fork-of-invalid-blocks-due-to-BIP66-violations.xml +++ b/static/bitcoin-dev/July_2015/combined_Fork-of-invalid-blocks-due-to-BIP66-violations.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fork of invalid blocks due to BIP66 violations - 2023-08-01T14:13:38.185615+00:00 + 2025-10-11T22:02:20.480011+00:00 + python-feedgen Tier Nolan 2015-07-05 01:32:16+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Fork of invalid blocks due to BIP66 violations - 2023-08-01T14:13:38.186614+00:00 + 2025-10-11T22:02:20.480186+00:00 - In an email exchange between Justus Ranvier and Adam Back, they discussed the scalability problem of Bitcoin and how it can be solved by assuming that SPV clients are able to perform validity checks without any state outside a single transaction or block. They also mentioned the importance of adding commitment information to extra trees and storing additional metadata with each block. The conversation also touched on the potential benefits of making P2SH mandatory for transaction validation.Another email conversation between Justus Ranvier and an unknown recipient discussed the validation of committed UTXO sets and the use of merkle paths to prove their correctness. They also emphasized the need for short proofs for each step and the importance of proving all the necessary commitments.The conversation then shifted to the potential use of fraud proofs to improve blockchain validation for full nodes and SPV nodes. They discussed the use of UTXO set commitments and ordered transactions in the merkle tree to make producing these proofs easier and more efficient.Peter Todd pointed out the reliance of SPV on other nodes to check the rules and the lack of straightforward solutions to this problem. Justus Ranvier suggested that validating full nodes could broadcast proofs to SPV nodes explaining why the branch with the most proof of work is invalid. They also discussed the use of UTXO set commitments and ordering transactions in the merkle tree to simplify the process of proving non-existent outputs or withheld transaction data.The discussion about SPV mining highlighted the risks and potential dangers associated with relying on headers only for mining without fully validating the chain. They discussed the possibility of implementing rules and safeguards to prevent illegal forks and ensure safety during the mining process.Raystonn discussed the need for SPV clients to check node versions for safety and the issue of trusting nodes to check the rules. Gregory Maxwell suggested upgrading the version check when new BIPs go into effect. They also discussed the high percentage of hashrate on the network that is engaged in SPV mining and the recent failure mode due to BIP66 violation.The conversation also touched on the recent Bitcoin fork caused by a large portion of the hashrate engaging in SPV mining. Miners were able to mine on top of the longest chain they knew about without fully validating the blocks. Custom patches were used to increase mining efficiency and compensate for low profit margins.Overall, the conversations revolved around finding solutions to improve scalability, validate transactions, prevent fraud, and ensure the safety and efficiency of blockchain validation processes. 2015-07-05T01:32:16+00:00 + In an email exchange between Justus Ranvier and Adam Back, they discussed the scalability problem of Bitcoin and how it can be solved by assuming that SPV clients are able to perform validity checks without any state outside a single transaction or block. They also mentioned the importance of adding commitment information to extra trees and storing additional metadata with each block. The conversation also touched on the potential benefits of making P2SH mandatory for transaction validation.Another email conversation between Justus Ranvier and an unknown recipient discussed the validation of committed UTXO sets and the use of merkle paths to prove their correctness. They also emphasized the need for short proofs for each step and the importance of proving all the necessary commitments.The conversation then shifted to the potential use of fraud proofs to improve blockchain validation for full nodes and SPV nodes. They discussed the use of UTXO set commitments and ordered transactions in the merkle tree to make producing these proofs easier and more efficient.Peter Todd pointed out the reliance of SPV on other nodes to check the rules and the lack of straightforward solutions to this problem. Justus Ranvier suggested that validating full nodes could broadcast proofs to SPV nodes explaining why the branch with the most proof of work is invalid. They also discussed the use of UTXO set commitments and ordering transactions in the merkle tree to simplify the process of proving non-existent outputs or withheld transaction data.The discussion about SPV mining highlighted the risks and potential dangers associated with relying on headers only for mining without fully validating the chain. They discussed the possibility of implementing rules and safeguards to prevent illegal forks and ensure safety during the mining process.Raystonn discussed the need for SPV clients to check node versions for safety and the issue of trusting nodes to check the rules. Gregory Maxwell suggested upgrading the version check when new BIPs go into effect. They also discussed the high percentage of hashrate on the network that is engaged in SPV mining and the recent failure mode due to BIP66 violation.The conversation also touched on the recent Bitcoin fork caused by a large portion of the hashrate engaging in SPV mining. Miners were able to mine on top of the longest chain they knew about without fully validating the blocks. Custom patches were used to increase mining efficiency and compensate for low profit margins.Overall, the conversations revolved around finding solutions to improve scalability, validate transactions, prevent fraud, and ensure the safety and efficiency of blockchain validation processes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Introduce-N-testnet-chains-to-test-different-block-sizes.xml b/static/bitcoin-dev/July_2015/combined_Introduce-N-testnet-chains-to-test-different-block-sizes.xml index c464d299df..55ab82a890 100644 --- a/static/bitcoin-dev/July_2015/combined_Introduce-N-testnet-chains-to-test-different-block-sizes.xml +++ b/static/bitcoin-dev/July_2015/combined_Introduce-N-testnet-chains-to-test-different-block-sizes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Introduce N testnet chains to test different block sizes - 2023-08-01T14:14:51.296657+00:00 + 2025-10-11T22:01:25.193705+00:00 + python-feedgen Jorge Timón 2015-08-19 18:30:31+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Introduce N testnet chains to test different block sizes - 2023-08-01T14:14:51.296657+00:00 + 2025-10-11T22:01:25.193869+00:00 - In a recent conversation within the Bitcoin development community, Danny Thorpe suggested deploying an uncontroversial hard fork in Bitcoin's main chain first in testnet3. Another member expressed gratitude for the suggestion and raised a question about how big-block testnet nodes would recognize each other on the peer network. Danny clarified that although these nodes share the same port and magic numbers, each testchain has a different genesis block, which means they will reject blocks from any other testchain right from the beginning. However, he mentioned that nodes can be manually connected to achieve the desired network topology for testing purposes. Danny also noted that he didn't have time to write tests and simulations himself but encouraged others to do so and offered to answer any further questions.On Github, a pull request has been created with the aim of simplifying the testing of different block sizes. If this pull request is merged, it would not only facilitate future block size changes but also encourage more people to test and simulate various consensus maximum block sizes. This, in turn, would simplify the overall work process. The creator of the pull request specifically requested that individuals refrain from discussing the block size issue itself in both the post and the pull request. The size itself is referred to as "-blocksize". Those interested can use the branch or a fork of it for testing purposes. The listed dependencies for this pull request include Chainparams: Translations, CTestNetParams, and CRegTestParams, all of which extend directly from CChainParams. As the pull request progresses and merges occur, the list of dependencies will be updated accordingly. 2015-08-19T18:30:31+00:00 + In a recent conversation within the Bitcoin development community, Danny Thorpe suggested deploying an uncontroversial hard fork in Bitcoin's main chain first in testnet3. Another member expressed gratitude for the suggestion and raised a question about how big-block testnet nodes would recognize each other on the peer network. Danny clarified that although these nodes share the same port and magic numbers, each testchain has a different genesis block, which means they will reject blocks from any other testchain right from the beginning. However, he mentioned that nodes can be manually connected to achieve the desired network topology for testing purposes. Danny also noted that he didn't have time to write tests and simulations himself but encouraged others to do so and offered to answer any further questions.On Github, a pull request has been created with the aim of simplifying the testing of different block sizes. If this pull request is merged, it would not only facilitate future block size changes but also encourage more people to test and simulate various consensus maximum block sizes. This, in turn, would simplify the overall work process. The creator of the pull request specifically requested that individuals refrain from discussing the block size issue itself in both the post and the pull request. The size itself is referred to as "-blocksize". Those interested can use the branch or a fork of it for testing purposes. The listed dependencies for this pull request include Chainparams: Translations, CTestNetParams, and CRegTestParams, all of which extend directly from CChainParams. As the pull request progresses and merges occur, the list of dependencies will be updated accordingly. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Libconsensus-separated-repository-was-Bitcoin-Core-and-hard-forks-.xml b/static/bitcoin-dev/July_2015/combined_Libconsensus-separated-repository-was-Bitcoin-Core-and-hard-forks-.xml index 246c85ed34..887d302d70 100644 --- a/static/bitcoin-dev/July_2015/combined_Libconsensus-separated-repository-was-Bitcoin-Core-and-hard-forks-.xml +++ b/static/bitcoin-dev/July_2015/combined_Libconsensus-separated-repository-was-Bitcoin-Core-and-hard-forks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Libconsensus separated repository (was Bitcoin Core and hard forks) - 2023-08-01T14:31:40.955368+00:00 + 2025-10-11T22:02:11.973967+00:00 + python-feedgen Jorge Timón 2015-08-29 23:30:39+00:00 @@ -115,13 +116,13 @@ - python-feedgen + 2 Combined summary - Libconsensus separated repository (was Bitcoin Core and hard forks) - 2023-08-01T14:31:40.956377+00:00 + 2025-10-11T22:02:11.974161+00:00 - Bitcoin developer Tamas Blummer has proposed a new infrastructure for enterprise applications, emphasizing the importance of building consensus on the ledger. He believes that enterprises have the resources to solve business problems and that mainstream adoption requires their involvement. To facilitate this, Blummer suggests a slim protocol server with no wallet, RPC, or QT, but with a high-performance remoting API.The discussion also highlights the need for modularization in Bitcoin's code. Modularization allows more people to contribute and review code, reduces risks associated with changes, and enables alternative code bases without fear of consensus bugs. Contributors like Jorge Timón, Wladimir, Pieter, Cory, Jonas Schnelli, and Eric Lombrozo advocate for modularization to resolve political challenges and improve software engineering.There is a focus on separating the BIP process into distinct areas, including consensus rule change proposals, update/deployment mechanisms, hard fork proposals, soft fork proposals, peer policies, RPC, and more. The idea is to specify core protocol layers and interfaces, allowing independent improvements and convergence on a common history and state.Tamas Blummer and Jorge Timón discuss the risks and benefits of re-implementation, refactoring, and copy-pasting in Bitcoin development. Blummer argues that quality is achieved at a high cost and is difficult to maintain over generations of developers. Timón emphasizes the need for code that is not only high quality but also easy to maintain with a development team experiencing high attrition.The conversation delves into the potential implementation of a libconsensus API, which would provide a correctly implemented consensus layer accessible to all Bitcoin developers. Blummer suggests expanding libconsensus to include functions like VerifyTx, VerifyHeader, and VerifyBlock. The plan is for the C API to interface with external storage by passing a function pointer to it.Tamas Blummer discusses his goal of creating an implementation that can extract consensus rules from Bitcoin Core so that they do not need to be re-implemented. He suggests using modern tool sets and a slim API server. Matt Corallo suggests that a libconsensus should ideally have a simple API for blocks and the current chain, with the possibility of pluggable block storage. Tamas Blummer expresses his eagerness to integrate secp256k1 (c) as part of consensus. Jorge Timon highlights the importance of extracting consensus rules from Bitcoin Core to avoid the need for future re-implementations. He proposes steps to implement libconsensus in Bitcoin Core, but acknowledges the risk of consensus fork bugs during the process. Eric Voskuil disagrees with forking Bitcoin Core and suggests separating libconsensus into a separate repository. In a conversation between Wladimir J. van der Laan and Jorge Timón, they discuss the possibility of Bitcoin Core using libconsensus. Wladimir notes the risk of introducing fork bugs if the code is refactored, but expresses support for the change if this can be avoided. They also discuss the need for code review capacity and the possibility of using libsecp256k1 instead of OpenSSL.The discussion focuses on separating current-libconsensus from future-libconsensus in the Bitcoin Core code. The plan is to complete future-libconsensus that implements all consensus rules and expose more functions through its API. There are concerns about code incompatibility and the need for code review capacity. The author maintains a fork of consensus sources until they are properly isolated from the satoshi client. They express willingness to work on the project but note that fear of consensus bugs keeps people on the satoshi client.Eric Voskuil discusses the removal of the OpenSSL dependency in their stack and the activation of BIP66. The need for a separate repository for libconsensus is mentioned to ensure alternative implementations can be consensus-safe.In conclusion, there is a strong discussion about the creation and implementation of libconsensus to extract consensus rules from Bitcoin Core. The goal is to avoid re-implementations and allow for the creation of other blockchains with different rules. There are discussions about the API, pluggable block storage, and the integration of secp256k1 (c). Concerns about code compatibility, code review capacity, and OpenSSL dependency are also addressed.The goal of the Bitcoin Core codebase is to be modularized, allowing for easy swapping out of consensus rules and reducing the risk of consensus fork bugs. Mike Hearn, a Bitcoin developer, expressed his desire for Bitcoin Core to have a benevolent dictator, similar to other free software projects. This is because decentralization still requires someone to make decisions for changes to occur.In an email exchange in 2015, Jorge Timón apologized for mentioning Mike Hearn and diverting attention from the topic at hand. Timón referenced Hearn's desire for a benevolent dictator but clarified that it was not relevant to the discussion of libconsensus, which focuses on alternative implementations and the ability to fork smaller projects without relying on Bitcoin Core.Another email exchange on 2015-08-29T23:30:39+00:00 + Bitcoin developer Tamas Blummer has proposed a new infrastructure for enterprise applications, emphasizing the importance of building consensus on the ledger. He believes that enterprises have the resources to solve business problems and that mainstream adoption requires their involvement. To facilitate this, Blummer suggests a slim protocol server with no wallet, RPC, or QT, but with a high-performance remoting API.The discussion also highlights the need for modularization in Bitcoin's code. Modularization allows more people to contribute and review code, reduces risks associated with changes, and enables alternative code bases without fear of consensus bugs. Contributors like Jorge Timón, Wladimir, Pieter, Cory, Jonas Schnelli, and Eric Lombrozo advocate for modularization to resolve political challenges and improve software engineering.There is a focus on separating the BIP process into distinct areas, including consensus rule change proposals, update/deployment mechanisms, hard fork proposals, soft fork proposals, peer policies, RPC, and more. The idea is to specify core protocol layers and interfaces, allowing independent improvements and convergence on a common history and state.Tamas Blummer and Jorge Timón discuss the risks and benefits of re-implementation, refactoring, and copy-pasting in Bitcoin development. Blummer argues that quality is achieved at a high cost and is difficult to maintain over generations of developers. Timón emphasizes the need for code that is not only high quality but also easy to maintain with a development team experiencing high attrition.The conversation delves into the potential implementation of a libconsensus API, which would provide a correctly implemented consensus layer accessible to all Bitcoin developers. Blummer suggests expanding libconsensus to include functions like VerifyTx, VerifyHeader, and VerifyBlock. The plan is for the C API to interface with external storage by passing a function pointer to it.Tamas Blummer discusses his goal of creating an implementation that can extract consensus rules from Bitcoin Core so that they do not need to be re-implemented. He suggests using modern tool sets and a slim API server. Matt Corallo suggests that a libconsensus should ideally have a simple API for blocks and the current chain, with the possibility of pluggable block storage. Tamas Blummer expresses his eagerness to integrate secp256k1 (c) as part of consensus. Jorge Timon highlights the importance of extracting consensus rules from Bitcoin Core to avoid the need for future re-implementations. He proposes steps to implement libconsensus in Bitcoin Core, but acknowledges the risk of consensus fork bugs during the process. Eric Voskuil disagrees with forking Bitcoin Core and suggests separating libconsensus into a separate repository. In a conversation between Wladimir J. van der Laan and Jorge Timón, they discuss the possibility of Bitcoin Core using libconsensus. Wladimir notes the risk of introducing fork bugs if the code is refactored, but expresses support for the change if this can be avoided. They also discuss the need for code review capacity and the possibility of using libsecp256k1 instead of OpenSSL.The discussion focuses on separating current-libconsensus from future-libconsensus in the Bitcoin Core code. The plan is to complete future-libconsensus that implements all consensus rules and expose more functions through its API. There are concerns about code incompatibility and the need for code review capacity. The author maintains a fork of consensus sources until they are properly isolated from the satoshi client. They express willingness to work on the project but note that fear of consensus bugs keeps people on the satoshi client.Eric Voskuil discusses the removal of the OpenSSL dependency in their stack and the activation of BIP66. The need for a separate repository for libconsensus is mentioned to ensure alternative implementations can be consensus-safe.In conclusion, there is a strong discussion about the creation and implementation of libconsensus to extract consensus rules from Bitcoin Core. The goal is to avoid re-implementations and allow for the creation of other blockchains with different rules. There are discussions about the API, pluggable block storage, and the integration of secp256k1 (c). Concerns about code compatibility, code review capacity, and OpenSSL dependency are also addressed.The goal of the Bitcoin Core codebase is to be modularized, allowing for easy swapping out of consensus rules and reducing the risk of consensus fork bugs. Mike Hearn, a Bitcoin developer, expressed his desire for Bitcoin Core to have a benevolent dictator, similar to other free software projects. This is because decentralization still requires someone to make decisions for changes to occur.In an email exchange in 2015, Jorge Timón apologized for mentioning Mike Hearn and diverting attention from the topic at hand. Timón referenced Hearn's desire for a benevolent dictator but clarified that it was not relevant to the discussion of libconsensus, which focuses on alternative implementations and the ability to fork smaller projects without relying on Bitcoin Core.Another email exchange on - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_List-of-approved-pools.xml b/static/bitcoin-dev/July_2015/combined_List-of-approved-pools.xml index 1608fa6344..9da83eb5b3 100644 --- a/static/bitcoin-dev/July_2015/combined_List-of-approved-pools.xml +++ b/static/bitcoin-dev/July_2015/combined_List-of-approved-pools.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - List of approved pools - 2023-08-01T14:13:54.235114+00:00 + 2025-10-11T22:00:44.789159+00:00 + python-feedgen David A. Harding 2015-07-04 15:42:32+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - List of approved pools - 2023-08-01T14:13:54.235114+00:00 + 2025-10-11T22:00:44.789329+00:00 - Geir Harald Hansen, representing Bitminter, is inquiring about the process to get Bitminter on the list of approved mining pools at bitcoin.org/en/alert/2015-07-04-spv-mining. The website provides a list of recommended mining pools for users to choose from when mining Bitcoin. To have Bitminter added to the list, there are likely certain requirements that must be met. It is unclear what these requirements are, but it is likely that the pool must meet certain criteria such as being secure and reliable.Bitminter is a popular Bitcoin mining pool that has been operating since 2011. It boasts a user-friendly interface and low fees for its members. However, being listed on the bitcoin.org website could potentially increase traffic and membership for the pool. It is important for mining pool operators like Bitminter to be vigilant about security and reliability. With so much money at stake, users need to trust that their funds are safe and that the pool will operate efficiently. Being listed on a reputable website like bitcoin.org could help build trust with potential members.In order to address Geir Harald Hansen's query, David A. Harding suggests adding known good/bad pools to the Comparison of mining pools page on the Bitcoin Wiki. This information is needed to make accurate guesses about how many additional confirmations are needed while the situation persists. He also mentions that he will update the Bitcoin.org alert to point to the Wiki page. Additionally, Jameson Lopp suggests opening an issue or submitting a pull request on GitHub to get Bitminter on the list of approved pools. The specific page on GitHub where this can be done is provided in the discussion thread. 2015-07-04T15:42:32+00:00 + Geir Harald Hansen, representing Bitminter, is inquiring about the process to get Bitminter on the list of approved mining pools at bitcoin.org/en/alert/2015-07-04-spv-mining. The website provides a list of recommended mining pools for users to choose from when mining Bitcoin. To have Bitminter added to the list, there are likely certain requirements that must be met. It is unclear what these requirements are, but it is likely that the pool must meet certain criteria such as being secure and reliable.Bitminter is a popular Bitcoin mining pool that has been operating since 2011. It boasts a user-friendly interface and low fees for its members. However, being listed on the bitcoin.org website could potentially increase traffic and membership for the pool. It is important for mining pool operators like Bitminter to be vigilant about security and reliability. With so much money at stake, users need to trust that their funds are safe and that the pool will operate efficiently. Being listed on a reputable website like bitcoin.org could help build trust with potential members.In order to address Geir Harald Hansen's query, David A. Harding suggests adding known good/bad pools to the Comparison of mining pools page on the Bitcoin Wiki. This information is needed to make accurate guesses about how many additional confirmations are needed while the situation persists. He also mentions that he will update the Bitcoin.org alert to point to the Wiki page. Additionally, Jameson Lopp suggests opening an issue or submitting a pull request on GitHub to get Bitminter on the list of approved pools. The specific page on GitHub where this can be done is provided in the discussion thread. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_LockUnspent-not-working-bug-.xml b/static/bitcoin-dev/July_2015/combined_LockUnspent-not-working-bug-.xml index 1e202b093a..22b5997212 100644 --- a/static/bitcoin-dev/July_2015/combined_LockUnspent-not-working-bug-.xml +++ b/static/bitcoin-dev/July_2015/combined_LockUnspent-not-working-bug-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - LockUnspent not working, bug? - 2023-08-01T14:49:18.909502+00:00 + 2025-10-11T22:01:08.164543+00:00 + python-feedgen Micha Bailey 2015-07-30 23:00:59+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - LockUnspent not working, bug? - 2023-08-01T14:49:18.909502+00:00 + 2025-10-11T22:01:08.164689+00:00 - On a Bitcoin development mailing list, Ian Treibick reported an issue with the 'lockunspent' command on OS X with Satoshi 0.11.0. He mentioned that the TXID and vout belong to the wallet and that he was able to spend it even after locking it with the command. In his post, he included the command he used to lock the unspent transaction output (UTXO) and the subsequent 'listlockunspent' output, which showed no locked UTXOs. Ian expressed uncertainty about whether he had posted in the right place and asked if it would be better to open an issue on GitHub. The main issue highlighted by Ian is that despite running the lockunspent command and obtaining a 'true' output, the subsequent listlockunspent command did not list any locked UTXOs. However, he still found himself able to spend the locked transaction from the wallet. Unfortunately, no additional information was provided regarding other potential issues or troubleshooting steps taken. 2015-07-30T23:00:59+00:00 + On a Bitcoin development mailing list, Ian Treibick reported an issue with the 'lockunspent' command on OS X with Satoshi 0.11.0. He mentioned that the TXID and vout belong to the wallet and that he was able to spend it even after locking it with the command. In his post, he included the command he used to lock the unspent transaction output (UTXO) and the subsequent 'listlockunspent' output, which showed no locked UTXOs. Ian expressed uncertainty about whether he had posted in the right place and asked if it would be better to open an issue on GitHub. The main issue highlighted by Ian is that despite running the lockunspent command and obtaining a 'true' output, the subsequent listlockunspent command did not list any locked UTXOs. However, he still found himself able to spend the locked transaction from the wallet. Unfortunately, no additional information was provided regarding other potential issues or troubleshooting steps taken. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Mailing-List-Administrivia-GPG-Archives-Breakage-TODO-mirrors-etc.xml b/static/bitcoin-dev/July_2015/combined_Mailing-List-Administrivia-GPG-Archives-Breakage-TODO-mirrors-etc.xml index eb056e195d..fe10cddedc 100644 --- a/static/bitcoin-dev/July_2015/combined_Mailing-List-Administrivia-GPG-Archives-Breakage-TODO-mirrors-etc.xml +++ b/static/bitcoin-dev/July_2015/combined_Mailing-List-Administrivia-GPG-Archives-Breakage-TODO-mirrors-etc.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mailing List Administrivia - GPG, Archives, Breakage, TODO, mirrors, etc - 2023-08-01T14:05:44.137694+00:00 + 2025-10-11T22:02:05.562049+00:00 + python-feedgen grarpamp 2015-07-16 05:08:59+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Mailing List Administrivia - GPG, Archives, Breakage, TODO, mirrors, etc - 2023-08-01T14:05:44.137694+00:00 + 2025-10-11T22:02:05.562159+00:00 - The email archive system "mbox" has been causing some emails to become lost in mirrors, as they do not appear in the archives. The attachment link for users of the web "archive" has stripped off the final blank line that was present in the original attachment, potentially leading to detached signatures failing. Warren Togami Jr. has disabled the obscure_addresses option for Mailman as it was ineffective in mitigating spam. However, a test message sent to check if mailman continues to break clearsign GPG signatures for messages containing e-mail addresses showed that the issue still persists. This problem has been reported on both web and mbox archives. An attachment named lost.c will not appear in the mbox archives, resulting in its loss to both mirrors and users who use the mbox archives as their source for local seeding or MUA access.On June 27, 2015, Jeff Garzik wrote an email stating that a minimum modification policy was needed to preserve digital signatures and make mbox archives useful. Another person named Peter agreed with this statement and suggested making the raw archives public for archiving as well. The email included a digital signature attachment from Peter.The bitcoin-dev mailing list has been experiencing issues with its archive, specifically with the "mbox" format. The archives are missing necessary headers for easy use by users' MUA's in their local environment. Attachments that are necessary for the context and archives of all lists are not included, resulting in wasted time attempting to post-process them into usable form. There are at least 15 instances of unescaped '^From ' in the "mbox." A user has requested that the full raw archives be provided in regularly updated [gzip/7z] mbox format to fix these issues. Message footers and subject prefixes are considered corruptive and space-wasting clutter that should be turned off. Gmane has changed the subscription of the previous list to the current list, but there is a gap in their archive at the beginning and last week of the archive. They have requested a link to a single mbox file archive that can be used to restore the list archive in its entirety.The need for a minimum modification policy to preserve digital signatures and make mbox archives more useful is discussed. The "mbox" archives are broken and not verifiable, resulting in valuable content being lost. They are also missing original headers necessary for fully replyable, threadable, sortable, searchable, context-preserving use by users' MUA's in their local environment, and do not include essential attachments. Additionally, there appear to be instances of unescaped '^From' in the "mbox." To address these issues, the full raw archives should be provided in regularly updated [gzip/7z] mbox format. Other mirrors, archives, analysis, journalism, and interfaces are useful, but they require pristine historical sources to seed from. The message footers and subject prefix should also be turned off as they are corruptive and space-wasting clutter.The members of the Bitcoin development community have expressed concern over the corrupt archives of the mailing list they use to communicate. They are requesting that the "mbox" format used for archiving be fixed and made available for public use as it is the most efficient way to preserve the list's history. Users have stated that attempting to prevent spam through this method is futile. Some users feel that message footers and subject prefixes should be turned off as they clutter up the email chain. It has been requested that the internet provide regularly updated gzip/7z mbox format archives to resolve these issues. 2015-07-16T05:08:59+00:00 + The email archive system "mbox" has been causing some emails to become lost in mirrors, as they do not appear in the archives. The attachment link for users of the web "archive" has stripped off the final blank line that was present in the original attachment, potentially leading to detached signatures failing. Warren Togami Jr. has disabled the obscure_addresses option for Mailman as it was ineffective in mitigating spam. However, a test message sent to check if mailman continues to break clearsign GPG signatures for messages containing e-mail addresses showed that the issue still persists. This problem has been reported on both web and mbox archives. An attachment named lost.c will not appear in the mbox archives, resulting in its loss to both mirrors and users who use the mbox archives as their source for local seeding or MUA access.On June 27, 2015, Jeff Garzik wrote an email stating that a minimum modification policy was needed to preserve digital signatures and make mbox archives useful. Another person named Peter agreed with this statement and suggested making the raw archives public for archiving as well. The email included a digital signature attachment from Peter.The bitcoin-dev mailing list has been experiencing issues with its archive, specifically with the "mbox" format. The archives are missing necessary headers for easy use by users' MUA's in their local environment. Attachments that are necessary for the context and archives of all lists are not included, resulting in wasted time attempting to post-process them into usable form. There are at least 15 instances of unescaped '^From ' in the "mbox." A user has requested that the full raw archives be provided in regularly updated [gzip/7z] mbox format to fix these issues. Message footers and subject prefixes are considered corruptive and space-wasting clutter that should be turned off. Gmane has changed the subscription of the previous list to the current list, but there is a gap in their archive at the beginning and last week of the archive. They have requested a link to a single mbox file archive that can be used to restore the list archive in its entirety.The need for a minimum modification policy to preserve digital signatures and make mbox archives more useful is discussed. The "mbox" archives are broken and not verifiable, resulting in valuable content being lost. They are also missing original headers necessary for fully replyable, threadable, sortable, searchable, context-preserving use by users' MUA's in their local environment, and do not include essential attachments. Additionally, there appear to be instances of unescaped '^From' in the "mbox." To address these issues, the full raw archives should be provided in regularly updated [gzip/7z] mbox format. Other mirrors, archives, analysis, journalism, and interfaces are useful, but they require pristine historical sources to seed from. The message footers and subject prefix should also be turned off as they are corruptive and space-wasting clutter.The members of the Bitcoin development community have expressed concern over the corrupt archives of the mailing list they use to communicate. They are requesting that the "mbox" format used for archiving be fixed and made available for public use as it is the most efficient way to preserve the list's history. Users have stated that attempting to prevent spam through this method is futile. Some users feel that message footers and subject prefixes should be turned off as they clutter up the email chain. It has been requested that the internet provide regularly updated gzip/7z mbox format archives to resolve these issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Making-Electrum-more-anonymous.xml b/static/bitcoin-dev/July_2015/combined_Making-Electrum-more-anonymous.xml index 2e519f721f..58bb0692a2 100644 --- a/static/bitcoin-dev/July_2015/combined_Making-Electrum-more-anonymous.xml +++ b/static/bitcoin-dev/July_2015/combined_Making-Electrum-more-anonymous.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Making Electrum more anonymous - 2023-08-01T14:26:05.194826+00:00 + 2025-10-11T22:00:49.036734+00:00 + python-feedgen Slurms MacKenzie 2015-07-24 21:20:06+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Making Electrum more anonymous - 2023-08-01T14:26:05.194826+00:00 + 2025-10-11T22:00:49.036908+00:00 - In an effort to improve the anonymity of Electrum, Thomas Voegtlin, the creator of the platform, has proposed the creation of an anonymous routing layer between Electrum servers and clients. Currently, when using Electrum, clients connect to multiple servers to fetch block headers, but request address balances and histories from a single server. This means that the chosen server knows which addresses belong to the same wallet, even if Electrum is used over TOR.Several proposals have been put forward to address this issue, such as creating subsets of wallet addresses and sending them to separate servers. However, these proposals require trusting more servers and do not necessarily provide improved anonymity. Inspired by the TOR network, Voegtlin suggests the implementation of an anonymous routing layer.Under this proposed system, each Electrum server would publish an RSA public key, and clients would receive a list of available servers along with their respective public keys. For each wallet address, the client would choose a server and generate an RSA keypair. They would then create a list of encrypted requests containing the wallet address and the generated keypair, encrypting it with the chosen server's public key.The client would send this list of encrypted requests to a main server, which would dispatch the requests to the corresponding servers without revealing the client's IP address. Each server would decrypt the received requests, perform the requested operations, and encrypt the results with the keypair. The main server would then receive the encrypted responses and forward them to the client, who would decrypt them using the corresponding keypair.However, it is important to note that this approach would be ineffective if all servers or a significant portion of them were controlled by the same entity that controls the main server. Furthermore, the weaknesses observed in TOR implementations, such as lack of relay nodes and the need for distinct routes to prevent correlation, are also applicable to this proposed scheme.Voegtlin is seeking feedback on this idea and wants to understand the costs and benefits associated with implementing an anonymous routing layer between Electrum servers and clients. One respondent suggested considering the Dissent protocol, which reduces the impact of Sybil attacks. It remains to be seen how this proposal will be received within the bitcoin-dev community and if it will ultimately be implemented in Electrum. 2015-07-24T21:20:06+00:00 + In an effort to improve the anonymity of Electrum, Thomas Voegtlin, the creator of the platform, has proposed the creation of an anonymous routing layer between Electrum servers and clients. Currently, when using Electrum, clients connect to multiple servers to fetch block headers, but request address balances and histories from a single server. This means that the chosen server knows which addresses belong to the same wallet, even if Electrum is used over TOR.Several proposals have been put forward to address this issue, such as creating subsets of wallet addresses and sending them to separate servers. However, these proposals require trusting more servers and do not necessarily provide improved anonymity. Inspired by the TOR network, Voegtlin suggests the implementation of an anonymous routing layer.Under this proposed system, each Electrum server would publish an RSA public key, and clients would receive a list of available servers along with their respective public keys. For each wallet address, the client would choose a server and generate an RSA keypair. They would then create a list of encrypted requests containing the wallet address and the generated keypair, encrypting it with the chosen server's public key.The client would send this list of encrypted requests to a main server, which would dispatch the requests to the corresponding servers without revealing the client's IP address. Each server would decrypt the received requests, perform the requested operations, and encrypt the results with the keypair. The main server would then receive the encrypted responses and forward them to the client, who would decrypt them using the corresponding keypair.However, it is important to note that this approach would be ineffective if all servers or a significant portion of them were controlled by the same entity that controls the main server. Furthermore, the weaknesses observed in TOR implementations, such as lack of relay nodes and the need for distinct routes to prevent correlation, are also applicable to this proposed scheme.Voegtlin is seeking feedback on this idea and wants to understand the costs and benefits associated with implementing an anonymous routing layer between Electrum servers and clients. One respondent suggested considering the Dissent protocol, which reduces the impact of Sybil attacks. It remains to be seen how this proposal will be received within the bitcoin-dev community and if it will ultimately be implemented in Electrum. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Mempool-Expected-Byte-Stay-policy.xml b/static/bitcoin-dev/July_2015/combined_Mempool-Expected-Byte-Stay-policy.xml index bfaaabdb9e..b33e7d5851 100644 --- a/static/bitcoin-dev/July_2015/combined_Mempool-Expected-Byte-Stay-policy.xml +++ b/static/bitcoin-dev/July_2015/combined_Mempool-Expected-Byte-Stay-policy.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Mempool "Expected Byte Stay" policy - 2023-08-01T14:20:25.858587+00:00 + Combined summary - Mempool "Expected Byte Stay" policy + 2025-10-11T22:01:40.065118+00:00 + python-feedgen Tom Harding 2015-07-16 16:50:58+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 - Combined summary - Mempool "Expected Byte Stay" policy - 2023-08-01T14:20:25.858587+00:00 + Combined summary - Mempool "Expected Byte Stay" policy + 2025-10-11T22:01:40.065291+00:00 - In a discussion on the bitcoin-dev mailing list, there was a debate about whether a block or time-based system should be used to determine when transactions and their dependents should be evicted from the mempool. Thomas Zander suggested using a number of blocks, while Tom Harding argued that a time-based system would be more beneficial for users and wallets.Zander's proposal was based on the idea that using blocks would allow users to know when they should rebroadcast their transaction and consider increasing the fee. However, Harding pointed out that block mining times are not guaranteed in the future, and a sudden change could cause issues for the mempool. This led to a disagreement about which method would be best for managing the mempool.The discussion then turned to Rule 2, which currently states that a transaction and its dependents will be evicted on its 2-hour anniversary, regardless of whether space is required or not. Harding suggested using a number of blocks instead of two hours, as this would provide clearer guidance for users and wallets. Zander did some calculations and found that using 12 blocks would result in a 5% chance of having to wait three hours, while using 120 minutes would only have a .23% chance of fewer than four blocks occurring.The author of the context is facing a problem with spammers using up their fullnode resources. To address this issue, they have made changes to the mempool management. They have set a maximum size for the mempool and are allocating space based on a simple rule. The cost of holding a transaction in the mempool is measured by "expected byte stay," which takes into account the size of the transaction and the expected number of blocks needed for confirmation.When there is not enough space for a new transaction, the author tries to make space by evicting transactions with a higher expected byte stay than the new transaction. However, the author is not concerned about fees except for their impact on confirmation time, coin age, CPFP, and replacement. Currently, a transaction and its dependents are evicted on its two-hour anniversary, regardless of whether space is required or not.The author has implemented a new fee estimation system and periodically applies the latest expectedBlocksToConfirm(feeRate) table to the entire mempool. They have faith in this new system, particularly its size independence. However, there is a possibility of clog-ups caused by transactions that appear to be confirmed in the next block but end up being delayed due to factors other than fees.The author plans to provide updates on how the new system works out in addressing the spamming issue and managing the mempool effectively. 2015-07-16T16:50:58+00:00 + In a discussion on the bitcoin-dev mailing list, there was a debate about whether a block or time-based system should be used to determine when transactions and their dependents should be evicted from the mempool. Thomas Zander suggested using a number of blocks, while Tom Harding argued that a time-based system would be more beneficial for users and wallets.Zander's proposal was based on the idea that using blocks would allow users to know when they should rebroadcast their transaction and consider increasing the fee. However, Harding pointed out that block mining times are not guaranteed in the future, and a sudden change could cause issues for the mempool. This led to a disagreement about which method would be best for managing the mempool.The discussion then turned to Rule 2, which currently states that a transaction and its dependents will be evicted on its 2-hour anniversary, regardless of whether space is required or not. Harding suggested using a number of blocks instead of two hours, as this would provide clearer guidance for users and wallets. Zander did some calculations and found that using 12 blocks would result in a 5% chance of having to wait three hours, while using 120 minutes would only have a .23% chance of fewer than four blocks occurring.The author of the context is facing a problem with spammers using up their fullnode resources. To address this issue, they have made changes to the mempool management. They have set a maximum size for the mempool and are allocating space based on a simple rule. The cost of holding a transaction in the mempool is measured by "expected byte stay," which takes into account the size of the transaction and the expected number of blocks needed for confirmation.When there is not enough space for a new transaction, the author tries to make space by evicting transactions with a higher expected byte stay than the new transaction. However, the author is not concerned about fees except for their impact on confirmation time, coin age, CPFP, and replacement. Currently, a transaction and its dependents are evicted on its two-hour anniversary, regardless of whether space is required or not.The author has implemented a new fee estimation system and periodically applies the latest expectedBlocksToConfirm(feeRate) table to the entire mempool. They have faith in this new system, particularly its size independence. However, there is a possibility of clog-ups caused by transactions that appear to be confirmed in the next block but end up being delayed due to factors other than fees.The author plans to provide updates on how the new system works out in addressing the spamming issue and managing the mempool effectively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Mining-centralization-pressure-from-non-uniform-propagation-speed.xml b/static/bitcoin-dev/July_2015/combined_Mining-centralization-pressure-from-non-uniform-propagation-speed.xml index e31348e868..62e4c33419 100644 --- a/static/bitcoin-dev/July_2015/combined_Mining-centralization-pressure-from-non-uniform-propagation-speed.xml +++ b/static/bitcoin-dev/July_2015/combined_Mining-centralization-pressure-from-non-uniform-propagation-speed.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mining centralization pressure from non-uniform propagation speed - 2023-08-01T13:12:02.124288+00:00 + 2025-10-11T22:02:07.724359+00:00 + python-feedgen Mashuri Clark 2015-07-08 19:15:08+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Mining centralization pressure from non-uniform propagation speed - 2023-08-01T13:12:02.124288+00:00 + 2025-10-11T22:02:07.724507+00:00 - The email thread discussed in the context focuses on the effects of block size on centralization pressure in the Bitcoin system. Tom Harding and Pieter Wuille discuss the impact of a per-node imposed max block size limit on orphan rates and reorgs, as well as the connectivity of nodes in countries with unfriendly internet policies. Jonas Nick argues that Pieter's scenario is due to a long-term network partition rather than a cartel.Tom runs a simulation with a large miner in a minority partition and 16 small miners in a majority partition to test the effects of block size and slow link speed. The results show that making small blocks when others are making big ones is detrimental, and being separated by a slow link from majority hash power is also disadvantageous. However, being a small miner with a block size of 20MB is not bad. Yifu Guo signs off the email.Another discussion between Pieter Wuille and Jonas Nick revolves around the centralization pressure caused by larger blocks. Jonas points out that it is unclear whether the pressure to merge with big miners can be separated from the pressure to connect with the majority partition. He runs a simulation with a large miner in a 20% minority partition and 16 small miners in an 80% majority partition, including a slow link speed of 100 Mbit/s. The simulation shows that making small blocks when others are making big ones is unfavorable, and fees become enormous. Being separated by a slow link from the majority hash power is also detrimental. However, being a small miner with a block size of 20MB is not disadvantageous. The simulation uses different configurations to demonstrate the effects of block size and fee per byte on the income of two miner groups with different hash rates.Pieter Wuille has developed a Bitcoin mining simulator that considers various factors such as block sizes, difficulty adjustments, processing and mining delays, and fees. The simulator includes two groups of miners that are well-connected internally but only connected to each other through a slow 2 Mbit/s link. The results indicate that the group with the larger hash rate profits overall, while miners not directly connected to the small group experience losses. When fees become more important, the effect becomes even stronger. The simulator also shows the impact of larger blocks on centralization pressure in the system, without assuming any destructive behavior on the network.A conversation between Peter Todd and Gavin Andresen focuses on the benefits of producing larger blocks and including high-fee transactions. They discuss the relevance of simulations considering Matt's fast relay network and future optimization of block propagation. Peter suggests simulating the relay network at different usage levels to analyze if it is advantageous for miners to sabotage the network. The conversation ends with Peter providing his contact information.Gavin Andresen and Pieter Wuille discuss the simulation of bandwidth for block messages as a bottleneck. Pieter suggests that Matt's fast relay network could make their simulations irrelevant in the long run. Gavin proposes two simulations: one assuming 100% usage of the relay network and another assuming a lower percentage. They also discuss the potential advantage for miners to sabotage the relay network. Despite the relay network, there is still a delay. Peter's contact information and a digital signature file conclude the email exchange.The context also mentions an email from Mike Hearn questioning the slow speed of a 2 Mbit/s link between two connected entities. He compares this to the average speed of a 3G connection and expresses concern about the accuracy of simulation data due to the slow connection speed. However, no further details are provided regarding the effect being discussed.Pieter Wuille shares an email explaining the configuration used in his code that simulates two groups of miners. The code supports different block sizes, takes fees into account, and considers difficulty adjustments, processing and mining delays. It also simulates longer periods of time and averages the results of multiple simulations running in parallel. The configuration involves two well-connected groups of miners that are only connected to each other through a slow 2 Mbit/s link. The simulation demonstrates that smaller miners experience a relative income loss when creating larger blocks, especially when fees become more important.In summary, the email exchanges and simulations discussed in the context explore the effects of block size, connectivity, and fee considerations on centralization pressure in the Bitcoin system. Various scenarios and configurations are simulated to analyze the impact on miner income and profitability. The discussions also touch upon the potential irrelevance of simulations due to advancements in block propagation optimization and the possibility of miners sabotaging the relay network. 2015-07-08T19:15:08+00:00 + The email thread discussed in the context focuses on the effects of block size on centralization pressure in the Bitcoin system. Tom Harding and Pieter Wuille discuss the impact of a per-node imposed max block size limit on orphan rates and reorgs, as well as the connectivity of nodes in countries with unfriendly internet policies. Jonas Nick argues that Pieter's scenario is due to a long-term network partition rather than a cartel.Tom runs a simulation with a large miner in a minority partition and 16 small miners in a majority partition to test the effects of block size and slow link speed. The results show that making small blocks when others are making big ones is detrimental, and being separated by a slow link from majority hash power is also disadvantageous. However, being a small miner with a block size of 20MB is not bad. Yifu Guo signs off the email.Another discussion between Pieter Wuille and Jonas Nick revolves around the centralization pressure caused by larger blocks. Jonas points out that it is unclear whether the pressure to merge with big miners can be separated from the pressure to connect with the majority partition. He runs a simulation with a large miner in a 20% minority partition and 16 small miners in an 80% majority partition, including a slow link speed of 100 Mbit/s. The simulation shows that making small blocks when others are making big ones is unfavorable, and fees become enormous. Being separated by a slow link from the majority hash power is also detrimental. However, being a small miner with a block size of 20MB is not disadvantageous. The simulation uses different configurations to demonstrate the effects of block size and fee per byte on the income of two miner groups with different hash rates.Pieter Wuille has developed a Bitcoin mining simulator that considers various factors such as block sizes, difficulty adjustments, processing and mining delays, and fees. The simulator includes two groups of miners that are well-connected internally but only connected to each other through a slow 2 Mbit/s link. The results indicate that the group with the larger hash rate profits overall, while miners not directly connected to the small group experience losses. When fees become more important, the effect becomes even stronger. The simulator also shows the impact of larger blocks on centralization pressure in the system, without assuming any destructive behavior on the network.A conversation between Peter Todd and Gavin Andresen focuses on the benefits of producing larger blocks and including high-fee transactions. They discuss the relevance of simulations considering Matt's fast relay network and future optimization of block propagation. Peter suggests simulating the relay network at different usage levels to analyze if it is advantageous for miners to sabotage the network. The conversation ends with Peter providing his contact information.Gavin Andresen and Pieter Wuille discuss the simulation of bandwidth for block messages as a bottleneck. Pieter suggests that Matt's fast relay network could make their simulations irrelevant in the long run. Gavin proposes two simulations: one assuming 100% usage of the relay network and another assuming a lower percentage. They also discuss the potential advantage for miners to sabotage the relay network. Despite the relay network, there is still a delay. Peter's contact information and a digital signature file conclude the email exchange.The context also mentions an email from Mike Hearn questioning the slow speed of a 2 Mbit/s link between two connected entities. He compares this to the average speed of a 3G connection and expresses concern about the accuracy of simulation data due to the slow connection speed. However, no further details are provided regarding the effect being discussed.Pieter Wuille shares an email explaining the configuration used in his code that simulates two groups of miners. The code supports different block sizes, takes fees into account, and considers difficulty adjustments, processing and mining delays. It also simulates longer periods of time and averages the results of multiple simulations running in parallel. The configuration involves two well-connected groups of miners that are only connected to each other through a slow 2 Mbit/s link. The simulation demonstrates that smaller miners experience a relative income loss when creating larger blocks, especially when fees become more important.In summary, the email exchanges and simulations discussed in the context explore the effects of block size, connectivity, and fee considerations on centralization pressure in the Bitcoin system. Various scenarios and configurations are simulated to analyze the impact on miner income and profitability. The discussions also touch upon the potential irrelevance of simulations due to advancements in block propagation optimization and the possibility of miners sabotaging the relay network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Process-for-BIP-number-allocation.xml b/static/bitcoin-dev/July_2015/combined_Process-for-BIP-number-allocation.xml index 615ba65ec8..46ee651b8a 100644 --- a/static/bitcoin-dev/July_2015/combined_Process-for-BIP-number-allocation.xml +++ b/static/bitcoin-dev/July_2015/combined_Process-for-BIP-number-allocation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Process for BIP number allocation - 2023-08-01T14:29:31.968785+00:00 + 2025-10-11T22:00:46.913968+00:00 + python-feedgen Peter Todd 2015-07-24 02:26:13+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Process for BIP number allocation - 2023-08-01T14:29:31.968785+00:00 + 2025-10-11T22:00:46.914128+00:00 - On July 23, 2015, Kalle Rosenbaum introduced a Proof of Payment-enabled fork of the Mycelium Bitcoin wallet. The source code for this version can be found on GitHub at https://github.com/kallerosenbaum/wallet, and the validating code for the server is hosted at https://github.com/kallerosenbaum/poppoc/. To demonstrate the functionality, a demo site using the server code is accessible at http://www.rosenbaum.se:8080/, and a video showcasing the demo is available at https://www.youtube.com/watch?v=euzZcoCilhc. Additionally, Mycelium binaries are provided on the demo site.Peter Todd responded to the announcement by encouraging users to utilize the new fork and provide feedback. He emphasized that BIP numbers will be assigned even for potentially risky or poorly designed standards once they gain real-world adoption. However, he highlighted the importance of avoiding assigning numbers to unused items, particularly those that lack consensus.Kalle Rosenbaum suggested amending the "BIP Editor Responsibilities & Workflow" section of BIP0001. The proposed clause stipulates that if a BIP editor is unable to handle a BIP within a week, they should notify the author within that same week with an estimated timeline for handling it. Unfortunately, there has been no response from BIP editor Gregory Maxwell regarding Kalle's request for a BIP number allocation for Proof of Payment. In response, Peter Todd requested an implementation of Kalle's proposed BIP, as the process prioritizes running code, preferably in production. Kalle has provided links to the PoP-enabled fork of Mycelium and the server (validating code) on Github, along with a demo site and video.In an email to the bitcoin-dev mailing list on July 23, 2015, a member of the Bitcoin development community suggested including a clause in BIP0001. This clause would require BIP editors to notify authors if they are unable to handle a BIP within a week and provide an estimated timeline for handling it. The author of the email was seeking BIP numbers for Proof of Payment but had not received any response from BIP editor Gregory Maxwell, despite requesting it and CCing the bitcoin-dev list. In response to the email, someone inquired about the implementation of the proposed BIP. They emphasized that running code is preferred for non-consensus BIPs and expressed concern about the number of BIPs significantly exceeding the number of actual standards being used. The email was signed with a PGP signature.The author of the email suggests including a clause in the "BIP Editor Responsibilities & Workflow" section of BIP0001. This clause would require BIP editors to notify authors if they are unable to handle a BIP within one or two weeks and provide an estimated timeline for handling it. The author's intention is to secure BIP numbers for Proof of Payment, but no response has been received from BIP editor Gregory Maxwell. The author also highlights the existence of multiple BIP proposals without a clear process for allocation and inclusion in the bips repository. They propose that authors should receive a response from the BIP editor when requesting a number, and if a BIP is disapproved, the author should be notified within a reasonable and predictable timeframe. 2015-07-24T02:26:13+00:00 + On July 23, 2015, Kalle Rosenbaum introduced a Proof of Payment-enabled fork of the Mycelium Bitcoin wallet. The source code for this version can be found on GitHub at https://github.com/kallerosenbaum/wallet, and the validating code for the server is hosted at https://github.com/kallerosenbaum/poppoc/. To demonstrate the functionality, a demo site using the server code is accessible at http://www.rosenbaum.se:8080/, and a video showcasing the demo is available at https://www.youtube.com/watch?v=euzZcoCilhc. Additionally, Mycelium binaries are provided on the demo site.Peter Todd responded to the announcement by encouraging users to utilize the new fork and provide feedback. He emphasized that BIP numbers will be assigned even for potentially risky or poorly designed standards once they gain real-world adoption. However, he highlighted the importance of avoiding assigning numbers to unused items, particularly those that lack consensus.Kalle Rosenbaum suggested amending the "BIP Editor Responsibilities & Workflow" section of BIP0001. The proposed clause stipulates that if a BIP editor is unable to handle a BIP within a week, they should notify the author within that same week with an estimated timeline for handling it. Unfortunately, there has been no response from BIP editor Gregory Maxwell regarding Kalle's request for a BIP number allocation for Proof of Payment. In response, Peter Todd requested an implementation of Kalle's proposed BIP, as the process prioritizes running code, preferably in production. Kalle has provided links to the PoP-enabled fork of Mycelium and the server (validating code) on Github, along with a demo site and video.In an email to the bitcoin-dev mailing list on July 23, 2015, a member of the Bitcoin development community suggested including a clause in BIP0001. This clause would require BIP editors to notify authors if they are unable to handle a BIP within a week and provide an estimated timeline for handling it. The author of the email was seeking BIP numbers for Proof of Payment but had not received any response from BIP editor Gregory Maxwell, despite requesting it and CCing the bitcoin-dev list. In response to the email, someone inquired about the implementation of the proposed BIP. They emphasized that running code is preferred for non-consensus BIPs and expressed concern about the number of BIPs significantly exceeding the number of actual standards being used. The email was signed with a PGP signature.The author of the email suggests including a clause in the "BIP Editor Responsibilities & Workflow" section of BIP0001. This clause would require BIP editors to notify authors if they are unable to handle a BIP within one or two weeks and provide an estimated timeline for handling it. The author's intention is to secure BIP numbers for Proof of Payment, but no response has been received from BIP editor Gregory Maxwell. The author also highlights the existence of multiple BIP proposals without a clear process for allocation and inclusion in the bips repository. They propose that authors should receive a response from the BIP editor when requesting a number, and if a BIP is disapproved, the author should be notified within a reasonable and predictable timeframe. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Proposal-extend-bip70-with-OpenAlias.xml b/static/bitcoin-dev/July_2015/combined_Proposal-extend-bip70-with-OpenAlias.xml index 3cae2d67bb..34d6dbb75f 100644 --- a/static/bitcoin-dev/July_2015/combined_Proposal-extend-bip70-with-OpenAlias.xml +++ b/static/bitcoin-dev/July_2015/combined_Proposal-extend-bip70-with-OpenAlias.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: extend bip70 with OpenAlias - 2023-08-01T14:20:02.486768+00:00 + 2025-10-11T22:02:18.356596+00:00 + python-feedgen Thomas Voegtlin 2015-07-31 20:34:55+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - Proposal: extend bip70 with OpenAlias - 2023-08-01T14:20:02.487767+00:00 + 2025-10-11T22:02:18.356808+00:00 - In an email conversation between Thomas Voegtlin and Justin W. Newton, the idea of hiding the "_oa2" portion of the domain name to facilitate the delegation of wallet names in a zone was discussed. Thomas proposed using "@" as a symbol to denote the hidden portion in the alias. He also provided an example of how Bitcoin aliases could be delegated to Netki using this system.The OpenAlias standard was created to simplify the process of creating aliases for cryptocurrency transactions. However, using a tiered system adds complexity for the alias creator and makes it easier to make mistakes. Retaining forward and backward compatibility is also more challenging with a Key-Value (KV) pair system. The proposal suggests using "_oa2_keys" for listing TXT records under a name and introducing "_oa2" as an intermediate level for delegation, translating to "@" in the alias.Another email thread on the bitcoin-dev mailing list discussed the idea of having an intermediate "_wallet" level for zone delegation. However, it was later suggested to separate the listing of TXT records from zone delegation. The proposal introduced the use of "_oa2" for the intermediate level and "_oa2_keys" for key listing. Examples of how this system could work with Bitcoin aliases being delegated to Netki were provided.The discussion also explored the efficiency of a two-tier lookup solution. While some argued that it would be more efficient, others believed that the efficiency does not come from using two-tier lookup. Instead, using an intermediate level like "_wallet" allows for zone delegation. It was further suggested that instead of separate records for each currency, it would be better to have a record specific to the currency, which would allow wallets supporting only one currency to skip the currencies lookup.To sign up for certain online services, users may need to create a new identity under a DNS tree they are not currently using. This can help ensure security and privacy while using online services. Services like netki.com provide the option to create a new digital identity or "root" associated with the user's online activities.In an email exchange between Mike Hearn and an unknown recipient, OpenAlias and its potential success were discussed. There was confusion over the terms "alias" and "DNS key" but it was concluded that "alias" refers to the domain name corresponding to the TXT record. The conversation also explored alternative options such as compact cert+optimized BIP70 and using pastebin for storing small bits of data. There was a suggestion to use a 150-byte QR code using base43 encoding for data storage, although legal issues may arise with services providing this type of storage.The discussion focused on two separate issues: DNSSEC and payment requests. DNSSEC attests to an EC key stored in the wallet used to sign payment requests or URIs. It was suggested not to include the proof in the payment request, as it is unnecessary for the payer to verify. DNSSEC's value lies in providing easy and canonical access to the proof. The possibility of using EC signatures with DNSSEC was questioned, as it was believed to be an all-RSA system. The author proposed using optimized BIP70 with compact cert and no DNSSEC in a QR code if creating a network for storing small bits of data proves difficult.The use of DNSSEC in payment requests and its drawbacks due to the size of the DNSSEC proof and RSA signature were discussed. The proposal suggested not including the proof in the request and only using the final signature. It also considered the use of SSL certificates for lightweight payment requests. The idea of building a new PKI for individuals that includes only a signature and a UTF-8 string without sacrificing revocability was proposed. The pubkey of the Certificate Authority would be obtained by running the pubkey recovery algorithm on the signature and verifying it against trusted pubkeys.In a conversation about convenience in Bitcoin transactions, the exchange of large data packets without a server acting as a dropbox was discussed. Possible solutions included using other people's web servers or making the data packets small. The limitations of QR codes were also mentioned, prompting the idea of finding a better replacement. The use of SSL certificates for lightweight payment requests was suggested. The benefits and drawbacks of creating a Bitcoin-specific or independent PKI for individuals were explored.Justin Newton raised concerns about including Namecoin in the standardization of DNS records holding Bitcoin addresses. He argued that .bit records cannot be easily verified by lightweight/spv wallets without a copy of the Namecoin blockchain. The proposal to include Namecoin was initially made to provide a censorship-resistant option and low-cost name registration for individuals. However, discussions are needed to consider the trade-offs for mobile wallets. The focus should be on standardizing DNS records holding Bitcoin addresses for Netki and Electrum, while other types of lookups such as Namecoin can be considered separately.The author proposed extending BIP70 to bring the benefits of public proof of payment request to user-to-user transactions. They suggested using DNSSEC for BIP 2015-07-31T20:34:55+00:00 + In an email conversation between Thomas Voegtlin and Justin W. Newton, the idea of hiding the "_oa2" portion of the domain name to facilitate the delegation of wallet names in a zone was discussed. Thomas proposed using "@" as a symbol to denote the hidden portion in the alias. He also provided an example of how Bitcoin aliases could be delegated to Netki using this system.The OpenAlias standard was created to simplify the process of creating aliases for cryptocurrency transactions. However, using a tiered system adds complexity for the alias creator and makes it easier to make mistakes. Retaining forward and backward compatibility is also more challenging with a Key-Value (KV) pair system. The proposal suggests using "_oa2_keys" for listing TXT records under a name and introducing "_oa2" as an intermediate level for delegation, translating to "@" in the alias.Another email thread on the bitcoin-dev mailing list discussed the idea of having an intermediate "_wallet" level for zone delegation. However, it was later suggested to separate the listing of TXT records from zone delegation. The proposal introduced the use of "_oa2" for the intermediate level and "_oa2_keys" for key listing. Examples of how this system could work with Bitcoin aliases being delegated to Netki were provided.The discussion also explored the efficiency of a two-tier lookup solution. While some argued that it would be more efficient, others believed that the efficiency does not come from using two-tier lookup. Instead, using an intermediate level like "_wallet" allows for zone delegation. It was further suggested that instead of separate records for each currency, it would be better to have a record specific to the currency, which would allow wallets supporting only one currency to skip the currencies lookup.To sign up for certain online services, users may need to create a new identity under a DNS tree they are not currently using. This can help ensure security and privacy while using online services. Services like netki.com provide the option to create a new digital identity or "root" associated with the user's online activities.In an email exchange between Mike Hearn and an unknown recipient, OpenAlias and its potential success were discussed. There was confusion over the terms "alias" and "DNS key" but it was concluded that "alias" refers to the domain name corresponding to the TXT record. The conversation also explored alternative options such as compact cert+optimized BIP70 and using pastebin for storing small bits of data. There was a suggestion to use a 150-byte QR code using base43 encoding for data storage, although legal issues may arise with services providing this type of storage.The discussion focused on two separate issues: DNSSEC and payment requests. DNSSEC attests to an EC key stored in the wallet used to sign payment requests or URIs. It was suggested not to include the proof in the payment request, as it is unnecessary for the payer to verify. DNSSEC's value lies in providing easy and canonical access to the proof. The possibility of using EC signatures with DNSSEC was questioned, as it was believed to be an all-RSA system. The author proposed using optimized BIP70 with compact cert and no DNSSEC in a QR code if creating a network for storing small bits of data proves difficult.The use of DNSSEC in payment requests and its drawbacks due to the size of the DNSSEC proof and RSA signature were discussed. The proposal suggested not including the proof in the request and only using the final signature. It also considered the use of SSL certificates for lightweight payment requests. The idea of building a new PKI for individuals that includes only a signature and a UTF-8 string without sacrificing revocability was proposed. The pubkey of the Certificate Authority would be obtained by running the pubkey recovery algorithm on the signature and verifying it against trusted pubkeys.In a conversation about convenience in Bitcoin transactions, the exchange of large data packets without a server acting as a dropbox was discussed. Possible solutions included using other people's web servers or making the data packets small. The limitations of QR codes were also mentioned, prompting the idea of finding a better replacement. The use of SSL certificates for lightweight payment requests was suggested. The benefits and drawbacks of creating a Bitcoin-specific or independent PKI for individuals were explored.Justin Newton raised concerns about including Namecoin in the standardization of DNS records holding Bitcoin addresses. He argued that .bit records cannot be easily verified by lightweight/spv wallets without a copy of the Namecoin blockchain. The proposal to include Namecoin was initially made to provide a censorship-resistant option and low-cost name registration for individuals. However, discussions are needed to consider the trade-offs for mobile wallets. The focus should be on standardizing DNS records holding Bitcoin addresses for Netki and Electrum, while other types of lookups such as Namecoin can be considered separately.The author proposed extending BIP70 to bring the benefits of public proof of payment request to user-to-user transactions. They suggested using DNSSEC for BIP - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_QR-code-alternatives-was-Proposal-extend-bip70-with-OpenAlias-.xml b/static/bitcoin-dev/July_2015/combined_QR-code-alternatives-was-Proposal-extend-bip70-with-OpenAlias-.xml index 7edd936991..66de335424 100644 --- a/static/bitcoin-dev/July_2015/combined_QR-code-alternatives-was-Proposal-extend-bip70-with-OpenAlias-.xml +++ b/static/bitcoin-dev/July_2015/combined_QR-code-alternatives-was-Proposal-extend-bip70-with-OpenAlias-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - QR code alternatives (was: Proposal: extend bip70 with OpenAlias) - 2023-08-01T14:24:44.702339+00:00 + 2025-10-11T22:01:14.541003+00:00 + python-feedgen Thomas Voegtlin 2015-07-21 14:58:39+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - QR code alternatives (was: Proposal: extend bip70 with OpenAlias) - 2023-08-01T14:24:44.702339+00:00 + 2025-10-11T22:01:14.541179+00:00 - In a message from July 20, 2015, Mike Hearn proposed an idea for generating QR codes for Bitcoin payment requests. The method suggested using a single payment address without merge avoidance tricks and provided an example QR code. However, this approach would require text mode and waste bytes at the front for the URI type. To avoid this issue, it was suggested that assuming the payment request is a single standard output + amount would cover most cases and generate a serialized bip70 PR from the parameters found in the URI. The string would then be signed, and the signature added to the URI. This approach saves bits by expressing the duration of validity as one week. The resulting QR code can be scanned with a phone.The 2D-Doc is a French standard used to protect documents such as address proofs and invoices. It includes an ECDSA signature inside a 2D barcode, specifically a Datamatrix, not a QR code. The barcode encodes a summary of the protected document, followed by an ECDSA signature. The signature is done by an official government-approved 2D-Doc emitter. The 2D-Code contains a reference to designate which emitter signed it, and the 2D-Doc TSL supplied by the French government provides all the X509 Certificates from every emitter. This allows for checking the signature. While the 2D-Doc solves a different problem than Bitcoin+BIP70, it's worth noting as it successfully embeds an ECDSA signature inside a 2D barcode.The email suggests that advanced QR code standards could potentially be useful without any changes to BIP7x. If more data can be added without affecting scanning performance, it's possible to maintain the current dataset while improving scanning capabilities.The email proposes a solution to the BIP 70 usability problem without servers by using upgraded QR codes that have more space and optimizing BIP 70. It mentions the High Capacity Colored Two Dimensional Codes paper, which extends standard QR codes with color for increased capacity. Another paper, DualCodes, overlays one QR code on top of another using shades of gray for enhanced reader extraction. The authors of these papers could be contacted to see if they would open source their work. Additionally, defining a certificate's format, including its own Certificate Authorities (CAs), could result in smaller certificates. A QR code with a single payment address could be serialized directly into the QR code if an embedded reader was required. Andreas' wallet can already handle this, but it's unclear how iOS handles it. The email also discusses the idea of implementing a store/forward network for private responses or using the "Stealth Address" / ECDH in the payment protocol proposals. However, these ideas come at the cost of not being able to restore a wallet from seed words. The email suggests using servers to store Payment messages and nodes sharding themselves by announcing that they only store Payment metadata for specific groups. Regular DoS issues would be present, but any P2P network storing data for others faces similar challenges. 2015-07-21T14:58:39+00:00 + In a message from July 20, 2015, Mike Hearn proposed an idea for generating QR codes for Bitcoin payment requests. The method suggested using a single payment address without merge avoidance tricks and provided an example QR code. However, this approach would require text mode and waste bytes at the front for the URI type. To avoid this issue, it was suggested that assuming the payment request is a single standard output + amount would cover most cases and generate a serialized bip70 PR from the parameters found in the URI. The string would then be signed, and the signature added to the URI. This approach saves bits by expressing the duration of validity as one week. The resulting QR code can be scanned with a phone.The 2D-Doc is a French standard used to protect documents such as address proofs and invoices. It includes an ECDSA signature inside a 2D barcode, specifically a Datamatrix, not a QR code. The barcode encodes a summary of the protected document, followed by an ECDSA signature. The signature is done by an official government-approved 2D-Doc emitter. The 2D-Code contains a reference to designate which emitter signed it, and the 2D-Doc TSL supplied by the French government provides all the X509 Certificates from every emitter. This allows for checking the signature. While the 2D-Doc solves a different problem than Bitcoin+BIP70, it's worth noting as it successfully embeds an ECDSA signature inside a 2D barcode.The email suggests that advanced QR code standards could potentially be useful without any changes to BIP7x. If more data can be added without affecting scanning performance, it's possible to maintain the current dataset while improving scanning capabilities.The email proposes a solution to the BIP 70 usability problem without servers by using upgraded QR codes that have more space and optimizing BIP 70. It mentions the High Capacity Colored Two Dimensional Codes paper, which extends standard QR codes with color for increased capacity. Another paper, DualCodes, overlays one QR code on top of another using shades of gray for enhanced reader extraction. The authors of these papers could be contacted to see if they would open source their work. Additionally, defining a certificate's format, including its own Certificate Authorities (CAs), could result in smaller certificates. A QR code with a single payment address could be serialized directly into the QR code if an embedded reader was required. Andreas' wallet can already handle this, but it's unclear how iOS handles it. The email also discusses the idea of implementing a store/forward network for private responses or using the "Stealth Address" / ECDH in the payment protocol proposals. However, these ideas come at the cost of not being able to restore a wallet from seed words. The email suggests using servers to store Payment messages and nodes sharding themselves by announcing that they only store Payment metadata for specific groups. Regular DoS issues would be present, but any P2P network storing data for others faces similar challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_R-spuns-Personal-opinion-on-the-fee-market-from-a-worried-local-trader-.xml b/static/bitcoin-dev/July_2015/combined_R-spuns-Personal-opinion-on-the-fee-market-from-a-worried-local-trader-.xml index c72093c2fc..008a90c6d8 100644 --- a/static/bitcoin-dev/July_2015/combined_R-spuns-Personal-opinion-on-the-fee-market-from-a-worried-local-trader-.xml +++ b/static/bitcoin-dev/July_2015/combined_R-spuns-Personal-opinion-on-the-fee-market-from-a-worried-local-trader-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Răspuns: Personal opinion on the fee market from a worried local trader‏ - 2023-08-01T14:52:06.094646+00:00 + 2025-10-11T22:02:14.099503+00:00 + python-feedgen Dave 2015-07-31 14:29:14+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Răspuns: Personal opinion on the fee market from a worried local trader‏ - 2023-08-01T14:52:06.094646+00:00 + 2025-10-11T22:02:14.099654+00:00 - The message posted on the Bitcoin-dev mailing list highlights the concept of a "fee market" in Bitcoin. Unlike a binary option, this fee market exists in varying degrees over time. Currently, the fee per transaction in Bitcoin constitutes less than 0.5% of the rewards paid for mining a full block. This low fee percentage serves the purpose of driving the widespread and cost-effective use of Bitcoin, aiming to solidify its network effects for all users.To emphasize the importance of fees in maintaining network decentralization, an analogy was drawn with email adoption. The hypothetical scenario presented questioned how many people would have embraced email if there had been a per-message fee and hourly sending limits, with only the highest-fee messages being delivered. The analogy suggests that fees are necessary for ensuring the decentralized nature of the Bitcoin network, while avoiding fees would accelerate centralization.It is important to note that miners do not currently rely on fees as their primary source of income. In fact, they will not need to be paid by fees for many decades to come. Therefore, requesting miners to include transactions for free is not equivalent to asking them to give away money. The focus on driving Bitcoin usage without significant fees aims to pave the way for long-term growth and adoption, ultimately benefiting the entire Bitcoin ecosystem. 2015-07-31T14:29:14+00:00 + The message posted on the Bitcoin-dev mailing list highlights the concept of a "fee market" in Bitcoin. Unlike a binary option, this fee market exists in varying degrees over time. Currently, the fee per transaction in Bitcoin constitutes less than 0.5% of the rewards paid for mining a full block. This low fee percentage serves the purpose of driving the widespread and cost-effective use of Bitcoin, aiming to solidify its network effects for all users.To emphasize the importance of fees in maintaining network decentralization, an analogy was drawn with email adoption. The hypothetical scenario presented questioned how many people would have embraced email if there had been a per-message fee and hourly sending limits, with only the highest-fee messages being delivered. The analogy suggests that fees are necessary for ensuring the decentralized nature of the Bitcoin network, while avoiding fees would accelerate centralization.It is important to note that miners do not currently rely on fees as their primary source of income. In fact, they will not need to be paid by fees for many decades to come. Therefore, requesting miners to include transactions for free is not equivalent to asking them to give away money. The focus on driving Bitcoin usage without significant fees aims to pave the way for long-term growth and adoption, ultimately benefiting the entire Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_R-spuns-Personal-opinion-on-the-fee-market-from-a-worried-local-trader.xml b/static/bitcoin-dev/July_2015/combined_R-spuns-Personal-opinion-on-the-fee-market-from-a-worried-local-trader.xml index 6401a592ab..6395b23365 100644 --- a/static/bitcoin-dev/July_2015/combined_R-spuns-Personal-opinion-on-the-fee-market-from-a-worried-local-trader.xml +++ b/static/bitcoin-dev/July_2015/combined_R-spuns-Personal-opinion-on-the-fee-market-from-a-worried-local-trader.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Răspuns: Personal opinion on the fee market from a worried local trader - 2023-08-01T14:40:20.607505+00:00 + 2025-10-11T22:02:35.351559+00:00 + python-feedgen Raystonn . 2015-07-29 17:47:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Răspuns: Personal opinion on the fee market from a worried local trader - 2023-08-01T14:40:20.607505+00:00 + 2025-10-11T22:02:35.351722+00:00 - In an email conversation posted on the Bitcoin-dev mailing list, Vali Zero and Angel Leon express their differing opinions on the establishment of a fee market for Bitcoin transactions. Vali Zero believes that a fee market would create an equilibrium between the demand and supply of Bitcoin transactions. He suggests that individuals who can afford to pay higher fees would continue to use Bitcoin, while others might switch to altcoins. Vali Zero predicts that spammers and gamblers would be the first to leave due to high fees pricing them out. On the other hand, Angel Leon disagrees with Vali Zero's viewpoint and argues that everyone should have the freedom to use Bitcoin regardless of their transaction amounts or purposes. Angel asserts that the network needs to increase its block size to accommodate the growing number of users. He emphasizes that if Bitcoin becomes useless, it loses its value. Angel also highlights the importance of financial freedom and decentralization in Bitcoin transactions.Vali Zero counters Angel's argument by stating that a fee market would bleed value from Bitcoin and direct it towards alternative blockchains. He explains that people would exchange their Bitcoin for something that allows them to transact with lower fees, and then make their desired payment. Vali Zero warns against the misconception that the fee market would be limited to Bitcoin alone.Ultimately, both parties agree that the implementation of a fee market will impact the usage of Bitcoin. However, they differ in their approaches to managing it. Vali Zero advocates for a fee market, while Angel Leon argues for increasing the block size to prevent high fees and ensure usability. The discussion remains unresolved, leaving the topic open for further debate and exploration.Vali Zero is described as a local Bitcoin trader and computer engineer with a reasonable understanding of free markets. He operates only one full node. On the other hand, Angel Leon values financial freedom and decentralization in Bitcoin transactions but does not have any specific background mentioned.Overall, the email conversation presents a comprehensive discussion on the establishment of a fee market for Bitcoin transactions, with Vali Zero and Angel Leon offering contrasting perspectives on its implications and management. 2015-07-29T17:47:50+00:00 + In an email conversation posted on the Bitcoin-dev mailing list, Vali Zero and Angel Leon express their differing opinions on the establishment of a fee market for Bitcoin transactions. Vali Zero believes that a fee market would create an equilibrium between the demand and supply of Bitcoin transactions. He suggests that individuals who can afford to pay higher fees would continue to use Bitcoin, while others might switch to altcoins. Vali Zero predicts that spammers and gamblers would be the first to leave due to high fees pricing them out. On the other hand, Angel Leon disagrees with Vali Zero's viewpoint and argues that everyone should have the freedom to use Bitcoin regardless of their transaction amounts or purposes. Angel asserts that the network needs to increase its block size to accommodate the growing number of users. He emphasizes that if Bitcoin becomes useless, it loses its value. Angel also highlights the importance of financial freedom and decentralization in Bitcoin transactions.Vali Zero counters Angel's argument by stating that a fee market would bleed value from Bitcoin and direct it towards alternative blockchains. He explains that people would exchange their Bitcoin for something that allows them to transact with lower fees, and then make their desired payment. Vali Zero warns against the misconception that the fee market would be limited to Bitcoin alone.Ultimately, both parties agree that the implementation of a fee market will impact the usage of Bitcoin. However, they differ in their approaches to managing it. Vali Zero advocates for a fee market, while Angel Leon argues for increasing the block size to prevent high fees and ensure usability. The discussion remains unresolved, leaving the topic open for further debate and exploration.Vali Zero is described as a local Bitcoin trader and computer engineer with a reasonable understanding of free markets. He operates only one full node. On the other hand, Angel Leon values financial freedom and decentralization in Bitcoin transactions but does not have any specific background mentioned.Overall, the email conversation presents a comprehensive discussion on the establishment of a fee market for Bitcoin transactions, with Vali Zero and Angel Leon offering contrasting perspectives on its implications and management. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_REQ-BIP-Discuss-Sweep-incoming-unconfirmed-transactions-with-a-bounty-.xml b/static/bitcoin-dev/July_2015/combined_REQ-BIP-Discuss-Sweep-incoming-unconfirmed-transactions-with-a-bounty-.xml index b389bd7c60..ee0f7e7152 100644 --- a/static/bitcoin-dev/July_2015/combined_REQ-BIP-Discuss-Sweep-incoming-unconfirmed-transactions-with-a-bounty-.xml +++ b/static/bitcoin-dev/July_2015/combined_REQ-BIP-Discuss-Sweep-incoming-unconfirmed-transactions-with-a-bounty-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty. - 2023-08-01T14:12:37.349353+00:00 + 2025-10-11T22:01:12.407551+00:00 + python-feedgen Aaron Voisine 2015-08-26 15:28:45+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty. - 2023-08-01T14:12:37.349353+00:00 + 2025-10-11T22:01:12.407701+00:00 - Breadwallet, a Bitcoin wallet provider, has implemented the Child Pays for Parent (CPFP) feature when spending unconfirmed non-change inputs. The feature was released in May 2015 and is available on the company's Github page. Meanwhile, Dan Bryant via bitcoin-dev offered a bounty for anyone who can put a CPFP transaction creation feature into any wallet featured on the bitcoin homepage. The funds will be dispersed from a multisig address. A bounty has been offered to anyone who can add a Child Pays for Parent (CPFP) transaction creation feature to any wallet featured on the Bitcoin homepage. The funds for the bounty are being raised by donation and will be dispersed from a specific address once the bounty is claimed. The address is currently not well-funded, but donations are welcome. Proof that the multisig address is not 1 of 1 can be found on Bitcointalk.org. It seems that someone attempted to increase a transaction and succeeded in getting it approved. The hash values of the parent, child, grandchild, great-grandchild, and great-great-grandchild blocks are provided, but the position of the transaction in the block is not a priority or fee cut line.During a conversation between Aaron Voisine and an unknown person on July 9, 2015, Aaron asked if the person knew how much hashing power was using CPFP. This information would be helpful for wallet developers to determine their confirmation times when utilizing CPFP. The other person was unsure of the exact percentage but suggested that at least 4% of hashing power on the Eligius platform was using CPFP.In a Bitcoin development mailing list, Luke Dashjr corrected a misconception in a BIP proposal regarding Child Pays for Parent (CPFP) transaction selection. The proposal assumed that miners were already utilizing CPFP, but Luke clarified that while it is not included in the reference policy, some miners do use it. Aaron Voisine, co-founder and CEO of breadwallet.com, chimed in to mention how knowing the amount of hashing power being used for CPFP could be useful for wallet developers to estimate confirmation times.In a conversation between Dan Bryant and Luke, it was discussed that when Dan wrote the BIP proposal, he assumed that CPFP (Child Pays For Parent) transaction selection was already being done by miners. However, it was pointed out that this assumption was correct, but not included in the reference policy. It was stated that miners are not expected to use the reference policy as-is and some of them do use CPFP.The discussion on Bitcoin development mailing list is about child pays for parent (CPFP) and Replace-by-fee (RBF). CPFP is a transaction selection policy in which the high fee from a child transaction is used to pay for its unconfirmed parent's fee. A pull request, #1647, has been created to implement CPFP but it only addresses miner policy. Matt Whitlock argues that wallets also need to offer users a way to goose up incoming transactions for CPFP to be effective. The sweep transaction UI issue is out of scope for the BIP proposal. Dan Bryant suggests talking with wallet authors to get them interested in this feature enhancement when PR1647 commits. The risks involved if CPFP is not enabled but the sweep tx enters the mempool are discussed and how miners may take the high fee "children" but ignore the low fee "parents," leading to potential issues. Peter Todd's article outlines the two forms of RBF: the countermeasure form and the anyonecanpay form. In the countermeasure form, the spender gives the receiver a partially signed "countermeasure" transaction with juiced-up fees. In the anyonecanpay form, the spender signs the transaction with ANYONECANPAY bit allowing the receiver to add fees at will. It is clarified that a transaction that is not completely signed won't be relayed, correct, and it cannot be mined. Lastly, Dan Bryant states he will try to clean up the draft BIP to include CPFP dependencies and RBF capabilities and will outline his thoughts in a doc.In a Bitcoin-development mailing list discussion, Mark Friedenbach introduced the concept of CPFP or “child pays for parent”. This feature allows miners to prioritize transactions in a block based on the fees attached to them. A pull request from 2015, PR#1647, implemented this feature which indicated that certain trees could bloom the TX selection latency as miners would need to be more dependency aware. However, it only addressed miner policy and did not offer a user-facing side of functionality. Matt Whitlock pointed out that the BIP proposal for CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions.Mark Friedenbach has suggested a child pays for parent (CPFP) method which would require changes to the P2P layer to support RBF scorched earth. The transactions are processed individually and 2015-08-26T15:28:45+00:00 + Breadwallet, a Bitcoin wallet provider, has implemented the Child Pays for Parent (CPFP) feature when spending unconfirmed non-change inputs. The feature was released in May 2015 and is available on the company's Github page. Meanwhile, Dan Bryant via bitcoin-dev offered a bounty for anyone who can put a CPFP transaction creation feature into any wallet featured on the bitcoin homepage. The funds will be dispersed from a multisig address. A bounty has been offered to anyone who can add a Child Pays for Parent (CPFP) transaction creation feature to any wallet featured on the Bitcoin homepage. The funds for the bounty are being raised by donation and will be dispersed from a specific address once the bounty is claimed. The address is currently not well-funded, but donations are welcome. Proof that the multisig address is not 1 of 1 can be found on Bitcointalk.org. It seems that someone attempted to increase a transaction and succeeded in getting it approved. The hash values of the parent, child, grandchild, great-grandchild, and great-great-grandchild blocks are provided, but the position of the transaction in the block is not a priority or fee cut line.During a conversation between Aaron Voisine and an unknown person on July 9, 2015, Aaron asked if the person knew how much hashing power was using CPFP. This information would be helpful for wallet developers to determine their confirmation times when utilizing CPFP. The other person was unsure of the exact percentage but suggested that at least 4% of hashing power on the Eligius platform was using CPFP.In a Bitcoin development mailing list, Luke Dashjr corrected a misconception in a BIP proposal regarding Child Pays for Parent (CPFP) transaction selection. The proposal assumed that miners were already utilizing CPFP, but Luke clarified that while it is not included in the reference policy, some miners do use it. Aaron Voisine, co-founder and CEO of breadwallet.com, chimed in to mention how knowing the amount of hashing power being used for CPFP could be useful for wallet developers to estimate confirmation times.In a conversation between Dan Bryant and Luke, it was discussed that when Dan wrote the BIP proposal, he assumed that CPFP (Child Pays For Parent) transaction selection was already being done by miners. However, it was pointed out that this assumption was correct, but not included in the reference policy. It was stated that miners are not expected to use the reference policy as-is and some of them do use CPFP.The discussion on Bitcoin development mailing list is about child pays for parent (CPFP) and Replace-by-fee (RBF). CPFP is a transaction selection policy in which the high fee from a child transaction is used to pay for its unconfirmed parent's fee. A pull request, #1647, has been created to implement CPFP but it only addresses miner policy. Matt Whitlock argues that wallets also need to offer users a way to goose up incoming transactions for CPFP to be effective. The sweep transaction UI issue is out of scope for the BIP proposal. Dan Bryant suggests talking with wallet authors to get them interested in this feature enhancement when PR1647 commits. The risks involved if CPFP is not enabled but the sweep tx enters the mempool are discussed and how miners may take the high fee "children" but ignore the low fee "parents," leading to potential issues. Peter Todd's article outlines the two forms of RBF: the countermeasure form and the anyonecanpay form. In the countermeasure form, the spender gives the receiver a partially signed "countermeasure" transaction with juiced-up fees. In the anyonecanpay form, the spender signs the transaction with ANYONECANPAY bit allowing the receiver to add fees at will. It is clarified that a transaction that is not completely signed won't be relayed, correct, and it cannot be mined. Lastly, Dan Bryant states he will try to clean up the draft BIP to include CPFP dependencies and RBF capabilities and will outline his thoughts in a doc.In a Bitcoin-development mailing list discussion, Mark Friedenbach introduced the concept of CPFP or “child pays for parent”. This feature allows miners to prioritize transactions in a block based on the fees attached to them. A pull request from 2015, PR#1647, implemented this feature which indicated that certain trees could bloom the TX selection latency as miners would need to be more dependency aware. However, it only addressed miner policy and did not offer a user-facing side of functionality. Matt Whitlock pointed out that the BIP proposal for CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions.Mark Friedenbach has suggested a child pays for parent (CPFP) method which would require changes to the P2P layer to support RBF scorched earth. The transactions are processed individually and - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml b/static/bitcoin-dev/July_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml index ea54d89274..b769b637de 100644 --- a/static/bitcoin-dev/July_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml +++ b/static/bitcoin-dev/July_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC: HD Bitmessage address derivation based on BIP-43 - 2023-08-01T14:09:53.705304+00:00 + 2025-10-11T22:01:03.918931+00:00 + python-feedgen Jorge Timón 2015-09-06 02:09:52+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - RFC: HD Bitmessage address derivation based on BIP-43 - 2023-08-01T14:09:53.705304+00:00 + 2025-10-11T22:01:03.919137+00:00 - In September 2015, a discussion took place on the Bitcoin-dev mailing list regarding the maintenance of competing registries for different companies and P2P chains. Some argued that the current centralized registries were acceptable as long as they didn't rely on having only one registry or having the same values for the same chains. However, others believed that BIP44's centralized registry control by a single company was not acceptable and proposed using a code deterministically generated from the chain ID instead. This proposal was seen as retro-compatible and provided securely unique IDs without the need for a centralized registry. It was suggested to start a Chain IDs BIP.The BIP repository made a decision to move part of the standard to a separate repository due to the constant updates unrelated to Bitcoin proper. On September 5th, 2015, a conversation between Jorge Timón and Justus Ranvier on the bitcoin-dev mailing list addressed concerns about delegating the BIP-43 namespace management to a specific company (SatoshiLabs). Justus questioned the benefit of this delegation and proposed using purpose codes matching the BIP number instead. He also expressed concerns with BIP44's centralized registry control and suggested using a code deterministically generated from the chain ID as a solution.Luke Dashjr, a Bitcoin Core Developer, expressed concerns about polluting the BIP repository with non-Bitcoin related specifications in response to a proposal to add HD generation of keypairs from a single seed for non-conflicting uses. Justus Ranvier countered by stating that intentionally making a useful technology less useful due to difficulties in assigning non-colliding numbers was a strange approach to software engineering. Justus Ranvier is associated with the Open Bitcoin Privacy Project, which promotes financial privacy and anonymity through the use of Bitcoin.On June 30, 2015, Justus Ranvier proposed a Bitmessage address derivation method based on BIP-43 developed by Monetas. This method allows Bitmessage users to generate addresses from a seed, providing eternal key backups and enabling future use cases. Monetas proposed this method as a BIP to reserve a purpose code. The proposal was made on the bitcoin-dev mailing list and included links to the relevant GitHub pages and contact details.Overall, the discussions on the bitcoin-dev mailing list revolved around the management of purpose codes, registry control, and the benefits and drawbacks of different approaches to maintain competing registries for different companies and P2P chains. 2015-09-06T02:09:52+00:00 + In September 2015, a discussion took place on the Bitcoin-dev mailing list regarding the maintenance of competing registries for different companies and P2P chains. Some argued that the current centralized registries were acceptable as long as they didn't rely on having only one registry or having the same values for the same chains. However, others believed that BIP44's centralized registry control by a single company was not acceptable and proposed using a code deterministically generated from the chain ID instead. This proposal was seen as retro-compatible and provided securely unique IDs without the need for a centralized registry. It was suggested to start a Chain IDs BIP.The BIP repository made a decision to move part of the standard to a separate repository due to the constant updates unrelated to Bitcoin proper. On September 5th, 2015, a conversation between Jorge Timón and Justus Ranvier on the bitcoin-dev mailing list addressed concerns about delegating the BIP-43 namespace management to a specific company (SatoshiLabs). Justus questioned the benefit of this delegation and proposed using purpose codes matching the BIP number instead. He also expressed concerns with BIP44's centralized registry control and suggested using a code deterministically generated from the chain ID as a solution.Luke Dashjr, a Bitcoin Core Developer, expressed concerns about polluting the BIP repository with non-Bitcoin related specifications in response to a proposal to add HD generation of keypairs from a single seed for non-conflicting uses. Justus Ranvier countered by stating that intentionally making a useful technology less useful due to difficulties in assigning non-colliding numbers was a strange approach to software engineering. Justus Ranvier is associated with the Open Bitcoin Privacy Project, which promotes financial privacy and anonymity through the use of Bitcoin.On June 30, 2015, Justus Ranvier proposed a Bitmessage address derivation method based on BIP-43 developed by Monetas. This method allows Bitmessage users to generate addresses from a seed, providing eternal key backups and enabling future use cases. Monetas proposed this method as a BIP to reserve a purpose code. The proposal was made on the bitcoin-dev mailing list and included links to the relevant GitHub pages and contact details.Overall, the discussions on the bitcoin-dev mailing list revolved around the management of purpose codes, registry control, and the benefits and drawbacks of different approaches to maintain competing registries for different companies and P2P chains. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_SPV-Mining-reveals-a-problematic-incentive-issue-.xml b/static/bitcoin-dev/July_2015/combined_SPV-Mining-reveals-a-problematic-incentive-issue-.xml index 495abafde1..6f52c2f6c3 100644 --- a/static/bitcoin-dev/July_2015/combined_SPV-Mining-reveals-a-problematic-incentive-issue-.xml +++ b/static/bitcoin-dev/July_2015/combined_SPV-Mining-reveals-a-problematic-incentive-issue-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SPV Mining reveals a problematic incentive issue. - 2023-08-01T14:17:22.667742+00:00 + 2025-10-11T22:01:18.786880+00:00 + python-feedgen Eric Lombrozo 2015-07-13 17:49:40+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - SPV Mining reveals a problematic incentive issue. - 2023-08-01T14:17:22.667742+00:00 + 2025-10-11T22:01:18.787054+00:00 - The discussion on the Bitcoin-dev mailing list revolves around the topic of SPV mining and its impact on the network. Jorge Timón suggests that all miners should validate transactions to prevent SPV mining, which he believes is not rational. He recommends that miners continue mining on top of the old block until they have fully validated the new one. However, Peter Todd points out the vulnerability of F2Pool/AntPool finding out about new blocks through anonymous connections, which can lead to fake information and invalid blocks being made. Eric Lombrozo emphasizes the importance of secure validation to maintain security and scalability. The conversation also touches on the use of SPV as protection against third-party-run trusted full nodes from lying to users. While relying solely on SPV with low numbers of confirmations is not smart, it can provide reasonable protection against fake blocks created by attackers targeting multiple people. Trusted third-party-run full nodes, combined with SPV, can offer reasonable safety for now.In an email conversation, Jorge Timón suggests that miners should validate transactions to prevent SPV mining. He argues that full miners can leverage their validation against SPV miners who blindly spend energy hashing on potentially worthless blocks. He recommends that miners continue mining on top of the old block until they fully validate the new block, even if it slightly increases the orphan rate. The discussion also highlights the issue of F2Pool/AntPool finding out about new blocks through anonymous connections, which can lead to fake information and invalid blocks. It is crucial to mark headers as "probably invalid" and update all the header's children to mitigate this risk.Another conversation between Tier Nolan and Jorge Timón discusses the security risks associated with SPV mining. They discuss the tradeoff between mining on top of a non-most-work-but-surely-valid block and mining on top of a most-work-but-potentially-invalid block. Both options have risks, but mining on top of the previous block has a lower impact on regular SPV users. The conversation mentions that mining on the previous block allows including transactions and earning fees, which is advantageous in a future where block rewards are not dominated by subsidies. The discussion also explores the potential issues that may arise if hashing is not constantly applied. Rational miners would power down their hashing when there are no interesting fees in the mempool to save energy costs. However, this behavior can lead to malicious miners re-mining the previous block and dropping some transactions, offering other miners more reward if they mine on top of the re-mined block. The discussion calls for solutions to address the problem of SPV mining and its impact on the network's robustness.Nathan Wilcox raises concerns about the disincentive for miners to verify transactions, weakening the network against forks. SPV mining has become popular among miners, but it allows consensus-violating forks to persist. The cost of verifying transactions leads some miners to forego verification, increasing the risk of mining atop an invalid block. Wilcox suggests incentivizing miners to verify transactions to prevent malicious miners from including erroneous transactions in their blocks. The discussion emphasizes the need to address the issue of SPV mining and its impact on the network's robustness.The discussion also touches on the topic of inter-block times and the variation in block-to-block times. If hashing is not constantly applied, the inter-block times will expand, reducing the difficulty and giving an advantage to pools that use all available hashing power. Having useful fees immediately after a block is found reduces the incentives to deliberately orphan the last block.SPV mining is discussed as a technique to prevent hashing hardware from wasting power when it isn't needed. SPV miners put headers in the "probably valid" category and build empty blocks on top of them. However, as time passes without full validation, the likelihood of the block being valid decreases. Increasing the timeout does not provide significant benefits. It is mentioned that in a future with low minting fees, there is no point in SPV mining since pools only earn income from transaction fees. The discussion suggests alternative models for pool payment and highlights the potential increase in average fee per byte for transactions as time passes since the last block.Overall, the discussions highlight the importance of transaction validation, the vulnerabilities of SPV mining, and the need to address these issues for the robustness and security of the Bitcoin network. 2015-07-13T17:49:40+00:00 + The discussion on the Bitcoin-dev mailing list revolves around the topic of SPV mining and its impact on the network. Jorge Timón suggests that all miners should validate transactions to prevent SPV mining, which he believes is not rational. He recommends that miners continue mining on top of the old block until they have fully validated the new one. However, Peter Todd points out the vulnerability of F2Pool/AntPool finding out about new blocks through anonymous connections, which can lead to fake information and invalid blocks being made. Eric Lombrozo emphasizes the importance of secure validation to maintain security and scalability. The conversation also touches on the use of SPV as protection against third-party-run trusted full nodes from lying to users. While relying solely on SPV with low numbers of confirmations is not smart, it can provide reasonable protection against fake blocks created by attackers targeting multiple people. Trusted third-party-run full nodes, combined with SPV, can offer reasonable safety for now.In an email conversation, Jorge Timón suggests that miners should validate transactions to prevent SPV mining. He argues that full miners can leverage their validation against SPV miners who blindly spend energy hashing on potentially worthless blocks. He recommends that miners continue mining on top of the old block until they fully validate the new block, even if it slightly increases the orphan rate. The discussion also highlights the issue of F2Pool/AntPool finding out about new blocks through anonymous connections, which can lead to fake information and invalid blocks. It is crucial to mark headers as "probably invalid" and update all the header's children to mitigate this risk.Another conversation between Tier Nolan and Jorge Timón discusses the security risks associated with SPV mining. They discuss the tradeoff between mining on top of a non-most-work-but-surely-valid block and mining on top of a most-work-but-potentially-invalid block. Both options have risks, but mining on top of the previous block has a lower impact on regular SPV users. The conversation mentions that mining on the previous block allows including transactions and earning fees, which is advantageous in a future where block rewards are not dominated by subsidies. The discussion also explores the potential issues that may arise if hashing is not constantly applied. Rational miners would power down their hashing when there are no interesting fees in the mempool to save energy costs. However, this behavior can lead to malicious miners re-mining the previous block and dropping some transactions, offering other miners more reward if they mine on top of the re-mined block. The discussion calls for solutions to address the problem of SPV mining and its impact on the network's robustness.Nathan Wilcox raises concerns about the disincentive for miners to verify transactions, weakening the network against forks. SPV mining has become popular among miners, but it allows consensus-violating forks to persist. The cost of verifying transactions leads some miners to forego verification, increasing the risk of mining atop an invalid block. Wilcox suggests incentivizing miners to verify transactions to prevent malicious miners from including erroneous transactions in their blocks. The discussion emphasizes the need to address the issue of SPV mining and its impact on the network's robustness.The discussion also touches on the topic of inter-block times and the variation in block-to-block times. If hashing is not constantly applied, the inter-block times will expand, reducing the difficulty and giving an advantage to pools that use all available hashing power. Having useful fees immediately after a block is found reduces the incentives to deliberately orphan the last block.SPV mining is discussed as a technique to prevent hashing hardware from wasting power when it isn't needed. SPV miners put headers in the "probably valid" category and build empty blocks on top of them. However, as time passes without full validation, the likelihood of the block being valid decreases. Increasing the timeout does not provide significant benefits. It is mentioned that in a future with low minting fees, there is no point in SPV mining since pools only earn income from transaction fees. The discussion suggests alternative models for pool payment and highlights the potential increase in average fee per byte for transactions as time passes since the last block.Overall, the discussions highlight the importance of transaction validation, the vulnerabilities of SPV mining, and the need to address these issues for the robustness and security of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Significant-losses-by-double-spending-unconfirmed-transactions.xml b/static/bitcoin-dev/July_2015/combined_Significant-losses-by-double-spending-unconfirmed-transactions.xml index 549c20fef5..70ddb65b61 100644 --- a/static/bitcoin-dev/July_2015/combined_Significant-losses-by-double-spending-unconfirmed-transactions.xml +++ b/static/bitcoin-dev/July_2015/combined_Significant-losses-by-double-spending-unconfirmed-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Significant losses by double-spending unconfirmed transactions - 2023-08-01T14:22:10.039964+00:00 + 2025-10-11T22:01:48.558968+00:00 + python-feedgen Peter Todd 2015-07-18 15:09:40+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Significant losses by double-spending unconfirmed transactions - 2023-08-01T14:22:10.040957+00:00 + 2025-10-11T22:01:48.559172+00:00 - A thorough examination of the relay drop rules in Bitcoin XT, specifically regarding the min-relay-fee drop, has revealed that this drop in fees has led to double-spend attacks and wasted resources for nodes, resulting in crashes. The bitcoin-dev mailing list has been discussing this issue, with contributions from various members such as Mike Hearn, Gavin, Tom, Simon, Arne, Matthieu Riou, Peter Todd, and others. It is acknowledged that patches by Gavin and Tom were included in Bitcoin XT, but it is pointed out that the conversation was actually about the min-relay-fee drop that Mike Hearn wrote. This fee drop has allowed for double-spending and has caused nodes to waste bandwidth and memory, resulting in crashes. The discussion concludes with a digital signature and an attachment.Within the discussion, users inquire about pre- and post-Hearn relay drop rules in Bitcoin XT, seeking clarification on their relationship with the minrelaytxfee setting proposed in the 0.11.0 release notes. Simon shares their success with double-spend attacks against zeroconf accepting individuals and advises against relying on zeroconf transactions. They also mention that Shapeshift.io lost around 3 BTC due to these types of attacks. Matthieu Riou from BlockCypher is implicated in the discussion as well. Peter Todd accuses BlockCypher of being "inherently incompatible with decentralisation," suggesting they may have relationships with mining pools. Riou denies any such relationships exist and argues against Todd's accusations. Another user points out that Riou's company is not executing a Sybil attack on the network, despite connecting to a significant number of nodes. The discussion ends with warnings about the vulnerability of zeroconf transactions and the need to re-examine dust as an opportunity for microgiving.The discussion also touches on the concept of Sybil attacks in peer-to-peer networks, with Peter Todd explaining how they can occur and Matthieu Riou arguing that this is not the case in Bitcoin. Todd raises concerns about BlockCypher's resource use and their relationships with mining pools, to which Riou denies having any contracts. The discussion ends with Todd accusing BlockCypher of actions incompatible with decentralization, and Riou defending their services for startups and expressing their commitment to helping decentralization.Additionally, there are discussions about the potential of on-chain microtransaction systems and the need for re-evaluation of dust as a means of microgiving. The author promotes their project, abis.io, which aims to enable decentralized giving. The conversation shifts to the accusation of Sybil attacks made by Peter Todd, with other developers refuting these claims and highlighting the lack of expertise in systematic risk analysis among Bitcoin companies. There is also a discussion about the actions taken by Chainalysis, which were referred to as a Sybil attack, but the developers argue that it does not fit the definition of an attack according to ISO/IEC 27000.In another exchange, Matthieu Riou thanks Simon for reporting a bug and assures ShapeShift that they will be protected from future attacks. Riou responds to accusations made by Peter Todd on social media, stating that Todd does not understand their business model or objectives. Todd accuses BlockCypher of conducting a Sybil attack, but Riou dismisses this claim as unfounded. The discussion continues with concerns about BlockCypher's resource usage and its compatibility with decentralization. Riou denies having relationships with mining pools and emphasizes BlockCypher's commitment to helping decentralization despite limited resources.The discussion on the bitcoin-dev mailing list highlights the vulnerabilities of zeroconf transactions and warns users against relying on them. It also addresses the issues surrounding the relay drop rules in Bitcoin XT and the impact of double-spend attacks. The thread includes discussions about Sybil attacks, resource usage, and relationships with mining pools. Throughout the conversation, there are disagreements and clarifications among the participants, emphasizing the need for caution and further analysis in addressing these issues.Developers in the Bitcoin community have been making exaggerated and negative statements about users, accusing them of being spammers and engaging in Sybil attacks. However, these claims are baseless and lack evidence. In fact, if this trend continues, it can be seen as an attack on developers themselves, revealing conflicts of interest within the system. It is crucial to conduct a systematic risk analysis to avoid such unfounded accusations and ensure the reliability and scalability of the Bitcoin network.A member of the bitcoin-dev community questioned the notion that having a large number of standard nodes running on the network strengthens it. Pieter Wuille, a Bitcoin Core developer, responded by explaining that running many nodes does not actually enhance the network's strength in terms of reducing trust between participants. He argued that it is better to run and control one or a few full nodes that validate transactions, rather than numerous nodes in third-party data centers, which may appear more decentralized but lack effectiveness.Peter Todd expressed concerns about Blockcypher's business model, 2015-07-18T15:09:40+00:00 + A thorough examination of the relay drop rules in Bitcoin XT, specifically regarding the min-relay-fee drop, has revealed that this drop in fees has led to double-spend attacks and wasted resources for nodes, resulting in crashes. The bitcoin-dev mailing list has been discussing this issue, with contributions from various members such as Mike Hearn, Gavin, Tom, Simon, Arne, Matthieu Riou, Peter Todd, and others. It is acknowledged that patches by Gavin and Tom were included in Bitcoin XT, but it is pointed out that the conversation was actually about the min-relay-fee drop that Mike Hearn wrote. This fee drop has allowed for double-spending and has caused nodes to waste bandwidth and memory, resulting in crashes. The discussion concludes with a digital signature and an attachment.Within the discussion, users inquire about pre- and post-Hearn relay drop rules in Bitcoin XT, seeking clarification on their relationship with the minrelaytxfee setting proposed in the 0.11.0 release notes. Simon shares their success with double-spend attacks against zeroconf accepting individuals and advises against relying on zeroconf transactions. They also mention that Shapeshift.io lost around 3 BTC due to these types of attacks. Matthieu Riou from BlockCypher is implicated in the discussion as well. Peter Todd accuses BlockCypher of being "inherently incompatible with decentralisation," suggesting they may have relationships with mining pools. Riou denies any such relationships exist and argues against Todd's accusations. Another user points out that Riou's company is not executing a Sybil attack on the network, despite connecting to a significant number of nodes. The discussion ends with warnings about the vulnerability of zeroconf transactions and the need to re-examine dust as an opportunity for microgiving.The discussion also touches on the concept of Sybil attacks in peer-to-peer networks, with Peter Todd explaining how they can occur and Matthieu Riou arguing that this is not the case in Bitcoin. Todd raises concerns about BlockCypher's resource use and their relationships with mining pools, to which Riou denies having any contracts. The discussion ends with Todd accusing BlockCypher of actions incompatible with decentralization, and Riou defending their services for startups and expressing their commitment to helping decentralization.Additionally, there are discussions about the potential of on-chain microtransaction systems and the need for re-evaluation of dust as a means of microgiving. The author promotes their project, abis.io, which aims to enable decentralized giving. The conversation shifts to the accusation of Sybil attacks made by Peter Todd, with other developers refuting these claims and highlighting the lack of expertise in systematic risk analysis among Bitcoin companies. There is also a discussion about the actions taken by Chainalysis, which were referred to as a Sybil attack, but the developers argue that it does not fit the definition of an attack according to ISO/IEC 27000.In another exchange, Matthieu Riou thanks Simon for reporting a bug and assures ShapeShift that they will be protected from future attacks. Riou responds to accusations made by Peter Todd on social media, stating that Todd does not understand their business model or objectives. Todd accuses BlockCypher of conducting a Sybil attack, but Riou dismisses this claim as unfounded. The discussion continues with concerns about BlockCypher's resource usage and its compatibility with decentralization. Riou denies having relationships with mining pools and emphasizes BlockCypher's commitment to helping decentralization despite limited resources.The discussion on the bitcoin-dev mailing list highlights the vulnerabilities of zeroconf transactions and warns users against relying on them. It also addresses the issues surrounding the relay drop rules in Bitcoin XT and the impact of double-spend attacks. The thread includes discussions about Sybil attacks, resource usage, and relationships with mining pools. Throughout the conversation, there are disagreements and clarifications among the participants, emphasizing the need for caution and further analysis in addressing these issues.Developers in the Bitcoin community have been making exaggerated and negative statements about users, accusing them of being spammers and engaging in Sybil attacks. However, these claims are baseless and lack evidence. In fact, if this trend continues, it can be seen as an attack on developers themselves, revealing conflicts of interest within the system. It is crucial to conduct a systematic risk analysis to avoid such unfounded accusations and ensure the reliability and scalability of the Bitcoin network.A member of the bitcoin-dev community questioned the notion that having a large number of standard nodes running on the network strengthens it. Pieter Wuille, a Bitcoin Core developer, responded by explaining that running many nodes does not actually enhance the network's strength in terms of reducing trust between participants. He argued that it is better to run and control one or a few full nodes that validate transactions, rather than numerous nodes in third-party data centers, which may appear more decentralized but lack effectiveness.Peter Todd expressed concerns about Blockcypher's business model, - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Thoughts-on-Forks-Scalability-and-other-Bitcoin-inconveniences-.xml b/static/bitcoin-dev/July_2015/combined_Thoughts-on-Forks-Scalability-and-other-Bitcoin-inconveniences-.xml index ef01eaf06e..2f937449af 100644 --- a/static/bitcoin-dev/July_2015/combined_Thoughts-on-Forks-Scalability-and-other-Bitcoin-inconveniences-.xml +++ b/static/bitcoin-dev/July_2015/combined_Thoughts-on-Forks-Scalability-and-other-Bitcoin-inconveniences-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Thoughts on Forks, Scalability, and other Bitcoin inconveniences. - 2023-08-01T14:14:35.919231+00:00 + 2025-10-11T22:02:26.856448+00:00 + python-feedgen Eric Lombrozo 2015-07-05 21:08:12+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Thoughts on Forks, Scalability, and other Bitcoin inconveniences. - 2023-08-01T14:14:35.919231+00:00 + 2025-10-11T22:02:26.856638+00:00 - In a conversation about Bitcoin security, Eric Lombrozo and Justus Ranvier discuss the challenges of achieving perfect security in the cryptocurrency. Lombrozo emphasizes that while Bitcoin aims to be trustless, it does not promise infinite security. He believes that striving for perfection can hinder progress towards good security measures. Ranvier, associated with the Open Bitcoin Privacy Project, agrees that good security is more important than an unachievable standard of perfection.Lombrozo argues that trust has been introduced into various elements of the Bitcoin network, undermining its original security model. Ranvier counters that trust has not completely abandoned the security model, as long as users have access to the complete blockchain. He suggests that improving the security of simplified payment verification (SPV) clients requires a mechanism to prove the invalidity of blocks for honest nodes.Lombrozo further explains how the current state of the Bitcoin network relies on trust in validators, miners, relayers, explorer websites, and online wallets. However, this contradicts the trustlessness that Bitcoin was designed for and compromises its security model. The security model aims to prevent double spending without a trusted third party, requiring attackers to pay a proof of work cost. The model holds for users with access to the complete blockchain but fails for those without it. To address this issue, a mechanism is needed for honest nodes to prove the invalidity of blocks, enhancing the security of SPV clients.Lombrozo also highlights the rising cost of validating the blockchain, making compliance with the original security model impractical for most use cases. Trust has been introduced as a practical way for the network to function, but it deviates from the trustlessness that Bitcoin intended. This has led to an unspecified replacement of the security model, with uncertain boundaries. There is now reliance on a few developers and mining pool operators, potentially compromising the network's benefits. Lombrozo suggests solving the validation cost/bottleneck issue or constructing a new security model that considers these trust assumptions. 2015-07-05T21:08:12+00:00 + In a conversation about Bitcoin security, Eric Lombrozo and Justus Ranvier discuss the challenges of achieving perfect security in the cryptocurrency. Lombrozo emphasizes that while Bitcoin aims to be trustless, it does not promise infinite security. He believes that striving for perfection can hinder progress towards good security measures. Ranvier, associated with the Open Bitcoin Privacy Project, agrees that good security is more important than an unachievable standard of perfection.Lombrozo argues that trust has been introduced into various elements of the Bitcoin network, undermining its original security model. Ranvier counters that trust has not completely abandoned the security model, as long as users have access to the complete blockchain. He suggests that improving the security of simplified payment verification (SPV) clients requires a mechanism to prove the invalidity of blocks for honest nodes.Lombrozo further explains how the current state of the Bitcoin network relies on trust in validators, miners, relayers, explorer websites, and online wallets. However, this contradicts the trustlessness that Bitcoin was designed for and compromises its security model. The security model aims to prevent double spending without a trusted third party, requiring attackers to pay a proof of work cost. The model holds for users with access to the complete blockchain but fails for those without it. To address this issue, a mechanism is needed for honest nodes to prove the invalidity of blocks, enhancing the security of SPV clients.Lombrozo also highlights the rising cost of validating the blockchain, making compliance with the original security model impractical for most use cases. Trust has been introduced as a practical way for the network to function, but it deviates from the trustlessness that Bitcoin intended. This has led to an unspecified replacement of the security model, with uncertain boundaries. There is now reliance on a few developers and mining pool operators, potentially compromising the network's benefits. Lombrozo suggests solving the validation cost/bottleneck issue or constructing a new security model that considers these trust assumptions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Upcoming-DOS-vulnerability-announcements-for-Bitcoin-Core.xml b/static/bitcoin-dev/July_2015/combined_Upcoming-DOS-vulnerability-announcements-for-Bitcoin-Core.xml index ffc8e94c81..75f61cc6e2 100644 --- a/static/bitcoin-dev/July_2015/combined_Upcoming-DOS-vulnerability-announcements-for-Bitcoin-Core.xml +++ b/static/bitcoin-dev/July_2015/combined_Upcoming-DOS-vulnerability-announcements-for-Bitcoin-Core.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Upcoming DOS vulnerability announcements for Bitcoin Core - 2023-08-01T14:00:35.965534+00:00 + 2025-10-11T22:02:03.440319+00:00 + python-feedgen Gregory Maxwell 2015-07-07 23:14:18+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Upcoming DOS vulnerability announcements for Bitcoin Core - 2023-08-01T14:00:35.965534+00:00 + 2025-10-11T22:02:03.440548+00:00 - On July 7th, 2015, Gregory Maxwell announced that he would disclose several serious denial of service vulnerabilities in Bitcoin Core, including CVE-2015-3641. He strongly recommended upgrading to version 0.10.2 as soon as possible for production nodes exposed to inbound internet connections. Older systems, especially miners, should also be upgraded due to the impending BIP66 soft-fork reaching enforcing status. However, the announcement was delayed due to network turbulence and attempted DOS attack activity on relayed infrastructure. Other cryptocurrency implementers requested a longer horizon for the disclosure.On June 27th, 2015, Jameson Lopp mentioned the release notes for Bitcoin version 0.10.2, noting that it only had significant changes for Windows. This explains why the Ubuntu PPA does not carry 0.10.2. Thomas Pryds asked when or if 0.10.2 would be available on the Ubuntu PPA, expressing a preference for the convenience of using a PPA rather than installing manually. Gregory Maxwell reiterated his recommendation of upgrading to 0.10.2 for production nodes exposed to inbound internet connections.On the same day, Gregory Maxwell shared a link to the Bitcoin-dev mailing list. The link leads to a message written by Wladimir, the lead developer of Bitcoin Core, discussing the importance of rigorous testing for new releases. Wladimir emphasized that proper testing is crucial to ensure stability and reliability. He highlighted the improved testing process with automated tools and a team of dedicated testers. Wladimir called for more developers, particularly those experienced in software testing, to contribute to the testing effort. He encouraged interested developers to reach out to the Bitcoin Core team and get involved. Overall, Wladimir's message emphasized the collaborative nature of open-source software development and the importance of testing in Bitcoin Core's development.To learn more about the disclosed denial of service vulnerabilities and the recommended upgrade to version 0.10.2, refer to the SourceForge link provided. 2015-07-07T23:14:18+00:00 + On July 7th, 2015, Gregory Maxwell announced that he would disclose several serious denial of service vulnerabilities in Bitcoin Core, including CVE-2015-3641. He strongly recommended upgrading to version 0.10.2 as soon as possible for production nodes exposed to inbound internet connections. Older systems, especially miners, should also be upgraded due to the impending BIP66 soft-fork reaching enforcing status. However, the announcement was delayed due to network turbulence and attempted DOS attack activity on relayed infrastructure. Other cryptocurrency implementers requested a longer horizon for the disclosure.On June 27th, 2015, Jameson Lopp mentioned the release notes for Bitcoin version 0.10.2, noting that it only had significant changes for Windows. This explains why the Ubuntu PPA does not carry 0.10.2. Thomas Pryds asked when or if 0.10.2 would be available on the Ubuntu PPA, expressing a preference for the convenience of using a PPA rather than installing manually. Gregory Maxwell reiterated his recommendation of upgrading to 0.10.2 for production nodes exposed to inbound internet connections.On the same day, Gregory Maxwell shared a link to the Bitcoin-dev mailing list. The link leads to a message written by Wladimir, the lead developer of Bitcoin Core, discussing the importance of rigorous testing for new releases. Wladimir emphasized that proper testing is crucial to ensure stability and reliability. He highlighted the improved testing process with automated tools and a team of dedicated testers. Wladimir called for more developers, particularly those experienced in software testing, to contribute to the testing effort. He encouraged interested developers to reach out to the Bitcoin Core team and get involved. Overall, Wladimir's message emphasized the collaborative nature of open-source software development and the importance of testing in Bitcoin Core's development.To learn more about the disclosed denial of service vulnerabilities and the recommended upgrade to version 0.10.2, refer to the SourceForge link provided. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-t-temporary.xml b/static/bitcoin-dev/July_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-t-temporary.xml index 69f7058eec..96958cfb63 100644 --- a/static/bitcoin-dev/July_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-t-temporary.xml +++ b/static/bitcoin-dev/July_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-t-temporary.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why Satoshi's temporary anti-spam measure isn't temporary - 2023-08-01T14:38:19.363336+00:00 + 2025-10-11T22:01:54.932821+00:00 + python-feedgen Pieter Wuille 2015-08-01 21:05:10+00:00 @@ -179,13 +180,13 @@ - python-feedgen + 2 Combined summary - Why Satoshi's temporary anti-spam measure isn't temporary - 2023-08-01T14:38:19.365396+00:00 + 2025-10-11T22:01:54.933029+00:00 - The context provided encompasses several discussions and debates within the Bitcoin community. One such debate revolves around the block size limit and its impact on scalability, decentralization, and security. Mark Friedenbach proposed a solution for scaling Bitcoin through distribution with minimal trust, while Thomas Zander emphasized prioritizing security and decentralization over scalability. The conversation highlights the ongoing trade-offs between these factors.Another discussion focuses on the importance of avoiding controversial hard forks when making changes to Bitcoin. Milly Bitcoin suggested a process that includes metrics, risk analysis, mitigation strategies, goals, and roadmaps to measure proposed changes against the baseline system. Jorge Timón agreed with this approach, emphasizing the use of metrics and simulations. The conversation emphasizes the need for a systematic and data-driven approach to decision-making in the Bitcoin ecosystem.Scalability is a complex issue, with differing opinions on timing and approach. Pieter Wuille suggested waiting for Blockstream Elements to be ready before implementing a hard fork, while Gavin Andresen advocated for immediate implementation to set a precedent. They also discussed alternatives such as the Lightning Network and older payment channel designs. The conversation reflects the varying perspectives within the community.The inclusion of smart contracts and off-chain systems into Bitcoin was also debated. Gregory Maxwell and Satoshi Nakamoto discussed the feasibility of incorporating a full domain-registry database on the blockchain and the potential risks to decentralization. The conversation highlighted the need to carefully consider trade-offs between functionality and scalability.The resource requirements of running a full node were also discussed. Eric Lombrozo suggested that users who benefit from the network should contribute to its maintenance by running full nodes. However, others argued that it is not feasible for every user due to resource constraints.There are various perspectives on the trade-off between decentralization, scalability, and security. Some developers believe that increasing block size compromises decentralization, while others raise concerns about the hidden costs and security risks associated with larger blocks. The challenge lies in finding a balance that allows for scalability without compromising core principles.The importance of the original vision of Bitcoin and Satoshi Nakamoto's intentions were also debated. The increasing cost of mining and the potential ramifications for the system were discussed, as well as the need to protect decentralization and maintain Bitcoin's competitive advantages beyond just payments. The community faces challenges in balancing scalability, decentralization, and security.Another discussion focused on transaction fees, SPV wallets, the block size limit, and protocol upgrades. The author argues that transaction fees should not exceed what competitors charge, and SPV wallets are widely used and effective at detecting network forks. The conversation also explores the history and purpose of the one megabyte block size limit and the importance of validators and transaction fees.The lack of progress in addressing existing problems within the Bitcoin community was also raised. Concerns were expressed about the motivation for experts to spend time developing and testing code when it does not directly benefit them. The importance of proactively addressing technical issues to prevent larger problems was emphasized.Overall, the context provides insights into the ongoing debates and concerns within the Bitcoin community regarding block size increase, scalability, decentralization, and the decision-making process for making changes to the Bitcoin ecosystem. It highlights the complexity of these issues and the need for careful consideration of trade-offs and potential risks. 2015-08-01T21:05:10+00:00 + The context provided encompasses several discussions and debates within the Bitcoin community. One such debate revolves around the block size limit and its impact on scalability, decentralization, and security. Mark Friedenbach proposed a solution for scaling Bitcoin through distribution with minimal trust, while Thomas Zander emphasized prioritizing security and decentralization over scalability. The conversation highlights the ongoing trade-offs between these factors.Another discussion focuses on the importance of avoiding controversial hard forks when making changes to Bitcoin. Milly Bitcoin suggested a process that includes metrics, risk analysis, mitigation strategies, goals, and roadmaps to measure proposed changes against the baseline system. Jorge Timón agreed with this approach, emphasizing the use of metrics and simulations. The conversation emphasizes the need for a systematic and data-driven approach to decision-making in the Bitcoin ecosystem.Scalability is a complex issue, with differing opinions on timing and approach. Pieter Wuille suggested waiting for Blockstream Elements to be ready before implementing a hard fork, while Gavin Andresen advocated for immediate implementation to set a precedent. They also discussed alternatives such as the Lightning Network and older payment channel designs. The conversation reflects the varying perspectives within the community.The inclusion of smart contracts and off-chain systems into Bitcoin was also debated. Gregory Maxwell and Satoshi Nakamoto discussed the feasibility of incorporating a full domain-registry database on the blockchain and the potential risks to decentralization. The conversation highlighted the need to carefully consider trade-offs between functionality and scalability.The resource requirements of running a full node were also discussed. Eric Lombrozo suggested that users who benefit from the network should contribute to its maintenance by running full nodes. However, others argued that it is not feasible for every user due to resource constraints.There are various perspectives on the trade-off between decentralization, scalability, and security. Some developers believe that increasing block size compromises decentralization, while others raise concerns about the hidden costs and security risks associated with larger blocks. The challenge lies in finding a balance that allows for scalability without compromising core principles.The importance of the original vision of Bitcoin and Satoshi Nakamoto's intentions were also debated. The increasing cost of mining and the potential ramifications for the system were discussed, as well as the need to protect decentralization and maintain Bitcoin's competitive advantages beyond just payments. The community faces challenges in balancing scalability, decentralization, and security.Another discussion focused on transaction fees, SPV wallets, the block size limit, and protocol upgrades. The author argues that transaction fees should not exceed what competitors charge, and SPV wallets are widely used and effective at detecting network forks. The conversation also explores the history and purpose of the one megabyte block size limit and the importance of validators and transaction fees.The lack of progress in addressing existing problems within the Bitcoin community was also raised. Concerns were expressed about the motivation for experts to spend time developing and testing code when it does not directly benefit them. The importance of proactively addressing technical issues to prevent larger problems was emphasized.Overall, the context provides insights into the ongoing debates and concerns within the Bitcoin community regarding block size increase, scalability, decentralization, and the decision-making process for making changes to the Bitcoin ecosystem. It highlights the complexity of these issues and the need for careful consideration of trade-offs and potential risks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-ttemporary.xml b/static/bitcoin-dev/July_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-ttemporary.xml index 8f0b0ada2d..b81a69886a 100644 --- a/static/bitcoin-dev/July_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-ttemporary.xml +++ b/static/bitcoin-dev/July_2015/combined_Why-Satoshi-s-temporary-anti-spam-measure-isn-ttemporary.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why Satoshi's temporary anti-spam measure isn'ttemporary - 2023-08-01T14:41:51.393823+00:00 + 2025-10-11T22:00:57.539271+00:00 + python-feedgen Bryan Bishop 2015-07-31 15:27:45+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Why Satoshi's temporary anti-spam measure isn'ttemporary - 2023-08-01T14:41:51.394820+00:00 + 2025-10-11T22:00:57.539470+00:00 - In July 2015, the bitcoin-dev mailing list saw a discussion regarding decentralized systems and their transaction costs and scarcity. Gavin Andresen challenged the idea that decentralized systems inherently have high transaction costs, while Bryan Bishop argued that high transaction costs and scarcity are inherent in any decentralized system. The conversation also touched on internet architecture and the need for better architecture.Mark Friedenbach proposed that a decentralized system like bitcoin can scale through distribution but requires changes to Bitcoin consensus rules. Thomas Zander suggested a solution where miners use a CPU in a well-connected data center and connect to it over RPC to get a "block 000f00" accepted signal. Zander concluded that innovation for making things better for miners should be done in miner-specific software.The email thread from Thomas Zander discussed the potential for decentralized technology to follow a similar path to multi-core CPUs. He compared the initial skepticism towards multi-core CPUs to the current skepticism towards decentralized technology. He noted that libraries and approaches for distributed systems can also be useful for decentralized systems.Gavin Andresen mentioned several successful decentralized systems, including Git and Google's search system, in a discussion about decentralized systems. He explored why the internet succeeded over more efficient centralized systems. Thomas Zander questioned whether Bitcoin would be outcompeted and replaced due to high transaction costs, and Bryan Bishop argued that decentralized systems will always have high transaction costs but also offer replication, redundancy, and cheap expansion of capacity.Gavin Andresen argued that successful decentralized systems like the internet prove that high transaction costs and scarcity are not inherent in decentralized systems. He also questioned the level of decentralization of the internet and its technology. Jorge Timón argued that even if the Lightning Network was never developed, fees in Bitcoin would still be competitive with non-decentralized payment systems.In another email thread, Bryan Bishop stated that any decentralized system will inherently have high transaction costs and scarcity. The email thread dated July 30, 2015, discussed Bitcoin's protocol functions and the implications of scalability and speed. It was agreed that Bitcoin should scale while maintaining decentralization. The addition of "layer 2" protocols like Lightning will allow fast, low-fee bitcoin transactions within two years.The conversation between members of the bitcoin-dev mailing list addressed various aspects of Bitcoin's future, including its role as a high-value settlement network, transaction fees, and the potential for Bitcoin to be outcompeted. There were disagreements on the impact of high transaction fees and the importance of decentralization.Adam Back, Venzen Khaosan, and Raystonn engaged in a recent email thread discussing the future of Bitcoin and its competition with other blockchains. Adam Back argued that Bitcoin's high level of security and the lack of expertise required to maintain it make it difficult for alternative blockchains to compete. Raystonn countered by stating that economic policy will be the distinguishing factor for alternative blockchains, and cheaper fees are essential to attract users towards Bitcoin. Venzen Khaosan questioned the statement about "liquidity moves to the location of least friction" and asked for a reference to modern economic study.The discussion also touched upon the topic of larger blocks potentially hurting decentralization. A server administrator or systems engineer who has been involved with Bitcoin since 2010 argued against this concern. They concluded that small devices can easily run Bitcoin nodes with larger blocks, with minimal operational costs.Gregory Maxwell addressed various points about Bitcoin's future, emphasizing that Bitcoin is more than just a payment system. He listed its attributes, including sound money, censorship resistance, personal control over money, and programmable money. Maxwell also discussed the potential impact of artificially high transaction fees on the Bitcoin network and the issue of alternative blockchains leeching some of Bitcoin's value. He suggested addressing these concerns through focused solutions rather than ignoring them completely.Lastly, Mike Hearn criticized Eric Lombrozo's article on settling the block size debate, disagreeing with the assumption that users are buying space in Bitcoin blocks. He proposed secure hardware attestation as a solution for double spends and called for more focus on upgrading existing wallets.Overall, the discussions revolved around the scalability, decentralization, and transaction costs of Bitcoin, with participants offering different perspectives and proposing various solutions. 2015-07-31T15:27:45+00:00 + In July 2015, the bitcoin-dev mailing list saw a discussion regarding decentralized systems and their transaction costs and scarcity. Gavin Andresen challenged the idea that decentralized systems inherently have high transaction costs, while Bryan Bishop argued that high transaction costs and scarcity are inherent in any decentralized system. The conversation also touched on internet architecture and the need for better architecture.Mark Friedenbach proposed that a decentralized system like bitcoin can scale through distribution but requires changes to Bitcoin consensus rules. Thomas Zander suggested a solution where miners use a CPU in a well-connected data center and connect to it over RPC to get a "block 000f00" accepted signal. Zander concluded that innovation for making things better for miners should be done in miner-specific software.The email thread from Thomas Zander discussed the potential for decentralized technology to follow a similar path to multi-core CPUs. He compared the initial skepticism towards multi-core CPUs to the current skepticism towards decentralized technology. He noted that libraries and approaches for distributed systems can also be useful for decentralized systems.Gavin Andresen mentioned several successful decentralized systems, including Git and Google's search system, in a discussion about decentralized systems. He explored why the internet succeeded over more efficient centralized systems. Thomas Zander questioned whether Bitcoin would be outcompeted and replaced due to high transaction costs, and Bryan Bishop argued that decentralized systems will always have high transaction costs but also offer replication, redundancy, and cheap expansion of capacity.Gavin Andresen argued that successful decentralized systems like the internet prove that high transaction costs and scarcity are not inherent in decentralized systems. He also questioned the level of decentralization of the internet and its technology. Jorge Timón argued that even if the Lightning Network was never developed, fees in Bitcoin would still be competitive with non-decentralized payment systems.In another email thread, Bryan Bishop stated that any decentralized system will inherently have high transaction costs and scarcity. The email thread dated July 30, 2015, discussed Bitcoin's protocol functions and the implications of scalability and speed. It was agreed that Bitcoin should scale while maintaining decentralization. The addition of "layer 2" protocols like Lightning will allow fast, low-fee bitcoin transactions within two years.The conversation between members of the bitcoin-dev mailing list addressed various aspects of Bitcoin's future, including its role as a high-value settlement network, transaction fees, and the potential for Bitcoin to be outcompeted. There were disagreements on the impact of high transaction fees and the importance of decentralization.Adam Back, Venzen Khaosan, and Raystonn engaged in a recent email thread discussing the future of Bitcoin and its competition with other blockchains. Adam Back argued that Bitcoin's high level of security and the lack of expertise required to maintain it make it difficult for alternative blockchains to compete. Raystonn countered by stating that economic policy will be the distinguishing factor for alternative blockchains, and cheaper fees are essential to attract users towards Bitcoin. Venzen Khaosan questioned the statement about "liquidity moves to the location of least friction" and asked for a reference to modern economic study.The discussion also touched upon the topic of larger blocks potentially hurting decentralization. A server administrator or systems engineer who has been involved with Bitcoin since 2010 argued against this concern. They concluded that small devices can easily run Bitcoin nodes with larger blocks, with minimal operational costs.Gregory Maxwell addressed various points about Bitcoin's future, emphasizing that Bitcoin is more than just a payment system. He listed its attributes, including sound money, censorship resistance, personal control over money, and programmable money. Maxwell also discussed the potential impact of artificially high transaction fees on the Bitcoin network and the issue of alternative blockchains leeching some of Bitcoin's value. He suggested addressing these concerns through focused solutions rather than ignoring them completely.Lastly, Mike Hearn criticized Eric Lombrozo's article on settling the block size debate, disagreeing with the assumption that users are buying space in Bitcoin blocks. He proposed secure hardware attestation as a solution for double spends and called for more focus on upgrading existing wallets.Overall, the discussions revolved around the scalability, decentralization, and transaction costs of Bitcoin, with participants offering different perspectives and proposing various solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2015/combined_Why-not-Child-Pays-For-Parent-.xml b/static/bitcoin-dev/July_2015/combined_Why-not-Child-Pays-For-Parent-.xml index bf3346db53..53d4532687 100644 --- a/static/bitcoin-dev/July_2015/combined_Why-not-Child-Pays-For-Parent-.xml +++ b/static/bitcoin-dev/July_2015/combined_Why-not-Child-Pays-For-Parent-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why not Child-Pays-For-Parent? - 2023-08-01T14:15:59.579256+00:00 + 2025-10-11T22:01:16.664086+00:00 + python-feedgen Matt Whitlock 2015-07-12 10:18:47+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Why not Child-Pays-For-Parent? - 2023-08-01T14:15:59.580254+00:00 + 2025-10-11T22:01:16.664306+00:00 - In an attempt to understand the factors affecting transaction confirmation, Richard Moore, the founder of Genetic Mistakes Software Inc., conducted a test. He sent 0.0008 BTC without any fee and included it as an unconfirmed utxo in another transaction with 0.0001 BTC. However, despite this, the transaction has not yet been confirmed.The lack of confirmation could be attributed to various factors. These factors include insufficient hash power, the small amount of the transactions, the newness of the coins being used, an incorrect fee amount, or excessive congestion on the network. It is unclear which specific factor or combination of factors is responsible for the lack of confirmation in this case.The author's test suggests that transaction confirmation may not solely depend on the total size of all transactions or the sum of each individual transaction's required fee. The lack of confirmation even with a small fee indicates that other factors must also play a role. This could include congestion or insufficient hash power for Child Pays For Parent (CPFP).Richard Moore's curiosity about these topics indicates that further exploration and investigation are needed to understand the dynamics of transaction confirmation more comprehensively. 2015-07-12T10:18:47+00:00 + In an attempt to understand the factors affecting transaction confirmation, Richard Moore, the founder of Genetic Mistakes Software Inc., conducted a test. He sent 0.0008 BTC without any fee and included it as an unconfirmed utxo in another transaction with 0.0001 BTC. However, despite this, the transaction has not yet been confirmed.The lack of confirmation could be attributed to various factors. These factors include insufficient hash power, the small amount of the transactions, the newness of the coins being used, an incorrect fee amount, or excessive congestion on the network. It is unclear which specific factor or combination of factors is responsible for the lack of confirmation in this case.The author's test suggests that transaction confirmation may not solely depend on the total size of all transactions or the sum of each individual transaction's required fee. The lack of confirmation even with a small fee indicates that other factors must also play a role. This could include congestion or insufficient hash power for Child Pays For Parent (CPFP).Richard Moore's curiosity about these topics indicates that further exploration and investigation are needed to understand the dynamics of transaction confirmation more comprehensively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/July_2016/combined_BIP-151-use-of-HMAC-SHA512.xml b/static/bitcoin-dev/July_2016/combined_BIP-151-use-of-HMAC-SHA512.xml index 52811cc2d0..cb8b7c65a0 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-151-use-of-HMAC-SHA512.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-151-use-of-HMAC-SHA512.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 151 use of HMAC_SHA512 - 2025-09-26T15:29:19.342056+00:00 + 2025-10-11T21:30:46.329710+00:00 python-feedgen Jonas Schnelli 2016-07-04 06:47:05+00:00 @@ -77,10 +77,11 @@ + 2 Combined summary - BIP 151 use of HMAC_SHA512 - 2025-09-26T15:29:19.342244+00:00 + 2025-10-11T21:30:46.329868+00:00 2016-07-04T06:47:05+00:00 Zooko Wilcox, in a discussion on the bitcoin-dev mailing list, suggests using the well-studied open standard of HKDF (HMAC-based Extract-and-Expand Key Derivation Function) instead of re-inventing it. He emphasizes the importance of using open standards in cryptography to reduce the risk of errors. Arthur Chen agrees with this recommendation and highlights the significance of following well-studied open standards in the realm of cryptocurrency.The discussion also touches upon the use of HMAC vs SHA256 for a Message Authentication Code (MAC). It is explained that SHA256 is insecure for a MAC due to its length extension property. Even though SHA256 appends the bitlength, making it more difficult to generate a new value, it is not being used as a MAC in BIP151. Arthur Chen explains the proven security properties of HMAC, even when the underlying crypto hashing function has weaknesses. He emphasizes the importance of using HMAC for MACs rather than custom constructions.There is a debate about using SHA512_HMAC instead of SHA256_HMAC for key derivation. Jonas Schnelli suggests using SHA512_HMAC, citing its usage in BIP32 and its cost-effectiveness compared to two SHA256_HMAC operations. However, Rusty Russell argues that introducing another hash algorithm would be unnecessarily painful and questions the use of HMAC over just SHA256. The discussion concludes without clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In another discussion, the importance of including the cipher-type in the symmetric cipher key is emphasized to avoid weak-cipher attacks. It is noted that although BIP151 currently specifies chacha20-poly1305 at openssh.com, it is possible for someone to add another symmetric cipher type after deployment which may have weaker security properties. Therefore, the inclusion of the ciphersuite-type in the key derivation HMAC is crucial to prevent potential attacks.Based on previous crypto analysis, it is stated that the security of SHA512 is not significantly higher than SHA256. There have been discussions about considering SHA3 as a potential alternative. However, there are no clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In summary, the context revolves around the importance of using well-studied open standards in cryptography. It emphasizes the use of HKDF instead of reinventing it and the utilization of HMAC for MACs to ensure security. There are debates regarding the use of SHA512_HMAC vs SHA256_HMAC for key derivation, with different perspectives provided. The inclusion of the cipher-type in the symmetric cipher key is highlighted to avoid weak-cipher attacks. Overall, the discussions aim to enhance the security and reliability of cryptographic systems in the realm of cryptocurrency. diff --git a/static/bitcoin-dev/July_2016/combined_BIP-151.xml b/static/bitcoin-dev/July_2016/combined_BIP-151.xml index 62b711ad57..25049efb33 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-151.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-151.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 151 - 2025-09-26T15:29:17.227063+00:00 + 2025-10-11T21:30:44.205396+00:00 python-feedgen Pieter Wuille 2016-08-31 14:29:53+00:00 @@ -169,10 +169,11 @@ + 2 Combined summary - BIP 151 - 2025-09-26T15:29:17.227293+00:00 + 2025-10-11T21:30:44.205630+00:00 2016-08-31T14:29:53+00:00 In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. diff --git a/static/bitcoin-dev/July_2016/combined_BIP-Number-Request-Open-Asset.xml b/static/bitcoin-dev/July_2016/combined_BIP-Number-Request-Open-Asset.xml index 085e800499..db129d9eb6 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-Number-Request-Open-Asset.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-Number-Request-Open-Asset.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Number Request: Open Asset - 2025-09-26T15:29:21.455432+00:00 + 2025-10-11T21:30:48.453519+00:00 python-feedgen Nicolas Dorier 2016-08-13 02:25:04+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - BIP Number Request: Open Asset - 2025-09-26T15:29:21.455637+00:00 + 2025-10-11T21:30:48.453684+00:00 2016-08-13T02:25:04+00:00 The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it diff --git a/static/bitcoin-dev/July_2016/combined_BIP-draft-HTLC-transactions.xml b/static/bitcoin-dev/July_2016/combined_BIP-draft-HTLC-transactions.xml index 267a826556..635c1f6b38 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-draft-HTLC-transactions.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-draft-HTLC-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP draft: HTLC transactions - 2025-09-26T15:29:25.717578+00:00 + 2025-10-11T21:30:52.700290+00:00 python-feedgen Johnson Lau 2016-08-17 10:00:37+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - BIP draft: HTLC transactions - 2025-09-26T15:29:25.717735+00:00 + 2025-10-11T21:30:52.700487+00:00 2016-08-17T10:00:37+00:00 On July 20, 2016, a discussion took place on the bitcoin-dev mailing list regarding Hash Time-Locked Contract (HTLC) transactions in Bitcoin. Sean Bowe requested feedback on these transactions which allow payment for the preimage of a hash, with CSV/CLTV used to recover funds if the other party is uncooperative. Luke Dashjr proposed using OP_SIZE to address the malleability issue caused by hashing the top item on the stack, and Peter Todd praised this idea.The HTLC scripts have a specific structure, starting with [HASHOP] OP_EQUAL followed by an OP_IF and an OP_ELSE, with a [TIMEOUTOP] OP_DROP in between. The script concludes with an OP_CHECKSIG. However, this design makes the scripts malleable as the top stack item can be modified without invalidating the scriptSig. Todd suggests using the OP_SIZE opcode to make it more difficult for attackers to manipulate transactions. This additional requirement involves adding OP_SIZE OP_2 OP_PICK OP_HASH160 [PUBKEYHASH] OP_EQUALVERIFY to the script.Todd also emphasizes the importance of considering different scenarios, such as malicious parties attempting double-spend attacks. The discussion delves into the vulnerabilities of HTLC transactions and provides suggestions for enhancing their security.In addition to the discussion, Sean Bowe shares his draft BIP for HTLC transactions on GitHub. Members of the community express interest in submitting a BIP to support these transactions in wallets with modifications to Bitcoin Core. An implementation of Bowe's draft BIP is currently under development. The HTLC scripts are seen as valuable for applications like the Lightning network and zero-knowledge contingent payments, as demonstrated by the author's 'pay-to-sudoku' ZKCP demo earlier in the year, which utilized the same script implemented with CLTV and SHA256. diff --git a/static/bitcoin-dev/July_2016/combined_BIP-proposal-derived-mnemonics.xml b/static/bitcoin-dev/July_2016/combined_BIP-proposal-derived-mnemonics.xml index 954a3e7ea6..c334203c7d 100644 --- a/static/bitcoin-dev/July_2016/combined_BIP-proposal-derived-mnemonics.xml +++ b/static/bitcoin-dev/July_2016/combined_BIP-proposal-derived-mnemonics.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP proposal: derived mnemonics - 2025-09-26T15:29:23.577648+00:00 + 2025-10-11T21:30:50.576702+00:00 python-feedgen Gregory Maxwell 2016-07-27 20:59:54+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - BIP proposal: derived mnemonics - 2025-09-26T15:29:23.577778+00:00 + 2025-10-11T21:30:50.576843+00:00 2016-07-27T20:59:54+00:00 In a bitcoin-dev discussion, concerns were raised about the security of Bip39's use of PBKDF2 with 2048 iterations to protect large amounts of funds. Alternative methods of protection were proposed, including the use of a scheme that supports delegatable hardening or eschewing pretextual 'hardening'. However, these alternatives were rejected by the authors of the Bip39 spec. It was pointed out that Bip39 is not a brainwallet solely protected by the passphrase. The Digital Bitbox team uses PBKDF2 with over 20,000 iterations on the computer and an additional 2048 rounds on-chip to secure user-entered passphrases for their hardware wallet. Adding two random lowercase letters to the passphrase can increase security, but relying solely on a strong passphrase is not recommended. It is important to choose a good passphrase and take measures to ensure the seed is not stolen.Jonas Schnelli expressed concerns over the use of PBKDF2 with 2048 iterations in Bip39, suggesting it is not sufficient to protect large amounts of funds. He questioned alternative methods, such as using an expensive processor and memory in every hardware wallet or waiting ten minutes after entering a passphrase with a million iterations. The idea of adding two random lowercase letters to a passphrase with 2048 iterations was considered to potentially provide better protection. Schnelli advised users to choose a good passphrase or ensure their seed is not stolen.The article explains how a master mnemonic is generated from a standard mnemonic according to BIP39. A new string is created using Count and Strength, where Count represents different derived mnemonics of a given strength, and Strength is calculated based on the desired number of words for the derived mnemonic. The string is then hashed using sha512. The author suggests using sha512_hmac with a passphrase and salt instead of a checksum based on a predetermined wordlist, highlighting security downsides. An alternative idea of deriving a child key after bip32 and using the derived 256bits to encode the mnemonic is proposed. Concerns are raised about users only storing and backing up the bip39 mnemonic, as reconstructing funds from a seed can be difficult without access to a trusted TX-indexed full node. Novice users might underestimate the risk of losing metadata coupled with their transactions when they only store the wallet seed.The author has submitted a draft BIP proposal for derived mnemonics from a master mnemonic, aiming to make it easier to split funds into smaller fractions and use them in an HD-wallet without putting the master mnemonic at risk on an online computer. The master mnemonic is generated offline, and multiple derived mnemonics are generated deterministically offline for online use. The proposed method uses sha512 hashing to generate byte arrays to create new mnemonics. A reference implementation for a 24-word master mnemonic based on BIP44 is available on the provided website. Use cases include splitting funds into fractions, sending them to multiple addresses, giving derived mnemonics to family members with bitcoin, and memorizing only a 12-word seed. diff --git a/static/bitcoin-dev/July_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml b/static/bitcoin-dev/July_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml index c372eb9203..4c3e29e581 100644 --- a/static/bitcoin-dev/July_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml +++ b/static/bitcoin-dev/July_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml @@ -2,7 +2,7 @@ 2 Combined summary - Code Review: The Consensus Critical Parts of Segwit by Peter Todd - 2025-09-26T15:29:13.004076+00:00 + 2025-10-11T21:30:39.956716+00:00 python-feedgen Peter Todd 2016-07-04 23:27:15+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Code Review: The Consensus Critical Parts of Segwit by Peter Todd - 2025-09-26T15:29:13.004231+00:00 + 2025-10-11T21:30:39.956841+00:00 2016-07-04T23:27:15+00:00 In a discussion about the implementation of Segregated Witness (SegWit) on the Bitcoin network, one issue raised is the odd result that occurs when a transaction spends a witness output with an unknown version. Surprisingly, this transaction is valid even if it doesn't have any witnesses. One suggestion is to leave these unknown witness programs as any-one-can-spend without looking at the witness. However, this creates a special case in the code, allowing spending of a witness output without a witness.There is a debate about whether to allow the use of 160-bit commitments for multisig transactions, which may require 256-bit security. The argument is that using shorter hash and pubkey for storing a small amount of Bitcoin could save bytes. However, concerns are raised about potential hash collisions and the reuse of signatures for different signature hashes. To address this, tagged hashing is proposed as a way to ensure that signatures cannot be reused in different contexts. XORing the magic tag prior to its use is suggested as sufficient for signature applications.Unfortunately, this method is not compatible with timestamping schemes like OpenTimestamps, which rely on all operations being cryptographically secure. Another concern is the difficulty of adding new commitments with soft forks. It is pointed out that anything after 38 bytes in the reserve value of a 32-byte hash has no consensus meaning, making it inefficient to add new commitments with softforks.In an email exchange between Johnson Lau and Bitcoin developer Peter Todd, various issues related to SegWit implementation are discussed. They discuss the possibility of allowing users to choose a less secure 160-bit commitment if their use-case doesn't require the full 256-bit security level. Additionally, the maximum size of serialized witness scripts is debated, with the constraint being set at 520 bytes. Lastly, there is a mention of concern about hash collision, although it is unclear how it could be possible.Overall, the discussion revolves around the complexities and potential vulnerabilities of implementing Segregated Witness on the Bitcoin network, with various suggestions and concerns being raised by different participants. The goal is to find solutions that ensure the security and efficiency of transactions while avoiding any potential issues or conflicts. diff --git a/static/bitcoin-dev/July_2016/combined_Holdup-on-Block-Alerts-Fraud-Proofs-.xml b/static/bitcoin-dev/July_2016/combined_Holdup-on-Block-Alerts-Fraud-Proofs-.xml index 75814e5aad..58caa9a923 100644 --- a/static/bitcoin-dev/July_2016/combined_Holdup-on-Block-Alerts-Fraud-Proofs-.xml +++ b/static/bitcoin-dev/July_2016/combined_Holdup-on-Block-Alerts-Fraud-Proofs-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Holdup on Block Alerts / Fraud Proofs ? - 2025-09-26T15:29:06.669531+00:00 + 2025-10-11T21:30:33.581511+00:00 python-feedgen Luke Dashjr 2016-07-31 05:18:18+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Holdup on Block Alerts / Fraud Proofs ? - 2025-09-26T15:29:06.669690+00:00 + 2025-10-11T21:30:33.581669+00:00 2016-07-31T05:18:18+00:00 In a Bitcoin developers' mailing list discussion, Paul Sztorc proposed the implementation of "alerts" to address the problem of transactions referencing block content on a "pretender block." However, there is still an issue with constructing a block that cannot be proven invalid. While it is possible to prove the invalidity of a transaction within a well-formed block, there is no way to prove that a block is not well-formed. This could result in a valid block with some transactions being withheld until it becomes stale, making it impossible for full nodes and miners to accept it without knowing all the transactions in the block.The proposed solution to this problem is for users to demand the full block from attackers. However, this opens up the possibility of attackers launching denial-of-service attacks by providing bogus incomplete-block claims. This is particularly problematic for users who rely on Simplified Payment Verification (SPV) and do not have the bandwidth to run a full node.In another discussion on the bitcoin-dev mailing list, Paul Sztorc expressed confusion about how segwit (Segregated Witness) would help in this context. Another member of the community, Bryan, shared a link to discussions on the topic that took place on the bitcoin-core-dev chat channel in December 2015. Although the link is currently unavailable, it may have contained useful information regarding the potential benefits of segwit.The idea of incentivizing users to provide proof of invalid block content dates back to Satoshi's whitepaper. This concept would be particularly valuable for Alice, who is running an SPV client. Paul Sztorc suggests that implementing "alerts" would be relatively straightforward and offers details on how this could be achieved using a new OP code. He also acknowledges that implementing "fraud proofs" (as they are now called) would require significant engineering work and asks if anyone can direct him to the problems associated with this approach.Sztorc outlines a proposed solution involving the creation of an OP Code called "OP FraudProof." This OP Code would include arguments such as a block number, block header, and merkle path from the header to an invalid transaction. In practice, this OP Code can be used in a transaction where Alice provides 1 BTC and X provides 0.2 BTC. If X signs the transaction, Alice assumes the block is invalid and stops offering to buy fraud proofs for it. If X does not sign, Alice gets her money back plus 0.2 BTC from Eric for wasting her time. Sztorc notes that the definition of an "invalid transaction" could refer to either a script that fails or a double-spend.While acknowledging that implementing this solution is not a simple task, Sztorc does not consider it to be a significant engineering overhaul. He also mentions that segwit may have a role in supporting this solution, although he does not fully understand why. diff --git a/static/bitcoin-dev/July_2016/combined_Merkle-trees-and-mountain-ranges.xml b/static/bitcoin-dev/July_2016/combined_Merkle-trees-and-mountain-ranges.xml index caffb7a7f4..a923498b55 100644 --- a/static/bitcoin-dev/July_2016/combined_Merkle-trees-and-mountain-ranges.xml +++ b/static/bitcoin-dev/July_2016/combined_Merkle-trees-and-mountain-ranges.xml @@ -2,7 +2,7 @@ 2 Combined summary - Merkle trees and mountain ranges - 2025-09-26T15:29:08.782381+00:00 + 2025-10-11T21:30:35.704898+00:00 python-feedgen Bram Cohen 2016-07-15 23:00:57+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Merkle trees and mountain ranges - 2025-09-26T15:29:08.782581+00:00 + 2025-10-11T21:30:35.705073+00:00 2016-07-15T23:00:57+00:00 In an email exchange between Peter Todd and Bram Cohen, the topic of discussion revolves around various aspects of UTXO commitments, merkle trees, and optimizations. Todd suggests using BLAKE2b for internal hashing due to its efficiency in omitting padding when the data is exactly one block in size. The implementation of a root branch block with nodes arranged in fixed positions and terminals having outpointers to other blocks is also discussed. The conversation also delves into the efficiency of their implementation when stored on a spinning hard drive. It is estimated that even an underpowered node could keep up with the blockchain if it is full of simple transactions. Validating an entire blockchain history might take a few days, but if some layers are kept in regular memory, validating a whole year of history might only take a few hours. The complexity of the MMR proposal's data structures is acknowledged, and it is suggested that specifying storage media and latency expectations would clarify the reasoning significantly.Cohen considers committing to the prefix as a way of handling cases where multiple keys share parts of the same prefix, but concludes that it would only save about 10% of memory in his implementation. Todd explains that committing to the prefix is a simple but possibly not-optimal way of committing to what data should be accessible under a given node. They discuss the depths of merkbiner trees in proportion to log2(n) against attackers who are choosing keys by grinding hashes. The optimization of hashing time is also explored, with the mention of the efficiency of BLAKE2 compared to SHA256.The conversation then moves on to the implementation of merkle trees and how each node contains metadata byte followed by fixed-size secure hashes and pointers to the children. The structure of branch blocks, terminals, and leaf blocks is explained, along with the overflow mechanism when a leaf block exceeds its capacity. The idea of achieving practical Bitcoin updates with minimal cache misses is discussed, with Cohen explaining the clever placement of nodes in memory to minimize cache misses.Another aspect of the conversation revolves around adding latency to UTXO commitments. It is agreed that adding latency can work in principle but should only be used as a last resort technique when optimization fails. The addition of roots of what's added and deleted in each block allows for proofs of inclusion and exclusion without significant latency. However, it adds complexity and should only be done when necessary for fast validation before block propagation.The discussion also touches upon the indexing of the UTXO set, the possibility of introducing incentives for collecting dust, and the use of variable-sized commitments instead of hash digests for improved efficiency. There is a debate about whether validation before block propagation needs to be done at all, with Todd suggesting that it's reasonable to propagate blocks that have not been fully validated beyond checking PoW. The importance of minimizing the time it takes miners to start mining the next block and collecting fees is emphasized.There are additional conversations discussing the technicalities of TXO commitments, the differences between merkle trees and patricia tries, and the performance and optimization considerations of implementing UTXO, STXO, and TXO commitments. The use of mountain ranges for merkle trees is debated, with suggestions for alternative approaches such as raw merkle trees.In conclusion, the email exchanges provide detailed insights into the discussions surrounding UTXO commitments, merkle trees, optimizations, latency issues, and various implementation considerations within the Bitcoin community. The conversations highlight the complexities and trade-offs involved in designing efficient and secure blockchain data structures. diff --git a/static/bitcoin-dev/July_2016/combined_Reasons-to-add-sync-flags-to-Bitcoin.xml b/static/bitcoin-dev/July_2016/combined_Reasons-to-add-sync-flags-to-Bitcoin.xml index d0d23e1e1b..cac29c3bce 100644 --- a/static/bitcoin-dev/July_2016/combined_Reasons-to-add-sync-flags-to-Bitcoin.xml +++ b/static/bitcoin-dev/July_2016/combined_Reasons-to-add-sync-flags-to-Bitcoin.xml @@ -2,7 +2,7 @@ 2 Combined summary - Reasons to add sync flags to Bitcoin - 2025-09-26T15:29:15.114081+00:00 + 2025-10-11T21:30:42.079139+00:00 python-feedgen Moral Agent 2016-07-28 16:41:48+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - Reasons to add sync flags to Bitcoin - 2025-09-26T15:29:15.114214+00:00 + 2025-10-11T21:30:42.079311+00:00 2016-07-28T16:41:48+00:00 A proposed strategy to mitigate the impact of a block-with-valid-header-but-invalid-transactions-spam-attack involves the use of sync flags. The key aspect of this strategy is relaxing the requirement for a flag to commit to a completely valid block, instead only requiring a valid block header. Miners can start mining a flag as soon as they have a valid block header and can choose to continue or abandon mining the flag if spam is detected. The distribution of hashpower between the flag and mining for a valid block should reflect miners' estimation of the cost of negative outcomes. This approach effectively neutralizes the harm caused by the attack and incorporates the work done to produce the spam into the blockchain's cumulative Proof of Work, without rewarding the spammer.The author of the proposal has created a repository for sync_flags and made some changes to it, which can be found in the repo. The author's main idea is to enhance mining decentralization by having all miners start hashing the next block simultaneously. This synchronization can be achieved through the use of sync flags, which are messages consisting of a hash of the previous block, a bitcoin address, and a nonce. Miners wait for the flag, and when it spreads through the network, they can begin hashing the next block together. To fund this proof of work, the protocol is modified to require that the block produced 10 blocks after the sync flag allocate 25% of the block reward to the address specified by the flag. Sync flags offer several advantages over optimistic mining. They reduce variance in mining profitability, eliminate SPV mined blocks and empty blocks, smooth out resource usage, alleviate the latency bottleneck on throughput, make transaction stuffing by miners either obvious or costly, and give miners a task while waiting for attractive transactions. The author addresses concerns about selfish mining, invalid block spam, payout compatibility with certain mining pools, and the impact of mandatory empty blocks on sync flags. By mining a sync flag instead, the use of Bitcoin miners for destabilizing purposes can be avoided. This approach would put miners to profitable work while they wait and create a more efficient price discovery mechanism for transactions. Transactions with high fees would have time to enter the marketplace, rather than being taken quickly because all the desirable transactions were included in the previous block. Implementing sync flags through a soft fork is feasible, although a hard fork would be more efficient. The proposed implementation requires that every block includes a transaction allocating 25% of the block reward to the address provided by the 10th previous sync flag and commits to the hash of the 1st previous sync flag.Moral Agent proposed a solution to enhance mining decentralization and reduce variance in mining profitability. The idea involves using a sync flag as a message that propagates at maximum speed through the network, triggering all miners to simultaneously start hashing the next block. The sync flag is composed of the hash of the previous block, a Bitcoin address, and a nonce. To ensure the implementation of this idea, the protocol is adjusted to mandate that the block produced 10 blocks after the sync flag allocates 25% of the block reward to the address specified by the flag. This proposal brings various benefits such as eliminating SPV mined blocks and empty blocks, reducing latency bottlenecks, making transaction stuffing costly or obvious, and providing miners with an activity while waiting for attractive transactions. A soft fork can easily implement sync flags. However, the current payout structure of non hot-wallet pools and decentralized pools may not be compatible with mining the sync flag. Instead of specifying an address for funds, including the hash of the transaction allowed to spend the sync flag output could be an alternative.In a bitcoin-dev mailing list discussion, Martijn Meijering questioned whether selfish mining of sync flags would be more likely compared to ordinary blocks. A proposal was suggested to achieve the same result as adding mandatory empty blocks by targeting Proof-of-Work (PoW) at 2 minutes to produce a flag every 2 minutes and a block every 8 minutes. The conversion rate from hashing power to reward would be the same for both flags and blocks. However, a soft fork implementing this rule would divert 20% of its hashing power to flag blocks, which legacy nodes would ignore. To win the race, the soft fork would require 55% of the hashing power. Consequently, headers-first clients would need to download more information to verify the longest chain as they would miss 20% of the PoW if they only downloaded headers.The concept of selfish mining of sync flags is introduced, where miners may selfishly mine flags and withhold them until the benefit gained from withholding is less than the mining reward. This practice could undermine decentralization, favoring only big miners capable of engaging in selfish mining. It may also encourage collusion among miners, resulting in flags being shipped only to miners with established business relationships, thereby reducing flag revenue and providing an advantage to in-group miners in main-chain mining.The idea of using a sync flag to ensure diff --git a/static/bitcoin-dev/July_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml b/static/bitcoin-dev/July_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml index e1f1051cff..e49752043f 100644 --- a/static/bitcoin-dev/July_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml +++ b/static/bitcoin-dev/July_2016/combined_Status-updates-for-BIP-9-68-112-and-113.xml @@ -2,7 +2,7 @@ 2 Combined summary - Status updates for BIP 9, 68, 112, and 113 - 2025-09-26T15:29:10.893300+00:00 + 2025-10-11T21:30:37.834557+00:00 python-feedgen Btc Drak 2016-08-18 23:05:59+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Status updates for BIP 9, 68, 112, and 113 - 2025-09-26T15:29:10.893475+00:00 + 2025-10-11T21:30:37.834702+00:00 2016-08-18T23:05:59+00:00 Luke Dashjr, a Bitcoin Core developer, has announced his plans to update the status of BIPs 9, 68, 112, and 113 to Final in one month. Previously, there was confusion surrounding the classification of BIP 9, as it was unclear whether it fell under the Draft/Accepted/Final or Draft/Active classification. However, Dashjr believes that since BIPs 68, 112, and 113 have already been successfully deployed, BIP 9 should now be considered an informational BIP falling under the Draft/Accepted/Final class. In order to proceed with this update, Dashjr requires at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage.The discussion surrounding BIP 9 centers around its classification as just an "Informational" BIP, despite its importance in the consensus logic. Luke Jr. argues that BIP 9 is merely informational in advising how other BIPs should deploy themselves, making it a grey area. Wladimir J. van der Laan raises concerns over such an important deployment mechanism being classified solely as an informational BIP. However, none of the authors have commented on changing the type of BIP 9, even after a month of discussion. Thus, Luke asks if anyone objects to him updating BIP 9 to Final status.Dashjr suggests that BIP 9 should be reclassified as a "Standard BIP" rather than just an informational one, as it is included as part of the BIP 68 standard. He further explains that any modifications to BIP 9 would likely require a new BIP, and soft-forks utilizing the new standard would refer to the new BIP number. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be considered as part of the Draft/Accepted/Final classification. Additionally, he highlights that BIPs 68, 112, and 113 have already been successfully deployed to the network, satisfying the requirements for both Accepted and Final status. Consequently, Dashjr proposes that all four BIPs (BIPs 9, 68, 112, and 113) should be updated to Final status within one month.To proceed with this update, Dashjr needs at least one author from each BIP to sign-off on promoting them to (and beyond) the Accepted stage. Peter Todd, a developer at Bitcoin, has responded with an ACK in support of the "Final" status. The discussion regarding these updates can be found on the Github BIPs repository. However, it is recommended to continue the discussion via email.In summary, Luke Dashjr plans to update the status of BIPs 9, 68, 112, and 113 to Final within one month. There is a debate surrounding the classification of BIP 9, with Dashjr suggesting it should be considered a "Standard BIP" rather than just informational. He argues that BIP 9 is included as part of the BIP 68 standard and that any modifications would likely require a new BIP. Reviewing the criteria for status changes, Dashjr concludes that BIPs 68, 112, 113, and 141 are implementations of BIP 9 and should be classified under the Draft/Accepted/Final category. To proceed with the updates, Dashjr needs sign-offs from authors of each BIP. The discussion took place on the Github BIPs repository, but further communication is recommended via email. diff --git a/static/bitcoin-dev/July_2017/combined_Drivechain-RfD-Follow-Up.xml b/static/bitcoin-dev/July_2017/combined_Drivechain-RfD-Follow-Up.xml index d6dcc773cd..c463ed443a 100644 --- a/static/bitcoin-dev/July_2017/combined_Drivechain-RfD-Follow-Up.xml +++ b/static/bitcoin-dev/July_2017/combined_Drivechain-RfD-Follow-Up.xml @@ -2,7 +2,7 @@ 2 Combined summary - Drivechain RfD -- Follow Up - 2025-09-26T15:30:29.137273+00:00 + 2025-10-11T21:31:50.154293+00:00 python-feedgen Paul Sztorc 2017-07-13 17:04:01+00:00 @@ -81,10 +81,11 @@ + 2 Combined summary - Drivechain RfD -- Follow Up - 2025-09-26T15:30:29.137485+00:00 + 2025-10-11T21:31:50.154508+00:00 2017-07-13T17:04:01+00:00 The discussion in the provided context revolves around the security and implementation of drivechains, softforks, and P2SH transactions. Hampus Sjöberg argues that for softforks, 100% of nodes and miners need to upgrade to new rules to prevent chain splits, while for drivechains, only interested nodes validate the other chain. Paul Sztorc agrees but points out that even if some percentage of the network is validating both chains in drivechains, there will be no chain split if miners improperly withdraw from a sidechain. However, he expresses concern about the possibility of sidechain theft turning into a campaign.Greg raises concerns about theft in drivechains and discusses two different usages of the word "theft." He also questions whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes. Experts suggest that delayed withdrawal techniques in drivechains can mitigate the threat of theft_2. The email thread further delves into the security of WT^ transactions compared to P2SH and SegWit transactions. The author expresses doubt that the security of WT^ transactions can match that of P2SH and SegWit transactions.The discussion also highlights the different modes of use for drivechains, ranging from not upgrading Bitcoin software to actively using sidechains. It is emphasized that miners cannot steal funds in drivechains due to automatic enforcement policies enforced by full nodes. Another email exchange between Greg Slepak and Paul Sztorc explores the Drivechain project and its comparison with P2SH. The conversation clarifies four different modes of use for drivechains and addresses the issue of theft in drivechains. It is noted that the security of WT^ transactions can be brought up to the same level as P2SH and SegWit transactions.The conversation also touches upon the feasibility of using a proof-of-burn sidechain as an alternative to merged mining for increased security. Erik Aronesty suggests users would tolerate depreciation due to cheap and secure transactions, but Paul Sztorc counters that this scheme would be more expensive and relatively less secure. The discussion also covers the role of UTXO commitments for sidechains and the potential impact on the main chain's incentive structure. The lightning model is mentioned as a way to prevent further centralization.Overall, the email exchanges provide insights into the technical details, security models, and potential implications of drivechains, softforks, and P2SH transactions. The discussions highlight different perspectives on the security and implementation of these concepts, as well as potential challenges and alternative approaches.In addition to the above context, there is a discussion about the concept of a proof-of-burn sidechain, which requires burning Bitcoin or side-chain tokens to mine the side chain. The size of the burn determines the degree of security. Users can have a secure sidechain that issues a mining reward in sidechain tokens, which can be aggregated and redeemed for Bitcoins. However, any Bitcoins held in the sidechain depreciate in value at a rate of X% per year, which pays for increased security. This functions like an altcoin with high inflation and cheap transactions but is pegged to Bitcoin's price due to the pool of unredeemed Bitcoins held within the side chain.Drivechain is another sidechain enabling technology that seeks to plug many blockchains into the main chain, removing the blocksize limit and addressing scalability concerns. However, there are concerns about centralization and user choice of custodians. The discussion also raises questions about the potential impact on user control over their Bitcoins, as well as the correlation between network security and economic value.There is a debate around whether merged mining or proof-of-burn is a better solution for sidechain security. Some argue that proof-of-burn may result in users avoiding the sidechain due to the depreciation of their Bitcoins, while others believe merged mining would be more competitive. UTXO commitments are also suggested as a way to enhance the security of sidechains.The conversation explores various scenarios and considerations related to implementing Drivechain, including miner control, theft, antifragility, and the ecological impact. The participants recognize the need to balance innovation and security, ensuring that any changes made to the Bitcoin network do not compromise its integrity.Overall, the context provides insights into different perspectives on sidechain technologies and their implications for the Bitcoin ecosystem. It highlights the ongoing discussions and debates within the Bitcoin community regarding scalability, security, centralization, and user control.Furthermore, in the provided context, it is mentioned that there is an 8 MB maxblocksize, which doubles every two years. This implies that the maximum block size in a certain system is initially set at 8 MB, and then it will double in size every two years. The doubling of the maxblocksize every two years suggests a potential increase in the system's capacity to handle larger amounts of data. This can be seen as a measure to accommodate the growing demand for storage space and processing power in various applications diff --git a/static/bitcoin-dev/July_2017/combined_UTXO-growth-scaling-solution-proposal.xml b/static/bitcoin-dev/July_2017/combined_UTXO-growth-scaling-solution-proposal.xml index 00473762bc..29db2fd521 100644 --- a/static/bitcoin-dev/July_2017/combined_UTXO-growth-scaling-solution-proposal.xml +++ b/static/bitcoin-dev/July_2017/combined_UTXO-growth-scaling-solution-proposal.xml @@ -2,7 +2,7 @@ 2 Combined summary - UTXO growth scaling solution proposal - 2025-09-26T15:30:37.629051+00:00 + 2025-10-11T21:31:54.409400+00:00 python-feedgen Mark Friedenbach 2017-08-23 03:26:19+00:00 @@ -101,10 +101,11 @@ + 2 Combined summary - UTXO growth scaling solution proposal - 2025-09-26T15:30:37.629241+00:00 + 2025-10-11T21:31:54.409606+00:00 2017-08-23T03:26:19+00:00 Bitcoin developers are engaged in discussions about implementing features that could change the operation of Bitcoin. One proposal suggests making coins "expire" after a certain period of time, while another proposes creating a "never expire" transaction output. The potential security risks and the need for transparency and warning are also emphasized. Additionally, there is debate about implementing free transactions based on old priority rules, with suggestions including requiring the inclusion of free transactions in each block or a two-step transaction with a fee to register a UTXO refresh. However, there is no consensus on how to implement these proposals without burdening consensus rules.The threat of quantum computing to Bitcoin's security is also discussed, with suggestions for new proof-of-work algorithms, address formats, and signing protocols. Removing stale coins to prevent hacking is proposed, but there are differing opinions on whether this aligns with the principles of Bitcoin. The conversation highlights the challenges of implementing significant changes to Bitcoin, touching on issues of transparency, security, taxation, and adapting to technological advancements.Bitcoin developers are exploring solutions to address unbounded UTXO growth and ensure scalability. Proposals include burning inactive coins, implementing a minimum mining fee based on input age, and returning lost coins to miners as a fee. Limiting UTXO age in block count and invalidating UTXOs after a certain number of generations are also suggested. Some argue that limiting UTXO growth does not improve scalability, while others believe it is necessary for Bitcoin's longevity. The issue of UTXO size being critical because it cannot currently be pruned is acknowledged.A proposed solution involves using a soft fork to limit the maximum size of the UTXO set, with concerns raised about "lost" bitcoins that have not been spent for a long time. To address this, a mechanism called "luster" is suggested, where UTXOs lose value as they age. Coins continuously used in the Bitcoin economy retain value, while old coins lose value until they become valueless or reenter circulation. The proposal suggests storing the last 150 years of history in the blockchain. These proposals show promise in resolving the UTXO growth problem and scalability concerns but require considerations such as wallet software compatibility and sidechain implementation.Sidechains offer solutions to interoperability and scalability challenges in the blockchain ecosystem. They operate as separate blockchains pegged to the main blockchain, enabling asset transfer between chains and providing flexibility. Sidechains mitigate scalability issues by reducing the size of the main blockchain. However, implementing sidechains requires careful consideration of wallet software functionality and communication protocols between the main chain and sidechains. Collaboration and standardization within the blockchain community are necessary for successful integration. Sidechains have the potential to enhance blockchain functionality and address scalability concerns with the right development efforts. diff --git a/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap-Update-.xml b/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap-Update-.xml index 9e15c8761f..48c43f5486 100644 --- a/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap-Update-.xml +++ b/static/bitcoin-dev/July_2017/combined_Updating-the-Scaling-Roadmap-Update-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Updating the Scaling Roadmap [Update] - 2025-09-26T15:30:24.937011+00:00 + 2025-10-11T21:31:48.031227+00:00 python-feedgen Paul Sztorc 2017-07-17 22:04:49+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Updating the Scaling Roadmap [Update] - 2025-09-26T15:30:24.937169+00:00 + 2025-10-11T21:31:48.031411+00:00 2017-07-17T22:04:49+00:00 In a recent email exchange between David A. Harding and Paul Sztorc, the possibility of a document gaining traction on BitcoinCore.org was discussed. Paul expressed that without interest from the maintainers of bitcoincore.org, the document will probably be unable to gain traction. David responded by stating that if Paul wants his document to appear on the website, he should open a PR and offered to help format the document for the website. The maintainers of BitcoinCore.org ultimately decide if the standard has been met. Paul appreciated David's response and stated that he would make opening a PR to BitcoinCore.org with David's statement a priority so that future confusion can be avoided.In another discussion about adding new ideas to the Bitcoin roadmap, Alex Morcos and Peter Todd agreed that caution is necessary. Todd used his own Treechains work as an example of an idea that generated excitement but proved more difficult to implement than anticipated. He emphasized the importance of proper security peer review. Paul Sztorc proposed updating the existing Core Scalability Roadmap created in December 2015. The roadmap succeeded in synchronizing the entire Bitcoin community and getting everyone back to work. However, since the roadmap is now 19 months old, it is quite obsolete and needs to be replaced. The new roadmap would remove what has been accomplished, introduce new innovations and approaches, and update deadlines and projections. It includes technologies that increase Bitcoin's maximum tps rate or make it easier to process a higher volume of transactions.The technical community has completed a number of items on the Dec 2015 roadmap such as VersionBits (BIP 9), Compact Blocks (BIP 152), and Check Sequence Verify (BIP 112). Segregated Witness (BIP 141) and Lightning Network have been completed and await activation. Schnorr Signature Aggregation has been implemented in draft form in libsecp256k1, and drivechain is currently under peer review and may be usable by the end of 2017. Alex Morcos expressed concern about adding relatively new/untested ideas like Drivechain to the roadmap. Paul updated the roadmap to a "forecast" and edited the drivechain part to emphasize mainchain space being freed as defectors leave for an alt-chain.The Bitcoin community is exploring various scaling technologies including Segregated Witness, Lightning Network, Schnorr signature aggregation, MimbleWimble's shrinking block history, and drivechains. However, these technologies may not be sufficient to solve Bitcoin's scalability problem, and a hard fork to increase block size may be necessary. The proposed roadmap is still in draft form and feedback from the community is requested. A Google Doc link is available for those interested.In July 2017, Paul Sztorc proposed updating the Core Scalability Roadmap. The older statement from Dec 2015 endorsed a belief that "the community is ready to deliver on its shared vision that addresses the needs of the system while upholding its values". However, the shared vision has grown sharper over the last 18 months. According to Paul, it's necessary to revise it: remove what has been accomplished, introduce new innovations and approaches, and update deadlines and projections. The roadmap helped synchronize the entire Bitcoin community, bringing finality to the conversations of that time and getting everyone back to work. However, the Dec 2015 roadmap is now 19 months old and needs to be replaced.The new roadmap includes technologies that increase Bitcoin's maximum tps rate or make it easier to process a higher volume of transactions. Several items on the Dec 2015 roadmap have been completed, such as VersionBits (BIP 9), Compact Blocks (BIP 152), and Check Sequence Verify (BIP 112). Segregated Witness (BIP 141) and Lightning Network are complete and await activation. Schnorr Signature Aggregation has been implemented in draft form and drivechain is currently under peer review. If the capacity improvements outlined are insufficient, a hard fork may be necessary to increase block size. The document has been uploaded to GitHub for comments and expressions of interest.Paul Sztorc suggested updating the Core Scalability Roadmap. Greg Maxwell, the author of the original roadmap, has expressed regret and NACK'ed the concept. Tom Zander also did not ACK it due to its labeling as a "Bitcoin" document instead of a specific project document. The draft has been uploaded to GitHub and updated based on feedback received. However, without interest from the maintainers of bitcoincore.org, the document will probably be unable to gain traction.Paul Sztorc provided his reasons for updating the roadmap, stating that it synchronized the entire Bitcoin community and brought finality to the conversations of that time, getting everyone back to work. He emphasized the fatal scaling problem of the scaling conversation itself. The new roadmap updates the previous roadmap, includes technologies to increase capacity and scalability, and emphasizes concrete numbers and dates. Paul welcomes edits and feedback from the community.The technologies diff --git a/static/bitcoin-dev/July_2017/combined_how-to-disable-segwit-in-my-build-.xml b/static/bitcoin-dev/July_2017/combined_how-to-disable-segwit-in-my-build-.xml index 30121c2690..c10c7fadc0 100644 --- a/static/bitcoin-dev/July_2017/combined_how-to-disable-segwit-in-my-build-.xml +++ b/static/bitcoin-dev/July_2017/combined_how-to-disable-segwit-in-my-build-.xml @@ -2,7 +2,7 @@ 2 Combined summary - how to disable segwit in my build? - 2025-09-26T15:30:33.361683+00:00 + 2025-10-11T21:31:52.278666+00:00 python-feedgen Troy Benjegerdes 2017-07-14 21:11:07+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - how to disable segwit in my build? - 2025-09-26T15:30:33.361857+00:00 + 2025-10-11T21:31:52.278878+00:00 2017-07-14T21:11:07+00:00 A discussion on the bitcoin-dev mailing list revolved around the issue of disabling segwit activation in Bitcoin Core releases prior to 0.13.1. The conversation began with a user named Dan Libby expressing his desire to avoid segwit activation until he felt comfortable with it. However, Gregory Maxwell pointed out that disabling segwit activation is not a simple task and is also an unsupported configuration. Another respondent criticized Maxwell's attitude, warning that it could lead to Bitcoin Core being dropped and multiple competing implementations emerging.One of the concerns raised by Libby was the difficulty in maintaining and reading the consensus-critical code with segwit, as less than one third of it is visible on-screen. He suggested that users should have the ability to firewall off the code to ensure they are not running segwit. Another issue discussed was the risk for those using legacy clients, as segwit transactions can appear as "anyone-can-spend" outputs from their perspective. This vulnerability creates a risk for "zero confirm" transactions. One proposed solution was to avoid any transaction chain that contains a segwit transaction, but this would require everyone they transact with to follow the same rule.The conversation then shifted to the topic of achieving full security in bitcoin transactions. The recipient expressed uncertainty about how to achieve this, given that anyone they have transacted with can send them coins at any time. One option suggested was to run a node that has never published an address to a third party. Another option was to modify their own node to reject segwit transactions, but this would hardfork the network. It was also mentioned that it may be possible to construct a "certain balance" and an "uncertain balance" without modifying any rules.Hampus Sjöberg provided further clarification, explaining that there are two ways to be fully secure regarding chain transactions. The first option is to validate using the new rules of the network by running a segwit node. The second option is to avoid any transaction chain that contains a segwit transaction. He explained that the witness program in segwit transactions is encoded in a new format that old nodes do not understand, so for old nodes, a number greater than zero will be counted as a valid spend.The implications of not upgrading to a segwit compliant node were discussed. It was noted that if the majority of the network adopts segwit, non-segwit nodes would be downgraded to near-SPV node validation and may not be able to fully verify the ownership of bitcoins. It was also mentioned that even if one does not upgrade to segwit, they cannot avoid receiving UTXOs that were previously encumbered by a segwit output. However, it was suggested that continuing with a lower bandwidth cap and keeping coins "untainted" could be an experiment worth considering.Another point raised in the discussion was the desire to disable enforcement of segwit rules. It was explained that individuals cannot control the collective action of the bitcoin ecosystem to start enforcing the rules after a sufficient number of miners signal support. Disabling segwit enforcement could result in accepting blocks that nobody else in the network would accept, leading to a higher risk of double spends.The reasons for not wanting to run a segwit compliant node were also discussed. One reason mentioned was the potential increase in bandwidth requirements for segwit transactions. It was suggested that those not interested in segwit transactions may prefer to keep their node lower-cost by running a non-segwit node. However, it was noted that if the majority of the network adopts segwit, it would be in their best interest to validate those transactions.In summary, the conversation on the bitcoin-dev mailing list revolved around the issue of disabling segwit activation and the implications of not upgrading to a segwit compliant node. Various concerns and suggestions were raised regarding security, validation, bandwidth requirements, and maintaining backward compatibility. The discussion provided different perspectives and considerations for users who may be interested in or hesitant about adopting segwit. diff --git a/static/bitcoin-dev/July_2018/combined_Generalised-taproot.xml b/static/bitcoin-dev/July_2018/combined_Generalised-taproot.xml index 19c39e6017..7139063941 100644 --- a/static/bitcoin-dev/July_2018/combined_Generalised-taproot.xml +++ b/static/bitcoin-dev/July_2018/combined_Generalised-taproot.xml @@ -2,7 +2,7 @@ 2 Combined summary - Generalised taproot - 2025-09-26T15:49:57.830652+00:00 + 2025-10-11T21:58:09.572546+00:00 python-feedgen Pieter Wuille 2018-10-24 02:22:24+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Generalised taproot - 2025-09-26T15:49:57.830799+00:00 + 2025-10-11T21:58:09.572689+00:00 2018-10-24T02:22:24+00:00 Pieter Wuille, a Bitcoin Core developer, has introduced a new construction called "g'root" to address the issue of recursive-taproot-without-revealing-intermediary-scripts. This structure combines the concepts of Pedersen Commitments and taproot, resulting in an equation that combines private keys, hashes of additional conditions, and alternative spending methods.The g'root construction eliminates the distinction between pay-to-pubkey and pay-to-script constructions, providing an easy way to create a softfork-safe cross-input aggregation system. It also ensures that any future cross-input signature aggregation system only applies to companion keys that are not susceptible to potential changes in the scripting language.Wuille suggests deploying schnorr/taproot/mast initially, followed by the addition of graftroot/aggregation. Finally, the deployment of generalised taproot alongside graftroot/aggregation is recommended.In addition to this proposal, there is another suggestion for recursive taproot that utilizes Pedersen Commitments. By combining the taproot structure with a second generator in the curve, it becomes possible to create a pubkey point that can be spent either through direct signing or by revealing additional conditions.To maintain secrecy, the proposal allows users to hide whether there are any lower layers until the merkle-tree of scripts is reached. Furthermore, it enables the non-disclosure of conditions corresponding to any keys other than the one being spent with.This proposal is as space-efficient as basic taproot and potentially more efficient than using a merkle tree with taproot when there are three spending paths.To summarize, Pieter Wuille's "g'root" construction and the proposal for recursive taproot with Pedersen Commitments aim to enhance the functionality and efficiency of Bitcoin transactions. These proposals suggest deploying different components such as schnorr/taproot/mast and graftroot/aggregation in a phased manner to ensure a smooth transition. diff --git a/static/bitcoin-dev/July_2018/combined_URI-scheme-with-optional-bech32-address.xml b/static/bitcoin-dev/July_2018/combined_URI-scheme-with-optional-bech32-address.xml index 6132492c50..1da6be399c 100644 --- a/static/bitcoin-dev/July_2018/combined_URI-scheme-with-optional-bech32-address.xml +++ b/static/bitcoin-dev/July_2018/combined_URI-scheme-with-optional-bech32-address.xml @@ -2,7 +2,7 @@ 2 Combined summary - URI scheme with optional bech32 address - 2025-09-26T15:49:32.526063+00:00 + 2025-10-11T21:58:07.446081+00:00 python-feedgen shiva sitamraju 2018-09-25 06:59:48+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - URI scheme with optional bech32 address - 2025-09-26T15:49:32.526226+00:00 + 2025-10-11T21:58:07.446240+00:00 2018-09-25T06:59:48+00:00 A proposal has been shared on Reddit regarding the adoption of bech32 QR codes in the Bitcoin network. While QR code adoption is considered important, bech32 QR codes are not backward compatible, leading many merchants and exchanges to opt for P2SH address QR codes instead. The proposed solution suggests using a URI format that includes both bech32 and P2SH address options. This would allow wallets to autopay using the lower transaction fee associated with bech32 addresses.The rationale behind this proposal is to increase the usage of bech32, which would create a network effect and potentially lead to widespread adoption of bech32 QR codes. To implement this solution, a team of developers is working on a walleting application capable of generating bech32 and P2WPKH-nested-in-P2SH addresses.One challenge faced by the team is that the payee cannot know in advance the technological capabilities of the payer. To address this, the proposal suggests encoding both bech32 and P2SH addresses in a Bitcoin URI. Legacy wallets would only see the P2SH address, while new wallets would be able to see and use the bech32 address for transactions.To maintain compatibility with BIP21, the 'path' field of the URI can be used for the P2WPKH-nested-in-P2SH address, while a new field (e.g., 'bech32') can be introduced for the bech32 address. It is assumed that wallets utilizing this scheme would monitor incoming transactions on both addresses. The order of attributes in the URI should not matter, as clients would check all attributes with the same name. However, it remains unclear if there are any precedents for the multiple use of an attribute in URI schemes.The team acknowledges that their proposal may not be entirely novel and asks if anyone has already proposed something similar. They also seek feedback on any major drawbacks to their proposal. diff --git a/static/bitcoin-dev/July_2021/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml b/static/bitcoin-dev/July_2021/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml index 2f1ff44f7b..f512facec8 100644 --- a/static/bitcoin-dev/July_2021/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml +++ b/static/bitcoin-dev/July_2021/combined_Unlimited-covenants-was-Re-CHECKSIGFROMSTACK-Verify-BIP-for-Bitcoin.xml @@ -2,7 +2,7 @@ 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2025-09-26T15:42:27.533629+00:00 + 2025-10-11T21:53:58.712823+00:00 python-feedgen ZmnSCPxj 2021-07-05 00:50:50+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin - 2025-09-26T15:42:27.533825+00:00 + 2025-10-11T21:53:58.712966+00:00 2021-07-05T00:50:50+00:00 In a response to Jeremy's concerns about arbitrary covenants in the Bitcoin community, ZmnSCPxj highlights the importance of respecting the concerns of others while still allowing for useful tools. ZmnSCPxj counters Shinobi's worries about covenants by stating that altcoins already have similar issues, and recursive covenants would not exacerbate these problems. ZmnSCPxj argues that an "inescapable" covenant is comparable to a `while (true);` loop, essentially making covenants Turing-complete. However, he suggests that placing an upper bound on the number of recursions could prevent full Turing-completeness while still accommodating a wide range of use-cases. Moving to an email thread, Jeremy expresses concern over the Bitcoin community's reluctance to embrace arbitrary covenants, fearing potential unforeseen consequences. In response, Dave proposes an alternative approach to addressing concerns, suggesting that proving their unfounded or lesser severity rather than limiting useful tools may be more effective in fostering mutual respect. He also points out that some of the concerns raised by Shinobi are already present in altcoins and recursive covenants might not necessarily worsen these issues. Dave believes that imposing restrictions on Bitcoin's flexibility to avoid certain problems is unnecessary when unlimited covenants could potentially offer interesting and valuable features to the community. diff --git a/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml b/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml index 3db8b69438..4d41f51315 100644 --- a/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml +++ b/static/bitcoin-dev/July_2022/combined_BIP-Proposal-Receiving-and-Change-Derivation-Paths-in-a-Single-Descriptor.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2025-09-26T15:34:33.325055+00:00 + 2025-10-11T21:43:54.961785+00:00 python-feedgen Dmitry Petukhov 2022-08-04 07:09:33+00:00 @@ -42,10 +42,11 @@ + 2 Combined summary - BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor - 2025-09-26T15:34:33.325202+00:00 + 2025-10-11T21:43:54.961932+00:00 2022-08-04T07:09:33+00:00 A recent update has been made to the Bitcoin Improvement Proposal (BIP) regarding the representation of descriptors for receiving and change addresses. The issue with tuples of length more than two is that the purpose for indexes beyond 'receive' and 'change' are not established. This could lead to various software using extra indexes in a tuple for their own non-standard purposes, creating incompatibilities where different wallet software that import the same descriptor would use those addresses for different purposes. Even if some auxiliary standard emerges for the meanings of extra indexes, all software will need to be aware of these purposes and define indexes for them. It is suggested that bip-multipath-descs should say that any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. Wallet software that wishes to utilize non-standard extra indexes beyond 'receive' and 'change' should use separate descriptors instead for these extra indexes. If a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position.The BIP has been updated to allow arbitrary length tuples, which was proposed by Pavol Rusnak. While there may not be any immediate use case for this, it would allow for future standards to introduce more sub-paths. However, it is important to note that even with generalized tuples, any interpretation of the purpose of such indexes and deriving new addresses at these indexes are strongly discouraged. When a new established purpose emerges for the next position in the index tuple, a new BIP should be made that defines such position. The BIP for position 3 would naturally come after the BIP for position 2, ensuring that software that implements BIP for position 3 would be aware of the previous BIP and choose some index for position 2.Andrew Chow proposed a BIP that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. The proposal allows for a single derivation path element that specifies a pair of indexes, which can be expanded into two almost identical descriptors with the difference being that the first uses the first index of the pair and the second uses the second index. This notation also works for descriptors involving multiple keys; the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Craig thanked Andrew for proposing a BIP that simplifies how descriptors for receiving and change addresses are represented. He finds a single descriptor important when backing up a wallet, especially a multisig wallet that requires a backup of all the xpubs. The proposed notation allows descriptors to have a single derivation path element specifying a pair of indexes. Parsers would then expand these into two almost identical descriptors with the difference being that the first uses the first of the pair of indexes, and the second uses the second. Andrew's BIP, called "multipath-descs," modifies key expressions of descriptors described in BIP 380 to indicate BIP 32 derivation path steps that can have multiple values. Wallets often require at least two descriptors for all of the scripts they watch for. The only differences between them are in the derivation path where one of the steps will be different between the descriptors. This modification allows a notation to represent both descriptors as a single descriptor where one of the derivation steps is a pair of values. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses and the second descriptor for producing change addresses. The addition to key expressions defined in BIP 380 is compatible with this modification, and parsers that implement this will still be able to parse such descriptors. However, older parsers will not be able to understand such descriptors.Andrew Chow proposed a Bitcoin Improvement Proposal (BIP) that aims to simplify and de-duplicate how descriptors for receiving and change addresses are represented. Currently, two almost identical descriptors are required with the only difference being one derivation path element. Andrew's proposal allows for a single derivation path element that specifies a pair of indexes which can be expanded into two nearly identical descriptors with the first using the first index of the pair and the second using the second index. This notation also works for descriptors involving multiple keys, where the first element in every pair is used for the first descriptor, and the second element of each pair in the second descriptor. The proposal uses tuples of diff --git a/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml index fba6525d9f..9e0682fe08 100644 --- a/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/July_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -2,7 +2,7 @@ 2 Combined summary - On a new community process to specify covenants - 2025-09-26T15:34:29.100860+00:00 + 2025-10-11T21:43:50.709609+00:00 python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -106,10 +106,11 @@ + 2 Combined summary - On a new community process to specify covenants - 2025-09-26T15:34:29.101029+00:00 + 2025-10-11T21:43:50.709764+00:00 2022-10-07T15:33:12+00:00 The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest diff --git a/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml b/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml index 6869b4fa15..03ab4c9b74 100644 --- a/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml +++ b/static/bitcoin-dev/July_2022/combined_Surprisingly-Tail-Emission-Is-Not-Inflationary.xml @@ -2,7 +2,7 @@ 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2025-09-26T15:34:31.213515+00:00 + 2025-10-11T21:43:52.835593+00:00 python-feedgen Billy Tetrud 2022-08-20 15:30:26+00:00 @@ -230,10 +230,11 @@ + 2 Combined summary - Surprisingly, Tail Emission Is Not Inflationary - 2025-09-26T15:34:31.213743+00:00 + 2025-10-11T21:43:52.835789+00:00 2022-08-20T15:30:26+00:00 The context discusses various discussions and debates related to the functioning and security of the Bitcoin network. One aspect discussed is the concept of "free lunches" in the network, where some users benefit without contributing, while others bear the costs. It is argued that this is an unhealthy state for the financial system and may not be sustainable in the long term.One suggestion to address this issue is to remove halvings, which are events that reduce the block reward for miners, if they become destructive to the network's security. It is also mentioned that a balanced system with a low annual inflation rate is preferable to any fiat system. While widespread consensus would be ideal, it is acknowledged that a hard fork may be necessary to implement necessary changes.The feasibility of large Bitcoin holders running ASICs to secure their holdings is also discussed. The assumption is made that fees alone may not compensate for low block rewards, and therefore, large holders may mine at a loss to preserve the value of their holdings. However, it is acknowledged that this approach may not work in practice due to trust issues and the potential for betrayal.The concept of the Prisoner's Dilemma is mentioned in relation to cooperation between Bitcoin users. It is highlighted that even though cooperation may be in the best interest of both parties, mistrust and self-interest can lead to suboptimal outcomes.The importance of transaction fees in providing censorship resistance and incentivizing miners to keep the network secure is emphasized. The discussion explores different approaches, such as tying miner revenue to the total value of Bitcoin or relying solely on transaction fees.There are debates about the business model of miners who intend to censor transactions when there is no block reward. It is argued that transaction fees provide censorship resistance, and miners may prioritize high fee transactions to maximize their earnings.The role of the block reward in the functioning of the Bitcoin network is highlighted. The question is raised about whether a perpetual block subsidy should be tied to the total value of Bitcoin or if other methods should be considered to incentivize miners.The assumption of a constant rate for losses in Bitcoin is challenged, and it is argued that losses can occur at a predictable rate. The potential impact of lost coins on the overall value of Bitcoin is discussed.There are also discussions about the subjective nature of defining Bitcoin and the role of leading bodies versus individual autonomy. The importance of the capped supply and predictable issuance curve is mentioned, and tinkering with the protocol is seen as potentially inviting further subversion.The discussion revolves around the predictability of losses in tail emission. While Peter assumes that there is a rate, it is possible for losses to be at a different predictable rate. However, if there exists any fixed central tendency for the rate, tail emission will eventually become non-inflationary. There are two other factors to consider: firstly, if people improve custody faster than 1/(N(t)*P), tail emission can still be inflationary, although this seems unlikely. Secondly, the rate is somewhat stochastic, with "black swan events" like popular wallet losing keys in coding error being possible but not relevant to tail-emission being non-inflationary. However, even such events can be factored into a fixed central tendency over a long enough time period.In the discussion on whether or not to extend block rewards after the current deadline, it is noted that this is only relevant if the community agrees that it is necessary to maintain network security. It is worth noting that a mild inflation can sometimes be compensated by coin loss, which is like a bonus. The assumption of a constant coin loss rate seems unreasonable as people improve their key storage habits over time, leading to a decrease in the rate of coin loss. Additionally, there may be common causes for coin losses that result in heavily correlated losses rather than independent ones.The conversation further explores the potential implications of tail emission on the ability of individuals to access their coins. Todd clarifies that his proposal does not involve re-assigning ownership of coins and therefore does not take away anyone's ability to access their coins. The concern raised by naman naman about the ability to move coins after a long period of inactivity is addressed, with Todd stating that his article on tail emission is focused on maintaining blockchain security without causing inflation.The latest blog post by Peter Todd titled "Surprisingly, Tail Emission Is Not Inflationary" explores the concept of tail emission and its impact on the supply of Bitcoin. Todd argues that tail emission, which is a fixed reward per block that continues indefinitely, can result in a stable monetary supply rather than a monetarily inflationary one. He explains that lost coins contribute to this stability, as they are constantly being lost due to various factors such as deaths, forgotten passphrases, and accidents.The article also discusses the feasibility of implementing tail emission in Bitcoin. While other currencies like Monero have successfully implemented it, adding tail emission to Bitcoin would require convincing a substantial fraction of the Bitcoin community to support the idea. Todd suggests that diff --git a/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml b/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml index 73d80f9233..93251217b5 100644 --- a/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml +++ b/static/bitcoin-dev/July_2023/combined_Concern-about-Inscriptions-ashneverdawn-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Concern about "Inscriptions". (ashneverdawn) - 2025-09-26T14:24:42.689306+00:00 + 2025-10-11T21:43:57.092782+00:00 python-feedgen Keagan McClelland 2023-08-02 05:58:53+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Concern about "Inscriptions". (ashneverdawn) - 2025-09-26T14:24:42.689449+00:00 + 2025-10-11T21:43:57.092914+00:00 2023-08-02T05:58:53+00:00 The debate revolves around introducing a pricing mechanism for space in the Unspent Transaction Output (UTXO) set. Currently, the UTXO set space is not priced, which causes uncertainty in classifying transactions as spam or legitimate. The UTXO set must be maintained by all nodes, including pruned nodes, making it more valuable than chain space. Introducing a pricing mechanism may lead to inscriptions disappearing as users would have to pay for their usage. However, this proposition may be controversial and offensive to some Bitcoin users. Pricing space in the UTXO set remains an open discussion. It is argued that differentiating transaction types on the network should not be done for privacy and censorship resistance. Limited blockchain resources should go to the highest bidder, based on the value they provide to the marketplace against the cost to the network. The growth rate of the blockchain is not caused by Ordinals, but rather by the limit on storage that can be added per block. diff --git a/static/bitcoin-dev/July_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml b/static/bitcoin-dev/July_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml index fca8311ebe..6fa39076c1 100644 --- a/static/bitcoin-dev/July_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml +++ b/static/bitcoin-dev/July_2023/combined_Pull-req-to-enable-Full-RBF-by-default.xml @@ -2,7 +2,7 @@ 2 Combined summary - Pull-req to enable Full-RBF by default - 2025-09-26T14:24:53.399206+00:00 + 2025-10-11T21:43:59.216998+00:00 python-feedgen Peter Todd 2023-08-03 12:46:40+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - Pull-req to enable Full-RBF by default - 2025-09-26T14:24:53.399379+00:00 + 2025-10-11T21:43:59.217186+00:00 2023-08-03T12:46:40+00:00 The claim that "trxs activity" is meaningless without demonstrating reliance on unconfirmed transaction acceptance is being challenged. The commenter questions the credibility of GAP600's offering of a "real-time risk engine" and "instant deposits & payments" without testing full-replace-by-fee (full-rbf) adoption themselves. They provide examples of transactions that were part of chains of replacements and question how these transactions are getting mined. The commenter requests the names of merchants using GAP600's claimed service to verify their reliance on unconfirmed transactions. They also mention reaching out to changelly.com for confirmation of their use of GAP600 but have yet to receive a response.GAP600 responds by stating they do not conduct specific assessments or research on hashing pools and that client confidentiality prevents them from disclosing their clients' names. They suggest contacting Max from Coinpaid for confirmation of their use of GAP600. They also mention that Changelly may not have fully implemented their service across all offerings. They provide contact details for further inquiries.In response to the commenter's assessment, GAP600 defends their honesty and offers evidence of their position. They state that they have provided clear access to clients to verify their statistics and offer a solution for validating full RBF adoption. They argue that the commenter's conclusions are unfounded.The author challenges the credibility of the claim that merchants relying on unconfirmed transactions exist and asks for concrete examples to support this assertion. They have reached out to Coinspaid and Changelly for confirmation but are awaiting a reply. They also query the specific services offered by Changelly that depend on unconfirmed transactions and inquire about the risk criteria set by GAP600. They suggest conducting test transactions if provided with the necessary information but refuse to provide transaction hashes to protect account owners. They question the lack of specific examples of affected businesses and dismiss payment processors as irrelevant. They mention instances of mining pools being harassed and decline to share private contact information. They suggest that if the service in question truly offered an unconfirmed transaction guarantee, they would have ample data on pools practicing full-rbf.The author provides evidence that there are no genuine examples of actual merchants accepting unconfirmed transactions. They mention that Changelly explicitly states that they do not accept unconfirmed payments. They request an example of an actual merchant accepting unconfirmed transactions.GAP600 provides statistics and feedback from Coinspaid to support their claims. They argue that the lack of impact on double spend rates suggests that the adoption of full RBF by miners is questionable. They mention that they reimburse clients for incorrect predictions of double spends. They clarify that they are not a payment processor but provide services to payment processors, merchants, and non-custodial liquidity providers.The author discusses the implementation of full Replace-By-Fee (RBF) in Bitcoin transactions and its potential negative impact on merchants and users who accept 0-conf transactions. They mention mitigation tools like GAP600 that require replacement transactions to include the original outputs. They provide statistics on the usage of GAP600 and mention their clients. They argue that the addition of a "first seen safe" rule is crucial to avoid negative consequences.The author of the context has submitted a pull request to enable full-rbf by default in Bitcoin Core. They mention several block explorers, nodes, and wallets that have enabled full-rbf. They argue that enabling full-rbf by default will address the issue of a minority of nodes relaying full-rbf replacements. They mention opposition from Bitrefill but found no evidence that they still accept unconfirmed transactions. They propose enabling full-rbf by default in Bitcoin Core and deprecating and removing BIP125 code in future releases. The context includes references to support the points made. diff --git a/static/bitcoin-dev/June_2012/combined_0-6-x-detachdb-in-wrong-place.xml b/static/bitcoin-dev/June_2012/combined_0-6-x-detachdb-in-wrong-place.xml index 0f27816438..e4cff48b0a 100644 --- a/static/bitcoin-dev/June_2012/combined_0-6-x-detachdb-in-wrong-place.xml +++ b/static/bitcoin-dev/June_2012/combined_0-6-x-detachdb-in-wrong-place.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.6.x - detachdb in wrong place - 2023-08-01T03:40:11.066589+00:00 + 2025-10-11T22:13:17.443221+00:00 + python-feedgen grarpamp 2012-06-20 09:06:53+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - 0.6.x - detachdb in wrong place - 2023-08-01T03:40:11.067589+00:00 + 2025-10-11T22:13:17.443387+00:00 - In the given context, the speaker discusses a work model that they plan to try out over the weekend. Although no specific details are provided about this work model, it can be inferred that the speaker is looking for ways to improve their productivity or efficiency. They express gratitude for the advice or suggestions they have received.The context also includes a conversation between grarpamp and Luke regarding the update of the stable repository with releases tagged in master. Luke's update fixes this issue, allowing Git users to compare release tags to stable 'x' branches on Gitorious more easily. Prior to this update, users had to manually diff checkouts from each repository. The work model mentioned involves cloning the Bitcoin repository and adding remote repositories such as stable and personal. With the command "git fetch --all", users can update their copy of the remote branches and access them as "origin/master", "stable/0.6.x", etc. Personal branches can also be pushed using "git push personal".Regarding workflows and release windows in master, the writer explains that new development takes place in master during release windows. Once the windows close, master is cleaned up and bug-fixed for the next 0.x release. If there are issues with 0.N.0 before the next release window opens, a 0.N.1 (or even a 0.N.2 and 0.N.2.2) can be rolled. The last bugfix-only commit after the final 0.N.M release made in master is imported into the stable repository as the 0.N.x branch, and backports are applied. Significant backports may result in another 0.N.M tag, and Windows binaries may be released.The cautionary note is given to have good backups that never touched the new code due to bugs in master that could corrupt wallets. It is suggested that anyone offering Bitcoin services should set up parallel toy versions of their sites on testnet to conduct testing without fear of losing funds. The email also mentions that there is currently not enough testing activity on master, and the writer recommends using caution when running master on wallets with large amounts of non-testnet coin.In an email conversation between grarpamp and an unknown party, the difference between two Bitcoin repositories hosted on GitHub and Gitorious is discussed. The Gitorious repository contains Luke's backports of security and stability fixes to old versions of the software that are no longer maintained. It is suggested that formal releases are tagged in one repository while branches with commits for the next formal release are in the other.Another conversation between grarpamp and Luke addresses the safety of the github/0.6.2 branch for production use. Luke explains that this branch is temporary and stable releases are available on Gitorious for production purposes. He also mentions a recent fix that will be backported to stable branches soon.In a separate email conversation, grarpamp raises a question about the absence of a certain line in the ifdef in the bitcoin git master. They seek clarification on the difference between two repositories, specifically in relation to the project. The user wants to know which repository contains formal releases that are tagged and cut into .tbz files, as well as which one has branches with commits for the next formal release. It is mentioned that the code in question is not located inside an ifdef in the Bitcoin Git master.Lastly, grarpamp reports that the command 'detachdb' is not appearing in the help section of the latest build of Bitcoin. The issue is due to it being included under 'pnp', which was not set in their build. They request a fix for this problem and receive a suggestion to post such requests on the GitHub issue tracker instead of the mailing list. The context also includes information about the conditional compilation of the "-upnp" flag and the functionality of the "-detachdb" flag. 2012-06-20T09:06:53+00:00 + In the given context, the speaker discusses a work model that they plan to try out over the weekend. Although no specific details are provided about this work model, it can be inferred that the speaker is looking for ways to improve their productivity or efficiency. They express gratitude for the advice or suggestions they have received.The context also includes a conversation between grarpamp and Luke regarding the update of the stable repository with releases tagged in master. Luke's update fixes this issue, allowing Git users to compare release tags to stable 'x' branches on Gitorious more easily. Prior to this update, users had to manually diff checkouts from each repository. The work model mentioned involves cloning the Bitcoin repository and adding remote repositories such as stable and personal. With the command "git fetch --all", users can update their copy of the remote branches and access them as "origin/master", "stable/0.6.x", etc. Personal branches can also be pushed using "git push personal".Regarding workflows and release windows in master, the writer explains that new development takes place in master during release windows. Once the windows close, master is cleaned up and bug-fixed for the next 0.x release. If there are issues with 0.N.0 before the next release window opens, a 0.N.1 (or even a 0.N.2 and 0.N.2.2) can be rolled. The last bugfix-only commit after the final 0.N.M release made in master is imported into the stable repository as the 0.N.x branch, and backports are applied. Significant backports may result in another 0.N.M tag, and Windows binaries may be released.The cautionary note is given to have good backups that never touched the new code due to bugs in master that could corrupt wallets. It is suggested that anyone offering Bitcoin services should set up parallel toy versions of their sites on testnet to conduct testing without fear of losing funds. The email also mentions that there is currently not enough testing activity on master, and the writer recommends using caution when running master on wallets with large amounts of non-testnet coin.In an email conversation between grarpamp and an unknown party, the difference between two Bitcoin repositories hosted on GitHub and Gitorious is discussed. The Gitorious repository contains Luke's backports of security and stability fixes to old versions of the software that are no longer maintained. It is suggested that formal releases are tagged in one repository while branches with commits for the next formal release are in the other.Another conversation between grarpamp and Luke addresses the safety of the github/0.6.2 branch for production use. Luke explains that this branch is temporary and stable releases are available on Gitorious for production purposes. He also mentions a recent fix that will be backported to stable branches soon.In a separate email conversation, grarpamp raises a question about the absence of a certain line in the ifdef in the bitcoin git master. They seek clarification on the difference between two repositories, specifically in relation to the project. The user wants to know which repository contains formal releases that are tagged and cut into .tbz files, as well as which one has branches with commits for the next formal release. It is mentioned that the code in question is not located inside an ifdef in the Bitcoin Git master.Lastly, grarpamp reports that the command 'detachdb' is not appearing in the help section of the latest build of Bitcoin. The issue is due to it being included under 'pnp', which was not set in their build. They request a fix for this problem and receive a suggestion to post such requests on the GitHub issue tracker instead of the mailing list. The context also includes information about the conditional compilation of the "-upnp" flag and the functionality of the "-detachdb" flag. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_After-compressed-pubkeys-hybrid-pubkeys.xml b/static/bitcoin-dev/June_2012/combined_After-compressed-pubkeys-hybrid-pubkeys.xml index a96fcf2b47..04fdf005de 100644 --- a/static/bitcoin-dev/June_2012/combined_After-compressed-pubkeys-hybrid-pubkeys.xml +++ b/static/bitcoin-dev/June_2012/combined_After-compressed-pubkeys-hybrid-pubkeys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - After compressed pubkeys: hybrid pubkeys - 2023-08-01T03:39:41.568622+00:00 + 2025-10-11T22:13:34.434207+00:00 + python-feedgen Wladimir 2012-06-17 15:16:13+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - After compressed pubkeys: hybrid pubkeys - 2023-08-01T03:39:41.568622+00:00 + 2025-10-11T22:13:34.434369+00:00 - The discussion between Pieter Wuille, Mike Hearn, and Wladimir revolves around the different formats of encryption keys in OpenSSL. They discuss the uncompressed format (0x04), hybrid format for even Y coords (0x06), and hybrid format for odd Y coords (0x07). Pieter explains that the only difference between these formats is the first number. However, to prevent surprises in the future, Wladimir suggests disabling all other key formats in advance.In 2012, Mike Hearn inquired about the differences in format between three types of elliptic curve points: uncompressed, hybrid for even Y coords, and hybrid for odd Y coords. Pieter responds, stating that the only difference between these formats is the first number. No further information is provided about the context or purpose of these elliptic curve points.There are three formats used for representing elliptic curve points: uncompressed format (0x04), hybrid format for even Y coords (0x06), and hybrid format for odd Y coords (0x07). These formats use the same 32-byte X coord and 32-byte Y coord but differ based on the type of format used.On June 16th, 2012, Gregory Maxwell and Gavin Andresen discuss the usage of 'hybrid' public keys. The topic is whether to forbid their usage or not. Gavin suggests treating transactions using these keys as 'non-standard,' meaning they won't be relayed or mined automatically but can still be accepted in a block. He agrees with Gregory that changing rules isn't necessary currently but making them non-standard now would make a rule change easier later. Gregory expresses hope that no one would mine these before a rule change could be implemented. The rejection of OP_NOP is also discussed, with Luke expressing willingness to reject both hybrid public keys and OP_NOP if a patch that didn't depend on IsStandard being enforced is provided.Gavin Andresen initiates a discussion on the Bitcoin development mailing list about 'hybrid' public keys with the prefix 0x06/0x07. He proposes treating them as 'non-standard' transactions to make alternative implementations easier in the future. However, he doesn't believe a network rule change is worth the hassle at this time. Instead, he suggests not relaying or mining these transactions by default but still accepting blocks that contain them. This approach would facilitate a rule change in the future if necessary.The author discusses the different encoding formats for public keys used in OpenSSL. Compressed public keys are supported in a fully backward-compatible way, and a non-standard encoding format is also supported by most validating clients on the network. The author believes that alternative implementations should handle these encodings despite no hybrid keys being used in the main chain. The various encodings include 0x00 for a point at infinity, 0x02 and 0x03 for compressed formats for even and odd Y coords, 0x04 for uncompressed format, and 0x06 and 0x07 for hybrid formats for even and odd Y coords. The author suggests forbidding these formats after a certain date or block height, although enforcing this through a network rule change may not be worth it. 2012-06-17T15:16:13+00:00 + The discussion between Pieter Wuille, Mike Hearn, and Wladimir revolves around the different formats of encryption keys in OpenSSL. They discuss the uncompressed format (0x04), hybrid format for even Y coords (0x06), and hybrid format for odd Y coords (0x07). Pieter explains that the only difference between these formats is the first number. However, to prevent surprises in the future, Wladimir suggests disabling all other key formats in advance.In 2012, Mike Hearn inquired about the differences in format between three types of elliptic curve points: uncompressed, hybrid for even Y coords, and hybrid for odd Y coords. Pieter responds, stating that the only difference between these formats is the first number. No further information is provided about the context or purpose of these elliptic curve points.There are three formats used for representing elliptic curve points: uncompressed format (0x04), hybrid format for even Y coords (0x06), and hybrid format for odd Y coords (0x07). These formats use the same 32-byte X coord and 32-byte Y coord but differ based on the type of format used.On June 16th, 2012, Gregory Maxwell and Gavin Andresen discuss the usage of 'hybrid' public keys. The topic is whether to forbid their usage or not. Gavin suggests treating transactions using these keys as 'non-standard,' meaning they won't be relayed or mined automatically but can still be accepted in a block. He agrees with Gregory that changing rules isn't necessary currently but making them non-standard now would make a rule change easier later. Gregory expresses hope that no one would mine these before a rule change could be implemented. The rejection of OP_NOP is also discussed, with Luke expressing willingness to reject both hybrid public keys and OP_NOP if a patch that didn't depend on IsStandard being enforced is provided.Gavin Andresen initiates a discussion on the Bitcoin development mailing list about 'hybrid' public keys with the prefix 0x06/0x07. He proposes treating them as 'non-standard' transactions to make alternative implementations easier in the future. However, he doesn't believe a network rule change is worth the hassle at this time. Instead, he suggests not relaying or mining these transactions by default but still accepting blocks that contain them. This approach would facilitate a rule change in the future if necessary.The author discusses the different encoding formats for public keys used in OpenSSL. Compressed public keys are supported in a fully backward-compatible way, and a non-standard encoding format is also supported by most validating clients on the network. The author believes that alternative implementations should handle these encodings despite no hybrid keys being used in the main chain. The various encodings include 0x00 for a point at infinity, 0x02 and 0x03 for compressed formats for even and odd Y coords, 0x04 for uncompressed format, and 0x06 and 0x07 for hybrid formats for even and odd Y coords. The author suggests forbidding these formats after a certain date or block height, although enforcing this through a network rule change may not be worth it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_BIP22-getmemorypool.xml b/static/bitcoin-dev/June_2012/combined_BIP22-getmemorypool.xml index 8eb9f2b906..9e55afa5cf 100644 --- a/static/bitcoin-dev/June_2012/combined_BIP22-getmemorypool.xml +++ b/static/bitcoin-dev/June_2012/combined_BIP22-getmemorypool.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP22/getmemorypool - 2023-08-01T03:34:28.220192+00:00 + 2025-10-11T22:13:00.451513+00:00 + python-feedgen Pieter Wuille 2012-06-12 10:50:40+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP22/getmemorypool - 2023-08-01T03:34:28.220192+00:00 + 2025-10-11T22:13:00.451666+00:00 - In an email thread dated June 11, 2012, the complexity of BIP 22 is discussed by various individuals. They express their desire to simplify it and gather feedback on the key features that will likely be used by pool customers. The discussion focuses on whether the proposed 20 optional features are necessary, rather than the usefulness of getmemorypool. One individual specifically mentions Electrum servers as users of these features.The Sourceforge mailing list system experienced issues over the weekend, causing multiple copies of Pieter's messages to appear in people's inboxes. These extra copies have been deleted from the mailing list archives. As a result of the mailing list problems, the discussion shifted to the pull request on Github regarding BIP 22. Gavin Andresen and Pieter both believe that BIP 22 is overly complicated and wish to simplify it. Gavin is particularly interested in knowing which features will be commonly used by pool customers versus those that will only be used by a small percentage of them. He encourages further discussion on the topic.Pieter, a member of the Bitcoin community, expresses concerns about the complexity of the BIP 22 standard for negotiating block generation. He believes that while having a stable and flexible API is important, too few people understand the details well enough to judge their necessity. Pieter suggests that the standard should not be more complex than necessary and its purpose and intended use cases should be clear.Pieter points out several issues with the current BIP 22 standard. He questions why full transactions (serialized in hex) are sent in templates and submissions, suggesting that transferring txids may be sufficient. He also believes there are too many optional features in the standard, such as variations in coinbase outputs and noncerange limiting, making it unnecessarily complex for clients. Additionally, Pieter dislikes several ways of specifying the same behavior and recommends picking one flexible way and discarding the others.In summary, Pieter suggests simplifying the standard to include only `getblocktemplate` and `submitblocktemplate`. The former creates a new block template and returns it, while the latter submits an object containing a hex serialized block header, hex serialized coinbase transaction, and a list of txids. Proof of work is checked last, so that error is only returned if there is no other problem with the suggested block.Pieter Wuille, a Bitcoin developer, has also posted in the bitcoin-development mailing list about his concerns with the BIP22 protocol. He emphasizes the importance of having a stable and flexible API for negotiating block generation standardized. However, he believes that too few people understand the details of BIP22 and its intended use cases. Wuille suggests simplifying the standard by reducing the number of optional features and ways of specifying the same behavior. He proposes creating a new block template with specific fields and submitting an object containing necessary information. Wuille asks for feedback on any important use cases that may have been missed. 2012-06-12T10:50:40+00:00 + In an email thread dated June 11, 2012, the complexity of BIP 22 is discussed by various individuals. They express their desire to simplify it and gather feedback on the key features that will likely be used by pool customers. The discussion focuses on whether the proposed 20 optional features are necessary, rather than the usefulness of getmemorypool. One individual specifically mentions Electrum servers as users of these features.The Sourceforge mailing list system experienced issues over the weekend, causing multiple copies of Pieter's messages to appear in people's inboxes. These extra copies have been deleted from the mailing list archives. As a result of the mailing list problems, the discussion shifted to the pull request on Github regarding BIP 22. Gavin Andresen and Pieter both believe that BIP 22 is overly complicated and wish to simplify it. Gavin is particularly interested in knowing which features will be commonly used by pool customers versus those that will only be used by a small percentage of them. He encourages further discussion on the topic.Pieter, a member of the Bitcoin community, expresses concerns about the complexity of the BIP 22 standard for negotiating block generation. He believes that while having a stable and flexible API is important, too few people understand the details well enough to judge their necessity. Pieter suggests that the standard should not be more complex than necessary and its purpose and intended use cases should be clear.Pieter points out several issues with the current BIP 22 standard. He questions why full transactions (serialized in hex) are sent in templates and submissions, suggesting that transferring txids may be sufficient. He also believes there are too many optional features in the standard, such as variations in coinbase outputs and noncerange limiting, making it unnecessarily complex for clients. Additionally, Pieter dislikes several ways of specifying the same behavior and recommends picking one flexible way and discarding the others.In summary, Pieter suggests simplifying the standard to include only `getblocktemplate` and `submitblocktemplate`. The former creates a new block template and returns it, while the latter submits an object containing a hex serialized block header, hex serialized coinbase transaction, and a list of txids. Proof of work is checked last, so that error is only returned if there is no other problem with the suggested block.Pieter Wuille, a Bitcoin developer, has also posted in the bitcoin-development mailing list about his concerns with the BIP22 protocol. He emphasizes the importance of having a stable and flexible API for negotiating block generation standardized. However, he believes that too few people understand the details of BIP22 and its intended use cases. Wuille suggests simplifying the standard by reducing the number of optional features and ways of specifying the same behavior. He proposes creating a new block template with specific fields and submitting an object containing necessary information. Wuille asks for feedback on any important use cases that may have been missed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Berlin-Bitcoin-Hackathon.xml b/static/bitcoin-dev/June_2012/combined_Berlin-Bitcoin-Hackathon.xml index d0c8260da4..b169f2100a 100644 --- a/static/bitcoin-dev/June_2012/combined_Berlin-Bitcoin-Hackathon.xml +++ b/static/bitcoin-dev/June_2012/combined_Berlin-Bitcoin-Hackathon.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Berlin Bitcoin Hackathon - 2023-08-01T03:42:45.100379+00:00 + 2025-10-11T22:13:13.195127+00:00 + python-feedgen Stefan Thomas 2012-06-22 06:39:24+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Berlin Bitcoin Hackathon - 2023-08-01T03:42:45.100379+00:00 + 2025-10-11T22:13:13.195261+00:00 - Amir Taaki, a member of the Bitcoin-development mailing list, announced on June 22, 2012, the occurrence of a Bitcoin hackathon event in Berlin. He expressed his willingness to provide hosting space for the event if required. The purpose of the hackathon was to discuss the evolving security and threat landscape in today's digital world, and to explore ways in which IT managers can effectively respond to these challenges.Discussions at the hackathon encompassed various topics such as endpoint security, mobile security, and the latest developments in malware threats. This event aimed to bring together experts and enthusiasts in the field of Bitcoin and cybersecurity to share knowledge, exchange ideas, and collaborate on innovative solutions.In response to Amir Taaki's announcement, Mike Hearn confirmed his attendance at the event, having booked flights to Berlin. Both Taaki and Hearn were looking forward to participating in this gathering of like-minded individuals who were passionate about Bitcoin and committed to addressing the security issues associated with it.For more information about the Bitcoin hackathon, including specific details and schedules, interested individuals could visit the website http://bitcoin-hackathon.com/ provided in the email. This website would serve as a comprehensive resource for participants and those seeking further knowledge about the event. 2012-06-22T06:39:24+00:00 + Amir Taaki, a member of the Bitcoin-development mailing list, announced on June 22, 2012, the occurrence of a Bitcoin hackathon event in Berlin. He expressed his willingness to provide hosting space for the event if required. The purpose of the hackathon was to discuss the evolving security and threat landscape in today's digital world, and to explore ways in which IT managers can effectively respond to these challenges.Discussions at the hackathon encompassed various topics such as endpoint security, mobile security, and the latest developments in malware threats. This event aimed to bring together experts and enthusiasts in the field of Bitcoin and cybersecurity to share knowledge, exchange ideas, and collaborate on innovative solutions.In response to Amir Taaki's announcement, Mike Hearn confirmed his attendance at the event, having booked flights to Berlin. Both Taaki and Hearn were looking forward to participating in this gathering of like-minded individuals who were passionate about Bitcoin and committed to addressing the security issues associated with it.For more information about the Bitcoin hackathon, including specific details and schedules, interested individuals could visit the website http://bitcoin-hackathon.com/ provided in the email. This website would serve as a comprehensive resource for participants and those seeking further knowledge about the event. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Bootstrapping-full-nodes-post-pruning.xml b/static/bitcoin-dev/June_2012/combined_Bootstrapping-full-nodes-post-pruning.xml index c86af7c9a2..a842ef6595 100644 --- a/static/bitcoin-dev/June_2012/combined_Bootstrapping-full-nodes-post-pruning.xml +++ b/static/bitcoin-dev/June_2012/combined_Bootstrapping-full-nodes-post-pruning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bootstrapping full nodes post-pruning - 2023-08-01T03:34:40.031544+00:00 + 2025-10-11T22:12:56.205019+00:00 + python-feedgen Mike Hearn 2012-06-11 20:48:36+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Bootstrapping full nodes post-pruning - 2023-08-01T03:34:40.031544+00:00 + 2025-10-11T22:12:56.205179+00:00 - The discussion revolves around the use of BerkeleyDB (BDB) in Bitcoin and concerns regarding its inter-version compatibility and lack of space efficiency. It is mentioned that BDB files are not deterministic, which poses a problem for read-only pruned indexes. There is a suggestion to swap out BDB for LevelDB, but uncertainty remains about how deterministic LevelDB is.In 2012, Mike Hearn expressed concerns about introducing unauditable single source material, as it would require users to trust developers without any means to audit the software. He suggests a deterministic process to produce archival chains and introducing commitments to them in the blockchain. This way, a client doing a reverse header sync would encounter a commitment for an archival chain they have and would stop syncing and use the archival chain for points before that. This approach allows for auditable software distribution.The discussion also addresses the issue of bootstrapping newly installed nodes for Bitcoin. Three options are suggested: having special archival nodes that never prune, shipping a post-pruning block chain and transaction index with client downloads, or a combination of both approaches. Some individuals, like Greg, are not in favor of shipping pre-indexed files due to the absence of indexing overhead, but it speeds up the startup process for new users. The goal is to find a solution that balances the benefits and drawbacks of each approach to ensure easy bootstrapping of new nodes. 2012-06-11T20:48:36+00:00 + The discussion revolves around the use of BerkeleyDB (BDB) in Bitcoin and concerns regarding its inter-version compatibility and lack of space efficiency. It is mentioned that BDB files are not deterministic, which poses a problem for read-only pruned indexes. There is a suggestion to swap out BDB for LevelDB, but uncertainty remains about how deterministic LevelDB is.In 2012, Mike Hearn expressed concerns about introducing unauditable single source material, as it would require users to trust developers without any means to audit the software. He suggests a deterministic process to produce archival chains and introducing commitments to them in the blockchain. This way, a client doing a reverse header sync would encounter a commitment for an archival chain they have and would stop syncing and use the archival chain for points before that. This approach allows for auditable software distribution.The discussion also addresses the issue of bootstrapping newly installed nodes for Bitcoin. Three options are suggested: having special archival nodes that never prune, shipping a post-pruning block chain and transaction index with client downloads, or a combination of both approaches. Some individuals, like Greg, are not in favor of shipping pre-indexed files due to the absence of indexing overhead, but it speeds up the startup process for new users. The goal is to find a solution that balances the benefits and drawbacks of each approach to ensure easy bootstrapping of new nodes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Defeating-the-block-withholding-attack.xml b/static/bitcoin-dev/June_2012/combined_Defeating-the-block-withholding-attack.xml index ec2c7fb1f1..92f688e81d 100644 --- a/static/bitcoin-dev/June_2012/combined_Defeating-the-block-withholding-attack.xml +++ b/static/bitcoin-dev/June_2012/combined_Defeating-the-block-withholding-attack.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Defeating the block withholding attack - 2023-08-01T03:34:04.944188+00:00 + 2025-10-11T22:13:15.318696+00:00 + python-feedgen Luke-Jr 2012-06-05 01:05:18+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Defeating the block withholding attack - 2023-08-01T03:34:04.944188+00:00 + 2025-10-11T22:13:15.318880+00:00 - In an email exchange between Mike Koss and Luke-Jr in 2012, Koss seeks clarification on how Luke-Jr's proposal would work for decentralized pools and what the new block header would look like. The proposed block header includes various components such as the block version number, hash of the previous block, share difficulty, timestamp, current target in compact format, and nonce. To earn a share, the final bits of the block header must be zero. For a block to be valid and added to the blockchain, the hash of the block header, concatenated with a valid share candidate for the next block header, must hash to a value less than the current target offset against the share difficulty. Koss also asks about the meaning of "NextBlockCandidate," which refers to the fact that a share becomes a block only after a subsequent share is found that combined hashes to meet the real difficulty.Koss expresses his understanding that in a mining pool attack, the attacker gets compensated for the shares they earn, but the pool will be denied any valid blocks found. However, the attacker does not have access to the Bitcoins earned in the unreported block. With decentralized pools, the attacker has access to the block and can potentially submit it to the Bitcoin network directly bypassing the pool if it benefits them to do so. This raises concerns about potential profit for the attacker. Koss believes that the only way to detect such an attack now is to look for "unlucky" miners, but this is not foolproof as attackers can create multiple fake identities. Koss suggests a solution where a secret part of a block is shared with the pool, which is used in a secondary hash. However, this solution only works for centralized pools and is not suitable for decentralized ones.The email thread discusses the possibility of an attack on a mining pool, where the attacker earns shares but denies the pool any valid blocks found. Detecting such an attack is challenging, and the proposal for fixing this issue involves creating a scheme where miners can detect a qualifying hash to earn a share but cannot determine if the hash is for a valid block. However, implementing this solution would require a major change to the block structure, which may not be justified since attackers do not have direct monetary gain from this attack. The asymmetric payoff for an attacker depends on the pool's reward scheme, and they can potentially use this attack to harm the pool's "luck factor" and bribe users away. It is suggested that planning for a solution should be done 1-2 years in advance to allow users to upgrade before any severe problems arise.In another discussion, Peter Vessenes suggests that the worthiness of attacking a blockchain pool depends on the pool's reward scheme. While attackers may receive bonus earnings or benefit from harming the pool, waiting until there is real pain caused by these attacks could result in a painful fork of the blockchain. Vessenes recommends planning for a solution well in advance to avoid such issues. Additionally, attackers could hurt the pool's "luck factor" and spend the bitcoins earned to bribe users away from the targeted pool.The potential attack on mining pools involves withholding valid blocks that could harm a pool's profitability. The effectiveness of this attack depends on the ratio of the attacker's hashrate to the rest of the pool. However, there is uncertainty regarding the economics of this attack and whether it would be more profitable for an attacker to spend their hashes attacking rather than just mining. It is suggested that forking the blockchain should only be considered if there is evidence of real pain caused by these attacks. The attack signature mentioned by one member is not a significant factor since only the pool that controls the merkle will benefit from block submission. Actual estimates of the potential impact of this attack are requested.A proposed solution to address the vulnerability of all pools to an attacker withholding shares is to accept blocks at a lower difficulty if they are submitted with a candidate for the next block and meet specific hashing requirements. This solution would create a hard-fork in the blockchain, but existing miners should work unmodified. Poolservers would need to adapt significantly. However, it is unlikely that rule changes would gain sufficient acceptance among the Bitcoin community due to centralized pools' potential harm to network security. 2012-06-05T01:05:18+00:00 + In an email exchange between Mike Koss and Luke-Jr in 2012, Koss seeks clarification on how Luke-Jr's proposal would work for decentralized pools and what the new block header would look like. The proposed block header includes various components such as the block version number, hash of the previous block, share difficulty, timestamp, current target in compact format, and nonce. To earn a share, the final bits of the block header must be zero. For a block to be valid and added to the blockchain, the hash of the block header, concatenated with a valid share candidate for the next block header, must hash to a value less than the current target offset against the share difficulty. Koss also asks about the meaning of "NextBlockCandidate," which refers to the fact that a share becomes a block only after a subsequent share is found that combined hashes to meet the real difficulty.Koss expresses his understanding that in a mining pool attack, the attacker gets compensated for the shares they earn, but the pool will be denied any valid blocks found. However, the attacker does not have access to the Bitcoins earned in the unreported block. With decentralized pools, the attacker has access to the block and can potentially submit it to the Bitcoin network directly bypassing the pool if it benefits them to do so. This raises concerns about potential profit for the attacker. Koss believes that the only way to detect such an attack now is to look for "unlucky" miners, but this is not foolproof as attackers can create multiple fake identities. Koss suggests a solution where a secret part of a block is shared with the pool, which is used in a secondary hash. However, this solution only works for centralized pools and is not suitable for decentralized ones.The email thread discusses the possibility of an attack on a mining pool, where the attacker earns shares but denies the pool any valid blocks found. Detecting such an attack is challenging, and the proposal for fixing this issue involves creating a scheme where miners can detect a qualifying hash to earn a share but cannot determine if the hash is for a valid block. However, implementing this solution would require a major change to the block structure, which may not be justified since attackers do not have direct monetary gain from this attack. The asymmetric payoff for an attacker depends on the pool's reward scheme, and they can potentially use this attack to harm the pool's "luck factor" and bribe users away. It is suggested that planning for a solution should be done 1-2 years in advance to allow users to upgrade before any severe problems arise.In another discussion, Peter Vessenes suggests that the worthiness of attacking a blockchain pool depends on the pool's reward scheme. While attackers may receive bonus earnings or benefit from harming the pool, waiting until there is real pain caused by these attacks could result in a painful fork of the blockchain. Vessenes recommends planning for a solution well in advance to avoid such issues. Additionally, attackers could hurt the pool's "luck factor" and spend the bitcoins earned to bribe users away from the targeted pool.The potential attack on mining pools involves withholding valid blocks that could harm a pool's profitability. The effectiveness of this attack depends on the ratio of the attacker's hashrate to the rest of the pool. However, there is uncertainty regarding the economics of this attack and whether it would be more profitable for an attacker to spend their hashes attacking rather than just mining. It is suggested that forking the blockchain should only be considered if there is evidence of real pain caused by these attacks. The attack signature mentioned by one member is not a significant factor since only the pool that controls the merkle will benefit from block submission. Actual estimates of the potential impact of this attack are requested.A proposed solution to address the vulnerability of all pools to an attacker withholding shares is to accept blocks at a lower difficulty if they are submitted with a candidate for the next block and meet specific hashing requirements. This solution would create a hard-fork in the blockchain, but existing miners should work unmodified. Poolservers would need to adapt significantly. However, it is unlikely that rule changes would gain sufficient acceptance among the Bitcoin community due to centralized pools' potential harm to network security. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Enforcing-inflation-rules-for-SPV-clients.xml b/static/bitcoin-dev/June_2012/combined_Enforcing-inflation-rules-for-SPV-clients.xml index b964e718a0..56406c8c0f 100644 --- a/static/bitcoin-dev/June_2012/combined_Enforcing-inflation-rules-for-SPV-clients.xml +++ b/static/bitcoin-dev/June_2012/combined_Enforcing-inflation-rules-for-SPV-clients.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Enforcing inflation rules for SPV clients - 2023-08-01T03:43:30.612754+00:00 + 2025-10-11T22:12:54.076111+00:00 + python-feedgen Daniel Lidstrom 2012-06-25 23:21:14+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Enforcing inflation rules for SPV clients - 2023-08-01T03:43:30.612754+00:00 + 2025-10-11T22:12:54.076256+00:00 - The conversation between Mike and Daniel focuses on various aspects of the Bitcoin system, including potential conspiracies involving bad or hacked client developers and miners. They discuss how the official Bitcoin client addresses this issue through its gitian system, which involves multiple developers compiling the same source to the same binary and signing the results. This helps prevent the release of hacked clients. The conversation also highlights the importance of lightweight clients being able to audit the coinbase transaction and the difficulty of calculating fees without all input transactions being available.To address these challenges, the conversation suggests compartmentalizing errors to make them individually cheaper to verify. This could involve requiring error messages to be received by a quorum of peers before checking and dropping unreliable peers. Hashcash could also be used to balance costs to send and verify a given type of error message. Additionally, SPV clients could subscribe to announcements of invalid blocks and their specific failure mode to keep rule enforcement decentralized while scaling Bitcoin.The conversation acknowledges that mobile clients may struggle with verifying coinbase transaction invalidity, especially if the block size limit is lifted. To overcome this, they propose splitting up the summing of spendable fees into verifiable pieces and including them in a new Merkle tree. Verifying a claim of invalidity of one of these leaves would require downloading about 1MB of transaction data and verifying inclusion, which could still be manageable for a smartphone at large transaction volumes.The conversation also touches on the topics of block size and centralization. One person expresses uncertainty about whether larger blocks would lead to centralization, as it would take significant changes in transaction usage to reach gigabyte-sized blocks. They speculate that technology will have improved enough by that time to mitigate any concerns. The conversation notes that this topic has been debated before and may be further discussed at a future meetup.In another part of the conversation, a proposal made by Daniel is discussed. The proposal involves good nodes broadcasting announcements when they detect a rule violation, along with a proof of the violation. Mike Hearn mentions that he had also proposed a similar idea on the same mailing list and elaborated on it in an IRC chat. The use of proofs would ensure that nodes doing validation without personally witnessing the complete history of Bitcoin still have strong security. This proposal aligns with Satoshi's comment about information being easy to spread but hard to stifle.The conversation also addresses the possibility of miners conspiring to raise inflation, which could be problematic if most economic actors use SPV clients. It is noted that checking the coinbase of a transaction is not possible without knowing the fees in the block, which requires all input transactions. To resolve this issue, Daniel proposes having good nodes broadcast announcements when they detect a rule-breaker, along with a proof. The SPV client would then verify the split, download the necessary transactions and merkle branches, and check the fee, apply the inflation formula, and validate the coinbase value. Mechanisms are discussed to recover from accidentally accepting invalid blocks, such as creating a system where miners who have contributed to the pool's proof-of-work are allocated verification work. Proofs of invalidity are also suggested to circulate.Overall, the conversation emphasizes the importance of trust models, decentralization, and auditing in ensuring the integrity of the Bitcoin system. Various proposals and solutions are discussed to address potential vulnerabilities and challenges in the system. 2012-06-25T23:21:14+00:00 + The conversation between Mike and Daniel focuses on various aspects of the Bitcoin system, including potential conspiracies involving bad or hacked client developers and miners. They discuss how the official Bitcoin client addresses this issue through its gitian system, which involves multiple developers compiling the same source to the same binary and signing the results. This helps prevent the release of hacked clients. The conversation also highlights the importance of lightweight clients being able to audit the coinbase transaction and the difficulty of calculating fees without all input transactions being available.To address these challenges, the conversation suggests compartmentalizing errors to make them individually cheaper to verify. This could involve requiring error messages to be received by a quorum of peers before checking and dropping unreliable peers. Hashcash could also be used to balance costs to send and verify a given type of error message. Additionally, SPV clients could subscribe to announcements of invalid blocks and their specific failure mode to keep rule enforcement decentralized while scaling Bitcoin.The conversation acknowledges that mobile clients may struggle with verifying coinbase transaction invalidity, especially if the block size limit is lifted. To overcome this, they propose splitting up the summing of spendable fees into verifiable pieces and including them in a new Merkle tree. Verifying a claim of invalidity of one of these leaves would require downloading about 1MB of transaction data and verifying inclusion, which could still be manageable for a smartphone at large transaction volumes.The conversation also touches on the topics of block size and centralization. One person expresses uncertainty about whether larger blocks would lead to centralization, as it would take significant changes in transaction usage to reach gigabyte-sized blocks. They speculate that technology will have improved enough by that time to mitigate any concerns. The conversation notes that this topic has been debated before and may be further discussed at a future meetup.In another part of the conversation, a proposal made by Daniel is discussed. The proposal involves good nodes broadcasting announcements when they detect a rule violation, along with a proof of the violation. Mike Hearn mentions that he had also proposed a similar idea on the same mailing list and elaborated on it in an IRC chat. The use of proofs would ensure that nodes doing validation without personally witnessing the complete history of Bitcoin still have strong security. This proposal aligns with Satoshi's comment about information being easy to spread but hard to stifle.The conversation also addresses the possibility of miners conspiring to raise inflation, which could be problematic if most economic actors use SPV clients. It is noted that checking the coinbase of a transaction is not possible without knowing the fees in the block, which requires all input transactions. To resolve this issue, Daniel proposes having good nodes broadcast announcements when they detect a rule-breaker, along with a proof. The SPV client would then verify the split, download the necessary transactions and merkle branches, and check the fee, apply the inflation formula, and validate the coinbase value. Mechanisms are discussed to recover from accidentally accepting invalid blocks, such as creating a system where miners who have contributed to the pool's proof-of-work are allocated verification work. Proofs of invalidity are also suggested to circulate.Overall, the conversation emphasizes the importance of trust models, decentralization, and auditing in ensuring the integrity of the Bitcoin system. Various proposals and solutions are discussed to address potential vulnerabilities and challenges in the system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Full-Clients-in-the-future-Blockchain-management.xml b/static/bitcoin-dev/June_2012/combined_Full-Clients-in-the-future-Blockchain-management.xml index 6b27d446a0..1816497803 100644 --- a/static/bitcoin-dev/June_2012/combined_Full-Clients-in-the-future-Blockchain-management.xml +++ b/static/bitcoin-dev/June_2012/combined_Full-Clients-in-the-future-Blockchain-management.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Full Clients in the future - Blockchain management - 2023-08-01T03:33:33.227597+00:00 + 2025-10-11T22:13:04.700036+00:00 + python-feedgen Mike Hearn 2012-06-03 14:17:42+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Full Clients in the future - Blockchain management - 2023-08-01T03:33:33.227597+00:00 + 2025-10-11T22:13:04.700201+00:00 - The writer discusses the challenges of storing transactions in a blockchain, particularly when it comes to scaling down to smaller devices. While the current approach used by Satoshi is sensible, it requires storing all chain headers in RAM, which may not be feasible for devices with limited memory. BitcoinJ avoids this problem but introduces other issues by avoiding the use of a database engine, which can impact performance on older phones. The goal is to find a solution that works for both small and large devices without compromising efficiency.In light of a poor code decision, the developer of Armory's blockchain utilities is planning to upgrade the system and wants to do it "right" this time. They are seeking input from other developers who will eventually have to deal with similar challenges. However, the developer is concerned about the feasibility of holding transaction files or pointers in RAM in the future, as even this could overwhelm standard RAM sizes. Without blockchain compression, the most viable solution would likely be complex.One proposed solution involves storing all transactions as 10-byte "file-references" in a multimap indexed by the first 6 bytes of the tx-hash. This allows for better trade-offs compared to storing all 32 bytes, but if there are billions of transactions in the blockchain, each node would require around 48 GB of RAM to track all the data. The developer is unsure if mmap() is the right solution for this issue and is looking for alternative ways to manage a multi-terabyte blockchain if storing references to each transaction becomes too burdensome for available RAM.The developer believes that blockchain compression will become more widespread in the future, but acknowledges that not everyone shares this belief. Some users and developers may want to maintain everything under all circumstances. Therefore, the developer is open to serious proposals on how to address this issue and find a suitable solution for managing a large blockchain. 2012-06-03T14:17:42+00:00 + The writer discusses the challenges of storing transactions in a blockchain, particularly when it comes to scaling down to smaller devices. While the current approach used by Satoshi is sensible, it requires storing all chain headers in RAM, which may not be feasible for devices with limited memory. BitcoinJ avoids this problem but introduces other issues by avoiding the use of a database engine, which can impact performance on older phones. The goal is to find a solution that works for both small and large devices without compromising efficiency.In light of a poor code decision, the developer of Armory's blockchain utilities is planning to upgrade the system and wants to do it "right" this time. They are seeking input from other developers who will eventually have to deal with similar challenges. However, the developer is concerned about the feasibility of holding transaction files or pointers in RAM in the future, as even this could overwhelm standard RAM sizes. Without blockchain compression, the most viable solution would likely be complex.One proposed solution involves storing all transactions as 10-byte "file-references" in a multimap indexed by the first 6 bytes of the tx-hash. This allows for better trade-offs compared to storing all 32 bytes, but if there are billions of transactions in the blockchain, each node would require around 48 GB of RAM to track all the data. The developer is unsure if mmap() is the right solution for this issue and is looking for alternative ways to manage a multi-terabyte blockchain if storing references to each transaction becomes too burdensome for available RAM.The developer believes that blockchain compression will become more widespread in the future, but acknowledges that not everyone shares this belief. Some users and developers may want to maintain everything under all circumstances. Therefore, the developer is open to serious proposals on how to address this issue and find a suitable solution for managing a large blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_LevelDB-benchmarking.xml b/static/bitcoin-dev/June_2012/combined_LevelDB-benchmarking.xml index b9590a5a6c..4669383657 100644 --- a/static/bitcoin-dev/June_2012/combined_LevelDB-benchmarking.xml +++ b/static/bitcoin-dev/June_2012/combined_LevelDB-benchmarking.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - LevelDB benchmarking - 2023-08-01T03:41:23.398194+00:00 + 2025-10-11T22:13:21.690566+00:00 + python-feedgen Mike Hearn 2012-07-21 18:49:54+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - LevelDB benchmarking - 2023-08-01T03:41:23.398194+00:00 + 2025-10-11T22:13:21.690786+00:00 - Stefan has completed a task related to Bitcoin's project and raised a pull request for it. The pull request can be found on Github with the URL: https://github.com/bitcoin/bitcoin/pull/1619. It is mentioned that the author of the mikehearn/bitcoin repository has added more commits to the codebase, but it is not yet ready for a pull request. Auto-migration and migration progress UI are present, but testing with empty wallets still needs to be done. The LevelDB source is checked into the main tree, and bitcoin-qt.pro has been updated to use it. However, there are some remaining tasks, such as more testing with actual wallets and updating non-Qt makefiles. The author asks for help with testing and makefile work.In a recent discussion on the #bitcoin-dev platform, it was discovered that the CTxDB::ReadOwnerTxes code has never been used in the Bitcoin codebase, even in version 0.1.5. As a result, the author plans to delete the code when they next work on the patch.Another conversation on #bitcoin-dev suggests that Satoshi's code uses ordered access/iteration in at least one place where it looks up the "owner transactions" of a tx. However, it is unclear what that code is used for and whether it is the best solution for the problem.A Bitcoin forum post discusses the issue of block propagation times. It is mentioned that the regular network lags behind p2pool in propagating new blocks by 0-60 seconds. Optimizing IO load and threading transmission verification are suggested as important improvements. Lukes preview functionality is also seen as a useful tool in this regard.In a message, someone expresses gratitude for the information that BitcoinJS uses LevelDB but points out that LevelDB was originally designed for servers and comes from BigTable. The speaker anticipates that most Bitcoin nodes on servers will continue to be HDD based for the foreseeable future. Additionally, the speaker mentions that Satoshis code uses ordered access/iteration in at least one place, but questions whether it is the best way to solve the problem.LevelDB is discussed as an ordered data structure that is good for desktop software with multiple use cases. It was written to power IndexedDB in Chrome and uses LSM trees as a database type. However, it is mentioned that LevelDB may not be ideal for Bitcoin due to its lack of ordered access and predictable characteristics. Nonetheless, it seems to work well for the Bitcoin use case. The speaker suggests lowering the file descriptor limit or combining tables into one to address any potential issues.The problem of slow block verification and propagation is discussed, and making existing nodes faster is proposed as a solution. This does not replace moving users to SPV clients. The robustness of LevelDB is uncertain, but it has an API call to repair the database. However, the lack of infrastructure poses a concern regarding reworking bitcointools to read the LevelDB Blockchain.In an email exchange, Gavin Andresen seeks decisions from colleagues on switching to LevelDB as a replacement for bdb. They discuss the benefits and drawbacks of LevelDB, including its minimalist build system and compatibility with different operating systems. They suggest including the source code in the main Bitcoin tree and linking it statically for simplicity. They also discuss possible tweaks to the database schema during migration.Mike Hearn suggests moving away from BDB and replacing it with LevelDB in an email conversation. Gavin Andresen expresses concerns about LevelDB's obscurity, newness, and compatibility guarantees. He suggests including the source code in the main Bitcoin tree and linking it statically. Other tweaks to the DB format are also discussed.Gregory Maxwell suggests running ECDSA caching on multiple cores for linear speedup. He realizes that he may have been wrong about being IO bound in a benchmark. Gavin is expected to make decisions on whether to proceed with the work, how to deal with LevelDB's minimalist build system, and how to handle any necessary tweaks to the db format.The author changes the transaction database to Google LevelDB library and performs tests comparing it with Regular BDB. The results show that LevelDB is faster, reducing the running time from 95 minutes to 50. Signature checking remains the bottleneck. 2012-07-21T18:49:54+00:00 + Stefan has completed a task related to Bitcoin's project and raised a pull request for it. The pull request can be found on Github with the URL: https://github.com/bitcoin/bitcoin/pull/1619. It is mentioned that the author of the mikehearn/bitcoin repository has added more commits to the codebase, but it is not yet ready for a pull request. Auto-migration and migration progress UI are present, but testing with empty wallets still needs to be done. The LevelDB source is checked into the main tree, and bitcoin-qt.pro has been updated to use it. However, there are some remaining tasks, such as more testing with actual wallets and updating non-Qt makefiles. The author asks for help with testing and makefile work.In a recent discussion on the #bitcoin-dev platform, it was discovered that the CTxDB::ReadOwnerTxes code has never been used in the Bitcoin codebase, even in version 0.1.5. As a result, the author plans to delete the code when they next work on the patch.Another conversation on #bitcoin-dev suggests that Satoshi's code uses ordered access/iteration in at least one place where it looks up the "owner transactions" of a tx. However, it is unclear what that code is used for and whether it is the best solution for the problem.A Bitcoin forum post discusses the issue of block propagation times. It is mentioned that the regular network lags behind p2pool in propagating new blocks by 0-60 seconds. Optimizing IO load and threading transmission verification are suggested as important improvements. Lukes preview functionality is also seen as a useful tool in this regard.In a message, someone expresses gratitude for the information that BitcoinJS uses LevelDB but points out that LevelDB was originally designed for servers and comes from BigTable. The speaker anticipates that most Bitcoin nodes on servers will continue to be HDD based for the foreseeable future. Additionally, the speaker mentions that Satoshis code uses ordered access/iteration in at least one place, but questions whether it is the best way to solve the problem.LevelDB is discussed as an ordered data structure that is good for desktop software with multiple use cases. It was written to power IndexedDB in Chrome and uses LSM trees as a database type. However, it is mentioned that LevelDB may not be ideal for Bitcoin due to its lack of ordered access and predictable characteristics. Nonetheless, it seems to work well for the Bitcoin use case. The speaker suggests lowering the file descriptor limit or combining tables into one to address any potential issues.The problem of slow block verification and propagation is discussed, and making existing nodes faster is proposed as a solution. This does not replace moving users to SPV clients. The robustness of LevelDB is uncertain, but it has an API call to repair the database. However, the lack of infrastructure poses a concern regarding reworking bitcointools to read the LevelDB Blockchain.In an email exchange, Gavin Andresen seeks decisions from colleagues on switching to LevelDB as a replacement for bdb. They discuss the benefits and drawbacks of LevelDB, including its minimalist build system and compatibility with different operating systems. They suggest including the source code in the main Bitcoin tree and linking it statically for simplicity. They also discuss possible tweaks to the database schema during migration.Mike Hearn suggests moving away from BDB and replacing it with LevelDB in an email conversation. Gavin Andresen expresses concerns about LevelDB's obscurity, newness, and compatibility guarantees. He suggests including the source code in the main Bitcoin tree and linking it statically. Other tweaks to the DB format are also discussed.Gregory Maxwell suggests running ECDSA caching on multiple cores for linear speedup. He realizes that he may have been wrong about being IO bound in a benchmark. Gavin is expected to make decisions on whether to proceed with the work, how to deal with LevelDB's minimalist build system, and how to handle any necessary tweaks to the db format.The author changes the transaction database to Google LevelDB library and performs tests comparing it with Regular BDB. The results show that LevelDB is faster, reducing the running time from 95 minutes to 50. Signature checking remains the bottleneck. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Manual-file-cleanup-on-exit-safe-coredump-backtrace-.xml b/static/bitcoin-dev/June_2012/combined_Manual-file-cleanup-on-exit-safe-coredump-backtrace-.xml index 542b63a0e0..9c3197126c 100644 --- a/static/bitcoin-dev/June_2012/combined_Manual-file-cleanup-on-exit-safe-coredump-backtrace-.xml +++ b/static/bitcoin-dev/June_2012/combined_Manual-file-cleanup-on-exit-safe-coredump-backtrace-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Manual file cleanup on exit, safe? [coredump backtrace] - 2023-08-01T03:38:38.232080+00:00 + 2025-10-11T22:13:28.061928+00:00 + python-feedgen Pieter Wuille 2012-06-15 23:11:39+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Manual file cleanup on exit, safe? [coredump backtrace] - 2023-08-01T03:38:38.232080+00:00 + 2025-10-11T22:13:28.062093+00:00 - In a discussion on June 15, 2012, a user named grarpamp expressed concern about the safety of cleaning up the blockchain hierarchy when bitcoind exits cleanly. Another user named Pieter suggested using the -detachdb argument to detach the blockchain database files from the database environment at exit. However, Pieter noted that this feature was turned off by default in version 0.6.0 to speed up the shutdown process and that only a few people would need to manually manipulate their blockchain database files.The article delves into the issue of cleaning up files and directories when the Bitcoin server exits cleanly or crashes. It warns against using the 'rm -r' command to clean up the hierarchy, which includes files such as database/, db.log, .lock, debug.log, addr.dat, and wallet.dat. Furthermore, it advises adding __db.* to the list in case bitcoind crashes. The article poses a question regarding the availability of an option to flush or roll the mentioned files on exit, allowing them to be removed or ported. Regardless of the answer, it emphasizes that bitcoind should not be dumping core.Providing specific details, the article mentions the version of Bitcoin being discussed, v0.6.2.2-unk-beta (), and the default data directory /.../.bitcoin. It also highlights an EXCEPTION: 11DbException error caused by invalid arguments while opening a database. The error message suggests that the error could be due to moving a database from one database environment to another without clearing the database LSNs or removing all of the log files from a database environment.Lastly, the article references a gdb backtrace command that can be used to obtain information about the threads and functions involved in the issue. 2012-06-15T23:11:39+00:00 + In a discussion on June 15, 2012, a user named grarpamp expressed concern about the safety of cleaning up the blockchain hierarchy when bitcoind exits cleanly. Another user named Pieter suggested using the -detachdb argument to detach the blockchain database files from the database environment at exit. However, Pieter noted that this feature was turned off by default in version 0.6.0 to speed up the shutdown process and that only a few people would need to manually manipulate their blockchain database files.The article delves into the issue of cleaning up files and directories when the Bitcoin server exits cleanly or crashes. It warns against using the 'rm -r' command to clean up the hierarchy, which includes files such as database/, db.log, .lock, debug.log, addr.dat, and wallet.dat. Furthermore, it advises adding __db.* to the list in case bitcoind crashes. The article poses a question regarding the availability of an option to flush or roll the mentioned files on exit, allowing them to be removed or ported. Regardless of the answer, it emphasizes that bitcoind should not be dumping core.Providing specific details, the article mentions the version of Bitcoin being discussed, v0.6.2.2-unk-beta (), and the default data directory /.../.bitcoin. It also highlights an EXCEPTION: 11DbException error caused by invalid arguments while opening a database. The error message suggests that the error could be due to moving a database from one database environment to another without clearing the database LSNs or removing all of the log files from a database environment.Lastly, the article references a gdb backtrace command that can be used to obtain information about the threads and functions involved in the issue. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Near-term-scalability.xml b/static/bitcoin-dev/June_2012/combined_Near-term-scalability.xml index d51ffcb2da..192da5d564 100644 --- a/static/bitcoin-dev/June_2012/combined_Near-term-scalability.xml +++ b/static/bitcoin-dev/June_2012/combined_Near-term-scalability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Near-term scalability - 2023-08-01T03:37:35.632068+00:00 + 2025-10-11T22:13:19.566966+00:00 + python-feedgen Mike Hearn 2012-06-16 07:55:55+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Near-term scalability - 2023-08-01T03:37:35.632068+00:00 + 2025-10-11T22:13:19.567138+00:00 - The participants in a discussion on Bitcoin scalability and address reuse debated various proposals to improve the functionality and accessibility of the cryptocurrency. One topic of debate was the use of fee algorithms, with a consensus that using the same algorithms as Bitcoin-Qt would prevent excessive fees and queue-jumping. The issue of address reuse was also discussed, with some concerns raised about complicating certain use cases and increasing the address index used by block explorers and lightweight client servers.In terms of scalability improvements, there was agreement that making the block size limit float would be more beneficial than setting an arbitrary threshold. However, concerns were raised about the potential centralization that could result from implementing blockchain pruning. Some participants argued that technical solutions could address this concern without changing trust requirements.To address concerns about large blocks slowing down end user syncing and wasting resources, it was suggested that Simplified Payment Verification (SPV) clients like MultiBit and Android Wallet could help. Additionally, implementing bloom filtering P2P commands could reduce excessive bandwidth usage and parse overheads for end-users.In a discussion specifically about scalability and SatoshiDice, the participants agreed that it would be desirable for senders/buyers to pay no fees. However, they acknowledged that this may eventually be necessary. Proposals were made to deprioritize rapidly-reused addresses by limiting the count of address reuses in the memory pool. Various other proposals were discussed, including grouping transactions together with their mempool dependencies and using the same fee algorithms as Bitcoin-Qt for SatoshiDice.Overall, the discussions focused on finding practical solutions to improve the functionality and accessibility of Bitcoin while also considering the potential consequences and trade-offs. The goal was to encourage widespread adoption and competition among currencies while maintaining decentralization and low costs for operating a fully validating node. 2012-06-16T07:55:55+00:00 + The participants in a discussion on Bitcoin scalability and address reuse debated various proposals to improve the functionality and accessibility of the cryptocurrency. One topic of debate was the use of fee algorithms, with a consensus that using the same algorithms as Bitcoin-Qt would prevent excessive fees and queue-jumping. The issue of address reuse was also discussed, with some concerns raised about complicating certain use cases and increasing the address index used by block explorers and lightweight client servers.In terms of scalability improvements, there was agreement that making the block size limit float would be more beneficial than setting an arbitrary threshold. However, concerns were raised about the potential centralization that could result from implementing blockchain pruning. Some participants argued that technical solutions could address this concern without changing trust requirements.To address concerns about large blocks slowing down end user syncing and wasting resources, it was suggested that Simplified Payment Verification (SPV) clients like MultiBit and Android Wallet could help. Additionally, implementing bloom filtering P2P commands could reduce excessive bandwidth usage and parse overheads for end-users.In a discussion specifically about scalability and SatoshiDice, the participants agreed that it would be desirable for senders/buyers to pay no fees. However, they acknowledged that this may eventually be necessary. Proposals were made to deprioritize rapidly-reused addresses by limiting the count of address reuses in the memory pool. Various other proposals were discussed, including grouping transactions together with their mempool dependencies and using the same fee algorithms as Bitcoin-Qt for SatoshiDice.Overall, the discussions focused on finding practical solutions to improve the functionality and accessibility of Bitcoin while also considering the potential consequences and trade-offs. The goal was to encourage widespread adoption and competition among currencies while maintaining decentralization and low costs for operating a fully validating node. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_New-P2P-commands-for-diagnostics-SPV-clients.xml b/static/bitcoin-dev/June_2012/combined_New-P2P-commands-for-diagnostics-SPV-clients.xml index 3de45c8c06..c4026741f0 100644 --- a/static/bitcoin-dev/June_2012/combined_New-P2P-commands-for-diagnostics-SPV-clients.xml +++ b/static/bitcoin-dev/June_2012/combined_New-P2P-commands-for-diagnostics-SPV-clients.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New P2P commands for diagnostics, SPV clients - 2023-08-01T03:35:39.542593+00:00 + 2025-10-11T22:13:30.186764+00:00 + python-feedgen Mike Hearn 2012-07-24 08:16:12+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - New P2P commands for diagnostics, SPV clients - 2023-08-01T03:35:39.543591+00:00 + 2025-10-11T22:13:30.186961+00:00 - In a discussion among developers on the Bitcoin mailing list, the topic of debate is combining the 'filterinit' and 'filterload' commands. These commands are used to initialize and input a serialized bloom filter table metadata and data. One developer suggests that if the 'filteradd' command does not have a compelling use case, then 'filterinit' and 'filteradd' can be dropped. The consensus is that the 'filterload' command includes all the necessary metadata required to initialize a bloom filter. However, there is a need to specify the format of how these commands arrive, particularly when a new block is found. It is suggested that input from potential users is required to determine what information they might need.The discussion also revolves around the combination of bloom filters and Simplified Payment Verification (SPV) clients. The combination is not widely used because it allows the node using the bloom filter to scan transactions and choose how much effort it wants to put into each transaction on behalf of the SPV client. A negotiation protocol would need to be specified for this to work. Despite this potential solution, it may still be too heavy for nodes and could result in overloading. In such cases, the node could simply disconnect intensive peers or refuse new connections.Another topic of discussion is the format of distributing blocks in the blockchain network. A proposal suggests using the 'invgetdatamerkleblock' command instead of the 'invgetdatablock' command. This new command includes a "merkleblock" structure that optimizes bandwidth by not re-transmitting transactions already seen in the mempool. The proposal also introduces a new command, 'getmerkletx', which returns a merkletx message for each requested transaction. Implementing this proposal could help reduce orphan blocks and spurious chain splits.Additionally, there is a discussion about the format of a project and potential user input to determine what information is necessary. One developer suggests a three-part change, including adding the 'mempool' command, syncing up nodes' mempools on startup, and changing the "block" message format. The proposed format for the "block" message aims to speed up the block propagation process and incentivize miners to upgrade.Furthermore, the discussion touches upon the needs of lightweight clients and proposes new P2P commands with associated behavior changes. These proposed commands include 'filterinit', 'filterload', 'filterclear', 'filteradd', and 'mempool'. The 'filterload' and 'filteradd' commands enable special behavior changes for 'mempool' and existing P2P commands. A lightweight client would issue the 'filterload' command, sync up with blocks, and then use the 'mempool' command to sync up to current transactions. The 'mempool' command could also be useful as a diagnostic tool, even if a bloom filter is not applied to its output.Overall, the discussions revolve around optimizing the code, streamlining protocols, improving block propagation speed, and addressing the needs of SPV clients and lightweight clients. Proposals include combining functions, specifying formats, and introducing new commands to achieve these goals. Input from potential users is considered crucial in determining the necessary information and making informed decisions. 2012-07-24T08:16:12+00:00 + In a discussion among developers on the Bitcoin mailing list, the topic of debate is combining the 'filterinit' and 'filterload' commands. These commands are used to initialize and input a serialized bloom filter table metadata and data. One developer suggests that if the 'filteradd' command does not have a compelling use case, then 'filterinit' and 'filteradd' can be dropped. The consensus is that the 'filterload' command includes all the necessary metadata required to initialize a bloom filter. However, there is a need to specify the format of how these commands arrive, particularly when a new block is found. It is suggested that input from potential users is required to determine what information they might need.The discussion also revolves around the combination of bloom filters and Simplified Payment Verification (SPV) clients. The combination is not widely used because it allows the node using the bloom filter to scan transactions and choose how much effort it wants to put into each transaction on behalf of the SPV client. A negotiation protocol would need to be specified for this to work. Despite this potential solution, it may still be too heavy for nodes and could result in overloading. In such cases, the node could simply disconnect intensive peers or refuse new connections.Another topic of discussion is the format of distributing blocks in the blockchain network. A proposal suggests using the 'invgetdatamerkleblock' command instead of the 'invgetdatablock' command. This new command includes a "merkleblock" structure that optimizes bandwidth by not re-transmitting transactions already seen in the mempool. The proposal also introduces a new command, 'getmerkletx', which returns a merkletx message for each requested transaction. Implementing this proposal could help reduce orphan blocks and spurious chain splits.Additionally, there is a discussion about the format of a project and potential user input to determine what information is necessary. One developer suggests a three-part change, including adding the 'mempool' command, syncing up nodes' mempools on startup, and changing the "block" message format. The proposed format for the "block" message aims to speed up the block propagation process and incentivize miners to upgrade.Furthermore, the discussion touches upon the needs of lightweight clients and proposes new P2P commands with associated behavior changes. These proposed commands include 'filterinit', 'filterload', 'filterclear', 'filteradd', and 'mempool'. The 'filterload' and 'filteradd' commands enable special behavior changes for 'mempool' and existing P2P commands. A lightweight client would issue the 'filterload' command, sync up with blocks, and then use the 'mempool' command to sync up to current transactions. The 'mempool' command could also be useful as a diagnostic tool, even if a bloom filter is not applied to its output.Overall, the discussions revolve around optimizing the code, streamlining protocols, improving block propagation speed, and addressing the needs of SPV clients and lightweight clients. Proposals include combining functions, specifying formats, and introducing new commands to achieve these goals. Input from potential users is considered crucial in determining the necessary information and making informed decisions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Proposed-new-P2P-command-and-response-getcmds-cmdlist.xml b/static/bitcoin-dev/June_2012/combined_Proposed-new-P2P-command-and-response-getcmds-cmdlist.xml index 5c3488a7d9..13c32c48a4 100644 --- a/static/bitcoin-dev/June_2012/combined_Proposed-new-P2P-command-and-response-getcmds-cmdlist.xml +++ b/static/bitcoin-dev/June_2012/combined_Proposed-new-P2P-command-and-response-getcmds-cmdlist.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed new P2P command and response: getcmds, cmdlist - 2023-08-01T03:39:15.529952+00:00 + 2025-10-11T22:12:58.327546+00:00 + python-feedgen Mark Friedenbach 2012-06-18 01:27:39+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Proposed new P2P command and response: getcmds, cmdlist - 2023-08-01T03:39:15.529952+00:00 + 2025-10-11T22:12:58.327743+00:00 - The discussion revolves around the Bitcoin protocol and its implementation. The first message suggests that the BitTorrent model, with its capability-based extension system, could be a useful example for the Bitcoin protocol to follow. This could involve trying out new algorithms, adding new features, and reverting protocol changes if necessary. The problem with implementing the Bitcoin protocol is not the protocol itself, but the fact that changes to it can happen suddenly without proper consideration or reflection.The second message highlights the complexity of the current P2P protocol in Bitcoin and the challenges faced by developers maintaining non-Satoshi codebases. The lack of documentation on the wiki makes it difficult to reference and implement. The P2P protocol is already filled with magic numbers and arbitrarily versioned binary data structures, making it a potentially buggy and insecure zoo of complicated interactions. The author posits that incremental protocol versions with clear requirements could be a better solution than the current extension system.The creator and maintainer of a full reimplementation of the Bitcoin protocol has stated that although the Bitcoin protocol is simple, it is filled with arbitrary endianness and magic numbers. The problem lies not in implementing the protocol, but in once having created a codebase, wanting to perfect and fine-tune the design. Changes to the Bitcoin protocol are more damaging than any issues with the current protocol. Although the author agrees with changes, they should be more conservative and have a longer time frame. Changes usually get added to the Satoshi client abruptly, which results in a week spent working to implement the change without proper consideration or reflection, compromising on design choices to remain compatible with the protocol. Despite this, the creator does not intend to slow down progress and tries to hedge against conservatism.Jeff Garzik responded to the above message and pointed out that for anyone maintaining a non-Satoshi codebase, the P2P protocol is already filled with all sorts of magic numbers, arbitrarily versioned binary data structures, and an unfriendly zoo of complicated and potentially buggy interactions. There is scant documentation on the wiki, making the Satoshi source code the only true reference. In comparison to other protocols, Bitcoin's P2P protocol is backwards, fragile, limited, and inflexible when it comes to parameter/extension exchange and negotiation. Jeff called the current P2P protocol "simple," but he believes that calling it so belies all the implementation details you absolutely must get right to run on mainnet today.In an email conversation, Jeff Garzik discusses the present version of Bitcoin’s peer-to-peer (P2P) protocol. While it is easy to make a protocol change and increase PROTOCOL_VERSION in the Satoshi client, other non-Satoshi codebases face difficulties since the P2P protocol already has numerous magic numbers, binary data structures, and complex interactions that are difficult to understand without complete documentation. In contrast to modern protocols like HTTP and JSON, bitcoin’s P2P protocol is fragile, inflexible, and outdated when it comes to parameter/extension exchange and negotiation. Garzik calls it a “zoo of complicated and potentially buggy interactions” with scarce, incomplete documentation, which makes it hard for other non-Satoshi codebase maintainers to work on the same. He further explains how even iSCSI, implemented on hard drive firmware, has the ability to exchange key=value parameters between local and remote sides of the Remote Procedure Call (RPC) connection.In this email conversation, Wladimir proposes standardizing the functionality of thin and thick clients without explicitly enumerating everything over the protocol. However, Andy expresses concern that the spectrum of clients will be more diverse than just "thin" or "thick." He suggests making a field that can hold more than just a bit with each value representing a specific set of features. Alternatively, they could enumerate the features instead of defining a specific set of feature-version mapping. Andy believes too much emphasis is being placed on defining a specific set of feature-version mapping, which makes it hard for future clients to implement some features but not all. He also notes that there is no easy way for a node to tell another that it doesn't have the whole blockchain available, so requesting it from it will fail. Wladimir agrees that the interaction between protocol versions and capabilities needs to be defined as well. Both agree that a capability system may be a good idea, but the granularity should be large, not command-level. They also note that the arguments might have changed between protocol versions, so offering "getdata" at protocol version 10 does not necessarily mean the same as offering it at protocol version 11. Finally, they agree that having a system for finding out what peers support makes it far easier to discover peer capabilities.A developer is concerned about the potential for Bitcoin's P2P protocol to become complex and vulnerable. They suggest being cautious about making changes unless absolutely necessary. Another developer points out that increasing complexity is typical during a system's initial development, but it eventually becomes standardized and cruft can be 2012-06-18T01:27:39+00:00 + The discussion revolves around the Bitcoin protocol and its implementation. The first message suggests that the BitTorrent model, with its capability-based extension system, could be a useful example for the Bitcoin protocol to follow. This could involve trying out new algorithms, adding new features, and reverting protocol changes if necessary. The problem with implementing the Bitcoin protocol is not the protocol itself, but the fact that changes to it can happen suddenly without proper consideration or reflection.The second message highlights the complexity of the current P2P protocol in Bitcoin and the challenges faced by developers maintaining non-Satoshi codebases. The lack of documentation on the wiki makes it difficult to reference and implement. The P2P protocol is already filled with magic numbers and arbitrarily versioned binary data structures, making it a potentially buggy and insecure zoo of complicated interactions. The author posits that incremental protocol versions with clear requirements could be a better solution than the current extension system.The creator and maintainer of a full reimplementation of the Bitcoin protocol has stated that although the Bitcoin protocol is simple, it is filled with arbitrary endianness and magic numbers. The problem lies not in implementing the protocol, but in once having created a codebase, wanting to perfect and fine-tune the design. Changes to the Bitcoin protocol are more damaging than any issues with the current protocol. Although the author agrees with changes, they should be more conservative and have a longer time frame. Changes usually get added to the Satoshi client abruptly, which results in a week spent working to implement the change without proper consideration or reflection, compromising on design choices to remain compatible with the protocol. Despite this, the creator does not intend to slow down progress and tries to hedge against conservatism.Jeff Garzik responded to the above message and pointed out that for anyone maintaining a non-Satoshi codebase, the P2P protocol is already filled with all sorts of magic numbers, arbitrarily versioned binary data structures, and an unfriendly zoo of complicated and potentially buggy interactions. There is scant documentation on the wiki, making the Satoshi source code the only true reference. In comparison to other protocols, Bitcoin's P2P protocol is backwards, fragile, limited, and inflexible when it comes to parameter/extension exchange and negotiation. Jeff called the current P2P protocol "simple," but he believes that calling it so belies all the implementation details you absolutely must get right to run on mainnet today.In an email conversation, Jeff Garzik discusses the present version of Bitcoin’s peer-to-peer (P2P) protocol. While it is easy to make a protocol change and increase PROTOCOL_VERSION in the Satoshi client, other non-Satoshi codebases face difficulties since the P2P protocol already has numerous magic numbers, binary data structures, and complex interactions that are difficult to understand without complete documentation. In contrast to modern protocols like HTTP and JSON, bitcoin’s P2P protocol is fragile, inflexible, and outdated when it comes to parameter/extension exchange and negotiation. Garzik calls it a “zoo of complicated and potentially buggy interactions” with scarce, incomplete documentation, which makes it hard for other non-Satoshi codebase maintainers to work on the same. He further explains how even iSCSI, implemented on hard drive firmware, has the ability to exchange key=value parameters between local and remote sides of the Remote Procedure Call (RPC) connection.In this email conversation, Wladimir proposes standardizing the functionality of thin and thick clients without explicitly enumerating everything over the protocol. However, Andy expresses concern that the spectrum of clients will be more diverse than just "thin" or "thick." He suggests making a field that can hold more than just a bit with each value representing a specific set of features. Alternatively, they could enumerate the features instead of defining a specific set of feature-version mapping. Andy believes too much emphasis is being placed on defining a specific set of feature-version mapping, which makes it hard for future clients to implement some features but not all. He also notes that there is no easy way for a node to tell another that it doesn't have the whole blockchain available, so requesting it from it will fail. Wladimir agrees that the interaction between protocol versions and capabilities needs to be defined as well. Both agree that a capability system may be a good idea, but the granularity should be large, not command-level. They also note that the arguments might have changed between protocol versions, so offering "getdata" at protocol version 10 does not necessarily mean the same as offering it at protocol version 11. Finally, they agree that having a system for finding out what peers support makes it far easier to discover peer capabilities.A developer is concerned about the potential for Bitcoin's P2P protocol to become complex and vulnerable. They suggest being cautious about making changes unless absolutely necessary. Another developer points out that increasing complexity is typical during a system's initial development, but it eventually becomes standardized and cruft can be - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_RPC-and-signals-processing-priority.xml b/static/bitcoin-dev/June_2012/combined_RPC-and-signals-processing-priority.xml index 18c42316c6..448680e312 100644 --- a/static/bitcoin-dev/June_2012/combined_RPC-and-signals-processing-priority.xml +++ b/static/bitcoin-dev/June_2012/combined_RPC-and-signals-processing-priority.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RPC and signals - processing priority - 2023-08-01T03:38:22.419850+00:00 + 2025-10-11T22:13:06.823266+00:00 + python-feedgen Wladimir 2012-06-16 07:04:34+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - RPC and signals - processing priority - 2023-08-01T03:38:22.419850+00:00 + 2025-10-11T22:13:06.823433+00:00 - In a forum post from 2012, a user named grarpamp raised an issue with the bitcoind software not responding to certain rpc queries and signals. They proposed that the program should check and process all user interrupts once per block while handling the chain in the background. However, another user named Wladimir provided a response clarifying that this issue is not related to priority or user interrupts, but rather to the locks on the wallet and client. According to Wladimir, each RPC command takes both locks and releases them only when finished. The shutting down process also requires both locks, resulting in serialized operations. This locking mechanism is implemented to protect the database and critical data structures. Although there may be scenarios where the locks are not necessary or read/write locks could be used for better concurrency, caution must be exercised in making such changes.The writer of this context is facing difficulties with the bitcoind software, which is not responding to various rpc queries and signals. They have noted that these actions are being recorded in the debug log, but they do not occur as expected. As a solution, the writer suggests that the software should incorporate a check and processing of all user interrupts once per block while simultaneously handling the chain in the background. Additionally, the writer expresses curiosity about how busy commerce servers handle this poor rpc handling and wonders if there is a way to increase the priority of user scheduled tasks. Overall, the writer seeks an explanation for the issues with the bitcoind software and possible solutions or workarounds. 2012-06-16T07:04:34+00:00 + In a forum post from 2012, a user named grarpamp raised an issue with the bitcoind software not responding to certain rpc queries and signals. They proposed that the program should check and process all user interrupts once per block while handling the chain in the background. However, another user named Wladimir provided a response clarifying that this issue is not related to priority or user interrupts, but rather to the locks on the wallet and client. According to Wladimir, each RPC command takes both locks and releases them only when finished. The shutting down process also requires both locks, resulting in serialized operations. This locking mechanism is implemented to protect the database and critical data structures. Although there may be scenarios where the locks are not necessary or read/write locks could be used for better concurrency, caution must be exercised in making such changes.The writer of this context is facing difficulties with the bitcoind software, which is not responding to various rpc queries and signals. They have noted that these actions are being recorded in the debug log, but they do not occur as expected. As a solution, the writer suggests that the software should incorporate a check and processing of all user interrupts once per block while simultaneously handling the chain in the background. Additionally, the writer expresses curiosity about how busy commerce servers handle this poor rpc handling and wonders if there is a way to increase the priority of user scheduled tasks. Overall, the writer seeks an explanation for the issues with the bitcoind software and possible solutions or workarounds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Raw-Transaction-RPC-calls-for-bitcoind.xml b/static/bitcoin-dev/June_2012/combined_Raw-Transaction-RPC-calls-for-bitcoind.xml index fd6e3c0c52..59816a9d38 100644 --- a/static/bitcoin-dev/June_2012/combined_Raw-Transaction-RPC-calls-for-bitcoind.xml +++ b/static/bitcoin-dev/June_2012/combined_Raw-Transaction-RPC-calls-for-bitcoind.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Raw Transaction RPC calls for bitcoind - 2023-08-01T03:36:54.750439+00:00 + 2025-10-11T22:13:25.939290+00:00 + python-feedgen Gavin Andresen 2012-06-14 20:00:57+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Raw Transaction RPC calls for bitcoind - 2023-08-01T03:36:54.750439+00:00 + 2025-10-11T22:13:25.939446+00:00 - On June 14th, 2012, Peter Vessenes emailed Gavin Andresen with a request to add a feature that would allow private keys to be provided at the command line with the signature, effectively turning the client into a wallet-less signature machine. Andresen agreed with the idea and suggested adding a third argument to support an array of private keys. This would enable the client to sign using only the given private key(s) and ignore the bitcoind wallet. The private keys would only remain in bitcoind memory for the duration of the RPC call.Peter subsequently submitted a feature request to allow private keys to be provided at the command line with the signature, enabling the client to function as a wallet-less signature machine. Meanwhile, Gavin Andresen has already submitted a pull request for an API implementation of low-level "raw" transactions. He is seeking feedback on the API and assistance in testing it.The key new method introduced in the pull request is the signrawtx method. It takes a raw transaction, signs as many inputs as possible, and returns the modified raw transaction with signatures. This API is primarily intended for people developing services on top of bitcoind rather than for command line usage. It is important to include appropriate transaction fees when using the sendrawtx method; otherwise, it is likely to fail. For more detailed information, the design document, pull request, and test plan can be found at the following links: - Design doc: https://gist.github.com/2839617- Pull request: https://github.com/bitcoin/bitcoin/pull/1456- Test plan: https://secure.bettermeans.com/projects/4180/wiki/Raw_Transaction_RPC_Test_PlanAdditionally, a list of all new RPC calls, along with their help output and example usage, is available. These include:- listunspent [minconf=1] [maxconf=999999]- getrawtx- createrawtx [["txid",n],...] {address:amount,...}- signrawtx [,...]- sendrawtx 2012-06-14T20:00:57+00:00 + On June 14th, 2012, Peter Vessenes emailed Gavin Andresen with a request to add a feature that would allow private keys to be provided at the command line with the signature, effectively turning the client into a wallet-less signature machine. Andresen agreed with the idea and suggested adding a third argument to support an array of private keys. This would enable the client to sign using only the given private key(s) and ignore the bitcoind wallet. The private keys would only remain in bitcoind memory for the duration of the RPC call.Peter subsequently submitted a feature request to allow private keys to be provided at the command line with the signature, enabling the client to function as a wallet-less signature machine. Meanwhile, Gavin Andresen has already submitted a pull request for an API implementation of low-level "raw" transactions. He is seeking feedback on the API and assistance in testing it.The key new method introduced in the pull request is the signrawtx method. It takes a raw transaction, signs as many inputs as possible, and returns the modified raw transaction with signatures. This API is primarily intended for people developing services on top of bitcoind rather than for command line usage. It is important to include appropriate transaction fees when using the sendrawtx method; otherwise, it is likely to fail. For more detailed information, the design document, pull request, and test plan can be found at the following links: - Design doc: https://gist.github.com/2839617- Pull request: https://github.com/bitcoin/bitcoin/pull/1456- Test plan: https://secure.bettermeans.com/projects/4180/wiki/Raw_Transaction_RPC_Test_PlanAdditionally, a list of all new RPC calls, along with their help output and example usage, is available. These include:- listunspent [minconf=1] [maxconf=999999]- getrawtx- createrawtx [["txid",n],...] {address:amount,...}- signrawtx [,...]- sendrawtx - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_SatoshiDice-and-Near-term-scalability.xml b/static/bitcoin-dev/June_2012/combined_SatoshiDice-and-Near-term-scalability.xml index 298fe7d521..cebd12893d 100644 --- a/static/bitcoin-dev/June_2012/combined_SatoshiDice-and-Near-term-scalability.xml +++ b/static/bitcoin-dev/June_2012/combined_SatoshiDice-and-Near-term-scalability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SatoshiDice and Near-term scalability - 2023-08-01T03:38:09.852343+00:00 + 2025-10-11T22:13:08.947399+00:00 + python-feedgen Mike Hearn 2012-06-16 08:30:30+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - SatoshiDice and Near-term scalability - 2023-08-01T03:38:09.852343+00:00 + 2025-10-11T22:13:08.947533+00:00 - Joseph, the operator of SatoshiDice, has expressed a willingness to cooperate and not harm the Bitcoin network. It has been proposed that instead of asking him to stop attaching small fees to every transaction, bitcoinj should be fixed to have smarter fee codes. The issue of SatoshiDice and its impact on Bitcoin's scalability was raised by Jeff Garzik. However, no data was presented to indicate whether SatoshiDice was shutting out other traffic. Jonathan Warren regularly measures mainnet confirmation times and noted that fee-paying transactions now take longer to confirm than before. In June 2012, Jeff Garzik brought up concerns about Bitcoin's scalability in relation to SatoshiDice. He suggested that a hard fork should only be considered if there was evidence that SatoshiDice was preventing other traffic. To support his suggestion, he asked if anyone measured confirmation times for "normal tx" on the mainnet regularly. Jonathan Warren responded with a graph showing confirmation times for transactions on the mainnet, indicating that fee-paying transactions now take longer to confirm. No action was taken as a result of this discussion.Jonathan Warren, known as Atheros on Bitcointalk, regularly measures mainnet confirmation times. He posted a chart of transaction confirmation times from June 2012, showing that fee-paying transactions used to confirm faster. Jeff Garzik raised the issue of SatoshiDice and scalability in an email to the bitcoin-development mailing list. He mentioned that a hard fork would require significant community buy-in, as older clients would not accept blocks larger than 1MB. Garzik asked for regular measurement of mainnet "normal tx" confirmation times and requested any other hard data available.The discussion focuses on the block size limit and its potential impact on Bitcoin. There are concerns about the block size being exhausted despite many transactions in the memory pool, leading to delays in confirming low priority transactions. SatoshiDice's ability to pay 0.0005 BTC fees and fill up the memory pool exacerbates the issue. It is suggested that prioritization needs to be smarter or the average actual block size should increase. Changing the block size limit is considered a hard fork measure that requires significant community buy-in. Before making any changes, hard data is needed to show whether SatoshiDice is shutting out other network traffic. Regular measurement of mainnet "normal tx" confirmation times is proposed to quantify the situation.In an email conversation between Jeff Garzik and Stefan Thomas on June 15, 2012, they discussed the possibility of changing the block size limit. Garzik mentioned that this would require a high level of community buy-in since it would exclude older clients that do not accept blocks larger than 1MB. Increasing the block size limit in the short term is unlikely due to its perceived impact. Garzik requested solid data indicating whether SatoshiDice was shutting out most of the network traffic, as significant changes would require justification. He acknowledged that while SatoshiDice is a heavy user of the network, there is a distinction between a stress test and a flood that excludes non-SatoshiDice users. Therefore, Garzik asked for quantification of the situation. 2012-06-16T08:30:30+00:00 + Joseph, the operator of SatoshiDice, has expressed a willingness to cooperate and not harm the Bitcoin network. It has been proposed that instead of asking him to stop attaching small fees to every transaction, bitcoinj should be fixed to have smarter fee codes. The issue of SatoshiDice and its impact on Bitcoin's scalability was raised by Jeff Garzik. However, no data was presented to indicate whether SatoshiDice was shutting out other traffic. Jonathan Warren regularly measures mainnet confirmation times and noted that fee-paying transactions now take longer to confirm than before. In June 2012, Jeff Garzik brought up concerns about Bitcoin's scalability in relation to SatoshiDice. He suggested that a hard fork should only be considered if there was evidence that SatoshiDice was preventing other traffic. To support his suggestion, he asked if anyone measured confirmation times for "normal tx" on the mainnet regularly. Jonathan Warren responded with a graph showing confirmation times for transactions on the mainnet, indicating that fee-paying transactions now take longer to confirm. No action was taken as a result of this discussion.Jonathan Warren, known as Atheros on Bitcointalk, regularly measures mainnet confirmation times. He posted a chart of transaction confirmation times from June 2012, showing that fee-paying transactions used to confirm faster. Jeff Garzik raised the issue of SatoshiDice and scalability in an email to the bitcoin-development mailing list. He mentioned that a hard fork would require significant community buy-in, as older clients would not accept blocks larger than 1MB. Garzik asked for regular measurement of mainnet "normal tx" confirmation times and requested any other hard data available.The discussion focuses on the block size limit and its potential impact on Bitcoin. There are concerns about the block size being exhausted despite many transactions in the memory pool, leading to delays in confirming low priority transactions. SatoshiDice's ability to pay 0.0005 BTC fees and fill up the memory pool exacerbates the issue. It is suggested that prioritization needs to be smarter or the average actual block size should increase. Changing the block size limit is considered a hard fork measure that requires significant community buy-in. Before making any changes, hard data is needed to show whether SatoshiDice is shutting out other network traffic. Regular measurement of mainnet "normal tx" confirmation times is proposed to quantify the situation.In an email conversation between Jeff Garzik and Stefan Thomas on June 15, 2012, they discussed the possibility of changing the block size limit. Garzik mentioned that this would require a high level of community buy-in since it would exclude older clients that do not accept blocks larger than 1MB. Increasing the block size limit in the short term is unlikely due to its perceived impact. Garzik requested solid data indicating whether SatoshiDice was shutting out most of the network traffic, as significant changes would require justification. He acknowledged that while SatoshiDice is a heavy user of the network, there is a distinction between a stress test and a flood that excludes non-SatoshiDice users. Therefore, Garzik asked for quantification of the situation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Suggestion-for-Simplifying-development-work.xml b/static/bitcoin-dev/June_2012/combined_Suggestion-for-Simplifying-development-work.xml index 6e3959c2a6..032776e2a9 100644 --- a/static/bitcoin-dev/June_2012/combined_Suggestion-for-Simplifying-development-work.xml +++ b/static/bitcoin-dev/June_2012/combined_Suggestion-for-Simplifying-development-work.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Suggestion for Simplifying development work - 2023-08-01T03:37:45.969242+00:00 + 2025-10-11T22:13:23.815049+00:00 + python-feedgen Wladimir 2012-06-15 15:59:02+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Suggestion for Simplifying development work - 2023-08-01T03:37:45.969242+00:00 + 2025-10-11T22:13:23.815195+00:00 - On June 15, 2012, Peter Vessenes, the CEO of CoinLab, proposed the idea of removing the GUI from the Satoshi client and implementing data requests as RPC calls instead. The goal behind this suggestion was to enable forking QT and other GUIs and simplify the codebase. However, it was noted that the current RPC calls were not sufficient to implement a fully-featured and responsive UI. Wladimir, a member of the community, questioned the need for splitting the project, emphasizing that the UI plays a crucial role in driving requirements on the core. Therefore, he argued that the UI should remain a first-class citizen. Despite this, Peter J. Vessenes sought input and thoughts from others in the community regarding this proposal. He believed that removing the GUI and implementing data requests as RPC calls could potentially speed up development and bring significant benefits.For more details, you can refer to the following link: [Link1](https://bitcointalk.org/index.php?topic=915875.msg10183092#msg10183092) 2012-06-15T15:59:02+00:00 + On June 15, 2012, Peter Vessenes, the CEO of CoinLab, proposed the idea of removing the GUI from the Satoshi client and implementing data requests as RPC calls instead. The goal behind this suggestion was to enable forking QT and other GUIs and simplify the codebase. However, it was noted that the current RPC calls were not sufficient to implement a fully-featured and responsive UI. Wladimir, a member of the community, questioned the need for splitting the project, emphasizing that the UI plays a crucial role in driving requirements on the core. Therefore, he argued that the UI should remain a first-class citizen. Despite this, Peter J. Vessenes sought input and thoughts from others in the community regarding this proposal. He believed that removing the GUI and implementing data requests as RPC calls could potentially speed up development and bring significant benefits.For more details, you can refer to the following link: [Link1](https://bitcointalk.org/index.php?topic=915875.msg10183092#msg10183092) - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Tor-hidden-service-support.xml b/static/bitcoin-dev/June_2012/combined_Tor-hidden-service-support.xml index b36d639655..6a733f7b00 100644 --- a/static/bitcoin-dev/June_2012/combined_Tor-hidden-service-support.xml +++ b/static/bitcoin-dev/June_2012/combined_Tor-hidden-service-support.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Tor hidden service support - 2023-08-01T03:44:02.492397+00:00 + 2025-10-11T22:13:11.070262+00:00 + python-feedgen grarpamp 2012-06-27 19:51:08+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Tor hidden service support - 2023-08-01T03:44:02.492397+00:00 + 2025-10-11T22:13:11.070446+00:00 - The discussion revolves around the possibility of incorporating tor binaries into bitcoin software to automatically create a Tor Hidden Service for users. However, it is assumed that the bitcoin user has already taken care of this aspect. The conversation also touches upon the use of IPv6 addresses and why not use .onion addresses directly. It is suggested that using IPv6 addresses is simpler than managing onions, i2p's, etc. throughout the code and private bitcoin p2p mesh.While the use of onioncat, GarliCat, or Phantom may not conflict with bitcoin's use of IPv6 mapping, configuring bitcoin to use Tor or I2P proxy ports may seem odd when one can dump the IPv6 traffic to the OS stack after setting up the *Cat shims and Phantom. It is important to note that onioncat is not used in bitcoin, and the connections are regular Tor hidden service connections, not the more risky and low-performance IP in TCP onioncat connections.Although there have been some nodes with onion:8333 and possibly some on I2P prior to this work, they could only be used as -connect or -addnode seeds with additional host setup. Therefore, the incorporation of tor binaries within the bitcoin software would provide a simpler and complete solution.In June 2012, Pieter Wuille discussed exchanging and relaying addresses via the P2P network using the fd87:d87e:eb43::/48 IPv6 range. Andy Parkins suggested using bits from the addr.services to store address families such as AF_INET, AF_INET6, AF_CUSTOM_TOR, and leaving space for a few more. These address families would only use four bits out of the mostly unused 64 bits.In an email exchange on June 26, 2012, grarpamp proposed including the block of the Phantom project for people who use overlay networks that are routable but use private space. There was also a suggestion to add blocks to the IsRoutable check. It was noted that while these blocks may not be expected to be routable, people may still have interfaces, routing tables, and packet filters on their machines configured with up to all three of those networks for specific purposes.The hidden service support in Bitcoin uses a compatible IPv6 mapping with Onioncat, but it is important to clarify that it is not Onioncat, does not use Onioncat, does not need Onioncat, and would not benefit from Onioncat. The Onioncat style advertisement is used because the protocol already relays IPv6 addresses. The connections are regular Tor hidden service connections, not the more risky and low performance IP in TCP onioncat connections.The Phantom project has reused the fd87:d87e:eb43::/48 IPv6 range to map each address in an 80-bit range to an onion address and treat it as belonging to a separate network. This network range is the same as used by the OnionCat application but is not utilized in any way. Other clients can use the test case 5wyqrzbvrdsumnok.onion == FD87:D87E:EB43:edb1:8e4:3588:e546:35ca, which involves decoding the base32 onion address and storing the resulting 80 bits of data as the low-order bits of an IPv6 address, prefixed by fd87:d87e:eb43:. Since this range is not routable, there should be no compatibility issues.Furthermore, the Phantom project has provided blocks for other similar projects, including fd00:2522:3493::/48 and fd60:db4d:ddb5::/48 for garlicat on I2P. While these blocks are not expected to be routable, some people may have interfaces, routing tables, and packet filters on their machines configured with up to all three networks for specific purposes.The Bitcoin Core team has merged Tor hidden service support in mainline, allowing users to run a hidden service bitcoin node and connect to other bitcoin hidden services via a Tor proxy. This feature is expected to be included in the 0.7 release. Each address in the fd87:d87e:eb43::/48 IPv6 range is mapped to an onion address and treated as belonging to a separate network. Other clients wishing to implement similar functionality can use the test case 5wyqrzbvrdsumnok.onion == FD87:D87E:EB43:edb1:8e4:3588:e546:35ca. The conversion simply involves decoding the base32 onion address and storing the resulting 80 bits of data as the low-order bits of an IPv6 address, prefixed by fd87:d87e:eb43:. This range is part of the RFC4193 Unique Local IPv6 range, which is normally not globally routable. 2012-06-27T19:51:08+00:00 + The discussion revolves around the possibility of incorporating tor binaries into bitcoin software to automatically create a Tor Hidden Service for users. However, it is assumed that the bitcoin user has already taken care of this aspect. The conversation also touches upon the use of IPv6 addresses and why not use .onion addresses directly. It is suggested that using IPv6 addresses is simpler than managing onions, i2p's, etc. throughout the code and private bitcoin p2p mesh.While the use of onioncat, GarliCat, or Phantom may not conflict with bitcoin's use of IPv6 mapping, configuring bitcoin to use Tor or I2P proxy ports may seem odd when one can dump the IPv6 traffic to the OS stack after setting up the *Cat shims and Phantom. It is important to note that onioncat is not used in bitcoin, and the connections are regular Tor hidden service connections, not the more risky and low-performance IP in TCP onioncat connections.Although there have been some nodes with onion:8333 and possibly some on I2P prior to this work, they could only be used as -connect or -addnode seeds with additional host setup. Therefore, the incorporation of tor binaries within the bitcoin software would provide a simpler and complete solution.In June 2012, Pieter Wuille discussed exchanging and relaying addresses via the P2P network using the fd87:d87e:eb43::/48 IPv6 range. Andy Parkins suggested using bits from the addr.services to store address families such as AF_INET, AF_INET6, AF_CUSTOM_TOR, and leaving space for a few more. These address families would only use four bits out of the mostly unused 64 bits.In an email exchange on June 26, 2012, grarpamp proposed including the block of the Phantom project for people who use overlay networks that are routable but use private space. There was also a suggestion to add blocks to the IsRoutable check. It was noted that while these blocks may not be expected to be routable, people may still have interfaces, routing tables, and packet filters on their machines configured with up to all three of those networks for specific purposes.The hidden service support in Bitcoin uses a compatible IPv6 mapping with Onioncat, but it is important to clarify that it is not Onioncat, does not use Onioncat, does not need Onioncat, and would not benefit from Onioncat. The Onioncat style advertisement is used because the protocol already relays IPv6 addresses. The connections are regular Tor hidden service connections, not the more risky and low performance IP in TCP onioncat connections.The Phantom project has reused the fd87:d87e:eb43::/48 IPv6 range to map each address in an 80-bit range to an onion address and treat it as belonging to a separate network. This network range is the same as used by the OnionCat application but is not utilized in any way. Other clients can use the test case 5wyqrzbvrdsumnok.onion == FD87:D87E:EB43:edb1:8e4:3588:e546:35ca, which involves decoding the base32 onion address and storing the resulting 80 bits of data as the low-order bits of an IPv6 address, prefixed by fd87:d87e:eb43:. Since this range is not routable, there should be no compatibility issues.Furthermore, the Phantom project has provided blocks for other similar projects, including fd00:2522:3493::/48 and fd60:db4d:ddb5::/48 for garlicat on I2P. While these blocks are not expected to be routable, some people may have interfaces, routing tables, and packet filters on their machines configured with up to all three networks for specific purposes.The Bitcoin Core team has merged Tor hidden service support in mainline, allowing users to run a hidden service bitcoin node and connect to other bitcoin hidden services via a Tor proxy. This feature is expected to be included in the 0.7 release. Each address in the fd87:d87e:eb43::/48 IPv6 range is mapped to an onion address and treated as belonging to a separate network. Other clients wishing to implement similar functionality can use the test case 5wyqrzbvrdsumnok.onion == FD87:D87E:EB43:edb1:8e4:3588:e546:35ca. The conversion simply involves decoding the base32 onion address and storing the resulting 80 bits of data as the low-order bits of an IPv6 address, prefixed by fd87:d87e:eb43:. This range is part of the RFC4193 Unique Local IPv6 range, which is normally not globally routable. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Ultimate-Blockchain-Compression-w-trust-free-lite-node.xml b/static/bitcoin-dev/June_2012/combined_Ultimate-Blockchain-Compression-w-trust-free-lite-node.xml index d93b7925a1..74978598f6 100644 --- a/static/bitcoin-dev/June_2012/combined_Ultimate-Blockchain-Compression-w-trust-free-lite-node.xml +++ b/static/bitcoin-dev/June_2012/combined_Ultimate-Blockchain-Compression-w-trust-free-lite-node.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ultimate Blockchain Compression w/ trust-free lite node - 2023-08-01T03:42:33.712756+00:00 + 2025-10-11T22:12:51.950300+00:00 + python-feedgen Gregory Maxwell 2012-06-21 22:02:27+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Ultimate Blockchain Compression w/ trust-free lite node - 2023-08-01T03:42:33.712756+00:00 + 2025-10-11T22:12:51.950517+00:00 - In a conversation between Mike Koss and an unknown individual, the topic of discussion was pruning spent transactions from an old block and commitments to the state of unspent transactions. The goal was to enable memoryless nodes to fully validate without trust and initialize new pruned nodes securely without exposing them to the old chain history. This would require adopting a new data structure for managing trees of unspent transactions in a secure, scalable, and DOS resistant manner.The discussion began with the question of whether it made sense to adopt a more complex data structure than the Merkle tree for the Bitcoin protocol. The Merkle tree allows replacing unneeded transactions by their hash and possibly a whole subtree if they fall within a common node of the tree. However, if a lite client only cares about retaining a single transaction in a block, it would only need O(log2(T)) Merkle hashes plus the transaction it cares about.There was a debate on whether a raw trie structure or a PATRICIA tree/trie would be ideal for this purpose. A trie has a deterministic structure and constant time access to elements, but a malicious actor could exploit it by constructing unbalanced segments. Self-balancing search trees like red-black trees or 2-3-4 trees don't suffer from this problem, but they may still have implementation errors.Alan Reiner suggested that a PATRICIA tree/trie would be ideal due to its deterministic structure and increased space efficiency. However, satisfactory implementations of this structure were hard to find. Mark Friedenbach argued that tries are dependent on the distribution of input data for balancing, and a malicious actor could exploit this. Peter Todd pointed out that any trie structure is dependent on the distribution of input data for balancing and suggested looking into Judy structures.In another discussion about app developers updating their RB tree code, Gregory Maxwell emphasized the importance of comprehensive tests and a well-specified algorithm to prevent disagreements in implementation. Alan Reiner expressed concern about different implementations due to the infinite ways of constructing a binary tree, leading to different root hashes. Maxwell suggested using a trie configuration which is history-independent and has only one way to construct the tree given an unspent-TxOut list.On June 19, 2012, Alan Reiner raised concerns about an app developer updating their RB tree code, causing disagreements in the correct root hash. He emphasized the importance of comprehensive tests and a well-specified algorithm to prevent disruptive issues. Reiner suggested that a PATRICIA tree/trie would have been ideal for this situation due to its completely deterministic structure.In a forum thread, the issue of using a tree-structure with multiple valid configurations for the same set of unspent-TxOuts was raised. Using a binary tree or red-black tree could result in significant portions of the network disagreeing on the correct root. A raw trie structure would solve these issues but may not be space-efficient. A PATRICIA tree/trie would be ideal as it has a deterministic structure and is more space-efficient, although it is not a trivial implementation.Andrew Miller proposed that any recursive data structure can be 'Merkle-ized' by adding a hash of the child node alongside each link/pointer. This allows verification of data for each node as the structure is traversed. The storage burden can be delegated to an untrusted helper server, making it easier for a lite-client to insert and rebalance its tree.In a discussion about Merkle trees, Peter Todd suggested discarding vertexes that cause the tree to become unbalanced and setting a depth of imbalance to prevent this. Andrew Miller proposed a simpler solution for balancing binary search trees, such as AVL trees or Red-Black trees. Miller also mentioned that any recursive data structure can be 'Merkle-ized', allowing verification of data for each node while traversing the structure. The storage burden can be delegated to an untrusted helper server as long as the lite-client knows the root hash.Overall, the discussion revolved around finding the best data structure for managing trees of unspent transactions in a secure and scalable manner. Various options were considered, including raw trie structures and PATRICIA tree/tries. The importance of comprehensive tests and well-specified algorithms was emphasized to avoid disagreements in implementation. Additionally, the concept of 'Merkle-izing' recursive data structures was discussed as a way to verify data integrity while traversing the structure. 2012-06-21T22:02:27+00:00 + In a conversation between Mike Koss and an unknown individual, the topic of discussion was pruning spent transactions from an old block and commitments to the state of unspent transactions. The goal was to enable memoryless nodes to fully validate without trust and initialize new pruned nodes securely without exposing them to the old chain history. This would require adopting a new data structure for managing trees of unspent transactions in a secure, scalable, and DOS resistant manner.The discussion began with the question of whether it made sense to adopt a more complex data structure than the Merkle tree for the Bitcoin protocol. The Merkle tree allows replacing unneeded transactions by their hash and possibly a whole subtree if they fall within a common node of the tree. However, if a lite client only cares about retaining a single transaction in a block, it would only need O(log2(T)) Merkle hashes plus the transaction it cares about.There was a debate on whether a raw trie structure or a PATRICIA tree/trie would be ideal for this purpose. A trie has a deterministic structure and constant time access to elements, but a malicious actor could exploit it by constructing unbalanced segments. Self-balancing search trees like red-black trees or 2-3-4 trees don't suffer from this problem, but they may still have implementation errors.Alan Reiner suggested that a PATRICIA tree/trie would be ideal due to its deterministic structure and increased space efficiency. However, satisfactory implementations of this structure were hard to find. Mark Friedenbach argued that tries are dependent on the distribution of input data for balancing, and a malicious actor could exploit this. Peter Todd pointed out that any trie structure is dependent on the distribution of input data for balancing and suggested looking into Judy structures.In another discussion about app developers updating their RB tree code, Gregory Maxwell emphasized the importance of comprehensive tests and a well-specified algorithm to prevent disagreements in implementation. Alan Reiner expressed concern about different implementations due to the infinite ways of constructing a binary tree, leading to different root hashes. Maxwell suggested using a trie configuration which is history-independent and has only one way to construct the tree given an unspent-TxOut list.On June 19, 2012, Alan Reiner raised concerns about an app developer updating their RB tree code, causing disagreements in the correct root hash. He emphasized the importance of comprehensive tests and a well-specified algorithm to prevent disruptive issues. Reiner suggested that a PATRICIA tree/trie would have been ideal for this situation due to its completely deterministic structure.In a forum thread, the issue of using a tree-structure with multiple valid configurations for the same set of unspent-TxOuts was raised. Using a binary tree or red-black tree could result in significant portions of the network disagreeing on the correct root. A raw trie structure would solve these issues but may not be space-efficient. A PATRICIA tree/trie would be ideal as it has a deterministic structure and is more space-efficient, although it is not a trivial implementation.Andrew Miller proposed that any recursive data structure can be 'Merkle-ized' by adding a hash of the child node alongside each link/pointer. This allows verification of data for each node as the structure is traversed. The storage burden can be delegated to an untrusted helper server, making it easier for a lite-client to insert and rebalance its tree.In a discussion about Merkle trees, Peter Todd suggested discarding vertexes that cause the tree to become unbalanced and setting a depth of imbalance to prevent this. Andrew Miller proposed a simpler solution for balancing binary search trees, such as AVL trees or Red-Black trees. Miller also mentioned that any recursive data structure can be 'Merkle-ized', allowing verification of data for each node while traversing the structure. The storage burden can be delegated to an untrusted helper server as long as the lite-client knows the root hash.Overall, the discussion revolved around finding the best data structure for managing trees of unspent transactions in a secure and scalable manner. Various options were considered, including raw trie structures and PATRICIA tree/tries. The importance of comprehensive tests and well-specified algorithms was emphasized to avoid disagreements in implementation. Additionally, the concept of 'Merkle-izing' recursive data structures was discussed as a way to verify data integrity while traversing the structure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Ultimate-Blockchain-Compression-w-trust-free-lite-nodes.xml b/static/bitcoin-dev/June_2012/combined_Ultimate-Blockchain-Compression-w-trust-free-lite-nodes.xml index 468a6ffcb3..7189633c25 100644 --- a/static/bitcoin-dev/June_2012/combined_Ultimate-Blockchain-Compression-w-trust-free-lite-nodes.xml +++ b/static/bitcoin-dev/June_2012/combined_Ultimate-Blockchain-Compression-w-trust-free-lite-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ultimate Blockchain Compression w/ trust-free lite nodes - 2023-08-01T03:40:47.804443+00:00 + 2025-10-11T22:13:02.575094+00:00 + python-feedgen Peter Todd 2012-06-18 10:14:41+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Ultimate Blockchain Compression w/ trust-free lite nodes - 2023-08-01T03:40:47.804443+00:00 + 2025-10-11T22:13:02.575239+00:00 - In 2012, Alberto Torres discussed a similar idea he had previously described and provided a link to his prototype. He mentioned that Gavin had left a comment on his talk page, which he hadn't seen before. Alberto believed that Armory would be the ideal client to implement this idea but wanted to wait until it could run on his laptop with 2GB of RAM. He disagreed with Peter Todd's suggestion of implementing it in the Satoshi client instead of Armory. Alberto expressed his willingness to help after summer if the implementation was still pending. He also apologized to Peter for mistakenly sending him a private message and didn't understand his concern about "unbalancing" the tree. The proposed idea required miner support, as miners typically use either the Satoshi client or custom code. Implementing it in Armory wouldn't provide an easy upgrade path for those miners. However, using the hash tree could be implemented in any client, and a significant amount of code would be shared between calculating and using it, making implementation in the Satoshi client logical.In an email exchange, Alan Reiner clarified the differences between his proposal and Alberto Torres's earlier proposal for a similar idea. Both proposals consisted of two major components: (1) the method for creating unspent-TxOut-tree roots/fingerprints for verification, and (2) using an alternate blockchain to maintain and distribute those fingerprints. While Torres proposed a different tree structure and placing the fingerprints in the main chain header, Reiner's proposal avoided a blockchain fork by utilizing a separate blockchain. This approach could be implemented without causing disruption and offered nearly the same security as changing the protocol without hard-forking. Alberto Torres had described a simpler and more efficient version of the idea on the Bitcoin Wiki page in January 2012, suggesting that Armory would be the ideal client for implementation. Peter Todd raised concerns about deliberate unbalancing of the tree by using addresses with chosen hashes. One potential solution could be to discard any new address with a hash deeper in the tree than a certain level, indicating it was likely chosen to unbalance the tree. However, this rule would only affect individuals playing games and wouldn't impact others, as the coins could still be spent using a non-pruning client to an acceptable address that can later re-spend on a pruning client.A user named DiThi expressed interest in implementing an idea for Bitcoin blockchain compression on the Bitcoin.it wiki. In response, Peter Todd commented on Alan Reiner's Bitcointalk post regarding the same topic. Reiner's proposal involved using a tree data structure to organize all unspent-TxOuts on the network. The root of the tree would communicate its "signature" between nodes, while the leaves would correspond to addresses/scripts. The data at the leaf represents a root of the unspent-TxOut list for that address/script. To maintain the security of the tree signatures, they would be included in the header of an alternate blockchain secured by merged mining. Peter Todd questioned how people could prevent intentional unbalancing of the tree using addresses with chosen hashes. He suggested a rule that discards any new address with a hash deeper in the tree than 10*log(n), indicating it was likely chosen to unbalance the tree. This rule would primarily affect individuals playing games and would not impact unrelated parties. Additionally, Todd mentioned considering a comparison function that works last bit first, considering the popularity of firstbits.In a forum post about blockchain compression, Alan Reiner proposed using a special tree data structure to organize all unspent-TxOuts on the network. The root of this tree would communicate its "signature" between nodes, while the leaves would correspond to addresses/scripts. The data at the leaf would be a root of the unspent-TxOut list for that address/script. This proposal offers the same compression as the simpler unspent-TxOut merkle tree but also allows nodes to download just the unspent-TxOut list for each address in their wallet and verify that list directly against the block headers. This enables even lightweight nodes to obtain full address information with only a small amount of downloaded data. Concerns were raised about deliberate unbalancing of the tree using addresses with chosen hashes. One suggestion was to discard any new address with a hash deeper in the tree than 10*log(n), indicating it was likely chosen to unbalance the tree. While this rule would prevent individuals playing games from spending their money, it would not affect unrelated parties. Another suggestion was to use a comparison function that works last bit first, which may be advantageous given the popularity of firstbits.In a forum post on bitcointalk.org, Alan proposed the use of a special tree data structure to organize all unspent-TxOuts on the network and communicate its "signature" between nodes without disrupting the main network. The leaves of this tree correspond to addresses/scripts, and the data at the leaf is a root of the unspent-TxOut list for 2012-06-18T10:14:41+00:00 + In 2012, Alberto Torres discussed a similar idea he had previously described and provided a link to his prototype. He mentioned that Gavin had left a comment on his talk page, which he hadn't seen before. Alberto believed that Armory would be the ideal client to implement this idea but wanted to wait until it could run on his laptop with 2GB of RAM. He disagreed with Peter Todd's suggestion of implementing it in the Satoshi client instead of Armory. Alberto expressed his willingness to help after summer if the implementation was still pending. He also apologized to Peter for mistakenly sending him a private message and didn't understand his concern about "unbalancing" the tree. The proposed idea required miner support, as miners typically use either the Satoshi client or custom code. Implementing it in Armory wouldn't provide an easy upgrade path for those miners. However, using the hash tree could be implemented in any client, and a significant amount of code would be shared between calculating and using it, making implementation in the Satoshi client logical.In an email exchange, Alan Reiner clarified the differences between his proposal and Alberto Torres's earlier proposal for a similar idea. Both proposals consisted of two major components: (1) the method for creating unspent-TxOut-tree roots/fingerprints for verification, and (2) using an alternate blockchain to maintain and distribute those fingerprints. While Torres proposed a different tree structure and placing the fingerprints in the main chain header, Reiner's proposal avoided a blockchain fork by utilizing a separate blockchain. This approach could be implemented without causing disruption and offered nearly the same security as changing the protocol without hard-forking. Alberto Torres had described a simpler and more efficient version of the idea on the Bitcoin Wiki page in January 2012, suggesting that Armory would be the ideal client for implementation. Peter Todd raised concerns about deliberate unbalancing of the tree by using addresses with chosen hashes. One potential solution could be to discard any new address with a hash deeper in the tree than a certain level, indicating it was likely chosen to unbalance the tree. However, this rule would only affect individuals playing games and wouldn't impact others, as the coins could still be spent using a non-pruning client to an acceptable address that can later re-spend on a pruning client.A user named DiThi expressed interest in implementing an idea for Bitcoin blockchain compression on the Bitcoin.it wiki. In response, Peter Todd commented on Alan Reiner's Bitcointalk post regarding the same topic. Reiner's proposal involved using a tree data structure to organize all unspent-TxOuts on the network. The root of the tree would communicate its "signature" between nodes, while the leaves would correspond to addresses/scripts. The data at the leaf represents a root of the unspent-TxOut list for that address/script. To maintain the security of the tree signatures, they would be included in the header of an alternate blockchain secured by merged mining. Peter Todd questioned how people could prevent intentional unbalancing of the tree using addresses with chosen hashes. He suggested a rule that discards any new address with a hash deeper in the tree than 10*log(n), indicating it was likely chosen to unbalance the tree. This rule would primarily affect individuals playing games and would not impact unrelated parties. Additionally, Todd mentioned considering a comparison function that works last bit first, considering the popularity of firstbits.In a forum post about blockchain compression, Alan Reiner proposed using a special tree data structure to organize all unspent-TxOuts on the network. The root of this tree would communicate its "signature" between nodes, while the leaves would correspond to addresses/scripts. The data at the leaf would be a root of the unspent-TxOut list for that address/script. This proposal offers the same compression as the simpler unspent-TxOut merkle tree but also allows nodes to download just the unspent-TxOut list for each address in their wallet and verify that list directly against the block headers. This enables even lightweight nodes to obtain full address information with only a small amount of downloaded data. Concerns were raised about deliberate unbalancing of the tree using addresses with chosen hashes. One suggestion was to discard any new address with a hash deeper in the tree than 10*log(n), indicating it was likely chosen to unbalance the tree. While this rule would prevent individuals playing games from spending their money, it would not affect unrelated parties. Another suggestion was to use a comparison function that works last bit first, which may be advantageous given the popularity of firstbits.In a forum post on bitcointalk.org, Alan proposed the use of a special tree data structure to organize all unspent-TxOuts on the network and communicate its "signature" between nodes without disrupting the main network. The leaves of this tree correspond to addresses/scripts, and the data at the leaf is a root of the unspent-TxOut list for - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2012/combined_Wallet-related-bug-.xml b/static/bitcoin-dev/June_2012/combined_Wallet-related-bug-.xml index ea9c4831ee..86ade2b4d6 100644 --- a/static/bitcoin-dev/June_2012/combined_Wallet-related-bug-.xml +++ b/static/bitcoin-dev/June_2012/combined_Wallet-related-bug-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Wallet related bug? - 2023-08-01T03:43:04.630963+00:00 + 2025-10-11T22:13:32.310545+00:00 + python-feedgen grarpamp 2012-06-23 00:10:57+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Wallet related bug? - 2023-08-01T03:43:04.630963+00:00 + 2025-10-11T22:13:32.310695+00:00 - The speaker in this context has previously made comments regarding references to the wallet version, specifically mentioning nFileVersion. Since then, they have successfully updated both the nFileVersion and the actual wallet version. However, an issue still persists where the wallet rescans the last 14,000+ blocks every time it is invoked, which seems unnecessary. The speaker cannot provide an explanation for why this occurs multiple times. To address this problem, the speaker intends to transfer the balance from their old wallets (version 10500) to a new wallet in the near future.The writer suspects that there may be a bug related to the order of operations when it comes to rescanning, wallet upgrades/imports, and the markers for the last block. They inserted an old wallet into a current blockchain and ran it in rescan mode, resulting in a message indicating an old wallet version. Subsequently, the entire chain was rescanned, with certain blockhashes and blocks that were out of range or contained invalid/nonwallet transaction IDs being added to the wallet. These transactions were already present as legitimate ones in the old logs. When running the wallet in plain mode, the new wallet version was logged and the last 20k blocks (approximately) were rescanned, potentially serving as the marker for the last use of the old wallet. In subsequent runs, the second scan was duplicated, although it did not display the message 'upgrading wallet' as it sometimes does. The writer always used the detach=1 command. They question why the last 20k blocks need to be scanned again if the entire chain has already been processed, suggesting that it should only occur once if not more. Additionally, they propose that dumping the run parameters (bitcoin.conf, cmdline) to the log would be helpful, and recommend that the log should not be automatically truncated when it becomes too large, but rather appended or rolled.In summary, the speaker has encountered an issue where the wallet rescans the last 14,000+ blocks every time it is invoked, despite having updated both the nFileVersion and the wallet version. They plan to transfer the balance from their old wallets to a new one to avoid this problem. The writer suspects a bug related to the order of operations in the context of rescanning, wallet upgrades/imports, and last block markers. They have observed duplicated scans of the last 20k blocks and question why this is necessary if the entire chain has already been processed. Additionally, they suggest including run parameters in the log and changing how the log is handled when it becomes large. 2012-06-23T00:10:57+00:00 + The speaker in this context has previously made comments regarding references to the wallet version, specifically mentioning nFileVersion. Since then, they have successfully updated both the nFileVersion and the actual wallet version. However, an issue still persists where the wallet rescans the last 14,000+ blocks every time it is invoked, which seems unnecessary. The speaker cannot provide an explanation for why this occurs multiple times. To address this problem, the speaker intends to transfer the balance from their old wallets (version 10500) to a new wallet in the near future.The writer suspects that there may be a bug related to the order of operations when it comes to rescanning, wallet upgrades/imports, and the markers for the last block. They inserted an old wallet into a current blockchain and ran it in rescan mode, resulting in a message indicating an old wallet version. Subsequently, the entire chain was rescanned, with certain blockhashes and blocks that were out of range or contained invalid/nonwallet transaction IDs being added to the wallet. These transactions were already present as legitimate ones in the old logs. When running the wallet in plain mode, the new wallet version was logged and the last 20k blocks (approximately) were rescanned, potentially serving as the marker for the last use of the old wallet. In subsequent runs, the second scan was duplicated, although it did not display the message 'upgrading wallet' as it sometimes does. The writer always used the detach=1 command. They question why the last 20k blocks need to be scanned again if the entire chain has already been processed, suggesting that it should only occur once if not more. Additionally, they propose that dumping the run parameters (bitcoin.conf, cmdline) to the log would be helpful, and recommend that the log should not be automatically truncated when it becomes too large, but rather appended or rolled.In summary, the speaker has encountered an issue where the wallet rescans the last 14,000+ blocks every time it is invoked, despite having updated both the nFileVersion and the wallet version. They plan to transfer the balance from their old wallets to a new one to avoid this problem. The writer suspects a bug related to the order of operations in the context of rescanning, wallet upgrades/imports, and last block markers. They have observed duplicated scans of the last 20k blocks and question why this is necessary if the entire chain has already been processed. Additionally, they suggest including run parameters in the log and changing how the log is handled when it becomes large. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Bitcoin-Qt-bitcoind-version-0-8-3-released.xml b/static/bitcoin-dev/June_2013/combined_Bitcoin-Qt-bitcoind-version-0-8-3-released.xml index cbc779f64c..0354a3497d 100644 --- a/static/bitcoin-dev/June_2013/combined_Bitcoin-Qt-bitcoind-version-0-8-3-released.xml +++ b/static/bitcoin-dev/June_2013/combined_Bitcoin-Qt-bitcoind-version-0-8-3-released.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin-Qt/bitcoind version 0.8.3 released - 2023-08-01T05:11:52.044859+00:00 + 2025-10-11T21:29:19.149207+00:00 + python-feedgen Pieter Wuille 2013-06-25 23:34:41+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bitcoin-Qt/bitcoind version 0.8.3 released - 2023-08-01T05:11:52.044859+00:00 + 2025-10-11T21:29:19.149402+00:00 - On June 26th, 2013, Jesus Cea noticed that the "splash" banner of Bitcoin-Qt version 0.8.3 displayed "0.8.3-BETA". Pieter explained that this was a normal occurrence and followed the pattern of previous releases until they reached version 1.0. No further details were provided in their email exchange.Gavin Andresen had announced on June 25th, 2013 that Bitcoin-Qt version 0.8.3 was now available on SourceForge. Interested users could download it from the provided link. The "splash" banner of this release also showed "0.8.3-BETA". The authenticity of the message was verified through a PGP signature.The main purpose of releasing Bitcoin-Qt version 0.8.3 was to address a denial-of-service attack that had the potential to crash nodes. To prevent a memory exhaustion attack, the new release implemented measures to truncate over-size messages. Furthermore, a regression that caused excessive rewriting of the 'peers.dat' file was fixed. Users were encouraged to report any bugs through the issue tracker on GitHub.Peter Todd was acknowledged for responsibly disclosing the vulnerability (CVE-2013-4627) and creating the fix. The software could be downloaded from SourceForge. 2013-06-25T23:34:41+00:00 + On June 26th, 2013, Jesus Cea noticed that the "splash" banner of Bitcoin-Qt version 0.8.3 displayed "0.8.3-BETA". Pieter explained that this was a normal occurrence and followed the pattern of previous releases until they reached version 1.0. No further details were provided in their email exchange.Gavin Andresen had announced on June 25th, 2013 that Bitcoin-Qt version 0.8.3 was now available on SourceForge. Interested users could download it from the provided link. The "splash" banner of this release also showed "0.8.3-BETA". The authenticity of the message was verified through a PGP signature.The main purpose of releasing Bitcoin-Qt version 0.8.3 was to address a denial-of-service attack that had the potential to crash nodes. To prevent a memory exhaustion attack, the new release implemented measures to truncate over-size messages. Furthermore, a regression that caused excessive rewriting of the 'peers.dat' file was fixed. Users were encouraged to report any bugs through the issue tracker on GitHub.Peter Todd was acknowledged for responsibly disclosing the vulnerability (CVE-2013-4627) and creating the fix. The software could be downloaded from SourceForge. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Bitcoin-addresses-opaque-or-not.xml b/static/bitcoin-dev/June_2013/combined_Bitcoin-addresses-opaque-or-not.xml index 5dbce9dae5..461bb7cfca 100644 --- a/static/bitcoin-dev/June_2013/combined_Bitcoin-addresses-opaque-or-not.xml +++ b/static/bitcoin-dev/June_2013/combined_Bitcoin-addresses-opaque-or-not.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin addresses -- opaque or not - 2023-08-01T05:08:47.129943+00:00 + 2025-10-11T21:29:12.766143+00:00 + python-feedgen Melvin Carvalho 2013-06-22 11:48:08+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Bitcoin addresses -- opaque or not - 2023-08-01T05:08:47.129943+00:00 + 2025-10-11T21:29:12.766326+00:00 - In a discussion on June 11, 2013, the nature of opaque addresses in Bitcoin was debated. Luke-Jr argued that whether an address is opaque or not depends on the context. He explained that transaction handling needs to be able to translate addresses, but URI handlers should not try to interpret them beyond their arbitrary word representation. Melvin Carvalho expressed concern about bitcoin being treated as a relative URL and emphasized the need for compatibility with other URI schemes.Luke-Jr clarified that while the wiki's explanations of how addresses work may not be relevant to most software in the Bitcoin ecosystem, they are of interest to developers working on components that interact with addresses. He mentioned that the base58 encoding for addresses is likely to change in the future to address known limitations and that the inclusion of Payment Protocol URIs is the only currently planned change. However, Luke-Jr opposed address changes until their wider implications are fully understood.The discussion thread began with Melvin Carvalho questioning the definition of opaque. Luke-Jr explained that whether an address is opaque or not depends on the context. He further stated that transaction handling implementations need to translate addresses, whereas URI handlers should not interpret the address beyond its arbitrary word representation. Melvin raised concerns about the validity of certain wiki pages if Bitcoin addresses are considered opaque. Luke-Jr clarified that the wiki provides detailed information on how addresses work, but it may not be relevant to most software in the ecosystem. He emphasized that it could be of interest to developers working on components that operate with addresses.Luke-Jr mentioned in an IRC conversation that the base58 encoding for Bitcoin addresses may change in the future to address known limitations. The only planned change at that time was the inclusion of Payment Protocol URIs. However, he cautioned software developers against assuming that addresses would remain base58 forever. In response to Melvin's query about investing in vanity addresses, Luke-Jr did not provide a clear answer.The conversation between Melvin Carvalho and Luke revolved around the meaning of "opaque" in the context of Bitcoin addresses. While Melvin argued that opaque means not being able to determine anything about the address from its characters, Luke explained that the transparency of addresses depends on their interpretation. He suggested that transaction handling software should translate addresses, but URI handlers should not interpret them beyond arbitrary words. They also discussed the accuracy of certain wiki pages related to Bitcoin addresses, with Luke noting that while the information provided may be true at the moment, it is subject to revision by newer standards. Luke further mentioned the likelihood of a future change from base58 encoding for Bitcoin addresses to address limitations, but the exact changes and timeline were not established. The only planned change at that time was the inclusion of Payment Protocol URIs. Luke advised software developers not to assume that addresses would remain base58 forever.On June 11, 2013, there was a discussion on IRC regarding the opacity of Bitcoin addresses. Melvin Carvalho defined opaque as not being able to determine anything about an address by examining its characters. However, this led to a misunderstanding, as previous discussions on IRC had argued that addresses should be considered opaque for the purposes of URI parsing and handling. Luke-Jr clarified that while addresses have well-defined specifications, keeping them independent from URIs allows for the possibility of changes in the address format without breaking or concerning URI handling code. It was emphasized that these two concerns should be dealt with separately.The debate on IRC centered around whether bitcoin addresses can be considered opaque or not. The term 'opaque' refers to not being able to determine anything about the address by examining its characters. From a human perspective, bitcoin addresses appear to be opaque since they don't reveal any specific information, such as geographical location or personal identity. However, from a code perspective, they do have a meaning, as they are composed of an "address type + hashed public key, base58 encoded." Nonetheless, it can still be argued that the value remains highly opaque. There was also a discussion regarding a possible change in base58 encoding for bitcoin addresses, but it was clarified that no changes had been made and the encoding remained the same as before. It was noted that Satoshi coined the term 'base58' and the encoding has not been altered.In the IRC conversation, there was confusion about whether bitcoin addresses are considered opaque. The term 'opaque' implies that examining the characters of an address reveals no information about it. However, the wiki page on bitcoin addresses provides information suggesting that they are not opaque, which could invalidate certain statements on the page. These include details about the length and composition of addresses, the process of creating them, the probability of mistyping, and the use of checksums. Furthermore, there may be a potential change in the base58 encoding for bitcoin addresses, highlighting the need to clarify the definition of an address and update the wiki accordingly to reflect any changes. 2013-06-22T11:48:08+00:00 + In a discussion on June 11, 2013, the nature of opaque addresses in Bitcoin was debated. Luke-Jr argued that whether an address is opaque or not depends on the context. He explained that transaction handling needs to be able to translate addresses, but URI handlers should not try to interpret them beyond their arbitrary word representation. Melvin Carvalho expressed concern about bitcoin being treated as a relative URL and emphasized the need for compatibility with other URI schemes.Luke-Jr clarified that while the wiki's explanations of how addresses work may not be relevant to most software in the Bitcoin ecosystem, they are of interest to developers working on components that interact with addresses. He mentioned that the base58 encoding for addresses is likely to change in the future to address known limitations and that the inclusion of Payment Protocol URIs is the only currently planned change. However, Luke-Jr opposed address changes until their wider implications are fully understood.The discussion thread began with Melvin Carvalho questioning the definition of opaque. Luke-Jr explained that whether an address is opaque or not depends on the context. He further stated that transaction handling implementations need to translate addresses, whereas URI handlers should not interpret the address beyond its arbitrary word representation. Melvin raised concerns about the validity of certain wiki pages if Bitcoin addresses are considered opaque. Luke-Jr clarified that the wiki provides detailed information on how addresses work, but it may not be relevant to most software in the ecosystem. He emphasized that it could be of interest to developers working on components that operate with addresses.Luke-Jr mentioned in an IRC conversation that the base58 encoding for Bitcoin addresses may change in the future to address known limitations. The only planned change at that time was the inclusion of Payment Protocol URIs. However, he cautioned software developers against assuming that addresses would remain base58 forever. In response to Melvin's query about investing in vanity addresses, Luke-Jr did not provide a clear answer.The conversation between Melvin Carvalho and Luke revolved around the meaning of "opaque" in the context of Bitcoin addresses. While Melvin argued that opaque means not being able to determine anything about the address from its characters, Luke explained that the transparency of addresses depends on their interpretation. He suggested that transaction handling software should translate addresses, but URI handlers should not interpret them beyond arbitrary words. They also discussed the accuracy of certain wiki pages related to Bitcoin addresses, with Luke noting that while the information provided may be true at the moment, it is subject to revision by newer standards. Luke further mentioned the likelihood of a future change from base58 encoding for Bitcoin addresses to address limitations, but the exact changes and timeline were not established. The only planned change at that time was the inclusion of Payment Protocol URIs. Luke advised software developers not to assume that addresses would remain base58 forever.On June 11, 2013, there was a discussion on IRC regarding the opacity of Bitcoin addresses. Melvin Carvalho defined opaque as not being able to determine anything about an address by examining its characters. However, this led to a misunderstanding, as previous discussions on IRC had argued that addresses should be considered opaque for the purposes of URI parsing and handling. Luke-Jr clarified that while addresses have well-defined specifications, keeping them independent from URIs allows for the possibility of changes in the address format without breaking or concerning URI handling code. It was emphasized that these two concerns should be dealt with separately.The debate on IRC centered around whether bitcoin addresses can be considered opaque or not. The term 'opaque' refers to not being able to determine anything about the address by examining its characters. From a human perspective, bitcoin addresses appear to be opaque since they don't reveal any specific information, such as geographical location or personal identity. However, from a code perspective, they do have a meaning, as they are composed of an "address type + hashed public key, base58 encoded." Nonetheless, it can still be argued that the value remains highly opaque. There was also a discussion regarding a possible change in base58 encoding for bitcoin addresses, but it was clarified that no changes had been made and the encoding remained the same as before. It was noted that Satoshi coined the term 'base58' and the encoding has not been altered.In the IRC conversation, there was confusion about whether bitcoin addresses are considered opaque. The term 'opaque' implies that examining the characters of an address reveals no information about it. However, the wiki page on bitcoin addresses provides information suggesting that they are not opaque, which could invalidate certain statements on the page. These include details about the length and composition of addresses, the process of creating them, the probability of mistyping, and the use of checksums. Furthermore, there may be a potential change in the base58 encoding for bitcoin addresses, highlighting the need to clarify the definition of an address and update the wiki accordingly to reflect any changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Blockchain-alternative-storage.xml b/static/bitcoin-dev/June_2013/combined_Blockchain-alternative-storage.xml index 4da7e6dd70..3544388826 100644 --- a/static/bitcoin-dev/June_2013/combined_Blockchain-alternative-storage.xml +++ b/static/bitcoin-dev/June_2013/combined_Blockchain-alternative-storage.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Blockchain alternative storage - 2023-08-01T05:06:59.365584+00:00 + 2025-10-11T21:29:40.402445+00:00 + python-feedgen Jouke Hofman 2013-06-06 08:20:50+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Blockchain alternative storage - 2023-08-01T05:06:59.366580+00:00 + 2025-10-11T21:29:40.402572+00:00 - In response to Marko Otbalkana's inquiry on the Bitcoin-development mailing list about projects related to storing the blockchain in a database, Jouke Hofman of Bitonic.nl recommended using the project bitcoin-abe. This project, available on GitHub, allows for the storage of the blockchain in a database. Additionally, there is a discussion thread about bitcoin-abe on the bitcointalk.org forum.Another project mentioned in response to Marko's inquiry is BitcoinJ, which stores parsed blocks in H2, an embedded SQL database for Java. This provides an alternative option for storing the blockchain in a database. Furthermore, Marko requested information on tools that can read the blockchain from the Satoshi client and convert it into different formats. Although not explicitly mentioned in the context, it can be inferred that both bitcoin-abe and BitcoinJ are capable of performing this task.In addition to the technical discussion, the email also included a sponsored message about ServiceNow, a cloud service that automates IT design, transition, and operations. This service offers high-level views of enterprise services through dashboards and provides a single system of record for all IT processes.Overall, the context revolves around Marko Otbalkana's inquiry about projects and tools related to storing the blockchain in a database, as well as converting it into different formats. Various options, including bitcoin-abe and BitcoinJ, were suggested, along with mention of the cloud service ServiceNow for IT automation. 2013-06-06T08:20:50+00:00 + In response to Marko Otbalkana's inquiry on the Bitcoin-development mailing list about projects related to storing the blockchain in a database, Jouke Hofman of Bitonic.nl recommended using the project bitcoin-abe. This project, available on GitHub, allows for the storage of the blockchain in a database. Additionally, there is a discussion thread about bitcoin-abe on the bitcointalk.org forum.Another project mentioned in response to Marko's inquiry is BitcoinJ, which stores parsed blocks in H2, an embedded SQL database for Java. This provides an alternative option for storing the blockchain in a database. Furthermore, Marko requested information on tools that can read the blockchain from the Satoshi client and convert it into different formats. Although not explicitly mentioned in the context, it can be inferred that both bitcoin-abe and BitcoinJ are capable of performing this task.In addition to the technical discussion, the email also included a sponsored message about ServiceNow, a cloud service that automates IT design, transition, and operations. This service offers high-level views of enterprise services through dashboards and provides a single system of record for all IT processes.Overall, the context revolves around Marko Otbalkana's inquiry about projects and tools related to storing the blockchain in a database, as well as converting it into different formats. Various options, including bitcoin-abe and BitcoinJ, were suggested, along with mention of the cloud service ServiceNow for IT automation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_CTxIn-nSequence.xml b/static/bitcoin-dev/June_2013/combined_CTxIn-nSequence.xml index 89538bd296..0a22abb5bc 100644 --- a/static/bitcoin-dev/June_2013/combined_CTxIn-nSequence.xml +++ b/static/bitcoin-dev/June_2013/combined_CTxIn-nSequence.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CTxIn::nSequence - 2023-08-01T05:11:29.222133+00:00 + 2025-10-11T21:29:23.394451+00:00 + python-feedgen Mike Hearn 2013-06-21 08:20:06+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - CTxIn::nSequence - 2023-08-01T05:11:29.222133+00:00 + 2025-10-11T21:29:23.394621+00:00 - The purpose of CTxIn::nSequence in Bitcoin is discussed in an email thread. Patrick Strateman shares a link to a Stack Exchange question that provides a thorough explanation of its function and significance. The nSequence field is a 32-bit integer that allows transactions to be sorted for processing. It can be set by the sender of a transaction and is used to prioritize transactions based on their age or other factors. The question was originally asked by Marko Otbalkana in 2013. The response on the stack exchange page explains that nSequence is used by miners to determine the order in which transactions are processed. It ensures that certain transactions can be included in the next block even if they arrive after other transactions that were broadcast earlier. The post also mentions that setting nSequence to a specific value can delay spending of a particular output until a certain time has passed. Overall, nSequence is an important tool for ensuring the correct order of transactions in the Bitcoin ecosystem. In addition to the discussion on nSequence, the email includes information about a sponsored Windows program for building apps for the Windows Store and a link to join the Bitcoin-development mailing list. However, the main focus is on understanding the purpose of CTxIn::nSequence. 2013-06-21T08:20:06+00:00 + The purpose of CTxIn::nSequence in Bitcoin is discussed in an email thread. Patrick Strateman shares a link to a Stack Exchange question that provides a thorough explanation of its function and significance. The nSequence field is a 32-bit integer that allows transactions to be sorted for processing. It can be set by the sender of a transaction and is used to prioritize transactions based on their age or other factors. The question was originally asked by Marko Otbalkana in 2013. The response on the stack exchange page explains that nSequence is used by miners to determine the order in which transactions are processed. It ensures that certain transactions can be included in the next block even if they arrive after other transactions that were broadcast earlier. The post also mentions that setting nSequence to a specific value can delay spending of a particular output until a certain time has passed. Overall, nSequence is an important tool for ensuring the correct order of transactions in the Bitcoin ecosystem. In addition to the discussion on nSequence, the email includes information about a sponsored Windows program for building apps for the Windows Store and a link to join the Bitcoin-development mailing list. However, the main focus is on understanding the purpose of CTxIn::nSequence. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Decentralizing-mining.xml b/static/bitcoin-dev/June_2013/combined_Decentralizing-mining.xml index c7190a08b5..2d716b4418 100644 --- a/static/bitcoin-dev/June_2013/combined_Decentralizing-mining.xml +++ b/static/bitcoin-dev/June_2013/combined_Decentralizing-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Decentralizing mining - 2023-08-01T05:04:22.409640+00:00 + 2025-10-11T21:29:21.270785+00:00 + python-feedgen Peter Todd 2013-06-17 17:39:42+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Decentralizing mining - 2023-08-01T05:04:22.409640+00:00 + 2025-10-11T21:29:21.270982+00:00 - The email thread discusses proposals for improving the prioritization of transactions in Bitcoin mining. One suggestion is to delay broadcasting INV messages until child transactions with higher fees are found. Another proposal is to include fee/kb information in INV advertisements sent to peers. The discussion also addresses the suboptimal way new blocks are communicated to peers and suggests prioritizing fast peers and investigating the network-wide costs of broadcasting block header + coinbase TX + TX list to opt-in miners.In a conversation between Peter Todd and Luke-Jr, they discuss the practice of using one share per second in pools, suggesting higher difficulty shares instead. They also discuss P2Pool-like solutions where only a subset of shares are sent to the pool. The importance of auditing and troubleshooting in mining operations is mentioned, as well as eliopool's ability to accept arbitrary shares and possible protocol extensions.To reduce bandwidth in mining, suggestions include sending only the block header for normal shares and randomly auditing a subset of transactions. The possibility of using higher difficulty shares that are audited is also discussed. The discussion emphasizes the need for proper prioritization and fee/kb information in INV advertisements. It is recommended to sort peer lists based on #inv-received/time for optimal flood-fill/gossip algorithms.Peter Todd's ideas for pooled mining and solo mining implementation involve making two connections - to the pool and a local bitcoind. Miners work on the subset of transactions common to both getblocktemplate and the local one. Shares that don't meet difficulty are handed over to the pool, while shares that meet difficulty are handed over to both the pool and the local bitcoind. Suggestions are made to optimize this process by handing over transaction hashes where possible. Bandwidth reduction suggestions include passing only the block header for normal shares and randomly auditing a subset of transactions.The email dated June 10, 2013, discusses the protocol work for miners, focusing on the connections between the miner, pool, and local bitcoind. The process of working on common transaction subsets and handing over shares based on difficulty is explained. Suggestions are made to reduce bandwidth by passing only the block header for normal shares and randomly auditing a subset of transactions. The intentional orphaning of slow-to-propagate blocks is also mentioned. The email discusses possible protocol extensions and the need for code to merge block templates together.The pooled-solo mining mode is introduced as a concept where miners run a local bitcoin node to construct blocks while the pool tracks shares and organizes payouts. This aims to decentralize power and protect against pool hacking. Technical requirements and possible protocol extensions are discussed.A post by Peter Todd on bitcointalk highlights the need for change in Bitcoin mining practices. Pooled-solo mining is proposed as a solution to give more power to individual miners and protect against pool hacks. The concept involves miners running a local Bitcoin node to construct blocks, while the pool handles share tracking and payouts. Todd plans to fund a developer to make this idea a reality under Keep Bitcoin Free's next project. 2013-06-17T17:39:42+00:00 + The email thread discusses proposals for improving the prioritization of transactions in Bitcoin mining. One suggestion is to delay broadcasting INV messages until child transactions with higher fees are found. Another proposal is to include fee/kb information in INV advertisements sent to peers. The discussion also addresses the suboptimal way new blocks are communicated to peers and suggests prioritizing fast peers and investigating the network-wide costs of broadcasting block header + coinbase TX + TX list to opt-in miners.In a conversation between Peter Todd and Luke-Jr, they discuss the practice of using one share per second in pools, suggesting higher difficulty shares instead. They also discuss P2Pool-like solutions where only a subset of shares are sent to the pool. The importance of auditing and troubleshooting in mining operations is mentioned, as well as eliopool's ability to accept arbitrary shares and possible protocol extensions.To reduce bandwidth in mining, suggestions include sending only the block header for normal shares and randomly auditing a subset of transactions. The possibility of using higher difficulty shares that are audited is also discussed. The discussion emphasizes the need for proper prioritization and fee/kb information in INV advertisements. It is recommended to sort peer lists based on #inv-received/time for optimal flood-fill/gossip algorithms.Peter Todd's ideas for pooled mining and solo mining implementation involve making two connections - to the pool and a local bitcoind. Miners work on the subset of transactions common to both getblocktemplate and the local one. Shares that don't meet difficulty are handed over to the pool, while shares that meet difficulty are handed over to both the pool and the local bitcoind. Suggestions are made to optimize this process by handing over transaction hashes where possible. Bandwidth reduction suggestions include passing only the block header for normal shares and randomly auditing a subset of transactions.The email dated June 10, 2013, discusses the protocol work for miners, focusing on the connections between the miner, pool, and local bitcoind. The process of working on common transaction subsets and handing over shares based on difficulty is explained. Suggestions are made to reduce bandwidth by passing only the block header for normal shares and randomly auditing a subset of transactions. The intentional orphaning of slow-to-propagate blocks is also mentioned. The email discusses possible protocol extensions and the need for code to merge block templates together.The pooled-solo mining mode is introduced as a concept where miners run a local bitcoin node to construct blocks while the pool tracks shares and organizes payouts. This aims to decentralize power and protect against pool hacking. Technical requirements and possible protocol extensions are discussed.A post by Peter Todd on bitcointalk highlights the need for change in Bitcoin mining practices. Pooled-solo mining is proposed as a solution to give more power to individual miners and protect against pool hacks. The concept involves miners running a local Bitcoin node to construct blocks, while the pool handles share tracking and payouts. Todd plans to fund a developer to make this idea a reality under Keep Bitcoin Free's next project. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Double-Spending-Fast-Payments-in-Bitcoin-due-to-Client-versions-0-8-1.xml b/static/bitcoin-dev/June_2013/combined_Double-Spending-Fast-Payments-in-Bitcoin-due-to-Client-versions-0-8-1.xml index 1ed23afba7..79f4984d6c 100644 --- a/static/bitcoin-dev/June_2013/combined_Double-Spending-Fast-Payments-in-Bitcoin-due-to-Client-versions-0-8-1.xml +++ b/static/bitcoin-dev/June_2013/combined_Double-Spending-Fast-Payments-in-Bitcoin-due-to-Client-versions-0-8-1.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1 - 2023-08-01T05:12:09.866792+00:00 + 2025-10-11T21:29:27.655815+00:00 + python-feedgen Jeff Garzik 2013-06-27 16:16:04+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1 - 2023-08-01T05:12:09.866792+00:00 + 2025-10-11T21:29:27.655967+00:00 - In a 2013 email discussion, Arthur Gervais raised concerns about the signature encoding differences between different versions of Bitcoin and the potential consequences for merchants who accept zero-confirmation transactions. However, Jeff Garzik pointed out that it is becoming harder to relay older transaction versions due to changes in P2P network node distributions. Garzik also noted that merchants who accept zero confirmation transactions are likely already aware of the risks involved and make a business decision accordingly.Gervais also discussed the issue of double-spending in Bitcoin transactions in a June 2013 email conversation. He believes that his reported problem is complementary to other issues affecting the same Bitcoin version and does not require sending the two double-spending transactions at the same time. Double-spending can still occur if the second transaction is sent minutes later, before the first has been included in a block. Gervais aims to raise awareness among merchants who accept zero-confirmation transactions, but there is concern that his focus on signature encoding differences may create misunderstanding.Furthermore, Gervais informed Bitcoin developers about a vulnerability on June 27, 2013, which could lead to a double-spending attack in fast payment scenarios. The vulnerability arises from signature encoding incompatibilities between versions 0.8.2 (or 0.8.3) and earlier versions of Bitcoin. Gregory Maxwell suggested referring to prior discussions of this transaction pattern, highlighting the unsafe nature of taking non-reversible actions on unconfirmed transactions. Gervais clarified that their reported problem is not related to fees or dust and that the two double-spending transactions do not need to be sent simultaneously.It is worth noting that the Bitcoin community has already discussed this transaction pattern in prior discussions. This type of pattern is considered unsafe and is advised against by most of the Bitcoin community resources. The vulnerability can be achieved through means other than changes in the IsStandard rule, such as concurrent announcements where conflicting transactions are announced simultaneously to multiple nodes.In summary, a vulnerability has been discovered in Bitcoin that could potentially lead to double-spending attacks in fast payment scenarios. This vulnerability is caused by signature encoding incompatibilities between versions 0.8.2 and earlier versions of Bitcoin. Researchers have provided a detailed description of the vulnerability, and Bitcoin developers have been informed about it. Efforts are underway to address this vulnerability and mitigate its potential risks. 2013-06-27T16:16:04+00:00 + In a 2013 email discussion, Arthur Gervais raised concerns about the signature encoding differences between different versions of Bitcoin and the potential consequences for merchants who accept zero-confirmation transactions. However, Jeff Garzik pointed out that it is becoming harder to relay older transaction versions due to changes in P2P network node distributions. Garzik also noted that merchants who accept zero confirmation transactions are likely already aware of the risks involved and make a business decision accordingly.Gervais also discussed the issue of double-spending in Bitcoin transactions in a June 2013 email conversation. He believes that his reported problem is complementary to other issues affecting the same Bitcoin version and does not require sending the two double-spending transactions at the same time. Double-spending can still occur if the second transaction is sent minutes later, before the first has been included in a block. Gervais aims to raise awareness among merchants who accept zero-confirmation transactions, but there is concern that his focus on signature encoding differences may create misunderstanding.Furthermore, Gervais informed Bitcoin developers about a vulnerability on June 27, 2013, which could lead to a double-spending attack in fast payment scenarios. The vulnerability arises from signature encoding incompatibilities between versions 0.8.2 (or 0.8.3) and earlier versions of Bitcoin. Gregory Maxwell suggested referring to prior discussions of this transaction pattern, highlighting the unsafe nature of taking non-reversible actions on unconfirmed transactions. Gervais clarified that their reported problem is not related to fees or dust and that the two double-spending transactions do not need to be sent simultaneously.It is worth noting that the Bitcoin community has already discussed this transaction pattern in prior discussions. This type of pattern is considered unsafe and is advised against by most of the Bitcoin community resources. The vulnerability can be achieved through means other than changes in the IsStandard rule, such as concurrent announcements where conflicting transactions are announced simultaneously to multiple nodes.In summary, a vulnerability has been discovered in Bitcoin that could potentially lead to double-spending attacks in fast payment scenarios. This vulnerability is caused by signature encoding incompatibilities between versions 0.8.2 and earlier versions of Bitcoin. Researchers have provided a detailed description of the vulnerability, and Bitcoin developers have been informed about it. Efforts are underway to address this vulnerability and mitigate its potential risks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Implementing-batch-processing-for-blocknotify.xml b/static/bitcoin-dev/June_2013/combined_Implementing-batch-processing-for-blocknotify.xml index 825302792d..63ea40b08e 100644 --- a/static/bitcoin-dev/June_2013/combined_Implementing-batch-processing-for-blocknotify.xml +++ b/static/bitcoin-dev/June_2013/combined_Implementing-batch-processing-for-blocknotify.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Implementing batch processing for -blocknotify - 2023-08-01T05:03:45.193163+00:00 + 2025-10-11T21:29:31.904980+00:00 + python-feedgen Rune Kjær Svendsen 2013-06-01 13:12:32+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Implementing batch processing for -blocknotify - 2023-08-01T05:03:45.193163+00:00 + 2025-10-11T21:29:31.905147+00:00 - In a discussion about high-speed notifications, Wladimir suggests using zmq and shares a pull request to integrate it into bitcoind. Chris Double, who has already integrated zmq for block notifications in bitcoin and alt coins, expresses interest in trying it out. Rune decides to go with the Unix socket method and expresses a desire to learn more about Unix sockets.On June 1, 2013, Wladimir suggests that using ZMQ would be ideal for high-speed notifications. He shares a pull request to integrate ZMQ directly into Bitcoind, eliminating the need for the -blocknotify flag. Chris, who has experience integrating ZMQ, offers to test the patch in the pull request.In a discussion on the Bitcoin-development mailing list, Chris mentions that he uses zmq for queuing outside of bitcoind to receive notifications. Wladimir suggests integrating zmq directly into bitcoind through a pull request on Github. Other members of the thread agree with Chris's approach of queuing outside of bitcoind. The thread also includes an advertisement for AppDynamics Lite, a free troubleshooting tool for Java/.NET code.Rune seeks a solution to the issue of his application not being fast enough to finish its work before a new block is received and processed. Suggestions include queuing outside of bitcoind and using zeromq for notifications. Jeff Garzik argues that updating bitcoind for this reason is not necessary as most systems can process a block before another one arrives.In May 2013, Rune posts a message outlining an issue with the -blocknotify option in bitcoind. Multiple instances of his application running simultaneously are considered inefficient. A solution involving a new function called -batchblocknotify is proposed, which would handle incoming blocks in batches to prevent resource inefficiency. The author is unsure how to implement this solution.Rune seeks a solution to his application not being fast enough to finish its work before a new block comes in. Suggestions include changing the -blocknotify script to append necessary information to a queue and having a separate script perform the calculations. Rune has concerns about concurrency issues.Rune asks for a solution on how to keep up with new blocks using the -blocknotify option with bitcoind. Michael suggests changing the -blocknotify script to append information to a queue and exit, while a separate script monitors the queue for work. Rune is concerned about concurrency issues and suggests batching together previously queued items.The author of a Bitcoin application wants to keep up with new blocks using the -blocknotify option with bitcoind, but their app isn't fast enough. A proposed solution involves a new function called -batchblocknotify that handles incoming blocks in batches. The author is unsure how to implement it. 2013-06-01T13:12:32+00:00 + In a discussion about high-speed notifications, Wladimir suggests using zmq and shares a pull request to integrate it into bitcoind. Chris Double, who has already integrated zmq for block notifications in bitcoin and alt coins, expresses interest in trying it out. Rune decides to go with the Unix socket method and expresses a desire to learn more about Unix sockets.On June 1, 2013, Wladimir suggests that using ZMQ would be ideal for high-speed notifications. He shares a pull request to integrate ZMQ directly into Bitcoind, eliminating the need for the -blocknotify flag. Chris, who has experience integrating ZMQ, offers to test the patch in the pull request.In a discussion on the Bitcoin-development mailing list, Chris mentions that he uses zmq for queuing outside of bitcoind to receive notifications. Wladimir suggests integrating zmq directly into bitcoind through a pull request on Github. Other members of the thread agree with Chris's approach of queuing outside of bitcoind. The thread also includes an advertisement for AppDynamics Lite, a free troubleshooting tool for Java/.NET code.Rune seeks a solution to the issue of his application not being fast enough to finish its work before a new block is received and processed. Suggestions include queuing outside of bitcoind and using zeromq for notifications. Jeff Garzik argues that updating bitcoind for this reason is not necessary as most systems can process a block before another one arrives.In May 2013, Rune posts a message outlining an issue with the -blocknotify option in bitcoind. Multiple instances of his application running simultaneously are considered inefficient. A solution involving a new function called -batchblocknotify is proposed, which would handle incoming blocks in batches to prevent resource inefficiency. The author is unsure how to implement this solution.Rune seeks a solution to his application not being fast enough to finish its work before a new block comes in. Suggestions include changing the -blocknotify script to append necessary information to a queue and having a separate script perform the calculations. Rune has concerns about concurrency issues.Rune asks for a solution on how to keep up with new blocks using the -blocknotify option with bitcoind. Michael suggests changing the -blocknotify script to append information to a queue and exit, while a separate script monitors the queue for work. Rune is concerned about concurrency issues and suggests batching together previously queued items.The author of a Bitcoin application wants to keep up with new blocks using the -blocknotify option with bitcoind, but their app isn't fast enough. A proposed solution involves a new function called -batchblocknotify that handles incoming blocks in batches. The author is unsure how to implement it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Missing-fRelayTxes-in-version-message.xml b/static/bitcoin-dev/June_2013/combined_Missing-fRelayTxes-in-version-message.xml index fe0592b887..f605000ca7 100644 --- a/static/bitcoin-dev/June_2013/combined_Missing-fRelayTxes-in-version-message.xml +++ b/static/bitcoin-dev/June_2013/combined_Missing-fRelayTxes-in-version-message.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Missing fRelayTxes in version message - 2023-08-01T05:10:52.387811+00:00 + 2025-10-11T21:29:36.155119+00:00 + python-feedgen Jeff Garzik 2013-06-20 13:35:11+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Missing fRelayTxes in version message - 2023-08-01T05:10:52.387811+00:00 + 2025-10-11T21:29:36.155299+00:00 - In a discussion about the relay field of a network packet, Addy Yeow emphasized its importance and explained that it is not an optional field. To read the packet correctly, one should first retrieve the header information, get the actual payload length, and then parse the payload accordingly. Yeow also mentioned that including 0x00 for the relay field in the outgoing packet and reflecting it in the length field in the header is possible.Jeff Garzik, a Senior Software Engineer and open source evangelist at BitPay, responded to Yeow's message by stating that although the logic of parsing fields may be ugly, there is no need to change it now. He argued that updating the version message to a different design solely for cleanliness reasons is not sufficient cause to migrate the entire bitcoin universe to a new and different version/feature negotiation setup.In this conversation, the participants discuss the issue of variable-length messages in Bitcoin protocol and their effect on parsing messages. They agree that optional lengths shouldn't be used and for every field change, the protocol version should be upgraded. The fRelayTxes field is specifically discussed and it is mentioned that it has been made a part of the protocol, but old clients don't send it so it has to be optional. The participants also discuss BIP 60, which proposes a protocol upgrade and details everything that needs to be done. Ultimately, they agree that having a fixed number of fields per protocol version would be beneficial for parsing messages and considered good practice.The Bitcoin protocol version was last bumped when Bloom filtering was added, and there is no need to bump it again. The existence of the nStartingHeight field depends on the message length and not anything else, and given that the old clients have to be handled no matter what, it is consistent with how other version fields are handled. A user named Turkey Breast brought up the issue that optional lengths shouldn't be used and for every field change, the protocol version should be upgraded. However, this is the first time anyone has suggested this minor detail is a problem, and it doesn't present any issues for the C++ code or bitcoinj where message objects know their own length at parse time. Additionally, Bitcoin version messages have always had variable length, and it is not inherent in the Bitcoin protocol that all messages are fixed length.Mike Hearn notes that if one wants to criticize the Bitcoin protocol for sloppiness, the variable length of some messages isn't where he would start. He points out that ping has the same issue, its length has changed over time to include the nonce. If one's parser can't handle that kind of thing, they need to fix it since the protocol has always worked that way. Similarly, when new fields are added to the version message, it's not a big deal to say that this protocol version has X number of fields, that (higher) protocol version message has X + N number of fields. Deterministic number of fields per protocol version is sensible and how Bitcoin has been for a long time.Turkey Breast believes that the existence of an unclear behavior that depends on some magic from one implementation doesn't help other implementations. He suggests that a fixed number of fields per protocol should be made, so given a protocol version number, one knows the number of fields in a message. This is not only easier for parsing messages but just good practice.Mike Hearn clarifies that it's not a bug (although there was recently a change to make bitcoind/qt always send this field anyway). He doesn't know where Amir is going with BIP 60, and he notes that version messages have always been variable length. There's nothing inherent in the Bitcoin protocol that says all messages are fixed length.In an email thread between Mike Hearn and Paul Lyon, they discuss the issue of the fRelayTxes field missing from some Bitcoin version messages. Turkey Breast also chimes in, suggesting that it would be better if messages always had a fixed number of fields per protocol version, rather than having variable length. Some argue that this is not a bug, but rather just how the protocol has always worked, with variable length messages being allowed for tx messages, for example. Ultimately, it is suggested that the protocol version should be upgraded to reflect the inclusion of fRelayTxes.The Bitcoin protocol has variable message length, which is also the case with ping messages. The issue may be a problem for some parsers who cannot handle it, but it has always been that way, and if you experience issues now, it means no sufficiently old nodes were talking to yours. The standard does not say the version message field should appear. There was a recent change to make bitcoind/qt always send the fRelayTxes field anyway, although it doesn't affect anything. The Bitcoin protocol has allowed tx messages to have arbitrary data appended after them that gets relayed. A fixed number of fields per protocol version would be good if messages always had 2013-06-20T13:35:11+00:00 + In a discussion about the relay field of a network packet, Addy Yeow emphasized its importance and explained that it is not an optional field. To read the packet correctly, one should first retrieve the header information, get the actual payload length, and then parse the payload accordingly. Yeow also mentioned that including 0x00 for the relay field in the outgoing packet and reflecting it in the length field in the header is possible.Jeff Garzik, a Senior Software Engineer and open source evangelist at BitPay, responded to Yeow's message by stating that although the logic of parsing fields may be ugly, there is no need to change it now. He argued that updating the version message to a different design solely for cleanliness reasons is not sufficient cause to migrate the entire bitcoin universe to a new and different version/feature negotiation setup.In this conversation, the participants discuss the issue of variable-length messages in Bitcoin protocol and their effect on parsing messages. They agree that optional lengths shouldn't be used and for every field change, the protocol version should be upgraded. The fRelayTxes field is specifically discussed and it is mentioned that it has been made a part of the protocol, but old clients don't send it so it has to be optional. The participants also discuss BIP 60, which proposes a protocol upgrade and details everything that needs to be done. Ultimately, they agree that having a fixed number of fields per protocol version would be beneficial for parsing messages and considered good practice.The Bitcoin protocol version was last bumped when Bloom filtering was added, and there is no need to bump it again. The existence of the nStartingHeight field depends on the message length and not anything else, and given that the old clients have to be handled no matter what, it is consistent with how other version fields are handled. A user named Turkey Breast brought up the issue that optional lengths shouldn't be used and for every field change, the protocol version should be upgraded. However, this is the first time anyone has suggested this minor detail is a problem, and it doesn't present any issues for the C++ code or bitcoinj where message objects know their own length at parse time. Additionally, Bitcoin version messages have always had variable length, and it is not inherent in the Bitcoin protocol that all messages are fixed length.Mike Hearn notes that if one wants to criticize the Bitcoin protocol for sloppiness, the variable length of some messages isn't where he would start. He points out that ping has the same issue, its length has changed over time to include the nonce. If one's parser can't handle that kind of thing, they need to fix it since the protocol has always worked that way. Similarly, when new fields are added to the version message, it's not a big deal to say that this protocol version has X number of fields, that (higher) protocol version message has X + N number of fields. Deterministic number of fields per protocol version is sensible and how Bitcoin has been for a long time.Turkey Breast believes that the existence of an unclear behavior that depends on some magic from one implementation doesn't help other implementations. He suggests that a fixed number of fields per protocol should be made, so given a protocol version number, one knows the number of fields in a message. This is not only easier for parsing messages but just good practice.Mike Hearn clarifies that it's not a bug (although there was recently a change to make bitcoind/qt always send this field anyway). He doesn't know where Amir is going with BIP 60, and he notes that version messages have always been variable length. There's nothing inherent in the Bitcoin protocol that says all messages are fixed length.In an email thread between Mike Hearn and Paul Lyon, they discuss the issue of the fRelayTxes field missing from some Bitcoin version messages. Turkey Breast also chimes in, suggesting that it would be better if messages always had a fixed number of fields per protocol version, rather than having variable length. Some argue that this is not a bug, but rather just how the protocol has always worked, with variable length messages being allowed for tx messages, for example. Ultimately, it is suggested that the protocol version should be upgraded to reflect the inclusion of fRelayTxes.The Bitcoin protocol has variable message length, which is also the case with ping messages. The issue may be a problem for some parsers who cannot handle it, but it has always been that way, and if you experience issues now, it means no sufficiently old nodes were talking to yours. The standard does not say the version message field should appear. There was a recent change to make bitcoind/qt always send the fRelayTxes field anyway, although it doesn't affect anything. The Bitcoin protocol has allowed tx messages to have arbitrary data appended after them that gets relayed. A fixed number of fields per protocol version would be good if messages always had - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Missing-fRelayTxes-in-version.xml b/static/bitcoin-dev/June_2013/combined_Missing-fRelayTxes-in-version.xml index 714b0d7868..c45860a680 100644 --- a/static/bitcoin-dev/June_2013/combined_Missing-fRelayTxes-in-version.xml +++ b/static/bitcoin-dev/June_2013/combined_Missing-fRelayTxes-in-version.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Missing fRelayTxes in version - 2023-08-01T05:11:18.713084+00:00 + 2025-10-11T21:29:10.641527+00:00 + python-feedgen Mike Hearn 2013-06-20 10:58:31+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Missing fRelayTxes in version - 2023-08-01T05:11:18.713084+00:00 + 2025-10-11T21:29:10.641673+00:00 - During a discussion on the Bitcoin-development mailing list, developers debated whether or not to increase the version number in the Bitcoin protocol. Pieter Wuille argued in favor of increasing the version number, stating that it would simplify things and be easy to implement. However, Turkey Breast disagreed, pointing out that this change would cause previous behavior to be lost and suggested that optional fields should have their own mechanism to remain optional between protocol version upgrades. Mike Hearn chimed in, stating that there was no immediate benefit to increasing the version number, but acknowledged that it may become necessary in the future if new optional fields are added to different messages.The debate centered around parsing the version message in the Bitcoin protocol. Some developers argued that the version should indicate which fields are present to simplify parsing, while others believed that keeping the number of fields flexible allowed for future changes without causing any issues. However, concerns were raised about relying on quirks and assumptions in the code, with suggestions that optional fields should have separate mechanisms to remain optional between protocol version upgrades. There were also discussions about truncated messages and handling them, as well as penalizing hosts that broadcast older version messages without all the required fields.Despite the disagreements, many developers agreed that changing the protocol version number from 70001 to 70002 would not be a significant problem and would not run the risk of running out of integers. It was ultimately decided to keep the number of fields in a message as a little version number, allowing for flexibility and costing nothing.In another email exchange, Mike Hearn questioned the need for a new version field unless there was an actual new feature to add. He also noted that the Bitcoin protocol did not require messages to have a fixed number of fields per version. Pieter Wuille disagreed, arguing that the version in the version message itself should indicate which fields are present to simplify parsing. They discussed raising the protocol version number to indicate that certain fields were required above a certain version number. It was mentioned that previous additions to the version message had been accompanied by a protocol/client version increase.In a separate discussion, Tamas Blummer and Mike Hearn discussed the complexity of the Bitcoin system and whether or not to address low-complexity issues. They specifically addressed an optional field in the version message and its complexity compared to other aspects of the system. While Mike argued that this issue was trivial and hardly worth thinking about, Tamas believed that eliminating complexity would strengthen the system. They discussed the backward compatibility of the issue and suggested bumping the version and parsing fields as mandatory going forward to maintain cleanliness.Another email exchange between Tamas Blummer and Mike Hearn focused on the variable number of fields in the version message in the Bitcoin protocol. Tamas suggested bumping the version and parsing certain fields as mandatory to eliminate unnecessary complexity. Mike questioned why this change should be made now instead of waiting for an actual new field to add. He also pointed out that any parser written with the assumption of a fixed number of fields per version would be buggy. The discussion also touched on the preservation of fields from the future in old versions.Overall, the discussions highlighted differing opinions on increasing the version number in the Bitcoin protocol and the benefits and drawbacks of doing so. Some developers argued for simplifying parsing by indicating which fields are present in the version message, while others believed that flexibility in the number of fields allowed for future changes without causing issues. The idea of penalizing hosts broadcasting older version messages without all the required fields was also brought up. Ultimately, it was decided to keep the number of fields flexible and maintain backward compatibility. 2013-06-20T10:58:31+00:00 + During a discussion on the Bitcoin-development mailing list, developers debated whether or not to increase the version number in the Bitcoin protocol. Pieter Wuille argued in favor of increasing the version number, stating that it would simplify things and be easy to implement. However, Turkey Breast disagreed, pointing out that this change would cause previous behavior to be lost and suggested that optional fields should have their own mechanism to remain optional between protocol version upgrades. Mike Hearn chimed in, stating that there was no immediate benefit to increasing the version number, but acknowledged that it may become necessary in the future if new optional fields are added to different messages.The debate centered around parsing the version message in the Bitcoin protocol. Some developers argued that the version should indicate which fields are present to simplify parsing, while others believed that keeping the number of fields flexible allowed for future changes without causing any issues. However, concerns were raised about relying on quirks and assumptions in the code, with suggestions that optional fields should have separate mechanisms to remain optional between protocol version upgrades. There were also discussions about truncated messages and handling them, as well as penalizing hosts that broadcast older version messages without all the required fields.Despite the disagreements, many developers agreed that changing the protocol version number from 70001 to 70002 would not be a significant problem and would not run the risk of running out of integers. It was ultimately decided to keep the number of fields in a message as a little version number, allowing for flexibility and costing nothing.In another email exchange, Mike Hearn questioned the need for a new version field unless there was an actual new feature to add. He also noted that the Bitcoin protocol did not require messages to have a fixed number of fields per version. Pieter Wuille disagreed, arguing that the version in the version message itself should indicate which fields are present to simplify parsing. They discussed raising the protocol version number to indicate that certain fields were required above a certain version number. It was mentioned that previous additions to the version message had been accompanied by a protocol/client version increase.In a separate discussion, Tamas Blummer and Mike Hearn discussed the complexity of the Bitcoin system and whether or not to address low-complexity issues. They specifically addressed an optional field in the version message and its complexity compared to other aspects of the system. While Mike argued that this issue was trivial and hardly worth thinking about, Tamas believed that eliminating complexity would strengthen the system. They discussed the backward compatibility of the issue and suggested bumping the version and parsing fields as mandatory going forward to maintain cleanliness.Another email exchange between Tamas Blummer and Mike Hearn focused on the variable number of fields in the version message in the Bitcoin protocol. Tamas suggested bumping the version and parsing certain fields as mandatory to eliminate unnecessary complexity. Mike questioned why this change should be made now instead of waiting for an actual new field to add. He also pointed out that any parser written with the assumption of a fixed number of fields per version would be buggy. The discussion also touched on the preservation of fields from the future in old versions.Overall, the discussions highlighted differing opinions on increasing the version number in the Bitcoin protocol and the benefits and drawbacks of doing so. Some developers argued for simplifying parsing by indicating which fields are present in the version message, while others believed that flexibility in the number of fields allowed for future changes without causing issues. The idea of penalizing hosts broadcasting older version messages without all the required fields was also brought up. Ultimately, it was decided to keep the number of fields flexible and maintain backward compatibility. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Optional-wallet-linkable-address-format-Payment-Protocol.xml b/static/bitcoin-dev/June_2013/combined_Optional-wallet-linkable-address-format-Payment-Protocol.xml index 6ad2256413..7af97e4409 100644 --- a/static/bitcoin-dev/June_2013/combined_Optional-wallet-linkable-address-format-Payment-Protocol.xml +++ b/static/bitcoin-dev/June_2013/combined_Optional-wallet-linkable-address-format-Payment-Protocol.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Optional "wallet-linkable" address format - Payment Protocol - 2023-08-01T05:10:15.707119+00:00 + Combined summary - Optional "wallet-linkable" address format - Payment Protocol + 2025-10-11T21:29:25.520334+00:00 + python-feedgen Alan Reiner 2013-06-26 15:29:50+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 - Combined summary - Optional "wallet-linkable" address format - Payment Protocol - 2023-08-01T05:10:15.707119+00:00 + Combined summary - Optional "wallet-linkable" address format - Payment Protocol + 2025-10-11T21:29:25.520535+00:00 - The discussion revolves around the complications of designing a wallet system that can handle multiple chains and addresses. BIP 32 defines M/i/j/k, where j=0 is the "external" chain used for distributing addresses, and j=1 is the "internal" chain for sending change. The extended wallet would have chains with j>=2 carved out for individual relationships with wallet code to individually associate each j-value with a particular identity. The wallet code will pool all the addresses in all j-chains when calculating the balance of the wallet and/or creating transactions.The email thread discusses the issue of proving a payment to a third party who has not seen the communication between payer and payee. The solution proposed involves using PubKeyParent and HMAC (Multiplier, PubKeyParent) to calculate the destination address, which can then be provided to the third party as proof of payment. The use of Timo's suggestion is also discussed, but it would require deviation from BIP 32 standardization. The importance of supporting both solutions is emphasized, rather than introducing extra wallets/chains.The context discusses the challenge of proving a payment to a third party who has not seen the communication between the payer and payee. The HASH160 is the only information that the third party has. The problem arises when the payee denies receiving the funds, as it's easy to prove what public key it was sent to (the preimage), but you can't prove the parent of that public key. However, a solution proposed by Timo suggests calculating the destination using PubKeyParent * HMAC(Multiplier, PubKeyParent). If this method is used, providing the 3rd party with a PubKeyParent and Multiplier that produces the destination address would prove the payment is spendable by PubKeyParent, leaving no room for denial.The discussion takes place between two individuals, Jeremy and an unidentified person, about the implementation of HD wallets in Bitcoinj. The unidentified person suggests defining an extension that allows for the push-style sending of payment requests containing public keys and chain codes. They also mention experimentation with how apps will arrange their chains internally. Jeremy mentions that BIP 32 already specifies the use of the first three tree levels: M/i/j/k, and that creating new wallets would not be free unless the levels are redefined.In this conversation, Jeremy is discussing with Alan the limitations of BIP32 in using multiple chains. He mentions that BIP32 does not prescribe a way to use multiple chains like the one he described. He also questions the need for a 128kB hardware wallet as it is only a signing device and doesn't listen on the P2P network. Jeremy emphasizes the benefits of gaining critical mass support for a technique that can be used in all cases, increasing security and privacy for everyone involved. He believes there are huge benefits in leaving the age of single address generation behind us.The discussion is about the use of PubKey and ChainCode for forming a persistent relationship between two parties using BIP32. The author suggests that exchanging PubKey and ChainCode beforehand can help in transaction securely forever without ever exchanging any more information, and without any address reuse. They propose that wallets should always dedicate a new child node {PubKey, ChainCode} to each party they transact with.An alternative address format is proposed in the context, which is made possible by BIP 32. The purpose of this new format is to specify a "Wallet ID" and "One-time payment" code instead of the standard one-use Base58-Hash160 addresses. This format allows parties with a persistent relationship to prove that payment addresses they provide each other are linked to a particular wallet. It reduces exposure to Man-in-the-Middle (MitM) attacks without the need for SSL or a web of trust, while maintaining the privacy of both parties.One suggestion discussed in the conversation is the use of ECDSA signatures for type2 public keys, which are multiples of a parent public key. The proposal suggests sending an ECDSA signature of the multiplier, which can be used to compute the parent public key. However, there are concerns about the unknown discrete log artifact and potential vulnerabilities. One solution proposed is to require a proof of knowledge of the discrete log, such as including an ECDSA signature or Schnorr proof of knowledge in the address.Another issue raised is the possibility of generating arbitrary pairs of {PublicKeyParent, Multiplier} that lead to the same address. This could be undesirable depending on what the transaction should prove. To address this, the suggestion is to replace PubKeyParent * Multiplier with PubKeyParent * HMAC(Multiplier, PubKeyParent). However, it is noted that the most obvious attack vector is the discrete log problem, where an attacker tries to find the multiplier that solves M * PubC = PubB.The conversation also explores the idea of an alternate way of encoding an address using {PubKey, Multiplier}. This allows the receiver of 2013-06-26T15:29:50+00:00 + The discussion revolves around the complications of designing a wallet system that can handle multiple chains and addresses. BIP 32 defines M/i/j/k, where j=0 is the "external" chain used for distributing addresses, and j=1 is the "internal" chain for sending change. The extended wallet would have chains with j>=2 carved out for individual relationships with wallet code to individually associate each j-value with a particular identity. The wallet code will pool all the addresses in all j-chains when calculating the balance of the wallet and/or creating transactions.The email thread discusses the issue of proving a payment to a third party who has not seen the communication between payer and payee. The solution proposed involves using PubKeyParent and HMAC (Multiplier, PubKeyParent) to calculate the destination address, which can then be provided to the third party as proof of payment. The use of Timo's suggestion is also discussed, but it would require deviation from BIP 32 standardization. The importance of supporting both solutions is emphasized, rather than introducing extra wallets/chains.The context discusses the challenge of proving a payment to a third party who has not seen the communication between the payer and payee. The HASH160 is the only information that the third party has. The problem arises when the payee denies receiving the funds, as it's easy to prove what public key it was sent to (the preimage), but you can't prove the parent of that public key. However, a solution proposed by Timo suggests calculating the destination using PubKeyParent * HMAC(Multiplier, PubKeyParent). If this method is used, providing the 3rd party with a PubKeyParent and Multiplier that produces the destination address would prove the payment is spendable by PubKeyParent, leaving no room for denial.The discussion takes place between two individuals, Jeremy and an unidentified person, about the implementation of HD wallets in Bitcoinj. The unidentified person suggests defining an extension that allows for the push-style sending of payment requests containing public keys and chain codes. They also mention experimentation with how apps will arrange their chains internally. Jeremy mentions that BIP 32 already specifies the use of the first three tree levels: M/i/j/k, and that creating new wallets would not be free unless the levels are redefined.In this conversation, Jeremy is discussing with Alan the limitations of BIP32 in using multiple chains. He mentions that BIP32 does not prescribe a way to use multiple chains like the one he described. He also questions the need for a 128kB hardware wallet as it is only a signing device and doesn't listen on the P2P network. Jeremy emphasizes the benefits of gaining critical mass support for a technique that can be used in all cases, increasing security and privacy for everyone involved. He believes there are huge benefits in leaving the age of single address generation behind us.The discussion is about the use of PubKey and ChainCode for forming a persistent relationship between two parties using BIP32. The author suggests that exchanging PubKey and ChainCode beforehand can help in transaction securely forever without ever exchanging any more information, and without any address reuse. They propose that wallets should always dedicate a new child node {PubKey, ChainCode} to each party they transact with.An alternative address format is proposed in the context, which is made possible by BIP 32. The purpose of this new format is to specify a "Wallet ID" and "One-time payment" code instead of the standard one-use Base58-Hash160 addresses. This format allows parties with a persistent relationship to prove that payment addresses they provide each other are linked to a particular wallet. It reduces exposure to Man-in-the-Middle (MitM) attacks without the need for SSL or a web of trust, while maintaining the privacy of both parties.One suggestion discussed in the conversation is the use of ECDSA signatures for type2 public keys, which are multiples of a parent public key. The proposal suggests sending an ECDSA signature of the multiplier, which can be used to compute the parent public key. However, there are concerns about the unknown discrete log artifact and potential vulnerabilities. One solution proposed is to require a proof of knowledge of the discrete log, such as including an ECDSA signature or Schnorr proof of knowledge in the address.Another issue raised is the possibility of generating arbitrary pairs of {PublicKeyParent, Multiplier} that lead to the same address. This could be undesirable depending on what the transaction should prove. To address this, the suggestion is to replace PubKeyParent * Multiplier with PubKeyParent * HMAC(Multiplier, PubKeyParent). However, it is noted that the most obvious attack vector is the discrete log problem, where an attacker tries to find the multiplier that solves M * PubC = PubB.The conversation also explores the idea of an alternate way of encoding an address using {PubKey, Multiplier}. This allows the receiver of - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Proposal-MultiBit-as-default-desktop-client-on-bitcoin-org.xml b/static/bitcoin-dev/June_2013/combined_Proposal-MultiBit-as-default-desktop-client-on-bitcoin-org.xml index 683e2bf87e..a9b8aa8d08 100644 --- a/static/bitcoin-dev/June_2013/combined_Proposal-MultiBit-as-default-desktop-client-on-bitcoin-org.xml +++ b/static/bitcoin-dev/June_2013/combined_Proposal-MultiBit-as-default-desktop-client-on-bitcoin-org.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: MultiBit as default desktop client on bitcoin.org - 2023-08-01T05:13:46.470693+00:00 + 2025-10-11T21:29:34.029775+00:00 + python-feedgen Andreas Petersson 2013-07-09 22:15:03+00:00 @@ -191,13 +192,13 @@ - python-feedgen + 2 Combined summary - Proposal: MultiBit as default desktop client on bitcoin.org - 2023-08-01T05:13:46.470693+00:00 + 2025-10-11T21:29:34.029994+00:00 - The context revolves around various discussions related to MultiBit, a Bitcoin wallet application. One topic of discussion is the concern about the security of Java and its impact on MultiBit's security. Despite these concerns, MultiBit is considered secure enough to handle money. The developer has made efforts to improve support for users by creating a dedicated support page on the website and enhancing the in-app help section. Users are directed to external resources such as bitcoin.stackexchange.com and GitHub issues for further assistance. There is also a debate about whether MultiBit should replace Bitcoin-Qt as the recommended desktop wallet app. The supporting documentation for the website can be found at https://github.com/jim618/multibit-website.In addition, there are conversations about the challenges and developments in the world of Bitcoin and its wallets. These discussions cover topics such as encryption, replace-by-fee rules, issues with Bitcoinj, adoption of Bitcoin, and making technology accessible to non-technical users. The context also touches on the features and improvements of MultiBit, including encrypted wallets, sign and verify message capabilities, stability improvements, and bug fixes. The founder of MultiBit proposes that it should become the default desktop client on bitcoin.org's "Choose your wallet" page to attract new users and introduce them to the broader Bitcoin economy.Overall, the discussions highlight the efforts made by the developer to enhance the usability and support of MultiBit, as well as the potential role of MultiBit in expanding the adoption of cryptocurrency. 2013-07-09T22:15:03+00:00 + The context revolves around various discussions related to MultiBit, a Bitcoin wallet application. One topic of discussion is the concern about the security of Java and its impact on MultiBit's security. Despite these concerns, MultiBit is considered secure enough to handle money. The developer has made efforts to improve support for users by creating a dedicated support page on the website and enhancing the in-app help section. Users are directed to external resources such as bitcoin.stackexchange.com and GitHub issues for further assistance. There is also a debate about whether MultiBit should replace Bitcoin-Qt as the recommended desktop wallet app. The supporting documentation for the website can be found at https://github.com/jim618/multibit-website.In addition, there are conversations about the challenges and developments in the world of Bitcoin and its wallets. These discussions cover topics such as encryption, replace-by-fee rules, issues with Bitcoinj, adoption of Bitcoin, and making technology accessible to non-technical users. The context also touches on the features and improvements of MultiBit, including encrypted wallets, sign and verify message capabilities, stability improvements, and bug fixes. The founder of MultiBit proposes that it should become the default desktop client on bitcoin.org's "Choose your wallet" page to attract new users and introduce them to the broader Bitcoin economy.Overall, the discussions highlight the efforts made by the developer to enhance the usability and support of MultiBit, as well as the potential role of MultiBit in expanding the adoption of cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Proposal-Vote-on-the-blocksize-limit-with-proof-of-stake-voting.xml b/static/bitcoin-dev/June_2013/combined_Proposal-Vote-on-the-blocksize-limit-with-proof-of-stake-voting.xml index 37cfef5b3b..0524642eb9 100644 --- a/static/bitcoin-dev/June_2013/combined_Proposal-Vote-on-the-blocksize-limit-with-proof-of-stake-voting.xml +++ b/static/bitcoin-dev/June_2013/combined_Proposal-Vote-on-the-blocksize-limit-with-proof-of-stake-voting.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: Vote on the blocksize limit with proof-of-stake voting - 2023-08-01T05:08:12.097592+00:00 + 2025-10-11T21:29:38.278247+00:00 + python-feedgen John Dillon 2013-06-28 10:25:28+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Proposal: Vote on the blocksize limit with proof-of-stake voting - 2023-08-01T05:08:12.097592+00:00 + 2025-10-11T21:29:38.278523+00:00 - The email communication discusses the implementation of a voting system to increase the blocksize limit in Bitcoin. The author suggests that this system would ensure that any increase genuinely represents the desires of the Bitcoin community. While coercion and vote buying are possible, the design of Bitcoin allows for a decentralized system. The process described in the email ensures that changes happen gradually, giving all participants time to react.The author also emphasizes that implementing a voting system would take control away from the core development team and give it back to the community. This is seen as a way to address the political nature of the issue. The vote itself would involve a txout with a scriptPubKey form that proves one could have spent the txout. The median, rather than the mean, would be computed to prevent skewing the vote. The rolling median and periodic reset process further ensure gradual changes and prevent temporary events from influencing the vote.The email dated June 10, 2013, focuses on setting the default for Bitcoin block size limits. The author proposes that the default should not be set by wallets, but instead, users who do not vote would accept the status quo. The status quo is defined as the mean of the old and new limits in the past year. By not voting, users effectively vote for the current limit. The author also mentions the importance of factoring in txout age, where older txouts would carry less weight in the vote. Sudden changes in votes should be avoided to ensure gradual increases.The message highlights the concern of putting too much power in the hands of a small minority if the decision of blocksize is left entirely up to miners. Unlimited blocksize proposals could lead to problems if the majority wishes to validate the blockchain. The proposed solution is proof-of-stake voting, where miners must prove that the majority wants to accept a larger blocksize before increasing it. The upper limit on blocksize would be determined by the median of all votes, weighted by txout value. Votes without corresponding txouts would be considered a vote for the current limit. To ensure the voting process continues even if coins are lost, votes including default votes would be weighted inversely according to their age after 1 year. 2013-06-28T10:25:28+00:00 + The email communication discusses the implementation of a voting system to increase the blocksize limit in Bitcoin. The author suggests that this system would ensure that any increase genuinely represents the desires of the Bitcoin community. While coercion and vote buying are possible, the design of Bitcoin allows for a decentralized system. The process described in the email ensures that changes happen gradually, giving all participants time to react.The author also emphasizes that implementing a voting system would take control away from the core development team and give it back to the community. This is seen as a way to address the political nature of the issue. The vote itself would involve a txout with a scriptPubKey form that proves one could have spent the txout. The median, rather than the mean, would be computed to prevent skewing the vote. The rolling median and periodic reset process further ensure gradual changes and prevent temporary events from influencing the vote.The email dated June 10, 2013, focuses on setting the default for Bitcoin block size limits. The author proposes that the default should not be set by wallets, but instead, users who do not vote would accept the status quo. The status quo is defined as the mean of the old and new limits in the past year. By not voting, users effectively vote for the current limit. The author also mentions the importance of factoring in txout age, where older txouts would carry less weight in the vote. Sudden changes in votes should be avoided to ensure gradual increases.The message highlights the concern of putting too much power in the hands of a small minority if the decision of blocksize is left entirely up to miners. Unlimited blocksize proposals could lead to problems if the majority wishes to validate the blockchain. The proposed solution is proof-of-stake voting, where miners must prove that the majority wants to accept a larger blocksize before increasing it. The upper limit on blocksize would be determined by the median of all votes, weighted by txout value. Votes without corresponding txouts would be considered a vote for the current limit. To ensure the voting process continues even if coins are lost, votes including default votes would be weighted inversely according to their age after 1 year. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Proposal-soft-fork-to-make-anyone-can-spend-outputs-unspendable-for-100-blocks.xml b/static/bitcoin-dev/June_2013/combined_Proposal-soft-fork-to-make-anyone-can-spend-outputs-unspendable-for-100-blocks.xml index 3ec7890010..9e9b6e6106 100644 --- a/static/bitcoin-dev/June_2013/combined_Proposal-soft-fork-to-make-anyone-can-spend-outputs-unspendable-for-100-blocks.xml +++ b/static/bitcoin-dev/June_2013/combined_Proposal-soft-fork-to-make-anyone-can-spend-outputs-unspendable-for-100-blocks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks - 2023-08-01T05:06:25.372092+00:00 + 2025-10-11T21:29:29.778836+00:00 + python-feedgen Melvin Carvalho 2013-06-06 22:10:11+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks - 2023-08-01T05:06:25.372092+00:00 + 2025-10-11T21:29:29.779004+00:00 - A discussion took place in a Bitcoin-development mailing list in June 2013 regarding the use of the blockchain for purposes other than payments. Andreas Antonopoulos argued for fixed fees to allow innovative uses of the distributed timestamping database, while Luke-Jr believed that non-payment storage violated the agreement to use the blockchain for payments. They also discussed the possibility of storing hashes of content instead of the content itself. Luke-Jr explained merged mining, which links the Bitcoin blockchain with other data through an extra hash in the coinbase.Antonopoulos clarified in an email conversation on June 6, 2013, that fees for storing data in the blockchain are only received by miners and not the majority of nodes. He argued that using other people's resources for non-payment storage violates the neutrality of the protocol and hinders future innovation. However, he suggested that if there was a legitimate use case for non-payment storage, it could be considered. He also explained merged mining as a solution.Antonopoulos raised the question of whether Bitcoin could function as a platform for various services while remaining neutral to payload. He compared this to the early days of the internet where there were debates about allowing video, voice, or images on the IP network. He proposed solving the issue of un-spendable outputs without limiting other transaction payloads that could enable layered apps above Bitcoin. Luke-Jr disagreed, stating that data does not belong in the blockchain and violates the social contract of nodes to store blocks for financial purposes. The discussion concluded with the idea that unexpected reuse should not be ruled out in the early stage of Bitcoin's development.The discussions highlighted the debate over using the blockchain for non-payment storage. Antonopoulos advocated for more flexibility, while Luke-Jr emphasized the importance of using the blockchain solely for payment transactions. Merged mining was proposed as a way to link the blockchain with other datasets.In another conversation, Jeff Garzik and Roy Badami discussed the difficulty of obtaining payments as a miner. Garzik argued that achieving the high difficulty needed to create a valid bitcoin block was challenging, while Badami suggested it was not difficult for pool operators or those buying hashing power. The conversation also touched on the vulnerability of mining fee sacrifices and the potential for large pools to create them cheaply.Other discussions included proposals for new standardized spend-to-fees for miners, the idea of zero-output transactions as proof of sacrifice, and the possibility of introducing new opcodes. There were also discussions about why someone would want to sacrifice their Bitcoins and the potential use of Fidelity Bonds. Technical details about implementing changes and ensuring security were also addressed.Overall, the discussions revolved around the use of the blockchain for non-payment purposes, the challenges of mining, and the potential for future innovation and flexibility in the Bitcoin network.A discussion has been taking place regarding the use of Bitcoin as a currency or commodity and the disincentives for using the blockchain for data storage and messaging. Concerns have been raised about the unlimited bloat caused by inefficient timestamping and the potential scalability issues it may create. One solution proposed is to sacrifice Bitcoins in a provably unspendable way, which is seen as an improvement for the long-term health of the Unspent Transaction Output (UTXO) set. However, it is worth continuing to disincentivize the use of the blockchain for data storage and messaging, except for cases where there is a clear currency or data storage incentive.Gavin proposes a new opcode for the Bitcoin protocol, redefining op_nop1 as "verify depth." The discussion explores different options for sacrificing Bitcoins in a provably unspendable way without using complex announce-commit logic. Another option is to implement a rule where txouts ending in OP_TRUE are unspendable for 100 blocks, similar to coinbases. This would require a soft-fork with 95% support. It is suggested that anyone-can-spend outputs should be made IsStandard() to ensure they are relayed. While sacrificing to unspendable outputs is an alternative, it is considered less desirable compared to sending the money to miners to enhance the network's security.In another email conversation, Luke-Jr argues against storing data on the blockchain, as it goes against the social contract agreed upon by node operators. Peter Todd suggests a way to implement his zookeyv key-value consensus system using transactions that prove funds have been sacrificed, which is compatible with Gregory Maxwell's fix to data-in-chain storage. The suggestion is to make such transactions more expensive to prevent them from being blocked. The email concludes with Todd stating his opposition to increasing the blocksize.Overall, a new mechanism has been proposed for sacrificing Bitcoins without making them unspendable. The most compact option currently available is to create an anyone-can-spend output in the coinbase of a block. Another option is to use anyone-can-spend in a regular transaction output, but there is no guarantee that a miner won't spend that output in the same 2013-06-06T22:10:11+00:00 + A discussion took place in a Bitcoin-development mailing list in June 2013 regarding the use of the blockchain for purposes other than payments. Andreas Antonopoulos argued for fixed fees to allow innovative uses of the distributed timestamping database, while Luke-Jr believed that non-payment storage violated the agreement to use the blockchain for payments. They also discussed the possibility of storing hashes of content instead of the content itself. Luke-Jr explained merged mining, which links the Bitcoin blockchain with other data through an extra hash in the coinbase.Antonopoulos clarified in an email conversation on June 6, 2013, that fees for storing data in the blockchain are only received by miners and not the majority of nodes. He argued that using other people's resources for non-payment storage violates the neutrality of the protocol and hinders future innovation. However, he suggested that if there was a legitimate use case for non-payment storage, it could be considered. He also explained merged mining as a solution.Antonopoulos raised the question of whether Bitcoin could function as a platform for various services while remaining neutral to payload. He compared this to the early days of the internet where there were debates about allowing video, voice, or images on the IP network. He proposed solving the issue of un-spendable outputs without limiting other transaction payloads that could enable layered apps above Bitcoin. Luke-Jr disagreed, stating that data does not belong in the blockchain and violates the social contract of nodes to store blocks for financial purposes. The discussion concluded with the idea that unexpected reuse should not be ruled out in the early stage of Bitcoin's development.The discussions highlighted the debate over using the blockchain for non-payment storage. Antonopoulos advocated for more flexibility, while Luke-Jr emphasized the importance of using the blockchain solely for payment transactions. Merged mining was proposed as a way to link the blockchain with other datasets.In another conversation, Jeff Garzik and Roy Badami discussed the difficulty of obtaining payments as a miner. Garzik argued that achieving the high difficulty needed to create a valid bitcoin block was challenging, while Badami suggested it was not difficult for pool operators or those buying hashing power. The conversation also touched on the vulnerability of mining fee sacrifices and the potential for large pools to create them cheaply.Other discussions included proposals for new standardized spend-to-fees for miners, the idea of zero-output transactions as proof of sacrifice, and the possibility of introducing new opcodes. There were also discussions about why someone would want to sacrifice their Bitcoins and the potential use of Fidelity Bonds. Technical details about implementing changes and ensuring security were also addressed.Overall, the discussions revolved around the use of the blockchain for non-payment purposes, the challenges of mining, and the potential for future innovation and flexibility in the Bitcoin network.A discussion has been taking place regarding the use of Bitcoin as a currency or commodity and the disincentives for using the blockchain for data storage and messaging. Concerns have been raised about the unlimited bloat caused by inefficient timestamping and the potential scalability issues it may create. One solution proposed is to sacrifice Bitcoins in a provably unspendable way, which is seen as an improvement for the long-term health of the Unspent Transaction Output (UTXO) set. However, it is worth continuing to disincentivize the use of the blockchain for data storage and messaging, except for cases where there is a clear currency or data storage incentive.Gavin proposes a new opcode for the Bitcoin protocol, redefining op_nop1 as "verify depth." The discussion explores different options for sacrificing Bitcoins in a provably unspendable way without using complex announce-commit logic. Another option is to implement a rule where txouts ending in OP_TRUE are unspendable for 100 blocks, similar to coinbases. This would require a soft-fork with 95% support. It is suggested that anyone-can-spend outputs should be made IsStandard() to ensure they are relayed. While sacrificing to unspendable outputs is an alternative, it is considered less desirable compared to sending the money to miners to enhance the network's security.In another email conversation, Luke-Jr argues against storing data on the blockchain, as it goes against the social contract agreed upon by node operators. Peter Todd suggests a way to implement his zookeyv key-value consensus system using transactions that prove funds have been sacrificed, which is compatible with Gregory Maxwell's fix to data-in-chain storage. The suggestion is to make such transactions more expensive to prevent them from being blocked. The email concludes with Todd stating his opposition to increasing the blocksize.Overall, a new mechanism has been proposed for sacrificing Bitcoins without making them unspendable. The most compact option currently available is to create an anyone-can-spend output in the coinbase of a block. Another option is to use anyone-can-spend in a regular transaction output, but there is no guarantee that a miner won't spend that output in the same - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Revocability-with-known-trusted-escrow-services-.xml b/static/bitcoin-dev/June_2013/combined_Revocability-with-known-trusted-escrow-services-.xml index 5c97508731..a4db88cf09 100644 --- a/static/bitcoin-dev/June_2013/combined_Revocability-with-known-trusted-escrow-services-.xml +++ b/static/bitcoin-dev/June_2013/combined_Revocability-with-known-trusted-escrow-services-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Revocability with known trusted escrow services? - 2023-08-01T05:06:46.163301+00:00 + 2025-10-11T21:29:17.025093+00:00 + python-feedgen Caleb James DeLisle 2013-06-07 05:46:04+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Revocability with known trusted escrow services? - 2023-08-01T05:06:46.164258+00:00 + 2025-10-11T21:29:17.025273+00:00 - On June 6, 2013, Peter Vessenes, the CEO of CoinLab, shared an article discussing FinCEN's belief that irrevocable payments are tools for money laundering. He proposed a scheme to add revocability to Bitcoin transactions without any protocol changes by creating a trusted escrow service that issues time promises for signing. However, he acknowledged that this approach is vulnerable to griefing and requires trust in the escrow service. Vessenes suggested replicating the effect of revoking a transaction by giving private keys to a relevant revocation authority or using 1-of-2 multisig addresses. He emphasized the importance of taking money from someone who thought they had it and giving it to someone else instead of simply revoking a transaction.In an email exchange with others, Vessenes disagreed with the American Banker article's claim that irrevocable payments are tools for money laundering. He argued that credit card transactions are not completely reversible either and questioned the motives of the head of FinCEN. He proposed the idea of layering on revocability without any protocol change as an opt-in. He suggested using 2-of-3 dispute mediation, which was already outlined in Satoshi's paper. However, he noted that implementing such a solution would require deploying the payment protocol first and defining how disputes would be opened and mediators found. Vessenes believed that reversible payments where one party decides whether to reverse them seem pointless, as they are equivalent to post-pay for buyers and just a refund for sellers, which can already be supported by the payment protocol.The conversation also touched on P2SH with 2 of 3, which involves the payer, recipient, and a trusted third party. It was explained in detail on the Bitcoin wiki contracts page, along with an example of escrow and dispute mediation. The issue of tainted coins was raised, and it was mentioned that nothing can be done at the protocol level if the transaction needs to remain peer-to-peer. The authorities were accused of using the differences between cryptocurrencies and the banking system as an excuse to prosecute members of the new industry. Suggestions were made to collect arguments against such accusations, and the concept of maturation for dedicated accounts/transactions was proposed as a possible solution.Overall, the discussion focused on finding ways to add revocability to Bitcoin transactions without requiring protocol changes. Various ideas, including trusted escrow services, dispute mediation, and alternative transaction structures, were proposed. However, concerns were raised about the vulnerability of these approaches to griefing and the need for trust in third parties. The conversation also highlighted the potential legal issues and implications surrounding reversible payments and the ongoing efforts to comply with US regulations on money transfers. 2013-06-07T05:46:04+00:00 + On June 6, 2013, Peter Vessenes, the CEO of CoinLab, shared an article discussing FinCEN's belief that irrevocable payments are tools for money laundering. He proposed a scheme to add revocability to Bitcoin transactions without any protocol changes by creating a trusted escrow service that issues time promises for signing. However, he acknowledged that this approach is vulnerable to griefing and requires trust in the escrow service. Vessenes suggested replicating the effect of revoking a transaction by giving private keys to a relevant revocation authority or using 1-of-2 multisig addresses. He emphasized the importance of taking money from someone who thought they had it and giving it to someone else instead of simply revoking a transaction.In an email exchange with others, Vessenes disagreed with the American Banker article's claim that irrevocable payments are tools for money laundering. He argued that credit card transactions are not completely reversible either and questioned the motives of the head of FinCEN. He proposed the idea of layering on revocability without any protocol change as an opt-in. He suggested using 2-of-3 dispute mediation, which was already outlined in Satoshi's paper. However, he noted that implementing such a solution would require deploying the payment protocol first and defining how disputes would be opened and mediators found. Vessenes believed that reversible payments where one party decides whether to reverse them seem pointless, as they are equivalent to post-pay for buyers and just a refund for sellers, which can already be supported by the payment protocol.The conversation also touched on P2SH with 2 of 3, which involves the payer, recipient, and a trusted third party. It was explained in detail on the Bitcoin wiki contracts page, along with an example of escrow and dispute mediation. The issue of tainted coins was raised, and it was mentioned that nothing can be done at the protocol level if the transaction needs to remain peer-to-peer. The authorities were accused of using the differences between cryptocurrencies and the banking system as an excuse to prosecute members of the new industry. Suggestions were made to collect arguments against such accusations, and the concept of maturation for dedicated accounts/transactions was proposed as a possible solution.Overall, the discussion focused on finding ways to add revocability to Bitcoin transactions without requiring protocol changes. Various ideas, including trusted escrow services, dispute mediation, and alternative transaction structures, were proposed. However, concerns were raised about the vulnerability of these approaches to griefing and the need for trust in third parties. The conversation also highlighted the potential legal issues and implications surrounding reversible payments and the ongoing efforts to comply with US regulations on money transfers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_Standard-public-key-base58-check-address-prefix-.xml b/static/bitcoin-dev/June_2013/combined_Standard-public-key-base58-check-address-prefix-.xml index 568c721f20..ec58df766f 100644 --- a/static/bitcoin-dev/June_2013/combined_Standard-public-key-base58-check-address-prefix-.xml +++ b/static/bitcoin-dev/June_2013/combined_Standard-public-key-base58-check-address-prefix-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Standard public key base58-check address prefix? - 2023-08-01T05:11:41.085365+00:00 + 2025-10-11T21:29:14.902519+00:00 + python-feedgen Nadav Ivgi 2013-06-21 20:41:25+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Standard public key base58-check address prefix? - 2023-08-01T05:11:41.085365+00:00 + 2025-10-11T21:29:14.902670+00:00 - In the discussion, the focus is on finding a more efficient method for exchanging public keys in multisig transactions. The current practice of using hex encoding leads to longer strings and doesn't provide 4-byte verification, raising security concerns. To address this issue, there is a need for a standard way to encode public keys as base58-check addresses, which would make it both easier and safer to display and exchange public keys.Nadav suggests using 0x37/0x38 prefix bytes for this purpose, resulting in the letter P to represent "Public". It's important to note that Nadav is referring to the actual public key itself, not the hash160 used for Bitcoin addresses. While this prefix byte usage is not common, it is necessary for multisig transactions.The author of the message shares their own project experience, highlighting the requirement of public key exchange for multisig transactions. They acknowledge that hex encoding is commonly used for displaying public keys but point out its drawbacks, such as longer strings and the absence of 4-byte verification. To overcome these limitations, the author proposes adopting a standard way to encode public keys as base58-check addresses.To achieve this, the author suggests utilizing the currently unused 0x37/0x38 prefix bytes, resulting in the letter P to represent "Public". By implementing this approach, the author aims to make the display and exchange of public keys easier and safer. 2013-06-21T20:41:25+00:00 + In the discussion, the focus is on finding a more efficient method for exchanging public keys in multisig transactions. The current practice of using hex encoding leads to longer strings and doesn't provide 4-byte verification, raising security concerns. To address this issue, there is a need for a standard way to encode public keys as base58-check addresses, which would make it both easier and safer to display and exchange public keys.Nadav suggests using 0x37/0x38 prefix bytes for this purpose, resulting in the letter P to represent "Public". It's important to note that Nadav is referring to the actual public key itself, not the hash160 used for Bitcoin addresses. While this prefix byte usage is not common, it is necessary for multisig transactions.The author of the message shares their own project experience, highlighting the requirement of public key exchange for multisig transactions. They acknowledge that hex encoding is commonly used for displaying public keys but point out its drawbacks, such as longer strings and the absence of 4-byte verification. To overcome these limitations, the author proposes adopting a standard way to encode public keys as base58-check addresses.To achieve this, the author suggests utilizing the currently unused 0x37/0x38 prefix bytes, resulting in the letter P to represent "Public". By implementing this approach, the author aims to make the display and exchange of public keys easier and safer. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_address-collision-and-undependability.xml b/static/bitcoin-dev/June_2013/combined_address-collision-and-undependability.xml index 51bfa512dc..f6efa7f68e 100644 --- a/static/bitcoin-dev/June_2013/combined_address-collision-and-undependability.xml +++ b/static/bitcoin-dev/June_2013/combined_address-collision-and-undependability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - address collision and undependability - 2023-08-01T05:07:11.427833+00:00 + 2025-10-11T21:29:08.513417+00:00 + python-feedgen Byte Coin 2013-06-06 12:00:42+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - address collision and undependability - 2023-08-01T05:07:11.427833+00:00 + 2025-10-11T21:29:08.513561+00:00 - The checksum used in cryptocurrency addresses, such as Bitcoin, is not effective in preventing single character errors or transpositions. This means that valid addresses can differ by just one character or have a transposition of characters and still be considered valid. For example, the addresses 1ByteCoinAddressesMatch1kpCWNXmHKW and 1ByteCoinAddressesMatch1kpCxNXmHKW only differ by one character. Similarly, the addresses 1ByteCoinAddressesMatchcNN781jjwLY and 1ByteCoinAddressesMatchcNN718jjwLY only differ by one transposition.A discussion on the Bitcoin-dev forum revealed that it would be impractical to generate two Bitcoin addresses that differ in exactly one character modulo different checksums. In other words, it would be highly unlikely to find two addresses that are only one character different but have different checksums. This adds an extra layer of security to the address system.Furthermore, if one were to change one character of an address that has a verifiable signature, it would render the address undependable. This is due to the lack of a known private key for the modified address. Therefore, any changes made to an address with a verifiable signature would make it unreliable for use.This information was discussed during a conversation on the #bitcoin-dev channel, highlighting the importance of the checksum and the limitations of making changes to cryptocurrency addresses. 2013-06-06T12:00:42+00:00 + The checksum used in cryptocurrency addresses, such as Bitcoin, is not effective in preventing single character errors or transpositions. This means that valid addresses can differ by just one character or have a transposition of characters and still be considered valid. For example, the addresses 1ByteCoinAddressesMatch1kpCWNXmHKW and 1ByteCoinAddressesMatch1kpCxNXmHKW only differ by one character. Similarly, the addresses 1ByteCoinAddressesMatchcNN781jjwLY and 1ByteCoinAddressesMatchcNN718jjwLY only differ by one transposition.A discussion on the Bitcoin-dev forum revealed that it would be impractical to generate two Bitcoin addresses that differ in exactly one character modulo different checksums. In other words, it would be highly unlikely to find two addresses that are only one character different but have different checksums. This adds an extra layer of security to the address system.Furthermore, if one were to change one character of an address that has a verifiable signature, it would render the address undependable. This is due to the lack of a known private key for the modified address. Therefore, any changes made to an address with a verifiable signature would make it unreliable for use.This information was discussed during a conversation on the #bitcoin-dev channel, highlighting the importance of the checksum and the limitations of making changes to cryptocurrency addresses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml b/static/bitcoin-dev/June_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml index de09692020..565ace4cf4 100644 --- a/static/bitcoin-dev/June_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml +++ b/static/bitcoin-dev/June_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - is there a way to do bitcoin-staging? - 2023-08-01T04:55:26.435643+00:00 + 2025-10-11T21:29:42.523907+00:00 + python-feedgen Melvin Carvalho 2013-11-21 20:35:44+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - is there a way to do bitcoin-staging? - 2023-08-01T04:55:26.435643+00:00 + 2025-10-11T21:29:42.524119+00:00 - In a discussion thread from 2013, various ideas for improving the Bitcoin network were proposed. Adam Back suggested creating a live beta version of Bitcoin called "betacoin" for testing and development purposes. Alan Reiner and Peter Vessenes expressed interest in this idea, with the goal of speeding up Bitcoin development while maintaining its value and security. Meanwhile, Betacoin, a new cryptocurrency designed for faster transactions and lower fees, had already been introduced on the market, attracting interest and investment despite potential risks.The conversation also delved into reorganizing blockchain data into an authenticated tree indexed by TxOut script instead of tx-hash. This idea was put forth by Alan Reiner, who believed it could improve the efficiency of the network. Merge mining, where an alt-coin is mined alongside Bitcoin, using the same coins as Bitcoin main, was also discussed by Adam Back. Michael Gronager mentioned that he had already coded the authenticated data structure part and was considering incorporating p2pool style mining.Another topic of discussion was the use of Testnet as an alt-coin for testing non-standard transactions and developing new technologies and services. Dennison Bertram suggested that using Testnet as an alt-coin would provide a pseudo live environment for testing and incentivize people to try and exploit the system. The conversation also explored the advantages and limitations of using blockchain technology for notary and verification services.The conversation continued with various suggestions and proposals. Peter Todd proposed a "fair" merged mining system where miners would have to choose between mining an altcoin or Bitcoin to prove the sacrifice of potential Bitcoin earnings. Luke raised concerns about how this system would work for an altcoin whose price is independent of Bitcoin. Zooko expressed interest in implementing a "beta bitcoin blockchain," suggesting the creation of a common codebase for Bitcoin enthusiasts to experiment with.Adam Back asked if there was a way to experiment with new features without burdening the Bitcoin network. Merged mining and the use of an altcoin, such as bitcoin-staging, were suggested as possible solutions. Additionally, the reorganization of blockchain data into an authenticated tree indexed by TxOut script was discussed.Overall, these discussions revolved around finding ways to experiment with new features, ensure the sacrifice of potential Bitcoin earnings, and avoid diluting the value and parameters of Bitcoin. Merged mining and the use of altcoins like bitcoin-staging were considered as potential solutions to these challenges. 2013-11-21T20:35:44+00:00 + In a discussion thread from 2013, various ideas for improving the Bitcoin network were proposed. Adam Back suggested creating a live beta version of Bitcoin called "betacoin" for testing and development purposes. Alan Reiner and Peter Vessenes expressed interest in this idea, with the goal of speeding up Bitcoin development while maintaining its value and security. Meanwhile, Betacoin, a new cryptocurrency designed for faster transactions and lower fees, had already been introduced on the market, attracting interest and investment despite potential risks.The conversation also delved into reorganizing blockchain data into an authenticated tree indexed by TxOut script instead of tx-hash. This idea was put forth by Alan Reiner, who believed it could improve the efficiency of the network. Merge mining, where an alt-coin is mined alongside Bitcoin, using the same coins as Bitcoin main, was also discussed by Adam Back. Michael Gronager mentioned that he had already coded the authenticated data structure part and was considering incorporating p2pool style mining.Another topic of discussion was the use of Testnet as an alt-coin for testing non-standard transactions and developing new technologies and services. Dennison Bertram suggested that using Testnet as an alt-coin would provide a pseudo live environment for testing and incentivize people to try and exploit the system. The conversation also explored the advantages and limitations of using blockchain technology for notary and verification services.The conversation continued with various suggestions and proposals. Peter Todd proposed a "fair" merged mining system where miners would have to choose between mining an altcoin or Bitcoin to prove the sacrifice of potential Bitcoin earnings. Luke raised concerns about how this system would work for an altcoin whose price is independent of Bitcoin. Zooko expressed interest in implementing a "beta bitcoin blockchain," suggesting the creation of a common codebase for Bitcoin enthusiasts to experiment with.Adam Back asked if there was a way to experiment with new features without burdening the Bitcoin network. Merged mining and the use of an altcoin, such as bitcoin-staging, were suggested as possible solutions. Additionally, the reorganization of blockchain data into an authenticated tree indexed by TxOut script was discussed.Overall, these discussions revolved around finding ways to experiment with new features, ensure the sacrifice of potential Bitcoin earnings, and avoid diluting the value and parameters of Bitcoin. Merged mining and the use of altcoins like bitcoin-staging were considered as potential solutions to these challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_-QT-Feature-proposal-Displaying-current-Units-Changing-Units-with-status-bar-control-.xml b/static/bitcoin-dev/June_2014/combined_-QT-Feature-proposal-Displaying-current-Units-Changing-Units-with-status-bar-control-.xml index e7aec66c11..3e0c2d3165 100644 --- a/static/bitcoin-dev/June_2014/combined_-QT-Feature-proposal-Displaying-current-Units-Changing-Units-with-status-bar-control-.xml +++ b/static/bitcoin-dev/June_2014/combined_-QT-Feature-proposal-Displaying-current-Units-Changing-Units-with-status-bar-control-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [QT] Feature proposal: Displaying current Units/Changing Units with status bar control. - 2023-08-01T09:24:54.803575+00:00 + 2025-10-11T21:50:21.909959+00:00 + python-feedgen Angel Leon 2014-06-02 19:41:12+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - [QT] Feature proposal: Displaying current Units/Changing Units with status bar control. - 2023-08-01T09:24:54.803575+00:00 + 2025-10-11T21:50:21.910109+00:00 - Angel has shared an update regarding the addition of features to a project. The update includes showing the current unit on the header column title "Amount ($unitHere)" and adding a confirmation dialog to prevent users from changing the current unit of display by mistake. Gregory Maxwell suggests that if a global setting is added in the status bar, it should be done in a way where it's impossible for a stray keypress to switch it.In an email dated June 2, 2014, Wladimir expressed uncertainty about the potential benefits of a global setting in the status bar. He suggested that such a setting might make it more clear to users that multiple units can be selected. However, he also cautioned that any implementation should ensure that a stray keypress could not accidentally switch the setting, as this could result in serious consequences for the user.In a conversation between Angel Leon and Wladimir, they are discussing the addition of a global setting in the status bar for Bitcoin. Angel shares an attachment and asks for feedback on whether this would be valuable in terms of user experience. Wladimir responds that they already allow specifying a unit in all places where the user can specify a BTC amount, and show the unit in all places where amounts are shown except for tables. He suggests adding a [unit] in the table header and is unsure how much a global setting in the status bar would add. Additionally, he notes that it may make it more apparent to the user that multiple units can be selected. There is also a link to an issue on Github related to adding the [unit] in the table header.In this email exchange, Angel Leon proposes the idea of a status bar component that would show the current unit of display and allow users to easily change it. The context is around the default unit of display for Bitcoin transactions, with debate over whether it should be BTC or mBTC. The dropdown menu for changing the unit of display would be a common part of the layout, but a slight optimization suggested was to also include the unit in the transaction table header so that users don't have to think about the unit of their values. Leon includes an attachment of how the status bar component would look and asks for feedback before submitting a pull request.There has been a debate over the default unit of display to use for Bitcoin transactions. The conversation can be found on GitHub and was closed. Regular users may have trouble finding a way to change the current unit of display, so having a status bar component that shows the current unit of display and allows easy changing could be beneficial. The proposed component would show the current unit of display at all times and allow users to easily change it. Feedback is being requested before submitting a pull request to polish the component. 2014-06-02T19:41:12+00:00 + Angel has shared an update regarding the addition of features to a project. The update includes showing the current unit on the header column title "Amount ($unitHere)" and adding a confirmation dialog to prevent users from changing the current unit of display by mistake. Gregory Maxwell suggests that if a global setting is added in the status bar, it should be done in a way where it's impossible for a stray keypress to switch it.In an email dated June 2, 2014, Wladimir expressed uncertainty about the potential benefits of a global setting in the status bar. He suggested that such a setting might make it more clear to users that multiple units can be selected. However, he also cautioned that any implementation should ensure that a stray keypress could not accidentally switch the setting, as this could result in serious consequences for the user.In a conversation between Angel Leon and Wladimir, they are discussing the addition of a global setting in the status bar for Bitcoin. Angel shares an attachment and asks for feedback on whether this would be valuable in terms of user experience. Wladimir responds that they already allow specifying a unit in all places where the user can specify a BTC amount, and show the unit in all places where amounts are shown except for tables. He suggests adding a [unit] in the table header and is unsure how much a global setting in the status bar would add. Additionally, he notes that it may make it more apparent to the user that multiple units can be selected. There is also a link to an issue on Github related to adding the [unit] in the table header.In this email exchange, Angel Leon proposes the idea of a status bar component that would show the current unit of display and allow users to easily change it. The context is around the default unit of display for Bitcoin transactions, with debate over whether it should be BTC or mBTC. The dropdown menu for changing the unit of display would be a common part of the layout, but a slight optimization suggested was to also include the unit in the transaction table header so that users don't have to think about the unit of their values. Leon includes an attachment of how the status bar component would look and asks for feedback before submitting a pull request.There has been a debate over the default unit of display to use for Bitcoin transactions. The conversation can be found on GitHub and was closed. Regular users may have trouble finding a way to change the current unit of display, so having a status bar component that shows the current unit of display and allows easy changing could be beneficial. The proposed component would show the current unit of display at all times and allow users to easily change it. Feedback is being requested before submitting a pull request to polish the component. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_-ann-Bitcoin-Core-version-0-9-2-has-been-released.xml b/static/bitcoin-dev/June_2014/combined_-ann-Bitcoin-Core-version-0-9-2-has-been-released.xml index f31ac85832..ed57ee90bf 100644 --- a/static/bitcoin-dev/June_2014/combined_-ann-Bitcoin-Core-version-0-9-2-has-been-released.xml +++ b/static/bitcoin-dev/June_2014/combined_-ann-Bitcoin-Core-version-0-9-2-has-been-released.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [ann] Bitcoin Core version 0.9.2 has been released - 2023-08-01T09:35:23.341036+00:00 + 2025-10-11T21:49:18.132892+00:00 + python-feedgen Wladimir 2014-06-17 15:01:35+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [ann] Bitcoin Core version 0.9.2 has been released - 2023-08-01T09:35:23.341036+00:00 + 2025-10-11T21:49:18.133016+00:00 - Wladimir reported an issue on June 17, 2014, while running bitcoin-qt under Ubuntu 10.04. He received a "symbol lookup error" that indicated an undefined symbol "_ZN10QTextCodec11validCodecsEv". In response, Jesus asked if the issue occurred with the release candidate.According to Wladimir's message on the same day at 11:46, they had built against Qt 4.6 for Linux and filtered the symbols for libstdc++ and glibc to ensure compatibility with Debian 6+, Tails, Ubuntu 10.04, and CentOS 6.5. However, Jesús Cea Avión encountered an error when trying to run bitcoin-qt in the /tmp/bitcoin-0.9.2-linux/bin/64 directory. The error was related to an undefined symbol: _ZN10QTextCodec11validCodecsEv.Bitcoin Core version 0.9.2 has been released, featuring the latest version of OpenSSL that addresses a recently-discovered security flaw. This minor release also includes various bug fixes and improvements. It is highly recommended to upgrade, particularly as it restores compatibility with older Linux distributions such as Debian 6+, Tails, Ubuntu 10.04, and CentOS 6.5.The release notes highlight significant changes, including per-peer block download tracking, detection of stalled downloads, lowering of the paytxfee warning threshold from 0.25 BTC to 0.01 BTC, and fixes for coin control visual issues. Additionally, the deterministic build system previously used for Windows and Linux builds is now available for OSX as well. Users are encouraged to report any potential regressions on Github. 2014-06-17T15:01:35+00:00 + Wladimir reported an issue on June 17, 2014, while running bitcoin-qt under Ubuntu 10.04. He received a "symbol lookup error" that indicated an undefined symbol "_ZN10QTextCodec11validCodecsEv". In response, Jesus asked if the issue occurred with the release candidate.According to Wladimir's message on the same day at 11:46, they had built against Qt 4.6 for Linux and filtered the symbols for libstdc++ and glibc to ensure compatibility with Debian 6+, Tails, Ubuntu 10.04, and CentOS 6.5. However, Jesús Cea Avión encountered an error when trying to run bitcoin-qt in the /tmp/bitcoin-0.9.2-linux/bin/64 directory. The error was related to an undefined symbol: _ZN10QTextCodec11validCodecsEv.Bitcoin Core version 0.9.2 has been released, featuring the latest version of OpenSSL that addresses a recently-discovered security flaw. This minor release also includes various bug fixes and improvements. It is highly recommended to upgrade, particularly as it restores compatibility with older Linux distributions such as Debian 6+, Tails, Ubuntu 10.04, and CentOS 6.5.The release notes highlight significant changes, including per-peer block download tracking, detection of stalled downloads, lowering of the paytxfee warning threshold from 0.25 BTC to 0.01 BTC, and fixes for coin control visual issues. Additionally, the deterministic build system previously used for Windows and Linux builds is now available for OSX as well. Users are encouraged to report any potential regressions on Github. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_-error-Bitcoin-cannot-be-compiled-without-assertions-NOT.xml b/static/bitcoin-dev/June_2014/combined_-error-Bitcoin-cannot-be-compiled-without-assertions-NOT.xml index cb9f5bbf93..aba6a72168 100644 --- a/static/bitcoin-dev/June_2014/combined_-error-Bitcoin-cannot-be-compiled-without-assertions-NOT.xml +++ b/static/bitcoin-dev/June_2014/combined_-error-Bitcoin-cannot-be-compiled-without-assertions-NOT.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - # error "Bitcoin cannot be compiled without assertions." <<<<NOT - 2023-08-01T09:26:34.933676+00:00 + Combined summary - # error "Bitcoin cannot be compiled without assertions." <<<<NOT + 2025-10-11T21:49:58.542966+00:00 + python-feedgen Jeff Garzik 2014-06-07 00:57:04+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 - Combined summary - # error "Bitcoin cannot be compiled without assertions." <<<<NOT - 2023-08-01T09:26:34.934641+00:00 + Combined summary - # error "Bitcoin cannot be compiled without assertions." <<<<NOT + 2025-10-11T21:49:58.543162+00:00 - According to Jeff Garzik, a Bitcoin core developer and open source evangelist, it is important to compile in as many cheap, compiler-predictable asserts as possible into the production runtime. Expensive diagnostics should be compiled in and disabled by default at runtime to avoid slowing down the system. Jannis Froese suggested changing the current use of asserts to a definition that is independent of NDEBUG and introducing a second class of debugging asserts exclusively for expensive, redundant checks. These changes would resolve most concerns about the current use of asserts. Jannis Froese also recommended that assertion errors be handled differently, such as proposing a -reindex instead of raising an assertion error in certain cases. The writer of an email exchange agrees with the kernel's policy of using lightweight assertions and suggests using the glog library's CHECK macros to make software more robust. The current assertion system in Bitcoin Core is designed to prevent incorrect behavior, but it comes at the cost of meeting performance requirements. Assertions are intended for checks like ensuring a hash hasn't changed or that data structures are in sync. There have been concerns about the current use of assertions, and some suggest introducing debugging asserts exclusively for expensive, redundant checks. It is common for professional codebases to require assertions to be enabled, and Bitcoin Core currently fails to build if assertions are disabled. In a conversation from June 2014, Mike Hearn discusses the use of assertions with side effects in code. He explains that the codebase no longer uses them, but still requires them to be enabled to catch errors. He recommends using the glog library's CHECK macros, which print stack traces when they fail. In another email conversation, it is revealed that Ron's email was being spamfoldered due to Yahoo's DMARC policy and broken SF.net mailing list software. It is suggested to move away from SF.net for hosting mailing lists. The use of assert() in code is discussed, and it is stated that assert() should have no side effects. Bitcoin Core currently requires assertions to be enabled in order to build. The issue with the Bitcoin code for 0.9.x regarding assertions has been addressed through a commit and code with all side effects removed. Unit tests are available, along with resources on building Bitcoind.exe and alternate coin-qt.exe. The problem with assert() having side effects is explained in a book titled "Gotcha #28 Side Effects". It is questioned why these coding practices were not fixed earlier. 2014-06-07T00:57:04+00:00 + According to Jeff Garzik, a Bitcoin core developer and open source evangelist, it is important to compile in as many cheap, compiler-predictable asserts as possible into the production runtime. Expensive diagnostics should be compiled in and disabled by default at runtime to avoid slowing down the system. Jannis Froese suggested changing the current use of asserts to a definition that is independent of NDEBUG and introducing a second class of debugging asserts exclusively for expensive, redundant checks. These changes would resolve most concerns about the current use of asserts. Jannis Froese also recommended that assertion errors be handled differently, such as proposing a -reindex instead of raising an assertion error in certain cases. The writer of an email exchange agrees with the kernel's policy of using lightweight assertions and suggests using the glog library's CHECK macros to make software more robust. The current assertion system in Bitcoin Core is designed to prevent incorrect behavior, but it comes at the cost of meeting performance requirements. Assertions are intended for checks like ensuring a hash hasn't changed or that data structures are in sync. There have been concerns about the current use of assertions, and some suggest introducing debugging asserts exclusively for expensive, redundant checks. It is common for professional codebases to require assertions to be enabled, and Bitcoin Core currently fails to build if assertions are disabled. In a conversation from June 2014, Mike Hearn discusses the use of assertions with side effects in code. He explains that the codebase no longer uses them, but still requires them to be enabled to catch errors. He recommends using the glog library's CHECK macros, which print stack traces when they fail. In another email conversation, it is revealed that Ron's email was being spamfoldered due to Yahoo's DMARC policy and broken SF.net mailing list software. It is suggested to move away from SF.net for hosting mailing lists. The use of assert() in code is discussed, and it is stated that assert() should have no side effects. Bitcoin Core currently requires assertions to be enabled in order to build. The issue with the Bitcoin code for 0.9.x regarding assertions has been addressed through a commit and code with all side effects removed. Unit tests are available, along with resources on building Bitcoind.exe and alternate coin-qt.exe. The problem with assert() having side effects is explained in a book titled "Gotcha #28 Side Effects". It is questioned why these coding practices were not fixed earlier. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_0-confirmation-txs-using-replace-by-fee-and-game-theory.xml b/static/bitcoin-dev/June_2014/combined_0-confirmation-txs-using-replace-by-fee-and-game-theory.xml index ff7948b1ff..4cdb667551 100644 --- a/static/bitcoin-dev/June_2014/combined_0-confirmation-txs-using-replace-by-fee-and-game-theory.xml +++ b/static/bitcoin-dev/June_2014/combined_0-confirmation-txs-using-replace-by-fee-and-game-theory.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0 confirmation txs using replace-by-fee and game theory - 2023-08-01T08:58:18.899247+00:00 + 2025-10-11T21:50:15.535203+00:00 + python-feedgen Isidor Zeuner 2014-06-19 03:47:17+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - 0 confirmation txs using replace-by-fee and game theory - 2023-08-01T08:58:18.899247+00:00 + 2025-10-11T21:50:15.535378+00:00 - Chris Pacia expressed his disapproval of a proposed payment system that requires users to have double the funds they need for a purchase, calling it an "ugly hack." He argues that not everyone will have the extra funds available, making it inconvenient to use the system. However, it was noted that the scheme would not be mandatory, and users could still opt to wait for confirmations or rely on existing trust.Mike Hearn responded to concerns about double spend attacks on Bitcoin, stating that the risk of getting caught and blacklisted makes it unlikely for attackers to attempt such an attack. He acknowledges that a dishonest mining pool could potentially execute a double spend attack for a fee, but this would not be feasible for high-value items due to the need to wait for block confirmation. The concern lies with opportunistic attackers who try to take back a portion of their transaction every time they make a purchase. The number of such opportunists and the hashrate a dishonest pool can attract remains to be seen.Double spending is when a person spends the same digital currency twice, but Bitcoin has been designed to prevent this. Successfully double spending does not result in getting money back, but rather being chased down by a shopkeeper or being blacklisted. The concern arises when one could actually double spend, and the only thing preventing them from doing so is Bitcoin's technology.Chris Pacia suggested an idea for Bitcoin transactions to prevent double spending. The proposed method involves the customer signing a transaction and walking out of the shop with their purchase. They would then immediately sign and broadcast a double-spend transaction with a higher fee. The POS computer would detect the double spend and sound the shoplifting alarm. While some complications exist with this scheme, Pacia believes that the number of people who would attempt this irrational method is lower than those who would shoplift traditionally.Mike Hearn raises a concern about fraudulent double-spending activities in payment networks. He questions the possibility of a customer buying a phone on contract and paying an artificially lower price, then double-spending by paying double the lower price. However, he suggests that nearly all payment systems have the same issue of needing to enforce contracts out-of-band.Bitcoin's relevance should not be compared to a theoretical perfect peer-to-peer system but rather to traditional bank notes and credit cards. While Bitcoin may not be the ideal instant peer-to-peer serialization mechanism, it still holds value and relevance in the current financial landscape. Bitcoin faces challenges in terms of proof of work, but this does not diminish its significance.The proposed scheme to discourage Finney attacks by charging the maximum double spending fee possible does not solve the problem. Chris Pacia prefers the hassle of a green address notary instead. There are also complications with the scheme, such as needing to double balances and what happens if a shop is selling something on contract.A discussion on replace-by-fee and child-pays-for-parent addresses the success rate of double spends. It is suggested that these policies would significantly reduce the risk of double spending. However, there are concerns about sybil attacks and the requirement of online private keys to sign replacements. Enforcing hashing visibility of block contents can help detect double spends and make them beneficial for decentralization.Jorge Timón proposed a solution for 0 confirmation transactions, but Peter Todd conducted an experiment suggesting that double spending frequently works without miners using replace-by-fee. Todd argues that only confirmations are solid evidence that a transaction has reached mining power. Enforcing hasher visibility of the blocks they are mining allows any hasher to detect a double spend.The proposed scheme to discourage Finney attacks does not fully address the issue, and a better solution is suggested. The discussion also explores the concept of 0 confirmation transactions and their feasibility with replace-by-fee policies. 2014-06-19T03:47:17+00:00 + Chris Pacia expressed his disapproval of a proposed payment system that requires users to have double the funds they need for a purchase, calling it an "ugly hack." He argues that not everyone will have the extra funds available, making it inconvenient to use the system. However, it was noted that the scheme would not be mandatory, and users could still opt to wait for confirmations or rely on existing trust.Mike Hearn responded to concerns about double spend attacks on Bitcoin, stating that the risk of getting caught and blacklisted makes it unlikely for attackers to attempt such an attack. He acknowledges that a dishonest mining pool could potentially execute a double spend attack for a fee, but this would not be feasible for high-value items due to the need to wait for block confirmation. The concern lies with opportunistic attackers who try to take back a portion of their transaction every time they make a purchase. The number of such opportunists and the hashrate a dishonest pool can attract remains to be seen.Double spending is when a person spends the same digital currency twice, but Bitcoin has been designed to prevent this. Successfully double spending does not result in getting money back, but rather being chased down by a shopkeeper or being blacklisted. The concern arises when one could actually double spend, and the only thing preventing them from doing so is Bitcoin's technology.Chris Pacia suggested an idea for Bitcoin transactions to prevent double spending. The proposed method involves the customer signing a transaction and walking out of the shop with their purchase. They would then immediately sign and broadcast a double-spend transaction with a higher fee. The POS computer would detect the double spend and sound the shoplifting alarm. While some complications exist with this scheme, Pacia believes that the number of people who would attempt this irrational method is lower than those who would shoplift traditionally.Mike Hearn raises a concern about fraudulent double-spending activities in payment networks. He questions the possibility of a customer buying a phone on contract and paying an artificially lower price, then double-spending by paying double the lower price. However, he suggests that nearly all payment systems have the same issue of needing to enforce contracts out-of-band.Bitcoin's relevance should not be compared to a theoretical perfect peer-to-peer system but rather to traditional bank notes and credit cards. While Bitcoin may not be the ideal instant peer-to-peer serialization mechanism, it still holds value and relevance in the current financial landscape. Bitcoin faces challenges in terms of proof of work, but this does not diminish its significance.The proposed scheme to discourage Finney attacks by charging the maximum double spending fee possible does not solve the problem. Chris Pacia prefers the hassle of a green address notary instead. There are also complications with the scheme, such as needing to double balances and what happens if a shop is selling something on contract.A discussion on replace-by-fee and child-pays-for-parent addresses the success rate of double spends. It is suggested that these policies would significantly reduce the risk of double spending. However, there are concerns about sybil attacks and the requirement of online private keys to sign replacements. Enforcing hashing visibility of block contents can help detect double spends and make them beneficial for decentralization.Jorge Timón proposed a solution for 0 confirmation transactions, but Peter Todd conducted an experiment suggesting that double spending frequently works without miners using replace-by-fee. Todd argues that only confirmations are solid evidence that a transaction has reached mining power. Enforcing hasher visibility of the blocks they are mining allows any hasher to detect a double spend.The proposed scheme to discourage Finney attacks does not fully address the issue, and a better solution is suggested. The discussion also explores the concept of 0 confirmation transactions and their feasibility with replace-by-fee policies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_About-the-small-number-of-bitcoin-nodes.xml b/static/bitcoin-dev/June_2014/combined_About-the-small-number-of-bitcoin-nodes.xml index b5dcfae657..f9a0285fb7 100644 --- a/static/bitcoin-dev/June_2014/combined_About-the-small-number-of-bitcoin-nodes.xml +++ b/static/bitcoin-dev/June_2014/combined_About-the-small-number-of-bitcoin-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - About the small number of bitcoin nodes - 2023-08-01T09:19:54.827817+00:00 + 2025-10-11T21:50:02.791492+00:00 + python-feedgen Wladimir 2014-06-30 10:16:01+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - About the small number of bitcoin nodes - 2023-08-01T09:19:54.827817+00:00 + 2025-10-11T21:50:02.791661+00:00 - The task at hand is to create a graphical interface for bitcoind on Linux servers. This interface should display a summary of necessary data for node administrators in the Terminal using ASCII characters. A tool called bitcoind-ncurses has already been developed for this purpose and is available on Github, but it is still in its early stages and may require assistance to become a fully-functional node admin tool.In a May 2014 email thread between Jeff Garzik and Raúl Martínez, the possibility of adding bitcoind and Bitcoin Core to Linux repositories is discussed. However, certain conditions must be met before this can happen. These conditions include allowing bitcoin developers to dictate which dependent libraries are shipped with or built statically into the bitcoin binaries/libs, enabling fresh updates to older stable distributions, and having active maintainers who closely follow bitcoin development and release status. Matt C's PPA is mentioned as an example of meeting these conditions in Ubuntu. It is noted that while conditions (1) and (3) are feasible, condition (2) poses difficulties due to Debian and Ubuntu policies. Alternative mechanisms such as backports, volatile, and updates repositories could meet condition (2), but user intervention is required, and they are not enabled by default. Debian unstable allows for condition (2), but the package is blocked from transitioning to a stable release. Matt C's PPA remains the best option for meeting all three conditions in Ubuntu, and the Debian unstable package is deemed the most suitable for Debian, although both require users to add a line to their apt sources list.The Bitcoin network is exploring ways to limit rates and improve block download reliability. One suggestion is to introduce a service bit indicating that a node has chain data and is willing to Bloom filter it for others, without serving full block data. This would allow home users with low tolerance for block chain uploads to contribute useful services to the network. The idea of an "archival node" service bit is also proposed. It is suggested that the capabilities of "I have CPU and can filter" and "I have bandwidth and can serve" should be separated more explicitly.In an email exchange between Bjørn Øivind Bjørnsen and Wladimir, the implementation of network rate limiting in the bitcoin codebase is discussed. While Bjørnsen, who is unfamiliar with the codebase, suggests adding network rate limiting as a feature, Wladimir informs him that an old patch already exists for it but will only be merged when headers-first and parallel block download are in place. Wladimir explains that it is safe to limit rates once the node can download blocks from multiple peers simultaneously. He mentions the script in contrib/qos as a trick to limit rates but emphasizes that it needs to be widely available first.Adding a node with slow upstream/downstream speed may slow down the network's bootstrap process, but it does not harm the network itself. Existing issues can already cause the download process to take several days, and using the torrent is a faster alternative. However, a slow node may impede parallel downloading for remote peers.In a discussion thread initiated by Mike Hearn, the issue of network rate limiting in Bitcoin Core is raised. While acknowledging the importance of this feature, its implementation is recognized as a challenging task. Additionally, it is noted that throttling one's connection would cause remote nodes to give up and rely more on unthrottled peers. Bjørn Øivind asks if adding a node with slow upstream/downstream speed could harm the network and shares his own experience of using QoS to throttle his node. The article delves into the implementation of network rate limiting in Bitcoin Core. One challenge highlighted is that Bitcoin Core does not detect if a remote peer is working slowly and switch to a faster one. Throttling one's connection would lead remote nodes to give up and rely more on unthrottled peers. The suggested approach is to implement chain pruning, allowing the node to shovel bytes as fast as possible but limiting it based on the number of bytes available. Remote nodes pulling down the block chain can then switch between nodes to avoid overburdening a single node. Extending the p2p protocol is also proposed, with addr broadcasts and version messages indicating how much of the chain a peer is willing to serve. This would enable smarter peer selection during downloading. However, progress on these ideas awaits the completion of merging headers-first downloading. The article encourages experimentation with these approaches.A discussion among developers in 2014 focuses on the small number of Bitcoin nodes and potential vulnerabilities resulting from this. Financial incentives are proposed as a means to encourage more people to run nodes. A tool similar to Tor's 'arm' is suggested to provide users with information such as bandwidth usage, CPU usage, connected peers, and active configurations. Felipe Micaroni Lalli, the developer of Bitcoin Paranoid Android, shares his contact details at the end of the email.In May 201 2014-06-30T10:16:01+00:00 + The task at hand is to create a graphical interface for bitcoind on Linux servers. This interface should display a summary of necessary data for node administrators in the Terminal using ASCII characters. A tool called bitcoind-ncurses has already been developed for this purpose and is available on Github, but it is still in its early stages and may require assistance to become a fully-functional node admin tool.In a May 2014 email thread between Jeff Garzik and Raúl Martínez, the possibility of adding bitcoind and Bitcoin Core to Linux repositories is discussed. However, certain conditions must be met before this can happen. These conditions include allowing bitcoin developers to dictate which dependent libraries are shipped with or built statically into the bitcoin binaries/libs, enabling fresh updates to older stable distributions, and having active maintainers who closely follow bitcoin development and release status. Matt C's PPA is mentioned as an example of meeting these conditions in Ubuntu. It is noted that while conditions (1) and (3) are feasible, condition (2) poses difficulties due to Debian and Ubuntu policies. Alternative mechanisms such as backports, volatile, and updates repositories could meet condition (2), but user intervention is required, and they are not enabled by default. Debian unstable allows for condition (2), but the package is blocked from transitioning to a stable release. Matt C's PPA remains the best option for meeting all three conditions in Ubuntu, and the Debian unstable package is deemed the most suitable for Debian, although both require users to add a line to their apt sources list.The Bitcoin network is exploring ways to limit rates and improve block download reliability. One suggestion is to introduce a service bit indicating that a node has chain data and is willing to Bloom filter it for others, without serving full block data. This would allow home users with low tolerance for block chain uploads to contribute useful services to the network. The idea of an "archival node" service bit is also proposed. It is suggested that the capabilities of "I have CPU and can filter" and "I have bandwidth and can serve" should be separated more explicitly.In an email exchange between Bjørn Øivind Bjørnsen and Wladimir, the implementation of network rate limiting in the bitcoin codebase is discussed. While Bjørnsen, who is unfamiliar with the codebase, suggests adding network rate limiting as a feature, Wladimir informs him that an old patch already exists for it but will only be merged when headers-first and parallel block download are in place. Wladimir explains that it is safe to limit rates once the node can download blocks from multiple peers simultaneously. He mentions the script in contrib/qos as a trick to limit rates but emphasizes that it needs to be widely available first.Adding a node with slow upstream/downstream speed may slow down the network's bootstrap process, but it does not harm the network itself. Existing issues can already cause the download process to take several days, and using the torrent is a faster alternative. However, a slow node may impede parallel downloading for remote peers.In a discussion thread initiated by Mike Hearn, the issue of network rate limiting in Bitcoin Core is raised. While acknowledging the importance of this feature, its implementation is recognized as a challenging task. Additionally, it is noted that throttling one's connection would cause remote nodes to give up and rely more on unthrottled peers. Bjørn Øivind asks if adding a node with slow upstream/downstream speed could harm the network and shares his own experience of using QoS to throttle his node. The article delves into the implementation of network rate limiting in Bitcoin Core. One challenge highlighted is that Bitcoin Core does not detect if a remote peer is working slowly and switch to a faster one. Throttling one's connection would lead remote nodes to give up and rely more on unthrottled peers. The suggested approach is to implement chain pruning, allowing the node to shovel bytes as fast as possible but limiting it based on the number of bytes available. Remote nodes pulling down the block chain can then switch between nodes to avoid overburdening a single node. Extending the p2p protocol is also proposed, with addr broadcasts and version messages indicating how much of the chain a peer is willing to serve. This would enable smarter peer selection during downloading. However, progress on these ideas awaits the completion of merging headers-first downloading. The article encourages experimentation with these approaches.A discussion among developers in 2014 focuses on the small number of Bitcoin nodes and potential vulnerabilities resulting from this. Financial incentives are proposed as a means to encourage more people to run nodes. A tool similar to Tor's 'arm' is suggested to provide users with information such as bandwidth usage, CPU usage, connected peers, and active configurations. Felipe Micaroni Lalli, the developer of Bitcoin Paranoid Android, shares his contact details at the end of the email.In May 201 - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Another-uninitialized-memory-problem.xml b/static/bitcoin-dev/June_2014/combined_Another-uninitialized-memory-problem.xml index efd84e9e08..f61ab5a474 100644 --- a/static/bitcoin-dev/June_2014/combined_Another-uninitialized-memory-problem.xml +++ b/static/bitcoin-dev/June_2014/combined_Another-uninitialized-memory-problem.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Another uninitialized memory problem - 2023-08-01T09:25:31.724962+00:00 + 2025-10-11T21:50:11.288771+00:00 + python-feedgen Jeff Garzik 2014-06-03 17:40:38+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Another uninitialized memory problem - 2023-08-01T09:25:31.724962+00:00 + 2025-10-11T21:50:11.288913+00:00 - On June 2nd, 2014, Toshi Morita reported an uninitialized memory problem in the bitcoind software using valgrind. The error message indicated that there was a conditional jump or move in the program that depended on uninitialised value(s). The specific function where the error occurred was CWallet::LoadKeyMetadata in wallet.cpp, which is responsible for loading key metadata from the wallet database. Upon further investigation, it was found that the error originated from the ReadKeyValue function in walletdb.cpp, which is used to read data from the wallet database. This function is then called by CWalletDB::LoadWallet, and subsequently by CWallet::LoadWallet(bool&), both located in wallet.cpp. These functions are called by AppInit2 in init.cpp, and ultimately by the main function of the application, AppInit in bitcoind.cpp.Jeff Garzik, a Bitcoin core developer and open-source evangelist at BitPay Inc., responded to Toshi's email and expressed that he believes he has identified the issue. He mentioned that one side of the comparison had been fixed but the other still had the same problem. Toshi confirmed this and stated that he would investigate further once he was out of meetings or meeting preparations.In addition to the discussion about the uninitialized memory problem, Jeff also shared information about a new guide to graph databases called "Graph Databases" that can be downloaded for free. He ended the conversation by mentioning that he is a Bitcoin core developer and an open-source evangelist at BitPay Inc.Overall, the email conversation provides insights into the uninitialized memory problem in the bitcoind software, with Toshi reporting the issue, Jeff identifying the potential cause, and plans for further investigation. 2014-06-03T17:40:38+00:00 + On June 2nd, 2014, Toshi Morita reported an uninitialized memory problem in the bitcoind software using valgrind. The error message indicated that there was a conditional jump or move in the program that depended on uninitialised value(s). The specific function where the error occurred was CWallet::LoadKeyMetadata in wallet.cpp, which is responsible for loading key metadata from the wallet database. Upon further investigation, it was found that the error originated from the ReadKeyValue function in walletdb.cpp, which is used to read data from the wallet database. This function is then called by CWalletDB::LoadWallet, and subsequently by CWallet::LoadWallet(bool&), both located in wallet.cpp. These functions are called by AppInit2 in init.cpp, and ultimately by the main function of the application, AppInit in bitcoind.cpp.Jeff Garzik, a Bitcoin core developer and open-source evangelist at BitPay Inc., responded to Toshi's email and expressed that he believes he has identified the issue. He mentioned that one side of the comparison had been fixed but the other still had the same problem. Toshi confirmed this and stated that he would investigate further once he was out of meetings or meeting preparations.In addition to the discussion about the uninitialized memory problem, Jeff also shared information about a new guide to graph databases called "Graph Databases" that can be downloaded for free. He ended the conversation by mentioning that he is a Bitcoin core developer and an open-source evangelist at BitPay Inc.Overall, the email conversation provides insights into the uninitialized memory problem in the bitcoind software, with Toshi reporting the issue, Jeff identifying the potential cause, and plans for further investigation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Anyone-still-using-SOCKS4-.xml b/static/bitcoin-dev/June_2014/combined_Anyone-still-using-SOCKS4-.xml index 29366d1bdb..bb7d61cea8 100644 --- a/static/bitcoin-dev/June_2014/combined_Anyone-still-using-SOCKS4-.xml +++ b/static/bitcoin-dev/June_2014/combined_Anyone-still-using-SOCKS4-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Anyone still using SOCKS4? - 2023-08-01T09:30:05.654801+00:00 + 2025-10-11T21:50:24.032608+00:00 + python-feedgen Odinn Cyberguerrilla 2014-07-07 06:54:23+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Anyone still using SOCKS4? - 2023-08-01T09:30:05.654801+00:00 + 2025-10-11T21:50:24.032795+00:00 - In a discussion about SOCKS4 and SOCKS4a, Odinn Cyberguerrilla questioned whether SOCKS4 was designed to prevent information leaks. Wladimir clarified that while SOCKS4a supports DNS lookups on the server, it is not supported by bitcoin core. On the other hand, SOCKS5 can perform all the functions of both SOCKS4 and SOCKS4a. Wladimir encouraged contributions to SOCKS4a support if anyone is interested.The Tor project warns about SOCKS and DNS information leaks, suggesting that using SOCKS4A may be a better alternative. This warning is based on the fact that applications using SOCKS5 only provide Tor with an IP address, while applications that do DNS resolves themselves may leak information. In response to this, someone questioned the necessity of SOCKS4 and SOCKS4A. They also asked if there would be any issues with having a setting for SOCKS4A in a setup that includes Tor, Privoxy, I2P, and FoxyProxy together while running Bitcoin Core. Wladimir responded by stating that they plan on removing support for SOCKS4 in the next major release for two reasons: it would eliminate unused code paths and improve privacy as SOCKS5 allows DNS redirection. Additionally, SOCKS5 supports IPv6.In a discussion on the Bitcoin-development mailing list, Wladimir proposed removing support for SOCKS4 in the next major release. The reasons given were to remove unused code and enhance privacy by allowing DNS redirection. Another reason was that SOCKS5 supports IPv6. With no objections raised, the removal of SOCKS4 was set to proceed. The email also included a message promoting Bonita BPM Community Edition, an open source business process management suite built on Java and Eclipse.In an email dated June 11, 2014, Wladimir suggested removing support for SOCKS4 from the next major release. The reasons provided were to eliminate untested code paths and improve privacy with the use of SOCKS5, which offers DNS redirection. Additionally, SOCKS5 supports IPv6.In a recent message to the Bitcoin Core mailing list, Wladimir announced plans to remove support for SOCKS4-only proxy in the next major release. This decision was made due to the introduction of SOCKS5 in 1996 and the lack of excuses not to support it. The removal of support for SOCKS4-only proxy will eliminate outdated code paths and enhance privacy as SOCKS5 allows DNS redirection. Wladimir also inquired if anyone is currently using a SOCKS4-only proxy with Bitcoin Core. If no concerns or objections are raised, the removal of support for SOCKS4-only proxy will proceed as planned. It's important to note that this change will only impact users still utilizing SOCKS4-only proxy, while those already using SOCKS5 will not be affected. 2014-07-07T06:54:23+00:00 + In a discussion about SOCKS4 and SOCKS4a, Odinn Cyberguerrilla questioned whether SOCKS4 was designed to prevent information leaks. Wladimir clarified that while SOCKS4a supports DNS lookups on the server, it is not supported by bitcoin core. On the other hand, SOCKS5 can perform all the functions of both SOCKS4 and SOCKS4a. Wladimir encouraged contributions to SOCKS4a support if anyone is interested.The Tor project warns about SOCKS and DNS information leaks, suggesting that using SOCKS4A may be a better alternative. This warning is based on the fact that applications using SOCKS5 only provide Tor with an IP address, while applications that do DNS resolves themselves may leak information. In response to this, someone questioned the necessity of SOCKS4 and SOCKS4A. They also asked if there would be any issues with having a setting for SOCKS4A in a setup that includes Tor, Privoxy, I2P, and FoxyProxy together while running Bitcoin Core. Wladimir responded by stating that they plan on removing support for SOCKS4 in the next major release for two reasons: it would eliminate unused code paths and improve privacy as SOCKS5 allows DNS redirection. Additionally, SOCKS5 supports IPv6.In a discussion on the Bitcoin-development mailing list, Wladimir proposed removing support for SOCKS4 in the next major release. The reasons given were to remove unused code and enhance privacy by allowing DNS redirection. Another reason was that SOCKS5 supports IPv6. With no objections raised, the removal of SOCKS4 was set to proceed. The email also included a message promoting Bonita BPM Community Edition, an open source business process management suite built on Java and Eclipse.In an email dated June 11, 2014, Wladimir suggested removing support for SOCKS4 from the next major release. The reasons provided were to eliminate untested code paths and improve privacy with the use of SOCKS5, which offers DNS redirection. Additionally, SOCKS5 supports IPv6.In a recent message to the Bitcoin Core mailing list, Wladimir announced plans to remove support for SOCKS4-only proxy in the next major release. This decision was made due to the introduction of SOCKS5 in 1996 and the lack of excuses not to support it. The removal of support for SOCKS4-only proxy will eliminate outdated code paths and enhance privacy as SOCKS5 allows DNS redirection. Wladimir also inquired if anyone is currently using a SOCKS4-only proxy with Bitcoin Core. If no concerns or objections are raised, the removal of support for SOCKS4-only proxy will proceed as planned. It's important to note that this change will only impact users still utilizing SOCKS4-only proxy, while those already using SOCKS5 will not be affected. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_BIP38-Encrypted-Address-Discussion.xml b/static/bitcoin-dev/June_2014/combined_BIP38-Encrypted-Address-Discussion.xml index 91c6ae3e9d..dac7cae5b5 100644 --- a/static/bitcoin-dev/June_2014/combined_BIP38-Encrypted-Address-Discussion.xml +++ b/static/bitcoin-dev/June_2014/combined_BIP38-Encrypted-Address-Discussion.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP38 Encrypted Address Discussion - 2023-08-01T09:29:40.501110+00:00 + 2025-10-11T21:49:52.166025+00:00 + python-feedgen Gregory Maxwell 2014-06-09 18:23:17+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP38 Encrypted Address Discussion - 2023-08-01T09:29:40.501110+00:00 + 2025-10-11T21:49:52.166159+00:00 - Richard Moore, a developer, is proposing the inclusion of an extra byte in BIP38 wallets to enhance their security. Currently, the scrypt pbkdf used for (N, r, p) is (16384, 8, 8). However, with the emergence of more powerful scrypt mining ASICs, there is a growing concern about potential hacking attacks on wallets. By encoding the parameters used in an additional byte in the address, the security of important master keys can be significantly enhanced. For instance, this could safeguard a key that holds millions of dollars in cold storage for several years.Moore's proposal, which can be found on bitcointalk.org, is highly regarded as well thought out compared to BIP38. The proposal is currently undergoing revisions to support secret sharing. To implement the extra byte, Moore suggests using one byte, denoted as 'c', and employing a formula: N = 2 ** (c + 11), r = 2 ** c, and p = r. While using a full byte may seem excessive, the available space can be utilized for other purposes. For example, by using five bits, different parameter combinations can be achieved. When c = 0, the parameters would be (1024, 1, 1), which is the same as scrypt mining but requires twice the dkLength. With c = 3, the current specifications of (16384, 8, 8) are maintained. At the highest difficulty level, c = 31, the parameters become (2199023255552, 2147483648, 2147483648), which would require an immense amount of memory per hash.However, one major concern is ensuring backwards compatibility. The author suggests keeping the 6P the same, as it already requires an additional passphrase. To indicate that the address is adaptive, one of the reserved bits could be used. Nevertheless, this would result in a change in the decoded length of the address, potentially causing issues if bounds checks are not implemented. Alternatively, "6A" or "6p" could be used to denote an adaptive address, but the author is hesitant to introduce unnecessary variations in the namespace for a minor adjustment.In conclusion, Richard Moore's proposal to include an extra byte in BIP38 wallets aims to enhance their security against potential hacking attacks. By encoding the parameters used in the address, important master keys can be better protected. However, ensuring backwards compatibility and addressing changes in the decoded length of the address remain key considerations in implementing this proposal. 2014-06-09T18:23:17+00:00 + Richard Moore, a developer, is proposing the inclusion of an extra byte in BIP38 wallets to enhance their security. Currently, the scrypt pbkdf used for (N, r, p) is (16384, 8, 8). However, with the emergence of more powerful scrypt mining ASICs, there is a growing concern about potential hacking attacks on wallets. By encoding the parameters used in an additional byte in the address, the security of important master keys can be significantly enhanced. For instance, this could safeguard a key that holds millions of dollars in cold storage for several years.Moore's proposal, which can be found on bitcointalk.org, is highly regarded as well thought out compared to BIP38. The proposal is currently undergoing revisions to support secret sharing. To implement the extra byte, Moore suggests using one byte, denoted as 'c', and employing a formula: N = 2 ** (c + 11), r = 2 ** c, and p = r. While using a full byte may seem excessive, the available space can be utilized for other purposes. For example, by using five bits, different parameter combinations can be achieved. When c = 0, the parameters would be (1024, 1, 1), which is the same as scrypt mining but requires twice the dkLength. With c = 3, the current specifications of (16384, 8, 8) are maintained. At the highest difficulty level, c = 31, the parameters become (2199023255552, 2147483648, 2147483648), which would require an immense amount of memory per hash.However, one major concern is ensuring backwards compatibility. The author suggests keeping the 6P the same, as it already requires an additional passphrase. To indicate that the address is adaptive, one of the reserved bits could be used. Nevertheless, this would result in a change in the decoded length of the address, potentially causing issues if bounds checks are not implemented. Alternatively, "6A" or "6p" could be used to denote an adaptive address, but the author is hesitant to introduce unnecessary variations in the namespace for a minor adjustment.In conclusion, Richard Moore's proposal to include an extra byte in BIP38 wallets aims to enhance their security against potential hacking attacks. By encoding the parameters used in the address, important master keys can be better protected. However, ensuring backwards compatibility and addressing changes in the decoded length of the address remain key considerations in implementing this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Bill-Request-Message-another-Proposed-BIP-70-extension.xml b/static/bitcoin-dev/June_2014/combined_Bill-Request-Message-another-Proposed-BIP-70-extension.xml index ea1d616581..7f32bf2589 100644 --- a/static/bitcoin-dev/June_2014/combined_Bill-Request-Message-another-Proposed-BIP-70-extension.xml +++ b/static/bitcoin-dev/June_2014/combined_Bill-Request-Message-another-Proposed-BIP-70-extension.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bill Request Message - (another) Proposed BIP 70 extension - 2023-08-01T09:39:52.826509+00:00 + 2025-10-11T21:50:26.159073+00:00 + python-feedgen Mike Hearn 2014-06-25 14:38:06+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bill Request Message - (another) Proposed BIP 70 extension - 2023-08-01T09:39:52.826509+00:00 + 2025-10-11T21:50:26.159210+00:00 - The writer suggests that both BIP70 and Bluetooth payment mechanisms can coexist. For BIP70, a fixed QR code can be printed on paper next to a cash register. The PoS system would upload payment details to the server, which would then serve it when the user scans the QR code. Alternatively, Andreas' work on Bluetooth can be used where the QR code contains the BT MAC of the device, and the payment request is downloaded that way. This approach is already implemented. The writer believes that if a seller can scan a user's phone, the user's phone can also scan a rectangle near the sales counter. The QR code can also be an NFC tag with a little icon in the middle to indicate touch functionality.The proposal suggests extending BIP 70 to allow wallets to be scanned by merchant barcode readers instead of the other way around. This would make it easier for mobile wallets to request a bill and greatly ease checkouts at drive-throughs. The proposed message BillRequest includes fields such as a Unix timestamp for when the request was created, an optional expiration date, and a URL where a BIP70 payment request can be sent. To avoid confusion with existing QR code usage, the author recommends displaying a non-QR barcode like a PDF417 barcode to initiate the Bill Request flow. While NFC technology could also be used, it may not be suitable for smaller wearables entering the market. The author suggests exploring different technologies before writing a specification.The proposed BIP 70 extension would allow wallets to be scanned by merchant barcode readers, initiating a payment request flow. This is necessary for mobile wallets to request a bill and start a payment protocol flow. Currently, wallets either scan a merchant barcode or click on a URL link to initiate BIP70 payment flows. However, successful non-bitcoin mobile wallet apps allow for the wallet app to be scanned by the merchant. To promote bitcoin adoption, a mechanism for wallets to be scanned by merchant barcode readers at brick and mortar shops is needed. The BillRequest message includes a Unix timestamp for creation and an optional expiration date. It also includes a bill_request_uri, which can be a URL where a BIP70 payment request can be sent, or other URI options like "sms:860-555-1212" or "mailto:asdf at gmail.com." To avoid confusion with existing QR code usage, wallet apps are recommended to display a non-QR barcode like a PDF417 barcode to initiate the Bill Request flow. While NFC technology could potentially replace this extension, it is currently uncommon and may not be suitable for smaller wearables entering the market. The proposed BIP 70 extension would greatly improve checkouts at drive-throughs and allow merchants to utilize existing hardware. 2014-06-25T14:38:06+00:00 + The writer suggests that both BIP70 and Bluetooth payment mechanisms can coexist. For BIP70, a fixed QR code can be printed on paper next to a cash register. The PoS system would upload payment details to the server, which would then serve it when the user scans the QR code. Alternatively, Andreas' work on Bluetooth can be used where the QR code contains the BT MAC of the device, and the payment request is downloaded that way. This approach is already implemented. The writer believes that if a seller can scan a user's phone, the user's phone can also scan a rectangle near the sales counter. The QR code can also be an NFC tag with a little icon in the middle to indicate touch functionality.The proposal suggests extending BIP 70 to allow wallets to be scanned by merchant barcode readers instead of the other way around. This would make it easier for mobile wallets to request a bill and greatly ease checkouts at drive-throughs. The proposed message BillRequest includes fields such as a Unix timestamp for when the request was created, an optional expiration date, and a URL where a BIP70 payment request can be sent. To avoid confusion with existing QR code usage, the author recommends displaying a non-QR barcode like a PDF417 barcode to initiate the Bill Request flow. While NFC technology could also be used, it may not be suitable for smaller wearables entering the market. The author suggests exploring different technologies before writing a specification.The proposed BIP 70 extension would allow wallets to be scanned by merchant barcode readers, initiating a payment request flow. This is necessary for mobile wallets to request a bill and start a payment protocol flow. Currently, wallets either scan a merchant barcode or click on a URL link to initiate BIP70 payment flows. However, successful non-bitcoin mobile wallet apps allow for the wallet app to be scanned by the merchant. To promote bitcoin adoption, a mechanism for wallets to be scanned by merchant barcode readers at brick and mortar shops is needed. The BillRequest message includes a Unix timestamp for creation and an optional expiration date. It also includes a bill_request_uri, which can be a URL where a BIP70 payment request can be sent, or other URI options like "sms:860-555-1212" or "mailto:asdf at gmail.com." To avoid confusion with existing QR code usage, wallet apps are recommended to display a non-QR barcode like a PDF417 barcode to initiate the Bill Request flow. While NFC technology could potentially replace this extension, it is currently uncommon and may not be suitable for smaller wearables entering the market. The proposed BIP 70 extension would greatly improve checkouts at drive-throughs and allow merchants to utilize existing hardware. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Bitcoin-Core-0-9-2-release-candidate-1-is-available.xml b/static/bitcoin-dev/June_2014/combined_Bitcoin-Core-0-9-2-release-candidate-1-is-available.xml index 14170e6c0d..ea11bcfe04 100644 --- a/static/bitcoin-dev/June_2014/combined_Bitcoin-Core-0-9-2-release-candidate-1-is-available.xml +++ b/static/bitcoin-dev/June_2014/combined_Bitcoin-Core-0-9-2-release-candidate-1-is-available.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.9.2 release candidate 1 is available - 2023-08-01T09:27:00.110613+00:00 + 2025-10-11T21:49:56.415068+00:00 + python-feedgen Wladimir 2014-06-04 08:10:00+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.9.2 release candidate 1 is available - 2023-08-01T09:27:00.110613+00:00 + 2025-10-11T21:49:56.415216+00:00 - Bitcoin Core version 0.9.2rc1 has been released, offering bug fixes and minor improvements. Users can download the release from the Bitcoin website. The update includes new translations from Transifex, and appreciation is expressed for those who contributed translations.This latest release, 0.9.2rc1, features bug fixes and minor enhancements. It is important to note that release candidates are intended for extensive testing, so non-technical users may prefer to wait for the final version, 0.9.2, before upgrading or downgrading. It's worth mentioning that the 'chainstate' in this release may not always be compatible with previous versions.There are a few notable changes in this release. First, the deterministic build system, previously used for Windows and Linux builds, is now also employed for OSX builds. While the resulting executables have undergone significant testing, there is still a possibility of regressions. In addition, this version of Bitcoin Core for Linux is built against Qt 4.6 and filters symbols for libstdc++ and glibc.The RPC (Remote Procedure Call) interface has received some updates as well. New calls such as `getwalletinfo`, `getblockchaininfo`, and `getnetworkinfo` have been added, replacing the older and less organized `getinfo` call. Command-line options have been fixed to properly output `-printblocktree` and display an error message if ReadConfigFile fails.Improvements have been made to the block-chain handling and storage, including an upgrade of leveldb to version 1.17. The protocol and network code now feature per-peer block download tracking and stalled download detection, as well as a new DNS seed from bitnodes.io.The wallet functionality has also been enhanced. The GetAvailableCredit function now only runs GetHash() once per transaction, improving performance. Additionally, the paytxfee warning threshold has been lowered from 0.25 BTC to 0.01 BTC, and the BerkeleyDB version is now logged at startup.Several changes have been made to the build system. OSX build descriptors have been added to gitian, a tool for creating secure deterministic builds. Furthermore, the miniupnpc version has been upgraded to 1.9.Miscellaneous changes include replacing non-threadsafe C functions (such as gmtime, strerror, and setlocale), adding missing cs_main and wallet locks, avoiding exceptions at startup when the system locale is not recognized, and modifying bitrpc.py's raw_input to getpass for password input, concealing characters during command line input.The Bitcoin Core team expresses gratitude to all those who contributed to this release. 2014-06-04T08:10:00+00:00 + Bitcoin Core version 0.9.2rc1 has been released, offering bug fixes and minor improvements. Users can download the release from the Bitcoin website. The update includes new translations from Transifex, and appreciation is expressed for those who contributed translations.This latest release, 0.9.2rc1, features bug fixes and minor enhancements. It is important to note that release candidates are intended for extensive testing, so non-technical users may prefer to wait for the final version, 0.9.2, before upgrading or downgrading. It's worth mentioning that the 'chainstate' in this release may not always be compatible with previous versions.There are a few notable changes in this release. First, the deterministic build system, previously used for Windows and Linux builds, is now also employed for OSX builds. While the resulting executables have undergone significant testing, there is still a possibility of regressions. In addition, this version of Bitcoin Core for Linux is built against Qt 4.6 and filters symbols for libstdc++ and glibc.The RPC (Remote Procedure Call) interface has received some updates as well. New calls such as `getwalletinfo`, `getblockchaininfo`, and `getnetworkinfo` have been added, replacing the older and less organized `getinfo` call. Command-line options have been fixed to properly output `-printblocktree` and display an error message if ReadConfigFile fails.Improvements have been made to the block-chain handling and storage, including an upgrade of leveldb to version 1.17. The protocol and network code now feature per-peer block download tracking and stalled download detection, as well as a new DNS seed from bitnodes.io.The wallet functionality has also been enhanced. The GetAvailableCredit function now only runs GetHash() once per transaction, improving performance. Additionally, the paytxfee warning threshold has been lowered from 0.25 BTC to 0.01 BTC, and the BerkeleyDB version is now logged at startup.Several changes have been made to the build system. OSX build descriptors have been added to gitian, a tool for creating secure deterministic builds. Furthermore, the miniupnpc version has been upgraded to 1.9.Miscellaneous changes include replacing non-threadsafe C functions (such as gmtime, strerror, and setlocale), adding missing cs_main and wallet locks, avoiding exceptions at startup when the system locale is not recognized, and modifying bitrpc.py's raw_input to getpass for password input, concealing characters during command line input.The Bitcoin Core team expresses gratitude to all those who contributed to this release. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Bitcoin-Protocol-Specification.xml b/static/bitcoin-dev/June_2014/combined_Bitcoin-Protocol-Specification.xml index 30dc9a24fe..5b599fb136 100644 --- a/static/bitcoin-dev/June_2014/combined_Bitcoin-Protocol-Specification.xml +++ b/static/bitcoin-dev/June_2014/combined_Bitcoin-Protocol-Specification.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Protocol Specification - 2023-08-01T09:18:23.533727+00:00 + 2025-10-11T21:49:26.666888+00:00 + python-feedgen sickpig at gmail.com 2014-07-14 20:51:35+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Protocol Specification - 2023-08-01T09:18:23.533727+00:00 + 2025-10-11T21:49:26.667080+00:00 - On July 14, 2014, Mike Hearn raises the question of whether it is possible to create proper protocol specifications for Bitcoin other than the original C++ codebase. The response is affirmative, but with the caveat that previous attempts have failed due to the complexity of Bitcoin. Krzysztof Okupski and Jeff Garzik discuss renaming the document "Bitcoin Developer Specification" to "Bitcoin Developer Reference" and acknowledge its value as a description of the protocol for beginners. However, they also recognize that implementing the protocol based on the document would result in mistakes.Wladimir confirms that the resource in question has already been linked under "Additional Resources" on the developer guide. The conversation ends with a cautionary note to be careful with the usage of the word "specification".Krzysztof Okupski announces that the Bitcoin specification will now be under version control on GitHub. This move aims to increase the number of Bitcoin developers by making the system more understandable. The old link to the PDF version will also be kept updated.Matt Whitlock inquires about a specification document for Satoshi's P2P protocol, specifically how blocks and transactions are communicated over the network. A high-level guide is provided via a link to the developer guide on bitcoin.org, but it is noted that this guide is not a protocol specification. However, the Bitcoin wiki page and a forum thread on bitcointalk.org are suggested as resources for understanding the P2P protocol.Aaron Voisine shares a short description in code comments for breadwallet, and Matt Whitlock asks if anyone is working on a specification document for Satoshi's P2P protocol. Interest in understanding how blocks and transactions are communicated over the network is expressed.Isidor Zeuner shares a link to a PDF document about Bitcoin's design, and JMOlmos GMail asks if there is a translation available. Isidor suggests putting the document source under version control to facilitate tracking future protocol improvements.Krzysztof Okupski receives commendation for his work on a Bitcoin reference document, and the idea of putting the document source under version control is suggested. A request for translation assistance is made, and the email thread is sent to the Bitcoin-development mailing list.Krzysztof Okupski has created a document on Bitcoin's design that is praised as a great reference. The suggestion of putting the document source under version control is made, and Krzysztof thanks Isidor in advance for any further improvement proposals.Krzysztof Okupski posts a revised version of the Bitcoin Protocol Specification that incorporates feedback from Bitcoin Core developers and enthusiasts. He hopes the revised version will be useful to the community and welcomes additional improvement proposals.In May 2014, Krzysztof Okupski requests feedback on a Bitcoin protocol specification he has written. The purpose of the email is to improve the quality of the document and ask for suggestions and error corrections. A link to the front page of the document and contact information are provided.Overall, the context discusses various discussions and exchanges related to creating proper protocol specifications for Bitcoin, particularly the Bitcoin Developer Reference. The challenges and limitations of creating such specifications are highlighted, along with the value of the existing resources available. 2014-07-14T20:51:35+00:00 + On July 14, 2014, Mike Hearn raises the question of whether it is possible to create proper protocol specifications for Bitcoin other than the original C++ codebase. The response is affirmative, but with the caveat that previous attempts have failed due to the complexity of Bitcoin. Krzysztof Okupski and Jeff Garzik discuss renaming the document "Bitcoin Developer Specification" to "Bitcoin Developer Reference" and acknowledge its value as a description of the protocol for beginners. However, they also recognize that implementing the protocol based on the document would result in mistakes.Wladimir confirms that the resource in question has already been linked under "Additional Resources" on the developer guide. The conversation ends with a cautionary note to be careful with the usage of the word "specification".Krzysztof Okupski announces that the Bitcoin specification will now be under version control on GitHub. This move aims to increase the number of Bitcoin developers by making the system more understandable. The old link to the PDF version will also be kept updated.Matt Whitlock inquires about a specification document for Satoshi's P2P protocol, specifically how blocks and transactions are communicated over the network. A high-level guide is provided via a link to the developer guide on bitcoin.org, but it is noted that this guide is not a protocol specification. However, the Bitcoin wiki page and a forum thread on bitcointalk.org are suggested as resources for understanding the P2P protocol.Aaron Voisine shares a short description in code comments for breadwallet, and Matt Whitlock asks if anyone is working on a specification document for Satoshi's P2P protocol. Interest in understanding how blocks and transactions are communicated over the network is expressed.Isidor Zeuner shares a link to a PDF document about Bitcoin's design, and JMOlmos GMail asks if there is a translation available. Isidor suggests putting the document source under version control to facilitate tracking future protocol improvements.Krzysztof Okupski receives commendation for his work on a Bitcoin reference document, and the idea of putting the document source under version control is suggested. A request for translation assistance is made, and the email thread is sent to the Bitcoin-development mailing list.Krzysztof Okupski has created a document on Bitcoin's design that is praised as a great reference. The suggestion of putting the document source under version control is made, and Krzysztof thanks Isidor in advance for any further improvement proposals.Krzysztof Okupski posts a revised version of the Bitcoin Protocol Specification that incorporates feedback from Bitcoin Core developers and enthusiasts. He hopes the revised version will be useful to the community and welcomes additional improvement proposals.In May 2014, Krzysztof Okupski requests feedback on a Bitcoin protocol specification he has written. The purpose of the email is to improve the quality of the document and ask for suggestions and error corrections. A link to the front page of the document and contact information are provided.Overall, the context discusses various discussions and exchanges related to creating proper protocol specifications for Bitcoin, particularly the Bitcoin Developer Reference. The challenges and limitations of creating such specifications are highlighted, along with the value of the existing resources available. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Bitcoin-miner-heads-up-getwork-RPC-going-away.xml b/static/bitcoin-dev/June_2014/combined_Bitcoin-miner-heads-up-getwork-RPC-going-away.xml index 42344d22bc..692449e2b8 100644 --- a/static/bitcoin-dev/June_2014/combined_Bitcoin-miner-heads-up-getwork-RPC-going-away.xml +++ b/static/bitcoin-dev/June_2014/combined_Bitcoin-miner-heads-up-getwork-RPC-going-away.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Bitcoin miner heads-up: "getwork" RPC going away - 2023-08-01T09:29:17.306864+00:00 + Combined summary - Bitcoin miner heads-up: "getwork" RPC going away + 2025-10-11T21:49:50.043543+00:00 + python-feedgen Pieter Wuille 2014-06-21 15:14:15+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 - Combined summary - Bitcoin miner heads-up: "getwork" RPC going away - 2023-08-01T09:29:17.306864+00:00 + Combined summary - Bitcoin miner heads-up: "getwork" RPC going away + 2025-10-11T21:49:50.043703+00:00 - During a discussion on June 7th, 2014, it was decided to remove the "getwork" method in the next release of Bitcoin. Jeff Garzik pointed out that most pool servers had already switched to using "getblocktemplate" and "submitblock" years ago, as these methods offer a more flexible and scalable approach to mining. Wladimir confirmed this, explaining that the new methods were superior and provided more information on how "getblocktemplate" works. The decision to remove "getwork" received no objections, leading to the merging of the code on Bitcoin's Github repository.Jeff Garzik announced the plan to remove "getwork" on June 7, 2014, noting that most pool servers had already adopted the use of "getblocktemplate" and "submitblock" long ago. These alternative methods offer greater flexibility and scalability for mining operations. Further details on "getblocktemplate" can be found on https://en.bitcoin.it/wiki/Getblocktemplate. Wladimir did not provide any additional comments on the matter.The "getwork" method, which generates work for the Bitcoin network, has been largely unused on mainnet and other platforms for some time. This is due to its inability to meet the demands of the modern network. As a result, the upcoming release of Bitcoin plans to remove "getwork". It is worth noting that most pool servers have already transitioned away from "getwork" years ago. Jeff Garzik, a Bitcoin core developer and open source evangelist at BitPay, Inc., shared this information. 2014-06-21T15:14:15+00:00 + During a discussion on June 7th, 2014, it was decided to remove the "getwork" method in the next release of Bitcoin. Jeff Garzik pointed out that most pool servers had already switched to using "getblocktemplate" and "submitblock" years ago, as these methods offer a more flexible and scalable approach to mining. Wladimir confirmed this, explaining that the new methods were superior and provided more information on how "getblocktemplate" works. The decision to remove "getwork" received no objections, leading to the merging of the code on Bitcoin's Github repository.Jeff Garzik announced the plan to remove "getwork" on June 7, 2014, noting that most pool servers had already adopted the use of "getblocktemplate" and "submitblock" long ago. These alternative methods offer greater flexibility and scalability for mining operations. Further details on "getblocktemplate" can be found on https://en.bitcoin.it/wiki/Getblocktemplate. Wladimir did not provide any additional comments on the matter.The "getwork" method, which generates work for the Bitcoin network, has been largely unused on mainnet and other platforms for some time. This is due to its inability to meet the demands of the modern network. As a result, the upcoming release of Bitcoin plans to remove "getwork". It is worth noting that most pool servers have already transitioned away from "getwork" years ago. Jeff Garzik, a Bitcoin core developer and open source evangelist at BitPay, Inc., shared this information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_BlockPow-A-Practical-Proposal-to-prevent-mining-pools-AND-reduce-payoff-variance-.xml b/static/bitcoin-dev/June_2014/combined_BlockPow-A-Practical-Proposal-to-prevent-mining-pools-AND-reduce-payoff-variance-.xml index bfc78197f8..6a7a806f78 100644 --- a/static/bitcoin-dev/June_2014/combined_BlockPow-A-Practical-Proposal-to-prevent-mining-pools-AND-reduce-payoff-variance-.xml +++ b/static/bitcoin-dev/June_2014/combined_BlockPow-A-Practical-Proposal-to-prevent-mining-pools-AND-reduce-payoff-variance-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance: - 2023-08-01T09:36:23.722554+00:00 + 2025-10-11T21:49:33.039781+00:00 + python-feedgen Mark Friedenbach 2014-06-19 21:07:17+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance: - 2023-08-01T09:36:23.722554+00:00 + 2025-10-11T21:49:33.039936+00:00 - The discussion revolves around the challenges faced by mining pools in validating transactions and ensuring that miners are using up-to-date software. It is noted that full validation of every submitted share is difficult and economically unfeasible for medium-sized pools. To address this, Mark Friedenbach suggests stochastically validating a randomly selected sample of shares as a solution to detect invalid blocks and protect against incorrect mining software.In an email conversation between Bitcoin developer Mike Hearn and Slush, founder of Slush Pool, they discuss the lack of decentralization in mining pools despite the availability of the getblocktemplate (GBT) protocol. The reason is attributed to implementation issues with software such as libblkmaker, which does not support miners connecting to their own node and choosing their own blocks. Slush proposes using Stratum + Simplified Payment Verification (SPV) validation on the miner side as an alternative, allowing miners to switch to fallback pools when necessary.Kevin questions why pools are being punished, to which the writer responds that it is part of a trend to criticize labor specialization. The writer mentions scrypt mining, PoS, and MaidSafe as examples of this trend. The message concludes with a reminder to support online privacy through email encryption.Sergio Lerner proposes a setting to prevent mining pools and reduce variance in payoffs. This involves increasing the block rate and changing the Bitcoin Proof-of-Work (PoW), while still allowing current ASICs to work. The proposed BlockPow concept aims to discourage mining pools by increasing bandwidth requirements for pool administrators. Solo miners without a pool can potentially earn more than pool miners if block fees account for a significant portion of the block reward. However, the proposed method requires infrastructure that utilizes getblocktemplate technology for local transaction selection.The author suggests a potential solution to prevent mining pools and reduce payoff variance by increasing the block rate and changing the Bitcoin PoW. This would involve transmitting information overhead to discourage miners from joining pools. The proposed BlockPow method can be made partially compatible with Bitcoin ASICs by modifying the block template. It is noted that the effectiveness of this method depends on the time it takes to transmit a block, which should not be a problem if the cryptocurrency becomes popular. To implement this solution for Bitcoin, the block rate would need to be reduced and blocks kept at a certain size.Overall, these discussions highlight the challenges and potential solutions related to mining pool decentralization, transaction validation, and preventing mining pools while reducing payoff variance. 2014-06-19T21:07:17+00:00 + The discussion revolves around the challenges faced by mining pools in validating transactions and ensuring that miners are using up-to-date software. It is noted that full validation of every submitted share is difficult and economically unfeasible for medium-sized pools. To address this, Mark Friedenbach suggests stochastically validating a randomly selected sample of shares as a solution to detect invalid blocks and protect against incorrect mining software.In an email conversation between Bitcoin developer Mike Hearn and Slush, founder of Slush Pool, they discuss the lack of decentralization in mining pools despite the availability of the getblocktemplate (GBT) protocol. The reason is attributed to implementation issues with software such as libblkmaker, which does not support miners connecting to their own node and choosing their own blocks. Slush proposes using Stratum + Simplified Payment Verification (SPV) validation on the miner side as an alternative, allowing miners to switch to fallback pools when necessary.Kevin questions why pools are being punished, to which the writer responds that it is part of a trend to criticize labor specialization. The writer mentions scrypt mining, PoS, and MaidSafe as examples of this trend. The message concludes with a reminder to support online privacy through email encryption.Sergio Lerner proposes a setting to prevent mining pools and reduce variance in payoffs. This involves increasing the block rate and changing the Bitcoin Proof-of-Work (PoW), while still allowing current ASICs to work. The proposed BlockPow concept aims to discourage mining pools by increasing bandwidth requirements for pool administrators. Solo miners without a pool can potentially earn more than pool miners if block fees account for a significant portion of the block reward. However, the proposed method requires infrastructure that utilizes getblocktemplate technology for local transaction selection.The author suggests a potential solution to prevent mining pools and reduce payoff variance by increasing the block rate and changing the Bitcoin PoW. This would involve transmitting information overhead to discourage miners from joining pools. The proposed BlockPow method can be made partially compatible with Bitcoin ASICs by modifying the block template. It is noted that the effectiveness of this method depends on the time it takes to transmit a block, which should not be a problem if the cryptocurrency becomes popular. To implement this solution for Bitcoin, the block rate would need to be reduced and blocks kept at a certain size.Overall, these discussions highlight the challenges and potential solutions related to mining pool decentralization, transaction validation, and preventing mining pools while reducing payoff variance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Bloom-bait.xml b/static/bitcoin-dev/June_2014/combined_Bloom-bait.xml index 229a9d02e3..737f2a271a 100644 --- a/static/bitcoin-dev/June_2014/combined_Bloom-bait.xml +++ b/static/bitcoin-dev/June_2014/combined_Bloom-bait.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bloom bait - 2023-08-01T09:28:33.120863+00:00 + 2025-10-11T21:49:47.919017+00:00 + python-feedgen Mike Hearn 2014-06-11 08:57:29+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Bloom bait - 2023-08-01T09:28:33.120863+00:00 + 2025-10-11T21:49:47.919193+00:00 - In an email conversation, the author responds to a proposal for retroactively making Bloom filtering an optional part of the Bitcoin protocol. They argue that there is no evidence of a problem and implementing such a change would be a waste of time and resources. Instead, they suggest exploring alternatives such as block ranges in addr announcements or a new protocol optimized for serving the chain to better support archival nodes.The author also refutes the idea that a feature using resources for a legitimate reason should be classified as a Denial-of-Service (DoS) attack. They criticize attempts to reclassify any feature as an "attack" without justification, calling it silly.The article discusses how disk activity affects the performance of Bitcoin transactions. When nodes act as archival data sources, the page cache pressure is immense, causing disks to constantly run and impacting all clients. The author argues that NODE_BLOOM tends to be slower due to the working set almost always being larger than available page cache, leading to disk activity and delays. They also mention that prefix filtering may not save disk seeks and can even worsen the issue. However, prefix filtering requires additional disk space for per-block indexes, potentially slowing down block relay and increasing pressure on the page cache.It is suggested that resources such as disk I/O are not currently scarce, so it's more beneficial to focus on increasing usage rather than worrying about these resources. The article emphasizes the importance of avoiding hitting the disk, as once that happens, performance is already compromised.The conversation between Mike Hearn and Jeff Garzik revolves around the potential impact of privacy-focused bloom filters on the Bitcoin network. Mike argues that sending different bloom filters to different peers for privacy reasons would create an O(n) cost per query, greatly increasing the network load and resembling a DoS attack. He suggests that prefix filtering might be a better approach, but Jeff counters that it can cause pagecache pressure and disk activity issues. They both agree that there isn't a one-size-fits-all implementation for filters and that NODE_BLOOM should be used to advertise services with different tradeoffs. They also note the need for an upgrade to allow nodes to advertise ranges of blocks to address pagecache pressure.The article mentions that a NODE_BLOOM service bit is a reasonable way to implement bloom filters, with nodes without support for bloom filters using it as default. It is suggested that Bitcoinj is the only large-scale user of filtering, and peers advertising a lower protocol version than 70000 should disconnect themselves if they claim support for it but do not actually implement it.The conversation discusses the implementation of bloom filters for privacy reasons in the Bitcoin network. The writer explains that implementing this feature would be costly and resemble a denial-of-service attack due to the O(n) cost per query. Another person suggests that prefix filtering may not save disk seeks or could make the issue worse given the current network loads. The article argues that it's more important to focus on increasing usage rather than worrying about resources that are not currently scarce. It also suggests that bloom filters will eventually be replaced in the future.Mike Hearn and Peter Todd discuss the use of bloom filters in Bitcoin transactions. Mike argues that sending different bloom filters to different peers makes subsetting not unique to prefix filters. However, Peter explains that doing so would incur significant disk IO resource costs and that prefix filters provide a better alternative.In an email exchange, Gregory Maxwell and Peter Todd discuss the issue of data privacy in the blockchain. Todd suggests giving peers multiple prefixes corresponding to at least one address in a wallet with some false positive rate, instead of using brute-force prefix selection. Maxwell expresses surprise at using super public data in the same way as data shared between nodes. The conversation then turns to communication, with Todd suggesting the need to effectively communicate his arguments. The usefulness of prefix filtering for DH-private outputs is questioned, expressing concerns about prior information leaks becoming compromising in retrospect.Gregory Maxwell and Peter Todd discuss the privacy of blockchain data. They compare bloom filters and prefix filters used for transactions, noting their scaling differences. However, without brute forcing, prefix filters do not provide additional transactional graph privacy compared to bloom filters. The difference between super public data and data shared between trusted peers is also raised, questioning the assertion that they have "no different" privacy implications. Todd explains the concept of giving peers multiple prefixes with false positive rates corresponding to wallet addresses. He mentions having detailed this in a previous writeup on blockchain data privacy.In their conversation, Adam Back responds to a discussion on NODE_BLOOM and mentions that prefix brute forcing saves some resources but weakens privacy by providing an extra correlation hook. Peter Todd clarifies that both bloom filters and prefix filters are ways of providing a probabilistic filter for peer matching. Prefix filters have better scalability and compatibility with future miner committed indexes. They also offer better protection against hostile nodes by splitting queries across multiple peers. Todd emphasizes designing for privacy against future analysis of public information rather than privacy by argument to select non 2014-06-11T08:57:29+00:00 + In an email conversation, the author responds to a proposal for retroactively making Bloom filtering an optional part of the Bitcoin protocol. They argue that there is no evidence of a problem and implementing such a change would be a waste of time and resources. Instead, they suggest exploring alternatives such as block ranges in addr announcements or a new protocol optimized for serving the chain to better support archival nodes.The author also refutes the idea that a feature using resources for a legitimate reason should be classified as a Denial-of-Service (DoS) attack. They criticize attempts to reclassify any feature as an "attack" without justification, calling it silly.The article discusses how disk activity affects the performance of Bitcoin transactions. When nodes act as archival data sources, the page cache pressure is immense, causing disks to constantly run and impacting all clients. The author argues that NODE_BLOOM tends to be slower due to the working set almost always being larger than available page cache, leading to disk activity and delays. They also mention that prefix filtering may not save disk seeks and can even worsen the issue. However, prefix filtering requires additional disk space for per-block indexes, potentially slowing down block relay and increasing pressure on the page cache.It is suggested that resources such as disk I/O are not currently scarce, so it's more beneficial to focus on increasing usage rather than worrying about these resources. The article emphasizes the importance of avoiding hitting the disk, as once that happens, performance is already compromised.The conversation between Mike Hearn and Jeff Garzik revolves around the potential impact of privacy-focused bloom filters on the Bitcoin network. Mike argues that sending different bloom filters to different peers for privacy reasons would create an O(n) cost per query, greatly increasing the network load and resembling a DoS attack. He suggests that prefix filtering might be a better approach, but Jeff counters that it can cause pagecache pressure and disk activity issues. They both agree that there isn't a one-size-fits-all implementation for filters and that NODE_BLOOM should be used to advertise services with different tradeoffs. They also note the need for an upgrade to allow nodes to advertise ranges of blocks to address pagecache pressure.The article mentions that a NODE_BLOOM service bit is a reasonable way to implement bloom filters, with nodes without support for bloom filters using it as default. It is suggested that Bitcoinj is the only large-scale user of filtering, and peers advertising a lower protocol version than 70000 should disconnect themselves if they claim support for it but do not actually implement it.The conversation discusses the implementation of bloom filters for privacy reasons in the Bitcoin network. The writer explains that implementing this feature would be costly and resemble a denial-of-service attack due to the O(n) cost per query. Another person suggests that prefix filtering may not save disk seeks or could make the issue worse given the current network loads. The article argues that it's more important to focus on increasing usage rather than worrying about resources that are not currently scarce. It also suggests that bloom filters will eventually be replaced in the future.Mike Hearn and Peter Todd discuss the use of bloom filters in Bitcoin transactions. Mike argues that sending different bloom filters to different peers makes subsetting not unique to prefix filters. However, Peter explains that doing so would incur significant disk IO resource costs and that prefix filters provide a better alternative.In an email exchange, Gregory Maxwell and Peter Todd discuss the issue of data privacy in the blockchain. Todd suggests giving peers multiple prefixes corresponding to at least one address in a wallet with some false positive rate, instead of using brute-force prefix selection. Maxwell expresses surprise at using super public data in the same way as data shared between nodes. The conversation then turns to communication, with Todd suggesting the need to effectively communicate his arguments. The usefulness of prefix filtering for DH-private outputs is questioned, expressing concerns about prior information leaks becoming compromising in retrospect.Gregory Maxwell and Peter Todd discuss the privacy of blockchain data. They compare bloom filters and prefix filters used for transactions, noting their scaling differences. However, without brute forcing, prefix filters do not provide additional transactional graph privacy compared to bloom filters. The difference between super public data and data shared between trusted peers is also raised, questioning the assertion that they have "no different" privacy implications. Todd explains the concept of giving peers multiple prefixes with false positive rates corresponding to wallet addresses. He mentions having detailed this in a previous writeup on blockchain data privacy.In their conversation, Adam Back responds to a discussion on NODE_BLOOM and mentions that prefix brute forcing saves some resources but weakens privacy by providing an extra correlation hook. Peter Todd clarifies that both bloom filters and prefix filters are ways of providing a probabilistic filter for peer matching. Prefix filters have better scalability and compatibility with future miner committed indexes. They also offer better protection against hostile nodes by splitting queries across multiple peers. Todd emphasizes designing for privacy against future analysis of public information rather than privacy by argument to select non - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_CoinJoin-bounty-fund-question.xml b/static/bitcoin-dev/June_2014/combined_CoinJoin-bounty-fund-question.xml index 6ba3da2742..bdab91d409 100644 --- a/static/bitcoin-dev/June_2014/combined_CoinJoin-bounty-fund-question.xml +++ b/static/bitcoin-dev/June_2014/combined_CoinJoin-bounty-fund-question.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CoinJoin bounty fund question - 2023-08-01T09:36:02.510218+00:00 + 2025-10-11T21:49:54.291526+00:00 + python-feedgen Kristov Atlas 2014-06-17 23:14:58+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - CoinJoin bounty fund question - 2023-08-01T09:36:02.510218+00:00 + 2025-10-11T21:49:54.291683+00:00 - In a Bitcointalk forum thread, an announcement was made about a bounty, but the current status of the bounty remains uncertain as of January 2014. However, it is known that the multisig address associated with the bounty continues to accumulate bitcoins. There have been discussions on other mailing lists about the possibility of paying a portion or all of the bounty to the Dark Wallet team. For more information, Gregory Maxwell suggests visiting the Bitcointalk forum thread.In June 2014, Odinn Cyberguerrilla posted a question regarding the CoinJoin bounty fund address. He was looking for information on what happens to the funds in that address. The correct place to find more information was stated to be the Bitcointalk forum thread where the bounty was announced. The link to this thread is provided as https://bitcointalk.org/index.php?topic=279249.0.Odinn, a Bitcoin enthusiast, had encouraged people to donate to the CoinJoin bounty fund in 2013 after coming across some discussions on Reddit. The address associated with the fund is a P2SH/multisignature one. Odinn has noticed that CoinJoin has been implemented in various places since then, such as blockchain.info and Sharedcoin by github.com. Now, he is curious about what the CoinJoin bounty fund currently supports and where it is intended to go. He wonders if it will help fund other projects or not. According to Odinn, the right place to ask this question is the bitcoin-development list, rather than platforms like Twitter. 2014-06-17T23:14:58+00:00 + In a Bitcointalk forum thread, an announcement was made about a bounty, but the current status of the bounty remains uncertain as of January 2014. However, it is known that the multisig address associated with the bounty continues to accumulate bitcoins. There have been discussions on other mailing lists about the possibility of paying a portion or all of the bounty to the Dark Wallet team. For more information, Gregory Maxwell suggests visiting the Bitcointalk forum thread.In June 2014, Odinn Cyberguerrilla posted a question regarding the CoinJoin bounty fund address. He was looking for information on what happens to the funds in that address. The correct place to find more information was stated to be the Bitcointalk forum thread where the bounty was announced. The link to this thread is provided as https://bitcointalk.org/index.php?topic=279249.0.Odinn, a Bitcoin enthusiast, had encouraged people to donate to the CoinJoin bounty fund in 2013 after coming across some discussions on Reddit. The address associated with the fund is a P2SH/multisignature one. Odinn has noticed that CoinJoin has been implemented in various places since then, such as blockchain.info and Sharedcoin by github.com. Now, he is curious about what the CoinJoin bounty fund currently supports and where it is intended to go. He wonders if it will help fund other projects or not. According to Odinn, the right place to ask this question is the bitcoin-development list, rather than platforms like Twitter. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_DNS-seeds-unstable.xml b/static/bitcoin-dev/June_2014/combined_DNS-seeds-unstable.xml index 1ff0634952..acda1d4bf0 100644 --- a/static/bitcoin-dev/June_2014/combined_DNS-seeds-unstable.xml +++ b/static/bitcoin-dev/June_2014/combined_DNS-seeds-unstable.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DNS seeds unstable - 2023-08-01T09:15:49.337291+00:00 + 2025-10-11T21:49:20.256876+00:00 + python-feedgen Andreas Schildbach 2014-06-11 14:24:21+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - DNS seeds unstable - 2023-08-01T09:15:49.338289+00:00 + 2025-10-11T21:49:20.257057+00:00 - The Bitcoin DNS seed infrastructure has been identified as unstable, potentially due to a custom DNS implementation that is not fully compatible. In the past, bugs such as case-sensitive matches for domain names have also contributed to the problem. The current state of the seeds, as reported by bitcoinj, reveals that some are functioning properly while others are experiencing SERVFAIL issues. One seed is being tested across multiple ISPs and another is only returning one node.Telefónica, one of Europe's largest ISPs, has encountered difficulties with the testnet-seed.bitcoin.petertodd.org seed. While there is a desire to address the situation, the writer of the article lacks the necessary C writing skills to do so. Suggestions have been made to increase the number of seeders and enable zone transfers, allowing existing seeders to distribute their records to multiple servers running standard DNS servers like bind, among others.The writer proposes a potential fix by re-implementing everything in Java, although they acknowledge that others may not be satisfied with this solution. It is crucial for Bitcoin apps to account for the potential issues associated with relying solely on seeds, as they serve as a backup for peer exchange. Jeff Garzik, a Bitcoin core developer and open-source evangelist, emphasizes the importance of addressing the problem but notes that it could also be attributed to issues with bitcoinj or other layers within the app. Garzik works for BitPay, Inc., a payment service provider facilitating Bitcoin payments for merchants. 2014-06-11T14:24:21+00:00 + The Bitcoin DNS seed infrastructure has been identified as unstable, potentially due to a custom DNS implementation that is not fully compatible. In the past, bugs such as case-sensitive matches for domain names have also contributed to the problem. The current state of the seeds, as reported by bitcoinj, reveals that some are functioning properly while others are experiencing SERVFAIL issues. One seed is being tested across multiple ISPs and another is only returning one node.Telefónica, one of Europe's largest ISPs, has encountered difficulties with the testnet-seed.bitcoin.petertodd.org seed. While there is a desire to address the situation, the writer of the article lacks the necessary C writing skills to do so. Suggestions have been made to increase the number of seeders and enable zone transfers, allowing existing seeders to distribute their records to multiple servers running standard DNS servers like bind, among others.The writer proposes a potential fix by re-implementing everything in Java, although they acknowledge that others may not be satisfied with this solution. It is crucial for Bitcoin apps to account for the potential issues associated with relying solely on seeds, as they serve as a backup for peer exchange. Jeff Garzik, a Bitcoin core developer and open-source evangelist, emphasizes the importance of addressing the problem but notes that it could also be attributed to issues with bitcoinj or other layers within the app. Garzik works for BitPay, Inc., a payment service provider facilitating Bitcoin payments for merchants. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Fidelity-bonds-for-decentralized-instant-confirmation-guarantees.xml b/static/bitcoin-dev/June_2014/combined_Fidelity-bonds-for-decentralized-instant-confirmation-guarantees.xml index 773893bdc2..cd3a6991db 100644 --- a/static/bitcoin-dev/June_2014/combined_Fidelity-bonds-for-decentralized-instant-confirmation-guarantees.xml +++ b/static/bitcoin-dev/June_2014/combined_Fidelity-bonds-for-decentralized-instant-confirmation-guarantees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fidelity bonds for decentralized instant confirmation guarantees - 2023-08-01T09:34:11.667783+00:00 + 2025-10-11T21:49:28.793206+00:00 + python-feedgen Mark Friedenbach 2014-06-17 22:28:36+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Fidelity bonds for decentralized instant confirmation guarantees - 2023-08-01T09:34:11.667783+00:00 + 2025-10-11T21:49:28.793399+00:00 - In a mailing list discussion from 2014, the topic of establishing trust in the identity associated with an ECC key pair was raised. Daniel Rice questioned how to bootstrap trust in a future where multiple companies may release products similar to TREZOR. Peter Todd suggested two methods to establish trust: fidelity bonds or "trusted identities". Todd explained that a user could prove their trustworthiness by publicly throwing away resources. For example, they could transfer coins to a null address or create transactions with large and equal transaction fees. By doing so, the user would demonstrate that they value their identity and are willing to give up a significant amount of value to establish trust.Others could verify this trust purchase and accept zero-confirmation transactions at face value. If the user were to break their promise, others could publish their signed transaction to expose them as fraudulent. This would destroy the value needed to create trust in their identity.Todd acknowledged that the second paragraph of his suggestion was obsolete and proposed using announce-commit sacrifices or destruction of coins instead. He argued that sacrificing coins to fees encouraged mining centralization and should be avoided.Overall, the discussion centered around finding ways to establish trust in the identity associated with bitcoin addresses and prevent double spending. The suggested methods involved demonstrating the value placed on one's identity through deliberate resource depletion and allowing others to verify this trust purchase. 2014-06-17T22:28:36+00:00 + In a mailing list discussion from 2014, the topic of establishing trust in the identity associated with an ECC key pair was raised. Daniel Rice questioned how to bootstrap trust in a future where multiple companies may release products similar to TREZOR. Peter Todd suggested two methods to establish trust: fidelity bonds or "trusted identities". Todd explained that a user could prove their trustworthiness by publicly throwing away resources. For example, they could transfer coins to a null address or create transactions with large and equal transaction fees. By doing so, the user would demonstrate that they value their identity and are willing to give up a significant amount of value to establish trust.Others could verify this trust purchase and accept zero-confirmation transactions at face value. If the user were to break their promise, others could publish their signed transaction to expose them as fraudulent. This would destroy the value needed to create trust in their identity.Todd acknowledged that the second paragraph of his suggestion was obsolete and proposed using announce-commit sacrifices or destruction of coins instead. He argued that sacrificing coins to fees encouraged mining centralization and should be avoided.Overall, the discussion centered around finding ways to establish trust in the identity associated with bitcoin addresses and prevent double spending. The suggested methods involved demonstrating the value placed on one's identity through deliberate resource depletion and allowing others to verify this trust purchase. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Future-Feature-Proposal-getgist.xml b/static/bitcoin-dev/June_2014/combined_Future-Feature-Proposal-getgist.xml index b53bc3c4bd..463e2483a5 100644 --- a/static/bitcoin-dev/June_2014/combined_Future-Feature-Proposal-getgist.xml +++ b/static/bitcoin-dev/June_2014/combined_Future-Feature-Proposal-getgist.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Future Feature Proposal - getgist - 2023-08-01T09:27:18.018059+00:00 + 2025-10-11T21:49:22.388716+00:00 + python-feedgen Pieter Wuille 2014-06-05 19:34:15+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Future Feature Proposal - getgist - 2023-08-01T09:27:18.018059+00:00 + 2025-10-11T21:49:22.388880+00:00 - In an email exchange, Richard Moore suggests using the name "getcheckpoints()" as a function in Bitcoin, but finds it too long. He proposes using "getheaders()" instead to quickly grab headers before downloading full blocks. However, Pieter Wuille argues against the use of "getgist()", stating that the reference client's design focuses on validating received data as soon as possible. Pieter explains that "getheaders()" allows for immediate validation of headers and the building of a tree structure locally. This enables requesting blocks along the good branches of the tree in parallel from multiple peers. Pieter adds that there can be two independent synchronization mechanisms: downloading headers and validating them, and downloading blocks corresponding to validated headers.Richard Moore, the founder of Genetic Mistakes Software Inc., has been using "getheaders()" in their thick client to quickly grab all the headers before downloading full blocks. They believe there is a case for a "getgist()" call, where a gist of segment count 50 could be used to request 50 "getblocks()" each with a block_locator of one hash from the gist, providing 25,000 block hashes. The writer was considering using names like "getcheckpoints()" but found them too long.Richard Moore reaches out to the Bitcoin development team with an idea for implementing a "getgist()" command that would be fully backward compatible. The inputs to "getgist()" would be similar to "getheaders()" with an additional field, segment_count. The response would be a spaced out headers message, with block hashes aligned to every 2000th block from the first block hash. This proposed method could significantly increase the speed of syncing block headers.The discussion revolves around optimizing "getheaders()", a function used by Simplified Payment Verification (SPV) clients in Bitcoin. The function allows SPV clients to download blocks without downloading the entire blockchain. A Bitcoin developer proposes a new command, "getgist()", which could speed up the process of syncing block headers. The developer is currently testing the command to determine its potential speed gains. 2014-06-05T19:34:15+00:00 + In an email exchange, Richard Moore suggests using the name "getcheckpoints()" as a function in Bitcoin, but finds it too long. He proposes using "getheaders()" instead to quickly grab headers before downloading full blocks. However, Pieter Wuille argues against the use of "getgist()", stating that the reference client's design focuses on validating received data as soon as possible. Pieter explains that "getheaders()" allows for immediate validation of headers and the building of a tree structure locally. This enables requesting blocks along the good branches of the tree in parallel from multiple peers. Pieter adds that there can be two independent synchronization mechanisms: downloading headers and validating them, and downloading blocks corresponding to validated headers.Richard Moore, the founder of Genetic Mistakes Software Inc., has been using "getheaders()" in their thick client to quickly grab all the headers before downloading full blocks. They believe there is a case for a "getgist()" call, where a gist of segment count 50 could be used to request 50 "getblocks()" each with a block_locator of one hash from the gist, providing 25,000 block hashes. The writer was considering using names like "getcheckpoints()" but found them too long.Richard Moore reaches out to the Bitcoin development team with an idea for implementing a "getgist()" command that would be fully backward compatible. The inputs to "getgist()" would be similar to "getheaders()" with an additional field, segment_count. The response would be a spaced out headers message, with block hashes aligned to every 2000th block from the first block hash. This proposed method could significantly increase the speed of syncing block headers.The discussion revolves around optimizing "getheaders()", a function used by Simplified Payment Verification (SPV) clients in Bitcoin. The function allows SPV clients to download blocks without downloading the entire blockchain. A Bitcoin developer proposes a new command, "getgist()", which could speed up the process of syncing block headers. The developer is currently testing the command to determine its potential speed gains. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Going-to-tag-0-9-2-final.xml b/static/bitcoin-dev/June_2014/combined_Going-to-tag-0-9-2-final.xml index c8e4d22ffd..7769015e07 100644 --- a/static/bitcoin-dev/June_2014/combined_Going-to-tag-0-9-2-final.xml +++ b/static/bitcoin-dev/June_2014/combined_Going-to-tag-0-9-2-final.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Going to tag 0.9.2 final - 2023-08-01T09:31:13.490945+00:00 + 2025-10-11T21:49:45.791217+00:00 + python-feedgen Wladimir 2014-06-14 06:23:20+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Going to tag 0.9.2 final - 2023-08-01T09:31:13.491895+00:00 + 2025-10-11T21:49:45.791408+00:00 - In an email exchange on June 14, 2014, a user named Un Ix suggested offering a prize for anyone who could find malicious strings within the next hour. Wladimir cautioned against focusing on such a task and instead suggested looking out for icebergs over wrongly arranged deck chairs. The conversation does not provide any further context or information.In a conversation dated June 14, 2014, Un Ix joked about the translation process in Bitcoin's development. Wladimir responded that there is post-processing done on the script to remove stray control characters, but there is no check for number and presence of formatting characters. Wladimir usually checks this manually by looking through diffs, but he mentioned that it would be great if someone added that feature.The discussion is about the testing of the translation process in software development. The conversation started with a joke about offering prizes for spotting malicious strings within an hour. However, Matt Whitlock explains that it is more of an issue of accidental breakage than any maliciousness. A single character in the wrong place in a language bundle can cause runtime failure leading to issues like scrapping the whole release which could prompt users to question the quality control process of the dev team. Failure is defined as extra text that pushes a UI element down, making the button the user needs to click no longer visible. This kind of failure cannot be tested except by having a human being run through some example workflows, which presumably happens during the release process.During a conversation between Matt Whitlock and Un Ix, Un Ix joked about offering a prize for anyone who could spot any "malicious" strings within the next hour. However, Whitlock noted that the translation process is more concerned with accidental breakage than maliciousness. He explained that one character in the wrong place in a language bundle can cause the application to fail at runtime, which may not be immediately apparent when running in unaffected locales. While this kind of problem may not result in data or money loss, it could prompt users to question the dev team's quality control process and require them to scrap the whole release.In June 2014, a developer named Un Ix raised a question regarding malicious strings in a programming project. The concern was more about accidental breakage than intentional harm. A single character placed incorrectly in a language bundle could cause runtime failure, potentially leading to a scrapped release and damage to the dev team's reputation. Although not likely to result in data or monetary loss, it remains a significant issue for quality control.On the Bitcoin-development mailing list, there was a discussion regarding translation updates. Jeff Garzik suggested that there should be a translation freeze point to prevent any malicious changes made at the last minute in a language where maintainers may not be familiar with all the strings. Wladimir responded by saying that translations follow a very different cycle than the rest of the code and that entering and reviewing them happens inside Transifex. He also mentioned that someone could maliciously change strings but it is a small risk. Despite this, he decided not to do the translation update if it would make everyone happy.In an email conversation between Jeff Garzik and Wladimir on June 13, 2014, a discussion was had about translation freeze points. The concern raised was that someone could maliciously change the strings at the last minute in a language maintainers don't know well. Wladimir stated that translations follow a different cycle than the rest of the code and are entered and reviewed through Transifex. He also mentioned that if it makes everyone happy, he won't do the translation update. The topic of discussion was considered as bikeshedding and attracted much attention.On June 13, 2014, a discussion took place among Bitcoin developers regarding the potential risks of last-minute changes to language imports. Developer Wladimir suggested that if he did not hear anything, he would proceed with a last-minute language import. However, another developer, xor, expressed concern about making any changes between release candidates and releases in high-risk projects like Bitcoin. Jeff Garzik, a Bitcoin core developer, agreed with the principle that such changes could cause severe havoc and suggested implementing translation freeze points to address this issue. The developers also discussed the possibility of someone maliciously changing strings at the last minute in a language maintainers don't know well, which could pose a small holistic risk to the project.In June 2014, a discussion occurred between two individuals, xor and Wladimir, regarding a potential last-minute language import for Bitcoin Core. Xor expressed concern over making changes to high-risk projects like Bitcoin, as any mistakes could cause severe issues. They suggested that there should be no changes between release candidates and releases. The discussion also brought up the idea of having a release cycle policy for Bitcoin Core. Mission-critical projects typically have a code and resource freeze prior to tagging a release candidate, after which only critical bugfixes are allowed into the release branch 2014-06-14T06:23:20+00:00 + In an email exchange on June 14, 2014, a user named Un Ix suggested offering a prize for anyone who could find malicious strings within the next hour. Wladimir cautioned against focusing on such a task and instead suggested looking out for icebergs over wrongly arranged deck chairs. The conversation does not provide any further context or information.In a conversation dated June 14, 2014, Un Ix joked about the translation process in Bitcoin's development. Wladimir responded that there is post-processing done on the script to remove stray control characters, but there is no check for number and presence of formatting characters. Wladimir usually checks this manually by looking through diffs, but he mentioned that it would be great if someone added that feature.The discussion is about the testing of the translation process in software development. The conversation started with a joke about offering prizes for spotting malicious strings within an hour. However, Matt Whitlock explains that it is more of an issue of accidental breakage than any maliciousness. A single character in the wrong place in a language bundle can cause runtime failure leading to issues like scrapping the whole release which could prompt users to question the quality control process of the dev team. Failure is defined as extra text that pushes a UI element down, making the button the user needs to click no longer visible. This kind of failure cannot be tested except by having a human being run through some example workflows, which presumably happens during the release process.During a conversation between Matt Whitlock and Un Ix, Un Ix joked about offering a prize for anyone who could spot any "malicious" strings within the next hour. However, Whitlock noted that the translation process is more concerned with accidental breakage than maliciousness. He explained that one character in the wrong place in a language bundle can cause the application to fail at runtime, which may not be immediately apparent when running in unaffected locales. While this kind of problem may not result in data or money loss, it could prompt users to question the dev team's quality control process and require them to scrap the whole release.In June 2014, a developer named Un Ix raised a question regarding malicious strings in a programming project. The concern was more about accidental breakage than intentional harm. A single character placed incorrectly in a language bundle could cause runtime failure, potentially leading to a scrapped release and damage to the dev team's reputation. Although not likely to result in data or monetary loss, it remains a significant issue for quality control.On the Bitcoin-development mailing list, there was a discussion regarding translation updates. Jeff Garzik suggested that there should be a translation freeze point to prevent any malicious changes made at the last minute in a language where maintainers may not be familiar with all the strings. Wladimir responded by saying that translations follow a very different cycle than the rest of the code and that entering and reviewing them happens inside Transifex. He also mentioned that someone could maliciously change strings but it is a small risk. Despite this, he decided not to do the translation update if it would make everyone happy.In an email conversation between Jeff Garzik and Wladimir on June 13, 2014, a discussion was had about translation freeze points. The concern raised was that someone could maliciously change the strings at the last minute in a language maintainers don't know well. Wladimir stated that translations follow a different cycle than the rest of the code and are entered and reviewed through Transifex. He also mentioned that if it makes everyone happy, he won't do the translation update. The topic of discussion was considered as bikeshedding and attracted much attention.On June 13, 2014, a discussion took place among Bitcoin developers regarding the potential risks of last-minute changes to language imports. Developer Wladimir suggested that if he did not hear anything, he would proceed with a last-minute language import. However, another developer, xor, expressed concern about making any changes between release candidates and releases in high-risk projects like Bitcoin. Jeff Garzik, a Bitcoin core developer, agreed with the principle that such changes could cause severe havoc and suggested implementing translation freeze points to address this issue. The developers also discussed the possibility of someone maliciously changing strings at the last minute in a language maintainers don't know well, which could pose a small holistic risk to the project.In June 2014, a discussion occurred between two individuals, xor and Wladimir, regarding a potential last-minute language import for Bitcoin Core. Xor expressed concern over making changes to high-risk projects like Bitcoin, as any mistakes could cause severe issues. They suggested that there should be no changes between release candidates and releases. The discussion also brought up the idea of having a release cycle policy for Bitcoin Core. Mission-critical projects typically have a code and resource freeze prior to tagging a release candidate, after which only critical bugfixes are allowed into the release branch - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Incentivizing-the-running-of-full-nodes.xml b/static/bitcoin-dev/June_2014/combined_Incentivizing-the-running-of-full-nodes.xml index 5faaed0097..96a2bb64c3 100644 --- a/static/bitcoin-dev/June_2014/combined_Incentivizing-the-running-of-full-nodes.xml +++ b/static/bitcoin-dev/June_2014/combined_Incentivizing-the-running-of-full-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Incentivizing the running of full nodes - 2023-08-01T09:33:59.167138+00:00 + 2025-10-11T21:49:30.916645+00:00 + python-feedgen Odinn Cyberguerrilla 2014-06-17 17:47:53+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Incentivizing the running of full nodes - 2023-08-01T09:33:59.167138+00:00 + 2025-10-11T21:49:30.916821+00:00 - The email conversation revolves around the idea of incentivizing full nodes in the Bitcoin network. The proposal suggests implementing a reward system based on transaction fees or coin age, but concerns are raised about potential perverse incentives and the possibility of a network split between capitalist and socialist nodes. One solution proposed by Justus Ranvier is to have multiple independent transport networks for Bitcoin, such as ipv4, ipv6, Tor, and native_i2p, with information propagating across all of them through multihomed hosts acting as bridges.There is also discussion about the potential perverse incentives that may arise from paying for goods and services with Bitcoin through individual transactions rather than consolidated ones. However, it is argued that payment can be based on coin age or fees regardless of the number of transactions made, mitigating this concern.Justus Ranvier proposes a solution to limit the number of lottery tickets acquired by individuals in proof-of-work or proof-of-stake systems. This involves nodes competing with their peers in terms of relevancy, established by delivering newly-seen transactions first. Micropayment channels would handle payments between nodes, with well-connected nodes being net recipients of payments and low-uptime nodes being net payers. Price signals would match supply and demand, but concerns are raised about the incentives this may create for greater consumption of bandwidth and storage.Another proposal is brought up by Odinn Cyberguerrilla, suggesting a feature that would process small change and tiny transaction outputs to user-specified donation targets. Individuals running full nodes and donating would be entered into a decentralizing lottery, complementing the existing block reward system for miners. This aims to incentivize more individuals to run full nodes and reduce node loss over time.In addition, the falling number of nodes in the Bitcoin network is discussed as a concern. It is suggested that instead of incentivizing nodes with money, the focus should be on moving chain upload onto specialized "archival nodes" that could potentially charge for their services. Microdonations are also proposed as a way to incentivize giving, with participants running full nodes being entered into a decentralizing lottery and provided with incentives in the form of small to large bitcoin amounts.Overall, these proposals aim to address the issue of incentivizing individuals to run full nodes, increase node participation, and encourage giving to the Bitcoin network. 2014-06-17T17:47:53+00:00 + The email conversation revolves around the idea of incentivizing full nodes in the Bitcoin network. The proposal suggests implementing a reward system based on transaction fees or coin age, but concerns are raised about potential perverse incentives and the possibility of a network split between capitalist and socialist nodes. One solution proposed by Justus Ranvier is to have multiple independent transport networks for Bitcoin, such as ipv4, ipv6, Tor, and native_i2p, with information propagating across all of them through multihomed hosts acting as bridges.There is also discussion about the potential perverse incentives that may arise from paying for goods and services with Bitcoin through individual transactions rather than consolidated ones. However, it is argued that payment can be based on coin age or fees regardless of the number of transactions made, mitigating this concern.Justus Ranvier proposes a solution to limit the number of lottery tickets acquired by individuals in proof-of-work or proof-of-stake systems. This involves nodes competing with their peers in terms of relevancy, established by delivering newly-seen transactions first. Micropayment channels would handle payments between nodes, with well-connected nodes being net recipients of payments and low-uptime nodes being net payers. Price signals would match supply and demand, but concerns are raised about the incentives this may create for greater consumption of bandwidth and storage.Another proposal is brought up by Odinn Cyberguerrilla, suggesting a feature that would process small change and tiny transaction outputs to user-specified donation targets. Individuals running full nodes and donating would be entered into a decentralizing lottery, complementing the existing block reward system for miners. This aims to incentivize more individuals to run full nodes and reduce node loss over time.In addition, the falling number of nodes in the Bitcoin network is discussed as a concern. It is suggested that instead of incentivizing nodes with money, the focus should be on moving chain upload onto specialized "archival nodes" that could potentially charge for their services. Microdonations are also proposed as a way to incentivize giving, with participants running full nodes being entered into a decentralizing lottery and provided with incentives in the form of small to large bitcoin amounts.Overall, these proposals aim to address the issue of incentivizing individuals to run full nodes, increase node participation, and encourage giving to the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Lets-discuss-what-to-do-if-SHA256d-is-actually-broken.xml b/static/bitcoin-dev/June_2014/combined_Lets-discuss-what-to-do-if-SHA256d-is-actually-broken.xml index 48f42e74a8..feb75e81db 100644 --- a/static/bitcoin-dev/June_2014/combined_Lets-discuss-what-to-do-if-SHA256d-is-actually-broken.xml +++ b/static/bitcoin-dev/June_2014/combined_Lets-discuss-what-to-do-if-SHA256d-is-actually-broken.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Lets discuss what to do if SHA256d is actually broken - 2023-08-01T09:26:12.226207+00:00 + 2025-10-11T21:50:00.667892+00:00 + python-feedgen Rusty Russell 2014-06-05 06:09:15+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Lets discuss what to do if SHA256d is actually broken - 2023-08-01T09:26:12.226207+00:00 + 2025-10-11T21:50:00.668034+00:00 - Charlie Shrem reached out to Rusty Russell expressing interest in a project and asked if there was a write-up available for him to read. Rusty acknowledged some areas needing improvement but shared a link to his Github repository containing the code and an unfinished paper with graphs. The PDF was also included for easier reading.Rusty addressed the issue of SHA256d being broken on a Bitcoin-development mailing list. While Luke Dashjr stated that Bitcoin would fail entirely if SHA256d was broken, Rusty proposed a gradual transition scheme using solve-SHA256-then-solve-SHA3. The difficulty of SHA256 would decrease while SHA3 increases over the transition period. Estimating the SHA3 difficulty over time was a challenge, so Rusty suggested adjusting only the SHA3 target every second difficulty change. This scheme would work even if the initial SHA3 difficulty is off or if SHA2 breaks halfway through the transition.Satoshi's post on bitcointalk.org discussed the implications of SHA-256 being broken for Bitcoin. A gradual breakdown would allow for an orderly transition to a new hash function through software updates. In case of a sudden breakdown, an agreement on the honest blockchain would be needed before trouble starts, enabling the use of a new hash function. Ethan Heilman mentioned that an attack on the mining difficulty algorithm may not violate typical security properties of a cryptographic hash function. If miners discovered a method making it easier to find new blocks, they would need to switch to new ASICs and change the hash function without resistance. However, if the attack severely affected difficulty scaling and leading zeroes ran out, SHA256 collision resistance would be broken. Luke Dashjr emphasized that if SHA256d broke, Bitcoin would fail entirely. The possibility of fabricating past blocks was also discussed, suggesting a switch to a new hash function by requiring miners to find two blocks computed using different functions.A Freenet project developer named 'xor' expressed concern about the potential breaking of SHA256d and its impact on Bitcoin miners who have invested heavily in hardware for mining. The developer proposed introducing multiple hash functions in a chain, chaining SHA256d with a new hash function. This would allow existing ASIC owners to solve the old SHA proof of work using their hardware and use a general-purpose CPU for the second hash function. Difficulty migration could be achieved smoothly with this method.Rusty responded to Luke Dashjr's suggestion on Bitcoin's failure if SHA256d is broken by proposing a gradual transition scheme to avoid financial disruption. His scheme involved solve-SHA256-then-solve-SHA3, ramping down SHA256 difficulty and ramping up SHA3 difficulty over the transition period. Estimating the SHA3 difficulty posed a challenge, but Rusty's solution was adjusting only the SHA3 target on every second difficulty change. He offered to provide more details if anyone was interested.The article discusses the consequences of an attack on the mining difficulty algorithm and its implications for the security properties of a cryptographic hash function. If a method making it easier to find new blocks is discovered, it may or may not be implementable by current SHA256 ASIC hardware. If usable, there would be a brief period of overproduction followed by a difficulty adjustment. However, if the attack prevents difficulty scaling and leads to running out of leading zeroes, SHA256 collision resistance would be broken, necessitating an immediate switch to new hardware. If the attack is not usable, miners would still need to switch to new ASICs, allowing for a change in the hash function without resistance. Switching hash functions could be done through finding two blocks computed using different functions as a roadmap for infrastructure transition.Luke Dashjr pointed out that if SHA256d is broken, Bitcoin would fail entirely due to the ability to fabricate past blocks. However, weakening collision resistance does not violate typical security properties of a cryptographic hash function.In 2014, a user named xor expressed concerns about the potential consequences of SHA256d being broken in the Bitcoin network. They outlined worst-case scenarios, including reducing mining block work, instant mining, and fabricating past blocks, which could lead to complete failure of the Bitcoin network. The discussion prompted further exploration of solutions to prevent such an event. Luke-Jr responded, acknowledging the seriousness of the situation. It's important to note that since this discussion occurred, the Bitcoin network has not experienced a major security breach related to SHA256d. Nonetheless, ongoing development and vulnerabilities highlight the importance of strong security protocols in the cryptocurrency ecosystem.The author suggests that if SHA256d is broken in a way that allows for easier mining, simply replacing it with a new hash function would not be accepted by miners who have invested heavily in their hardware. Instead, the author proposes chaining SHA256d with a new hash function to allow existing ASIC owners to continue using their hardware while transitioning to the new algorithm smoothly. However, implementing this solution would require significant work, and precautions should be taken by the Bitcoin Core team for this potential 2014-06-05T06:09:15+00:00 + Charlie Shrem reached out to Rusty Russell expressing interest in a project and asked if there was a write-up available for him to read. Rusty acknowledged some areas needing improvement but shared a link to his Github repository containing the code and an unfinished paper with graphs. The PDF was also included for easier reading.Rusty addressed the issue of SHA256d being broken on a Bitcoin-development mailing list. While Luke Dashjr stated that Bitcoin would fail entirely if SHA256d was broken, Rusty proposed a gradual transition scheme using solve-SHA256-then-solve-SHA3. The difficulty of SHA256 would decrease while SHA3 increases over the transition period. Estimating the SHA3 difficulty over time was a challenge, so Rusty suggested adjusting only the SHA3 target every second difficulty change. This scheme would work even if the initial SHA3 difficulty is off or if SHA2 breaks halfway through the transition.Satoshi's post on bitcointalk.org discussed the implications of SHA-256 being broken for Bitcoin. A gradual breakdown would allow for an orderly transition to a new hash function through software updates. In case of a sudden breakdown, an agreement on the honest blockchain would be needed before trouble starts, enabling the use of a new hash function. Ethan Heilman mentioned that an attack on the mining difficulty algorithm may not violate typical security properties of a cryptographic hash function. If miners discovered a method making it easier to find new blocks, they would need to switch to new ASICs and change the hash function without resistance. However, if the attack severely affected difficulty scaling and leading zeroes ran out, SHA256 collision resistance would be broken. Luke Dashjr emphasized that if SHA256d broke, Bitcoin would fail entirely. The possibility of fabricating past blocks was also discussed, suggesting a switch to a new hash function by requiring miners to find two blocks computed using different functions.A Freenet project developer named 'xor' expressed concern about the potential breaking of SHA256d and its impact on Bitcoin miners who have invested heavily in hardware for mining. The developer proposed introducing multiple hash functions in a chain, chaining SHA256d with a new hash function. This would allow existing ASIC owners to solve the old SHA proof of work using their hardware and use a general-purpose CPU for the second hash function. Difficulty migration could be achieved smoothly with this method.Rusty responded to Luke Dashjr's suggestion on Bitcoin's failure if SHA256d is broken by proposing a gradual transition scheme to avoid financial disruption. His scheme involved solve-SHA256-then-solve-SHA3, ramping down SHA256 difficulty and ramping up SHA3 difficulty over the transition period. Estimating the SHA3 difficulty posed a challenge, but Rusty's solution was adjusting only the SHA3 target on every second difficulty change. He offered to provide more details if anyone was interested.The article discusses the consequences of an attack on the mining difficulty algorithm and its implications for the security properties of a cryptographic hash function. If a method making it easier to find new blocks is discovered, it may or may not be implementable by current SHA256 ASIC hardware. If usable, there would be a brief period of overproduction followed by a difficulty adjustment. However, if the attack prevents difficulty scaling and leads to running out of leading zeroes, SHA256 collision resistance would be broken, necessitating an immediate switch to new hardware. If the attack is not usable, miners would still need to switch to new ASICs, allowing for a change in the hash function without resistance. Switching hash functions could be done through finding two blocks computed using different functions as a roadmap for infrastructure transition.Luke Dashjr pointed out that if SHA256d is broken, Bitcoin would fail entirely due to the ability to fabricate past blocks. However, weakening collision resistance does not violate typical security properties of a cryptographic hash function.In 2014, a user named xor expressed concerns about the potential consequences of SHA256d being broken in the Bitcoin network. They outlined worst-case scenarios, including reducing mining block work, instant mining, and fabricating past blocks, which could lead to complete failure of the Bitcoin network. The discussion prompted further exploration of solutions to prevent such an event. Luke-Jr responded, acknowledging the seriousness of the situation. It's important to note that since this discussion occurred, the Bitcoin network has not experienced a major security breach related to SHA256d. Nonetheless, ongoing development and vulnerabilities highlight the importance of strong security protocols in the cryptocurrency ecosystem.The author suggests that if SHA256d is broken in a way that allows for easier mining, simply replacing it with a new hash function would not be accepted by miners who have invested heavily in their hardware. Instead, the author proposes chaining SHA256d with a new hash function to allow existing ASIC owners to continue using their hardware while transitioning to the new algorithm smoothly. However, implementing this solution would require significant work, and precautions should be taken by the Bitcoin Core team for this potential - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_NODE-BLOOM-service-bit.xml b/static/bitcoin-dev/June_2014/combined_NODE-BLOOM-service-bit.xml index ae8786c24a..956912283f 100644 --- a/static/bitcoin-dev/June_2014/combined_NODE-BLOOM-service-bit.xml +++ b/static/bitcoin-dev/June_2014/combined_NODE-BLOOM-service-bit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - NODE_BLOOM service bit - 2023-08-01T09:27:50.401280+00:00 + 2025-10-11T21:50:04.916896+00:00 + python-feedgen Adam Back 2014-06-06 10:45:43+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - NODE_BLOOM service bit - 2023-08-01T09:27:50.401280+00:00 + 2025-10-11T21:50:04.917031+00:00 - In a discussion thread, Adam Back and Peter Todd engaged in a debate regarding the privacy tradeoffs of prefix filters in Bitcoin. While Adam expressed concerns about the questionable privacy tradeoffs of prefix filters, Peter argued that they offer better scalability than bloom filters and allow efficient querying of multiple servers for blockchain data. Both agreed that prefixes weaken privacy by providing extra correlation hooks for elimination from the network graph of payments with mismatched prefixes.The discussion also touched upon the two types of privacy involved: privacy from the full node an SPV client is relying on to find its payments, and privacy from analysis of the public transaction graph. They acknowledged that the latter type of privacy is more damaging, and recent changes in Tor reflect this concern. Additionally, they emphasized the importance of designing for privacy against future analysis of public information rather than relying on privacy by argument to select non-hostile nodes.Adam Back raised concerns about the privacy tradeoffs involved with prefix filters in relation to stealth addresses, stating that prefix filters have the same privacy issues since they affect everyone, not just the user. Gregory Maxwell suggested that the use of ECDH addresses for all transactions, as seen in Bytecoin, Monero, and Fantom systems, has made prefixes unnecessary. Furthermore, the efficiency of Obelisk's indexing allowed Dark Wallet to not store transaction information between sessions until recently. Although prefix brute-forcing is not yet implemented, prefix filters are being implemented for lookups, offering server operators plausible deniability.The email conversation between Adam Back and Peter Todd revolved around the privacy tradeoffs of prefix filters compared to bloom filters. While prefix filters provide better scalability and efficiency, they also compromise user privacy. However, it was noted that prefix brute forcing is an engineering tradeoff that can be implemented using existing technology. The conversation concluded by suggesting that if someone can come up with a better solution and write code for it, it would be welcomed. Additionally, the design of stealth addresses allows for future blockchain filter upgrades to be added in a backwards compatible manner.Adam Back expressed his concerns regarding the privacy tradeoffs of prefix filters in Bloom filters, highlighting that they pose similar problems as stealth addresses and can have a cumulative effect on privacy for all users. While he supports scalability, efficiency, and decentralization, he believes it should not come at the expense of compromising privacy. Notably, the performance of systems like Bytecoin, Monero, and Fantom, which utilize ECDH addresses for all transactions, suggests that prefixes may not be necessary under current system rules.The idea of advertising NODE BLOOM as a service was deemed attractive, but the use of prefix filters raises privacy concerns. It was emphasized that while scalability, efficiency, and decentralization are important, they should not be prioritized over privacy. The impact on privacy is cumulative and affects everyone, not just individual users. This analogy was drawn to the issue of reused addresses, where local decisions can have global effects. Additionally, bloom filters were criticized for their high IO loads, which make them vulnerable to DoS attacks, making them less ideal for nodes that are IO constrained rather than bandwidth constrained. VPS setups were suggested as a potential solution to better serve the network by serving full blocks.The proposed update in the Bitcoin Improvement Proposal (BIP) aims to add NODE_BLOOM as a service bit, allowing nodes to announce their support for bloom filters. This update would bump the network protocol version number, and nodes that do not support bloom filters would be recommended to disconnect peers who send filter messages regardless. However, it is important to note that bloom filters are not universally supported and have poor scaling properties, which can result in high IO loads and susceptibility to DoS attacks. In the long term, prefix-based filtering is expected to replace bloom filters, with implementations already underway in electrum and obelisk. The proposal has been successfully deployed on Litecoin, Dogecoin, and other alternative cryptocurrencies without any issues. Gregory Maxwell also requested the assignment of a BIP number for the proposal. 2014-06-06T10:45:43+00:00 + In a discussion thread, Adam Back and Peter Todd engaged in a debate regarding the privacy tradeoffs of prefix filters in Bitcoin. While Adam expressed concerns about the questionable privacy tradeoffs of prefix filters, Peter argued that they offer better scalability than bloom filters and allow efficient querying of multiple servers for blockchain data. Both agreed that prefixes weaken privacy by providing extra correlation hooks for elimination from the network graph of payments with mismatched prefixes.The discussion also touched upon the two types of privacy involved: privacy from the full node an SPV client is relying on to find its payments, and privacy from analysis of the public transaction graph. They acknowledged that the latter type of privacy is more damaging, and recent changes in Tor reflect this concern. Additionally, they emphasized the importance of designing for privacy against future analysis of public information rather than relying on privacy by argument to select non-hostile nodes.Adam Back raised concerns about the privacy tradeoffs involved with prefix filters in relation to stealth addresses, stating that prefix filters have the same privacy issues since they affect everyone, not just the user. Gregory Maxwell suggested that the use of ECDH addresses for all transactions, as seen in Bytecoin, Monero, and Fantom systems, has made prefixes unnecessary. Furthermore, the efficiency of Obelisk's indexing allowed Dark Wallet to not store transaction information between sessions until recently. Although prefix brute-forcing is not yet implemented, prefix filters are being implemented for lookups, offering server operators plausible deniability.The email conversation between Adam Back and Peter Todd revolved around the privacy tradeoffs of prefix filters compared to bloom filters. While prefix filters provide better scalability and efficiency, they also compromise user privacy. However, it was noted that prefix brute forcing is an engineering tradeoff that can be implemented using existing technology. The conversation concluded by suggesting that if someone can come up with a better solution and write code for it, it would be welcomed. Additionally, the design of stealth addresses allows for future blockchain filter upgrades to be added in a backwards compatible manner.Adam Back expressed his concerns regarding the privacy tradeoffs of prefix filters in Bloom filters, highlighting that they pose similar problems as stealth addresses and can have a cumulative effect on privacy for all users. While he supports scalability, efficiency, and decentralization, he believes it should not come at the expense of compromising privacy. Notably, the performance of systems like Bytecoin, Monero, and Fantom, which utilize ECDH addresses for all transactions, suggests that prefixes may not be necessary under current system rules.The idea of advertising NODE BLOOM as a service was deemed attractive, but the use of prefix filters raises privacy concerns. It was emphasized that while scalability, efficiency, and decentralization are important, they should not be prioritized over privacy. The impact on privacy is cumulative and affects everyone, not just individual users. This analogy was drawn to the issue of reused addresses, where local decisions can have global effects. Additionally, bloom filters were criticized for their high IO loads, which make them vulnerable to DoS attacks, making them less ideal for nodes that are IO constrained rather than bandwidth constrained. VPS setups were suggested as a potential solution to better serve the network by serving full blocks.The proposed update in the Bitcoin Improvement Proposal (BIP) aims to add NODE_BLOOM as a service bit, allowing nodes to announce their support for bloom filters. This update would bump the network protocol version number, and nodes that do not support bloom filters would be recommended to disconnect peers who send filter messages regardless. However, it is important to note that bloom filters are not universally supported and have poor scaling properties, which can result in high IO loads and susceptibility to DoS attacks. In the long term, prefix-based filtering is expected to replace bloom filters, with implementations already underway in electrum and obelisk. The proposal has been successfully deployed on Litecoin, Dogecoin, and other alternative cryptocurrencies without any issues. Gregory Maxwell also requested the assignment of a BIP number for the proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_PSA-Please-sign-your-git-commits.xml b/static/bitcoin-dev/June_2014/combined_PSA-Please-sign-your-git-commits.xml index a56432e8e3..7c7e72498d 100644 --- a/static/bitcoin-dev/June_2014/combined_PSA-Please-sign-your-git-commits.xml +++ b/static/bitcoin-dev/June_2014/combined_PSA-Please-sign-your-git-commits.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - PSA: Please sign your git commits - 2023-08-01T09:22:12.107933+00:00 + 2025-10-11T21:49:35.162513+00:00 + python-feedgen Chris Beams 2014-06-09 15:34:18+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - PSA: Please sign your git commits - 2023-08-01T09:22:12.107933+00:00 + 2025-10-11T21:49:35.162689+00:00 - With the release of Git 2.0, automatic commit signing is now possible with the 'commit.gpgsign' configuration option. However, there is a negative impact on speed when a large number of commits are involved. The context discusses the concept of multisig, which is beneficial for irreversible actions but not necessary most of the time. Although it has been implemented in bitcoin wallets, no PGP developer or user ever thought to implement it. In a mailing list discussion, Jeff Garzik emphasized that current multi-sig wallet technology is arguably more secure than PGP keyring. In an email exchange between Wladimir and Chris Beams, Chris suggests complying with commit signing for future commits but questions its effectiveness. In a conversation between Jeff Garzik and Wladimir, they discuss the security of multi-sig wallets compared to PGP keyrings.The email conversation between David A. Harding and Chris Beams discusses how to enable signing commits by default in Git. They mention the use of a script that can be added to .git/hooks/post-commit and post-merge to ensure proper signature of commit messages. In a discussion thread from 2014, Mark Friedenbach posed an honest question about the benefits of signed commits in Git. In a discussion on the use of commit signing in Git, Chris Beams expresses his willingness to comply with it while also questioning its efficacy. In an email from May 2014, Chris Beams expressed his desire for a way to enable signing Git commits by default and noted that most people would probably forget to do it. In an email exchange between Chris Beams and Wladimir J. van der Laan, the two discussed the idea of requiring signed commits in Github development process. A contributor to Bitcoin Core development, Chris, has responded to a request from Wladimir to sign git commits.Bitcoin Core developers are advised to sign their git commits as it helps in ensuring the integrity of the tree. To sign a commit, users need to provide the `-S` flag or `--gpg-sign` to git commit when committing changes. Users can also retroactively sign previous commits using `--amend`, or use the interactive rebase command with 'edit' to go back further. It is important to note that rewriting history will require resigning as signatures will be lost. To check if commits are signed, users can use git log with show-signature. Pieter Wullie has created a script that simplifies merging and signing and can be found in contrib/devtools. The script can be used to merge pull requests and drop users into a shell to verify changes and test. 2014-06-09T15:34:18+00:00 + With the release of Git 2.0, automatic commit signing is now possible with the 'commit.gpgsign' configuration option. However, there is a negative impact on speed when a large number of commits are involved. The context discusses the concept of multisig, which is beneficial for irreversible actions but not necessary most of the time. Although it has been implemented in bitcoin wallets, no PGP developer or user ever thought to implement it. In a mailing list discussion, Jeff Garzik emphasized that current multi-sig wallet technology is arguably more secure than PGP keyring. In an email exchange between Wladimir and Chris Beams, Chris suggests complying with commit signing for future commits but questions its effectiveness. In a conversation between Jeff Garzik and Wladimir, they discuss the security of multi-sig wallets compared to PGP keyrings.The email conversation between David A. Harding and Chris Beams discusses how to enable signing commits by default in Git. They mention the use of a script that can be added to .git/hooks/post-commit and post-merge to ensure proper signature of commit messages. In a discussion thread from 2014, Mark Friedenbach posed an honest question about the benefits of signed commits in Git. In a discussion on the use of commit signing in Git, Chris Beams expresses his willingness to comply with it while also questioning its efficacy. In an email from May 2014, Chris Beams expressed his desire for a way to enable signing Git commits by default and noted that most people would probably forget to do it. In an email exchange between Chris Beams and Wladimir J. van der Laan, the two discussed the idea of requiring signed commits in Github development process. A contributor to Bitcoin Core development, Chris, has responded to a request from Wladimir to sign git commits.Bitcoin Core developers are advised to sign their git commits as it helps in ensuring the integrity of the tree. To sign a commit, users need to provide the `-S` flag or `--gpg-sign` to git commit when committing changes. Users can also retroactively sign previous commits using `--amend`, or use the interactive rebase command with 'edit' to go back further. It is important to note that rewriting history will require resigning as signatures will be lost. To check if commits are signed, users can use git log with show-signature. Pieter Wullie has created a script that simplifies merging and signing and can be found in contrib/devtools. The script can be used to merge pull requests and drop users into a shell to verify changes and test. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml b/static/bitcoin-dev/June_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml index 40d938ea1c..909bf3a188 100644 --- a/static/bitcoin-dev/June_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml +++ b/static/bitcoin-dev/June_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.614614+00:00 + 2025-10-11T21:49:41.537879+00:00 + python-feedgen Alex Kotenko 2014-07-02 08:49:10+00:00 @@ -271,13 +272,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.615612+00:00 + 2025-10-11T21:49:41.538156+00:00 - In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. 2014-07-02T08:49:10+00:00 + In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Plans-to-separate-wallet-from-core.xml b/static/bitcoin-dev/June_2014/combined_Plans-to-separate-wallet-from-core.xml index f3076685d0..7029a61777 100644 --- a/static/bitcoin-dev/June_2014/combined_Plans-to-separate-wallet-from-core.xml +++ b/static/bitcoin-dev/June_2014/combined_Plans-to-separate-wallet-from-core.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Plans to separate wallet from core - 2023-08-01T09:38:04.693756+00:00 + 2025-10-11T21:49:39.411439+00:00 + python-feedgen Wladimir 2014-06-25 05:43:23+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Plans to separate wallet from core - 2023-08-01T09:38:04.694755+00:00 + 2025-10-11T21:49:39.411642+00:00 - In a discussion on June 24, 2014, Justus Ranvier and Wladimir debated the differences between full nodes and wallets. Wladimir argued that full nodes and wallets have different usage scenarios, with wallets being online as little as possible and full nodes being online 24/7. Justus pointed out that btcd had done this right, with the wallet daemon running constantly in the background like a full node. He also noted that there was no need for a one-to-one relationship between wallets and GUIs. Finally, Justus suggested that the wallet should not be running as much as it currently is.Wladimir has argued that full nodes and wallets have different usage scenarios. Wallets should be online as little as possible, whereas full nodes should be online 24/7 to be useful to the network. The author of the post believes that btcd has done this right. The wallet runs constantly in the background, like a full node daemon. However, the GUI (which is distinct from the wallet) runs as little as possible, indicating that there doesn't need to be a 1:1 relationship between wallets and GUIs. Finally, the post encourages supporting online privacy by using email encryption whenever possible and provides a link to learn more about it.The author of this message argues that there is a difference between what the core nodes should be like and what the codebase core nodes are built from must support. He suggests that with sufficiently modularized code, one can build a binary that does full verification and maintains some indexes of some sort. However, the author believes that what we push for as the core nodes of the network should aim for purely verification and relay, and nothing else. Despite this, the author acknowledges that people will do things differently if the source code allows it.In an email exchange on 24th June 2014, Tamas Blummer raised a question about the advantage of having services like exchange and payment processors talking via the p2p protocol instead of something more direct when both processes are controlled by the same entity. Wladimir responded positively to the headers-first approach and clarified that nobody would be forced to separate the code in a way they don't like. However, he acknowledged the need for modularity and competing codebases and expressed his reservation about the argument that indexes must be necessarily out of the core. He suggested that the "core full-node" should maintain a minimal and non-optimized mining functionality, even if it is only used for testing purposes. Nevertheless, he agreed with everyone that the wallet code needs to be separated.In an email exchange on June 24, 2014, Mike Hearn and Wladimir discussed the concept of a single unified program versus a "bag of parts" made up of specialized tools. While Hearn argued for a unified program that would automatically figure out priorities, Wladimir preferred the idea of specialized tools maintained by experts in each area, allowing for experimentation and competition. Wladimir believed that innovation outside of the strict consensus rules of the blockchain should be possible without bottlenecks or widespread agreement, including P2P message extensions. He suggested that successful experiments could be merged into Bitcoin core, but pre-assembled bags could still be offered for user convenience.Pieter and the author of the context agree on keeping bitcoind as lean as possible, which means maintaining extra indices for others does not fit in. The idea of an 'index node' is suggested to be a different approach. The goal is to make a p2p node as useful as possible within its resource constraints and optional advertising of new indexes is the way to go. However, the author questions whether having an RPC or new socket based method would be too complex for users who just want to help out the system. Therefore, a single unified program that automatically figures it out rather than expecting users to assemble a bag of parts seems like a more practical goal.In an email exchange between Jorge Timón and Mike Hearn, they discussed separating the wallet code from the full node. The qt-wallet currently does not support SPV operation, so complex work should be done after the wallet is separated. The first version of the separated wallet should be functionally equivalent to today's wallet as a full node wallet. Some steps on the path of bitcoind towards SPV are also useful in general. For example, headers-first allows parallel block download, which would solve a lot ofWladimir has suggested using peer-to-peer (P2P) primarily for a Simplified Payment Verification (SPV) client as the least surprising option. He believes that separating the wallet from Bitcoin's core code would result in cleaner and more modular software. The plan is for bitcoind to support SPV mode and an optional trusted core by RPC for mempool/conflicted transaction validation. However, Wladimir is uncertain about this idea as pure-SPV wallets already work well.Jorge Timón also 2014-06-25T05:43:23+00:00 + In a discussion on June 24, 2014, Justus Ranvier and Wladimir debated the differences between full nodes and wallets. Wladimir argued that full nodes and wallets have different usage scenarios, with wallets being online as little as possible and full nodes being online 24/7. Justus pointed out that btcd had done this right, with the wallet daemon running constantly in the background like a full node. He also noted that there was no need for a one-to-one relationship between wallets and GUIs. Finally, Justus suggested that the wallet should not be running as much as it currently is.Wladimir has argued that full nodes and wallets have different usage scenarios. Wallets should be online as little as possible, whereas full nodes should be online 24/7 to be useful to the network. The author of the post believes that btcd has done this right. The wallet runs constantly in the background, like a full node daemon. However, the GUI (which is distinct from the wallet) runs as little as possible, indicating that there doesn't need to be a 1:1 relationship between wallets and GUIs. Finally, the post encourages supporting online privacy by using email encryption whenever possible and provides a link to learn more about it.The author of this message argues that there is a difference between what the core nodes should be like and what the codebase core nodes are built from must support. He suggests that with sufficiently modularized code, one can build a binary that does full verification and maintains some indexes of some sort. However, the author believes that what we push for as the core nodes of the network should aim for purely verification and relay, and nothing else. Despite this, the author acknowledges that people will do things differently if the source code allows it.In an email exchange on 24th June 2014, Tamas Blummer raised a question about the advantage of having services like exchange and payment processors talking via the p2p protocol instead of something more direct when both processes are controlled by the same entity. Wladimir responded positively to the headers-first approach and clarified that nobody would be forced to separate the code in a way they don't like. However, he acknowledged the need for modularity and competing codebases and expressed his reservation about the argument that indexes must be necessarily out of the core. He suggested that the "core full-node" should maintain a minimal and non-optimized mining functionality, even if it is only used for testing purposes. Nevertheless, he agreed with everyone that the wallet code needs to be separated.In an email exchange on June 24, 2014, Mike Hearn and Wladimir discussed the concept of a single unified program versus a "bag of parts" made up of specialized tools. While Hearn argued for a unified program that would automatically figure out priorities, Wladimir preferred the idea of specialized tools maintained by experts in each area, allowing for experimentation and competition. Wladimir believed that innovation outside of the strict consensus rules of the blockchain should be possible without bottlenecks or widespread agreement, including P2P message extensions. He suggested that successful experiments could be merged into Bitcoin core, but pre-assembled bags could still be offered for user convenience.Pieter and the author of the context agree on keeping bitcoind as lean as possible, which means maintaining extra indices for others does not fit in. The idea of an 'index node' is suggested to be a different approach. The goal is to make a p2p node as useful as possible within its resource constraints and optional advertising of new indexes is the way to go. However, the author questions whether having an RPC or new socket based method would be too complex for users who just want to help out the system. Therefore, a single unified program that automatically figures it out rather than expecting users to assemble a bag of parts seems like a more practical goal.In an email exchange between Jorge Timón and Mike Hearn, they discussed separating the wallet code from the full node. The qt-wallet currently does not support SPV operation, so complex work should be done after the wallet is separated. The first version of the separated wallet should be functionally equivalent to today's wallet as a full node wallet. Some steps on the path of bitcoind towards SPV are also useful in general. For example, headers-first allows parallel block download, which would solve a lot ofWladimir has suggested using peer-to-peer (P2P) primarily for a Simplified Payment Verification (SPV) client as the least surprising option. He believes that separating the wallet from Bitcoin's core code would result in cleaner and more modular software. The plan is for bitcoind to support SPV mode and an optional trusted core by RPC for mempool/conflicted transaction validation. However, Wladimir is uncertain about this idea as pure-SPV wallets already work well.Jorge Timón also - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Possible-attack-Keeping-unconfirmed-transactions.xml b/static/bitcoin-dev/June_2014/combined_Possible-attack-Keeping-unconfirmed-transactions.xml index fe21c4186d..6e0756dc06 100644 --- a/static/bitcoin-dev/June_2014/combined_Possible-attack-Keeping-unconfirmed-transactions.xml +++ b/static/bitcoin-dev/June_2014/combined_Possible-attack-Keeping-unconfirmed-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Possible attack: Keeping unconfirmed transactions - 2023-08-01T09:29:02.727830+00:00 + 2025-10-11T21:49:37.285607+00:00 + python-feedgen Raúl Martínez 2014-06-10 11:25:05+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Possible attack: Keeping unconfirmed transactions - 2023-08-01T09:29:02.728827+00:00 + 2025-10-11T21:49:37.285798+00:00 - A potential attack on Bitcoin transactions has been proposed on the Bitcoin-development mailing list. The attack involves storing an unconfirmed transaction sent by a payer for a few days and then relaying it back to the network or mining it using the receiver's hash power. In this attack, the receiver, Alice, can obtain the bitcoins without the knowledge of the payer, Bob. The attack can also be carried out when using the Payment Protocol, as Alice is responsible for relaying the transaction to the network. However, Toshi Morita argues that Alice cannot intercept the transaction and prevent the rest of the network from seeing it.An email conversation between Raúl Martínez and Andrew Poelstra further discusses the feasibility of such an attack. Poelstra emphasizes the importance of reusing inputs when resending a transaction to avoid spending twice as much money. He also warns that any user interface suggesting a "cancel" feature not based on respending inputs is dangerously broken. Once a signed transaction leaves the system, it cannot be undone, regardless of low fees or nonstandard status.The discussion on the Bitcoin-development mailing list clarifies that Alice cannot intercept a transaction made by Bob and prevent the rest of the network from seeing it. The merchant's server must determine the payment conditions before broadcasting the transaction on the Bitcoin peer-to-peer network. A possible attack scenario is presented where Alice stores an unconfirmed transaction for a few days and later relays it to the network, causing confusion for Bob. However, there is no known fix for this issue, and it remains uncertain if this type of attack is even possible.In summary, a potential attack on Bitcoin transactions involves storing an unconfirmed transaction for a few days and then relaying it to the network or mining it with the attacker's hash power. This allows the attacker to gain possession of the bitcoins without the payer's knowledge. The attack can work with or without using the Payment Protocol. It is unclear if there is a fix for this problem or if the attack is possible to execute. 2014-06-10T11:25:05+00:00 + A potential attack on Bitcoin transactions has been proposed on the Bitcoin-development mailing list. The attack involves storing an unconfirmed transaction sent by a payer for a few days and then relaying it back to the network or mining it using the receiver's hash power. In this attack, the receiver, Alice, can obtain the bitcoins without the knowledge of the payer, Bob. The attack can also be carried out when using the Payment Protocol, as Alice is responsible for relaying the transaction to the network. However, Toshi Morita argues that Alice cannot intercept the transaction and prevent the rest of the network from seeing it.An email conversation between Raúl Martínez and Andrew Poelstra further discusses the feasibility of such an attack. Poelstra emphasizes the importance of reusing inputs when resending a transaction to avoid spending twice as much money. He also warns that any user interface suggesting a "cancel" feature not based on respending inputs is dangerously broken. Once a signed transaction leaves the system, it cannot be undone, regardless of low fees or nonstandard status.The discussion on the Bitcoin-development mailing list clarifies that Alice cannot intercept a transaction made by Bob and prevent the rest of the network from seeing it. The merchant's server must determine the payment conditions before broadcasting the transaction on the Bitcoin peer-to-peer network. A possible attack scenario is presented where Alice stores an unconfirmed transaction for a few days and later relays it to the network, causing confusion for Bob. However, there is no known fix for this issue, and it remains uncertain if this type of attack is even possible.In summary, a potential attack on Bitcoin transactions involves storing an unconfirmed transaction for a few days and then relaying it to the network or mining it with the attacker's hash power. This allows the attacker to gain possession of the bitcoins without the payer's knowledge. The attack can work with or without using the Payment Protocol. It is unclear if there is a fix for this problem or if the attack is possible to execute. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Proposal-allocate-8-service-bits-for-experimental-use.xml b/static/bitcoin-dev/June_2014/combined_Proposal-allocate-8-service-bits-for-experimental-use.xml index d3ecbc19af..8cb364219f 100644 --- a/static/bitcoin-dev/June_2014/combined_Proposal-allocate-8-service-bits-for-experimental-use.xml +++ b/static/bitcoin-dev/June_2014/combined_Proposal-allocate-8-service-bits-for-experimental-use.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: allocate 8 service bits for experimental use - 2023-08-01T09:34:27.388274+00:00 + 2025-10-11T21:49:24.541164+00:00 + python-feedgen Jeff Garzik 2014-06-18 11:48:47+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Proposal: allocate 8 service bits for experimental use - 2023-08-01T09:34:27.389275+00:00 + 2025-10-11T21:49:24.541320+00:00 - In June 2014, Bitcoin developers engaged in discussions regarding the need for a wider extension namespace. One of the topics discussed was the use of service bit 26 in the implementation of replace-by-fee feature. This feature allows users to increase the fee of a transaction that has not yet been confirmed, increasing the chances of it being included in the next block. However, the use of replace-by-fee is controversial as it can lead to double-spending attacks.The discussion involved developers like Wladimir J. van der Laan, Jeff Garzik, Peter Todd, and Matt Whitlock. Wladimir suggested reserving bits 24-31 for temporary experiments, which Garzik agreed to. The conversation also explored the idea of using string-based name space for extensions instead of unreadable bits. Wladimir proposed adding a command called 'getextensions' to query the supported extensions, returning a list of extension strings or (extension, version) pairs. This would provide more freedom for alternative implementations to experiment with their own extensions and remove the political aspect of P2P network extensions.There was some debate about whether to use textual strings, UUIDs, or OIDs for the extension namespace. Whitlock suggested using fixed-length UUIDs or hierarchical OIDs to minimize bandwidth usage. However, Wladimir argued that human-readable strings would be more useful for statistics and peer list views. He also emphasized the importance of having google-able strings to understand unknown extensions.Overall, the discussions highlighted the ongoing efforts to improve the functionality and efficiency of the Bitcoin network. The inclusion of service bit 26 and the NODE_REPLACE_BY_FEE flag demonstrated the developers' commitment to exploring new features while addressing potential security concerns. 2014-06-18T11:48:47+00:00 + In June 2014, Bitcoin developers engaged in discussions regarding the need for a wider extension namespace. One of the topics discussed was the use of service bit 26 in the implementation of replace-by-fee feature. This feature allows users to increase the fee of a transaction that has not yet been confirmed, increasing the chances of it being included in the next block. However, the use of replace-by-fee is controversial as it can lead to double-spending attacks.The discussion involved developers like Wladimir J. van der Laan, Jeff Garzik, Peter Todd, and Matt Whitlock. Wladimir suggested reserving bits 24-31 for temporary experiments, which Garzik agreed to. The conversation also explored the idea of using string-based name space for extensions instead of unreadable bits. Wladimir proposed adding a command called 'getextensions' to query the supported extensions, returning a list of extension strings or (extension, version) pairs. This would provide more freedom for alternative implementations to experiment with their own extensions and remove the political aspect of P2P network extensions.There was some debate about whether to use textual strings, UUIDs, or OIDs for the extension namespace. Whitlock suggested using fixed-length UUIDs or hierarchical OIDs to minimize bandwidth usage. However, Wladimir argued that human-readable strings would be more useful for statistics and peer list views. He also emphasized the importance of having google-able strings to understand unknown extensions.Overall, the discussions highlighted the ongoing efforts to improve the functionality and efficiency of the Bitcoin network. The inclusion of service bit 26 and the NODE_REPLACE_BY_FEE flag demonstrated the developers' commitment to exploring new features while addressing potential security concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Proposal-relax-the-IsStandard-rules-for-P2SH-transactions.xml b/static/bitcoin-dev/June_2014/combined_Proposal-relax-the-IsStandard-rules-for-P2SH-transactions.xml index f189e18b50..575eecd1fc 100644 --- a/static/bitcoin-dev/June_2014/combined_Proposal-relax-the-IsStandard-rules-for-P2SH-transactions.xml +++ b/static/bitcoin-dev/June_2014/combined_Proposal-relax-the-IsStandard-rules-for-P2SH-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: relax the IsStandard rules for P2SH transactions - 2023-08-01T09:35:50.476716+00:00 + 2025-10-11T21:50:13.411742+00:00 + python-feedgen Peter Todd 2014-06-20 00:45:29+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Proposal: relax the IsStandard rules for P2SH transactions - 2023-08-01T09:35:50.477674+00:00 + 2025-10-11T21:50:13.411906+00:00 - In June 2014, Gavin Andresen, Chief Scientist of Bitcoin Foundation, discussed the consensus on soft-forks bumping version numbers. He suggested converting a related Github Gist into an informational BIP and addressed concerns about malleability being unrelated but related to IsStandard. He mentioned that detecting scripts leaving extra items on the stack would be handled in a separate code part from the implemented pull request. In another email conversation, Andresen and Peter Todd debated proposed changes to Bitcoin's code. Andresen suggested that all changes should be separate pull requests to ease review, while Todd argued that the malleability protection change had already undergone extensive review. They also discussed future soft-forks, whether they would require a transaction nVersion bump or if a whitelist was necessary for invalid up-version transactions. Todd noted that restricting opcodes to the softfork-safe subset was simple and could be removed later, along with concerns about "do-nothing" behavior and compatible evalscript() code.Andresen proposed opening up the "IsStandard" transaction rules in 2014 to allow more complicated transaction forms like multi-signature. However, he suggested keeping the limit of 15 ECDSA signature checking operations per transaction output to prevent attackers from creating a single standard transaction requiring significantly more validation. The proposal allowed any combination of enabled Script opcodes, but the reference implementation's wallet only recognized P2SH transactions using standard forms. Specialized wallets or applications were needed for new transaction forms. Wladimir supported the proposal, emphasizing the importance of lifting restrictions while maintaining DoS limits.The discussion focused on opening up the "IsStandard" transaction rules on the main Bitcoin network to enable multi-signature and other complex transaction forms. Two risks were identified: potential chain-forking bugs in seldom-used opcodes and the possibility of a denial-of-service attack through expensive-to-store-or-verify transactions. Despite these risks, Andresen believed the likelihood of bugs was low, and measures were in place to mitigate DoS attacks. The proposal allowed any Script with 15 or fewer signature operations as a P2SH script to be relayed and mined by the reference implementation. A soft-fork-safe patch was also being developed, defining an opcode whitelist and considering scripts leaving extra items on the stack as non-standard due to malleability concerns. The patch included all opcodes except invalid ones and OP_NOPx opcodes that could be redefined in future soft-forks. Rejecting transactions with unknown nVersion ensured that miners with older versions of Bitcoin Core would only mine transactions considered valid by the new version. Andresen offered to add these changes to an existing patch and submit a pull request.In summary, the discussion revolved around the consensus for soft-forks bumping version numbers and the suggestion to convert a Github Gist into an informational BIP. There were debates about separating changes into pull requests, the necessity of a whitelist for future soft-forks, and concerns about malleability and evalscript() code. The proposal aimed to open up "IsStandard" transaction rules to accommodate multi-signature and complex transaction forms, while mitigating risks through limitations and soft-fork-safe patches. Specialized wallets or applications would be required for new transaction forms. 2014-06-20T00:45:29+00:00 + In June 2014, Gavin Andresen, Chief Scientist of Bitcoin Foundation, discussed the consensus on soft-forks bumping version numbers. He suggested converting a related Github Gist into an informational BIP and addressed concerns about malleability being unrelated but related to IsStandard. He mentioned that detecting scripts leaving extra items on the stack would be handled in a separate code part from the implemented pull request. In another email conversation, Andresen and Peter Todd debated proposed changes to Bitcoin's code. Andresen suggested that all changes should be separate pull requests to ease review, while Todd argued that the malleability protection change had already undergone extensive review. They also discussed future soft-forks, whether they would require a transaction nVersion bump or if a whitelist was necessary for invalid up-version transactions. Todd noted that restricting opcodes to the softfork-safe subset was simple and could be removed later, along with concerns about "do-nothing" behavior and compatible evalscript() code.Andresen proposed opening up the "IsStandard" transaction rules in 2014 to allow more complicated transaction forms like multi-signature. However, he suggested keeping the limit of 15 ECDSA signature checking operations per transaction output to prevent attackers from creating a single standard transaction requiring significantly more validation. The proposal allowed any combination of enabled Script opcodes, but the reference implementation's wallet only recognized P2SH transactions using standard forms. Specialized wallets or applications were needed for new transaction forms. Wladimir supported the proposal, emphasizing the importance of lifting restrictions while maintaining DoS limits.The discussion focused on opening up the "IsStandard" transaction rules on the main Bitcoin network to enable multi-signature and other complex transaction forms. Two risks were identified: potential chain-forking bugs in seldom-used opcodes and the possibility of a denial-of-service attack through expensive-to-store-or-verify transactions. Despite these risks, Andresen believed the likelihood of bugs was low, and measures were in place to mitigate DoS attacks. The proposal allowed any Script with 15 or fewer signature operations as a P2SH script to be relayed and mined by the reference implementation. A soft-fork-safe patch was also being developed, defining an opcode whitelist and considering scripts leaving extra items on the stack as non-standard due to malleability concerns. The patch included all opcodes except invalid ones and OP_NOPx opcodes that could be redefined in future soft-forks. Rejecting transactions with unknown nVersion ensured that miners with older versions of Bitcoin Core would only mine transactions considered valid by the new version. Andresen offered to add these changes to an existing patch and submit a pull request.In summary, the discussion revolved around the consensus for soft-forks bumping version numbers and the suggestion to convert a Github Gist into an informational BIP. There were debates about separating changes into pull requests, the necessity of a whitelist for future soft-forks, and concerns about malleability and evalscript() code. The proposal aimed to open up "IsStandard" transaction rules to accommodate multi-signature and complex transaction forms, while mitigating risks through limitations and soft-fork-safe patches. Specialized wallets or applications would be required for new transaction forms. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Proposals-for-improving-Bitcoin-mining-decentralization.xml b/static/bitcoin-dev/June_2014/combined_Proposals-for-improving-Bitcoin-mining-decentralization.xml index efbde213c7..c834838d5d 100644 --- a/static/bitcoin-dev/June_2014/combined_Proposals-for-improving-Bitcoin-mining-decentralization.xml +++ b/static/bitcoin-dev/June_2014/combined_Proposals-for-improving-Bitcoin-mining-decentralization.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposals for improving Bitcoin mining decentralization - 2023-08-01T09:35:08.265550+00:00 + 2025-10-11T21:50:17.662820+00:00 + python-feedgen Raúl Martínez 2014-06-17 19:01:00+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Proposals for improving Bitcoin mining decentralization - 2023-08-01T09:35:08.265550+00:00 + 2025-10-11T21:50:17.662957+00:00 - In a Bitcoin development mailing list post, Raúl Martínez proposes a protocol that allows miners to collect transactions by themselves and mine them individually, rather than relying on a pool sending the list of transactions to include in a block. This would prevent possible 51% attacks from pool owners. However, as pools are not part of the Bitcoin protocol, it is uncertain how this could be enforced or made widely used, especially since most miners do not care about transaction inclusion themselves and prefer just pointing hash power at a stratum server.The GHash.io pool controlling 51% of the hashrate is a concern for some in the Bitcoin community. An individual proposed a solution to stop this from happening again by creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner would have to collect transactions by their own and mine them. This could be achieved by running a full node or by running a Simplified Payment Verification (SPV) like node that asks other nodes for transactions. Once this protocol is developed and standardized, the community could require all pools to use it, not by imposing it but by recommending it. Pool owners could send instructions using this protocol to miners about how many transactions to include per block, how many zero-fee transactions to include, how much is the minimum fee per kilobyte to include transactions and some information about the Coinbase field in the block.This way, it would be impossible to perform some of the possible 51% attacks. A pool owner can't mine a new chain (selfish mining), perform double spends or reverse transactions, or decide which transactions not to include. The only thing that a 51% pool owner can do is to shut down their pool and drop the hashrate by 51% because they do not control the miners.The proposal is valid if the pool owner does not own all the hardware in the pool, and if the pool clients use this protocol. However, most miners don't care and don't want to do the work to set it up. If someone figures out a way to make getblocktemplate (GBT) widely used (>50% hashpower), it would be a significant accomplishment.The proposal aims to create a mining protocol that does not rely on the pool sending the list of transactions to include in a block and requires individual miners to collect transactions by themselves. This can be achieved by running a full node or an SPV like a node that asks other nodes for transactions. The protocol will standardize, and all pools will have to use it, which will make it impossible to perform some of the possible 51% attacks. Pool owners could send instructions using this protocol to the miner about how many transactions to include, how many 0 fee transactions to include, the minimum fee per KB to include transactions, and some info about the Coinbase field in the block.It is also suggested that miners who join a pool should be treated as independent miners rather than slave miners. A pool owner cannot mine a new chain (selfish mining) or perform double-spends or reverse transactions. They cannot decide which transactions not to include but can configure the minimum fee. A pool owner cannot get all the rewards by avoiding other pools from mining blocks because the pool client knows the last block independently that is from his pool or other.The only thing that a 51% pool owner can do is shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool, the proposal is not valid, and if the pool clients don't use this protocol, the idea is not valid. The proposal suggests creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block.In 2014, Raúl Martínez proposed a new mining protocol to prevent pools from controlling more than 51% of the hashrate. The protocol would require individual miners to collect transactions on their own instead of relying on the pool to send them. This could be achieved by running a full node or an SPV-like node that asks other nodes for transactions. Once developed and standardized, the community could recommend that all pools use this protocol. Pool owners could still send instructions to miners about how many transactions to include per block and other details about the Coinbase field in the block. However, this would make it impossible for a pool owner to perform certain 51% attacks, such as selfish mining or double spending. The proposal would only be invalid if the pool owner owns all the hardware in the pool, or if the pool clients don't use the new protocol.In June 2014, Raúl Martínez proposed a new mining protocol that could stop a pool from controlling more than 51% of the hashrate. He suggested that miners should join a pool like independent miners rather than slave miners, which would require developing a new 2014-06-17T19:01:00+00:00 + In a Bitcoin development mailing list post, Raúl Martínez proposes a protocol that allows miners to collect transactions by themselves and mine them individually, rather than relying on a pool sending the list of transactions to include in a block. This would prevent possible 51% attacks from pool owners. However, as pools are not part of the Bitcoin protocol, it is uncertain how this could be enforced or made widely used, especially since most miners do not care about transaction inclusion themselves and prefer just pointing hash power at a stratum server.The GHash.io pool controlling 51% of the hashrate is a concern for some in the Bitcoin community. An individual proposed a solution to stop this from happening again by creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner would have to collect transactions by their own and mine them. This could be achieved by running a full node or by running a Simplified Payment Verification (SPV) like node that asks other nodes for transactions. Once this protocol is developed and standardized, the community could require all pools to use it, not by imposing it but by recommending it. Pool owners could send instructions using this protocol to miners about how many transactions to include per block, how many zero-fee transactions to include, how much is the minimum fee per kilobyte to include transactions and some information about the Coinbase field in the block.This way, it would be impossible to perform some of the possible 51% attacks. A pool owner can't mine a new chain (selfish mining), perform double spends or reverse transactions, or decide which transactions not to include. The only thing that a 51% pool owner can do is to shut down their pool and drop the hashrate by 51% because they do not control the miners.The proposal is valid if the pool owner does not own all the hardware in the pool, and if the pool clients use this protocol. However, most miners don't care and don't want to do the work to set it up. If someone figures out a way to make getblocktemplate (GBT) widely used (>50% hashpower), it would be a significant accomplishment.The proposal aims to create a mining protocol that does not rely on the pool sending the list of transactions to include in a block and requires individual miners to collect transactions by themselves. This can be achieved by running a full node or an SPV like a node that asks other nodes for transactions. The protocol will standardize, and all pools will have to use it, which will make it impossible to perform some of the possible 51% attacks. Pool owners could send instructions using this protocol to the miner about how many transactions to include, how many 0 fee transactions to include, the minimum fee per KB to include transactions, and some info about the Coinbase field in the block.It is also suggested that miners who join a pool should be treated as independent miners rather than slave miners. A pool owner cannot mine a new chain (selfish mining) or perform double-spends or reverse transactions. They cannot decide which transactions not to include but can configure the minimum fee. A pool owner cannot get all the rewards by avoiding other pools from mining blocks because the pool client knows the last block independently that is from his pool or other.The only thing that a 51% pool owner can do is shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool, the proposal is not valid, and if the pool clients don't use this protocol, the idea is not valid. The proposal suggests creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block.In 2014, Raúl Martínez proposed a new mining protocol to prevent pools from controlling more than 51% of the hashrate. The protocol would require individual miners to collect transactions on their own instead of relying on the pool to send them. This could be achieved by running a full node or an SPV-like node that asks other nodes for transactions. Once developed and standardized, the community could recommend that all pools use this protocol. Pool owners could still send instructions to miners about how many transactions to include per block and other details about the Coinbase field in the block. However, this would make it impossible for a pool owner to perform certain 51% attacks, such as selfish mining or double spending. The proposal would only be invalid if the pool owner owns all the hardware in the pool, or if the pool clients don't use the new protocol.In June 2014, Raúl Martínez proposed a new mining protocol that could stop a pool from controlling more than 51% of the hashrate. He suggested that miners should join a pool like independent miners rather than slave miners, which would require developing a new - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Proposed-BIP-70-extension.xml b/static/bitcoin-dev/June_2014/combined_Proposed-BIP-70-extension.xml index d23e544538..d797922616 100644 --- a/static/bitcoin-dev/June_2014/combined_Proposed-BIP-70-extension.xml +++ b/static/bitcoin-dev/June_2014/combined_Proposed-BIP-70-extension.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed BIP 70 extension - 2023-08-01T09:39:27.913307+00:00 + 2025-10-11T21:50:09.165526+00:00 + python-feedgen Jeff Garzik 2014-06-25 18:10:58+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Proposed BIP 70 extension - 2023-08-01T09:39:27.913307+00:00 + 2025-10-11T21:50:09.165735+00:00 - The email thread discusses the process of creating payment protocol extensions and the need for a living document to keep track of all extensions. It is recommended that the document not be called BIP70, as it is outdated.There is also discussion around implementing discounts for paying with BTC and how this could affect adoption. A percentage/proportion discount is suggested over an amount in satoshis. The security of the optional discount field is discussed, as merchants can lie about the discount, but wallets can choose to ignore the field.Bitcoin core developer Jeff Garzik signs off on the email.In another conversation, the importance of having explicit standards is discussed. It is believed that having optional fields with ambiguous meanings is worse than not having them at all. The need to keep things simple and generalized is emphasized to prevent buggy implementations. It is suggested that any information not required by machines should only exist in human-oriented fields. Overly complicated and edge-case-oriented protocols are discouraged.Mike Hearn explains that the protocol is there to contain features and there is no benefit to blindly following notions of purity or minimalism. However, a good standard must be explicit. Examples of over-engineered protocols are cited, highlighting the importance of clear definitions and designs. Slush warns against over-engineering the payment protocol.The implementation of a discount for paying with Bitcoin in the payment protocol extensions process is discussed. The idea is to encourage adoption by offering discounts. The implementation would require a percentage or proportion discount rather than an amount in satoshis. The security of the optional discount field is discussed, as it does not seem harmful and wallets can ignore the field if they wish. Some members argue for including more features in the protocol to help users and adoption. The plan is to set up the extension process formally and have a living document version of the payment protocol with all the different extensions.The conversation includes discussions about specifying container formats for random features and the extensibility of protocol buffers. The need for clear reference prices for discounts and the possibility of abuse by merchants are also discussed. The inclusion of a numeric memo field in the payment protocol is debated, with arguments for and against its usefulness.Jeff Garzik and Mike Hearn discuss the idea of wallets being able to persist data on how much money users have saved over time. Concerns about the unprovability and potential inflation of such data are raised. Jeff suggests offering automatic cashback instead of discounts to prevent gaming the system. The conversation includes discussions about extending BIP 70 and clarifying reference prices for discounts.In June 2014, Mike Hearn proposed a minor BIP 70 extension that would allow wallets to show users how much they are saving by using Bitcoin. The extension would record the size in satoshis of any discount provided by the merchant because the user chose to pay using Bitcoin. Other kinds of discounts could be mentioned in the memo field. Wallets would then be able to persist this data to disk and compete on cool visualizations for how much money users saved over time. The need for a clear reference price for the discount is discussed.The conversation revolves around the validity and practicality of marketing claims that promote Bitcoin as a way to save on transaction fees. The possibility of abuse by merchants and the appropriate field for providing such information are debated. The conversation includes email threads, attachments, and discussions within the Bitcoin-development mailing list.Overall, the discussions center around creating payment protocol extensions, implementing discounts for paying with Bitcoin, the importance of explicit standards, avoiding over-engineering, the inclusion of a numeric memo field, and the potential benefits and challenges of persisting data on savings.The proposal discussed in the provided context aims to enhance the appeal of Bitcoin as a payment method by introducing a tangible incentive for its use. The author highlights the potential benefits of visualizations that showcase the amount of money users have saved over time, adding a more engaging and visually appealing element to the Bitcoin experience.While the idea of incorporating such visualizations is perceived positively, the author acknowledges the need to address the lack of formalization regarding how to extend BIP 70. This recognition emphasizes the importance of establishing clear guidelines and protocols to ensure the seamless integration of these cool visualizations into the Bitcoin ecosystem.By implementing this proposal, Bitcoin could become more attractive to customers, as they would be able to witness the real-time impact of using Bitcoin as a payment method on their savings. The incorporation of visual representations could potentially provide users with a sense of accomplishment and satisfaction, further incentivizing them to continue utilizing Bitcoin for their transactions.In conclusion, the proposal outlined in the context aims to augment the appeal of Bitcoin by introducing visualizations that demonstrate the amount of money saved over time. While the need to formalize the extension of BIP 70 is acknowledged, the overall goal is to provide users with an engaging and rewarding experience when using Bitcoin as a payment method. 2014-06-25T18:10:58+00:00 + The email thread discusses the process of creating payment protocol extensions and the need for a living document to keep track of all extensions. It is recommended that the document not be called BIP70, as it is outdated.There is also discussion around implementing discounts for paying with BTC and how this could affect adoption. A percentage/proportion discount is suggested over an amount in satoshis. The security of the optional discount field is discussed, as merchants can lie about the discount, but wallets can choose to ignore the field.Bitcoin core developer Jeff Garzik signs off on the email.In another conversation, the importance of having explicit standards is discussed. It is believed that having optional fields with ambiguous meanings is worse than not having them at all. The need to keep things simple and generalized is emphasized to prevent buggy implementations. It is suggested that any information not required by machines should only exist in human-oriented fields. Overly complicated and edge-case-oriented protocols are discouraged.Mike Hearn explains that the protocol is there to contain features and there is no benefit to blindly following notions of purity or minimalism. However, a good standard must be explicit. Examples of over-engineered protocols are cited, highlighting the importance of clear definitions and designs. Slush warns against over-engineering the payment protocol.The implementation of a discount for paying with Bitcoin in the payment protocol extensions process is discussed. The idea is to encourage adoption by offering discounts. The implementation would require a percentage or proportion discount rather than an amount in satoshis. The security of the optional discount field is discussed, as it does not seem harmful and wallets can ignore the field if they wish. Some members argue for including more features in the protocol to help users and adoption. The plan is to set up the extension process formally and have a living document version of the payment protocol with all the different extensions.The conversation includes discussions about specifying container formats for random features and the extensibility of protocol buffers. The need for clear reference prices for discounts and the possibility of abuse by merchants are also discussed. The inclusion of a numeric memo field in the payment protocol is debated, with arguments for and against its usefulness.Jeff Garzik and Mike Hearn discuss the idea of wallets being able to persist data on how much money users have saved over time. Concerns about the unprovability and potential inflation of such data are raised. Jeff suggests offering automatic cashback instead of discounts to prevent gaming the system. The conversation includes discussions about extending BIP 70 and clarifying reference prices for discounts.In June 2014, Mike Hearn proposed a minor BIP 70 extension that would allow wallets to show users how much they are saving by using Bitcoin. The extension would record the size in satoshis of any discount provided by the merchant because the user chose to pay using Bitcoin. Other kinds of discounts could be mentioned in the memo field. Wallets would then be able to persist this data to disk and compete on cool visualizations for how much money users saved over time. The need for a clear reference price for the discount is discussed.The conversation revolves around the validity and practicality of marketing claims that promote Bitcoin as a way to save on transaction fees. The possibility of abuse by merchants and the appropriate field for providing such information are debated. The conversation includes email threads, attachments, and discussions within the Bitcoin-development mailing list.Overall, the discussions center around creating payment protocol extensions, implementing discounts for paying with Bitcoin, the importance of explicit standards, avoiding over-engineering, the inclusion of a numeric memo field, and the potential benefits and challenges of persisting data on savings.The proposal discussed in the provided context aims to enhance the appeal of Bitcoin as a payment method by introducing a tangible incentive for its use. The author highlights the potential benefits of visualizations that showcase the amount of money users have saved over time, adding a more engaging and visually appealing element to the Bitcoin experience.While the idea of incorporating such visualizations is perceived positively, the author acknowledges the need to address the lack of formalization regarding how to extend BIP 70. This recognition emphasizes the importance of establishing clear guidelines and protocols to ensure the seamless integration of these cool visualizations into the Bitcoin ecosystem.By implementing this proposal, Bitcoin could become more attractive to customers, as they would be able to witness the real-time impact of using Bitcoin as a payment method on their savings. The incorporation of visual representations could potentially provide users with a sense of accomplishment and satisfaction, further incentivizing them to continue utilizing Bitcoin for their transactions.In conclusion, the proposal outlined in the context aims to augment the appeal of Bitcoin by introducing visualizations that demonstrate the amount of money saved over time. While the need to formalize the extension of BIP 70 is acknowledged, the overall goal is to provide users with an engaging and rewarding experience when using Bitcoin as a payment method. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_Wallet-nLockTime-best-practices.xml b/static/bitcoin-dev/June_2014/combined_Wallet-nLockTime-best-practices.xml index 048c39ddca..9a71c31989 100644 --- a/static/bitcoin-dev/June_2014/combined_Wallet-nLockTime-best-practices.xml +++ b/static/bitcoin-dev/June_2014/combined_Wallet-nLockTime-best-practices.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Wallet nLockTime best practices - 2023-08-01T09:28:44.142652+00:00 + 2025-10-11T21:50:07.039591+00:00 + python-feedgen Jeff Garzik 2014-06-25 15:43:05+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Wallet nLockTime best practices - 2023-08-01T09:28:44.142652+00:00 + 2025-10-11T21:50:07.039753+00:00 - Jeff Garzik, a Bitcoin Core developer and open source evangelist, has proposed implementing pull request #2340 from the Bitcoin GitHub repository. The pull request, titled "Discourage fee sniping with nLockTime," aims to discourage users from taking advantage of low fees by locking transactions for a specific period using nLockTime. Garzik is seeking feedback from other wallet implementors regarding this proposal. He is also affiliated with BitPay, Inc., a payment service provider that supports Bitcoin transactions. Aaron Voisine, the developer of breadwallet, an open-source SPV wallet, has expressed interest in implementing a new feature to discourage fee sniping using nLockTime. Garzik posted a message on the Bitcoin-development mailing list on June 6th, 2014, requesting comments about incorporating the feature into the codebase. Interested parties can find the proposed change on GitHub as pull request #2340 in the Bitcoin repository. In addition, Garzik mentions NeoTech's "Graph Databases" book, which is available for free download, at the end of his email. 2014-06-25T15:43:05+00:00 + Jeff Garzik, a Bitcoin Core developer and open source evangelist, has proposed implementing pull request #2340 from the Bitcoin GitHub repository. The pull request, titled "Discourage fee sniping with nLockTime," aims to discourage users from taking advantage of low fees by locking transactions for a specific period using nLockTime. Garzik is seeking feedback from other wallet implementors regarding this proposal. He is also affiliated with BitPay, Inc., a payment service provider that supports Bitcoin transactions. Aaron Voisine, the developer of breadwallet, an open-source SPV wallet, has expressed interest in implementing a new feature to discourage fee sniping using nLockTime. Garzik posted a message on the Bitcoin-development mailing list on June 6th, 2014, requesting comments about incorporating the feature into the codebase. Interested parties can find the proposed change on GitHub as pull request #2340 in the Bitcoin repository. In addition, Garzik mentions NeoTech's "Graph Databases" book, which is available for free download, at the end of his email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_instant-confirmation-via-payment-protocol-backwards-compatible-proto-buffer-extension.xml b/static/bitcoin-dev/June_2014/combined_instant-confirmation-via-payment-protocol-backwards-compatible-proto-buffer-extension.xml index d960f5107b..e23cb28761 100644 --- a/static/bitcoin-dev/June_2014/combined_instant-confirmation-via-payment-protocol-backwards-compatible-proto-buffer-extension.xml +++ b/static/bitcoin-dev/June_2014/combined_instant-confirmation-via-payment-protocol-backwards-compatible-proto-buffer-extension.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - instant confirmation via payment protocol backwards compatible proto buffer extension - 2023-08-01T09:33:42.309680+00:00 + 2025-10-11T21:49:43.665089+00:00 + python-feedgen sebastien requiem 2014-06-25 14:01:31+00:00 @@ -183,13 +184,13 @@ - python-feedgen + 2 Combined summary - instant confirmation via payment protocol backwards compatible proto buffer extension - 2023-08-01T09:33:42.310680+00:00 + 2025-10-11T21:49:43.665367+00:00 - The context discusses various aspects related to centralization and double-spending issues in Bitcoin transactions. It starts by mentioning the idea of using tamperproof hardware with embedded secret keys to prevent double spending and promote decentralization. The conversation then shifts towards the need for multiple instant signatures on transactions to encourage new providers and avoid a VISA monopoly. The suggestion is made to pay a trusted provider to co-sign the same transaction, thus building trust for new companies. Mike Hearn emphasizes the importance of writing code rather than blocking alternative approaches to ensure Bitcoin's robustness.Alex Kotenko expresses concerns about the potential centralization of Trusted Third Parties (TTPs) in Bitcoin transactions, warning against a "VISA world" scenario. He argues that economies of scale would make centralization inevitable and suggests finding a way to solve double-spending without TTP involvement. Mike Hearn agrees and proposes explicitly picking a third-party instant provider instead of enforcing larger rules on mining to avoid implicit centralization.The discussion also touches on the issue of double-spending prevention and the potential centralization of transactions if the system changes to a highest-fee-always-wins approach. Mike Hearn questions whether rules can be enforced on miners and suggests opting for explicit selection of an instant provider instead. The conversation further explores the need for anti-double-spend providers and incentivizing their use through discounts. The focus is on preventing double spends without relying on block confirmation, which is impractical for merchants and customers.The context raises concerns about double-spends occurring within minutes and the potential centralization of transactions if miners switch to a highest-fee-always-wins system. The hope is that Bitcoin remains safe and doesn't require instant transactions to pay specific providers. The conversation highlights the importance of resolving double-spending issues and encourages further discussion on the topic.Mike Hearn discusses the potential centralization of Bitcoin mining and the usefulness of Satoshi's first seen rule in preventing double-spends. He suggests that changing to a highest-fee-always-wins system would force instant transactions to pay specific providers, leading to implicit centralization. The focus is on finding practical solutions to double spends without compromising the future of Bitcoin.The conversation between Mike Hearn and an unknown person centers around the issue of double-spending in Bitcoin transactions. They discuss the need for anti-double-spend providers and the possibility of offering discounts to incentivize their use. The conversation ends with a call for further discussion on the topic.The context highlights the implementation of a patch to solve double spending issues, but it may not protect against corrupt miners. The proposal introduces centralized trust as a backup in case Bitcoin's existing double-spending protections are weak. Payment processors like Bitpay and Coinbase are likely to consider this approach, while individual mobile wallet users may find it complex. The market may become centralized around a few payment processing companies if native Bitcoin cannot meet small online shops' requirements.The placement of an instant provider signature in the payment protocol is discussed, with the conclusion that it is appropriate. However, privacy concerns arise from publicly revealing the wallet provider being used. The context also mentions the potential for arbitrage opportunities and liquidity in high-frequency trading between exchanges using the proposed BIP. The focus then shifts to the consumer case, where not all trades require dispute mediation. It is suggested that Bitcoin alone may not be suitable for medium-high value purchases without third-party involvement.The conversation involves discussions about double-spends detected by a node and relayed by another party. The possibility of high-frequency trading and unreliable transaction propagation across the blockchain is explored. Differentiating between consumer and corporate cases, it is noted that not all purchases require dispute mediation, and Bitcoin may not be suitable for medium-high value purchases without third-party involvement. The hope is that the market will naturally converge to a handful of trusted names for transactions requiring dispute mediation.The context addresses a proposed solution to double spend attempts on the Bitcoin network, highlighting potential security vulnerabilities and false sense of security. It is suggested as a backup in case existing double spending protections are deemed weak. The notion of centralized trust is introduced but only for cases where it would be useful. Payment processors like Bitpay and Coinbase are expected to consider this approach, while individual mobile wallet users may find it complex. The market may become centralized around a few payment processing companies if native Bitcoin cannot meet small online shops' requirements.The placement of an instant provider signature in the payment protocol is discussed, with the conclusion that it is appropriate. However, privacy concerns arise from publicly revealing the wallet provider being used. The context also mentions the potential for arbitrage opportunities and liquidity in high-frequency trading between exchanges using the proposed BIP. The focus then shifts to the consumer case, where not all trades require dispute mediation. It is suggested that Bitcoin alone may not be suitable for medium-high value purchases without third-party involvement.The conversation revolves around the issue of merchants and customers trusting only a handful of third parties for payment methods, similar to the duopoly of trusted Certificate 2014-06-25T14:01:31+00:00 + The context discusses various aspects related to centralization and double-spending issues in Bitcoin transactions. It starts by mentioning the idea of using tamperproof hardware with embedded secret keys to prevent double spending and promote decentralization. The conversation then shifts towards the need for multiple instant signatures on transactions to encourage new providers and avoid a VISA monopoly. The suggestion is made to pay a trusted provider to co-sign the same transaction, thus building trust for new companies. Mike Hearn emphasizes the importance of writing code rather than blocking alternative approaches to ensure Bitcoin's robustness.Alex Kotenko expresses concerns about the potential centralization of Trusted Third Parties (TTPs) in Bitcoin transactions, warning against a "VISA world" scenario. He argues that economies of scale would make centralization inevitable and suggests finding a way to solve double-spending without TTP involvement. Mike Hearn agrees and proposes explicitly picking a third-party instant provider instead of enforcing larger rules on mining to avoid implicit centralization.The discussion also touches on the issue of double-spending prevention and the potential centralization of transactions if the system changes to a highest-fee-always-wins approach. Mike Hearn questions whether rules can be enforced on miners and suggests opting for explicit selection of an instant provider instead. The conversation further explores the need for anti-double-spend providers and incentivizing their use through discounts. The focus is on preventing double spends without relying on block confirmation, which is impractical for merchants and customers.The context raises concerns about double-spends occurring within minutes and the potential centralization of transactions if miners switch to a highest-fee-always-wins system. The hope is that Bitcoin remains safe and doesn't require instant transactions to pay specific providers. The conversation highlights the importance of resolving double-spending issues and encourages further discussion on the topic.Mike Hearn discusses the potential centralization of Bitcoin mining and the usefulness of Satoshi's first seen rule in preventing double-spends. He suggests that changing to a highest-fee-always-wins system would force instant transactions to pay specific providers, leading to implicit centralization. The focus is on finding practical solutions to double spends without compromising the future of Bitcoin.The conversation between Mike Hearn and an unknown person centers around the issue of double-spending in Bitcoin transactions. They discuss the need for anti-double-spend providers and the possibility of offering discounts to incentivize their use. The conversation ends with a call for further discussion on the topic.The context highlights the implementation of a patch to solve double spending issues, but it may not protect against corrupt miners. The proposal introduces centralized trust as a backup in case Bitcoin's existing double-spending protections are weak. Payment processors like Bitpay and Coinbase are likely to consider this approach, while individual mobile wallet users may find it complex. The market may become centralized around a few payment processing companies if native Bitcoin cannot meet small online shops' requirements.The placement of an instant provider signature in the payment protocol is discussed, with the conclusion that it is appropriate. However, privacy concerns arise from publicly revealing the wallet provider being used. The context also mentions the potential for arbitrage opportunities and liquidity in high-frequency trading between exchanges using the proposed BIP. The focus then shifts to the consumer case, where not all trades require dispute mediation. It is suggested that Bitcoin alone may not be suitable for medium-high value purchases without third-party involvement.The conversation involves discussions about double-spends detected by a node and relayed by another party. The possibility of high-frequency trading and unreliable transaction propagation across the blockchain is explored. Differentiating between consumer and corporate cases, it is noted that not all purchases require dispute mediation, and Bitcoin may not be suitable for medium-high value purchases without third-party involvement. The hope is that the market will naturally converge to a handful of trusted names for transactions requiring dispute mediation.The context addresses a proposed solution to double spend attempts on the Bitcoin network, highlighting potential security vulnerabilities and false sense of security. It is suggested as a backup in case existing double spending protections are deemed weak. The notion of centralized trust is introduced but only for cases where it would be useful. Payment processors like Bitpay and Coinbase are expected to consider this approach, while individual mobile wallet users may find it complex. The market may become centralized around a few payment processing companies if native Bitcoin cannot meet small online shops' requirements.The placement of an instant provider signature in the payment protocol is discussed, with the conclusion that it is appropriate. However, privacy concerns arise from publicly revealing the wallet provider being used. The context also mentions the potential for arbitrage opportunities and liquidity in high-frequency trading between exchanges using the proposed BIP. The focus then shifts to the consumer case, where not all trades require dispute mediation. It is suggested that Bitcoin alone may not be suitable for medium-high value purchases without third-party involvement.The conversation revolves around the issue of merchants and customers trusting only a handful of third parties for payment methods, similar to the duopoly of trusted Certificate - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2014/combined_testnet-seed-bitcoin-petertodd-org-is-up-again.xml b/static/bitcoin-dev/June_2014/combined_testnet-seed-bitcoin-petertodd-org-is-up-again.xml index e3397ff010..7c6731c367 100644 --- a/static/bitcoin-dev/June_2014/combined_testnet-seed-bitcoin-petertodd-org-is-up-again.xml +++ b/static/bitcoin-dev/June_2014/combined_testnet-seed-bitcoin-petertodd-org-is-up-again.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - testnet-seed.bitcoin.petertodd.org is up again - 2023-08-01T09:23:08.001242+00:00 + 2025-10-11T21:50:19.786168+00:00 + python-feedgen Alex Kotenko 2014-06-01 09:56:52+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - testnet-seed.bitcoin.petertodd.org is up again - 2023-08-01T09:23:08.001242+00:00 + 2025-10-11T21:50:19.786391+00:00 - In a recent Github discussion, the topic of dependency on centralized resources in applications is emphasized. The conversation highlights the importance of addressing issues related to broken and insecure applications caused by DNS seeds being down. It is argued that instead of solely relying on DNS seeds, fallbacks such as hardcoded node lists and manual peer entry should be implemented, particularly during the initial startup phase. This approach ensures that the application remains functional even when DNS seeds are unavailable.However, it is important to note that this solution still relies on a centralized resource. To make the application more resilient, it is suggested that either the application needs to be made more resilient or there needs to be a more robust DNS system in place. This would prevent downtime and ensure that the application can continue to function even when there are issues with DNS seeds.To explore the details of this discussion further, you can refer to the provided link. Additionally, the conversation ends with a mention of automated cross-browser testing and an invitation to join a mailing list. 2014-06-01T09:56:52+00:00 + In a recent Github discussion, the topic of dependency on centralized resources in applications is emphasized. The conversation highlights the importance of addressing issues related to broken and insecure applications caused by DNS seeds being down. It is argued that instead of solely relying on DNS seeds, fallbacks such as hardcoded node lists and manual peer entry should be implemented, particularly during the initial startup phase. This approach ensures that the application remains functional even when DNS seeds are unavailable.However, it is important to note that this solution still relies on a centralized resource. To make the application more resilient, it is suggested that either the application needs to be made more resilient or there needs to be a more robust DNS system in place. This would prevent downtime and ensure that the application can continue to function even when there are issues with DNS seeds.To explore the details of this discussion further, you can refer to the provided link. Additionally, the conversation ends with a mention of automated cross-browser testing and an invitation to join a mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_-BIP-draft-Consensus-enforced-transaction-replacement-signalled-via-sequence-numbers.xml b/static/bitcoin-dev/June_2015/combined_-BIP-draft-Consensus-enforced-transaction-replacement-signalled-via-sequence-numbers.xml index 19264d84e0..5232f59751 100644 --- a/static/bitcoin-dev/June_2015/combined_-BIP-draft-Consensus-enforced-transaction-replacement-signalled-via-sequence-numbers.xml +++ b/static/bitcoin-dev/June_2015/combined_-BIP-draft-Consensus-enforced-transaction-replacement-signalled-via-sequence-numbers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers - 2023-08-01T13:02:08.050466+00:00 + 2025-10-11T21:37:17.543274+00:00 + python-feedgen Gregory Maxwell 2015-06-17 01:20:25+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers - 2023-08-01T13:02:08.050466+00:00 + 2025-10-11T21:37:17.543459+00:00 - Mark Friedenbach has proposed a soft-fork change to the consensus-enforced behavior of sequence numbers in Bitcoin. The purpose of this change is to enable safe transaction replacement via per-input relative lock-times. Friedenbach has requested the assignment of a BIP number for this work, and the BIP draft and reference implementation are available on GitHub.The proposed change involves repurposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. This would allow for the use of the full range of the 32-bit sequence number, which has rarely been used for anything other than boolean control over absolute nLockTime. The goal is to make use of the sequence numbers in a way that is compatible with the originally envisioned use for fast mempool transaction replacement.However, there are some disadvantages to this approach. External constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and repurposing nSequence as a relative lock-time precludes its use in other contexts. To address this, the proposal suggests enforcing the relative lock-time semantics only if the most significant bit of nSequence is set, leaving 31 bits for alternative use when relative lock-times are not required.In the email conversation, there is discussion about the possibility of implementing a "not after" feature in Bitcoin script, which would make a script that was once valid later invalid. However, it is noted that this may not be compatible with the current model of reprocessing transactions in later blocks if the block they were first in gets reorganized. One suggestion is to make it the previous holder's responsibility to spend a "not before" back to themselves.There is also discussion about the need for an OP_RCLTV (Relative CheckLockTimeVerify) opcode, even with Friedenbach's proposed implementation. While the proposed solution may work in cases where multiple signing parties are involved, there may be other use cases that require putting the relative lock-time right into the spending contract. It is suggested that repurposing an OP_NOP opcode to create OP_RCLTV could be a more fully-featured solution.Overall, Friedenbach's proposal aims to enable safe transaction replacement by repurposing sequence numbers as relative lock-times. While there are some disadvantages and potential issues raised in the discussion, the proposal is viewed as innovative and has generated interest among the Bitcoin community. Mark Friedenbach has requested the BIP editor to assign a BIP number for his work to further advance this proposal. 2015-06-17T01:20:25+00:00 + Mark Friedenbach has proposed a soft-fork change to the consensus-enforced behavior of sequence numbers in Bitcoin. The purpose of this change is to enable safe transaction replacement via per-input relative lock-times. Friedenbach has requested the assignment of a BIP number for this work, and the BIP draft and reference implementation are available on GitHub.The proposed change involves repurposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. This would allow for the use of the full range of the 32-bit sequence number, which has rarely been used for anything other than boolean control over absolute nLockTime. The goal is to make use of the sequence numbers in a way that is compatible with the originally envisioned use for fast mempool transaction replacement.However, there are some disadvantages to this approach. External constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and repurposing nSequence as a relative lock-time precludes its use in other contexts. To address this, the proposal suggests enforcing the relative lock-time semantics only if the most significant bit of nSequence is set, leaving 31 bits for alternative use when relative lock-times are not required.In the email conversation, there is discussion about the possibility of implementing a "not after" feature in Bitcoin script, which would make a script that was once valid later invalid. However, it is noted that this may not be compatible with the current model of reprocessing transactions in later blocks if the block they were first in gets reorganized. One suggestion is to make it the previous holder's responsibility to spend a "not before" back to themselves.There is also discussion about the need for an OP_RCLTV (Relative CheckLockTimeVerify) opcode, even with Friedenbach's proposed implementation. While the proposed solution may work in cases where multiple signing parties are involved, there may be other use cases that require putting the relative lock-time right into the spending contract. It is suggested that repurposing an OP_NOP opcode to create OP_RCLTV could be a more fully-featured solution.Overall, Friedenbach's proposal aims to enable safe transaction replacement by repurposing sequence numbers as relative lock-times. While there are some disadvantages and potential issues raised in the discussion, the proposal is viewed as innovative and has generated interest among the Bitcoin community. Mark Friedenbach has requested the BIP editor to assign a BIP number for his work to further advance this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml b/static/bitcoin-dev/June_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml index a5f0a48d0b..0c05c324ec 100644 --- a/static/bitcoin-dev/June_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml +++ b/static/bitcoin-dev/June_2015/combined_-BIP-draft-Motivation-and-deployment-of-consensus-rules-changes-soft-hard-forks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks) - 2023-08-01T13:27:52.323460+00:00 + 2025-10-11T21:37:49.390834+00:00 + python-feedgen Jorge Timón 2015-08-29 21:21:05+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks) - 2023-08-01T13:27:52.323460+00:00 + 2025-10-11T21:37:49.391039+00:00 - A discussion thread on GitHub regarding a draft BIP (Bitcoin Improvement Proposal) has been moved to the mailing list due to GitHub not being specified for high-level discussions in BIP001. The original poster raises concerns about the structure and wording of the proposal, suggesting it be slimmed down and simplified, with some history lessons removed. The author of the proposal requests more specific suggestions before taking action. There is a question about a separate BIP for "code forks," clarified as beyond the scope of this BIP. It is noted that spell checking has not been followed for any BIP. The current label of the proposal is "informational | process" but may change based on appropriateness. The proposal contains code for an uncontroversial hard fork example to set a precedent. However, a proposal for a "patch into core as a module that hard forks can use in the future" requires further clarification.On July 31, 2015, Thomas Kerin via bitcoin-dev expresses the belief that a document should exist prior to assigning a BIP number. While there was an initial document, alterations were made after the BIP number was assigned. The author apologizes for breaking the previous link and provides a new one. The code is also available on Github. A separate mailing list discussion is ongoing regarding activation thresholds related to this BIP. The assumption of the BIP is that miners will upgrade after a defined starting block height, and once a 95% threshold is reached, the hard fork takes effect. After the first block is buried, the check can be replaced by redefining the threshold height instead of the height when miners started voting.Jorge Timón requests a BIP number from Greg Maxwell on the bitcoin-dev mailing list for discussions about deploying uncontroversial hard forks in one place. The proposed timewarp fix could be coded as a soft fork instead of a hard fork, requiring all blocks to be within one day of the median of the previous 11 blocks. Tier Nolan suggests this would protect against the exploit. Another proposal suggests that the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Nolan believes a hard fork is necessary to fix the issue "right," especially for demonstrating a non-controversial hard fork.Discussions revolve around obtaining miner confirmation on uncontroversial hard forks and whether to use nHeight, nMedianTime, or just nTime. A BIP number is requested to concentrate discussions on deploying uncontroversial hard forks in one place. One proposal for a timewarp fix suggests all blocks should be within 1 day of the median of the previous 11 blocks, adding a condition at the other end. Another proposal suggests the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Fixing the issue "right" would likely require a hard fork, particularly for demonstrating a non-controversial hard fork.In an email conversation, Jorge Timón suggests a soft fork solution to the timewarp exploit, proposing that all blocks should be within one day of the median of the previous 11 blocks, with a condition added at the other end. While not a total fix, it would protect against the exploit. A stricter soft fork would require the two blocks in question to have the same timestamp, ensuring the off by 1 and correct value yield the same result. Timón believes a hard fork is necessary to fix the issue "right," especially when demonstrating a non-controversial hard fork.Tier Nolan suggests fixing the "off by 1 bug" through a soft fork in an email thread on June 21, 2015. This suggestion is made in the context of demonstrating how a non-controversial hard fork works. The timewarp fix discussed in the thread could potentially be coded as a soft fork instead of a hard fork. However, it is unclear if there were any other candidates for addressing the issue.There is a discussion about an off by 1 bug and its potential fix through a soft fork. The focus is primarily on demonstrating how a non-controversial hard fork operates, with the bug solution being of lesser importance.The author seeks feedback to create an informational BIP on deploying hard forks. It is specified that the discussion only pertains to hard forks and soft forks in an abstract manner, excluding block size issues. Block size changes are used as examples due to lack of alternatives, but non-blocksize-related examples for the same cases are welcomed. The author encourages suggestions and input on terminology. The full text can be found on the author's Github page at https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org. 2015-08-29T21:21:05+00:00 + A discussion thread on GitHub regarding a draft BIP (Bitcoin Improvement Proposal) has been moved to the mailing list due to GitHub not being specified for high-level discussions in BIP001. The original poster raises concerns about the structure and wording of the proposal, suggesting it be slimmed down and simplified, with some history lessons removed. The author of the proposal requests more specific suggestions before taking action. There is a question about a separate BIP for "code forks," clarified as beyond the scope of this BIP. It is noted that spell checking has not been followed for any BIP. The current label of the proposal is "informational | process" but may change based on appropriateness. The proposal contains code for an uncontroversial hard fork example to set a precedent. However, a proposal for a "patch into core as a module that hard forks can use in the future" requires further clarification.On July 31, 2015, Thomas Kerin via bitcoin-dev expresses the belief that a document should exist prior to assigning a BIP number. While there was an initial document, alterations were made after the BIP number was assigned. The author apologizes for breaking the previous link and provides a new one. The code is also available on Github. A separate mailing list discussion is ongoing regarding activation thresholds related to this BIP. The assumption of the BIP is that miners will upgrade after a defined starting block height, and once a 95% threshold is reached, the hard fork takes effect. After the first block is buried, the check can be replaced by redefining the threshold height instead of the height when miners started voting.Jorge Timón requests a BIP number from Greg Maxwell on the bitcoin-dev mailing list for discussions about deploying uncontroversial hard forks in one place. The proposed timewarp fix could be coded as a soft fork instead of a hard fork, requiring all blocks to be within one day of the median of the previous 11 blocks. Tier Nolan suggests this would protect against the exploit. Another proposal suggests that the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Nolan believes a hard fork is necessary to fix the issue "right," especially for demonstrating a non-controversial hard fork.Discussions revolve around obtaining miner confirmation on uncontroversial hard forks and whether to use nHeight, nMedianTime, or just nTime. A BIP number is requested to concentrate discussions on deploying uncontroversial hard forks in one place. One proposal for a timewarp fix suggests all blocks should be within 1 day of the median of the previous 11 blocks, adding a condition at the other end. Another proposal suggests the two blocks in question should have the same timestamp, forcing the off by 1 and correct value to give the same result. Fixing the issue "right" would likely require a hard fork, particularly for demonstrating a non-controversial hard fork.In an email conversation, Jorge Timón suggests a soft fork solution to the timewarp exploit, proposing that all blocks should be within one day of the median of the previous 11 blocks, with a condition added at the other end. While not a total fix, it would protect against the exploit. A stricter soft fork would require the two blocks in question to have the same timestamp, ensuring the off by 1 and correct value yield the same result. Timón believes a hard fork is necessary to fix the issue "right," especially when demonstrating a non-controversial hard fork.Tier Nolan suggests fixing the "off by 1 bug" through a soft fork in an email thread on June 21, 2015. This suggestion is made in the context of demonstrating how a non-controversial hard fork works. The timewarp fix discussed in the thread could potentially be coded as a soft fork instead of a hard fork. However, it is unclear if there were any other candidates for addressing the issue.There is a discussion about an off by 1 bug and its potential fix through a soft fork. The focus is primarily on demonstrating how a non-controversial hard fork operates, with the bug solution being of lesser importance.The author seeks feedback to create an informational BIP on deploying hard forks. It is specified that the discussion only pertains to hard forks and soft forks in an abstract manner, excluding block size issues. Block size changes are used as examples due to lack of alternatives, but non-blocksize-related examples for the same cases are welcomed. The author encourages suggestions and input on terminology. The full text can be found on the author's Github page at https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_-RFC-Canonical-input-and-output-ordering-in-transactions.xml b/static/bitcoin-dev/June_2015/combined_-RFC-Canonical-input-and-output-ordering-in-transactions.xml index e5f5e4fcd2..fa667a1948 100644 --- a/static/bitcoin-dev/June_2015/combined_-RFC-Canonical-input-and-output-ordering-in-transactions.xml +++ b/static/bitcoin-dev/June_2015/combined_-RFC-Canonical-input-and-output-ordering-in-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] Canonical input and output ordering in transactions - 2023-08-01T13:04:19.553143+00:00 + 2025-10-11T21:37:32.402460+00:00 + python-feedgen Kristov Atlas 2015-06-24 22:09:32+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - [RFC] Canonical input and output ordering in transactions - 2023-08-01T13:04:19.553143+00:00 + 2025-10-11T21:37:32.402628+00:00 - However, there are concerns raised about the strict ordering requirements of the proposal. Some argue that these requirements may not be compatible with future soft-forks that could impose additional ordering constraints. It is also suggested that there might be invisible constraints in systems like hardware wallets or future transaction covenants that have their own ordering restrictions. One alternative suggestion is to privately derandomize the ordering, allowing for more flexibility.Additionally, collaborative transaction systems such as coinjoins or micropayment channels are seen as potential drivers for the need to establish a canonical order for inputs and outputs. These systems rely on multiple parties coming together to create a single transaction, and having a consistent ordering of inputs and outputs would simplify the process.There have been discussions regarding the use of mid-state compression, which allows for compact commitments through an OP_RETURN output. Some suggest exempting this type of output from soft-fork enforcement, while others argue that this approach is not ideal. Another proposal suggests using a more general best-effort language that does not distinguish non-canonical ordering for OP_RETURN transactions.Some developers express skepticism towards enforcing strict transaction ordering requirements. They believe that such requirements could potentially conflict with future soft-forks and invisible constraints in various systems. However, they acknowledge that the motivations for the proposal are understated and suggest considering alternative proposals, such as privately derandomizing the ordering or proposing a simple derandomized randomization algorithm.Furthermore, there are discussions about the significance of the zeroth input and the position of the OP_RETURN colored coin marker output in the Open Assets colored coin protocol. Reordering the inputs or outputs would break the colored coin representation. While sorting inputs and outputs as a best practice is recommended, it should not be part of IsStandard() or consensus rules due to cases where the order is significant.In conclusion, the Canonical Input and Output Ordering BIP proposes a standardized order for inputs and outputs in Bitcoin transactions. While there are objections and concerns, alternative suggestions and ongoing discussions aim to find ways to improve transaction ordering while considering privacy, compatibility, and future developments in the Bitcoin ecosystem. 2015-06-24T22:09:32+00:00 + However, there are concerns raised about the strict ordering requirements of the proposal. Some argue that these requirements may not be compatible with future soft-forks that could impose additional ordering constraints. It is also suggested that there might be invisible constraints in systems like hardware wallets or future transaction covenants that have their own ordering restrictions. One alternative suggestion is to privately derandomize the ordering, allowing for more flexibility.Additionally, collaborative transaction systems such as coinjoins or micropayment channels are seen as potential drivers for the need to establish a canonical order for inputs and outputs. These systems rely on multiple parties coming together to create a single transaction, and having a consistent ordering of inputs and outputs would simplify the process.There have been discussions regarding the use of mid-state compression, which allows for compact commitments through an OP_RETURN output. Some suggest exempting this type of output from soft-fork enforcement, while others argue that this approach is not ideal. Another proposal suggests using a more general best-effort language that does not distinguish non-canonical ordering for OP_RETURN transactions.Some developers express skepticism towards enforcing strict transaction ordering requirements. They believe that such requirements could potentially conflict with future soft-forks and invisible constraints in various systems. However, they acknowledge that the motivations for the proposal are understated and suggest considering alternative proposals, such as privately derandomizing the ordering or proposing a simple derandomized randomization algorithm.Furthermore, there are discussions about the significance of the zeroth input and the position of the OP_RETURN colored coin marker output in the Open Assets colored coin protocol. Reordering the inputs or outputs would break the colored coin representation. While sorting inputs and outputs as a best practice is recommended, it should not be part of IsStandard() or consensus rules due to cases where the order is significant.In conclusion, the Canonical Input and Output Ordering BIP proposes a standardized order for inputs and outputs in Bitcoin transactions. While there are objections and concerns, alternative suggestions and ongoing discussions aim to find ways to improve transaction ordering while considering privacy, compatibility, and future developments in the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_-RFC-IBLT-block-testing-implementation.xml b/static/bitcoin-dev/June_2015/combined_-RFC-IBLT-block-testing-implementation.xml index f2163577d5..940bb4e562 100644 --- a/static/bitcoin-dev/June_2015/combined_-RFC-IBLT-block-testing-implementation.xml +++ b/static/bitcoin-dev/June_2015/combined_-RFC-IBLT-block-testing-implementation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] IBLT block testing implementation - 2023-08-01T13:49:42.988801+00:00 + 2025-10-11T21:37:23.910151+00:00 + python-feedgen Rusty Russell 2015-06-27 04:46:35+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [RFC] IBLT block testing implementation - 2023-08-01T13:49:42.989796+00:00 + 2025-10-11T21:37:23.910278+00:00 - Rusty Russell has developed a model for using Invertible Bloom Lookup Tables (IBLT) to communicate blocks between peers. The model is designed to be as flexible as possible, making few assumptions on transaction selection policy and relying on similarity in mempools, with some selection hints. The selection hints are minimum fee-per-byte and bitmaps of included-despite-that and rejected-despite-that. The former covers things like child-pays-for-parent and the priority area. The latter covers other cases like Eligius censoring "spam", bitcoin version differences, etc.The model performs reasonably well on a 100 block sample in bitcoin-corpus. There is more work to do, and more investigation to be done, but Rusty doesn't expect more than a 25% reduction in this "ideal minimum" result. Kalle Rosenbaum previously investigated IBLTs with Rusty last year.Rusty Russell's implementation of IBLTs does not use a keyHashSum, but instead concatenates (txid48, fragid, tx-chunk) as the value. The txid48+fragid functions as a kind of keyHashSum. Kalle Rosenbaum thinks this idea is very good.Rosenbaum asked if Rusty implemented his idea to remove all the count==1 fragments in ascending order of (fragid-base_fragid). Rusty replied that he keeps records of all the 1 and -1 buckets; separate lists depending on how far they are off the base. Lists for 0, 1, 2, ... 7, then powers of 2. They also discussed making more comparable tests as proposed last year by Rosenbaum.Rusty's design relies on similarity in mempools, with some selection hints. It is designed to be re-encoded between nodes as nodes will have similar mempools. Actual results will have to be worse than these minima, as peers will have to oversize the IBLT to have a reasonable chance of success.Rosenbaum suggested that exceptional tx *could* instead be encoded in the IBLT, just as if they were unknown differences. Rusty said that it's pretty easy to cut the bitmaps to zero and test this, whereas the overhead of IBLT is some factor greater than txsize. The purpose of reencoding when relaying is to improve the failure probability as new tx may have arrived in the mempool of the intermediary node.Rusty Russell thanks Kalle Rosenbaum for helping investigate IBLTs last year and adds that he works for Blockstream, while supposed to be working on Lightning. 2015-06-27T04:46:35+00:00 + Rusty Russell has developed a model for using Invertible Bloom Lookup Tables (IBLT) to communicate blocks between peers. The model is designed to be as flexible as possible, making few assumptions on transaction selection policy and relying on similarity in mempools, with some selection hints. The selection hints are minimum fee-per-byte and bitmaps of included-despite-that and rejected-despite-that. The former covers things like child-pays-for-parent and the priority area. The latter covers other cases like Eligius censoring "spam", bitcoin version differences, etc.The model performs reasonably well on a 100 block sample in bitcoin-corpus. There is more work to do, and more investigation to be done, but Rusty doesn't expect more than a 25% reduction in this "ideal minimum" result. Kalle Rosenbaum previously investigated IBLTs with Rusty last year.Rusty Russell's implementation of IBLTs does not use a keyHashSum, but instead concatenates (txid48, fragid, tx-chunk) as the value. The txid48+fragid functions as a kind of keyHashSum. Kalle Rosenbaum thinks this idea is very good.Rosenbaum asked if Rusty implemented his idea to remove all the count==1 fragments in ascending order of (fragid-base_fragid). Rusty replied that he keeps records of all the 1 and -1 buckets; separate lists depending on how far they are off the base. Lists for 0, 1, 2, ... 7, then powers of 2. They also discussed making more comparable tests as proposed last year by Rosenbaum.Rusty's design relies on similarity in mempools, with some selection hints. It is designed to be re-encoded between nodes as nodes will have similar mempools. Actual results will have to be worse than these minima, as peers will have to oversize the IBLT to have a reasonable chance of success.Rosenbaum suggested that exceptional tx *could* instead be encoded in the IBLT, just as if they were unknown differences. Rusty said that it's pretty easy to cut the bitmaps to zero and test this, whereas the overhead of IBLT is some factor greater than txsize. The purpose of reencoding when relaying is to improve the failure probability as new tx may have arrived in the mempool of the intermediary node.Rusty Russell thanks Kalle Rosenbaum for helping investigate IBLTs last year and adds that he works for Blockstream, while supposed to be working on Lightning. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_A-Proposed-Compromise-to-the-Block-Size-Limit.xml b/static/bitcoin-dev/June_2015/combined_A-Proposed-Compromise-to-the-Block-Size-Limit.xml index 29af09a8c2..4f0f11e4dc 100644 --- a/static/bitcoin-dev/June_2015/combined_A-Proposed-Compromise-to-the-Block-Size-Limit.xml +++ b/static/bitcoin-dev/June_2015/combined_A-Proposed-Compromise-to-the-Block-Size-Limit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A Proposed Compromise to the Block Size Limit - 2023-08-01T14:03:11.909501+00:00 + 2025-10-11T21:37:57.887101+00:00 + python-feedgen Tom Harding 2015-07-10 02:55:15+00:00 @@ -175,13 +176,13 @@ - python-feedgen + 2 Combined summary - A Proposed Compromise to the Block Size Limit - 2023-08-01T14:03:11.909501+00:00 + 2025-10-11T21:37:57.887363+00:00 - Gavin Andresen, an influential figure in the Bitcoin community, expressed skepticism about the use of the Lightning Network for everyday transactions. He believed that very few personal Bitcoin or dollar transactions fit the use case that the Lightning Network is designed to solve. While he acknowledged its potential for innovation in micropayments and hourly worker payments, he did not see it as a scaling solution for the current types of payments handled by the Bitcoin network. He also raised concerns about centralization, particularly with payment channels between big financial institutions.The Lightning Network is a proposed solution to the scalability problem in Bitcoin transactions. It allows participants to send and receive coins through various hub connections without on-chain settlements. Each channel has a pseudonymous identity and can be closed when funds are needed for non-lightning reasons. The network has been described as a write coalescing write cache layer for Bitcoin. However, there are significant problems with the concept of hubs, including questions about knowledge, incentives, and complexity reduction. Despite being an interesting idea, the Lightning Network is still far from actual implementation.A discussion on Bitcoin scaling took place in 2015, where Benjamin expressed concerns about naive scaling and suggested working incrementally and carefully. Adam disagreed and explained how the Lightning Network works, stating that every lightning transaction is a valid bitcoin transaction. Adam clarified that lightning is expected to be peer-to-peer like Bitcoin.Decentralization is a crucial aspect of Bitcoin, and measuring its level can be challenging. The concept of pooling protocols can help phase out artificial centralization, but claims about decentralization often lack analysis or explanation. To improve discussions on changes, it is suggested to develop a metric for measuring decentralization.The author agrees that scaling Bitcoin in a naive way could have negative outcomes but acknowledges its advantages in not changing the original system. They express skepticism towards Level2 and Lightning solutions, stating that even if money is moved within the constraints of a locked contract, it does not solve the issues with off-chain transactions. The author argues that moving between off-chain and on-chain requires liquidity and a pricing mechanism, which is a problem similar to side-chains. Additionally, off-chain transactions on an exchange are subject to KYC/AML regulations.In a forum post, Raystonn explains that nodes are limited to 133 connections, and the load is only affected by transaction rate, not by the number of connections. There have been concerns about larger blocks resulting in exponential growth of work, but this is based on a wrong assumption. Decentralization is crucial for Bitcoin's security properties, and simplistic thinking about an ever-increasing block size is destructive. Improvement can be achieved through bandwidth and relay enhancements and pooling protocols to phase out artificial centralization.In an email conversation, Jameson Lopp and Peter Todd discuss Bitcoin scaling. Lopp argues that for Bitcoin to have O(n) scaling, the number of validation nodes must remain constant with the number of users. Todd disagrees, stating that it doesn't matter what the total work of the network is, as participants only care about the resources required to run their own node. He points out that the number of nodes is inversely proportional to the number of users, which presents a significant problem. O(n^2) scaling means that as Bitcoin is adopted more widely, it becomes harder to use in a decentralized way without trusting others.Another email conversation between Peter Todd and Michael Naber addresses global network consensus in Bitcoin. Naber questions whether off-chain solutions like hub-and-spoke payment channels and the Lightning network provide global network consensus. Todd explains that these solutions are actually more efficient ways of using on-chain transactions and enable economic transactions without any blockchain transactions. He asserts that Bitcoin Core scales with O(N), and achieving O(n) scaling would require a trust-based system. Todd suggests building a trust-based system on top of Bitcoin's global consensus functionality.The discussion on the Bitcoin development mailing list revolves around the fee market and its comparison to other markets. While there is no assured quality of service in the Bitcoin fee market, this is not uncommon in other financial markets. The comparison is made to a market maker's order book, but in Bitcoin, it is difficult to know how miners are positioning themselves at any given moment. The author suggests that establishing a feedback loop through auctions with increasing increments could settle demand and supply. However, adapting supply remains a challenge for resolving capacity problems.In an email exchange, Benjamin expresses doubts about the capacity and functioning of the Bitcoin system. He argues that there is no supply and demand mechanism that would allow users to adapt fees and receive different qualities of service based on current capacity. Peter Todd counters this claim by stating that Bitcoin already operates based on supply and demand. Fees can be adapted to obtain different qualities of service depending on capacity. Todd refers Benjamin to his article on how transaction fees work for more details.Bitcoin Core aims to solve the global consensus problem, but there are ongoing discussions about raising the block size and meeting the demand for high-capacity global consensus. 2015-07-10T02:55:15+00:00 + Gavin Andresen, an influential figure in the Bitcoin community, expressed skepticism about the use of the Lightning Network for everyday transactions. He believed that very few personal Bitcoin or dollar transactions fit the use case that the Lightning Network is designed to solve. While he acknowledged its potential for innovation in micropayments and hourly worker payments, he did not see it as a scaling solution for the current types of payments handled by the Bitcoin network. He also raised concerns about centralization, particularly with payment channels between big financial institutions.The Lightning Network is a proposed solution to the scalability problem in Bitcoin transactions. It allows participants to send and receive coins through various hub connections without on-chain settlements. Each channel has a pseudonymous identity and can be closed when funds are needed for non-lightning reasons. The network has been described as a write coalescing write cache layer for Bitcoin. However, there are significant problems with the concept of hubs, including questions about knowledge, incentives, and complexity reduction. Despite being an interesting idea, the Lightning Network is still far from actual implementation.A discussion on Bitcoin scaling took place in 2015, where Benjamin expressed concerns about naive scaling and suggested working incrementally and carefully. Adam disagreed and explained how the Lightning Network works, stating that every lightning transaction is a valid bitcoin transaction. Adam clarified that lightning is expected to be peer-to-peer like Bitcoin.Decentralization is a crucial aspect of Bitcoin, and measuring its level can be challenging. The concept of pooling protocols can help phase out artificial centralization, but claims about decentralization often lack analysis or explanation. To improve discussions on changes, it is suggested to develop a metric for measuring decentralization.The author agrees that scaling Bitcoin in a naive way could have negative outcomes but acknowledges its advantages in not changing the original system. They express skepticism towards Level2 and Lightning solutions, stating that even if money is moved within the constraints of a locked contract, it does not solve the issues with off-chain transactions. The author argues that moving between off-chain and on-chain requires liquidity and a pricing mechanism, which is a problem similar to side-chains. Additionally, off-chain transactions on an exchange are subject to KYC/AML regulations.In a forum post, Raystonn explains that nodes are limited to 133 connections, and the load is only affected by transaction rate, not by the number of connections. There have been concerns about larger blocks resulting in exponential growth of work, but this is based on a wrong assumption. Decentralization is crucial for Bitcoin's security properties, and simplistic thinking about an ever-increasing block size is destructive. Improvement can be achieved through bandwidth and relay enhancements and pooling protocols to phase out artificial centralization.In an email conversation, Jameson Lopp and Peter Todd discuss Bitcoin scaling. Lopp argues that for Bitcoin to have O(n) scaling, the number of validation nodes must remain constant with the number of users. Todd disagrees, stating that it doesn't matter what the total work of the network is, as participants only care about the resources required to run their own node. He points out that the number of nodes is inversely proportional to the number of users, which presents a significant problem. O(n^2) scaling means that as Bitcoin is adopted more widely, it becomes harder to use in a decentralized way without trusting others.Another email conversation between Peter Todd and Michael Naber addresses global network consensus in Bitcoin. Naber questions whether off-chain solutions like hub-and-spoke payment channels and the Lightning network provide global network consensus. Todd explains that these solutions are actually more efficient ways of using on-chain transactions and enable economic transactions without any blockchain transactions. He asserts that Bitcoin Core scales with O(N), and achieving O(n) scaling would require a trust-based system. Todd suggests building a trust-based system on top of Bitcoin's global consensus functionality.The discussion on the Bitcoin development mailing list revolves around the fee market and its comparison to other markets. While there is no assured quality of service in the Bitcoin fee market, this is not uncommon in other financial markets. The comparison is made to a market maker's order book, but in Bitcoin, it is difficult to know how miners are positioning themselves at any given moment. The author suggests that establishing a feedback loop through auctions with increasing increments could settle demand and supply. However, adapting supply remains a challenge for resolving capacity problems.In an email exchange, Benjamin expresses doubts about the capacity and functioning of the Bitcoin system. He argues that there is no supply and demand mechanism that would allow users to adapt fees and receive different qualities of service based on current capacity. Peter Todd counters this claim by stating that Bitcoin already operates based on supply and demand. Fees can be adapted to obtain different qualities of service depending on capacity. Todd refers Benjamin to his article on how transaction fees work for more details.Bitcoin Core aims to solve the global consensus problem, but there are ongoing discussions about raising the block size and meeting the demand for high-capacity global consensus. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_A-possible-solution-for-the-block-size-limit-Detection-and-rejection-of-bloated-blocks-by-full-nodes-.xml b/static/bitcoin-dev/June_2015/combined_A-possible-solution-for-the-block-size-limit-Detection-and-rejection-of-bloated-blocks-by-full-nodes-.xml index 6eb80c9c8c..6fde8a7097 100644 --- a/static/bitcoin-dev/June_2015/combined_A-possible-solution-for-the-block-size-limit-Detection-and-rejection-of-bloated-blocks-by-full-nodes-.xml +++ b/static/bitcoin-dev/June_2015/combined_A-possible-solution-for-the-block-size-limit-Detection-and-rejection-of-bloated-blocks-by-full-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes. - 2023-08-01T14:10:55.687060+00:00 + 2025-10-11T21:38:55.262590+00:00 + python-feedgen Jeremy 2015-07-01 02:52:16+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes. - 2023-08-01T14:10:55.687060+00:00 + 2025-10-11T21:38:55.262780+00:00 - A proposal has been made to phase shift transaction fees by one block in order to prevent miners from putting in a bunch of transactions for free. The idea is that a miner would orphan a block that didn't properly reward them, making it very costly for the miner to do so. The phase can be adjusted to different amounts and spread over multiple blocks or even randomly selected at the time of mining from a pool of un-fee claimed blocks. However, this approach requires 100% mempool synchronization across all nodes on the network to reject a particular block. Otherwise, an attempted double spend could result in a fork in the network because some nodes saw it and some did not.The block size debate centers around the concern that if the block size is increased, malicious miners may publish unreasonably large "bloated" blocks. A solution proposed to detect these bloated blocks is to set a threshold by nodes on the allowable number of non-mempool transactions allowed in a solved block (e.g., maybe 50%). If a block contains more than this threshold of non-mempool transactions, it is rejected. The proposal states that if this idea works, the block size limitation could be completely removed. 2015-07-01T02:52:16+00:00 + A proposal has been made to phase shift transaction fees by one block in order to prevent miners from putting in a bunch of transactions for free. The idea is that a miner would orphan a block that didn't properly reward them, making it very costly for the miner to do so. The phase can be adjusted to different amounts and spread over multiple blocks or even randomly selected at the time of mining from a pool of un-fee claimed blocks. However, this approach requires 100% mempool synchronization across all nodes on the network to reject a particular block. Otherwise, an attempted double spend could result in a fork in the network because some nodes saw it and some did not.The block size debate centers around the concern that if the block size is increased, malicious miners may publish unreasonably large "bloated" blocks. A solution proposed to detect these bloated blocks is to set a threshold by nodes on the allowable number of non-mempool transactions allowed in a solved block (e.g., maybe 50%). If a block contains more than this threshold of non-mempool transactions, it is rejected. The proposal states that if this idea works, the block size limitation could be completely removed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Address-Expiration-to-Prevent-Reuse.xml b/static/bitcoin-dev/June_2015/combined_Address-Expiration-to-Prevent-Reuse.xml index 7fc544b8c4..6a6d886ffe 100644 --- a/static/bitcoin-dev/June_2015/combined_Address-Expiration-to-Prevent-Reuse.xml +++ b/static/bitcoin-dev/June_2015/combined_Address-Expiration-to-Prevent-Reuse.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Address Expiration to Prevent Reuse - 2023-08-01T12:10:53.102726+00:00 + 2025-10-11T21:38:10.636118+00:00 + python-feedgen odinn 2015-06-13 04:52:25+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Address Expiration to Prevent Reuse - 2023-08-01T12:10:53.102726+00:00 + 2025-10-11T21:38:10.636288+00:00 - The Bitcoin community has been discussing the implementation of address expiration to reduce the monitoring requirements associated with the increasing number of Bitcoin addresses. The idea is to add an expiration date to Bitcoin addresses, forcing users to create new addresses periodically instead of keeping old ones active indefinitely. This would help reduce the burden of monitoring old addresses and prevent the buildup of unused addresses over time.However, there are concerns about the potential implications of address expiration. One concern is that if businesses are issued with an address by a government body, then all transactions can be tracked for that business entity, compromising privacy and fungibility. Some argue that address reuse should be allowed in certain cases, such as for donation addresses or when accounting requirements necessitate archiving all keys and transaction hashes.Gregory Maxwell proposed encoding an expiration date into the address itself and specifying that clients enforce it. This would simplify the implementation and ensure that individuals who want to hack their client to make payments not according to the payee's specifications will have to face the consequences.There have also been discussions about the potential drawbacks of enforcing address expiration. It could invalidate payments made at or just before expiration in case of reorganization, and it may increase recommended confirmations above current levels centered around the possibility of a malicious double-spend. The benefit of the Bitcoin network providing this service needs to be weighed against the potential cost.Overall, address expiration presents an interesting potential solution to the issue of increasing Bitcoin addresses. While it remains to be seen whether it will be adopted in the future, it could have a positive impact on the scalability and efficiency of the Bitcoin network. 2015-06-13T04:52:25+00:00 + The Bitcoin community has been discussing the implementation of address expiration to reduce the monitoring requirements associated with the increasing number of Bitcoin addresses. The idea is to add an expiration date to Bitcoin addresses, forcing users to create new addresses periodically instead of keeping old ones active indefinitely. This would help reduce the burden of monitoring old addresses and prevent the buildup of unused addresses over time.However, there are concerns about the potential implications of address expiration. One concern is that if businesses are issued with an address by a government body, then all transactions can be tracked for that business entity, compromising privacy and fungibility. Some argue that address reuse should be allowed in certain cases, such as for donation addresses or when accounting requirements necessitate archiving all keys and transaction hashes.Gregory Maxwell proposed encoding an expiration date into the address itself and specifying that clients enforce it. This would simplify the implementation and ensure that individuals who want to hack their client to make payments not according to the payee's specifications will have to face the consequences.There have also been discussions about the potential drawbacks of enforcing address expiration. It could invalidate payments made at or just before expiration in case of reorganization, and it may increase recommended confirmations above current levels centered around the possibility of a malicious double-spend. The benefit of the Bitcoin network providing this service needs to be weighed against the potential cost.Overall, address expiration presents an interesting potential solution to the issue of increasing Bitcoin addresses. While it remains to be seen whether it will be adopted in the future, it could have a positive impact on the scalability and efficiency of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Alternate-HD-path-structure-BIP-blog-or-wat-.xml b/static/bitcoin-dev/June_2015/combined_Alternate-HD-path-structure-BIP-blog-or-wat-.xml index 7641170f35..7cb75ce2d9 100644 --- a/static/bitcoin-dev/June_2015/combined_Alternate-HD-path-structure-BIP-blog-or-wat-.xml +++ b/static/bitcoin-dev/June_2015/combined_Alternate-HD-path-structure-BIP-blog-or-wat-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Alternate HD path structure: BIP, blog, or wat? - 2023-08-01T13:26:57.817120+00:00 + 2025-10-11T21:37:47.269172+00:00 + python-feedgen Jonas Schnelli 2015-06-20 10:11:41+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Alternate HD path structure: BIP, blog, or wat? - 2023-08-01T13:26:57.818120+00:00 + 2025-10-11T21:37:47.269316+00:00 - The author of the message expresses concerns regarding HD chain standards like Bip43/44, stating that while they are designed to allow users to use different wallets with the same seed/wordlist, there can be risks and potential loss of coins when re-importing or re-creating a wallet. The author argues that a user's non-blockchain metadata cannot be recovered through HD seed recovery, as it is only intended for disaster recovery purposes. Reimporting an HD seed is considered an expert feature that requires manual configuration. The author also suggests that creating deep level chains in HD wallets requires more CPU power and may cause delays when signing or deriving on hardware wallets like Trezor or Digitalbitbox.The author questions whether the current standards of HD chain structures lead users and developers in the right direction, pointing out examples of wallets like Electrum and Breadwallet that do not follow the Bip39 standard or support Bip44. To provide further information, the message includes links to Bitcointalk.org and Github.com.In another discussion, the implementation of a new token layer on an existing blockchain is being discussed. The use of HD wallets to generate new token addresses is seen as a straightforward task, but maintaining them could be challenging. However, using this method allows older HD wallet software to understand which blockchain to query for utxos and generate valid addresses without updates, even if it doesn't know about the specific token. This approach is particularly useful when developing against platforms where client updates cannot be enforced. It is clarified that this is not a general-purpose successor to BIP44. Another member suggests using a different path, m/44'/9'/a'/c/i, instead of relying on internal mappings.In an email exchange between two individuals named Matt, the use of a proposed path structure in HD wallets is discussed. The proposed structure separates the concepts of network and coin type, which would be valuable when importing a wallet into an application and checking addresses derived below a specific path for balances against a specific blockchain. However, concerns are raised about the relevance of storing all variables of the path structure in the wallet database, as there is no way to retrieve the path used from just the address. It is suggested that using m/account'/change/index or m/change/index, depending on whether hardened child keys are used, would be more appropriate. Multisig HD wallet imports may require master keys and a list of account paths instead of addresses due to the possibility of new addresses being derived between exporting and importing wallet data.Another context provided discusses the use of the identifier "99" to identify a counterparty in the blockchain system. Concerns are raised about the use of this identifier, and alternatives are suggested. One proposal is to use m/44'/9'/a'/c/i, as described in the documentation for slip-0044, to avoid the need for internal mappings. Considering these suggestions could improve the efficiency and accuracy of the blockchain system.Matt Smith from Gem discusses the need to store paths in the wallet database. He explains that there is no way to infer the path of an address inside an HD wallet from the address alone. Therefore, it is necessary to store either the paths, addresses, or both that have been previously derived or used to monitor the blockchain effectively. The motivation for the proposed path structure is that it separates the concepts of network and coin type, which is useful when importing a wallet into an application and knowing that an account was in use at a specific path. Matt also mentions that multisig HD wallet imports may require master keys and a list of account paths rather than just addresses. He concludes by stating that this use case might be specific to their model and requests a BIP number to start using it.Gem, a company offering wallets for multiple cryptocurrencies, is considering a new HD wallet path structure. This structure aims to validate address formats, select appropriate daemons for scanning tokenized assets, and choose multiple blockchain data sources by utilizing information in the HDNode's path without maintaining explicit mappings. The proposed path structure separates the coin_type field into network and asset_type and is m/purpose'/network'/asset_type'/account'/change/index. However, there are concerns about storing all the variables of the path structure in the wallet database, as there is no way to retrieve the path from just the address. Gem is considering publishing this information in a blog post or requesting a BIP number for further development. They are also seeking feedback and suggestions from the community.Overall, these discussions highlight the challenges, risks, and possible improvements related to HD chain standards, token layer implementation, identifier usage, and HD wallet path structures in the blockchain system. 2015-06-20T10:11:41+00:00 + The author of the message expresses concerns regarding HD chain standards like Bip43/44, stating that while they are designed to allow users to use different wallets with the same seed/wordlist, there can be risks and potential loss of coins when re-importing or re-creating a wallet. The author argues that a user's non-blockchain metadata cannot be recovered through HD seed recovery, as it is only intended for disaster recovery purposes. Reimporting an HD seed is considered an expert feature that requires manual configuration. The author also suggests that creating deep level chains in HD wallets requires more CPU power and may cause delays when signing or deriving on hardware wallets like Trezor or Digitalbitbox.The author questions whether the current standards of HD chain structures lead users and developers in the right direction, pointing out examples of wallets like Electrum and Breadwallet that do not follow the Bip39 standard or support Bip44. To provide further information, the message includes links to Bitcointalk.org and Github.com.In another discussion, the implementation of a new token layer on an existing blockchain is being discussed. The use of HD wallets to generate new token addresses is seen as a straightforward task, but maintaining them could be challenging. However, using this method allows older HD wallet software to understand which blockchain to query for utxos and generate valid addresses without updates, even if it doesn't know about the specific token. This approach is particularly useful when developing against platforms where client updates cannot be enforced. It is clarified that this is not a general-purpose successor to BIP44. Another member suggests using a different path, m/44'/9'/a'/c/i, instead of relying on internal mappings.In an email exchange between two individuals named Matt, the use of a proposed path structure in HD wallets is discussed. The proposed structure separates the concepts of network and coin type, which would be valuable when importing a wallet into an application and checking addresses derived below a specific path for balances against a specific blockchain. However, concerns are raised about the relevance of storing all variables of the path structure in the wallet database, as there is no way to retrieve the path used from just the address. It is suggested that using m/account'/change/index or m/change/index, depending on whether hardened child keys are used, would be more appropriate. Multisig HD wallet imports may require master keys and a list of account paths instead of addresses due to the possibility of new addresses being derived between exporting and importing wallet data.Another context provided discusses the use of the identifier "99" to identify a counterparty in the blockchain system. Concerns are raised about the use of this identifier, and alternatives are suggested. One proposal is to use m/44'/9'/a'/c/i, as described in the documentation for slip-0044, to avoid the need for internal mappings. Considering these suggestions could improve the efficiency and accuracy of the blockchain system.Matt Smith from Gem discusses the need to store paths in the wallet database. He explains that there is no way to infer the path of an address inside an HD wallet from the address alone. Therefore, it is necessary to store either the paths, addresses, or both that have been previously derived or used to monitor the blockchain effectively. The motivation for the proposed path structure is that it separates the concepts of network and coin type, which is useful when importing a wallet into an application and knowing that an account was in use at a specific path. Matt also mentions that multisig HD wallet imports may require master keys and a list of account paths rather than just addresses. He concludes by stating that this use case might be specific to their model and requests a BIP number to start using it.Gem, a company offering wallets for multiple cryptocurrencies, is considering a new HD wallet path structure. This structure aims to validate address formats, select appropriate daemons for scanning tokenized assets, and choose multiple blockchain data sources by utilizing information in the HDNode's path without maintaining explicit mappings. The proposed path structure separates the coin_type field into network and asset_type and is m/purpose'/network'/asset_type'/account'/change/index. However, there are concerns about storing all the variables of the path structure in the wallet database, as there is no way to retrieve the path from just the address. Gem is considering publishing this information in a blog post or requesting a BIP number for further development. They are also seeking feedback and suggestions from the community.Overall, these discussions highlight the challenges, risks, and possible improvements related to HD chain standards, token layer implementation, identifier usage, and HD wallet path structures in the blockchain system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_BIP-Full-Replace-by-Fee-deployment-schedule.xml b/static/bitcoin-dev/June_2015/combined_BIP-Full-Replace-by-Fee-deployment-schedule.xml index 85763e9859..150e60f000 100644 --- a/static/bitcoin-dev/June_2015/combined_BIP-Full-Replace-by-Fee-deployment-schedule.xml +++ b/static/bitcoin-dev/June_2015/combined_BIP-Full-Replace-by-Fee-deployment-schedule.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP: Full Replace-by-Fee deployment schedule - 2023-08-01T14:08:53.854240+00:00 + 2025-10-11T21:38:12.759059+00:00 + python-feedgen Chris Pacia 2015-06-30 18:23:15+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - BIP: Full Replace-by-Fee deployment schedule - 2023-08-01T14:08:53.854240+00:00 + 2025-10-11T21:38:12.759205+00:00 - On June 30, 2015, there were email exchanges discussing the implementation of full Replace-by-Fee (RBF) in Bitcoin transactions. Peter Todd believed that contracts were being worked on due to inconsistent use of the first-seen protocol by some miners. Adam Back suggested deploying full-RBF in an opt-in way to transition towards trust-based and lightning/payment channel solutions. He warned about the risks of abruptly stopping the first-seen miner and relay policy. The impact of Invertible Bloom Lookup Tables (IBLT) on the first-seen policy was discussed between Chris Pacia and Adam Back. It was suggested that if a miner used full RBF while others used first-seen, their blocks would be at a disadvantage in terms of propagation. However, this disadvantage could be compensated for by higher fees. The discussion also highlighted the importance of fast block relaying for Bitcoin.Adam Back and David Harding discussed the support for opt-in full-RBF. Harding suggested bundling it with BIP62 version-2 transactions, but noted that it may delay the full BIP62 implementation. The conversation also touched upon the potential risks and consequences of meddling with successful usage patterns.Peter Todd raised concerns about payment providers entering into legal contracts with large miners, leading to centralization risks and potential 51% attacks. He suggested that nodes incentivize their peers to relay standard transactions to benefit the P2P network as a whole. The discussion also covered the benefits of full-RBF functionality in broadening what the P2P network relays.In another email exchange, Natanael expressed frustration over unresponsive recipients and concerns over the security of a proposed system. Tom Harding dismissed the idea of a sybil attack, while Natanael argued that the check means nothing unless one pays for hosting of that particular node. The conversation between Natanael and another person focused on the security and feasibility of a proposed feature. Natanael believed that the system would fail to a sybil attack, while the other person disagreed, stating that checking if a node relays something is similar to banning it for relaying garbage.These email exchanges highlight concerns about centralization risks, the impact of RBF on transaction propagation, the importance of fast block relaying, and debates about the role of policy in Bitcoin's development process.In an email exchange on June 29, 2015, Luke Dashjr and another participant disagreed on the role of BIPs (Bitcoin Improvement Proposals) in determining policy for nodes and miners. Luke argued that policy decisions are not within the scope of BIPs, while the other participant believed that BIPs can be used for best practices and coordination purposes.Peter Todd sent a message on the same day requesting Gregory to assign a BIP number to his proposal for full Replace-by-Fee (RBF) and transaction deadline functionality. However, Luke responded that such policy decisions should be left to the discretion of nodes and miners instead of being determined by proposals.The document presented is Peter Todd's proposal for the deployment schedule of Full Replace-by-Fee (Full-RBF) functionality. It suggests an automatic activation on April 5th, 2016 at 3 pm UTC, where supporting relay nodes and miners will enable full-RBF mempool behavior on the mainnet. Prior to the activation deadline, these nodes and miners will support first-seen-safe replace-by-fee (FSS-RBF) mempool behavior.The proposal highlights the efficiency advantages of Full-RBF over alternatives like FSS-RBF and Child-Pays-For-Parent for various transaction patterns and smart contract protocols. It states that miner support for Full-RBF would allow the Bitcoin community to use the blockchain more efficiently, handling more transactions per second with less blockchain space.The proposal also addresses concerns about double-spends and centralization risks. It acknowledges that decentralized wallets have limited ability to protect users from double-spends and that large payment providers may resort to extreme measures, such as entering into legal contracts with large miners, to ensure their transactions get mined. This poses a significant risk of centralization. The proposal aims to provide an orderly and planned upgrade that has been well-tested and considers potential DoS attacks.To maximize engineer availability, the deadline for the upgrade was set at the start of the week and away from public holidays. The nine-month timeframe was chosen to allow affected companies sufficient time to plan for the upgrade without delaying it excessively. The proposal includes references and is made available in the public domain.Overall, the context discusses the debate over BIPs' role in determining policy for nodes and miners, Peter Todd's proposal for Full-RBF functionality, its advantages, and considerations for an orderly implementation. It also addresses concerns about double-spends and centralization risks in the Bitcoin network. 2015-06-30T18:23:15+00:00 + On June 30, 2015, there were email exchanges discussing the implementation of full Replace-by-Fee (RBF) in Bitcoin transactions. Peter Todd believed that contracts were being worked on due to inconsistent use of the first-seen protocol by some miners. Adam Back suggested deploying full-RBF in an opt-in way to transition towards trust-based and lightning/payment channel solutions. He warned about the risks of abruptly stopping the first-seen miner and relay policy. The impact of Invertible Bloom Lookup Tables (IBLT) on the first-seen policy was discussed between Chris Pacia and Adam Back. It was suggested that if a miner used full RBF while others used first-seen, their blocks would be at a disadvantage in terms of propagation. However, this disadvantage could be compensated for by higher fees. The discussion also highlighted the importance of fast block relaying for Bitcoin.Adam Back and David Harding discussed the support for opt-in full-RBF. Harding suggested bundling it with BIP62 version-2 transactions, but noted that it may delay the full BIP62 implementation. The conversation also touched upon the potential risks and consequences of meddling with successful usage patterns.Peter Todd raised concerns about payment providers entering into legal contracts with large miners, leading to centralization risks and potential 51% attacks. He suggested that nodes incentivize their peers to relay standard transactions to benefit the P2P network as a whole. The discussion also covered the benefits of full-RBF functionality in broadening what the P2P network relays.In another email exchange, Natanael expressed frustration over unresponsive recipients and concerns over the security of a proposed system. Tom Harding dismissed the idea of a sybil attack, while Natanael argued that the check means nothing unless one pays for hosting of that particular node. The conversation between Natanael and another person focused on the security and feasibility of a proposed feature. Natanael believed that the system would fail to a sybil attack, while the other person disagreed, stating that checking if a node relays something is similar to banning it for relaying garbage.These email exchanges highlight concerns about centralization risks, the impact of RBF on transaction propagation, the importance of fast block relaying, and debates about the role of policy in Bitcoin's development process.In an email exchange on June 29, 2015, Luke Dashjr and another participant disagreed on the role of BIPs (Bitcoin Improvement Proposals) in determining policy for nodes and miners. Luke argued that policy decisions are not within the scope of BIPs, while the other participant believed that BIPs can be used for best practices and coordination purposes.Peter Todd sent a message on the same day requesting Gregory to assign a BIP number to his proposal for full Replace-by-Fee (RBF) and transaction deadline functionality. However, Luke responded that such policy decisions should be left to the discretion of nodes and miners instead of being determined by proposals.The document presented is Peter Todd's proposal for the deployment schedule of Full Replace-by-Fee (Full-RBF) functionality. It suggests an automatic activation on April 5th, 2016 at 3 pm UTC, where supporting relay nodes and miners will enable full-RBF mempool behavior on the mainnet. Prior to the activation deadline, these nodes and miners will support first-seen-safe replace-by-fee (FSS-RBF) mempool behavior.The proposal highlights the efficiency advantages of Full-RBF over alternatives like FSS-RBF and Child-Pays-For-Parent for various transaction patterns and smart contract protocols. It states that miner support for Full-RBF would allow the Bitcoin community to use the blockchain more efficiently, handling more transactions per second with less blockchain space.The proposal also addresses concerns about double-spends and centralization risks. It acknowledges that decentralized wallets have limited ability to protect users from double-spends and that large payment providers may resort to extreme measures, such as entering into legal contracts with large miners, to ensure their transactions get mined. This poses a significant risk of centralization. The proposal aims to provide an orderly and planned upgrade that has been well-tested and considers potential DoS attacks.To maximize engineer availability, the deadline for the upgrade was set at the start of the week and away from public holidays. The nine-month timeframe was chosen to allow affected companies sufficient time to plan for the upgrade without delaying it excessively. The proposal includes references and is made available in the public domain.Overall, the context discusses the debate over BIPs' role in determining policy for nodes and miners, Peter Todd's proposal for Full-RBF functionality, its advantages, and considerations for an orderly implementation. It also addresses concerns about double-spends and centralization risks in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_BIP-Process-and-Votes.xml b/static/bitcoin-dev/June_2015/combined_BIP-Process-and-Votes.xml index d3a16a906b..f6ff79d42d 100644 --- a/static/bitcoin-dev/June_2015/combined_BIP-Process-and-Votes.xml +++ b/static/bitcoin-dev/June_2015/combined_BIP-Process-and-Votes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP Process and Votes - 2023-08-01T13:51:59.523410+00:00 + 2025-10-11T21:38:29.758978+00:00 + python-feedgen odinn 2015-07-01 22:34:01+00:00 @@ -207,13 +208,13 @@ - python-feedgen + 2 Combined summary - BIP Process and Votes - 2023-08-01T13:51:59.525411+00:00 + 2025-10-11T21:38:29.759237+00:00 - The discussion on the Bitcoin-dev mailing list revolves around the process of hard forks and soft forks in Bitcoin. One suggestion is to have regularly scheduled hard forks with cut-off dates for BIP submissions to avoid debates and disagreements. It is mentioned that there is a defined process for soft forks, but not for hard forks, which can lead to issues of consensus. The fundamental problem is the lack of agreement on the block size.There is also a discussion about users expecting changes that would require a hard fork and the responsibility of core maintainers. In response to the discussion, suggestions are made to create a living document of risks and mitigations as well as a decentralization metric to measure proposed changes. There is a proposal for a second mailing list called "bitcoin-process" to educate people about the Bitcoin process, along with a FAQ on its sign-up page. Concerns are raised about the development of a new FAQ, as it may be controlled by a small group and present unrealistic claims. Criticism is also directed towards the Bitcoin wiki, which contains incorrect information and cult-like claims.The power dynamics within the Bitcoin community are discussed, particularly between developers, miners, users, merchants, and exchanges. There is a debate over who has control over the consensus rules, and concerns are raised about veto power held by developers with minimal stake in Bitcoin holdings. The need for a formal process for making decisions and deploying controversial changes is highlighted. The discussion ends with links to the Bitcoin-dev mailing list, emphasizing the importance of community involvement in decision-making processes.In another email thread, the role of Core Maintainer in managing the Bitcoin Core project is discussed. The discussion focuses on the ethical position of taking the safest option versus the majority's preference. Concerns are raised about potential lose-lose scenarios and the lack of mechanisms for resolving disagreements.The issue of power dynamics in bitcoin development decision-making is debated, with arguments about the influence of core developers and the vulnerability of the Bitcoin software development system. Suggestions are made for developing a process that does not rely on unwritten rules or one person's decision-making power. The importance of seeking consensus and maintaining decentralization is emphasized.The discussion brings attention to the fact that the Core Maintainer does not have more power than other individuals with GitHub commit privileges. Changes to the code must reach technical consensus before being merged. The official release of Bitcoin has significant power and control, leading to lobbying efforts for changes. Concerns are raised about the lack of mechanisms for deploying controversial changes to the consensus rules.Overall, the Bitcoin developer mailing list serves as a platform for discussions on power dynamics, decision-making processes, and the maintenance of Bitcoin Core. The need for community involvement and consensus in decision-making is acknowledged, along with the challenges posed by power dynamics within the community.Another email thread discusses the process of determining the block size limit and whether there is any consensus on it. Milly Bitcoin replied that there is no agreement on the block size limit and it has become a topic of debate. She suggested that regularly scheduled hard forks could be planned with cut-off dates for BIP submissions to avoid debates over whether there should be hard forks and what should be contained within them. She also proposed adding a step after "Dev acceptance" in the BIP process to include input from merchants, exchanges, miners, and users. The goal is to find a middle ground and move forward with an agreed-upon approach. Another participant in the conversation explained that if Satoshi had stated that 1MB was part of the definition of Bitcoin, people would accept it to the same extent as they accept the 21 million coin limit. However, there is no defined process for hard forks, which can result in a mutual veto. Both sides of the block size debate argue that their position should be considered the status quo.In response to this discussion, another participant suggests creating a living document of risks and mitigations as well as a decentralization metric to measure proposed changes. They also propose the creation of a second mailing list called "bitcoin-process" to educate people about the Bitcoin process, along with a FAQ on its sign-up page. However, concerns are raised about the development of a new FAQ, as it may be controlled by a small group and present unrealistic claims. Criticism is also directed towards the Bitcoin wiki, which contains incorrect information and cult-like claims.The power dynamics within the Bitcoin community are also debated, particularly between developers, miners, users, merchants, and exchanges. There is a debate over who has control over the consensus rules, and concerns are raised about veto power held by developers with minimal stake in Bitcoin holdings. The need for a formal process for making decisions and deploying controversial changes is highlighted. The discussion ends with links to the Bitcoin-dev mailing list, emphasizing the importance of community involvement in decision-making processes.In another email thread, the role of Core Maintainer in managing the Bitcoin Core project is discussed. The discussion focuses on the ethical position of taking the safest option versus the majority's preference 2015-07-01T22:34:01+00:00 + The discussion on the Bitcoin-dev mailing list revolves around the process of hard forks and soft forks in Bitcoin. One suggestion is to have regularly scheduled hard forks with cut-off dates for BIP submissions to avoid debates and disagreements. It is mentioned that there is a defined process for soft forks, but not for hard forks, which can lead to issues of consensus. The fundamental problem is the lack of agreement on the block size.There is also a discussion about users expecting changes that would require a hard fork and the responsibility of core maintainers. In response to the discussion, suggestions are made to create a living document of risks and mitigations as well as a decentralization metric to measure proposed changes. There is a proposal for a second mailing list called "bitcoin-process" to educate people about the Bitcoin process, along with a FAQ on its sign-up page. Concerns are raised about the development of a new FAQ, as it may be controlled by a small group and present unrealistic claims. Criticism is also directed towards the Bitcoin wiki, which contains incorrect information and cult-like claims.The power dynamics within the Bitcoin community are discussed, particularly between developers, miners, users, merchants, and exchanges. There is a debate over who has control over the consensus rules, and concerns are raised about veto power held by developers with minimal stake in Bitcoin holdings. The need for a formal process for making decisions and deploying controversial changes is highlighted. The discussion ends with links to the Bitcoin-dev mailing list, emphasizing the importance of community involvement in decision-making processes.In another email thread, the role of Core Maintainer in managing the Bitcoin Core project is discussed. The discussion focuses on the ethical position of taking the safest option versus the majority's preference. Concerns are raised about potential lose-lose scenarios and the lack of mechanisms for resolving disagreements.The issue of power dynamics in bitcoin development decision-making is debated, with arguments about the influence of core developers and the vulnerability of the Bitcoin software development system. Suggestions are made for developing a process that does not rely on unwritten rules or one person's decision-making power. The importance of seeking consensus and maintaining decentralization is emphasized.The discussion brings attention to the fact that the Core Maintainer does not have more power than other individuals with GitHub commit privileges. Changes to the code must reach technical consensus before being merged. The official release of Bitcoin has significant power and control, leading to lobbying efforts for changes. Concerns are raised about the lack of mechanisms for deploying controversial changes to the consensus rules.Overall, the Bitcoin developer mailing list serves as a platform for discussions on power dynamics, decision-making processes, and the maintenance of Bitcoin Core. The need for community involvement and consensus in decision-making is acknowledged, along with the challenges posed by power dynamics within the community.Another email thread discusses the process of determining the block size limit and whether there is any consensus on it. Milly Bitcoin replied that there is no agreement on the block size limit and it has become a topic of debate. She suggested that regularly scheduled hard forks could be planned with cut-off dates for BIP submissions to avoid debates over whether there should be hard forks and what should be contained within them. She also proposed adding a step after "Dev acceptance" in the BIP process to include input from merchants, exchanges, miners, and users. The goal is to find a middle ground and move forward with an agreed-upon approach. Another participant in the conversation explained that if Satoshi had stated that 1MB was part of the definition of Bitcoin, people would accept it to the same extent as they accept the 21 million coin limit. However, there is no defined process for hard forks, which can result in a mutual veto. Both sides of the block size debate argue that their position should be considered the status quo.In response to this discussion, another participant suggests creating a living document of risks and mitigations as well as a decentralization metric to measure proposed changes. They also propose the creation of a second mailing list called "bitcoin-process" to educate people about the Bitcoin process, along with a FAQ on its sign-up page. However, concerns are raised about the development of a new FAQ, as it may be controlled by a small group and present unrealistic claims. Criticism is also directed towards the Bitcoin wiki, which contains incorrect information and cult-like claims.The power dynamics within the Bitcoin community are also debated, particularly between developers, miners, users, merchants, and exchanges. There is a debate over who has control over the consensus rules, and concerns are raised about veto power held by developers with minimal stake in Bitcoin holdings. The need for a formal process for making decisions and deploying controversial changes is highlighted. The discussion ends with links to the Bitcoin-dev mailing list, emphasizing the importance of community involvement in decision-making processes.In another email thread, the role of Core Maintainer in managing the Bitcoin Core project is discussed. The discussion focuses on the ethical position of taking the safest option versus the majority's preference - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_BIP-for-Proof-of-Payment.xml b/static/bitcoin-dev/June_2015/combined_BIP-for-Proof-of-Payment.xml index 9f39a857c2..8f6f53f205 100644 --- a/static/bitcoin-dev/June_2015/combined_BIP-for-Proof-of-Payment.xml +++ b/static/bitcoin-dev/June_2015/combined_BIP-for-Proof-of-Payment.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP for Proof of Payment - 2023-08-01T13:06:47.119601+00:00 + 2025-10-11T21:37:21.788698+00:00 + python-feedgen Kalle Rosenbaum 2015-07-27 11:21:38+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - BIP for Proof of Payment - 2023-08-01T13:06:47.119601+00:00 + 2025-10-11T21:37:21.788915+00:00 - In an email exchange, Jorge Timón and Kalle Rosenbaum discuss the topic of increasing the nonce. Kalle asks if they need a bigger nonce, to which Jorge responds that he was not the one who proposed the idea. Instead, he reminds Kalle that the policy limit should not be a concern. The context does not provide any further details or background information on what the nonce is and why it might need to be increased.On July 24, 2015, Kalle Rosenbaum announced via bitcoin-dev that two new Bitcoin Improvement Proposals (BIPs) had been assigned numbers 120 and 121. The announcement prompted celebration, as the BIPs had faced challenges during the proposal process. The email thread did not provide further information on the content of the BIPs or their implications for Bitcoin development.In an email thread discussing the size of the nonce used in Proof of Payment (PoP) as outlined in Bitcoin Improvement Proposal (BIP) 120, it was noted that Bitcoin core now supports 80 bytes of data by default and does not maintain a policy limit. The BIP had assumed a limit of 40 bytes across all implementations. It was suggested that if there is a need to increase the size of the nonce, it could be done in a subsequent version of PoP. However, a longer nonce would result in bigger QR codes generated from the BIP 121 URIs, making 48 bits a good tradeoff for now. It was also mentioned that a server generating PoP requests should try to detect brute force attacks or delay the response containing the nonce by some 100ms. If PoP becomes an extension of BIP70, then there will be no size constraint on the nonce.Two Bitcoin Improvement Proposals (BIPs) have been assigned numbers 120 and 121. BIP 120 is for Proof of Payment, while BIP 121 is for a Proof of Payment URI scheme. Kalle Rosenbaum requested that these proposals be given their BIP numbers after much constructive discussion and feedback. During the discussions, Pieter Wuille raised some concerns about the Proof of Payment proposal, as it assumed that a transaction corresponds to a single payment. He suggested tracking payments instead of assigning identities to payers. However, Kalle believed that assigning a proof of payment was necessary for privacy reasons and proposed a nonce parameter in the URI, which was limited to 48 bits due to an OP_RETURN output limitation of 40 bytes.The context provided is a brief email conversation between Kalle and Pieter. Kalle thanks Pieter for his comments, but the rest of the conversation is not given. The conversation seems to be related to a reusable token that needs to be transferred to a friend. However, no information is provided on what this token is or why it needs to be transferred. It is not clear what the purpose of this conversation is and what the overall topic of discussion is.Kalle Rosenbaum has requested that proposals "Proof of Payment" and "Proof of Payment URI scheme" be assigned BIP numbers after constructive discussions, feedback, and updates. The source for both proposals can be found on GitHub. A limitation of 40 bytes for the OP_RETURN output had been discussed, and while it was suggested that a bigger nonce could be used, Kalle opted to stick with this limit due to simplifying implementation and not needing more data than 40 bytes. The Proof of Payment proposal allows for better privacy for customers who do not have to give out personal information such as an email address. It also creates a window of opportunity for thieves that is minimized since PoP is only usable once and created when needed. Different use cases will require different protection. The cost of using tokens is security, since a stolen token can be used over and over again.The discussion revolves around the Proof of Payment (PoP) feature for Bitcoin. Kalle Rosenbaum, who proposed the feature, discusses its limitations and use cases with Pieter Wuille. Rosenbaum notes that PoP allows for better privacy for customers who don't want to give out personal information such as email addresses. Wuille questions why anyone cares who paid and suggests that tracking payments rather than assigning identities to payers is a better approach. However, Rosenbaum indicates that the identity of the payer is necessary for PoP to work since the wallet used to pay must also be used to issue the PoP. The two discuss methods of sharing PoPs, including forwarding requests or transferring keys to friends' wallets. They also compare PoP to using tokens and note that tokens are reusable, whereas PoP is only usable once, which minimizes the window of opportunity for thieves.The discussion revolves around the limitation of creating a 40-byte OP_RETURN. The limitation comes from a relay policy in full nodes, not a limitation is wallet software. PoPs are not relayed on the network. The purpose of the PoP is to ensure that only the 2015-07-27T11:21:38+00:00 + In an email exchange, Jorge Timón and Kalle Rosenbaum discuss the topic of increasing the nonce. Kalle asks if they need a bigger nonce, to which Jorge responds that he was not the one who proposed the idea. Instead, he reminds Kalle that the policy limit should not be a concern. The context does not provide any further details or background information on what the nonce is and why it might need to be increased.On July 24, 2015, Kalle Rosenbaum announced via bitcoin-dev that two new Bitcoin Improvement Proposals (BIPs) had been assigned numbers 120 and 121. The announcement prompted celebration, as the BIPs had faced challenges during the proposal process. The email thread did not provide further information on the content of the BIPs or their implications for Bitcoin development.In an email thread discussing the size of the nonce used in Proof of Payment (PoP) as outlined in Bitcoin Improvement Proposal (BIP) 120, it was noted that Bitcoin core now supports 80 bytes of data by default and does not maintain a policy limit. The BIP had assumed a limit of 40 bytes across all implementations. It was suggested that if there is a need to increase the size of the nonce, it could be done in a subsequent version of PoP. However, a longer nonce would result in bigger QR codes generated from the BIP 121 URIs, making 48 bits a good tradeoff for now. It was also mentioned that a server generating PoP requests should try to detect brute force attacks or delay the response containing the nonce by some 100ms. If PoP becomes an extension of BIP70, then there will be no size constraint on the nonce.Two Bitcoin Improvement Proposals (BIPs) have been assigned numbers 120 and 121. BIP 120 is for Proof of Payment, while BIP 121 is for a Proof of Payment URI scheme. Kalle Rosenbaum requested that these proposals be given their BIP numbers after much constructive discussion and feedback. During the discussions, Pieter Wuille raised some concerns about the Proof of Payment proposal, as it assumed that a transaction corresponds to a single payment. He suggested tracking payments instead of assigning identities to payers. However, Kalle believed that assigning a proof of payment was necessary for privacy reasons and proposed a nonce parameter in the URI, which was limited to 48 bits due to an OP_RETURN output limitation of 40 bytes.The context provided is a brief email conversation between Kalle and Pieter. Kalle thanks Pieter for his comments, but the rest of the conversation is not given. The conversation seems to be related to a reusable token that needs to be transferred to a friend. However, no information is provided on what this token is or why it needs to be transferred. It is not clear what the purpose of this conversation is and what the overall topic of discussion is.Kalle Rosenbaum has requested that proposals "Proof of Payment" and "Proof of Payment URI scheme" be assigned BIP numbers after constructive discussions, feedback, and updates. The source for both proposals can be found on GitHub. A limitation of 40 bytes for the OP_RETURN output had been discussed, and while it was suggested that a bigger nonce could be used, Kalle opted to stick with this limit due to simplifying implementation and not needing more data than 40 bytes. The Proof of Payment proposal allows for better privacy for customers who do not have to give out personal information such as an email address. It also creates a window of opportunity for thieves that is minimized since PoP is only usable once and created when needed. Different use cases will require different protection. The cost of using tokens is security, since a stolen token can be used over and over again.The discussion revolves around the Proof of Payment (PoP) feature for Bitcoin. Kalle Rosenbaum, who proposed the feature, discusses its limitations and use cases with Pieter Wuille. Rosenbaum notes that PoP allows for better privacy for customers who don't want to give out personal information such as email addresses. Wuille questions why anyone cares who paid and suggests that tracking payments rather than assigning identities to payers is a better approach. However, Rosenbaum indicates that the identity of the payer is necessary for PoP to work since the wallet used to pay must also be used to issue the PoP. The two discuss methods of sharing PoPs, including forwarding requests or transferring keys to friends' wallets. They also compare PoP to using tokens and note that tokens are reusable, whereas PoP is only usable once, which minimizes the window of opportunity for thieves.The discussion revolves around the limitation of creating a 40-byte OP_RETURN. The limitation comes from a relay policy in full nodes, not a limitation is wallet software. PoPs are not relayed on the network. The purpose of the PoP is to ensure that only the - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml b/static/bitcoin-dev/June_2015/combined_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml index f4977cea18..4f3747489a 100644 --- a/static/bitcoin-dev/June_2015/combined_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml +++ b/static/bitcoin-dev/June_2015/combined_BIP65-CHECKLOCKTIMEVERIFY-deployment.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP65 / CHECKLOCKTIMEVERIFY deployment - 2023-08-01T13:54:09.592100+00:00 + 2025-10-11T21:37:51.514028+00:00 + python-feedgen Pieter Wuille 2015-08-04 16:54:39+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP65 / CHECKLOCKTIMEVERIFY deployment - 2023-08-01T13:54:09.592100+00:00 + 2025-10-11T21:37:51.514180+00:00 - On June 25, 2015, Peter Todd proposed the deployment of CheckLockTimeVerify (CLTV) considering its benefits to scalability solutions. He suggested using the existing median block version mechanism for CLTV as it is well-tested and understood. Todd stated that there is no lack of consensus on this proposal. He further added that if another soft-fork is proposed prior to BIP65 enforcement, they have the option of setting in motion yet another soft-fork as the median mechanism only requires forks to be serialized in sequence. The CLTV code has been extensively reviewed in the form of the "mempool-only" pull-req, has been included in the Elements sidechain prototype by Mark Friedenbach, has been running in production on Viacoin for six months, and has a few working demos of its functionality implemented.The adoption of BIP66 is close to 95% and will soon be enforced for all blocks. This leads to the consideration of how CheckLockTimeVerify (CLTV) will be implemented, especially given its benefits to scalability solutions such as payment channels. Peter Todd, a co-author of the Version bits BIP proposal, suggests that CLTV should be deployed sooner as the implementation of the BIP proposal will be complex. The CLTV code has been extensively reviewed and tested, including running in production on Viacoin for six months. Peter Todd proposes using the existing median block version mechanism previously used for nVersion=2 and nVersion=3 soft-forks for CLTV. This approach is well-tested and understood, allowing for easy backporting to v0.10.x (even 0.9.x) with low risk for rapid deployment. If another soft-fork is proposed before BIP65 enforcement, nVersion=4 can be set in motion as the median mechanism only requires forks to be serialized in sequence. Multiple soft-forks can be "in-flight" at the same time. 2015-08-04T16:54:39+00:00 + On June 25, 2015, Peter Todd proposed the deployment of CheckLockTimeVerify (CLTV) considering its benefits to scalability solutions. He suggested using the existing median block version mechanism for CLTV as it is well-tested and understood. Todd stated that there is no lack of consensus on this proposal. He further added that if another soft-fork is proposed prior to BIP65 enforcement, they have the option of setting in motion yet another soft-fork as the median mechanism only requires forks to be serialized in sequence. The CLTV code has been extensively reviewed in the form of the "mempool-only" pull-req, has been included in the Elements sidechain prototype by Mark Friedenbach, has been running in production on Viacoin for six months, and has a few working demos of its functionality implemented.The adoption of BIP66 is close to 95% and will soon be enforced for all blocks. This leads to the consideration of how CheckLockTimeVerify (CLTV) will be implemented, especially given its benefits to scalability solutions such as payment channels. Peter Todd, a co-author of the Version bits BIP proposal, suggests that CLTV should be deployed sooner as the implementation of the BIP proposal will be complex. The CLTV code has been extensively reviewed and tested, including running in production on Viacoin for six months. Peter Todd proposes using the existing median block version mechanism previously used for nVersion=2 and nVersion=3 soft-forks for CLTV. This approach is well-tested and understood, allowing for easy backporting to v0.10.x (even 0.9.x) with low risk for rapid deployment. If another soft-fork is proposed before BIP65 enforcement, nVersion=4 can be set in motion as the median mechanism only requires forks to be serialized in sequence. Multiple soft-forks can be "in-flight" at the same time. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Bip-32-Question.xml b/static/bitcoin-dev/June_2015/combined_Bip-32-Question.xml index a2abdd38b4..49ddcc7f4c 100644 --- a/static/bitcoin-dev/June_2015/combined_Bip-32-Question.xml +++ b/static/bitcoin-dev/June_2015/combined_Bip-32-Question.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bip 32 Question - 2023-08-01T13:14:18.514023+00:00 + 2025-10-11T21:37:55.764116+00:00 + python-feedgen William Swanson 2015-06-12 19:42:46+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bip 32 Question - 2023-08-01T13:14:18.514974+00:00 + 2025-10-11T21:37:55.764277+00:00 - In a discussion about BIP32, James Poole is seeking clarification on the meaning of "n" in the context of an algorithm. Specifically, he is referring to the line in the BIP32 definition that states "The returned child key ki is parse256(IL) + kpar (mod n)." To understand the role of "n," James has provided a link to the Bitcoin wiki page for Secp256k1, which explains that "n" represents the curve order. This step is essential to ensure that the user stays on the curve. The function secp256k1_ec_privkey_tweak_add from libsecp256k1 automatically handles this process, but for those using OpenSSL or non-EC math libraries, it may need to be done manually. By asking for help, James hopes to gain a clearer understanding of how "n" functions within the algorithm. For further information, you can refer to the provided links. 2015-06-12T19:42:46+00:00 + In a discussion about BIP32, James Poole is seeking clarification on the meaning of "n" in the context of an algorithm. Specifically, he is referring to the line in the BIP32 definition that states "The returned child key ki is parse256(IL) + kpar (mod n)." To understand the role of "n," James has provided a link to the Bitcoin wiki page for Secp256k1, which explains that "n" represents the curve order. This step is essential to ensure that the user stays on the curve. The function secp256k1_ec_privkey_tweak_add from libsecp256k1 automatically handles this process, but for those using OpenSSL or non-EC math libraries, it may need to be done manually. By asking for help, James hopes to gain a clearer understanding of how "n" functions within the algorithm. For further information, you can refer to the provided links. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Bitcoin-Core-The-globally-aware-global-consensus-network.xml b/static/bitcoin-dev/June_2015/combined_Bitcoin-Core-The-globally-aware-global-consensus-network.xml index a36e590d11..c481ee3995 100644 --- a/static/bitcoin-dev/June_2015/combined_Bitcoin-Core-The-globally-aware-global-consensus-network.xml +++ b/static/bitcoin-dev/June_2015/combined_Bitcoin-Core-The-globally-aware-global-consensus-network.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core: The globally aware global consensus network - 2023-08-01T14:09:08.735225+00:00 + 2025-10-11T21:38:27.635741+00:00 + python-feedgen Pindar Wong 2015-06-29 09:17:00+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core: The globally aware global consensus network - 2023-08-01T14:09:08.735225+00:00 + 2025-10-11T21:38:27.635885+00:00 - The email thread revolves around the need for global awareness in Bitcoin transactions and emphasizes Bitcoin Core's role as the central hub. The author proposes conducting thorough testing before increasing the maximum block size to 8 MB, with the possibility of further adjustments in the future as technology advances. Evan suggests that Huobi requires three months of testing on a test-net, commencing in early-mid October. To discuss the results of the testing process and address any remaining concerns, the author offers to host a face-to-face meeting in Hong Kong on October 14-15. They also invite anyone willing to contribute resources for the design, execution, and analysis of the testing to participate.While Bitcoin is a globally aware consensus network, it is not necessary for each node to be aware of every transaction for running a worldwide payment network due to technological limitations. Global awareness is a finite resource, hence the need for hub and spoke designs to facilitate worldwide transactions without requiring global awareness. However, there still needs to be a central "hub," and Bitcoin Core should strive to be that hub by being the best globally aware global consensus network possible. To achieve this, it is crucial to ensure that the network can operate at its maximum capacity based on current technology.If the test-net demonstrates that current hardware can safely handle an 8 MB block size, there will be widespread developer support to implement this change. This step is essential in building the most optimal network. Additionally, as technology progresses, the block size can be adjusted upwards to further improve the network. In summary, Bitcoin must focus on becoming the best globally aware global consensus network by maximizing the network's capacity within technological limits. Continuous adjustments and improvements are necessary to maintain its position as the leading network for worldwide transactions. 2015-06-29T09:17:00+00:00 + The email thread revolves around the need for global awareness in Bitcoin transactions and emphasizes Bitcoin Core's role as the central hub. The author proposes conducting thorough testing before increasing the maximum block size to 8 MB, with the possibility of further adjustments in the future as technology advances. Evan suggests that Huobi requires three months of testing on a test-net, commencing in early-mid October. To discuss the results of the testing process and address any remaining concerns, the author offers to host a face-to-face meeting in Hong Kong on October 14-15. They also invite anyone willing to contribute resources for the design, execution, and analysis of the testing to participate.While Bitcoin is a globally aware consensus network, it is not necessary for each node to be aware of every transaction for running a worldwide payment network due to technological limitations. Global awareness is a finite resource, hence the need for hub and spoke designs to facilitate worldwide transactions without requiring global awareness. However, there still needs to be a central "hub," and Bitcoin Core should strive to be that hub by being the best globally aware global consensus network possible. To achieve this, it is crucial to ensure that the network can operate at its maximum capacity based on current technology.If the test-net demonstrates that current hardware can safely handle an 8 MB block size, there will be widespread developer support to implement this change. This step is essential in building the most optimal network. Additionally, as technology progresses, the block size can be adjusted upwards to further improve the network. In summary, Bitcoin must focus on becoming the best globally aware global consensus network by maximizing the network's capacity within technological limits. Continuous adjustments and improvements are necessary to maintain its position as the leading network for worldwide transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Block-Size-Debate-Analogy-Workaround-Bitcoin-is-Like-Windows-3-11.xml b/static/bitcoin-dev/June_2015/combined_Block-Size-Debate-Analogy-Workaround-Bitcoin-is-Like-Windows-3-11.xml index f23ea57350..c601ceb07d 100644 --- a/static/bitcoin-dev/June_2015/combined_Block-Size-Debate-Analogy-Workaround-Bitcoin-is-Like-Windows-3-11.xml +++ b/static/bitcoin-dev/June_2015/combined_Block-Size-Debate-Analogy-Workaround-Bitcoin-is-Like-Windows-3-11.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block Size Debate Analogy / Workaround: Bitcoin is Like Windows 3.11 - 2023-08-01T14:05:11.809297+00:00 + 2025-10-11T21:38:17.017204+00:00 + python-feedgen Bernd Jendrissek 2015-06-27 17:36:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Block Size Debate Analogy / Workaround: Bitcoin is Like Windows 3.11 - 2023-08-01T14:05:11.809297+00:00 + 2025-10-11T21:38:17.017375+00:00 - In a thought-provoking comparison, the author of an email to a Bitcoin mailing list draws parallels between Bitcoin and Windows 3.11. The crux of their argument lies in the backward compatibility aspect of both systems. While they debate whether Bitcoin should follow the path of Windows 95, XP, Pro, etc., and undergo updates, an important point is overlooked.The comparison fails to acknowledge that running a program written for Windows 95 on a Windows 3.11 computer would be impossible if everyone upgraded to Windows 95. This is due to the absence of cross-compilers from Windows 95 to Windows 3.11. Similarly, the author highlights the issue of spending coins with post-hardfork coinbase outputs in their input tree on the no-change side of the fork, which poses a challenge.Considering the dilemma faced by those who choose not to upgrade and have funds tied up in the platform, the author raises valid concerns about the future of Bitcoin. They question whether it should remain as it is, with newer and better programs being developed exclusively for the updated versions. To address this debate, the author proposes a constructive solution. They suggest that representatives from both sides of the issue come together and appoint a developer representative. By working collaboratively, they can establish a framework that takes into account the interests of all stakeholders involved. This approach aims to find a middle ground between progress and the preservation of existing investments within the Bitcoin ecosystem. 2015-06-27T17:36:50+00:00 + In a thought-provoking comparison, the author of an email to a Bitcoin mailing list draws parallels between Bitcoin and Windows 3.11. The crux of their argument lies in the backward compatibility aspect of both systems. While they debate whether Bitcoin should follow the path of Windows 95, XP, Pro, etc., and undergo updates, an important point is overlooked.The comparison fails to acknowledge that running a program written for Windows 95 on a Windows 3.11 computer would be impossible if everyone upgraded to Windows 95. This is due to the absence of cross-compilers from Windows 95 to Windows 3.11. Similarly, the author highlights the issue of spending coins with post-hardfork coinbase outputs in their input tree on the no-change side of the fork, which poses a challenge.Considering the dilemma faced by those who choose not to upgrade and have funds tied up in the platform, the author raises valid concerns about the future of Bitcoin. They question whether it should remain as it is, with newer and better programs being developed exclusively for the updated versions. To address this debate, the author proposes a constructive solution. They suggest that representatives from both sides of the issue come together and appoint a developer representative. By working collaboratively, they can establish a framework that takes into account the interests of all stakeholders involved. This approach aims to find a middle ground between progress and the preservation of existing investments within the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Block-size-increase-oppositionists-please-clearly-define-what-you-need-done-to-increase-block-size-to-a-static-8MB-and-help-do-it.xml b/static/bitcoin-dev/June_2015/combined_Block-size-increase-oppositionists-please-clearly-define-what-you-need-done-to-increase-block-size-to-a-static-8MB-and-help-do-it.xml index 93ccc6acb4..327f223f8b 100644 --- a/static/bitcoin-dev/June_2015/combined_Block-size-increase-oppositionists-please-clearly-define-what-you-need-done-to-increase-block-size-to-a-static-8MB-and-help-do-it.xml +++ b/static/bitcoin-dev/June_2015/combined_Block-size-increase-oppositionists-please-clearly-define-what-you-need-done-to-increase-block-size-to-a-static-8MB-and-help-do-it.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it - 2023-08-01T14:09:32.579617+00:00 + 2025-10-11T21:38:14.882331+00:00 + python-feedgen Bryan Cheng 2015-06-30 19:59:23+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it - 2023-08-01T14:09:32.580610+00:00 + 2025-10-11T21:38:14.882532+00:00 - The Bitcoin development mailing list has seen a discussion about the arbitrary nature of the 1MB block size limit in Bitcoin. The post suggests that there is no technical or economic reason to keep the block size at 1MB and argues for considering 8MB as the minimum applicable size. It emphasizes the need for specific use cases explaining how an increase in block size would marginalize them. Additionally, the post proposes a real discussion about finding the right sweet spot for block size and even questions whether 1MB is too big. Increasing the block size is seen as having the potential to create a fee market after coinbase subsidies decline.The conversation on the email thread focuses on scaling the Bitcoin network. Doubling the capacity is suggested to accommodate more network participants, but concerns are raised about scaling beyond that. It is argued that simply increasing capacity with hardware may be a solution. The idea of an 8MB block size increase is also mentioned, highlighting worries about exclusion and decentralization. Testing at double capacity (2MB) is proposed as a potential solution to address these concerns. However, the question remains about the purpose and feasibility of doubling capacity if there is no clear way to scale further.On June 30, 2015, Venzen Khaosan proposed a static 8MB block size for Bitcoin. This proposal sparked concerns about exclusion from testnet and mainnet participants, as well as compromising diversity and decentralization. To mitigate these issues, testing at double capacity (2MB) is suggested. However, doubts arise regarding scaling beyond that and the necessity of such an increase. Peter Todd contributes to the discussion, pointing out the lack of a clear path for further scaling in the proposed plan.In another message, Michael expresses his support for lobbying a block size increase to 8MB. Peter Todd proposes a combined back-test and ongoing forward test to ensure the infrastructure ecosystem can handle an 8MB block size. This includes considerations about the scalability of various components such as block explorers, SPV wallets, initial synchronization feasibility, and the UTXO set's scalability. Testing at double capacity (2MB) is suggested instead to avoid excluding many participants and contributors. The core issue is that an 8MB block size would exclude numerous mainnet participants (miners) and compromise diversity and decentralization.The context emphasizes the need for consensus in increasing the block size to a static 8MB. An analogy is made to an engineer building planes with increasing capacity, highlighting the approaching zero cost of adding transactions to blocks. However, miners still need to charge fees to sustain their business. The author calls for the community to collaborate and conduct necessary tests while agreeing on future increases in block size as technology allows. Stifling progress is seen as contrary to Bitcoin's best interests, potentially leading to a fork. The message stresses prioritizing Bitcoin's growth and expansion to meet user needs and market demand for increased capacity. 2015-06-30T19:59:23+00:00 + The Bitcoin development mailing list has seen a discussion about the arbitrary nature of the 1MB block size limit in Bitcoin. The post suggests that there is no technical or economic reason to keep the block size at 1MB and argues for considering 8MB as the minimum applicable size. It emphasizes the need for specific use cases explaining how an increase in block size would marginalize them. Additionally, the post proposes a real discussion about finding the right sweet spot for block size and even questions whether 1MB is too big. Increasing the block size is seen as having the potential to create a fee market after coinbase subsidies decline.The conversation on the email thread focuses on scaling the Bitcoin network. Doubling the capacity is suggested to accommodate more network participants, but concerns are raised about scaling beyond that. It is argued that simply increasing capacity with hardware may be a solution. The idea of an 8MB block size increase is also mentioned, highlighting worries about exclusion and decentralization. Testing at double capacity (2MB) is proposed as a potential solution to address these concerns. However, the question remains about the purpose and feasibility of doubling capacity if there is no clear way to scale further.On June 30, 2015, Venzen Khaosan proposed a static 8MB block size for Bitcoin. This proposal sparked concerns about exclusion from testnet and mainnet participants, as well as compromising diversity and decentralization. To mitigate these issues, testing at double capacity (2MB) is suggested. However, doubts arise regarding scaling beyond that and the necessity of such an increase. Peter Todd contributes to the discussion, pointing out the lack of a clear path for further scaling in the proposed plan.In another message, Michael expresses his support for lobbying a block size increase to 8MB. Peter Todd proposes a combined back-test and ongoing forward test to ensure the infrastructure ecosystem can handle an 8MB block size. This includes considerations about the scalability of various components such as block explorers, SPV wallets, initial synchronization feasibility, and the UTXO set's scalability. Testing at double capacity (2MB) is suggested instead to avoid excluding many participants and contributors. The core issue is that an 8MB block size would exclude numerous mainnet participants (miners) and compromise diversity and decentralization.The context emphasizes the need for consensus in increasing the block size to a static 8MB. An analogy is made to an engineer building planes with increasing capacity, highlighting the approaching zero cost of adding transactions to blocks. However, miners still need to charge fees to sustain their business. The author calls for the community to collaborate and conduct necessary tests while agreeing on future increases in block size as technology allows. Stifling progress is seen as contrary to Bitcoin's best interests, potentially leading to a fork. The message stresses prioritizing Bitcoin's growth and expansion to meet user needs and market demand for increased capacity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Concerns-Regarding-Threats-by-a-Developer-to-Remove-Commit-Access-from-Other-Developers.xml b/static/bitcoin-dev/June_2015/combined_Concerns-Regarding-Threats-by-a-Developer-to-Remove-Commit-Access-from-Other-Developers.xml index 0ce8da8ab4..24ebd85769 100644 --- a/static/bitcoin-dev/June_2015/combined_Concerns-Regarding-Threats-by-a-Developer-to-Remove-Commit-Access-from-Other-Developers.xml +++ b/static/bitcoin-dev/June_2015/combined_Concerns-Regarding-Threats-by-a-Developer-to-Remove-Commit-Access-from-Other-Developers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers - 2023-08-01T13:22:00.676771+00:00 + 2025-10-11T21:37:43.017808+00:00 + python-feedgen Owen Gunden 2015-06-21 14:45:30+00:00 @@ -243,13 +244,13 @@ - python-feedgen + 2 Combined summary - Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers - 2023-08-01T13:22:00.678769+00:00 + 2025-10-11T21:37:43.018150+00:00 - The context discusses various issues related to decision-making, consensus, and the process of proposing changes in Bitcoin Core. It emphasizes the importance of convincing users about the benefits of agreeing on a common trade protocol for the growth of Bitcoin. The author suggests focusing on informing users about the consequences of their choices and making improvements based on user feedback.The proposal introduces a new process for submitting draft BIPs that affect the block chain consensus rules or the peer-to-peer protocol. It defines criteria for verdict delivery and provides instructions for rejected BIPs. However, there is no interest in improving the BIP process, which has not changed much since its adaptation from Python Enhancement Proposals.Discussions among developers highlight concerns about the lack of a formalized decision-making process in Bitcoin Core. Technical consensus is understood, but the absence of rules hampers progress and prevents the system from being manipulated. The role of users in choosing software and the need for a genuine process to avoid contention are emphasized.Email exchanges reveal debates regarding decision-making power, the importance of consensus, and the process of hard forks. The lack of clarity and a formalized process lead to frustration, and the need for a clear process that cannot be manipulated is emphasized. The possibility of hard forks and their implications are discussed, as well as the necessity of a mechanism for people to disagree with consensus decisions.Allegations of projects being run like Wikipedia or involved in an "edit war" are deemed false and can be verified through commit history. The importance of a clear decision-making process is stressed, and the author raises concerns about the current process and the potential for conflicts.Overall, the context highlights the need for a transparent and efficient decision-making process in Bitcoin Core, along with the importance of consensus, user feedback, and informed choices. It also addresses the challenges associated with hard forks and the role of developers and users in shaping the future of Bitcoin.In a discussion between Pieter Wuille and Wladimir J. van der Laan, the lack of a clear process for making changes to Bitcoin software development was highlighted. The current process is disorganized, with decisions being made through random tweets, Reddit posts, and blog posts. This lack of structure makes Bitcoin appear amateurish and risky. While forks are accepted in open source projects, Wuille cautioned against contentious hard forks due to the potential consequences they may have on the chain.Pieter Wuille responded to a suggestion made by Mike Hearn regarding a hardfork for Bitcoin Core. He explained that while softforks can be implemented relatively easily, hardforks are much more difficult as they require users to migrate to a new system. This migration process is risky and cannot guarantee that everyone will change their full nodes. Wuille argued that controversial changes to the system's rules set a dangerous precedent about who is in charge and emphasized the importance of consensus among users. Technological growth should not compromise the fundamental principles of the system.Wladimir J. van der Laan addressed criticisms that the Bitcoin Core project is run like Wikipedia or an "edit war." He stated that there have been very few reversions in over 5,500 commits made in six years, disproving the claim that anyone with commit access can block change. However, he acknowledged that controversies can arise, leading to reluctance in touching certain issues.Mike Hearn expressed his belief that managing Bitcoin with a Linux kernel style dictator would lead to centralization, which is not ideal for Bitcoin. Hard forks put everyone's bitcoins at risk, and this approach could expose individuals to threats and blackmailing. Hearn hopes that the confrontation surrounding Bitcoin will demonstrate the cryptocurrency's resistance to centralization and emphasize the importance of consensus.The Bitcoin Core project handles consensus changes differently from other open-source projects. Achieving consensus is challenging, and controversial issues are dealt with carefully. The ongoing libconsensus work aims to separate Bitcoin Core from Bitcoin Consensus, maintaining a decentralized network beyond anyone's control. Running the codebase like Wikipedia is not feasible, as maintainers must make decisions and respect them for the project to progress.A user on the Bitcoin development mailing list expressed concerns about a developer's "nuclear suggestion" to revoke commit access from everyone else and make changes independently. The user viewed this as sabotage against the Bitcoin community and called for an apology and explanation. The user also mentioned a recent policy change at bitcoin.org to prevent similar situations in the future. 2015-06-21T14:45:30+00:00 + The context discusses various issues related to decision-making, consensus, and the process of proposing changes in Bitcoin Core. It emphasizes the importance of convincing users about the benefits of agreeing on a common trade protocol for the growth of Bitcoin. The author suggests focusing on informing users about the consequences of their choices and making improvements based on user feedback.The proposal introduces a new process for submitting draft BIPs that affect the block chain consensus rules or the peer-to-peer protocol. It defines criteria for verdict delivery and provides instructions for rejected BIPs. However, there is no interest in improving the BIP process, which has not changed much since its adaptation from Python Enhancement Proposals.Discussions among developers highlight concerns about the lack of a formalized decision-making process in Bitcoin Core. Technical consensus is understood, but the absence of rules hampers progress and prevents the system from being manipulated. The role of users in choosing software and the need for a genuine process to avoid contention are emphasized.Email exchanges reveal debates regarding decision-making power, the importance of consensus, and the process of hard forks. The lack of clarity and a formalized process lead to frustration, and the need for a clear process that cannot be manipulated is emphasized. The possibility of hard forks and their implications are discussed, as well as the necessity of a mechanism for people to disagree with consensus decisions.Allegations of projects being run like Wikipedia or involved in an "edit war" are deemed false and can be verified through commit history. The importance of a clear decision-making process is stressed, and the author raises concerns about the current process and the potential for conflicts.Overall, the context highlights the need for a transparent and efficient decision-making process in Bitcoin Core, along with the importance of consensus, user feedback, and informed choices. It also addresses the challenges associated with hard forks and the role of developers and users in shaping the future of Bitcoin.In a discussion between Pieter Wuille and Wladimir J. van der Laan, the lack of a clear process for making changes to Bitcoin software development was highlighted. The current process is disorganized, with decisions being made through random tweets, Reddit posts, and blog posts. This lack of structure makes Bitcoin appear amateurish and risky. While forks are accepted in open source projects, Wuille cautioned against contentious hard forks due to the potential consequences they may have on the chain.Pieter Wuille responded to a suggestion made by Mike Hearn regarding a hardfork for Bitcoin Core. He explained that while softforks can be implemented relatively easily, hardforks are much more difficult as they require users to migrate to a new system. This migration process is risky and cannot guarantee that everyone will change their full nodes. Wuille argued that controversial changes to the system's rules set a dangerous precedent about who is in charge and emphasized the importance of consensus among users. Technological growth should not compromise the fundamental principles of the system.Wladimir J. van der Laan addressed criticisms that the Bitcoin Core project is run like Wikipedia or an "edit war." He stated that there have been very few reversions in over 5,500 commits made in six years, disproving the claim that anyone with commit access can block change. However, he acknowledged that controversies can arise, leading to reluctance in touching certain issues.Mike Hearn expressed his belief that managing Bitcoin with a Linux kernel style dictator would lead to centralization, which is not ideal for Bitcoin. Hard forks put everyone's bitcoins at risk, and this approach could expose individuals to threats and blackmailing. Hearn hopes that the confrontation surrounding Bitcoin will demonstrate the cryptocurrency's resistance to centralization and emphasize the importance of consensus.The Bitcoin Core project handles consensus changes differently from other open-source projects. Achieving consensus is challenging, and controversial issues are dealt with carefully. The ongoing libconsensus work aims to separate Bitcoin Core from Bitcoin Consensus, maintaining a decentralized network beyond anyone's control. Running the codebase like Wikipedia is not feasible, as maintainers must make decisions and respect them for the project to progress.A user on the Bitcoin development mailing list expressed concerns about a developer's "nuclear suggestion" to revoke commit access from everyone else and make changes independently. The user viewed this as sabotage against the Bitcoin community and called for an apology and explanation. The user also mentioned a recent policy change at bitcoin.org to prevent similar situations in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Consensus-enforced-transaction-replacement-via-sequence-numbers.xml b/static/bitcoin-dev/June_2015/combined_Consensus-enforced-transaction-replacement-via-sequence-numbers.xml index aabcd1251c..3b8ffd66c3 100644 --- a/static/bitcoin-dev/June_2015/combined_Consensus-enforced-transaction-replacement-via-sequence-numbers.xml +++ b/static/bitcoin-dev/June_2015/combined_Consensus-enforced-transaction-replacement-via-sequence-numbers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Consensus-enforced transaction replacement via sequence numbers - 2023-08-01T12:52:23.999880+00:00 + 2025-10-11T21:39:10.124480+00:00 + python-feedgen Rusty Russell 2015-06-10 02:40:38+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Consensus-enforced transaction replacement via sequence numbers - 2023-08-01T12:52:24.000880+00:00 + 2025-10-11T21:39:10.124755+00:00 - In various discussions within the Bitcoin development community, the implementation and potential changes to the relative lock-time feature in Bitcoin transactions are being explored. Peter Todd suggests using the nLockTime field similarly to how cltv works, which would simplify the implementation process. The need for one or two Bitcoin Improvement Proposals (BIPs) for this change is also discussed.Mike Hearn and another participant discuss possible changes to the semantics of the nSequence field. Mike suggests gating any changes with a high bit to preserve the original meaning for resource scheduling and update flood damping. The other individual argues that their proposal maintains the semantics of Satoshi's original construction and allows higher sequence numbers to hit the chain earlier. They question if they have failed in capturing the original intent.Gregory Maxwell proposes a change to make sequence numbers work as expected within the bounds of a decentralized system. This involves using a new transaction version number to indicate the change from sequence number to relative lock time. While this would give sequence numbers a rational meaning, applying this rule to legacy transactions could render them unspendable. It is not considered "consensus enforcement" but rather relative nlocktime.The original intention of sequence numbers in Bitcoin was for transaction replacement in multi-party transaction construction, such as micropayment channels. However, the lack of enforcement by miners makes relying on a transaction replacement policy impossible. To address this issue, sequence numbers can be given new consensus-enforced semantics as a relative lock-time. An example implementation of this concept can be found on Github as a policy change to the mempool processing of Bitcoin Core.Overall, the use of relative nLockTime and the proposed changes to sequence numbers aim to improve the functionality and reliability of payment channels in Bitcoin. By giving sequence numbers new semantics and allowing for bidirectional channels, the limitations of the original sequence numbers can be overcome. This has the potential to enhance the efficiency and security of micropayments and other multi-party transactions in the Bitcoin network. 2015-06-10T02:40:38+00:00 + In various discussions within the Bitcoin development community, the implementation and potential changes to the relative lock-time feature in Bitcoin transactions are being explored. Peter Todd suggests using the nLockTime field similarly to how cltv works, which would simplify the implementation process. The need for one or two Bitcoin Improvement Proposals (BIPs) for this change is also discussed.Mike Hearn and another participant discuss possible changes to the semantics of the nSequence field. Mike suggests gating any changes with a high bit to preserve the original meaning for resource scheduling and update flood damping. The other individual argues that their proposal maintains the semantics of Satoshi's original construction and allows higher sequence numbers to hit the chain earlier. They question if they have failed in capturing the original intent.Gregory Maxwell proposes a change to make sequence numbers work as expected within the bounds of a decentralized system. This involves using a new transaction version number to indicate the change from sequence number to relative lock time. While this would give sequence numbers a rational meaning, applying this rule to legacy transactions could render them unspendable. It is not considered "consensus enforcement" but rather relative nlocktime.The original intention of sequence numbers in Bitcoin was for transaction replacement in multi-party transaction construction, such as micropayment channels. However, the lack of enforcement by miners makes relying on a transaction replacement policy impossible. To address this issue, sequence numbers can be given new consensus-enforced semantics as a relative lock-time. An example implementation of this concept can be found on Github as a policy change to the mempool processing of Bitcoin Core.Overall, the use of relative nLockTime and the proposed changes to sequence numbers aim to improve the functionality and reliability of payment channels in Bitcoin. By giving sequence numbers new semantics and allowing for bidirectional channels, the limitations of the original sequence numbers can be overcome. This has the potential to enhance the efficiency and security of micropayments and other multi-party transactions in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_DevCore-London.xml b/static/bitcoin-dev/June_2015/combined_DevCore-London.xml index 88901bbcb6..657e871509 100644 --- a/static/bitcoin-dev/June_2015/combined_DevCore-London.xml +++ b/static/bitcoin-dev/June_2015/combined_DevCore-London.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DevCore London - 2023-08-01T12:13:17.868828+00:00 + 2025-10-11T21:39:12.249875+00:00 + python-feedgen Mike Hearn 2015-06-02 14:20:47+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - DevCore London - 2023-08-01T12:13:17.868828+00:00 + 2025-10-11T21:39:12.250023+00:00 - Former Bitcoin developer Mike Hearn has made his tutorial talk from DevCore 2015 available on the website. The tutorial provides detailed instructions on building a timestamping smart contracts app in just 30 minutes. It covers various aspects such as customizing the wallet-template app, constructing a complex multi-stage SPV proof of blockchain inclusion, saving and verifying proof files, binding transaction confidence state to the user interface, and creating a Mac DMG bundle with a custom icon.Hearn also announced an upcoming event called DevCore London, where he and other developers will be present to run a hackathon/workshop type event. During this event, Hearn will showcase a live coding session where he will write a decentralized cross-platform Tor supporting document timestamping app using OP_RETURN outputs. The app will have a user-friendly GUI and will be developed on stage within a span of 30 minutes.The event is open to the public and will take place at etc.venues St Paul's on April 15th. Apart from Hearn, attendees will include Gavin, Wladimir, Corey, and an unnamed individual. In the afternoon, the unnamed individual will host a hackathon/workshop event with a focus on contracts, although other topics will also be covered. The event aims to demonstrate the ease of writing contract apps in recent years. It promises to provide a hands-on experience for real developers rather than just being a platform for discussions. 2015-06-02T14:20:47+00:00 + Former Bitcoin developer Mike Hearn has made his tutorial talk from DevCore 2015 available on the website. The tutorial provides detailed instructions on building a timestamping smart contracts app in just 30 minutes. It covers various aspects such as customizing the wallet-template app, constructing a complex multi-stage SPV proof of blockchain inclusion, saving and verifying proof files, binding transaction confidence state to the user interface, and creating a Mac DMG bundle with a custom icon.Hearn also announced an upcoming event called DevCore London, where he and other developers will be present to run a hackathon/workshop type event. During this event, Hearn will showcase a live coding session where he will write a decentralized cross-platform Tor supporting document timestamping app using OP_RETURN outputs. The app will have a user-friendly GUI and will be developed on stage within a span of 30 minutes.The event is open to the public and will take place at etc.venues St Paul's on April 15th. Apart from Hearn, attendees will include Gavin, Wladimir, Corey, and an unnamed individual. In the afternoon, the unnamed individual will host a hackathon/workshop event with a focus on contracts, although other topics will also be covered. The event aims to demonstrate the ease of writing contract apps in recent years. It promises to provide a hands-on experience for real developers rather than just being a platform for discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml b/static/bitcoin-dev/June_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml index cb14437f23..c0883c0886 100644 --- a/static/bitcoin-dev/June_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml +++ b/static/bitcoin-dev/June_2015/combined_Draft-BIP-fixed-schedule-block-size-increase.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP : fixed-schedule block size increase - 2023-08-01T13:34:19.646161+00:00 + 2025-10-11T21:37:53.639956+00:00 + python-feedgen odinn 2015-08-19 03:45:47+00:00 @@ -251,13 +252,13 @@ - python-feedgen + 2 Combined summary - Draft BIP : fixed-schedule block size increase - 2023-08-01T13:34:19.647154+00:00 + 2025-10-11T21:37:53.640255+00:00 - A recent release by XT author(s) has not shown any sign of moving towards an "increasing consensus" version. However, the BIP authors are working together to create something meaningful and useful. Visualizations or graphs of miner votes on BIP 100 and BIP 101 are expected. Tier Nolan suggests making available a version of XT with only block size changes to address mining pools' concerns about its experimental nature. Additionally, there is discussion about combining BIP 100 and BIP 101 to increase consensus.In an email conversation, Tier Nolan suggested that miners vote to decide the soft limit for block size. However, one member argued against it, stating that it may lead to an anti-miner hardfork instead of a softfork. The discussion also referenced BIP99 and potential scenarios for reducing the supply.A suggestion was made to create a fourth test network with large blocks from the genesis onwards instead of replacing most of Testnet with a specialized test chain. Multiple test networks using the same code were also suggested.In a discussion on the Bitcoin-dev mailing list, Ross Nicoll suggested using a minimum height as a solution for activating hardforks. However, BIP99 recommended a minimum height plus 95% mining upgrade confirmation for uncontroversial hardforks. The activation discussion for general hardforks was inconclusive.Tier Nolan proposed making a version of Bitcoin XT with only blocksize changes available to address mining pools' concerns. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes, and the consensus measuring code could be removed. Satoshi Nakamoto's original proposal for a block height comparison could be used, and the state storing code could be eliminated by using the standard "counting" upgrade system.There is discussion about combining BIP 100 and BIP 101 to increase consensus. The proposed combined version includes a miner vote threshold, a notice period or earliest start time, a block size default target set to 1 MB, a soft limit set to 1MB, and a hard limit set to 8MB with doubling every two years. Miners could leave the 1MB limit initially, but the vote is to get the option to increase the block size. Legacy clients would remain until >80% of miners vote to raise the limit and a miner produces a >1MB block.The dismissal of a formal process in Bitcoin is criticized for not properly evaluating proposed changes. Some developers believe their knowledge makes them superior to outside experts. However, this attitude can be detrimental to Bitcoin's progress. It is suggested that a well-defined and well-documented evaluation process should be introduced to ensure the safety of proposed changes.In an email exchange, Peter Todd and Gavin Andresen discuss the impact of larger blocks on miners with poor connectivity. The suggestion to rent a server on the other side of the bottleneck is countered by concerns about insecure infrastructure. The discussion also highlights the centralizing effect of mining control and the need for proposals to counter it.Gavin Andresen promised to write a BIP after implementing the increase-the-maximum-block-size code. The discussion mentions updating contact information and upcoming events.In an email conversation, Gavin Andresen discusses the analogy of a suspension bridge with limited traffic capacity and tolls increasing as demand rises. The proposed change is to expand the bridge, but careful analysis is needed. Civil engineering teaches us not to give in to political pressure until consequences are well understood.The discussion on the Bitcoin-dev mailing list focuses on the centralizing effect of miner connectivity and its impact on block propagation. Simulations show that miners with poor connectivity are negatively affected. Suggestions to work around this include renting a server on the other side of the bottleneck, but concerns about insecure infrastructure are raised. The discussion also addresses the need for proposals to counter mining centralization.Moving averages are compared to fixed growth, but they have limitations. Gavin Andresen suggests changing the default 'target' block size to the average of the last N blocks to create healthy "fee pressure" in the system.In an email conversation, Gavin Andresen and Will discuss block size. The suggestion is made to make the lazy miners' default choice grow at a slower rate than the average, which would encourage more fee pressure in the system.In 2017, Gavin Andresen put forward a Bitcoin Improvement Proposal (BIP) to increase the maximum block size from one megabyte to 8,000,000 bytes. The proposal suggests doubling the block size every two years until it reaches 8,192,000,000 bytes. To activate this change, a hash-power supermajority vote is required. This proposal allows miners, merchants, and users running full-nodes ample time to upgrade their software to support larger blocks.It's important to note that this proposed change is a hard-forking modification to the Bitcoin protocol. Therefore, anyone running code that fully validates blocks must upgrade their software before the activation time. Failure to do so may result in rejecting a 2015-08-19T03:45:47+00:00 + A recent release by XT author(s) has not shown any sign of moving towards an "increasing consensus" version. However, the BIP authors are working together to create something meaningful and useful. Visualizations or graphs of miner votes on BIP 100 and BIP 101 are expected. Tier Nolan suggests making available a version of XT with only block size changes to address mining pools' concerns about its experimental nature. Additionally, there is discussion about combining BIP 100 and BIP 101 to increase consensus.In an email conversation, Tier Nolan suggested that miners vote to decide the soft limit for block size. However, one member argued against it, stating that it may lead to an anti-miner hardfork instead of a softfork. The discussion also referenced BIP99 and potential scenarios for reducing the supply.A suggestion was made to create a fourth test network with large blocks from the genesis onwards instead of replacing most of Testnet with a specialized test chain. Multiple test networks using the same code were also suggested.In a discussion on the Bitcoin-dev mailing list, Ross Nicoll suggested using a minimum height as a solution for activating hardforks. However, BIP99 recommended a minimum height plus 95% mining upgrade confirmation for uncontroversial hardforks. The activation discussion for general hardforks was inconclusive.Tier Nolan proposed making a version of Bitcoin XT with only blocksize changes available to address mining pools' concerns. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes, and the consensus measuring code could be removed. Satoshi Nakamoto's original proposal for a block height comparison could be used, and the state storing code could be eliminated by using the standard "counting" upgrade system.There is discussion about combining BIP 100 and BIP 101 to increase consensus. The proposed combined version includes a miner vote threshold, a notice period or earliest start time, a block size default target set to 1 MB, a soft limit set to 1MB, and a hard limit set to 8MB with doubling every two years. Miners could leave the 1MB limit initially, but the vote is to get the option to increase the block size. Legacy clients would remain until >80% of miners vote to raise the limit and a miner produces a >1MB block.The dismissal of a formal process in Bitcoin is criticized for not properly evaluating proposed changes. Some developers believe their knowledge makes them superior to outside experts. However, this attitude can be detrimental to Bitcoin's progress. It is suggested that a well-defined and well-documented evaluation process should be introduced to ensure the safety of proposed changes.In an email exchange, Peter Todd and Gavin Andresen discuss the impact of larger blocks on miners with poor connectivity. The suggestion to rent a server on the other side of the bottleneck is countered by concerns about insecure infrastructure. The discussion also highlights the centralizing effect of mining control and the need for proposals to counter it.Gavin Andresen promised to write a BIP after implementing the increase-the-maximum-block-size code. The discussion mentions updating contact information and upcoming events.In an email conversation, Gavin Andresen discusses the analogy of a suspension bridge with limited traffic capacity and tolls increasing as demand rises. The proposed change is to expand the bridge, but careful analysis is needed. Civil engineering teaches us not to give in to political pressure until consequences are well understood.The discussion on the Bitcoin-dev mailing list focuses on the centralizing effect of miner connectivity and its impact on block propagation. Simulations show that miners with poor connectivity are negatively affected. Suggestions to work around this include renting a server on the other side of the bottleneck, but concerns about insecure infrastructure are raised. The discussion also addresses the need for proposals to counter mining centralization.Moving averages are compared to fixed growth, but they have limitations. Gavin Andresen suggests changing the default 'target' block size to the average of the last N blocks to create healthy "fee pressure" in the system.In an email conversation, Gavin Andresen and Will discuss block size. The suggestion is made to make the lazy miners' default choice grow at a slower rate than the average, which would encourage more fee pressure in the system.In 2017, Gavin Andresen put forward a Bitcoin Improvement Proposal (BIP) to increase the maximum block size from one megabyte to 8,000,000 bytes. The proposal suggests doubling the block size every two years until it reaches 8,192,000,000 bytes. To activate this change, a hash-power supermajority vote is required. This proposal allows miners, merchants, and users running full-nodes ample time to upgrade their software to support larger blocks.It's important to note that this proposed change is a hard-forking modification to the Bitcoin protocol. Therefore, anyone running code that fully validates blocks must upgrade their software before the activation time. Failure to do so may result in rejecting a - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_F2Pool-has-enabled-full-replace-by-fee.xml b/static/bitcoin-dev/June_2015/combined_F2Pool-has-enabled-full-replace-by-fee.xml index 587269ac5e..9030bd073e 100644 --- a/static/bitcoin-dev/June_2015/combined_F2Pool-has-enabled-full-replace-by-fee.xml +++ b/static/bitcoin-dev/June_2015/combined_F2Pool-has-enabled-full-replace-by-fee.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - F2Pool has enabled full replace-by-fee - 2023-08-01T13:25:58.026253+00:00 + 2025-10-11T21:38:42.513005+00:00 + python-feedgen Jeff Garzik 2015-06-21 19:49:41+00:00 @@ -299,13 +300,13 @@ - python-feedgen + 2 Combined summary - F2Pool has enabled full replace-by-fee - 2023-08-01T13:25:58.027254+00:00 + 2025-10-11T21:38:42.513208+00:00 - In a series of email exchanges among Bitcoin developers, the topic of non-repudiation and the ability of the Bitcoin network to withstand double-spend attacks is discussed. Eric Lombrozo argues that non-repudiation is not necessary in the Bitcoin protocol, as there is no association of identity with signatures. He warns against blindly accepting unconfirmed transactions without assessing the risks involved. Jorge Timón disagrees, stating that non-repudiation can be built on top of the payment protocol layer. The two also discuss the network's ability to handle double-spend attacks, with Lombrozo emphasizing the need for merchants to assess the risks before accepting unconfirmed transactions. Timón cites Satoshi's statement that as long as a majority of CPU power is not cooperating to attack the network, they will outpace attackers. Lombrozo clarifies that he is not suggesting unconfirmed transactions are part of global consensus, but rather cautioning against accepting them without considering the risks.The discussion also touches on the design of the Bitcoin network to withstand double-spend attacks. Lombrozo argues that the network should be designed with this requirement in mind, while another participant cites Satoshi's statement about the majority of CPU power generating the longest chain. They clarify that attacking the network means attempting to rewrite valid, proof-of-work-timestamped history, which unconfirmed transactions are not yet part of. Lombrozo emphasizes that unconfirmed transactions should not be accepted as final without assessing the risks.The concept of non-repudiation mechanisms in the Bitcoin protocol is also discussed. Lombrozo suggests that if such a mechanism is desired, it should be explicitly defined rather than relying on assumptions. Timón believes that non-repudiation can be built on top of the payment protocol layer using ECDSA signatures. The importance of accurately defining mechanisms and not relying on assumptions is emphasized.The context also includes discussions on the implications of Bitcoin for users and businesses. Coinbase's decision to restrict firearms businesses from accepting Bitcoins is mentioned, leading to a debate over alternate payment options. The context also mentions F2Pool enabling full replace-by-fee (RBF) support, which may create risks for merchants using payment processors/transaction APIs. The need for confirmations prior to accepting orders is highlighted.The safety of unconfirmed transactions is discussed, with arguments made about their relative security compared to credit card payments that can be charged back. The potential for double-spending is acknowledged, but it is noted that most people have better things to do than try to steal small amounts, and vendors have learned to tolerate a certain level of risk. Analogies are made to vending machines selling newspapers, which are often left unmonitored despite the potential for abuse.Overall, the discussions revolve around the need for assessing risks, designing the network to withstand attacks, defining non-repudiation mechanisms, and considering the safety of unconfirmed transactions in the Bitcoin ecosystem.Adrian Macneil, Wladimir van der Laan, and Gregory Maxwell criticized Chainalysis's actions, referring to it as a Sybil attack. They argued that the Bitcoin P2P network is resilient when the chance of any one node going down is uncorrelated with others. However, if a bug exists in a node that fails to relay transactions or blocks properly, it can disrupt a large portion of the network simultaneously. Coinbase, a major player in the Bitcoin industry, runs multiple nodes of Bitcoin Core and accepts zeroconf payments from customers. Their goal is to drive bitcoin adoption by making it easy for people to spend their bitcoin with online merchants. However, there are concerns about the systemic risks of failure caused by Coinbase connecting to many nodes on the network.There is a discussion about the meaning of "prima facie" and whether fraud should be assumed by default. It is suggested that the null hypothesis should be the default assumption instead. The author argues that no assumption should be made about the possibility of double-spending being fraudulent or not without any information.Peter Todd expresses disappointment in F2Pool enabling full Replace-by-Fee (RBF) instead of the safer first-seen-safe RBF. He believes that the fees gained by supporting full RBF over FSS RBF would be negligible. He also discusses the differences between standard and zeroconf versions of replace-by-fee patch.Eric Lombrozo warns that relaxing the assumption that the Bitcoin network can withstand deliberate double-spend attacks could result in terrible security practice. He suggests that it's dangerous to assume that security measures are safe because they have never been hacked before. Lombrozo argues that miners must still intervene in cases of human misbehavior, even if the signed transaction itself is proof of intention to pay.Chun Wang claims to have performed a successful bitcoin double spend in 2013 without any mining power. Peter Todd replies with information about first-seen-safe replace-by-fee and the differences between standard and zeroconf versions of replace-by-fee patch.Jeff Garzik emphasizes 2015-06-21T19:49:41+00:00 + In a series of email exchanges among Bitcoin developers, the topic of non-repudiation and the ability of the Bitcoin network to withstand double-spend attacks is discussed. Eric Lombrozo argues that non-repudiation is not necessary in the Bitcoin protocol, as there is no association of identity with signatures. He warns against blindly accepting unconfirmed transactions without assessing the risks involved. Jorge Timón disagrees, stating that non-repudiation can be built on top of the payment protocol layer. The two also discuss the network's ability to handle double-spend attacks, with Lombrozo emphasizing the need for merchants to assess the risks before accepting unconfirmed transactions. Timón cites Satoshi's statement that as long as a majority of CPU power is not cooperating to attack the network, they will outpace attackers. Lombrozo clarifies that he is not suggesting unconfirmed transactions are part of global consensus, but rather cautioning against accepting them without considering the risks.The discussion also touches on the design of the Bitcoin network to withstand double-spend attacks. Lombrozo argues that the network should be designed with this requirement in mind, while another participant cites Satoshi's statement about the majority of CPU power generating the longest chain. They clarify that attacking the network means attempting to rewrite valid, proof-of-work-timestamped history, which unconfirmed transactions are not yet part of. Lombrozo emphasizes that unconfirmed transactions should not be accepted as final without assessing the risks.The concept of non-repudiation mechanisms in the Bitcoin protocol is also discussed. Lombrozo suggests that if such a mechanism is desired, it should be explicitly defined rather than relying on assumptions. Timón believes that non-repudiation can be built on top of the payment protocol layer using ECDSA signatures. The importance of accurately defining mechanisms and not relying on assumptions is emphasized.The context also includes discussions on the implications of Bitcoin for users and businesses. Coinbase's decision to restrict firearms businesses from accepting Bitcoins is mentioned, leading to a debate over alternate payment options. The context also mentions F2Pool enabling full replace-by-fee (RBF) support, which may create risks for merchants using payment processors/transaction APIs. The need for confirmations prior to accepting orders is highlighted.The safety of unconfirmed transactions is discussed, with arguments made about their relative security compared to credit card payments that can be charged back. The potential for double-spending is acknowledged, but it is noted that most people have better things to do than try to steal small amounts, and vendors have learned to tolerate a certain level of risk. Analogies are made to vending machines selling newspapers, which are often left unmonitored despite the potential for abuse.Overall, the discussions revolve around the need for assessing risks, designing the network to withstand attacks, defining non-repudiation mechanisms, and considering the safety of unconfirmed transactions in the Bitcoin ecosystem.Adrian Macneil, Wladimir van der Laan, and Gregory Maxwell criticized Chainalysis's actions, referring to it as a Sybil attack. They argued that the Bitcoin P2P network is resilient when the chance of any one node going down is uncorrelated with others. However, if a bug exists in a node that fails to relay transactions or blocks properly, it can disrupt a large portion of the network simultaneously. Coinbase, a major player in the Bitcoin industry, runs multiple nodes of Bitcoin Core and accepts zeroconf payments from customers. Their goal is to drive bitcoin adoption by making it easy for people to spend their bitcoin with online merchants. However, there are concerns about the systemic risks of failure caused by Coinbase connecting to many nodes on the network.There is a discussion about the meaning of "prima facie" and whether fraud should be assumed by default. It is suggested that the null hypothesis should be the default assumption instead. The author argues that no assumption should be made about the possibility of double-spending being fraudulent or not without any information.Peter Todd expresses disappointment in F2Pool enabling full Replace-by-Fee (RBF) instead of the safer first-seen-safe RBF. He believes that the fees gained by supporting full RBF over FSS RBF would be negligible. He also discusses the differences between standard and zeroconf versions of replace-by-fee patch.Eric Lombrozo warns that relaxing the assumption that the Bitcoin network can withstand deliberate double-spend attacks could result in terrible security practice. He suggests that it's dangerous to assume that security measures are safe because they have never been hacked before. Lombrozo argues that miners must still intervene in cases of human misbehavior, even if the signed transaction itself is proof of intention to pay.Chun Wang claims to have performed a successful bitcoin double spend in 2013 without any mining power. Peter Todd replies with information about first-seen-safe replace-by-fee and the differences between standard and zeroconf versions of replace-by-fee patch.Jeff Garzik emphasizes - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_FYI-Mailing-List-Move-Preparations.xml b/static/bitcoin-dev/June_2015/combined_FYI-Mailing-List-Move-Preparations.xml index 2fd1c6527a..2f3c179603 100644 --- a/static/bitcoin-dev/June_2015/combined_FYI-Mailing-List-Move-Preparations.xml +++ b/static/bitcoin-dev/June_2015/combined_FYI-Mailing-List-Move-Preparations.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - FYI - Mailing List Move Preparations - 2023-08-01T13:22:32.118746+00:00 + 2025-10-11T21:37:02.681539+00:00 + python-feedgen Jeff Garzik 2015-06-19 05:28:44+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - FYI - Mailing List Move Preparations - 2023-08-01T13:22:32.118746+00:00 + 2025-10-11T21:37:02.681696+00:00 - The bitcoin-dev mailing list is currently undergoing a transition to a new list server. The decision has been made to not link the old and new lists during this period. Instead, the switchover date will be announced soon, after which all posts to the old list will be rejected with a message directing them to the new list. The switchover is scheduled for Tuesday, June 23rd, 2015, with the exact time to be determined. Before the switchover, archives from the old list will be exported and imported into the new list server. Interested individuals can subscribe to the new list at https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev. Test posts are also encouraged to help test configuration options and address long-standing spam filter-related issues.It is important to note that any posts made to the new list before the final switchover will be wiped from the archives. For those who have opinions or questions about the transition, they can join the discussion in Freenode #bitcoin-dev and speak to Warren Togami, who is leading the transition process.Overall, the bitcoin-dev community has decided on this approach to ensure a smooth transition to the new list server. 2015-06-19T05:28:44+00:00 + The bitcoin-dev mailing list is currently undergoing a transition to a new list server. The decision has been made to not link the old and new lists during this period. Instead, the switchover date will be announced soon, after which all posts to the old list will be rejected with a message directing them to the new list. The switchover is scheduled for Tuesday, June 23rd, 2015, with the exact time to be determined. Before the switchover, archives from the old list will be exported and imported into the new list server. Interested individuals can subscribe to the new list at https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev. Test posts are also encouraged to help test configuration options and address long-standing spam filter-related issues.It is important to note that any posts made to the new list before the final switchover will be wiped from the archives. For those who have opinions or questions about the transition, they can join the discussion in Freenode #bitcoin-dev and speak to Warren Togami, who is leading the transition process.Overall, the bitcoin-dev community has decided on this approach to ensure a smooth transition to the new list server. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Fwd-Block-Size-Increase-Requirements-.xml b/static/bitcoin-dev/June_2015/combined_Fwd-Block-Size-Increase-Requirements-.xml index 3dc1b1d98a..e0cd6d0592 100644 --- a/static/bitcoin-dev/June_2015/combined_Fwd-Block-Size-Increase-Requirements-.xml +++ b/static/bitcoin-dev/June_2015/combined_Fwd-Block-Size-Increase-Requirements-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Block Size Increase Requirements‏ - 2023-08-01T13:02:16.577785+00:00 + 2025-10-11T21:39:18.645124+00:00 + python-feedgen Nathan Cook 2015-06-02 11:43:29+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Fwd: Block Size Increase Requirements‏ - 2023-08-01T13:02:16.578785+00:00 + 2025-10-11T21:39:18.645271+00:00 - The article discusses a concern raised by Mike Hearn in 2015 regarding the potential for a majority of Bitcoin mining hash rate to perform double spend attacks on exchanges. The fear is that these miners could sell their bitcoins for cash, extract the money, and then build a longer chain to retrieve their bitcoins, which would ultimately lead to the failure and abandonment of the Bitcoin experiment.Hearn points out that the basic assumption behind Bitcoin is that only a minority of actors are dishonest, as stated in the white paper. However, it is possible for agents to commit to honesty on a chain they support and dishonesty on a chain they oppose. This means that the majority hashpower doesn't need to be dishonest to stop a change to larger blocks; they can simply refuse to build on blocks that they don't like. On the other hand, the minority would not mine blocks larger than 1MB if they knew those blocks would be orphaned.In summary, if the majority of the mining hash rate can perform double spend attacks, they could undermine the integrity of Bitcoin by selling bitcoins for cash, extracting the money, and building a longer chain to retrieve their bitcoins. This raises concerns about the viability of the Bitcoin experiment, as it relies on the assumption that only a minority of actors are dishonest. 2015-06-02T11:43:29+00:00 + The article discusses a concern raised by Mike Hearn in 2015 regarding the potential for a majority of Bitcoin mining hash rate to perform double spend attacks on exchanges. The fear is that these miners could sell their bitcoins for cash, extract the money, and then build a longer chain to retrieve their bitcoins, which would ultimately lead to the failure and abandonment of the Bitcoin experiment.Hearn points out that the basic assumption behind Bitcoin is that only a minority of actors are dishonest, as stated in the white paper. However, it is possible for agents to commit to honesty on a chain they support and dishonesty on a chain they oppose. This means that the majority hashpower doesn't need to be dishonest to stop a change to larger blocks; they can simply refuse to build on blocks that they don't like. On the other hand, the minority would not mine blocks larger than 1MB if they knew those blocks would be orphaned.In summary, if the majority of the mining hash rate can perform double spend attacks, they could undermine the integrity of Bitcoin by selling bitcoins for cash, extracting the money, and building a longer chain to retrieve their bitcoins. This raises concerns about the viability of the Bitcoin experiment, as it relies on the assumption that only a minority of actors are dishonest. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Fwd-Block-Size-Increase-Requirements.xml b/static/bitcoin-dev/June_2015/combined_Fwd-Block-Size-Increase-Requirements.xml index b71e584670..f96567e2db 100644 --- a/static/bitcoin-dev/June_2015/combined_Fwd-Block-Size-Increase-Requirements.xml +++ b/static/bitcoin-dev/June_2015/combined_Fwd-Block-Size-Increase-Requirements.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Block Size Increase Requirements - 2023-08-01T12:56:58.388674+00:00 + 2025-10-11T21:37:00.557615+00:00 + python-feedgen Pindar Wong 2015-06-01 22:13:58+00:00 @@ -167,13 +168,13 @@ - python-feedgen + 2 Combined summary - Fwd: Block Size Increase Requirements - 2023-08-01T12:56:58.389685+00:00 + 2025-10-11T21:37:00.557837+00:00 - In this email thread, the discussion revolves around the potential consequences of increasing the block size in Bitcoin, particularly for miners in China. One member suggests that Chinese miners could collaborate and build a longer chain for themselves by firing out small coinbase only blocks, while another member sarcastically responds to a previous statement about excluding certain participants from mining. The conversation also delves into the idea that miners do not have an inherent right to mine if they cannot handle the job, specifically in regards to Chinese miners and their internet situation.Another email thread focuses on the block size limit of Bitcoin. One member suggests doing something relatively uncontroversial by increasing the block size limit to something in the 4-8GB range without further increases without a hard fork. They argue that hard forks need to become less scary and that a sequence of uncontroversial hard forks over time is more likely to gain consensus. The author believes that it is unnecessary to commit to future block size increases years into the future and that it is important to react appropriately to changing conditions.In a separate exchange, one member argues that miners are businesses selling a service to Bitcoin users and if they cannot provide the necessary service, then they should not mine. They believe that advancements in technology have caused many miners to come and go since the beginning of Bitcoin. The author agrees with this perspective and suggests that if miners outside of China cannot get the required bandwidth through their firewall, then they will have to carry on without them.The email thread also discusses the business aspect of Bitcoin mining. It is emphasized that miners are not charities but rather businesses that sell a service to Bitcoin users. Therefore, if some miners are unable to provide this service anymore, they should not/cannot mine. The author believes that it is just part of the business.Furthermore, the conversation highlights the importance of global connectivity for miners, as good connectivity is essential for receiving blocks at higher latency and reducing the risk of orphans. The cost of good connectivity is borne by people outside of well-connected miner groups, incentivizing miners to prioritize their connection quality. This perspective argues that if miners cannot handle the necessary global connectivity, they should not mine.Another email exchange focuses on the topic of miners in China and their ability to mine. One member suggests that if Chinese miners cannot get the necessary bandwidth through their firewall, they should be outcompeted and forced to stop mining. Another member responds with what they believe is obvious sarcasm to highlight the insensitivity of the previous statement. However, some people misunderstand the sarcasm and the original poster clarifies their intention. A third party expresses agreement with the sentiment but criticizes the idea of dis-incentivizing mining and suggests finding a way to decentralize mining without hurting miners.The discussion also touches upon Nielsen's Law of Internet Bandwidth, which predicts that bandwidth available to high-end users grows by 50% per year. It is stated that this law is not relevant for modeling the connectivity of a peer-to-peer network like Bitcoin. The context highlights the scarcity and cost of uplink bandwidth in China and suggests using Multipath TCP (MPTCP) as a solution to improve bandwidth and connection stability. MPTCP allows multiple interfaces/networks for a single TCP connection, combining different connections to optimize upload and download paths.In the email thread, there is a conversation about determining the maximum block size for Bitcoin. One member suggests starting at a max of 8 or 4GB to ensure predictability and scalability over time. Another member agrees with keeping the block sizes as powers of two to make it easier to count support levels for each level. The final consensus on the maximum block size remains unclear.Another email exchange discusses the proposal for a 20MB block size increase in Bitcoin. One member expresses opposition to this proposal, arguing that such an increase could lead to an unacceptable orphan rate. They suggest a lower limit of 5MB, 8MB, or 10MB instead. The member who proposed the 20MB increase defends their suggestion, stating that their testing showed it to be safe and reasonable. They also express uncertainty about the progress of BIP66.The conversation also includes a discussion on finding common ground regarding the block size limit. One member suggests compromising on a maximum size increase of 8 or 4MB to ensure the safety and stability of the system. They emphasize the importance of reaching a consensus rather than engaging in a head-on confrontation between incompatible software. The author acknowledges that a compromise based on a one-off maximum-size increase may not be ideal but suggests it as a reasonable compromise if certain individuals find a new maximum-size cap acceptable.Overall, the email thread provides insights into the ongoing discussions and debates within the Bitcoin development community regarding the potential consequences of increasing the block size, the role of miners, the need for global connectivity, and the ideal maximum block size for the network.In an email conversation in 2015, Gavin Andresen discussed the potential impact of a 20MB block size on the 2015-06-01T22:13:58+00:00 + In this email thread, the discussion revolves around the potential consequences of increasing the block size in Bitcoin, particularly for miners in China. One member suggests that Chinese miners could collaborate and build a longer chain for themselves by firing out small coinbase only blocks, while another member sarcastically responds to a previous statement about excluding certain participants from mining. The conversation also delves into the idea that miners do not have an inherent right to mine if they cannot handle the job, specifically in regards to Chinese miners and their internet situation.Another email thread focuses on the block size limit of Bitcoin. One member suggests doing something relatively uncontroversial by increasing the block size limit to something in the 4-8GB range without further increases without a hard fork. They argue that hard forks need to become less scary and that a sequence of uncontroversial hard forks over time is more likely to gain consensus. The author believes that it is unnecessary to commit to future block size increases years into the future and that it is important to react appropriately to changing conditions.In a separate exchange, one member argues that miners are businesses selling a service to Bitcoin users and if they cannot provide the necessary service, then they should not mine. They believe that advancements in technology have caused many miners to come and go since the beginning of Bitcoin. The author agrees with this perspective and suggests that if miners outside of China cannot get the required bandwidth through their firewall, then they will have to carry on without them.The email thread also discusses the business aspect of Bitcoin mining. It is emphasized that miners are not charities but rather businesses that sell a service to Bitcoin users. Therefore, if some miners are unable to provide this service anymore, they should not/cannot mine. The author believes that it is just part of the business.Furthermore, the conversation highlights the importance of global connectivity for miners, as good connectivity is essential for receiving blocks at higher latency and reducing the risk of orphans. The cost of good connectivity is borne by people outside of well-connected miner groups, incentivizing miners to prioritize their connection quality. This perspective argues that if miners cannot handle the necessary global connectivity, they should not mine.Another email exchange focuses on the topic of miners in China and their ability to mine. One member suggests that if Chinese miners cannot get the necessary bandwidth through their firewall, they should be outcompeted and forced to stop mining. Another member responds with what they believe is obvious sarcasm to highlight the insensitivity of the previous statement. However, some people misunderstand the sarcasm and the original poster clarifies their intention. A third party expresses agreement with the sentiment but criticizes the idea of dis-incentivizing mining and suggests finding a way to decentralize mining without hurting miners.The discussion also touches upon Nielsen's Law of Internet Bandwidth, which predicts that bandwidth available to high-end users grows by 50% per year. It is stated that this law is not relevant for modeling the connectivity of a peer-to-peer network like Bitcoin. The context highlights the scarcity and cost of uplink bandwidth in China and suggests using Multipath TCP (MPTCP) as a solution to improve bandwidth and connection stability. MPTCP allows multiple interfaces/networks for a single TCP connection, combining different connections to optimize upload and download paths.In the email thread, there is a conversation about determining the maximum block size for Bitcoin. One member suggests starting at a max of 8 or 4GB to ensure predictability and scalability over time. Another member agrees with keeping the block sizes as powers of two to make it easier to count support levels for each level. The final consensus on the maximum block size remains unclear.Another email exchange discusses the proposal for a 20MB block size increase in Bitcoin. One member expresses opposition to this proposal, arguing that such an increase could lead to an unacceptable orphan rate. They suggest a lower limit of 5MB, 8MB, or 10MB instead. The member who proposed the 20MB increase defends their suggestion, stating that their testing showed it to be safe and reasonable. They also express uncertainty about the progress of BIP66.The conversation also includes a discussion on finding common ground regarding the block size limit. One member suggests compromising on a maximum size increase of 8 or 4MB to ensure the safety and stability of the system. They emphasize the importance of reaching a consensus rather than engaging in a head-on confrontation between incompatible software. The author acknowledges that a compromise based on a one-off maximum-size increase may not be ideal but suggests it as a reasonable compromise if certain individuals find a new maximum-size cap acceptable.Overall, the email thread provides insights into the ongoing discussions and debates within the Bitcoin development community regarding the potential consequences of increasing the block size, the role of miners, the need for global connectivity, and the ideal maximum block size for the network.In an email conversation in 2015, Gavin Andresen discussed the potential impact of a 20MB block size on the - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Hard-fork-via-miner-vote.xml b/static/bitcoin-dev/June_2015/combined_Hard-fork-via-miner-vote.xml index b054829953..04b0228193 100644 --- a/static/bitcoin-dev/June_2015/combined_Hard-fork-via-miner-vote.xml +++ b/static/bitcoin-dev/June_2015/combined_Hard-fork-via-miner-vote.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hard fork via miner vote - 2023-08-01T13:27:13.044448+00:00 + 2025-10-11T21:38:57.385422+00:00 + python-feedgen Roy Badami 2015-06-20 20:07:53+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Hard fork via miner vote - 2023-08-01T13:27:13.044448+00:00 + 2025-10-11T21:38:57.385659+00:00 - The discussion revolves around the appropriate supermajority threshold for a hard fork in the Bitcoin network, with a focus on block size. Gavin Andresen proposes a 75% threshold, which the writer sees as problematic because it could lead to competing ecosystems claiming to be 'the real Bitcoin'. Therefore, the writer believes it is necessary to design the hardfork mechanism to prevent such an outcome.Pieter Wuille argues against using a 95% threshold for the hard fork, as it can lead to confusion among non-miner nodes and allow the old chain to keep growing. He suggests using a timestamp switchover or adding a block voting threshold with a 100% threshold to keep humans in the loop.The debate also discusses the challenges of ensuring all nodes upgrade during a hard fork. David Vorick believes it is unreasonable to expect every node to upgrade, while Wuille argues that it is important to consider nodes powering miners that produce blocks. They discuss the need for a mechanism to determine when all nodes have upgraded without risking a fork.Wuille expresses his opinion against using a block version vote as a trigger mechanism for hard forks, suggesting it is a bad idea that can confuse non-miner nodes. He recommends a timestamp switch-over or a block voting threshold with a 100% threshold.Overall, the discussion highlights the importance of determining the appropriate level of consensus required for a hard fork and the challenges of ensuring all nodes upgrade to the new code. Pieter Wuille's suggestions for a timestamp switchover or a block voting threshold with a 100% threshold are presented as potential solutions. 2015-06-20T20:07:53+00:00 + The discussion revolves around the appropriate supermajority threshold for a hard fork in the Bitcoin network, with a focus on block size. Gavin Andresen proposes a 75% threshold, which the writer sees as problematic because it could lead to competing ecosystems claiming to be 'the real Bitcoin'. Therefore, the writer believes it is necessary to design the hardfork mechanism to prevent such an outcome.Pieter Wuille argues against using a 95% threshold for the hard fork, as it can lead to confusion among non-miner nodes and allow the old chain to keep growing. He suggests using a timestamp switchover or adding a block voting threshold with a 100% threshold to keep humans in the loop.The debate also discusses the challenges of ensuring all nodes upgrade during a hard fork. David Vorick believes it is unreasonable to expect every node to upgrade, while Wuille argues that it is important to consider nodes powering miners that produce blocks. They discuss the need for a mechanism to determine when all nodes have upgraded without risking a fork.Wuille expresses his opinion against using a block version vote as a trigger mechanism for hard forks, suggesting it is a bad idea that can confuse non-miner nodes. He recommends a timestamp switch-over or a block voting threshold with a 100% threshold.Overall, the discussion highlights the importance of determining the appropriate level of consensus required for a hard fork and the challenges of ensuring all nodes upgrade to the new code. Pieter Wuille's suggestions for a timestamp switchover or a block voting threshold with a 100% threshold are presented as potential solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Is-SourceForge-still-trustworthy-enough-to-host-this-list-.xml b/static/bitcoin-dev/June_2015/combined_Is-SourceForge-still-trustworthy-enough-to-host-this-list-.xml index 81f9966550..80af9a9e92 100644 --- a/static/bitcoin-dev/June_2015/combined_Is-SourceForge-still-trustworthy-enough-to-host-this-list-.xml +++ b/static/bitcoin-dev/June_2015/combined_Is-SourceForge-still-trustworthy-enough-to-host-this-list-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Is SourceForge still trustworthy enough to host this list? - 2023-08-01T13:10:46.291471+00:00 + 2025-10-11T21:39:03.756011+00:00 + python-feedgen Wladimir J. van der Laan 2015-06-11 09:27:46+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Is SourceForge still trustworthy enough to host this list? - 2023-08-01T13:10:46.291471+00:00 + 2025-10-11T21:39:03.756187+00:00 - Recently, the Bitcoin Core community has been discussing the need to change their e-mail list provider. However, finding a suitable free solution has proven to be difficult. One suggestion that has been proposed is implementing a pay-per-message or pay-per-byte system, where the sender would be responsible for payment. This could potentially encourage people to be more concise in their messages and reduce spam.In response to this discussion, Wladimir J. van der Laan mentions that all downloads from SourceForge, including old versions, have been removed due to security concerns. It is worth noting that Bitcoin Core release announcements have not mentioned SourceForge for some time. Despite this, there is no clear consensus on whether or not to move the mailing list elsewhere.It is important for users to exercise caution when downloading software, especially from SourceForge. In the past, the developers of GIMP had to remove their Windows downloads from SourceForge due to misleading advertisements disguised as download buttons. Unfortunately, in 2015, SourceForge took control over the old GIMP account on their platform, locked out the original maintainer, and added junkware-filled installers to GIMP downloads. This serves as a warning to always be vigilant when downloading software from websites and to carefully read before clicking any download buttons.In conclusion, the Bitcoin Core community is considering a change in their e-mail list provider but faces challenges in finding a free solution. Additionally, all downloads from SourceForge have been removed due to security concerns. It is advisable to avoid downloading software from SourceForge and to exercise caution when downloading from other websites to avoid potential issues with misleading advertisements and junkware-filled installers. 2015-06-11T09:27:46+00:00 + Recently, the Bitcoin Core community has been discussing the need to change their e-mail list provider. However, finding a suitable free solution has proven to be difficult. One suggestion that has been proposed is implementing a pay-per-message or pay-per-byte system, where the sender would be responsible for payment. This could potentially encourage people to be more concise in their messages and reduce spam.In response to this discussion, Wladimir J. van der Laan mentions that all downloads from SourceForge, including old versions, have been removed due to security concerns. It is worth noting that Bitcoin Core release announcements have not mentioned SourceForge for some time. Despite this, there is no clear consensus on whether or not to move the mailing list elsewhere.It is important for users to exercise caution when downloading software, especially from SourceForge. In the past, the developers of GIMP had to remove their Windows downloads from SourceForge due to misleading advertisements disguised as download buttons. Unfortunately, in 2015, SourceForge took control over the old GIMP account on their platform, locked out the original maintainer, and added junkware-filled installers to GIMP downloads. This serves as a warning to always be vigilant when downloading software from websites and to carefully read before clicking any download buttons.In conclusion, the Bitcoin Core community is considering a change in their e-mail list provider but faces challenges in finding a free solution. Additionally, all downloads from SourceForge have been removed due to security concerns. It is advisable to avoid downloading software from SourceForge and to exercise caution when downloading from other websites to avoid potential issues with misleading advertisements and junkware-filled installers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Just-FYI.xml b/static/bitcoin-dev/June_2015/combined_Just-FYI.xml index 66daa0ef54..d5d7f85b74 100644 --- a/static/bitcoin-dev/June_2015/combined_Just-FYI.xml +++ b/static/bitcoin-dev/June_2015/combined_Just-FYI.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Just FYI - 2023-08-01T13:30:33.777163+00:00 + 2025-10-11T21:37:11.172189+00:00 + python-feedgen Frank Flores 2015-06-22 08:45:13+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Just FYI - 2023-08-01T13:30:33.777163+00:00 + 2025-10-11T21:37:11.172329+00:00 - The email exchange on the bitcoin-dev mailing list discusses the importance of publishing public keys and the need to republish any alterations made to them. It is emphasized that while the public key is necessary for verifying signed messages, the private key should never be published. The conversation includes a GnuPG command for sending a key to a keyserver.Venzen seeks clarification on whether a key needs to be republished after it has been signed, as well as whether the key used for signing it needs to be published for signature verification. He directs his questions to Peter Todd, who had previously given advice on publishing keys. Although Venzen's query is not specific to GnuPG, he notes that his request would benefit those on the GnuPG support list. The message is accompanied by a PGP signature, indicating its authenticity.Another email in the thread, sent by Frank Flores, requests that individuals who sign their public emails should publish their public key on a major key server or a platform accessible to Google's crawlers. Flores provides instructions on how to do this using stock gnupg and adds a disclaimer acknowledging that OpenPGP is not flawless.The sender of this email emphasizes the importance of publishing public keys if someone chooses to sign their public emails. They suggest making the key available on a major key server or a location accessible to Google's crawlers. The email concludes with a bold statement declaring "MONEY IS OVER!" and features a quote from musician Serj Tankian about the tyranny of money. 2015-06-22T08:45:13+00:00 + The email exchange on the bitcoin-dev mailing list discusses the importance of publishing public keys and the need to republish any alterations made to them. It is emphasized that while the public key is necessary for verifying signed messages, the private key should never be published. The conversation includes a GnuPG command for sending a key to a keyserver.Venzen seeks clarification on whether a key needs to be republished after it has been signed, as well as whether the key used for signing it needs to be published for signature verification. He directs his questions to Peter Todd, who had previously given advice on publishing keys. Although Venzen's query is not specific to GnuPG, he notes that his request would benefit those on the GnuPG support list. The message is accompanied by a PGP signature, indicating its authenticity.Another email in the thread, sent by Frank Flores, requests that individuals who sign their public emails should publish their public key on a major key server or a platform accessible to Google's crawlers. Flores provides instructions on how to do this using stock gnupg and adds a disclaimer acknowledging that OpenPGP is not flawless.The sender of this email emphasizes the importance of publishing public keys if someone chooses to sign their public emails. They suggest making the key available on a major key server or a location accessible to Google's crawlers. The email concludes with a bold statement declaring "MONEY IS OVER!" and features a quote from musician Serj Tankian about the tyranny of money. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Lexicographical-Indexing-of-Transaction-Inputs-and-Outputs.xml b/static/bitcoin-dev/June_2015/combined_Lexicographical-Indexing-of-Transaction-Inputs-and-Outputs.xml index c2366bb01c..2b1b4bc2bc 100644 --- a/static/bitcoin-dev/June_2015/combined_Lexicographical-Indexing-of-Transaction-Inputs-and-Outputs.xml +++ b/static/bitcoin-dev/June_2015/combined_Lexicographical-Indexing-of-Transaction-Inputs-and-Outputs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Lexicographical Indexing of Transaction Inputs and Outputs - 2023-08-01T13:03:29.878353+00:00 + 2025-10-11T21:39:01.633125+00:00 + python-feedgen Rusty Russell 2015-06-15 21:42:14+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Lexicographical Indexing of Transaction Inputs and Outputs - 2023-08-01T13:03:29.879350+00:00 + 2025-10-11T21:39:01.633286+00:00 - Kristov Atlas has written a draft of a BIP to standardize the sorting of transaction inputs and outputs for privacy and security reasons. He has received feedback from colleagues privately but is now looking for feedback from a wider audience before assigning a BIP number and having it accepted into https://github.com/bitcoin/bips. Rusty Russell has modified his implementation to match Kristov's proposal, which can be found at https://github.com/rustyrussell/bitcoin/tree/bip-69. BIP 79 has been implemented in the latest release of Electrum, version 2.3.2. Kristov Atlas made a pull request to add this as an informational BIP 79 to the bips directory. The purpose of BIP 79 is to establish a deterministic order for transaction input and output values so that transactions can be more easily verified by nodes. It applies to all transactions where the order of inputs and outputs does not matter and SIGHASH_ALL is used. In the case where SIGHASH_ANYONECANPAY or SIGHASH_NONE has been used, compliant software should still emit transactions with sorted inputs and outputs, even though they may later be modified by others. Future protocol upgrades introducing new signature hash types should apply the lexicographic ordering principle analogously. In 2015, Kristov Atlas made a pull request to add an informational BIP 79 to the bips directory. Peter Todd suggested that the use-case of SIGHASH_SINGLE was highly specialized and that it would be better to stick to the use-cases where the need is clear and there exist running code. Todd advised presenting the BIP in terms of a generic statement with a focus on the fact that the spirit of what the BIP is about is applicable, and future standards should be developed. Todd also recommended removing the "handling input/output deps" section. As for the actual ordering algorithm, Todd suggested sorting txids as little-endian byte arrays and outputs by largest/smallest amount first. Additionally, he stated that amounts are 8 bytes, while P2PKH scriptPubKeys are 25 bytes.Kristov Atlas has made requested changes to the BIP and sample code in response to Peter Todd's feedback. The discussion between the two revolved around the applicability of SIGHASH_SINGLE, with Todd suggesting that it is better to present the BIP in terms of a generic statement, while Atlas updated the language accordingly. Todd also recommended removing the "handling input/output deps" section. Additionally, Todd suggested simplifying the ordering algorithm by sorting txids as little-endian byte arrays using the bytearr_cmp() function, and sorting outputs by output amount instead of P2PKH locking script. He also pointed out an error in the statement about the number of bytes in amounts and P2PKH locking script.In an email exchange between Kristov Atlas and Peter Todd on June 8, 2015, they discussed the applicability of a BIP (Bitcoin Improvement Proposal) that covers all transactions where the order of inputs and outputs do not matter. They agreed to simplify the language in the proposal to state that such use cases are out of scope for the BIP since there are numerous possible scenarios that cannot be predicted. The BIP applies to transactions where SIGHASH_ALL is used, with the exact input and output order committed to by signatures. In the case of SIGHASH_ANYONECANPAY or SIGHASH_NONE, compliant software should still emit sorted inputs and outputs, although these may later be modified by others. If new signature hash types are introduced in the future, the lexicographic ordering principle should be applied analogously. Protocols requiring a specified input/output order should consider adapting the goals of this BIP to their specific needs.Regarding a patch implementing deterministic transaction ordering for Bitcoin Core, Todd offered to take care of it since he is a frequent code committer, but if no one else does, Atlas will do it. Todd also suggested changes to the actual ordering algorithm, recommending that txids be sorted as little-endian byte arrays instead of with the hex-based algorithm and that scriptPubkeys be used instead of locking scripts.In this context, the author Kristov has removed a certain part of the discussion regarding IsStandard() rules and soft forks. The latest version of the discussion can be found on the provided link to the GitHub repository where the BIP-LI01 document is located. It is suggested to leave the discussion on these topics out for now.In this email thread, Peter Todd provides feedback on a Bitcoin Improvement Proposal (BIP) related to transaction ordering. He questions the mention of SIGHASH_SINGLE and suggests focusing on generic statements rather than speculating too much on future uses. He recommends presenting the BIP in terms of a generic statement that specifies two common cases in detail. The updated language is provided for the BIP. Todd advises leaving out discussions on IsStandard() rules and soft 2015-06-15T21:42:14+00:00 + Kristov Atlas has written a draft of a BIP to standardize the sorting of transaction inputs and outputs for privacy and security reasons. He has received feedback from colleagues privately but is now looking for feedback from a wider audience before assigning a BIP number and having it accepted into https://github.com/bitcoin/bips. Rusty Russell has modified his implementation to match Kristov's proposal, which can be found at https://github.com/rustyrussell/bitcoin/tree/bip-69. BIP 79 has been implemented in the latest release of Electrum, version 2.3.2. Kristov Atlas made a pull request to add this as an informational BIP 79 to the bips directory. The purpose of BIP 79 is to establish a deterministic order for transaction input and output values so that transactions can be more easily verified by nodes. It applies to all transactions where the order of inputs and outputs does not matter and SIGHASH_ALL is used. In the case where SIGHASH_ANYONECANPAY or SIGHASH_NONE has been used, compliant software should still emit transactions with sorted inputs and outputs, even though they may later be modified by others. Future protocol upgrades introducing new signature hash types should apply the lexicographic ordering principle analogously. In 2015, Kristov Atlas made a pull request to add an informational BIP 79 to the bips directory. Peter Todd suggested that the use-case of SIGHASH_SINGLE was highly specialized and that it would be better to stick to the use-cases where the need is clear and there exist running code. Todd advised presenting the BIP in terms of a generic statement with a focus on the fact that the spirit of what the BIP is about is applicable, and future standards should be developed. Todd also recommended removing the "handling input/output deps" section. As for the actual ordering algorithm, Todd suggested sorting txids as little-endian byte arrays and outputs by largest/smallest amount first. Additionally, he stated that amounts are 8 bytes, while P2PKH scriptPubKeys are 25 bytes.Kristov Atlas has made requested changes to the BIP and sample code in response to Peter Todd's feedback. The discussion between the two revolved around the applicability of SIGHASH_SINGLE, with Todd suggesting that it is better to present the BIP in terms of a generic statement, while Atlas updated the language accordingly. Todd also recommended removing the "handling input/output deps" section. Additionally, Todd suggested simplifying the ordering algorithm by sorting txids as little-endian byte arrays using the bytearr_cmp() function, and sorting outputs by output amount instead of P2PKH locking script. He also pointed out an error in the statement about the number of bytes in amounts and P2PKH locking script.In an email exchange between Kristov Atlas and Peter Todd on June 8, 2015, they discussed the applicability of a BIP (Bitcoin Improvement Proposal) that covers all transactions where the order of inputs and outputs do not matter. They agreed to simplify the language in the proposal to state that such use cases are out of scope for the BIP since there are numerous possible scenarios that cannot be predicted. The BIP applies to transactions where SIGHASH_ALL is used, with the exact input and output order committed to by signatures. In the case of SIGHASH_ANYONECANPAY or SIGHASH_NONE, compliant software should still emit sorted inputs and outputs, although these may later be modified by others. If new signature hash types are introduced in the future, the lexicographic ordering principle should be applied analogously. Protocols requiring a specified input/output order should consider adapting the goals of this BIP to their specific needs.Regarding a patch implementing deterministic transaction ordering for Bitcoin Core, Todd offered to take care of it since he is a frequent code committer, but if no one else does, Atlas will do it. Todd also suggested changes to the actual ordering algorithm, recommending that txids be sorted as little-endian byte arrays instead of with the hex-based algorithm and that scriptPubkeys be used instead of locking scripts.In this context, the author Kristov has removed a certain part of the discussion regarding IsStandard() rules and soft forks. The latest version of the discussion can be found on the provided link to the GitHub repository where the BIP-LI01 document is located. It is suggested to leave the discussion on these topics out for now.In this email thread, Peter Todd provides feedback on a Bitcoin Improvement Proposal (BIP) related to transaction ordering. He questions the mention of SIGHASH_SINGLE and suggests focusing on generic statements rather than speculating too much on future uses. He recommends presenting the BIP in terms of a generic statement that specifies two common cases in detail. The updated language is provided for the BIP. Todd advises leaving out discussions on IsStandard() rules and soft - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Lost-proposals-from-FellowTraveler-Monetas.xml b/static/bitcoin-dev/June_2015/combined_Lost-proposals-from-FellowTraveler-Monetas.xml index 992b744b1d..5b6811473d 100644 --- a/static/bitcoin-dev/June_2015/combined_Lost-proposals-from-FellowTraveler-Monetas.xml +++ b/static/bitcoin-dev/June_2015/combined_Lost-proposals-from-FellowTraveler-Monetas.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Lost proposals from FellowTraveler/Monetas - 2023-08-01T13:20:22.972079+00:00 + 2025-10-11T21:38:21.263819+00:00 + python-feedgen Justus Ranvier 2015-06-16 23:44:45+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Lost proposals from FellowTraveler/Monetas - 2023-08-01T13:20:22.972079+00:00 + 2025-10-11T21:38:21.263991+00:00 - In 2015, Gregory Maxwell raised concerns about the lack of progress on BIP-drafts related to Base58 Serialization for Transaction-Based Color Descriptors and Order-based Smart Property Coloring. Fellow Traveler had been waiting for nine months for updates on these proposals but found no discussion or activity regarding them. Maxwell searched through his email and the mailing list archives but could not find any information. Only two proposals were attached to a post on Sourceforge, while the remaining proposals in the Open-Transactions/rfc and Monetas/rfc repositories were never submitted due to the use of alternative identifiers instead of BIP numbers.A member of the community named Fellow Traveler expressed frustration over the lack of progress on BIP-drafts related to Base58 Serialization for Transaction-Based Color Descriptors and Order-based Smart Property Coloring. These proposals can be found at https://github.com/Open-Transactions/rfc/tree/master/bips. Despite waiting for nine months, there has been no discussion or any information available on these proposals. Fellow Traveler conducted a thorough search of their email and the mailing list archives but found no relevant results. They reached out to others for assistance but received no response. In an attempt to resolve the issue, Fellow Traveler is considering creating separate threads for each proposal, assuming that there may have been a mailing list error. 2015-06-16T23:44:45+00:00 + In 2015, Gregory Maxwell raised concerns about the lack of progress on BIP-drafts related to Base58 Serialization for Transaction-Based Color Descriptors and Order-based Smart Property Coloring. Fellow Traveler had been waiting for nine months for updates on these proposals but found no discussion or activity regarding them. Maxwell searched through his email and the mailing list archives but could not find any information. Only two proposals were attached to a post on Sourceforge, while the remaining proposals in the Open-Transactions/rfc and Monetas/rfc repositories were never submitted due to the use of alternative identifiers instead of BIP numbers.A member of the community named Fellow Traveler expressed frustration over the lack of progress on BIP-drafts related to Base58 Serialization for Transaction-Based Color Descriptors and Order-based Smart Property Coloring. These proposals can be found at https://github.com/Open-Transactions/rfc/tree/master/bips. Despite waiting for nine months, there has been no discussion or any information available on these proposals. Fellow Traveler conducted a thorough search of their email and the mailing list archives but found no relevant results. They reached out to others for assistance but received no response. In an attempt to resolve the issue, Fellow Traveler is considering creating separate threads for each proposal, assuming that there may have been a mailing list error. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Mailing-List-Administrivia-GPG-Archives-Breakage-TODO-mirrors-etc.xml b/static/bitcoin-dev/June_2015/combined_Mailing-List-Administrivia-GPG-Archives-Breakage-TODO-mirrors-etc.xml index 53fff78cb7..c8db54603f 100644 --- a/static/bitcoin-dev/June_2015/combined_Mailing-List-Administrivia-GPG-Archives-Breakage-TODO-mirrors-etc.xml +++ b/static/bitcoin-dev/June_2015/combined_Mailing-List-Administrivia-GPG-Archives-Breakage-TODO-mirrors-etc.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mailing List Administrivia - GPG, Archives, Breakage, TODO, mirrors, etc - 2023-08-01T14:05:44.137694+00:00 + 2025-10-11T21:38:36.129562+00:00 + python-feedgen grarpamp 2015-07-16 05:08:59+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Mailing List Administrivia - GPG, Archives, Breakage, TODO, mirrors, etc - 2023-08-01T14:05:44.137694+00:00 + 2025-10-11T21:38:36.129755+00:00 - The email archive system "mbox" has been causing some emails to become lost in mirrors, as they do not appear in the archives. The attachment link for users of the web "archive" has stripped off the final blank line that was present in the original attachment, potentially leading to detached signatures failing. Warren Togami Jr. has disabled the obscure_addresses option for Mailman as it was ineffective in mitigating spam. However, a test message sent to check if mailman continues to break clearsign GPG signatures for messages containing e-mail addresses showed that the issue still persists. This problem has been reported on both web and mbox archives. An attachment named lost.c will not appear in the mbox archives, resulting in its loss to both mirrors and users who use the mbox archives as their source for local seeding or MUA access.On June 27, 2015, Jeff Garzik wrote an email stating that a minimum modification policy was needed to preserve digital signatures and make mbox archives useful. Another person named Peter agreed with this statement and suggested making the raw archives public for archiving as well. The email included a digital signature attachment from Peter.The bitcoin-dev mailing list has been experiencing issues with its archive, specifically with the "mbox" format. The archives are missing necessary headers for easy use by users' MUA's in their local environment. Attachments that are necessary for the context and archives of all lists are not included, resulting in wasted time attempting to post-process them into usable form. There are at least 15 instances of unescaped '^From ' in the "mbox." A user has requested that the full raw archives be provided in regularly updated [gzip/7z] mbox format to fix these issues. Message footers and subject prefixes are considered corruptive and space-wasting clutter that should be turned off. Gmane has changed the subscription of the previous list to the current list, but there is a gap in their archive at the beginning and last week of the archive. They have requested a link to a single mbox file archive that can be used to restore the list archive in its entirety.The need for a minimum modification policy to preserve digital signatures and make mbox archives more useful is discussed. The "mbox" archives are broken and not verifiable, resulting in valuable content being lost. They are also missing original headers necessary for fully replyable, threadable, sortable, searchable, context-preserving use by users' MUA's in their local environment, and do not include essential attachments. Additionally, there appear to be instances of unescaped '^From' in the "mbox." To address these issues, the full raw archives should be provided in regularly updated [gzip/7z] mbox format. Other mirrors, archives, analysis, journalism, and interfaces are useful, but they require pristine historical sources to seed from. The message footers and subject prefix should also be turned off as they are corruptive and space-wasting clutter.The members of the Bitcoin development community have expressed concern over the corrupt archives of the mailing list they use to communicate. They are requesting that the "mbox" format used for archiving be fixed and made available for public use as it is the most efficient way to preserve the list's history. Users have stated that attempting to prevent spam through this method is futile. Some users feel that message footers and subject prefixes should be turned off as they clutter up the email chain. It has been requested that the internet provide regularly updated gzip/7z mbox format archives to resolve these issues. 2015-07-16T05:08:59+00:00 + The email archive system "mbox" has been causing some emails to become lost in mirrors, as they do not appear in the archives. The attachment link for users of the web "archive" has stripped off the final blank line that was present in the original attachment, potentially leading to detached signatures failing. Warren Togami Jr. has disabled the obscure_addresses option for Mailman as it was ineffective in mitigating spam. However, a test message sent to check if mailman continues to break clearsign GPG signatures for messages containing e-mail addresses showed that the issue still persists. This problem has been reported on both web and mbox archives. An attachment named lost.c will not appear in the mbox archives, resulting in its loss to both mirrors and users who use the mbox archives as their source for local seeding or MUA access.On June 27, 2015, Jeff Garzik wrote an email stating that a minimum modification policy was needed to preserve digital signatures and make mbox archives useful. Another person named Peter agreed with this statement and suggested making the raw archives public for archiving as well. The email included a digital signature attachment from Peter.The bitcoin-dev mailing list has been experiencing issues with its archive, specifically with the "mbox" format. The archives are missing necessary headers for easy use by users' MUA's in their local environment. Attachments that are necessary for the context and archives of all lists are not included, resulting in wasted time attempting to post-process them into usable form. There are at least 15 instances of unescaped '^From ' in the "mbox." A user has requested that the full raw archives be provided in regularly updated [gzip/7z] mbox format to fix these issues. Message footers and subject prefixes are considered corruptive and space-wasting clutter that should be turned off. Gmane has changed the subscription of the previous list to the current list, but there is a gap in their archive at the beginning and last week of the archive. They have requested a link to a single mbox file archive that can be used to restore the list archive in its entirety.The need for a minimum modification policy to preserve digital signatures and make mbox archives more useful is discussed. The "mbox" archives are broken and not verifiable, resulting in valuable content being lost. They are also missing original headers necessary for fully replyable, threadable, sortable, searchable, context-preserving use by users' MUA's in their local environment, and do not include essential attachments. Additionally, there appear to be instances of unescaped '^From' in the "mbox." To address these issues, the full raw archives should be provided in regularly updated [gzip/7z] mbox format. Other mirrors, archives, analysis, journalism, and interfaces are useful, but they require pristine historical sources to seed from. The message footers and subject prefix should also be turned off as they are corruptive and space-wasting clutter.The members of the Bitcoin development community have expressed concern over the corrupt archives of the mailing list they use to communicate. They are requesting that the "mbox" format used for archiving be fixed and made available for public use as it is the most efficient way to preserve the list's history. Users have stated that attempting to prevent spam through this method is futile. Some users feel that message footers and subject prefixes should be turned off as they clutter up the email chain. It has been requested that the internet provide regularly updated gzip/7z mbox format archives to resolve these issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Mailman-incompatibility-with-DKIM-.xml b/static/bitcoin-dev/June_2015/combined_Mailman-incompatibility-with-DKIM-.xml index 8373b1c7c4..1987d4144b 100644 --- a/static/bitcoin-dev/June_2015/combined_Mailman-incompatibility-with-DKIM-.xml +++ b/static/bitcoin-dev/June_2015/combined_Mailman-incompatibility-with-DKIM-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mailman incompatibility with DKIM ... - 2023-08-01T13:23:32.770140+00:00 + 2025-10-11T21:39:22.890285+00:00 + python-feedgen Adam Weiss 2015-06-20 18:43:31+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Mailman incompatibility with DKIM ... - 2023-08-01T13:23:32.771197+00:00 + 2025-10-11T21:39:22.890475+00:00 - In an email exchange between Adam Weiss and Jeff Garzik in June 2015, they discussed a feature that would rewrite the envelope-from address to the list's address when someone posts from a domain with strict signature checking. This behavior is not well-specified in RFC822 and is considered an edge case. However, with the adoption of strict DMARC, rewriting envelopes has become more common. If this feature proves problematic, it could be switched to follow the lkml route. Jeff Garzik expressed concern that this change may accidentally direct mail intended for DKIM-user + list to DKIM-user.Adam Weiss suggested a way to detect when someone posts from a domain with strict signature checking by setting dmarc_moderation_action to "Munge from." This would rewrite the envelope-from to the list's address and add a Reply-to field set to the original sender. However, Jeff Garzik raised concerns about changing reply behavior for some recipients and potentially directing mail intended for DKIM-user + list to DKIM-user.Warren Togami Jr and Adam also discussed the issue of DKIM signature checking for all mails originating from a domain. They considered setting dmarc_moderation_action to "Munge from" as a workaround until the issue matures further. Warren expressed displeasure with the need to remove the subject tag and footer for compatibility with DKIM users. He asked if mailing list software resigns for messages themselves, to which Mike Hearn explained that lists can do so, but Mailman does not. DKIM is used by most mail on the internet, and DMARC rules are enforced by major webmail providers like Gmail. Rusty geek infrastructure has problems with this, while the majority of email users benefit from it. Warren understood the reason to protect heavily phished domains but noted that LKML does not modify the subject or add a footer.Mailman, a popular mailing list management software, currently does not sign emails with DKIM. However, DKIM signing is highly recommended to help spam filters identify the 'owner' of the mail. Mailing lists that edit people's emails do resign, but Mailman does not. Removing subject tags and footers may be acceptable if there is no other choice, as email clients can still extract information from the headers. Gmail is capable of using these headers programmatically.Mike Hearn expressed his displeasure with the need to remove subject tags and footers for compatibility with DKIM users. He also noted that lists can effectively perform MITM attacks on messages if they resign for the messages themselves. DKIM is enforced using DMARC rules published in DNS statements. Major webmail providers enforce these rules, but some infrastructure has issues. LKML does not modify the subject or add a footer, likely to maintain compatibility with big corporate domains participating in DKIM. It is acceptable to remove subject tags and footers if there is no other choice.The discussion revolves around removing footers during testing of a new mailing list for compatibility with DKIM users. DKIM/DMARC rules are used by heavily phished domains like Google, PayPal, eBay, and BitPay. The poster suggests everyone should use DKIM/DMARC as it adds cryptographic integrity to email. SourceForge does not drop DKIM enforced mail, but it may get caught in spam filters.Mike Hearn and Warren discuss the issue of compatibility with DKIM signing. They removed the footer due to incompatibility and consider removing the subject tag as well. There is concern about DKIM enforcement being uncommon, and suggestions are made to auto-reject DKIM-enforced domain postings. Spam may have to be silently dropped to avoid Mailman servers becoming spammers.The footer has been removed from the mailing list to be more compatible with DKIM signing. The "[Bitcoin-dev] " prepend tag in the subject is only compatible if manually added by the poster. However, SourceForge still adds footers to the list. The best solution is to use a mailing list operator that operates correctly with DKIM/DMARC and does not modify messages in transit or re-send them under their own identity. The latter approach is risky as it puts the responsibility of spamming on the list operator. To avoid this, it is important to ensure that everyone's mail does not go to the spam folder.Both the sender and recipient of an email experienced their mail being sent to Gmail's spam folder due to DKIM. The sender is concerned about DKIM compatibility with mailing lists. The footer has been removed as it was incompatible with DKIM signing. However, keeping the "[Bitcoin-dev]" prepend tag in the subject is only compatible if manually added by the poster. Removing the subject tag might improve DKIM enforcement but could confuse subscribers. The lack of a Mailman footer may make it difficult for subscribers to unsubscribe or access archives. The sender seeks opinions on how to proceed, and Arthur suggests manually adding "[Bitcoin-dev]" to the beginning of the subject. 2015-06-20T18:43:31+00:00 + In an email exchange between Adam Weiss and Jeff Garzik in June 2015, they discussed a feature that would rewrite the envelope-from address to the list's address when someone posts from a domain with strict signature checking. This behavior is not well-specified in RFC822 and is considered an edge case. However, with the adoption of strict DMARC, rewriting envelopes has become more common. If this feature proves problematic, it could be switched to follow the lkml route. Jeff Garzik expressed concern that this change may accidentally direct mail intended for DKIM-user + list to DKIM-user.Adam Weiss suggested a way to detect when someone posts from a domain with strict signature checking by setting dmarc_moderation_action to "Munge from." This would rewrite the envelope-from to the list's address and add a Reply-to field set to the original sender. However, Jeff Garzik raised concerns about changing reply behavior for some recipients and potentially directing mail intended for DKIM-user + list to DKIM-user.Warren Togami Jr and Adam also discussed the issue of DKIM signature checking for all mails originating from a domain. They considered setting dmarc_moderation_action to "Munge from" as a workaround until the issue matures further. Warren expressed displeasure with the need to remove the subject tag and footer for compatibility with DKIM users. He asked if mailing list software resigns for messages themselves, to which Mike Hearn explained that lists can do so, but Mailman does not. DKIM is used by most mail on the internet, and DMARC rules are enforced by major webmail providers like Gmail. Rusty geek infrastructure has problems with this, while the majority of email users benefit from it. Warren understood the reason to protect heavily phished domains but noted that LKML does not modify the subject or add a footer.Mailman, a popular mailing list management software, currently does not sign emails with DKIM. However, DKIM signing is highly recommended to help spam filters identify the 'owner' of the mail. Mailing lists that edit people's emails do resign, but Mailman does not. Removing subject tags and footers may be acceptable if there is no other choice, as email clients can still extract information from the headers. Gmail is capable of using these headers programmatically.Mike Hearn expressed his displeasure with the need to remove subject tags and footers for compatibility with DKIM users. He also noted that lists can effectively perform MITM attacks on messages if they resign for the messages themselves. DKIM is enforced using DMARC rules published in DNS statements. Major webmail providers enforce these rules, but some infrastructure has issues. LKML does not modify the subject or add a footer, likely to maintain compatibility with big corporate domains participating in DKIM. It is acceptable to remove subject tags and footers if there is no other choice.The discussion revolves around removing footers during testing of a new mailing list for compatibility with DKIM users. DKIM/DMARC rules are used by heavily phished domains like Google, PayPal, eBay, and BitPay. The poster suggests everyone should use DKIM/DMARC as it adds cryptographic integrity to email. SourceForge does not drop DKIM enforced mail, but it may get caught in spam filters.Mike Hearn and Warren discuss the issue of compatibility with DKIM signing. They removed the footer due to incompatibility and consider removing the subject tag as well. There is concern about DKIM enforcement being uncommon, and suggestions are made to auto-reject DKIM-enforced domain postings. Spam may have to be silently dropped to avoid Mailman servers becoming spammers.The footer has been removed from the mailing list to be more compatible with DKIM signing. The "[Bitcoin-dev] " prepend tag in the subject is only compatible if manually added by the poster. However, SourceForge still adds footers to the list. The best solution is to use a mailing list operator that operates correctly with DKIM/DMARC and does not modify messages in transit or re-send them under their own identity. The latter approach is risky as it puts the responsibility of spamming on the list operator. To avoid this, it is important to ensure that everyone's mail does not go to the spam folder.Both the sender and recipient of an email experienced their mail being sent to Gmail's spam folder due to DKIM. The sender is concerned about DKIM compatibility with mailing lists. The footer has been removed as it was incompatible with DKIM signing. However, keeping the "[Bitcoin-dev]" prepend tag in the subject is only compatible if manually added by the poster. Removing the subject tag might improve DKIM enforcement but could confuse subscribers. The lack of a Mailman footer may make it difficult for subscribers to unsubscribe or access archives. The sender seeks opinions on how to proceed, and Arthur suggests manually adding "[Bitcoin-dev]" to the beginning of the subject. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Max-Block-Size-Simple-Voting-Procedure.xml b/static/bitcoin-dev/June_2015/combined_Max-Block-Size-Simple-Voting-Procedure.xml index d7f0ad4410..06a31d63bc 100644 --- a/static/bitcoin-dev/June_2015/combined_Max-Block-Size-Simple-Voting-Procedure.xml +++ b/static/bitcoin-dev/June_2015/combined_Max-Block-Size-Simple-Voting-Procedure.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Max Block Size: Simple Voting Procedure - 2023-08-01T12:59:08.483186+00:00 + 2025-10-11T21:38:46.759802+00:00 + python-feedgen Pindar Wong 2015-06-03 04:18:22+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Max Block Size: Simple Voting Procedure - 2023-08-01T12:59:08.483186+00:00 + 2025-10-11T21:38:46.759977+00:00 - The email exchange between Stephen Morse and Pindar Wong discusses the idea of separating hard/soft fork upgrades in Bitcoin. Wong believes that involving mining pools in decisions can be interesting, but Morse acknowledges concerns about giving miners too much power. Vincent proposes changes to the voting system for miners, suggesting that votes need to be 100% instead of 50.01% to give small miners a fair chance. He also suggests that users who make transactions should have a vote, and fee incentives should attract legitimate votes from miners. However, Stephen points out technical infeasibilities with voting through wallets. The discussion also mentions the possibility of using a token in the coinbase input script to indicate support for larger blocks, but there are concerns about centralization and risks associated with miners wanting larger blocks than the rest of the network can handle. The proposal suggests a voting procedure to increase the block size limit, using an output in the coinbase transaction to vote for or against the increase. Not voting is equivalent to voting against the increase. If more than 1008 blocks out of a 2016 block round vote to increase the block size limit, then the maximum block size increases by 500 kb. The proposal aims to create a non-gameable voting system without artificially bloating blocks or excluding transactions. 2015-06-03T04:18:22+00:00 + The email exchange between Stephen Morse and Pindar Wong discusses the idea of separating hard/soft fork upgrades in Bitcoin. Wong believes that involving mining pools in decisions can be interesting, but Morse acknowledges concerns about giving miners too much power. Vincent proposes changes to the voting system for miners, suggesting that votes need to be 100% instead of 50.01% to give small miners a fair chance. He also suggests that users who make transactions should have a vote, and fee incentives should attract legitimate votes from miners. However, Stephen points out technical infeasibilities with voting through wallets. The discussion also mentions the possibility of using a token in the coinbase input script to indicate support for larger blocks, but there are concerns about centralization and risks associated with miners wanting larger blocks than the rest of the network can handle. The proposal suggests a voting procedure to increase the block size limit, using an output in the coinbase transaction to vote for or against the increase. Not voting is equivalent to voting against the increase. If more than 1008 blocks out of a 2016 block round vote to increase the block size limit, then the maximum block size increases by 500 kb. The proposal aims to create a non-gameable voting system without artificially bloating blocks or excluding transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Membership-disabled-due-to-bounces.xml b/static/bitcoin-dev/June_2015/combined_Membership-disabled-due-to-bounces.xml index b0eaef3635..7ea088003a 100644 --- a/static/bitcoin-dev/June_2015/combined_Membership-disabled-due-to-bounces.xml +++ b/static/bitcoin-dev/June_2015/combined_Membership-disabled-due-to-bounces.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Membership disabled due to bounces - 2023-08-01T13:29:26.547984+00:00 + 2025-10-11T21:37:30.279225+00:00 + python-feedgen Trevin Hofmann 2015-06-21 19:17:37+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Membership disabled due to bounces - 2023-08-01T13:29:26.547984+00:00 + 2025-10-11T21:37:30.279394+00:00 - Several individuals on the Bitcoin-development mailing list, including Braun Brelin and Matt Whitlock, received a message stating that their membership had been disabled due to excessive bounces. Braun expressed confusion as he had only sent one email on the list recently, while Matt also questioned why messages from the list would be bouncing. It is unclear if this issue is related to the recent issues with SourceForge and mail list hosting. The email includes a link to the Bitcoin-development mailing list for further information.Approximately 500 uncaught bounce notifications were received on the Bitcoin-development mailing list, resulting in some members being unsubscribed due to excessive bounces. Matt Whitlock also experienced this issue and had to re-enable his membership. Laszlo Hanyecz raised concerns about something being broken and questioned if it was connected to the SourceForge and mail list hosting problems. Braun Brelin also faced the same problem and asked if others had encountered it too. Warren suggested moving the list as soon as possible but needed both the LF sysadmin and an existing SF list admin to be online simultaneously for an orderly transition, scheduled for Tuesday at 8pm UTC. Opinions on moving the list sooner were requested in #bitcoin-dev.In 2013, a password was set after a debate that inspired the decision to improve Litecoin. The person responsible for fixing up Litecoin expressed gratitude to Gavin. In June 2015, Warren Togami Jr. received an email that caused confusion regarding its potential impact on the bounces in the mailing list. The email contained an HTML attachment, which was scrubbed.The email thread revolves around a discussion about an issue with the Bitcoin development mailing list. Braun Brelin received a message stating that his membership was disabled due to excessive bounces, despite claiming to have only sent one email on the list. Matt Whitlock also encountered the same problem and had to re-enable his membership. They pondered whether the issue was connected to the problems with SourceForge and mail list hosting. The thread concludes with the standard footer of the Bitcoin-development mailing list.One member of a mailing list reported receiving a message indicating that their membership had been disabled due to excessive bounces. The member expressed confusion as they only recall sending one email to the list. They wondered if this issue was related to recent problems with SourceForge and mail list hosting. Another member confirmed receiving the same message and having to re-enable their membership. However, they believed there should be no reason for messages sent by the list to bounce back. No further information was provided regarding the cause of the issue or any steps being taken to resolve it.Braun Brelin shared that his membership in a mailing list was disabled due to excessive bounces. He mentioned having sent only one email on the list, excluding the current one, and asked if anyone else had experienced similar issues. Braun also questioned whether the problem could be associated with SourceForge's mail list hosting issue. The message was posted on a public forum for discussion purposes. 2015-06-21T19:17:37+00:00 + Several individuals on the Bitcoin-development mailing list, including Braun Brelin and Matt Whitlock, received a message stating that their membership had been disabled due to excessive bounces. Braun expressed confusion as he had only sent one email on the list recently, while Matt also questioned why messages from the list would be bouncing. It is unclear if this issue is related to the recent issues with SourceForge and mail list hosting. The email includes a link to the Bitcoin-development mailing list for further information.Approximately 500 uncaught bounce notifications were received on the Bitcoin-development mailing list, resulting in some members being unsubscribed due to excessive bounces. Matt Whitlock also experienced this issue and had to re-enable his membership. Laszlo Hanyecz raised concerns about something being broken and questioned if it was connected to the SourceForge and mail list hosting problems. Braun Brelin also faced the same problem and asked if others had encountered it too. Warren suggested moving the list as soon as possible but needed both the LF sysadmin and an existing SF list admin to be online simultaneously for an orderly transition, scheduled for Tuesday at 8pm UTC. Opinions on moving the list sooner were requested in #bitcoin-dev.In 2013, a password was set after a debate that inspired the decision to improve Litecoin. The person responsible for fixing up Litecoin expressed gratitude to Gavin. In June 2015, Warren Togami Jr. received an email that caused confusion regarding its potential impact on the bounces in the mailing list. The email contained an HTML attachment, which was scrubbed.The email thread revolves around a discussion about an issue with the Bitcoin development mailing list. Braun Brelin received a message stating that his membership was disabled due to excessive bounces, despite claiming to have only sent one email on the list. Matt Whitlock also encountered the same problem and had to re-enable his membership. They pondered whether the issue was connected to the problems with SourceForge and mail list hosting. The thread concludes with the standard footer of the Bitcoin-development mailing list.One member of a mailing list reported receiving a message indicating that their membership had been disabled due to excessive bounces. The member expressed confusion as they only recall sending one email to the list. They wondered if this issue was related to recent problems with SourceForge and mail list hosting. Another member confirmed receiving the same message and having to re-enable their membership. However, they believed there should be no reason for messages sent by the list to bounce back. No further information was provided regarding the cause of the issue or any steps being taken to resolve it.Braun Brelin shared that his membership in a mailing list was disabled due to excessive bounces. He mentioned having sent only one email on the list, excluding the current one, and asked if anyone else had experienced similar issues. Braun also questioned whether the problem could be associated with SourceForge's mail list hosting issue. The message was posted on a public forum for discussion purposes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Mempool-size-consensus-dynamic-block-size-re-targetting.xml b/static/bitcoin-dev/June_2015/combined_Mempool-size-consensus-dynamic-block-size-re-targetting.xml index 4bf9ad037b..88ea955b83 100644 --- a/static/bitcoin-dev/June_2015/combined_Mempool-size-consensus-dynamic-block-size-re-targetting.xml +++ b/static/bitcoin-dev/June_2015/combined_Mempool-size-consensus-dynamic-block-size-re-targetting.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mempool size consensus + dynamic block size re-targetting - 2023-08-01T13:50:11.571651+00:00 + 2025-10-11T21:38:06.384797+00:00 + python-feedgen Filipe Farinha 2015-06-24 03:02:37+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Mempool size consensus + dynamic block size re-targetting - 2023-08-01T13:50:11.571651+00:00 + 2025-10-11T21:38:06.384987+00:00 - In an email exchange on June 24, 2015, Peter Todd and Filipe Farinha discussed the possibility of using mempool consensus to replace proof-of-work. Farinha responded with a clear "no" to Todd's question about whether his mempool consensus idea would work for this purpose. This response is important when considering the pros and cons of BIP 100.Another email exchange on the same day took place between Filipe Farinha and Mark Friedenbach. They discussed the potential for transaction broadcasting full-nodes lying about mempool size. Farinha questioned the incentive for these nodes to lie, and Friedenbach raised the question of whether Farinha's mempool consensus idea could replace proof-of-work. The context also included a non-text attachment of a digital signature from 'peter'[:-1]@petertodd.org.Mark Friedenbach pointed out in a discussion on June 24, 2015, that anyone could lie about the mempool size. The topic of discussion was the incentive for transaction broadcasting full-nodes to engage in such behavior. It was questioned why the majority of these nodes would have a reason to lie. The mempool refers to the collection of valid but unconfirmed transactions maintained by nodes. Full-nodes broadcast the mempool size to estimate network capacity and plan their own transactions. However, there is no apparent benefit for a full-node to lie about the size of its mempool. While a small number of malicious nodes could potentially manipulate the mempool size, it is unlikely that the majority of full-nodes would engage in such behavior as it goes against their own interests. Therefore, while anyone could lie, there seems to be no incentive for the majority of transaction broadcasting full-nodes to lie about the mempool size.On June 23, 2015, Filipe Farinha proposed a solution for determining the appropriate block size limit for Bitcoin in an email sent to the Bitcoin-dev mailing list. He argued that existing proposals, which relied on predictions or a voting mechanism by a limited set of stakeholders, did not consider real-time changes to the mempool. Farinha suggested that each full-node broadcasting a new transaction could include a mempool_size field to represent their current view of the mempool. As blocks are mined with this new data, all nodes can quickly reach consensus on the current average/median/etc mempool size and agree on a suitable periodic blocksize "re-targetting" similar to mining difficulty. This approach would allow all full-nodes, not just miners, to vote with their transactions, resulting in a truly global consensus. Farinha acknowledged that this proposal would introduce some transaction overhead but argued that it would be more effective than blind changes to the blocksize based on unpredictable future scenarios.In summary, the author proposes a new approach to block size changes in the blockchain that considers real-time changes to the mempool. The current main proposals for block size changes rely on predictions or a limited voting mechanism that may not align with the wider community. The proposed solution involves adding a mempool_size field to each full-node broadcasting a new transaction. By mining blocks with this data, all nodes can quickly reach a consensus on the current mempool size and determine a suitable periodic blocksize adjustment. This approach allows all full-nodes, not just miners, to vote with their transactions, resulting in a truly global consensus. The author suggests that this approach would prevent blindly changing the blocksize based on unpredictable future scenarios. 2015-06-24T03:02:37+00:00 + In an email exchange on June 24, 2015, Peter Todd and Filipe Farinha discussed the possibility of using mempool consensus to replace proof-of-work. Farinha responded with a clear "no" to Todd's question about whether his mempool consensus idea would work for this purpose. This response is important when considering the pros and cons of BIP 100.Another email exchange on the same day took place between Filipe Farinha and Mark Friedenbach. They discussed the potential for transaction broadcasting full-nodes lying about mempool size. Farinha questioned the incentive for these nodes to lie, and Friedenbach raised the question of whether Farinha's mempool consensus idea could replace proof-of-work. The context also included a non-text attachment of a digital signature from 'peter'[:-1]@petertodd.org.Mark Friedenbach pointed out in a discussion on June 24, 2015, that anyone could lie about the mempool size. The topic of discussion was the incentive for transaction broadcasting full-nodes to engage in such behavior. It was questioned why the majority of these nodes would have a reason to lie. The mempool refers to the collection of valid but unconfirmed transactions maintained by nodes. Full-nodes broadcast the mempool size to estimate network capacity and plan their own transactions. However, there is no apparent benefit for a full-node to lie about the size of its mempool. While a small number of malicious nodes could potentially manipulate the mempool size, it is unlikely that the majority of full-nodes would engage in such behavior as it goes against their own interests. Therefore, while anyone could lie, there seems to be no incentive for the majority of transaction broadcasting full-nodes to lie about the mempool size.On June 23, 2015, Filipe Farinha proposed a solution for determining the appropriate block size limit for Bitcoin in an email sent to the Bitcoin-dev mailing list. He argued that existing proposals, which relied on predictions or a voting mechanism by a limited set of stakeholders, did not consider real-time changes to the mempool. Farinha suggested that each full-node broadcasting a new transaction could include a mempool_size field to represent their current view of the mempool. As blocks are mined with this new data, all nodes can quickly reach consensus on the current average/median/etc mempool size and agree on a suitable periodic blocksize "re-targetting" similar to mining difficulty. This approach would allow all full-nodes, not just miners, to vote with their transactions, resulting in a truly global consensus. Farinha acknowledged that this proposal would introduce some transaction overhead but argued that it would be more effective than blind changes to the blocksize based on unpredictable future scenarios.In summary, the author proposes a new approach to block size changes in the blockchain that considers real-time changes to the mempool. The current main proposals for block size changes rely on predictions or a limited voting mechanism that may not align with the wider community. The proposed solution involves adding a mempool_size field to each full-node broadcasting a new transaction. By mining blocks with this data, all nodes can quickly reach a consensus on the current mempool size and determine a suitable periodic blocksize adjustment. This approach allows all full-nodes, not just miners, to vote with their transactions, resulting in a truly global consensus. The author suggests that this approach would prevent blindly changing the blocksize based on unpredictable future scenarios. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Meta-suggestions-for-this-block-size-debate.xml b/static/bitcoin-dev/June_2015/combined_Meta-suggestions-for-this-block-size-debate.xml index c0ea74a67a..716b69c04e 100644 --- a/static/bitcoin-dev/June_2015/combined_Meta-suggestions-for-this-block-size-debate.xml +++ b/static/bitcoin-dev/June_2015/combined_Meta-suggestions-for-this-block-size-debate.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Meta suggestions for this block size debate - 2023-08-01T13:00:59.033966+00:00 + 2025-10-11T21:39:20.767325+00:00 + python-feedgen gabe appleton 2015-06-08 00:55:44+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Meta suggestions for this block size debate - 2023-08-01T13:00:59.033966+00:00 + 2025-10-11T21:39:20.767527+00:00 - In an email chain discussing the block size debate in Bitcoin, participants express frustration with the repetitive nature of the discussion and encourage posters to read up on previous arguments and suggest alternatives. They discuss the creation of a wiki page to condense information and avoid rehashing old arguments. Pindar Wong shares a GitHub link for the project, but Gabe Appleton suggests using the original forked version by Ethan Heilman to avoid confusion. Mats Henricson emphasizes the need for posters to be helpful and suggests that they should not just criticize without offering solutions. The group plans to post the project on /r/Bitcoin for more public comments. 2015-06-08T00:55:44+00:00 + In an email chain discussing the block size debate in Bitcoin, participants express frustration with the repetitive nature of the discussion and encourage posters to read up on previous arguments and suggest alternatives. They discuss the creation of a wiki page to condense information and avoid rehashing old arguments. Pindar Wong shares a GitHub link for the project, but Gabe Appleton suggests using the original forked version by Ethan Heilman to avoid confusion. Mats Henricson emphasizes the need for posters to be helpful and suggests that they should not just criticize without offering solutions. The group plans to post the project on /r/Bitcoin for more public comments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Miners-You-ll-very-likely-need-to-upgrade-your-Bitcoin-Core-node-soon-to-support-BIP66.xml b/static/bitcoin-dev/June_2015/combined_Miners-You-ll-very-likely-need-to-upgrade-your-Bitcoin-Core-node-soon-to-support-BIP66.xml index 6c4eca9da3..ac50eb5ef4 100644 --- a/static/bitcoin-dev/June_2015/combined_Miners-You-ll-very-likely-need-to-upgrade-your-Bitcoin-Core-node-soon-to-support-BIP66.xml +++ b/static/bitcoin-dev/June_2015/combined_Miners-You-ll-very-likely-need-to-upgrade-your-Bitcoin-Core-node-soon-to-support-BIP66.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66 - 2023-08-01T13:11:22.840224+00:00 + 2025-10-11T21:37:40.894058+00:00 + python-feedgen Pieter Wuille 2015-06-13 13:01:12+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66 - 2023-08-01T13:11:22.840224+00:00 + 2025-10-11T21:37:40.894214+00:00 - In their email conversation, Tier Nolan and Pieter discuss the importance of updating miners in mining on invalid blocks. Nolan explains that once the 75% threshold is reached, miners who have not updated their systems are at risk of mining on invalid blocks. This occurs when someone produces a version 3 block that violates new rules, and miners who haven't upgraded waste their mining power building on that block. While the risk of this happening is low, creating an invalid version 3 block costs 25BTC in hashing power.The BIP66 soft-fork has recently surpassed the 75% support threshold, indicating that 75% of the hashing power has upgraded to support it while 25% has not. When the hashing power reaches 95%, blocks created by the remaining 5% who have not upgraded will be rejected. It is crucial for those operating a pool, solo-mining, or mining on p2pool to upgrade their Bitcoin Core nodes to support the BIP66 soft-fork; otherwise, their blocks will be rejected. However, individuals who only sell their hashing power to a centralized pool do not need to take any action.To measure BIP66 support, upgraded miners set the version field in their blocks to 3, while non-upgraded miners set it to 2. Bitcoin Core determines BIP66 support by counting the number of blocks with a version greater than or equal to 3 within the last 1000 blocks. If 750 out of the last 1000 blocks support BIP66, blocks with a version greater than or equal to 3 that do not follow the BIP66 rules are rejected. On the other hand, if 950 out of the last 1000 blocks support BIP66, blocks with a version greater than or equal to 3 are accepted. 2015-06-13T13:01:12+00:00 + In their email conversation, Tier Nolan and Pieter discuss the importance of updating miners in mining on invalid blocks. Nolan explains that once the 75% threshold is reached, miners who have not updated their systems are at risk of mining on invalid blocks. This occurs when someone produces a version 3 block that violates new rules, and miners who haven't upgraded waste their mining power building on that block. While the risk of this happening is low, creating an invalid version 3 block costs 25BTC in hashing power.The BIP66 soft-fork has recently surpassed the 75% support threshold, indicating that 75% of the hashing power has upgraded to support it while 25% has not. When the hashing power reaches 95%, blocks created by the remaining 5% who have not upgraded will be rejected. It is crucial for those operating a pool, solo-mining, or mining on p2pool to upgrade their Bitcoin Core nodes to support the BIP66 soft-fork; otherwise, their blocks will be rejected. However, individuals who only sell their hashing power to a centralized pool do not need to take any action.To measure BIP66 support, upgraded miners set the version field in their blocks to 3, while non-upgraded miners set it to 2. Bitcoin Core determines BIP66 support by counting the number of blocks with a version greater than or equal to 3 within the last 1000 blocks. If 750 out of the last 1000 blocks support BIP66, blocks with a version greater than or equal to 3 that do not follow the BIP66 rules are rejected. On the other hand, if 950 out of the last 1000 blocks support BIP66, blocks with a version greater than or equal to 3 are accepted. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Mining-centralization-pressure-from-non-uniform-propagation-speed.xml b/static/bitcoin-dev/June_2015/combined_Mining-centralization-pressure-from-non-uniform-propagation-speed.xml index e848e49da0..167a49d3cb 100644 --- a/static/bitcoin-dev/June_2015/combined_Mining-centralization-pressure-from-non-uniform-propagation-speed.xml +++ b/static/bitcoin-dev/June_2015/combined_Mining-centralization-pressure-from-non-uniform-propagation-speed.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mining centralization pressure from non-uniform propagation speed - 2023-08-01T13:12:02.124288+00:00 + 2025-10-11T21:38:38.264574+00:00 + python-feedgen Mashuri Clark 2015-07-08 19:15:08+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Mining centralization pressure from non-uniform propagation speed - 2023-08-01T13:12:02.124288+00:00 + 2025-10-11T21:38:38.264748+00:00 - The email thread discussed in the context focuses on the effects of block size on centralization pressure in the Bitcoin system. Tom Harding and Pieter Wuille discuss the impact of a per-node imposed max block size limit on orphan rates and reorgs, as well as the connectivity of nodes in countries with unfriendly internet policies. Jonas Nick argues that Pieter's scenario is due to a long-term network partition rather than a cartel.Tom runs a simulation with a large miner in a minority partition and 16 small miners in a majority partition to test the effects of block size and slow link speed. The results show that making small blocks when others are making big ones is detrimental, and being separated by a slow link from majority hash power is also disadvantageous. However, being a small miner with a block size of 20MB is not bad. Yifu Guo signs off the email.Another discussion between Pieter Wuille and Jonas Nick revolves around the centralization pressure caused by larger blocks. Jonas points out that it is unclear whether the pressure to merge with big miners can be separated from the pressure to connect with the majority partition. He runs a simulation with a large miner in a 20% minority partition and 16 small miners in an 80% majority partition, including a slow link speed of 100 Mbit/s. The simulation shows that making small blocks when others are making big ones is unfavorable, and fees become enormous. Being separated by a slow link from the majority hash power is also detrimental. However, being a small miner with a block size of 20MB is not disadvantageous. The simulation uses different configurations to demonstrate the effects of block size and fee per byte on the income of two miner groups with different hash rates.Pieter Wuille has developed a Bitcoin mining simulator that considers various factors such as block sizes, difficulty adjustments, processing and mining delays, and fees. The simulator includes two groups of miners that are well-connected internally but only connected to each other through a slow 2 Mbit/s link. The results indicate that the group with the larger hash rate profits overall, while miners not directly connected to the small group experience losses. When fees become more important, the effect becomes even stronger. The simulator also shows the impact of larger blocks on centralization pressure in the system, without assuming any destructive behavior on the network.A conversation between Peter Todd and Gavin Andresen focuses on the benefits of producing larger blocks and including high-fee transactions. They discuss the relevance of simulations considering Matt's fast relay network and future optimization of block propagation. Peter suggests simulating the relay network at different usage levels to analyze if it is advantageous for miners to sabotage the network. The conversation ends with Peter providing his contact information.Gavin Andresen and Pieter Wuille discuss the simulation of bandwidth for block messages as a bottleneck. Pieter suggests that Matt's fast relay network could make their simulations irrelevant in the long run. Gavin proposes two simulations: one assuming 100% usage of the relay network and another assuming a lower percentage. They also discuss the potential advantage for miners to sabotage the relay network. Despite the relay network, there is still a delay. Peter's contact information and a digital signature file conclude the email exchange.The context also mentions an email from Mike Hearn questioning the slow speed of a 2 Mbit/s link between two connected entities. He compares this to the average speed of a 3G connection and expresses concern about the accuracy of simulation data due to the slow connection speed. However, no further details are provided regarding the effect being discussed.Pieter Wuille shares an email explaining the configuration used in his code that simulates two groups of miners. The code supports different block sizes, takes fees into account, and considers difficulty adjustments, processing and mining delays. It also simulates longer periods of time and averages the results of multiple simulations running in parallel. The configuration involves two well-connected groups of miners that are only connected to each other through a slow 2 Mbit/s link. The simulation demonstrates that smaller miners experience a relative income loss when creating larger blocks, especially when fees become more important.In summary, the email exchanges and simulations discussed in the context explore the effects of block size, connectivity, and fee considerations on centralization pressure in the Bitcoin system. Various scenarios and configurations are simulated to analyze the impact on miner income and profitability. The discussions also touch upon the potential irrelevance of simulations due to advancements in block propagation optimization and the possibility of miners sabotaging the relay network. 2015-07-08T19:15:08+00:00 + The email thread discussed in the context focuses on the effects of block size on centralization pressure in the Bitcoin system. Tom Harding and Pieter Wuille discuss the impact of a per-node imposed max block size limit on orphan rates and reorgs, as well as the connectivity of nodes in countries with unfriendly internet policies. Jonas Nick argues that Pieter's scenario is due to a long-term network partition rather than a cartel.Tom runs a simulation with a large miner in a minority partition and 16 small miners in a majority partition to test the effects of block size and slow link speed. The results show that making small blocks when others are making big ones is detrimental, and being separated by a slow link from majority hash power is also disadvantageous. However, being a small miner with a block size of 20MB is not bad. Yifu Guo signs off the email.Another discussion between Pieter Wuille and Jonas Nick revolves around the centralization pressure caused by larger blocks. Jonas points out that it is unclear whether the pressure to merge with big miners can be separated from the pressure to connect with the majority partition. He runs a simulation with a large miner in a 20% minority partition and 16 small miners in an 80% majority partition, including a slow link speed of 100 Mbit/s. The simulation shows that making small blocks when others are making big ones is unfavorable, and fees become enormous. Being separated by a slow link from the majority hash power is also detrimental. However, being a small miner with a block size of 20MB is not disadvantageous. The simulation uses different configurations to demonstrate the effects of block size and fee per byte on the income of two miner groups with different hash rates.Pieter Wuille has developed a Bitcoin mining simulator that considers various factors such as block sizes, difficulty adjustments, processing and mining delays, and fees. The simulator includes two groups of miners that are well-connected internally but only connected to each other through a slow 2 Mbit/s link. The results indicate that the group with the larger hash rate profits overall, while miners not directly connected to the small group experience losses. When fees become more important, the effect becomes even stronger. The simulator also shows the impact of larger blocks on centralization pressure in the system, without assuming any destructive behavior on the network.A conversation between Peter Todd and Gavin Andresen focuses on the benefits of producing larger blocks and including high-fee transactions. They discuss the relevance of simulations considering Matt's fast relay network and future optimization of block propagation. Peter suggests simulating the relay network at different usage levels to analyze if it is advantageous for miners to sabotage the network. The conversation ends with Peter providing his contact information.Gavin Andresen and Pieter Wuille discuss the simulation of bandwidth for block messages as a bottleneck. Pieter suggests that Matt's fast relay network could make their simulations irrelevant in the long run. Gavin proposes two simulations: one assuming 100% usage of the relay network and another assuming a lower percentage. They also discuss the potential advantage for miners to sabotage the relay network. Despite the relay network, there is still a delay. Peter's contact information and a digital signature file conclude the email exchange.The context also mentions an email from Mike Hearn questioning the slow speed of a 2 Mbit/s link between two connected entities. He compares this to the average speed of a 3G connection and expresses concern about the accuracy of simulation data due to the slow connection speed. However, no further details are provided regarding the effect being discussed.Pieter Wuille shares an email explaining the configuration used in his code that simulates two groups of miners. The code supports different block sizes, takes fees into account, and considers difficulty adjustments, processing and mining delays. It also simulates longer periods of time and averages the results of multiple simulations running in parallel. The configuration involves two well-connected groups of miners that are only connected to each other through a slow 2 Mbit/s link. The simulation demonstrates that smaller miners experience a relative income loss when creating larger blocks, especially when fees become more important.In summary, the email exchanges and simulations discussed in the context explore the effects of block size, connectivity, and fee considerations on centralization pressure in the Bitcoin system. Various scenarios and configurations are simulated to analyze the impact on miner income and profitability. The discussions also touch upon the potential irrelevance of simulations due to advancements in block propagation optimization and the possibility of miners sabotaging the relay network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_New-attack-identified-and-potential-solution-described-Dropped-transaction-spam-attack-against-the-block-size-limit.xml b/static/bitcoin-dev/June_2015/combined_New-attack-identified-and-potential-solution-described-Dropped-transaction-spam-attack-against-the-block-size-limit.xml index e022cee26e..a9f3f4e22a 100644 --- a/static/bitcoin-dev/June_2015/combined_New-attack-identified-and-potential-solution-described-Dropped-transaction-spam-attack-against-the-block-size-limit.xml +++ b/static/bitcoin-dev/June_2015/combined_New-attack-identified-and-potential-solution-described-Dropped-transaction-spam-attack-against-the-block-size-limit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit - 2023-08-01T13:09:37.959632+00:00 + 2025-10-11T21:39:08.001538+00:00 + python-feedgen Peter Todd 2015-06-08 22:28:16+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit - 2023-08-01T13:09:37.959632+00:00 + 2025-10-11T21:39:08.001693+00:00 - In a recent discussion, Bob McElrath highlighted the technology of Hashcash, originally invented to combat spam, and suggested that individual transactions should be mined rather than relaying unmined items. Peter Todd added to this by describing Bitcoin as a system that maintains a ledger for transferrable hashcash, with transaction fees paid in hashcash.The conversation then shifted to the rising costs of Bitcoin transactions. Patrick Mccorry pointed out that with the current relay fee and Bitcoin exchange rate, the cost of ram per gigabyte amounted to $2.3kUSD. In response, Mike Hearn reduced the minimum relay fee, resulting in a fee of $23 per megabyte and $23k per gigabyte. This escalation in expenses raised concerns about the affordability of Bitcoin transactions.Next, the discussion turned towards potential attacks on Bitcoin. While it was acknowledged that filling all blocks with spam transactions would be costly, it was noted that well-funded entities could potentially harm Bitcoin after the implementation of block size limits. Without these limits, spam transactions would not harm Bitcoin but instead benefit miners at the expense of spammers. However, due to technological constraints and network bandwidth limitations, block size limits are necessary. It was also mentioned that flooding the network with transactions would only increase costs and not compromise security, as it would be more cost-effective to execute a 51% attack.Another issue raised during the conversation was the absence of a memory pool cap in the Bitcoin Core. Raystonn expressed concern about this, but Peter Todd explained that transactions can only be removed from the mempool through mining, double-spending, or node restarting. The suggested solution was to cap the mempool size, although this would impact zeroconf security and hinder the propagation of reasonable fee transactions. Thus, finding a fix for this issue is crucial.The implementation of the block size limit in Bitcoin aimed to prevent the use of massive blocks as an attack, which would delay other miners while they downloaded and validated the large block, benefiting the miner responsible. However, this introduced a new vulnerability: network spamming. Prior to the limit, spamming was economically unfeasible since every transaction required a fee. Now, a spam attack can drive up transaction fees by dropping transactions from mempools, undermining Bitcoin's credibility and usability. To address this, a proposed solution suggests burning a portion of every fee, making it unspendable. Additionally, doubling the default fee per transaction would ensure that miners still receive the same fees. With these changes in place, large blocks would come at a significant cost, even if all transactions within the block were created by the miner. Ultimately, removing the block size limit would be possible once a minimum fee is paid for most transactions in each block and the new transaction fee rule is established. 2015-06-08T22:28:16+00:00 + In a recent discussion, Bob McElrath highlighted the technology of Hashcash, originally invented to combat spam, and suggested that individual transactions should be mined rather than relaying unmined items. Peter Todd added to this by describing Bitcoin as a system that maintains a ledger for transferrable hashcash, with transaction fees paid in hashcash.The conversation then shifted to the rising costs of Bitcoin transactions. Patrick Mccorry pointed out that with the current relay fee and Bitcoin exchange rate, the cost of ram per gigabyte amounted to $2.3kUSD. In response, Mike Hearn reduced the minimum relay fee, resulting in a fee of $23 per megabyte and $23k per gigabyte. This escalation in expenses raised concerns about the affordability of Bitcoin transactions.Next, the discussion turned towards potential attacks on Bitcoin. While it was acknowledged that filling all blocks with spam transactions would be costly, it was noted that well-funded entities could potentially harm Bitcoin after the implementation of block size limits. Without these limits, spam transactions would not harm Bitcoin but instead benefit miners at the expense of spammers. However, due to technological constraints and network bandwidth limitations, block size limits are necessary. It was also mentioned that flooding the network with transactions would only increase costs and not compromise security, as it would be more cost-effective to execute a 51% attack.Another issue raised during the conversation was the absence of a memory pool cap in the Bitcoin Core. Raystonn expressed concern about this, but Peter Todd explained that transactions can only be removed from the mempool through mining, double-spending, or node restarting. The suggested solution was to cap the mempool size, although this would impact zeroconf security and hinder the propagation of reasonable fee transactions. Thus, finding a fix for this issue is crucial.The implementation of the block size limit in Bitcoin aimed to prevent the use of massive blocks as an attack, which would delay other miners while they downloaded and validated the large block, benefiting the miner responsible. However, this introduced a new vulnerability: network spamming. Prior to the limit, spamming was economically unfeasible since every transaction required a fee. Now, a spam attack can drive up transaction fees by dropping transactions from mempools, undermining Bitcoin's credibility and usability. To address this, a proposed solution suggests burning a portion of every fee, making it unspendable. Additionally, doubling the default fee per transaction would ensure that miners still receive the same fees. With these changes in place, large blocks would come at a significant cost, even if all transactions within the block were created by the miner. Ultimately, removing the block size limit would be possible once a minimum fee is paid for most transactions in each block and the new transaction fee rule is established. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_New-attack-identified-and-potential-solution-described-Dropped-transaction-spam-attack-against-the-blocksize-limit.xml b/static/bitcoin-dev/June_2015/combined_New-attack-identified-and-potential-solution-described-Dropped-transaction-spam-attack-against-the-blocksize-limit.xml index 6a1c4dfe85..a6f7ea7fd0 100644 --- a/static/bitcoin-dev/June_2015/combined_New-attack-identified-and-potential-solution-described-Dropped-transaction-spam-attack-against-the-blocksize-limit.xml +++ b/static/bitcoin-dev/June_2015/combined_New-attack-identified-and-potential-solution-described-Dropped-transaction-spam-attack-against-the-blocksize-limit.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit - 2023-08-01T13:09:58.147279+00:00 + 2025-10-11T21:39:25.016863+00:00 + python-feedgen Raystonn . 2015-06-08 22:46:59+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit - 2023-08-01T13:09:58.148278+00:00 + 2025-10-11T21:39:25.016999+00:00 - The blocksize limit in Bitcoin is causing concerns, as it can be exploited by spammers to obstruct transaction confirmation. By filling up blocks with high fees, these attackers could perpetuate the attack indefinitely, particularly if the BTCUSD market weakens due to the network's diminished usability. This self-reinforcing assault poses a threat to Bitcoin until a patch is implemented. The blocksize limit is crucial for maintaining consensus and preventing bandwidth overload. Without it, an attacker flooding the network with transactions could render Bitcoin unusable by ensuring that only 1% of genuine transactions are processed. Meanwhile, individuals would flock to mine blocks and collect fees from the spammers, leading to a significant wealth transfer.In a discussion on the block size limit and spam attacks, Peter Todd argues that a finite block size limit is necessary due to the network's limited bandwidth. While bandwidth varies among users, the block size limit applies universally to safeguard against an attacker overwhelming the network and jeopardizing Bitcoin's value and security. However, Raystonn suggests that removing the block size limit would not harm Bitcoin but instead benefit miners at the expense of spammers, fostering an antifragile system. In response, Todd asserts that even without a block size limit, an attacker could still flood the network until bandwidth usage becomes unsustainable, potentially leading to a failure in consensus. With a block size limit in place, the worst an attacker can do is increase costs without compromising security. However, if fees become exorbitant, legitimate users may abandon Bitcoin due to its impracticality. Ultimately, Todd highlights that technological factors dictate the existence of a block size limit.The Bitcoin Core mempool does not discard transactions with insufficient fees unless they are double-spent or the node restarts. This presents a problem, as the only defense against a spam attack is having enough bitcoins to pay the fees. If there were no block size limit, this attack would merely transfer wealth from spammers to miners, a response that strengthens the Bitcoin network. Although there is currently no cap on the mempool size, hardware limitations prevent unlimited growth. One solution could involve capping the mempool size and prioritizing transactions with higher fees per kilobyte, but this would compromise zeroconf security. Without breaking zeroconf security, attackers can impede the propagation of reasonable fee transactions across the network. 2015-06-08T22:46:59+00:00 + The blocksize limit in Bitcoin is causing concerns, as it can be exploited by spammers to obstruct transaction confirmation. By filling up blocks with high fees, these attackers could perpetuate the attack indefinitely, particularly if the BTCUSD market weakens due to the network's diminished usability. This self-reinforcing assault poses a threat to Bitcoin until a patch is implemented. The blocksize limit is crucial for maintaining consensus and preventing bandwidth overload. Without it, an attacker flooding the network with transactions could render Bitcoin unusable by ensuring that only 1% of genuine transactions are processed. Meanwhile, individuals would flock to mine blocks and collect fees from the spammers, leading to a significant wealth transfer.In a discussion on the block size limit and spam attacks, Peter Todd argues that a finite block size limit is necessary due to the network's limited bandwidth. While bandwidth varies among users, the block size limit applies universally to safeguard against an attacker overwhelming the network and jeopardizing Bitcoin's value and security. However, Raystonn suggests that removing the block size limit would not harm Bitcoin but instead benefit miners at the expense of spammers, fostering an antifragile system. In response, Todd asserts that even without a block size limit, an attacker could still flood the network until bandwidth usage becomes unsustainable, potentially leading to a failure in consensus. With a block size limit in place, the worst an attacker can do is increase costs without compromising security. However, if fees become exorbitant, legitimate users may abandon Bitcoin due to its impracticality. Ultimately, Todd highlights that technological factors dictate the existence of a block size limit.The Bitcoin Core mempool does not discard transactions with insufficient fees unless they are double-spent or the node restarts. This presents a problem, as the only defense against a spam attack is having enough bitcoins to pay the fees. If there were no block size limit, this attack would merely transfer wealth from spammers to miners, a response that strengthens the Bitcoin network. Although there is currently no cap on the mempool size, hardware limitations prevent unlimited growth. One solution could involve capping the mempool size and prioritizing transactions with higher fees per kilobyte, but this would compromise zeroconf security. Without breaking zeroconf security, attackers can impede the propagation of reasonable fee transactions across the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Ninki-Wallet-view-on-blocksize-debate.xml b/static/bitcoin-dev/June_2015/combined_Ninki-Wallet-view-on-blocksize-debate.xml index f4aa9065ab..432df00387 100644 --- a/static/bitcoin-dev/June_2015/combined_Ninki-Wallet-view-on-blocksize-debate.xml +++ b/static/bitcoin-dev/June_2015/combined_Ninki-Wallet-view-on-blocksize-debate.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ninki Wallet view on blocksize debate - 2023-08-01T13:22:20.172425+00:00 + 2025-10-11T21:39:16.523637+00:00 + python-feedgen Stephen Morse 2015-06-18 14:53:46+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Ninki Wallet view on blocksize debate - 2023-08-01T13:22:20.172425+00:00 + 2025-10-11T21:39:16.523791+00:00 - The discussion revolves around how wallets calculate transaction fees for miners and whether they adjust automatically when transactions take longer to confirm. The response of wallets when transactions fail, such as when blocks are full, is also being debated. The writer urges Gavin, a key figure in the debate, to withdraw from the current standoff and collaborate with Bitcoin core developers through the existing BIP process.While the proposed solution of convincing miners and services to switch to Bitcoin-XT is acknowledged as urgent, it is not considered ideal due to potential compatibility issues and loss of funds. However, changes in the Bitcoin system take time to roll out, so starting them sooner rather than later is crucial. The central issue at hand is determining which option is riskier: implementing a consensus hard fork or allowing Bitcoin to surpass its capacity limits. Both scenarios pose dangers, including service incompatibility and loss of public confidence on one hand, and software failures, instability, and inability to transact on the other. In light of these risks, two short-term solutions have been proposed.One solution involves all miners and wallet developers upgrading to support first-safe RBF, which allows for double spending when transactions lack sufficient fees for confirmation. The second solution involves implementing either Gavin's or Jeff Garzik's proposal to change the consensus parameters around the block size limit. The writer expresses hope that if the second option is not deemed suitable (despite the consensus on eventually increasing the block size limit), Ben should focus on implementing the first solution for his Ninki Wallet software to handle capacity limits gracefully.Ben, the developer of Ninki Wallet, supports the bitcoin core dev team's approach to consensus and a clear process for change. He believes that the block size limit will need to be increased in the future, but emphasizes the importance of establishing consensus on how bitcoin can scale while maintaining decentralization and its core value. Ben opposes any group attempting to fork the blockchain using XT and strongly urges Gavin to collaborate with the bitcoin core devs through the successful bip process. It is worth mentioning that Ninki Wallet has recently been listed on bitcoin.org, indicating its legitimacy and recognition in the Bitcoin community. 2015-06-18T14:53:46+00:00 + The discussion revolves around how wallets calculate transaction fees for miners and whether they adjust automatically when transactions take longer to confirm. The response of wallets when transactions fail, such as when blocks are full, is also being debated. The writer urges Gavin, a key figure in the debate, to withdraw from the current standoff and collaborate with Bitcoin core developers through the existing BIP process.While the proposed solution of convincing miners and services to switch to Bitcoin-XT is acknowledged as urgent, it is not considered ideal due to potential compatibility issues and loss of funds. However, changes in the Bitcoin system take time to roll out, so starting them sooner rather than later is crucial. The central issue at hand is determining which option is riskier: implementing a consensus hard fork or allowing Bitcoin to surpass its capacity limits. Both scenarios pose dangers, including service incompatibility and loss of public confidence on one hand, and software failures, instability, and inability to transact on the other. In light of these risks, two short-term solutions have been proposed.One solution involves all miners and wallet developers upgrading to support first-safe RBF, which allows for double spending when transactions lack sufficient fees for confirmation. The second solution involves implementing either Gavin's or Jeff Garzik's proposal to change the consensus parameters around the block size limit. The writer expresses hope that if the second option is not deemed suitable (despite the consensus on eventually increasing the block size limit), Ben should focus on implementing the first solution for his Ninki Wallet software to handle capacity limits gracefully.Ben, the developer of Ninki Wallet, supports the bitcoin core dev team's approach to consensus and a clear process for change. He believes that the block size limit will need to be increased in the future, but emphasizes the importance of establishing consensus on how bitcoin can scale while maintaining decentralization and its core value. Ben opposes any group attempting to fork the blockchain using XT and strongly urges Gavin to collaborate with the bitcoin core devs through the successful bip process. It is worth mentioning that Ninki Wallet has recently been listed on bitcoin.org, indicating its legitimacy and recognition in the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Original-Vision.xml b/static/bitcoin-dev/June_2015/combined_Original-Vision.xml index c80b624043..deedde989c 100644 --- a/static/bitcoin-dev/June_2015/combined_Original-Vision.xml +++ b/static/bitcoin-dev/June_2015/combined_Original-Vision.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Original Vision - 2023-08-01T14:07:32.211290+00:00 + 2025-10-11T21:38:23.389226+00:00 + python-feedgen Santino Napolitano 2015-06-28 21:53:23+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Original Vision - 2023-08-01T14:07:32.211290+00:00 + 2025-10-11T21:38:23.389421+00:00 - The debate surrounding Bitcoin extends beyond block size and hard forks, encompassing the essence of Bitcoin and its growth. The original intention of the author was to have organizations operating full network nodes provide connectivity to light clients, which would constitute the majority of users. This aligns with current trends in Internet consumption, favoring tablets and phones over traditional computers. The incentive for running a full network node was to facilitate mining and receive rewards from new coins and transaction fees.However, concerns have arisen regarding the security of Simplified Payment Verification (SPV) clients compared to full nodes. While fraud proofs were deemed feasible, no efficient and secure design has been proposed or implemented. Peering with a trusted node or consulting other nodes could mitigate the security concern that a newly announced block may not reflect a valid block, particularly for important transactions.The article also delves into the complexity and scalability of Unspent Transaction Output (UTXO) and Spent Transaction Output (TXO)/Spent Transaction Output after eXclusion (STXO) trees. The size of the entire blockchain history becomes a factor in the sluggishness of TXO/STXO trees, while UTXO represents only the set of unspent transaction outputs. Various alternatives and optimizations have been suggested, but trade-offs exist between efficiency and scalability.An email exchange explored the usage of UTXO commitments and their potential impact on block validation speed. However, maintaining a hash tree commitment over the validator state is expensive and poses limitations. Another suggestion was an O(1)-append commitment for TXO and STXO, which could offer better scalability but might not be as efficient in certain aspects.Efficiency and security concerns surrounding fraud proofs were further discussed in the email thread. It was acknowledged that the current SPV system is fundamentally flawed, but future protocols may present optimization opportunities. For fraud proofs to be effective, they must be secure and incentivized, potentially through a market. However, no efficient and secure design for fraud proofs has been proposed thus far.The email conversation also touched upon the original author's intent and the decentralized nature of Bitcoin. The intention behind running a full network node was to enable mining, with rewards serving as an incentive to continue operating these nodes. The global decentralized consensus aimed to make the network resilient against adversaries. There is an ongoing debate regarding the level of trust within the system, with some arguing for localized trust as a necessary trade-off. The objective is to comprehend the original author's intentions and anticipate how Bitcoin will evolve.Overall, these discussions underscore the need for efficient and secure fraud proofs, the scalability of different tree structures, the incentives for running full network nodes, and the nature of Bitcoin's growth and decentralization. By revisiting the original author's goals and scaling plans, the Bitcoin community can collectively address the challenges of scalability and decentralization while staying true to the system's initial vision. 2015-06-28T21:53:23+00:00 + The debate surrounding Bitcoin extends beyond block size and hard forks, encompassing the essence of Bitcoin and its growth. The original intention of the author was to have organizations operating full network nodes provide connectivity to light clients, which would constitute the majority of users. This aligns with current trends in Internet consumption, favoring tablets and phones over traditional computers. The incentive for running a full network node was to facilitate mining and receive rewards from new coins and transaction fees.However, concerns have arisen regarding the security of Simplified Payment Verification (SPV) clients compared to full nodes. While fraud proofs were deemed feasible, no efficient and secure design has been proposed or implemented. Peering with a trusted node or consulting other nodes could mitigate the security concern that a newly announced block may not reflect a valid block, particularly for important transactions.The article also delves into the complexity and scalability of Unspent Transaction Output (UTXO) and Spent Transaction Output (TXO)/Spent Transaction Output after eXclusion (STXO) trees. The size of the entire blockchain history becomes a factor in the sluggishness of TXO/STXO trees, while UTXO represents only the set of unspent transaction outputs. Various alternatives and optimizations have been suggested, but trade-offs exist between efficiency and scalability.An email exchange explored the usage of UTXO commitments and their potential impact on block validation speed. However, maintaining a hash tree commitment over the validator state is expensive and poses limitations. Another suggestion was an O(1)-append commitment for TXO and STXO, which could offer better scalability but might not be as efficient in certain aspects.Efficiency and security concerns surrounding fraud proofs were further discussed in the email thread. It was acknowledged that the current SPV system is fundamentally flawed, but future protocols may present optimization opportunities. For fraud proofs to be effective, they must be secure and incentivized, potentially through a market. However, no efficient and secure design for fraud proofs has been proposed thus far.The email conversation also touched upon the original author's intent and the decentralized nature of Bitcoin. The intention behind running a full network node was to enable mining, with rewards serving as an incentive to continue operating these nodes. The global decentralized consensus aimed to make the network resilient against adversaries. There is an ongoing debate regarding the level of trust within the system, with some arguing for localized trust as a necessary trade-off. The objective is to comprehend the original author's intentions and anticipate how Bitcoin will evolve.Overall, these discussions underscore the need for efficient and secure fraud proofs, the scalability of different tree structures, the incentives for running full network nodes, and the nature of Bitcoin's growth and decentralization. By revisiting the original author's goals and scaling plans, the Bitcoin community can collectively address the challenges of scalability and decentralization while staying true to the system's initial vision. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Outroduction-of-old-non-updated-full-nodes-through-graceful-degradation-to-SPV-mode.xml b/static/bitcoin-dev/June_2015/combined_Outroduction-of-old-non-updated-full-nodes-through-graceful-degradation-to-SPV-mode.xml index a61052379c..6626e9eaf1 100644 --- a/static/bitcoin-dev/June_2015/combined_Outroduction-of-old-non-updated-full-nodes-through-graceful-degradation-to-SPV-mode.xml +++ b/static/bitcoin-dev/June_2015/combined_Outroduction-of-old-non-updated-full-nodes-through-graceful-degradation-to-SPV-mode.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Outroduction of old non-updated full nodes through graceful degradation to SPV mode - 2023-08-01T14:06:32.571261+00:00 + 2025-10-11T21:38:08.507142+00:00 + python-feedgen Jeff Garzik 2015-06-27 23:57:00+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Outroduction of old non-updated full nodes through graceful degradation to SPV mode - 2023-08-01T14:06:32.572262+00:00 + 2025-10-11T21:38:08.507270+00:00 - Natanael, in a post to the bitcoin-dev mailing list, emphasized the importance of phasing out old software versions that lack sandboxing capabilities. These outdated versions can be exploited and used counterproductively, which goes against their intended purpose. In the context of Bitcoin, full nodes are responsible for validating new transactions based on their own set of rules and policies. As the global consensus evolves and agrees upon rule changes, incompatible old full nodes will eventually be removed from the blockchain.However, identifying outdated nodes is currently challenging. To address this issue, Natanael proposed implementing expiration dates for nodes that lag behind due to multiple soft forks. These expired nodes would automatically switch to Simplified Payment Verification (SPV) mode while simultaneously alerting their owners. This approach allows nodes to continue functioning with minimal disruption, and it also prompts owners who do not regularly update their software to recognize the necessity of an update.In addition to expiration dates, Natanael suggested introducing an explicit declaration of block policy/rules within blocks themselves. This declaration would include miner votes for changes and a clear statement of incompatibility with old versions. By doing so, nodes would be able to alert their owners about the impending need for an update. Switching to SPV mode once again ensures a smooth transition and reduces the urgency associated with hard forks, giving more time for the entire network to upgrade.The decision to switch to SPV mode offers several benefits. Firstly, it extends the lifetime of older nodes without compromising security. Secondly, it prevents abandoned nodes from trusting potentially malicious longer chains. Moreover, this approach informs node owners that they cannot validate blocks using outdated code, prompting them to investigate and update as necessary. While there is still a need for information campaigns to ensure the timely updating of SPV fallback nodes, the absence of rushed deadlines makes this process more manageable.Overall, the suggestions made by Natanael aim to deprecate old software versions that lack sandboxing capabilities. By implementing expiration dates and providing explicit block policy/rules, the Bitcoin network can ensure a smoother transition to new versions, while minimizing disruption for node owners and buying more time for everyone involved. 2015-06-27T23:57:00+00:00 + Natanael, in a post to the bitcoin-dev mailing list, emphasized the importance of phasing out old software versions that lack sandboxing capabilities. These outdated versions can be exploited and used counterproductively, which goes against their intended purpose. In the context of Bitcoin, full nodes are responsible for validating new transactions based on their own set of rules and policies. As the global consensus evolves and agrees upon rule changes, incompatible old full nodes will eventually be removed from the blockchain.However, identifying outdated nodes is currently challenging. To address this issue, Natanael proposed implementing expiration dates for nodes that lag behind due to multiple soft forks. These expired nodes would automatically switch to Simplified Payment Verification (SPV) mode while simultaneously alerting their owners. This approach allows nodes to continue functioning with minimal disruption, and it also prompts owners who do not regularly update their software to recognize the necessity of an update.In addition to expiration dates, Natanael suggested introducing an explicit declaration of block policy/rules within blocks themselves. This declaration would include miner votes for changes and a clear statement of incompatibility with old versions. By doing so, nodes would be able to alert their owners about the impending need for an update. Switching to SPV mode once again ensures a smooth transition and reduces the urgency associated with hard forks, giving more time for the entire network to upgrade.The decision to switch to SPV mode offers several benefits. Firstly, it extends the lifetime of older nodes without compromising security. Secondly, it prevents abandoned nodes from trusting potentially malicious longer chains. Moreover, this approach informs node owners that they cannot validate blocks using outdated code, prompting them to investigate and update as necessary. While there is still a need for information campaigns to ensure the timely updating of SPV fallback nodes, the absence of rushed deadlines makes this process more manageable.Overall, the suggestions made by Natanael aim to deprecate old software versions that lack sandboxing capabilities. By implementing expiration dates and providing explicit block policy/rules, the Bitcoin network can ensure a smoother transition to new versions, while minimizing disruption for node owners and buying more time for everyone involved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Proposal-Move-Bitcoin-Dev-List-to-a-Neutral-Competent-Entity.xml b/static/bitcoin-dev/June_2015/combined_Proposal-Move-Bitcoin-Dev-List-to-a-Neutral-Competent-Entity.xml index 97c1237980..17a04c4413 100644 --- a/static/bitcoin-dev/June_2015/combined_Proposal-Move-Bitcoin-Dev-List-to-a-Neutral-Competent-Entity.xml +++ b/static/bitcoin-dev/June_2015/combined_Proposal-Move-Bitcoin-Dev-List-to-a-Neutral-Competent-Entity.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: Move Bitcoin Dev List to a Neutral Competent Entity - 2023-08-01T13:16:19.580450+00:00 + 2025-10-11T21:38:19.140180+00:00 + python-feedgen grarpamp 2015-06-17 01:59:47+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Proposal: Move Bitcoin Dev List to a Neutral Competent Entity - 2023-08-01T13:16:19.580450+00:00 + 2025-10-11T21:38:19.140377+00:00 - The author emphasizes the importance of using an open-source platform like Mailman instead of GoogleGroups, highlighting the drawbacks of third-party archives. They suggest making raw archives downloadable in mbox format and getting rid of unnecessary tags in the subject. The author also discourages the use of forums due to their lack of bidirectional real-time message copying. They question when crypto P2P communities will develop and use distributed messaging systems.On June 14, 2015, Warren Togami Jr. proposed the name for a new list related to bitcoin development. The group decided on a shorter name and discussed a cut-off date for the old list. There were suggestions to subscribe the old list to the new one and concerns about double-posts.In an email exchange, Adam Weiss mentioned that project admins may be able to download mbox archives of a list from SF. Pieter confirmed this, stating that he had already downloaded the entire archive of the list. There is a discussion about the problem of DKIM signatures not being handled properly by Mailman 1.0. The suggestion is made to move the list and one month is considered a reasonable timeframe. The user documentation for Mailman 3 is lacking, and there is controversy surrounding Google Groups as an alternative option.Jeff's messages are not getting through due to Mailman 1.0 not handling DKIM properly. There is uncertainty about whether Mailman 3.0 fixes this issue. The user documentation for Mailman 3 is non-existent. Google Groups is seen as a controversial alternative to Mailman. Mailman requires users to create an account for each listserv, which may be cumbersome.Warren Togami Jr. suggested creating a new mailing list for Bitcoin development and moving away from SourceForge mailing lists. The community welcomed the idea and discussed the name of the new list, the cut-off date for the old list, and moderators for the new list. The Linux Foundation was seen as a suitable host due to their neutrality and competence in open source development.The bitcoin community is discussing moving away from SourceForge mailing lists and using the Linux Foundation as a mailing infrastructure provider. They also want to research secure mailing list models for bitcoin-security. There are discussions about the name of the new list, a proposed cut-off date for the old list, and moderators for the new list. Warren Togami Jr. expresses support for hosting the bitcoin-dev list at the Linux Foundation (LF). He believes LF's competence and neutrality make them a suitable host. He suggests not deleting the SourceForge account while active links still exist. Warren agrees with Jeff's comments on bitcoin-security.There has been ongoing discussion about moving the Bitcoin-dev mailing list away from SourceForge due to concerns over the company's behavior and stability. Suggestions have been made to move the list to a neutral and competent entity such as Google Groups or the Linux Foundation. The proposal is to import the entire list archive into the new host's archives for user convenience.The Bitcoin Dev mailing list has expressed concern over SourceForge's continued hosting of the mailing list. Suggestions have been made to move the list to a neutral and competent entity such as Google Groups or the Linux Foundation. The proposal is to import the entire list archive into the new host's archives.Bitcoin developers are considering moving the Bitcoin-dev mailing list from SourceForge to an alternative host. The move is in response to concerns over SourceForge's perceived stability and questionable behavior. Suggestions have been made for Google Groups or existing organizations such as the IETF or Linux Foundation to host the mailing list. The proposal is to import the entire list archive into the new host's archives.Jeff Garzik suggests moving away from SourceForge mailing lists and using the Linux Foundation as a mailing infrastructure provider. He also suggests researching secure mailing list models for bitcoin-security. Peter Todd acknowledges Jeff's points.The Bitcoin Dev mailing list has expressed concern over SourceForge's hosting of the mailing list due to questionable behavior and stability. Suggestions have been made to move the list to a neutral and competent entity such as the Linux Foundation. The proposal includes migrating the current list archive to the new host's archives.Many people have expressed discomfort with SourceForge's hosting of the bitcoin-dev mailing list. The proposal is to move the list to a neutral and competent entity such as the Linux Foundation. The plan involves discussing the matter within the community and importing the entire list archive into the new host's archives.Bitcoin developers are considering moving their mailing list away from SourceForge. One developer suggests using the Linux Foundation as a mailing infrastructure provider. Research on secure mailing list models for bitcoin-security is also suggested. Peter Todd agrees with Jeff's points.The Bitcoin Dev mailing list has expressed concern over SourceForge's hosting of the mailing list. Suggestions have been made to move the list to a neutral and competent entity such as the Linux Foundation. The proposal includes migrating the current list archive to the new host's archives.In conclusion, the tendency to upset people can arise from a range of 2015-06-17T01:59:47+00:00 + The author emphasizes the importance of using an open-source platform like Mailman instead of GoogleGroups, highlighting the drawbacks of third-party archives. They suggest making raw archives downloadable in mbox format and getting rid of unnecessary tags in the subject. The author also discourages the use of forums due to their lack of bidirectional real-time message copying. They question when crypto P2P communities will develop and use distributed messaging systems.On June 14, 2015, Warren Togami Jr. proposed the name for a new list related to bitcoin development. The group decided on a shorter name and discussed a cut-off date for the old list. There were suggestions to subscribe the old list to the new one and concerns about double-posts.In an email exchange, Adam Weiss mentioned that project admins may be able to download mbox archives of a list from SF. Pieter confirmed this, stating that he had already downloaded the entire archive of the list. There is a discussion about the problem of DKIM signatures not being handled properly by Mailman 1.0. The suggestion is made to move the list and one month is considered a reasonable timeframe. The user documentation for Mailman 3 is lacking, and there is controversy surrounding Google Groups as an alternative option.Jeff's messages are not getting through due to Mailman 1.0 not handling DKIM properly. There is uncertainty about whether Mailman 3.0 fixes this issue. The user documentation for Mailman 3 is non-existent. Google Groups is seen as a controversial alternative to Mailman. Mailman requires users to create an account for each listserv, which may be cumbersome.Warren Togami Jr. suggested creating a new mailing list for Bitcoin development and moving away from SourceForge mailing lists. The community welcomed the idea and discussed the name of the new list, the cut-off date for the old list, and moderators for the new list. The Linux Foundation was seen as a suitable host due to their neutrality and competence in open source development.The bitcoin community is discussing moving away from SourceForge mailing lists and using the Linux Foundation as a mailing infrastructure provider. They also want to research secure mailing list models for bitcoin-security. There are discussions about the name of the new list, a proposed cut-off date for the old list, and moderators for the new list. Warren Togami Jr. expresses support for hosting the bitcoin-dev list at the Linux Foundation (LF). He believes LF's competence and neutrality make them a suitable host. He suggests not deleting the SourceForge account while active links still exist. Warren agrees with Jeff's comments on bitcoin-security.There has been ongoing discussion about moving the Bitcoin-dev mailing list away from SourceForge due to concerns over the company's behavior and stability. Suggestions have been made to move the list to a neutral and competent entity such as Google Groups or the Linux Foundation. The proposal is to import the entire list archive into the new host's archives for user convenience.The Bitcoin Dev mailing list has expressed concern over SourceForge's continued hosting of the mailing list. Suggestions have been made to move the list to a neutral and competent entity such as Google Groups or the Linux Foundation. The proposal is to import the entire list archive into the new host's archives.Bitcoin developers are considering moving the Bitcoin-dev mailing list from SourceForge to an alternative host. The move is in response to concerns over SourceForge's perceived stability and questionable behavior. Suggestions have been made for Google Groups or existing organizations such as the IETF or Linux Foundation to host the mailing list. The proposal is to import the entire list archive into the new host's archives.Jeff Garzik suggests moving away from SourceForge mailing lists and using the Linux Foundation as a mailing infrastructure provider. He also suggests researching secure mailing list models for bitcoin-security. Peter Todd acknowledges Jeff's points.The Bitcoin Dev mailing list has expressed concern over SourceForge's hosting of the mailing list due to questionable behavior and stability. Suggestions have been made to move the list to a neutral and competent entity such as the Linux Foundation. The proposal includes migrating the current list archive to the new host's archives.Many people have expressed discomfort with SourceForge's hosting of the bitcoin-dev mailing list. The proposal is to move the list to a neutral and competent entity such as the Linux Foundation. The plan involves discussing the matter within the community and importing the entire list archive into the new host's archives.Bitcoin developers are considering moving their mailing list away from SourceForge. One developer suggests using the Linux Foundation as a mailing infrastructure provider. Research on secure mailing list models for bitcoin-security is also suggested. Peter Todd agrees with Jeff's points.The Bitcoin Dev mailing list has expressed concern over SourceForge's hosting of the mailing list. Suggestions have been made to move the list to a neutral and competent entity such as the Linux Foundation. The proposal includes migrating the current list archive to the new host's archives.In conclusion, the tendency to upset people can arise from a range of - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Proposal-SPV-Fee-Discovery-mechanism.xml b/static/bitcoin-dev/June_2015/combined_Proposal-SPV-Fee-Discovery-mechanism.xml index 41b93d6672..5fe6c0e2d5 100644 --- a/static/bitcoin-dev/June_2015/combined_Proposal-SPV-Fee-Discovery-mechanism.xml +++ b/static/bitcoin-dev/June_2015/combined_Proposal-SPV-Fee-Discovery-mechanism.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: SPV Fee Discovery mechanism - 2023-08-01T13:11:06.966083+00:00 + 2025-10-11T21:36:58.432907+00:00 + python-feedgen Nathan Wilcox 2015-06-13 15:38:56+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Proposal: SPV Fee Discovery mechanism - 2023-08-01T13:11:06.966083+00:00 + 2025-10-11T21:36:58.433105+00:00 - The email conversation discusses the possibility of encoding fee statistics in the coinbase transaction to assist SPV clients. However, concerns are raised about miners moving fees outside of explicit inband fees and the potential for individual miners to fabricate fee stats. The discussion also addresses the issue of blocks filling up and proposes working with the largest miners and pools to auction off space in their blocks. This would result in a federated service operator model but would avoid unpredictable transaction failure. The importance of predictability for users when it comes to transaction fees and dropped transactions is emphasized.Another proposal suggests agreeing on a data format and encoding it in an op_return output in the coinbase transaction for calculating average fee-per-kb paid by all transactions in a block. However, it is noted that SPV clients should not rely on this encoding until a softfork is activated. The trade-off between the size of transactions and altering consensus rules for Header-PoW-verifying client is also discussed. The email thread also discusses the vulnerability of replace-by-fee to fabrications by transaction relay services and proposes using information in the blockchain as a source of pricing information for fee decisions. The predictability of dropped transactions is addressed, with lowest fee/KB transactions being dropped first. However, it is pointed out that from the user's perspective, the dropping of transactions can still be unpredictable if they don't know how to pick the appropriate fees. The need for ways to increase transaction fees after initial broadcast is mentioned, as well as the issue of network congestion causing dropped transactions. It is suggested that knowing the network congestion at the present moment is critical, but this can be a lagging indicator based on the last time you connected. The proposal to embed output values into the signed data of transactions and upgrade the P2P protocol to send UTXO data is discussed as a method for SPV wallets to learn about fees. However, significant protocol upgrades and code changes would be required.The conversation also addresses the issue of implementing a mechanism for SPV clients to rely on fee and other statistics. The proposal suggests encoding this information in an op_return output within the coinbase transaction, but it is noted that the results can be fabricated by individual miners until a softfork is activated. The risk of Sybil attacks and the use of services like blockcypher for up-to-the-minute fee calculations are discussed. The implementation of such a mechanism is seen as valuable regardless of the outcome of the blocksize debate.Overall, the discussion revolves around finding solutions to the challenges associated with transaction fees, network congestion, and dropped transactions. Various proposals and concerns are raised, highlighting the need for reliable and predictable fee information for users and SPV clients. 2015-06-13T15:38:56+00:00 + The email conversation discusses the possibility of encoding fee statistics in the coinbase transaction to assist SPV clients. However, concerns are raised about miners moving fees outside of explicit inband fees and the potential for individual miners to fabricate fee stats. The discussion also addresses the issue of blocks filling up and proposes working with the largest miners and pools to auction off space in their blocks. This would result in a federated service operator model but would avoid unpredictable transaction failure. The importance of predictability for users when it comes to transaction fees and dropped transactions is emphasized.Another proposal suggests agreeing on a data format and encoding it in an op_return output in the coinbase transaction for calculating average fee-per-kb paid by all transactions in a block. However, it is noted that SPV clients should not rely on this encoding until a softfork is activated. The trade-off between the size of transactions and altering consensus rules for Header-PoW-verifying client is also discussed. The email thread also discusses the vulnerability of replace-by-fee to fabrications by transaction relay services and proposes using information in the blockchain as a source of pricing information for fee decisions. The predictability of dropped transactions is addressed, with lowest fee/KB transactions being dropped first. However, it is pointed out that from the user's perspective, the dropping of transactions can still be unpredictable if they don't know how to pick the appropriate fees. The need for ways to increase transaction fees after initial broadcast is mentioned, as well as the issue of network congestion causing dropped transactions. It is suggested that knowing the network congestion at the present moment is critical, but this can be a lagging indicator based on the last time you connected. The proposal to embed output values into the signed data of transactions and upgrade the P2P protocol to send UTXO data is discussed as a method for SPV wallets to learn about fees. However, significant protocol upgrades and code changes would be required.The conversation also addresses the issue of implementing a mechanism for SPV clients to rely on fee and other statistics. The proposal suggests encoding this information in an op_return output within the coinbase transaction, but it is noted that the results can be fabricated by individual miners until a softfork is activated. The risk of Sybil attacks and the use of services like blockcypher for up-to-the-minute fee calculations are discussed. The implementation of such a mechanism is seen as valuable regardless of the outcome of the blocksize debate.Overall, the discussion revolves around finding solutions to the challenges associated with transaction fees, network congestion, and dropped transactions. Various proposals and concerns are raised, highlighting the need for reliable and predictable fee information for users and SPV clients. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Proposed-alternatives-to-the-20MB-step-function.xml b/static/bitcoin-dev/June_2015/combined_Proposed-alternatives-to-the-20MB-step-function.xml index 70649dc6ee..53976f0cf7 100644 --- a/static/bitcoin-dev/June_2015/combined_Proposed-alternatives-to-the-20MB-step-function.xml +++ b/static/bitcoin-dev/June_2015/combined_Proposed-alternatives-to-the-20MB-step-function.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed alternatives to the 20MB step function - 2023-08-01T12:30:25.361158+00:00 + 2025-10-11T21:38:53.137846+00:00 + python-feedgen Marcel Jamin 2015-06-01 11:46:30+00:00 @@ -255,13 +256,13 @@ - python-feedgen + 2 Combined summary - Proposed alternatives to the 20MB step function - 2023-08-01T12:30:25.362112+00:00 + 2025-10-11T21:38:53.138127+00:00 - The ongoing debate and proposals regarding the block size limit in the Bitcoin network have been highlighted in the context. Various suggestions have been made, including making the block size limit a function of the number of transactions in the mempool, implementing dynamic scaling within a certain range, and introducing a consensus protocol for block sizes. The discussion acknowledges the need to balance scalability with decentralization and inclusivity.Gavin Andresen has proposed implementing a big increase in block size over time and seeking support from miners and infrastructure companies to run alternative versions of Bitcoin. However, there is disagreement on whether the block size should increase or remain constant, and how to measure merchant and exchange acceptance of bigger blocks.Mike Hearn suggested that the current 32mb cap on block sizes could be changed to at least some multiple of the maximum block size allowed. Another suggestion was to incorporate the required functionality into the merkle block message, allowing for sending headers messages with one header and merkleblock messages with a maximum of 1MB per message.The topic of block size and transaction throughput in Bitcoin was further discussed, with concerns raised about artificially limiting the network's organic growth. Gavin Andresen proposed a 20mb limit as a reasonable compromise, but also emphasized the importance of planning around global factors, rather than just American buying habits. Doubling the block size daily was considered imprudent, and a logarithmic increase in difficulty every 2016 blocks was suggested instead.There was a conversation about changing default settings for Bitcoin miners, with Gavin Andresen expressing skepticism towards this idea. He suggested a rule of "larger of 1MB or 2x average size" as a better option.Gavin Andresen also shared his opinion on fee pressure in the network, stating that block propagation should be made faster to eliminate technical reasons for miners producing small blocks. However, he emphasized that developers should not decide whether fees are too high or low.The fear associated with a maximum block size of twenty in Bitcoin was mentioned, with concerns raised about artificially throttling organic network growth. The discussion also touched on the balance between scaling and maintaining network stability.There were discussions about potentially setting the max size to be 20 times the average size instead. Different ideas were proposed for calculating the maximum block size, including using the median or average size of recent blocks.In terms of unspent transaction outputs (UTXOs), concerns were raised about incentives for miners to include more UTXOs in blocks. Suggestions were made to exclude UTXOs before a certain count and to store them as a fixed digest. There were also discussions about the difficulty of cryptocurrency mining and its impact on transaction fees.The article by Justus Ranvier proposes a solution where the block size is determined by the price of fees and the willingness of users to pay them, allowing for greater price discovery and alignment of incentives among network participants.During discussions about the maximum block size for Bitcoin, different proposals have been put forward. Joel Joonatan Kaartinen suggested using "bitcoin days destroyed" as a measure of demand for space in the blockchain, but Matt Whitlock pointed out flaws in this method. Whitlock argued that it does not account for future changes in bitcoin velocity and may not be relevant when large amounts of bitcoins are moved to new addresses.Gavin Andresen also proposed using the bitcoin days destroyed in transactions included in the block to determine the maximum block size. This suggestion has potential for scaling and maintaining a constant fee pressure. However, concerns were raised about its accuracy in reflecting the demand for blockchain space in the distant future when Bitcoin is more widely adopted. Further explanation is needed to ensure everyone understands the purpose of this proposal.In another discussion, various ideas were raised for determining the hard block size limit of Bitcoin. One proposal was to base the limit on bitcoin days destroyed, while another suggested allowing miners to vote on the limit. A third idea proposed making the limit a function of the blockchain length. Matt expressed support for the first proposal, as it utilizes existing data and eliminates the possibility of a mismatch between conscious votes and behavior. He cautioned against immediately jumping to a 20 MB limit, believing that it would avoid solving the problem in a controversial way.There are proponents and critics of the fixed 20 MB cap, with arguments presented for and against it. While it is the simplest solution currently proposed, it is acknowledged that it is not perfect. The speaker hopes for a less traumatic chain forking process and recalls a previous discussion about scheduling a fork every year to provide predictability. However, if things go well, there is no reason why the 20 MB limit would be permanent.In summary, discussions have taken place regarding the maximum block size for Bitcoin, with suggestions ranging from using "bitcoin days destroyed" to allowing miners to vote on the limit. The ultimate goal is to find a scalable and secure solution that supports the growth and adoption of blockchain technology. 2015-06-01T11:46:30+00:00 + The ongoing debate and proposals regarding the block size limit in the Bitcoin network have been highlighted in the context. Various suggestions have been made, including making the block size limit a function of the number of transactions in the mempool, implementing dynamic scaling within a certain range, and introducing a consensus protocol for block sizes. The discussion acknowledges the need to balance scalability with decentralization and inclusivity.Gavin Andresen has proposed implementing a big increase in block size over time and seeking support from miners and infrastructure companies to run alternative versions of Bitcoin. However, there is disagreement on whether the block size should increase or remain constant, and how to measure merchant and exchange acceptance of bigger blocks.Mike Hearn suggested that the current 32mb cap on block sizes could be changed to at least some multiple of the maximum block size allowed. Another suggestion was to incorporate the required functionality into the merkle block message, allowing for sending headers messages with one header and merkleblock messages with a maximum of 1MB per message.The topic of block size and transaction throughput in Bitcoin was further discussed, with concerns raised about artificially limiting the network's organic growth. Gavin Andresen proposed a 20mb limit as a reasonable compromise, but also emphasized the importance of planning around global factors, rather than just American buying habits. Doubling the block size daily was considered imprudent, and a logarithmic increase in difficulty every 2016 blocks was suggested instead.There was a conversation about changing default settings for Bitcoin miners, with Gavin Andresen expressing skepticism towards this idea. He suggested a rule of "larger of 1MB or 2x average size" as a better option.Gavin Andresen also shared his opinion on fee pressure in the network, stating that block propagation should be made faster to eliminate technical reasons for miners producing small blocks. However, he emphasized that developers should not decide whether fees are too high or low.The fear associated with a maximum block size of twenty in Bitcoin was mentioned, with concerns raised about artificially throttling organic network growth. The discussion also touched on the balance between scaling and maintaining network stability.There were discussions about potentially setting the max size to be 20 times the average size instead. Different ideas were proposed for calculating the maximum block size, including using the median or average size of recent blocks.In terms of unspent transaction outputs (UTXOs), concerns were raised about incentives for miners to include more UTXOs in blocks. Suggestions were made to exclude UTXOs before a certain count and to store them as a fixed digest. There were also discussions about the difficulty of cryptocurrency mining and its impact on transaction fees.The article by Justus Ranvier proposes a solution where the block size is determined by the price of fees and the willingness of users to pay them, allowing for greater price discovery and alignment of incentives among network participants.During discussions about the maximum block size for Bitcoin, different proposals have been put forward. Joel Joonatan Kaartinen suggested using "bitcoin days destroyed" as a measure of demand for space in the blockchain, but Matt Whitlock pointed out flaws in this method. Whitlock argued that it does not account for future changes in bitcoin velocity and may not be relevant when large amounts of bitcoins are moved to new addresses.Gavin Andresen also proposed using the bitcoin days destroyed in transactions included in the block to determine the maximum block size. This suggestion has potential for scaling and maintaining a constant fee pressure. However, concerns were raised about its accuracy in reflecting the demand for blockchain space in the distant future when Bitcoin is more widely adopted. Further explanation is needed to ensure everyone understands the purpose of this proposal.In another discussion, various ideas were raised for determining the hard block size limit of Bitcoin. One proposal was to base the limit on bitcoin days destroyed, while another suggested allowing miners to vote on the limit. A third idea proposed making the limit a function of the blockchain length. Matt expressed support for the first proposal, as it utilizes existing data and eliminates the possibility of a mismatch between conscious votes and behavior. He cautioned against immediately jumping to a 20 MB limit, believing that it would avoid solving the problem in a controversial way.There are proponents and critics of the fixed 20 MB cap, with arguments presented for and against it. While it is the simplest solution currently proposed, it is acknowledged that it is not perfect. The speaker hopes for a less traumatic chain forking process and recalls a previous discussion about scheduling a fork every year to provide predictability. However, if things go well, there is no reason why the 20 MB limit would be permanent.In summary, discussions have taken place regarding the maximum block size for Bitcoin, with suggestions ranging from using "bitcoin days destroyed" to allowing miners to vote on the limit. The ultimate goal is to find a scalable and secure solution that supports the growth and adoption of blockchain technology. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Proposed-alternatives-to-the-20MB-step.xml b/static/bitcoin-dev/June_2015/combined_Proposed-alternatives-to-the-20MB-step.xml index ffbb9ec48a..0417bbfee2 100644 --- a/static/bitcoin-dev/June_2015/combined_Proposed-alternatives-to-the-20MB-step.xml +++ b/static/bitcoin-dev/June_2015/combined_Proposed-alternatives-to-the-20MB-step.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed alternatives to the 20MB step - 2023-08-01T12:59:53.860490+00:00 + 2025-10-11T21:38:04.257584+00:00 + python-feedgen odinn 2015-06-13 06:05:35+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Proposed alternatives to the 20MB step - 2023-08-01T12:59:53.860490+00:00 + 2025-10-11T21:38:04.257762+00:00 - Former Bitcoin developer Mike Hearn believes that decentralization is crucial for the cryptocurrency system. He suggests using an "ASIC resistant" alt-coin with no SPV or web wallets to achieve this goal. Hearn emphasizes that the number of independent people who mine is more important than the percentage of the community that mines. However, some argue that having more usage but concentrated power in a smaller elite group would be preferable.Hearn discusses how Bitcoin has become less decentralized over time due to the rise of mining pools. While there used to be thousands of people mining with their own CPUs and GPUs, now only dozens of full nodes matter for block selection. However, a recent report suggests that the number of Bitcoin miners is actually higher than popular estimates. Mining pools may make Bitcoin appear less decentralized, but they do not necessarily undermine the cooperative nature of the ecosystem.The discussion also involves the value and goals of Bitcoin. Hearn argues that Bitcoin's value comes from its decentralization, while Satoshi Nakamoto counters that usage is what gives Bitcoin value. Hearn believes that Bitcoin's utility lies in its lack of centralized control. He states that decentralization is the primary objective of Bitcoin and that the absolute number of independent people in control is what matters for decentralization.There is controversy among core developers regarding a proposal to raise capacity in the Bitcoin ecosystem. Some see it as necessary for the system's growth, while others believe they have veto power over changes to Bitcoin. This disagreement could potentially lead to a fork in the system. The value of Bitcoin is not solely based on decentralization but also on its usage. There are proposals for layer 2 and offchain solutions, but implementing them is not a straightforward task.Gavin Andresen, a core developer of Bitcoin, prioritizes scaling up as the biggest concern. He believes that increasing the block size limit will not lead to centralization and that layer 2 services built on top of the blockchain are necessary for various types of payments. However, he acknowledges concerns about long-term security and transaction fees.Jerome Legoupil expresses concern over Gavin Andresen's approach to implementing a big increase in the block size limit. He believes that decentralization is crucial for Bitcoin's security model and opposes the 20MB proposal.Gavin Andresen plans to ask for help in reviewing and submitting patches for his proposal to increase the block size limit. He aims to avoid future debates by gradually growing the limit. However, this approach is criticized as it distracts core developers from their technical responsibilities. Some argue that the proposed increase compromises Bitcoin's long-term security. Jerome opposes the proposal, suggesting that reaching a limit would incentivize layer 2 and off-chain solutions and allow consensus to be reached if necessary. 2015-06-13T06:05:35+00:00 + Former Bitcoin developer Mike Hearn believes that decentralization is crucial for the cryptocurrency system. He suggests using an "ASIC resistant" alt-coin with no SPV or web wallets to achieve this goal. Hearn emphasizes that the number of independent people who mine is more important than the percentage of the community that mines. However, some argue that having more usage but concentrated power in a smaller elite group would be preferable.Hearn discusses how Bitcoin has become less decentralized over time due to the rise of mining pools. While there used to be thousands of people mining with their own CPUs and GPUs, now only dozens of full nodes matter for block selection. However, a recent report suggests that the number of Bitcoin miners is actually higher than popular estimates. Mining pools may make Bitcoin appear less decentralized, but they do not necessarily undermine the cooperative nature of the ecosystem.The discussion also involves the value and goals of Bitcoin. Hearn argues that Bitcoin's value comes from its decentralization, while Satoshi Nakamoto counters that usage is what gives Bitcoin value. Hearn believes that Bitcoin's utility lies in its lack of centralized control. He states that decentralization is the primary objective of Bitcoin and that the absolute number of independent people in control is what matters for decentralization.There is controversy among core developers regarding a proposal to raise capacity in the Bitcoin ecosystem. Some see it as necessary for the system's growth, while others believe they have veto power over changes to Bitcoin. This disagreement could potentially lead to a fork in the system. The value of Bitcoin is not solely based on decentralization but also on its usage. There are proposals for layer 2 and offchain solutions, but implementing them is not a straightforward task.Gavin Andresen, a core developer of Bitcoin, prioritizes scaling up as the biggest concern. He believes that increasing the block size limit will not lead to centralization and that layer 2 services built on top of the blockchain are necessary for various types of payments. However, he acknowledges concerns about long-term security and transaction fees.Jerome Legoupil expresses concern over Gavin Andresen's approach to implementing a big increase in the block size limit. He believes that decentralization is crucial for Bitcoin's security model and opposes the 20MB proposal.Gavin Andresen plans to ask for help in reviewing and submitting patches for his proposal to increase the block size limit. He aims to avoid future debates by gradually growing the limit. However, this approach is criticized as it distracts core developers from their technical responsibilities. Some argue that the proposed increase compromises Bitcoin's long-term security. Jerome opposes the proposal, suggesting that reaching a limit would incentivize layer 2 and off-chain solutions and allow consensus to be reached if necessary. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Question-regarding-transactions-with-NLOCKTIME-0.xml b/static/bitcoin-dev/June_2015/combined_Question-regarding-transactions-with-NLOCKTIME-0.xml index fa14a88392..9825d659e5 100644 --- a/static/bitcoin-dev/June_2015/combined_Question-regarding-transactions-with-NLOCKTIME-0.xml +++ b/static/bitcoin-dev/June_2015/combined_Question-regarding-transactions-with-NLOCKTIME-0.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Question regarding transactions with NLOCKTIME > 0 - 2023-08-01T13:29:42.426406+00:00 + 2025-10-11T21:38:40.387453+00:00 + python-feedgen Jeff Garzik 2015-06-21 16:54:08+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Question regarding transactions with NLOCKTIME > 0 - 2023-08-01T13:29:42.426406+00:00 + 2025-10-11T21:38:40.387613+00:00 - The email thread discusses the usage of nLockTime in Bitcoin transactions and how it is handled by different wallets. When a transaction with an nLockTime value greater than zero is created, it cannot be accepted or relayed by nodes until the locktime expires. This means that it cannot be stored in a block before its locktime expires and must be kept offline until then. The purpose of nLockTime is to ensure that the transaction is not broadcasted and confirmed into a block before the specified locktime.Peter Todd and others are working on enhancements to basic nLockTime called CHECKLOCKTIMEVERIFY and RELATIVE CHECKLOCKTIMEVERIFY. These enhancements offer users the guarantee that if they have a transaction with nLockTime, the signer holding the private keys used to sign it cannot sign another transaction with nLockTime 0 and broadcast it before the locktime for their original transaction expires. This provides added security and prevents the possibility of a signed transaction being overridden by a conflicting one.There is also a discussion about the storage of transactions with nLockTime on the blockchain. Braun Brelin raises a question regarding whether such transactions are stored in a block on the blockchain or in the mempool until the actual time or block number exceeds the current value. In addition, Braun questions how this affects the concept of pruning that is supposed to be implemented in version 0.11. Specifically, if a transaction is created that doesn't take effect for 10 years and is stored in a block, does that block stay on the active list for that entire period?Overall, the email thread delves into the intricacies of nLockTime, its importance in verifying transactions, and ongoing efforts to enhance its functionality. It also addresses concerns regarding the storage of transactions with nLockTime on the blockchain and their impact on the concept of pruning. 2015-06-21T16:54:08+00:00 + The email thread discusses the usage of nLockTime in Bitcoin transactions and how it is handled by different wallets. When a transaction with an nLockTime value greater than zero is created, it cannot be accepted or relayed by nodes until the locktime expires. This means that it cannot be stored in a block before its locktime expires and must be kept offline until then. The purpose of nLockTime is to ensure that the transaction is not broadcasted and confirmed into a block before the specified locktime.Peter Todd and others are working on enhancements to basic nLockTime called CHECKLOCKTIMEVERIFY and RELATIVE CHECKLOCKTIMEVERIFY. These enhancements offer users the guarantee that if they have a transaction with nLockTime, the signer holding the private keys used to sign it cannot sign another transaction with nLockTime 0 and broadcast it before the locktime for their original transaction expires. This provides added security and prevents the possibility of a signed transaction being overridden by a conflicting one.There is also a discussion about the storage of transactions with nLockTime on the blockchain. Braun Brelin raises a question regarding whether such transactions are stored in a block on the blockchain or in the mempool until the actual time or block number exceeds the current value. In addition, Braun questions how this affects the concept of pruning that is supposed to be implemented in version 0.11. Specifically, if a transaction is created that doesn't take effect for 10 years and is stored in a block, does that block stay on the active list for that entire period?Overall, the email thread delves into the intricacies of nLockTime, its importance in verifying transactions, and ongoing efforts to enhance its functionality. It also addresses concerns regarding the storage of transactions with nLockTime on the blockchain and their impact on the concept of pruning. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml b/static/bitcoin-dev/June_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml index ea54d89274..b942426980 100644 --- a/static/bitcoin-dev/June_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml +++ b/static/bitcoin-dev/June_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC: HD Bitmessage address derivation based on BIP-43 - 2023-08-01T14:09:53.705304+00:00 + 2025-10-11T21:37:19.665758+00:00 + python-feedgen Jorge Timón 2015-09-06 02:09:52+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - RFC: HD Bitmessage address derivation based on BIP-43 - 2023-08-01T14:09:53.705304+00:00 + 2025-10-11T21:37:19.665928+00:00 - In September 2015, a discussion took place on the Bitcoin-dev mailing list regarding the maintenance of competing registries for different companies and P2P chains. Some argued that the current centralized registries were acceptable as long as they didn't rely on having only one registry or having the same values for the same chains. However, others believed that BIP44's centralized registry control by a single company was not acceptable and proposed using a code deterministically generated from the chain ID instead. This proposal was seen as retro-compatible and provided securely unique IDs without the need for a centralized registry. It was suggested to start a Chain IDs BIP.The BIP repository made a decision to move part of the standard to a separate repository due to the constant updates unrelated to Bitcoin proper. On September 5th, 2015, a conversation between Jorge Timón and Justus Ranvier on the bitcoin-dev mailing list addressed concerns about delegating the BIP-43 namespace management to a specific company (SatoshiLabs). Justus questioned the benefit of this delegation and proposed using purpose codes matching the BIP number instead. He also expressed concerns with BIP44's centralized registry control and suggested using a code deterministically generated from the chain ID as a solution.Luke Dashjr, a Bitcoin Core Developer, expressed concerns about polluting the BIP repository with non-Bitcoin related specifications in response to a proposal to add HD generation of keypairs from a single seed for non-conflicting uses. Justus Ranvier countered by stating that intentionally making a useful technology less useful due to difficulties in assigning non-colliding numbers was a strange approach to software engineering. Justus Ranvier is associated with the Open Bitcoin Privacy Project, which promotes financial privacy and anonymity through the use of Bitcoin.On June 30, 2015, Justus Ranvier proposed a Bitmessage address derivation method based on BIP-43 developed by Monetas. This method allows Bitmessage users to generate addresses from a seed, providing eternal key backups and enabling future use cases. Monetas proposed this method as a BIP to reserve a purpose code. The proposal was made on the bitcoin-dev mailing list and included links to the relevant GitHub pages and contact details.Overall, the discussions on the bitcoin-dev mailing list revolved around the management of purpose codes, registry control, and the benefits and drawbacks of different approaches to maintain competing registries for different companies and P2P chains. 2015-09-06T02:09:52+00:00 + In September 2015, a discussion took place on the Bitcoin-dev mailing list regarding the maintenance of competing registries for different companies and P2P chains. Some argued that the current centralized registries were acceptable as long as they didn't rely on having only one registry or having the same values for the same chains. However, others believed that BIP44's centralized registry control by a single company was not acceptable and proposed using a code deterministically generated from the chain ID instead. This proposal was seen as retro-compatible and provided securely unique IDs without the need for a centralized registry. It was suggested to start a Chain IDs BIP.The BIP repository made a decision to move part of the standard to a separate repository due to the constant updates unrelated to Bitcoin proper. On September 5th, 2015, a conversation between Jorge Timón and Justus Ranvier on the bitcoin-dev mailing list addressed concerns about delegating the BIP-43 namespace management to a specific company (SatoshiLabs). Justus questioned the benefit of this delegation and proposed using purpose codes matching the BIP number instead. He also expressed concerns with BIP44's centralized registry control and suggested using a code deterministically generated from the chain ID as a solution.Luke Dashjr, a Bitcoin Core Developer, expressed concerns about polluting the BIP repository with non-Bitcoin related specifications in response to a proposal to add HD generation of keypairs from a single seed for non-conflicting uses. Justus Ranvier countered by stating that intentionally making a useful technology less useful due to difficulties in assigning non-colliding numbers was a strange approach to software engineering. Justus Ranvier is associated with the Open Bitcoin Privacy Project, which promotes financial privacy and anonymity through the use of Bitcoin.On June 30, 2015, Justus Ranvier proposed a Bitmessage address derivation method based on BIP-43 developed by Monetas. This method allows Bitmessage users to generate addresses from a seed, providing eternal key backups and enabling future use cases. Monetas proposed this method as a BIP to reserve a purpose code. The proposal was made on the bitcoin-dev mailing list and included links to the relevant GitHub pages and contact details.Overall, the discussions on the bitcoin-dev mailing list revolved around the management of purpose codes, registry control, and the benefits and drawbacks of different approaches to maintain competing registries for different companies and P2P chains. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Remove-Us-Please.xml b/static/bitcoin-dev/June_2015/combined_Remove-Us-Please.xml index 036e6f6ceb..6253cf39f9 100644 --- a/static/bitcoin-dev/June_2015/combined_Remove-Us-Please.xml +++ b/static/bitcoin-dev/June_2015/combined_Remove-Us-Please.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Remove Us Please - 2023-08-01T13:26:20.236547+00:00 + 2025-10-11T21:37:26.033149+00:00 + python-feedgen Jameson Lopp 2015-06-19 20:27:05+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Remove Us Please - 2023-08-01T13:26:20.236547+00:00 + 2025-10-11T21:37:26.033296+00:00 - In October 2014, Gigas Gaming Inc. announced its plans to launch its own cryptocurrency and had hired an expert to do some of the coding for the project by October 14, 2015. They had previously created a cryptocurrency called GigasCorpCoin for testing purposes and had identified an underlying problem with Bitcoin that they aimed to solve. However, the company's President declined to be interviewed about the secretive project due to the amount of work still needed to be done.In June 2015, Gigas Gaming Inc. responded to an email from Jameson Lopp, a member of the Bitcoin-development mailing list, requesting that their email be removed from the list. The company believed that the mailing list had turned into a chatroom and was interfering with official company business. They emphasized the importance of the project and the need for confidentiality. Despite this request, the company continued to develop its cryptocurrency in secret.On June 19, 2015, Gigas Gaming Inc. sent an email requesting to be removed from the Bitcoin-development mailing list, as they believed it had become a chatroom and was interfering with official company business. They included a link to unsubscribe from the list, which is provided at the bottom of every email. This request was made to the Bitcoin-development mailing list hosted by SourceForge.From the available information, it can be inferred that Gigas Gaming Inc. was facing issues with the mailing list, potentially due to excessive emails or irrelevant messages that were impacting productivity or communication within the organization. The company took proactive steps to address their concerns by requesting to be removed from the list. However, the exact nature and impact of the issue remain unclear without further information.Overall, the situation highlights Gigas Gaming Inc.'s commitment to maintaining a professional and focused work environment, despite any challenges posed by the mailing list. It remains to be seen how this issue will be resolved and if any changes will be made to the management of the mailing list in the future. 2015-06-19T20:27:05+00:00 + In October 2014, Gigas Gaming Inc. announced its plans to launch its own cryptocurrency and had hired an expert to do some of the coding for the project by October 14, 2015. They had previously created a cryptocurrency called GigasCorpCoin for testing purposes and had identified an underlying problem with Bitcoin that they aimed to solve. However, the company's President declined to be interviewed about the secretive project due to the amount of work still needed to be done.In June 2015, Gigas Gaming Inc. responded to an email from Jameson Lopp, a member of the Bitcoin-development mailing list, requesting that their email be removed from the list. The company believed that the mailing list had turned into a chatroom and was interfering with official company business. They emphasized the importance of the project and the need for confidentiality. Despite this request, the company continued to develop its cryptocurrency in secret.On June 19, 2015, Gigas Gaming Inc. sent an email requesting to be removed from the Bitcoin-development mailing list, as they believed it had become a chatroom and was interfering with official company business. They included a link to unsubscribe from the list, which is provided at the bottom of every email. This request was made to the Bitcoin-development mailing list hosted by SourceForge.From the available information, it can be inferred that Gigas Gaming Inc. was facing issues with the mailing list, potentially due to excessive emails or irrelevant messages that were impacting productivity or communication within the organization. The company took proactive steps to address their concerns by requesting to be removed from the list. However, the exact nature and impact of the issue remain unclear without further information.Overall, the situation highlights Gigas Gaming Inc.'s commitment to maintaining a professional and focused work environment, despite any challenges posed by the mailing list. It remains to be seen how this issue will be resolved and if any changes will be made to the management of the mailing list in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Reusable-payment-codes.xml b/static/bitcoin-dev/June_2015/combined_Reusable-payment-codes.xml index 66adf5b092..0078f79659 100644 --- a/static/bitcoin-dev/June_2015/combined_Reusable-payment-codes.xml +++ b/static/bitcoin-dev/June_2015/combined_Reusable-payment-codes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reusable payment codes - 2023-08-01T12:16:22.615116+00:00 + 2025-10-11T21:37:04.804739+00:00 + python-feedgen Justus Ranvier 2015-10-23 15:57:14+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Reusable payment codes - 2023-08-01T12:16:22.615116+00:00 + 2025-10-11T21:37:04.804921+00:00 - In October 2015, there was a discussion on the bitcoin-dev mailing list about Bitcoin Improvement Proposal (BIP) version 1. Luke Dashjr disagreed with adopting the proposal as is because multi-push OP_RETURN outputs were not standard transactions and could not be relied upon for network relay. He suggested waiting for additional capabilities to be deployed in the network before specifying a version 2 payment code. Justus Ranvier argued that version 1 payment codes were designed to be deployable without requiring network-level changes and acknowledged that multi-push OP_RETURN outputs would be standard in v0.12.0 of Bitcoin.Luke Dashjr expressed concerns about the "notification address" requirement in a proposal, as it would lead to address reuse and blockchain spam. He suggested using a single zero-value OP_RETURN output with two pushes instead. Justus Ranvier acknowledged that this portion of the proposal was not ideal but emphasized the goal of making the proposal usable on as many mobile/light wallets as possible. Dashjr argued that BIPs should not be designed around current software and that software upgrades are necessary regardless.There was also an email exchange regarding BIP 63, where Peter Todd expressed his inclination to shelve work on it due to other priorities. Several people offered to send donations to advance the BIP, but no donation address was posted. Todd suggested that someone else could take up the work if interested.Justus Ranvier shared an RFC on April 24, 2015, for a new type of Bitcoin address called a payment code. Payment codes are SPV-friendly alternatives to stealth addresses that positively identify senders to recipients and require less blockchain data storage. They can be publicly advertised without compromising financial privacy. Luke Dashjr expressed concerns about the "notification address" requirement in the proposal, suggesting an alternative approach using a single zero-value OP_RETURN output with two pushes.The concept of identity in relation to payment codes was discussed, with the understanding that it refers to a specific extended public/private key pair rather than conventional personal information. The discussion also touched on privacy concerns in SPV clients and suggested measures such as connecting exclusively through Tor and using varying bloom filters to enhance privacy.Brian Deery expressed worries about payment codes, particularly regarding the explicit tying of identities to them and the potential for identity linkage in bloom filter clients. There were suggestions for improving privacy in SPV clients by using multiple peers, filtering subsets of addresses, and varying the addresses being monitored.One of the main challenges with payment codes is that they rely on making dust payments to a constantly reused address, which undermines the privacy it aims to provide. This method also doubles the data sent for one-time anonymous donations. To address these issues, Brian suggests some ideas such as using even or odd DER encoding to save bytes and deriving the chain value from the x value to save more bytes. Another suggestion is to encode the "x value" into the signature's R value to make the transaction appear like a standard bitcoin transaction and eliminate the need for op_return.In terms of privacy, Brian proposes the concept of a common meeting point where the receiver of the payment code would trial-decode all payment codes sent to a pre-specified dead drop address, such as a charity address. This would require more effort from the receiver but would provide privacy regarding the number of people interacting with them.The proposed payment code scheme establishes a shared chain once and does not require reestablishment, improving upon the stealth address proposal. However, there is no solution presented for scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses.Overall, payment codes offer SPV-friendly alternatives to stealth addresses with features like sender identification and automatic transaction refunds. They require less blockchain data storage compared to stealth addresses but face challenges in terms of privacy and data efficiency. The provided link contains an RFC detailing the payment code proposal. 2015-10-23T15:57:14+00:00 + In October 2015, there was a discussion on the bitcoin-dev mailing list about Bitcoin Improvement Proposal (BIP) version 1. Luke Dashjr disagreed with adopting the proposal as is because multi-push OP_RETURN outputs were not standard transactions and could not be relied upon for network relay. He suggested waiting for additional capabilities to be deployed in the network before specifying a version 2 payment code. Justus Ranvier argued that version 1 payment codes were designed to be deployable without requiring network-level changes and acknowledged that multi-push OP_RETURN outputs would be standard in v0.12.0 of Bitcoin.Luke Dashjr expressed concerns about the "notification address" requirement in a proposal, as it would lead to address reuse and blockchain spam. He suggested using a single zero-value OP_RETURN output with two pushes instead. Justus Ranvier acknowledged that this portion of the proposal was not ideal but emphasized the goal of making the proposal usable on as many mobile/light wallets as possible. Dashjr argued that BIPs should not be designed around current software and that software upgrades are necessary regardless.There was also an email exchange regarding BIP 63, where Peter Todd expressed his inclination to shelve work on it due to other priorities. Several people offered to send donations to advance the BIP, but no donation address was posted. Todd suggested that someone else could take up the work if interested.Justus Ranvier shared an RFC on April 24, 2015, for a new type of Bitcoin address called a payment code. Payment codes are SPV-friendly alternatives to stealth addresses that positively identify senders to recipients and require less blockchain data storage. They can be publicly advertised without compromising financial privacy. Luke Dashjr expressed concerns about the "notification address" requirement in the proposal, suggesting an alternative approach using a single zero-value OP_RETURN output with two pushes.The concept of identity in relation to payment codes was discussed, with the understanding that it refers to a specific extended public/private key pair rather than conventional personal information. The discussion also touched on privacy concerns in SPV clients and suggested measures such as connecting exclusively through Tor and using varying bloom filters to enhance privacy.Brian Deery expressed worries about payment codes, particularly regarding the explicit tying of identities to them and the potential for identity linkage in bloom filter clients. There were suggestions for improving privacy in SPV clients by using multiple peers, filtering subsets of addresses, and varying the addresses being monitored.One of the main challenges with payment codes is that they rely on making dust payments to a constantly reused address, which undermines the privacy it aims to provide. This method also doubles the data sent for one-time anonymous donations. To address these issues, Brian suggests some ideas such as using even or odd DER encoding to save bytes and deriving the chain value from the x value to save more bytes. Another suggestion is to encode the "x value" into the signature's R value to make the transaction appear like a standard bitcoin transaction and eliminate the need for op_return.In terms of privacy, Brian proposes the concept of a common meeting point where the receiver of the payment code would trial-decode all payment codes sent to a pre-specified dead drop address, such as a charity address. This would require more effort from the receiver but would provide privacy regarding the number of people interacting with them.The proposed payment code scheme establishes a shared chain once and does not require reestablishment, improving upon the stealth address proposal. However, there is no solution presented for scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses.Overall, payment codes offer SPV-friendly alternatives to stealth addresses with features like sender identification and automatic transaction refunds. They require less blockchain data storage compared to stealth addresses but face challenges in terms of privacy and data efficiency. The provided link contains an RFC detailing the payment code proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Scaling-Bitcoin-with-Subchains.xml b/static/bitcoin-dev/June_2015/combined_Scaling-Bitcoin-with-Subchains.xml index 2112c45a74..d6d5ddce19 100644 --- a/static/bitcoin-dev/June_2015/combined_Scaling-Bitcoin-with-Subchains.xml +++ b/static/bitcoin-dev/June_2015/combined_Scaling-Bitcoin-with-Subchains.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Scaling Bitcoin with Subchains - 2023-08-01T12:46:53.338981+00:00 + 2025-10-11T21:37:45.146184+00:00 + python-feedgen Andrew 2015-06-16 19:04:44+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Scaling Bitcoin with Subchains - 2023-08-01T12:46:53.339983+00:00 + 2025-10-11T21:37:45.146368+00:00 - The email thread discussed various proposals and ideas to scale blockchain technology, specifically focusing on Bitcoin. One proposal suggested merge-mining, where the parent chain includes the hashes of its children's headers as transactions. This would incentivize parents to validate their children by collecting fees from them. Another proposal suggested a treechain-like subchain system, where miners can only mine certain parts of the tree to ensure fairness. However, no solid design has been developed yet for this approach.The discussion also touched on the possibility of increasing the block size limit through a soft fork with sidechains in the future. Sidechains were seen as a way to achieve horizontal scaling and sharding while maintaining the primary security parameters of the main chain. However, some participants argued that sidechains do not offer a useful compromise between validation and non-validation. They believed that validation should either be done for everything or not at all. Concerns were also expressed about the complexity and delays introduced by sidechains.There was also a debate about the importance of validation in blockchain technology. Some argued that validation is necessary for all transactions, while others suggested probabilistic verification or validating a random subset of scripts. The consensus was that sidechains are not a solution for scaling up blockchain technology.The participants discussed the advantages and disadvantages of different proposals, such as storing only headers or full blocks, filtering transactions based on criteria, and the risk of pruned nodes. They emphasized the need for a proper system that ensures decentralization, security, and scalability.The email thread focused on a proposal by Andrew Poelstra to scale Bitcoin without increasing the block size. The proposal suggested creating child chains linked to the main blockchain, which would increase the network's total capacity for storing transactions. The proposal aimed to promote decentralization by allowing participants to produce the necessary devices without relying on centralized powers.While some developers supported the proposal and offered suggestions for implementation, others raised concerns and objections. Specific sidechain problems mentioned in previous research were brought up as potential issues. Gavin Andresen objected to the proposal without providing an explanation for his objections. Mike Hearn expressed concerns about the costs and limitations of hard drives and proposed tape backup as a more viable storage option. He also questioned Poelstra's motivations, wondering if they stemmed from philosophical beliefs or self-interest.In response to Andrew's concern regarding Bitcoin's reliance on hard disk storage, another participant suggested using tape backup technology instead. They provided a link to an article about Sony's development of tape technology capable of storing 185 terabytes per cartridge. While sharing the cost of a blockchain archive with others was not seen as a significant concern, caution was advised against validating the chain on compromised computers.To address the block size limit increase problem, the author proposed a partitioned system with ten 1 MB chains below the main chain. This arrangement would allow larger transactions to be processed through the top chain, while middle and small-sized transactions would be verified by one of the middle or bottom chains respectively. Regular users would be able to store lifetime transactions on a 5 TB drive. Additionally, the author suggested that people should be able to validate all blocks rather than just a pruned part to counter compromised machines. This would enable individuals to access information about Bitcoin transactions comparable to large data centers, potentially exposing government or corporate corruption.In terms of implementation, the author proposed keeping the current chain as the top chain and creating ten level 2 chains that also store Bitcoin. To incentivize people to continue mining on the level 1 chain, the author suggested forcing it into the protocol that anyone mining on level 2 must also mine on level 1, with a similar requirement for subsequent levels. Even if people stop using level 1, any owned bitcoin in the level 1 chain can be transferred to level 2 while still maintaining 1 MB blocks due to the partitioning scheme. The author acknowledged having only a high-level understanding of the Bitcoin protocol but believed that his proposal could work with a soft fork.In conclusion, the email thread explored various proposals and ideas to scale blockchain technology, particularly focusing on Bitcoin. Different approaches, such as merge-mining, treechain-like subchains, and sidechains, were discussed, along with their potential benefits and challenges. While no definitive solution was reached, the participants acknowledged the importance of ongoing research and development in this area to address scalability, validation, mining decentralization, and security concerns. 2015-06-16T19:04:44+00:00 + The email thread discussed various proposals and ideas to scale blockchain technology, specifically focusing on Bitcoin. One proposal suggested merge-mining, where the parent chain includes the hashes of its children's headers as transactions. This would incentivize parents to validate their children by collecting fees from them. Another proposal suggested a treechain-like subchain system, where miners can only mine certain parts of the tree to ensure fairness. However, no solid design has been developed yet for this approach.The discussion also touched on the possibility of increasing the block size limit through a soft fork with sidechains in the future. Sidechains were seen as a way to achieve horizontal scaling and sharding while maintaining the primary security parameters of the main chain. However, some participants argued that sidechains do not offer a useful compromise between validation and non-validation. They believed that validation should either be done for everything or not at all. Concerns were also expressed about the complexity and delays introduced by sidechains.There was also a debate about the importance of validation in blockchain technology. Some argued that validation is necessary for all transactions, while others suggested probabilistic verification or validating a random subset of scripts. The consensus was that sidechains are not a solution for scaling up blockchain technology.The participants discussed the advantages and disadvantages of different proposals, such as storing only headers or full blocks, filtering transactions based on criteria, and the risk of pruned nodes. They emphasized the need for a proper system that ensures decentralization, security, and scalability.The email thread focused on a proposal by Andrew Poelstra to scale Bitcoin without increasing the block size. The proposal suggested creating child chains linked to the main blockchain, which would increase the network's total capacity for storing transactions. The proposal aimed to promote decentralization by allowing participants to produce the necessary devices without relying on centralized powers.While some developers supported the proposal and offered suggestions for implementation, others raised concerns and objections. Specific sidechain problems mentioned in previous research were brought up as potential issues. Gavin Andresen objected to the proposal without providing an explanation for his objections. Mike Hearn expressed concerns about the costs and limitations of hard drives and proposed tape backup as a more viable storage option. He also questioned Poelstra's motivations, wondering if they stemmed from philosophical beliefs or self-interest.In response to Andrew's concern regarding Bitcoin's reliance on hard disk storage, another participant suggested using tape backup technology instead. They provided a link to an article about Sony's development of tape technology capable of storing 185 terabytes per cartridge. While sharing the cost of a blockchain archive with others was not seen as a significant concern, caution was advised against validating the chain on compromised computers.To address the block size limit increase problem, the author proposed a partitioned system with ten 1 MB chains below the main chain. This arrangement would allow larger transactions to be processed through the top chain, while middle and small-sized transactions would be verified by one of the middle or bottom chains respectively. Regular users would be able to store lifetime transactions on a 5 TB drive. Additionally, the author suggested that people should be able to validate all blocks rather than just a pruned part to counter compromised machines. This would enable individuals to access information about Bitcoin transactions comparable to large data centers, potentially exposing government or corporate corruption.In terms of implementation, the author proposed keeping the current chain as the top chain and creating ten level 2 chains that also store Bitcoin. To incentivize people to continue mining on the level 1 chain, the author suggested forcing it into the protocol that anyone mining on level 2 must also mine on level 1, with a similar requirement for subsequent levels. Even if people stop using level 1, any owned bitcoin in the level 1 chain can be transferred to level 2 while still maintaining 1 MB blocks due to the partitioning scheme. The author acknowledged having only a high-level understanding of the Bitcoin protocol but believed that his proposal could work with a soft fork.In conclusion, the email thread explored various proposals and ideas to scale blockchain technology, particularly focusing on Bitcoin. Different approaches, such as merge-mining, treechain-like subchains, and sidechains, were discussed, along with their potential benefits and challenges. While no definitive solution was reached, the participants acknowledged the importance of ongoing research and development in this area to address scalability, validation, mining decentralization, and security concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Test.xml b/static/bitcoin-dev/June_2015/combined_Test.xml index 27798a8b61..cb5fa21dfc 100644 --- a/static/bitcoin-dev/June_2015/combined_Test.xml +++ b/static/bitcoin-dev/June_2015/combined_Test.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Test - 2023-08-01T13:19:34.810605+00:00 + 2025-10-11T21:38:48.884997+00:00 + python-feedgen Johnathan Corgan 2015-06-22 17:45:44+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Test - 2023-08-01T13:19:34.810605+00:00 + 2025-10-11T21:38:48.885163+00:00 - Recently, Johnathan Corgan from Corgan Labs posted a message on an online platform stating that Ivan is hiding a message in oak. The context of the message and the relationship between Johnathan and Ivan are not clear from the post.Corgan Labs is a company that provides SDR (Sales Development Representative) training and development services. It is unclear whether the message hidden by Ivan is related to the business operations of Corgan Labs or is something personal.Additionally, it is not specified how Johnathan came to know about this hidden message or what steps he plans to take in response to it. The post includes a link to the official website of Corgan Labs, which provides information about their services, team members, and testimonials from clients. However, the website does not offer any further insight into the context of the message hidden by Ivan in oak.Overall, the post by Johnathan Corgan raises more questions than it answers, leaving readers to wonder about the significance of the hidden message and its potential impact on Corgan Labs or other parties involved. 2015-06-22T17:45:44+00:00 + Recently, Johnathan Corgan from Corgan Labs posted a message on an online platform stating that Ivan is hiding a message in oak. The context of the message and the relationship between Johnathan and Ivan are not clear from the post.Corgan Labs is a company that provides SDR (Sales Development Representative) training and development services. It is unclear whether the message hidden by Ivan is related to the business operations of Corgan Labs or is something personal.Additionally, it is not specified how Johnathan came to know about this hidden message or what steps he plans to take in response to it. The post includes a link to the official website of Corgan Labs, which provides information about their services, team members, and testimonials from clients. However, the website does not offer any further insight into the context of the message hidden by Ivan in oak.Overall, the post by Johnathan Corgan raises more questions than it answers, leaving readers to wonder about the significance of the hidden message and its potential impact on Corgan Labs or other parties involved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_The-Bitcoin-Node-Market.xml b/static/bitcoin-dev/June_2015/combined_The-Bitcoin-Node-Market.xml index bfc32b488b..f19bb26cd9 100644 --- a/static/bitcoin-dev/June_2015/combined_The-Bitcoin-Node-Market.xml +++ b/static/bitcoin-dev/June_2015/combined_The-Bitcoin-Node-Market.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The Bitcoin Node Market - 2023-08-01T13:20:10.033050+00:00 + 2025-10-11T21:37:28.154187+00:00 + python-feedgen Aaron Voisine 2015-06-16 17:22:54+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - The Bitcoin Node Market - 2023-08-01T13:20:10.033050+00:00 + 2025-10-11T21:37:28.154379+00:00 - The proposal suggests implementing a market-based approach to cover the costs of running nodes on the Bitcoin Network. This approach would involve charging fees for connecting to the network and sharing the financial burden among all users, including those who do not run full nodes.However, there are concerns about the impact this could have on user experience and the potential for centralization. Charging fees for SPV wallets to connect to the network may confuse and frustrate users, potentially leading them to switch to centralized wallet services that do not require such fees. Additionally, the requirement to tie up outputs every time a wallet is opened could hinder users from making timely payments.Despite these concerns, the goal of the proposal is to create a sustainable model for running full nodes on the Bitcoin Network. By sharing the cost among users and developing a market for connectivity fees, the aim is to ensure the long-term viability and profitability of running nodes while maintaining decentralization and a positive user experience.Under the new system, fees will be developed to cover the expenses of maintaining the network. Nodes will collect the necessary funds required to sustain the functionality of the network, aligning the fees with the actual expenses incurred. However, nodes still have the option to offer free access to the Bitcoin network if they choose to do so. This flexibility allows nodes to cater to different user preferences and potentially attract more users by offering a cost-free connection.Overall, the goal of the new system is to ensure the sustainability of the Bitcoin network by distributing the costs of running it among all users. While fees will be implemented, nodes can still choose to provide free access. This approach is expected to lead to market efficiencies, as nodes will only collect the necessary funds to keep the network operational. 2015-06-16T17:22:54+00:00 + The proposal suggests implementing a market-based approach to cover the costs of running nodes on the Bitcoin Network. This approach would involve charging fees for connecting to the network and sharing the financial burden among all users, including those who do not run full nodes.However, there are concerns about the impact this could have on user experience and the potential for centralization. Charging fees for SPV wallets to connect to the network may confuse and frustrate users, potentially leading them to switch to centralized wallet services that do not require such fees. Additionally, the requirement to tie up outputs every time a wallet is opened could hinder users from making timely payments.Despite these concerns, the goal of the proposal is to create a sustainable model for running full nodes on the Bitcoin Network. By sharing the cost among users and developing a market for connectivity fees, the aim is to ensure the long-term viability and profitability of running nodes while maintaining decentralization and a positive user experience.Under the new system, fees will be developed to cover the expenses of maintaining the network. Nodes will collect the necessary funds required to sustain the functionality of the network, aligning the fees with the actual expenses incurred. However, nodes still have the option to offer free access to the Bitcoin network if they choose to do so. This flexibility allows nodes to cater to different user preferences and potentially attract more users by offering a cost-free connection.Overall, the goal of the new system is to ensure the sustainability of the Bitcoin network by distributing the costs of running it among all users. While fees will be implemented, nodes can still choose to provide free access. This approach is expected to lead to market efficiencies, as nodes will only collect the necessary funds to keep the network operational. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_The-need-for-larger-blocks.xml b/static/bitcoin-dev/June_2015/combined_The-need-for-larger-blocks.xml index 7356620ee8..876f4cd42c 100644 --- a/static/bitcoin-dev/June_2015/combined_The-need-for-larger-blocks.xml +++ b/static/bitcoin-dev/June_2015/combined_The-need-for-larger-blocks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The need for larger blocks - 2023-08-01T14:00:18.445572+00:00 + 2025-10-11T21:37:13.294965+00:00 + python-feedgen Aaron Voisine 2015-06-28 20:56:20+00:00 @@ -247,13 +248,13 @@ - python-feedgen + 2 Combined summary - The need for larger blocks - 2023-08-01T14:00:18.446571+00:00 + 2025-10-11T21:37:13.295235+00:00 - In a discussion on the Bitcoin-dev mailing list, members expressed concerns about the decision-making process for controversial changes to Bitcoin. They debated whether it was appropriate to rely on a single person to determine what is considered controversial, as this could be influenced by a vocal minority. It was suggested that proposals should be made after things have "cooled down" to avoid unnecessary controversy. The conversation referenced the phrase "I know it when I see it," which originated from a US Supreme Court ruling and has since been used to describe subjective judgments.Some members discussed the risks of both "doing nothing" and increasing the block size limit. They noted that gauging the majority's preference is difficult before something actually happens. There were varying perceptions of the risks, but it was suggested that conducting a "software fork" would be the only way to determine how many people are in favor of bigger blocks. The question of whether the majority has the right to dictate to the minority was deemed complex and advised to be left out of the discussion.The debate over increasing the block size limit highlighted a contradiction between the economic policy of avoiding fee pressure and the consensus status quo of not having a hard fork. Some argued that maintaining the status quo without changing either the policy or consensus rules is not possible. It was suggested that making changes to the policy code of different implementations would be closer to "maintaining the status quo" than a hard fork. However, increasing the block size without addressing underlying problems was considered a "lazy option" that could leave implementations unprepared for new rules.There were discussions on the possibility of uncontroversial hardforks and the need to propose them to see if they are viable. It was mentioned that minor issues planned for the long term or non-politically loaded features could be considered for hardforks. Additionally, major emergencies that exploit coin holders or miners could warrant a hard fork. Non-critical and non-controversial hardforks could even be planned and time-locked up to five years ahead, eliminating the need for quick client upgrades.The issue of whether Bitcoin needs to scale to business or vice versa was debated. The writer argued that Bitcoin already has utility and that increased adoption does not necessarily increase its value. They cautioned against sacrificing decentralization to big business and advocated for holding steady while doing necessary research. It was suggested that Bitcoin should be seen as a solution when things go wrong for ordinary users, rather than fitting into existing business models.In an email exchange, Wladimir J. van der Laan expressed hostility towards hardforks after recent stressful conditions. He suggested that hardforks must be possible if they are uncontroversial and give enough time for users and alternative software to upgrade. However, politically loaded changes were advised to be avoided. The article also compared the debate over block size to limiting planes' wingspan to old hangar doors, which caused controversy as modern planes may not fit. The writer argued for facing reality instead of creating false expectations.In discussions on blockchains, it was suggested that they can go beyond value tokens to determine consensus among users. The role of developers in making economic decisions for Bitcoin's growth was emphasized. The question of whether Bitcoin should compete with existing payment networks or define its own network was raised. It was argued that developers have a crucial role in implementing economic policy and that multinational or government-sponsored entities dominating the blockchain do not mean that Bitcoin has been surrendered to the "free market."In an email conversation, Pieter Wuille and Wladimir J. van der Laan expressed their views on larger blocks in Bitcoin's blockchain. They disagreed on the necessity of larger blocks due to fear of changes in economics. They found political pressure tactics used to change the consensus system concerning and stressed that developers work on technical improvements, not governing the system. They expressed hostility towards hardforks that make politically loaded changes and emphasized the importance of resiliency and decentralization.In discussions on the Bitcoin-dev mailing list, ideas were proposed to create websites displaying current mempool backlogs and fees needed to prioritize transactions. Standardizing reporting "delay alerts" in wallets was also suggested to inform users about potential issues during periods of increased transaction volume. The importance of communication between senders and receivers regarding transaction delays and confirmations was highlighted.Overall, the context highlights the ongoing debate about increasing the block size in Bitcoin. Different perspectives are presented, with some arguing for larger blocks to increase utility and accommodate growing usage, while others emphasize the importance of careful consideration, decentralization, and understanding the risks involved. The need for a clear path and schedule to accomplish changes is also mentioned, as well as concerns about centralization risk and the impact on the blockchain network.In the context provided, there is a disagreement between Gavin and Pieter regarding the idea of increasing block sizes in Bitcoin. Gavin argues that a fear of change does not necessitate larger blocks, as it could lead to an unlimited growth similar to infinite copyright terms. He warns about the consequences of 2015-06-28T20:56:20+00:00 + In a discussion on the Bitcoin-dev mailing list, members expressed concerns about the decision-making process for controversial changes to Bitcoin. They debated whether it was appropriate to rely on a single person to determine what is considered controversial, as this could be influenced by a vocal minority. It was suggested that proposals should be made after things have "cooled down" to avoid unnecessary controversy. The conversation referenced the phrase "I know it when I see it," which originated from a US Supreme Court ruling and has since been used to describe subjective judgments.Some members discussed the risks of both "doing nothing" and increasing the block size limit. They noted that gauging the majority's preference is difficult before something actually happens. There were varying perceptions of the risks, but it was suggested that conducting a "software fork" would be the only way to determine how many people are in favor of bigger blocks. The question of whether the majority has the right to dictate to the minority was deemed complex and advised to be left out of the discussion.The debate over increasing the block size limit highlighted a contradiction between the economic policy of avoiding fee pressure and the consensus status quo of not having a hard fork. Some argued that maintaining the status quo without changing either the policy or consensus rules is not possible. It was suggested that making changes to the policy code of different implementations would be closer to "maintaining the status quo" than a hard fork. However, increasing the block size without addressing underlying problems was considered a "lazy option" that could leave implementations unprepared for new rules.There were discussions on the possibility of uncontroversial hardforks and the need to propose them to see if they are viable. It was mentioned that minor issues planned for the long term or non-politically loaded features could be considered for hardforks. Additionally, major emergencies that exploit coin holders or miners could warrant a hard fork. Non-critical and non-controversial hardforks could even be planned and time-locked up to five years ahead, eliminating the need for quick client upgrades.The issue of whether Bitcoin needs to scale to business or vice versa was debated. The writer argued that Bitcoin already has utility and that increased adoption does not necessarily increase its value. They cautioned against sacrificing decentralization to big business and advocated for holding steady while doing necessary research. It was suggested that Bitcoin should be seen as a solution when things go wrong for ordinary users, rather than fitting into existing business models.In an email exchange, Wladimir J. van der Laan expressed hostility towards hardforks after recent stressful conditions. He suggested that hardforks must be possible if they are uncontroversial and give enough time for users and alternative software to upgrade. However, politically loaded changes were advised to be avoided. The article also compared the debate over block size to limiting planes' wingspan to old hangar doors, which caused controversy as modern planes may not fit. The writer argued for facing reality instead of creating false expectations.In discussions on blockchains, it was suggested that they can go beyond value tokens to determine consensus among users. The role of developers in making economic decisions for Bitcoin's growth was emphasized. The question of whether Bitcoin should compete with existing payment networks or define its own network was raised. It was argued that developers have a crucial role in implementing economic policy and that multinational or government-sponsored entities dominating the blockchain do not mean that Bitcoin has been surrendered to the "free market."In an email conversation, Pieter Wuille and Wladimir J. van der Laan expressed their views on larger blocks in Bitcoin's blockchain. They disagreed on the necessity of larger blocks due to fear of changes in economics. They found political pressure tactics used to change the consensus system concerning and stressed that developers work on technical improvements, not governing the system. They expressed hostility towards hardforks that make politically loaded changes and emphasized the importance of resiliency and decentralization.In discussions on the Bitcoin-dev mailing list, ideas were proposed to create websites displaying current mempool backlogs and fees needed to prioritize transactions. Standardizing reporting "delay alerts" in wallets was also suggested to inform users about potential issues during periods of increased transaction volume. The importance of communication between senders and receivers regarding transaction delays and confirmations was highlighted.Overall, the context highlights the ongoing debate about increasing the block size in Bitcoin. Different perspectives are presented, with some arguing for larger blocks to increase utility and accommodate growing usage, while others emphasize the importance of careful consideration, decentralization, and understanding the risks involved. The need for a clear path and schedule to accomplish changes is also mentioned, as well as concerns about centralization risk and the impact on the blockchain network.In the context provided, there is a disagreement between Gavin and Pieter regarding the idea of increasing block sizes in Bitcoin. Gavin argues that a fear of change does not necessitate larger blocks, as it could lead to an unlimited growth similar to infinite copyright terms. He warns about the consequences of - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Tough-questions-for-Peter-Todd-Chief-Scientist-Mastercoin-Counterparty-Coinkite-Darkwallet-Viacoin-.xml b/static/bitcoin-dev/June_2015/combined_Tough-questions-for-Peter-Todd-Chief-Scientist-Mastercoin-Counterparty-Coinkite-Darkwallet-Viacoin-.xml index 9b67f9868d..f33ab8b2ad 100644 --- a/static/bitcoin-dev/June_2015/combined_Tough-questions-for-Peter-Todd-Chief-Scientist-Mastercoin-Counterparty-Coinkite-Darkwallet-Viacoin-.xml +++ b/static/bitcoin-dev/June_2015/combined_Tough-questions-for-Peter-Todd-Chief-Scientist-Mastercoin-Counterparty-Coinkite-Darkwallet-Viacoin-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Tough questions for Peter Todd, Chief Scientist {Mastercoin | Counterparty | Coinkite | Darkwallet | Viacoin} - 2023-08-01T13:02:48.845369+00:00 + 2025-10-11T21:38:44.637275+00:00 + python-feedgen Jeff Garzik 2015-06-04 22:39:25+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Tough questions for Peter Todd, Chief Scientist {Mastercoin | Counterparty | Coinkite | Darkwallet | Viacoin} - 2023-08-01T13:02:48.845369+00:00 + 2025-10-11T21:38:44.637435+00:00 - In a series of email exchanges, several individuals engage in discussions and inquiries related to various topics within the Bitcoin community. One exchange involves Daniel Stadulis, who made an off-topic and inappropriate comment that was criticized by Jeff Garzik, a Bitcoin core developer. Garzik's response suggests that Stadulis's original message was not suitable for a technical mailing list. It is worth noting that Garzik includes a signature indicating his role as a BitPay employee and providing a link to the company's website.Another email exchange between Sven Berg and Kr focuses on specific questions regarding the accountability of Peter. Berg seeks information such as the number of hours worked per project out of a 40-hour work week, upfront and ongoing fees for using Peter's name, total amounts allocated for each project, start and end dates of contracts, current and past holdings of altcoins/appcoins, return on investment to investors related to Peter's activities excluding marketing/price pump, involvement in Initial Coin Offers (ICO), and rationale for pursuing ICO fund sources instead of community or established businesses. These questions are posed in relation to the Bitcoin-development mailing list.There is also an email conversation between Braun Brelin and Todd, in which Brelin asks if Todd is a federal prosecutor, state prosecutor, or involved in law enforcement or civil suits against Mr. Todd. Depending on Todd's response, these parties may become involved. Todd's response to these questions is deemed inappropriate, using offensive language.A separate email thread between Mark Friedenbach and Sven Berg discusses Todd's involvement in "shady projects" and his refusal to answer reasonable questions regarding his participation in scams and failures elsewhere. Berg Investigations LLC expresses concern about the lack of transparency when someone prominent is associated with numerous dubious projects resulting in significant losses, such as the failure of DarkWallet. However, Braun Brelin responds to these inquiries by asking if they are federal or state prosecutors, involved in law enforcement, or engaged in civil suits against Mr. Todd before telling them to "F*** off."In another discussion thread on June 4, 2015, Mark Friedenbach questions the relevance of a topic being discussed in a mailing list. The discussion revolves around accusations against someone named Todd for their involvement in various shady projects and scams, including the failure of DarkWallet. Berg Investigations LLC expresses its belief that the community deserves answers when such prominent individuals are associated with such activities. However, no clear resolution or response is provided regarding this topic.Furthermore, one email conversation within the thread is considered off-topic and inappropriate for the Bitcoin-development mailing list. One individual poses a series of questions related to a project, but another member questions why these inquiries matter to anyone on the list. Additionally, it is observed that all anti-Todd comments originate from *@airmail.cc accounts, although the significance or relevance of this observation remains unclear.Overall, the context provides a list of information that Berg Investigations LLC requires from an individual. This includes details such as the number of hours dedicated to each project per week, upfront and ongoing fees, total amounts allocated for each project, contract start and end dates, current and past holdings of altcoins/appcoins, liquidation dates, return on investment to investors unrelated to marketing/price pump activities, involvement in Initial Coin Offers (ICO), and an explanation for pursuing ICO fund sources instead of community or established businesses. It is also mentioned that this discussion should be taken elsewhere as it is not relevant to the business of those participating in the mailing list. 2015-06-04T22:39:25+00:00 + In a series of email exchanges, several individuals engage in discussions and inquiries related to various topics within the Bitcoin community. One exchange involves Daniel Stadulis, who made an off-topic and inappropriate comment that was criticized by Jeff Garzik, a Bitcoin core developer. Garzik's response suggests that Stadulis's original message was not suitable for a technical mailing list. It is worth noting that Garzik includes a signature indicating his role as a BitPay employee and providing a link to the company's website.Another email exchange between Sven Berg and Kr focuses on specific questions regarding the accountability of Peter. Berg seeks information such as the number of hours worked per project out of a 40-hour work week, upfront and ongoing fees for using Peter's name, total amounts allocated for each project, start and end dates of contracts, current and past holdings of altcoins/appcoins, return on investment to investors related to Peter's activities excluding marketing/price pump, involvement in Initial Coin Offers (ICO), and rationale for pursuing ICO fund sources instead of community or established businesses. These questions are posed in relation to the Bitcoin-development mailing list.There is also an email conversation between Braun Brelin and Todd, in which Brelin asks if Todd is a federal prosecutor, state prosecutor, or involved in law enforcement or civil suits against Mr. Todd. Depending on Todd's response, these parties may become involved. Todd's response to these questions is deemed inappropriate, using offensive language.A separate email thread between Mark Friedenbach and Sven Berg discusses Todd's involvement in "shady projects" and his refusal to answer reasonable questions regarding his participation in scams and failures elsewhere. Berg Investigations LLC expresses concern about the lack of transparency when someone prominent is associated with numerous dubious projects resulting in significant losses, such as the failure of DarkWallet. However, Braun Brelin responds to these inquiries by asking if they are federal or state prosecutors, involved in law enforcement, or engaged in civil suits against Mr. Todd before telling them to "F*** off."In another discussion thread on June 4, 2015, Mark Friedenbach questions the relevance of a topic being discussed in a mailing list. The discussion revolves around accusations against someone named Todd for their involvement in various shady projects and scams, including the failure of DarkWallet. Berg Investigations LLC expresses its belief that the community deserves answers when such prominent individuals are associated with such activities. However, no clear resolution or response is provided regarding this topic.Furthermore, one email conversation within the thread is considered off-topic and inappropriate for the Bitcoin-development mailing list. One individual poses a series of questions related to a project, but another member questions why these inquiries matter to anyone on the list. Additionally, it is observed that all anti-Todd comments originate from *@airmail.cc accounts, although the significance or relevance of this observation remains unclear.Overall, the context provides a list of information that Berg Investigations LLC requires from an individual. This includes details such as the number of hours dedicated to each project per week, upfront and ongoing fees, total amounts allocated for each project, contract start and end dates, current and past holdings of altcoins/appcoins, liquidation dates, return on investment to investors unrelated to marketing/price pump activities, involvement in Initial Coin Offers (ICO), and an explanation for pursuing ICO fund sources instead of community or established businesses. It is also mentioned that this discussion should be taken elsewhere as it is not relevant to the business of those participating in the mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Upcoming-DOS-vulnerability-announcements-for-Bitcoin-Core.xml b/static/bitcoin-dev/June_2015/combined_Upcoming-DOS-vulnerability-announcements-for-Bitcoin-Core.xml index 1b807ba61f..e496c092b2 100644 --- a/static/bitcoin-dev/June_2015/combined_Upcoming-DOS-vulnerability-announcements-for-Bitcoin-Core.xml +++ b/static/bitcoin-dev/June_2015/combined_Upcoming-DOS-vulnerability-announcements-for-Bitcoin-Core.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Upcoming DOS vulnerability announcements for Bitcoin Core - 2023-08-01T14:00:35.965534+00:00 + 2025-10-11T21:38:34.008019+00:00 + python-feedgen Gregory Maxwell 2015-07-07 23:14:18+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Upcoming DOS vulnerability announcements for Bitcoin Core - 2023-08-01T14:00:35.965534+00:00 + 2025-10-11T21:38:34.008113+00:00 - On July 7th, 2015, Gregory Maxwell announced that he would disclose several serious denial of service vulnerabilities in Bitcoin Core, including CVE-2015-3641. He strongly recommended upgrading to version 0.10.2 as soon as possible for production nodes exposed to inbound internet connections. Older systems, especially miners, should also be upgraded due to the impending BIP66 soft-fork reaching enforcing status. However, the announcement was delayed due to network turbulence and attempted DOS attack activity on relayed infrastructure. Other cryptocurrency implementers requested a longer horizon for the disclosure.On June 27th, 2015, Jameson Lopp mentioned the release notes for Bitcoin version 0.10.2, noting that it only had significant changes for Windows. This explains why the Ubuntu PPA does not carry 0.10.2. Thomas Pryds asked when or if 0.10.2 would be available on the Ubuntu PPA, expressing a preference for the convenience of using a PPA rather than installing manually. Gregory Maxwell reiterated his recommendation of upgrading to 0.10.2 for production nodes exposed to inbound internet connections.On the same day, Gregory Maxwell shared a link to the Bitcoin-dev mailing list. The link leads to a message written by Wladimir, the lead developer of Bitcoin Core, discussing the importance of rigorous testing for new releases. Wladimir emphasized that proper testing is crucial to ensure stability and reliability. He highlighted the improved testing process with automated tools and a team of dedicated testers. Wladimir called for more developers, particularly those experienced in software testing, to contribute to the testing effort. He encouraged interested developers to reach out to the Bitcoin Core team and get involved. Overall, Wladimir's message emphasized the collaborative nature of open-source software development and the importance of testing in Bitcoin Core's development.To learn more about the disclosed denial of service vulnerabilities and the recommended upgrade to version 0.10.2, refer to the SourceForge link provided. 2015-07-07T23:14:18+00:00 + On July 7th, 2015, Gregory Maxwell announced that he would disclose several serious denial of service vulnerabilities in Bitcoin Core, including CVE-2015-3641. He strongly recommended upgrading to version 0.10.2 as soon as possible for production nodes exposed to inbound internet connections. Older systems, especially miners, should also be upgraded due to the impending BIP66 soft-fork reaching enforcing status. However, the announcement was delayed due to network turbulence and attempted DOS attack activity on relayed infrastructure. Other cryptocurrency implementers requested a longer horizon for the disclosure.On June 27th, 2015, Jameson Lopp mentioned the release notes for Bitcoin version 0.10.2, noting that it only had significant changes for Windows. This explains why the Ubuntu PPA does not carry 0.10.2. Thomas Pryds asked when or if 0.10.2 would be available on the Ubuntu PPA, expressing a preference for the convenience of using a PPA rather than installing manually. Gregory Maxwell reiterated his recommendation of upgrading to 0.10.2 for production nodes exposed to inbound internet connections.On the same day, Gregory Maxwell shared a link to the Bitcoin-dev mailing list. The link leads to a message written by Wladimir, the lead developer of Bitcoin Core, discussing the importance of rigorous testing for new releases. Wladimir emphasized that proper testing is crucial to ensure stability and reliability. He highlighted the improved testing process with automated tools and a team of dedicated testers. Wladimir called for more developers, particularly those experienced in software testing, to contribute to the testing effort. He encouraged interested developers to reach out to the Bitcoin Core team and get involved. Overall, Wladimir's message emphasized the collaborative nature of open-source software development and the importance of testing in Bitcoin Core's development.To learn more about the disclosed denial of service vulnerabilities and the recommended upgrade to version 0.10.2, refer to the SourceForge link provided. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_User-vote-in-blocksize-through-fees.xml b/static/bitcoin-dev/June_2015/combined_User-vote-in-blocksize-through-fees.xml index a931bb8280..9ce038c152 100644 --- a/static/bitcoin-dev/June_2015/combined_User-vote-in-blocksize-through-fees.xml +++ b/static/bitcoin-dev/June_2015/combined_User-vote-in-blocksize-through-fees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - User vote in blocksize through fees - 2023-08-01T13:14:09.144939+00:00 + 2025-10-11T21:39:14.373828+00:00 + python-feedgen Eric Lombrozo 2015-06-15 03:59:05+00:00 @@ -171,13 +172,13 @@ - python-feedgen + 2 Combined summary - User vote in blocksize through fees - 2023-08-01T13:14:09.145939+00:00 + 2025-10-11T21:39:14.374054+00:00 - The ongoing discussion on block size limits in Bitcoin revolves around the consensus that the limit needs to be increased. However, there are differing opinions on how this should be done and what the limit should be. Jeff Garzik suggests a mechanism for determining the limit through miner voting, transitioning the decision-making process from software developers to the free market. Eric Lombrozo proposes a voting system for metaconsensus to address higher-level governance problems.The economic consequences of the block size limit decision are also highlighted in the discussions. The size limit defines the fee market and directly impacts miners, developers, and users. Various proposals have been made, but none have fully addressed the fundamental question of how to redesign this aspect of Bitcoin. This raises concerns over corruptibility and the need for proper consensus.The overall goal is to find a solution that allows users to have a say in the block size limit while ensuring the stability and decentralization of the Bitcoin network. Transitioning from software-based decision-making to a free market approach is seen as a way to achieve this. However, there are still many factors to consider, such as the economic policy lever, fee calculation heuristics, and the potential impact on business models and user adoption.In conclusion, the block size limit controversy in Bitcoin sparks discussions about economic policy, governance, and the transition from software to the free market. The consensus is that the limit needs to be increased, but there are debates about the best approach and the potential consequences. The discussions highlight the need for a voting system for metaconsensus and the importance of considering the economic implications of any changes made.One proposal suggests removing the block size limit entirely and enforcing a "soft" limit through miner voting. Users would have influence over the miner vote through transactions casting a specific vote. Another proposal suggests using proof-of-stake blocksize voting. There are debates about whether users should have a say in block size limits, with some arguing that it should be left to miners and node operators. However, others believe that user input is necessary for Bitcoin to grow its user base and remain competitive.The discussions also explore the implementation of a decentralized, distributed system that allows users to have a say in how the network evolves and operates. Some members question the need for user input in block size limits, while others argue that it is essential for the success of a decentralized network. Overall, the goal is to find a consensus-based system that can effectively incorporate user input while ensuring the stability and growth of Bitcoin.In an email conversation, Whitlock and Todd discuss the implementation of a voting system for miners in the Bitcoin network. They propose using two bits for voting, with options for keeping the limit the same, halving it, or doubling it. They also discuss the possibility of determining the final decision through the plurality of votes. Another proposal suggests using proof-of-stake to apportion control of increases based on the percentage of Bitcoin owned.There are concerns about miner influence over the vote, as they could potentially manipulate the outcome by generating transactions in their own blocks. However, it is argued that miners would need to align with user preferences to earn actual income. The discussions aim to improve the governance process of the Bitcoin network and find a mechanism for effective user input in transaction verification. 2015-06-15T03:59:05+00:00 + The ongoing discussion on block size limits in Bitcoin revolves around the consensus that the limit needs to be increased. However, there are differing opinions on how this should be done and what the limit should be. Jeff Garzik suggests a mechanism for determining the limit through miner voting, transitioning the decision-making process from software developers to the free market. Eric Lombrozo proposes a voting system for metaconsensus to address higher-level governance problems.The economic consequences of the block size limit decision are also highlighted in the discussions. The size limit defines the fee market and directly impacts miners, developers, and users. Various proposals have been made, but none have fully addressed the fundamental question of how to redesign this aspect of Bitcoin. This raises concerns over corruptibility and the need for proper consensus.The overall goal is to find a solution that allows users to have a say in the block size limit while ensuring the stability and decentralization of the Bitcoin network. Transitioning from software-based decision-making to a free market approach is seen as a way to achieve this. However, there are still many factors to consider, such as the economic policy lever, fee calculation heuristics, and the potential impact on business models and user adoption.In conclusion, the block size limit controversy in Bitcoin sparks discussions about economic policy, governance, and the transition from software to the free market. The consensus is that the limit needs to be increased, but there are debates about the best approach and the potential consequences. The discussions highlight the need for a voting system for metaconsensus and the importance of considering the economic implications of any changes made.One proposal suggests removing the block size limit entirely and enforcing a "soft" limit through miner voting. Users would have influence over the miner vote through transactions casting a specific vote. Another proposal suggests using proof-of-stake blocksize voting. There are debates about whether users should have a say in block size limits, with some arguing that it should be left to miners and node operators. However, others believe that user input is necessary for Bitcoin to grow its user base and remain competitive.The discussions also explore the implementation of a decentralized, distributed system that allows users to have a say in how the network evolves and operates. Some members question the need for user input in block size limits, while others argue that it is essential for the success of a decentralized network. Overall, the goal is to find a consensus-based system that can effectively incorporate user input while ensuring the stability and growth of Bitcoin.In an email conversation, Whitlock and Todd discuss the implementation of a voting system for miners in the Bitcoin network. They propose using two bits for voting, with options for keeping the limit the same, halving it, or doubling it. They also discuss the possibility of determining the final decision through the plurality of votes. Another proposal suggests using proof-of-stake to apportion control of increases based on the percentage of Bitcoin owned.There are concerns about miner influence over the vote, as they could potentially manipulate the outcome by generating transactions in their own blocks. However, it is argued that miners would need to align with user preferences to earn actual income. The discussions aim to improve the governance process of the Bitcoin network and find a mechanism for effective user input in transaction verification. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Various-block-size-proposals.xml b/static/bitcoin-dev/June_2015/combined_Various-block-size-proposals.xml index 674fda1b8a..a9bf670113 100644 --- a/static/bitcoin-dev/June_2015/combined_Various-block-size-proposals.xml +++ b/static/bitcoin-dev/June_2015/combined_Various-block-size-proposals.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Various block size proposals - 2023-08-01T13:14:35.337937+00:00 + 2025-10-11T21:37:15.420830+00:00 + python-feedgen Pindar Wong 2015-06-12 23:29:29+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Various block size proposals - 2023-08-01T13:14:35.338937+00:00 + 2025-10-11T21:37:15.420992+00:00 - In the Bitcoin development community, there are numerous proposals addressing the minimum block size questions and scalability issues. Bryan Bishop has compiled a list of these proposals, which includes ideas from various individuals. Some of the proposals mentioned include a dynamic block size limit controller by maaku, increasing the maximum block size using a soft-fork by Tier Nolan, an elastic block cap with rollover penalties by Meni Rosenfield, variable mining effort by gmaxwell, and a BIP100 soft-fork limit of 2 MB by jgarzik.Other proposals mentioned in the list include transaction fee targeting, difficulty target scaling, an annual 50% increase in the maximum block size, and various algorithmic adjustment proposals. Adam Back has proposed extension blocks, and there are suggestions for voting by paying to an address or fees. Sergio Lerner proposes reducing the block rate instead of increasing the maximum block size, while other proposals suggest decreasing the block interval and increasing the default soft block size limit in Bitcoin Core.There are also proposals to consider the size of the utxo set when determining the maximum block size, as well as reducing and decreasing the max block size. Some developers suggest changing the value of MAX_BLOCK_SIZE in Bitcoin Core, while others have highlighted problems with floating block size limits. Additionally, developers have proposed alternative solutions such as simplified payment verification, the lightning network, GHOST, payment channels, and tree chains to support high transaction volumes.However, it is important to note that some proposals have limitations, including vote censorship and utxo depth, which cannot achieve consensus. Furthermore, the list compiled by Bryan Bishop is missing old Bitcoin-development and Bitcointalk proposals. To ensure thorough discussion and fact-checking, there is a miningconsensus.slack.com group available for further engagement on these topics. 2015-06-12T23:29:29+00:00 + In the Bitcoin development community, there are numerous proposals addressing the minimum block size questions and scalability issues. Bryan Bishop has compiled a list of these proposals, which includes ideas from various individuals. Some of the proposals mentioned include a dynamic block size limit controller by maaku, increasing the maximum block size using a soft-fork by Tier Nolan, an elastic block cap with rollover penalties by Meni Rosenfield, variable mining effort by gmaxwell, and a BIP100 soft-fork limit of 2 MB by jgarzik.Other proposals mentioned in the list include transaction fee targeting, difficulty target scaling, an annual 50% increase in the maximum block size, and various algorithmic adjustment proposals. Adam Back has proposed extension blocks, and there are suggestions for voting by paying to an address or fees. Sergio Lerner proposes reducing the block rate instead of increasing the maximum block size, while other proposals suggest decreasing the block interval and increasing the default soft block size limit in Bitcoin Core.There are also proposals to consider the size of the utxo set when determining the maximum block size, as well as reducing and decreasing the max block size. Some developers suggest changing the value of MAX_BLOCK_SIZE in Bitcoin Core, while others have highlighted problems with floating block size limits. Additionally, developers have proposed alternative solutions such as simplified payment verification, the lightning network, GHOST, payment channels, and tree chains to support high transaction volumes.However, it is important to note that some proposals have limitations, including vote censorship and utxo depth, which cannot achieve consensus. Furthermore, the list compiled by Bryan Bishop is missing old Bitcoin-development and Bitcointalk proposals. To ensure thorough discussion and fact-checking, there is a miningconsensus.slack.com group available for further engagement on these topics. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Version-bits-proposal.xml b/static/bitcoin-dev/June_2015/combined_Version-bits-proposal.xml index 72fe2734c6..64cba06ef1 100644 --- a/static/bitcoin-dev/June_2015/combined_Version-bits-proposal.xml +++ b/static/bitcoin-dev/June_2015/combined_Version-bits-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Version bits proposal - 2023-08-01T12:50:48.992239+00:00 + 2025-10-11T21:37:36.649163+00:00 + python-feedgen Pieter Wuille 2015-06-03 20:42:44+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Version bits proposal - 2023-08-01T12:50:48.992239+00:00 + 2025-10-11T21:37:36.649358+00:00 - On May 26, 2015, Pieter Wuille proposed a plan for coordinating future soft-forking consensus changes on Bitcoin. The proposal supports multiple parallel changes and changes that get permanently rejected without obstructing the rollout of others. Wuille suggested using the mailing list for commenting as the gist does not support notifying participants of new comments. This joint work was done with Peter Todd and Greg Maxwell. The plan received feedback, and Wuille plans to address it and work on an implementation next week.The email conversation is a discussion on the use of the median time and nVersion soft-fork mechanisms for Bitcoin Improvement Proposals (BIPs). The median time mechanism allows hashing power to show what time they think it is, while the nVersion soft-fork mechanism enables hashing power to indicate which features they want to support. The deadline for BIPs need not be set accurately; a roughly six-month deadline should suffice, and a majority of miners are needed to abuse the median time. Increasing the number of blocks used in the median could reduce "noise". Each bit is assigned to a particular BIP for a specific range of times or blocks, and if block numbers were used for the deadline, one only needs to check the block index for the deadline block. The block at height deadline would indicate whether the BIP was locked in. Block time could still be used as long as the block height was set after that. For each block height, there is a set of known BIP bits that are allowed, and once the final deadline passes, the expected mask is zeros. There was some ambiguity in phrasing regarding changing the 95% rule, where 75% is needed to start applying it, and 95% to start rejecting blocks that do not apply it.In a discussion about manipulating the merkle tree in Bitcoin, Christian Decker and Patrick Strateman agree that there is no need to misuse the version field. Decker states that there is enough variability in the merkle tree, including and excluding transactions, and even the scriptSig of the coinbase transaction, which influences the merkle root. He has a fundamental dislike of retroactively changing semantics and thinks that the version field should only be used for that purpose. Strateman argues that any reasonable micro-controller can build merkle tree roots significantly faster than necessary, with an RPi 1 model B doing 2451050 SHA256 ops/second. Sergio Lerner likes the idea but suggests leaving at least 16 bits of the version fixed as an extra-nonce to avoid miners using them as a nonce and interfering with the soft-fork voting system. In this way, miners could permute transactions in the block by permuting the internal merkle tree nodes at increasing depths, making the tree manipulations maximum depth independent and possibly even transaction-independent, depending on how much depth in the tree of hashes are permutation safe.In a discussion on the Bitcoin-development mailing list, Chris expressed his dislike of retroactively changing semantics and proposed that the version field should only be used for its intended purpose. He also voiced support for Sipa's proposal to flag support for a fork in the version field, although he did not particularly like this solution. The discussion also included Patrick Strateman's argument that there is no need to misuse the version field, as micro-controllers can build merkle tree roots faster than necessary. Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and disrupting the soft-fork voting system. Lerner's original proposal can be found on GitHub.The context discusses the efficiency of building merkle tree roots using micro-controllers. The writer argues that any reasonable micro-controller can perform this task much faster than necessary. For instance, a controller with 1 Th/s walks the nonce range in just 4.3ms. The largest valid merkle trees are 14 nodes high, which means that translating them to SHA256 operations would require 28 ops per 4.3 ms or 6511 ops/second. However, for reference, an RPi 1 model B performs 2451050 SHA256 ops/second. In response to this context, Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce. He believes that if not done, miners may use them as a nonce and interfere with the soft-fork voting system. The writer provided a link to their original proposal on Github.The author of the context suggests leaving 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and interfering with the soft-fork voting system. The author provides a link to their original proposal in a GitHub pull request. It is unclear what exactly the proposal entails, but it may provide more details on how the extra-nonce would work. Overall, the author seems to be concerned about maintaining the integrity of the soft 2015-06-03T20:42:44+00:00 + On May 26, 2015, Pieter Wuille proposed a plan for coordinating future soft-forking consensus changes on Bitcoin. The proposal supports multiple parallel changes and changes that get permanently rejected without obstructing the rollout of others. Wuille suggested using the mailing list for commenting as the gist does not support notifying participants of new comments. This joint work was done with Peter Todd and Greg Maxwell. The plan received feedback, and Wuille plans to address it and work on an implementation next week.The email conversation is a discussion on the use of the median time and nVersion soft-fork mechanisms for Bitcoin Improvement Proposals (BIPs). The median time mechanism allows hashing power to show what time they think it is, while the nVersion soft-fork mechanism enables hashing power to indicate which features they want to support. The deadline for BIPs need not be set accurately; a roughly six-month deadline should suffice, and a majority of miners are needed to abuse the median time. Increasing the number of blocks used in the median could reduce "noise". Each bit is assigned to a particular BIP for a specific range of times or blocks, and if block numbers were used for the deadline, one only needs to check the block index for the deadline block. The block at height deadline would indicate whether the BIP was locked in. Block time could still be used as long as the block height was set after that. For each block height, there is a set of known BIP bits that are allowed, and once the final deadline passes, the expected mask is zeros. There was some ambiguity in phrasing regarding changing the 95% rule, where 75% is needed to start applying it, and 95% to start rejecting blocks that do not apply it.In a discussion about manipulating the merkle tree in Bitcoin, Christian Decker and Patrick Strateman agree that there is no need to misuse the version field. Decker states that there is enough variability in the merkle tree, including and excluding transactions, and even the scriptSig of the coinbase transaction, which influences the merkle root. He has a fundamental dislike of retroactively changing semantics and thinks that the version field should only be used for that purpose. Strateman argues that any reasonable micro-controller can build merkle tree roots significantly faster than necessary, with an RPi 1 model B doing 2451050 SHA256 ops/second. Sergio Lerner likes the idea but suggests leaving at least 16 bits of the version fixed as an extra-nonce to avoid miners using them as a nonce and interfering with the soft-fork voting system. In this way, miners could permute transactions in the block by permuting the internal merkle tree nodes at increasing depths, making the tree manipulations maximum depth independent and possibly even transaction-independent, depending on how much depth in the tree of hashes are permutation safe.In a discussion on the Bitcoin-development mailing list, Chris expressed his dislike of retroactively changing semantics and proposed that the version field should only be used for its intended purpose. He also voiced support for Sipa's proposal to flag support for a fork in the version field, although he did not particularly like this solution. The discussion also included Patrick Strateman's argument that there is no need to misuse the version field, as micro-controllers can build merkle tree roots faster than necessary. Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and disrupting the soft-fork voting system. Lerner's original proposal can be found on GitHub.The context discusses the efficiency of building merkle tree roots using micro-controllers. The writer argues that any reasonable micro-controller can perform this task much faster than necessary. For instance, a controller with 1 Th/s walks the nonce range in just 4.3ms. The largest valid merkle trees are 14 nodes high, which means that translating them to SHA256 operations would require 28 ops per 4.3 ms or 6511 ops/second. However, for reference, an RPi 1 model B performs 2451050 SHA256 ops/second. In response to this context, Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce. He believes that if not done, miners may use them as a nonce and interfere with the soft-fork voting system. The writer provided a link to their original proposal on Github.The author of the context suggests leaving 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and interfering with the soft-fork voting system. The author provides a link to their original proposal in a GitHub pull request. It is unclear what exactly the proposal entails, but it may provide more details on how the extra-nonce would work. Overall, the author seems to be concerned about maintaining the integrity of the soft - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Welcome-to-the-new-Bitcoin-Dev-List.xml b/static/bitcoin-dev/June_2015/combined_Welcome-to-the-new-Bitcoin-Dev-List.xml index bfbc7e2185..852b29d536 100644 --- a/static/bitcoin-dev/June_2015/combined_Welcome-to-the-new-Bitcoin-Dev-List.xml +++ b/static/bitcoin-dev/June_2015/combined_Welcome-to-the-new-Bitcoin-Dev-List.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Welcome to the new Bitcoin Dev List - 2023-08-01T13:29:58.118623+00:00 + 2025-10-11T21:37:06.928106+00:00 + python-feedgen Andy Schroder 2015-06-23 18:45:01+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Welcome to the new Bitcoin Dev List - 2023-08-01T13:29:58.118623+00:00 + 2025-10-11T21:37:06.928244+00:00 - The Bitcoin-dev mailing list has completed its move to the Linux Foundation, and the previous archive has been fully imported. However, there may be a delay of 5+ minutes for the first post due to Greylisting. The Linux Foundation plans to upgrade Mailman soon to better handle posts from DKIM enforced domains. They will also make some config tweaks, including auto-rejecting non-subscribed posts. While auto-rejecting spam is deemed too dangerous, those messages will go into a blackhole to prevent bounce abuse.Warren Togami Jr. made the announcement on June 22, 2015, stating that the move to the new list, bitcoin-dev, was complete. The previous archive has been fully imported, and new posts will now be saved. However, the first post to this list may be delayed by 5+ minutes due to greylisting. Warren Togami Jr. also mentioned that LF will be upgrading Mailman soon to better handle posts from DKIM enforced domains. There will be a few more config tweaks like auto-rejecting non-subscribed posts. It is too dangerous to auto-reject spam because those messages need to go into a blackhole to prevent bounce abuse.Regarding the updating of bitcoin.org and other related forums, Jonas Schnelli inquired about it after the successful move to a new archive. Wladimir responded with links to pull requests on Github for updating these platforms. However, he mentioned that the bitcoin.org page still needed some tweaking.Overall, the context provides updates on the completion of the move of the bitcoin-dev mailing list archives and upcoming improvements to the Mailman system. Additionally, there is discussion about the need for updating bitcoin.org and bitcointalk.org. 2015-06-23T18:45:01+00:00 + The Bitcoin-dev mailing list has completed its move to the Linux Foundation, and the previous archive has been fully imported. However, there may be a delay of 5+ minutes for the first post due to Greylisting. The Linux Foundation plans to upgrade Mailman soon to better handle posts from DKIM enforced domains. They will also make some config tweaks, including auto-rejecting non-subscribed posts. While auto-rejecting spam is deemed too dangerous, those messages will go into a blackhole to prevent bounce abuse.Warren Togami Jr. made the announcement on June 22, 2015, stating that the move to the new list, bitcoin-dev, was complete. The previous archive has been fully imported, and new posts will now be saved. However, the first post to this list may be delayed by 5+ minutes due to greylisting. Warren Togami Jr. also mentioned that LF will be upgrading Mailman soon to better handle posts from DKIM enforced domains. There will be a few more config tweaks like auto-rejecting non-subscribed posts. It is too dangerous to auto-reject spam because those messages need to go into a blackhole to prevent bounce abuse.Regarding the updating of bitcoin.org and other related forums, Jonas Schnelli inquired about it after the successful move to a new archive. Wladimir responded with links to pull requests on Github for updating these platforms. However, he mentioned that the bitcoin.org page still needed some tweaking.Overall, the context provides updates on the completion of the move of the bitcoin-dev mailing list archives and upcoming improvements to the Mailman system. Additionally, there is discussion about the need for updating bitcoin.org and bitcointalk.org. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_Why-do-we-need-a-MAX-BLOCK-SIZE-at-all-.xml b/static/bitcoin-dev/June_2015/combined_Why-do-we-need-a-MAX-BLOCK-SIZE-at-all-.xml index d2b4eed853..8968d73120 100644 --- a/static/bitcoin-dev/June_2015/combined_Why-do-we-need-a-MAX-BLOCK-SIZE-at-all-.xml +++ b/static/bitcoin-dev/June_2015/combined_Why-do-we-need-a-MAX-BLOCK-SIZE-at-all-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why do we need a MAX_BLOCK_SIZE at all? - 2023-08-01T13:00:31.315660+00:00 + 2025-10-11T21:38:59.509328+00:00 + python-feedgen Jim Phillips 2015-06-01 20:02:31+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Why do we need a MAX_BLOCK_SIZE at all? - 2023-08-01T13:00:31.315660+00:00 + 2025-10-11T21:38:59.509505+00:00 - In this discussion from 2015, Jim Phillips raises questions about the necessity of a hard limit on the block size in Bitcoin. While acknowledging the importance of maintaining consensus in the network, Phillips suggests that configurable settings could be used instead of a hard limit to address issues such as propagation difficulties and the need for a fee economy for miners.Phillips argues that the original purpose of the block size limit, to prevent spamming, is no longer a significant concern with the rise of ASIC mining. He proposes that allowing hardware limits to act as bottlenecks for scaling would be a more preferable approach than introducing an artificial bottleneck into the protocol that requires regular adjustment.The author further suggests that relay nodes should have the ability to configure their own limits on block size. This would prevent rogue miners from flooding the network with large blocks and potentially centralizing pools. By refusing to relay large blocks filled with nonsense or coming from miners known for producing bad blocks, relays can mitigate the risk of centralization and maintain a healthy network.The author also highlights that anonymizing networks like TOR are not designed to handle static IP traffic, which means larger miners using static IPs would not risk getting blacklisted by relays. Removing the 1 MB cap entirely could lead to further centralization of pools, as larger pools may create larger blocks that smaller pools cannot handle. This would force smaller pools out of the network and increase the percentage of network hashrate for the original pool operator.Furthermore, the author notes that larger blocks would result in fewer people willing to run full nodes and store all of the blockchain data. This could increase server costs for those running full nodes and make it impractical for individuals with home computers to keep up with the network. The author emphasizes the importance of finding a block size limit that strikes the right balance between resource restrictions and functional requirements.Ultimately, the author concludes that there currently does not exist a solution that adequately addresses all the tradeoffs involved in determining the block size limit. However, the author suggests that allowing relays to decide which blocks they propagate could mitigate potential attacks and limitations associated with block size. The author questions the necessity of a hard-coded limit that affects the entire network and poses ongoing challenges in the future, advocating for Bitcoin to grow naturally within the increasing limits of hardware. 2015-06-01T20:02:31+00:00 + In this discussion from 2015, Jim Phillips raises questions about the necessity of a hard limit on the block size in Bitcoin. While acknowledging the importance of maintaining consensus in the network, Phillips suggests that configurable settings could be used instead of a hard limit to address issues such as propagation difficulties and the need for a fee economy for miners.Phillips argues that the original purpose of the block size limit, to prevent spamming, is no longer a significant concern with the rise of ASIC mining. He proposes that allowing hardware limits to act as bottlenecks for scaling would be a more preferable approach than introducing an artificial bottleneck into the protocol that requires regular adjustment.The author further suggests that relay nodes should have the ability to configure their own limits on block size. This would prevent rogue miners from flooding the network with large blocks and potentially centralizing pools. By refusing to relay large blocks filled with nonsense or coming from miners known for producing bad blocks, relays can mitigate the risk of centralization and maintain a healthy network.The author also highlights that anonymizing networks like TOR are not designed to handle static IP traffic, which means larger miners using static IPs would not risk getting blacklisted by relays. Removing the 1 MB cap entirely could lead to further centralization of pools, as larger pools may create larger blocks that smaller pools cannot handle. This would force smaller pools out of the network and increase the percentage of network hashrate for the original pool operator.Furthermore, the author notes that larger blocks would result in fewer people willing to run full nodes and store all of the blockchain data. This could increase server costs for those running full nodes and make it impractical for individuals with home computers to keep up with the network. The author emphasizes the importance of finding a block size limit that strikes the right balance between resource restrictions and functional requirements.Ultimately, the author concludes that there currently does not exist a solution that adequately addresses all the tradeoffs involved in determining the block size limit. However, the author suggests that allowing relays to decide which blocks they propagate could mitigate potential attacks and limitations associated with block size. The author questions the necessity of a hard-coded limit that affects the entire network and poses ongoing challenges in the future, advocating for Bitcoin to grow naturally within the increasing limits of hardware. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_block-size-tradeoffs-hypothetical-alternatives-Re-Block-size-increase-oppositionists-please-clearly-define-what-you-need-done-to-increase-block-size-to-a-static-8MB-and-help-do-it-.xml b/static/bitcoin-dev/June_2015/combined_block-size-tradeoffs-hypothetical-alternatives-Re-Block-size-increase-oppositionists-please-clearly-define-what-you-need-done-to-increase-block-size-to-a-static-8MB-and-help-do-it-.xml index 79db5881a7..f7ab448652 100644 --- a/static/bitcoin-dev/June_2015/combined_block-size-tradeoffs-hypothetical-alternatives-Re-Block-size-increase-oppositionists-please-clearly-define-what-you-need-done-to-increase-block-size-to-a-static-8MB-and-help-do-it-.xml +++ b/static/bitcoin-dev/June_2015/combined_block-size-tradeoffs-hypothetical-alternatives-Re-Block-size-increase-oppositionists-please-clearly-define-what-you-need-done-to-increase-block-size-to-a-static-8MB-and-help-do-it-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - block-size tradeoffs & hypothetical alternatives (Re: Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it) - 2023-08-01T14:10:44.341927+00:00 + 2025-10-11T21:37:09.049481+00:00 + python-feedgen Tom Harding 2015-06-30 22:56:04+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - block-size tradeoffs & hypothetical alternatives (Re: Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it) - 2023-08-01T14:10:44.342899+00:00 + 2025-10-11T21:37:09.049607+00:00 - In an email dated June 30, 2015, Adam Back discussed the interests and incentives of miners in relation to increasing block size limits. He noted that while miners can collectively keep blocks smaller, a large excess of space relative to current demand could result in fees dropping to zero for a few years if someone breaks ranks and takes any fee, regardless of how small. Back also mentioned that wallet defaults play a significant role in preserving fees, and that there is less reason today to worry about fees than there was in 2012.Back expressed uncertainty about the clear picture of hash-rate-imposed limits, but it is evident from the all-blocksizes plot that the 750K soft limit and another less common soft limit at 900K are being imposed and broken more frequently as demand surpasses them. These soft limits serve only to delay transactions, and there is no purpose to them other than that. Additionally, Back stated that a 750KB block is followed by another 750KB or larger block as frequently as expected from the actual block time distribution.BIP 101 has working code ready for evaluation to increase block size, but it remains unclear when Lightning and Sidechains will be ready for a fair and controlled test. Back suggested running an experiment as a layer 2 side-chain or analogous for those interested in higher tier data-center and throughput by high bandwidth use route. He also proposed conducting this experiment parallelly with Lightning to see how it works.The concept of "decentralization" is gaining popularity in the context of Bitcoin, which differentiates itself by preventing double spending without a trusted third party. The author of the text shared a link to a paper on measuring decentralization of government functions, which provides a framework for defining decentralization metrics. Although not directly related to Bitcoin, the paper can be useful in understanding how decentralization can be measured.The security model of Bitcoin is based on decentralization, but Back's statement about decentralization being key to Bitcoin's security model lacks definition and evidence. A more precise problem description is needed to focus on questions about incentives for nodes to collude with miners or behave as trusted third parties. MAX_BLOCK_SIZE is also related to these questions.Bitcoin experts such as Greg Maxwell, Jeff Garzik, and Gavin Andresen have discussed the issue of block size and scaling for improved decentralization, privacy, and throughput. While increasing block size is important, it should be done within tech limits and allocate some bandwidth to decentralization improvements. Miners should also be considered in the block-size increase plan. The growth should scale smoothly to avoid unforeseen side-effects, and tests of achievable network bandwidth on different networks should be conducted.Decentralization is crucial to Bitcoin's security model, and alternative designs that are more network efficient while achieving effective decentralization are preferable. Lightning or a semi-centralized trade-off in the side-chain model could be more appropriate for high scale. It is suggested that BIPs should include sections on security, privacy, and decentralization/fungibility. Additionally, any proposal should be reasonably analyzed in terms of bandwidth assumptions and game theory.While increasing capacity alongside hardware is a good idea, it is important to ensure that core functionality remains for Lightning and other scaling approaches to remain secure by using Bitcoin as a secure anchor. 2015-06-30T22:56:04+00:00 + In an email dated June 30, 2015, Adam Back discussed the interests and incentives of miners in relation to increasing block size limits. He noted that while miners can collectively keep blocks smaller, a large excess of space relative to current demand could result in fees dropping to zero for a few years if someone breaks ranks and takes any fee, regardless of how small. Back also mentioned that wallet defaults play a significant role in preserving fees, and that there is less reason today to worry about fees than there was in 2012.Back expressed uncertainty about the clear picture of hash-rate-imposed limits, but it is evident from the all-blocksizes plot that the 750K soft limit and another less common soft limit at 900K are being imposed and broken more frequently as demand surpasses them. These soft limits serve only to delay transactions, and there is no purpose to them other than that. Additionally, Back stated that a 750KB block is followed by another 750KB or larger block as frequently as expected from the actual block time distribution.BIP 101 has working code ready for evaluation to increase block size, but it remains unclear when Lightning and Sidechains will be ready for a fair and controlled test. Back suggested running an experiment as a layer 2 side-chain or analogous for those interested in higher tier data-center and throughput by high bandwidth use route. He also proposed conducting this experiment parallelly with Lightning to see how it works.The concept of "decentralization" is gaining popularity in the context of Bitcoin, which differentiates itself by preventing double spending without a trusted third party. The author of the text shared a link to a paper on measuring decentralization of government functions, which provides a framework for defining decentralization metrics. Although not directly related to Bitcoin, the paper can be useful in understanding how decentralization can be measured.The security model of Bitcoin is based on decentralization, but Back's statement about decentralization being key to Bitcoin's security model lacks definition and evidence. A more precise problem description is needed to focus on questions about incentives for nodes to collude with miners or behave as trusted third parties. MAX_BLOCK_SIZE is also related to these questions.Bitcoin experts such as Greg Maxwell, Jeff Garzik, and Gavin Andresen have discussed the issue of block size and scaling for improved decentralization, privacy, and throughput. While increasing block size is important, it should be done within tech limits and allocate some bandwidth to decentralization improvements. Miners should also be considered in the block-size increase plan. The growth should scale smoothly to avoid unforeseen side-effects, and tests of achievable network bandwidth on different networks should be conducted.Decentralization is crucial to Bitcoin's security model, and alternative designs that are more network efficient while achieving effective decentralization are preferable. Lightning or a semi-centralized trade-off in the side-chain model could be more appropriate for high scale. It is suggested that BIPs should include sections on security, privacy, and decentralization/fungibility. Additionally, any proposal should be reasonably analyzed in terms of bandwidth assumptions and game theory.While increasing capacity alongside hardware is a good idea, it is important to ensure that core functionality remains for Lightning and other scaling approaches to remain secure by using Bitcoin as a secure anchor. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_comments-on-BIP-100.xml b/static/bitcoin-dev/June_2015/combined_comments-on-BIP-100.xml index ac96fa2f4c..286ae5b312 100644 --- a/static/bitcoin-dev/June_2015/combined_comments-on-BIP-100.xml +++ b/static/bitcoin-dev/June_2015/combined_comments-on-BIP-100.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - comments on BIP 100 - 2023-08-01T13:17:27.957013+00:00 + 2025-10-11T21:37:34.526106+00:00 + python-feedgen Adam Back 2015-06-15 18:14:56+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - comments on BIP 100 - 2023-08-01T13:17:27.957013+00:00 + 2025-10-11T21:37:34.526318+00:00 - In a discussion on the Bitcoin-development mailing list, there is a debate about whether to increase Bitcoin's 1MB block size limit or not. One user suggests a hard fork to remove the limit, but others express concern about the potential impact on the market price and suggest alternative solutions.One proposal is a soft-forkable extension-block approach, while another suggests a hard fork and merge-mining approach to allow both the original 1MB limited bitcoin and a forked version with no block size limit to coexist. A developer named Rebroad suggests a merge-mining solution where a forked Bitcoin with no block size limit could be mined alongside the original Bitcoin. This would preserve diversity and avoid risk to people's investments. The Bitcoin core developers can implement a patch to allow the chain to fork at a set point, splitting bitcoins into the new and old versions. However, concerns remain about branding and potential confusion between the two versions.In another email thread, developer Mike Hearn discusses the importance of decentralization and the trade-off between using centralized services and decentralized approaches in the block size debate. Some argue that the benefits of decentralization are low compared to adding additional features. Third-party services are providing what developers need to build great apps, even if it fails to meet perfect cryptographic ideals.The conversation also touches on the issue of trustless querying of the UTXO set and the compromise of querying multiple peers for more decentralization and robustness. However, some developers prefer outsourcing to trusted services for ease of use.There is a discussion about O() notation and the majority of users running web or SPV wallets instead of relaying nodes. Eric Lombrozo expresses concern about the lack of validation among nodes and its acceptability as a feature of the protocol.The article mentions the trend of using web2.0 technology in wallets/services and the preference for outsourced services due to their developer-friendly features. There is a call for acceptance of different approaches to decentralized app development.The conversation also includes discussions about StrawPay's micropayments system, the block size increase code in Bitcoin XT, and various scaling and decentralization proposals.The issue of validation cost in blockchain is discussed, with suggestions for better data structures and algorithms rather than simply increasing block size.Finally, there is a discussion about Jeff Garzik's outline draft BIP 100, which proposes a block size increase with an explicit 32MB ceiling and an option for users to opt into further growth. There is a recognition of the need for a measured pace of transition and market input.Overall, the discussion highlights the ongoing debate within the Bitcoin community about the best way to handle the block size limit, scalability, and decentralization while considering the potential impact on the market and user experience.In a discussion about Bitcoin scalability, there is disagreement over whether there should be a growth limiter on block size increase. The conversation involves proposals such as Greg Maxwell's difficulty adjust and paying bitcoins to future miners as alternatives. Adam Back suggests that conversations about Jeff Garzik's draft BIP 100 should be held on the mailing list. He highlights issues with "paying with difficulty" and proposes layering models, smart-contracts, and protocols like lightning to improve scalability.Eric Lombrozo states that the real issue with scalability is the cost of validation, not complexity. Algorithmic improvements are needed, but a hard-fork takes time to deploy.Adam Back believes that much of the industry is built on outdated technology and companies need to invest in integration and coding for scalability. Mike Hearn expresses concern about outsourcing services and not running full nodes, suggesting that technologists should focus on building incrementally deployable solutions.The conversation also touches on the idea of raising the block size limit and the potential consequences of scrapping existing software. Adam shares his thoughts on Jeff Garzik's BIP 100 and proposes changes to the original proposal. He emphasizes the importance of avoiding interventionist subsidies and providing links to related discussions and proposals. 2015-06-15T18:14:56+00:00 + In a discussion on the Bitcoin-development mailing list, there is a debate about whether to increase Bitcoin's 1MB block size limit or not. One user suggests a hard fork to remove the limit, but others express concern about the potential impact on the market price and suggest alternative solutions.One proposal is a soft-forkable extension-block approach, while another suggests a hard fork and merge-mining approach to allow both the original 1MB limited bitcoin and a forked version with no block size limit to coexist. A developer named Rebroad suggests a merge-mining solution where a forked Bitcoin with no block size limit could be mined alongside the original Bitcoin. This would preserve diversity and avoid risk to people's investments. The Bitcoin core developers can implement a patch to allow the chain to fork at a set point, splitting bitcoins into the new and old versions. However, concerns remain about branding and potential confusion between the two versions.In another email thread, developer Mike Hearn discusses the importance of decentralization and the trade-off between using centralized services and decentralized approaches in the block size debate. Some argue that the benefits of decentralization are low compared to adding additional features. Third-party services are providing what developers need to build great apps, even if it fails to meet perfect cryptographic ideals.The conversation also touches on the issue of trustless querying of the UTXO set and the compromise of querying multiple peers for more decentralization and robustness. However, some developers prefer outsourcing to trusted services for ease of use.There is a discussion about O() notation and the majority of users running web or SPV wallets instead of relaying nodes. Eric Lombrozo expresses concern about the lack of validation among nodes and its acceptability as a feature of the protocol.The article mentions the trend of using web2.0 technology in wallets/services and the preference for outsourced services due to their developer-friendly features. There is a call for acceptance of different approaches to decentralized app development.The conversation also includes discussions about StrawPay's micropayments system, the block size increase code in Bitcoin XT, and various scaling and decentralization proposals.The issue of validation cost in blockchain is discussed, with suggestions for better data structures and algorithms rather than simply increasing block size.Finally, there is a discussion about Jeff Garzik's outline draft BIP 100, which proposes a block size increase with an explicit 32MB ceiling and an option for users to opt into further growth. There is a recognition of the need for a measured pace of transition and market input.Overall, the discussion highlights the ongoing debate within the Bitcoin community about the best way to handle the block size limit, scalability, and decentralization while considering the potential impact on the market and user experience.In a discussion about Bitcoin scalability, there is disagreement over whether there should be a growth limiter on block size increase. The conversation involves proposals such as Greg Maxwell's difficulty adjust and paying bitcoins to future miners as alternatives. Adam Back suggests that conversations about Jeff Garzik's draft BIP 100 should be held on the mailing list. He highlights issues with "paying with difficulty" and proposes layering models, smart-contracts, and protocols like lightning to improve scalability.Eric Lombrozo states that the real issue with scalability is the cost of validation, not complexity. Algorithmic improvements are needed, but a hard-fork takes time to deploy.Adam Back believes that much of the industry is built on outdated technology and companies need to invest in integration and coding for scalability. Mike Hearn expresses concern about outsourcing services and not running full nodes, suggesting that technologists should focus on building incrementally deployable solutions.The conversation also touches on the idea of raising the block size limit and the potential consequences of scrapping existing software. Adam shares his thoughts on Jeff Garzik's BIP 100 and proposes changes to the original proposal. He emphasizes the importance of avoiding interventionist subsidies and providing links to related discussions and proposals. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_improving-development-model-Re-Concerns-Regarding-Threats-by-a-Developer-to-Remove-Commit-Access-from-Other-Developers.xml b/static/bitcoin-dev/June_2015/combined_improving-development-model-Re-Concerns-Regarding-Threats-by-a-Developer-to-Remove-Commit-Access-from-Other-Developers.xml index ccd89ab4c8..dfa6d72609 100644 --- a/static/bitcoin-dev/June_2015/combined_improving-development-model-Re-Concerns-Regarding-Threats-by-a-Developer-to-Remove-Commit-Access-from-Other-Developers.xml +++ b/static/bitcoin-dev/June_2015/combined_improving-development-model-Re-Concerns-Regarding-Threats-by-a-Developer-to-Remove-Commit-Access-from-Other-Developers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers - 2023-08-01T13:22:51.729946+00:00 + 2025-10-11T21:38:00.013497+00:00 + python-feedgen Tom Harding 2015-06-20 02:59:25+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers - 2023-08-01T13:22:51.729946+00:00 + 2025-10-11T21:38:00.013652+00:00 - In an email exchange from June 2015, Mike Hearn expressed concern about Blockstream employees opposing a blocksize hard fork and suggested that they may be hiding their true motives. The ongoing debate around the implementation of a blocksize hard fork in Bitcoin was highlighted, with some arguing it would create security issues while others believed it was necessary for accommodating the growing number of transactions.The conversation shifted towards lobbying for 20MB blocks and whether payments were accepted for this purpose. The prioritization of user rights versus company interests in Bitcoin was discussed, with one participant arguing that developers lobby for changes beneficial to funding companies. They disagreed with the idea of a "social contract" and "strong user ethos" in Bitcoin.The discussion then focused on the urgency of raising the block size limit to prevent congestion and the accusation that one participant accepted payment from companies to lobby for larger blocks. It was noted that Blockstream had a potential conflict of interest due to their involvement in Sidechains and Lightning. Polling suggested that users strongly supported increasing the block size, and the Bitcoin social contract was defined by its founding vision.An email chain between Eric Lombrozo and Dr. Adam Back discussed the potential downfall of Bitcoin, with Lombrozo suggesting that someone will eventually create a better version. Lombrozo argued that being the first does not guarantee success, citing examples like Mac and Windows PC, and Yahoo! and Google. He concluded that there is untapped brainpower available for cryptocurrency development, potentially relegating Bitcoin to history.Dr. Adam Back discussed the payment protocol layer in Bitcoin, emphasizing the importance of transitioning to layer2 and working on decentralization and algorithmic scaling. User rights were deemed more important than company interests, as Bitcoin is a user-centric currency. Importing company interests could lead to the demise of Bitcoin.In another discussion, Dr. Adam Back suggested using sidechains to test beta features and novel ideas on the Bitcoin network. Eric Lombrozo highlighted the issue of forking cryptoledgers and argued against unilaterally imposing changes to consensus rules, as it would undermine the value of decentralized cryptoledgers. 2015-06-20T02:59:25+00:00 + In an email exchange from June 2015, Mike Hearn expressed concern about Blockstream employees opposing a blocksize hard fork and suggested that they may be hiding their true motives. The ongoing debate around the implementation of a blocksize hard fork in Bitcoin was highlighted, with some arguing it would create security issues while others believed it was necessary for accommodating the growing number of transactions.The conversation shifted towards lobbying for 20MB blocks and whether payments were accepted for this purpose. The prioritization of user rights versus company interests in Bitcoin was discussed, with one participant arguing that developers lobby for changes beneficial to funding companies. They disagreed with the idea of a "social contract" and "strong user ethos" in Bitcoin.The discussion then focused on the urgency of raising the block size limit to prevent congestion and the accusation that one participant accepted payment from companies to lobby for larger blocks. It was noted that Blockstream had a potential conflict of interest due to their involvement in Sidechains and Lightning. Polling suggested that users strongly supported increasing the block size, and the Bitcoin social contract was defined by its founding vision.An email chain between Eric Lombrozo and Dr. Adam Back discussed the potential downfall of Bitcoin, with Lombrozo suggesting that someone will eventually create a better version. Lombrozo argued that being the first does not guarantee success, citing examples like Mac and Windows PC, and Yahoo! and Google. He concluded that there is untapped brainpower available for cryptocurrency development, potentially relegating Bitcoin to history.Dr. Adam Back discussed the payment protocol layer in Bitcoin, emphasizing the importance of transitioning to layer2 and working on decentralization and algorithmic scaling. User rights were deemed more important than company interests, as Bitcoin is a user-centric currency. Importing company interests could lead to the demise of Bitcoin.In another discussion, Dr. Adam Back suggested using sidechains to test beta features and novel ideas on the Bitcoin network. Eric Lombrozo highlighted the issue of forking cryptoledgers and argued against unilaterally imposing changes to consensus rules, as it would undermine the value of decentralized cryptoledgers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_questions-about-bitcoin-XT-code-fork-non-consensus-hard-fork.xml b/static/bitcoin-dev/June_2015/combined_questions-about-bitcoin-XT-code-fork-non-consensus-hard-fork.xml index 5ffec9723d..3e2564ee95 100644 --- a/static/bitcoin-dev/June_2015/combined_questions-about-bitcoin-XT-code-fork-non-consensus-hard-fork.xml +++ b/static/bitcoin-dev/June_2015/combined_questions-about-bitcoin-XT-code-fork-non-consensus-hard-fork.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - questions about bitcoin-XT code fork & non-consensus hard-fork - 2023-08-01T13:19:24.235942+00:00 + 2025-10-11T21:38:31.882608+00:00 + python-feedgen Peter Todd 2015-06-26 19:30:31+00:00 @@ -115,13 +116,13 @@ - python-feedgen + 2 Combined summary - questions about bitcoin-XT code fork & non-consensus hard-fork - 2023-08-01T13:19:24.235942+00:00 + 2025-10-11T21:38:31.882839+00:00 - In a series of email discussions, several key points regarding the regulatory question of Bitcoin and the blocksize issue were raised. Pindar Wong emphasized the need to involve all Bitcoin holders in any changes to the blocksize, not just miners. He proposed a technical meeting at the Cyberport in Hong Kong to discuss various proposals, such as BIP100 and 101. Peter Todd agreed with the need for science-driven investigations on Bitcoin to gather hard data for decision-making. He mentioned attending a conference in London where the blocksize issue was being discussed by attendees with different views than those on Reddit. Aaron Voisine argued for major changes to non-consensus code to handle blocks filling up, suggesting that hardfork deployment should be discussed more often. He expressed his interest in proposing a fork himself if necessary. Mike Hearn responded to Voisine's email, mentioning alternatives to the XT hard fork, such as a modified version of Gavin's proposal or BIP100. Bryan Bishop cautioned about evaluating consensus changes carefully. Pindar Wong expressed interest in collaborating with Constance Choi, Primavera De Filippi, and Peter Todd for science-driven investigations on the blocksize issue. He also noted that regulatory questions extended beyond local jurisdictions to customers' jurisdictions.Developers discussed reducing or limiting blockchain growth and proposed various ideas, including setting minimum fees for acceptance and using replace-by-fee (RBF) to estimate fees correctly. Concerns about transaction propagation and fee estimation for mobile wallets were raised. Troy Benjegerdes suggested that non-consensus hard forks could be beneficial for the long-term health of the Bitcoin ecosystem. He advised against picking fights and emphasized the need for collaborative efforts. Adam Back and Peter Todd discussed arranging an open summit in Hong Kong to meet with Chinese miners and coordinate with the blockchain-tech conference held by Constance Choi and Primavera De Filippi. They stressed the importance of considering regulatory issues and potential threats to Bitcoin. The Bitcoin development community engaged in a contentious debate over scalability, with discussions on the risks of unilateral hard forks. The community rejected the idea of a hard fork and proposed a combination plan focusing on improving decentralization, gradually increasing block size, and algorithmic scaling. Mike Hearn addressed the security and incident response during the deployment of the unilateral hard fork for Bitcoin XT, expressing confidence in dealing with them. He also discussed the potential risk involved and the need for consensus. Mike Hearn expressed frustration over the insistence from Adam Back, Gregory Maxwell, and others that "the technical community" agrees with them. He emphasized his and Gavin Andresen's contributions to Bitcoin and called for mutual respect in the debate. Venzen urged Mike Hearn to cease his activity of a unilateral hard fork, highlighting the importance of collaborative work and due process of change implementation by consensus. He suggested using soft fork rules as a reasonable compromise and involving users in the decision-making process.In an email thread, Mike Hearn responds to Adam's questions about the proposed hard fork and the consensus process. Hearn explains that the Bitcoin protocol does not have definitions about developer consensus and voting is not a perfect mechanism. He suggests that a proposed hard fork vote would require each party to lay out a long-term plan and proposal. Hearn and Gavin Andresen do not have plans to implement new scaling facilities, and Hearn believes that Lightning is not a coherent proposal. He argues that the notion that change has no consensus is inaccurate, as there are highly technical and passionate developers who have built up the Bitcoin user base. Hearn asserts that many wallet developers, major exchanges, payment processors, and mining pools want to see the limit lifted.The email chain discusses potential changes to Bitcoin's mempool size and transaction propagation rules. Aaron Voisine suggests that ejecting transactions from mempools instead of preemptively refusing them based on network-wide propagation rules may result in inconsistent transaction propagation and an increase in transaction rebroadcasts. He also raises concerns about the lack of transparency in fee estimation with replace-by-fee (RBF). Alex Morcos responds by mentioning improvements made to the fee estimation code and efforts to overhaul block creation and mempool limiting code to incorporate actual outstanding queues in fee estimation. There is also mention of upcoming inclusion of CPFP and RBF in Bitcoin core to handle edge cases.In another email conversation, Eric Lombrozo expresses his disagreement with the means being used by Mike Hearn and Gavin Andresen to lift the block size limit. Lombrozo believes that while the limit needs to be lifted eventually, the current method is not the right approach. He suggests that permissionless innovation is one of Bitcoin's virtues and adoption will ultimately decide what Bitcoin is and isn't.The email thread discusses the concerns raised by Adam regarding personal ownership of the proposed hard fork in Bitcoin-XT. Faiz Khan urges caution and suggests that anyone wishing to fork the protocol should reconsider whether they are truly ready to test their skills and resources in such a way. Bryan Bishop emphasizes the need for careful 2015-06-26T19:30:31+00:00 + In a series of email discussions, several key points regarding the regulatory question of Bitcoin and the blocksize issue were raised. Pindar Wong emphasized the need to involve all Bitcoin holders in any changes to the blocksize, not just miners. He proposed a technical meeting at the Cyberport in Hong Kong to discuss various proposals, such as BIP100 and 101. Peter Todd agreed with the need for science-driven investigations on Bitcoin to gather hard data for decision-making. He mentioned attending a conference in London where the blocksize issue was being discussed by attendees with different views than those on Reddit. Aaron Voisine argued for major changes to non-consensus code to handle blocks filling up, suggesting that hardfork deployment should be discussed more often. He expressed his interest in proposing a fork himself if necessary. Mike Hearn responded to Voisine's email, mentioning alternatives to the XT hard fork, such as a modified version of Gavin's proposal or BIP100. Bryan Bishop cautioned about evaluating consensus changes carefully. Pindar Wong expressed interest in collaborating with Constance Choi, Primavera De Filippi, and Peter Todd for science-driven investigations on the blocksize issue. He also noted that regulatory questions extended beyond local jurisdictions to customers' jurisdictions.Developers discussed reducing or limiting blockchain growth and proposed various ideas, including setting minimum fees for acceptance and using replace-by-fee (RBF) to estimate fees correctly. Concerns about transaction propagation and fee estimation for mobile wallets were raised. Troy Benjegerdes suggested that non-consensus hard forks could be beneficial for the long-term health of the Bitcoin ecosystem. He advised against picking fights and emphasized the need for collaborative efforts. Adam Back and Peter Todd discussed arranging an open summit in Hong Kong to meet with Chinese miners and coordinate with the blockchain-tech conference held by Constance Choi and Primavera De Filippi. They stressed the importance of considering regulatory issues and potential threats to Bitcoin. The Bitcoin development community engaged in a contentious debate over scalability, with discussions on the risks of unilateral hard forks. The community rejected the idea of a hard fork and proposed a combination plan focusing on improving decentralization, gradually increasing block size, and algorithmic scaling. Mike Hearn addressed the security and incident response during the deployment of the unilateral hard fork for Bitcoin XT, expressing confidence in dealing with them. He also discussed the potential risk involved and the need for consensus. Mike Hearn expressed frustration over the insistence from Adam Back, Gregory Maxwell, and others that "the technical community" agrees with them. He emphasized his and Gavin Andresen's contributions to Bitcoin and called for mutual respect in the debate. Venzen urged Mike Hearn to cease his activity of a unilateral hard fork, highlighting the importance of collaborative work and due process of change implementation by consensus. He suggested using soft fork rules as a reasonable compromise and involving users in the decision-making process.In an email thread, Mike Hearn responds to Adam's questions about the proposed hard fork and the consensus process. Hearn explains that the Bitcoin protocol does not have definitions about developer consensus and voting is not a perfect mechanism. He suggests that a proposed hard fork vote would require each party to lay out a long-term plan and proposal. Hearn and Gavin Andresen do not have plans to implement new scaling facilities, and Hearn believes that Lightning is not a coherent proposal. He argues that the notion that change has no consensus is inaccurate, as there are highly technical and passionate developers who have built up the Bitcoin user base. Hearn asserts that many wallet developers, major exchanges, payment processors, and mining pools want to see the limit lifted.The email chain discusses potential changes to Bitcoin's mempool size and transaction propagation rules. Aaron Voisine suggests that ejecting transactions from mempools instead of preemptively refusing them based on network-wide propagation rules may result in inconsistent transaction propagation and an increase in transaction rebroadcasts. He also raises concerns about the lack of transparency in fee estimation with replace-by-fee (RBF). Alex Morcos responds by mentioning improvements made to the fee estimation code and efforts to overhaul block creation and mempool limiting code to incorporate actual outstanding queues in fee estimation. There is also mention of upcoming inclusion of CPFP and RBF in Bitcoin core to handle edge cases.In another email conversation, Eric Lombrozo expresses his disagreement with the means being used by Mike Hearn and Gavin Andresen to lift the block size limit. Lombrozo believes that while the limit needs to be lifted eventually, the current method is not the right approach. He suggests that permissionless innovation is one of Bitcoin's virtues and adoption will ultimately decide what Bitcoin is and isn't.The email thread discusses the concerns raised by Adam regarding personal ownership of the proposed hard fork in Bitcoin-XT. Faiz Khan urges caution and suggests that anyone wishing to fork the protocol should reconsider whether they are truly ready to test their skills and resources in such a way. Bryan Bishop emphasizes the need for careful - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_soft-fork-block-size-increase-extension-blocks-.xml b/static/bitcoin-dev/June_2015/combined_soft-fork-block-size-increase-extension-blocks-.xml index 25d9ef0e03..11180e5e63 100644 --- a/static/bitcoin-dev/June_2015/combined_soft-fork-block-size-increase-extension-blocks-.xml +++ b/static/bitcoin-dev/June_2015/combined_soft-fork-block-size-increase-extension-blocks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - soft-fork block size increase (extension blocks) - 2023-08-01T13:00:10.956516+00:00 + 2025-10-11T21:37:38.771113+00:00 + python-feedgen Richard Moore 2015-06-17 16:17:22+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - soft-fork block size increase (extension blocks) - 2023-08-01T13:00:10.956516+00:00 + 2025-10-11T21:37:38.771291+00:00 - In an email thread from June 1, 2015, Adam Back suggests taking a wait-and-see approach while addressing spam and improving decentralization metrics in Bitcoin. He proposes incrementally increasing the block size as a temporary solution while working on long-term scalability improvements. Tom Harding questions the lead time required for this approach and shares a graph showing the distribution of block sizes over time. Richard Moore is listed as a contact in the email.It is noted that increasing the block size can cause problems for old clients who may not understand the difference between various block sizes. However, SPV wallets are not affected by this issue, and fully validating wallets can be updated with a small code change. The writer clarifies that the argument about huge blocks and data centers was made by Satoshi, not the person being addressed. They had previously written the scalability page for Bitcoin in 2011, which stated that the network could scale to higher transaction rates assuming nodes run on high-end servers. The author feels that their words have been misinterpreted.The discussion revolves around businesses seeking more transactions and the implementation of compatible wallets. Extension blocks are mentioned as a way to enable opt-in and incrementally deployable options. Exchanges could encourage users to adopt wallets supporting larger block sizes by charging fees for smaller transactions. The author emphasizes that extension blocks and lightning networks are unrelated, and there is a tradeoff between security and volume in block size. Different people have different requirements, and the proposal aims to facilitate experiments with larger blocks without conflicting with those who prioritize decentralization. The author suggests waiting and observing whether the block size should remain unchanged for a year or implementing incremental changes while also focusing on long-term scale improvements.Another email conversation involves a wallet developer expressing concerns about updating software to support extension blocks. They worry that if an exchange supports such blocks and a withdrawal is made to a wallet that doesn't understand them, the money might never arrive, potentially causing a disaster. The developer emphasizes the importance of reliable payments and compatibility among wallets. They disagree with the idea of a Lightning-style approach, citing risks, inflexibility, and reduced decentralization. The developer also raises concerns about relying on companies as sounding boards and disregarding the opinions of those providing services to the community.In a separate email conversation, Adam proposes that opt-in block size increases are a preferable solution to hard forks for increasing transaction capacity. He argues that extension blocks offer forward and backward compatibility, allowing businesses in need of more transactions to implement them in their wallets. This approach gives users the choice to opt-in while maintaining security and gaining access to higher transaction per second (TPS) rates at the expense of increased centralization. Adam points out that the decentralization metrics are worsening, making it an unfavorable time to exacerbate the situation. Extension blocks are deemed less centralizing than a fixed block size of 9MB because non-spam transactions would likely occur off-chain until lightning-like systems are established, which would introduce central systems prone to custody and security failures. 2015-06-17T16:17:22+00:00 + In an email thread from June 1, 2015, Adam Back suggests taking a wait-and-see approach while addressing spam and improving decentralization metrics in Bitcoin. He proposes incrementally increasing the block size as a temporary solution while working on long-term scalability improvements. Tom Harding questions the lead time required for this approach and shares a graph showing the distribution of block sizes over time. Richard Moore is listed as a contact in the email.It is noted that increasing the block size can cause problems for old clients who may not understand the difference between various block sizes. However, SPV wallets are not affected by this issue, and fully validating wallets can be updated with a small code change. The writer clarifies that the argument about huge blocks and data centers was made by Satoshi, not the person being addressed. They had previously written the scalability page for Bitcoin in 2011, which stated that the network could scale to higher transaction rates assuming nodes run on high-end servers. The author feels that their words have been misinterpreted.The discussion revolves around businesses seeking more transactions and the implementation of compatible wallets. Extension blocks are mentioned as a way to enable opt-in and incrementally deployable options. Exchanges could encourage users to adopt wallets supporting larger block sizes by charging fees for smaller transactions. The author emphasizes that extension blocks and lightning networks are unrelated, and there is a tradeoff between security and volume in block size. Different people have different requirements, and the proposal aims to facilitate experiments with larger blocks without conflicting with those who prioritize decentralization. The author suggests waiting and observing whether the block size should remain unchanged for a year or implementing incremental changes while also focusing on long-term scale improvements.Another email conversation involves a wallet developer expressing concerns about updating software to support extension blocks. They worry that if an exchange supports such blocks and a withdrawal is made to a wallet that doesn't understand them, the money might never arrive, potentially causing a disaster. The developer emphasizes the importance of reliable payments and compatibility among wallets. They disagree with the idea of a Lightning-style approach, citing risks, inflexibility, and reduced decentralization. The developer also raises concerns about relying on companies as sounding boards and disregarding the opinions of those providing services to the community.In a separate email conversation, Adam proposes that opt-in block size increases are a preferable solution to hard forks for increasing transaction capacity. He argues that extension blocks offer forward and backward compatibility, allowing businesses in need of more transactions to implement them in their wallets. This approach gives users the choice to opt-in while maintaining security and gaining access to higher transaction per second (TPS) rates at the expense of increased centralization. Adam points out that the decentralization metrics are worsening, making it an unfavorable time to exacerbate the situation. Extension blocks are deemed less centralizing than a fixed block size of 9MB because non-spam transactions would likely occur off-chain until lightning-like systems are established, which would introduce central systems prone to custody and security failures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_soft-fork-block-size-increase-extensionblocks-.xml b/static/bitcoin-dev/June_2015/combined_soft-fork-block-size-increase-extensionblocks-.xml index 0eb86ae9bb..b47e4a0199 100644 --- a/static/bitcoin-dev/June_2015/combined_soft-fork-block-size-increase-extensionblocks-.xml +++ b/static/bitcoin-dev/June_2015/combined_soft-fork-block-size-increase-extensionblocks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - soft-fork block size increase (extensionblocks) - 2023-08-01T13:00:51.266011+00:00 + 2025-10-11T21:38:25.515119+00:00 + python-feedgen Raystonn . 2015-06-01 19:02:44+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - soft-fork block size increase (extensionblocks) - 2023-08-01T13:00:51.266011+00:00 + 2025-10-11T21:38:25.515249+00:00 - In a recent email thread, the topic of increasing the default block limit to 1 MB in the next release is discussed. The current limit is causing strain on average transaction display graphs, leading to the suggestion that reaching one million transactions per day would be impossible without raising the limit. Mike Hearn, a Bitcoin developer, argues that by increasing the block size, SPV wallets would not be affected, and fully validating wallets could be updated with a small code change. However, he raises concerns about reduced security if software does not understand the difference between 1 MB and 8 MB output payments.Another issue raised by Hearn is the potential confusion for an old client that makes a payment only confirmed in an extension block. This situation may cause the client to perceive the payment as unconfirmed indefinitely, providing inaccurate information to the user. Regarding scalability, Hearn highlights a distinction from Satoshi's perspective. While Satoshi advocated for large blocks, Hearn believes Satoshi did not argue for Visa scale. Hearn references a scalability page he wrote in 2011, which suggests that the Bitcoin network can handle higher transaction rates than currently observed. However, this assumption relies on nodes running on high-end servers rather than desktops. Hearn further clarifies his position on scalability, emphasizing that he has never claimed Bitcoin would reach Visa scale in the near future. Such a milestone would require either decades or the emergence of an unforeseen killer app. He points out that the core Bitcoin network has the capacity to handle much higher transaction rates, given the appropriate infrastructure of high-end servers. Hearn also expresses frustration with people attributing words to him that he never actually said.Overall, the discussion revolves around the need to increase the maximum block size for Bitcoin to accommodate higher transaction volumes and improve scalability. Various considerations are raised, including the impact on different types of wallets and potential security implications. Hearn underscores the importance of understanding the nuances of scalability and clarifies his stance on reaching Visa scale, emphasizing the need for realistic expectations and appropriate infrastructure. 2015-06-01T19:02:44+00:00 + In a recent email thread, the topic of increasing the default block limit to 1 MB in the next release is discussed. The current limit is causing strain on average transaction display graphs, leading to the suggestion that reaching one million transactions per day would be impossible without raising the limit. Mike Hearn, a Bitcoin developer, argues that by increasing the block size, SPV wallets would not be affected, and fully validating wallets could be updated with a small code change. However, he raises concerns about reduced security if software does not understand the difference between 1 MB and 8 MB output payments.Another issue raised by Hearn is the potential confusion for an old client that makes a payment only confirmed in an extension block. This situation may cause the client to perceive the payment as unconfirmed indefinitely, providing inaccurate information to the user. Regarding scalability, Hearn highlights a distinction from Satoshi's perspective. While Satoshi advocated for large blocks, Hearn believes Satoshi did not argue for Visa scale. Hearn references a scalability page he wrote in 2011, which suggests that the Bitcoin network can handle higher transaction rates than currently observed. However, this assumption relies on nodes running on high-end servers rather than desktops. Hearn further clarifies his position on scalability, emphasizing that he has never claimed Bitcoin would reach Visa scale in the near future. Such a milestone would require either decades or the emergence of an unforeseen killer app. He points out that the core Bitcoin network has the capacity to handle much higher transaction rates, given the appropriate infrastructure of high-end servers. Hearn also expresses frustration with people attributing words to him that he never actually said.Overall, the discussion revolves around the need to increase the maximum block size for Bitcoin to accommodate higher transaction volumes and improve scalability. Various considerations are raised, including the impact on different types of wallets and potential security implications. Hearn underscores the importance of understanding the nuances of scalability and clarifies his stance on reaching Visa scale, emphasizing the need for realistic expectations and appropriate infrastructure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_test-2.xml b/static/bitcoin-dev/June_2015/combined_test-2.xml index 95d79a5dcb..4d417b19ff 100644 --- a/static/bitcoin-dev/June_2015/combined_test-2.xml +++ b/static/bitcoin-dev/June_2015/combined_test-2.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - test #2 - 2023-08-01T13:30:10.840927+00:00 + 2025-10-11T21:39:05.880332+00:00 + python-feedgen s7r 2015-06-21 22:21:52+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - test #2 - 2023-08-01T13:30:10.840927+00:00 + 2025-10-11T21:39:05.880505+00:00 - On June 22, 2015, Warren Togami Jr. raised an issue on the bitcoin-dev mailing list regarding an email from an un-subscribed user. He pointed out that the server should have automatically rejected the email, but it went through to the list instead. This led him to suspect a configuration problem. In his message, Togami included links to both the bitcoin-dev mailing list and the website for the Linux Foundation, which hosts the list.Togami noted that the email came from wtogami at apache.org, an address that is not subscribed to the list. The fact that the email was not rejected by the server indicates a potential configuration problem with the mailing list. To ensure the efficiency and security of the list, it is crucial to allow only subscribed email addresses to send messages. This helps prevent unauthorized individuals or spam from cluttering the list.Although the email had an HTML attachment, it had been scrubbed, meaning no information could be obtained from it. Despite this, Togami's post serves as a reminder to thoroughly review list configurations in order to maintain optimal efficiency and security. By addressing any configuration issues, the mailing list can better protect against unauthorized access and ensure that only authorized subscribers can contribute to the discussions. 2015-06-21T22:21:52+00:00 + On June 22, 2015, Warren Togami Jr. raised an issue on the bitcoin-dev mailing list regarding an email from an un-subscribed user. He pointed out that the server should have automatically rejected the email, but it went through to the list instead. This led him to suspect a configuration problem. In his message, Togami included links to both the bitcoin-dev mailing list and the website for the Linux Foundation, which hosts the list.Togami noted that the email came from wtogami at apache.org, an address that is not subscribed to the list. The fact that the email was not rejected by the server indicates a potential configuration problem with the mailing list. To ensure the efficiency and security of the list, it is crucial to allow only subscribed email addresses to send messages. This helps prevent unauthorized individuals or spam from cluttering the list.Although the email had an HTML attachment, it had been scrubbed, meaning no information could be obtained from it. Despite this, Togami's post serves as a reminder to thoroughly review list configurations in order to maintain optimal efficiency and security. By addressing any configuration issues, the mailing list can better protect against unauthorized access and ensure that only authorized subscribers can contribute to the discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_test-3.xml b/static/bitcoin-dev/June_2015/combined_test-3.xml index 349ca391a5..7dd104e186 100644 --- a/static/bitcoin-dev/June_2015/combined_test-3.xml +++ b/static/bitcoin-dev/June_2015/combined_test-3.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - test #3 - 2023-08-01T13:30:19.675812+00:00 + 2025-10-11T21:38:02.136804+00:00 + python-feedgen Ivan Brightly 2015-06-21 22:35:20+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - test #3 - 2023-08-01T13:30:19.675812+00:00 + 2025-10-11T21:38:02.136949+00:00 - On June 21, 2015, Warren Togami Jr. raised a concern on the bitcoin-dev mailing list about a post that was sent from an address not subscribed to the list. He noted that the server should have automatically rejected the post, and if it was still able to go through, there might be an issue with the configuration. The email included the usual footer of the mailing list, containing links for subscription and unsubscription. Additionally, an HTML attachment was present in the email, but its content remains unknown as it was scrubbed. It is important to note that the bitcoin-dev mailing list is hosted by the Linux Foundation and serves as a platform for developers to discuss Bitcoin-related software development. The flagged post from wtogami at apache.org highlights the non-subscribed address as an issue, which should have triggered an automatic rejection from the server. The presence of the scrubbed HTML attachment adds further complexity to the situation, as its relevance or content is not provided. 2015-06-21T22:35:20+00:00 + On June 21, 2015, Warren Togami Jr. raised a concern on the bitcoin-dev mailing list about a post that was sent from an address not subscribed to the list. He noted that the server should have automatically rejected the post, and if it was still able to go through, there might be an issue with the configuration. The email included the usual footer of the mailing list, containing links for subscription and unsubscription. Additionally, an HTML attachment was present in the email, but its content remains unknown as it was scrubbed. It is important to note that the bitcoin-dev mailing list is hosted by the Linux Foundation and serves as a platform for developers to discuss Bitcoin-related software development. The flagged post from wtogami at apache.org highlights the non-subscribed address as an issue, which should have triggered an automatic rejection from the server. The presence of the scrubbed HTML attachment adds further complexity to the situation, as its relevance or content is not provided. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2015/combined_test-post.xml b/static/bitcoin-dev/June_2015/combined_test-post.xml index 0e3dfeb7d2..18dca2f323 100644 --- a/static/bitcoin-dev/June_2015/combined_test-post.xml +++ b/static/bitcoin-dev/June_2015/combined_test-post.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - test post - 2023-08-01T13:30:41.251855+00:00 + 2025-10-11T21:38:51.006789+00:00 + python-feedgen odinn 2015-06-24 01:26:23+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - test post - 2023-08-01T13:30:41.251855+00:00 + 2025-10-11T21:38:51.006971+00:00 - Nathan Wilcox sent an email to the bitcoin-dev mailing list on June 22, 2015. The email introduced himself and included his contact information, such as his email address and Twitter handle. He also shared his PGP key for secure communication. The email was signed with a GnuPG v1 signature. In the signature, Wilcox promoted two projects: abis.io, which aims to enable decentralization and expansion of a giving economy, and Keybase.io, where he had a profile under the username odinn. Another member of the mailing list, Richard Winder, had sent an email prior to Nathan's, but it did not provide any further context or information. 2015-06-24T01:26:23+00:00 + Nathan Wilcox sent an email to the bitcoin-dev mailing list on June 22, 2015. The email introduced himself and included his contact information, such as his email address and Twitter handle. He also shared his PGP key for secure communication. The email was signed with a GnuPG v1 signature. In the signature, Wilcox promoted two projects: abis.io, which aims to enable decentralization and expansion of a giving economy, and Keybase.io, where he had a profile under the username odinn. Another member of the mailing list, Richard Winder, had sent an email prior to Nathan's, but it did not provide any further context or information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/June_2016/combined_BIP-151-MITM.xml b/static/bitcoin-dev/June_2016/combined_BIP-151-MITM.xml index c600efca02..b3851eb536 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP-151-MITM.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP-151-MITM.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 151 MITM - 2025-09-26T15:32:16.516745+00:00 + 2025-10-11T21:42:19.340395+00:00 python-feedgen Alfie John 2016-06-09 07:00:51+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - BIP 151 MITM - 2025-09-26T15:32:16.516893+00:00 + 2025-10-11T21:42:19.340575+00:00 2016-06-09T07:00:51+00:00 In a recent bitcoin-dev mailing list discussion, Jonas Schnelli announced that he is currently working on an Auth-BIP, which is not yet ready for review. However, he kindly provided a link to his work on Github for those interested in taking a look. He also shared the most recent MITM/auth discussion that took place on IRC. Another member of the group, Alfie John, expressed gratitude towards Jonas for sharing the links.The conversation revolved around concerns raised by Gregory Maxwell regarding plaintext attacks. He stated that active attackers find plaintext reduction uninteresting, as they can easily impersonate the remote side. To address this issue, authentication is mentioned as a separate specification that builds upon the ongoing work. This leads to Alfie John's query about how authentication can be achieved. In response, Jonas Schnelli suggests reviewing his current work on Auth-BIP and provides a link to both his Github repository and the most recent MITM/auth discussion.In a discussion thread from June 9, 2016, Gregory Maxwell discussed the lack of interest in plaintext attacks for active attackers, who can instead impersonate the remote side. The solution to this concern is authentication, which is addressed through a separate specification building on the ongoing work. Alfie John, a participant in the discussion, requested links to further discussions on authentication methods.During the discussion, Alfie John raised concerns about the potential manipulation of the initial 'encinit' message during negotiation in BIP 151. This manipulation could lead to both peers falling back to plaintext. While some argue that reducing to plaintext is not a significant attack vector for active attackers, as they can simply impersonate the remote side, authentication is seen as the solution. However, without authentication, the protection provided only defends against passive attackers. The suggestion is made that peers should negotiate a secure channel from the beginning or entirely back out, with no option of falling back. Additionally, it is proposed that the daemon listening on a completely new port can loudly indicate this. The message is signed by Alfie John and includes a link to their personal website, https://www.alfie.wtf. diff --git a/static/bitcoin-dev/June_2016/combined_BIP-151-use-of-HMAC-SHA512.xml b/static/bitcoin-dev/June_2016/combined_BIP-151-use-of-HMAC-SHA512.xml index 4c36fc57e3..83d5667c5c 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP-151-use-of-HMAC-SHA512.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP-151-use-of-HMAC-SHA512.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 151 use of HMAC_SHA512 - 2025-09-26T15:32:22.858891+00:00 + 2025-10-11T21:42:25.710011+00:00 python-feedgen Jonas Schnelli 2016-07-04 06:47:05+00:00 @@ -77,10 +77,11 @@ + 2 Combined summary - BIP 151 use of HMAC_SHA512 - 2025-09-26T15:32:22.859089+00:00 + 2025-10-11T21:42:25.710187+00:00 2016-07-04T06:47:05+00:00 Zooko Wilcox, in a discussion on the bitcoin-dev mailing list, suggests using the well-studied open standard of HKDF (HMAC-based Extract-and-Expand Key Derivation Function) instead of re-inventing it. He emphasizes the importance of using open standards in cryptography to reduce the risk of errors. Arthur Chen agrees with this recommendation and highlights the significance of following well-studied open standards in the realm of cryptocurrency.The discussion also touches upon the use of HMAC vs SHA256 for a Message Authentication Code (MAC). It is explained that SHA256 is insecure for a MAC due to its length extension property. Even though SHA256 appends the bitlength, making it more difficult to generate a new value, it is not being used as a MAC in BIP151. Arthur Chen explains the proven security properties of HMAC, even when the underlying crypto hashing function has weaknesses. He emphasizes the importance of using HMAC for MACs rather than custom constructions.There is a debate about using SHA512_HMAC instead of SHA256_HMAC for key derivation. Jonas Schnelli suggests using SHA512_HMAC, citing its usage in BIP32 and its cost-effectiveness compared to two SHA256_HMAC operations. However, Rusty Russell argues that introducing another hash algorithm would be unnecessarily painful and questions the use of HMAC over just SHA256. The discussion concludes without clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In another discussion, the importance of including the cipher-type in the symmetric cipher key is emphasized to avoid weak-cipher attacks. It is noted that although BIP151 currently specifies chacha20-poly1305 at openssh.com, it is possible for someone to add another symmetric cipher type after deployment which may have weaker security properties. Therefore, the inclusion of the ciphersuite-type in the key derivation HMAC is crucial to prevent potential attacks.Based on previous crypto analysis, it is stated that the security of SHA512 is not significantly higher than SHA256. There have been discussions about considering SHA3 as a potential alternative. However, there are no clear pros and cons identified for using SHA512_HMAC over SHA256_HMAC.In summary, the context revolves around the importance of using well-studied open standards in cryptography. It emphasizes the use of HKDF instead of reinventing it and the utilization of HMAC for MACs to ensure security. There are debates regarding the use of SHA512_HMAC vs SHA256_HMAC for key derivation, with different perspectives provided. The inclusion of the cipher-type in the symmetric cipher key is highlighted to avoid weak-cipher attacks. Overall, the discussions aim to enhance the security and reliability of cryptographic systems in the realm of cryptocurrency. diff --git a/static/bitcoin-dev/June_2016/combined_BIP-151.xml b/static/bitcoin-dev/June_2016/combined_BIP-151.xml index f5b881dac2..05bc614f79 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP-151.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP-151.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 151 - 2025-09-26T15:32:18.632550+00:00 + 2025-10-11T21:42:21.462817+00:00 python-feedgen Pieter Wuille 2016-08-31 14:29:53+00:00 @@ -169,10 +169,11 @@ + 2 Combined summary - BIP 151 - 2025-09-26T15:32:18.632737+00:00 + 2025-10-11T21:42:21.463018+00:00 2016-08-31T14:29:53+00:00 In a discussion among members of the Bitcoin development community, concerns were raised about the BIP151 protocol and its ability to detect man-in-the-middle (MITM) attacks. Eric Voskuil pointed out that BIP151 does not provide tools to detect such attacks, which is a general requirement for authentication. He also questioned the security of using a Bitcoin address and whether emails claiming to be from the NSA should be trusted.Peter Todd countered by arguing that BIP151 does give users the tools to detect MITM attacks, similar to how some users don't properly check keys in PGP. He explained that anonymous peers aren't always truly anonymous and that an out-of-band key check can be used to determine if an attack is occurring. However, Voskuil noted that this type of key check is not part of BIP151 and requires a secure channel for authentication.The discussion also touched on the security of Bitcoin and its network, particularly the use of encryption. Some participants expressed concerns about the potential drawbacks and challenges of implementing authentication without identity and central control. The proposed BIP151 focuses on encryption and creating a stepping stone towards greater security, but it must be deployed together with an authentication scheme to protect against MITM during encryption initialization.Another topic of discussion was the use of Bloom filters in the P2P protocol. Some argued that these filters lack value and should be removed, while others emphasized the necessity of the BIP151 protocol for network participant privacy and authenticated links. It was noted that BIP151 is an ephemerally keyed opportunistic encryption system, not an identity system. The protocol may also become faster with the implementation of BIP151.The discussion highlighted the need for a secure side channel for the distribution of public keys and the potential risk of censorship. Multiple ways of sharing identity keys exist, but the challenges of designing a distributed system that requires authentication without identity and central control were acknowledged. The ongoing discussion and brainstorming surrounding BIP151 sparked ideas about how encryption and authentication could work in Bitcoin.In a separate email exchange, concerns were raised about the security implications of applying identity to the P2P protocol instead of keeping it in a client-server model. The writer argued that the Bloom filter features should be isolated from the P2P protocol and moved to a client-server protocol. They also expressed concerns about key distribution in an identity system and the potential for censorship. The responder disagreed, stating that they didn't see how BIP151 would weaken the security of the P2P network and requested specific concerns. They emphasized the importance of an authentication/identity management system to prevent MITM attacks and suggested focusing on the "pure encryption part" of BIP151 to avoid overspecification.Overall, the discussions highlighted the importance of encryption and authentication in ensuring the security and privacy of the Bitcoin network. While there are ongoing debates and no implementation of BIP151 has started yet, the draft proposal has sparked valuable brainstorming on how to improve the encryption and authentication mechanisms in Bitcoin. diff --git a/static/bitcoin-dev/June_2016/combined_BIP-draft-Memo-server.xml b/static/bitcoin-dev/June_2016/combined_BIP-draft-Memo-server.xml index ca2056c25c..92291de267 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP-draft-Memo-server.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP-draft-Memo-server.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP draft: Memo server - 2025-09-26T15:32:14.403238+00:00 + 2025-10-11T21:42:17.209223+00:00 python-feedgen Luke Dashjr 2016-06-02 00:41:27+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - BIP draft: Memo server - 2025-09-26T15:32:14.403391+00:00 + 2025-10-11T21:42:17.209395+00:00 2016-06-02T00:41:27+00:00 Chris Priest, a developer, is creating a standalone system to archive and serve memos for Bitcoin wallets. The purpose of this system is to allow wallet users to switch from one wallet to another without losing their memos. These memos will be encrypted and stored on memo servers. The public key will be propagated so that the memos can be shared among different servers. The specific encryption method for the memos has not been finalized yet, but it is crucial that they are strongly encrypted. Additionally, the memos should support various types of data, and the memo server should not be tied to a specific wallet schema.To access the memo server, users will only need to provide their memo-specific identifier, which may not be related to any part of their wallet. Multiple memo servers will be available, giving users the option to choose which ones they trust with their data. The writer of the context is developing a wallet called multiexplorer, which supports all BIPs (Bitcoin Improvement Proposals), including those that enable exporting and importing based on a 12-word mnemonic. However, when exporting and importing into another wallet, the memos added to each transaction are lost because the mnemonic cannot encode this data. To address this issue, the writer plans to create a separate system for archiving and serving these memos. Once implemented, every wallet will support this system, allowing users to seamlessly move between wallets by copying and pasting the mnemonic without losing their memos.The system works by encrypting and sending the memos to multiple memo servers operated by different individuals. These memo servers synchronize data amongst themselves. The exact encryption scheme for the memos is yet to be determined, and it is essential to choose a strong encryption method since the memos will be publicly propagated.This system aims to facilitate the transition from older, potentially less secure wallets to modern wallets with enhanced security features. It also aims to reduce lock-in by providing a solution to preserve memos when switching wallets. Detailed information about how the system will work can be found at the provided GitHub link: https://github.com/priestc/bips/blob/master/memo-server.mediawiki. diff --git a/static/bitcoin-dev/June_2016/combined_BIP141-segwit-consensus-rule-update-extension-of-witness-program-definition.xml b/static/bitcoin-dev/June_2016/combined_BIP141-segwit-consensus-rule-update-extension-of-witness-program-definition.xml index 21bd1a3d77..fc44fccfca 100644 --- a/static/bitcoin-dev/June_2016/combined_BIP141-segwit-consensus-rule-update-extension-of-witness-program-definition.xml +++ b/static/bitcoin-dev/June_2016/combined_BIP141-segwit-consensus-rule-update-extension-of-witness-program-definition.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP141 segwit consensus rule update: extension of witness program definition - 2025-09-26T15:32:20.745805+00:00 + 2025-10-11T21:42:23.586297+00:00 python-feedgen Pieter Wuille 2016-06-12 14:40:17+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - BIP141 segwit consensus rule update: extension of witness program definition - 2025-09-26T15:32:20.745960+00:00 + 2025-10-11T21:42:23.586459+00:00 2016-06-12T14:40:17+00:00 In a Bitcoin-dev mailing list discussion, Luke Dashjr expressed his opinion on the safety and size limitations of the 32 bytes hash. He argued that a witness program larger than 40 bytes would be unnecessary and expensive, taking up more UTXO space. However, he acknowledged the downside of being too strict, which limits the ability to do soft fork upgrades in the future. As a compromise, he suggested raising the limit to 75 bytes.Pieter, who initiated the discussion, disagreed with the need for any changes. He believed that any data that needs to be encoded can be moved to the witness at a cheaper cost and replaced by a 256-bit hash. The only thing not allowed in the hash is metadata to indicate the hashing/rule scheme used, which Pieter thought could be represented by 68 bits (OP_n + 8 bytes).Johnson Lau also expressed concerns about the safety of the 32 bytes hash and its potential impact on the safety of txid. He suggested that if the 32 bytes hash is deemed unsafe in the future, a hard fork might be needed. Additionally, he questioned the usefulness of a witness program larger than 40 bytes, as it would be more expensive and take up more UTXO space.Luke Dashjr and Johnson Lau discussed the possibility of extending the definition for scripts with a 1-byte push followed by a push of 40 bytes. Lau suggested making it even bigger, up to 75 bytes, but Dashjr did not see this as a sufficient answer. However, Pieter explained that a softfork to redefine such scripts would be complicated due to the current limit preventing the use of the witness field.On June 8, 2016, Johnson Lau proposed increasing the size of transaction scripts to 75 bytes. Pieter explained why a size larger than 75 would be inconvenient, but did not provide a satisfactory response to the proposed increase. Luke Dashjr pointed out that scripts with a 1-byte push followed by a push of over 40 bytes remain anyone-can-spend, so they could be redefined with a softfork. However, this would prevent the use of the witness field for such scripts, requiring two different witness commitments or disabling the previous witness transaction format.The segregated witness (BIP141) consensus rule has been updated to extend the definition of a witness program, allowing it to consist of a data push between 2 to 40 bytes, instead of the previous limit of 2 to 32 bytes. This update was necessary as BIP141 only defined version 0 witness programs for P2WPKH and P2WSH, leaving versions 1 to 16 undefined and considered anyone-can-spend scripts. By extending the maximum length by 8 bytes, up to 16 * 2^64 versions are now available for future upgrades. A witness program of 40 bytes allows a 32-byte hash with 8-byte metadata, and any scripts larger than 32 bytes should be recorded in the witness field to reduce transaction cost and impact on the UTXO set.It is unlikely that a larger witness program would be required without a major revamp of the Bitcoin protocol since SHA256 is widely used. Previously, a script with a 1-byte push followed by a data push of 33-40 bytes did not allow witness data, but this is now allowed. Users running segnet nodes or testnet nodes with segwit code are advised to upgrade to the latest version at https://github.com/bitcoin/bitcoin/pull/7910. Alternative implementations should also ensure their consensus code is updated accordingly to avoid forking off the network. diff --git a/static/bitcoin-dev/June_2016/combined_Building-Blocks-of-the-State-Machine-Approach-to-Consensus.xml b/static/bitcoin-dev/June_2016/combined_Building-Blocks-of-the-State-Machine-Approach-to-Consensus.xml index 455a882143..d5c62f5b19 100644 --- a/static/bitcoin-dev/June_2016/combined_Building-Blocks-of-the-State-Machine-Approach-to-Consensus.xml +++ b/static/bitcoin-dev/June_2016/combined_Building-Blocks-of-the-State-Machine-Approach-to-Consensus.xml @@ -2,7 +2,7 @@ 2 Combined summary - Building Blocks of the State Machine Approach to Consensus - 2025-09-26T15:32:24.979248+00:00 + 2025-10-11T21:42:27.834066+00:00 python-feedgen Peter Todd 2016-06-24 22:23:16+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - Building Blocks of the State Machine Approach to Consensus - 2025-09-26T15:32:24.979412+00:00 + 2025-10-11T21:42:27.834220+00:00 2016-06-24T22:23:16+00:00 In the realm of blockchain technology, various implementations have been developed to ensure the integrity and security of transactions. These implementations include decentralized blockchains, centralized public logs, and receipt oracles. Each approach offers a unique way to attest to the validity of transactions and handle potential fraudulent activities.One key concept in this field is the use of validity oracles. These oracles serve as trusted entities that can verify the accuracy and legitimacy of transactions. By attesting to the validity of transactions, these oracles enable the removal of historical data prior to the verified transactions, helping to streamline and optimize the blockchain.Another important tool in combatting fraud within the system is the use of fraud proofs. These proofs are designed to expose any invalid states or fraudulent proof within the blockchain. By leveraging fraud proofs, developers can ensure that the information stored within the system is accurate and reliable.To efficiently manage the blockchain's data, pruning techniques can be implemented. Pruning involves automatically keeping track of only the necessary data while serializing the proof. This helps to reduce the storage requirements and enhance the overall scalability of the blockchain, making it more efficient and accessible.Additionally, probabilistic validation techniques play a crucial role in detecting undetected fraud within the system. These techniques employ statistical methods to verify that the percentage of undetected fraud falls below a predetermined threshold with a specified probability. By utilizing probabilistic validation techniques, developers can add an extra layer of security to the blockchain, ensuring its reliability and trustworthiness.In summary, the diverse range of implementations for blockchain technology includes decentralized blockchains, centralized public logs, and receipt oracles. Validity oracles, fraud proofs, pruning techniques, and probabilistic validation techniques all contribute to the integrity and security of transactions within the blockchain ecosystem. These tools and approaches collectively work towards creating a robust and trustworthy system for handling digital transactions. diff --git a/static/bitcoin-dev/June_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml b/static/bitcoin-dev/June_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml index 61f8d9a363..736d1a9aa2 100644 --- a/static/bitcoin-dev/June_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml +++ b/static/bitcoin-dev/June_2016/combined_Code-Review-The-Consensus-Critical-Parts-of-Segwit-by-Peter-Todd.xml @@ -2,7 +2,7 @@ 2 Combined summary - Code Review: The Consensus Critical Parts of Segwit by Peter Todd - 2025-09-26T15:32:10.178154+00:00 + 2025-10-11T21:42:12.957947+00:00 python-feedgen Peter Todd 2016-07-04 23:27:15+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Code Review: The Consensus Critical Parts of Segwit by Peter Todd - 2025-09-26T15:32:10.178320+00:00 + 2025-10-11T21:42:12.958088+00:00 2016-07-04T23:27:15+00:00 In a discussion about the implementation of Segregated Witness (SegWit) on the Bitcoin network, one issue raised is the odd result that occurs when a transaction spends a witness output with an unknown version. Surprisingly, this transaction is valid even if it doesn't have any witnesses. One suggestion is to leave these unknown witness programs as any-one-can-spend without looking at the witness. However, this creates a special case in the code, allowing spending of a witness output without a witness.There is a debate about whether to allow the use of 160-bit commitments for multisig transactions, which may require 256-bit security. The argument is that using shorter hash and pubkey for storing a small amount of Bitcoin could save bytes. However, concerns are raised about potential hash collisions and the reuse of signatures for different signature hashes. To address this, tagged hashing is proposed as a way to ensure that signatures cannot be reused in different contexts. XORing the magic tag prior to its use is suggested as sufficient for signature applications.Unfortunately, this method is not compatible with timestamping schemes like OpenTimestamps, which rely on all operations being cryptographically secure. Another concern is the difficulty of adding new commitments with soft forks. It is pointed out that anything after 38 bytes in the reserve value of a 32-byte hash has no consensus meaning, making it inefficient to add new commitments with softforks.In an email exchange between Johnson Lau and Bitcoin developer Peter Todd, various issues related to SegWit implementation are discussed. They discuss the possibility of allowing users to choose a less secure 160-bit commitment if their use-case doesn't require the full 256-bit security level. Additionally, the maximum size of serialized witness scripts is debated, with the constraint being set at 520 bytes. Lastly, there is a mention of concern about hash collision, although it is unclear how it could be possible.Overall, the discussion revolves around the complexities and potential vulnerabilities of implementing Segregated Witness on the Bitcoin network, with various suggestions and concerns being raised by different participants. The goal is to find solutions that ensure the security and efficiency of transactions while avoiding any potential issues or conflicts. diff --git a/static/bitcoin-dev/June_2016/combined_Even-more-proposed-BIP-extensions-to-BIP-0070.xml b/static/bitcoin-dev/June_2016/combined_Even-more-proposed-BIP-extensions-to-BIP-0070.xml index 4e35fd3c75..18d4267ebf 100644 --- a/static/bitcoin-dev/June_2016/combined_Even-more-proposed-BIP-extensions-to-BIP-0070.xml +++ b/static/bitcoin-dev/June_2016/combined_Even-more-proposed-BIP-extensions-to-BIP-0070.xml @@ -2,7 +2,7 @@ 2 Combined summary - Even more proposed BIP extensions to BIP 0070 - 2025-09-26T15:32:12.291868+00:00 + 2025-10-11T21:42:15.081227+00:00 python-feedgen James MacWhyte 2016-06-24 05:27:36+00:00 @@ -161,10 +161,11 @@ + 2 Combined summary - Even more proposed BIP extensions to BIP 0070 - 2025-09-26T15:32:12.292093+00:00 + 2025-10-11T21:42:15.081458+00:00 2016-06-24T05:27:36+00:00 BIP0075 is an encrypted/encapsulated version of BIP70 that ensures the safe exchange of BIP70 messages through an intermediary. However, it has sparked a debate about user-friendliness and privacy in Bitcoin. Justin Newton suggests using software wallets like breadwallet to keep information private, as BIP75 allows direct exchange of identity information between peers without involving the blockchain or network. There are concerns about UK legislation compelling service providers to hand over data, but BIP75 and software wallets can help protect user privacy as the information is not stored on the blockchain. However, some people may need transactional identity for fraud reduction and regulatory reasons.The bitcoin-dev community is against implementing built-in anti-money laundering (AML) or know-your-customer (KYC) tools in Bitcoin, as it could draw expectations from all users to authorities. BIP75 allows voluntary identity exchange at the application level, without passing through or storing the blockchain. Peter Todd argues against participating in AML/KYC practices and suggests removing BIP75 from the bips repository and boycotting wallets that implement it. Pieter Wuille disagrees, stating that censorship based on personal opinion is not appropriate and that editorial control should be based on objective processes.The practicality of maintaining infrastructure for payment protocol is discussed, with some participants noting that it may be impractical for end users. There is also mention of an unencrypted version of BIP70 available via Bluetooth for face-to-face transfers.In terms of editorial control over BIPs, Pieter Wuille believes that some degree of editorial control is inevitable but should be restricted to objective processes. Peter Todd suggests rejecting BIP75 on ethical and strategic grounds, but Wuille disagrees and calls it ridiculous. The conversation then shifts to the acceptance of future BIPs related to AML/KYC support.The discussion also highlights the importance of incorporating subscriptions into the protocol to facilitate Bitcoin's use as a real payment system. It is suggested that subscription information should be stored in the customer's wallet, and wallets should be responsible for initiating subscriptions on behalf of users. Expanding Bitcoin URIs to include signatures is also recommended.The discussion on improving BIP0070 explores using JSON messages instead of Protocol Buffers, alternative schemes for merchant identification, and improving subscription support. There are debates over the efficiency and potential bugs of JSON and whether existing solutions like HTTPS or Keybase are sufficient. The debate between using Protocol Buffers or JSON for the protocol itself is also discussed, with considerations for efficiency, ease of use, and security. The need for additional PKI types and identity methods is addressed, along with suggestions to expand the pki_data slot in BIP0070. The BIP75 protocol is mentioned as a way to share identity information out-of-band, independently of any name resolution system. Suggestions are made to expand the pki_data slot in BIP75 to accommodate new identity types.Overall, the discussions emphasize the desire for improvements in the BIP0070 protocol, including the use of JSON messages, alternative merchant identification schemes, enhanced subscription support, and multi-mode identity mechanisms. Different opinions are presented regarding the best approach, considering factors such as user-friendliness, efficiency, extensibility, and privacy. diff --git a/static/bitcoin-dev/June_2016/combined_Merkle-trees-and-mountain-ranges.xml b/static/bitcoin-dev/June_2016/combined_Merkle-trees-and-mountain-ranges.xml index fb36a8b9c1..96e2a5273e 100644 --- a/static/bitcoin-dev/June_2016/combined_Merkle-trees-and-mountain-ranges.xml +++ b/static/bitcoin-dev/June_2016/combined_Merkle-trees-and-mountain-ranges.xml @@ -2,7 +2,7 @@ 2 Combined summary - Merkle trees and mountain ranges - 2025-09-26T15:32:08.064394+00:00 + 2025-10-11T21:42:10.835798+00:00 python-feedgen Bram Cohen 2016-07-15 23:00:57+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Merkle trees and mountain ranges - 2025-09-26T15:32:08.064609+00:00 + 2025-10-11T21:42:10.835988+00:00 2016-07-15T23:00:57+00:00 In an email exchange between Peter Todd and Bram Cohen, the topic of discussion revolves around various aspects of UTXO commitments, merkle trees, and optimizations. Todd suggests using BLAKE2b for internal hashing due to its efficiency in omitting padding when the data is exactly one block in size. The implementation of a root branch block with nodes arranged in fixed positions and terminals having outpointers to other blocks is also discussed. The conversation also delves into the efficiency of their implementation when stored on a spinning hard drive. It is estimated that even an underpowered node could keep up with the blockchain if it is full of simple transactions. Validating an entire blockchain history might take a few days, but if some layers are kept in regular memory, validating a whole year of history might only take a few hours. The complexity of the MMR proposal's data structures is acknowledged, and it is suggested that specifying storage media and latency expectations would clarify the reasoning significantly.Cohen considers committing to the prefix as a way of handling cases where multiple keys share parts of the same prefix, but concludes that it would only save about 10% of memory in his implementation. Todd explains that committing to the prefix is a simple but possibly not-optimal way of committing to what data should be accessible under a given node. They discuss the depths of merkbiner trees in proportion to log2(n) against attackers who are choosing keys by grinding hashes. The optimization of hashing time is also explored, with the mention of the efficiency of BLAKE2 compared to SHA256.The conversation then moves on to the implementation of merkle trees and how each node contains metadata byte followed by fixed-size secure hashes and pointers to the children. The structure of branch blocks, terminals, and leaf blocks is explained, along with the overflow mechanism when a leaf block exceeds its capacity. The idea of achieving practical Bitcoin updates with minimal cache misses is discussed, with Cohen explaining the clever placement of nodes in memory to minimize cache misses.Another aspect of the conversation revolves around adding latency to UTXO commitments. It is agreed that adding latency can work in principle but should only be used as a last resort technique when optimization fails. The addition of roots of what's added and deleted in each block allows for proofs of inclusion and exclusion without significant latency. However, it adds complexity and should only be done when necessary for fast validation before block propagation.The discussion also touches upon the indexing of the UTXO set, the possibility of introducing incentives for collecting dust, and the use of variable-sized commitments instead of hash digests for improved efficiency. There is a debate about whether validation before block propagation needs to be done at all, with Todd suggesting that it's reasonable to propagate blocks that have not been fully validated beyond checking PoW. The importance of minimizing the time it takes miners to start mining the next block and collecting fees is emphasized.There are additional conversations discussing the technicalities of TXO commitments, the differences between merkle trees and patricia tries, and the performance and optimization considerations of implementing UTXO, STXO, and TXO commitments. The use of mountain ranges for merkle trees is debated, with suggestions for alternative approaches such as raw merkle trees.In conclusion, the email exchanges provide detailed insights into the discussions surrounding UTXO commitments, merkle trees, optimizations, latency issues, and various implementation considerations within the Bitcoin community. The conversations highlight the complexities and trade-offs involved in designing efficient and secure blockchain data structures. diff --git a/static/bitcoin-dev/June_2016/combined_RFC-for-BIP-Derivation-scheme-for-P2WPKH-nested-in-P2SH-based-accounts.xml b/static/bitcoin-dev/June_2016/combined_RFC-for-BIP-Derivation-scheme-for-P2WPKH-nested-in-P2SH-based-accounts.xml index bd96cc90e4..1add8b6c8b 100644 --- a/static/bitcoin-dev/June_2016/combined_RFC-for-BIP-Derivation-scheme-for-P2WPKH-nested-in-P2SH-based-accounts.xml +++ b/static/bitcoin-dev/June_2016/combined_RFC-for-BIP-Derivation-scheme-for-P2WPKH-nested-in-P2SH-based-accounts.xml @@ -2,7 +2,7 @@ 2 Combined summary - RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts - 2025-09-26T15:32:05.950356+00:00 + 2025-10-11T21:42:08.712708+00:00 python-feedgen Aaron Voisine 2016-06-18 06:07:48+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts - 2025-09-26T15:32:05.950546+00:00 + 2025-10-11T21:42:08.712865+00:00 2016-06-18T06:07:48+00:00 On June 14, 2016, Daniel Weigl proposed a BIP for a P2SH accounts protocol on Github and sought feedback from the community. Aaron Voisine, co-founder and CEO of breadwallet, raised questions about the upcoming implementation of segwit version 2 with schnorr signatures and the possibility of supporting it without a third derivation path. However, no further information is provided regarding these questions.The discussion on the bitcoin-dev mailing list revolved around privacy concerns related to change outputs in transactions. One suggestion was to always use the same output type for change output if the wallet can recognize it. However, this method may still result in a privacy leak if there is only one P2PKH output and someone knows the algorithm being used. Another suggestion was to randomly select a change output that mimics one of the sending outputs to increase privacy. Additionally, to enhance privacy further, the redeemscript/witnessscript template should also be matched.Another discussion on the bitcoin-dev mailing list expressed concern about the privacy implications of using different output types for change outputs in transactions. It was suggested that "normal" send-to-single-address transactions should always use the same output type for the change output. To further enhance privacy, it was recommended to mimic one of the sending outputs by picking one at random if there are multiple "sending" outputs. The proposal also suggests matching the template of the redeemscript/witnessscript to maintain privacy even after the sends are spent.A proposal has been made to include both "native" P2WPKH addresses and P2WPKH over P2SH addresses in compatible wallets. The proposal suggests that every fully BIP-compatible wallet must support both address types. Different chain IDs could be used to differentiate between the address types, with 0 and 1 for P2WPKH over P2SH and 2 and 3 for native P2WPKH. Using P2WPKH over P2SH for change addresses instead of native P2WPKH is believed to potentially lead to a privacy leak. Therefore, it is recommended to always use the same output type for the change output in "normal" send-to-single-address transactions if the wallet can recognize it. However, there is no final decision yet on how the address encoding for P2WPKH public keys should look like as Bip141 is deferred.Daniel Weigl has proposed a BIP for P2SH accounts on the Bitcoin-dev mailing list and has requested comments and feedback from the community. He also asked if anyone is implementing something different for BIP44 compliant wallets. The question of whether to keep the discussion on the mailing list or move it to GitHub was raised. Jochen suggested considering not only P2WPKH over P2SH addresses but also "native" P2WPKH addresses and recommended that every fully BIP-compatible wallet should support both types of segwit addresses. Aaron Voisine's suggestion to use different chain IDs to distinguish between address types was also supported by Jochen.In summary, Daniel Weigl has prepared a proposal for a BIP related to a BIP44-compliant wallet and has sought feedback from the community. The discussion on the bitcoin-dev mailing list focused on privacy concerns related to change outputs and the inclusion of both P2WPKH over P2SH and "native" P2WPKH addresses in compatible wallets. Suggestions were made to enhance privacy by selecting the same output type for change outputs in "normal" send-to-single-address transactions and mimicking one of the sending outputs. The use of different chain IDs to differentiate between address types was also proposed. diff --git a/static/bitcoin-dev/June_2017/combined_Drivechain-RfD-Follow-Up.xml b/static/bitcoin-dev/June_2017/combined_Drivechain-RfD-Follow-Up.xml index c6cedb100a..c91be56afd 100644 --- a/static/bitcoin-dev/June_2017/combined_Drivechain-RfD-Follow-Up.xml +++ b/static/bitcoin-dev/June_2017/combined_Drivechain-RfD-Follow-Up.xml @@ -2,7 +2,7 @@ 2 Combined summary - Drivechain RfD -- Follow Up - 2025-09-26T15:56:37.228317+00:00 + 2025-10-11T22:07:58.525944+00:00 python-feedgen Paul Sztorc 2017-07-13 17:04:01+00:00 @@ -81,10 +81,11 @@ + 2 Combined summary - Drivechain RfD -- Follow Up - 2025-09-26T15:56:37.228492+00:00 + 2025-10-11T22:07:58.526144+00:00 2017-07-13T17:04:01+00:00 The discussion in the provided context revolves around the security and implementation of drivechains, softforks, and P2SH transactions. Hampus Sjöberg argues that for softforks, 100% of nodes and miners need to upgrade to new rules to prevent chain splits, while for drivechains, only interested nodes validate the other chain. Paul Sztorc agrees but points out that even if some percentage of the network is validating both chains in drivechains, there will be no chain split if miners improperly withdraw from a sidechain. However, he expresses concern about the possibility of sidechain theft turning into a campaign.Greg raises concerns about theft in drivechains and discusses two different usages of the word "theft." He also questions whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes. Experts suggest that delayed withdrawal techniques in drivechains can mitigate the threat of theft_2. The email thread further delves into the security of WT^ transactions compared to P2SH and SegWit transactions. The author expresses doubt that the security of WT^ transactions can match that of P2SH and SegWit transactions.The discussion also highlights the different modes of use for drivechains, ranging from not upgrading Bitcoin software to actively using sidechains. It is emphasized that miners cannot steal funds in drivechains due to automatic enforcement policies enforced by full nodes. Another email exchange between Greg Slepak and Paul Sztorc explores the Drivechain project and its comparison with P2SH. The conversation clarifies four different modes of use for drivechains and addresses the issue of theft in drivechains. It is noted that the security of WT^ transactions can be brought up to the same level as P2SH and SegWit transactions.The conversation also touches upon the feasibility of using a proof-of-burn sidechain as an alternative to merged mining for increased security. Erik Aronesty suggests users would tolerate depreciation due to cheap and secure transactions, but Paul Sztorc counters that this scheme would be more expensive and relatively less secure. The discussion also covers the role of UTXO commitments for sidechains and the potential impact on the main chain's incentive structure. The lightning model is mentioned as a way to prevent further centralization.Overall, the email exchanges provide insights into the technical details, security models, and potential implications of drivechains, softforks, and P2SH transactions. The discussions highlight different perspectives on the security and implementation of these concepts, as well as potential challenges and alternative approaches.In addition to the above context, there is a discussion about the concept of a proof-of-burn sidechain, which requires burning Bitcoin or side-chain tokens to mine the side chain. The size of the burn determines the degree of security. Users can have a secure sidechain that issues a mining reward in sidechain tokens, which can be aggregated and redeemed for Bitcoins. However, any Bitcoins held in the sidechain depreciate in value at a rate of X% per year, which pays for increased security. This functions like an altcoin with high inflation and cheap transactions but is pegged to Bitcoin's price due to the pool of unredeemed Bitcoins held within the side chain.Drivechain is another sidechain enabling technology that seeks to plug many blockchains into the main chain, removing the blocksize limit and addressing scalability concerns. However, there are concerns about centralization and user choice of custodians. The discussion also raises questions about the potential impact on user control over their Bitcoins, as well as the correlation between network security and economic value.There is a debate around whether merged mining or proof-of-burn is a better solution for sidechain security. Some argue that proof-of-burn may result in users avoiding the sidechain due to the depreciation of their Bitcoins, while others believe merged mining would be more competitive. UTXO commitments are also suggested as a way to enhance the security of sidechains.The conversation explores various scenarios and considerations related to implementing Drivechain, including miner control, theft, antifragility, and the ecological impact. The participants recognize the need to balance innovation and security, ensuring that any changes made to the Bitcoin network do not compromise its integrity.Overall, the context provides insights into different perspectives on sidechain technologies and their implications for the Bitcoin ecosystem. It highlights the ongoing discussions and debates within the Bitcoin community regarding scalability, security, centralization, and user control.Furthermore, in the provided context, it is mentioned that there is an 8 MB maxblocksize, which doubles every two years. This implies that the maximum block size in a certain system is initially set at 8 MB, and then it will double in size every two years. The doubling of the maxblocksize every two years suggests a potential increase in the system's capacity to handle larger amounts of data. This can be seen as a measure to accommodate the growing demand for storage space and processing power in various applications diff --git a/static/bitcoin-dev/June_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol.xml b/static/bitcoin-dev/June_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol.xml index a4a31a7a0f..67872f2f46 100644 --- a/static/bitcoin-dev/June_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol.xml +++ b/static/bitcoin-dev/June_2019/combined_New-BIP-v2-peer-to-peer-message-transport-protocol.xml @@ -2,7 +2,7 @@ 2 Combined summary - New BIP - v2 peer-to-peer message transport protocol - 2025-09-26T16:04:11.648047+00:00 + 2025-10-11T22:18:31.944891+00:00 python-feedgen Elichai Turkel 2019-06-17 17:13:05+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - New BIP - v2 peer-to-peer message transport protocol - 2025-09-26T16:04:11.648194+00:00 + 2025-10-11T22:18:31.945026+00:00 2019-06-17T17:13:05+00:00 In an email conversation between Elichai Turkel and Jonas Schnelli, the topic of the message sequence number for Chacha20 is discussed. Schnelli explains that the proposed AEAD in BIP324 uses a "message sequence number" as the nonce instead of a random nonce. The sequence number starts at 0 and cannot be reset without rekeying. Additionally, the maximum amount of traffic allowed before rekeying is 1GB, and there is no possibility of nonce/key reuse. While XChaCha20 allows for a random nonce, using a sequence number as a nonce is considered safe.The discussion also touches on the change from a 64-bit to a 96-bit nonce in RFC7539. Elichai suggests using the "message sequence number" as the nonce for Chacha20, which prompts a query about whether this number is randomly generated or a counter, and if it can be reset without rekeying. If the number is randomly generated, then a 64-bit nonce may not be secure enough, and it is suggested to either use Chacha20 from RFC7539, which has a 96-bit nonce and 32-bit counter, or manually increment the nonce every time. However, if the number is simply a counter, then a 64-bit nonce should suffice.This email thread emphasizes the importance of understanding nonce and its security implications when implementing cryptographic protocols. diff --git a/static/bitcoin-dev/June_2019/combined_bitcoin-dev-Digest-Vol-49-Issue-8.xml b/static/bitcoin-dev/June_2019/combined_bitcoin-dev-Digest-Vol-49-Issue-8.xml index 4bed2fbe23..1a34c963e4 100644 --- a/static/bitcoin-dev/June_2019/combined_bitcoin-dev-Digest-Vol-49-Issue-8.xml +++ b/static/bitcoin-dev/June_2019/combined_bitcoin-dev-Digest-Vol-49-Issue-8.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 49, Issue 8 - 2025-09-26T16:04:13.758417+00:00 + 2025-10-11T22:18:34.066879+00:00 python-feedgen Emil Engler 2019-06-09 18:56:47+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 49, Issue 8 - 2025-09-26T16:04:13.758570+00:00 + 2025-10-11T22:18:34.067009+00:00 2019-06-09T18:56:47+00:00 When utilizing the testnet, it is necessary to address resets. Although a more advantageous option exists, miners continue to rely on the testnet for testing new firmware versions, hardware prototypes, and operation services. The most recent reset occurred in 2011, preceded by two previous resets. As of now, the difficulty levels are expected to remain steady.The focal point of the discussion revolves around the decision of whether or not to reset the testnet, despite the existence of a potentially superior alternative. Miners still find value in using the testnet for testing purposes, including the evaluation of new firmware versions, hardware prototypes, and operation services. It is crucial to acknowledge that the difficulty levels will remain consistent in the foreseeable future. diff --git a/static/bitcoin-dev/June_2020/combined_-was-BIP-OP-CHECKTEMPLATEVERIFY-Fee-Bumping-Operation.xml b/static/bitcoin-dev/June_2020/combined_-was-BIP-OP-CHECKTEMPLATEVERIFY-Fee-Bumping-Operation.xml index 61315790e1..c202567116 100644 --- a/static/bitcoin-dev/June_2020/combined_-was-BIP-OP-CHECKTEMPLATEVERIFY-Fee-Bumping-Operation.xml +++ b/static/bitcoin-dev/June_2020/combined_-was-BIP-OP-CHECKTEMPLATEVERIFY-Fee-Bumping-Operation.xml @@ -2,7 +2,7 @@ 2 Combined summary - [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation - 2025-09-26T16:00:08.400838+00:00 + 2025-10-11T22:14:10.580791+00:00 python-feedgen Dmitry Petukhov 2020-06-08 07:15:11+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation - 2025-09-26T16:00:08.400988+00:00 + 2025-10-11T22:14:10.580936+00:00 2020-06-08T07:15:11+00:00 A proposal was made on the bitcoin-dev mailing list to introduce a new type of transaction called PFN (Parent Fixing Nonce) that aims to fix stuck transactions by modifying their parent transactions. However, concerns were raised about the feasibility and complexity of implementing this proposal due to the requirement of a new index of all past transactions for consensus.In response to these concerns, another proposal was suggested for a Fee Bump transaction. This transaction would target a list of TXIDs or a single TXID representing all ancestors it wants to include in a block. The goal is to make it similar to normal transactions for inclusion, with potential minimums for mempool inclusion. However, there are still questions regarding whether the sender of a PFN transaction could Replace-By-Fee (RBF) it or increase the fee for its parent transactions without being able to replace any other transactions besides their own.To address application-DoS attacks in the mempool beyond CTV (CheckTemplateVerify), a potential solution is proposed: the "Pay for Neighbor" transaction. With this approach, a transaction can specify that it wants to pay the fee for another transaction(s). This creates a 'ghost child' transaction that can only be mined if its 'ghost parents' are confirmed as well. This method is essentially Child-Pays-for-Parent (CPFP) but ensures that the examined link is always one hop away, reducing CPFP graph traversal issues. However, the existing CPFP logic is not working as expected, and it may be necessary to remove CPFP entirely to make fee bumping work smoothly.A Fee Bump transaction can name a list of TXIDs or a single TXID that represents all ancestors it wishes to include in a block. It must be included in that block and should have no unconfirmed ancestors or children. Transactions in the mempool can set a flag to opt out of CPFP for descendants/blocks to prevent pinning. Channel protocols should use this feature to prevent pinning and then use the Fee Bump transaction to add fees to transactions that need to be processed.There is also a suggestion to use the annex or anyone-can-spend output for this purpose. If implemented correctly, a coinswap protocol could be layered with the fee-bumping transactions change, providing privacy benefits. Initially, this idea required a hardfork, but it could potentially be achieved as a soft fork past-taproot by including the txids of 'ghost parents' in the taproot annex. However, creating a new index of all past transactions for consensus would be problematic and cannot be done. diff --git a/static/bitcoin-dev/June_2020/combined_Hash-based-accumulators-with-quick-insertion.xml b/static/bitcoin-dev/June_2020/combined_Hash-based-accumulators-with-quick-insertion.xml index dc25c6f70e..5c0ae4cf20 100644 --- a/static/bitcoin-dev/June_2020/combined_Hash-based-accumulators-with-quick-insertion.xml +++ b/static/bitcoin-dev/June_2020/combined_Hash-based-accumulators-with-quick-insertion.xml @@ -2,7 +2,7 @@ 2 Combined summary - Hash-based accumulators with quick insertion - 2025-09-26T16:00:23.323045+00:00 + 2025-10-11T22:14:12.705439+00:00 python-feedgen German Luna 2020-06-08 22:01:09+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Hash-based accumulators with quick insertion - 2025-09-26T16:00:23.323189+00:00 + 2025-10-11T22:14:12.705602+00:00 2020-06-08T22:01:09+00:00 A mathematician named Germán expressed interest in a piece of work and suggested a method to indirectly support addition and removal by formulating it as a difference of sets, similar to collision-resistant replicated data types (CRDTs). This suggestion involves checking for membership through CheckMembershipInAdditionSet && !CheckMembershipInRemovalSet. Germán also mentioned the possibility of supporting multiple addition/removal by attaching a count of how many times an item has been added, but this may disrupt some aspects of the paper.The author has been focusing on cryptographic accumulators that optimize for quick insertion. Accumulators are data structures that maintain compact commitments to a potentially large set while keeping proofs of membership short. The author's focus is on additive accumulators that support adding new elements but not removing them. The motivation behind this is to enable Script to access an arbitrarily large portion of the blockchain history and state. The author has developed two constructions: 1. An accumulator with insertion time O(1) and proof size O(log^2 n).2. A construction with insertion time O(log log n) and proof size O(log n log log n).The draft writeup and sample python code for these constructions are available on Github. Although the ideas presented in the draft are still unfinished, they are clear and easy to understand. The author is sharing the work at this stage to receive feedback for improving the constructions, covering related work, and exploring potential applications in Bitcoin. One notable application in Bitcoin is the creation of lightweight full nodes that do not require storing the UTXO set, known as the Utreexo accumulator.Overall, the mathematician's comment sparked interest in the work, and the author has been working on cryptographic accumulators that optimize for quick insertion. The author has developed two constructions and is seeking feedback to enhance the constructions, explore related work, and uncover potential applications in Bitcoin, such as lightweight full nodes using the Utreexo accumulator. The draft writeup and sample python code are available on Github for further examination. diff --git a/static/bitcoin-dev/June_2021/combined_Opinion-on-proof-of-stake-in-future.xml b/static/bitcoin-dev/June_2021/combined_Opinion-on-proof-of-stake-in-future.xml index b2cc37c2fd..d7509e774a 100644 --- a/static/bitcoin-dev/June_2021/combined_Opinion-on-proof-of-stake-in-future.xml +++ b/static/bitcoin-dev/June_2021/combined_Opinion-on-proof-of-stake-in-future.xml @@ -2,7 +2,7 @@ 2 Combined summary - Opinion on proof of stake in future - 2025-09-26T15:39:28.411095+00:00 + 2025-10-11T21:50:30.408373+00:00 python-feedgen Billy Tetrud 2021-06-26 16:26:12+00:00 @@ -273,10 +273,11 @@ + 2 Combined summary - Opinion on proof of stake in future - 2025-09-26T15:39:28.411363+00:00 + 2025-10-11T21:50:30.408680+00:00 2021-06-26T16:26:12+00:00 The ongoing debate within the bitcoin-dev community revolves around the compatibility of Proof of Stake (PoS) with Bitcoin's objectives. Some argue that PoS contradicts Bitcoin's permissionless nature and introduces trust into the system, while others propose alternatives like Proof of Burn (PoB) but acknowledge block timing issues. Overall, consensus is that new consensus algorithms must meet high standards, and PoS has not yet demonstrated properties consistent with Bitcoin's objectives.Verifiable Delay Functions (VDFs) are being discussed as a potential solution to regulate block times in proof-of-burn blockchains. However, concerns exist regarding ways to increase sequential speed without compromising energy consumption. Despite these concerns, there are promising developments with VDFs that could address block regulation problems without relying solely on brute-force search PoW.Reducing the block reward in Bitcoin has been proposed as a means to improve its mainstream reputation and reduce energy expenditure. However, it should be noted that the block reward is already being reduced through halving events every four years. Concerns about the environmental impact of Bitcoin mining persist, with estimates suggesting that it consumes more energy than entire countries. Arguments in favor of Bitcoin's energy consumption include the use of renewable energy sources for mining and the potential for Bitcoin to incentivize the development of a more sustainable energy grid.Discussions also revolve around the potential of chip fabs to eliminate the hardware barrier and allow more people to participate in Bitcoin mining. It is believed that the energy economy still has more supply than competition, and as prices drop, renewable energy would outcompete nonrenewable sources. The impact of Bitcoin mining on energy usage is seen as an opportunity for investment in renewable energy sources rather than a cause for shame.Various perspectives on PoS as a consensus mechanism for Bitcoin mining are presented. Some argue against implementing PoS due to security concerns and concentration of power. Others believe that PoS may have advantages for other cryptocurrencies but may not be the best solution for Bitcoin. The discussions highlight the need to find sustainable solutions for mining and energy consumption in the cryptocurrency space, with ongoing exploration of alternatives such as VDFs. diff --git a/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork.xml b/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork.xml index d5ba6191fe..13e43e43e3 100644 --- a/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork.xml +++ b/static/bitcoin-dev/June_2021/combined_Trinary-Version-Signaling-for-softfork.xml @@ -2,7 +2,7 @@ 2 Combined summary - Trinary Version Signaling for softfork - 2025-09-26T15:39:22.054790+00:00 + 2025-10-11T21:50:28.283980+00:00 python-feedgen Eric Voskuil 2021-06-30 18:11:06+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Trinary Version Signaling for softfork - 2025-09-26T15:39:22.054941+00:00 + 2025-10-11T21:50:28.284136+00:00 2021-06-30T18:11:06+00:00 In a recent email exchange between Zac Greenwood and Eric Voskuil, the topic of whether a node enforces consensus rules in Bitcoin was debated. Voskuil argued that it is up to economic nodes, people who refuse to accept invalid money, to enforce consensus rules. Greenwood disagreed, stating that nodes do enforce consensus rules by disregarding invalid transactions and blocks. He provided examples from the BCH split to support his argument. The debate continued with Greenwood asserting that non-economic nodes are ignored by the network, while Voskuil emphasized the role of merchants in enforcing consensus rules.Another discussion focused on the relationship between game theory and Bitcoin. Voskuil expressed skepticism regarding the relevance of game theory to Bitcoin, stating that he has not seen any demonstration of their connection. He also clarified that mining pools and exchanges do not necessarily discuss before signaling for a soft fork. Miners can mine whatever they want and earn block rewards. Voskuil further explained that consensus rules are enforced by merchants who reject trading for something they don't consider money. The conversation highlighted the misunderstanding of signaling as voting and emphasized the complexity of enforcing consensus rules.Further discussions explored the enforcement of consensus rules in the Bitcoin network. One participant argued that it is ultimately up to individuals to enforce the decision to reject invalid transactions, while another participant asserted that nodes definitely enforce consensus rules and define what Bitcoin is. The conversations also touched on topics such as chain splits, soft fork signaling, and the role of miners. The participants offered different perspectives, highlighting the complexity and differing viewpoints surrounding the enforcement of consensus rules.Voskuil responded to questions related to Bitcoin's consensus rules and mining, noting that two people on different rules imply a chain split. He highlighted the absence of a concept of "the rules" and questioned why miners would mine a chain that nobody wants to use. Voskuil expressed uncertainty about the relevance of game theory to Bitcoin and clarified that a node does not enforce anything. He emphasized the role of merchants in enforcing consensus rules and addressed misconceptions about soft fork signaling. Voskuil stated that miners mine whichever chain they want and earn block rewards, and that signaling is not equivalent to voting.In summary, the discussions revolved around the enforcement of consensus rules in the Bitcoin network. While there were differing opinions, it was acknowledged that both nodes and merchants play a role in enforcing these rules. The complexity of enforcing consensus rules, the relevance of game theory, and the misconceptions surrounding soft fork signaling were also highlighted. Ultimately, the conversations showcased the multiple perspectives and challenges associated with maintaining consensus in the Bitcoin network. diff --git a/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml index 9b83a75720..900ff37bfd 100644 --- a/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/June_2022/combined_Packaged-Transaction-Relay.xml @@ -2,7 +2,7 @@ 2 Combined summary - Packaged Transaction Relay - 2025-09-26T15:46:37.840027+00:00 + 2025-10-11T21:57:29.157479+00:00 python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -70,10 +70,11 @@ + 2 Combined summary - Packaged Transaction Relay - 2025-09-26T15:46:37.840214+00:00 + 2025-10-11T21:57:29.157700+00:00 2022-10-10T22:05:38+00:00 The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. diff --git a/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml b/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml index 2ed24658a3..3e77cfefa1 100644 --- a/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml +++ b/static/bitcoin-dev/June_2022/combined_Why-OpenTimestamps-does-not-linearize-its-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - Why OpenTimestamps does not "linearize" its transactions - 2025-09-26T15:46:35.708155+00:00 + 2025-10-11T21:57:27.030442+00:00 python-feedgen Peter Todd 2022-06-19 11:04:50+00:00 @@ -62,10 +62,11 @@ + 2 Combined summary - Why OpenTimestamps does not "linearize" its transactions - 2025-09-26T15:46:35.708311+00:00 + 2025-10-11T21:57:27.030600+00:00 2022-06-19T11:04:50+00:00 In a recent email exchange on the bitcoin-dev mailing list, concerns were raised regarding the use of OpenTimestamps (OTS) for timestamping. One user expressed worry about the requirement to publicize .ots files and suggested including more cryptographic information in the original OP_RETURN to eliminate the need for this. However, it was clarified that publication is not actually a part of the OTS system.The discussion also touched upon the issue of security with .ots files when shared with other parties. Without cryptographic pinning, there is a possibility that a fourth party could replace the .ots file, changing the timestamp to a later date and compromising the validity of the data. Additionally, there were concerns about the potential loss of transaction history containing OTS hashes in chain forks.Another user highlighted the limitations of OTS in proving the timing and uniqueness of documents. While OTS can prove the duration of a document, it cannot demonstrate its shortness or whether an earlier version was already published. The user referred to this as the system being "designed to be broken" as it allows individuals to rewrite history by republishing others' documents under different contexts.The conversation also delved into the scalability and efficiency of OTS. It was noted that through the use of merkle trees, OTS can timestamp tens of thousands of messages with a single transaction, making it a more efficient option. However, there were suggestions for additional measures to ensure the security and uniqueness of timestamps, such as publicizing nonces and document hashes with user consent.Overall, the discussions highlighted the complexities and considerations involved in using timestamp services like OpenTimestamps. While they provide valuable information about the existence of content at a given time, there are limitations and security concerns that need to be addressed to ensure the validity and reliability of the timestamps.In the context of proving the existence of a message prior to a certain point in time, linearization is not considered as a viable solution. The focus is on verifying statements about messages rather than timestamp proofs. To address this issue, random beacons provide a solution by offering dual-sided bounds on the creation time of messages. By creating messages that are known to have been created after a specific point in time and with an unpredictable prior, the accuracy of timestamp proofs can be ensured.For use-cases that require day to hour level precision, Bitcoin block hashes serve as an effective random beacon. However, for higher precision absolute time, there are several trusted alternatives available. These include the NIST random beacon and Roughtime, among others.Overall, random beacons offer a way to establish the creation time of messages, allowing for the verification of statements without relying solely on timestamp proofs. Whether using Bitcoin block hashes or other trusted alternatives, random beacons provide a valuable tool for various precision requirements. diff --git a/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml b/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml index e1b63adaa1..cf626465ca 100644 --- a/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml +++ b/static/bitcoin-dev/June_2022/combined_bitcoin-dev-Digest-Vol-85-Issue-4.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 85, Issue 4 - 2025-09-26T15:46:39.955695+00:00 + 2025-10-11T21:57:31.282570+00:00 python-feedgen Billy Tetrud 2022-06-15 04:02:38+00:00 @@ -18,10 +18,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 85, Issue 4 - 2025-09-26T15:46:39.955828+00:00 + 2025-10-11T21:57:31.282756+00:00 2022-06-15T04:02:38+00:00 The concept of consensus in Bitcoin involves trust, which is measured using a mechanism called Trust Metric. The Ford Fulkerson Max Flow Algorithm is used to convert an unordered graph of "Trust Declarations" into a Directed Acyclic Graph with weighting to prevent faults. Sybil resistance is achieved by linking pseudo-identities to trusted individuals and requiring a minimum number of Trust Declarations. However, attackers can still pose as trustworthy individuals. Negative Certs were considered but not implemented due to potential harm.Maintaining the system requires discipline and does not incentivize people without risking bribery. Getting people to pay BTC to make declarations of trust is difficult. There was a discussion about whether developers are paid enough in BTC to afford making declarations, and the idea of separating the Declaration from the payment threshold was proposed. This would allow anyone to enter a zero-value transaction with a Declaration of Trust, but independent post-processing would determine inclusion in the Graph Processing.Luke Kenneth Casson Leighton suggests that trust metrics could address misinformation undermining Bitcoin. Trust metrics are similar to the Bitcoin protocol and could benefit the ecosystem. Trust metrics quantify who's trusted among a set of people and can be used to answer questions about Bitcoin. Public declarations of trust and Maximum-Flow Graph analysis help filter out spam. Colluding users farming aliases can game trust metrics, but Sybil resistance can be bolstered by charging fees or requiring proof of funds. Adding trust metrics evaluation to the Bitcoin protocol would help developers evaluate whom to trust for protocol development.AliceXBT discusses misinformation being used to undermine Bitcoin and suggests Trust Metrics as a solution. She mentions advogato.org as a successful experiment in this regard. Public declarations of trust and Maximum-Flow Graph analysis help filter out false information. AliceXBT finds it ironic that trust metric evaluation was not added to the Bitcoin protocol from the start, hindering developers' ability to evaluate whom to trust for protocol development. diff --git a/static/bitcoin-dev/June_2023/combined_Scaling-and-anonymizing-Bitcoin-at-layer-1-with-client-side-validation.xml b/static/bitcoin-dev/June_2023/combined_Scaling-and-anonymizing-Bitcoin-at-layer-1-with-client-side-validation.xml index 372887e76e..df42906c81 100644 --- a/static/bitcoin-dev/June_2023/combined_Scaling-and-anonymizing-Bitcoin-at-layer-1-with-client-side-validation.xml +++ b/static/bitcoin-dev/June_2023/combined_Scaling-and-anonymizing-Bitcoin-at-layer-1-with-client-side-validation.xml @@ -2,7 +2,7 @@ 2 Combined summary - Scaling and anonymizing Bitcoin at layer 1 with client-side validation - 2025-09-26T14:23:47.132446+00:00 + 2025-10-11T21:42:40.589659+00:00 python-feedgen Dr Maxim Orlovsky 2023-06-14 20:14:26+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Scaling and anonymizing Bitcoin at layer 1 with client-side validation - 2025-09-26T14:23:47.132602+00:00 + 2025-10-11T21:42:40.589811+00:00 2023-06-14T20:14:26+00:00 Dr. Maxim Orlovsky, in response to comments from Peter, agrees that the section describing the timestamping service should be extended. He clarifies that the term "timestamping" refers to the knowledge of certain facts prior to a specific moment in time. He also explains that the term "timechain" is used as a historical reference. In regards to Peter's claim about scalability, Maxim disagrees and states that the consensus layer only includes headers of fixed size, eliminating the need for sharding. Other data are client-side and shared by network users. Each user tracks and keeps data relevant to their part of the state history. The miners producing headers and PMTs act independently.Maxim acknowledges the data availability problem as the main issue but proposes several solutions. The most promising one involves allowing anyone to witness if a miner hasn't released data from a previous PMT. Miners would then include the missing data in subsequent headers to demonstrate its existence. He suggests adding fees cryptoeconomics, where miners would lose fees if they fail to provide the required data. Maxim confirms that he is proposing a proof-of-publication-based single-use-seal and admits that the smart contract protocol and P2P network structure were not discussed in detail in the paper. However, he agrees with Peter that the exact details of the P2P network are not crucial at this point.On June 1, 2023, Dr. Maxim Orlovsky announced the release of the RGB smart contract system by LNP/BP Standards Association. This system aims to upgrade the Bitcoin layer 1 - blockchain by introducing client-side validation. The proposal, called Prime, offers a scalable and completely anonymous layer 1 that can handle billions of transactions per minute. It doesn't require a softfork or miners upgrade and won't affect users who choose not to upgrade. Lightning Network and other layer 2 systems will become redundant. The white paper for the proposal can be found on GitHub. However, criticisms have been raised regarding the design of the timestamping service and scalability claims.To address these concerns, Maxim suggests reading two papers that provide more details on scalable single-use-seal asset transfer and tree chains. In response to John Tromp's question about Bitcoin Proof of Work (PoW) anchoring, Maxim refers to their paper, which explains the consequences if a miner spends the current miner single-use-seal without proper commitment or sufficient PoW. The issue of PMT availability and consensus among miners is still unclear and requires further discussion.The LNP/BP Standards Association plans to establish a working group for the formal specification and reference implementation of the new layer. They also aim to organize educational and workshop activities. Funding will be raised through non-profit donations, as the infrastructural effort should not be managed by a for-profit company. Interested parties can contact them via email, and for-profit organizations can become members of the Association to contribute to the future development of Bitcoin technologies. diff --git a/static/bitcoin-dev/June_2023/combined_postr-p2n-payjoin-using-nostr.xml b/static/bitcoin-dev/June_2023/combined_postr-p2n-payjoin-using-nostr.xml index bfe44cfef4..4976781617 100644 --- a/static/bitcoin-dev/June_2023/combined_postr-p2n-payjoin-using-nostr.xml +++ b/static/bitcoin-dev/June_2023/combined_postr-p2n-payjoin-using-nostr.xml @@ -2,7 +2,7 @@ 2 Combined summary - postr: p2n payjoin using nostr - 2025-09-26T14:23:49.277713+00:00 + 2025-10-11T21:42:42.712853+00:00 python-feedgen alicexbt 2023-06-12 19:28:47+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - postr: p2n payjoin using nostr - 2025-09-26T14:23:49.277895+00:00 + 2025-10-11T21:42:42.713010+00:00 2023-06-12T19:28:47+00:00 In an email thread, a discussion is taking place regarding a proof of concept for using nostr npub and relays for payjoin. The method of using SIGHASH_NONE is explained, where there is no change in the transaction and the sender wants to spend the entire UTXO for the payment. However, this allows the receiver to have control over the funds and anyone who sees the final broadcasted transaction can extract the sender's input for any purpose.The use of specific SIGHASH flags can be ignored by developers, as they can use other flags or the default option. It is mentioned that there are no incentives for the sender or recipient to use RBF (Replace-by-Fee) and double spend in a payjoin transaction. To secure all outputs, it is suggested to use SIGHASH_ALL by the recipient, based on the understanding of SIGHASH flags and a blog post by Raghav Sood. However, it is pointed out that this method is still vulnerable, as mentioned in a tweet thread by Symphonicbtc.Furthermore, the email suggests disabling the ability to use mainnet coins directly in the code, emphasizing that it is highly irresponsible to post in this state. It is also warned that this proof of concept is not a proper implementation of a payjoin, even in a theoretical scenario, as it is easy to discern which inputs belong to the sender and receiver respectively in the final transaction.In another development, a Bitcoin developer has shared a proof of concept for payjoin (p2ep) that eliminates the need for a personal server, addressing concerns about its adoption. Unlike the stowaway method used by samourai, the developer's proposal only requires common nostr relays between the sender and recipient. The repository for this proof of concept can be found on GitLab, and a demo video showcasing the concept is available on YouTube. diff --git a/static/bitcoin-dev/June_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml b/static/bitcoin-dev/June_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml index 85ec8fafe9..649be02135 100644 --- a/static/bitcoin-dev/June_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml +++ b/static/bitcoin-dev/June_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP39 Extension for Manual Seed Phrase Creation - 2025-09-26T14:30:46.413688+00:00 + 2025-10-11T21:57:24.900998+00:00 python-feedgen Russell OConnor 2025-06-04 17:45:00+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - BIP39 Extension for Manual Seed Phrase Creation - 2025-09-26T14:30:46.413846+00:00 + 2025-10-11T21:57:24.901153+00:00 2025-06-04T17:45:00+00:00 The discussion explores the nuances and potential improvements to the BIP39 checksum mechanism, focusing on alternative methods for generating and verifying mnemonic phrases. The conversation begins with an acknowledgment of the possible advantages in manually generating randomness over relying on computer chips' hidden processes. It introduces BIP-93, also known as codex32, as a protocol that supports both human and computer-generated randomness, facilitating secret sharing and emphasizing transparency in the generation process. This approach addresses concerns about the opacity of current systems and suggests a method that could enhance user trust and security. diff --git a/static/bitcoin-dev/March_2012/combined_0-7-merge-recommendations-status.xml b/static/bitcoin-dev/March_2012/combined_0-7-merge-recommendations-status.xml index 8deab1c7ec..9019a440ab 100644 --- a/static/bitcoin-dev/March_2012/combined_0-7-merge-recommendations-status.xml +++ b/static/bitcoin-dev/March_2012/combined_0-7-merge-recommendations-status.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.7 merge recommendations/status - 2023-08-01T03:24:59.640736+00:00 + 2025-10-11T22:17:38.819707+00:00 + python-feedgen Pieter Wuille 2012-03-31 12:28:28+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - 0.7 merge recommendations/status - 2023-08-01T03:24:59.640736+00:00 + 2025-10-11T22:17:38.819834+00:00 - In a recent email thread, Michael Grønager has proposed pushing libcoin to bitcoin as a solution to various issues. He is willing to change the copyright/license if necessary but notes that a license change would be required for any merging to occur. Libcoin, unlike bitcoin, is designed without global thread mutexes and does not block the main thread due to rpc methods, except for a sendto. Additionally, a reorganize operation only briefly locks the main thread while the final commit is made. While Pieter Wuille likes the design and refactorings of libcoin, he expresses some concerns about its thread-safety. He suggests implementing reader and writer locks in each publicly accessible method of BlockChain to ensure proper synchronization. The libcoin rpc supports keep_alive and pipelining and runs in its own thread, but it can also run in the same thread as the node using async operation. Implementing IPv6 support in libcoin is relatively easy, as the CAddress/Endpoint class is already implemented as a subclass of boost::endpoint. The main obstacle to implementing IPv6 support is deciding on an IPv6 format on IRC. Lastly, Pieter suggests reversing the order of the last 12 bytes in the address database since they are opposite to boost.In regard to updates for bitcoin version 0.7, Luke-Jr provides a list of changes that are ready for merging. These include multithreaded JSON-RPC with keep-alive support, optimized ToHex function, FastGetWork, getalltransactions, and getblock_full. Luke-Jr also calls for better encapsulation of wallet and blockchain data structures to allow for safe multithreaded RPC. Pieter's IPv6 support is nearing completion, although there are still some issues to address, such as relaying and potential risks for DoS or other vulnerabilities. Enabling IPv6 support could open up possibilities for bitcoin to function as a Tor or I2P hidden service.Pieter Wuille raises the issue of nodes accidentally connecting to themselves in an email thread. With the switch to IPv6 and multiple local addresses, the chances of this happening increase. There are potential risks involved, including DoS vulnerabilities. However, Pieter later clarifies that he meant two nodes connecting twice to each other, for which there is already protection in place.Luke-Jr provides a compilation of changes ready for merging into bitcoin version 0.7. He suggests starting the release candidate (RC) process and mentions the need for rebasing the first merge. Some changes that have already been acknowledged for 0.7 include Hearn's "pong" message and Wladimir's Visual C++ 2010 fixes. The standardization of getmemorypool BIP is also acknowledged, but it might be better to wait until later in the merge window. Luke-Jr highlights the importance of merging multithreaded JSON-RPC with keep-alive support, as it has undergone extensive testing and is crucial for high-volume bitcoind usage. Other optimizations by Joel, such as the optimized ToHex function and FastGetWork, significantly improve the performance of JSON-RPC. Additionally, Pieter's getalltransactions and Luke-Jr's getblock_full provide the necessary functionalities to replace Jeff's old dumpblock call with bitcoind's new getblock. There are several other changes proposed, including refactoring the coin selection algorithm, implementing the standard reopen-log-files-on-SIGHUP, and adding a JSON-RPC call to customize fee requirements. Scott has submitted a pull request for Bitcoin-Qt to behave more like other close-to-systray applications, and Nils is working on a complete redesign of Bitcoin-Qt's user interface. Coderrr's Coin Control features are also nearing completion and should be merged soon. Lastly, there is hope that Pieter's IPv6 support will be ready for version 0.7, although only support for multiple local IPs has been submitted so far. 2012-03-31T12:28:28+00:00 + In a recent email thread, Michael Grønager has proposed pushing libcoin to bitcoin as a solution to various issues. He is willing to change the copyright/license if necessary but notes that a license change would be required for any merging to occur. Libcoin, unlike bitcoin, is designed without global thread mutexes and does not block the main thread due to rpc methods, except for a sendto. Additionally, a reorganize operation only briefly locks the main thread while the final commit is made. While Pieter Wuille likes the design and refactorings of libcoin, he expresses some concerns about its thread-safety. He suggests implementing reader and writer locks in each publicly accessible method of BlockChain to ensure proper synchronization. The libcoin rpc supports keep_alive and pipelining and runs in its own thread, but it can also run in the same thread as the node using async operation. Implementing IPv6 support in libcoin is relatively easy, as the CAddress/Endpoint class is already implemented as a subclass of boost::endpoint. The main obstacle to implementing IPv6 support is deciding on an IPv6 format on IRC. Lastly, Pieter suggests reversing the order of the last 12 bytes in the address database since they are opposite to boost.In regard to updates for bitcoin version 0.7, Luke-Jr provides a list of changes that are ready for merging. These include multithreaded JSON-RPC with keep-alive support, optimized ToHex function, FastGetWork, getalltransactions, and getblock_full. Luke-Jr also calls for better encapsulation of wallet and blockchain data structures to allow for safe multithreaded RPC. Pieter's IPv6 support is nearing completion, although there are still some issues to address, such as relaying and potential risks for DoS or other vulnerabilities. Enabling IPv6 support could open up possibilities for bitcoin to function as a Tor or I2P hidden service.Pieter Wuille raises the issue of nodes accidentally connecting to themselves in an email thread. With the switch to IPv6 and multiple local addresses, the chances of this happening increase. There are potential risks involved, including DoS vulnerabilities. However, Pieter later clarifies that he meant two nodes connecting twice to each other, for which there is already protection in place.Luke-Jr provides a compilation of changes ready for merging into bitcoin version 0.7. He suggests starting the release candidate (RC) process and mentions the need for rebasing the first merge. Some changes that have already been acknowledged for 0.7 include Hearn's "pong" message and Wladimir's Visual C++ 2010 fixes. The standardization of getmemorypool BIP is also acknowledged, but it might be better to wait until later in the merge window. Luke-Jr highlights the importance of merging multithreaded JSON-RPC with keep-alive support, as it has undergone extensive testing and is crucial for high-volume bitcoind usage. Other optimizations by Joel, such as the optimized ToHex function and FastGetWork, significantly improve the performance of JSON-RPC. Additionally, Pieter's getalltransactions and Luke-Jr's getblock_full provide the necessary functionalities to replace Jeff's old dumpblock call with bitcoind's new getblock. There are several other changes proposed, including refactoring the coin selection algorithm, implementing the standard reopen-log-files-on-SIGHUP, and adding a JSON-RPC call to customize fee requirements. Scott has submitted a pull request for Bitcoin-Qt to behave more like other close-to-systray applications, and Nils is working on a complete redesign of Bitcoin-Qt's user interface. Coderrr's Coin Control features are also nearing completion and should be merged soon. Lastly, there is hope that Pieter's IPv6 support will be ready for version 0.7, although only support for multiple local IPs has been submitted so far. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_A-better-Spanish-translation-for-vulnerability-page.xml b/static/bitcoin-dev/March_2012/combined_A-better-Spanish-translation-for-vulnerability-page.xml index 595e0b5266..59dabe7f1a 100644 --- a/static/bitcoin-dev/March_2012/combined_A-better-Spanish-translation-for-vulnerability-page.xml +++ b/static/bitcoin-dev/March_2012/combined_A-better-Spanish-translation-for-vulnerability-page.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A better Spanish translation for vulnerability page - 2023-08-01T03:24:06.473691+00:00 + 2025-10-11T22:17:43.067688+00:00 + python-feedgen Jorge Timón 2012-03-19 09:35:56+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - A better Spanish translation for vulnerability page - 2023-08-01T03:24:06.473691+00:00 + 2025-10-11T22:17:43.067838+00:00 - A security flaw has been discovered in Bitcoin-Qt for Windows versions 0.5 to 0.6, prompting users to take immediate action. The flaw could potentially allow an attacker to hang the program or execute remote code if an unexpected closure occurs. To mitigate the risk, users are advised to update their software to either version 0.5.3.1 or 0.6rc4. It is important to note that this security flaw does not affect the Mac, Linux, or command line (bitcoind) versions of Bitcoin-Qt.The severity of the incident is considered critical due to the possibility of remote code execution. While it may be difficult for an attacker to do more than block the Bitcoin-Qt process, the potential for unexpected closure raises concerns. In response, users are urged to download the updated software from SourceForge. Windows users can choose between version 0.6rc or 0.5.3.1, while Linux users should opt for version 0.5.3.For any further inquiries or questions regarding this issue, users can visit the IRC channel #bitcoin-dev on Freenode. It is crucial for users to take immediate action and update their Bitcoin-Qt software to protect against potential security risks. 2012-03-19T09:35:56+00:00 + A security flaw has been discovered in Bitcoin-Qt for Windows versions 0.5 to 0.6, prompting users to take immediate action. The flaw could potentially allow an attacker to hang the program or execute remote code if an unexpected closure occurs. To mitigate the risk, users are advised to update their software to either version 0.5.3.1 or 0.6rc4. It is important to note that this security flaw does not affect the Mac, Linux, or command line (bitcoind) versions of Bitcoin-Qt.The severity of the incident is considered critical due to the possibility of remote code execution. While it may be difficult for an attacker to do more than block the Bitcoin-Qt process, the potential for unexpected closure raises concerns. In response, users are urged to download the updated software from SourceForge. Windows users can choose between version 0.6rc or 0.5.3.1, while Linux users should opt for version 0.5.3.For any further inquiries or questions regarding this issue, users can visit the IRC channel #bitcoin-dev on Freenode. It is crucial for users to take immediate action and update their Bitcoin-Qt software to protect against potential security risks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_Adding-a-pong-message.xml b/static/bitcoin-dev/March_2012/combined_Adding-a-pong-message.xml index ac42c19a8f..e798099047 100644 --- a/static/bitcoin-dev/March_2012/combined_Adding-a-pong-message.xml +++ b/static/bitcoin-dev/March_2012/combined_Adding-a-pong-message.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Adding a pong message - 2023-08-01T03:23:12.765679+00:00 + 2025-10-11T22:17:45.192636+00:00 + python-feedgen Mike Hearn 2012-03-13 22:29:27+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Adding a pong message - 2023-08-01T03:23:12.765679+00:00 + 2025-10-11T22:17:45.192781+00:00 - TCP keep-alives are not always implemented reliably, causing difficulties in maintaining network connections on mobile devices in areas with poor connectivity. To address this issue, a new "pong" message has been added to the Bitcoin protocol on Github. This message echoes back a 64-bit nonce from the initial ping, allowing clients to quickly determine if a connection is stale or if a remote node is overloaded. This feature would be particularly beneficial for mobile clients. It was noted that TCP keepalives do not provide information about whether a node is overloaded, hence the need for the "pong" message. On March 13, 2012, Mike Hearn proposed the addition of the "pong" message feature on Github's bitcoin repository. The aim of this feature is to enable clients, especially mobile ones, to easily check if a connection is stale and avoid interacting with an overloaded remote node. By echoing back the nonce from the ping, users can determine whether a node is busy performing resource-intensive tasks such as downloading the blockchain. The implementation of this feature is intended to improve the overall connectivity of clients on the network.A recent pull request on Github for Bitcoin introduces the "pong" message, which echoes back a 64-bit nonce from the initial ping. This change aims to enhance the connectivity of clients, especially mobile clients, by enabling them to quickly determine if a connection is stale or if a remote node is overloaded. This helps users avoid interacting with nodes that are engaged in intensive tasks like blockchain downloads. The purpose of this update is to facilitate smoother client operations on the network. No specific concerns or objections have been raised regarding this modification. 2012-03-13T22:29:27+00:00 + TCP keep-alives are not always implemented reliably, causing difficulties in maintaining network connections on mobile devices in areas with poor connectivity. To address this issue, a new "pong" message has been added to the Bitcoin protocol on Github. This message echoes back a 64-bit nonce from the initial ping, allowing clients to quickly determine if a connection is stale or if a remote node is overloaded. This feature would be particularly beneficial for mobile clients. It was noted that TCP keepalives do not provide information about whether a node is overloaded, hence the need for the "pong" message. On March 13, 2012, Mike Hearn proposed the addition of the "pong" message feature on Github's bitcoin repository. The aim of this feature is to enable clients, especially mobile ones, to easily check if a connection is stale and avoid interacting with an overloaded remote node. By echoing back the nonce from the ping, users can determine whether a node is busy performing resource-intensive tasks such as downloading the blockchain. The implementation of this feature is intended to improve the overall connectivity of clients on the network.A recent pull request on Github for Bitcoin introduces the "pong" message, which echoes back a 64-bit nonce from the initial ping. This change aims to enhance the connectivity of clients, especially mobile clients, by enabling them to quickly determine if a connection is stale or if a remote node is overloaded. This helps users avoid interacting with nodes that are engaged in intensive tasks like blockchain downloads. The purpose of this update is to facilitate smoother client operations on the network. No specific concerns or objections have been raised regarding this modification. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_Adding-callback-hooks-to-the-satoshi-client.xml b/static/bitcoin-dev/March_2012/combined_Adding-callback-hooks-to-the-satoshi-client.xml index 0ffe33d137..efa368e99f 100644 --- a/static/bitcoin-dev/March_2012/combined_Adding-callback-hooks-to-the-satoshi-client.xml +++ b/static/bitcoin-dev/March_2012/combined_Adding-callback-hooks-to-the-satoshi-client.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Adding callback hooks to the satoshi client - 2023-08-01T03:24:30.186076+00:00 + 2025-10-11T22:17:21.821801+00:00 + python-feedgen Eric Lombrozo 2012-03-24 08:41:25+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Adding callback hooks to the satoshi client - 2023-08-01T03:24:30.186076+00:00 + 2025-10-11T22:17:21.821920+00:00 - Eric Lombrozo, a Bitcoin developer, is interested in obtaining detailed information about message format errors that occur when nodes connect to bitcoind for debugging purposes. He wants to know if a transaction gets rejected due to various reasons such as an invalid signature, being out of range, or if the output couldn't be connected. Additionally, he wants to know if a transaction is claiming an output that has already been claimed by another transaction.To address this issue, Lombrozo has inserted tracers and stubs into bitcoind. However, he would prefer to write an error log and inform the connecting node about what went wrong using callbacks, which could be configured in a similar way to the RPC in the bitcoin.conf file. Lombrozo suggests having a separate channel for this type of data rather than including it in the Bitcoin protocol itself to avoid potential attacks.The author suggests implementing a callback architecture in applications to handle events related to Bitcoin transactions without requiring access to the wallet space. This can be done by using HTTP POST requests to subscribe to specific events such as new transactions or blocks being seen, which is supported by libcoin. Other types of events, including node connections and disconnections, potential attacks, and alerts related to the status of bitcoind, could also be useful.The proposed system would allow for all I/O to be done via IPC or over network sockets, ensuring that other code never needs to enter into the wallet-handling process/memory space. This approach makes it easier to handle events without requiring direct access to the underlying Bitcoin process.In a discussion on March 22, 2012, Eric Lombrozo proposed adding callback hooks to the main branch of code in the Satoshi client to improve apps that require real-time event notifications. He offered to assist in reorganizing the code and contributing source code to implement this proposal. However, there were concerns about allowing other code into the main wallet-handling process/memory space. Instead, it was suggested to design a Wallet Protocol for general use between the wallet and GUIs/applications.In a forum post from 2012, Lombrozo expressed his need for real-time event notifications and proposed adding callback hooks to the main Bitcoin branch. He explained that his previous approaches of writing his own library or making custom builds of the Satoshi client were not ideal due to code duplication and the risk of breaking patches. Lombrozo offered to help locate key points in the source code, reorganize it, define a callback mechanism, and contribute source code.Another forum member, Matt, replied to Lombrozo's proposal, stating that he had worked on changing the internal Bitcoin code to use callback hooks but it was still incomplete and usable only within the Satoshi client itself. Matt also mentioned that the stability of the blockstore API might be uncertain in the future and provided a link to his work on Github.Overall, these discussions highlight the challenges faced by developers who require real-time event notifications and their efforts to find effective solutions within the Bitcoin ecosystem. Lombrozo's proposal of adding callback hooks to the main branch and designing a Wallet Protocol shows potential for improving the handling of events related to Bitcoin transactions. 2012-03-24T08:41:25+00:00 + Eric Lombrozo, a Bitcoin developer, is interested in obtaining detailed information about message format errors that occur when nodes connect to bitcoind for debugging purposes. He wants to know if a transaction gets rejected due to various reasons such as an invalid signature, being out of range, or if the output couldn't be connected. Additionally, he wants to know if a transaction is claiming an output that has already been claimed by another transaction.To address this issue, Lombrozo has inserted tracers and stubs into bitcoind. However, he would prefer to write an error log and inform the connecting node about what went wrong using callbacks, which could be configured in a similar way to the RPC in the bitcoin.conf file. Lombrozo suggests having a separate channel for this type of data rather than including it in the Bitcoin protocol itself to avoid potential attacks.The author suggests implementing a callback architecture in applications to handle events related to Bitcoin transactions without requiring access to the wallet space. This can be done by using HTTP POST requests to subscribe to specific events such as new transactions or blocks being seen, which is supported by libcoin. Other types of events, including node connections and disconnections, potential attacks, and alerts related to the status of bitcoind, could also be useful.The proposed system would allow for all I/O to be done via IPC or over network sockets, ensuring that other code never needs to enter into the wallet-handling process/memory space. This approach makes it easier to handle events without requiring direct access to the underlying Bitcoin process.In a discussion on March 22, 2012, Eric Lombrozo proposed adding callback hooks to the main branch of code in the Satoshi client to improve apps that require real-time event notifications. He offered to assist in reorganizing the code and contributing source code to implement this proposal. However, there were concerns about allowing other code into the main wallet-handling process/memory space. Instead, it was suggested to design a Wallet Protocol for general use between the wallet and GUIs/applications.In a forum post from 2012, Lombrozo expressed his need for real-time event notifications and proposed adding callback hooks to the main Bitcoin branch. He explained that his previous approaches of writing his own library or making custom builds of the Satoshi client were not ideal due to code duplication and the risk of breaking patches. Lombrozo offered to help locate key points in the source code, reorganize it, define a callback mechanism, and contribute source code.Another forum member, Matt, replied to Lombrozo's proposal, stating that he had worked on changing the internal Bitcoin code to use callback hooks but it was still incomplete and usable only within the Satoshi client itself. Matt also mentioned that the stability of the blockstore API might be uncertain in the future and provided a link to his work on Github.Overall, these discussions highlight the challenges faced by developers who require real-time event notifications and their efforts to find effective solutions within the Bitcoin ecosystem. Lombrozo's proposal of adding callback hooks to the main branch and designing a Wallet Protocol shows potential for improving the handling of events related to Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_Announcement-libcoin.xml b/static/bitcoin-dev/March_2012/combined_Announcement-libcoin.xml index 8ec33e056b..b806961027 100644 --- a/static/bitcoin-dev/March_2012/combined_Announcement-libcoin.xml +++ b/static/bitcoin-dev/March_2012/combined_Announcement-libcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.669593+00:00 + 2025-10-11T22:17:47.315669+00:00 + python-feedgen Martinx - ジェームズ 2012-09-12 23:27:32+00:00 @@ -207,13 +208,13 @@ - python-feedgen + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.670592+00:00 + 2025-10-11T22:17:47.315885+00:00 - In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, 2012-09-12T23:27:32+00:00 + In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_April-1-BIP16-switchover-time-is-definite.xml b/static/bitcoin-dev/March_2012/combined_April-1-BIP16-switchover-time-is-definite.xml index 3752674b83..76682c2f2b 100644 --- a/static/bitcoin-dev/March_2012/combined_April-1-BIP16-switchover-time-is-definite.xml +++ b/static/bitcoin-dev/March_2012/combined_April-1-BIP16-switchover-time-is-definite.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - April 1 BIP16 switchover time is definite - 2023-08-01T03:23:37.282099+00:00 + 2025-10-11T22:17:40.944363+00:00 + python-feedgen Gavin Andresen 2012-03-16 17:45:27+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - April 1 BIP16 switchover time is definite - 2023-08-01T03:23:37.283100+00:00 + 2025-10-11T22:17:40.944514+00:00 - Gavin Andresen recently shared a link to a graph that shows support over the last 100 blocks. However, he later corrected the URL and provided the correct link to the pretty graph, which can be found at http://blockchain.info/P2SH. It is unclear what exactly the support referred to in the graph measures, but it is most likely related to the Bitcoin blockchain.The corrected link leads to a website that provides information on Bitcoins and allows users to explore the network's activity. This communication seems to be directed towards those who are interested in tracking the activity of the Bitcoin network, particularly as it relates to support for certain features or protocols.In other news, the BIP16 switchover time of April 1 has been announced as final. Approximately 70% of hashing power has been supporting it for the last two days, with 54% support over the last week. Pools and miners who have not yet upgraded their software are encouraged to do so within the next two weeks to avoid hashing on a minority chain. Support will continue to be monitored to ensure no slipping before April 1.Furthermore, Gavin Andresen is currently drafting a document that suggests how to make the next upgrade process less painful. He also shared data showing support over the last 30 days using the search_coinbases.py command and bitcointools.For those interested, a graph of support over the last 100 blocks can be found at github.com/bitcoin/bitcoin/. The graph provides further insights into the support for Bitcoin features or protocols. 2012-03-16T17:45:27+00:00 + Gavin Andresen recently shared a link to a graph that shows support over the last 100 blocks. However, he later corrected the URL and provided the correct link to the pretty graph, which can be found at http://blockchain.info/P2SH. It is unclear what exactly the support referred to in the graph measures, but it is most likely related to the Bitcoin blockchain.The corrected link leads to a website that provides information on Bitcoins and allows users to explore the network's activity. This communication seems to be directed towards those who are interested in tracking the activity of the Bitcoin network, particularly as it relates to support for certain features or protocols.In other news, the BIP16 switchover time of April 1 has been announced as final. Approximately 70% of hashing power has been supporting it for the last two days, with 54% support over the last week. Pools and miners who have not yet upgraded their software are encouraged to do so within the next two weeks to avoid hashing on a minority chain. Support will continue to be monitored to ensure no slipping before April 1.Furthermore, Gavin Andresen is currently drafting a document that suggests how to make the next upgrade process less painful. He also shared data showing support over the last 30 days using the search_coinbases.py command and bitcointools.For those interested, a graph of support over the last 100 blocks can be found at github.com/bitcoin/bitcoin/. The graph provides further insights into the support for Bitcoin features or protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_BIP-16-changes-list-inside-.xml b/static/bitcoin-dev/March_2012/combined_BIP-16-changes-list-inside-.xml index 37baa60188..5e9fb16cee 100644 --- a/static/bitcoin-dev/March_2012/combined_BIP-16-changes-list-inside-.xml +++ b/static/bitcoin-dev/March_2012/combined_BIP-16-changes-list-inside-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 16 changes (list inside) - 2023-08-01T03:23:55.786057+00:00 + 2025-10-11T22:17:28.197096+00:00 + python-feedgen Luke-Jr 2012-03-18 18:11:48+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP 16 changes (list inside) - 2023-08-01T03:23:55.786057+00:00 + 2025-10-11T22:17:28.197250+00:00 - On March 18, 2012, Amir Taaki reached out to inquire about the accuracy of a summary regarding changes needed for P2SH and BIP 16. He suggested using his 0.4.x backport from GitHub but cautioned that it still needed auditing since no one else had reviewed it yet. Although the backport could cover the minimal changes required for P2SH validation, it would not address the standard rule changes necessary for accepting them into blocks.The discussion highlights the changes needed for P2SH (Pay to Script Hash) and BIP 16 (Bitcoin Improvement Proposal). These changes are divided into two categories: block validation and script.In terms of block validation, the CheckBlock function uses LegacySigOpCount instead of SigOpCount. The ConnectBlock function undergoes some modifications, including a new SigOp calculation. However, FetchInputs() and ConnectInputs() remain unchanged. There are also some efficient improvements made to SetBestChain(), although they are unrelated to BIP 16.Regarding the script changes, the Solver function has a special case to check for TX_SCRIPTHASH, which returns the hash of the input eval script. Another solver returns the signature of the pubkey script or TX_SCRIPTHASH, finding the redeem script in KeyStore and returning it. ExtractAddress(es) and VerifyScript are also included.If the fValidatePayToScriptHash block date and output script (scriptPubKey) are P2SH, then the scriptSig must consist only of push operations. The last item of the copied stack is evaluated as a script using the copied stack as the stack.A SigOpCount is used within the CBlock::ConnectBlock main loop to perform scoring checksigs and multisigs. Additionally, a newly added DecodeOP_N is used alongside the normal SigOpCount.Lastly, in the Address component, the main hash160 data is set with a beginning byte (nVersion) of 0x05.Overall, the discussion provides detailed insights into the changes required for P2SH and BIP 16, covering both block validation and script modifications. It also addresses the caution regarding the need for auditing the suggested backport and mentions some efficient improvements made to SetBestChain() that are unrelated to BIP 16. 2012-03-18T18:11:48+00:00 + On March 18, 2012, Amir Taaki reached out to inquire about the accuracy of a summary regarding changes needed for P2SH and BIP 16. He suggested using his 0.4.x backport from GitHub but cautioned that it still needed auditing since no one else had reviewed it yet. Although the backport could cover the minimal changes required for P2SH validation, it would not address the standard rule changes necessary for accepting them into blocks.The discussion highlights the changes needed for P2SH (Pay to Script Hash) and BIP 16 (Bitcoin Improvement Proposal). These changes are divided into two categories: block validation and script.In terms of block validation, the CheckBlock function uses LegacySigOpCount instead of SigOpCount. The ConnectBlock function undergoes some modifications, including a new SigOp calculation. However, FetchInputs() and ConnectInputs() remain unchanged. There are also some efficient improvements made to SetBestChain(), although they are unrelated to BIP 16.Regarding the script changes, the Solver function has a special case to check for TX_SCRIPTHASH, which returns the hash of the input eval script. Another solver returns the signature of the pubkey script or TX_SCRIPTHASH, finding the redeem script in KeyStore and returning it. ExtractAddress(es) and VerifyScript are also included.If the fValidatePayToScriptHash block date and output script (scriptPubKey) are P2SH, then the scriptSig must consist only of push operations. The last item of the copied stack is evaluated as a script using the copied stack as the stack.A SigOpCount is used within the CBlock::ConnectBlock main loop to perform scoring checksigs and multisigs. Additionally, a newly added DecodeOP_N is used alongside the normal SigOpCount.Lastly, in the Address component, the main hash160 data is set with a beginning byte (nVersion) of 0x05.Overall, the discussion provides detailed insights into the changes required for P2SH and BIP 16, covering both block validation and script modifications. It also addresses the caution regarding the need for auditing the suggested backport and mentions some efficient improvements made to SetBestChain() that are unrelated to BIP 16. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_BIP-18-or-not-.xml b/static/bitcoin-dev/March_2012/combined_BIP-18-or-not-.xml index cab9b5a491..0554ed0aa7 100644 --- a/static/bitcoin-dev/March_2012/combined_BIP-18-or-not-.xml +++ b/static/bitcoin-dev/March_2012/combined_BIP-18-or-not-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 18 (or not?) - 2023-08-01T03:23:24.641485+00:00 + 2025-10-11T22:17:30.326042+00:00 + python-feedgen Stefan Thomas 2012-03-14 15:20:43+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - BIP 18 (or not?) - 2023-08-01T03:23:24.641485+00:00 + 2025-10-11T22:17:30.326214+00:00 - On March 14, 2012, Amir Taaki sent an email to the Bitcoin-development mailing list addressing Bitcoin Improvement Proposals (BIPs). It was noted that luke-jr withdrew BIP 16 and advocated for BIP 17, which gained consensus to move forward. However, luke-jr then submitted BIP 18, which raised concerns about its technical viability and questioned its purpose given the adoption of BIP 17.Amir Taaki explained the general process of evaluating and accepting BIPs within the community. He emphasized that a draft BIP should be presented to bitcoin-development at lists.sourceforge.net, where it undergoes discussion and evaluation based on specific minimum criteria. However, he pointed out that some BIPs, including BIP 18, had not followed this process before being accepted.The discussion primarily revolved around whether BIP 18 should be accepted into the repository, highlighting the importance of adhering to the proper protocol for evaluating and accepting BIPs. Amir Taaki outlined the criteria for accepting a BIP, including having a clear and comprehensive description of the proposed enhancement, demonstrating a net improvement, and presenting a well-structured implementation that does not overly complicate the protocol.In conclusion, the email exchange focused on the technical soundness and purposefulness of BIP 18, along with the significance of following the established procedure for evaluating and accepting BIPs within the Bitcoin community. 2012-03-14T15:20:43+00:00 + On March 14, 2012, Amir Taaki sent an email to the Bitcoin-development mailing list addressing Bitcoin Improvement Proposals (BIPs). It was noted that luke-jr withdrew BIP 16 and advocated for BIP 17, which gained consensus to move forward. However, luke-jr then submitted BIP 18, which raised concerns about its technical viability and questioned its purpose given the adoption of BIP 17.Amir Taaki explained the general process of evaluating and accepting BIPs within the community. He emphasized that a draft BIP should be presented to bitcoin-development at lists.sourceforge.net, where it undergoes discussion and evaluation based on specific minimum criteria. However, he pointed out that some BIPs, including BIP 18, had not followed this process before being accepted.The discussion primarily revolved around whether BIP 18 should be accepted into the repository, highlighting the importance of adhering to the proper protocol for evaluating and accepting BIPs. Amir Taaki outlined the criteria for accepting a BIP, including having a clear and comprehensive description of the proposed enhancement, demonstrating a net improvement, and presenting a well-structured implementation that does not overly complicate the protocol.In conclusion, the email exchange focused on the technical soundness and purposefulness of BIP 18, along with the significance of following the established procedure for evaluating and accepting BIPs within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_Duplicate-transactions-vulnerability.xml b/static/bitcoin-dev/March_2012/combined_Duplicate-transactions-vulnerability.xml index d8a6832af6..46bf78557b 100644 --- a/static/bitcoin-dev/March_2012/combined_Duplicate-transactions-vulnerability.xml +++ b/static/bitcoin-dev/March_2012/combined_Duplicate-transactions-vulnerability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Duplicate transactions vulnerability - 2023-08-01T03:20:01.503737+00:00 + 2025-10-11T22:17:34.574141+00:00 + python-feedgen Pieter Wuille 2012-03-03 16:41:03+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Duplicate transactions vulnerability - 2023-08-01T03:20:01.503737+00:00 + 2025-10-11T22:17:34.574311+00:00 - In February 2012, a vulnerability in the Bitcoin reference client was discovered. This vulnerability allowed for duplicate transactions, although exploiting it required significant hash power and had no financial benefit for attackers. Despite this, it was still seen as a security issue that needed to be addressed promptly.To fix the vulnerability, Pieter Wuille proposed adding an additional protocol rule that would prevent blocks from containing a transaction with the same hash as a previous transaction that had not been fully spent. This proposal was detailed in BIP30, and a patch for the reference client was created and tested to ensure the attack would be impossible. Importantly, the change was designed to be backward compatible with older versions of the software.Wuille reached out to the Bitcoin community for support in adding this rule to the protocol rules. The goal was to encourage pools and miners to update their nodes without needing a lengthy coinbase-flagging procedure that could delay the implementation of the solution. Gavin Andresen expressed strong support for this proposal.However, some community members, like Robert, raised concerns and suggested modifying the rule further. They believed that there should be no duplicate transaction hashes at all and proposed preventing the inclusion of transaction hashes that already existed in the branch. Additionally, they suggested "tweaking" transactions with the same hash to avoid collision.Despite these concerns, the Bitcoin community was actively working together to find a solution to the security vulnerability and ensure the safety of the network. The proposed protocol rule aimed to prevent duplicate transactions and make the attack impossible. With consensus and support from pools and miners, the implementation of this rule could be achieved without significant delays. 2012-03-03T16:41:03+00:00 + In February 2012, a vulnerability in the Bitcoin reference client was discovered. This vulnerability allowed for duplicate transactions, although exploiting it required significant hash power and had no financial benefit for attackers. Despite this, it was still seen as a security issue that needed to be addressed promptly.To fix the vulnerability, Pieter Wuille proposed adding an additional protocol rule that would prevent blocks from containing a transaction with the same hash as a previous transaction that had not been fully spent. This proposal was detailed in BIP30, and a patch for the reference client was created and tested to ensure the attack would be impossible. Importantly, the change was designed to be backward compatible with older versions of the software.Wuille reached out to the Bitcoin community for support in adding this rule to the protocol rules. The goal was to encourage pools and miners to update their nodes without needing a lengthy coinbase-flagging procedure that could delay the implementation of the solution. Gavin Andresen expressed strong support for this proposal.However, some community members, like Robert, raised concerns and suggested modifying the rule further. They believed that there should be no duplicate transaction hashes at all and proposed preventing the inclusion of transaction hashes that already existed in the branch. Additionally, they suggested "tweaking" transactions with the same hash to avoid collision.Despite these concerns, the Bitcoin community was actively working together to find a solution to the security vulnerability and ensure the safety of the network. The proposed protocol rule aimed to prevent duplicate transactions and make the attack impossible. With consensus and support from pools and miners, the implementation of this rule could be achieved without significant delays. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_Fwd-Proposal-for-a-new-opcode.xml b/static/bitcoin-dev/March_2012/combined_Fwd-Proposal-for-a-new-opcode.xml index 3595069495..0a294affde 100644 --- a/static/bitcoin-dev/March_2012/combined_Fwd-Proposal-for-a-new-opcode.xml +++ b/static/bitcoin-dev/March_2012/combined_Fwd-Proposal-for-a-new-opcode.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Proposal for a new opcode - 2023-08-01T03:22:26.391723+00:00 + 2025-10-11T22:17:26.070284+00:00 + python-feedgen Gregory Maxwell 2012-03-21 19:54:30+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Fwd: Proposal for a new opcode - 2023-08-01T03:22:26.391723+00:00 + 2025-10-11T22:17:26.070510+00:00 - In an email sent on March 2, 2012, Watson Ladd proposed a new opcode for anonymous transactions. The purpose of this opcode is to allow scripts to be given proof that the receiver can carry out or has carried out a previous transaction. Ladd was working on a paper that discussed using this opcode for anonymous transactions. The idea behind the opcode is to prevent double spend attacks against anonymization schemes by validating an opaque signature.However, there seems to be some confusion about how this opcode enables anonymous transactions. Gregory Maxwell questioned its effectiveness and compared it to a hash locked transaction from the perspective of the blockchain. Ladd explained that the inability to blind a Lamport signature makes it different from a hash locked transaction. Although the draft proposal is not ready for anything official yet, Ladd is actively searching for a place to post it as it seems to be of interest.Gavin Andresen expressed excitement about the proposal and requested to read the paper for further details. He also mentioned that additional work may be required beyond introducing a new opcode in order to provide strong anonymity, such as creating new transaction types that clients can understand.Overall, Ladd's proposal aims to enhance anonymity in transactions through the use of a new opcode. Despite some confusion about its implementation, the idea behind the opcode shows promise for improving the security and privacy of transactions. Ladd is currently working on a paper discussing the use of this opcode for anonymous transactions, and it is generating interest within the Bitcoin community. 2012-03-21T19:54:30+00:00 + In an email sent on March 2, 2012, Watson Ladd proposed a new opcode for anonymous transactions. The purpose of this opcode is to allow scripts to be given proof that the receiver can carry out or has carried out a previous transaction. Ladd was working on a paper that discussed using this opcode for anonymous transactions. The idea behind the opcode is to prevent double spend attacks against anonymization schemes by validating an opaque signature.However, there seems to be some confusion about how this opcode enables anonymous transactions. Gregory Maxwell questioned its effectiveness and compared it to a hash locked transaction from the perspective of the blockchain. Ladd explained that the inability to blind a Lamport signature makes it different from a hash locked transaction. Although the draft proposal is not ready for anything official yet, Ladd is actively searching for a place to post it as it seems to be of interest.Gavin Andresen expressed excitement about the proposal and requested to read the paper for further details. He also mentioned that additional work may be required beyond introducing a new opcode in order to provide strong anonymity, such as creating new transaction types that clients can understand.Overall, Ladd's proposal aims to enhance anonymity in transactions through the use of a new opcode. Despite some confusion about its implementation, the idea behind the opcode shows promise for improving the security and privacy of transactions. Ladd is currently working on a paper discussing the use of this opcode for anonymous transactions, and it is generating interest within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_JSON-RPC-is-BIP-territory-or-not-.xml b/static/bitcoin-dev/March_2012/combined_JSON-RPC-is-BIP-territory-or-not-.xml index 9dc61922e6..dca159bb94 100644 --- a/static/bitcoin-dev/March_2012/combined_JSON-RPC-is-BIP-territory-or-not-.xml +++ b/static/bitcoin-dev/March_2012/combined_JSON-RPC-is-BIP-territory-or-not-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - JSON-RPC is BIP territory or not? - 2023-08-01T03:22:14.043351+00:00 + 2025-10-11T22:17:32.448706+00:00 + python-feedgen Luke-Jr 2012-03-03 13:49:03+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - JSON-RPC is BIP territory or not? - 2023-08-01T03:22:14.043351+00:00 + 2025-10-11T22:17:32.448828+00:00 - In a Bitcoin development thread on February 28, 2012, the discussion focused on a proposed BIP (Bitcoin Improvement Proposal) for getmemorypool. Stefan Thomas chose to wait until the BIP was officially proposed before sharing his thoughts. The topic at hand was whether JSON-RPC API calls should be included as part of BIPs, as several independent clients aimed to implement these APIs.The aim of the proposed BIP was to create a common protocol between different clients, miners, mining proxies, and pools. Standardization was seen as a positive step since it would impact a lot of software. However, the content of the BIP had not been discussed yet, as the thread was more of a meta-discussion.One participant in the discussion argued that the BIP process applies across bitcoin implementations and primarily focuses on generic use-cases and the protocol that affect all clients. They believed that implementation-specific non-bitcoin-protocol proposals, like the one being discussed, were outside the scope of the BIP process. They provided an example of a hypothetical situation where multiple backends used Bitcoin-Qt and stated that a proposal to mandate a change in the UI placement or abstraction layer of Bitcoin-Qt would not be appropriate for a BIP. However, they acknowledged that the BIP process was suitable for standardizing behaviors like URIs, which are necessary for network and community interoperability.Amir Taaki made a proposal regarding the adoption of BIPs across bitcoin implementations. This proposal was not implementation-specific but aimed to cover multiple use-cases. Currently, bitcoind supports getmemorypool for a few use-cases, but the proposed BIP would enable it to be utilized for many more. This standardization was desirable, as other pools expressed interest in moving towards a more decentralized method of pooled mining, similar to the p2pool protocol.Overall, the message shared in the context discussed the BIP proposal for the getmemorypool JSON-RPC method. The sender clarified that BIPs are implementation-specific non-bitcoin-protocol proposals that focus on generic use-cases and the protocol, affecting all clients. They also mentioned that proposals related to specific implementations, like changes in Bitcoin-Qt's abstraction layer or UI placement, would not be appropriate for BIPs. However, they acknowledged the importance of the BIP process for standardizing behaviors related to network and community interoperability. 2012-03-03T13:49:03+00:00 + In a Bitcoin development thread on February 28, 2012, the discussion focused on a proposed BIP (Bitcoin Improvement Proposal) for getmemorypool. Stefan Thomas chose to wait until the BIP was officially proposed before sharing his thoughts. The topic at hand was whether JSON-RPC API calls should be included as part of BIPs, as several independent clients aimed to implement these APIs.The aim of the proposed BIP was to create a common protocol between different clients, miners, mining proxies, and pools. Standardization was seen as a positive step since it would impact a lot of software. However, the content of the BIP had not been discussed yet, as the thread was more of a meta-discussion.One participant in the discussion argued that the BIP process applies across bitcoin implementations and primarily focuses on generic use-cases and the protocol that affect all clients. They believed that implementation-specific non-bitcoin-protocol proposals, like the one being discussed, were outside the scope of the BIP process. They provided an example of a hypothetical situation where multiple backends used Bitcoin-Qt and stated that a proposal to mandate a change in the UI placement or abstraction layer of Bitcoin-Qt would not be appropriate for a BIP. However, they acknowledged that the BIP process was suitable for standardizing behaviors like URIs, which are necessary for network and community interoperability.Amir Taaki made a proposal regarding the adoption of BIPs across bitcoin implementations. This proposal was not implementation-specific but aimed to cover multiple use-cases. Currently, bitcoind supports getmemorypool for a few use-cases, but the proposed BIP would enable it to be utilized for many more. This standardization was desirable, as other pools expressed interest in moving towards a more decentralized method of pooled mining, similar to the p2pool protocol.Overall, the message shared in the context discussed the BIP proposal for the getmemorypool JSON-RPC method. The sender clarified that BIPs are implementation-specific non-bitcoin-protocol proposals that focus on generic use-cases and the protocol, affecting all clients. They also mentioned that proposals related to specific implementations, like changes in Bitcoin-Qt's abstraction layer or UI placement, would not be appropriate for BIPs. However, they acknowledged the importance of the BIP process for standardizing behaviors related to network and community interoperability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_P2SH-status-update.xml b/static/bitcoin-dev/March_2012/combined_P2SH-status-update.xml index c1f83776b1..aad2279180 100644 --- a/static/bitcoin-dev/March_2012/combined_P2SH-status-update.xml +++ b/static/bitcoin-dev/March_2012/combined_P2SH-status-update.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - P2SH status update - 2023-08-01T03:22:59.136023+00:00 + 2025-10-11T22:17:36.697305+00:00 + python-feedgen Luke-Jr 2012-03-06 19:29:14+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - P2SH status update - 2023-08-01T03:22:59.136023+00:00 + 2025-10-11T22:17:36.697517+00:00 - In March 2012, a user named "slush" raised a question about the lack of support from Deepbit, a prominent bitcoin mining pool. Another user responded, stating that there had been no recent discussions with Tycho, the operator of Deepbit, regarding P2SH (Pay-to-Script-Hash). The priority at that time was to deploy BIP30, a proposal related to blockchain consistency.Around the same time, Luke-Jr sent an email to the Bitcoin-development mailing list providing updates on two key proposals: BIP16 and BIP17. BIP16 had received 37% support and only 4% opposition, while BIP17 had garnered 4% support without any opposition. These proposals aimed to introduce new features to enhance the functionality and security of the cryptocurrency.BIP16 suggested the inclusion of a new script opcode that would enable new transaction types. With significant support, this proposal seemed to have gained more traction among cryptocurrency enthusiasts. On the other hand, BIP17 proposed a new address format to prevent accidental spends and improve security. Although it had received less support, it addressed a pressing issue with the current address format, which is prone to errors.While both proposals had their own merits, the success of BIP16 indicated its potential to bring about positive changes in the crypto world. However, the implementation and impact of these proposals remained to be seen. Alongside these updates, the email also contained an advertisement for LearnDevNow, an online learning library for Microsoft developers.Overall, the discussion highlighted the ongoing efforts within the cryptocurrency community to enhance the functionality and security of the digital currency system. The support for BIP16 and BIP17 reflected the collective interest in improving the crypto world and addressing its challenges. 2012-03-06T19:29:14+00:00 + In March 2012, a user named "slush" raised a question about the lack of support from Deepbit, a prominent bitcoin mining pool. Another user responded, stating that there had been no recent discussions with Tycho, the operator of Deepbit, regarding P2SH (Pay-to-Script-Hash). The priority at that time was to deploy BIP30, a proposal related to blockchain consistency.Around the same time, Luke-Jr sent an email to the Bitcoin-development mailing list providing updates on two key proposals: BIP16 and BIP17. BIP16 had received 37% support and only 4% opposition, while BIP17 had garnered 4% support without any opposition. These proposals aimed to introduce new features to enhance the functionality and security of the cryptocurrency.BIP16 suggested the inclusion of a new script opcode that would enable new transaction types. With significant support, this proposal seemed to have gained more traction among cryptocurrency enthusiasts. On the other hand, BIP17 proposed a new address format to prevent accidental spends and improve security. Although it had received less support, it addressed a pressing issue with the current address format, which is prone to errors.While both proposals had their own merits, the success of BIP16 indicated its potential to bring about positive changes in the crypto world. However, the implementation and impact of these proposals remained to be seen. Alongside these updates, the email also contained an advertisement for LearnDevNow, an online learning library for Microsoft developers.Overall, the discussion highlighted the ongoing efforts within the cryptocurrency community to enhance the functionality and security of the digital currency system. The support for BIP16 and BIP17 reflected the collective interest in improving the crypto world and addressing its challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_Proposal-for-a-new-opcode.xml b/static/bitcoin-dev/March_2012/combined_Proposal-for-a-new-opcode.xml index 5acb64567e..31fd9261e9 100644 --- a/static/bitcoin-dev/March_2012/combined_Proposal-for-a-new-opcode.xml +++ b/static/bitcoin-dev/March_2012/combined_Proposal-for-a-new-opcode.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal for a new opcode - 2023-08-01T03:22:44.745430+00:00 + 2025-10-11T22:17:23.946244+00:00 + python-feedgen Gregory Maxwell 2012-03-22 00:49:20+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Proposal for a new opcode - 2023-08-01T03:22:44.745430+00:00 + 2025-10-11T22:17:23.946443+00:00 - Watson Ladd and Gregory Maxwell have been engaged in an email conversation discussing various proposals for enhancing anonymity in Bitcoin transactions. Ladd emphasizes the importance of a verifiable mix to prevent misconduct by mixers, suggesting that if the final step fails, mixes can be challenged to disclose half of their correspondences in order to identify any defectors. He also considers the possibility of publishing everything if the final stage fails, as this would instantly and provably identify cheaters, although precautions must be taken to avoid fake-failures.Ladd further suggests that private keys and signatures serve as better proofs of knowledge than hashes in P2SH conversations. P2SH, being a superset of other schemes, allows for a signature to prove access to a private key and control of a P2SH address. Ladd believes that interactive proofs for knowing the preimages of hashes can be constructed in Bitcoin.Maxwell proposes a new protocol for purchasing equal amounts of Bitcoin while maintaining privacy. The protocol involves N parties who contribute the relevant amount of gold or any other asset at the exchange. Each participant generates a new bitcoin address, encrypting it with the exchange's public key and the public keys of all the mixers. These encrypted addresses are combined into a block and passed to the mixing chain, where each mixer randomizes the order and decrypts the messages with its key. At the end of the chain, the exchange performs the final decryption and presents a list of addresses to the users involved. Users validate that their address is in the set and sign the entire set before the exchange makes the payment. This protocol ensures strong anonymity as long as one of the mixers remains uncompromised and has minimal overhead.In addition to these discussions, Ladd proposes a new opcode called OP_CHECKEXPSIG for anonymous transactions. This opcode enables scripts to provide proof that the receiver can carry out or has carried out a previous transaction. It combines the strong double spend protection of Bitcoin with the strong anonymity of traditional digital cash techniques. However, Michael Gronager raises concerns about how OP_CHECKEXPSIG maintains protection against double spending, as the revelation of former transactions only occurs upon redeeming the OP_CHECKEXPSIG transaction. He seeks clarification on any points he may have missed.It is worth noting that Michael Gronager is the director of Ceptacle, a company based in Copenhagen, Denmark. 2012-03-22T00:49:20+00:00 + Watson Ladd and Gregory Maxwell have been engaged in an email conversation discussing various proposals for enhancing anonymity in Bitcoin transactions. Ladd emphasizes the importance of a verifiable mix to prevent misconduct by mixers, suggesting that if the final step fails, mixes can be challenged to disclose half of their correspondences in order to identify any defectors. He also considers the possibility of publishing everything if the final stage fails, as this would instantly and provably identify cheaters, although precautions must be taken to avoid fake-failures.Ladd further suggests that private keys and signatures serve as better proofs of knowledge than hashes in P2SH conversations. P2SH, being a superset of other schemes, allows for a signature to prove access to a private key and control of a P2SH address. Ladd believes that interactive proofs for knowing the preimages of hashes can be constructed in Bitcoin.Maxwell proposes a new protocol for purchasing equal amounts of Bitcoin while maintaining privacy. The protocol involves N parties who contribute the relevant amount of gold or any other asset at the exchange. Each participant generates a new bitcoin address, encrypting it with the exchange's public key and the public keys of all the mixers. These encrypted addresses are combined into a block and passed to the mixing chain, where each mixer randomizes the order and decrypts the messages with its key. At the end of the chain, the exchange performs the final decryption and presents a list of addresses to the users involved. Users validate that their address is in the set and sign the entire set before the exchange makes the payment. This protocol ensures strong anonymity as long as one of the mixers remains uncompromised and has minimal overhead.In addition to these discussions, Ladd proposes a new opcode called OP_CHECKEXPSIG for anonymous transactions. This opcode enables scripts to provide proof that the receiver can carry out or has carried out a previous transaction. It combines the strong double spend protection of Bitcoin with the strong anonymity of traditional digital cash techniques. However, Michael Gronager raises concerns about how OP_CHECKEXPSIG maintains protection against double spending, as the revelation of former transactions only occurs upon redeeming the OP_CHECKEXPSIG transaction. He seeks clarification on any points he may have missed.It is worth noting that Michael Gronager is the director of Ceptacle, a company based in Copenhagen, Denmark. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2012/combined_getmemorypool-BIP-process.xml b/static/bitcoin-dev/March_2012/combined_getmemorypool-BIP-process.xml index c3e14419ab..011b1bd314 100644 --- a/static/bitcoin-dev/March_2012/combined_getmemorypool-BIP-process.xml +++ b/static/bitcoin-dev/March_2012/combined_getmemorypool-BIP-process.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - getmemorypool BIP process - 2023-08-01T03:21:29.402892+00:00 + 2025-10-11T22:17:19.698684+00:00 + python-feedgen Geir Harald Hansen 2012-03-04 17:49:00+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - getmemorypool BIP process - 2023-08-01T03:21:29.402892+00:00 + 2025-10-11T22:17:19.698818+00:00 - Geir Harald Hansen proposed a solution to the race condition in long polling implemented in pools. He suggested adding "longpollid" in long poll responses and for the client to include the last seen longpollid in future requests. This would allow the server to check if the client has missed any block changes. Additionally, Hansen recommended including the "height" value in the getmemorypool response so that miners can include the correct height in the coinbase. However, adding parameters to getmemorypool itself breaks compatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific again. It was suggested that some features should be optional for clients to implement, but this requires a way for clients to communicate their capabilities to the server. Lastly, it was mentioned that "noncerange" is of limited use and could result in getting the endianness wrong.In a discussion between Luke-Jr and Gavin Andresen, the limitations of using JSON-RPC for server to client calls were highlighted. Gavin pointed out that JSON-RPC and HTTP are client-server models that don't allow the server to make calls to the client, making it impractical for clients to run their own JSON-RPC server. However, Luke-Jr updated the draft to include long polling and remove assumptions of using HTTP for transport. The context also provides a link to a page about virtualization and cloud management using capacity planning, which explains how cloud computing uses virtualization to deliver computing as a service. There is also information about the Bitcoin-development mailing list with a link to sign up for it.The context mentions that there is no explicit standard way to do S->C JSON-RPC. The JSON-RPC 1.0 spec doesn't require a specific transport protocol, while the JSON-RPC 2.0 spec is transport agnostic. Plain TCP sockets are commonly used for bidirectional JSON-RPC, but they lack a standardized authentication mechanism. The use of HTTP Keep-Alive with an event system, similar to web chat applications, was suggested as a solution. It was noted that HTTP Keep-Alive works but is not widely supported among client libraries, and HTTP itself isn't designed for this type of usage. Adding challenge-response authentication and TLS support to the JSON-RPC API in the future was also mentioned.A proposal called "getmemorypool" has been submitted as part of the Bitcoin Improvement Proposal (BIP) draft by Luke-Jr. The proposal aims to improve the memory pool process for miners by providing details about unconfirmed transactions. This would help miners select transactions more efficiently for inclusion in the next block. The proposal suggests adding additional values like "longpollid" and "height" to the getmemorypool response. Geir Harald Hansen provided comments on the proposal, suggesting clarifications and making certain features optional for clients to implement. The context also mentions Stefan Thomas initiating a discussion about the use of a polling model in BIP and the interest in a "push" API using JSON-RPC over TCP.Overall, the proposed changes aim to address issues with long polling in pools, improve communication between servers and clients using JSON-RPC, and enhance the memory pool process for miners. These developments have the potential to make the Bitcoin network more efficient and secure. 2012-03-04T17:49:00+00:00 + Geir Harald Hansen proposed a solution to the race condition in long polling implemented in pools. He suggested adding "longpollid" in long poll responses and for the client to include the last seen longpollid in future requests. This would allow the server to check if the client has missed any block changes. Additionally, Hansen recommended including the "height" value in the getmemorypool response so that miners can include the correct height in the coinbase. However, adding parameters to getmemorypool itself breaks compatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific again. It was suggested that some features should be optional for clients to implement, but this requires a way for clients to communicate their capabilities to the server. Lastly, it was mentioned that "noncerange" is of limited use and could result in getting the endianness wrong.In a discussion between Luke-Jr and Gavin Andresen, the limitations of using JSON-RPC for server to client calls were highlighted. Gavin pointed out that JSON-RPC and HTTP are client-server models that don't allow the server to make calls to the client, making it impractical for clients to run their own JSON-RPC server. However, Luke-Jr updated the draft to include long polling and remove assumptions of using HTTP for transport. The context also provides a link to a page about virtualization and cloud management using capacity planning, which explains how cloud computing uses virtualization to deliver computing as a service. There is also information about the Bitcoin-development mailing list with a link to sign up for it.The context mentions that there is no explicit standard way to do S->C JSON-RPC. The JSON-RPC 1.0 spec doesn't require a specific transport protocol, while the JSON-RPC 2.0 spec is transport agnostic. Plain TCP sockets are commonly used for bidirectional JSON-RPC, but they lack a standardized authentication mechanism. The use of HTTP Keep-Alive with an event system, similar to web chat applications, was suggested as a solution. It was noted that HTTP Keep-Alive works but is not widely supported among client libraries, and HTTP itself isn't designed for this type of usage. Adding challenge-response authentication and TLS support to the JSON-RPC API in the future was also mentioned.A proposal called "getmemorypool" has been submitted as part of the Bitcoin Improvement Proposal (BIP) draft by Luke-Jr. The proposal aims to improve the memory pool process for miners by providing details about unconfirmed transactions. This would help miners select transactions more efficiently for inclusion in the next block. The proposal suggests adding additional values like "longpollid" and "height" to the getmemorypool response. Geir Harald Hansen provided comments on the proposal, suggesting clarifications and making certain features optional for clients to implement. The context also mentions Stefan Thomas initiating a discussion about the use of a polling model in BIP and the interest in a "push" API using JSON-RPC over TCP.Overall, the proposed changes aim to address issues with long polling in pools, improve communication between servers and clients using JSON-RPC, and enhance the memory pool process for miners. These developments have the potential to make the Bitcoin network more efficient and secure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_-PATCH-Change-recommended-fee-to-0-001-BTC.xml b/static/bitcoin-dev/March_2013/combined_-PATCH-Change-recommended-fee-to-0-001-BTC.xml index 876a12e0a5..8899155df1 100644 --- a/static/bitcoin-dev/March_2013/combined_-PATCH-Change-recommended-fee-to-0-001-BTC.xml +++ b/static/bitcoin-dev/March_2013/combined_-PATCH-Change-recommended-fee-to-0-001-BTC.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [PATCH] Change recommended fee to 0.001 BTC - 2023-08-01T04:30:33.645120+00:00 + 2025-10-11T21:28:49.379554+00:00 + python-feedgen Luke-Jr 2013-03-11 21:29:29+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - [PATCH] Change recommended fee to 0.001 BTC - 2023-08-01T04:30:33.645120+00:00 + 2025-10-11T21:28:49.379704+00:00 - In an email conversation between Rune Kjær Svendsen and Luke-Jr on March 11, 2013, they discussed the possibility of doing string substitution for both the value and unit in Qt documentation. Luke-Jr suggested using a formatted string and another function to format the string, while Rune Kjær Svendsen planned on using the method described on the "Use QString::arg() for Simple Arguments" page. He wanted to put a %1 and %2 in the translation strings to substitute for value and unit, respectively. He also mentioned wanting to define the constant in main.h alongside MIN_TX_FEE and MIN_RELAY_TX_FEE.They further discussed forking on Github and using string substitution for both the value and the unit. Luke-Jr suggested using a formatted string and another function to format the string, which already exists to decide how to display units elsewhere. Rune Kjær Svendsen planned to use the method described on the Qt documentation page under "Use QString::arg() for Simple Arguments". They also discussed where to define the constant and suggested defining it in main.h alongside MIN_TX_FEE and MIN_RELAY_TX_FEE.In a discussion among developers on March 11, 2013, there was a question about whether a new value should be defined solely for display purposes or if MIN_TX_FEE or MIN_RELAY_TX_FEE should be used in some way. Rune Kjær Svendsen suggested that a new value should be created, but no further information was provided as to why a new value was deemed necessary.A user named Rune K. Svendsen suggested changing the minimum fee recommended in the Main tab of the Options dialog from 0.01 to 0.001 BTC or even lower in a Bitcoin development mailing list. He proposed doing string substitution for both the value and the unit by defining a new value solely for display or using MIN_TX_FEE or MIN_RELAY_TX_FEE in some way. He sought more opinions from other developers before proceeding to write the code. Luke-Jr replied to his suggestion, advising him to use GitHub pull requests or publish a git repository instead of mailing patches. He also suggested two commits for this change and expressed no opinion on whether the recommended fee should be changed or not. Eligius uses a lower minimum fee, but most pools/miners treat anything under 0.01 BTC as if it were no fee at all.Rune K. Svendsen sent an email on March 11, 2013, suggesting changing the minimum fee recommendation for Bitcoin transactions from 0.01 BTC to 0.001 BTC or even lower. The current recommendation amounted to about $0.50 at the time of the email. Svendsen recommended making this change on the Main tab in the Options dialog. Svendsen also suggested that pull requests be used on GitHub instead of mailing patches. He further suggested breaking the changes into two commits. The first commit would involve moving the recommended fee outside the translatable string and formatting it using the user's preferred unit. The second commit would change the recommended fee in one place. Svendsen did not express an opinion on whether the recommended fee should be changed or not. However, he noted that some pools/miners would treat anything under 0.01 BTC as if it were no fee at all, despite Eligius using a lower minimum fee.A request has been made to change the minimum recommended transaction fee on the Main tab in the Options dialog. The current recommendation of 0.01 BTC is approximately $0.50 at today's price, but the request suggests changing it to 0.001 BTC or lower. Changes have been made to the optionsdialog.ui file and the localization files for various languages, including bg.ts, ca_ES.ts, cs.ts, da.ts, de.ts, el_GR.ts, en.ts, es.ts, es_CL.ts, et.ts, eu_ES.ts, fa.ts, fa_IR.ts, fi.ts, fr.ts, fr_CA.ts, gu_IN.ts, he.ts, hi_IN.ts, hr.ts, hu.ts, it.ts, ja.ts, lt.ts, nb.ts, nl.ts, pl.ts, pt_BR.ts, pt_PT.ts, ro_RO.ts, ru.ts, sk.ts, sr.ts, sv.ts, th_TH.ts, tr.ts, uk.ts, zh_CN.ts, and zh_TW.ts.The Bitcoin software provides an optional transaction fee per KB to ensure that transactions are processed quickly. Most transactions are 1 KB in size, and a fee of 0.01 BTC is recommended. However, recent updates suggest a lower fee of 0.001 BTC to be used instead. This information is provided in multiple language translations, including Spanish, Estonian, Basque, Persian, Finnish, French, Hebrew, Hindi, Croatian, and Hungarian. These translations can be found in their respective files within the src/qt/locale/ 2013-03-11T21:29:29+00:00 + In an email conversation between Rune Kjær Svendsen and Luke-Jr on March 11, 2013, they discussed the possibility of doing string substitution for both the value and unit in Qt documentation. Luke-Jr suggested using a formatted string and another function to format the string, while Rune Kjær Svendsen planned on using the method described on the "Use QString::arg() for Simple Arguments" page. He wanted to put a %1 and %2 in the translation strings to substitute for value and unit, respectively. He also mentioned wanting to define the constant in main.h alongside MIN_TX_FEE and MIN_RELAY_TX_FEE.They further discussed forking on Github and using string substitution for both the value and the unit. Luke-Jr suggested using a formatted string and another function to format the string, which already exists to decide how to display units elsewhere. Rune Kjær Svendsen planned to use the method described on the Qt documentation page under "Use QString::arg() for Simple Arguments". They also discussed where to define the constant and suggested defining it in main.h alongside MIN_TX_FEE and MIN_RELAY_TX_FEE.In a discussion among developers on March 11, 2013, there was a question about whether a new value should be defined solely for display purposes or if MIN_TX_FEE or MIN_RELAY_TX_FEE should be used in some way. Rune Kjær Svendsen suggested that a new value should be created, but no further information was provided as to why a new value was deemed necessary.A user named Rune K. Svendsen suggested changing the minimum fee recommended in the Main tab of the Options dialog from 0.01 to 0.001 BTC or even lower in a Bitcoin development mailing list. He proposed doing string substitution for both the value and the unit by defining a new value solely for display or using MIN_TX_FEE or MIN_RELAY_TX_FEE in some way. He sought more opinions from other developers before proceeding to write the code. Luke-Jr replied to his suggestion, advising him to use GitHub pull requests or publish a git repository instead of mailing patches. He also suggested two commits for this change and expressed no opinion on whether the recommended fee should be changed or not. Eligius uses a lower minimum fee, but most pools/miners treat anything under 0.01 BTC as if it were no fee at all.Rune K. Svendsen sent an email on March 11, 2013, suggesting changing the minimum fee recommendation for Bitcoin transactions from 0.01 BTC to 0.001 BTC or even lower. The current recommendation amounted to about $0.50 at the time of the email. Svendsen recommended making this change on the Main tab in the Options dialog. Svendsen also suggested that pull requests be used on GitHub instead of mailing patches. He further suggested breaking the changes into two commits. The first commit would involve moving the recommended fee outside the translatable string and formatting it using the user's preferred unit. The second commit would change the recommended fee in one place. Svendsen did not express an opinion on whether the recommended fee should be changed or not. However, he noted that some pools/miners would treat anything under 0.01 BTC as if it were no fee at all, despite Eligius using a lower minimum fee.A request has been made to change the minimum recommended transaction fee on the Main tab in the Options dialog. The current recommendation of 0.01 BTC is approximately $0.50 at today's price, but the request suggests changing it to 0.001 BTC or lower. Changes have been made to the optionsdialog.ui file and the localization files for various languages, including bg.ts, ca_ES.ts, cs.ts, da.ts, de.ts, el_GR.ts, en.ts, es.ts, es_CL.ts, et.ts, eu_ES.ts, fa.ts, fa_IR.ts, fi.ts, fr.ts, fr_CA.ts, gu_IN.ts, he.ts, hi_IN.ts, hr.ts, hu.ts, it.ts, ja.ts, lt.ts, nb.ts, nl.ts, pl.ts, pt_BR.ts, pt_PT.ts, ro_RO.ts, ru.ts, sk.ts, sr.ts, sv.ts, th_TH.ts, tr.ts, uk.ts, zh_CN.ts, and zh_TW.ts.The Bitcoin software provides an optional transaction fee per KB to ensure that transactions are processed quickly. Most transactions are 1 KB in size, and a fee of 0.01 BTC is recommended. However, recent updates suggest a lower fee of 0.001 BTC to be used instead. This information is provided in multiple language translations, including Spanish, Estonian, Basque, Persian, Finnish, French, Hebrew, Hindi, Croatian, and Hungarian. These translations can be found in their respective files within the src/qt/locale/ - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_0-8-1-ideas.xml b/static/bitcoin-dev/March_2013/combined_0-8-1-ideas.xml index 12574e84cc..0ecc0c21dc 100644 --- a/static/bitcoin-dev/March_2013/combined_0-8-1-ideas.xml +++ b/static/bitcoin-dev/March_2013/combined_0-8-1-ideas.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.8.1 ideas - 2023-08-01T04:33:18.326691+00:00 + 2025-10-11T21:28:40.873050+00:00 + python-feedgen Gregory Maxwell 2013-03-15 19:52:18+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - 0.8.1 ideas - 2023-08-01T04:33:18.326691+00:00 + 2025-10-11T21:28:40.873254+00:00 - On March 13, 2013, Bitcoin developers engaged in discussions regarding various issues and proposals. Benjamin Lindner expressed his opinion on software behavior not described by the source code, stating that it should not be considered part of the rule set. Cameron Garnham brought up the topic of Bitcoin's block size limit, arguing that it should be removed as it was not described in the source code. The discussion highlighted concerns about technical complications and risks associated with making such changes.There were discussions about client detection and warning in the case of non-trivial forking. Roy Badami suggested implementing a warning system to notify users during forks, which could help address incidents like the bug affecting Bitcoin users using version 0.8. Luke-Jr proposed that end-user clients should warn about such situations when possible, even if they are not always aware of the fork.The issue of assurance to users that their transactions were confirmed was raised. Andy Parkins expressed concern about the failure to provide this assurance, while Luke-Jr proposed changing the definition of "6 confirmations" to account for potential chain failures. The discussions emphasized the need for improved monitoring and warning systems in Bitcoin clients.Matthew Mitchell raised concerns about difficulties in getting people to update their systems from older versions. The development community explained the challenges involved in updating and upgrading Bitcoin software, including the need for integration and testing. The community also emphasized the importance of careful consideration of the risks and benefits when updating or upgrading.Mark Friedenbach proposed solutions to prevent hard forks and ensure consensus. However, there were debates about the definitions of hard forks and how to handle client divergence from consensus. Pieter Wuille pointed out that some proposed solutions still resulted in nodes accepting blocks they previously considered invalid.The urgency to increase the lock count in the blockchain was discussed to avoid potential crises. The proposal included patching pre-0.8 branches and coordinating with miners to remove the patch once widespread adoption was achieved. Luke-Jr also proposed a solution involving block size limits and soft and hard forks at specific block numbers.There were discussions about increasing the block size limit to accommodate transaction volume growth. While some developers, like Luke-Jr, believed a 2 MB increase over the next few years was uncontroversial, others, like Gregory Maxwell, urged caution to avoid controversial changes. Peter Todd noted concerns about the controversy surrounding the issue, including receiving threatening messages from opponents of the block size increase.In a proposal sent by Luke-Jr on March 13th, 2013, he suggested three rules for Bitcoin block sizes. The first rule applied before block 262144 and aimed to make older clients safe under most circumstances. It stated that no block should have over 4500 transaction modifications when combined with the previous four blocks. Additionally, no block should include more than 4500 transaction modifications on its own.The second rule applied between block 262144 and block 393216, which was referred to as hard fork #1. This rule stated that no block should include more than 24391 transaction modifications on its own, which was thought to be equivalent to 1MB. However, this rule could make older client backports safe unless a reorg was more than six blocks deep.The third and final rule applied from block 393216 onward, which was referred to as hard fork #2. This rule stated that no block should include more than 48781 transaction modifications on its own, which was thought to be equivalent to 2MB. Additionally, it allowed blocks up to 2MB in data size. The proposal aimed to discontinue support for clients prior to 0.8.1.Peter Todd replied to the proposal suggesting the need for a separate limit for how much the UTXO set can be grown by each block. He proposed setting the UTXO growth limit fairly low, at 1/4th of the block limit, given the uncertainty around limiting the creation of txouts that cannot be spent economically.In an email conversation, Luke-Jr proposed a hard fork from block 262144 to block 393216, where any block that includes more than 24391 transaction modifications on its own will be rejected. This change would ensure that older client backports remain safe unless there is a reorg deeper than six blocks.Another participant disagreed with the two-stage proposal and suggested choosing a number closer to 4911, which would still be less than what pre-0.8 accepts but need not be small. This participant argued that this approach would halve the complexity of the change by avoiding two hard forks. However, it would involve accepting some risk of "backport" clients getting stuck after large reorgs, which would require manual intervention to resolve.The participant further emphasized the importance of a separate process for the size change once a low-risk/low-controversy hardforking change has been proven. This would prevent another issue like the current one where the increase in block target exposed inadequate 2013-03-15T19:52:18+00:00 + On March 13, 2013, Bitcoin developers engaged in discussions regarding various issues and proposals. Benjamin Lindner expressed his opinion on software behavior not described by the source code, stating that it should not be considered part of the rule set. Cameron Garnham brought up the topic of Bitcoin's block size limit, arguing that it should be removed as it was not described in the source code. The discussion highlighted concerns about technical complications and risks associated with making such changes.There were discussions about client detection and warning in the case of non-trivial forking. Roy Badami suggested implementing a warning system to notify users during forks, which could help address incidents like the bug affecting Bitcoin users using version 0.8. Luke-Jr proposed that end-user clients should warn about such situations when possible, even if they are not always aware of the fork.The issue of assurance to users that their transactions were confirmed was raised. Andy Parkins expressed concern about the failure to provide this assurance, while Luke-Jr proposed changing the definition of "6 confirmations" to account for potential chain failures. The discussions emphasized the need for improved monitoring and warning systems in Bitcoin clients.Matthew Mitchell raised concerns about difficulties in getting people to update their systems from older versions. The development community explained the challenges involved in updating and upgrading Bitcoin software, including the need for integration and testing. The community also emphasized the importance of careful consideration of the risks and benefits when updating or upgrading.Mark Friedenbach proposed solutions to prevent hard forks and ensure consensus. However, there were debates about the definitions of hard forks and how to handle client divergence from consensus. Pieter Wuille pointed out that some proposed solutions still resulted in nodes accepting blocks they previously considered invalid.The urgency to increase the lock count in the blockchain was discussed to avoid potential crises. The proposal included patching pre-0.8 branches and coordinating with miners to remove the patch once widespread adoption was achieved. Luke-Jr also proposed a solution involving block size limits and soft and hard forks at specific block numbers.There were discussions about increasing the block size limit to accommodate transaction volume growth. While some developers, like Luke-Jr, believed a 2 MB increase over the next few years was uncontroversial, others, like Gregory Maxwell, urged caution to avoid controversial changes. Peter Todd noted concerns about the controversy surrounding the issue, including receiving threatening messages from opponents of the block size increase.In a proposal sent by Luke-Jr on March 13th, 2013, he suggested three rules for Bitcoin block sizes. The first rule applied before block 262144 and aimed to make older clients safe under most circumstances. It stated that no block should have over 4500 transaction modifications when combined with the previous four blocks. Additionally, no block should include more than 4500 transaction modifications on its own.The second rule applied between block 262144 and block 393216, which was referred to as hard fork #1. This rule stated that no block should include more than 24391 transaction modifications on its own, which was thought to be equivalent to 1MB. However, this rule could make older client backports safe unless a reorg was more than six blocks deep.The third and final rule applied from block 393216 onward, which was referred to as hard fork #2. This rule stated that no block should include more than 48781 transaction modifications on its own, which was thought to be equivalent to 2MB. Additionally, it allowed blocks up to 2MB in data size. The proposal aimed to discontinue support for clients prior to 0.8.1.Peter Todd replied to the proposal suggesting the need for a separate limit for how much the UTXO set can be grown by each block. He proposed setting the UTXO growth limit fairly low, at 1/4th of the block limit, given the uncertainty around limiting the creation of txouts that cannot be spent economically.In an email conversation, Luke-Jr proposed a hard fork from block 262144 to block 393216, where any block that includes more than 24391 transaction modifications on its own will be rejected. This change would ensure that older client backports remain safe unless there is a reorg deeper than six blocks.Another participant disagreed with the two-stage proposal and suggested choosing a number closer to 4911, which would still be less than what pre-0.8 accepts but need not be small. This participant argued that this approach would halve the complexity of the change by avoiding two hard forks. However, it would involve accepting some risk of "backport" clients getting stuck after large reorgs, which would require manual intervention to resolve.The participant further emphasized the importance of a separate process for the size change once a low-risk/low-controversy hardforking change has been proven. This would prevent another issue like the current one where the increase in block target exposed inadequate - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_0-8-1-plan.xml b/static/bitcoin-dev/March_2013/combined_0-8-1-plan.xml index c34f5cb26d..4a05212773 100644 --- a/static/bitcoin-dev/March_2013/combined_0-8-1-plan.xml +++ b/static/bitcoin-dev/March_2013/combined_0-8-1-plan.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.8.1 plan - 2023-08-01T04:34:24.970407+00:00 + 2025-10-11T21:28:34.501903+00:00 + python-feedgen Luke-Jr 2013-03-17 15:29:37+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - 0.8.1 plan - 2023-08-01T04:34:24.970407+00:00 + 2025-10-11T21:28:34.502083+00:00 - In a conversation on March 17, 2013, Frank F expressed concerns about the recommended configuration on the may15.html page on bitcoin.org. He suggested that the recommended lock limit should be at least 292692 to avoid potential issues with deep reorgs. Frank also questioned the inclusion of set_lg_dir in the example config, as it could cause problems if the client is using a different directory. He requested that a note be added indicating that previous versions will receive backports in their next stable releases before May 15.Gavin Andresen, a prominent figure in the Bitcoin community, has stated that he will not be changing the date for the upcoming "Bitcoin Independence Day" celebration on May 15. Despite acknowledging that it may be inconvenient and confusing, Andresen is firm in his decision to stick to the original date. He emphasized the need to focus on more important tasks, such as hard-forking to increase the 1MB blocksize limit. This move is seen as practice for the eventual hard-fork required to further increase the blocksize limit.In a conversation on March 16, 2013, between Alan Reiner and Gavin Andresen, the latter mentioned that he chose May 15 as the date for people to upgrade or find a workaround arbitrarily. Reiner suggested pushing back the date by a week due to the Bitcoin Conference being scheduled two days after May 15, which could cause unnecessary stress if something goes wrong. However, changing the date at this point would be impractical since the page bitcoin.org/may15.html had already been created.Gavin Andresen, a developer and Bitcoin pioneer, initially suggested in March 2013 that Bitcoin users should upgrade their software or find workarounds by May 15th. The date was chosen arbitrarily, but Gavin believed that two months provided a reasonable timeframe for everyone to make the necessary changes. Alan, another member of the community, proposed pushing back the deadline by one week to avoid potential stress for conference attendees. However, changing the date was deemed impractical at that point.The Bitcoin team has announced plans for the 0.8.1 release, which includes a new CheckBlock() rule that only allows blocks compatible with old releases to be accepted into the main chain. The limit of 500k to blocks created will also be in effect until May 15. Alerts will be sent to pre-0.8 releases over the next two months, urging users to either upgrade or create a DB_CONFIG file to handle large blocks. The fix was designed to be easily ported to previous versions. The binaries for the 0.8.1 version will be available soon. Multiple alerts will be sent leading up to May 15, reminding users to upgrade or find workarounds. After May 15, miners will be able to create blocks up to 1MB, and users running old versions who ignored the alerts may be left behind. 2013-03-17T15:29:37+00:00 + In a conversation on March 17, 2013, Frank F expressed concerns about the recommended configuration on the may15.html page on bitcoin.org. He suggested that the recommended lock limit should be at least 292692 to avoid potential issues with deep reorgs. Frank also questioned the inclusion of set_lg_dir in the example config, as it could cause problems if the client is using a different directory. He requested that a note be added indicating that previous versions will receive backports in their next stable releases before May 15.Gavin Andresen, a prominent figure in the Bitcoin community, has stated that he will not be changing the date for the upcoming "Bitcoin Independence Day" celebration on May 15. Despite acknowledging that it may be inconvenient and confusing, Andresen is firm in his decision to stick to the original date. He emphasized the need to focus on more important tasks, such as hard-forking to increase the 1MB blocksize limit. This move is seen as practice for the eventual hard-fork required to further increase the blocksize limit.In a conversation on March 16, 2013, between Alan Reiner and Gavin Andresen, the latter mentioned that he chose May 15 as the date for people to upgrade or find a workaround arbitrarily. Reiner suggested pushing back the date by a week due to the Bitcoin Conference being scheduled two days after May 15, which could cause unnecessary stress if something goes wrong. However, changing the date at this point would be impractical since the page bitcoin.org/may15.html had already been created.Gavin Andresen, a developer and Bitcoin pioneer, initially suggested in March 2013 that Bitcoin users should upgrade their software or find workarounds by May 15th. The date was chosen arbitrarily, but Gavin believed that two months provided a reasonable timeframe for everyone to make the necessary changes. Alan, another member of the community, proposed pushing back the deadline by one week to avoid potential stress for conference attendees. However, changing the date was deemed impractical at that point.The Bitcoin team has announced plans for the 0.8.1 release, which includes a new CheckBlock() rule that only allows blocks compatible with old releases to be accepted into the main chain. The limit of 500k to blocks created will also be in effect until May 15. Alerts will be sent to pre-0.8 releases over the next two months, urging users to either upgrade or create a DB_CONFIG file to handle large blocks. The fix was designed to be easily ported to previous versions. The binaries for the 0.8.1 version will be available soon. Multiple alerts will be sent leading up to May 15, reminding users to upgrade or find workarounds. After May 15, miners will be able to create blocks up to 1MB, and users running old versions who ignored the alerts may be left behind. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_A-bitcoin-UDP-P2P-protocol-extension.xml b/static/bitcoin-dev/March_2013/combined_A-bitcoin-UDP-P2P-protocol-extension.xml index 7a1294ae2f..c6e30227d3 100644 --- a/static/bitcoin-dev/March_2013/combined_A-bitcoin-UDP-P2P-protocol-extension.xml +++ b/static/bitcoin-dev/March_2013/combined_A-bitcoin-UDP-P2P-protocol-extension.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A bitcoin UDP P2P protocol extension - 2023-08-01T04:34:51.200804+00:00 + 2025-10-11T21:28:23.860943+00:00 + python-feedgen Ralph J.Mayer 2013-03-24 09:11:24+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - A bitcoin UDP P2P protocol extension - 2023-08-01T04:34:51.200804+00:00 + 2025-10-11T21:28:23.861158+00:00 - The conversation revolves around the usage of SCTP (Stream Control Transmission Protocol) and newer user-mode transports that run over UDP. The person expressing their opinions is a fan of SCTP but acknowledges that firewall practices often restrict the implementation of new protocols like SCTP. They suggest exploring alternative protocols like UDT (UDP-based Data Transfer Protocol) and SCTP, which offer advanced features such as reliable data transfer, multi-streaming capabilities, and support for multiple flows sharing a single port. The person also mentions that they are not directly involved in the project but want to prevent reinventing the wheel.In another conversation between Gregory Maxwell and Jeff Garzik, it is mentioned that SCTP is considered an optimal transport for Bitcoin-like messaging due to its versatility in adjusting almost everything into a message. However, Jeff Garzik points out that firewall practices tend to hinder the implementation of new protocols like SCTP.Jay F raises concerns about TCP/UDP port forwarding for bulk data transfer and suggests using tunneling. They provide a link to a document discussing the encapsulation of DTLS over SCTP and suggest that using SCTP could be beneficial for Bitcoin-like messaging. Jay F also suggests that using SCTP could result in a data stream resembling WEBRTC traffic.UDT is highlighted as a solution for breaking the data transfer bottleneck, as it uses UDP to transfer bulk data with its own reliability control and congestion control mechanisms. It allows multiple UDT flows to share a single UDP port, making it firewall-friendly. However, it may not be friendly to NAT. SCTP is mentioned as another protocol that provides reliable, ordered, and error-checked delivery of data between applications, with support for multiple streams of messages in a single connection.Jeff Garzik proposes a rough draft implementation of a UDP P2P protocol extension for Bitcoin. The goals include improving "inv" relay speed, unconditional "tx" broadcasting via UDP as an alternative to "inv" for small transactions, improving block relay speed, and opening up new design avenues more suited to UDP than TCP. The protocol specification includes using UDP bound to the same port as TCP P2P, requiring an active simultaneous TCP P2P connection, permitting multiple P2P messages per UDP packet, and setting a maximum UDP packet size of 100*1024 bytes.The conversation discusses the usage of UDP and the need for a notion of association when subscribing to a broadcast. It is proposed that a parallel TCP connection with a version/verack sequence can be used if a connection is needed. Alternatively, a more robust and heavyweight UDP P2P protocol could be a hole-punching TCP alternative, but further experimentation and community input are required. Bittorrent's use of UDP in its protocols is mentioned as a potential solution to problems with short-lived HTTP connections and bufferbloat in active TCP connections.Randy Willis suggests introducing super-nodes with thousands of connected peers to enhance the capabilities of UDP, but Luke-Jr emphasizes that any UDP bitcoin protocol should not try to emulate a connection.Jeff Garzik's rough draft implementation of the UDP P2P protocol extension for Bitcoin is detailed, highlighting its features, such as multiple P2P messages per UDP packet, advertising NODE_UDP, and handling commands like "inv", "tx", and "addr". The project aims to improve "inv" relay speed, investigate unconditional "tx" broadcasting via UDP, improve block relay speed, and explore new design avenues for P2P patterns more suited to UDP. Jeff Garzik believes that productive discussions start with code rather than endless discussion. 2013-03-24T09:11:24+00:00 + The conversation revolves around the usage of SCTP (Stream Control Transmission Protocol) and newer user-mode transports that run over UDP. The person expressing their opinions is a fan of SCTP but acknowledges that firewall practices often restrict the implementation of new protocols like SCTP. They suggest exploring alternative protocols like UDT (UDP-based Data Transfer Protocol) and SCTP, which offer advanced features such as reliable data transfer, multi-streaming capabilities, and support for multiple flows sharing a single port. The person also mentions that they are not directly involved in the project but want to prevent reinventing the wheel.In another conversation between Gregory Maxwell and Jeff Garzik, it is mentioned that SCTP is considered an optimal transport for Bitcoin-like messaging due to its versatility in adjusting almost everything into a message. However, Jeff Garzik points out that firewall practices tend to hinder the implementation of new protocols like SCTP.Jay F raises concerns about TCP/UDP port forwarding for bulk data transfer and suggests using tunneling. They provide a link to a document discussing the encapsulation of DTLS over SCTP and suggest that using SCTP could be beneficial for Bitcoin-like messaging. Jay F also suggests that using SCTP could result in a data stream resembling WEBRTC traffic.UDT is highlighted as a solution for breaking the data transfer bottleneck, as it uses UDP to transfer bulk data with its own reliability control and congestion control mechanisms. It allows multiple UDT flows to share a single UDP port, making it firewall-friendly. However, it may not be friendly to NAT. SCTP is mentioned as another protocol that provides reliable, ordered, and error-checked delivery of data between applications, with support for multiple streams of messages in a single connection.Jeff Garzik proposes a rough draft implementation of a UDP P2P protocol extension for Bitcoin. The goals include improving "inv" relay speed, unconditional "tx" broadcasting via UDP as an alternative to "inv" for small transactions, improving block relay speed, and opening up new design avenues more suited to UDP than TCP. The protocol specification includes using UDP bound to the same port as TCP P2P, requiring an active simultaneous TCP P2P connection, permitting multiple P2P messages per UDP packet, and setting a maximum UDP packet size of 100*1024 bytes.The conversation discusses the usage of UDP and the need for a notion of association when subscribing to a broadcast. It is proposed that a parallel TCP connection with a version/verack sequence can be used if a connection is needed. Alternatively, a more robust and heavyweight UDP P2P protocol could be a hole-punching TCP alternative, but further experimentation and community input are required. Bittorrent's use of UDP in its protocols is mentioned as a potential solution to problems with short-lived HTTP connections and bufferbloat in active TCP connections.Randy Willis suggests introducing super-nodes with thousands of connected peers to enhance the capabilities of UDP, but Luke-Jr emphasizes that any UDP bitcoin protocol should not try to emulate a connection.Jeff Garzik's rough draft implementation of the UDP P2P protocol extension for Bitcoin is detailed, highlighting its features, such as multiple P2P messages per UDP packet, advertising NODE_UDP, and handling commands like "inv", "tx", and "addr". The project aims to improve "inv" relay speed, investigate unconditional "tx" broadcasting via UDP, improve block relay speed, and explore new design avenues for P2P patterns more suited to UDP. Jeff Garzik believes that productive discussions start with code rather than endless discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Blocking-uneconomical-UTXO-creation.xml b/static/bitcoin-dev/March_2013/combined_Blocking-uneconomical-UTXO-creation.xml index 92db963fc9..78fc2961c5 100644 --- a/static/bitcoin-dev/March_2013/combined_Blocking-uneconomical-UTXO-creation.xml +++ b/static/bitcoin-dev/March_2013/combined_Blocking-uneconomical-UTXO-creation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Blocking uneconomical UTXO creation - 2023-08-01T04:30:01.703982+00:00 + 2025-10-11T21:28:21.735388+00:00 + python-feedgen Jorge Timón 2013-03-13 09:20:17+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Blocking uneconomical UTXO creation - 2023-08-01T04:30:01.704984+00:00 + 2025-10-11T21:28:21.735616+00:00 - In a discussion about transaction fees in Bitcoin, Stephen Pair proposes a new approach to paying for transactions. He suggests that instead of blocking uneconomical transactions, there should be a market for fee-bearing transactions. This system would allow for determining the probability of confirmation in a specific timeframe for a given fee. Peter Todd responds to this by discussing the costs of creating unspent transaction outputs (UTXO) and suggests a standard transaction type for unspendable but not provably so transaction outputs. He highlights the advantages of this approach for timestamping and secure data backups.The conversation also touches on the use of RAM as a database cache, potential attack scenarios on the UTXO, and the scalability of Bitcoin. The cost of storing data in the UTXO set is noted to be more expensive than storing the actual transaction data. The current fee system based on KB in a block is argued to not capture the long-term costs of UTXO creation. To address this, Todd suggests paying for a feed of economical transactions to determine confirmation probabilities. He also proposes using unspendable but not provably so transaction outputs for timestamping and secure data backups.There is a concern raised about potential attacks on the UTXO storage if it is not stored in fast storage. The specific attack scenario is not clarified, but it is mentioned that attempting to send fake transactions to nodes with invalid transactions would result in disconnection and IP banning. The need to prioritize addressing potential denial-of-service attacks on Bitcoin is emphasized.The UTXO set is currently stored in LevelDB and not in memory. Unspendable outputs are not part of the working set and can be moved to a separate database if necessary. Immediate pruning can be done for proven unspendable outputs, and consensus has been reached on adding a standard template for insta-pruning. However, low-value spendable outputs pose challenges, and wallet apps need to find a balance in output sizes. Wallets with lots of small outputs generate larger transactions that take longer to verify.The discussion explores the possibility of transitioning from a peer-to-peer network to a Distributed Hash Table (DHT) for storing, validating, and verifying UTXOs. While the current use of UTXOs in the Satoshi client does not directly involve DHT, it speeds up validation by checking if an output is unspent. An alternative method is suggested that uses an authenticated data structure storing UTXOs in a DHT.The issue of scalability of Bitcoin and the size of the UTXO set is addressed. The proposal is made to move from a peer-to-peer network to a DHT to accommodate a growing UTXO set. Concerns are raised about abusive/misuse or massive use of systems like SatoshiDice, which contribute to UTXO bloat. The need for protocol-level discouragement of such spamming is highlighted to allow for scaling without excessive memory leaks.Different opinions are expressed regarding the size of the UTXO set and the need for solutions. It is argued that the UTXO problem scales with the block size limit and should be resolved before considering increasing it. The idea of making transaction outputs with a value less than the transaction fee non-standard is debated, with alternative proposals like activating a non-proportional demurrage to incentivize old transactions to be moved. Concerns about the incentive structure and negative community response are raised.The possibility of introducing demurrage as a fee for holding bitcoins or any cryptocurrency is discussed. While some believe it would face negative publicity, the suggestion of creating a separate coin with a finite lifespan is proposed. This alt-coin, called "tempcoin," could have rules where miners reclaim coins older than a certain block height.In a discussion about micropayments and demurrage in Bitcoin, it is questioned whether these concepts are still relevant considering that the base rules of Bitcoin will not be changing. The size of the UTXO set is also debated, with some arguing that minimizing its size is unnecessary as it currently takes up only a few hundred megabytes and can easily fit into RAM or disk.Banning micropayments is seen as potentially detrimental to interesting applications without providing any real benefit. Instead, there are less invasive changes proposed for improving scalability. These include making transaction validation multi-threaded, transmitting merkle blocks instead of full blocks, moving blocking disk IO off the main loop, and completing the payment protocol work.Jorge Timón suggests an alternative solution to the perceived problem of micropayments and demurrage. He proposes a sudden "destruction" or re-generation of accounts after a certain period rather than rejecting potential use cases for the Bitcoin chain. While he prefers a small fixed demurrage fee after a specific number of blocks without moving them, he acknowledges the community's aversion to demurrage and suggests charging a fee for a resource that users are enjoying and has real costs for the network.Gavin Andresen opposes the idea 2013-03-13T09:20:17+00:00 + In a discussion about transaction fees in Bitcoin, Stephen Pair proposes a new approach to paying for transactions. He suggests that instead of blocking uneconomical transactions, there should be a market for fee-bearing transactions. This system would allow for determining the probability of confirmation in a specific timeframe for a given fee. Peter Todd responds to this by discussing the costs of creating unspent transaction outputs (UTXO) and suggests a standard transaction type for unspendable but not provably so transaction outputs. He highlights the advantages of this approach for timestamping and secure data backups.The conversation also touches on the use of RAM as a database cache, potential attack scenarios on the UTXO, and the scalability of Bitcoin. The cost of storing data in the UTXO set is noted to be more expensive than storing the actual transaction data. The current fee system based on KB in a block is argued to not capture the long-term costs of UTXO creation. To address this, Todd suggests paying for a feed of economical transactions to determine confirmation probabilities. He also proposes using unspendable but not provably so transaction outputs for timestamping and secure data backups.There is a concern raised about potential attacks on the UTXO storage if it is not stored in fast storage. The specific attack scenario is not clarified, but it is mentioned that attempting to send fake transactions to nodes with invalid transactions would result in disconnection and IP banning. The need to prioritize addressing potential denial-of-service attacks on Bitcoin is emphasized.The UTXO set is currently stored in LevelDB and not in memory. Unspendable outputs are not part of the working set and can be moved to a separate database if necessary. Immediate pruning can be done for proven unspendable outputs, and consensus has been reached on adding a standard template for insta-pruning. However, low-value spendable outputs pose challenges, and wallet apps need to find a balance in output sizes. Wallets with lots of small outputs generate larger transactions that take longer to verify.The discussion explores the possibility of transitioning from a peer-to-peer network to a Distributed Hash Table (DHT) for storing, validating, and verifying UTXOs. While the current use of UTXOs in the Satoshi client does not directly involve DHT, it speeds up validation by checking if an output is unspent. An alternative method is suggested that uses an authenticated data structure storing UTXOs in a DHT.The issue of scalability of Bitcoin and the size of the UTXO set is addressed. The proposal is made to move from a peer-to-peer network to a DHT to accommodate a growing UTXO set. Concerns are raised about abusive/misuse or massive use of systems like SatoshiDice, which contribute to UTXO bloat. The need for protocol-level discouragement of such spamming is highlighted to allow for scaling without excessive memory leaks.Different opinions are expressed regarding the size of the UTXO set and the need for solutions. It is argued that the UTXO problem scales with the block size limit and should be resolved before considering increasing it. The idea of making transaction outputs with a value less than the transaction fee non-standard is debated, with alternative proposals like activating a non-proportional demurrage to incentivize old transactions to be moved. Concerns about the incentive structure and negative community response are raised.The possibility of introducing demurrage as a fee for holding bitcoins or any cryptocurrency is discussed. While some believe it would face negative publicity, the suggestion of creating a separate coin with a finite lifespan is proposed. This alt-coin, called "tempcoin," could have rules where miners reclaim coins older than a certain block height.In a discussion about micropayments and demurrage in Bitcoin, it is questioned whether these concepts are still relevant considering that the base rules of Bitcoin will not be changing. The size of the UTXO set is also debated, with some arguing that minimizing its size is unnecessary as it currently takes up only a few hundred megabytes and can easily fit into RAM or disk.Banning micropayments is seen as potentially detrimental to interesting applications without providing any real benefit. Instead, there are less invasive changes proposed for improving scalability. These include making transaction validation multi-threaded, transmitting merkle blocks instead of full blocks, moving blocking disk IO off the main loop, and completing the payment protocol work.Jorge Timón suggests an alternative solution to the perceived problem of micropayments and demurrage. He proposes a sudden "destruction" or re-generation of accounts after a certain period rather than rejecting potential use cases for the Bitcoin chain. While he prefers a small fixed demurrage fee after a specific number of blocks without moving them, he acknowledges the community's aversion to demurrage and suggests charging a fee for a resource that users are enjoying and has real costs for the network.Gavin Andresen opposes the idea - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Blocksize-and-off-chain-transactions.xml b/static/bitcoin-dev/March_2013/combined_Blocksize-and-off-chain-transactions.xml index 29df92d972..e09f64da1a 100644 --- a/static/bitcoin-dev/March_2013/combined_Blocksize-and-off-chain-transactions.xml +++ b/static/bitcoin-dev/March_2013/combined_Blocksize-and-off-chain-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Blocksize and off-chain transactions - 2023-08-01T04:33:37.332961+00:00 + 2025-10-11T21:28:47.254995+00:00 + python-feedgen Michael Gronager 2013-03-13 20:14:24+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Blocksize and off-chain transactions - 2023-08-01T04:33:37.333960+00:00 + 2025-10-11T21:28:47.255197+00:00 - In a recent email exchange within the Bitcoin community, the topic of dropping support for old nodes was discussed. It was deemed unreasonable to implement a hardfork without proper discussion and consensus from the majority of the network. Pieter Wuille proposed a solution to address the issue of a block causing version 0.7 to "get stuck" by releasing version 0.8.1 as a stopgap measure. However, it was suggested that the new version should not precisely emulate the old behavior to avoid issues for nodes using version 0.7. Instead, a network with a mix of version 0.8.1 and version 0.7 nodes would eliminate the risk of a fork.Michael Gronager clarified that the issues were in version 0.7 and below, not in 0.8. He argued against changing features in 0.8 to accommodate previous versions, stating that it would not be a viable solution for future situations. The way forward suggested was to create a 0.8.1 version that mimics the old behavior while fixing the lock limit issue. Patches can also be provided for 0.7 and previous branches to enforce the same limit as 0.8.1. A hard fork will eventually be necessary to drop the 0.8.1 limit, but widespread community consensus is required.The author emphasizes the importance of adhering to the established protocol, as version 0.8's failure to do so has created an issue. They propose a "considerate mining" setup where pools run on either the newest or second newest version (e.g. 0.8), but connect to the rest of the network only through a node of the other version (e.g. 0.7). This ensures that no blocks will be rejected by either version and that the two combined will make up the majority of the network.In a discussion about increasing the blocksize limit to accommodate increased transaction volume, there is disagreement over whether to pursue off-chain transactions or not. However, it is acknowledged that the blocksize limit will likely be raised in less than two years due to pressure from big businesses using the chain. The vision has always been to scale up and limiting the blockchain to single-digit transactions-per-second is not an option. Off-chain transactions will also be necessary for instantly confirmed transactions. Gavin Andresen argues that raising the block size limit is necessary to scale up the blockchain, but believes the discussion should be postponed until version 0.8.1 is released. 2013-03-13T20:14:24+00:00 + In a recent email exchange within the Bitcoin community, the topic of dropping support for old nodes was discussed. It was deemed unreasonable to implement a hardfork without proper discussion and consensus from the majority of the network. Pieter Wuille proposed a solution to address the issue of a block causing version 0.7 to "get stuck" by releasing version 0.8.1 as a stopgap measure. However, it was suggested that the new version should not precisely emulate the old behavior to avoid issues for nodes using version 0.7. Instead, a network with a mix of version 0.8.1 and version 0.7 nodes would eliminate the risk of a fork.Michael Gronager clarified that the issues were in version 0.7 and below, not in 0.8. He argued against changing features in 0.8 to accommodate previous versions, stating that it would not be a viable solution for future situations. The way forward suggested was to create a 0.8.1 version that mimics the old behavior while fixing the lock limit issue. Patches can also be provided for 0.7 and previous branches to enforce the same limit as 0.8.1. A hard fork will eventually be necessary to drop the 0.8.1 limit, but widespread community consensus is required.The author emphasizes the importance of adhering to the established protocol, as version 0.8's failure to do so has created an issue. They propose a "considerate mining" setup where pools run on either the newest or second newest version (e.g. 0.8), but connect to the rest of the network only through a node of the other version (e.g. 0.7). This ensures that no blocks will be rejected by either version and that the two combined will make up the majority of the network.In a discussion about increasing the blocksize limit to accommodate increased transaction volume, there is disagreement over whether to pursue off-chain transactions or not. However, it is acknowledged that the blocksize limit will likely be raised in less than two years due to pressure from big businesses using the chain. The vision has always been to scale up and limiting the blockchain to single-digit transactions-per-second is not an option. Off-chain transactions will also be necessary for instantly confirmed transactions. Gavin Andresen argues that raising the block size limit is necessary to scale up the blockchain, but believes the discussion should be postponed until version 0.8.1 is released. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Changing-the-fee-on-already-sent-transactions.xml b/static/bitcoin-dev/March_2013/combined_Changing-the-fee-on-already-sent-transactions.xml index d4ef507a8d..dcc4cf07b6 100644 --- a/static/bitcoin-dev/March_2013/combined_Changing-the-fee-on-already-sent-transactions.xml +++ b/static/bitcoin-dev/March_2013/combined_Changing-the-fee-on-already-sent-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Changing the fee on already sent transactions - 2023-08-01T04:32:02.578319+00:00 + 2025-10-11T21:28:30.248703+00:00 + python-feedgen Luke-Jr 2013-03-12 13:10:20+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Changing the fee on already sent transactions - 2023-08-01T04:32:02.578319+00:00 + 2025-10-11T21:28:30.248880+00:00 - In a message sent on March 12, 2013, Bitcoin developer Peter Todd discussed the possibility of transaction replacement to add fees to existing transactions without increasing the risk of double-spends. He suggested using the stubbed out replacement code, which allows the replacement of a transaction only if a transaction spending the same tx is not already present in the mempool.Todd proposed changing the replacement logic for Bitcoin transactions to evaluate if the candidate replacement does not remove or decrease the value of any existing outputs. This change would prevent DoS attacks by only accepting replacements that increase the fees paid by at least MIN_RELAY_TX_FEE * size. Todd argued that this method is preferable to the fast expiration method previously proposed, as he believes it would lower the security of Bitcoin.While implementing this new replacement logic would require complexity and testing, Todd believes that achieving full branch coverage of the code would be straightforward. He also suggests that implementing this logic correctly could reduce the urgency of including child-pays-for-parent in Bitcoin.Overall, the proposed approach of allowing transaction replacement for adding fees appears to be a viable solution. By utilizing the replacement code and carefully checking for conflicts in the mempool, it should be possible to safely replace old transactions with new ones and add the necessary fees. 2013-03-12T13:10:20+00:00 + In a message sent on March 12, 2013, Bitcoin developer Peter Todd discussed the possibility of transaction replacement to add fees to existing transactions without increasing the risk of double-spends. He suggested using the stubbed out replacement code, which allows the replacement of a transaction only if a transaction spending the same tx is not already present in the mempool.Todd proposed changing the replacement logic for Bitcoin transactions to evaluate if the candidate replacement does not remove or decrease the value of any existing outputs. This change would prevent DoS attacks by only accepting replacements that increase the fees paid by at least MIN_RELAY_TX_FEE * size. Todd argued that this method is preferable to the fast expiration method previously proposed, as he believes it would lower the security of Bitcoin.While implementing this new replacement logic would require complexity and testing, Todd believes that achieving full branch coverage of the code would be straightforward. He also suggests that implementing this logic correctly could reduce the urgency of including child-pays-for-parent in Bitcoin.Overall, the proposed approach of allowing transaction replacement for adding fees appears to be a viable solution. By utilizing the replacement code and carefully checking for conflicts in the mempool, it should be possible to safely replace old transactions with new ones and add the necessary fees. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Key-retirement-and-key-compromise.xml b/static/bitcoin-dev/March_2013/combined_Key-retirement-and-key-compromise.xml index d18259969b..d2dcd70c3c 100644 --- a/static/bitcoin-dev/March_2013/combined_Key-retirement-and-key-compromise.xml +++ b/static/bitcoin-dev/March_2013/combined_Key-retirement-and-key-compromise.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Key retirement and key compromise - 2023-08-01T04:26:59.002770+00:00 + 2025-10-11T21:28:32.371096+00:00 + python-feedgen Roy Badami 2013-03-25 21:35:45+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Key retirement and key compromise - 2023-08-01T04:26:59.002770+00:00 + 2025-10-11T21:28:32.371253+00:00 - In a conversation between Gregory Maxwell and Roy Badami, the idea of implementing an overlay protocol to address transactions to revoked addresses in Bitcoin was discussed. This proposal aimed to make such transactions invalid, but it was noted that this would require adding more perpetual data for all validating nodes, leading to a drastic change in the rules. To tackle this problem, Roy suggested that addresses should have expiry dates to avoid maintaining revocation lists indefinitely. It was also mentioned that reusing addresses is generally not recommended, although it may be unavoidable in certain cases. In some use cases, the payment protocol could help mitigate this issue.Roy Badami proposed the concept of an overlay protocol in an email conversation from March 25, 2013. This suggestion was in response to the idea of changing rules to invalidate transactions to revoked addresses. However, another individual pointed out that even implementing an overlay protocol could be significant as it would require perpetual data to remain in fast lookup for all validating nodes. The discussion also emphasized the potential risks of reusing addresses when using Bitcoin.In 2013, Roy suggested the implementation of a "big key compromise button" for Bitcoin, which would transfer all coins to newly generated addresses automatically. However, Andrew Poelstra raised concerns about this idea, as it could expose the public key in use and potentially compromised to attackers. Realizing the need for a means to revoke an address rather than automatic transmissions, Roy proposed an address revocation protocol. This protocol would generate an error if a user tried to send coins to a revoked address. Instead of changing the rules to invalidate transactions to revoked addresses, Roy suggested the implementation of an overlay protocol. This functionality could potentially be incorporated into the payment protocol, although Roy remained unsure about this approach's effectiveness. For the protocol to be useful, it would need to be universally implemented by clients.A related idea discussed was the concept of a "dead" button. This involved sending pre-generated transactions to previously secured addresses in case of an emergency. By using a long-term storage address or set of addresses, coins could be stored and transferred to emergency storage during panic situations using signed transactions. However, if some BTC had been sent or received from the long-term storage, the panic transaction would only capture a portion of it. Nevertheless, the security requirements for the panic transaction leaking were lower than those for private keys, reducing the risk of losing all coins. This idea could be complemented by a server that monitors the blockchain for unauthorized transactions, providing an automated security layer. Opinions on the effectiveness of this approach varied in enterprise scenarios.On February 23, 2013, Roy Badami suggested creating tools to help manage key retirement and compromise for Bitcoin users. Currently, if someone suspects their keys may be compromised, they must create a new wallet and transfer their coins from the old wallet to the new one. This process is cumbersome and results in the loss of the address book and transaction history unless the old wallet is kept. To address this, Roy proposed the inclusion of a "big key compromise button" in Bitcoin. This button would automatically transfer all coins to newly generated addresses and offer the option to flag compromised or retired addresses. Roy believed that this functionality should be developed within the official client, and the first step would involve specifying the desired features. Despite the popularity of deterministic wallets, Roy preferred having a collection of keys since old keys would be regularly retired, with their balances automatically transferring to newly generated keys. Finally, Roy expressed the desire for a panic button that would enable the automatic transfer of all coins to new addresses in case of an accidental mistake like typing the passphrase into an IRC window. The Bitcoin community showed interest in developing this functionality within the official client, but determining the exact desired functionality was considered the initial step. 2013-03-25T21:35:45+00:00 + In a conversation between Gregory Maxwell and Roy Badami, the idea of implementing an overlay protocol to address transactions to revoked addresses in Bitcoin was discussed. This proposal aimed to make such transactions invalid, but it was noted that this would require adding more perpetual data for all validating nodes, leading to a drastic change in the rules. To tackle this problem, Roy suggested that addresses should have expiry dates to avoid maintaining revocation lists indefinitely. It was also mentioned that reusing addresses is generally not recommended, although it may be unavoidable in certain cases. In some use cases, the payment protocol could help mitigate this issue.Roy Badami proposed the concept of an overlay protocol in an email conversation from March 25, 2013. This suggestion was in response to the idea of changing rules to invalidate transactions to revoked addresses. However, another individual pointed out that even implementing an overlay protocol could be significant as it would require perpetual data to remain in fast lookup for all validating nodes. The discussion also emphasized the potential risks of reusing addresses when using Bitcoin.In 2013, Roy suggested the implementation of a "big key compromise button" for Bitcoin, which would transfer all coins to newly generated addresses automatically. However, Andrew Poelstra raised concerns about this idea, as it could expose the public key in use and potentially compromised to attackers. Realizing the need for a means to revoke an address rather than automatic transmissions, Roy proposed an address revocation protocol. This protocol would generate an error if a user tried to send coins to a revoked address. Instead of changing the rules to invalidate transactions to revoked addresses, Roy suggested the implementation of an overlay protocol. This functionality could potentially be incorporated into the payment protocol, although Roy remained unsure about this approach's effectiveness. For the protocol to be useful, it would need to be universally implemented by clients.A related idea discussed was the concept of a "dead" button. This involved sending pre-generated transactions to previously secured addresses in case of an emergency. By using a long-term storage address or set of addresses, coins could be stored and transferred to emergency storage during panic situations using signed transactions. However, if some BTC had been sent or received from the long-term storage, the panic transaction would only capture a portion of it. Nevertheless, the security requirements for the panic transaction leaking were lower than those for private keys, reducing the risk of losing all coins. This idea could be complemented by a server that monitors the blockchain for unauthorized transactions, providing an automated security layer. Opinions on the effectiveness of this approach varied in enterprise scenarios.On February 23, 2013, Roy Badami suggested creating tools to help manage key retirement and compromise for Bitcoin users. Currently, if someone suspects their keys may be compromised, they must create a new wallet and transfer their coins from the old wallet to the new one. This process is cumbersome and results in the loss of the address book and transaction history unless the old wallet is kept. To address this, Roy proposed the inclusion of a "big key compromise button" in Bitcoin. This button would automatically transfer all coins to newly generated addresses and offer the option to flag compromised or retired addresses. Roy believed that this functionality should be developed within the official client, and the first step would involve specifying the desired features. Despite the popularity of deterministic wallets, Roy preferred having a collection of keys since old keys would be regularly retired, with their balances automatically transferring to newly generated keys. Finally, Roy expressed the desire for a panic button that would enable the automatic transfer of all coins to new addresses in case of an accidental mistake like typing the passphrase into an IRC window. The Bitcoin community showed interest in developing this functionality within the official client, but determining the exact desired functionality was considered the initial step. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Large-blocks-and-censorship.xml b/static/bitcoin-dev/March_2013/combined_Large-blocks-and-censorship.xml index 912b6cca52..bad94391da 100644 --- a/static/bitcoin-dev/March_2013/combined_Large-blocks-and-censorship.xml +++ b/static/bitcoin-dev/March_2013/combined_Large-blocks-and-censorship.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Large-blocks and censorship - 2023-08-01T04:28:32.414169+00:00 + 2025-10-11T21:28:38.748452+00:00 + python-feedgen Peter Todd 2013-03-10 08:18:57+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Large-blocks and censorship - 2023-08-01T04:28:32.414169+00:00 + 2025-10-11T21:28:38.748610+00:00 - In this email conversation, Daniel Lidstrom discusses the importance of censorship resistance in Bitcoin as it scales. He emphasizes the need to preserve privacy when using Bitcoin to avoid being censored by miners. This can be achieved through anonymous connections, not reusing addresses, and mixing coins. Lidstrom believes that privacy preservation should become automatic in the future.He argues that anonymity systems should scale to accommodate Bitcoin full nodes, rather than Bitcoin staying small to avoid putting pressure on anonymity systems. If anonymity systems don't scale enough, mining in a pool is an option. There will always be countries that allow mining pools to operate, and miners in countries that ban Bitcoin can connect to these pools anonymously.However, centralized validating nodes and mining pools present a challenge for avoiding censorship. Lidstrom states that there aren't any clever technical ways to avoid censorship if these entities are centralized. He also mentions a paper on integrating Chaum-style privacy with Bitcoin using zero knowledge proofs, but notes that it is too slow and complicated to integrate practically.The conversation also touches on the argument that large blocks make it easier for authorities to censor transactions. The author suggests analyzing block sizes based on improving technology while considering the impact on censorship resistance. Despite concerns about censorship, a high number of validating nodes in Bitcoin makes discouraging unwanted traffic difficult, indicating strong censorship resistance.Another point raised is the vulnerability of auditable off-chain transaction systems. Trustworthy systems require some on-chain transactions to be publicly known for auditing purposes. However, censorship is still possible, as miners choose what transactions to accept into blocks. Transaction volumes make running a validating node more expensive, leading to decreased independent pools. Small blocks, on the other hand, allow for lower barriers to entry for miners and the possibility of mining anonymously behind anti-censorship technologies like Tor.Overall, the conversation highlights the challenges and potential solutions for maintaining censorship resistance as Bitcoin scales. Privacy preservation, scalability of anonymity systems, and the role of validating nodes and mining pools are key considerations in this regard. 2013-03-10T08:18:57+00:00 + In this email conversation, Daniel Lidstrom discusses the importance of censorship resistance in Bitcoin as it scales. He emphasizes the need to preserve privacy when using Bitcoin to avoid being censored by miners. This can be achieved through anonymous connections, not reusing addresses, and mixing coins. Lidstrom believes that privacy preservation should become automatic in the future.He argues that anonymity systems should scale to accommodate Bitcoin full nodes, rather than Bitcoin staying small to avoid putting pressure on anonymity systems. If anonymity systems don't scale enough, mining in a pool is an option. There will always be countries that allow mining pools to operate, and miners in countries that ban Bitcoin can connect to these pools anonymously.However, centralized validating nodes and mining pools present a challenge for avoiding censorship. Lidstrom states that there aren't any clever technical ways to avoid censorship if these entities are centralized. He also mentions a paper on integrating Chaum-style privacy with Bitcoin using zero knowledge proofs, but notes that it is too slow and complicated to integrate practically.The conversation also touches on the argument that large blocks make it easier for authorities to censor transactions. The author suggests analyzing block sizes based on improving technology while considering the impact on censorship resistance. Despite concerns about censorship, a high number of validating nodes in Bitcoin makes discouraging unwanted traffic difficult, indicating strong censorship resistance.Another point raised is the vulnerability of auditable off-chain transaction systems. Trustworthy systems require some on-chain transactions to be publicly known for auditing purposes. However, censorship is still possible, as miners choose what transactions to accept into blocks. Transaction volumes make running a validating node more expensive, leading to decreased independent pools. Small blocks, on the other hand, allow for lower barriers to entry for miners and the possibility of mining anonymously behind anti-censorship technologies like Tor.Overall, the conversation highlights the challenges and potential solutions for maintaining censorship resistance as Bitcoin scales. Privacy preservation, scalability of anonymity systems, and the role of validating nodes and mining pools are key considerations in this regard. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Ok-to-use-0-8-x-.xml b/static/bitcoin-dev/March_2013/combined_Ok-to-use-0-8-x-.xml index 70203bfb68..7cca5e4d85 100644 --- a/static/bitcoin-dev/March_2013/combined_Ok-to-use-0-8-x-.xml +++ b/static/bitcoin-dev/March_2013/combined_Ok-to-use-0-8-x-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ok to use 0.8.x? - 2023-08-01T04:34:03.458813+00:00 + 2025-10-11T21:28:36.624833+00:00 + python-feedgen Peter Todd 2013-03-16 22:17:09+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Ok to use 0.8.x? - 2023-08-01T04:34:03.458813+00:00 + 2025-10-11T21:28:36.625030+00:00 - Bitcoin version 0.8.0 is considered safe for use in all activities except block creation. This means that the update is available for everyone, except for solo miners and pool operators. However, even they can use it if they connect to the network through a 0.7 node. Despite this limitation, users are encouraged to use the latest version of Bitcoin as it only affects block creation. For those who are not solo miners or pool operators, using version 0.8.x is a viable option as it allows for transactions and queries to be conducted without any issues. It is expected that the issue with block creation will be resolved within a couple of weeks. In the meantime, it is anticipated that the softcode used by ASIC and FPGA miners, as well as pure softminers (GPU), will be updated accordingly.Overall, while there are some limitations to using Bitcoin version 0.8.0, it remains a safe and reliable option for most users. As always, it is recommended to stay up-to-date with the latest versions and updates to ensure optimal performance and security.It is important to note that Bitcoin version 0.8.0 is safe for all users except for those who are involved in creating blocks, such as solo miners or pool operators. However, even these users can still use the software if they connect to the network through a 0.7 node. It is important to stay informed and make sure you are using the most secure and up-to-date version for your needs. Bitcoin version 0.8.0 is considered safe for most users, but not for those who are creating blocks such as solo miners and pool operators. This statement was made by Gavin Andresen, a prominent figure in the Bitcoin community. It is important to note that this version of Bitcoin is not completely secure for everyone and caution should still be taken when using it.For those who are unfamiliar with Bitcoin, it is a decentralized digital currency that operates without a central bank or administrator. Transactions are verified by network nodes through cryptography and recorded on a public ledger called a blockchain. Bitcoin version 0.8.0 is an older version of the software used to participate in the Bitcoin network.Despite its age, this version of Bitcoin is still widely used and has been deemed safe for most individuals. However, it is important to keep in mind that any software can have vulnerabilities and users should always exercise caution when transacting with Bitcoin.If you're doing a new install and connecting to the internet for the first time, it's important to consider whether 0.8.x is safe to use for all or select purposes in regard to the current fork issue. If not, there may be a recommended branch, tag, or commit to use until an upgrade alert is broadcasted. However, it should be noted that there are only 'branch master' and 'tag v0.8.0' available on the Bitcoin GitHub page regarding possible 0.8.x flavors. There are currently no 0.8.x branches or tags available on the Bitcoin Gitorious page. It's important to stay informed and make sure you are using the most secure and up-to-date version for your needs.In conclusion, while Bitcoin version 0.8.0 is generally considered safe for most users, those who are creating blocks such as solo miners and pool operators should use caution when using this version of the software. As with all software, it is important to stay up-to-date with the latest security patches and updates to ensure the highest level of security possible. 2013-03-16T22:17:09+00:00 + Bitcoin version 0.8.0 is considered safe for use in all activities except block creation. This means that the update is available for everyone, except for solo miners and pool operators. However, even they can use it if they connect to the network through a 0.7 node. Despite this limitation, users are encouraged to use the latest version of Bitcoin as it only affects block creation. For those who are not solo miners or pool operators, using version 0.8.x is a viable option as it allows for transactions and queries to be conducted without any issues. It is expected that the issue with block creation will be resolved within a couple of weeks. In the meantime, it is anticipated that the softcode used by ASIC and FPGA miners, as well as pure softminers (GPU), will be updated accordingly.Overall, while there are some limitations to using Bitcoin version 0.8.0, it remains a safe and reliable option for most users. As always, it is recommended to stay up-to-date with the latest versions and updates to ensure optimal performance and security.It is important to note that Bitcoin version 0.8.0 is safe for all users except for those who are involved in creating blocks, such as solo miners or pool operators. However, even these users can still use the software if they connect to the network through a 0.7 node. It is important to stay informed and make sure you are using the most secure and up-to-date version for your needs. Bitcoin version 0.8.0 is considered safe for most users, but not for those who are creating blocks such as solo miners and pool operators. This statement was made by Gavin Andresen, a prominent figure in the Bitcoin community. It is important to note that this version of Bitcoin is not completely secure for everyone and caution should still be taken when using it.For those who are unfamiliar with Bitcoin, it is a decentralized digital currency that operates without a central bank or administrator. Transactions are verified by network nodes through cryptography and recorded on a public ledger called a blockchain. Bitcoin version 0.8.0 is an older version of the software used to participate in the Bitcoin network.Despite its age, this version of Bitcoin is still widely used and has been deemed safe for most individuals. However, it is important to keep in mind that any software can have vulnerabilities and users should always exercise caution when transacting with Bitcoin.If you're doing a new install and connecting to the internet for the first time, it's important to consider whether 0.8.x is safe to use for all or select purposes in regard to the current fork issue. If not, there may be a recommended branch, tag, or commit to use until an upgrade alert is broadcasted. However, it should be noted that there are only 'branch master' and 'tag v0.8.0' available on the Bitcoin GitHub page regarding possible 0.8.x flavors. There are currently no 0.8.x branches or tags available on the Bitcoin Gitorious page. It's important to stay informed and make sure you are using the most secure and up-to-date version for your needs.In conclusion, while Bitcoin version 0.8.0 is generally considered safe for most users, those who are creating blocks such as solo miners and pool operators should use caution when using this version of the software. As with all software, it is important to stay up-to-date with the latest security patches and updates to ensure the highest level of security possible. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Secure-download.xml b/static/bitcoin-dev/March_2013/combined_Secure-download.xml index 86b306bde0..a75a1fce6d 100644 --- a/static/bitcoin-dev/March_2013/combined_Secure-download.xml +++ b/static/bitcoin-dev/March_2013/combined_Secure-download.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Secure download - 2023-08-01T04:28:16.565440+00:00 + 2025-10-11T21:28:28.111050+00:00 + python-feedgen Roy Badami 2013-03-05 12:37:50+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Secure download - 2023-08-01T04:28:16.565440+00:00 + 2025-10-11T21:28:28.111221+00:00 - Gavin Andresen, a prominent member of the Bitcoin community, has provided his gpg key on the Bitcoin.org homepage to ensure secure access. This key can be accessed securely through various methods, including a link to its history on GitHub and fetching it from the MIT pgp keyserver or bitcointalk forums archives. Users can verify their download checksums by importing the key into pgp/gpg and using the command 'gpg --verify SHA256SUMS.asc'. Windows and OSX users can automatically check for integrity as the latest downloads are code-signed.The context also mentions the use of PGP Public Key Blocks, which contain encrypted information for sending secure messages and files. The block includes metadata such as expiration date, creation date, and email address of the user it belongs to. PGP is widely used for encryption and provides privacy and authentication for data communication. The PGP Public Key Block provided in the context can be used by someone who wishes to send a message or file securely to the user associated with the email address listed in the block.In terms of downloading Bitcoin software securely, Chris, a newbie in the world of cryptocurrency, seeks advice on verifying SHA256 hashes and finding signatures and signing keys. He can verify SHA256 hashes by using a checksum tool to compare the hash value of the downloaded file with the original hash value provided by the developer. GPG can be used to authenticate signatures and signing keys, which can be found on the official website of the Bitcoin software or on various trusted websites.Chris also asks about the possibility of read-only ssh/sftp/scp access for transferring files securely and remotely. However, it may not be applicable for downloading Bitcoin software directly. Therefore, he should follow the above-mentioned steps to ensure the safety of the downloaded files.Overall, it is important for individuals like Chris to take necessary precautions before downloading anything related to cryptocurrency. By verifying SHA256 hashes and using GPG authentication, the risk of downloading malicious software can be minimized, ensuring the safety of investments. 2013-03-05T12:37:50+00:00 + Gavin Andresen, a prominent member of the Bitcoin community, has provided his gpg key on the Bitcoin.org homepage to ensure secure access. This key can be accessed securely through various methods, including a link to its history on GitHub and fetching it from the MIT pgp keyserver or bitcointalk forums archives. Users can verify their download checksums by importing the key into pgp/gpg and using the command 'gpg --verify SHA256SUMS.asc'. Windows and OSX users can automatically check for integrity as the latest downloads are code-signed.The context also mentions the use of PGP Public Key Blocks, which contain encrypted information for sending secure messages and files. The block includes metadata such as expiration date, creation date, and email address of the user it belongs to. PGP is widely used for encryption and provides privacy and authentication for data communication. The PGP Public Key Block provided in the context can be used by someone who wishes to send a message or file securely to the user associated with the email address listed in the block.In terms of downloading Bitcoin software securely, Chris, a newbie in the world of cryptocurrency, seeks advice on verifying SHA256 hashes and finding signatures and signing keys. He can verify SHA256 hashes by using a checksum tool to compare the hash value of the downloaded file with the original hash value provided by the developer. GPG can be used to authenticate signatures and signing keys, which can be found on the official website of the Bitcoin software or on various trusted websites.Chris also asks about the possibility of read-only ssh/sftp/scp access for transferring files securely and remotely. However, it may not be applicable for downloading Bitcoin software directly. Therefore, he should follow the above-mentioned steps to ensure the safety of the downloaded files.Overall, it is important for individuals like Chris to take necessary precautions before downloading anything related to cryptocurrency. By verifying SHA256 hashes and using GPG authentication, the risk of downloading malicious software can be minimized, ensuring the safety of investments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Some-PR-preparation.xml b/static/bitcoin-dev/March_2013/combined_Some-PR-preparation.xml index 7115ce129b..d6618b54b2 100644 --- a/static/bitcoin-dev/March_2013/combined_Some-PR-preparation.xml +++ b/static/bitcoin-dev/March_2013/combined_Some-PR-preparation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Some PR preparation - 2023-08-01T04:31:51.724187+00:00 + 2025-10-11T21:28:45.131211+00:00 + python-feedgen Peter Vessenes 2013-03-12 20:09:17+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Some PR preparation - 2023-08-01T04:31:51.724187+00:00 + 2025-10-11T21:28:45.131393+00:00 - Christian Decker, a Bitcoin developer, reported that out of 430 transactions confirmed in the alt-chain, only seven transactions were true double spends. The conflicting transactions were confirmed with their respective amounts: 261 BTC, 0.06 BTC, 0.01 BTC, 0.05 BTC, 0.61 BTC, 1.62 BTC, and 0.81 BTC. The one transaction that caused the most damage was published on BitcoinTalk. Although some of the 423 transactions still have a chance of being doublespent, the situation is not as bad as initially feared. It is essential to confirm that no one has been ripped off, even though there might have been attempts. For a complete list of transactions, see http://pastebin.com/wctJU3Ln.In a post on the BitcoinTalk forum in March 2013, user Peter Vessenes asked if anyone had determined if there were any double-spend attempts related to the recent blockchain fork that occurred. Gregory Maxwell responded and agreed that it would be good to confirm that no one was ripped off, even though they couldn't say for certain that there weren't any attempts. It is unclear from this context whether any further action was taken to investigate possible double-spends.In an email conversation, Alan Reiner asked about the risks involved in a rejected block while transactions remained unaffected. A flood of duplicate transactions announcing both spends to multiple nodes could cause conflicts in both chains, which would eventually result in one chain being popped and transactions being undone for anyone on that side. This attack would not require any particular resources and only enough technical sophistication to run something like pynode to give raw txn to nodes at random. However, interest in attacking and lack of good targets who hadn't shut down their deposits were major barriers. In response to a query by someone regarding double-spend attempts, it was confirmed that there were circulating double-spends during the fork as visible on blockchain.info. It is unknown whether any conflicts made it into the losing chain. Checking consumed inputs in the losing fork can determine if any have been consumed by different transactions now. Even though no one knows if there weren't any attempts, it would be good to confirm that no one was ripped off.The discussion revolves around the possibility of any double-spend attempts during a recent Bitcoin test. Some individuals believe that it is unlikely that such an attempt was made, while others argue that the risk was real and should not be downplayed. Despite this, many people agree that the test was successful and credit goes to everyone who contributed to it. One participant in the discussion suggests that contacting larger payment processors might be necessary, as some individuals could have been scammed even with standard precautions. However, others argue that the risk was minimal, as executing a double-spend would require an exceptional amount of resources way outside the scope of regular users. In conclusion, the discussion highlights the importance of thorough testing and the need to address potential risks to ensure the safety and security of Bitcoin transactions.In an email exchange, Luke-Jr expressed concern about the risk of double-spending during a brief period when transactions could have received up to N confirmations and then still been reversed. There was a possibility that people trying to buy/sell on OTC could have been scammed even by taking standard precautions. However, another participant in the exchange argued that the risk was not as great as it appeared because any valid transactions hitting the network would get added to everyone's memory pool and mined in both chains. Thus all nodes would still reject double-spend attempts. Majority mining power on one of the chains was required, and both had non-negligible computing power on them, so double-spending still required an exceptional amount of resources, just not the normal 50% that is normally needed. It required at least 10%, which limited the number of potential attackers. In addition, a victim needed to be found that hadn't seen the alert, was willing to execute a large transaction, and was on the wrong side of the chain. This made the attack outside the scope of regular users.On March 12, 2013, Alan Reiner expressed concern about the potential negative attention that could arise from an event involving Bitcoin. He believed it was important to prepare PR comments in advance to combat any inaccurate or exaggerated reporting. Reiner emphasized that the event was a short and harmless lapse in network consensus that caused transaction delays rather than a threat to the safety of coins. However, Luke cautioned against downplaying the reality of the situation as transactions could have been reversed and scams were still possible even with standard precautions. The event received media attention due to Bitcoin's rising popularity at the time.Bitcoin suffered a short and harmless lapse that caused transaction delays of a few hours due to a bug that was fixed. The coins are safe, and it would have been difficult to exploit the incident for gain. It is important to emphasize this fact to counteract negative attention 2013-03-12T20:09:17+00:00 + Christian Decker, a Bitcoin developer, reported that out of 430 transactions confirmed in the alt-chain, only seven transactions were true double spends. The conflicting transactions were confirmed with their respective amounts: 261 BTC, 0.06 BTC, 0.01 BTC, 0.05 BTC, 0.61 BTC, 1.62 BTC, and 0.81 BTC. The one transaction that caused the most damage was published on BitcoinTalk. Although some of the 423 transactions still have a chance of being doublespent, the situation is not as bad as initially feared. It is essential to confirm that no one has been ripped off, even though there might have been attempts. For a complete list of transactions, see http://pastebin.com/wctJU3Ln.In a post on the BitcoinTalk forum in March 2013, user Peter Vessenes asked if anyone had determined if there were any double-spend attempts related to the recent blockchain fork that occurred. Gregory Maxwell responded and agreed that it would be good to confirm that no one was ripped off, even though they couldn't say for certain that there weren't any attempts. It is unclear from this context whether any further action was taken to investigate possible double-spends.In an email conversation, Alan Reiner asked about the risks involved in a rejected block while transactions remained unaffected. A flood of duplicate transactions announcing both spends to multiple nodes could cause conflicts in both chains, which would eventually result in one chain being popped and transactions being undone for anyone on that side. This attack would not require any particular resources and only enough technical sophistication to run something like pynode to give raw txn to nodes at random. However, interest in attacking and lack of good targets who hadn't shut down their deposits were major barriers. In response to a query by someone regarding double-spend attempts, it was confirmed that there were circulating double-spends during the fork as visible on blockchain.info. It is unknown whether any conflicts made it into the losing chain. Checking consumed inputs in the losing fork can determine if any have been consumed by different transactions now. Even though no one knows if there weren't any attempts, it would be good to confirm that no one was ripped off.The discussion revolves around the possibility of any double-spend attempts during a recent Bitcoin test. Some individuals believe that it is unlikely that such an attempt was made, while others argue that the risk was real and should not be downplayed. Despite this, many people agree that the test was successful and credit goes to everyone who contributed to it. One participant in the discussion suggests that contacting larger payment processors might be necessary, as some individuals could have been scammed even with standard precautions. However, others argue that the risk was minimal, as executing a double-spend would require an exceptional amount of resources way outside the scope of regular users. In conclusion, the discussion highlights the importance of thorough testing and the need to address potential risks to ensure the safety and security of Bitcoin transactions.In an email exchange, Luke-Jr expressed concern about the risk of double-spending during a brief period when transactions could have received up to N confirmations and then still been reversed. There was a possibility that people trying to buy/sell on OTC could have been scammed even by taking standard precautions. However, another participant in the exchange argued that the risk was not as great as it appeared because any valid transactions hitting the network would get added to everyone's memory pool and mined in both chains. Thus all nodes would still reject double-spend attempts. Majority mining power on one of the chains was required, and both had non-negligible computing power on them, so double-spending still required an exceptional amount of resources, just not the normal 50% that is normally needed. It required at least 10%, which limited the number of potential attackers. In addition, a victim needed to be found that hadn't seen the alert, was willing to execute a large transaction, and was on the wrong side of the chain. This made the attack outside the scope of regular users.On March 12, 2013, Alan Reiner expressed concern about the potential negative attention that could arise from an event involving Bitcoin. He believed it was important to prepare PR comments in advance to combat any inaccurate or exaggerated reporting. Reiner emphasized that the event was a short and harmless lapse in network consensus that caused transaction delays rather than a threat to the safety of coins. However, Luke cautioned against downplaying the reality of the situation as transactions could have been reversed and scams were still possible even with standard precautions. The event received media attention due to Bitcoin's rising popularity at the time.Bitcoin suffered a short and harmless lapse that caused transaction delays of a few hours due to a bug that was fixed. The coins are safe, and it would have been difficult to exploit the incident for gain. It is important to emphasize this fact to counteract negative attention - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Upcoming-network-event-block-v2-lock-in.xml b/static/bitcoin-dev/March_2013/combined_Upcoming-network-event-block-v2-lock-in.xml index 4415e9a9cd..98f0e346e4 100644 --- a/static/bitcoin-dev/March_2013/combined_Upcoming-network-event-block-v2-lock-in.xml +++ b/static/bitcoin-dev/March_2013/combined_Upcoming-network-event-block-v2-lock-in.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Upcoming network event: block v2 lock-in - 2023-08-01T04:35:07.259391+00:00 + 2025-10-11T21:28:43.000932+00:00 + python-feedgen Gregory Maxwell 2013-03-23 19:18:03+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Upcoming network event: block v2 lock-in - 2023-08-01T04:35:07.259391+00:00 + 2025-10-11T21:28:43.001122+00:00 - In a discussion between Jeff Garzik and Luke-Jr on March 23, 2013, they debated the role of Bitcoind in relation to BIP34's implementation. While Luke-Jr argued that Bitcoind was not relevant for producing coinbases, Jeff Garzik pointed out that it played a role in supplying the block version and selecting transactions for miners. Both parties agreed that upgrading Bitcoind alone would prevent the creation of forks.Luke-Jr stated in an email conversation that Bitcoind was not involved in the implementation of the miner end of BIP34. However, Jeff Garzik disagreed, explaining that Bitcoind's 'getblocktemplate' RPC call is used by some miners. He mentioned that several pools, including slush, BTC Guild, and ozcoin, were using Bitcoind 0.7 or later for mining.Jeff Garzik announced that the Bitcoin network would undergo a fork to version 2 due to issues with version 1. He assured users that they should not be impacted and encouraged miners to use a recent Bitcoind version (0.7 or later) to mine. However, some ancient miners would produce newly-invalid blocks that would be ignored.In response to Garzik's announcement, one individual stated that they were not aware of anyone mining using Bitcoind 0.7 or later, except for Deepbit which used an older version. However, other open-source pool servers had already supported v2 blocks for months. It was noted that PoolServerJ and ecoinpool had issues with v2 blocks.It was mentioned that once a supermajority of mining reached block version 2 (95%), blocks with nVersion==1 would be rejected. The Version 2 block specification is available on the Bitcoin wiki page for BIP 0034. Users should not be affected by this change, but older miners may produce newly-invalid blocks that get ignored. Upgrading to a recent Bitcoind version is the recommended solution for miners, and assistance can be sought through #bitcoin-dev or bitcoin-development at lists.sourceforge.net. 2013-03-23T19:18:03+00:00 + In a discussion between Jeff Garzik and Luke-Jr on March 23, 2013, they debated the role of Bitcoind in relation to BIP34's implementation. While Luke-Jr argued that Bitcoind was not relevant for producing coinbases, Jeff Garzik pointed out that it played a role in supplying the block version and selecting transactions for miners. Both parties agreed that upgrading Bitcoind alone would prevent the creation of forks.Luke-Jr stated in an email conversation that Bitcoind was not involved in the implementation of the miner end of BIP34. However, Jeff Garzik disagreed, explaining that Bitcoind's 'getblocktemplate' RPC call is used by some miners. He mentioned that several pools, including slush, BTC Guild, and ozcoin, were using Bitcoind 0.7 or later for mining.Jeff Garzik announced that the Bitcoin network would undergo a fork to version 2 due to issues with version 1. He assured users that they should not be impacted and encouraged miners to use a recent Bitcoind version (0.7 or later) to mine. However, some ancient miners would produce newly-invalid blocks that would be ignored.In response to Garzik's announcement, one individual stated that they were not aware of anyone mining using Bitcoind 0.7 or later, except for Deepbit which used an older version. However, other open-source pool servers had already supported v2 blocks for months. It was noted that PoolServerJ and ecoinpool had issues with v2 blocks.It was mentioned that once a supermajority of mining reached block version 2 (95%), blocks with nVersion==1 would be rejected. The Version 2 block specification is available on the Bitcoin wiki page for BIP 0034. Users should not be affected by this change, but older miners may produce newly-invalid blocks that get ignored. Upgrading to a recent Bitcoind version is the recommended solution for miners, and assistance can be sought through #bitcoin-dev or bitcoin-development at lists.sourceforge.net. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2013/combined_Warning-many-0-7-nodes-break-on-large-number-of-tx-block-fork-risk.xml b/static/bitcoin-dev/March_2013/combined_Warning-many-0-7-nodes-break-on-large-number-of-tx-block-fork-risk.xml index 52f2679ebc..047ab591f1 100644 --- a/static/bitcoin-dev/March_2013/combined_Warning-many-0-7-nodes-break-on-large-number-of-tx-block-fork-risk.xml +++ b/static/bitcoin-dev/March_2013/combined_Warning-many-0-7-nodes-break-on-large-number-of-tx-block-fork-risk.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Warning: many 0.7 nodes break on large number of tx/block; fork risk - 2023-08-01T04:31:15.699967+00:00 + 2025-10-11T21:28:25.985746+00:00 + python-feedgen Michael Gronager 2013-03-12 13:00:13+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Warning: many 0.7 nodes break on large number of tx/block; fork risk - 2023-08-01T04:31:15.699967+00:00 + 2025-10-11T21:28:25.985993+00:00 - The context discusses the issue of lock exhaustion in BDB on certain nodes, leading to a buildup of transactions in the memory pool and potential failures. Two alternatives are proposed to address this issue: blocking or down-prioritizing specific transactions at the network level or implementing a crash hard fork to remove the 1mb limit. Pieter Wuille identifies a problem with lock entries in the BDB database that caused nodes running version 0.7 to get stuck around block 225430. Miners are advised to revert back to version 0.7 until the majority of mining power is on the old chain, and merchants using version 0.8 are advised to halt transaction processing until both sides have switched to the same chain. Upgrading to version 0.8 or adjusting the number of lock objects in the database are suggested as immediate solutions.On March 12th, 2013, Pieter Wuille posts about a fork caused by a specific block. It is decided to switch the majority of mining power back to the "old" chain accepted by version 0.7 nodes. Miners are advised to revert to version 0.7 until the cause of the issue is better understood, and merchants on version 0.8 are advised to stop processing transactions until both sides have switched to the same chain. Many reports of version 0.7 nodes getting stuck are due to running out of lock entries in the BDB database. Immediate solutions include upgrading to version 0.8 or adjusting the number of lock objects in the database. There is a risk of multiple forked chains being accepted by version 0.7 nodes, creating an emergency situation. People are asked to contact pool operators to determine which fork they are on, and those unsure are advised to stop processing transactions. Blockexplorer and blockchain.info are also experiencing issues.In summary, the context highlights the problems caused by lock exhaustion in BDB on certain nodes, the suggestion of blocking or down-prioritizing transactions, and the need for a crash hard fork. Pieter Wuille addresses the issue with lock entries in the BDB database and provides guidance to miners and merchants on how to navigate the situation. It is crucial to upgrade to version 0.8 or adjust lock objects in the database, contact pool operators to determine the fork, and halt transaction processing if uncertain. 2013-03-12T13:00:13+00:00 + The context discusses the issue of lock exhaustion in BDB on certain nodes, leading to a buildup of transactions in the memory pool and potential failures. Two alternatives are proposed to address this issue: blocking or down-prioritizing specific transactions at the network level or implementing a crash hard fork to remove the 1mb limit. Pieter Wuille identifies a problem with lock entries in the BDB database that caused nodes running version 0.7 to get stuck around block 225430. Miners are advised to revert back to version 0.7 until the majority of mining power is on the old chain, and merchants using version 0.8 are advised to halt transaction processing until both sides have switched to the same chain. Upgrading to version 0.8 or adjusting the number of lock objects in the database are suggested as immediate solutions.On March 12th, 2013, Pieter Wuille posts about a fork caused by a specific block. It is decided to switch the majority of mining power back to the "old" chain accepted by version 0.7 nodes. Miners are advised to revert to version 0.7 until the cause of the issue is better understood, and merchants on version 0.8 are advised to stop processing transactions until both sides have switched to the same chain. Many reports of version 0.7 nodes getting stuck are due to running out of lock entries in the BDB database. Immediate solutions include upgrading to version 0.8 or adjusting the number of lock objects in the database. There is a risk of multiple forked chains being accepted by version 0.7 nodes, creating an emergency situation. People are asked to contact pool operators to determine which fork they are on, and those unsure are advised to stop processing transactions. Blockexplorer and blockchain.info are also experiencing issues.In summary, the context highlights the problems caused by lock exhaustion in BDB on certain nodes, the suggestion of blocking or down-prioritizing transactions, and the need for a crash hard fork. Pieter Wuille addresses the issue with lock entries in the BDB database and provides guidance to miners and merchants on how to navigate the situation. It is crucial to upgrade to version 0.8 or adjust lock objects in the database, contact pool operators to determine the fork, and halt transaction processing if uncertain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_-QT-how-to-disable-block-verification-for-faster-UI-testing-.xml b/static/bitcoin-dev/March_2014/combined_-QT-how-to-disable-block-verification-for-faster-UI-testing-.xml index 025e502915..e9181816f2 100644 --- a/static/bitcoin-dev/March_2014/combined_-QT-how-to-disable-block-verification-for-faster-UI-testing-.xml +++ b/static/bitcoin-dev/March_2014/combined_-QT-how-to-disable-block-verification-for-faster-UI-testing-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [QT] how to disable block verification for faster UI testing? - 2023-08-01T07:59:18.765588+00:00 + 2025-10-11T21:34:52.875709+00:00 + python-feedgen Angel Leon 2014-03-19 18:36:31+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [QT] how to disable block verification for faster UI testing? - 2023-08-01T07:59:18.765588+00:00 + 2025-10-11T21:34:52.875855+00:00 - In an email conversation between Angel Leon and Wladimir, the issue of database corruption while developing the UI for Bitcoin-Qt was discussed. Angel mentioned that when he opens the official binary, there is a database corruption problem which leads to the need for reindexing blocks on disk, a process that can take up to a day. Wladimir suggested a solution by using separate Bitcoin data directories and making copies before performing risky actions. He also recommended using the -regtest option to quickly set up test scenarios. He cautioned against switching between 0.8.x and 0.9.x versions with the same directory as it may cause database problems. To support his point, Wladimir provided a link to the downgrading warning in the README.txt file located at https://bitcoin.org/bin/0.9.0/README.txt.Angel clarified that he was not testing anything specific, but rather coding, building, and launching repeatedly. He expressed a desire to make the startup of the Qt client faster. Angel's Twitter handle, @gubatron, was mentioned at the end of the conversation.In summary, the conversation revolved around the issue of database corruption while developing the UI for Bitcoin-Qt. Wladimir suggested using separate Bitcoin data directories, making copies, and using the -regtest option for testing scenarios. He also warned against switching between different versions with the same directory. Angel, who was not testing anything specific, wanted to improve the startup speed of the Qt client. The context was posted by Angel on Twitter at @gubatron. 2014-03-19T18:36:31+00:00 + In an email conversation between Angel Leon and Wladimir, the issue of database corruption while developing the UI for Bitcoin-Qt was discussed. Angel mentioned that when he opens the official binary, there is a database corruption problem which leads to the need for reindexing blocks on disk, a process that can take up to a day. Wladimir suggested a solution by using separate Bitcoin data directories and making copies before performing risky actions. He also recommended using the -regtest option to quickly set up test scenarios. He cautioned against switching between 0.8.x and 0.9.x versions with the same directory as it may cause database problems. To support his point, Wladimir provided a link to the downgrading warning in the README.txt file located at https://bitcoin.org/bin/0.9.0/README.txt.Angel clarified that he was not testing anything specific, but rather coding, building, and launching repeatedly. He expressed a desire to make the startup of the Qt client faster. Angel's Twitter handle, @gubatron, was mentioned at the end of the conversation.In summary, the conversation revolved around the issue of database corruption while developing the UI for Bitcoin-Qt. Wladimir suggested using separate Bitcoin data directories, making copies, and using the -regtest option for testing scenarios. He also warned against switching between different versions with the same directory. Angel, who was not testing anything specific, wanted to improve the startup speed of the Qt client. The context was posted by Angel on Twitter at @gubatron. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-root-key-with-optional-encryption.xml b/static/bitcoin-dev/March_2014/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-root-key-with-optional-encryption.xml index 0e5055d4b5..67efb009f1 100644 --- a/static/bitcoin-dev/March_2014/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-root-key-with-optional-encryption.xml +++ b/static/bitcoin-dev/March_2014/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-root-key-with-optional-encryption.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption - 2023-08-01T07:55:43.899157+00:00 + 2025-10-11T21:34:23.133110+00:00 + python-feedgen William Yager 2014-04-24 19:39:52+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption - 2023-08-01T07:55:43.900240+00:00 + 2025-10-11T21:34:23.133279+00:00 - The Bitcoin community has updated its specification to include front-loading all the key pre-stretching, as suggested by Gmaxwell. This update is designed to allow more powerful devices like laptops and mobile phones to handle the key-stretching process on their own, while weaker devices can outsource it to more capable devices. The updated spec includes a minimum of 8192 rounds of salted PBKDF2-HMAC-SHA512 for password protection, even when key-stretching is outsourced. The spec has been updated to remove the Scrypt dependency and add new key derivation functions and plausible deniability.There are concerns about potential password cracking if StrongH calculation is outsourced, but it is emphasized that the key material would still remain safe even if the password is exposed. Adjustments can be made to make password recovery more expensive if users are concerned about this vulnerability.The feasibility of using PBKDF2-HMAC-SHA512 for encryption in storage wallets is discussed. It is noted that this method is easy to implement on devices with limited RAM and can run at reasonable speeds on slow processors. Even if it takes several minutes to encrypt/decrypt, it is considered acceptable for one-time activities such as printing a cold wallet or importing an encrypted wallet into a phone. The deterministic time it takes allows for the addition of a progress bar to the user interface.The idea of using semi-trusted devices, like desktop PCs, for key stretching work in wallets is proposed. Concerns are raised about the security implications if a compromised computer is involved in the process. However, a compromise is reached with the inclusion of PBKDF2-HMAC-SHA512 based KDFs, which can run on memory-constrained devices and slow processors while still providing sufficient security.A bloom filter is proposed for typo checking and plausible deniability in a BIP. It is optimized for two elements and catches 99.9975% of typos while allowing for two different passwords. However, it is noted that this doesn't qualify as true plausible deniability as there are always at least two passwords. The conversation also covers the outsourcing of the KDF and the importance of using the specified algorithms to maintain compatibility.Discussions also touch on the integration of the BIP39 word list into Bitcoinj, timestamping and checksums, entropy length options, cross-wallet compatibility, and the benefits of a new specification over BIP 0038 and BIP 0039. It is suggested that BIP 0039 should not limit improvements on BIP 0038. The email thread concludes with links to a book on graph databases and the Bitcoin-development mailing list.In an email exchange, Jean-Paul Kogelman compared his proposal to BIP 39, highlighting the differences between the two. BIP 39 offers a list of words instead of using case-sensitive letters and numbers. It also supports different lengths of entropy, contrary to the belief that it only supports 12 words. Additionally, BIP 39 lacks a genesis date field, password typo detection, user-selectable KDF, and encourages the use of custom word lists.Kogelman announced updates to his spec, including removing Scrypt dependency, adding new KDFs, and plausible deniability. Pavol Rusnak mentioned BIP-0039, which offers an easy list of words, fixed length of entropy, no genesis date field, lack of password typo detection, no user-selectable KDF, inability to outsource KDF computation, and allows implementers to use their own word lists.On December 3rd, 2014, Kogelman shared the updates made in the spec, incorporating the requested features and removing Scrypt dependency. He also mentioned BIP-0039 as a related Bitcoin Improvement Proposal and provided a link to it.Kogelman proposed a method for encoding and encrypting Bitcoin HD Wallet root keys. The proposal includes encoding methodologies, encrypted and unencrypted wallet prefixes, verification information, salting, user-selectable KDF, second password option for plausible deniability, and prefix changes for alt-chains. The proposal provides KDF functions, date field for faster blockchain transaction search, derivation of master key from root key using SHA512, password encryption steps, bloom filter creation and verification methods, Python reference implementation, and test vectors.The context includes a list of public addresses, private extended keys, public extended keys, encrypted values, and creation dates for various test scenarios. Each scenario has different information such as root key, clear key, password, second password, associated public addresses, private extended keys, and public extended keys. Tests were conducted to generate multiple keys and public addresses using different KDFs, some with additional password encryption.The proposal includes updated wording, computation changes using PBKDF2-HMAC-SHA512, moving the KDF field, adding plausible deniability, new KDFs, entropy field in encrypted version, checksum field renamed to bloom field 2014-04-24T19:39:52+00:00 + The Bitcoin community has updated its specification to include front-loading all the key pre-stretching, as suggested by Gmaxwell. This update is designed to allow more powerful devices like laptops and mobile phones to handle the key-stretching process on their own, while weaker devices can outsource it to more capable devices. The updated spec includes a minimum of 8192 rounds of salted PBKDF2-HMAC-SHA512 for password protection, even when key-stretching is outsourced. The spec has been updated to remove the Scrypt dependency and add new key derivation functions and plausible deniability.There are concerns about potential password cracking if StrongH calculation is outsourced, but it is emphasized that the key material would still remain safe even if the password is exposed. Adjustments can be made to make password recovery more expensive if users are concerned about this vulnerability.The feasibility of using PBKDF2-HMAC-SHA512 for encryption in storage wallets is discussed. It is noted that this method is easy to implement on devices with limited RAM and can run at reasonable speeds on slow processors. Even if it takes several minutes to encrypt/decrypt, it is considered acceptable for one-time activities such as printing a cold wallet or importing an encrypted wallet into a phone. The deterministic time it takes allows for the addition of a progress bar to the user interface.The idea of using semi-trusted devices, like desktop PCs, for key stretching work in wallets is proposed. Concerns are raised about the security implications if a compromised computer is involved in the process. However, a compromise is reached with the inclusion of PBKDF2-HMAC-SHA512 based KDFs, which can run on memory-constrained devices and slow processors while still providing sufficient security.A bloom filter is proposed for typo checking and plausible deniability in a BIP. It is optimized for two elements and catches 99.9975% of typos while allowing for two different passwords. However, it is noted that this doesn't qualify as true plausible deniability as there are always at least two passwords. The conversation also covers the outsourcing of the KDF and the importance of using the specified algorithms to maintain compatibility.Discussions also touch on the integration of the BIP39 word list into Bitcoinj, timestamping and checksums, entropy length options, cross-wallet compatibility, and the benefits of a new specification over BIP 0038 and BIP 0039. It is suggested that BIP 0039 should not limit improvements on BIP 0038. The email thread concludes with links to a book on graph databases and the Bitcoin-development mailing list.In an email exchange, Jean-Paul Kogelman compared his proposal to BIP 39, highlighting the differences between the two. BIP 39 offers a list of words instead of using case-sensitive letters and numbers. It also supports different lengths of entropy, contrary to the belief that it only supports 12 words. Additionally, BIP 39 lacks a genesis date field, password typo detection, user-selectable KDF, and encourages the use of custom word lists.Kogelman announced updates to his spec, including removing Scrypt dependency, adding new KDFs, and plausible deniability. Pavol Rusnak mentioned BIP-0039, which offers an easy list of words, fixed length of entropy, no genesis date field, lack of password typo detection, no user-selectable KDF, inability to outsource KDF computation, and allows implementers to use their own word lists.On December 3rd, 2014, Kogelman shared the updates made in the spec, incorporating the requested features and removing Scrypt dependency. He also mentioned BIP-0039 as a related Bitcoin Improvement Proposal and provided a link to it.Kogelman proposed a method for encoding and encrypting Bitcoin HD Wallet root keys. The proposal includes encoding methodologies, encrypted and unencrypted wallet prefixes, verification information, salting, user-selectable KDF, second password option for plausible deniability, and prefix changes for alt-chains. The proposal provides KDF functions, date field for faster blockchain transaction search, derivation of master key from root key using SHA512, password encryption steps, bloom filter creation and verification methods, Python reference implementation, and test vectors.The context includes a list of public addresses, private extended keys, public extended keys, encrypted values, and creation dates for various test scenarios. Each scenario has different information such as root key, clear key, password, second password, associated public addresses, private extended keys, and public extended keys. Tests were conducted to generate multiple keys and public addresses using different KDFs, some with additional password encryption.The proposal includes updated wording, computation changes using PBKDF2-HMAC-SHA512, moving the KDF field, adding plausible deniability, new KDFs, entropy field in encrypted version, checksum field renamed to bloom field - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_0-9-0-release-candidate-two.xml b/static/bitcoin-dev/March_2014/combined_0-9-0-release-candidate-two.xml index 51a6b0050b..8521dda045 100644 --- a/static/bitcoin-dev/March_2014/combined_0-9-0-release-candidate-two.xml +++ b/static/bitcoin-dev/March_2014/combined_0-9-0-release-candidate-two.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.9.0 release candidate two - 2023-08-01T07:47:18.770603+00:00 + 2025-10-11T21:33:57.647832+00:00 + python-feedgen Christian Decker 2014-03-02 21:11:01+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - 0.9.0 release candidate two - 2023-08-01T07:47:18.770603+00:00 + 2025-10-11T21:33:57.647989+00:00 - James Hartig, a software engineer at Grooveshark.com, reported that his server was terminated after downloading the Linux tar.gz to his OVH box. The email screenshot he received indicated that he was attacking 88.198.199.140 over port 443. In response, Wladimir expressed doubt that bitcoind would connect to port 443 or "attack" anything and asked if there was anything in debug.log regarding that IP. James is currently trying to convince them that he wasn't attacking anyone so they can re-enable the server.In other news, Gavin Andresen requested users to download and test version 0.9.0rc2 for Bitcoin Core from https://bitcoin.org/bin/0.9.0/test/. This new release includes upgraded git dependencies, Windows 64-bit build support, Solaris compatibility fixes, and the ability to check the integrity of gitian input source tarballs. The latest Bitcoin release, version 0.9.0, also includes several changes such as tightened transaction rules to prevent relaying and mining of mutated transactions, dropping support for older Macs, and changes to the build system, RPC, command-line options, block-chain handling and storage, wallet, mining, protocol and network, validation, and build system. The GUI has been improved with the addition of payment request support, an options dialog, a send confirmation dialog with transaction fee display, a total balance on the overview page, and the ability for users to choose a data directory. The update also allows for the saving and restoration of window positions, the addition of a vout index to the transaction ID in transaction details, and a network traffic graph in the debug window. Additionally, there is now Coin Control Features and a receive coins workflow that makes the 'Receive' tab into a form to request payments. The update also adds the ability to move initialization/shutdown to a thread, preventing "not responding" messages during startup. A separate bitcoin-cli client has been added, and Linux users can now use the script (contrib/qos/tc.sh) to limit outgoing bandwidth. Finally, Bitcoin has been rebranded as Bitcoin Core.Bitcoin Core version 0.9.0rc2 is a release candidate for a new major version that brings both new features and bug fixes. The binaries are available for download from the Bitcoin website. Users are encouraged to test it and report bugs using the issue tracker on GitHub. If no serious bugs are found, this release candidate will become the final 0.9.0 release. This version includes several changes such as renaming the reference client to Bitcoin Core to reduce confusion between Bitcoin-the-network and Bitcoin-the-software, and switching to an autotools-based build system instead of individual (q)makefiles. The Windows 64-bit version of the client has been introduced in this release due to frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. However, release candidate 2 windows binaries are not code-signed, so users are advised to use PGP and SHA256SUMS.asc file to verify their binaries. The minimum requirements for Macs have also changed - a 64-bit-capable CPU running OSX 10.6 or later is now required, dropping support for older Macs. This release contains some fixes for transaction id malleability issues and drops the default fee required to relay transactions across the network to 0.01mBTC per kilobyte. Additionally, the relay fee may be changed with the -minrelaytxfee command-line option, and miners may change the default minimum fee they accept with the -mintxfee command-line option. There have also been several changes to RPC, command line options, block-chain handling and storage, GUI, mining, protocol and network, validation, and miscellaneous improvements. The latest bitcoin release includes a number of new features and enhancements. Among the most notable changes are the addition of a '-regtest' mode, which is similar to testnet but private with instant block generation using the 'setgenerate' RPC. Additionally, a new script called 'linearize.py' has been added to contrib, which creates a bootstrap.dat file. Finally, a separate bitcoin-cli client has also been introduced. A long list of contributors was acknowledged for their contributions to this release. 2014-03-02T21:11:01+00:00 + James Hartig, a software engineer at Grooveshark.com, reported that his server was terminated after downloading the Linux tar.gz to his OVH box. The email screenshot he received indicated that he was attacking 88.198.199.140 over port 443. In response, Wladimir expressed doubt that bitcoind would connect to port 443 or "attack" anything and asked if there was anything in debug.log regarding that IP. James is currently trying to convince them that he wasn't attacking anyone so they can re-enable the server.In other news, Gavin Andresen requested users to download and test version 0.9.0rc2 for Bitcoin Core from https://bitcoin.org/bin/0.9.0/test/. This new release includes upgraded git dependencies, Windows 64-bit build support, Solaris compatibility fixes, and the ability to check the integrity of gitian input source tarballs. The latest Bitcoin release, version 0.9.0, also includes several changes such as tightened transaction rules to prevent relaying and mining of mutated transactions, dropping support for older Macs, and changes to the build system, RPC, command-line options, block-chain handling and storage, wallet, mining, protocol and network, validation, and build system. The GUI has been improved with the addition of payment request support, an options dialog, a send confirmation dialog with transaction fee display, a total balance on the overview page, and the ability for users to choose a data directory. The update also allows for the saving and restoration of window positions, the addition of a vout index to the transaction ID in transaction details, and a network traffic graph in the debug window. Additionally, there is now Coin Control Features and a receive coins workflow that makes the 'Receive' tab into a form to request payments. The update also adds the ability to move initialization/shutdown to a thread, preventing "not responding" messages during startup. A separate bitcoin-cli client has been added, and Linux users can now use the script (contrib/qos/tc.sh) to limit outgoing bandwidth. Finally, Bitcoin has been rebranded as Bitcoin Core.Bitcoin Core version 0.9.0rc2 is a release candidate for a new major version that brings both new features and bug fixes. The binaries are available for download from the Bitcoin website. Users are encouraged to test it and report bugs using the issue tracker on GitHub. If no serious bugs are found, this release candidate will become the final 0.9.0 release. This version includes several changes such as renaming the reference client to Bitcoin Core to reduce confusion between Bitcoin-the-network and Bitcoin-the-software, and switching to an autotools-based build system instead of individual (q)makefiles. The Windows 64-bit version of the client has been introduced in this release due to frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. However, release candidate 2 windows binaries are not code-signed, so users are advised to use PGP and SHA256SUMS.asc file to verify their binaries. The minimum requirements for Macs have also changed - a 64-bit-capable CPU running OSX 10.6 or later is now required, dropping support for older Macs. This release contains some fixes for transaction id malleability issues and drops the default fee required to relay transactions across the network to 0.01mBTC per kilobyte. Additionally, the relay fee may be changed with the -minrelaytxfee command-line option, and miners may change the default minimum fee they accept with the -mintxfee command-line option. There have also been several changes to RPC, command line options, block-chain handling and storage, GUI, mining, protocol and network, validation, and miscellaneous improvements. The latest bitcoin release includes a number of new features and enhancements. Among the most notable changes are the addition of a '-regtest' mode, which is similar to testnet but private with instant block generation using the 'setgenerate' RPC. Additionally, a new script called 'linearize.py' has been added to contrib, which creates a bootstrap.dat file. Finally, a separate bitcoin-cli client has also been introduced. A long list of contributors was acknowledged for their contributions to this release. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_0-9-0rc3-tagged.xml b/static/bitcoin-dev/March_2014/combined_0-9-0rc3-tagged.xml index cbc8eee897..e29fed3e94 100644 --- a/static/bitcoin-dev/March_2014/combined_0-9-0rc3-tagged.xml +++ b/static/bitcoin-dev/March_2014/combined_0-9-0rc3-tagged.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.9.0rc3 tagged - 2023-08-01T07:57:13.679269+00:00 + 2025-10-11T21:34:10.385727+00:00 + python-feedgen Gavin Andresen 2014-03-13 12:25:32+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - 0.9.0rc3 tagged - 2023-08-01T07:57:13.679269+00:00 + 2025-10-11T21:34:10.385898+00:00 - The official website has released the binaries for the Bitcoin 0.9.0rc3 version and is calling on the community to participate in sanity testing to ensure stability and bug-free operation. The release of the final 0.9.0 version also requires more 'gitian builders', as currently only two builders, Wladimir and the author, have built the rc3 binaries. Users running Linux or OSX are encouraged to contribute by building dependencies on their virtual machines.Users have been advised to begin their gitian builds for the newly tagged version, 0.9.0rc3. This version brings changes to the mining code fee policy, which now aligns with the relay fee policy. Furthermore, a rare crash in the wallet code has been addressed, and minor alterations have been made to the build system, documentation, and GUI. Notably, no message regarding this update has been posted on the mailing list at this time. 2014-03-13T12:25:32+00:00 + The official website has released the binaries for the Bitcoin 0.9.0rc3 version and is calling on the community to participate in sanity testing to ensure stability and bug-free operation. The release of the final 0.9.0 version also requires more 'gitian builders', as currently only two builders, Wladimir and the author, have built the rc3 binaries. Users running Linux or OSX are encouraged to contribute by building dependencies on their virtual machines.Users have been advised to begin their gitian builds for the newly tagged version, 0.9.0rc3. This version brings changes to the mining code fee policy, which now aligns with the relay fee policy. Furthermore, a rare crash in the wallet code has been addressed, and minor alterations have been made to the build system, documentation, and GUI. Notably, no message regarding this update has been posted on the mailing list at this time. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml b/static/bitcoin-dev/March_2014/combined_2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml index 5b106d00bf..bf326f07d1 100644 --- a/static/bitcoin-dev/March_2014/combined_2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml +++ b/static/bitcoin-dev/March_2014/combined_2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 2-way pegging (Re: is there a way to do bitcoin-staging?) - 2023-08-01T07:59:04.213939+00:00 + 2025-10-11T21:34:33.763768+00:00 + python-feedgen Gregory Maxwell 2014-03-17 15:55:41+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - 2-way pegging (Re: is there a way to do bitcoin-staging?) - 2023-08-01T07:59:04.213939+00:00 + 2025-10-11T21:34:33.763935+00:00 - In a March 2014 email, Adam Back discussed the process of moving coins to a side-chain by spending them on a script that suspends them and allows for reanimation through an SPV proof of burn on the side-chain. However, this method can be cumbersome due to security requirements, resulting in large and slow transactions. Alternatively, atomic cross-chain transactions can be used instead of direct movement across chains, but they require an untrusted counterparty on the other chain.To address these issues, Adam Back proposed the term "fraud proof" for an SPV proof with a longer chain, but Jorge Timón suggested "reorg proof" as a more suitable term since reorganizations can occur without fraud. Timón also mentioned the possibility of pegging a side-chain to a private chain, which would allow for higher scaling while maintaining bitcoin security properties. However, he noted that requiring a side-chain proof of burn to move back to the side-chain could potentially lock funds by dishonest private chain operators. Instead, he proposed allowing unilateral withdrawals to impose the responsibility of observing the side-chain for double-spends on the private chain.Bitcoin developers have discovered that secure two-way pegging between side chains is possible with some changes to bitcoin. This enables interoperability, as users can move bitcoin into and out of a side-chain with different parameters or experimental features. Greg Maxwell proposed a compact method for two-way pegging using SPV proofs, which also provides a security firewall. On the beta chain network, bitcoin has no mining reward but allows users to mint coins at no mining cost by providing an SPV proof that the coin has been suspended in bitcoin.For more information on fast atomic cross-chain transactions and CoinSwap as a trustless trading option, please refer to the provided links. 2014-03-17T15:55:41+00:00 + In a March 2014 email, Adam Back discussed the process of moving coins to a side-chain by spending them on a script that suspends them and allows for reanimation through an SPV proof of burn on the side-chain. However, this method can be cumbersome due to security requirements, resulting in large and slow transactions. Alternatively, atomic cross-chain transactions can be used instead of direct movement across chains, but they require an untrusted counterparty on the other chain.To address these issues, Adam Back proposed the term "fraud proof" for an SPV proof with a longer chain, but Jorge Timón suggested "reorg proof" as a more suitable term since reorganizations can occur without fraud. Timón also mentioned the possibility of pegging a side-chain to a private chain, which would allow for higher scaling while maintaining bitcoin security properties. However, he noted that requiring a side-chain proof of burn to move back to the side-chain could potentially lock funds by dishonest private chain operators. Instead, he proposed allowing unilateral withdrawals to impose the responsibility of observing the side-chain for double-spends on the private chain.Bitcoin developers have discovered that secure two-way pegging between side chains is possible with some changes to bitcoin. This enables interoperability, as users can move bitcoin into and out of a side-chain with different parameters or experimental features. Greg Maxwell proposed a compact method for two-way pegging using SPV proofs, which also provides a security firewall. On the beta chain network, bitcoin has no mining reward but allows users to mint coins at no mining cost by providing an SPV proof that the coin has been suspended in bitcoin.For more information on fast atomic cross-chain transactions and CoinSwap as a trustless trading option, please refer to the provided links. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_BIP-70-and-OP-RETURN.xml b/static/bitcoin-dev/March_2014/combined_BIP-70-and-OP-RETURN.xml index 4a43754057..d0db88c232 100644 --- a/static/bitcoin-dev/March_2014/combined_BIP-70-and-OP-RETURN.xml +++ b/static/bitcoin-dev/March_2014/combined_BIP-70-and-OP-RETURN.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 70 and OP_RETURN - 2023-08-01T08:14:32.277980+00:00 + 2025-10-11T21:35:03.640187+00:00 + python-feedgen Mike Hearn 2014-03-29 15:06:04+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP 70 and OP_RETURN - 2023-08-01T08:14:32.277980+00:00 + 2025-10-11T21:35:03.640379+00:00 - The discussion in this context primarily revolves around BIP 70 compliance in Bitcoin Core and Android Bitcoin Wallet. The conversation starts with the suggestion that clients should be spec compliant if they are not already. However, there seems to be uncertainty about the specific functionality of BIP 70. Currently, only Bitcoin Core and Android Bitcoin Wallet implement BIP 70. To gain a better understanding, it is suggested to create a request and test it out. There is a question regarding whether all BIP 70 compatible clients support the creation of standard output types, including OP_RETURN outputs. The answer to this question is not explicitly provided in the context. Mike Hearn is involved in a separate discussion related to the encoding of OP_RETURN scripts into Output structures. There is some confusion about the question being asked, as it appears to provide its own answer in the first paragraph. The discussion seems to be related to blockchain technology or cryptocurrency, given the use of technical terms like OP_RETURN and Output structure. OP_RETURN is a specific type of transaction output used in Bitcoin and other cryptocurrencies. Its purpose is to embed arbitrary data into the blockchain without affecting the ownership or transfer of coins. This enables various applications such as storing metadata or proof of existence. On the other hand, an Output structure refers to the part of a transaction that specifies where the coins are being sent and how much is being sent. It contains the recipient's address and the amount of cryptocurrency being transferred. From this information, it can be inferred that the discussion focuses on the technical aspects of cryptocurrency transactions and the use of OP_RETURN script for encoding data onto the blockchain. The Output message allows for the specification of any standard TxOut script, including the ability to include OP_RETURN outputs in BIP 70 payment requests. If a payment request creator wants to include a small amount of data as an OP_RETURN output, they need to specify this information. Additionally, the context emphasizes the importance of supporting online privacy by utilizing email encryption whenever possible. A link is provided for further information on how to implement email encryption. The context also mentions the presence of attachments like a PGP key and digital signature, which can enhance security measures. 2014-03-29T15:06:04+00:00 + The discussion in this context primarily revolves around BIP 70 compliance in Bitcoin Core and Android Bitcoin Wallet. The conversation starts with the suggestion that clients should be spec compliant if they are not already. However, there seems to be uncertainty about the specific functionality of BIP 70. Currently, only Bitcoin Core and Android Bitcoin Wallet implement BIP 70. To gain a better understanding, it is suggested to create a request and test it out. There is a question regarding whether all BIP 70 compatible clients support the creation of standard output types, including OP_RETURN outputs. The answer to this question is not explicitly provided in the context. Mike Hearn is involved in a separate discussion related to the encoding of OP_RETURN scripts into Output structures. There is some confusion about the question being asked, as it appears to provide its own answer in the first paragraph. The discussion seems to be related to blockchain technology or cryptocurrency, given the use of technical terms like OP_RETURN and Output structure. OP_RETURN is a specific type of transaction output used in Bitcoin and other cryptocurrencies. Its purpose is to embed arbitrary data into the blockchain without affecting the ownership or transfer of coins. This enables various applications such as storing metadata or proof of existence. On the other hand, an Output structure refers to the part of a transaction that specifies where the coins are being sent and how much is being sent. It contains the recipient's address and the amount of cryptocurrency being transferred. From this information, it can be inferred that the discussion focuses on the technical aspects of cryptocurrency transactions and the use of OP_RETURN script for encoding data onto the blockchain. The Output message allows for the specification of any standard TxOut script, including the ability to include OP_RETURN outputs in BIP 70 payment requests. If a payment request creator wants to include a small amount of data as an OP_RETURN output, they need to specify this information. Additionally, the context emphasizes the importance of supporting online privacy by utilizing email encryption whenever possible. A link is provided for further information on how to implement email encryption. The context also mentions the presence of attachments like a PGP key and digital signature, which can enhance security measures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_BIP-70-refund-field.xml b/static/bitcoin-dev/March_2014/combined_BIP-70-refund-field.xml index 0d9781eacc..45bdaa65ec 100644 --- a/static/bitcoin-dev/March_2014/combined_BIP-70-refund-field.xml +++ b/static/bitcoin-dev/March_2014/combined_BIP-70-refund-field.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 70 refund field - 2023-08-01T08:14:12.745877+00:00 + 2025-10-11T21:34:42.258622+00:00 + python-feedgen Peter Todd 2014-03-31 09:23:09+00:00 @@ -111,13 +112,13 @@ - python-feedgen + 2 Combined summary - BIP 70 refund field - 2023-08-01T08:14:12.746873+00:00 + 2025-10-11T21:34:42.258835+00:00 - On March 28th, 2014, Mike Hearn proposed adding a refund field to BIP 70 for easier implementation of refunds on phones. The discussion revolved around establishing an appropriate time frame for refunds. Two months or three months were considered, with concerns about RAM usage and EU DSD compliance. A fixed expiry time of 2.5 years was suggested to comply with EU regulations, but the consensus was to adopt a couple of months for refunds.The conversation also touched upon the use of stealth addresses with a per-order UUID to improve scalability. Privacy concerns were raised due to a reduction in OP_RETURN size. The PaymentRequest specification was discussed regarding refunds and the absence of a specified time limit. The EU Distance Selling Directive and varying refund time frames across countries were also mentioned.There was a discussion about implementing BIP70 by BitPay, BopShop, and Trezor. It was seen as an easy process with no reason to be enthusiastic until further specification enhancements. The need for a fixed warranty expiry time to allow for shipping was debated, considering RAM usage. The current payment protocol's inability to handle salaries was noted, and emphasis was placed on solving existing problems before creating new ones.The potential limitations of the Bitcoin payment protocol were discussed, including symmetrical payment options, aggregating and netting for multiple installments, and enhanced security for payment and refund addresses. Incremental development was favored, but caution was advised against adding too many features at once. The need for a payment channel for businesses to handle salaries was proposed.Tags in a contact list to represent different payment types were suggested. The address itself could serve as the tag for blockchain-based payments, allowing for better UI display. The benefits of creating a clean protocol for repeated payments in both directions were highlighted, along with the importance of the refund field for intelligent wallet UIs.Mike Hearn expressed reluctance to manage a business relationship with every shop and suggested focusing on the buyer-to-seller relationship for now. The need for a protocol that deals with the concept of business relationships was mentioned.Overall, the discussions revolved around refund time frames, implementation of BIP70, warranty expiration, payment protocol limitations, and the importance of incremental development to address existing problems.The discussion revolves around the limitations of BIP70, a payment protocol, and the need for it to expand its scope beyond basic buyer-to-seller relationships. The protocol is criticized for not addressing the concept of business relationships and lacking provisions for communication between merchants and buyers in cases where refunds are required after a long period of time. The suggestion is made to create a new protocol that allows parties to terminate the relationship at their own discretion, rather than being controlled by algorithms and timeouts.Andreas Schildbach questions the use of PaymentDetails as a solution to a problem, noting that most of the fields cannot be known in advance at the time of initial payment. However, the other person suggests that only a few specific fields would be needed for refunds. Andreas raises concerns about the lack of protection for the refund address and proposes signing it with a key that is also signing the Bitcoin transaction. The other person agrees that tampering should not be possible over secure channels like HTTPS or Bluetooth but also suggests the idea of a full-blown PaymentRequest with optional PKI signing for refunds, although normally a seller wouldn't need to know the identity of a buyer for refunds.Mike Hearn discusses the impact of modern devices lacking swap files, which creates issues for storing keys or transactions in memory. He suggests adding a new refund field that embeds a PaymentDetails structure instead of just a list of outputs to address the lack of an equivalent for refund addresses. Alternatively, a wallet-specific swapping process could be used to create "infinite" wallets, but this may result in huge Bloom filters that hurt efficiency. Key expiry is considered fundamental to scalability.In conclusion, the limitations of BIP70 are highlighted, specifically regarding the narrow scope of the current payment protocol and the lack of provisions for refunds. Suggestions are made to either incorporate a refund field that embeds a PaymentDetails structure or implement a wallet-specific swapping process. The importance of key expiry and the impact of modern devices lacking swap files on storing keys or transactions in memory are also discussed. Overall, adding a refund feature with a time limit is seen as necessary to avoid wallets having to search for refunds for payments made years ago. 2014-03-31T09:23:09+00:00 + On March 28th, 2014, Mike Hearn proposed adding a refund field to BIP 70 for easier implementation of refunds on phones. The discussion revolved around establishing an appropriate time frame for refunds. Two months or three months were considered, with concerns about RAM usage and EU DSD compliance. A fixed expiry time of 2.5 years was suggested to comply with EU regulations, but the consensus was to adopt a couple of months for refunds.The conversation also touched upon the use of stealth addresses with a per-order UUID to improve scalability. Privacy concerns were raised due to a reduction in OP_RETURN size. The PaymentRequest specification was discussed regarding refunds and the absence of a specified time limit. The EU Distance Selling Directive and varying refund time frames across countries were also mentioned.There was a discussion about implementing BIP70 by BitPay, BopShop, and Trezor. It was seen as an easy process with no reason to be enthusiastic until further specification enhancements. The need for a fixed warranty expiry time to allow for shipping was debated, considering RAM usage. The current payment protocol's inability to handle salaries was noted, and emphasis was placed on solving existing problems before creating new ones.The potential limitations of the Bitcoin payment protocol were discussed, including symmetrical payment options, aggregating and netting for multiple installments, and enhanced security for payment and refund addresses. Incremental development was favored, but caution was advised against adding too many features at once. The need for a payment channel for businesses to handle salaries was proposed.Tags in a contact list to represent different payment types were suggested. The address itself could serve as the tag for blockchain-based payments, allowing for better UI display. The benefits of creating a clean protocol for repeated payments in both directions were highlighted, along with the importance of the refund field for intelligent wallet UIs.Mike Hearn expressed reluctance to manage a business relationship with every shop and suggested focusing on the buyer-to-seller relationship for now. The need for a protocol that deals with the concept of business relationships was mentioned.Overall, the discussions revolved around refund time frames, implementation of BIP70, warranty expiration, payment protocol limitations, and the importance of incremental development to address existing problems.The discussion revolves around the limitations of BIP70, a payment protocol, and the need for it to expand its scope beyond basic buyer-to-seller relationships. The protocol is criticized for not addressing the concept of business relationships and lacking provisions for communication between merchants and buyers in cases where refunds are required after a long period of time. The suggestion is made to create a new protocol that allows parties to terminate the relationship at their own discretion, rather than being controlled by algorithms and timeouts.Andreas Schildbach questions the use of PaymentDetails as a solution to a problem, noting that most of the fields cannot be known in advance at the time of initial payment. However, the other person suggests that only a few specific fields would be needed for refunds. Andreas raises concerns about the lack of protection for the refund address and proposes signing it with a key that is also signing the Bitcoin transaction. The other person agrees that tampering should not be possible over secure channels like HTTPS or Bluetooth but also suggests the idea of a full-blown PaymentRequest with optional PKI signing for refunds, although normally a seller wouldn't need to know the identity of a buyer for refunds.Mike Hearn discusses the impact of modern devices lacking swap files, which creates issues for storing keys or transactions in memory. He suggests adding a new refund field that embeds a PaymentDetails structure instead of just a list of outputs to address the lack of an equivalent for refund addresses. Alternatively, a wallet-specific swapping process could be used to create "infinite" wallets, but this may result in huge Bloom filters that hurt efficiency. Key expiry is considered fundamental to scalability.In conclusion, the limitations of BIP70 are highlighted, specifically regarding the narrow scope of the current payment protocol and the lack of provisions for refunds. Suggestions are made to either incorporate a refund field that embeds a PaymentDetails structure or implement a wallet-specific swapping process. The importance of key expiry and the impact of modern devices lacking swap files on storing keys or transactions in memory are also discussed. Overall, adding a refund feature with a time limit is seen as necessary to avoid wallets having to search for refunds for payments made years ago. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_BIP70-extension-to-allow-for-identity-delegation.xml b/static/bitcoin-dev/March_2014/combined_BIP70-extension-to-allow-for-identity-delegation.xml index 40a59f9e98..7c7c5d1ed5 100644 --- a/static/bitcoin-dev/March_2014/combined_BIP70-extension-to-allow-for-identity-delegation.xml +++ b/static/bitcoin-dev/March_2014/combined_BIP70-extension-to-allow-for-identity-delegation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70 extension to allow for identity delegation - 2023-08-01T07:45:08.881966+00:00 + 2025-10-11T21:33:51.268497+00:00 + python-feedgen Mike Hearn 2014-03-02 16:14:43+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP70 extension to allow for identity delegation - 2023-08-01T07:45:08.881966+00:00 + 2025-10-11T21:33:51.268669+00:00 - In a 2014 email exchange between Andreas Schildbach and Mike Hearn, concerns were raised about the deployment of a new extension for Bitcoin Improvement Proposal 70 (BIP70). Schildbach believed it was too early to implement the extension widely and questioned whether multiple Public Key Infrastructures (PKIs) could be used at once. Hearn explained that the proposal did not allow for multiple PKIs and clarified that the extension specialized and extended the existing PKI. He also argued against keeping the fix local to X.509, stating that it would sacrifice backwards compatibility.The proposed extension aims to address issues with payment processors and security risks by allowing identity delegation. It suggests creating an extended certificate that would be added to the X509Certificates message in the PaymentRequest. This new certificate would be signed by both the SSL certificate of the payment processor and their delegated ECDSA key. The proposed implementation includes an option for maximum security, where the merchant can set short expiry times on the certificates and upload a new one at the end of each period. This ensures faster resealing in case of payment processor compromise. The proposal also explores alternatives, such as using the User-Agent field or creating the extension certificate as an X.509 cert, but ultimately recommends a unique format to ensure safety.In the email conversation, Dev Random raises concerns about the technical expertise required for small businesses or individuals to perform delegation signature. One solution proposed is to create a simple GUI app that allows them to produce the ExtendedCert file, which can then be sent to the payment processor. However, for small businesses without a CA cert, there are currently no ideal solutions available. Another idea discussed is the possibility of a scheme where a merchant can be namespaced under the payment processor, requiring just one additional field - the merchant identifier. However, the exact definition of the "merchant identifier" is left unresolved. The suggestion of payment processors becoming certificate authorities themselves is also mentioned, with BitPay as an example. However, this would require significant setup and raises questions about the verification process.The current user interface (UI) may not effectively alert users to potential issues with payment processing due to a lack of authenticated fields beyond the memo field available to payment processors. One solution proposed is to include a certificate viewer in the UI, allowing advanced users to inspect the certificate for additional fields. However, this may only benefit advanced users, and there may be difficulties in getting certificate authorities to sign certificates with arbitrary data. It is considered undesirable for users to have to make special requests to their certificate authorities.In another email exchange, Mike Hearn expresses concerns about the security risks associated with payment processors that allow open signups. He warns that hackers could sign up for a payment processor under false identities and swap out payment requests, leading to potential fraud. To address this, he suggests embedding additional information in payment requests, such as specific fields defined in an extension, to be shown reliably in the user interface. The proposal faces difficulties in getting certificate authorities to allow additional fields in certificates, so a simpler solution is suggested: having a single field containing a delimited key/value string (in JSON format) that can be shown as additional lines of labeled text in the UI.The lack of identity delegation in BIP70 poses challenges for payment processors like BitPay and Coinbase, as they have to sign payment requests as themselves, resulting in a confusing UI for users. Mike Hearn proposes a simple extension that allows the creation of an extended certificate, which is similar to X.509 certificates but simpler and Bitcoin-specific. The ExtensionCert message includes an ECDSA public key from the payment processor, signature, and expiry time fields. The merchant can be namespaced under the payment processor, giving the user the correct name in the wallet UI. The memo field can optionally indicate the purpose of the cert. Dev Random suggests a solution for small businesses or individuals without technical expertise, where the payment processor certifies that the merchant generated the invoice directly on their system. The proposal emphasizes the importance of security and simplicity, considering alternatives like using the User-Agent field or creating an X.509 cert but deeming them less safe.The implementation of BIP70 highlights the need for identity delegation, which is not included in version 1. Payment processors face challenges in signing payment requests as themselves, leading to confusion in the user interface. The proposed solution involves creating an extended certificate specific to Bitcoin, called the "extension certificate." This certificate includes the ECDSA public key of the payment processor and is signed using an SSL private key. It is added to the X509Certificates message provided by the payment processor. The PaymentRequest then contains two signature fields: one using the SSL cert of the payment processor and another using the delegated ECDSA key. The proposal also addresses cases where there is no X.509 cert available and explores alternatives to customize the PaymentRequest based on client capabilities. 2014-03-02T16:14:43+00:00 + In a 2014 email exchange between Andreas Schildbach and Mike Hearn, concerns were raised about the deployment of a new extension for Bitcoin Improvement Proposal 70 (BIP70). Schildbach believed it was too early to implement the extension widely and questioned whether multiple Public Key Infrastructures (PKIs) could be used at once. Hearn explained that the proposal did not allow for multiple PKIs and clarified that the extension specialized and extended the existing PKI. He also argued against keeping the fix local to X.509, stating that it would sacrifice backwards compatibility.The proposed extension aims to address issues with payment processors and security risks by allowing identity delegation. It suggests creating an extended certificate that would be added to the X509Certificates message in the PaymentRequest. This new certificate would be signed by both the SSL certificate of the payment processor and their delegated ECDSA key. The proposed implementation includes an option for maximum security, where the merchant can set short expiry times on the certificates and upload a new one at the end of each period. This ensures faster resealing in case of payment processor compromise. The proposal also explores alternatives, such as using the User-Agent field or creating the extension certificate as an X.509 cert, but ultimately recommends a unique format to ensure safety.In the email conversation, Dev Random raises concerns about the technical expertise required for small businesses or individuals to perform delegation signature. One solution proposed is to create a simple GUI app that allows them to produce the ExtendedCert file, which can then be sent to the payment processor. However, for small businesses without a CA cert, there are currently no ideal solutions available. Another idea discussed is the possibility of a scheme where a merchant can be namespaced under the payment processor, requiring just one additional field - the merchant identifier. However, the exact definition of the "merchant identifier" is left unresolved. The suggestion of payment processors becoming certificate authorities themselves is also mentioned, with BitPay as an example. However, this would require significant setup and raises questions about the verification process.The current user interface (UI) may not effectively alert users to potential issues with payment processing due to a lack of authenticated fields beyond the memo field available to payment processors. One solution proposed is to include a certificate viewer in the UI, allowing advanced users to inspect the certificate for additional fields. However, this may only benefit advanced users, and there may be difficulties in getting certificate authorities to sign certificates with arbitrary data. It is considered undesirable for users to have to make special requests to their certificate authorities.In another email exchange, Mike Hearn expresses concerns about the security risks associated with payment processors that allow open signups. He warns that hackers could sign up for a payment processor under false identities and swap out payment requests, leading to potential fraud. To address this, he suggests embedding additional information in payment requests, such as specific fields defined in an extension, to be shown reliably in the user interface. The proposal faces difficulties in getting certificate authorities to allow additional fields in certificates, so a simpler solution is suggested: having a single field containing a delimited key/value string (in JSON format) that can be shown as additional lines of labeled text in the UI.The lack of identity delegation in BIP70 poses challenges for payment processors like BitPay and Coinbase, as they have to sign payment requests as themselves, resulting in a confusing UI for users. Mike Hearn proposes a simple extension that allows the creation of an extended certificate, which is similar to X.509 certificates but simpler and Bitcoin-specific. The ExtensionCert message includes an ECDSA public key from the payment processor, signature, and expiry time fields. The merchant can be namespaced under the payment processor, giving the user the correct name in the wallet UI. The memo field can optionally indicate the purpose of the cert. Dev Random suggests a solution for small businesses or individuals without technical expertise, where the payment processor certifies that the merchant generated the invoice directly on their system. The proposal emphasizes the importance of security and simplicity, considering alternatives like using the User-Agent field or creating an X.509 cert but deeming them less safe.The implementation of BIP70 highlights the need for identity delegation, which is not included in version 1. Payment processors face challenges in signing payment requests as themselves, leading to confusion in the user interface. The proposed solution involves creating an extended certificate specific to Bitcoin, called the "extension certificate." This certificate includes the ECDSA public key of the payment processor and is signed using an SSL private key. It is added to the X509Certificates message provided by the payment processor. The PaymentRequest then contains two signature fields: one using the SSL cert of the payment processor and another using the delegated ECDSA key. The proposal also addresses cases where there is no X.509 cert available and explores alternatives to customize the PaymentRequest based on client capabilities. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_BIP70-proposed-changes.xml b/static/bitcoin-dev/March_2014/combined_BIP70-proposed-changes.xml index 8e9a817292..abf671f074 100644 --- a/static/bitcoin-dev/March_2014/combined_BIP70-proposed-changes.xml +++ b/static/bitcoin-dev/March_2014/combined_BIP70-proposed-changes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70 proposed changes - 2023-08-01T07:40:05.028127+00:00 + 2025-10-11T21:35:07.884687+00:00 + python-feedgen Alon Muroch 2014-05-06 08:22:15+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP70 proposed changes - 2023-08-01T07:40:05.028127+00:00 + 2025-10-11T21:35:07.884867+00:00 - In an email conversation, Odinn Cyberguerrilla discusses the progress of two-factor authentication and bitcoin with the Bitcoin developers Andreas Schildbach and Jeff Garzik. They are working on a decentralized authentication protocol based on bitcoin-like addresses. BitPay is also developing a new standard for authentication and hopes to establish a complete, decentralized authentication protocol with community support. Progress can be followed on their Github page. Odinn also asks about progress on a fully decentralized way of residing on one's device or devices and mentions maidsafe, a decentralized internet platform.Ryan X. Charles suggests that BitPay implement merge avoidance to increase customer and merchant privacy in the payment protocol. He also expresses concerns about X.509 encryption certificates and proposes a new standard for authentication based on bitcoin-like addresses. In another email, Ryan expresses concern about the missing concept of payment status after it has been made and suggests adding a message to return the merchant's view of the transaction status. He also recommends requiring UTC for times in the payment protocol to avoid confusion. Gavin Andresen and Andreas Schildbach provide feedback and suggest changes to BIP70.The email thread also includes discussions about X.509 certificates, the length of Bitcoin URIs, and the possibility of having a UNIX UTC timestamp field in customer payment messages. The conversation covers various technical aspects and potential improvements to the payment protocol. 2014-05-06T08:22:15+00:00 + In an email conversation, Odinn Cyberguerrilla discusses the progress of two-factor authentication and bitcoin with the Bitcoin developers Andreas Schildbach and Jeff Garzik. They are working on a decentralized authentication protocol based on bitcoin-like addresses. BitPay is also developing a new standard for authentication and hopes to establish a complete, decentralized authentication protocol with community support. Progress can be followed on their Github page. Odinn also asks about progress on a fully decentralized way of residing on one's device or devices and mentions maidsafe, a decentralized internet platform.Ryan X. Charles suggests that BitPay implement merge avoidance to increase customer and merchant privacy in the payment protocol. He also expresses concerns about X.509 encryption certificates and proposes a new standard for authentication based on bitcoin-like addresses. In another email, Ryan expresses concern about the missing concept of payment status after it has been made and suggests adding a message to return the merchant's view of the transaction status. He also recommends requiring UTC for times in the payment protocol to avoid confusion. Gavin Andresen and Andreas Schildbach provide feedback and suggest changes to BIP70.The email thread also includes discussions about X.509 certificates, the length of Bitcoin URIs, and the possibility of having a UNIX UTC timestamp field in customer payment messages. The conversation covers various technical aspects and potential improvements to the payment protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Best-practices-for-dust-remining.xml b/static/bitcoin-dev/March_2014/combined_Best-practices-for-dust-remining.xml index 281141f2ee..8ccb97cb91 100644 --- a/static/bitcoin-dev/March_2014/combined_Best-practices-for-dust-remining.xml +++ b/static/bitcoin-dev/March_2014/combined_Best-practices-for-dust-remining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Best practices for dust remining - 2023-08-01T08:30:02.096296+00:00 + 2025-10-11T21:34:46.505032+00:00 + python-feedgen Mark Friedenbach 2014-03-29 20:10:00+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Best practices for dust remining - 2023-08-01T08:30:02.096296+00:00 + 2025-10-11T21:34:46.505189+00:00 - In March 2014, a discussion took place on the Bitcoin-development mailing list regarding the handling of dust deposits in a multisig wallet. Dust deposits are small amounts of bitcoin that are not economically viable to spend due to high transaction fees. These deposits were received as part of an advertising campaign for the Olympics. Justus Ranvier initiated the conversation, seeking advice on how to clean up the unspent transaction output (UTXO) set without compromising the security of the multisig wallet.One concern raised by Ranvier was the possibility of the scripts including large values of n, which represents the number of signatures required to authorize a transaction from the wallet. The thread primarily focuses on the use of the NONE|ANYONECANPAY transaction type. This transaction type allows anyone to add inputs to a transaction without requiring their signature. By utilizing this transaction type, it becomes possible to combine the dust outputs into a single transaction that can be spent by a miner who includes a fee that makes it economically viable.Various suggestions were put forward during the discussion. One contributor recommended using a tool like Pycoin to manually craft the transaction. Another proposed the idea of creating a custom client that would automatically handle dust inputs using NONE|ANYONECANPAY transactions.Overall, this email thread provides insights into the technical challenges associated with dealing with dust deposits in a multisig wallet. It highlights the importance of keeping the UTXO set clean for the overall health of the Bitcoin network. Additionally, the context mentions the use of email encryption for online privacy and provides a link for further information on implementing this measure. The attachments included in the email consist of a PGP-key and a PGP-signature. 2014-03-29T20:10:00+00:00 + In March 2014, a discussion took place on the Bitcoin-development mailing list regarding the handling of dust deposits in a multisig wallet. Dust deposits are small amounts of bitcoin that are not economically viable to spend due to high transaction fees. These deposits were received as part of an advertising campaign for the Olympics. Justus Ranvier initiated the conversation, seeking advice on how to clean up the unspent transaction output (UTXO) set without compromising the security of the multisig wallet.One concern raised by Ranvier was the possibility of the scripts including large values of n, which represents the number of signatures required to authorize a transaction from the wallet. The thread primarily focuses on the use of the NONE|ANYONECANPAY transaction type. This transaction type allows anyone to add inputs to a transaction without requiring their signature. By utilizing this transaction type, it becomes possible to combine the dust outputs into a single transaction that can be spent by a miner who includes a fee that makes it economically viable.Various suggestions were put forward during the discussion. One contributor recommended using a tool like Pycoin to manually craft the transaction. Another proposed the idea of creating a custom client that would automatically handle dust inputs using NONE|ANYONECANPAY transactions.Overall, this email thread provides insights into the technical challenges associated with dealing with dust deposits in a multisig wallet. It highlights the importance of keeping the UTXO set clean for the overall health of the Bitcoin network. Additionally, the context mentions the use of email encryption for online privacy and provides a link for further information on implementing this measure. The attachments included in the email consist of a PGP-key and a PGP-signature. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Bitcoin-for-W3C-Payments-Workshop-March-24-25.xml b/static/bitcoin-dev/March_2014/combined_Bitcoin-for-W3C-Payments-Workshop-March-24-25.xml index 6dc3d6dc39..f64a8580d6 100644 --- a/static/bitcoin-dev/March_2014/combined_Bitcoin-for-W3C-Payments-Workshop-March-24-25.xml +++ b/static/bitcoin-dev/March_2014/combined_Bitcoin-for-W3C-Payments-Workshop-March-24-25.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin for W3C Payments Workshop, March 24-25 - 2023-08-01T07:59:45.336101+00:00 + 2025-10-11T21:34:12.510000+00:00 + python-feedgen Melvin Carvalho 2014-03-20 02:03:09+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bitcoin for W3C Payments Workshop, March 24-25 - 2023-08-01T07:59:45.336101+00:00 + 2025-10-11T21:34:12.510137+00:00 - The W3C (World Wide Web Consortium) Payments Workshop has recently faced criticism for its requirement of Contributor License Agreements (CLAs) for participation. One individual, Odinn Cyberguerrilla, expressed disagreement with the proposal, arguing that the requirements hinder innovation and free thought. The CLA mandates that participants agree to license their Essential Claims under the W3C CLA RF Licensing Requirements, among other obligations. In response, someone pointed out that all specs created by the W3C are committed to be royalty-free, necessitating the need for CLAs to ensure contributions remain unencumbered by patents or royalties.Meanwhile, Brent Shambaugh has been actively working on use cases for the W3C payments workshop, specifically focusing on incorporating Bitcoin. He has shared a link to an editable wiki page where members of the Web Payments Community Group can contribute their ideas through pull requests. The template provided includes key use cases for the solution, regions, and currencies. The use cases aim to address various scenarios such as adding real money to the service, purchasing physical goods in the real world, paying for physical services, converting virtual money into paper currency, transferring funds between individuals (even if the recipient is not part of the service), buying products online, resolving disputes, viewing transactions, and ensuring wallet security.Brent, an enthusiastic Bitcoin advocate, invites others to contribute to the project and expresses gratitude for their time and involvement in shaping the future of web payments. 2014-03-20T02:03:09+00:00 + The W3C (World Wide Web Consortium) Payments Workshop has recently faced criticism for its requirement of Contributor License Agreements (CLAs) for participation. One individual, Odinn Cyberguerrilla, expressed disagreement with the proposal, arguing that the requirements hinder innovation and free thought. The CLA mandates that participants agree to license their Essential Claims under the W3C CLA RF Licensing Requirements, among other obligations. In response, someone pointed out that all specs created by the W3C are committed to be royalty-free, necessitating the need for CLAs to ensure contributions remain unencumbered by patents or royalties.Meanwhile, Brent Shambaugh has been actively working on use cases for the W3C payments workshop, specifically focusing on incorporating Bitcoin. He has shared a link to an editable wiki page where members of the Web Payments Community Group can contribute their ideas through pull requests. The template provided includes key use cases for the solution, regions, and currencies. The use cases aim to address various scenarios such as adding real money to the service, purchasing physical goods in the real world, paying for physical services, converting virtual money into paper currency, transferring funds between individuals (even if the recipient is not part of the service), buying products online, resolving disputes, viewing transactions, and ensuring wallet security.Brent, an enthusiastic Bitcoin advocate, invites others to contribute to the project and expresses gratitude for their time and involvement in shaping the future of web payments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Bitcoin-wiki-is-down.xml b/static/bitcoin-dev/March_2014/combined_Bitcoin-wiki-is-down.xml index 748519e129..c418bf9bbd 100644 --- a/static/bitcoin-dev/March_2014/combined_Bitcoin-wiki-is-down.xml +++ b/static/bitcoin-dev/March_2014/combined_Bitcoin-wiki-is-down.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin wiki is down - 2023-08-01T07:52:35.537682+00:00 + 2025-10-11T21:34:38.009768+00:00 + python-feedgen Gregory Maxwell 2014-03-08 23:13:33+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin wiki is down - 2023-08-01T07:52:35.538752+00:00 + 2025-10-11T21:34:38.009923+00:00 - On March 8, 2014, Tom Geller raised concern about the Bitcoin wiki being down and requested information on how to report such occurrences. It was later discovered that the wiki was undergoing changes in control and operation. Despite the outage, it was assured that there was nothing to fear as a result of this change.The current status of the Bitcoin wiki, which is normally accessible at https://en.bitcoin.it, is currently down. The cause of this outage remains unknown, and there is no indication of when it will be resolved. Unfortunately, there are no designated communication procedures or specific point persons for reporting issues related to the Bitcoin wiki.However, for individuals seeking assistance with various tasks including articles, marketing, videos, user guides, and books, Tom Geller, a writer and presenter based in Oberlin, Ohio, can be contacted. His contact information can be found on his website at http://www.tomgeller.com. 2014-03-08T23:13:33+00:00 + On March 8, 2014, Tom Geller raised concern about the Bitcoin wiki being down and requested information on how to report such occurrences. It was later discovered that the wiki was undergoing changes in control and operation. Despite the outage, it was assured that there was nothing to fear as a result of this change.The current status of the Bitcoin wiki, which is normally accessible at https://en.bitcoin.it, is currently down. The cause of this outage remains unknown, and there is no indication of when it will be resolved. Unfortunately, there are no designated communication procedures or specific point persons for reporting issues related to the Bitcoin wiki.However, for individuals seeking assistance with various tasks including articles, marketing, videos, user guides, and books, Tom Geller, a writer and presenter based in Oberlin, Ohio, can be contacted. His contact information can be found on his website at http://www.tomgeller.com. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Decentralized-digital-asset-exchange-with-honest-pricing-and-market-depth.xml b/static/bitcoin-dev/March_2014/combined_Decentralized-digital-asset-exchange-with-honest-pricing-and-market-depth.xml index 74cc0312a7..94b64b9f7d 100644 --- a/static/bitcoin-dev/March_2014/combined_Decentralized-digital-asset-exchange-with-honest-pricing-and-market-depth.xml +++ b/static/bitcoin-dev/March_2014/combined_Decentralized-digital-asset-exchange-with-honest-pricing-and-market-depth.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Decentralized digital asset exchange with honest pricing and market depth - 2023-08-01T07:35:38.591290+00:00 + 2025-10-11T21:34:06.142799+00:00 + python-feedgen Jorge Timón 2014-03-02 19:03:06+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Decentralized digital asset exchange with honest pricing and market depth - 2023-08-01T07:35:38.591290+00:00 + 2025-10-11T21:34:06.142986+00:00 - Troy Benjegerdes requested a clear design document for developing code for trading between two blockchains. The conversation then shifted towards the importance of accurate historic market data in buying and selling commodities. Some argued that trade is the primary goal of markets, while others emphasized the significance of accurate historic data for traders. Despite the debates, Benjegerdes reiterated his request for working code for cross-chain trades and suggested addressing the historic data problem later.The discussion also touched upon the vulnerability of a Bitmessage-like network to front-running through a sybil attack. It was pointed out that marketplaces face challenges because the data they publish must be public, making them susceptible to attacks. The primary goal of markets was asserted to be trade itself rather than price discovery. While the accuracy of historic data may not be crucial, as long as personal trade data is correct and auditable, buyers and sellers can still exchange goods at a good price. In another email conversation, Peter Todd discussed the possibility of a hard fork to enable marketplaces. He expressed support for testing out the functionality of marketplaces through one-sided trade before considering any forks. Todd disagreed with the argument that a Bitmessage-like network would be easily front-run through a sybil attack. He emphasized that the primary goal of markets is trade, not price discovery. Todd also discussed the importance of accurate historic market data and proposed methods to ensure honesty in records.The context included discussions on cross-chain trading, the limitations of hard forks, and the importance of accurate historic market data. Various viewpoints were presented regarding the role of markets, the vulnerability of networks to attacks, and the need for working code for cross-chain trades. The conversations involved multiple participants who shared their perspectives on these topics.In the given context, a two-step trade mechanism is described that allows for trust-free and atomic transactions. The mechanism involves Alice creating a partial transaction with an input she controls and an output that she controls as well. She gives this partial transaction to Bob, who completes it by providing one or more inputs with a sum value of at least 1BTC and an output for the colored coins to be directed to. Bob signs his inputs with SIGHASH_ALL and broadcasts the transaction, completing the trade.This two-step trade mechanism can also be used to create a decentralized marketplace. Proof-of-publication offers a solution in this case by allowing Alice to embed her incomplete transaction as data in a second, valid transaction. Bidders like Bob can then scan the blockchain for offers with acceptable prices, and unfilled offers at any given block height provide honest information about the market historically.It is mentioned that any embedded consensus system can make use of this two-step trade mechanism as long as it is possible to create transactions where spending a single transaction output moves an asset appropriately. However, extending this mechanism to situations where more than one input needs to be spent or more than one output needs to be created is difficult.An alternative approach could be to create a mechanism where some embedded data signifies the creation of a temporary transfer txout. Spending that txout would then atomically bring about the desired change in the consensus state. This alternative approach would overcome the limitations of the current mechanism when dealing with multiple inputs or outputs. 2014-03-02T19:03:06+00:00 + Troy Benjegerdes requested a clear design document for developing code for trading between two blockchains. The conversation then shifted towards the importance of accurate historic market data in buying and selling commodities. Some argued that trade is the primary goal of markets, while others emphasized the significance of accurate historic data for traders. Despite the debates, Benjegerdes reiterated his request for working code for cross-chain trades and suggested addressing the historic data problem later.The discussion also touched upon the vulnerability of a Bitmessage-like network to front-running through a sybil attack. It was pointed out that marketplaces face challenges because the data they publish must be public, making them susceptible to attacks. The primary goal of markets was asserted to be trade itself rather than price discovery. While the accuracy of historic data may not be crucial, as long as personal trade data is correct and auditable, buyers and sellers can still exchange goods at a good price. In another email conversation, Peter Todd discussed the possibility of a hard fork to enable marketplaces. He expressed support for testing out the functionality of marketplaces through one-sided trade before considering any forks. Todd disagreed with the argument that a Bitmessage-like network would be easily front-run through a sybil attack. He emphasized that the primary goal of markets is trade, not price discovery. Todd also discussed the importance of accurate historic market data and proposed methods to ensure honesty in records.The context included discussions on cross-chain trading, the limitations of hard forks, and the importance of accurate historic market data. Various viewpoints were presented regarding the role of markets, the vulnerability of networks to attacks, and the need for working code for cross-chain trades. The conversations involved multiple participants who shared their perspectives on these topics.In the given context, a two-step trade mechanism is described that allows for trust-free and atomic transactions. The mechanism involves Alice creating a partial transaction with an input she controls and an output that she controls as well. She gives this partial transaction to Bob, who completes it by providing one or more inputs with a sum value of at least 1BTC and an output for the colored coins to be directed to. Bob signs his inputs with SIGHASH_ALL and broadcasts the transaction, completing the trade.This two-step trade mechanism can also be used to create a decentralized marketplace. Proof-of-publication offers a solution in this case by allowing Alice to embed her incomplete transaction as data in a second, valid transaction. Bidders like Bob can then scan the blockchain for offers with acceptable prices, and unfilled offers at any given block height provide honest information about the market historically.It is mentioned that any embedded consensus system can make use of this two-step trade mechanism as long as it is possible to create transactions where spending a single transaction output moves an asset appropriately. However, extending this mechanism to situations where more than one input needs to be spent or more than one output needs to be created is difficult.An alternative approach could be to create a mechanism where some embedded data signifies the creation of a temporary transfer txout. Spending that txout would then atomically bring about the desired change in the consensus state. This alternative approach would overcome the limitations of the current mechanism when dealing with multiple inputs or outputs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Dust-recycling.xml b/static/bitcoin-dev/March_2014/combined_Dust-recycling.xml index cc89f7cc2b..e2fb43c781 100644 --- a/static/bitcoin-dev/March_2014/combined_Dust-recycling.xml +++ b/static/bitcoin-dev/March_2014/combined_Dust-recycling.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dust recycling - 2023-08-01T08:30:21.387377+00:00 + 2025-10-11T21:35:10.015535+00:00 + python-feedgen Gregory Maxwell 2014-03-29 20:33:13+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Dust recycling - 2023-08-01T08:30:21.387377+00:00 + 2025-10-11T21:35:10.015710+00:00 - During a conversation between Justus Ranvier and Gregory Maxwell, they discussed the issue of dust in transactions. Maxwell suggested using "dust-b-gone" to transfer the responsibility of relaying dust to someone else. However, Ranvier argued against this solution, stating that it introduces a third party and could result in server downtime. Instead, he proposed starting the server oneself and aggregating multiple bits of dust in single transactions for greater efficiency. He also highlighted the challenge of miners prioritizing transactions with higher fees per byte over those with dust.On March 29, 2014, during a discussion, Gregory Maxwell's suggestion of using "dust-b-gone" was seen as sub-optimal due to its reliance on a third party and potential server issues. The participants agreed that a universal solution would be preferable. The conversation also included a call to support online privacy by utilizing email encryption whenever possible, with a link provided for learning how to do so. The email thread contained two attachments: an application/pgp-keys file and an application/pgp-signature.In another discussion on the same day, Justus Ranvier proposed the need for a standard output type to facilitate sending the entire transaction to miner fees easily. He jokingly referred to this output type as a "return operator." This would enable even large transactions that would typically be dropped by fee/kB rules to propagate. Another user suggested using "dust-b-gone" to shift the responsibility of relaying such transactions to others.A physician and BitCoin enthusiast named Brian C. Goss raised a question in an email thread from March 29, 2014, regarding the possibility of collecting dust into a transaction with no outputs or including it in an anyone can spend transaction. Goss acknowledged that the large number of signatures for large n could result in a large transaction size. However, if enough dust were present, it might be worth propagating to a pool's hash power. Another individual responded by suggesting the use of a standard output type that would allow even large transactions, which would normally be dropped by fee/kB rules, to propagate. The email thread included attachments for an encrypted key and signature, promoting secure communication. 2014-03-29T20:33:13+00:00 + During a conversation between Justus Ranvier and Gregory Maxwell, they discussed the issue of dust in transactions. Maxwell suggested using "dust-b-gone" to transfer the responsibility of relaying dust to someone else. However, Ranvier argued against this solution, stating that it introduces a third party and could result in server downtime. Instead, he proposed starting the server oneself and aggregating multiple bits of dust in single transactions for greater efficiency. He also highlighted the challenge of miners prioritizing transactions with higher fees per byte over those with dust.On March 29, 2014, during a discussion, Gregory Maxwell's suggestion of using "dust-b-gone" was seen as sub-optimal due to its reliance on a third party and potential server issues. The participants agreed that a universal solution would be preferable. The conversation also included a call to support online privacy by utilizing email encryption whenever possible, with a link provided for learning how to do so. The email thread contained two attachments: an application/pgp-keys file and an application/pgp-signature.In another discussion on the same day, Justus Ranvier proposed the need for a standard output type to facilitate sending the entire transaction to miner fees easily. He jokingly referred to this output type as a "return operator." This would enable even large transactions that would typically be dropped by fee/kB rules to propagate. Another user suggested using "dust-b-gone" to shift the responsibility of relaying such transactions to others.A physician and BitCoin enthusiast named Brian C. Goss raised a question in an email thread from March 29, 2014, regarding the possibility of collecting dust into a transaction with no outputs or including it in an anyone can spend transaction. Goss acknowledged that the large number of signatures for large n could result in a large transaction size. However, if enough dust were present, it might be worth propagating to a pool's hash power. Another individual responded by suggesting the use of a standard output type that would allow even large transactions, which would normally be dropped by fee/kB rules, to propagate. The email thread included attachments for an encrypted key and signature, promoting secure communication. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Electrum-1-9-8-release.xml b/static/bitcoin-dev/March_2014/combined_Electrum-1-9-8-release.xml index 6860f9a07e..dcf734876c 100644 --- a/static/bitcoin-dev/March_2014/combined_Electrum-1-9-8-release.xml +++ b/static/bitcoin-dev/March_2014/combined_Electrum-1-9-8-release.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Electrum 1.9.8 release - 2023-08-01T07:58:47.649348+00:00 + 2025-10-11T21:35:12.138059+00:00 + python-feedgen Thomas Voegtlin 2014-03-16 15:48:21+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Electrum 1.9.8 release - 2023-08-01T07:58:47.649348+00:00 + 2025-10-11T21:35:12.138230+00:00 - In an email exchange on March 16, 2014, it was revealed that there were problems with the encryption methods in the current release of a software. Thomas Voegtlin, the developer, was not aware of the flaws and promised to fix the code. However, Gregory Maxwell pointed out that the implementation was leaking data and could result in incorrectly decrypted messages. As a result, Voegtlin decided to remove the encryption methods from the current release and updated the packages.Maxwell informed Voegtlin that the encryption algorithm used in the code was insecure and not actually implementing ECIES. The most significant issue was the use of a trivial 16-bit check value instead of a cryptographically strong MAC. This allowed anyone with access to a decryption oracle to decrypt any message encrypted to a third person by making no more than 65536 queries. Additionally, if a random query yielded a result, it directly revealed the ECDH value. If the implementation did not check if the nonce point was on the curve, the result could yield a point on the twist instead of the curve, making the private key more vulnerable to recovery. Maxwell also noted that there may be other problems or mitigating factors in the code. Voegtlin thanked Maxwell for informing him about the flaws and promised to fix the code.Voegtlin explained that the encryption algorithm used in the Bitcoin wallet was ECIES and the code was borrowed from a repository. However, the cryptosystem used in the repository was insecure and not actually implementing ECIES. The main issue was the use of a trivial 16-bit check value instead of a cryptographically strong MAC. This meant that an arbitrary message encrypted to a third person could be decoded with no more than 65536 queries to a decryption oracle. If a random query yielded a result, it directly revealed the ECDH value. Additionally, if the implementation did not check if the nonce point was on the curve, the result could yield a point on the twist instead of the curve, making the private key more vulnerable to recovery. The implementation also had other issues, such as not using a strong RNG for its EC nonce.Electrum 1.9.8 was released with features initially planned for version 2.0. The Electrum servers were upgraded to version 0.9, allowing the client to request the balance of any address directly. New commands, including getaddressbalance, getaddressunspent, and getutxoaddress, were added. Two commands for message encryption, encrypt and decrypt, were also added using the ECIES encryption algorithm. The key could be obtained using the 'getpubkeys' command. The Qt GUI also had access to these functions. Additionally, command-line commands that required a network connection spawned a daemon, making scripting more efficient. Packages for download were available on https://electrum.org/download.html, and binaries for Windows and Mac would be available soon. 2014-03-16T15:48:21+00:00 + In an email exchange on March 16, 2014, it was revealed that there were problems with the encryption methods in the current release of a software. Thomas Voegtlin, the developer, was not aware of the flaws and promised to fix the code. However, Gregory Maxwell pointed out that the implementation was leaking data and could result in incorrectly decrypted messages. As a result, Voegtlin decided to remove the encryption methods from the current release and updated the packages.Maxwell informed Voegtlin that the encryption algorithm used in the code was insecure and not actually implementing ECIES. The most significant issue was the use of a trivial 16-bit check value instead of a cryptographically strong MAC. This allowed anyone with access to a decryption oracle to decrypt any message encrypted to a third person by making no more than 65536 queries. Additionally, if a random query yielded a result, it directly revealed the ECDH value. If the implementation did not check if the nonce point was on the curve, the result could yield a point on the twist instead of the curve, making the private key more vulnerable to recovery. Maxwell also noted that there may be other problems or mitigating factors in the code. Voegtlin thanked Maxwell for informing him about the flaws and promised to fix the code.Voegtlin explained that the encryption algorithm used in the Bitcoin wallet was ECIES and the code was borrowed from a repository. However, the cryptosystem used in the repository was insecure and not actually implementing ECIES. The main issue was the use of a trivial 16-bit check value instead of a cryptographically strong MAC. This meant that an arbitrary message encrypted to a third person could be decoded with no more than 65536 queries to a decryption oracle. If a random query yielded a result, it directly revealed the ECDH value. Additionally, if the implementation did not check if the nonce point was on the curve, the result could yield a point on the twist instead of the curve, making the private key more vulnerable to recovery. The implementation also had other issues, such as not using a strong RNG for its EC nonce.Electrum 1.9.8 was released with features initially planned for version 2.0. The Electrum servers were upgraded to version 0.9, allowing the client to request the balance of any address directly. New commands, including getaddressbalance, getaddressunspent, and getutxoaddress, were added. Two commands for message encryption, encrypt and decrypt, were also added using the ECIES encryption algorithm. The key could be obtained using the 'getpubkeys' command. The Qt GUI also had access to these functions. Additionally, command-line commands that required a network connection spawned a daemon, making scripting more efficient. Packages for download were available on https://electrum.org/download.html, and binaries for Windows and Mac would be available soon. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_External-IP-Address.xml b/static/bitcoin-dev/March_2014/combined_External-IP-Address.xml index bcf6b94fb6..619f9c39a1 100644 --- a/static/bitcoin-dev/March_2014/combined_External-IP-Address.xml +++ b/static/bitcoin-dev/March_2014/combined_External-IP-Address.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - External IP Address - 2023-08-01T07:58:23.245906+00:00 + 2025-10-11T21:33:55.514402+00:00 + python-feedgen Wladimir 2014-03-16 10:22:25+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - External IP Address - 2023-08-01T07:58:23.245906+00:00 + 2025-10-11T21:33:55.514568+00:00 - In an email conversation, Sam suggests checking X-Client-Update to see if the check-in was logged. He mentions that errors are trapped and the IP address is always displayed in the headers. However, Wladimir replies that the current plan is to phase out centralized external services and instead use peer-based address detection. He provides a link to a Github page for Bitcoin where more information can be found.The author of the message discovered a function called GetMyExternalIP() in net.cpp for a small project and realized that the current method being used needed to be phased out. As a result, they created a website called ip.bitcheck.us which captures the IP, user agent, and time for analysis and sends that information when clients visit the site. The site quickly searches for "Mozilla" in the user agent to redirect browsers that visit there.The information sent includes GET / HTTP/1.1, Host: ip.bitcheck.us, User-Agent: /Satoshi:0.8.6/, Connection: close. On the other hand, the received data includes HTTP/1.1 200 OK, Date: Sun, 16 Mar 2014 05:31:51 GMT, Server: Apache mod_fcgid/2.3.10-dev, X-Powered-By: Satoshi v1.0, X-Client-Update: yes, Content-Length: 9, Connection: close, Content-Type: text/html, and 127.0.0.1.The author explains that errors are trapped so that the IP address will always display, and any error information is contained in the headers. 2014-03-16T10:22:25+00:00 + In an email conversation, Sam suggests checking X-Client-Update to see if the check-in was logged. He mentions that errors are trapped and the IP address is always displayed in the headers. However, Wladimir replies that the current plan is to phase out centralized external services and instead use peer-based address detection. He provides a link to a Github page for Bitcoin where more information can be found.The author of the message discovered a function called GetMyExternalIP() in net.cpp for a small project and realized that the current method being used needed to be phased out. As a result, they created a website called ip.bitcheck.us which captures the IP, user agent, and time for analysis and sends that information when clients visit the site. The site quickly searches for "Mozilla" in the user agent to redirect browsers that visit there.The information sent includes GET / HTTP/1.1, Host: ip.bitcheck.us, User-Agent: /Satoshi:0.8.6/, Connection: close. On the other hand, the received data includes HTTP/1.1 200 OK, Date: Sun, 16 Mar 2014 05:31:51 GMT, Server: Apache mod_fcgid/2.3.10-dev, X-Powered-By: Satoshi v1.0, X-Client-Update: yes, Content-Length: 9, Connection: close, Content-Type: text/html, and 127.0.0.1.The author explains that errors are trapped so that the IP address will always display, and any error information is contained in the headers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Fake-PGP-key-for-Gavin.xml b/static/bitcoin-dev/March_2014/combined_Fake-PGP-key-for-Gavin.xml index add9d72e08..dcbda9ea45 100644 --- a/static/bitcoin-dev/March_2014/combined_Fake-PGP-key-for-Gavin.xml +++ b/static/bitcoin-dev/March_2014/combined_Fake-PGP-key-for-Gavin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fake PGP key for Gavin - 2023-08-01T08:01:05.706584+00:00 + 2025-10-11T21:34:48.625853+00:00 + python-feedgen The Doctor 2014-03-24 19:44:24+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Fake PGP key for Gavin - 2023-08-01T08:01:05.706584+00:00 + 2025-10-11T21:34:48.626001+00:00 - On March 22, 2014, a warning was issued regarding the creation of fake PGP keys to sign popular crypto software. This practice could potentially be used to make a MITM attack appear more legitimate, possibly by an intelligence agency. Users were advised to exercise caution and ensure they are using the correct key when verifying Bitcoin downloads. It was suggested that these fake PGP keys may be the result of corporate industrial espionage or organized crime outfits, rather than intelligence agencies. The latter would likely use compromised X509, network cards, or binary code blobs instead. It was further noted that it is unlikely for an intelligence agency to have an interest in Bitcoin, as they can easily intercept ASIC miners.In response to the difficulty in finding keys initially, a user created a documentation site, which is now outdated. However, Gavin Andresen's GPG key can be found through a Google search. Despite this, users expressed gratitude for any signing that has been done and took the responsibility to verify it themselves.The blog post also mentioned the importance of checking if the correct key is being used when using PGP to verify Bitcoin downloads. It emphasized that Bitcoin source and binary downloads are protected by both the PGP Web of Trust (WoT) and the certificate authority PKI system. The binaries are hosted on bitcoin.org, which is https and protected by the PKI system, while the source code is hosted on GitHub, again, https protected. To execute a MITM attack, the PKI system would need to be compromised, assuming users do not download over http.Additionally, there was a discussion about whether the Windows binaries should be codesigned. It was confirmed that the -setup.exe installers are Authenticode signed, also known as Microsoft code-signing. It was suggested that signing the Windows binaries would be a good idea, as antivirus scanners learn key reputations to reduce false positives. However, Linux does not support X.509 code signing, so extra signing would not be possible in that case.Overall, the warning about fake PGP keys highlights the need for users to be vigilant and verify the authenticity of their downloads. 2014-03-24T19:44:24+00:00 + On March 22, 2014, a warning was issued regarding the creation of fake PGP keys to sign popular crypto software. This practice could potentially be used to make a MITM attack appear more legitimate, possibly by an intelligence agency. Users were advised to exercise caution and ensure they are using the correct key when verifying Bitcoin downloads. It was suggested that these fake PGP keys may be the result of corporate industrial espionage or organized crime outfits, rather than intelligence agencies. The latter would likely use compromised X509, network cards, or binary code blobs instead. It was further noted that it is unlikely for an intelligence agency to have an interest in Bitcoin, as they can easily intercept ASIC miners.In response to the difficulty in finding keys initially, a user created a documentation site, which is now outdated. However, Gavin Andresen's GPG key can be found through a Google search. Despite this, users expressed gratitude for any signing that has been done and took the responsibility to verify it themselves.The blog post also mentioned the importance of checking if the correct key is being used when using PGP to verify Bitcoin downloads. It emphasized that Bitcoin source and binary downloads are protected by both the PGP Web of Trust (WoT) and the certificate authority PKI system. The binaries are hosted on bitcoin.org, which is https and protected by the PKI system, while the source code is hosted on GitHub, again, https protected. To execute a MITM attack, the PKI system would need to be compromised, assuming users do not download over http.Additionally, there was a discussion about whether the Windows binaries should be codesigned. It was confirmed that the -setup.exe installers are Authenticode signed, also known as Microsoft code-signing. It was suggested that signing the Windows binaries would be a good idea, as antivirus scanners learn key reputations to reduce false positives. However, Linux does not support X.509 code signing, so extra signing would not be possible in that case.Overall, the warning about fake PGP keys highlights the need for users to be vigilant and verify the authenticity of their downloads. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_HEADS-UP-Bitcoin-0-9-0-doesn-t-work-on-old-Linux.xml b/static/bitcoin-dev/March_2014/combined_HEADS-UP-Bitcoin-0-9-0-doesn-t-work-on-old-Linux.xml index c2b42c9d41..6ce8a604cd 100644 --- a/static/bitcoin-dev/March_2014/combined_HEADS-UP-Bitcoin-0-9-0-doesn-t-work-on-old-Linux.xml +++ b/static/bitcoin-dev/March_2014/combined_HEADS-UP-Bitcoin-0-9-0-doesn-t-work-on-old-Linux.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - HEADS UP: Bitcoin 0.9.0 doesn't work on old Linux - 2023-08-01T07:59:30.843593+00:00 + 2025-10-11T21:34:40.131623+00:00 + python-feedgen Wladimir 2014-03-19 18:57:47+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - HEADS UP: Bitcoin 0.9.0 doesn't work on old Linux - 2023-08-01T07:59:30.843593+00:00 + 2025-10-11T21:34:40.131789+00:00 - A user named Jesus Cea encountered an issue after upgrading to Bitcoin 0.9.0 on March 19, 2014. The problem arose when attempting to run the program, resulting in an error message stating that versions `GLIBC_2.15' and `GLIBC_2.14' were required but not found. This known problem can be found on Github under issue number 3803.The user's specific error message appears when trying to execute the bitcoind and bitcoin-qt commands. It indicates that the required versions of GLIBC (GLIBC_2.15 and GLIBC_2.14) are missing from the system's /lib/libc.so.6 directory. It is important to note that the user is running Red Hat Enterprise Linux, which utilizes glibc 2.12.In the email signature provided by Jesús Cea Avión, contact information is included along with a quote from Leibniz about love. Additionally, a digital signature attachment is present.Overall, this issue involves a user experiencing errors while running Bitcoin 0.9.0 due to missing required versions of GLIBC on their Red Hat Enterprise Linux system. 2014-03-19T18:57:47+00:00 + A user named Jesus Cea encountered an issue after upgrading to Bitcoin 0.9.0 on March 19, 2014. The problem arose when attempting to run the program, resulting in an error message stating that versions `GLIBC_2.15' and `GLIBC_2.14' were required but not found. This known problem can be found on Github under issue number 3803.The user's specific error message appears when trying to execute the bitcoind and bitcoin-qt commands. It indicates that the required versions of GLIBC (GLIBC_2.15 and GLIBC_2.14) are missing from the system's /lib/libc.so.6 directory. It is important to note that the user is running Red Hat Enterprise Linux, which utilizes glibc 2.12.In the email signature provided by Jesús Cea Avión, contact information is included along with a quote from Leibniz about love. Additionally, a digital signature attachment is present.Overall, this issue involves a user experiencing errors while running Bitcoin 0.9.0 due to missing required versions of GLIBC on their Red Hat Enterprise Linux system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Handling-miner-adoption-gracefully-for-embedded-consensus-systems-via-double-spending-replace-by-fee.xml b/static/bitcoin-dev/March_2014/combined_Handling-miner-adoption-gracefully-for-embedded-consensus-systems-via-double-spending-replace-by-fee.xml index 11c3391cd1..efa015114c 100644 --- a/static/bitcoin-dev/March_2014/combined_Handling-miner-adoption-gracefully-for-embedded-consensus-systems-via-double-spending-replace-by-fee.xml +++ b/static/bitcoin-dev/March_2014/combined_Handling-miner-adoption-gracefully-for-embedded-consensus-systems-via-double-spending-replace-by-fee.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee - 2023-08-01T08:00:46.488880+00:00 + 2025-10-11T21:34:01.893793+00:00 + python-feedgen kjj 2014-03-26 01:09:01+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee - 2023-08-01T08:00:46.488880+00:00 + 2025-10-11T21:34:01.893959+00:00 - In a recent discussion, blockchain technology expert Peter Todd raised concerns about the reduction of OP_RETURN length to 40 bytes before the release of Bitcoin 0.9. He pointed out a security flaw regarding OP_CHECKMULTISIG sigops that were not taken into account, which could lead to unminable transactions and mempool bloat. Todd suggested getting rid of bare OP_CHECKMULTISIG outputs, as this only affects Counterparty at present.In response to Todd's concerns, Troy Benjegerdes proposed creating a new coin with an explicit 'data' field of around 169 bytes, adding 1 byte to each transaction if unused. This alternative is considered more viable than various hacks to overcome the 40-byte limit in Bitcoin. The discussion concluded by urging the Bitcoin 1% to assess the market risk associated with the 40-byte limit and consider implementing some of Todd's proposed alternatives.Todd also spent time examining the Datacoin code and concluded that his next copycatcoin would have an explicit "data" field of around 169 bytes. This addition would provide a small data field for proof of publication while adding one byte to each transaction if unused. He believed this approach would create a more reliable infrastructure for proof of publication compared to existing workarounds for Bitcoin's 40 byte limit.During the discussion, Todd expressed his concern about miners accepting transactions with longer data than specified as standard. He argued that non-validated proof of publication would become costly in the long run as it competes with transactions that actually use the utxo feature. However, he opposed any limitation on OP_RETURN at the protocol level, except for the block size limit itself. He suggested different and configurable mining policies to improve modularity, noting that these methods come with additional overhead compared to using OP_RETURN.Todd emphasized the importance of proof-of-publication and suggested that miners should support it. He argued that embedding within Bitcoin provides greater security compared to operating alongside it. He used Twister as an example, highlighting the switch to a centralized checkpointing scheme when utilizing a separate PoW blockchain or a merge-mined one. While acknowledging the censorship risk of going the embedded route, Todd pointed out that explicit blacklists would be required. He emphasized that the "proof of publication vs separate chain" discussion is separate from the "merged mining vs independent chain" debate.In conclusion, Todd's concerns about the reduction of OP_RETURN length and his suggestions for improving proof-of-publication highlight the need for careful consideration and implementation within the Bitcoin ecosystem. 2014-03-26T01:09:01+00:00 + In a recent discussion, blockchain technology expert Peter Todd raised concerns about the reduction of OP_RETURN length to 40 bytes before the release of Bitcoin 0.9. He pointed out a security flaw regarding OP_CHECKMULTISIG sigops that were not taken into account, which could lead to unminable transactions and mempool bloat. Todd suggested getting rid of bare OP_CHECKMULTISIG outputs, as this only affects Counterparty at present.In response to Todd's concerns, Troy Benjegerdes proposed creating a new coin with an explicit 'data' field of around 169 bytes, adding 1 byte to each transaction if unused. This alternative is considered more viable than various hacks to overcome the 40-byte limit in Bitcoin. The discussion concluded by urging the Bitcoin 1% to assess the market risk associated with the 40-byte limit and consider implementing some of Todd's proposed alternatives.Todd also spent time examining the Datacoin code and concluded that his next copycatcoin would have an explicit "data" field of around 169 bytes. This addition would provide a small data field for proof of publication while adding one byte to each transaction if unused. He believed this approach would create a more reliable infrastructure for proof of publication compared to existing workarounds for Bitcoin's 40 byte limit.During the discussion, Todd expressed his concern about miners accepting transactions with longer data than specified as standard. He argued that non-validated proof of publication would become costly in the long run as it competes with transactions that actually use the utxo feature. However, he opposed any limitation on OP_RETURN at the protocol level, except for the block size limit itself. He suggested different and configurable mining policies to improve modularity, noting that these methods come with additional overhead compared to using OP_RETURN.Todd emphasized the importance of proof-of-publication and suggested that miners should support it. He argued that embedding within Bitcoin provides greater security compared to operating alongside it. He used Twister as an example, highlighting the switch to a centralized checkpointing scheme when utilizing a separate PoW blockchain or a merge-mined one. While acknowledging the censorship risk of going the embedded route, Todd pointed out that explicit blacklists would be required. He emphasized that the "proof of publication vs separate chain" discussion is separate from the "merged mining vs independent chain" debate.In conclusion, Todd's concerns about the reduction of OP_RETURN length and his suggestions for improving proof-of-publication highlight the need for careful consideration and implementation within the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Instant-contactless-payments-IsoDep.xml b/static/bitcoin-dev/March_2014/combined_Instant-contactless-payments-IsoDep.xml index 3563298b9d..34f04f1b83 100644 --- a/static/bitcoin-dev/March_2014/combined_Instant-contactless-payments-IsoDep.xml +++ b/static/bitcoin-dev/March_2014/combined_Instant-contactless-payments-IsoDep.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Instant / contactless payments, IsoDep - 2023-08-01T07:52:06.351074+00:00 + 2025-10-11T21:34:16.752711+00:00 + python-feedgen Andreas Schildbach 2014-03-07 08:45:43+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Instant / contactless payments, IsoDep - 2023-08-01T07:52:06.352120+00:00 + 2025-10-11T21:34:16.752893+00:00 - In a June 3, 2014 email exchange, Mike Hearn and Andreas Schildbach discuss the potential use of the IsoDep protocol with NFC tags to authorize Bitcoin transactions on Android devices. The main concern is that the connection may break when the phone is picked up, so fallback options such as HTTPS or Bluetooth may be necessary. One idea suggested is to dispatch different IsoDep applications to different apps, but a challenge arises in avoiding conflicts between apps fighting for access to IsoDep endpoints, as there is currently no mime type or similar concept to prevent this. Another suggestion is to have a NDEF tag trigger the app, which would then initiate an IsoDep protocol. However, Mike expresses uncertainty about whether this is possible using the Android API. The email thread concludes with advertisements for Perforce, a tool that claims to provide hassle-free workflows and faster operations for version control. Additionally, a link to the Bitcoin-development mailing list is included for further information. 2014-03-07T08:45:43+00:00 + In a June 3, 2014 email exchange, Mike Hearn and Andreas Schildbach discuss the potential use of the IsoDep protocol with NFC tags to authorize Bitcoin transactions on Android devices. The main concern is that the connection may break when the phone is picked up, so fallback options such as HTTPS or Bluetooth may be necessary. One idea suggested is to dispatch different IsoDep applications to different apps, but a challenge arises in avoiding conflicts between apps fighting for access to IsoDep endpoints, as there is currently no mime type or similar concept to prevent this. Another suggestion is to have a NDEF tag trigger the app, which would then initiate an IsoDep protocol. However, Mike expresses uncertainty about whether this is possible using the Android API. The email thread concludes with advertisements for Perforce, a tool that claims to provide hassle-free workflows and faster operations for version control. Additionally, a link to the Bitcoin-development mailing list is included for further information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Instant-contactless-payments.xml b/static/bitcoin-dev/March_2014/combined_Instant-contactless-payments.xml index e76f18f15b..e537804108 100644 --- a/static/bitcoin-dev/March_2014/combined_Instant-contactless-payments.xml +++ b/static/bitcoin-dev/March_2014/combined_Instant-contactless-payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Instant / contactless payments - 2023-08-01T07:51:56.178373+00:00 + 2025-10-11T21:35:18.514826+00:00 + python-feedgen Alex Kotenko 2014-03-10 19:47:55+00:00 @@ -127,13 +128,13 @@ - python-feedgen + 2 Combined summary - Instant / contactless payments - 2023-08-01T07:51:56.179389+00:00 + 2025-10-11T21:35:18.515033+00:00 - In the given context, several discussions and email exchanges are explored regarding various aspects of Bitcoin technology and its potential applications. One topic discussed is the implementation of Bluetooth and NFC technology in wallets and point-of-sale (POS) systems. It is mentioned that supporting Bluetooth is optional but recommended, with an emphasis on the need to support all major wallets. The discussion also highlights the importance of hardware/software support and a polished user experience for Bluetooth integration. Additionally, the concept of generating PDF receipts and sending them via NFC is proposed to avoid an additional tap during payment, and the BIP70 payment protocol is suggested as a potential solution.Another email exchange focuses on the idea of using a self-signed certificate or HD wallet root as a means of gaining reputation within the Bitcoin ecosystem. The use of ECDSA signatures and a distributed store of signed messages is discussed as a way to establish a reputation score, with the aim of allowing any user to contribute to their reputation without requiring additional knowledge or infrastructure.The topic of transaction fees and their potential equilibrium is also addressed. It is suggested that with the update to Bitcoin v0.9, transaction fees will become floating and reflect real-world value. However, it is acknowledged that fees may fluctuate depending on system load. The concept of a stable currency, which gradually increases in value along with economic growth, is also mentioned, with the proposal of a fake currency backed by a basket of goods to maintain price stability.Furthermore, there are discussions on the use of iso-dep protocols for payment systems via cell phones and the challenges associated with it. Issues such as connection breaks when the phone is picked up and the risk analysis of memo fields are raised, along with suggestions for alternative methods such as HTTPS or Bluetooth. The importance of optimizing the payment process for speed and user experience is emphasized, with examples given of long wait times and excessive tracking experienced with existing payment systems.The context also mentions the possibility of integrating Bitcoin support into contactless payment systems, such as London's Oyster card system, without requiring hardware replacements. The aim is to make the payment process more intuitive and seamless, similar to other contactless payment methods.Overall, the discussions and exchanges in the context highlight various considerations and ideas for improving the usability, security, and integration of Bitcoin technology into existing payment systems. The importance of user experience, hardware/software support, and maintaining a consistent and intuitive payment process are recurring themes throughout the discussions. 2014-03-10T19:47:55+00:00 + In the given context, several discussions and email exchanges are explored regarding various aspects of Bitcoin technology and its potential applications. One topic discussed is the implementation of Bluetooth and NFC technology in wallets and point-of-sale (POS) systems. It is mentioned that supporting Bluetooth is optional but recommended, with an emphasis on the need to support all major wallets. The discussion also highlights the importance of hardware/software support and a polished user experience for Bluetooth integration. Additionally, the concept of generating PDF receipts and sending them via NFC is proposed to avoid an additional tap during payment, and the BIP70 payment protocol is suggested as a potential solution.Another email exchange focuses on the idea of using a self-signed certificate or HD wallet root as a means of gaining reputation within the Bitcoin ecosystem. The use of ECDSA signatures and a distributed store of signed messages is discussed as a way to establish a reputation score, with the aim of allowing any user to contribute to their reputation without requiring additional knowledge or infrastructure.The topic of transaction fees and their potential equilibrium is also addressed. It is suggested that with the update to Bitcoin v0.9, transaction fees will become floating and reflect real-world value. However, it is acknowledged that fees may fluctuate depending on system load. The concept of a stable currency, which gradually increases in value along with economic growth, is also mentioned, with the proposal of a fake currency backed by a basket of goods to maintain price stability.Furthermore, there are discussions on the use of iso-dep protocols for payment systems via cell phones and the challenges associated with it. Issues such as connection breaks when the phone is picked up and the risk analysis of memo fields are raised, along with suggestions for alternative methods such as HTTPS or Bluetooth. The importance of optimizing the payment process for speed and user experience is emphasized, with examples given of long wait times and excessive tracking experienced with existing payment systems.The context also mentions the possibility of integrating Bitcoin support into contactless payment systems, such as London's Oyster card system, without requiring hardware replacements. The aim is to make the payment process more intuitive and seamless, similar to other contactless payment methods.Overall, the discussions and exchanges in the context highlight various considerations and ideas for improving the usability, security, and integration of Bitcoin technology into existing payment systems. The importance of user experience, hardware/software support, and maintaining a consistent and intuitive payment process are recurring themes throughout the discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Is-this-a-safe-thing-to-be-doing-with-ECC-addition-Oracle-protocol-.xml b/static/bitcoin-dev/March_2014/combined_Is-this-a-safe-thing-to-be-doing-with-ECC-addition-Oracle-protocol-.xml index 224324d687..76e795ed62 100644 --- a/static/bitcoin-dev/March_2014/combined_Is-this-a-safe-thing-to-be-doing-with-ECC-addition-Oracle-protocol-.xml +++ b/static/bitcoin-dev/March_2014/combined_Is-this-a-safe-thing-to-be-doing-with-ECC-addition-Oracle-protocol-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Is this a safe thing to be doing with ECC addition? (Oracle protocol) - 2023-08-01T07:48:50.198458+00:00 + 2025-10-11T21:34:04.016178+00:00 + python-feedgen Alan Reiner 2014-03-08 23:13:10+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Is this a safe thing to be doing with ECC addition? (Oracle protocol) - 2023-08-01T07:48:50.198458+00:00 + 2025-10-11T21:34:04.016322+00:00 - The email thread discusses the security of public key exchange, specifically in the context of EC Diffie-Hellman. It is mentioned that EC point addition is insecure because it is invertible, while EC-scalar multiplication is not. This is why EC Diffie-Hellman is secure even with timing asymmetry. Alan Reiner suggests creating a new keypair and giving the other party minus the public key, which can only be detected after the private key has been abused. To avoid this situation, parties should exchange their public keys before combining them.The conversation also explores limitations of ECDSA and alternatives for creating a signature with a + b. It is noted that Schnorr signatures can achieve this, but the k^-1 term in ECDSA makes direct multiparty signatures difficult. The idea of using a hash of the other party's public key as a means of ensuring integrity is discussed, with Joel Kaartinen suggesting that both parties insist on seeing a hash of the other party's public key before sharing their own.In another thread on the Bitcoin-development mailing list, participants discuss the issue of ensuring public key integrity. One suggestion is for parties to insist on seeing a hash of the other party's public key before sharing their own. The use of multisig is also proposed as an alternative solution. Edmund Edgar recommends exchanging public keys before combining them to avoid potential abuse.On March 8, 2014, Alan Reiner mentions creating a new key pair and sharing only the minus version with others. He explains that even without knowing his private key, someone can still abuse it. Edmund Edgar suggests the exchange of public keys before combining them to prevent such situations. Edmund Edgar is associated with Social Minds Inc and Reality Keys.Edmund Edgar presents a scenario where he gives Odinn Cyberguerrilla an ECC public key and receives back a public key of Odinn's own devising. He then pays money to the address resulting from add_pubkeys(). Edgar asks if anyone can think of a way for Odinn to spend the money without having the private key. Alan Reiner responds by presenting a scenario where he sees Odinn's public key before creating and sending his own. He creates a new keypair with an arbitrary value for c_priv and gives Odinn c_pub = G * (c_priv - b_priv). Since Alan knows b_priv, he can calculate c_pub - b_pub = G * (c_priv - b_priv + a_priv), where a_priv is his secret key. He then spends the money using the private key for c_pub - b_pub. Odinn can only detect the fraud after it's too late.On March 4th, 2014, Odinn Cyberguerrilla states that "nothing is safe." Edmund Edgar poses a question about the safety of a transaction involving ECC public keys and asks if anyone can think of a way for Odinn to spend the money without having the necessary key. Edgar is associated with Social Minds Inc and Reality Keys.Edmund Edgar introduces a new m-of-n contract implementation based on Reality Keys. This implementation uses the Reality Keys service as an External State Oracle and allows registration of possible outcomes with public keys for "yes" and "no". The winner receives the appropriate private key from Reality Keys to release the funds. Peter Todd suggests an effective way to use these keys for m-of-n contracts. Edgar combines the public key of each party with the public key of the outcome they're representing into one address spendable by either Alice or Bob after the outcome occurs. However, he expresses concern that Bob could intentionally weaken the resulting public key to sign a transaction without needing to know the private key. The example script is available on GitHub and feedback on its safety is welcome.Edmund Edgar discusses a new way of using Reality Keys to make m-of-n contracts. Reality Keys acts as an External State Oracle and allows registration of possible outcomes with public keys for "yes" and "no". Edmund Edgar combines the public key of each party with the public key of the outcome they're representing to create a public key that goes into a 1/2 P2SH address. This address is spendable by one of Alice or Bob after the outcome occurs. He expresses concern about the security of this approach and welcomes feedback from those who understand it. The code for this approach is available on GitHub and Edmund Edgar believes it could have implications for other protocols. 2014-03-08T23:13:10+00:00 + The email thread discusses the security of public key exchange, specifically in the context of EC Diffie-Hellman. It is mentioned that EC point addition is insecure because it is invertible, while EC-scalar multiplication is not. This is why EC Diffie-Hellman is secure even with timing asymmetry. Alan Reiner suggests creating a new keypair and giving the other party minus the public key, which can only be detected after the private key has been abused. To avoid this situation, parties should exchange their public keys before combining them.The conversation also explores limitations of ECDSA and alternatives for creating a signature with a + b. It is noted that Schnorr signatures can achieve this, but the k^-1 term in ECDSA makes direct multiparty signatures difficult. The idea of using a hash of the other party's public key as a means of ensuring integrity is discussed, with Joel Kaartinen suggesting that both parties insist on seeing a hash of the other party's public key before sharing their own.In another thread on the Bitcoin-development mailing list, participants discuss the issue of ensuring public key integrity. One suggestion is for parties to insist on seeing a hash of the other party's public key before sharing their own. The use of multisig is also proposed as an alternative solution. Edmund Edgar recommends exchanging public keys before combining them to avoid potential abuse.On March 8, 2014, Alan Reiner mentions creating a new key pair and sharing only the minus version with others. He explains that even without knowing his private key, someone can still abuse it. Edmund Edgar suggests the exchange of public keys before combining them to prevent such situations. Edmund Edgar is associated with Social Minds Inc and Reality Keys.Edmund Edgar presents a scenario where he gives Odinn Cyberguerrilla an ECC public key and receives back a public key of Odinn's own devising. He then pays money to the address resulting from add_pubkeys(). Edgar asks if anyone can think of a way for Odinn to spend the money without having the private key. Alan Reiner responds by presenting a scenario where he sees Odinn's public key before creating and sending his own. He creates a new keypair with an arbitrary value for c_priv and gives Odinn c_pub = G * (c_priv - b_priv). Since Alan knows b_priv, he can calculate c_pub - b_pub = G * (c_priv - b_priv + a_priv), where a_priv is his secret key. He then spends the money using the private key for c_pub - b_pub. Odinn can only detect the fraud after it's too late.On March 4th, 2014, Odinn Cyberguerrilla states that "nothing is safe." Edmund Edgar poses a question about the safety of a transaction involving ECC public keys and asks if anyone can think of a way for Odinn to spend the money without having the necessary key. Edgar is associated with Social Minds Inc and Reality Keys.Edmund Edgar introduces a new m-of-n contract implementation based on Reality Keys. This implementation uses the Reality Keys service as an External State Oracle and allows registration of possible outcomes with public keys for "yes" and "no". The winner receives the appropriate private key from Reality Keys to release the funds. Peter Todd suggests an effective way to use these keys for m-of-n contracts. Edgar combines the public key of each party with the public key of the outcome they're representing into one address spendable by either Alice or Bob after the outcome occurs. However, he expresses concern that Bob could intentionally weaken the resulting public key to sign a transaction without needing to know the private key. The example script is available on GitHub and feedback on its safety is welcome.Edmund Edgar discusses a new way of using Reality Keys to make m-of-n contracts. Reality Keys acts as an External State Oracle and allows registration of possible outcomes with public keys for "yes" and "no". Edmund Edgar combines the public key of each party with the public key of the outcome they're representing to create a public key that goes into a 1/2 P2SH address. This address is spendable by one of Alice or Bob after the outcome occurs. He expresses concern about the security of this approach and welcomes feedback from those who understand it. The code for this approach is available on GitHub and Edmund Edgar believes it could have implications for other protocols. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Multisign-payment-protocol-.xml b/static/bitcoin-dev/March_2014/combined_Multisign-payment-protocol-.xml index 6d461f5b02..547c4064f2 100644 --- a/static/bitcoin-dev/March_2014/combined_Multisign-payment-protocol-.xml +++ b/static/bitcoin-dev/March_2014/combined_Multisign-payment-protocol-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Multisign payment protocol? - 2023-08-01T07:54:17.445173+00:00 + 2025-10-11T21:33:53.391041+00:00 + python-feedgen Jeff Garzik 2014-03-12 16:57:28+00:00 @@ -143,13 +144,13 @@ - python-feedgen + 2 Combined summary - Multisign payment protocol? - 2023-08-01T07:54:17.447169+00:00 + 2025-10-11T21:33:53.391250+00:00 - In an email exchange on March 12, 2014, Bitcoin core developers Mike Hearn and Jeff Garzik raised concerns about the handling of partially signed and multisig transactions within bitcoind. They discussed how the raw transaction API does not adjust fees if the signature pushes the transaction to a higher fee level, which could cause issues for app developers relying on this functionality. They also mentioned a proposed raw transaction API call by developer sipa that would automatically calculate fees and other details.The conversation highlighted the need for careful documentation of this aspect of the raw transaction API and suggested that the raw transaction API and Bitcoin Core wallet should not be used to hold customer funds. It was emphasized that SPV is not secure enough for businesses unless they run their own full node, and users should consider using Bitcoinj or something else instead of the raw transaction API.To avoid problems with fees, it was suggested that developers may need to implement a fee loop in their own apps, where they create a transaction with an estimated fee level, add signatures, and submit. If the transaction is rejected for low fees, they would need to increment and try again until successful.The discussion also covered the calculation of transaction size for partially signed transactions and the use of placeholders in transaction scripts to avoid miscalculating the fee based on the final size.CoinVault's use of a partially signed transaction format was mentioned, and it was suggested to use placeholders in the transaction scripts as bitcoinj does to avoid miscalculating the fee based on the final size.The importance of planning and specifying the user experience for fully interoperable "multisig" implementations was highlighted. It was suggested to design the UI in terms of people with social network integration and to avoid exposing end users to the concept of a key for a "group account for an organization".Different companies and developers were mentioned in relation to their plans and implementations regarding HD wallets and multisig transactions. Armory plans to introduce a wallet "bundle" that includes all wallets protected by the same backup, while Jean-Pierre Rupp is working on using BIP-0032 HD wallets for his multisig system. The haskoin-wallet supports regular and multisig accounts and uses synced trees rooted at the extended pubkeys of participants.The discussion also touched on the practicality of implementing a wallet that uses stealth addresses for change and the ongoing work towards the adoption of HD wallets in the Bitcoin community. Many popular end user wallets are expected to support HD wallets soon.The release of bip32 features in Electrum was postponed due to ongoing discussions with Trezor and bitcoinj developers. MultiBit plans to release HD code within two months, and Hive and Haskoin are also committed to HD. However, it was noted that building anything on top of HD is premature until major user wallets and bitcoind have basic support.The context argues that the current state of HD in Bitcoin is overhyped without any code to back it up. It suggests that it is premature to build anything on top of HD until major user wallets and bitcoind have basic support. The Waiting For Godot situation is mentioned, including examples of Bitcoin Wallet failing to rotate addresses and a stalled attempt to add a simple RPC.In another email exchange, Gavin Andresen and Jeff Garzik discuss the assumption of HD wallets in multisig transactions. They disagree on assuming HD capability, with Garzik stating that current multisig wallets don't match this assumption and there is a lack of infrastructure for HD. However, Andresen suggests that if a remote party is involved in a multisig and speaks the necessary protocols, it is reasonable to assume they are HD-capable. The conversation emphasizes the need to do multisig correctly from the beginning and discusses the challenges and potential benefits of using HD wallets.Another email exchange between Garzik and Drak explores the idea of assuming each party in a transaction uses HD wallets. Drak supports this idea as it simplifies things, but Garzik points out that it assumes a different reality from the current one. They agree that transitioning to multisig wallets requires careful consideration and proper protocols.The discussion also covers the establishment of multisig wallets, gathering signatures for multisig spends, and leaving a multisig wallet. It is suggested that BIP32 HD public keys should be used to ensure privacy from the beginning of establishing multisig wallets. Different protocols may be needed for multi-person shared wallets, escrows, and "wallet protection service" wallets. The gathering of signatures could utilize the PaymentRequest message and a partially-signed Payment message. There may also be a need for a protocol to leave a multisig wallet.The feasibility of using BIP10 for multisig and coinjoin is discussed, with Alan Reiner expressing his opinion on the deficiencies of BIP10 and suggesting building something new that is flexible and extensible. Gavin Andresen shares his experience with standardization and suggests that multisig wallets are still in the early stages of development. A suggestion is 2014-03-12T16:57:28+00:00 + In an email exchange on March 12, 2014, Bitcoin core developers Mike Hearn and Jeff Garzik raised concerns about the handling of partially signed and multisig transactions within bitcoind. They discussed how the raw transaction API does not adjust fees if the signature pushes the transaction to a higher fee level, which could cause issues for app developers relying on this functionality. They also mentioned a proposed raw transaction API call by developer sipa that would automatically calculate fees and other details.The conversation highlighted the need for careful documentation of this aspect of the raw transaction API and suggested that the raw transaction API and Bitcoin Core wallet should not be used to hold customer funds. It was emphasized that SPV is not secure enough for businesses unless they run their own full node, and users should consider using Bitcoinj or something else instead of the raw transaction API.To avoid problems with fees, it was suggested that developers may need to implement a fee loop in their own apps, where they create a transaction with an estimated fee level, add signatures, and submit. If the transaction is rejected for low fees, they would need to increment and try again until successful.The discussion also covered the calculation of transaction size for partially signed transactions and the use of placeholders in transaction scripts to avoid miscalculating the fee based on the final size.CoinVault's use of a partially signed transaction format was mentioned, and it was suggested to use placeholders in the transaction scripts as bitcoinj does to avoid miscalculating the fee based on the final size.The importance of planning and specifying the user experience for fully interoperable "multisig" implementations was highlighted. It was suggested to design the UI in terms of people with social network integration and to avoid exposing end users to the concept of a key for a "group account for an organization".Different companies and developers were mentioned in relation to their plans and implementations regarding HD wallets and multisig transactions. Armory plans to introduce a wallet "bundle" that includes all wallets protected by the same backup, while Jean-Pierre Rupp is working on using BIP-0032 HD wallets for his multisig system. The haskoin-wallet supports regular and multisig accounts and uses synced trees rooted at the extended pubkeys of participants.The discussion also touched on the practicality of implementing a wallet that uses stealth addresses for change and the ongoing work towards the adoption of HD wallets in the Bitcoin community. Many popular end user wallets are expected to support HD wallets soon.The release of bip32 features in Electrum was postponed due to ongoing discussions with Trezor and bitcoinj developers. MultiBit plans to release HD code within two months, and Hive and Haskoin are also committed to HD. However, it was noted that building anything on top of HD is premature until major user wallets and bitcoind have basic support.The context argues that the current state of HD in Bitcoin is overhyped without any code to back it up. It suggests that it is premature to build anything on top of HD until major user wallets and bitcoind have basic support. The Waiting For Godot situation is mentioned, including examples of Bitcoin Wallet failing to rotate addresses and a stalled attempt to add a simple RPC.In another email exchange, Gavin Andresen and Jeff Garzik discuss the assumption of HD wallets in multisig transactions. They disagree on assuming HD capability, with Garzik stating that current multisig wallets don't match this assumption and there is a lack of infrastructure for HD. However, Andresen suggests that if a remote party is involved in a multisig and speaks the necessary protocols, it is reasonable to assume they are HD-capable. The conversation emphasizes the need to do multisig correctly from the beginning and discusses the challenges and potential benefits of using HD wallets.Another email exchange between Garzik and Drak explores the idea of assuming each party in a transaction uses HD wallets. Drak supports this idea as it simplifies things, but Garzik points out that it assumes a different reality from the current one. They agree that transitioning to multisig wallets requires careful consideration and proper protocols.The discussion also covers the establishment of multisig wallets, gathering signatures for multisig spends, and leaving a multisig wallet. It is suggested that BIP32 HD public keys should be used to ensure privacy from the beginning of establishing multisig wallets. Different protocols may be needed for multi-person shared wallets, escrows, and "wallet protection service" wallets. The gathering of signatures could utilize the PaymentRequest message and a partially-signed Payment message. There may also be a need for a protocol to leave a multisig wallet.The feasibility of using BIP10 for multisig and coinjoin is discussed, with Alan Reiner expressing his opinion on the deficiencies of BIP10 and suggesting building something new that is flexible and extensible. Gavin Andresen shares his experience with standardization and suggests that multisig wallets are still in the early stages of development. A suggestion is - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_New-BIP32-structure.xml b/static/bitcoin-dev/March_2014/combined_New-BIP32-structure.xml index 2b7a791e72..40d6dc942c 100644 --- a/static/bitcoin-dev/March_2014/combined_New-BIP32-structure.xml +++ b/static/bitcoin-dev/March_2014/combined_New-BIP32-structure.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP32 structure - 2023-08-01T08:08:37.970792+00:00 + 2025-10-11T21:35:01.372865+00:00 + python-feedgen Thomas Voegtlin 2014-04-24 08:15:18+00:00 @@ -403,13 +404,13 @@ - python-feedgen + 2 Combined summary - New BIP32 structure - 2023-08-01T08:08:37.974781+00:00 + 2025-10-11T21:35:01.373159+00:00 - In a series of email exchanges among Bitcoin developers, discussions and debates took place regarding the implementation and compatibility of BIP64 with BIP32. Pavol Rusnak argued that clients should be able to specify which subwallet they are accessing to ensure compatibility. However, he stated that calling these clients BIP64 compatible would be inaccurate if they cannot distinguish between subwallets and keep coins apart. There were differing views on the restrictiveness of BIP64, with some developers asserting that most end users do not need subwallet support.Developers also discussed the behavior of software that scans all accounts specified by BIP64 without providing user interface options to distinguish them or keep the coins apart. Marek explained that mixing funds across accounts is not compliant with the spec, and the wallet should never mix coins across different accounts. Pieter Wuille questioned the need for mixing funds between accounts, as it was seen as a niche requirement.Furthermore, conversations revolved around storing wallet birth time and importing clients. Tamas Blummer suggested appending key birth to key serialization in xprv, while modifying the serialization format was considered a potential solution. The goal was to find a solution that fit all requirements, but developers had differing opinions.Discussions also touched on the standardization of wallet structures, the importance of compatibility, and the challenges of achieving a single system that is compatible across multiple platforms. Developers emphasized the need for a standard structure for sharing wallets, with debates about the best way to store seeds and master nodes. There were disagreements on specific aspects of implementation, but the overall goal was to improve functionality and meet the needs of different users.There were suggestions to use one seed across different chains with separate master nodes derived by replacing "Bitcoin seed" with something chain-specific. Another suggestion was to have each encoded node, including master nodes, with a chain-specific serialization magic. It was debated whether using "cointype" in the bip32 path was necessary, but it was seen as an elegant solution for a single backup that can handle all coins with one master.The discussions also addressed the need for compatibility and standardization among wallet software. The importance of having a single system compatible over a large number of systems was emphasized. However, there were disagreements on implementing BIP64 fully or not at all, as using only a subset of the specification could confuse users.In conclusion, the conversations among Bitcoin developers revolved around the implementation and compatibility of BIP64 with BIP32, the need for standard structures in sharing wallets, and the challenges of achieving compatibility across multiple platforms. There were differing views on various aspects, such as the restrictiveness of BIP64 and the necessity of multiple subwallets. The discussions highlighted the ongoing efforts to find the best solutions and improve the functionality of Bitcoin wallets.During discussions in March 2014, Bitcoin developers focused on improving the structure of Bitcoin Improvement Proposal (BIP) and Bitcoin wallets. One suggestion was to increase the number of unused addresses available in lightweight or server-based wallets and count the number of unused addresses since the beginning instead of using a "gap limit." Bandwidth issues for Electrum and Mycelium were also addressed, with proposals to pre-generate a larger lookahead region and request more data at once.The topic of altcoins was brought up, with Testnet being highlighted as an important one. Different methods of identifying altcoins were discussed, such as using a hash of certain words or maintaining a directory of magic numbers. The purpose of the "reserved" feature in Bitcoin was questioned, and it was confirmed that it was intended for multisig addresses.Andreas Schildbach initiated a discussion on finding a better structure for Bitcoin wallets, emphasizing the need for interoperability and addressing bandwidth limitations. Distinguishing between merchant and regular user accounts was proposed, and a BIP32 wallet structure (/m/cointype/reserved'/account'/change/n) was suggested by Mike Hearn. Interoperability between wallets was deemed important, although metadata might be necessary alongside the hierarchical structure.At the Inside Bitcoin Conference in Berlin, developers debated the standardization of BIP32 wallet structures. They discussed the use of hierarchy and suggested using a hash of certain words instead of a directory of magic numbers. Armory Technologies announced plans to implement multi-sig/linked wallets, allowing users to switch to new apps without losing their coin history. Discouraging the use of a common root keychain for multiple keys in the same P2SH address was recommended.Discussions continued in March 2014 to create a compatible BIP32 wallet structure for different wallets. Mike Hearn proposed a new structure (/m/cointype/reserved'/account'/change/n) that was agreed upon by Thomas V and Marek. The structure aimed to meet users' needs while allowing flexibility. The topic of altcoins was also discussed, considering the potential larger trade volume of altcoins compared to Bitcoin.The ongoing discussion among Bitcoin developers focused on achieving better structure for 2014-04-24T08:15:18+00:00 + In a series of email exchanges among Bitcoin developers, discussions and debates took place regarding the implementation and compatibility of BIP64 with BIP32. Pavol Rusnak argued that clients should be able to specify which subwallet they are accessing to ensure compatibility. However, he stated that calling these clients BIP64 compatible would be inaccurate if they cannot distinguish between subwallets and keep coins apart. There were differing views on the restrictiveness of BIP64, with some developers asserting that most end users do not need subwallet support.Developers also discussed the behavior of software that scans all accounts specified by BIP64 without providing user interface options to distinguish them or keep the coins apart. Marek explained that mixing funds across accounts is not compliant with the spec, and the wallet should never mix coins across different accounts. Pieter Wuille questioned the need for mixing funds between accounts, as it was seen as a niche requirement.Furthermore, conversations revolved around storing wallet birth time and importing clients. Tamas Blummer suggested appending key birth to key serialization in xprv, while modifying the serialization format was considered a potential solution. The goal was to find a solution that fit all requirements, but developers had differing opinions.Discussions also touched on the standardization of wallet structures, the importance of compatibility, and the challenges of achieving a single system that is compatible across multiple platforms. Developers emphasized the need for a standard structure for sharing wallets, with debates about the best way to store seeds and master nodes. There were disagreements on specific aspects of implementation, but the overall goal was to improve functionality and meet the needs of different users.There were suggestions to use one seed across different chains with separate master nodes derived by replacing "Bitcoin seed" with something chain-specific. Another suggestion was to have each encoded node, including master nodes, with a chain-specific serialization magic. It was debated whether using "cointype" in the bip32 path was necessary, but it was seen as an elegant solution for a single backup that can handle all coins with one master.The discussions also addressed the need for compatibility and standardization among wallet software. The importance of having a single system compatible over a large number of systems was emphasized. However, there were disagreements on implementing BIP64 fully or not at all, as using only a subset of the specification could confuse users.In conclusion, the conversations among Bitcoin developers revolved around the implementation and compatibility of BIP64 with BIP32, the need for standard structures in sharing wallets, and the challenges of achieving compatibility across multiple platforms. There were differing views on various aspects, such as the restrictiveness of BIP64 and the necessity of multiple subwallets. The discussions highlighted the ongoing efforts to find the best solutions and improve the functionality of Bitcoin wallets.During discussions in March 2014, Bitcoin developers focused on improving the structure of Bitcoin Improvement Proposal (BIP) and Bitcoin wallets. One suggestion was to increase the number of unused addresses available in lightweight or server-based wallets and count the number of unused addresses since the beginning instead of using a "gap limit." Bandwidth issues for Electrum and Mycelium were also addressed, with proposals to pre-generate a larger lookahead region and request more data at once.The topic of altcoins was brought up, with Testnet being highlighted as an important one. Different methods of identifying altcoins were discussed, such as using a hash of certain words or maintaining a directory of magic numbers. The purpose of the "reserved" feature in Bitcoin was questioned, and it was confirmed that it was intended for multisig addresses.Andreas Schildbach initiated a discussion on finding a better structure for Bitcoin wallets, emphasizing the need for interoperability and addressing bandwidth limitations. Distinguishing between merchant and regular user accounts was proposed, and a BIP32 wallet structure (/m/cointype/reserved'/account'/change/n) was suggested by Mike Hearn. Interoperability between wallets was deemed important, although metadata might be necessary alongside the hierarchical structure.At the Inside Bitcoin Conference in Berlin, developers debated the standardization of BIP32 wallet structures. They discussed the use of hierarchy and suggested using a hash of certain words instead of a directory of magic numbers. Armory Technologies announced plans to implement multi-sig/linked wallets, allowing users to switch to new apps without losing their coin history. Discouraging the use of a common root keychain for multiple keys in the same P2SH address was recommended.Discussions continued in March 2014 to create a compatible BIP32 wallet structure for different wallets. Mike Hearn proposed a new structure (/m/cointype/reserved'/account'/change/n) that was agreed upon by Thomas V and Marek. The structure aimed to meet users' needs while allowing flexibility. The topic of altcoins was also discussed, considering the potential larger trade volume of altcoins compared to Bitcoin.The ongoing discussion among Bitcoin developers focused on achieving better structure for - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_New-side-channel-attack-that-can-recover-Bitcoin-keys.xml b/static/bitcoin-dev/March_2014/combined_New-side-channel-attack-that-can-recover-Bitcoin-keys.xml index 5fd6f7f249..faf677839e 100644 --- a/static/bitcoin-dev/March_2014/combined_New-side-channel-attack-that-can-recover-Bitcoin-keys.xml +++ b/static/bitcoin-dev/March_2014/combined_New-side-channel-attack-that-can-recover-Bitcoin-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New side channel attack that can recover Bitcoin keys - 2023-08-01T07:50:26.610336+00:00 + 2025-10-11T21:34:59.248736+00:00 + python-feedgen Gavin Andresen 2014-03-25 13:50:02+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - New side channel attack that can recover Bitcoin keys - 2023-08-01T07:50:26.611280+00:00 + 2025-10-11T21:34:59.248922+00:00 - In a series of email conversations and forum discussions in 2014, various vulnerabilities and security concerns related to Bitcoin addresses and the OpenSSL secp256k1 implementation were highlighted. Peter Todd emphasized the importance of not reusing addresses and recommended using n-of-m multisig instead of single-factor addresses for increased security. However, he acknowledged that many people do not follow these practices. To enhance security, Todd suggested incorporating side-channel resistant signing, specifically mentioning Oleg Andreev's blind signature scheme for ECDSA as a potential solution.Gregory Maxwell expressed his belief that not everyone follows good practices and advocated for the use of side-channel resistant signing. He mentioned Oleganza's blind signature scheme as a potential solution to address vulnerabilities associated with repeated payments to high-value addresses. However, Todd criticized amateur efforts like Coinbase and EasyWallet for potentially neglecting necessary precautions.The vulnerability of reusing Bitcoin addresses and using single-factor addresses was discussed in an email thread on March 5, 2014. Todd recommended not reusing addresses to avoid passing a threshold of approximately 200 signatures. He also suggested using n-of-m multisig instead of single-factor addresses to increase robustness. However, Todd acknowledged that behavioral changes required for following these recommendations might deter many people. Therefore, he emphasized the importance of incorporating side-channel resistant signing on top of these practices. He mentioned Oleg Andreev's blind signature scheme for ECDSA as a potential solution.A practical technique was published in March 2014, which could recover secp256k1 private keys after observing OpenSSL calculations of as few as 200 signatures. Mike Hearn advised hot wallet users to manage their wallets with dedicated hardware and start moving away from shared cloud services. He recommended architecting systems such that every transaction requires authorization from both online servers and a second hardened server. Additionally, customers could PGP-sign requests to independently verify their intent on both servers. Mircea Popescu's MPEx exchange was cited as an example of this model. Hearn also recommended using Tor and hidden services for connecting to machines placed in apartments, especially when only accepting Bitcoins from customers.Hearn wrote to the Bitcoin-development mailing list in March 2014 about the published technique that could recover secp256k1 private keys by observing OpenSSL calculations. The attack exploited L3 CPU cache timings using the FLUSH+RELOAD technique and targeted virtualized hosting environments where keys were reused. Hearn advised hot wallet users to manage their wallets with dedicated hardware and gradually move away from shared cloud services.In an email exchange between Jean-Paul Kogelman and Pieter, the topic of timing attacks and their prevention was discussed. Pieter mentioned some preliminary work he had done to make the implementation leak less but acknowledged that there was hardly any effort to prevent timing attacks, and it was not guaranteed to be constant time either.In a discussion on the Bitcoin-development mailing list, concerns were raised about the security of OpenSSL's secp256k1 implementation. Mike Hearn highlighted the lack of efforts to make it completely side channel free and the possibility of custom implementations not being fixed even if OpenSSL gets patched. Pieter Wuille noted the minimal effort in preventing timing attacks within the implementation, highlighting potential vulnerabilities and the need for improved security measures.Overall, these conversations and discussions emphasized the importance of not reusing Bitcoin addresses, utilizing n-of-m multisig, and incorporating side-channel resistant signing for enhanced security. The vulnerability of the OpenSSL secp256k1 implementation and the risks associated with shared cloud services were also highlighted, emphasizing the need for dedicated hardware and secure architectural designs. 2014-03-25T13:50:02+00:00 + In a series of email conversations and forum discussions in 2014, various vulnerabilities and security concerns related to Bitcoin addresses and the OpenSSL secp256k1 implementation were highlighted. Peter Todd emphasized the importance of not reusing addresses and recommended using n-of-m multisig instead of single-factor addresses for increased security. However, he acknowledged that many people do not follow these practices. To enhance security, Todd suggested incorporating side-channel resistant signing, specifically mentioning Oleg Andreev's blind signature scheme for ECDSA as a potential solution.Gregory Maxwell expressed his belief that not everyone follows good practices and advocated for the use of side-channel resistant signing. He mentioned Oleganza's blind signature scheme as a potential solution to address vulnerabilities associated with repeated payments to high-value addresses. However, Todd criticized amateur efforts like Coinbase and EasyWallet for potentially neglecting necessary precautions.The vulnerability of reusing Bitcoin addresses and using single-factor addresses was discussed in an email thread on March 5, 2014. Todd recommended not reusing addresses to avoid passing a threshold of approximately 200 signatures. He also suggested using n-of-m multisig instead of single-factor addresses to increase robustness. However, Todd acknowledged that behavioral changes required for following these recommendations might deter many people. Therefore, he emphasized the importance of incorporating side-channel resistant signing on top of these practices. He mentioned Oleg Andreev's blind signature scheme for ECDSA as a potential solution.A practical technique was published in March 2014, which could recover secp256k1 private keys after observing OpenSSL calculations of as few as 200 signatures. Mike Hearn advised hot wallet users to manage their wallets with dedicated hardware and start moving away from shared cloud services. He recommended architecting systems such that every transaction requires authorization from both online servers and a second hardened server. Additionally, customers could PGP-sign requests to independently verify their intent on both servers. Mircea Popescu's MPEx exchange was cited as an example of this model. Hearn also recommended using Tor and hidden services for connecting to machines placed in apartments, especially when only accepting Bitcoins from customers.Hearn wrote to the Bitcoin-development mailing list in March 2014 about the published technique that could recover secp256k1 private keys by observing OpenSSL calculations. The attack exploited L3 CPU cache timings using the FLUSH+RELOAD technique and targeted virtualized hosting environments where keys were reused. Hearn advised hot wallet users to manage their wallets with dedicated hardware and gradually move away from shared cloud services.In an email exchange between Jean-Paul Kogelman and Pieter, the topic of timing attacks and their prevention was discussed. Pieter mentioned some preliminary work he had done to make the implementation leak less but acknowledged that there was hardly any effort to prevent timing attacks, and it was not guaranteed to be constant time either.In a discussion on the Bitcoin-development mailing list, concerns were raised about the security of OpenSSL's secp256k1 implementation. Mike Hearn highlighted the lack of efforts to make it completely side channel free and the possibility of custom implementations not being fixed even if OpenSSL gets patched. Pieter Wuille noted the minimal effort in preventing timing attacks within the implementation, highlighting potential vulnerabilities and the need for improved security measures.Overall, these conversations and discussions emphasized the importance of not reusing Bitcoin addresses, utilizing n-of-m multisig, and incorporating side-channel resistant signing for enhanced security. The vulnerability of the OpenSSL secp256k1 implementation and the risks associated with shared cloud services were also highlighted, emphasizing the need for dedicated hardware and secure architectural designs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_New-to-this-list.xml b/static/bitcoin-dev/March_2014/combined_New-to-this-list.xml index a06ba0bb31..f65e4ccad8 100644 --- a/static/bitcoin-dev/March_2014/combined_New-to-this-list.xml +++ b/static/bitcoin-dev/March_2014/combined_New-to-this-list.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New to this list - 2023-08-01T07:48:12.537591+00:00 + 2025-10-11T21:34:54.998986+00:00 + python-feedgen Luke-Jr 2014-03-03 06:09:01+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - New to this list - 2023-08-01T07:48:12.537591+00:00 + 2025-10-11T21:34:54.999105+00:00 - To contribute to Bitcoin, a developer named Kevin sought advice on where to start. He received the suggestion to begin with unit tests, which would not only add value to projects but also help him understand how things work in the Bitcoin ecosystem. Another suggestion he received was to read and learn the source code of the reference client or any non-reference client Bitcoin projects.For developers interested in contributing to Bitcoin, getting involved with the open-source community is recommended. Joining online communities like Reddit's r/Bitcoin or BitcoinTalk can provide valuable insights and connections to other developers. Contributing to existing projects on Github or proposing new projects can help establish credibility within the community.While developing for Bitcoin may require specialized knowledge, there are resources available for newcomers. The Bitcoin Wiki serves as a comprehensive starting point for understanding the technical aspects of the system. Online courses, such as Coursera's "Bitcoin and Cryptocurrency Technologies," offer structured introductions to the subject.Attending Bitcoin conferences and meetups can provide opportunities to network with other developers and stay updated on emerging trends and technologies. These events also serve as platforms for presenting ideas and projects to a wider audience.Contributing to Bitcoin requires dedication and persistence, but the rewards can be significant. By becoming part of the open-source community and staying up-to-date on the latest developments, developers can play an important role in shaping the future of this groundbreaking technology. 2014-03-03T06:09:01+00:00 + To contribute to Bitcoin, a developer named Kevin sought advice on where to start. He received the suggestion to begin with unit tests, which would not only add value to projects but also help him understand how things work in the Bitcoin ecosystem. Another suggestion he received was to read and learn the source code of the reference client or any non-reference client Bitcoin projects.For developers interested in contributing to Bitcoin, getting involved with the open-source community is recommended. Joining online communities like Reddit's r/Bitcoin or BitcoinTalk can provide valuable insights and connections to other developers. Contributing to existing projects on Github or proposing new projects can help establish credibility within the community.While developing for Bitcoin may require specialized knowledge, there are resources available for newcomers. The Bitcoin Wiki serves as a comprehensive starting point for understanding the technical aspects of the system. Online courses, such as Coursera's "Bitcoin and Cryptocurrency Technologies," offer structured introductions to the subject.Attending Bitcoin conferences and meetups can provide opportunities to network with other developers and stay updated on emerging trends and technologies. These events also serve as platforms for presenting ideas and projects to a wider audience.Contributing to Bitcoin requires dedication and persistence, but the rewards can be significant. By becoming part of the open-source community and staying up-to-date on the latest developments, developers can play an important role in shaping the future of this groundbreaking technology. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Payment-Protocol-Hash-Comments.xml b/static/bitcoin-dev/March_2014/combined_Payment-Protocol-Hash-Comments.xml index f4137a6686..07ca2fa96f 100644 --- a/static/bitcoin-dev/March_2014/combined_Payment-Protocol-Hash-Comments.xml +++ b/static/bitcoin-dev/March_2014/combined_Payment-Protocol-Hash-Comments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol Hash Comments - 2023-08-01T07:46:43.044932+00:00 + 2025-10-11T21:35:05.762193+00:00 + python-feedgen Drak 2014-03-03 12:39:36+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol Hash Comments - 2023-08-01T07:46:43.044932+00:00 + 2025-10-11T21:35:05.762372+00:00 - In March 2014, an email exchange between Mike Hearn and Gavin discussed the rationale for adding SHA-2 to the spec. It was mentioned that although SHA-2 was available in standard PHP since version 5.1.2, there was a suggestion to remove SHA-1 from the specification unless there was a compelling reason to keep it.Contrary to Mike's previous statement, it was pointed out that PHP does support SHA-2, as evidenced by resources on the php.net website. A discussion thread on the Bitcoin-development mailing list in 2014 also touched on the use of SHA-1 versus SHA-2 in the context of BIP70. Some participants questioned the inclusion of SHA-1 due to its retirement. The thread also raised questions about whether end-users should be able to see details like the pki_type and certificate chain.On March 2nd, 2014, Jeremy Spilman posted a message on the Bitcoin-development mailing list regarding SHA-1 support in PHP development. The message referenced BIP70 and discussed the use of SHA-256 and SHA-1 algorithms for hashing payment messages. It suggested clarifying that the field to be hashed should be 'PaymentRequest' instead of 'Payment' and being more explicit about the hashing process. There were also concerns about SHA-1's retirement and whether it should be included in the system. Additionally, the question was raised about providing end-users with access to details such as pki_type and certificate chains.The BIP70 protocol outlines that the PaymentRequest message is hashed using the SHA256 algorithm if the pki_type is x509+sha256, and the SHA1 algorithm is used if the pki_type is x509+sha1. However, it was noted that the reference may be outdated as the field to be hashed is actually 'PaymentRequest', not 'Payment' message. Suggestions were made to improve the clarity of the protocol, including outlining the hashing process more explicitly. There was also a suggestion to reconsider the use of SHA-1 in the protocol due to its retirement. Additionally, the question was raised about providing end-users with a way to view details like the pki_type and certificate chain, similar to how browsers display this information. 2014-03-03T12:39:36+00:00 + In March 2014, an email exchange between Mike Hearn and Gavin discussed the rationale for adding SHA-2 to the spec. It was mentioned that although SHA-2 was available in standard PHP since version 5.1.2, there was a suggestion to remove SHA-1 from the specification unless there was a compelling reason to keep it.Contrary to Mike's previous statement, it was pointed out that PHP does support SHA-2, as evidenced by resources on the php.net website. A discussion thread on the Bitcoin-development mailing list in 2014 also touched on the use of SHA-1 versus SHA-2 in the context of BIP70. Some participants questioned the inclusion of SHA-1 due to its retirement. The thread also raised questions about whether end-users should be able to see details like the pki_type and certificate chain.On March 2nd, 2014, Jeremy Spilman posted a message on the Bitcoin-development mailing list regarding SHA-1 support in PHP development. The message referenced BIP70 and discussed the use of SHA-256 and SHA-1 algorithms for hashing payment messages. It suggested clarifying that the field to be hashed should be 'PaymentRequest' instead of 'Payment' and being more explicit about the hashing process. There were also concerns about SHA-1's retirement and whether it should be included in the system. Additionally, the question was raised about providing end-users with access to details such as pki_type and certificate chains.The BIP70 protocol outlines that the PaymentRequest message is hashed using the SHA256 algorithm if the pki_type is x509+sha256, and the SHA1 algorithm is used if the pki_type is x509+sha1. However, it was noted that the reference may be outdated as the field to be hashed is actually 'PaymentRequest', not 'Payment' message. Suggestions were made to improve the clarity of the protocol, including outlining the hashing process more explicitly. There was also a suggestion to reconsider the use of SHA-1 in the protocol due to its retirement. Additionally, the question was raised about providing end-users with a way to view details like the pki_type and certificate chain, similar to how browsers display this information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml b/static/bitcoin-dev/March_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml index 998e73aa0c..4460f36afe 100644 --- a/static/bitcoin-dev/March_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml +++ b/static/bitcoin-dev/March_2014/combined_Payment-Protocol-for-Face-to-face-Payments.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.614614+00:00 + 2025-10-11T21:34:18.875903+00:00 + python-feedgen Alex Kotenko 2014-07-02 08:49:10+00:00 @@ -271,13 +272,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol for Face-to-face Payments - 2023-08-01T07:23:18.615612+00:00 + 2025-10-11T21:34:18.876127+00:00 - In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. 2014-07-02T08:49:10+00:00 + In a discussion on the Bitcoin-development mailing list, the issue of verifying the identity of the recipient during Bitcoin payments is explored. The writer suggests that in most cases, verifying the name on the company register and certificate would be sufficient to prevent fraud. They propose the idea of a "cheesy" Certificate Authority (CA) that issues certificates with addresses included in them. However, this solution may not work for vending machines.Another challenge discussed is Germany's naming convention for businesses, which often leads to them being referred to by their type of establishment rather than their official name. This poses a challenge when conducting face-to-face transactions as the legal name of the entity running the establishment is often unknown. Creating a new infrastructure to address this issue is suggested but may not be feasible.The discussion also explores the suitability of BIP70 for bitcoin transactions in locations with limited or no internet access. One participant argues that such locations are unsuitable for bitcoin transactions as the receiver cannot verify double-spending or other transaction details. However, another participant suggests using a telephonic-based system connected to a centralized double-spend database to make these transactions possible.The conversation delves into the use of HTTP-over-Bluetooth and the challenges of implementing it. There is also a conversation about inventing a URI for Bluetooth and the considerations involved. ECC certificates are discussed, with concerns expressed about their risks and others arguing for their implementation despite the challenges.Throughout the conversation, there were invitations for volunteers from the Bitcoin community who enjoy cryptography to contribute and help develop the proposed security measures. The importance of growing the community and involving experts in the forums was highlighted.In conclusion, the discussion revolved around finding practical solutions for face-to-face Bitcoin transactions, including the use of QR codes, Bluetooth, and encryption/authentication layers. The goal was to ensure convenience, security, and interoperability while addressing the limitations and challenges associated with existing technologies and protocols.Another aspect of the discussion revolves around the idea of using Bluetooth to enable scan-to-pay transactions. Including a Bluetooth MAC address in the payment_url inside the PaymentDetails message is suggested to allow for the smartphone to send back the payment response and receive a PaymentAck. This approach is seen as a way to improve the process and enhance connectivity.The current approach for Bitcoin transactions involves using a BTMAC parameter in the Bitcoin URI, which works universally across NFC tags and QR codes. These signed payment requests are considered "large" because they can be verified offline. The signing process is still useful for face-to-face payments, as it blurs the distinction between the "merchant" and the "user," making it more secure.There is potential for using payment protocol URLs for links published on web pages as well. This could serve as a replacement for the BIP72 specification once the payment protocol becomes widely deployed. To implement this approach, the author has created a prototype on a branch of Bitcoin Wallet.Overall, this proposed approach aims to improve the efficiency and security of Bitcoin transactions, both in face-to-face scenarios and online. By leveraging the payment protocol and utilizing different technologies like NFC and QR codes, the author's implementation offers a promising solution for seamless and secure payments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Physical-key-edge-detection-software-and-PIN-to-generate-private-key.xml b/static/bitcoin-dev/March_2014/combined_Physical-key-edge-detection-software-and-PIN-to-generate-private-key.xml index 8d342e5aa3..0f114db947 100644 --- a/static/bitcoin-dev/March_2014/combined_Physical-key-edge-detection-software-and-PIN-to-generate-private-key.xml +++ b/static/bitcoin-dev/March_2014/combined_Physical-key-edge-detection-software-and-PIN-to-generate-private-key.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Physical key / edge detection software and PIN to generate private key - 2023-08-01T07:57:30.706892+00:00 + 2025-10-11T21:34:29.519945+00:00 + python-feedgen Brooks Boyd 2014-03-14 17:49:19+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Physical key / edge detection software and PIN to generate private key - 2023-08-01T07:57:30.706892+00:00 + 2025-10-11T21:34:29.520088+00:00 - Jack Scott proposed a method to generate a Bitcoin private key using a physical key, image recognition software, and a PIN. This proposal was submitted under BIP XX titled "Physical key / edge detection software and PIN to generate a Bitcoin private key" on March 13, 2014. The idea is to convert the shape of a physical key into an equation that describes the key by utilizing edge detection software applied to an incoming video feed. The resulting equation, along with a user-generated five-digit PIN, can be hashed to create a Bitcoin private key.Brooks showed interest in the proposal but raised concerns about the security of a real-world "key" compared to a Bitcoin/PGP "key". He acknowledged that a physical/visual "key" could be any complex, high-contrast image, such as a motion tracking target. He suggested that the standard should enforce a minimum level of complexity to prevent the use of simple and easily reproducible/stealable keys. Additionally, he recommended using a QR code instead if a high level of complexity was required.In an email exchange, Wladimir pointed out practical issues with the proposed method. He noted that physical keys are vulnerable to reproduction attacks based on photography and that computer vision algorithms often produce noisy output. Using a physical key as input for hashing a private key may make it difficult or even impossible to reproduce. Furthermore, physical objects like keys may deform over time, adding another challenge to this method.In conclusion, the proposed method for generating a Bitcoin private key involves utilizing a physical key, edge detection software, and a PIN. The shape of the physical key is converted into an equation using image recognition software that applies edge detection to an incoming video feed. The resulting equation, combined with a user-generated five-digit PIN, can be hashed to create a Bitcoin private key. However, practical considerations such as security vulnerabilities and potential deformations of physical objects need to be addressed before implementing this method. 2014-03-14T17:49:19+00:00 + Jack Scott proposed a method to generate a Bitcoin private key using a physical key, image recognition software, and a PIN. This proposal was submitted under BIP XX titled "Physical key / edge detection software and PIN to generate a Bitcoin private key" on March 13, 2014. The idea is to convert the shape of a physical key into an equation that describes the key by utilizing edge detection software applied to an incoming video feed. The resulting equation, along with a user-generated five-digit PIN, can be hashed to create a Bitcoin private key.Brooks showed interest in the proposal but raised concerns about the security of a real-world "key" compared to a Bitcoin/PGP "key". He acknowledged that a physical/visual "key" could be any complex, high-contrast image, such as a motion tracking target. He suggested that the standard should enforce a minimum level of complexity to prevent the use of simple and easily reproducible/stealable keys. Additionally, he recommended using a QR code instead if a high level of complexity was required.In an email exchange, Wladimir pointed out practical issues with the proposed method. He noted that physical keys are vulnerable to reproduction attacks based on photography and that computer vision algorithms often produce noisy output. Using a physical key as input for hashing a private key may make it difficult or even impossible to reproduce. Furthermore, physical objects like keys may deform over time, adding another challenge to this method.In conclusion, the proposed method for generating a Bitcoin private key involves utilizing a physical key, edge detection software, and a PIN. The shape of the physical key is converted into an equation using image recognition software that applies edge detection to an incoming video feed. The resulting equation, combined with a user-generated five-digit PIN, can be hashed to create a Bitcoin private key. However, practical considerations such as security vulnerabilities and potential deformations of physical objects need to be addressed before implementing this method. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Positive-and-negative-feedback-on-certificate-validation-errors.xml b/static/bitcoin-dev/March_2014/combined_Positive-and-negative-feedback-on-certificate-validation-errors.xml index 9220f5c3b5..c598618c55 100644 --- a/static/bitcoin-dev/March_2014/combined_Positive-and-negative-feedback-on-certificate-validation-errors.xml +++ b/static/bitcoin-dev/March_2014/combined_Positive-and-negative-feedback-on-certificate-validation-errors.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Positive and negative feedback on certificate validation errors - 2023-08-01T07:46:21.476862+00:00 + 2025-10-11T21:34:20.999699+00:00 + python-feedgen Troy Benjegerdes 2014-03-02 18:18:18+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Positive and negative feedback on certificate validation errors - 2023-08-01T07:46:21.476862+00:00 + 2025-10-11T21:34:20.999869+00:00 - In an email thread, Jeremy Spilman raised concerns about the use of third-party root certificates as a form of positive feedback for signed payment requests in cryptographic currency. He questioned the necessity of external certificates and their potential impact on security. Spilman proposed that if a payment is signed by the ECDSA private key it's being sent to, it should be marked with a green background. He also suggested implementing a signing fee extension or a compile-time option to disable this feature for small businesses. The email thread concluded with a quote advising against picking fights with influential individuals or trying to buy hackers.In another email conversation on the Bitcoin-development mailing list, Wladimir proposed a green stamp watermark for future BIP standards to differentiate signed requests. However, Jeremy Spilman pointed out the challenge of differentiating unsigned payment requests since they lack an "origin". The best way to distinguish signed requests, according to Spilman, is by prominently displaying the Merchant string in the green part of the stamp. The rest of the content would be displayed as normal, and a blank "Pay To" line would indicate the absence of a certificate. Saivann was suggested to potentially assist with graphics work for this.Continuing the email conversation, Wladimir and the recipient discussed the difficulty of differentiating unsigned payment requests due to the lack of an "origin" or referrer. If a request has a certificate, the Common Name (CN) becomes the "Pay To" string displayed for the merchant. Without a certificate, the most effective way to differentiate signed requests is by prominently displaying the Merchant string. The green display should only show the "Pay To" line, while the rest remains as content. An empty "Pay To" line would indicate the absence of a certificate.Another email exchange among Bitcoin developers focused on bug (#3628) and pull request (#3684) regarding negative feedback for missing or invalid signatures. It was agreed that treating invalid and unsigned payment requests equally would be ideal since the cost to an attacker is the same. The recommendation was made to test the pull request for improved payment request reporting. There was also discussion about making the difference between invalid and unsigned requests more noticeable to end users. Additionally, implementing a measure similar to HTTP Strict Transport Security for payment protocols was suggested to prevent signature stripping attacks in the future. However, the challenge of identifying the "origin" for unsigned payment requests was raised, and it was proposed that the server serving the payment requests could provide an HSTS-like header to only accept signed payment requests from them.Currently, signed payment requests are indicated by a green background, while unsigned requests have no background. Requests with a certificate but missing or invalid signatures also lack the green background. A bug (#3628) and pull request (#3684) have been opened to introduce negative feedback in the form of a yellow background for requests with missing or invalid signatures. However, there is a debate on whether this should be implemented in bitcoind. Concerns have been raised that if an attacker can avoid negative feedback by stripping the signature and setting pki_type to none, there may not be a security benefit in differentiating badly signed payment requests from unsigned ones. As a result, it is suggested that the root problem may lie in the positive feedback (green background) not being noticeable enough to the end user. Furthermore, there is ongoing discussion about implementing a measure similar to HTTP Strict Transport Security for payment protocols to mitigate signature stripping attacks, which merchants may be interested in as an extension field. 2014-03-02T18:18:18+00:00 + In an email thread, Jeremy Spilman raised concerns about the use of third-party root certificates as a form of positive feedback for signed payment requests in cryptographic currency. He questioned the necessity of external certificates and their potential impact on security. Spilman proposed that if a payment is signed by the ECDSA private key it's being sent to, it should be marked with a green background. He also suggested implementing a signing fee extension or a compile-time option to disable this feature for small businesses. The email thread concluded with a quote advising against picking fights with influential individuals or trying to buy hackers.In another email conversation on the Bitcoin-development mailing list, Wladimir proposed a green stamp watermark for future BIP standards to differentiate signed requests. However, Jeremy Spilman pointed out the challenge of differentiating unsigned payment requests since they lack an "origin". The best way to distinguish signed requests, according to Spilman, is by prominently displaying the Merchant string in the green part of the stamp. The rest of the content would be displayed as normal, and a blank "Pay To" line would indicate the absence of a certificate. Saivann was suggested to potentially assist with graphics work for this.Continuing the email conversation, Wladimir and the recipient discussed the difficulty of differentiating unsigned payment requests due to the lack of an "origin" or referrer. If a request has a certificate, the Common Name (CN) becomes the "Pay To" string displayed for the merchant. Without a certificate, the most effective way to differentiate signed requests is by prominently displaying the Merchant string. The green display should only show the "Pay To" line, while the rest remains as content. An empty "Pay To" line would indicate the absence of a certificate.Another email exchange among Bitcoin developers focused on bug (#3628) and pull request (#3684) regarding negative feedback for missing or invalid signatures. It was agreed that treating invalid and unsigned payment requests equally would be ideal since the cost to an attacker is the same. The recommendation was made to test the pull request for improved payment request reporting. There was also discussion about making the difference between invalid and unsigned requests more noticeable to end users. Additionally, implementing a measure similar to HTTP Strict Transport Security for payment protocols was suggested to prevent signature stripping attacks in the future. However, the challenge of identifying the "origin" for unsigned payment requests was raised, and it was proposed that the server serving the payment requests could provide an HSTS-like header to only accept signed payment requests from them.Currently, signed payment requests are indicated by a green background, while unsigned requests have no background. Requests with a certificate but missing or invalid signatures also lack the green background. A bug (#3628) and pull request (#3684) have been opened to introduce negative feedback in the form of a yellow background for requests with missing or invalid signatures. However, there is a debate on whether this should be implemented in bitcoind. Concerns have been raised that if an attacker can avoid negative feedback by stripping the signature and setting pki_type to none, there may not be a security benefit in differentiating badly signed payment requests from unsigned ones. As a result, it is suggested that the root problem may lie in the positive feedback (green background) not being noticeable enough to the end user. Furthermore, there is ongoing discussion about implementing a measure similar to HTTP Strict Transport Security for payment protocols to mitigate signature stripping attacks, which merchants may be interested in as an extension field. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Post-to-list-request.xml b/static/bitcoin-dev/March_2014/combined_Post-to-list-request.xml index 3cbbc4df49..a0d8953a55 100644 --- a/static/bitcoin-dev/March_2014/combined_Post-to-list-request.xml +++ b/static/bitcoin-dev/March_2014/combined_Post-to-list-request.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Post to list request - 2023-08-01T07:59:53.419867+00:00 + 2025-10-11T21:34:08.264261+00:00 + python-feedgen Mike Hearn 2014-03-21 11:09:33+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Post to list request - 2023-08-01T07:59:53.419867+00:00 + 2025-10-11T21:34:08.264442+00:00 - On March 21, 2014, Andreas Schildbach welcomed Chris D'Costa's request for access to post on the dev list. Chris was working on a project called the Meek hardware wallet, which aimed to address the issue of MITM attacks during the transmission of pay-to information over a non-secure transport mechanism. The email also included a promotional message offering a free download of the book "Graph Databases," written by three renowned experts in the field. This book serves as a comprehensive guide to graph databases and their various applications. By requesting access to the dev list, Chris may be seeking feedback and collaboration from the developer community to further enhance the Meek hardware wallet project. 2014-03-21T11:09:33+00:00 + On March 21, 2014, Andreas Schildbach welcomed Chris D'Costa's request for access to post on the dev list. Chris was working on a project called the Meek hardware wallet, which aimed to address the issue of MITM attacks during the transmission of pay-to information over a non-secure transport mechanism. The email also included a promotional message offering a free download of the book "Graph Databases," written by three renowned experts in the field. This book serves as a comprehensive guide to graph databases and their various applications. By requesting access to the dev list, Chris may be seeking feedback and collaboration from the developer community to further enhance the Meek hardware wallet project. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml b/static/bitcoin-dev/March_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml index bdae5cf2a5..7ee41d3b23 100644 --- a/static/bitcoin-dev/March_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml +++ b/static/bitcoin-dev/March_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys - 2023-08-01T08:17:21.054953+00:00 + 2025-10-11T21:35:14.261571+00:00 + python-feedgen Nikita Schmidt 2014-08-14 19:23:16+00:00 @@ -363,13 +364,13 @@ - python-feedgen + 2 Combined summary - Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys - 2023-08-01T08:17:21.055952+00:00 + 2025-10-11T21:35:14.261888+00:00 - Jan Møller, in an email exchange, expressed his opinion that the current format of the Shared Secret Sharing (SSS) standard is over-engineered. He suggested that only the long format makes sense from a user experience standpoint and proposed that it is only slightly longer than the short version. After no objections were raised, the draft was revised to address this concern.The new version of the SSS standard allows for the shared secret to be encoded in various forms, such as SIPA or BIP38, instead of just a plain private key. This change has several benefits, including not needing to modify the specification for different types of content and encoding metadata together with the secret. The underlying field of the standard was also changed to GF(256), which is more advantageous for dealing with secrets of arbitrary length.To solve the issue of variable length and lack of control over the Base58 prefix, the magic prefix was moved outside of the Base58 encoded content. The application identifier 'SSS-' was introduced, followed by the Base58 encoding of the share. This change may be mildly controversial, and alternatives could be considered.A Java implementation of BIPSS based on a GF2^8 implementation can be found on Github. The use of three encoding formats in the SSS standard is considered over-engineered, with the long format being the only necessary option from a user experience perspective. A fork of Matt's proposal converted to GF(2^8) is also available on Github, which includes changes like allocating only six application/version bytes and using SHA-256 hash functions.The inclusion of a specific flag for testnet in SSS and BIP32 was discussed in email exchanges. It was agreed that such flags are unnecessary since they are not used for sending addresses. The convention so far has been to include a 'version' identifier to identify the purpose of the data, such as network meaning.There was a debate about the importance of testnet in Bitcoin Improvement Proposals (BIPs). Some argued that testnet exists for public testing involving multiple people and services, while others saw it as a tool for certain types of testing. It was noted that testnet is not normally addressed in BIPs, except for soft fork BIPs with compressed deployment schedules on testnet.The serialization of keys when using test chains was discussed, with some expressing that distinguishing serialization of keys is unnecessary. The difference between testnet and mainnet was emphasized as separate from bitcoin vs altcoin, but few altcoins understood this distinction.The issue of encoding the chain in WIF and BIP32 was debated, with some suggesting that it should be ignored as legacy. New BIPs should no longer carry this forward.Discussions also took place regarding the encoding of N-of-M shares. Suggestions were made to encode N-of-M in one byte and to use a bias of -1 for M encoding. Test vectors were updated accordingly.Tamas Blummer expressed his opinion that extra encoding for testnet is not necessary compared to many alt chains. He suggested that BIPs should remain chain agnostic.In an email exchange between Jan Møller and Gregory Maxwell, Møller expressed his concerns about BIP38 and suggested using Shamir's Secret Sharing instead. It is unclear if Møller provided a list of concerns about BIP38 or offered to do so upon request.Tamas Blummer argued that the wide variety of available chains supersedes the notion of main and testnet. He believes that what altcoins do is their own business and outside the scope of a BIP. He also questioned the need for a separate encoding for Bitcoin testnet private keys.Overall, the discussions revolved around simplifying the SSS standard, considering the use cases for testnet and altchains, and debating the encoding of keys and chains in various contexts.The complexity of using the binary extension field of GF(2^8) for secret sharing and data integrity applications was discussed. Some suggested that big-integer operations may be more practical, while others argued that implementing a complex system with many individually testable parts is easier than implementing a single complex part. Gregory Maxwell's implementation of his Bitcoin Improvement Proposal (BIP) is in C++ and uses the GMP library for big-integer arithmetic.There was a debate about the potential risks of obfuscating the parameters of the secret sharing process. Some expressed concerns about users accidentally mixing different types of fragments or distributing too many, which can lead to insecurity or difficulty in restoring their wallets. However, it was acknowledged that attackers may still be able to figure out the information despite the obfuscation.Matt Whitlock proposed an obfuscation method for the secret sharing process but ultimately decided against it based on the consensus of others. Alan Reiner disagreed with this tradeoff, stating that obfuscating something already considered secure at the expense of usability is not beneficial. He argued that it is more important for users to understand what 2014-08-14T19:23:16+00:00 + Jan Møller, in an email exchange, expressed his opinion that the current format of the Shared Secret Sharing (SSS) standard is over-engineered. He suggested that only the long format makes sense from a user experience standpoint and proposed that it is only slightly longer than the short version. After no objections were raised, the draft was revised to address this concern.The new version of the SSS standard allows for the shared secret to be encoded in various forms, such as SIPA or BIP38, instead of just a plain private key. This change has several benefits, including not needing to modify the specification for different types of content and encoding metadata together with the secret. The underlying field of the standard was also changed to GF(256), which is more advantageous for dealing with secrets of arbitrary length.To solve the issue of variable length and lack of control over the Base58 prefix, the magic prefix was moved outside of the Base58 encoded content. The application identifier 'SSS-' was introduced, followed by the Base58 encoding of the share. This change may be mildly controversial, and alternatives could be considered.A Java implementation of BIPSS based on a GF2^8 implementation can be found on Github. The use of three encoding formats in the SSS standard is considered over-engineered, with the long format being the only necessary option from a user experience perspective. A fork of Matt's proposal converted to GF(2^8) is also available on Github, which includes changes like allocating only six application/version bytes and using SHA-256 hash functions.The inclusion of a specific flag for testnet in SSS and BIP32 was discussed in email exchanges. It was agreed that such flags are unnecessary since they are not used for sending addresses. The convention so far has been to include a 'version' identifier to identify the purpose of the data, such as network meaning.There was a debate about the importance of testnet in Bitcoin Improvement Proposals (BIPs). Some argued that testnet exists for public testing involving multiple people and services, while others saw it as a tool for certain types of testing. It was noted that testnet is not normally addressed in BIPs, except for soft fork BIPs with compressed deployment schedules on testnet.The serialization of keys when using test chains was discussed, with some expressing that distinguishing serialization of keys is unnecessary. The difference between testnet and mainnet was emphasized as separate from bitcoin vs altcoin, but few altcoins understood this distinction.The issue of encoding the chain in WIF and BIP32 was debated, with some suggesting that it should be ignored as legacy. New BIPs should no longer carry this forward.Discussions also took place regarding the encoding of N-of-M shares. Suggestions were made to encode N-of-M in one byte and to use a bias of -1 for M encoding. Test vectors were updated accordingly.Tamas Blummer expressed his opinion that extra encoding for testnet is not necessary compared to many alt chains. He suggested that BIPs should remain chain agnostic.In an email exchange between Jan Møller and Gregory Maxwell, Møller expressed his concerns about BIP38 and suggested using Shamir's Secret Sharing instead. It is unclear if Møller provided a list of concerns about BIP38 or offered to do so upon request.Tamas Blummer argued that the wide variety of available chains supersedes the notion of main and testnet. He believes that what altcoins do is their own business and outside the scope of a BIP. He also questioned the need for a separate encoding for Bitcoin testnet private keys.Overall, the discussions revolved around simplifying the SSS standard, considering the use cases for testnet and altchains, and debating the encoding of keys and chains in various contexts.The complexity of using the binary extension field of GF(2^8) for secret sharing and data integrity applications was discussed. Some suggested that big-integer operations may be more practical, while others argued that implementing a complex system with many individually testable parts is easier than implementing a single complex part. Gregory Maxwell's implementation of his Bitcoin Improvement Proposal (BIP) is in C++ and uses the GMP library for big-integer arithmetic.There was a debate about the potential risks of obfuscating the parameters of the secret sharing process. Some expressed concerns about users accidentally mixing different types of fragments or distributing too many, which can lead to insecurity or difficulty in restoring their wallets. However, it was acknowledged that attackers may still be able to figure out the information despite the obfuscation.Matt Whitlock proposed an obfuscation method for the secret sharing process but ultimately decided against it based on the consensus of others. Alan Reiner disagreed with this tradeoff, stating that obfuscating something already considered secure at the expense of usability is not beneficial. He argued that it is more important for users to understand what - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Procedure-for-non-tech-contributions.xml b/static/bitcoin-dev/March_2014/combined_Procedure-for-non-tech-contributions.xml index 6c2367d775..05996511cd 100644 --- a/static/bitcoin-dev/March_2014/combined_Procedure-for-non-tech-contributions.xml +++ b/static/bitcoin-dev/March_2014/combined_Procedure-for-non-tech-contributions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Procedure for non-tech contributions - 2023-08-01T07:47:59.817193+00:00 + 2025-10-11T21:34:31.641454+00:00 + python-feedgen Tom Geller 2014-03-04 19:10:08+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Procedure for non-tech contributions - 2023-08-01T07:47:59.817193+00:00 + 2025-10-11T21:34:31.641622+00:00 - Tom Geller, a writer and presenter from Oberlin, Ohio, has expressed his gratitude to all who assisted him in getting involved in the Bitcoin community. He was contacted by Mike Hearn with the idea of creating a "Bitcoin Developer Network" subsection on bitcoin.org to provide professionally curated web content for developers. Currently, the website is consumer-focused and the wiki section is facing technical difficulties. To address this gap, Tom proposes finding people to produce content while a web developer named Saivann assists with visual design.In an email exchange, Tom discusses the need for professional web content for developers interested in working with Bitcoin. The current bitcoin.org website is targeted towards consumers and the wiki section is not ideal for professional documentation. He suggests creating a "Bitcoin Developer Network" subsection on the website to provide curated content for developers. The hope is to find individuals willing to produce content and have Saivann, a web developer sponsored by the Foundation, assist with visual design. Tom also mentions his edits to the release notes for 0.9.0rc2 software and requests assistance if needed. However, his edits failed testing, and he hopes others will reach out to help resolve any issues. Additionally, Tom includes an advertisement for Perforce, a version control system, promoting its benefits over Subversion.Tom Geller, a writer and presenter from Oberlin, Ohio, has made his first contribution to the release notes of 0.9.0rc2 for the Bitcoin project. He posted a pull request on GitHub and welcomed any corrections that may be needed. However, his edits failed testing. Tom mentions that he assumes he'll receive emails as others add comments and requests anyone willing to help him privately contact him. Apart from his work with the Bitcoin project, Tom has experience in writing articles, marketing materials, creating videos, user guides, and books.The context includes discussions about the control of the Mt. Gox wiki and text editing on Github. Fixes for the Mt. Gox wiki are underway, but no specifics are given. Regarding text editing on Github, Wladimir provides a simple solution involving going to the release-notes page, clicking "edit", making desired changes, and adding a commit message. Tom expresses his thanks to those who provided advice and mentions that he will go over the 0.9.0rc2 text soon. The email concludes with contact information for Tom Geller, a writer/presenter specializing in articles, marketing, videos, user guides, and books.A non-developer writer expresses interest in contributing to the Bitcoin community with writing, editing, and marketing skills. They ask for information on how to do so and if there is someone in charge of that area. The writer provides two examples of unclear areas within the community, including difficulties in sending changes for proofreading and outdated information on a Bitcoin wiki page. They share their contact information and welcome off-list replies. The email also includes a subscription link to join the Bitcoin-development mailing list and a Reddit post about developers, core developers, and contributors. Additionally, a promotional message for NetFlow Analyzer software is included.In an email dated March 3, 2014, Tom Geller asks for suggestions on adding a file to a particular solution. Wladimir responds with a possible solution involving editing the file in the 0.9 branch on Github. The process includes going to the release notes page, clicking "edit", making changes, and adding a commit message.Tom Geller expresses concerns about sending payments to a wallet held by MtGox for editing the Bitcoin wiki. He believes it may prevent new contributors from joining and mentions not receiving a confirmation email after registering. However, the priority for moving the wiki to new hosting is low for MtGox. It is suggested to contact SomeoneWeird on IRC for manual approvals of new editing accounts.Peter Todd proofreads rc1 and submits his changes via pull-req on the Github repository. Drak suggests using Github's direct file editing feature, but it is not possible in this case as the file is not available at the repository. Peter raises concerns about sending payments to a Mt. Gox-held wallet for editing the Bitcoin wiki, which he believes is a hard blocker for new contributors. He mentions not receiving the confirmation email after registering for the wiki, suggesting that the process may be broken.On March 2, 2014, Peter Todd suggests using the pull request method to encourage proofreading with corrections applied. He submits his changes via pull-req on Github and mentions that no fancy software is required for diffing changes. However, Drak points out that editing files directly on the site is possible on Github, making contributing easy even for non-techy people.In an email thread, Tom Geller, a non-developer writer, expresses interest in contributing to the Bitcoin project through writing, editing, and marketing. He asks about the procedure for doing so and if there is someone in charge of that area. Another member 2014-03-04T19:10:08+00:00 + Tom Geller, a writer and presenter from Oberlin, Ohio, has expressed his gratitude to all who assisted him in getting involved in the Bitcoin community. He was contacted by Mike Hearn with the idea of creating a "Bitcoin Developer Network" subsection on bitcoin.org to provide professionally curated web content for developers. Currently, the website is consumer-focused and the wiki section is facing technical difficulties. To address this gap, Tom proposes finding people to produce content while a web developer named Saivann assists with visual design.In an email exchange, Tom discusses the need for professional web content for developers interested in working with Bitcoin. The current bitcoin.org website is targeted towards consumers and the wiki section is not ideal for professional documentation. He suggests creating a "Bitcoin Developer Network" subsection on the website to provide curated content for developers. The hope is to find individuals willing to produce content and have Saivann, a web developer sponsored by the Foundation, assist with visual design. Tom also mentions his edits to the release notes for 0.9.0rc2 software and requests assistance if needed. However, his edits failed testing, and he hopes others will reach out to help resolve any issues. Additionally, Tom includes an advertisement for Perforce, a version control system, promoting its benefits over Subversion.Tom Geller, a writer and presenter from Oberlin, Ohio, has made his first contribution to the release notes of 0.9.0rc2 for the Bitcoin project. He posted a pull request on GitHub and welcomed any corrections that may be needed. However, his edits failed testing. Tom mentions that he assumes he'll receive emails as others add comments and requests anyone willing to help him privately contact him. Apart from his work with the Bitcoin project, Tom has experience in writing articles, marketing materials, creating videos, user guides, and books.The context includes discussions about the control of the Mt. Gox wiki and text editing on Github. Fixes for the Mt. Gox wiki are underway, but no specifics are given. Regarding text editing on Github, Wladimir provides a simple solution involving going to the release-notes page, clicking "edit", making desired changes, and adding a commit message. Tom expresses his thanks to those who provided advice and mentions that he will go over the 0.9.0rc2 text soon. The email concludes with contact information for Tom Geller, a writer/presenter specializing in articles, marketing, videos, user guides, and books.A non-developer writer expresses interest in contributing to the Bitcoin community with writing, editing, and marketing skills. They ask for information on how to do so and if there is someone in charge of that area. The writer provides two examples of unclear areas within the community, including difficulties in sending changes for proofreading and outdated information on a Bitcoin wiki page. They share their contact information and welcome off-list replies. The email also includes a subscription link to join the Bitcoin-development mailing list and a Reddit post about developers, core developers, and contributors. Additionally, a promotional message for NetFlow Analyzer software is included.In an email dated March 3, 2014, Tom Geller asks for suggestions on adding a file to a particular solution. Wladimir responds with a possible solution involving editing the file in the 0.9 branch on Github. The process includes going to the release notes page, clicking "edit", making changes, and adding a commit message.Tom Geller expresses concerns about sending payments to a wallet held by MtGox for editing the Bitcoin wiki. He believes it may prevent new contributors from joining and mentions not receiving a confirmation email after registering. However, the priority for moving the wiki to new hosting is low for MtGox. It is suggested to contact SomeoneWeird on IRC for manual approvals of new editing accounts.Peter Todd proofreads rc1 and submits his changes via pull-req on the Github repository. Drak suggests using Github's direct file editing feature, but it is not possible in this case as the file is not available at the repository. Peter raises concerns about sending payments to a Mt. Gox-held wallet for editing the Bitcoin wiki, which he believes is a hard blocker for new contributors. He mentions not receiving the confirmation email after registering for the wiki, suggesting that the process may be broken.On March 2, 2014, Peter Todd suggests using the pull request method to encourage proofreading with corrections applied. He submits his changes via pull-req on Github and mentions that no fancy software is required for diffing changes. However, Drak points out that editing files directly on the site is possible on Github, making contributing easy even for non-techy people.In an email thread, Tom Geller, a non-developer writer, expresses interest in contributing to the Bitcoin project through writing, editing, and marketing. He asks about the procedure for doing so and if there is someone in charge of that area. Another member - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Process-for-getting-a-patch-aproved-.xml b/static/bitcoin-dev/March_2014/combined_Process-for-getting-a-patch-aproved-.xml index 672d561521..88a6616a94 100644 --- a/static/bitcoin-dev/March_2014/combined_Process-for-getting-a-patch-aproved-.xml +++ b/static/bitcoin-dev/March_2014/combined_Process-for-getting-a-patch-aproved-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Process for getting a patch aproved? - 2023-08-01T07:50:44.721966+00:00 + 2025-10-11T21:34:27.398497+00:00 + python-feedgen Wladimir 2014-03-06 07:56:30+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Process for getting a patch aproved? - 2023-08-01T07:50:44.722964+00:00 + 2025-10-11T21:34:27.398679+00:00 - Kevin asked for guidance on how to submit a patch and inquired if it could be sent as an attachment through the mailing list. Wladimir suggested using GitHub instead, as reviewing patches sent through the mailing list can take time and they may get lost. He explained that the GitHub model is better for this project because an 'issue' appears until the patch is either merged or closed, ensuring it doesn't get overlooked.However, Wladimir mentioned that if the proposed change concerns a protocol change, it is advisable to discuss it on the mailing list, as people building other implementations read there and not on GitHub.In terms of submitting a patch, the recommended method is to open a GitHub account and submit the patch there. This allows for more collaborative development and easier tracking of changes. If opening a GitHub account is not possible, sending a git-format-patch via email may be an acceptable alternative.There are also other options available for submitting a patch. One option is to send it through the mailing list as an attachment, as Kevin had suggested. However, this may not always be the most efficient method. Using a version control system like Git or SVN to create and submit the patch is another option. These systems enable collaborative development and make it easier to track changes. Many open source projects prefer patches submitted through these systems.When submitting a patch, it is important to ensure that it adheres to the coding standards or guidelines set by the project. This increases the likelihood of the patch being accepted and merged into the codebase. Thoroughly testing the patch before submission is also crucial.In conclusion, there are multiple ways to submit a patch, and it is important to follow the appropriate procedures and guidelines set forth by the project. Using GitHub or a version control system like Git or SVN is recommended, but sending patches through the mailing list as attachments is also an option. Adhering to coding standards and thoroughly testing the patch are essential for increasing its chances of being accepted. 2014-03-06T07:56:30+00:00 + Kevin asked for guidance on how to submit a patch and inquired if it could be sent as an attachment through the mailing list. Wladimir suggested using GitHub instead, as reviewing patches sent through the mailing list can take time and they may get lost. He explained that the GitHub model is better for this project because an 'issue' appears until the patch is either merged or closed, ensuring it doesn't get overlooked.However, Wladimir mentioned that if the proposed change concerns a protocol change, it is advisable to discuss it on the mailing list, as people building other implementations read there and not on GitHub.In terms of submitting a patch, the recommended method is to open a GitHub account and submit the patch there. This allows for more collaborative development and easier tracking of changes. If opening a GitHub account is not possible, sending a git-format-patch via email may be an acceptable alternative.There are also other options available for submitting a patch. One option is to send it through the mailing list as an attachment, as Kevin had suggested. However, this may not always be the most efficient method. Using a version control system like Git or SVN to create and submit the patch is another option. These systems enable collaborative development and make it easier to track changes. Many open source projects prefer patches submitted through these systems.When submitting a patch, it is important to ensure that it adheres to the coding standards or guidelines set by the project. This increases the likelihood of the patch being accepted and merged into the codebase. Thoroughly testing the patch before submission is also crucial.In conclusion, there are multiple ways to submit a patch, and it is important to follow the appropriate procedures and guidelines set forth by the project. Using GitHub or a version control system like Git or SVN is recommended, but sending patches through the mailing list as attachments is also an option. Adhering to coding standards and thoroughly testing the patch are essential for increasing its chances of being accepted. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Stealth-Addresses.xml b/static/bitcoin-dev/March_2014/combined_Stealth-Addresses.xml index 0738d121fd..b07d56a3b6 100644 --- a/static/bitcoin-dev/March_2014/combined_Stealth-Addresses.xml +++ b/static/bitcoin-dev/March_2014/combined_Stealth-Addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Stealth Addresses - 2023-08-01T07:12:42.080079+00:00 + 2025-10-11T21:34:35.885947+00:00 + python-feedgen Dan Carter 2014-03-06 12:23:40+00:00 @@ -307,13 +308,13 @@ - python-feedgen + 2 Combined summary - Stealth Addresses - 2023-08-01T07:12:42.081104+00:00 + 2025-10-11T21:34:35.886190+00:00 - In a series of email exchanges, developers Peter Todd and Jeremy Spilman discussed various aspects of implementing stealth addresses in Bitcoin. They discussed using a master shared secret to derive per-pubkey secrets and the possibility of adding a counter to the hash function to improve stealthiness. They also explored the use of multi-sig and P2SH outputs for better anonymity and compatibility with other wallets.In another email exchange, Spilman asked why two EC points were not used in the stealth address. Todd explained that he had implemented both pubKeys in a 2-of-2 multisig instead, to prevent false positives on the online detection key while funds are still controlled by the payer. They also discussed the process of nonce recovery with ECDH and the need for defining a reasonable stealth address spec.The conversation then shifted to integrating stealth addresses into OpenPGP keys or x.509 certs, with the aim of making them usable for P2P payments. Todd suggested replacing static address text with new 'href=bitcoin:xSTL...' URIs to encourage their usage. He also emphasized the importance of identifying the recipient and proposed adding stealth addresses to the Output message rather than the PaymentDetails field.In a separate email exchange, Spilman and Todd discussed the implementation of stealth addresses for Payment Protocol. They debated the feasibility of certain approaches, such as adding a prefix to the OP_RETURN TxOut and symmetric encryption of P. Privacy risks and potential reduced anonymity sets were considered in these discussions.Other topics covered included the under-addressed use case of non-transactional personal payments, the concept of sending "please pay me" messages, and the differences between Reiner's proposal and stealth addresses. The advantages and complexities of different payment schemes were examined, including the use of BIP32 branches and the necessity of bidirectional communication.Overall, these email exchanges shed light on the technical considerations and challenges involved in implementing stealth addresses in Bitcoin, as well as the potential use cases and benefits they offer.The scriptPubKey/transaction generation scheme known as Stealth Address is designed to allow payees to share a single, fixed address with payors. This enables efficient, private, reliable, and non-interactive fund transfers. The generated scriptPubKey must be unique globally and only spendable by the intended payee. It is essential that this method is fully deterministic so that funds can be recovered using a wallet seed and blockchain data for both the payee and the payor.Importantly, the scheme must be compatible with CoinJoin, a privacy-enhancing technique, and should not reveal any information to the payee about which transaction inputs were used to make payments to them. Additionally, it offers the flexibility to trade off anonymity set size for decreased bandwidth and CPU usage. This can be achieved by allowing the payee to specify that payments matching a short prefix, k, are acceptable.An alternative approach to increase efficiency could involve using bare OP_CHECK(MULTI)SIG outputs to hold the nonce pubkey. For multisig support, the scheme must allow for the specification of n-of-m master pubkeys using the nonce to generate derived ones.It is worth noting that addresses generated using this method will be slightly longer than standard Bitcoin addresses. 2014-03-06T12:23:40+00:00 + In a series of email exchanges, developers Peter Todd and Jeremy Spilman discussed various aspects of implementing stealth addresses in Bitcoin. They discussed using a master shared secret to derive per-pubkey secrets and the possibility of adding a counter to the hash function to improve stealthiness. They also explored the use of multi-sig and P2SH outputs for better anonymity and compatibility with other wallets.In another email exchange, Spilman asked why two EC points were not used in the stealth address. Todd explained that he had implemented both pubKeys in a 2-of-2 multisig instead, to prevent false positives on the online detection key while funds are still controlled by the payer. They also discussed the process of nonce recovery with ECDH and the need for defining a reasonable stealth address spec.The conversation then shifted to integrating stealth addresses into OpenPGP keys or x.509 certs, with the aim of making them usable for P2P payments. Todd suggested replacing static address text with new 'href=bitcoin:xSTL...' URIs to encourage their usage. He also emphasized the importance of identifying the recipient and proposed adding stealth addresses to the Output message rather than the PaymentDetails field.In a separate email exchange, Spilman and Todd discussed the implementation of stealth addresses for Payment Protocol. They debated the feasibility of certain approaches, such as adding a prefix to the OP_RETURN TxOut and symmetric encryption of P. Privacy risks and potential reduced anonymity sets were considered in these discussions.Other topics covered included the under-addressed use case of non-transactional personal payments, the concept of sending "please pay me" messages, and the differences between Reiner's proposal and stealth addresses. The advantages and complexities of different payment schemes were examined, including the use of BIP32 branches and the necessity of bidirectional communication.Overall, these email exchanges shed light on the technical considerations and challenges involved in implementing stealth addresses in Bitcoin, as well as the potential use cases and benefits they offer.The scriptPubKey/transaction generation scheme known as Stealth Address is designed to allow payees to share a single, fixed address with payors. This enables efficient, private, reliable, and non-interactive fund transfers. The generated scriptPubKey must be unique globally and only spendable by the intended payee. It is essential that this method is fully deterministic so that funds can be recovered using a wallet seed and blockchain data for both the payee and the payor.Importantly, the scheme must be compatible with CoinJoin, a privacy-enhancing technique, and should not reveal any information to the payee about which transaction inputs were used to make payments to them. Additionally, it offers the flexibility to trade off anonymity set size for decreased bandwidth and CPU usage. This can be achieved by allowing the payee to specify that payments matching a short prefix, k, are acceptable.An alternative approach to increase efficiency could involve using bare OP_CHECK(MULTI)SIG outputs to hold the nonce pubkey. For multisig support, the scheme must allow for the specification of n-of-m master pubkeys using the nonce to generate derived ones.It is worth noting that addresses generated using this method will be slightly longer than standard Bitcoin addresses. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Sudden-temporary-drop-in-reachable-nodes-.xml b/static/bitcoin-dev/March_2014/combined_Sudden-temporary-drop-in-reachable-nodes-.xml index 857faf61af..f351faf5b8 100644 --- a/static/bitcoin-dev/March_2014/combined_Sudden-temporary-drop-in-reachable-nodes-.xml +++ b/static/bitcoin-dev/March_2014/combined_Sudden-temporary-drop-in-reachable-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Sudden temporary drop in reachable nodes? - 2023-08-01T08:04:04.283871+00:00 + 2025-10-11T21:34:44.382654+00:00 + python-feedgen Addy Yeow 2014-03-26 20:10:56+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Sudden temporary drop in reachable nodes? - 2023-08-01T08:04:04.283871+00:00 + 2025-10-11T21:34:44.382803+00:00 - In response to the inquiry, Addy, a crawler operator, explained that the drop in reachable nodes on http://getaddr.bitnodes.io/dashboard/ was not a technical glitch but rather a result of restarting the crawler for updates. This temporary disconnection from all reachable nodes caused the significant drop in reachable nodes observed on March 25th, between 7:20 pm and 9:35 pm.Addy further clarified that it took approximately 15 minutes or 3 snapshots before the crawler stabilized again after the restart. This suggests that the drop in reachable nodes was a brief disruption in the monitoring system rather than an actual network event affecting the Bitcoin network.In light of this incident, Addy mentioned that they will consider annotating these drops with a note in order to provide transparency and alleviate concerns about similar drops in the future. This annotation would help users of the monitoring system understand that such drops are not indicative of network issues but rather a result of necessary maintenance and updates being performed on the crawler.Overall, Addy's explanation provides clarity on the drop in reachable nodes observed on http://getaddr.bitnodes.io/dashboard/. It highlights that the drop was a temporary disruption caused by restarting the crawler for updates, rather than a network issue impacting the Bitcoin network. By considering annotating these drops with a note, Addy aims to address concerns and ensure transparency in the monitoring system. 2014-03-26T20:10:56+00:00 + In response to the inquiry, Addy, a crawler operator, explained that the drop in reachable nodes on http://getaddr.bitnodes.io/dashboard/ was not a technical glitch but rather a result of restarting the crawler for updates. This temporary disconnection from all reachable nodes caused the significant drop in reachable nodes observed on March 25th, between 7:20 pm and 9:35 pm.Addy further clarified that it took approximately 15 minutes or 3 snapshots before the crawler stabilized again after the restart. This suggests that the drop in reachable nodes was a brief disruption in the monitoring system rather than an actual network event affecting the Bitcoin network.In light of this incident, Addy mentioned that they will consider annotating these drops with a note in order to provide transparency and alleviate concerns about similar drops in the future. This annotation would help users of the monitoring system understand that such drops are not indicative of network issues but rather a result of necessary maintenance and updates being performed on the crawler.Overall, Addy's explanation provides clarity on the drop in reachable nodes observed on http://getaddr.bitnodes.io/dashboard/. It highlights that the drop was a temporary disruption caused by restarting the crawler for updates, rather than a network issue impacting the Bitcoin network. By considering annotating these drops with a note, Addy aims to address concerns and ensure transparency in the monitoring system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_Tree-chains-preliminary-summary.xml b/static/bitcoin-dev/March_2014/combined_Tree-chains-preliminary-summary.xml index 51ec7ea210..93b0d932a0 100644 --- a/static/bitcoin-dev/March_2014/combined_Tree-chains-preliminary-summary.xml +++ b/static/bitcoin-dev/March_2014/combined_Tree-chains-preliminary-summary.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Tree-chains preliminary summary - 2023-08-01T08:01:59.097124+00:00 + 2025-10-11T21:34:25.265762+00:00 + python-feedgen Gregory Sanders 2014-08-03 17:23:07+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Tree-chains preliminary summary - 2023-08-01T08:01:59.097124+00:00 + 2025-10-11T21:34:25.265948+00:00 - In the Bitcoin community, discussions are taking place regarding the need to maintain a friendly and professional environment on the mailing list. Some members suggest implementing a moderation policy or negative reinforcement to discourage hostile behavior and promote collaboration and constructive discussions.One topic of conversation is scalability in the Bitcoin network. Peter Todd argues that Bitcoin doesn't scale effectively due to the bandwidth required to update the UTXO set, leading to scaling issues. On the other hand, Gavin Andresen disagrees and refers to Satoshi's original thoughts on scaling, envisioning a large number of mining nodes and lightweight SPV users. However, Todd points out that the low number of mining pools is due to miners finding it unfeasible to mine on their own. He proposes tree chains as a solution to decentralization and scalability.Merged mining is also discussed, with some expressing concerns about draining the pegging pool and potential attacks. However, others argue that merged mining can indirectly solve scalability problems. Additionally, there is a conversation about reducing dependence on miner validation through the use of ZK-SNARKS.Overall, these conversations highlight different perspectives within the Bitcoin community on topics such as scalability, decentralization, and the importance of maintaining a friendly and professional environment for technical discussions. There are ongoing debates and proposed solutions to address these issues, but further research and testing will be necessary to ensure the security and integrity of the network. 2014-08-03T17:23:07+00:00 + In the Bitcoin community, discussions are taking place regarding the need to maintain a friendly and professional environment on the mailing list. Some members suggest implementing a moderation policy or negative reinforcement to discourage hostile behavior and promote collaboration and constructive discussions.One topic of conversation is scalability in the Bitcoin network. Peter Todd argues that Bitcoin doesn't scale effectively due to the bandwidth required to update the UTXO set, leading to scaling issues. On the other hand, Gavin Andresen disagrees and refers to Satoshi's original thoughts on scaling, envisioning a large number of mining nodes and lightweight SPV users. However, Todd points out that the low number of mining pools is due to miners finding it unfeasible to mine on their own. He proposes tree chains as a solution to decentralization and scalability.Merged mining is also discussed, with some expressing concerns about draining the pegging pool and potential attacks. However, others argue that merged mining can indirectly solve scalability problems. Additionally, there is a conversation about reducing dependence on miner validation through the use of ZK-SNARKS.Overall, these conversations highlight different perspectives within the Bitcoin community on topics such as scalability, decentralization, and the importance of maintaining a friendly and professional environment for technical discussions. There are ongoing debates and proposed solutions to address these issues, but further research and testing will be necessary to ensure the security and integrity of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_bip-0021-and-bip-0072-ambiguities-mistakes.xml b/static/bitcoin-dev/March_2014/combined_bip-0021-and-bip-0072-ambiguities-mistakes.xml index 946b009ae8..10d4bea5d3 100644 --- a/static/bitcoin-dev/March_2014/combined_bip-0021-and-bip-0072-ambiguities-mistakes.xml +++ b/static/bitcoin-dev/March_2014/combined_bip-0021-and-bip-0072-ambiguities-mistakes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bip-0021 and bip-0072 ambiguities & mistakes - 2023-08-01T07:52:24.887848+00:00 + 2025-10-11T21:34:57.124508+00:00 + python-feedgen William Swanson 2014-03-07 02:16:14+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - bip-0021 and bip-0072 ambiguities & mistakes - 2023-08-01T07:52:24.887848+00:00 + 2025-10-11T21:34:57.124682+00:00 - On March 6, 2014, Mike Hearn requested a pull request from William regarding QR code escaping. William submitted the pull request and noted that the bitcoin-qt client's behavior should now align better with the recommended practices outlined in the RFC. The de-escaped QR codes resulting from this adjustment are also reportedly more aesthetically pleasing.Although it is unclear what project or codebase this conversation is taking place in, someone has requested a pull request and mentioned that escaping doesn't seem to be necessary, with de-escaped QR codes appearing much nicer. The message references an HTML attachment, but its relation to the conversation remains unclear.The writer of the conversation wants to create a parser for bip-0021 URIs with the new bip-0072 payment parameters, aiming for complete accuracy. They highlight that the internet RFC 3986 governs the general syntax for URIs and suggest that any bitcoin URI scheme should use it instead of the earlier RFCs.However, bip-0021 does not mention RFC 3986, while bip-0072 explicitly refers to RFC 1738, which is obsolete. The old standard requires more escapes than necessary, so updating bip-0072 to refer to RFC 3986 would allow shorter and more readable bitcoin URIs.Another issue is that neither bip describes what to do with international characters. The writer believes that character encoding needs to be defined and suggests that all new URI schemes use UTF-8 as their encoding, as recommended by the RFC. Therefore, they propose adding it into bip-0021.Lastly, the writer notes an error in the bip-0021 BNF grammar, which fails to mention the '&' separator between query elements. The writer seeks clarification on the procedure for correcting these issues and suggests submitting a pull request with the changes.Furthermore, it is worth mentioning that the bitcoin-qt client already uses QUrl to parse bitcoin URIs based on RFC 3986, indicating that it may have already implemented these suggestions. 2014-03-07T02:16:14+00:00 + On March 6, 2014, Mike Hearn requested a pull request from William regarding QR code escaping. William submitted the pull request and noted that the bitcoin-qt client's behavior should now align better with the recommended practices outlined in the RFC. The de-escaped QR codes resulting from this adjustment are also reportedly more aesthetically pleasing.Although it is unclear what project or codebase this conversation is taking place in, someone has requested a pull request and mentioned that escaping doesn't seem to be necessary, with de-escaped QR codes appearing much nicer. The message references an HTML attachment, but its relation to the conversation remains unclear.The writer of the conversation wants to create a parser for bip-0021 URIs with the new bip-0072 payment parameters, aiming for complete accuracy. They highlight that the internet RFC 3986 governs the general syntax for URIs and suggest that any bitcoin URI scheme should use it instead of the earlier RFCs.However, bip-0021 does not mention RFC 3986, while bip-0072 explicitly refers to RFC 1738, which is obsolete. The old standard requires more escapes than necessary, so updating bip-0072 to refer to RFC 3986 would allow shorter and more readable bitcoin URIs.Another issue is that neither bip describes what to do with international characters. The writer believes that character encoding needs to be defined and suggests that all new URI schemes use UTF-8 as their encoding, as recommended by the RFC. Therefore, they propose adding it into bip-0021.Lastly, the writer notes an error in the bip-0021 BNF grammar, which fails to mention the '&' separator between query elements. The writer seeks clarification on the procedure for correcting these issues and suggests submitting a pull request with the changes.Furthermore, it is worth mentioning that the bitcoin-qt client already uses QUrl to parse bitcoin URIs based on RFC 3986, indicating that it may have already implemented these suggestions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_moving-the-default-display-to-mbtc.xml b/static/bitcoin-dev/March_2014/combined_moving-the-default-display-to-mbtc.xml index 7075f030de..75669d1c79 100644 --- a/static/bitcoin-dev/March_2014/combined_moving-the-default-display-to-mbtc.xml +++ b/static/bitcoin-dev/March_2014/combined_moving-the-default-display-to-mbtc.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - moving the default display to mbtc - 2023-08-01T06:36:29.548885+00:00 + 2025-10-11T21:34:50.749520+00:00 + python-feedgen Jannis Froese 2014-05-03 18:46:37+00:00 @@ -451,13 +452,13 @@ - python-feedgen + 2 Combined summary - moving the default display to mbtc - 2023-08-01T06:36:29.551884+00:00 + 2025-10-11T21:34:50.749800+00:00 - The ongoing debate in the Bitcoin community revolves around the unit of measurement for Bitcoin transactions. Andreas Schildbach argues that users prioritize the amount in their local currency, while Tamas Blummer suggests denominations similar to traditional currencies. Jeff Garzik proposes uBTC as a user-friendly option, and MultiBit HD offers customizable configuration options. The conversation highlights the complexity of determining the best unit of measurement for Bitcoin.There are suggestions to use symbols like XUB or uBTC as the naming convention for microbitcoins. It is emphasized that changes should not be made without user permission and that the system should take care of users who make mistakes when entering values. Additionally, the discussion highlights the need for a standardized format that empowers users to use all available decimal places and suggests the use of official test cases for wallet software to ensure desired behavior.The discussion also touches on the perception of Bitcoin prices in different currencies. Schildbach argues that users are not confused by the use of mBTC as a unit of measurement, while Blummer suggests that Bitcoin would be more widely accepted if it had prices and fractions like other currencies. The debate continues with Garzik expressing disappointment over the switch to mBTC and suggesting uBTC as a more user-friendly option.In November 2013, the Bitcoin community engaged in discussions regarding the unit of measurement for Bitcoin transactions. The main proposal was to switch from mBTC (millibitcoin) to uBTC (microbitcoin) as the standard unit. Advocates of uBTC argued that it would be more intuitive for users, as two decimal places are becoming standard for new national currencies. They believed that using uBTC would bring Bitcoin closer to everyday human scale numbers. However, there were concerns about confusion and potential mistakes leading to lost coins, as well as the perception of uBTC being less valuable.Alan Reiner expressed concerns about changing the base unit of an established system, stating that it could cause more problems than it's worth. Mark Friedenbach supported skipping mBTC and moving straight to uBTC, emphasizing the need for user-friendliness. He suggested switching currency symbols to XBT or NBC (New Bitcoin) to alleviate confusion. The discussion also touched on other issues, such as displaying fees and trading rates in BTC or MBTC, addressing terminology fix-ups, and the use of confirmations and addresses. The goal was to promote consistency and clarity in Bitcoin transactions.The rise in the value of Bitcoin raised concerns among new users who found the high price intimidating. A straw poll conducted previously showed that a majority of respondents favored switching to a system allowing for fractional amounts of Bitcoin to be purchased. Satoshi's comments indicated that while there are only 21 million coins available, there are six decimal places internally, allowing for a total of eight decimal places. It was suggested to change the default display in software to mbtc, with a dropdown display option initially and eventually becoming the default. This change aimed to make working with small numbers less tiresome and more user-friendly.Overall, the discussions focused on optimizing the user experience in Bitcoin transactions by considering the unit of measurement, currency symbols, fee displays, and terminology fixes. The community aimed to address concerns and promote clarity while ensuring a smooth transition for users. The MultiBit HD wallet offered customizable options for icons and symbols, following NIST guidelines for SI unit symbol representation. However, there was disappointment expressed by Jeff Garzik when Bitcoin Wallet moved to mBTC instead of uBTC. He believed that the consensus was for uBTC and another decimal place transition would cause confusion.Wladimir, on the other hand, responded that getting people to care about this issue was difficult and couldn't blame Andreas for making the change to mBTC since it seemed to be catching on in the community. The conversation also touched upon the issue of terminology for Bitcoin addresses. Mark Friedenbach proposed changing the term "address" to "key id" to avoid misleading associations with physical addresses or accounts. Other suggestions included using "invoice id" or "payment address" instead of "address" to avoid confusion with email addresses.The discussion also addressed the standardization of Bitcoin units and terminology. Alex Kravets suggested Bitcoin currency code standardization, proposing the use of XBT as the currency code and defining one bit as 100 satoshis. Eugen Leitl opposed this idea and suggested using SI prefixes instead. Alan Reiner supported the XBT idea but disagreed with the term "micro bitcoins", suggesting alternatives like "bits" or "microbits". The goal was to find a standardized way to represent Bitcoin units to avoid confusion among users.Usability issues in Bitcoin transactions were also discussed, particularly the difficulty of dealing with small amounts and the learning curve of Bitcoin. Suggestions were made to simplify bitcoin transactions by displaying fees and trading rates in BTC or MBTC instead of fractions of bitcoins. The community aimed to find consensus on a path forward to avoid fragmentation and confusion in the market.In conclusion, the discussions among Bitcoin developers 2014-05-03T18:46:37+00:00 + The ongoing debate in the Bitcoin community revolves around the unit of measurement for Bitcoin transactions. Andreas Schildbach argues that users prioritize the amount in their local currency, while Tamas Blummer suggests denominations similar to traditional currencies. Jeff Garzik proposes uBTC as a user-friendly option, and MultiBit HD offers customizable configuration options. The conversation highlights the complexity of determining the best unit of measurement for Bitcoin.There are suggestions to use symbols like XUB or uBTC as the naming convention for microbitcoins. It is emphasized that changes should not be made without user permission and that the system should take care of users who make mistakes when entering values. Additionally, the discussion highlights the need for a standardized format that empowers users to use all available decimal places and suggests the use of official test cases for wallet software to ensure desired behavior.The discussion also touches on the perception of Bitcoin prices in different currencies. Schildbach argues that users are not confused by the use of mBTC as a unit of measurement, while Blummer suggests that Bitcoin would be more widely accepted if it had prices and fractions like other currencies. The debate continues with Garzik expressing disappointment over the switch to mBTC and suggesting uBTC as a more user-friendly option.In November 2013, the Bitcoin community engaged in discussions regarding the unit of measurement for Bitcoin transactions. The main proposal was to switch from mBTC (millibitcoin) to uBTC (microbitcoin) as the standard unit. Advocates of uBTC argued that it would be more intuitive for users, as two decimal places are becoming standard for new national currencies. They believed that using uBTC would bring Bitcoin closer to everyday human scale numbers. However, there were concerns about confusion and potential mistakes leading to lost coins, as well as the perception of uBTC being less valuable.Alan Reiner expressed concerns about changing the base unit of an established system, stating that it could cause more problems than it's worth. Mark Friedenbach supported skipping mBTC and moving straight to uBTC, emphasizing the need for user-friendliness. He suggested switching currency symbols to XBT or NBC (New Bitcoin) to alleviate confusion. The discussion also touched on other issues, such as displaying fees and trading rates in BTC or MBTC, addressing terminology fix-ups, and the use of confirmations and addresses. The goal was to promote consistency and clarity in Bitcoin transactions.The rise in the value of Bitcoin raised concerns among new users who found the high price intimidating. A straw poll conducted previously showed that a majority of respondents favored switching to a system allowing for fractional amounts of Bitcoin to be purchased. Satoshi's comments indicated that while there are only 21 million coins available, there are six decimal places internally, allowing for a total of eight decimal places. It was suggested to change the default display in software to mbtc, with a dropdown display option initially and eventually becoming the default. This change aimed to make working with small numbers less tiresome and more user-friendly.Overall, the discussions focused on optimizing the user experience in Bitcoin transactions by considering the unit of measurement, currency symbols, fee displays, and terminology fixes. The community aimed to address concerns and promote clarity while ensuring a smooth transition for users. The MultiBit HD wallet offered customizable options for icons and symbols, following NIST guidelines for SI unit symbol representation. However, there was disappointment expressed by Jeff Garzik when Bitcoin Wallet moved to mBTC instead of uBTC. He believed that the consensus was for uBTC and another decimal place transition would cause confusion.Wladimir, on the other hand, responded that getting people to care about this issue was difficult and couldn't blame Andreas for making the change to mBTC since it seemed to be catching on in the community. The conversation also touched upon the issue of terminology for Bitcoin addresses. Mark Friedenbach proposed changing the term "address" to "key id" to avoid misleading associations with physical addresses or accounts. Other suggestions included using "invoice id" or "payment address" instead of "address" to avoid confusion with email addresses.The discussion also addressed the standardization of Bitcoin units and terminology. Alex Kravets suggested Bitcoin currency code standardization, proposing the use of XBT as the currency code and defining one bit as 100 satoshis. Eugen Leitl opposed this idea and suggested using SI prefixes instead. Alan Reiner supported the XBT idea but disagreed with the term "micro bitcoins", suggesting alternatives like "bits" or "microbits". The goal was to find a standardized way to represent Bitcoin units to avoid confusion among users.Usability issues in Bitcoin transactions were also discussed, particularly the difficulty of dealing with small amounts and the learning curve of Bitcoin. Suggestions were made to simplify bitcoin transactions by displaying fees and trading rates in BTC or MBTC instead of fractions of bitcoins. The community aimed to find consensus on a path forward to avoid fragmentation and confusion in the market.In conclusion, the discussions among Bitcoin developers - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_python-bitcoinlib-v0-1-release-a-low-level-Python2-3-interface-to-the-Bitcoin-protocol.xml b/static/bitcoin-dev/March_2014/combined_python-bitcoinlib-v0-1-release-a-low-level-Python2-3-interface-to-the-Bitcoin-protocol.xml index 8f00d20820..7567d9f649 100644 --- a/static/bitcoin-dev/March_2014/combined_python-bitcoinlib-v0-1-release-a-low-level-Python2-3-interface-to-the-Bitcoin-protocol.xml +++ b/static/bitcoin-dev/March_2014/combined_python-bitcoinlib-v0-1-release-a-low-level-Python2-3-interface-to-the-Bitcoin-protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - python-bitcoinlib v0.1 release - a low-level Python2/3 interface to the Bitcoin protocol - 2023-08-01T07:58:08.203909+00:00 + 2025-10-11T21:35:16.386722+00:00 + python-feedgen Drak 2014-03-15 18:04:37+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - python-bitcoinlib v0.1 release - a low-level Python2/3 interface to the Bitcoin protocol - 2023-08-01T07:58:08.204910+00:00 + 2025-10-11T21:35:16.386885+00:00 - On March 15, 2014, Peter Todd announced the release of v0.1 of Python-bitcoinlib, a Python2/3 library that offers an easy interface to the Bitcoin data structures and protocol. The approach is low-level and "ground up", with a focus on providing tools to manipulate the internals of how Bitcoin works in a Pythonic way, without straying far from the Bitcoin Core implementation. The current status of the library as of v0.1 is that the support for data-structures related to transactions, scripting, addresses, and keys are all quite usable and the API is probably not going to change that much. Bitcoin Core RPC support is included and automatically converts the JSON to/from Python objects when appropriate. The release and others in the future are signed by Todd's PGP key, as well as every publicly pushed commit.Todd mentioned that he hasn't had any need for the p2p network-related code for some time, so it's not in good shape and lacks unittests; Bloom filters for one are missing the Merkle-block support to actually make them useful. But the RPC support makes up for that for many uses.Jeff Garzik responded to Todd's announcement and said that it sounds great and he is glad to see this with a more active maintainer. Maintaining -three- client libs was a bit much for him.Lastly, Drak asked if it would make sense to pull the stuff in and add Peter with commit access since Todd's repo is top of the fork tree.Peter Todd, a Bitcoin core developer, has released v0.1 of his Python2/3 library for an easy interface to the bitcoin data structures and protocol. The approach is low-level and “ground up,” with a focus on providing tools to manipulate the internals of how Bitcoin works in a Pythonic way without straying far from the Bitcoin Core implementation. The current status of the library as of v0.1 is that the support for data-structures related to transactions, scripting, addresses, and keys are all quite usable and the API is probably not going to change that much. Bitcoin Core RPC support is included and automatically converts the JSON to/from Python objects when appropriate. EvalScript(), VerifyScript(), and SignatureHash() are all functional and pass all the Bitcoin Core unittests, as well as a few that are still yet to be merged. You will find some examples for signing pay2script-hash and p2sh txouts in the examples/ directory; Todd personally used the transaction signing functionality to make up a set of unittests related to OP_CODESEPARATOR and FindAndDelete() recently. Finally, his dust-b-gone script is another good example, specifically of the RPC functionality.The email thread reveals a discussion between Jeff Garzik, a Bitcoin core developer and open source evangelist, and Peter Todd, discussing the python-bitcoinlib dependency. Todd states that the ngccbase Colored Coin client has added his fork of python-bitcoinlib as a dependency. He further mentions the existence of a rudimentary python-bitcoinlib package in archlinux. Todd attributes the bulk of the code structure of his fork to Jeff Garzik's implementation, while also clarifying that he has made some changes to "pythonize" the code. In turn, Garzik credits the project's inception to ArtForz, who started the project with his half-a-node. Todd provides a link to Garzik's original implementation on Github.Peter Todd, a software developer, noticed that the ngccbase Colored Coin client added a python-bitcoinlib dependency, specifically his fork. He also mentioned that there is now a rudimentary python-bitcoinlib package in Arch Linux. Todd's fork is based on Jeff Garzik's implementation, and the bulk of the code structure is his work, modulo "pythonizing" that he has done. Todd provided a GitHub link to Garzik's implementation for those who are interested in its history.The developer, Peter Todd, has released a new version (v0.1) of his python-bitcoinlib library on Github. The library provides easy access to Bitcoin's data structures and protocol in a Pythonic way. It includes support for all data-structures related to transactions, scripting, addresses, and keys, which is quite usable; although some p2p network-related code is missing. Also, the API will probably not change that much. The release is signed by Peter Todd's PGP key, as well as every publicly pushed commit. 2014-03-15T18:04:37+00:00 + On March 15, 2014, Peter Todd announced the release of v0.1 of Python-bitcoinlib, a Python2/3 library that offers an easy interface to the Bitcoin data structures and protocol. The approach is low-level and "ground up", with a focus on providing tools to manipulate the internals of how Bitcoin works in a Pythonic way, without straying far from the Bitcoin Core implementation. The current status of the library as of v0.1 is that the support for data-structures related to transactions, scripting, addresses, and keys are all quite usable and the API is probably not going to change that much. Bitcoin Core RPC support is included and automatically converts the JSON to/from Python objects when appropriate. The release and others in the future are signed by Todd's PGP key, as well as every publicly pushed commit.Todd mentioned that he hasn't had any need for the p2p network-related code for some time, so it's not in good shape and lacks unittests; Bloom filters for one are missing the Merkle-block support to actually make them useful. But the RPC support makes up for that for many uses.Jeff Garzik responded to Todd's announcement and said that it sounds great and he is glad to see this with a more active maintainer. Maintaining -three- client libs was a bit much for him.Lastly, Drak asked if it would make sense to pull the stuff in and add Peter with commit access since Todd's repo is top of the fork tree.Peter Todd, a Bitcoin core developer, has released v0.1 of his Python2/3 library for an easy interface to the bitcoin data structures and protocol. The approach is low-level and “ground up,” with a focus on providing tools to manipulate the internals of how Bitcoin works in a Pythonic way without straying far from the Bitcoin Core implementation. The current status of the library as of v0.1 is that the support for data-structures related to transactions, scripting, addresses, and keys are all quite usable and the API is probably not going to change that much. Bitcoin Core RPC support is included and automatically converts the JSON to/from Python objects when appropriate. EvalScript(), VerifyScript(), and SignatureHash() are all functional and pass all the Bitcoin Core unittests, as well as a few that are still yet to be merged. You will find some examples for signing pay2script-hash and p2sh txouts in the examples/ directory; Todd personally used the transaction signing functionality to make up a set of unittests related to OP_CODESEPARATOR and FindAndDelete() recently. Finally, his dust-b-gone script is another good example, specifically of the RPC functionality.The email thread reveals a discussion between Jeff Garzik, a Bitcoin core developer and open source evangelist, and Peter Todd, discussing the python-bitcoinlib dependency. Todd states that the ngccbase Colored Coin client has added his fork of python-bitcoinlib as a dependency. He further mentions the existence of a rudimentary python-bitcoinlib package in archlinux. Todd attributes the bulk of the code structure of his fork to Jeff Garzik's implementation, while also clarifying that he has made some changes to "pythonize" the code. In turn, Garzik credits the project's inception to ArtForz, who started the project with his half-a-node. Todd provides a link to Garzik's original implementation on Github.Peter Todd, a software developer, noticed that the ngccbase Colored Coin client added a python-bitcoinlib dependency, specifically his fork. He also mentioned that there is now a rudimentary python-bitcoinlib package in Arch Linux. Todd's fork is based on Jeff Garzik's implementation, and the bulk of the code structure is his work, modulo "pythonizing" that he has done. Todd provided a GitHub link to Garzik's implementation for those who are interested in its history.The developer, Peter Todd, has released a new version (v0.1) of his python-bitcoinlib library on Github. The library provides easy access to Bitcoin's data structures and protocol in a Pythonic way. It includes support for all data-structures related to transactions, scripting, addresses, and keys, which is quite usable; although some p2p network-related code is missing. Also, the API will probably not change that much. The release is signed by Peter Todd's PGP key, as well as every publicly pushed commit. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_secure-assigned-bitcoin-address-directory.xml b/static/bitcoin-dev/March_2014/combined_secure-assigned-bitcoin-address-directory.xml index 4ad9dde38f..c976e5aeae 100644 --- a/static/bitcoin-dev/March_2014/combined_secure-assigned-bitcoin-address-directory.xml +++ b/static/bitcoin-dev/March_2014/combined_secure-assigned-bitcoin-address-directory.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - secure assigned bitcoin address directory - 2023-08-01T08:30:54.658130+00:00 + 2025-10-11T21:33:59.771280+00:00 + python-feedgen Mike Hearn 2014-04-02 12:01:51+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - secure assigned bitcoin address directory - 2023-08-01T08:30:54.658130+00:00 + 2025-10-11T21:33:59.771502+00:00 - On the Bitcointalk forum, a discussion has emerged regarding the accessibility and verification of vanity addresses. Some users expressed an interest in making their vanity addresses easily accessible to others while also ensuring ownership verification. However, the current method of signing addresses and posting them on forums is deemed insecure.To address this concern, the possibility of utilizing PGP keyservers was raised. However, it was noted that this approach would only be suitable for single vanity addresses, limiting its effectiveness for multiple addresses.As a potential solution, the concept of webfinger was proposed. Webfinger would allow servers of businesses to confirm and validate ownership of specific addresses. This method holds promise for ensuring secure access and verification of vanity addresses.It remains uncertain if there are any existing plans or initiatives that specifically cater to this use case. The mention of BIP70, which involves Certificate Authorities, was made in relation to addressing this issue. However, it is unclear whether this solution fully resolves the problem at hand.Overall, the email thread showcased ongoing conversations and ideas among developers in the Bitcoin space, exploring various approaches to enhance security and improve the efficiency of Bitcoin transactions.For further information and insights on this topic, readers are encouraged to explore the provided links to the relevant discussions on the Bitcointalk forum. 2014-04-02T12:01:51+00:00 + On the Bitcointalk forum, a discussion has emerged regarding the accessibility and verification of vanity addresses. Some users expressed an interest in making their vanity addresses easily accessible to others while also ensuring ownership verification. However, the current method of signing addresses and posting them on forums is deemed insecure.To address this concern, the possibility of utilizing PGP keyservers was raised. However, it was noted that this approach would only be suitable for single vanity addresses, limiting its effectiveness for multiple addresses.As a potential solution, the concept of webfinger was proposed. Webfinger would allow servers of businesses to confirm and validate ownership of specific addresses. This method holds promise for ensuring secure access and verification of vanity addresses.It remains uncertain if there are any existing plans or initiatives that specifically cater to this use case. The mention of BIP70, which involves Certificate Authorities, was made in relation to addressing this issue. However, it is unclear whether this solution fully resolves the problem at hand.Overall, the email thread showcased ongoing conversations and ideas among developers in the Bitcoin space, exploring various approaches to enhance security and improve the efficiency of Bitcoin transactions.For further information and insights on this topic, readers are encouraged to explore the provided links to the relevant discussions on the Bitcointalk forum. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2014/combined_sorting-public-keys-for-p2sh-multisig-transactions.xml b/static/bitcoin-dev/March_2014/combined_sorting-public-keys-for-p2sh-multisig-transactions.xml index 8877134c18..6979842c71 100644 --- a/static/bitcoin-dev/March_2014/combined_sorting-public-keys-for-p2sh-multisig-transactions.xml +++ b/static/bitcoin-dev/March_2014/combined_sorting-public-keys-for-p2sh-multisig-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - sorting public keys for p2sh multisig transactions - 2023-08-01T07:57:04.333383+00:00 + 2025-10-11T21:34:14.631398+00:00 + python-feedgen devrandom 2014-03-12 19:42:44+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - sorting public keys for p2sh multisig transactions - 2023-08-01T07:57:04.333383+00:00 + 2025-10-11T21:34:14.631591+00:00 - Alan Reiner suggests using parallel trees to generate P2SH addresses after sorting the public keys lexicographically as strings. This means that the keys should be sorted based on their string representation. The writer of the discussion implemented sorting in JavaScript, sorting the keys as big endian numbers and filling in any leading zeros. However, the writer emphasizes that the specific method used is not important, as long as there is a standard way that everyone in the Bitcoin world agrees upon.In a P2SH multisig transaction, the serialized script includes multiple public keys and an OP_CHECKMULTISIG operation. The order of the public keys is crucial because it affects the resulting P2SH address. To ensure consistency, a standard sorting method needs to be established. There are two types of public keys: compressed and uncompressed. Compressed keys are shorter than uncompressed ones. Different sorting methods can be employed, such as treating the keys as strings, big endian numbers, or little endian numbers.Sorting the keys as strings may lead to unexpected results, as the length of the keys can influence the sorting order. For example, a compressed key could be ranked higher than an uncompressed one solely due to its shorter length. On the other hand, sorting the keys as big endian numbers would provide the correct order, ensuring that the uncompressed keys come before the compressed ones. The writer's implementation uses this method, sorting the keys as big endian numbers, and filling in any leading zeros to maintain consistency.In conclusion, establishing a standard way of sorting public keys for p2sh multisig transactions is crucial to ensure consistency and avoid potential issues. Sorting the keys as big endian numbers appears to be a suitable method, as it preserves the correct ordering regardless of the key type. It is vital for the Bitcoin community to agree on a standardized sorting approach to maintain compatibility and prevent any discrepancies. 2014-03-12T19:42:44+00:00 + Alan Reiner suggests using parallel trees to generate P2SH addresses after sorting the public keys lexicographically as strings. This means that the keys should be sorted based on their string representation. The writer of the discussion implemented sorting in JavaScript, sorting the keys as big endian numbers and filling in any leading zeros. However, the writer emphasizes that the specific method used is not important, as long as there is a standard way that everyone in the Bitcoin world agrees upon.In a P2SH multisig transaction, the serialized script includes multiple public keys and an OP_CHECKMULTISIG operation. The order of the public keys is crucial because it affects the resulting P2SH address. To ensure consistency, a standard sorting method needs to be established. There are two types of public keys: compressed and uncompressed. Compressed keys are shorter than uncompressed ones. Different sorting methods can be employed, such as treating the keys as strings, big endian numbers, or little endian numbers.Sorting the keys as strings may lead to unexpected results, as the length of the keys can influence the sorting order. For example, a compressed key could be ranked higher than an uncompressed one solely due to its shorter length. On the other hand, sorting the keys as big endian numbers would provide the correct order, ensuring that the uncompressed keys come before the compressed ones. The writer's implementation uses this method, sorting the keys as big endian numbers, and filling in any leading zeros to maintain consistency.In conclusion, establishing a standard way of sorting public keys for p2sh multisig transactions is crucial to ensure consistency and avoid potential issues. Sorting the keys as big endian numbers appears to be a suitable method, as it preserves the correct ordering regardless of the key type. It is vital for the Bitcoin community to agree on a standardized sorting approach to maintain compatibility and prevent any discrepancies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_-network-disruption-as-a-service-and-proof-of-local-storage.xml b/static/bitcoin-dev/March_2015/combined_-network-disruption-as-a-service-and-proof-of-local-storage.xml index 1195d6aa2f..6bdcbaf3bc 100644 --- a/static/bitcoin-dev/March_2015/combined_-network-disruption-as-a-service-and-proof-of-local-storage.xml +++ b/static/bitcoin-dev/March_2015/combined_-network-disruption-as-a-service-and-proof-of-local-storage.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - "network disruption as a service" and proof of local storage - 2023-08-01T12:04:00.763556+00:00 + Combined summary - "network disruption as a service" and proof of local storage + 2025-10-11T21:56:16.810919+00:00 + python-feedgen Sergio Lerner 2015-04-01 02:34:56+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 - Combined summary - "network disruption as a service" and proof of local storage - 2023-08-01T12:04:00.763556+00:00 + Combined summary - "network disruption as a service" and proof of local storage + 2025-10-11T21:56:16.811091+00:00 - The protocol described in the given context aims to enable a node to prove to another peer that it is storing a local copy of a public file, such as the blockchain, without requiring additional resources. This is achieved through the use of asymmetric-time-encoding, which encodes the blockchain in a way that takes significantly more time to write than to read.There are two protocols proposed to prove local possession. The first protocol involves both the prover and verifier paying a small cost. In this protocol, the verifier sends a seed to the prover, who must respond with the hash of the decrypted blocks within a certain time limit. The second protocol requires the prover to pay a higher cost, while the verifier pays a negligible cost. In this case, the verifier chooses a seed and pre-computes the encrypted blocks derived from the seed using the prover's IP. The seed is then sent to the prover, who must respond with the hash of the encrypted blocks within a certain time limit.These protocols can be made available by the client under different states. New nodes are initially only allowed to request protocol 2, and once they have completed it, they are permitted to periodically perform protocol 1. It is also possible to restrict the challenge-response to a specific portion of the blockchain.One of the key advantages of this proposal over GMaxwell's proposal is that each peer only needs to build a single table, which represents the encrypted blockchain. This means that it could still be possible for a single peer to establish thousands of connections to the network. Additionally, Sergio's proposal allows for a larger time gap between a good peer and a malicious peer by selecting a larger p value. However, it is important to note that an attacker's IP can be easily detected, and measures can be taken to restrict the challenge-response to a specific portion of the blockchain.In the context of the Bitcoin network, the problem of pseudo-nodes is a significant concern. One potential solution to this issue is requiring each peer to demonstrate resource consumption before being allowed to connect to other peers. Gmaxwell proposed Proof of Storage as a solution, while Sergio introduced the protocol called "Proof of Local Storage." Unlike Gmaxwell's proposal, Proof of Local Storage does not require additional data storage and allows peers to prove that they are maintaining a full copy of the blockchain.Overall, the discussions revolve around finding ways to improve blockchain resiliency through proof of storage, ensuring more full nodes on the network, and detecting non-full nodes with less computation. The proposed protocols aim to provide a reliable mechanism for discerning a local copy's existence without imposing substantial encoding costs. 2015-04-01T02:34:56+00:00 + The protocol described in the given context aims to enable a node to prove to another peer that it is storing a local copy of a public file, such as the blockchain, without requiring additional resources. This is achieved through the use of asymmetric-time-encoding, which encodes the blockchain in a way that takes significantly more time to write than to read.There are two protocols proposed to prove local possession. The first protocol involves both the prover and verifier paying a small cost. In this protocol, the verifier sends a seed to the prover, who must respond with the hash of the decrypted blocks within a certain time limit. The second protocol requires the prover to pay a higher cost, while the verifier pays a negligible cost. In this case, the verifier chooses a seed and pre-computes the encrypted blocks derived from the seed using the prover's IP. The seed is then sent to the prover, who must respond with the hash of the encrypted blocks within a certain time limit.These protocols can be made available by the client under different states. New nodes are initially only allowed to request protocol 2, and once they have completed it, they are permitted to periodically perform protocol 1. It is also possible to restrict the challenge-response to a specific portion of the blockchain.One of the key advantages of this proposal over GMaxwell's proposal is that each peer only needs to build a single table, which represents the encrypted blockchain. This means that it could still be possible for a single peer to establish thousands of connections to the network. Additionally, Sergio's proposal allows for a larger time gap between a good peer and a malicious peer by selecting a larger p value. However, it is important to note that an attacker's IP can be easily detected, and measures can be taken to restrict the challenge-response to a specific portion of the blockchain.In the context of the Bitcoin network, the problem of pseudo-nodes is a significant concern. One potential solution to this issue is requiring each peer to demonstrate resource consumption before being allowed to connect to other peers. Gmaxwell proposed Proof of Storage as a solution, while Sergio introduced the protocol called "Proof of Local Storage." Unlike Gmaxwell's proposal, Proof of Local Storage does not require additional data storage and allows peers to prove that they are maintaining a full copy of the blockchain.Overall, the discussions revolve around finding ways to improve blockchain resiliency through proof of storage, ensuring more full nodes on the network, and detecting non-full nodes with less computation. The proposed protocols aim to provide a reliable mechanism for discerning a local copy's existence without imposing substantial encoding costs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Address-Expiration-to-Prevent-Reuse.xml b/static/bitcoin-dev/March_2015/combined_Address-Expiration-to-Prevent-Reuse.xml index 0ba87523bd..51ca485da1 100644 --- a/static/bitcoin-dev/March_2015/combined_Address-Expiration-to-Prevent-Reuse.xml +++ b/static/bitcoin-dev/March_2015/combined_Address-Expiration-to-Prevent-Reuse.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Address Expiration to Prevent Reuse - 2023-08-01T12:10:53.102726+00:00 + 2025-10-11T21:56:42.308805+00:00 + python-feedgen odinn 2015-06-13 04:52:25+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Address Expiration to Prevent Reuse - 2023-08-01T12:10:53.102726+00:00 + 2025-10-11T21:56:42.308999+00:00 - The Bitcoin community has been discussing the implementation of address expiration to reduce the monitoring requirements associated with the increasing number of Bitcoin addresses. The idea is to add an expiration date to Bitcoin addresses, forcing users to create new addresses periodically instead of keeping old ones active indefinitely. This would help reduce the burden of monitoring old addresses and prevent the buildup of unused addresses over time.However, there are concerns about the potential implications of address expiration. One concern is that if businesses are issued with an address by a government body, then all transactions can be tracked for that business entity, compromising privacy and fungibility. Some argue that address reuse should be allowed in certain cases, such as for donation addresses or when accounting requirements necessitate archiving all keys and transaction hashes.Gregory Maxwell proposed encoding an expiration date into the address itself and specifying that clients enforce it. This would simplify the implementation and ensure that individuals who want to hack their client to make payments not according to the payee's specifications will have to face the consequences.There have also been discussions about the potential drawbacks of enforcing address expiration. It could invalidate payments made at or just before expiration in case of reorganization, and it may increase recommended confirmations above current levels centered around the possibility of a malicious double-spend. The benefit of the Bitcoin network providing this service needs to be weighed against the potential cost.Overall, address expiration presents an interesting potential solution to the issue of increasing Bitcoin addresses. While it remains to be seen whether it will be adopted in the future, it could have a positive impact on the scalability and efficiency of the Bitcoin network. 2015-06-13T04:52:25+00:00 + The Bitcoin community has been discussing the implementation of address expiration to reduce the monitoring requirements associated with the increasing number of Bitcoin addresses. The idea is to add an expiration date to Bitcoin addresses, forcing users to create new addresses periodically instead of keeping old ones active indefinitely. This would help reduce the burden of monitoring old addresses and prevent the buildup of unused addresses over time.However, there are concerns about the potential implications of address expiration. One concern is that if businesses are issued with an address by a government body, then all transactions can be tracked for that business entity, compromising privacy and fungibility. Some argue that address reuse should be allowed in certain cases, such as for donation addresses or when accounting requirements necessitate archiving all keys and transaction hashes.Gregory Maxwell proposed encoding an expiration date into the address itself and specifying that clients enforce it. This would simplify the implementation and ensure that individuals who want to hack their client to make payments not according to the payee's specifications will have to face the consequences.There have also been discussions about the potential drawbacks of enforcing address expiration. It could invalidate payments made at or just before expiration in case of reorganization, and it may increase recommended confirmations above current levels centered around the possibility of a malicious double-spend. The benefit of the Bitcoin network providing this service needs to be weighed against the potential cost.Overall, address expiration presents an interesting potential solution to the issue of increasing Bitcoin addresses. While it remains to be seen whether it will be adopted in the future, it could have a positive impact on the scalability and efficiency of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Are-Instant-Confirmations-safe-.xml b/static/bitcoin-dev/March_2015/combined_Are-Instant-Confirmations-safe-.xml index 89a0ec3bdb..5b54341fdf 100644 --- a/static/bitcoin-dev/March_2015/combined_Are-Instant-Confirmations-safe-.xml +++ b/static/bitcoin-dev/March_2015/combined_Are-Instant-Confirmations-safe-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Are Instant Confirmations safe? - 2023-08-01T12:10:38.613919+00:00 + 2025-10-11T21:56:21.061040+00:00 + python-feedgen Natanael 2015-03-18 22:53:32+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Are Instant Confirmations safe? - 2023-08-01T12:10:38.614910+00:00 + 2025-10-11T21:56:21.061226+00:00 - In a Bitcoin email list post on March 18, 2015, a user named Dennis Sullivan introduced a proposal called "transaction locking". This proposal claimed to enable the acceptance of 0-conf (zero confirmation) transactions with a guarantee that they will be mined. However, Sullivan expressed skepticism about the system, noting the absence of prior discussion on the mailing list.The transaction locking scheme operates by broadcasting an InstantX transaction that spends specific outputs in Darkcoin. Certain nodes then sign a message that locks this transaction in the mempool, preventing double-spending of its inputs. All nodes are instructed to reject conflicting transactions and remove any existing ones in the mempool that conflict with the locked transaction.Once a transaction obtains consensus lock across multiple nodes in the mempool, it becomes guaranteed to be mined since it cannot be double-spent. Miners are unable to mine a double spend of the consensus-locked transaction. However, Sullivan highlights a potential attack vector that could lead to block rejections and potential network forks.To provide further insight into the proposal, Sullivan shares a link to a paper that provides a comprehensive explanation of the transaction locking concept. He also discusses potential weaknesses of the proposal, such as vulnerability to sybil attacks, Finney attacks, and defecting miners. Additionally, he emphasizes that while low-value transactions may tolerate the associated risks, larger value transactions pose a greater risk of making oneself a target.Overall, Sullivan's introductory email seeks opinions on the transaction locking proposal, expresses doubt about its effectiveness, and raises concerns about potential weaknesses and attack vectors. 2015-03-18T22:53:32+00:00 + In a Bitcoin email list post on March 18, 2015, a user named Dennis Sullivan introduced a proposal called "transaction locking". This proposal claimed to enable the acceptance of 0-conf (zero confirmation) transactions with a guarantee that they will be mined. However, Sullivan expressed skepticism about the system, noting the absence of prior discussion on the mailing list.The transaction locking scheme operates by broadcasting an InstantX transaction that spends specific outputs in Darkcoin. Certain nodes then sign a message that locks this transaction in the mempool, preventing double-spending of its inputs. All nodes are instructed to reject conflicting transactions and remove any existing ones in the mempool that conflict with the locked transaction.Once a transaction obtains consensus lock across multiple nodes in the mempool, it becomes guaranteed to be mined since it cannot be double-spent. Miners are unable to mine a double spend of the consensus-locked transaction. However, Sullivan highlights a potential attack vector that could lead to block rejections and potential network forks.To provide further insight into the proposal, Sullivan shares a link to a paper that provides a comprehensive explanation of the transaction locking concept. He also discusses potential weaknesses of the proposal, such as vulnerability to sybil attacks, Finney attacks, and defecting miners. Additionally, he emphasizes that while low-value transactions may tolerate the associated risks, larger value transactions pose a greater risk of making oneself a target.Overall, Sullivan's introductory email seeks opinions on the transaction locking proposal, expresses doubt about its effectiveness, and raises concerns about potential weaknesses and attack vectors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_BIP-for-standard-multi-signature-P2SH-addresses.xml b/static/bitcoin-dev/March_2015/combined_BIP-for-standard-multi-signature-P2SH-addresses.xml index 9d7d99c70f..c7d859d2aa 100644 --- a/static/bitcoin-dev/March_2015/combined_BIP-for-standard-multi-signature-P2SH-addresses.xml +++ b/static/bitcoin-dev/March_2015/combined_BIP-for-standard-multi-signature-P2SH-addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP for standard multi-signature P2SH addresses - 2023-08-01T12:00:23.109555+00:00 + 2025-10-11T21:56:23.184298+00:00 + python-feedgen Pindar Wong 2015-03-11 23:50:08+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP for standard multi-signature P2SH addresses - 2023-08-01T12:00:23.109555+00:00 + 2025-10-11T21:56:23.184507+00:00 - In an email conversation between Gregory Maxwell and Pindar Wong, the idea of adding a statement indicating that a BIP number will be assigned after copy-editing and acceptance, and that it will be published on the Bitcoin Wiki page, is discussed. Wong suggests introducing a 'Bitcoin-Draft' status with an auto-expiry period similar to the concept of 'Internet Drafts' used by the Internet Engineering Task Force (IETF). Maxwell explains that posting to the list is already considered a draft document and requires no approval beyond filling out the appropriate form, but agrees that calling it a distinct step might be better.On March 11, 2015, Pindar Wong suggests the creation of a 'Bitcoin-Draft' (BD) status with an auto-expiry period, drawing a comparison to the success of the IETF's 'Internet Drafts' (ID). Another participant in the conversation notes that posting to the list serves a similar purpose and creating a draft document requires no approval beyond filling out the appropriate form. It is suggested to potentially establish a distinct step for creating a draft document.The suggestion to create a 'Bitcoin-Draft' (BD) status with an auto-expiry period similar to the IETF's concept of 'Internet Drafts' (ID) is met with caution due to past issues with people squatting on prior draft proposals and demanding access to the same numbers. It is emphasized that squatted numbers will not be assigned and discussion must come before number assignment. Proposals should not be referred to as "BIP[nn]" until they are actually a BIP, and placeholder names can be used during the drafting process.Thomas Kerin proposes a new standard for creating standard multisignature P2SH addresses given 'm' and a set of public keys. He creates a PR on bitcoin/bips and uses BIP0090 as a placeholder, requesting a BIP number for this purpose. The method is currently used by CryptoCorp for their external signer service. The email is sent to the Bitcoin-development mailing list and also includes a promotion for the Go Parallel website, sponsored by Intel and developed in partnership with Slashdot Media, which provides resources related to parallel software development.In the email thread from March 11, 2015, Thomas Kerin requests a BIP number for his proposal. The issue of individuals squatting on BIP numbers and demanding access to them is discussed, leading to the suggestion that proposals should not be referred to as "BIP[nn]" until they are actually a BIP. Instead, placeholder names can be used during the drafting process. It is emphasized that discussion should come before number assignments, and that many proposals are withdrawn after further discussion shows that they are without public interest or subsumed by other functionality. If there is any confusion regarding the process, individuals are encouraged to bring it to attention.Bitcoinj, a Java implementation of the Bitcoin protocol, uses the convention of representing units of Bitcoin as "satoshi" in code, named after the pseudonymous creator of Bitcoin, Satoshi Nakamoto. This convention is also used by other Bitcoin implementations, including Bitcoin Core.Thomas Kerin's proposal for creating standard multisignature P2SH addresses given 'm' and a set of public keys can be found on GitHub at https://github.com/bitcoin/bips/pull/146. The email message also includes Thomas Kerin's PGP key. 2015-03-11T23:50:08+00:00 + In an email conversation between Gregory Maxwell and Pindar Wong, the idea of adding a statement indicating that a BIP number will be assigned after copy-editing and acceptance, and that it will be published on the Bitcoin Wiki page, is discussed. Wong suggests introducing a 'Bitcoin-Draft' status with an auto-expiry period similar to the concept of 'Internet Drafts' used by the Internet Engineering Task Force (IETF). Maxwell explains that posting to the list is already considered a draft document and requires no approval beyond filling out the appropriate form, but agrees that calling it a distinct step might be better.On March 11, 2015, Pindar Wong suggests the creation of a 'Bitcoin-Draft' (BD) status with an auto-expiry period, drawing a comparison to the success of the IETF's 'Internet Drafts' (ID). Another participant in the conversation notes that posting to the list serves a similar purpose and creating a draft document requires no approval beyond filling out the appropriate form. It is suggested to potentially establish a distinct step for creating a draft document.The suggestion to create a 'Bitcoin-Draft' (BD) status with an auto-expiry period similar to the IETF's concept of 'Internet Drafts' (ID) is met with caution due to past issues with people squatting on prior draft proposals and demanding access to the same numbers. It is emphasized that squatted numbers will not be assigned and discussion must come before number assignment. Proposals should not be referred to as "BIP[nn]" until they are actually a BIP, and placeholder names can be used during the drafting process.Thomas Kerin proposes a new standard for creating standard multisignature P2SH addresses given 'm' and a set of public keys. He creates a PR on bitcoin/bips and uses BIP0090 as a placeholder, requesting a BIP number for this purpose. The method is currently used by CryptoCorp for their external signer service. The email is sent to the Bitcoin-development mailing list and also includes a promotion for the Go Parallel website, sponsored by Intel and developed in partnership with Slashdot Media, which provides resources related to parallel software development.In the email thread from March 11, 2015, Thomas Kerin requests a BIP number for his proposal. The issue of individuals squatting on BIP numbers and demanding access to them is discussed, leading to the suggestion that proposals should not be referred to as "BIP[nn]" until they are actually a BIP. Instead, placeholder names can be used during the drafting process. It is emphasized that discussion should come before number assignments, and that many proposals are withdrawn after further discussion shows that they are without public interest or subsumed by other functionality. If there is any confusion regarding the process, individuals are encouraged to bring it to attention.Bitcoinj, a Java implementation of the Bitcoin protocol, uses the convention of representing units of Bitcoin as "satoshi" in code, named after the pseudonymous creator of Bitcoin, Satoshi Nakamoto. This convention is also used by other Bitcoin implementations, including Bitcoin Core.Thomas Kerin's proposal for creating standard multisignature P2SH addresses given 'm' and a set of public keys can be found on GitHub at https://github.com/bitcoin/bips/pull/146. The email message also includes Thomas Kerin's PGP key. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_BIP32-Index-Randomisation.xml b/static/bitcoin-dev/March_2015/combined_BIP32-Index-Randomisation.xml index b91c1347a5..87db60c258 100644 --- a/static/bitcoin-dev/March_2015/combined_BIP32-Index-Randomisation.xml +++ b/static/bitcoin-dev/March_2015/combined_BIP32-Index-Randomisation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP32 Index Randomisation - 2023-08-01T12:01:12.193147+00:00 + 2025-10-11T21:56:52.962414+00:00 + python-feedgen Mike Hearn 2015-03-13 21:34:31+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP32 Index Randomisation - 2023-08-01T12:01:12.194144+00:00 + 2025-10-11T21:56:52.962575+00:00 - The conversation revolves around the topic of web wallets and the concern over privacy in relation to a web wallet server. The sender is worried that their platform, BWS, may be considered a web wallet, but clarifies that private keys are not stored on the server. The recipient explains that they were referring to a setup similar to blockchain.info or CoPay, where the client has the private keys but relies on the server for wallet information. They also discuss the idea of having visibility of the wallet by the multisig facilitator for better user experience. The challenge of implementing push notifications in a decentralized way is mentioned. The recipient suggests following Gregory's approach, but acknowledges that the decision ultimately rests with the sender.The main focus of the discussion is on a web wallet server and the associated privacy concerns. It is mentioned that clients, being SPV (Simplified Payment Verification), can check their own balances and transaction history. This means that coordination tasks could be done by storing encrypted blobs on the server instead of giving it insight into the transactions. The fact that private keys are not stored on the server and addresses can be generated offline is highlighted. Copay is referenced as an example of using encrypted blobs to check balances and transaction history through Insight. However, it is believed that allowing some visibility of the wallet by the multisig facilitator would greatly improve the user experience. The engineering cost of preventing the server from knowing xpubs keys needs to be evaluated, and Subspace is suggested for further exploration.The context indicates that the main issue revolves around a web wallet server where clients are not SPV and rely on the server for balance and transaction history checks. The suggestion is made to store encrypted blobs on the server for coordination tasks instead of providing direct insight into the transactions. This approach is similar to the concept of Subspace. Even with measures in place to prevent the server from knowing the xpubkey, it still has access to all addresses and transactions due to the nature of web wallets. Therefore, limiting the information known by the server would not be worth the engineering cost as it would only reduce the server's knowledge from everything to 95%.BWS (Bitcore Wallet Service) is described as a platform that coordinates transaction proposals in multisignature wallets, stores BIP32 derivation indexes, accesses the blockchain, and provides functions like `getBalance` and `getTxHistory` to peers. It aims to provide an easy setup while ensuring privacy and security. The evaluation of BWS not having extended public keys reveals that it would have no way to verify addresses sent by peers, which could lead to broken functions like `getBalance` or `txHistory`. However, Gregory Maxwell has proposed a schema that may address this issue using "not extended" pubkeys, but further evaluation is needed.Bitcore-wallet-server (BWS) is identified as a facilitator for HD (Hierarchical Deterministic) multisig wallets. Currently, BWS instances hold the set of extended public keys of the wallet's peers to derive addresses. The concern raised is that this poses a privacy issue. To mitigate this concern, the suggestion is made to use pseudo-random BIP32 paths with a seed known only by the peers. This way, the server can verify submitted addresses without being able to derive future wallet addresses. The proposed approach involves giving the server the master pubkey P without the chaincode and generating addresses in a manner determined by the user. The server then computes the address based on the provided scalar value iL and checks for agreement. This approach is considered more private than sharing the chain code and is compatible with hardened derivation.The developers of bitcore-wallet-server (BWS) are seeking feedback on their usage of BIP32 paths. Currently, BWS instances hold the extended public keys of the wallet's peers to derive addresses, which raises privacy concerns. To address this, the team proposes using pseudo-random BIP32 paths with a seed known only by the peers. This would allow the server to verify addresses without being able to derive future wallet addresses. The proposed workflow involves the peer requesting the current index and creating an address using the index and pathSeed. The server then derives the address and adds it to the wallet. 2015-03-13T21:34:31+00:00 + The conversation revolves around the topic of web wallets and the concern over privacy in relation to a web wallet server. The sender is worried that their platform, BWS, may be considered a web wallet, but clarifies that private keys are not stored on the server. The recipient explains that they were referring to a setup similar to blockchain.info or CoPay, where the client has the private keys but relies on the server for wallet information. They also discuss the idea of having visibility of the wallet by the multisig facilitator for better user experience. The challenge of implementing push notifications in a decentralized way is mentioned. The recipient suggests following Gregory's approach, but acknowledges that the decision ultimately rests with the sender.The main focus of the discussion is on a web wallet server and the associated privacy concerns. It is mentioned that clients, being SPV (Simplified Payment Verification), can check their own balances and transaction history. This means that coordination tasks could be done by storing encrypted blobs on the server instead of giving it insight into the transactions. The fact that private keys are not stored on the server and addresses can be generated offline is highlighted. Copay is referenced as an example of using encrypted blobs to check balances and transaction history through Insight. However, it is believed that allowing some visibility of the wallet by the multisig facilitator would greatly improve the user experience. The engineering cost of preventing the server from knowing xpubs keys needs to be evaluated, and Subspace is suggested for further exploration.The context indicates that the main issue revolves around a web wallet server where clients are not SPV and rely on the server for balance and transaction history checks. The suggestion is made to store encrypted blobs on the server for coordination tasks instead of providing direct insight into the transactions. This approach is similar to the concept of Subspace. Even with measures in place to prevent the server from knowing the xpubkey, it still has access to all addresses and transactions due to the nature of web wallets. Therefore, limiting the information known by the server would not be worth the engineering cost as it would only reduce the server's knowledge from everything to 95%.BWS (Bitcore Wallet Service) is described as a platform that coordinates transaction proposals in multisignature wallets, stores BIP32 derivation indexes, accesses the blockchain, and provides functions like `getBalance` and `getTxHistory` to peers. It aims to provide an easy setup while ensuring privacy and security. The evaluation of BWS not having extended public keys reveals that it would have no way to verify addresses sent by peers, which could lead to broken functions like `getBalance` or `txHistory`. However, Gregory Maxwell has proposed a schema that may address this issue using "not extended" pubkeys, but further evaluation is needed.Bitcore-wallet-server (BWS) is identified as a facilitator for HD (Hierarchical Deterministic) multisig wallets. Currently, BWS instances hold the set of extended public keys of the wallet's peers to derive addresses. The concern raised is that this poses a privacy issue. To mitigate this concern, the suggestion is made to use pseudo-random BIP32 paths with a seed known only by the peers. This way, the server can verify submitted addresses without being able to derive future wallet addresses. The proposed approach involves giving the server the master pubkey P without the chaincode and generating addresses in a manner determined by the user. The server then computes the address based on the provided scalar value iL and checks for agreement. This approach is considered more private than sharing the chain code and is compatible with hardened derivation.The developers of bitcore-wallet-server (BWS) are seeking feedback on their usage of BIP32 paths. Currently, BWS instances hold the extended public keys of the wallet's peers to derive addresses, which raises privacy concerns. To address this, the team proposes using pseudo-random BIP32 paths with a seed known only by the peers. This would allow the server to verify addresses without being able to derive future wallet addresses. The proposed workflow involves the peer requesting the current index and creating an address using the index and pathSeed. The server then derives the address and adds it to the wallet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_BIP70-why-Google-Protocol-Buffers-for-encoding-.xml b/static/bitcoin-dev/March_2015/combined_BIP70-why-Google-Protocol-Buffers-for-encoding-.xml index 91f2211575..73e6a17b8b 100644 --- a/static/bitcoin-dev/March_2015/combined_BIP70-why-Google-Protocol-Buffers-for-encoding-.xml +++ b/static/bitcoin-dev/March_2015/combined_BIP70-why-Google-Protocol-Buffers-for-encoding-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70: why Google Protocol Buffers for encoding? - 2023-08-01T11:09:13.242345+00:00 + 2025-10-11T21:56:14.686183+00:00 + python-feedgen Jorge Timón 2015-03-24 12:08:03+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - BIP70: why Google Protocol Buffers for encoding? - 2023-08-01T11:09:13.242345+00:00 + 2025-10-11T21:56:14.686421+00:00 - The Bitcoin-development mailing list discusses the idea of using the hash of the genesis block as the chain ID. One member argues that forking bitcoins and bitcoinsB with the same owners doesn't make sense and a new currency warrants defining a new chain. However, this is not a good reason to not adopt a hash of the genesis block as the chain ID. Another member raises concerns about interpreting messages on the wrong chain if there are two forked chains with different communities. The use of a central registry is also discussed as potentially harmful.A unique approach has been adopted to replace the network identifier with the genesis block hash. This replacement ensures compatibility with Bitcoin Core and altcoins without requiring a central registry. However, there is a possibility that interpreting messages on the wrong chain may still occur if there are two forked chains with different communities.A critical vulnerability in BlackPhone has been fixed, which allowed hackers to run malicious code on the handsets. Attackers only needed a phone number to compromise the devices via the Silent Text application. The vulnerability occurred during the deserialization of JSON objects and was a type confusion vulnerability. This flaw could allow an attacker to overwrite a pointer in memory. The use of C++/Java/Python protocol buffer implementations by Google for internal inter-server communication is also mentioned. Any exploit in these implementations could bypass their entire internal security system.JSON has been known to generate bugs due to the lack of type marshalling and input validation. Protobufs and msgpack have addressed this issue by including type support and input validation in their designs. Some developers argue that creating a JSON-to-schema marshall is not worthwhile since there are only three types - bytes, int, and string. They prefer coding the JSON wrapper classes by hand. Using third-party services to convert data to JSON has also been criticized as an unnecessary and high-effort solution.The conversation revolves around the implementation of BIP70, a payment protocol for Bitcoin. One person suggests using JSON+HTTPS instead of BIP70, as it would be easier and sufficient for today's use case. Another person argues that BIP70 was designed to support hardware wallets by keeping the code small. Embedding certificates in BIP70 requests allows them to be verifiable by third parties. The conversation touches on the challenges of targeting WinRT and other platforms with a single codebase, as well as the pros and cons of bundling a custom root store.The discussion is about the limitations of BIP70 and whether to allow both serializations or keep it as is. One of the goals of BIP70 was to support hardware wallets, which requires keeping the code small. Implementing JSON and HTTPS would increase cost, complexity, and decrease security. Embedding certificates in BIP70 requests makes them verifiable by third parties, providing a form of digital receipt. The conversation also discusses the challenges of implementing BIP70 on different platforms and the pros and cons of bundling a custom root store.The conversation between Mike Hearn and an unknown person discusses the limitations of BIP70 as a client-side technology. Using JSON and HTTPS is suggested as an alternative, but it would increase cost, complexity, and decrease security. Embedding certificates in BIP70 requests allows them to be verifiable by third parties and provides a form of digital receipt. The conversation also highlights the challenges of targeting different platforms with a single codebase.The burden of certificate verification in BIP70 is discussed. One person argues that using JSON and HTTPS would be easier for developers, while another person defends the use of certificates in BIP70 as necessary for verifiability by third parties. The conversation also touches on the difficulty of implementing BIP70 on certain platforms and the pros and cons of bundling a custom root store.The discussion revolves around the use of JSON and schema in BIP70. It is argued that for the number of fields in the spec, having a JSON to schema is not worthwhile. Some developers prefer coding the JSON wrapper classes by hand. The conversation also discusses the benefits of using cross-platform libraries for protobuf and the challenges of dealing with X509 certificates.In a conversation on January 28, 2015, using OS root stores for certificates is discussed. It is suggested that taking a snapshot of the Mozilla/Apple/MSFT certificate stores and loading it into the app would be a better approach. However, concerns are raised about outdated certificates and the potential vulnerability of BitcoinJ-using software if a root CA gets breached and a certificate is revoked.The burden of certificate verification in BIP70 is placed on developers, but there is no obligation to use the OS root store. Taking a snapshot of the Mozilla/Apple/MSFT certificate stores is suggested as an alternative. However, this approach can lead to outdated certificates and potential vulnerabilities. Shipping an app with its own snapshot of certificates can make the system less secure and harder to audit.The burden of certificate verification in BIP70 is discussed. Using the OS root 2015-03-24T12:08:03+00:00 + The Bitcoin-development mailing list discusses the idea of using the hash of the genesis block as the chain ID. One member argues that forking bitcoins and bitcoinsB with the same owners doesn't make sense and a new currency warrants defining a new chain. However, this is not a good reason to not adopt a hash of the genesis block as the chain ID. Another member raises concerns about interpreting messages on the wrong chain if there are two forked chains with different communities. The use of a central registry is also discussed as potentially harmful.A unique approach has been adopted to replace the network identifier with the genesis block hash. This replacement ensures compatibility with Bitcoin Core and altcoins without requiring a central registry. However, there is a possibility that interpreting messages on the wrong chain may still occur if there are two forked chains with different communities.A critical vulnerability in BlackPhone has been fixed, which allowed hackers to run malicious code on the handsets. Attackers only needed a phone number to compromise the devices via the Silent Text application. The vulnerability occurred during the deserialization of JSON objects and was a type confusion vulnerability. This flaw could allow an attacker to overwrite a pointer in memory. The use of C++/Java/Python protocol buffer implementations by Google for internal inter-server communication is also mentioned. Any exploit in these implementations could bypass their entire internal security system.JSON has been known to generate bugs due to the lack of type marshalling and input validation. Protobufs and msgpack have addressed this issue by including type support and input validation in their designs. Some developers argue that creating a JSON-to-schema marshall is not worthwhile since there are only three types - bytes, int, and string. They prefer coding the JSON wrapper classes by hand. Using third-party services to convert data to JSON has also been criticized as an unnecessary and high-effort solution.The conversation revolves around the implementation of BIP70, a payment protocol for Bitcoin. One person suggests using JSON+HTTPS instead of BIP70, as it would be easier and sufficient for today's use case. Another person argues that BIP70 was designed to support hardware wallets by keeping the code small. Embedding certificates in BIP70 requests allows them to be verifiable by third parties. The conversation touches on the challenges of targeting WinRT and other platforms with a single codebase, as well as the pros and cons of bundling a custom root store.The discussion is about the limitations of BIP70 and whether to allow both serializations or keep it as is. One of the goals of BIP70 was to support hardware wallets, which requires keeping the code small. Implementing JSON and HTTPS would increase cost, complexity, and decrease security. Embedding certificates in BIP70 requests makes them verifiable by third parties, providing a form of digital receipt. The conversation also discusses the challenges of implementing BIP70 on different platforms and the pros and cons of bundling a custom root store.The conversation between Mike Hearn and an unknown person discusses the limitations of BIP70 as a client-side technology. Using JSON and HTTPS is suggested as an alternative, but it would increase cost, complexity, and decrease security. Embedding certificates in BIP70 requests allows them to be verifiable by third parties and provides a form of digital receipt. The conversation also highlights the challenges of targeting different platforms with a single codebase.The burden of certificate verification in BIP70 is discussed. One person argues that using JSON and HTTPS would be easier for developers, while another person defends the use of certificates in BIP70 as necessary for verifiability by third parties. The conversation also touches on the difficulty of implementing BIP70 on certain platforms and the pros and cons of bundling a custom root store.The discussion revolves around the use of JSON and schema in BIP70. It is argued that for the number of fields in the spec, having a JSON to schema is not worthwhile. Some developers prefer coding the JSON wrapper classes by hand. The conversation also discusses the benefits of using cross-platform libraries for protobuf and the challenges of dealing with X509 certificates.In a conversation on January 28, 2015, using OS root stores for certificates is discussed. It is suggested that taking a snapshot of the Mozilla/Apple/MSFT certificate stores and loading it into the app would be a better approach. However, concerns are raised about outdated certificates and the potential vulnerability of BitcoinJ-using software if a root CA gets breached and a certificate is revoked.The burden of certificate verification in BIP70 is placed on developers, but there is no obligation to use the OS root store. Taking a snapshot of the Mozilla/Apple/MSFT certificate stores is suggested as an alternative. However, this approach can lead to outdated certificates and potential vulnerabilities. Shipping an app with its own snapshot of certificates can make the system less secure and harder to audit.The burden of certificate verification in BIP70 is discussed. Using the OS root - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Bitcoin-at-POS-using-BIP70-NFC-and-offline-payments-implementer-feedback.xml b/static/bitcoin-dev/March_2015/combined_Bitcoin-at-POS-using-BIP70-NFC-and-offline-payments-implementer-feedback.xml index 31c5eb5308..2d720d8a0f 100644 --- a/static/bitcoin-dev/March_2015/combined_Bitcoin-at-POS-using-BIP70-NFC-and-offline-payments-implementer-feedback.xml +++ b/static/bitcoin-dev/March_2015/combined_Bitcoin-at-POS-using-BIP70-NFC-and-offline-payments-implementer-feedback.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback - 2023-08-01T11:54:07.905855+00:00 + 2025-10-11T21:56:44.445948+00:00 + python-feedgen Eric Voskuil 2015-03-03 00:54:18+00:00 @@ -183,13 +184,13 @@ - python-feedgen + 2 Combined summary - Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback - 2023-08-01T11:54:07.905855+00:00 + 2025-10-11T21:56:44.446205+00:00 - The email conversations revolve around various aspects of improving the bitcoin URI scheme and addressing security concerns in NFC and Bluetooth transactions. There are suggestions to add parameters to the bitcoin URI to simplify wallet development for NFC-only wallets and to improve security for Bluetooth transactions. The use of fallback addresses is debated, with some participants suggesting adding their own parameter instead. The discussion also covers the format of the Session ID, the elimination of the h= parameter, and the use of base58 encoding.There are concerns about the compromise of public keys and the potential for abuse scenarios in point-of-sale systems. The conversation explores the use of public keys via NFC or QR codes and the need for authentication of payers by payees. Reusing public keys is deemed insecure, and suggestions are made to encrypt secrets with public keys or use ephemeral keys. The debate extends to using self-signed certificates versus those signed by a Certificate Authority (CA) and the identification of customers in various scenarios.The reliability of NFC payment transfers is discussed, with suggestions to limit connection speed or run mechanisms in parallel. Compatibility issues with NFC based on the long certificate chain are also discussed, as well as concerns about enabling Bluetooth and potential solutions to turn it on programmatically. Changes to the "ack" memo field and BitPay's memo field are considered. The security risks of NFC and Bluetooth payment transactions are examined, with proposals to send a unique public key over NFC to prevent spoofing and seller impersonation. The use of public certificates versus session keys is debated, with the consensus leaning towards the former for increased security.In another email conversation, the topic of limiting Bitcoin capabilities based on Apple's product capabilities and their stance towards Bitcoin is discussed. It is suggested that Bitcoin should not be limited due to Apple's restrictions and that an Airbitz-like proposal could be implemented as a fallback. The general consensus is that Apple will likely open up NFC to developers in iOS 9 and that Apple doesn't really care about Bitcoin. The history of Bitcoin wallets being banned from the app store and then allowed back in is mentioned, with the opinion that Bitcoin is too small for Apple to be concerned about.In an email exchange on February 22, 2015, Eric Voskuil suggested encoding MAC addresses and resource names using base58 instead of base16. Another person responded, stating that Base64Url is a more efficient encoding method than Base58 and is implemented in more libraries and operating systems. They also noted that Base58 was designed for copy-typing by humans.The email conversations also discuss the security of NFC and Bluetooth communication. Concerns are raised about the privacy of NFC communication and the possibility of eavesdropping. The use of SSL/TLS for private communication over a public channel is debated, as well as the privacy implications of NFC and Bluetooth communication.Overall, the email conversations cover various aspects of implementing NFC and offline payments, proposing changes to the bitcoin payment protocol, and addressing security concerns in NFC and Bluetooth transactions. The discussions aim to improve the bitcoin URI scheme, find solutions to authentication and abuse scenarios, and ensure the security of payment transactions. 2015-03-03T00:54:18+00:00 + The email conversations revolve around various aspects of improving the bitcoin URI scheme and addressing security concerns in NFC and Bluetooth transactions. There are suggestions to add parameters to the bitcoin URI to simplify wallet development for NFC-only wallets and to improve security for Bluetooth transactions. The use of fallback addresses is debated, with some participants suggesting adding their own parameter instead. The discussion also covers the format of the Session ID, the elimination of the h= parameter, and the use of base58 encoding.There are concerns about the compromise of public keys and the potential for abuse scenarios in point-of-sale systems. The conversation explores the use of public keys via NFC or QR codes and the need for authentication of payers by payees. Reusing public keys is deemed insecure, and suggestions are made to encrypt secrets with public keys or use ephemeral keys. The debate extends to using self-signed certificates versus those signed by a Certificate Authority (CA) and the identification of customers in various scenarios.The reliability of NFC payment transfers is discussed, with suggestions to limit connection speed or run mechanisms in parallel. Compatibility issues with NFC based on the long certificate chain are also discussed, as well as concerns about enabling Bluetooth and potential solutions to turn it on programmatically. Changes to the "ack" memo field and BitPay's memo field are considered. The security risks of NFC and Bluetooth payment transactions are examined, with proposals to send a unique public key over NFC to prevent spoofing and seller impersonation. The use of public certificates versus session keys is debated, with the consensus leaning towards the former for increased security.In another email conversation, the topic of limiting Bitcoin capabilities based on Apple's product capabilities and their stance towards Bitcoin is discussed. It is suggested that Bitcoin should not be limited due to Apple's restrictions and that an Airbitz-like proposal could be implemented as a fallback. The general consensus is that Apple will likely open up NFC to developers in iOS 9 and that Apple doesn't really care about Bitcoin. The history of Bitcoin wallets being banned from the app store and then allowed back in is mentioned, with the opinion that Bitcoin is too small for Apple to be concerned about.In an email exchange on February 22, 2015, Eric Voskuil suggested encoding MAC addresses and resource names using base58 instead of base16. Another person responded, stating that Base64Url is a more efficient encoding method than Base58 and is implemented in more libraries and operating systems. They also noted that Base58 was designed for copy-typing by humans.The email conversations also discuss the security of NFC and Bluetooth communication. Concerns are raised about the privacy of NFC communication and the possibility of eavesdropping. The use of SSL/TLS for private communication over a public channel is debated, as well as the privacy implications of NFC and Bluetooth communication.Overall, the email conversations cover various aspects of implementing NFC and offline payments, proposing changes to the bitcoin payment protocol, and addressing security concerns in NFC and Bluetooth transactions. The discussions aim to improve the bitcoin URI scheme, find solutions to authentication and abuse scenarios, and ensure the security of payment transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Criminal-complaints-against-network-disruption-as-a-service-startups.xml b/static/bitcoin-dev/March_2015/combined_Criminal-complaints-against-network-disruption-as-a-service-startups.xml index dbca6fab2f..352b4ad13f 100644 --- a/static/bitcoin-dev/March_2015/combined_Criminal-complaints-against-network-disruption-as-a-service-startups.xml +++ b/static/bitcoin-dev/March_2015/combined_Criminal-complaints-against-network-disruption-as-a-service-startups.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Criminal complaints against "network disruption as a service" startups - 2023-08-01T12:03:03.151106+00:00 + Combined summary - Criminal complaints against "network disruption as a service" startups + 2025-10-11T21:56:46.579025+00:00 + python-feedgen odinn 2015-03-23 06:45:31+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 - Combined summary - Criminal complaints against "network disruption as a service" startups - 2023-08-01T12:03:03.151106+00:00 + Combined summary - Criminal complaints against "network disruption as a service" startups + 2025-10-11T21:56:46.579202+00:00 - Chainalysis, a blockchain analysis company based in Switzerland, is facing legal scrutiny for collecting publicly available information from the Bitcoin P2P network. The debate centers around the legality of surveillance and data gathering, with concerns raised about potential violations of Swiss laws and user privacy. Some argue that analyzing publicly available information is not illegal, while others believe it could lead to lawsuits against such corporations. There are calls for developers to provide anonymity options for users to protect against surveillance.Meanwhile, the Go Parallel website, developed in partnership with Slashdot Media and sponsored by Intel, serves as a platform for parallel software development. It offers various resources, including thought leadership blogs, news, videos, case studies, tutorials, and more. The aim is to promote decentralization and expansion of a giving economy through a protocol concept called Abis.io. Furthermore, a Bitcoin-development mailing list is available for community participation and collaboration in the Bitcoin space.The context also includes discussions on the flow of funds between countries, the challenges faced by breadwallet, and proposals for funding network resources using crowdfunding contracts. Various individuals express their opinions on allowing bitcoin nodes to limit access, pay for node resources consumed, and establish finer-grained access controls. In summary, the legality of collecting publicly available information from the Bitcoin P2P network is under debate, with concerns about violating privacy laws and potential lawsuits. Chainalysis and similar companies may face legal consequences, but there are differing interpretations and uncertainties surrounding these issues. The context also mentions the Go Parallel website, Abis.io protocol concept, Bitcoin-development mailing list, and proposals for network resource funding and access controls. 2015-03-23T06:45:31+00:00 + Chainalysis, a blockchain analysis company based in Switzerland, is facing legal scrutiny for collecting publicly available information from the Bitcoin P2P network. The debate centers around the legality of surveillance and data gathering, with concerns raised about potential violations of Swiss laws and user privacy. Some argue that analyzing publicly available information is not illegal, while others believe it could lead to lawsuits against such corporations. There are calls for developers to provide anonymity options for users to protect against surveillance.Meanwhile, the Go Parallel website, developed in partnership with Slashdot Media and sponsored by Intel, serves as a platform for parallel software development. It offers various resources, including thought leadership blogs, news, videos, case studies, tutorials, and more. The aim is to promote decentralization and expansion of a giving economy through a protocol concept called Abis.io. Furthermore, a Bitcoin-development mailing list is available for community participation and collaboration in the Bitcoin space.The context also includes discussions on the flow of funds between countries, the challenges faced by breadwallet, and proposals for funding network resources using crowdfunding contracts. Various individuals express their opinions on allowing bitcoin nodes to limit access, pay for node resources consumed, and establish finer-grained access controls. In summary, the legality of collecting publicly available information from the Bitcoin P2P network is under debate, with concerns about violating privacy laws and potential lawsuits. Chainalysis and similar companies may face legal consequences, but there are differing interpretations and uncertainties surrounding these issues. The context also mentions the Go Parallel website, Abis.io protocol concept, Bitcoin-development mailing list, and proposals for network resource funding and access controls. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Double-spending-and-replace-by-fee.xml b/static/bitcoin-dev/March_2015/combined_Double-spending-and-replace-by-fee.xml index acee1d6f4b..4420d2ccd0 100644 --- a/static/bitcoin-dev/March_2015/combined_Double-spending-and-replace-by-fee.xml +++ b/static/bitcoin-dev/March_2015/combined_Double-spending-and-replace-by-fee.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Double spending and replace by fee - 2023-08-01T12:11:41.865487+00:00 + 2025-10-11T21:56:55.088899+00:00 + python-feedgen Peter Todd 2015-04-21 11:37:14+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Double spending and replace by fee - 2023-08-01T12:11:41.865487+00:00 + 2025-10-11T21:56:55.089066+00:00 - In a 2015 email thread, Adrian Macneil from Coinbase expressed concern about the impact of the proposed Replace-by-Fee (RBF) protocol on Bitcoin. He discussed with Coinbase the potential difficulty in pitching Bitcoin as an alternative to credit card payments for large merchants due to their reliance on the current first-seen mempool behavior. Macneil raised questions about Coinbase's contractual obligations regarding zeroconf transactions, their double-spend losses history, and their plans to move away from dependency on "first-seen" mempool policy.Peter Todd challenged Adrian to provide a list of companies that actually rely on first-seen mempool behavior. Meanwhile, Mike Hearn shared two blog posts related to RBF and double spending mitigations. The first post argued against RBF-SE, highlighting its potential harm to Bitcoin. The second post explored techniques such as risk analysis, payment channels, countersigning by a trusted third party, remote attestation, ID verification, waiting for confirmations, and punishment of double spending blocks to make double spending more difficult.The email thread also included a promotional message about the Go Parallel Website, a platform sponsored by Intel and developed in partnership with Slashdot Media. This website focuses on parallel software development and offers various resources like thought leadership blogs, news, videos, case studies, tutorials, and more.On the Bitcoin-development mailing list, Mike Hearn wrote two blog posts discussing replace by fee and double-spending mitigations. The first article, titled "Replace by Fee Scorched Earth, a Counter Argument," presents arguments against RBF-SE, emphasizing its potential harm to Bitcoin. The second post, titled "Double Spending and How to Make It Harder," summarizes instances of double spending against merchants and suggests techniques to mitigate this risk. These techniques include risk analysis, payment channels, countersigning by a trusted third party, remote attestation, ID verification, waiting for confirmations, and punishment of double spending blocks. The posts are considered valuable and interesting to those interested in the topic.The author acknowledges that their views may not be exhaustive or unbiased but hopes that their thoughts will provide useful insights for readers interested in replace-by-fee and double-spending mitigations. 2015-04-21T11:37:14+00:00 + In a 2015 email thread, Adrian Macneil from Coinbase expressed concern about the impact of the proposed Replace-by-Fee (RBF) protocol on Bitcoin. He discussed with Coinbase the potential difficulty in pitching Bitcoin as an alternative to credit card payments for large merchants due to their reliance on the current first-seen mempool behavior. Macneil raised questions about Coinbase's contractual obligations regarding zeroconf transactions, their double-spend losses history, and their plans to move away from dependency on "first-seen" mempool policy.Peter Todd challenged Adrian to provide a list of companies that actually rely on first-seen mempool behavior. Meanwhile, Mike Hearn shared two blog posts related to RBF and double spending mitigations. The first post argued against RBF-SE, highlighting its potential harm to Bitcoin. The second post explored techniques such as risk analysis, payment channels, countersigning by a trusted third party, remote attestation, ID verification, waiting for confirmations, and punishment of double spending blocks to make double spending more difficult.The email thread also included a promotional message about the Go Parallel Website, a platform sponsored by Intel and developed in partnership with Slashdot Media. This website focuses on parallel software development and offers various resources like thought leadership blogs, news, videos, case studies, tutorials, and more.On the Bitcoin-development mailing list, Mike Hearn wrote two blog posts discussing replace by fee and double-spending mitigations. The first article, titled "Replace by Fee Scorched Earth, a Counter Argument," presents arguments against RBF-SE, emphasizing its potential harm to Bitcoin. The second post, titled "Double Spending and How to Make It Harder," summarizes instances of double spending against merchants and suggests techniques to mitigate this risk. These techniques include risk analysis, payment channels, countersigning by a trusted third party, remote attestation, ID verification, waiting for confirmations, and punishment of double spending blocks. The posts are considered valuable and interesting to those interested in the topic.The author acknowledges that their views may not be exhaustive or unbiased but hopes that their thoughts will provide useful insights for readers interested in replace-by-fee and double-spending mitigations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Electrum-2-0-has-been-tagged.xml b/static/bitcoin-dev/March_2015/combined_Electrum-2-0-has-been-tagged.xml index 007f7557e5..7e23481f25 100644 --- a/static/bitcoin-dev/March_2015/combined_Electrum-2-0-has-been-tagged.xml +++ b/static/bitcoin-dev/March_2015/combined_Electrum-2-0-has-been-tagged.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Electrum 2.0 has been tagged - 2023-08-01T11:59:08.478016+00:00 + 2025-10-11T21:56:48.702857+00:00 + python-feedgen devrandom 2015-03-18 02:06:09+00:00 @@ -171,13 +172,13 @@ - python-feedgen + 2 Combined summary - Electrum 2.0 has been tagged - 2023-08-01T11:59:08.479007+00:00 + 2025-10-11T21:56:48.703085+00:00 - In an email conversation from March 2015, Andreas Schildbach discussed issues with using BIP70 for mobile wallets. Another participant suggested un-multisigging coins for daily use. The discussion also touched on multisig adoption, which was predicted to increase exponentially. In another email thread, concerns were raised about importing wallets from different providers. A solution was proposed to have the importing wallet specify which sections it supports. The thread also discussed the need for a standard synchronization or transition protocol for wallets. Gregory Maxwell suggested using an explicit unstructured mass private key export and a sweep function for emergency transitions. He expressed concerns about the availability of sweep functions that create enough keys for sweeping purposes. Bryan added that privacy can be compromised when broadcasting multiple transactions during a sweep.A suggestion was made to create a common file format for wallets to interpret. However, it was met with skepticism due to the differences in wallet designs. Instead, it was proposed that bitcoinj-based wallets could share the bitcoinj protobuf wallet format. The ultimate goal is to have a 12-word seed serve as an encryption key for a wallet backup, but this transition will take time.Mike Hearn discussed the need for a common file format that all wallets can use. He suggested creating something extensible that can describe how to derive addresses used by the user. The format should also allow for different types of wallets, such as multisignature wallets. Additionally, there should be labels for transactions and P2SH script templates for address recovery.Jim and his team considered several factors when selecting which HD wallet structures to support. They found BIP39, BIP32, and BIP44 to be good standards for maximum compatibility with other wallets. They opted for a timestamp as optional external metadata to reduce user error when entering a timestamp. Restoring a wallet requires the user to select where the "wallet words" came from.The discussion around BIP39 clarified that changing the word list does not affect previously generated mnemonics. However, a static word list is necessary for real-world usage. Electrum v2 seed phrases include an explicit version number, unlike BIP39. The new seed derivation method in Electrum allows for wordlists to be added and modified without breaking existing seed phrases.The usage of BIP39 seed phrases was discussed, noting that changing the wordlist will invalidate existing mnemonics. However, changing the wordlist only affects new mnemonics, not previously generated ones. The wordlist is only used to generate a mnemonic, not for seed generation. BIP39 was criticized for not including a version number in the seed phrase and requiring a fixed wordlist. Electrum v2 seed phrases include a version number and allow for future wordlist modifications.In another discussion, concerns were raised about the implementation of BIP39 in libbitcoin. Changing the wordlist would invalidate mnemonics, but it has no impact on previously generated ones. It was suggested that BIP39 should include a version number and allow for flexible wordlists.Overall, the discussions revolve around the challenges and considerations of using different wallet standards and formats. There is a need for interoperability, privacy considerations, and long-term solutions for securing wallets.In an email exchange, Thomas V. expresses concern about the need to explore branches of the derivation tree to determine if a wallet exists. He suggests that a version number would be more useful as it allows the software to answer negatively without being online. Andreas Schildbach questions why BIP43 is tied to BIP32, leading to a discussion on their thoughts about the matter.The effectiveness of PBKDF2 in securing wallet seeds is discussed. While PBKDF2 slows down attackers attempting to attack through an interface, it doesn't add any security to the seed in a brute force attack. The 2048 iteration count is sufficient for its purpose, even though it adds a slight delay in seed generation. Aaron Voisine shares his thoughts on the compromises made for current low power embedded devices and the need for stronger password key stretching and the ability to derive the seed phrase from the wallet seed.Aaron Voisine disagrees with the sentiment that BIP39 is admirable. He acknowledges the compromises made for current generation devices but expresses concern about the weak password key stretching and the inability to derive the seed phrase from the wallet seed. Despite his concerns, he understands the motivation behind the decision.The discussion revolves around determining the version for different Bitcoin wallets and the use of BIP39. The group believes that brute force is an acceptable trade-off for not requiring the need to remember a version. They also disagree with the need for version "magic flags" or creation dates stored in the mnemonic. Wordlists don't require fixing between wallet providers according to BIP39 recommendations. The conversation also touches on the compatibility issues between Electrum 2.0 and BIP39, with Thomas V. explaining the reasons behind the differences.The conversation emphasizes the importance of being able to 2015-03-18T02:06:09+00:00 + In an email conversation from March 2015, Andreas Schildbach discussed issues with using BIP70 for mobile wallets. Another participant suggested un-multisigging coins for daily use. The discussion also touched on multisig adoption, which was predicted to increase exponentially. In another email thread, concerns were raised about importing wallets from different providers. A solution was proposed to have the importing wallet specify which sections it supports. The thread also discussed the need for a standard synchronization or transition protocol for wallets. Gregory Maxwell suggested using an explicit unstructured mass private key export and a sweep function for emergency transitions. He expressed concerns about the availability of sweep functions that create enough keys for sweeping purposes. Bryan added that privacy can be compromised when broadcasting multiple transactions during a sweep.A suggestion was made to create a common file format for wallets to interpret. However, it was met with skepticism due to the differences in wallet designs. Instead, it was proposed that bitcoinj-based wallets could share the bitcoinj protobuf wallet format. The ultimate goal is to have a 12-word seed serve as an encryption key for a wallet backup, but this transition will take time.Mike Hearn discussed the need for a common file format that all wallets can use. He suggested creating something extensible that can describe how to derive addresses used by the user. The format should also allow for different types of wallets, such as multisignature wallets. Additionally, there should be labels for transactions and P2SH script templates for address recovery.Jim and his team considered several factors when selecting which HD wallet structures to support. They found BIP39, BIP32, and BIP44 to be good standards for maximum compatibility with other wallets. They opted for a timestamp as optional external metadata to reduce user error when entering a timestamp. Restoring a wallet requires the user to select where the "wallet words" came from.The discussion around BIP39 clarified that changing the word list does not affect previously generated mnemonics. However, a static word list is necessary for real-world usage. Electrum v2 seed phrases include an explicit version number, unlike BIP39. The new seed derivation method in Electrum allows for wordlists to be added and modified without breaking existing seed phrases.The usage of BIP39 seed phrases was discussed, noting that changing the wordlist will invalidate existing mnemonics. However, changing the wordlist only affects new mnemonics, not previously generated ones. The wordlist is only used to generate a mnemonic, not for seed generation. BIP39 was criticized for not including a version number in the seed phrase and requiring a fixed wordlist. Electrum v2 seed phrases include a version number and allow for future wordlist modifications.In another discussion, concerns were raised about the implementation of BIP39 in libbitcoin. Changing the wordlist would invalidate mnemonics, but it has no impact on previously generated ones. It was suggested that BIP39 should include a version number and allow for flexible wordlists.Overall, the discussions revolve around the challenges and considerations of using different wallet standards and formats. There is a need for interoperability, privacy considerations, and long-term solutions for securing wallets.In an email exchange, Thomas V. expresses concern about the need to explore branches of the derivation tree to determine if a wallet exists. He suggests that a version number would be more useful as it allows the software to answer negatively without being online. Andreas Schildbach questions why BIP43 is tied to BIP32, leading to a discussion on their thoughts about the matter.The effectiveness of PBKDF2 in securing wallet seeds is discussed. While PBKDF2 slows down attackers attempting to attack through an interface, it doesn't add any security to the seed in a brute force attack. The 2048 iteration count is sufficient for its purpose, even though it adds a slight delay in seed generation. Aaron Voisine shares his thoughts on the compromises made for current low power embedded devices and the need for stronger password key stretching and the ability to derive the seed phrase from the wallet seed.Aaron Voisine disagrees with the sentiment that BIP39 is admirable. He acknowledges the compromises made for current generation devices but expresses concern about the weak password key stretching and the inability to derive the seed phrase from the wallet seed. Despite his concerns, he understands the motivation behind the decision.The discussion revolves around determining the version for different Bitcoin wallets and the use of BIP39. The group believes that brute force is an acceptable trade-off for not requiring the need to remember a version. They also disagree with the need for version "magic flags" or creation dates stored in the mnemonic. Wordlists don't require fixing between wallet providers according to BIP39 recommendations. The conversation also touches on the compatibility issues between Electrum 2.0 and BIP39, with Thomas V. explaining the reasons behind the differences.The conversation emphasizes the importance of being able to - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Improving-resistance-to-transaction-origination-harvesting.xml b/static/bitcoin-dev/March_2015/combined_Improving-resistance-to-transaction-origination-harvesting.xml index 10675a287b..6f7c80ceef 100644 --- a/static/bitcoin-dev/March_2015/combined_Improving-resistance-to-transaction-origination-harvesting.xml +++ b/static/bitcoin-dev/March_2015/combined_Improving-resistance-to-transaction-origination-harvesting.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Improving resistance to transaction origination harvesting - 2023-08-01T12:10:24.839942+00:00 + 2025-10-11T21:56:40.181268+00:00 + python-feedgen Wladimir J. van der Laan 2015-03-19 20:08:25+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Improving resistance to transaction origination harvesting - 2023-08-01T12:10:24.839942+00:00 + 2025-10-11T21:56:40.181445+00:00 - The proposal suggests implementing the use of CurveCP to enhance privacy and reduce leaks in the Bitcoin network. It proposes that Bitcoin nodes should be able to establish authenticated connections with trusted peers via CurveCP, ensuring that transactions are only broadcasted to these trusted peers. This, however, may result in reduced privacy for users who are unaware of how to use CurveCP or unable to determine the trustworthiness of their peers.To select trusted peers, a web of trust could be utilized, although caution must be exercised as mistakes can easily occur. Establishing a connection using CurveCP requires both parties to know each other's long-term public key, which can be stored in a structure similar to a Freenet node reference. Users would generate their node references through an API command and save them in the ~/.bitcoin/curvecp directory.While this approach may not directly improve privacy, it can be beneficial for whitelisting purposes, allowing trusted nodes to be subjected to fewer Denial of Service (DoS) constraints. The proposal also highlights that it can function independently of Tor usage; however, separating transaction submission from normal node functionality would significantly enhance privacy. In this scenario, the transaction submitter would connect to a few nodes through Tor, drop off the transaction, and then disconnect. This process would not advertise itself as a hidden service and should utilize a different Tor circuit compared to the node connections.Another aspect proposed is the implementation of Freenet's "Darknet" technique in Bitcoin. This involves enabling Bitcoin nodes to establish authenticated connections with trusted peers using CurveCP, ensuring that nodes with at least one CurveCP peer only broadcast their transactions to those specific peers. Similar to the previous proposal, the use of CurveCP requires both sides of the connection to possess knowledge of each other's long-term public key.To establish a secure connection between nodes, users would generate their node references using an API command and exchange these files, storing them in the ~/.bitcoin/curvecp directory with a .ref extension. CurveCP connections would take place on a separate port, designated by -bind_curvecp, -port_curvecp, and -externalip_curvecp, rather than sharing the same port as regular TCP connections.This proposal can work alongside or independently of Tor usage. Currently, configuring a node to anonymously submit transactions to the network requires making the node non-listening, thereby preventing it from contributing to the network. However, the proposal aims to allow nodes to be listening nodes while maintaining privacy regarding their own transactions. Additionally, CurveCP connections can be established between full nodes and Simplified Payment Verification (SPV) nodes, allowing transactions originating from SPV peers to be routed as if they originated from the full node. 2015-03-19T20:08:25+00:00 + The proposal suggests implementing the use of CurveCP to enhance privacy and reduce leaks in the Bitcoin network. It proposes that Bitcoin nodes should be able to establish authenticated connections with trusted peers via CurveCP, ensuring that transactions are only broadcasted to these trusted peers. This, however, may result in reduced privacy for users who are unaware of how to use CurveCP or unable to determine the trustworthiness of their peers.To select trusted peers, a web of trust could be utilized, although caution must be exercised as mistakes can easily occur. Establishing a connection using CurveCP requires both parties to know each other's long-term public key, which can be stored in a structure similar to a Freenet node reference. Users would generate their node references through an API command and save them in the ~/.bitcoin/curvecp directory.While this approach may not directly improve privacy, it can be beneficial for whitelisting purposes, allowing trusted nodes to be subjected to fewer Denial of Service (DoS) constraints. The proposal also highlights that it can function independently of Tor usage; however, separating transaction submission from normal node functionality would significantly enhance privacy. In this scenario, the transaction submitter would connect to a few nodes through Tor, drop off the transaction, and then disconnect. This process would not advertise itself as a hidden service and should utilize a different Tor circuit compared to the node connections.Another aspect proposed is the implementation of Freenet's "Darknet" technique in Bitcoin. This involves enabling Bitcoin nodes to establish authenticated connections with trusted peers using CurveCP, ensuring that nodes with at least one CurveCP peer only broadcast their transactions to those specific peers. Similar to the previous proposal, the use of CurveCP requires both sides of the connection to possess knowledge of each other's long-term public key.To establish a secure connection between nodes, users would generate their node references using an API command and exchange these files, storing them in the ~/.bitcoin/curvecp directory with a .ref extension. CurveCP connections would take place on a separate port, designated by -bind_curvecp, -port_curvecp, and -externalip_curvecp, rather than sharing the same port as regular TCP connections.This proposal can work alongside or independently of Tor usage. Currently, configuring a node to anonymously submit transactions to the network requires making the node non-listening, thereby preventing it from contributing to the network. However, the proposal aims to allow nodes to be listening nodes while maintaining privacy regarding their own transactions. Additionally, CurveCP connections can be established between full nodes and Simplified Payment Verification (SPV) nodes, allowing transactions originating from SPV peers to be routed as if they originated from the full node. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_My-thoughts-on-the-viability-of-the-Factom-token.xml b/static/bitcoin-dev/March_2015/combined_My-thoughts-on-the-viability-of-the-Factom-token.xml index 7cad21f123..51e3b39907 100644 --- a/static/bitcoin-dev/March_2015/combined_My-thoughts-on-the-viability-of-the-Factom-token.xml +++ b/static/bitcoin-dev/March_2015/combined_My-thoughts-on-the-viability-of-the-Factom-token.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - My thoughts on the viability of the Factom token - 2023-08-01T12:05:34.354284+00:00 + 2025-10-11T21:56:31.678761+00:00 + python-feedgen Peter Todd 2015-03-29 14:20:43+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - My thoughts on the viability of the Factom token - 2023-08-01T12:05:34.354284+00:00 + 2025-10-11T21:56:31.678928+00:00 - On a Bitcoin mailing list, Brian Deery shared a link to a Reddit thread discussing the launch of Factom's software token. Peter Todd requested that Deery explicitly list what he believes Factom prevents from happening as its primary function is security software. Factom aims to create a publishing platform that is resistant to both censorship and spam. It operates as a censorship and spam resistant third party similar to Bitcoin. The system is designed to be visible if someone tries to censor it, with other members actively fighting against any attempts at censorship. Factom sits in a sweet spot between Proof of Work and a centralized solution, making it a good option for interpreted protocols. The Factom protocol allows users to choose how they audit data independently of the packager, serving as proof of publication (POP). It enables users to create a dispassionate third party, while interpreted protocols like Counterparty filter out invalid transactions after the fact.The main goal of Factom is to create a proof-of-publication medium where facts can be published, and the token incentivizes people to maintain the required infrastructure for this medium. Factom servers provide a layer used by secondary proof-of-publication ledgers. By publishing records in the Factom layer, it proves that the secondary layer of actual facts is being maintained honestly. However, the consensus layer of Factom requires trust in Factom servers, which may compromise the ability to prove the honesty of Factom-secured records.It is worth noting that it is technically possible to secure ledgers in the Bitcoin blockchain without using Factom, although transaction fees must be paid. Threshold signatures can ensure that a majority of cities have to sign off on any updates to a meta-ledger for all their per-city property title systems. The only disadvantage of securing records directly in the blockchain is the payment of transaction fees.In conclusion, the viability of Factom and the value of its token are contingent on Bitcoin transaction fees rising or people choosing more complex and less secure systems over simpler ones. 2015-03-29T14:20:43+00:00 + On a Bitcoin mailing list, Brian Deery shared a link to a Reddit thread discussing the launch of Factom's software token. Peter Todd requested that Deery explicitly list what he believes Factom prevents from happening as its primary function is security software. Factom aims to create a publishing platform that is resistant to both censorship and spam. It operates as a censorship and spam resistant third party similar to Bitcoin. The system is designed to be visible if someone tries to censor it, with other members actively fighting against any attempts at censorship. Factom sits in a sweet spot between Proof of Work and a centralized solution, making it a good option for interpreted protocols. The Factom protocol allows users to choose how they audit data independently of the packager, serving as proof of publication (POP). It enables users to create a dispassionate third party, while interpreted protocols like Counterparty filter out invalid transactions after the fact.The main goal of Factom is to create a proof-of-publication medium where facts can be published, and the token incentivizes people to maintain the required infrastructure for this medium. Factom servers provide a layer used by secondary proof-of-publication ledgers. By publishing records in the Factom layer, it proves that the secondary layer of actual facts is being maintained honestly. However, the consensus layer of Factom requires trust in Factom servers, which may compromise the ability to prove the honesty of Factom-secured records.It is worth noting that it is technically possible to secure ledgers in the Bitcoin blockchain without using Factom, although transaction fees must be paid. Threshold signatures can ensure that a majority of cities have to sign off on any updates to a meta-ledger for all their per-city property title systems. The only disadvantage of securing records directly in the blockchain is the payment of transaction fees.In conclusion, the viability of Factom and the value of its token are contingent on Bitcoin transaction fees rising or people choosing more complex and less secure systems over simpler ones. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_New-paper-Research-Perspectives-and-Challenges-for-Bitcoin-and-Cryptocurrencies.xml b/static/bitcoin-dev/March_2015/combined_New-paper-Research-Perspectives-and-Challenges-for-Bitcoin-and-Cryptocurrencies.xml index 61395ff912..d1c5490d83 100644 --- a/static/bitcoin-dev/March_2015/combined_New-paper-Research-Perspectives-and-Challenges-for-Bitcoin-and-Cryptocurrencies.xml +++ b/static/bitcoin-dev/March_2015/combined_New-paper-Research-Perspectives-and-Challenges-for-Bitcoin-and-Cryptocurrencies.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies - 2023-08-01T11:59:17.677230+00:00 + 2025-10-11T21:56:38.059232+00:00 + python-feedgen Pindar Wong 2015-03-08 12:23:56+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies - 2023-08-01T11:59:17.677230+00:00 + 2025-10-11T21:56:38.059384+00:00 - A group of researchers from Stanford, Maryland, Concordia, and Princeton have written a "systemization" paper about Bitcoin-related research. The paper aims to bridge the gap between the computer science research community and the cryptocurrency community. It will be presented at the IEEE Security and Privacy conference later this year, but a draft has been released early. The researchers hope that their paper will bring attention to the best ideas and research questions from the Bitcoin community and inspire further research. The scope of the paper extends beyond Bitcoin to explain the differences between altcoins and other next-generation cryptocurrency designs. The research effort has taken around two years, with several pauses and restarts. The team is still open to feedback and plans to continue updating the online version of the paper. The draft can be found at http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf. 2015-03-08T12:23:56+00:00 + A group of researchers from Stanford, Maryland, Concordia, and Princeton have written a "systemization" paper about Bitcoin-related research. The paper aims to bridge the gap between the computer science research community and the cryptocurrency community. It will be presented at the IEEE Security and Privacy conference later this year, but a draft has been released early. The researchers hope that their paper will bring attention to the best ideas and research questions from the Bitcoin community and inspire further research. The scope of the paper extends beyond Bitcoin to explain the differences between altcoins and other next-generation cryptocurrency designs. The research effort has taken around two years, with several pauses and restarts. The team is still open to feedback and plans to continue updating the online version of the paper. The draft can be found at http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_On-Rewriting-Bitcoin-was-Re-Libbitcoin-Satoshi-client-is-a-fork-past-0-10-possible-.xml b/static/bitcoin-dev/March_2015/combined_On-Rewriting-Bitcoin-was-Re-Libbitcoin-Satoshi-client-is-a-fork-past-0-10-possible-.xml index f235854df8..2b742abf50 100644 --- a/static/bitcoin-dev/March_2015/combined_On-Rewriting-Bitcoin-was-Re-Libbitcoin-Satoshi-client-is-a-fork-past-0-10-possible-.xml +++ b/static/bitcoin-dev/March_2015/combined_On-Rewriting-Bitcoin-was-Re-Libbitcoin-Satoshi-client-is-a-fork-past-0-10-possible-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?) - 2023-08-01T11:36:42.299486+00:00 + 2025-10-11T21:56:25.308620+00:00 + python-feedgen Eric Voskuil 2015-03-25 08:04:48+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?) - 2023-08-01T11:36:42.299486+00:00 + 2025-10-11T21:56:25.308830+00:00 - In an email exchange dated February 14th, 2015, Peter Todd expressed frustration with the lack of transparency in the soft-forking process for Bitcoin. He suggested moving the consensus critical code out of Bitcoin Core and into a standalone libconsensus library to enable a more democratic decision-making process in future soft-forks. The email ended with a humorous comment from Todd's recipient.Mike Hearn clarified during a discussion about language bindings that while the project primarily focused on Java bindings, other languages' bindings would be separate projects. It was noted that Java/JNA bindings could still be used from other languages such as Python, Ruby, Javascript, PHP, Haskell, Lisp, Smalltalk, Scala, Kotlin, Ceylon, and more obscure languages. It was considered more practical to discuss bindings to particular runtimes rather than specific languages in today's world.A user recommended using Swig, a tool for generating bindings in an automated fashion, for creating Java bindings. Once generated with Swig, bindings for other languages can be easily adjusted. Java/JNA bindings can also be used from Python, Ruby, Javascript, PHP, as well as dialects of Haskell, Lisp, Smalltalk, and lesser-known languages like Scala, Kotlin, and Ceylon. It was suggested that it makes more sense to talk about bindings to particular runtimes rather than particular languages.On February 19, 2015, Tamas Blummer responded to Bryan Bishop's comment about language bindings in a project. Blummer clarified that the language binding would be a separate and independent project, solely using the C interface of the libconsensus library. Bishop had expressed his opinion that including all possible language bindings in a project would be unproductive. However, Blummer specified that only Java bindings were intended to be included, with other languages' bindings being separate projects.Bryan Bishop expressed his disagreement with voting for the lighthouse project on February 19, 2015. He clarified that he was referring to voting by pledging on the project rather than on the mailing list. Bishop also argued against squeezing all possible language bindings into a project, stating that it would be unproductive. However, Tamas Blummer suggested that the language binding would be a separate project hosted independently and only use the C interface of the libconsensus library.On February 18, 2015, Tamas Blummer launched the Lighthouse project aimed at adding Java Language Binding to lib consensus. However, Bryan disagreed with the idea of voting and squeezing all possible language bindings into one project. Instead, he suggested exploring a solution similar to what the webkit people did by having gobject bindings. This solution allows all languages to have their own gobject bridge. Blummer's contact information can be found at http://heybryan.org/ and he can be reached at 1 512 203 0507.Tamas Blummer initiated a Lighthouse project on February 19, 2015, aimed at adding Java language binding to the core consensus library. The proposed language binding would allow JVM application developers to innovate without raising concerns about network forks through incompatible alternate protocol implementations. It would be written using lightweight, immutable, and self-contained data classes that use only language standard libraries, making it suitable for any service framework.Tamas Blummer announced the launch of the Lighthouse project to integrate Java language binding to lib consensus. According to Blummer, this will create an alternative to the border router setup in a production environment. The announcement was made on Reddit's Lighthouse Projects page and Blummer hopes that it will lead to constructive debate and voting.Troy Benjegerdes suggests treating the consensus code as a buggy and poorly defined proof-of-concept rather than holy scripture. He recommends looking at the git commit history for the consensus-critical part of the Bitcoin Core codebase as much work has been done in cleaning it up and refactoring for v0.10.0/libconsensus.Tamas Blummer explains that he is using Bitcoin Core as a border router while talking to its P2P interface. His reimplementation of consensus code helps him understand the protocol better, aids debugging, and can be used to create a side chain. He argues that the quality of the consensus code could improve significantly if the community treated it as a buggy and poorly defined proof-of-concept that just happens to actually run.In an email exchange between Tamas Blummer and Peter Todd, Blummer defends his use of Bitcoin Core as a border router and explains how the reimplementation of consensus code has helped him. Todd criticizes Blummer's work and advises him to acquire prior experience before claiming its usefulness. The conversation ends with Blummer condemning Todd's behavior and accusing him of bad-mouthing the work of others.Adam Back and Peter Todd discuss the risks of consensus rewrite experiments in maintaining strict consensus between Bitcoin Core versions. They agree that rewriting the consensus protocol should be approached cautiously to avoid contributing to centralization. 2015-03-25T08:04:48+00:00 + In an email exchange dated February 14th, 2015, Peter Todd expressed frustration with the lack of transparency in the soft-forking process for Bitcoin. He suggested moving the consensus critical code out of Bitcoin Core and into a standalone libconsensus library to enable a more democratic decision-making process in future soft-forks. The email ended with a humorous comment from Todd's recipient.Mike Hearn clarified during a discussion about language bindings that while the project primarily focused on Java bindings, other languages' bindings would be separate projects. It was noted that Java/JNA bindings could still be used from other languages such as Python, Ruby, Javascript, PHP, Haskell, Lisp, Smalltalk, Scala, Kotlin, Ceylon, and more obscure languages. It was considered more practical to discuss bindings to particular runtimes rather than specific languages in today's world.A user recommended using Swig, a tool for generating bindings in an automated fashion, for creating Java bindings. Once generated with Swig, bindings for other languages can be easily adjusted. Java/JNA bindings can also be used from Python, Ruby, Javascript, PHP, as well as dialects of Haskell, Lisp, Smalltalk, and lesser-known languages like Scala, Kotlin, and Ceylon. It was suggested that it makes more sense to talk about bindings to particular runtimes rather than particular languages.On February 19, 2015, Tamas Blummer responded to Bryan Bishop's comment about language bindings in a project. Blummer clarified that the language binding would be a separate and independent project, solely using the C interface of the libconsensus library. Bishop had expressed his opinion that including all possible language bindings in a project would be unproductive. However, Blummer specified that only Java bindings were intended to be included, with other languages' bindings being separate projects.Bryan Bishop expressed his disagreement with voting for the lighthouse project on February 19, 2015. He clarified that he was referring to voting by pledging on the project rather than on the mailing list. Bishop also argued against squeezing all possible language bindings into a project, stating that it would be unproductive. However, Tamas Blummer suggested that the language binding would be a separate project hosted independently and only use the C interface of the libconsensus library.On February 18, 2015, Tamas Blummer launched the Lighthouse project aimed at adding Java Language Binding to lib consensus. However, Bryan disagreed with the idea of voting and squeezing all possible language bindings into one project. Instead, he suggested exploring a solution similar to what the webkit people did by having gobject bindings. This solution allows all languages to have their own gobject bridge. Blummer's contact information can be found at http://heybryan.org/ and he can be reached at 1 512 203 0507.Tamas Blummer initiated a Lighthouse project on February 19, 2015, aimed at adding Java language binding to the core consensus library. The proposed language binding would allow JVM application developers to innovate without raising concerns about network forks through incompatible alternate protocol implementations. It would be written using lightweight, immutable, and self-contained data classes that use only language standard libraries, making it suitable for any service framework.Tamas Blummer announced the launch of the Lighthouse project to integrate Java language binding to lib consensus. According to Blummer, this will create an alternative to the border router setup in a production environment. The announcement was made on Reddit's Lighthouse Projects page and Blummer hopes that it will lead to constructive debate and voting.Troy Benjegerdes suggests treating the consensus code as a buggy and poorly defined proof-of-concept rather than holy scripture. He recommends looking at the git commit history for the consensus-critical part of the Bitcoin Core codebase as much work has been done in cleaning it up and refactoring for v0.10.0/libconsensus.Tamas Blummer explains that he is using Bitcoin Core as a border router while talking to its P2P interface. His reimplementation of consensus code helps him understand the protocol better, aids debugging, and can be used to create a side chain. He argues that the quality of the consensus code could improve significantly if the community treated it as a buggy and poorly defined proof-of-concept that just happens to actually run.In an email exchange between Tamas Blummer and Peter Todd, Blummer defends his use of Bitcoin Core as a border router and explains how the reimplementation of consensus code has helped him. Todd criticizes Blummer's work and advises him to acquire prior experience before claiming its usefulness. The conversation ends with Blummer condemning Todd's behavior and accusing him of bad-mouthing the work of others.Adam Back and Peter Todd discuss the risks of consensus rewrite experiments in maintaining strict consensus between Bitcoin Core versions. They agree that rewriting the consensus protocol should be approached cautiously to avoid contributing to centralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Proof-of-Payment.xml b/static/bitcoin-dev/March_2015/combined_Proof-of-Payment.xml index c27e73fd00..5cb0244d58 100644 --- a/static/bitcoin-dev/March_2015/combined_Proof-of-Payment.xml +++ b/static/bitcoin-dev/March_2015/combined_Proof-of-Payment.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proof of Payment - 2023-08-01T12:01:55.202198+00:00 + 2025-10-11T21:56:50.837574+00:00 + python-feedgen Jorge Timón 2015-04-28 12:53:58+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Proof of Payment - 2023-08-01T12:01:55.202198+00:00 + 2025-10-11T21:56:50.837740+00:00 - In the context, a new idea called Proof of Payment (PoP) has been proposed by Kalle Rosenbaum to provide proof that a payment has been made. This concept can be applied in various scenarios such as pre-paid hotel rooms, online video rental services, ad-signs, and lotteries. PoP is unique because it can be generated on demand and is only usable once to prevent theft issues. It is also capable of creating PoP for any payment regardless of script type.The author discusses the current methods of proving payment, including BIP0070 and signing messages with private keys. However, the author believes that these methods have limitations. To address this, the author introduces the data structure and process for PoP. This involves generating a request from the server to the wallet, identifying the transaction, creating an unsigned PoP, signing the UPoP to create PoP, sending PoP to the destination, and validating it.The format of PoP and security issues are also addressed in the context. Potential interception of PoP requests and stealing of PoP are identified as potential concerns. The importance of maintaining the security of wallets after they have been emptied is emphasized. Further work to be done includes extending BIP0070 for PoPs, defining an extension for BIP0021 to support PoP requests, implementing a proof-of-concept, and proposing BIPs for the different parts.In addition, the context mentions the concept of Anonymous Credentials, which provides privacy for service usage while maintaining accountability for payment. The issuance of Anonymous Credentials is not atomic with payment transactions, but proof of payment can be used in court if the credentials are not issued. The Zerocoin developers have also published a paper on a blockchain version of Distributed Anonymous Credentials, with a link provided for additional information.Overall, the proposal of Proof of Payment (PoP) aims to offer a reliable method for proving that a payment has been made, with various use cases and desirable properties discussed. The context also highlights the need for further development and implementation of PoP-related protocols and extensions. 2015-04-28T12:53:58+00:00 + In the context, a new idea called Proof of Payment (PoP) has been proposed by Kalle Rosenbaum to provide proof that a payment has been made. This concept can be applied in various scenarios such as pre-paid hotel rooms, online video rental services, ad-signs, and lotteries. PoP is unique because it can be generated on demand and is only usable once to prevent theft issues. It is also capable of creating PoP for any payment regardless of script type.The author discusses the current methods of proving payment, including BIP0070 and signing messages with private keys. However, the author believes that these methods have limitations. To address this, the author introduces the data structure and process for PoP. This involves generating a request from the server to the wallet, identifying the transaction, creating an unsigned PoP, signing the UPoP to create PoP, sending PoP to the destination, and validating it.The format of PoP and security issues are also addressed in the context. Potential interception of PoP requests and stealing of PoP are identified as potential concerns. The importance of maintaining the security of wallets after they have been emptied is emphasized. Further work to be done includes extending BIP0070 for PoPs, defining an extension for BIP0021 to support PoP requests, implementing a proof-of-concept, and proposing BIPs for the different parts.In addition, the context mentions the concept of Anonymous Credentials, which provides privacy for service usage while maintaining accountability for payment. The issuance of Anonymous Credentials is not atomic with payment transactions, but proof of payment can be used in court if the credentials are not issued. The Zerocoin developers have also published a paper on a blockchain version of Distributed Anonymous Credentials, with a link provided for additional information.Overall, the proposal of Proof of Payment (PoP) aims to offer a reliable method for proving that a payment has been made, with various use cases and desirable properties discussed. The context also highlights the need for further development and implementation of PoP-related protocols and extensions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml b/static/bitcoin-dev/March_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml index da4d81be46..c00ea013d9 100644 --- a/static/bitcoin-dev/March_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml +++ b/static/bitcoin-dev/March_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) - 2023-08-01T12:06:55.534846+00:00 + 2025-10-11T21:56:18.936788+00:00 + python-feedgen Tier Nolan 2015-05-06 22:09:59+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) - 2023-08-01T12:06:55.535908+00:00 + 2025-10-11T21:56:18.936990+00:00 - Several proposals and ideas were discussed by Bitcoin developers regarding the implementation of new opcodes and changes to the Bitcoin scripting system. One proposal was the addition of CHECKLOCKTIMEVERIFY (CLTV), which would make a transaction output unspendable until a certain point in the future. Another proposal suggested increasing the transaction version to achieve a similar outcome. Developers expressed concerns about changing the semantics of nSequence and the potential impact on previously valid transactions. Mark Friedenbach proposed an nSequence-based RCLTV proposal that was already reorg safe. Peter Todd and Matt Corallo discussed the idea of adding OP_RELATIVECHECKLOCKTIMEVERIFY (RCLTV) opcode, acknowledging its drawbacks but highlighting its usefulness for certain protocols. The conversations also touched on time-based locks and the potential incentive issues with mining. Timón proposed a new softfork rule to enforce setting the nHeight of CTxIn to the correct height. Discussions also revolved around implementing RCLTV and OP_MATURITY for more secure transactions against reorganization. In March 2015, Matt Corallo proposed requiring locktime to be at least N plus the input's height. Zooko preferred relative CHECKLOCKTIMEVERIFY over absolute CHECKLOCKTIMEVERIFY due to concerns about "race conditions."The article discusses the use of the CHECKLOCKTIMEVERIFY opcode in Bitcoin scripts and its applications. Despite challenges such as exposing script information and enforcing mempool invariants during reorganizations, CHECKLOCKTIMEVERIFY can be used in non-interactive time-locked refunds, two-factor wallets, and micropayment channels. Two-factor wallets utilize 2-of-2 multisig scriptPubKeys, allowing users to spend funds without the cooperation of the service by waiting for the expiry time. The article also addresses vulnerabilities in Bitcoin protocols and suggests solutions. It analyzes micropayment channels and proposes using the same scriptPubKey as the two-factor wallet example to solve issues with refund transactions. The PayPub protocol for trustless payments for information is discussed, highlighting a flaw in the existing implementation that can be addressed with scriptPubKeys. The challenge of proving sacrifices of coins to mining fees is mentioned, and CHECKLOCKTIMEVERIFY is suggested as a solution to discourage mining centralization. Finally, the article suggests replacing the nLockTime field entirely with a per-signature capability that would serve as proof of spendability. Detailed specifications and references are provided for these proposed solutions. 2015-05-06T22:09:59+00:00 + Several proposals and ideas were discussed by Bitcoin developers regarding the implementation of new opcodes and changes to the Bitcoin scripting system. One proposal was the addition of CHECKLOCKTIMEVERIFY (CLTV), which would make a transaction output unspendable until a certain point in the future. Another proposal suggested increasing the transaction version to achieve a similar outcome. Developers expressed concerns about changing the semantics of nSequence and the potential impact on previously valid transactions. Mark Friedenbach proposed an nSequence-based RCLTV proposal that was already reorg safe. Peter Todd and Matt Corallo discussed the idea of adding OP_RELATIVECHECKLOCKTIMEVERIFY (RCLTV) opcode, acknowledging its drawbacks but highlighting its usefulness for certain protocols. The conversations also touched on time-based locks and the potential incentive issues with mining. Timón proposed a new softfork rule to enforce setting the nHeight of CTxIn to the correct height. Discussions also revolved around implementing RCLTV and OP_MATURITY for more secure transactions against reorganization. In March 2015, Matt Corallo proposed requiring locktime to be at least N plus the input's height. Zooko preferred relative CHECKLOCKTIMEVERIFY over absolute CHECKLOCKTIMEVERIFY due to concerns about "race conditions."The article discusses the use of the CHECKLOCKTIMEVERIFY opcode in Bitcoin scripts and its applications. Despite challenges such as exposing script information and enforcing mempool invariants during reorganizations, CHECKLOCKTIMEVERIFY can be used in non-interactive time-locked refunds, two-factor wallets, and micropayment channels. Two-factor wallets utilize 2-of-2 multisig scriptPubKeys, allowing users to spend funds without the cooperation of the service by waiting for the expiry time. The article also addresses vulnerabilities in Bitcoin protocols and suggests solutions. It analyzes micropayment channels and proposes using the same scriptPubKey as the two-factor wallet example to solve issues with refund transactions. The PayPub protocol for trustless payments for information is discussed, highlighting a flaw in the existing implementation that can be addressed with scriptPubKeys. The challenge of proving sacrifices of coins to mining fees is mentioned, and CHECKLOCKTIMEVERIFY is suggested as a solution to discourage mining centralization. Finally, the article suggests replacing the nLockTime field entirely with a per-signature capability that would serve as proof of spendability. Detailed specifications and references are provided for these proposed solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Testnet3.xml b/static/bitcoin-dev/March_2015/combined_Testnet3.xml index d75291fa72..ac7e91ee35 100644 --- a/static/bitcoin-dev/March_2015/combined_Testnet3.xml +++ b/static/bitcoin-dev/March_2015/combined_Testnet3.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Testnet3 - 2023-08-01T12:00:39.121035+00:00 + 2025-10-11T21:56:29.556960+00:00 + python-feedgen Thy Shizzle 2015-03-12 06:36:02+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Testnet3 - 2023-08-01T12:00:39.121035+00:00 + 2025-10-11T21:56:29.557115+00:00 - The author of the post is facing issues while migrating their .NET node to testnet. They have confirmed that their messages are being sent with the correct packet magic using Wireshark. However, when they connect to a test node obtained from DNS seed testnet-seed.bitcoin.petertodd.org, they do not receive a verack or version in response. Instead, they only receive a ping before the connection is severed by the remote node. The author is perplexed as they are using the correct testnet3 packet magic value and their code is specifically looking for it. Interestingly, their code functions properly with the mainnet packet magic value. It is worth noting that the author's code was previously stuck in a loop/ping circuit, but it started working correctly without any changes made.Currently, the user is developing a .NET node for communication on the P2P network. They now want to migrate to the testnet to begin making and validating transactions. Their current packet magic value is 0x0b110907, and they have verified through Wireshark that their messages contain this packet magic. However, when they attempt to connect to a test node obtained from DNS seed testnet-seed.bitcoin.petertodd.org and send a version message with the testnet3 packet magic, they do not receive the expected verack or version in response. Instead, they only receive a ping before the connection is abruptly terminated by the remote node. In an effort to resolve this issue, the user has been debugging their code and ensuring that it is specifically looking for the testnet3 packet magic. However, despite their efforts, they still do not receive the desired response from the node. It is important to note that the code functions properly when using the mainnet packet magic value of 0x0f9beb4d9. 2015-03-12T06:36:02+00:00 + The author of the post is facing issues while migrating their .NET node to testnet. They have confirmed that their messages are being sent with the correct packet magic using Wireshark. However, when they connect to a test node obtained from DNS seed testnet-seed.bitcoin.petertodd.org, they do not receive a verack or version in response. Instead, they only receive a ping before the connection is severed by the remote node. The author is perplexed as they are using the correct testnet3 packet magic value and their code is specifically looking for it. Interestingly, their code functions properly with the mainnet packet magic value. It is worth noting that the author's code was previously stuck in a loop/ping circuit, but it started working correctly without any changes made.Currently, the user is developing a .NET node for communication on the P2P network. They now want to migrate to the testnet to begin making and validating transactions. Their current packet magic value is 0x0b110907, and they have verified through Wireshark that their messages contain this packet magic. However, when they attempt to connect to a test node obtained from DNS seed testnet-seed.bitcoin.petertodd.org and send a version message with the testnet3 packet magic, they do not receive the expected verack or version in response. Instead, they only receive a ping before the connection is abruptly terminated by the remote node. In an effort to resolve this issue, the user has been debugging their code and ensuring that it is specifically looking for the testnet3 packet magic. However, despite their efforts, they still do not receive the desired response from the node. It is important to note that the code functions properly when using the mainnet packet magic value of 0x0f9beb4d9. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_Useless-Address-attack-.xml b/static/bitcoin-dev/March_2015/combined_Useless-Address-attack-.xml index 85baebb187..5ec83013ca 100644 --- a/static/bitcoin-dev/March_2015/combined_Useless-Address-attack-.xml +++ b/static/bitcoin-dev/March_2015/combined_Useless-Address-attack-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Useless Address attack? - 2023-08-01T11:59:35.185670+00:00 + 2025-10-11T21:56:27.432553+00:00 + python-feedgen Thy Shizzle 2015-03-05 03:18:54+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Useless Address attack? - 2023-08-01T11:59:35.185670+00:00 + 2025-10-11T21:56:27.432714+00:00 - A member of the Bitcoin development mailing list has expressed concerns about the potential for slowing down communication on the P2P network by utilizing dummy nodes. In response, Kevin Greene explains that Bitcoind effectively safeguards against this by storing addresses in randomized buckets, which are selected based on the IP of the peer and the address in the message. This random bucketing prevents attackers from overwhelming the database with their own nodes. Additionally, misbehaving nodes can be blacklisted for a certain period of time to prevent persistent connection attempts.Bitcoind's address manager protects against potential attackers by organizing addresses into buckets. The selection of these buckets is determined by the IP of the peer advertising the address message and the address itself. By randomly assigning addresses to buckets, the risk of an attacker filling the entire table with their own nodes is mitigated. Addresses that have not yet been tried are placed in "new" buckets, while addresses of known accessible nodes are stored in "tried" buckets. The selection of buckets is based on cryptographic hashing using a 256-bit key that is randomly generated. To ensure high performance, various indexes are maintained.Someone on the Bitcoin-development mailing list suggests the idea of congesting the address pool with dummy nodes to slow down communication on the P2P network. The proposal involves sending addr messages with 1000 addresses pointing to these useless nodes, potentially causing clients to connect to them instead of legitimate ones. The individual speculates that if the address pool were filled with enough addresses to these dummy nodes and they were kept fresh, it could have a notable impact, particularly if all eight outbound connections were occupied by these nodes. However, Bitcoind's address manager thwarts such an attack through the random organization of addresses into buckets and the use of cryptographic hashing for bucket selection.It is important to note that the writer of this message is merely considering this plan while building their own node and does not actually intend to carry it out. They seek information regarding the measures in place to prevent such tactics from being employed. 2015-03-05T03:18:54+00:00 + A member of the Bitcoin development mailing list has expressed concerns about the potential for slowing down communication on the P2P network by utilizing dummy nodes. In response, Kevin Greene explains that Bitcoind effectively safeguards against this by storing addresses in randomized buckets, which are selected based on the IP of the peer and the address in the message. This random bucketing prevents attackers from overwhelming the database with their own nodes. Additionally, misbehaving nodes can be blacklisted for a certain period of time to prevent persistent connection attempts.Bitcoind's address manager protects against potential attackers by organizing addresses into buckets. The selection of these buckets is determined by the IP of the peer advertising the address message and the address itself. By randomly assigning addresses to buckets, the risk of an attacker filling the entire table with their own nodes is mitigated. Addresses that have not yet been tried are placed in "new" buckets, while addresses of known accessible nodes are stored in "tried" buckets. The selection of buckets is based on cryptographic hashing using a 256-bit key that is randomly generated. To ensure high performance, various indexes are maintained.Someone on the Bitcoin-development mailing list suggests the idea of congesting the address pool with dummy nodes to slow down communication on the P2P network. The proposal involves sending addr messages with 1000 addresses pointing to these useless nodes, potentially causing clients to connect to them instead of legitimate ones. The individual speculates that if the address pool were filled with enough addresses to these dummy nodes and they were kept fresh, it could have a notable impact, particularly if all eight outbound connections were occupied by these nodes. However, Bitcoind's address manager thwarts such an attack through the random organization of addresses into buckets and the use of cryptographic hashing for bucket selection.It is important to note that the writer of this message is merely considering this plan while building their own node and does not actually intend to carry it out. They seek information regarding the measures in place to prevent such tactics from being employed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_bip44-GPG-identities-POC-demo.xml b/static/bitcoin-dev/March_2015/combined_bip44-GPG-identities-POC-demo.xml index 06db8da6e3..a378c7e932 100644 --- a/static/bitcoin-dev/March_2015/combined_bip44-GPG-identities-POC-demo.xml +++ b/static/bitcoin-dev/March_2015/combined_bip44-GPG-identities-POC-demo.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bip44 GPG identities - POC demo - 2023-08-01T11:59:54.500939+00:00 + 2025-10-11T21:56:35.935999+00:00 + python-feedgen Natanael 2015-03-08 08:20:31+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - bip44 GPG identities - POC demo - 2023-08-01T11:59:54.501945+00:00 + 2025-10-11T21:56:35.936156+00:00 - Pavol Rusnak, in an email thread, discussed his implementation of a SignIdentity message for TREZOR, which would be used for HTTPS/SSH logins. He proposed deriving the BIP32 path from the HTTPS/SSH URI and using it to derive the private key. This scheme could also be applicable to GPG keys. Another member in the thread mentioned FIDO's U2F protocol, which prevents credential phishing by tying into the browser SSL session. Yubico's FIDO U2F security key was also mentioned, as it generates a unique keypair for each service to enhance privacy. However, using the device alone does not allow easy identification across services for individuals with multiple pseudonyms.A user named Mem Wallet shared their approach to managing a GPG identity for encryption and signing with zero bytes of permanent storage. Pavol Rusnak, as the author of BIP44, suggested allocating a new BIP number instead of using BIP44 for this purpose. He proposed creating a GPG key hierarchy per device/master seed rather than per Bitcoin account. In addition, Pavol Rusnak mentioned that he was working on implementing a SignIdentity message for TREZOR, specifically for HTTPS/SSH/etc. logins. He shared a proof of concept (PoC) on Github, where the BIP32 path would be derived from the HTTPS/SSH URI to obtain the private key. The same scheme might also work for GPG keys by utilizing "gpg://user@host.com" as the URI.Furthermore, there is a javascript implementation available on http://memwallet.info/bip44ext/test.html that demonstrates the use of a bip44 Wallet to generate deterministic GPG identities. This allows users to manage a GPG identity for encryption and signing without requiring any permanent storage, such as on Tails. The paper detailing this implementation can be found on https://github.com/taelfrinn/bip44extention/blob/master/README.md. A minor correction has been made to the implementation, specifying that the smallest S value should be used to prevent non-canonical/identical outputs caused by different ecdsa implementations. Feedback and comments on this approach are welcome. 2015-03-08T08:20:31+00:00 + Pavol Rusnak, in an email thread, discussed his implementation of a SignIdentity message for TREZOR, which would be used for HTTPS/SSH logins. He proposed deriving the BIP32 path from the HTTPS/SSH URI and using it to derive the private key. This scheme could also be applicable to GPG keys. Another member in the thread mentioned FIDO's U2F protocol, which prevents credential phishing by tying into the browser SSL session. Yubico's FIDO U2F security key was also mentioned, as it generates a unique keypair for each service to enhance privacy. However, using the device alone does not allow easy identification across services for individuals with multiple pseudonyms.A user named Mem Wallet shared their approach to managing a GPG identity for encryption and signing with zero bytes of permanent storage. Pavol Rusnak, as the author of BIP44, suggested allocating a new BIP number instead of using BIP44 for this purpose. He proposed creating a GPG key hierarchy per device/master seed rather than per Bitcoin account. In addition, Pavol Rusnak mentioned that he was working on implementing a SignIdentity message for TREZOR, specifically for HTTPS/SSH/etc. logins. He shared a proof of concept (PoC) on Github, where the BIP32 path would be derived from the HTTPS/SSH URI to obtain the private key. The same scheme might also work for GPG keys by utilizing "gpg://user@host.com" as the URI.Furthermore, there is a javascript implementation available on http://memwallet.info/bip44ext/test.html that demonstrates the use of a bip44 Wallet to generate deterministic GPG identities. This allows users to manage a GPG identity for encryption and signing without requiring any permanent storage, such as on Tails. The paper detailing this implementation can be found on https://github.com/taelfrinn/bip44extention/blob/master/README.md. A minor correction has been made to the implementation, specifying that the smallest S value should be used to prevent non-canonical/identical outputs caused by different ecdsa implementations. Feedback and comments on this approach are welcome. - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2015/combined_replace-by-fee-v0-10-0rc4.xml b/static/bitcoin-dev/March_2015/combined_replace-by-fee-v0-10-0rc4.xml index deb959fa0c..bb20fb2000 100644 --- a/static/bitcoin-dev/March_2015/combined_replace-by-fee-v0-10-0rc4.xml +++ b/static/bitcoin-dev/March_2015/combined_replace-by-fee-v0-10-0rc4.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - replace-by-fee v0.10.0rc4 - 2023-08-01T11:29:50.426652+00:00 + 2025-10-11T21:56:33.807951+00:00 + python-feedgen Neil Fincham 2015-03-01 19:05:39+00:00 @@ -307,13 +308,13 @@ - python-feedgen + 2 Combined summary - replace-by-fee v0.10.0rc4 - 2023-08-01T11:29:50.427648+00:00 + 2025-10-11T21:56:33.808258+00:00 - In a series of email conversations and forum discussions within the Bitcoin community, several topics related to the issue of double-spending in Bitcoin are explored. One of the main focuses is on the concept of replace-by-fee (RBF) and its potential impact on zero confirmation (0-conf) transactions. There are concerns that implementing RBF for all transactions could harm present-day Bitcoin payments and push instant transactions towards centralized services. However, there is also recognition that 0-conf transactions need a security upgrade.Jeff Garzik, a Bitcoin core developer, acknowledges the importance of secure 0-conf transactions for rapid payments but emphasizes the need for careful consideration when making changes to avoid harming the system. He suggests finding a solution that balances security and convenience. The distinction between fee replacement and output replacement in double-spending cases is discussed. It is suggested that fee replacement can be handled by relaying both conflicting transactions and letting miners choose one, while output replacement can be rewarded to a miner if they include both conflicting transactions in the same block.The conversation also delves into the ANYONECANPAY feature in Bitcoin and its potential vulnerabilities. Ways to defeat this feature through double-spending with high fees are discussed, as well as concerns about the effectiveness of the replace-by-fee patch in detecting and relaying double-spends. The importance of understanding weaknesses and limitations in order to improve the system is emphasized.The need for reversible mechanisms and decentralized solutions in payment processing technologies is highlighted. The proposal of "Solomon's spend" as a potential solution involving a hacked exchange, insurance contracts, and incentivizing miners to roll back the chain is presented. The importance of balancing security and convenience in developing payment processing technologies is emphasized.The discussions also touch on the issue of settlement times in payment systems and the benefits of reversible mechanisms built on top of Bitcoin. The suggestion is made to extend the zero-conf double-spend transaction reversal to allow senders and receivers a choice to use it or not. The need for a base currency that is non-reversible is highlighted.There are debates about the terminology used to describe the 0-conf protocol based on game theory, with suggestions to extend the zero-conf double-spend transaction reversal explicitly. The rarity of massive double-spending incidents in Bitcoin is discussed, as well as concerns about relying on moral judgments and altruism as a security model.The controversy around replace-by-fee (RBF) in Bitcoin transactions is also explored. Some argue in favor of RBF, stating that it can improve the efficiency of the transaction fee marketplace. Others raise concerns about its potential misuse and negative impact on the Bitcoin network.Overall, the discussions highlight the need for solutions to address the issue of double-spending in Bitcoin while considering the trade-offs between security, convenience, and decentralization. The importance of understanding weaknesses, improving security through penetration testing, and developing alternative solutions is emphasized.In a series of email exchanges in February 2015, the risks and limitations of relying on zero-confirmation transactions in Bitcoin were discussed. One concept that was debated was replace-by-fee (RBF), which allows users to increase the fee of a transaction after it has been sent, potentially leading to double-spending. While some considered RBF fraudulent, others saw it differently.The context emphasizes the vulnerabilities of Bitcoin, particularly for merchants who accept payments with zero confirmations. It is suggested that these merchants may be targeted by attackers. To mitigate this risk, some merchants may establish a network of trusted third parties to interact with the blockchain. However, cunning merchants could exploit this system by keeping transactions counter-signed by third parties in their wallets and passing them along without paying miner fees until someone needs to pay all the fees at once.Bitcoin's vulnerability to attacks by a large group of miners is also discussed. However, it is noted that such attacks are not directed towards Bitcoin itself but towards merchants who accept zero-confirmation payments. The possibility of proving a double spend instantly by showing conflicting transactions signed by the same party is mentioned.There is a suggestion to explore alternative solutions to address the potential unreliability of unconfirmed payments, as people may stop using Bitcoin if they become unreliable. One proposed solution is a decentralized IOU-based payment network similar to Ripple, specifically designed for "dumb and daily" payments. This would eliminate the need for zero-confirmation transactions and reduce the need to debate block size limits.The idea of collateralized multisignature notaries is introduced as an extended version of the Greenaddress.it model. This model renders unconfirmed transactions useless in the classical Bitcoin model. However, introducing trusted third parties would reintroduce the disadvantages of centralized trust.The role of miners and their incentives in Bitcoin is discussed. It is argued that miners are incentivized not to earn the most money in the next block but to maximize their return on investment. Making Bitcoin less useful would reduce the demand for mined bitcoins, resulting in a decrease in income for miners.Various email exchanges between individuals such as Tamas Bl 2015-03-01T19:05:39+00:00 + In a series of email conversations and forum discussions within the Bitcoin community, several topics related to the issue of double-spending in Bitcoin are explored. One of the main focuses is on the concept of replace-by-fee (RBF) and its potential impact on zero confirmation (0-conf) transactions. There are concerns that implementing RBF for all transactions could harm present-day Bitcoin payments and push instant transactions towards centralized services. However, there is also recognition that 0-conf transactions need a security upgrade.Jeff Garzik, a Bitcoin core developer, acknowledges the importance of secure 0-conf transactions for rapid payments but emphasizes the need for careful consideration when making changes to avoid harming the system. He suggests finding a solution that balances security and convenience. The distinction between fee replacement and output replacement in double-spending cases is discussed. It is suggested that fee replacement can be handled by relaying both conflicting transactions and letting miners choose one, while output replacement can be rewarded to a miner if they include both conflicting transactions in the same block.The conversation also delves into the ANYONECANPAY feature in Bitcoin and its potential vulnerabilities. Ways to defeat this feature through double-spending with high fees are discussed, as well as concerns about the effectiveness of the replace-by-fee patch in detecting and relaying double-spends. The importance of understanding weaknesses and limitations in order to improve the system is emphasized.The need for reversible mechanisms and decentralized solutions in payment processing technologies is highlighted. The proposal of "Solomon's spend" as a potential solution involving a hacked exchange, insurance contracts, and incentivizing miners to roll back the chain is presented. The importance of balancing security and convenience in developing payment processing technologies is emphasized.The discussions also touch on the issue of settlement times in payment systems and the benefits of reversible mechanisms built on top of Bitcoin. The suggestion is made to extend the zero-conf double-spend transaction reversal to allow senders and receivers a choice to use it or not. The need for a base currency that is non-reversible is highlighted.There are debates about the terminology used to describe the 0-conf protocol based on game theory, with suggestions to extend the zero-conf double-spend transaction reversal explicitly. The rarity of massive double-spending incidents in Bitcoin is discussed, as well as concerns about relying on moral judgments and altruism as a security model.The controversy around replace-by-fee (RBF) in Bitcoin transactions is also explored. Some argue in favor of RBF, stating that it can improve the efficiency of the transaction fee marketplace. Others raise concerns about its potential misuse and negative impact on the Bitcoin network.Overall, the discussions highlight the need for solutions to address the issue of double-spending in Bitcoin while considering the trade-offs between security, convenience, and decentralization. The importance of understanding weaknesses, improving security through penetration testing, and developing alternative solutions is emphasized.In a series of email exchanges in February 2015, the risks and limitations of relying on zero-confirmation transactions in Bitcoin were discussed. One concept that was debated was replace-by-fee (RBF), which allows users to increase the fee of a transaction after it has been sent, potentially leading to double-spending. While some considered RBF fraudulent, others saw it differently.The context emphasizes the vulnerabilities of Bitcoin, particularly for merchants who accept payments with zero confirmations. It is suggested that these merchants may be targeted by attackers. To mitigate this risk, some merchants may establish a network of trusted third parties to interact with the blockchain. However, cunning merchants could exploit this system by keeping transactions counter-signed by third parties in their wallets and passing them along without paying miner fees until someone needs to pay all the fees at once.Bitcoin's vulnerability to attacks by a large group of miners is also discussed. However, it is noted that such attacks are not directed towards Bitcoin itself but towards merchants who accept zero-confirmation payments. The possibility of proving a double spend instantly by showing conflicting transactions signed by the same party is mentioned.There is a suggestion to explore alternative solutions to address the potential unreliability of unconfirmed payments, as people may stop using Bitcoin if they become unreliable. One proposed solution is a decentralized IOU-based payment network similar to Ripple, specifically designed for "dumb and daily" payments. This would eliminate the need for zero-confirmation transactions and reduce the need to debate block size limits.The idea of collateralized multisignature notaries is introduced as an extended version of the Greenaddress.it model. This model renders unconfirmed transactions useless in the classical Bitcoin model. However, introducing trusted third parties would reintroduce the disadvantages of centralized trust.The role of miners and their incentives in Bitcoin is discussed. It is argued that miners are incentivized not to earn the most money in the next block but to maximize their return on investment. Making Bitcoin less useful would reduce the demand for mined bitcoins, resulting in a decrease in income for miners.Various email exchanges between individuals such as Tamas Bl - + \ No newline at end of file diff --git a/static/bitcoin-dev/March_2016/combined_BIP-2-promotion-to-Final.xml b/static/bitcoin-dev/March_2016/combined_BIP-2-promotion-to-Final.xml index 8aac466c22..293517b9fe 100644 --- a/static/bitcoin-dev/March_2016/combined_BIP-2-promotion-to-Final.xml +++ b/static/bitcoin-dev/March_2016/combined_BIP-2-promotion-to-Final.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 2 promotion to Final - 2025-09-26T15:41:55.878177+00:00 + 2025-10-11T21:53:11.943627+00:00 python-feedgen David A. Harding 2016-03-18 22:52:55+00:00 @@ -65,10 +65,11 @@ + 2 Combined summary - BIP 2 promotion to Final - 2025-09-26T15:41:55.878354+00:00 + 2025-10-11T21:53:11.943819+00:00 2016-03-18T22:52:55+00:00 Dave suggests that the BIP authors should be allowed to decide for themselves which wiki is better instead of arguing. He proposes using Draft-BIP2's provision for authors to specify their own backup wiki as policy in all cases, eliminating the need for a backup wiki altogether. This would allow for greater flexibility and autonomy among authors.In a discussion between Btc Drak and Luke Dashjr about the use of external sources for BIP comments, Luke argues that BIP comments are not part of the BIP itself and can be kept external. Btc Drak objects to using external sources and suggests using the Wiki feature at bitcoin/bips. Luke clarifies that stronger moderation was needed, which is why the BIP process was moved to GitHub. However, he believes that such moderation is unnecessary for BIP comments. The discussion ends without reaching a resolution.Luke suggests that BIP comments should not be linked to external sources like the Bitcoin Wiki but rather made using the Wiki feature at bitcoin/bips itself. External sources are bound to go stale over time. The forum for comments should have a low barrier of use, and the Bitcoin Wiki requires only a request for editing privileges unlike GitHub wiki that would require reading and agreeing to a lengthy Terms of Service contract. The Bitcoin Wiki has been shown to stand the test of time and is less likely to move than the GitHub repository. The BIP process originated on the Wiki and was only moved to GitHub because stronger moderation was needed. Such moderation is unnecessary for BIP Comments. It is suggested that non-reference implementation lists/links be moved to BIP Comments rather than constantly revising the BIPs with them.Mustafa Al-Bassam raises concerns about the adoption of hard-fork BIP by the entire Bitcoin economy. He points out that even if a small minority refuses to accept a hard fork, it can veto the entire process. Another member clarifies that the hardfork can still happen, but for it to move to the final state, deployment needs to be universal. The discussion highlights the importance of unanimous agreement in the Bitcoin ecosystem for hard forks to be successful.In a conversation between Luke Dashjr and Mustafa Al-Bassam, they discuss the wording of a soft-fork that does not become final as long as a hard-fork has potentially-majority support or at most three months. Mustafa raises concerns about the requirement for adoption from the entire Bitcoin economy for a hard-fork BIP. He questions what would happen if one shop owner out of thousands did not adapt to the hard-fork. Luke clarifies that one shop cannot operate in a vacuum and they will soon find themselves no longer selling in exchange for bitcoin payments. The discussion concludes that any hard fork BIPs are unlikely to reach final status.Jorge Timón raises concerns about an attacker preventing a BIP from reaching final status. Mustafa Al-Bassam proposes a definition for when a hard fork becomes active, but Timón points out that an attacker could easily prevent a BIP from becoming final with little time or effort. While there may not be an obvious incentive for such an attack, Timón argues that some people might do it purely for the enjoyment of causing trouble. He suggests that any hard fork BIPs are unlikely to reach final status.Luke Dashjr opens a pull request to move BIP 2 to final status. The current requirement is that "the reference implementation is complete and accepted by the community". Luke intends to apply BIP 2's more specific criteria to itself, which requires rough consensus on the mailing list and addressing all objections. If there are no outstanding objections by April 9th, 2016, the draft BIP will be considered to have reached rough consensus and updated to Final Status. diff --git a/static/bitcoin-dev/March_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml b/static/bitcoin-dev/March_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml index 7c60f2ac32..6d60125b8e 100644 --- a/static/bitcoin-dev/March_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml +++ b/static/bitcoin-dev/March_2016/combined_BIP-Process-Status-comments-and-copyright-licenses.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Process: Status, comments, and copyright licenses - 2025-09-26T15:41:49.536647+00:00 + 2025-10-11T21:53:05.560179+00:00 python-feedgen Mustafa Al-Bassam 2016-03-10 00:37:46+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - BIP Process: Status, comments, and copyright licenses - 2025-09-26T15:41:49.536822+00:00 + 2025-10-11T21:53:05.560387+00:00 2016-03-10T00:37:46+00:00 The Bitcoin Improvement Proposals (BIPs) are currently overseen by the mailing list, which could lead to centralized control. A proposal has been made to replace the mailing list with a "public discussion medium" such as forums or conferences. Luke Dashjr has created a draft BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concern about too much control being given to those who control the mailing list and wiki.Luke Dashjr suggested keeping reviews on the mailing list while using author-chosen forums in addition to the Bitcoin Wiki. Ryan Grant questioned the process for changing the status of a BIP from Draft to Active when rough consensus is reached on the mailing list. Luke explained that the wiki page is for leaving comments after discussion is over, and all review should remain on the mailing list. He also suggested that any forum used for review should have indisputable records of moderation and user edits.Luke Dashjr has made changes to BIP 2 to reduce hard feelings during comments. He proposed that a BIP author gather new/edited comment titles and report them once a week. Mediawiki offers watchlists for this purpose, and the wiki as a whole should be verifiable.A draft BIP by Luke Dashjr provides clarification on the Status field, expands allowable licenses, and adds public comments. Feedback on the draft is welcome. BIP99 aims to establish safe deployment requirements for an uncontroversial hardfork, but the concept of "adoption consensus" needs a neutral term. Suggestions are sought to make this clearer.Dave Scotese suggested that rules and code define Bitcoin, but consensus is needed after release. Gavin Andresen expressed concern about the definition of "consensus" giving too much control to the mailing list and wiki. Suggestions to make the meaning of "consensus" clear are welcomed.Jorge Timón suggested finding another term for "consensus" in the BIP document to avoid confusion. Luke-Jr agreed and proposed using "concord rules/code" instead of "consensus rules/code".Gavin Andresen expressed concern about the definition of "consensus" in the BIP process, giving too much control to the mailing list and wiki. He added a statement clarifying that the criteria for updating the status of BIPs should not be used to oppose or reject a BIP.The overuse of the term "consensus" in various contexts has caused confusion. Suggestions for alternative terms are welcomed. Luke-Jr suggested replacing it with "nearly universal acceptance" or "ecosystem-harmonious".Luke Dashjr and Dave Scotese discussed the need for coordination among multiple applications providing their own implementations of API/RPC and corresponding BIPs. They agreed that only one application would be standard to avoid confusion. The status of a BIP and comments should be unrelated metrics. The author of a BIP should be allowed to specify other internet locations for comments, but this could potentially be abused.Luke Dashjr proposed a draft BIP that provides clarity on the Status field, expands allowable licenses, and introduces public comments. Gavin Andresen expressed concerns about the definition of "consensus" giving too much control to the mailing list and wiki.Dave Scotese addressed the question of multiple applications providing their own implementations of API/RPC and corresponding BIPs. He stated that only one such application should be standard to avoid confusion. The status of a BIP and comments should not influence each other. The author of a BIP should be allowed to specify other internet locations for comments, although this could be potentially abused.Luke Dashjr requested objections to reach consensus on formally defining consensus. Clear reasoning must be given for objections not deemed substantiated by the community. Comments on BIPs should be solicited on the bitcoin-dev mailing list and summarized fairly in the wiki. Wiki registration and monitoring should not be a required hurdle to participation.Luke Dashjr completed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. Comments and status are unrelated metrics. The author of a BIP can specify other internet locations for comments.Luke Dashjr proposed an initial draft of a BIP that clarifies the Status field, adds public comments, and expands allowable licenses. Gavin Andresen expressed concerns about the definition of "consensus" giving too much centralized control.Dave Scotese stated that multiple applications providing their own implementations of API/RPC and corresponding BIPs would not be beneficial. The status of a BIP and comments should not directly influence each other. The author of a BIP should be allowed to specify other internet locations for comments. Clear reasoning must be offered for objections not deemed substantiated by the community.Luke Dashjr requested objections for consensus on formally defining consensus. Comments on BIPs should be solicited on diff --git a/static/bitcoin-dev/March_2016/combined_BIP147-minor-error.xml b/static/bitcoin-dev/March_2016/combined_BIP147-minor-error.xml index e6e33da977..95720347f4 100644 --- a/static/bitcoin-dev/March_2016/combined_BIP147-minor-error.xml +++ b/static/bitcoin-dev/March_2016/combined_BIP147-minor-error.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP147 minor error - 2025-09-26T15:41:51.650963+00:00 + 2025-10-11T21:53:07.697064+00:00 python-feedgen Sergio Demian Lerner 2016-03-22 10:39:51+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - BIP147 minor error - 2025-09-26T15:41:51.651096+00:00 + 2025-10-11T21:53:07.697204+00:00 2016-03-22T10:39:51+00:00 On March 21, 2016, Sergio Demian Lerner reported a minor error in BIP147 to the bitcoin-dev mailing list. The BIP147 defines the cost of a sigop in traditional script as 4 and the cost of a sigop in a witness program as 1. The new rule states that the total sigop cost should be no more than 80,000. However, the code implements the rule differently, using the condition (nSigOps + (nWitSigOps + 3)/4 > MAX_BLOCK_SIGOPS) to determine if there is an error. This implementation does not align with what was defined in the BIP147.To demonstrate the error in the implemented code, Lerner provided an example. He stated that nSigOps = 1 and nWitSigOps = 79999, which does not violate the BIP147 definition but does cause an error in the implemented code. This discrepancy between the BIP definition and the code's implementation can lead to confusion and potential issues in the Bitcoin network.Lerner highlighted this error in a post to the bitcoin-dev mailing list, drawing attention to the need for the code to accurately reflect the rules defined in BIP147. By addressing this issue and ensuring consistency between the BIP and the code, developers can prevent such errors and maintain the integrity of the Bitcoin protocol. diff --git a/static/bitcoin-dev/March_2016/combined_BIP75-Out-of-Band-Address-Exchange.xml b/static/bitcoin-dev/March_2016/combined_BIP75-Out-of-Band-Address-Exchange.xml index 0680feff91..49767f0e18 100644 --- a/static/bitcoin-dev/March_2016/combined_BIP75-Out-of-Band-Address-Exchange.xml +++ b/static/bitcoin-dev/March_2016/combined_BIP75-Out-of-Band-Address-Exchange.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP75 - Out of Band Address Exchange - 2025-09-26T15:42:02.218015+00:00 + 2025-10-11T21:53:18.316855+00:00 python-feedgen James MacWhyte 2016-03-17 01:23:09+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - BIP75 - Out of Band Address Exchange - 2025-09-26T15:42:02.218193+00:00 + 2025-10-11T21:53:18.317002+00:00 2016-03-17T01:23:09+00:00 On March 1, a new Bitcoin Improvement Proposal (BIP) was proposed, tentatively assigned number 75 and titled "Out of Band Address Exchange using Payment Protocol Encryption". The proposal suggests adding optional fields to the BIP70 paymentDetails message. These fields include subtractable fee, fee per kb, and replace by fee. James MacWhyte believes that these extensions should be included in the new BIP as a general modernization of BIP70. However, Andreas Schildbach disagrees and argues that these extensions should go to separate BIPs since they are unrelated to secure and authenticated bi-directional BIP70 communication.Justin Newton is open to either leaving the extensions in or creating a separate BIP. In response to the fee part of BIP75, Schildbach proposes declaring an absolute amount that the payee is willing to cover instead of letting the payee define a fee rate. He suggests deducting the amount from the BIP70 payment message and displaying only the exceeding amount if it exceeds existing fee policies to avoid disputes. The discussion continues on the bitcoin-dev mailing list.There is a general issue with the Bitcoin Improvement Proposal process regarding multiple orthogonal "sub-BIPs". For example, BIP32 faces this issue where HD wallets implement the derivation part but not the hierarchy part. While splitting BIP32 into two BIPs without content changes was declined, there is no harm in using a BIP for a small thing, and BIP numbers are infinite. James MacWhyte's proposal for BIP75 has been tentatively assigned number 75 and changed the title to be more accurate. Some optional fields have been added to the BIP70 paymentDetails message, including subtractable fee, fee per kb, and replace by fee. These extensions clarify the fee and are not related to secure and authenticated bi-directional BIP70 communication. Andreas Schildbach believes that these extensions should go to separate BIPs to avoid polluting the original idea of BIP75. James MacWhyte, on the other hand, sees BIP75 as a general modernization of BIP70 and believes it is acceptable to include these extensions in the new BIP.In summary, a new version of BIP has been proposed, tentatively assigned number 75, and titled "Out of Band Address Exchange using Payment Protocol Encryption". The proposal suggests adding optional fields to the paymentDetails message, including subtractable fee, fee per kb, and replace by fee. There are differing opinions on whether these extensions should be included in the new BIP or placed in separate BIPs. The Bitcoin Improvement Proposal process has encountered issues with multiple sub-BIPs, and there are ongoing discussions regarding the best approach for BIP75. diff --git a/static/bitcoin-dev/March_2016/combined_Bitcoin-Guarantees-Strong-not-Eventual-Consistency-.xml b/static/bitcoin-dev/March_2016/combined_Bitcoin-Guarantees-Strong-not-Eventual-Consistency-.xml index eb49cf53eb..43cd3167eb 100644 --- a/static/bitcoin-dev/March_2016/combined_Bitcoin-Guarantees-Strong-not-Eventual-Consistency-.xml +++ b/static/bitcoin-dev/March_2016/combined_Bitcoin-Guarantees-Strong-not-Eventual-Consistency-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Bitcoin Guarantees Strong, not Eventual, Consistency. - 2025-09-26T15:41:57.993400+00:00 + 2025-10-11T21:53:14.072444+00:00 python-feedgen Emin Gün Sirer 2016-03-02 16:56:28+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Bitcoin Guarantees Strong, not Eventual, Consistency. - 2025-09-26T15:41:57.993582+00:00 + 2025-10-11T21:53:14.072658+00:00 2016-03-02T16:56:28+00:00 The concept of eventual consistency is commonly used in distributed computing to ensure high availability in systems. It guarantees that all accesses to a specific data item will eventually return its last updated value if no new updates are made. However, this does not require a system to have a final state as most practical database systems operate continuously without one.Regarding Bitcoin, the reference client's listreceivedbyaddress function returns the number of confirmations by default, and getbalance and getreceivedbyaddress functions take a number of confirmations as an argument. This is done to protect the application from suffix reorgs, where a block is removed from the blockchain due to a fork. In practice, there may be a difference between 0 probability and epsilon probability, but it is negligible due to hardware errors. Therefore, an omega can be selected such that the chance of processor mis-execution is higher than observing a reorganization.Contrary to popular belief, Bitcoin does not provide eventual consistency. The author of a post on the Bitcoin-dev mailing list argues that Bitcoin actually guarantees strong consistency. Eventually consistent systems do not have a final state and may give inconsistent responses to queries over time. However, Bitcoin does not ignore the contents of the last X blocks, and a Bitcoin node queried about the current blockchain state will give inconsistent answers when there are block rearrangements. This inconsistency indicates that Bitcoin does not provide strong consistency.Furthermore, Bitcoin provides a probabilistic, accumulative probability rather than a perfect one. This probability drops exponentially but is never exactly 0. This is similar to hash collisions, which Bitcoin relies on for its correctness.The author of the post hopes to dispel the false perception that Bitcoin is eventually consistent and believes that this idea has become a bad meme that should be laid to rest. Bitcoin actually guarantees strong consistency and operates differently from systems that provide eventual consistency. diff --git a/static/bitcoin-dev/March_2016/combined_Hardfork-to-fix-difficulty-drop-algorithm.xml b/static/bitcoin-dev/March_2016/combined_Hardfork-to-fix-difficulty-drop-algorithm.xml index b85d870dbd..f447f8fda6 100644 --- a/static/bitcoin-dev/March_2016/combined_Hardfork-to-fix-difficulty-drop-algorithm.xml +++ b/static/bitcoin-dev/March_2016/combined_Hardfork-to-fix-difficulty-drop-algorithm.xml @@ -2,7 +2,7 @@ 2 Combined summary - Hardfork to fix difficulty drop algorithm - 2025-09-26T15:41:47.421096+00:00 + 2025-10-11T21:53:03.436833+00:00 python-feedgen Dave Hudson 2016-03-09 23:24:15+00:00 @@ -129,10 +129,11 @@ + 2 Combined summary - Hardfork to fix difficulty drop algorithm - 2025-09-26T15:41:47.421263+00:00 + 2025-10-11T21:53:03.437027+00:00 2016-03-09T23:24:15+00:00 In an email exchange between Bob McElrath and Dave Hudson, they discuss the challenges of accurately measuring the hashrate in Bitcoin. Hudson suggests a damping-based design for measurement, but McElrath expresses doubts about its accuracy over short timeframes. Additionally, the consensus data lacks a strong notion of time, making it difficult to calculate difficulty based on anything outside of the consensus.Henning Kopp expresses his thoughts on the community's process for making decisions regarding Bitcoin. He believes that the community should demonstrate a good process for making such decisions and show that they can separate meaningful underlying principles from implementation details. Another individual disagrees with Kopp's statement that the coin limit was a meaningful underlying principle while mining reward halving was an implementation detail. They provide a link to a post by Dr. Back, who had been pointing this out for some time.Bitcoin miners have invested heavily in the industry with hash rates increasing by almost 70% in the last six to seven months. However, there are several ways in which this information could be irrelevant; some miners may expect to breakeven before the halving, while others may believe that the halving will not pose any problems. In addition, many miners anticipate that the price of bitcoin will increase around the time of the halving, though others believe it could just as easily decrease. The fact that these same miners were mining when the coin price was $250 last year indicates that profitability won't be a significant concern if the price remains around $400.The problem of working out a timeframe over which to run the derivative calculations is not an easy one. From a measurement theory perspective, this can be done by treating each block as a measurement and performing error propagation to derive an error on the derivatives. Bitcoin's block timing follows the statistical theory of Poisson Point Process, and there is a lot of literature available on how to handle this.The difficulty retargeting in cryptocurrencies is a matter of concern. A damping-based design is an obvious choice for this, but the problem is working out a timeframe over which to run the derivative calculations. The measurement of hashrate is pretty inaccurate, and even 2016 events aren't enough to predict difficulty swings accurately. To react meaningfully to a significant loss of hashing, a window of around two weeks is necessary.Bitcoin developers are discussing the upcoming subsidy halving this July and the potential for a significant drop in mining rate, which could lead to longer block intervals and the block size limit being hit sooner than expected. They propose a hardfork to the difficulty adjustment algorithm so it can adapt quicker to such a drop in mining rate. Some suggest adjusting the economic parameter instead of the difficulty targeting mechanism. It is important to demonstrate a good process for making decisions and separating meaningful underlying principles from implementation details.Luke Dashjr suggests an adjustment to the reward schedule to alleviate concerns about the upcoming subsidy halving. He suggests that instead of a large supply shock every four years, the reward could drop yearly or at each difficulty adjustment in a way that smooths out the inflation curve. He believes this could increase confidence in the system if the community demonstrates a good decision-making process.The success of Bitcoin has led to discussions about hard forks and the possibility of creating a new Bitcoin. The creation of a new Bitcoin would benefit from the brand awareness of Bitcoin and would not require consensus if the market values it more than the original Bitcoin. However, a hard fork is still considered contentious, and a soft fork is preferable. It is also possible to create an altcoin with a different coin limit and a smooth inflation schedule instead of abrupt drops.In a discussion among Bitcoin developers, Gregory Maxwell questions the proposal of a large difficulty drop in the Bitcoin network, stating that it would only make sense if there was evidence suggesting a significant decrease in hashrate. Paul suggests that miners should invest in hardware closer to the halving, rather than making investments too soon. He notes that assuming miners are already located in low-power-cost areas, the difficulty will quickly rise to compensate for improvements in power efficiency, which could result in the cancellation of any benefits by July.Drak has tested code for an altcoin that could potentially address the issue of the block size limit being reached earlier than anticipated. However, it is unclear which altcoin he is referring to. Luke Dashjr argues that historically, difficulty has followed value rather than being influenced by factors such as a longer block interval and higher per-block transaction volume. Nonetheless, having prepared code for negative scenarios in case of an emergency seems reasonable. The development of a local fee market and an increase in fees could attract more miners back to the network, along with an expected higher exchange rate. Pavel Janik suggests that if the blockchain network experiences a longer block interval, it could result in a higher per-block transaction volume, potentially reaching the block size limit sooner. However, if the coin's exchange rate can accommodate this expectation, a local fee market would develop, leading to increased fees and diff --git a/static/bitcoin-dev/March_2016/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml b/static/bitcoin-dev/March_2016/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml index 3555341f16..303d01ef6d 100644 --- a/static/bitcoin-dev/March_2016/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml +++ b/static/bitcoin-dev/March_2016/combined_Open-Bitcoin-Privacy-Protect-Privacy-Questionnaire-Mid-Year-2015-report.xml @@ -2,7 +2,7 @@ 2 Combined summary - Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report - 2025-09-26T15:41:38.967137+00:00 + 2025-10-11T21:52:54.939627+00:00 python-feedgen Gregory Maxwell 2016-03-01 00:57:58+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report - 2025-09-26T15:41:38.967270+00:00 + 2025-10-11T21:52:54.939781+00:00 2016-03-01T00:57:58+00:00 In the Bitcoin-dev mailing list conversation, Wei initiates a discussion on the privacy features of the Bitcoin-Qt wallet application. Kristov Atlas responds with his best guesses, highlighting key aspects of the application's privacy features.Bitcoin-Qt implements cryptographic randomization of transaction ordering, which provides maximum privacy. However, the BIP 69 recommendation could also offer the same level of privacy if universally used. The joinmarket module can be used with Bitcoin-Qt to incorporate coinjoins. Currently, there are no decentralized mixing tools available that do not harm user privacy.The article mentions that Bitcoin-Qt does not implement anti-features like donations and always maintains the highest possible FP rate. To obtain balance information, the software makes remote queries, but users can direct these queries to use Tor for all communications. All network connections are independent via Tor by default, ensuring privacy. Separate wallets are required for separate "identities".One concern raised is that an attacker could deduce that transactions come from the same client by observing transactions signed by private keys from multiple wallets. However, changing the wallet ensures that the node no longer knows any of them.The article emphasizes that reliable deletion of private data is not feasible on current hardware/OSes. Therefore, users are advised to use OS-level encryption for local privacy protection. Backups are stored locally, and there is no linkage to email or SMS.Bitcoin-Qt does not perform any external lookup related to identifying transaction senders or recipients. It connects to known p2p full nodes to bootstrap the connection to the Bitcoin p2p network. Users are recommended to run Tor to prevent identifiable traffic, except for timing/volume analysis.The application allows users to encrypt the wallet file with a password, preventing decryption of private keys without the password. Each wallet file can have its own single password for spending protection, and there is no custodianship involved. The article notes that no obvious telemetry data is being sent.Regarding the source code and building process, the application supports a deterministic build process actively audited by multiple parties who post cryptographic signatures of their duplicated builds. This ensures that users can compile the application themselves in a manner that produces an identical binary version to the distributed one.In conclusion, the email thread provides answers to various privacy and security questions related to Bitcoin-Qt. It addresses transaction formatting, mixing, donations, balance queries, network privacy, physical access, custodianship, telemetry data, and source code and building. The Open Bitcoin Privacy Project includes Bitcoin-Qt in its survey to measure wallet privacy and requests developers to answer a set of questions about how different wallets handle these aspects. diff --git a/static/bitcoin-dev/March_2016/combined_Proposed-BIP-Maximum-block-size-consensus-rule-based-on-median-block-size-adaptive-block-size-.xml b/static/bitcoin-dev/March_2016/combined_Proposed-BIP-Maximum-block-size-consensus-rule-based-on-median-block-size-adaptive-block-size-.xml index 55677c2ef9..11b9b57903 100644 --- a/static/bitcoin-dev/March_2016/combined_Proposed-BIP-Maximum-block-size-consensus-rule-based-on-median-block-size-adaptive-block-size-.xml +++ b/static/bitcoin-dev/March_2016/combined_Proposed-BIP-Maximum-block-size-consensus-rule-based-on-median-block-size-adaptive-block-size-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposed BIP: Maximum block size consensus rule based on median block size (adaptive block size) - 2025-09-26T15:42:00.106850+00:00 + 2025-10-11T21:53:16.193794+00:00 python-feedgen Tier Nolan 2016-03-25 18:48:15+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Proposed BIP: Maximum block size consensus rule based on median block size (adaptive block size) - 2025-09-26T15:42:00.106975+00:00 + 2025-10-11T21:53:16.193933+00:00 2016-03-25T18:48:15+00:00 The email thread discusses the proposal to change the MAX_BLOCK_SIZE consensus rule in the Bitcoin network. The proposed change is based on the median block size over the last three months, allowing the maximum block size to increase or decrease based on actual network usage. The purpose of this consensus rule change is to allow the network's capacity to adjust to changes in user demand and scaling related technology advancements, while still being protected from denial of service attacks.The use of floating point calculations in consensus code is considered a bad idea, so the standard practice is to use very large integers instead. The suggestion is made to use an array of integers in the get median function, even though the block size has to be an integer. This would still allow for a rounded-up integer limit on the block size.To gain acceptance for the proposed change, it is suggested to add a second limiter to the growth rate. One idea is to make it so that the block size isn't allowed to more than double every year, similar to the 1MB limit on the lower end. The graphs provided likely underestimate the growth rate, as the current 1MB limit inherently restricts things to that size.A draft BIP (Bitcoin Improvement Proposal) has been created to formalize the proposed change to the MAX_BLOCK_SIZE consensus rule. The draft is available on GitHub and was submitted by Chris Kleeschulte. diff --git a/static/bitcoin-dev/March_2016/combined_Proposed-BIP-extension-to-BIP-0070.xml b/static/bitcoin-dev/March_2016/combined_Proposed-BIP-extension-to-BIP-0070.xml index 0d7873b59f..4ce3d37ab6 100644 --- a/static/bitcoin-dev/March_2016/combined_Proposed-BIP-extension-to-BIP-0070.xml +++ b/static/bitcoin-dev/March_2016/combined_Proposed-BIP-extension-to-BIP-0070.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposed BIP extension to BIP 0070 - 2025-09-26T15:41:41.081685+00:00 + 2025-10-11T21:52:57.062005+00:00 python-feedgen James MacWhyte 2016-03-09 01:17:11+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Proposed BIP extension to BIP 0070 - 2025-09-26T15:41:41.081848+00:00 + 2025-10-11T21:52:57.062145+00:00 2016-03-09T01:17:11+00:00 The Bitcoin Improvement Proposal (BIP) 70 Payment Protocol extension aims to create a permissioned and encrypted exchange of payment information between two parties. The extension enhances the Payment Protocol by ensuring that payment details can only be seen by the participants in the transaction. It also allows for store and forward servers to sign and serve Payment Requests, and gives the sender of funds the option of sharing their identity with the receiver.The proposed update to the Payment Protocol has three main goals. Firstly, it ensures that payment details are only visible to the participants in the transaction, enhancing privacy. Secondly, it allows for store and forward servers to enable mobile wallets to sign and serve Payment Requests, making the process more convenient. Lastly, it gives the senders of funds the option to share their identity with the receiver. This feature could be used to make bitcoin logs more human-readable or to help regulated financial entities meet regulatory requirements.The protocol is designed to be flexible, allowing developers to build different types of schemes while maintaining standard messages that can be forwarded between services if needed. The email thread also discusses the possibility of a user uploading authenticated PaymentRequests to an untrusted server, which would then encrypt and pass them on in response to InvoiceRequests.A draft BIP proposal has been made to update the Payment Protocol, with the goal of enabling two parties to exchange payment information in an encrypted manner. This update would automate wallet address communication and allow for off-blockchain transaction logs that are human-readable. The motivation behind this extension is to ensure payment details are only visible to participants, enable store and forward servers, and give senders the option of sharing their identity with the receiver.The proposed extension to BIP70 has several potential benefits. It could make bitcoin logs more human-readable, allow users to control who they release payment details to, help political campaigns meet regulatory requirements, and provide a way for regulated financial entities to meet their own regulatory requirements. The full proposal can be found on GitHub, and feedback is welcomed.In summary, the proposed update to the Payment Protocol aims to create a permissioned and encrypted exchange of payment information. It allows for automated communication of wallet addresses and enables the creation of human-readable off-blockchain transaction logs. The extension ensures that payment details are only visible to participants, allows for store and forward servers, and gives senders the option of sharing their identity with receivers. This update has the potential to make bitcoin logs more human-readable, help political campaigns comply with regulations, and provide a way for regulated financial entities to meet requirements. Justin W. Newton, Founder/CEO of Netki, Inc., has shared the full proposal on GitHub and is seeking feedback. diff --git a/static/bitcoin-dev/March_2016/combined_Proposed-release-schedule-0-13-0.xml b/static/bitcoin-dev/March_2016/combined_Proposed-release-schedule-0-13-0.xml index f18369e2b2..b74b7458c0 100644 --- a/static/bitcoin-dev/March_2016/combined_Proposed-release-schedule-0-13-0.xml +++ b/static/bitcoin-dev/March_2016/combined_Proposed-release-schedule-0-13-0.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposed release schedule 0.13.0 - 2025-09-26T15:41:34.741839+00:00 + 2025-10-11T21:52:50.694753+00:00 python-feedgen Wladimir J. van der Laan 2016-03-16 11:42:02+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Proposed release schedule 0.13.0 - 2025-09-26T15:41:34.741997+00:00 + 2025-10-11T21:52:50.694910+00:00 2016-03-16T11:42:02+00:00 In an email dated March 14, 2016, Wladimir J. van der Laan presented a release schedule for version 0.13.0 of Bitcoin. However, there was a mistake in the listing of the release dates, as they were mentioned as May 1 and May 15, 2015 instead of 2016. To track the progress of this project more actively, one can refer to the Bitcoin GitHub page, specifically the issue tracker and milestone section dedicated to version 0.13.0.The proposed release schedule for version 0.13.0 of the software entails various stages, each with its own set of deadlines and objectives. The first deadline is set for May 1st, 2015, which signifies the commencement of the translation process for the new version. During this phase, Transifex will be made available for translations; however, there will be a "soft" translation string freeze, implying that no significant changes to the strings will be allowed until the release. Additionally, translations for the previous version, 0.11, will be finalized and closed.The subsequent deadline is scheduled for May 15th, 2015, marking the feature freeze for version 0.13.0. From this point onwards, only bug fixes will be accepted until the final release. Furthermore, a complete translation string freeze will be implemented, disallowing any further modifications to the source language until the release.On June 6th, 2016, the 0.13 branch will be split off from the master branch, signaling the initiation of the Release Candidate cycle. The first RC for version 0.13.0 will be tagged and released during this phase. Additionally, merging for version 0.14 will commence on the master branch.Finally, the goal is to release the final version of 0.13.0 on July 1st, 2016. diff --git a/static/bitcoin-dev/March_2016/combined_Services-bit-for-xthin-blocks.xml b/static/bitcoin-dev/March_2016/combined_Services-bit-for-xthin-blocks.xml index 1323d97a76..5abeb5043f 100644 --- a/static/bitcoin-dev/March_2016/combined_Services-bit-for-xthin-blocks.xml +++ b/static/bitcoin-dev/March_2016/combined_Services-bit-for-xthin-blocks.xml @@ -2,7 +2,7 @@ 2 Combined summary - Services bit for xthin blocks - 2025-09-26T15:41:43.192216+00:00 + 2025-10-11T21:52:59.185114+00:00 python-feedgen Tier Nolan 2016-03-09 21:11:36+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - Services bit for xthin blocks - 2025-09-26T15:41:43.192368+00:00 + 2025-10-11T21:52:59.185271+00:00 2016-03-09T21:11:36+00:00 Andrew Stone, a member of the Bitcoin Unlimited team, expressed satisfaction with their own process for documentation and discussion of cross-implementation standards. He sees the Bitcoin Improvement Proposal (BIP) process and the bitcoin-dev mailing list as Core specific. The BIP process allows for hashlocked descriptions of specifications to be implemented against. Stone proposed a process for claiming service bits, which involves justifying the claim, providing a finalized description of the feature within three months, deploying the feature within six months, and locking the bit after six months of active use.Luke Dashjr, in response to a proposal by Bitcoin Unlimited, clarified that the BIP process was actually created by Amir Taaki, not affiliated with Core, and encouraged Bitcoin Unlimited to use it for peer review from the wider Bitcoin development community. He offered to assign BIP numbers to the current Bitcoin Unlimited Improvement Proposals (BUIPs) if they meet the necessary requirements. Dashjr requested links to each of the BUIPs and noted that discussions may occur on other forums besides the mailing list.Stone wrote to the bitcoin-dev mailing list regarding the documentation and discussion of cross-implementation standards. Dashjr replied, stating that bitcoin-dev and the BIP process are not affiliated with Core, and suggested that Bitcoin Unlimited use the BIP process for peer review. He also offered to assign BIP numbers to the current BUIPs if they meet the requirements and requested links to them.Stone proposed using bit 4 as a services bit to indicate that the Bitcoin Unlimited client is capable of communicating thin blocks. Gregory Maxwell suggested a more general proposal that allows customization of user-agent specific service bits in the user-agent string. This would provide flexibility for future development and allow other clients to recognize or follow suit. The proposal does not change peer selection, and if it did, the preferred signaling mechanism would be the one in BIP 130. Stone also mentioned his tech services and ownership of Litmocracy and Meme Racing.A BIP concerning the use of a particular services bit for the extreme thin block protocol was sent to Luke jr for discussion. Bitcoin Unlimited has its own process for documentation and discussion on an uncensored forum. Stone requested interested engineers to join their forum with ideas and criticisms. It is up to Core to decide whether they want to preserve interoperability by avoiding the use of bit 1. The BIP proposes using a service bit to communicate support for thin block communication messages, with the most appropriate location being a service bit. The preferred signaling mechanism is likely the one in BIP 130, and numbers are obtained through writing BIPs.The email thread discussed the proposal to use bit 4 as a services bit for indicating that the Bitcoin Unlimited client can communicate thin blocks. Maxwell questioned if this would change peer selection and suggested using the signaling mechanism in BIP 130 if it does not. If it does change peer selection, a BIP documenting the usage should be written. The conversation ended without further discussion.The discussion highlighted the need for a services bit to indicate a node's capability to communicate thin blocks. The proposal suggested using bit 4, as bit 3 is reserved for Segregated Witness. However, before claiming a bit, proof of usefulness and actual users is required. The NODE_GETUTXO bit, which is included in the BIPs, is not supported by Core and is only one of XT's features. Claiming one of the temporary bits 24-31 is also possible. Relevant information on NODE_GETUTXO and NODE_BLOOM can be found in their respective GitHub links. Providing a link to "thin blocks" would promote further discussion about its merits.In summary, G. Andrew Stone proposed implementing a services bit in the Bitcoin Unlimited client to indicate its capability of communicating thin blocks. Luke Dashjr clarified the BIP process's affiliation and encouraged Bitcoin Unlimited to use it for peer review. Gregory Maxwell suggested a more general proposal for user-agent specific service bits. The discussion also touched on the standard method for obtaining numbers through writing BIPs. diff --git a/static/bitcoin-dev/March_2016/combined_bitcoin-dev-Digest-Vol-10-Issue-13.xml b/static/bitcoin-dev/March_2016/combined_bitcoin-dev-Digest-Vol-10-Issue-13.xml index fc66024b49..696180f245 100644 --- a/static/bitcoin-dev/March_2016/combined_bitcoin-dev-Digest-Vol-10-Issue-13.xml +++ b/static/bitcoin-dev/March_2016/combined_bitcoin-dev-Digest-Vol-10-Issue-13.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 10, Issue 13 - 2025-09-26T15:41:53.764399+00:00 + 2025-10-11T21:53:09.820571+00:00 python-feedgen Bob McElrath 2016-03-09 06:17:50+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 10, Issue 13 - 2025-09-26T15:41:53.764582+00:00 + 2025-10-11T21:53:09.820754+00:00 2016-03-09T06:17:50+00:00 During a discussion on the Bitcoin-dev mailing list, Daniele Pinna suggested an alternative approach to implementing a proposal for real-time hash rate rebalancing. Instead of adjusting the difficulty at each new block using the current method, Pinna proposed performing a weighted average of the previous 2016 blocks to find an optimal weighting based on historical interblock timing data. The goal was to prevent oscillation between blocks, even when miners switch hardware on and off.Pinna noted that the optimal solution for this rebalancing is the critically damped oscillator. This solution would provide a zero-parameter, optimal damping solution for a varying hashrate. However, Mike Wozniak pointed out that Simplified Payment Verification (SPV) wallets must also calculate retargeting but stated that it is a simple calculation that would not affect the runtime of SPV wallets.Bob McElrath proposed a simple algorithm called the "critically damped harmonic oscillator" for hashrate rebalancing. This algorithm aims to find the first and second derivatives of the hashrate over time, resulting in a damped harmonic oscillator system with two parameters: oscillation frequency and damping factor. The maximum oscillation frequency is determined by the block rate, as any oscillation faster than that cannot be accurately measured by block times. The damping rate is set to twice the oscillation frequency for critical damping.While McElrath's solution is a numeric approximation to a differential equation, it offers an optimal damping solution for a varying hashrate without the need for additional parameters. It is also possible for weak block proposals to obtain better approximations to the hashrate.Dave Hudson suggested that instead of adopting McElrath's proposal, the community should adjust the difficulty at each new block using the current method. However, if faster relaxation in case of adversity is required, a weighted average of the previous 2016 blocks could be performed based on historical interblock timing data. This approach would allow for finding an optimal weighting to address the issue.Overall, the discussion on the Bitcoin-dev mailing list revolved around different approaches to hash rate rebalancing and difficulty adjustment. While Pinna proposed a weighted average based on historical data, McElrath suggested a critically damped harmonic oscillator algorithm. Hudson, on the other hand, advocated for sticking with the current method of difficulty adjustment but acknowledged the potential benefits of a weighted average approach in certain situations. diff --git a/static/bitcoin-dev/March_2016/combined_consensus-rule-change-for-TX-fee-safety.xml b/static/bitcoin-dev/March_2016/combined_consensus-rule-change-for-TX-fee-safety.xml index eba01f4a89..51da044eb8 100644 --- a/static/bitcoin-dev/March_2016/combined_consensus-rule-change-for-TX-fee-safety.xml +++ b/static/bitcoin-dev/March_2016/combined_consensus-rule-change-for-TX-fee-safety.xml @@ -2,7 +2,7 @@ 2 Combined summary - consensus rule change for TX fee safety - 2025-09-26T15:41:45.305302+00:00 + 2025-10-11T21:53:01.313533+00:00 python-feedgen Dave Scotese 2016-03-03 16:38:17+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - consensus rule change for TX fee safety - 2025-09-26T15:41:45.305467+00:00 + 2025-10-11T21:53:01.313721+00:00 2016-03-03T16:38:17+00:00 The bitcoin-dev mailing list discussion has raised concerns about transaction fees and the need for safety rules. Alice Wonder proposed implementing protections to prevent typo blunders in transactions, citing an example of a 15 BTC transaction fee that was likely a mistake. She suggested two possible solutions: limiting the fee to the sum of outputs or limiting the fee per byte based on the previous block's largest fee per byte. Henning Kopp agreed with implementing the rule as a safety mechanism in the client rather than through a hard fork. Jorge Timón suggested improving existing checks and implementing them at the wallet layer.Bitcoin Core already has a safety limit, called the "absurd fee" limit, which is set at 10000 times the minimum relay fee to prevent large transaction fees. This limit applies to both the wallet and the sendrawtransaction RPC call. There is also a user-configurable option, -maxtxfee, to limit fees set by the wallet, which defaults to 0.1 BTC. In Bitcoin Core 0.13, it is planned to use -maxtxfee for both the wallet and the RPC interface. Historically, large transaction fees were caused by insufficient warnings from wallet software, making it the responsibility of operators to ensure user-friendliness. However, there are legitimate use cases for paying large fees, such as convenience for miners and increased privacy.In the bitcoin-dev mailing list discussion, Alice Wonder proposed adding safety rules for transaction fees to prevent mistakes. She suggested limiting the fee based on the sum of outputs or the previous block's largest fee per byte. Some participants disagreed with implementing this as a hard fork and instead suggested implementing it as a safety mechanism in the client. Alice Wonder argued that adding protections could increase confidence in using bitcoin and prevent typo blunders. The discussion concluded without a clear consensus on how to proceed.A user in the discussion suggested limitations on transaction fees, either by not allowing them to be larger than the sum of outputs or by limiting the fee per byte based on the previous block. They disagreed with this idea, stating that such checks should be done by transaction creation clients or that nodes could choose not to accept transactions with high fees into their mempool based on policy. They also argued that these limitations should not be part of the consensus layer.Henning Kopp proposed implementing a safety mechanism in the client to warn users if certain conditions are met, rather than doing a hard fork. Peter Todd pointed out that Bitcoin Core already has a safety limit called the "absurd fee" limit, which is set at 10000 times the minimum relay fee. This limit applies to both the wallet and the sendrawtransaction RPC call. The wallet also has a user-configurable option, -maxtxfee, to limit fees set by the wallet, currently defaulting to 0.1 BTC.Alice Wonder suggested implementing a safety rule for transaction fees in the next hard fork on the bitcoin-dev mailing list. She mentioned an incident where a user paid a 15 BTC fee due to a probable typo or client bug. Two proposed solutions were limiting the fee to the sum of outputs or limiting the fee per byte based on the previous block. Alice argued that adding protections could increase user confidence, using the four-byte checksum in public addresses as an example. Henning Kopp suggested implementing the safety mechanism in the client rather than through a hard fork, with a warning pop-up for conditions A) or B) being met.A recent Bitcoin transaction with an unusually high fee has sparked discussions about the need for safety rules regarding transaction fees during hard forks. The transaction in question involved a 15 BTC fee, equivalent to approximately $130,000. Experts have suggested that implementing safety rules for transaction fees could prevent similar incidents in the future. The issue has reignited debates about the scalability of Bitcoin and its adoption, with concerns raised about high transaction fees hindering wider usage. However, some argue that this incident is isolated and not indicative of broader issues in the cryptocurrency ecosystem. The incident serves as a reminder of the challenges facing the industry as it continues to grow and mature. Concrete action to address transaction fees during hard forks remains uncertain. diff --git a/static/bitcoin-dev/March_2016/combined_p2p-authentication-and-encryption-BIPs.xml b/static/bitcoin-dev/March_2016/combined_p2p-authentication-and-encryption-BIPs.xml index aa7a6ca230..7635144506 100644 --- a/static/bitcoin-dev/March_2016/combined_p2p-authentication-and-encryption-BIPs.xml +++ b/static/bitcoin-dev/March_2016/combined_p2p-authentication-and-encryption-BIPs.xml @@ -2,7 +2,7 @@ 2 Combined summary - p2p authentication and encryption BIPs - 2025-09-26T15:41:36.854324+00:00 + 2025-10-11T21:52:52.816845+00:00 python-feedgen Jonas Schnelli 2016-05-25 09:36:24+00:00 @@ -97,10 +97,11 @@ + 2 Combined summary - p2p authentication and encryption BIPs - 2025-09-26T15:41:36.854498+00:00 + 2025-10-11T21:52:52.817023+00:00 2016-05-25T09:36:24+00:00 The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, diff --git a/static/bitcoin-dev/March_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml b/static/bitcoin-dev/March_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml index b5efc53d07..bc469fcd99 100644 --- a/static/bitcoin-dev/March_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml +++ b/static/bitcoin-dev/March_2017/combined_Hard-fork-proposal-from-last-week-s-meeting.xml @@ -2,7 +2,7 @@ 2 Combined summary - Hard fork proposal from last week's meeting - 2025-09-26T15:36:46.166694+00:00 + 2025-10-11T21:47:19.056428+00:00 python-feedgen Staf Verhaegen 2017-04-02 19:12:06+00:00 @@ -329,10 +329,11 @@ + 2 Combined summary - Hard fork proposal from last week's meeting - 2025-09-26T15:36:46.166915+00:00 + 2025-10-11T21:47:19.056671+00:00 2017-04-02T19:12:06+00:00 The Bitcoin community has been engaged in ongoing discussions about the scalability of Bitcoin and the balance between on-chain scaling and layer two scaling. Some members argue that on-chain bandwidth should be available for layer two scaling to thrive and propose exploring sharding solutions. However, others emphasize the importance of individuals running full nodes on personal computers for security and challenge this assertion.The scalability of processing transactions in a distributed system like Bitcoin is a significant challenge. While network speeds have improved, there is still a debate about raising the block size limit. Some participants believe it is possible but risky, while others suggest waiting until SegWit activates before considering any additional increases.Running full nodes on personal computers is seen as crucial for the security of Bitcoin. There are discussions about the feasibility of running nodes and potential alternatives such as lightweight clients, zero-knowledge proofs, and hardware wallets. Maintaining the security of the Bitcoin network is highly dependent on personal computers.The importance of low node costs and the consequences of high transaction fees are also discussed. Some argue that a true fee-market is needed, where miners can choose to make blocks smaller to increase fees. However, increasing transaction fees may allow other cryptocurrencies to gain market share for low-value use cases. The market will continue to innovate solutions when there is profit to be made.The ongoing debate over block size increases involves different factions with differing opinions. It is crucial to carefully consider the impact on node costs and the potential burden on archival nodes. Before making any changes to the block size, implementing fixes and conducting studies are important steps.Overall, the Bitcoin community is actively discussing the scalability of Bitcoin, the importance of individuals running full nodes on personal computers for security, and the ongoing debate over on-chain scaling versus layer two scaling. The cost implications of running a node capable of handling massive transaction volumes are also being considered. In order to address these challenges and ensure the growth and security of Bitcoin, the community is exploring various solutions and technologies. diff --git a/static/bitcoin-dev/March_2017/combined_Requirement-for-pseudonymous-BIP-submissions.xml b/static/bitcoin-dev/March_2017/combined_Requirement-for-pseudonymous-BIP-submissions.xml index 19a361d2c5..c43a26eeeb 100644 --- a/static/bitcoin-dev/March_2017/combined_Requirement-for-pseudonymous-BIP-submissions.xml +++ b/static/bitcoin-dev/March_2017/combined_Requirement-for-pseudonymous-BIP-submissions.xml @@ -2,7 +2,7 @@ 2 Combined summary - Requirement for pseudonymous BIP submissions - 2025-09-26T15:36:56.703960+00:00 + 2025-10-11T21:47:23.309037+00:00 python-feedgen Tom Zander 2017-03-29 08:49:38+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - Requirement for pseudonymous BIP submissions - 2025-09-26T15:36:56.704137+00:00 + 2025-10-11T21:47:23.309206+00:00 2017-03-29T08:49:38+00:00 The ongoing Bitcoin scaling debate has become politicized, with one side advocating for increasing block size via segwit and the other through a hard fork. Companies are hesitant to take sides due to potential backlash. Pseudonymous submissions are suggested to be carried by a well-known member of the Bitcoin community to ensure credibility. Bips are seen politically based on their usefulness to each side rather than who suggests them. Protocol changes cannot be made until after a protocol upgrade has been implemented.In an email thread, Chris Stewart proposed a method that would allow individuals to reveal themselves after the BIP has been accepted. While this process cannot be forced upon people, it may become a de facto requirement by the BIP maintainer. The conversation then turns to making decisions based on merit versus financial gain. The author suggests that decisions within the project are based on return on investment (ROI), rather than merit. In fact, if killing the project or running all competing miners out of business is more profitable, many actors involved are obligated to attempt to do so. The author suggests that if merit were important, there should be a way to finance development that provides real financial incentives for merit. Additionally, the author believes that demurrage and increasing the money supply have more merit, but they are not profitable to existing Bitcoin investors, thus making them less discussed.The conversation on the Bitcoin-dev mailing list started with a discussion about the inconvenience of creating new email and GitHub accounts to submit BIPs. It was pointed out that GitHub doesn't allow multiple accounts. This led to a suggestion from Luke Dashjr for a decentralized version control system that would let users propose BIPs anonymously and get paid in crypto for the best commits. The proposed system would be developed using Mercurial, BitTorrent, and pynode by motivated grad students who know Python. A crowdfunding effort was suggested to support the development of this system.Anonymity is emphasized in the cryptocurrency community, with concerns raised about being a "recognizable target" discouraging contributions. BitFury's CEO is criticized for threatening to sue developers, with the argument that decisions should be made on merit alone. Privacy concerns are also discussed, with suggestions for creating a safe space for merit and recommendations for http://gplspace.org/.The author of the email to bitcoin-dev-request highlights the fact that GitHub does not allow multiple accounts per email address. This means that a user cannot have more than one account linked to the same email address on GitHub.To avoid the politicization of protocol-level changes and promote technical progress, Chris Stewart proposes a pseudonymous BIP system. Authors would be required to submit their proposals under a pseudonym, allowing the focus to be solely on the proposal's technical merits rather than who submitted it. The goal is to level the playing field and prevent trolls from discussing protocol changes. If desired, authors can reveal the preimage of the author hash to prove their identity after the acceptance of their BIP.Overall, the context highlights the importance of anonymity in the cryptocurrency community, the need for decisions based on merit rather than personal agendas, and proposals for improving the submission process for Bitcoin Improvement Proposals (BIPs) while maintaining privacy. diff --git a/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers-and-BIP150-.xml b/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers-and-BIP150-.xml index d7ffbd7051..8cf6562ec7 100644 --- a/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers-and-BIP150-.xml +++ b/static/bitcoin-dev/March_2017/combined_Unique-node-identifiers-and-BIP150-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Unique node identifiers (and BIP150) - 2025-09-26T15:36:50.404349+00:00 + 2025-10-11T21:47:21.185878+00:00 python-feedgen Jonas Schnelli 2017-03-08 21:31:01+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Unique node identifiers (and BIP150) - 2025-09-26T15:36:50.404538+00:00 + 2025-10-11T21:47:21.186011+00:00 2017-03-08T21:31:01+00:00 In a message exchange between Tom and an unknown sender, the sender warns Tom about the security risks associated with open wifi base stations in public areas. The sender explains that setting up an open wifi base station with a hidden ssid can lead to tracking, as phones will automatically try to connect to it by revealing their ssid. This could be particularly problematic if there is a network of these base stations.The sender goes on to mention that this same issue could potentially affect Tom's BIP (Bitcoin Improvement Proposal) as well. In the BIP, a node wants to connect using the AUTHCHALLENGE, which includes the hash of the person they are trying to connect with. Tom argues that the hash includes encryption session information, making it impossible to distinguish identities. However, the sender disagrees, stating that the hash never changes and anyone listening can see the same hash being sent on every connection to that peer, regardless of where it's connected from.Despite their disagreement, Tom asks if the sender has read the BIP, suggesting that their discussion is related to a technical document or protocol. On March 8th, 2017, Jonas Schnelli wrote a message about BIP150 on the bitcoin-dev mailing list. He explained that BIP150 has an optional authentication feature designed to not reveal any node identity without first obtaining a crypto-proof from another peer who already knows the identity. This feature is meant to be fingerprint-free. Schnelli also mentioned that peers cannot be identified without having the identity-keys pre-shared by node operators.Tom Zander, however, pointed out a vulnerability in the BIP. He compared it to the issue of having an open wifi base station in a public street, explaining that the connection process of BIP involves sending the same hash every time one connects to a node. This makes it easy to fingerprint and track a peer's activity. Zander proposed using industry standards like Diffie-Hellman key exchange as a more secure alternative.Zander's concern was primarily focused on privacy and tracking. By using the analogy of an open wifi base station, he illustrated the potential weaknesses in BIP150's authentication process. This discussion shed light on the need for improvements in BIP150's design and suggested alternative solutions to address the identified vulnerabilities. diff --git a/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader-stratum-mining-configure.xml b/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader-stratum-mining-configure.xml index 57cd3776e5..621878f1e2 100644 --- a/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader-stratum-mining-configure.xml +++ b/static/bitcoin-dev/March_2018/combined_BIP-proposal-Reserved-nversion-bits-in-blockheader-stratum-mining-configure.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure - 2025-09-26T15:33:53.316063+00:00 + 2025-10-11T21:43:42.201426+00:00 python-feedgen Luke Dashjr 2018-03-07 15:48:00+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure - 2025-09-26T15:33:53.316189+00:00 + 2025-10-11T21:43:42.201596+00:00 2018-03-07T15:48:00+00:00 On March 7, 2018, Btc Drak proposed a new Bitcoin Improvement Proposal (BIP) to reserve 16 bits of the block header nVersion field for general-purpose use and remove their meaning for version bits soft-fork signaling. The purpose of this proposal was to allow miners to utilize some of the nVersion bits for other purposes without generating false warnings about unknown soft forks. By implementing this change, the number of parallel soft-fork activations using version bits would be reduced from 29 to 13, while preventing node software from emitting false warnings. It should be noted that this proposal does not assign specific bits for specific purposes, allowing flexibility for version-rolling AsicBoost or nonce rolling to reduce CPU load on mining controllers.Luke Dashjr responded to Btc Drak's proposal by questioning the necessity of it and pointing out that similar proposals were made years ago by Timo and Sergio. He suggested that the current draft should integrate their work without attempting to take credit for it. Furthermore, Dashjr emphasized that it would be inappropriate to implement a draft BIP on the mainnet before any discussion or consensus had been reached, describing such actions as malicious.Jan Čapek criticized the reasoning behind the choice of the new method for miner configuration, arguing that defining the response type would have been a better solution than reinventing it incompatibly for no reason. This criticism was directed at the mining.configure proposal, which aimed to address issues with the existing method, mining.capabilities. The decision to adopt mining.configure was based on the expectation of a deterministic response. Additional information regarding the rationale for this new method can be found on Github.In summary, the email thread discusses two proposals related to Bitcoin mining. The first proposal involves a new miner configuration method called mining.configure, chosen for its expected deterministic response. The second proposal aims to reserve 16 bits of the block header nVersion field for general-purpose use and remove their meaning for version bits soft-fork signaling. This proposal would reduce the number of parallel soft-fork activations using version bits and prevent false warnings from node software. Luke Dashjr expressed concerns about the necessity and proper procedure of implementing these proposals, while Jan Čapek criticized the reasoning behind the choice of the new miner configuration method. diff --git a/static/bitcoin-dev/March_2019/combined_OP-CODESEPARATOR-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml b/static/bitcoin-dev/March_2019/combined_OP-CODESEPARATOR-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml index a5e1fe9e53..45cfc7b156 100644 --- a/static/bitcoin-dev/March_2019/combined_OP-CODESEPARATOR-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml +++ b/static/bitcoin-dev/March_2019/combined_OP-CODESEPARATOR-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml @@ -2,7 +2,7 @@ 2 Combined summary - OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup - 2025-09-26T15:47:32.725732+00:00 + 2025-10-11T21:57:41.929207+00:00 python-feedgen Russell O'Connor 2019-03-13 01:38:44+00:00 @@ -89,10 +89,11 @@ + 2 Combined summary - OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup - 2025-09-26T15:47:32.725923+00:00 + 2025-10-11T21:57:41.929416+00:00 2019-03-13T01:38:44+00:00 A proposal has been made to fix a vulnerability in Bitcoin using OP_CODESEPARATOR. The proposal suggests implementing a soft-fork rule that increases an input's weight based on the number of OP_CODESEPARATORs executed and the weight of the UTXO being spent, plus an additional 40 bytes. However, there are concerns that this may result in low fees and could be complex to implement.Another suggestion is to limit the maximum number of OP_CODESEPARATORs allowed per script. However, there is skepticism about this approach as it may render some transactions unspendable. It is emphasized that non-standardness should not be used as an excuse to permanently destroy people's funds.In an email exchange between Matt Corallo and Russell O'Connor, the topic of OP_CODESEPARATOR in non-BIP 143 scripts failing script validation was discussed. While OP_CODESEPARATOR is used for users to sign specific branches within scripts, it appears to have limited practical use cases. O'Connor argues that activating a soft-fork that disables OP_CODESEPARATOR would risk people's money and proposes alternative solutions such as increasing the transaction's weight or imposing a limit on the number of OP_CODESEPARATORs allowed per script.Corallo disagrees with this proposal, noting that such limits could make moderately-large transactions unspendable. He believes that OP_CODESEPARATOR in non-segwit scripts represents a significant vulnerability in Bitcoin and suggests a soft fork rule to address this.Russell O'Connor expresses concerns about disabling OP_CODESEPARATOR in non-BIP 143 scripts, stating that it is necessary for signing specific branches with multiple possible conditions reusing the same public key. Matt Corallo argues that despite efforts, there have been few practical use-cases for this feature. He suggests that OP_CODESEPARATOR in non-segwit scripts poses a vulnerability that needs to be addressed. Corallo dismisses the concern of funds being permanently lost, stating that it is not a sufficient reason to avoid fixing the vulnerability. He proposes increasing the transaction's weight upon OP_CODESEPARATOR execution or implementing a limit on the number of OP_CODESEPARATORs allowed per script.OP_CODESEPARATOR is a mechanism for users to sign specific branches within scripts. However, it fails script validation in non-BIP 143 scripts and poses a vulnerability in Bitcoin. Activating a soft-fork to disable OP_CODESEPARATOR could result in funds being permanently lost. To address this vulnerability, alternative solutions such as increasing the transaction's weight or imposing a limit on the number of OP_CODESEPARATORs executed per script have been suggested. The goal is to prevent fund loss without compromising security. diff --git a/static/bitcoin-dev/March_2019/combined_Sighash-Type-Byte-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml b/static/bitcoin-dev/March_2019/combined_Sighash-Type-Byte-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml index a245f8ee30..8ea4194886 100644 --- a/static/bitcoin-dev/March_2019/combined_Sighash-Type-Byte-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml +++ b/static/bitcoin-dev/March_2019/combined_Sighash-Type-Byte-Re-BIP-Proposal-The-Great-Consensus-Cleanup.xml @@ -2,7 +2,7 @@ 2 Combined summary - Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup - 2025-09-26T15:47:24.296431+00:00 + 2025-10-11T21:57:37.683929+00:00 python-feedgen Russell O'Connor 2019-03-13 01:34:21+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup - 2025-09-26T15:47:24.296614+00:00 + 2025-10-11T21:57:37.684105+00:00 2019-03-13T01:34:21+00:00 In an email exchange, Russell O'Connor and Matt Corallo discuss the possibility of removing certain aspects of the Bitcoin protocol through a soft-fork. O'Connor suggests classifying nSequence numbers, NOP1-NOP10, and extra sighash types as redundant and removing them. However, Corallo argues that even carve-outs for OP_NOP may not be sufficient in some cases. He believes soft forks should invalidate unused bits of the protocol, similar to OP_NOPs. While sighash bits are less likely candidates for soft-forking, Corallo sees no issue with removing them if they are redundant and not in use.O'Connor disagrees, stating that these bits are unsuitable for soft-forking within legacy Script. He argues that random bits inserted into locked-for-more-than-a-year transactions are not sufficient reason to not soft-fork them out. He points out the lack of precedent for soft-forking out working transactions unless the security of the Bitcoin protocol itself is at risk. O'Connor believes crossing this line should only happen under existential threats.Corallo suggests that the reason these bits are not seen in use on the blockchain could be because users trying to use them are caught up in the fact that they are not being relayed by default and violating SCRIPT_VERIFY_STRICTENC. He argues that making transactions non-standard and then using their lack of usage to justify a soft-fork is unacceptable.O'Connor counters with examples of users whose funds are tied up due to other changes in Bitcoin Core's default relay policy. He believes permanently destroying their funds before their transactions have a chance to get mined would be unfair. The exchange highlights the debate around whether certain aspects of the Bitcoin protocol should be removed via soft-fork and the potential consequences of doing so.The discussion also touches on default relay policies and how changes to them can affect users' ability to use certain transactions. Ultimately, there is disagreement between the two individuals on whether the potential harm caused by removing these bits outweighs the benefits of simplifying the transaction format.In addition to the debate on removing certain bits, there is a discussion on disabling unused bits within the sighash type byte. The author proposes that since these bits are not in use, they could be soft-forked out without significant impact, comparing them to OP_NOPs. However, O'Connor argues that the sighash type byte is useful for storing ancillary data during signatures. He suggests that some users may have unbroadcast transactions in cold storage with UTXOs whose private keys may have been lost, making disabling these sighashes risky. O'Connor proposes an alternative proposal of caching the just-before-the-last-byte sighash midstate instead.The sighash type byte plays a crucial role in signature evaluation during Bitcoin scripting operations. However, if this byte is anything other than specific values, script execution fails. Despite this limitation, some users have been utilizing the sighash type byte to store additional data during signatures. This usage means that there may be unbroadcast transactions in cold storage with UTXOs whose private keys are lost. While the risk of disabling these sighashes may seem low, O'Connor argues that it could put people's funds at risk. He suggests considering an alternative proposal of caching the just-before-the-last-byte sighash midstate before implementing any changes to the Bitcoin protocol. diff --git a/static/bitcoin-dev/March_2019/combined_Signet.xml b/static/bitcoin-dev/March_2019/combined_Signet.xml index 7796bdb580..df6bbfbd87 100644 --- a/static/bitcoin-dev/March_2019/combined_Signet.xml +++ b/static/bitcoin-dev/March_2019/combined_Signet.xml @@ -2,7 +2,7 @@ 2 Combined summary - Signet - 2025-09-26T15:47:30.614003+00:00 + 2025-10-11T21:57:39.806025+00:00 python-feedgen Karl-Johan Alm 2019-03-14 01:17:31+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Signet - 2025-09-26T15:47:30.614189+00:00 + 2025-10-11T21:57:39.806187+00:00 2019-03-14T01:17:31+00:00 Dear Varunram,Thank you for expressing your concerns regarding the use of a common signet controlled by a trusted entity. While using a signet would be beneficial in testing reorgs, it is important to consider the potential issues that may arise. The maintainer's unscheduled work or emergencies could impact the testing process, and people would need to run Signet1 nodes in parallel with current testnet nodes. To test Signet on a global scale, individuals can spin up nodes in various locations and use centralized services like AWS.In an email exchange between Anthony Towns and Kalle Alm, the idea of making signatures optional in headers was discussed. This would allow for "light nodes" that don't download or verify signatures. Signatures would only sign the traditional 80-byte header and wouldn't be included in the block's tx merkle root. However, this approach comes with added complexity, as signature-aware nodes would need to reject headers sent from non-signature-aware nodes. One solution proposed is to enforce including the previous block's header signature in the current block's coinbase.Matt Corallo suggested keeping the existing block header format and applying signature rules to a field in the coinbase transaction for easier testing. However, there are concerns that this approach could make DoS attacks easier. David A. Harding proposed connecting lite clients to trusted nodes on signet to protect against missing/invalid-signature DoS.The idea of moving digital signatures from Bitcoin blocks to help with scaling and reduce block size was discussed. It was suggested that users could connect their lite clients to trusted nodes on signet to protect against missing/invalid-signature DoS. Trusted signer Alice and Bob were proposed as multiple keys to sign blocks, allowing users to choose their preferred behavior.Karl-Johan Alm proposed a new network called "signet" as a centralized alternative to the existing testnet. Signet blocks are signed by a specific key instead of using proof of work, offering predictability, stability, and ease of global testing. Anyone can create a signet by creating a key pair and a challenge scriptPubKey. A default persistent "signet1" is proposed to be created, which can be replaced in future versions if necessary.In conclusion, the introduction of signet as a complement to the existing testnet provides benefits such as predictability, stability, and ease of global testing. However, it is important to address concerns regarding the potential impact of unscheduled work or emergencies on the testing process. The discussion also explored the idea of making signatures optional in headers and connecting lite clients to trusted nodes on signet. Overall, the implementation of signet would enhance the Bitcoin protocol's testing capabilities and provide a more stable and predictable environment for developers.Best regards,Kalle diff --git a/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown.xml b/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown.xml index 8a666b0693..0d40eb901a 100644 --- a/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown.xml +++ b/static/bitcoin-dev/March_2020/combined_Block-solving-slowdown.xml @@ -2,7 +2,7 @@ 2 Combined summary - Block solving slowdown - 2025-09-26T15:34:45.943906+00:00 + 2025-10-11T21:44:03.467646+00:00 python-feedgen ZmnSCPxj 2020-03-31 02:06:32+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Block solving slowdown - 2025-09-26T15:34:45.944052+00:00 + 2025-10-11T21:44:03.467788+00:00 2020-03-31T02:06:32+00:00 Miners' behavior under a new ruleset is a concern raised by the author of the message. The author argues that miners, who benefit directly from increased inflation rates and have the power to decide which transactions are added to blocks, are likely to accept attempts to delete UTXOs (Unspent Transaction Outputs) that vote for lower inflation rates and create UTXOs that vote for higher inflation rates. This would result in miners strongly controlling the inflation rate of the coin. Additionally, as inflation grants more coins to miners, they would also have more control over the value of the coin used for voting.To avoid the moral hazard of beneficiaries of higher inflation rates being the ones who determine the inflation rate, Bitcoin has a fixed inflation rate schedule.The Bitcoin system introduces a competition for limited block space, forcing users to assess how much security they are willing to pay for. This ensures that individuals pay the market rate for block space, determined by supply and demand. However, this mechanism may lead to some individuals paying less than what is required to maintain network security.Off-chain mechanisms in Bitcoin do not eliminate on-chain fees but rather distribute them across multiple logical transactions, increasing effective capacity while still maintaining on-chain fees at a level that ensures healthy blockchain operation. However, the use of Lightning nodes, one such off-chain mechanism, is not a permanent solution as they will eventually close, leading to on-chain funds being in the slow and expensive on-chain domain. Therefore, there will always be a need for a block weight limit to ensure miners can be paid.The block weight limit in Bitcoin restricts the number of transactions that can be included in a block, ensuring miners receive payment. However, each individual only has an incentive to pay the market rate for block space based on supply and demand. This creates a collective action problem, where individuals aim to pay the minimum necessary to include their transaction in a block while relying on others to cover the cost of transaction security.Although off-chain mechanisms can increase effective capacity, reducing demand for block space and transaction fees, this could lead to a decrease in miner revenue below the level required to maintain network security. Finding a solution to this problem remains an ongoing challenge. diff --git a/static/bitcoin-dev/March_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml b/static/bitcoin-dev/March_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml index 3343467ad5..d73a6ac34b 100644 --- a/static/bitcoin-dev/March_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml +++ b/static/bitcoin-dev/March_2020/combined_Nonce-blinding-protocol-for-hardware-wallets-and-airgapped-signers.xml @@ -2,7 +2,7 @@ 2 Combined summary - Nonce blinding protocol for hardware wallets and airgapped signers - 2025-09-26T15:34:35.440265+00:00 + 2025-10-11T21:44:01.343900+00:00 python-feedgen Dustin Dettmer 2020-03-02 20:01:51+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Nonce blinding protocol for hardware wallets and airgapped signers - 2025-09-26T15:34:35.440428+00:00 + 2025-10-11T21:44:01.343997+00:00 2020-03-02T20:01:51+00:00 Stepan Snigirev has proposed a protocol for signing messages using an air-gapped computer or hardware wallet in the Bitcoin development mailing list. This comes in response to the acknowledgment that these devices can be compromised through supply chain attacks or malicious firmware updates. The proposed protocol aims to reduce the attack surface by involving additional entropy from the host. The protocol requires the host to pick a random number `n` and send its hash along with the message `m` to the signer. The signer calculates a nonce `k` and sends the corresponding point `R=kG` to the host, committing to the chosen nonce. The preimage `n` is then sent to the signer, who tweaks the nonce by this number and signs the message. The signed message is sent back to the host, who verifies that the public point in the signature is tweaked by `n`.Extensions to the protocol are also suggested by Snigirev. One extension involves the use of multiple hosts, where all hosts don't trust each other and the signer. In this case, hosts can concatenate hashes and preimages to add external entropy to the nonce. Another extension involves the use of a stateless random signer. If the signer wants to generate a nonce non-deterministically but doesn't have the ability to store it, they can send back meta-information to the host that would help regenerate the same nonce later.The proposed protocol can be implemented for PSBT using key-value pairs added to BIP-174. These include keys such as {PSBT_IN_EXT_NONCE_HASH}|{pubkey} for sha256(n1)|sha256(n2)|..., {PSBT_IN_NONCE_COMMITMENT}|{pubkey} for the 33-byte R point, {PSBT_IN_NONCE_SIGNER_METADATA}|{pubkey} for any value, and {PSBT_IN_EXT_NONCE_PREIMAGE}|{pubkey} for n1|n2|....Marko expresses gratitude for the implementation of a protocol for PSBT anti-nonce covert channel and backports the scheme to ECDSA in the secp256k1 library. He suggests using the generalized sign-to-contract scheme in PSBT, where the final nonce is computed as `k' = k + H(k*G, n)` instead of `k'=k+n`. Proprietary fields or key-value pairs can be added to BIP-174 depending on the interest of others. Careful verification against the state stored by the host for the PSBT is necessary to avoid implementation mistakes and private key leakage.The writer appreciates the initiative of implementing and releasing a protocol inspired by a blog post. The protocol was implemented in the secp256k1 library for Schnorr sigs and backported to ECDSA for current transactions. Proof of concepts were made to verify its effectiveness. The generalized sign-to-contract scheme was used in these implementations, with the final nonce computed as `k' = k + H(k*G, n)`. However, caution is advised when implementing the protocol with an air-gapped signer, as wrong implementation could lead to private key leaks. Guidelines and best practices to avoid pitfalls are requested.When generating a digital signature, it is unsafe to use only the message and private key. Instead, all data from the host should be used to create a nonce. Multiple blinding factors can also be used. If completely random nonces cannot be gathered due to insufficient entropy, any available source of entropy can be mixed into the nonce generation function. Glitch attacks, where two identical messages produce different signatures due to a flipped bit in the message, can be prevented by including a monotonic counter in the nonce generation function. The Yubikey had a problem with RNG initialization that caused private key leakage, so it's recommended to avoid pure RNG-generated nonces.The compromise of hardware wallets and air-gapped computers is discussed, highlighting the risks of supply chain attacks and malicious firmware updates. The proposed protocol aims to address these concerns by involving additional entropy from the host in the signing process. It is noted that using a deterministic scheme with only the message and privkey would be unsafe in certain scenarios. To prevent targeted attacks, it's recommended to derive the nonce from the message, `sha256(n)`, and the privkey mixed together using a suitable hashing function. While completely random nonces are ideal, resource limitations may prevent their use.Stepan Snigirev proposes a protocol to prevent the compromise of hardware wallets or air-gapped computers used for signing transactions. The protocol involves the host picking a random number and sending its hash along with the message to the signer, who computes a nonce and commits to it by sending the corresponding point to the host. The preimage is then sent back to the signer, who tweaks the nonce and signs the message. The host verifies that the public point in the signature is tweaked by the same amount. If the signer wants to generate a nonce non-determin diff --git a/static/bitcoin-dev/March_2021/combined_BIP-Proposal-Consensus-hard-fork-PoST-Datastore-for-Energy-Efficient-Mining.xml b/static/bitcoin-dev/March_2021/combined_BIP-Proposal-Consensus-hard-fork-PoST-Datastore-for-Energy-Efficient-Mining.xml index 387e574c54..263850e212 100644 --- a/static/bitcoin-dev/March_2021/combined_BIP-Proposal-Consensus-hard-fork-PoST-Datastore-for-Energy-Efficient-Mining.xml +++ b/static/bitcoin-dev/March_2021/combined_BIP-Proposal-Consensus-hard-fork-PoST-Datastore-for-Energy-Efficient-Mining.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining - 2025-09-26T16:05:10.618670+00:00 + 2025-10-11T22:18:57.439911+00:00 python-feedgen Lonero Foundation 2021-03-17 07:06:32+00:00 @@ -153,10 +153,11 @@ + 2 Combined summary - BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining - 2025-09-26T16:05:10.618844+00:00 + 2025-10-11T22:18:57.440098+00:00 2021-03-17T07:06:32+00:00 In a recent email exchange on the Bitcoin-dev mailing list, there was a discussion about improving the cryptography layer for validation in Bitcoin mining. Andrew proposed a document suggesting a better cryptography algorithm that could reduce costs while maintaining security. However, Devrandom argued that the negative externalities of energy expenditure would soon be eliminated due to the adoption of renewable energy sources.The conversation also touched on the topic of proof of work (PoW) and its relation to energy consumption. Ryan Grant shared an article arguing that nothing is cheaper than proof of work, but it did not prove that energy expenditure has to be the primary cost of mining work. The paper mentioned that the mining market tends to expend resources equivalent to miner rewards, but it did not provide conclusive evidence about energy consumption as the primary cost.Andrew had also mentioned the idea of a staking hybrid, which could change the dynamics and economic forces in Bitcoin mining. However, staking was considered cryptodynamically insecure and not censorship-resistant, so it wouldn't likely be seen as a contribution to Bitcoin. Other attempts to improve energy efficiency were either disguised proof of work or repurposing computing power, neither of which would lead to a reduction in dedicated energy consumption.In another email exchange with the Lonero Foundation, Andrew proposed a cryptography proposal to improve hashing efficiency and address vulnerabilities in the BTC network. He believed that this upgrade should be discussed, considering the suggestion of bigger block height proposals as hard forks. Andrew asked about the preferred format for his proposal.Devrandom responded to another email by discussing the argument that proof of work is the cheapest method for mining. They pointed out that while the mining market tends to use resources equivalent to miner rewards, it does not necessarily mean that energy expenditure is the primary cost. Devrandom also mentioned that negative externalities from energy consumption may decrease as the move towards renewables progresses.The email thread focused on the discussion of a better cryptography layer for validation and the proposal of a document. It did not directly address the energy-efficient argument for renewables or mining devices. However, a paper was linked that suggested the mining market tends to use resources equivalent to rewards without proving energy expenditure as the primary cost. The debate revolved around the potential negative externalities of energy consumption and the potential reduction through renewable energy sources.In a separate email to the bitcoin-dev mailing list, a member of the Lonero Foundation proposed a BIP to address energy efficiency concerns in Bitcoin mining. However, another member disagreed with the proposal, citing previous discussions that rejected similar ideas. Links were provided to BIP 2, which outlines the BIP process, and a blog post advocating for the value of proof of work. The conversation shifted towards whether technically well-constructed proposals guaranteed to be rejected should be allowed in the BIP repository. It was suggested that such proposals should be unilaterally rejected as spam by the BIP Editor, but a moderation log should be maintained to ensure transparency and prevent censorship.The writer of one email sought guidance on creating a new BIP to tackle energy efficiency issues in Bitcoin mining. They were unsure about the format and whether to attach a README to their draft proposal on GitHub. Their proposed solution involved integrating a hybrid mining approach with proof of work and proof of stake for Bitcoin's SHA-256 hash algorithm. The writer, despite their background as a Quantum Engineer and Bioinformatics consultant, believed their proposal could be of interest and wanted to submit a detailed document explaining its workings. diff --git a/static/bitcoin-dev/March_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml b/static/bitcoin-dev/March_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml index 5de4774b01..72c6b76690 100644 --- a/static/bitcoin-dev/March_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml +++ b/static/bitcoin-dev/March_2021/combined_March-23rd-2021-Taproot-Activation-Meeting-Notes.xml @@ -2,7 +2,7 @@ 2 Combined summary - March 23rd 2021 Taproot Activation Meeting Notes - 2025-09-26T16:05:16.959307+00:00 + 2025-10-11T22:19:01.688138+00:00 python-feedgen Anthony Towns 2021-04-08 11:11:06+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - March 23rd 2021 Taproot Activation Meeting Notes - 2025-09-26T16:05:16.959499+00:00 + 2025-10-11T22:19:01.688317+00:00 2021-04-08T11:11:06+00:00 In recent discussions on the bitcoin-dev mailing list, the focus has been on establishing developer and user consensus for Bitcoin. One suggestion is to create a contingency plan for a chain split, which some argue is good preparation. However, others believe that this approach does not address the underlying issue of consensus. The ideal scenario would allow users to download any version of bitcoind and run it with default settings, confident in the validity of their payments. Third-party explorers can track invalid chains, but these measures are only useful after a split has occurred. The risk of a split is higher during an attack on Bitcoin. Suggestions like lockinontimeout have been made, but they are not seen as the ideal solution. Businesses accepting Bitcoin payments need to know what software to run to stay in consensus with the network. Streamlining the consensus-building process is crucial. One possible solution is to implement an approach dealing with miners who don't upgrade to enforce a soft-fork quickly.Another thread discussed the Signet-based Taproot activation proposal. Different opinions were expressed regarding whether to use a Lot=false compromise or embrace brinkmanship tooling. Some argued that de-escalation in the strategy toolkit makes Bitcoin stronger, while others disagreed and emphasized the lack of agreement on a grand plan. Downsides of using LOT=true were mentioned, including dropping blocks from apathetic miners and the risk of a split. However, tracking economic majority is already possible based on previous experiences. The disagreement continued regarding the normalization of brinkmanship, with some members highlighting the need to optimize for a reliable Bitcoin and avoid strife.Claus Ehrenberg suggested that Taproot should be activated if either miners or users decide for it, with a chain split as the fairest way to resolve conflicts. Rusty Russell proposed the Speedy Trial approach, pretending that miners were not asked, and letting users ultimately decide. Preparation for a UASF branch along with ST was also discussed.The Bitcoin development community discussed the implementation of Taproot and parameter selection for an upcoming release. They targeted a May 1st release date and discussed the use of block heights or MTP for signaling periods. The team considered the advantages and disadvantages of each approach and adjusted the timing and other parameters based on preferences and technical considerations.Jeremy Rubin accused Michael Folkson of being disingenuous in his response and disagreed with his rejection of MTP-based ST. Folkson expressed his preference for consistent use of block heights and rejected the idea of using a mix of block heights and MTP in the same activation mechanism.Overall, the discussions revolve around finding the best approach to establish consensus for Bitcoin, activate Taproot, and handle potential challenges such as chain splits and miners failing to upgrade. The community aims to optimize the decision-making process, ensure payment validity, and strengthen the Bitcoin network.During a recent meeting on the activation mechanism for Taproot, there was a discussion about using block heights consistently or a mix of block heights and MTP. Michael Folkson preferred consistent use of block heights and disagreed with using a mix. The meeting also addressed the use of a speedy trial variant, which received no new objections. However, there was uncertainty about Rusty Russell's objection and whether it remains if sufficiently addressed.There was no consensus reached on selecting between block heights and MTP. Parameter selection discussions included targeting a May 1st release, specific start and stop times, and activation height proposals. It was agreed that November 15th should remain a target date, with limited belief that the release could be stretched into June if necessary.Simultaneous User Activated Soft Fork (UASF) was also discussed, with luke-jr suggesting that a UASF client must be able to release before the Taproot client. However, this sentiment was not shared by others, and it was agreed that a UASF can proceed independently of Taproot. Additionally, luke-jr objected to using MTP in combination with Taproot, while Jeremy Rubin objected to using block heights, citing concerns about avoiding contentious forks. diff --git a/static/bitcoin-dev/March_2021/combined_Provisions-was-PSA-Taproot-loss-of-quantum-protections-.xml b/static/bitcoin-dev/March_2021/combined_Provisions-was-PSA-Taproot-loss-of-quantum-protections-.xml index 5b0ecfc6e3..8646fb6f34 100644 --- a/static/bitcoin-dev/March_2021/combined_Provisions-was-PSA-Taproot-loss-of-quantum-protections-.xml +++ b/static/bitcoin-dev/March_2021/combined_Provisions-was-PSA-Taproot-loss-of-quantum-protections-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Provisions (was: PSA: Taproot loss of quantum protections) - 2025-09-26T16:05:56.890528+00:00 + 2025-10-11T22:19:10.197770+00:00 python-feedgen Andrea Barontini 2021-03-20 16:31:19+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Provisions (was: PSA: Taproot loss of quantum protections) - 2025-09-26T16:05:56.890659+00:00 + 2025-10-11T22:19:10.197969+00:00 2021-03-20T16:31:19+00:00 In a conversation between Andrew, ZmnSCPxj, and Jonas, they discuss the use of Taproot in zero-knowledge proofs. The sender of the message has reviewed the resources provided and is unsure if Jonas' code qualifies as a use of Taproot for anonymity sets. However, they express their enjoyment in discovering new things and being part of the community.ZmnSCPxj responds to Andrew and Andrea's inquiry about Taproot ring signatures by providing links to the Bitcoin Wiki page on Taproot uses and a GitHub repository authored by Jonas on Taproot ring signatures. Although they admit to not having read the GitHub page themselves, the inclusion of these resources may be helpful for further research or understanding of Taproot and its applications.In a Bitcoin-dev mailing list, Andrea asks for references to ring signatures over/for/via Taproot and clarification on what "Provisions" means. Andrew Poelstra replies, explaining that Provisions is a scheme for proving ownership of funds by associating Bitcoin outputs with a Pedersen commitment. This allows for a zero-knowledge proof of owning a certain amount of BTC without revealing specific UTXOs. Currently, only a small anonymity set can use Provisions due to the lack of known public keys for most unspent Bitcoin outputs. However, Taproot outputs, which have exposed public keys, will be an exception, allowing for larger anonymity sets. Andrew also shares a link to simpler things that can be done with Taproot keys along these lines.Overall, this conversation provides insights into the use of Taproot in zero-knowledge proofs, the concept of Provisions for proof of ownership, and the resources available for further reading on the topic. diff --git a/static/bitcoin-dev/March_2021/combined_Signature-and-Script-Independent-Hierarchy-for-Deterministic-Wallets-.xml b/static/bitcoin-dev/March_2021/combined_Signature-and-Script-Independent-Hierarchy-for-Deterministic-Wallets-.xml index ffc74f548e..6c958baff3 100644 --- a/static/bitcoin-dev/March_2021/combined_Signature-and-Script-Independent-Hierarchy-for-Deterministic-Wallets-.xml +++ b/static/bitcoin-dev/March_2021/combined_Signature-and-Script-Independent-Hierarchy-for-Deterministic-Wallets-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Signature and Script Independent Hierarchy for Deterministic Wallets. - 2025-09-26T16:05:25.412035+00:00 + 2025-10-11T22:19:05.936330+00:00 python-feedgen Robert Spigler 2021-03-19 08:59:05+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - Signature and Script Independent Hierarchy for Deterministic Wallets. - 2025-09-26T16:05:25.412236+00:00 + 2025-10-11T22:19:05.936510+00:00 2021-03-19T08:59:05+00:00 Developer Robert Spigler has proposed a Bitcoin Improvement Proposal (BIP) for multisignature and single signature wallets. However, concerns have been raised about the impact of the proposal on single signature wallets by ghost43 and Jochen Hoenicke. As a result, Spigler has decided to revert the proposal back to multisignature derivations, which he believes will address all concerns. The updated proposal can be found on Github, along with Spigler's personal fingerprint.In a discussion on the bitcoin-dev mailing list, Robert Spigler argued that wallets shouldn't have to check all script types on recovery and proposed a new standard called "Signature and Script Independent Hierarchy for Deterministic Wallets." According to Robert, descriptor wallets can solve this problem. For multisignature wallets, each cosigner stores their extended private key (xprv) and the wallet descriptor for backup. To recover, simply combine M private keys and check the script designated in 1 of the descriptor copies. For single signature wallets, it is the same, except only one signature is needed. Jochen disagreed with Robert's proposal and pointed out that currently, BIP39/BIP44 wallets can recover all accounts using just the seed words without the need for public keys or derivation paths. Additionally, Jochen stated that most hardware wallets currently rely on this feature. However, autodiscover doesn't work for multisig wallets, unless some output descriptor is stored in an OP_RETURN on the blockchain.The proposal to encode script type in the derivation is being questioned as output descriptors are becoming more prevalent. Two options have been suggested: 1) Use derivation paths that do not encode the script type and educate users to backup output descriptors in addition to their seed words or 2) Use a standard set of derivation paths that encode the script type, ensuring fund recovery even if users do not back it up by checking against common derivations. Robert Spigler suggests using descriptor wallets for multisignature and single signature wallets. To backup a multisignature wallet, each cosigner stores their extended private key and the wallet descriptor. For single signature wallets, the same applies but only one signature is needed.The current standards for deterministic wallets have many issues, including the mixing of keys and scripts in the same layer. BIP44/49/84 specifies a path that includes per-script derivations, but these are made redundant with descriptors. The proposal is to create extended private/public keys independent of the script or signature type. In multisignature wallets, each cosigner stores their xprv and the wallet descriptor for backup. For single signature wallets, only one signature is needed. There is a tradeoff as the proposal mixes discoverable and non-discoverable scripts in the same derivation scheme, which could turn all scripts into being non-discoverable. The workaround is to backup both seed words and output script descriptors, which is less user-friendly than backing up just a seed but more generic and extendable.Robert Spigler is working on a draft BIP for a signature and script independent hierarchy for deterministic wallets. He believes that with the implementation of descriptor wallets, the typical use case of a BIP43 `purpose’` level per script type is redundant. The differentiation of separate BIPs for multisignature derivation paths is also considered redundant. Descriptors can set the order of the public keys with multi or have them sorted lexicographically with sortedmulti. Robert proposes that keys and scripts should not be mixed in the same layer. The wallet should create extended private/public keys independent of the script or signature type, whereas the descriptor language tells wallets to watch (single or multi-sig) outputs with the specified public keys. diff --git a/static/bitcoin-dev/March_2021/combined_Taproot-NACK.xml b/static/bitcoin-dev/March_2021/combined_Taproot-NACK.xml index 0bb6fb0b0b..b789e267d6 100644 --- a/static/bitcoin-dev/March_2021/combined_Taproot-NACK.xml +++ b/static/bitcoin-dev/March_2021/combined_Taproot-NACK.xml @@ -2,7 +2,7 @@ 2 Combined summary - Taproot NACK - 2025-09-26T16:05:21.174745+00:00 + 2025-10-11T22:19:03.811372+00:00 python-feedgen DA Williamson 2021-03-18 01:10:38+00:00 @@ -149,10 +149,11 @@ + 2 Combined summary - Taproot NACK - 2025-09-26T16:05:21.174928+00:00 + 2025-10-11T22:19:03.811551+00:00 2021-03-18T01:10:38+00:00 The email thread on the bitcoin-dev mailing list revolves around discussions about privacy concerns related to Bitcoin transactions and the proposed Taproot protocol change. LORD HIS EXCELLENCY JAMES HRMH expresses concerns about increased privacy and potential obfuscation of transactions, which could lead to government bans. However, other members argue that Taproot does not increase privacy beyond current techniques like coinjoin, payjoin, and lightning. The importance of maintaining transparency in the blockchain while still allowing for privacy is emphasized.The conversation also touches on the affiliation of LORD HIS EXCELLENCY JAMES HRMH with a Bitcoin mixer service, raising questions about their motivations and potential conflicts of interest. The need for proper disclosure when discussing transaction privacy is highlighted.Another member named Damian A. James Williamson, associated with Willtech, shares contact information but does not provide specific advice or information about projects. The intention behind the email is unclear.The debate centers around striking a balance between privacy and security with transparency and accountability in Bitcoin transactions. Various perspectives are shared, including the value proposition of Bitcoin, the availability of privacy suitable for cash, and the implications of obfuscating transactions on government bans.Overall, the email thread covers topics such as consensus, censorship resistance, fraud prevention, privacy techniques, and the presence of a disruptive troll on the bitcoin-dev mailing list. It provides insights into various perspectives and approaches within the Bitcoin community. diff --git a/static/bitcoin-dev/March_2021/combined_Taproot-activation-proposal-Speedy-Trial-.xml b/static/bitcoin-dev/March_2021/combined_Taproot-activation-proposal-Speedy-Trial-.xml index 7915cbb6d3..f4439f812c 100644 --- a/static/bitcoin-dev/March_2021/combined_Taproot-activation-proposal-Speedy-Trial-.xml +++ b/static/bitcoin-dev/March_2021/combined_Taproot-activation-proposal-Speedy-Trial-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Taproot activation proposal "Speedy Trial" - 2025-09-26T16:05:12.732289+00:00 + 2025-10-11T22:18:59.565161+00:00 python-feedgen Michael Folkson 2021-03-15 14:06:45+00:00 @@ -69,10 +69,11 @@ + 2 Combined summary - Taproot activation proposal "Speedy Trial" - 2025-09-26T16:05:12.732519+00:00 + 2025-10-11T22:18:59.565321+00:00 2021-03-15T14:06:45+00:00 Bitcoin developers have proposed a new activation mechanism called Speedy Trial for the Taproot upgrade. This proposal aims to quickly succeed or fail without compromising safety. Miners would signal readiness for Taproot, and if the 90% threshold is not reached within three months, the activation attempt fails. The proposed timeline includes the release of full nodes with activation code, signal tracking, lock-in, and activation.Some are concerned about the three-month window potentially leading to network splits. David Harding has proposed an activation timeline for Taproot, suggesting specific dates for release, signal tracking, lock-in, and activation. His proposal can be implemented using either BIP9 or BIP8. The timeline includes a delay between lock-in and activation, and signaling begins in April. False signaling is possible with any proposal, but it is not required in Speedy Trial.Russell O'Connor has proposed Speedy Trial as a way to ensure widespread adoption of Taproot without compromising safety. The proposal includes an extended lock-in period and does not require mandatory signaling. However, concerns exist about false signaling and unprepared miners losing money. Implementation details are still being discussed, and a patch against BIP8 may be developed if Speedy Trial gains traction.The Taproot activation discussion has been ongoing for several years, with previous proposals and discussions dating back to 2015 and 2016. The latest proposal aims to generate fast progress and provide data for future activation proposals. Developers are working on updates to Bitcoin Core's code to support the proposed activation parameters.Overall, the Speedy Trial proposal offers a way to activate Taproot quickly and safely, with options for implementation using existing code or a proposed patchset. The proposal addresses concerns about network splits and false signaling while allowing for advanced notice and preparation by users and organizations. The goal is to find a solution that achieves widespread adoption of new consensus rules while maintaining the integrity of the Bitcoin network. diff --git a/static/bitcoin-dev/March_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml b/static/bitcoin-dev/March_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml index efadcae014..72fda6606a 100644 --- a/static/bitcoin-dev/March_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml +++ b/static/bitcoin-dev/March_2021/combined_Yesterday-s-Taproot-activation-meeting-on-lockinontimeout-LOT-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Yesterday's Taproot activation meeting on lockinontimeout (LOT) - 2025-09-26T16:05:31.696131+00:00 + 2025-10-11T22:19:08.059624+00:00 python-feedgen Ariel Lorenzo-Luaces 2021-03-02 18:32:00+00:00 @@ -173,10 +173,11 @@ + 2 Combined summary - Yesterday's Taproot activation meeting on lockinontimeout (LOT) - 2025-09-26T16:05:31.696332+00:00 + 2025-10-11T22:19:08.059809+00:00 2021-03-02T18:32:00+00:00 The Bitcoin community is currently engaged in discussions about the activation of Taproot, a proposed soft-fork upgrade for the network. The activation method itself has raised concerns about the risk of chain splits and the potential impact on consensus. One suggestion to minimize this risk is to release a version of Bitcoin Core that requires users to choose between activating Taproot with LOT=true or LOT=false. However, there are debates about whether giving miners too much control over consensus could set a problematic precedent.Bitcoin Core developer Matt Corallo emphasized the long-standing policy of not including options that could harm users, explaining that the role of Bitcoin Core developers is to recommend technically sound and consensus-supported courses of action. While users are free to run their own software, he doesn't anticipate that the minority advocating for certain options on platforms like Twitter will have sufficient influence to sustain their choices if they find themselves on a chain with no blocks.The ongoing debate on the activation mechanism for Taproot includes discussions about whether to set the lock-in on timeout (LOT) parameter to true or false. Various viewpoints have been expressed, with some participants arguing for LOT=true and others suggesting LOT=false. Michael Folkson, who summarized the outcomes of a Taproot activation meeting, concluded that there was no overwhelming consensus but noted stronger opposition to LOT=true from Bitcoin Core contributors and Lightning developers. Based on this, he recommended proposing LOT=false as the activation parameter.However, the decision-making process is still ongoing, and code review of the Bitcoin Core PR #19573 is scheduled for February 23rd. While there are diverging opinions on the best course of action, the goal remains to activate Taproot as early as possible while minimizing risks and ensuring broad consensus within the Bitcoin community.It's worth noting that an activation mechanism is a consensus change that can be contentious. Therefore, it's important to engage in open discussions and prepare for different scenarios without being antagonistic or destructive. The Bitcoin community aims to find a resolution that aligns with the collective interest and avoids detrimental outcomes.The activation of Taproot has sparked debates within the Bitcoin community. Some members suggest setting LOT=false to minimize the risk, while others propose allowing users to make the choice themselves. There is disagreement on which option is safer, with arguments made for both LOT=true and LOT=false.During a recent meeting on Taproot activation, there was majority support for LOT=false over LOT=true. However, concerns were raised about the representativeness of the meeting, as only around 100 people attended. Despite this, it is recommended to propose LOT=false in order to finalize Taproot activation parameters and propose them to the community.It is emphasized that users are not forced to upgrade to any particular software version, and there is a possibility that only a small number of people will run LOT=true while others delay their upgrade. The goal is to avoid a chain split and falling out of consensus.The Bitcoin community acknowledges the importance of open discussions and preparation for worst-case scenarios in order to build secure systems. A code review of Bitcoin Core PR #19573 is scheduled, and participants are thanked for engaging productively and in good faith.Overall, the Bitcoin community is actively discussing the activation of Taproot and considering the potential risks and benefits. The debate centers around whether to set LOT to true or false, with arguments made for both options. The community aims to reach a consensus and activate Taproot in a way that minimizes risks and ensures the long-term growth and security of the ecosystem.The ongoing debate on the activation of Taproot continues, with different perspectives on the implementation and consensus rules. Software complexity and infrastructure limitations have been raised as challenges. The proposal for a LOT=true option in Bitcoin Core has faced opposition, leading to the recommendation of proposing LOT=false. Communication, agreement, and avoiding forced-signaling via forks are emphasized. Multiple forks and alternative implementations are suggested to enhance decentralization. The aim is to activate Taproot as early as possible while considering consensus and technical soundness.In the recent meeting on Taproot activation, arguments for both LOT=true and LOT=false were discussed. While there was no overwhelming consensus, there was more opposition against LOT=true among Bitcoin Core contributors, Lightning developers, and other community members. Some mining pools expressed a preference for LOT=false. It was decided to propose LOT=false at this time, considering the aim of activating the Taproot soft fork as early as possible.Matt Corallo emphasized the importance of communication and agreement in the activation process. He suggested that if there is broad consensus for Taproot but some miners fail to upgrade, a flag day activation could be considered instead of a UASF/BIP8-style fork, which carries additional risks. The tradeoffs of a BIP8(false, ∞) option were also discussed, with suggestions for maintaining multiple forks of Bitcoin Core to enhance decentralization.The practicality of implementing a LOT=false option in Bitcoin Core was questioned due to the software complexity involved. Bitcoin Core's long-standing policy is not to ship options that diff --git a/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml b/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml index 3ccf251a26..e8392c90be 100644 --- a/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml +++ b/static/bitcoin-dev/March_2022/combined_Decentralized-BIP-47-payment-code-directory.xml @@ -2,7 +2,7 @@ 2 Combined summary - Decentralized BIP 47 payment code directory - 2025-09-26T15:56:26.533983+00:00 + 2025-10-11T22:04:59.885273+00:00 python-feedgen Prayank 2022-03-02 04:45:58+00:00 @@ -18,10 +18,11 @@ + 2 Combined summary - Decentralized BIP 47 payment code directory - 2025-09-26T15:56:26.534133+00:00 + 2025-10-11T22:04:59.885428+00:00 2022-03-02T04:45:58+00:00 In a conversation between Peter and Prayank, Prayank introduces a newer version (v3 and v4) of BIP47, which has been proposed on GitHub. This version aims to solve the toxic change issue and seems like an improvement. Prayank explains that using an xpub does not provide anonymity because anyone who has access to the xpub, including platforms or hackers, can identify one's payments. However, using a payment code allows for public association without revealing the payment identifier on the blockchain, making it difficult for others to determine if funds have been received. Prayank also suggests a rust library that can assist application developers in implementing BIP47 into different bitcoin projects.The OpenBitcoinPrivacyProject has proposed a newer version of BIP47, v3 and v4, which addresses certain issues present in the previous version. The new version eliminates the toxic change issue by modifying the notification from Alice to Bob as a transaction from Alice to herself, functioning as a bare 1 of 3 multisig. Two pubkeys represent Alice's payment code and Bob's payment identifier. This change incurs a one-time overhead of 64 bytes for the two pubkeys, which is spread out over the lifespan of the relationship between Alice and Bob. Additionally, the first economic payment from Alice to Bob can be included with the notification transaction. Payment codes can be recovered from the bip32 seed without requiring extra backups. The new version is already being used in production with Samourai wallet. BIP47 v3 enables Alice to receive Bob's address without exposing her IP/identity to Charlie. Charlie can observe Alice receiving the payment code material from Bob but cannot determine if Alice proceeded to make a payment to Bob. Unlike an xpub, this method ensures privacy even if the xpub is shared with a crowdfunding platform, as the platform or any potential hackers cannot identify the payments made by Alice. By using the payment code, individuals can publicly associate themselves with their payment code without revealing if they have received funds, as the payment code is not visible on the blockchain.Twitter has seen discussions about BIP47 and its potential to enhance privacy. However, some developers argue that it merely adds spam to the Bitcoin network without providing any actual improvements. Additionally, the only existing implementation of BIP47 is Paynym, a centralized payment code directory managed by Samourai wallet, raising concerns regarding privacy and security. To address these concerns, the author suggests utilizing TXT records and domains. They present a proof of concept using GNS (GNU Name Service) to create a payment code for Alice, adding it as a TXT record with an expiry date, and verifying it. The author also proposes using `gnunet-publish` as a replacement for notification transactions. These solutions could potentially help users avoid sharing their bitcoin addresses on social media platforms when receiving donations. In addition to these suggestions, the author provides links to related resources, including a Q&A on accepting donations correctly and a new proposal addressing privacy concerns. diff --git a/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml b/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml index 4676a281e2..985af4e225 100644 --- a/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml +++ b/static/bitcoin-dev/March_2022/combined_Recursive-covenant-opposition-or-the-absence-thereof-was-Re-TXHASH-CHECKSIGFROMSTACKVERIFY-in-lieu-of-CTV-and-ANYPREVOUT.xml @@ -2,7 +2,7 @@ 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2025-09-26T15:56:28.686168+00:00 + 2025-10-11T22:05:02.012087+00:00 python-feedgen Paul Sztorc 2022-03-04 20:06:50+00:00 @@ -94,10 +94,11 @@ + 2 Combined summary - Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT - 2025-09-26T15:56:28.686331+00:00 + 2025-10-11T22:05:02.012276+00:00 2022-03-04T20:06:50+00:00 In an email exchange on the bitcoin-dev mailing list, Billy Tetrud discusses sidechains and their potential to address the issue of a less-secure altcoin dominating Bitcoin. While he acknowledges some merits of sidechains in this scenario, Tetrud points out that they do not completely solve the problem. He raises concerns about a sidechain cutting off the main chain and whether it would be in the best interest of enough people. Tetrud also explores the benefits and drawbacks of largeblock sidechains compared to other payment systems like Visa and Lightning. Various tradeoffs, such as onboarding, payment speed, micropayments, fees, and contribution to layer 1 security budget, are considered. Tetrud concludes that if a layer 2 is harmless, its existence can be justified by one net benefit for some users.Another discussion revolves around the size of commitments needed for sidechains and channel factories. User ZmnSCPxj suggests a solution to reduce on-chain bytes by utilizing tweaks in the miner's key and unused TapScript. This eliminates the need for separate commitments and reduces data requirements. Additionally, sidechains can push zero bytes on-chain by using OP_RETURN inside TapScript for checking purposes.The conversation centers around the potential dominance of a sidechain over Bitcoin and how it could prevent an altcoin from dominating. The consensus is that having all chains, centralized and decentralized, in the same monetary unit ensures the decentralized chain always exists without interference from monetary network effects. However, it is argued that a sidechain cannot exist without its main chain, and if it becomes too popular, people may stop using the main chain altogether. The discussion also compares the benefits of a largeblock sidechain to Visa and Lightning and considers the burden on Bitcoin-only nodes. The potential advantages to users of a largeblock sidechain are discussed, including lower fees and more decentralization. The idea of sweeping fiat transactions into a largeblock sidechain is also explored.Another conversation between Billy Tetrud and Paul focuses on the use of sidechains in Bitcoin. Billy proposes that all chains, decentralized and centralized, being in the same monetary unit ensures the existence of the decentralized chain without interference from network effects. Paul disagrees, stating that sidechains cannot exist without their main chain and gives an example using a zcash sidechain. They also discuss the merits of largeblock sidechains and how they can allow users to easily sweep fiat transactions into the BTC universe. Paul believes that largeblock sidechains would not burden Bitcoin Core full nodes.The bitcoin-dev mailing list discussion covers various topics related to Bitcoin scalability, sidechains, network effects, and the security of Lightning Network and Drivechains. Participants argue that sidechains are necessary to prevent people from switching entirely to altcoins, which could be heavily exploited by attackers. Another participant suggests that having all chains in the same monetary unit guarantees the existence of the decentralized chain. The discussion delves into the security risks of LN channel factories and compares the security of LN and Drivechains. The participants emphasize the importance of separating the onboarding rate from the payment rate for designing different structures.The email exchange on the bitcoin-dev mailing list centers around the use of recursive covenants and their potential impact on Bitcoin. The discussion explores implementing techniques like Drivechains using recursive covenants. While concerns about negative effects on Bitcoin or the user base are raised, it is suggested that separate soft forks can be used to add recursive covenants if consensus is reached. The rejection of Drivechains in Bitcoin is also discussed, with arguments made against their implementation due to their distinct security model and potential block size increase. However, proponents argue that Drivechains could have a positive impact and should be given a chance. The debate includes discussions on miner censorship, block size increase, and the need for consensus changes. Paul Sztorc responds to the rejection of Drivechains, stating that there is no strong incentive for mainchain miners and sidechain validators to merge their businesses. He refutes claims that Drivechains would degrade security and believes that Drivechain was ahead of its time and will eventually be adopted. Other discussions revolve around encumbrances and restrictions on spend from covenants, the potential harm to the fungibility of UTXOs, and the shift in risk models. Some argue that introducing different risk models can be damaging to fungibility, while others believe that being able to reject certain coins is at the heart of Bitcoin's security. The email exchanges highlight the ongoing debates and considerations surrounding recursive covenants, Drivechains, and their potential impact on Bitcoin.In a recent email to the Bitcoin-dev mailing list, Jeremy Rubin raises concerns about proposals enabling more "featureful" covenants by adding additional computation into bitcoin script. They emphasize the importance of limiting operations in bitcoin script to "verification" rather than "computation" whenever possible. The author expresses uncertainty about these proposals and fears that opcodes like OP_CAT and OP_TX introduce unnecessary complexity into the script. However, diff --git a/static/bitcoin-dev/March_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml b/static/bitcoin-dev/March_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml index 357794603a..cd8915f14f 100644 --- a/static/bitcoin-dev/March_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml +++ b/static/bitcoin-dev/March_2023/combined_Bitcoin-fungibility-and-inscribed-sats.xml @@ -2,7 +2,7 @@ 2 Combined summary - Bitcoin fungibility and inscribed sats - 2025-09-26T14:29:07.842561+00:00 + 2025-10-11T21:53:22.593609+00:00 python-feedgen Kree Love 2023-04-20 23:06:17+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Bitcoin fungibility and inscribed sats - 2025-09-26T14:29:07.842698+00:00 + 2025-10-11T21:53:22.593766+00:00 2023-04-20T23:06:17+00:00 In a detailed message, the author shares their personal journey with Bitcoin, starting from late 2010 when they saw it as an electronic cash system. However, they express concern about the current state of Bitcoin, noting that it has become more of an electronic asset rather than a peer-to-peer cash system due to regulation and artificially limited block sizes causing network congestion and high fees.The author also highlights the challenges faced in improving fungibility, citing regulatory hostility towards protocols like CoinJoin. They emphasize the importance of practical applications and global usability for Bitcoin to maintain its status as a global currency, despite pressure from governments, industrial lobbies, and cartels.Furthermore, the author believes that Non-Fungible Tokens (NFTs) distract from the ongoing efforts to ensure the safety and stability of Bitcoin as a reserve currency. However, they clarify that NFTs do not affect the fungibility of Bitcoin itself, as there is no token standard being used. These sats or UTXOs can be sold as regular Bitcoin on exchanges and consolidated for use like any other Bitcoin.The issue of Bitcoin fungibility is acknowledged as debatable by the author, who is actively working on implementing a coinjoin feature to prevent censorship of post-mix UTXOs on certain exchanges. They also mention the existence of the Ordinals theory, where some users believe in it and strive to understand how Bitcoin works.Developers are mentioned as being interested in building various things around Bitcoin, including BIP, DEX, libraries, and projects implementing PSBT. The author acknowledges not living in a first-world country and not attending bitdevs but expresses their desire for Bitcoin to be accessible to all.In conclusion, the author urges people to freely use Bitcoin without changing consensus rules, as this approach will ultimately benefit Bitcoin. The message was sent using Proton Mail secure email. diff --git a/static/bitcoin-dev/March_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/March_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 0f281ce89a..9f1c804125 100644 --- a/static/bitcoin-dev/March_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/March_2023/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -2,7 +2,7 @@ 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:29:12.139212+00:00 + 2025-10-11T21:53:26.841236+00:00 python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -81,10 +81,11 @@ + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T14:29:12.139401+00:00 + 2025-10-11T21:53:26.841467+00:00 2023-03-13T16:38:25+00:00 On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to diff --git a/static/bitcoin-dev/March_2023/combined_Minimum-fees.xml b/static/bitcoin-dev/March_2023/combined_Minimum-fees.xml index 6377713c00..f86ce60a45 100644 --- a/static/bitcoin-dev/March_2023/combined_Minimum-fees.xml +++ b/static/bitcoin-dev/March_2023/combined_Minimum-fees.xml @@ -2,7 +2,7 @@ 2 Combined summary - Minimum fees - 2025-09-26T14:29:09.987583+00:00 + 2025-10-11T21:53:24.717237+00:00 python-feedgen vjudeu at gazeta.pl 2023-03-05 21:58:51+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - Minimum fees - 2025-09-26T14:29:09.987737+00:00 + 2025-10-11T21:53:24.717452+00:00 2023-03-05T21:58:51+00:00 The bitcoin community is considering a new protocol rule called min_fees, proposed by Giuseppe B. This rule would require miners to specify a minimum fee for the following block to be valid. The aim is to address the issue of low transaction fees and increase network security. Currently, transaction fees can be very small due to ample space in blocks. Users are willing to pay higher fees, but only if others do too. Miners also want higher fees. By implementing min_fees, the equilibrium could be brought closer to a socially optimal state. However, there are concerns about potential reorgs/orphan rates and chain instability. Further analysis and discussion are needed before implementing the rule. diff --git a/static/bitcoin-dev/March_2024/combined_Re-A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml b/static/bitcoin-dev/March_2024/combined_Re-A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml index 612f2800aa..70055a7824 100644 --- a/static/bitcoin-dev/March_2024/combined_Re-A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml +++ b/static/bitcoin-dev/March_2024/combined_Re-A-Free-Relay-Attack-Exploiting-RBF-Rule-6.xml @@ -2,7 +2,7 @@ 2 Combined summary - Re: A Free-Relay Attack Exploiting RBF Rule #6 - 2025-09-26T14:41:54.624579+00:00 + 2025-10-11T22:18:23.439702+00:00 python-feedgen Peter Todd 2024-03-28 19:16:00+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Re: A Free-Relay Attack Exploiting RBF Rule #6 - 2025-09-26T14:41:54.624710+00:00 + 2025-10-11T22:18:23.439817+00:00 2024-03-28T19:16:00+00:00 The discussion initiated by Peter Todd concerns CVE-2017-12842 and the broader issues surrounding vulnerability disclosure and patching within the Bitcoin Core community. Todd highlights a critical perspective on the severity of CVE-2017-12842, questioning its practical significance compared to the effort and resources required for exploitation. He raises concerns about certain design choices in projects like Sergio's RSK Bridge contract that could be prone to this vulnerability, implying a deeper issue with how security is approached in some blockchain projects. diff --git a/static/bitcoin-dev/May_2012/combined_BIP-33-Stratized-Nodes.xml b/static/bitcoin-dev/May_2012/combined_BIP-33-Stratized-Nodes.xml index 8d63a0ac96..ea15f114cd 100644 --- a/static/bitcoin-dev/May_2012/combined_BIP-33-Stratized-Nodes.xml +++ b/static/bitcoin-dev/May_2012/combined_BIP-33-Stratized-Nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 33 - Stratized Nodes - 2023-08-01T03:32:00.902364+00:00 + 2025-10-11T21:48:56.890855+00:00 + python-feedgen Jeff Garzik 2012-05-16 18:22:08+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - BIP 33 - Stratized Nodes - 2023-08-01T03:32:00.902364+00:00 + 2025-10-11T21:48:56.890994+00:00 - Mike Hearn and Jeff Garzik discussed an alternative solution for Bitcoin that involves implementing the original design outlined over a year ago. This design uses a new protocol command to set a Bloom filter on a connection, allowing only transactions matching that filter to appear in relayed inventory. Clients can adjust the strength of the filters to choose their preferred balance between privacy and bandwidth usage. By filtering server-side instead of downloading the entire chain and dropping irrelevant transactions, clients can gain confidence in their balance by examining the chain. The proposal covers the necessary bases for an idealized model of a client as a set of private keys.Stratized nodes have been considered useful but concerns have been raised regarding security and use cases beyond a sample conversation. The discovery process for stratized nodes is similar to normal nodes, with service nodes being explicitly chosen like IRC servers for clients. However, there are no economic motivations for running a stratized server. It is suggested that keeping each request minimal would prevent resource starvation and simplify the protocol. Additionally, it is recommended to allow history to be resolved with multiple services during data download and sorting.In an email thread between Mike Hearn and Amir Taaki, Hearn expresses his belief that the best option is to implement the original design proposed over a year ago. This design involves using a new protocol command to apply Bloom filters to connections, with only matching transactions appearing in relayed inventory. By adjusting the filters' strength, clients can choose their desired level of privacy and bandwidth usage. The filters are applied to each data block in each script, allowing selection for things like multisig outputs or outputs that don't use addresses/pubkeys to authenticate. Hearn suggests writing a BIP for this alternative protocol if someone else wants to implement it, as simple optimizations to BitcoinJ could maintain its performance.Peter reviewed a proposal from Amir and provided initial reactions. He finds the proposal cool and useful but less secure than validating an entire blockchain. Peter suggests exploring detailed use cases beyond a sample conversation to better understand the security implications. He raises concerns about discovery and how stratized servers will decide which transactions to relay/store, as well as the economic motivations for running such servers. Peter also suggests working out theoretical security/cost/value calculations for subverting or lying about transactions, NODE_STRATIZED transaction chains, and address balance requests.The proposed alternative solution involves implementing the original design outlined over a year ago using a new protocol command to set Bloom filters on connections. This change is relatively simple and allows clients to gain confidence in their balance by examining the chain. The proposal maintains compatibility with existing Bitcoin clients and can be implemented through simple optimizations to BitcoinJ. The goal of the proposal is to enhance the capabilities of the Bitcoin network without disrupting its infrastructure or user base. By utilizing the existing protocol and maintaining compatibility, the proposal aims to create a smooth transition into the new parallel system while providing benefits to both new and existing users. 2012-05-16T18:22:08+00:00 + Mike Hearn and Jeff Garzik discussed an alternative solution for Bitcoin that involves implementing the original design outlined over a year ago. This design uses a new protocol command to set a Bloom filter on a connection, allowing only transactions matching that filter to appear in relayed inventory. Clients can adjust the strength of the filters to choose their preferred balance between privacy and bandwidth usage. By filtering server-side instead of downloading the entire chain and dropping irrelevant transactions, clients can gain confidence in their balance by examining the chain. The proposal covers the necessary bases for an idealized model of a client as a set of private keys.Stratized nodes have been considered useful but concerns have been raised regarding security and use cases beyond a sample conversation. The discovery process for stratized nodes is similar to normal nodes, with service nodes being explicitly chosen like IRC servers for clients. However, there are no economic motivations for running a stratized server. It is suggested that keeping each request minimal would prevent resource starvation and simplify the protocol. Additionally, it is recommended to allow history to be resolved with multiple services during data download and sorting.In an email thread between Mike Hearn and Amir Taaki, Hearn expresses his belief that the best option is to implement the original design proposed over a year ago. This design involves using a new protocol command to apply Bloom filters to connections, with only matching transactions appearing in relayed inventory. By adjusting the filters' strength, clients can choose their desired level of privacy and bandwidth usage. The filters are applied to each data block in each script, allowing selection for things like multisig outputs or outputs that don't use addresses/pubkeys to authenticate. Hearn suggests writing a BIP for this alternative protocol if someone else wants to implement it, as simple optimizations to BitcoinJ could maintain its performance.Peter reviewed a proposal from Amir and provided initial reactions. He finds the proposal cool and useful but less secure than validating an entire blockchain. Peter suggests exploring detailed use cases beyond a sample conversation to better understand the security implications. He raises concerns about discovery and how stratized servers will decide which transactions to relay/store, as well as the economic motivations for running such servers. Peter also suggests working out theoretical security/cost/value calculations for subverting or lying about transactions, NODE_STRATIZED transaction chains, and address balance requests.The proposed alternative solution involves implementing the original design outlined over a year ago using a new protocol command to set Bloom filters on connections. This change is relatively simple and allows clients to gain confidence in their balance by examining the chain. The proposal maintains compatibility with existing Bitcoin clients and can be implemented through simple optimizations to BitcoinJ. The goal of the proposal is to enhance the capabilities of the Bitcoin network without disrupting its infrastructure or user base. By utilizing the existing protocol and maintaining compatibility, the proposal aims to create a smooth transition into the new parallel system while providing benefits to both new and existing users. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2012/combined_IPv6-bitcoin-support-now-live.xml b/static/bitcoin-dev/May_2012/combined_IPv6-bitcoin-support-now-live.xml index 052749300c..322e65dd30 100644 --- a/static/bitcoin-dev/May_2012/combined_IPv6-bitcoin-support-now-live.xml +++ b/static/bitcoin-dev/May_2012/combined_IPv6-bitcoin-support-now-live.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - IPv6 bitcoin support now live - 2023-08-01T03:31:38.572199+00:00 + 2025-10-11T21:48:52.642947+00:00 + python-feedgen Peter Todd 2012-05-27 17:02:06+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - IPv6 bitcoin support now live - 2023-08-01T03:31:38.572199+00:00 + 2025-10-11T21:48:52.643086+00:00 - On May 12, 2012, sipa added IPv6 support to the bitcoin/bitcoin.git repository, allowing for the integration of IPv6 nodes into the Bitcoin network. Pieter Wuille's DNS seeder at seed.bitcoin.sipa.be has also been updated to crawl the IPv6 network and provide AAAA records to assist IPv6 nodes in finding each other. Peter Todd noted that previously, an IPv6-only node would not be able to sync with the network unless a dual-net node was manually created and added. However, with the recent update, IPv6 nodes can now start up and sync with the network without any additional steps. In fact, Todd reported having five peers when he last checked.Jeff Garzik, representing exMULTI Inc., announced on the same day that IPv6 support had been added to the bitcoin/bitcoin.git repository. He mentioned that there were already a few live IPv6 nodes on the network and encouraged users with IPv6 connectivity to test the latest version of Bitcoin. Garzik also highlighted the role of Pieter's DNS seeder, which now includes crawling the IPv6 network and providing corresponding AAAA records. This feature is expected to facilitate the connection between IPv6 nodes.In summary, the recent update to the bitcoin/bitcoin.git repository introduced IPv6 support, allowing for the inclusion of IPv6 nodes in the Bitcoin network. Users are encouraged to update their software and test the new version, particularly those with IPv6 connectivity. Pieter's DNS seeder plays a crucial role in assisting IPv6 nodes in finding each other by providing AAAA records. The announcement was made by Jeff Garzik, representing exMULTI Inc., through a mailing list message. For users without IPv6, the resource sixxs.net is recommended as a means to obtain it. 2012-05-27T17:02:06+00:00 + On May 12, 2012, sipa added IPv6 support to the bitcoin/bitcoin.git repository, allowing for the integration of IPv6 nodes into the Bitcoin network. Pieter Wuille's DNS seeder at seed.bitcoin.sipa.be has also been updated to crawl the IPv6 network and provide AAAA records to assist IPv6 nodes in finding each other. Peter Todd noted that previously, an IPv6-only node would not be able to sync with the network unless a dual-net node was manually created and added. However, with the recent update, IPv6 nodes can now start up and sync with the network without any additional steps. In fact, Todd reported having five peers when he last checked.Jeff Garzik, representing exMULTI Inc., announced on the same day that IPv6 support had been added to the bitcoin/bitcoin.git repository. He mentioned that there were already a few live IPv6 nodes on the network and encouraged users with IPv6 connectivity to test the latest version of Bitcoin. Garzik also highlighted the role of Pieter's DNS seeder, which now includes crawling the IPv6 network and providing corresponding AAAA records. This feature is expected to facilitate the connection between IPv6 nodes.In summary, the recent update to the bitcoin/bitcoin.git repository introduced IPv6 support, allowing for the inclusion of IPv6 nodes in the Bitcoin network. Users are encouraged to update their software and test the new version, particularly those with IPv6 connectivity. Pieter's DNS seeder plays a crucial role in assisting IPv6 nodes in finding each other by providing AAAA records. The announcement was made by Jeff Garzik, representing exMULTI Inc., through a mailing list message. For users without IPv6, the resource sixxs.net is recommended as a means to obtain it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2012/combined_P2P-feature-discovery-was-Re-BIP-33-Stratized-Nodes-.xml b/static/bitcoin-dev/May_2012/combined_P2P-feature-discovery-was-Re-BIP-33-Stratized-Nodes-.xml index fcb19e6df2..0fd7c31ea2 100644 --- a/static/bitcoin-dev/May_2012/combined_P2P-feature-discovery-was-Re-BIP-33-Stratized-Nodes-.xml +++ b/static/bitcoin-dev/May_2012/combined_P2P-feature-discovery-was-Re-BIP-33-Stratized-Nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - P2P feature discovery (was Re: BIP 33 - Stratized Nodes) - 2023-08-01T03:32:21.429865+00:00 + 2025-10-11T21:48:59.012866+00:00 + python-feedgen Luke-Jr 2012-05-16 18:46:49+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - P2P feature discovery (was Re: BIP 33 - Stratized Nodes) - 2023-08-01T03:32:21.430867+00:00 + 2025-10-11T21:48:59.013006+00:00 - In a discussion on May 16, 2012, Jeff Garzik and Luke-Jr debated the idea of passing a large list of nodes along as part of the address. Luke-Jr suggested that service bits be propagated as part of the address to make it easier for users to identify nodes they want to connect to for specific services. However, Jeff Garzik raised concerns about the stratification of the peer list and the potential overload on bitcoin's P2P network. He believed that if the peer list becomes too stratified, clients should consider using another network instead. Luke-Jr clarified that his intention was for clients to be able to connect to specific nodes without connecting to every node.In an email exchange, Luke-Jr explained that service bits are already propagated as part of the address, allowing users to easily identify nodes for specific services. He acknowledged that passing long lists of nodes might not always be practical, but it could work for protocol changes that don't add new services. Jeff Garzik cautioned against using bitcoin's P2P network for unrelated tasks and emphasized the importance of not overloading the network with non-bitcoin related activities.On May 16, 2012, Jeff Garzik proposed an alternative solution to further overloading service bits or altering the version message. He suggested creating a new command called "get-features" that would return a list of key/value pairs. The key would be a string, and the value type would be determined by the key. This solution assumes that one already has a connection to the peer in question. By using this approach, clients can discover the features of a peer in an easy, flexible, and extensible manner. Passing a large list of nodes along may be unwieldy, but it could be useful for protocol changes that don't introduce new services.Amir Taaki proposed a different approach called BIP 33, which aimed to provide new functionality while maintaining compatibility with the existing Bitcoin protocol. This proposal suggested allowing a parallel system to operate alongside the main Bitcoin network without affecting current Bitcoin clients. However, Jeff Garzik suggested improving the discovery process by creating the "get-features" command. He proposed that this could be implemented as BIP 34 if there was enough interest from the community. The standard behavior of clients would be to send the "get-features" command after receiving remote version information as part of the initial connection handshake. 2012-05-16T18:46:49+00:00 + In a discussion on May 16, 2012, Jeff Garzik and Luke-Jr debated the idea of passing a large list of nodes along as part of the address. Luke-Jr suggested that service bits be propagated as part of the address to make it easier for users to identify nodes they want to connect to for specific services. However, Jeff Garzik raised concerns about the stratification of the peer list and the potential overload on bitcoin's P2P network. He believed that if the peer list becomes too stratified, clients should consider using another network instead. Luke-Jr clarified that his intention was for clients to be able to connect to specific nodes without connecting to every node.In an email exchange, Luke-Jr explained that service bits are already propagated as part of the address, allowing users to easily identify nodes for specific services. He acknowledged that passing long lists of nodes might not always be practical, but it could work for protocol changes that don't add new services. Jeff Garzik cautioned against using bitcoin's P2P network for unrelated tasks and emphasized the importance of not overloading the network with non-bitcoin related activities.On May 16, 2012, Jeff Garzik proposed an alternative solution to further overloading service bits or altering the version message. He suggested creating a new command called "get-features" that would return a list of key/value pairs. The key would be a string, and the value type would be determined by the key. This solution assumes that one already has a connection to the peer in question. By using this approach, clients can discover the features of a peer in an easy, flexible, and extensible manner. Passing a large list of nodes along may be unwieldy, but it could be useful for protocol changes that don't introduce new services.Amir Taaki proposed a different approach called BIP 33, which aimed to provide new functionality while maintaining compatibility with the existing Bitcoin protocol. This proposal suggested allowing a parallel system to operate alongside the main Bitcoin network without affecting current Bitcoin clients. However, Jeff Garzik suggested improving the discovery process by creating the "get-features" command. He proposed that this could be implemented as BIP 34 if there was enough interest from the community. The standard behavior of clients would be to send the "get-features" command after receiving remote version information as part of the initial connection handshake. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2012/combined_Potential-network-split-when-individual-tx-used-as-coinbase-.xml b/static/bitcoin-dev/May_2012/combined_Potential-network-split-when-individual-tx-used-as-coinbase-.xml index 51a0b12c27..f113bf1139 100644 --- a/static/bitcoin-dev/May_2012/combined_Potential-network-split-when-individual-tx-used-as-coinbase-.xml +++ b/static/bitcoin-dev/May_2012/combined_Potential-network-split-when-individual-tx-used-as-coinbase-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Potential network split when individual tx used as coinbase? - 2023-08-01T03:31:22.337206+00:00 + 2025-10-11T21:48:48.387435+00:00 + python-feedgen Pieter Wuille 2012-05-05 11:40:35+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Potential network split when individual tx used as coinbase? - 2023-08-01T03:31:22.337206+00:00 + 2025-10-11T21:48:48.387623+00:00 - In May 2012, a member named Rebroad raised a query on SourceForge regarding a code change in Bitcoin's main.cpp file. The change was related to the DoS (Denial of Service) protocol for nodes sending transactions that use individual transactions as their coinbase. Specifically, Rebroad wanted to know if this change affected transactions with zero confirmations. Pieter, another member of the Bitcoin community, responded to the query and provided clarification. From Pieter's response, it can be inferred that there was indeed a code change made to Bitcoin eight months prior that allowed for denial-of-service (DoS) attacks on 100 nodes sending transactions using individual transactions as the coinbase. The writer of the context is seeking to understand whether this change puts transactions with zero confirmations at risk of causing a network split. They also mention having come across services that facilitate zero-confirmation transactions, which suggests that there are peers within the Bitcoin community who accept such transactions. It remains uncertain whether the writer may have misinterpreted the code or not. Additionally, the writer raises a question about whether a BIP (Bitcoin Improvement Proposal) would have been applicable or considered for the code change made. 2012-05-05T11:40:35+00:00 + In May 2012, a member named Rebroad raised a query on SourceForge regarding a code change in Bitcoin's main.cpp file. The change was related to the DoS (Denial of Service) protocol for nodes sending transactions that use individual transactions as their coinbase. Specifically, Rebroad wanted to know if this change affected transactions with zero confirmations. Pieter, another member of the Bitcoin community, responded to the query and provided clarification. From Pieter's response, it can be inferred that there was indeed a code change made to Bitcoin eight months prior that allowed for denial-of-service (DoS) attacks on 100 nodes sending transactions using individual transactions as the coinbase. The writer of the context is seeking to understand whether this change puts transactions with zero confirmations at risk of causing a network split. They also mention having come across services that facilitate zero-confirmation transactions, which suggests that there are peers within the Bitcoin community who accept such transactions. It remains uncertain whether the writer may have misinterpreted the code or not. Additionally, the writer raises a question about whether a BIP (Bitcoin Improvement Proposal) would have been applicable or considered for the code change made. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2012/combined_Punishing-empty-blocks-.xml b/static/bitcoin-dev/May_2012/combined_Punishing-empty-blocks-.xml index 7ba1a6eb9c..b0bf7b0d2e 100644 --- a/static/bitcoin-dev/May_2012/combined_Punishing-empty-blocks-.xml +++ b/static/bitcoin-dev/May_2012/combined_Punishing-empty-blocks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Punishing empty blocks? - 2023-08-01T03:33:18.252209+00:00 + 2025-10-11T21:48:54.766086+00:00 + python-feedgen Rebroad (sourceforge) 2012-05-29 16:30:52+00:00 @@ -123,13 +124,13 @@ - python-feedgen + 2 Combined summary - Punishing empty blocks? - 2023-08-01T03:33:18.253205+00:00 + 2025-10-11T21:48:54.766275+00:00 - In a 2012 email thread, Bitcoin developer Jeff Garzik raised concerns about the prevalence of empty blocks being mined by some Bitcoin miners. Despite Satoshi Nakamoto's suggestion to hash only the fixed 80-byte header, some miners found it more profitable to mine empty blocks rather than waiting for new transactions. Garzik proposed two potential solutions to address this issue.The first solution suggested not storing or relaying empty blocks if a certain amount of time had passed since the last block. This approach aimed to disincentivize miners from mining empty blocks and encourage them to include transactions instead. However, there were concerns that no-transaction (no-TX) miners might include statically generated transactions, which could undermine the effectiveness of this solution.The second proposal involved ensuring that the latest block includes a certain percentage of unconfirmed transactions from the mempool. This would incentivize miners to include transactions in their blocks and improve the efficiency of the Bitcoin network. However, there was a concern that this approach could lead to miners refusing to relay quickly found blocks.Another participant in the discussion, Arthur, recommended a stronger change to prevent a mystery miner from masking their block by including a few transactions to themselves. The ongoing debate highlighted the challenge of optimizing the mining process while maintaining the integrity and security of the Bitcoin network.Overall, the proposed client implementation changes aimed to discourage the mining of empty blocks and incentivize miners to include transactions. This would increase the efficiency of the network and enhance the user experience for Bitcoin users. However, it remains to be seen whether these solutions will be widely adopted by the Bitcoin community and implemented in future versions of the Bitcoin client. 2012-05-29T16:30:52+00:00 + In a 2012 email thread, Bitcoin developer Jeff Garzik raised concerns about the prevalence of empty blocks being mined by some Bitcoin miners. Despite Satoshi Nakamoto's suggestion to hash only the fixed 80-byte header, some miners found it more profitable to mine empty blocks rather than waiting for new transactions. Garzik proposed two potential solutions to address this issue.The first solution suggested not storing or relaying empty blocks if a certain amount of time had passed since the last block. This approach aimed to disincentivize miners from mining empty blocks and encourage them to include transactions instead. However, there were concerns that no-transaction (no-TX) miners might include statically generated transactions, which could undermine the effectiveness of this solution.The second proposal involved ensuring that the latest block includes a certain percentage of unconfirmed transactions from the mempool. This would incentivize miners to include transactions in their blocks and improve the efficiency of the Bitcoin network. However, there was a concern that this approach could lead to miners refusing to relay quickly found blocks.Another participant in the discussion, Arthur, recommended a stronger change to prevent a mystery miner from masking their block by including a few transactions to themselves. The ongoing debate highlighted the challenge of optimizing the mining process while maintaining the integrity and security of the Bitcoin network.Overall, the proposed client implementation changes aimed to discourage the mining of empty blocks and incentivize miners to include transactions. This would increase the efficiency of the network and enhance the user experience for Bitcoin users. However, it remains to be seen whether these solutions will be widely adopted by the Bitcoin community and implemented in future versions of the Bitcoin client. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2012/combined_URI-Handling-in-Bitcoin-Qt.xml b/static/bitcoin-dev/May_2012/combined_URI-Handling-in-Bitcoin-Qt.xml index 37fa84205d..4896d485e7 100644 --- a/static/bitcoin-dev/May_2012/combined_URI-Handling-in-Bitcoin-Qt.xml +++ b/static/bitcoin-dev/May_2012/combined_URI-Handling-in-Bitcoin-Qt.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - URI Handling in Bitcoin-Qt - 2023-08-01T03:31:11.793756+00:00 + 2025-10-11T21:48:50.519273+00:00 + python-feedgen Alan Reiner 2012-05-04 00:54:39+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - URI Handling in Bitcoin-Qt - 2023-08-01T03:31:11.793756+00:00 + 2025-10-11T21:48:50.519458+00:00 - In an email exchange between Wladimir and Alan, the concept of transaction meta-data fields is discussed. Alan proposes adding separate strings for labeling addresses and transactions in the client. He believes that having different strings for owner information and purchase information would be ideal and would align with the availability of "label=" and "message=" fields in BIP 21. However, Alan acknowledges that this approach may not be feasible if Bitcoin-Qt cannot support it. For now, he suggests that users rely on the /label/ field for important information, as anything in the /message/ field might not be saved. Although Alan expects message data to be displayed after clicking the URI, it may not be saved. In the future, users may populate both the /message/ and /label/ fields with extensive data using newlines. The first line would serve as a summary and be displayed in the address book and ledger, while additional lines would be visible when the user opens a details window. This functionality would be automatically generated by the merchant, providing purchasers with detailed documentation effortlessly.Alan Reiner raises questions about the implementation of "label" and "message" fields in Bitcoin Wallet for Android. The response indicates that the current version ignores both fields, but displaying the transaction message is part of the developer's short-term plan. No distinction between the two fields is mentioned.During another email exchange, Alan inquires about the status and plans for supporting "bitcoin:" URIs in the Satoshi client. It is mentioned that the feature is already implemented for Linux (Gnome) and Windows but temporarily disabled on Windows due to a startup crash issue with boost::ipc. Alan also seeks clarification on the intentions behind the "label=" and "message=" fields. The label is intended for the destination address, while the message is meant for a freeform description of the transaction. Currently, the message is not stored in the Satoshi client, but there are plans to add it in the future, along with other transaction meta-data fields such as contact information, purchased items, and item prices.The author of the message requests information on two BIP 21 (URI scheme) implementation topics in Armory and Bitcoin-Qt. Firstly, they ask about the support for "bitcoin:" URIs in the Satoshi client and express that this feature could greatly enhance usability. Secondly, they seek clarification on the intentions behind the "label=" and "message=" fields in Bitcoin-Qt, highlighting how Armory has implemented them to support both address labels and transaction labels. The author suggests that merchants could include additional purchase information in the "message" field while only disclosing their business name in the "label" field to maintain privacy. Additionally, the author is interested in understanding how other clients implement these features and whether they distinguish between "label" and "message." 2012-05-04T00:54:39+00:00 + In an email exchange between Wladimir and Alan, the concept of transaction meta-data fields is discussed. Alan proposes adding separate strings for labeling addresses and transactions in the client. He believes that having different strings for owner information and purchase information would be ideal and would align with the availability of "label=" and "message=" fields in BIP 21. However, Alan acknowledges that this approach may not be feasible if Bitcoin-Qt cannot support it. For now, he suggests that users rely on the /label/ field for important information, as anything in the /message/ field might not be saved. Although Alan expects message data to be displayed after clicking the URI, it may not be saved. In the future, users may populate both the /message/ and /label/ fields with extensive data using newlines. The first line would serve as a summary and be displayed in the address book and ledger, while additional lines would be visible when the user opens a details window. This functionality would be automatically generated by the merchant, providing purchasers with detailed documentation effortlessly.Alan Reiner raises questions about the implementation of "label" and "message" fields in Bitcoin Wallet for Android. The response indicates that the current version ignores both fields, but displaying the transaction message is part of the developer's short-term plan. No distinction between the two fields is mentioned.During another email exchange, Alan inquires about the status and plans for supporting "bitcoin:" URIs in the Satoshi client. It is mentioned that the feature is already implemented for Linux (Gnome) and Windows but temporarily disabled on Windows due to a startup crash issue with boost::ipc. Alan also seeks clarification on the intentions behind the "label=" and "message=" fields. The label is intended for the destination address, while the message is meant for a freeform description of the transaction. Currently, the message is not stored in the Satoshi client, but there are plans to add it in the future, along with other transaction meta-data fields such as contact information, purchased items, and item prices.The author of the message requests information on two BIP 21 (URI scheme) implementation topics in Armory and Bitcoin-Qt. Firstly, they ask about the support for "bitcoin:" URIs in the Satoshi client and express that this feature could greatly enhance usability. Secondly, they seek clarification on the intentions behind the "label=" and "message=" fields in Bitcoin-Qt, highlighting how Armory has implemented them to support both address labels and transaction labels. The author suggests that merchants could include additional purchase information in the "message" field while only disclosing their business name in the "label" field to maintain privacy. Additionally, the author is interested in understanding how other clients implement these features and whether they distinguish between "label" and "message." - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2012/combined_new-bitcoin-org-clients-page.xml b/static/bitcoin-dev/May_2012/combined_new-bitcoin-org-clients-page.xml index e606fd446d..680bfacfb3 100644 --- a/static/bitcoin-dev/May_2012/combined_new-bitcoin-org-clients-page.xml +++ b/static/bitcoin-dev/May_2012/combined_new-bitcoin-org-clients-page.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - new bitcoin.org clients page - 2023-08-01T03:29:16.874507+00:00 + 2025-10-11T21:49:01.136201+00:00 + python-feedgen Jorge Timón 2012-05-03 10:25:48+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - new bitcoin.org clients page - 2023-08-01T03:29:16.874507+00:00 + 2025-10-11T21:49:01.136448+00:00 - In a discussion on the Freicoin forum, Andreas Schildbach suggested adding Bitcoin Wallet to the list of smartphone clients. Jorge Timón responded with concerns about the slowness of cell phone apps. Schildbach explained that Bitcoin Wallet is just as fast as any other client after the initial blockchain update. The advantage is that users are not dependent on any server.In an email conversation, Schildbach suggested adding Bitcoin Wallet to the list of cell phone apps. Jorge raised concerns about slowness, but Schildbach clarified that it works just as fast as other clients. On May 3, 2012, Schildbach requested adding Bitcoin Wallet to the list of smartphone clients.An article titled "Reply-To" Munging Considered Harmful discusses the negative effects of changing the "Reply-To" field in email messages. The author argues against this practice, noting potential confusion and loss of important information. The author suggests leaving the original "Reply-To" field intact for clear communication.In an email exchange, Jeff Garzik expresses concerns about Bitcoin.org being too centralized. He proposes creating an independently managed website for Bitcoin clients. The conversation also mentions different Bitcoin clients, their requirements, design, and availability.The email thread discusses the ordering of Bitcoin clients on bitcoin.org. Discussions become messy, and Amir Taaki decides the ordering to prevent exploitation. Gary Rowe proposes simple descriptions for each client, including details like required blockchains and development language. The conversation digresses into email etiquette and issues related to group emails. The thread ends with announcements for a security virtual conference and links to the Bitcoin-development mailing list.The email thread focuses on the comparison of Bitcoin clients such as Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet. Each client is described in terms of requirements, design, availability, and programming language. There is also a discussion on email etiquette and the harmful effects of "Reply-To" munging. The conversation ends with announcements for a security virtual conference and links to the Bitcoin-development mailing list.In an email thread, members discuss creating a webpage for less technically-inclined Bitcoin users. Different Bitcoin clients like Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet are described in terms of requirements, design, and availability. Email etiquette and issues related to group emails are also discussed. The thread ends with a promotion for a live security virtual conference.The email conversation proposes creating a simple webpage for new Bitcoin users, discussing different Bitcoin clients like Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet. Email etiquette is also discussed, along with a link to an article about "Reply-To" munging. The conversation ends with announcements for a live security virtual conference and links to the Bitcoin-development mailing list.The email conversation suggests changes to the Bitcoin.org clients page for better user experience. Different Bitcoin clients are discussed, including their requirements, design, and availability. The conversation also touches on email etiquette and issues related to group emails. The email ends with an invitation to a live security virtual conference.The context discusses various email conversations and exchanges regarding different topics related to email functionality, Bitcoin clients, and the Bitcoin.org website. In one conversation, a writer expresses frustration with default email options when group emailing. They mention using Yahoo mail for spam and mailing lists and finding it difficult to access the 'reply all' option. Jeff Garzik suggests using "Reply to All," but the writer explains its limitations. The conversation also touches on the harmful effects of "Reply-To" Munging.Another email exchange discusses the best way to respond to group emails. Using the "Reply to All" function is recommended, but it can lead to cluttered threads if people don't trim their responses. Using the "reply to" function is suggested as an alternative to ensure only intended recipients receive the response.Bitcoin.org is described as a resource for learning about Bitcoin. Different Bitcoin client options are discussed, including Bitcoin-Qt, MultiBit, Armory, and Electrum, each with their own features and benefits. The importance of language support and sync-up times for these clients is also mentioned.The discussion on running the Bitcoin.org page focuses on maintaining a theme per client while keeping descriptions less technical. The suggestion is made to provide neutral descriptions that highlight strengths and weaknesses and evolve them based on user and developer feedback. Links to client websites and platforms are provided in the descriptions.The conversation between Alan and Mike Hearn clarifies that Bitcoin-Qt was written by Wladimir, not Satoshi Nakamoto. Feedback on descriptions and language support for Bitcoin clients is exchanged. The goal is to provide objective information for users to make informed decisions.There is a mention of changing the initial start time for blockchain sync-up on normal systems and reducing the sync-up time. The importance of refining the system for optimal performance is emphasized.The discussion on the Bitcoin.org clients page involves creating descriptions for each client that emphasize 2012-05-03T10:25:48+00:00 + In a discussion on the Freicoin forum, Andreas Schildbach suggested adding Bitcoin Wallet to the list of smartphone clients. Jorge Timón responded with concerns about the slowness of cell phone apps. Schildbach explained that Bitcoin Wallet is just as fast as any other client after the initial blockchain update. The advantage is that users are not dependent on any server.In an email conversation, Schildbach suggested adding Bitcoin Wallet to the list of cell phone apps. Jorge raised concerns about slowness, but Schildbach clarified that it works just as fast as other clients. On May 3, 2012, Schildbach requested adding Bitcoin Wallet to the list of smartphone clients.An article titled "Reply-To" Munging Considered Harmful discusses the negative effects of changing the "Reply-To" field in email messages. The author argues against this practice, noting potential confusion and loss of important information. The author suggests leaving the original "Reply-To" field intact for clear communication.In an email exchange, Jeff Garzik expresses concerns about Bitcoin.org being too centralized. He proposes creating an independently managed website for Bitcoin clients. The conversation also mentions different Bitcoin clients, their requirements, design, and availability.The email thread discusses the ordering of Bitcoin clients on bitcoin.org. Discussions become messy, and Amir Taaki decides the ordering to prevent exploitation. Gary Rowe proposes simple descriptions for each client, including details like required blockchains and development language. The conversation digresses into email etiquette and issues related to group emails. The thread ends with announcements for a security virtual conference and links to the Bitcoin-development mailing list.The email thread focuses on the comparison of Bitcoin clients such as Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet. Each client is described in terms of requirements, design, availability, and programming language. There is also a discussion on email etiquette and the harmful effects of "Reply-To" munging. The conversation ends with announcements for a security virtual conference and links to the Bitcoin-development mailing list.In an email thread, members discuss creating a webpage for less technically-inclined Bitcoin users. Different Bitcoin clients like Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet are described in terms of requirements, design, and availability. Email etiquette and issues related to group emails are also discussed. The thread ends with a promotion for a live security virtual conference.The email conversation proposes creating a simple webpage for new Bitcoin users, discussing different Bitcoin clients like Bitcoin-Qt, MultiBit, Armory, Electrum, and Bitcoin Wallet. Email etiquette is also discussed, along with a link to an article about "Reply-To" munging. The conversation ends with announcements for a live security virtual conference and links to the Bitcoin-development mailing list.The email conversation suggests changes to the Bitcoin.org clients page for better user experience. Different Bitcoin clients are discussed, including their requirements, design, and availability. The conversation also touches on email etiquette and issues related to group emails. The email ends with an invitation to a live security virtual conference.The context discusses various email conversations and exchanges regarding different topics related to email functionality, Bitcoin clients, and the Bitcoin.org website. In one conversation, a writer expresses frustration with default email options when group emailing. They mention using Yahoo mail for spam and mailing lists and finding it difficult to access the 'reply all' option. Jeff Garzik suggests using "Reply to All," but the writer explains its limitations. The conversation also touches on the harmful effects of "Reply-To" Munging.Another email exchange discusses the best way to respond to group emails. Using the "Reply to All" function is recommended, but it can lead to cluttered threads if people don't trim their responses. Using the "reply to" function is suggested as an alternative to ensure only intended recipients receive the response.Bitcoin.org is described as a resource for learning about Bitcoin. Different Bitcoin client options are discussed, including Bitcoin-Qt, MultiBit, Armory, and Electrum, each with their own features and benefits. The importance of language support and sync-up times for these clients is also mentioned.The discussion on running the Bitcoin.org page focuses on maintaining a theme per client while keeping descriptions less technical. The suggestion is made to provide neutral descriptions that highlight strengths and weaknesses and evolve them based on user and developer feedback. Links to client websites and platforms are provided in the descriptions.The conversation between Alan and Mike Hearn clarifies that Bitcoin-Qt was written by Wladimir, not Satoshi Nakamoto. Feedback on descriptions and language support for Bitcoin clients is exchanged. The goal is to provide objective information for users to make informed decisions.There is a mention of changing the initial start time for blockchain sync-up on normal systems and reducing the sync-up time. The importance of refining the system for optimal performance is emphasized.The discussion on the Bitcoin.org clients page involves creating descriptions for each client that emphasize - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_-no-subject-.xml b/static/bitcoin-dev/May_2013/combined_-no-subject-.xml index a09c8867b3..ccc2c86f9d 100644 --- a/static/bitcoin-dev/May_2013/combined_-no-subject-.xml +++ b/static/bitcoin-dev/May_2013/combined_-no-subject-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - (no subject) - 2023-08-01T05:01:33.099019+00:00 + 2025-10-11T21:33:36.392497+00:00 + python-feedgen Btc Drak 2016-10-17 13:13:25+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - (no subject) - 2023-08-01T05:01:33.099019+00:00 + 2025-10-11T21:33:36.392680+00:00 - On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. 2016-10-17T13:13:25+00:00 + On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_0-8-2-branch.xml b/static/bitcoin-dev/May_2013/combined_0-8-2-branch.xml index fbe901bedd..8680611b73 100644 --- a/static/bitcoin-dev/May_2013/combined_0-8-2-branch.xml +++ b/static/bitcoin-dev/May_2013/combined_0-8-2-branch.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.8.2 branch - 2023-08-01T05:03:24.921954+00:00 + 2025-10-11T21:33:23.651399+00:00 + python-feedgen Luke-Jr 2013-05-30 02:57:06+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - 0.8.2 branch - 2023-08-01T05:03:24.921954+00:00 + 2025-10-11T21:33:23.651566+00:00 - On May 30, 2013, a user named grarpamp proposed the creation of a new branch at v0.8.2 in order to incorporate critical fixes without the need to keep up with post-release changes. In response, Luke announced that he would be creating the 0.8.x branch in the upcoming weeks. Currently, the stable branches can be found on Gitorious.The suggestion to create a 0.8.2 branch at commit 09e437b has been made for those who want to track a specific level of defect without having to follow all the ongoing developments in HEAD. This branch would include important fixes, such as d315eb0, which may be necessary for release builds. The purpose of this branch would be to provide a stable reference point for individuals who are not interested in the latest developments but still require significant fixes.By creating this branch, users will have the option to focus on critical fixes and maintain stability without being burdened by the continuous post-release developments. This allows for easier tracking of specific defect levels and ensures that important fixes are accessible for release builds. The 0.8.x branch, which will be created by Luke in the near future, will serve as a reliable source for those who prioritize stability over the latest developments. 2013-05-30T02:57:06+00:00 + On May 30, 2013, a user named grarpamp proposed the creation of a new branch at v0.8.2 in order to incorporate critical fixes without the need to keep up with post-release changes. In response, Luke announced that he would be creating the 0.8.x branch in the upcoming weeks. Currently, the stable branches can be found on Gitorious.The suggestion to create a 0.8.2 branch at commit 09e437b has been made for those who want to track a specific level of defect without having to follow all the ongoing developments in HEAD. This branch would include important fixes, such as d315eb0, which may be necessary for release builds. The purpose of this branch would be to provide a stable reference point for individuals who are not interested in the latest developments but still require significant fixes.By creating this branch, users will have the option to focus on critical fixes and maintain stability without being burdened by the continuous post-release developments. This allows for easier tracking of specific defect levels and ensures that important fixes are accessible for release builds. The 0.8.x branch, which will be created by Luke in the near future, will serve as a reliable source for those who prioritize stability over the latest developments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_0-8-2rc1-testnet-datadir-behavior-changed.xml b/static/bitcoin-dev/May_2013/combined_0-8-2rc1-testnet-datadir-behavior-changed.xml index 1ea5c9f874..816f90e644 100644 --- a/static/bitcoin-dev/May_2013/combined_0-8-2rc1-testnet-datadir-behavior-changed.xml +++ b/static/bitcoin-dev/May_2013/combined_0-8-2rc1-testnet-datadir-behavior-changed.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.8.2rc1 - testnet datadir behavior changed - 2023-08-01T04:52:30.959051+00:00 + 2025-10-11T21:33:44.899612+00:00 + python-feedgen Pieter Wuille 2013-05-12 09:04:09+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - 0.8.2rc1 - testnet datadir behavior changed - 2023-08-01T04:52:30.959051+00:00 + 2025-10-11T21:33:44.899811+00:00 - On May 10, 2013, Gavin Andresen announced the release of Bitcoin-Qt version 0.8.2 release candidate 1. This new version was made available through a SourceForge link provided in an email sent by Andresen. However, upon testing the release candidate, it was discovered that there was a glitch with something breaking.The glitch seemed to be related to an issue on Github, which was reported by Jay F. The issue involved a change in how the data directory was handled. In previous versions, the datadir worked as expected with both bitcoin-qt and bitcoind interacting without any problems when a command-line datadir was specified. However, with the new version, the root datadir data was ignored, and a new hierarchy was created in the subdirectory /testnet3. This change raised confusion for Gavin Andresen, as he did not anticipate this behavior.To further investigate the bug, Andresen tested removing the config file, which resulted in unexpected consequences. His testnet wallet balance appeared as real BTC, and Bitcoin attempted to reorganize 67,662 blocks starting from the genesis block. Eventually, a crash occurred with the error message "Assertion failed!" at line 1745 of the main.cpp file. Andresen noted that this issue should be added to the changelog, as dropping in this binary could potentially break testnet functionality for those using Bitcoin in this way for their testnet faucet, among other things.As a result of this glitch, the testnet data is now stored in the testnet3 subdirectory, regardless of whether a datadir is specified on the command line. Users are advised to manually move their data to the new subdirectory to ensure proper functioning of the testnet. 2013-05-12T09:04:09+00:00 + On May 10, 2013, Gavin Andresen announced the release of Bitcoin-Qt version 0.8.2 release candidate 1. This new version was made available through a SourceForge link provided in an email sent by Andresen. However, upon testing the release candidate, it was discovered that there was a glitch with something breaking.The glitch seemed to be related to an issue on Github, which was reported by Jay F. The issue involved a change in how the data directory was handled. In previous versions, the datadir worked as expected with both bitcoin-qt and bitcoind interacting without any problems when a command-line datadir was specified. However, with the new version, the root datadir data was ignored, and a new hierarchy was created in the subdirectory /testnet3. This change raised confusion for Gavin Andresen, as he did not anticipate this behavior.To further investigate the bug, Andresen tested removing the config file, which resulted in unexpected consequences. His testnet wallet balance appeared as real BTC, and Bitcoin attempted to reorganize 67,662 blocks starting from the genesis block. Eventually, a crash occurred with the error message "Assertion failed!" at line 1745 of the main.cpp file. Andresen noted that this issue should be added to the changelog, as dropping in this binary could potentially break testnet functionality for those using Bitcoin in this way for their testnet faucet, among other things.As a result of this glitch, the testnet data is now stored in the testnet3 subdirectory, regardless of whether a datadir is specified on the command line. Users are advised to manually move their data to the new subdirectory to ensure proper functioning of the testnet. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_2BTC-reward-for-making-probabalistic-double-spending-via-conflicting-transactions-easy.xml b/static/bitcoin-dev/May_2013/combined_2BTC-reward-for-making-probabalistic-double-spending-via-conflicting-transactions-easy.xml index e1b6d64ad0..d8511f3732 100644 --- a/static/bitcoin-dev/May_2013/combined_2BTC-reward-for-making-probabalistic-double-spending-via-conflicting-transactions-easy.xml +++ b/static/bitcoin-dev/May_2013/combined_2BTC-reward-for-making-probabalistic-double-spending-via-conflicting-transactions-easy.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 2BTC reward for making probabalistic double-spending via conflicting transactions easy - 2023-08-01T04:54:02.234899+00:00 + 2025-10-11T21:33:10.912128+00:00 + python-feedgen Alan Reiner 2013-05-15 13:31:33+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - 2BTC reward for making probabalistic double-spending via conflicting transactions easy - 2023-08-01T04:54:02.234899+00:00 + 2025-10-11T21:33:10.912269+00:00 - In a forum post dated May 15, 2013, Bitcoin developer Peter Todd offered a reward of 2 BTC to anyone who could create a command line tool capable of creating two versions of a Bitcoin transaction. One version would send coins to a desired recipient, while the other would send all coins back to the sender. The tool would also need to broadcast both transactions simultaneously to different nodes on the network. Todd suggested that using blockchain.info's raw transaction POST API and a local Bitcoin node might be a clever approach.The proposal sparked some concerns among forum participants, with one commenter likening the promotion of such tools to promoting mail theft. However, Todd had previously discussed the potential security issues with zero-conf transactions and the concept of replace-by-fee in the same thread.Todd later clarified that his intention was to demonstrate an attack before releasing the code for the tool. He believed it would be better for the community to understand and address any vulnerabilities before making the tool widely available. To this end, he invited attendees at a conference to attempt to double-spend against his Android wallet. He offered to buy the Bitcoins off them at Mt. Gox rates plus a 10% bonus and allowed them to keep the loot. Todd requested that the demonstration be videotaped for educational purposes.In a recent proposal addressing the security issues related to zero-conf transactions, it was noted that very few vendors have systems in place to detect conflicting transactions broadcasted on the network simultaneously. Additionally, there is no mechanism to propagate double-spend warnings. To tackle these issues, the author of the proposal offered a reward of 2 BTC to anyone who can develop a tool allowing users to create two versions of the same transaction and broadcast them simultaneously to different nodes on the network.The proposed solution involves finding a way to send coins to a desired recipient while simultaneously sending all coins back to the sender, both with the same transaction inputs. One approach suggested is to utilize blockchain.info's raw transaction POST API along with the local Bitcoin node. Furthermore, the author suggests demonstrating the attack against an Android wallet at a conference, with the intention of buying the Bitcoins at Mt. Gox rates plus a 10% bonus and allowing the attacker to keep the loot. The demonstration should be recorded for educational purposes. 2013-05-15T13:31:33+00:00 + In a forum post dated May 15, 2013, Bitcoin developer Peter Todd offered a reward of 2 BTC to anyone who could create a command line tool capable of creating two versions of a Bitcoin transaction. One version would send coins to a desired recipient, while the other would send all coins back to the sender. The tool would also need to broadcast both transactions simultaneously to different nodes on the network. Todd suggested that using blockchain.info's raw transaction POST API and a local Bitcoin node might be a clever approach.The proposal sparked some concerns among forum participants, with one commenter likening the promotion of such tools to promoting mail theft. However, Todd had previously discussed the potential security issues with zero-conf transactions and the concept of replace-by-fee in the same thread.Todd later clarified that his intention was to demonstrate an attack before releasing the code for the tool. He believed it would be better for the community to understand and address any vulnerabilities before making the tool widely available. To this end, he invited attendees at a conference to attempt to double-spend against his Android wallet. He offered to buy the Bitcoins off them at Mt. Gox rates plus a 10% bonus and allowed them to keep the loot. Todd requested that the demonstration be videotaped for educational purposes.In a recent proposal addressing the security issues related to zero-conf transactions, it was noted that very few vendors have systems in place to detect conflicting transactions broadcasted on the network simultaneously. Additionally, there is no mechanism to propagate double-spend warnings. To tackle these issues, the author of the proposal offered a reward of 2 BTC to anyone who can develop a tool allowing users to create two versions of the same transaction and broadcast them simultaneously to different nodes on the network.The proposed solution involves finding a way to send coins to a desired recipient while simultaneously sending all coins back to the sender, both with the same transaction inputs. One approach suggested is to utilize blockchain.info's raw transaction POST API along with the local Bitcoin node. Furthermore, the author suggests demonstrating the attack against an Android wallet at a conference, with the intention of buying the Bitcoins at Mt. Gox rates plus a 10% bonus and allowing the attacker to keep the loot. The demonstration should be recorded for educational purposes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_32-vs-64-bit-timestamp-fields.xml b/static/bitcoin-dev/May_2013/combined_32-vs-64-bit-timestamp-fields.xml index e2ca47021a..46c3a16497 100644 --- a/static/bitcoin-dev/May_2013/combined_32-vs-64-bit-timestamp-fields.xml +++ b/static/bitcoin-dev/May_2013/combined_32-vs-64-bit-timestamp-fields.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 32 vs 64-bit timestamp fields - 2023-08-01T04:51:11.460775+00:00 + 2025-10-11T21:33:15.156978+00:00 + python-feedgen Jeff Garzik 2013-05-09 15:43:31+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - 32 vs 64-bit timestamp fields - 2023-08-01T04:51:11.461779+00:00 + 2025-10-11T21:33:15.157195+00:00 - In an email conversation between Mike Hearn and Jeff Garzik, the issue of signed timestamps is discussed. Hearn raises the question of whether the 2038 issue applies to signed timestamps in Bitcoin blocks. Garzik responds by stating that they treat the field as unsigned, so it is not a major concern.The discussion then moves to Pieter Wuille's proposal for a well-defined 64-bit timestamp for each block, with only the lowest 32 bits included in the header. Wuille suggests that the full 64-bit timestamp can be derived deterministically by adding the lowest 32-bit value that does not violate certain rules. This proposal is not backward-incompatible and ensures that there is never a gap of more than 136 years between two blocks.Another email exchange between Peter Todd and someone else focuses on interpreting timestamps on blockchain blocks for timestamping purposes. Todd suggests changing the meaning of the header timestamp to be relative time passed since the last block. The conversation also mentions the possibility of using a random beacon for secure timestamping and the idea of having a flag day where blocks after a certain height are considered to have a different epoch.The accuracy of block timestamps in Bitcoin is discussed, with nodes accepting blocks within a certain time range. It is noted that miners have an incentive to set the timestamp accurately to avoid driving up the difficulty. Two types of timestamps are mentioned: proofs that data existed before a time and proofs that data existed after. A solution is proposed to update the block header time calculation during a flag day when blocks after a certain height are considered to have a different epoch.A conversation between Pieter Wuille and Jeff Garzik debates the relevance of the year 2038 in relation to Bitcoin's block header format. Wuille believes it is unlikely that they would break the block header format and invalidate mining hardware. He suggests that even 16 bits of precision in the block header timestamp could suffice under certain conditions. The discussion ends with a link to download a free book on graph databases and an invitation to join the Bitcoin-development mailing list.Jeff Garzik and John Dillon discuss the possibility of Satoshi Nakamoto intentionally designing the Bitcoin protocol to require a hard fork in 2038. Garzik dismisses this idea, stating that it is too far in the future to be relevant. He also argues against expanding the precision beyond 32 bits in the timestamp field. Pieter adds that assuming the "full" 64-bit time is the smallest one that makes sense given its lower 32 bits would work fine.In an email exchange, John Dillon speculates about Satoshi Nakamoto setting up the Bitcoin network to require a hard fork in the future. Jeff Garzik responds by saying that 2038 is too far off to be relevant and explains that a hard fork may be necessary to break the 1MB limit. Garzik's email signature indicates that he was working for exMULTI, Inc. at the time.Peter Todd speculates about whether Satoshi Nakamoto deliberately used 32-bit timestamps in Bitcoin's code. Todd suggests that a hard fork could be an opportunity to change the timestamps. The email is signed using GnuPG v1.4.11 with a SHA256 hash.The reason behind having both 32-bit and 64-bit timestamp fields in Bitcoin is discussed in an email thread. It is explained that changing the fields would require all Bitcoin users to update their software simultaneously, which is a "hard-fork" change. It is suggested that fixing the timestamps can be left until a hard fork is needed for other reasons.The question of why there are both 32-bit and 64-bit timestamp fields in the Bitcoin protocol specification is raised in an email from Addy Yeow. Jeff Garzik cryptically replies, "Hysterical raisins," which is a play on words of "historical reasons." The use of smaller timestamp fields may save space in the data structure for efficiency. However, without more information, the exact reason is unclear.In a post to a mailing list, Addy asks why there are both 32-bit and 64-bit timestamp fields instead of making all of them 64-bit in the Bitcoin protocol specification. The specific reason behind this choice is not clear, but it is suggested that using smaller timestamp fields may save space in the data structure for efficiency purposes. Further clarification is needed to fully understand the reasoning behind this design decision. 2013-05-09T15:43:31+00:00 + In an email conversation between Mike Hearn and Jeff Garzik, the issue of signed timestamps is discussed. Hearn raises the question of whether the 2038 issue applies to signed timestamps in Bitcoin blocks. Garzik responds by stating that they treat the field as unsigned, so it is not a major concern.The discussion then moves to Pieter Wuille's proposal for a well-defined 64-bit timestamp for each block, with only the lowest 32 bits included in the header. Wuille suggests that the full 64-bit timestamp can be derived deterministically by adding the lowest 32-bit value that does not violate certain rules. This proposal is not backward-incompatible and ensures that there is never a gap of more than 136 years between two blocks.Another email exchange between Peter Todd and someone else focuses on interpreting timestamps on blockchain blocks for timestamping purposes. Todd suggests changing the meaning of the header timestamp to be relative time passed since the last block. The conversation also mentions the possibility of using a random beacon for secure timestamping and the idea of having a flag day where blocks after a certain height are considered to have a different epoch.The accuracy of block timestamps in Bitcoin is discussed, with nodes accepting blocks within a certain time range. It is noted that miners have an incentive to set the timestamp accurately to avoid driving up the difficulty. Two types of timestamps are mentioned: proofs that data existed before a time and proofs that data existed after. A solution is proposed to update the block header time calculation during a flag day when blocks after a certain height are considered to have a different epoch.A conversation between Pieter Wuille and Jeff Garzik debates the relevance of the year 2038 in relation to Bitcoin's block header format. Wuille believes it is unlikely that they would break the block header format and invalidate mining hardware. He suggests that even 16 bits of precision in the block header timestamp could suffice under certain conditions. The discussion ends with a link to download a free book on graph databases and an invitation to join the Bitcoin-development mailing list.Jeff Garzik and John Dillon discuss the possibility of Satoshi Nakamoto intentionally designing the Bitcoin protocol to require a hard fork in 2038. Garzik dismisses this idea, stating that it is too far in the future to be relevant. He also argues against expanding the precision beyond 32 bits in the timestamp field. Pieter adds that assuming the "full" 64-bit time is the smallest one that makes sense given its lower 32 bits would work fine.In an email exchange, John Dillon speculates about Satoshi Nakamoto setting up the Bitcoin network to require a hard fork in the future. Jeff Garzik responds by saying that 2038 is too far off to be relevant and explains that a hard fork may be necessary to break the 1MB limit. Garzik's email signature indicates that he was working for exMULTI, Inc. at the time.Peter Todd speculates about whether Satoshi Nakamoto deliberately used 32-bit timestamps in Bitcoin's code. Todd suggests that a hard fork could be an opportunity to change the timestamps. The email is signed using GnuPG v1.4.11 with a SHA256 hash.The reason behind having both 32-bit and 64-bit timestamp fields in Bitcoin is discussed in an email thread. It is explained that changing the fields would require all Bitcoin users to update their software simultaneously, which is a "hard-fork" change. It is suggested that fixing the timestamps can be left until a hard fork is needed for other reasons.The question of why there are both 32-bit and 64-bit timestamp fields in the Bitcoin protocol specification is raised in an email from Addy Yeow. Jeff Garzik cryptically replies, "Hysterical raisins," which is a play on words of "historical reasons." The use of smaller timestamp fields may save space in the data structure for efficiency. However, without more information, the exact reason is unclear.In a post to a mailing list, Addy asks why there are both 32-bit and 64-bit timestamp fields instead of making all of them 64-bit in the Bitcoin protocol specification. The specific reason behind this choice is not clear, but it is suggested that using smaller timestamp fields may save space in the data structure for efficiency purposes. Further clarification is needed to fully understand the reasoning behind this design decision. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_An-initial-replace-by-fee-implementation-is-now-available.xml b/static/bitcoin-dev/May_2013/combined_An-initial-replace-by-fee-implementation-is-now-available.xml index 5314c76ce6..c2bf63071e 100644 --- a/static/bitcoin-dev/May_2013/combined_An-initial-replace-by-fee-implementation-is-now-available.xml +++ b/static/bitcoin-dev/May_2013/combined_An-initial-replace-by-fee-implementation-is-now-available.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - An initial replace-by-fee implementation is now available - 2023-08-01T04:51:29.820188+00:00 + 2025-10-11T21:32:58.160618+00:00 + python-feedgen Peter Todd 2013-05-09 12:20:05+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - An initial replace-by-fee implementation is now available - 2023-08-01T04:51:29.820188+00:00 + 2025-10-11T21:32:58.160775+00:00 - In an email conversation between Adam Back and Peter Todd, concerns are raised about conflicting double-spends with different payee and change addresses. Todd explains that the current mechanism for Bitcoin is the best available option but acknowledges that net-splits can weaken it. He suggests implementing a safety margin in fees to protect against after-the-fact blockchain analysis. Additionally, Todd raises a question about stopping both bids from being processed if they are too flexibly different.Todd responds to Back's concerns by explaining that the patch makes the concept of a 0-confirm double-spend obsolete. He argues that relying on the behavior of major miners and nodes for payments is not ideal and suggests not giving people a false sense of security.A discussion thread on the Bitcoin forum reveals concerns about the replace-by-fee patch, as it could potentially make double-spending easier. However, the patch addresses this issue by making double-spending impossible and providing more flexibility for users. Some argue that fee revisions should only be valid if every aspect of the revision remains unchanged except for the reward, while others believe this violates privacy. The patch allows for a simple replacement without further rules, allowing the fee adjustment process to continue indefinitely.Another thread on BitcoinTalk discusses the idea of replace-by-fee and how it could make 0-confirm double-spends easier. However, Adam argues against this notion and emphasizes that validation of fee revisions should include keeping every aspect of the revision unchanged except for the reward. A replace-by-fee implementation has been released on the testnet, but it is vulnerable to DoS attacks and does not include an "undo" RPC command or fee adjustments. Users are advised against mining on the mainnet with this implementation.Bitcoin developers Peter Todd and Adam Back have released a replace-by-fee implementation on the testnet after consulting with affected sites and requests from vulnerable parties. The implementation is available at testnet-replace-by-fee.bitcoin.petertodd.org. Users can test the server by using the raw transaction API and manually creating replacement transactions. The implementation does not include recursive fee evaluation to allow for gradual adoption. Peter Todd will receive the full reward for his work, despite it not being 100% complete, due to his concern for proper implementation and working with vulnerable sites.Overall, the discussions and implementations of replace-by-fee aim to address concerns about conflicting double-spends and provide a more secure and flexible solution for Bitcoin transactions. 2013-05-09T12:20:05+00:00 + In an email conversation between Adam Back and Peter Todd, concerns are raised about conflicting double-spends with different payee and change addresses. Todd explains that the current mechanism for Bitcoin is the best available option but acknowledges that net-splits can weaken it. He suggests implementing a safety margin in fees to protect against after-the-fact blockchain analysis. Additionally, Todd raises a question about stopping both bids from being processed if they are too flexibly different.Todd responds to Back's concerns by explaining that the patch makes the concept of a 0-confirm double-spend obsolete. He argues that relying on the behavior of major miners and nodes for payments is not ideal and suggests not giving people a false sense of security.A discussion thread on the Bitcoin forum reveals concerns about the replace-by-fee patch, as it could potentially make double-spending easier. However, the patch addresses this issue by making double-spending impossible and providing more flexibility for users. Some argue that fee revisions should only be valid if every aspect of the revision remains unchanged except for the reward, while others believe this violates privacy. The patch allows for a simple replacement without further rules, allowing the fee adjustment process to continue indefinitely.Another thread on BitcoinTalk discusses the idea of replace-by-fee and how it could make 0-confirm double-spends easier. However, Adam argues against this notion and emphasizes that validation of fee revisions should include keeping every aspect of the revision unchanged except for the reward. A replace-by-fee implementation has been released on the testnet, but it is vulnerable to DoS attacks and does not include an "undo" RPC command or fee adjustments. Users are advised against mining on the mainnet with this implementation.Bitcoin developers Peter Todd and Adam Back have released a replace-by-fee implementation on the testnet after consulting with affected sites and requests from vulnerable parties. The implementation is available at testnet-replace-by-fee.bitcoin.petertodd.org. Users can test the server by using the raw transaction API and manually creating replacement transactions. The implementation does not include recursive fee evaluation to allow for gradual adoption. Peter Todd will receive the full reward for his work, despite it not being 100% complete, due to his concern for proper implementation and working with vulnerable sites.Overall, the discussions and implementations of replace-by-fee aim to address concerns about conflicting double-spends and provide a more secure and flexible solution for Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Automated-Weekly-Testnet-Alerts.xml b/static/bitcoin-dev/May_2013/combined_Automated-Weekly-Testnet-Alerts.xml index 3d7182ccf3..d51a889e3a 100644 --- a/static/bitcoin-dev/May_2013/combined_Automated-Weekly-Testnet-Alerts.xml +++ b/static/bitcoin-dev/May_2013/combined_Automated-Weekly-Testnet-Alerts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Automated Weekly Testnet Alerts - 2023-08-01T04:51:42.393774+00:00 + 2025-10-11T21:33:00.289499+00:00 + python-feedgen Caleb James DeLisle 2013-05-10 18:45:01+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Automated Weekly Testnet Alerts - 2023-08-01T04:51:42.393774+00:00 + 2025-10-11T21:33:00.289658+00:00 - Starting next Thursday on the testnet, developers will be able to access automated weekly alerts to test their alert-handling code. These alerts will contain a message stating that it is a test alert, along with the timestamp of the initial broadcast. They will expire between 2 to 4 hours and will have varying priority levels. The announcement for these alerts will be made at 13:00 UTC, which is currently 9am EST.The purpose of this initiative is to provide developers with a practical way to test their alert-handling code. By receiving these weekly alerts, developers can identify any issues or bugs in their systems and make necessary improvements. It is important to note that these alerts are not actual emergencies but are solely for testing purposes.This new feature will be advantageous for developers who want to ensure that their alert-handling code is working efficiently and effectively. It offers them a platform to test and enhance their systems' capabilities. By participating in these weekly tests, developers can contribute to the overall security and reliability of the system.In addition to the information about the alerts, the email also includes a link to download a free book called "Graph Databases." This book is written by three renowned leaders in the field and provides valuable insights into graph databases.Overall, this email serves as an announcement to the Bitcoin-development mailing list, informing developers of the upcoming opportunity to test their alert-handling code using automated weekly alerts. It emphasizes the importance of thorough testing and improvement to ensure the system's integrity and reliability. 2013-05-10T18:45:01+00:00 + Starting next Thursday on the testnet, developers will be able to access automated weekly alerts to test their alert-handling code. These alerts will contain a message stating that it is a test alert, along with the timestamp of the initial broadcast. They will expire between 2 to 4 hours and will have varying priority levels. The announcement for these alerts will be made at 13:00 UTC, which is currently 9am EST.The purpose of this initiative is to provide developers with a practical way to test their alert-handling code. By receiving these weekly alerts, developers can identify any issues or bugs in their systems and make necessary improvements. It is important to note that these alerts are not actual emergencies but are solely for testing purposes.This new feature will be advantageous for developers who want to ensure that their alert-handling code is working efficiently and effectively. It offers them a platform to test and enhance their systems' capabilities. By participating in these weekly tests, developers can contribute to the overall security and reliability of the system.In addition to the information about the alerts, the email also includes a link to download a free book called "Graph Databases." This book is written by three renowned leaders in the field and provides valuable insights into graph databases.Overall, this email serves as an announcement to the Bitcoin-development mailing list, informing developers of the upcoming opportunity to test their alert-handling code using automated weekly alerts. It emphasizes the importance of thorough testing and improvement to ensure the system's integrity and reliability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_BIP-0021-idea-sendmany.xml b/static/bitcoin-dev/May_2013/combined_BIP-0021-idea-sendmany.xml index dd286eabe7..ac979fa1a6 100644 --- a/static/bitcoin-dev/May_2013/combined_BIP-0021-idea-sendmany.xml +++ b/static/bitcoin-dev/May_2013/combined_BIP-0021-idea-sendmany.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 0021 idea: sendmany - 2023-08-01T05:00:49.431502+00:00 + 2025-10-11T21:33:30.022082+00:00 + python-feedgen shaker521 at hushmail.com 2013-05-22 18:10:03+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP 0021 idea: sendmany - 2023-08-01T05:00:49.431502+00:00 + 2025-10-11T21:33:30.022237+00:00 - The given context discusses various aspects of Bitcoin, a decentralized digital currency that operates on a blockchain network. Created in 2009 by an anonymous individual or group known as Satoshi Nakamoto, Bitcoin can be bought and sold on exchanges and used for transactions. However, its high volatility poses risks for investors, and it has been associated with illegal activities like money laundering. Despite this, many people believe in the potential of Bitcoin to revolutionize the financial industry and create a more democratic system. Notable incidents involving Bitcoin include the bankruptcy of the Mt. Gox exchange in 2014 and the price surge and subsequent crash in 2017. While some view Bitcoin as a speculative bubble, it is undeniable that it has had a significant impact on finance and technology.In another topic, the author proposes a new bitcoin URI scheme that simplifies transactions with multiple outputs. The proposed format includes labels and addresses for improved readability and ease of parsing by bitcoin clients. The author also discusses potential failure modes and provides examples and testing results using MultiBit.Additionally, there is an email thread discussing the use of a percentage slider for a Bitcoin Improvement Proposal (BIP) related to extending BIP 21. The purpose of the slider is to make it explicit where a certain percentage goes. However, it is suggested that a new BIP needs to be written for this extension, and any syntax can be used. The email also includes an advertisement for New Relic, a SaaS-based application performance monitoring service, offering a shirt as a reward for trying their service.Overall, the given context lacks sufficient information to generate a detailed summary due to incomplete details about specific use cases, recipients, and amounts mentioned. The mention of an HTML attachment that has been scrubbed further adds to the lack of clarity. 2013-05-22T18:10:03+00:00 + The given context discusses various aspects of Bitcoin, a decentralized digital currency that operates on a blockchain network. Created in 2009 by an anonymous individual or group known as Satoshi Nakamoto, Bitcoin can be bought and sold on exchanges and used for transactions. However, its high volatility poses risks for investors, and it has been associated with illegal activities like money laundering. Despite this, many people believe in the potential of Bitcoin to revolutionize the financial industry and create a more democratic system. Notable incidents involving Bitcoin include the bankruptcy of the Mt. Gox exchange in 2014 and the price surge and subsequent crash in 2017. While some view Bitcoin as a speculative bubble, it is undeniable that it has had a significant impact on finance and technology.In another topic, the author proposes a new bitcoin URI scheme that simplifies transactions with multiple outputs. The proposed format includes labels and addresses for improved readability and ease of parsing by bitcoin clients. The author also discusses potential failure modes and provides examples and testing results using MultiBit.Additionally, there is an email thread discussing the use of a percentage slider for a Bitcoin Improvement Proposal (BIP) related to extending BIP 21. The purpose of the slider is to make it explicit where a certain percentage goes. However, it is suggested that a new BIP needs to be written for this extension, and any syntax can be used. The email also includes an advertisement for New Relic, a SaaS-based application performance monitoring service, offering a shirt as a reward for trying their service.Overall, the given context lacks sufficient information to generate a detailed summary due to incomplete details about specific use cases, recipients, and amounts mentioned. The mention of an HTML attachment that has been scrubbed further adds to the lack of clarity. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_BIP0032.xml b/static/bitcoin-dev/May_2013/combined_BIP0032.xml index f8c58687b9..d85b0322e2 100644 --- a/static/bitcoin-dev/May_2013/combined_BIP0032.xml +++ b/static/bitcoin-dev/May_2013/combined_BIP0032.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP0032 - 2023-08-01T05:03:13.982594+00:00 + 2025-10-11T21:33:21.526312+00:00 + python-feedgen Tamas Blummer 2013-05-28 05:16:41+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - BIP0032 - 2023-08-01T05:03:13.982594+00:00 + 2025-10-11T21:33:21.526538+00:00 - Tamas Blummer has shared a JSON file on GitHub that contains test vectors for Bitcoin Improvement Proposal (BIP) 32. The JSON file can be accessed at https://github.com/bitsofproof/supernode/blob/master/api/src/test/resources/BIP32.json. Along with the test vectors, Blummer has also provided Bits of Proof code that matches with them. The code can be found at https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java. Additionally, Blummer has attached a signature.asc file to the message.In an email thread discussing BIP 32, Michael Gronager points out the confusion caused by the current formulation of the BIP text. He suggests using better terminology such as type-1 and type-2 derivation instead of "public derivation" and "public derivation function". Gronager explains that the motivation for private derivation is to avoid revealing known values like K, c, and k_i, which could lead to the discovery of other values. He mentions that there are already other implementations available, such as a Python implementation by Felix Weis and Java code in Bits of Proof. Gronager emphasizes that implementing a deterministic wallet involves more than just key derivation; it also includes detecting new keys/chains being used, lookahead, and how to use accounts.In a reply to Gronager's comment, a member of the bitcoin-development mailing list explains that sharing the master public extended key with an auditor would allow them to see all transactions from and to the wallet, in all accounts, without revealing a single secret key. The original poster had attempted to implement this concept based on documentation and code from sipa's repository on GitHub, but was waiting for further implementation before proceeding. The email also includes an advertisement for New Relic's application performance monitoring service.It is clarified in another email that the statement regarding audits through the Master Public key, M, is incorrect. Only incoming and outgoing transactions of publicly derived wallets will be part of the audit. Privately derived wallets cannot be obtained. However, addition points from privately derived wallets can be shared without loss of security: (m/i')*G. It is emphasized that there is no concept of a single public master key. To provide full access to the list of incoming and outgoing payments, an auditor can be given the master public extended key. This will enable them to view all transactions from and to the wallet in all accounts, but not a single secret key.In an email to himself, Michael discusses the private derivation in the BIP and concludes that it is intentional. He explains that while (m/i/j/k)*G = (M/i/j/k), (m/i'/j/k)*G does not equal (M/i/j/k) and results in an error. However, ((m/i')*G)/j/k = (m/i'/j/k)*G. Michael believes that the private derivation is motivated by the desire to avoid revealing known values like K, c, and k_i since they could lead to the discovery of other values as well. He expresses concern that many people may fall into this trap.In an email to Pieter, Michael expresses his concerns about BIP0032 and the equations used for private and public derivation. He notes that there can only be one HMAC function used for both types of derivation. After analyzing the formulas for private derivation, he finds that they result in K_i = k_i*G = I_L*G + k_par(mod n)*G. However, the formula for public derivation results in K_i = (I_L+k_par)*G = I_L*G + K_par, which is not the same as the previous formula. To address this, Michael suggests changing the private child key derivation to CDK((k_par, c_par), i) -> (k_i, c_i), where I = HMACSHA512(c_par, X(k_par*G)||i). He proposes splitting I into I_L and I_R (256 bits each), resulting in k_i = k_par + I_L and c_i = I_R. For pure public derivation, where the private key is not known, Michael suggests using CDK'((K_par, c_par), i) -> (K_i, c_i), where I = HMACSHA512(c_par, X(K_par)||i). He explains that by splitting I into I_L and I_R, K_i = K_par + I_L*G (= k_par*G + I_L*G = (k_par+I_L)*G = k_i*G), and c_i = I_R. These changes ensure the right properties and equal c_i values for both types of derivation.Overall, these discussions highlight the complexities and considerations involved in implementing BIP 32 and emphasize the importance of using proper terminology and equations to avoid confusion and potential security risks. 2013-05-28T05:16:41+00:00 + Tamas Blummer has shared a JSON file on GitHub that contains test vectors for Bitcoin Improvement Proposal (BIP) 32. The JSON file can be accessed at https://github.com/bitsofproof/supernode/blob/master/api/src/test/resources/BIP32.json. Along with the test vectors, Blummer has also provided Bits of Proof code that matches with them. The code can be found at https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java. Additionally, Blummer has attached a signature.asc file to the message.In an email thread discussing BIP 32, Michael Gronager points out the confusion caused by the current formulation of the BIP text. He suggests using better terminology such as type-1 and type-2 derivation instead of "public derivation" and "public derivation function". Gronager explains that the motivation for private derivation is to avoid revealing known values like K, c, and k_i, which could lead to the discovery of other values. He mentions that there are already other implementations available, such as a Python implementation by Felix Weis and Java code in Bits of Proof. Gronager emphasizes that implementing a deterministic wallet involves more than just key derivation; it also includes detecting new keys/chains being used, lookahead, and how to use accounts.In a reply to Gronager's comment, a member of the bitcoin-development mailing list explains that sharing the master public extended key with an auditor would allow them to see all transactions from and to the wallet, in all accounts, without revealing a single secret key. The original poster had attempted to implement this concept based on documentation and code from sipa's repository on GitHub, but was waiting for further implementation before proceeding. The email also includes an advertisement for New Relic's application performance monitoring service.It is clarified in another email that the statement regarding audits through the Master Public key, M, is incorrect. Only incoming and outgoing transactions of publicly derived wallets will be part of the audit. Privately derived wallets cannot be obtained. However, addition points from privately derived wallets can be shared without loss of security: (m/i')*G. It is emphasized that there is no concept of a single public master key. To provide full access to the list of incoming and outgoing payments, an auditor can be given the master public extended key. This will enable them to view all transactions from and to the wallet in all accounts, but not a single secret key.In an email to himself, Michael discusses the private derivation in the BIP and concludes that it is intentional. He explains that while (m/i/j/k)*G = (M/i/j/k), (m/i'/j/k)*G does not equal (M/i/j/k) and results in an error. However, ((m/i')*G)/j/k = (m/i'/j/k)*G. Michael believes that the private derivation is motivated by the desire to avoid revealing known values like K, c, and k_i since they could lead to the discovery of other values as well. He expresses concern that many people may fall into this trap.In an email to Pieter, Michael expresses his concerns about BIP0032 and the equations used for private and public derivation. He notes that there can only be one HMAC function used for both types of derivation. After analyzing the formulas for private derivation, he finds that they result in K_i = k_i*G = I_L*G + k_par(mod n)*G. However, the formula for public derivation results in K_i = (I_L+k_par)*G = I_L*G + K_par, which is not the same as the previous formula. To address this, Michael suggests changing the private child key derivation to CDK((k_par, c_par), i) -> (k_i, c_i), where I = HMACSHA512(c_par, X(k_par*G)||i). He proposes splitting I into I_L and I_R (256 bits each), resulting in k_i = k_par + I_L and c_i = I_R. For pure public derivation, where the private key is not known, Michael suggests using CDK'((K_par, c_par), i) -> (K_i, c_i), where I = HMACSHA512(c_par, X(K_par)||i). He explains that by splitting I into I_L and I_R, K_i = K_par + I_L*G (= k_par*G + I_L*G = (k_par+I_L)*G = k_i*G), and c_i = I_R. These changes ensure the right properties and equal c_i values for both types of derivation.Overall, these discussions highlight the complexities and considerations involved in implementing BIP 32 and emphasize the importance of using proper terminology and equations to avoid confusion and potential security risks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_BIP21-bitcoin-URIs-and-HTML5.xml b/static/bitcoin-dev/May_2013/combined_BIP21-bitcoin-URIs-and-HTML5.xml index 1165d1d094..f1083d07b0 100644 --- a/static/bitcoin-dev/May_2013/combined_BIP21-bitcoin-URIs-and-HTML5.xml +++ b/static/bitcoin-dev/May_2013/combined_BIP21-bitcoin-URIs-and-HTML5.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP21 bitcoin URIs and HTML5 - 2023-08-01T04:42:27.320613+00:00 + 2025-10-11T21:32:51.791914+00:00 + python-feedgen Mike Hearn 2013-05-02 12:53:38+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - BIP21 bitcoin URIs and HTML5 - 2023-08-01T04:42:27.320613+00:00 + 2025-10-11T21:32:51.792054+00:00 - In an email conversation on April 24, 2013, Gavin Andresen and Ian discussed errors in the BIP21 spec for bitcoin: URIs. Gavin inquired about the process for amending the BIP and suggested fixing the issues without creating a new one. This approach was supported by Gregory Maxwell, as long as the corrections were not gratuitously incompatible.HTML5 now allows web apps to register themselves for handling URI schemes, including the bitcoin: URI used in the payment protocol. However, there is a whitelist of acceptable schemes for security reasons. The good news is that bitcoin has been added to the whitelist by Hixie, and browsers should soon be able to accept bitcoin as a web-app handleable protocol scheme.Ian identified errors in the BIP21 spec, including missing character set definition, undefined separator, incorrect syntax, and referencing "pchar" without definition. The process for amending the BIP was questioned, with suggestions of creating a new BIP or fixing the errors in place due to their exotic nature. No consensus has been reached yet.Additionally, the IETF URL specs are being replaced by http://url.spec.whatwg.org/ for Web purposes. Improvement of the URL spec is encouraged, as it is important for the value proposition of the Web. 2013-05-02T12:53:38+00:00 + In an email conversation on April 24, 2013, Gavin Andresen and Ian discussed errors in the BIP21 spec for bitcoin: URIs. Gavin inquired about the process for amending the BIP and suggested fixing the issues without creating a new one. This approach was supported by Gregory Maxwell, as long as the corrections were not gratuitously incompatible.HTML5 now allows web apps to register themselves for handling URI schemes, including the bitcoin: URI used in the payment protocol. However, there is a whitelist of acceptable schemes for security reasons. The good news is that bitcoin has been added to the whitelist by Hixie, and browsers should soon be able to accept bitcoin as a web-app handleable protocol scheme.Ian identified errors in the BIP21 spec, including missing character set definition, undefined separator, incorrect syntax, and referencing "pchar" without definition. The process for amending the BIP was questioned, with suggestions of creating a new BIP or fixing the errors in place due to their exotic nature. No consensus has been reached yet.Additionally, the IETF URL specs are being replaced by http://url.spec.whatwg.org/ for Web purposes. Improvement of the URL spec is encouraged, as it is important for the value proposition of the Web. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Bitcoin2013-Speakers-Include-your-PGP-fingerprint-in-your-slides.xml b/static/bitcoin-dev/May_2013/combined_Bitcoin2013-Speakers-Include-your-PGP-fingerprint-in-your-slides.xml index b122590ec3..be8f1bdfce 100644 --- a/static/bitcoin-dev/May_2013/combined_Bitcoin2013-Speakers-Include-your-PGP-fingerprint-in-your-slides.xml +++ b/static/bitcoin-dev/May_2013/combined_Bitcoin2013-Speakers-Include-your-PGP-fingerprint-in-your-slides.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin2013 Speakers: Include your PGP fingerprint in your slides - 2023-08-01T04:53:13.583073+00:00 + 2025-10-11T21:33:42.776991+00:00 + python-feedgen Adam Back 2013-05-14 20:12:32+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Bitcoin2013 Speakers: Include your PGP fingerprint in your slides - 2023-08-01T04:53:13.584072+00:00 + 2025-10-11T21:33:42.777121+00:00 - In a discussion on May 14, 2013, it was shared that encryption keys can be stored as a TXT entry on one's own domain by using the command "dig +short harald._pka.schil.ly. TXT". This method can also be used automatically through the command "$ gpg ... --auto-key-locate pka -r email at address.domain". However, concerns were raised about the security of DNS, suggesting that this may not be the most secure way to store encryption keys.In an email conversation from 2013, it was asked if PGP key servers could suffer from a 51% attack similar to the Bitcoin network. Unlike Bitcoin, PGP keyservers are not reliant on mining power, so a 51% attack would not be possible in that sense. However, PGP keyservers are vulnerable to spamming, which can cause clients to become unresponsive or crash. Storing PGP keys as a TXT entry on one's own domain and using them automatically can help mitigate this risk and avoid relying on PGP keyservers.On May 14, 2013, it was mentioned that using a hardware smartcard to store PGP keys is a security measure taken seriously. Keeping the master signing key separate from day-to-day signing subkeys is also practiced. Regularly PGP signing emails allows anyone to verify if they have the correct key by checking the signatures in the mailing list archives. However, it was acknowledged that a dedicated attacker could potentially sign something without the owner's knowledge.In terms of security measures, using PGP fingerprints in talks and presentations was discussed as a way to ensure validity. While there is a possibility of fraud, the wide audiences and opportunities for detection make it reasonable to use PGP fingerprints in slides. The importance of the web-of-trust in PGP verification was emphasized, stating that multiple verifications contribute to ensuring validity. Better code signing practices are also necessary, but it is important to ensure the keys signing the code are valid. Using a hardware smartcard to store PGP keys and separating the master signing key from day-to-day signing subkeys were mentioned as personal security measures.A writer on bitcointalk.org suggested adding PGP fingerprints to presentation slides to improve security during talks. Although there is a risk of fraud, the benefits of a wide audience and greater opportunities for detection outweigh this concern. The importance of the web-of-trust in PGP verification was highlighted, and the use of SSL and certificate authorities alongside PGP WoT to enhance code signing practices was advocated. Personal security measures included using a hardware smartcard to store PGP keys and keeping the master signing key separate from day-to-day signing subkeys. 2013-05-14T20:12:32+00:00 + In a discussion on May 14, 2013, it was shared that encryption keys can be stored as a TXT entry on one's own domain by using the command "dig +short harald._pka.schil.ly. TXT". This method can also be used automatically through the command "$ gpg ... --auto-key-locate pka -r email at address.domain". However, concerns were raised about the security of DNS, suggesting that this may not be the most secure way to store encryption keys.In an email conversation from 2013, it was asked if PGP key servers could suffer from a 51% attack similar to the Bitcoin network. Unlike Bitcoin, PGP keyservers are not reliant on mining power, so a 51% attack would not be possible in that sense. However, PGP keyservers are vulnerable to spamming, which can cause clients to become unresponsive or crash. Storing PGP keys as a TXT entry on one's own domain and using them automatically can help mitigate this risk and avoid relying on PGP keyservers.On May 14, 2013, it was mentioned that using a hardware smartcard to store PGP keys is a security measure taken seriously. Keeping the master signing key separate from day-to-day signing subkeys is also practiced. Regularly PGP signing emails allows anyone to verify if they have the correct key by checking the signatures in the mailing list archives. However, it was acknowledged that a dedicated attacker could potentially sign something without the owner's knowledge.In terms of security measures, using PGP fingerprints in talks and presentations was discussed as a way to ensure validity. While there is a possibility of fraud, the wide audiences and opportunities for detection make it reasonable to use PGP fingerprints in slides. The importance of the web-of-trust in PGP verification was emphasized, stating that multiple verifications contribute to ensuring validity. Better code signing practices are also necessary, but it is important to ensure the keys signing the code are valid. Using a hardware smartcard to store PGP keys and separating the master signing key from day-to-day signing subkeys were mentioned as personal security measures.A writer on bitcointalk.org suggested adding PGP fingerprints to presentation slides to improve security during talks. Although there is a risk of fraud, the benefits of a wide audience and greater opportunities for detection outweigh this concern. The importance of the web-of-trust in PGP verification was highlighted, and the use of SSL and certificate authorities alongside PGP WoT to enhance code signing practices was advocated. Personal security measures included using a hardware smartcard to store PGP keys and keeping the master signing key separate from day-to-day signing subkeys. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Cold-Signing-Payment-Requests.xml b/static/bitcoin-dev/May_2013/combined_Cold-Signing-Payment-Requests.xml index 782b488103..40347754a8 100644 --- a/static/bitcoin-dev/May_2013/combined_Cold-Signing-Payment-Requests.xml +++ b/static/bitcoin-dev/May_2013/combined_Cold-Signing-Payment-Requests.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Cold Signing Payment Requests - 2023-08-01T04:43:53.582572+00:00 + 2025-10-11T21:33:32.145010+00:00 + python-feedgen Peter Todd 2013-05-06 21:29:59+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Cold Signing Payment Requests - 2023-08-01T04:43:53.582572+00:00 + 2025-10-11T21:33:32.145215+00:00 - In a series of email exchanges, discussions surrounding the security and functionality of Bitcoin payment protocols are explored. One concern is the potential risks associated with compromised web servers and the need to protect refund addresses. It is suggested that archiving key documentation on archive.org could help ward off potential patent threats in the future. The challenges faced by merchants regarding missed payments and server vulnerabilities are also discussed.The threat of malware-compromised hosts and the potential redirection of payments is another area of concern. The complexities involved in handling errors during payment posting and the need for secure channels to obtain cryptographic identities are examined. Code review and testing for version updates are highlighted as a bottleneck in the development process. Suggestions are made for protecting pay-to addresses in case of web server compromise, such as using different types of certificates and encoding pubKeys or fingerprints.The limitations of SSL PKI and the challenges of obtaining a more trusted payment request signing key than an SSL key are covered. The difficulties in implementing offline intermediate certificates are also discussed. The proposal to sign payment requests with keys kept offline is considered, with debates on the feasibility and effectiveness of chaining custom certificates onto SSL certificates.Another discussion on bitcointalk.org suggests using x509 certificates to sign Payment Requests to enhance verification and prevent address tampering. However, generating live Payment Requests exposes the signing key to potential theft. A solution is proposed involving a two-tier certificate system, where a 'parent' certificate is kept offline and a 'child' certificate is used for live signing. This approach ensures that the payer can verify the address in the payment request belongs to the intended recipient.To implement this solution, the Payment Protocol utilizes x509 certificates to sign payment requests, allowing wallets to display metadata from the certificate. However, the key used to sign these requests is vulnerable to theft. To mitigate this risk, the proposed two-tier certificate system is explained, where the parent certificate is kept offline and the child certificate is used for live signing on the payment server.While this solution offers improved security, there is a need for established conventions to identify which certificate is the 'most trusted' and which is the 'less trusted'. Alternative ideas are needed for better identification. However, if merchants can keep the key used for signing the address offline, several benefits can be gained, such as enhanced verification and protection against address tampering. 2013-05-06T21:29:59+00:00 + In a series of email exchanges, discussions surrounding the security and functionality of Bitcoin payment protocols are explored. One concern is the potential risks associated with compromised web servers and the need to protect refund addresses. It is suggested that archiving key documentation on archive.org could help ward off potential patent threats in the future. The challenges faced by merchants regarding missed payments and server vulnerabilities are also discussed.The threat of malware-compromised hosts and the potential redirection of payments is another area of concern. The complexities involved in handling errors during payment posting and the need for secure channels to obtain cryptographic identities are examined. Code review and testing for version updates are highlighted as a bottleneck in the development process. Suggestions are made for protecting pay-to addresses in case of web server compromise, such as using different types of certificates and encoding pubKeys or fingerprints.The limitations of SSL PKI and the challenges of obtaining a more trusted payment request signing key than an SSL key are covered. The difficulties in implementing offline intermediate certificates are also discussed. The proposal to sign payment requests with keys kept offline is considered, with debates on the feasibility and effectiveness of chaining custom certificates onto SSL certificates.Another discussion on bitcointalk.org suggests using x509 certificates to sign Payment Requests to enhance verification and prevent address tampering. However, generating live Payment Requests exposes the signing key to potential theft. A solution is proposed involving a two-tier certificate system, where a 'parent' certificate is kept offline and a 'child' certificate is used for live signing. This approach ensures that the payer can verify the address in the payment request belongs to the intended recipient.To implement this solution, the Payment Protocol utilizes x509 certificates to sign payment requests, allowing wallets to display metadata from the certificate. However, the key used to sign these requests is vulnerable to theft. To mitigate this risk, the proposed two-tier certificate system is explained, where the parent certificate is kept offline and the child certificate is used for live signing on the payment server.While this solution offers improved security, there is a need for established conventions to identify which certificate is the 'most trusted' and which is the 'less trusted'. Alternative ideas are needed for better identification. However, if merchants can keep the key used for signing the address offline, several benefits can be gained, such as enhanced verification and protection against address tampering. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Decentralizing-mining.xml b/static/bitcoin-dev/May_2013/combined_Decentralizing-mining.xml index c12b5ffaf2..da501169ab 100644 --- a/static/bitcoin-dev/May_2013/combined_Decentralizing-mining.xml +++ b/static/bitcoin-dev/May_2013/combined_Decentralizing-mining.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Decentralizing mining - 2023-08-01T05:04:22.409640+00:00 + 2025-10-11T21:33:06.660010+00:00 + python-feedgen Peter Todd 2013-06-17 17:39:42+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Decentralizing mining - 2023-08-01T05:04:22.409640+00:00 + 2025-10-11T21:33:06.660153+00:00 - The email thread discusses proposals for improving the prioritization of transactions in Bitcoin mining. One suggestion is to delay broadcasting INV messages until child transactions with higher fees are found. Another proposal is to include fee/kb information in INV advertisements sent to peers. The discussion also addresses the suboptimal way new blocks are communicated to peers and suggests prioritizing fast peers and investigating the network-wide costs of broadcasting block header + coinbase TX + TX list to opt-in miners.In a conversation between Peter Todd and Luke-Jr, they discuss the practice of using one share per second in pools, suggesting higher difficulty shares instead. They also discuss P2Pool-like solutions where only a subset of shares are sent to the pool. The importance of auditing and troubleshooting in mining operations is mentioned, as well as eliopool's ability to accept arbitrary shares and possible protocol extensions.To reduce bandwidth in mining, suggestions include sending only the block header for normal shares and randomly auditing a subset of transactions. The possibility of using higher difficulty shares that are audited is also discussed. The discussion emphasizes the need for proper prioritization and fee/kb information in INV advertisements. It is recommended to sort peer lists based on #inv-received/time for optimal flood-fill/gossip algorithms.Peter Todd's ideas for pooled mining and solo mining implementation involve making two connections - to the pool and a local bitcoind. Miners work on the subset of transactions common to both getblocktemplate and the local one. Shares that don't meet difficulty are handed over to the pool, while shares that meet difficulty are handed over to both the pool and the local bitcoind. Suggestions are made to optimize this process by handing over transaction hashes where possible. Bandwidth reduction suggestions include passing only the block header for normal shares and randomly auditing a subset of transactions.The email dated June 10, 2013, discusses the protocol work for miners, focusing on the connections between the miner, pool, and local bitcoind. The process of working on common transaction subsets and handing over shares based on difficulty is explained. Suggestions are made to reduce bandwidth by passing only the block header for normal shares and randomly auditing a subset of transactions. The intentional orphaning of slow-to-propagate blocks is also mentioned. The email discusses possible protocol extensions and the need for code to merge block templates together.The pooled-solo mining mode is introduced as a concept where miners run a local bitcoin node to construct blocks while the pool tracks shares and organizes payouts. This aims to decentralize power and protect against pool hacking. Technical requirements and possible protocol extensions are discussed.A post by Peter Todd on bitcointalk highlights the need for change in Bitcoin mining practices. Pooled-solo mining is proposed as a solution to give more power to individual miners and protect against pool hacks. The concept involves miners running a local Bitcoin node to construct blocks, while the pool handles share tracking and payouts. Todd plans to fund a developer to make this idea a reality under Keep Bitcoin Free's next project. 2013-06-17T17:39:42+00:00 + The email thread discusses proposals for improving the prioritization of transactions in Bitcoin mining. One suggestion is to delay broadcasting INV messages until child transactions with higher fees are found. Another proposal is to include fee/kb information in INV advertisements sent to peers. The discussion also addresses the suboptimal way new blocks are communicated to peers and suggests prioritizing fast peers and investigating the network-wide costs of broadcasting block header + coinbase TX + TX list to opt-in miners.In a conversation between Peter Todd and Luke-Jr, they discuss the practice of using one share per second in pools, suggesting higher difficulty shares instead. They also discuss P2Pool-like solutions where only a subset of shares are sent to the pool. The importance of auditing and troubleshooting in mining operations is mentioned, as well as eliopool's ability to accept arbitrary shares and possible protocol extensions.To reduce bandwidth in mining, suggestions include sending only the block header for normal shares and randomly auditing a subset of transactions. The possibility of using higher difficulty shares that are audited is also discussed. The discussion emphasizes the need for proper prioritization and fee/kb information in INV advertisements. It is recommended to sort peer lists based on #inv-received/time for optimal flood-fill/gossip algorithms.Peter Todd's ideas for pooled mining and solo mining implementation involve making two connections - to the pool and a local bitcoind. Miners work on the subset of transactions common to both getblocktemplate and the local one. Shares that don't meet difficulty are handed over to the pool, while shares that meet difficulty are handed over to both the pool and the local bitcoind. Suggestions are made to optimize this process by handing over transaction hashes where possible. Bandwidth reduction suggestions include passing only the block header for normal shares and randomly auditing a subset of transactions.The email dated June 10, 2013, discusses the protocol work for miners, focusing on the connections between the miner, pool, and local bitcoind. The process of working on common transaction subsets and handing over shares based on difficulty is explained. Suggestions are made to reduce bandwidth by passing only the block header for normal shares and randomly auditing a subset of transactions. The intentional orphaning of slow-to-propagate blocks is also mentioned. The email discusses possible protocol extensions and the need for code to merge block templates together.The pooled-solo mining mode is introduced as a concept where miners run a local bitcoin node to construct blocks while the pool tracks shares and organizes payouts. This aims to decentralize power and protect against pool hacking. Technical requirements and possible protocol extensions are discussed.A post by Peter Todd on bitcointalk highlights the need for change in Bitcoin mining practices. Pooled-solo mining is proposed as a solution to give more power to individual miners and protect against pool hacks. The concept involves miners running a local Bitcoin node to construct blocks, while the pool handles share tracking and payouts. Todd plans to fund a developer to make this idea a reality under Keep Bitcoin Free's next project. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Discovery-addr-packets-was-Service-bits-for-pruned-nodes-.xml b/static/bitcoin-dev/May_2013/combined_Discovery-addr-packets-was-Service-bits-for-pruned-nodes-.xml index 00f6a05381..a4942aa11a 100644 --- a/static/bitcoin-dev/May_2013/combined_Discovery-addr-packets-was-Service-bits-for-pruned-nodes-.xml +++ b/static/bitcoin-dev/May_2013/combined_Discovery-addr-packets-was-Service-bits-for-pruned-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Discovery/addr packets (was: Service bits for pruned nodes) - 2023-08-01T04:49:38.079464+00:00 + 2025-10-11T21:33:17.279975+00:00 + python-feedgen John Dillon 2013-05-09 00:57:42+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Discovery/addr packets (was: Service bits for pruned nodes) - 2023-08-01T04:49:38.080408+00:00 + 2025-10-11T21:33:17.280185+00:00 - In a discussion about the usefulness of the blockchain, it has been argued that there are transactions which do not require its double-spend protection. For example, when Facebook bought Instagram or when an employer pays an employee their salary, the legal system is enough to ensure payments are honored. Small payments may also not benefit from the blockchain if the cost of double spending exceeds what the payment is worth. However, for large transactions that are not big enough to justify expensive cross-jurisdictional legal action or where identity verification costs are too high, the blockchain is valuable. In most online transactions today, the blockchain falls within this category.The conversation also delves into various ways to improve the accountability and security of the Bitcoin network. Suggestions include making node identities expensive to obtain, implementing SSL transport for secure peer communication, and creating reputations for nodes based on their reliability and trustworthiness. Non-repudiation is seen as a valuable feature to tie reputation to good behavior, although its implementation at the protocol level is debated. The importance of considering different security measures and their potential implications in the development of protocols like Bitcoin is emphasized.There are also discussions about the vulnerability of the Bitcoin network to network attacks that can induce network splits and lower difficulty to trick a local area of the network into accepting an orphan branch as the true block chain. To protect against such attacks, discovering peers through multiple network routes and steganographic protocols is suggested. Implementing SSL encryption for connections is recommended, but it is noted that SSL alone does not provide non-repudiation. The concept of per-node identity keypairs is proposed as a step towards non-repudiation, although caution is needed to avoid deanonymizing use over Tor. Overall, the conversations highlight the ongoing efforts to enhance the security and effectiveness of the Bitcoin network.In a discussion between Bitcoin developers Peter Todd, Jeff Garzik, and Mike Hearn, various suggestions are made to improve the security and privacy of Bitcoin transactions.Peter Todd recommends working with The Guardian Project to implement Tor on Android phones for improved privacy. He also suggests using torchat, which bundles a special tor build and runs a hidden service.Jeff Garzik agrees with implementing an internal Tor hidden service node for secure communication, stating that it would be more secure than a proxy server approach in certain scenarios.Mike Hearn proposes several ideas to enhance transaction security. He suggests making it clear in the user interface that payments from untrusted sources should not be accepted when connected to WiFi. He also recommends establishing end-to-end encryption through Tor or another method of obfuscation. Additionally, he suggests adding keys to nodes and implementing a protocol message that asks the node to sign the accumulated hash of messages sent on a connection.The conversation also touches on the security of DNS seeds in the Bitcoinj implementation. Garzik suggests selecting peers from a wider pool to reduce effort and notes that Bitcoinj needs fixing regarding over-reliance on DNS seeds. He proposes encrypting and signing node-to-node communication and having seeds return the pubkey for communication.Issues related to delays in finding peers on Android phones and optimizing performance are discussed. Peter Todd suggests using dedicated nodes backed by fast hardware for faster startup. He also proposes discouraging non-Simplified Payment Verification (SPV) use by refusing to relay full blocks. Todd suggests vouching for trusted special servers with SSL certificates. Mike Hearn highlights the weaker security of SPV nodes compared to full nodes and suggests building better SPV-specific systems with dedicated nodes. He believes this could improve security and suggests having trusted individuals vouch for these servers. He acknowledges the challenges of moving away from DNS seeding for SPV clients due to sensitivity to startup time.Overall, the discussions focus on improving privacy, security, and performance in Bitcoin transactions through the implementation of Tor, encryption, signing, and careful selection of peers. 2013-05-09T00:57:42+00:00 + In a discussion about the usefulness of the blockchain, it has been argued that there are transactions which do not require its double-spend protection. For example, when Facebook bought Instagram or when an employer pays an employee their salary, the legal system is enough to ensure payments are honored. Small payments may also not benefit from the blockchain if the cost of double spending exceeds what the payment is worth. However, for large transactions that are not big enough to justify expensive cross-jurisdictional legal action or where identity verification costs are too high, the blockchain is valuable. In most online transactions today, the blockchain falls within this category.The conversation also delves into various ways to improve the accountability and security of the Bitcoin network. Suggestions include making node identities expensive to obtain, implementing SSL transport for secure peer communication, and creating reputations for nodes based on their reliability and trustworthiness. Non-repudiation is seen as a valuable feature to tie reputation to good behavior, although its implementation at the protocol level is debated. The importance of considering different security measures and their potential implications in the development of protocols like Bitcoin is emphasized.There are also discussions about the vulnerability of the Bitcoin network to network attacks that can induce network splits and lower difficulty to trick a local area of the network into accepting an orphan branch as the true block chain. To protect against such attacks, discovering peers through multiple network routes and steganographic protocols is suggested. Implementing SSL encryption for connections is recommended, but it is noted that SSL alone does not provide non-repudiation. The concept of per-node identity keypairs is proposed as a step towards non-repudiation, although caution is needed to avoid deanonymizing use over Tor. Overall, the conversations highlight the ongoing efforts to enhance the security and effectiveness of the Bitcoin network.In a discussion between Bitcoin developers Peter Todd, Jeff Garzik, and Mike Hearn, various suggestions are made to improve the security and privacy of Bitcoin transactions.Peter Todd recommends working with The Guardian Project to implement Tor on Android phones for improved privacy. He also suggests using torchat, which bundles a special tor build and runs a hidden service.Jeff Garzik agrees with implementing an internal Tor hidden service node for secure communication, stating that it would be more secure than a proxy server approach in certain scenarios.Mike Hearn proposes several ideas to enhance transaction security. He suggests making it clear in the user interface that payments from untrusted sources should not be accepted when connected to WiFi. He also recommends establishing end-to-end encryption through Tor or another method of obfuscation. Additionally, he suggests adding keys to nodes and implementing a protocol message that asks the node to sign the accumulated hash of messages sent on a connection.The conversation also touches on the security of DNS seeds in the Bitcoinj implementation. Garzik suggests selecting peers from a wider pool to reduce effort and notes that Bitcoinj needs fixing regarding over-reliance on DNS seeds. He proposes encrypting and signing node-to-node communication and having seeds return the pubkey for communication.Issues related to delays in finding peers on Android phones and optimizing performance are discussed. Peter Todd suggests using dedicated nodes backed by fast hardware for faster startup. He also proposes discouraging non-Simplified Payment Verification (SPV) use by refusing to relay full blocks. Todd suggests vouching for trusted special servers with SSL certificates. Mike Hearn highlights the weaker security of SPV nodes compared to full nodes and suggests building better SPV-specific systems with dedicated nodes. He believes this could improve security and suggests having trusted individuals vouch for these servers. He acknowledges the challenges of moving away from DNS seeding for SPV clients due to sensitivity to startup time.Overall, the discussions focus on improving privacy, security, and performance in Bitcoin transactions through the implementation of Tor, encryption, signing, and careful selection of peers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Double-Spend-Notification.xml b/static/bitcoin-dev/May_2013/combined_Double-Spend-Notification.xml index 70c5fd74b5..7795e32934 100644 --- a/static/bitcoin-dev/May_2013/combined_Double-Spend-Notification.xml +++ b/static/bitcoin-dev/May_2013/combined_Double-Spend-Notification.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Double Spend Notification - 2023-08-01T05:00:35.406465+00:00 + 2025-10-11T21:33:47.020296+00:00 + python-feedgen Quinn Harris 2013-05-21 16:47:59+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Double Spend Notification - 2023-08-01T05:00:35.406465+00:00 + 2025-10-11T21:33:47.020530+00:00 - The discussion on the Bitcoin-development mailing list in 2013 focused on the issue of double-spend attacks on 0-confirmation payments in the Bitcoin network. One proposal suggested making 0-conf double spends trivial by considering a later transaction with a larger fee as valid and dropping the first one if it hasn't been confirmed. However, no decision had been made at the time.Pieter Wuille expressed skepticism about this proposal and believed that double spend notifications were a better solution. The mailing list was seen as an important resource for staying informed about the latest developments in the Bitcoin network.Robert Backhaus suggested that a decision had been made to make 0-conf double spends trivial, but Pieter Wuille replied stating that he was not aware of such a decision. The suggested solution was to consider a later transaction with a larger fee as valid and drop the first one if it hadn't been confirmed.The current implementation of Bitcoin is vulnerable to double spend attacks for 0 confirmation payments, which are necessary for in-person transactions. This vulnerability allows two transactions from the same output to be transmitted simultaneously, resulting in different nodes receiving different transactions.To address this issue, a new double spend message should be sent with proof of the double spend but not the complete transactions. This would promptly notify the receiving end of a double spend without increasing the likelihood of a successful double spend.However, over time, this solution may become less effective as transaction fees become a more significant part of the mining reward. Therefore, it is important to work towards more robust solutions, such as tamper-resistant devices, third-party certificates, or multi-signature transactions involving trusted third parties.While implementing a double spend notification would make double spends more costly for most cases, it is necessary to continue striving for more secure solutions. It is crucial to explore and implement more robust solutions, particularly those involving third-party trust mechanisms, to ensure the long-term security and reliability of the Bitcoin system. 2013-05-21T16:47:59+00:00 + The discussion on the Bitcoin-development mailing list in 2013 focused on the issue of double-spend attacks on 0-confirmation payments in the Bitcoin network. One proposal suggested making 0-conf double spends trivial by considering a later transaction with a larger fee as valid and dropping the first one if it hasn't been confirmed. However, no decision had been made at the time.Pieter Wuille expressed skepticism about this proposal and believed that double spend notifications were a better solution. The mailing list was seen as an important resource for staying informed about the latest developments in the Bitcoin network.Robert Backhaus suggested that a decision had been made to make 0-conf double spends trivial, but Pieter Wuille replied stating that he was not aware of such a decision. The suggested solution was to consider a later transaction with a larger fee as valid and drop the first one if it hadn't been confirmed.The current implementation of Bitcoin is vulnerable to double spend attacks for 0 confirmation payments, which are necessary for in-person transactions. This vulnerability allows two transactions from the same output to be transmitted simultaneously, resulting in different nodes receiving different transactions.To address this issue, a new double spend message should be sent with proof of the double spend but not the complete transactions. This would promptly notify the receiving end of a double spend without increasing the likelihood of a successful double spend.However, over time, this solution may become less effective as transaction fees become a more significant part of the mining reward. Therefore, it is important to work towards more robust solutions, such as tamper-resistant devices, third-party certificates, or multi-signature transactions involving trusted third parties.While implementing a double spend notification would make double spends more costly for most cases, it is necessary to continue striving for more secure solutions. It is crucial to explore and implement more robust solutions, particularly those involving third-party trust mechanisms, to ensure the long-term security and reliability of the Bitcoin system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Fwd-Service-bits-for-pruned-nodes.xml b/static/bitcoin-dev/May_2013/combined_Fwd-Service-bits-for-pruned-nodes.xml index 143a5a68f0..2c854e1f1d 100644 --- a/static/bitcoin-dev/May_2013/combined_Fwd-Service-bits-for-pruned-nodes.xml +++ b/static/bitcoin-dev/May_2013/combined_Fwd-Service-bits-for-pruned-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Service bits for pruned nodes - 2023-08-01T04:47:47.414158+00:00 + 2025-10-11T21:33:19.403698+00:00 + python-feedgen Andy Parkins 2013-05-01 14:34:27+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Fwd: Service bits for pruned nodes - 2023-08-01T04:47:47.414158+00:00 + 2025-10-11T21:33:19.403876+00:00 - On May 1, 2013, Jeff Garzik proposed the idea of a generalized HTTP REST query protocol in an email. He acknowledged that it was off-topic for the current thread but suggested discussing it separately. In the same email, he provided a link to a pull request he wrote for an HTTP REST interface that downloads an encrypted wallet backup. Dr. Andy Parkins responded to Garzik's email, expressing his belief that Garzik was behind the state-of-the-art and should trust the development team's plans. They then discussed the storage format for Bitcoin protocol blocks. Garzik argued for storing blocks in their native P2P wire protocol format, while Parkins suggested parsing and separating blocks into database fields instead of duplicating bitcoind. Garzik noted that Parkins' proposal would require expanding blocks from their native form into a larger form, which would be extra work for clients downloading blocks. Garzik also mentioned that they had previously discussed an HTTP query interface as a separate topic.In another email thread, Garzik defended the storage format of Bitcoin protocol blocks, stating that it was the most efficient and supported format for multiple applications. A member of the group proposed adding support for more Bitcoin-protocol-oriented HTTP requests to allow any client to supply the same interface. Garzik disagreed, saying that this would require a whole new client interface and was outside the scope of an efficient HTTP protocol for downloading blocks. The member then suggested adding another thread listening for HTTP requests, but Garzik disagreed again.Garzik and Parkins had a conversation about the storage format for Bitcoin protocol blocks. Garzik suggested using the format currently used by bitcoind, arguing that it was a generic format supported in multiple applications. Parkins felt this was too specific to bitcoind and proposed supporting more bitcoin-protocol-oriented HTTP requests. He suggested using URLs for block, transaction, orphaned transaction, peers, and peer requests. Garzik responded that Parkins' proposal was closer to a full P2P rewrite over HTTP or a proxy thereof. They also discussed finding the ideal domain name for caching content and enhancing bitcoind to respond to HTTP.On April 30, 2013, Garzik suggested using the format currently used by bitcoind for raw data storage. He recommended adding a small metadata download and serving raw block files. Parkins disagreed, stating that this approach was not generic and too closely tied to bitcoind's current storage format. Instead, he proposed adding support for more bitcoin-protocol-oriented HTTP requests. This would create a block explorer's raw mode in every bitcoind, making it easier for light clients to find the block containing a particular transaction. Parkins also requested support for HTTP POST/PUT of signed transactions and block announcements.In response to a suggestion for an HTTP/HTTPS protocol for block downloading, Garzik expressed support for finding new ways to store and transmit blocks. However, he mentioned issues with large files when using HTTP and emphasized the need for well-defined HTTP-retrievable layout with proper headers for web caches to function properly. Garzik suggested using bitcoind's format for raw data, limiting the size to below 1GB, and adding a small metadata download to serve the raw block files. 2013-05-01T14:34:27+00:00 + On May 1, 2013, Jeff Garzik proposed the idea of a generalized HTTP REST query protocol in an email. He acknowledged that it was off-topic for the current thread but suggested discussing it separately. In the same email, he provided a link to a pull request he wrote for an HTTP REST interface that downloads an encrypted wallet backup. Dr. Andy Parkins responded to Garzik's email, expressing his belief that Garzik was behind the state-of-the-art and should trust the development team's plans. They then discussed the storage format for Bitcoin protocol blocks. Garzik argued for storing blocks in their native P2P wire protocol format, while Parkins suggested parsing and separating blocks into database fields instead of duplicating bitcoind. Garzik noted that Parkins' proposal would require expanding blocks from their native form into a larger form, which would be extra work for clients downloading blocks. Garzik also mentioned that they had previously discussed an HTTP query interface as a separate topic.In another email thread, Garzik defended the storage format of Bitcoin protocol blocks, stating that it was the most efficient and supported format for multiple applications. A member of the group proposed adding support for more Bitcoin-protocol-oriented HTTP requests to allow any client to supply the same interface. Garzik disagreed, saying that this would require a whole new client interface and was outside the scope of an efficient HTTP protocol for downloading blocks. The member then suggested adding another thread listening for HTTP requests, but Garzik disagreed again.Garzik and Parkins had a conversation about the storage format for Bitcoin protocol blocks. Garzik suggested using the format currently used by bitcoind, arguing that it was a generic format supported in multiple applications. Parkins felt this was too specific to bitcoind and proposed supporting more bitcoin-protocol-oriented HTTP requests. He suggested using URLs for block, transaction, orphaned transaction, peers, and peer requests. Garzik responded that Parkins' proposal was closer to a full P2P rewrite over HTTP or a proxy thereof. They also discussed finding the ideal domain name for caching content and enhancing bitcoind to respond to HTTP.On April 30, 2013, Garzik suggested using the format currently used by bitcoind for raw data storage. He recommended adding a small metadata download and serving raw block files. Parkins disagreed, stating that this approach was not generic and too closely tied to bitcoind's current storage format. Instead, he proposed adding support for more bitcoin-protocol-oriented HTTP requests. This would create a block explorer's raw mode in every bitcoind, making it easier for light clients to find the block containing a particular transaction. Parkins also requested support for HTTP POST/PUT of signed transactions and block announcements.In response to a suggestion for an HTTP/HTTPS protocol for block downloading, Garzik expressed support for finding new ways to store and transmit blocks. However, he mentioned issues with large files when using HTTP and emphasized the need for well-defined HTTP-retrievable layout with proper headers for web caches to function properly. Garzik suggested using bitcoind's format for raw data, limiting the size to below 1GB, and adding a small metadata download to serve the raw block files. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Implementing-batch-processing-for-blocknotify.xml b/static/bitcoin-dev/May_2013/combined_Implementing-batch-processing-for-blocknotify.xml index d96ffa2528..000dbc1b24 100644 --- a/static/bitcoin-dev/May_2013/combined_Implementing-batch-processing-for-blocknotify.xml +++ b/static/bitcoin-dev/May_2013/combined_Implementing-batch-processing-for-blocknotify.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Implementing batch processing for -blocknotify - 2023-08-01T05:03:45.193163+00:00 + 2025-10-11T21:33:13.033602+00:00 + python-feedgen Rune Kjær Svendsen 2013-06-01 13:12:32+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Implementing batch processing for -blocknotify - 2023-08-01T05:03:45.193163+00:00 + 2025-10-11T21:33:13.033777+00:00 - In a discussion about high-speed notifications, Wladimir suggests using zmq and shares a pull request to integrate it into bitcoind. Chris Double, who has already integrated zmq for block notifications in bitcoin and alt coins, expresses interest in trying it out. Rune decides to go with the Unix socket method and expresses a desire to learn more about Unix sockets.On June 1, 2013, Wladimir suggests that using ZMQ would be ideal for high-speed notifications. He shares a pull request to integrate ZMQ directly into Bitcoind, eliminating the need for the -blocknotify flag. Chris, who has experience integrating ZMQ, offers to test the patch in the pull request.In a discussion on the Bitcoin-development mailing list, Chris mentions that he uses zmq for queuing outside of bitcoind to receive notifications. Wladimir suggests integrating zmq directly into bitcoind through a pull request on Github. Other members of the thread agree with Chris's approach of queuing outside of bitcoind. The thread also includes an advertisement for AppDynamics Lite, a free troubleshooting tool for Java/.NET code.Rune seeks a solution to the issue of his application not being fast enough to finish its work before a new block is received and processed. Suggestions include queuing outside of bitcoind and using zeromq for notifications. Jeff Garzik argues that updating bitcoind for this reason is not necessary as most systems can process a block before another one arrives.In May 2013, Rune posts a message outlining an issue with the -blocknotify option in bitcoind. Multiple instances of his application running simultaneously are considered inefficient. A solution involving a new function called -batchblocknotify is proposed, which would handle incoming blocks in batches to prevent resource inefficiency. The author is unsure how to implement this solution.Rune seeks a solution to his application not being fast enough to finish its work before a new block comes in. Suggestions include changing the -blocknotify script to append necessary information to a queue and having a separate script perform the calculations. Rune has concerns about concurrency issues.Rune asks for a solution on how to keep up with new blocks using the -blocknotify option with bitcoind. Michael suggests changing the -blocknotify script to append information to a queue and exit, while a separate script monitors the queue for work. Rune is concerned about concurrency issues and suggests batching together previously queued items.The author of a Bitcoin application wants to keep up with new blocks using the -blocknotify option with bitcoind, but their app isn't fast enough. A proposed solution involves a new function called -batchblocknotify that handles incoming blocks in batches. The author is unsure how to implement it. 2013-06-01T13:12:32+00:00 + In a discussion about high-speed notifications, Wladimir suggests using zmq and shares a pull request to integrate it into bitcoind. Chris Double, who has already integrated zmq for block notifications in bitcoin and alt coins, expresses interest in trying it out. Rune decides to go with the Unix socket method and expresses a desire to learn more about Unix sockets.On June 1, 2013, Wladimir suggests that using ZMQ would be ideal for high-speed notifications. He shares a pull request to integrate ZMQ directly into Bitcoind, eliminating the need for the -blocknotify flag. Chris, who has experience integrating ZMQ, offers to test the patch in the pull request.In a discussion on the Bitcoin-development mailing list, Chris mentions that he uses zmq for queuing outside of bitcoind to receive notifications. Wladimir suggests integrating zmq directly into bitcoind through a pull request on Github. Other members of the thread agree with Chris's approach of queuing outside of bitcoind. The thread also includes an advertisement for AppDynamics Lite, a free troubleshooting tool for Java/.NET code.Rune seeks a solution to the issue of his application not being fast enough to finish its work before a new block is received and processed. Suggestions include queuing outside of bitcoind and using zeromq for notifications. Jeff Garzik argues that updating bitcoind for this reason is not necessary as most systems can process a block before another one arrives.In May 2013, Rune posts a message outlining an issue with the -blocknotify option in bitcoind. Multiple instances of his application running simultaneously are considered inefficient. A solution involving a new function called -batchblocknotify is proposed, which would handle incoming blocks in batches to prevent resource inefficiency. The author is unsure how to implement this solution.Rune seeks a solution to his application not being fast enough to finish its work before a new block comes in. Suggestions include changing the -blocknotify script to append necessary information to a queue and having a separate script perform the calculations. Rune has concerns about concurrency issues.Rune asks for a solution on how to keep up with new blocks using the -blocknotify option with bitcoind. Michael suggests changing the -blocknotify script to append information to a queue and exit, while a separate script monitors the queue for work. Rune is concerned about concurrency issues and suggests batching together previously queued items.The author of a Bitcoin application wants to keep up with new blocks using the -blocknotify option with bitcoind, but their app isn't fast enough. A proposed solution involves a new function called -batchblocknotify that handles incoming blocks in batches. The author is unsure how to implement it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Modularizing-Bitcoin.xml b/static/bitcoin-dev/May_2013/combined_Modularizing-Bitcoin.xml index 91c8026d38..4657b6a111 100644 --- a/static/bitcoin-dev/May_2013/combined_Modularizing-Bitcoin.xml +++ b/static/bitcoin-dev/May_2013/combined_Modularizing-Bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Modularizing Bitcoin - 2023-08-01T04:54:20.891640+00:00 + 2025-10-11T21:33:02.413699+00:00 + python-feedgen Tamas Blummer 2013-05-27 02:57:38+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - Modularizing Bitcoin - 2023-08-01T04:54:20.891640+00:00 + 2025-10-11T21:33:02.413898+00:00 - There is an open source implementation of the Bitcoin protocol called Bits of Proof, launched by Tamás Blummer at the Bitcoin2013 conference. It provides a remote wallet feature and can be found on GitHub. The creator's website offers supporting documentation.In May 2013, there was a discussion about the number of client nodes on the Bitcoin network. Luke Dashjr confirmed that there were approximately 57,000 listening nodes running protocol >= 70001 with a timestamp no older than 24 hours. However, this count didn't include connect-only nodes or non-p2p nodes like Electrum.The proposal to separate the wallet from the node in Bitcoin mining was brought up. This aimed to improve security and flexibility. Electrum had already achieved this separation, but the proposal had some key differences, such as aiming for a decentralized system.Bitcoin Grant organization offered a financial incentive of 500 bitcoins or $500,000 to develop a smarter and more efficient system. The main goal was to separate the wallet from the node to strengthen the system and prevent cancer attacks. The organization welcomed grant proposals and suggestions.Another suggestion was to create a special compiled bitcoind simulator to speed up processing transactions and blocks between virtual nodes. This would require significant additional work but could provide greater confidence in code changes.Bitcoin Grant initiative continued to offer a financial incentive of 500 bitcoins or $500,000 for modularization of the Bitcoin system. The aim was to separate the wallet from the node and increase the node count to prevent cancer attacks. They emphasized the need for tightly written technical requirements and collaboration with developers.There was a discussion about estimating the number of nodes on the Bitcoin network. Estimates varied, with one mentioning around 57,000 nodes, while an email from 2013 suggested it was around 8,000.Bitcoin Grant believed that compensating developers for their work on open source projects was important. They sought to develop a smarter and more efficient system by separating the wallet from the node and increasing the node count. They welcomed feedback, suggestions, and grant proposals.Bitcoin Grant offered 500 bitcoins or $500,000 to developers for modularizing Bitcoin's infrastructure beyond the bloom filter. The goal was to separate the wallet from the node and increase the node count to prevent cancer attacks. They believed in compensating excellent developers and aimed to develop a smarter and more efficient system. Feedback, suggestions, and grant proposals were encouraged. 2013-05-27T02:57:38+00:00 + There is an open source implementation of the Bitcoin protocol called Bits of Proof, launched by Tamás Blummer at the Bitcoin2013 conference. It provides a remote wallet feature and can be found on GitHub. The creator's website offers supporting documentation.In May 2013, there was a discussion about the number of client nodes on the Bitcoin network. Luke Dashjr confirmed that there were approximately 57,000 listening nodes running protocol >= 70001 with a timestamp no older than 24 hours. However, this count didn't include connect-only nodes or non-p2p nodes like Electrum.The proposal to separate the wallet from the node in Bitcoin mining was brought up. This aimed to improve security and flexibility. Electrum had already achieved this separation, but the proposal had some key differences, such as aiming for a decentralized system.Bitcoin Grant organization offered a financial incentive of 500 bitcoins or $500,000 to develop a smarter and more efficient system. The main goal was to separate the wallet from the node to strengthen the system and prevent cancer attacks. The organization welcomed grant proposals and suggestions.Another suggestion was to create a special compiled bitcoind simulator to speed up processing transactions and blocks between virtual nodes. This would require significant additional work but could provide greater confidence in code changes.Bitcoin Grant initiative continued to offer a financial incentive of 500 bitcoins or $500,000 for modularization of the Bitcoin system. The aim was to separate the wallet from the node and increase the node count to prevent cancer attacks. They emphasized the need for tightly written technical requirements and collaboration with developers.There was a discussion about estimating the number of nodes on the Bitcoin network. Estimates varied, with one mentioning around 57,000 nodes, while an email from 2013 suggested it was around 8,000.Bitcoin Grant believed that compensating developers for their work on open source projects was important. They sought to develop a smarter and more efficient system by separating the wallet from the node and increasing the node count. They welcomed feedback, suggestions, and grant proposals.Bitcoin Grant offered 500 bitcoins or $500,000 to developers for modularizing Bitcoin's infrastructure beyond the bloom filter. The goal was to separate the wallet from the node and increase the node count to prevent cancer attacks. They believed in compensating excellent developers and aimed to develop a smarter and more efficient system. Feedback, suggestions, and grant proposals were encouraged. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Requirement-for-relay-field-in-version-packet-protocol-version-70001-.xml b/static/bitcoin-dev/May_2013/combined_Requirement-for-relay-field-in-version-packet-protocol-version-70001-.xml index a29c550d05..4f9d42ccd3 100644 --- a/static/bitcoin-dev/May_2013/combined_Requirement-for-relay-field-in-version-packet-protocol-version-70001-.xml +++ b/static/bitcoin-dev/May_2013/combined_Requirement-for-relay-field-in-version-packet-protocol-version-70001-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Requirement for relay field in version packet (protocol version >= 70001) - 2023-08-01T04:48:39.132340+00:00 + 2025-10-11T21:33:25.775262+00:00 + python-feedgen Mike Hearn 2013-05-06 08:20:01+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Requirement for relay field in version packet (protocol version >= 70001) - 2023-08-01T04:48:39.133341+00:00 + 2025-10-11T21:33:25.775431+00:00 - In May 2013, a question was posted on the Bitcoin-development mailing list by Addy Yeow regarding the relay field in version packets from clients with a protocol version of 70001 or higher. The question referred to the Protocol Specification page on the Bitcoin Wiki, although the context and purpose of the question were unclear. The email also included an advertisement for AppDynamics Lite, a free troubleshooting tool for Java and .NET applications that provides code-level diagnostics for performance bottlenecks. A link was provided to download the tool for free. The email concluded with standard information about the Bitcoin-development mailing list, including the email address and a link to subscribe/unsubscribe.According to the Bitcoin protocol specification, the relay field is required in all version packets sent by clients with a protocol version of 70001 or higher. This information can be found on the Bitcoin Wiki under the protocol specification section. The relay field is a boolean value represented by one byte and is used to indicate whether a node relays transactions after receiving them from other nodes. The Bitcoin protocol is a set of rules and guidelines that govern the operation of the Bitcoin network, including details on transaction verification, block addition to the blockchain, and node communication.The relay field is one of several fields included in the version packet, which is transmitted when two nodes initially connect. Its purpose is to prevent spam and reduce network congestion. If a node receives a transaction but does not intend to relay it, it can set the relay field to false. This signals the sending node to refrain from sending additional transactions to the non-relaying node, thereby conserving network resources. Nodes that do intend to relay transactions should set the relay field to true.It is crucial for clients to adhere to the Bitcoin protocol specification to ensure compatibility with other nodes on the network. Failure to include the relay field in a version packet may result in rejection by nodes running the latest version of the protocol. Thus, developers must stay updated with the latest changes to the Bitcoin protocol and implement them correctly. 2013-05-06T08:20:01+00:00 + In May 2013, a question was posted on the Bitcoin-development mailing list by Addy Yeow regarding the relay field in version packets from clients with a protocol version of 70001 or higher. The question referred to the Protocol Specification page on the Bitcoin Wiki, although the context and purpose of the question were unclear. The email also included an advertisement for AppDynamics Lite, a free troubleshooting tool for Java and .NET applications that provides code-level diagnostics for performance bottlenecks. A link was provided to download the tool for free. The email concluded with standard information about the Bitcoin-development mailing list, including the email address and a link to subscribe/unsubscribe.According to the Bitcoin protocol specification, the relay field is required in all version packets sent by clients with a protocol version of 70001 or higher. This information can be found on the Bitcoin Wiki under the protocol specification section. The relay field is a boolean value represented by one byte and is used to indicate whether a node relays transactions after receiving them from other nodes. The Bitcoin protocol is a set of rules and guidelines that govern the operation of the Bitcoin network, including details on transaction verification, block addition to the blockchain, and node communication.The relay field is one of several fields included in the version packet, which is transmitted when two nodes initially connect. Its purpose is to prevent spam and reduce network congestion. If a node receives a transaction but does not intend to relay it, it can set the relay field to false. This signals the sending node to refrain from sending additional transactions to the non-relaying node, thereby conserving network resources. Nodes that do intend to relay transactions should set the relay field to true.It is crucial for clients to adhere to the Bitcoin protocol specification to ensure compatibility with other nodes on the network. Failure to include the relay field in a version packet may result in rejection by nodes running the latest version of the protocol. Thus, developers must stay updated with the latest changes to the Bitcoin protocol and implement them correctly. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Service-bits-for-pruned-nodes.xml b/static/bitcoin-dev/May_2013/combined_Service-bits-for-pruned-nodes.xml index 9a6a386230..879077a179 100644 --- a/static/bitcoin-dev/May_2013/combined_Service-bits-for-pruned-nodes.xml +++ b/static/bitcoin-dev/May_2013/combined_Service-bits-for-pruned-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Service bits for pruned nodes - 2023-08-01T04:46:14.421991+00:00 + 2025-10-11T21:33:49.144515+00:00 + python-feedgen Ricardo Filipe 2013-05-16 16:23:23+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Service bits for pruned nodes - 2023-08-01T04:46:14.422988+00:00 + 2025-10-11T21:33:49.144702+00:00 - In 2013, discussions were taking place within the Bitcoin network regarding the storage and replication of historic data. One proposal suggested allowing users to choose which parts of the blockchain to store, but concerns were raised about the lack of copies of the data. An alternative suggestion was made to randomly store chunks of data based on available space, prioritizing the "N most recent" chunks for more replicas. However, Jeff Garzik argued against this idea, warning that it could make the blockchain vulnerable to DoS attacks on one part of the Distributed Hash Table (DHT), potentially causing the entire chain to break.Another topic of discussion focused on optimizing peer discovery mechanisms in the Bitcoin network. The current methods, such as DNS seeds, a fixed list, and IRC discovery, were not deemed effective for overall peer discovery. Several alternative means of peer discovery were suggested, including search engines, IPv4 scanning, and anycast peers. Mike Hearn proposed extending the DNS seeding protocol to allow queries that return only nodes matching specific requirements. However, concerns were raised about DNS caching and the risk of sudden traffic influx at one set of nodes if a large ISP caches a response.The concept of pruning nodes, which validate and relay blocks without keeping all historic blocks, was also explored. Pieter Wuille suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. This would ensure synchronization between new and old nodes. Although there was general support for this proposal, potential issues related to snapshotting and UTXO snapshots were raised.The possibility of using BitTorrent technology in the Bitcoin network was considered. It was suggested that clients could analyze the distribution of parts to maintain high availability of the entire blockchain. However, caution was advised due to concerns about centralized trackers and expensive DHTs. Gregory Maxwell dismissed the idea, arguing that tracker-less torrents didn't work well in practice and that integrating BitTorrent technology into Bitcoin would require additional software and opening more ports.In an email conversation, John Dillon proposed using BitTorrent to address the issue of storage capacity in Bitcoin. However, objections were raised regarding the ineffectiveness and susceptibility to DoS attacks of tracker-less torrents. Integrating a DHT capable BitTorrent client was seen as a complicating factor that would require extra software. Instead, it was suggested to add the ability for nodes to advertise what parts of the blockchain they have and revise the address message format to support I2P peers.The discussion emphasized the importance of having sufficient copies of historic data by splitting Bitcoin into ranges. While nodes may be willing to contribute storage space, without a proper structure in place, they would not be able to do so effectively. Suggestions were made to integrate a DHT capable BitTorrent client or call out to a library to solve the problem of nodes finding each other to obtain the data. It was also proposed to use Bitcoin to bootstrap the BitTorrent DHT.Mike Hearn and Pieter Wuille had a conversation about the flexibility of node pruning in Bitcoin. They agreed that nodes should be able to choose their own ranges to keep rather than having fixed intervals. Pieter suggested adding new fields to the addr message to advertise the height at which nodes prune. However, he acknowledged that propagation speed might be slow with this method due to the number of IPs circulating. They also discussed separating the responsibilities of relay/validation and serving historic data, suggesting separate service bits for each. The behavior of old nodes connecting to new nodes and the use case for NODE_VALIDATE were also discussed.Pieter Wuille proposed the idea of pruning nodes that do not keep historic blocks. He suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. NODE_VALIDATE would relay and validate recent blocks and transactions but only answer getdata requests for those. NODE_BLOCKS_2016 could be queried for the last 2016 blocks without guaranteeing relaying or validating new blocks and transactions. The NODE_NETWORK bit would imply NODE_VALIDATE and ensure the availability of all historic blocks. Pieter plans to write a BIP to formalize this proposal. 2013-05-16T16:23:23+00:00 + In 2013, discussions were taking place within the Bitcoin network regarding the storage and replication of historic data. One proposal suggested allowing users to choose which parts of the blockchain to store, but concerns were raised about the lack of copies of the data. An alternative suggestion was made to randomly store chunks of data based on available space, prioritizing the "N most recent" chunks for more replicas. However, Jeff Garzik argued against this idea, warning that it could make the blockchain vulnerable to DoS attacks on one part of the Distributed Hash Table (DHT), potentially causing the entire chain to break.Another topic of discussion focused on optimizing peer discovery mechanisms in the Bitcoin network. The current methods, such as DNS seeds, a fixed list, and IRC discovery, were not deemed effective for overall peer discovery. Several alternative means of peer discovery were suggested, including search engines, IPv4 scanning, and anycast peers. Mike Hearn proposed extending the DNS seeding protocol to allow queries that return only nodes matching specific requirements. However, concerns were raised about DNS caching and the risk of sudden traffic influx at one set of nodes if a large ISP caches a response.The concept of pruning nodes, which validate and relay blocks without keeping all historic blocks, was also explored. Pieter Wuille suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. This would ensure synchronization between new and old nodes. Although there was general support for this proposal, potential issues related to snapshotting and UTXO snapshots were raised.The possibility of using BitTorrent technology in the Bitcoin network was considered. It was suggested that clients could analyze the distribution of parts to maintain high availability of the entire blockchain. However, caution was advised due to concerns about centralized trackers and expensive DHTs. Gregory Maxwell dismissed the idea, arguing that tracker-less torrents didn't work well in practice and that integrating BitTorrent technology into Bitcoin would require additional software and opening more ports.In an email conversation, John Dillon proposed using BitTorrent to address the issue of storage capacity in Bitcoin. However, objections were raised regarding the ineffectiveness and susceptibility to DoS attacks of tracker-less torrents. Integrating a DHT capable BitTorrent client was seen as a complicating factor that would require extra software. Instead, it was suggested to add the ability for nodes to advertise what parts of the blockchain they have and revise the address message format to support I2P peers.The discussion emphasized the importance of having sufficient copies of historic data by splitting Bitcoin into ranges. While nodes may be willing to contribute storage space, without a proper structure in place, they would not be able to do so effectively. Suggestions were made to integrate a DHT capable BitTorrent client or call out to a library to solve the problem of nodes finding each other to obtain the data. It was also proposed to use Bitcoin to bootstrap the BitTorrent DHT.Mike Hearn and Pieter Wuille had a conversation about the flexibility of node pruning in Bitcoin. They agreed that nodes should be able to choose their own ranges to keep rather than having fixed intervals. Pieter suggested adding new fields to the addr message to advertise the height at which nodes prune. However, he acknowledged that propagation speed might be slow with this method due to the number of IPs circulating. They also discussed separating the responsibilities of relay/validation and serving historic data, suggesting separate service bits for each. The behavior of old nodes connecting to new nodes and the use case for NODE_VALIDATE were also discussed.Pieter Wuille proposed the idea of pruning nodes that do not keep historic blocks. He suggested adding two extra service bits to the P2P protocol: NODE_VALIDATE and NODE_BLOCKS_2016. NODE_VALIDATE would relay and validate recent blocks and transactions but only answer getdata requests for those. NODE_BLOCKS_2016 could be queried for the last 2016 blocks without guaranteeing relaying or validating new blocks and transactions. The NODE_NETWORK bit would imply NODE_VALIDATE and ensure the availability of all historic blocks. Pieter plans to write a BIP to formalize this proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_Tentitive-port-for-FreeBSD.xml b/static/bitcoin-dev/May_2013/combined_Tentitive-port-for-FreeBSD.xml index af3d8fcf6f..fc6a27d310 100644 --- a/static/bitcoin-dev/May_2013/combined_Tentitive-port-for-FreeBSD.xml +++ b/static/bitcoin-dev/May_2013/combined_Tentitive-port-for-FreeBSD.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Tentitive port for FreeBSD - 2023-08-01T05:01:04.930648+00:00 + 2025-10-11T21:33:08.790588+00:00 + python-feedgen Luke-Jr 2013-05-25 04:03:43+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Tentitive port for FreeBSD - 2023-08-01T05:01:04.930648+00:00 + 2025-10-11T21:33:08.790756+00:00 - On May 25, 2013 at 3:36:46 AM, Robert Backhaus sent an email to his colleagues sharing a link to the FreeBSD build system 'port'. This email was intended for comments and feedback. The Makefile in this build system incorporates user requests for GUI/QR/UPNP. Additionally, it utilizes an external port for leveldb. The files directory contains five patches, including two that add boost-crypto to LIBS because boost has not been updated yet. There is also a patch that modifies the build to use the external leveldb. Furthermore, there are two minor fixes required for the build process.Robert Backhaus mentioned in his email that he has branches ready for pullreqs on these minor fixes. He plans to double-check them before creating the pull requests later that evening. Luke, another participant in the email thread, encouraged others to test and use the pull request for system LevelDB support. However, he advised caution when linking the port to the specific bundled version of LevelDB to avoid any unforeseen hardforking bugs or fixes in the upstream LevelDB. Luke also requested portable solutions for other patches if they were not already available, and suggested opening pull requests on Github.Robert Backhaus, the developer of the FreeBSD build system 'port', is aiming to have the system committed once version 0.8.2 is released. The Makefile in this build system addresses user requests for GUI/QR/UPNP, with the main change being the use of an external port for leveldb. The files directory contains five patches, including two that add boost-crypto to LIBS and one that modifies the build to use the external leveldb. In addition, there are two minor fixes included. Branches are available for pullreqs on these minor fixes. The files can be found at https://redports.org/browser/robbak/net-p2p/bitcoin. Any comments or feedback on the build system are welcome. 2013-05-25T04:03:43+00:00 + On May 25, 2013 at 3:36:46 AM, Robert Backhaus sent an email to his colleagues sharing a link to the FreeBSD build system 'port'. This email was intended for comments and feedback. The Makefile in this build system incorporates user requests for GUI/QR/UPNP. Additionally, it utilizes an external port for leveldb. The files directory contains five patches, including two that add boost-crypto to LIBS because boost has not been updated yet. There is also a patch that modifies the build to use the external leveldb. Furthermore, there are two minor fixes required for the build process.Robert Backhaus mentioned in his email that he has branches ready for pullreqs on these minor fixes. He plans to double-check them before creating the pull requests later that evening. Luke, another participant in the email thread, encouraged others to test and use the pull request for system LevelDB support. However, he advised caution when linking the port to the specific bundled version of LevelDB to avoid any unforeseen hardforking bugs or fixes in the upstream LevelDB. Luke also requested portable solutions for other patches if they were not already available, and suggested opening pull requests on Github.Robert Backhaus, the developer of the FreeBSD build system 'port', is aiming to have the system committed once version 0.8.2 is released. The Makefile in this build system addresses user requests for GUI/QR/UPNP, with the main change being the use of an external port for leveldb. The files directory contains five patches, including two that add boost-crypto to LIBS and one that modifies the build to use the external leveldb. In addition, there are two minor fixes included. Branches are available for pullreqs on these minor fixes. The files can be found at https://redports.org/browser/robbak/net-p2p/bitcoin. Any comments or feedback on the build system are welcome. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_UUID-to-identify-chains-payment-protocol-and-elsewhere-.xml b/static/bitcoin-dev/May_2013/combined_UUID-to-identify-chains-payment-protocol-and-elsewhere-.xml index b3a6fef557..7e839a0e83 100644 --- a/static/bitcoin-dev/May_2013/combined_UUID-to-identify-chains-payment-protocol-and-elsewhere-.xml +++ b/static/bitcoin-dev/May_2013/combined_UUID-to-identify-chains-payment-protocol-and-elsewhere-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - UUID to identify chains (payment protocol and elsewhere) - 2023-08-01T04:59:30.070524+00:00 + 2025-10-11T21:33:38.519397+00:00 + python-feedgen Gavin Andresen 2013-05-22 15:59:53+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - UUID to identify chains (payment protocol and elsewhere) - 2023-08-01T04:59:30.070524+00:00 + 2025-10-11T21:33:38.519580+00:00 - Gavin Andresen, the Chief Scientist at Bitcoin Foundation, voted against a proposal to use uuid instead of "main" / "test" in the payment protocol. He explained that the payment protocol would become at least 3 BIPs, including Protocol messages, MIME type, and bitcoin: URI extension. He discussed how alt coins would need their own version of these components. He also changed his mind regarding which coin would be encoded in the MIME type and which chain for that coin would be encoded in PaymentDetails.network.An email conversation between Luke-Jr and Jeff Garzik discussed the possibility of multiple currencies using the same blockchain. They agreed that encouraging such a use case would benefit altcoins that fit within the scope of Bitcoin or another existing altchain. However, they did not want to support cases like a fork that leaves the genesis block intact and the subsidy at 50.0 BTC forever.In a conversation between Jeff Garzik and Melvin Carvalho, they discussed the possibility of multiple coin ecosystems sharing the same genesis block. Melvin suggested an out-of-band algo/hash could work if there was a one-to-one relationship between the object and UUID. Jeff disagreed, stating that it would have bad side effects and go against the point of the Bitcoin consensus algorithm. He did not want to encourage such behavior with code.Mark Friedenbach proposed a standard mechanism for identifying chains using UUIDs. He suggested using Version 4 (random) UUIDs with random bits extracted from the double-SHA256 hash of the genesis block of the chain. He argued that namespaces become more important as registries grow and that an out of band algo/hash could work as long as there was a one-to-one relationship between the object and the UUID. He recommended allowing the registry to be a URI for better readability and usability.Bitcoin developer Mark Friedenbach proposed a way to uniquely identify coloured coins and chains using UUIDs. He suggests using Version 4 (random) UUIDs with random bits extracted from the double-SHA256 hash of the genesis block of the chain. The proposal would help adopt the payment protocol to coloured coins. Some altcoins may share a blockchain, or even merely the genesis block, so requiring a 1:1 mapping between genesis block and chain or coin seems non-ideal.In an email conversation between Jeff Garzik and Mark Friedenbach, they discussed identifying chains/coins using UUIDs. Friedenbach suggested using Version 4 (random) UUIDs with random bits extracted from the double-SHA256 hash of the genesis block of the chain. Garzik proposed a double-SHA256 Version 6 as it is more applicable for identifying chains/coins. They also discussed different chain identifiers and the need for readable shortname strings.The Bitcoinj project discussed creating a global naming system using Version 4 (random) UUIDs. The proposal included examples of chain identifiers such as mainnet, testnet3, and namecoin. Jeff Garzik commented on the proposal, suggesting a bitcoin-specific version 6 may be necessary.In an email exchange between Mark Friedenbach and Jeff Garzik, Friedenbach recommended using Version 4 UUIDs with random bits extracted from the double-SHA256 hash of the genesis block of the chain. Garzik proposed a bitcoin-specific Version 6. They discussed the need for readable shortname strings despite attempts to avoid them.During a developer round-table discussion, it was mentioned that the payment protocol supports alt-chains. Mark Friedenbach proposed using UUID to uniquely identify any chain by its genesis block. He suggested using Version 4 (random) UUIDs with random bits extracted from the double-SHA256 hash of the genesis block. His proposal aimed to avoid issues with alt-chains or colored coins.Overall, the discussions revolve around the use of UUIDs to identify chains and coins, the need for readable shortname strings, and the considerations for supporting alt-chains in the payment protocol. 2013-05-22T15:59:53+00:00 + Gavin Andresen, the Chief Scientist at Bitcoin Foundation, voted against a proposal to use uuid instead of "main" / "test" in the payment protocol. He explained that the payment protocol would become at least 3 BIPs, including Protocol messages, MIME type, and bitcoin: URI extension. He discussed how alt coins would need their own version of these components. He also changed his mind regarding which coin would be encoded in the MIME type and which chain for that coin would be encoded in PaymentDetails.network.An email conversation between Luke-Jr and Jeff Garzik discussed the possibility of multiple currencies using the same blockchain. They agreed that encouraging such a use case would benefit altcoins that fit within the scope of Bitcoin or another existing altchain. However, they did not want to support cases like a fork that leaves the genesis block intact and the subsidy at 50.0 BTC forever.In a conversation between Jeff Garzik and Melvin Carvalho, they discussed the possibility of multiple coin ecosystems sharing the same genesis block. Melvin suggested an out-of-band algo/hash could work if there was a one-to-one relationship between the object and UUID. Jeff disagreed, stating that it would have bad side effects and go against the point of the Bitcoin consensus algorithm. He did not want to encourage such behavior with code.Mark Friedenbach proposed a standard mechanism for identifying chains using UUIDs. He suggested using Version 4 (random) UUIDs with random bits extracted from the double-SHA256 hash of the genesis block of the chain. He argued that namespaces become more important as registries grow and that an out of band algo/hash could work as long as there was a one-to-one relationship between the object and the UUID. He recommended allowing the registry to be a URI for better readability and usability.Bitcoin developer Mark Friedenbach proposed a way to uniquely identify coloured coins and chains using UUIDs. He suggests using Version 4 (random) UUIDs with random bits extracted from the double-SHA256 hash of the genesis block of the chain. The proposal would help adopt the payment protocol to coloured coins. Some altcoins may share a blockchain, or even merely the genesis block, so requiring a 1:1 mapping between genesis block and chain or coin seems non-ideal.In an email conversation between Jeff Garzik and Mark Friedenbach, they discussed identifying chains/coins using UUIDs. Friedenbach suggested using Version 4 (random) UUIDs with random bits extracted from the double-SHA256 hash of the genesis block of the chain. Garzik proposed a double-SHA256 Version 6 as it is more applicable for identifying chains/coins. They also discussed different chain identifiers and the need for readable shortname strings.The Bitcoinj project discussed creating a global naming system using Version 4 (random) UUIDs. The proposal included examples of chain identifiers such as mainnet, testnet3, and namecoin. Jeff Garzik commented on the proposal, suggesting a bitcoin-specific version 6 may be necessary.In an email exchange between Mark Friedenbach and Jeff Garzik, Friedenbach recommended using Version 4 UUIDs with random bits extracted from the double-SHA256 hash of the genesis block of the chain. Garzik proposed a bitcoin-specific Version 6. They discussed the need for readable shortname strings despite attempts to avoid them.During a developer round-table discussion, it was mentioned that the payment protocol supports alt-chains. Mark Friedenbach proposed using UUID to uniquely identify any chain by its genesis block. He suggested using Version 4 (random) UUIDs with random bits extracted from the double-SHA256 hash of the genesis block. His proposal aimed to avoid issues with alt-chains or colored coins.Overall, the discussions revolve around the use of UUIDs to identify chains and coins, the need for readable shortname strings, and the considerations for supporting alt-chains in the payment protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_WebCryto-standard-to-support-secp256r1-but-not-secp256k1.xml b/static/bitcoin-dev/May_2013/combined_WebCryto-standard-to-support-secp256r1-but-not-secp256k1.xml index 0749db9985..c8ce15e348 100644 --- a/static/bitcoin-dev/May_2013/combined_WebCryto-standard-to-support-secp256r1-but-not-secp256k1.xml +++ b/static/bitcoin-dev/May_2013/combined_WebCryto-standard-to-support-secp256r1-but-not-secp256k1.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - WebCryto standard to support secp256r1 but not secp256k1 - 2023-08-01T04:50:19.640054+00:00 + 2025-10-11T21:32:49.669372+00:00 + python-feedgen Melvin Carvalho 2013-05-29 12:14:20+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - WebCryto standard to support secp256r1 but not secp256k1 - 2023-08-01T04:50:19.640054+00:00 + 2025-10-11T21:32:49.669523+00:00 - Melvin Carvalho has expressed interest in adding Bitcoin's Koblitz curve to the proposed native crypto browser support, which is set to be implemented next year. The current Web Crypto API includes three NIST recommended curves: P-256, P-384, and P-521. In order to gather more information on this matter, Melvin reached out to the chair of the crypto group, who advised him to email public-webcrypto-comments at w3.org and specify his use-cases.The main objective of the proposed native crypto browser support is to expose existing crypto code rather than requiring browser vendors to develop new code. However, there is an unresolved issue regarding the maintenance of an "experimental" registry for identifiers of new curves not included in the core specification. The chair of the crypto group suggested that if browsers do not currently support the Koblitz curve, they may consider supporting it in the future due to Bitcoin's growing popularity.To further explore this topic, Melvin requested individuals with a use case for ecdsa (Elliptic Curve Digital Signature Algorithm) in the browser to contact him or contribute to the public discussion list. The proposed native crypto browser support currently includes the three aforementioned NIST curves, but there are arguments for including the Koblitz curve used by Bitcoin. More details about the Koblitz curve can be found on the Bitcointalk forum.Overall, the discussion revolves around the inclusion of Bitcoin's Koblitz curve in the upcoming native crypto browser support, with Melvin Carvalho actively seeking input from relevant parties. 2013-05-29T12:14:20+00:00 + Melvin Carvalho has expressed interest in adding Bitcoin's Koblitz curve to the proposed native crypto browser support, which is set to be implemented next year. The current Web Crypto API includes three NIST recommended curves: P-256, P-384, and P-521. In order to gather more information on this matter, Melvin reached out to the chair of the crypto group, who advised him to email public-webcrypto-comments at w3.org and specify his use-cases.The main objective of the proposed native crypto browser support is to expose existing crypto code rather than requiring browser vendors to develop new code. However, there is an unresolved issue regarding the maintenance of an "experimental" registry for identifiers of new curves not included in the core specification. The chair of the crypto group suggested that if browsers do not currently support the Koblitz curve, they may consider supporting it in the future due to Bitcoin's growing popularity.To further explore this topic, Melvin requested individuals with a use case for ecdsa (Elliptic Curve Digital Signature Algorithm) in the browser to contact him or contribute to the public discussion list. The proposed native crypto browser support currently includes the three aforementioned NIST curves, but there are arguments for including the Koblitz curve used by Bitcoin. More details about the Koblitz curve can be found on the Bitcointalk forum.Overall, the discussion revolves around the inclusion of Bitcoin's Koblitz curve in the upcoming native crypto browser support, with Melvin Carvalho actively seeking input from relevant parties. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_bitcoin-taint-unilateral-revocability-Re-ecash-and-revocability-.xml b/static/bitcoin-dev/May_2013/combined_bitcoin-taint-unilateral-revocability-Re-ecash-and-revocability-.xml index b5af83582f..63c81d9787 100644 --- a/static/bitcoin-dev/May_2013/combined_bitcoin-taint-unilateral-revocability-Re-ecash-and-revocability-.xml +++ b/static/bitcoin-dev/May_2013/combined_bitcoin-taint-unilateral-revocability-Re-ecash-and-revocability-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoin taint & unilateral revocability (Re: ecash and revocability) - 2023-08-01T04:52:52.960099+00:00 + 2025-10-11T21:32:56.037501+00:00 + python-feedgen grarpamp 2013-05-14 17:30:05+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - bitcoin taint & unilateral revocability (Re: ecash and revocability) - 2023-08-01T04:52:52.960099+00:00 + 2025-10-11T21:32:56.037657+00:00 - Adam Back, a prominent cryptographer involved in the development of Bitcoin, has expressed concerns about the lack of privacy in the cryptocurrency and its potential impact on taint and revocability. Taint refers to the risk of coins becoming unspendable or only spendable at a discount due to their transaction history. While Bitcoin's policy states that all coins should be equally acceptable, individuals can reject them based on their taint.However, there have been no reported issues with revocability or taint inspection thus far. People currently have the option and technical means to check the taint of coins and send them back if necessary. This lack of privacy has also not been thoroughly documented in terms of Bitcoin traceability when using various privacy enhancement methods, such as using different addresses for each transaction, washing coins, or utilizing anonymity networks.Rejecting tainted coins could greatly diminish the usability of Bitcoin as a globally adopted currency. It is unlikely that people would want to use a currency that risks becoming unspendable or requires extensive know-your-customer (KYC) procedures and background checks for every transaction. Additionally, if a significant number of coins were blacklisted, it would render the currency useless for everyone. While specialized currencies in specific markets might be able to address these issues, a common global currency like Bitcoin cannot afford such problems.In an email exchange between Simon and Adam, Simon proposes a privacy-enhancing solution based on fair exchange through bitcoin contracts and cut-and-choose. This solution involves a public pool of users who would simultaneously exchange in common denominations, ensuring unlinkability while leaving a trace of exchange activity on the blockchain. Simon provides a link to the solution, which can potentially be integrated into wallet software to automate the process.Adam responds by discussing his thoughts on ecash and revocability, as well as the taint issue in Bitcoin. He suggests that commitments could be an efficient fix for the taint problem without the need for blinding or zero-knowledge proof (ZKP) of set membership. The idea is to commit to a payment and lock a coin without revealing one's identity until the commitment is released. This approach resembles a self-issued green coin that requires no trust and can be immediately cleared. To prevent double-spending, the recipient would also need to be committed simultaneously.Adam also mentions an article by Sander & Ta Shma on "Auditable, Anonymous Electronic Cash," which explores blinding-based unlinkability in a distributed cryptographic payer/payee anonymous system. These systems rely on ZKP of set membership, which can be computationally expensive. Zerocoin offers a more efficient form of ZKP with its cut-and-choose proof. Commitments, another related concept, could potentially address the taint issue as well.Overall, Adam Back raises important concerns about taint and revocability in cryptocurrencies, particularly Bitcoin. He suggests potential fixes such as commitments and discusses existing research on ecash and anonymity. These discussions highlight the ongoing efforts to enhance privacy and usability in digital currencies. 2013-05-14T17:30:05+00:00 + Adam Back, a prominent cryptographer involved in the development of Bitcoin, has expressed concerns about the lack of privacy in the cryptocurrency and its potential impact on taint and revocability. Taint refers to the risk of coins becoming unspendable or only spendable at a discount due to their transaction history. While Bitcoin's policy states that all coins should be equally acceptable, individuals can reject them based on their taint.However, there have been no reported issues with revocability or taint inspection thus far. People currently have the option and technical means to check the taint of coins and send them back if necessary. This lack of privacy has also not been thoroughly documented in terms of Bitcoin traceability when using various privacy enhancement methods, such as using different addresses for each transaction, washing coins, or utilizing anonymity networks.Rejecting tainted coins could greatly diminish the usability of Bitcoin as a globally adopted currency. It is unlikely that people would want to use a currency that risks becoming unspendable or requires extensive know-your-customer (KYC) procedures and background checks for every transaction. Additionally, if a significant number of coins were blacklisted, it would render the currency useless for everyone. While specialized currencies in specific markets might be able to address these issues, a common global currency like Bitcoin cannot afford such problems.In an email exchange between Simon and Adam, Simon proposes a privacy-enhancing solution based on fair exchange through bitcoin contracts and cut-and-choose. This solution involves a public pool of users who would simultaneously exchange in common denominations, ensuring unlinkability while leaving a trace of exchange activity on the blockchain. Simon provides a link to the solution, which can potentially be integrated into wallet software to automate the process.Adam responds by discussing his thoughts on ecash and revocability, as well as the taint issue in Bitcoin. He suggests that commitments could be an efficient fix for the taint problem without the need for blinding or zero-knowledge proof (ZKP) of set membership. The idea is to commit to a payment and lock a coin without revealing one's identity until the commitment is released. This approach resembles a self-issued green coin that requires no trust and can be immediately cleared. To prevent double-spending, the recipient would also need to be committed simultaneously.Adam also mentions an article by Sander & Ta Shma on "Auditable, Anonymous Electronic Cash," which explores blinding-based unlinkability in a distributed cryptographic payer/payee anonymous system. These systems rely on ZKP of set membership, which can be computationally expensive. Zerocoin offers a more efficient form of ZKP with its cut-and-choose proof. Commitments, another related concept, could potentially address the taint issue as well.Overall, Adam Back raises important concerns about taint and revocability in cryptocurrencies, particularly Bitcoin. He suggests potential fixes such as commitments and discusses existing research on ecash and anonymity. These discussions highlight the ongoing efforts to enhance privacy and usability in digital currencies. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_blind-symmetric-commitment-for-stronger-byzantine-voting-resilience-Re-bitcoin-taint-unilateral-revocability-.xml b/static/bitcoin-dev/May_2013/combined_blind-symmetric-commitment-for-stronger-byzantine-voting-resilience-Re-bitcoin-taint-unilateral-revocability-.xml index 566d7c53f9..d65353f124 100644 --- a/static/bitcoin-dev/May_2013/combined_blind-symmetric-commitment-for-stronger-byzantine-voting-resilience-Re-bitcoin-taint-unilateral-revocability-.xml +++ b/static/bitcoin-dev/May_2013/combined_blind-symmetric-commitment-for-stronger-byzantine-voting-resilience-Re-bitcoin-taint-unilateral-revocability-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability) - 2023-08-01T04:53:43.242782+00:00 + 2025-10-11T21:33:04.536921+00:00 + python-feedgen Adam Back 2013-05-16 14:51:09+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint & unilateral revocability) - 2023-08-01T04:53:43.242782+00:00 + 2025-10-11T21:33:04.537067+00:00 - In May 2013, Adam Back suggested the use of fixed size committed coin spends for better cryptography. The system involved using blind-sender, auth-tag, and encrypted-tx-commit with pub key P = xG, G = base point. To solve the issue of earlier committed spend chains forcing a reveal for someone later, K_i was used for different spends and included in the encrypted-tx-commit. The proposal aimed to improve the clarity of key derivation by suggesting the use of a KDF like IEEE P1363 KDF2 or PKCS#5 PBKDF2 with 1 iteration.Gregory Maxwell discussed the concealment of transactions and quadratic costs in evaluating a private clique's claims. Adam Back contributed his opinions on coin size, verification cost being linear, and offered a tweak to keep committed coin sizes small. He suggested that temporary privacy could be maintained, but peers have technical means to react and defend themselves if dishonest mining is detected. He proposed replacing tx-commit with encrypted-tx-commit to reduce the size of public keys required for each hop.In an email conversation, Gregory Maxwell proposed a coin spending system involving txouts that pay P2SH addresses with an OP_PUSH nonce. The recipient would be provided with the nonce out of band and when they spend the coins, they provide the script but not the nonce. This proposal aimed to make identities public only once they're buried a bit and bound the growth of proofs. The implementation had potential attacks on publication for 'tainted' transactions, but it was considered an interesting idea.Mike Hearn asked about Adamcoin and its similarity to Zerocoin. The key difference was that Zerocoin completely conceals the connection forever, while Adamcoin only conceals transactions from those not involved. The conversation highlighted the quadratic costs in evaluating a private clique's claims and the need to make identities public once they're buried a bit to mitigate this issue.Gavin and Gregory Maxwell discussed Adam Back's proposal to hide coins being spent on the Bitcoin network. The proposal involved using blinded payments, but there were complications such as anti-DOS issues and strange economic implications. The conversation also touched on the possibility of miner cartels trying to exclude transactions but concluded that it might not become a big issue.The writer proposed using committed transactions to improve Bitcoin scalability by reducing network bandwidth. They suggested using blind-sender, auth-tag, and tx-commit in the commitment to prevent non-blind double spends. The committed coins were not linkable to non-blind coins, giving users more control over policy. The writer also mentioned the possibility of adding tracing to privacy-preserving protocols.Caleb James DeLisle wrote about using bit-commitments based on deterministic one-way functions. These commitments ensured no non-blind double spends of committed coins until commitment reveal. The committed coins were not linkable to non-blind coins, putting policy control in the user's hands. The writer emphasized the need for more time to fully understand the implications of this proposal.Peter Todd expressed concerns about the vulnerability of Bitcoin protocol to 51% attacks. Adam Back argued that protocol voting is a vote per user policy preference, making it difficult for miners to impose arbitrary policies. He suggested that the blind commitment proposal could fix this issue by preventing even a 99% quorum from imposing policies. The feasibility of protocol voting attacks was considered an open question.An email exchange between Adam Back and Peter Todd discussed the vulnerability of protocols in the Bitcoin network. Todd raised concerns about the lack of chargebacks in Bitcoin, which could create issues in kidnap and ransom cases. The conversation predicted potential government actions and their impact on Bitcoin.In an email, Adam Back proposed a simple, efficient, and easy-to-implement symmetric key commitment protocol that could improve the Byzantine generals problem in Bitcoin. This commitment protocol would remove the need for honest nodes and enable transactions to be accepted without relying on CPU power. The approach was composable, and the network wouldn't learn the size of the transaction even though the spend grows each time. 2013-05-16T14:51:09+00:00 + In May 2013, Adam Back suggested the use of fixed size committed coin spends for better cryptography. The system involved using blind-sender, auth-tag, and encrypted-tx-commit with pub key P = xG, G = base point. To solve the issue of earlier committed spend chains forcing a reveal for someone later, K_i was used for different spends and included in the encrypted-tx-commit. The proposal aimed to improve the clarity of key derivation by suggesting the use of a KDF like IEEE P1363 KDF2 or PKCS#5 PBKDF2 with 1 iteration.Gregory Maxwell discussed the concealment of transactions and quadratic costs in evaluating a private clique's claims. Adam Back contributed his opinions on coin size, verification cost being linear, and offered a tweak to keep committed coin sizes small. He suggested that temporary privacy could be maintained, but peers have technical means to react and defend themselves if dishonest mining is detected. He proposed replacing tx-commit with encrypted-tx-commit to reduce the size of public keys required for each hop.In an email conversation, Gregory Maxwell proposed a coin spending system involving txouts that pay P2SH addresses with an OP_PUSH nonce. The recipient would be provided with the nonce out of band and when they spend the coins, they provide the script but not the nonce. This proposal aimed to make identities public only once they're buried a bit and bound the growth of proofs. The implementation had potential attacks on publication for 'tainted' transactions, but it was considered an interesting idea.Mike Hearn asked about Adamcoin and its similarity to Zerocoin. The key difference was that Zerocoin completely conceals the connection forever, while Adamcoin only conceals transactions from those not involved. The conversation highlighted the quadratic costs in evaluating a private clique's claims and the need to make identities public once they're buried a bit to mitigate this issue.Gavin and Gregory Maxwell discussed Adam Back's proposal to hide coins being spent on the Bitcoin network. The proposal involved using blinded payments, but there were complications such as anti-DOS issues and strange economic implications. The conversation also touched on the possibility of miner cartels trying to exclude transactions but concluded that it might not become a big issue.The writer proposed using committed transactions to improve Bitcoin scalability by reducing network bandwidth. They suggested using blind-sender, auth-tag, and tx-commit in the commitment to prevent non-blind double spends. The committed coins were not linkable to non-blind coins, giving users more control over policy. The writer also mentioned the possibility of adding tracing to privacy-preserving protocols.Caleb James DeLisle wrote about using bit-commitments based on deterministic one-way functions. These commitments ensured no non-blind double spends of committed coins until commitment reveal. The committed coins were not linkable to non-blind coins, putting policy control in the user's hands. The writer emphasized the need for more time to fully understand the implications of this proposal.Peter Todd expressed concerns about the vulnerability of Bitcoin protocol to 51% attacks. Adam Back argued that protocol voting is a vote per user policy preference, making it difficult for miners to impose arbitrary policies. He suggested that the blind commitment proposal could fix this issue by preventing even a 99% quorum from imposing policies. The feasibility of protocol voting attacks was considered an open question.An email exchange between Adam Back and Peter Todd discussed the vulnerability of protocols in the Bitcoin network. Todd raised concerns about the lack of chargebacks in Bitcoin, which could create issues in kidnap and ransom cases. The conversation predicted potential government actions and their impact on Bitcoin.In an email, Adam Back proposed a simple, efficient, and easy-to-implement symmetric key commitment protocol that could improve the Byzantine generals problem in Bitcoin. This commitment protocol would remove the need for honest nodes and enable transactions to be accepted without relying on CPU power. The approach was composable, and the network wouldn't learn the size of the transaction even though the spend grows each time. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml b/static/bitcoin-dev/May_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml index de09692020..d7b2b404fe 100644 --- a/static/bitcoin-dev/May_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml +++ b/static/bitcoin-dev/May_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - is there a way to do bitcoin-staging? - 2023-08-01T04:55:26.435643+00:00 + 2025-10-11T21:33:40.641572+00:00 + python-feedgen Melvin Carvalho 2013-11-21 20:35:44+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - is there a way to do bitcoin-staging? - 2023-08-01T04:55:26.435643+00:00 + 2025-10-11T21:33:40.641790+00:00 - In a discussion thread from 2013, various ideas for improving the Bitcoin network were proposed. Adam Back suggested creating a live beta version of Bitcoin called "betacoin" for testing and development purposes. Alan Reiner and Peter Vessenes expressed interest in this idea, with the goal of speeding up Bitcoin development while maintaining its value and security. Meanwhile, Betacoin, a new cryptocurrency designed for faster transactions and lower fees, had already been introduced on the market, attracting interest and investment despite potential risks.The conversation also delved into reorganizing blockchain data into an authenticated tree indexed by TxOut script instead of tx-hash. This idea was put forth by Alan Reiner, who believed it could improve the efficiency of the network. Merge mining, where an alt-coin is mined alongside Bitcoin, using the same coins as Bitcoin main, was also discussed by Adam Back. Michael Gronager mentioned that he had already coded the authenticated data structure part and was considering incorporating p2pool style mining.Another topic of discussion was the use of Testnet as an alt-coin for testing non-standard transactions and developing new technologies and services. Dennison Bertram suggested that using Testnet as an alt-coin would provide a pseudo live environment for testing and incentivize people to try and exploit the system. The conversation also explored the advantages and limitations of using blockchain technology for notary and verification services.The conversation continued with various suggestions and proposals. Peter Todd proposed a "fair" merged mining system where miners would have to choose between mining an altcoin or Bitcoin to prove the sacrifice of potential Bitcoin earnings. Luke raised concerns about how this system would work for an altcoin whose price is independent of Bitcoin. Zooko expressed interest in implementing a "beta bitcoin blockchain," suggesting the creation of a common codebase for Bitcoin enthusiasts to experiment with.Adam Back asked if there was a way to experiment with new features without burdening the Bitcoin network. Merged mining and the use of an altcoin, such as bitcoin-staging, were suggested as possible solutions. Additionally, the reorganization of blockchain data into an authenticated tree indexed by TxOut script was discussed.Overall, these discussions revolved around finding ways to experiment with new features, ensure the sacrifice of potential Bitcoin earnings, and avoid diluting the value and parameters of Bitcoin. Merged mining and the use of altcoins like bitcoin-staging were considered as potential solutions to these challenges. 2013-11-21T20:35:44+00:00 + In a discussion thread from 2013, various ideas for improving the Bitcoin network were proposed. Adam Back suggested creating a live beta version of Bitcoin called "betacoin" for testing and development purposes. Alan Reiner and Peter Vessenes expressed interest in this idea, with the goal of speeding up Bitcoin development while maintaining its value and security. Meanwhile, Betacoin, a new cryptocurrency designed for faster transactions and lower fees, had already been introduced on the market, attracting interest and investment despite potential risks.The conversation also delved into reorganizing blockchain data into an authenticated tree indexed by TxOut script instead of tx-hash. This idea was put forth by Alan Reiner, who believed it could improve the efficiency of the network. Merge mining, where an alt-coin is mined alongside Bitcoin, using the same coins as Bitcoin main, was also discussed by Adam Back. Michael Gronager mentioned that he had already coded the authenticated data structure part and was considering incorporating p2pool style mining.Another topic of discussion was the use of Testnet as an alt-coin for testing non-standard transactions and developing new technologies and services. Dennison Bertram suggested that using Testnet as an alt-coin would provide a pseudo live environment for testing and incentivize people to try and exploit the system. The conversation also explored the advantages and limitations of using blockchain technology for notary and verification services.The conversation continued with various suggestions and proposals. Peter Todd proposed a "fair" merged mining system where miners would have to choose between mining an altcoin or Bitcoin to prove the sacrifice of potential Bitcoin earnings. Luke raised concerns about how this system would work for an altcoin whose price is independent of Bitcoin. Zooko expressed interest in implementing a "beta bitcoin blockchain," suggesting the creation of a common codebase for Bitcoin enthusiasts to experiment with.Adam Back asked if there was a way to experiment with new features without burdening the Bitcoin network. Merged mining and the use of an altcoin, such as bitcoin-staging, were suggested as possible solutions. Additionally, the reorganization of blockchain data into an authenticated tree indexed by TxOut script was discussed.Overall, these discussions revolved around finding ways to experiment with new features, ensure the sacrifice of potential Bitcoin earnings, and avoid diluting the value and parameters of Bitcoin. Merged mining and the use of altcoins like bitcoin-staging were considered as potential solutions to these challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_limits-of-network-hacking-netsplits-was-Discovery-addr-packets-.xml b/static/bitcoin-dev/May_2013/combined_limits-of-network-hacking-netsplits-was-Discovery-addr-packets-.xml index ae14584cb1..0dcddeed77 100644 --- a/static/bitcoin-dev/May_2013/combined_limits-of-network-hacking-netsplits-was-Discovery-addr-packets-.xml +++ b/static/bitcoin-dev/May_2013/combined_limits-of-network-hacking-netsplits-was-Discovery-addr-packets-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - limits of network hacking/netsplits (was: Discovery/addr packets) - 2023-08-01T04:50:06.990061+00:00 + 2025-10-11T21:32:53.913387+00:00 + python-feedgen Matt Corallo 2013-05-07 21:07:50+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - limits of network hacking/netsplits (was: Discovery/addr packets) - 2023-08-01T04:50:06.990061+00:00 + 2025-10-11T21:32:53.913531+00:00 - The author of the context disagrees with the notion that Bitcoin package maintainers are doing a good job for Linux users. They argue that Ubuntu users on the distro quantal are stuck on an outdated version of Bitcoin with no updates since 2012, and Debian Squeeze users are missing every fix since version 0.3.24. Additionally, the author notes that most distros link Bitcoin against libdb5.1, making wallets unusable for an official Bitcoin build. The author acknowledges that package maintainers may not be at fault for using outdated versions of libraries. The context also discusses the importance of secure binary distribution and the role of SSL in providing a secure connection. The author suggests that SSL is essential but requires finding alternative file hosting. They mention Damgards as a potential solution, but note that there is no choice in what to use. On Android, developers are limited in their ability to change the signing key after deployment. The author mentions the quorum-of-developers signing system using gitian and reproducible builds, but points out that people don't check the signatures, rendering the system less effective. The author suggests combining this system with an auto-update engine or other software distribution platform for better security.An email conversation between Mike Hearn and Adam explores the trustworthiness of Bitcoin binaries and ways to ensure their source. They discuss the website redesign and suggest checking PGP signatures using the Web of Trust (WoT). Some developers have their keys in a PGP Global Trust Register, which could provide a level of trust for those who take the WoT seriously. SSL-enabled websites are considered trustworthy up to the weakest link in CA security. The threshold RSA library is mentioned as a means of splitting RSA keys for updates, and Linux is identified as having the worst situation due to man-in-the-middle attacks by package maintainers. The conversation suggests multiple people signing releases to provide assurance, even if some signers are pseudonymous.The context also highlights the limitations of signatures for verifying mirror integrity, as they are often not checked and obtained from the same website serving the binary. The verify-bitcoin.sh script is mentioned as unreliable for checking signatures. The Bitcoin Wallet app on Android is protected by measures such as only accepting updates signed by the original key and being at the top of the Play Store search results. MacOS X binaries are signed under the legal identity of the Bitcoin Foundation, and unsigned binaries do not run by default. Windows antivirus companies operate binary whitelisting to fight viruses. However, Linux faces more challenges, including man-in-the-middle attacks and patches, prompting a need for a health warning on the Bitcoin website.The discussion on the Bitcoin-development mailing list revolves around various topics related to Bitcoin mining, including network manipulation through hacking pools or segmenting the network. Participants acknowledge that such attacks can be short-lived and inconsiderate. They also discuss the difficulty level in Bitcoin mining, which can be reduced every 2016 blocks. The conversation then shifts to the security of Bitcoin software packages. While some maintainers are doing a good job, there are concerns about SSL and CA infrastructure vulnerabilities. The use of gpg signatures and gitian downloader signatures is considered secure, but getting users to use them remains an open question.Email exchanges between Adam Back and others delve into the vulnerability of Bitcoin network attacks. Back argues that network attacks that induce splits are the primary vulnerability of Bitcoin. He suggests hacking pools or segmenting the network to have miners do the work. The issue of signatures is also discussed, with Back pointing out the lack of signatures for Linux binaries and tarballs. Maxwell claims that they are signed, but Back refutes this and highlights the absence of signatures. The ease of attacking binaries is mentioned, such as creating user-operated netsplits or emptying wallets via a mix. 2013-05-07T21:07:50+00:00 + The author of the context disagrees with the notion that Bitcoin package maintainers are doing a good job for Linux users. They argue that Ubuntu users on the distro quantal are stuck on an outdated version of Bitcoin with no updates since 2012, and Debian Squeeze users are missing every fix since version 0.3.24. Additionally, the author notes that most distros link Bitcoin against libdb5.1, making wallets unusable for an official Bitcoin build. The author acknowledges that package maintainers may not be at fault for using outdated versions of libraries. The context also discusses the importance of secure binary distribution and the role of SSL in providing a secure connection. The author suggests that SSL is essential but requires finding alternative file hosting. They mention Damgards as a potential solution, but note that there is no choice in what to use. On Android, developers are limited in their ability to change the signing key after deployment. The author mentions the quorum-of-developers signing system using gitian and reproducible builds, but points out that people don't check the signatures, rendering the system less effective. The author suggests combining this system with an auto-update engine or other software distribution platform for better security.An email conversation between Mike Hearn and Adam explores the trustworthiness of Bitcoin binaries and ways to ensure their source. They discuss the website redesign and suggest checking PGP signatures using the Web of Trust (WoT). Some developers have their keys in a PGP Global Trust Register, which could provide a level of trust for those who take the WoT seriously. SSL-enabled websites are considered trustworthy up to the weakest link in CA security. The threshold RSA library is mentioned as a means of splitting RSA keys for updates, and Linux is identified as having the worst situation due to man-in-the-middle attacks by package maintainers. The conversation suggests multiple people signing releases to provide assurance, even if some signers are pseudonymous.The context also highlights the limitations of signatures for verifying mirror integrity, as they are often not checked and obtained from the same website serving the binary. The verify-bitcoin.sh script is mentioned as unreliable for checking signatures. The Bitcoin Wallet app on Android is protected by measures such as only accepting updates signed by the original key and being at the top of the Play Store search results. MacOS X binaries are signed under the legal identity of the Bitcoin Foundation, and unsigned binaries do not run by default. Windows antivirus companies operate binary whitelisting to fight viruses. However, Linux faces more challenges, including man-in-the-middle attacks and patches, prompting a need for a health warning on the Bitcoin website.The discussion on the Bitcoin-development mailing list revolves around various topics related to Bitcoin mining, including network manipulation through hacking pools or segmenting the network. Participants acknowledge that such attacks can be short-lived and inconsiderate. They also discuss the difficulty level in Bitcoin mining, which can be reduced every 2016 blocks. The conversation then shifts to the security of Bitcoin software packages. While some maintainers are doing a good job, there are concerns about SSL and CA infrastructure vulnerabilities. The use of gpg signatures and gitian downloader signatures is considered secure, but getting users to use them remains an open question.Email exchanges between Adam Back and others delve into the vulnerability of Bitcoin network attacks. Back argues that network attacks that induce splits are the primary vulnerability of Bitcoin. He suggests hacking pools or segmenting the network to have miners do the work. The issue of signatures is also discussed, with Back pointing out the lack of signatures for Linux binaries and tarballs. Maxwell claims that they are signed, but Back refutes this and highlights the absence of signatures. The ease of attacking binaries is mentioned, such as creating user-operated netsplits or emptying wallets via a mix. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_merged-mining-hashcash-bitcoin-Re-Coinbase-TxOut-Hashcash-.xml b/static/bitcoin-dev/May_2013/combined_merged-mining-hashcash-bitcoin-Re-Coinbase-TxOut-Hashcash-.xml index 628dbb6564..058bf2b45d 100644 --- a/static/bitcoin-dev/May_2013/combined_merged-mining-hashcash-bitcoin-Re-Coinbase-TxOut-Hashcash-.xml +++ b/static/bitcoin-dev/May_2013/combined_merged-mining-hashcash-bitcoin-Re-Coinbase-TxOut-Hashcash-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash) - 2023-08-01T04:52:16.579543+00:00 + 2025-10-11T21:33:27.898719+00:00 + python-feedgen Adam Back 2013-05-14 20:07:31+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash) - 2023-08-01T04:52:16.579543+00:00 + 2025-10-11T21:33:27.898928+00:00 - In a conversation between Jeff Garzik and Adam in May 2013, they discuss different methods of rewarding miners for their work in verifying transactions and adding blocks to the blockchain. Jeff mentions that if a promised transaction to the miner is not an integral part of the reward transaction, the user may choose to withhold it, which is not ideal. He suggests proof that they directly mined a block with a coinbase that immediately makes payment to future miners as a better method. This has several advantages, including not creating new traffic for the bitcoin network, easy verification on the blockchain, and the ability to be bound to a service if micro-mined on the spot. Jeff believes that ideally, one should simultaneously mine and give a reward to future block miners.The idea of creating an anonymous identity using a decentralized approach is discussed as a solution to the problem of not being able to create Google accounts via Tor without a phone number. The concept involves a server generating transactions with pubkeys owned by private keys to prove ownership of the passport/fidelity bond. This could be used on platforms like MediaWiki, Wordpress, or phpBB to prevent spam and abuse.Jeff explains that the miner's reward for processing transactions is the sum of all per-transaction fees and the initial currency distribution of 25 BTC. The remainder of a transaction when input value exceeds output value becomes the transaction fee, which is paid to the miner. However, the protocol prevents zero-output, give-it-all-to-the-miner transactions. Adam suggests changing the output sum > 0BTC limitation to >= to allow for closer approximation of give-to-miner transactions.The possibility of a pool locking the reward instead of receiving or destroying it is mentioned. Gregory Maxwell's idea of using a Merkle Sum tree to split one sacrifice among many users is discussed. The responder also suggests committing the sacrifice to a pubkey and making signatures to say what the new balance is for each message. Trusting nodes to give accurate balances is considered adequate for DoS protection.In an email exchange between Adam Back and Jeff Garzik, the topic of destroy-via-miner-fee is discussed. A destroy-by-miner fee transaction is a normal bitcoin transaction sent by any user, where the remainder becomes the transaction fee if input value exceeds output value. The miner's reward is the initial currency distribution of 25 BTC plus the sum of all per-transaction fees. However, the protocol prevents zero-output, give-it-all-to-the-miner transactions.Peter's proof-of-sacrifice, which uses time-stamped difficulty coordinated inflation control, is discussed as an alternative method of destroying Bitcoin. It is mentioned that values are too low to spam the blockchain, making them payable to the identity of the recipient. Different ideas are presented, such as amortizable hashcash under-contribution and using a merkle root instead of a public key hash in the reward recipient address field. The creation cost of an anonymous identity called SIN is also discussed, where a specified amount of bitcoins is burned via miner fee to create a SIN. This provides a positive feedback loop for miners who receive fees via such services.Merge-mining and its benefits are discussed, including Peter's coinbase hashcash protocol. The email thread introduces three options for destroying bitcoin: merged-mine, destroy-via-miner-fee, and anyone-can-spend. It also mentions the possibility of creating an anonymous identity called SIN, associated with a bitcoin transaction's miner fee.Adam Back has a discussion with Peter about a new proposal that is not merge-mining. Peter's coinbase hashcash protocol ensures that mining the hashcash costs the miner at least some well-defined amount. Peter's ideas include using blockchain headers over DNS or a twitter system to combat spam and create merged stamps. The widely distributed blockchain header data can be used as an anti-spam measure. The discussion also touches on Rivest's PayWord as a mechanism for low-value micro-payments and making DoS attacks expensive enough to be impractical. PowPay is introduced as a method providing greater scalability than Bitcoin but with limitations in actual fund transfers per second.In May 2013, an email conversation between John Dillon and Peter Todd discusses merge-mining and its protocol. It mentions three options for miners: merged-mine, destroy bitcoin, or anyone-can-spend. Publicly auditable pooled mining protocols are suggested as a starting point for respendable micropayments. The use of blockchain header data in naming systems is also mentioned.Overall, the context provides insights into different methods of rewarding miners, creating anonymous identities, destroying bitcoin, merge-mining, and exploring alternative solutions to combat spam and enable micro-payments. 2013-05-14T20:07:31+00:00 + In a conversation between Jeff Garzik and Adam in May 2013, they discuss different methods of rewarding miners for their work in verifying transactions and adding blocks to the blockchain. Jeff mentions that if a promised transaction to the miner is not an integral part of the reward transaction, the user may choose to withhold it, which is not ideal. He suggests proof that they directly mined a block with a coinbase that immediately makes payment to future miners as a better method. This has several advantages, including not creating new traffic for the bitcoin network, easy verification on the blockchain, and the ability to be bound to a service if micro-mined on the spot. Jeff believes that ideally, one should simultaneously mine and give a reward to future block miners.The idea of creating an anonymous identity using a decentralized approach is discussed as a solution to the problem of not being able to create Google accounts via Tor without a phone number. The concept involves a server generating transactions with pubkeys owned by private keys to prove ownership of the passport/fidelity bond. This could be used on platforms like MediaWiki, Wordpress, or phpBB to prevent spam and abuse.Jeff explains that the miner's reward for processing transactions is the sum of all per-transaction fees and the initial currency distribution of 25 BTC. The remainder of a transaction when input value exceeds output value becomes the transaction fee, which is paid to the miner. However, the protocol prevents zero-output, give-it-all-to-the-miner transactions. Adam suggests changing the output sum > 0BTC limitation to >= to allow for closer approximation of give-to-miner transactions.The possibility of a pool locking the reward instead of receiving or destroying it is mentioned. Gregory Maxwell's idea of using a Merkle Sum tree to split one sacrifice among many users is discussed. The responder also suggests committing the sacrifice to a pubkey and making signatures to say what the new balance is for each message. Trusting nodes to give accurate balances is considered adequate for DoS protection.In an email exchange between Adam Back and Jeff Garzik, the topic of destroy-via-miner-fee is discussed. A destroy-by-miner fee transaction is a normal bitcoin transaction sent by any user, where the remainder becomes the transaction fee if input value exceeds output value. The miner's reward is the initial currency distribution of 25 BTC plus the sum of all per-transaction fees. However, the protocol prevents zero-output, give-it-all-to-the-miner transactions.Peter's proof-of-sacrifice, which uses time-stamped difficulty coordinated inflation control, is discussed as an alternative method of destroying Bitcoin. It is mentioned that values are too low to spam the blockchain, making them payable to the identity of the recipient. Different ideas are presented, such as amortizable hashcash under-contribution and using a merkle root instead of a public key hash in the reward recipient address field. The creation cost of an anonymous identity called SIN is also discussed, where a specified amount of bitcoins is burned via miner fee to create a SIN. This provides a positive feedback loop for miners who receive fees via such services.Merge-mining and its benefits are discussed, including Peter's coinbase hashcash protocol. The email thread introduces three options for destroying bitcoin: merged-mine, destroy-via-miner-fee, and anyone-can-spend. It also mentions the possibility of creating an anonymous identity called SIN, associated with a bitcoin transaction's miner fee.Adam Back has a discussion with Peter about a new proposal that is not merge-mining. Peter's coinbase hashcash protocol ensures that mining the hashcash costs the miner at least some well-defined amount. Peter's ideas include using blockchain headers over DNS or a twitter system to combat spam and create merged stamps. The widely distributed blockchain header data can be used as an anti-spam measure. The discussion also touches on Rivest's PayWord as a mechanism for low-value micro-payments and making DoS attacks expensive enough to be impractical. PowPay is introduced as a method providing greater scalability than Bitcoin but with limitations in actual fund transfers per second.In May 2013, an email conversation between John Dillon and Peter Todd discusses merge-mining and its protocol. It mentions three options for miners: merged-mine, destroy bitcoin, or anyone-can-spend. Publicly auditable pooled mining protocols are suggested as a starting point for respendable micropayments. The use of blockchain header data in naming systems is also mentioned.Overall, the context provides insights into different methods of rewarding miners, creating anonymous identities, destroying bitcoin, merge-mining, and exploring alternative solutions to combat spam and enable micro-payments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2013/combined_minor-bitcoin-qt-gripes-moving-BTC-off-specific-key.xml b/static/bitcoin-dev/May_2013/combined_minor-bitcoin-qt-gripes-moving-BTC-off-specific-key.xml index 5862237271..e38e7f3ce3 100644 --- a/static/bitcoin-dev/May_2013/combined_minor-bitcoin-qt-gripes-moving-BTC-off-specific-key.xml +++ b/static/bitcoin-dev/May_2013/combined_minor-bitcoin-qt-gripes-moving-BTC-off-specific-key.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - minor bitcoin-qt gripes moving BTC off specific key - 2023-08-01T04:50:39.657773+00:00 + 2025-10-11T21:33:34.268968+00:00 + python-feedgen Jesus Cea 2013-05-10 15:27:34+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - minor bitcoin-qt gripes moving BTC off specific key - 2023-08-01T04:50:39.657773+00:00 + 2025-10-11T21:33:34.269145+00:00 - In a discussion about Bitcoin security, Adam Back and Craig raise concerns about the current functionality of Bitcoin wallets. Craig suggests using the JSON API to unlock a wallet without displaying the password on the console screen, but Adam Back points out that this method may not work on all systems and could be vulnerable to spyware monitoring passwords. Adam Back also raises the issue of needing a way to transfer BTC off a specific address without spending the entire wallet balance, which creates more network traffic, higher fees, and damages privacy.At ZKS, pseudonyms are used to segregate online linkability for different purposes, but people still make mistakes and accidentally link all their coin sources. There is a need for a privacy algorithm to minimize cross-linking of coin sources and allow users to control which address the payment is from. Misbehavers could be blocked based on pseudonym in ZKS. The current Bitcoind's RPC client is not suitable for many features, and it would be better to provide a feature-rich Python RPC client. Instead of per-key fiddling in the GUI, it is recommended to use entire-wallet export and import. Coin control should be implemented for transferring BTC off a specific address.In an email thread from May 7, 2013, Adam Back, Pieter, and Gavin Andresen discuss possible improvements to Bitcoin's functionality. Adam Back suggests the need for a way to unlock the wallet without displaying the password on the console screen when importing a private key. Pieter recommends a Python RPC client with enhanced features, such as remembering passwords and batch lookups of compound commands. Adding a button to import a private key with an option to transfer it to another key is also discussed, but Pieter advises against per-key fiddling in the GUI. Instead, entire-wallet export and import are recommended. The need to transfer BTC off a specific address without spending the entire wallet balance is also raised, and Pieter suggests adding this capability to coin control.Gavin Andresen agrees with the idea of implementing a "sweep private key" feature and even suggests the possibility of periodic sweeping, although it would require remembering the key. However, he cautions against adding a user-friendly option to import private keys into the wallet due to potential dangers and confusion. Wladimir suggests censoring certain command arguments in the console screen and command line history to address the issue of displaying passwords. Overall, the discussions highlight the need for improvements in Bitcoin wallets, including enhanced security measures, better user experience, and privacy-preserving features. The developers propose various solutions, such as Python RPC clients, entire-wallet export/import, and coin control, to address these concerns. 2013-05-10T15:27:34+00:00 + In a discussion about Bitcoin security, Adam Back and Craig raise concerns about the current functionality of Bitcoin wallets. Craig suggests using the JSON API to unlock a wallet without displaying the password on the console screen, but Adam Back points out that this method may not work on all systems and could be vulnerable to spyware monitoring passwords. Adam Back also raises the issue of needing a way to transfer BTC off a specific address without spending the entire wallet balance, which creates more network traffic, higher fees, and damages privacy.At ZKS, pseudonyms are used to segregate online linkability for different purposes, but people still make mistakes and accidentally link all their coin sources. There is a need for a privacy algorithm to minimize cross-linking of coin sources and allow users to control which address the payment is from. Misbehavers could be blocked based on pseudonym in ZKS. The current Bitcoind's RPC client is not suitable for many features, and it would be better to provide a feature-rich Python RPC client. Instead of per-key fiddling in the GUI, it is recommended to use entire-wallet export and import. Coin control should be implemented for transferring BTC off a specific address.In an email thread from May 7, 2013, Adam Back, Pieter, and Gavin Andresen discuss possible improvements to Bitcoin's functionality. Adam Back suggests the need for a way to unlock the wallet without displaying the password on the console screen when importing a private key. Pieter recommends a Python RPC client with enhanced features, such as remembering passwords and batch lookups of compound commands. Adding a button to import a private key with an option to transfer it to another key is also discussed, but Pieter advises against per-key fiddling in the GUI. Instead, entire-wallet export and import are recommended. The need to transfer BTC off a specific address without spending the entire wallet balance is also raised, and Pieter suggests adding this capability to coin control.Gavin Andresen agrees with the idea of implementing a "sweep private key" feature and even suggests the possibility of periodic sweeping, although it would require remembering the key. However, he cautions against adding a user-friendly option to import private keys into the wallet due to potential dangers and confusion. Wladimir suggests censoring certain command arguments in the console screen and command line history to address the issue of displaying passwords. Overall, the discussions highlight the need for improvements in Bitcoin wallets, including enhanced security measures, better user experience, and privacy-preserving features. The developers propose various solutions, such as Python RPC clients, entire-wallet export/import, and coin control, to address these concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_-QT-Feature-proposal-Displaying-current-Units-Changing-Units-with-status-bar-control-.xml b/static/bitcoin-dev/May_2014/combined_-QT-Feature-proposal-Displaying-current-Units-Changing-Units-with-status-bar-control-.xml index dabe6a5ff4..a09366bf28 100644 --- a/static/bitcoin-dev/May_2014/combined_-QT-Feature-proposal-Displaying-current-Units-Changing-Units-with-status-bar-control-.xml +++ b/static/bitcoin-dev/May_2014/combined_-QT-Feature-proposal-Displaying-current-Units-Changing-Units-with-status-bar-control-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [QT] Feature proposal: Displaying current Units/Changing Units with status bar control. - 2023-08-01T09:24:54.803575+00:00 + 2025-10-11T22:19:56.959030+00:00 + python-feedgen Angel Leon 2014-06-02 19:41:12+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - [QT] Feature proposal: Displaying current Units/Changing Units with status bar control. - 2023-08-01T09:24:54.803575+00:00 + 2025-10-11T22:19:56.959161+00:00 - Angel has shared an update regarding the addition of features to a project. The update includes showing the current unit on the header column title "Amount ($unitHere)" and adding a confirmation dialog to prevent users from changing the current unit of display by mistake. Gregory Maxwell suggests that if a global setting is added in the status bar, it should be done in a way where it's impossible for a stray keypress to switch it.In an email dated June 2, 2014, Wladimir expressed uncertainty about the potential benefits of a global setting in the status bar. He suggested that such a setting might make it more clear to users that multiple units can be selected. However, he also cautioned that any implementation should ensure that a stray keypress could not accidentally switch the setting, as this could result in serious consequences for the user.In a conversation between Angel Leon and Wladimir, they are discussing the addition of a global setting in the status bar for Bitcoin. Angel shares an attachment and asks for feedback on whether this would be valuable in terms of user experience. Wladimir responds that they already allow specifying a unit in all places where the user can specify a BTC amount, and show the unit in all places where amounts are shown except for tables. He suggests adding a [unit] in the table header and is unsure how much a global setting in the status bar would add. Additionally, he notes that it may make it more apparent to the user that multiple units can be selected. There is also a link to an issue on Github related to adding the [unit] in the table header.In this email exchange, Angel Leon proposes the idea of a status bar component that would show the current unit of display and allow users to easily change it. The context is around the default unit of display for Bitcoin transactions, with debate over whether it should be BTC or mBTC. The dropdown menu for changing the unit of display would be a common part of the layout, but a slight optimization suggested was to also include the unit in the transaction table header so that users don't have to think about the unit of their values. Leon includes an attachment of how the status bar component would look and asks for feedback before submitting a pull request.There has been a debate over the default unit of display to use for Bitcoin transactions. The conversation can be found on GitHub and was closed. Regular users may have trouble finding a way to change the current unit of display, so having a status bar component that shows the current unit of display and allows easy changing could be beneficial. The proposed component would show the current unit of display at all times and allow users to easily change it. Feedback is being requested before submitting a pull request to polish the component. 2014-06-02T19:41:12+00:00 + Angel has shared an update regarding the addition of features to a project. The update includes showing the current unit on the header column title "Amount ($unitHere)" and adding a confirmation dialog to prevent users from changing the current unit of display by mistake. Gregory Maxwell suggests that if a global setting is added in the status bar, it should be done in a way where it's impossible for a stray keypress to switch it.In an email dated June 2, 2014, Wladimir expressed uncertainty about the potential benefits of a global setting in the status bar. He suggested that such a setting might make it more clear to users that multiple units can be selected. However, he also cautioned that any implementation should ensure that a stray keypress could not accidentally switch the setting, as this could result in serious consequences for the user.In a conversation between Angel Leon and Wladimir, they are discussing the addition of a global setting in the status bar for Bitcoin. Angel shares an attachment and asks for feedback on whether this would be valuable in terms of user experience. Wladimir responds that they already allow specifying a unit in all places where the user can specify a BTC amount, and show the unit in all places where amounts are shown except for tables. He suggests adding a [unit] in the table header and is unsure how much a global setting in the status bar would add. Additionally, he notes that it may make it more apparent to the user that multiple units can be selected. There is also a link to an issue on Github related to adding the [unit] in the table header.In this email exchange, Angel Leon proposes the idea of a status bar component that would show the current unit of display and allow users to easily change it. The context is around the default unit of display for Bitcoin transactions, with debate over whether it should be BTC or mBTC. The dropdown menu for changing the unit of display would be a common part of the layout, but a slight optimization suggested was to also include the unit in the transaction table header so that users don't have to think about the unit of their values. Leon includes an attachment of how the status bar component would look and asks for feedback before submitting a pull request.There has been a debate over the default unit of display to use for Bitcoin transactions. The conversation can be found on GitHub and was closed. Regular users may have trouble finding a way to change the current unit of display, so having a status bar component that shows the current unit of display and allows easy changing could be beneficial. The proposed component would show the current unit of display at all times and allow users to easily change it. Feedback is being requested before submitting a pull request to polish the component. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_-bits-Unit-of-account.xml b/static/bitcoin-dev/May_2014/combined_-bits-Unit-of-account.xml index 1b82e6909d..d731110db0 100644 --- a/static/bitcoin-dev/May_2014/combined_-bits-Unit-of-account.xml +++ b/static/bitcoin-dev/May_2014/combined_-bits-Unit-of-account.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - "bits": Unit of account - 2023-08-01T08:50:32.136441+00:00 + Combined summary - "bits": Unit of account + 2025-10-11T22:19:31.449789+00:00 + python-feedgen Gordon Mohr 2014-05-05 22:33:37+00:00 @@ -227,13 +228,13 @@ - python-feedgen + 2 - Combined summary - "bits": Unit of account - 2023-08-01T08:50:32.137483+00:00 + Combined summary - "bits": Unit of account + 2025-10-11T22:19:31.450056+00:00 - In an email thread from April 2014, the Bitcoin development mailing list discussed possible names for smaller units of bitcoin. Mike Caldwell suggested "bit" as a short, memorable, and pronounceable option. However, it was noted that "bit" phonetically collides with slang for phallus in French and means "louse" in Turkish. Justin A proposed "ubit," pronounced "YOU-bit," representing 1e-6 bitcoin, which ties visually to the metric micro and leaves the required 2 decimal places. The discussion also considered using a letter before "bit," such as "ebit" or "xbit," the latter being XBT. Despite these suggestions, some believed that no term for smaller units had yet established itself.The conversation focused on finding a culturally neutral term for a unit representing 1e-6 bitcoin. The suggestion of "ubit" was made, but concerns were raised about the pronunciation and potential confusion with the term "XBT." Culturally neutral names were preferred to avoid invoking specific cultural references. It was pointed out that "bit" has conflicting meanings in different languages. Some participants believed that terms for smaller units would arise naturally over time. The email also included information on joining the Bitcoin development mailing list and a link to a free book on graph databases.The discussion emphasized the importance of finding a culturally neutral name for smaller units of bitcoin. Suggestions included "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about using the term "bit" due to its conflicting meanings in different languages. It was mentioned that terms for smaller units would likely establish themselves over time. Additionally, a link to a free book on graph databases was provided.The email conversation highlighted the need for a culturally neutral term for smaller units of bitcoin. The discussion included suggestions such as "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about the conflicting meanings of "bit" in different languages. The importance of avoiding cultural references in the name was emphasized. The conversation also included information on joining the Bitcoin development mailing list and a link to a free book on graph databases.The discussion revolved around finding a culturally neutral term for smaller units of bitcoin. Suggestions included "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about the conflicting meanings of "bit" in different languages. Some participants believed that terms for smaller units would arise naturally over time. The email also included a link to a free book on graph databases and information on joining the Bitcoin development mailing list.The discussion on Bitcoin denominations has been ongoing since 2013, with suggestions for alternative units such as XBT and bits. Some members of the community support the idea of using "bits" as a new unit of measurement for Bitcoin, while others have concerns about the term being too overloaded. Armory, a Bitcoin wallet, has started integrating alternative units, but more work is needed. Alan Reiner, the founder of Armory, supports the use of "microbitcoin" as a default unit but is unsure about the name "bits." Tamas Blummer suggests taking the discussion to wallet developers rather than engineers. Rob Golding proposes offering users the option to denominate Bitcoin currency in a unit called a bit, where one bitcoin equals one million bits and one bit equals 100 satoshis.The email thread among members of the Bitcoin-development mailing list discusses the proposal to introduce a new unit of account called "bits." The proposal suggests that one bitcoin would equal one million bits and one bit would equal 100 satoshis. Some members express concern about introducing a new prefix, while others argue that it may not be necessary given the existing divisions in u/mBTC. There are also concerns about confusion for average users and potential errors in transactions. Tamas Blummer suggests bringing the discussion to wallet developers, and Rob Golding recommends using satoshis instead of bits for simplicity.The discussion highlights the divergent views within the Bitcoin community regarding changes to the system. Some believe convention changes should apply to all clients, while others argue that these discussions should involve wallet developers. Ultimately, any decision on denomination would require consensus among stakeholders in the Bitcoin ecosystem.The proposal to denominate Bitcoin currency in units called bits has sparked debate among Bitcoin developers. Some argue that the term "bit" is already used in computer science and could cause confusion. Others suggest that people can choose other divisions if they prefer or use satoshis for simplicity. The discussion includes suggestions to bring the topic to wallet developers and concerns about potential errors in transactions.To address the issue of decimal problems in Bitcoin transactions, a proposal has been made to introduce a new unit called "bit." One bitcoin would equal one million bits, and one bit would equal 100 satoshis. This proposal aims to simplify the process and make it easier for users to understand. Further discussions on this topic can be 2014-05-05T22:33:37+00:00 + In an email thread from April 2014, the Bitcoin development mailing list discussed possible names for smaller units of bitcoin. Mike Caldwell suggested "bit" as a short, memorable, and pronounceable option. However, it was noted that "bit" phonetically collides with slang for phallus in French and means "louse" in Turkish. Justin A proposed "ubit," pronounced "YOU-bit," representing 1e-6 bitcoin, which ties visually to the metric micro and leaves the required 2 decimal places. The discussion also considered using a letter before "bit," such as "ebit" or "xbit," the latter being XBT. Despite these suggestions, some believed that no term for smaller units had yet established itself.The conversation focused on finding a culturally neutral term for a unit representing 1e-6 bitcoin. The suggestion of "ubit" was made, but concerns were raised about the pronunciation and potential confusion with the term "XBT." Culturally neutral names were preferred to avoid invoking specific cultural references. It was pointed out that "bit" has conflicting meanings in different languages. Some participants believed that terms for smaller units would arise naturally over time. The email also included information on joining the Bitcoin development mailing list and a link to a free book on graph databases.The discussion emphasized the importance of finding a culturally neutral name for smaller units of bitcoin. Suggestions included "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about using the term "bit" due to its conflicting meanings in different languages. It was mentioned that terms for smaller units would likely establish themselves over time. Additionally, a link to a free book on graph databases was provided.The email conversation highlighted the need for a culturally neutral term for smaller units of bitcoin. The discussion included suggestions such as "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about the conflicting meanings of "bit" in different languages. The importance of avoiding cultural references in the name was emphasized. The conversation also included information on joining the Bitcoin development mailing list and a link to a free book on graph databases.The discussion revolved around finding a culturally neutral term for smaller units of bitcoin. Suggestions included "ubit" pronounced as "you-bit," which tied visually to the metric micro. Concerns were raised about the conflicting meanings of "bit" in different languages. Some participants believed that terms for smaller units would arise naturally over time. The email also included a link to a free book on graph databases and information on joining the Bitcoin development mailing list.The discussion on Bitcoin denominations has been ongoing since 2013, with suggestions for alternative units such as XBT and bits. Some members of the community support the idea of using "bits" as a new unit of measurement for Bitcoin, while others have concerns about the term being too overloaded. Armory, a Bitcoin wallet, has started integrating alternative units, but more work is needed. Alan Reiner, the founder of Armory, supports the use of "microbitcoin" as a default unit but is unsure about the name "bits." Tamas Blummer suggests taking the discussion to wallet developers rather than engineers. Rob Golding proposes offering users the option to denominate Bitcoin currency in a unit called a bit, where one bitcoin equals one million bits and one bit equals 100 satoshis.The email thread among members of the Bitcoin-development mailing list discusses the proposal to introduce a new unit of account called "bits." The proposal suggests that one bitcoin would equal one million bits and one bit would equal 100 satoshis. Some members express concern about introducing a new prefix, while others argue that it may not be necessary given the existing divisions in u/mBTC. There are also concerns about confusion for average users and potential errors in transactions. Tamas Blummer suggests bringing the discussion to wallet developers, and Rob Golding recommends using satoshis instead of bits for simplicity.The discussion highlights the divergent views within the Bitcoin community regarding changes to the system. Some believe convention changes should apply to all clients, while others argue that these discussions should involve wallet developers. Ultimately, any decision on denomination would require consensus among stakeholders in the Bitcoin ecosystem.The proposal to denominate Bitcoin currency in units called bits has sparked debate among Bitcoin developers. Some argue that the term "bit" is already used in computer science and could cause confusion. Others suggest that people can choose other divisions if they prefer or use satoshis for simplicity. The discussion includes suggestions to bring the topic to wallet developers and concerns about potential errors in transactions.To address the issue of decimal problems in Bitcoin transactions, a proposal has been made to introduce a new unit called "bit." One bitcoin would equal one million bits, and one bit would equal 100 satoshis. This proposal aims to simplify the process and make it easier for users to understand. Further discussions on this topic can be - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_-no-subject-.xml b/static/bitcoin-dev/May_2014/combined_-no-subject-.xml index a09c8867b3..f6e67641cc 100644 --- a/static/bitcoin-dev/May_2014/combined_-no-subject-.xml +++ b/static/bitcoin-dev/May_2014/combined_-no-subject-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - (no subject) - 2023-08-01T05:01:33.099019+00:00 + 2025-10-11T22:20:01.215771+00:00 + python-feedgen Btc Drak 2016-10-17 13:13:25+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - (no subject) - 2023-08-01T05:01:33.099019+00:00 + 2025-10-11T22:20:01.215940+00:00 - On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. 2016-10-17T13:13:25+00:00 + On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_A-statistical-consensus-rule-for-reducing-0-conf-double-spend-risk.xml b/static/bitcoin-dev/May_2014/combined_A-statistical-consensus-rule-for-reducing-0-conf-double-spend-risk.xml index ccabc2b308..90dfda37f7 100644 --- a/static/bitcoin-dev/May_2014/combined_A-statistical-consensus-rule-for-reducing-0-conf-double-spend-risk.xml +++ b/static/bitcoin-dev/May_2014/combined_A-statistical-consensus-rule-for-reducing-0-conf-double-spend-risk.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A statistical consensus rule for reducing 0-conf double-spend risk - 2023-08-01T09:11:42.920921+00:00 + 2025-10-11T22:19:22.948291+00:00 + python-feedgen Tom Harding 2014-05-12 13:04:47+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - A statistical consensus rule for reducing 0-conf double-spend risk - 2023-08-01T09:11:42.920921+00:00 + 2025-10-11T22:19:22.948511+00:00 - In an email thread between Tom Harding and some Bitcoin developers, a correction was made to the calculation of the cost of double-spending. The new approximation requires the rule-following minority to find the next two blocks, resulting in a lower bound cost of .0025 BTC for one transaction. If a miner includes a seasoned double-spend despite the rule, he still loses at least .25 BTC, which is about 1000x the typical "double-spend premium." Christophe Biocca commented that the current rule is unenforceable in a discussion about Bitcoin's double-spend problem. Biocca explained that no miner would wait before mining on the longest chain, which would be a rational move. In a scenario where a miner decided to include a "seasoned" double-spend in his block, despite the rule, the expected cost of including the respend would be any revenue loss from doing so. If only 1% of hashpower follows the rule, the miner would still lose at least .25 BTC. This amount is about 1000x the typical "double-spend premium." Biocca questioned whether the greedy-rational miner would decide to include the earlier spend instead.In a discussion about Bitcoin's transaction confirmation time, Christophe Biocca suggests that it is easy to split the network into two halves by ordering transactions in a specific way. However, Tom Harding points out that this is not a practical solution and proposes a consensus rule to prevent double-spending attacks. This rule states that blocks containing a transaction (tx2) that spends an output of another locally accepted transaction (tx1) should not be accepted if the timestamp of tx2 minus the timestamp of tx1 is greater than T. The use of this rule would help prevent 50% of nodes from misidentifying respend attempts.A proposal was made on bitcointalk.org to address the issue of double-spending and lack of consensus in the blockchain. The proposal involves associating a timestamp with every transaction and adding a consensus rule that rejects blocks containing a transaction that respends an output spent by another locally accepted transaction if the time difference between the two transactions is greater than a certain threshold (T). The suggested threshold is T = 7.4 seconds, which would result in misidentification of the second spend by less than 1% of nodes. However, this proposal could potentially fork the network permanently since there is no magic way to achieve consensus, making it easy to split the network into two halves. To avoid this, a way to reconcile the split is necessary, such as accepting the offending block once it's two or more deep. But since the rule isn't enforceable, miners are likely to continue mining on the longest chain, rendering the proposal ineffective. The proposal presents the first consensus rule that anticipates less than 100% agreement, but the parameters can be chosen to remain conservative. Additionally, a fail-safe condition was suggested to drop the rule if a block has six confirmations to prevent a fork in unusual network circumstances.On February 14, 2011, a user named "Joe" suggested a new idea for blockchain technology in the Bitcointalk forum. Currently, nodes decide which of several conflicting transactions to accept and which is a double-spend, but there is no incorporation of these collective judgments into the blockchain. Joe proposed that nodes should associate a timestamp with every transaction upon first seeing it and add a consensus rule to reject blocks containing a transaction that respends an output spent by another locally accepted transaction after a certain amount of time has passed. The value of T, or the time threshold, was calculated based on the assumption that if a double-spender introduces both transactions from the same node, the median propagation time for recent transactions is 1.3 seconds, and the propagation times are distributed exponentially with a median of 1.3 seconds, then the above consensus rule would result in the misidentification of the second spend by less than 1% of nodes if T is set to 7.4 seconds. If transactions are introduced in mutually time-distant parts of the network, a population of nodes in between would be able to accept either transaction as they can today. However, the attacker still needs to introduce them at close to the same time, or the majority of the network will confirm the one introduced earlier. The merchant is also able to watch for double-spending attempts and gain confidence quickly if he is likely to be double-spent.The proposed consensus rule would be the first to anticipate less than 100% agreement, but the parameters could be chosen so that it remains conservative. Joe also suggested a fail-safe condition: drop the rule if the block has six confirmations to prevent a fork in unusual network circumstances. The first step towards implementing this solution is to share data broadly by relaying first double-spend attempts. 2014-05-12T13:04:47+00:00 + In an email thread between Tom Harding and some Bitcoin developers, a correction was made to the calculation of the cost of double-spending. The new approximation requires the rule-following minority to find the next two blocks, resulting in a lower bound cost of .0025 BTC for one transaction. If a miner includes a seasoned double-spend despite the rule, he still loses at least .25 BTC, which is about 1000x the typical "double-spend premium." Christophe Biocca commented that the current rule is unenforceable in a discussion about Bitcoin's double-spend problem. Biocca explained that no miner would wait before mining on the longest chain, which would be a rational move. In a scenario where a miner decided to include a "seasoned" double-spend in his block, despite the rule, the expected cost of including the respend would be any revenue loss from doing so. If only 1% of hashpower follows the rule, the miner would still lose at least .25 BTC. This amount is about 1000x the typical "double-spend premium." Biocca questioned whether the greedy-rational miner would decide to include the earlier spend instead.In a discussion about Bitcoin's transaction confirmation time, Christophe Biocca suggests that it is easy to split the network into two halves by ordering transactions in a specific way. However, Tom Harding points out that this is not a practical solution and proposes a consensus rule to prevent double-spending attacks. This rule states that blocks containing a transaction (tx2) that spends an output of another locally accepted transaction (tx1) should not be accepted if the timestamp of tx2 minus the timestamp of tx1 is greater than T. The use of this rule would help prevent 50% of nodes from misidentifying respend attempts.A proposal was made on bitcointalk.org to address the issue of double-spending and lack of consensus in the blockchain. The proposal involves associating a timestamp with every transaction and adding a consensus rule that rejects blocks containing a transaction that respends an output spent by another locally accepted transaction if the time difference between the two transactions is greater than a certain threshold (T). The suggested threshold is T = 7.4 seconds, which would result in misidentification of the second spend by less than 1% of nodes. However, this proposal could potentially fork the network permanently since there is no magic way to achieve consensus, making it easy to split the network into two halves. To avoid this, a way to reconcile the split is necessary, such as accepting the offending block once it's two or more deep. But since the rule isn't enforceable, miners are likely to continue mining on the longest chain, rendering the proposal ineffective. The proposal presents the first consensus rule that anticipates less than 100% agreement, but the parameters can be chosen to remain conservative. Additionally, a fail-safe condition was suggested to drop the rule if a block has six confirmations to prevent a fork in unusual network circumstances.On February 14, 2011, a user named "Joe" suggested a new idea for blockchain technology in the Bitcointalk forum. Currently, nodes decide which of several conflicting transactions to accept and which is a double-spend, but there is no incorporation of these collective judgments into the blockchain. Joe proposed that nodes should associate a timestamp with every transaction upon first seeing it and add a consensus rule to reject blocks containing a transaction that respends an output spent by another locally accepted transaction after a certain amount of time has passed. The value of T, or the time threshold, was calculated based on the assumption that if a double-spender introduces both transactions from the same node, the median propagation time for recent transactions is 1.3 seconds, and the propagation times are distributed exponentially with a median of 1.3 seconds, then the above consensus rule would result in the misidentification of the second spend by less than 1% of nodes if T is set to 7.4 seconds. If transactions are introduced in mutually time-distant parts of the network, a population of nodes in between would be able to accept either transaction as they can today. However, the attacker still needs to introduce them at close to the same time, or the majority of the network will confirm the one introduced earlier. The merchant is also able to watch for double-spending attempts and gain confidence quickly if he is likely to be double-spent.The proposed consensus rule would be the first to anticipate less than 100% agreement, but the parameters could be chosen so that it remains conservative. Joe also suggested a fail-safe condition: drop the rule if the block has six confirmations to prevent a fork in unusual network circumstances. The first step towards implementing this solution is to share data broadly by relaying first double-spend attempts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_About-the-small-number-of-bitcoin-nodes.xml b/static/bitcoin-dev/May_2014/combined_About-the-small-number-of-bitcoin-nodes.xml index 58099f7251..57f9cb4330 100644 --- a/static/bitcoin-dev/May_2014/combined_About-the-small-number-of-bitcoin-nodes.xml +++ b/static/bitcoin-dev/May_2014/combined_About-the-small-number-of-bitcoin-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - About the small number of bitcoin nodes - 2023-08-01T09:19:54.827817+00:00 + 2025-10-11T22:19:39.961547+00:00 + python-feedgen Wladimir 2014-06-30 10:16:01+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - About the small number of bitcoin nodes - 2023-08-01T09:19:54.827817+00:00 + 2025-10-11T22:19:39.961715+00:00 - The task at hand is to create a graphical interface for bitcoind on Linux servers. This interface should display a summary of necessary data for node administrators in the Terminal using ASCII characters. A tool called bitcoind-ncurses has already been developed for this purpose and is available on Github, but it is still in its early stages and may require assistance to become a fully-functional node admin tool.In a May 2014 email thread between Jeff Garzik and Raúl Martínez, the possibility of adding bitcoind and Bitcoin Core to Linux repositories is discussed. However, certain conditions must be met before this can happen. These conditions include allowing bitcoin developers to dictate which dependent libraries are shipped with or built statically into the bitcoin binaries/libs, enabling fresh updates to older stable distributions, and having active maintainers who closely follow bitcoin development and release status. Matt C's PPA is mentioned as an example of meeting these conditions in Ubuntu. It is noted that while conditions (1) and (3) are feasible, condition (2) poses difficulties due to Debian and Ubuntu policies. Alternative mechanisms such as backports, volatile, and updates repositories could meet condition (2), but user intervention is required, and they are not enabled by default. Debian unstable allows for condition (2), but the package is blocked from transitioning to a stable release. Matt C's PPA remains the best option for meeting all three conditions in Ubuntu, and the Debian unstable package is deemed the most suitable for Debian, although both require users to add a line to their apt sources list.The Bitcoin network is exploring ways to limit rates and improve block download reliability. One suggestion is to introduce a service bit indicating that a node has chain data and is willing to Bloom filter it for others, without serving full block data. This would allow home users with low tolerance for block chain uploads to contribute useful services to the network. The idea of an "archival node" service bit is also proposed. It is suggested that the capabilities of "I have CPU and can filter" and "I have bandwidth and can serve" should be separated more explicitly.In an email exchange between Bjørn Øivind Bjørnsen and Wladimir, the implementation of network rate limiting in the bitcoin codebase is discussed. While Bjørnsen, who is unfamiliar with the codebase, suggests adding network rate limiting as a feature, Wladimir informs him that an old patch already exists for it but will only be merged when headers-first and parallel block download are in place. Wladimir explains that it is safe to limit rates once the node can download blocks from multiple peers simultaneously. He mentions the script in contrib/qos as a trick to limit rates but emphasizes that it needs to be widely available first.Adding a node with slow upstream/downstream speed may slow down the network's bootstrap process, but it does not harm the network itself. Existing issues can already cause the download process to take several days, and using the torrent is a faster alternative. However, a slow node may impede parallel downloading for remote peers.In a discussion thread initiated by Mike Hearn, the issue of network rate limiting in Bitcoin Core is raised. While acknowledging the importance of this feature, its implementation is recognized as a challenging task. Additionally, it is noted that throttling one's connection would cause remote nodes to give up and rely more on unthrottled peers. Bjørn Øivind asks if adding a node with slow upstream/downstream speed could harm the network and shares his own experience of using QoS to throttle his node. The article delves into the implementation of network rate limiting in Bitcoin Core. One challenge highlighted is that Bitcoin Core does not detect if a remote peer is working slowly and switch to a faster one. Throttling one's connection would lead remote nodes to give up and rely more on unthrottled peers. The suggested approach is to implement chain pruning, allowing the node to shovel bytes as fast as possible but limiting it based on the number of bytes available. Remote nodes pulling down the block chain can then switch between nodes to avoid overburdening a single node. Extending the p2p protocol is also proposed, with addr broadcasts and version messages indicating how much of the chain a peer is willing to serve. This would enable smarter peer selection during downloading. However, progress on these ideas awaits the completion of merging headers-first downloading. The article encourages experimentation with these approaches.A discussion among developers in 2014 focuses on the small number of Bitcoin nodes and potential vulnerabilities resulting from this. Financial incentives are proposed as a means to encourage more people to run nodes. A tool similar to Tor's 'arm' is suggested to provide users with information such as bandwidth usage, CPU usage, connected peers, and active configurations. Felipe Micaroni Lalli, the developer of Bitcoin Paranoid Android, shares his contact details at the end of the email.In May 201 2014-06-30T10:16:01+00:00 + The task at hand is to create a graphical interface for bitcoind on Linux servers. This interface should display a summary of necessary data for node administrators in the Terminal using ASCII characters. A tool called bitcoind-ncurses has already been developed for this purpose and is available on Github, but it is still in its early stages and may require assistance to become a fully-functional node admin tool.In a May 2014 email thread between Jeff Garzik and Raúl Martínez, the possibility of adding bitcoind and Bitcoin Core to Linux repositories is discussed. However, certain conditions must be met before this can happen. These conditions include allowing bitcoin developers to dictate which dependent libraries are shipped with or built statically into the bitcoin binaries/libs, enabling fresh updates to older stable distributions, and having active maintainers who closely follow bitcoin development and release status. Matt C's PPA is mentioned as an example of meeting these conditions in Ubuntu. It is noted that while conditions (1) and (3) are feasible, condition (2) poses difficulties due to Debian and Ubuntu policies. Alternative mechanisms such as backports, volatile, and updates repositories could meet condition (2), but user intervention is required, and they are not enabled by default. Debian unstable allows for condition (2), but the package is blocked from transitioning to a stable release. Matt C's PPA remains the best option for meeting all three conditions in Ubuntu, and the Debian unstable package is deemed the most suitable for Debian, although both require users to add a line to their apt sources list.The Bitcoin network is exploring ways to limit rates and improve block download reliability. One suggestion is to introduce a service bit indicating that a node has chain data and is willing to Bloom filter it for others, without serving full block data. This would allow home users with low tolerance for block chain uploads to contribute useful services to the network. The idea of an "archival node" service bit is also proposed. It is suggested that the capabilities of "I have CPU and can filter" and "I have bandwidth and can serve" should be separated more explicitly.In an email exchange between Bjørn Øivind Bjørnsen and Wladimir, the implementation of network rate limiting in the bitcoin codebase is discussed. While Bjørnsen, who is unfamiliar with the codebase, suggests adding network rate limiting as a feature, Wladimir informs him that an old patch already exists for it but will only be merged when headers-first and parallel block download are in place. Wladimir explains that it is safe to limit rates once the node can download blocks from multiple peers simultaneously. He mentions the script in contrib/qos as a trick to limit rates but emphasizes that it needs to be widely available first.Adding a node with slow upstream/downstream speed may slow down the network's bootstrap process, but it does not harm the network itself. Existing issues can already cause the download process to take several days, and using the torrent is a faster alternative. However, a slow node may impede parallel downloading for remote peers.In a discussion thread initiated by Mike Hearn, the issue of network rate limiting in Bitcoin Core is raised. While acknowledging the importance of this feature, its implementation is recognized as a challenging task. Additionally, it is noted that throttling one's connection would cause remote nodes to give up and rely more on unthrottled peers. Bjørn Øivind asks if adding a node with slow upstream/downstream speed could harm the network and shares his own experience of using QoS to throttle his node. The article delves into the implementation of network rate limiting in Bitcoin Core. One challenge highlighted is that Bitcoin Core does not detect if a remote peer is working slowly and switch to a faster one. Throttling one's connection would lead remote nodes to give up and rely more on unthrottled peers. The suggested approach is to implement chain pruning, allowing the node to shovel bytes as fast as possible but limiting it based on the number of bytes available. Remote nodes pulling down the block chain can then switch between nodes to avoid overburdening a single node. Extending the p2p protocol is also proposed, with addr broadcasts and version messages indicating how much of the chain a peer is willing to serve. This would enable smarter peer selection during downloading. However, progress on these ideas awaits the completion of merging headers-first downloading. The article encourages experimentation with these approaches.A discussion among developers in 2014 focuses on the small number of Bitcoin nodes and potential vulnerabilities resulting from this. Financial incentives are proposed as a means to encourage more people to run nodes. A tool similar to Tor's 'arm' is suggested to provide users with information such as bandwidth usage, CPU usage, connected peers, and active configurations. Felipe Micaroni Lalli, the developer of Bitcoin Paranoid Android, shares his contact details at the end of the email.In May 201 - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Allow-cross-site-requests-of-payment-requests.xml b/static/bitcoin-dev/May_2014/combined_Allow-cross-site-requests-of-payment-requests.xml index 15d6efa608..452b1827ad 100644 --- a/static/bitcoin-dev/May_2014/combined_Allow-cross-site-requests-of-payment-requests.xml +++ b/static/bitcoin-dev/May_2014/combined_Allow-cross-site-requests-of-payment-requests.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Allow cross-site requests of payment requests - 2023-08-01T09:14:07.238438+00:00 + 2025-10-11T22:20:28.893788+00:00 + python-feedgen Andy Alness 2014-05-12 17:21:33+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Allow cross-site requests of payment requests - 2023-08-01T09:14:07.239440+00:00 + 2025-10-11T22:20:28.893959+00:00 - The discussion revolves around the security concerns associated with mobile code fetching random web resources, which can lead to unexpected security vulnerabilities. The proposal suggests allowing payment requests/payments to be accessed cross-site, as they already need to be publicly accessible endpoints from the server's perspective. However, implementing the payment protocol in browser-sandboxed JavaScript would require someone willing to fully implement it, including features like root cert store, ASN.1 parsing, and RSA.Despite the challenges, there is still value in fetching the payment request cross-site, even if the request payload is validated by a third party using a more conventional TLS/crypto suite. The author finds the idea of exposing x.509/RSA/ASN.1/chain verification functionality in browsers to be beneficial and easily achievable. However, the author acknowledges that without the ability to implement this proposal, it is unlikely to gain popularity.Another point of discussion is amending BIP 70, which suggests including an "Access-Control-Allow-Origin: *" response header for payment request responses. This amendment aims to prevent security vulnerabilities arising from mobile code fetching random web resources. Implementing the payment protocol in browser-sandboxed JavaScript may not be widely accepted, making the usefulness of this suggestion uncertain.Andy proposes amending BIP 70 to recommend implementers to include the "Access-Control-Allow-Origin: *" response header for their payment request responses. This approach would allow HTML5 web wallets to use the payment protocol entirely within the browser, eliminating the need for the server hosting the wallet's HTML to fetch payment requests on behalf of the browser. Andy argues that this method is more elegant and has fewer security and resource implications for the back-end. He also believes that this amendment does not introduce any significant attack vectors. 2014-05-12T17:21:33+00:00 + The discussion revolves around the security concerns associated with mobile code fetching random web resources, which can lead to unexpected security vulnerabilities. The proposal suggests allowing payment requests/payments to be accessed cross-site, as they already need to be publicly accessible endpoints from the server's perspective. However, implementing the payment protocol in browser-sandboxed JavaScript would require someone willing to fully implement it, including features like root cert store, ASN.1 parsing, and RSA.Despite the challenges, there is still value in fetching the payment request cross-site, even if the request payload is validated by a third party using a more conventional TLS/crypto suite. The author finds the idea of exposing x.509/RSA/ASN.1/chain verification functionality in browsers to be beneficial and easily achievable. However, the author acknowledges that without the ability to implement this proposal, it is unlikely to gain popularity.Another point of discussion is amending BIP 70, which suggests including an "Access-Control-Allow-Origin: *" response header for payment request responses. This amendment aims to prevent security vulnerabilities arising from mobile code fetching random web resources. Implementing the payment protocol in browser-sandboxed JavaScript may not be widely accepted, making the usefulness of this suggestion uncertain.Andy proposes amending BIP 70 to recommend implementers to include the "Access-Control-Allow-Origin: *" response header for their payment request responses. This approach would allow HTML5 web wallets to use the payment protocol entirely within the browser, eliminating the need for the server hosting the wallet's HTML to fetch payment requests on behalf of the browser. Andy argues that this method is more elegant and has fewer security and resource implications for the back-end. He also believes that this amendment does not introduce any significant attack vectors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Announcing-the-Statoshi-fork.xml b/static/bitcoin-dev/May_2014/combined_Announcing-the-Statoshi-fork.xml index c16c89d7e9..d673c6fa4c 100644 --- a/static/bitcoin-dev/May_2014/combined_Announcing-the-Statoshi-fork.xml +++ b/static/bitcoin-dev/May_2014/combined_Announcing-the-Statoshi-fork.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Announcing the Statoshi fork - 2023-08-01T09:12:33.007041+00:00 + 2025-10-11T22:19:33.577404+00:00 + python-feedgen Wladimir 2014-05-08 11:22:46+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Announcing the Statoshi fork - 2023-08-01T09:12:33.008040+00:00 + 2025-10-11T22:19:33.577575+00:00 - In a discussion about implementing clients, Nelson Castillo suggests using SNMP due to the availability of existing tools. However, Wladimir expresses concern about the complexity of implementing SNMP on client devices and registering custom OIDs. He questions the added value of using SNMP, as there are other ways of collecting statistics supported by monitoring tools.The conversation between Mike Hearn and Wladimir focuses on the similarities and differences between Bitcoin DNS seeds and Tor directory authorities. Both aim to find stable nodes, but Tor directory authorities are authenticated while DNS seeds are not. Bitcoin prioritizes decentralization more than Tor. They also discuss the possibility of having authenticated "directory authorities" in the Bitcoin source code and making stats public or private/authenticated to parties configured by the node owner.Gregory Maxwell explains the workings of the Tor network in an email. The network operates on a centralized but theoretically federated trusted directory service. Semi-trusted bandwidth authorities generate data by measuring node performance back to the directory authorities. This process is more extensive and involves third-party testing on nodes.Mike Hearn suggests exporting stats over regular TCP in order to make them public for any node. Wladimir mentions that the Tor network already does this and provides a link to torstatus.blutmagie.de. However, it is unclear what technology or tools Tor uses for submitting and gathering statistics.Charlie Shrem shares his guide for installing a full node in a universal way. Jameson Lopp and Wladimir discuss the possibility of including statistics with the installer for running a wallet-less node as an OS background service. They consider using Graphite and StatsD for stats aggregation and chart rendering, with Python being necessary for the stats service. They agree that the tool should be external, not part of bitcoind itself.Jameson Lopp chooses StatsD for sending stats via UDP to avoid affecting the node's performance. Wladimir suggests including statistics as part of the installer, but emphasizes the need for Python and external tools. The chart rendering happens client-side, so the web service only needs to collect and provide data.Mike Hearn and Wladimir discuss different ways to simplify the setup of components for Bitcoin Core stats aggregation and chart rendering. They consider exporting stats over TCP to make them public or having a site crawling nodes to trigger alerts based on chain heights by version. They agree that monitoring and analysis appeals more to certain types of people. Python is deemed necessary for the stats service, and the tool should be external, not part of bitcoind itself.Jameson Lopp and Wladimir discuss offering statistics with the Bitcoin Core installer. Jameson mentions dependencies on other software for stats aggregation and chart rendering. Wladimir agrees that including some statistics would be worth extra download size, but implementing web services in C++ is unrealistic. They decide that the tool should be external and suggest using SNMP as an option.The discussion explores ways to simplify the installation of Graphite components. Exporting stats over TCP and making them public is considered, as well as using community StatsD and Graphite instances. Monitoring and analysis are seen as appealing to certain types of people. Implementing web services in C++ is not realistic, so Python is necessary. The web service collects and provides data.Charlie Shrem expresses excitement about installing new software on his full node. Mike Hearn and Wladimir discuss simplifying the setup process for monitored bitcoind systems. They consider running a community StatsD and Graphite instance. Jameson Lopp raises concerns about trust if StatsD is run outside of highly secure infrastructure. He suggests packaging other software along with the installer. They discuss the possibility of offering public graphs.Jameson Lopp creates a Bitcoin Core fork that outputs statistics to StatsD for gaining insight into node processing. Wladimir sees potential in including this feature in Bitcoin Core node-only installers. Jameson mentions dependencies on other software and suggests packaging it with the installer. He also proposes offering public graphs.Jameson Lopp's Bitcoin Core fork provides statistics to StatsD for monitoring node processing. Pavol Rusnak asks about merging the feature into the mainline. The conversation highlights the need for an operations team and the complexity of setting up a monitored bitcoind system.Mike Hearn praises a proposal to simplify setting up monitored bitcoind systems. Jameson Lopp agrees that the current setup is difficult for most users. They discuss running a community StatsD and Graphite instance. Jameson notes the issue of trust if StatsD is not run on highly secure infrastructure. 2014-05-08T11:22:46+00:00 + In a discussion about implementing clients, Nelson Castillo suggests using SNMP due to the availability of existing tools. However, Wladimir expresses concern about the complexity of implementing SNMP on client devices and registering custom OIDs. He questions the added value of using SNMP, as there are other ways of collecting statistics supported by monitoring tools.The conversation between Mike Hearn and Wladimir focuses on the similarities and differences between Bitcoin DNS seeds and Tor directory authorities. Both aim to find stable nodes, but Tor directory authorities are authenticated while DNS seeds are not. Bitcoin prioritizes decentralization more than Tor. They also discuss the possibility of having authenticated "directory authorities" in the Bitcoin source code and making stats public or private/authenticated to parties configured by the node owner.Gregory Maxwell explains the workings of the Tor network in an email. The network operates on a centralized but theoretically federated trusted directory service. Semi-trusted bandwidth authorities generate data by measuring node performance back to the directory authorities. This process is more extensive and involves third-party testing on nodes.Mike Hearn suggests exporting stats over regular TCP in order to make them public for any node. Wladimir mentions that the Tor network already does this and provides a link to torstatus.blutmagie.de. However, it is unclear what technology or tools Tor uses for submitting and gathering statistics.Charlie Shrem shares his guide for installing a full node in a universal way. Jameson Lopp and Wladimir discuss the possibility of including statistics with the installer for running a wallet-less node as an OS background service. They consider using Graphite and StatsD for stats aggregation and chart rendering, with Python being necessary for the stats service. They agree that the tool should be external, not part of bitcoind itself.Jameson Lopp chooses StatsD for sending stats via UDP to avoid affecting the node's performance. Wladimir suggests including statistics as part of the installer, but emphasizes the need for Python and external tools. The chart rendering happens client-side, so the web service only needs to collect and provide data.Mike Hearn and Wladimir discuss different ways to simplify the setup of components for Bitcoin Core stats aggregation and chart rendering. They consider exporting stats over TCP to make them public or having a site crawling nodes to trigger alerts based on chain heights by version. They agree that monitoring and analysis appeals more to certain types of people. Python is deemed necessary for the stats service, and the tool should be external, not part of bitcoind itself.Jameson Lopp and Wladimir discuss offering statistics with the Bitcoin Core installer. Jameson mentions dependencies on other software for stats aggregation and chart rendering. Wladimir agrees that including some statistics would be worth extra download size, but implementing web services in C++ is unrealistic. They decide that the tool should be external and suggest using SNMP as an option.The discussion explores ways to simplify the installation of Graphite components. Exporting stats over TCP and making them public is considered, as well as using community StatsD and Graphite instances. Monitoring and analysis are seen as appealing to certain types of people. Implementing web services in C++ is not realistic, so Python is necessary. The web service collects and provides data.Charlie Shrem expresses excitement about installing new software on his full node. Mike Hearn and Wladimir discuss simplifying the setup process for monitored bitcoind systems. They consider running a community StatsD and Graphite instance. Jameson Lopp raises concerns about trust if StatsD is run outside of highly secure infrastructure. He suggests packaging other software along with the installer. They discuss the possibility of offering public graphs.Jameson Lopp creates a Bitcoin Core fork that outputs statistics to StatsD for gaining insight into node processing. Wladimir sees potential in including this feature in Bitcoin Core node-only installers. Jameson mentions dependencies on other software and suggests packaging it with the installer. He also proposes offering public graphs.Jameson Lopp's Bitcoin Core fork provides statistics to StatsD for monitoring node processing. Pavol Rusnak asks about merging the feature into the mainline. The conversation highlights the need for an operations team and the complexity of setting up a monitored bitcoind system.Mike Hearn praises a proposal to simplify setting up monitored bitcoind systems. Jameson Lopp agrees that the current setup is difficult for most users. They discuss running a community StatsD and Graphite instance. Jameson notes the issue of trust if StatsD is not run on highly secure infrastructure. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_BIP70-implementation-guidance.xml b/static/bitcoin-dev/May_2014/combined_BIP70-implementation-guidance.xml index b6bb1545a8..6f16c93049 100644 --- a/static/bitcoin-dev/May_2014/combined_BIP70-implementation-guidance.xml +++ b/static/bitcoin-dev/May_2014/combined_BIP70-implementation-guidance.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70 implementation guidance - 2023-08-01T09:10:26.184403+00:00 + 2025-10-11T22:19:25.073545+00:00 + python-feedgen Mike Hearn 2014-05-04 13:06:29+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP70 implementation guidance - 2023-08-01T09:10:26.184403+00:00 + 2025-10-11T22:19:25.073726+00:00 - The article discusses the issue of unincorporated businesses or sole traders in the UK being unable to obtain Extended Validation (EV) certificates due to the absence of a trade register. However, this is not seen as a significant concern as they can still trade under their name, email address, domain name, or telephone number if an SMS verifying Certificate Authority (CA) is set up. The purpose of EV certificates is to avoid confusion and ensure payments are directed to the correct entity. Companies that are unable to obtain EV certificates may indirectly cause confusion among users and make them uncertain about payment expectations, potentially making it easier for confusion attacks to occur. Nevertheless, this is expected to be a minor issue in practice.The importance of showing a business name instead of just the domain name for better identification and security purposes is discussed. Domain names are more susceptible to phishing attacks compared to EV names, making it harder to distinguish between legitimate and fake websites. Hackers can also obtain a domain name SSL certificate without being easily detected. On the other hand, EV certificates involve more checks, making them more difficult for hackers to obtain. EV certificates have the domain name in the CN field and the business name in the OU field. However, there is currently no code to verify if a certificate has undergone extended validation before displaying its contents. The article suggests showing the organization data instead of the domain name if available for EV certificates. Despite the inequitable rules around EV certificates, supporting them is still considered better than taking no action.The email thread discusses the implementation and issues associated with BIP70, a payment protocol used in Bitcoin transactions. One of the concerns raised is error handling during signature checking. It is suggested that if Public Key Infrastructure (PKI) checking fails, the request should be treated as unsigned. This is because there is no incentive for an attacker to break the signature when they can simply remove it entirely. Signature checking failure can also occur when someone signs their request with an unknown CA or uses an upgraded version of the protocol that is not entirely backwards compatible. To allow for the introduction of new (possibly community-run) CAs or new variations on signing, any errors should be treated as if there was no signature at all. Additionally, wallets lack context compared to browsers, so graphical user interfaces (GUIs) should train users to expect signed payment requests. It is recommended to show the recipient name in the future and instruct users not to proceed if it does not appear. The discussion also touches on the use of extended validation certificates, which display the business name instead of the domain name, making them less susceptible to phishing attacks. However, bitcoinj and Bitcoin Core do not currently have code in place to verify if a certificate has indeed undergone extended validation before displaying the organization data field. The email also emphasizes the proper handling of different types of certificates, such as S/MIME certs, and stresses the importance of testing, providing a test site for payment requests on the main network. Lastly, memo contents should contain useful information about the purchase or the merchant's name. Expiry times should not be overly aggressive as some users may need to coordinate payments from multi-party accounts.In conclusion, the implementation of BIP70 has several important considerations that need to be addressed. These include improving error handling during signature checking, showing the business name instead of just the domain name for better identification and security, properly handling different types of certificates, and providing useful memo contents. Despite the limitations and issues discussed, supporting extended validation certificates is still seen as a step in the right direction. 2014-05-04T13:06:29+00:00 + The article discusses the issue of unincorporated businesses or sole traders in the UK being unable to obtain Extended Validation (EV) certificates due to the absence of a trade register. However, this is not seen as a significant concern as they can still trade under their name, email address, domain name, or telephone number if an SMS verifying Certificate Authority (CA) is set up. The purpose of EV certificates is to avoid confusion and ensure payments are directed to the correct entity. Companies that are unable to obtain EV certificates may indirectly cause confusion among users and make them uncertain about payment expectations, potentially making it easier for confusion attacks to occur. Nevertheless, this is expected to be a minor issue in practice.The importance of showing a business name instead of just the domain name for better identification and security purposes is discussed. Domain names are more susceptible to phishing attacks compared to EV names, making it harder to distinguish between legitimate and fake websites. Hackers can also obtain a domain name SSL certificate without being easily detected. On the other hand, EV certificates involve more checks, making them more difficult for hackers to obtain. EV certificates have the domain name in the CN field and the business name in the OU field. However, there is currently no code to verify if a certificate has undergone extended validation before displaying its contents. The article suggests showing the organization data instead of the domain name if available for EV certificates. Despite the inequitable rules around EV certificates, supporting them is still considered better than taking no action.The email thread discusses the implementation and issues associated with BIP70, a payment protocol used in Bitcoin transactions. One of the concerns raised is error handling during signature checking. It is suggested that if Public Key Infrastructure (PKI) checking fails, the request should be treated as unsigned. This is because there is no incentive for an attacker to break the signature when they can simply remove it entirely. Signature checking failure can also occur when someone signs their request with an unknown CA or uses an upgraded version of the protocol that is not entirely backwards compatible. To allow for the introduction of new (possibly community-run) CAs or new variations on signing, any errors should be treated as if there was no signature at all. Additionally, wallets lack context compared to browsers, so graphical user interfaces (GUIs) should train users to expect signed payment requests. It is recommended to show the recipient name in the future and instruct users not to proceed if it does not appear. The discussion also touches on the use of extended validation certificates, which display the business name instead of the domain name, making them less susceptible to phishing attacks. However, bitcoinj and Bitcoin Core do not currently have code in place to verify if a certificate has indeed undergone extended validation before displaying the organization data field. The email also emphasizes the proper handling of different types of certificates, such as S/MIME certs, and stresses the importance of testing, providing a test site for payment requests on the main network. Lastly, memo contents should contain useful information about the purchase or the merchant's name. Expiry times should not be overly aggressive as some users may need to coordinate payments from multi-party accounts.In conclusion, the implementation of BIP70 has several important considerations that need to be addressed. These include improving error handling during signature checking, showing the business name instead of just the domain name for better identification and security, properly handling different types of certificates, and providing useful memo contents. Despite the limitations and issues discussed, supporting extended validation certificates is still seen as a step in the right direction. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_BIP70-proposed-changes.xml b/static/bitcoin-dev/May_2014/combined_BIP70-proposed-changes.xml index e4702340f2..9398e5bfd2 100644 --- a/static/bitcoin-dev/May_2014/combined_BIP70-proposed-changes.xml +++ b/static/bitcoin-dev/May_2014/combined_BIP70-proposed-changes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP70 proposed changes - 2023-08-01T07:40:05.028127+00:00 + 2025-10-11T22:20:16.144140+00:00 + python-feedgen Alon Muroch 2014-05-06 08:22:15+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - BIP70 proposed changes - 2023-08-01T07:40:05.028127+00:00 + 2025-10-11T22:20:16.144300+00:00 - In an email conversation, Odinn Cyberguerrilla discusses the progress of two-factor authentication and bitcoin with the Bitcoin developers Andreas Schildbach and Jeff Garzik. They are working on a decentralized authentication protocol based on bitcoin-like addresses. BitPay is also developing a new standard for authentication and hopes to establish a complete, decentralized authentication protocol with community support. Progress can be followed on their Github page. Odinn also asks about progress on a fully decentralized way of residing on one's device or devices and mentions maidsafe, a decentralized internet platform.Ryan X. Charles suggests that BitPay implement merge avoidance to increase customer and merchant privacy in the payment protocol. He also expresses concerns about X.509 encryption certificates and proposes a new standard for authentication based on bitcoin-like addresses. In another email, Ryan expresses concern about the missing concept of payment status after it has been made and suggests adding a message to return the merchant's view of the transaction status. He also recommends requiring UTC for times in the payment protocol to avoid confusion. Gavin Andresen and Andreas Schildbach provide feedback and suggest changes to BIP70.The email thread also includes discussions about X.509 certificates, the length of Bitcoin URIs, and the possibility of having a UNIX UTC timestamp field in customer payment messages. The conversation covers various technical aspects and potential improvements to the payment protocol. 2014-05-06T08:22:15+00:00 + In an email conversation, Odinn Cyberguerrilla discusses the progress of two-factor authentication and bitcoin with the Bitcoin developers Andreas Schildbach and Jeff Garzik. They are working on a decentralized authentication protocol based on bitcoin-like addresses. BitPay is also developing a new standard for authentication and hopes to establish a complete, decentralized authentication protocol with community support. Progress can be followed on their Github page. Odinn also asks about progress on a fully decentralized way of residing on one's device or devices and mentions maidsafe, a decentralized internet platform.Ryan X. Charles suggests that BitPay implement merge avoidance to increase customer and merchant privacy in the payment protocol. He also expresses concerns about X.509 encryption certificates and proposes a new standard for authentication based on bitcoin-like addresses. In another email, Ryan expresses concern about the missing concept of payment status after it has been made and suggests adding a message to return the merchant's view of the transaction status. He also recommends requiring UTC for times in the payment protocol to avoid confusion. Gavin Andresen and Andreas Schildbach provide feedback and suggest changes to BIP70.The email thread also includes discussions about X.509 certificates, the length of Bitcoin URIs, and the possibility of having a UNIX UTC timestamp field in customer payment messages. The conversation covers various technical aspects and potential improvements to the payment protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Bitcoin-Cooperative-Proof-of-Stake-whitpaper.xml b/static/bitcoin-dev/May_2014/combined_Bitcoin-Cooperative-Proof-of-Stake-whitpaper.xml index e8a6c22926..f9c50373ae 100644 --- a/static/bitcoin-dev/May_2014/combined_Bitcoin-Cooperative-Proof-of-Stake-whitpaper.xml +++ b/static/bitcoin-dev/May_2014/combined_Bitcoin-Cooperative-Proof-of-Stake-whitpaper.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Cooperative Proof-of-Stake whitpaper - 2023-08-01T09:21:47.633203+00:00 + 2025-10-11T22:20:05.473792+00:00 + python-feedgen Benjamin Cordes 2014-05-21 15:52:45+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Cooperative Proof-of-Stake whitpaper - 2023-08-01T09:21:47.633203+00:00 + 2025-10-11T22:20:05.473977+00:00 - Stephen Reed, a user from Austin, Texas, has completed a whitepaper proposing a proof-of-stake version of Bitcoin. The proposed system utilizes a single nomadic verifiable mint agent and distributed replication of a single blockchain by compensated full nodes to achieve 6-hop, sub-second transaction acknowledgement times. Unlike the current system, this version would pay dividends to holders instead of miners, resulting in lower subsidized transaction fees.While the paper presents an interesting idea, it is worth noting that the code for this proposed system has not yet been written. Therefore, the concept is still in its early stages of development. Reed acknowledges the complexity of the proposed system and suggests incentivizing full nodes instead.Reed's plan is to hard fork the Bitcoin blockchain in early 2016, but only after a year of public system testing and wide approval. This cautious approach ensures that the proposed changes are thoroughly evaluated before implementation. In order to gather feedback and promote transparency, Reed encourages readers to comment on the project thread, which will serve as a development diary.It is important to highlight that referring to the subsidy for miners as "wasting it on miners" may not be well received within the Bitcoin community. The email includes a link to the whitepaper and project thread for those who wish to reference or contribute to the ongoing discussion.Overall, while Reed's whitepaper offers an intriguing vision for the future of Bitcoin, it is clear that significant work remains before implementing such drastic changes. The proposed proof-of-stake system could revolutionize transaction speeds and reduce costs through dividend payments to holders. However, it remains to be seen how the wider Bitcoin community will respond to these ideas. 2014-05-21T15:52:45+00:00 + Stephen Reed, a user from Austin, Texas, has completed a whitepaper proposing a proof-of-stake version of Bitcoin. The proposed system utilizes a single nomadic verifiable mint agent and distributed replication of a single blockchain by compensated full nodes to achieve 6-hop, sub-second transaction acknowledgement times. Unlike the current system, this version would pay dividends to holders instead of miners, resulting in lower subsidized transaction fees.While the paper presents an interesting idea, it is worth noting that the code for this proposed system has not yet been written. Therefore, the concept is still in its early stages of development. Reed acknowledges the complexity of the proposed system and suggests incentivizing full nodes instead.Reed's plan is to hard fork the Bitcoin blockchain in early 2016, but only after a year of public system testing and wide approval. This cautious approach ensures that the proposed changes are thoroughly evaluated before implementation. In order to gather feedback and promote transparency, Reed encourages readers to comment on the project thread, which will serve as a development diary.It is important to highlight that referring to the subsidy for miners as "wasting it on miners" may not be well received within the Bitcoin community. The email includes a link to the whitepaper and project thread for those who wish to reference or contribute to the ongoing discussion.Overall, while Reed's whitepaper offers an intriguing vision for the future of Bitcoin, it is clear that significant work remains before implementing such drastic changes. The proposed proof-of-stake system could revolutionize transaction speeds and reduce costs through dividend payments to holders. However, it remains to be seen how the wider Bitcoin community will respond to these ideas. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Bitcoin-Core-Nightly-Builds.xml b/static/bitcoin-dev/May_2014/combined_Bitcoin-Core-Nightly-Builds.xml index cbac506961..6fc7ceb9db 100644 --- a/static/bitcoin-dev/May_2014/combined_Bitcoin-Core-Nightly-Builds.xml +++ b/static/bitcoin-dev/May_2014/combined_Bitcoin-Core-Nightly-Builds.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core Nightly Builds - 2023-08-01T08:46:53.051562+00:00 + 2025-10-11T22:19:37.833707+00:00 + python-feedgen Warren Togami Jr. 2014-05-22 02:28:56+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core Nightly Builds - 2023-08-01T08:46:53.051562+00:00 + 2025-10-11T22:19:37.833862+00:00 - Bitcoin Core developers are preparing to release version 0.9.2, which will primarily focus on bug fixes, cleanup, and translation updates. This upcoming release is expected to be available in a few weeks from the announcement made by Warren Togami Jr. on April 16, 2014. In order to ensure a smooth and polished release, power users are encouraged to test the master branch using unofficial nightly builds. By doing so, they can help identify any bugs and provide valuable feedback to the developers.Notably, the Bitcoin Core team has made significant progress in improving the development process for Mac users. Thanks to the efforts of Cory Fields, deterministic builds for MacOS X are now available. This means that users on MacOS X can also benefit from the latest updates and contribute to the testing and improvement of the software.Furthermore, translators are urged to take advantage of the latest code to identify and translate any strings that need attention before the next stable release. This will ensure that the software is accessible to users worldwide and language barriers are minimized.For more information on the upcoming release and how to get involved in testing and translation efforts, interested individuals can visit the BitcoinTalk forum at the provided link (https://bitcointalk.org/index.php?topic=571414.0). The forum post by Warren Togami Jr. contains detailed information about the plans for version 0.9.2 and the ways in which users can contribute to its success. 2014-05-22T02:28:56+00:00 + Bitcoin Core developers are preparing to release version 0.9.2, which will primarily focus on bug fixes, cleanup, and translation updates. This upcoming release is expected to be available in a few weeks from the announcement made by Warren Togami Jr. on April 16, 2014. In order to ensure a smooth and polished release, power users are encouraged to test the master branch using unofficial nightly builds. By doing so, they can help identify any bugs and provide valuable feedback to the developers.Notably, the Bitcoin Core team has made significant progress in improving the development process for Mac users. Thanks to the efforts of Cory Fields, deterministic builds for MacOS X are now available. This means that users on MacOS X can also benefit from the latest updates and contribute to the testing and improvement of the software.Furthermore, translators are urged to take advantage of the latest code to identify and translate any strings that need attention before the next stable release. This will ensure that the software is accessible to users worldwide and language barriers are minimized.For more information on the upcoming release and how to get involved in testing and translation efforts, interested individuals can visit the BitcoinTalk forum at the provided link (https://bitcointalk.org/index.php?topic=571414.0). The forum post by Warren Togami Jr. contains detailed information about the plans for version 0.9.2 and the ways in which users can contribute to its success. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Bitcoin-Fee-Formula-Proposal.xml b/static/bitcoin-dev/May_2014/combined_Bitcoin-Fee-Formula-Proposal.xml index c1b500cd44..3c1f92152f 100644 --- a/static/bitcoin-dev/May_2014/combined_Bitcoin-Fee-Formula-Proposal.xml +++ b/static/bitcoin-dev/May_2014/combined_Bitcoin-Fee-Formula-Proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Fee Formula Proposal - 2023-08-01T09:14:40.598945+00:00 + 2025-10-11T22:20:18.267705+00:00 + python-feedgen Bernd Jendrissek 2014-05-13 10:02:08+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Fee Formula Proposal - 2023-08-01T09:14:40.598945+00:00 + 2025-10-11T22:20:18.267847+00:00 - In a message posted on GitHub issue manager, Peter Grigor has proposed a new method for calculating transaction fees in Bitcoin. The proposed method involves calculating the fee from a percentage of the input amount divided by the confirmations of the input multiplied by the number of inputs. This proposal was made in response to concerns about the safety of small "spam" transactions that could become unsafely inexpensive with the use of 0 confirmation inputs.However, there are some concerns raised in the issue tracker regarding the suitability of this proposed method for Bitcoin. Some responses suggest that it may do more harm than good. As a result, there is uncertainty about whether or not this proposal should be implemented.The proposed formula for calculating transaction fees is ((INPUT_AMOUNT * BASE_PERCENT) / CONFIRMATIONS) * NUMBER_OF_INPUTS. The INPUT_AMOUNT, CONFIRMATIONS, and NUMBER_OF_INPUTS would be determined by the creator of the transaction, while the BASE_PERCENT would be hard-coded in the bitcoind software.This proposed method aims to ensure that the transaction fee always makes sense regardless of the bitcoin price in fiat. Dividing the fee by the number of confirmations encourages careful spending and rewards savings, while multiplying the fee by the number of inputs discourages "payment fragmenting." Payment fragmenting occurs when multiple inputs are required to pay for larger purchases, leading to higher transaction fees.To provide a visual representation of the proposed fees based on this method, a spreadsheet has been created. The spreadsheet shows the various fees by amount and confirmations. This allows for a better understanding of how the proposed formula would work in practice.Overall, Peter Grigor's proposal for a new method to calculate transaction fees in Bitcoin has sparked discussions and debates within the community. While the proposal offers potential benefits, there are also concerns raised about its suitability and potential negative impacts. Further analysis and consideration are needed before deciding whether or not to implement this proposed method. 2014-05-13T10:02:08+00:00 + In a message posted on GitHub issue manager, Peter Grigor has proposed a new method for calculating transaction fees in Bitcoin. The proposed method involves calculating the fee from a percentage of the input amount divided by the confirmations of the input multiplied by the number of inputs. This proposal was made in response to concerns about the safety of small "spam" transactions that could become unsafely inexpensive with the use of 0 confirmation inputs.However, there are some concerns raised in the issue tracker regarding the suitability of this proposed method for Bitcoin. Some responses suggest that it may do more harm than good. As a result, there is uncertainty about whether or not this proposal should be implemented.The proposed formula for calculating transaction fees is ((INPUT_AMOUNT * BASE_PERCENT) / CONFIRMATIONS) * NUMBER_OF_INPUTS. The INPUT_AMOUNT, CONFIRMATIONS, and NUMBER_OF_INPUTS would be determined by the creator of the transaction, while the BASE_PERCENT would be hard-coded in the bitcoind software.This proposed method aims to ensure that the transaction fee always makes sense regardless of the bitcoin price in fiat. Dividing the fee by the number of confirmations encourages careful spending and rewards savings, while multiplying the fee by the number of inputs discourages "payment fragmenting." Payment fragmenting occurs when multiple inputs are required to pay for larger purchases, leading to higher transaction fees.To provide a visual representation of the proposed fees based on this method, a spreadsheet has been created. The spreadsheet shows the various fees by amount and confirmations. This allows for a better understanding of how the proposed formula would work in practice.Overall, Peter Grigor's proposal for a new method to calculate transaction fees in Bitcoin has sparked discussions and debates within the community. While the proposal offers potential benefits, there are also concerns raised about its suitability and potential negative impacts. Further analysis and consideration are needed before deciding whether or not to implement this proposed method. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Bitcoin-Protocol-Specification.xml b/static/bitcoin-dev/May_2014/combined_Bitcoin-Protocol-Specification.xml index 01412cc447..6c6516cd0d 100644 --- a/static/bitcoin-dev/May_2014/combined_Bitcoin-Protocol-Specification.xml +++ b/static/bitcoin-dev/May_2014/combined_Bitcoin-Protocol-Specification.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Protocol Specification - 2023-08-01T09:18:23.533727+00:00 + 2025-10-11T22:19:16.577300+00:00 + python-feedgen sickpig at gmail.com 2014-07-14 20:51:35+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Protocol Specification - 2023-08-01T09:18:23.533727+00:00 + 2025-10-11T22:19:16.577548+00:00 - On July 14, 2014, Mike Hearn raises the question of whether it is possible to create proper protocol specifications for Bitcoin other than the original C++ codebase. The response is affirmative, but with the caveat that previous attempts have failed due to the complexity of Bitcoin. Krzysztof Okupski and Jeff Garzik discuss renaming the document "Bitcoin Developer Specification" to "Bitcoin Developer Reference" and acknowledge its value as a description of the protocol for beginners. However, they also recognize that implementing the protocol based on the document would result in mistakes.Wladimir confirms that the resource in question has already been linked under "Additional Resources" on the developer guide. The conversation ends with a cautionary note to be careful with the usage of the word "specification".Krzysztof Okupski announces that the Bitcoin specification will now be under version control on GitHub. This move aims to increase the number of Bitcoin developers by making the system more understandable. The old link to the PDF version will also be kept updated.Matt Whitlock inquires about a specification document for Satoshi's P2P protocol, specifically how blocks and transactions are communicated over the network. A high-level guide is provided via a link to the developer guide on bitcoin.org, but it is noted that this guide is not a protocol specification. However, the Bitcoin wiki page and a forum thread on bitcointalk.org are suggested as resources for understanding the P2P protocol.Aaron Voisine shares a short description in code comments for breadwallet, and Matt Whitlock asks if anyone is working on a specification document for Satoshi's P2P protocol. Interest in understanding how blocks and transactions are communicated over the network is expressed.Isidor Zeuner shares a link to a PDF document about Bitcoin's design, and JMOlmos GMail asks if there is a translation available. Isidor suggests putting the document source under version control to facilitate tracking future protocol improvements.Krzysztof Okupski receives commendation for his work on a Bitcoin reference document, and the idea of putting the document source under version control is suggested. A request for translation assistance is made, and the email thread is sent to the Bitcoin-development mailing list.Krzysztof Okupski has created a document on Bitcoin's design that is praised as a great reference. The suggestion of putting the document source under version control is made, and Krzysztof thanks Isidor in advance for any further improvement proposals.Krzysztof Okupski posts a revised version of the Bitcoin Protocol Specification that incorporates feedback from Bitcoin Core developers and enthusiasts. He hopes the revised version will be useful to the community and welcomes additional improvement proposals.In May 2014, Krzysztof Okupski requests feedback on a Bitcoin protocol specification he has written. The purpose of the email is to improve the quality of the document and ask for suggestions and error corrections. A link to the front page of the document and contact information are provided.Overall, the context discusses various discussions and exchanges related to creating proper protocol specifications for Bitcoin, particularly the Bitcoin Developer Reference. The challenges and limitations of creating such specifications are highlighted, along with the value of the existing resources available. 2014-07-14T20:51:35+00:00 + On July 14, 2014, Mike Hearn raises the question of whether it is possible to create proper protocol specifications for Bitcoin other than the original C++ codebase. The response is affirmative, but with the caveat that previous attempts have failed due to the complexity of Bitcoin. Krzysztof Okupski and Jeff Garzik discuss renaming the document "Bitcoin Developer Specification" to "Bitcoin Developer Reference" and acknowledge its value as a description of the protocol for beginners. However, they also recognize that implementing the protocol based on the document would result in mistakes.Wladimir confirms that the resource in question has already been linked under "Additional Resources" on the developer guide. The conversation ends with a cautionary note to be careful with the usage of the word "specification".Krzysztof Okupski announces that the Bitcoin specification will now be under version control on GitHub. This move aims to increase the number of Bitcoin developers by making the system more understandable. The old link to the PDF version will also be kept updated.Matt Whitlock inquires about a specification document for Satoshi's P2P protocol, specifically how blocks and transactions are communicated over the network. A high-level guide is provided via a link to the developer guide on bitcoin.org, but it is noted that this guide is not a protocol specification. However, the Bitcoin wiki page and a forum thread on bitcointalk.org are suggested as resources for understanding the P2P protocol.Aaron Voisine shares a short description in code comments for breadwallet, and Matt Whitlock asks if anyone is working on a specification document for Satoshi's P2P protocol. Interest in understanding how blocks and transactions are communicated over the network is expressed.Isidor Zeuner shares a link to a PDF document about Bitcoin's design, and JMOlmos GMail asks if there is a translation available. Isidor suggests putting the document source under version control to facilitate tracking future protocol improvements.Krzysztof Okupski receives commendation for his work on a Bitcoin reference document, and the idea of putting the document source under version control is suggested. A request for translation assistance is made, and the email thread is sent to the Bitcoin-development mailing list.Krzysztof Okupski has created a document on Bitcoin's design that is praised as a great reference. The suggestion of putting the document source under version control is made, and Krzysztof thanks Isidor in advance for any further improvement proposals.Krzysztof Okupski posts a revised version of the Bitcoin Protocol Specification that incorporates feedback from Bitcoin Core developers and enthusiasts. He hopes the revised version will be useful to the community and welcomes additional improvement proposals.In May 2014, Krzysztof Okupski requests feedback on a Bitcoin protocol specification he has written. The purpose of the email is to improve the quality of the document and ask for suggestions and error corrections. A link to the front page of the document and contact information are provided.Overall, the context discusses various discussions and exchanges related to creating proper protocol specifications for Bitcoin, particularly the Bitcoin Developer Reference. The challenges and limitations of creating such specifications are highlighted, along with the value of the existing resources available. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Bitcoind-in-background-mode-for-SPV-wallets.xml b/static/bitcoin-dev/May_2014/combined_Bitcoind-in-background-mode-for-SPV-wallets.xml index dd29ca345b..0b44c8757c 100644 --- a/static/bitcoin-dev/May_2014/combined_Bitcoind-in-background-mode-for-SPV-wallets.xml +++ b/static/bitcoin-dev/May_2014/combined_Bitcoind-in-background-mode-for-SPV-wallets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoind-in-background mode for SPV wallets - 2023-08-01T08:41:56.947412+00:00 + 2025-10-11T22:19:12.321717+00:00 + python-feedgen Tier Nolan 2014-05-04 21:11:27+00:00 @@ -199,13 +200,13 @@ - python-feedgen + 2 Combined summary - Bitcoind-in-background mode for SPV wallets - 2023-08-01T08:41:56.948412+00:00 + 2025-10-11T22:19:12.321985+00:00 - In an email exchange between Bitcoin Core developer Mike Hearn and Wladimir J. van der Laan, they discuss the issue of incompatibility between wallets and nodes. Hearn suggests optimizing the NAT tunneling code, adding diagnostic features to the GUI, and implementing STUN support to address the problem of users not keeping their computers switched on all the time. Van der Laan agrees with Hearn's proposal but suggests creating a separate "node control" user interface instead of controlling the node from the wallet. However, he acknowledges that initially people may not know when or why to install this separate interface, so he suggests packaging it with wallets.Another topic discussed on the Bitcoin-development mailing list is the need to improve reachability for bitcoind instances. Slush suggests implementing a self-test feature and IPv6 tunneling to enhance reachability. Gregory Maxwell argues that existing implementations are inefficient, but he believes that improvements in implementation can address the low resource requirements of the protocol. The main constraint with home devices is not their power but the fact that people no longer keep computers switched on all the time. Suggestions to address this issue include optimizing NAT tunneling code, adding diagnostic features to the GUI, and implementing STUN support.Tamas Blummer and Wladimir have an email conversation about SPV wallets and the need for a lightweight bitcoin router or "core" that can be easily deployed anywhere. Blummer suggests that the index should be specific to added features and the subset of the blockchain relevant to the wallet. He also proposes serving headers as default, with the option to configure storing and serving full blocks based on bandwidth and available space. Wladimir agrees with these suggestions and proposes adding an RPC call for an "address -> utxo" query. They also discuss integrating the torrent download of bootstrap.dat into bitcoind to improve synchronization.Mark Friedenbach mentions that there is a reasonable pathway to do everything in-protocol without introducing external dependencies. He implemented headers first, which saturates residential broadband and copes with unreliable peers.In an email thread from April 9, 2014, slush and Laszlo discuss the slow deployment of IPv6 and ways to make instances IPv6-reachable automatically. Teredo is mentioned as a potential solution, but security settings need to be considered. Laszlo suggests adding an IPv6 checkbox in the settings with a link to an explanation or a built-in checker for reachability.There is a need for a lightweight bitcoin router or "core" that can be easily deployed anywhere. Bundling core with SPV clients would not improve anything as it would make the computer unusable every time the wallet is started. Instead, converting hidden nodes to publicly reachable nodes may be a more effective way to attract fresh instances. Wladimir proposes an interface to bitcoind to allow 'running with full node', which could benefit other clients as well.In an email exchange, slush suggests integrating the torrent download of bootstrap.dat into bitcoind to improve synchronization. Wladimir suggests parallel block download instead of involving BitTorrent.The Bitcoin-development mailing list discusses various ways to improve the Bitcoin network. Marek suggests integrating the torrent download of bootstrap.dat into bitcoind to attract more users. Slush suggests finding ways to expose existing bitcoind instances to the internet or provide self-tests for reachability. Gregory Maxwell emphasizes the need for improvements in existing implementations. Justus Ranvier challenges claims about resource usage, suggesting that full nodes can be operated with fewer resources than current implementations use.In an email thread, Thomas Voegtlin and Gregory Maxwell discuss the resource usage of Electrum and the potential for adding an RPC call for an "address to utxo" query. Wladimir also contributes to the conversation.Gregory Maxwell denies claims about a broken incentive model and argues that full nodes can be operated with fewer resources than current implementations use. He refers to archives of the mailing list where more people confirm the resource usage problem than deny it.Justus Ranvier suggests changing the network design if the security relies on a flawed incentive model. However, others argue that suitable software improvements can reduce resource requirements for running a full node. The main cost would be setting up the system, which bundling could potentially resolve.In an email exchange, Wladimir expresses concern over the lack of resources being volunteered to support the Bitcoin network. Justus Ranvier suggests a solution to quickly add more nodes and separate the wallet from Bitcoin Core. Wladimir welcomes pull requests for solutions.On April 9th, 2014, Wladimir proposes adding an option to popular SPV wallets to run a bitcoind process in the background to address the decrease in the number of full nodes.In an email conversation, Tamas Blummer suggests that the Simplified Payment Verification (SPV) is a sufficient API to a trusted node to build sophisticated features that are not offered by the core. He also mentions the need for a lightweight bitcoin 2014-05-04T21:11:27+00:00 + In an email exchange between Bitcoin Core developer Mike Hearn and Wladimir J. van der Laan, they discuss the issue of incompatibility between wallets and nodes. Hearn suggests optimizing the NAT tunneling code, adding diagnostic features to the GUI, and implementing STUN support to address the problem of users not keeping their computers switched on all the time. Van der Laan agrees with Hearn's proposal but suggests creating a separate "node control" user interface instead of controlling the node from the wallet. However, he acknowledges that initially people may not know when or why to install this separate interface, so he suggests packaging it with wallets.Another topic discussed on the Bitcoin-development mailing list is the need to improve reachability for bitcoind instances. Slush suggests implementing a self-test feature and IPv6 tunneling to enhance reachability. Gregory Maxwell argues that existing implementations are inefficient, but he believes that improvements in implementation can address the low resource requirements of the protocol. The main constraint with home devices is not their power but the fact that people no longer keep computers switched on all the time. Suggestions to address this issue include optimizing NAT tunneling code, adding diagnostic features to the GUI, and implementing STUN support.Tamas Blummer and Wladimir have an email conversation about SPV wallets and the need for a lightweight bitcoin router or "core" that can be easily deployed anywhere. Blummer suggests that the index should be specific to added features and the subset of the blockchain relevant to the wallet. He also proposes serving headers as default, with the option to configure storing and serving full blocks based on bandwidth and available space. Wladimir agrees with these suggestions and proposes adding an RPC call for an "address -> utxo" query. They also discuss integrating the torrent download of bootstrap.dat into bitcoind to improve synchronization.Mark Friedenbach mentions that there is a reasonable pathway to do everything in-protocol without introducing external dependencies. He implemented headers first, which saturates residential broadband and copes with unreliable peers.In an email thread from April 9, 2014, slush and Laszlo discuss the slow deployment of IPv6 and ways to make instances IPv6-reachable automatically. Teredo is mentioned as a potential solution, but security settings need to be considered. Laszlo suggests adding an IPv6 checkbox in the settings with a link to an explanation or a built-in checker for reachability.There is a need for a lightweight bitcoin router or "core" that can be easily deployed anywhere. Bundling core with SPV clients would not improve anything as it would make the computer unusable every time the wallet is started. Instead, converting hidden nodes to publicly reachable nodes may be a more effective way to attract fresh instances. Wladimir proposes an interface to bitcoind to allow 'running with full node', which could benefit other clients as well.In an email exchange, slush suggests integrating the torrent download of bootstrap.dat into bitcoind to improve synchronization. Wladimir suggests parallel block download instead of involving BitTorrent.The Bitcoin-development mailing list discusses various ways to improve the Bitcoin network. Marek suggests integrating the torrent download of bootstrap.dat into bitcoind to attract more users. Slush suggests finding ways to expose existing bitcoind instances to the internet or provide self-tests for reachability. Gregory Maxwell emphasizes the need for improvements in existing implementations. Justus Ranvier challenges claims about resource usage, suggesting that full nodes can be operated with fewer resources than current implementations use.In an email thread, Thomas Voegtlin and Gregory Maxwell discuss the resource usage of Electrum and the potential for adding an RPC call for an "address to utxo" query. Wladimir also contributes to the conversation.Gregory Maxwell denies claims about a broken incentive model and argues that full nodes can be operated with fewer resources than current implementations use. He refers to archives of the mailing list where more people confirm the resource usage problem than deny it.Justus Ranvier suggests changing the network design if the security relies on a flawed incentive model. However, others argue that suitable software improvements can reduce resource requirements for running a full node. The main cost would be setting up the system, which bundling could potentially resolve.In an email exchange, Wladimir expresses concern over the lack of resources being volunteered to support the Bitcoin network. Justus Ranvier suggests a solution to quickly add more nodes and separate the wallet from Bitcoin Core. Wladimir welcomes pull requests for solutions.On April 9th, 2014, Wladimir proposes adding an option to popular SPV wallets to run a bitcoind process in the background to address the decrease in the number of full nodes.In an email conversation, Tamas Blummer suggests that the Simplified Payment Verification (SPV) is a sufficient API to a trusted node to build sophisticated features that are not offered by the core. He also mentions the need for a lightweight bitcoin - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Block-collision-resolution-using-the-DECOR-protocol-and-Bonneau-s-Kickbacks-problem.xml b/static/bitcoin-dev/May_2014/combined_Block-collision-resolution-using-the-DECOR-protocol-and-Bonneau-s-Kickbacks-problem.xml index 80c6cb4b3c..9e7cbc3b57 100644 --- a/static/bitcoin-dev/May_2014/combined_Block-collision-resolution-using-the-DECOR-protocol-and-Bonneau-s-Kickbacks-problem.xml +++ b/static/bitcoin-dev/May_2014/combined_Block-collision-resolution-using-the-DECOR-protocol-and-Bonneau-s-Kickbacks-problem.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem - 2023-08-01T09:09:53.095741+00:00 + 2025-10-11T22:20:11.897885+00:00 + python-feedgen Ittay 2014-05-05 20:27:08+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem - 2023-08-01T09:09:53.095741+00:00 + 2025-10-11T22:20:11.898055+00:00 - In an email thread dated 2nd May 2014, Sergio Lerner proposed a new mining protocol that would include 'uncle' blocks in the reward system. Joseph Bonneau raised two concerns regarding this idea. Firstly, he questioned whether the parent block would receive one unit of the reward while the uncle block would receive 0.5 units or if both would receive 0.5 units. Sergio confirmed that the latter was the correct interpretation.Secondly, Bonneau suggested that including uncle blocks could encourage kickback-style attacks where miners ignore uncles to avoid sharing the reward, which would favor large mining pools. However, Sergio refuted this suggestion by stating that including an uncle block can be done at any time before a coinbase matures (100 blocks). Therefore, it is difficult for a miner to prevent other miners from including the uncle and taking the reward given by uncle inclusion. Furthermore, he argued that a big miner trying to bribe all other miners not to include the uncle would be too costly.Joseph Bonneau also expressed concern about the method used to break ties between blocks A and B in the DECOR protocol. He suggested that hashing the blocks to decide the "winner" would allow miners to predict their block's likelihood of winning a collision by looking at how high or low its hash is, leading to selfish mining. Instead, he proposed seeing if H(A||B) could be used to determine in advance if a block is likely to win a collision. However, Sergio believed that selfish miners cannot get any advantage in the DECOR protocol since the blocks that lose the latency race will come back as uncles and get their reward share anyway.In a blog post titled "Decor," author Sergio Lerner discusses a method of decorating Bitcoin transaction messages in order to add personalization and privacy. Lerner proposes a format for these decorated transaction messages, which includes a unique identifier followed by the desired message and a checksum for verification purposes. This method can increase privacy by making it more difficult for third parties to link transactions together.Lerner provides examples of how this method could be used, including adding a personalized message to a donation transaction or indicating the reason for a payment. He also suggests that businesses could use this method to include additional information about their products or services in transaction messages. Overall, Lerner argues that this method of decorating Bitcoin transaction messages adds a level of personalization and privacy to the Bitcoin network, and encourages others to adopt this method.The Bonneau's Kickbacks problem is an interesting issue as it creates a destabilizing incentive. A way to prevent Kickbacks and provide a conflict resolution strategy that benefits all members of the network has been found.The GHOST protocol is a paper that addresses the Bitcoin block-chain design and aims to achieve higher TPS securely by changing the way nodes decide which is the best chain fork. However, one issue not considered in the paper is the existence of a selfish bias independent of the miner’s hashing power. Double-betting is a mining strategy pre-programmed in the Satoshi reference miner. If two competing miners could detect the other miners' identity in blocks, they could apply a cooperative strategy like Tit for Tat.DECOR (DEterministic COnflict Resolution) is a reward strategy that incentives resolving conflicts in a deterministic way that benefits all conflicting miners at the same time. It practically eliminates any possible block-chain reversal when miners are rational. The DECOR strategy can be implemented along with the GHOST protocol. Using both protocols together, along with route optimizations proposed here, maybe 2000 TPS can be achieved today. 2014-05-05T20:27:08+00:00 + In an email thread dated 2nd May 2014, Sergio Lerner proposed a new mining protocol that would include 'uncle' blocks in the reward system. Joseph Bonneau raised two concerns regarding this idea. Firstly, he questioned whether the parent block would receive one unit of the reward while the uncle block would receive 0.5 units or if both would receive 0.5 units. Sergio confirmed that the latter was the correct interpretation.Secondly, Bonneau suggested that including uncle blocks could encourage kickback-style attacks where miners ignore uncles to avoid sharing the reward, which would favor large mining pools. However, Sergio refuted this suggestion by stating that including an uncle block can be done at any time before a coinbase matures (100 blocks). Therefore, it is difficult for a miner to prevent other miners from including the uncle and taking the reward given by uncle inclusion. Furthermore, he argued that a big miner trying to bribe all other miners not to include the uncle would be too costly.Joseph Bonneau also expressed concern about the method used to break ties between blocks A and B in the DECOR protocol. He suggested that hashing the blocks to decide the "winner" would allow miners to predict their block's likelihood of winning a collision by looking at how high or low its hash is, leading to selfish mining. Instead, he proposed seeing if H(A||B) could be used to determine in advance if a block is likely to win a collision. However, Sergio believed that selfish miners cannot get any advantage in the DECOR protocol since the blocks that lose the latency race will come back as uncles and get their reward share anyway.In a blog post titled "Decor," author Sergio Lerner discusses a method of decorating Bitcoin transaction messages in order to add personalization and privacy. Lerner proposes a format for these decorated transaction messages, which includes a unique identifier followed by the desired message and a checksum for verification purposes. This method can increase privacy by making it more difficult for third parties to link transactions together.Lerner provides examples of how this method could be used, including adding a personalized message to a donation transaction or indicating the reason for a payment. He also suggests that businesses could use this method to include additional information about their products or services in transaction messages. Overall, Lerner argues that this method of decorating Bitcoin transaction messages adds a level of personalization and privacy to the Bitcoin network, and encourages others to adopt this method.The Bonneau's Kickbacks problem is an interesting issue as it creates a destabilizing incentive. A way to prevent Kickbacks and provide a conflict resolution strategy that benefits all members of the network has been found.The GHOST protocol is a paper that addresses the Bitcoin block-chain design and aims to achieve higher TPS securely by changing the way nodes decide which is the best chain fork. However, one issue not considered in the paper is the existence of a selfish bias independent of the miner’s hashing power. Double-betting is a mining strategy pre-programmed in the Satoshi reference miner. If two competing miners could detect the other miners' identity in blocks, they could apply a cooperative strategy like Tit for Tat.DECOR (DEterministic COnflict Resolution) is a reward strategy that incentives resolving conflicts in a deterministic way that benefits all conflicting miners at the same time. It practically eliminates any possible block-chain reversal when miners are rational. The DECOR strategy can be implemented along with the GHOST protocol. Using both protocols together, along with route optimizations proposed here, maybe 2000 TPS can be achieved today. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Bug-in-key-cpp.xml b/static/bitcoin-dev/May_2014/combined_Bug-in-key-cpp.xml index 43af946e3a..ba65ee9f8f 100644 --- a/static/bitcoin-dev/May_2014/combined_Bug-in-key-cpp.xml +++ b/static/bitcoin-dev/May_2014/combined_Bug-in-key-cpp.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bug in key.cpp - 2023-08-01T09:11:54.353675+00:00 + 2025-10-11T22:20:07.649046+00:00 + python-feedgen Pieter Wuille 2014-05-06 08:25:06+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bug in key.cpp - 2023-08-01T09:11:54.353675+00:00 + 2025-10-11T22:20:07.649180+00:00 - In an email exchange on May 6, 2014, Pieter identifies a bug in the system, even though the value is not exactly 25%. He advises the recipient to continue investigating the issue. The bug relates to values 2 and 3, which should only occur once in 2**127 when the signature value is between the group size and field size. Despite these values being theoretical in nature, they still represent a bug in the system.The bug is discussed on the Bitcoin-development mailing list, specifically in a thread about a bug in line 273 of the key.cpp file. Currently, the if statement in this line uses "rec=3" instead of "rec==3", causing confusion as 3 is a valid value. One suggestion to fix the bug is to change "return false" to "return true". However, another participant points out that the problematic value may not actually be 25%, indicating that further investigation is needed to identify the root cause of the bug.Additionally, the email includes a promotional message for an upcoming event hosted by Perforce. This event promises expert tips and advice on migrating legacy SCM systems to improve productivity and software release efficiency. 2014-05-06T08:25:06+00:00 + In an email exchange on May 6, 2014, Pieter identifies a bug in the system, even though the value is not exactly 25%. He advises the recipient to continue investigating the issue. The bug relates to values 2 and 3, which should only occur once in 2**127 when the signature value is between the group size and field size. Despite these values being theoretical in nature, they still represent a bug in the system.The bug is discussed on the Bitcoin-development mailing list, specifically in a thread about a bug in line 273 of the key.cpp file. Currently, the if statement in this line uses "rec=3" instead of "rec==3", causing confusion as 3 is a valid value. One suggestion to fix the bug is to change "return false" to "return true". However, another participant points out that the problematic value may not actually be 25%, indicating that further investigation is needed to identify the root cause of the bug.Additionally, the email includes a promotional message for an upcoming event hosted by Perforce. This event promises expert tips and advice on migrating legacy SCM systems to improve productivity and software release efficiency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Bug-with-handing-of-OP-RETURN-.xml b/static/bitcoin-dev/May_2014/combined_Bug-with-handing-of-OP-RETURN-.xml index c5ac15c460..c022df04de 100644 --- a/static/bitcoin-dev/May_2014/combined_Bug-with-handing-of-OP-RETURN-.xml +++ b/static/bitcoin-dev/May_2014/combined_Bug-with-handing-of-OP-RETURN-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bug with handing of OP_RETURN? - 2023-08-01T09:10:59.391097+00:00 + 2025-10-11T22:20:20.395930+00:00 + python-feedgen Jeff Garzik 2014-05-05 17:30:02+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Bug with handing of OP_RETURN? - 2023-08-01T09:10:59.391097+00:00 + 2025-10-11T22:20:20.396129+00:00 - In a Bitcoin-development mailing list, Jeff Garzik clarified that the pushed-data size is limited to the standard format of OP_RETURN. He pointed out that the code does not implement the "standard format" and any opcode after OP_RETURN is accepted. The email thread discussed the standard format of OP_RETURN and was started by Peter Todd. Mark Friedenbach replied, stating that the email was correct but unintentional. Jeff Garzik's name and job title are mentioned in the email signature, along with his association with BitPay, Inc. The email also featured a sponsored message from SauceLabs promoting their Selenium testing platform.In an email conversation, Mark Friedenbach compared the complexity of the current implementation using template matching to an alternative method involving a conditional statement. The discussion focused on the scripting language used in Bitcoin transactions. Friedenbach questioned whether the current implementation is more complex than using a simple 'if' statement with an OP_RETURN condition. The email exchange includes technical terms such as 'script.vch[0]' and 'OP_RETURN', highlighting the importance of considering complexity in software development.Mark Friedenbach responded to Peter Todd's message regarding the "standard format" of OP_RETURN, noting that the code did not actually implement this standard format. Any opcode after OP_RETURN is accepted, such as "OP_RETURN OP_CHECKSIG".Flavien Charlon expressed confusion about a rejected Bitcoin transaction in an email conversation with Jeff Garzik. Flavien noted that the outputs were above dust and inputs were not spent, and the carried data was well below 40 bytes. Jeff Garzik explained that all of the carried data must be contained within one pushdata.Flavien Charlon questioned why a particular transaction was being rejected despite meeting the stated guidelines. The issue seemed to be with the inputs not being spent properly. Jeff Garzik responded explaining that the data needed to be contained within one pushdata to meet the required standards.The discussion revolves around a pull request aiming to minimize the impact on the blockchain. Mark Friedenbach doubts whether such a pull request would be accepted, as each extra txout adds 9 bytes minimum without benefiting from serializing the data together in a single OP_RETURN. The concern is not extra txouts but additional pushes, which may add complexity to the IsStandard rule. The writer questions why this matters if the application already defines the meaning of the data and argues against making hash commitment less uniform with the rest of the network.In an email conversation, Mark Friedenbach expresses doubts about accepting a pull request that would add additional transaction outputs to the blockchain. He argues that each extra transaction output adds nine bytes minimum without providing any benefit over serializing the data together in a single OP_RETURN. The issue at hand is additional pushes, and Friedenbach questions the purpose of making hash commitment less uniform with the rest of the network if the application already defines the meaning of the data.A pull request may not be accepted due to its potential impact on the blockchain. Each additional transaction output adds at least 9 bytes, with no benefit gained from serializing the data together in a single OP_RETURN. Peter Todd noted that the standard format should be a single OP_RETURN, but it appears that the pull request was accepted despite this deviation.Flavien Charlon asked the Bitcoin development mailing list for help regarding a rejected transaction by Bitcoind 0.9.1 on Mainnet. The decoded transaction showed lock_time, inputs (with one prev_out), vout_sz, vin_sz, and out. The script_string included "OP_RETURN 4f41010001 753d," which is supposed to be standard in 0.9.1. However, the data was split across two PUSHDATA's, causing the rejection. The issue remains unresolved. 2014-05-05T17:30:02+00:00 + In a Bitcoin-development mailing list, Jeff Garzik clarified that the pushed-data size is limited to the standard format of OP_RETURN. He pointed out that the code does not implement the "standard format" and any opcode after OP_RETURN is accepted. The email thread discussed the standard format of OP_RETURN and was started by Peter Todd. Mark Friedenbach replied, stating that the email was correct but unintentional. Jeff Garzik's name and job title are mentioned in the email signature, along with his association with BitPay, Inc. The email also featured a sponsored message from SauceLabs promoting their Selenium testing platform.In an email conversation, Mark Friedenbach compared the complexity of the current implementation using template matching to an alternative method involving a conditional statement. The discussion focused on the scripting language used in Bitcoin transactions. Friedenbach questioned whether the current implementation is more complex than using a simple 'if' statement with an OP_RETURN condition. The email exchange includes technical terms such as 'script.vch[0]' and 'OP_RETURN', highlighting the importance of considering complexity in software development.Mark Friedenbach responded to Peter Todd's message regarding the "standard format" of OP_RETURN, noting that the code did not actually implement this standard format. Any opcode after OP_RETURN is accepted, such as "OP_RETURN OP_CHECKSIG".Flavien Charlon expressed confusion about a rejected Bitcoin transaction in an email conversation with Jeff Garzik. Flavien noted that the outputs were above dust and inputs were not spent, and the carried data was well below 40 bytes. Jeff Garzik explained that all of the carried data must be contained within one pushdata.Flavien Charlon questioned why a particular transaction was being rejected despite meeting the stated guidelines. The issue seemed to be with the inputs not being spent properly. Jeff Garzik responded explaining that the data needed to be contained within one pushdata to meet the required standards.The discussion revolves around a pull request aiming to minimize the impact on the blockchain. Mark Friedenbach doubts whether such a pull request would be accepted, as each extra txout adds 9 bytes minimum without benefiting from serializing the data together in a single OP_RETURN. The concern is not extra txouts but additional pushes, which may add complexity to the IsStandard rule. The writer questions why this matters if the application already defines the meaning of the data and argues against making hash commitment less uniform with the rest of the network.In an email conversation, Mark Friedenbach expresses doubts about accepting a pull request that would add additional transaction outputs to the blockchain. He argues that each extra transaction output adds nine bytes minimum without providing any benefit over serializing the data together in a single OP_RETURN. The issue at hand is additional pushes, and Friedenbach questions the purpose of making hash commitment less uniform with the rest of the network if the application already defines the meaning of the data.A pull request may not be accepted due to its potential impact on the blockchain. Each additional transaction output adds at least 9 bytes, with no benefit gained from serializing the data together in a single OP_RETURN. Peter Todd noted that the standard format should be a single OP_RETURN, but it appears that the pull request was accepted despite this deviation.Flavien Charlon asked the Bitcoin development mailing list for help regarding a rejected transaction by Bitcoind 0.9.1 on Mainnet. The decoded transaction showed lock_time, inputs (with one prev_out), vout_sz, vin_sz, and out. The script_string included "OP_RETURN 4f41010001 753d," which is supposed to be standard in 0.9.1. However, the data was split across two PUSHDATA's, causing the rejection. The issue remains unresolved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Compatibility-Bitcoin-Qt-with-Tails.xml b/static/bitcoin-dev/May_2014/combined_Compatibility-Bitcoin-Qt-with-Tails.xml index cdd4adbce3..1674a71f17 100644 --- a/static/bitcoin-dev/May_2014/combined_Compatibility-Bitcoin-Qt-with-Tails.xml +++ b/static/bitcoin-dev/May_2014/combined_Compatibility-Bitcoin-Qt-with-Tails.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Compatibility Bitcoin-Qt with Tails - 2023-08-01T09:02:17.758649+00:00 + 2025-10-11T22:19:35.710295+00:00 + python-feedgen Wladimir 2014-05-02 18:28:18+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Compatibility Bitcoin-Qt with Tails - 2023-08-01T09:02:17.758649+00:00 + 2025-10-11T22:19:35.710509+00:00 - On May 2, 2014, Kristov Atlas confirmed that a dev binary runs smoothly in the latest version of Tails, v1.0, which was tested by him. Wladimir assured that the usual Linux binary would be compatible when incorporated into the next release of Bitcoin Core, but he mentioned the possibility of adding a binary linked to Qt 5.x for newer distributions at some point. Compatibility remains their primary concern. Earlier on April 30th, 2014, Kristov Atlas reported an issue with a binary built by Wladimir where the GUI segfaulted after choosing the default datadir. However, Wladimir fixed the issue and created a new test build which is available for download from visucore.com. This dev binary was confirmed to run smoothly in Tails v1.0 by Kristov Atlas. It is unclear whether this will make the usual Linux binary compatible or if there will be a special binary just for systems running the older Qt.In another email sent on April 26, 2014, Kristov Atlas thanked Wladimir for building a binary to fix the initial problem with Qt, but mentioned that after choosing the default datadir, it still segfaulted. Wladimir addressed this issue and made a new test build available for download. The details of the fix can be found on GitHub at https://github.com/bitcoin/bitcoin/pull/4094. The new test build can be downloaded from https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz, with signatures available at https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz.sig.The context also includes a sample terminal output for the latest Tails operating system version 0.23. The user encountered errors when attempting to run the bitcoin-qt command, including "Bus::open: Can not get ibus-daemon's address," "IBusInputContext::createInputContext: no connection to ibus-daemon," and "sendto: Operation not permitted." Additionally, a "Segmentation fault" error occurred when running the command with a proxy. The user requested a traceback from Wladimir, the creator of Bitcoin.In an email exchange between Wladimir and Kristov, Wladimir mentioned modifying the gitian build to work with Qt 4.6 instead of Qt 4.8 in a pull request. He provided a test build of master with the updated gitian descriptor that should work on Debian Squeeze/Tails Linux. Kristov confirmed that the initial problem with Qt was resolved and he was able to load the GUI to choose his datadir. However, after selecting the default datadir, it segfaulted. The "sendto: Operation not permitted" message indicated that Core couldn't connect to the internet without going through Tails' Tor SOCKS proxy. When Kristov specified the SOCKS proxy through the command-line, there was a brief flash of the GUI before it segfaulted again. The "Bus::open" and "IBusInputContext::createInputContext" messages were considered atypical and might be related to the segfault. Lastly, in an email conversation between Kristov Atlas and Warren Togami Jr. on April 23, 2014, Kristov shared that he had modified the gitian build to use Qt 4.6 instead of 4.8, aiming to make it compatible with Tails/Debian Squeeze. He provided a link to a test build of master with the updated gitian descriptor that should work on Debian Squeeze / Tails Linux, along with the links to download the bitcoin-qt executables. 2014-05-02T18:28:18+00:00 + On May 2, 2014, Kristov Atlas confirmed that a dev binary runs smoothly in the latest version of Tails, v1.0, which was tested by him. Wladimir assured that the usual Linux binary would be compatible when incorporated into the next release of Bitcoin Core, but he mentioned the possibility of adding a binary linked to Qt 5.x for newer distributions at some point. Compatibility remains their primary concern. Earlier on April 30th, 2014, Kristov Atlas reported an issue with a binary built by Wladimir where the GUI segfaulted after choosing the default datadir. However, Wladimir fixed the issue and created a new test build which is available for download from visucore.com. This dev binary was confirmed to run smoothly in Tails v1.0 by Kristov Atlas. It is unclear whether this will make the usual Linux binary compatible or if there will be a special binary just for systems running the older Qt.In another email sent on April 26, 2014, Kristov Atlas thanked Wladimir for building a binary to fix the initial problem with Qt, but mentioned that after choosing the default datadir, it still segfaulted. Wladimir addressed this issue and made a new test build available for download. The details of the fix can be found on GitHub at https://github.com/bitcoin/bitcoin/pull/4094. The new test build can be downloaded from https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz, with signatures available at https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz.sig.The context also includes a sample terminal output for the latest Tails operating system version 0.23. The user encountered errors when attempting to run the bitcoin-qt command, including "Bus::open: Can not get ibus-daemon's address," "IBusInputContext::createInputContext: no connection to ibus-daemon," and "sendto: Operation not permitted." Additionally, a "Segmentation fault" error occurred when running the command with a proxy. The user requested a traceback from Wladimir, the creator of Bitcoin.In an email exchange between Wladimir and Kristov, Wladimir mentioned modifying the gitian build to work with Qt 4.6 instead of Qt 4.8 in a pull request. He provided a test build of master with the updated gitian descriptor that should work on Debian Squeeze/Tails Linux. Kristov confirmed that the initial problem with Qt was resolved and he was able to load the GUI to choose his datadir. However, after selecting the default datadir, it segfaulted. The "sendto: Operation not permitted" message indicated that Core couldn't connect to the internet without going through Tails' Tor SOCKS proxy. When Kristov specified the SOCKS proxy through the command-line, there was a brief flash of the GUI before it segfaulted again. The "Bus::open" and "IBusInputContext::createInputContext" messages were considered atypical and might be related to the segfault. Lastly, in an email conversation between Kristov Atlas and Warren Togami Jr. on April 23, 2014, Kristov shared that he had modified the gitian build to use Qt 4.6 instead of 4.8, aiming to make it compatible with Tails/Debian Squeeze. He provided a link to a test build of master with the updated gitian descriptor that should work on Debian Squeeze / Tails Linux, along with the links to download the bitcoin-qt executables. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Cut-through-propagation-of-blocks.xml b/static/bitcoin-dev/May_2014/combined_Cut-through-propagation-of-blocks.xml index e182866d1d..f447c8cf69 100644 --- a/static/bitcoin-dev/May_2014/combined_Cut-through-propagation-of-blocks.xml +++ b/static/bitcoin-dev/May_2014/combined_Cut-through-propagation-of-blocks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Cut-through propagation of blocks - 2023-08-01T09:24:15.616429+00:00 + 2025-10-11T22:19:48.455206+00:00 + python-feedgen Mike Hearn 2014-05-26 15:08:46+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Cut-through propagation of blocks - 2023-08-01T09:24:15.616429+00:00 + 2025-10-11T22:19:48.455358+00:00 - The discussion revolves around whether to run experimental p2p code inside production bitcoinds or to run an experimental gateway in another process on a node. It is suggested that running the experimental gateway during the development phase would be better. However, if the code proves valuable, it should eventually be integrated or rewritten into Core to avoid increasing the setup cost of running a node and ending up with a two-tier network. The tradeoffs involved in this decision are complex and subtle. If the code will eventually be merged into Core, it might as well be implemented directly into it, perhaps behind a switch that can disable those code paths if something goes wrong.Bitcoin developer Mike Hearn discussed creating an alternative to the current P2P protocol in an email exchange with others. While some argued that it could improve feature velocity, Hearn pointed out that implementing features twice in two protocols would slow things down. However, he did concede that certain use cases might require an alternative protocol. An advantage of an alternative protocol is that it can proceed asynchronously with implementation development, allowing for faster revving of versions. Additionally, if there are bugs, it wouldn't break the nodes using it, making it less risky than experimental p2p code inside production bitcoinds themselves.The idea of having multiple protocols for Bitcoin transport is suggested for better robustness and feature velocity. However, implementing features twice in two different protocols could slow things down. The current p2p protocol is considered efficient, and fixing the 100msec sleep and measuring latency and queuing inside the code are seen as the lowest hanging fruit for improvements.In an email conversation between Gregory Maxwell and Alan Reiner, they discussed a modification in the way Bitcoin Core prioritizes blocks. Currently, it uses the first full block verified as the highest priority, but Reiner suggests considering the first valid header received as the highest priority. Maxwell points out that this would open up an attack where someone could delay announcing the block content and continue to mine on the block without others being able to do so. Maxwell suggests putting an expiration on the logic by ignoring the header-received time if the full new block hasn't been received within 5-10 seconds. They also mention Ashley, who is apparently working on solving this issue.Bitcoin Core developer Alan Reiner proposed modifying the way Bitcoin Core prioritizes blocks in an email from May 2014. Currently, it uses the first full block verified instead of considering the first valid header received as the highest priority. Reiner suggests this change because the current system opens up an attack where one can delay announcing the content of a block while continuing to mine on it. Reiner also addresses concerns about the 1-3 second gap that could occur with the new system and advises miners to focus on making sure the transactions they are mining are well-propagated already. Additionally, he suggests that with an alternative transport protocol, similar latency could be achieved without increasing the motivations for miners to misbehave.In a discussion among Bitcoin Core developers on May 24, 2014, concerns were raised about potential denial of service (DoS) attacks on the Bitcoin network. One developer notes that an attacker with sufficient hash power could use cut-through forwarding to carry out such an attack, while another points out the possibility of a teergrube attack in which the attacker prevents blocks from being transmitted to the network. The conversation also focuses on issues related to block propagation and suggests improvements to the peer-to-peer protocol. One proposed solution is to allow for multiplexing of messages using something like HTTP chunked encoding to prevent slow messages from causing delays. Another suggestion is to modify the way Bitcoin Core prioritizes blocks by giving priority to the first valid header received rather than the first full block verified. This would allow nodes to mine on whatever full and verified block they have with the earliest header-received time, switching to mining on a new block only once it has done full verification of the block.Bitcoin's ability to establish the primacy of blocks by time through incentives arising from block propagation times has been underestimated. Partitions on the network evolve as a block is propagated, with blocks reaching over 50% of the network in five seconds. This means that 50% of the hashing power are already building a block that builds on top of the block that is already circulating, resulting in a fast decline in the probability of a collision on the network. However, miners who are less well connected to the network may find block propagation times a bigger issue, as they spend more time mining redundant problems and may find blocks to compete with blocks that are already spreading throughout the network.In a discussion among Bitcoin developers on May 25, 2014, concerns were raised regarding possible attacks on the network. One issue was the possibility of a 'teergrube attack' where an attacker aims to fill the network with empty blocks by not sending the block body, while another was the potential for an attacker to subjugate the entire network 2014-05-26T15:08:46+00:00 + The discussion revolves around whether to run experimental p2p code inside production bitcoinds or to run an experimental gateway in another process on a node. It is suggested that running the experimental gateway during the development phase would be better. However, if the code proves valuable, it should eventually be integrated or rewritten into Core to avoid increasing the setup cost of running a node and ending up with a two-tier network. The tradeoffs involved in this decision are complex and subtle. If the code will eventually be merged into Core, it might as well be implemented directly into it, perhaps behind a switch that can disable those code paths if something goes wrong.Bitcoin developer Mike Hearn discussed creating an alternative to the current P2P protocol in an email exchange with others. While some argued that it could improve feature velocity, Hearn pointed out that implementing features twice in two protocols would slow things down. However, he did concede that certain use cases might require an alternative protocol. An advantage of an alternative protocol is that it can proceed asynchronously with implementation development, allowing for faster revving of versions. Additionally, if there are bugs, it wouldn't break the nodes using it, making it less risky than experimental p2p code inside production bitcoinds themselves.The idea of having multiple protocols for Bitcoin transport is suggested for better robustness and feature velocity. However, implementing features twice in two different protocols could slow things down. The current p2p protocol is considered efficient, and fixing the 100msec sleep and measuring latency and queuing inside the code are seen as the lowest hanging fruit for improvements.In an email conversation between Gregory Maxwell and Alan Reiner, they discussed a modification in the way Bitcoin Core prioritizes blocks. Currently, it uses the first full block verified as the highest priority, but Reiner suggests considering the first valid header received as the highest priority. Maxwell points out that this would open up an attack where someone could delay announcing the block content and continue to mine on the block without others being able to do so. Maxwell suggests putting an expiration on the logic by ignoring the header-received time if the full new block hasn't been received within 5-10 seconds. They also mention Ashley, who is apparently working on solving this issue.Bitcoin Core developer Alan Reiner proposed modifying the way Bitcoin Core prioritizes blocks in an email from May 2014. Currently, it uses the first full block verified instead of considering the first valid header received as the highest priority. Reiner suggests this change because the current system opens up an attack where one can delay announcing the content of a block while continuing to mine on it. Reiner also addresses concerns about the 1-3 second gap that could occur with the new system and advises miners to focus on making sure the transactions they are mining are well-propagated already. Additionally, he suggests that with an alternative transport protocol, similar latency could be achieved without increasing the motivations for miners to misbehave.In a discussion among Bitcoin Core developers on May 24, 2014, concerns were raised about potential denial of service (DoS) attacks on the Bitcoin network. One developer notes that an attacker with sufficient hash power could use cut-through forwarding to carry out such an attack, while another points out the possibility of a teergrube attack in which the attacker prevents blocks from being transmitted to the network. The conversation also focuses on issues related to block propagation and suggests improvements to the peer-to-peer protocol. One proposed solution is to allow for multiplexing of messages using something like HTTP chunked encoding to prevent slow messages from causing delays. Another suggestion is to modify the way Bitcoin Core prioritizes blocks by giving priority to the first valid header received rather than the first full block verified. This would allow nodes to mine on whatever full and verified block they have with the earliest header-received time, switching to mining on a new block only once it has done full verification of the block.Bitcoin's ability to establish the primacy of blocks by time through incentives arising from block propagation times has been underestimated. Partitions on the network evolve as a block is propagated, with blocks reaching over 50% of the network in five seconds. This means that 50% of the hashing power are already building a block that builds on top of the block that is already circulating, resulting in a fast decline in the probability of a collision on the network. However, miners who are less well connected to the network may find block propagation times a bigger issue, as they spend more time mining redundant problems and may find blocks to compete with blocks that are already spreading throughout the network.In a discussion among Bitcoin developers on May 25, 2014, concerns were raised regarding possible attacks on the network. One issue was the possibility of a 'teergrube attack' where an attacker aims to fill the network with empty blocks by not sending the block body, while another was the potential for an attacker to subjugate the entire network - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_DNS-seeds-unstable.xml b/static/bitcoin-dev/May_2014/combined_DNS-seeds-unstable.xml index b801eb0521..1d1aac8450 100644 --- a/static/bitcoin-dev/May_2014/combined_DNS-seeds-unstable.xml +++ b/static/bitcoin-dev/May_2014/combined_DNS-seeds-unstable.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DNS seeds unstable - 2023-08-01T09:15:49.337291+00:00 + 2025-10-11T22:19:14.446190+00:00 + python-feedgen Andreas Schildbach 2014-06-11 14:24:21+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - DNS seeds unstable - 2023-08-01T09:15:49.338289+00:00 + 2025-10-11T22:19:14.446422+00:00 - The Bitcoin DNS seed infrastructure has been identified as unstable, potentially due to a custom DNS implementation that is not fully compatible. In the past, bugs such as case-sensitive matches for domain names have also contributed to the problem. The current state of the seeds, as reported by bitcoinj, reveals that some are functioning properly while others are experiencing SERVFAIL issues. One seed is being tested across multiple ISPs and another is only returning one node.Telefónica, one of Europe's largest ISPs, has encountered difficulties with the testnet-seed.bitcoin.petertodd.org seed. While there is a desire to address the situation, the writer of the article lacks the necessary C writing skills to do so. Suggestions have been made to increase the number of seeders and enable zone transfers, allowing existing seeders to distribute their records to multiple servers running standard DNS servers like bind, among others.The writer proposes a potential fix by re-implementing everything in Java, although they acknowledge that others may not be satisfied with this solution. It is crucial for Bitcoin apps to account for the potential issues associated with relying solely on seeds, as they serve as a backup for peer exchange. Jeff Garzik, a Bitcoin core developer and open-source evangelist, emphasizes the importance of addressing the problem but notes that it could also be attributed to issues with bitcoinj or other layers within the app. Garzik works for BitPay, Inc., a payment service provider facilitating Bitcoin payments for merchants. 2014-06-11T14:24:21+00:00 + The Bitcoin DNS seed infrastructure has been identified as unstable, potentially due to a custom DNS implementation that is not fully compatible. In the past, bugs such as case-sensitive matches for domain names have also contributed to the problem. The current state of the seeds, as reported by bitcoinj, reveals that some are functioning properly while others are experiencing SERVFAIL issues. One seed is being tested across multiple ISPs and another is only returning one node.Telefónica, one of Europe's largest ISPs, has encountered difficulties with the testnet-seed.bitcoin.petertodd.org seed. While there is a desire to address the situation, the writer of the article lacks the necessary C writing skills to do so. Suggestions have been made to increase the number of seeders and enable zone transfers, allowing existing seeders to distribute their records to multiple servers running standard DNS servers like bind, among others.The writer proposes a potential fix by re-implementing everything in Java, although they acknowledge that others may not be satisfied with this solution. It is crucial for Bitcoin apps to account for the potential issues associated with relying solely on seeds, as they serve as a backup for peer exchange. Jeff Garzik, a Bitcoin core developer and open-source evangelist, emphasizes the importance of addressing the problem but notes that it could also be attributed to issues with bitcoinj or other layers within the app. Garzik works for BitPay, Inc., a payment service provider facilitating Bitcoin payments for merchants. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Developer-documentation-on-bitcoin-org.xml b/static/bitcoin-dev/May_2014/combined_Developer-documentation-on-bitcoin-org.xml index fae4017b04..1b10c80094 100644 --- a/static/bitcoin-dev/May_2014/combined_Developer-documentation-on-bitcoin-org.xml +++ b/static/bitcoin-dev/May_2014/combined_Developer-documentation-on-bitcoin-org.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Developer documentation on bitcoin.org - 2023-08-01T09:13:17.921924+00:00 + 2025-10-11T22:20:26.769766+00:00 + python-feedgen Saïvann Carignan 2014-05-19 22:22:48+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Developer documentation on bitcoin.org - 2023-08-01T09:13:17.921924+00:00 + 2025-10-11T22:20:26.769914+00:00 - Saïvann Carignan, a Bitcoin developer, has announced that bitcoin.org will soon be adding a new section called "Developer Documentation". This documentation aims to provide comprehensive technical knowledge to developers. The documentation has been extensively worked on to ensure its quality, and the feedback received so far has been positive.Experienced Bitcoin developers are now invited to help proofread the documentation before it is published. The pull request for the documentation can be found on GitHub, where reviews and feedback are welcome. It is important to note that the pull request will be merged on May 24th, so any inaccuracies or mistakes should be reported as soon as possible.To avoid spamming everyone, comments on the pull request or the bitcoin-documentation mailing list are requested instead of commenting on the mailing list directly. Interested individuals can find instructions for commenting on the pull request or joining the Bitcoin-documentation mailing list at github.com/bitcoin/bitcoin.org/pull/393.A live preview of the Developer Documentation section can be accessed at bitcoindev.us.to/en/developer-documentation. Additionally, there is a Bitcointalk thread about the documentation at bitcointalk.org/index.php?topic=511876.0. Wladimir, a member of the Bitcoin community, has already praised the work, mentioning that he has been reading it and hasn't found any technical issues yet.Overall, the addition of the Developer Documentation section to bitcoin.org is a significant step in providing valuable resources and technical information to Bitcoin developers. The documentation has been carefully prepared and feedback from experienced developers is encouraged to ensure its accuracy and usefulness. 2014-05-19T22:22:48+00:00 + Saïvann Carignan, a Bitcoin developer, has announced that bitcoin.org will soon be adding a new section called "Developer Documentation". This documentation aims to provide comprehensive technical knowledge to developers. The documentation has been extensively worked on to ensure its quality, and the feedback received so far has been positive.Experienced Bitcoin developers are now invited to help proofread the documentation before it is published. The pull request for the documentation can be found on GitHub, where reviews and feedback are welcome. It is important to note that the pull request will be merged on May 24th, so any inaccuracies or mistakes should be reported as soon as possible.To avoid spamming everyone, comments on the pull request or the bitcoin-documentation mailing list are requested instead of commenting on the mailing list directly. Interested individuals can find instructions for commenting on the pull request or joining the Bitcoin-documentation mailing list at github.com/bitcoin/bitcoin.org/pull/393.A live preview of the Developer Documentation section can be accessed at bitcoindev.us.to/en/developer-documentation. Additionally, there is a Bitcointalk thread about the documentation at bitcointalk.org/index.php?topic=511876.0. Wladimir, a member of the Bitcoin community, has already praised the work, mentioning that he has been reading it and hasn't found any technical issues yet.Overall, the addition of the Developer Documentation section to bitcoin.org is a significant step in providing valuable resources and technical information to Bitcoin developers. The documentation has been carefully prepared and feedback from experienced developers is encouraged to ensure its accuracy and usefulness. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_ECDH-in-the-payment-protocol.xml b/static/bitcoin-dev/May_2014/combined_ECDH-in-the-payment-protocol.xml index 781567e222..680243f9b6 100644 --- a/static/bitcoin-dev/May_2014/combined_ECDH-in-the-payment-protocol.xml +++ b/static/bitcoin-dev/May_2014/combined_ECDH-in-the-payment-protocol.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ECDH in the payment protocol - 2023-08-01T09:13:02.325424+00:00 + 2025-10-11T22:20:31.015749+00:00 + python-feedgen Mike Hearn 2014-05-13 10:29:43+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - ECDH in the payment protocol - 2023-08-01T09:13:02.326423+00:00 + 2025-10-11T22:20:31.015925+00:00 - Chris Pacia and another individual discussed the potential of using the payment protocol for stealth, which would require frequent wallet backups. They considered auto-respending transactions to a private HD derived key, but this approach would be inefficient in terms of block space. The ability to access funds with just 12 words and a date is desirable.Peter Todd and Jeff Garzik rejected the idea of depending solely on a communications backchannel to retrieve funds as it would make the payment non-atomic. Garzik argues that putting the communications medium in the blockchain itself is wrong and goes against the purpose of the blockchain.Pieter Wuille proposed using PaymentACK messages as proof of payment. The sender would send a Payment message containing a scriptSig-less Bitcoin transaction and a limit on its byte size to the receiver. Once the receiver acknowledges it, the sender can either send the full transaction or broadcast it themselves. This approach ensures both parties agree with the transaction before committing.In a conversation between Peter Todd and Pieter Wuille, Wuille proposed a method for making payments more atomic. It involves having PaymentACK messages signed with the same key as the payment request. The sender would send a scriptSig-less Bitcoin transaction with byte size and sigop count limits to the receiver. The receiver would only acknowledge the transaction if it satisfies certain criteria. However, there are still issues with the system, such as the possibility of the sender withholding the signed transaction or the receiver claiming to have never received it.Pieter Wuille posted about the benefits of stealth addresses and payment protocols. He suggests improving atomicity in the payment protocol instead of adding stealth functionality as a last resort. However, there are many edge cases due to how payments tie up txouts. Wuille also plans to write a relaxed version of IsStandard() rules based on soft-fork safe whitelisting/blacklisting.The speaker discusses a proposed method of including nonces in a payment protocol. They acknowledge that it makes sense but understand the proposal.The author believes that stealth addresses and payment protocols have different use cases. They suggest using anonymous donations for anonymity and direct communication for other benefits such as negotiating transaction details and refund information. The author suggests improving atomicity instead of adding stealth functionality as a last resort.Mike Hearn proposes a method to achieve atomicity and stealth payments without additional space in the blockchain. A lightweight client would identify transactions via the payment protocol. The speaker discusses the benefits of atomicity and extending BIP70 with ECDH.Todd proposed the idea of using a communication backchannel for retrieving funds again, but this time, the payment messages would be sent directly to the merchant who takes responsibility for broadcast. The author argues that a good store and forward network ensures atomicity.Mike Hearn mentions Amir Taaki's proposal for stealth addresses but rejects the idea of depending solely on a communication backchannel for retrieving funds. He also addresses recent advancements in ECDH multi-party signing and emphasizes the importance of letting the free market for fees do its job.The article discusses an ECDH extension for BIP 70 that is not backward compatible with the stealth address proposal. It resolves privacy issues and allows for attaching messages to payments. The article presents a way to combine nonces for backwards compatibility. The article also discusses the justification for the original stealth address design. 2014-05-13T10:29:43+00:00 + Chris Pacia and another individual discussed the potential of using the payment protocol for stealth, which would require frequent wallet backups. They considered auto-respending transactions to a private HD derived key, but this approach would be inefficient in terms of block space. The ability to access funds with just 12 words and a date is desirable.Peter Todd and Jeff Garzik rejected the idea of depending solely on a communications backchannel to retrieve funds as it would make the payment non-atomic. Garzik argues that putting the communications medium in the blockchain itself is wrong and goes against the purpose of the blockchain.Pieter Wuille proposed using PaymentACK messages as proof of payment. The sender would send a Payment message containing a scriptSig-less Bitcoin transaction and a limit on its byte size to the receiver. Once the receiver acknowledges it, the sender can either send the full transaction or broadcast it themselves. This approach ensures both parties agree with the transaction before committing.In a conversation between Peter Todd and Pieter Wuille, Wuille proposed a method for making payments more atomic. It involves having PaymentACK messages signed with the same key as the payment request. The sender would send a scriptSig-less Bitcoin transaction with byte size and sigop count limits to the receiver. The receiver would only acknowledge the transaction if it satisfies certain criteria. However, there are still issues with the system, such as the possibility of the sender withholding the signed transaction or the receiver claiming to have never received it.Pieter Wuille posted about the benefits of stealth addresses and payment protocols. He suggests improving atomicity in the payment protocol instead of adding stealth functionality as a last resort. However, there are many edge cases due to how payments tie up txouts. Wuille also plans to write a relaxed version of IsStandard() rules based on soft-fork safe whitelisting/blacklisting.The speaker discusses a proposed method of including nonces in a payment protocol. They acknowledge that it makes sense but understand the proposal.The author believes that stealth addresses and payment protocols have different use cases. They suggest using anonymous donations for anonymity and direct communication for other benefits such as negotiating transaction details and refund information. The author suggests improving atomicity instead of adding stealth functionality as a last resort.Mike Hearn proposes a method to achieve atomicity and stealth payments without additional space in the blockchain. A lightweight client would identify transactions via the payment protocol. The speaker discusses the benefits of atomicity and extending BIP70 with ECDH.Todd proposed the idea of using a communication backchannel for retrieving funds again, but this time, the payment messages would be sent directly to the merchant who takes responsibility for broadcast. The author argues that a good store and forward network ensures atomicity.Mike Hearn mentions Amir Taaki's proposal for stealth addresses but rejects the idea of depending solely on a communication backchannel for retrieving funds. He also addresses recent advancements in ECDH multi-party signing and emphasizes the importance of letting the free market for fees do its job.The article discusses an ECDH extension for BIP 70 that is not backward compatible with the stealth address proposal. It resolves privacy issues and allows for attaching messages to payments. The article presents a way to combine nonces for backwards compatibility. The article also discusses the justification for the original stealth address design. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_PSA-Please-sign-your-git-commits.xml b/static/bitcoin-dev/May_2014/combined_PSA-Please-sign-your-git-commits.xml index 4891850790..5b982ddb92 100644 --- a/static/bitcoin-dev/May_2014/combined_PSA-Please-sign-your-git-commits.xml +++ b/static/bitcoin-dev/May_2014/combined_PSA-Please-sign-your-git-commits.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - PSA: Please sign your git commits - 2023-08-01T09:22:12.107933+00:00 + 2025-10-11T22:19:20.825837+00:00 + python-feedgen Chris Beams 2014-06-09 15:34:18+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - PSA: Please sign your git commits - 2023-08-01T09:22:12.107933+00:00 + 2025-10-11T22:19:20.826001+00:00 - With the release of Git 2.0, automatic commit signing is now possible with the 'commit.gpgsign' configuration option. However, there is a negative impact on speed when a large number of commits are involved. The context discusses the concept of multisig, which is beneficial for irreversible actions but not necessary most of the time. Although it has been implemented in bitcoin wallets, no PGP developer or user ever thought to implement it. In a mailing list discussion, Jeff Garzik emphasized that current multi-sig wallet technology is arguably more secure than PGP keyring. In an email exchange between Wladimir and Chris Beams, Chris suggests complying with commit signing for future commits but questions its effectiveness. In a conversation between Jeff Garzik and Wladimir, they discuss the security of multi-sig wallets compared to PGP keyrings.The email conversation between David A. Harding and Chris Beams discusses how to enable signing commits by default in Git. They mention the use of a script that can be added to .git/hooks/post-commit and post-merge to ensure proper signature of commit messages. In a discussion thread from 2014, Mark Friedenbach posed an honest question about the benefits of signed commits in Git. In a discussion on the use of commit signing in Git, Chris Beams expresses his willingness to comply with it while also questioning its efficacy. In an email from May 2014, Chris Beams expressed his desire for a way to enable signing Git commits by default and noted that most people would probably forget to do it. In an email exchange between Chris Beams and Wladimir J. van der Laan, the two discussed the idea of requiring signed commits in Github development process. A contributor to Bitcoin Core development, Chris, has responded to a request from Wladimir to sign git commits.Bitcoin Core developers are advised to sign their git commits as it helps in ensuring the integrity of the tree. To sign a commit, users need to provide the `-S` flag or `--gpg-sign` to git commit when committing changes. Users can also retroactively sign previous commits using `--amend`, or use the interactive rebase command with 'edit' to go back further. It is important to note that rewriting history will require resigning as signatures will be lost. To check if commits are signed, users can use git log with show-signature. Pieter Wullie has created a script that simplifies merging and signing and can be found in contrib/devtools. The script can be used to merge pull requests and drop users into a shell to verify changes and test. 2014-06-09T15:34:18+00:00 + With the release of Git 2.0, automatic commit signing is now possible with the 'commit.gpgsign' configuration option. However, there is a negative impact on speed when a large number of commits are involved. The context discusses the concept of multisig, which is beneficial for irreversible actions but not necessary most of the time. Although it has been implemented in bitcoin wallets, no PGP developer or user ever thought to implement it. In a mailing list discussion, Jeff Garzik emphasized that current multi-sig wallet technology is arguably more secure than PGP keyring. In an email exchange between Wladimir and Chris Beams, Chris suggests complying with commit signing for future commits but questions its effectiveness. In a conversation between Jeff Garzik and Wladimir, they discuss the security of multi-sig wallets compared to PGP keyrings.The email conversation between David A. Harding and Chris Beams discusses how to enable signing commits by default in Git. They mention the use of a script that can be added to .git/hooks/post-commit and post-merge to ensure proper signature of commit messages. In a discussion thread from 2014, Mark Friedenbach posed an honest question about the benefits of signed commits in Git. In a discussion on the use of commit signing in Git, Chris Beams expresses his willingness to comply with it while also questioning its efficacy. In an email from May 2014, Chris Beams expressed his desire for a way to enable signing Git commits by default and noted that most people would probably forget to do it. In an email exchange between Chris Beams and Wladimir J. van der Laan, the two discussed the idea of requiring signed commits in Github development process. A contributor to Bitcoin Core development, Chris, has responded to a request from Wladimir to sign git commits.Bitcoin Core developers are advised to sign their git commits as it helps in ensuring the integrity of the tree. To sign a commit, users need to provide the `-S` flag or `--gpg-sign` to git commit when committing changes. Users can also retroactively sign previous commits using `--amend`, or use the interactive rebase command with 'edit' to go back further. It is important to note that rewriting history will require resigning as signatures will be lost. To check if commits are signed, users can use git log with show-signature. Pieter Wullie has created a script that simplifies merging and signing and can be found in contrib/devtools. The script can be used to merge pull requests and drop users into a shell to verify changes and test. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Paper-Currency.xml b/static/bitcoin-dev/May_2014/combined_Paper-Currency.xml index 23a1362381..d690d5c2c2 100644 --- a/static/bitcoin-dev/May_2014/combined_Paper-Currency.xml +++ b/static/bitcoin-dev/May_2014/combined_Paper-Currency.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Paper Currency - 2023-08-01T09:17:54.128523+00:00 + 2025-10-11T22:20:03.350643+00:00 + python-feedgen Peter Todd 2014-05-19 18:39:21+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - Paper Currency - 2023-08-01T09:17:54.129518+00:00 + 2025-10-11T22:20:03.350828+00:00 - Participants in discussions about the use of paper money in Bitcoin highlighted the importance of usability and maintaining high standards. One suggestion was to use Trusted Platform Modules (TPMs) as a solution to protect against unauthorized redemption. These discussions focused on the need for a social contract in Bitcoin, secure and decentralized paper implementations of sidechains, and the potential of paper currency representing bitcoins. The conversations emphasized the ongoing efforts within the Bitcoin community to improve security, usability, and trust in the system.In an email thread, Chris Pacia expressed concerns about the security of using physical bitcoin notes. He pointed out that simply scanning the note is not enough to ensure validity, as it must be successfully swept to avoid double-spending. This creates a vulnerability for any prior bearer to record private keys and perform a double-spend race later on. Chris also suggested that Othercoin has better properties for offline transactions. Separately, Cassius encountered regulatory issues with selling physical bitcoin artifacts, especially those that imply redeemable value. The base58 encoding used for the physical bitcoins was criticized for being unfriendly to humans, and the A/B side design may be difficult to educate users about. It was also noted that there is no way to check txouts without recovering the private key, but this may not be necessary since no one should rely on such a measurement without sweeping.Chris, a user on the Bitcoin-development mailing list, expressed concern about the viability of using paper currency to transfer bitcoins due to the need for immediate redemption and the potential for fraud. He also mentioned that this method would not work well in areas with poor internet connectivity. On the other hand, Jerry Felix proposed the idea of creating a counterfeit-resistant, inexpensive, internationally recognized, machine-readable paper currency that could be used to transfer bitcoins. He documented his proposed standard in BIP format and shared it on GitHub for discussion. Despite some fear of being laughed at, he submitted his proposal with humility.Jerry Felix wrote an email on May 17, 2014, at 11:31 am stating that he had picked some BIP numbers himself that seemed to be available. However, it was pointed out to him that this action was not allowed.In summary, there is a need for a counterfeit-resistant, inexpensive, internationally recognized, machine-readable paper currency that can fit in a wallet. This idea was presented at the Cincinnati Bitcoin meetup and has been documented into a proposed standard called provisional BIPs numbered BIP-80 to BIP-84. The proposal can be found on GitHub, and the author welcomes discussion about the idea. 2014-05-19T18:39:21+00:00 + Participants in discussions about the use of paper money in Bitcoin highlighted the importance of usability and maintaining high standards. One suggestion was to use Trusted Platform Modules (TPMs) as a solution to protect against unauthorized redemption. These discussions focused on the need for a social contract in Bitcoin, secure and decentralized paper implementations of sidechains, and the potential of paper currency representing bitcoins. The conversations emphasized the ongoing efforts within the Bitcoin community to improve security, usability, and trust in the system.In an email thread, Chris Pacia expressed concerns about the security of using physical bitcoin notes. He pointed out that simply scanning the note is not enough to ensure validity, as it must be successfully swept to avoid double-spending. This creates a vulnerability for any prior bearer to record private keys and perform a double-spend race later on. Chris also suggested that Othercoin has better properties for offline transactions. Separately, Cassius encountered regulatory issues with selling physical bitcoin artifacts, especially those that imply redeemable value. The base58 encoding used for the physical bitcoins was criticized for being unfriendly to humans, and the A/B side design may be difficult to educate users about. It was also noted that there is no way to check txouts without recovering the private key, but this may not be necessary since no one should rely on such a measurement without sweeping.Chris, a user on the Bitcoin-development mailing list, expressed concern about the viability of using paper currency to transfer bitcoins due to the need for immediate redemption and the potential for fraud. He also mentioned that this method would not work well in areas with poor internet connectivity. On the other hand, Jerry Felix proposed the idea of creating a counterfeit-resistant, inexpensive, internationally recognized, machine-readable paper currency that could be used to transfer bitcoins. He documented his proposed standard in BIP format and shared it on GitHub for discussion. Despite some fear of being laughed at, he submitted his proposal with humility.Jerry Felix wrote an email on May 17, 2014, at 11:31 am stating that he had picked some BIP numbers himself that seemed to be available. However, it was pointed out to him that this action was not allowed.In summary, there is a need for a counterfeit-resistant, inexpensive, internationally recognized, machine-readable paper currency that can fit in a wallet. This idea was presented at the Cincinnati Bitcoin meetup and has been documented into a proposed standard called provisional BIPs numbered BIP-80 to BIP-84. The proposal can be found on GitHub, and the author welcomes discussion about the idea. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Prenumbered-BIP-naming.xml b/static/bitcoin-dev/May_2014/combined_Prenumbered-BIP-naming.xml index 281dddf169..2c75ea409a 100644 --- a/static/bitcoin-dev/May_2014/combined_Prenumbered-BIP-naming.xml +++ b/static/bitcoin-dev/May_2014/combined_Prenumbered-BIP-naming.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Prenumbered BIP naming - 2023-08-01T09:14:21.541021+00:00 + 2025-10-11T22:20:09.773809+00:00 + python-feedgen Gregory Maxwell 2014-05-12 17:11:25+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Prenumbered BIP naming - 2023-08-01T09:14:21.541021+00:00 + 2025-10-11T22:20:09.773964+00:00 - In a conversation on May 12, 2014, Matt Whitlock raised concerns about the difficulty of obtaining a BIP (Bitcoin Improvement Proposals) number. Despite BIP 1 suggesting that assigning a number is not a significant hurdle, proposals that require hours of work are not receiving numbers. Whitlock questioned whether the numbers are only given to well-liked proposals and if the purpose of assigning numbers was not to facilitate organized discussions about all proposals, including those that are not popular.The response clarified that assigning numbers to proposals that have not been publicly discussed is not part of the BIP process. If individuals want to create specifications without engaging in public discussion, they can do so, but BIP is not intended for that purpose. The primary reason for assigning numbers is to provide a reference for a proposal before further actions are taken. This issue is also present in other contexts.To address the struggle of attaching labels to their yet-to-be-numbered BIPs, Gregory Maxwell suggested in May 2014 that individuals should use the labeling format "draft--" followed by the name of the BIP, such as draft-maxwell-coinburning. This format is inspired by pre-WG IETF drafts. Despite this suggestion, it remains unclear why there is a high bar for obtaining a BIP number, especially considering that there is no shortage of available integers. The assignment of numbers is meant to enable organized discussions about all proposals, even those that may not be well-liked. 2014-05-12T17:11:25+00:00 + In a conversation on May 12, 2014, Matt Whitlock raised concerns about the difficulty of obtaining a BIP (Bitcoin Improvement Proposals) number. Despite BIP 1 suggesting that assigning a number is not a significant hurdle, proposals that require hours of work are not receiving numbers. Whitlock questioned whether the numbers are only given to well-liked proposals and if the purpose of assigning numbers was not to facilitate organized discussions about all proposals, including those that are not popular.The response clarified that assigning numbers to proposals that have not been publicly discussed is not part of the BIP process. If individuals want to create specifications without engaging in public discussion, they can do so, but BIP is not intended for that purpose. The primary reason for assigning numbers is to provide a reference for a proposal before further actions are taken. This issue is also present in other contexts.To address the struggle of attaching labels to their yet-to-be-numbered BIPs, Gregory Maxwell suggested in May 2014 that individuals should use the labeling format "draft--" followed by the name of the BIP, such as draft-maxwell-coinburning. This format is inspired by pre-WG IETF drafts. Despite this suggestion, it remains unclear why there is a high bar for obtaining a BIP number, especially considering that there is no shortage of available integers. The assignment of numbers is meant to enable organized discussions about all proposals, even those that may not be well-liked. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml b/static/bitcoin-dev/May_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml index 254123f31a..60ea8adc06 100644 --- a/static/bitcoin-dev/May_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml +++ b/static/bitcoin-dev/May_2014/combined_Presenting-a-BIP-for-Shamir-s-Secret-Sharing-of-Bitcoin-private-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys - 2023-08-01T08:17:21.054953+00:00 + 2025-10-11T22:20:22.520837+00:00 + python-feedgen Nikita Schmidt 2014-08-14 19:23:16+00:00 @@ -363,13 +364,13 @@ - python-feedgen + 2 Combined summary - Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys - 2023-08-01T08:17:21.055952+00:00 + 2025-10-11T22:20:22.521102+00:00 - Jan Møller, in an email exchange, expressed his opinion that the current format of the Shared Secret Sharing (SSS) standard is over-engineered. He suggested that only the long format makes sense from a user experience standpoint and proposed that it is only slightly longer than the short version. After no objections were raised, the draft was revised to address this concern.The new version of the SSS standard allows for the shared secret to be encoded in various forms, such as SIPA or BIP38, instead of just a plain private key. This change has several benefits, including not needing to modify the specification for different types of content and encoding metadata together with the secret. The underlying field of the standard was also changed to GF(256), which is more advantageous for dealing with secrets of arbitrary length.To solve the issue of variable length and lack of control over the Base58 prefix, the magic prefix was moved outside of the Base58 encoded content. The application identifier 'SSS-' was introduced, followed by the Base58 encoding of the share. This change may be mildly controversial, and alternatives could be considered.A Java implementation of BIPSS based on a GF2^8 implementation can be found on Github. The use of three encoding formats in the SSS standard is considered over-engineered, with the long format being the only necessary option from a user experience perspective. A fork of Matt's proposal converted to GF(2^8) is also available on Github, which includes changes like allocating only six application/version bytes and using SHA-256 hash functions.The inclusion of a specific flag for testnet in SSS and BIP32 was discussed in email exchanges. It was agreed that such flags are unnecessary since they are not used for sending addresses. The convention so far has been to include a 'version' identifier to identify the purpose of the data, such as network meaning.There was a debate about the importance of testnet in Bitcoin Improvement Proposals (BIPs). Some argued that testnet exists for public testing involving multiple people and services, while others saw it as a tool for certain types of testing. It was noted that testnet is not normally addressed in BIPs, except for soft fork BIPs with compressed deployment schedules on testnet.The serialization of keys when using test chains was discussed, with some expressing that distinguishing serialization of keys is unnecessary. The difference between testnet and mainnet was emphasized as separate from bitcoin vs altcoin, but few altcoins understood this distinction.The issue of encoding the chain in WIF and BIP32 was debated, with some suggesting that it should be ignored as legacy. New BIPs should no longer carry this forward.Discussions also took place regarding the encoding of N-of-M shares. Suggestions were made to encode N-of-M in one byte and to use a bias of -1 for M encoding. Test vectors were updated accordingly.Tamas Blummer expressed his opinion that extra encoding for testnet is not necessary compared to many alt chains. He suggested that BIPs should remain chain agnostic.In an email exchange between Jan Møller and Gregory Maxwell, Møller expressed his concerns about BIP38 and suggested using Shamir's Secret Sharing instead. It is unclear if Møller provided a list of concerns about BIP38 or offered to do so upon request.Tamas Blummer argued that the wide variety of available chains supersedes the notion of main and testnet. He believes that what altcoins do is their own business and outside the scope of a BIP. He also questioned the need for a separate encoding for Bitcoin testnet private keys.Overall, the discussions revolved around simplifying the SSS standard, considering the use cases for testnet and altchains, and debating the encoding of keys and chains in various contexts.The complexity of using the binary extension field of GF(2^8) for secret sharing and data integrity applications was discussed. Some suggested that big-integer operations may be more practical, while others argued that implementing a complex system with many individually testable parts is easier than implementing a single complex part. Gregory Maxwell's implementation of his Bitcoin Improvement Proposal (BIP) is in C++ and uses the GMP library for big-integer arithmetic.There was a debate about the potential risks of obfuscating the parameters of the secret sharing process. Some expressed concerns about users accidentally mixing different types of fragments or distributing too many, which can lead to insecurity or difficulty in restoring their wallets. However, it was acknowledged that attackers may still be able to figure out the information despite the obfuscation.Matt Whitlock proposed an obfuscation method for the secret sharing process but ultimately decided against it based on the consensus of others. Alan Reiner disagreed with this tradeoff, stating that obfuscating something already considered secure at the expense of usability is not beneficial. He argued that it is more important for users to understand what 2014-08-14T19:23:16+00:00 + Jan Møller, in an email exchange, expressed his opinion that the current format of the Shared Secret Sharing (SSS) standard is over-engineered. He suggested that only the long format makes sense from a user experience standpoint and proposed that it is only slightly longer than the short version. After no objections were raised, the draft was revised to address this concern.The new version of the SSS standard allows for the shared secret to be encoded in various forms, such as SIPA or BIP38, instead of just a plain private key. This change has several benefits, including not needing to modify the specification for different types of content and encoding metadata together with the secret. The underlying field of the standard was also changed to GF(256), which is more advantageous for dealing with secrets of arbitrary length.To solve the issue of variable length and lack of control over the Base58 prefix, the magic prefix was moved outside of the Base58 encoded content. The application identifier 'SSS-' was introduced, followed by the Base58 encoding of the share. This change may be mildly controversial, and alternatives could be considered.A Java implementation of BIPSS based on a GF2^8 implementation can be found on Github. The use of three encoding formats in the SSS standard is considered over-engineered, with the long format being the only necessary option from a user experience perspective. A fork of Matt's proposal converted to GF(2^8) is also available on Github, which includes changes like allocating only six application/version bytes and using SHA-256 hash functions.The inclusion of a specific flag for testnet in SSS and BIP32 was discussed in email exchanges. It was agreed that such flags are unnecessary since they are not used for sending addresses. The convention so far has been to include a 'version' identifier to identify the purpose of the data, such as network meaning.There was a debate about the importance of testnet in Bitcoin Improvement Proposals (BIPs). Some argued that testnet exists for public testing involving multiple people and services, while others saw it as a tool for certain types of testing. It was noted that testnet is not normally addressed in BIPs, except for soft fork BIPs with compressed deployment schedules on testnet.The serialization of keys when using test chains was discussed, with some expressing that distinguishing serialization of keys is unnecessary. The difference between testnet and mainnet was emphasized as separate from bitcoin vs altcoin, but few altcoins understood this distinction.The issue of encoding the chain in WIF and BIP32 was debated, with some suggesting that it should be ignored as legacy. New BIPs should no longer carry this forward.Discussions also took place regarding the encoding of N-of-M shares. Suggestions were made to encode N-of-M in one byte and to use a bias of -1 for M encoding. Test vectors were updated accordingly.Tamas Blummer expressed his opinion that extra encoding for testnet is not necessary compared to many alt chains. He suggested that BIPs should remain chain agnostic.In an email exchange between Jan Møller and Gregory Maxwell, Møller expressed his concerns about BIP38 and suggested using Shamir's Secret Sharing instead. It is unclear if Møller provided a list of concerns about BIP38 or offered to do so upon request.Tamas Blummer argued that the wide variety of available chains supersedes the notion of main and testnet. He believes that what altcoins do is their own business and outside the scope of a BIP. He also questioned the need for a separate encoding for Bitcoin testnet private keys.Overall, the discussions revolved around simplifying the SSS standard, considering the use cases for testnet and altchains, and debating the encoding of keys and chains in various contexts.The complexity of using the binary extension field of GF(2^8) for secret sharing and data integrity applications was discussed. Some suggested that big-integer operations may be more practical, while others argued that implementing a complex system with many individually testable parts is easier than implementing a single complex part. Gregory Maxwell's implementation of his Bitcoin Improvement Proposal (BIP) is in C++ and uses the GMP library for big-integer arithmetic.There was a debate about the potential risks of obfuscating the parameters of the secret sharing process. Some expressed concerns about users accidentally mixing different types of fragments or distributing too many, which can lead to insecurity or difficulty in restoring their wallets. However, it was acknowledged that attackers may still be able to figure out the information despite the obfuscation.Matt Whitlock proposed an obfuscation method for the secret sharing process but ultimately decided against it based on the consensus of others. Alan Reiner disagreed with this tradeoff, stating that obfuscating something already considered secure at the expense of usability is not beneficial. He argued that it is more important for users to understand what - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Proposal-for-extra-nonce-in-block-header.xml b/static/bitcoin-dev/May_2014/combined_Proposal-for-extra-nonce-in-block-header.xml index 97f4b25cc5..04b9e48d89 100644 --- a/static/bitcoin-dev/May_2014/combined_Proposal-for-extra-nonce-in-block-header.xml +++ b/static/bitcoin-dev/May_2014/combined_Proposal-for-extra-nonce-in-block-header.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal for extra nonce in block header - 2023-08-01T09:05:29.704021+00:00 + 2025-10-11T22:20:14.020688+00:00 + python-feedgen Timo Hanke 2014-10-18 18:25:59+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Proposal for extra nonce in block header - 2023-08-01T09:05:29.705063+00:00 + 2025-10-11T22:20:14.020859+00:00 - In 2014, Timo Hanke proposed a Bitcoin Improvement Proposal (BIP) to address the issue of miners finding cheap and non-standard ways to generate new work in the Bitcoin protocol. The proposal suggests reassigning two bytes from the version field of the block header to a new extra nonce field. This would allow miners to create new work without altering the transaction tree while protecting the version and timestamp fields in the block header.Currently, the extra nonce is part of the coinbase field of the generation transaction, which is always the first transaction of a block. By incrementing the extra nonce, a miner has to hash the coinbase transaction and recalculate the left-most branch of the merkle tree all the way to the merkle root. However, as the cost of pre-hashing decreases with the advancement of ASIC technology, miners are incentivized to find cheaper ways to create new work.The proposal suggests reducing the range of version numbers from 2^32 to 2^16 and designating the third and fourth bytes of the block header as legitimate space for an extra nonce. This would significantly reduce the incentive for miners to abuse the shortened version number. Additionally, this change would greatly reduce the bandwidth requirements of a blind pool protocol, as only the block header would need to be submitted to the miner.Old versions of the client will still accept blocks with the new extra nonce arrangement but will alert the user to upgrade. There is no need to introduce a new block version number or phase out old block versions. Overall, this proposal aims to provide miners with a cost-effective method of creating new work while maintaining the integrity of the Bitcoin protocol. 2014-10-18T18:25:59+00:00 + In 2014, Timo Hanke proposed a Bitcoin Improvement Proposal (BIP) to address the issue of miners finding cheap and non-standard ways to generate new work in the Bitcoin protocol. The proposal suggests reassigning two bytes from the version field of the block header to a new extra nonce field. This would allow miners to create new work without altering the transaction tree while protecting the version and timestamp fields in the block header.Currently, the extra nonce is part of the coinbase field of the generation transaction, which is always the first transaction of a block. By incrementing the extra nonce, a miner has to hash the coinbase transaction and recalculate the left-most branch of the merkle tree all the way to the merkle root. However, as the cost of pre-hashing decreases with the advancement of ASIC technology, miners are incentivized to find cheaper ways to create new work.The proposal suggests reducing the range of version numbers from 2^32 to 2^16 and designating the third and fourth bytes of the block header as legitimate space for an extra nonce. This would significantly reduce the incentive for miners to abuse the shortened version number. Additionally, this change would greatly reduce the bandwidth requirements of a blind pool protocol, as only the block header would need to be submitted to the miner.Old versions of the client will still accept blocks with the new extra nonce arrangement but will alert the user to upgrade. There is no need to introduce a new block version number or phase out old block versions. Overall, this proposal aims to provide miners with a cost-effective method of creating new work while maintaining the integrity of the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Regtest-Address-Version-Change-Proposal.xml b/static/bitcoin-dev/May_2014/combined_Regtest-Address-Version-Change-Proposal.xml index cc1c927df5..35a569aea9 100644 --- a/static/bitcoin-dev/May_2014/combined_Regtest-Address-Version-Change-Proposal.xml +++ b/static/bitcoin-dev/May_2014/combined_Regtest-Address-Version-Change-Proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Regtest Address Version Change Proposal - 2023-08-01T09:14:48.339716+00:00 + 2025-10-11T22:19:59.092184+00:00 + python-feedgen Mike Hearn 2014-05-13 11:28:44+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Regtest Address Version Change Proposal - 2023-08-01T09:14:48.339716+00:00 + 2025-10-11T22:19:59.092314+00:00 - The discussion focuses on the proposal to change the address versions in -regtest mode to be unique and different from testnet. The suggestion is to modify the regtest pubkey hash addresses to start with either "r" or "R". However, the existing code in bitcore guesses the network based on the address version and changing it would be a significant task. Bitcoinj also supports regtest mode but would also need to be modified. It is important to consider if any existing tools would require modifications to support this change to regtest. Warren Togami Jr. proposed the change and seeks feedback on the impact it may have on existing tools. Additionally, the email mentions automated cross-browser testing and includes a link to the Bitcoin-development mailing list. 2014-05-13T11:28:44+00:00 + The discussion focuses on the proposal to change the address versions in -regtest mode to be unique and different from testnet. The suggestion is to modify the regtest pubkey hash addresses to start with either "r" or "R". However, the existing code in bitcore guesses the network based on the address version and changing it would be a significant task. Bitcoinj also supports regtest mode but would also need to be modified. It is important to consider if any existing tools would require modifications to support this change to regtest. Warren Togami Jr. proposed the change and seeks feedback on the impact it may have on existing tools. Additionally, the email mentions automated cross-browser testing and includes a link to the Bitcoin-development mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Someone-put-a-virus-signature-into-the-blockchain.xml b/static/bitcoin-dev/May_2014/combined_Someone-put-a-virus-signature-into-the-blockchain.xml index e094563ce8..c270d13573 100644 --- a/static/bitcoin-dev/May_2014/combined_Someone-put-a-virus-signature-into-the-blockchain.xml +++ b/static/bitcoin-dev/May_2014/combined_Someone-put-a-virus-signature-into-the-blockchain.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Someone put a virus signature into the blockchain - 2023-08-01T09:17:11.593119+00:00 + 2025-10-11T22:19:46.331619+00:00 + python-feedgen Christophe Biocca 2014-05-16 15:19:37+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Someone put a virus signature into the blockchain - 2023-08-01T09:17:11.593119+00:00 + 2025-10-11T22:19:46.331764+00:00 - On May 16, 2014, a Reddit user named David posted a thread in the Bitcoin subreddit, informing the community about a virus signature that had been discovered in the Bitcoin blockchain. Concerned about the potential security risks associated with this finding, David wanted to ensure that the developers were aware of the situation.David's post did not provide any specific details about the virus or how it ended up in the blockchain. However, the mere presence of a virus signature in the blockchain raised concerns among users and developers alike. This incident highlights the importance of remaining vigilant and taking steps to protect digital assets when dealing with cryptocurrencies like Bitcoin.In response to David's Reddit post, another individual named David Shares shared his findings on the Bitcoin developers' mailing list. He included a link to a relevant Github issue, drawing attention to the potential virus signature if it had not already been seen by the group. While the email also contained an advertisement for cross-browser testing, the main focus was on addressing the possible virus signature.The discovery of a virus signature in the Bitcoin blockchain serves as a reminder for everyone involved in cryptocurrency to exercise caution and stay informed about any security issues or updates. By staying vigilant and taking necessary precautions, developers and users can better protect their digital assets from potential threats. 2014-05-16T15:19:37+00:00 + On May 16, 2014, a Reddit user named David posted a thread in the Bitcoin subreddit, informing the community about a virus signature that had been discovered in the Bitcoin blockchain. Concerned about the potential security risks associated with this finding, David wanted to ensure that the developers were aware of the situation.David's post did not provide any specific details about the virus or how it ended up in the blockchain. However, the mere presence of a virus signature in the blockchain raised concerns among users and developers alike. This incident highlights the importance of remaining vigilant and taking steps to protect digital assets when dealing with cryptocurrencies like Bitcoin.In response to David's Reddit post, another individual named David Shares shared his findings on the Bitcoin developers' mailing list. He included a link to a relevant Github issue, drawing attention to the potential virus signature if it had not already been seen by the group. While the email also contained an advertisement for cross-browser testing, the main focus was on addressing the possible virus signature.The discovery of a virus signature in the Bitcoin blockchain serves as a reminder for everyone involved in cryptocurrency to exercise caution and stay informed about any security issues or updates. By staying vigilant and taking necessary precautions, developers and users can better protect their digital assets from potential threats. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Translators-Needed-for-Bitcoin-Core.xml b/static/bitcoin-dev/May_2014/combined_Translators-Needed-for-Bitcoin-Core.xml index d25b2301da..5dabcbc8b3 100644 --- a/static/bitcoin-dev/May_2014/combined_Translators-Needed-for-Bitcoin-Core.xml +++ b/static/bitcoin-dev/May_2014/combined_Translators-Needed-for-Bitcoin-Core.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Translators Needed for Bitcoin Core - 2023-08-01T08:57:32.656260+00:00 + 2025-10-11T22:20:24.647168+00:00 + python-feedgen Warren Togami Jr. 2014-05-11 06:32:18+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Translators Needed for Bitcoin Core - 2023-08-01T08:57:32.656260+00:00 + 2025-10-11T22:20:24.647301+00:00 - The Bitcoin project is looking for volunteers to help improve translations in multiple languages for the upcoming release of Bitcoin Core 0.9.2. Native non-English speakers are encouraged to join Transifex, a platform for collaborative translation, to clean up and refine the translations. These translations will not only be used for Bitcoin, but also for Litecoin. Volunteers can try out the nightly builds of Bitcoin Core as it progresses towards the 0.9.2 release, although it is advised not to use these builds for their production wallet. Additionally, volunteers should join the Translator mailing list to stay updated on when translations are needed for Bitcoin. They will also receive notifications if other Bitcoin Project materials in Transifex require translations, such as bitcoin.org.Even individuals who do not speak other languages can still contribute by directing others who are fluent in different languages to the translation page. This way, they can help ensure that the translations are accurate and comprehensive. The feature freeze for Bitcoin Core 0.9.2 is set for May 13th, 2014, so now is the perfect time for interested volunteers to get involved and make a difference in improving the language support for Bitcoin and Litecoin. 2014-05-11T06:32:18+00:00 + The Bitcoin project is looking for volunteers to help improve translations in multiple languages for the upcoming release of Bitcoin Core 0.9.2. Native non-English speakers are encouraged to join Transifex, a platform for collaborative translation, to clean up and refine the translations. These translations will not only be used for Bitcoin, but also for Litecoin. Volunteers can try out the nightly builds of Bitcoin Core as it progresses towards the 0.9.2 release, although it is advised not to use these builds for their production wallet. Additionally, volunteers should join the Translator mailing list to stay updated on when translations are needed for Bitcoin. They will also receive notifications if other Bitcoin Project materials in Transifex require translations, such as bitcoin.org.Even individuals who do not speak other languages can still contribute by directing others who are fluent in different languages to the translation page. This way, they can help ensure that the translations are accurate and comprehensive. The feature freeze for Bitcoin Core 0.9.2 is set for May 13th, 2014, so now is the perfect time for interested volunteers to get involved and make a difference in improving the language support for Bitcoin and Litecoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Why-are-we-bleeding-nodes-.xml b/static/bitcoin-dev/May_2014/combined_Why-are-we-bleeding-nodes-.xml index 288823996e..f18be6ffe4 100644 --- a/static/bitcoin-dev/May_2014/combined_Why-are-we-bleeding-nodes-.xml +++ b/static/bitcoin-dev/May_2014/combined_Why-are-we-bleeding-nodes-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why are we bleeding nodes? - 2023-08-01T08:36:54.156883+00:00 + 2025-10-11T22:19:29.322775+00:00 + python-feedgen Jeff Garzik 2014-05-20 20:22:27+00:00 @@ -283,13 +284,13 @@ - python-feedgen + 2 Combined summary - Why are we bleeding nodes? - 2023-08-01T08:36:54.158932+00:00 + 2025-10-11T22:19:29.323018+00:00 - The discussion revolved around the possibility of extending the Bitcoin protocol to support UDP transport. This would enable NAT traversal and allow more people to run effective nodes. Jeff Garzik, a Bitcoin core developer, had already spec'd out the UDP traversal of the P2P protocol and deemed it reasonable. Andy Alness, a software engineer at Coinbase, suggested reinventing TCP over UDP to handle blocks and large transactions. There was also discussion about the potential for a blockchain fork due to network split and how mining interests in China would make arrangements to circumvent the Great Firewall of China.In May 2014, China updated its firewall blocking Bitcoin sites and pools, leading to concerns about a possible blockchain fork. The discussion also covered the resource requirements and associated costs of running a full node for Bitcoin. Some users reported high bandwidth usage and costs, while others argued that the requirements were within the capabilities of casual users. There was also a discussion about simplifying Bitcoin wallets and making them more user-friendly, as well as improving block fetching capabilities for better performance.The email conversations and forum discussions highlighted various aspects of the Bitcoin network, including UDP transport, NAT traversal, blockchain forks, mining interests in China, resource requirements of running a node, wallet usability, multi-sig security, and block fetching capabilities. There were also suggestions to advertise node capabilities in a more fine-grained manner using service bits. Tamas Blummer expressed concerns about extreme load hot-spotting and resource usage caused by a binary archive bit for an archive node. He proposed extending the addr messages to indicate a range of blocks served and returning a bitmap of pruned/full blocks.The discussions also focused on the challenges of running a full node for Bitcoin, including the resource requirements of bandwidth and disk space. Implementations such as headers-first and chain pruning were suggested to reduce the load and storage consumption. Concerns were raised about the decreasing number of Bitcoin nodes and suggestions were made to gather data on why people were ceasing to run nodes. The importance of improving the user experience of running Bitcoin was emphasized, as well as the potential risks associated with third-party services. Overall, the discussions demonstrated ongoing efforts to address the scalability and usability challenges of the Bitcoin network. 2014-05-20T20:22:27+00:00 + The discussion revolved around the possibility of extending the Bitcoin protocol to support UDP transport. This would enable NAT traversal and allow more people to run effective nodes. Jeff Garzik, a Bitcoin core developer, had already spec'd out the UDP traversal of the P2P protocol and deemed it reasonable. Andy Alness, a software engineer at Coinbase, suggested reinventing TCP over UDP to handle blocks and large transactions. There was also discussion about the potential for a blockchain fork due to network split and how mining interests in China would make arrangements to circumvent the Great Firewall of China.In May 2014, China updated its firewall blocking Bitcoin sites and pools, leading to concerns about a possible blockchain fork. The discussion also covered the resource requirements and associated costs of running a full node for Bitcoin. Some users reported high bandwidth usage and costs, while others argued that the requirements were within the capabilities of casual users. There was also a discussion about simplifying Bitcoin wallets and making them more user-friendly, as well as improving block fetching capabilities for better performance.The email conversations and forum discussions highlighted various aspects of the Bitcoin network, including UDP transport, NAT traversal, blockchain forks, mining interests in China, resource requirements of running a node, wallet usability, multi-sig security, and block fetching capabilities. There were also suggestions to advertise node capabilities in a more fine-grained manner using service bits. Tamas Blummer expressed concerns about extreme load hot-spotting and resource usage caused by a binary archive bit for an archive node. He proposed extending the addr messages to indicate a range of blocks served and returning a bitmap of pruned/full blocks.The discussions also focused on the challenges of running a full node for Bitcoin, including the resource requirements of bandwidth and disk space. Implementations such as headers-first and chain pruning were suggested to reduce the load and storage consumption. Concerns were raised about the decreasing number of Bitcoin nodes and suggestions were made to gather data on why people were ceasing to run nodes. The importance of improving the user experience of running Bitcoin was emphasized, as well as the potential risks associated with third-party services. Overall, the discussions demonstrated ongoing efforts to address the scalability and usability challenges of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_Working-on-social-contracts-was-Paper-Currency-.xml b/static/bitcoin-dev/May_2014/combined_Working-on-social-contracts-was-Paper-Currency-.xml index c315f4466d..665cf6e49c 100644 --- a/static/bitcoin-dev/May_2014/combined_Working-on-social-contracts-was-Paper-Currency-.xml +++ b/static/bitcoin-dev/May_2014/combined_Working-on-social-contracts-was-Paper-Currency-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Working on social contracts (was: Paper Currency) - 2023-08-01T09:21:31.226049+00:00 + 2025-10-11T22:19:42.085856+00:00 + python-feedgen Justus Ranvier 2014-05-19 21:18:54+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Working on social contracts (was: Paper Currency) - 2023-08-01T09:21:31.226049+00:00 + 2025-10-11T22:19:42.086009+00:00 - Gregory Maxwell discusses the limitations of social contracts in cases involving coercion and violence. He argues that even if developers publicly promise to resist coercion, they may not be able to follow through when faced with life-threatening situations. Maxwell suggests that warrant canaries, which signal the absence of secret government subpoenas, are more effective than social contracts. While social contracts make it harder for attackers to conceal their activities, they cannot prevent attacks. Maxwell emphasizes that social contracts are valuable but not a cure-all solution.Justus Ranvier argues against personal promises in Bitcoin development, stating that people change and can be coerced. He advocates for building robust social and technical infrastructure to prevent failures and attacks. Justus believes in a trustless system governed by free will and understanding. Despite potential mistrust, he sees constant scrutiny as an opportunity to improve technology and security. He calls for respectful communication without personal attacks to uncover actual attacks.Mike Hearn responds to someone causing problems on a development list who suggested that certain ideas were too dangerous to discuss. He disagrees, calling such thinking outdated and medieval. He proposes creating a parallel forum where people can freely express their thoughts without fear of judgment or censorship. However, he criticizes vicious attacks on the forum, which hinder productive discussion. He suggests that those causing problems should unsubscribe to restore a positive environment for potential developers.Gavin Andresen promises to never endorse or work on changes to the Bitcoin system that would allow for confiscation, blacklisting, or devaluation of anyone's Bitcoin. He rejects requests to write an RFC regarding possible changes, citing other priorities. He encourages others to write the RFC themselves.In response to confusion over their authority to write a social contract for Bitcoin, Gavin Andresen questions why he and Mike Hearn would have that responsibility. The author of the email asserts that anyone can make promises about their future behavior, including developers like Andresen and Hearn. The community can track developers' promises about implementing or not implementing changes in Bitcoin to make informed decisions about software support.Justus Ranvier suggests a Bitcoin social contract to Gavin Andresen, specifying features that will never be added or removed from Bitcoin. Andresen questions their authority to write such a contract but acknowledges his ability to enforce a social contract against trolling or flaming on the mailing list. He expresses a desire to delegate this authority, preferably to a software algorithm that can automatically censor unproductive discussions or contributors. He reminds the group to change the subject line when topics wander. 2014-05-19T21:18:54+00:00 + Gregory Maxwell discusses the limitations of social contracts in cases involving coercion and violence. He argues that even if developers publicly promise to resist coercion, they may not be able to follow through when faced with life-threatening situations. Maxwell suggests that warrant canaries, which signal the absence of secret government subpoenas, are more effective than social contracts. While social contracts make it harder for attackers to conceal their activities, they cannot prevent attacks. Maxwell emphasizes that social contracts are valuable but not a cure-all solution.Justus Ranvier argues against personal promises in Bitcoin development, stating that people change and can be coerced. He advocates for building robust social and technical infrastructure to prevent failures and attacks. Justus believes in a trustless system governed by free will and understanding. Despite potential mistrust, he sees constant scrutiny as an opportunity to improve technology and security. He calls for respectful communication without personal attacks to uncover actual attacks.Mike Hearn responds to someone causing problems on a development list who suggested that certain ideas were too dangerous to discuss. He disagrees, calling such thinking outdated and medieval. He proposes creating a parallel forum where people can freely express their thoughts without fear of judgment or censorship. However, he criticizes vicious attacks on the forum, which hinder productive discussion. He suggests that those causing problems should unsubscribe to restore a positive environment for potential developers.Gavin Andresen promises to never endorse or work on changes to the Bitcoin system that would allow for confiscation, blacklisting, or devaluation of anyone's Bitcoin. He rejects requests to write an RFC regarding possible changes, citing other priorities. He encourages others to write the RFC themselves.In response to confusion over their authority to write a social contract for Bitcoin, Gavin Andresen questions why he and Mike Hearn would have that responsibility. The author of the email asserts that anyone can make promises about their future behavior, including developers like Andresen and Hearn. The community can track developers' promises about implementing or not implementing changes in Bitcoin to make informed decisions about software support.Justus Ranvier suggests a Bitcoin social contract to Gavin Andresen, specifying features that will never be added or removed from Bitcoin. Andresen questions their authority to write such a contract but acknowledges his ability to enforce a social contract against trolling or flaming on the mailing list. He expresses a desire to delegate this authority, preferably to a software algorithm that can automatically censor unproductive discussions or contributors. He reminds the group to change the subject line when topics wander. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_bitcoind-minor-bug-in-wallet-and-possible-fix.xml b/static/bitcoin-dev/May_2014/combined_bitcoind-minor-bug-in-wallet-and-possible-fix.xml index cd6e0a0325..0e8ed5f368 100644 --- a/static/bitcoin-dev/May_2014/combined_bitcoind-minor-bug-in-wallet-and-possible-fix.xml +++ b/static/bitcoin-dev/May_2014/combined_bitcoind-minor-bug-in-wallet-and-possible-fix.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoind minor bug in wallet and possible fix - 2023-08-01T09:24:28.937389+00:00 + 2025-10-11T22:19:44.209106+00:00 + python-feedgen Toshi Morita 2014-05-30 00:10:36+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - bitcoind minor bug in wallet and possible fix - 2023-08-01T09:24:28.937389+00:00 + 2025-10-11T22:19:44.209230+00:00 - On May 29, 2014, Toshi Morita reported a bug in the Bitcoin-development mailing list. The bug was found while running `bitcoind` under `valgrind` and was caused by an uninitialized variable in the CWallet class. Specifically, the bug occurred because the variable `nTimeFirstKey` was not initialized when the wallet was instantiated.Toshi provided a fix for the issue in his fork of the code and included the necessary code changes in his email. He suggested submitting a pull request on GitHub from his repository with the username "tm314159" if the fix is acceptable. This would allow the fix to be merged quickly into the main codebase.In addition to reporting the bug and providing a fix, Toshi also included an advertisement for Restlet, a web API service, in his email.Further analysis of the bug revealed that the error message indicated a conditional jump or move depends on uninitialised value(s) in the CWallet::LoadKeyMetadata function. The bug was identified using Valgrind-3.8.1 and LibVEX, and the specific line of code where the error occurs is line 63 in the wallet.cpp file.To fix the bug, it is recommended to either initialize the variable `nTimeFirstKey` or ensure that it is given a value before it is used in the code. By doing so, the uninitialized variable bug can be resolved. 2014-05-30T00:10:36+00:00 + On May 29, 2014, Toshi Morita reported a bug in the Bitcoin-development mailing list. The bug was found while running `bitcoind` under `valgrind` and was caused by an uninitialized variable in the CWallet class. Specifically, the bug occurred because the variable `nTimeFirstKey` was not initialized when the wallet was instantiated.Toshi provided a fix for the issue in his fork of the code and included the necessary code changes in his email. He suggested submitting a pull request on GitHub from his repository with the username "tm314159" if the fix is acceptable. This would allow the fix to be merged quickly into the main codebase.In addition to reporting the bug and providing a fix, Toshi also included an advertisement for Restlet, a web API service, in his email.Further analysis of the bug revealed that the error message indicated a conditional jump or move depends on uninitialised value(s) in the CWallet::LoadKeyMetadata function. The bug was identified using Valgrind-3.8.1 and LibVEX, and the specific line of code where the error occurs is line 63 in the wallet.cpp file.To fix the bug, it is recommended to either initialize the variable `nTimeFirstKey` or ensure that it is given a value before it is used in the code. By doing so, the uninitialized variable bug can be resolved. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_moving-the-default-display-to-mbtc.xml b/static/bitcoin-dev/May_2014/combined_moving-the-default-display-to-mbtc.xml index 7075f030de..3877db17b2 100644 --- a/static/bitcoin-dev/May_2014/combined_moving-the-default-display-to-mbtc.xml +++ b/static/bitcoin-dev/May_2014/combined_moving-the-default-display-to-mbtc.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - moving the default display to mbtc - 2023-08-01T06:36:29.548885+00:00 + 2025-10-11T22:19:52.709523+00:00 + python-feedgen Jannis Froese 2014-05-03 18:46:37+00:00 @@ -451,13 +452,13 @@ - python-feedgen + 2 Combined summary - moving the default display to mbtc - 2023-08-01T06:36:29.551884+00:00 + 2025-10-11T22:19:52.709851+00:00 - The ongoing debate in the Bitcoin community revolves around the unit of measurement for Bitcoin transactions. Andreas Schildbach argues that users prioritize the amount in their local currency, while Tamas Blummer suggests denominations similar to traditional currencies. Jeff Garzik proposes uBTC as a user-friendly option, and MultiBit HD offers customizable configuration options. The conversation highlights the complexity of determining the best unit of measurement for Bitcoin.There are suggestions to use symbols like XUB or uBTC as the naming convention for microbitcoins. It is emphasized that changes should not be made without user permission and that the system should take care of users who make mistakes when entering values. Additionally, the discussion highlights the need for a standardized format that empowers users to use all available decimal places and suggests the use of official test cases for wallet software to ensure desired behavior.The discussion also touches on the perception of Bitcoin prices in different currencies. Schildbach argues that users are not confused by the use of mBTC as a unit of measurement, while Blummer suggests that Bitcoin would be more widely accepted if it had prices and fractions like other currencies. The debate continues with Garzik expressing disappointment over the switch to mBTC and suggesting uBTC as a more user-friendly option.In November 2013, the Bitcoin community engaged in discussions regarding the unit of measurement for Bitcoin transactions. The main proposal was to switch from mBTC (millibitcoin) to uBTC (microbitcoin) as the standard unit. Advocates of uBTC argued that it would be more intuitive for users, as two decimal places are becoming standard for new national currencies. They believed that using uBTC would bring Bitcoin closer to everyday human scale numbers. However, there were concerns about confusion and potential mistakes leading to lost coins, as well as the perception of uBTC being less valuable.Alan Reiner expressed concerns about changing the base unit of an established system, stating that it could cause more problems than it's worth. Mark Friedenbach supported skipping mBTC and moving straight to uBTC, emphasizing the need for user-friendliness. He suggested switching currency symbols to XBT or NBC (New Bitcoin) to alleviate confusion. The discussion also touched on other issues, such as displaying fees and trading rates in BTC or MBTC, addressing terminology fix-ups, and the use of confirmations and addresses. The goal was to promote consistency and clarity in Bitcoin transactions.The rise in the value of Bitcoin raised concerns among new users who found the high price intimidating. A straw poll conducted previously showed that a majority of respondents favored switching to a system allowing for fractional amounts of Bitcoin to be purchased. Satoshi's comments indicated that while there are only 21 million coins available, there are six decimal places internally, allowing for a total of eight decimal places. It was suggested to change the default display in software to mbtc, with a dropdown display option initially and eventually becoming the default. This change aimed to make working with small numbers less tiresome and more user-friendly.Overall, the discussions focused on optimizing the user experience in Bitcoin transactions by considering the unit of measurement, currency symbols, fee displays, and terminology fixes. The community aimed to address concerns and promote clarity while ensuring a smooth transition for users. The MultiBit HD wallet offered customizable options for icons and symbols, following NIST guidelines for SI unit symbol representation. However, there was disappointment expressed by Jeff Garzik when Bitcoin Wallet moved to mBTC instead of uBTC. He believed that the consensus was for uBTC and another decimal place transition would cause confusion.Wladimir, on the other hand, responded that getting people to care about this issue was difficult and couldn't blame Andreas for making the change to mBTC since it seemed to be catching on in the community. The conversation also touched upon the issue of terminology for Bitcoin addresses. Mark Friedenbach proposed changing the term "address" to "key id" to avoid misleading associations with physical addresses or accounts. Other suggestions included using "invoice id" or "payment address" instead of "address" to avoid confusion with email addresses.The discussion also addressed the standardization of Bitcoin units and terminology. Alex Kravets suggested Bitcoin currency code standardization, proposing the use of XBT as the currency code and defining one bit as 100 satoshis. Eugen Leitl opposed this idea and suggested using SI prefixes instead. Alan Reiner supported the XBT idea but disagreed with the term "micro bitcoins", suggesting alternatives like "bits" or "microbits". The goal was to find a standardized way to represent Bitcoin units to avoid confusion among users.Usability issues in Bitcoin transactions were also discussed, particularly the difficulty of dealing with small amounts and the learning curve of Bitcoin. Suggestions were made to simplify bitcoin transactions by displaying fees and trading rates in BTC or MBTC instead of fractions of bitcoins. The community aimed to find consensus on a path forward to avoid fragmentation and confusion in the market.In conclusion, the discussions among Bitcoin developers 2014-05-03T18:46:37+00:00 + The ongoing debate in the Bitcoin community revolves around the unit of measurement for Bitcoin transactions. Andreas Schildbach argues that users prioritize the amount in their local currency, while Tamas Blummer suggests denominations similar to traditional currencies. Jeff Garzik proposes uBTC as a user-friendly option, and MultiBit HD offers customizable configuration options. The conversation highlights the complexity of determining the best unit of measurement for Bitcoin.There are suggestions to use symbols like XUB or uBTC as the naming convention for microbitcoins. It is emphasized that changes should not be made without user permission and that the system should take care of users who make mistakes when entering values. Additionally, the discussion highlights the need for a standardized format that empowers users to use all available decimal places and suggests the use of official test cases for wallet software to ensure desired behavior.The discussion also touches on the perception of Bitcoin prices in different currencies. Schildbach argues that users are not confused by the use of mBTC as a unit of measurement, while Blummer suggests that Bitcoin would be more widely accepted if it had prices and fractions like other currencies. The debate continues with Garzik expressing disappointment over the switch to mBTC and suggesting uBTC as a more user-friendly option.In November 2013, the Bitcoin community engaged in discussions regarding the unit of measurement for Bitcoin transactions. The main proposal was to switch from mBTC (millibitcoin) to uBTC (microbitcoin) as the standard unit. Advocates of uBTC argued that it would be more intuitive for users, as two decimal places are becoming standard for new national currencies. They believed that using uBTC would bring Bitcoin closer to everyday human scale numbers. However, there were concerns about confusion and potential mistakes leading to lost coins, as well as the perception of uBTC being less valuable.Alan Reiner expressed concerns about changing the base unit of an established system, stating that it could cause more problems than it's worth. Mark Friedenbach supported skipping mBTC and moving straight to uBTC, emphasizing the need for user-friendliness. He suggested switching currency symbols to XBT or NBC (New Bitcoin) to alleviate confusion. The discussion also touched on other issues, such as displaying fees and trading rates in BTC or MBTC, addressing terminology fix-ups, and the use of confirmations and addresses. The goal was to promote consistency and clarity in Bitcoin transactions.The rise in the value of Bitcoin raised concerns among new users who found the high price intimidating. A straw poll conducted previously showed that a majority of respondents favored switching to a system allowing for fractional amounts of Bitcoin to be purchased. Satoshi's comments indicated that while there are only 21 million coins available, there are six decimal places internally, allowing for a total of eight decimal places. It was suggested to change the default display in software to mbtc, with a dropdown display option initially and eventually becoming the default. This change aimed to make working with small numbers less tiresome and more user-friendly.Overall, the discussions focused on optimizing the user experience in Bitcoin transactions by considering the unit of measurement, currency symbols, fee displays, and terminology fixes. The community aimed to address concerns and promote clarity while ensuring a smooth transition for users. The MultiBit HD wallet offered customizable options for icons and symbols, following NIST guidelines for SI unit symbol representation. However, there was disappointment expressed by Jeff Garzik when Bitcoin Wallet moved to mBTC instead of uBTC. He believed that the consensus was for uBTC and another decimal place transition would cause confusion.Wladimir, on the other hand, responded that getting people to care about this issue was difficult and couldn't blame Andreas for making the change to mBTC since it seemed to be catching on in the community. The conversation also touched upon the issue of terminology for Bitcoin addresses. Mark Friedenbach proposed changing the term "address" to "key id" to avoid misleading associations with physical addresses or accounts. Other suggestions included using "invoice id" or "payment address" instead of "address" to avoid confusion with email addresses.The discussion also addressed the standardization of Bitcoin units and terminology. Alex Kravets suggested Bitcoin currency code standardization, proposing the use of XBT as the currency code and defining one bit as 100 satoshis. Eugen Leitl opposed this idea and suggested using SI prefixes instead. Alan Reiner supported the XBT idea but disagreed with the term "micro bitcoins", suggesting alternatives like "bits" or "microbits". The goal was to find a standardized way to represent Bitcoin units to avoid confusion among users.Usability issues in Bitcoin transactions were also discussed, particularly the difficulty of dealing with small amounts and the learning curve of Bitcoin. Suggestions were made to simplify bitcoin transactions by displaying fees and trading rates in BTC or MBTC instead of fractions of bitcoins. The community aimed to find consensus on a path forward to avoid fragmentation and confusion in the market.In conclusion, the discussions among Bitcoin developers - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_patents-.xml b/static/bitcoin-dev/May_2014/combined_patents-.xml index 1af16add2d..3194aedd03 100644 --- a/static/bitcoin-dev/May_2014/combined_patents-.xml +++ b/static/bitcoin-dev/May_2014/combined_patents-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - patents... - 2023-08-01T09:21:07.341266+00:00 + 2025-10-11T22:19:54.834806+00:00 + python-feedgen Jeff Garzik 2014-05-20 10:30:37+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - patents... - 2023-08-01T09:21:07.341266+00:00 + 2025-10-11T22:19:54.834975+00:00 - In May 2014, a discussion was initiated by Adam Back on the bitcoin-dev mailing list regarding non-development related topics. He expressed concern about the lack of a convenient mailing list format for such discussions and suggested that web forums were not ideal. Jeff Garzik informed the group about a little-used "bitcoin-list" on SourceForge that could be used for general discussions. Garzik proposed new rules for the list, including being respectful and only allowing topics related to decentralization, consensus, proven data structures, or crypto.In an email conversation, Mike Hearn mentioned that most companies have banned their staff from reading patents. However, the application of patent protocols to Bitcoin is seen as different from Google. While Google can survive single or triple damages from patent violations, Bitcoin has a narrower scope. Even a single patent infringement resulting in commercial death needs attention. The right approach for Bitcoin regarding patents is not straightforward, as it involves money and potential legal consequences. A transcript link was provided for more details.Avoiding patent infringement no longer requires paying a patent attorney for a freedom to operate review. However, reading patents may not always be productive. If a company learns that it violates a patent but continues doing business, it becomes a willful violator. Despite this, it is argued that reading patents never makes sense as there is only potential for loss.In a 2014 email exchange, Gregory Maxwell discussed the potential benefits of filing for a patent as a defensive approach. By filing for a patent, the work is entered into the USPTO database, which examiners consult during prior art searches. While they may also search the internet and other resources, consulting existing patents and applications is guaranteed. The idea of letting the patent application lapse as a viable strategy was raised but not addressed.In the same email exchange, Mike Hearn advised against looking for patents due to US law that triples damages for knowingly infringing. However, this advice is outdated as the precedent was overturned. Reading patents may not always be productive, but filing a patent can ensure that the work is included in the USPTO database, potentially preventing others from patenting the same material later. Patents can also be used defensively in licensing negotiations or to secure a place at the negotiating table with someone who holds relevant patents.The discussion also touches on the impact of patents on Bitcoin. One person suggests that discussing patents only within the Bitcoin community limits the ability to educate people about their negative aspects. They propose finding examples outside of Bitcoin to discuss the patent system more broadly. However, another person argues that keeping patent discussions off mailing lists is appropriate and wise, suggesting discussing Bitcoin-relevant patents elsewhere. The former person disagrees, stating that such discussions are common in tech news.The email addresses the first rule of patents, which advises against actively searching for them due to US law tripling damages for knowingly infringing. Many companies have banned their staff from reading patents to avoid legal issues. The author argues against keeping patent discussions off mailing lists, especially when tech news is full of such discussions.The author provides a crash course on patents, emphasizing the first rule of not actively seeking them. This is because US law imposes triple damages for knowingly infringing on a patent. Companies have prohibited their staff from reading patents to avoid legal complications. The author urges against patenting any Bitcoin-related research, highlighting that defensive patenting is ineffective and fighting back against a patent is not a viable strategy. Instead, new ideas should be put into the public domain. Additionally, suing people using Bitcoin based on patents will not gain any support.The writer questions the need for patents in the bitcoin industry and suggests that companies consider placing their patents into a Linux Foundation defensive pool. They caution against the dangers of individual or company-held patents, citing an example of digicash patents causing innovation delays after the company went bankrupt. The patents were sold to a large company, preventing others from using them until they expired. The writer concludes by stating the non-dev related nature of the topic and the lack of a convenient mailing list format for such discussions. 2014-05-20T10:30:37+00:00 + In May 2014, a discussion was initiated by Adam Back on the bitcoin-dev mailing list regarding non-development related topics. He expressed concern about the lack of a convenient mailing list format for such discussions and suggested that web forums were not ideal. Jeff Garzik informed the group about a little-used "bitcoin-list" on SourceForge that could be used for general discussions. Garzik proposed new rules for the list, including being respectful and only allowing topics related to decentralization, consensus, proven data structures, or crypto.In an email conversation, Mike Hearn mentioned that most companies have banned their staff from reading patents. However, the application of patent protocols to Bitcoin is seen as different from Google. While Google can survive single or triple damages from patent violations, Bitcoin has a narrower scope. Even a single patent infringement resulting in commercial death needs attention. The right approach for Bitcoin regarding patents is not straightforward, as it involves money and potential legal consequences. A transcript link was provided for more details.Avoiding patent infringement no longer requires paying a patent attorney for a freedom to operate review. However, reading patents may not always be productive. If a company learns that it violates a patent but continues doing business, it becomes a willful violator. Despite this, it is argued that reading patents never makes sense as there is only potential for loss.In a 2014 email exchange, Gregory Maxwell discussed the potential benefits of filing for a patent as a defensive approach. By filing for a patent, the work is entered into the USPTO database, which examiners consult during prior art searches. While they may also search the internet and other resources, consulting existing patents and applications is guaranteed. The idea of letting the patent application lapse as a viable strategy was raised but not addressed.In the same email exchange, Mike Hearn advised against looking for patents due to US law that triples damages for knowingly infringing. However, this advice is outdated as the precedent was overturned. Reading patents may not always be productive, but filing a patent can ensure that the work is included in the USPTO database, potentially preventing others from patenting the same material later. Patents can also be used defensively in licensing negotiations or to secure a place at the negotiating table with someone who holds relevant patents.The discussion also touches on the impact of patents on Bitcoin. One person suggests that discussing patents only within the Bitcoin community limits the ability to educate people about their negative aspects. They propose finding examples outside of Bitcoin to discuss the patent system more broadly. However, another person argues that keeping patent discussions off mailing lists is appropriate and wise, suggesting discussing Bitcoin-relevant patents elsewhere. The former person disagrees, stating that such discussions are common in tech news.The email addresses the first rule of patents, which advises against actively searching for them due to US law tripling damages for knowingly infringing. Many companies have banned their staff from reading patents to avoid legal issues. The author argues against keeping patent discussions off mailing lists, especially when tech news is full of such discussions.The author provides a crash course on patents, emphasizing the first rule of not actively seeking them. This is because US law imposes triple damages for knowingly infringing on a patent. Companies have prohibited their staff from reading patents to avoid legal complications. The author urges against patenting any Bitcoin-related research, highlighting that defensive patenting is ineffective and fighting back against a patent is not a viable strategy. Instead, new ideas should be put into the public domain. Additionally, suing people using Bitcoin based on patents will not gain any support.The writer questions the need for patents in the bitcoin industry and suggests that companies consider placing their patents into a Linux Foundation defensive pool. They caution against the dangers of individual or company-held patents, citing an example of digicash patents causing innovation delays after the company went bankrupt. The patents were sold to a large company, preventing others from using them until they expired. The writer concludes by stating the non-dev related nature of the topic and the lack of a convenient mailing list format for such discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_statoshi-info-is-now-live.xml b/static/bitcoin-dev/May_2014/combined_statoshi-info-is-now-live.xml index 7746f00d7a..87afe739f9 100644 --- a/static/bitcoin-dev/May_2014/combined_statoshi-info-is-now-live.xml +++ b/static/bitcoin-dev/May_2014/combined_statoshi-info-is-now-live.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - statoshi.info is now live - 2023-08-01T09:13:51.553596+00:00 + 2025-10-11T22:19:18.702734+00:00 + python-feedgen Pieter Wuille 2014-05-14 13:10:52+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - statoshi.info is now live - 2023-08-01T09:13:51.553596+00:00 + 2025-10-11T22:19:18.702934+00:00 - In an email conversation on May 14, 2014 at 1:42 PM, Jameson Lopp thanked someone for suggesting metrics to collect and acknowledged that tracking per-peer pings is a different type of metric than what he's currently collecting. He mentioned that he had noted the lack of pong messages in a post he made a few weeks ago on coinchomp.com and provided a link to it. The email also included a pull request #2784.A post made by Jameson Lopp on coinchomp.com notes a lack of pong messages. He adds that tracking per-peer pings is a different type of metric than what he's currently collecting. He says that adding metrics for sent messages validated his theory: his node has never sent a single ping request to a peer and thus has never received a pong message. He also says that he can't even add sent pings or received pongs to the chart because they don't exist in his graphite instance.Josh Lehan, in an email to Jameson Lopp, suggests adding the ping time from one node to other peers. However, he says that it would be a challenge to fit that information into the current design as the graphs seem to be comprised of overall statistics for this node, not per-peer statistics that can vary between peers (such as ping time). He suggests sending the "ping" RPC command on a regular schedule to ensure the graph is updated with new information. He also notes that there is currently no support for overlapping pings.Wladimir comments on the graphs, saying that in the 'connected peers' chart, some larger quantities are visualized. This makes the smaller ones invisible due to scale. He suggests adding other stats such as the number of connected peers that are SPV clients or full nodes, current block height, number of transactions in mempool, number of transactions in UTXO set, maybe some fee statistics, and number of orphan blocks/orphan transactions.This all stems from Jameson Lopp setting up a public Statoshi instance and throwing a nicer interface on top of it.Jameson Lopp created a public Statoshi instance with a better interface than an integrated stats/monitoring feature. Wladimir, while appreciating the graphs in the 'connected peers' chart, suggested adding some random stats such as the number of connected peers that are SPV clients or full nodes (NODE_NETWORK), current block height, the number of transactions in mempool and UTXO set, fee statistics, number of orphan blocks/orphan transactions. Josh Lehan brainstormed the idea of adding the ping time from one node to other peers, however, fitting it into the current design would be a challenge since the graphs seem to be comprised of overall statistics for this node and not per-peer statistics that can vary between peers. There is currently no support for overlapping pings, and something would have to send the "ping" RPC command regularly to ensure the graph is updated with new information.In an email conversation between Jameson Lopp and Wladimir, they discussed the difficulties of shipping an integrated stats/monitoring feature in the short term. As a solution, Jameson created a public Statoshi instance with a nicer interface. Wladimir provided feedback on the graphs, suggesting that visualizing smaller quantities made them invisible due to scale. He also suggested adding random stats such as the number of connected peers that are SPV clients or full nodes, current block height to detect stuck nodes, number of transactions in mempool and UTXO set, fee statistics, and number of orphan blocks/orphan transactions.Jameson has set up a public Statoshi instance and added a nicer interface on top of it since it seems unlikely that an integrated stats/monitoring feature will be shipped in the short term. The public Statoshi instance can be accessed at http://statoshi.info, while the raw Graphite stats can be viewed at http://statoshi.info:8080/. Jameson also invites those with metrics that they think would be helpful for development or monitoring purposes to let him know so he can add them. 2014-05-14T13:10:52+00:00 + In an email conversation on May 14, 2014 at 1:42 PM, Jameson Lopp thanked someone for suggesting metrics to collect and acknowledged that tracking per-peer pings is a different type of metric than what he's currently collecting. He mentioned that he had noted the lack of pong messages in a post he made a few weeks ago on coinchomp.com and provided a link to it. The email also included a pull request #2784.A post made by Jameson Lopp on coinchomp.com notes a lack of pong messages. He adds that tracking per-peer pings is a different type of metric than what he's currently collecting. He says that adding metrics for sent messages validated his theory: his node has never sent a single ping request to a peer and thus has never received a pong message. He also says that he can't even add sent pings or received pongs to the chart because they don't exist in his graphite instance.Josh Lehan, in an email to Jameson Lopp, suggests adding the ping time from one node to other peers. However, he says that it would be a challenge to fit that information into the current design as the graphs seem to be comprised of overall statistics for this node, not per-peer statistics that can vary between peers (such as ping time). He suggests sending the "ping" RPC command on a regular schedule to ensure the graph is updated with new information. He also notes that there is currently no support for overlapping pings.Wladimir comments on the graphs, saying that in the 'connected peers' chart, some larger quantities are visualized. This makes the smaller ones invisible due to scale. He suggests adding other stats such as the number of connected peers that are SPV clients or full nodes, current block height, number of transactions in mempool, number of transactions in UTXO set, maybe some fee statistics, and number of orphan blocks/orphan transactions.This all stems from Jameson Lopp setting up a public Statoshi instance and throwing a nicer interface on top of it.Jameson Lopp created a public Statoshi instance with a better interface than an integrated stats/monitoring feature. Wladimir, while appreciating the graphs in the 'connected peers' chart, suggested adding some random stats such as the number of connected peers that are SPV clients or full nodes (NODE_NETWORK), current block height, the number of transactions in mempool and UTXO set, fee statistics, number of orphan blocks/orphan transactions. Josh Lehan brainstormed the idea of adding the ping time from one node to other peers, however, fitting it into the current design would be a challenge since the graphs seem to be comprised of overall statistics for this node and not per-peer statistics that can vary between peers. There is currently no support for overlapping pings, and something would have to send the "ping" RPC command regularly to ensure the graph is updated with new information.In an email conversation between Jameson Lopp and Wladimir, they discussed the difficulties of shipping an integrated stats/monitoring feature in the short term. As a solution, Jameson created a public Statoshi instance with a nicer interface. Wladimir provided feedback on the graphs, suggesting that visualizing smaller quantities made them invisible due to scale. He also suggested adding random stats such as the number of connected peers that are SPV clients or full nodes, current block height to detect stuck nodes, number of transactions in mempool and UTXO set, fee statistics, and number of orphan blocks/orphan transactions.Jameson has set up a public Statoshi instance and added a nicer interface on top of it since it seems unlikely that an integrated stats/monitoring feature will be shipped in the short term. The public Statoshi instance can be accessed at http://statoshi.info, while the raw Graphite stats can be viewed at http://statoshi.info:8080/. Jameson also invites those with metrics that they think would be helpful for development or monitoring purposes to let him know so he can add them. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_testnet-seed-bitcoin-petertodd-org-is-up-again.xml b/static/bitcoin-dev/May_2014/combined_testnet-seed-bitcoin-petertodd-org-is-up-again.xml index ca4dd5cdcf..9fd677bd44 100644 --- a/static/bitcoin-dev/May_2014/combined_testnet-seed-bitcoin-petertodd-org-is-up-again.xml +++ b/static/bitcoin-dev/May_2014/combined_testnet-seed-bitcoin-petertodd-org-is-up-again.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - testnet-seed.bitcoin.petertodd.org is up again - 2023-08-01T09:23:08.001242+00:00 + 2025-10-11T22:19:50.577633+00:00 + python-feedgen Alex Kotenko 2014-06-01 09:56:52+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - testnet-seed.bitcoin.petertodd.org is up again - 2023-08-01T09:23:08.001242+00:00 + 2025-10-11T22:19:50.577803+00:00 - In a recent Github discussion, the topic of dependency on centralized resources in applications is emphasized. The conversation highlights the importance of addressing issues related to broken and insecure applications caused by DNS seeds being down. It is argued that instead of solely relying on DNS seeds, fallbacks such as hardcoded node lists and manual peer entry should be implemented, particularly during the initial startup phase. This approach ensures that the application remains functional even when DNS seeds are unavailable.However, it is important to note that this solution still relies on a centralized resource. To make the application more resilient, it is suggested that either the application needs to be made more resilient or there needs to be a more robust DNS system in place. This would prevent downtime and ensure that the application can continue to function even when there are issues with DNS seeds.To explore the details of this discussion further, you can refer to the provided link. Additionally, the conversation ends with a mention of automated cross-browser testing and an invitation to join a mailing list. 2014-06-01T09:56:52+00:00 + In a recent Github discussion, the topic of dependency on centralized resources in applications is emphasized. The conversation highlights the importance of addressing issues related to broken and insecure applications caused by DNS seeds being down. It is argued that instead of solely relying on DNS seeds, fallbacks such as hardcoded node lists and manual peer entry should be implemented, particularly during the initial startup phase. This approach ensures that the application remains functional even when DNS seeds are unavailable.However, it is important to note that this solution still relies on a centralized resource. To make the application more resilient, it is suggested that either the application needs to be made more resilient or there needs to be a more robust DNS system in place. This would prevent downtime and ensure that the application can continue to function even when there are issues with DNS seeds.To explore the details of this discussion further, you can refer to the provided link. Additionally, the conversation ends with a mention of automated cross-browser testing and an invitation to join a mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2014/combined_we-can-all-relax-now.xml b/static/bitcoin-dev/May_2014/combined_we-can-all-relax-now.xml index 4039cbbe28..510233bede 100644 --- a/static/bitcoin-dev/May_2014/combined_we-can-all-relax-now.xml +++ b/static/bitcoin-dev/May_2014/combined_we-can-all-relax-now.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - we can all relax now - 2023-08-01T06:27:39.645643+00:00 + 2025-10-11T22:19:27.197167+00:00 + python-feedgen E willbefull 2014-05-10 11:05:29+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - we can all relax now - 2023-08-01T06:27:39.646630+00:00 + 2025-10-11T22:19:27.197327+00:00 - The discussion revolves around several emails that were sent to the Bitcoin-development mailing list. One member, named 'kjj', criticizes the Selfish Mining paper and its unsuitability as a simulation of the Bitcoin system. They argue that the model used in the paper lacks latency and assumes attackers have total visibility across the network. In response to this, 'kjj' offers a bounty of 1 BTC for building a general Bitcoin network simulator framework that can account for latency between nodes and simulate an attacker owning varying fractions of the network.Another contributor expresses frustration with the Selfish Mining paper and criticizes the authors for assuming a total sybil attack without realizing that the conditions necessary for the attack are worse than the attack itself. This contributor also offers a bounty of 1 BTC for building a suitable network simulator that can account for latency and simulate various network scenarios.The author of one email questions the level of accuracy required for a Bitcoin network simulator and suggests conducting experiments to clarify the necessary components. They mention testing Peter Todd's miner strategy, various network split conditions, double spends, and other scenarios. Jeff Garzik offers to contribute 1 BTC to this project.In addition, one email criticizes academics for prioritizing publishing over being helpful to society. The author specifically mentions the Selfish Mining paper, which they believe is based on a flawed model that does not accurately simulate the Bitcoin system. To address the lack of a decent network simulator that allowed the paper to gain press attention, the author offers a bounty of 1 BTC for building a general Bitcoin network simulator framework that can account for latency between nodes and simulate an attacker owning varying fractions of the network.Furthermore, an author on bitcointalk.org criticizes the Selfish Mining paper for its lack of latency and proposes the need for a general Bitcoin network simulator framework that can account for latency between nodes, simulate an attacker owning varying fractions of the network, and be easily modified for other schemes. This author also offers a bounty of 1 BTC for building such a simulator, as the lack of a decent network simulator allowed the Selfish Mining paper to gain attention. 2014-05-10T11:05:29+00:00 + The discussion revolves around several emails that were sent to the Bitcoin-development mailing list. One member, named 'kjj', criticizes the Selfish Mining paper and its unsuitability as a simulation of the Bitcoin system. They argue that the model used in the paper lacks latency and assumes attackers have total visibility across the network. In response to this, 'kjj' offers a bounty of 1 BTC for building a general Bitcoin network simulator framework that can account for latency between nodes and simulate an attacker owning varying fractions of the network.Another contributor expresses frustration with the Selfish Mining paper and criticizes the authors for assuming a total sybil attack without realizing that the conditions necessary for the attack are worse than the attack itself. This contributor also offers a bounty of 1 BTC for building a suitable network simulator that can account for latency and simulate various network scenarios.The author of one email questions the level of accuracy required for a Bitcoin network simulator and suggests conducting experiments to clarify the necessary components. They mention testing Peter Todd's miner strategy, various network split conditions, double spends, and other scenarios. Jeff Garzik offers to contribute 1 BTC to this project.In addition, one email criticizes academics for prioritizing publishing over being helpful to society. The author specifically mentions the Selfish Mining paper, which they believe is based on a flawed model that does not accurately simulate the Bitcoin system. To address the lack of a decent network simulator that allowed the paper to gain press attention, the author offers a bounty of 1 BTC for building a general Bitcoin network simulator framework that can account for latency between nodes and simulate an attacker owning varying fractions of the network.Furthermore, an author on bitcointalk.org criticizes the Selfish Mining paper for its lack of latency and proposes the need for a general Bitcoin network simulator framework that can account for latency between nodes, simulate an attacker owning varying fractions of the network, and be easily modified for other schemes. This author also offers a bounty of 1 BTC for building such a simulator, as the lack of a decent network simulator allowed the Selfish Mining paper to gain attention. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_-ANN-METAmarket-Trustless-Federated-Marketplaces.xml b/static/bitcoin-dev/May_2015/combined_-ANN-METAmarket-Trustless-Federated-Marketplaces.xml index 0b74b3d95a..cd7c2375a4 100644 --- a/static/bitcoin-dev/May_2015/combined_-ANN-METAmarket-Trustless-Federated-Marketplaces.xml +++ b/static/bitcoin-dev/May_2015/combined_-ANN-METAmarket-Trustless-Federated-Marketplaces.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [ANN] METAmarket - Trustless Federated Marketplaces - 2023-08-01T12:20:39.094967+00:00 + 2025-10-11T22:09:57.616302+00:00 + python-feedgen Marc D. Wood 2015-05-02 15:45:35+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [ANN] METAmarket - Trustless Federated Marketplaces - 2023-08-01T12:20:39.094967+00:00 + 2025-10-11T22:09:57.616496+00:00 - In an email conversation between Melvin Carvalho and Marc D. Wood on May 1, 2015, the concept of a software project for creating markets with variable levels of privacy and censorship resistance is discussed. The project, known as METAmarket, is built on top of Bitcoin Core and Bitmessage, similar to the work Satoshi was doing before leaving. However, Marc clarifies that this is not the same project as Satoshi's original plan for a bitcoin marketplace and he is not Satoshi.METAmarket is an open source protocol and reference client for a trustless federated marketplace that utilizes Bitcoin as a universal currency and Bitmessage as a P2P communication network. This system aims to eliminate the need for trusted third parties and middlemen, while also addressing issues such as transaction malleability through a federated reputation model. The client application allows users to post, browse, and execute trades, requiring a Bitcoin Core wallet for handling payments and refunds.The motivation behind METAmarket is to tackle problems associated with overly centralized marketplaces and payment services that impose high fees, excessive control, and compromised privacy. As online commerce grows, users may find their purchase history being sold to advertisers, employers, or government agencies. METAmarket envisions a system where secure private transactions take place directly between buyers and sellers, without middlemen collecting data or adding fees. It is important to note that there is no apparent connection between METAmarket and Satoshi's work in the Bitcoin Core before his departure.METAmarket operates as a trustless federated marketplace, allowing buyers and sellers to transact without intermediaries. Built on blockchain technology, the platform ensures transparent, secure, and immutable transactions. Being decentralized, METAmarket does not charge any fees or commissions from a central authority, and all transaction data is securely stored on the blockchain. The platform incorporates a reputation system, encouraging positive behavior from users and discouraging bad actors. After each transaction, buyers and sellers can rate each other, contributing to an overall reputation score that determines the likelihood of future successful transactions.METAmarket aims to be a universal marketplace that facilitates transactions across all industries, rather than being limited to a specific industry or product category. It supports various types of transactions, including peer-to-peer, business-to-business, and business-to-consumer. The platform is built on the Ethereum blockchain and utilizes smart contracts to automate transactions when certain conditions are met. This ensures smooth and efficient transaction execution. Additionally, METAmarket supports the use of cryptocurrencies as a means of payment, offering users flexibility in conducting their transactions.Overall, METAmarket provides a unique solution to the issue of trust in online marketplaces by leveraging blockchain technology and a reputation system. As the platform continues to expand into new industries, it has the potential to revolutionize online commerce, providing a secure and efficient way for buyers and sellers to transact without intermediaries. 2015-05-02T15:45:35+00:00 + In an email conversation between Melvin Carvalho and Marc D. Wood on May 1, 2015, the concept of a software project for creating markets with variable levels of privacy and censorship resistance is discussed. The project, known as METAmarket, is built on top of Bitcoin Core and Bitmessage, similar to the work Satoshi was doing before leaving. However, Marc clarifies that this is not the same project as Satoshi's original plan for a bitcoin marketplace and he is not Satoshi.METAmarket is an open source protocol and reference client for a trustless federated marketplace that utilizes Bitcoin as a universal currency and Bitmessage as a P2P communication network. This system aims to eliminate the need for trusted third parties and middlemen, while also addressing issues such as transaction malleability through a federated reputation model. The client application allows users to post, browse, and execute trades, requiring a Bitcoin Core wallet for handling payments and refunds.The motivation behind METAmarket is to tackle problems associated with overly centralized marketplaces and payment services that impose high fees, excessive control, and compromised privacy. As online commerce grows, users may find their purchase history being sold to advertisers, employers, or government agencies. METAmarket envisions a system where secure private transactions take place directly between buyers and sellers, without middlemen collecting data or adding fees. It is important to note that there is no apparent connection between METAmarket and Satoshi's work in the Bitcoin Core before his departure.METAmarket operates as a trustless federated marketplace, allowing buyers and sellers to transact without intermediaries. Built on blockchain technology, the platform ensures transparent, secure, and immutable transactions. Being decentralized, METAmarket does not charge any fees or commissions from a central authority, and all transaction data is securely stored on the blockchain. The platform incorporates a reputation system, encouraging positive behavior from users and discouraging bad actors. After each transaction, buyers and sellers can rate each other, contributing to an overall reputation score that determines the likelihood of future successful transactions.METAmarket aims to be a universal marketplace that facilitates transactions across all industries, rather than being limited to a specific industry or product category. It supports various types of transactions, including peer-to-peer, business-to-business, and business-to-consumer. The platform is built on the Ethereum blockchain and utilizes smart contracts to automate transactions when certain conditions are met. This ensures smooth and efficient transaction execution. Additionally, METAmarket supports the use of cryptocurrencies as a means of payment, offering users flexibility in conducting their transactions.Overall, METAmarket provides a unique solution to the issue of trust in online marketplaces by leveraging blockchain technology and a reputation system. As the platform continues to expand into new industries, it has the potential to revolutionize online commerce, providing a secure and efficient way for buyers and sellers to transact without intermediaries. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_-BIP-Normalized-Transaction-IDs.xml b/static/bitcoin-dev/May_2015/combined_-BIP-Normalized-Transaction-IDs.xml index a7557dce0e..41c8b1f3a1 100644 --- a/static/bitcoin-dev/May_2015/combined_-BIP-Normalized-Transaction-IDs.xml +++ b/static/bitcoin-dev/May_2015/combined_-BIP-Normalized-Transaction-IDs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP] Normalized Transaction IDs - 2023-08-01T12:44:01.437339+00:00 + 2025-10-11T22:09:59.740448+00:00 + python-feedgen Stephen Morse 2015-05-19 12:48:20+00:00 @@ -111,13 +112,13 @@ - python-feedgen + 2 Combined summary - [BIP] Normalized Transaction IDs - 2023-08-01T12:44:01.437339+00:00 + 2025-10-11T22:09:59.740664+00:00 - The discussion revolves around the proposal to include the height in transactions without adding an extra field. It is suggested that for non-coinbase transactions, the height used is zero, while for coinbase transactions, the height specified in the scriptSig is copied into the locktime of the transaction before computing the normalized transaction ID.However, it is argued that there's no need to replace lock times or any other part of the transaction. Instead, the height can be serialized right before serializing the transaction, and 0 can be pre-serialized for non-coinbase transactions. The normalization process for non-coinbase transactions involves replacing prevout hash with normalized hash and clearing the scriptSig. Finally, the transaction is serialized using CHashWriter.Christian Decker raises concerns about addressing BIP 34 and avoiding hashed transactions in different ways. Tier Nolan responds by suggesting that the normalized TXID should not depend on the height for non-coinbase transactions, as it would cause mutation when added to the chain. For coinbase transactions, they want the height to be included. The height is proposed to be included in the scriptSig for all transactions, with a height of zero for non-coinbase transactions. Adding an extra field to include the height is not necessary. A rule can be implemented where the height specified in the scriptSig in coinbase transactions is copied into the locktime of the transaction before computing the normalized transaction ID. Nolan suggests that the normalized txid could add the height to the txids of all inputs, while non-coinbase transactions would have heights of zero. The scriptSig in the coinbase is intended to be "random" bytes/extra nonce, so putting a restriction on it was guaranteed to be backward compatible.In an email exchange from May 19, 2015, Christian Decker proposes two proposals to address BIP 34. He suggests including the height in the scriptSig for all transactions, with non-coinbase transactions using a height of zero. The normalized txid function could incorporate the height without any specific inclusion method. The previous txid for coinbases is required to be all zeros, so the normalized txid could add the height to the txids of all inputs. Decker assumes that the scriptSig in the coinbase is intended to be random and therefore backward compatible.Christian Decker proposed a BIP to normalize transaction IDs to address transaction malleability and simplify higher-level protocols. The normalized transaction ID is calculated by removing the scriptSig before computing the hash, ensuring that only data guaranteed by the signatures influences the hash. This guarantees that any change to the normalized ID will invalidate the signature. Validating clients supporting this BIP would use both the normalized tx ID and the legacy tx ID when validating transactions. Template transactions can now be used to build sequences of transactions before signing them. The proposal requires a hardfork but suggests that hardforks should not be feared. The details of how the hardfork is to be done were left out, as it does not matter, and a good mechanism may exist to apply multiple hardforks concurrently in the future.Stephen raises concerns about how BIP34 affects normalized transaction ids in a discussion about implementing a new block height rule. He suggests that normalized txids should strip scriptSigs of all transactions except for coinbase transactions to prevent replay attacks. Another contributor agrees and proposes replacing the scriptSig for coinbases with the height expressed as a varint, which would give all coinbases a unique normalized txid while still preventing spendable duplicates.In an email exchange, s7r discusses the issue of scriptSig and txid being stripped for safety against replays. However, this method is not safe enough as it does not account for multiple scriptPubKeys per transaction. Instead, Luke proposes a scriptPubKey-only sighash type that would provide strong safety in all malleability situations. This would enable advanced wallet software to take advantage of it in the future while strictly enforcing no-reuse on its own wallet to avoid known replays.In response to s7r's question about how a certain process can be safe against malleability of the parent transaction and replays, it is explained that the signature signs everything except itself and the normalized txid doesn't include the signature, so mutations of the signature won't change the normalized txid. If the refund transaction refers to the parent using the normalized txid, then it doesn't matter if the parent has a mutated signature, as the normalized transaction ignores such changes. If there are two transactions that are mutations of each other, only one can be added to the blockchain since the other is a double spend. The normalized txid refers to all of them rather than a specific transaction. Mutation is only a problem if it occurs after signing. If both the scriptSig of the parent and the txid are stripped, nothing can be mutated any longer, but this isn't safe enough as it does not account for multiple scriptPub 2015-05-19T12:48:20+00:00 + The discussion revolves around the proposal to include the height in transactions without adding an extra field. It is suggested that for non-coinbase transactions, the height used is zero, while for coinbase transactions, the height specified in the scriptSig is copied into the locktime of the transaction before computing the normalized transaction ID.However, it is argued that there's no need to replace lock times or any other part of the transaction. Instead, the height can be serialized right before serializing the transaction, and 0 can be pre-serialized for non-coinbase transactions. The normalization process for non-coinbase transactions involves replacing prevout hash with normalized hash and clearing the scriptSig. Finally, the transaction is serialized using CHashWriter.Christian Decker raises concerns about addressing BIP 34 and avoiding hashed transactions in different ways. Tier Nolan responds by suggesting that the normalized TXID should not depend on the height for non-coinbase transactions, as it would cause mutation when added to the chain. For coinbase transactions, they want the height to be included. The height is proposed to be included in the scriptSig for all transactions, with a height of zero for non-coinbase transactions. Adding an extra field to include the height is not necessary. A rule can be implemented where the height specified in the scriptSig in coinbase transactions is copied into the locktime of the transaction before computing the normalized transaction ID. Nolan suggests that the normalized txid could add the height to the txids of all inputs, while non-coinbase transactions would have heights of zero. The scriptSig in the coinbase is intended to be "random" bytes/extra nonce, so putting a restriction on it was guaranteed to be backward compatible.In an email exchange from May 19, 2015, Christian Decker proposes two proposals to address BIP 34. He suggests including the height in the scriptSig for all transactions, with non-coinbase transactions using a height of zero. The normalized txid function could incorporate the height without any specific inclusion method. The previous txid for coinbases is required to be all zeros, so the normalized txid could add the height to the txids of all inputs. Decker assumes that the scriptSig in the coinbase is intended to be random and therefore backward compatible.Christian Decker proposed a BIP to normalize transaction IDs to address transaction malleability and simplify higher-level protocols. The normalized transaction ID is calculated by removing the scriptSig before computing the hash, ensuring that only data guaranteed by the signatures influences the hash. This guarantees that any change to the normalized ID will invalidate the signature. Validating clients supporting this BIP would use both the normalized tx ID and the legacy tx ID when validating transactions. Template transactions can now be used to build sequences of transactions before signing them. The proposal requires a hardfork but suggests that hardforks should not be feared. The details of how the hardfork is to be done were left out, as it does not matter, and a good mechanism may exist to apply multiple hardforks concurrently in the future.Stephen raises concerns about how BIP34 affects normalized transaction ids in a discussion about implementing a new block height rule. He suggests that normalized txids should strip scriptSigs of all transactions except for coinbase transactions to prevent replay attacks. Another contributor agrees and proposes replacing the scriptSig for coinbases with the height expressed as a varint, which would give all coinbases a unique normalized txid while still preventing spendable duplicates.In an email exchange, s7r discusses the issue of scriptSig and txid being stripped for safety against replays. However, this method is not safe enough as it does not account for multiple scriptPubKeys per transaction. Instead, Luke proposes a scriptPubKey-only sighash type that would provide strong safety in all malleability situations. This would enable advanced wallet software to take advantage of it in the future while strictly enforcing no-reuse on its own wallet to avoid known replays.In response to s7r's question about how a certain process can be safe against malleability of the parent transaction and replays, it is explained that the signature signs everything except itself and the normalized txid doesn't include the signature, so mutations of the signature won't change the normalized txid. If the refund transaction refers to the parent using the normalized txid, then it doesn't matter if the parent has a mutated signature, as the normalized transaction ignores such changes. If there are two transactions that are mutations of each other, only one can be added to the blockchain since the other is a double spend. The normalized txid refers to all of them rather than a specific transaction. Mutation is only a problem if it occurs after signing. If both the scriptSig of the parent and the txid are stripped, nothing can be mutated any longer, but this isn't safe enough as it does not account for multiple scriptPub - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_-Bulk-Re-Fwd-Block-Size-Increase-Requirements.xml b/static/bitcoin-dev/May_2015/combined_-Bulk-Re-Fwd-Block-Size-Increase-Requirements.xml index d98e10cd97..02bc8bbed7 100644 --- a/static/bitcoin-dev/May_2015/combined_-Bulk-Re-Fwd-Block-Size-Increase-Requirements.xml +++ b/static/bitcoin-dev/May_2015/combined_-Bulk-Re-Fwd-Block-Size-Increase-Requirements.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [Bulk] Re: Fwd: Block Size Increase Requirements - 2023-08-01T12:58:55.465354+00:00 + 2025-10-11T22:09:21.405504+00:00 + python-feedgen Gavin Andresen 2015-05-31 19:49:05+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [Bulk] Re: Fwd: Block Size Increase Requirements - 2023-08-01T12:58:55.465354+00:00 + 2025-10-11T22:09:21.405640+00:00 - In an email conversation between Gavin Andresen and gb, the topic of calculating bandwidth for highly connected miners was discussed. Gb suggested that the traffic estimates needed to be increased by a factor of 30-100 due to the number of node connections a miner could have. However, Andresen pointed out that randomly connected gossip networks, such as the Bitcoin p2p network, operate differently and that bandwidth is roughly O(N), where N is the number of bytes relayed to everybody.Andresen also mentioned that the overhead of 'inv' messages could increase the bandwidth slightly, but this would not be a problem for years. The discussion revolves around the calculation of bandwidth for a highly connected miner with 30-100 node connections. This means that the traffic estimates need to be increased by that factor.For miners dealing with 100MB blocks, a bandwidth of 30-100 Mbps is required, which translates to data costs of $60-$100 per day. To handle this, the Aliyun and Linode cloud services are utilized for block propagation. As of May 2015, the price for 100Mbps connectivity at Aliyun is 0.13 U.S. dollars per GB. At this speed, it is possible to handle 20MB blocks without any issues.Each 20MB block is estimated to be 100MB of data up/down the wire, but after optimization, it should be reduced to 40MB. Based on this estimation, the cost for bandwidth will be less than $2 per day. It is acknowledged that a single cross-border TCP connection may be slower than 12.5 MB/s, but a speed of 1.3Mbps or less would still be sufficient. 2015-05-31T19:49:05+00:00 + In an email conversation between Gavin Andresen and gb, the topic of calculating bandwidth for highly connected miners was discussed. Gb suggested that the traffic estimates needed to be increased by a factor of 30-100 due to the number of node connections a miner could have. However, Andresen pointed out that randomly connected gossip networks, such as the Bitcoin p2p network, operate differently and that bandwidth is roughly O(N), where N is the number of bytes relayed to everybody.Andresen also mentioned that the overhead of 'inv' messages could increase the bandwidth slightly, but this would not be a problem for years. The discussion revolves around the calculation of bandwidth for a highly connected miner with 30-100 node connections. This means that the traffic estimates need to be increased by that factor.For miners dealing with 100MB blocks, a bandwidth of 30-100 Mbps is required, which translates to data costs of $60-$100 per day. To handle this, the Aliyun and Linode cloud services are utilized for block propagation. As of May 2015, the price for 100Mbps connectivity at Aliyun is 0.13 U.S. dollars per GB. At this speed, it is possible to handle 20MB blocks without any issues.Each 20MB block is estimated to be 100MB of data up/down the wire, but after optimization, it should be reduced to 40MB. Based on this estimation, the cost for bandwidth will be less than $2 per day. It is acknowledged that a single cross-border TCP connection may be slower than 12.5 MB/s, but a speed of 1.3Mbps or less would still be sufficient. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_A-suggestion-for-reducing-the-size-of-the-UTXO-database.xml b/static/bitcoin-dev/May_2015/combined_A-suggestion-for-reducing-the-size-of-the-UTXO-database.xml index ddb59d349a..9609a0cd16 100644 --- a/static/bitcoin-dev/May_2015/combined_A-suggestion-for-reducing-the-size-of-the-UTXO-database.xml +++ b/static/bitcoin-dev/May_2015/combined_A-suggestion-for-reducing-the-size-of-the-UTXO-database.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A suggestion for reducing the size of the UTXO database - 2023-08-01T12:37:12.528074+00:00 + 2025-10-11T22:10:01.872017+00:00 + python-feedgen Andreas Schildbach 2015-05-26 12:40:28+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - A suggestion for reducing the size of the UTXO database - 2023-08-01T12:37:12.529073+00:00 + 2025-10-11T22:10:01.872217+00:00 - Building a transaction in Bitcoin can lead to the growth of the Unspent Transaction Output (UTXO) database. The current practice is to select the minimum number of unspent outputs from a specific address for a transaction. However, a proposal suggests that all UTXOs from a particular address or wallet should be selected instead. This approach involves sending the required amount to the payee and sending the remaining funds back to the same address or a change address as a single output. By consolidating unspent outputs in this way, the UTXO database would gradually decrease in size over time, preventing its continuous growth.Implementing this solution poses some challenges. Spending unconfirmed outputs requires a different security model for the receiver, and wallet software may refuse to spend unconfirmed outputs. There is also a proposal for a fork/merge design where the network calculates the change instead of the submitter. This would allow transactions with the same change address and a common input to be merged or split, but it has privacy implications and would require a hard fork.Various proposals have been suggested to address the issue of UTXO growth, including consolidating unspent outputs at the wallet level and implementing a fork/merge design. Wallet developers and miners have a vested interest in reducing the size of the UTXO database. Relays could enforce behavior that promotes this goal by refusing to relay or deprioritizing transactions that don't use all available UTXOs from input addresses. However, these proposals come with challenges and trade-offs, and further discussions and considerations are needed to find an effective solution.The consolidation of UTXOs in transactions would also benefit miners by reducing the storage space required for holding the UTXO. Relays could play a role in enforcing this behavior by prioritizing transactions that utilize all available UTXOs. The criteria for selecting UTXOs when making a Bitcoin transaction include choosing the smallest possible set of addresses that can provide enough BTC, selecting sets with the largest number of UTXOs, sets with the largest total amount of BTC, sets that destroy the most bitcoin days, and randomly selecting from multiple sets.The age of UTXOs is another factor discussed in relation to Bitcoin transactions. Miners typically do not consider the age of UTXO entries, except for cases involving free transactions or coinbase transaction outputs. Free transactions need to have a priority level determined by BTC-days-destroyed per byte, while coinbase transaction outputs cannot be spent until 100 confirmations after being added to the blockchain.Privacy concerns are also raised when building Bitcoin transactions. Some suggest limiting the selection of UTXOs to a single address and sending change back to the same address to ensure privacy. However, others argue that sending change back to the same address could compromise privacy and propose sending the change output to a new change address. While mainstream wallets have different priorities regarding privacy compared to privacy-focused wallets, all wallets can improve their algorithms and promote some degree of consolidation.The issue of UTXO growth has implications for transaction fees and privacy. The size of the UTXO set affects the ease of running a full node and the spread and value of Bitcoin. Wallet developers are encouraged to adopt UTXO selection algorithms that reduce the database size. However, UTXO growth is not limited to wallets alone, and economic implications should be considered when charging differently for in/out mismatches.Overall, the email thread and conversations underscore the importance of considering privacy concerns, UTXO growth, and fee optimization when building wallets and improving algorithms. Developers, miners, and other stakeholders should collaborate to find effective solutions that balance these factors and ensure the continued efficiency and scalability of the Bitcoin network. 2015-05-26T12:40:28+00:00 + Building a transaction in Bitcoin can lead to the growth of the Unspent Transaction Output (UTXO) database. The current practice is to select the minimum number of unspent outputs from a specific address for a transaction. However, a proposal suggests that all UTXOs from a particular address or wallet should be selected instead. This approach involves sending the required amount to the payee and sending the remaining funds back to the same address or a change address as a single output. By consolidating unspent outputs in this way, the UTXO database would gradually decrease in size over time, preventing its continuous growth.Implementing this solution poses some challenges. Spending unconfirmed outputs requires a different security model for the receiver, and wallet software may refuse to spend unconfirmed outputs. There is also a proposal for a fork/merge design where the network calculates the change instead of the submitter. This would allow transactions with the same change address and a common input to be merged or split, but it has privacy implications and would require a hard fork.Various proposals have been suggested to address the issue of UTXO growth, including consolidating unspent outputs at the wallet level and implementing a fork/merge design. Wallet developers and miners have a vested interest in reducing the size of the UTXO database. Relays could enforce behavior that promotes this goal by refusing to relay or deprioritizing transactions that don't use all available UTXOs from input addresses. However, these proposals come with challenges and trade-offs, and further discussions and considerations are needed to find an effective solution.The consolidation of UTXOs in transactions would also benefit miners by reducing the storage space required for holding the UTXO. Relays could play a role in enforcing this behavior by prioritizing transactions that utilize all available UTXOs. The criteria for selecting UTXOs when making a Bitcoin transaction include choosing the smallest possible set of addresses that can provide enough BTC, selecting sets with the largest number of UTXOs, sets with the largest total amount of BTC, sets that destroy the most bitcoin days, and randomly selecting from multiple sets.The age of UTXOs is another factor discussed in relation to Bitcoin transactions. Miners typically do not consider the age of UTXO entries, except for cases involving free transactions or coinbase transaction outputs. Free transactions need to have a priority level determined by BTC-days-destroyed per byte, while coinbase transaction outputs cannot be spent until 100 confirmations after being added to the blockchain.Privacy concerns are also raised when building Bitcoin transactions. Some suggest limiting the selection of UTXOs to a single address and sending change back to the same address to ensure privacy. However, others argue that sending change back to the same address could compromise privacy and propose sending the change output to a new change address. While mainstream wallets have different priorities regarding privacy compared to privacy-focused wallets, all wallets can improve their algorithms and promote some degree of consolidation.The issue of UTXO growth has implications for transaction fees and privacy. The size of the UTXO set affects the ease of running a full node and the spread and value of Bitcoin. Wallet developers are encouraged to adopt UTXO selection algorithms that reduce the database size. However, UTXO growth is not limited to wallets alone, and economic implications should be considered when charging differently for in/out mismatches.Overall, the email thread and conversations underscore the importance of considering privacy concerns, UTXO growth, and fee optimization when building wallets and improving algorithms. Developers, miners, and other stakeholders should collaborate to find effective solutions that balance these factors and ensure the continued efficiency and scalability of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_A-way-to-create-a-fee-market-even-without-a-block-size-limit-2013-.xml b/static/bitcoin-dev/May_2015/combined_A-way-to-create-a-fee-market-even-without-a-block-size-limit-2013-.xml index 7d15655855..2b82286386 100644 --- a/static/bitcoin-dev/May_2015/combined_A-way-to-create-a-fee-market-even-without-a-block-size-limit-2013-.xml +++ b/static/bitcoin-dev/May_2015/combined_A-way-to-create-a-fee-market-even-without-a-block-size-limit-2013-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A way to create a fee market even without a block size limit (2013) - 2023-08-01T12:37:35.315954+00:00 + 2025-10-11T22:09:40.610202+00:00 + python-feedgen Sergio Lerner 2015-05-11 06:09:58+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - A way to create a fee market even without a block size limit (2013) - 2023-08-01T12:37:35.315954+00:00 + 2025-10-11T22:09:40.610414+00:00 - In a 2015 discussion, Gregory Maxwell and Sergio Lerner explored the possibility of gaming the Bitcoin network. Lerner proposed five methods for users to pay fees to miners, including transaction fees, creating multiple transactions with output that pays each miner fees, adding an anyone-can-spend output for fees, using a single input to add desired amount plus fees, and negotiating out-of-band with the miner. Lerner concluded that alternate fee-paying methods without pre-negotiation were unreliable. He suggested reducing the block rate, utilizing the CoVar method, and not allowing spending outputs in the same block they were created.The email thread discussed the connection between the block size debate and creating a fee market. The author argued that there is already a marketplace for block space but miners are not competitive enough. They believed that altering consensus rules to force a marketplace for fees/block space should not be the solution and that the market should develop on its own. Sergio Lerner proposed a new way to create a fee market that does not rely on the blockchain limit. His proposal required a hardfork but had minimal impact on the code and economics. The solution involved requiring that the set of fees collected in a block has a dispersion below a threshold, using the Coefficient of Variation. This would discourage spamming users from paying low fees and encourage the market to develop naturally. Increasing the block size would also prevent miners from filling the block with spamming transactions.In another email conversation in May 2015, Sergio Lerner questioned whether the system could be gamed. It was noted that users have the ability to pay fees out of band to miners, which is undetectable to the network. This behavior has been observed since at least 2011. Lerner's suggestion was seen as further rewarding this behavior and enabling bypassing of controls. It was suspected that any scheme looking at fee values may have similar properties.Two years later, Sergio Lerner presented a new solution to create a fee market that does not depend on the blockchain limit. The proposed solution involved requiring the set of fees collected in a block to have a dispersion below a threshold calculated using the Coefficient of Variation. If the CoVar exceeded the threshold, the block would be considered invalid. However, enforcing consensus rules regarding fees is challenging due to the ability to pay miners out of band. Despite this limitation, the modification to the transaction selection algorithm could discourage spamming users and incentivize researchers to develop better transaction selection algorithms.Overall, these discussions highlight the complexities and challenges associated with creating a fee market within the Bitcoin network. Various methods and proposals have been suggested, but there is still debate and exploration needed to find the most effective approach. 2015-05-11T06:09:58+00:00 + In a 2015 discussion, Gregory Maxwell and Sergio Lerner explored the possibility of gaming the Bitcoin network. Lerner proposed five methods for users to pay fees to miners, including transaction fees, creating multiple transactions with output that pays each miner fees, adding an anyone-can-spend output for fees, using a single input to add desired amount plus fees, and negotiating out-of-band with the miner. Lerner concluded that alternate fee-paying methods without pre-negotiation were unreliable. He suggested reducing the block rate, utilizing the CoVar method, and not allowing spending outputs in the same block they were created.The email thread discussed the connection between the block size debate and creating a fee market. The author argued that there is already a marketplace for block space but miners are not competitive enough. They believed that altering consensus rules to force a marketplace for fees/block space should not be the solution and that the market should develop on its own. Sergio Lerner proposed a new way to create a fee market that does not rely on the blockchain limit. His proposal required a hardfork but had minimal impact on the code and economics. The solution involved requiring that the set of fees collected in a block has a dispersion below a threshold, using the Coefficient of Variation. This would discourage spamming users from paying low fees and encourage the market to develop naturally. Increasing the block size would also prevent miners from filling the block with spamming transactions.In another email conversation in May 2015, Sergio Lerner questioned whether the system could be gamed. It was noted that users have the ability to pay fees out of band to miners, which is undetectable to the network. This behavior has been observed since at least 2011. Lerner's suggestion was seen as further rewarding this behavior and enabling bypassing of controls. It was suspected that any scheme looking at fee values may have similar properties.Two years later, Sergio Lerner presented a new solution to create a fee market that does not depend on the blockchain limit. The proposed solution involved requiring the set of fees collected in a block to have a dispersion below a threshold calculated using the Coefficient of Variation. If the CoVar exceeded the threshold, the block would be considered invalid. However, enforcing consensus rules regarding fees is challenging due to the ability to pay miners out of band. Despite this limitation, the modification to the transaction selection algorithm could discourage spamming users and incentivize researchers to develop better transaction selection algorithms.Overall, these discussions highlight the complexities and challenges associated with creating a fee market within the Bitcoin network. Various methods and proposals have been suggested, but there is still debate and exploration needed to find the most effective approach. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Assurance-contracts-to-fund-the-network-with-OP-CHECKLOCKTIMEVERIFY.xml b/static/bitcoin-dev/May_2015/combined_Assurance-contracts-to-fund-the-network-with-OP-CHECKLOCKTIMEVERIFY.xml index 1fed85690e..97ed935081 100644 --- a/static/bitcoin-dev/May_2015/combined_Assurance-contracts-to-fund-the-network-with-OP-CHECKLOCKTIMEVERIFY.xml +++ b/static/bitcoin-dev/May_2015/combined_Assurance-contracts-to-fund-the-network-with-OP-CHECKLOCKTIMEVERIFY.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY - 2023-08-01T12:26:48.268120+00:00 + 2025-10-11T22:10:03.996973+00:00 + python-feedgen Peter Todd 2015-05-08 16:43:10+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY - 2023-08-01T12:26:48.268120+00:00 + 2025-10-11T22:10:03.997150+00:00 - On May 8, 2015, Jeff Garzik suggested integrating a patch for anyone-can-pay transactions, but it should be anyone-can-spend instead. Peter Todd had already written code for this, which can be found on Github. However, an added feature is needed where the txout set will be replaced with just OP_RETURN-to-fees if the inputs do not sign the outputs. The previous email discussed the advantages of assurance contracts over simple donations. Assurance contracts are similar to Kickstarter, where the credit card is charged only if the project is fully funded, reducing the risk for pledgers. Kickstarter also has pledge rewards to encourage people to pledge and create momentum for the project. The discussion revolves around incentivizing transaction verification, as AC or anti-cheat mechanisms do not solve the problem. Bitcoin solves this issue through an enforced subsidy, but the challenge of incentivizing verification without subsidy remains unsolved. Pledgers create transactions using a specific template and broadcast them. The p2p protocol could be modified or a separate system could be used. The OP_CHECKLOCKTIMEVERIFY opcode ensures that the 50BTC output cannot be spent until block 1 million. If the transaction hasn't been completed by block 999,900 due to insufficient pledgers, they can withdraw their pledge by spending the coins intended for the pledge.The context describes a process of making a donation of 50BTC by a group of 1000 people. Pledgers create transactions using a specified template and broadcast them. The transaction is invalid until enough other users have added pledges, and a valid transaction can be broadcast. Once a valid transaction is included in the blockchain, it becomes locked in. The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot be spent until block 1 million. If the transaction hasn't been completed by block 999,900 due to not enough pledgers, the pledgers can spend the coins they were going to use for their pledge. The context discusses the process of creating transactions and broadcasting them. Pledgers create transactions using a template and broadcast it, and the p2p protocol could be modified or be a separate system. The transaction includes inputs, outputs, and signatures with SIGHASH_ANYONE_CAN_PAY that allows other people to add additional inputs without making the signature invalid. The aim is to add enough pledges from other users to create a valid transaction that can be broadcasted to the main network and once included in the blockchain, it is locked in. The transaction includes an OP_CHECKLOCKTIMEVERIFY opcode that means the 50BTC output cannot be spent until block 1 million, and once block 1 million arrives, the output is completely unprotected. In case the transaction hasn't been completed by block 999,900, the pledgers can spend the coins they were going to use for their pledge, which invalidates those inputs and withdraws from the pledge. Furthermore, the context discusses a scenario where a pledger says that they will only pay 0.01BTC if the miner gets a reward of 50BTC. It highlights the tragedy of the commons problem where everyone has an incentive to wait until the last minute to pledge, making it not perfect.The email conversation thread discusses issues related to Bitcoin mining. One issue raised is how to determine who was the first in the chain, as a node closer to where more transactions happen would have an advantage, making mining unfair. Another issue is a merchant causing block number 1 million to have a minting fee of 50BTC, which could lead to the tragedy of the commons problem. Tier's solution is positively received by Mike Hearn, but no further details are provided. The email ends with an advertisement for a monitoring support service with deep dive visibility.In May 2015, Tier Nolan suggested using assurance contracts to avoid fees going to zero. Mike Hearn's method did not create an assurance contract, as miners could exploit it. Nolan proposed a transaction with one input and one output signed using SIGHASH_ANYONE_CAN_PAY. The output pays to OP_TRUE, meaning anyone can spend it. If enough pledges are made, then a valid transaction can be created. Miners could maintain a notice board system for these pledges. However, this system counts as a pure donation, and miners can add their own money to finish the transaction. OP_CHECKLOCKTIMEVERIFY can be used to solve this problem by paying 50 BTC to "million> OP_CHECKLOCKTIMEVERIFY OP_TRUE" and 0.01BTC to "OP_TRUE." This allows the transaction to be included well in advance of the 1 million block point, and any miner would be able to spend the 50 BTC once block 1 million arrives. Pledgers may also want to pledge to multiple blocks at once. 2015-05-08T16:43:10+00:00 + On May 8, 2015, Jeff Garzik suggested integrating a patch for anyone-can-pay transactions, but it should be anyone-can-spend instead. Peter Todd had already written code for this, which can be found on Github. However, an added feature is needed where the txout set will be replaced with just OP_RETURN-to-fees if the inputs do not sign the outputs. The previous email discussed the advantages of assurance contracts over simple donations. Assurance contracts are similar to Kickstarter, where the credit card is charged only if the project is fully funded, reducing the risk for pledgers. Kickstarter also has pledge rewards to encourage people to pledge and create momentum for the project. The discussion revolves around incentivizing transaction verification, as AC or anti-cheat mechanisms do not solve the problem. Bitcoin solves this issue through an enforced subsidy, but the challenge of incentivizing verification without subsidy remains unsolved. Pledgers create transactions using a specific template and broadcast them. The p2p protocol could be modified or a separate system could be used. The OP_CHECKLOCKTIMEVERIFY opcode ensures that the 50BTC output cannot be spent until block 1 million. If the transaction hasn't been completed by block 999,900 due to insufficient pledgers, they can withdraw their pledge by spending the coins intended for the pledge.The context describes a process of making a donation of 50BTC by a group of 1000 people. Pledgers create transactions using a specified template and broadcast them. The transaction is invalid until enough other users have added pledges, and a valid transaction can be broadcast. Once a valid transaction is included in the blockchain, it becomes locked in. The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot be spent until block 1 million. If the transaction hasn't been completed by block 999,900 due to not enough pledgers, the pledgers can spend the coins they were going to use for their pledge. The context discusses the process of creating transactions and broadcasting them. Pledgers create transactions using a template and broadcast it, and the p2p protocol could be modified or be a separate system. The transaction includes inputs, outputs, and signatures with SIGHASH_ANYONE_CAN_PAY that allows other people to add additional inputs without making the signature invalid. The aim is to add enough pledges from other users to create a valid transaction that can be broadcasted to the main network and once included in the blockchain, it is locked in. The transaction includes an OP_CHECKLOCKTIMEVERIFY opcode that means the 50BTC output cannot be spent until block 1 million, and once block 1 million arrives, the output is completely unprotected. In case the transaction hasn't been completed by block 999,900, the pledgers can spend the coins they were going to use for their pledge, which invalidates those inputs and withdraws from the pledge. Furthermore, the context discusses a scenario where a pledger says that they will only pay 0.01BTC if the miner gets a reward of 50BTC. It highlights the tragedy of the commons problem where everyone has an incentive to wait until the last minute to pledge, making it not perfect.The email conversation thread discusses issues related to Bitcoin mining. One issue raised is how to determine who was the first in the chain, as a node closer to where more transactions happen would have an advantage, making mining unfair. Another issue is a merchant causing block number 1 million to have a minting fee of 50BTC, which could lead to the tragedy of the commons problem. Tier's solution is positively received by Mike Hearn, but no further details are provided. The email ends with an advertisement for a monitoring support service with deep dive visibility.In May 2015, Tier Nolan suggested using assurance contracts to avoid fees going to zero. Mike Hearn's method did not create an assurance contract, as miners could exploit it. Nolan proposed a transaction with one input and one output signed using SIGHASH_ANYONE_CAN_PAY. The output pays to OP_TRUE, meaning anyone can spend it. If enough pledges are made, then a valid transaction can be created. Miners could maintain a notice board system for these pledges. However, this system counts as a pure donation, and miners can add their own money to finish the transaction. OP_CHECKLOCKTIMEVERIFY can be used to solve this problem by paying 50 BTC to "million> OP_CHECKLOCKTIMEVERIFY OP_TRUE" and 0.01BTC to "OP_TRUE." This allows the transaction to be included well in advance of the 1 million block point, and any miner would be able to spend the 50 BTC once block 1 million arrives. Pledgers may also want to pledge to multiple blocks at once. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_BIP-for-deterministic-pay-to-script-hash-multi-signature-addresses.xml b/static/bitcoin-dev/May_2015/combined_BIP-for-deterministic-pay-to-script-hash-multi-signature-addresses.xml index 3d8aee5356..9a85e7a546 100644 --- a/static/bitcoin-dev/May_2015/combined_BIP-for-deterministic-pay-to-script-hash-multi-signature-addresses.xml +++ b/static/bitcoin-dev/May_2015/combined_BIP-for-deterministic-pay-to-script-hash-multi-signature-addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP for deterministic pay-to-script-hash multi-signature addresses - 2023-08-01T11:34:38.505279+00:00 + 2025-10-11T22:09:34.166670+00:00 + python-feedgen Eric Lombrozo 2015-05-24 00:44:20+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP for deterministic pay-to-script-hash multi-signature addresses - 2023-08-01T11:34:38.505279+00:00 + 2025-10-11T22:09:34.166816+00:00 - In February 2015, a discussion took place on the Bitcoin-development mailing list regarding the lack of a specification section in a script template format created by William Swanson and Eric Lombrozo. Luke Dashjr asked if the format supported arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested that all pubkeys executed by all CHECKMULTISIG opcodes should be in canonical order, with some examples provided. However, Todd expressed concern about the rule being too restrictive and not enforced as an IsStandard() rule.The email thread discussed modifications needed for a document to be merged. The BIP being discussed is meant to derive the type of scripts encountered while doing addmultisigaddress. There was a discussion about enforcing a convention for canonical ordering of pubkeys executed by all CHECKMULTISIG opcodes, but it should not be brought into validation rules. It was suggested that wallets could opt-in to this convention for ease of recovery and interoperability reasons.Luke Dashjr and Peter Todd discussed the BIP process for deriving scripts and the need for a Specification section. They agreed that there should be a convention for ordering pubkeys executed by all CHECKMULTISIG opcodes, but it should not be enforced as a soft-fork or IsStandard() rule. Wallets can choose to follow this convention for ease of recovery and interoperability.A proposed standard called BIP44/45 aims to allow software to comply and express compatibility, making it easier for wallet software to be compatible with each other. Questions were raised about whether the specification section supports arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested a rule stating that all pubkeys executed by all CHECKMULTISIG opcodes will be in canonical order, followed by some explanatory examples. However, he noted that there is currently no standard way of discussing arbitrary scripts, so the above rule may be too restrictive in some cases.In an email conversation, Luke Dashjr inquired about the specification section of a BIP. Peter Todd suggested rewriting the BIP to state that all public keys executed by all CHECKMULTISIG opcodes would be in canonical order, with some examples provided. However, he also noted that there is currently no standard way of discussing arbitrary scripts, so this rule may not be sufficient in many cases. Peter Todd further stated that he would not want to enforce this as a soft-fork or make it an IsStandard() rule.On February 12, 2015, Thomas Kerin drafted a Bitcoin Improvement Proposal (BIP) with Jean Pierre and Ruben, describing a method to deterministically generate multi-signature transaction scripts. The proposal aims to allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. The BIP focuses on defining how public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and required signatures. Implementations that do not conform with this BIP may have compatibility issues with strictly-compliant wallets.A new Bitcoin Improvement Proposal (BIP) has been drafted to enable deterministic pay-to-script-hash multi-signature addresses through public key sorting. The BIP proposes a standard method to generate multi-signature transaction scripts and defines how the public keys must be encoded and sorted to ensure that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. This will simplify the derivation of scripts and their addresses by all parties and enable services to declare themselves as BIP compliant, working towards interoperability of services.The adoption of a sorting and encoding standard will ensure that compliant wallets produce the same P2SH address for the same given set of keys and required signature count, which is particularly beneficial for multisignature hierarchical-deterministic wallets as less state is required to set up multi-signature accounts. The proposed method requires that public keys be received in compressed form, sorted lexicographically according to their binary representation, and used in a standard multisig redeem script before being hashed according to BIP-0016 to get the P2SH address.Although the BIP is compatible with compressed keys only, it will enable implementations that adopt this standard to be cross-compatible when choosing multisig addresses. However, a group of users that are not entirely compliant could result in one participant deriving an address that the others will not recognize.The context also includes a PGP signature for cryptographic authentication, an HTML attachment that has been scrubbed, and two non-text attachments in the form of PGP keys and signatures. The purpose or content of the message is not clear from the available information, but it appears to be related to secure communication and authentication using PGP encryption and signatures. 2015-05-24T00:44:20+00:00 + In February 2015, a discussion took place on the Bitcoin-development mailing list regarding the lack of a specification section in a script template format created by William Swanson and Eric Lombrozo. Luke Dashjr asked if the format supported arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested that all pubkeys executed by all CHECKMULTISIG opcodes should be in canonical order, with some examples provided. However, Todd expressed concern about the rule being too restrictive and not enforced as an IsStandard() rule.The email thread discussed modifications needed for a document to be merged. The BIP being discussed is meant to derive the type of scripts encountered while doing addmultisigaddress. There was a discussion about enforcing a convention for canonical ordering of pubkeys executed by all CHECKMULTISIG opcodes, but it should not be brought into validation rules. It was suggested that wallets could opt-in to this convention for ease of recovery and interoperability reasons.Luke Dashjr and Peter Todd discussed the BIP process for deriving scripts and the need for a Specification section. They agreed that there should be a convention for ordering pubkeys executed by all CHECKMULTISIG opcodes, but it should not be enforced as a soft-fork or IsStandard() rule. Wallets can choose to follow this convention for ease of recovery and interoperability.A proposed standard called BIP44/45 aims to allow software to comply and express compatibility, making it easier for wallet software to be compatible with each other. Questions were raised about whether the specification section supports arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested a rule stating that all pubkeys executed by all CHECKMULTISIG opcodes will be in canonical order, followed by some explanatory examples. However, he noted that there is currently no standard way of discussing arbitrary scripts, so the above rule may be too restrictive in some cases.In an email conversation, Luke Dashjr inquired about the specification section of a BIP. Peter Todd suggested rewriting the BIP to state that all public keys executed by all CHECKMULTISIG opcodes would be in canonical order, with some examples provided. However, he also noted that there is currently no standard way of discussing arbitrary scripts, so this rule may not be sufficient in many cases. Peter Todd further stated that he would not want to enforce this as a soft-fork or make it an IsStandard() rule.On February 12, 2015, Thomas Kerin drafted a Bitcoin Improvement Proposal (BIP) with Jean Pierre and Ruben, describing a method to deterministically generate multi-signature transaction scripts. The proposal aims to allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. The BIP focuses on defining how public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and required signatures. Implementations that do not conform with this BIP may have compatibility issues with strictly-compliant wallets.A new Bitcoin Improvement Proposal (BIP) has been drafted to enable deterministic pay-to-script-hash multi-signature addresses through public key sorting. The BIP proposes a standard method to generate multi-signature transaction scripts and defines how the public keys must be encoded and sorted to ensure that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. This will simplify the derivation of scripts and their addresses by all parties and enable services to declare themselves as BIP compliant, working towards interoperability of services.The adoption of a sorting and encoding standard will ensure that compliant wallets produce the same P2SH address for the same given set of keys and required signature count, which is particularly beneficial for multisignature hierarchical-deterministic wallets as less state is required to set up multi-signature accounts. The proposed method requires that public keys be received in compressed form, sorted lexicographically according to their binary representation, and used in a standard multisig redeem script before being hashed according to BIP-0016 to get the P2SH address.Although the BIP is compatible with compressed keys only, it will enable implementations that adopt this standard to be cross-compatible when choosing multisig addresses. However, a group of users that are not entirely compliant could result in one participant deriving an address that the others will not recognize.The context also includes a PGP signature for cryptographic authentication, an HTML attachment that has been scrubbed, and two non-text attachments in the form of PGP keys and signatures. The purpose or content of the message is not clear from the available information, but it appears to be related to secure communication and authentication using PGP encryption and signatures. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Bitcoin-Core-0-10-1-release-candidate-2-available.xml b/static/bitcoin-dev/May_2015/combined_Bitcoin-Core-0-10-1-release-candidate-2-available.xml index dce7cffe55..3e707dd44c 100644 --- a/static/bitcoin-dev/May_2015/combined_Bitcoin-Core-0-10-1-release-candidate-2-available.xml +++ b/static/bitcoin-dev/May_2015/combined_Bitcoin-Core-0-10-1-release-candidate-2-available.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.10.1 release candidate 2 available - 2023-08-01T12:13:42.768921+00:00 + 2025-10-11T22:09:55.492178+00:00 + python-feedgen Wladimir J. van der Laan 2015-05-14 09:18:26+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.10.1 release candidate 2 available - 2023-08-01T12:13:42.768921+00:00 + 2025-10-11T22:09:55.492309+00:00 - Bitcoin Core version 0.10.2rc1 binaries are now available for download from bitcoin.org. This release is a minor update that primarily addresses a bug affecting Windows users with non-ASCII characters in their data directory. Additionally, the release includes translation updates. Users who did not encounter any issues with the previous version, 0.10.1, do not need to upgrade.For those interested, preliminary release notes for version 0.10.2 can be found on Github under the signed tag. Release candidates like this one serve as test runs for new releases. If no critical problems are discovered, this release candidate will be tagged as version 0.10.2. Any bugs encountered should be reported using the issue tracker on Github.In related news, Bitcoin Core 0.10.1rc2 executables have been uploaded to bitcoin.org for testing purposes. The source code can be found in git under the tag 'v0.10.1rc2'. The sole change in this release candidate compared to rc1 is a fix by Gavin Andresen, which ensures consistent mempool behavior during block-reorganizations. Wladimir expressed gratitude to everyone who participated in the gitian build process. 2015-05-14T09:18:26+00:00 + Bitcoin Core version 0.10.2rc1 binaries are now available for download from bitcoin.org. This release is a minor update that primarily addresses a bug affecting Windows users with non-ASCII characters in their data directory. Additionally, the release includes translation updates. Users who did not encounter any issues with the previous version, 0.10.1, do not need to upgrade.For those interested, preliminary release notes for version 0.10.2 can be found on Github under the signed tag. Release candidates like this one serve as test runs for new releases. If no critical problems are discovered, this release candidate will be tagged as version 0.10.2. Any bugs encountered should be reported using the issue tracker on Github.In related news, Bitcoin Core 0.10.1rc2 executables have been uploaded to bitcoin.org for testing purposes. The source code can be found in git under the tag 'v0.10.1rc2'. The sole change in this release candidate compared to rc1 is a fix by Gavin Andresen, which ensures consistent mempool behavior during block-reorganizations. Wladimir expressed gratitude to everyone who participated in the gitian build process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Bitcoin-Core-0-10-2-released.xml b/static/bitcoin-dev/May_2015/combined_Bitcoin-Core-0-10-2-released.xml index e2b11ca81e..485bb7a433 100644 --- a/static/bitcoin-dev/May_2015/combined_Bitcoin-Core-0-10-2-released.xml +++ b/static/bitcoin-dev/May_2015/combined_Bitcoin-Core-0-10-2-released.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.10.2 released - 2023-08-01T12:45:23.463488+00:00 + 2025-10-11T22:10:16.756015+00:00 + python-feedgen Wladimir 2015-05-19 14:29:16+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.10.2 released - 2023-08-01T12:45:23.463488+00:00 + 2025-10-11T22:10:16.756150+00:00 - Bitcoin Core version 0.10.2 has been released and is now available for download. This update includes minor bug fixes and translation updates. It is only necessary to upgrade if you are unable to start the application on Windows with version 0.10.1. The source code can be found in git under the tag 'v0.10.2' or in bitcoin-0.10.2.tar.gz in the distribution.To downgrade smoothly, users are advised to make a backup of their entire data directory. It is important to note that this release utilizes headers-first synchronization and parallel block download, which means that the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software. One notable change in this release is the fix for a serious problem on Windows with data directories that have non-ASCII characters. There are no other notable changes for other platforms. The change log also includes a fix for boost::get usage with boost 1.58 and an avoidance of crash on start in TestBlockValidity with gen=1. Additionally, an issue with imbuing boost::filesystem::path with locale "C" on Windows has been resolved.The release credits Cory Fields, Gregory Maxwell, Jonas Schnelli, and Wladimir J. van der Laan for their direct contributions. dexX7, Pieter Wuille, and vayvanne are also acknowledged for their additional code review and/or security research.Users are encouraged to report any bugs using the issue tracker at Github. 2015-05-19T14:29:16+00:00 + Bitcoin Core version 0.10.2 has been released and is now available for download. This update includes minor bug fixes and translation updates. It is only necessary to upgrade if you are unable to start the application on Windows with version 0.10.1. The source code can be found in git under the tag 'v0.10.2' or in bitcoin-0.10.2.tar.gz in the distribution.To downgrade smoothly, users are advised to make a backup of their entire data directory. It is important to note that this release utilizes headers-first synchronization and parallel block download, which means that the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software. One notable change in this release is the fix for a serious problem on Windows with data directories that have non-ASCII characters. There are no other notable changes for other platforms. The change log also includes a fix for boost::get usage with boost 1.58 and an avoidance of crash on start in TestBlockValidity with gen=1. Additionally, an issue with imbuing boost::filesystem::path with locale "C" on Windows has been resolved.The release credits Cory Fields, Gregory Maxwell, Jonas Schnelli, and Wladimir J. van der Laan for their direct contributions. dexX7, Pieter Wuille, and vayvanne are also acknowledged for their additional code review and/or security research.Users are encouraged to report any bugs using the issue tracker at Github. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Bitcoin-Survey-Paper.xml b/static/bitcoin-dev/May_2015/combined_Bitcoin-Survey-Paper.xml index 07968fdaaa..277fa64a7c 100644 --- a/static/bitcoin-dev/May_2015/combined_Bitcoin-Survey-Paper.xml +++ b/static/bitcoin-dev/May_2015/combined_Bitcoin-Survey-Paper.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Survey Paper - 2023-08-01T12:50:05.007126+00:00 + 2025-10-11T22:09:32.043170+00:00 + python-feedgen Daniel Kraft 2015-05-26 14:11:14+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Survey Paper - 2023-08-01T12:50:05.007126+00:00 + 2025-10-11T22:09:32.043382+00:00 - Florian Tschorsch, a research scholar, noticed a lack of comprehensive survey papers on Bitcoin and decided to address this gap by creating a technical report. Seeking to contribute to the Bitcoin community, Florian shared the link (https://eprint.iacr.org/2015/464) to his report and invited readers to provide feedback for future revisions. One reader, Daniel, appreciated Florian's work and recommended another research paper co-authored by Joseph Bonneau, which focuses on Bitcoin. Additionally, Daniel promoted his own work on the difficulty mechanism of Bitcoin, offering both an official publication and a preprint without paywall. In closing, Daniel wished Florian good luck with his continued research on the subject. 2015-05-26T14:11:14+00:00 + Florian Tschorsch, a research scholar, noticed a lack of comprehensive survey papers on Bitcoin and decided to address this gap by creating a technical report. Seeking to contribute to the Bitcoin community, Florian shared the link (https://eprint.iacr.org/2015/464) to his report and invited readers to provide feedback for future revisions. One reader, Daniel, appreciated Florian's work and recommended another research paper co-authored by Joseph Bonneau, which focuses on Bitcoin. Additionally, Daniel promoted his own work on the difficulty mechanism of Bitcoin, offering both an official publication and a preprint without paywall. In closing, Daniel wished Florian good luck with his continued research on the subject. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Bitcoin-core-0-11-planning.xml b/static/bitcoin-dev/May_2015/combined_Bitcoin-core-0-11-planning.xml index 08d7c5c0f7..b50b1bbb30 100644 --- a/static/bitcoin-dev/May_2015/combined_Bitcoin-core-0-11-planning.xml +++ b/static/bitcoin-dev/May_2015/combined_Bitcoin-core-0-11-planning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin core 0.11 planning - 2023-08-01T12:19:46.279240+00:00 + 2025-10-11T22:10:27.375913+00:00 + python-feedgen Wladimir 2015-05-11 15:00:03+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Bitcoin core 0.11 planning - 2023-08-01T12:19:46.279240+00:00 + 2025-10-11T22:10:27.376043+00:00 - In an email dated April 28, 2015, Wladimir J. van der Laan proposed a schedule for the release of version 0.11 of Bitcoin Core. The proposed schedule includes a soft translation string freeze on May 1, opening Transifex translations for 0.11, and finalizing and closing translation for 0.9. The feature and string freeze is scheduled for May 15. On June 1, the plan is to split off the 0.11 branch, tag and release 0.11.0rc1, and start merging for 0.12 on the master branch. The target is to release 0.11.0 final on July 1. Unlike previous releases, the intention is to be more strict about the dates. However, it is acknowledged that last-minute critical issues may affect the planning. It is also stated that the release will not be held up for features, and anything that does not make it to 0.11 will be postponed to the next release scheduled for the end of the year.In another email, it is mentioned that the soonest implementation of CHECKLOCKTIMEVERIFY on Bitcoin will be around summer 2016. This feature has already been adopted on Viacoin and a few other altcoins. To accelerate the adoption of CHECKLOCKTIMEVERIFY, it is suggested to release a v0.12 with just a CLTV soft-fork as soon as the BIP66 softfork triggers. The main reason for accelerating CLTV is scalability, as it provides robust fixes for scalability issues. It is noted that payment channel schemes can start with Jeremy Spilman's scheme and later transition to CLTV, but this would require writing extra code that may later become deprecated.The proposed schedule for the release of version 0.11 has been shared with the community. The deadline for the soft translation string freeze, opening Transifex translations for 0.11, and finalizing and closing translation for 0.9 is set for May 1. The feature and string freeze will take place on May 15. On June 1, the plan is to split off the 0.11 branch, tag and release 0.11.0rc1, and start merging for 0.12 on the master branch. The aim is to release 0.11.0 final on July 1. While there is an intention to be more strict about the dates, it is acknowledged that last-minute critical issues could impact the planning. However, the release will not be delayed for features, and anything that does not make it to 0.11 will be postponed to the next release scheduled for the end of the year. 2015-05-11T15:00:03+00:00 + In an email dated April 28, 2015, Wladimir J. van der Laan proposed a schedule for the release of version 0.11 of Bitcoin Core. The proposed schedule includes a soft translation string freeze on May 1, opening Transifex translations for 0.11, and finalizing and closing translation for 0.9. The feature and string freeze is scheduled for May 15. On June 1, the plan is to split off the 0.11 branch, tag and release 0.11.0rc1, and start merging for 0.12 on the master branch. The target is to release 0.11.0 final on July 1. Unlike previous releases, the intention is to be more strict about the dates. However, it is acknowledged that last-minute critical issues may affect the planning. It is also stated that the release will not be held up for features, and anything that does not make it to 0.11 will be postponed to the next release scheduled for the end of the year.In another email, it is mentioned that the soonest implementation of CHECKLOCKTIMEVERIFY on Bitcoin will be around summer 2016. This feature has already been adopted on Viacoin and a few other altcoins. To accelerate the adoption of CHECKLOCKTIMEVERIFY, it is suggested to release a v0.12 with just a CLTV soft-fork as soon as the BIP66 softfork triggers. The main reason for accelerating CLTV is scalability, as it provides robust fixes for scalability issues. It is noted that payment channel schemes can start with Jeremy Spilman's scheme and later transition to CLTV, but this would require writing extra code that may later become deprecated.The proposed schedule for the release of version 0.11 has been shared with the community. The deadline for the soft translation string freeze, opening Transifex translations for 0.11, and finalizing and closing translation for 0.9 is set for May 1. The feature and string freeze will take place on May 15. On June 1, the plan is to split off the 0.11 branch, tag and release 0.11.0rc1, and start merging for 0.12 on the master branch. The aim is to release 0.11.0 final on July 1. While there is an intention to be more strict about the dates, it is acknowledged that last-minute critical issues could impact the planning. However, the release will not be delayed for features, and anything that does not make it to 0.11 will be postponed to the next release scheduled for the end of the year. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Bitcoin-development-Digest-Vol-48-Issue-41.xml b/static/bitcoin-dev/May_2015/combined_Bitcoin-development-Digest-Vol-48-Issue-41.xml index ef2b95eea4..0afddeab4b 100644 --- a/static/bitcoin-dev/May_2015/combined_Bitcoin-development-Digest-Vol-48-Issue-41.xml +++ b/static/bitcoin-dev/May_2015/combined_Bitcoin-development-Digest-Vol-48-Issue-41.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin-development Digest, Vol 48, Issue 41 - 2023-08-01T12:35:58.904554+00:00 + 2025-10-11T22:09:17.152975+00:00 + python-feedgen Peter Todd 2015-05-09 16:39:24+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Bitcoin-development Digest, Vol 48, Issue 41 - 2023-08-01T12:35:58.904554+00:00 + 2025-10-11T22:09:17.153103+00:00 - In an email conversation, Gregory Maxwell and Damian Gomez discuss the implementation of a block size that minimizes transaction fees. Gomez suggests using weight to represent the total number of semantic constraints expressed by individuals through emotive packets to implement a greater block size that prevents interception of bundled information and replaces value. Maxwell notes similarities between Gomez's AES ModuleK Hashcodes and Mr. NASDAQEnema's 2012 proposal on multigenerational token architectures. He also shares his thesis paper on the creation of imitations of reality with the mathematical technique of Bolshevik Statistics as a potential aid for Gomez.Damian Gomez sent an email discussing DH_GENERATION and adding a ternary option to the DH key. He also discussed using weight to implement a block size that prevents interception of bundled information and replacing value. This would reduce transaction fees and the need for e-wallet providers to implement additional 264-bit implementations. The writer notes that this work is similar to a proposal by Mr. NASDAQEnema of Bitcointalk in 2012 concerning multigenerational token architectures, specifically, AES ModuleK Hashcodes. The writer also references a publication by Virtuli Beatnik and suggests that he may be an ideal collaborator for Damian's work.The email thread primarily discusses the implementation of a Merkle-Winternitz OTS to prevent the loss of fee structure through the use of a security hash. This will enable a one-way transaction to continue following the TESLA protocol. Additionally, it is suggested that DH key construction could be an alternative to the BIP X509 protocol. The weight of the total number of semantical constraints expressed through emotive packets is represented by "w". The discussion then shifts towards the appropriate route to implementing a greater block size in order to prevent interception of bundled information and the replacement of value. A code snippet is included in the email for reference.In a separate conversation on the Bitcoin-development mailing list, the issue of increasing block size is discussed. Aaron Voisine expresses support for Gavin's 20MB block proposal, arguing that hard limits on block size would negatively impact user experience. Instead, Voisine suggests that fee pressure should be used to economize on scarce resources. Damian Gomez proposes a blockchain within 200-300 bytes and adding encryption standards to increase the system's integrity level. Raystonn proposes replace-by-fee as a better approach to zombie transactions due to insufficient fees, but acknowledges the potential for huge fee spikes or a return to zombie transactions if fee caps are implemented by wallets. Mark Friedenbach notes that replace-by-fee is no longer reorg-safe because transactions can expire during a reorg, invalidating any transaction built on an expired transaction. Finally, Raystonn proposes an alternative feature that expires a transaction after a specific time, but acknowledges that time can be unreliable in the blockchain.The email thread is focused on various aspects of Bitcoin development, with discussions ranging from transaction security and softfork signaling to proposals for wallet transactions with expiration times and block size increases. One message raises concerns about man-in-the-middle attacks on Bitcoin transactions due to the current BIP7 protocol, which could compromise the system's security. The suggested solution is to keep the block size under 300 bytes.In response to this issue, Raystonn proposes a "Replace by Fee" feature to replace zombie transactions with higher fees. However, some members of the thread express concern that this feature could lead to fee spikes or a return to zombie transactions if fee caps are implemented by wallets. Another message suggests an alternative feature that would allow for transaction expiration after a specific time, but acknowledges that time can be unreliable on the blockchain.The discussion also includes proposals for improving softfork signaling and allowing multiple softforks to be deployed simultaneously. Additionally, there is a proposal for wallets to create transactions with an expiration time starting with a low fee and then replacing them with new transactions that have a higher fee as time passes. The author of a popular SPV wallet supports Gavin's 20Mb block proposal as a way to avoid transactions hanging in limbo for days before failing.Finally, the thread discusses the possibility of adding encryption standards to the blockchain, such as DH algorithm keys, which would allow for a higher integrity level within the system. Overall, the email thread highlights several potential solutions and concerns regarding the block size increase in Bitcoin.The email conversation among Bitcoin developers revolves around several topics related to Bitcoin development. One of the main discussions is about increasing the block size. Aaron Voisine, the co-founder and CEO of breadwallet.com, supports Gavin's 20Mb block proposal, arguing that placing hard limits on block size will severely negatively impact users' experience. There is also a discussion about Softfork signaling improvements. Douglas Roark inquires if Pieter has a new proposal for allowing multiple softforks to be deployed at the same time. The developers also discuss replace-by-fee and transaction expiration time. Mark Friedenbach explains that periodically 2015-05-09T16:39:24+00:00 + In an email conversation, Gregory Maxwell and Damian Gomez discuss the implementation of a block size that minimizes transaction fees. Gomez suggests using weight to represent the total number of semantic constraints expressed by individuals through emotive packets to implement a greater block size that prevents interception of bundled information and replaces value. Maxwell notes similarities between Gomez's AES ModuleK Hashcodes and Mr. NASDAQEnema's 2012 proposal on multigenerational token architectures. He also shares his thesis paper on the creation of imitations of reality with the mathematical technique of Bolshevik Statistics as a potential aid for Gomez.Damian Gomez sent an email discussing DH_GENERATION and adding a ternary option to the DH key. He also discussed using weight to implement a block size that prevents interception of bundled information and replacing value. This would reduce transaction fees and the need for e-wallet providers to implement additional 264-bit implementations. The writer notes that this work is similar to a proposal by Mr. NASDAQEnema of Bitcointalk in 2012 concerning multigenerational token architectures, specifically, AES ModuleK Hashcodes. The writer also references a publication by Virtuli Beatnik and suggests that he may be an ideal collaborator for Damian's work.The email thread primarily discusses the implementation of a Merkle-Winternitz OTS to prevent the loss of fee structure through the use of a security hash. This will enable a one-way transaction to continue following the TESLA protocol. Additionally, it is suggested that DH key construction could be an alternative to the BIP X509 protocol. The weight of the total number of semantical constraints expressed through emotive packets is represented by "w". The discussion then shifts towards the appropriate route to implementing a greater block size in order to prevent interception of bundled information and the replacement of value. A code snippet is included in the email for reference.In a separate conversation on the Bitcoin-development mailing list, the issue of increasing block size is discussed. Aaron Voisine expresses support for Gavin's 20MB block proposal, arguing that hard limits on block size would negatively impact user experience. Instead, Voisine suggests that fee pressure should be used to economize on scarce resources. Damian Gomez proposes a blockchain within 200-300 bytes and adding encryption standards to increase the system's integrity level. Raystonn proposes replace-by-fee as a better approach to zombie transactions due to insufficient fees, but acknowledges the potential for huge fee spikes or a return to zombie transactions if fee caps are implemented by wallets. Mark Friedenbach notes that replace-by-fee is no longer reorg-safe because transactions can expire during a reorg, invalidating any transaction built on an expired transaction. Finally, Raystonn proposes an alternative feature that expires a transaction after a specific time, but acknowledges that time can be unreliable in the blockchain.The email thread is focused on various aspects of Bitcoin development, with discussions ranging from transaction security and softfork signaling to proposals for wallet transactions with expiration times and block size increases. One message raises concerns about man-in-the-middle attacks on Bitcoin transactions due to the current BIP7 protocol, which could compromise the system's security. The suggested solution is to keep the block size under 300 bytes.In response to this issue, Raystonn proposes a "Replace by Fee" feature to replace zombie transactions with higher fees. However, some members of the thread express concern that this feature could lead to fee spikes or a return to zombie transactions if fee caps are implemented by wallets. Another message suggests an alternative feature that would allow for transaction expiration after a specific time, but acknowledges that time can be unreliable on the blockchain.The discussion also includes proposals for improving softfork signaling and allowing multiple softforks to be deployed simultaneously. Additionally, there is a proposal for wallets to create transactions with an expiration time starting with a low fee and then replacing them with new transactions that have a higher fee as time passes. The author of a popular SPV wallet supports Gavin's 20Mb block proposal as a way to avoid transactions hanging in limbo for days before failing.Finally, the thread discusses the possibility of adding encryption standards to the blockchain, such as DH algorithm keys, which would allow for a higher integrity level within the system. Overall, the email thread highlights several potential solutions and concerns regarding the block size increase in Bitcoin.The email conversation among Bitcoin developers revolves around several topics related to Bitcoin development. One of the main discussions is about increasing the block size. Aaron Voisine, the co-founder and CEO of breadwallet.com, supports Gavin's 20Mb block proposal, arguing that placing hard limits on block size will severely negatively impact users' experience. There is also a discussion about Softfork signaling improvements. Douglas Roark inquires if Pieter has a new proposal for allowing multiple softforks to be deployed at the same time. The developers also discuss replace-by-fee and transaction expiration time. Mark Friedenbach explains that periodically - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Bitcoin-transaction.xml b/static/bitcoin-dev/May_2015/combined_Bitcoin-transaction.xml index 2de06e5fb9..36c22840ab 100644 --- a/static/bitcoin-dev/May_2015/combined_Bitcoin-transaction.xml +++ b/static/bitcoin-dev/May_2015/combined_Bitcoin-transaction.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin transaction - 2023-08-01T12:40:33.594622+00:00 + 2025-10-11T22:10:33.745463+00:00 + python-feedgen Danny Thorpe 2015-05-12 18:40:31+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bitcoin transaction - 2023-08-01T12:40:33.594622+00:00 + 2025-10-11T22:10:33.745637+00:00 - The conversation in this context revolves around the technical details of colored coins in bitcoin transactions. The Open Assets protocol specification is referenced for more information on how a colored coin is represented in a transaction. CoinPrism.com has a discussion forum where some colored coin developers hang out, and coinprism.info is a blockchain explorer that is colored-coin aware.The original question posed is about the technical difference between a bitcoin transaction and a colored coins transaction. One reply states that there is no difference to the transaction itself, but rather the inputs/outputs have a special meaning and order in colored coins transactions.In an email sent to the Bitcoin Dev mailing list on May 12, 2015, Telephone Lemien asked for technical details on the differences between a regular Bitcoin transaction and a colored coins transaction. Patrick Mccorry responded, stating that there is no difference to the transaction itself, but rather the inputs and outputs have a special meaning and order in colored coins transactions. He also mentioned that it is possible to track one BTC throughout the blockchain as representing an asset.The original poster thanked Mccorry for his input and requested more details on the inputs/outputs and how to proceed in the code.Bitcoin transactions are the primary method for transferring value over the Bitcoin network. They involve the transfer of bitcoins from one address to another, with each transaction being verified and recorded on the blockchain. Colored coins, on the other hand, are a way of representing assets or tokens on top of the Bitcoin network.The main difference between Bitcoin transactions and colored coins transactions lies in their purpose and functionality. Bitcoin transactions are used for the transfer of the cryptocurrency itself, while colored coins transactions are used to represent and transfer other types of assets. In a colored coins transaction, the sender "colors" a certain amount of bitcoins to represent the asset they wish to transfer. This colored bitcoin can then be transferred to the recipient, who can redeem it for the underlying asset.From a technical standpoint, Bitcoin transactions and colored coins transactions share many similarities. Both types of transactions involve the creation of a digital signature using a private key, which is then broadcast to the network and verified by other nodes. However, there are some key differences in the specific data included in each type of transaction, such as the inclusion of metadata in colored coins transactions to indicate the type of asset being transferred.In summary, while Bitcoin transactions and colored coins transactions share some similarities in their underlying mechanics, they serve fundamentally different purposes. Bitcoin transactions are used for the transfer of the cryptocurrency itself, while colored coins transactions are used to represent and transfer other types of assets on top of the Bitcoin network. 2015-05-12T18:40:31+00:00 + The conversation in this context revolves around the technical details of colored coins in bitcoin transactions. The Open Assets protocol specification is referenced for more information on how a colored coin is represented in a transaction. CoinPrism.com has a discussion forum where some colored coin developers hang out, and coinprism.info is a blockchain explorer that is colored-coin aware.The original question posed is about the technical difference between a bitcoin transaction and a colored coins transaction. One reply states that there is no difference to the transaction itself, but rather the inputs/outputs have a special meaning and order in colored coins transactions.In an email sent to the Bitcoin Dev mailing list on May 12, 2015, Telephone Lemien asked for technical details on the differences between a regular Bitcoin transaction and a colored coins transaction. Patrick Mccorry responded, stating that there is no difference to the transaction itself, but rather the inputs and outputs have a special meaning and order in colored coins transactions. He also mentioned that it is possible to track one BTC throughout the blockchain as representing an asset.The original poster thanked Mccorry for his input and requested more details on the inputs/outputs and how to proceed in the code.Bitcoin transactions are the primary method for transferring value over the Bitcoin network. They involve the transfer of bitcoins from one address to another, with each transaction being verified and recorded on the blockchain. Colored coins, on the other hand, are a way of representing assets or tokens on top of the Bitcoin network.The main difference between Bitcoin transactions and colored coins transactions lies in their purpose and functionality. Bitcoin transactions are used for the transfer of the cryptocurrency itself, while colored coins transactions are used to represent and transfer other types of assets. In a colored coins transaction, the sender "colors" a certain amount of bitcoins to represent the asset they wish to transfer. This colored bitcoin can then be transferred to the recipient, who can redeem it for the underlying asset.From a technical standpoint, Bitcoin transactions and colored coins transactions share many similarities. Both types of transactions involve the creation of a digital signature using a private key, which is then broadcast to the network and verified by other nodes. However, there are some key differences in the specific data included in each type of transaction, such as the inclusion of metadata in colored coins transactions to indicate the type of asset being transferred.In summary, while Bitcoin transactions and colored coins transactions share some similarities in their underlying mechanics, they serve fundamentally different purposes. Bitcoin transactions are used for the transfer of the cryptocurrency itself, while colored coins transactions are used to represent and transfer other types of assets on top of the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Block-Size-Increase-Requirements.xml b/static/bitcoin-dev/May_2015/combined_Block-Size-Increase-Requirements.xml index df233dbf72..c28423f2aa 100644 --- a/static/bitcoin-dev/May_2015/combined_Block-Size-Increase-Requirements.xml +++ b/static/bitcoin-dev/May_2015/combined_Block-Size-Increase-Requirements.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block Size Increase Requirements - 2023-08-01T12:25:51.961940+00:00 + 2025-10-11T22:09:15.027676+00:00 + python-feedgen Jorge Timón 2015-05-31 15:45:01+00:00 @@ -127,13 +128,13 @@ - python-feedgen + 2 Combined summary - Block Size Increase Requirements - 2023-08-01T12:25:51.961940+00:00 + 2025-10-11T22:09:15.027891+00:00 - There have been discussions among Bitcoin developers regarding the block size increase and its implications. One concern raised is the difference in bandwidth costs between 2MB and 20MB blocks, particularly in China where server bandwidth is more expensive. F2Pool, a Chinese pool, supports an increase in block size but cannot handle 20MB blocks due to potential orphan rate issues. Other Chinese pools, such as AntPool and BW, are less concerned about this issue.Matt Corallo expresses concerns about committing to a block size increase without addressing other important factors. He believes that better technologies should be implemented to decrease block propagation latency and improve scaling. He also wants to see better conclusions regarding long-term incentives within the system. Gavin Andresen responds by questioning the connection between the max block size and the need for better scaling technology. He argues that if block propagation isn't fixed, miners will create smaller blocks regardless of the maximum block size.In an email exchange, Peter Todd proposes the idea of having a "miner" flag for the Bitcoin network. However, concerns are raised about the potential risks it poses, such as making it easier to find miners and perform denial-of-service attacks on them. To mitigate against these risks, suggestions are made to track two chaintips - the miner tip and the client tip - and to reject certain block sizes when in "miner mode". However, there are concerns about the increased chance of double-spending merchants.Another proposal discussed is the idea of counting transactions differently to mitigate delays in confirmations. This would involve penalties for blocks that do not meet the stricter rules set by miners. The email conversation ends with a suggestion to add "minermaxblocksize=4MB" to the bitcoin.conf file to speed up transactions.The topic of block propagation latency is also raised in the discussions. While there are proposals to decrease latency, none have been implemented yet. There are concerns about the soft limit's effectiveness in controlling block sizes and the potential for miners to harm competition with 20MB blocks. One company, StrawPay, is working on developing better scaling technology with code available on Github.In another email exchange, Gregory Maxwell expresses concern over the sudden push for a block size increase without proper communication on Github. He argues that block size increases primarily benefit miners at the expense of reduced security or higher operating costs for nodes. He also raises concerns about mining centralization being a bigger systemic risk than a block size increase. He emphasizes the importance of including non-"industry" voices in discussions and considering alternative proposals like the lightning network.Matt Corallo shares his concerns about committing to a block size increase in an email to the Bitcoin Development mailing list. He highlights the need to address issues such as block propagation latency and ensuring miners don't cheat and stop validating blocks fully. He also calls for better conclusions regarding long-term incentives within the system.The email conversation between Matt Corallo and Joseph Poon focuses on the need for a discussion on how to approach the problem of a block size increase. Corallo emphasizes the importance of real free pressure already developing on the network before committing to hardforking. Poon agrees and suggests a coinbase voting protocol for soft-cap enforcement. The Lightning Network's security model may rely on a multi-tier soft-cap. They agree that discussion and resolution of blocking concerns are necessary.Overall, there are various proposals and concerns surrounding the block size increase in Bitcoin. Issues such as block propagation latency, miner behavior, long-term incentives, and security risks need to be addressed before a consensus can be reached.In order to address the challenges faced by the blockchain industry, it is widely acknowledged that better scaling technology is crucial. This applies not only to the development of such technology but also to its adoption by major players in the marketplace. By improving scalability, blockchain networks can accommodate larger transaction volumes and enhance their overall efficiency.Another key area that requires attention is the discussion surrounding long-term incentives within the system. It is important to develop software solutions that effectively handle fees across the entire blockchain ecosystem. Proper fee management is essential for creating a sustainable and economically viable environment for all participants.Although progress has been made in these areas, they are still considered to be in their early stages of development. Further advancements and refinements are needed to fully address the challenges at hand. In support of this perspective, Jeff Garzik shares Corallo's proposal and emphasizes the importance of looking ahead rather than dwelling on the past.By focusing on moving forward and investing in the necessary improvements, the blockchain industry can overcome its current limitations and pave the way for a more scalable and efficient future. It is through continued collaboration and innovation that the potential of blockchain technology can be fully realized. 2015-05-31T15:45:01+00:00 + There have been discussions among Bitcoin developers regarding the block size increase and its implications. One concern raised is the difference in bandwidth costs between 2MB and 20MB blocks, particularly in China where server bandwidth is more expensive. F2Pool, a Chinese pool, supports an increase in block size but cannot handle 20MB blocks due to potential orphan rate issues. Other Chinese pools, such as AntPool and BW, are less concerned about this issue.Matt Corallo expresses concerns about committing to a block size increase without addressing other important factors. He believes that better technologies should be implemented to decrease block propagation latency and improve scaling. He also wants to see better conclusions regarding long-term incentives within the system. Gavin Andresen responds by questioning the connection between the max block size and the need for better scaling technology. He argues that if block propagation isn't fixed, miners will create smaller blocks regardless of the maximum block size.In an email exchange, Peter Todd proposes the idea of having a "miner" flag for the Bitcoin network. However, concerns are raised about the potential risks it poses, such as making it easier to find miners and perform denial-of-service attacks on them. To mitigate against these risks, suggestions are made to track two chaintips - the miner tip and the client tip - and to reject certain block sizes when in "miner mode". However, there are concerns about the increased chance of double-spending merchants.Another proposal discussed is the idea of counting transactions differently to mitigate delays in confirmations. This would involve penalties for blocks that do not meet the stricter rules set by miners. The email conversation ends with a suggestion to add "minermaxblocksize=4MB" to the bitcoin.conf file to speed up transactions.The topic of block propagation latency is also raised in the discussions. While there are proposals to decrease latency, none have been implemented yet. There are concerns about the soft limit's effectiveness in controlling block sizes and the potential for miners to harm competition with 20MB blocks. One company, StrawPay, is working on developing better scaling technology with code available on Github.In another email exchange, Gregory Maxwell expresses concern over the sudden push for a block size increase without proper communication on Github. He argues that block size increases primarily benefit miners at the expense of reduced security or higher operating costs for nodes. He also raises concerns about mining centralization being a bigger systemic risk than a block size increase. He emphasizes the importance of including non-"industry" voices in discussions and considering alternative proposals like the lightning network.Matt Corallo shares his concerns about committing to a block size increase in an email to the Bitcoin Development mailing list. He highlights the need to address issues such as block propagation latency and ensuring miners don't cheat and stop validating blocks fully. He also calls for better conclusions regarding long-term incentives within the system.The email conversation between Matt Corallo and Joseph Poon focuses on the need for a discussion on how to approach the problem of a block size increase. Corallo emphasizes the importance of real free pressure already developing on the network before committing to hardforking. Poon agrees and suggests a coinbase voting protocol for soft-cap enforcement. The Lightning Network's security model may rely on a multi-tier soft-cap. They agree that discussion and resolution of blocking concerns are necessary.Overall, there are various proposals and concerns surrounding the block size increase in Bitcoin. Issues such as block propagation latency, miner behavior, long-term incentives, and security risks need to be addressed before a consensus can be reached.In order to address the challenges faced by the blockchain industry, it is widely acknowledged that better scaling technology is crucial. This applies not only to the development of such technology but also to its adoption by major players in the marketplace. By improving scalability, blockchain networks can accommodate larger transaction volumes and enhance their overall efficiency.Another key area that requires attention is the discussion surrounding long-term incentives within the system. It is important to develop software solutions that effectively handle fees across the entire blockchain ecosystem. Proper fee management is essential for creating a sustainable and economically viable environment for all participants.Although progress has been made in these areas, they are still considered to be in their early stages of development. Further advancements and refinements are needed to fully address the challenges at hand. In support of this perspective, Jeff Garzik shares Corallo's proposal and emphasizes the importance of looking ahead rather than dwelling on the past.By focusing on moving forward and investing in the necessary improvements, the blockchain industry can overcome its current limitations and pave the way for a more scalable and efficient future. It is through continued collaboration and innovation that the potential of blockchain technology can be fully realized. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Block-Size-Increase.xml b/static/bitcoin-dev/May_2015/combined_Block-Size-Increase.xml index c0ad04a922..4f0b983626 100644 --- a/static/bitcoin-dev/May_2015/combined_Block-Size-Increase.xml +++ b/static/bitcoin-dev/May_2015/combined_Block-Size-Increase.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Block Size Increase - 2023-08-01T12:23:55.593342+00:00 + 2025-10-11T22:09:53.365560+00:00 + python-feedgen Angel Leon 2015-05-13 11:25:47+00:00 @@ -463,13 +464,13 @@ - python-feedgen + 2 Combined summary - Block Size Increase - 2023-08-01T12:23:55.598282+00:00 + 2025-10-11T22:09:53.365921+00:00 - The Bitcoin community is engaged in a debate about the block size limit and the need for its increase. Some argue that the current limit of 1MB is insufficient for meaningful commercial activity, while others express concerns about potential centralization risks. The discussion includes proposals for larger block sizes, such as 20MB or even 100MB, to accommodate higher transaction volumes. There are debates about the trade-offs between scalability and decentralization, with some suggesting dynamic limits for block size based on demand and fees offered.The importance of consensus among developers is discussed, with suggestions for more inclusive decision-making processes. It is emphasized that decisions regarding block size should consider long-term solutions and avoid simply picking arbitrary numbers. The need for more research and software development to support larger block sizes is suggested. Additionally, there are discussions about the impact of block intervals and the consequences of running out of capacity in the Bitcoin network. Overall, the context highlights the challenges and debates surrounding Bitcoin's scalability and the need to find a balance between transaction capacity, decentralization, and adoption.Gavin Andresen argues for an urgent increase in the block size, citing the current limit of 1MB as insufficient for meaningful commercial activity. Mike Hearn agrees with the urgency of raising the block size and emphasizes the need for more research and software development to support larger block sizes. There are debates about the timing and methodology of a hard fork, with differing opinions on the need for "universally uncontroversial" agreement and the role of market conditions. Concerns are raised about the potential economic implications of increasing the block size and the need to avoid creating winners and losers.Various individuals express their perspectives and concerns regarding the block size increase. Some argue for a rigorous system for instant transactions and the need for a clear plan, while others advocate for waiting to see if full blocks occur and a true fee market emerges. There are disagreements on whether consensus is possible in the Bitcoin community on protocol-related matters. Concerns are raised about the consequences of increasing the block size, such as pushing people away from running their own full nodes and increasing external costs for users. The importance of scalability and accurate advice on blockchain's scalability is emphasized.The ongoing discussion about increasing the maximum block size for Bitcoin involves debates about centralization risks, security implications, orphan rate, fee competition, and the impact on miners. There are discussions about the potential consequences of not increasing the block size, including transaction confirmation times, security implications, and the possible impact on miners at the next block reward halving. Various individuals express their opinions and concerns regarding the block size increase, with differing perspectives on the timing and necessity of a hard fork. Concerns are raised about the potential security risks of increasing the block size and the need to prioritize safety and consider the nature of the system itself.The debate surrounding the block size increase involves considerations of scalability, decentralization, consensus, and the development of Bitcoin. It is acknowledged that finding a concrete course of action that everyone can agree upon is challenging but necessary. The importance of research, compromise, and clarity in decision-making is emphasized to ensure the future success of the cryptocurrency. The ongoing discussions and debates within the Bitcoin community highlight the complexity of the block size issue and the need for careful consideration of technical trade-offs. 2015-05-13T11:25:47+00:00 + The Bitcoin community is engaged in a debate about the block size limit and the need for its increase. Some argue that the current limit of 1MB is insufficient for meaningful commercial activity, while others express concerns about potential centralization risks. The discussion includes proposals for larger block sizes, such as 20MB or even 100MB, to accommodate higher transaction volumes. There are debates about the trade-offs between scalability and decentralization, with some suggesting dynamic limits for block size based on demand and fees offered.The importance of consensus among developers is discussed, with suggestions for more inclusive decision-making processes. It is emphasized that decisions regarding block size should consider long-term solutions and avoid simply picking arbitrary numbers. The need for more research and software development to support larger block sizes is suggested. Additionally, there are discussions about the impact of block intervals and the consequences of running out of capacity in the Bitcoin network. Overall, the context highlights the challenges and debates surrounding Bitcoin's scalability and the need to find a balance between transaction capacity, decentralization, and adoption.Gavin Andresen argues for an urgent increase in the block size, citing the current limit of 1MB as insufficient for meaningful commercial activity. Mike Hearn agrees with the urgency of raising the block size and emphasizes the need for more research and software development to support larger block sizes. There are debates about the timing and methodology of a hard fork, with differing opinions on the need for "universally uncontroversial" agreement and the role of market conditions. Concerns are raised about the potential economic implications of increasing the block size and the need to avoid creating winners and losers.Various individuals express their perspectives and concerns regarding the block size increase. Some argue for a rigorous system for instant transactions and the need for a clear plan, while others advocate for waiting to see if full blocks occur and a true fee market emerges. There are disagreements on whether consensus is possible in the Bitcoin community on protocol-related matters. Concerns are raised about the consequences of increasing the block size, such as pushing people away from running their own full nodes and increasing external costs for users. The importance of scalability and accurate advice on blockchain's scalability is emphasized.The ongoing discussion about increasing the maximum block size for Bitcoin involves debates about centralization risks, security implications, orphan rate, fee competition, and the impact on miners. There are discussions about the potential consequences of not increasing the block size, including transaction confirmation times, security implications, and the possible impact on miners at the next block reward halving. Various individuals express their opinions and concerns regarding the block size increase, with differing perspectives on the timing and necessity of a hard fork. Concerns are raised about the potential security risks of increasing the block size and the need to prioritize safety and consider the nature of the system itself.The debate surrounding the block size increase involves considerations of scalability, decentralization, consensus, and the development of Bitcoin. It is acknowledged that finding a concrete course of action that everyone can agree upon is challenging but necessary. The importance of research, compromise, and clarity in decision-making is emphasized to ensure the future success of the cryptocurrency. The ongoing discussions and debates within the Bitcoin community highlight the complexity of the block size issue and the need for careful consideration of technical trade-offs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_CLTV-opcode-allocation-long-term-plans-.xml b/static/bitcoin-dev/May_2015/combined_CLTV-opcode-allocation-long-term-plans-.xml index c28cef02d4..f5597eb751 100644 --- a/static/bitcoin-dev/May_2015/combined_CLTV-opcode-allocation-long-term-plans-.xml +++ b/static/bitcoin-dev/May_2015/combined_CLTV-opcode-allocation-long-term-plans-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CLTV opcode allocation; long-term plans? - 2023-08-01T12:21:21.539533+00:00 + 2025-10-11T22:10:14.630147+00:00 + python-feedgen Jorge Timón 2015-05-13 00:38:44+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - CLTV opcode allocation; long-term plans? - 2023-08-01T12:21:21.539533+00:00 + 2025-10-11T22:10:14.630368+00:00 - In a discussion about the implementation of RCLTV (Relative CheckLockTimeVerify) in Bitcoin, there are different opinions on how to approach the issue. One suggestion is to use negative numbers for the RCLTV instead of the current proposal, as it would not require larger scripts. However, this approach may make handling the year 2038 problem more complex and could lead to ambiguity in the codebase.Luke Dashjr proposed implementing a softfork of RCLTV as a negative CLTV, which would define negative numbers as relative later. This solution is considered straightforward, as all nLockTime values are greater than or equal to any negative number, making CLTV a no-op. The use of negative numbers is not new and should be familiar to developers, especially those with experience in Python. This approach would allow for more flexibility and control in the softforking process.There is also a discussion on whether to use NOPs in Bitcoin's implementation of CheckLockTimeVerify (CLTV) opcode. Some developers argue that using the original unparameterized CLTV version would be better tested and result in a slightly smaller script. On the other hand, adding a parameter to OP_CLTV would make it more flexible and economically feasible. Despite the extra work required to update tests, example code, and the BIP, it is deemed acceptable and necessary for the feature freeze. The use of separate opcodes is also considered, but there are concerns about fitting them into the current CLTV argument structure.Peter Todd suggests adding a parameter to OP_CLTV, which would be the most economical use of NOPs. He believes that the necessary changes can be made in time for the feature freeze and provides a link to the pull request with the suggested changes. Btc Drak agrees with this proposal and emphasizes the importance of making the change before the feature freeze.Another proposal is to use '1' to select absolute mode in OP_CLTV, while all other entries act as NOPs. This would allow for the future implementation of relative CLTV as a soft-fork by using '2' instead of '1'. Rusty Russell suggests an alternative approach, where OP_NOP1 becomes an OP_EXTENSION_PREFIX and the following opcode defines which extended opcode it is. However, this approach is considered complex and difficult to implement.In another email exchange, Peter Todd and Matt Corallo discuss the issue of OP_NOP scarcity in the Bitcoin mempool. Todd suggests that adding a parameter to OP_CLTV would make it more flexible and efficient, despite requiring some extra time and effort to update tests and example code. Corallo raises concerns about complicating the codebase compared to sticking with Script v2.0, but overall, the proposed change is not seen as a big deal.Overall, the discussions revolve around finding the most effective and efficient way to implement RCLTV in Bitcoin. There are different proposals, including using negative numbers, adding parameters to OP_CLTV, or using separate opcodes. The developers acknowledge the potential challenges and complexities involved in making these changes but believe that they are necessary for the improvement of the protocol. 2015-05-13T00:38:44+00:00 + In a discussion about the implementation of RCLTV (Relative CheckLockTimeVerify) in Bitcoin, there are different opinions on how to approach the issue. One suggestion is to use negative numbers for the RCLTV instead of the current proposal, as it would not require larger scripts. However, this approach may make handling the year 2038 problem more complex and could lead to ambiguity in the codebase.Luke Dashjr proposed implementing a softfork of RCLTV as a negative CLTV, which would define negative numbers as relative later. This solution is considered straightforward, as all nLockTime values are greater than or equal to any negative number, making CLTV a no-op. The use of negative numbers is not new and should be familiar to developers, especially those with experience in Python. This approach would allow for more flexibility and control in the softforking process.There is also a discussion on whether to use NOPs in Bitcoin's implementation of CheckLockTimeVerify (CLTV) opcode. Some developers argue that using the original unparameterized CLTV version would be better tested and result in a slightly smaller script. On the other hand, adding a parameter to OP_CLTV would make it more flexible and economically feasible. Despite the extra work required to update tests, example code, and the BIP, it is deemed acceptable and necessary for the feature freeze. The use of separate opcodes is also considered, but there are concerns about fitting them into the current CLTV argument structure.Peter Todd suggests adding a parameter to OP_CLTV, which would be the most economical use of NOPs. He believes that the necessary changes can be made in time for the feature freeze and provides a link to the pull request with the suggested changes. Btc Drak agrees with this proposal and emphasizes the importance of making the change before the feature freeze.Another proposal is to use '1' to select absolute mode in OP_CLTV, while all other entries act as NOPs. This would allow for the future implementation of relative CLTV as a soft-fork by using '2' instead of '1'. Rusty Russell suggests an alternative approach, where OP_NOP1 becomes an OP_EXTENSION_PREFIX and the following opcode defines which extended opcode it is. However, this approach is considered complex and difficult to implement.In another email exchange, Peter Todd and Matt Corallo discuss the issue of OP_NOP scarcity in the Bitcoin mempool. Todd suggests that adding a parameter to OP_CLTV would make it more flexible and efficient, despite requiring some extra time and effort to update tests and example code. Corallo raises concerns about complicating the codebase compared to sticking with Script v2.0, but overall, the proposed change is not seen as a big deal.Overall, the discussions revolve around finding the most effective and efficient way to implement RCLTV in Bitcoin. There are different proposals, including using negative numbers, adding parameters to OP_CLTV, or using separate opcodes. The developers acknowledge the potential challenges and complexities involved in making these changes but believe that they are necessary for the improvement of the protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_ChainDB-Whitepaper.xml b/static/bitcoin-dev/May_2015/combined_ChainDB-Whitepaper.xml index cc9774cfce..d23f683036 100644 --- a/static/bitcoin-dev/May_2015/combined_ChainDB-Whitepaper.xml +++ b/static/bitcoin-dev/May_2015/combined_ChainDB-Whitepaper.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ChainDB Whitepaper - 2023-08-01T12:45:37.498713+00:00 + 2025-10-11T22:09:23.541131+00:00 + python-feedgen Peter Todd 2015-05-20 06:26:11+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - ChainDB Whitepaper - 2023-08-01T12:45:37.499712+00:00 + 2025-10-11T22:09:23.541293+00:00 - BitPay has recently unveiled its whitepaper on ChainDB, a novel peer-to-peer database system that utilizes the Bitcoin blockchain. The document outlines BitPay's proposed consensus mechanism, known as proof of fee. However, critics have voiced concerns regarding potential risks associated with this approach. They argue that miners may be inclined to sell the inclusion of "high-fee" transactions in blocks they mine for significantly lower amounts than the risk of blocks being orphaned, allowing other miners to collect those fees. To address these concerns, Peter Todd suggests implementing direct provably unspendable OP_RETURN sacrifices and making ChainDB chains private. Additionally, Todd emphasizes the need for a clear statement on ChainDB's objectives and what it aims to prevent from occurring. He also notes that while Bitcoin does not securely store data, it does verify the publication of data. The discussion also touches upon Zookeyv and Factom.In light of the aforementioned criticisms and uncertainties surrounding ChainDB, it remains unclear what exactly the proposal seeks to achieve and prevent. The use of transaction fees as "proof" poses inherent risks, prompting suggestions to explore alternative measures such as direct provably unspendable OP_RETURN sacrifices. Furthermore, it is recommended that ChainDB chains be kept private, accompanied by a comprehensive articulation of the system's goals. It should be noted that Bitcoin's primary function is not secure data storage but rather confirming the publication of data. Lastly, there are some comments pertaining to Zookeyv and Factom, although no further details are provided.For more information, interested individuals can access BitPay's whitepaper on ChainDB through the following link: https://bitpay.com/chaindb.pdf. Eric Martindale, BitPay's CTO, welcomes any inquiries or clarifications regarding the paper's content. 2015-05-20T06:26:11+00:00 + BitPay has recently unveiled its whitepaper on ChainDB, a novel peer-to-peer database system that utilizes the Bitcoin blockchain. The document outlines BitPay's proposed consensus mechanism, known as proof of fee. However, critics have voiced concerns regarding potential risks associated with this approach. They argue that miners may be inclined to sell the inclusion of "high-fee" transactions in blocks they mine for significantly lower amounts than the risk of blocks being orphaned, allowing other miners to collect those fees. To address these concerns, Peter Todd suggests implementing direct provably unspendable OP_RETURN sacrifices and making ChainDB chains private. Additionally, Todd emphasizes the need for a clear statement on ChainDB's objectives and what it aims to prevent from occurring. He also notes that while Bitcoin does not securely store data, it does verify the publication of data. The discussion also touches upon Zookeyv and Factom.In light of the aforementioned criticisms and uncertainties surrounding ChainDB, it remains unclear what exactly the proposal seeks to achieve and prevent. The use of transaction fees as "proof" poses inherent risks, prompting suggestions to explore alternative measures such as direct provably unspendable OP_RETURN sacrifices. Furthermore, it is recommended that ChainDB chains be kept private, accompanied by a comprehensive articulation of the system's goals. It should be noted that Bitcoin's primary function is not secure data storage but rather confirming the publication of data. Lastly, there are some comments pertaining to Zookeyv and Factom, although no further details are provided.For more information, interested individuals can access BitPay's whitepaper on ChainDB through the following link: https://bitpay.com/chaindb.pdf. Eric Martindale, BitPay's CTO, welcomes any inquiries or clarifications regarding the paper's content. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Consensus-enforced-transaction-replacement-via-sequence-numbers.xml b/static/bitcoin-dev/May_2015/combined_Consensus-enforced-transaction-replacement-via-sequence-numbers.xml index 977bc4c921..ae3dd56c0a 100644 --- a/static/bitcoin-dev/May_2015/combined_Consensus-enforced-transaction-replacement-via-sequence-numbers.xml +++ b/static/bitcoin-dev/May_2015/combined_Consensus-enforced-transaction-replacement-via-sequence-numbers.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Consensus-enforced transaction replacement via sequence numbers - 2023-08-01T12:52:23.999880+00:00 + 2025-10-11T22:10:31.622203+00:00 + python-feedgen Rusty Russell 2015-06-10 02:40:38+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Consensus-enforced transaction replacement via sequence numbers - 2023-08-01T12:52:24.000880+00:00 + 2025-10-11T22:10:31.622470+00:00 - In various discussions within the Bitcoin development community, the implementation and potential changes to the relative lock-time feature in Bitcoin transactions are being explored. Peter Todd suggests using the nLockTime field similarly to how cltv works, which would simplify the implementation process. The need for one or two Bitcoin Improvement Proposals (BIPs) for this change is also discussed.Mike Hearn and another participant discuss possible changes to the semantics of the nSequence field. Mike suggests gating any changes with a high bit to preserve the original meaning for resource scheduling and update flood damping. The other individual argues that their proposal maintains the semantics of Satoshi's original construction and allows higher sequence numbers to hit the chain earlier. They question if they have failed in capturing the original intent.Gregory Maxwell proposes a change to make sequence numbers work as expected within the bounds of a decentralized system. This involves using a new transaction version number to indicate the change from sequence number to relative lock time. While this would give sequence numbers a rational meaning, applying this rule to legacy transactions could render them unspendable. It is not considered "consensus enforcement" but rather relative nlocktime.The original intention of sequence numbers in Bitcoin was for transaction replacement in multi-party transaction construction, such as micropayment channels. However, the lack of enforcement by miners makes relying on a transaction replacement policy impossible. To address this issue, sequence numbers can be given new consensus-enforced semantics as a relative lock-time. An example implementation of this concept can be found on Github as a policy change to the mempool processing of Bitcoin Core.Overall, the use of relative nLockTime and the proposed changes to sequence numbers aim to improve the functionality and reliability of payment channels in Bitcoin. By giving sequence numbers new semantics and allowing for bidirectional channels, the limitations of the original sequence numbers can be overcome. This has the potential to enhance the efficiency and security of micropayments and other multi-party transactions in the Bitcoin network. 2015-06-10T02:40:38+00:00 + In various discussions within the Bitcoin development community, the implementation and potential changes to the relative lock-time feature in Bitcoin transactions are being explored. Peter Todd suggests using the nLockTime field similarly to how cltv works, which would simplify the implementation process. The need for one or two Bitcoin Improvement Proposals (BIPs) for this change is also discussed.Mike Hearn and another participant discuss possible changes to the semantics of the nSequence field. Mike suggests gating any changes with a high bit to preserve the original meaning for resource scheduling and update flood damping. The other individual argues that their proposal maintains the semantics of Satoshi's original construction and allows higher sequence numbers to hit the chain earlier. They question if they have failed in capturing the original intent.Gregory Maxwell proposes a change to make sequence numbers work as expected within the bounds of a decentralized system. This involves using a new transaction version number to indicate the change from sequence number to relative lock time. While this would give sequence numbers a rational meaning, applying this rule to legacy transactions could render them unspendable. It is not considered "consensus enforcement" but rather relative nlocktime.The original intention of sequence numbers in Bitcoin was for transaction replacement in multi-party transaction construction, such as micropayment channels. However, the lack of enforcement by miners makes relying on a transaction replacement policy impossible. To address this issue, sequence numbers can be given new consensus-enforced semantics as a relative lock-time. An example implementation of this concept can be found on Github as a policy change to the mempool processing of Bitcoin Core.Overall, the use of relative nLockTime and the proposed changes to sequence numbers aim to improve the functionality and reliability of payment channels in Bitcoin. By giving sequence numbers new semantics and allowing for bidirectional channels, the limitations of the original sequence numbers can be overcome. This has the potential to enhance the efficiency and security of micropayments and other multi-party transactions in the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Cost-savings-by-using-replace-by-fee-30-90-.xml b/static/bitcoin-dev/May_2015/combined_Cost-savings-by-using-replace-by-fee-30-90-.xml index 5df5852fdf..2caa258172 100644 --- a/static/bitcoin-dev/May_2015/combined_Cost-savings-by-using-replace-by-fee-30-90-.xml +++ b/static/bitcoin-dev/May_2015/combined_Cost-savings-by-using-replace-by-fee-30-90-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Cost savings by using replace-by-fee, 30-90% - 2023-08-01T12:48:52.188881+00:00 + 2025-10-11T22:10:10.370786+00:00 + python-feedgen s7r 2015-05-27 19:28:55+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Cost savings by using replace-by-fee, 30-90% - 2023-08-01T12:48:52.189880+00:00 + 2025-10-11T22:10:10.370936+00:00 - In the context of transaction fees in the blockchain industry, two methods that are commonly used are Replace By Fee (RBF) and defragmentation. When comparing the two approaches, it has been observed that RBF can be a more cost-effective method. RBF allows for the doubling of spending on a previous transaction while reducing the number of inputs and overall transaction size. This results in significantly lower fees when utilizing RBF compared to defragmentation. Cost savings can range from 30% to as much as 90%. In some cases, the cost savings through RBF may even be considered infinite if the expenses associated with defragmentation outweigh the benefits gained.Overall, RBF is considered a more efficient and cost-effective approach for handling transaction fees in these scenarios. It provides a way to optimize transaction costs efficiently, making it an attractive option for those looking to minimize fees in the blockchain industry. 2015-05-27T19:28:55+00:00 + In the context of transaction fees in the blockchain industry, two methods that are commonly used are Replace By Fee (RBF) and defragmentation. When comparing the two approaches, it has been observed that RBF can be a more cost-effective method. RBF allows for the doubling of spending on a previous transaction while reducing the number of inputs and overall transaction size. This results in significantly lower fees when utilizing RBF compared to defragmentation. Cost savings can range from 30% to as much as 90%. In some cases, the cost savings through RBF may even be considered infinite if the expenses associated with defragmentation outweigh the benefits gained.Overall, RBF is considered a more efficient and cost-effective approach for handling transaction fees in these scenarios. It provides a way to optimize transaction costs efficiently, making it an attractive option for those looking to minimize fees in the blockchain industry. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_First-Seen-Safe-Replace-by-Fee.xml b/static/bitcoin-dev/May_2015/combined_First-Seen-Safe-Replace-by-Fee.xml index 3721a8ed62..bdc520b933 100644 --- a/static/bitcoin-dev/May_2015/combined_First-Seen-Safe-Replace-by-Fee.xml +++ b/static/bitcoin-dev/May_2015/combined_First-Seen-Safe-Replace-by-Fee.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - First-Seen-Safe Replace-by-Fee - 2023-08-01T12:49:57.529715+00:00 + 2025-10-11T22:10:35.871545+00:00 + python-feedgen Peter Todd 2015-05-27 07:30:32+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 Combined summary - First-Seen-Safe Replace-by-Fee - 2023-08-01T12:49:57.529715+00:00 + 2025-10-11T22:10:35.871718+00:00 - The email discusses the use of Full Sequence Replace-By-Fee (FSS-RBF) in increasing fees on bitcoin transactions more efficiently than Child Pays For Parent (CPFP). In one case, adding a new input and increasing the change output value can result in cost savings ranging from 11% to 34%+. If an unspent output has a greater value than one of the outputs spent by the original transaction, it can be replaced, resulting in a 34% savings compared to CPFP. In another case, paying multiple recipients requires adding or swapping inputs, which can lead to overall savings of 25%. FSS-RBF can help reduce transaction size and increase cost savings. However, caution must be taken to ensure that at least one input remains unchanged after multiple rounds of this process.A discussion between Gregory Maxwell and Tom Harding addresses the potential risks of transaction replacement in Bitcoin. Harding raises concerns about certain payments being part of larger deals with unknown connections, which could cause issues if paying parties are kicked out or not informed immediately. Maxwell argues that multisig signers have already accepted the possibility of being written out and should not be considered less reliable. They also discuss Kalle's Proof of Payment proposed standard, where one payer in a two-input transaction could boot the other and claim everything for themselves. The conversation suggests that while there are risks associated with transaction replacement, existing mechanisms can mitigate them.Harding expresses confusion about the relationship between bitcoin transactions and real-world "deals" and calls for more specific definitions. He also discusses changing signatures in transactions and its impact on involved parties. Armory simulfunding transactions are mentioned, where one signer's input can be replaced after broadcasting. The consequences of changing inputs in transactions and the importance of warning signers of multi-input transactions are also discussed. The conversation delves into the complexities of bitcoin transactions and the factors influencing them.Maxwell explains the potential consequences of not contributing to a bitcoin transaction. New inputs combined with new or increased outputs can be seen as a second deal sharing the same envelope. If paying parties are kicked out, the entire transaction may be compromised, leading to real-world consequences. For example, in an Armory simulfunding transaction, one payer's input could be replaced after broadcasting, which could cause problems if the receiver cares about the payment source or makes subsequent decisions based on it. Maxwell also mentions the proposed Proof of Payment standard by Kalle, which allows one payer in a two-input transaction to boot the other and claim everything for themselves. However, this may not work as expected in the real world, especially when there are limited tickets available for a concert. The conversation emphasizes the need for caution when changing how an input is signed and highlights that replacement is a new concept requiring stronger warnings than those for 0-conf.The context explains how replacing a bitcoin transaction works and the implications of doing so. It clarifies that RBF applies only to pending transactions in the mempool waiting to be incorporated into a block. If a replacement transaction conflicts with an already confirmed original transaction, it will be rejected as a double spend. Implementations utilizing RBF must have a backup plan to handle the rejection of a replacement transaction as a double spend. Changing the contents of blocks, aside from mining a competing chain, would be a significant change to Bitcoin's design.The context mentions the mempool policy rule in Bitcoin's design, which states that any change to the contents of blocks other than through mining a competing chain would be a substantial alteration to Bitcoin's design.There is a discussion about whether transactions in buried blocks can be overridden or replaced by RBF. First-seen-safe replace-by-fee (FSS RBF) is a compromise between the standard RBF and first-seen mempool behavior. FSS RBF allows higher fee-paying transactions to replace previous transactions if all outputs in the previous transaction are still paid by the replacement. FSS RBF introduces additional criteria for replacing a transaction, such as all outputs existing in the new transaction and being unspent. Various usage scenarios for FSS RBF are mentioned, including increasing the fee on a single transaction and paying multiple recipients in succession. Wallets should treat conflicting incoming transactions as equivalent as long as their owned transaction outputs do not change.In an email conversation between Tom Harding and an unknown recipient, Harding questions the necessity of contributing to a transaction and suggests using another unused input with a larger fee instead. He highlights the unreliability of depending on the signature content of a transaction until it is buried. Harding argues that an inability to replace an input means that one cannot use RBF for additional fees without taking change in more cases. He believes there should be a benefit to this.FSS RBF is explained as a modification to the Bitcoin Core implementation that allows users effective ways to resolve "stuck" transactions and use blockchain space efficiently while maintaining zeroconf behavior. It allows transactions to be replaced with higher-fee paying transactions as long as all outputs in 2015-05-27T07:30:32+00:00 + The email discusses the use of Full Sequence Replace-By-Fee (FSS-RBF) in increasing fees on bitcoin transactions more efficiently than Child Pays For Parent (CPFP). In one case, adding a new input and increasing the change output value can result in cost savings ranging from 11% to 34%+. If an unspent output has a greater value than one of the outputs spent by the original transaction, it can be replaced, resulting in a 34% savings compared to CPFP. In another case, paying multiple recipients requires adding or swapping inputs, which can lead to overall savings of 25%. FSS-RBF can help reduce transaction size and increase cost savings. However, caution must be taken to ensure that at least one input remains unchanged after multiple rounds of this process.A discussion between Gregory Maxwell and Tom Harding addresses the potential risks of transaction replacement in Bitcoin. Harding raises concerns about certain payments being part of larger deals with unknown connections, which could cause issues if paying parties are kicked out or not informed immediately. Maxwell argues that multisig signers have already accepted the possibility of being written out and should not be considered less reliable. They also discuss Kalle's Proof of Payment proposed standard, where one payer in a two-input transaction could boot the other and claim everything for themselves. The conversation suggests that while there are risks associated with transaction replacement, existing mechanisms can mitigate them.Harding expresses confusion about the relationship between bitcoin transactions and real-world "deals" and calls for more specific definitions. He also discusses changing signatures in transactions and its impact on involved parties. Armory simulfunding transactions are mentioned, where one signer's input can be replaced after broadcasting. The consequences of changing inputs in transactions and the importance of warning signers of multi-input transactions are also discussed. The conversation delves into the complexities of bitcoin transactions and the factors influencing them.Maxwell explains the potential consequences of not contributing to a bitcoin transaction. New inputs combined with new or increased outputs can be seen as a second deal sharing the same envelope. If paying parties are kicked out, the entire transaction may be compromised, leading to real-world consequences. For example, in an Armory simulfunding transaction, one payer's input could be replaced after broadcasting, which could cause problems if the receiver cares about the payment source or makes subsequent decisions based on it. Maxwell also mentions the proposed Proof of Payment standard by Kalle, which allows one payer in a two-input transaction to boot the other and claim everything for themselves. However, this may not work as expected in the real world, especially when there are limited tickets available for a concert. The conversation emphasizes the need for caution when changing how an input is signed and highlights that replacement is a new concept requiring stronger warnings than those for 0-conf.The context explains how replacing a bitcoin transaction works and the implications of doing so. It clarifies that RBF applies only to pending transactions in the mempool waiting to be incorporated into a block. If a replacement transaction conflicts with an already confirmed original transaction, it will be rejected as a double spend. Implementations utilizing RBF must have a backup plan to handle the rejection of a replacement transaction as a double spend. Changing the contents of blocks, aside from mining a competing chain, would be a significant change to Bitcoin's design.The context mentions the mempool policy rule in Bitcoin's design, which states that any change to the contents of blocks other than through mining a competing chain would be a substantial alteration to Bitcoin's design.There is a discussion about whether transactions in buried blocks can be overridden or replaced by RBF. First-seen-safe replace-by-fee (FSS RBF) is a compromise between the standard RBF and first-seen mempool behavior. FSS RBF allows higher fee-paying transactions to replace previous transactions if all outputs in the previous transaction are still paid by the replacement. FSS RBF introduces additional criteria for replacing a transaction, such as all outputs existing in the new transaction and being unspent. Various usage scenarios for FSS RBF are mentioned, including increasing the fee on a single transaction and paying multiple recipients in succession. Wallets should treat conflicting incoming transactions as equivalent as long as their owned transaction outputs do not change.In an email conversation between Tom Harding and an unknown recipient, Harding questions the necessity of contributing to a transaction and suggests using another unused input with a larger fee instead. He highlights the unreliability of depending on the signature content of a transaction until it is buried. Harding argues that an inability to replace an input means that one cannot use RBF for additional fees without taking change in more cases. He believes there should be a benefit to this.FSS RBF is explained as a modification to the Bitcoin Core implementation that allows users effective ways to resolve "stuck" transactions and use blockchain space efficiently while maintaining zeroconf behavior. It allows transactions to be replaced with higher-fee paying transactions as long as all outputs in - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Fwd-Block-Size-Increase-Requirements.xml b/static/bitcoin-dev/May_2015/combined_Fwd-Block-Size-Increase-Requirements.xml index 21dc3f8452..3bdb3e553e 100644 --- a/static/bitcoin-dev/May_2015/combined_Fwd-Block-Size-Increase-Requirements.xml +++ b/static/bitcoin-dev/May_2015/combined_Fwd-Block-Size-Increase-Requirements.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Block Size Increase Requirements - 2023-08-01T12:56:58.388674+00:00 + 2025-10-11T22:09:25.665644+00:00 + python-feedgen Pindar Wong 2015-06-01 22:13:58+00:00 @@ -167,13 +168,13 @@ - python-feedgen + 2 Combined summary - Fwd: Block Size Increase Requirements - 2023-08-01T12:56:58.389685+00:00 + 2025-10-11T22:09:25.665838+00:00 - In this email thread, the discussion revolves around the potential consequences of increasing the block size in Bitcoin, particularly for miners in China. One member suggests that Chinese miners could collaborate and build a longer chain for themselves by firing out small coinbase only blocks, while another member sarcastically responds to a previous statement about excluding certain participants from mining. The conversation also delves into the idea that miners do not have an inherent right to mine if they cannot handle the job, specifically in regards to Chinese miners and their internet situation.Another email thread focuses on the block size limit of Bitcoin. One member suggests doing something relatively uncontroversial by increasing the block size limit to something in the 4-8GB range without further increases without a hard fork. They argue that hard forks need to become less scary and that a sequence of uncontroversial hard forks over time is more likely to gain consensus. The author believes that it is unnecessary to commit to future block size increases years into the future and that it is important to react appropriately to changing conditions.In a separate exchange, one member argues that miners are businesses selling a service to Bitcoin users and if they cannot provide the necessary service, then they should not mine. They believe that advancements in technology have caused many miners to come and go since the beginning of Bitcoin. The author agrees with this perspective and suggests that if miners outside of China cannot get the required bandwidth through their firewall, then they will have to carry on without them.The email thread also discusses the business aspect of Bitcoin mining. It is emphasized that miners are not charities but rather businesses that sell a service to Bitcoin users. Therefore, if some miners are unable to provide this service anymore, they should not/cannot mine. The author believes that it is just part of the business.Furthermore, the conversation highlights the importance of global connectivity for miners, as good connectivity is essential for receiving blocks at higher latency and reducing the risk of orphans. The cost of good connectivity is borne by people outside of well-connected miner groups, incentivizing miners to prioritize their connection quality. This perspective argues that if miners cannot handle the necessary global connectivity, they should not mine.Another email exchange focuses on the topic of miners in China and their ability to mine. One member suggests that if Chinese miners cannot get the necessary bandwidth through their firewall, they should be outcompeted and forced to stop mining. Another member responds with what they believe is obvious sarcasm to highlight the insensitivity of the previous statement. However, some people misunderstand the sarcasm and the original poster clarifies their intention. A third party expresses agreement with the sentiment but criticizes the idea of dis-incentivizing mining and suggests finding a way to decentralize mining without hurting miners.The discussion also touches upon Nielsen's Law of Internet Bandwidth, which predicts that bandwidth available to high-end users grows by 50% per year. It is stated that this law is not relevant for modeling the connectivity of a peer-to-peer network like Bitcoin. The context highlights the scarcity and cost of uplink bandwidth in China and suggests using Multipath TCP (MPTCP) as a solution to improve bandwidth and connection stability. MPTCP allows multiple interfaces/networks for a single TCP connection, combining different connections to optimize upload and download paths.In the email thread, there is a conversation about determining the maximum block size for Bitcoin. One member suggests starting at a max of 8 or 4GB to ensure predictability and scalability over time. Another member agrees with keeping the block sizes as powers of two to make it easier to count support levels for each level. The final consensus on the maximum block size remains unclear.Another email exchange discusses the proposal for a 20MB block size increase in Bitcoin. One member expresses opposition to this proposal, arguing that such an increase could lead to an unacceptable orphan rate. They suggest a lower limit of 5MB, 8MB, or 10MB instead. The member who proposed the 20MB increase defends their suggestion, stating that their testing showed it to be safe and reasonable. They also express uncertainty about the progress of BIP66.The conversation also includes a discussion on finding common ground regarding the block size limit. One member suggests compromising on a maximum size increase of 8 or 4MB to ensure the safety and stability of the system. They emphasize the importance of reaching a consensus rather than engaging in a head-on confrontation between incompatible software. The author acknowledges that a compromise based on a one-off maximum-size increase may not be ideal but suggests it as a reasonable compromise if certain individuals find a new maximum-size cap acceptable.Overall, the email thread provides insights into the ongoing discussions and debates within the Bitcoin development community regarding the potential consequences of increasing the block size, the role of miners, the need for global connectivity, and the ideal maximum block size for the network.In an email conversation in 2015, Gavin Andresen discussed the potential impact of a 20MB block size on the 2015-06-01T22:13:58+00:00 + In this email thread, the discussion revolves around the potential consequences of increasing the block size in Bitcoin, particularly for miners in China. One member suggests that Chinese miners could collaborate and build a longer chain for themselves by firing out small coinbase only blocks, while another member sarcastically responds to a previous statement about excluding certain participants from mining. The conversation also delves into the idea that miners do not have an inherent right to mine if they cannot handle the job, specifically in regards to Chinese miners and their internet situation.Another email thread focuses on the block size limit of Bitcoin. One member suggests doing something relatively uncontroversial by increasing the block size limit to something in the 4-8GB range without further increases without a hard fork. They argue that hard forks need to become less scary and that a sequence of uncontroversial hard forks over time is more likely to gain consensus. The author believes that it is unnecessary to commit to future block size increases years into the future and that it is important to react appropriately to changing conditions.In a separate exchange, one member argues that miners are businesses selling a service to Bitcoin users and if they cannot provide the necessary service, then they should not mine. They believe that advancements in technology have caused many miners to come and go since the beginning of Bitcoin. The author agrees with this perspective and suggests that if miners outside of China cannot get the required bandwidth through their firewall, then they will have to carry on without them.The email thread also discusses the business aspect of Bitcoin mining. It is emphasized that miners are not charities but rather businesses that sell a service to Bitcoin users. Therefore, if some miners are unable to provide this service anymore, they should not/cannot mine. The author believes that it is just part of the business.Furthermore, the conversation highlights the importance of global connectivity for miners, as good connectivity is essential for receiving blocks at higher latency and reducing the risk of orphans. The cost of good connectivity is borne by people outside of well-connected miner groups, incentivizing miners to prioritize their connection quality. This perspective argues that if miners cannot handle the necessary global connectivity, they should not mine.Another email exchange focuses on the topic of miners in China and their ability to mine. One member suggests that if Chinese miners cannot get the necessary bandwidth through their firewall, they should be outcompeted and forced to stop mining. Another member responds with what they believe is obvious sarcasm to highlight the insensitivity of the previous statement. However, some people misunderstand the sarcasm and the original poster clarifies their intention. A third party expresses agreement with the sentiment but criticizes the idea of dis-incentivizing mining and suggests finding a way to decentralize mining without hurting miners.The discussion also touches upon Nielsen's Law of Internet Bandwidth, which predicts that bandwidth available to high-end users grows by 50% per year. It is stated that this law is not relevant for modeling the connectivity of a peer-to-peer network like Bitcoin. The context highlights the scarcity and cost of uplink bandwidth in China and suggests using Multipath TCP (MPTCP) as a solution to improve bandwidth and connection stability. MPTCP allows multiple interfaces/networks for a single TCP connection, combining different connections to optimize upload and download paths.In the email thread, there is a conversation about determining the maximum block size for Bitcoin. One member suggests starting at a max of 8 or 4GB to ensure predictability and scalability over time. Another member agrees with keeping the block sizes as powers of two to make it easier to count support levels for each level. The final consensus on the maximum block size remains unclear.Another email exchange discusses the proposal for a 20MB block size increase in Bitcoin. One member expresses opposition to this proposal, arguing that such an increase could lead to an unacceptable orphan rate. They suggest a lower limit of 5MB, 8MB, or 10MB instead. The member who proposed the 20MB increase defends their suggestion, stating that their testing showed it to be safe and reasonable. They also express uncertainty about the progress of BIP66.The conversation also includes a discussion on finding common ground regarding the block size limit. One member suggests compromising on a maximum size increase of 8 or 4MB to ensure the safety and stability of the system. They emphasize the importance of reaching a consensus rather than engaging in a head-on confrontation between incompatible software. The author acknowledges that a compromise based on a one-off maximum-size increase may not be ideal but suggests it as a reasonable compromise if certain individuals find a new maximum-size cap acceptable.Overall, the email thread provides insights into the ongoing discussions and debates within the Bitcoin development community regarding the potential consequences of increasing the block size, the role of miners, the need for global connectivity, and the ideal maximum block size for the network.In an email conversation in 2015, Gavin Andresen discussed the potential impact of a 20MB block size on the - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Long-term-mining-incentives.xml b/static/bitcoin-dev/May_2015/combined_Long-term-mining-incentives.xml index 3edaab2f4e..4039c25013 100644 --- a/static/bitcoin-dev/May_2015/combined_Long-term-mining-incentives.xml +++ b/static/bitcoin-dev/May_2015/combined_Long-term-mining-incentives.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Long-term mining incentives - 2023-08-01T12:40:09.453657+00:00 + 2025-10-11T22:10:12.503175+00:00 + python-feedgen Mike Hearn 2015-05-28 10:30:55+00:00 @@ -151,13 +152,13 @@ - python-feedgen + 2 Combined summary - Long-term mining incentives - 2023-08-01T12:40:09.455657+00:00 + 2025-10-11T22:10:12.503448+00:00 - The article discusses the concept of assurance contracts for paying miners in Bitcoin. The current system pays miners regardless of whether they support or oppose the user's interests, but assurance contracts propose to pay miners based on their actions. However, the article notes that transaction fees already exist as a mechanism for paying for security and may be more effective than assurance contracts. The author also acknowledges that the success of assurance contracts is uncertain and that funding development through crowdfunding is still an experimental plan. Additionally, the author mentions that existing crowdfunding platforms do not typically incorporate ongoing costs into binary contracts.Mike Hearn, a developer involved in the creation of Bitcoin, explains the concept of hashing assurance contracts. He argues that transaction fees, which already exist in Bitcoin, serve as a mechanism for paying for security and can solve the common action problem of people waiting for others to pay for security. However, he questions the workability of assurance contracts, particularly for ongoing costs like security. Hearn also points out that many crowdfunding platforms do not use binary contracts for ongoing costs. He reminds readers that mining per-contract poses an existential risk to Bitcoin.In a recently written article, the hashing assurance contract concept is explained in detail. While the article does not provide an in-depth protocol description, it offers valuable insights into the concept. The article can be useful for those interested in understanding hashing assurance contracts.In an email exchange, Thomas expresses his agreement with Gavin that long-term planning for Bitcoin's future is ambitious and cannot justify decisions made today. Thomas believes that opposition to block size increases stems from concerns about increased centralization and long-term fee pressure needs. He supports the proposed block size increase but acknowledges the issue of long-term mining incentives. He suggests solutions such as ending the original block halving schedule or allowing miners to redeem lost coins. Thomas emphasizes the importance of adopting proven solutions rather than relying on untested methods.The lack of vision in the Bitcoin community is discussed in an email exchange. Gavin expresses concerns about planning for 20 years ahead given the uncertainty surrounding the longevity of Bitcoin. The author suggests that an elevated level of hashing is crucial for maintaining decentralization and autonomy in the network. They argue that the current system of incentivizing through inflation should be replaced with minimum fees for transactions. The author emphasizes the importance of letting network users express their preferences for security and willingness to pay for it.In another email conversation, the sender suggests alternatives such as sidechains and off-chain solutions that still use Bitcoin as a unit of value. However, the recipient argues that the only options currently available are of the centralized custody variety. The sender explains that when the block size limit is reached, transactions at the margins will experience unpredictable failure. They suggest slowing blockchain growth by increasing fees alone. The recipient compares the cost of using gold to Bitcoin, but the sender counters by pointing out the costs associated with using gold and how people shifted to fiat currency over time.The debate over increasing the block size as a solution to scalability is ongoing in the Bitcoin community. Some argue that there are plenty of options to increase fees and incentivize users to economize on block space. Others believe that payment channels are a more viable solution than increasing the block size. Concerns are raised about the future of Bitcoin's security when the block subsidy becomes insignificant. The community is encouraged to focus on the debate over hardforks rather than the block size debate, and a clear criterion for acceptable hardforks is suggested.In May 2015, Thomas Voegtlin initiated a discussion about the long-term mining incentives of Bitcoin. He questions whether a steady-state regime can exist in the future and what conditions are necessary for its existence. Proponents of a block size increase argue that if the block size is not raised soon, Bitcoin may enter a harmful regime. However, opponents argue that increasing the block size limit could lead to unknown consequences. expressing skepticism about the feasibility and sustainability of relying solely on fees to support mining incentives. They argue that without a block size increase, there will not be enough transaction fees to incentivize miners in the long term. They also mention potential issues with scaling and the need for a clear vision from both proponents and opponents of a block size increase. Additionally, they highlight the importance of considering alternative solutions such as payment channels for scalability instead of solely focusing on increasing the block size. The individual further emphasizes the experimental nature of Bitcoin and cautions against rushing into decisions regarding the block size limit. They advocate for a cautious approach as the Bitcoin infrastructure continues to grow rapidly.Gavin Andresen, a core developer of Bitcoin, acknowledges the importance of proof-of-work (PoW) in securing the chain but believes that alternatives might be necessary in the future. He suggests that new innovations or methods could be developed that do not compromise Bitcoin's security model. Andresen also proposes payment channels as a potential solution to scalability challenges, rather than increasing the block size. He advocates for a focus on the hardfork debate and the establishment of clear criteria for hardforks, which 2015-05-28T10:30:55+00:00 + The article discusses the concept of assurance contracts for paying miners in Bitcoin. The current system pays miners regardless of whether they support or oppose the user's interests, but assurance contracts propose to pay miners based on their actions. However, the article notes that transaction fees already exist as a mechanism for paying for security and may be more effective than assurance contracts. The author also acknowledges that the success of assurance contracts is uncertain and that funding development through crowdfunding is still an experimental plan. Additionally, the author mentions that existing crowdfunding platforms do not typically incorporate ongoing costs into binary contracts.Mike Hearn, a developer involved in the creation of Bitcoin, explains the concept of hashing assurance contracts. He argues that transaction fees, which already exist in Bitcoin, serve as a mechanism for paying for security and can solve the common action problem of people waiting for others to pay for security. However, he questions the workability of assurance contracts, particularly for ongoing costs like security. Hearn also points out that many crowdfunding platforms do not use binary contracts for ongoing costs. He reminds readers that mining per-contract poses an existential risk to Bitcoin.In a recently written article, the hashing assurance contract concept is explained in detail. While the article does not provide an in-depth protocol description, it offers valuable insights into the concept. The article can be useful for those interested in understanding hashing assurance contracts.In an email exchange, Thomas expresses his agreement with Gavin that long-term planning for Bitcoin's future is ambitious and cannot justify decisions made today. Thomas believes that opposition to block size increases stems from concerns about increased centralization and long-term fee pressure needs. He supports the proposed block size increase but acknowledges the issue of long-term mining incentives. He suggests solutions such as ending the original block halving schedule or allowing miners to redeem lost coins. Thomas emphasizes the importance of adopting proven solutions rather than relying on untested methods.The lack of vision in the Bitcoin community is discussed in an email exchange. Gavin expresses concerns about planning for 20 years ahead given the uncertainty surrounding the longevity of Bitcoin. The author suggests that an elevated level of hashing is crucial for maintaining decentralization and autonomy in the network. They argue that the current system of incentivizing through inflation should be replaced with minimum fees for transactions. The author emphasizes the importance of letting network users express their preferences for security and willingness to pay for it.In another email conversation, the sender suggests alternatives such as sidechains and off-chain solutions that still use Bitcoin as a unit of value. However, the recipient argues that the only options currently available are of the centralized custody variety. The sender explains that when the block size limit is reached, transactions at the margins will experience unpredictable failure. They suggest slowing blockchain growth by increasing fees alone. The recipient compares the cost of using gold to Bitcoin, but the sender counters by pointing out the costs associated with using gold and how people shifted to fiat currency over time.The debate over increasing the block size as a solution to scalability is ongoing in the Bitcoin community. Some argue that there are plenty of options to increase fees and incentivize users to economize on block space. Others believe that payment channels are a more viable solution than increasing the block size. Concerns are raised about the future of Bitcoin's security when the block subsidy becomes insignificant. The community is encouraged to focus on the debate over hardforks rather than the block size debate, and a clear criterion for acceptable hardforks is suggested.In May 2015, Thomas Voegtlin initiated a discussion about the long-term mining incentives of Bitcoin. He questions whether a steady-state regime can exist in the future and what conditions are necessary for its existence. Proponents of a block size increase argue that if the block size is not raised soon, Bitcoin may enter a harmful regime. However, opponents argue that increasing the block size limit could lead to unknown consequences. expressing skepticism about the feasibility and sustainability of relying solely on fees to support mining incentives. They argue that without a block size increase, there will not be enough transaction fees to incentivize miners in the long term. They also mention potential issues with scaling and the need for a clear vision from both proponents and opponents of a block size increase. Additionally, they highlight the importance of considering alternative solutions such as payment channels for scalability instead of solely focusing on increasing the block size. The individual further emphasizes the experimental nature of Bitcoin and cautions against rushing into decisions regarding the block size limit. They advocate for a cautious approach as the Bitcoin infrastructure continues to grow rapidly.Gavin Andresen, a core developer of Bitcoin, acknowledges the importance of proof-of-work (PoW) in securing the chain but believes that alternatives might be necessary in the future. He suggests that new innovations or methods could be developed that do not compromise Bitcoin's security model. Andresen also proposes payment channels as a potential solution to scalability challenges, rather than increasing the block size. He advocates for a focus on the hardfork debate and the establishment of clear criteria for hardforks, which - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Max-Block-Size-Simple-Voting-Procedure.xml b/static/bitcoin-dev/May_2015/combined_Max-Block-Size-Simple-Voting-Procedure.xml index 9f6f1f5259..5fa071c220 100644 --- a/static/bitcoin-dev/May_2015/combined_Max-Block-Size-Simple-Voting-Procedure.xml +++ b/static/bitcoin-dev/May_2015/combined_Max-Block-Size-Simple-Voting-Procedure.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Max Block Size: Simple Voting Procedure - 2023-08-01T12:59:08.483186+00:00 + 2025-10-11T22:10:23.124847+00:00 + python-feedgen Pindar Wong 2015-06-03 04:18:22+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Max Block Size: Simple Voting Procedure - 2023-08-01T12:59:08.483186+00:00 + 2025-10-11T22:10:23.125017+00:00 - The email exchange between Stephen Morse and Pindar Wong discusses the idea of separating hard/soft fork upgrades in Bitcoin. Wong believes that involving mining pools in decisions can be interesting, but Morse acknowledges concerns about giving miners too much power. Vincent proposes changes to the voting system for miners, suggesting that votes need to be 100% instead of 50.01% to give small miners a fair chance. He also suggests that users who make transactions should have a vote, and fee incentives should attract legitimate votes from miners. However, Stephen points out technical infeasibilities with voting through wallets. The discussion also mentions the possibility of using a token in the coinbase input script to indicate support for larger blocks, but there are concerns about centralization and risks associated with miners wanting larger blocks than the rest of the network can handle. The proposal suggests a voting procedure to increase the block size limit, using an output in the coinbase transaction to vote for or against the increase. Not voting is equivalent to voting against the increase. If more than 1008 blocks out of a 2016 block round vote to increase the block size limit, then the maximum block size increases by 500 kb. The proposal aims to create a non-gameable voting system without artificially bloating blocks or excluding transactions. 2015-06-03T04:18:22+00:00 + The email exchange between Stephen Morse and Pindar Wong discusses the idea of separating hard/soft fork upgrades in Bitcoin. Wong believes that involving mining pools in decisions can be interesting, but Morse acknowledges concerns about giving miners too much power. Vincent proposes changes to the voting system for miners, suggesting that votes need to be 100% instead of 50.01% to give small miners a fair chance. He also suggests that users who make transactions should have a vote, and fee incentives should attract legitimate votes from miners. However, Stephen points out technical infeasibilities with voting through wallets. The discussion also mentions the possibility of using a token in the coinbase input script to indicate support for larger blocks, but there are concerns about centralization and risks associated with miners wanting larger blocks than the rest of the network can handle. The proposal suggests a voting procedure to increase the block size limit, using an output in the coinbase transaction to vote for or against the increase. Not voting is equivalent to voting against the increase. If more than 1008 blocks out of a 2016 block round vote to increase the block size limit, then the maximum block size increases by 500 kb. The proposal aims to create a non-gameable voting system without artificially bloating blocks or excluding transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Mechanics-of-a-hard-fork.xml b/static/bitcoin-dev/May_2015/combined_Mechanics-of-a-hard-fork.xml index 4c1dc3a171..fbb9eeb89d 100644 --- a/static/bitcoin-dev/May_2015/combined_Mechanics-of-a-hard-fork.xml +++ b/static/bitcoin-dev/May_2015/combined_Mechanics-of-a-hard-fork.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mechanics of a hard fork - 2023-08-01T12:24:23.514689+00:00 + 2025-10-11T22:10:18.878715+00:00 + python-feedgen Cameron Garnham 2015-05-08 03:12:22+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Mechanics of a hard fork - 2023-08-01T12:24:23.514689+00:00 + 2025-10-11T22:10:18.878885+00:00 - In an email exchange between Pieter Wuille and Roy Badami, the two discuss the risks and implications of implementing a hard fork in the Bitcoin network. Pieter argues that a hard fork is only safe if all economically relevant users upgrade, while Roy believes that requiring a supermajority of miners for a hard fork to proceed is a wise precaution. They also touch on the potential power of users to change the hash function or freeze transactions in extreme circumstances.Pieter states that he would not modify his node if a change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. Roy responds by saying that in this scenario, Bitcoin would be dead and vulnerable to a 501% attack if the fork had only 1% of the hash power. He emphasizes the need to convince people and ensure that they modify their code before making any changes to the Bitcoin system.The conversation, shared on the Bitcoin-development mailing list, delves into the risks associated with a hard fork. Pieter argues that a hashrate-triggered hard fork does not make sense as it is risky regardless of whether the hashrate upgrades. Roy questions the plausibility of a scenario where 99% of miners vote for a hard fork, but the economic majority votes to stay on the old blockchain, given the significant drop in hashrate and block time. They also discuss the potential for users to change the hash function or freeze transactions in extreme situations.Another thread on the Bitcoin-development mailing list sees Pieter stating that he would not modify his node if a change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners agreed. Someone else responds by suggesting that such a scenario would lead to the death of Bitcoin and vulnerability to a 501% attack. Pieter emphasizes that a hard fork is safe when all economically relevant users upgrade, and requiring a supermajority of miners is a wise precaution. They also discuss the possibility of miners upgrading at a different schedule than the rest of the network.The context highlights the importance of consensus among miners, merchants, and users for a successful hard fork in the Bitcoin network. While a supermajority of 75% miners is sufficient, near-total consensus is required from merchants and users. If there is a significant split in support, it can result in blockchain stalls. The author suggests that before considering any hard fork proposal, there needs to be rough consensus on the level of supermajority required. Various proposals have been made, ranging from 99% to 80% of miners. The author believes that a supermajority of approximately 97.2% (35/36th) of miners is the minimum needed to avoid forking Bitcoin into two competing coins.Overall, the context provides insights into the risks and implications of implementing a hard fork in the Bitcoin network. It emphasizes the need for consensus among miners, merchants, and users, and the importance of convincing people to modify their code. 2015-05-08T03:12:22+00:00 + In an email exchange between Pieter Wuille and Roy Badami, the two discuss the risks and implications of implementing a hard fork in the Bitcoin network. Pieter argues that a hard fork is only safe if all economically relevant users upgrade, while Roy believes that requiring a supermajority of miners for a hard fork to proceed is a wise precaution. They also touch on the potential power of users to change the hash function or freeze transactions in extreme circumstances.Pieter states that he would not modify his node if a change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. Roy responds by saying that in this scenario, Bitcoin would be dead and vulnerable to a 501% attack if the fork had only 1% of the hash power. He emphasizes the need to convince people and ensure that they modify their code before making any changes to the Bitcoin system.The conversation, shared on the Bitcoin-development mailing list, delves into the risks associated with a hard fork. Pieter argues that a hashrate-triggered hard fork does not make sense as it is risky regardless of whether the hashrate upgrades. Roy questions the plausibility of a scenario where 99% of miners vote for a hard fork, but the economic majority votes to stay on the old blockchain, given the significant drop in hashrate and block time. They also discuss the potential for users to change the hash function or freeze transactions in extreme situations.Another thread on the Bitcoin-development mailing list sees Pieter stating that he would not modify his node if a change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners agreed. Someone else responds by suggesting that such a scenario would lead to the death of Bitcoin and vulnerability to a 501% attack. Pieter emphasizes that a hard fork is safe when all economically relevant users upgrade, and requiring a supermajority of miners is a wise precaution. They also discuss the possibility of miners upgrading at a different schedule than the rest of the network.The context highlights the importance of consensus among miners, merchants, and users for a successful hard fork in the Bitcoin network. While a supermajority of 75% miners is sufficient, near-total consensus is required from merchants and users. If there is a significant split in support, it can result in blockchain stalls. The author suggests that before considering any hard fork proposal, there needs to be rough consensus on the level of supermajority required. Various proposals have been made, ranging from 99% to 80% of miners. The author believes that a supermajority of approximately 97.2% (35/36th) of miners is the minimum needed to avoid forking Bitcoin into two competing coins.Overall, the context provides insights into the risks and implications of implementing a hard fork in the Bitcoin network. It emphasizes the need for consensus among miners, merchants, and users, and the importance of convincing people to modify their code. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_New-release-of-replace-by-fee-for-Bitcoin-Core-v0-10-1.xml b/static/bitcoin-dev/May_2015/combined_New-release-of-replace-by-fee-for-Bitcoin-Core-v0-10-1.xml index ae9c7810ce..0320da22bc 100644 --- a/static/bitcoin-dev/May_2015/combined_New-release-of-replace-by-fee-for-Bitcoin-Core-v0-10-1.xml +++ b/static/bitcoin-dev/May_2015/combined_New-release-of-replace-by-fee-for-Bitcoin-Core-v0-10-1.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New release of replace-by-fee for Bitcoin Core v0.10.1 - 2023-08-01T12:20:55.297988+00:00 + 2025-10-11T22:09:44.855628+00:00 + python-feedgen Kevin Greene 2015-05-05 02:23:09+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - New release of replace-by-fee for Bitcoin Core v0.10.1 - 2023-08-01T12:20:55.297988+00:00 + 2025-10-11T22:09:44.855771+00:00 - Peter Todd has released a replace-by-fee patch for Bitcoin Core v0.10.1, which can be found on Github. This new version is essentially a rebase of the previous version and does not introduce any new features. The purpose of the patch is to change the way most Bitcoin nodes accept transactions, aligning them with miner incentives by accepting transactions with the highest fee. This change aims to create a more efficient transaction fee marketplace.One of the main benefits of replace-by-fee is that it provides a solution for "stuck" transactions. With this patch, users can create higher paying versions of these stuck transactions, allowing them to be double-spent and making zeroconf transactions economically secure through economic incentives. By adopting replace-by-fee, the development of an ecosystem that relies heavily on large miners punishing smaller ones for misbehavior can be avoided.The installation process for the replace-by-fee-v0.10.1 branch is straightforward. Users simply need to compile the branch and run their node as they normally would. To see messages indicating that their node is replacing transactions with higher-fee paying double-spends, users should enable -debug logging. It is worth noting that replace-by-fee nodes advertise service bit 26 from the experimental use range, while Bitcoin XT nodes advertise service bit 1 for their getutxos support. This information can help users determine whether they are connected to replace-by-fee nodes or Bitcoin XT nodes.For those who do not wish to advertise that they are running a replace-by-fee node, there is an option to checkout an earlier commit in git. Overall, Peter Todd's replace-by-fee patch for Bitcoin Core v0.10.1 offers a solution to improve the efficiency of the transaction fee marketplace and enhance the security of zeroconf transactions. 2015-05-05T02:23:09+00:00 + Peter Todd has released a replace-by-fee patch for Bitcoin Core v0.10.1, which can be found on Github. This new version is essentially a rebase of the previous version and does not introduce any new features. The purpose of the patch is to change the way most Bitcoin nodes accept transactions, aligning them with miner incentives by accepting transactions with the highest fee. This change aims to create a more efficient transaction fee marketplace.One of the main benefits of replace-by-fee is that it provides a solution for "stuck" transactions. With this patch, users can create higher paying versions of these stuck transactions, allowing them to be double-spent and making zeroconf transactions economically secure through economic incentives. By adopting replace-by-fee, the development of an ecosystem that relies heavily on large miners punishing smaller ones for misbehavior can be avoided.The installation process for the replace-by-fee-v0.10.1 branch is straightforward. Users simply need to compile the branch and run their node as they normally would. To see messages indicating that their node is replacing transactions with higher-fee paying double-spends, users should enable -debug logging. It is worth noting that replace-by-fee nodes advertise service bit 26 from the experimental use range, while Bitcoin XT nodes advertise service bit 1 for their getutxos support. This information can help users determine whether they are connected to replace-by-fee nodes or Bitcoin XT nodes.For those who do not wish to advertise that they are running a replace-by-fee node, there is an option to checkout an earlier commit in git. Overall, Peter Todd's replace-by-fee patch for Bitcoin Core v0.10.1 offers a solution to improve the efficiency of the transaction fee marketplace and enhance the security of zeroconf transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_No-Bitcoin-For-You.xml b/static/bitcoin-dev/May_2015/combined_No-Bitcoin-For-You.xml index 9ae5c2c551..6454aa3668 100644 --- a/static/bitcoin-dev/May_2015/combined_No-Bitcoin-For-You.xml +++ b/static/bitcoin-dev/May_2015/combined_No-Bitcoin-For-You.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - No Bitcoin For You - 2023-08-01T12:44:58.073518+00:00 + 2025-10-11T22:09:49.115232+00:00 + python-feedgen Jim Phillips 2015-05-26 08:29:31+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - No Bitcoin For You - 2023-08-01T12:44:58.073518+00:00 + 2025-10-11T22:09:49.115410+00:00 - There is a debate within the Bitcoin community about the block size, with arguments for both smaller and larger block sizes. Some believe that a small block size will make Bitcoin too expensive for individuals to use, while others think that larger blocks will prevent most people from owning even a single utxo. Currently, with a block size of 1 MB, less than 1% of people can own a single Satoshi, leading them to either not use Bitcoin or rely on a substitute lacking the full security guarantees of the main blockchain.One concern for individuals is being able to validate the blockchain. With a pruning node, an individual only needs to download the blockchain once and maintain the utxo set, which requires roughly 30 bytes per utxo. This means that if each person has one utxo, around 210 GB of storage would be needed, which is achievable with today's hardware. Even if each person has ten utxos, it would still be feasible with approximately 2.1 TB of storage.However, the current block size of 1 MB is not suitable for settling transactions on a global scale within a reasonable timescale. To handle trillions of transactions per day, supporting approximately 1 utxo per person per day, we would need block sizes of 10 GB, which is achievable with current hardware. Additionally, using SPV (Simplified Payment Verification) security instead of pruning security would further reduce the cost.As the capacity of Bitcoin grows, fewer individuals would be able to run full nodes, potentially leading them to give up running a full-node wallet. However, if more parts of the network rely on SPV-level security, it may still be possible for individuals collectively to form the majority of the network. This could be facilitated by implementing a scalable DHT-type network of nodes that collectively store and index the extensive transaction history, including unconfirmed transactions.The concern with restricting block capacity to allow individuals to run full nodes is that it could make Bitcoin too expensive for individuals to use. The Lightning Network, for example, would need to consolidate global payments by a factor of 25000:1 to fit into Bitcoin's current capacity as a settlement network. This would make it costly for current holders to sell or spend their Bitcoin.In conclusion, finding a balance between block size and individual participation is crucial for the future of Bitcoin. Implementing scalable SPV-level security and a decentralized network of nodes may enable individuals to collectively maintain the majority of the network, even as the capacity of Bitcoin grows. 2015-05-26T08:29:31+00:00 + There is a debate within the Bitcoin community about the block size, with arguments for both smaller and larger block sizes. Some believe that a small block size will make Bitcoin too expensive for individuals to use, while others think that larger blocks will prevent most people from owning even a single utxo. Currently, with a block size of 1 MB, less than 1% of people can own a single Satoshi, leading them to either not use Bitcoin or rely on a substitute lacking the full security guarantees of the main blockchain.One concern for individuals is being able to validate the blockchain. With a pruning node, an individual only needs to download the blockchain once and maintain the utxo set, which requires roughly 30 bytes per utxo. This means that if each person has one utxo, around 210 GB of storage would be needed, which is achievable with today's hardware. Even if each person has ten utxos, it would still be feasible with approximately 2.1 TB of storage.However, the current block size of 1 MB is not suitable for settling transactions on a global scale within a reasonable timescale. To handle trillions of transactions per day, supporting approximately 1 utxo per person per day, we would need block sizes of 10 GB, which is achievable with current hardware. Additionally, using SPV (Simplified Payment Verification) security instead of pruning security would further reduce the cost.As the capacity of Bitcoin grows, fewer individuals would be able to run full nodes, potentially leading them to give up running a full-node wallet. However, if more parts of the network rely on SPV-level security, it may still be possible for individuals collectively to form the majority of the network. This could be facilitated by implementing a scalable DHT-type network of nodes that collectively store and index the extensive transaction history, including unconfirmed transactions.The concern with restricting block capacity to allow individuals to run full nodes is that it could make Bitcoin too expensive for individuals to use. The Lightning Network, for example, would need to consolidate global payments by a factor of 25000:1 to fit into Bitcoin's current capacity as a settlement network. This would make it costly for current holders to sell or spend their Bitcoin.In conclusion, finding a balance between block size and individual participation is crucial for the future of Bitcoin. Implementing scalable SPV-level security and a decentralized network of nodes may enable individuals to collectively maintain the majority of the network, even as the capacity of Bitcoin grows. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Open-Bitcoin-Privacy-Project-Spring-2015-Report.xml b/static/bitcoin-dev/May_2015/combined_Open-Bitcoin-Privacy-Project-Spring-2015-Report.xml index 792411beb0..71eb250cb4 100644 --- a/static/bitcoin-dev/May_2015/combined_Open-Bitcoin-Privacy-Project-Spring-2015-Report.xml +++ b/static/bitcoin-dev/May_2015/combined_Open-Bitcoin-Privacy-Project-Spring-2015-Report.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Open Bitcoin Privacy Project Spring 2015 Report - 2023-08-01T12:45:08.288240+00:00 + 2025-10-11T22:09:42.732790+00:00 + python-feedgen Jonas Schnelli 2015-05-19 11:50:03+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Open Bitcoin Privacy Project Spring 2015 Report - 2023-08-01T12:45:08.288240+00:00 + 2025-10-11T22:09:42.732925+00:00 - Justus Ranvier, a member of the Bitcoin community and founder of the Open Bitcoin Privacy Project, responded to a question about the ratings of Bitcoin wallets. He explained that they rated as many wallets as possible based on the available manpower and will be recruiting more volunteers for future rounds of ratings. The specific question asked why Bitcoin-Core and Breadwallet for iOS were missing from the ratings.The context also includes an email from Jonas Schnelli, a representative of include7 AG in Switzerland. The email provides contact information for the company and warns against sending sensitive data in unencrypted emails. Instead, a link to a secure form is provided.Eric Lombrozo questioned why mSIGNA was not included in the report by the Open Bitcoin Privacy Project. He stated that mSIGNA has advanced security and privacy features and has been listed on bitcoin.org longer than some of the other wallets reviewed. Justus Ranvier replied to the list, stating that they will add mSIGNA to the report if it meets their standards.In addition, the Open Bitcoin Privacy Project has published its first report on Bitcoin wallet privacy features. The full report assesses the privacy of several popular wallets. The organization plans to produce further reports over time, establishing itself as a valuable source of information in the Bitcoin space. They are also seeking feedback from the community about their methodology and criteria for assessing privacy.Overall, the Open Bitcoin Privacy Project is actively rating Bitcoin wallets based on available manpower and plans to recruit more volunteers for future rounds. They have published a report on wallet privacy features and will continue to produce more reports. The organization is open to feedback from the community to improve their assessment methods. 2015-05-19T11:50:03+00:00 + Justus Ranvier, a member of the Bitcoin community and founder of the Open Bitcoin Privacy Project, responded to a question about the ratings of Bitcoin wallets. He explained that they rated as many wallets as possible based on the available manpower and will be recruiting more volunteers for future rounds of ratings. The specific question asked why Bitcoin-Core and Breadwallet for iOS were missing from the ratings.The context also includes an email from Jonas Schnelli, a representative of include7 AG in Switzerland. The email provides contact information for the company and warns against sending sensitive data in unencrypted emails. Instead, a link to a secure form is provided.Eric Lombrozo questioned why mSIGNA was not included in the report by the Open Bitcoin Privacy Project. He stated that mSIGNA has advanced security and privacy features and has been listed on bitcoin.org longer than some of the other wallets reviewed. Justus Ranvier replied to the list, stating that they will add mSIGNA to the report if it meets their standards.In addition, the Open Bitcoin Privacy Project has published its first report on Bitcoin wallet privacy features. The full report assesses the privacy of several popular wallets. The organization plans to produce further reports over time, establishing itself as a valuable source of information in the Bitcoin space. They are also seeking feedback from the community about their methodology and criteria for assessing privacy.Overall, the Open Bitcoin Privacy Project is actively rating Bitcoin wallets based on available manpower and plans to recruit more volunteers for future rounds. They have published a report on wallet privacy features and will continue to produce more reports. The organization is open to feedback from the community to improve their assessment methods. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Proposal-A-measured-response-to-save-Bitcoin-Core.xml b/static/bitcoin-dev/May_2015/combined_Proposal-A-measured-response-to-save-Bitcoin-Core.xml index bfee482ee0..a26ce975e7 100644 --- a/static/bitcoin-dev/May_2015/combined_Proposal-A-measured-response-to-save-Bitcoin-Core.xml +++ b/static/bitcoin-dev/May_2015/combined_Proposal-A-measured-response-to-save-Bitcoin-Core.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: A measured response to save Bitcoin Core - 2023-08-01T12:54:53.487586+00:00 + 2025-10-11T22:09:19.278449+00:00 + python-feedgen Eric Lombrozo 2015-05-31 10:01:53+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Proposal: A measured response to save Bitcoin Core - 2023-08-01T12:54:53.487586+00:00 + 2025-10-11T22:09:19.278625+00:00 - Eric Lombrozo agrees with Drak's assessment that politics are inevitable in any consensus protocol seeking dynamism. He argues that while the block size discussion is necessary, it is only serving as an example of the political issues that need to be addressed. Lombrozo suggests that external input may be required, such as a vote or hashing power. He also proposes building the dynamics of hard forks into the model rather than avoiding them altogether. Lombrozo acknowledges that hard forks are easy, but the difficulty lies in merging different branches. He suggests learning from git and designing the network to allow for merging.On May 31st, 2015 Matt Whitlock sent an email discussing Gavin's proposal to move Bitcoin forward with his own proposal, regardless of the agreement of other Bitcoin Core committers. While some miners and merchants may support the idea of larger blocks, there is a substantial risk that it could fail, so until there is actual consensus among the technical community it is best not to take the risk. The proposal is to gradually raise the block size limit using an approximately smooth function, without a step discontinuity, from 1 MB to 20 MB over the course of several years, beginning next March. It would be far more helpful if we focused on stuff that helps enable level 2 technologies so that Bitcoin can actually scale. Extending blocksize now would be nothing more than a political move. In order for bitcoin to survive, changes must be based on well thought out and discussed technical merits and not the result of political pressure.The current hard cap of 1 MB block is not enough to handle the increasing transaction volume as more and more people use Bitcoin. The proposed solution is to increase the block size hard cap to 20 MB, but this may not be a permanent fix as the need for larger blocks may arise again in the future. The possibility of other solutions like micropayment channels and offchain transactions that can easily function with 1 MB blocks is also considered. There are concerns about the proposed solution dividing Bitcoin XT and Bitcoin Core into different consensus and creating two altcoins instead of one Bitcoin. Matt Whitlock proposes an alternative solution to gradually raise the block size limit using an approximately smooth function from 1 MB to 20 MB over the course of several years, beginning next March. This gradual increase will allow time to discuss and fix any problem that may arise without panicking. Whitlock believes that ignoring the immediate problem is too risky and that if significantly larger blocks cause a serious problem for Bitcoin, then not making any change to Bitcoin Core will virtually assure that Bitcoin XT takes over. He proposes a way to satisfy both those who want larger blocks and those who want to be extremely cautious about changing the fundamental economic parameters of Bitcoin.Matt Whitlock has proposed a gradual increase in the block size limit of Bitcoin to avoid sudden changes that could potentially damage the currency. He acknowledges that Bitcoin could face problems if it does not raise the block size limit, but he believes that Gavin's proposal to suddenly increase the limit is too risky. Matt suggests using a linear growth function to smoothly adjust the block size limit from 1 MB to 20 MB over several years, beginning next March. His proposal aims to satisfy both those who want larger blocks and those who are cautious about changing the fundamental economic parameters of Bitcoin. Matt offers to implement this proposal and submit a pull request to Bitcoin Core. 2015-05-31T10:01:53+00:00 + Eric Lombrozo agrees with Drak's assessment that politics are inevitable in any consensus protocol seeking dynamism. He argues that while the block size discussion is necessary, it is only serving as an example of the political issues that need to be addressed. Lombrozo suggests that external input may be required, such as a vote or hashing power. He also proposes building the dynamics of hard forks into the model rather than avoiding them altogether. Lombrozo acknowledges that hard forks are easy, but the difficulty lies in merging different branches. He suggests learning from git and designing the network to allow for merging.On May 31st, 2015 Matt Whitlock sent an email discussing Gavin's proposal to move Bitcoin forward with his own proposal, regardless of the agreement of other Bitcoin Core committers. While some miners and merchants may support the idea of larger blocks, there is a substantial risk that it could fail, so until there is actual consensus among the technical community it is best not to take the risk. The proposal is to gradually raise the block size limit using an approximately smooth function, without a step discontinuity, from 1 MB to 20 MB over the course of several years, beginning next March. It would be far more helpful if we focused on stuff that helps enable level 2 technologies so that Bitcoin can actually scale. Extending blocksize now would be nothing more than a political move. In order for bitcoin to survive, changes must be based on well thought out and discussed technical merits and not the result of political pressure.The current hard cap of 1 MB block is not enough to handle the increasing transaction volume as more and more people use Bitcoin. The proposed solution is to increase the block size hard cap to 20 MB, but this may not be a permanent fix as the need for larger blocks may arise again in the future. The possibility of other solutions like micropayment channels and offchain transactions that can easily function with 1 MB blocks is also considered. There are concerns about the proposed solution dividing Bitcoin XT and Bitcoin Core into different consensus and creating two altcoins instead of one Bitcoin. Matt Whitlock proposes an alternative solution to gradually raise the block size limit using an approximately smooth function from 1 MB to 20 MB over the course of several years, beginning next March. This gradual increase will allow time to discuss and fix any problem that may arise without panicking. Whitlock believes that ignoring the immediate problem is too risky and that if significantly larger blocks cause a serious problem for Bitcoin, then not making any change to Bitcoin Core will virtually assure that Bitcoin XT takes over. He proposes a way to satisfy both those who want larger blocks and those who want to be extremely cautious about changing the fundamental economic parameters of Bitcoin.Matt Whitlock has proposed a gradual increase in the block size limit of Bitcoin to avoid sudden changes that could potentially damage the currency. He acknowledges that Bitcoin could face problems if it does not raise the block size limit, but he believes that Gavin's proposal to suddenly increase the limit is too risky. Matt suggests using a linear growth function to smoothly adjust the block size limit from 1 MB to 20 MB over several years, beginning next March. His proposal aims to satisfy both those who want larger blocks and those who are cautious about changing the fundamental economic parameters of Bitcoin. Matt offers to implement this proposal and submit a pull request to Bitcoin Core. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Proposed-additional-options-for-pruned-nodes.xml b/static/bitcoin-dev/May_2015/combined_Proposed-additional-options-for-pruned-nodes.xml index ac6a6245ae..5b8e8a8985 100644 --- a/static/bitcoin-dev/May_2015/combined_Proposed-additional-options-for-pruned-nodes.xml +++ b/static/bitcoin-dev/May_2015/combined_Proposed-additional-options-for-pruned-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed additional options for pruned nodes - 2023-08-01T12:41:52.056390+00:00 + 2025-10-11T22:09:38.484409+00:00 + python-feedgen Tier Nolan 2015-05-13 09:34:03+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Proposed additional options for pruned nodes - 2023-08-01T12:41:52.056390+00:00 + 2025-10-11T22:09:38.484625+00:00 - The discussion revolves around the issue of block coverage on Bitcoin nodes and the security concerns related to syncing the blockchain. Several proposals are made to address these issues. Daniel Kraft suggests dividing blocks into intervals with exponentially growing size and broadcasting information such as seed, M_bits_lsb, and N. Gregory Maxwell proposes a similar idea involving a PRNG and selecting intervals using it. Another proposal suggests using a sequence of start points generated by hashing a seed. There is a concern about randomness and the priority of tiny blocks.The discussion also addresses the problem of block sync horizon/cliff, where nodes need an average number of X blocks to sync and must fall back to archive nodes for older data. There is a suggestion to use torrents to download ancient data but concerns about centralization and efficiency are raised. Jeff Garzik suggests having a partial archive that stores only the most recent X% of the blockchain by default.The security of the network is a major concern, as attackers can disrupt a small part of the chain and cause a network-wide DoS. It is suggested to view this attack as a bandwidth exhaustion DoS on archive nodes. The discussion emphasizes the importance of providing incremental ways for people to participate in the network and maintaining security.Overall, the discussion focuses on finding solutions for block coverage, block sync, and security issues in the Bitcoin network. Various proposals and concerns are addressed, highlighting the need for efficient communication, compactness, uniformity, and resistance to attacks. The goal is to ensure efficient syncing, secure block storage, and participation in the network while addressing the challenges posed by the growth of the blockchain.Peter Todd proposed the idea of partial archival nodes that can store a subset of blocks, ensuring the availability of the entire blockchain even if no single node has the complete chain. To achieve this, a compact way of describing which blocks are stored is necessary. A node could indicate which blocks it stores using service bits by selecting two numbers: W (window), a power of 2, and P (position), a random value less than W. The node would store all blocks with a height of P mod W. This approach allows a node to discard half of its data while representing what is stored and increases the probability that at least someone has every block.On May 12, 2015, Jeff Garzik discussed the assumption that there will be a few archive nodes with the full blockchain and a majority of pruned nodes serving only the tail of the chains. In response, Peter Todd suggested partial archival nodes as a solution, enabling the storage of a subset of blocks to ensure the availability of the entire blockchain. The discussion focused on finding the best approach for handling the storage and retrieval of the Bitcoin blockchain.Gabe Appleton proposed a hybrid option for nodes to address the increasing storage needs and network security concerns. The idea involves storing a section of the blockchain fully (percentage-based) and selectively pruning all sections not included in it. This allows nodes to continue validating transactions while significantly reducing storage requirements. The proposal also suggests the introduction of a retroactive --max-size flag to prune the blockchain until a specified size, allowing for continued pruning over time while adhering to the sections defined by the network. However, concerns were raised about potential side effects and network vulnerabilities, particularly regarding Sybil resistance.The email thread dated May 12, 2015, discusses the proposal for a hybrid option in nodes to reduce storage needs while maintaining transaction validation capabilities. The suggested solution entails flipping the --no-wallet toggle, choosing a percentage-based section of the blockchain to store fully, and pruning all other sections. This approach resembles how Koorde works, with the network determining which sections to retrieve. The proposal aims to address concerns about increasing storage needs and switching to pruned nodes, offering a solution that distributes the full copy among multiple nodes and significantly reduces storage requirements. Jeff Garzik, a Bitcoin core developer and open-source evangelist, participated in the email thread.In response to concerns about the 20MB blockchain storage limit and network security, a user suggests a hybrid node option. This option involves flipping the --no-wallet toggle, selecting a percentage-based section of the blockchain to store fully, and pruning all other sections. By distributing the full copy among many nodes, individual storage needs are reduced while allowing for continued transaction validation. The network would determine which sections to retrieve based on peer data, similar to a Koorde implementation. The proposed method is expected to have minimal impact on security and could include a retroactive --max-size flag for ongoing pruning. However, there are concerns about potential side effects and vulnerabilities, including Sybil resistance. Feedback is sought regarding these issues. 2015-05-13T09:34:03+00:00 + The discussion revolves around the issue of block coverage on Bitcoin nodes and the security concerns related to syncing the blockchain. Several proposals are made to address these issues. Daniel Kraft suggests dividing blocks into intervals with exponentially growing size and broadcasting information such as seed, M_bits_lsb, and N. Gregory Maxwell proposes a similar idea involving a PRNG and selecting intervals using it. Another proposal suggests using a sequence of start points generated by hashing a seed. There is a concern about randomness and the priority of tiny blocks.The discussion also addresses the problem of block sync horizon/cliff, where nodes need an average number of X blocks to sync and must fall back to archive nodes for older data. There is a suggestion to use torrents to download ancient data but concerns about centralization and efficiency are raised. Jeff Garzik suggests having a partial archive that stores only the most recent X% of the blockchain by default.The security of the network is a major concern, as attackers can disrupt a small part of the chain and cause a network-wide DoS. It is suggested to view this attack as a bandwidth exhaustion DoS on archive nodes. The discussion emphasizes the importance of providing incremental ways for people to participate in the network and maintaining security.Overall, the discussion focuses on finding solutions for block coverage, block sync, and security issues in the Bitcoin network. Various proposals and concerns are addressed, highlighting the need for efficient communication, compactness, uniformity, and resistance to attacks. The goal is to ensure efficient syncing, secure block storage, and participation in the network while addressing the challenges posed by the growth of the blockchain.Peter Todd proposed the idea of partial archival nodes that can store a subset of blocks, ensuring the availability of the entire blockchain even if no single node has the complete chain. To achieve this, a compact way of describing which blocks are stored is necessary. A node could indicate which blocks it stores using service bits by selecting two numbers: W (window), a power of 2, and P (position), a random value less than W. The node would store all blocks with a height of P mod W. This approach allows a node to discard half of its data while representing what is stored and increases the probability that at least someone has every block.On May 12, 2015, Jeff Garzik discussed the assumption that there will be a few archive nodes with the full blockchain and a majority of pruned nodes serving only the tail of the chains. In response, Peter Todd suggested partial archival nodes as a solution, enabling the storage of a subset of blocks to ensure the availability of the entire blockchain. The discussion focused on finding the best approach for handling the storage and retrieval of the Bitcoin blockchain.Gabe Appleton proposed a hybrid option for nodes to address the increasing storage needs and network security concerns. The idea involves storing a section of the blockchain fully (percentage-based) and selectively pruning all sections not included in it. This allows nodes to continue validating transactions while significantly reducing storage requirements. The proposal also suggests the introduction of a retroactive --max-size flag to prune the blockchain until a specified size, allowing for continued pruning over time while adhering to the sections defined by the network. However, concerns were raised about potential side effects and network vulnerabilities, particularly regarding Sybil resistance.The email thread dated May 12, 2015, discusses the proposal for a hybrid option in nodes to reduce storage needs while maintaining transaction validation capabilities. The suggested solution entails flipping the --no-wallet toggle, choosing a percentage-based section of the blockchain to store fully, and pruning all other sections. This approach resembles how Koorde works, with the network determining which sections to retrieve. The proposal aims to address concerns about increasing storage needs and switching to pruned nodes, offering a solution that distributes the full copy among multiple nodes and significantly reduces storage requirements. Jeff Garzik, a Bitcoin core developer and open-source evangelist, participated in the email thread.In response to concerns about the 20MB blockchain storage limit and network security, a user suggests a hybrid node option. This option involves flipping the --no-wallet toggle, selecting a percentage-based section of the blockchain to store fully, and pruning all other sections. By distributing the full copy among many nodes, individual storage needs are reduced while allowing for continued transaction validation. The network would determine which sections to retrieve based on peer data, similar to a Koorde implementation. The proposed method is expected to have minimal impact on security and could include a retroactive --max-size flag for ongoing pruning. However, there are concerns about potential side effects and vulnerabilities, including Sybil resistance. Feedback is sought regarding these issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Proposed-alternatives-to-the-20MB-step-function.xml b/static/bitcoin-dev/May_2015/combined_Proposed-alternatives-to-the-20MB-step-function.xml index a36be9642a..04671174ef 100644 --- a/static/bitcoin-dev/May_2015/combined_Proposed-alternatives-to-the-20MB-step-function.xml +++ b/static/bitcoin-dev/May_2015/combined_Proposed-alternatives-to-the-20MB-step-function.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed alternatives to the 20MB step function - 2023-08-01T12:30:25.361158+00:00 + 2025-10-11T22:10:25.249295+00:00 + python-feedgen Marcel Jamin 2015-06-01 11:46:30+00:00 @@ -255,13 +256,13 @@ - python-feedgen + 2 Combined summary - Proposed alternatives to the 20MB step function - 2023-08-01T12:30:25.362112+00:00 + 2025-10-11T22:10:25.249615+00:00 - The ongoing debate and proposals regarding the block size limit in the Bitcoin network have been highlighted in the context. Various suggestions have been made, including making the block size limit a function of the number of transactions in the mempool, implementing dynamic scaling within a certain range, and introducing a consensus protocol for block sizes. The discussion acknowledges the need to balance scalability with decentralization and inclusivity.Gavin Andresen has proposed implementing a big increase in block size over time and seeking support from miners and infrastructure companies to run alternative versions of Bitcoin. However, there is disagreement on whether the block size should increase or remain constant, and how to measure merchant and exchange acceptance of bigger blocks.Mike Hearn suggested that the current 32mb cap on block sizes could be changed to at least some multiple of the maximum block size allowed. Another suggestion was to incorporate the required functionality into the merkle block message, allowing for sending headers messages with one header and merkleblock messages with a maximum of 1MB per message.The topic of block size and transaction throughput in Bitcoin was further discussed, with concerns raised about artificially limiting the network's organic growth. Gavin Andresen proposed a 20mb limit as a reasonable compromise, but also emphasized the importance of planning around global factors, rather than just American buying habits. Doubling the block size daily was considered imprudent, and a logarithmic increase in difficulty every 2016 blocks was suggested instead.There was a conversation about changing default settings for Bitcoin miners, with Gavin Andresen expressing skepticism towards this idea. He suggested a rule of "larger of 1MB or 2x average size" as a better option.Gavin Andresen also shared his opinion on fee pressure in the network, stating that block propagation should be made faster to eliminate technical reasons for miners producing small blocks. However, he emphasized that developers should not decide whether fees are too high or low.The fear associated with a maximum block size of twenty in Bitcoin was mentioned, with concerns raised about artificially throttling organic network growth. The discussion also touched on the balance between scaling and maintaining network stability.There were discussions about potentially setting the max size to be 20 times the average size instead. Different ideas were proposed for calculating the maximum block size, including using the median or average size of recent blocks.In terms of unspent transaction outputs (UTXOs), concerns were raised about incentives for miners to include more UTXOs in blocks. Suggestions were made to exclude UTXOs before a certain count and to store them as a fixed digest. There were also discussions about the difficulty of cryptocurrency mining and its impact on transaction fees.The article by Justus Ranvier proposes a solution where the block size is determined by the price of fees and the willingness of users to pay them, allowing for greater price discovery and alignment of incentives among network participants.During discussions about the maximum block size for Bitcoin, different proposals have been put forward. Joel Joonatan Kaartinen suggested using "bitcoin days destroyed" as a measure of demand for space in the blockchain, but Matt Whitlock pointed out flaws in this method. Whitlock argued that it does not account for future changes in bitcoin velocity and may not be relevant when large amounts of bitcoins are moved to new addresses.Gavin Andresen also proposed using the bitcoin days destroyed in transactions included in the block to determine the maximum block size. This suggestion has potential for scaling and maintaining a constant fee pressure. However, concerns were raised about its accuracy in reflecting the demand for blockchain space in the distant future when Bitcoin is more widely adopted. Further explanation is needed to ensure everyone understands the purpose of this proposal.In another discussion, various ideas were raised for determining the hard block size limit of Bitcoin. One proposal was to base the limit on bitcoin days destroyed, while another suggested allowing miners to vote on the limit. A third idea proposed making the limit a function of the blockchain length. Matt expressed support for the first proposal, as it utilizes existing data and eliminates the possibility of a mismatch between conscious votes and behavior. He cautioned against immediately jumping to a 20 MB limit, believing that it would avoid solving the problem in a controversial way.There are proponents and critics of the fixed 20 MB cap, with arguments presented for and against it. While it is the simplest solution currently proposed, it is acknowledged that it is not perfect. The speaker hopes for a less traumatic chain forking process and recalls a previous discussion about scheduling a fork every year to provide predictability. However, if things go well, there is no reason why the 20 MB limit would be permanent.In summary, discussions have taken place regarding the maximum block size for Bitcoin, with suggestions ranging from using "bitcoin days destroyed" to allowing miners to vote on the limit. The ultimate goal is to find a scalable and secure solution that supports the growth and adoption of blockchain technology. 2015-06-01T11:46:30+00:00 + The ongoing debate and proposals regarding the block size limit in the Bitcoin network have been highlighted in the context. Various suggestions have been made, including making the block size limit a function of the number of transactions in the mempool, implementing dynamic scaling within a certain range, and introducing a consensus protocol for block sizes. The discussion acknowledges the need to balance scalability with decentralization and inclusivity.Gavin Andresen has proposed implementing a big increase in block size over time and seeking support from miners and infrastructure companies to run alternative versions of Bitcoin. However, there is disagreement on whether the block size should increase or remain constant, and how to measure merchant and exchange acceptance of bigger blocks.Mike Hearn suggested that the current 32mb cap on block sizes could be changed to at least some multiple of the maximum block size allowed. Another suggestion was to incorporate the required functionality into the merkle block message, allowing for sending headers messages with one header and merkleblock messages with a maximum of 1MB per message.The topic of block size and transaction throughput in Bitcoin was further discussed, with concerns raised about artificially limiting the network's organic growth. Gavin Andresen proposed a 20mb limit as a reasonable compromise, but also emphasized the importance of planning around global factors, rather than just American buying habits. Doubling the block size daily was considered imprudent, and a logarithmic increase in difficulty every 2016 blocks was suggested instead.There was a conversation about changing default settings for Bitcoin miners, with Gavin Andresen expressing skepticism towards this idea. He suggested a rule of "larger of 1MB or 2x average size" as a better option.Gavin Andresen also shared his opinion on fee pressure in the network, stating that block propagation should be made faster to eliminate technical reasons for miners producing small blocks. However, he emphasized that developers should not decide whether fees are too high or low.The fear associated with a maximum block size of twenty in Bitcoin was mentioned, with concerns raised about artificially throttling organic network growth. The discussion also touched on the balance between scaling and maintaining network stability.There were discussions about potentially setting the max size to be 20 times the average size instead. Different ideas were proposed for calculating the maximum block size, including using the median or average size of recent blocks.In terms of unspent transaction outputs (UTXOs), concerns were raised about incentives for miners to include more UTXOs in blocks. Suggestions were made to exclude UTXOs before a certain count and to store them as a fixed digest. There were also discussions about the difficulty of cryptocurrency mining and its impact on transaction fees.The article by Justus Ranvier proposes a solution where the block size is determined by the price of fees and the willingness of users to pay them, allowing for greater price discovery and alignment of incentives among network participants.During discussions about the maximum block size for Bitcoin, different proposals have been put forward. Joel Joonatan Kaartinen suggested using "bitcoin days destroyed" as a measure of demand for space in the blockchain, but Matt Whitlock pointed out flaws in this method. Whitlock argued that it does not account for future changes in bitcoin velocity and may not be relevant when large amounts of bitcoins are moved to new addresses.Gavin Andresen also proposed using the bitcoin days destroyed in transactions included in the block to determine the maximum block size. This suggestion has potential for scaling and maintaining a constant fee pressure. However, concerns were raised about its accuracy in reflecting the demand for blockchain space in the distant future when Bitcoin is more widely adopted. Further explanation is needed to ensure everyone understands the purpose of this proposal.In another discussion, various ideas were raised for determining the hard block size limit of Bitcoin. One proposal was to base the limit on bitcoin days destroyed, while another suggested allowing miners to vote on the limit. A third idea proposed making the limit a function of the blockchain length. Matt expressed support for the first proposal, as it utilizes existing data and eliminates the possibility of a mismatch between conscious votes and behavior. He cautioned against immediately jumping to a 20 MB limit, believing that it would avoid solving the problem in a controversial way.There are proponents and critics of the fixed 20 MB cap, with arguments presented for and against it. While it is the simplest solution currently proposed, it is acknowledged that it is not perfect. The speaker hopes for a less traumatic chain forking process and recalls a previous discussion about scheduling a fork every year to provide predictability. However, if things go well, there is no reason why the 20 MB limit would be permanent.In summary, discussions have taken place regarding the maximum block size for Bitcoin, with suggestions ranging from using "bitcoin days destroyed" to allowing miners to vote on the limit. The ultimate goal is to find a scalable and secure solution that supports the growth and adoption of blockchain technology. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Proposed-alternatives-to-the-20MB-stepfunction.xml b/static/bitcoin-dev/May_2015/combined_Proposed-alternatives-to-the-20MB-stepfunction.xml index b3faf7cf63..270d15705f 100644 --- a/static/bitcoin-dev/May_2015/combined_Proposed-alternatives-to-the-20MB-stepfunction.xml +++ b/static/bitcoin-dev/May_2015/combined_Proposed-alternatives-to-the-20MB-stepfunction.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed alternatives to the 20MB stepfunction - 2023-08-01T12:54:02.900057+00:00 + 2025-10-11T22:10:29.498183+00:00 + python-feedgen Tier Nolan 2015-05-29 18:28:22+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Proposed alternatives to the 20MB stepfunction - 2023-08-01T12:54:02.901013+00:00 + 2025-10-11T22:10:29.498390+00:00 - In an email conversation, Raystonn expresses concern over the lower security proposed by Tier for extended blocks. They believe that this could delay the implementation of larger blocks and is not an optimal solution. Tier argues that the potential centralization risk lies in the lower security of the extended chain. However, full nodes would still verify the entire block, including the root and extended chains. The extended block would only be able to make changes to its rules, but people would have to voluntarily transfer coins to it. Despite having a lower level of security, the extended block may still be useful as it would contain a significant portion of the total bitcoins and would be responsible for most transactions. Those who want to store their coins long term can move them back to the root block where they can monitor them more closely. One drawback of Tier's proposal is that wallets would need to list two balances, making things more complex.The email thread also discusses the proposal for increasing the maximum block size and raises concerns about the potential delay caused by the lower security of extended blocks. The writer compares the current situation to the US Congress, where the support of stakeholders has become irrelevant due to the influence of lobbyists. They suggest secret ballots as a solution to eliminate the power of lobbyists in Bitcoin Core. The thread then delves into the technical aspect of increasing the block size through a soft fork using extended blocks with lower security but giving people the choice to move their money or not. This is presented as a fallback option if no consensus is reached.In another email exchange between Gavin Andresen and Pieter Wuille, the topic of increasing the block size is discussed. Andresen believes that the block size should increase but only after sufficient technological growth has been demonstrated to mitigate any risks. He refers to his blog posts on the subject for further details. While he acknowledges the risk of unforeseen consequences from a sudden jump to a 20MB maximum block size, he suggests that a dynamic increase would solve that problem.In a separate email thread from May 2015, Pieter Wuille expresses his opinion that developers should not be responsible for imposing economic policy on the Bitcoin network. He believes that hard forks should not be controversial and forcing the public to adopt a controversial change is an abuse of power that sets a dangerous precedent for future changes. Wuille argues that the block size is a compromise made by the network between utility and centralization pressure and should be treated as such. While he personally thinks the block size should increase, he believes it should only be done after sufficient technological growth has been demonstrated to support it without increased risk.Furthermore, in an email exchange between Gavin Andresen and Mike Hearn, Andresen expresses his belief that developers should avoid imposing economic policy. He argues that it is dangerous for Bitcoin and the core developers themselves to become a central point of attack for those wishing to disrupt Bitcoin. Instead, he believes that such matters are better left to a decentralized free market. The discussion also touches on the proposed alternatives to the 20MB maximum block size, with Hearn questioning why there is fee pressure at the moment and suggesting that block propagation should be made faster to eliminate the technical reasons for producing tiny blocks. Hearn proposes setting the maximum block size to be 20 times the average size, but Andresen finds this number too large and scary. He suggests using two as a neutral number, where half of the hashpower produces blocks two times as big and the other half produces empty blocks, keeping the maximum block size unchanged. Andresen concludes by restating his belief that developers should stay out of deciding economic policies and leave them to the decentralized free market. 2015-05-29T18:28:22+00:00 + In an email conversation, Raystonn expresses concern over the lower security proposed by Tier for extended blocks. They believe that this could delay the implementation of larger blocks and is not an optimal solution. Tier argues that the potential centralization risk lies in the lower security of the extended chain. However, full nodes would still verify the entire block, including the root and extended chains. The extended block would only be able to make changes to its rules, but people would have to voluntarily transfer coins to it. Despite having a lower level of security, the extended block may still be useful as it would contain a significant portion of the total bitcoins and would be responsible for most transactions. Those who want to store their coins long term can move them back to the root block where they can monitor them more closely. One drawback of Tier's proposal is that wallets would need to list two balances, making things more complex.The email thread also discusses the proposal for increasing the maximum block size and raises concerns about the potential delay caused by the lower security of extended blocks. The writer compares the current situation to the US Congress, where the support of stakeholders has become irrelevant due to the influence of lobbyists. They suggest secret ballots as a solution to eliminate the power of lobbyists in Bitcoin Core. The thread then delves into the technical aspect of increasing the block size through a soft fork using extended blocks with lower security but giving people the choice to move their money or not. This is presented as a fallback option if no consensus is reached.In another email exchange between Gavin Andresen and Pieter Wuille, the topic of increasing the block size is discussed. Andresen believes that the block size should increase but only after sufficient technological growth has been demonstrated to mitigate any risks. He refers to his blog posts on the subject for further details. While he acknowledges the risk of unforeseen consequences from a sudden jump to a 20MB maximum block size, he suggests that a dynamic increase would solve that problem.In a separate email thread from May 2015, Pieter Wuille expresses his opinion that developers should not be responsible for imposing economic policy on the Bitcoin network. He believes that hard forks should not be controversial and forcing the public to adopt a controversial change is an abuse of power that sets a dangerous precedent for future changes. Wuille argues that the block size is a compromise made by the network between utility and centralization pressure and should be treated as such. While he personally thinks the block size should increase, he believes it should only be done after sufficient technological growth has been demonstrated to support it without increased risk.Furthermore, in an email exchange between Gavin Andresen and Mike Hearn, Andresen expresses his belief that developers should avoid imposing economic policy. He argues that it is dangerous for Bitcoin and the core developers themselves to become a central point of attack for those wishing to disrupt Bitcoin. Instead, he believes that such matters are better left to a decentralized free market. The discussion also touches on the proposed alternatives to the 20MB maximum block size, with Hearn questioning why there is fee pressure at the moment and suggesting that block propagation should be made faster to eliminate the technical reasons for producing tiny blocks. Hearn proposes setting the maximum block size to be 20 times the average size, but Andresen finds this number too large and scary. He suggests using two as a neutral number, where half of the hashpower produces blocks two times as big and the other half produces empty blocks, keeping the maximum block size unchanged. Andresen concludes by restating his belief that developers should stay out of deciding economic policies and leave them to the decentralized free market. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Reducing-the-block-rate-instead-of-increasing-the-maximum-block-size.xml b/static/bitcoin-dev/May_2015/combined_Reducing-the-block-rate-instead-of-increasing-the-maximum-block-size.xml index 7d3476dfe5..2dc209a597 100644 --- a/static/bitcoin-dev/May_2015/combined_Reducing-the-block-rate-instead-of-increasing-the-maximum-block-size.xml +++ b/static/bitcoin-dev/May_2015/combined_Reducing-the-block-rate-instead-of-increasing-the-maximum-block-size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reducing the block rate instead of increasing the maximum block size - 2023-08-01T12:38:15.225257+00:00 + 2025-10-11T22:10:08.245701+00:00 + python-feedgen Sergio Lerner 2015-05-12 18:55:05+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Reducing the block rate instead of increasing the maximum block size - 2023-08-01T12:38:15.226270+00:00 + 2025-10-11T22:10:08.245906+00:00 - In a discussion about the block rate in Bitcoin, Leo Wandersleb expressed his belief that a one-minute block target would not have substantial support due to the delay between pool/network and miner causing stale shares. However, he acknowledged that a one-minute block target could reduce payout variance and make bitcoin more accessible as a payment method. In response, Sergio pushed for near-instant payments and opposed any changes that move the balance towards the economically upper billion. He dismissed concerns about increased traffic from SPV and proposed small improvements in the wire protocol to reduce traffic two-fold.Sergio Lerner discusses how reducing block propagation time in the Bitcoin network can lead to centralization of mining pools and reduced security. He explains that while mining pool administrators would need to invest in server infrastructure to achieve lower latency and higher bandwidth, most mining pools are run at a loss and have nothing to invest. Additionally, reducing block propagation time only on average case is good but it has to be considered what will happen in the worst-case scenario. Thousands of SPV wallets running in mobile devices may require upgrading. Sergio also highlights that thousands of blocks mean more block headers, which increases the amount of bandwidth SPV wallets need to catch up with the chain.The article discusses the tradeoff between propagation speed gain and blockchain fork rate in smaller blocks in Bitcoin. The author strongly advises against increasing the block generation rate in Bitcoin as it would be a controversial proposal and would not solve anything. A response from Dave Hudson points out that blacklisting miners who engage in bad behavior is not effective because large-scale miners can easily make themselves look like many smaller-scale miners. Anonymity on behalf of transaction validators and block makers makes it almost impossible to maintain any sanctions against anti-social behavior.In a discussion regarding blacklisting on the Bitcoin network, it was suggested to ban miners who engage in bad behavior. However, this method is flawed because large-scale miners can disguise themselves as smaller miners, making it difficult to identify and blacklist them. Additionally, anonymity for validators and block makers makes it virtually impossible to maintain sanctions against antisocial behavior. The only deterrent is the lack of incentives for miners to engage in such activity.In a discussion about potential attacks on the Bitcoin network, it was asked how blacklisting would be implemented. The response given was that miners who engage in harmful behavior can simply be banned from mining. However, it was also mentioned that any attack by miners only lasts for 10 minutes before being stopped. Therefore, excessive worry about these types of attacks on the network is unnecessary.Sergio Lerner has outlined arguments against reducing the block interval, including concerns about centralization, blockchain splits, decreased speed and efficiency of block verification and transmission, insufficient testing and research into technical/economic implications, and the possibility of adding networking optimizations later.The issue of increasing server bandwidth to achieve a tenfold increase in work distribution has been discussed. Latency is the main issue, with up to 15 seconds between the first and last pools to push headers to clients for the latest block. Some pools do not validate blocks but mirror other pools, making this an epidemic of invalidity rather than a solution. It is unclear whether there is even a single study of the stale rates within proof-of-work cryptocurrencies with lower than 1-minute block intervals like Bitcoin, Litecoin, Dogecoin, and Quarkcoin.The email proposes that reducing the block rate to 1 minute can be a better way to increase transactions/second than increasing the maximum block size. The author argues against several arguments for not reducing the block interval, including concerns about centralization, blockchain splits, security, and technical/economic implications. The author suggests that lowering the block rate can decrease the probability of block competition, and the decrease in security is only if participants wish to decrease it. The email provides evidence and research to back up these claims. The author also suggests that upgrades to SPV wallets and optimizations to the protocol can help reduce the impact on mobile devices and bandwidth. The email concludes that there have been insufficient testing and research into reducing the block rate but argues that the changes required are minor compared to other proposals. The email encourages consideration of reducing the block rate as opposed to increasing the block size through miners voting.The email argues that increasing the maximum block size is not the best way to increase transactions per second in Bitcoin. The author suggests decreasing the block rate to 1 minute while keeping the block size limit to 1 megabyte or increasing it from a lower value such as 100 kilobytes. The author backs up their claims with many hours of research simulating the Bitcoin network under different conditions. The email addresses and responds to arguments against reducing the block interval, including the potential for centralization, an increased probability of a blockchain split, decreased security, and insufficient testing. The email concludes that there are no good arguments against lowering the block rate. The changes required to lower the block rate comprise no more than 15 lines of code, much less than the number 2015-05-12T18:55:05+00:00 + In a discussion about the block rate in Bitcoin, Leo Wandersleb expressed his belief that a one-minute block target would not have substantial support due to the delay between pool/network and miner causing stale shares. However, he acknowledged that a one-minute block target could reduce payout variance and make bitcoin more accessible as a payment method. In response, Sergio pushed for near-instant payments and opposed any changes that move the balance towards the economically upper billion. He dismissed concerns about increased traffic from SPV and proposed small improvements in the wire protocol to reduce traffic two-fold.Sergio Lerner discusses how reducing block propagation time in the Bitcoin network can lead to centralization of mining pools and reduced security. He explains that while mining pool administrators would need to invest in server infrastructure to achieve lower latency and higher bandwidth, most mining pools are run at a loss and have nothing to invest. Additionally, reducing block propagation time only on average case is good but it has to be considered what will happen in the worst-case scenario. Thousands of SPV wallets running in mobile devices may require upgrading. Sergio also highlights that thousands of blocks mean more block headers, which increases the amount of bandwidth SPV wallets need to catch up with the chain.The article discusses the tradeoff between propagation speed gain and blockchain fork rate in smaller blocks in Bitcoin. The author strongly advises against increasing the block generation rate in Bitcoin as it would be a controversial proposal and would not solve anything. A response from Dave Hudson points out that blacklisting miners who engage in bad behavior is not effective because large-scale miners can easily make themselves look like many smaller-scale miners. Anonymity on behalf of transaction validators and block makers makes it almost impossible to maintain any sanctions against anti-social behavior.In a discussion regarding blacklisting on the Bitcoin network, it was suggested to ban miners who engage in bad behavior. However, this method is flawed because large-scale miners can disguise themselves as smaller miners, making it difficult to identify and blacklist them. Additionally, anonymity for validators and block makers makes it virtually impossible to maintain sanctions against antisocial behavior. The only deterrent is the lack of incentives for miners to engage in such activity.In a discussion about potential attacks on the Bitcoin network, it was asked how blacklisting would be implemented. The response given was that miners who engage in harmful behavior can simply be banned from mining. However, it was also mentioned that any attack by miners only lasts for 10 minutes before being stopped. Therefore, excessive worry about these types of attacks on the network is unnecessary.Sergio Lerner has outlined arguments against reducing the block interval, including concerns about centralization, blockchain splits, decreased speed and efficiency of block verification and transmission, insufficient testing and research into technical/economic implications, and the possibility of adding networking optimizations later.The issue of increasing server bandwidth to achieve a tenfold increase in work distribution has been discussed. Latency is the main issue, with up to 15 seconds between the first and last pools to push headers to clients for the latest block. Some pools do not validate blocks but mirror other pools, making this an epidemic of invalidity rather than a solution. It is unclear whether there is even a single study of the stale rates within proof-of-work cryptocurrencies with lower than 1-minute block intervals like Bitcoin, Litecoin, Dogecoin, and Quarkcoin.The email proposes that reducing the block rate to 1 minute can be a better way to increase transactions/second than increasing the maximum block size. The author argues against several arguments for not reducing the block interval, including concerns about centralization, blockchain splits, security, and technical/economic implications. The author suggests that lowering the block rate can decrease the probability of block competition, and the decrease in security is only if participants wish to decrease it. The email provides evidence and research to back up these claims. The author also suggests that upgrades to SPV wallets and optimizations to the protocol can help reduce the impact on mobile devices and bandwidth. The email concludes that there have been insufficient testing and research into reducing the block rate but argues that the changes required are minor compared to other proposals. The email encourages consideration of reducing the block rate as opposed to increasing the block size through miners voting.The email argues that increasing the maximum block size is not the best way to increase transactions per second in Bitcoin. The author suggests decreasing the block rate to 1 minute while keeping the block size limit to 1 megabyte or increasing it from a lower value such as 100 kilobytes. The author backs up their claims with many hours of research simulating the Bitcoin network under different conditions. The email addresses and responds to arguments against reducing the block interval, including the potential for centralization, an increased probability of a blockchain split, decreased security, and insufficient testing. The email concludes that there are no good arguments against lowering the block rate. The changes required to lower the block rate comprise no more than 15 lines of code, much less than the number - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml b/static/bitcoin-dev/May_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml index 3ca1934588..46b0f4d163 100644 --- a/static/bitcoin-dev/May_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml +++ b/static/bitcoin-dev/May_2015/combined_Relative-CHECKLOCKTIMEVERIFY-was-CLTV-proposal-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) - 2023-08-01T12:06:55.534846+00:00 + 2025-10-11T22:09:27.794578+00:00 + python-feedgen Tier Nolan 2015-05-06 22:09:59+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) - 2023-08-01T12:06:55.535908+00:00 + 2025-10-11T22:09:27.794766+00:00 - Several proposals and ideas were discussed by Bitcoin developers regarding the implementation of new opcodes and changes to the Bitcoin scripting system. One proposal was the addition of CHECKLOCKTIMEVERIFY (CLTV), which would make a transaction output unspendable until a certain point in the future. Another proposal suggested increasing the transaction version to achieve a similar outcome. Developers expressed concerns about changing the semantics of nSequence and the potential impact on previously valid transactions. Mark Friedenbach proposed an nSequence-based RCLTV proposal that was already reorg safe. Peter Todd and Matt Corallo discussed the idea of adding OP_RELATIVECHECKLOCKTIMEVERIFY (RCLTV) opcode, acknowledging its drawbacks but highlighting its usefulness for certain protocols. The conversations also touched on time-based locks and the potential incentive issues with mining. Timón proposed a new softfork rule to enforce setting the nHeight of CTxIn to the correct height. Discussions also revolved around implementing RCLTV and OP_MATURITY for more secure transactions against reorganization. In March 2015, Matt Corallo proposed requiring locktime to be at least N plus the input's height. Zooko preferred relative CHECKLOCKTIMEVERIFY over absolute CHECKLOCKTIMEVERIFY due to concerns about "race conditions."The article discusses the use of the CHECKLOCKTIMEVERIFY opcode in Bitcoin scripts and its applications. Despite challenges such as exposing script information and enforcing mempool invariants during reorganizations, CHECKLOCKTIMEVERIFY can be used in non-interactive time-locked refunds, two-factor wallets, and micropayment channels. Two-factor wallets utilize 2-of-2 multisig scriptPubKeys, allowing users to spend funds without the cooperation of the service by waiting for the expiry time. The article also addresses vulnerabilities in Bitcoin protocols and suggests solutions. It analyzes micropayment channels and proposes using the same scriptPubKey as the two-factor wallet example to solve issues with refund transactions. The PayPub protocol for trustless payments for information is discussed, highlighting a flaw in the existing implementation that can be addressed with scriptPubKeys. The challenge of proving sacrifices of coins to mining fees is mentioned, and CHECKLOCKTIMEVERIFY is suggested as a solution to discourage mining centralization. Finally, the article suggests replacing the nLockTime field entirely with a per-signature capability that would serve as proof of spendability. Detailed specifications and references are provided for these proposed solutions. 2015-05-06T22:09:59+00:00 + Several proposals and ideas were discussed by Bitcoin developers regarding the implementation of new opcodes and changes to the Bitcoin scripting system. One proposal was the addition of CHECKLOCKTIMEVERIFY (CLTV), which would make a transaction output unspendable until a certain point in the future. Another proposal suggested increasing the transaction version to achieve a similar outcome. Developers expressed concerns about changing the semantics of nSequence and the potential impact on previously valid transactions. Mark Friedenbach proposed an nSequence-based RCLTV proposal that was already reorg safe. Peter Todd and Matt Corallo discussed the idea of adding OP_RELATIVECHECKLOCKTIMEVERIFY (RCLTV) opcode, acknowledging its drawbacks but highlighting its usefulness for certain protocols. The conversations also touched on time-based locks and the potential incentive issues with mining. Timón proposed a new softfork rule to enforce setting the nHeight of CTxIn to the correct height. Discussions also revolved around implementing RCLTV and OP_MATURITY for more secure transactions against reorganization. In March 2015, Matt Corallo proposed requiring locktime to be at least N plus the input's height. Zooko preferred relative CHECKLOCKTIMEVERIFY over absolute CHECKLOCKTIMEVERIFY due to concerns about "race conditions."The article discusses the use of the CHECKLOCKTIMEVERIFY opcode in Bitcoin scripts and its applications. Despite challenges such as exposing script information and enforcing mempool invariants during reorganizations, CHECKLOCKTIMEVERIFY can be used in non-interactive time-locked refunds, two-factor wallets, and micropayment channels. Two-factor wallets utilize 2-of-2 multisig scriptPubKeys, allowing users to spend funds without the cooperation of the service by waiting for the expiry time. The article also addresses vulnerabilities in Bitcoin protocols and suggests solutions. It analyzes micropayment channels and proposes using the same scriptPubKey as the two-factor wallet example to solve issues with refund transactions. The PayPub protocol for trustless payments for information is discussed, highlighting a flaw in the existing implementation that can be addressed with scriptPubKeys. The challenge of proving sacrifices of coins to mining fees is mentioned, and CHECKLOCKTIMEVERIFY is suggested as a solution to discourage mining centralization. Finally, the article suggests replacing the nLockTime field entirely with a per-signature capability that would serve as proof of spendability. Detailed specifications and references are provided for these proposed solutions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Removing-transaction-data-from-blocks.xml b/static/bitcoin-dev/May_2015/combined_Removing-transaction-data-from-blocks.xml index 8657d64fcb..4295f21695 100644 --- a/static/bitcoin-dev/May_2015/combined_Removing-transaction-data-from-blocks.xml +++ b/static/bitcoin-dev/May_2015/combined_Removing-transaction-data-from-blocks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Removing transaction data from blocks - 2023-08-01T12:35:17.589520+00:00 + 2025-10-11T22:09:36.360831+00:00 + python-feedgen Pieter Wuille 2015-05-08 14:52:28+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Removing transaction data from blocks - 2023-08-01T12:35:17.589520+00:00 + 2025-10-11T22:09:36.360974+00:00 - During the DevCore London event, Gavin Andresen put forward a proposal to improve the efficiency of block distribution in Bitcoin. He suggested distributing newly minted blocks as block headers along with all the transaction hashes included in the block, rather than sending the entire block. This approach has several advantages, including reducing the size of blocks being sent over the network and eliminating the block size limit. By only sending transactions once and utilizing smaller blocks, the network can operate more efficiently.However, implementing this idea would require changes to Bitcoin Core's internals, such as introducing a new block format and developing a method to bulk-request missing transactions. Several other ideas for reducing block size have also been discussed. Matt Corallo has proposed a relay network, Gavin Andresen has suggested IBLT based set reconciliation for blocks, and Greg Maxwell has proposed network block coding based on erasure coding, which also supports sharding.The primary goal of reducing block size is to minimize propagation delay, which in turn reduces forking rates. Fast propagation is crucial for full nodes to prevent centralization pressure. It is important to note that these techniques do not completely eliminate the need for block size, as all transactions still have to be transferred and processed. However, by optimizing block distribution and communication mechanisms, processing overheads and unnecessary roundtrips can be minimized.Various individuals are currently working on refining and optimizing these proposed mechanisms to make them practical and usable. Gavin's idea of distributing block headers and transaction hashes instead of full blocks is an interesting approach, but further input from experts familiar with Bitcoin Core's internals is necessary to assess the feasibility and potential impact of these changes. 2015-05-08T14:52:28+00:00 + During the DevCore London event, Gavin Andresen put forward a proposal to improve the efficiency of block distribution in Bitcoin. He suggested distributing newly minted blocks as block headers along with all the transaction hashes included in the block, rather than sending the entire block. This approach has several advantages, including reducing the size of blocks being sent over the network and eliminating the block size limit. By only sending transactions once and utilizing smaller blocks, the network can operate more efficiently.However, implementing this idea would require changes to Bitcoin Core's internals, such as introducing a new block format and developing a method to bulk-request missing transactions. Several other ideas for reducing block size have also been discussed. Matt Corallo has proposed a relay network, Gavin Andresen has suggested IBLT based set reconciliation for blocks, and Greg Maxwell has proposed network block coding based on erasure coding, which also supports sharding.The primary goal of reducing block size is to minimize propagation delay, which in turn reduces forking rates. Fast propagation is crucial for full nodes to prevent centralization pressure. It is important to note that these techniques do not completely eliminate the need for block size, as all transactions still have to be transferred and processed. However, by optimizing block distribution and communication mechanisms, processing overheads and unnecessary roundtrips can be minimized.Various individuals are currently working on refining and optimizing these proposed mechanisms to make them practical and usable. Gavin's idea of distributing block headers and transaction hashes instead of full blocks is an interesting approach, but further input from experts familiar with Bitcoin Core's internals is necessary to assess the feasibility and potential impact of these changes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Scaling-Bitcoin-with-Subchains.xml b/static/bitcoin-dev/May_2015/combined_Scaling-Bitcoin-with-Subchains.xml index 342164a46f..8a599a728e 100644 --- a/static/bitcoin-dev/May_2015/combined_Scaling-Bitcoin-with-Subchains.xml +++ b/static/bitcoin-dev/May_2015/combined_Scaling-Bitcoin-with-Subchains.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Scaling Bitcoin with Subchains - 2023-08-01T12:46:53.338981+00:00 + 2025-10-11T22:09:51.237898+00:00 + python-feedgen Andrew 2015-06-16 19:04:44+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Scaling Bitcoin with Subchains - 2023-08-01T12:46:53.339983+00:00 + 2025-10-11T22:09:51.238059+00:00 - The email thread discussed various proposals and ideas to scale blockchain technology, specifically focusing on Bitcoin. One proposal suggested merge-mining, where the parent chain includes the hashes of its children's headers as transactions. This would incentivize parents to validate their children by collecting fees from them. Another proposal suggested a treechain-like subchain system, where miners can only mine certain parts of the tree to ensure fairness. However, no solid design has been developed yet for this approach.The discussion also touched on the possibility of increasing the block size limit through a soft fork with sidechains in the future. Sidechains were seen as a way to achieve horizontal scaling and sharding while maintaining the primary security parameters of the main chain. However, some participants argued that sidechains do not offer a useful compromise between validation and non-validation. They believed that validation should either be done for everything or not at all. Concerns were also expressed about the complexity and delays introduced by sidechains.There was also a debate about the importance of validation in blockchain technology. Some argued that validation is necessary for all transactions, while others suggested probabilistic verification or validating a random subset of scripts. The consensus was that sidechains are not a solution for scaling up blockchain technology.The participants discussed the advantages and disadvantages of different proposals, such as storing only headers or full blocks, filtering transactions based on criteria, and the risk of pruned nodes. They emphasized the need for a proper system that ensures decentralization, security, and scalability.The email thread focused on a proposal by Andrew Poelstra to scale Bitcoin without increasing the block size. The proposal suggested creating child chains linked to the main blockchain, which would increase the network's total capacity for storing transactions. The proposal aimed to promote decentralization by allowing participants to produce the necessary devices without relying on centralized powers.While some developers supported the proposal and offered suggestions for implementation, others raised concerns and objections. Specific sidechain problems mentioned in previous research were brought up as potential issues. Gavin Andresen objected to the proposal without providing an explanation for his objections. Mike Hearn expressed concerns about the costs and limitations of hard drives and proposed tape backup as a more viable storage option. He also questioned Poelstra's motivations, wondering if they stemmed from philosophical beliefs or self-interest.In response to Andrew's concern regarding Bitcoin's reliance on hard disk storage, another participant suggested using tape backup technology instead. They provided a link to an article about Sony's development of tape technology capable of storing 185 terabytes per cartridge. While sharing the cost of a blockchain archive with others was not seen as a significant concern, caution was advised against validating the chain on compromised computers.To address the block size limit increase problem, the author proposed a partitioned system with ten 1 MB chains below the main chain. This arrangement would allow larger transactions to be processed through the top chain, while middle and small-sized transactions would be verified by one of the middle or bottom chains respectively. Regular users would be able to store lifetime transactions on a 5 TB drive. Additionally, the author suggested that people should be able to validate all blocks rather than just a pruned part to counter compromised machines. This would enable individuals to access information about Bitcoin transactions comparable to large data centers, potentially exposing government or corporate corruption.In terms of implementation, the author proposed keeping the current chain as the top chain and creating ten level 2 chains that also store Bitcoin. To incentivize people to continue mining on the level 1 chain, the author suggested forcing it into the protocol that anyone mining on level 2 must also mine on level 1, with a similar requirement for subsequent levels. Even if people stop using level 1, any owned bitcoin in the level 1 chain can be transferred to level 2 while still maintaining 1 MB blocks due to the partitioning scheme. The author acknowledged having only a high-level understanding of the Bitcoin protocol but believed that his proposal could work with a soft fork.In conclusion, the email thread explored various proposals and ideas to scale blockchain technology, particularly focusing on Bitcoin. Different approaches, such as merge-mining, treechain-like subchains, and sidechains, were discussed, along with their potential benefits and challenges. While no definitive solution was reached, the participants acknowledged the importance of ongoing research and development in this area to address scalability, validation, mining decentralization, and security concerns. 2015-06-16T19:04:44+00:00 + The email thread discussed various proposals and ideas to scale blockchain technology, specifically focusing on Bitcoin. One proposal suggested merge-mining, where the parent chain includes the hashes of its children's headers as transactions. This would incentivize parents to validate their children by collecting fees from them. Another proposal suggested a treechain-like subchain system, where miners can only mine certain parts of the tree to ensure fairness. However, no solid design has been developed yet for this approach.The discussion also touched on the possibility of increasing the block size limit through a soft fork with sidechains in the future. Sidechains were seen as a way to achieve horizontal scaling and sharding while maintaining the primary security parameters of the main chain. However, some participants argued that sidechains do not offer a useful compromise between validation and non-validation. They believed that validation should either be done for everything or not at all. Concerns were also expressed about the complexity and delays introduced by sidechains.There was also a debate about the importance of validation in blockchain technology. Some argued that validation is necessary for all transactions, while others suggested probabilistic verification or validating a random subset of scripts. The consensus was that sidechains are not a solution for scaling up blockchain technology.The participants discussed the advantages and disadvantages of different proposals, such as storing only headers or full blocks, filtering transactions based on criteria, and the risk of pruned nodes. They emphasized the need for a proper system that ensures decentralization, security, and scalability.The email thread focused on a proposal by Andrew Poelstra to scale Bitcoin without increasing the block size. The proposal suggested creating child chains linked to the main blockchain, which would increase the network's total capacity for storing transactions. The proposal aimed to promote decentralization by allowing participants to produce the necessary devices without relying on centralized powers.While some developers supported the proposal and offered suggestions for implementation, others raised concerns and objections. Specific sidechain problems mentioned in previous research were brought up as potential issues. Gavin Andresen objected to the proposal without providing an explanation for his objections. Mike Hearn expressed concerns about the costs and limitations of hard drives and proposed tape backup as a more viable storage option. He also questioned Poelstra's motivations, wondering if they stemmed from philosophical beliefs or self-interest.In response to Andrew's concern regarding Bitcoin's reliance on hard disk storage, another participant suggested using tape backup technology instead. They provided a link to an article about Sony's development of tape technology capable of storing 185 terabytes per cartridge. While sharing the cost of a blockchain archive with others was not seen as a significant concern, caution was advised against validating the chain on compromised computers.To address the block size limit increase problem, the author proposed a partitioned system with ten 1 MB chains below the main chain. This arrangement would allow larger transactions to be processed through the top chain, while middle and small-sized transactions would be verified by one of the middle or bottom chains respectively. Regular users would be able to store lifetime transactions on a 5 TB drive. Additionally, the author suggested that people should be able to validate all blocks rather than just a pruned part to counter compromised machines. This would enable individuals to access information about Bitcoin transactions comparable to large data centers, potentially exposing government or corporate corruption.In terms of implementation, the author proposed keeping the current chain as the top chain and creating ten level 2 chains that also store Bitcoin. To incentivize people to continue mining on the level 1 chain, the author suggested forcing it into the protocol that anyone mining on level 2 must also mine on level 1, with a similar requirement for subsequent levels. Even if people stop using level 1, any owned bitcoin in the level 1 chain can be transferred to level 2 while still maintaining 1 MB blocks due to the partitioning scheme. The author acknowledged having only a high-level understanding of the Bitcoin protocol but believed that his proposal could work with a soft fork.In conclusion, the email thread explored various proposals and ideas to scale blockchain technology, particularly focusing on Bitcoin. Different approaches, such as merge-mining, treechain-like subchains, and sidechains, were discussed, along with their potential benefits and challenges. While no definitive solution was reached, the participants acknowledged the importance of ongoing research and development in this area to address scalability, validation, mining decentralization, and security concerns. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Solution-for-Block-Size-Increase.xml b/static/bitcoin-dev/May_2015/combined_Solution-for-Block-Size-Increase.xml index 35da300bef..a639d3d8c2 100644 --- a/static/bitcoin-dev/May_2015/combined_Solution-for-Block-Size-Increase.xml +++ b/static/bitcoin-dev/May_2015/combined_Solution-for-Block-Size-Increase.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Solution for Block Size Increase - 2023-08-01T12:26:08.571490+00:00 + 2025-10-11T22:09:29.919695+00:00 + python-feedgen Thy Shizzle 2015-05-08 04:12:15+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Solution for Block Size Increase - 2023-08-01T12:26:08.571490+00:00 + 2025-10-11T22:09:29.919836+00:00 - Nicolas Dorier has proposed a solution to the block size increase problem in Bitcoin that aims to eliminate controversy and be immediately applicable. The proposal focuses on relieving core developers from acting as central bankers and promoting decentralization. According to Dorier, decisions regarding block size should be based solely on technical and decentralization considerations, rather than economic, political, or ideological principles.The proposed solution involves implementing block voting, where miners vote for the desired block size at the next deadline. The median of these votes would then be implemented as the new block size limit. This approach addresses various objectives, including accommodating increasing demand for larger block sizes, expanding network capacity and storage, and aligning Bitcoin with the desires of miners.However, there are uncertainties surrounding the proposed solution. It remains unknown how it would impact Bitcoin's core stability, and whether a better statistical function could be employed. Despite these uncertainties, Dorier urges core developers to step away from their role as bankers and focus on their expertise.The author emphasizes the need to reject arguments based on economic, political, and ideological principles when determining the future of Bitcoin. Instead, decisions should be made based solely on technical and decentralization considerations. The author also highlights the peculiarity of the TCP backoff game and the importance of avoiding decisions driven by maximizing metrics, favoring technical considerations instead.In conclusion, Dorier proposes a solution to the block size problem in Bitcoin that seeks to achieve consensus without controversy, relieve core developers from the central banker role, and promote decentralization. The proposed solution utilizes block voting to determine the new block size limit. While uncertainties exist regarding its impact on core stability and the possibility of a better statistical function, the author calls for a focus on technical decision-making and avoidance of decisions driven solely by economic or political factors. 2015-05-08T04:12:15+00:00 + Nicolas Dorier has proposed a solution to the block size increase problem in Bitcoin that aims to eliminate controversy and be immediately applicable. The proposal focuses on relieving core developers from acting as central bankers and promoting decentralization. According to Dorier, decisions regarding block size should be based solely on technical and decentralization considerations, rather than economic, political, or ideological principles.The proposed solution involves implementing block voting, where miners vote for the desired block size at the next deadline. The median of these votes would then be implemented as the new block size limit. This approach addresses various objectives, including accommodating increasing demand for larger block sizes, expanding network capacity and storage, and aligning Bitcoin with the desires of miners.However, there are uncertainties surrounding the proposed solution. It remains unknown how it would impact Bitcoin's core stability, and whether a better statistical function could be employed. Despite these uncertainties, Dorier urges core developers to step away from their role as bankers and focus on their expertise.The author emphasizes the need to reject arguments based on economic, political, and ideological principles when determining the future of Bitcoin. Instead, decisions should be made based solely on technical and decentralization considerations. The author also highlights the peculiarity of the TCP backoff game and the importance of avoiding decisions driven by maximizing metrics, favoring technical considerations instead.In conclusion, Dorier proposes a solution to the block size problem in Bitcoin that seeks to achieve consensus without controversy, relieve core developers from the central banker role, and promote decentralization. The proposed solution utilizes block voting to determine the new block size limit. While uncertainties exist regarding its impact on core stability and the possibility of a better statistical function, the author calls for a focus on technical decision-making and avoidance of decisions driven solely by economic or political factors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Version-bits-proposal.xml b/static/bitcoin-dev/May_2015/combined_Version-bits-proposal.xml index 678ee37170..06d7ccd558 100644 --- a/static/bitcoin-dev/May_2015/combined_Version-bits-proposal.xml +++ b/static/bitcoin-dev/May_2015/combined_Version-bits-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Version bits proposal - 2023-08-01T12:50:48.992239+00:00 + 2025-10-11T22:09:46.987547+00:00 + python-feedgen Pieter Wuille 2015-06-03 20:42:44+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Version bits proposal - 2023-08-01T12:50:48.992239+00:00 + 2025-10-11T22:09:46.987712+00:00 - On May 26, 2015, Pieter Wuille proposed a plan for coordinating future soft-forking consensus changes on Bitcoin. The proposal supports multiple parallel changes and changes that get permanently rejected without obstructing the rollout of others. Wuille suggested using the mailing list for commenting as the gist does not support notifying participants of new comments. This joint work was done with Peter Todd and Greg Maxwell. The plan received feedback, and Wuille plans to address it and work on an implementation next week.The email conversation is a discussion on the use of the median time and nVersion soft-fork mechanisms for Bitcoin Improvement Proposals (BIPs). The median time mechanism allows hashing power to show what time they think it is, while the nVersion soft-fork mechanism enables hashing power to indicate which features they want to support. The deadline for BIPs need not be set accurately; a roughly six-month deadline should suffice, and a majority of miners are needed to abuse the median time. Increasing the number of blocks used in the median could reduce "noise". Each bit is assigned to a particular BIP for a specific range of times or blocks, and if block numbers were used for the deadline, one only needs to check the block index for the deadline block. The block at height deadline would indicate whether the BIP was locked in. Block time could still be used as long as the block height was set after that. For each block height, there is a set of known BIP bits that are allowed, and once the final deadline passes, the expected mask is zeros. There was some ambiguity in phrasing regarding changing the 95% rule, where 75% is needed to start applying it, and 95% to start rejecting blocks that do not apply it.In a discussion about manipulating the merkle tree in Bitcoin, Christian Decker and Patrick Strateman agree that there is no need to misuse the version field. Decker states that there is enough variability in the merkle tree, including and excluding transactions, and even the scriptSig of the coinbase transaction, which influences the merkle root. He has a fundamental dislike of retroactively changing semantics and thinks that the version field should only be used for that purpose. Strateman argues that any reasonable micro-controller can build merkle tree roots significantly faster than necessary, with an RPi 1 model B doing 2451050 SHA256 ops/second. Sergio Lerner likes the idea but suggests leaving at least 16 bits of the version fixed as an extra-nonce to avoid miners using them as a nonce and interfering with the soft-fork voting system. In this way, miners could permute transactions in the block by permuting the internal merkle tree nodes at increasing depths, making the tree manipulations maximum depth independent and possibly even transaction-independent, depending on how much depth in the tree of hashes are permutation safe.In a discussion on the Bitcoin-development mailing list, Chris expressed his dislike of retroactively changing semantics and proposed that the version field should only be used for its intended purpose. He also voiced support for Sipa's proposal to flag support for a fork in the version field, although he did not particularly like this solution. The discussion also included Patrick Strateman's argument that there is no need to misuse the version field, as micro-controllers can build merkle tree roots faster than necessary. Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and disrupting the soft-fork voting system. Lerner's original proposal can be found on GitHub.The context discusses the efficiency of building merkle tree roots using micro-controllers. The writer argues that any reasonable micro-controller can perform this task much faster than necessary. For instance, a controller with 1 Th/s walks the nonce range in just 4.3ms. The largest valid merkle trees are 14 nodes high, which means that translating them to SHA256 operations would require 28 ops per 4.3 ms or 6511 ops/second. However, for reference, an RPi 1 model B performs 2451050 SHA256 ops/second. In response to this context, Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce. He believes that if not done, miners may use them as a nonce and interfere with the soft-fork voting system. The writer provided a link to their original proposal on Github.The author of the context suggests leaving 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and interfering with the soft-fork voting system. The author provides a link to their original proposal in a GitHub pull request. It is unclear what exactly the proposal entails, but it may provide more details on how the extra-nonce would work. Overall, the author seems to be concerned about maintaining the integrity of the soft 2015-06-03T20:42:44+00:00 + On May 26, 2015, Pieter Wuille proposed a plan for coordinating future soft-forking consensus changes on Bitcoin. The proposal supports multiple parallel changes and changes that get permanently rejected without obstructing the rollout of others. Wuille suggested using the mailing list for commenting as the gist does not support notifying participants of new comments. This joint work was done with Peter Todd and Greg Maxwell. The plan received feedback, and Wuille plans to address it and work on an implementation next week.The email conversation is a discussion on the use of the median time and nVersion soft-fork mechanisms for Bitcoin Improvement Proposals (BIPs). The median time mechanism allows hashing power to show what time they think it is, while the nVersion soft-fork mechanism enables hashing power to indicate which features they want to support. The deadline for BIPs need not be set accurately; a roughly six-month deadline should suffice, and a majority of miners are needed to abuse the median time. Increasing the number of blocks used in the median could reduce "noise". Each bit is assigned to a particular BIP for a specific range of times or blocks, and if block numbers were used for the deadline, one only needs to check the block index for the deadline block. The block at height deadline would indicate whether the BIP was locked in. Block time could still be used as long as the block height was set after that. For each block height, there is a set of known BIP bits that are allowed, and once the final deadline passes, the expected mask is zeros. There was some ambiguity in phrasing regarding changing the 95% rule, where 75% is needed to start applying it, and 95% to start rejecting blocks that do not apply it.In a discussion about manipulating the merkle tree in Bitcoin, Christian Decker and Patrick Strateman agree that there is no need to misuse the version field. Decker states that there is enough variability in the merkle tree, including and excluding transactions, and even the scriptSig of the coinbase transaction, which influences the merkle root. He has a fundamental dislike of retroactively changing semantics and thinks that the version field should only be used for that purpose. Strateman argues that any reasonable micro-controller can build merkle tree roots significantly faster than necessary, with an RPi 1 model B doing 2451050 SHA256 ops/second. Sergio Lerner likes the idea but suggests leaving at least 16 bits of the version fixed as an extra-nonce to avoid miners using them as a nonce and interfering with the soft-fork voting system. In this way, miners could permute transactions in the block by permuting the internal merkle tree nodes at increasing depths, making the tree manipulations maximum depth independent and possibly even transaction-independent, depending on how much depth in the tree of hashes are permutation safe.In a discussion on the Bitcoin-development mailing list, Chris expressed his dislike of retroactively changing semantics and proposed that the version field should only be used for its intended purpose. He also voiced support for Sipa's proposal to flag support for a fork in the version field, although he did not particularly like this solution. The discussion also included Patrick Strateman's argument that there is no need to misuse the version field, as micro-controllers can build merkle tree roots faster than necessary. Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and disrupting the soft-fork voting system. Lerner's original proposal can be found on GitHub.The context discusses the efficiency of building merkle tree roots using micro-controllers. The writer argues that any reasonable micro-controller can perform this task much faster than necessary. For instance, a controller with 1 Th/s walks the nonce range in just 4.3ms. The largest valid merkle trees are 14 nodes high, which means that translating them to SHA256 operations would require 28 ops per 4.3 ms or 6511 ops/second. However, for reference, an RPi 1 model B performs 2451050 SHA256 ops/second. In response to this context, Sergio Lerner suggested leaving at least 16 bits of the version fixed as an extra-nonce. He believes that if not done, miners may use them as a nonce and interfere with the soft-fork voting system. The writer provided a link to their original proposal on Github.The author of the context suggests leaving 16 bits of the version fixed as an extra-nonce to prevent miners from using them as a nonce and interfering with the soft-fork voting system. The author provides a link to their original proposal in a GitHub pull request. It is unclear what exactly the proposal entails, but it may provide more details on how the extra-nonce would work. Overall, the author seems to be concerned about maintaining the integrity of the soft - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Virtual-Notary-.xml b/static/bitcoin-dev/May_2015/combined_Virtual-Notary-.xml index b994722e3a..f4dd54bb02 100644 --- a/static/bitcoin-dev/May_2015/combined_Virtual-Notary-.xml +++ b/static/bitcoin-dev/May_2015/combined_Virtual-Notary-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Virtual Notary. - 2023-08-01T12:48:31.024450+00:00 + 2025-10-11T22:10:06.120839+00:00 + python-feedgen Mike Hearn 2015-05-25 18:07:09+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Virtual Notary. - 2023-08-01T12:48:31.024450+00:00 + 2025-10-11T22:10:06.121001+00:00 - During a conversation, someone praised a tool that could serve as a building block for oracle-based services but acknowledged the annoyance of working with X.509. They suggested documenting the process of extracting data from a certificate and highlighted two issues: the difficulty of working with X.509 and the presence of embedded text within the certificate, which is not developer-friendly and poses the risk of parsing errors. To address these concerns, they proposed embedding either a protocol buffer or DER encoded structure inside the extension, enabling developers to extract notarized data directly without additional parsing.Jonas Schnelli expressed his appreciation for http://www.deedbot.org, a website providing proof of existence and ownership for various types of information such as Bitcoin funds, real estate value, DNS ownership, and web page contents. The generated factoids can be recorded on the blockchain or included in a free attestation chain maintained by the website. Each factoid has a permanent URL and an available X.509 certificate for download. However, Schnelli suggested improvements to enhance the user experience, including resolving issues with Bitcoin payment verification and adding a "US only" badge for weather and real estate notarization. Additionally, he proposed two ideas: decentralizing the notary service log through an open-source P2P daemon and introducing an open-source UI app to examine certificates, showcasing independence from the website and its services.A website has been established to offer proof of various facts such as Bitcoin funds, address ownership, tweets, real estate value, DNS ownership, existence, web page contents, and weather conditions. The site ensures privacy by not revealing public addresses or fund location on the blockchain. Factoids can be recorded on the blockchain by paying for the transaction using Bitcoin or PayPal. The website provides a permanent URL for each factoid and allows users to download an X.509 certificate, ensuring its preservation independently from the website. However, the site requires improvement in terms of user experience and the resolution of payment verification issues. Furthermore, weather and real estate notarization are limited to the United States. Two ideas have been proposed: decentralizing the notary service log through an open-source P2P daemon and introducing an open-source UI app for examining certificates, demonstrating independence from the website and its services.In May 2015, Emin Gün Sirer, an American computer science professor, introduced the Virtual Notary project as an online witness or attestor to various factoids. The project aimed to provide proof of Bitcoin funds, address ownership, and tweets without disclosing public addresses or fund location on the blockchain. Simultaneously, a subsidiary of Dunvegan Space Systems pursued a similar concept. Interested parties were advised to email JGarzik at DSS.co for more information about the project. Jeff Garzik, a Bitcoin core developer and open-source evangelist, concluded the email with his credentials and included a link to the BitPay, Inc. website.The Virtual Notary project serves as an online witness for factoids, offering proof of Bitcoin funds, address ownership, tweets, real estate value, DNS ownership, existence, web page contents, and weather conditions. Factoids can be recorded on the blockchain or included in a free attestation chain maintained by the website. The site provides a permanent URL for each factoid and allows users to download an X.509 certificate. They actively seek individuals to further develop the service and welcome suggestions for new types of proof or factoids, as well as ideas for building a business case around the core concept. For more information, visit http://virtual-notary.org, and to explore the various factoids and their use cases, refer to the write-up at http://hackingdistributed.com/2013/06/20/virtual-notary-intro/. 2015-05-25T18:07:09+00:00 + During a conversation, someone praised a tool that could serve as a building block for oracle-based services but acknowledged the annoyance of working with X.509. They suggested documenting the process of extracting data from a certificate and highlighted two issues: the difficulty of working with X.509 and the presence of embedded text within the certificate, which is not developer-friendly and poses the risk of parsing errors. To address these concerns, they proposed embedding either a protocol buffer or DER encoded structure inside the extension, enabling developers to extract notarized data directly without additional parsing.Jonas Schnelli expressed his appreciation for http://www.deedbot.org, a website providing proof of existence and ownership for various types of information such as Bitcoin funds, real estate value, DNS ownership, and web page contents. The generated factoids can be recorded on the blockchain or included in a free attestation chain maintained by the website. Each factoid has a permanent URL and an available X.509 certificate for download. However, Schnelli suggested improvements to enhance the user experience, including resolving issues with Bitcoin payment verification and adding a "US only" badge for weather and real estate notarization. Additionally, he proposed two ideas: decentralizing the notary service log through an open-source P2P daemon and introducing an open-source UI app to examine certificates, showcasing independence from the website and its services.A website has been established to offer proof of various facts such as Bitcoin funds, address ownership, tweets, real estate value, DNS ownership, existence, web page contents, and weather conditions. The site ensures privacy by not revealing public addresses or fund location on the blockchain. Factoids can be recorded on the blockchain by paying for the transaction using Bitcoin or PayPal. The website provides a permanent URL for each factoid and allows users to download an X.509 certificate, ensuring its preservation independently from the website. However, the site requires improvement in terms of user experience and the resolution of payment verification issues. Furthermore, weather and real estate notarization are limited to the United States. Two ideas have been proposed: decentralizing the notary service log through an open-source P2P daemon and introducing an open-source UI app for examining certificates, demonstrating independence from the website and its services.In May 2015, Emin Gün Sirer, an American computer science professor, introduced the Virtual Notary project as an online witness or attestor to various factoids. The project aimed to provide proof of Bitcoin funds, address ownership, and tweets without disclosing public addresses or fund location on the blockchain. Simultaneously, a subsidiary of Dunvegan Space Systems pursued a similar concept. Interested parties were advised to email JGarzik at DSS.co for more information about the project. Jeff Garzik, a Bitcoin core developer and open-source evangelist, concluded the email with his credentials and included a link to the BitPay, Inc. website.The Virtual Notary project serves as an online witness for factoids, offering proof of Bitcoin funds, address ownership, tweets, real estate value, DNS ownership, existence, web page contents, and weather conditions. Factoids can be recorded on the blockchain or included in a free attestation chain maintained by the website. The site provides a permanent URL for each factoid and allows users to download an X.509 certificate. They actively seek individuals to further develop the service and welcome suggestions for new types of proof or factoids, as well as ideas for building a business case around the core concept. For more information, visit http://virtual-notary.org, and to explore the various factoids and their use cases, refer to the write-up at http://hackingdistributed.com/2013/06/20/virtual-notary-intro/. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_Zero-Conf-for-Full-Node-Discovery.xml b/static/bitcoin-dev/May_2015/combined_Zero-Conf-for-Full-Node-Discovery.xml index aba4d36e66..f2ce46d08e 100644 --- a/static/bitcoin-dev/May_2015/combined_Zero-Conf-for-Full-Node-Discovery.xml +++ b/static/bitcoin-dev/May_2015/combined_Zero-Conf-for-Full-Node-Discovery.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Zero-Conf for Full Node Discovery - 2023-08-01T12:49:14.273723+00:00 + 2025-10-11T22:10:21.001593+00:00 + python-feedgen Louis Rossouw 2015-05-27 10:16:49+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Zero-Conf for Full Node Discovery - 2023-08-01T12:49:14.273723+00:00 + 2025-10-11T22:10:21.001750+00:00 - During a conversation on the Bitcoin-development mailing list, Matt Whitlock shared his experience of operating a Bitcoin-only Wi-Fi network at the Porcupine Freedom Festival ("PorcFest") in New Hampshire. He poisoned the DNS and rejected all outbound connection attempts on port 8333, forcing all the wallets to connect to a single local full node, which had connectivity to a single remote node over the internet. This allowed all the lightweight wallets at the festival to have Bitcoin network connectivity while only needing to backhaul the Bitcoin network's transaction traffic once. The backhaul was a 3G cellular internet connection, and the local Bitcoin node and network router were hosted on a Raspberry Pi with some Netfilter tricks to restrict connectivity.Whitlock also mentioned that in the future, bitcoinj is likely to bootstrap from Cartographer nodes (signed HTTP) rather than DNS, and they're working towards Tor by default. Therefore, the approach used at PorcFest may not work in the future, and there might be a need for a ZeroConf/Rendezvous solution to capture Bitcoin traffic away from Tor.The discussion also touched upon the importance of preventing Sybil attacks. Kevin Greene advised choosing a diverse and unpredictable set of peers to make it difficult for attackers to carry out such attacks. However, he also recommended having a few local nodes to improve propagation while maintaining diversity in the peer set.Furthermore, the conversation explored the possibility of lightweight devices finding a full node on the same LAN to peer with instead of using WAN bandwidth. Jim Phillips suggested using a zero-conf service discovery protocol for this purpose. He envisioned a future where lightweight devices within a home use SPV over WiFi to connect with a home server, which relays transactions to larger and faster relays on the Internet. This approach could result in lower traffic across slow WAN connections, especially when there are numerous small SPV devices monitoring the blockchain in a single home. However, Phillips acknowledged that a significant number of devices would be required before the total bandwidth exceeds downloading a full copy of the blockchain. Nonetheless, hosting one's own full node is seen as more trustworthy.In summary, Matt Whitlock shared his experience of operating a Bitcoin-only Wi-Fi network at PorcFest, Kevin Greene emphasized the importance of diversity in preventing Sybil attacks, and Jim Phillips discussed the potential use of a zero-conf service discovery protocol for lightweight devices to connect with a full node on the same LAN. 2015-05-27T10:16:49+00:00 + During a conversation on the Bitcoin-development mailing list, Matt Whitlock shared his experience of operating a Bitcoin-only Wi-Fi network at the Porcupine Freedom Festival ("PorcFest") in New Hampshire. He poisoned the DNS and rejected all outbound connection attempts on port 8333, forcing all the wallets to connect to a single local full node, which had connectivity to a single remote node over the internet. This allowed all the lightweight wallets at the festival to have Bitcoin network connectivity while only needing to backhaul the Bitcoin network's transaction traffic once. The backhaul was a 3G cellular internet connection, and the local Bitcoin node and network router were hosted on a Raspberry Pi with some Netfilter tricks to restrict connectivity.Whitlock also mentioned that in the future, bitcoinj is likely to bootstrap from Cartographer nodes (signed HTTP) rather than DNS, and they're working towards Tor by default. Therefore, the approach used at PorcFest may not work in the future, and there might be a need for a ZeroConf/Rendezvous solution to capture Bitcoin traffic away from Tor.The discussion also touched upon the importance of preventing Sybil attacks. Kevin Greene advised choosing a diverse and unpredictable set of peers to make it difficult for attackers to carry out such attacks. However, he also recommended having a few local nodes to improve propagation while maintaining diversity in the peer set.Furthermore, the conversation explored the possibility of lightweight devices finding a full node on the same LAN to peer with instead of using WAN bandwidth. Jim Phillips suggested using a zero-conf service discovery protocol for this purpose. He envisioned a future where lightweight devices within a home use SPV over WiFi to connect with a home server, which relays transactions to larger and faster relays on the Internet. This approach could result in lower traffic across slow WAN connections, especially when there are numerous small SPV devices monitoring the blockchain in a single home. However, Phillips acknowledged that a significant number of devices would be required before the total bandwidth exceeds downloading a full copy of the blockchain. Nonetheless, hosting one's own full node is seen as more trustworthy.In summary, Matt Whitlock shared his experience of operating a Bitcoin-only Wi-Fi network at PorcFest, Kevin Greene emphasized the importance of diversity in preventing Sybil attacks, and Jim Phillips discussed the potential use of a zero-conf service discovery protocol for lightweight devices to connect with a full node on the same LAN. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2015/combined_soft-fork-block-size-increase-extension-blocks-Re-Proposed-alternatives-to-the-20MB-stepfunction.xml b/static/bitcoin-dev/May_2015/combined_soft-fork-block-size-increase-extension-blocks-Re-Proposed-alternatives-to-the-20MB-stepfunction.xml index 4fce9b2996..ff32e7fba3 100644 --- a/static/bitcoin-dev/May_2015/combined_soft-fork-block-size-increase-extension-blocks-Re-Proposed-alternatives-to-the-20MB-stepfunction.xml +++ b/static/bitcoin-dev/May_2015/combined_soft-fork-block-size-increase-extension-blocks-Re-Proposed-alternatives-to-the-20MB-stepfunction.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction - 2023-08-01T12:54:24.469683+00:00 + 2025-10-11T22:09:12.901225+00:00 + python-feedgen Andrew 2015-05-30 03:27:36+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction - 2023-08-01T12:54:24.469683+00:00 + 2025-10-11T22:09:12.901434+00:00 - In an email conversation between Bitcoin developers Adam Back and Raystonn, Raystonn expresses gratitude to Adam for inventing hashcash, the basis for Bitcoin. He then proposes a different approach to scaling Bitcoin using subchains, explaining the need for a tree structure of blockchains to handle transactions efficiently. Raystonn advocates for multiple 1MB chains over a single 10MB chain, highlighting the advantages of this approach. He believes that the specifics of how the blockchains interact can be figured out in the future.Raystonn also discusses the importance of having an "exit plan" in case a better idea emerges. He suggests a way to reverse the soft fork, ensuring flexibility for future developments. In response, Gavin Andresen recommends implementing the proposed solution in the Bitcoin Core wallet. He suggests coding it and reaching out to various wallet developers to determine the time required to update their software accordingly. Gavin also emphasizes the need for user interface mockups to enhance the user experience.However, Gavin raises concerns about the complexity of the proposed solution. He suggests considering simpler alternatives if they can achieve the same effectiveness. Additionally, Gavin questions the potential risks associated with 20MB extension blocks and whether they pose similar issues as 20MB main blocks.The concept of an "extension block" is discussed as a means to soft-fork an opt-in block-size increase. It offers improved security compared to what Raystonn initially suggested. The extension block operates alongside the existing 1MB block, with users able to transfer bitcoin into and out of the extension block. This approach allows for opt-in block size changes and gives users more choice. However, different validation levels and mining options are available for both 1MB and 10MB transactions.There is a risk associated with non-upgraded users who run 1MB full nodes or those who upgrade but lack sufficient bandwidth to validate 10MB blocks. To address this, receiving funds via the extension block could also be made opt-in. Measures such as UTXO commitments, fraud proofs, and optional coin maturation can enhance the security of 1MB blocks in relation to weaker extension block transactions.Although implementing this approach is more complex than a hard fork, it offers a safer transition and allows users to opt for either higher decentralization with 1MB blocks or larger block sizes with opt-in choices like 10MB or even 100MB for low-value transactions. By making bigger block sizes an opt-in choice, the block size debate can be approached more easily. 2015-05-30T03:27:36+00:00 + In an email conversation between Bitcoin developers Adam Back and Raystonn, Raystonn expresses gratitude to Adam for inventing hashcash, the basis for Bitcoin. He then proposes a different approach to scaling Bitcoin using subchains, explaining the need for a tree structure of blockchains to handle transactions efficiently. Raystonn advocates for multiple 1MB chains over a single 10MB chain, highlighting the advantages of this approach. He believes that the specifics of how the blockchains interact can be figured out in the future.Raystonn also discusses the importance of having an "exit plan" in case a better idea emerges. He suggests a way to reverse the soft fork, ensuring flexibility for future developments. In response, Gavin Andresen recommends implementing the proposed solution in the Bitcoin Core wallet. He suggests coding it and reaching out to various wallet developers to determine the time required to update their software accordingly. Gavin also emphasizes the need for user interface mockups to enhance the user experience.However, Gavin raises concerns about the complexity of the proposed solution. He suggests considering simpler alternatives if they can achieve the same effectiveness. Additionally, Gavin questions the potential risks associated with 20MB extension blocks and whether they pose similar issues as 20MB main blocks.The concept of an "extension block" is discussed as a means to soft-fork an opt-in block-size increase. It offers improved security compared to what Raystonn initially suggested. The extension block operates alongside the existing 1MB block, with users able to transfer bitcoin into and out of the extension block. This approach allows for opt-in block size changes and gives users more choice. However, different validation levels and mining options are available for both 1MB and 10MB transactions.There is a risk associated with non-upgraded users who run 1MB full nodes or those who upgrade but lack sufficient bandwidth to validate 10MB blocks. To address this, receiving funds via the extension block could also be made opt-in. Measures such as UTXO commitments, fraud proofs, and optional coin maturation can enhance the security of 1MB blocks in relation to weaker extension block transactions.Although implementing this approach is more complex than a hard fork, it offers a safer transition and allows users to opt for either higher decentralization with 1MB blocks or larger block sizes with opt-in choices like 10MB or even 100MB for low-value transactions. By making bigger block sizes an opt-in choice, the block size debate can be approached more easily. - + \ No newline at end of file diff --git a/static/bitcoin-dev/May_2016/combined_BIP-Number-Request-Open-Asset.xml b/static/bitcoin-dev/May_2016/combined_BIP-Number-Request-Open-Asset.xml index a48c497b3a..07f14aeecc 100644 --- a/static/bitcoin-dev/May_2016/combined_BIP-Number-Request-Open-Asset.xml +++ b/static/bitcoin-dev/May_2016/combined_BIP-Number-Request-Open-Asset.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Number Request: Open Asset - 2025-09-26T15:35:11.253720+00:00 + 2025-10-11T21:44:16.230873+00:00 python-feedgen Nicolas Dorier 2016-08-13 02:25:04+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - BIP Number Request: Open Asset - 2025-09-26T15:35:11.253885+00:00 + 2025-10-11T21:44:16.231074+00:00 2016-08-13T02:25:04+00:00 The discussion revolves around the Open Assets (OA) protocol, which has become stable and is being used by many companies in the industry. The goal is to make OA 1.0 the Bitcoin Improvement Proposal (BIP) since it is the one people are using. The idea of creating a new "multiple-colored-coin-protocol" that merges the features of different implementations has failed in the past due to different assumptions and tradeoffs taken by each protocol for different use cases. Therefore, there is no point in creating yet another "standard" that nobody uses. However, it would be useful to have other colored coin protocols such as EPOBC and Colu. ChromaWay is willing to replace EPOBC with something better and can support multiple different kernels, so adding a new protocol is not a big deal for them. One idea is to decouple input-output mapping/multiplexing from coloring, enabling advanced protocols with smart contracts that are compatible with old ones to a certain extent. Core developers may not be interested in colored coins, but Blockstream is developing a sidechain with user-defined assets that could be a preferred way of doing things. Investors do not need to install multiple wallets to deal with varying implementations since a wallet supporting multiple protocols can be implemented. Nicolas is proposing the BIP on behalf of Flavien, who will ACK as needed, but Nicolas will drive the discussions.In 2014-2015, an attempt was made to create an RFC-style standard "multiple-colored-coin-protocol" with representatives from all major protocols. However, the effort failed due to lack of interest in collaboration and each company only caring about its own product. Colu asked for requirements but developed a new protocol entirely on their own without taking anyone's input. Merging the protocols may not make sense as some value simplicity, and a combined protocol cannot have this feature. There is little interest in a merged colored coin protocol now, and Colu is moving away from it. ChromaWay would not mind replacing EPOBC with something better, and they are open to adding a new protocol. One idea they have is to decouple input-output mapping/multiplexing from coloring, allowing for more advanced protocols with smart contracts while keeping them compatible with old ones. Core developers generally dislike things like colored coins, so getting their help is unlikely. Blockstream is developing a sidechain with user-defined assets, which they see as the preferred way of doing things. Investors currently have to install multiple wallets to deal with varying implementations, but this can be solved by implementing a wallet that supports multiple protocols.The Open Asset protocol has been used in the wild since 2014 and cannot be easily modified. However, a new OA2.0 protocol can be created to address existing issues while ensuring that upgraded wallets continue to support both versions. The focus of OA has always been on integration rather than fixing the core protocol, which has resulted in various implementations being used by investors who need to install multiple wallets. To address this, it would be beneficial for major protocols to collaborate and develop a meta-specification that merges the features of existing implementations while avoiding potential issues. This could lead to a more streamlined process for investors and benefit the community as a whole.The Open Asset protocol is an already implemented protocol used in production with multiple implementations. It is not possible to do provably limited issuance and the scriptPubKey can be anything, not necessarily P2PK. The issuer of the asset is determined by whoever can spend the scriptPubkey. If a colored output is spent incorrectly, it is effectively destroyed. It is not possible to issue more than one asset type in a transaction as the asset issued is defined by the scriptPubKey of the first input. For multiple transfers, it is possible to have several outputs. The marker output is skipped in the list. To prevent users from sending assets to a wallet that does not support Open Asset via another address scheme, the protocol requires address reuse for issuing. However, this is not supported behavior and insecure. Older clients may accidentally destroy assets but are prevented from doing so by Open Asset protocol. It is not easily modifiable by now for improving it. There were questions about the clarity and thought-out nature of the Open Asset protocol documentation, but there are also no objections to calling it BIP 160. It was originally proposed by Flavien Charlon and there has been no response from Nicolas Dorier, who is known personally by the original author regarding whether or not James MacWhyte can put his name in the BIP.After reading through the documentation, the writer doesn't believe that OpenAssets, the most popular colored coin protocol in use, has been thought out well enough to build something on top of. However, they acknowledge that it is not a work-in-progress but rather an already established protocol that cannot be changed without breaking stuff. The writer hopes that the lack of response or discussion on the project does not mean that it diff --git a/static/bitcoin-dev/May_2016/combined_BIP-OP-PRANDOM.xml b/static/bitcoin-dev/May_2016/combined_BIP-OP-PRANDOM.xml index 93c316e430..15d47b2ebb 100644 --- a/static/bitcoin-dev/May_2016/combined_BIP-OP-PRANDOM.xml +++ b/static/bitcoin-dev/May_2016/combined_BIP-OP-PRANDOM.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP: OP_PRANDOM - 2025-09-26T15:35:17.597693+00:00 + 2025-10-11T21:44:22.599419+00:00 python-feedgen Sergio Demian Lerner 2016-05-24 14:36:35+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - BIP: OP_PRANDOM - 2025-09-26T15:35:17.597856+00:00 + 2025-10-11T21:44:22.599587+00:00 2016-05-24T14:36:35+00:00 The email conversation posted discusses the issue of using random numbers in Bitcoin. A proposed solution is the use of the Bitcoin Beacon paper, which suggests deciding a random bit on the majority 1s or 0s of least significant bits taken from last block hashes. The protocol πbeacon is also examined, which outputs unpredictable and publicly verifiable randomness. The paper shows that πbeacon can be instantiated via Bitcoin under sensible assumptions, but provides an impossibility result that stems from the similarity between the Bitcoin model and Santha-Vazirani sources for cases in which the adversary has an infinite budget. The email also discusses the potential security risks of using multiple block hashes as a source of randomness, which can be mitigated by every miner needing to be bribed to control the results of the random numbers. Additionally, Eric Martindale mentions OP_DETERMINISTICRANDOM from the Elements Project as a possible solution. Finally, Jeremy Rubin suggests adding OP_XOR back and then using something like Blum's fair coin-flipping over the phone for these use cases.A protocol named πbeacon is examined in a paper by Iddo Bentov, Ariel Gabizon, and David Zuckerman that outputs unpredictable and publicly verifiable randomness. Bitcoin can be used to instantiate πbeacon under sensible assumptions. However, an impossibility result exists in case the adversary has an infinite budget as it stems from the similarity between the Bitcoin model and Santha-Vazirani sources. A hybrid protocol that combines trusted parties and a Bitcoin-based beacon is also provided. In a discussion on bitcoin-dev mailing list, Eric Martindale suggests taking a look at OP_DETERMINISTICRANDOM from the Elements Project as it aims to achieve a similar goal. Matthew Roberts explores the idea of using multiple block hashes as a source of randomness, but Johnson Lau points out that this does not make it any safer since the miner of the last block always determines the results. To protect the details of contracts using OP_PRANDOM from miners, pay-to-script-hash can be used, but there is still a non-zero risk of participants attempting to bribe a miner.The discussion on the bitcoin-dev mailing list revolves around the security of using OP_PRANDOM to generate random numbers. It is argued that OP_PRANDOM is not secure and adds extra validation overhead on a block composed of transactions spending an OP_PRANDOM output from different blocks. The suggestion is made to add OP_XOR back and use Blum's fair coin-flipping over the phone. However, there are limitations and issues with this approach. Another option suggested is to use OP_DETERMINISTICRANDOM from the Elements Project. There is also a discussion on the security aspect of using multiple block hashes as a source of randomness and how Pay-to-script-hash can be used to protect the details of contracts using OP_PRANDOM. The risk of a participant attempting to bribe a miner to control the results of the random numbers is considered low as the number of required bribes goes up.A suggestion was made to Matthew Roberts to take a look at OP_DETERMINISTICRANDOM from the Elements Project, as it aims to achieve a similar goal. The code for this can be found in the alpha branch. In response to this, Johnson Lau stated that using the hash of multiple blocks does not make it any safer and that the miner of the last block always determines the results. However, to protect the details of contracts that use OP_PRANDOM from the prying eyes of miners, Pay-to-script-hash can be used, and the inclusion of multiple block hashes as a source of randomness is a must. The risk approaches zero as N goes up. Matthew Roberts mentioned a possible solution where the hash of the proof of work hash could be used as part of the number, but he needs to sleep on it for now.The context is a discussion of the security of using multiple block hashes as a source of randomness. It is suggested that combining block hashes by taking the first N bits from each block hash to produce a single number may be a better approach than the current direction. Another suggestion is to use the hash of the proof of work hash as part of the number, making it infinitely expensive to manipulate the number. However, there is a non-zero risk of a participant in a contract attempting to bribe a miner, so the inclusion of multiple block hashes as a source of randomness is necessary. Every miner would effectively need to be bribed to ensure control over the results of the random numbers. Using Pay-to-script-hash can protect the details of contracts that use OP_PRANDOM from miners' prying eyes. The risk approaches zero as N goes up.In a discussion on the bitcoin-dev mailing list, Johnson Lau questioned the usefulness of using the hash of multiple blocks to secure transactions. He argued that since the miner of the last block ultimately determines the results, knowing the hashes of previous blocks doesn't make it any safer. However, pay-to-script-hash can be utilized diff --git a/static/bitcoin-dev/May_2016/combined_Bip44-extension-for-P2SH-P2WSH-.xml b/static/bitcoin-dev/May_2016/combined_Bip44-extension-for-P2SH-P2WSH-.xml index 24b4aeed6b..e6dabe41d7 100644 --- a/static/bitcoin-dev/May_2016/combined_Bip44-extension-for-P2SH-P2WSH-.xml +++ b/static/bitcoin-dev/May_2016/combined_Bip44-extension-for-P2SH-P2WSH-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Bip44 extension for P2SH/P2WSH/... - 2025-09-26T15:35:09.140667+00:00 + 2025-10-11T21:44:14.096914+00:00 python-feedgen Aaron Voisine 2016-05-15 17:36:54+00:00 @@ -85,10 +85,11 @@ + 2 Combined summary - Bip44 extension for P2SH/P2WSH/... - 2025-09-26T15:35:09.140840+00:00 + 2025-10-11T21:44:14.097073+00:00 2016-05-15T17:36:54+00:00 In an email conversation, Daniel Weigl and Aaron Voisine discussed the idea of using 0x40000000 as the next available number to specify witness addresses. Weigl expressed concern that every BIP-compatible wallet in the future would have to implement all legacy derivation and transaction schemes. Voisine agreed that old derivations would still need to be supported for many decades, but suggested using a new BIP43 purpose number for segwit only wallets. He also proposed specifying 0x40000000/1 for the change/receive index to maintain compatibility with other schemes for upgrading existing wallets.Another discussion focused on implementing a new derivation path parallel to Bip44 but with a different purpose, allowing users to choose between normal and witness accounts. However, this approach would require all Bip-compatible wallets in the future to implement all legacy derivation and transaction schemes and could result in non-deterministic failures when importing seeds or xPriv/xPub across different capable wallets. The solution proposed was to use 0x40000000 as the bit field flag to specify witness addresses, compatible with existing accounts and wallet layouts. However, recovering on non-segwit software would miss segwit receives.Jonas Schnelli raised the issue of the lack of BIP39 import support in wallets such as Schildbachs android wallet, Electrum, and Breadwallet. It was confirmed that these wallets are not BIP44 compatible, and there were concerns about the security risks involved in importing a bip39 mnemonic into a hardware wallet. Despite the potential risks, it was recommended to send all coins to the new seed.Electrum's developer explained that they do not support Bip39 import due to the lack of a version number in BIP39 seed phrases, which is needed for maintaining backward compatibility. As Electrum allocated a new version number for seed phrases derived to segwit addresses, BIP39 designers would need to change the semantics of their checksum bits to encode a version number for segwit.There were discussions about the challenges of moving funds to a new wallet, potential loss of funds if the old wallet has used more than 1000 addresses, and the need for wallets to implement BIP32 HD. Importing a wallet, especially cross-wallet imports, was considered a tricky step that may require expertise and further improvements.BIP43 and BIP44 were discussed, with BIP43 defining how balance retrieval works and BIP44 based on this idea. The goal was to ensure that the same balance is always seen on wallets that use the same BIP and seed.Opinions differed on whether importing a BIP32 wallet is still an expert job. Some argued that it is not, as reasonable wallets now use BIP39 mnemonic for this purpose. However, concerns were raised about cross-wallet imports using BIP39 and the potential problems associated with it.The email thread also touched on the topic of recovering funds from a wallet conforming to BIPXX, which requires wallet software to handle BIPXX. Importing a bip32 wallet was still considered an expert job, and there were discussions on how to improve the process.A proposed scheme involved using the chain index instead of the account index to indicate the type of address, but it created confusion regarding wallet compatibility with segwit. It was suggested to have another BIP specifically for segwit to clarify compatibility.In a discussion about the default BIP32 wallet layout, Aaron Voisine suggested using a bit field flag to specify the type of address. He proposed using 0x40000000 as the flag since 0x80000000 is already used for hardened derivation. However, Pavol Rusnak questioned the advantages of this optimization and noted that the discussion was off-topic as they were discussing multiple-accounts per wallet layout, not one-account-per-wallet design.The idea of specifying the type of address as a bit field flag is liked because it avoids checking multiple address types for each key. The suggestion was to use 0x40000000 as the flag, which would be compatible with existing accounts and wallet layouts. However, recovering on non-segwit software would miss segwit receives. Another option proposed was to define a new derivation path parallel to Bip44, allowing users to choose between a "Normal account" and a "Witness account". Pavol Rusnak from SatoshiLabs.com suggested that option #2 is better and they plan to implement it in myTREZOR. There are plans for BIP44 compliant wallets, but no visible results yet.Daniel Weigl suggested two options for improving the wallet experience. The second option involves defining a new derivation path parallel to Bip44 but with a different purpose, allowing users to choose between a "normal" or "witness" account. The team agreed that option #2 would be better and plans to implement it in myTREZOR. It was mentioned that there is a project in the pipeline for BIP diff --git a/static/bitcoin-dev/May_2016/combined_Compact-Block-Relay-BIP.xml b/static/bitcoin-dev/May_2016/combined_Compact-Block-Relay-BIP.xml index 8af86f5ba8..79b8669ad8 100644 --- a/static/bitcoin-dev/May_2016/combined_Compact-Block-Relay-BIP.xml +++ b/static/bitcoin-dev/May_2016/combined_Compact-Block-Relay-BIP.xml @@ -2,7 +2,7 @@ 2 Combined summary - Compact Block Relay BIP - 2025-09-26T15:35:04.912477+00:00 + 2025-10-11T21:44:09.849530+00:00 python-feedgen Matt Corallo 2016-05-18 01:49:10+00:00 @@ -93,10 +93,11 @@ + 2 Combined summary - Compact Block Relay BIP - 2025-09-26T15:35:04.912701+00:00 + 2025-10-11T21:44:09.849724+00:00 2016-05-18T01:49:10+00:00 In a Bitcoin developers mailing list conversation, Rusty Russell proposed using variable-length bit encodings to reduce the size of transmitted data. Gregory Maxwell questioned the reliability and failure rate of this approach. Russell suggested using variable-length IDs and avoiding nonces to save time. However, Maxwell disagreed, stating that it would increase the cost of collisions. The conversation also touched on the idea of using UDP instead of TCP, but Russell was not convinced. Finally, Russell mentioned adding extra bits in the sender's coding to prevent collisions.Bitcoin developers are working on a new compact block relay system that will send transactions in smaller packets. This system aims to reduce bandwidth requirements and improve transmission speed between nodes. Instead of sending all transaction details, miners would only send a unique identifier for each transaction along with a list of excluded transactions. The receiving node would then request the full transaction information if needed.Pieter explained the length of short IDs required and suggested allowing the sender to choose. He also discussed techniques for reducing the number of bytes used for txids. Matt Corallo designed a BIP for compact block relay, introducing new data structures and a variable-length integer encoding. Short transaction IDs were introduced to represent a transaction without sending a full hash. Several heuristics can be used to improve performance, such as treating short txids that match multiple mempool transactions as non-matches and verifying against the sender's mempool to check for collisions.In another email thread, Peter R raised concerns about collision attacks, and Gregory Maxwell explained the likelihood of finding two transactions with the same initial 8 bytes of txid. Peter calculated the number of possible pairs in a set of transactions and questioned how to find the pair. Later, Peter suggested a faster way to scan the set using binary search. He agreed that the attack was feasible.The conversation also involved discussions about moderation and off-topic posts, with recommendations for sending further posts to appropriate mailing lists.Overall, the Bitcoin developers are exploring various techniques to improve the network's speed and efficiency, including reducing the size of transmitted data, using variable-length encodings, and optimizing transaction identification and relay.In a discussion on the bitcoin-dev mailing list, Tom and Gregory debated over the use of service bits for indicating additional peer-to-peer feature support. Gregory argued against using service bits for negating optional parameters, while Tom believed they were the right solution. They also discussed variable length encoding and collision attacks. Matt Corallo proposed a solution called Compact Block Relay BIP to address block propagation issues, but Tom criticized it as too complicated. The discussion also touched on the use of short transaction IDs and the acknowledgment of contributors to the document.The conversation shifted to the relay protocol and its optimization for propagation time rather than bandwidth. Two other proposals, xthin block and ILBT, were mentioned as potential solutions to decrease bandwidth usage, but further information was requested. Matt Corallo introduced his Compact Block Relay BIP, which aims to reduce data transmission. He explained the protocol flow, the calculation of short transaction IDs, and backward compatibility with older clients. The implementation of the BIP can be found on Github.A user reported testing the compact block relay design for a couple of weeks and observed a significant reduction in block-bytes sent and bandwidth spikes. The measurements showed that a high percentage of blocks were transferred with low latency, even without prediction.Matt Corallo's BIP-formatted design spec for compact block relay aimed to limit on-wire bytes during block relay. The latest version of the document can be found on Github. A user who tested the design reported over 96% reduction in block-bytes sent and decreased bandwidth spikes. The user's measurements showed that a significant percentage of blocks were transferred with low latency, even without prediction.The Compact Block Relay BIP designed by Matt Corallo aims to reduce block relay time and conserve bandwidth for nodes on the P2P network. The protocol includes two modes: high-bandwidth and low-bandwidth. Several new messages and inv types are introduced, along with the use of short transaction IDs. The protocol also includes new data structures and a variable-length integer encoding. Nodes are required to follow specific rules when requesting and sending compact blocks.The document discusses the protocol for handling missing transactions in the Bitcoin network. It emphasizes the importance of validating that the header properly commits to each transaction in the block before sending a cmpctblock message. When a requested blocktxn message is received, nodes are advised to reconstruct the full block. To improve block relay time, nodes are recommended to send a sendcmpct message with the first integer set to 1 to up to three peers based on their past performance in providing blocks quickly. Additionally, all nodes should send a sendcmpct message to all appropriate peers. Nodes with limited inbound bandwidth should prioritize using MSG_CMPCT_BLOCK/getblocktxn requests when requesting blocks. When sending cmpctblock messages, nodes should limit prefilledtxn to approximately 10KB of transactions. To optimize efficiency, nodes may choose one diff --git a/static/bitcoin-dev/May_2016/combined_Making-AsicBoost-irrelevant.xml b/static/bitcoin-dev/May_2016/combined_Making-AsicBoost-irrelevant.xml index 52d5f0fca3..6e9be67851 100644 --- a/static/bitcoin-dev/May_2016/combined_Making-AsicBoost-irrelevant.xml +++ b/static/bitcoin-dev/May_2016/combined_Making-AsicBoost-irrelevant.xml @@ -2,7 +2,7 @@ 2 Combined summary - Making AsicBoost irrelevant - 2025-09-26T15:35:19.710586+00:00 + 2025-10-11T21:44:24.727618+00:00 python-feedgen Jorge Timón 2016-05-12 11:05:51+00:00 @@ -161,10 +161,11 @@ + 2 Combined summary - Making AsicBoost irrelevant - 2025-09-26T15:35:19.710803+00:00 + 2025-10-11T21:44:24.727851+00:00 2016-05-12T11:05:51+00:00 In May 2016, the bitcoin-dev mailing list saw discussions on various topics related to the Bitcoin protocol and its potential optimizations. One topic debated was the possibility of forking the Bitcoin blockchain to create altcoins. Timo Hanke argued that forking would result in an altcoin, while another participant disagreed, stating that survival depends on demand. The discussion was suggested to be moved to the bitcoin-discuss forum for further exploration.Another discussion revolved around ASIC optimizations and whether they should be kept secret. Sergio Demian Lerner proposed that changing the protocol would imply the need for secrecy, but Tom Harding countered by pointing out that other optimizations are already kept secret. There was also debate about patent encumbrance in ASIC design and manufacturing, with Gregory Maxwell proposing a modification to the Proof-of-Work algorithm to neutralize the advantage of implementing AsicBoost. Peter Todd emphasized the importance of allowing the market to determine winners and losers.Timo Hanke accused Bitcoin Core developers of undermining his work through a blockchain fork, but Peter Todd noted that it is impossible to determine if Hanke's AsicBoost technology was used. Todd suggested miners negotiate lower licensing fees for the patent. The conversation also touched on the redesign of the Bitcoin block header and concerns over banning AsicBoost miners. Timo Hanke proposed a new mining header to address some issues related to the redesign.Overall, these discussions showcased different perspectives on the impact of optimizations, patents, and forks in the Bitcoin ecosystem. Centralization, fairness, and balancing innovation with network stability were key considerations. The developers and community members engaged in thoughtful exchanges, exploring various solutions and potential outcomes.The ongoing discussion in the Bitcoin community focused on the patented AsicBoost optimization and its potential implications. A major concern was the inability to determine if a block was mined with AsicBoost, making it challenging to assess its usage. This issue could lead to a chain fork if AsicBoost miners are banned, resulting in two co-existing Bitcoin blockchains. Sergio Demian Lerner proposed a redesign of the Bitcoin block header to increase nonce space and address this issue.The discussion also mentioned XORing bytes 64-76 with the first 12 bytes of the SHA2 midstate, but it was noted that this would only marginally increase the difficulty of finding a collision. It was recommended to restrict the use of 10 bytes to prevent timestamp rolling on-chip by hardware. There were differing opinions on the impact of banning AsicBoost, with concerns about hindering competition and decentralization, as well as centralizing the technology with one manufacturer.Opinions varied on the likelihood of a hard fork resulting from banning AsicBoost, with some believing it could lead to a chain fork, while others argued that AsicBoost blocks would be ignored until they stop being produced. The possibility of a difficulty adjustment on the AsicBoost chain was also mentioned, which could result in both chains growing at similar speeds. Changing the protocol to render AsicBoost useless was thoroughly discussed, with considerations for fairness and exploring alternative optimizations.Transparency and careful consideration of changes to the Bitcoin protocol were recognized as crucial for the health and stability of the network, as well as promoting fair competition and decentralization.In a post to the bitcoin-dev mailing list, Matt Corallo suggested several changes to render AsicBoost useless during a hard fork. These changes included fixing the version field, altering the merkle root, and swapping bytes within the merkle root and timestamp fields. Tier Nolan also proposed enhancing security by splitting the merkle root into two pieces. Peter Todd raised concerns about implementation without affecting existing mining hardware or SPV compatibility. The email referred to the HK agreement and provided links to additional discussions.The HK agreement aimed to make AsicBoost and similar optimizations ineffective through a hard fork. The goal was to find the best approach compatible with SPV and existing mining hardware. Changes from SPV clients were acceptable if necessary, but compatibility was essential. The Bitcoin Roundtable Consensus and discussions on the bitcoin-dev mailing list were valuable sources for further information, and Peter Todd was suggested as a contact for more details. diff --git a/static/bitcoin-dev/May_2016/combined_Making-UTXO-Set-Growth-Irrelevant-With-Low-Latency-Delayed-TXO-Commitments.xml b/static/bitcoin-dev/May_2016/combined_Making-UTXO-Set-Growth-Irrelevant-With-Low-Latency-Delayed-TXO-Commitments.xml index 03edbd42ea..915f6cbb54 100644 --- a/static/bitcoin-dev/May_2016/combined_Making-UTXO-Set-Growth-Irrelevant-With-Low-Latency-Delayed-TXO-Commitments.xml +++ b/static/bitcoin-dev/May_2016/combined_Making-UTXO-Set-Growth-Irrelevant-With-Low-Latency-Delayed-TXO-Commitments.xml @@ -2,7 +2,7 @@ 2 Combined summary - Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments - 2025-09-26T15:35:07.026844+00:00 + 2025-10-11T21:44:11.973901+00:00 python-feedgen Peter Todd 2016-05-22 08:55:33+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments - 2025-09-26T15:35:07.027020+00:00 + 2025-10-11T21:44:11.974073+00:00 2016-05-22T08:55:33+00:00 In a comparison of two proposals related to Bitcoin mining, Johnson Lau's proposal from 2015 suggests using the pruned UTXO set and 32 bytes per archived block for mining. However, there may be difficulty in spending archived outputs without knowing the status of other archived outputs from the same block. Lau proposes that third-party archival nodes can perform full re-scans of the blockchain to generate proof.Peter Todd claims to have a better proposal, where the dormant UTXO list is indexed by UTXO expiration order, making it impossible to verify the contents of that commitment without the global state of all UTXO data.The article discusses the issue of UTXO growth in Bitcoin and how it poses a threat to long-term decentralization. The current lack of consensus rules limiting UTXO growth can be attributed to factors such as lost coins, dust outputs, and non-Bitcoin-value-transfer use-cases. While Segregated Witness aims to reduce the UTXO set size, it may not discourage all UTXO growing behavior.To address this, TXO commitments propose a Merkle Mountain Range (MMR) that commits to the state of all transaction outputs, allowing less frequently accessed parts of the UTXO set to be archived while still providing a mechanism to spend those archived outputs. This improves storage efficiency and scalability, reducing the need for SPV wallet software to trust third parties.In a discussion about TXO commitments, Peter Todd explains how the proposed Merkle Mountain Range (MMR) allows new items to be appended to the tree with minimal storage requirements. Once an output is added to the TXO MMR, it is never removed, even if it is spent. Todd also discusses the implementation of a high-performance/low-latency delayed commitment full-node that stores the UTXO set, STXO set, TXO journal, and TXO MMR list. The TXO MMR implementation can store a large number of states with minimal data requirements, allowing for efficient pruning and unpruning of data.In another discussion, Todd argues against having both an append-only TXO and an append-only STXO, as indexing the STXO would be difficult due to the random position of new STXOs. However, if the STXO was indexed by txout creation order, it would be similar to Todd's proposed insertion-ordered TXO commitment. The article also mentions the availability of the MMR implementation with pruning support on Github and how the proofchains MMR scheme fixes the problem of proving the position in the tree.The article further discusses the proposed TXO commitments using Merkle Mountain Range (MMR), which allows for compactly proving the current state of an output. It explores the implementation details and benefits of using MMRs, such as reduced storage requirements and improved retrieval efficiency. However, there are still questions that need to be addressed, including how TXO commitments will interact with fraud proofs and whether incentivization schemes for miners can discount or ignore TXO commitment proof sizes. Optimization possibilities and the decision of UTXO archiving based on size or threshold are also mentioned.Overall, TXO commitments represent an improvement in Bitcoin's scalability and storage efficiency. The proposal addresses the issue of UTXO growth and provides mechanisms for efficient storage and retrieval of transaction outputs. However, further work and consideration are needed to fully implement and optimize TXO commitments, as well as address potential security concerns and interaction with fraud proofs.The article delves into the implementation of Transaction Output (TXO) commitments in Bitcoin's security model. It addresses the issue of TXO growth, which poses a challenge to the decentralization of Bitcoin. Currently, there are no rules limiting the size of the Unspent Transaction Output (UTXO) set, leading to significant memory expansion. The proposed solution is the Merkle Mountain Range (MMR), also known as TXO commitments, which offers a deterministic and indexable merkle tree structure. This allows for efficient appending of new items with minimal storage requirements.Implementing UTXO commitments without delaying commitment can adversely affect small miners' orphan rates, causing slower block validation. By introducing a delay, the latency-critical task becomes an average throughput problem. The TXO journal records spent outputs in the TXO MMR, and the MMR data is hashed to obtain the TXO commitment digest. While the TXO commitment calculation may have lower throughput compared to the UTXO only scheme, it offers tradeoffs that can mitigate the impact on validation throughput.The article highlights the challenges involved in implementing TXO commitments, such as determining the minimum age considered "assumed valid" and balancing political, social, and technical concerns. It suggests further work on optimizing the TXO commitment scheme to simplify complexity, prioritizing bitcoin value-transfer, and exploring alternative metrics/incentives for miner fairness and decentralization.The proposed high-performance/low-latency delayed commitment full-node implementation requires storing diff --git a/static/bitcoin-dev/May_2016/combined_Proposal-to-update-BIP-32.xml b/static/bitcoin-dev/May_2016/combined_Proposal-to-update-BIP-32.xml index b72b26bec9..4cc17d1cf0 100644 --- a/static/bitcoin-dev/May_2016/combined_Proposal-to-update-BIP-32.xml +++ b/static/bitcoin-dev/May_2016/combined_Proposal-to-update-BIP-32.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposal to update BIP-32 - 2025-09-26T15:35:13.366784+00:00 + 2025-10-11T21:44:18.353862+00:00 python-feedgen Gregory Maxwell 2016-05-08 11:09:45+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Proposal to update BIP-32 - 2025-09-26T15:35:13.366944+00:00 + 2025-10-11T21:44:18.354012+00:00 2016-05-08T11:09:45+00:00 On May 8, 2016, Pavol Rusnak reached out to the bitcoin-dev mailing list seeking Sipa's opinion on a proposed fix. Marek Palatinus also requested Sipa's input and expressed support for the proposal. However, since Sipa had not been active on the mailing list, he did not receive the message.In an email exchange between Eric Lombrozo and Jochen Hoenicke, they discussed the probability of a specific case of BIP32 triggering. They concluded that the likelihood of it happening is incredibly small at 2^-128. While many have been using BIP32 for years, some app developers feel that dealing with this level of complexity is not worth the effort. However, if handling the case is easy to implement and isolate in program flow, Lombrozo would be in favor of implementing a solution. The idea is to handle the problem in the library so app developers don't have to worry about missing addresses or ignore the issue. This could be achieved by having the library retry instead of returning an error.On April 21, 2016, Eric Lombrozo raised a concern on bitcoin-dev regarding the handling of cases where the BIP-32 derivation path is invalid. This issue is further complicated by limited software performing these checks. Additionally, even if a check is performed, handling the exception can be challenging as skipping may not always be an option. The motivation behind addressing this issue is to enable BIP-32 usage for non-secp256k1 curves such as the NIST P-256 curve with a chance of 2^-32. An example of an invalid BIP-32 path was found by Jochen at m/28578'/33941 derived from a hexadecimal seed.Jochen Hoenicke proposed an update to BIP-32, suggesting that if the computed hash is larger or equal to the prime or 0, the node should be considered invalid and skipped in the BIP-32 tree. He recommended modifying the procedure by repeating the hashing with slightly different input data until a valid private key is found. This way, the library will always return a valid node for all paths. Jochen believes that the chance of this affecting anyone is less than 10^-30 and that backward compatibility issues are minimal. However, many app developers feel that dealing with this complexity may not be worth the effort. Nevertheless, if the handling of this case is simple to implement and isolate in the program flow, Jochen is in favor of making changes.The proposal suggests updating BIP-32 to make it easier for developers to use. Currently, the specification requires all callers of CKDpriv or CKDpub to check for errors when the computed hash is larger or equal to the prime or zero, and handle these errors appropriately. This places an additional burden on application developers instead of being able to handle it within the BIP-32 library. Furthermore, it is unclear how to proceed if an intermediate node is missing. The suggestion is to repeat the hashing with slightly different input data until a valid private key is found. This approach ensures that the library always returns a valid node for all paths, avoiding issues encountered with the original version. The proposal also includes suggestions for updating the derivation functions and root node derivation from the seed. While there may be minimal backward compatibility issues, the author believes that the benefits of the update outweigh any potential consequences. The post concludes with questions regarding how to update the BIP and which algorithm is preferred for implementation. diff --git a/static/bitcoin-dev/May_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml b/static/bitcoin-dev/May_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml index 032175f96e..16862652c0 100644 --- a/static/bitcoin-dev/May_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml +++ b/static/bitcoin-dev/May_2016/combined_RFC-for-BIP-Best-Practices-for-Heterogeneous-Input-Script-Transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - RFC for BIP: Best Practices for Heterogeneous Input Script Transactions - 2025-09-26T15:35:15.483644+00:00 + 2025-10-11T21:44:20.477044+00:00 python-feedgen Luke Dashjr 2016-05-26 00:00:37+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - RFC for BIP: Best Practices for Heterogeneous Input Script Transactions - 2025-09-26T15:35:15.483822+00:00 + 2025-10-11T21:44:20.477177+00:00 2016-05-26T00:00:37+00:00 On May 19, 2016, Kristov Atlas introduced a Bitcoin Improvement Proposal (BIP) known as BIP 126. This proposal suggests the implementation of Heterogenous Input Script Transactions (HITs), which allow for transactions to have multiple inputs with different scripts. It is important to note that transactions are not associated with specific Bitcoin addresses, but rather with inputs that spend from Unspent Transaction Outputs (UTXOs). Furthermore, it is uncommon for inputs to have identical scripts.The draft proposal titled "Best Practices for Heterogeneous Input Script Transactions (HITs)" aims to mitigate the negative impact on privacy and user protection protocols when transactions involve inputs with different scripts. The document outlines a set of guidelines to address the privacy concerns associated with HITs, while maximizing the effectiveness of user protection protocols. To achieve this, the specification proposes two forms of HITs: Standard form and alternate form.Standard form HIT transactions must adhere to specific rules. These rules include having an equal number of unique input/output scripts, ensuring all output scripts are unique, requiring at least one pair of outputs with equal value, and making sure the largest output in the transaction belongs to a set containing at least two identically-sized outputs. These requirements serve various purposes such as preventing address reuse, limiting the growth of the UTXO set, and optimizing behavior to make intentional HITs resemble unavoidable HITs.In cases where standard form HITs are not feasible, such as when HITs are unavoidable or the user does not possess sets of UTXOs with identical scripts, alternate form HITs can be employed. A compliant implementation can construct a transaction by finding the smallest combination of inputs whose value is equal to or greater than the desired spend. These inputs are then added to the transaction along with a spend output and change output. The process is repeated to create a second spend output and change output, with the change outputs adjusted as necessary to cover the transaction fee. The aim of this approach is to maximize the effectiveness of user-protecting protocols, minimize the adverse consequences of unavoidable HITs, and limit the impact on UTXO set growth.Non-compliant heterogenous input script transactions may be created if a user wishes to create an output larger than half the total size of their spendable outputs or if their inputs are not distributed in a manner that allows for the completion of the alternate form procedure.In conclusion, this document proposes a set of best practice guidelines to minimize the adverse privacy consequences of creating transactions with inputs composed of different scripts. The guidelines aim to maximize the effectiveness of protection protocols, minimize the negative consequences of unavoidable HITs, and limit the effect on the UTXO set growth. It defines terms related to HITs and provides rules for both standard form and alternate form HITs. The recommendations aim to enhance privacy and optimize the usage of HITs while ensuring compliance with the proposed guidelines. diff --git a/static/bitcoin-dev/May_2016/combined_p2p-authentication-and-encryption-BIPs.xml b/static/bitcoin-dev/May_2016/combined_p2p-authentication-and-encryption-BIPs.xml index 571a867b47..bbd6923e36 100644 --- a/static/bitcoin-dev/May_2016/combined_p2p-authentication-and-encryption-BIPs.xml +++ b/static/bitcoin-dev/May_2016/combined_p2p-authentication-and-encryption-BIPs.xml @@ -2,7 +2,7 @@ 2 Combined summary - p2p authentication and encryption BIPs - 2025-09-26T15:35:02.794848+00:00 + 2025-10-11T21:44:07.721852+00:00 python-feedgen Jonas Schnelli 2016-05-25 09:36:24+00:00 @@ -97,10 +97,11 @@ + 2 Combined summary - p2p authentication and encryption BIPs - 2025-09-26T15:35:02.795034+00:00 + 2025-10-11T21:44:07.722023+00:00 2016-05-25T09:36:24+00:00 The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)). Re-Keying interval is a peer policy with a minimum timespan of 600 seconds.On March 23, 2016, diff --git a/static/bitcoin-dev/May_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml b/static/bitcoin-dev/May_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml index b246447e69..838e35da84 100644 --- a/static/bitcoin-dev/May_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml +++ b/static/bitcoin-dev/May_2016/combined_segwit-subsidy-and-multi-sender-coinjoin-transactions.xml @@ -2,7 +2,7 @@ 2 Combined summary - segwit subsidy and multi-sender (coinjoin) transactions - 2025-09-26T15:35:00.682618+00:00 + 2025-10-11T21:44:05.591872+00:00 python-feedgen Peter Todd 2016-05-03 02:05:11+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - segwit subsidy and multi-sender (coinjoin) transactions - 2025-09-26T15:35:00.682746+00:00 + 2025-10-11T21:44:05.592014+00:00 2016-05-03T02:05:11+00:00 Kristov Atlas, a developer, has shared a sample of 16 transaction IDs from the BitcoinTalk thread on JoinMarket. These transactions reveal an average ratio of 1.38 outputs to inputs. Atlas points out that this situation is unsustainable because eventually the change needs to be combined again or else the unspent transaction outputs (UTXOs) will not get spent. However, the advantage of segwit discount for CoinJoin transactions is that it makes spending UTXOs cheaper and recovers funds that would otherwise be lost to dust.In a discussion on bitcoin-dev about the impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones, Kristov Atlas raises the question of whether this subsidy serves as a financial disincentive against CoinJoin transactions. It is noted that CoinJoin transactions do not necessitate any specific behavior that would be affected by this subsidy. Normal transactions spend a coin and create a payment of a specified amount along with change, and CoinJoins are no different in this regard. While users may sometimes split their outputs to enhance privacy, resulting in the "more outputs" effect, this alone does not increase costs under segwit. The total cost for a user to create an output paying themselves includes both the cost of creation and the eventual cost of spending it. Segwit's cost calculation improvements shift some relative cost from spending to creation, but the same users pay for both. It is important to consider where other transactions are when evaluating the output to input ratio for self-sends. For example, in block 409711, there is an average of 1.4647 outputs per input, although this figure varies across different blocks.Regarding the sample of the 16 transaction IDs posted in the JoinMarket thread on BitcoinTalk, which showed an average ratio of 1.38 outputs to inputs, it is pointed out that it is strange to state this as a fact right after providing data that disproves it. The author also requests that people refrain from discussing Schnorr signatures since they are not currently part of any immediate roadmap. However, it is mentioned that Schnorr signatures for Bitcoin have been in development for years and are one of the first proposed uses of segwit versioning. Schnorr multisignature signature aggregates would significantly reduce the cost of CoinJoin transactions, and if there were any disincentive, it would be eliminated by planned use of segwit versioning.The impact of the 75% Segregated Witness subsidy on CoinJoin transactions and similar ones has raised questions. This subsidy makes signature data, which does not affect the size of the unspent transaction output (UTXO) set, 75% cheaper than data that does impact the UTXO set size. The expectation is that users will prefer transactions that minimize the impact on the UTXO set in order to reduce fees, and developers will design new features that also minimize this impact. While this could potentially act as a disincentive against CoinJoin transactions, it remains unclear if there is any evidence to support this claim. It is worth noting that traditional CoinJoin transactions typically create around two UTXOs for every one they consume, unless address reuse is involved. The author emphasizes that they do not wish to discuss Schnorr signatures in replies, as they are not currently part of any immediate roadmap. diff --git a/static/bitcoin-dev/May_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml b/static/bitcoin-dev/May_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml index a3f99793f6..dd52290065 100644 --- a/static/bitcoin-dev/May_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml +++ b/static/bitcoin-dev/May_2017/combined_Extension-block-proposal-by-Jeffrey-et-al.xml @@ -2,7 +2,7 @@ 2 Combined summary - Extension block proposal by Jeffrey et al - 2025-09-26T15:57:41.408110+00:00 + 2025-10-11T22:10:37.997817+00:00 python-feedgen Christopher Jeffrey 2017-05-10 01:19:30+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - Extension block proposal by Jeffrey et al - 2025-09-26T15:57:41.408280+00:00 + 2025-10-11T22:10:37.997961+00:00 2017-05-10T01:19:30+00:00 A proposal has been made for an extension block that would allow atomic swaps between Bitcoin and Xbitcoin. However, there are concerns about the maturity rule and its impact on legacy wallets. Christopher Jeffrey suggests revising the extension block code to coexist with mainchain segwit and require exiting outputs to only be witness programs. This would mitigate the issue assuming most segwit-supporting wallets implement this rule before the activation of segwit.There is also discussion about allowing direct exit payments to legacy addresses and the lock-up period for exiting outputs. One solution is to add a maturity requirement for exiting outputs, but this would make non-upgraded wallets unusable. Another solution is to move all exiting outputs to the coinbase, but this would deteriorate user experience and essentially become a hardfork. It is suggested that switching to witness programs only and requiring exiting outputs to be witness programs may be a good balance between fungibility and backward-compatibility.The proposal also addresses the issue of making return outputs transparent to unupgraded wallets. The proposed solution is to send them to something non-standard today. The mainchain segwit is important in enabling atomic swaps between Bitcoin and Xbitcoin. The extension block specification/code is being revised to coexist with mainchain segwit and require exiting outputs to only be witness programs.In another discussion, Olaoluwa Osuntokun analyzes the xblock proposal and focuses on the sub-proposal for Lightning Network (LN) safety enhancement. The proposal involves a block-size decrease for each open channel within the network, which reserves space for honest parties to punish dishonest channel counter parties. There is also a proposal for a Pre-Allocated Smart-contract Dispute Arena (PASDA) to address systematic risks in the LN. However, the system has not been fully specified and evaluated yet.Overall, the discussions revolve around the proposed extension block, its compatibility with segwit, the issue of direct exit payments to legacy addresses, and the need for a balance between fungibility and backward-compatibility. The proposal also introduces additional safety measures for Lightning Network (LN) and blockchain availability in case of channel disputes.The writer of the context raises concerns about a new Bitcoin Improvement Proposal (BIP) and expresses disappointment that their proposal was not given more consideration. They criticize the lack of specificity in the proposed approach to resolving transaction malleability and suggest changes to how the merkle root is calculated. Additionally, they question whether direct exit payment to legacy addresses should be allowed and propose limiting the number of soft-fork upgrades, increasing the points for witness v0 outputs, and setting a higher dust threshold.A work-in-progress extension block proposal has been introduced by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. The proposal is available on Github and aims to increase bitcoin transaction throughput without altering existing consensus rules. However, the writer argues that extension blocks create additional complexity compared to other proposals and can potentially create two classes of "full nodes," leaving some insecure. They also mention potential issues with the maximum extension size and the validity of output script code in extension blocks.The Witness Vector specification details that every 73 bytes in the serialized witness vector is worth one additional point, but it doesn't explain why this number was chosen. The writer emphasizes the importance of submitting BIPs in MediaWiki format and for discussion on the bitcoin-dev mailing list rather than social media and news outlets. They assert that extension blocks are more like a hard-fork rather than a soft-fork and highlight the potential legal implications of BIPs not being recognized in certain jurisdictions.The UTXO set behaves fundamentally differently with the extension block proposal, but mostly in a compatible manner. Canonical blocks containing entering outputs must have an extension block commitment, even if it contains all zeroes. The writer suggests adding a special message to the genesis resolution transaction and mentions the possibility of including a witness vector using BIP141 transaction serialization within the extended transaction vector. They also note the enforcement of a consensus dust threshold within the extension block.The deployment name for this specification is "extblk" and appears as "!extblk" in GBT. The writer points out that while the start time for the deactivation deployment is mentioned, there is no information about the timeout or how to continue the extension block. They critique the lack of clarity and specificity in the new BIP and propose alternative solutions. Finally, they caution against specifying policy in BIPs and comment on the potential negative effects of deactivating unused chains. diff --git a/static/bitcoin-dev/May_2017/combined_Non-confirming-block-signalling.xml b/static/bitcoin-dev/May_2017/combined_Non-confirming-block-signalling.xml index 7ffadb4b44..dd3a1f8874 100644 --- a/static/bitcoin-dev/May_2017/combined_Non-confirming-block-signalling.xml +++ b/static/bitcoin-dev/May_2017/combined_Non-confirming-block-signalling.xml @@ -2,7 +2,7 @@ 2 Combined summary - Non-confirming block signalling - 2025-09-26T15:58:15.460226+00:00 + 2025-10-11T22:10:40.126617+00:00 python-feedgen Tomas 2017-05-05 13:09:17+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Non-confirming block signalling - 2025-09-26T15:58:15.460355+00:00 + 2025-10-11T22:10:40.126772+00:00 2017-05-05T13:09:17+00:00 On May 5, 2017, Tomas proposed a method to mark blocks indicating that they were generated without verifying the previous block by using a bit of the version field. This proposal aims to address the issue of reduced security caused by SPV-mining. Bryan Bishop responded to the proposal, acknowledging that it had been previously discussed in a Bitcoin-dev mailing list post from December 2015, which he provided a link to. Tomas's suggestion involves utilizing a specific bit in the version field to indicate blocks that were generated without verifying the previous block. By implementing this marking system, the potential risks associated with SPV-mining can be mitigated. It is important to note that the idea had already been discussed in a Bitcoin-dev mailing list post in December 2015, and Bryan Bishop shared the link to this discussion.In addition to the proposal and the reference to the earlier discussion, Bryan included his contact information in his email signature. His personal website, heybryan.org, was provided along with his phone number. This information allows for further communication and collaboration on the topic.For more detailed information about the proposal, including the full proposal document and related discussions, the BIP can be found on Tomas's GitHub page. diff --git a/static/bitcoin-dev/May_2018/combined_-bitcoin-discuss-Checkpoints-in-the-Blockchain-.xml b/static/bitcoin-dev/May_2018/combined_-bitcoin-discuss-Checkpoints-in-the-Blockchain-.xml index d2d3137426..037cb89100 100644 --- a/static/bitcoin-dev/May_2018/combined_-bitcoin-discuss-Checkpoints-in-the-Blockchain-.xml +++ b/static/bitcoin-dev/May_2018/combined_-bitcoin-discuss-Checkpoints-in-the-Blockchain-.xml @@ -2,7 +2,7 @@ 2 Combined summary - [bitcoin-discuss] Checkpoints in the Blockchain. - 2025-09-26T15:37:51.467339+00:00 + 2025-10-11T21:48:44.132954+00:00 python-feedgen Dave Scotese 2018-05-21 20:03:37+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - [bitcoin-discuss] Checkpoints in the Blockchain. - 2025-09-26T15:37:51.467522+00:00 + 2025-10-11T21:48:44.133104+00:00 2018-05-21T20:03:37+00:00 The Bitcoin-discuss forum has been discussing the importance of deep blockchain corruption recovery mechanisms and the potential issues with using Stuxnet to change copies of the blockchain. Some members suggest rendering the blockchain into something memorable to prevent hijacking of memory, while others argue that the blockchain itself is the perfect solution due to its internal consistency and resistance to attacks. However, concerns have been raised about the creation of two versions of the code, one with a fake checkpoint useful to a powerful attacker.The discussion highlights the need for a shared memory of the state of a recent UTXO Set to obviate the need for historical transaction data and the challenges of choosing between multiple options. It emphasizes the importance of maintaining the integrity of the blockchain to ensure the validity of transactions and the security of the network.One suggestion put forth by Dave Scotese on the mailing list is to render a SHA256 hash into something memorable and difficult to forget. Each of the 256 bits could be used to specify something important about the rendering, which is memorable in an instinctive human-memory way. If enough people involved in Bitcoin recognize this protection, it relieves the need to retain the full blockchain to validate the UTXO Set at that point, as it can be validated without reference to any prior computer record.Scott Roberts disagreed with this premise and proposed using words as a common way of achieving what Scotese was thinking about. By making the checkpoint a hash that meets a difficulty target, the possibilities are reduced to 2^182 at the current hashrate instead of 2^256, requiring only 12 or 13 common words. To address the issue of forgetting passphrases, Scotese suggests coupling the data with more items than usual, creating a phrase memorable only in the language for which the algorithm is developed.An algorithm could be used with the Bip39 word list to categorize the words according to parts of speech. The bits could then be used to determine the next word in a kind of ad-lib, but this creates a phrase that is only memorable in the language for which the algorithm is developed.Overall, the discussion highlights the importance of finding ways to maintain the integrity of the blockchain while making it more accessible and user-friendly. diff --git a/static/bitcoin-dev/May_2019/combined_OP-DIFFICULTY-to-enable-difficulty-hedges-bets-without-an-oracle-and-3rd-party-.xml b/static/bitcoin-dev/May_2019/combined_OP-DIFFICULTY-to-enable-difficulty-hedges-bets-without-an-oracle-and-3rd-party-.xml index f13b84a65b..b183878c0b 100644 --- a/static/bitcoin-dev/May_2019/combined_OP-DIFFICULTY-to-enable-difficulty-hedges-bets-without-an-oracle-and-3rd-party-.xml +++ b/static/bitcoin-dev/May_2019/combined_OP-DIFFICULTY-to-enable-difficulty-hedges-bets-without-an-oracle-and-3rd-party-.xml @@ -2,7 +2,7 @@ 2 Combined summary - OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party. - 2025-09-26T15:40:33.568955+00:00 + 2025-10-11T21:51:59.690996+00:00 python-feedgen Tamas Blummer 2019-05-24 16:23:38+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party. - 2025-09-26T15:40:33.569130+00:00 + 2025-10-11T21:51:59.691168+00:00 2019-05-24T16:23:38+00:00 Tamas Blummer, a blockchain developer, has proposed a new opcode called OP_DIFFICULTY that aims to provide a native solution to hedge risks in Bitcoin mining. The proposed transaction would only be valid after the difficulty-adjusted block in the future. It would involve a multi-sig escrow from participants in the bet, with the winner broadcasting the result. This proposal aligns with Bitcoin's aim to avoid third-party intermediaries and addresses the significant economic interest of the Bitcoin economy.However, there are concerns about the implementation of this proposal. Pieter Wuille has raised concerns about potential complications in implementing mempools and determining the validity of unconfirmed transactions if the difficulty can be directly observed by the script language. Tamas Blummer acknowledges these concerns and suggests that similar constructions are needed for observing block difficulty as for observing block time/height.Nathan Cook proposes an alternative approach using OP_CHECKBLOCKATHEIGHT, but Tamas points out that this opcode fetches the block hash rather than the content of the header, making it unsuitable for comparing difficulty levels. Despite these concerns and alternative suggestions, Tamas Blummer believes that his proposal offers a better solution than traditional commodity markets' futures and options.The current method of using nLocktime denominated in block height to hedge risks in Bitcoin mining has limitations. Blummer argues that a native solution within Bitcoin may be more efficient. The proposed OP_DIFFICULTY opcode would put the value of difficulty onto the stack for the block the transaction is included in. By comparing this value with a strike, the transaction can be executed without counterparty risk and without relying on an oracle to settle the bet.Blummer plans to draft a BIP (Bitcoin Improvement Proposal) for the OP_DIFFICULTY opcode and invites others to provide feedback or contribute to its further development. diff --git a/static/bitcoin-dev/May_2021/combined_Consensus-protocol-immutability-is-a-feature.xml b/static/bitcoin-dev/May_2021/combined_Consensus-protocol-immutability-is-a-feature.xml index 8232f7d777..17138e235b 100644 --- a/static/bitcoin-dev/May_2021/combined_Consensus-protocol-immutability-is-a-feature.xml +++ b/static/bitcoin-dev/May_2021/combined_Consensus-protocol-immutability-is-a-feature.xml @@ -2,7 +2,7 @@ 2 Combined summary - Consensus protocol immutability is a feature - 2025-09-26T15:54:03.712216+00:00 + 2025-10-11T22:00:40.542842+00:00 python-feedgen Jorge Timón 2021-05-25 10:24:43+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - Consensus protocol immutability is a feature - 2025-09-26T15:54:03.712426+00:00 + 2025-10-11T22:00:40.543044+00:00 2021-05-25T10:24:43+00:00 In an email exchange on the bitcoin-dev mailing list, the possibility of using softforks for certain changes to the Bitcoin protocol was discussed. While there were differing opinions on whether hardforks should be completely avoided, one proposal suggested changing the block header format to include both SHA-256 and SHA-3 hashes. This would allow new nodes to see the correct SHA-3 hashes if SHA-256 were to be broken in the future. It was also mentioned that the Merkle Tree could be changed to use SHA3 instead. However, it was noted that making changes to the block header format and proof-of-work computation may require a hardfork. Despite this, the coinbase allows for new commitments to be added, similar to SegWit's `witness` field.The discussion emphasized the challenges and hurdles that any hardfork would have to go through, similar to what Taproot and SegWit experienced. Any hardfork would require more engineering manpower and several years of work before being considered. The conversation provided valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. Interested individuals were also invited to join the conversation by signing up for the mailing list. Another discussion on the bitcoin-dev mailing list explored the limitations and possibilities of implementing softforks. It was noted that while significant changes can be made to transaction and block formats with softforks, there are limitations to what can be changed. The block header format and how proof-of-work is computed from it cannot be changed without a hardfork. The discussion highlighted the hurdles that any hardfork would have to overcome, as seen with SegWit and Taproot. Hardforks would require more engineering manpower and several years of work. The conclusion was that it is important to work with the existing system or start working on future solutions today.A user on the mailing list pointed out that the space of possible softforks is wider than expected. They discussed the potential for changes to block discovery rates and cited SegWit as an example of massive changes that can be made with softforks. However, they noted that the block header format and proof-of-work computation cannot be usefully changed with softforks. The discussion also highlighted the importance of Taproot's implementation and deployment, which took time due to controversy surrounding the activation code. It was emphasized that any hardfork would have to go through similar hurdles and must be prepared to work on it for several years. The discussion concluded by emphasizing the need to find solutions for future problems and mentioned the existence of an "emergency" branch for adding post-quantum signature schemes in case of a quantum break.In another email exchange, the topic of consensus protocol changes in Bitcoin was discussed. One participant argued that hard forks are required for hard consensus changes, while soft forks can be useful. Another participant disagreed and highlighted the importance of consensus protocol changes in improving Bitcoin's efficiency and addressing user needs. They mentioned examples like relative lock time verify and SegWit, which have made lightning transactions easier and more efficient. The discussion touched upon the role of hard forks and soft forks in implementing these changes, as well as the ongoing debate within the Bitcoin community about the balance between stability and adapting to changing user needs.Overall, the email exchanges provided valuable insights into the ongoing discussions around the Bitcoin protocol and its potential updates. They highlighted the challenges and limitations of implementing changes through softforks, the hurdles that any hardfork would have to overcome, and the importance of consensus protocol changes in improving Bitcoin's efficiency and addressing user needs. diff --git a/static/bitcoin-dev/May_2021/combined_Fee-estimates-and-RBF.xml b/static/bitcoin-dev/May_2021/combined_Fee-estimates-and-RBF.xml index cd18164c24..1e4181d4b2 100644 --- a/static/bitcoin-dev/May_2021/combined_Fee-estimates-and-RBF.xml +++ b/static/bitcoin-dev/May_2021/combined_Fee-estimates-and-RBF.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fee estimates and RBF - 2025-09-26T15:54:05.823265+00:00 + 2025-10-11T22:00:42.663962+00:00 python-feedgen ZmnSCPxj 2021-05-18 13:10:12+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Fee estimates and RBF - 2025-09-26T15:54:05.823465+00:00 + 2025-10-11T22:00:42.664141+00:00 2021-05-18T13:10:12+00:00 Implementing Replace-By-Fee (RBF) in financial code presents challenges in exception handling and testing reorgs. Thorough testing is necessary, but code with many branches due to handling exceptions is difficult to cover completely. C-lightning supports RBF, but potential edge cases may cause mishandling of replaced transactions and loss of onchain funds. The combination of RBF and Child-Pays-for-Parent (CPFP) has yet to be explored fully, with potential use cases like the maker-taker model requiring careful exception handling.In a discussion on Bitcoin Stack Exchange, Jeremy and ZmnSCPxj share their thoughts on fee estimation. The recent CVE related to RBF by Antoine Riard and the differences between RBF implementation in Bitcoin Core and btcd are also discussed. However, the reasoning behind not implementing inherited signalling in Bitcoin Core remains unclear.In an email exchange, ZmnSCPxj and Prayank discuss engineering issues related to a full RBF wallet. While ZmnSCPxj believes a true full-RBF wallet should be the goal, he acknowledges the engineering challenges. He explains the process of a true full-RBF wallet and warns about race conditions when miners find new blocks while fees are being bumped. The wallet needs to track "pending spends" and correlate them with actual transactions. ZmnSCPxj also notes that spending unconfirmed inputs may not be safe due to conflicting transactions. Engineering issues pose significant challenges in achieving a true full-RBF wallet.The author of the message agrees that a "true" full-RBF wallet should be the goal for every on-chain wallet but notes the difficulties in achieving this. They explain how some wallets handle unconfirmed inputs and the simplification of database design. To achieve a true full-RBF wallet, the wallet must keep track of pending spends and correlate them with actual transactions. The author admits they have not considered all factors related to this issue.Jeremy Rubin shares a link with Prayank explaining the concept of a "fee-only" wallet. This feature allows users to arrange fee bumps using a separate wallet without disturbing on-chain dependents. It can be cheaper than RBF since users are not subject to the feerate improvement rule. Rubin suggests creating a market via LN for transaction inclusion by a particular date. Prayank raises concerns about different estimations used in wallets and proposes a three-step approach: showing mempool stats, leaving the fee rate decision to the user, and using RBF algorithms for automated bidding.In an email exchange, Jeremy Rubin shares a post on Bitcoin-dev related to background services. He highlights the potential of a separate fee-only wallet for arranging fee bumps without disturbing on-chain dependents. He suggests it could be cheaper than RBF and discusses the idea of creating a market for transaction inclusion. Prayank discusses different fee estimations and suggests sharing mempool stats and allowing users to decide the fee rate. He proposes using RBF algorithms and wonders if the proposed approach would work offline.The writer begins with personal well-being and recovery from COVID-19 before discussing Bitcoin transactions and fee estimations. They question the use of different estimations and propose showing mempool stats and allowing users to decide on the fee rate. They compare this to estimating buy orders in the BTCUSD orderbook. The writer finds current estimations misleading and suggests a three-step approach, including RBF algorithms for automated bidding. They seek input on the proposed approach and provide an example of replacing transactions with different fee rates even when offline. diff --git a/static/bitcoin-dev/May_2021/combined_Opinion-on-proof-of-stake-in-future.xml b/static/bitcoin-dev/May_2021/combined_Opinion-on-proof-of-stake-in-future.xml index 6de55c24bf..5e15456507 100644 --- a/static/bitcoin-dev/May_2021/combined_Opinion-on-proof-of-stake-in-future.xml +++ b/static/bitcoin-dev/May_2021/combined_Opinion-on-proof-of-stake-in-future.xml @@ -2,7 +2,7 @@ 2 Combined summary - Opinion on proof of stake in future - 2025-09-26T15:53:57.426123+00:00 + 2025-10-11T22:00:38.417849+00:00 python-feedgen Billy Tetrud 2021-06-26 16:26:12+00:00 @@ -273,10 +273,11 @@ + 2 Combined summary - Opinion on proof of stake in future - 2025-09-26T15:53:57.426366+00:00 + 2025-10-11T22:00:38.418210+00:00 2021-06-26T16:26:12+00:00 The ongoing debate within the bitcoin-dev community revolves around the compatibility of Proof of Stake (PoS) with Bitcoin's objectives. Some argue that PoS contradicts Bitcoin's permissionless nature and introduces trust into the system, while others propose alternatives like Proof of Burn (PoB) but acknowledge block timing issues. Overall, consensus is that new consensus algorithms must meet high standards, and PoS has not yet demonstrated properties consistent with Bitcoin's objectives.Verifiable Delay Functions (VDFs) are being discussed as a potential solution to regulate block times in proof-of-burn blockchains. However, concerns exist regarding ways to increase sequential speed without compromising energy consumption. Despite these concerns, there are promising developments with VDFs that could address block regulation problems without relying solely on brute-force search PoW.Reducing the block reward in Bitcoin has been proposed as a means to improve its mainstream reputation and reduce energy expenditure. However, it should be noted that the block reward is already being reduced through halving events every four years. Concerns about the environmental impact of Bitcoin mining persist, with estimates suggesting that it consumes more energy than entire countries. Arguments in favor of Bitcoin's energy consumption include the use of renewable energy sources for mining and the potential for Bitcoin to incentivize the development of a more sustainable energy grid.Discussions also revolve around the potential of chip fabs to eliminate the hardware barrier and allow more people to participate in Bitcoin mining. It is believed that the energy economy still has more supply than competition, and as prices drop, renewable energy would outcompete nonrenewable sources. The impact of Bitcoin mining on energy usage is seen as an opportunity for investment in renewable energy sources rather than a cause for shame.Various perspectives on PoS as a consensus mechanism for Bitcoin mining are presented. Some argue against implementing PoS due to security concerns and concentration of power. Others believe that PoS may have advantages for other cryptocurrencies but may not be the best solution for Bitcoin. The discussions highlight the need to find sustainable solutions for mining and energy consumption in the cryptocurrency space, with ongoing exploration of alternatives such as VDFs. diff --git a/static/bitcoin-dev/May_2021/combined_Proposal-Force-to-do-nothing-for-first-9-minutes-to-save-90-of-mining-energy.xml b/static/bitcoin-dev/May_2021/combined_Proposal-Force-to-do-nothing-for-first-9-minutes-to-save-90-of-mining-energy.xml index 323ac9d472..c6019951a9 100644 --- a/static/bitcoin-dev/May_2021/combined_Proposal-Force-to-do-nothing-for-first-9-minutes-to-save-90-of-mining-energy.xml +++ b/static/bitcoin-dev/May_2021/combined_Proposal-Force-to-do-nothing-for-first-9-minutes-to-save-90-of-mining-energy.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy - 2025-09-26T15:53:55.310736+00:00 + 2025-10-11T22:00:36.284191+00:00 python-feedgen ZmnSCPxj 2021-05-18 08:04:56+00:00 @@ -89,10 +89,11 @@ + 2 Combined summary - Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy - 2025-09-26T15:53:55.310944+00:00 + 2025-10-11T22:00:36.284395+00:00 2021-05-18T08:04:56+00:00 One of the main concerns surrounding Bitcoin mining is its high energy consumption. However, it is important to consider that the cost of mining Bitcoin involves more than just energy, including capital expenses and operational costs. Miners who have access to excess waste energy, such as Chinese miners near hydropower stations, pay a near-zero price for energy, which contributes significantly to the total energy usage of Bitcoin. While the energy usage is high, it is worth noting that a considerable amount of this energy comes from renewable sources, making the carbon footprint of Bitcoin less alarming than it seems.The email thread discusses various proposals to address the issue of energy consumption in Bitcoin mining. One proposal suggests encouraging users to support "green miners" by allowing only these miners to process their transactions. This would create economic incentives for miners to use green energy or purchase offsets. Another proposal suggests implementing a clock mechanism on a peer network level, where transactions would be broadcasted after a 9-minute delay. This could potentially decrease energy consumption, but there are concerns about its feasibility and effectiveness.There is also a discussion about the relationship between mining budgets and energy expenditure. Some argue that reducing energy consumption may lead to increased spending on hardware. It is important to find a balance between energy efficiency and maintaining the security and robustness of the Bitcoin network.In an email to the bitcoin-dev mailing list, Michael Fuhrmann proposes the idea of not mining for the first 9 minutes after a block is found. This aims to prevent pre-mining during this time window. However, there are concerns about the security of the network and the synchronization of clocks in a distributed network. While the idea may be appreciated, it appears to be impractical.Overall, the email thread provides a comprehensive overview of the different proposals and considerations related to the issue of energy consumption in Bitcoin mining. Finding a working solution that addresses energy concerns without compromising the robustness of the network is crucial for the sustainability of Bitcoin mining. diff --git a/static/bitcoin-dev/May_2021/combined_maximum-block-height-on-transaction.xml b/static/bitcoin-dev/May_2021/combined_maximum-block-height-on-transaction.xml index baa0f989a5..a79cb0fd4c 100644 --- a/static/bitcoin-dev/May_2021/combined_maximum-block-height-on-transaction.xml +++ b/static/bitcoin-dev/May_2021/combined_maximum-block-height-on-transaction.xml @@ -2,7 +2,7 @@ 2 Combined summary - maximum block height on transaction - 2025-09-26T15:53:53.196232+00:00 + 2025-10-11T22:00:34.153936+00:00 python-feedgen ZmnSCPxj 2021-05-03 02:30:07+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - maximum block height on transaction - 2025-09-26T15:53:53.196376+00:00 + 2025-10-11T22:00:34.154123+00:00 2021-05-03T02:30:07+00:00 The email thread on the bitcoin-dev mailing list discusses the issue of increasing CPU usage and code complexity when adding a field or opcode to transactions. It proposes a solution involving a "hidden" field in a transaction with a default value compatible with pre-softfork rules, along with an opcode that manipulates this field. Additionally, the proposal suggests implementing a maximum block height on transactions using a new field and opcode. This functionality allows users to be safely offline at the time of timeout in any complicated timeout-based contract. However, it also increases risk for the contractor holding lien on the hashlock branch in a two-participant contract, making the proposal less significant improvement to Bitcoin.Satoshi's statement about the inability to safely implement OP_BLOCKNUMBER is brought up in the discussion. One user suggests that software could be written to warn users about edge cases, arguing that if a person waits for 6 blocks before accepting a transaction as confirmed, there should be no likely scenario where any finalized transaction needs to be reverted. They believe that any transaction with 5 or fewer confirmations should be considered fair game for reversal. The possibility of buggy software is not seen as a good reason to block an opcode. Another user suggests using two transactions, one with a desired expiry at H and another with nlocktime H, to accomplish the goal of a rough expiry. After a timeout, participants in the first transaction can cancel the action using the second transaction. However, limiting the maximum block height for a specific transaction would have the same problem as cited above for OP_BLOCKNUMBER. A third user asks if there is any way to specify a maximum block height on a transaction and considers it useful. The discussion emphasizes the risks and limitations of implementing OP_BLOCKNUMBER. It is noted that limiting the maximum block height for a specific transaction would face the same problem as OP_BLOCKNUMBER in the event of a blockchain reorganization. Instead, nTimeLock is suggested as an alternative solution. nTimeLock is an open transaction that can be replaced with new versions until the deadline. It could be used to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. While nTimeLock is not currently enabled or used, the support for its implementation is available.In response to the discussion, a user suggests accomplishing a rough goal by using tx A with a desired expiry at H and then using tx B with nlocktime H and creating outputs equivalent to inputs. After a timeout, participants in tx A can cancel the action using tx B. However, the effectiveness of this approach depends on the use case and further clarification is needed.The possibility of specifying a maximum block height on a transaction is raised during a discussion on the bitcoin-dev mailing list. However, it is pointed out that such a feature would encounter the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorganization. As an alternative, nTimeLock is suggested. This open transaction can be replaced with new versions until the deadline, and the highest version at the deadline is recorded. It can be utilized for escrow transactions that automatically lock and proceed unless revoked before the deadline. Although nTimeLock is not currently enabled or used, the necessary support exists for its future implementation.A user on the Bitcoin development mailing list inquires about the possibility of specifying a maximum block height for a transaction. However, it is noted that implementing such a feature would present the same issue as the OP_BLOCKNUMBER transaction, which becomes invalid during a blockchain reorganization. Instead, an alternative option called nTimeLock is proposed. nTimeLock allows for an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is then recorded. This feature could be used for escrow transactions that automatically lock and proceed unless revoked before the deadline. While nTimeLock is not currently enabled or used, the necessary support exists for its implementation in the future.The inquiry regarding the possibility of specifying a maximum block height on a transaction is raised by a user. However, it is pointed out that this feature would face the same problem as the OP_BLOCKNUMBER transaction in the event of a blockchain reorg. An alternative suggestion is made to use nTimeLock, which is an open transaction that can be replaced with new versions until the deadline. The highest version at the deadline is recorded. This feature could be useful for creating escrow transactions that automatically lock and go through unless revoked before the deadline. While nTimeLock is currently not enabled or used, the support for its implementation is available. In conclusion, the discussions on the bitcoin-dev mailing list revolve around the issue of increasing CPU usage and code complexity when adding fields or opcodes to transactions. Various suggestions and alternatives are proposed, such as using hidden fields, implementing a maximum block height, and utilizing nTimeLock. The limitations of implementing OP_BLOCKNUMBER and the potential risks associated with each solution are thoroughly examined. Ultimately, any modification to diff --git a/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml b/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml index 4fe0e34d72..78e8881f1e 100644 --- a/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml +++ b/static/bitcoin-dev/May_2022/combined_What-to-do-when-contentious-soft-fork-activations-are-attempted.xml @@ -2,7 +2,7 @@ 2 Combined summary - What to do when contentious soft fork activations are attempted - 2025-09-26T15:59:27.831598+00:00 + 2025-10-11T22:11:26.908744+00:00 python-feedgen Jorge Timón 2022-05-07 01:57:39+00:00 @@ -46,10 +46,11 @@ + 2 Combined summary - What to do when contentious soft fork activations are attempted - 2025-09-26T15:59:27.831763+00:00 + 2025-10-11T22:11:26.908887+00:00 2022-05-07T01:57:39+00:00 The email conversation between Jorge Timón and John Tromp on the Bitcoin-dev mailing list has sparked a discussion on irony. Timón accused Tromp of making personal attacks against Andreas Antonopoulos for his opinions on bip8. However, Tromp pointed out that Timón himself had made a personal attack by calling Jeremy ignorant about bip8. This led to a discussion on how ironic it is that people who base their arguments on personal attacks are also the ones who complain the most about personal attacks.In a separate discussion on the bitcoin-dev mailing list, Jorge Timón questioned a claim made by Russell O'Connor about the design of Speedy Trial (ST). Timón found the claim strange and stated that the grace period for slower activation after lock-in was added to address concerns raised by people who disliked the proposal. However, he still believed that speedy trial was a bad proposal due to incorrect analysis. O'Connor responded by quoting his own blog post where he clarified that the design of speedy trial was not based on any activation philosophy about failing fast.In another email exchange, Jorge Timón suggested that it is unnecessary to personally attack Andreas for his opinions. He argued that the only reason Jeremy Rubin does not like BIP8 is because he is ignorant about it and has not reviewed it enough. However, John Tromp pointed out the irony in equating 'clueless about BIP119' with a personal attack and then calling Jeremy ignorant about BIP8. The conversation seems to revolve around differences of opinion regarding different Bitcoin Improvement Proposals (BIPs).In a separate email thread, Ryan Grant defends the OP_CTV covenant proposal after Jorge Timón questioned Andreas' criticism. Ryan argues that OP_CTV covenants cannot restrict any address that the sender does not control and criticizes Andreas for not code-reviewing BIP119 or the pull request. Ryan believes that Andreas did not look into the reason why the proposed client was safe and would not cause a chain split. The conversation also references Russell O'Connor's explanation for how Speedy Trials arose in the consensus process and how it was designed.The email threads also touch upon the concept of covenants in Bitcoin and the contributions made by individuals towards it. There is a mention of Bip8 and the importance of being open-minded to understand its analysis. The discussions revolve around the need for education, avoiding personal attacks, addressing misinformation, and looking at technical details when discussing contentious soft forks and covenant proposals.Michael Folkson expresses his thoughts on the recent attempt to activate a contentious soft fork and questions what should be done differently if such attempts happen again. He believes that it is unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split and suggests there should be a personal cost to dissuade them from trying it again. Folkson acknowledges that Bitcoin is a permissionless network and no authority can stop such attempts, but hopes that people will actively resist and prevent the network from being fundamentally broken.Overall, the email exchanges and threads highlight discussions on irony, differences of opinion regarding Bitcoin Improvement Proposals, the design of Speedy Trial, criticism of covenant proposals, addressing misinformation, and the recent attempt to activate a contentious soft fork. The conversations emphasize the importance of education, avoiding personal attacks, and considering technical details when discussing contentious topics in the Bitcoin community. diff --git a/static/bitcoin-dev/May_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml b/static/bitcoin-dev/May_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml index 59d51a3551..9252784f29 100644 --- a/static/bitcoin-dev/May_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml +++ b/static/bitcoin-dev/May_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml @@ -2,7 +2,7 @@ 2 Combined summary - [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? - 2025-09-26T14:32:52.599750+00:00 + 2025-10-11T21:57:46.193414+00:00 python-feedgen ArmchairCryptologist 2023-11-04 09:58:48+00:00 @@ -105,10 +105,11 @@ + 2 Combined summary - [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? - 2025-09-26T14:32:52.599917+00:00 + 2025-10-11T21:57:46.193603+00:00 2023-11-04T09:58:48+00:00 Bitcoin developers are engaged in discussions to find solutions for the current high fee environment, prevent spam transactions, and ensure the long-term sustainability and decentralization of the network. Proposed solutions include fixing layered protocols, introducing new opcodes like OP_ZKP, reallocating block space, and penalizing non-economic transactions. The goal is to strike a balance between reducing fees, preventing spam, and maintaining the economic viability and security of the network. Ali Sherief expresses concern over congestion caused by side projects like BRC-20 and suggests implementing BIPs or commits in the Bitcoin Core codebase to address the issue. Michael Folkson argues that consensus-compatible transactions paying market-rate fees are functioning as intended. However, the debate continues on finding effective solutions while preserving maximum freedom and valid use cases. The email exchange also discusses the purpose of paying higher transaction fees than the received amount, the lack of Lightning wallets for desktop, and the need for GUI wallets to interact with the Lightning Network. Overall, the focus is on addressing congestion, preventing spam, and ensuring smooth operation of the Bitcoin network as a peer-to-peer digital currency. diff --git a/static/bitcoin-dev/May_2023/combined_tx-max-fee.xml b/static/bitcoin-dev/May_2023/combined_tx-max-fee.xml index 992a5acb47..17c05df417 100644 --- a/static/bitcoin-dev/May_2023/combined_tx-max-fee.xml +++ b/static/bitcoin-dev/May_2023/combined_tx-max-fee.xml @@ -2,7 +2,7 @@ 2 Combined summary - tx max fee - 2025-09-26T14:33:05.451790+00:00 + 2025-10-11T21:57:48.320247+00:00 python-feedgen Tom Harding 2023-05-12 00:06:51+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - tx max fee - 2025-09-26T14:33:05.451950+00:00 + 2025-10-11T21:57:48.320413+00:00 2023-05-12T00:06:51+00:00 On the bitcoin-dev mailing list, a user named vjudeu proposed a new method of replacing transactions with multiple smaller transactions. The proposal suggests that transactions paying "fee > sum" can be replaced by N transactions paying "fee < sum". This would allow users to split up large transactions into smaller ones, potentially saving on fees.The discussion sparked among members of the bitcoin development community, with some expressing concern about the potential impact on the network's mempool and block size. Others pointed out that this approach could improve fee estimation for users and reduce the risk of overpaying for transactions.The conversation also revolves around the use case of paying more fees than outputs to incentivize honest mining during state-level censorship attacks. It is suggested that instead of changing the "max fee" rule, a better solution would be to introduce op_ctv, which allows many users to pool fees and share a single utxo.Furthermore, it is explained that even if the "max fee" rule were changed, it could still be avoided by splitting the transaction into multiple transactions, each paying one satoshi per virtual byte. Maintaining balances and using change addresses would not be a deterrent as the transactions could be prepared upfront as part of the protocol and released all at once. This can be achieved through HD wallets, which only require storing a single key and generating addresses as needed.The proposal raises interesting questions about the tradeoffs between transaction size, fees, and network congestion. It remains to be seen whether this idea will be implemented or how it might affect the broader bitcoin ecosystem. However, it is clear that innovation and experimentation are still alive and well in the world of cryptocurrency development.Overall, the discussion explores the possibility of changing the "max fee" rule to output amounts in Bitcoin transactions. While some argue that it could help prevent spam and denial-of-service attacks, others raise concerns about the potential impact on fees, mempool, and block size. The proposal also touches on alternative solutions such as op_ctv and the use of multiple smaller transactions with lower fees. The conversation showcases the ongoing debate and exploration of new ideas within the bitcoin-dev community. diff --git a/static/bitcoin-dev/May_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml b/static/bitcoin-dev/May_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml index dab411d1c4..e80bc2bdc3 100644 --- a/static/bitcoin-dev/May_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml +++ b/static/bitcoin-dev/May_2025/combined_BIP39-Extension-for-Manual-Seed-Phrase-Creation.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP39 Extension for Manual Seed Phrase Creation - 2025-09-26T14:38:50.293513+00:00 + 2025-10-11T22:12:49.819594+00:00 python-feedgen Russell OConnor 2025-06-04 17:45:00+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - BIP39 Extension for Manual Seed Phrase Creation - 2025-09-26T14:38:50.293679+00:00 + 2025-10-11T22:12:49.819749+00:00 2025-06-04T17:45:00+00:00 The discussion explores the nuances and potential improvements to the BIP39 checksum mechanism, focusing on alternative methods for generating and verifying mnemonic phrases. The conversation begins with an acknowledgment of the possible advantages in manually generating randomness over relying on computer chips' hidden processes. It introduces BIP-93, also known as codex32, as a protocol that supports both human and computer-generated randomness, facilitating secret sharing and emphasizing transparency in the generation process. This approach addresses concerns about the opacity of current systems and suggests a method that could enhance user trust and security. diff --git a/static/bitcoin-dev/Nov_2012/combined_-ANNOUNCE-picocoin-and-libccoin-C-based-bitcoin-library-and-client.xml b/static/bitcoin-dev/Nov_2012/combined_-ANNOUNCE-picocoin-and-libccoin-C-based-bitcoin-library-and-client.xml index 18685e8cbb..181cc76d93 100644 --- a/static/bitcoin-dev/Nov_2012/combined_-ANNOUNCE-picocoin-and-libccoin-C-based-bitcoin-library-and-client.xml +++ b/static/bitcoin-dev/Nov_2012/combined_-ANNOUNCE-picocoin-and-libccoin-C-based-bitcoin-library-and-client.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client - 2023-08-01T04:17:04.895906+00:00 + 2025-10-11T21:47:44.640258+00:00 + python-feedgen Peter Vessenes 2012-11-28 17:29:04+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client - 2023-08-01T04:17:04.895906+00:00 + 2025-10-11T21:47:44.640465+00:00 - According to an email response by Mike Hearn, both libccoin and picocoin should work on Windows. However, he notes that picocoin may be less secure on this platform due to the lack of fork. Despite this, Mike suggests that Windows has good sandboxing support and proposes the potential implementation of Win32 for the same purpose.The email also includes a link to Go Parallel, a resource that provides updates on parallel hardware and programming. It seems that the user is interested in exploring libccoin and picocoin on Windows, and this response provides some insight into their compatibility and security considerations.Picocoin is a new bitcoin implementation that comes with a bitcoin library called libccoin. This library supports various essential features of a bitcoin client, such as network datastructures, script parsing and validation, transaction and block validation, headers-only or full block database, and more. Picocoin itself is a command line/JSON-driven bitcoin wallet with advanced security features like required wallet encryption and fork-based process separation of P2P networking and wallet.Some notable features of picocoin include support for multiple block chains, bloom filtering, and improved security. The announcement also mentions that code contributions, comments, and donations are welcome.At the end of the email, there is a signature from Peter Vessenes, CEO of CoinLab. 2012-11-28T17:29:04+00:00 + According to an email response by Mike Hearn, both libccoin and picocoin should work on Windows. However, he notes that picocoin may be less secure on this platform due to the lack of fork. Despite this, Mike suggests that Windows has good sandboxing support and proposes the potential implementation of Win32 for the same purpose.The email also includes a link to Go Parallel, a resource that provides updates on parallel hardware and programming. It seems that the user is interested in exploring libccoin and picocoin on Windows, and this response provides some insight into their compatibility and security considerations.Picocoin is a new bitcoin implementation that comes with a bitcoin library called libccoin. This library supports various essential features of a bitcoin client, such as network datastructures, script parsing and validation, transaction and block validation, headers-only or full block database, and more. Picocoin itself is a command line/JSON-driven bitcoin wallet with advanced security features like required wallet encryption and fork-based process separation of P2P networking and wallet.Some notable features of picocoin include support for multiple block chains, bloom filtering, and improved security. The announcement also mentions that code contributions, comments, and donations are welcome.At the end of the email, there is a signature from Peter Vessenes, CEO of CoinLab. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2012/combined_Draft-BIP-for-Bloom-filtering.xml b/static/bitcoin-dev/Nov_2012/combined_Draft-BIP-for-Bloom-filtering.xml index d11a8d6a99..c0429ea38d 100644 --- a/static/bitcoin-dev/Nov_2012/combined_Draft-BIP-for-Bloom-filtering.xml +++ b/static/bitcoin-dev/Nov_2012/combined_Draft-BIP-for-Bloom-filtering.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP for Bloom filtering - 2023-08-01T04:02:04.922697+00:00 + 2025-10-11T21:47:51.016110+00:00 + python-feedgen Mike Hearn 2013-02-20 12:44:56+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for Bloom filtering - 2023-08-01T04:02:04.922697+00:00 + 2025-10-11T21:47:51.016385+00:00 - In the provided context, the author discusses the proposal for delaying the reception of inventory messages (invs) in the Bitcoin Improvement Proposal (BIP). They realize that the current method of delaying invs is arbitrary and suggest a better approach. The proposed solution involves sending a bloom filter in the version message itself, allowing for the filter to be calculated simultaneously with establishing network connections.The author acknowledges that creating a Bloom filter is a fast process. However, they note that deterministic wallets may require multiple calculations to find the keys to scan for. Despite this potential complexity, the proposed approach of including a bloom filter in the version message allows for efficient parallel processing.Additionally, the author mentions the process of obtaining an allocated number for the BIP. They feel that this process may be excessive for their particular proposal. This demonstrates the author's consideration of the existing procedures and their awareness of the broader framework within which their suggestion exists.By addressing the issue of delaying invs and proposing an alternative method involving bloom filters, the author highlights a potential improvement to the Bitcoin protocol. Their understanding of the technical aspects and the existing processes surrounding BIPs lends credibility to their proposal. 2013-02-20T12:44:56+00:00 + In the provided context, the author discusses the proposal for delaying the reception of inventory messages (invs) in the Bitcoin Improvement Proposal (BIP). They realize that the current method of delaying invs is arbitrary and suggest a better approach. The proposed solution involves sending a bloom filter in the version message itself, allowing for the filter to be calculated simultaneously with establishing network connections.The author acknowledges that creating a Bloom filter is a fast process. However, they note that deterministic wallets may require multiple calculations to find the keys to scan for. Despite this potential complexity, the proposed approach of including a bloom filter in the version message allows for efficient parallel processing.Additionally, the author mentions the process of obtaining an allocated number for the BIP. They feel that this process may be excessive for their particular proposal. This demonstrates the author's consideration of the existing procedures and their awareness of the broader framework within which their suggestion exists.By addressing the issue of delaying invs and proposing an alternative method involving bloom filters, the author highlights a potential improvement to the Bitcoin protocol. Their understanding of the technical aspects and the existing processes surrounding BIPs lends credibility to their proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2012/combined_Electrum-security-model-concerns.xml b/static/bitcoin-dev/Nov_2012/combined_Electrum-security-model-concerns.xml index b11fa250a7..61ba76f05f 100644 --- a/static/bitcoin-dev/Nov_2012/combined_Electrum-security-model-concerns.xml +++ b/static/bitcoin-dev/Nov_2012/combined_Electrum-security-model-concerns.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Electrum security model concerns - 2023-08-01T03:58:45.909360+00:00 + 2025-10-11T21:47:48.892293+00:00 + python-feedgen Mike Hearn 2012-11-16 17:44:32+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Electrum security model concerns - 2023-08-01T03:58:45.910359+00:00 + 2025-10-11T21:47:48.892525+00:00 - In a conversation, the handling of wallet state in the presence of re-orgs is a concern. Transactions are checked to appear in the blockchain, but it is unclear if the wallet will be in the right state during a chain switch. A message from Thomas implies that there is no re-org handling at all. The conversation then shifts to a comparison between Electrum and MultiBit in terms of their handling of SPV work. The speaker asks how they differ beyond deterministic wallet seeding. Another conversation discusses the challenges of finding someone trustworthy and capable to work on the bitcoin.org website and emphasizes the need for better communication and understanding within the community to avoid conflicts. In an email thread, various issues related to Bitcoin are discussed, including concerns about the security model of Electrum and the importance of effectively communicating transaction confidence to users. The conversation also touches upon the challenges of developing and promoting Bitcoin. The conversation revolves around the functionality and potential risks of Electrum as a thin client, with a focus on its merchant daemon. The unauthenticated cleartext JSON protocol between clients and servers is mentioned, as well as the difficulty in communicating transaction confidence to users. The conversation highlights the need for clear explanations and appropriate caution for clients and security models on bitcoin.org. Another discussion addresses the security implications of thin clients, particularly Electrum, and the lack of awareness among users about the associated risks. The conversation emphasizes the need for better security features in client models and improved communication to prevent negative press for Bitcoin. The author of a message requests a proper discussion on understanding the bitcoinj security model. They have rewritten and extended a page on the subject, linking to the ETH paper, and highlight the differences between Electrum and bitcoinj in terms of user and app developer focus. The future divergence of software used by end-users and merchants is predicted, making it easier to tailor documentation to each demographic. Additionally, optimizations such as bloom filtering and better peer selection logic may render Electrum-type services obsolete. Concerns are raised about the security model of Electrum, as the website lacks detailed information and makes factually incorrect claims. A proper discussion is needed to avoid misunderstandings and encourage safer user behaviors. The bitcoinj security model is also critiqued for false claims regarding detecting double spends, emphasizing the need for a thorough examination of Electrum's security model. 2012-11-16T17:44:32+00:00 + In a conversation, the handling of wallet state in the presence of re-orgs is a concern. Transactions are checked to appear in the blockchain, but it is unclear if the wallet will be in the right state during a chain switch. A message from Thomas implies that there is no re-org handling at all. The conversation then shifts to a comparison between Electrum and MultiBit in terms of their handling of SPV work. The speaker asks how they differ beyond deterministic wallet seeding. Another conversation discusses the challenges of finding someone trustworthy and capable to work on the bitcoin.org website and emphasizes the need for better communication and understanding within the community to avoid conflicts. In an email thread, various issues related to Bitcoin are discussed, including concerns about the security model of Electrum and the importance of effectively communicating transaction confidence to users. The conversation also touches upon the challenges of developing and promoting Bitcoin. The conversation revolves around the functionality and potential risks of Electrum as a thin client, with a focus on its merchant daemon. The unauthenticated cleartext JSON protocol between clients and servers is mentioned, as well as the difficulty in communicating transaction confidence to users. The conversation highlights the need for clear explanations and appropriate caution for clients and security models on bitcoin.org. Another discussion addresses the security implications of thin clients, particularly Electrum, and the lack of awareness among users about the associated risks. The conversation emphasizes the need for better security features in client models and improved communication to prevent negative press for Bitcoin. The author of a message requests a proper discussion on understanding the bitcoinj security model. They have rewritten and extended a page on the subject, linking to the ETH paper, and highlight the differences between Electrum and bitcoinj in terms of user and app developer focus. The future divergence of software used by end-users and merchants is predicted, making it easier to tailor documentation to each demographic. Additionally, optimizations such as bloom filtering and better peer selection logic may render Electrum-type services obsolete. Concerns are raised about the security model of Electrum, as the website lacks detailed information and makes factually incorrect claims. A proper discussion is needed to avoid misunderstandings and encourage safer user behaviors. The bitcoinj security model is also critiqued for false claims regarding detecting double spends, emphasizing the need for a thorough examination of Electrum's security model. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2012/combined_Has-anyone-compiled-under-MacOS-10-8-.xml b/static/bitcoin-dev/Nov_2012/combined_Has-anyone-compiled-under-MacOS-10-8-.xml index 0850da7613..4987bd3d80 100644 --- a/static/bitcoin-dev/Nov_2012/combined_Has-anyone-compiled-under-MacOS-10-8-.xml +++ b/static/bitcoin-dev/Nov_2012/combined_Has-anyone-compiled-under-MacOS-10-8-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Has anyone compiled under MacOS 10.8? - 2023-08-01T04:06:56.186547+00:00 + 2025-10-11T21:47:53.140869+00:00 + python-feedgen Mike Hearn 2012-12-27 16:28:59+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Has anyone compiled under MacOS 10.8? - 2023-08-01T04:06:56.186547+00:00 + 2025-10-11T21:47:53.141009+00:00 - The problem of Boost not playing nicely with default build instructions has resurfaced. It appears that there may be a compatibility issue between Boost and the default build instructions, possibly due to a switch to clang++. To address this, a magic incantation needs to be added at the top, possibly related to how qmake is being used. Running qmake like "gmake -spec macx-g++" can generate a real makefile instead of an xcode project. However, this may make gcc stricter than intended.In a related email, Mike Hearn discovered that the issue was caused by using an older version of the Qt SDK with the new MacOS version. Reinstalling Qt resolved the problem for him. However, he also mentioned that he had previously requested assistance in finding a solution, as he was unable to investigate further at the moment. He specifically asked for someone to share a recipe or solution to fix the issue.In summary, there seems to be an issue with Boost and the default build instructions, potentially related to the switch to clang++. The user who raised the concern plans to investigate further but is currently seeking help from others. They are specifically requesting a recipe or solution to fix the problem and encourage anyone with information to reach out. 2012-12-27T16:28:59+00:00 + The problem of Boost not playing nicely with default build instructions has resurfaced. It appears that there may be a compatibility issue between Boost and the default build instructions, possibly due to a switch to clang++. To address this, a magic incantation needs to be added at the top, possibly related to how qmake is being used. Running qmake like "gmake -spec macx-g++" can generate a real makefile instead of an xcode project. However, this may make gcc stricter than intended.In a related email, Mike Hearn discovered that the issue was caused by using an older version of the Qt SDK with the new MacOS version. Reinstalling Qt resolved the problem for him. However, he also mentioned that he had previously requested assistance in finding a solution, as he was unable to investigate further at the moment. He specifically asked for someone to share a recipe or solution to fix the issue.In summary, there seems to be an issue with Boost and the default build instructions, potentially related to the switch to clang++. The user who raised the concern plans to investigate further but is currently seeking help from others. They are specifically requesting a recipe or solution to fix the problem and encourage anyone with information to reach out. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2012/combined_IRC-meeting-agenda-18-00-UTC-Thursday.xml b/static/bitcoin-dev/Nov_2012/combined_IRC-meeting-agenda-18-00-UTC-Thursday.xml index d48420d21b..e5d8c4ad1b 100644 --- a/static/bitcoin-dev/Nov_2012/combined_IRC-meeting-agenda-18-00-UTC-Thursday.xml +++ b/static/bitcoin-dev/Nov_2012/combined_IRC-meeting-agenda-18-00-UTC-Thursday.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - IRC meeting agenda, 18:00 UTC Thursday - 2023-08-01T04:06:45.000716+00:00 + 2025-10-11T21:47:46.762133+00:00 + python-feedgen Gregory Maxwell 2012-11-08 13:07:31+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - IRC meeting agenda, 18:00 UTC Thursday - 2023-08-01T04:06:45.000716+00:00 + 2025-10-11T21:47:46.762301+00:00 - On November 8th, 2012, Mike Hearn suggested freezing the features of version 0.8 in order to focus on implementing the bloom filtering work, which is considered an important scalability and performance improvement for the network. Another developer expressed concern about overselling the update to miners and merchants, but agreed with the sentiment. However, there were concerns that freezing RPC and GUI changes might cause delays in quality assurance (QA) for those updates. It was suggested that discussions should take place to determine what needs to be done to prepare the current version for release.In a discussion about Bitcoin Improvement Proposals (BIPs), Mike Hearn questioned the need for a process to allocate numbers and suggested removing that part from the BIP template. He also questioned the need for an editing role in the BIP process. While there have been some issues with collisions and nonsensical proposals in the past, many BIPs do not result in useful discussion. Pieter expressed his desire to see more non-core proposals related to Bitcoin being discussed. Both Mike and Pieter agreed that more time is needed to complete the bloom filtering work before freezing features in version 0.8. They believed that promoting the release as an important scalability and performance improvement for the network would be easier once the bloom filtering work is complete. Ultraprune and bloom filtering are considered the two major scalability improvements available at the moment. There are still some TODOs left for ultraprune, including auto-migrating old data and UTXO set consistency checks at startup.The author of the message, who is unable to attend meetings on IRC, suggested using email for decision making. They also questioned the need for a process to allocate numbers in the BIP process and suggested removing the editing role. The author expressed a desire for more time to work on bloom filtering before freezing features in version 0.8 of Bitcoin. They believed that promoting the release as important for scalability and performance would help encourage upgrades, with ultraprune and bloom filtering being the two major scalability improvements currently available.Gavin Andresen, a prominent personality in the world of Bitcoin, suggested Thursdays at 18:00 UTC as a suitable time for the core development team to meet and chat on the #bitcoin-dev freenode IRC channel. Pieter responded positively to Gavin's suggestion, indicating agreement with the proposed meeting schedule. The #bitcoin-dev freenode IRC channel will provide an opportunity for members of the core development team to collaborate and discuss issues related to Bitcoin.In a discussion about the success of BIP, Luke-Jr emphasized the importance of encouraging wider community participation. Slush argued that it's not just about the BIP process, but also the content of proposals. He pointed out that he had promised to write a BIP draft for Stratum and implemented get_transactions method to allow Stratum jobs inspection. Luke explained that the BIP process involves more than just writing a document; it also requires peer review and changes to meet the community's needs. The failure of key members of the community to participate in the GBT BIP process was identified as an issue that needs to be addressed to improve the process. While get_transactions is a step in the right direction, it may take time for Stratum to reach the same level as GBT. Luke's comments were not intended to bash Stratum or complain about the past, but to learn from it and figure out how to improve things for the future.In an email exchange on November 6, 2012, Luke-Jr expressed the importance of encouraging wider community participation for the success of BIP. Slush argued that it's not about the BIP process, but rather the content of particular proposals. The discussion then shifted to the topic of stratum mining and its related protocol. Luke-Jr suggested that the mess with stratum mining is a direct result of lack of peer review and contribution toward the stratum protocol. Slush countered that there have been peer reviews of the protocol and that stratum is not related to the Bitcoin protocol or implementation. Slush also expressed frustration with Luke-Jr's constant bashing of stratum in his posts and reminded him that he had promised to write a BIP draft for stratum and had proposed and implemented a get_transactions method for stratum jobs inspection. Slush apologized to other developers who had to read Luke-Jr's negative posts and vowed to try to refrain from responding in the future.Gavin Andresen, a member of the Bitcoin core development team, proposed a meeting every Thursday at 18:00 UTC via the #bitcoin-dev freenode IRC channel to discuss issues related to Bitcoin. The agenda for the meeting included creating a to-do list to get to a 0.8 release candidate, freezing the features, working on testing new features, fixing existing bugs, and evaluating the BIP process. Gavin expressed concerns about the absence of Amir and suggested having a successor in place. 2012-11-08T13:07:31+00:00 + On November 8th, 2012, Mike Hearn suggested freezing the features of version 0.8 in order to focus on implementing the bloom filtering work, which is considered an important scalability and performance improvement for the network. Another developer expressed concern about overselling the update to miners and merchants, but agreed with the sentiment. However, there were concerns that freezing RPC and GUI changes might cause delays in quality assurance (QA) for those updates. It was suggested that discussions should take place to determine what needs to be done to prepare the current version for release.In a discussion about Bitcoin Improvement Proposals (BIPs), Mike Hearn questioned the need for a process to allocate numbers and suggested removing that part from the BIP template. He also questioned the need for an editing role in the BIP process. While there have been some issues with collisions and nonsensical proposals in the past, many BIPs do not result in useful discussion. Pieter expressed his desire to see more non-core proposals related to Bitcoin being discussed. Both Mike and Pieter agreed that more time is needed to complete the bloom filtering work before freezing features in version 0.8. They believed that promoting the release as an important scalability and performance improvement for the network would be easier once the bloom filtering work is complete. Ultraprune and bloom filtering are considered the two major scalability improvements available at the moment. There are still some TODOs left for ultraprune, including auto-migrating old data and UTXO set consistency checks at startup.The author of the message, who is unable to attend meetings on IRC, suggested using email for decision making. They also questioned the need for a process to allocate numbers in the BIP process and suggested removing the editing role. The author expressed a desire for more time to work on bloom filtering before freezing features in version 0.8 of Bitcoin. They believed that promoting the release as important for scalability and performance would help encourage upgrades, with ultraprune and bloom filtering being the two major scalability improvements currently available.Gavin Andresen, a prominent personality in the world of Bitcoin, suggested Thursdays at 18:00 UTC as a suitable time for the core development team to meet and chat on the #bitcoin-dev freenode IRC channel. Pieter responded positively to Gavin's suggestion, indicating agreement with the proposed meeting schedule. The #bitcoin-dev freenode IRC channel will provide an opportunity for members of the core development team to collaborate and discuss issues related to Bitcoin.In a discussion about the success of BIP, Luke-Jr emphasized the importance of encouraging wider community participation. Slush argued that it's not just about the BIP process, but also the content of proposals. He pointed out that he had promised to write a BIP draft for Stratum and implemented get_transactions method to allow Stratum jobs inspection. Luke explained that the BIP process involves more than just writing a document; it also requires peer review and changes to meet the community's needs. The failure of key members of the community to participate in the GBT BIP process was identified as an issue that needs to be addressed to improve the process. While get_transactions is a step in the right direction, it may take time for Stratum to reach the same level as GBT. Luke's comments were not intended to bash Stratum or complain about the past, but to learn from it and figure out how to improve things for the future.In an email exchange on November 6, 2012, Luke-Jr expressed the importance of encouraging wider community participation for the success of BIP. Slush argued that it's not about the BIP process, but rather the content of particular proposals. The discussion then shifted to the topic of stratum mining and its related protocol. Luke-Jr suggested that the mess with stratum mining is a direct result of lack of peer review and contribution toward the stratum protocol. Slush countered that there have been peer reviews of the protocol and that stratum is not related to the Bitcoin protocol or implementation. Slush also expressed frustration with Luke-Jr's constant bashing of stratum in his posts and reminded him that he had promised to write a BIP draft for stratum and had proposed and implemented a get_transactions method for stratum jobs inspection. Slush apologized to other developers who had to read Luke-Jr's negative posts and vowed to try to refrain from responding in the future.Gavin Andresen, a member of the Bitcoin core development team, proposed a meeting every Thursday at 18:00 UTC via the #bitcoin-dev freenode IRC channel to discuss issues related to Bitcoin. The agenda for the meeting included creating a to-do list to get to a 0.8 release candidate, freezing the features, working on testing new features, fixing existing bugs, and evaluating the BIP process. Gavin expressed concerns about the absence of Amir and suggested having a successor in place. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2012/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml b/static/bitcoin-dev/Nov_2012/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml index 272cc579b6..2e89f6c60e 100644 --- a/static/bitcoin-dev/Nov_2012/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml +++ b/static/bitcoin-dev/Nov_2012/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol Proposal: Invoices/Payments/Receipts - 2023-08-01T04:10:51.910113+00:00 + 2025-10-11T21:47:42.508028+00:00 + python-feedgen Vezalke 2014-09-17 19:28:08+00:00 @@ -351,13 +352,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol Proposal: Invoices/Payments/Receipts - 2023-08-01T04:10:51.912154+00:00 + 2025-10-11T21:47:42.508281+00:00 - In a series of discussions on the Bitcoin-development mailing list, various topics related to Bitcoin payment protocols were addressed. One discussion focused on the implementation of a "pass around" method, which was considered simpler and easier to implement for experts in the early stages. Another topic discussed was the launch of Crypto-Games.net, an online gambling platform designed specifically for slot machine betting using cryptocurrencies like Bitcoin, Litecoin, and Dogecoin.The need for a secure and private messaging system as the first step in implementing a payment protocol was emphasized by Stephen Pair. A proposal suggested using signed and authenticated "invoices" and "receipts" with X.509 certificates as an identity system for merchants. The proposal also covered multi-signature wallet scenarios and the use of Protocol Buffers as an encoding format.The debate between binary and text formats in the Bitcoin protocol was addressed, with arguments for both sides. The advantages of JSON for accessibility were acknowledged, but concerns were raised about maintaining field order and complexity. The discussion highlighted the lack of compelling arguments for text formats and the need for further research before making a final decision.Other discussions covered topics such as the migration to textual representation, the use of root CAs in the system, and the challenges of confirming the validity of addresses displayed on computer screens. There were also proposals for extending the protocol, handling payment failures, and ensuring the security of paying invoices with Bitcoin.Ensuring consistency and security in Bitcoin transactions is a top priority for sellers. The use of Certificate Authorities (CAs) plays a crucial role in verifying website or server identities and establishing secure connections. In a discussion on November 26, 2012, Mike Hearn emphasized the need for consistency in Bitcoin transactions and suggested supporting all CAs used by popular browsers. However, he expressed a preference for user-accepted certificates at the operating system level to address potential restrictions. The goal was to establish secure communication between users and servers.The limitations of X.509 for the web were also discussed, particularly regarding delegation and the potential undermining of the benefits of chained certificates. To enhance security for payment processors, the proposal suggests issuing a new certificate specifically for signing Bitcoin transactions. It is recommended to redefine the certificate chain part of the protocol to allow for the introduction of new minimal certificate formats with desired features. Compatibility issues may arise for old clients encountering unfamiliar invoice cert types, so the suggestion is made to include a protocol version number when downloading invoices to ensure safe utilization of new invoice features.In addition to certificate discussions, the Bitcoin development community is considering various new features for the digital currency. This includes switching from JSON to a binary format for more efficient and secure data transfer. Another proposed feature is the ability for merchants to cover transaction processing fees. Three potential methods are suggested for implementing this feature, such as adding a 'maxfee' field to the invoice, altering the transaction selection code used by Bitcoin miners, and signing Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag.Another protocol proposal involves utilizing protocol buffer-based formats for signed, authenticated "invoices" and "receipts." Invoices serve as payment requests from merchants to customers and contain outputs specifying where Bitcoins are to be sent. These invoices must include one or more DER-encoded X.509 certificates identifying the merchant, validated according to [RFC5280]. Authenticated identities are linked to invoices, which also include a description of the payment, refund details, and a cryptographically signed receipt that serves as proof-of-payment during disputes with merchants. Merchants will incorporate this proposal into their checkout process, while customers receive SignedInvoice, authorize payment, and create the Payment message, which is then submitted to the site's payment URI.After the payment transaction is validated and broadcasted, a SignedReceipt is returned, indicating either a "You win" or "You lost" memo. The Bitcoin development community is also exploring the possibility of using the Online Certificate Checking Protocol (OCSP) to check for revoked certificates. However, concerns exist regarding the effectiveness of this approach, as it may introduce delays or false-positive rejections if the OCSP endpoint experiences downtime or becomes overwhelmed.Overall, the discussions revolve around improving security and authentication in Bitcoin invoice payments, exploring different identification types, clarifying terminology, and considering alternative approaches to achieve the desired functionality. The Bitcoin development community is actively seeking feedback from other developers to refine these proposals and ensure the continued growth and security of the digital currency. 2014-09-17T19:28:08+00:00 + In a series of discussions on the Bitcoin-development mailing list, various topics related to Bitcoin payment protocols were addressed. One discussion focused on the implementation of a "pass around" method, which was considered simpler and easier to implement for experts in the early stages. Another topic discussed was the launch of Crypto-Games.net, an online gambling platform designed specifically for slot machine betting using cryptocurrencies like Bitcoin, Litecoin, and Dogecoin.The need for a secure and private messaging system as the first step in implementing a payment protocol was emphasized by Stephen Pair. A proposal suggested using signed and authenticated "invoices" and "receipts" with X.509 certificates as an identity system for merchants. The proposal also covered multi-signature wallet scenarios and the use of Protocol Buffers as an encoding format.The debate between binary and text formats in the Bitcoin protocol was addressed, with arguments for both sides. The advantages of JSON for accessibility were acknowledged, but concerns were raised about maintaining field order and complexity. The discussion highlighted the lack of compelling arguments for text formats and the need for further research before making a final decision.Other discussions covered topics such as the migration to textual representation, the use of root CAs in the system, and the challenges of confirming the validity of addresses displayed on computer screens. There were also proposals for extending the protocol, handling payment failures, and ensuring the security of paying invoices with Bitcoin.Ensuring consistency and security in Bitcoin transactions is a top priority for sellers. The use of Certificate Authorities (CAs) plays a crucial role in verifying website or server identities and establishing secure connections. In a discussion on November 26, 2012, Mike Hearn emphasized the need for consistency in Bitcoin transactions and suggested supporting all CAs used by popular browsers. However, he expressed a preference for user-accepted certificates at the operating system level to address potential restrictions. The goal was to establish secure communication between users and servers.The limitations of X.509 for the web were also discussed, particularly regarding delegation and the potential undermining of the benefits of chained certificates. To enhance security for payment processors, the proposal suggests issuing a new certificate specifically for signing Bitcoin transactions. It is recommended to redefine the certificate chain part of the protocol to allow for the introduction of new minimal certificate formats with desired features. Compatibility issues may arise for old clients encountering unfamiliar invoice cert types, so the suggestion is made to include a protocol version number when downloading invoices to ensure safe utilization of new invoice features.In addition to certificate discussions, the Bitcoin development community is considering various new features for the digital currency. This includes switching from JSON to a binary format for more efficient and secure data transfer. Another proposed feature is the ability for merchants to cover transaction processing fees. Three potential methods are suggested for implementing this feature, such as adding a 'maxfee' field to the invoice, altering the transaction selection code used by Bitcoin miners, and signing Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag.Another protocol proposal involves utilizing protocol buffer-based formats for signed, authenticated "invoices" and "receipts." Invoices serve as payment requests from merchants to customers and contain outputs specifying where Bitcoins are to be sent. These invoices must include one or more DER-encoded X.509 certificates identifying the merchant, validated according to [RFC5280]. Authenticated identities are linked to invoices, which also include a description of the payment, refund details, and a cryptographically signed receipt that serves as proof-of-payment during disputes with merchants. Merchants will incorporate this proposal into their checkout process, while customers receive SignedInvoice, authorize payment, and create the Payment message, which is then submitted to the site's payment URI.After the payment transaction is validated and broadcasted, a SignedReceipt is returned, indicating either a "You win" or "You lost" memo. The Bitcoin development community is also exploring the possibility of using the Online Certificate Checking Protocol (OCSP) to check for revoked certificates. However, concerns exist regarding the effectiveness of this approach, as it may introduce delays or false-positive rejections if the OCSP endpoint experiences downtime or becomes overwhelmed.Overall, the discussions revolve around improving security and authentication in Bitcoin invoice payments, exploring different identification types, clarifying terminology, and considering alternative approaches to achieve the desired functionality. The Bitcoin development community is actively seeking feedback from other developers to refine these proposals and ensure the continued growth and security of the digital currency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_-ANN-High-speed-Bitcoin-Relay-Network.xml b/static/bitcoin-dev/Nov_2013/combined_-ANN-High-speed-Bitcoin-Relay-Network.xml index 457a68c892..79b9417888 100644 --- a/static/bitcoin-dev/Nov_2013/combined_-ANN-High-speed-Bitcoin-Relay-Network.xml +++ b/static/bitcoin-dev/Nov_2013/combined_-ANN-High-speed-Bitcoin-Relay-Network.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [ANN] High-speed Bitcoin Relay Network - 2023-08-01T06:29:55.353699+00:00 + 2025-10-11T21:46:42.929065+00:00 + python-feedgen Matt Corallo 2014-08-03 00:56:54+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - [ANN] High-speed Bitcoin Relay Network - 2023-08-01T06:29:55.353699+00:00 + 2025-10-11T21:46:42.929245+00:00 - To improve the efficiency and speed of relaying Bitcoin data, users can now peer with public relay nodes. These relay nodes are located in different regions such as us-west, us-east, eu, au, or jpy. To connect to a relay node, users need to add "public.REGION.relay.mattcorallo.com" to their addnode list.Each relay node can be connected to either port 8334 or 8335, with the former only relaying blocks and the latter relaying both blocks and transactions. While the relay nodes do perform some data verification to prevent Denial of Service attacks (DoS), they do not fully verify the data they are relaying. Therefore, it is crucial for users to never mine a block based solely on a relayed block without conducting their own thorough verification using a bitcoin validator.The relay nodes do not follow the standard inv-getdata-tx/block flow; instead, they relay transactions and blocks immediately after performing cursory verification. It is important to understand that the relay nodes are not meant to replace the standard P2P network but rather to complement it. They are designed to augment the existing network and should not be relied upon to ensure that users never miss any data. There may be instances where the relay nodes fail to relay certain transactions. Furthermore, if a user disconnects and then reconnects, any missed data will not be sent again by the relay nodes. Therefore, it is still advisable to have peers on the standard P2P network.For important node operators such as merchants, exchanges, and large miners who wish to have access to relay nodes with fewer peers, there is a form available on the website to request additional domain names. The source code for the relay nodes can be found on GitHub, allowing users to review and contribute to their development.Users are encouraged to provide feedback, voice concerns, or make suggestions by emailing bitcoin-peering at mattcorallo.com. This helps in improving the relay node system and addressing any issues that may arise. 2014-08-03T00:56:54+00:00 + To improve the efficiency and speed of relaying Bitcoin data, users can now peer with public relay nodes. These relay nodes are located in different regions such as us-west, us-east, eu, au, or jpy. To connect to a relay node, users need to add "public.REGION.relay.mattcorallo.com" to their addnode list.Each relay node can be connected to either port 8334 or 8335, with the former only relaying blocks and the latter relaying both blocks and transactions. While the relay nodes do perform some data verification to prevent Denial of Service attacks (DoS), they do not fully verify the data they are relaying. Therefore, it is crucial for users to never mine a block based solely on a relayed block without conducting their own thorough verification using a bitcoin validator.The relay nodes do not follow the standard inv-getdata-tx/block flow; instead, they relay transactions and blocks immediately after performing cursory verification. It is important to understand that the relay nodes are not meant to replace the standard P2P network but rather to complement it. They are designed to augment the existing network and should not be relied upon to ensure that users never miss any data. There may be instances where the relay nodes fail to relay certain transactions. Furthermore, if a user disconnects and then reconnects, any missed data will not be sent again by the relay nodes. Therefore, it is still advisable to have peers on the standard P2P network.For important node operators such as merchants, exchanges, and large miners who wish to have access to relay nodes with fewer peers, there is a form available on the website to request additional domain names. The source code for the relay nodes can be found on GitHub, allowing users to review and contribute to their development.Users are encouraged to provide feedback, voice concerns, or make suggestions by emailing bitcoin-peering at mattcorallo.com. This helps in improving the relay node system and addressing any issues that may arise. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_-PATCH-bitcoind-whitelist-nodes-to-prevent-them-from-being-banned.xml b/static/bitcoin-dev/Nov_2013/combined_-PATCH-bitcoind-whitelist-nodes-to-prevent-them-from-being-banned.xml index 0c84ae6a60..d42cc1767d 100644 --- a/static/bitcoin-dev/Nov_2013/combined_-PATCH-bitcoind-whitelist-nodes-to-prevent-them-from-being-banned.xml +++ b/static/bitcoin-dev/Nov_2013/combined_-PATCH-bitcoind-whitelist-nodes-to-prevent-them-from-being-banned.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [PATCH] bitcoind: whitelist nodes, to prevent them from being banned - 2023-08-01T06:42:58.639826+00:00 + 2025-10-11T21:46:57.794741+00:00 + python-feedgen Michael Hendricks 2013-11-22 23:11:00+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [PATCH] bitcoind: whitelist nodes, to prevent them from being banned - 2023-08-01T06:42:58.639826+00:00 + 2025-10-11T21:46:57.794921+00:00 - In 2013, Jeff Garzik, a Bitcoin core developer, submitted a patch for discussion on the Bitcoin-development mailing list. Due to temporary Github access disablement, he chose this avenue to submit the patch. However, another member of the mailing list named Michael noticed that the code in the patch resembled node.js code for a tool called txtool. The purpose of the patch and whether it was accepted and implemented into the Bitcoin codebase remains unclear.Jeff Garzik, aside from being a Bitcoin core developer, also worked for BitPay, Inc., an open-source payment processor for Bitcoin. In the email containing the patch, Garzik included a promotional message for Intel's Software Adrenaline. This promotion offered a free subscription for software experts and developers to stay updated on tech innovation.The patch submitted by Garzik adds functions to the BitcoinRPC.js file, including getRawTransaction, signRawTransaction, and sendRawTransaction. Additionally, a new transaction tool has been introduced, allowing users to load files in hex format, serialize transactions from bitcoind RPC, and execute JSON-RPC commands using the txtool command. Users can run the tool by executing `./txtool -h` and following the provided instructions. 2013-11-22T23:11:00+00:00 + In 2013, Jeff Garzik, a Bitcoin core developer, submitted a patch for discussion on the Bitcoin-development mailing list. Due to temporary Github access disablement, he chose this avenue to submit the patch. However, another member of the mailing list named Michael noticed that the code in the patch resembled node.js code for a tool called txtool. The purpose of the patch and whether it was accepted and implemented into the Bitcoin codebase remains unclear.Jeff Garzik, aside from being a Bitcoin core developer, also worked for BitPay, Inc., an open-source payment processor for Bitcoin. In the email containing the patch, Garzik included a promotional message for Intel's Software Adrenaline. This promotion offered a free subscription for software experts and developers to stay updated on tech innovation.The patch submitted by Garzik adds functions to the BitcoinRPC.js file, including getRawTransaction, signRawTransaction, and sendRawTransaction. Additionally, a new transaction tool has been introduced, allowing users to load files in hex format, serialize transactions from bitcoind RPC, and execute JSON-RPC commands using the txtool command. Users can run the tool by executing `./txtool -h` and following the provided instructions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_-PATCH-try2-bitcoind-whitelist-nodes-against-banning.xml b/static/bitcoin-dev/Nov_2013/combined_-PATCH-try2-bitcoind-whitelist-nodes-against-banning.xml index c52b0d5f81..8f44dc5221 100644 --- a/static/bitcoin-dev/Nov_2013/combined_-PATCH-try2-bitcoind-whitelist-nodes-against-banning.xml +++ b/static/bitcoin-dev/Nov_2013/combined_-PATCH-try2-bitcoind-whitelist-nodes-against-banning.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [PATCH, try2] bitcoind: whitelist nodes against banning - 2023-08-01T06:43:14.413517+00:00 + 2025-10-11T21:46:28.049937+00:00 + python-feedgen Jouke Hofman 2013-11-22 21:37:40+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - [PATCH, try2] bitcoind: whitelist nodes against banning - 2023-08-01T06:43:14.413517+00:00 + 2025-10-11T21:46:28.050096+00:00 - In a November 2013 email, Jeff Garzik proposed the idea of whitelisting nodes as a solution to the issue of frequent bans on the Bitcoin network. The proposal was shared on the Bitcoin-development mailing list hosted by SourceForge. Garzik, a Bitcoin core developer and open-source evangelist affiliated with BitPay, Inc., included a link to Intel(R) Software Adrenaline in the email, which offers free subscriptions to software experts and developers interested in staying updated with tech innovation.The purpose of Garzik's email was to initiate a discussion within the Bitcoin-development community about how to shape the rapidly evolving mobile landscape. A response to Garzik's proposal expressed gratitude for his contribution and promised to test the effectiveness of the suggested patches on some nodes the following day.On Github, there is a pull request for a bannode RPC, although it does not seem to be functional currently. In a discussion between Jeff Garzik and Gregory Maxwell, Maxwell suggested the implementation of a parallel get RPC to obtain the current list of nodes. Garzik agreed that it would be easy to add this feature. Additionally, there were requests for an IP blacklist, which would require associated RPC/config gadgetry.In another email exchange on November 22, 2013, Gregory Maxwell asked Garzik about the absence of a parallel get RPC in Bitcoin Core. Garzik responded that it would be simple to include such functionality. He also mentioned the requests for an IP blacklist, which would involve additional RPC/config gadgetry.In 2013, Jeff Garzik, a Bitcoin core developer and open-source evangelist working for BitPay, Inc., added a whitelist feature to the bitcoin client software. This feature allows for the protection of whitelisted nodes from being banned. The whitelist can be managed through an entry point via RPC, configuration file, or command line. The implementation of the whitelist feature can be found in the net.cpp file of the Bitcoin Core codebase, specifically through the AddWhitelist() function. The IsWhitelisted() function checks whether a given address is potentially local, and LoadWhitelist() loads any addresses specified in the -whitelist parameter. The rpcnet.cpp file contains the addwhite() function, which attempts to add a node to the whitelist. 2013-11-22T21:37:40+00:00 + In a November 2013 email, Jeff Garzik proposed the idea of whitelisting nodes as a solution to the issue of frequent bans on the Bitcoin network. The proposal was shared on the Bitcoin-development mailing list hosted by SourceForge. Garzik, a Bitcoin core developer and open-source evangelist affiliated with BitPay, Inc., included a link to Intel(R) Software Adrenaline in the email, which offers free subscriptions to software experts and developers interested in staying updated with tech innovation.The purpose of Garzik's email was to initiate a discussion within the Bitcoin-development community about how to shape the rapidly evolving mobile landscape. A response to Garzik's proposal expressed gratitude for his contribution and promised to test the effectiveness of the suggested patches on some nodes the following day.On Github, there is a pull request for a bannode RPC, although it does not seem to be functional currently. In a discussion between Jeff Garzik and Gregory Maxwell, Maxwell suggested the implementation of a parallel get RPC to obtain the current list of nodes. Garzik agreed that it would be easy to add this feature. Additionally, there were requests for an IP blacklist, which would require associated RPC/config gadgetry.In another email exchange on November 22, 2013, Gregory Maxwell asked Garzik about the absence of a parallel get RPC in Bitcoin Core. Garzik responded that it would be simple to include such functionality. He also mentioned the requests for an IP blacklist, which would involve additional RPC/config gadgetry.In 2013, Jeff Garzik, a Bitcoin core developer and open-source evangelist working for BitPay, Inc., added a whitelist feature to the bitcoin client software. This feature allows for the protection of whitelisted nodes from being banned. The whitelist can be managed through an entry point via RPC, configuration file, or command line. The implementation of the whitelist feature can be found in the net.cpp file of the Bitcoin Core codebase, specifically through the AddWhitelist() function. The IsWhitelisted() function checks whether a given address is potentially local, and LoadWhitelist() loads any addresses specified in the -whitelist parameter. The rpcnet.cpp file contains the addwhite() function, which attempts to add a node to the whitelist. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml b/static/bitcoin-dev/Nov_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml index 1870328e70..5b19cfe1f5 100644 --- a/static/bitcoin-dev/Nov_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml +++ b/static/bitcoin-dev/Nov_2013/combined_-RFC-Proposal-Base58-encoded-HD-Wallet-master-seed-with-optional-encryption.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption - 2023-08-01T05:20:12.304613+00:00 + 2025-10-11T21:47:10.553187+00:00 + python-feedgen Jean-Paul Kogelman 2013-12-26 11:48:12+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption - 2023-08-01T05:20:12.304613+00:00 + 2025-10-11T21:47:10.553380+00:00 - Jean-Paul Kogelman has updated a proposal on the Bitcointalk forum, making changes to the checksum and adding support for third-party KDF computation. The full proposal can be found at the provided link. The author of the post states that there have been no recent changes to the proposal, which includes expanding the salt, renaming the 'master seed', adding user-selectable KDF parameters, and a creation date field. They compare their proposal to BIP38 and question whether it could replace it.In response to the proposal, Mike Hearn points out that the proposal is not usable for SPV wallets unless it has a birthday. He suggests adding a UNIX time or a uint16 representing "days since birth of this specification" to solve this issue.The context discusses the usability of SPV wallets and the need for a birthday in order for them to function effectively. Without a birthday, scanning the blockchain can be slow and finding a fully indexed copy of the blockchain can be expensive and centralized. The suggestion is to add a UNIX time or a uint16 to address this problem.The document describes a method for encoding and optionally encrypting a Bitcoin HD Wallet master seed. The proposal provides two encoding methodologies in three lengths each, with one being a clear version and the other an encrypted representation. The proposed method uses various functions such as AES256Encrypt, AES256Decrypt, SHA256, RIPEMD160, scrypt, HMAC-SHA512, Base58Check, G, and N. It also includes test vectors and acknowledgements to related BIPs.In a forum discussion, Jean-Paul Kogelman proposes a Base58 encoded HD wallet master seed with optional encryption. Andreas M. Antonopoulos expresses interest in the proposal and calls it necessary and a great approach. Kogelman asks for feedback on the proposal but mentions that it is not yet in shippable form.The proposal by Jean-Paul Kogelman outlines a method for encoding and encrypting a Bitcoin HD Wallet master seed. It provides a compact representation of the master seed, making it easier to handle. A two-factor version allows for safe storage and creation of paper wallets by third parties. The proposal involves various functions and definitions and suggests modifications to BIP0038. Test vectors are provided, and acknowledgements are given to related BIPs and contributors. 2013-12-26T11:48:12+00:00 + Jean-Paul Kogelman has updated a proposal on the Bitcointalk forum, making changes to the checksum and adding support for third-party KDF computation. The full proposal can be found at the provided link. The author of the post states that there have been no recent changes to the proposal, which includes expanding the salt, renaming the 'master seed', adding user-selectable KDF parameters, and a creation date field. They compare their proposal to BIP38 and question whether it could replace it.In response to the proposal, Mike Hearn points out that the proposal is not usable for SPV wallets unless it has a birthday. He suggests adding a UNIX time or a uint16 representing "days since birth of this specification" to solve this issue.The context discusses the usability of SPV wallets and the need for a birthday in order for them to function effectively. Without a birthday, scanning the blockchain can be slow and finding a fully indexed copy of the blockchain can be expensive and centralized. The suggestion is to add a UNIX time or a uint16 to address this problem.The document describes a method for encoding and optionally encrypting a Bitcoin HD Wallet master seed. The proposal provides two encoding methodologies in three lengths each, with one being a clear version and the other an encrypted representation. The proposed method uses various functions such as AES256Encrypt, AES256Decrypt, SHA256, RIPEMD160, scrypt, HMAC-SHA512, Base58Check, G, and N. It also includes test vectors and acknowledgements to related BIPs.In a forum discussion, Jean-Paul Kogelman proposes a Base58 encoded HD wallet master seed with optional encryption. Andreas M. Antonopoulos expresses interest in the proposal and calls it necessary and a great approach. Kogelman asks for feedback on the proposal but mentions that it is not yet in shippable form.The proposal by Jean-Paul Kogelman outlines a method for encoding and encrypting a Bitcoin HD Wallet master seed. It provides a compact representation of the master seed, making it easier to handle. A two-factor version allows for safe storage and creation of paper wallets by third parties. The proposal involves various functions and definitions and suggests modifications to BIP0038. Test vectors are provided, and acknowledgements are given to related BIPs and contributors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_1-Re-On-the-optimal-block-size-and-why-transaction-fees-are-8.xml b/static/bitcoin-dev/Nov_2013/combined_1-Re-On-the-optimal-block-size-and-why-transaction-fees-are-8.xml index 29d965dad1..ff3fa1fa25 100644 --- a/static/bitcoin-dev/Nov_2013/combined_1-Re-On-the-optimal-block-size-and-why-transaction-fees-are-8.xml +++ b/static/bitcoin-dev/Nov_2013/combined_1-Re-On-the-optimal-block-size-and-why-transaction-fees-are-8.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 1. Re: On the optimal block size and why transaction fees are 8 - 2023-08-01T06:31:31.994858+00:00 + 2025-10-11T21:46:40.800549+00:00 + python-feedgen John Dillon 2013-11-13 20:27:52+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - 1. Re: On the optimal block size and why transaction fees are 8 - 2023-08-01T06:31:31.995823+00:00 + 2025-10-11T21:46:40.800706+00:00 - In a communication between Brian Goss and Peter Todd, the topic of propagation time within a mining pool is discussed. Brian questions whether the propagation time from the pool to the miner affects the analysis of Q for a mining pool composed of ASICs connected by 300 baud modems.Peter explains that even now, the propagation time from the pool to the miner is significant, especially for pools that do not pay for stale shares. He also mentions the growing importance of selfish mining and orphans, which could result in the centralization of hashing power's physical location. If there is a 100ms delay to a pool, miners may choose to locate their mining equipment closer to the pool to avoid financial losses. This could potentially lead to pools wanting to be located near each other.Peter suggests that if all Bitcoin mining were concentrated in one place, like Iceland, it would have negative consequences. Addressing Brian's concerns, he assures him that his questions are not ignorant.In an email exchange on the Bitcoin development mailing list from November 2013, Peter Todd responds to a question regarding propagation time within a mining pool. He explains that the likelihood of fork occurrences depends on the amount of hashing power a miner possesses. Peter outlines three potential outcomes: the block propagating without any other miner finding a block, another miner finding a block during propagation resulting in a tie that the original miner either wins or loses, or another miner finding a block before propagation is complete.To further illustrate his point, Peter introduces variables such as t_prop (the time it takes for a block to propagate from a miner to 100% of the hashing power), t_int (the average interval between blocks), and Q (the probability that a miner will find the next block). Using these variables, Peter calculates probabilities for each outcome while considering Q. He defines P_fork(Q) as (t_prop/t_int * (1-Q))(1-Q) = t_prop/t_int * (1-Q)^2.Additionally, Peter recalculates the break-even fee/KB using Q and discovers that larger pools have a significant advantage as they can charge lower fees for transactions and earn more money. He emphasizes that this issue is inherent to Bitcoin's design and regardless of block size or network speed, the current consensus protocol rewards larger mining pools with lower costs per KB for including transactions.Peter argues that an unlimited block size would exacerbate the problem by increasing fixed costs. However, maintaining the block size at 1MB indefinitely does not solve the underlying issue either. He warns that the perverse incentives to publish blocks only to a minority of hashing power would be detrimental to decentralization. 2013-11-13T20:27:52+00:00 + In a communication between Brian Goss and Peter Todd, the topic of propagation time within a mining pool is discussed. Brian questions whether the propagation time from the pool to the miner affects the analysis of Q for a mining pool composed of ASICs connected by 300 baud modems.Peter explains that even now, the propagation time from the pool to the miner is significant, especially for pools that do not pay for stale shares. He also mentions the growing importance of selfish mining and orphans, which could result in the centralization of hashing power's physical location. If there is a 100ms delay to a pool, miners may choose to locate their mining equipment closer to the pool to avoid financial losses. This could potentially lead to pools wanting to be located near each other.Peter suggests that if all Bitcoin mining were concentrated in one place, like Iceland, it would have negative consequences. Addressing Brian's concerns, he assures him that his questions are not ignorant.In an email exchange on the Bitcoin development mailing list from November 2013, Peter Todd responds to a question regarding propagation time within a mining pool. He explains that the likelihood of fork occurrences depends on the amount of hashing power a miner possesses. Peter outlines three potential outcomes: the block propagating without any other miner finding a block, another miner finding a block during propagation resulting in a tie that the original miner either wins or loses, or another miner finding a block before propagation is complete.To further illustrate his point, Peter introduces variables such as t_prop (the time it takes for a block to propagate from a miner to 100% of the hashing power), t_int (the average interval between blocks), and Q (the probability that a miner will find the next block). Using these variables, Peter calculates probabilities for each outcome while considering Q. He defines P_fork(Q) as (t_prop/t_int * (1-Q))(1-Q) = t_prop/t_int * (1-Q)^2.Additionally, Peter recalculates the break-even fee/KB using Q and discovers that larger pools have a significant advantage as they can charge lower fees for transactions and earn more money. He emphasizes that this issue is inherent to Bitcoin's design and regardless of block size or network speed, the current consensus protocol rewards larger mining pools with lower costs per KB for including transactions.Peter argues that an unlimited block size would exacerbate the problem by increasing fixed costs. However, maintaining the block size at 1MB indefinitely does not solve the underlying issue either. He warns that the perverse incentives to publish blocks only to a minority of hashing power would be detrimental to decentralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Auto-generated-miner-backbone.xml b/static/bitcoin-dev/Nov_2013/combined_Auto-generated-miner-backbone.xml index 2e0a53ec44..46d601db56 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Auto-generated-miner-backbone.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Auto-generated-miner-backbone.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Auto-generated miner backbone - 2023-08-01T06:24:53.609788+00:00 + 2025-10-11T21:46:55.670234+00:00 + python-feedgen Gregory Maxwell 2013-11-05 06:37:43+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - Auto-generated miner backbone - 2023-08-01T06:24:53.610788+00:00 + 2025-10-11T21:46:55.670460+00:00 - In various email conversations and discussions, several individuals have explored the concept of selfish mining in Bitcoin and proposed solutions to address the issue. They express concerns about the potential for centralization and the need to improve the security and decentralization of the network.One proposal suggests creating an authenticated miner announced set of nodes to enhance security, but it is acknowledged that this alone is not a complete solution. The importance of improving Bitcoin's security through tighter networks and making it difficult to partition is emphasized. There are debates regarding the idea of building a miner backbone and its potential for centralization. The use of Tor addresses is suggested as a means of authentication and decentralization. It is also mentioned that Google was not involved in the discussion.The conversation delves into the strategies of selfish mining, where a miner keeps newly mined blocks a secret and broadcasts them only after another miner finds a block, in order to orphan the other miner's chain and increase their own revenue. However, it is argued that this strategy may not be profitable in practice due to the need for well-connectedness in all miners. The possibility of de-incentivizing selfish mining by randomizing the order of broadcasts is discussed, along with the use of deterministic pseudo-random mechanisms for choosing between competing chains.The issue of rational motivation of individual miners is addressed, and solutions are proposed to ensure that the majority of miners mine on the non-selfish block. Feedback effects and near-target PoW solutions are suggested as ways to quickly establish consensus and prevent exploitation by selfish miners.Other topics discussed include the vulnerability of blockchain mining, the potential for sybil attacks, and the challenges of estimating hashing power and selecting the majority side. Various proposals and ideas are put forward, but caution is urged in implementing changes to the current system without thorough analysis.Overall, these email conversations highlight the ongoing discussions and efforts to address the issue of selfish mining in Bitcoin, while considering the implications for security, decentralization, and the rational motivations of individual miners.The discussion on Bitcoin development revolves around addressing the issue of selfish miners having an advantage. Peter Todd suggests that miners should mine to extend the block that the majority of hashing power is trying to extend, but current relay rules do not provide this information. He proposes relaying all blocks that meet the PoW target and also relaying block headers that nearly meet the PoW target. This allows miners to estimate the hashing power on each fork and switch if they are not on the majority side, effectively defeating the selfish-miner strategy.Mike Hearn initially proposes using IP addresses of nodes embedded into coinbases to address the miner backbone problem. However, he later realizes that this approach would make the attack described in the paper easier to carry out. Peter Todd suggests two solutions: relaying all blocks that meet the PoW target and relaying block headers that nearly meet the PoW target. Miners should mine to extend the first block they see, but as they receive "near-blocks" that are under the PoW target, they should use them to estimate the hashing power on each fork and switch if it looks like they are not on the majority side. This raises the threshold for a 51% attack back to 51%.Another proposal suggests that when a miner learns of competing branches of the same length, it should propagate all of them and choose which one to mine on uniformly at random. This would remove the advantage of selfish miners who know which chain the other will work on and choose the opposite one. However, this random scheme would only be used in the case of two competing chains, which happens on average every 60 blocks. While this change might result in roughly losing 1% of blocks, it makes it harder for such an attack to happen. The proposal is met with disagreement, as it fundamentally changes the dynamics of how Bitcoin works and does not address the sybil attack issue.In an email conversation, Peter Todd proposes a mechanism for wallets to get non-sybilled peers, discouraging pools from only connecting to other pools and preventing centralization. The proposal suggests using a standard in the coinbase that commits to extra data appended to the block message and stored temporarily in the block database. This semi-transient data would not be part of the chain but could be extended as needed with new "getextra" messages allowing nodes to query for it. The proposed hash for this data can be short since it doesn't have to survive brute force attacks longer than the validity period of the transient data.Another email exchange discusses an alternative protocol change suggested by Mike Hearn in response to the miner backbone paper. He proposes building a miner backbone by embedding IP addresses of nodes into coinbases, allowing automatic connection to IPs from recent blocks. This would link all major pools together without administration overhead. Hearn believes that this mechanism would also allow wallets to get non-sybilled peers. He argues that his proposal has an easier impact to reason about than a fundamental rule change like the one proposed in the paper.In summary 2013-11-05T06:37:43+00:00 + In various email conversations and discussions, several individuals have explored the concept of selfish mining in Bitcoin and proposed solutions to address the issue. They express concerns about the potential for centralization and the need to improve the security and decentralization of the network.One proposal suggests creating an authenticated miner announced set of nodes to enhance security, but it is acknowledged that this alone is not a complete solution. The importance of improving Bitcoin's security through tighter networks and making it difficult to partition is emphasized. There are debates regarding the idea of building a miner backbone and its potential for centralization. The use of Tor addresses is suggested as a means of authentication and decentralization. It is also mentioned that Google was not involved in the discussion.The conversation delves into the strategies of selfish mining, where a miner keeps newly mined blocks a secret and broadcasts them only after another miner finds a block, in order to orphan the other miner's chain and increase their own revenue. However, it is argued that this strategy may not be profitable in practice due to the need for well-connectedness in all miners. The possibility of de-incentivizing selfish mining by randomizing the order of broadcasts is discussed, along with the use of deterministic pseudo-random mechanisms for choosing between competing chains.The issue of rational motivation of individual miners is addressed, and solutions are proposed to ensure that the majority of miners mine on the non-selfish block. Feedback effects and near-target PoW solutions are suggested as ways to quickly establish consensus and prevent exploitation by selfish miners.Other topics discussed include the vulnerability of blockchain mining, the potential for sybil attacks, and the challenges of estimating hashing power and selecting the majority side. Various proposals and ideas are put forward, but caution is urged in implementing changes to the current system without thorough analysis.Overall, these email conversations highlight the ongoing discussions and efforts to address the issue of selfish mining in Bitcoin, while considering the implications for security, decentralization, and the rational motivations of individual miners.The discussion on Bitcoin development revolves around addressing the issue of selfish miners having an advantage. Peter Todd suggests that miners should mine to extend the block that the majority of hashing power is trying to extend, but current relay rules do not provide this information. He proposes relaying all blocks that meet the PoW target and also relaying block headers that nearly meet the PoW target. This allows miners to estimate the hashing power on each fork and switch if they are not on the majority side, effectively defeating the selfish-miner strategy.Mike Hearn initially proposes using IP addresses of nodes embedded into coinbases to address the miner backbone problem. However, he later realizes that this approach would make the attack described in the paper easier to carry out. Peter Todd suggests two solutions: relaying all blocks that meet the PoW target and relaying block headers that nearly meet the PoW target. Miners should mine to extend the first block they see, but as they receive "near-blocks" that are under the PoW target, they should use them to estimate the hashing power on each fork and switch if it looks like they are not on the majority side. This raises the threshold for a 51% attack back to 51%.Another proposal suggests that when a miner learns of competing branches of the same length, it should propagate all of them and choose which one to mine on uniformly at random. This would remove the advantage of selfish miners who know which chain the other will work on and choose the opposite one. However, this random scheme would only be used in the case of two competing chains, which happens on average every 60 blocks. While this change might result in roughly losing 1% of blocks, it makes it harder for such an attack to happen. The proposal is met with disagreement, as it fundamentally changes the dynamics of how Bitcoin works and does not address the sybil attack issue.In an email conversation, Peter Todd proposes a mechanism for wallets to get non-sybilled peers, discouraging pools from only connecting to other pools and preventing centralization. The proposal suggests using a standard in the coinbase that commits to extra data appended to the block message and stored temporarily in the block database. This semi-transient data would not be part of the chain but could be extended as needed with new "getextra" messages allowing nodes to query for it. The proposed hash for this data can be short since it doesn't have to survive brute force attacks longer than the validity period of the transient data.Another email exchange discusses an alternative protocol change suggested by Mike Hearn in response to the miner backbone paper. He proposes building a miner backbone by embedding IP addresses of nodes into coinbases, allowing automatic connection to IPs from recent blocks. This would link all major pools together without administration overhead. Hearn believes that this mechanism would also allow wallets to get non-sybilled peers. He argues that his proposal has an easier impact to reason about than a fundamental rule change like the one proposed in the paper.In summary - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_BIP-38.xml b/static/bitcoin-dev/Nov_2013/combined_BIP-38.xml index 5c33bc0e2e..d344a5dd37 100644 --- a/static/bitcoin-dev/Nov_2013/combined_BIP-38.xml +++ b/static/bitcoin-dev/Nov_2013/combined_BIP-38.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 38 - 2023-08-01T06:17:51.280494+00:00 + 2025-10-11T21:46:34.422306+00:00 + python-feedgen Wladimir 2013-11-08 15:41:00+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP 38 - 2023-08-01T06:17:51.280494+00:00 + 2025-10-11T21:46:34.422478+00:00 - In an email exchange, Wladimir raises concerns about the implementation of BIP 0038 in Python. He highlights the lack of clarity regarding the use of flag 0x04 and suggests that it be clarified. Wladimir also points out an error in the encryption process mentioned in the BIP. He notes that the process incorrectly states to split the result into two 16-byte halves instead of two 32-byte halves.Gregory responds to Mike's email regarding a recent change to BIP 0038. Gregory informs Mike that there have been no prior messages about his proposal on the list and no mention of the assignment had been made in the wiki. Gregory had assumed that something similar to what happened with BIP 22 had occurred. He also criticizes the idea of having a wallet with only a single address and mentions Jean-Paul Kogelman's draft proposal, which is based on Caldwell's BIP38 work but with a different encoding scheme that was revised in response to public discussion. Gregory suggests combining efforts to move forward.Mike Caldwell, the proposer of BIP 38, requests that the identity of his original proposal be maintained. He acknowledges that Kogelman's improvements to his proposal may be sufficient to supersede what he originally proposed. However, he wants BIP 38 to still be recognized as an existing proposal to avoid confusion for those who have already chosen to use it. Caldwell also expresses his desire to address some shortcomings in another iteration of BIP 38, including outsourcing computationally expensive steps to minimize user risks, incorporating special-purpose "encrypted minikeys," and implementing a typo check with better privacy.Gregory clarifies to Caldwell that prior messages about his proposal never made it to the list and no mention of the assignment had been made in the wiki. Gregory had assumed that Caldwell had created the BIP document without public discussion, similar to his previous actions with BIP 22. Gregory moved the document out after a complaint about bitcoin-qt not confirming with BIP38, but later moved it back when Caldwell informed him that it had been assigned/announced. Gregory believes that having a wallet that only supports a single address is poor form and suggests collaborating with Jean-Paul Kogelman's draft proposal, which is based on Caldwell's BIP38 work but has a different encoding scheme revised in response to public discussion.The author of BIP 0038 seeks help to confirm a recent change made on the Wiki regarding their proposal. They state that the number was assigned in November 2012 but the change suggests otherwise. The author expresses concern that their messages may not be reaching the list and requests assistance in pushing forward the proposal. BIP 0038 enables the creation of password-protected private keys and is already being implemented by various entities such as BitAddress.org, Bit2Factor.org, and Mycelium. The author emphasizes that reassigning the number after it has been established for nearly a year would be confusing, particularly on procedural grounds. 2013-11-08T15:41:00+00:00 + In an email exchange, Wladimir raises concerns about the implementation of BIP 0038 in Python. He highlights the lack of clarity regarding the use of flag 0x04 and suggests that it be clarified. Wladimir also points out an error in the encryption process mentioned in the BIP. He notes that the process incorrectly states to split the result into two 16-byte halves instead of two 32-byte halves.Gregory responds to Mike's email regarding a recent change to BIP 0038. Gregory informs Mike that there have been no prior messages about his proposal on the list and no mention of the assignment had been made in the wiki. Gregory had assumed that something similar to what happened with BIP 22 had occurred. He also criticizes the idea of having a wallet with only a single address and mentions Jean-Paul Kogelman's draft proposal, which is based on Caldwell's BIP38 work but with a different encoding scheme that was revised in response to public discussion. Gregory suggests combining efforts to move forward.Mike Caldwell, the proposer of BIP 38, requests that the identity of his original proposal be maintained. He acknowledges that Kogelman's improvements to his proposal may be sufficient to supersede what he originally proposed. However, he wants BIP 38 to still be recognized as an existing proposal to avoid confusion for those who have already chosen to use it. Caldwell also expresses his desire to address some shortcomings in another iteration of BIP 38, including outsourcing computationally expensive steps to minimize user risks, incorporating special-purpose "encrypted minikeys," and implementing a typo check with better privacy.Gregory clarifies to Caldwell that prior messages about his proposal never made it to the list and no mention of the assignment had been made in the wiki. Gregory had assumed that Caldwell had created the BIP document without public discussion, similar to his previous actions with BIP 22. Gregory moved the document out after a complaint about bitcoin-qt not confirming with BIP38, but later moved it back when Caldwell informed him that it had been assigned/announced. Gregory believes that having a wallet that only supports a single address is poor form and suggests collaborating with Jean-Paul Kogelman's draft proposal, which is based on Caldwell's BIP38 work but has a different encoding scheme revised in response to public discussion.The author of BIP 0038 seeks help to confirm a recent change made on the Wiki regarding their proposal. They state that the number was assigned in November 2012 but the change suggests otherwise. The author expresses concern that their messages may not be reaching the list and requests assistance in pushing forward the proposal. BIP 0038 enables the creation of password-protected private keys and is already being implemented by various entities such as BitAddress.org, Bit2Factor.org, and Mycelium. The author emphasizes that reassigning the number after it has been established for nearly a year would be confusing, particularly on procedural grounds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_BIP-proposal-patch-to-raise-selfish-mining-threshold-.xml b/static/bitcoin-dev/Nov_2013/combined_BIP-proposal-patch-to-raise-selfish-mining-threshold-.xml index 372209e859..c25eae8826 100644 --- a/static/bitcoin-dev/Nov_2013/combined_BIP-proposal-patch-to-raise-selfish-mining-threshold-.xml +++ b/static/bitcoin-dev/Nov_2013/combined_BIP-proposal-patch-to-raise-selfish-mining-threshold-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP proposal - patch to raise selfish mining threshold. - 2023-08-01T06:26:15.412015+00:00 + 2025-10-11T21:46:59.919735+00:00 + python-feedgen Ittay 2013-11-05 22:49:26+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - BIP proposal - patch to raise selfish mining threshold. - 2023-08-01T06:26:15.413010+00:00 + 2025-10-11T21:46:59.919902+00:00 - The email conversations among various individuals highlight different aspects of the Bitcoin protocol and the need for careful consideration when proposing changes or fixes. Gregory Maxwell pointed out a vulnerability in a proposed solution where larger pools could withhold blocks, potentially benefiting attackers. Peter Todd suggested analyzing a deterministic switching scheme as an alternative. Alessandro Parisi expressed concern about bugs in the protocol and the need for immediate action, but Jeff Garzik emphasized the complexity of Bitcoin and the importance of thorough research and testing before making changes. The risks of a 51% attack and selfish mining were also discussed, with different perspectives on potential solutions.In response to concerns about potential harm to miners, a proposal has been made to gradually raise the threshold for adoption until it reaches 25% with universal acceptance. This approach aims to address concerns while maintaining complete backward compatibility. By increasing the threshold gradually, all miners have the opportunity to adopt the change at their own pace, minimizing disruption. The proposal also emphasizes the importance of not introducing new vulnerabilities and maintaining the system's integrity and security.Throughout the proposal, the focus remains on achieving complete backward compatibility. This ensures that the changes made do not compromise the existing functionality and compatibility of the system. By prioritizing backward compatibility, the proposal aims to provide a seamless transition for all stakeholders involved.Overall, the proposed approach addresses concerns around potential harm to miners, the introduction of new vulnerabilities, and complete backward compatibility. The gradual adoption of the change aims to achieve widespread acceptance while minimizing any negative impacts on miners. 2013-11-05T22:49:26+00:00 + The email conversations among various individuals highlight different aspects of the Bitcoin protocol and the need for careful consideration when proposing changes or fixes. Gregory Maxwell pointed out a vulnerability in a proposed solution where larger pools could withhold blocks, potentially benefiting attackers. Peter Todd suggested analyzing a deterministic switching scheme as an alternative. Alessandro Parisi expressed concern about bugs in the protocol and the need for immediate action, but Jeff Garzik emphasized the complexity of Bitcoin and the importance of thorough research and testing before making changes. The risks of a 51% attack and selfish mining were also discussed, with different perspectives on potential solutions.In response to concerns about potential harm to miners, a proposal has been made to gradually raise the threshold for adoption until it reaches 25% with universal acceptance. This approach aims to address concerns while maintaining complete backward compatibility. By increasing the threshold gradually, all miners have the opportunity to adopt the change at their own pace, minimizing disruption. The proposal also emphasizes the importance of not introducing new vulnerabilities and maintaining the system's integrity and security.Throughout the proposal, the focus remains on achieving complete backward compatibility. This ensures that the changes made do not compromise the existing functionality and compatibility of the system. By prioritizing backward compatibility, the proposal aims to provide a seamless transition for all stakeholders involved.Overall, the proposed approach addresses concerns around potential harm to miners, the introduction of new vulnerabilities, and complete backward compatibility. The gradual adoption of the change aims to achieve widespread acceptance while minimizing any negative impacts on miners. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_BIP39-word-list.xml b/static/bitcoin-dev/Nov_2013/combined_BIP39-word-list.xml index d8674887da..35767b67e8 100644 --- a/static/bitcoin-dev/Nov_2013/combined_BIP39-word-list.xml +++ b/static/bitcoin-dev/Nov_2013/combined_BIP39-word-list.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP39 word list - 2023-08-01T05:59:26.971146+00:00 + 2025-10-11T21:46:53.546507+00:00 + python-feedgen Brooks Boyd 2013-11-02 04:31:33+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP39 word list - 2023-08-01T05:59:26.971146+00:00 + 2025-10-11T21:46:53.546658+00:00 - A proposal has been made to modify the BIP39 wordlist by including alternate options for words that are very similar to each other. This would allow translation programs to assist users in fixing input errors. Marek suggests a simpler solution, using a mapping of similar characters to find combinations that appear in the wordlist when a user types a word not in the list. An updated wordlist has been pushed, filtered to similar characters, and is open for review and comments. The discussion aims to find a clear standard for translating binary to words and avoid confusion. Gregory Maxwell shared a link to a search utility for finding similar words, while Pavol Rusnak emphasizes the need for pull requests with specific changesets. The email thread also includes code for a wordlist solver and mentions avoiding words that could be confusing when written down. 2013-11-02T04:31:33+00:00 + A proposal has been made to modify the BIP39 wordlist by including alternate options for words that are very similar to each other. This would allow translation programs to assist users in fixing input errors. Marek suggests a simpler solution, using a mapping of similar characters to find combinations that appear in the wordlist when a user types a word not in the list. An updated wordlist has been pushed, filtered to similar characters, and is open for review and comments. The discussion aims to find a clear standard for translating binary to words and avoid confusion. Gregory Maxwell shared a link to a search utility for finding similar words, while Pavol Rusnak emphasizes the need for pull requests with specific changesets. The email thread also includes code for a wordlist solver and mentions avoiding words that could be confusing when written down. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Bitcoin-Network-Simulator.xml b/static/bitcoin-dev/Nov_2013/combined_Bitcoin-Network-Simulator.xml index fb232ea761..7e8126fe11 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Bitcoin-Network-Simulator.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Bitcoin-Network-Simulator.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Network Simulator - 2023-08-01T06:42:24.332121+00:00 + 2025-10-11T21:46:32.298994+00:00 + python-feedgen Christophe Biocca 2013-11-18 03:59:04+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Network Simulator - 2023-08-01T06:42:24.332121+00:00 + 2025-10-11T21:46:32.299157+00:00 - Rafael Brune has developed a Bitcoin network simulator that functions as a stochastic event-based continuous-time simulation. This simulator focuses on the exchange of messages and the construction of block chains among miners. It includes two examples, one showcasing a 51% attack and the other demonstrating selfish mining. The simulator accurately represents latency, bandwidth, and verification speed. However, it currently does not simulate propagation or inclusion of transactions, instead relying on random block sizes.Another developer has also created a Bitcoin network simulator with similar principles, aiming to closely follow the protocol message structure. The ultimate objective is to create a network/chain visualization that operates smoothly in the browser. To ensure responsiveness, the simulation itself runs on a WebWorker. This second simulator encompasses a network of 1000 full nodes, including 100 miners, for a simulated duration of one week. Empty blocks, with the exception of the coinbase transaction, are generated within a timeframe of approximately 30-60 seconds using nodejs.The second simulator also integrates theoretical support for transaction propagation. This allows for testing of zero-conf functionality and its effectiveness. By utilizing this simulator, users can assess whether zero-conf capabilities function properly. Rafael Brune encourages others to explore his project and contribute to its enhancement. The Bitcoin network simulator he has developed can be accessed on his Github page. 2013-11-18T03:59:04+00:00 + Rafael Brune has developed a Bitcoin network simulator that functions as a stochastic event-based continuous-time simulation. This simulator focuses on the exchange of messages and the construction of block chains among miners. It includes two examples, one showcasing a 51% attack and the other demonstrating selfish mining. The simulator accurately represents latency, bandwidth, and verification speed. However, it currently does not simulate propagation or inclusion of transactions, instead relying on random block sizes.Another developer has also created a Bitcoin network simulator with similar principles, aiming to closely follow the protocol message structure. The ultimate objective is to create a network/chain visualization that operates smoothly in the browser. To ensure responsiveness, the simulation itself runs on a WebWorker. This second simulator encompasses a network of 1000 full nodes, including 100 miners, for a simulated duration of one week. Empty blocks, with the exception of the coinbase transaction, are generated within a timeframe of approximately 30-60 seconds using nodejs.The second simulator also integrates theoretical support for transaction propagation. This allows for testing of zero-conf functionality and its effectiveness. By utilizing this simulator, users can assess whether zero-conf capabilities function properly. Rafael Brune encourages others to explore his project and contribute to its enhancement. The Bitcoin network simulator he has developed can be accessed on his Github page. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Committing-to-extra-block-data-a-better-merge-mine-standard.xml b/static/bitcoin-dev/Nov_2013/combined_Committing-to-extra-block-data-a-better-merge-mine-standard.xml index b4ec5c3873..992abb020a 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Committing-to-extra-block-data-a-better-merge-mine-standard.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Committing-to-extra-block-data-a-better-merge-mine-standard.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Committing to extra block data/a better merge-mine standard - 2023-08-01T06:25:31.085024+00:00 + 2025-10-11T21:46:30.172686+00:00 + python-feedgen Peter Todd 2013-11-15 22:06:48+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Committing to extra block data/a better merge-mine standard - 2023-08-01T06:25:31.086024+00:00 + 2025-10-11T21:46:30.172864+00:00 - In an email conversation, Mark Friedenbach proposed using per-purpose UUIDs to validate data committed to a jagged tree structure. The UUID bits are interpreted as allowed paths (0 = left, 1 = right) from the top of the tree. When building the tree, everything that is going to be committed must use its allowed path. This ensures that the paths won't collide for very many levels on average, and path lengths will remain short. Validating that some given data was committed properly is simple and easy: just check the path and ensure that the directions from the top of the tree followed the spec.Peter Todd suggested using a hash256-to-UUID mechanism explicitly for this purpose. He also mentioned that any large randomly picked integer is fine. He further suggests running the idea past forrestv, as p2pool would need to adopt the standard and there have been some oddness with mining hardware and nonces that would be good to understand.The discussion also revolves around the issue of transiently relayed data, specifically IP addresses. Hearn believes that additional complexity in storing the 256-bit root hash truncated to less in the coinbase output may not be worth it. However, Friedenbach argues that it makes a difference when merged mining, as it allows for double-counting the bitcoin PoW for more than one aux block on the same chain, potentially facilitating aux chain attacks. For merged mined aux chains to have 128 bits of security, 256 bits of hash in the coinbase are required.The idea of using UUID-as-path is appreciated for resolving the problem of sharing alt-chain merkle tree. It is suggested to make the Merkle branch a full 256 bits for proving extra data validity. However, the coinbase hash does not get stored indefinitely, so it is suggested that the data stored in the coinbase output can always be the 256-bit root hash truncated to less. Although the additional bytes may not make much difference, the idea of adding complexity to achieve better results is not entirely dismissed.In the email exchange, Todd proposes defining a standard for using the last txout so midstate compression can be applied in the future. The proposed standard involves generating a random 128-bit UUID for each thing one might want to commit, such as a merge-mined coin, a p2pool share, or a UTXO commitment. The bits of the UUID are then interpreted as an allowed path from the top of the tree. When building the tree, everything that is going to be committed uses its allowed path, resulting in a jagged tree. Validating the data is simple: just check the path and ensure that the directions from the top of the tree followed the spec.Friedenbach responds by suggesting an authenticated prefix tree with level compression, which allows for smaller path validation, traversal, and proof size. He had previously suggested using a hash256-to-UUID mechanism but is now leaning towards simply using the hash of the genesis block directly to identify aux chains. This is because level compression will allow longer keys with the same path length. Mark also mentions that he's in the middle of writing BIPs on this topic among his other tasks. Essentially, Mark's proposal is similar to Todd's, except keys don't necessarily have to be UUIDs. He offers to prioritize finishing this if there is general interest.Todd suggests setting a reasonable limit on actual path lengths and advises making allowed paths block specific by defining them as H(uuid | nonce), with nonce as an option. This could be H(uuid | nLockTime) where Coinbase transactions still have a nLockTime. The message includes contact information for Todd and a digital signature.Hearn suggests a solution to define a short hash in the coinbase that commits to extra data relayed along with block data. This can be stored temporarily in the block database and erased after some time. He also emphasizes the importance of defining a standard for using the last txout, allowing for midstate compression in the future. The proposed method involves generating a random 128-bit UUID for each thing one might want to commit, interpreting the bits of the UUID as an allowed path from the top of the tree, and ensuring that everything being committed uses its allowed path. Unlike the original merge-mining standard, this approach works for alt-coins, extends indefinitely, and is simple and easy to validate given a single merkle-path for each purpose.The email thread ends with a link to a white paper on secure code signing practices for Android apps. 2013-11-15T22:06:48+00:00 + In an email conversation, Mark Friedenbach proposed using per-purpose UUIDs to validate data committed to a jagged tree structure. The UUID bits are interpreted as allowed paths (0 = left, 1 = right) from the top of the tree. When building the tree, everything that is going to be committed must use its allowed path. This ensures that the paths won't collide for very many levels on average, and path lengths will remain short. Validating that some given data was committed properly is simple and easy: just check the path and ensure that the directions from the top of the tree followed the spec.Peter Todd suggested using a hash256-to-UUID mechanism explicitly for this purpose. He also mentioned that any large randomly picked integer is fine. He further suggests running the idea past forrestv, as p2pool would need to adopt the standard and there have been some oddness with mining hardware and nonces that would be good to understand.The discussion also revolves around the issue of transiently relayed data, specifically IP addresses. Hearn believes that additional complexity in storing the 256-bit root hash truncated to less in the coinbase output may not be worth it. However, Friedenbach argues that it makes a difference when merged mining, as it allows for double-counting the bitcoin PoW for more than one aux block on the same chain, potentially facilitating aux chain attacks. For merged mined aux chains to have 128 bits of security, 256 bits of hash in the coinbase are required.The idea of using UUID-as-path is appreciated for resolving the problem of sharing alt-chain merkle tree. It is suggested to make the Merkle branch a full 256 bits for proving extra data validity. However, the coinbase hash does not get stored indefinitely, so it is suggested that the data stored in the coinbase output can always be the 256-bit root hash truncated to less. Although the additional bytes may not make much difference, the idea of adding complexity to achieve better results is not entirely dismissed.In the email exchange, Todd proposes defining a standard for using the last txout so midstate compression can be applied in the future. The proposed standard involves generating a random 128-bit UUID for each thing one might want to commit, such as a merge-mined coin, a p2pool share, or a UTXO commitment. The bits of the UUID are then interpreted as an allowed path from the top of the tree. When building the tree, everything that is going to be committed uses its allowed path, resulting in a jagged tree. Validating the data is simple: just check the path and ensure that the directions from the top of the tree followed the spec.Friedenbach responds by suggesting an authenticated prefix tree with level compression, which allows for smaller path validation, traversal, and proof size. He had previously suggested using a hash256-to-UUID mechanism but is now leaning towards simply using the hash of the genesis block directly to identify aux chains. This is because level compression will allow longer keys with the same path length. Mark also mentions that he's in the middle of writing BIPs on this topic among his other tasks. Essentially, Mark's proposal is similar to Todd's, except keys don't necessarily have to be UUIDs. He offers to prioritize finishing this if there is general interest.Todd suggests setting a reasonable limit on actual path lengths and advises making allowed paths block specific by defining them as H(uuid | nonce), with nonce as an option. This could be H(uuid | nLockTime) where Coinbase transactions still have a nLockTime. The message includes contact information for Todd and a digital signature.Hearn suggests a solution to define a short hash in the coinbase that commits to extra data relayed along with block data. This can be stored temporarily in the block database and erased after some time. He also emphasizes the importance of defining a standard for using the last txout, allowing for midstate compression in the future. The proposed method involves generating a random 128-bit UUID for each thing one might want to commit, interpreting the bits of the UUID as an allowed path from the top of the tree, and ensuring that everything being committed uses its allowed path. Unlike the original merge-mining standard, this approach works for alt-coins, extends indefinitely, and is simple and easy to validate given a single merkle-path for each purpose.The email thread ends with a link to a white paper on secure code signing practices for Android apps. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Even-simpler-minimum-fee-calculation-formula-f-bounty-fork-rate-average-blocksize.xml b/static/bitcoin-dev/Nov_2013/combined_Even-simpler-minimum-fee-calculation-formula-f-bounty-fork-rate-average-blocksize.xml index 45606bddcb..fcd1bd2eb4 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Even-simpler-minimum-fee-calculation-formula-f-bounty-fork-rate-average-blocksize.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Even-simpler-minimum-fee-calculation-formula-f-bounty-fork-rate-average-blocksize.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize - 2023-08-01T06:32:56.391720+00:00 + 2025-10-11T21:46:25.926205+00:00 + python-feedgen Peter Todd 2013-11-20 10:01:08+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize - 2023-08-01T06:32:56.391720+00:00 + 2025-10-11T21:46:25.926394+00:00 - In an email exchange on November 15th, 2013, Peter Todd and Michael Gronager discussed the speed of Bitcoin in terms of alpha. Todd calculated alpha to be 39.62 microseconds per byte or 24 kilobytes per second, which he considered to be inefficient. Gronager then calculated alpha to be 29 milliseconds per kilobyte using a different formula. They debated where Gronager got the number 454,000 from, and Gronager explained that he used the actual block interval instead of the steady state one. The conversation ended with Todd's signature.The primary focus of the conversation was the efficiency of block propagation in Bitcoin. Todd and Gronager calculated the alpha value for Bitcoin to be 24kB/s for block propagation, which they deemed inefficient. Gronager suggested that optimizing profits could be achieved by using high-bandwidth nodes with restricted numbers of peers, as mining pulls in $1.8 million per day and not optimizing profits results in a loss of up to $16k. However, smaller miners bear this loss disproportionately. They also discussed the advantages of P2Pool in block propagation efficiency but acknowledged the challenges in growing P2Pool due to the requirement of running a full node.Another topic of discussion was the economics of mining pools in Bitcoin. Gronager argued that participating in a pool can be advantageous due to economies of scale, despite miners having to pay a fraction of their income to the pool owner. Todd agreed that there is an incentive for miners to join pools and centralize, but regulation or social pressure could counter this. They delved into equations and models to analyze the profitability of mining in pools versus mining solo, considering factors like hashing power and block size.The email thread also covered topics such as transaction fees, orphaned blocks, and the impact of mining centralization. They discussed the minimum fee for Bitcoin transactions, the relationship between block size and latency, and the potential implications of relaying all orphaned blocks. They highlighted the need for an optimal tx inclusion policy in P2Pool and emphasized the importance of network and node latency in the scalability of Bitcoin.In summary, the email exchange provided insights into various aspects of Bitcoin mining, including block propagation efficiency, the economics of mining pools, and the implications of mining centralization. The conversation involved calculations, equations, and analyses to understand the dynamics of the cryptocurrency ecosystem.Blockchain.info's sybil attack on the network revealed that the average fee for bitcoin transactions over the last 90 days is approximately 0.0003BTC/txn, close to the theoretical minimum of 0.00037BTC/txn. However, this may be due to old clients and fee settings rather than network wisdom. Gronager conducted calculations using different pool sizes and found that the measured fork rate can estimate the minimum fee. He determined alpha as a function of the average fork rate and average block size, which yielded a minimum fee formula of f > P_fork*E_bounty/S_average. By analyzing historical data from blockchain.info, Gronager determined that the minimum fee should be f > 0.00165XBT/kb or 0.00037XBT/txn based on the average number of orphaned blocks per day and the average block size over the past year. Looking at the trend over the last 12 months, Gronager found that considering only the last 90 days, the minimum fee would be f > 0.00162XBT/kb or 0.00037XBT/txn. He also noted that a 4 times increase in block size would still be sufficient for the current load based on the optimal revenue block size being a function of the transaction fee. The key factor in determining fees is alpha, which represents network latency and depends on interconnectivity, bandwidths, and software quality. The email exchange concluded with the understanding that software quality improvements could bring down fees, as standard clients can be configured to choose a better fee based on easily measured parameters. 2013-11-20T10:01:08+00:00 + In an email exchange on November 15th, 2013, Peter Todd and Michael Gronager discussed the speed of Bitcoin in terms of alpha. Todd calculated alpha to be 39.62 microseconds per byte or 24 kilobytes per second, which he considered to be inefficient. Gronager then calculated alpha to be 29 milliseconds per kilobyte using a different formula. They debated where Gronager got the number 454,000 from, and Gronager explained that he used the actual block interval instead of the steady state one. The conversation ended with Todd's signature.The primary focus of the conversation was the efficiency of block propagation in Bitcoin. Todd and Gronager calculated the alpha value for Bitcoin to be 24kB/s for block propagation, which they deemed inefficient. Gronager suggested that optimizing profits could be achieved by using high-bandwidth nodes with restricted numbers of peers, as mining pulls in $1.8 million per day and not optimizing profits results in a loss of up to $16k. However, smaller miners bear this loss disproportionately. They also discussed the advantages of P2Pool in block propagation efficiency but acknowledged the challenges in growing P2Pool due to the requirement of running a full node.Another topic of discussion was the economics of mining pools in Bitcoin. Gronager argued that participating in a pool can be advantageous due to economies of scale, despite miners having to pay a fraction of their income to the pool owner. Todd agreed that there is an incentive for miners to join pools and centralize, but regulation or social pressure could counter this. They delved into equations and models to analyze the profitability of mining in pools versus mining solo, considering factors like hashing power and block size.The email thread also covered topics such as transaction fees, orphaned blocks, and the impact of mining centralization. They discussed the minimum fee for Bitcoin transactions, the relationship between block size and latency, and the potential implications of relaying all orphaned blocks. They highlighted the need for an optimal tx inclusion policy in P2Pool and emphasized the importance of network and node latency in the scalability of Bitcoin.In summary, the email exchange provided insights into various aspects of Bitcoin mining, including block propagation efficiency, the economics of mining pools, and the implications of mining centralization. The conversation involved calculations, equations, and analyses to understand the dynamics of the cryptocurrency ecosystem.Blockchain.info's sybil attack on the network revealed that the average fee for bitcoin transactions over the last 90 days is approximately 0.0003BTC/txn, close to the theoretical minimum of 0.00037BTC/txn. However, this may be due to old clients and fee settings rather than network wisdom. Gronager conducted calculations using different pool sizes and found that the measured fork rate can estimate the minimum fee. He determined alpha as a function of the average fork rate and average block size, which yielded a minimum fee formula of f > P_fork*E_bounty/S_average. By analyzing historical data from blockchain.info, Gronager determined that the minimum fee should be f > 0.00165XBT/kb or 0.00037XBT/txn based on the average number of orphaned blocks per day and the average block size over the past year. Looking at the trend over the last 12 months, Gronager found that considering only the last 90 days, the minimum fee would be f > 0.00162XBT/kb or 0.00037XBT/txn. He also noted that a 4 times increase in block size would still be sufficient for the current load based on the optimal revenue block size being a function of the transaction fee. The key factor in determining fees is alpha, which represents network latency and depends on interconnectivity, bandwidths, and software quality. The email exchange concluded with the understanding that software quality improvements could bring down fees, as standard clients can be configured to choose a better fee based on easily measured parameters. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Extending-the-Payment-Protocol-with-vCards.xml b/static/bitcoin-dev/Nov_2013/combined_Extending-the-Payment-Protocol-with-vCards.xml index 5142775f2b..3c5bd24bad 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Extending-the-Payment-Protocol-with-vCards.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Extending-the-Payment-Protocol-with-vCards.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Extending the Payment Protocol with vCards - 2023-08-01T06:31:46.214334+00:00 + 2025-10-11T21:46:47.175634+00:00 + python-feedgen Wendell 2013-11-12 18:34:37+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Extending the Payment Protocol with vCards - 2023-08-01T06:31:46.214334+00:00 + 2025-10-11T21:46:47.175785+00:00 - In an email exchange between Wendell and Taylor, confusion arose regarding the use of a vCard for passing around data. Wendell clarified that Taylor was referring to a standard method of data transfer and assured that the end user would not be exposed to the vCard. He also mentioned that the vCard's existence would be temporary. Mike Hearn responded to this exchange by expressing his skepticism about the necessity of vCard support for payment protocol extensions. However, he encouraged experimentation and prototyping, stating that extensions only require tag numbers, which are not likely to run out soon. Wendell's signature in the email included links to grabhive.com, hivewallet on Twitter, and his GPG key (6C0C9411).Another email exchange between Taylor Gerring and Mike Hearn focused on payment protocol extensions. Gerring proposed the idea of vCard support as a means to enhance usability and improve user experience in wallets supporting Payment Protocol (PP). Hearn, however, expressed doubt about the usefulness of vCards and instead suggested social network integration as a better alternative. He argued that social network integration is more favorable because it utilizes existing user IDs that can be queried without API authorization. Hearn suggested embedding a social network URL into a payment request to associate a name or photo with a payment. He also mentioned the possibility of steganographically embedding a key into a profile picture for authentication purposes. Overall, Hearn encouraged experimentation and prototyping of various extension ideas.In a post on the BitcoinTalk forums, Taylor Gerring outlined a concept for extending the Payment Protocol with optional vCard support. Gerring referred to BIP 0070 and Mike Hearn's Payment Protocol FAQ to provide detailed explanations. The goal of this proposal is to initiate a discussion on how to make wallets more user-friendly in a standardized manner. Gerring specifically highlighted the interest of the Hive team in "contact exchange" functionality. Gerring invited readers to provide feedback after reading the post. 2013-11-12T18:34:37+00:00 + In an email exchange between Wendell and Taylor, confusion arose regarding the use of a vCard for passing around data. Wendell clarified that Taylor was referring to a standard method of data transfer and assured that the end user would not be exposed to the vCard. He also mentioned that the vCard's existence would be temporary. Mike Hearn responded to this exchange by expressing his skepticism about the necessity of vCard support for payment protocol extensions. However, he encouraged experimentation and prototyping, stating that extensions only require tag numbers, which are not likely to run out soon. Wendell's signature in the email included links to grabhive.com, hivewallet on Twitter, and his GPG key (6C0C9411).Another email exchange between Taylor Gerring and Mike Hearn focused on payment protocol extensions. Gerring proposed the idea of vCard support as a means to enhance usability and improve user experience in wallets supporting Payment Protocol (PP). Hearn, however, expressed doubt about the usefulness of vCards and instead suggested social network integration as a better alternative. He argued that social network integration is more favorable because it utilizes existing user IDs that can be queried without API authorization. Hearn suggested embedding a social network URL into a payment request to associate a name or photo with a payment. He also mentioned the possibility of steganographically embedding a key into a profile picture for authentication purposes. Overall, Hearn encouraged experimentation and prototyping of various extension ideas.In a post on the BitcoinTalk forums, Taylor Gerring outlined a concept for extending the Payment Protocol with optional vCard support. Gerring referred to BIP 0070 and Mike Hearn's Payment Protocol FAQ to provide detailed explanations. The goal of this proposal is to initiate a discussion on how to make wallets more user-friendly in a standardized manner. Gerring specifically highlighted the interest of the Hive team in "contact exchange" functionality. Gerring invited readers to provide feedback after reading the post. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Message-Signing-based-authentication.xml b/static/bitcoin-dev/Nov_2013/combined_Message-Signing-based-authentication.xml index 9c1f2259ef..8c91e69631 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Message-Signing-based-authentication.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Message-Signing-based-authentication.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Message Signing based authentication - 2023-08-01T06:22:02.845121+00:00 + 2025-10-11T21:46:36.545195+00:00 + python-feedgen Melvin Carvalho 2013-12-06 10:44:32+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Message Signing based authentication - 2023-08-01T06:22:02.846122+00:00 + 2025-10-11T21:46:36.545402+00:00 - On November 6, 2013, a discussion was held on the storage of private keys in relation to cryptocurrency. The conversation mentioned the use of Trezor, a hardware wallet for storing Bitcoin private keys. Another topic discussed was the use of Secure QR Login (SQRL), a simplified authentication system that uses QR codes.The conversation also touched on the possibility of storing crypto in the browser using NSS, but it was noted that Bitcoin's curve may not be supported due to lack of NIST approval. However, if a compelling use case is presented, it could potentially be added.In an email exchange between Johnathan Corgan and bitcoingrant, the signing of an arbitrary string by the server was discussed. Bitcoingrant suggested XORing the string with a randomly generated nonce before signing it, and passing both the nonce and signature back to the server for verification. The conversation also mentioned the little-known HTTP code 402, "Payment Required," and provided contact information and a link to Corgan Labs, which offers SDR Training and Development Services.Slush suggested that in order to replace passwords with digital signatures, the message-to-be-signed should be structured and human-readable. Slush also raised concerns about where private keys are stored, but suggested that client-side certificates can be used to solve this problem. Two methods were explained for using client-side certificates, both of which have been used by Slush for over five years.A new Message Signing based authentication method was introduced in celebration of the 5-year anniversary of the Bitcoin whitepaper. The method involves the server providing a token for the client to sign, and the client passing back the signed message and Bitcoin address for validation. A proof of concept forum utilizing this method was provided, with plans to make the source code available on Github.The security of token signing was discussed, with suggestions made to modify or structure the token to avoid unintentional signatures. The Diffie-Hellman key exchange protocol was proposed as a standard way to avoid producing unintentional signatures.The distinction between what is required and what is strongly recommended in terms of reusing EC keys and addresses for transactions was discussed. It was argued that reusing keys should be seen as a best practice rather than a protocol requirement.On November 3, 2013, Allen Piscitello shared a use case where generating a new key for a Multisig Refund Transaction was necessary. It was noted that Bitcoin as a system has always required a unique EC key and address for each transaction.In a discussion on November 2, 2013, Allen Piscitello expressed concerns about signing a refund transaction before the original transaction is broadcast. Luke-Jr commented that there is no use case for signing with an address that has already been sent coins, but it was acknowledged that there is no way to stop someone from sending to an "identity" address.The concern of signing a refund transaction before the original transaction is broadcast was raised in multiple email threads. It was suggested to require sending the full transaction instead of just a hash to ensure security. The importance of use cases being grounded in actual needs rather than laziness was emphasized.A white paper on passwordless secure login based on bitcoin/bitmessage technology has been shared by alk.org. This technology aims to create a secure login without the need for passwords. The post was signed using PGP encryption.In an email thread from November 2, 2013, Mike Hearn discussed the use of client certificates for authentication. He acknowledged that while browser manufacturers have not optimized the user experience for this method, it is still possible. Hearn cited a Mozilla Labs project as an example. However, he noted that more popular options like OAuth or Persona operate on a trusted third-party model, creating a conflict of interest since browser manufacturers are often identity providers. Hearn expressed his preference for controlling his own identity with Public Key Infrastructure (PKI), but acknowledged that major players like Facebook and webmail providers dominate the market. The email thread also included a link to a white paper on secure code signing practices for Android apps.The authentication process described in the context involves a server providing a token to the client, which is then signed by the client and sent back along with a Bitcoin address. The server then validates the message and uses the provided alias (optional) and Bitcoin address for identification. A detailed article on this authentication method can be found on the website pilif.github.io, which explores why SSL client certificates are not widely used.On November 2, 2013, a celebration was held for the 5th anniversary of the Bitcoin whitepaper. As part of the celebration, a new authentication method called Message Signing was introduced. In this method, the server provides a token for the client to sign, which is then passed back to the server along with the client's bitcoin address. The server validates the message and uses the alias and bitcoin address for identification. A proof of concept forum utilizing this authentication method 2013-12-06T10:44:32+00:00 + On November 6, 2013, a discussion was held on the storage of private keys in relation to cryptocurrency. The conversation mentioned the use of Trezor, a hardware wallet for storing Bitcoin private keys. Another topic discussed was the use of Secure QR Login (SQRL), a simplified authentication system that uses QR codes.The conversation also touched on the possibility of storing crypto in the browser using NSS, but it was noted that Bitcoin's curve may not be supported due to lack of NIST approval. However, if a compelling use case is presented, it could potentially be added.In an email exchange between Johnathan Corgan and bitcoingrant, the signing of an arbitrary string by the server was discussed. Bitcoingrant suggested XORing the string with a randomly generated nonce before signing it, and passing both the nonce and signature back to the server for verification. The conversation also mentioned the little-known HTTP code 402, "Payment Required," and provided contact information and a link to Corgan Labs, which offers SDR Training and Development Services.Slush suggested that in order to replace passwords with digital signatures, the message-to-be-signed should be structured and human-readable. Slush also raised concerns about where private keys are stored, but suggested that client-side certificates can be used to solve this problem. Two methods were explained for using client-side certificates, both of which have been used by Slush for over five years.A new Message Signing based authentication method was introduced in celebration of the 5-year anniversary of the Bitcoin whitepaper. The method involves the server providing a token for the client to sign, and the client passing back the signed message and Bitcoin address for validation. A proof of concept forum utilizing this method was provided, with plans to make the source code available on Github.The security of token signing was discussed, with suggestions made to modify or structure the token to avoid unintentional signatures. The Diffie-Hellman key exchange protocol was proposed as a standard way to avoid producing unintentional signatures.The distinction between what is required and what is strongly recommended in terms of reusing EC keys and addresses for transactions was discussed. It was argued that reusing keys should be seen as a best practice rather than a protocol requirement.On November 3, 2013, Allen Piscitello shared a use case where generating a new key for a Multisig Refund Transaction was necessary. It was noted that Bitcoin as a system has always required a unique EC key and address for each transaction.In a discussion on November 2, 2013, Allen Piscitello expressed concerns about signing a refund transaction before the original transaction is broadcast. Luke-Jr commented that there is no use case for signing with an address that has already been sent coins, but it was acknowledged that there is no way to stop someone from sending to an "identity" address.The concern of signing a refund transaction before the original transaction is broadcast was raised in multiple email threads. It was suggested to require sending the full transaction instead of just a hash to ensure security. The importance of use cases being grounded in actual needs rather than laziness was emphasized.A white paper on passwordless secure login based on bitcoin/bitmessage technology has been shared by alk.org. This technology aims to create a secure login without the need for passwords. The post was signed using PGP encryption.In an email thread from November 2, 2013, Mike Hearn discussed the use of client certificates for authentication. He acknowledged that while browser manufacturers have not optimized the user experience for this method, it is still possible. Hearn cited a Mozilla Labs project as an example. However, he noted that more popular options like OAuth or Persona operate on a trusted third-party model, creating a conflict of interest since browser manufacturers are often identity providers. Hearn expressed his preference for controlling his own identity with Public Key Infrastructure (PKI), but acknowledged that major players like Facebook and webmail providers dominate the market. The email thread also included a link to a white paper on secure code signing practices for Android apps.The authentication process described in the context involves a server providing a token to the client, which is then signed by the client and sent back along with a Bitcoin address. The server then validates the message and uses the provided alias (optional) and Bitcoin address for identification. A detailed article on this authentication method can be found on the website pilif.github.io, which explores why SSL client certificates are not widely used.On November 2, 2013, a celebration was held for the 5th anniversary of the Bitcoin whitepaper. As part of the celebration, a new authentication method called Message Signing was introduced. In this method, the server provides a token for the client to sign, which is then passed back to the server along with the client's bitcoin address. The server validates the message and uses the alias and bitcoin address for identification. A proof of concept forum utilizing this authentication method - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Network-propagation-speeds.xml b/static/bitcoin-dev/Nov_2013/combined_Network-propagation-speeds.xml index e788da5d87..f51bd5a923 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Network-propagation-speeds.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Network-propagation-speeds.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Network propagation speeds - 2023-08-01T06:43:42.093831+00:00 + 2025-10-11T21:46:23.793914+00:00 + python-feedgen Christian Decker 2013-11-27 20:46:50+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Network propagation speeds - 2023-08-01T06:43:42.095076+00:00 + 2025-10-11T21:46:23.794099+00:00 - Christian Decker is currently working on adding real-time stats to the webpage and is looking for time to implement access to the collector. He received a request from Mike Hearn to sort the snapshots by date, which he agreed to do. In response to Michael Gronager's suggestion to normalize the results with block size, Christian Decker stated that he will extend the calculations to include a size-normalized version. He also mentioned that given enough samples, they may be able to reconstruct some of the system parameters and attempted to correlate propagation speed and number of inputs/outputs.Gregory Maxwell requested Christian Decker to publish the block ids and timestamp sets for each block, which would be useful in correlating propagation information against block characteristics. To this, Christian Decker said that he's looking for a good way to publish these measurements as they are rather large in size. The conversation took place on the Bitcoin-development mailing list.A conversation between Michael Gronager and Christian Decker from 2013 about sorting snapshots by date gave rise to a discussion on real-time stats. Christian suggested extending calculations to include a size-normalized version, as well as attempting to correlate propagation speed and number of inputs/outputs to see if processing at the nodes has an influence. Michael suggested normalizing the results with block size and plotting the delay graph as e.g. normalized to the averaged blocksize or defining a standard block size to compare the plot between days. He also asked if the correlation of propagation times holds for transaction sizes as well.In a discussion on Bitcoin development, Christian Decker posted his measurement code from the Information Propagation paper and automated it to correlate propagation information against block characteristics. Gregory Maxwell requested that Decker publish the block ids and timestamp sets for each block to further analyze the data. However, Decker expressed concern about serving large files due to website capacity limitations but offered to provide the information on a per user basis if demand is not significant. Michael also contributed to the conversation, suggesting normalizing results with block size and finding correlations with transaction sizes.Christian Decker shared his measurement code on the Information Propagation paper and automated it as much as possible to create the Network Propagation page on bitcoinstats.com. This page takes a daily snapshot of the situation, calculates the time until blocks and transactions reach a certain percentile of the nodes in the network, and shows the density function describing at what times nodes learn about the existence of a block/transaction. Decker intends to add more information and plots over time, but he wanted to push this out quickly as there were some people asking for it. He mentioned that saving raw log data requires saving transaction timestamp data because whether or not a given node has a transaction already matters regarding propagation.A member of the Bitcoin-development mailing list requested graphs and raw data showing how propagation data changes over time, as well as instrumentation of bitcoind to discover where time is spent when relaying a block. Gregory Maxwell asked for block ids and timestamp sets for each block to aid in correlating propagation information against block characteristics. Christian Decker mentioned that he is trying to find a good way to publish some measurements, but doesn't want to serve them along with the website due to capacity limitations. He is currently looking for suggestions on how to publish them effectively.In November 2013, Christian Decker wrote an email regarding the measurement code from the Information Propagation paper. He automated the code as much as possible and mentioned that it would be useful to publish the block ids and timestamp sets for each block. The reason for this was to correlate propagation information against block characteristics, which came up during a discussion about the Cornell paper.Christian Decker, the author of the Information Propagation paper, has created an automated measurement code for network propagation, which takes a daily snapshot of the situation and calculates the time until blocks and transactions reach a certain percentile of nodes in the network. The result is available on the Network Propagation page on bitcoinstats.com. Christian Decker intends to add more information and plots over time, but wanted to push this out quickly as there were some people asking for it. 2013-11-27T20:46:50+00:00 + Christian Decker is currently working on adding real-time stats to the webpage and is looking for time to implement access to the collector. He received a request from Mike Hearn to sort the snapshots by date, which he agreed to do. In response to Michael Gronager's suggestion to normalize the results with block size, Christian Decker stated that he will extend the calculations to include a size-normalized version. He also mentioned that given enough samples, they may be able to reconstruct some of the system parameters and attempted to correlate propagation speed and number of inputs/outputs.Gregory Maxwell requested Christian Decker to publish the block ids and timestamp sets for each block, which would be useful in correlating propagation information against block characteristics. To this, Christian Decker said that he's looking for a good way to publish these measurements as they are rather large in size. The conversation took place on the Bitcoin-development mailing list.A conversation between Michael Gronager and Christian Decker from 2013 about sorting snapshots by date gave rise to a discussion on real-time stats. Christian suggested extending calculations to include a size-normalized version, as well as attempting to correlate propagation speed and number of inputs/outputs to see if processing at the nodes has an influence. Michael suggested normalizing the results with block size and plotting the delay graph as e.g. normalized to the averaged blocksize or defining a standard block size to compare the plot between days. He also asked if the correlation of propagation times holds for transaction sizes as well.In a discussion on Bitcoin development, Christian Decker posted his measurement code from the Information Propagation paper and automated it to correlate propagation information against block characteristics. Gregory Maxwell requested that Decker publish the block ids and timestamp sets for each block to further analyze the data. However, Decker expressed concern about serving large files due to website capacity limitations but offered to provide the information on a per user basis if demand is not significant. Michael also contributed to the conversation, suggesting normalizing results with block size and finding correlations with transaction sizes.Christian Decker shared his measurement code on the Information Propagation paper and automated it as much as possible to create the Network Propagation page on bitcoinstats.com. This page takes a daily snapshot of the situation, calculates the time until blocks and transactions reach a certain percentile of the nodes in the network, and shows the density function describing at what times nodes learn about the existence of a block/transaction. Decker intends to add more information and plots over time, but he wanted to push this out quickly as there were some people asking for it. He mentioned that saving raw log data requires saving transaction timestamp data because whether or not a given node has a transaction already matters regarding propagation.A member of the Bitcoin-development mailing list requested graphs and raw data showing how propagation data changes over time, as well as instrumentation of bitcoind to discover where time is spent when relaying a block. Gregory Maxwell asked for block ids and timestamp sets for each block to aid in correlating propagation information against block characteristics. Christian Decker mentioned that he is trying to find a good way to publish some measurements, but doesn't want to serve them along with the website due to capacity limitations. He is currently looking for suggestions on how to publish them effectively.In November 2013, Christian Decker wrote an email regarding the measurement code from the Information Propagation paper. He automated the code as much as possible and mentioned that it would be useful to publish the block ids and timestamp sets for each block. The reason for this was to correlate propagation information against block characteristics, which came up during a discussion about the Cornell paper.Christian Decker, the author of the Information Propagation paper, has created an automated measurement code for network propagation, which takes a daily snapshot of the situation and calculates the time until blocks and transactions reach a certain percentile of nodes in the network. The result is available on the Network Propagation page on bitcoinstats.com. Christian Decker intends to add more information and plots over time, but wanted to push this out quickly as there were some people asking for it. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_On-the-optimal-block-size-and-why-transaction-fees-are-8-times-too-low-or-transactions-8-times-too-big-.xml b/static/bitcoin-dev/Nov_2013/combined_On-the-optimal-block-size-and-why-transaction-fees-are-8-times-too-low-or-transactions-8-times-too-big-.xml index cf5754a663..4559923cb1 100644 --- a/static/bitcoin-dev/Nov_2013/combined_On-the-optimal-block-size-and-why-transaction-fees-are-8-times-too-low-or-transactions-8-times-too-big-.xml +++ b/static/bitcoin-dev/Nov_2013/combined_On-the-optimal-block-size-and-why-transaction-fees-are-8-times-too-low-or-transactions-8-times-too-big-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big) - 2023-08-01T06:31:13.122812+00:00 + 2025-10-11T21:46:49.300502+00:00 + python-feedgen Peter Todd 2013-11-15 10:52:40+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big) - 2023-08-01T06:31:13.122812+00:00 + 2025-10-11T21:46:49.300644+00:00 - The email thread among Bitcoin experts revolves around the cost of including transactions in blocks and how it benefits larger mining pools. Michael Gronager suggests that reducing network hops would decrease the cost of including transactions per kilobyte (kB). However, Peter Todd argues that this reduction is unlikely to occur and that large pools can easily connect with each other. He also advises smaller miners not to include transactions in their blocks if they want to remain competitive. The conversation concludes with a discussion on the reward system for miners and the importance of decentralization and resistance to a 51% attack.Peter Todd presents his calculation of the current fee being too small and argues against the need to set a maximum block size. He believes that the probability of a fork will naturally incentivize not letting blocks grow endlessly. Michael agrees with Todd's calculations and points out that the problem lies in Bitcoin's design itself. Regardless of block size or network speed, the current consensus protocol rewards larger mining pools with lower costs per kB to include transactions. Todd does not see rewarding economies of scale as a problem as long as the impact is not severe. The email includes links to other Bitcoin development topics.The fundamental issue at hand is that the current Bitcoin consensus protocol favors larger mining pools by granting them lower costs per kB to include transactions. This problem persists irrespective of block size or network speed. Allowing unlimited block size would exacerbate the problem by increasing fixed costs, while maintaining a 1MB block size indefinitely does not address the underlying issue. Being a larger miner confers significant advantages as they can charge lower fees for transactions, resulting in higher earnings. However, this creates a challenge for decentralization, as smaller miners lack the resources to match the high bandwidth and low-latency internet connections of larger pools. As a result, there are substantial differences in costs and perverse incentives to publish blocks to only a minority of hashing power.Michael Gronager introduces a framework for approximating minimal fees and optimal block size based on propagation time. He suggests that reducing propagation time would also reduce fees. Another parameter to consider is the time between blocks, which is currently closer to 400 than the ideal of 600 due to current hash acceleration. Mike Hearn proposes tracking and recording block propagation times, orphan stats per size bucket, and other network data to help users determine proper settings. Pieter Wuille corrects himself regarding C. Decker's paper, clarifying that it used measurements from blocks 20000-210000 between September and November 2012, before the release of version 0.8. Michael requests someone from academia to perform a full probabilistic analysis of his outlined model.A user in the Bitcoin development mailing list expresses the opinion that developers must first understand the tradeoff between propagation and fees before helping miners figure it out. They suggest developing a server that tracks and records block propagation times, fees passed up per block, orphan stats per size bucket, etc., as this would be immensely beneficial. Pieter Wuille corrects himself again, stating that C. Decker's paper actually used measurements from blocks 20000-210000 between September and November 2012, not blocks 180000-190000 as previously mentioned. The email also includes a link to November webinars for C, C++, Fortran developers to enhance application performance with scalable programming models and explore techniques for threading, error checking, porting, and tuning.In a discussion on the use of measurements for propagation delays in Bitcoin, Pieter Wuille corrects himself once more regarding the data used in C. Decker's paper. He clarifies that the actual measurements were taken from blocks 20000-210000, which occurred from September to November 2012, before the release of version 0.8 of bitcoind/bitcoin-qt.Michael Gronager discusses the possibility of estimating transaction fee size and optimal block size based on an article by Decker et al. Gronager determines that the propagation of a block is roughly proportional to its size, and slower propagation increases the risk of a fork. Miners must balance this risk with the opportunity to include more transactions and earn fees. Using equations, Gronager calculates the expected average earnings and concludes that the current fee is too small. He argues against the need for a maximum block size, as the probability of a fork naturally incentivizes not letting blocks grow infinitely. Gronager suggests two potential paths forward: raising the minimum fee or making transactions smaller. Broadcasting transactions in blocks solely as their hash could separate fee size from transaction size. According to Gronager's calculations, the current optimal block size is an empty block (without other transactions), and the current optimal transaction fee size should be 0.00076. Implementing a minimum fee of 0.00015 would lead to an optimal block size of 1083kB for a bounty of 25 and 2417kB for a bounty of 12.5. The optimal size without a bounty or with an infinite fee would 2013-11-15T10:52:40+00:00 + The email thread among Bitcoin experts revolves around the cost of including transactions in blocks and how it benefits larger mining pools. Michael Gronager suggests that reducing network hops would decrease the cost of including transactions per kilobyte (kB). However, Peter Todd argues that this reduction is unlikely to occur and that large pools can easily connect with each other. He also advises smaller miners not to include transactions in their blocks if they want to remain competitive. The conversation concludes with a discussion on the reward system for miners and the importance of decentralization and resistance to a 51% attack.Peter Todd presents his calculation of the current fee being too small and argues against the need to set a maximum block size. He believes that the probability of a fork will naturally incentivize not letting blocks grow endlessly. Michael agrees with Todd's calculations and points out that the problem lies in Bitcoin's design itself. Regardless of block size or network speed, the current consensus protocol rewards larger mining pools with lower costs per kB to include transactions. Todd does not see rewarding economies of scale as a problem as long as the impact is not severe. The email includes links to other Bitcoin development topics.The fundamental issue at hand is that the current Bitcoin consensus protocol favors larger mining pools by granting them lower costs per kB to include transactions. This problem persists irrespective of block size or network speed. Allowing unlimited block size would exacerbate the problem by increasing fixed costs, while maintaining a 1MB block size indefinitely does not address the underlying issue. Being a larger miner confers significant advantages as they can charge lower fees for transactions, resulting in higher earnings. However, this creates a challenge for decentralization, as smaller miners lack the resources to match the high bandwidth and low-latency internet connections of larger pools. As a result, there are substantial differences in costs and perverse incentives to publish blocks to only a minority of hashing power.Michael Gronager introduces a framework for approximating minimal fees and optimal block size based on propagation time. He suggests that reducing propagation time would also reduce fees. Another parameter to consider is the time between blocks, which is currently closer to 400 than the ideal of 600 due to current hash acceleration. Mike Hearn proposes tracking and recording block propagation times, orphan stats per size bucket, and other network data to help users determine proper settings. Pieter Wuille corrects himself regarding C. Decker's paper, clarifying that it used measurements from blocks 20000-210000 between September and November 2012, before the release of version 0.8. Michael requests someone from academia to perform a full probabilistic analysis of his outlined model.A user in the Bitcoin development mailing list expresses the opinion that developers must first understand the tradeoff between propagation and fees before helping miners figure it out. They suggest developing a server that tracks and records block propagation times, fees passed up per block, orphan stats per size bucket, etc., as this would be immensely beneficial. Pieter Wuille corrects himself again, stating that C. Decker's paper actually used measurements from blocks 20000-210000 between September and November 2012, not blocks 180000-190000 as previously mentioned. The email also includes a link to November webinars for C, C++, Fortran developers to enhance application performance with scalable programming models and explore techniques for threading, error checking, porting, and tuning.In a discussion on the use of measurements for propagation delays in Bitcoin, Pieter Wuille corrects himself once more regarding the data used in C. Decker's paper. He clarifies that the actual measurements were taken from blocks 20000-210000, which occurred from September to November 2012, before the release of version 0.8 of bitcoind/bitcoin-qt.Michael Gronager discusses the possibility of estimating transaction fee size and optimal block size based on an article by Decker et al. Gronager determines that the propagation of a block is roughly proportional to its size, and slower propagation increases the risk of a fork. Miners must balance this risk with the opportunity to include more transactions and earn fees. Using equations, Gronager calculates the expected average earnings and concludes that the current fee is too small. He argues against the need for a maximum block size, as the probability of a fork naturally incentivizes not letting blocks grow infinitely. Gronager suggests two potential paths forward: raising the minimum fee or making transactions smaller. Broadcasting transactions in blocks solely as their hash could separate fee size from transaction size. According to Gronager's calculations, the current optimal block size is an empty block (without other transactions), and the current optimal transaction fee size should be 0.00076. Implementing a minimum fee of 0.00015 would lead to an optimal block size of 1083kB for a bounty of 25 and 2417kB for a bounty of 12.5. The optimal size without a bounty or with an infinite fee would - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Possible-Solution-To-SM-Attack.xml b/static/bitcoin-dev/Nov_2013/combined_Possible-Solution-To-SM-Attack.xml index 88917c2d8f..f30ff97540 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Possible-Solution-To-SM-Attack.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Possible-Solution-To-SM-Attack.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Possible Solution To SM Attack - 2023-08-01T06:26:45.660083+00:00 + 2025-10-11T21:46:51.423286+00:00 + python-feedgen rob.golding at astutium.com 2013-11-06 00:37:49+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Possible Solution To SM Attack - 2023-08-01T06:26:45.661080+00:00 + 2025-10-11T21:46:51.423502+00:00 - In the context presented, Alice and Bob are miners in the Bitcoin network. Alice secretly mines on a different block (A2) while withholding this information from other miners. Bob broadcasts his block (A1) assuming that Alice will send her previously mined block to all other miners. However, by the time Bob's block reaches other miners, most of them have already received Block A1, making Bob's block likely to be orphaned. To gain an advantage, Alice waits until another miner finds a block before releasing her previously mined block. This allows her to mine longer on a valid block. One potential solution suggested is to consider either the total transactions or fees for block acceptance. It is unclear if there is a problem that needs fixing.The conversation also discusses the issue of choosing the block with the lowest hash when mining in Bitcoin. Quinn Harris argues that this may not be the best option as both good and bad miners have an equal probability of finding a lower hash. Drak suggests making it unpredictable by choosing based on a hash of the blockhash and selecting the lowest result. This way, Alice can calculate the hash of her blockhash and determine the probability of Bob's block being used. The complexity does not change the decision-making process, as Alice should mine the next block if hers is more than 50% likely to be used. Otherwise, she should work to find a better current block.Gavin Andresen expresses his desire to be convinced of a real-world problem existing before considering potential solutions. He requests further analysis of the proposed selfish-mining algorithm at a specific share-of-network and gamma=0. He struggles to reproduce the findings in the paper, especially when considering the "opportunity cost" of working on more blocks in the private chain that might be orphaned. Gavin admits that he may be missing something obvious.In another conversation, Gregory Maxwell and Drak discuss the issue of fair block selection. Drak suggests choosing the block with the lower target if two blocks are broadcast within a certain period. Gregory points out a flaw in this logic, stating that it incentivizes miners to hurry up and release their blocks if they have an unusually low number. Gregory proposes a two-step solution: first, deciding whether high or low wins based on the leading bytes from hash(alice)+hash(bob), and second, choosing the winner based on the higher or lower hash value of Alice and Bob's hashes. This eliminates the incentive to release a block with an unusually low hash value.A proposal is made to randomly choose the winning block in the case of two blocks being broadcast within a certain period. This is considered fair and simple. However, concerns are raised about the incentive for miners to quickly release blocks with unusually low values. Non-first-block-heard strategies could lead to significant increases in large reorganizations and perverse incentives. The author mentions negative results from simulating these strategies in the past.Quinn Harris criticizes the idea of choosing the block with the lowest hash as the best option in blockchain. Both good and bad miners have an equal probability of finding a lower hash. However, after Alice finds a block, she can determine the probability of someone else finding a lower value hash that meets the difficulty requirement. Drak suggests adding another factor by deciding the rules of whether higher or lower wins based on hashing both competing blockhashes.On November 5, 2013, a proposed solution suggests randomly choosing the winning block when multiple blocks are received within a certain time frame. This ensures randomness and fairness, and it makes it harder for an attacker to manipulate the outcome by propagating blocks first and ensuring the smallest hash.Alice has an advantage in the Bitcoin network as she can hear of a block before other miners do. She uses this advantage to gain an unfair advantage by withholding her blocks and only revealing them when it benefits her. To counter this, a possible solution is to mine on the block with the lowest hash if a certain number of blocks built from the same previous block are received within a specific time frame. Alice must also ensure that her blocks have the smallest hash, but decreasing her target to achieve this would take longer to find a valid block, negating her time advantage. 2013-11-06T00:37:49+00:00 + In the context presented, Alice and Bob are miners in the Bitcoin network. Alice secretly mines on a different block (A2) while withholding this information from other miners. Bob broadcasts his block (A1) assuming that Alice will send her previously mined block to all other miners. However, by the time Bob's block reaches other miners, most of them have already received Block A1, making Bob's block likely to be orphaned. To gain an advantage, Alice waits until another miner finds a block before releasing her previously mined block. This allows her to mine longer on a valid block. One potential solution suggested is to consider either the total transactions or fees for block acceptance. It is unclear if there is a problem that needs fixing.The conversation also discusses the issue of choosing the block with the lowest hash when mining in Bitcoin. Quinn Harris argues that this may not be the best option as both good and bad miners have an equal probability of finding a lower hash. Drak suggests making it unpredictable by choosing based on a hash of the blockhash and selecting the lowest result. This way, Alice can calculate the hash of her blockhash and determine the probability of Bob's block being used. The complexity does not change the decision-making process, as Alice should mine the next block if hers is more than 50% likely to be used. Otherwise, she should work to find a better current block.Gavin Andresen expresses his desire to be convinced of a real-world problem existing before considering potential solutions. He requests further analysis of the proposed selfish-mining algorithm at a specific share-of-network and gamma=0. He struggles to reproduce the findings in the paper, especially when considering the "opportunity cost" of working on more blocks in the private chain that might be orphaned. Gavin admits that he may be missing something obvious.In another conversation, Gregory Maxwell and Drak discuss the issue of fair block selection. Drak suggests choosing the block with the lower target if two blocks are broadcast within a certain period. Gregory points out a flaw in this logic, stating that it incentivizes miners to hurry up and release their blocks if they have an unusually low number. Gregory proposes a two-step solution: first, deciding whether high or low wins based on the leading bytes from hash(alice)+hash(bob), and second, choosing the winner based on the higher or lower hash value of Alice and Bob's hashes. This eliminates the incentive to release a block with an unusually low hash value.A proposal is made to randomly choose the winning block in the case of two blocks being broadcast within a certain period. This is considered fair and simple. However, concerns are raised about the incentive for miners to quickly release blocks with unusually low values. Non-first-block-heard strategies could lead to significant increases in large reorganizations and perverse incentives. The author mentions negative results from simulating these strategies in the past.Quinn Harris criticizes the idea of choosing the block with the lowest hash as the best option in blockchain. Both good and bad miners have an equal probability of finding a lower hash. However, after Alice finds a block, she can determine the probability of someone else finding a lower value hash that meets the difficulty requirement. Drak suggests adding another factor by deciding the rules of whether higher or lower wins based on hashing both competing blockhashes.On November 5, 2013, a proposed solution suggests randomly choosing the winning block when multiple blocks are received within a certain time frame. This ensures randomness and fairness, and it makes it harder for an attacker to manipulate the outcome by propagating blocks first and ensuring the smallest hash.Alice has an advantage in the Bitcoin network as she can hear of a block before other miners do. She uses this advantage to gain an unfair advantage by withholding her blocks and only revealing them when it benefits her. To counter this, a possible solution is to mine on the block with the lowest hash if a certain number of blocks built from the same previous block are received within a specific time frame. Alice must also ensure that her blocks have the smallest hash, but decreasing her target to achieve this would take longer to find a valid block, negating her time advantage. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Proposal-to-replace-BIP0039.xml b/static/bitcoin-dev/Nov_2013/combined_Proposal-to-replace-BIP0039.xml index 4bec91e8c4..f98e2695fb 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Proposal-to-replace-BIP0039.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Proposal-to-replace-BIP0039.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal to replace BIP0039 - 2023-08-01T06:15:56.935326+00:00 + 2025-10-11T21:47:06.302285+00:00 + python-feedgen Pavol Rusnak 2013-11-17 00:49:00+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - Proposal to replace BIP0039 - 2023-08-01T06:15:56.936392+00:00 + 2025-10-11T21:47:06.302515+00:00 - Trezor, a hardware wallet for Bitcoin users, has developed a method to prove the integrity of the seed generated by their device. This method involves combining computer-provided entropy and device-provided entropy to create a master private key and derive a master public key. The computer can verify that the master public key was derived from its own entropy without knowing Trezor's random number. However, there are concerns about verifying the mnemonic corresponding to the secret in Trezor. Trust in Trezor is required to ensure the correct derivation of the master public key. Discussions also revolve around the practicality of using mnemonics in embedded devices and the need for modifications or alternative solutions.In terms of communication between Trezor and the computer, proposals have been made for the computer to verify the master public key and confirm it is derived from its own entropy. Considerations include rigging, the use of bip32 public derivations versus private derivations, version numbers in the seed phrase, defining the tree structure, custom wordlists, and best practices for standardization in the use of BIP32. These discussions emphasize the importance of secure seed generation, verification methods, and the need for compatibility and standardization in cryptocurrency wallets.In an email exchange, the discussion focuses on the standardization of including the tree structure or version information inside the seed. Pieter suggests establishing best practices and exploring different wallet structures before finalizing any standards. Marek agrees with the need for hardening and emphasizes that bip39 already includes some strengthening. The email also touches upon bidirectional transformations, backward-compatibility, and the need to cover version bits in the specification to ensure cross-compatibility between clients.A linked Wikipedia page offers implementation methods for BIP0039, including formatting metadata. Developers can follow the guidelines provided on the page to create efficient and user-friendly implementations. Electrum developer ThomasV admits his previous rejection of adding extra information to mnemonic seeds was wrong. He now sees metadata such as a "version number" as necessary for specifying which branches of the HD tree should be used. A new proposal is suggested, similar to Pieter Wuille's proposal but without requiring a dictionary. The encoding is not symmetric, which is not a requirement for Electrum but may be required for Trezor.In a Bitcointalk forum discussion, concerns are raised about BIP0039's compatibility with Electrum and the lack of version number information in seed encoding. Suggestions include allocating a few bits of the mnemonic for encoding a version number. However, implementing both algorithms simultaneously is also proposed. An email conversation from October 2013 addresses these concerns, suggesting a decision tree implementation in Electrum to determine if the mnemonic is Electrum or BIP39. The lack of history on both algorithms would require choosing a preferred one for specific clients. 2013-11-17T00:49:00+00:00 + Trezor, a hardware wallet for Bitcoin users, has developed a method to prove the integrity of the seed generated by their device. This method involves combining computer-provided entropy and device-provided entropy to create a master private key and derive a master public key. The computer can verify that the master public key was derived from its own entropy without knowing Trezor's random number. However, there are concerns about verifying the mnemonic corresponding to the secret in Trezor. Trust in Trezor is required to ensure the correct derivation of the master public key. Discussions also revolve around the practicality of using mnemonics in embedded devices and the need for modifications or alternative solutions.In terms of communication between Trezor and the computer, proposals have been made for the computer to verify the master public key and confirm it is derived from its own entropy. Considerations include rigging, the use of bip32 public derivations versus private derivations, version numbers in the seed phrase, defining the tree structure, custom wordlists, and best practices for standardization in the use of BIP32. These discussions emphasize the importance of secure seed generation, verification methods, and the need for compatibility and standardization in cryptocurrency wallets.In an email exchange, the discussion focuses on the standardization of including the tree structure or version information inside the seed. Pieter suggests establishing best practices and exploring different wallet structures before finalizing any standards. Marek agrees with the need for hardening and emphasizes that bip39 already includes some strengthening. The email also touches upon bidirectional transformations, backward-compatibility, and the need to cover version bits in the specification to ensure cross-compatibility between clients.A linked Wikipedia page offers implementation methods for BIP0039, including formatting metadata. Developers can follow the guidelines provided on the page to create efficient and user-friendly implementations. Electrum developer ThomasV admits his previous rejection of adding extra information to mnemonic seeds was wrong. He now sees metadata such as a "version number" as necessary for specifying which branches of the HD tree should be used. A new proposal is suggested, similar to Pieter Wuille's proposal but without requiring a dictionary. The encoding is not symmetric, which is not a requirement for Electrum but may be required for Trezor.In a Bitcointalk forum discussion, concerns are raised about BIP0039's compatibility with Electrum and the lack of version number information in seed encoding. Suggestions include allocating a few bits of the mnemonic for encoding a version number. However, implementing both algorithms simultaneously is also proposed. An email conversation from October 2013 addresses these concerns, suggesting a decision tree implementation in Electrum to determine if the mnemonic is Electrum or BIP39. The lack of history on both algorithms would require choosing a preferred one for specific clients. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Revisiting-the-BIPS-process-a-proposal.xml b/static/bitcoin-dev/Nov_2013/combined_Revisiting-the-BIPS-process-a-proposal.xml index dabe616698..aa4c81040f 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Revisiting-the-BIPS-process-a-proposal.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Revisiting-the-BIPS-process-a-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Revisiting the BIPS process, a proposal - 2023-08-01T06:01:52.857239+00:00 + 2025-10-11T21:47:04.176169+00:00 + python-feedgen Gregory Maxwell 2013-11-19 17:54:34+00:00 @@ -143,13 +144,13 @@ - python-feedgen + 2 Combined summary - Revisiting the BIPS process, a proposal - 2023-08-01T06:01:52.858278+00:00 + 2025-10-11T21:47:04.176418+00:00 - In a conversation about the Bitcoin protocol, Peter Todd expressed his belief that the reference implementation should be considered the real specification, while the information on the Wiki is more like a set of notes. He acknowledged that people who are familiar with the source code do not rely heavily on the Wiki. However, Todd emphasized the importance of openness and transparency in the protocol to instill trust in the system. He suggested that alternate implementations are likely to emerge and that accurately describing the rules should include a notice indicating that it is descriptive rather than normative. Todd also offered his assistance to anyone interested in working on documenting the protocol and its semantics.Another discussion focused on the need for a formalized specification for the Bitcoin protocol to reduce bugs and encourage alternate implementations. The challenge, however, lies in the reluctance to move away from the reference client due to concerns about working on a forked chain or having inaccurate data as a client. One proposed solution is to take small pieces, reach consensus, use universal test cases, and run tests on the testnet. It was suggested that qualified individuals could handle transactions/scripting, but others are welcome to join. While the reference implementation serves as the specification, the information on the Wiki is seen as a condensed version of the real specification. Some have questioned if the information on the Wiki is intentionally obscured to encourage people to check the source code. Despite this, it is important for the protocol to be transparent and documented to build trust in the system.Christian Decker discussed the historical background of the Bitcoin protocol specification, which started over three years ago with an attempt to document the network protocol by reverse engineering it from the Satoshi client. The goal was to enable engineers to create alternative clients and move away from a single client dominating the network. Although the protocol description has improved, Decker does not consider it a complete specification. He believes that having a specification allows for an application-independent review of the protocol to identify improvements and bugs. Decker expressed his desire to see the protocol specification become an official part of the Bitcoin GitHub repository alongside the Satoshi client.In a conversation about consistency in Bitcoin's documentation, Pieter Wuille emphasized the importance of accurately describing the rules of the system while making it clear that the documentation is descriptive rather than normative. He argued against making it difficult to find information about the system, as alternate implementations are likely inevitable. Wuille suggested that extensive documentation of the source code, similar to Knuth's literate programming, could be a middle ground. The discussion raised questions about whether alternative implementations are more likely to have incorrect protocol descriptions or misunderstandings of the reference implementation source code. Wuille offered his availability to answer any questions about the protocol and its semantics.Jeff Garzik highlighted the lack of associated documents for Bitcoin Improvement Proposals (BIPs) 40 and 41 in an email exchange. The group agreed that BIPs should not be used to force ideas onto others but to build consensus and document agreements. Gregory Maxwell and Drak discussed the allocation of numbers for draft proposals, with Maxwell explaining that the IETF distinguishes between individual proposals and accepted documents by working groups. Wladimir suggested creating a repository on Github to store BIP drafts, which received support from Drak. Peter Todd volunteered to create the repository, which would allow new BIPs to use either markdown or MediaWiki format.In a discussion about the Bitcoin protocol specification, Peter Todd emphasized that the reference implementation serves as the true specification for Bitcoin, while the information on the wiki pages is more like simplified notes. He clarified that the wiki pages are not deliberately obscure but are contributed by individuals who are not involved in the development of the reference implementation. Martin Sustrik questioned whether the notes were intentionally vague to force people to check the source code.Jeff Garzik suggested a distributed approach to writing Bitcoin Improvement Proposals (BIPs), where anyone can submit a pull request to improve a draft. Martin Sustrik expressed interest in participating but was concerned that the spec was deliberately vague to force compatibility with the reference implementation rather than with a document. Peter Todd explained that the reference implementation is the actual specification and advised those who don't understand this to assume that the protocol is fixed and doesn't evolve much.Gregory Maxwell and Martin Sustrik discussed the relevance of Security Considerations in RFCs for Bitcoin. Maxwell suggested that conformance with certain sections of the specification is necessary for security. Sustrik agreed and stated that all implementations must support the current version of the protocol, regardless of whether it has been documented and published. He also recommended using RFC 6919 keywords in the Bitcoin protocol RFC to convey different levels of importance and requirement.Martin Sustrik expressed frustration with the lack of a comprehensive protocol specification for Bitcoin and offered to help create one if necessary. Peter Todd cautioned against writing RFCs due to the consensus nature of Bitcoin and suggested learning from the Khan Academy videos and reading the source code instead.Jean-Paul Kogelman shared a link to the 2013-11-19T17:54:34+00:00 + In a conversation about the Bitcoin protocol, Peter Todd expressed his belief that the reference implementation should be considered the real specification, while the information on the Wiki is more like a set of notes. He acknowledged that people who are familiar with the source code do not rely heavily on the Wiki. However, Todd emphasized the importance of openness and transparency in the protocol to instill trust in the system. He suggested that alternate implementations are likely to emerge and that accurately describing the rules should include a notice indicating that it is descriptive rather than normative. Todd also offered his assistance to anyone interested in working on documenting the protocol and its semantics.Another discussion focused on the need for a formalized specification for the Bitcoin protocol to reduce bugs and encourage alternate implementations. The challenge, however, lies in the reluctance to move away from the reference client due to concerns about working on a forked chain or having inaccurate data as a client. One proposed solution is to take small pieces, reach consensus, use universal test cases, and run tests on the testnet. It was suggested that qualified individuals could handle transactions/scripting, but others are welcome to join. While the reference implementation serves as the specification, the information on the Wiki is seen as a condensed version of the real specification. Some have questioned if the information on the Wiki is intentionally obscured to encourage people to check the source code. Despite this, it is important for the protocol to be transparent and documented to build trust in the system.Christian Decker discussed the historical background of the Bitcoin protocol specification, which started over three years ago with an attempt to document the network protocol by reverse engineering it from the Satoshi client. The goal was to enable engineers to create alternative clients and move away from a single client dominating the network. Although the protocol description has improved, Decker does not consider it a complete specification. He believes that having a specification allows for an application-independent review of the protocol to identify improvements and bugs. Decker expressed his desire to see the protocol specification become an official part of the Bitcoin GitHub repository alongside the Satoshi client.In a conversation about consistency in Bitcoin's documentation, Pieter Wuille emphasized the importance of accurately describing the rules of the system while making it clear that the documentation is descriptive rather than normative. He argued against making it difficult to find information about the system, as alternate implementations are likely inevitable. Wuille suggested that extensive documentation of the source code, similar to Knuth's literate programming, could be a middle ground. The discussion raised questions about whether alternative implementations are more likely to have incorrect protocol descriptions or misunderstandings of the reference implementation source code. Wuille offered his availability to answer any questions about the protocol and its semantics.Jeff Garzik highlighted the lack of associated documents for Bitcoin Improvement Proposals (BIPs) 40 and 41 in an email exchange. The group agreed that BIPs should not be used to force ideas onto others but to build consensus and document agreements. Gregory Maxwell and Drak discussed the allocation of numbers for draft proposals, with Maxwell explaining that the IETF distinguishes between individual proposals and accepted documents by working groups. Wladimir suggested creating a repository on Github to store BIP drafts, which received support from Drak. Peter Todd volunteered to create the repository, which would allow new BIPs to use either markdown or MediaWiki format.In a discussion about the Bitcoin protocol specification, Peter Todd emphasized that the reference implementation serves as the true specification for Bitcoin, while the information on the wiki pages is more like simplified notes. He clarified that the wiki pages are not deliberately obscure but are contributed by individuals who are not involved in the development of the reference implementation. Martin Sustrik questioned whether the notes were intentionally vague to force people to check the source code.Jeff Garzik suggested a distributed approach to writing Bitcoin Improvement Proposals (BIPs), where anyone can submit a pull request to improve a draft. Martin Sustrik expressed interest in participating but was concerned that the spec was deliberately vague to force compatibility with the reference implementation rather than with a document. Peter Todd explained that the reference implementation is the actual specification and advised those who don't understand this to assume that the protocol is fixed and doesn't evolve much.Gregory Maxwell and Martin Sustrik discussed the relevance of Security Considerations in RFCs for Bitcoin. Maxwell suggested that conformance with certain sections of the specification is necessary for security. Sustrik agreed and stated that all implementations must support the current version of the protocol, regardless of whether it has been documented and published. He also recommended using RFC 6919 keywords in the Bitcoin protocol RFC to convey different levels of importance and requirement.Martin Sustrik expressed frustration with the lack of a comprehensive protocol specification for Bitcoin and offered to help create one if necessary. Peter Todd cautioned against writing RFCs due to the consensus nature of Bitcoin and suggested learning from the Khan Academy videos and reading the source code instead.Jean-Paul Kogelman shared a link to the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Testnet-under-attack-.xml b/static/bitcoin-dev/Nov_2013/combined_Testnet-under-attack-.xml index 6f6290a1e3..cf2fc77d4e 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Testnet-under-attack-.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Testnet-under-attack-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Testnet under attack? - 2023-08-01T06:42:13.899617+00:00 + 2025-10-11T21:47:14.806170+00:00 + python-feedgen Mike Hearn 2013-11-15 20:02:06+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Testnet under attack? - 2023-08-01T06:42:13.899617+00:00 + 2025-10-11T21:47:14.806367+00:00 - The use of testnet in the development and testing of applications can sometimes be limited due to the possibility of it breaking as a result of public resource abuse. However, an alternative solution called -regtest allows for the creation of a local network that enables instant block minting and simplifies the testing and app development process.In a 2013 email thread initiated by Mike Belshe on the Bitcoin-development mailing list, concerns were raised about the occurrence of new blocks being minted every couple of seconds on the testnet chain. This issue was observed on popular platforms such as blockexplorer and btclook. The question arises as to whether this rapid creation of new blocks should be regarded as a cause for concern.It is worth noting that the email thread also included a promotion for DreamFactory, which is an open-source REST and JSON services provider specifically designed for HTML5 and Native Apps. 2013-11-15T20:02:06+00:00 + The use of testnet in the development and testing of applications can sometimes be limited due to the possibility of it breaking as a result of public resource abuse. However, an alternative solution called -regtest allows for the creation of a local network that enables instant block minting and simplifies the testing and app development process.In a 2013 email thread initiated by Mike Belshe on the Bitcoin-development mailing list, concerns were raised about the occurrence of new blocks being minted every couple of seconds on the testnet chain. This issue was observed on popular platforms such as blockexplorer and btclook. The question arises as to whether this rapid creation of new blocks should be regarded as a cause for concern.It is worth noting that the email thread also included a promotion for DreamFactory, which is an open-source REST and JSON services provider specifically designed for HTML5 and Native Apps. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Who-or-what-is-Satoshi-0-8-99-Gangnam-Style-2-1-.xml b/static/bitcoin-dev/Nov_2013/combined_Who-or-what-is-Satoshi-0-8-99-Gangnam-Style-2-1-.xml index 04a186c390..24578cae25 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Who-or-what-is-Satoshi-0-8-99-Gangnam-Style-2-1-.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Who-or-what-is-Satoshi-0-8-99-Gangnam-Style-2-1-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Who or what is /Satoshi:0.8.99/Gangnam Style:2.1/ ? - 2023-08-01T06:42:48.761290+00:00 + 2025-10-11T21:47:16.927616+00:00 + python-feedgen Addy Yeow 2013-11-22 10:55:21+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Who or what is /Satoshi:0.8.99/Gangnam Style:2.1/ ? - 2023-08-01T06:42:48.761290+00:00 + 2025-10-11T21:47:16.927770+00:00 - In an email exchange between Mike Hearn and Addy Yeow, Hearn praises Yeow's Bitnodes site and asks if it would be possible to gather and chart data on block and transaction propagation times. Yeow responds that there are several TODOs for the project in the next couple of months, including propagation data. Hearn also asks about the recent increase in running nodes and whether it is real or due to custom experimental additions. Yeow notes that a more in-depth analysis is needed.Hearn discusses additional logging he added to his node and notices that despite having 87 connections from regular nodes, virtually all transactions seen by his node are being announced by modified software running on different machines. He wonders if the owners of these nodes are relaying transactions without checking their validity, which may explain why they always win the race to announce to his node. Hearn has opened a pull request for his extra logging, which he considers trivial.On November 21, 2013, Hearn adds additional logging to his node and runs it for a few days. He finds that despite having 87 connections from regular nodes, virtually all transactions seen by his node are being announced by modified software running on different machines. Hearn wonders if anyone knows or owns these nodes and if they are relaying transactions without checking their validity, which seems to be the reason for their success. Jeff Garzik questions if the relay in question belongs to Matt and has reduced validity checking. The email exchange ends with an advertisement for Intel(R) Software Adrenaline and a link to sign up for it.Hearn shares a log showing the transactions accepted by his node and suspects that the modified software is relaying transactions without checking their validity, allowing them to always be the first to announce to his node. Garzik, a Bitcoin core developer, responds to this email. In another email conversation between Hearn and Arthur, Arthur shares a link to blockchain.info/hub-nodes, which shows three nodes from nogleg that relay the most to blockchain.info. Hearn questions if anyone knows or owns these nodes and if they are relaying transactions without checking their validity, which may explain their ability to win the race.The email thread also includes discussions on the recent increase in running nodes and the possibility of gathering and charting data on block and transaction propagation times. Hearn adds additional logging to his node and notices that virtually all transactions seen by his node are being announced by modified software running on different machines. He questions if anyone knows or owns these nodes and if they are relaying transactions without checking their validity, as it seems to be the reason for their success. The email provides a link to bitcointalk.org for further discussion.Hearn sends an email to the Bitcoin development mailing list on November 22, 2013. He adds additional logging to his node and runs it for a few days. He observes that virtually all transactions seen by his node are being announced by modified software running on different machines. Hearn wonders if anyone knows or owns these nodes and if they are relaying transactions without checking their validity. He shares a link to the pull request for his extra logging, which is considered trivial.In summary, Mike Hearn, a Bitcoin developer, discovers that despite having multiple connections, virtually all transactions seen by his node are being announced by modified software running on different machines. He suspects that these nodes are relaying transactions without checking their validity, allowing them to always be the first to announce to his node. Discussions on the recent increase in running nodes and the possibility of gathering data on block and transaction propagation times are also included in the email exchange. 2013-11-22T10:55:21+00:00 + In an email exchange between Mike Hearn and Addy Yeow, Hearn praises Yeow's Bitnodes site and asks if it would be possible to gather and chart data on block and transaction propagation times. Yeow responds that there are several TODOs for the project in the next couple of months, including propagation data. Hearn also asks about the recent increase in running nodes and whether it is real or due to custom experimental additions. Yeow notes that a more in-depth analysis is needed.Hearn discusses additional logging he added to his node and notices that despite having 87 connections from regular nodes, virtually all transactions seen by his node are being announced by modified software running on different machines. He wonders if the owners of these nodes are relaying transactions without checking their validity, which may explain why they always win the race to announce to his node. Hearn has opened a pull request for his extra logging, which he considers trivial.On November 21, 2013, Hearn adds additional logging to his node and runs it for a few days. He finds that despite having 87 connections from regular nodes, virtually all transactions seen by his node are being announced by modified software running on different machines. Hearn wonders if anyone knows or owns these nodes and if they are relaying transactions without checking their validity, which seems to be the reason for their success. Jeff Garzik questions if the relay in question belongs to Matt and has reduced validity checking. The email exchange ends with an advertisement for Intel(R) Software Adrenaline and a link to sign up for it.Hearn shares a log showing the transactions accepted by his node and suspects that the modified software is relaying transactions without checking their validity, allowing them to always be the first to announce to his node. Garzik, a Bitcoin core developer, responds to this email. In another email conversation between Hearn and Arthur, Arthur shares a link to blockchain.info/hub-nodes, which shows three nodes from nogleg that relay the most to blockchain.info. Hearn questions if anyone knows or owns these nodes and if they are relaying transactions without checking their validity, which may explain their ability to win the race.The email thread also includes discussions on the recent increase in running nodes and the possibility of gathering and charting data on block and transaction propagation times. Hearn adds additional logging to his node and notices that virtually all transactions seen by his node are being announced by modified software running on different machines. He questions if anyone knows or owns these nodes and if they are relaying transactions without checking their validity, as it seems to be the reason for their success. The email provides a link to bitcointalk.org for further discussion.Hearn sends an email to the Bitcoin development mailing list on November 22, 2013. He adds additional logging to his node and runs it for a few days. He observes that virtually all transactions seen by his node are being announced by modified software running on different machines. Hearn wonders if anyone knows or owns these nodes and if they are relaying transactions without checking their validity. He shares a link to the pull request for his extra logging, which is considered trivial.In summary, Mike Hearn, a Bitcoin developer, discovers that despite having multiple connections, virtually all transactions seen by his node are being announced by modified software running on different machines. He suspects that these nodes are relaying transactions without checking their validity, allowing them to always be the first to announce to his node. Discussions on the recent increase in running nodes and the possibility of gathering data on block and transaction propagation times are also included in the email exchange. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_Zeroconf-safe-tx-replacement-replace-for-fee-.xml b/static/bitcoin-dev/Nov_2013/combined_Zeroconf-safe-tx-replacement-replace-for-fee-.xml index 68bc5cb106..59d73fad61 100644 --- a/static/bitcoin-dev/Nov_2013/combined_Zeroconf-safe-tx-replacement-replace-for-fee-.xml +++ b/static/bitcoin-dev/Nov_2013/combined_Zeroconf-safe-tx-replacement-replace-for-fee-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Zeroconf-safe tx replacement (replace-for-fee) - 2023-08-01T06:23:37.836408+00:00 + 2025-10-11T21:46:45.051833+00:00 + python-feedgen Peter Todd 2013-11-04 11:59:25+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Zeroconf-safe tx replacement (replace-for-fee) - 2023-08-01T06:23:37.836408+00:00 + 2025-10-11T21:46:45.052007+00:00 - In a discussion about Bitcoin transaction replacement, Adam Back suggests that keeping everything the same except for the amount going to one address would simplify and strengthen transactions. However, he acknowledges that this method may compromise privacy. He also points out that change addresses do not provide much privacy based on network analysis. Back believes that more robust solutions are needed to address privacy concerns, in addition to revising fees.It is worth noting that transaction replacement has uses beyond modifying fees. However, changing the value of a designated change address after the fact could potentially enable a zeroconf attack, making it incompatible with current zero-conf-using implementations. Despite this, the code for implementing replacement is already simple and does not require further simplification. It is important to mention that transaction relaying rules are not part of consensus.In an email exchange between Bitcoin developers, Adam Back suggests that keeping everything the same except for one address receiving a different amount might enhance security. While this approach may compromise privacy, Back argues that it is worth considering to simplify and facilitate transaction validation. In response, Peter Todd suggests that instead of focusing on revising fees or undermining the 0-conf feature, more robust privacy fixes should be independently developed. Todd also proposes that replace-for-fee could prepare infrastructure for future replace-by-fee usage while avoiding debates around zero-conf transactions. The conversation also touches on the imperfect nature of estimates and the importance of backups.In another email exchange from 2013, John Dillon and Peter Todd discuss the limitations of Bitcoin estimates and the significance of backups. Todd presents his work on replace-for-fee, which allows for infrastructure preparation for potential replace-by-fee usage without getting involved in the politics surrounding zero-conf transactions. The rules for replacement are straightforward: each output in the old transaction must have a corresponding output in the new transaction with the same scriptPubKey and equal or greater value, and all old transaction outputs must be unspent. However, Todd highlights a flaw in Bitcoin wallet code where a transaction with double-spent inputs permanently blocks those inputs from being spent. Although this occurrence is rare, any CoinJoin implementation violates that assumption and could cause issues. Todd suggests that wallets should recognize when a transaction's inputs no longer exist and mark remaining inputs as unspent. 2013-11-04T11:59:25+00:00 + In a discussion about Bitcoin transaction replacement, Adam Back suggests that keeping everything the same except for the amount going to one address would simplify and strengthen transactions. However, he acknowledges that this method may compromise privacy. He also points out that change addresses do not provide much privacy based on network analysis. Back believes that more robust solutions are needed to address privacy concerns, in addition to revising fees.It is worth noting that transaction replacement has uses beyond modifying fees. However, changing the value of a designated change address after the fact could potentially enable a zeroconf attack, making it incompatible with current zero-conf-using implementations. Despite this, the code for implementing replacement is already simple and does not require further simplification. It is important to mention that transaction relaying rules are not part of consensus.In an email exchange between Bitcoin developers, Adam Back suggests that keeping everything the same except for one address receiving a different amount might enhance security. While this approach may compromise privacy, Back argues that it is worth considering to simplify and facilitate transaction validation. In response, Peter Todd suggests that instead of focusing on revising fees or undermining the 0-conf feature, more robust privacy fixes should be independently developed. Todd also proposes that replace-for-fee could prepare infrastructure for future replace-by-fee usage while avoiding debates around zero-conf transactions. The conversation also touches on the imperfect nature of estimates and the importance of backups.In another email exchange from 2013, John Dillon and Peter Todd discuss the limitations of Bitcoin estimates and the significance of backups. Todd presents his work on replace-for-fee, which allows for infrastructure preparation for potential replace-by-fee usage without getting involved in the politics surrounding zero-conf transactions. The rules for replacement are straightforward: each output in the old transaction must have a corresponding output in the new transaction with the same scriptPubKey and equal or greater value, and all old transaction outputs must be unspent. However, Todd highlights a flaw in Bitcoin wallet code where a transaction with double-spent inputs permanently blocks those inputs from being spent. Although this occurrence is rare, any CoinJoin implementation violates that assumption and could cause issues. Todd suggests that wallets should recognize when a transaction's inputs no longer exist and mark remaining inputs as unspent. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_idea.xml b/static/bitcoin-dev/Nov_2013/combined_idea.xml index 21ee42cc83..ac52af4d89 100644 --- a/static/bitcoin-dev/Nov_2013/combined_idea.xml +++ b/static/bitcoin-dev/Nov_2013/combined_idea.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - idea - 2023-08-01T06:31:56.341473+00:00 + 2025-10-11T21:47:12.679197+00:00 + python-feedgen Wladimir 2013-11-10 08:13:46+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - idea - 2023-08-01T06:31:56.341473+00:00 + 2025-10-11T21:47:12.679394+00:00 - In a November 2013 email thread, Chris Evans proposed the inclusion of an optional note field to Bitcoin transactions. The aim was to enable receivers to identify the sender of the cryptocurrency. Wladimir, one of the Bitcoin Core developers, highlighted that this issue typically arises when users reuse addresses, which is discouraged for security purposes. Instead, Wladimir recommended that users request a new receiving address along with a message through the appropriate communication channel when someone wants to send them Bitcoin. During a discussion on Bitcoin development in a mailing list, Chris Evans introduced the idea of incorporating an optional note field in transactions to facilitate transparency regarding the sender's identity. However, it was noted that the mailing list was specifically designated for development-related discussions and not intended for bug reports or feature requests. At present, Bitcoin lacks an inherent mechanism to convey the sender's information or include notes within transactions. Consequently, it is advisable to gather any necessary details before providing a payment address to someone.By implementing the proposed optional note field, Chris Evans seeks to enhance the recipient's ability to identify the sender of Bitcoin. Presently, unless explicitly stated in the accompanying message, there is no means for the receiver to ascertain the identity of the sender. The addition of a note field would streamline and organize this information, providing a more efficient solution. 2013-11-10T08:13:46+00:00 + In a November 2013 email thread, Chris Evans proposed the inclusion of an optional note field to Bitcoin transactions. The aim was to enable receivers to identify the sender of the cryptocurrency. Wladimir, one of the Bitcoin Core developers, highlighted that this issue typically arises when users reuse addresses, which is discouraged for security purposes. Instead, Wladimir recommended that users request a new receiving address along with a message through the appropriate communication channel when someone wants to send them Bitcoin. During a discussion on Bitcoin development in a mailing list, Chris Evans introduced the idea of incorporating an optional note field in transactions to facilitate transparency regarding the sender's identity. However, it was noted that the mailing list was specifically designated for development-related discussions and not intended for bug reports or feature requests. At present, Bitcoin lacks an inherent mechanism to convey the sender's information or include notes within transactions. Consequently, it is advisable to gather any necessary details before providing a payment address to someone.By implementing the proposed optional note field, Chris Evans seeks to enhance the recipient's ability to identify the sender of Bitcoin. Presently, unless explicitly stated in the accompanying message, there is no means for the receiver to ascertain the identity of the sender. The addition of a note field would streamline and organize this information, providing a more efficient solution. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml b/static/bitcoin-dev/Nov_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml index de09692020..cd61842188 100644 --- a/static/bitcoin-dev/Nov_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml +++ b/static/bitcoin-dev/Nov_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - is there a way to do bitcoin-staging? - 2023-08-01T04:55:26.435643+00:00 + 2025-10-11T21:47:08.427889+00:00 + python-feedgen Melvin Carvalho 2013-11-21 20:35:44+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - is there a way to do bitcoin-staging? - 2023-08-01T04:55:26.435643+00:00 + 2025-10-11T21:47:08.428056+00:00 - In a discussion thread from 2013, various ideas for improving the Bitcoin network were proposed. Adam Back suggested creating a live beta version of Bitcoin called "betacoin" for testing and development purposes. Alan Reiner and Peter Vessenes expressed interest in this idea, with the goal of speeding up Bitcoin development while maintaining its value and security. Meanwhile, Betacoin, a new cryptocurrency designed for faster transactions and lower fees, had already been introduced on the market, attracting interest and investment despite potential risks.The conversation also delved into reorganizing blockchain data into an authenticated tree indexed by TxOut script instead of tx-hash. This idea was put forth by Alan Reiner, who believed it could improve the efficiency of the network. Merge mining, where an alt-coin is mined alongside Bitcoin, using the same coins as Bitcoin main, was also discussed by Adam Back. Michael Gronager mentioned that he had already coded the authenticated data structure part and was considering incorporating p2pool style mining.Another topic of discussion was the use of Testnet as an alt-coin for testing non-standard transactions and developing new technologies and services. Dennison Bertram suggested that using Testnet as an alt-coin would provide a pseudo live environment for testing and incentivize people to try and exploit the system. The conversation also explored the advantages and limitations of using blockchain technology for notary and verification services.The conversation continued with various suggestions and proposals. Peter Todd proposed a "fair" merged mining system where miners would have to choose between mining an altcoin or Bitcoin to prove the sacrifice of potential Bitcoin earnings. Luke raised concerns about how this system would work for an altcoin whose price is independent of Bitcoin. Zooko expressed interest in implementing a "beta bitcoin blockchain," suggesting the creation of a common codebase for Bitcoin enthusiasts to experiment with.Adam Back asked if there was a way to experiment with new features without burdening the Bitcoin network. Merged mining and the use of an altcoin, such as bitcoin-staging, were suggested as possible solutions. Additionally, the reorganization of blockchain data into an authenticated tree indexed by TxOut script was discussed.Overall, these discussions revolved around finding ways to experiment with new features, ensure the sacrifice of potential Bitcoin earnings, and avoid diluting the value and parameters of Bitcoin. Merged mining and the use of altcoins like bitcoin-staging were considered as potential solutions to these challenges. 2013-11-21T20:35:44+00:00 + In a discussion thread from 2013, various ideas for improving the Bitcoin network were proposed. Adam Back suggested creating a live beta version of Bitcoin called "betacoin" for testing and development purposes. Alan Reiner and Peter Vessenes expressed interest in this idea, with the goal of speeding up Bitcoin development while maintaining its value and security. Meanwhile, Betacoin, a new cryptocurrency designed for faster transactions and lower fees, had already been introduced on the market, attracting interest and investment despite potential risks.The conversation also delved into reorganizing blockchain data into an authenticated tree indexed by TxOut script instead of tx-hash. This idea was put forth by Alan Reiner, who believed it could improve the efficiency of the network. Merge mining, where an alt-coin is mined alongside Bitcoin, using the same coins as Bitcoin main, was also discussed by Adam Back. Michael Gronager mentioned that he had already coded the authenticated data structure part and was considering incorporating p2pool style mining.Another topic of discussion was the use of Testnet as an alt-coin for testing non-standard transactions and developing new technologies and services. Dennison Bertram suggested that using Testnet as an alt-coin would provide a pseudo live environment for testing and incentivize people to try and exploit the system. The conversation also explored the advantages and limitations of using blockchain technology for notary and verification services.The conversation continued with various suggestions and proposals. Peter Todd proposed a "fair" merged mining system where miners would have to choose between mining an altcoin or Bitcoin to prove the sacrifice of potential Bitcoin earnings. Luke raised concerns about how this system would work for an altcoin whose price is independent of Bitcoin. Zooko expressed interest in implementing a "beta bitcoin blockchain," suggesting the creation of a common codebase for Bitcoin enthusiasts to experiment with.Adam Back asked if there was a way to experiment with new features without burdening the Bitcoin network. Merged mining and the use of an altcoin, such as bitcoin-staging, were suggested as possible solutions. Additionally, the reorganization of blockchain data into an authenticated tree indexed by TxOut script was discussed.Overall, these discussions revolved around finding ways to experiment with new features, ensure the sacrifice of potential Bitcoin earnings, and avoid diluting the value and parameters of Bitcoin. Merged mining and the use of altcoins like bitcoin-staging were considered as potential solutions to these challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_moving-the-default-display-to-mbtc.xml b/static/bitcoin-dev/Nov_2013/combined_moving-the-default-display-to-mbtc.xml index 8d81903da1..105fea8160 100644 --- a/static/bitcoin-dev/Nov_2013/combined_moving-the-default-display-to-mbtc.xml +++ b/static/bitcoin-dev/Nov_2013/combined_moving-the-default-display-to-mbtc.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - moving the default display to mbtc - 2023-08-01T06:36:29.548885+00:00 + 2025-10-11T21:47:02.044777+00:00 + python-feedgen Jannis Froese 2014-05-03 18:46:37+00:00 @@ -451,13 +452,13 @@ - python-feedgen + 2 Combined summary - moving the default display to mbtc - 2023-08-01T06:36:29.551884+00:00 + 2025-10-11T21:47:02.045164+00:00 - The ongoing debate in the Bitcoin community revolves around the unit of measurement for Bitcoin transactions. Andreas Schildbach argues that users prioritize the amount in their local currency, while Tamas Blummer suggests denominations similar to traditional currencies. Jeff Garzik proposes uBTC as a user-friendly option, and MultiBit HD offers customizable configuration options. The conversation highlights the complexity of determining the best unit of measurement for Bitcoin.There are suggestions to use symbols like XUB or uBTC as the naming convention for microbitcoins. It is emphasized that changes should not be made without user permission and that the system should take care of users who make mistakes when entering values. Additionally, the discussion highlights the need for a standardized format that empowers users to use all available decimal places and suggests the use of official test cases for wallet software to ensure desired behavior.The discussion also touches on the perception of Bitcoin prices in different currencies. Schildbach argues that users are not confused by the use of mBTC as a unit of measurement, while Blummer suggests that Bitcoin would be more widely accepted if it had prices and fractions like other currencies. The debate continues with Garzik expressing disappointment over the switch to mBTC and suggesting uBTC as a more user-friendly option.In November 2013, the Bitcoin community engaged in discussions regarding the unit of measurement for Bitcoin transactions. The main proposal was to switch from mBTC (millibitcoin) to uBTC (microbitcoin) as the standard unit. Advocates of uBTC argued that it would be more intuitive for users, as two decimal places are becoming standard for new national currencies. They believed that using uBTC would bring Bitcoin closer to everyday human scale numbers. However, there were concerns about confusion and potential mistakes leading to lost coins, as well as the perception of uBTC being less valuable.Alan Reiner expressed concerns about changing the base unit of an established system, stating that it could cause more problems than it's worth. Mark Friedenbach supported skipping mBTC and moving straight to uBTC, emphasizing the need for user-friendliness. He suggested switching currency symbols to XBT or NBC (New Bitcoin) to alleviate confusion. The discussion also touched on other issues, such as displaying fees and trading rates in BTC or MBTC, addressing terminology fix-ups, and the use of confirmations and addresses. The goal was to promote consistency and clarity in Bitcoin transactions.The rise in the value of Bitcoin raised concerns among new users who found the high price intimidating. A straw poll conducted previously showed that a majority of respondents favored switching to a system allowing for fractional amounts of Bitcoin to be purchased. Satoshi's comments indicated that while there are only 21 million coins available, there are six decimal places internally, allowing for a total of eight decimal places. It was suggested to change the default display in software to mbtc, with a dropdown display option initially and eventually becoming the default. This change aimed to make working with small numbers less tiresome and more user-friendly.Overall, the discussions focused on optimizing the user experience in Bitcoin transactions by considering the unit of measurement, currency symbols, fee displays, and terminology fixes. The community aimed to address concerns and promote clarity while ensuring a smooth transition for users. The MultiBit HD wallet offered customizable options for icons and symbols, following NIST guidelines for SI unit symbol representation. However, there was disappointment expressed by Jeff Garzik when Bitcoin Wallet moved to mBTC instead of uBTC. He believed that the consensus was for uBTC and another decimal place transition would cause confusion.Wladimir, on the other hand, responded that getting people to care about this issue was difficult and couldn't blame Andreas for making the change to mBTC since it seemed to be catching on in the community. The conversation also touched upon the issue of terminology for Bitcoin addresses. Mark Friedenbach proposed changing the term "address" to "key id" to avoid misleading associations with physical addresses or accounts. Other suggestions included using "invoice id" or "payment address" instead of "address" to avoid confusion with email addresses.The discussion also addressed the standardization of Bitcoin units and terminology. Alex Kravets suggested Bitcoin currency code standardization, proposing the use of XBT as the currency code and defining one bit as 100 satoshis. Eugen Leitl opposed this idea and suggested using SI prefixes instead. Alan Reiner supported the XBT idea but disagreed with the term "micro bitcoins", suggesting alternatives like "bits" or "microbits". The goal was to find a standardized way to represent Bitcoin units to avoid confusion among users.Usability issues in Bitcoin transactions were also discussed, particularly the difficulty of dealing with small amounts and the learning curve of Bitcoin. Suggestions were made to simplify bitcoin transactions by displaying fees and trading rates in BTC or MBTC instead of fractions of bitcoins. The community aimed to find consensus on a path forward to avoid fragmentation and confusion in the market.In conclusion, the discussions among Bitcoin developers 2014-05-03T18:46:37+00:00 + The ongoing debate in the Bitcoin community revolves around the unit of measurement for Bitcoin transactions. Andreas Schildbach argues that users prioritize the amount in their local currency, while Tamas Blummer suggests denominations similar to traditional currencies. Jeff Garzik proposes uBTC as a user-friendly option, and MultiBit HD offers customizable configuration options. The conversation highlights the complexity of determining the best unit of measurement for Bitcoin.There are suggestions to use symbols like XUB or uBTC as the naming convention for microbitcoins. It is emphasized that changes should not be made without user permission and that the system should take care of users who make mistakes when entering values. Additionally, the discussion highlights the need for a standardized format that empowers users to use all available decimal places and suggests the use of official test cases for wallet software to ensure desired behavior.The discussion also touches on the perception of Bitcoin prices in different currencies. Schildbach argues that users are not confused by the use of mBTC as a unit of measurement, while Blummer suggests that Bitcoin would be more widely accepted if it had prices and fractions like other currencies. The debate continues with Garzik expressing disappointment over the switch to mBTC and suggesting uBTC as a more user-friendly option.In November 2013, the Bitcoin community engaged in discussions regarding the unit of measurement for Bitcoin transactions. The main proposal was to switch from mBTC (millibitcoin) to uBTC (microbitcoin) as the standard unit. Advocates of uBTC argued that it would be more intuitive for users, as two decimal places are becoming standard for new national currencies. They believed that using uBTC would bring Bitcoin closer to everyday human scale numbers. However, there were concerns about confusion and potential mistakes leading to lost coins, as well as the perception of uBTC being less valuable.Alan Reiner expressed concerns about changing the base unit of an established system, stating that it could cause more problems than it's worth. Mark Friedenbach supported skipping mBTC and moving straight to uBTC, emphasizing the need for user-friendliness. He suggested switching currency symbols to XBT or NBC (New Bitcoin) to alleviate confusion. The discussion also touched on other issues, such as displaying fees and trading rates in BTC or MBTC, addressing terminology fix-ups, and the use of confirmations and addresses. The goal was to promote consistency and clarity in Bitcoin transactions.The rise in the value of Bitcoin raised concerns among new users who found the high price intimidating. A straw poll conducted previously showed that a majority of respondents favored switching to a system allowing for fractional amounts of Bitcoin to be purchased. Satoshi's comments indicated that while there are only 21 million coins available, there are six decimal places internally, allowing for a total of eight decimal places. It was suggested to change the default display in software to mbtc, with a dropdown display option initially and eventually becoming the default. This change aimed to make working with small numbers less tiresome and more user-friendly.Overall, the discussions focused on optimizing the user experience in Bitcoin transactions by considering the unit of measurement, currency symbols, fee displays, and terminology fixes. The community aimed to address concerns and promote clarity while ensuring a smooth transition for users. The MultiBit HD wallet offered customizable options for icons and symbols, following NIST guidelines for SI unit symbol representation. However, there was disappointment expressed by Jeff Garzik when Bitcoin Wallet moved to mBTC instead of uBTC. He believed that the consensus was for uBTC and another decimal place transition would cause confusion.Wladimir, on the other hand, responded that getting people to care about this issue was difficult and couldn't blame Andreas for making the change to mBTC since it seemed to be catching on in the community. The conversation also touched upon the issue of terminology for Bitcoin addresses. Mark Friedenbach proposed changing the term "address" to "key id" to avoid misleading associations with physical addresses or accounts. Other suggestions included using "invoice id" or "payment address" instead of "address" to avoid confusion with email addresses.The discussion also addressed the standardization of Bitcoin units and terminology. Alex Kravets suggested Bitcoin currency code standardization, proposing the use of XBT as the currency code and defining one bit as 100 satoshis. Eugen Leitl opposed this idea and suggested using SI prefixes instead. Alan Reiner supported the XBT idea but disagreed with the term "micro bitcoins", suggesting alternatives like "bits" or "microbits". The goal was to find a standardized way to represent Bitcoin units to avoid confusion among users.Usability issues in Bitcoin transactions were also discussed, particularly the difficulty of dealing with small amounts and the learning curve of Bitcoin. Suggestions were made to simplify bitcoin transactions by displaying fees and trading rates in BTC or MBTC instead of fractions of bitcoins. The community aimed to find consensus on a path forward to avoid fragmentation and confusion in the market.In conclusion, the discussions among Bitcoin developers - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2013/combined_we-can-all-relax-now.xml b/static/bitcoin-dev/Nov_2013/combined_we-can-all-relax-now.xml index 72c0d8abdc..e21d428a99 100644 --- a/static/bitcoin-dev/Nov_2013/combined_we-can-all-relax-now.xml +++ b/static/bitcoin-dev/Nov_2013/combined_we-can-all-relax-now.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - we can all relax now - 2023-08-01T06:27:39.645643+00:00 + 2025-10-11T21:46:38.676812+00:00 + python-feedgen E willbefull 2014-05-10 11:05:29+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - we can all relax now - 2023-08-01T06:27:39.646630+00:00 + 2025-10-11T21:46:38.677003+00:00 - The discussion revolves around several emails that were sent to the Bitcoin-development mailing list. One member, named 'kjj', criticizes the Selfish Mining paper and its unsuitability as a simulation of the Bitcoin system. They argue that the model used in the paper lacks latency and assumes attackers have total visibility across the network. In response to this, 'kjj' offers a bounty of 1 BTC for building a general Bitcoin network simulator framework that can account for latency between nodes and simulate an attacker owning varying fractions of the network.Another contributor expresses frustration with the Selfish Mining paper and criticizes the authors for assuming a total sybil attack without realizing that the conditions necessary for the attack are worse than the attack itself. This contributor also offers a bounty of 1 BTC for building a suitable network simulator that can account for latency and simulate various network scenarios.The author of one email questions the level of accuracy required for a Bitcoin network simulator and suggests conducting experiments to clarify the necessary components. They mention testing Peter Todd's miner strategy, various network split conditions, double spends, and other scenarios. Jeff Garzik offers to contribute 1 BTC to this project.In addition, one email criticizes academics for prioritizing publishing over being helpful to society. The author specifically mentions the Selfish Mining paper, which they believe is based on a flawed model that does not accurately simulate the Bitcoin system. To address the lack of a decent network simulator that allowed the paper to gain press attention, the author offers a bounty of 1 BTC for building a general Bitcoin network simulator framework that can account for latency between nodes and simulate an attacker owning varying fractions of the network.Furthermore, an author on bitcointalk.org criticizes the Selfish Mining paper for its lack of latency and proposes the need for a general Bitcoin network simulator framework that can account for latency between nodes, simulate an attacker owning varying fractions of the network, and be easily modified for other schemes. This author also offers a bounty of 1 BTC for building such a simulator, as the lack of a decent network simulator allowed the Selfish Mining paper to gain attention. 2014-05-10T11:05:29+00:00 + The discussion revolves around several emails that were sent to the Bitcoin-development mailing list. One member, named 'kjj', criticizes the Selfish Mining paper and its unsuitability as a simulation of the Bitcoin system. They argue that the model used in the paper lacks latency and assumes attackers have total visibility across the network. In response to this, 'kjj' offers a bounty of 1 BTC for building a general Bitcoin network simulator framework that can account for latency between nodes and simulate an attacker owning varying fractions of the network.Another contributor expresses frustration with the Selfish Mining paper and criticizes the authors for assuming a total sybil attack without realizing that the conditions necessary for the attack are worse than the attack itself. This contributor also offers a bounty of 1 BTC for building a suitable network simulator that can account for latency and simulate various network scenarios.The author of one email questions the level of accuracy required for a Bitcoin network simulator and suggests conducting experiments to clarify the necessary components. They mention testing Peter Todd's miner strategy, various network split conditions, double spends, and other scenarios. Jeff Garzik offers to contribute 1 BTC to this project.In addition, one email criticizes academics for prioritizing publishing over being helpful to society. The author specifically mentions the Selfish Mining paper, which they believe is based on a flawed model that does not accurately simulate the Bitcoin system. To address the lack of a decent network simulator that allowed the paper to gain press attention, the author offers a bounty of 1 BTC for building a general Bitcoin network simulator framework that can account for latency between nodes and simulate an attacker owning varying fractions of the network.Furthermore, an author on bitcointalk.org criticizes the Selfish Mining paper for its lack of latency and proposes the need for a general Bitcoin network simulator framework that can account for latency between nodes, simulate an attacker owning varying fractions of the network, and be easily modified for other schemes. This author also offers a bounty of 1 BTC for building such a simulator, as the lack of a decent network simulator allowed the Selfish Mining paper to gain attention. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_BIP-65-and-OP-CHECKLOCKTIMEVERIFY-inquiry-.xml b/static/bitcoin-dev/Nov_2014/combined_BIP-65-and-OP-CHECKLOCKTIMEVERIFY-inquiry-.xml index a5eb395997..60af7bca6c 100644 --- a/static/bitcoin-dev/Nov_2014/combined_BIP-65-and-OP-CHECKLOCKTIMEVERIFY-inquiry-.xml +++ b/static/bitcoin-dev/Nov_2014/combined_BIP-65-and-OP-CHECKLOCKTIMEVERIFY-inquiry-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry... - 2023-08-01T10:54:56.294047+00:00 + 2025-10-11T22:15:22.816573+00:00 + python-feedgen Gregory Maxwell 2014-11-28 12:03:52+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry... - 2023-08-01T10:54:56.294047+00:00 + 2025-10-11T22:15:22.816729+00:00 - During a discussion about the fungibility of coins, Flavien Charlon expressed concern that making coins less fungible could result in them being non-reorg safe. However, it was argued that coins are already not reorg safe since a double spend can invalidate them after a reorg. To mitigate this risk, it is recommended to wait for 6 confirmations for important payments. It was also noted that roughly 1% of blocks are lost to reorganizations by chance. Longer reorgs could potentially destroy large amounts of coins if descendants had additional constraints. This highlights the potential for substantial losses if reorganizations prevent the recovery of valid transactions placed earlier in the chain.The use of CHECKLOCKTIMEVERIFY was discussed, with Peter Todd suggesting that the BIP text needs further clarification. He proposed that actual working examples in code, such as micropayment channels and a greenaddress-style wallet, would be more helpful. However, Gregory Maxwell pointed out that these suggestions were intentionally excluded from the proposal. Maxwell also emphasized that coins are never reorg safe, as a double spend in their history is enough to render them invalid after a reorg. Therefore, it is advised to wait for 6 confirmations for important payments.In an email exchange, Richard Moore questioned the use of OP_CHECKLOCKTIMEVERIFY in BIP 65. He suggested an alternative approach using OP_CHECKLOCKTIME, which would push either OP_TRUE or OP_FALSE onto the stack. However, it was explained that updating the stack is not soft-fork compatible and would immediately fork the network. Similarly, an invertible test is also not soft-fork compatible. A possible solution proposed by Moore is to have the VERIFY test inside a branch and have the signer provide its falseness as input to the branch. Moore also proposed allowing an opcode that would use similar semantics against an item in the stack, enabling multiple nLockTimes in a single script. However, these suggestions would break existing invariants and potentially reduce the fungibility of coins. The locktime validity, which is monotonic, was highlighted as a useful intentional property. It was concluded that these suggestions should be further clarified in the BIP text.The email questioning the use of BIP 65 and proposing alternative approaches was sent by Richard Moore, founder of Genetic Mistakes Software Inc. Contact information for Moore can be found at the end of the email. 2014-11-28T12:03:52+00:00 + During a discussion about the fungibility of coins, Flavien Charlon expressed concern that making coins less fungible could result in them being non-reorg safe. However, it was argued that coins are already not reorg safe since a double spend can invalidate them after a reorg. To mitigate this risk, it is recommended to wait for 6 confirmations for important payments. It was also noted that roughly 1% of blocks are lost to reorganizations by chance. Longer reorgs could potentially destroy large amounts of coins if descendants had additional constraints. This highlights the potential for substantial losses if reorganizations prevent the recovery of valid transactions placed earlier in the chain.The use of CHECKLOCKTIMEVERIFY was discussed, with Peter Todd suggesting that the BIP text needs further clarification. He proposed that actual working examples in code, such as micropayment channels and a greenaddress-style wallet, would be more helpful. However, Gregory Maxwell pointed out that these suggestions were intentionally excluded from the proposal. Maxwell also emphasized that coins are never reorg safe, as a double spend in their history is enough to render them invalid after a reorg. Therefore, it is advised to wait for 6 confirmations for important payments.In an email exchange, Richard Moore questioned the use of OP_CHECKLOCKTIMEVERIFY in BIP 65. He suggested an alternative approach using OP_CHECKLOCKTIME, which would push either OP_TRUE or OP_FALSE onto the stack. However, it was explained that updating the stack is not soft-fork compatible and would immediately fork the network. Similarly, an invertible test is also not soft-fork compatible. A possible solution proposed by Moore is to have the VERIFY test inside a branch and have the signer provide its falseness as input to the branch. Moore also proposed allowing an opcode that would use similar semantics against an item in the stack, enabling multiple nLockTimes in a single script. However, these suggestions would break existing invariants and potentially reduce the fungibility of coins. The locktime validity, which is monotonic, was highlighted as a useful intentional property. It was concluded that these suggestions should be further clarified in the BIP text.The email questioning the use of BIP 65 and proposing alternative approaches was sent by Richard Moore, founder of Genetic Mistakes Software Inc. Contact information for Moore can be found at the end of the email. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_BIP-draft-Auxiliary-Header-Format.xml b/static/bitcoin-dev/Nov_2014/combined_BIP-draft-Auxiliary-Header-Format.xml index 68cf1f6e76..eca68e11b0 100644 --- a/static/bitcoin-dev/Nov_2014/combined_BIP-draft-Auxiliary-Header-Format.xml +++ b/static/bitcoin-dev/Nov_2014/combined_BIP-draft-Auxiliary-Header-Format.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP draft - Auxiliary Header Format - 2023-08-01T10:39:03.720136+00:00 + 2025-10-11T22:15:33.450451+00:00 + python-feedgen Tier Nolan 2014-11-12 19:00:48+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP draft - Auxiliary Header Format - 2023-08-01T10:39:03.720136+00:00 + 2025-10-11T22:15:33.450587+00:00 - Tier Nolan has updated the Bitcoin Improvement Proposal (BIP) for adding auxiliary headers in a bandwidth-efficient way. The BIP now covers the specification of the transactions that need to be added, and Nolan plans to create a network BIP the following day. The proposed BIP involves using the last transaction in the block to store the hash of the auxiliary header, with an overhead of only around 104 bytes per header. This is much smaller than embedding the hash of the header in the coinbase of the block.There is a tradeoff between overhead and delayed transactions, as around 12.5% of transactions may be delayed to the next block. To address this, the author suggests adding padding transactions as an improvement. However, there are implementation challenges associated with creating "seed" transactions. Each node needs control over an unspent transaction output (UTXO) to create the final transaction in the block with the digest of the auxiliary header. Therefore, mining nodes would need to include wallets to manage their UTXO entry.There are different approaches for generating signatures for locktime-restricted transactions. One approach involves adding a transaction with a few thousand outputs into the blockchain, with the signatures hard-coded into the software. However, this requires a large table of signatures and trust in the person generating the signature list not to spend the outputs early. Alternatively, mining nodes could include wallets to manage their UTXO entry, allowing them to split a zero value output into many outputs if desired. Another option is for nodes to detect special transactions and use them, such as timelocked transactions that pay to a particular address but are timelocked, with the private key for the output known. However, miners who mine version 2 blocks would not be able to spend them early.In response to initial comments, the author acknowledges the confusion regarding tying in protocol changes and agrees that separating the peer-to-peer (p2p) part from the committed data would make deployment easier. The author also proposes a middle ground where nodes can detect special transactions and use them. This would involve encoding the entire auxiliary header in the block by including the hash in the final transaction and the full auxiliary header in the second-to-last one. This reduces changes to block data storage since the auxiliary header does not have to be stored separately.Overall, the proposed BIP aims to add auxiliary headers to Bitcoin in a bandwidth-efficient manner. It addresses the tradeoff between overhead and delayed transactions, as well as implementation challenges related to creating "seed" transactions and controlling UTXO for private keys. The BIP suggests different approaches for generating signatures and acknowledges the need to separate p2p functionality from the committed data. 2014-11-12T19:00:48+00:00 + Tier Nolan has updated the Bitcoin Improvement Proposal (BIP) for adding auxiliary headers in a bandwidth-efficient way. The BIP now covers the specification of the transactions that need to be added, and Nolan plans to create a network BIP the following day. The proposed BIP involves using the last transaction in the block to store the hash of the auxiliary header, with an overhead of only around 104 bytes per header. This is much smaller than embedding the hash of the header in the coinbase of the block.There is a tradeoff between overhead and delayed transactions, as around 12.5% of transactions may be delayed to the next block. To address this, the author suggests adding padding transactions as an improvement. However, there are implementation challenges associated with creating "seed" transactions. Each node needs control over an unspent transaction output (UTXO) to create the final transaction in the block with the digest of the auxiliary header. Therefore, mining nodes would need to include wallets to manage their UTXO entry.There are different approaches for generating signatures for locktime-restricted transactions. One approach involves adding a transaction with a few thousand outputs into the blockchain, with the signatures hard-coded into the software. However, this requires a large table of signatures and trust in the person generating the signature list not to spend the outputs early. Alternatively, mining nodes could include wallets to manage their UTXO entry, allowing them to split a zero value output into many outputs if desired. Another option is for nodes to detect special transactions and use them, such as timelocked transactions that pay to a particular address but are timelocked, with the private key for the output known. However, miners who mine version 2 blocks would not be able to spend them early.In response to initial comments, the author acknowledges the confusion regarding tying in protocol changes and agrees that separating the peer-to-peer (p2p) part from the committed data would make deployment easier. The author also proposes a middle ground where nodes can detect special transactions and use them. This would involve encoding the entire auxiliary header in the block by including the hash in the final transaction and the full auxiliary header in the second-to-last one. This reduces changes to block data storage since the auxiliary header does not have to be stored separately.Overall, the proposed BIP aims to add auxiliary headers to Bitcoin in a bandwidth-efficient manner. It addresses the tradeoff between overhead and delayed transactions, as well as implementation challenges related to creating "seed" transactions and controlling UTXO for private keys. The BIP suggests different approaches for generating signatures and acknowledges the need to separate p2p functionality from the committed data. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_BIP62-and-future-script-upgrades.xml b/static/bitcoin-dev/Nov_2014/combined_BIP62-and-future-script-upgrades.xml index 956fbf99a8..868d8c09d0 100644 --- a/static/bitcoin-dev/Nov_2014/combined_BIP62-and-future-script-upgrades.xml +++ b/static/bitcoin-dev/Nov_2014/combined_BIP62-and-future-script-upgrades.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP62 and future script upgrades - 2023-08-01T10:36:29.684991+00:00 + 2025-10-11T22:15:27.076041+00:00 + python-feedgen Pieter Wuille 2014-11-05 07:53:03+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP62 and future script upgrades - 2023-08-01T10:36:29.684991+00:00 + 2025-10-11T22:15:27.076201+00:00 - Pieter Wuille has addressed some issues with the rules for Bitcoin Improvement Proposal (BIP) 62 in a Github pull request. The changes include better names for the rules, clarification on the interaction of BIP62 with P2SH, and the requirement of known hashtypes despite not being part of DER. He also suggests using v2 transactions instead of v3 transactions and applying optional rules only to strict v2, not higher or lower.In response, Peter Todd expresses skepticism about using nVersion==3, preferring to disconnect TX and block version. He believes there may be circumstances where two different new tx version numbers might need to be introduced in a single soft-fork. Todd also notes that transactions can be verified for correctness outside of a block.In a discussion among developers on Bitcoin Improvement Proposals, Todd expresses skepticism about choosing nVersion==3 for blocks and transactions. Jeff Garzik agrees with this concern and prefers to disconnect block version and transaction version. Pieter Wuille sees consensus rules as one set of rules but has no strong opinion and is fine with using nVersion==2 for transactions. They discuss the possibility of introducing two different new tx version numbers in a single soft-fork in the future and how transactions can be verified outside a block.In an email exchange, Garzik and Todd discuss the choice of nVersion==3 in relation to block version increases. Todd is skeptical about this rule and believes future increases in block.nVersion could be unrelated to transactions. Garzik agrees and cites previous ambiguity from bumping tx version due to changes in block version. While Garzik acknowledges the change, he prefers to disconnect TX and block version. Todd proposes using a single numbering system for consensus rules since they only apply to blocks. Garzik has no strong opinion and is fine with using nVersion==2 for transactions.Peter Todd expresses his skepticism towards the choice of nVersion==3 and argues that future block.nVersion increases may have nothing to do with transactions. He believes creating such a rule would be counterproductive as it would quickly be broken. Jeff Garzik agrees and shares his experience with ambiguity resulting from bumping tx version due to an increase in block version. While Garzik acknowledges the change, he prefers to disconnect TX and block version.Pieter Wuille submits a Pull Request to clarify the "clean stack" requirement in BIP62, which makes passing more inputs to a script than necessary illegal. An exception is needed for P2SH scripts as the test can only be done after the second stage evaluation. However, this rule is incompatible with future P2SH-like constructs, and any such upgrade would require an exception in the clean-stack rule, which is no longer a softfork once deployed. Luke suggests not applying this rule on every transaction with nVersion >= 3, which solves the problem. Peter Todd agrees and suggests making the rules only apply to transactions with strict nVersion==3.On November 4, 2014, Pieter Wuille suggests a solution to applying rules on every transaction with nVersion greater than or equal to 3. Luke's suggestion of not applying this rule on every transaction resolves the issue. Pieter believes this solution can be generalized by making the non-mandatory BIP62 rules only applicable to transactions with strict nVersion==3 and not higher ones. Gavin Andresen agrees, stating that soft-forking is useful for upgrades and should not be prohibited.Mike Hearn and Pieter agree that the desire for soft forks sometimes leads to ugly hacks. They also believe that hard forks should be possible when useful. However, hard forks have a higher risk that may not always be justified. Introducing a new transaction type without a hard fork is possible and avoids the risks. Additionally, hard forks reduce the security model of former full nodes to SPV without their knowledge. They suggest being aware of the effects of changes like this to keep future soft forks open as an option.The problem of using scripts-which-are-not-scripts in Bitcoin can be solved by implementing a hard fork upgrade known as "script 2.0." The current system relies on these hacks due to the desire to avoid a hard fork, but implementing this upgrade would eliminate the need for them. It is important to note that this issue exists solely because of the preference for a soft fork and the subsequent need for workarounds.A discussion has been initiated regarding the "clean stack" requirement in BIP62. An exception is needed for P2SH scripts as the test can only be done after the second stage evaluation, and rejecting all spends from P2SH would complicate matters. A pull request has been submitted to clarify this issue in BIP62. Additionally, the clean-stack rule is incompatible with future P2SH-like constructs that could be useful for deploying "Script 2.0". Any upgrade to such a system would require an exception in the clean-stack rule, which is no longer a softfork once deployed. 2014-11-05T07:53:03+00:00 + Pieter Wuille has addressed some issues with the rules for Bitcoin Improvement Proposal (BIP) 62 in a Github pull request. The changes include better names for the rules, clarification on the interaction of BIP62 with P2SH, and the requirement of known hashtypes despite not being part of DER. He also suggests using v2 transactions instead of v3 transactions and applying optional rules only to strict v2, not higher or lower.In response, Peter Todd expresses skepticism about using nVersion==3, preferring to disconnect TX and block version. He believes there may be circumstances where two different new tx version numbers might need to be introduced in a single soft-fork. Todd also notes that transactions can be verified for correctness outside of a block.In a discussion among developers on Bitcoin Improvement Proposals, Todd expresses skepticism about choosing nVersion==3 for blocks and transactions. Jeff Garzik agrees with this concern and prefers to disconnect block version and transaction version. Pieter Wuille sees consensus rules as one set of rules but has no strong opinion and is fine with using nVersion==2 for transactions. They discuss the possibility of introducing two different new tx version numbers in a single soft-fork in the future and how transactions can be verified outside a block.In an email exchange, Garzik and Todd discuss the choice of nVersion==3 in relation to block version increases. Todd is skeptical about this rule and believes future increases in block.nVersion could be unrelated to transactions. Garzik agrees and cites previous ambiguity from bumping tx version due to changes in block version. While Garzik acknowledges the change, he prefers to disconnect TX and block version. Todd proposes using a single numbering system for consensus rules since they only apply to blocks. Garzik has no strong opinion and is fine with using nVersion==2 for transactions.Peter Todd expresses his skepticism towards the choice of nVersion==3 and argues that future block.nVersion increases may have nothing to do with transactions. He believes creating such a rule would be counterproductive as it would quickly be broken. Jeff Garzik agrees and shares his experience with ambiguity resulting from bumping tx version due to an increase in block version. While Garzik acknowledges the change, he prefers to disconnect TX and block version.Pieter Wuille submits a Pull Request to clarify the "clean stack" requirement in BIP62, which makes passing more inputs to a script than necessary illegal. An exception is needed for P2SH scripts as the test can only be done after the second stage evaluation. However, this rule is incompatible with future P2SH-like constructs, and any such upgrade would require an exception in the clean-stack rule, which is no longer a softfork once deployed. Luke suggests not applying this rule on every transaction with nVersion >= 3, which solves the problem. Peter Todd agrees and suggests making the rules only apply to transactions with strict nVersion==3.On November 4, 2014, Pieter Wuille suggests a solution to applying rules on every transaction with nVersion greater than or equal to 3. Luke's suggestion of not applying this rule on every transaction resolves the issue. Pieter believes this solution can be generalized by making the non-mandatory BIP62 rules only applicable to transactions with strict nVersion==3 and not higher ones. Gavin Andresen agrees, stating that soft-forking is useful for upgrades and should not be prohibited.Mike Hearn and Pieter agree that the desire for soft forks sometimes leads to ugly hacks. They also believe that hard forks should be possible when useful. However, hard forks have a higher risk that may not always be justified. Introducing a new transaction type without a hard fork is possible and avoids the risks. Additionally, hard forks reduce the security model of former full nodes to SPV without their knowledge. They suggest being aware of the effects of changes like this to keep future soft forks open as an option.The problem of using scripts-which-are-not-scripts in Bitcoin can be solved by implementing a hard fork upgrade known as "script 2.0." The current system relies on these hacks due to the desire to avoid a hard fork, but implementing this upgrade would eliminate the need for them. It is important to note that this issue exists solely because of the preference for a soft fork and the subsequent need for workarounds.A discussion has been initiated regarding the "clean stack" requirement in BIP62. An exception is needed for P2SH scripts as the test can only be done after the second stage evaluation, and rejecting all spends from P2SH would complicate matters. A pull request has been submitted to clarify this issue in BIP62. Additionally, the clean-stack rule is incompatible with future P2SH-like constructs that could be useful for deploying "Script 2.0". Any upgrade to such a system would require an exception in the clean-stack rule, which is no longer a softfork once deployed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_Bug-in-genbuild-sh-.xml b/static/bitcoin-dev/Nov_2014/combined_Bug-in-genbuild-sh-.xml index b397c6426b..44be932981 100644 --- a/static/bitcoin-dev/Nov_2014/combined_Bug-in-genbuild-sh-.xml +++ b/static/bitcoin-dev/Nov_2014/combined_Bug-in-genbuild-sh-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bug in genbuild.sh ? - 2023-08-01T10:35:50.345633+00:00 + 2025-10-11T22:15:18.562190+00:00 + python-feedgen Wladimir 2014-11-03 10:11:09+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bug in genbuild.sh ? - 2023-08-01T10:35:50.345633+00:00 + 2025-10-11T22:15:18.562328+00:00 - During the email conversation, Francis GASCHET reported a problem they encountered while executing genuid.sh after compiling Bitcoin core on Debian 7. The error message displayed was "too many arguments". Francis shared their solution to fix this issue by making modifications to the genbuild.sh file. Specifically, they made changes to the if condition where the command "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" was executed. The modification involved adding double quotes around "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true". This adjustment successfully resolved the problem, allowing genuid.sh to execute without any issues.Wladimir, in response to Francis' solution, acknowledged it and informed him that there is an existing issue for this problem on Github. However, Wladimir mentioned that Rebroad's solution presented a new error. As a result, he planned to merge Francis' patch instead. With this information, it can be concluded that Francis' solution effectively addressed the issue with executing genuid.sh after compiling Bitcoin core on Debian 7. 2014-11-03T10:11:09+00:00 + During the email conversation, Francis GASCHET reported a problem they encountered while executing genuid.sh after compiling Bitcoin core on Debian 7. The error message displayed was "too many arguments". Francis shared their solution to fix this issue by making modifications to the genbuild.sh file. Specifically, they made changes to the if condition where the command "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" was executed. The modification involved adding double quotes around "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true". This adjustment successfully resolved the problem, allowing genuid.sh to execute without any issues.Wladimir, in response to Francis' solution, acknowledged it and informed him that there is an existing issue for this problem on Github. However, Wladimir mentioned that Rebroad's solution presented a new error. As a result, he planned to merge Francis' patch instead. With this information, it can be concluded that Francis' solution effectively addressed the issue with executing genuid.sh after compiling Bitcoin core on Debian 7. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_DS-Deprecation-Window.xml b/static/bitcoin-dev/Nov_2014/combined_DS-Deprecation-Window.xml index cd2ae2e208..ce4b0e6a19 100644 --- a/static/bitcoin-dev/Nov_2014/combined_DS-Deprecation-Window.xml +++ b/static/bitcoin-dev/Nov_2014/combined_DS-Deprecation-Window.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DS Deprecation Window - 2023-08-01T10:34:15.122397+00:00 + 2025-10-11T22:15:37.697265+00:00 + python-feedgen Tom Harding 2014-11-06 23:50:53+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - DS Deprecation Window - 2023-08-01T10:34:15.122397+00:00 + 2025-10-11T22:15:37.697450+00:00 - A new section called "Confidence to include tx1" has been added to the GitHub repository for dgenr8's out-there project. The section discusses a potential attack on miners, in which a miner excludes any transaction that was first seen less than 30 seconds ago or double spent less than 30 seconds after it was first seen. The post mentions that if a miner were to perform this action, they should expect five of 10,000 nodes to delay their block. Hal Finney and Tom Harding commented on the idea, with Finney stating that it would need careful analysis and Harding suggesting that it may be possible to quantify and target the risk of including tx1.Gregory Maxwell has proposed an attack on Bitcoin in which a malicious miner can flood other miners with orthogonal double spends that he doesn't mine himself. This attack is based on transmitting three transactions to two miners at the same time, creating a situation where Miner A knows about tx1a before Miner B, and Miner B delays his block until he knows about tx1a. The attacker tries to create a conflict that only affects everyone else except Miner A. However, Miner A can neutralize his risk by excluding any tx1 known to be double-spent. The success of the attack depends on the timing between the malicious transactions. If they are sent 10 seconds apart, the attack has little chance of success. It will be possible to quantify and target the risk of including tx1a based on the time gap to tx2.In an online discussion on Bitcoin forums, user Tom Harding expressed caution about miners including a double-spend in their block. He mentioned several factors that could mitigate the risk, such as the time offset from the first spend received and most other nodes having seen the transaction. Another user named Matt raised concerns about the proposal, and two other users replied with additional insights.In an email conversation, Tom Harding acknowledged that without double-spend relay, a miner would not be able to detect conflicting transactions. He also stated that even with double-spend relay, the miner cannot be sure and may choose to include no transactions at all to be safe. This is because a malicious miner can flood the network with orthogonal double spends.In a conversation between Matt and Tom Harding, it was discussed that without double-spend relay, miners will not know about conflicting transactions. Tom plans to add first-double-spends relay according to a specific proposal. However, if a miner includes a double-spend in their block, they have to be very careful. They hope that only a small fraction of the network will delay their block based on the time offset from the first spend they received. Additionally, most other nodes should see their transaction. The best course of action for a miner is to exclude fast transactions and connect to everyone on the network to look for double-spends.The delay in relaying/accepting blocks based on local information is considered a bad idea as it can lead to the splitting of the network. Miners are incentivized to connect with everyone on the network and look for double-spends to avoid being delayed. Tom Harding proposed a solution to improve the ability of bitcoin users to rely on unconfirmed transactions without the need for hard or soft forks. The proposal has not been implemented yet, and feedback from Bitcoin Dev is appreciated. 2014-11-06T23:50:53+00:00 + A new section called "Confidence to include tx1" has been added to the GitHub repository for dgenr8's out-there project. The section discusses a potential attack on miners, in which a miner excludes any transaction that was first seen less than 30 seconds ago or double spent less than 30 seconds after it was first seen. The post mentions that if a miner were to perform this action, they should expect five of 10,000 nodes to delay their block. Hal Finney and Tom Harding commented on the idea, with Finney stating that it would need careful analysis and Harding suggesting that it may be possible to quantify and target the risk of including tx1.Gregory Maxwell has proposed an attack on Bitcoin in which a malicious miner can flood other miners with orthogonal double spends that he doesn't mine himself. This attack is based on transmitting three transactions to two miners at the same time, creating a situation where Miner A knows about tx1a before Miner B, and Miner B delays his block until he knows about tx1a. The attacker tries to create a conflict that only affects everyone else except Miner A. However, Miner A can neutralize his risk by excluding any tx1 known to be double-spent. The success of the attack depends on the timing between the malicious transactions. If they are sent 10 seconds apart, the attack has little chance of success. It will be possible to quantify and target the risk of including tx1a based on the time gap to tx2.In an online discussion on Bitcoin forums, user Tom Harding expressed caution about miners including a double-spend in their block. He mentioned several factors that could mitigate the risk, such as the time offset from the first spend received and most other nodes having seen the transaction. Another user named Matt raised concerns about the proposal, and two other users replied with additional insights.In an email conversation, Tom Harding acknowledged that without double-spend relay, a miner would not be able to detect conflicting transactions. He also stated that even with double-spend relay, the miner cannot be sure and may choose to include no transactions at all to be safe. This is because a malicious miner can flood the network with orthogonal double spends.In a conversation between Matt and Tom Harding, it was discussed that without double-spend relay, miners will not know about conflicting transactions. Tom plans to add first-double-spends relay according to a specific proposal. However, if a miner includes a double-spend in their block, they have to be very careful. They hope that only a small fraction of the network will delay their block based on the time offset from the first spend they received. Additionally, most other nodes should see their transaction. The best course of action for a miner is to exclude fast transactions and connect to everyone on the network to look for double-spends.The delay in relaying/accepting blocks based on local information is considered a bad idea as it can lead to the splitting of the network. Miners are incentivized to connect with everyone on the network and look for double-spends to avoid being delayed. Tom Harding proposed a solution to improve the ability of bitcoin users to rely on unconfirmed transactions without the need for hard or soft forks. The proposal has not been implemented yet, and feedback from Bitcoin Dev is appreciated. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml b/static/bitcoin-dev/Nov_2014/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml index 0afa9e37ce..910ceb196c 100644 --- a/static/bitcoin-dev/Nov_2014/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml +++ b/static/bitcoin-dev/Nov_2014/combined_Deanonymisation-of-clients-in-Bitcoin-P2P-network-paper.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Deanonymisation of clients in Bitcoin P2P network paper - 2023-08-01T10:41:10.355017+00:00 + 2025-10-11T22:15:16.436973+00:00 + python-feedgen Mike Hearn 2015-01-22 13:20:29+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Deanonymisation of clients in Bitcoin P2P network paper - 2023-08-01T10:41:10.356013+00:00 + 2025-10-11T22:15:16.437139+00:00 - The conversation revolves around the idea of mainstream wallets and wallets designed for cryptocurrency research sharing a common core. The speaker gives examples such as bitcoinj and discusses the use of Tor to improve Bitcoin wallet security. The potential risks and limitations of using Tor are also addressed, including connection drops and deanonymization issues.There is a suggestion to explore ways to improve synergy between Tor and Bitcoin, while maintaining their standalone functionality. The importance of prioritizing user privacy and the need for better DoS handling are emphasized. The discussion also touches on the effectiveness of connecting to Bitcoin using Tor and the concerns over users being forced off Tor via DOS attacks.The paper from the University of Luxembourg is referenced, which discusses the risks of obtaining IP addresses of clients involved in transactions on the Bitcoin network. The need for improvements in DoS handling and the separation of transaction submission and P2P networking are also mentioned. The potential vulnerabilities and trade-offs associated with tying Bitcoin to Tor too deeply are discussed.In response to a query about a paper posted on Reddit, Jeff Garzik, a Bitcoin core developer and open source evangelist, discussed an attack that can de-anonymize clients on the bitcoin network. While Garzik did not recall being contacted directly, he explained that the attack has been previously discussed and relies on certain conditions.If a user is using Tor, the attacker will attempt to kick the machine off Tor, assuming it will switch to non-Tor. However, this only applies to dual stack nodes, which are not completely anonymous as users operate from their public IP address anyway. The email thread includes a link to the paper from the University of Luxembourg, which delves into the details of the attack.A recent post on Reddit has shed light on a paper by the University of Luxembourg, which explores how attackers can compromise the anonymity of clients on the Bitcoin network. The paper examines various methods that can be employed to undermine user privacy. It is unclear whether these issues have been addressed, but it is mentioned that the core developers were informed about them before the publication of the paper. To access the full paper, interested individuals can follow the link provided in the Reddit post. 2015-01-22T13:20:29+00:00 + The conversation revolves around the idea of mainstream wallets and wallets designed for cryptocurrency research sharing a common core. The speaker gives examples such as bitcoinj and discusses the use of Tor to improve Bitcoin wallet security. The potential risks and limitations of using Tor are also addressed, including connection drops and deanonymization issues.There is a suggestion to explore ways to improve synergy between Tor and Bitcoin, while maintaining their standalone functionality. The importance of prioritizing user privacy and the need for better DoS handling are emphasized. The discussion also touches on the effectiveness of connecting to Bitcoin using Tor and the concerns over users being forced off Tor via DOS attacks.The paper from the University of Luxembourg is referenced, which discusses the risks of obtaining IP addresses of clients involved in transactions on the Bitcoin network. The need for improvements in DoS handling and the separation of transaction submission and P2P networking are also mentioned. The potential vulnerabilities and trade-offs associated with tying Bitcoin to Tor too deeply are discussed.In response to a query about a paper posted on Reddit, Jeff Garzik, a Bitcoin core developer and open source evangelist, discussed an attack that can de-anonymize clients on the bitcoin network. While Garzik did not recall being contacted directly, he explained that the attack has been previously discussed and relies on certain conditions.If a user is using Tor, the attacker will attempt to kick the machine off Tor, assuming it will switch to non-Tor. However, this only applies to dual stack nodes, which are not completely anonymous as users operate from their public IP address anyway. The email thread includes a link to the paper from the University of Luxembourg, which delves into the details of the attack.A recent post on Reddit has shed light on a paper by the University of Luxembourg, which explores how attackers can compromise the anonymity of clients on the Bitcoin network. The paper examines various methods that can be employed to undermine user privacy. It is unclear whether these issues have been addressed, but it is mentioned that the core developers were informed about them before the publication of the paper. To access the full paper, interested individuals can follow the link provided in the Reddit post. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_Increasing-the-OP-RETURN-maximum-payload-size.xml b/static/bitcoin-dev/Nov_2014/combined_Increasing-the-OP-RETURN-maximum-payload-size.xml index b1e61c439c..6293afe68e 100644 --- a/static/bitcoin-dev/Nov_2014/combined_Increasing-the-OP-RETURN-maximum-payload-size.xml +++ b/static/bitcoin-dev/Nov_2014/combined_Increasing-the-OP-RETURN-maximum-payload-size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Increasing the OP_RETURN maximum payload size - 2023-08-01T10:40:35.801028+00:00 + 2025-10-11T22:15:14.313571+00:00 + python-feedgen Jean-Pierre Rupp 2014-11-20 23:39:16+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Increasing the OP_RETURN maximum payload size - 2023-08-01T10:40:35.801028+00:00 + 2025-10-11T22:15:14.313768+00:00 - The current size of the OP_RETURN in the blockchain is causing concerns among application developers who find it insufficient for many legitimate uses. While increasing the size could potentially lead to a faster-growing blockchain, there have been no issues with the current size of 40 bytes. Wladimir supports increasing the OP_RETURN size and believes it can be done safely without any worries. There is even a suggestion to increase it beyond 80 bytes.The debate revolves around the use of OP_RETURN, which allows small amounts of data to be stored within bitcoin transactions. The proposal is to increase the size from 40 bytes to 80 bytes, but some worry that this could encourage people to use the blockchain as a convenient transport channel. Counterparty, however, has found a way around the limit by using multi-sig outputs instead. Open Assets also requires more than 40 bytes to store a URL in the OP_RETURN output. In October 2014, there were 1,674 OP_RETURNs with an average size of 14.37 bytes per block. Increasing the size to 80 bytes would have minimal impact on bandwidth and storage requirements while being extremely useful for many use cases where a hash alone is insufficient. These statistics should take into account the number of Counterparty transactions that could have been OP_RETURNs if they had been permitted.In an email conversation, Pieter Wuille explains that any wallet offering functionality beyond maintaining a balance and sending coins will result in privacy loss. However, HD wallets provide the advantage of separating secret data and public data. While there are risks associated with upgrading to stealth addresses, such as potential loss of metadata and coins if not backed up properly, OP_RETURN offers a solution that eliminates these risks.Flavien Charlon expresses concern about the use of OP_RETURN, arguing that it encourages people to use the blockchain as a transport channel. However, he acknowledges that Counterparty has managed to bypass the 40-byte limit by using multi-sig outputs. Charlon believes that Open Assets needs to store a URL in the OP_RETURN output, which is not possible within the current size limit. Storing only a hash is inadequate for building interesting applications. There were 1,674 OP_RETURNs in October 2014, and increasing the size to 80 bytes would have negligible impact on bandwidth and storage requirements while being highly useful.Chris Pacia and Pieter Wuille discuss the use of stealth addresses with out-of-band communication in relation to HD wallets. Chris expresses concern that this approach would negate the benefits of HD wallets and require more frequent backups. Pieter explains that any wallet offering additional functionality beyond balance maintenance will require backups. HD wallets offer the separation of secret data and public data, reducing the risk of lost coins. In terms of upgrading to stealth, manual backup is necessary, whereas OP_RETURN eliminates the need for manual backups.Adam Back discusses the use of the blockchain as a backup mechanism, highlighting its inefficiency and unreliability due to its broadcast nature. He suggests alternative methods such as cloud storage or disk encryption for decentralized long-term storage. Back also raises concerns about the use of stealth addresses and the potential loss of benefits from HD wallets if out-of-band communication is used instead of OP_RETURN.The concern with OP_RETURN is that it encourages the use of the blockchain as a convenient transport channel rather than solely for data validation. Counterparty has been successful in using the blockchain for storage and transport by employing multi-sig outputs. However, the 40-byte limit hinders Open Assets' ability to store a URL in the OP_RETURN output. Storing only a hash is suitable for basic timestamping applications but lacks the capacity to build more interesting functionalities. Increasing the size to 80 bytes would have a negligible impact on bandwidth and storage requirements while providing significant utility. Pieter Wuille emphasizes the importance of discouraging the use of blockchain as a transport channel.The idea of using the blockchain for transaction data is gaining popularity due to convenience, backup, and atomicity. However, data design must be compressed and minimal for scalability. The blockchain's use as a convenient channel is not sufficient justification, as there are other reliable channels available. Backup on the blockchain is inefficient, and cheaper methods like cloud storage or disk encryption provide secure backup. Atomicity can be achieved through out-of-band communication, avoiding the need for transactions on the blockchain. Slow transports can offer better security than interactive transports.Jorge Timón and Alan Reiner discuss potential use cases that require larger OP_RETURN sizes. While Jorge couldn't think of any, Alan mentions his previous irritation with the reduction to 40 bytes, as he wanted to put ECDSA in signatures in the OP_RETURN. Although he couldn't recall the application, it could be used for sending a payment with a signature timestamped in the blockchain.In a discussion about OP_RETURN sizes, it is mentioned that the decision to make it 40 bytes was justified for timestamping purposes. However, pay-to-contract offers a cheaper and more 2014-11-20T23:39:16+00:00 + The current size of the OP_RETURN in the blockchain is causing concerns among application developers who find it insufficient for many legitimate uses. While increasing the size could potentially lead to a faster-growing blockchain, there have been no issues with the current size of 40 bytes. Wladimir supports increasing the OP_RETURN size and believes it can be done safely without any worries. There is even a suggestion to increase it beyond 80 bytes.The debate revolves around the use of OP_RETURN, which allows small amounts of data to be stored within bitcoin transactions. The proposal is to increase the size from 40 bytes to 80 bytes, but some worry that this could encourage people to use the blockchain as a convenient transport channel. Counterparty, however, has found a way around the limit by using multi-sig outputs instead. Open Assets also requires more than 40 bytes to store a URL in the OP_RETURN output. In October 2014, there were 1,674 OP_RETURNs with an average size of 14.37 bytes per block. Increasing the size to 80 bytes would have minimal impact on bandwidth and storage requirements while being extremely useful for many use cases where a hash alone is insufficient. These statistics should take into account the number of Counterparty transactions that could have been OP_RETURNs if they had been permitted.In an email conversation, Pieter Wuille explains that any wallet offering functionality beyond maintaining a balance and sending coins will result in privacy loss. However, HD wallets provide the advantage of separating secret data and public data. While there are risks associated with upgrading to stealth addresses, such as potential loss of metadata and coins if not backed up properly, OP_RETURN offers a solution that eliminates these risks.Flavien Charlon expresses concern about the use of OP_RETURN, arguing that it encourages people to use the blockchain as a transport channel. However, he acknowledges that Counterparty has managed to bypass the 40-byte limit by using multi-sig outputs. Charlon believes that Open Assets needs to store a URL in the OP_RETURN output, which is not possible within the current size limit. Storing only a hash is inadequate for building interesting applications. There were 1,674 OP_RETURNs in October 2014, and increasing the size to 80 bytes would have negligible impact on bandwidth and storage requirements while being highly useful.Chris Pacia and Pieter Wuille discuss the use of stealth addresses with out-of-band communication in relation to HD wallets. Chris expresses concern that this approach would negate the benefits of HD wallets and require more frequent backups. Pieter explains that any wallet offering additional functionality beyond balance maintenance will require backups. HD wallets offer the separation of secret data and public data, reducing the risk of lost coins. In terms of upgrading to stealth, manual backup is necessary, whereas OP_RETURN eliminates the need for manual backups.Adam Back discusses the use of the blockchain as a backup mechanism, highlighting its inefficiency and unreliability due to its broadcast nature. He suggests alternative methods such as cloud storage or disk encryption for decentralized long-term storage. Back also raises concerns about the use of stealth addresses and the potential loss of benefits from HD wallets if out-of-band communication is used instead of OP_RETURN.The concern with OP_RETURN is that it encourages the use of the blockchain as a convenient transport channel rather than solely for data validation. Counterparty has been successful in using the blockchain for storage and transport by employing multi-sig outputs. However, the 40-byte limit hinders Open Assets' ability to store a URL in the OP_RETURN output. Storing only a hash is suitable for basic timestamping applications but lacks the capacity to build more interesting functionalities. Increasing the size to 80 bytes would have a negligible impact on bandwidth and storage requirements while providing significant utility. Pieter Wuille emphasizes the importance of discouraging the use of blockchain as a transport channel.The idea of using the blockchain for transaction data is gaining popularity due to convenience, backup, and atomicity. However, data design must be compressed and minimal for scalability. The blockchain's use as a convenient channel is not sufficient justification, as there are other reliable channels available. Backup on the blockchain is inefficient, and cheaper methods like cloud storage or disk encryption provide secure backup. Atomicity can be achieved through out-of-band communication, avoiding the need for transactions on the blockchain. Slow transports can offer better security than interactive transports.Jorge Timón and Alan Reiner discuss potential use cases that require larger OP_RETURN sizes. While Jorge couldn't think of any, Alan mentions his previous irritation with the reduction to 40 bytes, as he wanted to put ECDSA in signatures in the OP_RETURN. Although he couldn't recall the application, it could be used for sending a payment with a signature timestamped in the blockchain.In a discussion about OP_RETURN sizes, it is mentioned that the decision to make it 40 bytes was justified for timestamping purposes. However, pay-to-contract offers a cheaper and more - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_Proposal-PoW-based-throttling-of-addresses-was-Outbound-connections-rotation-.xml b/static/bitcoin-dev/Nov_2014/combined_Proposal-PoW-based-throttling-of-addresses-was-Outbound-connections-rotation-.xml index 1cad73c898..d89b471a2b 100644 --- a/static/bitcoin-dev/Nov_2014/combined_Proposal-PoW-based-throttling-of-addresses-was-Outbound-connections-rotation-.xml +++ b/static/bitcoin-dev/Nov_2014/combined_Proposal-PoW-based-throttling-of-addresses-was-Outbound-connections-rotation-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal: PoW-based throttling of addresses (was: Outbound connections rotation) - 2023-08-01T10:17:22.140245+00:00 + 2025-10-11T22:15:24.950943+00:00 + python-feedgen Isidor Zeuner 2014-11-27 03:29:24+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Proposal: PoW-based throttling of addresses (was: Outbound connections rotation) - 2023-08-01T10:17:22.140245+00:00 + 2025-10-11T22:15:24.951127+00:00 - The conversation between Mike and Isidor revolves around the impact of DKIM and PoW/hash-cash in email businesses. Isidor argues that bulk mailing companies use destination DKIM toggling to reduce CPU usage, but this may become impractical when using Bitcoin over Tor. He also challenges Mike's statement on humans not caring about delays but their source, suggesting that users do notice slow website or mobile wallet performance and avoid them. Mike counters that Tor is a separate issue and notifying users of anomalies would be unhelpful since they cannot take actionable decisions. They agree that the solution to a privacy-attacking DoS attack is to not use Tor at all, while solving an attack on the entire Bitcoin network is much more challenging.A former employee considers DKIM as a cheap and irrelevant aspect in the email business. Proof of Work (PoW) has not effectively deterred spamming efforts as it confuses bulk mail with spam. Slow website performance does matter to humans as it negatively impacts revenue. PoW tokens can be useful in a shared toolbox if nodes cannot prioritize connections, but if all users are subjected to PoW, it could lead to game over. Tor should be considered separately from the DoS problem, and users generally do not care about technical jargon like peer-to-peer networks or Tor. The solution to a privacy-attacking DoS attack is to avoid using Tor, while solving an attack on the entire Bitcoin network is more complex.The discussion centers on using PoW to combat DoS attacks in cryptocurrencies. PoW has been recognized since the days of "hashcash" before cryptocurrencies existed. However, it did not work well against bots, who have more patience than humans. DKIM, another PoW approach, is disliked by bulk mailer operators due to the CPU burden it creates. Nevertheless, users see it as advantageous for identifying participants. In cryptocurrencies, PoW can be used to combat DoS without compromising user identification. Allowing users to prove their dedication through a connecting PoW challenge can help them navigate a DoS-imposed partial outage. Nodes can utilize measures such as scaling up connection PoW, throttling the connection on the work queue, and throttling the IP on the work queue to throttle misbehaving clients. However, proper tuning of these measures is crucial to minimize the impact on well-behaving users.It is important to avoid misclassifying reasonable behavior as harmful to prevent unintended consequences. Big sites often suffer DoS attacks due to accidental bad software updates or unexpected press-driven growth. Users should be notified when unusual events occur. Approaches like cookies and Proof of UTXO provide additional possibilities to deduce user identity, making them less ideal for maintaining privacy. The use of PoW as a defense against DoS attacks has been recognized since the pre-cryptocurrency days of "hashcash." However, scoring connections and distinguishing bots from humans remains a challenge. Human PoWs in the form of CAPTCHAs also prove ineffective. Concerns about using cookies to link connections and deanonymize users are mitigated by the likelihood of DoS attacks being driven by botnets. Proof of UTXO presents another way to rank users, but it carries CPU imbalances that can be leveled out with a small PoW cost.Isidor proposes a PoW-based approach to prevent DoS attacks on Tor exit nodes for Bitcoin. He suggests that only misbehaving clients should be required to do the PoW, making it harder for attackers to sustain their attacks. Mike suggests that work prioritization and queueing mechanisms, along with finding ways to distinguish "good" clients from "bad" ones, are the correct solutions. However, preserving privacy while implementing these measures poses challenges. Isidor proposes having both options available - allowing those who can solve the anti-DoS PoW to connect, albeit slower, while those who prefer weaker clients can sacrifice privacy for connectivity using cookies.The article discusses the difficulty of addressing DoS attacks on Tor exit nodes used for connecting to Bitcoin. Requiring all clients to perform complicated work wouldn't solve the issue and would make weak clients vulnerable while attackers' botnets solve PoWs. The article suggests implementing work prioritization and queueing mechanisms to distinguish "good" clients from "bad" ones. However, maintaining privacy during this process is challenging. Requiring clients to present a cookie during resource exhaustion events to prove their longevity and allow them to jump the queue may be a long-term solution.To improve privacy when posting transactions using unrelated inputs, the article suggests using only the same set of nodes for subsequent transactions with the same input addresses. This approach mirrors how Tor uses different circuits for connecting to different hosts. Completely banning Tor exit nodes may not be the best solution, but throttling them using a PoW-based access control scheme could be more effective. Scaling up the connecting difficulty for misbehaving addresses would discourage DoS attacks on Tor exit nodes for Bitcoin connectivity. Additionally, this approach can 2014-11-27T03:29:24+00:00 + The conversation between Mike and Isidor revolves around the impact of DKIM and PoW/hash-cash in email businesses. Isidor argues that bulk mailing companies use destination DKIM toggling to reduce CPU usage, but this may become impractical when using Bitcoin over Tor. He also challenges Mike's statement on humans not caring about delays but their source, suggesting that users do notice slow website or mobile wallet performance and avoid them. Mike counters that Tor is a separate issue and notifying users of anomalies would be unhelpful since they cannot take actionable decisions. They agree that the solution to a privacy-attacking DoS attack is to not use Tor at all, while solving an attack on the entire Bitcoin network is much more challenging.A former employee considers DKIM as a cheap and irrelevant aspect in the email business. Proof of Work (PoW) has not effectively deterred spamming efforts as it confuses bulk mail with spam. Slow website performance does matter to humans as it negatively impacts revenue. PoW tokens can be useful in a shared toolbox if nodes cannot prioritize connections, but if all users are subjected to PoW, it could lead to game over. Tor should be considered separately from the DoS problem, and users generally do not care about technical jargon like peer-to-peer networks or Tor. The solution to a privacy-attacking DoS attack is to avoid using Tor, while solving an attack on the entire Bitcoin network is more complex.The discussion centers on using PoW to combat DoS attacks in cryptocurrencies. PoW has been recognized since the days of "hashcash" before cryptocurrencies existed. However, it did not work well against bots, who have more patience than humans. DKIM, another PoW approach, is disliked by bulk mailer operators due to the CPU burden it creates. Nevertheless, users see it as advantageous for identifying participants. In cryptocurrencies, PoW can be used to combat DoS without compromising user identification. Allowing users to prove their dedication through a connecting PoW challenge can help them navigate a DoS-imposed partial outage. Nodes can utilize measures such as scaling up connection PoW, throttling the connection on the work queue, and throttling the IP on the work queue to throttle misbehaving clients. However, proper tuning of these measures is crucial to minimize the impact on well-behaving users.It is important to avoid misclassifying reasonable behavior as harmful to prevent unintended consequences. Big sites often suffer DoS attacks due to accidental bad software updates or unexpected press-driven growth. Users should be notified when unusual events occur. Approaches like cookies and Proof of UTXO provide additional possibilities to deduce user identity, making them less ideal for maintaining privacy. The use of PoW as a defense against DoS attacks has been recognized since the pre-cryptocurrency days of "hashcash." However, scoring connections and distinguishing bots from humans remains a challenge. Human PoWs in the form of CAPTCHAs also prove ineffective. Concerns about using cookies to link connections and deanonymize users are mitigated by the likelihood of DoS attacks being driven by botnets. Proof of UTXO presents another way to rank users, but it carries CPU imbalances that can be leveled out with a small PoW cost.Isidor proposes a PoW-based approach to prevent DoS attacks on Tor exit nodes for Bitcoin. He suggests that only misbehaving clients should be required to do the PoW, making it harder for attackers to sustain their attacks. Mike suggests that work prioritization and queueing mechanisms, along with finding ways to distinguish "good" clients from "bad" ones, are the correct solutions. However, preserving privacy while implementing these measures poses challenges. Isidor proposes having both options available - allowing those who can solve the anti-DoS PoW to connect, albeit slower, while those who prefer weaker clients can sacrifice privacy for connectivity using cookies.The article discusses the difficulty of addressing DoS attacks on Tor exit nodes used for connecting to Bitcoin. Requiring all clients to perform complicated work wouldn't solve the issue and would make weak clients vulnerable while attackers' botnets solve PoWs. The article suggests implementing work prioritization and queueing mechanisms to distinguish "good" clients from "bad" ones. However, maintaining privacy during this process is challenging. Requiring clients to present a cookie during resource exhaustion events to prove their longevity and allow them to jump the queue may be a long-term solution.To improve privacy when posting transactions using unrelated inputs, the article suggests using only the same set of nodes for subsequent transactions with the same input addresses. This approach mirrors how Tor uses different circuits for connecting to different hosts. Completely banning Tor exit nodes may not be the best solution, but throttling them using a PoW-based access control scheme could be more effective. Scaling up the connecting difficulty for misbehaving addresses would discourage DoS attacks on Tor exit nodes for Bitcoin connectivity. Additionally, this approach can - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_Running-a-full-node.xml b/static/bitcoin-dev/Nov_2014/combined_Running-a-full-node.xml index d6c99e090e..025b1ef99d 100644 --- a/static/bitcoin-dev/Nov_2014/combined_Running-a-full-node.xml +++ b/static/bitcoin-dev/Nov_2014/combined_Running-a-full-node.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Running a full node - 2023-08-01T10:36:52.857161+00:00 + 2025-10-11T22:15:41.949935+00:00 + python-feedgen Francis GASCHET 2014-11-09 15:22:21+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Running a full node - 2023-08-01T10:36:52.857161+00:00 + 2025-10-11T22:15:41.950093+00:00 - Francis GASCHET, a Bitcoin enthusiast, is concerned about the decreasing number of full nodes with appropriate resources in France. To contribute to the network, he plans to set up a full node and seeks advice on the required storage, RAM, and bandwidth resources. His company has the capacity to host an HA server in a secured environment. In his email update, Francis informs that his node is up and running on 5.56.40.1:8333, using Linux HA + dual-homed Internet transit.Jameson Lopp, a well-known Bitcoin developer, notes abnormal CPU spikes in his node's system metrics due to automated RPC calls. The bandwidth usage chart for his node can be found at http://statoshi.info/#/dashboard/file/default.json?panelId=1&fullscreen. Melvin Carvalho provides guidelines for running a full node based on statistics from his own node. He suggests allocating at least 50GB of disk space as the blockchain data currently uses around 30GB and may continue to grow slowly. CPU usage is minimal after syncing the blockchain. RAM usage may reach up to 1.5 GB after running for a few months. Bandwidth usage averages about 500GB of traffic per month, mostly outgoing.Daniel F also provides guidelines for storage, RAM, and bandwidth resources needed to run a full node. Disk usage for blockchain data is currently around 30GB and may continue to grow slowly. CPU usage is not a problem after syncing the blockchain. RAM usage after a few months is approximately 1.5GB. Bandwidth usage averages about 500GB of traffic per month, mostly outgoing.A Reddit user named Francis GASCHET posts a comment in 2014, stating his plan to set up a full node for Bitcoin using his company's resources. He asks for information on storage, RAM, and bandwidth requirements. Thomas Zander directs GASCHET to a stats script running on a particular node and shares a link - http://213.165.91.169/. He also suggests checking out a forum discussion on bitcointalk.org for more opinions on the topic.In an email, Francis Gaschet expresses his interest in Bitcoin and his plan to set up a full node. He requests information on storage, RAM, and bandwidth resources. He believes that CPU won't be a problem. He also provides a link to a forum discussion on bitcointalk.org where more opinions can be found.The context includes two attachments - a scrubbed HTML file and a JPEG image named "Signature-Fg.jpg". The purpose of these attachments is unclear without further information. 2014-11-09T15:22:21+00:00 + Francis GASCHET, a Bitcoin enthusiast, is concerned about the decreasing number of full nodes with appropriate resources in France. To contribute to the network, he plans to set up a full node and seeks advice on the required storage, RAM, and bandwidth resources. His company has the capacity to host an HA server in a secured environment. In his email update, Francis informs that his node is up and running on 5.56.40.1:8333, using Linux HA + dual-homed Internet transit.Jameson Lopp, a well-known Bitcoin developer, notes abnormal CPU spikes in his node's system metrics due to automated RPC calls. The bandwidth usage chart for his node can be found at http://statoshi.info/#/dashboard/file/default.json?panelId=1&fullscreen. Melvin Carvalho provides guidelines for running a full node based on statistics from his own node. He suggests allocating at least 50GB of disk space as the blockchain data currently uses around 30GB and may continue to grow slowly. CPU usage is minimal after syncing the blockchain. RAM usage may reach up to 1.5 GB after running for a few months. Bandwidth usage averages about 500GB of traffic per month, mostly outgoing.Daniel F also provides guidelines for storage, RAM, and bandwidth resources needed to run a full node. Disk usage for blockchain data is currently around 30GB and may continue to grow slowly. CPU usage is not a problem after syncing the blockchain. RAM usage after a few months is approximately 1.5GB. Bandwidth usage averages about 500GB of traffic per month, mostly outgoing.A Reddit user named Francis GASCHET posts a comment in 2014, stating his plan to set up a full node for Bitcoin using his company's resources. He asks for information on storage, RAM, and bandwidth requirements. Thomas Zander directs GASCHET to a stats script running on a particular node and shares a link - http://213.165.91.169/. He also suggests checking out a forum discussion on bitcointalk.org for more opinions on the topic.In an email, Francis Gaschet expresses his interest in Bitcoin and his plan to set up a full node. He requests information on storage, RAM, and bandwidth resources. He believes that CPU won't be a problem. He also provides a link to a forum discussion on bitcointalk.org where more opinions can be found.The context includes two attachments - a scrubbed HTML file and a JPEG image named "Signature-Fg.jpg". The purpose of these attachments is unclear without further information. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_SCRIPT-VERIFY-STRICTENC-and-CHECKSIG-NOT.xml b/static/bitcoin-dev/Nov_2014/combined_SCRIPT-VERIFY-STRICTENC-and-CHECKSIG-NOT.xml index 36f7d62739..5a3644909f 100644 --- a/static/bitcoin-dev/Nov_2014/combined_SCRIPT-VERIFY-STRICTENC-and-CHECKSIG-NOT.xml +++ b/static/bitcoin-dev/Nov_2014/combined_SCRIPT-VERIFY-STRICTENC-and-CHECKSIG-NOT.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT - 2023-08-01T10:37:18.667905+00:00 + 2025-10-11T22:15:35.573971+00:00 + python-feedgen Marius Hanne 2014-11-06 12:39:48+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT - 2023-08-01T10:37:18.667905+00:00 + 2025-10-11T22:15:35.574145+00:00 - On November 6th, 2014, Bitcoin developer Peter Todd raised concerns about an invalid transaction being accepted into the mempool by git head. The transaction in question spends the redeemScript: CHECKSIG NOT. Todd also mentioned that Bitcoin-Ruby had undergone another fork. Another user asked for clarification on the potential forking issue, as a webbtc node had just received a block, but no further information was provided.Emails between Pieter Wuille and Peter Todd discuss the vulnerability of pubkey formats not recognized by the STRICTENC flag. This vulnerability allows garbage transactions to fill up the mempool, although it does not affect IsStandard() transactions. Wuille suggests adding a second validity check with the actual consensus rules. Todd proposes two solutions: either failing unrecognized pubkeys immediately or failing the script if the pubkey is non-standard but signature verification succeeds. They agree to implement the latter solution as a "least invasive" measure, with plans to eventually eliminate hybrid-encoded pubkeys.On the same day, Pieter Wuille proposed changing the STRICTENC protocol to either fail unrecognized pubkeys immediately or fail the script if the pubkey is non-standard and signature verification succeeds. This proposal was accepted, but there was a discussion about whether this rule should apply to all pubkeys passed to CHECKMULTISIG or just the ones checked otherwise. They also acknowledged the potential difficulty of spending existing outputs and how making this a consensus rule could render existing P2SH outputs/addresses unspendable.In a message dated November 6, 2014, Peter Todd discusses the vulnerability of the STRICTENC flag implementation in the Bitcoin software. He explains that the flag treats public key formats unrecognized by the software as invalid signatures rather than rejecting the entire transaction. Exploiting this loophole allows attackers to flood the mempool with fake transactions that will never be mined. However, Todd states that he found no way to exploit this vulnerability in version 0.9.x IsStandard() transactions. He suggests changing the STRICTENC flag to either fail unrecognized pubkeys immediately or fail the script if the pubkey is non-standard but signature verification succeeds. Pieter agrees with Todd's suggestion, and they also mention the lack of softfork safety for the STRICTENC flag.On November 6, 2014, Peter Todd reported a flaw in the Bitcoin protocol where git head accepts an invalid transaction into the mempool, which spends the redeemScript. This flaw could potentially enable double spending attacks and increase the risk of fraud. Additionally, Bitcoin-Ruby experienced another fork during this time. Todd includes a signature.asc file with a digital signature along with his report.The current implementation of the STRICTENC flag in git head allows unrecognized pubkeys to be accepted into the mempool, resulting in garbage transactions that will never be mined. The issue lies in the fact that this flag treats unrecognized pubkey formats as though the signature is invalid, rather than failing the entire transaction. While this vulnerability does not affect v0.9.x IsStandard() transactions, it is uncertain if alt-implementations have been impacted. To address this, the suggested solutions are to either change STRICTENC to fail unrecognized pubkeys immediately or to fail the script if the pubkey is non-standard and signature verification succeeds. 2014-11-06T12:39:48+00:00 + On November 6th, 2014, Bitcoin developer Peter Todd raised concerns about an invalid transaction being accepted into the mempool by git head. The transaction in question spends the redeemScript: CHECKSIG NOT. Todd also mentioned that Bitcoin-Ruby had undergone another fork. Another user asked for clarification on the potential forking issue, as a webbtc node had just received a block, but no further information was provided.Emails between Pieter Wuille and Peter Todd discuss the vulnerability of pubkey formats not recognized by the STRICTENC flag. This vulnerability allows garbage transactions to fill up the mempool, although it does not affect IsStandard() transactions. Wuille suggests adding a second validity check with the actual consensus rules. Todd proposes two solutions: either failing unrecognized pubkeys immediately or failing the script if the pubkey is non-standard but signature verification succeeds. They agree to implement the latter solution as a "least invasive" measure, with plans to eventually eliminate hybrid-encoded pubkeys.On the same day, Pieter Wuille proposed changing the STRICTENC protocol to either fail unrecognized pubkeys immediately or fail the script if the pubkey is non-standard and signature verification succeeds. This proposal was accepted, but there was a discussion about whether this rule should apply to all pubkeys passed to CHECKMULTISIG or just the ones checked otherwise. They also acknowledged the potential difficulty of spending existing outputs and how making this a consensus rule could render existing P2SH outputs/addresses unspendable.In a message dated November 6, 2014, Peter Todd discusses the vulnerability of the STRICTENC flag implementation in the Bitcoin software. He explains that the flag treats public key formats unrecognized by the software as invalid signatures rather than rejecting the entire transaction. Exploiting this loophole allows attackers to flood the mempool with fake transactions that will never be mined. However, Todd states that he found no way to exploit this vulnerability in version 0.9.x IsStandard() transactions. He suggests changing the STRICTENC flag to either fail unrecognized pubkeys immediately or fail the script if the pubkey is non-standard but signature verification succeeds. Pieter agrees with Todd's suggestion, and they also mention the lack of softfork safety for the STRICTENC flag.On November 6, 2014, Peter Todd reported a flaw in the Bitcoin protocol where git head accepts an invalid transaction into the mempool, which spends the redeemScript. This flaw could potentially enable double spending attacks and increase the risk of fraud. Additionally, Bitcoin-Ruby experienced another fork during this time. Todd includes a signature.asc file with a digital signature along with his report.The current implementation of the STRICTENC flag in git head allows unrecognized pubkeys to be accepted into the mempool, resulting in garbage transactions that will never be mined. The issue lies in the fact that this flag treats unrecognized pubkey formats as though the signature is invalid, rather than failing the entire transaction. While this vulnerability does not affect v0.9.x IsStandard() transactions, it is uncertain if alt-implementations have been impacted. To address this, the suggested solutions are to either change STRICTENC to fail unrecognized pubkeys immediately or to fail the script if the pubkey is non-standard and signature verification succeeds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_The-difficulty-of-writing-consensus-critical-code-the-SIGHASH-SINGLE-bug.xml b/static/bitcoin-dev/Nov_2014/combined_The-difficulty-of-writing-consensus-critical-code-the-SIGHASH-SINGLE-bug.xml index 4f8db1c056..b30f1a7946 100644 --- a/static/bitcoin-dev/Nov_2014/combined_The-difficulty-of-writing-consensus-critical-code-the-SIGHASH-SINGLE-bug.xml +++ b/static/bitcoin-dev/Nov_2014/combined_The-difficulty-of-writing-consensus-critical-code-the-SIGHASH-SINGLE-bug.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug - 2023-08-01T10:38:25.868985+00:00 + 2025-10-11T22:15:31.324010+00:00 + python-feedgen Jean-Pierre Rupp 2014-11-15 04:43:43+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug - 2023-08-01T10:38:25.868985+00:00 + 2025-10-11T22:15:31.324186+00:00 - Jean-Pierre Rupp from Haskoin advocates for a hard fork to fix consensus bugs in the Bitcoin protocol. He believes that bugs should not be tolerated and that the protocol should be clearly documented. Rupp suggests thoroughly documenting and repairing consensus bugs on a separate branch, which would eventually lead to a scheduled hard fork. This approach would eliminate known bugs and establish a process for addressing future bugs. The hard fork would primarily impact mining pools, while most bitcoin transactions would remain unaffected. Rupp argues that convincing mining pools to upgrade their software well in advance should not be difficult.Justus Ranvier also emphasizes the importance of fixing bugs in Bitcoin due to its extra consensus requirements. Clément Elbaz suggested separating the Bitcoin consensus code into a project similar to the Linux Kernel. This idea has already been put into motion with the creation of a stand-alone script verification library, which will eventually become part of a larger project called the Bitcoin Kernel. The Bitcoin Kernel would contain only the minimum code necessary for consensus and leave the implementation of other aspects to applications built with it.In an email conversation, Tamas Blummer asked Peter Todd about the possibility of forking the consensus code. Todd responded that the consensus code is essentially frozen, and any changes made are due to mistakes rather than intentional modifications. However, he mentioned two soft-fork proposals, BIP62 and CHECKLOCKTIMEVERIFY, which are being considered. Todd highlights the challenges of making changes in an environment where multiple implementations use the same consensus-critical code.Peter Todd explains that hard-forking upgrades are not regularly done in protocols, even when there are no consensus problems. He argues that scheduling and planning necessary upgrades to fix bugs in the Bitcoin protocol is preferable to waiting for a crisis. Todd questions who benefits from not fixing bugs and provides a link to a video on email encryption for online privacy.Justus Ranvier criticizes the way Bitcoin Core handles bugs and argues for scheduling upgrades to fix bugs in the protocol. He suggests forking Bitcoin Core to avoid centralized control and ensure multiple forks maintain strong consensus. Peter Todd disagrees with regular hard-fork upgrades and emphasizes the rarity of flag days in engineering.In a discussion on Bitcoin development, various developers express their opinions on soft forks and hard forks. Jeff Garzik suggests adding CHECKLOCKTIMEVERIFY and discusses the risks and benefits of both types of forks. Matt Corallo explains the necessity of BIP62 for basic contracts and atomic swaps but also highlights its limitations. The discussion emphasizes the difficulty of writing bug-for-bug compatible code and the importance of consensus-compatible implementations derived from Bitcoin Core.In light of the bugs present in Bitcoin's consensus code, some propose freezing the code and conducting a thorough study to address these issues. Blockstream has been actively discussing this approach as an alternative to soft-fork-ready versioning, which they find unsatisfactory. It is crucial to note that bug-for-bug compatibility in Bitcoin's consensus code is critical and needs to be addressed. The exploitation of bugs like the SIGHASH_SINGLE bug and the CHECKSIG* opcode evaluation bug can result in forks and block rejections. Ensuring the consistency of the encoding of CScript() is also important to maintain the integrity of the network. 2014-11-15T04:43:43+00:00 + Jean-Pierre Rupp from Haskoin advocates for a hard fork to fix consensus bugs in the Bitcoin protocol. He believes that bugs should not be tolerated and that the protocol should be clearly documented. Rupp suggests thoroughly documenting and repairing consensus bugs on a separate branch, which would eventually lead to a scheduled hard fork. This approach would eliminate known bugs and establish a process for addressing future bugs. The hard fork would primarily impact mining pools, while most bitcoin transactions would remain unaffected. Rupp argues that convincing mining pools to upgrade their software well in advance should not be difficult.Justus Ranvier also emphasizes the importance of fixing bugs in Bitcoin due to its extra consensus requirements. Clément Elbaz suggested separating the Bitcoin consensus code into a project similar to the Linux Kernel. This idea has already been put into motion with the creation of a stand-alone script verification library, which will eventually become part of a larger project called the Bitcoin Kernel. The Bitcoin Kernel would contain only the minimum code necessary for consensus and leave the implementation of other aspects to applications built with it.In an email conversation, Tamas Blummer asked Peter Todd about the possibility of forking the consensus code. Todd responded that the consensus code is essentially frozen, and any changes made are due to mistakes rather than intentional modifications. However, he mentioned two soft-fork proposals, BIP62 and CHECKLOCKTIMEVERIFY, which are being considered. Todd highlights the challenges of making changes in an environment where multiple implementations use the same consensus-critical code.Peter Todd explains that hard-forking upgrades are not regularly done in protocols, even when there are no consensus problems. He argues that scheduling and planning necessary upgrades to fix bugs in the Bitcoin protocol is preferable to waiting for a crisis. Todd questions who benefits from not fixing bugs and provides a link to a video on email encryption for online privacy.Justus Ranvier criticizes the way Bitcoin Core handles bugs and argues for scheduling upgrades to fix bugs in the protocol. He suggests forking Bitcoin Core to avoid centralized control and ensure multiple forks maintain strong consensus. Peter Todd disagrees with regular hard-fork upgrades and emphasizes the rarity of flag days in engineering.In a discussion on Bitcoin development, various developers express their opinions on soft forks and hard forks. Jeff Garzik suggests adding CHECKLOCKTIMEVERIFY and discusses the risks and benefits of both types of forks. Matt Corallo explains the necessity of BIP62 for basic contracts and atomic swaps but also highlights its limitations. The discussion emphasizes the difficulty of writing bug-for-bug compatible code and the importance of consensus-compatible implementations derived from Bitcoin Core.In light of the bugs present in Bitcoin's consensus code, some propose freezing the code and conducting a thorough study to address these issues. Blockstream has been actively discussing this approach as an alternative to soft-fork-ready versioning, which they find unsatisfactory. It is crucial to note that bug-for-bug compatibility in Bitcoin's consensus code is critical and needs to be addressed. The exploitation of bugs like the SIGHASH_SINGLE bug and the CHECKSIG* opcode evaluation bug can result in forks and block rejections. Ensuring the consistency of the encoding of CScript() is also important to maintain the integrity of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_Update-on-mobile-2-factor-wallets.xml b/static/bitcoin-dev/Nov_2014/combined_Update-on-mobile-2-factor-wallets.xml index da0a20ab72..80caeb8609 100644 --- a/static/bitcoin-dev/Nov_2014/combined_Update-on-mobile-2-factor-wallets.xml +++ b/static/bitcoin-dev/Nov_2014/combined_Update-on-mobile-2-factor-wallets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Update on mobile 2-factor wallets - 2023-08-01T10:38:40.428762+00:00 + 2025-10-11T22:15:29.199292+00:00 + python-feedgen Mike Hearn 2014-11-08 19:36:07+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Update on mobile 2-factor wallets - 2023-08-01T10:38:40.428762+00:00 + 2025-10-11T22:15:29.199466+00:00 - The email thread discusses the development of decentralized 2FA wallets for Bitcoin, which require both a desktop/laptop and an Android smartphone app to function. Two different implementations are discussed: Bitcoin Authenticator and a wallet made by Christopher Mann and Daniel Loebenberger from Uni Bonn. Bitcoin Authenticator, developed by Alon Muroch and Chris Pacia, is currently in alpha and focuses on UI and a simple mobile security model. It uses P2SH/CHECKMULTISIG for the 2-factor functionality, but has downsides such as less support for address types and larger transactions that waste blockchain space and result in higher fees.To address these issues, Mann and Loebenberger have ported the DSA 2-of-2 signing protocol by MacKenzie and Reiter to ECDSA. Their implementation uses a combination of ECDSA, Paillier homomorphic encryption, and zero-knowledge proofs. Their protocol only works for the 2-of-2 case and their code is liberally licensed and easily integrated with Bitcoin Authenticator. Currently, neither project supports BIP70, which means that the transaction signing screen is not user-friendly or secure without trusting the destination address.The next step for these wallets is to implement support for sending a full payment request between devices. This will be pursued once the projects have obtained a reasonable user base and stability. The post also highlights the need for further research in the field of secure key escrow, as being one's own bank seems riskier compared to using traditional banks. Overall, these developments in decentralized 2FA wallets show promise in improving user experience and security in Bitcoin transactions. 2014-11-08T19:36:07+00:00 + The email thread discusses the development of decentralized 2FA wallets for Bitcoin, which require both a desktop/laptop and an Android smartphone app to function. Two different implementations are discussed: Bitcoin Authenticator and a wallet made by Christopher Mann and Daniel Loebenberger from Uni Bonn. Bitcoin Authenticator, developed by Alon Muroch and Chris Pacia, is currently in alpha and focuses on UI and a simple mobile security model. It uses P2SH/CHECKMULTISIG for the 2-factor functionality, but has downsides such as less support for address types and larger transactions that waste blockchain space and result in higher fees.To address these issues, Mann and Loebenberger have ported the DSA 2-of-2 signing protocol by MacKenzie and Reiter to ECDSA. Their implementation uses a combination of ECDSA, Paillier homomorphic encryption, and zero-knowledge proofs. Their protocol only works for the 2-of-2 case and their code is liberally licensed and easily integrated with Bitcoin Authenticator. Currently, neither project supports BIP70, which means that the transaction signing screen is not user-friendly or secure without trusting the destination address.The next step for these wallets is to implement support for sending a full payment request between devices. This will be pursued once the projects have obtained a reasonable user base and stability. The post also highlights the need for further research in the field of secure key escrow, as being one's own bank seems riskier compared to using traditional banks. Overall, these developments in decentralized 2FA wallets show promise in improving user experience and security in Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_bitcoind-as-a-library.xml b/static/bitcoin-dev/Nov_2014/combined_bitcoind-as-a-library.xml index 89556bd751..6521f39a2b 100644 --- a/static/bitcoin-dev/Nov_2014/combined_bitcoind-as-a-library.xml +++ b/static/bitcoin-dev/Nov_2014/combined_bitcoind-as-a-library.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoind as a library - 2023-08-01T10:54:36.255358+00:00 + 2025-10-11T22:15:20.688101+00:00 + python-feedgen Jeff Garzik 2014-11-30 16:38:42+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - bitcoind as a library - 2023-08-01T10:54:36.256358+00:00 + 2025-10-11T22:15:20.688246+00:00 - In an email conversation between Btc Drak and Oliver Egginger, Egginger asks for a C library for blockchain analysis and provides a link to picocoin's library. In response, Drak suggests MatthewLM's cbitcoin as an alternative option. Egginger highlights picocoin's ability to parse raw blocks and transactions and mentions their Github repository. Drak notes that cbitcoin is a good alternative to picocoin, mentioning its features such as being valgrind-clean, supporting all core and P2P data structures, and being able to parse and index the blockchain.On November 28, 2014, Egginger sent an email asking for a C library for block chain analysis and provided a link to the picocoin repository on Github. In response, there was a suggestion of another library called cbitcoin along with a Github link.In a discussion on the Bitcoin development mailing list, Mem Wallet asked if the internal libraries of Bitcoin could be made suitable for third-party development of Bitcoin-related services and tools. Wladimir responded that the plan is to provide the consensus functionality as a library in future versions of Bitcoin, with a basic transaction/script verifier already available in version 0.10. The plan for the next version is to extend this to further utxo set management, with plans also in place to add a library for transaction signing. However, there is no goal to expose everything as a library, particularly wallet- or user interface-related functionality. Specialized utility libraries would serve this purpose better. An off-topic question was also raised regarding the use of picocoin for blockchain analysis, with Oliver seeking opinions on its limitations.A recent comment on Github suggests breaking out distinct repositories may be a good approach, but it is unclear what would be in separate repositories. Wladimir explained in response to Mem Wallet's inquiry that the plan is to provide the consensus functionality as a library, where essential parts that make Bitcoin, Bitcoin will be made available. However, not everything will be exposed as a library, and specialized utility libraries would fill this purpose better. Wladimir referenced libbase58 for base58 processing as an example. Another project broke out stealth and coinjoin as distinct repositories and made them installable using npm. The message concludes with links to Abis.io, a protocol concept for decentralization and expansion of a giving economy, and a new social good.In response to a question from Mem Wallet, Wladimir explains that the plan is to provide consensus functionality as a library, starting with a basic transaction/script verifier in version 0.10. This functionality is expected to be extended to further utxo set management in future versions, but no API has been worked out yet. There are also plans to add a library for transaction signing. However, not everything will be exposed as a library, particularly wallet- or user interface-related functionality. Specialized utility libraries, like libbase58 for base58 processing on GitHub, would serve this purpose better.In the context provided, there are two minor observations regarding the libbitcoin_common.a library. Firstly, DecodeBase58Check is listed as inline in the header but is not actually inlined, making it both non-present in libbitcoin_common.a and unavailable to other code that would use it as a library. This is identified as a potential bug. Secondly, the hierarchy of tools within the library is poor/weak, with base58.h being an example of an independent low level math/string library that includes caddress, requiring chainparams and making the whole dependency tree quite involved. It is unclear whether there is an intention to strengthen and hierarchicalize the various internal libraries such that they would be suitable for third-party development of Bitcoin-related services and tools. It is also unclear if some other project would have to fill such a role. 2014-11-30T16:38:42+00:00 + In an email conversation between Btc Drak and Oliver Egginger, Egginger asks for a C library for blockchain analysis and provides a link to picocoin's library. In response, Drak suggests MatthewLM's cbitcoin as an alternative option. Egginger highlights picocoin's ability to parse raw blocks and transactions and mentions their Github repository. Drak notes that cbitcoin is a good alternative to picocoin, mentioning its features such as being valgrind-clean, supporting all core and P2P data structures, and being able to parse and index the blockchain.On November 28, 2014, Egginger sent an email asking for a C library for block chain analysis and provided a link to the picocoin repository on Github. In response, there was a suggestion of another library called cbitcoin along with a Github link.In a discussion on the Bitcoin development mailing list, Mem Wallet asked if the internal libraries of Bitcoin could be made suitable for third-party development of Bitcoin-related services and tools. Wladimir responded that the plan is to provide the consensus functionality as a library in future versions of Bitcoin, with a basic transaction/script verifier already available in version 0.10. The plan for the next version is to extend this to further utxo set management, with plans also in place to add a library for transaction signing. However, there is no goal to expose everything as a library, particularly wallet- or user interface-related functionality. Specialized utility libraries would serve this purpose better. An off-topic question was also raised regarding the use of picocoin for blockchain analysis, with Oliver seeking opinions on its limitations.A recent comment on Github suggests breaking out distinct repositories may be a good approach, but it is unclear what would be in separate repositories. Wladimir explained in response to Mem Wallet's inquiry that the plan is to provide the consensus functionality as a library, where essential parts that make Bitcoin, Bitcoin will be made available. However, not everything will be exposed as a library, and specialized utility libraries would fill this purpose better. Wladimir referenced libbase58 for base58 processing as an example. Another project broke out stealth and coinjoin as distinct repositories and made them installable using npm. The message concludes with links to Abis.io, a protocol concept for decentralization and expansion of a giving economy, and a new social good.In response to a question from Mem Wallet, Wladimir explains that the plan is to provide consensus functionality as a library, starting with a basic transaction/script verifier in version 0.10. This functionality is expected to be extended to further utxo set management in future versions, but no API has been worked out yet. There are also plans to add a library for transaction signing. However, not everything will be exposed as a library, particularly wallet- or user interface-related functionality. Specialized utility libraries, like libbase58 for base58 processing on GitHub, would serve this purpose better.In the context provided, there are two minor observations regarding the libbitcoin_common.a library. Firstly, DecodeBase58Check is listed as inline in the header but is not actually inlined, making it both non-present in libbitcoin_common.a and unavailable to other code that would use it as a library. This is identified as a potential bug. Secondly, the hierarchy of tools within the library is poor/weak, with base58.h being an example of an independent low level math/string library that includes caddress, requiring chainparams and making the whole dependency tree quite involved. It is unclear whether there is an intention to strengthen and hierarchicalize the various internal libraries such that they would be suitable for third-party development of Bitcoin-related services and tools. It is also unclear if some other project would have to fill such a role. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2014/combined_side-chains-2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml b/static/bitcoin-dev/Nov_2014/combined_side-chains-2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml index 23e2d928a9..66781f4e18 100644 --- a/static/bitcoin-dev/Nov_2014/combined_side-chains-2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml +++ b/static/bitcoin-dev/Nov_2014/combined_side-chains-2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?) - 2023-08-01T10:30:50.336112+00:00 + 2025-10-11T22:15:39.824777+00:00 + python-feedgen odinn 2014-11-03 19:38:27+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?) - 2023-08-01T10:30:50.336112+00:00 + 2025-10-11T22:15:39.824956+00:00 - The provided context includes a PGP signed message with a hash value of SHA512, containing links to two cryptography-related websites: IACR and DES. The first link leads to the proceedings of Eurocrypt 2002, a conference on cryptology, while the second link directs to the accepted papers for Asiacrypt 2014, another cryptographic conference. Within these links, there is a message from Andrew Poelstra mentioning a "false proof" without further explanation. The authenticity and integrity of the message are confirmed by the signature at the end.The discussion revolves around the distinction between hardness and likelihood of successful attack. It is explained that fraudulent transfers can occur without reorganization if an attacker produces a fake SPV proof. This type of attack does not require the attacker to own coins. However, in the absence of reorganization, the false proof will be invalidated by proof of longer work on the real chain.There is a conversation between Alex Mizrahi and an unknown person discussing the security model of sidechains. It is argued that anyone with sufficient hashpower can unlock a locked coin on the parent chain by producing an SPV proof. However, if the majority of sidechain miners continue working on the honest chain, a reorg proof can be submitted during the contest period to invalidate this "unlockment" on the parent chain. The security model of sidechains relies on the assumption that an attacker won't control a majority of the network.The article explains the concept of miners in blockchain technology and how they prove computational work to achieve stable consensus on the blockchain history. Sidechains are discussed, where anyone with sufficient hashpower can unlock a locked coin on the parent chain by producing an SPV proof. This eliminates the incentive for miners to behave honestly in sidechains as they only receive transaction fees as rewards. The security of sidechains is compared to Bitcoin's security, relying on the assumption that an attacker won't control a majority of the network.In a mailing list discussion, Alex Mizrahi criticizes a paper on sidechains as "wishful thinking," arguing that it is based on the assumption that Bitcoin's decentralized mining model is secure, which he believes may not always be true. The paper discusses hashpower attacks and reorganizations and suggests longer contest periods for transfers to make fraudulent transfers more difficult.A paper on side-chains, two-way pegs, and compact SPV proofs has been written by Blockstream, Andrew Poelstra, and Andrew Miller. However, minimal discussion of the paper's contents has occurred, other than Peter Todd's reaction on Reddit. The paper suggests that sidechains will be secure because they use DMMS (distributed market-based mechanism security), which is also used by alt-coins but not as secure as Bitcoin. The authors mention a problem with hashpower attack resistance that needs to be solved before the proposal is viable.Adam Back and his co-authors published a paper on side-chains, two-way pegs, and compact SPV proofs. The paper outlines how Bitcoin can be moved into and out of a side-chain to achieve interoperability. There is a discussion about Satoshi's whitepaper and terminology related to Bitcoin, altcoins, altchains, and blockchains. Two-way pegging is discussed as a way to enable interoperability between Bitcoin and side-chains using SPV proofs of burn. The concept of a beta network is also proposed to test new features before implementing them on the main network.Daniel Murrell posted a paper on a mailing list and requested feedback on his website. Bryan Bishop responded, suggesting that the frequency of these messages should be toned down. Jeff Garzik, a Bitcoin core developer, also participated in the discussion. The main topic of discussion is the paper and side-chains.In an email exchange, Daniel Murrell apologized for posting his paper to a mailing list and advertising it on his website. Bryan Bishop responded, suggesting that Murrell should tone down the frequency of his posts. The discussion focuses on the paper and side-chains.A person named Daniel Murrell sent a message stating that he was not trying to monetize his website but simply wanted to create something useful. Another user named Bryan responded, suggesting toning down the frequency of posts. Bryan's contact information was included in the message.The email thread discusses enabling blockchain innovations with pegged sidechains. A paper by Adam Back and other authors describes how Bitcoin can be moved into and out of side chains with different parameters or experimental features. Greg Maxwell proposed a compact way to do 2-way pegging using SPV proofs. Private chains are also discussed as a possibility for higher scaling while retaining Bitcoin security properties.The Bitcoin community has developed a process called 2-way pegging, allowing users to move Bitcoin between the main blockchain and side chains with different parameters or experimental features. The discussion involves several Bitcoin experts, including Greg Maxwell, Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach. 2014-11-03T19:38:27+00:00 + The provided context includes a PGP signed message with a hash value of SHA512, containing links to two cryptography-related websites: IACR and DES. The first link leads to the proceedings of Eurocrypt 2002, a conference on cryptology, while the second link directs to the accepted papers for Asiacrypt 2014, another cryptographic conference. Within these links, there is a message from Andrew Poelstra mentioning a "false proof" without further explanation. The authenticity and integrity of the message are confirmed by the signature at the end.The discussion revolves around the distinction between hardness and likelihood of successful attack. It is explained that fraudulent transfers can occur without reorganization if an attacker produces a fake SPV proof. This type of attack does not require the attacker to own coins. However, in the absence of reorganization, the false proof will be invalidated by proof of longer work on the real chain.There is a conversation between Alex Mizrahi and an unknown person discussing the security model of sidechains. It is argued that anyone with sufficient hashpower can unlock a locked coin on the parent chain by producing an SPV proof. However, if the majority of sidechain miners continue working on the honest chain, a reorg proof can be submitted during the contest period to invalidate this "unlockment" on the parent chain. The security model of sidechains relies on the assumption that an attacker won't control a majority of the network.The article explains the concept of miners in blockchain technology and how they prove computational work to achieve stable consensus on the blockchain history. Sidechains are discussed, where anyone with sufficient hashpower can unlock a locked coin on the parent chain by producing an SPV proof. This eliminates the incentive for miners to behave honestly in sidechains as they only receive transaction fees as rewards. The security of sidechains is compared to Bitcoin's security, relying on the assumption that an attacker won't control a majority of the network.In a mailing list discussion, Alex Mizrahi criticizes a paper on sidechains as "wishful thinking," arguing that it is based on the assumption that Bitcoin's decentralized mining model is secure, which he believes may not always be true. The paper discusses hashpower attacks and reorganizations and suggests longer contest periods for transfers to make fraudulent transfers more difficult.A paper on side-chains, two-way pegs, and compact SPV proofs has been written by Blockstream, Andrew Poelstra, and Andrew Miller. However, minimal discussion of the paper's contents has occurred, other than Peter Todd's reaction on Reddit. The paper suggests that sidechains will be secure because they use DMMS (distributed market-based mechanism security), which is also used by alt-coins but not as secure as Bitcoin. The authors mention a problem with hashpower attack resistance that needs to be solved before the proposal is viable.Adam Back and his co-authors published a paper on side-chains, two-way pegs, and compact SPV proofs. The paper outlines how Bitcoin can be moved into and out of a side-chain to achieve interoperability. There is a discussion about Satoshi's whitepaper and terminology related to Bitcoin, altcoins, altchains, and blockchains. Two-way pegging is discussed as a way to enable interoperability between Bitcoin and side-chains using SPV proofs of burn. The concept of a beta network is also proposed to test new features before implementing them on the main network.Daniel Murrell posted a paper on a mailing list and requested feedback on his website. Bryan Bishop responded, suggesting that the frequency of these messages should be toned down. Jeff Garzik, a Bitcoin core developer, also participated in the discussion. The main topic of discussion is the paper and side-chains.In an email exchange, Daniel Murrell apologized for posting his paper to a mailing list and advertising it on his website. Bryan Bishop responded, suggesting that Murrell should tone down the frequency of his posts. The discussion focuses on the paper and side-chains.A person named Daniel Murrell sent a message stating that he was not trying to monetize his website but simply wanted to create something useful. Another user named Bryan responded, suggesting toning down the frequency of posts. Bryan's contact information was included in the message.The email thread discusses enabling blockchain innovations with pegged sidechains. A paper by Adam Back and other authors describes how Bitcoin can be moved into and out of side chains with different parameters or experimental features. Greg Maxwell proposed a compact way to do 2-way pegging using SPV proofs. Private chains are also discussed as a possibility for higher scaling while retaining Bitcoin security properties.The Bitcoin community has developed a process called 2-way pegging, allowing users to move Bitcoin between the main blockchain and side chains with different parameters or experimental features. The discussion involves several Bitcoin experts, including Greg Maxwell, Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_-BIP-Draft-Datastream-compression-of-Blocks-and-Transactions.xml b/static/bitcoin-dev/Nov_2015/combined_-BIP-Draft-Datastream-compression-of-Blocks-and-Transactions.xml index 688f71a76c..814b43db01 100644 --- a/static/bitcoin-dev/Nov_2015/combined_-BIP-Draft-Datastream-compression-of-Blocks-and-Transactions.xml +++ b/static/bitcoin-dev/Nov_2015/combined_-BIP-Draft-Datastream-compression-of-Blocks-and-Transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP Draft] Datastream compression of Blocks and Transactions - 2023-08-01T16:57:46.530241+00:00 + 2025-10-11T22:16:11.702032+00:00 + python-feedgen Matt Corallo 2015-12-04 13:30:33+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - [BIP Draft] Datastream compression of Blocks and Transactions - 2023-08-01T16:57:46.531240+00:00 + 2025-10-11T22:16:11.702206+00:00 - In a Bitcoin developer mailing list, concerns were raised about the potential complexity and attack surface that may come with implementing the Lempel-Ziv (LZ) family of compressors. Despite the minor compression gain of 15 to 27%, it was suggested that syncing over slow or restrictive connections could be better addressed by a sync-over-http-via-cdn protocol. However, arguments were made in favor of compression, stating that larger data sizes benefit from better compression and that adding compression could be easily turned off if necessary.The discussion also touched on the limitations of the LZ family of compressors for binary data like the Bitcoin wire protocol. It was proposed that a custom, Bitcoin-aware compressor could achieve significantly higher compression ratios of 2X or more in some cases. However, concerns were raised about the maintainability and potential difficulties in changing the wire format later on. Despite these concerns, the idea of compressing Bitcoin was seen as an opportunity for free improvements and additional throughput without any cost.A programming challenge/contest was suggested as one way to find the best possible, Bitcoin-specific compressor. This would not only lead to potential improvements but also bring new programmers into the ecosystem. The idea of building a standardized dataset using real data from the network to test against was also discussed, allowing for measurements of proposed optimizations.Another email conversation proposed the idea of adding compression directly accessible to the network on financial software. While there were concerns about security issues, it was argued that the LZO compressor has been around for 20 years with few problems. The performance improvement through compression was shown to increase as block sizes increased, making it beneficial for transmission but not for post-processing and validating blocks.Further discussions highlighted the potential benefits of a custom, Bitcoin-specific compressor compared to the existing LZ family of compressors. While LZ compressors assign unique numbers to subsequence encounters, they are not as efficient for binary data like Bitcoin. Building a custom compressor could lead to higher compression ratios, although there are considerations regarding maintainability and potential difficulties in changing the wire format. The idea of a programming challenge/contest to find the best possible Bitcoin-specific compressor was seen as an effective way to discover the limits of compressibility and bring in new programmers.The email exchanges also addressed concerns about the security of compression libraries and the possibility of exposing them to potential attackers. Various suggestions were made, such as isolating the decompression phase and verifying block hashes through external processes or daemons.In summary, there is ongoing discussion among Bitcoin developers regarding the implementation of compression for Bitcoin data transmission. While there are concerns about complexity, attack surface, and potential security issues, there is also recognition of the potential benefits in terms of improved performance and additional throughput. The idea of a custom, Bitcoin-specific compressor has been proposed, along with the suggestion of a programming challenge/contest to find the best possible solution. Overall, the goal is to find the most efficient and secure method of compressing Bitcoin data to enhance network efficiency and scalability. 2015-12-04T13:30:33+00:00 + In a Bitcoin developer mailing list, concerns were raised about the potential complexity and attack surface that may come with implementing the Lempel-Ziv (LZ) family of compressors. Despite the minor compression gain of 15 to 27%, it was suggested that syncing over slow or restrictive connections could be better addressed by a sync-over-http-via-cdn protocol. However, arguments were made in favor of compression, stating that larger data sizes benefit from better compression and that adding compression could be easily turned off if necessary.The discussion also touched on the limitations of the LZ family of compressors for binary data like the Bitcoin wire protocol. It was proposed that a custom, Bitcoin-aware compressor could achieve significantly higher compression ratios of 2X or more in some cases. However, concerns were raised about the maintainability and potential difficulties in changing the wire format later on. Despite these concerns, the idea of compressing Bitcoin was seen as an opportunity for free improvements and additional throughput without any cost.A programming challenge/contest was suggested as one way to find the best possible, Bitcoin-specific compressor. This would not only lead to potential improvements but also bring new programmers into the ecosystem. The idea of building a standardized dataset using real data from the network to test against was also discussed, allowing for measurements of proposed optimizations.Another email conversation proposed the idea of adding compression directly accessible to the network on financial software. While there were concerns about security issues, it was argued that the LZO compressor has been around for 20 years with few problems. The performance improvement through compression was shown to increase as block sizes increased, making it beneficial for transmission but not for post-processing and validating blocks.Further discussions highlighted the potential benefits of a custom, Bitcoin-specific compressor compared to the existing LZ family of compressors. While LZ compressors assign unique numbers to subsequence encounters, they are not as efficient for binary data like Bitcoin. Building a custom compressor could lead to higher compression ratios, although there are considerations regarding maintainability and potential difficulties in changing the wire format. The idea of a programming challenge/contest to find the best possible Bitcoin-specific compressor was seen as an effective way to discover the limits of compressibility and bring in new programmers.The email exchanges also addressed concerns about the security of compression libraries and the possibility of exposing them to potential attackers. Various suggestions were made, such as isolating the decompression phase and verifying block hashes through external processes or daemons.In summary, there is ongoing discussion among Bitcoin developers regarding the implementation of compression for Bitcoin data transmission. While there are concerns about complexity, attack surface, and potential security issues, there is also recognition of the potential benefits in terms of improved performance and additional throughput. The idea of a custom, Bitcoin-specific compressor has been proposed, along with the suggestion of a programming challenge/contest to find the best possible solution. Overall, the goal is to find the most efficient and secure method of compressing Bitcoin data to enhance network efficiency and scalability. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_-BIP-Normalized-transaction-IDs.xml b/static/bitcoin-dev/Nov_2015/combined_-BIP-Normalized-transaction-IDs.xml index 520aeddb34..3d93fdbeb6 100644 --- a/static/bitcoin-dev/Nov_2015/combined_-BIP-Normalized-transaction-IDs.xml +++ b/static/bitcoin-dev/Nov_2015/combined_-BIP-Normalized-transaction-IDs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP] Normalized transaction IDs - 2023-08-01T16:41:42.999183+00:00 + 2025-10-11T22:16:41.444736+00:00 + python-feedgen Christian Decker 2015-11-06 14:52:49+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - [BIP] Normalized transaction IDs - 2023-08-01T16:41:43.000706+00:00 + 2025-10-11T22:16:41.444917+00:00 - In an email exchange, Jorge Timón and Christian Decker discuss the issue of malleability in Bitcoin transactions. They argue that there is confusion between conflicting spends and signature malleability, and Segregated Witnesses could solve the latter. However, they agree that a good migration plan for Bitcoin needs to be found.The discussion highlights that wallets are addressing malleability in acceptable ways but face problems with second and third level malleability. For example, if an unconfirmed transaction's ID changes due to malleability, subsequent transactions become invalid. Additionally, certain types of contracts are not fully safe due to malleability.The authors disagree on the significance of "signature malleability," with one asserting its importance and the other suggesting it is not problematic.A proposed solution involves creating a new public key type, address type, and signature type to prevent double spending via simultaneous equation. However, this solution does not enforce no pubkey reuse and may put pressure on transactional storage.Luke Dashjr and an anonymous speaker discuss the issue of "signature malleability." While one believes it is not a problem, the other argues that segregated witnesses can solve it and be useful in practical cases. They also note the importance of looking at scriptPubKeys instead of transaction IDs.In a Bitcoin-dev mailing list conversation, confusion arises regarding the term "malleability" and its scope. Some argue that it only applies to signature malleability, while others argue that conflicting spends should also be addressed. Ultimately, it is agreed upon that all forms of malleability should be addressed in any practical solution.Luke Dashjr and Christian Decker discuss the issue of malleability in Bitcoin. They discuss the problem of single signers double-spending their outputs and the limitations of segregated witnesses in solving this issue. They also discuss the definition of malleability and its implications for Bitcoin transactions.The conversation discusses a solution for the normalization issue in the Bitcoin network. The proposed solution involves having a connected component of upgraded nodes that relay both the transaction and associated external scripts. Non-upgraded nodes will only parse the classical transaction, dropping the external script. To ensure this solution works, a long rollout phase before activation is suggested.Christian Decker proposes a solution for malleability in Bitcoin transactions, involving piggybacking external scripts onto normal messages. Non-upgraded nodes will ignore the external script. Luke Dashjr suggests enforcing no-address-reuse rule on received payments to make an anti-malleable wallet. However, this does not address the issue of double spending unconfirmed outputs.Luke Dashjr and Christian Decker discuss the idea of having empty scriptsigs and shipping signatures in external scripts. The proposal uses on-the-fly normalization, but a better solution is sought. Luke suggests making wallets add more outputs to unconfirmed transactions instead of spending unconfirmed change.Christian Decker discusses piggybacking external scripts onto normal messages in Bitcoin transactions. Non-upgraded nodes will read the entire message but only parse the classical transaction, ignoring the external script. He is open to suggestions for a better solution. A possible upgrade for wallets is also mentioned.Christian Decker provides an update on the proposed Bitcoin Improvement Proposal (BIP), mentioning changes made to the proposal. He expresses doubt about fixing malleability and asks about the perfect properties for such a fix. Luke Dashjr argues that wallets should add more outputs to unconfirmed transactions. Gregory Maxwell cautions against overselling certain ideas.The discussions on normalized transaction IDs within smart contracts continue. Suggestions are made regarding treating singlesig transactions as 1-of-1 transactions and using Schnorr signatures. The bitmap of flags could be replaced with a simple version number. However, caution is advised in overselling these ideas.In an email thread, Christian Decker comments on the scenario of a single signer re-ordering the outputs and inputs of a transaction. He believes that even with a canonical ordering, this action could still occur. Luke argues that wallets should add more outputs to unconfirmed transactions.In 2015, Christian Decker proposed a new implementation for normalized transaction IDs and storing them with coin state. However, Luke Dashjr expressed concern that this proposal doesn't completely close malleability and suggested specifying flags upfront in the UTXO-creating transaction to allow for fully malleability-proof wallets. He also pointed out that the flag to control whether the opcode behaves as VERIFY or not must be mandatory to guarantee successful evaluation on non-updated clients.The discussion revolves around the issue of malleability in Bitcoin transactions. While some believe that specifying flags upfront in the UTXO-creating transaction could allow for implementation of fully malleability-proof wallets, others argue that the use of non-sighash_all flags still poses a threat to the security of transactions. Signer malleability is also a concern needing consideration, and it is suggested that wallets should actively CoinJoin, bump fees on, etc any pending transactions in the background to prevent these 2015-11-06T14:52:49+00:00 + In an email exchange, Jorge Timón and Christian Decker discuss the issue of malleability in Bitcoin transactions. They argue that there is confusion between conflicting spends and signature malleability, and Segregated Witnesses could solve the latter. However, they agree that a good migration plan for Bitcoin needs to be found.The discussion highlights that wallets are addressing malleability in acceptable ways but face problems with second and third level malleability. For example, if an unconfirmed transaction's ID changes due to malleability, subsequent transactions become invalid. Additionally, certain types of contracts are not fully safe due to malleability.The authors disagree on the significance of "signature malleability," with one asserting its importance and the other suggesting it is not problematic.A proposed solution involves creating a new public key type, address type, and signature type to prevent double spending via simultaneous equation. However, this solution does not enforce no pubkey reuse and may put pressure on transactional storage.Luke Dashjr and an anonymous speaker discuss the issue of "signature malleability." While one believes it is not a problem, the other argues that segregated witnesses can solve it and be useful in practical cases. They also note the importance of looking at scriptPubKeys instead of transaction IDs.In a Bitcoin-dev mailing list conversation, confusion arises regarding the term "malleability" and its scope. Some argue that it only applies to signature malleability, while others argue that conflicting spends should also be addressed. Ultimately, it is agreed upon that all forms of malleability should be addressed in any practical solution.Luke Dashjr and Christian Decker discuss the issue of malleability in Bitcoin. They discuss the problem of single signers double-spending their outputs and the limitations of segregated witnesses in solving this issue. They also discuss the definition of malleability and its implications for Bitcoin transactions.The conversation discusses a solution for the normalization issue in the Bitcoin network. The proposed solution involves having a connected component of upgraded nodes that relay both the transaction and associated external scripts. Non-upgraded nodes will only parse the classical transaction, dropping the external script. To ensure this solution works, a long rollout phase before activation is suggested.Christian Decker proposes a solution for malleability in Bitcoin transactions, involving piggybacking external scripts onto normal messages. Non-upgraded nodes will ignore the external script. Luke Dashjr suggests enforcing no-address-reuse rule on received payments to make an anti-malleable wallet. However, this does not address the issue of double spending unconfirmed outputs.Luke Dashjr and Christian Decker discuss the idea of having empty scriptsigs and shipping signatures in external scripts. The proposal uses on-the-fly normalization, but a better solution is sought. Luke suggests making wallets add more outputs to unconfirmed transactions instead of spending unconfirmed change.Christian Decker discusses piggybacking external scripts onto normal messages in Bitcoin transactions. Non-upgraded nodes will read the entire message but only parse the classical transaction, ignoring the external script. He is open to suggestions for a better solution. A possible upgrade for wallets is also mentioned.Christian Decker provides an update on the proposed Bitcoin Improvement Proposal (BIP), mentioning changes made to the proposal. He expresses doubt about fixing malleability and asks about the perfect properties for such a fix. Luke Dashjr argues that wallets should add more outputs to unconfirmed transactions. Gregory Maxwell cautions against overselling certain ideas.The discussions on normalized transaction IDs within smart contracts continue. Suggestions are made regarding treating singlesig transactions as 1-of-1 transactions and using Schnorr signatures. The bitmap of flags could be replaced with a simple version number. However, caution is advised in overselling these ideas.In an email thread, Christian Decker comments on the scenario of a single signer re-ordering the outputs and inputs of a transaction. He believes that even with a canonical ordering, this action could still occur. Luke argues that wallets should add more outputs to unconfirmed transactions.In 2015, Christian Decker proposed a new implementation for normalized transaction IDs and storing them with coin state. However, Luke Dashjr expressed concern that this proposal doesn't completely close malleability and suggested specifying flags upfront in the UTXO-creating transaction to allow for fully malleability-proof wallets. He also pointed out that the flag to control whether the opcode behaves as VERIFY or not must be mandatory to guarantee successful evaluation on non-updated clients.The discussion revolves around the issue of malleability in Bitcoin transactions. While some believe that specifying flags upfront in the UTXO-creating transaction could allow for implementation of fully malleability-proof wallets, others argue that the use of non-sighash_all flags still poses a threat to the security of transactions. Signer malleability is also a concern needing consideration, and it is suggested that wallets should actively CoinJoin, bump fees on, etc any pending transactions in the background to prevent these - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_-BIP-OP-CHECKPRIVPUBPAIR.xml b/static/bitcoin-dev/Nov_2015/combined_-BIP-OP-CHECKPRIVPUBPAIR.xml index d05e421056..ce768c6d51 100644 --- a/static/bitcoin-dev/Nov_2015/combined_-BIP-OP-CHECKPRIVPUBPAIR.xml +++ b/static/bitcoin-dev/Nov_2015/combined_-BIP-OP-CHECKPRIVPUBPAIR.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP] OP_CHECKPRIVPUBPAIR - 2023-08-01T16:55:54.181027+00:00 + 2025-10-11T22:15:48.333480+00:00 + python-feedgen Anthony Towns 2015-11-29 23:41:43+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - [BIP] OP_CHECKPRIVPUBPAIR - 2023-08-01T16:55:54.181027+00:00 + 2025-10-11T22:15:48.333610+00:00 - In a bitcoin-dev mailing list discussion on November 27, 2015, Mats Jerratsch proposed the introduction of a new general OP_CRYPTO to enable various types of crypto operations in script. His suggestion involved using a prefixed 0x01 byte to push "OP_CRYPTO" onto the stack, with OP_CRYPTO examining the top item on the stack to determine its action. This proposal would not require a softfork and could allow for expandable multi-byte pushes. Jerratsch also discussed certain constructions that could potentially disrupt the signature scheme but were either too large or costly to compute.As a response, it was suggested to include additional crypto ops into a BIP (Bitcoin Improvement Proposal) for a check-verify crypto toolkit op. Practical uses in the near future were mentioned for base-point multiply on secp256k1 (CHECKPUBPRIVPAIR) and Schnorr-signature of transaction with secp256k1 curve (smaller, faster, more-anonymous N-of-N multisig). Other suggestions included general point addition/multiply on secp256k1, SHA3-256/SHA2-512/SHA3-512, and ECDSA/Schnorr signature of value from stack. It was also noted that if the segregated witness soft-fork is feasible, any opcode could be re-enabled/changed/added as a soft-fork, not just converting a NOP into CHECK_foo_VERIFY. Therefore, it was recommended to observe the progress of the segregated witness soft-fork before drafting a BIP or similar proposal.Furthermore, onion-routing has been proposed as a means to enhance privacy while utilizing a payment network. In this approach, each node only knows the preceding and succeeding node in the payment route, without having information about its position, the payer, or the payee. However, the use of preimage-hash pair R-H in payments within the network can compromise privacy by reducing the number of nodes an attacker needs to control. To address this issue, it was suggested to employ private/public EC key pairs instead of RIPEMD-160 for preimage-hash construction. This would require a method to derive a private key from a public key on the blockchain. One possible approach is to utilize one of the currently unused OP_NOP codes, allowing for deployment through a softfork. Alternatively, a Non-Interactive Zero-Knowledge Proof (NIZKP) can be used to demonstrate that a node can recover a preimage based on certain information, but these calculations are computationally expensive. 2015-11-29T23:41:43+00:00 + In a bitcoin-dev mailing list discussion on November 27, 2015, Mats Jerratsch proposed the introduction of a new general OP_CRYPTO to enable various types of crypto operations in script. His suggestion involved using a prefixed 0x01 byte to push "OP_CRYPTO" onto the stack, with OP_CRYPTO examining the top item on the stack to determine its action. This proposal would not require a softfork and could allow for expandable multi-byte pushes. Jerratsch also discussed certain constructions that could potentially disrupt the signature scheme but were either too large or costly to compute.As a response, it was suggested to include additional crypto ops into a BIP (Bitcoin Improvement Proposal) for a check-verify crypto toolkit op. Practical uses in the near future were mentioned for base-point multiply on secp256k1 (CHECKPUBPRIVPAIR) and Schnorr-signature of transaction with secp256k1 curve (smaller, faster, more-anonymous N-of-N multisig). Other suggestions included general point addition/multiply on secp256k1, SHA3-256/SHA2-512/SHA3-512, and ECDSA/Schnorr signature of value from stack. It was also noted that if the segregated witness soft-fork is feasible, any opcode could be re-enabled/changed/added as a soft-fork, not just converting a NOP into CHECK_foo_VERIFY. Therefore, it was recommended to observe the progress of the segregated witness soft-fork before drafting a BIP or similar proposal.Furthermore, onion-routing has been proposed as a means to enhance privacy while utilizing a payment network. In this approach, each node only knows the preceding and succeeding node in the payment route, without having information about its position, the payer, or the payee. However, the use of preimage-hash pair R-H in payments within the network can compromise privacy by reducing the number of nodes an attacker needs to control. To address this issue, it was suggested to employ private/public EC key pairs instead of RIPEMD-160 for preimage-hash construction. This would require a method to derive a private key from a public key on the blockchain. One possible approach is to utilize one of the currently unused OP_NOP codes, allowing for deployment through a softfork. Alternatively, a Non-Interactive Zero-Knowledge Proof (NIZKP) can be used to demonstrate that a node can recover a preimage based on certain information, but these calculations are computationally expensive. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_-patch-Switching-Bitcoin-Core-to-sqlite-db.xml b/static/bitcoin-dev/Nov_2015/combined_-patch-Switching-Bitcoin-Core-to-sqlite-db.xml index 9d960dfae7..678a8fbd36 100644 --- a/static/bitcoin-dev/Nov_2015/combined_-patch-Switching-Bitcoin-Core-to-sqlite-db.xml +++ b/static/bitcoin-dev/Nov_2015/combined_-patch-Switching-Bitcoin-Core-to-sqlite-db.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [patch] Switching Bitcoin Core to sqlite db - 2023-08-01T16:45:02.908700+00:00 + 2025-10-11T22:15:54.711994+00:00 + python-feedgen Jorge Timón 2015-11-20 14:15:20+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - [patch] Switching Bitcoin Core to sqlite db - 2023-08-01T16:45:02.909734+00:00 + 2025-10-11T22:15:54.712214+00:00 - The discussions focused on the issue of consensus failures in Bitcoin. There are two types of consensus failures to consider: Type 1, where one implementation says "yes" or "no" while the other says "I don't know," and Type 2, where one implementation says "yes" and the other says "no" due to a bug. It was suggested that multiple competing implementations should be used to address these issues. In the event of a Type 2 failure, it was proposed that Core should accept a rogue transaction that creates more bitcoins and allow other implementations to fork away from it. The conversation also touched on the classification of consensus failures and the philosophical aspects of Bitcoin governance.In another discussion, the use of RocksDB as a replacement for LevelDB in Bitcoin was mentioned. While RocksDB is optimized for big databases running on multiple cores, concerns were raised about its suitability for spinning disks. The reliability of LevelDB was also discussed, with participants expressing their intention to explore alternative options due to bugs and reliability issues. Despite its challenges, LevelDB has remained popular among Bitcoin developers for its simplicity and ease of use.The importance of UTXO storage in Bitcoin was emphasized, as the choice of database technology can impact consensus protocol failure. Consistency between all nodes was deemed more important than having "right" UTXO storage. Inconsistencies in database behavior can lead to inconsistencies in consensus state and potential theft. The need for vigilance in identifying possible errors and ensuring equivalence under all inputs was highlighted.Bitcoin Unlimited explored the concept of "meta-cognition" to decentralize development and promote bottom-up governance. The conversation discussed the challenges of using multiple database technologies in Bitcoin and the potential for inconsistencies in determining the validity of transactions across nodes.Jeff Garzik has started working on an implementation to replace LevelDB with SQLite. The implementation is still a work in progress and needs further testing. It has been suggested that instead of implementing it as a replacement, multiple backends should be supported to allow for migration. The author also recommends considering LMDB as an alternative, but notes its limitations on 32-bit systems requiring over 2gb of storage.Overall, the Bitcoin project is actively exploring alternatives to the unmaintained LevelDB database. Jeff Garzik's implementation to replace LevelDB with SQLite is currently underway, but still needs further testing and refinement. The goal is to find a maintained and reliable alternative to LevelDB. 2015-11-20T14:15:20+00:00 + The discussions focused on the issue of consensus failures in Bitcoin. There are two types of consensus failures to consider: Type 1, where one implementation says "yes" or "no" while the other says "I don't know," and Type 2, where one implementation says "yes" and the other says "no" due to a bug. It was suggested that multiple competing implementations should be used to address these issues. In the event of a Type 2 failure, it was proposed that Core should accept a rogue transaction that creates more bitcoins and allow other implementations to fork away from it. The conversation also touched on the classification of consensus failures and the philosophical aspects of Bitcoin governance.In another discussion, the use of RocksDB as a replacement for LevelDB in Bitcoin was mentioned. While RocksDB is optimized for big databases running on multiple cores, concerns were raised about its suitability for spinning disks. The reliability of LevelDB was also discussed, with participants expressing their intention to explore alternative options due to bugs and reliability issues. Despite its challenges, LevelDB has remained popular among Bitcoin developers for its simplicity and ease of use.The importance of UTXO storage in Bitcoin was emphasized, as the choice of database technology can impact consensus protocol failure. Consistency between all nodes was deemed more important than having "right" UTXO storage. Inconsistencies in database behavior can lead to inconsistencies in consensus state and potential theft. The need for vigilance in identifying possible errors and ensuring equivalence under all inputs was highlighted.Bitcoin Unlimited explored the concept of "meta-cognition" to decentralize development and promote bottom-up governance. The conversation discussed the challenges of using multiple database technologies in Bitcoin and the potential for inconsistencies in determining the validity of transactions across nodes.Jeff Garzik has started working on an implementation to replace LevelDB with SQLite. The implementation is still a work in progress and needs further testing. It has been suggested that instead of implementing it as a replacement, multiple backends should be supported to allow for migration. The author also recommends considering LMDB as an alternative, but notes its limitations on 32-bit systems requiring over 2gb of storage.Overall, the Bitcoin project is actively exploring alternatives to the unmaintained LevelDB database. Jeff Garzik's implementation to replace LevelDB with SQLite is currently underway, but still needs further testing and refinement. The goal is to find a maintained and reliable alternative to LevelDB. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_A-validation-cost-metric-for-aggregate-limits-and-fee-determination.xml b/static/bitcoin-dev/Nov_2015/combined_A-validation-cost-metric-for-aggregate-limits-and-fee-determination.xml index 35e937e64c..beccc68b7f 100644 --- a/static/bitcoin-dev/Nov_2015/combined_A-validation-cost-metric-for-aggregate-limits-and-fee-determination.xml +++ b/static/bitcoin-dev/Nov_2015/combined_A-validation-cost-metric-for-aggregate-limits-and-fee-determination.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A validation-cost metric for aggregate limits and fee determination - 2023-08-01T16:48:19.881401+00:00 + 2025-10-11T22:16:01.085677+00:00 + python-feedgen Gavin Andresen 2015-11-05 09:23:44+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - A validation-cost metric for aggregate limits and fee determination - 2023-08-01T16:48:19.881401+00:00 + 2025-10-11T22:16:01.085768+00:00 - In this context, the author discusses the problem of measuring CPU and bandwidth costs for validating a block. They propose using a common unit of measurement, which is the "percentage of maximum validation ability for some reference hardware running with a network connection capable of some reference bandwidth." This unit will be used to measure the CPU and bandwidth costs.The author also addresses the issue of measuring UTXO (Unspent Transaction Output) growth, which can be negative or positive. To overcome this challenge, they suggest choosing a reasonable growth rate and expressing the actual UTXO growth as a percentage of the maximum allowed. This percentage is then combined with the CPU and bandwidth percentages to determine if the block is valid.Furthermore, the author considers whether miners or wallets need to solve a bin-packing problem to determine which transactions to include in their blocks and what fees to attach. They propose using a fee-per-validation-cost approach instead of fee-per-kilobyte. However, they note that transactions creating more UTXOs than they spend may incur higher costs.To address these challenges, the author suggests breaking down the cost into three components: UTXO growth, CPU, and bandwidth. Miners can then set reasonable transaction selection policies that keep each of these components under the imposed caps.During the first Scaling Bitcoin workshop in Montreal, a presentation highlighted the issue of "bad blocks" that take too long to validate. The presenter discussed how the system's design parameters assume linear scaling of validation costs with transaction or block size. However, certain types of transactions have quadratic scaling validation costs, creating gaps between average-case and worst-case validation costs.Various solutions, such as Gavin's code, have been proposed to track bytes hashed and enforce separate limits for blocks. However, these solutions still leave gaps between average-case and worst-case validation costs. Additionally, transaction selection and fee determination become more complex.The presenter suggests using a linear function of the different costs involved to determine the "size" of a transaction. Others have suggested using a "net-UTXO" metric, which applies an extra fee for creating unspent outputs. This approach makes small dust outputs significantly more expensive than regular spend outputs. However, it also widens the gap between average and worst-case block validation times.The presenter plans to submit a talk proposal for Scaling Bitcoin on this topic and welcomes feedback from the developer community. 2015-11-05T09:23:44+00:00 + In this context, the author discusses the problem of measuring CPU and bandwidth costs for validating a block. They propose using a common unit of measurement, which is the "percentage of maximum validation ability for some reference hardware running with a network connection capable of some reference bandwidth." This unit will be used to measure the CPU and bandwidth costs.The author also addresses the issue of measuring UTXO (Unspent Transaction Output) growth, which can be negative or positive. To overcome this challenge, they suggest choosing a reasonable growth rate and expressing the actual UTXO growth as a percentage of the maximum allowed. This percentage is then combined with the CPU and bandwidth percentages to determine if the block is valid.Furthermore, the author considers whether miners or wallets need to solve a bin-packing problem to determine which transactions to include in their blocks and what fees to attach. They propose using a fee-per-validation-cost approach instead of fee-per-kilobyte. However, they note that transactions creating more UTXOs than they spend may incur higher costs.To address these challenges, the author suggests breaking down the cost into three components: UTXO growth, CPU, and bandwidth. Miners can then set reasonable transaction selection policies that keep each of these components under the imposed caps.During the first Scaling Bitcoin workshop in Montreal, a presentation highlighted the issue of "bad blocks" that take too long to validate. The presenter discussed how the system's design parameters assume linear scaling of validation costs with transaction or block size. However, certain types of transactions have quadratic scaling validation costs, creating gaps between average-case and worst-case validation costs.Various solutions, such as Gavin's code, have been proposed to track bytes hashed and enforce separate limits for blocks. However, these solutions still leave gaps between average-case and worst-case validation costs. Additionally, transaction selection and fee determination become more complex.The presenter suggests using a linear function of the different costs involved to determine the "size" of a transaction. Others have suggested using a "net-UTXO" metric, which applies an extra fee for creating unspent outputs. This approach makes small dust outputs significantly more expensive than regular spend outputs. However, it also widens the gap between average and worst-case block validation times.The presenter plans to submit a talk proposal for Scaling Bitcoin on this topic and welcomes feedback from the developer community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Ads-on-bitcoin-org-website.xml b/static/bitcoin-dev/Nov_2015/combined_Ads-on-bitcoin-org-website.xml index 24b17da57d..bb654fca3e 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Ads-on-bitcoin-org-website.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Ads-on-bitcoin-org-website.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ads on bitcoin.org website - 2023-08-01T16:51:20.119953+00:00 + 2025-10-11T22:16:45.694864+00:00 + python-feedgen David A. Harding 2015-11-13 15:59:16+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Ads on bitcoin.org website - 2023-08-01T16:51:20.119953+00:00 + 2025-10-11T22:16:45.695015+00:00 - A concern has been raised by Jonas Schnelli, via bitcoin-dev, regarding the future of Bitcoin.org. As Bitcoin.org is responsible for hosting the Bitcoin Core binaries mentioned in release announcements, it is deemed relevant to discuss this topic on bitcoin-dev. However, it has been suggested that inquiries about the operations of Bitcoin.org should be directed to bitcoin-discuss, while issues related to advertising should be addressed through the referenced PRs. Dave, one of the maintainers of Bitcoin.org, has provided several suggestions in response, including joining bitcoin-discuss to ask questions, opening a GitHub issue to discuss advertising on the site, and exploring the possibility of relocating the Bitcoin Core binaries if there is general dissatisfaction with the addition of advertisements. Links to both bitcoin-discuss and the GitHub issue have been provided.Recently, the author of a post on Bitcoin.org expressed concerns about the neutrality of the site. The author emphasizes the importance of maintaining an unbiased platform for information on bitcoin, its applications, and exchanges. Criticism is directed towards the merging of a pull request (PR) that would introduce Google Analytics to the site, as the author believes this action contradicts the principles of determining who holds control over bitcoin and violates the underlying philosophy of bitcoin. Furthermore, the author highlights another PR that, if merged, would enable ads on Bitcoin.org, arguing that such a move would undermine the site's commitment to neutrality. Questioning how changes are implemented on Bitcoin.org, the author seeks clarification on whether decisions are made based on consensus among contributors or if a select group determines which changes are incorporated and which are not. To address the issue of site operators or contributors requiring compensation for their work or infrastructure expenses, the author suggests tackling the root problem and raising funds for these purposes. Additionally, the author offers assistance in reaching out to bitcoin businesses and individuals to facilitate fundraising efforts. 2015-11-13T15:59:16+00:00 + A concern has been raised by Jonas Schnelli, via bitcoin-dev, regarding the future of Bitcoin.org. As Bitcoin.org is responsible for hosting the Bitcoin Core binaries mentioned in release announcements, it is deemed relevant to discuss this topic on bitcoin-dev. However, it has been suggested that inquiries about the operations of Bitcoin.org should be directed to bitcoin-discuss, while issues related to advertising should be addressed through the referenced PRs. Dave, one of the maintainers of Bitcoin.org, has provided several suggestions in response, including joining bitcoin-discuss to ask questions, opening a GitHub issue to discuss advertising on the site, and exploring the possibility of relocating the Bitcoin Core binaries if there is general dissatisfaction with the addition of advertisements. Links to both bitcoin-discuss and the GitHub issue have been provided.Recently, the author of a post on Bitcoin.org expressed concerns about the neutrality of the site. The author emphasizes the importance of maintaining an unbiased platform for information on bitcoin, its applications, and exchanges. Criticism is directed towards the merging of a pull request (PR) that would introduce Google Analytics to the site, as the author believes this action contradicts the principles of determining who holds control over bitcoin and violates the underlying philosophy of bitcoin. Furthermore, the author highlights another PR that, if merged, would enable ads on Bitcoin.org, arguing that such a move would undermine the site's commitment to neutrality. Questioning how changes are implemented on Bitcoin.org, the author seeks clarification on whether decisions are made based on consensus among contributors or if a select group determines which changes are incorporated and which are not. To address the issue of site operators or contributors requiring compensation for their work or infrastructure expenses, the author suggests tackling the root problem and raising funds for these purposes. Additionally, the author offers assistance in reaching out to bitcoin businesses and individuals to facilitate fundraising efforts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Alternative-name-for-CHECKSEQUENCEVERIFY-BIP112-.xml b/static/bitcoin-dev/Nov_2015/combined_Alternative-name-for-CHECKSEQUENCEVERIFY-BIP112-.xml index a5e582967d..018c394afc 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Alternative-name-for-CHECKSEQUENCEVERIFY-BIP112-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Alternative-name-for-CHECKSEQUENCEVERIFY-BIP112-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Alternative name for CHECKSEQUENCEVERIFY (BIP112) - 2023-08-01T16:54:45.616066+00:00 + 2025-10-11T22:16:49.943721+00:00 + python-feedgen Jorge Timón 2015-11-27 10:14:10+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Alternative name for CHECKSEQUENCEVERIFY (BIP112) - 2023-08-01T16:54:45.616066+00:00 + 2025-10-11T22:16:49.943871+00:00 - In an email thread on the bitcoin-dev mailing list, Mark Friedenbach expressed his objection to the use of nSequence in Bitcoin's implementation. He suggested renaming it to nMaturity, a suggestion he had previously made before the implementation began. However, he acknowledged that it was now too late to make such changes without disrupting the implementation. The discussion focuses on the relative locktime (or minimum age) and the nSequence field in transactions, which currently plays a combined role. The lack of a dedicated field for the purpose of relative locktime is considered unfortunate as it requires repurposing unused bits in the txin. However, there may be ways around this issue using segwit.One suggestion is to add an extra input vector to the prunable extra data that comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash. Adding extra prunable signed data fields to transactions may ultimately remove scarcity of tx data that can be repurposed via soft forks. The nSequence field could be turned into a dedicated min age/rlt field to simplify semantics and avoid ugliness in trying to reclaim unused bits.The article discusses the limited availability of single-byte opcodes left, with only ten single-byte OP_NOPx opcodes defined. Additionally, there are 66 single-byte values that are currently reserved. The author argues that it seems trivial to him to add a comment in script.h, which would neither slow compilation nor confuse anyone but could lead the curious to explore history and expand their knowledge. The article also talks about the name OP_CHECKSEQUENCEVERIFY, which should not be changed. The author explains that each person has a single best reason not to change it, and finding other reasons suggests that one's top reason is not good enough. Moreover, the article highlights that the same goes for changing it. In any case, it is 178 (0xb2), and app developers can call it whatever they want.Eric Lombrozo, a developer, believes that relative timelock is the most important exposed functionality intended for app developers. He also agrees with Mark and Matt that the relative locktime feature is not in the CSV opcode but in the nSequence calculation. Rusty, who developed scripts using CSV, supports keeping CSV as it is.In a bitcoin-dev email thread, Eric Lombrozo proposed that the full opcode name for CHECKRELATIVELOCKTIMEVERIFY should be abbreviated. He suggested using both CLTV and CRLTV for abbreviation, however, these abbreviations are hard to distinguish from each other. Peter Todd suggested using the abbreviation AGEVERIFY instead, which is short and sweet.The discussion in the bitcoin-dev mailing list revolves around the naming of the opcode for BIP112, which verifies the time/maturity of transaction inputs relative to their inclusion in a block. The original name suggested was CHECKSEQUENCEVERIFY (CSV), but some members propose that it should be renamed to reflect its actual use case rather than focusing on the bitcoin internals. Eric Lombrozo argues that app developers need a clear interface to develop apps and that relative timelock is the critical exposed functionality intended here. He suggests calling the opcode RCHECKLOCKTIMEVERIFY to communicate fairly directly to developers and protocol designers the semantics they actually care about and also make clear the relationship between absolute and relative timelock. Mark Friedenbach, who originated the name CHECKSEQUENCEVERIFY, explains that the names are purposefully chosen to illustrate what they do and that the semantics are not limited to relative lock-time/maturity only. However, many members agree with Eric Lombrozo that the opcode should be renamed to reflect its actual use case. Suggestions include CHECKMATURITYVERIFY, RELATIVELOCKTIMEVERIFY, RCHECKLOCKTIMEVERIFY, and RCLTV.The discussion is about the naming convention of an opcode related to timelock functionality in the Bitcoin system. Eric Lombrozo suggests that the naming convention should be CHECKVERIFY, and the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY, but it is too long and should be abbreviated. He also thinks that timelock is more relevant from an application developer standpoint than maturity because it controls when funds can be moved. Eric believes that RCLTV or RCHECKLOCKTIMEVERIFY is a better choice for abbreviation as we already have CLTV, which makes the relationship between the two more explicit. He further adds about the possibility of adding opcodes with segregated witness that push values onto the stack. Jorge Timón also agrees with Eric's suggestion and proposes CMV instead of the check_x_verify naming pattern.The debate over the naming of opcode CHECKSEQUENCEVERIFY (OP_CSV) in BIP112 continues. While the name was purposefully chosen to illustrate its function, some argue that it is too broad and limits the use of nSequence bits for future applications. Suggestions have been made to rename it to reflect its actual use case of verifying the time/maturity of transaction inputs 2015-11-27T10:14:10+00:00 + In an email thread on the bitcoin-dev mailing list, Mark Friedenbach expressed his objection to the use of nSequence in Bitcoin's implementation. He suggested renaming it to nMaturity, a suggestion he had previously made before the implementation began. However, he acknowledged that it was now too late to make such changes without disrupting the implementation. The discussion focuses on the relative locktime (or minimum age) and the nSequence field in transactions, which currently plays a combined role. The lack of a dedicated field for the purpose of relative locktime is considered unfortunate as it requires repurposing unused bits in the txin. However, there may be ways around this issue using segwit.One suggestion is to add an extra input vector to the prunable extra data that comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash. Adding extra prunable signed data fields to transactions may ultimately remove scarcity of tx data that can be repurposed via soft forks. The nSequence field could be turned into a dedicated min age/rlt field to simplify semantics and avoid ugliness in trying to reclaim unused bits.The article discusses the limited availability of single-byte opcodes left, with only ten single-byte OP_NOPx opcodes defined. Additionally, there are 66 single-byte values that are currently reserved. The author argues that it seems trivial to him to add a comment in script.h, which would neither slow compilation nor confuse anyone but could lead the curious to explore history and expand their knowledge. The article also talks about the name OP_CHECKSEQUENCEVERIFY, which should not be changed. The author explains that each person has a single best reason not to change it, and finding other reasons suggests that one's top reason is not good enough. Moreover, the article highlights that the same goes for changing it. In any case, it is 178 (0xb2), and app developers can call it whatever they want.Eric Lombrozo, a developer, believes that relative timelock is the most important exposed functionality intended for app developers. He also agrees with Mark and Matt that the relative locktime feature is not in the CSV opcode but in the nSequence calculation. Rusty, who developed scripts using CSV, supports keeping CSV as it is.In a bitcoin-dev email thread, Eric Lombrozo proposed that the full opcode name for CHECKRELATIVELOCKTIMEVERIFY should be abbreviated. He suggested using both CLTV and CRLTV for abbreviation, however, these abbreviations are hard to distinguish from each other. Peter Todd suggested using the abbreviation AGEVERIFY instead, which is short and sweet.The discussion in the bitcoin-dev mailing list revolves around the naming of the opcode for BIP112, which verifies the time/maturity of transaction inputs relative to their inclusion in a block. The original name suggested was CHECKSEQUENCEVERIFY (CSV), but some members propose that it should be renamed to reflect its actual use case rather than focusing on the bitcoin internals. Eric Lombrozo argues that app developers need a clear interface to develop apps and that relative timelock is the critical exposed functionality intended here. He suggests calling the opcode RCHECKLOCKTIMEVERIFY to communicate fairly directly to developers and protocol designers the semantics they actually care about and also make clear the relationship between absolute and relative timelock. Mark Friedenbach, who originated the name CHECKSEQUENCEVERIFY, explains that the names are purposefully chosen to illustrate what they do and that the semantics are not limited to relative lock-time/maturity only. However, many members agree with Eric Lombrozo that the opcode should be renamed to reflect its actual use case. Suggestions include CHECKMATURITYVERIFY, RELATIVELOCKTIMEVERIFY, RCHECKLOCKTIMEVERIFY, and RCLTV.The discussion is about the naming convention of an opcode related to timelock functionality in the Bitcoin system. Eric Lombrozo suggests that the naming convention should be CHECKVERIFY, and the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY, but it is too long and should be abbreviated. He also thinks that timelock is more relevant from an application developer standpoint than maturity because it controls when funds can be moved. Eric believes that RCLTV or RCHECKLOCKTIMEVERIFY is a better choice for abbreviation as we already have CLTV, which makes the relationship between the two more explicit. He further adds about the possibility of adding opcodes with segregated witness that push values onto the stack. Jorge Timón also agrees with Eric's suggestion and proposes CMV instead of the check_x_verify naming pattern.The debate over the naming of opcode CHECKSEQUENCEVERIFY (OP_CSV) in BIP112 continues. While the name was purposefully chosen to illustrate its function, some argue that it is too broad and limits the use of nSequence bits for future applications. Suggestions have been made to rename it to reflect its actual use case of verifying the time/maturity of transaction inputs - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Announcing-Jonas-Schnelli-as-GUI-maintainer.xml b/static/bitcoin-dev/Nov_2015/combined_Announcing-Jonas-Schnelli-as-GUI-maintainer.xml index f06c733ef2..0695e92a03 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Announcing-Jonas-Schnelli-as-GUI-maintainer.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Announcing-Jonas-Schnelli-as-GUI-maintainer.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Announcing Jonas Schnelli as GUI maintainer - 2023-08-01T16:51:30.459216+00:00 + 2025-10-11T22:15:58.961154+00:00 + python-feedgen Jonas Schnelli 2015-11-13 08:13:24+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Announcing Jonas Schnelli as GUI maintainer - 2023-08-01T16:51:30.459216+00:00 + 2025-10-11T22:15:58.961309+00:00 - Jonas Schnelli, a senior software developer from Switzerland, has been announced as the new maintainer of the Graphical User Interface (GUI) for Bitcoin Core. This software is essential to the functioning of the most widely used cryptocurrency in the world. Over the past year, Schnelli has been actively involved in various GUI-related tasks, such as redesigning icons, visualizing network statistics, and continuously improving the user experience.Although Schnelli had previously been unofficially providing direction on GUI matters, his appointment now makes it official. Wladimir Van Der Laan, the creator of Bitcoin Core, acknowledged that he had been receiving Schnelli's guidance for some time. As the new GUI maintainer, Schnelli will have the responsibility of handling GUI-related issues on the GitHub tracker and assisting in merging GUI-related pull requests.This announcement marks a significant step towards addressing the long-standing need for improvements in the user experience of Bitcoin Core. With Schnelli's expertise and dedication, it is expected that the GUI of Bitcoin Core will continue to evolve and enhance the overall usability of this popular cryptocurrency. 2015-11-13T08:13:24+00:00 + Jonas Schnelli, a senior software developer from Switzerland, has been announced as the new maintainer of the Graphical User Interface (GUI) for Bitcoin Core. This software is essential to the functioning of the most widely used cryptocurrency in the world. Over the past year, Schnelli has been actively involved in various GUI-related tasks, such as redesigning icons, visualizing network statistics, and continuously improving the user experience.Although Schnelli had previously been unofficially providing direction on GUI matters, his appointment now makes it official. Wladimir Van Der Laan, the creator of Bitcoin Core, acknowledged that he had been receiving Schnelli's guidance for some time. As the new GUI maintainer, Schnelli will have the responsibility of handling GUI-related issues on the GitHub tracker and assisting in merging GUI-related pull requests.This announcement marks a significant step towards addressing the long-standing need for improvements in the user experience of Bitcoin Core. With Schnelli's expertise and dedication, it is expected that the GUI of Bitcoin Core will continue to evolve and enhance the overall usability of this popular cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_BIP-113-Median-time-past-is-a-HARDfork-not-a-softfork-.xml b/static/bitcoin-dev/Nov_2015/combined_BIP-113-Median-time-past-is-a-HARDfork-not-a-softfork-.xml index d9ba2ff1b8..244dfeb680 100644 --- a/static/bitcoin-dev/Nov_2015/combined_BIP-113-Median-time-past-is-a-HARDfork-not-a-softfork-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_BIP-113-Median-time-past-is-a-HARDfork-not-a-softfork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 113: Median time-past is a HARDfork, not a softfork! - 2023-08-01T16:47:53.240301+00:00 + 2025-10-11T22:15:52.585132+00:00 + python-feedgen Luke Dashjr 2015-11-02 05:06:36+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP 113: Median time-past is a HARDfork, not a softfork! - 2023-08-01T16:47:53.240301+00:00 + 2025-10-11T22:15:52.585291+00:00 - The discussion on a Bitcoin forum revolves around a proposed Bitcoin Improvement Proposal (BIP 113) that is causing controversy. The current consensus rule states that a transaction can only be included in a block if its locktime is smaller than the timestamp of the block. However, BIP 113 proposes a new rule whereby the transaction can only be included if its locktime is smaller than the median-time-past, which is the median timestamp of the past 11 blocks. Since it is already a consensus rule that the timestamp of a block must be greater than the median-time-past, this new rule makes previously invalid transactions valid, constituting a hardfork.Bitcoin Core recently merged #6566, which added BIP 113 logic to the mempool and block creation process. However, there are concerns that this may result in invalid blocks. To address this issue, Rusty suggested adding N hours to the median-time-past for comparison and max()'d with the block nTime to ensure a proper hardfork. Alternatively, it is suggested to hold off on deploying BIP 113 until a hardfork is implemented in the future.In conclusion, there are concerns about the implementation of BIP 113 as it introduces a new consensus rule and constitutes a hardfork. Bitcoin Core has already merged this logic, but there is a possibility of producing invalid blocks. Further discussion and input are required before a solution can be determined. 2015-11-02T05:06:36+00:00 + The discussion on a Bitcoin forum revolves around a proposed Bitcoin Improvement Proposal (BIP 113) that is causing controversy. The current consensus rule states that a transaction can only be included in a block if its locktime is smaller than the timestamp of the block. However, BIP 113 proposes a new rule whereby the transaction can only be included if its locktime is smaller than the median-time-past, which is the median timestamp of the past 11 blocks. Since it is already a consensus rule that the timestamp of a block must be greater than the median-time-past, this new rule makes previously invalid transactions valid, constituting a hardfork.Bitcoin Core recently merged #6566, which added BIP 113 logic to the mempool and block creation process. However, there are concerns that this may result in invalid blocks. To address this issue, Rusty suggested adding N hours to the median-time-past for comparison and max()'d with the block nTime to ensure a proper hardfork. Alternatively, it is suggested to hold off on deploying BIP 113 until a hardfork is implemented in the future.In conclusion, there are concerns about the implementation of BIP 113 as it introduces a new consensus rule and constitutes a hardfork. Bitcoin Core has already merged this logic, but there is a possibility of producing invalid blocks. Further discussion and input are required before a solution can be determined. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_BIP-Block-size-doubles-at-each-reward-halving-with-max-block-size-of-32M.xml b/static/bitcoin-dev/Nov_2015/combined_BIP-Block-size-doubles-at-each-reward-halving-with-max-block-size-of-32M.xml index 8ed95d4dfc..5b9de0d56a 100644 --- a/static/bitcoin-dev/Nov_2015/combined_BIP-Block-size-doubles-at-each-reward-halving-with-max-block-size-of-32M.xml +++ b/static/bitcoin-dev/Nov_2015/combined_BIP-Block-size-doubles-at-each-reward-halving-with-max-block-size-of-32M.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP - Block size doubles at each reward halving with max block size of 32M - 2023-08-01T16:51:05.694271+00:00 + 2025-10-11T22:16:03.208244+00:00 + python-feedgen Jorge Timón 2015-11-18 10:15:54+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - BIP - Block size doubles at each reward halving with max block size of 32M - 2023-08-01T16:51:05.694271+00:00 + 2025-10-11T22:16:03.208438+00:00 - On August 11, 2015, a proposal was made to gradually increase the maximum block size of Bitcoin. The proposal aimed to increase the block size to 2 MB at the next block subsidy halving and double it at each subsequent halving until reaching a maximum of 32 MB. This proposal was motivated by the desire to restore the block size to its original setting and provide a long-term solution that doesn't rely on assumptions about future bandwidth and storage availability.However, concerns were raised about the timeline for upgrading nodes, leading to a revised specification proposed on November 13, 2015. This revised specification suggested increasing the maximum block size to 2 MB at height 420,000, which was expected to be reached in 2032. It was noted that older clients would not be compatible with this change, potentially creating a network partition that excluded non-upgraded nodes and miners.The debate over block size and scalability issues in Bitcoin has been ongoing for years. In 2017, a compromise agreement called the "SegWit2x" proposal was reached, which included a soft fork to enable Segregated Witness (SegWit) and a subsequent hard fork to increase the block size to 2 MB. However, this proposal was ultimately abandoned due to lack of consensus within the community.Since then, other solutions such as the Lightning Network have been proposed and implemented to address scalability. Nonetheless, the debate over block size remains a contentious issue within the Bitcoin community, highlighting the challenges of finding consensus in a decentralized system.In summary, the proposal made in August 2015 aimed to gradually increase the maximum block size of Bitcoin to restore it to its original setting of 32 MB. The revised specification addressed concerns about node upgrades but introduced potential complications with older clients. The ongoing debate over block size and scalability highlights the difficulties of achieving consensus in a decentralized system. 2015-11-18T10:15:54+00:00 + On August 11, 2015, a proposal was made to gradually increase the maximum block size of Bitcoin. The proposal aimed to increase the block size to 2 MB at the next block subsidy halving and double it at each subsequent halving until reaching a maximum of 32 MB. This proposal was motivated by the desire to restore the block size to its original setting and provide a long-term solution that doesn't rely on assumptions about future bandwidth and storage availability.However, concerns were raised about the timeline for upgrading nodes, leading to a revised specification proposed on November 13, 2015. This revised specification suggested increasing the maximum block size to 2 MB at height 420,000, which was expected to be reached in 2032. It was noted that older clients would not be compatible with this change, potentially creating a network partition that excluded non-upgraded nodes and miners.The debate over block size and scalability issues in Bitcoin has been ongoing for years. In 2017, a compromise agreement called the "SegWit2x" proposal was reached, which included a soft fork to enable Segregated Witness (SegWit) and a subsequent hard fork to increase the block size to 2 MB. However, this proposal was ultimately abandoned due to lack of consensus within the community.Since then, other solutions such as the Lightning Network have been proposed and implemented to address scalability. Nonetheless, the debate over block size remains a contentious issue within the Bitcoin community, highlighting the challenges of finding consensus in a decentralized system.In summary, the proposal made in August 2015 aimed to gradually increase the maximum block size of Bitcoin to restore it to its original setting of 32 MB. The revised specification addressed concerns about node upgrades but introduced potential complications with older clients. The ongoing debate over block size and scalability highlights the difficulties of achieving consensus in a decentralized system. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_BIP-proposal-Max-block-size.xml b/static/bitcoin-dev/Nov_2015/combined_BIP-proposal-Max-block-size.xml index 0101790e65..1ae2d7aa7c 100644 --- a/static/bitcoin-dev/Nov_2015/combined_BIP-proposal-Max-block-size.xml +++ b/static/bitcoin-dev/Nov_2015/combined_BIP-proposal-Max-block-size.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP proposal - Max block size - 2023-08-01T16:51:50.133767+00:00 + 2025-10-11T22:15:56.837141+00:00 + python-feedgen Erik 2015-11-14 15:25:19+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP proposal - Max block size - 2023-08-01T16:51:50.133767+00:00 + 2025-10-11T22:15:56.837293+00:00 - Erik, a Bitcoin developer, has raised concerns about the BIP proposals for the maximum block size in Bitcoin. He believes that implementing BIP101 would lead to centralization of the currency as it would outperform consumer hardware over time. In response, Erik has proposed an alternative solution to address this issue. However, another developer named Luke has pointed out that Erik did not consider newer BIPs, such as BIP103, and suggested that he collaborate with John Sacco, who has recently posted a draft BIP similar to Erik's proposal.Luke has criticized Erik's proposal, stating that it is unnecessarily complicated and lacks specificity. He questions how the 2^(1/2) block size limit would work and suggests that it could potentially result in rounding errors in different implementations. Luke also argues that the miner voting process is redundant since miners can already implement lower limits through soft forks. Instead, he suggests expressing the current possibility to enforce it by full nodes, but this should be done through an unlimited simple-majority vote to reduce the limit. Luke advises separating this from the hard fork BIP as it is somewhat unrelated.Erik Fors' proposal aims to provide a long-term solution for the maximum block size in Bitcoin. He identifies issues with existing BIPs, such as BIP101 leading to centralization and BIP100 allowing miners to vote on the block size, which may have negative consequences for trust and transaction fees. Fors' proposal seeks to offer a smooth growth rate based on a large consensus, making future growth more predictable. It places the decision for growth rate in the hands of miners, ensuring that there is always growth in the block size and that it never decreases.The proposed rules suggest a target growth rate of 2^(1/2) every second year or a doubling of the block size every four years. The growth rate is determined based on votes from the last half-year, and the block size increases at the same time as the block difficulty retarget. While there are some drawbacks to this proposal, such as the potential for a few entities to vote for smaller growth over an extended period, leading to mistrust in the network, the overall aim is to provide a long-term solution that brings stability to the Bitcoin network by eliminating fluctuating block sizes. 2015-11-14T15:25:19+00:00 + Erik, a Bitcoin developer, has raised concerns about the BIP proposals for the maximum block size in Bitcoin. He believes that implementing BIP101 would lead to centralization of the currency as it would outperform consumer hardware over time. In response, Erik has proposed an alternative solution to address this issue. However, another developer named Luke has pointed out that Erik did not consider newer BIPs, such as BIP103, and suggested that he collaborate with John Sacco, who has recently posted a draft BIP similar to Erik's proposal.Luke has criticized Erik's proposal, stating that it is unnecessarily complicated and lacks specificity. He questions how the 2^(1/2) block size limit would work and suggests that it could potentially result in rounding errors in different implementations. Luke also argues that the miner voting process is redundant since miners can already implement lower limits through soft forks. Instead, he suggests expressing the current possibility to enforce it by full nodes, but this should be done through an unlimited simple-majority vote to reduce the limit. Luke advises separating this from the hard fork BIP as it is somewhat unrelated.Erik Fors' proposal aims to provide a long-term solution for the maximum block size in Bitcoin. He identifies issues with existing BIPs, such as BIP101 leading to centralization and BIP100 allowing miners to vote on the block size, which may have negative consequences for trust and transaction fees. Fors' proposal seeks to offer a smooth growth rate based on a large consensus, making future growth more predictable. It places the decision for growth rate in the hands of miners, ensuring that there is always growth in the block size and that it never decreases.The proposed rules suggest a target growth rate of 2^(1/2) every second year or a doubling of the block size every four years. The growth rate is determined based on votes from the last half-year, and the block size increases at the same time as the block difficulty retarget. While there are some drawbacks to this proposal, such as the potential for a few entities to vote for smaller growth over an extended period, leading to mistrust in the network, the overall aim is to provide a long-term solution that brings stability to the Bitcoin network by eliminating fluctuating block sizes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_BIP68-Second-level-granularity-doesn-t-make-sense.xml b/static/bitcoin-dev/Nov_2015/combined_BIP68-Second-level-granularity-doesn-t-make-sense.xml index 0e9a4cd401..260b52e8b9 100644 --- a/static/bitcoin-dev/Nov_2015/combined_BIP68-Second-level-granularity-doesn-t-make-sense.xml +++ b/static/bitcoin-dev/Nov_2015/combined_BIP68-Second-level-granularity-doesn-t-make-sense.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP68: Second-level granularity doesn't make sense - 2023-08-01T16:54:09.594754+00:00 + 2025-10-11T22:16:28.690986+00:00 + python-feedgen Peter Todd 2015-11-24 05:58:40+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - BIP68: Second-level granularity doesn't make sense - 2023-08-01T16:54:09.594754+00:00 + 2025-10-11T22:16:28.691166+00:00 - In a discussion on the bitcoin-dev mailing list, Peter Todd proposed changes to BIP68, which defines the rules for locktime in transactions. The current specification creates an awkward situation where users of by-height locktimes have 14 bits unused in nSequence, but by-time locktimes only have 5 bits unused. Todd suggests making by-time locks use the same number of bits as by-height locks, and multiplying the by-time lock field by the block interval.Another participant in the discussion pointed out that this issue had already been addressed and resolved in a previous version of the specification. Todd was pleased to see that his conclusions matched those of previous discussions.BIP68 is a representation of lock-time values, allowing for transactions to be locked for a specific period or until a certain block height. By-height locks are represented as a 16-bit integer while by-time locks are represented as a 25-bit integer with a granularity of 1 second. However, this granularity does not align with BIP113, which uses the median time-past as the endpoint for lock-time calculations and may pose problems for future upgrades.There are two cases to consider when using lock-time values: no competing transactions and competing transactions. In the former case, exact miner behavior is irrelevant and granularity below an hour or two has little significance. In the latter case, miners are expected to prefer lower sequence numbers, allowing for bidirectional payment channels to decrement nSequence for each change of direction. BIP113 calculates the median time-past by taking the median time of the previous 11 blocks, meaning miners have no control over it.This renders granularity below a block interval ineffective in determining which transaction the miner includes. Therefore, users will want to use significantly larger than 1 block interval granularity in protocols.The downside of BIP68 is that unused bits in nSequence present an awkward situation if new meanings need to be added and more than five bits are required. The recommendation is to modify BIP68 to make by-time locks have the same number of bits as by-height locks and multiply the by-time lock field by the block interval. By aligning the number of bits and incorporating the block interval, this modification can address the issue of unused bits and ensure a more efficient representation of locktime values.Overall, the discussion on bitcoin-dev mailing list highlights the need for improvements in the BIP68 specification regarding the representation of locktime values. Peter Todd's proposed changes aim to address the issue of unused bits and provide a more consistent and effective approach. The previous resolution mentioned by another participant reflects the ongoing efforts to enhance the specification based on collective discussions and insights from various contributors. 2015-11-24T05:58:40+00:00 + In a discussion on the bitcoin-dev mailing list, Peter Todd proposed changes to BIP68, which defines the rules for locktime in transactions. The current specification creates an awkward situation where users of by-height locktimes have 14 bits unused in nSequence, but by-time locktimes only have 5 bits unused. Todd suggests making by-time locks use the same number of bits as by-height locks, and multiplying the by-time lock field by the block interval.Another participant in the discussion pointed out that this issue had already been addressed and resolved in a previous version of the specification. Todd was pleased to see that his conclusions matched those of previous discussions.BIP68 is a representation of lock-time values, allowing for transactions to be locked for a specific period or until a certain block height. By-height locks are represented as a 16-bit integer while by-time locks are represented as a 25-bit integer with a granularity of 1 second. However, this granularity does not align with BIP113, which uses the median time-past as the endpoint for lock-time calculations and may pose problems for future upgrades.There are two cases to consider when using lock-time values: no competing transactions and competing transactions. In the former case, exact miner behavior is irrelevant and granularity below an hour or two has little significance. In the latter case, miners are expected to prefer lower sequence numbers, allowing for bidirectional payment channels to decrement nSequence for each change of direction. BIP113 calculates the median time-past by taking the median time of the previous 11 blocks, meaning miners have no control over it.This renders granularity below a block interval ineffective in determining which transaction the miner includes. Therefore, users will want to use significantly larger than 1 block interval granularity in protocols.The downside of BIP68 is that unused bits in nSequence present an awkward situation if new meanings need to be added and more than five bits are required. The recommendation is to modify BIP68 to make by-time locks have the same number of bits as by-height locks and multiply the by-time lock field by the block interval. By aligning the number of bits and incorporating the block interval, this modification can address the issue of unused bits and ensure a more efficient representation of locktime values.Overall, the discussion on bitcoin-dev mailing list highlights the need for improvements in the BIP68 specification regarding the representation of locktime values. Peter Todd's proposed changes aim to address the issue of unused bits and provide a more consistent and effective approach. The previous resolution mentioned by another participant reflects the ongoing efforts to enhance the specification based on collective discussions and insights from various contributors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Bitcoin-Core-0-11-2-released.xml b/static/bitcoin-dev/Nov_2015/combined_Bitcoin-Core-0-11-2-released.xml index 70fb6c1ecf..94d0f075e1 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Bitcoin-Core-0-11-2-released.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Bitcoin-Core-0-11-2-released.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.11.2 released - 2023-08-01T16:52:08.289643+00:00 + 2025-10-11T22:16:05.331272+00:00 + python-feedgen Wladimir J. van der Laan 2015-11-16 07:49:15+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.11.2 released - 2023-08-01T16:52:08.289643+00:00 + 2025-10-11T22:16:05.331449+00:00 - The author of the text has attempted to verify Wladimir's PGP keys, starting with the old key and then proceeding to the new one. However, he found that the signature of the new key was bad when visiting the website where it was referenced in a message signed by the old key. Despite this, the SHA256SUMS.asc file obtained from the magnet link posted in the same email verified using the new key. The email contains information about Bitcoin Core version 0.11.2, which is now available for download from the bitcoin.org/bin/ website. This update includes bug fixes, the BIP65 (CLTV) consensus change, and relay policy preparation for BIP113. It is highly recommended to upgrade to this version as soon as possible. The release introduces changes related to the BIP65 soft fork, which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY (CLTV). This allows for the creation of unspendable transaction outputs until a specified point in the future. The release also applies the BIP113 rule to received transactions, meaning that transactions with a time greater than the GetMedianTimePast() will no longer be accepted into the mempool. Furthermore, the release addresses a bug in Windows where the UTXO database becomes corrupted on unclean shutdowns. This fix eliminates the need for frequent reindexing after such shutdowns. In the previous version, Bitcoin Core version 0.11.1, bug fixes, performance improvements, and the BIP65 softfork were included. Other changes included a fix for locking in GetTransaction, new rules for using GetMedianTimePast as the endpoint for lock-time calculations, and the ability to mine on top of old tip blocks for testnet. It is worth noting that downgrading to previous versions may cause compatibility issues due to changes in block files and databases. Overall, the release of Bitcoin Core version 0.11.2 brings important bug fixes and improvements, including the implementation of BIP113 and the fix for the corrupted UTXO database on unclean shutdowns in Windows. It is recommended for users to upgrade to this version to ensure a more secure and reliable Bitcoin experience. 2015-11-16T07:49:15+00:00 + The author of the text has attempted to verify Wladimir's PGP keys, starting with the old key and then proceeding to the new one. However, he found that the signature of the new key was bad when visiting the website where it was referenced in a message signed by the old key. Despite this, the SHA256SUMS.asc file obtained from the magnet link posted in the same email verified using the new key. The email contains information about Bitcoin Core version 0.11.2, which is now available for download from the bitcoin.org/bin/ website. This update includes bug fixes, the BIP65 (CLTV) consensus change, and relay policy preparation for BIP113. It is highly recommended to upgrade to this version as soon as possible. The release introduces changes related to the BIP65 soft fork, which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY (CLTV). This allows for the creation of unspendable transaction outputs until a specified point in the future. The release also applies the BIP113 rule to received transactions, meaning that transactions with a time greater than the GetMedianTimePast() will no longer be accepted into the mempool. Furthermore, the release addresses a bug in Windows where the UTXO database becomes corrupted on unclean shutdowns. This fix eliminates the need for frequent reindexing after such shutdowns. In the previous version, Bitcoin Core version 0.11.1, bug fixes, performance improvements, and the BIP65 softfork were included. Other changes included a fix for locking in GetTransaction, new rules for using GetMedianTimePast as the endpoint for lock-time calculations, and the ability to mine on top of old tip blocks for testnet. It is worth noting that downgrading to previous versions may cause compatibility issues due to changes in block files and databases. Overall, the release of Bitcoin Core version 0.11.2 brings important bug fixes and improvements, including the implementation of BIP113 and the fix for the corrupted UTXO database on unclean shutdowns in Windows. It is recommended for users to upgrade to this version to ensure a more secure and reliable Bitcoin experience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Bitcoin-NG-whitepaper-.xml b/static/bitcoin-dev/Nov_2015/combined_Bitcoin-NG-whitepaper-.xml index 9266fb6dad..a77b43b1df 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Bitcoin-NG-whitepaper-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Bitcoin-NG-whitepaper-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin-NG whitepaper. - 2023-08-01T16:38:14.268302+00:00 + 2025-10-11T22:15:50.456753+00:00 + python-feedgen Emin Gün Sirer 2015-11-09 18:33:27+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Bitcoin-NG whitepaper. - 2023-08-01T16:38:14.269303+00:00 + 2025-10-11T22:15:50.457150+00:00 - On October 14, 2015, a conversation took place among Bitcoin developers regarding the use of microblocks in the Bitcoin-NG protocol. One issue raised was the lack of a mechanism to punish individuals involved in a double spend in a microblock that occurs in a key block, which reorganizes away the first transaction. It was suggested that users should wait before accepting a transaction to ensure no key-block was missed. Additionally, an attacker could continuously double spend by immediately mining a key block after sending a transaction and creating a microblock that double-spends the previous transaction.The confirmation time for microblocks may not need to be a full key-block, but it should be long enough for the attacker to lose more fees than the value of their double-spend. There was also discussion about the implementation of Bitcoin-NG and its compatibility with Bitcoin and Blockstream-like sidechains. It was suggested that NG could support privacy measures such as stealth sends or confidential transactions. NG could potentially be implemented as a feature in Bitcoin Core that users can activate or deactivate. Concerns were raised about managing and protecting information in the NG scheme, including references to previous blocks, current GMT times, cryptographic hashes of ledger entries, and cryptographic signatures of headers. The question of whether NG can support privacy measures remains unanswered.The Bitcoin-NG protocol aims to address scalability challenges faced by Bitcoin by increasing throughput and reducing latency without changing Bitcoin's trust model or open architecture. The whitepaper provides detailed information on the protocol, which involves electing a "leader" who vets future transactions. There are two options for the overlay-NG that runs on top of Bitcoin: significantly reduce observed latency or increase bandwidth once everyone is on board. Microblocks in Bitcoin-NG contain ledger entries and a header, but they do not affect the weight of the chain because they do not contain proof of work. The actual leader in NG is a key, not a specific node.Bob McElrath proposed that shutting down Bitcoin-NG could be done by identifying the current leader and launching a DDoS attack on them. Emin Gün Sirer countered this by explaining that Bitcoin-NG is designed to mitigate DDoS attacks by dynamically migrating the leader within the network. He also mentioned that defenses against DDoS attacks on miners can be applied to Bitcoin-NG as well. The success of Matt Corallo's high-speed bitcoin relay network has contributed to the rarity of such attacks.Ittay responded to a discussion on double-spending issues, suggesting that fraud proof could eliminate the attacker's revenue. He compared it to an attacker sacrificing an entire block for double-spending in the current system. The whitepaper provides more detailed insights into the topic.Bitcoin-NG is a technique specifically designed to tackle scalability challenges faced by Bitcoin. This approach increases throughput while reducing latency without compromising Bitcoin's open architecture or trust model. The creators of Bitcoin-NG do not intend to compete commercially with Bitcoin or Blockstream-like sidechains but rather see it as complementary. They aim to advance blockchain technology and inspire further innovations. Feedback from the community is encouraged. One comment suggests considering a miner's ability to choose the key block time to generate more miniblocks.In an email conversation, Emin Gün Sirer discusses the difficulties of resolving double-spending issues solely through fraud proofs. He refers to a whitepaper that provides technical details on this matter. The topic was also discussed in a -wizards thread. Fidelity-bonded ledgers are recommended for a system reliant on fraud proofs and threats.Overall, Bitcoin-NG offers a potential solution to scalability challenges in Bitcoin with its increased throughput and reduced latency. However, there are still concerns regarding the implementation and privacy measures of the protocol. The conversation among developers highlighted the need for further discussion and analysis to address potential issues such as double spending in microblocks. 2015-11-09T18:33:27+00:00 + On October 14, 2015, a conversation took place among Bitcoin developers regarding the use of microblocks in the Bitcoin-NG protocol. One issue raised was the lack of a mechanism to punish individuals involved in a double spend in a microblock that occurs in a key block, which reorganizes away the first transaction. It was suggested that users should wait before accepting a transaction to ensure no key-block was missed. Additionally, an attacker could continuously double spend by immediately mining a key block after sending a transaction and creating a microblock that double-spends the previous transaction.The confirmation time for microblocks may not need to be a full key-block, but it should be long enough for the attacker to lose more fees than the value of their double-spend. There was also discussion about the implementation of Bitcoin-NG and its compatibility with Bitcoin and Blockstream-like sidechains. It was suggested that NG could support privacy measures such as stealth sends or confidential transactions. NG could potentially be implemented as a feature in Bitcoin Core that users can activate or deactivate. Concerns were raised about managing and protecting information in the NG scheme, including references to previous blocks, current GMT times, cryptographic hashes of ledger entries, and cryptographic signatures of headers. The question of whether NG can support privacy measures remains unanswered.The Bitcoin-NG protocol aims to address scalability challenges faced by Bitcoin by increasing throughput and reducing latency without changing Bitcoin's trust model or open architecture. The whitepaper provides detailed information on the protocol, which involves electing a "leader" who vets future transactions. There are two options for the overlay-NG that runs on top of Bitcoin: significantly reduce observed latency or increase bandwidth once everyone is on board. Microblocks in Bitcoin-NG contain ledger entries and a header, but they do not affect the weight of the chain because they do not contain proof of work. The actual leader in NG is a key, not a specific node.Bob McElrath proposed that shutting down Bitcoin-NG could be done by identifying the current leader and launching a DDoS attack on them. Emin Gün Sirer countered this by explaining that Bitcoin-NG is designed to mitigate DDoS attacks by dynamically migrating the leader within the network. He also mentioned that defenses against DDoS attacks on miners can be applied to Bitcoin-NG as well. The success of Matt Corallo's high-speed bitcoin relay network has contributed to the rarity of such attacks.Ittay responded to a discussion on double-spending issues, suggesting that fraud proof could eliminate the attacker's revenue. He compared it to an attacker sacrificing an entire block for double-spending in the current system. The whitepaper provides more detailed insights into the topic.Bitcoin-NG is a technique specifically designed to tackle scalability challenges faced by Bitcoin. This approach increases throughput while reducing latency without compromising Bitcoin's open architecture or trust model. The creators of Bitcoin-NG do not intend to compete commercially with Bitcoin or Blockstream-like sidechains but rather see it as complementary. They aim to advance blockchain technology and inspire further innovations. Feedback from the community is encouraged. One comment suggests considering a miner's ability to choose the key block time to generate more miniblocks.In an email conversation, Emin Gün Sirer discusses the difficulties of resolving double-spending issues solely through fraud proofs. He refers to a whitepaper that provides technical details on this matter. The topic was also discussed in a -wizards thread. Fidelity-bonded ledgers are recommended for a system reliant on fraud proofs and threats.Overall, Bitcoin-NG offers a potential solution to scalability challenges in Bitcoin with its increased throughput and reduced latency. However, there are still concerns regarding the implementation and privacy measures of the protocol. The conversation among developers highlighted the need for further discussion and analysis to address potential issues such as double spending in microblocks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Call-for-Proposals-for-Scaling-Bitcoin-Hong-Kong.xml b/static/bitcoin-dev/Nov_2015/combined_Call-for-Proposals-for-Scaling-Bitcoin-Hong-Kong.xml index a8ab568c82..f0b0061a4b 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Call-for-Proposals-for-Scaling-Bitcoin-Hong-Kong.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Call-for-Proposals-for-Scaling-Bitcoin-Hong-Kong.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Call for Proposals for Scaling Bitcoin Hong Kong - 2023-08-01T16:48:31.794874+00:00 + 2025-10-11T22:16:20.198731+00:00 + python-feedgen Pindar Wong 2015-11-10 00:52:44+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Call for Proposals for Scaling Bitcoin Hong Kong - 2023-08-01T16:48:31.794874+00:00 + 2025-10-11T22:16:20.198884+00:00 - The second Scaling Bitcoin Workshop is set to take place in Hong Kong on December 6th-7th. The workshop aims to address the scalability challenges of Bitcoin and provide potential solutions while identifying key areas for further research. Researchers, developers, and miners will have the opportunity to communicate and collaborate on Bitcoin development at this event.Technical proposals are currently being accepted until November 9th. These proposals can include designs, experimental results, and comparisons against other proposals. Authors have two options for submission: they can either give a 20-30 minute presentation or run an hour-long interactive workshop. Topics of interest for these proposals include improving Bitcoin throughput, layer 2 ideas, security and privacy, incentives and fee structures, testing, simulation, and modeling, network resilience, anti-spam measures, block size proposals, mining concerns, and community coordination.Accepted authors will be notified by November 16th and will have the opportunity to present their work at the workshop. All talks will be livestreamed and published online, including slide decks. This allows for a wider audience to access and benefit from the knowledge shared at the workshop.The deadline for proposal submissions has been extended by two days, with proposals now due by November 11th at 23:59 UTC. It is important for interested individuals to submit their proposals within this timeframe to be considered for acceptance. This workshop provides a valuable platform for the Bitcoin community to come together, share insights, and work towards improving the performance of Bitcoin. 2015-11-10T00:52:44+00:00 + The second Scaling Bitcoin Workshop is set to take place in Hong Kong on December 6th-7th. The workshop aims to address the scalability challenges of Bitcoin and provide potential solutions while identifying key areas for further research. Researchers, developers, and miners will have the opportunity to communicate and collaborate on Bitcoin development at this event.Technical proposals are currently being accepted until November 9th. These proposals can include designs, experimental results, and comparisons against other proposals. Authors have two options for submission: they can either give a 20-30 minute presentation or run an hour-long interactive workshop. Topics of interest for these proposals include improving Bitcoin throughput, layer 2 ideas, security and privacy, incentives and fee structures, testing, simulation, and modeling, network resilience, anti-spam measures, block size proposals, mining concerns, and community coordination.Accepted authors will be notified by November 16th and will have the opportunity to present their work at the workshop. All talks will be livestreamed and published online, including slide decks. This allows for a wider audience to access and benefit from the knowledge shared at the workshop.The deadline for proposal submissions has been extended by two days, with proposals now due by November 11th at 23:59 UTC. It is important for interested individuals to submit their proposals within this timeframe to be considered for acceptance. This workshop provides a valuable platform for the Bitcoin community to come together, share insights, and work towards improving the performance of Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Compatibility-requirements-for-hard-or-soft-forks.xml b/static/bitcoin-dev/Nov_2015/combined_Compatibility-requirements-for-hard-or-soft-forks.xml index 43e6688588..66f09d267d 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Compatibility-requirements-for-hard-or-soft-forks.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Compatibility-requirements-for-hard-or-soft-forks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Compatibility requirements for hard or soft forks - 2023-08-01T16:47:10.879812+00:00 + 2025-10-11T22:16:35.069518+00:00 + python-feedgen jl2012 at xbt.hk 2015-11-03 05:32:18+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Compatibility requirements for hard or soft forks - 2023-08-01T16:47:10.879812+00:00 + 2025-10-11T22:16:35.069665+00:00 - A strategy for the safe use of Bitcoin involves creating an informational BIP (Bitcoin Improvement Proposal). The guidelines for this proposal include increasing transaction version numbers when possible, considering transactions with unknown/large version numbers as unsafe to use with locktime, and providing reasonable notice before implementing changes. Non-opt-in changes should only be made to protect the network's integrity. Transactions that can be validated without overburdening the network are considered safe to use, even if they are non-standard. However, an OP_CAT script that requires terabytes of RAM to validate is not considered "reasonable." While these guidelines have generally been well-received, there may be disagreements over what constitutes "protecting the integrity of the network" and "reasonable notice."Gavin Andresen shared his opinion on the guidelines, agreeing with them but noting potential disagreements over what constitutes "reasonable notice" and "protects the integrity of the network." He suggested that if Bitcoin were perfect, any valid transaction would remain valid until spent regardless of protocol changes. However, there are cases where this guarantee cannot be met, and it is difficult to determine if these cases pose a real problem in practice. To address these issues, he proposed implementing non-pathological backward compatibility and treating unhandled cases as bugs until triggered.On November 1, 2015, Tier Nolan discussed guidelines for Bitcoin transaction version numbers. According to the guidelines, version numbers will be increased when possible, but transactions with unknown or large version numbers should not be used with locktime. Non-opt-in changes will only be made to protect the network's integrity, and reasonable notice must be given before implementing any changes. Locked transactions that can be validated without burdening the network are considered safe, even if they are non-standard. However, an OP_CAT script requiring terabytes of RAM to validate is deemed unreasonable. Gavin Andresen responded positively to these guidelines but acknowledged potential disagreements over "reasonable notice."In a Bitcoin-dev mailing list, Tier Nolan suggested giving at least one year's notice to prevent people from losing their money. It was also noted that bitcoin nodes can validate blocks going back to the genesis block, preserving old consensus rules in current code bases. While validating input scripts according to past consensus rules is feasible, handling output may be more challenging. It was proposed that if every consensus rule change had been accompanied by a version number bump, old versions could have been phased out without invalidating signed-but-unbroadcast transactions.The term "locked transaction" may refer to a P2SH output. Justus Ranvier raised concerns about OP_CAT scripts in the UTXO set and the possibility of locked transactions paying to such scripts with lost private keys, potentially making outputs unspendable. There were discussions on preventing rule changes that permanently disable spendability of outputs and the question of who should decide Bitcoin usage standards. Miners were identified as the decision-makers, not developers. Additionally, the question of how close Bitcoin developers want to sail towards being administrators of a virtual currency was posed.The threshold of reasonableness for OP_CAT scripts, which require terabytes of RAM to validate, was discussed in a Bitcoin-dev thread. Concerns were raised about the presence of such scripts in the UTXO set, worth approximately $5 billion. The need to justify not changing the meaning of someone else's outputs and the role of Bitcoin developers as administrators of a virtual currency were debated. It was highlighted that miners have the power to collectively vote on disabling specific UTXOs and changing acceptance rules.Rusty Russell emphasized the importance of clear notification and non-standard transaction invalidation in the future. He suggested that surpassing the benchmark of "reasonable certainty" would involve adding redundancies like OP_CHECKSIG and widespread notification of change. Gavin Andresen raised questions about the requirement of validating one-megabyte transactions under new rules, expressing concern about the potential confiscation of funds in cases where expensive-to-validate transactions with lockTime exist. The benchmark for "reasonable certainty" was proposed as a transaction that would never have been generated by any known software.The author questioned the definition of "short-term changes to the Bitcoin protocol" as a moderation rule and raised the question of whether any one-megabyte transaction valid under existing rules should also be valid under new rules. Arguments were presented regarding expensive-to-validate transactions with lockTime in the future and the unlikelihood of such transactions existing. It was suggested that the requirement should only apply to valid 100,000-byte transactions under old consensus rules. Gavin Andresen implemented BIP101/Bitcoin XT with support for any "non-attack" 1MB transaction. 2015-11-03T05:32:18+00:00 + A strategy for the safe use of Bitcoin involves creating an informational BIP (Bitcoin Improvement Proposal). The guidelines for this proposal include increasing transaction version numbers when possible, considering transactions with unknown/large version numbers as unsafe to use with locktime, and providing reasonable notice before implementing changes. Non-opt-in changes should only be made to protect the network's integrity. Transactions that can be validated without overburdening the network are considered safe to use, even if they are non-standard. However, an OP_CAT script that requires terabytes of RAM to validate is not considered "reasonable." While these guidelines have generally been well-received, there may be disagreements over what constitutes "protecting the integrity of the network" and "reasonable notice."Gavin Andresen shared his opinion on the guidelines, agreeing with them but noting potential disagreements over what constitutes "reasonable notice" and "protects the integrity of the network." He suggested that if Bitcoin were perfect, any valid transaction would remain valid until spent regardless of protocol changes. However, there are cases where this guarantee cannot be met, and it is difficult to determine if these cases pose a real problem in practice. To address these issues, he proposed implementing non-pathological backward compatibility and treating unhandled cases as bugs until triggered.On November 1, 2015, Tier Nolan discussed guidelines for Bitcoin transaction version numbers. According to the guidelines, version numbers will be increased when possible, but transactions with unknown or large version numbers should not be used with locktime. Non-opt-in changes will only be made to protect the network's integrity, and reasonable notice must be given before implementing any changes. Locked transactions that can be validated without burdening the network are considered safe, even if they are non-standard. However, an OP_CAT script requiring terabytes of RAM to validate is deemed unreasonable. Gavin Andresen responded positively to these guidelines but acknowledged potential disagreements over "reasonable notice."In a Bitcoin-dev mailing list, Tier Nolan suggested giving at least one year's notice to prevent people from losing their money. It was also noted that bitcoin nodes can validate blocks going back to the genesis block, preserving old consensus rules in current code bases. While validating input scripts according to past consensus rules is feasible, handling output may be more challenging. It was proposed that if every consensus rule change had been accompanied by a version number bump, old versions could have been phased out without invalidating signed-but-unbroadcast transactions.The term "locked transaction" may refer to a P2SH output. Justus Ranvier raised concerns about OP_CAT scripts in the UTXO set and the possibility of locked transactions paying to such scripts with lost private keys, potentially making outputs unspendable. There were discussions on preventing rule changes that permanently disable spendability of outputs and the question of who should decide Bitcoin usage standards. Miners were identified as the decision-makers, not developers. Additionally, the question of how close Bitcoin developers want to sail towards being administrators of a virtual currency was posed.The threshold of reasonableness for OP_CAT scripts, which require terabytes of RAM to validate, was discussed in a Bitcoin-dev thread. Concerns were raised about the presence of such scripts in the UTXO set, worth approximately $5 billion. The need to justify not changing the meaning of someone else's outputs and the role of Bitcoin developers as administrators of a virtual currency were debated. It was highlighted that miners have the power to collectively vote on disabling specific UTXOs and changing acceptance rules.Rusty Russell emphasized the importance of clear notification and non-standard transaction invalidation in the future. He suggested that surpassing the benchmark of "reasonable certainty" would involve adding redundancies like OP_CHECKSIG and widespread notification of change. Gavin Andresen raised questions about the requirement of validating one-megabyte transactions under new rules, expressing concern about the potential confiscation of funds in cases where expensive-to-validate transactions with lockTime exist. The benchmark for "reasonable certainty" was proposed as a transaction that would never have been generated by any known software.The author questioned the definition of "short-term changes to the Bitcoin protocol" as a moderation rule and raised the question of whether any one-megabyte transaction valid under existing rules should also be valid under new rules. Arguments were presented regarding expensive-to-validate transactions with lockTime in the future and the unlikelihood of such transactions existing. It was suggested that the requirement should only apply to valid 100,000-byte transactions under old consensus rules. Gavin Andresen implemented BIP101/Bitcoin XT with support for any "non-attack" 1MB transaction. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Contradiction-in-BIP65-text-.xml b/static/bitcoin-dev/Nov_2015/combined_Contradiction-in-BIP65-text-.xml index c1e2c157ad..23719bcada 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Contradiction-in-BIP65-text-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Contradiction-in-BIP65-text-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Contradiction in BIP65 text? - 2023-08-01T16:52:52.900298+00:00 + 2025-10-11T22:16:30.820962+00:00 + python-feedgen xor 2015-11-14 22:47:23+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Contradiction in BIP65 text? - 2023-08-01T16:52:52.900298+00:00 + 2025-10-11T22:16:30.821128+00:00 - In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the language used in BIP65, a Bitcoin Improvement Proposal aiming to enable the freezing of funds in UTXOs directly on the blockchain. The main concern was that the language suggested funds could be frozen involuntarily, but Jeff Garzik clarified that users themselves have the choice to freeze their own funds, and it is not an act of force from outside parties. However, there was confusion regarding how scriptpubkeys work, with some believing that wallets would display all available funds, which is not the case. Wallets will only display funds paid to scriptpubkeys they generated or would have generated, ensuring that no one can create a multisig and then claw back coins after they have been paid.The discussion also touched upon nlocktime, another aspect of BIP65, as Gregory Maxwell requested clarification on it. The purpose of this was to provide context for the need of BIP65, and Maxwell recommended changing the wording of the proposal to make this connection clearer. The original poster in the email chain questioned whether BIP65 could be used to freeze funds, referring to the motivation section of the proposal. This section explains that the nLockTime field cannot prove that it is impossible to spend a transaction output until some time in the future, leading to the interpretation that nLockTime cannot be used for freezing funds. However, the motivation section also states that funds can now be frozen in UTXOs directly on the blockchain, in addition to using other methods like cold storage, hardware wallets, and P2SH multisig outputs. The discussion revealed confusion over the interpretation of BIP65 and its potential uses, with the original poster admitting to being an end user without experience reading Bitcoin script.Overall, this discussion highlights the ongoing development of Bitcoin and emphasizes the importance of clear communication about proposals like BIP65. It is important to note that BIP65 is aimed at an audience with more experience, and the discussion provides a neutral review from an outsider's perspective. The source of this information is a GitHub page containing the full text of the BIP65 proposal. 2015-11-14T22:47:23+00:00 + In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the language used in BIP65, a Bitcoin Improvement Proposal aiming to enable the freezing of funds in UTXOs directly on the blockchain. The main concern was that the language suggested funds could be frozen involuntarily, but Jeff Garzik clarified that users themselves have the choice to freeze their own funds, and it is not an act of force from outside parties. However, there was confusion regarding how scriptpubkeys work, with some believing that wallets would display all available funds, which is not the case. Wallets will only display funds paid to scriptpubkeys they generated or would have generated, ensuring that no one can create a multisig and then claw back coins after they have been paid.The discussion also touched upon nlocktime, another aspect of BIP65, as Gregory Maxwell requested clarification on it. The purpose of this was to provide context for the need of BIP65, and Maxwell recommended changing the wording of the proposal to make this connection clearer. The original poster in the email chain questioned whether BIP65 could be used to freeze funds, referring to the motivation section of the proposal. This section explains that the nLockTime field cannot prove that it is impossible to spend a transaction output until some time in the future, leading to the interpretation that nLockTime cannot be used for freezing funds. However, the motivation section also states that funds can now be frozen in UTXOs directly on the blockchain, in addition to using other methods like cold storage, hardware wallets, and P2SH multisig outputs. The discussion revealed confusion over the interpretation of BIP65 and its potential uses, with the original poster admitting to being an end user without experience reading Bitcoin script.Overall, this discussion highlights the ongoing development of Bitcoin and emphasizes the importance of clear communication about proposals like BIP65. It is important to note that BIP65 is aimed at an audience with more experience, and the discussion provides a neutral review from an outsider's perspective. The source of this information is a GitHub page containing the full text of the BIP65 proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Dealing-with-OP-IF-and-OP-NOTIF-malleability.xml b/static/bitcoin-dev/Nov_2015/combined_Dealing-with-OP-IF-and-OP-NOTIF-malleability.xml index 03d164e30e..3fe83d5f25 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Dealing-with-OP-IF-and-OP-NOTIF-malleability.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Dealing-with-OP-IF-and-OP-NOTIF-malleability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dealing with OP_IF and OP_NOTIF malleability - 2023-08-01T16:49:16.229529+00:00 + 2025-10-11T22:16:37.193179+00:00 + python-feedgen Oleg Andreev 2015-11-10 10:52:46+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Dealing with OP_IF and OP_NOTIF malleability - 2023-08-01T16:49:16.229529+00:00 + 2025-10-11T22:16:37.193389+00:00 - In a discussion on the bitcoin-dev mailing list, the usage of OP_0 and OP_PUSH opcodes for pushing data is being debated. It is stated that OP_0 represents a zero-length byte array, whereas a single-byte string with 0x00 in it is not equal to an empty string. This leads to "false" being pushed as the result of comparison with OP_EQUAL. The participants suggest using only OP_0 and OP_1 for pushing data and not any other push opcode.One participant raises a concern about defining the "IF/NOTIF argument must be either zero-length array or a single byte 0x01" explicitly, as it contradicts the rule of minimally-encoded "zero". The aim is to prevent potential mutation of the transaction by changing the length of the array.The discussion takes place in relation to implementing a proposal alongside BIP62, which addresses malleability in OP_IF and OP_NOTIF. These flow control codes in the Bitcoin script system can be manipulated without invalidating the transaction. The proposal suggests that if the transaction version is three or above, the flow control value for OP_IF and OP_NOTIF must be either zero or one, or else the transaction fails. This change is a softfork and should be implemented with BIP62.To ensure compatibility with transactions created before the introduction of this BIP, the new rules only apply to transactions of version 3 or above. Those who wish to preserve the original behavior of OP_IF and OP_NOTIF can use an OP_0NOTEQUAL before the flow control code to transform any non-zero value to one. The proposal also emphasizes that one and zero should be defined as arrays of length one to prevent transaction mutation by changing the length of the array.Overall, the proposed BIP aims to fix the malleability issue in transactions with OP_IF and OP_NOTIF and should be implemented alongside other malleability fixes. 2015-11-10T10:52:46+00:00 + In a discussion on the bitcoin-dev mailing list, the usage of OP_0 and OP_PUSH opcodes for pushing data is being debated. It is stated that OP_0 represents a zero-length byte array, whereas a single-byte string with 0x00 in it is not equal to an empty string. This leads to "false" being pushed as the result of comparison with OP_EQUAL. The participants suggest using only OP_0 and OP_1 for pushing data and not any other push opcode.One participant raises a concern about defining the "IF/NOTIF argument must be either zero-length array or a single byte 0x01" explicitly, as it contradicts the rule of minimally-encoded "zero". The aim is to prevent potential mutation of the transaction by changing the length of the array.The discussion takes place in relation to implementing a proposal alongside BIP62, which addresses malleability in OP_IF and OP_NOTIF. These flow control codes in the Bitcoin script system can be manipulated without invalidating the transaction. The proposal suggests that if the transaction version is three or above, the flow control value for OP_IF and OP_NOTIF must be either zero or one, or else the transaction fails. This change is a softfork and should be implemented with BIP62.To ensure compatibility with transactions created before the introduction of this BIP, the new rules only apply to transactions of version 3 or above. Those who wish to preserve the original behavior of OP_IF and OP_NOTIF can use an OP_0NOTEQUAL before the flow control code to transform any non-zero value to one. The proposal also emphasizes that one and zero should be defined as arrays of length one to prevent transaction mutation by changing the length of the array.Overall, the proposed BIP aims to fix the malleability issue in transactions with OP_IF and OP_NOTIF and should be implemented alongside other malleability fixes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Dynamic-Hierarchical-Deterministic-Key-Trees.xml b/static/bitcoin-dev/Nov_2015/combined_Dynamic-Hierarchical-Deterministic-Key-Trees.xml index df341e5fbf..ca76458411 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Dynamic-Hierarchical-Deterministic-Key-Trees.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Dynamic-Hierarchical-Deterministic-Key-Trees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dynamic Hierarchical Deterministic Key Trees - 2023-08-01T16:53:47.573651+00:00 + 2025-10-11T22:16:15.953120+00:00 + python-feedgen Eric Lombrozo 2015-11-21 08:45:10+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Dynamic Hierarchical Deterministic Key Trees - 2023-08-01T16:53:47.574652+00:00 + 2025-10-11T22:16:15.953303+00:00 - In November 2015, Eric Lombrozo submitted a BIP proposal to address the issue of HD wallet structures in Bitcoin. The goal of the proposal was to simplify multidevice synchronization, key management, and account structures by generating signing key sequences from easily backupable and shareable seeds. This would allow for easier use of HD wallets while also maintaining privacy by making it difficult to associate transactions with an account without knowing the seed/chain code.During the discussion on the proposal, Tamas Blummer asked if it was possible to use a key both for signing and for deriving a deeper level of the hierarchy. However, Eric did not provide any arguments discouraging this use.In response to Tamas' question, Eric mentioned that he had submitted a BIP proposal that specifically addressed the issue of needing to predefine HD wallet structures and not being able to arbitrarily nest deeper levels. The proposal can be found on GitHub (https://github.com/bitcoin/bips/pull/242). Although Eric did not directly answer Tamas' question about discouraging the use of a key for both signing and deriving a deeper level of the hierarchy, his submission of the BIP proposal indicates that he is seeking solutions to expand the capabilities of HD wallets in Bitcoin.Eric, a developer, has invited public comments and feedback on the BIP proposal on GitHub. This open invitation allows for further development and refinement of the proposed solution to the limitations posed by the current structure of HD wallets in Bitcoin. 2015-11-21T08:45:10+00:00 + In November 2015, Eric Lombrozo submitted a BIP proposal to address the issue of HD wallet structures in Bitcoin. The goal of the proposal was to simplify multidevice synchronization, key management, and account structures by generating signing key sequences from easily backupable and shareable seeds. This would allow for easier use of HD wallets while also maintaining privacy by making it difficult to associate transactions with an account without knowing the seed/chain code.During the discussion on the proposal, Tamas Blummer asked if it was possible to use a key both for signing and for deriving a deeper level of the hierarchy. However, Eric did not provide any arguments discouraging this use.In response to Tamas' question, Eric mentioned that he had submitted a BIP proposal that specifically addressed the issue of needing to predefine HD wallet structures and not being able to arbitrarily nest deeper levels. The proposal can be found on GitHub (https://github.com/bitcoin/bips/pull/242). Although Eric did not directly answer Tamas' question about discouraging the use of a key for both signing and deriving a deeper level of the hierarchy, his submission of the BIP proposal indicates that he is seeking solutions to expand the capabilities of HD wallets in Bitcoin.Eric, a developer, has invited public comments and feedback on the BIP proposal on GitHub. This open invitation allows for further development and refinement of the proposed solution to the limitations posed by the current structure of HD wallets in Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_How-to-evaluate-block-size-increase-suggestions-.xml b/static/bitcoin-dev/Nov_2015/combined_How-to-evaluate-block-size-increase-suggestions-.xml index fd96d0d958..014c6d8293 100644 --- a/static/bitcoin-dev/Nov_2015/combined_How-to-evaluate-block-size-increase-suggestions-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_How-to-evaluate-block-size-increase-suggestions-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - How to evaluate block size increase suggestions. - 2023-08-01T16:52:34.466453+00:00 + 2025-10-11T22:16:09.577790+00:00 + python-feedgen Johnathan Corgan 2015-11-15 06:04:10+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - How to evaluate block size increase suggestions. - 2023-08-01T16:52:34.467450+00:00 + 2025-10-11T22:16:09.577957+00:00 - A new mailing list called bitcoin-discuss has been created for more free-flowing topics related to Bitcoin governance, policy or other meta-issues. The bitcoin-dev moderation team requests that further discussion on these topics be taken to this forum instead of the current one. A member named Peter R suggests discussing how Bitcoin should be governed in the first place and whether it should evolve from the “bottom up” or from the “top down”. If one’s answer is from the “bottom up,” then the meta-level criteria is very easy: we do what the people want and allow them to weigh the tradeoffs.Regarding the block size limit debate, if one concedes that Bitcoin should be governed from the “bottom up,” then it is already possible to empower each node operator to express his free choice regarding the size of blocks he is willing to accept while simultaneously ensuring that his node tracks consensus. Emin Gün Sirer posed the question of how to evaluate a truly perfect function for block size increase. He asked the community to first agree upon how to evaluate proposals before discussing specific functions. Several meta-level criteria were suggested, including increasing the block size while ensuring that large miners never have an advantage over small miners and increasing block size as much as possible subject to the constraint that 90% of nodes on the network are no more than one minute behind one of the tails of the blockchain 99% of the time. Additionally, the ability to run low-cost fully validating nodes, include additional data into the Bitcoin blockchain, reduce noise in the ledger, and address long-term scalability with well-defined auxiliary protocols to offer high-transaction throughputs were also proposed as important criteria. The discussion highlighted the need to re-evaluate the problem of scalability facing the Bitcoin network and focus on how to deal with the increasing demands on transaction throughput rather than solely on block size increase.The author agrees with the idea of defining a formal set of criteria. Proposals that schedule future increases to the blocksize consensus maximum, or leave it for miners to decide, can't be evaluated without making assumptions about the future. To address this, the author suggests having simulation and benchmarking software that can analyze proposals, give resource consumption benchmark data about average and worst cases, and also give some kind of metric from "mining centralization dynamics simulations." The author believes it would be ideal to have a metric for concrete block sizes, unrelated to the deployment mechanism, proposed activation date, and other details.In response to a suggestion that no user on the network should wait more than an hour to get three confirmations on the blockchain, the author explains that this depends on various factors such as block space demand, the fee paid by the user, local relay and mining policies in the network, the form of the transaction, and even the network topology. There's no consensus rule that can guarantee that all transactions from all users will be included at most three blocks after they are relayed. However, there is a fee estimator that observes the chain and can estimate the market situation to tell you the average number of blocks for a given transaction with a given feerate.The block size debate within the Bitcoin community has sparked a multitude of proposals for future block size increases, with countless alternative functions being suggested. However, instead of discussing specific block size increase functions, the author suggests enunciating what grand goals a truly perfect function would achieve. This meta-question asks what criteria we should look for when evaluating a good proposal, rather than judging individual proposals themselves. Possible meta-goals include increasing block size while ensuring large miners never have an advantage over small miners, increasing block size subject to a constraint on node synchronization, or not increasing block size until a certain date. Defining these meta-criteria before evaluating proposals will help prevent unnecessary proliferation of block size increase proposals. Ultimately, even with meta-criteria in hand, there may be room for disagreement due to uncertainty about the future evolution of network access technologies and node placement. 2015-11-15T06:04:10+00:00 + A new mailing list called bitcoin-discuss has been created for more free-flowing topics related to Bitcoin governance, policy or other meta-issues. The bitcoin-dev moderation team requests that further discussion on these topics be taken to this forum instead of the current one. A member named Peter R suggests discussing how Bitcoin should be governed in the first place and whether it should evolve from the “bottom up” or from the “top down”. If one’s answer is from the “bottom up,” then the meta-level criteria is very easy: we do what the people want and allow them to weigh the tradeoffs.Regarding the block size limit debate, if one concedes that Bitcoin should be governed from the “bottom up,” then it is already possible to empower each node operator to express his free choice regarding the size of blocks he is willing to accept while simultaneously ensuring that his node tracks consensus. Emin Gün Sirer posed the question of how to evaluate a truly perfect function for block size increase. He asked the community to first agree upon how to evaluate proposals before discussing specific functions. Several meta-level criteria were suggested, including increasing the block size while ensuring that large miners never have an advantage over small miners and increasing block size as much as possible subject to the constraint that 90% of nodes on the network are no more than one minute behind one of the tails of the blockchain 99% of the time. Additionally, the ability to run low-cost fully validating nodes, include additional data into the Bitcoin blockchain, reduce noise in the ledger, and address long-term scalability with well-defined auxiliary protocols to offer high-transaction throughputs were also proposed as important criteria. The discussion highlighted the need to re-evaluate the problem of scalability facing the Bitcoin network and focus on how to deal with the increasing demands on transaction throughput rather than solely on block size increase.The author agrees with the idea of defining a formal set of criteria. Proposals that schedule future increases to the blocksize consensus maximum, or leave it for miners to decide, can't be evaluated without making assumptions about the future. To address this, the author suggests having simulation and benchmarking software that can analyze proposals, give resource consumption benchmark data about average and worst cases, and also give some kind of metric from "mining centralization dynamics simulations." The author believes it would be ideal to have a metric for concrete block sizes, unrelated to the deployment mechanism, proposed activation date, and other details.In response to a suggestion that no user on the network should wait more than an hour to get three confirmations on the blockchain, the author explains that this depends on various factors such as block space demand, the fee paid by the user, local relay and mining policies in the network, the form of the transaction, and even the network topology. There's no consensus rule that can guarantee that all transactions from all users will be included at most three blocks after they are relayed. However, there is a fee estimator that observes the chain and can estimate the market situation to tell you the average number of blocks for a given transaction with a given feerate.The block size debate within the Bitcoin community has sparked a multitude of proposals for future block size increases, with countless alternative functions being suggested. However, instead of discussing specific block size increase functions, the author suggests enunciating what grand goals a truly perfect function would achieve. This meta-question asks what criteria we should look for when evaluating a good proposal, rather than judging individual proposals themselves. Possible meta-goals include increasing block size while ensuring large miners never have an advantage over small miners, increasing block size subject to a constraint on node synchronization, or not increasing block size until a certain date. Defining these meta-criteria before evaluating proposals will help prevent unnecessary proliferation of block size increase proposals. Ultimately, even with meta-criteria in hand, there may be room for disagreement due to uncertainty about the future evolution of network access technologies and node placement. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_OP-CHECKWILDCARDSIGVERIFY-or-Wildcard-Inputs-or-Coalescing-Transactions-.xml b/static/bitcoin-dev/Nov_2015/combined_OP-CHECKWILDCARDSIGVERIFY-or-Wildcard-Inputs-or-Coalescing-Transactions-.xml index 45938303b1..4b27aff6a1 100644 --- a/static/bitcoin-dev/Nov_2015/combined_OP-CHECKWILDCARDSIGVERIFY-or-Wildcard-Inputs-or-Coalescing-Transactions-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_OP-CHECKWILDCARDSIGVERIFY-or-Wildcard-Inputs-or-Coalescing-Transactions-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions" - 2023-08-01T16:55:35.858122+00:00 + Combined summary - OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions" + 2025-10-11T22:16:07.455440+00:00 + python-feedgen Dave Scotese 2015-11-25 17:03:32+00:00 @@ -47,13 +48,13 @@ - python-feedgen + 2 - Combined summary - OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions" - 2023-08-01T16:55:35.858122+00:00 + Combined summary - OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions" + 2025-10-11T22:16:07.455586+00:00 - A proposal has been made for a new type of transaction called the wildcard transaction. The idea is to use a wildcard signature that applies to all UTXOs in a standard form and paid to a particular address, which would then be treated like a time-limited offer to the network to reduce the UTXO set of an address. This could have several advantages, such as reducing the number of UTXOs left in databases and reducing the impact of forked blockchains. However, there are several problems to consider, including limiting outputs to avoid double-spending, guaranteeing that the output is calculated from all inputs involved, and preventing signing with a future date.Several possible solutions were suggested, such as using the highest block height number of transactions or a special form of output specifying only one destination address/script and the amount of fees to pay. The proposal also includes information about a PGP signature, which is used to verify the authenticity and integrity of the message. The bitcoin-dev mailing list, hosted by the Linux Foundation, is mentioned as the platform where the proposal was discussed.Another proposal discussed on the mailing list is the concept of a coalescing transaction. This transaction clears out all funds associated with one address and sends them to another address belonging to the same owner. While this may encourage address reuse and raises concerns about reorgs, it is seen as a way to reduce the UTXO set.The idea of OP_CHECKWILDCARDSIGVERIFY was also discussed, which would allow the consolidation of multiple UTXOs into one larger UTXO. Concerns were raised about address reuse and double spending, but potential solutions were suggested, such as including a block height indicating maximum matching UTXOs and adding a minimum block height to prevent unnecessary scanning. The proposal also discusses the cost of rescanning the entire UTXO set and suggests a special extra mining fee for transactions using this opcode.The email thread also includes discussions about the technical difficulties of listing each UTXO individually during transactions and proposals to coalesce scriptSigs to reduce transaction size and fees. The use of OP_RINGSIGVERIFY for funding transactions and making all-but-the-first scriptSig zero-length are suggested as possible solutions.A new opcode has been introduced that aims to address the issue of small UTXOs and high transaction fees. This opcode, when signed with, allows for all the unspent transaction outputs (UTXOs) to be combined into a single output. By doing so, the transaction fee is reduced as there is only one input involved.While this proposal is still in need of some refinement, it holds potential in solving the problem at hand. The reduction in transaction fees could be beneficial for users, especially those dealing with numerous small UTXOs. Further development and adjustments will likely be necessary to ensure the effectiveness and efficiency of this solution. Nonetheless, the introduction of this new opcode presents a promising possibility for addressing the challenges associated with high transaction fees and small UTXOs.For more information on the topic, please refer to the provided links. 2015-11-25T17:03:32+00:00 + A proposal has been made for a new type of transaction called the wildcard transaction. The idea is to use a wildcard signature that applies to all UTXOs in a standard form and paid to a particular address, which would then be treated like a time-limited offer to the network to reduce the UTXO set of an address. This could have several advantages, such as reducing the number of UTXOs left in databases and reducing the impact of forked blockchains. However, there are several problems to consider, including limiting outputs to avoid double-spending, guaranteeing that the output is calculated from all inputs involved, and preventing signing with a future date.Several possible solutions were suggested, such as using the highest block height number of transactions or a special form of output specifying only one destination address/script and the amount of fees to pay. The proposal also includes information about a PGP signature, which is used to verify the authenticity and integrity of the message. The bitcoin-dev mailing list, hosted by the Linux Foundation, is mentioned as the platform where the proposal was discussed.Another proposal discussed on the mailing list is the concept of a coalescing transaction. This transaction clears out all funds associated with one address and sends them to another address belonging to the same owner. While this may encourage address reuse and raises concerns about reorgs, it is seen as a way to reduce the UTXO set.The idea of OP_CHECKWILDCARDSIGVERIFY was also discussed, which would allow the consolidation of multiple UTXOs into one larger UTXO. Concerns were raised about address reuse and double spending, but potential solutions were suggested, such as including a block height indicating maximum matching UTXOs and adding a minimum block height to prevent unnecessary scanning. The proposal also discusses the cost of rescanning the entire UTXO set and suggests a special extra mining fee for transactions using this opcode.The email thread also includes discussions about the technical difficulties of listing each UTXO individually during transactions and proposals to coalesce scriptSigs to reduce transaction size and fees. The use of OP_RINGSIGVERIFY for funding transactions and making all-but-the-first scriptSig zero-length are suggested as possible solutions.A new opcode has been introduced that aims to address the issue of small UTXOs and high transaction fees. This opcode, when signed with, allows for all the unspent transaction outputs (UTXOs) to be combined into a single output. By doing so, the transaction fee is reduced as there is only one input involved.While this proposal is still in need of some refinement, it holds potential in solving the problem at hand. The reduction in transaction fees could be beneficial for users, especially those dealing with numerous small UTXOs. Further development and adjustments will likely be necessary to ensure the effectiveness and efficiency of this solution. Nonetheless, the introduction of this new opcode presents a promising possibility for addressing the challenges associated with high transaction fees and small UTXOs.For more information on the topic, please refer to the provided links. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml b/static/bitcoin-dev/Nov_2015/combined_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml index 9e3efb6f60..b46d436fe4 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Opt-in-Full-Replace-By-Fee-Full-RBF-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Opt-in Full Replace-By-Fee (Full-RBF) - 2023-08-01T16:53:18.576992+00:00 + 2025-10-11T22:15:46.210468+00:00 + python-feedgen Peter Todd 2015-12-02 09:27:39+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Opt-in Full Replace-By-Fee (Full-RBF) - 2023-08-01T16:53:18.576992+00:00 + 2025-10-11T22:15:46.210591+00:00 - A discussion on the Bitcoin-dev mailing list occurred regarding the use of Sequence for opting in. The CTxOut data structure lacks additional fields for this purpose. One suggestion was to utilize the same scheme as sighash_single, but it raises privacy concerns by exposing change address information. Another proposed option involves pre-committing via a hash and revealing it later, but this approach is complex and not easily feasible with the current transaction data structure.On November 16th, 2015, Peter Todd posted a message on bitcoin-dev discussing the use of Sequence for opting in. He pointed out that it is the only "free-form" field available for this purpose. Luke-Jr proposed opt-in per output, but the CTxOut data structure does not have extra fields for such usage. The message also mentioned questioning the use of the same scheme as sighash_single and suggested considering if input 0 has nSequence... (the rest of the sentence is not provided).Bitcoin Core developers have decided to merge the opt-in Full-RBF pull request. This new feature will enable senders to opt into full-RBF semantics for their transactions, allowing receivers to detect if the sender has done so. Transactions that do not opt-in will still retain the existing "first-seen" mempool semantics. Pending code review, this feature is expected to be included in Bitcoin Core v0.12.0. A transaction is considered to have opted into full-RBF semantics if nSequence < (2^32 - 2), indicating the possibility of the sender reissuing the transaction with a higher fee.The initial version of Replace-by-Fee (RBF) raised controversy due to concerns about double-spending. However, opt-in Full-RBF addresses these concerns by enabling receivers to differentiate between opt-in and non-opt-in transactions. The creation of the opt-in Full-RBF pull request was in response to user feedback, with users desiring more control over the fees paid for transactions. This feature allows users to increase the fee on a transaction that is taking longer than expected to confirm, without worrying about rejection by nodes that do not support RBF.Overall, the opt-in Full-RBF feature offers users greater flexibility and control over their transactions. It also addresses security concerns associated with the original RBF implementation. 2015-12-02T09:27:39+00:00 + A discussion on the Bitcoin-dev mailing list occurred regarding the use of Sequence for opting in. The CTxOut data structure lacks additional fields for this purpose. One suggestion was to utilize the same scheme as sighash_single, but it raises privacy concerns by exposing change address information. Another proposed option involves pre-committing via a hash and revealing it later, but this approach is complex and not easily feasible with the current transaction data structure.On November 16th, 2015, Peter Todd posted a message on bitcoin-dev discussing the use of Sequence for opting in. He pointed out that it is the only "free-form" field available for this purpose. Luke-Jr proposed opt-in per output, but the CTxOut data structure does not have extra fields for such usage. The message also mentioned questioning the use of the same scheme as sighash_single and suggested considering if input 0 has nSequence... (the rest of the sentence is not provided).Bitcoin Core developers have decided to merge the opt-in Full-RBF pull request. This new feature will enable senders to opt into full-RBF semantics for their transactions, allowing receivers to detect if the sender has done so. Transactions that do not opt-in will still retain the existing "first-seen" mempool semantics. Pending code review, this feature is expected to be included in Bitcoin Core v0.12.0. A transaction is considered to have opted into full-RBF semantics if nSequence < (2^32 - 2), indicating the possibility of the sender reissuing the transaction with a higher fee.The initial version of Replace-by-Fee (RBF) raised controversy due to concerns about double-spending. However, opt-in Full-RBF addresses these concerns by enabling receivers to differentiate between opt-in and non-opt-in transactions. The creation of the opt-in Full-RBF pull request was in response to user feedback, with users desiring more control over the fees paid for transactions. This feature allows users to increase the fee on a transaction that is taking longer than expected to confirm, without worrying about rejection by nodes that do not support RBF.Overall, the opt-in Full-RBF feature offers users greater flexibility and control over their transactions. It also addresses security concerns associated with the original RBF implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml b/static/bitcoin-dev/Nov_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml index dea50bb070..5f5e8b0aff 100644 --- a/static/bitcoin-dev/Nov_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml +++ b/static/bitcoin-dev/Nov_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC - BIP: URI scheme for Blockchain exploration - 2023-08-01T15:44:07.597614+00:00 + 2025-10-11T22:16:32.944968+00:00 + python-feedgen Marco Pontello 2015-11-18 12:31:46+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - RFC - BIP: URI scheme for Blockchain exploration - 2023-08-01T15:44:07.597614+00:00 + 2025-10-11T22:16:32.945193+00:00 - A proposed new URI scheme for blockchain exploration has been submitted by Marco Pontello. The purpose of this URI scheme is to enable users to handle all requests for details about blocks, transactions, and addresses on a blockchain explorer with their preferred tool, whether it be a web service or a local application. Currently, Bitcoin clients typically point to an arbitrary blockchain explorer when the user looks for transaction details, and sometimes resorting to cut-and-paste is necessary. The same happens with posts and messages that reference specific transactions or blocks, if they provide links at all.The proposed URI follows a simple form: "blockchain:" followed by the block or transaction ID. The proposal suggests that keeping it simple should be practical enough, and blockchain explorers can apply the same disambiguation rules they are already using to process the usual search box. From the perspective of a wallet developer or other tool that needs to show blockchain references, using this scheme means they can simply make it a blockchain link and be done with it without worrying about any specific blockchain explorer or providing a means for the user to select one.The proposal also discusses improving the syntax of blockchain URLs. Participants suggest different approaches, such as making the chain part optional or using the "authority" component of the URL to identify the chain. There is also discussion about allowing well-known chains to register names as alternatives to the hash syntax. The use of the genesis block hash as a method for identifying a reference to a transaction is proposed, along with the idea of using name constants as a simpler alternative.Overall, the goal of the proposal is to create a standard URI scheme for blockchain exploration that all explorers would understand. This would provide users with the convenience of using their preferred explorer and simplify the process for wallet developers and other tools that need to show blockchain references. 2015-11-18T12:31:46+00:00 + A proposed new URI scheme for blockchain exploration has been submitted by Marco Pontello. The purpose of this URI scheme is to enable users to handle all requests for details about blocks, transactions, and addresses on a blockchain explorer with their preferred tool, whether it be a web service or a local application. Currently, Bitcoin clients typically point to an arbitrary blockchain explorer when the user looks for transaction details, and sometimes resorting to cut-and-paste is necessary. The same happens with posts and messages that reference specific transactions or blocks, if they provide links at all.The proposed URI follows a simple form: "blockchain:" followed by the block or transaction ID. The proposal suggests that keeping it simple should be practical enough, and blockchain explorers can apply the same disambiguation rules they are already using to process the usual search box. From the perspective of a wallet developer or other tool that needs to show blockchain references, using this scheme means they can simply make it a blockchain link and be done with it without worrying about any specific blockchain explorer or providing a means for the user to select one.The proposal also discusses improving the syntax of blockchain URLs. Participants suggest different approaches, such as making the chain part optional or using the "authority" component of the URL to identify the chain. There is also discussion about allowing well-known chains to register names as alternatives to the hash syntax. The use of the genesis block hash as a method for identifying a reference to a transaction is proposed, along with the idea of using name constants as a simpler alternative.Overall, the goal of the proposal is to create a standard URI scheme for blockchain exploration that all explorers would understand. This would provide users with the convenience of using their preferred explorer and simplify the process for wallet developers and other tools that need to show blockchain references. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Ramping-up-with-bitcoin-core-engineering-.xml b/static/bitcoin-dev/Nov_2015/combined_Ramping-up-with-bitcoin-core-engineering-.xml index 2c70e1d835..bd6b17879b 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Ramping-up-with-bitcoin-core-engineering-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Ramping-up-with-bitcoin-core-engineering-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ramping up with bitcoin core engineering? - 2023-08-01T16:48:01.426791+00:00 + 2025-10-11T22:16:26.568237+00:00 + python-feedgen Eric Martindale 2015-11-02 21:05:39+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Ramping up with bitcoin core engineering? - 2023-08-01T16:48:01.426791+00:00 + 2025-10-11T22:16:26.568427+00:00 - The Bitcoin.org Development Guide has seen significant growth this year, providing valuable resources for individuals interested in contributing to the development of Bitcoin Core. There are two comprehensive introductions available on the website, catering to different levels of understanding. The first introduction provides a broad overview of how developers can contribute, while the second offers an in-depth reference to understand the entire system.For those seeking further involvement or information, there are additional resources to explore. The Bitcoin Wiki is a valuable source of information, with extensive documentation on various aspects of Bitcoin Core development. Additionally, the #bitcoin-dev room on Freenode is a platform where individuals can engage with the wider developer community and exchange ideas.One user named Panos Sakkos expressed keen interest in contributing to the development of Bitcoin Core. He specifically mentioned his willingness to start by writing unit tests and also offered assistance with test efforts if required. In his query, Panos asked if there was any documentation or ramp-up process available to help him familiarize himself with the project's tools and infrastructure.Overall, the Bitcoin.org Development Guide serves as a hub for aspiring contributors, offering a range of resources and avenues for engagement. Whether one is a beginner looking for an introduction or an experienced developer seeking specific information, the guide provides a comprehensive foundation for involvement in Bitcoin Core development. 2015-11-02T21:05:39+00:00 + The Bitcoin.org Development Guide has seen significant growth this year, providing valuable resources for individuals interested in contributing to the development of Bitcoin Core. There are two comprehensive introductions available on the website, catering to different levels of understanding. The first introduction provides a broad overview of how developers can contribute, while the second offers an in-depth reference to understand the entire system.For those seeking further involvement or information, there are additional resources to explore. The Bitcoin Wiki is a valuable source of information, with extensive documentation on various aspects of Bitcoin Core development. Additionally, the #bitcoin-dev room on Freenode is a platform where individuals can engage with the wider developer community and exchange ideas.One user named Panos Sakkos expressed keen interest in contributing to the development of Bitcoin Core. He specifically mentioned his willingness to start by writing unit tests and also offered assistance with test efforts if required. In his query, Panos asked if there was any documentation or ramp-up process available to help him familiarize himself with the project's tools and infrastructure.Overall, the Bitcoin.org Development Guide serves as a hub for aspiring contributors, offering a range of resources and avenues for engagement. Whether one is a beginner looking for an introduction or an experienced developer seeking specific information, the guide provides a comprehensive foundation for involvement in Bitcoin Core development. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Test-Results-for-Datasstream-Compression-of-Blocks-and-Tx-s.xml b/static/bitcoin-dev/Nov_2015/combined_Test-Results-for-Datasstream-Compression-of-Blocks-and-Tx-s.xml index 17f6588940..e3c3ea7410 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Test-Results-for-Datasstream-Compression-of-Blocks-and-Tx-s.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Test-Results-for-Datasstream-Compression-of-Blocks-and-Tx-s.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Test Results for : Datasstream Compression of Blocks and Tx's - 2023-08-01T16:56:32.042162+00:00 + 2025-10-11T22:16:13.828550+00:00 + python-feedgen Jeff Garzik 2015-11-30 16:53:39+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Test Results for : Datasstream Compression of Blocks and Tx's - 2023-08-01T16:56:32.042162+00:00 + 2025-10-11T22:16:13.828677+00:00 - The final analysis of testing with the reference implementation for compressing blocks and transactions reveals interesting findings. The implementation involves concatenating blocks and transactions whenever possible, resulting in data sizes ranging from 1-2MB. The analysis focuses on comparing the performance of Zlib and the LZOx library in terms of syncing the first part of the blockchain.With latency present on the network, all compression libraries show significant improvements compared to uncompressed data. While Zlib offers higher compression capabilities, LZO proves to be faster and more scalable. This is particularly beneficial for users prioritizing performance over compression. At the high end, LZO provides decent compression that approaches Zlib's level, but at a higher cost in terms of processing time. This makes it a suitable choice for those seeking to save bandwidth.When considering compression ratios, Zlib emerges as the clear winner in terms of compressibility. LZOx-999 comes close to Zlib but comes with some trade-offs. As compression ratios increase, LZOx-999 performs significantly worse than Zlib. On the other hand, LZO1x stands out as the fastest option. Interestingly, as file sizes increase, the time taken by LZO1x remains relatively stable, hardly increasing at all.Overall, LZO demonstrates superior speed on the lower end of the spectrum but lags behind (5 to 6 times slower) on the higher end. These findings provide valuable insights into the performance and capabilities of Zlib and the LZOx library when it comes to compressing blocks and transactions. Users can now make informed decisions based on their specific requirements, whether they prioritize compression or seek optimal performance. 2015-11-30T16:53:39+00:00 + The final analysis of testing with the reference implementation for compressing blocks and transactions reveals interesting findings. The implementation involves concatenating blocks and transactions whenever possible, resulting in data sizes ranging from 1-2MB. The analysis focuses on comparing the performance of Zlib and the LZOx library in terms of syncing the first part of the blockchain.With latency present on the network, all compression libraries show significant improvements compared to uncompressed data. While Zlib offers higher compression capabilities, LZO proves to be faster and more scalable. This is particularly beneficial for users prioritizing performance over compression. At the high end, LZO provides decent compression that approaches Zlib's level, but at a higher cost in terms of processing time. This makes it a suitable choice for those seeking to save bandwidth.When considering compression ratios, Zlib emerges as the clear winner in terms of compressibility. LZOx-999 comes close to Zlib but comes with some trade-offs. As compression ratios increase, LZOx-999 performs significantly worse than Zlib. On the other hand, LZO1x stands out as the fastest option. Interestingly, as file sizes increase, the time taken by LZO1x remains relatively stable, hardly increasing at all.Overall, LZO demonstrates superior speed on the lower end of the spectrum but lags behind (5 to 6 times slower) on the higher end. These findings provide valuable insights into the performance and capabilities of Zlib and the LZOx library when it comes to compressing blocks and transactions. Users can now make informed decisions based on their specific requirements, whether they prioritize compression or seek optimal performance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Upcoming-Transaction-Priority-Changes.xml b/static/bitcoin-dev/Nov_2015/combined_Upcoming-Transaction-Priority-Changes.xml index 56cc7348d1..fc6d792d08 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Upcoming-Transaction-Priority-Changes.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Upcoming-Transaction-Priority-Changes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Upcoming Transaction Priority Changes - 2023-08-01T16:50:20.604277+00:00 + 2025-10-11T22:16:39.318527+00:00 + python-feedgen Luke Dashjr 2015-11-12 21:26:38+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Upcoming Transaction Priority Changes - 2023-08-01T16:50:20.604277+00:00 + 2025-10-11T22:16:39.318675+00:00 - The conversation on the bitcoin-dev mailing list focuses on the challenges of maintaining mining policy while also allowing priority-based transactions in a limited mempool world. One of the examples discussed is issue #6992, which recently closed. Another issue highlighted is #6357, which raises concerns about potential logic breaking in future changes. It is suggested that unit tests could address this concern. The usefulness and complexity of free transactions and rebroadcasting them if they are still in memory pools are also debated.In another conversation between Jorge Timón and Luke Dashjr, the use of starting priority in the mining code is discussed. Luke argues that it should be optional, while Jorge believes that maintaining the current priority algorithm is not expensive. The default block priority size is also debated, with Luke objecting to changing defaults as it could influence miner policy. However, he agrees that priority is currently the best metric for ensuring legitimate transactions get mined despite spam attacks.On November 12, 2015, the bitcoin-dev mailing list discusses the implementation of mining code and the block priority size. Luke suggests that starting priority should be optional for ease of implementation, while the default block priority size should be set to 0. Matt agrees with the former but disagrees with changing defaults as it could influence miner policy. The idea of merging priority, feerate, and sigoprate into one number is proposed by Chun Wang, with some members supporting customizable cost and reward. The main issue raised is that priority is not integrated into the reward function and changing it may slow down other improvements in mempool limits.The Bitcoin network is facing issues with mempool bloating and GBT latency due to the priority space. Free transactions are not getting mined and cleared from the mempool anymore. To prevent mempool size increase during a spam attack, setting minrelaytxfee=0.0001 is not enough; limitfreerelay=0 is also necessary to prevent GBT latency degradation. However, spammers generally cannot use the priority space, and it is an important way for legitimate users to have their transactions processed cheaply despite ongoing spam attempts.In a conversation with Chun Wang, Luke expresses confusion regarding Chun's statement that the priority space is "always the best place for spam nowadays." Luke argues that spammers generally cannot use the priority space and that it is actually beneficial for legitimate users. He asks Chun to explain their reasoning behind the statement.Email exchanges between Matt Corallo and Luke Dashjr discuss proposed changes for Bitcoin version 0.12. Matt mentions disabling high-priority relay when mempools are full and agrees to use starting priority in mining code for ease of implementation. However, Luke disagrees with changing defaults and suggests changing the priority size to 0 instead, which he believes is the best place for spam. He also proposes merging priority, feerate, and sigoprate into one number. The discussion revolves around finding the right balance between maintaining mining policy and preserving the ability for priority-based transactions.During an IRC meeting, the focus is on handling the old "transaction priority" feature in Bitcoin version 0.12. There is an agreement that it will either be removed or replaced with something less costly to maintain in the future. With mempool limiting already implemented, high-priority relay is disabled when mempools are full. For version 0.12, the mining code will use starting priority for ease of implementation, the default block priority size will be set to 0, and the wallet will no longer create 0-fee transactions when mempool limiting is in effect. Users are advised to exercise caution when relying on priority to mine their transactions and analyze previous blocks to ensure their transactions will be relayed. 2015-11-12T21:26:38+00:00 + The conversation on the bitcoin-dev mailing list focuses on the challenges of maintaining mining policy while also allowing priority-based transactions in a limited mempool world. One of the examples discussed is issue #6992, which recently closed. Another issue highlighted is #6357, which raises concerns about potential logic breaking in future changes. It is suggested that unit tests could address this concern. The usefulness and complexity of free transactions and rebroadcasting them if they are still in memory pools are also debated.In another conversation between Jorge Timón and Luke Dashjr, the use of starting priority in the mining code is discussed. Luke argues that it should be optional, while Jorge believes that maintaining the current priority algorithm is not expensive. The default block priority size is also debated, with Luke objecting to changing defaults as it could influence miner policy. However, he agrees that priority is currently the best metric for ensuring legitimate transactions get mined despite spam attacks.On November 12, 2015, the bitcoin-dev mailing list discusses the implementation of mining code and the block priority size. Luke suggests that starting priority should be optional for ease of implementation, while the default block priority size should be set to 0. Matt agrees with the former but disagrees with changing defaults as it could influence miner policy. The idea of merging priority, feerate, and sigoprate into one number is proposed by Chun Wang, with some members supporting customizable cost and reward. The main issue raised is that priority is not integrated into the reward function and changing it may slow down other improvements in mempool limits.The Bitcoin network is facing issues with mempool bloating and GBT latency due to the priority space. Free transactions are not getting mined and cleared from the mempool anymore. To prevent mempool size increase during a spam attack, setting minrelaytxfee=0.0001 is not enough; limitfreerelay=0 is also necessary to prevent GBT latency degradation. However, spammers generally cannot use the priority space, and it is an important way for legitimate users to have their transactions processed cheaply despite ongoing spam attempts.In a conversation with Chun Wang, Luke expresses confusion regarding Chun's statement that the priority space is "always the best place for spam nowadays." Luke argues that spammers generally cannot use the priority space and that it is actually beneficial for legitimate users. He asks Chun to explain their reasoning behind the statement.Email exchanges between Matt Corallo and Luke Dashjr discuss proposed changes for Bitcoin version 0.12. Matt mentions disabling high-priority relay when mempools are full and agrees to use starting priority in mining code for ease of implementation. However, Luke disagrees with changing defaults and suggests changing the priority size to 0 instead, which he believes is the best place for spam. He also proposes merging priority, feerate, and sigoprate into one number. The discussion revolves around finding the right balance between maintaining mining policy and preserving the ability for priority-based transactions.During an IRC meeting, the focus is on handling the old "transaction priority" feature in Bitcoin version 0.12. There is an agreement that it will either be removed or replaced with something less costly to maintain in the future. With mempool limiting already implemented, high-priority relay is disabled when mempools are full. For version 0.12, the mining code will use starting priority for ease of implementation, the default block priority size will be set to 0, and the wallet will no longer create 0-fee transactions when mempool limiting is in effect. Users are advised to exercise caution when relying on priority to mine their transactions and analyze previous blocks to ensure their transactions will be relayed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_Use-CPFP-as-consensus-critical-for-Full-RBF.xml b/static/bitcoin-dev/Nov_2015/combined_Use-CPFP-as-consensus-critical-for-Full-RBF.xml index 9323a31d27..85f7ca8b3a 100644 --- a/static/bitcoin-dev/Nov_2015/combined_Use-CPFP-as-consensus-critical-for-Full-RBF.xml +++ b/static/bitcoin-dev/Nov_2015/combined_Use-CPFP-as-consensus-critical-for-Full-RBF.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Use CPFP as consensus critical for Full-RBF - 2023-08-01T16:56:46.999409+00:00 + 2025-10-11T22:16:18.075915+00:00 + python-feedgen Jorge Timón 2015-11-29 11:55:08+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Use CPFP as consensus critical for Full-RBF - 2023-08-01T16:56:46.999409+00:00 + 2025-10-11T22:16:18.076068+00:00 - The email thread revolves around the relay/mining policy of CPFP (Child Pays for Parent) and RBF (Replace-By-Fee) transactions. The consensus rules cannot be applied to these policies because it is impossible to determine which transactions have been received by a specific peer and at what time. Consensus rules can only validate information present in the blockchain. The main focus of the discussion is to make CPFP consensus critical for all Full-RBF transactions, aiming to enhance the safety of RBF usage. While RBF is necessary for users to rectify mistakes, distinguishing between legitimate and malicious RBF transactions poses a challenge. To address this, the recipient needs to sign off on the RBF transaction they are aware of using CPFP. However, the implementation of CPFP is crucial as it should prevent the sender from signing off their own transactions. The proposed solution suggests allowing Full-RBF until the point where a recipient creates a CPFP transaction. Any Full-RBF transaction that has not been signed off with a CPFP would be considered invalid for inclusion in a block, effectively turning it into a consensus rule rather than a local policy. This integration of CPFP and Full-RBF aims to make RBF safer to use.The author emphasizes the importance of CPFP in enabling merchants to bear the burden of fees. Combining CPFP with Full-RBF would greatly improve the safety of RBF transactions. Additionally, the author highlights the benefits of opt-in RBF, which eliminates the need for trust in miners. The inclusion of opt-in flags within transactions enables Full-RBF transactions to become a consensus rule rather than a local policy.In summary, this discussion explores the safety concerns associated with RBF transactions and proposes the integration of CPFP consensus to enhance security. The introduction of opt-in RBF and the use of CPFP would make RBF transactions safer and enable merchants to manage fees more effectively. 2015-11-29T11:55:08+00:00 + The email thread revolves around the relay/mining policy of CPFP (Child Pays for Parent) and RBF (Replace-By-Fee) transactions. The consensus rules cannot be applied to these policies because it is impossible to determine which transactions have been received by a specific peer and at what time. Consensus rules can only validate information present in the blockchain. The main focus of the discussion is to make CPFP consensus critical for all Full-RBF transactions, aiming to enhance the safety of RBF usage. While RBF is necessary for users to rectify mistakes, distinguishing between legitimate and malicious RBF transactions poses a challenge. To address this, the recipient needs to sign off on the RBF transaction they are aware of using CPFP. However, the implementation of CPFP is crucial as it should prevent the sender from signing off their own transactions. The proposed solution suggests allowing Full-RBF until the point where a recipient creates a CPFP transaction. Any Full-RBF transaction that has not been signed off with a CPFP would be considered invalid for inclusion in a block, effectively turning it into a consensus rule rather than a local policy. This integration of CPFP and Full-RBF aims to make RBF safer to use.The author emphasizes the importance of CPFP in enabling merchants to bear the burden of fees. Combining CPFP with Full-RBF would greatly improve the safety of RBF transactions. Additionally, the author highlights the benefits of opt-in RBF, which eliminates the need for trust in miners. The inclusion of opt-in flags within transactions enables Full-RBF transactions to become a consensus rule rather than a local policy.In summary, this discussion explores the safety concerns associated with RBF transactions and proposes the integration of CPFP consensus to enhance security. The introduction of opt-in RBF and the use of CPFP would make RBF transactions safer and enable merchants to manage fees more effectively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_further-test-results-for-Datastream-Compression-of-Blocks-and-Tx-s-.xml b/static/bitcoin-dev/Nov_2015/combined_further-test-results-for-Datastream-Compression-of-Blocks-and-Tx-s-.xml index 71bc52f5bd..e7a16960d0 100644 --- a/static/bitcoin-dev/Nov_2015/combined_further-test-results-for-Datastream-Compression-of-Blocks-and-Tx-s-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_further-test-results-for-Datastream-Compression-of-Blocks-and-Tx-s-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - further test results for : "Datastream Compression of Blocks and Tx's" - 2023-08-01T16:56:18.845595+00:00 + Combined summary - further test results for : "Datastream Compression of Blocks and Tx's" + 2025-10-11T22:16:43.570323+00:00 + python-feedgen Peter Tschipper 2015-11-29 05:15:32+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 - Combined summary - further test results for : "Datastream Compression of Blocks and Tx's" - 2023-08-01T16:56:18.845595+00:00 + Combined summary - further test results for : "Datastream Compression of Blocks and Tx's" + 2025-10-11T22:16:43.570524+00:00 - The conversation between Jonathan Toomim and Peter Tschipper on bitcoin-dev revolves around the concept of compression ratio. Toomim clarifies that compression ratio refers to the ratio of compressed to uncompressed data, while Tschipper seems to be using (1 - compressed/uncompressed) to describe size reduction. Tschipper provides a table showcasing the compression ratios achieved by different methods for various data sizes. The table reveals that Zlib is the most effective in compressing data, followed closely by LZOx-999, albeit at a cost. The compression percentages for different data ranges are also displayed in the table.The term "compression ratio" is often misunderstood as referring to size reduction instead of the actual ratio of compressed to uncompressed data. In November 2015, Peter Tschipper shares data on compression ratios achieved by different methods on bitcoin-dev. The results indicate that Zlib is highly efficient in compression, with LZOx-999 being a close contender but at a higher cost. The data is presented in a table, illustrating the compression ratios achieved for different file sizes. Specifically, Zlib-1 and Zlib-6 achieve the highest compression ratios for files ranging from 0-250b and 250-500b, respectively. Across all file size ranges, LZOx-1 and LZOx-999 yield lower compression ratios compared to Zlib.The study also examines the performance of the reference implementation in compressing blocks and transactions. By concatenating blocks and transactions, the resulting data sizes fall within the 1-2MB range. Compression libraries were tested with and without latency, and it was found that all performed better when latency was present on the network. Although there is a preference for higher compression provided by Zlib, LZO is favored due to its speed, scalability, and lower compression setting. Furthermore, the compression ratios achieved for different data sizes are analyzed, with Zlib emerging as the clear winner in terms of compressibility. LZOx-999 comes close but at a higher cost. The time taken to compress data of varying sizes is also examined, revealing that LZO1x is the fastest option. As file sizes increase, LZO1x shows minimal increases in compression time. However, as compression ratios increase, LZOx-999 performs significantly worse than Zlib. Jeff Garzik suggests the need for a fallback path to non-compressed data in case compression fails or crashes.The discussion on the bitcoin-dev mailing list focuses on the idea of negotiating local trade-off decisions between peers instead of making it a mandatory feature of the P2P network. One participant highlights that achieving 25% bandwidth savings is significant, especially for those running full nodes in countries with limited internet bandwidth and data caps. The conversation is led by Jonathan Corgan from Corgan Labs, a company specializing in SDR training and development services. Peter Ts's recent data supports the notion that most blocks and transactions contain runs of zeroes and/or highly common bit-patterns, which contributes to effective compression even at smaller sizes. Tier Nolan suggests focusing solely on compressing blocks for historical data and introducing a "cblocks" message to handle multiple blocks. Similarly, transactions could be combined and compressed as "ctxs". Alternatively, a compressed message holder could be defined, although its complexity may outweigh its benefits.The thread concludes with information on how to subscribe to the bitcoin-dev mailing list. 2015-11-29T05:15:32+00:00 + The conversation between Jonathan Toomim and Peter Tschipper on bitcoin-dev revolves around the concept of compression ratio. Toomim clarifies that compression ratio refers to the ratio of compressed to uncompressed data, while Tschipper seems to be using (1 - compressed/uncompressed) to describe size reduction. Tschipper provides a table showcasing the compression ratios achieved by different methods for various data sizes. The table reveals that Zlib is the most effective in compressing data, followed closely by LZOx-999, albeit at a cost. The compression percentages for different data ranges are also displayed in the table.The term "compression ratio" is often misunderstood as referring to size reduction instead of the actual ratio of compressed to uncompressed data. In November 2015, Peter Tschipper shares data on compression ratios achieved by different methods on bitcoin-dev. The results indicate that Zlib is highly efficient in compression, with LZOx-999 being a close contender but at a higher cost. The data is presented in a table, illustrating the compression ratios achieved for different file sizes. Specifically, Zlib-1 and Zlib-6 achieve the highest compression ratios for files ranging from 0-250b and 250-500b, respectively. Across all file size ranges, LZOx-1 and LZOx-999 yield lower compression ratios compared to Zlib.The study also examines the performance of the reference implementation in compressing blocks and transactions. By concatenating blocks and transactions, the resulting data sizes fall within the 1-2MB range. Compression libraries were tested with and without latency, and it was found that all performed better when latency was present on the network. Although there is a preference for higher compression provided by Zlib, LZO is favored due to its speed, scalability, and lower compression setting. Furthermore, the compression ratios achieved for different data sizes are analyzed, with Zlib emerging as the clear winner in terms of compressibility. LZOx-999 comes close but at a higher cost. The time taken to compress data of varying sizes is also examined, revealing that LZO1x is the fastest option. As file sizes increase, LZO1x shows minimal increases in compression time. However, as compression ratios increase, LZOx-999 performs significantly worse than Zlib. Jeff Garzik suggests the need for a fallback path to non-compressed data in case compression fails or crashes.The discussion on the bitcoin-dev mailing list focuses on the idea of negotiating local trade-off decisions between peers instead of making it a mandatory feature of the P2P network. One participant highlights that achieving 25% bandwidth savings is significant, especially for those running full nodes in countries with limited internet bandwidth and data caps. The conversation is led by Jonathan Corgan from Corgan Labs, a company specializing in SDR training and development services. Peter Ts's recent data supports the notion that most blocks and transactions contain runs of zeroes and/or highly common bit-patterns, which contributes to effective compression even at smaller sizes. Tier Nolan suggests focusing solely on compressing blocks for historical data and introducing a "cblocks" message to handle multiple blocks. Similarly, transactions could be combined and compressed as "ctxs". Alternatively, a compressed message holder could be defined, although its complexity may outweigh its benefits.The thread concludes with information on how to subscribe to the bitcoin-dev mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_request-BIP-number-for-Support-for-Datastream-Compression-.xml b/static/bitcoin-dev/Nov_2015/combined_request-BIP-number-for-Support-for-Datastream-Compression-.xml index 1db5e678eb..1e807027ef 100644 --- a/static/bitcoin-dev/Nov_2015/combined_request-BIP-number-for-Support-for-Datastream-Compression-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_request-BIP-number-for-Support-for-Datastream-Compression-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - request BIP number for: "Support for Datastream Compression" - 2023-08-01T16:49:52.058123+00:00 + Combined summary - request BIP number for: "Support for Datastream Compression" + 2025-10-11T22:16:47.818200+00:00 + python-feedgen Peter Tschipper 2015-11-11 19:11:13+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 - Combined summary - request BIP number for: "Support for Datastream Compression" - 2023-08-01T16:49:52.058123+00:00 + Combined summary - request BIP number for: "Support for Datastream Compression" + 2025-10-11T22:16:47.818444+00:00 - A proposal has been made to incorporate datastream compression into Bitcoin's block relay mechanism. The proposal suggests compressing the data before sending, initially for blocks but potentially for transactions as well. It is estimated that this compression could result in an average of 20% block compression and take 90 milliseconds to compress a full block on a slow laptop.The main advantage of implementing this feature would be to reduce bandwidth usage, although there may also be a slight performance gain during transmission, especially in areas with higher network latency. However, it is important to note that the decision to use this compression method is up to individual nodes, as there are trade-offs between bandwidth savings, CPU performance, and latency.Concerns were raised about the security track record of Zlib, which is the current compression method used by Bitcoin, and its potential vulnerabilities. It was suggested that LZO compression could provide better compression but at the cost of CPU performance.The discussion also touched on the idea of combining multiple blocks into a single "cblocks" message and combining transactions together and compressing them as "ctxs". This would further optimize compression and reduce bandwidth usage. Most blocks and transactions have runs of zeroes and/or highly common bit-patterns, which contributes to useful compression even at smaller sizes.Overall, the conversation revolved around finding ways to save bandwidth in transmitting blocks and transactions while considering the trade-offs between compression ratios, CPU performance, and security. The consensus was that these trade-off decisions should be made locally and negotiated between peers rather than being a required feature of the network P2P.The author of the proposal has submitted a pull request on Bitcoin Core, numbered #6973, for Zlib Block Compression for block relay. The request was made at the request of @sipa, and it is recommended that a Bitcoin Improvement Proposal (BIP) be associated with it. If accepted, the author suggests using the more generic title "Support for Datastream Compression" instead of "Zlib Compression for block relay," as the feature could also be used for transactions in the future. 2015-11-11T19:11:13+00:00 + A proposal has been made to incorporate datastream compression into Bitcoin's block relay mechanism. The proposal suggests compressing the data before sending, initially for blocks but potentially for transactions as well. It is estimated that this compression could result in an average of 20% block compression and take 90 milliseconds to compress a full block on a slow laptop.The main advantage of implementing this feature would be to reduce bandwidth usage, although there may also be a slight performance gain during transmission, especially in areas with higher network latency. However, it is important to note that the decision to use this compression method is up to individual nodes, as there are trade-offs between bandwidth savings, CPU performance, and latency.Concerns were raised about the security track record of Zlib, which is the current compression method used by Bitcoin, and its potential vulnerabilities. It was suggested that LZO compression could provide better compression but at the cost of CPU performance.The discussion also touched on the idea of combining multiple blocks into a single "cblocks" message and combining transactions together and compressing them as "ctxs". This would further optimize compression and reduce bandwidth usage. Most blocks and transactions have runs of zeroes and/or highly common bit-patterns, which contributes to useful compression even at smaller sizes.Overall, the conversation revolved around finding ways to save bandwidth in transmitting blocks and transactions while considering the trade-offs between compression ratios, CPU performance, and security. The consensus was that these trade-off decisions should be made locally and negotiated between peers rather than being a required feature of the network P2P.The author of the proposal has submitted a pull request on Bitcoin Core, numbered #6973, for Zlib Block Compression for block relay. The request was made at the request of @sipa, and it is recommended that a Bitcoin Improvement Proposal (BIP) be associated with it. If accepted, the author suggests using the more generic title "Support for Datastream Compression" instead of "Zlib Compression for block relay," as the feature could also be used for transactions in the future. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_request-to-use-service-bit-28-for-testing.xml b/static/bitcoin-dev/Nov_2015/combined_request-to-use-service-bit-28-for-testing.xml index b347d432e3..0b90180404 100644 --- a/static/bitcoin-dev/Nov_2015/combined_request-to-use-service-bit-28-for-testing.xml +++ b/static/bitcoin-dev/Nov_2015/combined_request-to-use-service-bit-28-for-testing.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - request to use service bit 28 for testing - 2023-08-01T16:53:02.372451+00:00 + 2025-10-11T22:16:22.321367+00:00 + python-feedgen Peter Todd 2015-11-16 23:24:05+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - request to use service bit 28 for testing - 2023-08-01T16:53:02.372451+00:00 + 2025-10-11T22:16:22.321510+00:00 - On November 14, 2015, Peter Tschipper reached out to the bitcoin-dev community via a post on the platform. In the post, Tschipper requested permission to utilize service bit 28 for the purpose of testing the block compression prototype. The author seemed to be interested in determining whether anyone objected to this request or if the service bit was already being used by someone else. In response to Tschipper's inquiry, another user responded affirmatively, stating that there were no objections to the use of service bit 28. Additionally, this user mentioned that bit 26 was currently being utilized to indicate full-RBF (replace-by-fee) support in their replace-by-fee branch. Furthermore, the user suggested that the preferential peering code from their replace-by-fee branch might prove helpful for testing purposes.Overall, Tschipper's message appeared to be a polite inquiry, as evidenced by the author's expression of gratitude in advance. 2015-11-16T23:24:05+00:00 + On November 14, 2015, Peter Tschipper reached out to the bitcoin-dev community via a post on the platform. In the post, Tschipper requested permission to utilize service bit 28 for the purpose of testing the block compression prototype. The author seemed to be interested in determining whether anyone objected to this request or if the service bit was already being used by someone else. In response to Tschipper's inquiry, another user responded affirmatively, stating that there were no objections to the use of service bit 28. Additionally, this user mentioned that bit 26 was currently being utilized to indicate full-RBF (replace-by-fee) support in their replace-by-fee branch. Furthermore, the user suggested that the preferential peering code from their replace-by-fee branch might prove helpful for testing purposes.Overall, Tschipper's message appeared to be a polite inquiry, as evidenced by the author's expression of gratitude in advance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2015/combined_summarising-security-assumptions-re-cost-metrics-.xml b/static/bitcoin-dev/Nov_2015/combined_summarising-security-assumptions-re-cost-metrics-.xml index 387d0dc686..7da31e8162 100644 --- a/static/bitcoin-dev/Nov_2015/combined_summarising-security-assumptions-re-cost-metrics-.xml +++ b/static/bitcoin-dev/Nov_2015/combined_summarising-security-assumptions-re-cost-metrics-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - summarising security assumptions (re cost metrics) - 2023-08-01T16:49:01.472527+00:00 + 2025-10-11T22:16:24.446116+00:00 + python-feedgen Gavin Andresen 2015-11-09 16:27:22+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - summarising security assumptions (re cost metrics) - 2023-08-01T16:49:01.472527+00:00 + 2025-10-11T22:16:24.446322+00:00 - In an email exchange between Bryan Bishop and Gavin Andresen, they discuss the concept of "key-holder decentralization," which refers to both the number of key-holders and the number of transactions they make. They mention that a small maximum block size would limit the system to institutions with large-value transactions. The Lightning Network is not a solution to this problem as it still relies on the main chain and can be affected by insufficient fees. Andresen provides a link to a video for further information.Gavin Andresen expresses disappointment over the lack of discussion about the key-holder versus validator decentralization balance tradeoff. Bryan seeks clarification on the definition of "key-holder decentralization" and its implications. They also discuss the use of Lightning Network payment channels and BTC-pegged merge-mined chains to handle transaction demand. Further clarification is requested regarding concerns about a scenario with only 10 key holders.Adam Back and Gavin Andresen discuss the security assumptions and design requirements of Bitcoin. They highlight the importance of economically dependent full nodes in assuring Bitcoin's security. They emphasize that small miners should not be significantly disadvantaged compared to larger miners, and there should be no collusion advantages leading to policy centralization. The balance between validators and miners decentralization is also discussed. They suggest best practices such as simplicity and an incremental approach to deployment.A discussion on the Bitcoin-dev mailing list involves Chris Priest, Adam Back, and Eric Voskuil. They debate the impact of widespread use of APIs on network security. Priest argues that the system's security is independent of the ratio between full nodes and lightweight nodes, while Back notes the need for users to understand the security implications of using APIs and trust the third-party providers. Voskuil believes that centralized Bitcoin APIs contribute to reducing network security over time.Another discussion on the mailing list involves Eric Voskuil and Adam Back. They address the importance of economically dependent full nodes (validators) in ensuring Bitcoin's security. They mention the weakening of validators due to non-validating wallet software, centralized wallets, and centralized Bitcoin APIs. They also discuss the availability of multiple blockexplorer APIs, which Voskuil sees as beneficial for decentralization.The security assumption behind Bitcoin's need for decentralization is discussed by Jeremy Rubin. He highlights the property that "$10 in the hand of 10 people is more than $50 in the hand of two, or $100 in the hand of one" and its importance in transacting large amounts with Bitcoin. Validators play a crucial role in enforcing consensus rules and assuring security. The trade-off between weak miner decentralization and good validator decentralization is mentioned. Eric Voskuil emphasizes the underappreciated importance of validator decentralization and the potential risks of relying on centralized Bitcoin APIs.Adam Back shares his thoughts on economically dependent full nodes in Bitcoin's security model. He emphasizes their role in enforcing consensus rules and preventing maliciously crafted blocks from eroding security. He discusses the tradeoff between weak miner decentralization and good validator decentralization, stating that both being weak is risky. He points out that the proliferation of non-validating wallet software, centralized web wallets, and centralized Bitcoin APIs has weakened the security model, which he believes is not fully understood. Developers tending to settle on a few API providers can lead to reliance on a single validator, further weakening the system's security.The author suggests starting discussions with a summary of the security assumptions and design requirements. The importance of economically dependent full nodes is emphasized, along with the tradeoff between weak miner decentralization and good validator decentralization. The weakening of validators due to non-validating wallet software, centralized wallets, and centralized Bitcoin APIs is highlighted. Best practices are suggested to maintain network health and security, including simplicity and an incremental approach. Working incrementally is seen as a way to address issues and reach consensus. 2015-11-09T16:27:22+00:00 + In an email exchange between Bryan Bishop and Gavin Andresen, they discuss the concept of "key-holder decentralization," which refers to both the number of key-holders and the number of transactions they make. They mention that a small maximum block size would limit the system to institutions with large-value transactions. The Lightning Network is not a solution to this problem as it still relies on the main chain and can be affected by insufficient fees. Andresen provides a link to a video for further information.Gavin Andresen expresses disappointment over the lack of discussion about the key-holder versus validator decentralization balance tradeoff. Bryan seeks clarification on the definition of "key-holder decentralization" and its implications. They also discuss the use of Lightning Network payment channels and BTC-pegged merge-mined chains to handle transaction demand. Further clarification is requested regarding concerns about a scenario with only 10 key holders.Adam Back and Gavin Andresen discuss the security assumptions and design requirements of Bitcoin. They highlight the importance of economically dependent full nodes in assuring Bitcoin's security. They emphasize that small miners should not be significantly disadvantaged compared to larger miners, and there should be no collusion advantages leading to policy centralization. The balance between validators and miners decentralization is also discussed. They suggest best practices such as simplicity and an incremental approach to deployment.A discussion on the Bitcoin-dev mailing list involves Chris Priest, Adam Back, and Eric Voskuil. They debate the impact of widespread use of APIs on network security. Priest argues that the system's security is independent of the ratio between full nodes and lightweight nodes, while Back notes the need for users to understand the security implications of using APIs and trust the third-party providers. Voskuil believes that centralized Bitcoin APIs contribute to reducing network security over time.Another discussion on the mailing list involves Eric Voskuil and Adam Back. They address the importance of economically dependent full nodes (validators) in ensuring Bitcoin's security. They mention the weakening of validators due to non-validating wallet software, centralized wallets, and centralized Bitcoin APIs. They also discuss the availability of multiple blockexplorer APIs, which Voskuil sees as beneficial for decentralization.The security assumption behind Bitcoin's need for decentralization is discussed by Jeremy Rubin. He highlights the property that "$10 in the hand of 10 people is more than $50 in the hand of two, or $100 in the hand of one" and its importance in transacting large amounts with Bitcoin. Validators play a crucial role in enforcing consensus rules and assuring security. The trade-off between weak miner decentralization and good validator decentralization is mentioned. Eric Voskuil emphasizes the underappreciated importance of validator decentralization and the potential risks of relying on centralized Bitcoin APIs.Adam Back shares his thoughts on economically dependent full nodes in Bitcoin's security model. He emphasizes their role in enforcing consensus rules and preventing maliciously crafted blocks from eroding security. He discusses the tradeoff between weak miner decentralization and good validator decentralization, stating that both being weak is risky. He points out that the proliferation of non-validating wallet software, centralized web wallets, and centralized Bitcoin APIs has weakened the security model, which he believes is not fully understood. Developers tending to settle on a few API providers can lead to reliance on a single validator, further weakening the system's security.The author suggests starting discussions with a summary of the security assumptions and design requirements. The importance of economically dependent full nodes is emphasized, along with the tradeoff between weak miner decentralization and good validator decentralization. The weakening of validators due to non-validating wallet software, centralized wallets, and centralized Bitcoin APIs is highlighted. Best practices are suggested to maintain network health and security, including simplicity and an incremental approach. Working incrementally is seen as a way to address issues and reach consensus. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml b/static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml index 96ed94e7c8..ec50925cc0 100644 --- a/static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml +++ b/static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml @@ -2,7 +2,7 @@ 2 Combined summary - [BIP Proposal] Buried Deployments - 2025-09-26T15:53:38.413012+00:00 + 2025-10-11T21:59:38.895742+00:00 python-feedgen Eric Voskuil 2016-11-17 10:10:30+00:00 @@ -101,10 +101,11 @@ + 2 Combined summary - [BIP Proposal] Buried Deployments - 2025-09-26T15:53:38.413204+00:00 + 2025-10-11T21:59:38.895944+00:00 2016-11-17T10:10:30+00:00 In a recent email exchange, bitcoin developers Pieter Wuille and Eric Voskuil discussed the use of checkpoints in the blockchain. Checkpoints have been used as a way to prevent attacks, but Wuille argues that they are not necessary and can be removed. He suggests that users validate the full chain without checkpoints and select their own checkpoints instead.Voskuil expresses concern that this could lead to centralization of control over the "true chain", but Wuille counters that developers already have this power and good review and release practices can mitigate the risk.The conversation also touches on buried softforks, which modify the validity of a theoretically construable chain from invalid to valid. Wuille believes that avoiding certain checks for BIP34 and BIP66 could improve performance optimization, but Voskuil disagrees and sees no benefit in this approach.Another topic of discussion is the comparison between BIP30 and BIP34. Voskuil clarifies that duplicate transaction hashes can still occur in Bitcoin even with the activation of BIP34, and that BIP30 is not validated after BIP34 is active because blocks complying with BIP34 will always comply with BIP30.The email exchange also involves a discussion about a recent change in Bitcoin Core regarding the deployment of BIPs 34, 66, and 65. The change replaces the trigger mechanism with cached block heights, simplifying and optimizing the process. Voskuil initially opposes the change, but others argue that it doesn't represent a performance improvement and merely cements attributes of the blockchain's history. There is also mention of BIP30 and BIP50, which were given similar treatment after a reasonable amount of time had passed.In addition, there are discussions about reducing code complexity, defining maximum depth of reorganization, and the definition of "BIP" itself. The conversation provides different perspectives on these topics, with some arguing for the elimination of checkpoints and others highlighting potential issues and complexities.Bitcoin Core has recently merged a simplification to the consensus rules surrounding the deployment of BIPs 34, 66, and 65. This change replaces the trigger mechanism for prior soft forks by caching the block heights at which those consensus rules became enforced. The purpose of this change is to simplify and optimize the trigger mechanism. However, this proposal has been met with criticism from Eric Voskuil, who calls it a "horrible precedent" and argues that it is not a significant performance optimization. Despite the debate, the change has already been merged into Bitcoin Core.The change is considered a minor one, but the rationale behind it has been documented in a BIP for posterity. Prior soft forks were activated via miner signaling in block version numbers. Now, with the chain having passed the blocks where those consensus rules were triggered, caching the block heights at which those rules were enforced is seen as a more efficient solution. This change solidifies certain attributes of the blockchain's history that are not disputed. It is widely agreed upon that BIP34 was activated at block 227931, BIP65 at block 388381, and BIP66 at block 363725. While this change does not provide justification for the consensus rule change, it ensures that any reorganization that disconnects the activating block will raise concerns about the security assumptions of Bitcoin.Despite potential concerns about a consensus split, the change is not expected to cause fundamental security concerns in Bitcoin. The proposal suggests that including at least one checkpoint to directly verify that no 50k reorganizations will occur would make the change a soft fork instead of a hard fork. Chains that do not go through the checkpoint would be rejected, but no new chains would be allowed. The purpose of the checkpoint is to validate the assumption that no such large reorganizations will happen. However, many people still want to verify the legacy chain. This checkpointing process would only be necessary during the headers-first part of the download.The simplified consensus rules have not yet appeared in any released software but are expected to be included in the next release, 0.14.0. Despite concerns raised about the performance optimization and the process followed for this change, the developer responsible has agreed to modify the BIP draft to de-emphasize the performance aspect. The full draft of the BIP can be found on GitHub.In summary, Bitcoin Core has merged a simplification to the consensus rules surrounding the deployment of certain BIPs. This change replaces the trigger mechanism for prior soft forks by caching the block heights at which those rules were enforced. While there has been criticism regarding this change, it has already been merged into Bitcoin Core. The purpose of this change is to simplify and optimize the trigger mechanism, although concerns have been raised about its performance optimization and the process followed. The full draft of the BIP can be found on GitHub, and the change is expected to be included in the next software release. diff --git a/static/bitcoin-dev/Nov_2016/combined_BIP-idea-Standardised-p2sh-bitcoin-addresses-requiring-an-arbitrary-and-or-combination-of-keys.xml b/static/bitcoin-dev/Nov_2016/combined_BIP-idea-Standardised-p2sh-bitcoin-addresses-requiring-an-arbitrary-and-or-combination-of-keys.xml index b5505d1906..249a493169 100644 --- a/static/bitcoin-dev/Nov_2016/combined_BIP-idea-Standardised-p2sh-bitcoin-addresses-requiring-an-arbitrary-and-or-combination-of-keys.xml +++ b/static/bitcoin-dev/Nov_2016/combined_BIP-idea-Standardised-p2sh-bitcoin-addresses-requiring-an-arbitrary-and-or-combination-of-keys.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP idea: Standardised p2sh bitcoin addresses requiring an arbitrary and/or combination of keys - 2025-09-26T15:53:36.303097+00:00 + 2025-10-11T21:59:36.771504+00:00 python-feedgen Edmund Edgar 2016-11-30 00:00:43+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - BIP idea: Standardised p2sh bitcoin addresses requiring an arbitrary and/or combination of keys - 2025-09-26T15:53:36.303285+00:00 + 2025-10-11T21:59:36.771640+00:00 2016-11-30T00:00:43+00:00 Erland Lewin has proposed a method to create "Boolean addresses" that can be redeemed by a set of keys and multi-signatures combined with logical and/or operations. The aim of this proposal is to standardize these addresses, allowing for interoperability among wallet software. By implementing a consistent way to generate a P2SH script from a given boolean address tree, wallet authors can create, sign, and share signature requests for these addresses.A Boolean address is described as a tree structure, starting at a root node. The nodes within the tree can be an "and" operation, an "or" operation, a public key, a multisig operation n-of-m with a list of public keys, or a CHECKLOCKTIMEVERIFY operation. This proposal provides flexibility for various scenarios. For example, corporations can utilize this proposal to allow signatures by "A or (2 of 4 of B, C, D, E)," enabling spending by either the CEO or board members with their respective keys.Additionally, individuals like Alice can redeem her address in case of key loss or compromise. She can set up her address as "A or (B and 1-of-3 of C, D, E)." This means that if Alice loses her key or if her cloud wallet key is compromised, she can still access her funds using a combination of keys C, D, or E.The implementation of this proposal will establish a well-defined process for generating a P2SH script based on a given boolean address tree. It will also outline how spending transactions are to be signed. Reality Keys, a platform that verifies information against real-world events, recognizes the value of this proposal in addressing pain points and suggests that its adoption by wallet authors would be beneficial. Edmund Edgar, founder of Social Minds Inc (KK), supports the proposal's sensible implementation.In conclusion, Erland Lewin's proposal offers a consistent method for creating Boolean addresses that can be redeemed by a combination of keys and multi-signatures using logical and/or operations. Its implementation will ensure standardized interoperability among wallet software while providing clear guidelines for generating P2SH scripts and signing spending transactions. diff --git a/static/bitcoin-dev/Nov_2016/combined_BIP30-and-BIP34-interaction-was-Re-BIP-Proposal-Buried-Deployments-.xml b/static/bitcoin-dev/Nov_2016/combined_BIP30-and-BIP34-interaction-was-Re-BIP-Proposal-Buried-Deployments-.xml index f611832709..a8f3674231 100644 --- a/static/bitcoin-dev/Nov_2016/combined_BIP30-and-BIP34-interaction-was-Re-BIP-Proposal-Buried-Deployments-.xml +++ b/static/bitcoin-dev/Nov_2016/combined_BIP30-and-BIP34-interaction-was-Re-BIP-Proposal-Buried-Deployments-.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments) - 2025-09-26T15:53:42.644360+00:00 + 2025-10-11T21:59:43.143995+00:00 python-feedgen Eric Voskuil 2016-11-18 16:47:09+00:00 @@ -81,10 +81,11 @@ + 2 Combined summary - BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments) - 2025-09-26T15:53:42.644558+00:00 + 2025-10-11T21:59:43.144155+00:00 2016-11-18T16:47:09+00:00 In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the possibility of transaction hash collisions and their potential impact on the Bitcoin network. While it is unlikely that such collisions will occur due to the strength of SHA256, there is still a small chance that they could happen. BIP30 allows for fully-spent transactions to be duplicated for pruning purposes, but this means that there could be duplicated transaction IDs (txids) in the future. BIP34 aims to enforce block and transaction uniqueness, but does not explicitly reject collisions by consensus. To address this issue, a suggestion is made to draft a new BIP, but it is noted that doing so would make it impossible to guard against chain splits caused by pruning.Peter Todd responds to these concerns, stating that the likelihood of a transaction hash collision is highly unlikely, as SHA256 is currently a secure algorithm with infeasible brute-force attacks against 256-bit keys. He emphasizes that if SHA256 were to become weak, Bitcoin would be fundamentally broken, as miners would be able to generate blocks with collisions in transactions and merkle trees, leading to multiple contradictory transaction histories. Todd cites Bruce Schneier's statement that brute-force attacks against 256-bit keys will remain infeasible until computers are built from something other than matter and occupy something other than space.Eric Voskuil explains in another discussion that banning duplicate transaction hashes outright is not feasible, as it would require spent transaction hashes to be retained forever, contradicting the concept of pruning nodes. Additionally, implementing such a ban would result in a chain split and a hard fork. While BIP34 prevents exact duplicate transactions, different transactions can still have the same hash if their parents are identical. However, as long as the hash function remains secure, future transactions are guaranteed to have unique txids.Tier Nolan adds that as long as there is no hash function break, the rules guarantee that all future transactions will have different txids. However, Eric Voskuil points out that if there is an address collision, someone may lose money, while a tx hash collision handled differently by implementations could lead to a chain split. It is emphasized that nodes cannot dismiss this possibility and must remain vigilant. Nolan explains that the only way for two transactions to have the same txid is if their parents are identical, as txids of parents are included in a transaction. While coinbases used to allow for the possibility of identical transactions, exceptions were made because duplicate outputs were not possible in the database. All new coinbases will have unique hashes, ensuring that all future transactions will have different txids.In regards to BIP30, it is clarified that it prevents duplicate transaction hashes only when a new transaction hash duplicates that of a preceding transaction with unspent outputs. On the other hand, BIP34 does not prevent duplicate transaction hashes from different transactions. Two cases of duplicate transaction hashes have already occurred, one of which was exempted from validation because it had become buried in the chain, while the other complied with the BIP30 rule due to its predecessor being spent. BIP34 now precludes exact duplicate transactions. The collision of regular transactions is highly unlikely due to inputs and usage of entropy, but coinbase transactions, which do not have inputs, present a worrying case. BIP30 introduces committed height to prevent collisions on coinbase transactions.Overall, while the likelihood of transaction hash collisions is low, precautions must be taken to ensure the integrity of the Bitcoin network. The discussions highlight the importance of maintaining a secure hash function and implementing measures such as BIP30 and BIP34 to prevent collisions and chain splits. diff --git a/static/bitcoin-dev/Nov_2016/combined_Flexible-Transactions-.xml b/static/bitcoin-dev/Nov_2016/combined_Flexible-Transactions-.xml index 28e2c202a1..0832c1501c 100644 --- a/static/bitcoin-dev/Nov_2016/combined_Flexible-Transactions-.xml +++ b/static/bitcoin-dev/Nov_2016/combined_Flexible-Transactions-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Flexible Transactions. - 2025-09-26T15:53:46.873936+00:00 + 2025-10-11T21:59:47.396460+00:00 python-feedgen Russell O'Connor 2016-11-21 21:29:21+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Flexible Transactions. - 2025-09-26T15:53:46.874084+00:00 + 2025-10-11T21:59:47.396641+00:00 2016-11-21T21:29:21+00:00 In response to an email from Russell, Tom Zander from the bitcoin-dev mailing list expressed gratitude for his review but mentioned that the issue raised had already been resolved some time ago. It was revealed that Tom had waited for six weeks before sending the email. Russell expressed satisfaction with the solution and looked forward to seeing BIP 134 updated accordingly. On 21 November 2016, Russell O'Connor expressed concern about Tom's proposal to change the semantics of OP_CHECKSIG in version 2 of 'script', deeming it too naive. Tom had previously explained that in version 2, the data signed would be equivalent to the transaction-id, simplifying the process. However, Tom responded to Russell's email stating that the issue had already been fixed and thanked him for the review after the six-week wait. Tom also provided links to his blog and vlog.The proposal to change the semantics of OP_CHECKSIG in version 2 of script suggested altering the signed data to align with the transaction-id, streamlining the process. However, critics argue that this proposal is overly simplistic. They explain that the SIGHASH data utilized in both Bitcoin script and Segwit script contains information indicating which input is being signed. By signing only the transaction id, the proposed signature fails to include the data specifying which input of the transaction is being signed. Consequently, if different inputs share the same public key due to key reuse, the signatures on those inputs will be identical. Additionally, the Flexible Transactions proposal introduces a new vulnerability to Bitcoin that currently does not exist.An example is given to illustrate this flaw, where two individuals jointly prepare a transaction with one input from each person. If one individual deceives the other by using the outpoint from the other person's transaction, which has the same public key as their chosen input, they can duplicate the signature provided by the other person and fund both inputs for the "jointly" funded purchase. This flaw is considered to be on par with transaction malleability, which is already being addressed. Therefore, caution and vigilance are necessary to avoid this trap, requiring unexpected work. It is advised not to expose Bitcoin to this line of attack. Consequently, it is crucial to thoroughly comprehend the reasons behind existing processes before proposing changes. diff --git a/static/bitcoin-dev/Nov_2016/combined_Implementing-Covenants-with-OP-CHECKSIGFROMSTACKVERIFY.xml b/static/bitcoin-dev/Nov_2016/combined_Implementing-Covenants-with-OP-CHECKSIGFROMSTACKVERIFY.xml index 7e1a1047b7..e2af03f365 100644 --- a/static/bitcoin-dev/Nov_2016/combined_Implementing-Covenants-with-OP-CHECKSIGFROMSTACKVERIFY.xml +++ b/static/bitcoin-dev/Nov_2016/combined_Implementing-Covenants-with-OP-CHECKSIGFROMSTACKVERIFY.xml @@ -2,7 +2,7 @@ 2 Combined summary - Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY - 2025-09-26T15:53:44.757276+00:00 + 2025-10-11T21:59:45.267083+00:00 python-feedgen Jeremy 2016-11-07 19:30:26+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY - 2025-09-26T15:53:44.757415+00:00 + 2025-10-11T21:59:45.267225+00:00 2016-11-07T19:30:26+00:00 Russell O'Connor has provided a detailed explanation on how to implement covenants using the OP_CAT and OP_CHECKSIGFROMSTACKVERIFY op codes in the Elements Alpha sidechain. These op codes allow for the construction of covenants in Elements Alpha currently. O'Connor has also demonstrated the construction of the Moeser-Eyal-Sirer vault as an example. The implementation involves creating an output that can be spent by anyone if it is double-spent with two different transactions. This is achieved by adding a case to the script that allows spending when two valid signatures on different messages under the public key of the output are given.The "opt-in miner takes double-spend" functionality can be implemented using either OP_CAT or OP_CHECKSIGFROMSTACKVERIFY. By creating an output that is spendable by everyone if it is double-spent, the next miner who mines the double-spent transaction will receive all the money. The recipient can accept zero-conf transactions, knowing that the sender will lose the money upon attempting to double-spend. In the case of OP_CHECKSIGFROMSTACKVERIFY, spending is allowed if two valid signatures on different messages under the public key of the output are provided. OP_CAT offers a simpler way to achieve the same functionality by converting Bitcoin's ECDSA into an opt-in one-time signature scheme.During the discussion on the bitcoin-dev mailing list, Daniel Robinson and Russell O'Connor explored the possibility of implementing "poison transactions" using OP_CHECKSIGFROMSTACKVERIFY. O'Connor mentioned that while he had not extensively studied poison transactions, adding transaction introspection operations could save a significant amount of work as the transaction data is easily recoverable. Although there are no immediate plans to include transaction introspection opcodes in Elements, it remains a possibility in the future.Johnson Lau also joined the conversation, sharing his alternative implementation of OP_CHECKSIGFROMSTACKVERIFY. Instead of hashing the data on stack, he directly puts the 32 byte hash onto the stack. Lau believes that this approach offers more flexibility as not all systems use double-SHA256.The discussion prompted Russell O'Connor to encourage the collection and implementation of other useful covenants. A business case example was presented, demonstrating the usage of multisig with an oracle determination to protect against renegotiation or unforeseen circumstances. The terms of the transaction included a CLTV lasting several years, and both parties could mutually select and sign one of the payout distributions for early exit. The desired features were the ability for one party to sell their participation before the CLTV becomes valid and the mutual revocation of rogue oracle-entities without affecting other terms.Overall, the implementation of covenants using OP_CAT and OP_CHECKSIGFROMSTACKVERIFY in the Elements Alpha sidechain has been detailed by Russell O'Connor. The construction process is already available and can be used to create various types of covenants. Johnson Lau has also provided an alternative implementation of OP_CHECKSIGFROMSTACKVERIFY. O'Connor welcomes suggestions for implementing other useful covenants and encourages the community to share their ideas. diff --git a/static/bitcoin-dev/Nov_2016/combined_The-Excessive-Block-Gate-How-a-Bitcoin-Unlimited-Node-Deals-With-Large-Blocks.xml b/static/bitcoin-dev/Nov_2016/combined_The-Excessive-Block-Gate-How-a-Bitcoin-Unlimited-Node-Deals-With-Large-Blocks.xml index 27ea209e53..903d08dad1 100644 --- a/static/bitcoin-dev/Nov_2016/combined_The-Excessive-Block-Gate-How-a-Bitcoin-Unlimited-Node-Deals-With-Large-Blocks.xml +++ b/static/bitcoin-dev/Nov_2016/combined_The-Excessive-Block-Gate-How-a-Bitcoin-Unlimited-Node-Deals-With-Large-Blocks.xml @@ -2,7 +2,7 @@ 2 Combined summary - The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks - 2025-09-26T15:53:40.530838+00:00 + 2025-10-11T21:59:41.021406+00:00 python-feedgen Tom Zander 2016-11-27 07:47:00+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks - 2025-09-26T15:53:40.531011+00:00 + 2025-10-11T21:59:41.021591+00:00 2016-11-27T07:47:00+00:00 On November 26, 2016, Peter R via bitcoin-dev suggested that miners should set the same block size limit and signal it reliably, similar to what Bitcoin Unlimited (BU) miners do. This concept was recently implemented in Classic, which will now respect the EB limit and put it in the coinbase. Tom Zander mentioned that there may be a significant difference in cost versus expected earnings of creating a block. Sergio and Tom discussed how miners setting their block size limits above or below the "effective BSL" can disadvantage them. The conversation also highlighted that it is in the best interest of miners to all set the same block size limit and signal it reliably in their coinbase TX.Sergio Demian Lerner wrote an email expressing concern about the false premise of his reasoning and conclusions about BU block size policies for miners. He believes that all miners need to follow the same block size policy to prevent short forks. The conversation between Sergio and Tom emphasized the importance of miners announcing and following the same block size policy to prevent short forks. They also discussed the possibility of improvements to be made to the policy that BU uses.Bitcoin developers are discussing the possibility of unlimited block size in the Bitcoin Core implementation of the consensus protocol. Sergio expressed concern about the riskiness of this change without detailed analysis. Tom responded that he did not see it as a change, but rather miners would simply choose a rule that maximizes their revenue. The concept of proof-of-work was discussed, highlighting that the longer a chain, the higher the probability that it will be extended. The issue of having a 3 or 4 deep fork was acknowledged as a problem in Bitcoin, but it hasn't happened for ages and miners prefer it that way.The email conversation between Sergio and Peter focused on the acceptance of payment in BU when the gate policy of 51% miners is not known. Sergio suggested that miners should advertise their gate block size and acceptance depth in their coinbase field to provide clarity. Peter responded by providing a link to an article that explains how Bitcoin Unlimited's excessive-block logic works from the perspective of a single node. He also mentioned that BU's market-based solution to the block-size limit is gaining support and hopes to write a follow-up article describing how this behavior facilitates the emergence of a fluid and organic block size limit at the network scale.In summary, the discussions revolve around miners setting the same block size limit, preventing short forks, the concept of proof-of-work, the possibility of unlimited block size, and the workings of Bitcoin Unlimited. The conversation also explores the idea of miners advertising their gate block size and acceptance depth, and the potential improvements to be made to BU's policy. diff --git a/static/bitcoin-dev/Nov_2017/combined_Simplicity-proposal-Jets-.xml b/static/bitcoin-dev/Nov_2017/combined_Simplicity-proposal-Jets-.xml index b1fc40e6c6..a642b75365 100644 --- a/static/bitcoin-dev/Nov_2017/combined_Simplicity-proposal-Jets-.xml +++ b/static/bitcoin-dev/Nov_2017/combined_Simplicity-proposal-Jets-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Simplicity proposal - Jets? - 2025-09-26T15:50:14.704175+00:00 + 2025-10-11T21:58:11.703041+00:00 python-feedgen Adán Sánchez de Pedro Crespo 2017-11-03 16:42:38+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - Simplicity proposal - Jets? - 2025-09-26T15:50:14.704352+00:00 + 2025-10-11T21:58:11.703206+00:00 2017-11-03T16:42:38+00:00 The Simplicity proposal introduces the concept of "jets", which are precompiled functions that can be called directly from Simplicity code. These jets allow for faster execution of Simplicity code compared to other blockchain languages, while also increasing security by reducing vulnerabilities to bugs and attacks. Each Simplicity expression is identified by its MAST root, which is the Merkle root of all branches in its Abstract Syntax Tree. When the Simplicity interpreter encounters an expression with a jet, it looks for it in a predefined jets dictionary and finds the binary for a precompiled, formally proven implementation of the function. This means that popular Simplicity expressions can be recognized and directly evaluated using specialized C or assembly code, rather than being interpreted.In response to concerns about the need for Simplicity code to be publicly available in the blockchain when using jets, it was explained that discounted jets will be explicitly labeled as jets in the commitment. If a user can provide a Merkle path to an explicit jet node that isn't among the known discounted jets, it will not be executed. This mitigates the need for large algorithms like EDCA verification/SHA256 hashing to take up space in the blockchain. Additionally, in a softfork for a jet, the Simplicity code for the jet could be defined as "consensus", eliminating the need for it to be provided within every script output. The use of formal verification ensures that the jets match the corresponding Simplicity code.The bitcoin-dev mailing list featured discussions on the Simplicity proposal and the use of jets. Users raised questions about the need for Simplicity code to be publicly available and the possibility of mitigating this. Russell O'Connor, in response, referred to section 3.4 of the Simplicity proposal document and explained how jets work. He mentioned that jets are briefly discussed in the proposal and are a way to recognize popular Simplicity expressions and directly evaluate their functions using specialized C or assembly code. Russell also clarified that discounted jets will be explicitly labeled as jets in the commitment, and a Merkle path to an explicit jet node can be provided if it isn't among the known discounted jets.The Simplicity programming language uses jets as a smart optimization technique to make complex Simplicity contracts more computationally efficient. Jets leverage the frames stack in the Simplicity Bit Machine, allowing for known results of expressions to be written to the active write frame instead of executing the expression step-by-step again. This optimization reduces CPU usage and ensures that jets cannot introduce side effects. Different sets of jets can create single-purpose dialects, similar to domain-specific languages, enhancing the vocabulary and semantics of Simplicity code.While there is a lack of specific information and links regarding jets in the Simplicity proposal, it is mentioned that discounted jets will be identified as such in the commitment. If a Merkle path can be provided to an explicit jet node that is not among the known discounted jets, it will also be considered a jet. However, further details on this feature are currently unavailable. diff --git a/static/bitcoin-dev/Nov_2018/combined_BIP-SLIP-0039-better-multi-language-support.xml b/static/bitcoin-dev/Nov_2018/combined_BIP-SLIP-0039-better-multi-language-support.xml index 1384df6ef2..fd94895ce9 100644 --- a/static/bitcoin-dev/Nov_2018/combined_BIP-SLIP-0039-better-multi-language-support.xml +++ b/static/bitcoin-dev/Nov_2018/combined_BIP-SLIP-0039-better-multi-language-support.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP- & SLIP-0039 -- better multi-language support - 2025-09-26T15:31:38.532805+00:00 + 2025-10-11T21:40:07.543696+00:00 python-feedgen Weiji Guo 2018-11-22 17:25:07+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - BIP- & SLIP-0039 -- better multi-language support - 2025-09-26T15:31:38.532979+00:00 + 2025-10-11T21:40:07.543852+00:00 2018-11-22T17:25:07+00:00 In a bitcoin-dev discussion, Steven Hatzakis proposed revising the process for generating BIP39 seed by feeding the initial entropy into the PBKDF2 function instead of using words. Weiji suggested incorporating Shamir's Secret Sharing (SSS) into the design to maintain language independence and enable mnemonics in multiple languages simultaneously. The proposed revision includes a language id for each defined wordlist in the SSS share, as well as other parameters such as share id, threshold, index, share value, and checksum. Weiji also suggested using two languages or one language + numbers to cross-check for errors in handprinting. Another discussion on the use of mnemonics in different languages highlighted the issue that while words cannot be directly translated, the underlying entropy is the same when comparing mnemonics generated across different languages from the same initial entropy. Two options were suggested to solve this problem: either have the wallet recognize the language and re-map the entropy accordingly or revise how the BIP39 seed is generated by hashing the entropy instead of the words. It was also suggested to include the identifier of the chosen wordlist as part of the mnemonic and maintain an official list of named dictionaries for user selection.The BIP39 seed generation process currently depends on the language chosen for the mnemonic sentence, limiting users to specific languages. The proposed solution is to represent the mnemonic code as the underlying entropy or pre-master secret, allowing for the same seed/secret to be displayed in any language. Decimal numbers could also be used to represent the seed/secret for users who struggle with words in other languages. However, it should be noted that two mnemonics generated with the same entropy will produce different BIP39 seeds depending on the language chosen.In a conversation between Neill Miller and Jonathan Underwood, it was mentioned that Electrum treats BIP39 recovery in the same way as non-BIP39 mnemonics. Jonathan mentioned that Electrum follows the BIP39 specifications for recovery, but Neill pointed out that Electrum mnemonics are not based on BIP39.Jonathan Underwood further discussed how Electrum handles BIP39 recovery according to the specifications, while mentioning that not all apps follow the BIP39 spec. He expressed the difficulty of expecting every app to support multiple languages due to the lack of adherence to the spec. However, he noted that Electrum allows for restoring random strings with a warning. Neill Miller confirmed that Electrum mnemonics are not based on BIP39.Jonathan Underwood emphasized that while multiple languages in BIP39 make sense, it is unreasonable to expect every app to load every language due to the lack of adherence to the spec. He clarified that Electrum follows the BIP39 recovery process but warned about restoring random strings. Neill confirmed this information.BIP39 provides flexibility in wordlists for generating mnemonic sentences, but it is advised to use mnemonics generated by the algorithm described in the specification. Software must compute a checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid. The BIP39 multi-language feature is important for non-English speakers, but many wallets only support the English wordlist. Electrum seeds are language/wordlist agnostic and allow for restoration of random strings. The need to address the language issue in BIP39 has led to proposals such as representing the mnemonic code as underlying entropy or using decimal numbers instead of words.Weiji Guo highlighted that BIP-0039 is language dependent, limiting users who prefer non-English languages. While SLIP-0039 offers SSS capability with an English wordlist, it does not provide a user-friendly solution. Weiji proposed two solutions: representing the mnemonic code as underlying entropy or allowing the seed/secret to be represented in decimal numbers for users who struggle with words in other languages. Implementation details for these proposals are uncertain, and community input is sought.In summary, there have been discussions and proposals to address the language dependence of BIP39 mnemonics. Suggestions include revising the seed generation process, incorporating Shamir's Secret Sharing, and representing the mnemonic code as underlying entropy or using decimal numbers. Electrum follows the BIP39 recovery process but also supports non-BIP39 mnemonics. The lack of adherence to the BIP39 spec by other apps has made it challenging to support multiple languages. Further exploration and input from the community are needed to find a suitable solution. diff --git a/static/bitcoin-dev/Nov_2018/combined_Considering-starting-a-toy-full-node-implementation-Any-advice-.xml b/static/bitcoin-dev/Nov_2018/combined_Considering-starting-a-toy-full-node-implementation-Any-advice-.xml index b05997fa9f..1111146a30 100644 --- a/static/bitcoin-dev/Nov_2018/combined_Considering-starting-a-toy-full-node-implementation-Any-advice-.xml +++ b/static/bitcoin-dev/Nov_2018/combined_Considering-starting-a-toy-full-node-implementation-Any-advice-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Considering starting a toy full-node implementation. Any advice? - 2025-09-26T15:31:28.067889+00:00 + 2025-10-11T21:40:05.405151+00:00 python-feedgen John C. Vernaleo 2018-11-07 16:19:26+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Considering starting a toy full-node implementation. Any advice? - 2025-09-26T15:31:28.068018+00:00 + 2025-10-11T21:40:05.405320+00:00 2018-11-07T16:19:26+00:00 In a message to the bitcoin-dev mailing list, an individual expressed their intention to develop a toy full-node implementation for educational purposes. They sought advice on which resources to use as a reference for the protocol, where to start, and any general tips or advice for such a project. Artem, in response, advised the individual to start small and take small steps, such as connecting to nodes and downloading blocks. They also suggested that the individual should not dismiss the idea of creating a wallet or mining capabilities, as these can provide a good understanding of keys and transactions. Additionally, Artem warned that the individual should be prepared to work with large and diverse sets of data. They also mentioned that new exploitable signatures are unlikely to be found, as there are constantly bots scanning the blockchain for weak keys and signatures.Artem provided several references for the individual, including bitcoin.org/en/developer-reference, en.bitcoin.it/wiki/Protocol_documentation, and github.com/bitcoin/bips. They wished the individual luck and fun in their project. The individual mentioned considering using btcd as a reference since they are unfamiliar with C++. They clarified that they do not intend to include a wallet or mining capabilities in their implementation. It is worth mentioning that one reply in the discussion warned against using an SSD or SD card due to the potential damage caused by repeated downloading of the blockchain, based on previous experiences. Finally, another reply cautioned about the presence of artwork and puzzles in the early blockchain, highlighting its historical significance. diff --git a/static/bitcoin-dev/Nov_2021/combined_A-fee-bumping-model.xml b/static/bitcoin-dev/Nov_2021/combined_A-fee-bumping-model.xml index 49fc7c0aff..51344271da 100644 --- a/static/bitcoin-dev/Nov_2021/combined_A-fee-bumping-model.xml +++ b/static/bitcoin-dev/Nov_2021/combined_A-fee-bumping-model.xml @@ -2,7 +2,7 @@ 2 Combined summary - A fee-bumping model - 2025-09-26T15:34:22.784714+00:00 + 2025-10-11T21:43:46.450945+00:00 python-feedgen Peter Todd 2021-12-09 13:50:33+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - A fee-bumping model - 2025-09-26T15:34:22.784878+00:00 + 2025-10-11T21:43:46.451120+00:00 2021-12-09T13:50:33+00:00 emails discussing the topic. It also mentions the idea of creating an insurance project for the LGBTQ community in India and shares a presentation by Jack Mallers on creating derivatives to hedge fees.In summary, the discussions and articles revolve around the importance of fee-bumping strategies for the security and efficiency of protocols built on Bitcoin. The challenges of fee estimation, confirmation of transactions, and overpayments are addressed, along with proposed solutions such as presigned transactions, reserve feerates, and consolidation with fanout. The need for accurate fee estimation, policy-level mitigations, new consensus rules, and potential insurance markets are emphasized throughout the conversations and articles. diff --git a/static/bitcoin-dev/Nov_2021/combined_Trying-to-patch-Core-ZMQ-rawtx-topic-to-only-publish-unconfirmed-transactions-How-.xml b/static/bitcoin-dev/Nov_2021/combined_Trying-to-patch-Core-ZMQ-rawtx-topic-to-only-publish-unconfirmed-transactions-How-.xml index ff2fbcc4da..12b90bb992 100644 --- a/static/bitcoin-dev/Nov_2021/combined_Trying-to-patch-Core-ZMQ-rawtx-topic-to-only-publish-unconfirmed-transactions-How-.xml +++ b/static/bitcoin-dev/Nov_2021/combined_Trying-to-patch-Core-ZMQ-rawtx-topic-to-only-publish-unconfirmed-transactions-How-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How? - 2025-09-26T15:34:26.988620+00:00 + 2025-10-11T21:43:48.583702+00:00 python-feedgen Ali Sherief 2021-11-29 14:13:37+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How? - 2025-09-26T15:34:26.988796+00:00 + 2025-10-11T21:43:48.583866+00:00 2021-11-29T14:13:37+00:00 In an email thread on the bitcoin-dev mailing list, a discussion is being held regarding an issue with the ZeroMQ topic "rawtx." This topic emits a raw transaction when it appears on the mempool, but it also emits the same transaction once it has been confirmed. This causes problems with software that de-duplicates arrays, as the same transaction is received twice. The proposed solution is to configure Core to only publish unconfirmed transactions. However, this cannot be done through configuration or command-line options and requires editing the source code directly.A draft pull request has been opened by 0xB10C to add a rawmempooltx publisher. This PR includes a new function called NotifyMempoolTransaction() in zmq/zmqnotificationinterface.cpp, which notifies the CZMQNotificationInterface about TransactionAddedToMempool. The function calls the publisher with the rawmempooltx topic. The author of the PR mentions that a mempool transaction publisher with both the raw transaction and transaction fee would also be useful, but changes to the chain notifications in interfaces/chain.h would be necessary for this.Meanwhile, on the Bitcointalk forum, a user named Ali Sherief reports experiencing the issue with the "rawtx" topic emitting confirmed transactions. Ali attempts to instruct Core to only publish unconfirmed transactions but discovers that it requires editing the source code directly. They are uncertain which function in src/zmq/zmqnotificationinterface.cpp needs to be patched for their own build. They mention two possibilities: CZMQNotificationInterface::TransactionRemovedFromMempool or void CZMQNotificationInterface::BlockDisconnected, both of which call the NotifyTransaction() method that fires a message on the "rawtx" channel.The author refers to Jonas Schnelli's suggestion from several years ago to add an `if (!pblock)` check. However, they note that the function he was referencing no longer exists and are unsure if the pblock check is still applicable in the present day to determine the block a transaction is inside.To resolve the issue, Prayank suggests a solution to Ali. The solution involves saving zmqpubsequence=tcp://127.0.0.1:28332 in the bitcoin.conf file, running bitcoind, and executing a Python script provided at https://pastebin.com/raw/tNp2x5y3. Prayank shares screenshots of the script execution, showing the status of accepted, connected (block), and removal transactions. Prayank recommends modifying the script to handle transaction duplication since transactions could be printed twice. Alternatively, they suggest using debug=mempool and reading debug.log for changes without polling.Overall, the discussion revolves around the issue with the ZeroMQ topic "rawtx" emitting confirmed transactions and the need to patch the source code to only publish unconfirmed transactions. Suggestions have been made through a pull request and on the Bitcointalk forum, but the exact function to be patched and the applicability of Jonas Schnelli's suggestion are still under consideration. Additionally, Prayank offers a solution involving configuration changes and a Python script to manage transaction duplication. diff --git a/static/bitcoin-dev/Nov_2021/combined_bitcoinj-fork-with-Taproot-support.xml b/static/bitcoin-dev/Nov_2021/combined_bitcoinj-fork-with-Taproot-support.xml index bf58e8960a..065555f63e 100644 --- a/static/bitcoin-dev/Nov_2021/combined_bitcoinj-fork-with-Taproot-support.xml +++ b/static/bitcoin-dev/Nov_2021/combined_bitcoinj-fork-with-Taproot-support.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoinj fork with Taproot support - 2025-09-26T15:34:14.332284+00:00 + 2025-10-11T21:43:44.327661+00:00 python-feedgen n1ms0s 2021-11-17 20:05:55+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - bitcoinj fork with Taproot support - 2025-09-26T15:34:14.332416+00:00 + 2025-10-11T21:43:44.327815+00:00 2021-11-17T20:05:55+00:00 On the Bitcoin development mailing list, a discussion took place regarding the relaying of P2TR spends. Prior to version 0.19.0, creating outputs with an unknown witness version was considered non-standard and violated BIP 173. However, this issue was resolved in PR #15846 for version 0.19.0+. Despite the fix, post-segwit pre-taproot Bitcoin Core releases still reject P2TR spends. A user on the Bitcoin StackExchange forum suggested a potential solution using bitcoinj. They made it so that the client only connects to nodes with at least protocol version 70016, which successfully addressed the issue. In another discussion led by Andrew Chow on November 17th, 2021, it was mentioned that creating outputs with an unknown witness version was previously deemed non-standard and violated BIP 173. The problem at hand, however, pertains to getting P2TR spends to relay. All post-segwit pre-taproot Bitcoin Core releases currently reject these spends. A developer named n1ms0s recently shared their work on a fork of bitcoinj that includes basic Taproot support. This fork allows for sending and receiving with Taproot addresses using a bitcoinj SPV wallet, as well as public/private key tweaking. However, when attempting to broadcast a Taproot transaction to older nodes (around version 0.18.0), an error response stating "Witness version reserved for soft-fork upgrades" is encountered. Seeking assistance, the developer posted a question on Stack Exchange, inviting feedback and contributions to address this issue.Overall, the discussions highlight the challenges surrounding P2TR spends and the rejection of such spends by post-segwit pre-taproot Bitcoin Core releases. Additionally, they shed light on the efforts of a developer working on a bitcoinj fork with basic Taproot support, who seeks assistance in resolving the issue encountered when broadcasting Taproot transactions to older nodes. diff --git a/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 01bd473059..3b44bdc4de 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -2,7 +2,7 @@ 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T15:44:02.165244+00:00 + 2025-10-11T21:56:01.921608+00:00 python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -82,10 +82,11 @@ + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T15:44:02.165439+00:00 + 2025-10-11T21:56:01.921794+00:00 2023-03-13T16:38:25+00:00 On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to diff --git a/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml b/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml index 36292c4d9f..c0fc04a06b 100644 --- a/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml +++ b/static/bitcoin-dev/Nov_2022/combined_On-mempool-policy-consistency.xml @@ -2,7 +2,7 @@ 2 Combined summary - On mempool policy consistency - 2025-09-26T15:44:00.048645+00:00 + 2025-10-11T21:55:59.798042+00:00 python-feedgen email at yancy.lol 2022-11-10 14:38:27+00:00 @@ -138,10 +138,11 @@ + 2 Combined summary - On mempool policy consistency - 2025-09-26T15:44:00.048830+00:00 + 2025-10-11T21:55:59.798233+00:00 2022-11-10T14:38:27+00:00 The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases. The discussion also touched upon diff --git a/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml b/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml index 12b1870801..0840a237d6 100644 --- a/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml +++ b/static/bitcoin-dev/Nov_2022/combined_Using-Full-RBF-to-fix-BIP-125-Rule-3-Pinning-with-nLockTime.xml @@ -2,7 +2,7 @@ 2 Combined summary - Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime - 2025-09-26T15:44:04.307168+00:00 + 2025-10-11T21:56:04.048618+00:00 python-feedgen David A. Harding 2022-11-11 03:00:58+00:00 @@ -22,10 +22,11 @@ + 2 Combined summary - Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime - 2025-09-26T15:44:04.307321+00:00 + 2025-10-11T21:56:04.048795+00:00 2022-11-11T03:00:58+00:00 In a recent email thread on the bitcoin-dev mailing list, Peter Todd proposed a solution to address Rule #3 pinning in multi-party transactions. The attack involves one party broadcasting a low fee transaction that ties up funds from other parties, making it difficult for them to spend their inputs unless they pay for the malicious party's transaction. Todd's solution involves pre-signing transactions with nLockTime set far into the future and spending one or more inputs of the transaction with a high enough fee to replace any attempts to exploit the rule.However, there are several open questions and challenges associated with this solution. One issue is determining the high fee needed to guarantee replacements with high odds. Since the sat/vb (satoshi per virtual byte) is unknown at the time of signature exchange among participants, overshooting and adopting a historical worst-case mempool feerate may be necessary. This introduces economic lower bounds on the funds involved in a contract, creating a griefing vector where a participant could deliberately pin to inflict asymmetric damage without entering into any fee competition.To address these challenges, participants may consider unilaterally spending after a protocol/implementation timepoint to save the time value of their contributed UTXOs over operation success. Additionally, a proposed more workable solution is to rely on package-relay, an ephemeral anchor output, and a special replacement regime (e.g., nVersion=3). This would allow the multi-party funded transaction coordinator to unilateral fee-bump, step-by-step, without relying on assumptions about the knowledge of network mempools and burning excessive fees.The email exchange between Antoine and Peter Todd also highlights the issue of incentive compatibility when considering miner harvesting attacks as part of the threat model. It remains unclear if the v3 rules that depend on miners arbitrarily rejecting transactions from their mempools are sufficiently incentive compatible to work effectively.Overall, the Bitcoin community is actively discussing ways to prevent pinning attacks on multi-party transactions. Implementing pre-signed transactions with nLockTime set in the future and utilizing a combination of package-relay, an ephemeral anchor output, and a special replacement regime could potentially address this issue. However, there are still challenges to be addressed, such as determining the appropriate fee and ensuring incentive compatibility in the face of potential miner harvesting attacks. diff --git a/static/bitcoin-dev/Nov_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml b/static/bitcoin-dev/Nov_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml index 7bfdf45272..e8bc1461a1 100644 --- a/static/bitcoin-dev/Nov_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml +++ b/static/bitcoin-dev/Nov_2023/combined_-Mempool-spam-Should-we-as-developers-reject-non-standard-Taproot-transactions-from-full-nodes-.xml @@ -2,7 +2,7 @@ 2 Combined summary - [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? - 2025-09-26T14:27:03.841326+00:00 + 2025-10-11T21:45:20.015578+00:00 python-feedgen ArmchairCryptologist 2023-11-04 09:58:48+00:00 @@ -105,10 +105,11 @@ + 2 Combined summary - [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? - 2025-09-26T14:27:03.841485+00:00 + 2025-10-11T21:45:20.015837+00:00 2023-11-04T09:58:48+00:00 Bitcoin developers are engaged in discussions to find solutions for the current high fee environment, prevent spam transactions, and ensure the long-term sustainability and decentralization of the network. Proposed solutions include fixing layered protocols, introducing new opcodes like OP_ZKP, reallocating block space, and penalizing non-economic transactions. The goal is to strike a balance between reducing fees, preventing spam, and maintaining the economic viability and security of the network. Ali Sherief expresses concern over congestion caused by side projects like BRC-20 and suggests implementing BIPs or commits in the Bitcoin Core codebase to address the issue. Michael Folkson argues that consensus-compatible transactions paying market-rate fees are functioning as intended. However, the debate continues on finding effective solutions while preserving maximum freedom and valid use cases. The email exchange also discusses the purpose of paying higher transaction fees than the received amount, the lack of Lightning wallets for desktop, and the need for GUI wallets to interact with the Lightning Network. Overall, the focus is on addressing congestion, preventing spam, and ensuring smooth operation of the Bitcoin network as a peer-to-peer digital currency. diff --git a/static/bitcoin-dev/Nov_2023/combined_Future-of-the-bitcoin-dev-mailing-list.xml b/static/bitcoin-dev/Nov_2023/combined_Future-of-the-bitcoin-dev-mailing-list.xml index cc301add00..d463f71f61 100644 --- a/static/bitcoin-dev/Nov_2023/combined_Future-of-the-bitcoin-dev-mailing-list.xml +++ b/static/bitcoin-dev/Nov_2023/combined_Future-of-the-bitcoin-dev-mailing-list.xml @@ -2,7 +2,7 @@ 2 Combined summary - Future of the bitcoin-dev mailing list - 2025-09-26T14:26:46.703886+00:00 + 2025-10-11T21:45:15.764769+00:00 python-feedgen Brad Morrison 2024-01-04 13:50:51+00:00 @@ -109,10 +109,11 @@ + 2 Combined summary - Future of the bitcoin-dev mailing list - 2025-09-26T14:26:46.704038+00:00 + 2025-10-11T21:45:15.765009+00:00 2024-01-04T13:50:51+00:00 The Linux Foundation's mailing lists, primarily running on an outdated Mailman version, necessitate migration or upgrade. Nostr is proposed as a replacement due to its decentralized nature, potentially through a custom Nostr Improvement Proposal (NIP) for relay functions. diff --git a/static/bitcoin-dev/Nov_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml b/static/bitcoin-dev/Nov_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml index ec64a6c6ee..ea7ca62018 100644 --- a/static/bitcoin-dev/Nov_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml +++ b/static/bitcoin-dev/Nov_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml @@ -2,7 +2,7 @@ 2 Combined summary - OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely - 2025-09-26T14:27:10.282178+00:00 + 2025-10-11T21:45:24.263254+00:00 python-feedgen Peter Todd 2023-11-14 19:50:04+00:00 @@ -105,10 +105,11 @@ + 2 Combined summary - OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely - 2025-09-26T14:27:10.282342+00:00 + 2025-10-11T21:45:24.263495+00:00 2023-11-14T19:50:04+00:00 The discussion addresses technical challenges within the Lightning Network, such as managing outdated states and transaction fees. It is recognized that while security could be improved, keeping transaction fees to a minimum relative to the channel's total value is essential for economic viability. diff --git a/static/bitcoin-dev/Nov_2023/combined_Purely-off-chain-coin-colouring.xml b/static/bitcoin-dev/Nov_2023/combined_Purely-off-chain-coin-colouring.xml index 4380b4d4bf..95379b9bf4 100644 --- a/static/bitcoin-dev/Nov_2023/combined_Purely-off-chain-coin-colouring.xml +++ b/static/bitcoin-dev/Nov_2023/combined_Purely-off-chain-coin-colouring.xml @@ -2,7 +2,7 @@ 2 Combined summary - Purely off-chain coin colouring - 2025-09-26T14:26:44.560699+00:00 + 2025-10-11T21:45:13.628501+00:00 python-feedgen vjudeu at gazeta.pl 2023-11-20 19:47:13+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - Purely off-chain coin colouring - 2025-09-26T14:26:44.560856+00:00 + 2025-10-11T21:45:13.628685+00:00 2023-11-20T19:47:13+00:00 Blockchain standardization is a key topic, with suggestions to treat signature R-values as Taproot-based public keys for consistent protocol interpretation. Another approach proposes using commitments that can push any data and nest future commitments within previous ones, ensuring they remain off-chain by starting with OP_RETURN and expressing r-values as 256-bit numbers. diff --git a/static/bitcoin-dev/Nov_2023/combined_bitcoin-dev-Digest-Vol-102-Issue-15.xml b/static/bitcoin-dev/Nov_2023/combined_bitcoin-dev-Digest-Vol-102-Issue-15.xml index bb97b3faf9..745e8f652b 100644 --- a/static/bitcoin-dev/Nov_2023/combined_bitcoin-dev-Digest-Vol-102-Issue-15.xml +++ b/static/bitcoin-dev/Nov_2023/combined_bitcoin-dev-Digest-Vol-102-Issue-15.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 102, Issue 15 - 2025-09-26T14:27:05.988280+00:00 + 2025-10-11T21:45:22.139315+00:00 python-feedgen Luke Kenneth Casson Leighton 2023-11-08 02:00:00+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 102, Issue 15 - 2025-09-26T14:27:05.988408+00:00 + 2025-10-11T21:45:22.139548+00:00 2023-11-08T02:00:00+00:00 The discussion opens with a recognition of the importance of email lists as a means to stay abreast of technical dialogues within a particular community. It's suggested that email lists are a preferred method for knowledge sharing, and there is an active search for alternatives to the current system, indicating some limitations or the need for better features. Alain Williams, who previously chaired UKUUG 25 years ago, is mentioned as a competent individual capable of managing such lists through his platform at lists.phcomp.co.uk. This reference points towards the quest for reliable list management. diff --git a/static/bitcoin-dev/Nov_2023/combined_ossification-and-misaligned-incentive-concerns.xml b/static/bitcoin-dev/Nov_2023/combined_ossification-and-misaligned-incentive-concerns.xml index 01afa022c6..682807b60c 100644 --- a/static/bitcoin-dev/Nov_2023/combined_ossification-and-misaligned-incentive-concerns.xml +++ b/static/bitcoin-dev/Nov_2023/combined_ossification-and-misaligned-incentive-concerns.xml @@ -2,7 +2,7 @@ 2 Combined summary - ossification and misaligned incentive concerns - 2025-09-26T14:26:57.467849+00:00 + 2025-10-11T21:45:17.891530+00:00 python-feedgen JK 2023-11-07 12:24:39+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - ossification and misaligned incentive concerns - 2025-09-26T14:26:57.468065+00:00 + 2025-10-11T21:45:17.891726+00:00 2023-11-07T12:24:39+00:00 The email discussion opens with a critical examination of Bitcoin's economic model, particularly the challenges stemming from its programmed halvings and inflation rate. It points out that the system's initial expansion, which helped stakeholders weather high inflation phases, is nearing saturation, and the lack of control over the transition from high to low inflation rates is causing favoritism and conflicts of interest among different user groups. This imbalance has been evident for years, with transaction fees being a contentious issue, as demonstrated by the recent uproar caused by Ordinals. The concern is that users who actively transact will not indefinitely bear the cost of network security, benefiting passive stakeholders who do not contribute. The writer suggests that a possible solution might involve a conditional delay in halvings during prolonged network regression periods, thus preventing free rider problems and ensuring compatibility between new and old code until a critical event necessitates change. diff --git a/static/bitcoin-dev/Oct_2012/combined_0-7-1-release-candidate-1-ready-for-testing.xml b/static/bitcoin-dev/Oct_2012/combined_0-7-1-release-candidate-1-ready-for-testing.xml index ad9adb84ab..76f7e676e0 100644 --- a/static/bitcoin-dev/Oct_2012/combined_0-7-1-release-candidate-1-ready-for-testing.xml +++ b/static/bitcoin-dev/Oct_2012/combined_0-7-1-release-candidate-1-ready-for-testing.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.7.1 release candidate 1 ready for testing - 2023-08-01T04:00:19.304440+00:00 + 2025-10-11T21:48:18.634278+00:00 + python-feedgen Arklan Uth Oslin 2012-10-11 20:08:13+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - 0.7.1 release candidate 1 ready for testing - 2023-08-01T04:00:19.304440+00:00 + 2025-10-11T21:48:18.634472+00:00 - In an email thread between Arklan Uth Oslin and Jeff Garzik on October 11, 2012, Arklan suggests the creation of a separate Bitcoin test list. However, Garzik argues that the current bitcoin-devel list has low traffic and there is no issue of crowding. He believes that having a separate list would make it more difficult for people to participate. They discuss the importance of testing and the process involved.A member of the Bitcoin community has requested the creation of a Bitcoin-test mailing list for discussions related to testing, tools, ideas, and general chatter. This request comes after the release of Bitcoin version 0.7.1's first candidate, which includes minor bug fixes, new features, and dependency changes. The most significant new feature is the addition of a boolean argument to the RPC 'stop' command that sets -detachdb to create standalone database .dat files before shutting down. Another notable addition is the -salvagewallet command-line option, which salvages public/private keys and master encryption keys into a new wallet.dat file. The release also includes updates to dependencies such as Qt 4.8.2 for Windows builds and openssl 1.0.1c. Various bug fixes were implemented, including better detection and handling of corrupt wallet.dat and blkindex.dat files, elimination of occasional crashes on exit, and fixing an uninitialized variable bug that could cause transactions to be reported out of order. Users are also warned about creating fresh wallet backups after encrypting their wallet.Gavin Andresen inquires about the progress on a release candidate QA sanity testing plan, and the respondent replies that they have considered his suggestions. They discuss different types of tests, including automated tests, recorded tests, and video-based sanity checks. They also mention the protocol-based GAT tests that should be run against all releases. The respondent suggests creating a separate bitcoin-test mailing list for discussions related to testing, tools, ideas, and chatter, without reporting bugs as the dev list is more focused. They provide a link to the Bitcoin version 0.7.1 release candidate 1 and mention some of its new features, dependency changes, and bug fixes.Arklan emails Steve to inquire about the test cases he had worked on but has not received a response yet. However, Arklan plans to go through the release candidate (RC) tonight. Jeff Garzik also posted a call for testing in a forum thread regarding a release candidate QA sanity testing plan. The email includes a signature with links to deploy New Relic APM and join the Bitcoin-development mailing list.Gavin Andresen, a prominent figure in the Bitcoin community, posts a question on October 11th, 2012, regarding the progress made towards a release candidate QA sanity testing plan. Jeff Garzik responds by sharing a forum thread where he previously called for testing. Jeff Garzik is the Founder and CEO of exMULTI, a company focusing on blockchain-related projects.The Bitcoin version 0.7.1 release candidate 1 is available for download from the sourceforge website. This release focuses on bug fixes, with minor changes and features added. The new features include the ability to create standalone database .dat files before shutting down, salvage public/private keys and master encryption keys into a new wallet.dat file, and automatic import of $DataDir/bootstrap.dat if it exists. Dependency updates include Qt 4.8.2 for Windows builds and openssl 1.0.1c for security reasons. Bug fixes address issues such as better detection and handling of corrupt wallet.dat and blkindex.dat files, eliminating occasional crashes on exit, fixing an uninitialized variable bug that could cause transactions to be reported out of order, and warning users about creating fresh wallet backups after encrypting their wallet. Gavin Andresen shares the details of the update as one of the core developers behind Bitcoin. 2012-10-11T20:08:13+00:00 + In an email thread between Arklan Uth Oslin and Jeff Garzik on October 11, 2012, Arklan suggests the creation of a separate Bitcoin test list. However, Garzik argues that the current bitcoin-devel list has low traffic and there is no issue of crowding. He believes that having a separate list would make it more difficult for people to participate. They discuss the importance of testing and the process involved.A member of the Bitcoin community has requested the creation of a Bitcoin-test mailing list for discussions related to testing, tools, ideas, and general chatter. This request comes after the release of Bitcoin version 0.7.1's first candidate, which includes minor bug fixes, new features, and dependency changes. The most significant new feature is the addition of a boolean argument to the RPC 'stop' command that sets -detachdb to create standalone database .dat files before shutting down. Another notable addition is the -salvagewallet command-line option, which salvages public/private keys and master encryption keys into a new wallet.dat file. The release also includes updates to dependencies such as Qt 4.8.2 for Windows builds and openssl 1.0.1c. Various bug fixes were implemented, including better detection and handling of corrupt wallet.dat and blkindex.dat files, elimination of occasional crashes on exit, and fixing an uninitialized variable bug that could cause transactions to be reported out of order. Users are also warned about creating fresh wallet backups after encrypting their wallet.Gavin Andresen inquires about the progress on a release candidate QA sanity testing plan, and the respondent replies that they have considered his suggestions. They discuss different types of tests, including automated tests, recorded tests, and video-based sanity checks. They also mention the protocol-based GAT tests that should be run against all releases. The respondent suggests creating a separate bitcoin-test mailing list for discussions related to testing, tools, ideas, and chatter, without reporting bugs as the dev list is more focused. They provide a link to the Bitcoin version 0.7.1 release candidate 1 and mention some of its new features, dependency changes, and bug fixes.Arklan emails Steve to inquire about the test cases he had worked on but has not received a response yet. However, Arklan plans to go through the release candidate (RC) tonight. Jeff Garzik also posted a call for testing in a forum thread regarding a release candidate QA sanity testing plan. The email includes a signature with links to deploy New Relic APM and join the Bitcoin-development mailing list.Gavin Andresen, a prominent figure in the Bitcoin community, posts a question on October 11th, 2012, regarding the progress made towards a release candidate QA sanity testing plan. Jeff Garzik responds by sharing a forum thread where he previously called for testing. Jeff Garzik is the Founder and CEO of exMULTI, a company focusing on blockchain-related projects.The Bitcoin version 0.7.1 release candidate 1 is available for download from the sourceforge website. This release focuses on bug fixes, with minor changes and features added. The new features include the ability to create standalone database .dat files before shutting down, salvage public/private keys and master encryption keys into a new wallet.dat file, and automatic import of $DataDir/bootstrap.dat if it exists. Dependency updates include Qt 4.8.2 for Windows builds and openssl 1.0.1c for security reasons. Bug fixes address issues such as better detection and handling of corrupt wallet.dat and blkindex.dat files, eliminating occasional crashes on exit, fixing an uninitialized variable bug that could cause transactions to be reported out of order, and warning users about creating fresh wallet backups after encrypting their wallet. Gavin Andresen shares the details of the update as one of the core developers behind Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_0-7-1-release.xml b/static/bitcoin-dev/Oct_2012/combined_0-7-1-release.xml index da771488cf..f27790671a 100644 --- a/static/bitcoin-dev/Oct_2012/combined_0-7-1-release.xml +++ b/static/bitcoin-dev/Oct_2012/combined_0-7-1-release.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.7.1 release - 2023-08-01T03:58:27.471425+00:00 + 2025-10-11T21:48:16.512472+00:00 + python-feedgen Jeff Garzik 2012-10-03 19:53:41+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - 0.7.1 release - 2023-08-01T03:58:27.472383+00:00 + 2025-10-11T21:48:16.512628+00:00 - In an email conversation on October 3, 2012, Gavin Andresen suggested the addition of '-reindex' to perform in-place reindexing of blockchain data files, acknowledging that it needed testing. He also agreed to a proposal of not requesting blocks from peers with fewer blocks than them. Another suggestion was made to add the new RPC "lockunspent" to prevent spending selected outputs, which Jeff Garzik supported but raised concerns about its ability to miss raw transactions that spend outputs not in the wallet. However, Garzik deemed it acceptable since listunspent is already wallet-based and should be noted.During the same conversation, Gavin Andresen and Wladimir agreed to do a 0.7.1 release specifically to fix the bug where clicking on a bitcoin: URI led to no action on Windows. They also decided to add pull requests for in-place reindexing of blockchain data files and adding LOCK() for proxy-related data structures to prevent random crashes due to missing synchronization primitives. These pull requests were considered high priority and should be included in the upcoming 0.7.1 release, while others could wait. Links to the pull requests were provided in the email.Following these discussions, the Bitcoin community has agreed upon a 0.7.1 release to address the Windows bug related to clicking on a bitcoin: URI and experiencing no response. Additionally, a proposed solution to fix the problem of receiving a DB_RUNRECOVERY error on startup after upgrading from a binary running an incompatible version of BDB has been submitted as a pull request. This pull request addresses half of the issue along with fixing several other cases of broken wallets. Another proposed solution involves deleting the problematic blkindex.dat file and recreating it from the blk000?.dat files.Gavin Andresen, a prominent member of the Bitcoin community, inquires if there are any other high-priority pull requests that should be included in the upcoming 0.7.1 release. Finally, he suggests including other pull requests that have the potential to fix issues with the new raw transactions API.Overall, these discussions and proposals highlight the ongoing efforts within the Bitcoin community to address bugs and improve the functionality of the system through the upcoming 0.7.1 release. 2012-10-03T19:53:41+00:00 + In an email conversation on October 3, 2012, Gavin Andresen suggested the addition of '-reindex' to perform in-place reindexing of blockchain data files, acknowledging that it needed testing. He also agreed to a proposal of not requesting blocks from peers with fewer blocks than them. Another suggestion was made to add the new RPC "lockunspent" to prevent spending selected outputs, which Jeff Garzik supported but raised concerns about its ability to miss raw transactions that spend outputs not in the wallet. However, Garzik deemed it acceptable since listunspent is already wallet-based and should be noted.During the same conversation, Gavin Andresen and Wladimir agreed to do a 0.7.1 release specifically to fix the bug where clicking on a bitcoin: URI led to no action on Windows. They also decided to add pull requests for in-place reindexing of blockchain data files and adding LOCK() for proxy-related data structures to prevent random crashes due to missing synchronization primitives. These pull requests were considered high priority and should be included in the upcoming 0.7.1 release, while others could wait. Links to the pull requests were provided in the email.Following these discussions, the Bitcoin community has agreed upon a 0.7.1 release to address the Windows bug related to clicking on a bitcoin: URI and experiencing no response. Additionally, a proposed solution to fix the problem of receiving a DB_RUNRECOVERY error on startup after upgrading from a binary running an incompatible version of BDB has been submitted as a pull request. This pull request addresses half of the issue along with fixing several other cases of broken wallets. Another proposed solution involves deleting the problematic blkindex.dat file and recreating it from the blk000?.dat files.Gavin Andresen, a prominent member of the Bitcoin community, inquires if there are any other high-priority pull requests that should be included in the upcoming 0.7.1 release. Finally, he suggests including other pull requests that have the potential to fix issues with the new raw transactions API.Overall, these discussions and proposals highlight the ongoing efforts within the Bitcoin community to address bugs and improve the functionality of the system through the upcoming 0.7.1 release. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Bitcoin-Testing-Project.xml b/static/bitcoin-dev/Oct_2012/combined_Bitcoin-Testing-Project.xml index 0ac238726d..4006b9bfc2 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Bitcoin-Testing-Project.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Bitcoin-Testing-Project.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Testing Project - 2023-08-01T03:56:40.402090+00:00 + 2025-10-11T21:48:25.011785+00:00 + python-feedgen Arklan Uth Oslin 2012-10-03 16:11:39+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Testing Project - 2023-08-01T03:56:40.402090+00:00 + 2025-10-11T21:48:25.011968+00:00 - Steve, a Bitcoin developer, is looking to create a QA environment that will enhance testing and allow testers to excel. He believes that Git is too developer-centric for organizing testing, but acknowledges its compatibility with a large amount of software. The linking between bugs, requirements, fixes, re-tests, and regression test plans is deemed vital. Steve also mentions the need to organize testing campaigns, assign tests, work units, and relevant documentation/scripts/ideas.Currently, there are four potential places to report bugs - Jenkins (and unit tests), Git, the mailing list, and forums such as Bitcointalk. However, Github has become the authoritative place to report issues. Failed tests are reported on Github by the pull tester. There are currently 232 issues on Github, classified into categories like "Bug," "Improvement," "GUI," and "Wallet." Github issues can be easily referred to in commits using #123 with automatic linking. While other bug reporting systems may exist, Wladimir, another Bitcoin developer, does not see the value in switching to another system.In an email, Steve expresses his desire to shift away from Bettermeans and focus on test-driven development with a strong emphasis on requirements management and automation. He has been developing rudimentary requirement sets, basic requirement tracking, and stress tests to prove the requirements. Steve has installed open-source applications like Mantis, SalomeTMF, and Bugzilla to evaluate the best workflow process. He is finalizing workflow flow diagrams and welcomes anyone interested in helping or reviewing the processes to reach out via email.In September 2012, Wladimir and Daniel F discuss the addition of a developer resources page to bitcoin.org. Wladimir agrees to write the page, which would link to an editable and expandable wiki page for developer resources. They decide that adding a direct link to the developer resources page on the main site makes sense since the front page already has wiki links.On September 26th, 2012, Wladimir proposes creating a page on bitcoin.org that would link to a wiki page of developer resources. He acknowledges the potential for disagreement but suggests being pragmatic. This separate page would provide an easy link from the main site while still allowing for editable and expandable content.Bitcoin developer Matt Corallo discusses the usefulness of pulltester and Jenkins, stating that both run the same set of scripts. He suggests keeping them and improving if necessary. Corallo also proposes creating a page that links all the developer resources for Bitcoin development, including information on checking out the source code, contribution guidelines, where to ask development problems, and which bugs to solve first. While willing to write this page, he acknowledges that it may spark discussions about what should be included on bitcoin.org.In another email, Steve requests help with reviewing processes or even just encouragement. Another person responds, expressing limited availability but providing encouragement and emphasizing the importance of more testing. The email thread includes a promotional message for a Live Security Virtual Conference covering endpoint security, mobile security, and malware threats. It also mentions the Bitcoin-development mailing list.Overall, the discussion revolves around testing tools and methodologies in the context of Bitcoin development. Steve is seeking to create a conducive QA environment, while Wladimir and Daniel F discuss adding a developer resources page to bitcoin.org. Matt Corallo emphasizes the usefulness of pulltester and Jenkins and proposes linking all developer resources. The emails highlight the importance of testing and invite assistance and reviews from interested parties. 2012-10-03T16:11:39+00:00 + Steve, a Bitcoin developer, is looking to create a QA environment that will enhance testing and allow testers to excel. He believes that Git is too developer-centric for organizing testing, but acknowledges its compatibility with a large amount of software. The linking between bugs, requirements, fixes, re-tests, and regression test plans is deemed vital. Steve also mentions the need to organize testing campaigns, assign tests, work units, and relevant documentation/scripts/ideas.Currently, there are four potential places to report bugs - Jenkins (and unit tests), Git, the mailing list, and forums such as Bitcointalk. However, Github has become the authoritative place to report issues. Failed tests are reported on Github by the pull tester. There are currently 232 issues on Github, classified into categories like "Bug," "Improvement," "GUI," and "Wallet." Github issues can be easily referred to in commits using #123 with automatic linking. While other bug reporting systems may exist, Wladimir, another Bitcoin developer, does not see the value in switching to another system.In an email, Steve expresses his desire to shift away from Bettermeans and focus on test-driven development with a strong emphasis on requirements management and automation. He has been developing rudimentary requirement sets, basic requirement tracking, and stress tests to prove the requirements. Steve has installed open-source applications like Mantis, SalomeTMF, and Bugzilla to evaluate the best workflow process. He is finalizing workflow flow diagrams and welcomes anyone interested in helping or reviewing the processes to reach out via email.In September 2012, Wladimir and Daniel F discuss the addition of a developer resources page to bitcoin.org. Wladimir agrees to write the page, which would link to an editable and expandable wiki page for developer resources. They decide that adding a direct link to the developer resources page on the main site makes sense since the front page already has wiki links.On September 26th, 2012, Wladimir proposes creating a page on bitcoin.org that would link to a wiki page of developer resources. He acknowledges the potential for disagreement but suggests being pragmatic. This separate page would provide an easy link from the main site while still allowing for editable and expandable content.Bitcoin developer Matt Corallo discusses the usefulness of pulltester and Jenkins, stating that both run the same set of scripts. He suggests keeping them and improving if necessary. Corallo also proposes creating a page that links all the developer resources for Bitcoin development, including information on checking out the source code, contribution guidelines, where to ask development problems, and which bugs to solve first. While willing to write this page, he acknowledges that it may spark discussions about what should be included on bitcoin.org.In another email, Steve requests help with reviewing processes or even just encouragement. Another person responds, expressing limited availability but providing encouragement and emphasizing the importance of more testing. The email thread includes a promotional message for a Live Security Virtual Conference covering endpoint security, mobile security, and malware threats. It also mentions the Bitcoin-development mailing list.Overall, the discussion revolves around testing tools and methodologies in the context of Bitcoin development. Steve is seeking to create a conducive QA environment, while Wladimir and Daniel F discuss adding a developer resources page to bitcoin.org. Matt Corallo emphasizes the usefulness of pulltester and Jenkins and proposes linking all developer resources. The emails highlight the importance of testing and invite assistance and reviews from interested parties. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Draft-BIP-for-Bloom-filtering.xml b/static/bitcoin-dev/Oct_2012/combined_Draft-BIP-for-Bloom-filtering.xml index 6334722678..91f8cfd487 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Draft-BIP-for-Bloom-filtering.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Draft-BIP-for-Bloom-filtering.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Draft BIP for Bloom filtering - 2023-08-01T04:02:04.922697+00:00 + 2025-10-11T21:48:39.881160+00:00 + python-feedgen Mike Hearn 2013-02-20 12:44:56+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - Draft BIP for Bloom filtering - 2023-08-01T04:02:04.922697+00:00 + 2025-10-11T21:48:39.881395+00:00 - In the provided context, the author discusses the proposal for delaying the reception of inventory messages (invs) in the Bitcoin Improvement Proposal (BIP). They realize that the current method of delaying invs is arbitrary and suggest a better approach. The proposed solution involves sending a bloom filter in the version message itself, allowing for the filter to be calculated simultaneously with establishing network connections.The author acknowledges that creating a Bloom filter is a fast process. However, they note that deterministic wallets may require multiple calculations to find the keys to scan for. Despite this potential complexity, the proposed approach of including a bloom filter in the version message allows for efficient parallel processing.Additionally, the author mentions the process of obtaining an allocated number for the BIP. They feel that this process may be excessive for their particular proposal. This demonstrates the author's consideration of the existing procedures and their awareness of the broader framework within which their suggestion exists.By addressing the issue of delaying invs and proposing an alternative method involving bloom filters, the author highlights a potential improvement to the Bitcoin protocol. Their understanding of the technical aspects and the existing processes surrounding BIPs lends credibility to their proposal. 2013-02-20T12:44:56+00:00 + In the provided context, the author discusses the proposal for delaying the reception of inventory messages (invs) in the Bitcoin Improvement Proposal (BIP). They realize that the current method of delaying invs is arbitrary and suggest a better approach. The proposed solution involves sending a bloom filter in the version message itself, allowing for the filter to be calculated simultaneously with establishing network connections.The author acknowledges that creating a Bloom filter is a fast process. However, they note that deterministic wallets may require multiple calculations to find the keys to scan for. Despite this potential complexity, the proposed approach of including a bloom filter in the version message allows for efficient parallel processing.Additionally, the author mentions the process of obtaining an allocated number for the BIP. They feel that this process may be excessive for their particular proposal. This demonstrates the author's consideration of the existing procedures and their awareness of the broader framework within which their suggestion exists.By addressing the issue of delaying invs and proposing an alternative method involving bloom filters, the author highlights a potential improvement to the Bitcoin protocol. Their understanding of the technical aspects and the existing processes surrounding BIPs lends credibility to their proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Electrum-security-model-concerns.xml b/static/bitcoin-dev/Oct_2012/combined_Electrum-security-model-concerns.xml index 6d931a2b86..5d4a36e1a4 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Electrum-security-model-concerns.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Electrum-security-model-concerns.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Electrum security model concerns - 2023-08-01T03:58:45.909360+00:00 + 2025-10-11T21:48:31.383211+00:00 + python-feedgen Mike Hearn 2012-11-16 17:44:32+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Electrum security model concerns - 2023-08-01T03:58:45.910359+00:00 + 2025-10-11T21:48:31.383428+00:00 - In a conversation, the handling of wallet state in the presence of re-orgs is a concern. Transactions are checked to appear in the blockchain, but it is unclear if the wallet will be in the right state during a chain switch. A message from Thomas implies that there is no re-org handling at all. The conversation then shifts to a comparison between Electrum and MultiBit in terms of their handling of SPV work. The speaker asks how they differ beyond deterministic wallet seeding. Another conversation discusses the challenges of finding someone trustworthy and capable to work on the bitcoin.org website and emphasizes the need for better communication and understanding within the community to avoid conflicts. In an email thread, various issues related to Bitcoin are discussed, including concerns about the security model of Electrum and the importance of effectively communicating transaction confidence to users. The conversation also touches upon the challenges of developing and promoting Bitcoin. The conversation revolves around the functionality and potential risks of Electrum as a thin client, with a focus on its merchant daemon. The unauthenticated cleartext JSON protocol between clients and servers is mentioned, as well as the difficulty in communicating transaction confidence to users. The conversation highlights the need for clear explanations and appropriate caution for clients and security models on bitcoin.org. Another discussion addresses the security implications of thin clients, particularly Electrum, and the lack of awareness among users about the associated risks. The conversation emphasizes the need for better security features in client models and improved communication to prevent negative press for Bitcoin. The author of a message requests a proper discussion on understanding the bitcoinj security model. They have rewritten and extended a page on the subject, linking to the ETH paper, and highlight the differences between Electrum and bitcoinj in terms of user and app developer focus. The future divergence of software used by end-users and merchants is predicted, making it easier to tailor documentation to each demographic. Additionally, optimizations such as bloom filtering and better peer selection logic may render Electrum-type services obsolete. Concerns are raised about the security model of Electrum, as the website lacks detailed information and makes factually incorrect claims. A proper discussion is needed to avoid misunderstandings and encourage safer user behaviors. The bitcoinj security model is also critiqued for false claims regarding detecting double spends, emphasizing the need for a thorough examination of Electrum's security model. 2012-11-16T17:44:32+00:00 + In a conversation, the handling of wallet state in the presence of re-orgs is a concern. Transactions are checked to appear in the blockchain, but it is unclear if the wallet will be in the right state during a chain switch. A message from Thomas implies that there is no re-org handling at all. The conversation then shifts to a comparison between Electrum and MultiBit in terms of their handling of SPV work. The speaker asks how they differ beyond deterministic wallet seeding. Another conversation discusses the challenges of finding someone trustworthy and capable to work on the bitcoin.org website and emphasizes the need for better communication and understanding within the community to avoid conflicts. In an email thread, various issues related to Bitcoin are discussed, including concerns about the security model of Electrum and the importance of effectively communicating transaction confidence to users. The conversation also touches upon the challenges of developing and promoting Bitcoin. The conversation revolves around the functionality and potential risks of Electrum as a thin client, with a focus on its merchant daemon. The unauthenticated cleartext JSON protocol between clients and servers is mentioned, as well as the difficulty in communicating transaction confidence to users. The conversation highlights the need for clear explanations and appropriate caution for clients and security models on bitcoin.org. Another discussion addresses the security implications of thin clients, particularly Electrum, and the lack of awareness among users about the associated risks. The conversation emphasizes the need for better security features in client models and improved communication to prevent negative press for Bitcoin. The author of a message requests a proper discussion on understanding the bitcoinj security model. They have rewritten and extended a page on the subject, linking to the ETH paper, and highlight the differences between Electrum and bitcoinj in terms of user and app developer focus. The future divergence of software used by end-users and merchants is predicted, making it easier to tailor documentation to each demographic. Additionally, optimizations such as bloom filtering and better peer selection logic may render Electrum-type services obsolete. Concerns are raised about the security model of Electrum, as the website lacks detailed information and makes factually incorrect claims. A proper discussion is needed to avoid misunderstandings and encourage safer user behaviors. The bitcoinj security model is also critiqued for false claims regarding detecting double spends, emphasizing the need for a thorough examination of Electrum's security model. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Fwd-Re-Bitcoin-Testing-Project.xml b/static/bitcoin-dev/Oct_2012/combined_Fwd-Re-Bitcoin-Testing-Project.xml index 46c06a9ca9..5d32ff48e4 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Fwd-Re-Bitcoin-Testing-Project.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Fwd-Re-Bitcoin-Testing-Project.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Re: Bitcoin Testing Project - 2023-08-01T03:57:53.073732+00:00 + 2025-10-11T21:48:22.880260+00:00 + python-feedgen Gavin Andresen 2012-10-03 17:30:44+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Fwd: Re: Bitcoin Testing Project - 2023-08-01T03:57:53.073732+00:00 + 2025-10-11T21:48:22.880449+00:00 - The Testing Project, which aims to create a self-organizing community for QA testing, has encountered obstacles in its progress. While Steve has proven to be proficient at developing test cases, establishing a cohesive "community" for testing purposes has proven challenging. The utilization of the BetterMeans platform, intended to facilitate the project, has instead hindered its advancement. In light of these setbacks, Gavin Andresen, the project leader, is eager to move forward and plans to release a 0.7.1rc1 version in the coming days. His primary objective is to establish a structured process for QA testers to conduct sanity tests on release builds and provide feedback categorized as either "Tested/problems found" or "Tested/OK". Additionally, Gavin seeks an online platform that allows him to verify if all supported platforms have undergone testing before the final version is released. Notably, there is currently no affiliation between the Foundation and the Testing Project.In an unrelated development, the sender of the message attempted to forward a reply-all email to a list comprising over 40,000 recipients. However, their email was blocked, resulting in their expression of disappointment. They noted that they had already reached the list with enough spam for one night, but no further information regarding this incident was provided. 2012-10-03T17:30:44+00:00 + The Testing Project, which aims to create a self-organizing community for QA testing, has encountered obstacles in its progress. While Steve has proven to be proficient at developing test cases, establishing a cohesive "community" for testing purposes has proven challenging. The utilization of the BetterMeans platform, intended to facilitate the project, has instead hindered its advancement. In light of these setbacks, Gavin Andresen, the project leader, is eager to move forward and plans to release a 0.7.1rc1 version in the coming days. His primary objective is to establish a structured process for QA testers to conduct sanity tests on release builds and provide feedback categorized as either "Tested/problems found" or "Tested/OK". Additionally, Gavin seeks an online platform that allows him to verify if all supported platforms have undergone testing before the final version is released. Notably, there is currently no affiliation between the Foundation and the Testing Project.In an unrelated development, the sender of the message attempted to forward a reply-all email to a list comprising over 40,000 recipients. However, their email was blocked, resulting in their expression of disappointment. They noted that they had already reached the list with enough spam for one night, but no further information regarding this incident was provided. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Hosting-of-compiled-bitcoin-client.xml b/static/bitcoin-dev/Oct_2012/combined_Hosting-of-compiled-bitcoin-client.xml index 3605b43c0e..359031685f 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Hosting-of-compiled-bitcoin-client.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Hosting-of-compiled-bitcoin-client.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hosting of compiled bitcoin client - 2023-08-01T04:00:42.263712+00:00 + 2025-10-11T21:48:37.757731+00:00 + python-feedgen Caleb James DeLisle 2012-10-20 14:19:47+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Hosting of compiled bitcoin client - 2023-08-01T04:00:42.263712+00:00 + 2025-10-11T21:48:37.757884+00:00 - There are concerns about Sourceforge being attacked and a backdoored client being uploaded, with some people not checking signatures. Sourceforge has had vulnerabilities in the past due to their "your own website on Sourceforge" feature, leading to suggestions that Github takes security more seriously. It has been proposed to ask for free hosting from a reputable security-conscious bitcoin enthusiast, although this would create another Single Point of Failure (SPOF) in the coineverse. Additionally, Sourceforge downloads are blocked in China due to the Great Firewall, but it is easy to bypass these restrictions.In an email conversation between Mark Lister and Wladimir, the issue of Sourceforge blocking downloads in certain countries is discussed. They agree that the problem is related to trade with sanctioned countries and the Great Firewall of China. They also note that bypassing these restrictions is relatively easy.A user on Reddit argues that the issue is not cryptography itself, but rather trade with sanctioned countries. Making files available for download can be considered trade and may lead to restrictions. This highlights the complexity of the cryptography and trade restriction issue. While some advocate for strong encryption protocols to protect privacy and sensitive data, others are concerned about potential misuse. There are also concerns about the impact of trade restrictions on innovation and open access to information.The laws in question are Office of Foreign Assets Control (OFAC) sanctions, which apply to US citizens or residents. Making files available for download to sanctioned countries is considered trade. To make Bitcoin available in these places, sites and download mirrors must be hosted outside the USA by non-citizens. EU sanctions primarily focus on financial aspects and do not prevent serving data to Iran. Switzerland does not have any sanctions in effect, but datacenter space in Zurich is expensive. The SDN list of OFAC, which assumes globally unique names, has been found unconstitutional.In an email exchange, Christian Decker seeks information on the laws regarding cryptography in their project. The only known restrictions are the EAR restrictions on the export of cryptography, which do not apply to them as they only use cryptography for authentication. Enforcement attempts against open source projects have been minimal since the Bernstein vs US case. Christian also mentions the difficulty of finding a country with more permissive laws and plans to contact the EFF for advice.A member of the Bitcoin-development mailing list suggests finding a country with more permissive laws for hosting and accessing Bitcoin-related content. Another member questions the legality of restricting access at the request of the USA and suggests non-US developers evaluate their own laws. The reason for Sourceforge's restrictions should be made known. GitHub, another US-located platform, may also present similar problems.In an email exchange, Kyle Henderson expresses concerns about SourceForge restricting access to certain countries at the request of the USA. He requests clarification on the legality of this situation to protect US developers. Kyle suggests hosting the compiled client on GitHub as an alternative to Sourceforge, as it is already used as the code repository and would require minimal effort. 2012-10-20T14:19:47+00:00 + There are concerns about Sourceforge being attacked and a backdoored client being uploaded, with some people not checking signatures. Sourceforge has had vulnerabilities in the past due to their "your own website on Sourceforge" feature, leading to suggestions that Github takes security more seriously. It has been proposed to ask for free hosting from a reputable security-conscious bitcoin enthusiast, although this would create another Single Point of Failure (SPOF) in the coineverse. Additionally, Sourceforge downloads are blocked in China due to the Great Firewall, but it is easy to bypass these restrictions.In an email conversation between Mark Lister and Wladimir, the issue of Sourceforge blocking downloads in certain countries is discussed. They agree that the problem is related to trade with sanctioned countries and the Great Firewall of China. They also note that bypassing these restrictions is relatively easy.A user on Reddit argues that the issue is not cryptography itself, but rather trade with sanctioned countries. Making files available for download can be considered trade and may lead to restrictions. This highlights the complexity of the cryptography and trade restriction issue. While some advocate for strong encryption protocols to protect privacy and sensitive data, others are concerned about potential misuse. There are also concerns about the impact of trade restrictions on innovation and open access to information.The laws in question are Office of Foreign Assets Control (OFAC) sanctions, which apply to US citizens or residents. Making files available for download to sanctioned countries is considered trade. To make Bitcoin available in these places, sites and download mirrors must be hosted outside the USA by non-citizens. EU sanctions primarily focus on financial aspects and do not prevent serving data to Iran. Switzerland does not have any sanctions in effect, but datacenter space in Zurich is expensive. The SDN list of OFAC, which assumes globally unique names, has been found unconstitutional.In an email exchange, Christian Decker seeks information on the laws regarding cryptography in their project. The only known restrictions are the EAR restrictions on the export of cryptography, which do not apply to them as they only use cryptography for authentication. Enforcement attempts against open source projects have been minimal since the Bernstein vs US case. Christian also mentions the difficulty of finding a country with more permissive laws and plans to contact the EFF for advice.A member of the Bitcoin-development mailing list suggests finding a country with more permissive laws for hosting and accessing Bitcoin-related content. Another member questions the legality of restricting access at the request of the USA and suggests non-US developers evaluate their own laws. The reason for Sourceforge's restrictions should be made known. GitHub, another US-located platform, may also present similar problems.In an email exchange, Kyle Henderson expresses concerns about SourceForge restricting access to certain countries at the request of the USA. He requests clarification on the legality of this situation to protect US developers. Kyle suggests hosting the compiled client on GitHub as an alternative to Sourceforge, as it is already used as the code repository and would require minimal effort. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_On-bitcoin-testing.xml b/static/bitcoin-dev/Oct_2012/combined_On-bitcoin-testing.xml index 233159a837..7cfe66caf1 100644 --- a/static/bitcoin-dev/Oct_2012/combined_On-bitcoin-testing.xml +++ b/static/bitcoin-dev/Oct_2012/combined_On-bitcoin-testing.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On bitcoin testing - 2023-08-01T03:59:36.592911+00:00 + 2025-10-11T21:48:27.135772+00:00 + python-feedgen Gregory Maxwell 2012-10-10 00:03:52+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - On bitcoin testing - 2023-08-01T03:59:36.592911+00:00 + 2025-10-11T21:48:27.135918+00:00 - Jeff Garzik suggests that in order to improve software testing for Bitcoin, data-driven tests should be written that are compatible with clients other than the reference client. He also recommends embedding tests in the testnet3 chain for better testing. The discussion then turns to the issue of confirmation bias in software testing, which leads to over-testing success cases and under-testing failure cases. It is emphasized that failure cases are critical for testing implementation compatibility and preventing network splits.To ensure comprehensive testing, it is essential to have a diverse collection of testers who can think outside the box and test corner cases. Developers should use multiple approaches rather than relying on a single one. Combining different mechanisms of software testing enhances the detection of issues. For example, using valgrind significantly improves almost all testing by lowering the threshold of issue detection. Automatable testing such as coded data-driven, unit, and fuzz testing works well with diverse compilation.However, it is noted that valgrind is not available on Windows. Dr. Memory may be an alternative, or ASAN could be ported to GCC to enable mingw ASAN builds. Arklan expresses gratitude to Jeff Garzik for sharing his response on software testing efforts for Bitcoin. Jeff suggests various types of testing that can be helpful for the community, including "it works" testing, major features testing, stress and fuzz testing, regression testing, unit function testing, full peer automated testing, and data-driven tests. He encourages users to download and run the latest version of Bitcoin software, report any problems or success, and contribute to testing and test-case writing at any level they are comfortable with.Arklan plans to set up a virtual machine to start testing himself and asks Steve for updates on the test cases he set up. The context concludes with two quotes by Arklan about facing fear and leaving the world with a bang.In summary, Jeff Garzik suggests using data-driven tests that are compatible with clients other than the reference client and embedding tests in the testnet3 chain for better testing. Confirmation bias in software testing is discussed, highlighting the importance of testing failure cases for implementation compatibility and network split prevention. It is advised to have a diverse collection of testers who can think outside the box and test corner cases. Using multiple approaches to software testing enhances issue detection, such as incorporating valgrind or alternatives like Dr. Memory or porting ASAN to GCC for mingw ASAN builds.Arklan expresses gratitude for Jeff Garzik's suggestions and plans to set up a virtual machine for testing. The community is encouraged to download and run the latest version of Bitcoin software, report any issues or success, and contribute to testing and test-case writing at any level they are comfortable with. The context ends with two quotes by Arklan about facing fear and leaving a lasting impact. 2012-10-10T00:03:52+00:00 + Jeff Garzik suggests that in order to improve software testing for Bitcoin, data-driven tests should be written that are compatible with clients other than the reference client. He also recommends embedding tests in the testnet3 chain for better testing. The discussion then turns to the issue of confirmation bias in software testing, which leads to over-testing success cases and under-testing failure cases. It is emphasized that failure cases are critical for testing implementation compatibility and preventing network splits.To ensure comprehensive testing, it is essential to have a diverse collection of testers who can think outside the box and test corner cases. Developers should use multiple approaches rather than relying on a single one. Combining different mechanisms of software testing enhances the detection of issues. For example, using valgrind significantly improves almost all testing by lowering the threshold of issue detection. Automatable testing such as coded data-driven, unit, and fuzz testing works well with diverse compilation.However, it is noted that valgrind is not available on Windows. Dr. Memory may be an alternative, or ASAN could be ported to GCC to enable mingw ASAN builds. Arklan expresses gratitude to Jeff Garzik for sharing his response on software testing efforts for Bitcoin. Jeff suggests various types of testing that can be helpful for the community, including "it works" testing, major features testing, stress and fuzz testing, regression testing, unit function testing, full peer automated testing, and data-driven tests. He encourages users to download and run the latest version of Bitcoin software, report any problems or success, and contribute to testing and test-case writing at any level they are comfortable with.Arklan plans to set up a virtual machine to start testing himself and asks Steve for updates on the test cases he set up. The context concludes with two quotes by Arklan about facing fear and leaving the world with a bang.In summary, Jeff Garzik suggests using data-driven tests that are compatible with clients other than the reference client and embedding tests in the testnet3 chain for better testing. Confirmation bias in software testing is discussed, highlighting the importance of testing failure cases for implementation compatibility and network split prevention. It is advised to have a diverse collection of testers who can think outside the box and test corner cases. Using multiple approaches to software testing enhances issue detection, such as incorporating valgrind or alternatives like Dr. Memory or porting ASAN to GCC for mingw ASAN builds.Arklan expresses gratitude for Jeff Garzik's suggestions and plans to set up a virtual machine for testing. The community is encouraged to download and run the latest version of Bitcoin software, report any issues or success, and contribute to testing and test-case writing at any level they are comfortable with. The context ends with two quotes by Arklan about facing fear and leaving a lasting impact. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Payment-protocol-thoughts.xml b/static/bitcoin-dev/Oct_2012/combined_Payment-protocol-thoughts.xml index f8897e7e0d..7669e74ae9 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Payment-protocol-thoughts.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Payment-protocol-thoughts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment protocol thoughts - 2023-08-01T03:57:41.236430+00:00 + 2025-10-11T21:48:33.511052+00:00 + python-feedgen Gregory Maxwell 2012-10-02 22:52:23+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Payment protocol thoughts - 2023-08-01T03:57:41.236430+00:00 + 2025-10-11T21:48:33.511225+00:00 - In an email exchange from 2012, Mike Hearn suggested using the SSL identity of the server in a protocol as a solution to a problem, but noted that further measures would be needed. The idea of signed invoices and blockchain transactions was also discussed, with the caveat that dispute mediation should be in place. The importance of proving faultlessness to prospective customers was highlighted, even without formal direct remedy.The author suggests brainstorming different feature ideas for a robust design. Bitcoin addresses alone are insecure against man-in-the-middle attacks, so embedding a signature and cert chain into the invoice could help solve this issue. Allowing multiple sigs/cert chains keeps the design open to cases where SSL may not be appropriate. Having a receipt that proves following the payee's instructions after payment is important. A signed invoice and blockchain transactions can provide this, but dispute mediation should also be in place. The author proposes a protocol for gathering signatures from multiple devices to enhance the basic payment protocol.In another email exchange, the issue of double-spending was brought up. It was mentioned that approximately 3-5% of initial Bitcoin Foundation members had double-spent. Clarification was sought regarding whether this meant paying twice or sending the same coins elsewhere after sending them to CoinLab. It was confirmed that it meant "sent twice" but no double-spends were known.The Bitcoin Foundation disclosed that 3-5% of its initial members double-spent due to a UI issue in web wallets. Gavin Andresen agreed on the need for a payment protocol to address issues such as securing bitcoin addresses and providing receipts. He suggested including refund information with payments to handle overpayments efficiently. A protocol for gathering signatures from multiple devices was proposed to enhance financial controls. However, critical problems should be solved first before addressing other issues.A payment protocol is needed to solve current Bitcoin user problems. Critical issues include the insecurity of Bitcoin addresses against man-in-the-middle attacks, which can be addressed through a payment protocol ensuring donation link authenticity. Receipts should be issued after sending payments. A protocol for gathering signatures from multiple devices is also suggested. Including refund information with payments can handle overpayments and refunds efficiently. Other features can wait for later protocol versions.The context discusses the requirements for a payment protocol that offers better privacy and security. Moving towards "uploading transactions" instead of "sending BTC to an address" is proposed. This would balance hot and cold wallets, enable multi-sig scripts, and offer better privacy by unlinking separate transactions. Other desirable features include SSL certificates, optional expiry times, messaging options, and more. Protocol buffers are suggested over JSON for easier code implementation.Overall, the context highlights various discussions and proposals related to improving the security, privacy, and functionality of Bitcoin payments through the implementation of a robust payment protocol. 2012-10-02T22:52:23+00:00 + In an email exchange from 2012, Mike Hearn suggested using the SSL identity of the server in a protocol as a solution to a problem, but noted that further measures would be needed. The idea of signed invoices and blockchain transactions was also discussed, with the caveat that dispute mediation should be in place. The importance of proving faultlessness to prospective customers was highlighted, even without formal direct remedy.The author suggests brainstorming different feature ideas for a robust design. Bitcoin addresses alone are insecure against man-in-the-middle attacks, so embedding a signature and cert chain into the invoice could help solve this issue. Allowing multiple sigs/cert chains keeps the design open to cases where SSL may not be appropriate. Having a receipt that proves following the payee's instructions after payment is important. A signed invoice and blockchain transactions can provide this, but dispute mediation should also be in place. The author proposes a protocol for gathering signatures from multiple devices to enhance the basic payment protocol.In another email exchange, the issue of double-spending was brought up. It was mentioned that approximately 3-5% of initial Bitcoin Foundation members had double-spent. Clarification was sought regarding whether this meant paying twice or sending the same coins elsewhere after sending them to CoinLab. It was confirmed that it meant "sent twice" but no double-spends were known.The Bitcoin Foundation disclosed that 3-5% of its initial members double-spent due to a UI issue in web wallets. Gavin Andresen agreed on the need for a payment protocol to address issues such as securing bitcoin addresses and providing receipts. He suggested including refund information with payments to handle overpayments efficiently. A protocol for gathering signatures from multiple devices was proposed to enhance financial controls. However, critical problems should be solved first before addressing other issues.A payment protocol is needed to solve current Bitcoin user problems. Critical issues include the insecurity of Bitcoin addresses against man-in-the-middle attacks, which can be addressed through a payment protocol ensuring donation link authenticity. Receipts should be issued after sending payments. A protocol for gathering signatures from multiple devices is also suggested. Including refund information with payments can handle overpayments and refunds efficiently. Other features can wait for later protocol versions.The context discusses the requirements for a payment protocol that offers better privacy and security. Moving towards "uploading transactions" instead of "sending BTC to an address" is proposed. This would balance hot and cold wallets, enable multi-sig scripts, and offer better privacy by unlinking separate transactions. Other desirable features include SSL certificates, optional expiry times, messaging options, and more. Protocol buffers are suggested over JSON for easier code implementation.Overall, the context highlights various discussions and proposals related to improving the security, privacy, and functionality of Bitcoin payments through the implementation of a robust payment protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Post-0-7-1-tree-freeze-for-ultraprune.xml b/static/bitcoin-dev/Oct_2012/combined_Post-0-7-1-tree-freeze-for-ultraprune.xml index 727c0ada42..58fd78f34b 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Post-0-7-1-tree-freeze-for-ultraprune.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Post-0-7-1-tree-freeze-for-ultraprune.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Post-0.7.1 tree freeze for ultraprune - 2023-08-01T03:59:51.046638+00:00 + 2025-10-11T21:48:35.635055+00:00 + python-feedgen Wladimir 2012-10-11 11:12:15+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Post-0.7.1 tree freeze for ultraprune - 2023-08-01T03:59:51.046638+00:00 + 2025-10-11T21:48:35.635179+00:00 - In October 2012, Jeff Garzik proposed freezing the tree after the release of version 0.7.1 until ultraprune was either added or rejected. Wladimir agreed with this proposal and had already merged some small changes that were approved for post-0.7.1. However, Wladimir later realized that 0.7.1 was still in rc (release candidate) and not yet final. He had merged a few changes from different contributors, but he didn't believe any of these changes would cause issues in rc2. If there were any problems, a branch would be created for 0.7.x and master would become the 0.8.x branch.On October 10, 2012, Jeff Garzik proposed to freeze the tree after the 0.7.1 release until ultraprune was pulled in or rejected. Wladimir agreed and mentioned that he had already pulled all the small changes that were acknowledged for post-0.7.1. Therefore, the freeze could begin.The proposal suggests freezing the tree after the 0.7.1 release until ultraprune is either pulled or rejected. Critical bug fixes and reasonable exceptions would still be allowed. It is not necessary for ultraprune to be perfect before being pulled, as further improvements can be made during the 0.8 development phase. The main challenge is getting everyone to acknowledge and agree on the design and direction of the ultraprune branch, particularly Gavin. High-level design approvals are more important than detailed code reviews, as any code mistakes can be fixed during the 0.8 development once the correct design is agreed upon. The actual code errors and potential issues will only be discovered through extensive testing. Jeff Garzik has already given his approval for the design. 2012-10-11T11:12:15+00:00 + In October 2012, Jeff Garzik proposed freezing the tree after the release of version 0.7.1 until ultraprune was either added or rejected. Wladimir agreed with this proposal and had already merged some small changes that were approved for post-0.7.1. However, Wladimir later realized that 0.7.1 was still in rc (release candidate) and not yet final. He had merged a few changes from different contributors, but he didn't believe any of these changes would cause issues in rc2. If there were any problems, a branch would be created for 0.7.x and master would become the 0.8.x branch.On October 10, 2012, Jeff Garzik proposed to freeze the tree after the 0.7.1 release until ultraprune was pulled in or rejected. Wladimir agreed and mentioned that he had already pulled all the small changes that were acknowledged for post-0.7.1. Therefore, the freeze could begin.The proposal suggests freezing the tree after the 0.7.1 release until ultraprune is either pulled or rejected. Critical bug fixes and reasonable exceptions would still be allowed. It is not necessary for ultraprune to be perfect before being pulled, as further improvements can be made during the 0.8 development phase. The main challenge is getting everyone to acknowledge and agree on the design and direction of the ultraprune branch, particularly Gavin. High-level design approvals are more important than detailed code reviews, as any code mistakes can be fixed during the 0.8 development once the correct design is agreed upon. The actual code errors and potential issues will only be discovered through extensive testing. Jeff Garzik has already given his approval for the design. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Public-key-and-signature-malleability.xml b/static/bitcoin-dev/Oct_2012/combined_Public-key-and-signature-malleability.xml index ffb949bb83..8214383100 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Public-key-and-signature-malleability.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Public-key-and-signature-malleability.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Public key and signature malleability - 2023-08-01T04:00:58.714182+00:00 + 2025-10-11T21:48:20.757374+00:00 + python-feedgen Stefan Thomas 2012-10-21 18:48:15+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Public key and signature malleability - 2023-08-01T04:00:58.714182+00:00 + 2025-10-11T21:48:20.757545+00:00 - In the context provided, Gavin Andresen expresses his support for redefining the transaction validity rules in the Bitcoin reference implementation. He believes that it is important to allow people the opportunity to fix their software and asks if there are any objections from other transaction-validating implementations. This suggests that there may be some issues with the current transaction validation process that need to be addressed.Pieter Wuille proposed implementing strict rules to define the Bitcoin network and eliminate dependency on OpenSSL's implementation. This proposal was supported by Wladimir, who expressed concerns about changes in OpenSSL API leading to unexpected behavior and forks. The goal is to make the protocol as well-defined as possible and prevent unexpected outcomes and potential security or denial-of-service problems.Pieter Wuille also suggested implementing rules to prevent malleability in Bitcoin transactions. The idea was strongly supported because malleability has caused unexpected outcomes, and there may be additional security or denial-of-service problems associated with allowing it. The proposal suggests enabling the rules as a check similar to IsStandard(), making it difficult for non-complying transactions to get into blocks but still allowing them to be accepted when they aren't standard. Once no significant amount of non-standard transactions are seen, a BIP can be written, and enforcement of the rules can begin as a network rule.To further address the issue of malleability, Pieter proposed specific rules for public keys and signatures. Sergio Lerner discovered that taking the secp256k1-field-size complement of the S value in the signature does not invalidate it. To prevent this, requiring the lowest bit of the S value to always be even is suggested. While no client currently enforces this, it is considered easy to implement and would make the Bitcoin network rules more well-defined and prevent malleability attacks.Overall, the context indicates a need for more precise transaction validity rules in the Bitcoin system. Gavin Andresen supports changing the reference implementation to achieve this. Pieter Wuille's proposals aim to make the Bitcoin network rules more well-defined, eliminate dependencies on OpenSSL, and prevent malleability attacks. 2012-10-21T18:48:15+00:00 + In the context provided, Gavin Andresen expresses his support for redefining the transaction validity rules in the Bitcoin reference implementation. He believes that it is important to allow people the opportunity to fix their software and asks if there are any objections from other transaction-validating implementations. This suggests that there may be some issues with the current transaction validation process that need to be addressed.Pieter Wuille proposed implementing strict rules to define the Bitcoin network and eliminate dependency on OpenSSL's implementation. This proposal was supported by Wladimir, who expressed concerns about changes in OpenSSL API leading to unexpected behavior and forks. The goal is to make the protocol as well-defined as possible and prevent unexpected outcomes and potential security or denial-of-service problems.Pieter Wuille also suggested implementing rules to prevent malleability in Bitcoin transactions. The idea was strongly supported because malleability has caused unexpected outcomes, and there may be additional security or denial-of-service problems associated with allowing it. The proposal suggests enabling the rules as a check similar to IsStandard(), making it difficult for non-complying transactions to get into blocks but still allowing them to be accepted when they aren't standard. Once no significant amount of non-standard transactions are seen, a BIP can be written, and enforcement of the rules can begin as a network rule.To further address the issue of malleability, Pieter proposed specific rules for public keys and signatures. Sergio Lerner discovered that taking the secp256k1-field-size complement of the S value in the signature does not invalidate it. To prevent this, requiring the lowest bit of the S value to always be even is suggested. While no client currently enforces this, it is considered easy to implement and would make the Bitcoin network rules more well-defined and prevent malleability attacks.Overall, the context indicates a need for more precise transaction validity rules in the Bitcoin system. Gavin Andresen supports changing the reference implementation to achieve this. Pieter Wuille's proposals aim to make the Bitcoin network rules more well-defined, eliminate dependencies on OpenSSL, and prevent malleability attacks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_Ultraprune-merged-in-mainline.xml b/static/bitcoin-dev/Oct_2012/combined_Ultraprune-merged-in-mainline.xml index 8077baca49..6d0b4b2357 100644 --- a/static/bitcoin-dev/Oct_2012/combined_Ultraprune-merged-in-mainline.xml +++ b/static/bitcoin-dev/Oct_2012/combined_Ultraprune-merged-in-mainline.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Ultraprune merged in mainline - 2023-08-01T04:01:12.571766+00:00 + 2025-10-11T21:48:42.008791+00:00 + python-feedgen Arklan Uth Oslin 2012-10-21 01:38:23+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Ultraprune merged in mainline - 2023-08-01T04:01:12.571766+00:00 + 2025-10-11T21:48:42.008924+00:00 - Pieter Wuille, a Bitcoin Core developer, has announced the merging of his "ultraprune" branch into mainline, which involves significant changes to the blockchain validation process. The ultraprune feature aims to improve performance and reduce the working set size for validation by using an ultra-pruned copy of the blockchain instead of a transaction index. This copy only includes unspent transaction outputs in a custom compact format while still keeping all blocks for serving other nodes, rescanning, and reorganizations.Several changes have been made as part of this merge. The blk000?.dat files have been renamed to blocks/blk000??.dat with a maximum size of 128 MiB and pre-allocated per 16 MiB. The previous Berkeley DB blkindex.dat has been replaced by a LevelDB directory called blktree/, which only contains a block index without a transaction index. Additionally, a new LevelDB directory called coins/ has been added, which contains data about the current unspent transaction output set. Undo data for blocks is now stored in new files called blocks/rev000??.dat, which is necessary for reorganization.Two new RPC calls, gettxout and gettxoutsetinfo, have also been introduced. These changes are expected to significantly improve performance, as LevelDB handles slow I/O more efficiently than Berkeley DB, and the working set size for validation is much smaller.Wuille believes that these changes are a step towards preparing for future pruning and enabling the separation between validation nodes and archive nodes. However, he acknowledges that implementing these changes may have profound effects on the network and suggests that further discussion is needed before implementation. Unfortunately, no specific link or instructions were provided for Arklan to access the project being tested. 2012-10-21T01:38:23+00:00 + Pieter Wuille, a Bitcoin Core developer, has announced the merging of his "ultraprune" branch into mainline, which involves significant changes to the blockchain validation process. The ultraprune feature aims to improve performance and reduce the working set size for validation by using an ultra-pruned copy of the blockchain instead of a transaction index. This copy only includes unspent transaction outputs in a custom compact format while still keeping all blocks for serving other nodes, rescanning, and reorganizations.Several changes have been made as part of this merge. The blk000?.dat files have been renamed to blocks/blk000??.dat with a maximum size of 128 MiB and pre-allocated per 16 MiB. The previous Berkeley DB blkindex.dat has been replaced by a LevelDB directory called blktree/, which only contains a block index without a transaction index. Additionally, a new LevelDB directory called coins/ has been added, which contains data about the current unspent transaction output set. Undo data for blocks is now stored in new files called blocks/rev000??.dat, which is necessary for reorganization.Two new RPC calls, gettxout and gettxoutsetinfo, have also been introduced. These changes are expected to significantly improve performance, as LevelDB handles slow I/O more efficiently than Berkeley DB, and the working set size for validation is much smaller.Wuille believes that these changes are a step towards preparing for future pruning and enabling the separation between validation nodes and archive nodes. However, he acknowledges that implementing these changes may have profound effects on the network and suggests that further discussion is needed before implementation. Unfortunately, no specific link or instructions were provided for Arklan to access the project being tested. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2012/combined_performance-testing-for-bitcoin.xml b/static/bitcoin-dev/Oct_2012/combined_performance-testing-for-bitcoin.xml index 80e3b4210f..da064bd187 100644 --- a/static/bitcoin-dev/Oct_2012/combined_performance-testing-for-bitcoin.xml +++ b/static/bitcoin-dev/Oct_2012/combined_performance-testing-for-bitcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - performance testing for bitcoin - 2023-08-01T03:58:09.986748+00:00 + 2025-10-11T21:48:29.258729+00:00 + python-feedgen Ian Miers 2012-10-04 16:31:11+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - performance testing for bitcoin - 2023-08-01T03:58:09.987714+00:00 + 2025-10-11T21:48:29.258863+00:00 - In a discussion on the Bitcoin-development mailing list in 2012, Ian Miers sought advice on obtaining performance numbers for modifications to Bitcoin. He was primarily concerned with script evaluation performance and needed to test how adding new instruction types would affect performance. To ensure accuracy, simulated traffic that approximated real-world traffic was required. Jeff Garzik responded by suggesting that specific aspects of blockchain performance could be measured by importing blocks via -loadblock=FILE. However, he noted that other performance measurements, such as block relay speed through the network, were not easily measured. Joel Joonatan Kaartinen added that benchmarking worst-case scenarios should also be considered to avoid creating a DoS vulnerability. The discussion concluded with a suggestion to deploy New Relic APM for application performance management.In an email exchange between Ian Miers and Jeff Garzik, Ian inquired about the best way to obtain performance numbers for Bitcoin modifications. His primary focus was on script evaluation performance and the addition of new instruction types. He wanted to test the impact on performance by interspersing transactions with the new instructions alongside existing ones. It was important for his simulated traffic to closely resemble real-world traffic to achieve accurate results. Jeff advised being specific about the aspect of performance being measured, as "performance" is a broad term. He suggested importing blocks via -loadblock=FILE to measure certain aspects of blockchain performance but acknowledged that measuring block relay speed through the network posed challenges. Ian also asked if there were any benchmarking or instrumentation options in bitcoind, but the email exchange did not provide further information on this topic.The context revolves around Ian Miers' search for methods to obtain performance numbers for Bitcoin modifications. He aimed to improve script evaluation performance and experiment with new instruction types. Simulated traffic resembling real-world traffic was necessary for accurate testing. Jeff Garzik emphasized the importance of specifying the performance aspect being measured and suggested using -loadblock=FILE to measure certain blockchain performance aspects. However, measuring block relay speed through the network proved to be more challenging. The discussion also highlighted the need to benchmark worst-case scenarios to avoid DoS vulnerabilities. There was a mention of deploying New Relic APM for application performance management. Additionally, there was a query about speeding up the performance measurement process by replaying real Bitcoin transactions on a test-net-in-a-box network with reduced hash difficulty, but it remains unclear whether this approach was pursued or further explored. 2012-10-04T16:31:11+00:00 + In a discussion on the Bitcoin-development mailing list in 2012, Ian Miers sought advice on obtaining performance numbers for modifications to Bitcoin. He was primarily concerned with script evaluation performance and needed to test how adding new instruction types would affect performance. To ensure accuracy, simulated traffic that approximated real-world traffic was required. Jeff Garzik responded by suggesting that specific aspects of blockchain performance could be measured by importing blocks via -loadblock=FILE. However, he noted that other performance measurements, such as block relay speed through the network, were not easily measured. Joel Joonatan Kaartinen added that benchmarking worst-case scenarios should also be considered to avoid creating a DoS vulnerability. The discussion concluded with a suggestion to deploy New Relic APM for application performance management.In an email exchange between Ian Miers and Jeff Garzik, Ian inquired about the best way to obtain performance numbers for Bitcoin modifications. His primary focus was on script evaluation performance and the addition of new instruction types. He wanted to test the impact on performance by interspersing transactions with the new instructions alongside existing ones. It was important for his simulated traffic to closely resemble real-world traffic to achieve accurate results. Jeff advised being specific about the aspect of performance being measured, as "performance" is a broad term. He suggested importing blocks via -loadblock=FILE to measure certain aspects of blockchain performance but acknowledged that measuring block relay speed through the network posed challenges. Ian also asked if there were any benchmarking or instrumentation options in bitcoind, but the email exchange did not provide further information on this topic.The context revolves around Ian Miers' search for methods to obtain performance numbers for Bitcoin modifications. He aimed to improve script evaluation performance and experiment with new instruction types. Simulated traffic resembling real-world traffic was necessary for accurate testing. Jeff Garzik emphasized the importance of specifying the performance aspect being measured and suggested using -loadblock=FILE to measure certain blockchain performance aspects. However, measuring block relay speed through the network proved to be more challenging. The discussion also highlighted the need to benchmark worst-case scenarios to avoid DoS vulnerabilities. There was a mention of deploying New Relic APM for application performance management. Additionally, there was a query about speeding up the performance measurement process by replaying real Bitcoin transactions on a test-net-in-a-box network with reduced hash difficulty, but it remains unclear whether this approach was pursued or further explored. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_-Bitcoin-codebase-is-actually-really-simple-and-readable-.xml b/static/bitcoin-dev/Oct_2013/combined_-Bitcoin-codebase-is-actually-really-simple-and-readable-.xml index d655b940df..ce55d883e5 100644 --- a/static/bitcoin-dev/Oct_2013/combined_-Bitcoin-codebase-is-actually-really-simple-and-readable-.xml +++ b/static/bitcoin-dev/Oct_2013/combined_-Bitcoin-codebase-is-actually-really-simple-and-readable-.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - "Bitcoin codebase is actually really simple and readable." - 2023-08-01T06:13:50.783300+00:00 + Combined summary - "Bitcoin codebase is actually really simple and readable." + 2025-10-11T21:41:49.563278+00:00 + python-feedgen Peter Todd 2013-10-23 19:29:40+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 - Combined summary - "Bitcoin codebase is actually really simple and readable." - 2023-08-01T06:13:50.783300+00:00 + Combined summary - "Bitcoin codebase is actually really simple and readable." + 2025-10-11T21:41:49.563484+00:00 - The Bitcoin codebase, written in C++, has been described as simple and readable. However, understanding the implications of the code is anything but simple. The fear that making changes to the code could have catastrophic consequences has hindered efforts to improve documentation and find replacements for obscure names of important items. The difficulty with C++ lies in its design, which makes it hard to achieve readability. Despite this, the reference client's code is considered to be simpler and easier to read than OpenSSL's source-code.Recognizing the need for newcomers to understand the complexities of the cryptocurrency, a developer has proposed the creation of a well-written RFC (Request for Comments) document. Currently, much of the available information about Bitcoin is incomplete and difficult to decipher for those without prior knowledge. However, there are concerns about writing such an RFC due to the consensus nature of the currency.While the code itself may be simple and readable, expressing ideas within the code is challenging due to the constraints of C++. The intentional writing of code for others' understanding becomes particularly difficult when things are designed to be hidden. As a result, efforts to review changes for potential exploits require significant time and effort.In conclusion, while the Bitcoin codebase may appear simple and readable, the implications of the code are complex and difficult to grasp. There is a recognized need for better documentation and resources to aid newcomers in understanding the intricacies of the cryptocurrency. However, the challenges posed by the consensus nature of Bitcoin and the limitations of the C++ language make it difficult to create a well-written RFC document. 2013-10-23T19:29:40+00:00 + The Bitcoin codebase, written in C++, has been described as simple and readable. However, understanding the implications of the code is anything but simple. The fear that making changes to the code could have catastrophic consequences has hindered efforts to improve documentation and find replacements for obscure names of important items. The difficulty with C++ lies in its design, which makes it hard to achieve readability. Despite this, the reference client's code is considered to be simpler and easier to read than OpenSSL's source-code.Recognizing the need for newcomers to understand the complexities of the cryptocurrency, a developer has proposed the creation of a well-written RFC (Request for Comments) document. Currently, much of the available information about Bitcoin is incomplete and difficult to decipher for those without prior knowledge. However, there are concerns about writing such an RFC due to the consensus nature of the currency.While the code itself may be simple and readable, expressing ideas within the code is challenging due to the constraints of C++. The intentional writing of code for others' understanding becomes particularly difficult when things are designed to be hidden. As a result, efforts to review changes for potential exploits require significant time and effort.In conclusion, while the Bitcoin codebase may appear simple and readable, the implications of the code are complex and difficult to grasp. There is a recognized need for better documentation and resources to aid newcomers in understanding the intricacies of the cryptocurrency. However, the challenges posed by the consensus nature of Bitcoin and the limitations of the C++ language make it difficult to create a well-written RFC document. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_0-8-5-with-libsecp256k1.xml b/static/bitcoin-dev/Oct_2013/combined_0-8-5-with-libsecp256k1.xml index d1f78086f3..092f0ee66d 100644 --- a/static/bitcoin-dev/Oct_2013/combined_0-8-5-with-libsecp256k1.xml +++ b/static/bitcoin-dev/Oct_2013/combined_0-8-5-with-libsecp256k1.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 0.8.5 with libsecp256k1 - 2023-08-01T05:59:05.400468+00:00 + 2025-10-11T21:41:43.188597+00:00 + python-feedgen Pieter Wuille 2013-10-11 11:41:41+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - 0.8.5 with libsecp256k1 - 2023-08-01T05:59:05.400468+00:00 + 2025-10-11T21:41:43.188757+00:00 - On October 10, 2013, Mike Hearn expressed his interest in making a library usable behind a command line flag or config setting. The current plan is to provide a compile-time flag that enables the library while disabling the wallet and mining RPCs. This would create a safe state for test builds. The main concern at the time was malleability issues, but it was suggested that OpenSSL could be used to parse the signature into components while libsecp256k1 verifies them. It is worth noting that libsecp256k1 supports every signature that OpenSSL supports. Another potential issue could arise if a majority of the hash power ran on it. However, with recent relaying nodes enforcing canonical encodings, a softfork could be scheduled to require them inside blocks.Apart from malleability issues, there might be exploitable mistakes in the crypto code. While there are unit tests, errors are more likely to occur in edge cases that are not covered by randomized tests. Reviewing the code would be the best way to catch these errors. Pieter, in particular, welcomed people to look at the code for comments and suggestions.Warren Togami Jr. announced on the same day that a branch of Bitcoin 0.8.5 with sipa's secp256k1 had been created. Litecoin had already been using secp256k1 for several months. The purpose of this branch was to make it work with the old 0.8 makefiles, although there were no plans for merging it into production code. Cfields was working on autotoolizing it as a prerequisite before inclusion into bitcoin master, where it would be an option disabled by default. An untested win32 gitian build was available but not recommended for production wallet or mining uses.In response to this announcement, someone in #bitcoin-dev requested Bitcoin 0.8.5 with sipa's secp256k1. The library was optimized for elliptic curve digital signature algorithm (ECDSA) and significantly faster than OpenSSL. The main concern at the time was still the malleability issues. It was suggested that OpenSSL could be used to parse the signature into components, which libsecp256k1 would then verify.Lastly, Warren Togami Jr. shared a link to sipa's secp256k1 on the Bitcoin-dev mailing list. He highlighted that Litecoin had been using secp256k1 for several months already. Meanwhile, October webinars were announced, offering free Intel webinars to help accelerate application performance. These webinars covered topics such as MPI, OpenMP, advanced profiling, and more, with an emphasis on getting the most from the latest Intel processors and coprocessors. 2013-10-11T11:41:41+00:00 + On October 10, 2013, Mike Hearn expressed his interest in making a library usable behind a command line flag or config setting. The current plan is to provide a compile-time flag that enables the library while disabling the wallet and mining RPCs. This would create a safe state for test builds. The main concern at the time was malleability issues, but it was suggested that OpenSSL could be used to parse the signature into components while libsecp256k1 verifies them. It is worth noting that libsecp256k1 supports every signature that OpenSSL supports. Another potential issue could arise if a majority of the hash power ran on it. However, with recent relaying nodes enforcing canonical encodings, a softfork could be scheduled to require them inside blocks.Apart from malleability issues, there might be exploitable mistakes in the crypto code. While there are unit tests, errors are more likely to occur in edge cases that are not covered by randomized tests. Reviewing the code would be the best way to catch these errors. Pieter, in particular, welcomed people to look at the code for comments and suggestions.Warren Togami Jr. announced on the same day that a branch of Bitcoin 0.8.5 with sipa's secp256k1 had been created. Litecoin had already been using secp256k1 for several months. The purpose of this branch was to make it work with the old 0.8 makefiles, although there were no plans for merging it into production code. Cfields was working on autotoolizing it as a prerequisite before inclusion into bitcoin master, where it would be an option disabled by default. An untested win32 gitian build was available but not recommended for production wallet or mining uses.In response to this announcement, someone in #bitcoin-dev requested Bitcoin 0.8.5 with sipa's secp256k1. The library was optimized for elliptic curve digital signature algorithm (ECDSA) and significantly faster than OpenSSL. The main concern at the time was still the malleability issues. It was suggested that OpenSSL could be used to parse the signature into components, which libsecp256k1 would then verify.Lastly, Warren Togami Jr. shared a link to sipa's secp256k1 on the Bitcoin-dev mailing list. He highlighted that Litecoin had been using secp256k1 for several months already. Meanwhile, October webinars were announced, offering free Intel webinars to help accelerate application performance. These webinars covered topics such as MPI, OpenMP, advanced profiling, and more, with an emphasis on getting the most from the latest Intel processors and coprocessors. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_A-critique-of-bitcoin-open-source-community.xml b/static/bitcoin-dev/Oct_2013/combined_A-critique-of-bitcoin-open-source-community.xml index 9148d0c496..578d4a1aba 100644 --- a/static/bitcoin-dev/Oct_2013/combined_A-critique-of-bitcoin-open-source-community.xml +++ b/static/bitcoin-dev/Oct_2013/combined_A-critique-of-bitcoin-open-source-community.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - A critique of bitcoin open source community - 2023-08-01T06:00:06.166160+00:00 + 2025-10-11T21:41:28.324587+00:00 + python-feedgen Jorge Timón 2013-10-21 10:21:27+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - A critique of bitcoin open source community - 2023-08-01T06:00:06.166160+00:00 + 2025-10-11T21:41:28.324753+00:00 - Melvin Carvalho, a follower of free/libre and open-source software (FLOSS) projects, expressed admiration for the Bitcoin Improvement Proposal (BIP) process. He believes that this process is agile and strikes a balance between necessary features and documentation, which will help maintain the momentum of Bitcoin in the short to medium term. The BIP process is also used in other systems such as Python. Other enhancement proposal processes similar to BIP are used in XMPP and BitTorrent.In an email conversation, Jean-Paul Kogelman suggests organizing BIPs into subdirectories that map onto the status of the BIP. Martin Sustrik asks if it has been considered to do this via IETF, but notes that the process can take many years and there may be costs involved. However, he praises the BIP process as an agile process that strikes a balance between needed features and documentation, and believes it will continue to drive Bitcoin’s momentum in the short to medium term.In a discussion thread, Jean-Paul Kogelman proposes organizing a list into subdirectories that correspond to the status of BIP 1. Martin suggests considering using IETF (Internet Engineering Task Force) for this process, noting their extensive experience in handling over 7000 RFCs through a hardened process developed over 40 years.Jean-Paul Kogelman suggests organizing BIPs into subdirectories based on their status- Accepted, Active, Draft, Deferred, Final, Rejected, Replaced, or Withdrawn. Martin then asks if the process could be done via IETF, which has over 40 years of experience and 7000+ RFCs.Peter Todd suggests making a GitHub repository for Bitcoin Improvement Proposals (BIPs) to make it easier to archive and update them. Todd creates a GitHub repository and copies the exact text of the BIP from the bitcoin.it wiki using MediaWiki support. Jeff Garzik agrees with Todd's proposal and nominates him to do the conversion.Wladimir van der Laan expresses frustration with the unfriendly behavior of some Bitcoin developers on forums. He cautions against sending people to these forums and emphasizes that they are not endorsed by the developer community. However, he notes that the core developer community is relatively small and reviewing and testing proposals can take time.On October 19, 2013, Jean-Paul Kogelman asks Luke Dashjr about the process for obtaining a BIP number. Dashjr directs Kogelman to BIP 1 which outlines the proposal process.Mitar shares an interesting read from the Berkeley School of Information about Bitcoin's development community. The conversation touches on newcomer experience and potential issues with communication and transparency. Some pull requests were left unaddressed for long periods of time due to shortages of active review and prioritization of safety-critical changes.In an email conversation, Mitar suggests that the Bitcoin community could benefit from adopting a code of conduct similar to Ubuntu's. The Ubuntu Code of Conduct v2.0 emphasizes collaboration, respect, taking responsibility for actions and decisions, and valuing diversity.The provided links lead to an article on "Open Collaboration and Peer Production" from the University of California, Berkeley. The author discusses the principles behind successful open collaboration efforts and identifies key factors that contribute to their success. The link to Mitar's personal website showcases his work and interests in various areas, including software development and blockchain technology. 2013-10-21T10:21:27+00:00 + Melvin Carvalho, a follower of free/libre and open-source software (FLOSS) projects, expressed admiration for the Bitcoin Improvement Proposal (BIP) process. He believes that this process is agile and strikes a balance between necessary features and documentation, which will help maintain the momentum of Bitcoin in the short to medium term. The BIP process is also used in other systems such as Python. Other enhancement proposal processes similar to BIP are used in XMPP and BitTorrent.In an email conversation, Jean-Paul Kogelman suggests organizing BIPs into subdirectories that map onto the status of the BIP. Martin Sustrik asks if it has been considered to do this via IETF, but notes that the process can take many years and there may be costs involved. However, he praises the BIP process as an agile process that strikes a balance between needed features and documentation, and believes it will continue to drive Bitcoin’s momentum in the short to medium term.In a discussion thread, Jean-Paul Kogelman proposes organizing a list into subdirectories that correspond to the status of BIP 1. Martin suggests considering using IETF (Internet Engineering Task Force) for this process, noting their extensive experience in handling over 7000 RFCs through a hardened process developed over 40 years.Jean-Paul Kogelman suggests organizing BIPs into subdirectories based on their status- Accepted, Active, Draft, Deferred, Final, Rejected, Replaced, or Withdrawn. Martin then asks if the process could be done via IETF, which has over 40 years of experience and 7000+ RFCs.Peter Todd suggests making a GitHub repository for Bitcoin Improvement Proposals (BIPs) to make it easier to archive and update them. Todd creates a GitHub repository and copies the exact text of the BIP from the bitcoin.it wiki using MediaWiki support. Jeff Garzik agrees with Todd's proposal and nominates him to do the conversion.Wladimir van der Laan expresses frustration with the unfriendly behavior of some Bitcoin developers on forums. He cautions against sending people to these forums and emphasizes that they are not endorsed by the developer community. However, he notes that the core developer community is relatively small and reviewing and testing proposals can take time.On October 19, 2013, Jean-Paul Kogelman asks Luke Dashjr about the process for obtaining a BIP number. Dashjr directs Kogelman to BIP 1 which outlines the proposal process.Mitar shares an interesting read from the Berkeley School of Information about Bitcoin's development community. The conversation touches on newcomer experience and potential issues with communication and transparency. Some pull requests were left unaddressed for long periods of time due to shortages of active review and prioritization of safety-critical changes.In an email conversation, Mitar suggests that the Bitcoin community could benefit from adopting a code of conduct similar to Ubuntu's. The Ubuntu Code of Conduct v2.0 emphasizes collaboration, respect, taking responsibility for actions and decisions, and valuing diversity.The provided links lead to an article on "Open Collaboration and Peer Production" from the University of California, Berkeley. The author discusses the principles behind successful open collaboration efforts and identifies key factors that contribute to their success. The link to Mitar's personal website showcases his work and interests in various areas, including software development and blockchain technology. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Advisory-PHP-library-Bitcoin-SCI-weak-key-generation.xml b/static/bitcoin-dev/Oct_2013/combined_Advisory-PHP-library-Bitcoin-SCI-weak-key-generation.xml index c54e6fb506..87496cde05 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Advisory-PHP-library-Bitcoin-SCI-weak-key-generation.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Advisory-PHP-library-Bitcoin-SCI-weak-key-generation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Advisory: PHP library Bitcoin SCI weak key generation - 2023-08-01T06:20:29.799333+00:00 + 2025-10-11T21:41:34.698643+00:00 + python-feedgen Andres Home 2013-10-27 22:48:04+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Advisory: PHP library Bitcoin SCI weak key generation - 2023-08-01T06:20:29.799333+00:00 + 2025-10-11T21:41:34.698782+00:00 - In 2013, Gavin Andresen, a prominent developer in the Bitcoin community, raised concerns about weak key generation in the Bitcoin SCI library. He specifically warned developers who use this library to carefully review how their software handles private key creation. While there is no information about other affected libraries, Gavin was able to identify another library besides Bitcoin SCI that had similar issues.The Bitcoin SCI library, which can be found at http://bitfreak.info/index.php?page=tools&t=bitsci, has been flagged for its weak private key creation. The library previously used either the Mersenne Twister PRNG or the GMP library's PRNG directly to generate private keys. Although the most recent version of the library has resolved some of these concerns by updating the createNewMiniKey() function, other functions related to key generation remain unchanged.It is advised that even developers not using the Bitcoin SCI library should review their own key generation functions if they do not directly interface with bitcoind. This caution is necessary because the affected keys generated by Bitcoin SCI have only 32 bits of entropy, making them vulnerable to GPU-based attacks on keys within the lower ranges. The extent of the issue is unknown, as it is unclear how many keys have been created using the weak functions. These concerns highlight the importance of robust key generation practices in ensuring the security of Bitcoin transactions. 2013-10-27T22:48:04+00:00 + In 2013, Gavin Andresen, a prominent developer in the Bitcoin community, raised concerns about weak key generation in the Bitcoin SCI library. He specifically warned developers who use this library to carefully review how their software handles private key creation. While there is no information about other affected libraries, Gavin was able to identify another library besides Bitcoin SCI that had similar issues.The Bitcoin SCI library, which can be found at http://bitfreak.info/index.php?page=tools&t=bitsci, has been flagged for its weak private key creation. The library previously used either the Mersenne Twister PRNG or the GMP library's PRNG directly to generate private keys. Although the most recent version of the library has resolved some of these concerns by updating the createNewMiniKey() function, other functions related to key generation remain unchanged.It is advised that even developers not using the Bitcoin SCI library should review their own key generation functions if they do not directly interface with bitcoind. This caution is necessary because the affected keys generated by Bitcoin SCI have only 32 bits of entropy, making them vulnerable to GPU-based attacks on keys within the lower ranges. The extent of the issue is unknown, as it is unclear how many keys have been created using the weak functions. These concerns highlight the importance of robust key generation practices in ensuring the security of Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_An-app-store-and-non-network-transaction-fees.xml b/static/bitcoin-dev/Oct_2013/combined_An-app-store-and-non-network-transaction-fees.xml index 622a9ca093..e73818c58f 100644 --- a/static/bitcoin-dev/Oct_2013/combined_An-app-store-and-non-network-transaction-fees.xml +++ b/static/bitcoin-dev/Oct_2013/combined_An-app-store-and-non-network-transaction-fees.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - An "app store" and non-network transaction fees - 2023-08-01T05:52:22.255329+00:00 + Combined summary - An "app store" and non-network transaction fees + 2025-10-11T21:41:38.944483+00:00 + python-feedgen Wendell 2013-10-18 11:56:09+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 - Combined summary - An "app store" and non-network transaction fees - 2023-08-01T05:52:22.255329+00:00 + Combined summary - An "app store" and non-network transaction fees + 2025-10-11T21:41:38.944620+00:00 - A v1 API for managing pledges using Bitcoin has been released. The announcement was made by Wendell on the BitcoinTalk forum, stating that there are currently no fees and only basic features available. Mike Hearn expressed interest in the idea. Contact information for grabhive.com, Twitter, and a GPG key were provided.To use Bitcoin for managing pledges, people can either use a dedicated app or a wallet with the right features. Each option has its own pros and cons. bitcoinj makes it easy to create a new GUI wallet app written in Java. Programming contracts can be done through the link provided for Working With Contracts on the bitcoinj wiki.On Sep 5, 2013, Mike Hearn and Wendell discussed the idea of using assurance contracts to fund a public good. They referred to the 5-step model for assurance contracts described on the Bitcoin wiki and used the example of "Facebook contact synchronization" with a target of 50 BTC. However, they had no experience with the required scripting language. Wendell asked for an example and clarification on donor requirements, to which Hearn responded that it was a bit complicated and required software development. He also suggested that assurance contracts could be a good way to fund complex projects.The email conversation also discussed the idea of a voting system for features using Bitcoin, where users vote by sending funds to a corresponding address. Assurance contracts were considered as a funding method for complex projects. However, implementing these ideas would require significant software development. The conversation then shifted to the potential burden on users if the Bitcoin network were to start relaying blocks. It was pointed out that mobile and tablet devices have different capabilities and limitations compared to desktop computers and laptops. Running Bitcoin software in the background on these devices could negatively impact battery life and bandwidth usage. One solution suggested was using a separate device, such as a Raspberry Pi, to donate to the network without affecting the performance of the primary device.In another email conversation, Mike Hearn and an unknown recipient discussed various aspects of an app store for Bitcoin. Mike suggested thinking of the app store as a set of affiliate schemes, where businesses must have an affiliate scheme in place to be placed into the apps section. Users who refer a lot of users to that business will receive referral bonuses. The apps should be online so businesses can retain control of their features and brand. Hive also plans to have a submission/review process to ensure user experience continuity and monitor potential exploits. They plan to have a public repository for applications maintained by them. One downside is that technical judgment may be distorted if projects heavily push certain businesses due to income dependence. Another alternative funding model suggested was allowing users to bid on assurance contracts for feature development. This would allow the community to direct development and feel directly involved. However, no recurring income could support future endeavors. The use of bitcoinj with an integrated VM for the app's framework was also discussed. It was noted that relying on random end-users donating CPU time or bandwidth to the network is not ideal.In the same email exchange, Wendell proposed a new approach to monetizing apps, where businesses would need to have an affiliate scheme in place to be placed in the apps section. App developers could earn referral bonuses from businesses when they refer users to them through their app. This funding model is compatible with openness but can distort technical judgment. Another alternative funding model suggested was allowing users to bid on assurance contracts for feature development, which would allow the community to direct development and feel directly involved. The use of bitcoinj with an integrated VM was discussed, with the main advantage being SPV. However, any schemes relying on random end-users donating CPU time or bandwidth to the network may not be feasible. Bitcoin might become more like Tor, with relays run on dedicated servers by people with knowledge and community involvement.The OS X wallet Hive has an integrated application platform that allows new users to discover Bitcoin businesses such as exchanges, merchants, and games. The locally hosted HTML/JS applications feature stripped-down UIs displayed in a mobile-proportioned WebKit frame inside of Hive itself. Transaction requests within apps trigger native Cocoa dialogue boxes for a secure experience. The team hopes to sustain themselves via small fees on transactions within the app platform but wants to be as ethical and decentralized as possible. Tracking user behavior and sending bills or having users send micro-transactions are not favored approaches. The team plans to release everything as free software under a GPL license, including the app store and the apps themselves. They will be using bitcoinj with an integrated VM for the time being due to SPV, but they would prefer to support the network more through ideas like partial UTXO sets. The team will be attending a conference in Amsterdam on the 27th of this month for further discussions. 2013-10-18T11:56:09+00:00 + A v1 API for managing pledges using Bitcoin has been released. The announcement was made by Wendell on the BitcoinTalk forum, stating that there are currently no fees and only basic features available. Mike Hearn expressed interest in the idea. Contact information for grabhive.com, Twitter, and a GPG key were provided.To use Bitcoin for managing pledges, people can either use a dedicated app or a wallet with the right features. Each option has its own pros and cons. bitcoinj makes it easy to create a new GUI wallet app written in Java. Programming contracts can be done through the link provided for Working With Contracts on the bitcoinj wiki.On Sep 5, 2013, Mike Hearn and Wendell discussed the idea of using assurance contracts to fund a public good. They referred to the 5-step model for assurance contracts described on the Bitcoin wiki and used the example of "Facebook contact synchronization" with a target of 50 BTC. However, they had no experience with the required scripting language. Wendell asked for an example and clarification on donor requirements, to which Hearn responded that it was a bit complicated and required software development. He also suggested that assurance contracts could be a good way to fund complex projects.The email conversation also discussed the idea of a voting system for features using Bitcoin, where users vote by sending funds to a corresponding address. Assurance contracts were considered as a funding method for complex projects. However, implementing these ideas would require significant software development. The conversation then shifted to the potential burden on users if the Bitcoin network were to start relaying blocks. It was pointed out that mobile and tablet devices have different capabilities and limitations compared to desktop computers and laptops. Running Bitcoin software in the background on these devices could negatively impact battery life and bandwidth usage. One solution suggested was using a separate device, such as a Raspberry Pi, to donate to the network without affecting the performance of the primary device.In another email conversation, Mike Hearn and an unknown recipient discussed various aspects of an app store for Bitcoin. Mike suggested thinking of the app store as a set of affiliate schemes, where businesses must have an affiliate scheme in place to be placed into the apps section. Users who refer a lot of users to that business will receive referral bonuses. The apps should be online so businesses can retain control of their features and brand. Hive also plans to have a submission/review process to ensure user experience continuity and monitor potential exploits. They plan to have a public repository for applications maintained by them. One downside is that technical judgment may be distorted if projects heavily push certain businesses due to income dependence. Another alternative funding model suggested was allowing users to bid on assurance contracts for feature development. This would allow the community to direct development and feel directly involved. However, no recurring income could support future endeavors. The use of bitcoinj with an integrated VM for the app's framework was also discussed. It was noted that relying on random end-users donating CPU time or bandwidth to the network is not ideal.In the same email exchange, Wendell proposed a new approach to monetizing apps, where businesses would need to have an affiliate scheme in place to be placed in the apps section. App developers could earn referral bonuses from businesses when they refer users to them through their app. This funding model is compatible with openness but can distort technical judgment. Another alternative funding model suggested was allowing users to bid on assurance contracts for feature development, which would allow the community to direct development and feel directly involved. The use of bitcoinj with an integrated VM was discussed, with the main advantage being SPV. However, any schemes relying on random end-users donating CPU time or bandwidth to the network may not be feasible. Bitcoin might become more like Tor, with relays run on dedicated servers by people with knowledge and community involvement.The OS X wallet Hive has an integrated application platform that allows new users to discover Bitcoin businesses such as exchanges, merchants, and games. The locally hosted HTML/JS applications feature stripped-down UIs displayed in a mobile-proportioned WebKit frame inside of Hive itself. Transaction requests within apps trigger native Cocoa dialogue boxes for a secure experience. The team hopes to sustain themselves via small fees on transactions within the app platform but wants to be as ethical and decentralized as possible. Tracking user behavior and sending bills or having users send micro-transactions are not favored approaches. The team plans to release everything as free software under a GPL license, including the app store and the apps themselves. They will be using bitcoinj with an integrated VM for the time being due to SPV, but they would prefer to support the network more through ideas like partial UTXO sets. The team will be attending a conference in Amsterdam on the 27th of this month for further discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_BIP-38.xml b/static/bitcoin-dev/Oct_2013/combined_BIP-38.xml index 7cda92e58d..060c544ecf 100644 --- a/static/bitcoin-dev/Oct_2013/combined_BIP-38.xml +++ b/static/bitcoin-dev/Oct_2013/combined_BIP-38.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 38 - 2023-08-01T06:17:51.280494+00:00 + 2025-10-11T21:41:30.448699+00:00 + python-feedgen Wladimir 2013-11-08 15:41:00+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - BIP 38 - 2023-08-01T06:17:51.280494+00:00 + 2025-10-11T21:41:30.448850+00:00 - In an email exchange, Wladimir raises concerns about the implementation of BIP 0038 in Python. He highlights the lack of clarity regarding the use of flag 0x04 and suggests that it be clarified. Wladimir also points out an error in the encryption process mentioned in the BIP. He notes that the process incorrectly states to split the result into two 16-byte halves instead of two 32-byte halves.Gregory responds to Mike's email regarding a recent change to BIP 0038. Gregory informs Mike that there have been no prior messages about his proposal on the list and no mention of the assignment had been made in the wiki. Gregory had assumed that something similar to what happened with BIP 22 had occurred. He also criticizes the idea of having a wallet with only a single address and mentions Jean-Paul Kogelman's draft proposal, which is based on Caldwell's BIP38 work but with a different encoding scheme that was revised in response to public discussion. Gregory suggests combining efforts to move forward.Mike Caldwell, the proposer of BIP 38, requests that the identity of his original proposal be maintained. He acknowledges that Kogelman's improvements to his proposal may be sufficient to supersede what he originally proposed. However, he wants BIP 38 to still be recognized as an existing proposal to avoid confusion for those who have already chosen to use it. Caldwell also expresses his desire to address some shortcomings in another iteration of BIP 38, including outsourcing computationally expensive steps to minimize user risks, incorporating special-purpose "encrypted minikeys," and implementing a typo check with better privacy.Gregory clarifies to Caldwell that prior messages about his proposal never made it to the list and no mention of the assignment had been made in the wiki. Gregory had assumed that Caldwell had created the BIP document without public discussion, similar to his previous actions with BIP 22. Gregory moved the document out after a complaint about bitcoin-qt not confirming with BIP38, but later moved it back when Caldwell informed him that it had been assigned/announced. Gregory believes that having a wallet that only supports a single address is poor form and suggests collaborating with Jean-Paul Kogelman's draft proposal, which is based on Caldwell's BIP38 work but has a different encoding scheme revised in response to public discussion.The author of BIP 0038 seeks help to confirm a recent change made on the Wiki regarding their proposal. They state that the number was assigned in November 2012 but the change suggests otherwise. The author expresses concern that their messages may not be reaching the list and requests assistance in pushing forward the proposal. BIP 0038 enables the creation of password-protected private keys and is already being implemented by various entities such as BitAddress.org, Bit2Factor.org, and Mycelium. The author emphasizes that reassigning the number after it has been established for nearly a year would be confusing, particularly on procedural grounds. 2013-11-08T15:41:00+00:00 + In an email exchange, Wladimir raises concerns about the implementation of BIP 0038 in Python. He highlights the lack of clarity regarding the use of flag 0x04 and suggests that it be clarified. Wladimir also points out an error in the encryption process mentioned in the BIP. He notes that the process incorrectly states to split the result into two 16-byte halves instead of two 32-byte halves.Gregory responds to Mike's email regarding a recent change to BIP 0038. Gregory informs Mike that there have been no prior messages about his proposal on the list and no mention of the assignment had been made in the wiki. Gregory had assumed that something similar to what happened with BIP 22 had occurred. He also criticizes the idea of having a wallet with only a single address and mentions Jean-Paul Kogelman's draft proposal, which is based on Caldwell's BIP38 work but with a different encoding scheme that was revised in response to public discussion. Gregory suggests combining efforts to move forward.Mike Caldwell, the proposer of BIP 38, requests that the identity of his original proposal be maintained. He acknowledges that Kogelman's improvements to his proposal may be sufficient to supersede what he originally proposed. However, he wants BIP 38 to still be recognized as an existing proposal to avoid confusion for those who have already chosen to use it. Caldwell also expresses his desire to address some shortcomings in another iteration of BIP 38, including outsourcing computationally expensive steps to minimize user risks, incorporating special-purpose "encrypted minikeys," and implementing a typo check with better privacy.Gregory clarifies to Caldwell that prior messages about his proposal never made it to the list and no mention of the assignment had been made in the wiki. Gregory had assumed that Caldwell had created the BIP document without public discussion, similar to his previous actions with BIP 22. Gregory moved the document out after a complaint about bitcoin-qt not confirming with BIP38, but later moved it back when Caldwell informed him that it had been assigned/announced. Gregory believes that having a wallet that only supports a single address is poor form and suggests collaborating with Jean-Paul Kogelman's draft proposal, which is based on Caldwell's BIP38 work but has a different encoding scheme revised in response to public discussion.The author of BIP 0038 seeks help to confirm a recent change made on the Wiki regarding their proposal. They state that the number was assigned in November 2012 but the change suggests otherwise. The author expresses concern that their messages may not be reaching the list and requests assistance in pushing forward the proposal. BIP 0038 enables the creation of password-protected private keys and is already being implemented by various entities such as BitAddress.org, Bit2Factor.org, and Mycelium. The author emphasizes that reassigning the number after it has been established for nearly a year would be confusing, particularly on procedural grounds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_BIP0039-Mnemonic-code-for-generating-deterministic-keys.xml b/static/bitcoin-dev/Oct_2013/combined_BIP0039-Mnemonic-code-for-generating-deterministic-keys.xml index e02d0867b8..85e6c6891f 100644 --- a/static/bitcoin-dev/Oct_2013/combined_BIP0039-Mnemonic-code-for-generating-deterministic-keys.xml +++ b/static/bitcoin-dev/Oct_2013/combined_BIP0039-Mnemonic-code-for-generating-deterministic-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP0039 Mnemonic code for generating deterministic keys - 2023-08-01T05:54:31.160072+00:00 + 2025-10-11T21:41:53.823066+00:00 + python-feedgen slush 2013-10-24 19:46:57+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - BIP0039 Mnemonic code for generating deterministic keys - 2023-08-01T05:54:31.160072+00:00 + 2025-10-11T21:41:53.823229+00:00 - Pieter Wuille proposed a Proof of Work (PoW) concept in 2012, which was not pushed as a standard. Slush found the concept to be smart but pointed out its lack of bidirectionality and ability to convert between mnemonic and seed. Jorge Timón raised concerns about removing offensive words from the mnemonics, arguing that these words have a greater emotional impact and are more memorable. However, Slush suggested adding a swearword dictionary to bip39, but it may not gain popularity.The author questions the effectiveness of removing offensive words from mnemonics, proposing that generally offensive words, especially when combined with each other, could optimize the "maximum unforgettableness" criterion. This proposal goes against the trend of removing offensive words and may not be well-received by users.Changes have been made to the BIP39 wordlist, including removing offensive words, resolving duplicities, and implementing an algorithm for detecting similar characters. Slush expressed satisfaction with the new list and requested constructive feedback for the final round. The implementation also includes password protection and seed hardening using Rijndael cipher. The goal is to finalize the project for use in Trezor and by other developers who want to implement the algorithm into clients compatible with Trezor.Pieter proposed a superior system to BIP39, which has built-in configurable difficulty and checksums. The system allows for the use of any dictionary/language/text generator, as the software on the other side doesn't need to use the same dictionary. However, it cannot encode arbitrary data. Slush made changes to the BIP39 wordlist, removing offensive words and implementing an algorithm for detecting similar characters. Password protection of seed and seed hardening using Rijndael cipher were also added.The Bitcoin community has reflected on the BIP39 wordlist and made changes to improve it. Offensive words have been removed, and an algorithm has been implemented to detect words with similar characters. Duplicities have been resolved, making the wordlist more satisfactory. Password protection of seed and seed hardening using Rijndael cipher have also been added. The algorithm will be used in Trezor, and other wallet developers want to implement it into clients compatible with Trezor.The email thread discusses the wordlist used in python-mnemonic. Offensive words have been removed, but concerns have been raised about potentially offensive or threatening word combinations. Changes have been made to replace offensive words, and suggestions have been made to rate words for potential offensiveness and use neutral nouns. The email ends with an advertisement for ServiceNow and a link to join the Bitcoin-development mailing list.In an email exchange, Matthew Mitchell expressed concern about potentially offensive words in the wordlist. Pavol Rusnak revisited the wordlist and replaced approximately 67 offensive words. The changes aimed to improve the overall tone and sensitivity of the list towards different audiences.Andreas Petersson suggested using NLP to generate a grammatically correct sentence out of 128 random bits that humans could remember. He also mentioned encoding information in word selection and syntax tree choice. However, this idea required a larger wordlist and had complexity limitations due to running on embedded devices.The developers of a cryptocurrency wallet are open to changes in their wordlist and will accept pull requests replacing potentially offensive words with more neutral ones. Concerns were raised about rude or offensive word combinations, and suggestions were made to use mechanical turk time to rate words for offensiveness and use neutral nouns instead of place names with political complications.In an email conversation, Mark Friedenbach commented on how image display problems persisted on Wikipedia due to add-ons blocking certain URLs. This highlights the importance of avoiding potential filtering issues when designing systems. The conversation also touched on the challenges of troubleshooting situations where rude word combinations may cause confusion.The author expresses a desire to combine an NLP engine with a mnemonic code generator to output a short, humorous story as a passphrase. This idea was explored further, and another individual expressed interest in encoding the key within the story itself. The goal is to make passphrases more memorable while maintaining security.In an email exchange, Matthew Mitchell expressed concern about potentially offensive words in a project. Pavol Rusnak encouraged Mitchell to come up with wordlist enhancements, acknowledging that the wordlist is not perfect. Rusnak emphasized the importance of providing good alternatives for every word removed from the list.Slush sent an email announcing the finalization of the draft and reference implementation of BIP39. The proposal aims to standardize the algorithm across various clients and fix design problems of the existing Electrum mnemonic algorithm. BIP39 is seen as a complement to BIP32, allowing users to easily backup and share their wallet across multiple clients. The email also includes an advertisement for ServiceNow and information about the Bitcoin-development mailing list.In a discussion about wordlists used in BIPs, concerns were raised about potentially offensive or threatening word combinations. Slush explained 2013-10-24T19:46:57+00:00 + Pieter Wuille proposed a Proof of Work (PoW) concept in 2012, which was not pushed as a standard. Slush found the concept to be smart but pointed out its lack of bidirectionality and ability to convert between mnemonic and seed. Jorge Timón raised concerns about removing offensive words from the mnemonics, arguing that these words have a greater emotional impact and are more memorable. However, Slush suggested adding a swearword dictionary to bip39, but it may not gain popularity.The author questions the effectiveness of removing offensive words from mnemonics, proposing that generally offensive words, especially when combined with each other, could optimize the "maximum unforgettableness" criterion. This proposal goes against the trend of removing offensive words and may not be well-received by users.Changes have been made to the BIP39 wordlist, including removing offensive words, resolving duplicities, and implementing an algorithm for detecting similar characters. Slush expressed satisfaction with the new list and requested constructive feedback for the final round. The implementation also includes password protection and seed hardening using Rijndael cipher. The goal is to finalize the project for use in Trezor and by other developers who want to implement the algorithm into clients compatible with Trezor.Pieter proposed a superior system to BIP39, which has built-in configurable difficulty and checksums. The system allows for the use of any dictionary/language/text generator, as the software on the other side doesn't need to use the same dictionary. However, it cannot encode arbitrary data. Slush made changes to the BIP39 wordlist, removing offensive words and implementing an algorithm for detecting similar characters. Password protection of seed and seed hardening using Rijndael cipher were also added.The Bitcoin community has reflected on the BIP39 wordlist and made changes to improve it. Offensive words have been removed, and an algorithm has been implemented to detect words with similar characters. Duplicities have been resolved, making the wordlist more satisfactory. Password protection of seed and seed hardening using Rijndael cipher have also been added. The algorithm will be used in Trezor, and other wallet developers want to implement it into clients compatible with Trezor.The email thread discusses the wordlist used in python-mnemonic. Offensive words have been removed, but concerns have been raised about potentially offensive or threatening word combinations. Changes have been made to replace offensive words, and suggestions have been made to rate words for potential offensiveness and use neutral nouns. The email ends with an advertisement for ServiceNow and a link to join the Bitcoin-development mailing list.In an email exchange, Matthew Mitchell expressed concern about potentially offensive words in the wordlist. Pavol Rusnak revisited the wordlist and replaced approximately 67 offensive words. The changes aimed to improve the overall tone and sensitivity of the list towards different audiences.Andreas Petersson suggested using NLP to generate a grammatically correct sentence out of 128 random bits that humans could remember. He also mentioned encoding information in word selection and syntax tree choice. However, this idea required a larger wordlist and had complexity limitations due to running on embedded devices.The developers of a cryptocurrency wallet are open to changes in their wordlist and will accept pull requests replacing potentially offensive words with more neutral ones. Concerns were raised about rude or offensive word combinations, and suggestions were made to use mechanical turk time to rate words for offensiveness and use neutral nouns instead of place names with political complications.In an email conversation, Mark Friedenbach commented on how image display problems persisted on Wikipedia due to add-ons blocking certain URLs. This highlights the importance of avoiding potential filtering issues when designing systems. The conversation also touched on the challenges of troubleshooting situations where rude word combinations may cause confusion.The author expresses a desire to combine an NLP engine with a mnemonic code generator to output a short, humorous story as a passphrase. This idea was explored further, and another individual expressed interest in encoding the key within the story itself. The goal is to make passphrases more memorable while maintaining security.In an email exchange, Matthew Mitchell expressed concern about potentially offensive words in a project. Pavol Rusnak encouraged Mitchell to come up with wordlist enhancements, acknowledging that the wordlist is not perfect. Rusnak emphasized the importance of providing good alternatives for every word removed from the list.Slush sent an email announcing the finalization of the draft and reference implementation of BIP39. The proposal aims to standardize the algorithm across various clients and fix design problems of the existing Electrum mnemonic algorithm. BIP39 is seen as a complement to BIP32, allowing users to easily backup and share their wallet across multiple clients. The email also includes an advertisement for ServiceNow and information about the Bitcoin-development mailing list.In a discussion about wordlists used in BIPs, concerns were raised about potentially offensive or threatening word combinations. Slush explained - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_BIP39-word-list.xml b/static/bitcoin-dev/Oct_2013/combined_BIP39-word-list.xml index 0ea660361e..53b410bf91 100644 --- a/static/bitcoin-dev/Oct_2013/combined_BIP39-word-list.xml +++ b/static/bitcoin-dev/Oct_2013/combined_BIP39-word-list.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP39 word list - 2023-08-01T05:59:26.971146+00:00 + 2025-10-11T21:41:41.066000+00:00 + python-feedgen Brooks Boyd 2013-11-02 04:31:33+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - BIP39 word list - 2023-08-01T05:59:26.971146+00:00 + 2025-10-11T21:41:41.066155+00:00 - A proposal has been made to modify the BIP39 wordlist by including alternate options for words that are very similar to each other. This would allow translation programs to assist users in fixing input errors. Marek suggests a simpler solution, using a mapping of similar characters to find combinations that appear in the wordlist when a user types a word not in the list. An updated wordlist has been pushed, filtered to similar characters, and is open for review and comments. The discussion aims to find a clear standard for translating binary to words and avoid confusion. Gregory Maxwell shared a link to a search utility for finding similar words, while Pavol Rusnak emphasizes the need for pull requests with specific changesets. The email thread also includes code for a wordlist solver and mentions avoiding words that could be confusing when written down. 2013-11-02T04:31:33+00:00 + A proposal has been made to modify the BIP39 wordlist by including alternate options for words that are very similar to each other. This would allow translation programs to assist users in fixing input errors. Marek suggests a simpler solution, using a mapping of similar characters to find combinations that appear in the wordlist when a user types a word not in the list. An updated wordlist has been pushed, filtered to similar characters, and is open for review and comments. The discussion aims to find a clear standard for translating binary to words and avoid confusion. Gregory Maxwell shared a link to a search utility for finding similar words, while Pavol Rusnak emphasizes the need for pull requests with specific changesets. The email thread also includes code for a wordlist solver and mentions avoiding words that could be confusing when written down. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Bitcoin-meets-the-Semantic-Web-.xml b/static/bitcoin-dev/Oct_2013/combined_Bitcoin-meets-the-Semantic-Web-.xml index 178cb5b8e0..0c5b2c1b11 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Bitcoin-meets-the-Semantic-Web-.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Bitcoin-meets-the-Semantic-Web-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin meets the Semantic Web.... - 2023-08-01T04:35:32.733838+00:00 + 2025-10-11T21:41:47.440311+00:00 + python-feedgen Melvin Carvalho 2013-10-11 11:27:49+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Bitcoin meets the Semantic Web.... - 2023-08-01T04:35:32.733838+00:00 + 2025-10-11T21:41:47.440503+00:00 - Melvin Carvalho is working on porting crypto currencies to the semantic web, allowing new types of innovation and spreading bitcoin information to a wider audience. The first step is to create a "vocabulary" for bitcoin, which is like a dictionary of terms that can be put down in a machine-readable standard called RDF. To do this, he asks if anyone has worked on this before or if there is a human readable "glossary" for bitcoin that he could take text from. He has made a start on creating the vocabulary and is hosting it at https://w3id.org/cc.During a discussion on April 1st, 2013 about hosting schemas for Bitcoin on the internet, Melvin Carvalho suggested using bitcoin.org, but noted that it lacked https and Github does not allow for setting mime types. Another participant in the discussion suggested using a subdomain such as schema.bitcoin.org to point to an independently run server for the files. The suggestion was made to address the issue of security and effective management of the files.In an email exchange between Harald Schilly and Melvin Carvalho on April 1, 2013, the discussion centered around creating a "vocabulary" for Bitcoin. Schilly suggested checking existing databases like OKFN and searching for existing vocabularies for payments rather than reinventing it. He provided links to various payment protocols such as http://schema.org/PaymentMethod, http://www.heppnetz.de/ontologies/goodrelations/v1#PayPal, and http://lov.okfn.org/dataset/lov/search/#s=payment. Carvalho was already familiar with most of this work and planned to reuse as much as possible, but some terms would be Bitcoin specific. He found https://en.bitcoin.it/wiki/Bitcoin_glossary and wondered where to host it. Schilly gave three ideas for hosting: bitcoin.org, w3id.org, and bitcoin.it wiki.The use case for modeling all crypto currencies, starting with bitcoin, is that a publisher would like to link their web page content or app to a bitcoin address so that donations can be received by those who have enjoyed their work. The model will be something like URI -> crypto-currency-address -> bitcoin-address and the folks at w3id.org have offered to use their permanent identifier switchboard, then redirect to a locked-down vocabulary. As an implementer, one simply needs to add a single rel= tag to their markup. In a web page or HTML5 app, one can use href="bitcoin:1234....". For litecoins (coming soon), one can use href="....">. It's just a small step to start with but can allow all sorts of entities to start accepting bitcoin in a way that complies with the W3C best practices. Melvin will be improving and extending this over time and feedback or help is welcome.In conclusion, Melvin Carvalho is working on porting crypto currencies to the semantic web by creating a vocabulary for bitcoin in machine-readable format. He is seeking input and assistance from others who have experience in this area. During discussions, suggestions were made to host the schemas for Bitcoin on independent servers to address security concerns. Additionally, existing databases such as OKFN were recommended to search for established vocabularies for payments. The ultimate goal is to enable web pages and apps to link to bitcoin addresses for receiving donations, thereby promoting wider acceptance of bitcoin. 2013-10-11T11:27:49+00:00 + Melvin Carvalho is working on porting crypto currencies to the semantic web, allowing new types of innovation and spreading bitcoin information to a wider audience. The first step is to create a "vocabulary" for bitcoin, which is like a dictionary of terms that can be put down in a machine-readable standard called RDF. To do this, he asks if anyone has worked on this before or if there is a human readable "glossary" for bitcoin that he could take text from. He has made a start on creating the vocabulary and is hosting it at https://w3id.org/cc.During a discussion on April 1st, 2013 about hosting schemas for Bitcoin on the internet, Melvin Carvalho suggested using bitcoin.org, but noted that it lacked https and Github does not allow for setting mime types. Another participant in the discussion suggested using a subdomain such as schema.bitcoin.org to point to an independently run server for the files. The suggestion was made to address the issue of security and effective management of the files.In an email exchange between Harald Schilly and Melvin Carvalho on April 1, 2013, the discussion centered around creating a "vocabulary" for Bitcoin. Schilly suggested checking existing databases like OKFN and searching for existing vocabularies for payments rather than reinventing it. He provided links to various payment protocols such as http://schema.org/PaymentMethod, http://www.heppnetz.de/ontologies/goodrelations/v1#PayPal, and http://lov.okfn.org/dataset/lov/search/#s=payment. Carvalho was already familiar with most of this work and planned to reuse as much as possible, but some terms would be Bitcoin specific. He found https://en.bitcoin.it/wiki/Bitcoin_glossary and wondered where to host it. Schilly gave three ideas for hosting: bitcoin.org, w3id.org, and bitcoin.it wiki.The use case for modeling all crypto currencies, starting with bitcoin, is that a publisher would like to link their web page content or app to a bitcoin address so that donations can be received by those who have enjoyed their work. The model will be something like URI -> crypto-currency-address -> bitcoin-address and the folks at w3id.org have offered to use their permanent identifier switchboard, then redirect to a locked-down vocabulary. As an implementer, one simply needs to add a single rel= tag to their markup. In a web page or HTML5 app, one can use href="bitcoin:1234....". For litecoins (coming soon), one can use href="....">. It's just a small step to start with but can allow all sorts of entities to start accepting bitcoin in a way that complies with the W3C best practices. Melvin will be improving and extending this over time and feedback or help is welcome.In conclusion, Melvin Carvalho is working on porting crypto currencies to the semantic web by creating a vocabulary for bitcoin in machine-readable format. He is seeking input and assistance from others who have experience in this area. During discussions, suggestions were made to host the schemas for Bitcoin on independent servers to address security concerns. Additionally, existing databases such as OKFN were recommended to search for established vocabularies for payments. The ultimate goal is to enable web pages and apps to link to bitcoin addresses for receiving donations, thereby promoting wider acceptance of bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Code-review.xml b/static/bitcoin-dev/Oct_2013/combined_Code-review.xml index 7d378d42e7..3799434cde 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Code-review.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Code-review.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Code review - 2023-08-01T05:58:44.560800+00:00 + 2025-10-11T21:41:36.821297+00:00 + python-feedgen Mike Hearn 2013-10-05 11:36:26+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Code review - 2023-08-01T05:58:44.560800+00:00 + 2025-10-11T21:41:36.821513+00:00 - In an email conversation, Gavin Andresen and another participant discussed the issue of incentivizing code review for open-source software projects. They considered using better tools to help with incentivization but expressed concerns over making the pool of reviewers even smaller if the tools are too difficult to use. They also debated whether to thank only people who significantly helped test or review other people's code in future releases' "Thank you" sections or to have a separate section for those who helped review above the current section. Ultimately, they decided it would be unfair not to credit occasional contributors who fixed bugs or maintained something important but didn't review complicated changes to the core.The email thread from October 2013 on the Bitcoin-development mailing list involved Gavin Andresen discussing the process of submitting large and complex work for review. Mike Hearn requested that such work either be submitted as one squashed change or kept logically clean and separated. Andresen agreed to try harder to keep commits separate and thanked Hearn for reviewing the fee changes in detail. During the discussion, Andresen mentioned the idea of using Review Board but expressed concern about potential reviewers being deterred by having to sign up for another account or learn a new tool. He asked if there were examples of other open source projects successfully incentivizing code review. Warren recommended reading the kernel.org documentation on submitting patches for helpful information.In another email exchange, Mike Hearn requested that when submitting large, complex pieces of work for review, they should either be submitted as one giant squashed change or be careful about keeping commits logically clean and separated. Gavin Andresen agreed to try harder to keep commits logically clean and separated. They also discussed the use of Review Board, a tool for code review. Andresen expressed his support for better tools but worried that requiring potential reviewers to sign up and learn another tool may make the pool of reviewers even smaller. They also looked for examples of how other open source software projects incentivize code review and suggested that only people who significantly helped test or review other people's code should be thanked in the "Thank You" section for future releases.In a discussion about code review, it was emphasized that making commits serves to explain to other coders why a change was made. The number of commits is not set in stone, but it is important to consider what would be the best way to explain the changes to fellow coders. It is also crucial to ensure that every commit works and doesn't break the build, as git-bisect works best if every commit in the tree being debugged works without errors. Squashing all changes into one big commit may result in a lack of explanation for why changes were made. While individual commits can be useful for understanding why someone made a change, it may be better to encourage better commit behavior rather than squashing chains of commits.The discussion revolved around whether it is better to have a long chain of commits on a feature branch that are compressed into one big diff or to preserve the individual and accurate messages in the individual commits. The first option disregards valuable information and hinders easy reviewing, while the second option maintains advantages like easier merges and bisects. However, reviewing lots of small commits can be challenging, and some prefer to review large diffs. It is suggested not to discard the small commits, as they can be useful in isolating specific changes. The writer personally puts effort into creating well-described commits and believes that collapsing them all would be a waste of effort.In October 2013, Mike Hearn proposed using Github as a third-party for Bitcoin development, but raised concerns about potentially creating the impression of a closed development process by moving the code review to a server controlled with explicit review groups. He also mentioned Fossil as an alternative option.In an email exchange between Peter Todd and another contributor, Todd shared his preference for using the "Files Changed" tab on GitHub when reviewing multiple commit pull-requests as it allows him to see every change made. The other contributor mentioned that comments on the files changed tab have disappeared in the past, leading to a loss of trust in doing reviews that way. However, they acknowledged that it does make things easier to read. They also discussed the advantages and risks of using GitHub as an independent third party for code review, including the potential impression of a closed process and the possibility of allowing anyone to sign up and comment.In a discussion about code review on Bitcoin, Peter Todd highlighted the issue of rebasing pull requests multiple times until they are accepted, which can render earlier code reviews irrelevant. He also mentioned the risk of introducing malicious code into the Bitcoin codebase. Arto Bendiken provided an example from 2003 where a missing character was used to backdoor the Linux kernel, emphasizing the need for careful review. Peter suggested a system combining PGP-signed code review discussions with git's per-commit signature mechanism to ensure safety, but acknowledged that this system is still a long way off and suggested focusing on careful examination of code that goes into the master branch 2013-10-05T11:36:26+00:00 + In an email conversation, Gavin Andresen and another participant discussed the issue of incentivizing code review for open-source software projects. They considered using better tools to help with incentivization but expressed concerns over making the pool of reviewers even smaller if the tools are too difficult to use. They also debated whether to thank only people who significantly helped test or review other people's code in future releases' "Thank you" sections or to have a separate section for those who helped review above the current section. Ultimately, they decided it would be unfair not to credit occasional contributors who fixed bugs or maintained something important but didn't review complicated changes to the core.The email thread from October 2013 on the Bitcoin-development mailing list involved Gavin Andresen discussing the process of submitting large and complex work for review. Mike Hearn requested that such work either be submitted as one squashed change or kept logically clean and separated. Andresen agreed to try harder to keep commits separate and thanked Hearn for reviewing the fee changes in detail. During the discussion, Andresen mentioned the idea of using Review Board but expressed concern about potential reviewers being deterred by having to sign up for another account or learn a new tool. He asked if there were examples of other open source projects successfully incentivizing code review. Warren recommended reading the kernel.org documentation on submitting patches for helpful information.In another email exchange, Mike Hearn requested that when submitting large, complex pieces of work for review, they should either be submitted as one giant squashed change or be careful about keeping commits logically clean and separated. Gavin Andresen agreed to try harder to keep commits logically clean and separated. They also discussed the use of Review Board, a tool for code review. Andresen expressed his support for better tools but worried that requiring potential reviewers to sign up and learn another tool may make the pool of reviewers even smaller. They also looked for examples of how other open source software projects incentivize code review and suggested that only people who significantly helped test or review other people's code should be thanked in the "Thank You" section for future releases.In a discussion about code review, it was emphasized that making commits serves to explain to other coders why a change was made. The number of commits is not set in stone, but it is important to consider what would be the best way to explain the changes to fellow coders. It is also crucial to ensure that every commit works and doesn't break the build, as git-bisect works best if every commit in the tree being debugged works without errors. Squashing all changes into one big commit may result in a lack of explanation for why changes were made. While individual commits can be useful for understanding why someone made a change, it may be better to encourage better commit behavior rather than squashing chains of commits.The discussion revolved around whether it is better to have a long chain of commits on a feature branch that are compressed into one big diff or to preserve the individual and accurate messages in the individual commits. The first option disregards valuable information and hinders easy reviewing, while the second option maintains advantages like easier merges and bisects. However, reviewing lots of small commits can be challenging, and some prefer to review large diffs. It is suggested not to discard the small commits, as they can be useful in isolating specific changes. The writer personally puts effort into creating well-described commits and believes that collapsing them all would be a waste of effort.In October 2013, Mike Hearn proposed using Github as a third-party for Bitcoin development, but raised concerns about potentially creating the impression of a closed development process by moving the code review to a server controlled with explicit review groups. He also mentioned Fossil as an alternative option.In an email exchange between Peter Todd and another contributor, Todd shared his preference for using the "Files Changed" tab on GitHub when reviewing multiple commit pull-requests as it allows him to see every change made. The other contributor mentioned that comments on the files changed tab have disappeared in the past, leading to a loss of trust in doing reviews that way. However, they acknowledged that it does make things easier to read. They also discussed the advantages and risks of using GitHub as an independent third party for code review, including the potential impression of a closed process and the possibility of allowing anyone to sign up and comment.In a discussion about code review on Bitcoin, Peter Todd highlighted the issue of rebasing pull requests multiple times until they are accepted, which can render earlier code reviews irrelevant. He also mentioned the risk of introducing malicious code into the Bitcoin codebase. Arto Bendiken provided an example from 2003 where a missing character was used to backdoor the Linux kernel, emphasizing the need for careful review. Peter suggested a system combining PGP-signed code review discussions with git's per-commit signature mechanism to ensure safety, but acknowledged that this system is still a long way off and suggested focusing on careful examination of code that goes into the master branch - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Feedback-requested-reject-p2p-message.xml b/static/bitcoin-dev/Oct_2013/combined_Feedback-requested-reject-p2p-message.xml index 0f8285d7ff..a9ece3428e 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Feedback-requested-reject-p2p-message.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Feedback-requested-reject-p2p-message.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Feedback requested: "reject" p2p message - 2023-08-01T06:19:41.977868+00:00 + Combined summary - Feedback requested: "reject" p2p message + 2025-10-11T21:41:32.572285+00:00 + python-feedgen Mike Hearn 2013-10-31 12:01:37+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 - Combined summary - Feedback requested: "reject" p2p message - 2023-08-01T06:19:41.978866+00:00 + Combined summary - Feedback requested: "reject" p2p message + 2025-10-11T21:41:32.572523+00:00 - In an email thread from October 2013, Gregory Maxwell raised concerns about a race condition in which a node using priority queued rate limiting for relaying could accept a transaction but have it fall out of its memory pool before sending it to other peers. However, the author of the email believes this issue is trivial and can be easily resolved. They suggest that there is no requirement for a transaction to be placed into a buffer before relaying, and the small gap between relaying and placing the transaction into the buffer should not cause any issues. It is also noted that Gavin's smartfees branch adds mempool persistence to disk, ensuring that restarting nodes won't clear the mempool in the future. Additionally, the author points out that even if all nodes are honest and well-behaved, it cannot be guaranteed that they will forward transactions, making measuring propagation a necessary part of Bitcoin wallets.In an email from Mike Hearn on October 27th, 2013, he expressed excitement for a new development that would resolve issues with the current Bitcoinj library. The library had been receiving bug reports about transactions not propagating properly, which caused problems as the library selected only one peer to send the transaction to and waited for it to propagate across the network. If this peer refused the transaction, it would not propagate and cause issues. However, Hearn noted that there needed to be documentation explaining that a failure to reject a transaction did not guarantee its forwarding. He explained that if a node was using priority queued rate limiting for relaying, it could accept a transaction but have it fall out of its memory pool before sending it to other peers due to higher priority transactions arriving or getting restarted. Thus, it was not certain that a transaction would be forwarded without issue.In an email exchange from October 30, 2013, Mark Friedenbach discussed fork alerts with an unknown recipient. He clarified that his previous comment was not related to rejecting blocks but rather to the fork alerts that Matt had implemented. These alerts would notify users if an upgrade had been missed. The context provides insight into the technical workings of soft forks in Bitcoin. The author clarifies that a soft fork is an upgrade designed to appear valid to old nodes, relying on miner majority to return everyone "back on track". If new block versions change the serialization format or script language such that old clients reject the block, a hard fork occurs and the alerting code triggers. This discussion sheds light on the technical aspects of Bitcoin and how soft forks operate.In an email conversation between Mike Hearn and Gavin Andresen on October 29, 2013, they discussed the use of soft forks in Bitcoin. Hearn expressed concerns about the mechanism being flawed and undermining the security model of Bitcoin. However, Andresen pointed out that recent versions of the reference implementation would alert users if they were being soft-forked. A warning would be issued if more than half of the last 100 blocks declared a version number that was meaningless to them. The block.version, part of the block header, could also be used by SPV clients to issue warnings. Additionally, there were warnings for those who were forked and for those on a high-work alternative fork.In an email exchange between Peter Todd and Mike Hearn on October 29, 2013, the topic of using nVersion as a soft-forking mechanism was discussed. Hearn suggested having a separate code for blocks claiming to be v2 or v3 to prevent people from using nVersion for nonsense. However, Todd argued that rejecting blocks with unexpected nVersions would result in a hard fork. He also expressed his belief that the whole soft-fork mechanism was wrong and undermined Bitcoin's security model. He emphasized the idea that if rules changed, nodes were meant to end up on a chain fork and trigger an alert.In an email conversation on October 29th, 2013, Mike Hearn raised concerns about losing the nVersion field to people using it for nonsense if a separate code was created for "block is from the future" regarding block 0x11. However, doing so would prevent nVersion from being used as a soft-forking mechanism. Peter Todd responded, agreeing with Hearn's point and signed off with his email signature.Gavin Andresen proposed adding new reject codes for the Bitcoin protocol in a discussion on the bitcoin-development mailing list in 2013. He suggested organizing the codes into categories, such as syntax errors, semantic errors, and server policy rules. There were also debates about having separate codes for different versions of blocks and transactions. It was agreed that using HTTP codes directly would not be suitable, and varints for reject codes were deemed unnecessary as it was unlikely that more than sixteen codes would ever be needed.Warren Togami Jr. suggested using rejection codes to notify users that they had been rate-limited in an email exchange on October 28, 2013. Peter Todd acknowledged the suggestion 2013-10-31T12:01:37+00:00 + In an email thread from October 2013, Gregory Maxwell raised concerns about a race condition in which a node using priority queued rate limiting for relaying could accept a transaction but have it fall out of its memory pool before sending it to other peers. However, the author of the email believes this issue is trivial and can be easily resolved. They suggest that there is no requirement for a transaction to be placed into a buffer before relaying, and the small gap between relaying and placing the transaction into the buffer should not cause any issues. It is also noted that Gavin's smartfees branch adds mempool persistence to disk, ensuring that restarting nodes won't clear the mempool in the future. Additionally, the author points out that even if all nodes are honest and well-behaved, it cannot be guaranteed that they will forward transactions, making measuring propagation a necessary part of Bitcoin wallets.In an email from Mike Hearn on October 27th, 2013, he expressed excitement for a new development that would resolve issues with the current Bitcoinj library. The library had been receiving bug reports about transactions not propagating properly, which caused problems as the library selected only one peer to send the transaction to and waited for it to propagate across the network. If this peer refused the transaction, it would not propagate and cause issues. However, Hearn noted that there needed to be documentation explaining that a failure to reject a transaction did not guarantee its forwarding. He explained that if a node was using priority queued rate limiting for relaying, it could accept a transaction but have it fall out of its memory pool before sending it to other peers due to higher priority transactions arriving or getting restarted. Thus, it was not certain that a transaction would be forwarded without issue.In an email exchange from October 30, 2013, Mark Friedenbach discussed fork alerts with an unknown recipient. He clarified that his previous comment was not related to rejecting blocks but rather to the fork alerts that Matt had implemented. These alerts would notify users if an upgrade had been missed. The context provides insight into the technical workings of soft forks in Bitcoin. The author clarifies that a soft fork is an upgrade designed to appear valid to old nodes, relying on miner majority to return everyone "back on track". If new block versions change the serialization format or script language such that old clients reject the block, a hard fork occurs and the alerting code triggers. This discussion sheds light on the technical aspects of Bitcoin and how soft forks operate.In an email conversation between Mike Hearn and Gavin Andresen on October 29, 2013, they discussed the use of soft forks in Bitcoin. Hearn expressed concerns about the mechanism being flawed and undermining the security model of Bitcoin. However, Andresen pointed out that recent versions of the reference implementation would alert users if they were being soft-forked. A warning would be issued if more than half of the last 100 blocks declared a version number that was meaningless to them. The block.version, part of the block header, could also be used by SPV clients to issue warnings. Additionally, there were warnings for those who were forked and for those on a high-work alternative fork.In an email exchange between Peter Todd and Mike Hearn on October 29, 2013, the topic of using nVersion as a soft-forking mechanism was discussed. Hearn suggested having a separate code for blocks claiming to be v2 or v3 to prevent people from using nVersion for nonsense. However, Todd argued that rejecting blocks with unexpected nVersions would result in a hard fork. He also expressed his belief that the whole soft-fork mechanism was wrong and undermined Bitcoin's security model. He emphasized the idea that if rules changed, nodes were meant to end up on a chain fork and trigger an alert.In an email conversation on October 29th, 2013, Mike Hearn raised concerns about losing the nVersion field to people using it for nonsense if a separate code was created for "block is from the future" regarding block 0x11. However, doing so would prevent nVersion from being used as a soft-forking mechanism. Peter Todd responded, agreeing with Hearn's point and signed off with his email signature.Gavin Andresen proposed adding new reject codes for the Bitcoin protocol in a discussion on the bitcoin-development mailing list in 2013. He suggested organizing the codes into categories, such as syntax errors, semantic errors, and server policy rules. There were also debates about having separate codes for different versions of blocks and transactions. It was agreed that using HTTP codes directly would not be suitable, and varints for reject codes were deemed unnecessary as it was unlikely that more than sixteen codes would ever be needed.Warren Togami Jr. suggested using rejection codes to notify users that they had been rate-limited in an email exchange on October 28, 2013. Peter Todd acknowledged the suggestion - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Identity-protocol-observation.xml b/static/bitcoin-dev/Oct_2013/combined_Identity-protocol-observation.xml index 701edc1de2..94aecc4007 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Identity-protocol-observation.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Identity-protocol-observation.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Identity protocol observation - 2023-08-01T05:58:04.411379+00:00 + 2025-10-11T21:42:02.336088+00:00 + python-feedgen Daniel Lidstrom 2013-10-03 16:16:27+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Identity protocol observation - 2023-08-01T05:58:04.411379+00:00 + 2025-10-11T21:42:02.336231+00:00 - The context discusses the use of sacrifice as an anonymous identity, proposing it as a simpler alternative to decentralized naming systems like NameCoin. The sacrifice system involves generating short names using phonemes to encode the location of a transaction in the blockchain. These names can be used as unique identifiers for users in an identity protocol being developed by Jeff Garzik. Lightweight clients can verify the validity of a sacrifice transaction by checking its merkle path and verifying its short name. The proposed phoneme system is inspired by urbit.org and bitcoin's identity protocol v1.The identity protocol being developed by Jeff Garzik aims to link a public key fingerprint to a miner sacrifice transaction. The location of a transaction in the blockchain can be encoded using n=log2(h)+log2(t) bits, where h is the block height and t is the number of transactions in the block. Using CVC phonemes, which encode approximately 10.7 bits each, a transaction can be located in the blockchain with just three phonemes. This allows for reasonably short, readable, and memorable names.In the proposed identity protocol, lightweight clients verify the validity of a sacrifice transaction by checking its merkle path. The ordering of the hashes at each level in the merkle path encodes the location of the transaction in the block. Therefore, the lightweight client can verify the short name of the transaction using only the information they already have.To create these short names, the choices for consonants and vowels are somewhat restricted to avoid conflicts and ensure readability. For example, q and k are disallowed, while c is preferred over k. The first consonant cannot be H, and the last consonant cannot be X. Y is considered a vowel and not a consonant.Overall, the proposed sacrifice system offers a simple, scalable solution for decentralized naming, with short, memorable names generated using phonemes encoding the location of a transaction in the blockchain. 2013-10-03T16:16:27+00:00 + The context discusses the use of sacrifice as an anonymous identity, proposing it as a simpler alternative to decentralized naming systems like NameCoin. The sacrifice system involves generating short names using phonemes to encode the location of a transaction in the blockchain. These names can be used as unique identifiers for users in an identity protocol being developed by Jeff Garzik. Lightweight clients can verify the validity of a sacrifice transaction by checking its merkle path and verifying its short name. The proposed phoneme system is inspired by urbit.org and bitcoin's identity protocol v1.The identity protocol being developed by Jeff Garzik aims to link a public key fingerprint to a miner sacrifice transaction. The location of a transaction in the blockchain can be encoded using n=log2(h)+log2(t) bits, where h is the block height and t is the number of transactions in the block. Using CVC phonemes, which encode approximately 10.7 bits each, a transaction can be located in the blockchain with just three phonemes. This allows for reasonably short, readable, and memorable names.In the proposed identity protocol, lightweight clients verify the validity of a sacrifice transaction by checking its merkle path. The ordering of the hashes at each level in the merkle path encodes the location of the transaction in the block. Therefore, the lightweight client can verify the short name of the transaction using only the information they already have.To create these short names, the choices for consonants and vowels are somewhat restricted to avoid conflicts and ensure readability. For example, q and k are disallowed, while c is preferred over k. The first consonant cannot be H, and the last consonant cannot be X. Y is considered a vowel and not a consonant.Overall, the proposed sacrifice system offers a simple, scalable solution for decentralized naming, with short, memorable names generated using phonemes encoding the location of a transaction in the blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Making-fee-estimation-better.xml b/static/bitcoin-dev/Oct_2013/combined_Making-fee-estimation-better.xml index 6038049154..d3fb93f619 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Making-fee-estimation-better.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Making-fee-estimation-better.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Making fee estimation better - 2023-08-01T06:14:43.395768+00:00 + 2025-10-11T21:41:26.201914+00:00 + python-feedgen John Dillon 2013-10-28 07:17:50+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Making fee estimation better - 2023-08-01T06:14:43.396820+00:00 + 2025-10-11T21:41:26.202105+00:00 - The email exchanges discussed the need for better fee estimation and transaction replacement in Bitcoin. Gavin Andresen emphasized the importance of fee estimation and suggested that there may be better mechanisms for estimating fees. Andreas Petersson raised concerns about constantly monitoring transaction propagation and recreating transactions with different fees, especially for certain use cases like half-offline Bluetooth transactions. He proposed combining fee estimation with transaction replacement to give users a way to recover from bad estimates.Peter Todd suggested implementing an 'estimatefees' JSON-RPC api call to estimate the priority or fee needed for a transaction to be relayed across the network and included in the blockchain. He also discussed the need for an increasetxfee RPC command and an erasewallettx RPC command to handle duplicates. Todd offered a 4BTC bounty for a mempool implementation similar to replace-by-fee and believed that getting pools to use it would be relatively easy.The participants discussed the parameters they would like to see in a fee estimation API, such as processing time and confidence levels. They also highlighted the correlation between transaction fees and network security. Tamas Blummer stressed the importance of simplicity in blockchain technology and suggested a method for increasing transaction fees by spending unconfirmed outputs with higher fees.In a conversation between Mike Hearn and Peter Todd, the focus shifted to miners and their transaction acceptance policies. They discussed the possibility of customers wanting exclusive contracts with miners for non-standard transactions. It was emphasized that if a transaction is broadcasted, it should be mined promptly, otherwise indicating a problem. Todd suggested that miners should advertise in their coinbase what fees were actually paid to improve fee estimates. However, Hearn argued that some miners may have complex business models that don't neatly fit into the concept of a "fee." The discussion revealed challenges in determining and implementing effective fee structures within blockchain technology.In a separate email exchange, Peter Todd proposed enhancing fee estimates in out-of-band mining contracts by having miners advertise in their coinbase what fees were actually paid. Concerns were raised about miners with complex business models and the potential for fees to be pushed too low if private transactions were included. The estimates were solely based on broadcast transactions, highlighting the difficulty of accurately estimating fees within blockchain technology.Another suggestion was made to improve fee estimates in out-of-band mining contracts by having miners broadcast transactions with competitive fees to incentivize immediate mining. Additionally, miners could advertise an address to which transactions can be submitted, providing a proof-of-work mechanism to verify significant mining work. While this approach has drawbacks, it offers a different security model compared to other bootstrapping methods. 2013-10-28T07:17:50+00:00 + The email exchanges discussed the need for better fee estimation and transaction replacement in Bitcoin. Gavin Andresen emphasized the importance of fee estimation and suggested that there may be better mechanisms for estimating fees. Andreas Petersson raised concerns about constantly monitoring transaction propagation and recreating transactions with different fees, especially for certain use cases like half-offline Bluetooth transactions. He proposed combining fee estimation with transaction replacement to give users a way to recover from bad estimates.Peter Todd suggested implementing an 'estimatefees' JSON-RPC api call to estimate the priority or fee needed for a transaction to be relayed across the network and included in the blockchain. He also discussed the need for an increasetxfee RPC command and an erasewallettx RPC command to handle duplicates. Todd offered a 4BTC bounty for a mempool implementation similar to replace-by-fee and believed that getting pools to use it would be relatively easy.The participants discussed the parameters they would like to see in a fee estimation API, such as processing time and confidence levels. They also highlighted the correlation between transaction fees and network security. Tamas Blummer stressed the importance of simplicity in blockchain technology and suggested a method for increasing transaction fees by spending unconfirmed outputs with higher fees.In a conversation between Mike Hearn and Peter Todd, the focus shifted to miners and their transaction acceptance policies. They discussed the possibility of customers wanting exclusive contracts with miners for non-standard transactions. It was emphasized that if a transaction is broadcasted, it should be mined promptly, otherwise indicating a problem. Todd suggested that miners should advertise in their coinbase what fees were actually paid to improve fee estimates. However, Hearn argued that some miners may have complex business models that don't neatly fit into the concept of a "fee." The discussion revealed challenges in determining and implementing effective fee structures within blockchain technology.In a separate email exchange, Peter Todd proposed enhancing fee estimates in out-of-band mining contracts by having miners advertise in their coinbase what fees were actually paid. Concerns were raised about miners with complex business models and the potential for fees to be pushed too low if private transactions were included. The estimates were solely based on broadcast transactions, highlighting the difficulty of accurately estimating fees within blockchain technology.Another suggestion was made to improve fee estimates in out-of-band mining contracts by having miners broadcast transactions with competitive fees to incentivize immediate mining. Additionally, miners could advertise an address to which transactions can be submitted, providing a proof-of-work mechanism to verify significant mining work. While this approach has drawbacks, it offers a different security model compared to other bootstrapping methods. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Payment-protocol-for-onion-URLs-.xml b/static/bitcoin-dev/Oct_2013/combined_Payment-protocol-for-onion-URLs-.xml index f5f533f798..de6dc632cb 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Payment-protocol-for-onion-URLs-.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Payment-protocol-for-onion-URLs-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment protocol for onion URLs. - 2023-08-01T06:20:18.137209+00:00 + 2025-10-11T21:42:04.461308+00:00 + python-feedgen Peter Todd 2013-10-31 00:44:01+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Payment protocol for onion URLs. - 2023-08-01T06:20:18.138203+00:00 + 2025-10-11T21:42:04.461526+00:00 - In an email thread, Jeremy Spilman discusses the risks of reusing keys for signing and notes that it is bad form to do so. He suggests that John should have gotten separate public keys for the purpose of his bounty, rather than placing demands on people who haven't consented. Disambiguating bounties was also discussed, with the issue being that if further funds are sent to the bounty address, it's unclear how to handle those funds.The possibility of creating a Python script to do signature accumulation and signing was mentioned, but there hasn't been much demand yet to fully polish UIs. It was noted that blockchain.info had added multisig escrow support in the past but removed it due to near-zero usage.In this context, the author discusses bounties and their signatories. He refers to a bounty for which John has offered 1BTC as reward and another for which he has offered 4BTC as a reward. The 1BTC bounty is a P2SH output with a redeemScript that hashes to the expected value and is a 2-of-3 multisig with three pubkeys expressed as addresses. The vanity address makes it easy to guess who one of the signatories is.The author wonders if reusing keys for signing is bad form. John mentions wanting to disambiguate bounties, perhaps through a bounty-specific pubkey. The author is not sure how that is better than just referencing the address of the output or the TxID in a 'Table of Bounties'. The author also asks if John keeps pubkeys for the signatories he wants to appoint and reuses the same pubkey to create these multi-sigs or has to ask for a new one each time.The author imagines that from the signatories' perspective, a wallet receiving or importing the p2sh, tracking these outputs as "yours," and even more, which contract/bounty they correspond to, and finally a usable way to accumulate signatures and ultimately spend the output to the bounty winner is a long way off.The context then shifts to a discussion between John and Gregory Maxwell about limitations of the payment protocol as specified. Gregory mentions that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. John thinks this is a great idea and offers 1BTC as a reward for completing the task. He trusts either Jeff Garzik or Peter Todd to evaluate the finished product, or possibly someone else's.In an email dated October 28, 2013, Adam Back expressed his opinion on payment protocols and PGP signing. He mentioned that many topics related to payment protocol were discussed a year ago when it was first being designed. According to him, the right way to tackle governments getting bogus certs issued is certificate transparency, and all other suggestions tend to boil down to "handwaving" that does not solve the problem.Back stated that the evidence from the Snowden case reinforces the strength of the CA system, and we did not see stories about bulk usage of fake certificates. Back argued that the increased usage of SSL was a game-changer for intelligence agencies. They compile databases of private keys they obtain in various ways to solve SSL. When the FBI wanted access to LavaBit, they tried to obtain their private keys rather than push a convenient "give me a fake cert" button. When Lavabit had to hand over its key, GoDaddy revoked its certificate because industry policies forced their hand, which doesn't have a get-out clause for the FBI.Back acknowledged that government-issued fake certs are floating about somewhere due to the scale of hacking. However, he stated that demanding perfection in a system that handles security for over a billion people and tens of millions of operators is unreasonable. He suggested that all we can ask for is that the system is being improved, which initiatives like cert transparency aim to do. Back concluded by asking to call time on discussions as they long ago ceased to have any value.In an email exchange on the Bitcoin-development mailing list, Adam Back expressed concern over the use of X.509 in Bitcoin's payment protocol due to its susceptibility to corruption attacks and potential for security nightmares. Instead, Back suggests using bitcoin keys to sign payment messages, which can be associated with X.509 if desired. He also proposes a "pollution" of Bitcoin main with X.509 to avoid binding to Tor.Gregory Maxwell responds that the x.509 in the payment protocol is used for authentication and non-repudiation, not confidentiality, and that the payment protocol is extensible to support namecoin-provided keys and GPG authenticated messages. However, he notes that these would require a fair amount of code and may not be worth doing at this time. Maxwell thinks that Tor onion support would only require a few lines of code and could easily be more widely used than namecoin.In an email exchange from October 2013 2013-10-31T00:44:01+00:00 + In an email thread, Jeremy Spilman discusses the risks of reusing keys for signing and notes that it is bad form to do so. He suggests that John should have gotten separate public keys for the purpose of his bounty, rather than placing demands on people who haven't consented. Disambiguating bounties was also discussed, with the issue being that if further funds are sent to the bounty address, it's unclear how to handle those funds.The possibility of creating a Python script to do signature accumulation and signing was mentioned, but there hasn't been much demand yet to fully polish UIs. It was noted that blockchain.info had added multisig escrow support in the past but removed it due to near-zero usage.In this context, the author discusses bounties and their signatories. He refers to a bounty for which John has offered 1BTC as reward and another for which he has offered 4BTC as a reward. The 1BTC bounty is a P2SH output with a redeemScript that hashes to the expected value and is a 2-of-3 multisig with three pubkeys expressed as addresses. The vanity address makes it easy to guess who one of the signatories is.The author wonders if reusing keys for signing is bad form. John mentions wanting to disambiguate bounties, perhaps through a bounty-specific pubkey. The author is not sure how that is better than just referencing the address of the output or the TxID in a 'Table of Bounties'. The author also asks if John keeps pubkeys for the signatories he wants to appoint and reuses the same pubkey to create these multi-sigs or has to ask for a new one each time.The author imagines that from the signatories' perspective, a wallet receiving or importing the p2sh, tracking these outputs as "yours," and even more, which contract/bounty they correspond to, and finally a usable way to accumulate signatures and ultimately spend the output to the bounty winner is a long way off.The context then shifts to a discussion between John and Gregory Maxwell about limitations of the payment protocol as specified. Gregory mentions that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. John thinks this is a great idea and offers 1BTC as a reward for completing the task. He trusts either Jeff Garzik or Peter Todd to evaluate the finished product, or possibly someone else's.In an email dated October 28, 2013, Adam Back expressed his opinion on payment protocols and PGP signing. He mentioned that many topics related to payment protocol were discussed a year ago when it was first being designed. According to him, the right way to tackle governments getting bogus certs issued is certificate transparency, and all other suggestions tend to boil down to "handwaving" that does not solve the problem.Back stated that the evidence from the Snowden case reinforces the strength of the CA system, and we did not see stories about bulk usage of fake certificates. Back argued that the increased usage of SSL was a game-changer for intelligence agencies. They compile databases of private keys they obtain in various ways to solve SSL. When the FBI wanted access to LavaBit, they tried to obtain their private keys rather than push a convenient "give me a fake cert" button. When Lavabit had to hand over its key, GoDaddy revoked its certificate because industry policies forced their hand, which doesn't have a get-out clause for the FBI.Back acknowledged that government-issued fake certs are floating about somewhere due to the scale of hacking. However, he stated that demanding perfection in a system that handles security for over a billion people and tens of millions of operators is unreasonable. He suggested that all we can ask for is that the system is being improved, which initiatives like cert transparency aim to do. Back concluded by asking to call time on discussions as they long ago ceased to have any value.In an email exchange on the Bitcoin-development mailing list, Adam Back expressed concern over the use of X.509 in Bitcoin's payment protocol due to its susceptibility to corruption attacks and potential for security nightmares. Instead, Back suggests using bitcoin keys to sign payment messages, which can be associated with X.509 if desired. He also proposes a "pollution" of Bitcoin main with X.509 to avoid binding to Tor.Gregory Maxwell responds that the x.509 in the payment protocol is used for authentication and non-repudiation, not confidentiality, and that the payment protocol is extensible to support namecoin-provided keys and GPG authenticated messages. However, he notes that these would require a fair amount of code and may not be worth doing at this time. Maxwell thinks that Tor onion support would only require a few lines of code and could easily be more widely used than namecoin.In an email exchange from October 2013 - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Proposal-to-replace-BIP0039.xml b/static/bitcoin-dev/Oct_2013/combined_Proposal-to-replace-BIP0039.xml index 87d5d63955..233021326e 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Proposal-to-replace-BIP0039.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Proposal-to-replace-BIP0039.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal to replace BIP0039 - 2023-08-01T06:15:56.935326+00:00 + 2025-10-11T21:41:58.072619+00:00 + python-feedgen Pavol Rusnak 2013-11-17 00:49:00+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - Proposal to replace BIP0039 - 2023-08-01T06:15:56.936392+00:00 + 2025-10-11T21:41:58.072861+00:00 - Trezor, a hardware wallet for Bitcoin users, has developed a method to prove the integrity of the seed generated by their device. This method involves combining computer-provided entropy and device-provided entropy to create a master private key and derive a master public key. The computer can verify that the master public key was derived from its own entropy without knowing Trezor's random number. However, there are concerns about verifying the mnemonic corresponding to the secret in Trezor. Trust in Trezor is required to ensure the correct derivation of the master public key. Discussions also revolve around the practicality of using mnemonics in embedded devices and the need for modifications or alternative solutions.In terms of communication between Trezor and the computer, proposals have been made for the computer to verify the master public key and confirm it is derived from its own entropy. Considerations include rigging, the use of bip32 public derivations versus private derivations, version numbers in the seed phrase, defining the tree structure, custom wordlists, and best practices for standardization in the use of BIP32. These discussions emphasize the importance of secure seed generation, verification methods, and the need for compatibility and standardization in cryptocurrency wallets.In an email exchange, the discussion focuses on the standardization of including the tree structure or version information inside the seed. Pieter suggests establishing best practices and exploring different wallet structures before finalizing any standards. Marek agrees with the need for hardening and emphasizes that bip39 already includes some strengthening. The email also touches upon bidirectional transformations, backward-compatibility, and the need to cover version bits in the specification to ensure cross-compatibility between clients.A linked Wikipedia page offers implementation methods for BIP0039, including formatting metadata. Developers can follow the guidelines provided on the page to create efficient and user-friendly implementations. Electrum developer ThomasV admits his previous rejection of adding extra information to mnemonic seeds was wrong. He now sees metadata such as a "version number" as necessary for specifying which branches of the HD tree should be used. A new proposal is suggested, similar to Pieter Wuille's proposal but without requiring a dictionary. The encoding is not symmetric, which is not a requirement for Electrum but may be required for Trezor.In a Bitcointalk forum discussion, concerns are raised about BIP0039's compatibility with Electrum and the lack of version number information in seed encoding. Suggestions include allocating a few bits of the mnemonic for encoding a version number. However, implementing both algorithms simultaneously is also proposed. An email conversation from October 2013 addresses these concerns, suggesting a decision tree implementation in Electrum to determine if the mnemonic is Electrum or BIP39. The lack of history on both algorithms would require choosing a preferred one for specific clients. 2013-11-17T00:49:00+00:00 + Trezor, a hardware wallet for Bitcoin users, has developed a method to prove the integrity of the seed generated by their device. This method involves combining computer-provided entropy and device-provided entropy to create a master private key and derive a master public key. The computer can verify that the master public key was derived from its own entropy without knowing Trezor's random number. However, there are concerns about verifying the mnemonic corresponding to the secret in Trezor. Trust in Trezor is required to ensure the correct derivation of the master public key. Discussions also revolve around the practicality of using mnemonics in embedded devices and the need for modifications or alternative solutions.In terms of communication between Trezor and the computer, proposals have been made for the computer to verify the master public key and confirm it is derived from its own entropy. Considerations include rigging, the use of bip32 public derivations versus private derivations, version numbers in the seed phrase, defining the tree structure, custom wordlists, and best practices for standardization in the use of BIP32. These discussions emphasize the importance of secure seed generation, verification methods, and the need for compatibility and standardization in cryptocurrency wallets.In an email exchange, the discussion focuses on the standardization of including the tree structure or version information inside the seed. Pieter suggests establishing best practices and exploring different wallet structures before finalizing any standards. Marek agrees with the need for hardening and emphasizes that bip39 already includes some strengthening. The email also touches upon bidirectional transformations, backward-compatibility, and the need to cover version bits in the specification to ensure cross-compatibility between clients.A linked Wikipedia page offers implementation methods for BIP0039, including formatting metadata. Developers can follow the guidelines provided on the page to create efficient and user-friendly implementations. Electrum developer ThomasV admits his previous rejection of adding extra information to mnemonic seeds was wrong. He now sees metadata such as a "version number" as necessary for specifying which branches of the HD tree should be used. A new proposal is suggested, similar to Pieter Wuille's proposal but without requiring a dictionary. The encoding is not symmetric, which is not a requirement for Electrum but may be required for Trezor.In a Bitcointalk forum discussion, concerns are raised about BIP0039's compatibility with Electrum and the lack of version number information in seed encoding. Suggestions include allocating a few bits of the mnemonic for encoding a version number. However, implementing both algorithms simultaneously is also proposed. An email conversation from October 2013 addresses these concerns, suggesting a decision tree implementation in Electrum to determine if the mnemonic is Electrum or BIP39. The lack of history on both algorithms would require choosing a preferred one for specific clients. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_Revisiting-the-BIPS-process-a-proposal.xml b/static/bitcoin-dev/Oct_2013/combined_Revisiting-the-BIPS-process-a-proposal.xml index bc6c0b9f8c..cc0b583d6d 100644 --- a/static/bitcoin-dev/Oct_2013/combined_Revisiting-the-BIPS-process-a-proposal.xml +++ b/static/bitcoin-dev/Oct_2013/combined_Revisiting-the-BIPS-process-a-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Revisiting the BIPS process, a proposal - 2023-08-01T06:01:52.857239+00:00 + 2025-10-11T21:41:51.686771+00:00 + python-feedgen Gregory Maxwell 2013-11-19 17:54:34+00:00 @@ -143,13 +144,13 @@ - python-feedgen + 2 Combined summary - Revisiting the BIPS process, a proposal - 2023-08-01T06:01:52.858278+00:00 + 2025-10-11T21:41:51.686966+00:00 - In a conversation about the Bitcoin protocol, Peter Todd expressed his belief that the reference implementation should be considered the real specification, while the information on the Wiki is more like a set of notes. He acknowledged that people who are familiar with the source code do not rely heavily on the Wiki. However, Todd emphasized the importance of openness and transparency in the protocol to instill trust in the system. He suggested that alternate implementations are likely to emerge and that accurately describing the rules should include a notice indicating that it is descriptive rather than normative. Todd also offered his assistance to anyone interested in working on documenting the protocol and its semantics.Another discussion focused on the need for a formalized specification for the Bitcoin protocol to reduce bugs and encourage alternate implementations. The challenge, however, lies in the reluctance to move away from the reference client due to concerns about working on a forked chain or having inaccurate data as a client. One proposed solution is to take small pieces, reach consensus, use universal test cases, and run tests on the testnet. It was suggested that qualified individuals could handle transactions/scripting, but others are welcome to join. While the reference implementation serves as the specification, the information on the Wiki is seen as a condensed version of the real specification. Some have questioned if the information on the Wiki is intentionally obscured to encourage people to check the source code. Despite this, it is important for the protocol to be transparent and documented to build trust in the system.Christian Decker discussed the historical background of the Bitcoin protocol specification, which started over three years ago with an attempt to document the network protocol by reverse engineering it from the Satoshi client. The goal was to enable engineers to create alternative clients and move away from a single client dominating the network. Although the protocol description has improved, Decker does not consider it a complete specification. He believes that having a specification allows for an application-independent review of the protocol to identify improvements and bugs. Decker expressed his desire to see the protocol specification become an official part of the Bitcoin GitHub repository alongside the Satoshi client.In a conversation about consistency in Bitcoin's documentation, Pieter Wuille emphasized the importance of accurately describing the rules of the system while making it clear that the documentation is descriptive rather than normative. He argued against making it difficult to find information about the system, as alternate implementations are likely inevitable. Wuille suggested that extensive documentation of the source code, similar to Knuth's literate programming, could be a middle ground. The discussion raised questions about whether alternative implementations are more likely to have incorrect protocol descriptions or misunderstandings of the reference implementation source code. Wuille offered his availability to answer any questions about the protocol and its semantics.Jeff Garzik highlighted the lack of associated documents for Bitcoin Improvement Proposals (BIPs) 40 and 41 in an email exchange. The group agreed that BIPs should not be used to force ideas onto others but to build consensus and document agreements. Gregory Maxwell and Drak discussed the allocation of numbers for draft proposals, with Maxwell explaining that the IETF distinguishes between individual proposals and accepted documents by working groups. Wladimir suggested creating a repository on Github to store BIP drafts, which received support from Drak. Peter Todd volunteered to create the repository, which would allow new BIPs to use either markdown or MediaWiki format.In a discussion about the Bitcoin protocol specification, Peter Todd emphasized that the reference implementation serves as the true specification for Bitcoin, while the information on the wiki pages is more like simplified notes. He clarified that the wiki pages are not deliberately obscure but are contributed by individuals who are not involved in the development of the reference implementation. Martin Sustrik questioned whether the notes were intentionally vague to force people to check the source code.Jeff Garzik suggested a distributed approach to writing Bitcoin Improvement Proposals (BIPs), where anyone can submit a pull request to improve a draft. Martin Sustrik expressed interest in participating but was concerned that the spec was deliberately vague to force compatibility with the reference implementation rather than with a document. Peter Todd explained that the reference implementation is the actual specification and advised those who don't understand this to assume that the protocol is fixed and doesn't evolve much.Gregory Maxwell and Martin Sustrik discussed the relevance of Security Considerations in RFCs for Bitcoin. Maxwell suggested that conformance with certain sections of the specification is necessary for security. Sustrik agreed and stated that all implementations must support the current version of the protocol, regardless of whether it has been documented and published. He also recommended using RFC 6919 keywords in the Bitcoin protocol RFC to convey different levels of importance and requirement.Martin Sustrik expressed frustration with the lack of a comprehensive protocol specification for Bitcoin and offered to help create one if necessary. Peter Todd cautioned against writing RFCs due to the consensus nature of Bitcoin and suggested learning from the Khan Academy videos and reading the source code instead.Jean-Paul Kogelman shared a link to the 2013-11-19T17:54:34+00:00 + In a conversation about the Bitcoin protocol, Peter Todd expressed his belief that the reference implementation should be considered the real specification, while the information on the Wiki is more like a set of notes. He acknowledged that people who are familiar with the source code do not rely heavily on the Wiki. However, Todd emphasized the importance of openness and transparency in the protocol to instill trust in the system. He suggested that alternate implementations are likely to emerge and that accurately describing the rules should include a notice indicating that it is descriptive rather than normative. Todd also offered his assistance to anyone interested in working on documenting the protocol and its semantics.Another discussion focused on the need for a formalized specification for the Bitcoin protocol to reduce bugs and encourage alternate implementations. The challenge, however, lies in the reluctance to move away from the reference client due to concerns about working on a forked chain or having inaccurate data as a client. One proposed solution is to take small pieces, reach consensus, use universal test cases, and run tests on the testnet. It was suggested that qualified individuals could handle transactions/scripting, but others are welcome to join. While the reference implementation serves as the specification, the information on the Wiki is seen as a condensed version of the real specification. Some have questioned if the information on the Wiki is intentionally obscured to encourage people to check the source code. Despite this, it is important for the protocol to be transparent and documented to build trust in the system.Christian Decker discussed the historical background of the Bitcoin protocol specification, which started over three years ago with an attempt to document the network protocol by reverse engineering it from the Satoshi client. The goal was to enable engineers to create alternative clients and move away from a single client dominating the network. Although the protocol description has improved, Decker does not consider it a complete specification. He believes that having a specification allows for an application-independent review of the protocol to identify improvements and bugs. Decker expressed his desire to see the protocol specification become an official part of the Bitcoin GitHub repository alongside the Satoshi client.In a conversation about consistency in Bitcoin's documentation, Pieter Wuille emphasized the importance of accurately describing the rules of the system while making it clear that the documentation is descriptive rather than normative. He argued against making it difficult to find information about the system, as alternate implementations are likely inevitable. Wuille suggested that extensive documentation of the source code, similar to Knuth's literate programming, could be a middle ground. The discussion raised questions about whether alternative implementations are more likely to have incorrect protocol descriptions or misunderstandings of the reference implementation source code. Wuille offered his availability to answer any questions about the protocol and its semantics.Jeff Garzik highlighted the lack of associated documents for Bitcoin Improvement Proposals (BIPs) 40 and 41 in an email exchange. The group agreed that BIPs should not be used to force ideas onto others but to build consensus and document agreements. Gregory Maxwell and Drak discussed the allocation of numbers for draft proposals, with Maxwell explaining that the IETF distinguishes between individual proposals and accepted documents by working groups. Wladimir suggested creating a repository on Github to store BIP drafts, which received support from Drak. Peter Todd volunteered to create the repository, which would allow new BIPs to use either markdown or MediaWiki format.In a discussion about the Bitcoin protocol specification, Peter Todd emphasized that the reference implementation serves as the true specification for Bitcoin, while the information on the wiki pages is more like simplified notes. He clarified that the wiki pages are not deliberately obscure but are contributed by individuals who are not involved in the development of the reference implementation. Martin Sustrik questioned whether the notes were intentionally vague to force people to check the source code.Jeff Garzik suggested a distributed approach to writing Bitcoin Improvement Proposals (BIPs), where anyone can submit a pull request to improve a draft. Martin Sustrik expressed interest in participating but was concerned that the spec was deliberately vague to force compatibility with the reference implementation rather than with a document. Peter Todd explained that the reference implementation is the actual specification and advised those who don't understand this to assume that the protocol is fixed and doesn't evolve much.Gregory Maxwell and Martin Sustrik discussed the relevance of Security Considerations in RFCs for Bitcoin. Maxwell suggested that conformance with certain sections of the specification is necessary for security. Sustrik agreed and stated that all implementations must support the current version of the protocol, regardless of whether it has been documented and published. He also recommended using RFC 6919 keywords in the Bitcoin protocol RFC to convey different levels of importance and requirement.Martin Sustrik expressed frustration with the lack of a comprehensive protocol specification for Bitcoin and offered to help create one if necessary. Peter Todd cautioned against writing RFCs due to the consensus nature of Bitcoin and suggested learning from the Khan Academy videos and reading the source code instead.Jean-Paul Kogelman shared a link to the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_bitcoind-stops-responding.xml b/static/bitcoin-dev/Oct_2013/combined_bitcoind-stops-responding.xml index a67e01cbbf..b41f534017 100644 --- a/static/bitcoin-dev/Oct_2013/combined_bitcoind-stops-responding.xml +++ b/static/bitcoin-dev/Oct_2013/combined_bitcoind-stops-responding.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoind stops responding - 2023-08-01T05:56:46.167168+00:00 + 2025-10-11T21:41:45.313665+00:00 + python-feedgen Jeff Garzik 2013-10-04 15:05:29+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - bitcoind stops responding - 2023-08-01T05:56:46.167168+00:00 + 2025-10-11T21:41:45.313827+00:00 - In an email chain on October 4th, 2013, Gavin Andresen suggested a patch to make the RPC code in Bitcoin smarter by making the last rpc thread ignore keepalive and always disconnect. Currently, the HTTP server code paths use blocking I/O, so RPC is multi-threaded to work around this issue. Jeff Garzik tried a multi-threaded approach using boost::asio, but it resulted in messy code that required more lines of code per boost async action. The goal is to make the code truly async I/O, and Jeff believes that a single thread with async I/O is likely sufficient for even heavy uses of RPC.In an email correspondence on October 1, 2013, slush reported an issue where one process was frequently calling getinfo every second as a fallback to possibly misconfigured blocknotify, and another process was calling getinfo once a minute to check if bitcoind was working. Gavin Andresen suggested using 'help getinfo' to check if bitcoind was responding to RPC requests without acquiring any locks. Users running into the maximum-of-4-keepalive-requests issue were advised to run with -rpcthreads=11 or however many keepalive connections they needed to support. He also suggested that the rpc code should be smarter, and making the last rpc thread ignore keepalive and always disconnecting should be a simple patch.The context highlights a log from Bitcoin where the `getinfo` RPC function takes more than two seconds to return. This delay is caused by various factors such as receiving a block, committing transactions to the coin database, and setting a new best chain. The author suggests ideas to reduce the time taken by `getinfo`, including closing and reopening the database asynchronously, removing unnecessary options from BDB, and experimenting with an optional boolean parameter for `getinfo` that could skip gathering information that may prolong the call.Jeff Garzik and Olivier discuss network activity during a test and the duration of locks being held. It is suggested that the lock contention with other threads may be causing the long lock time. Olivier modifies the code to measure how long it takes to acquire the locks and finds that it can take over 6 seconds in some cases. Jeff Garzik forwards the email to the Bitcoin-development mailing list.The context also includes reports of issues with bitcoind not responding to RPC calls without any suspicious activity in the logs. These problems occur on various backends, indicating that it is not specific to one node. The issue of RPC hanging is mentioned, and the complexity associated with IsConfirmed/Ismine is highlighted as a possible cause. Suggestions are made to use alternative methods like sendmany instead of sendToAddress to address these issues.There are discussions about the four RPC thread limit introduced in version 0.8.2 of Bitcoin and the support for RPC keepalive. It is noted that building with more RPC threads can resolve the issue of exhausting all four threads and preventing further connections.In September 2013, a user reported an issue where bitcoind stops responding to RPC calls when transactions are sent every 20 seconds or less. This problem is unrelated to other reported issues and is suspected to be caused by the four RPC thread limit. Another user observed similar problems with bitcoind stopping responding to RPC calls without any suspicious activity in the log. This issue occurs on various backends, suggesting it is not specific to one node.A member of the mailing list raises concerns about bitcoind stopping responses to RPC calls without any suspicious activity in the log and low CPU usage. This issue is observed in versions 0.8.2 and 0.8.5 and occurs multiple times per day on various backends. The issue is raised to seek input from others who may be experiencing similar problems.Overall, the context highlights various issues and discussions related to the RPC functionality in Bitcoin, including suggestions for improvements, reports of problems with bitcoind not responding to RPC calls, and possible solutions and workarounds. 2013-10-04T15:05:29+00:00 + In an email chain on October 4th, 2013, Gavin Andresen suggested a patch to make the RPC code in Bitcoin smarter by making the last rpc thread ignore keepalive and always disconnect. Currently, the HTTP server code paths use blocking I/O, so RPC is multi-threaded to work around this issue. Jeff Garzik tried a multi-threaded approach using boost::asio, but it resulted in messy code that required more lines of code per boost async action. The goal is to make the code truly async I/O, and Jeff believes that a single thread with async I/O is likely sufficient for even heavy uses of RPC.In an email correspondence on October 1, 2013, slush reported an issue where one process was frequently calling getinfo every second as a fallback to possibly misconfigured blocknotify, and another process was calling getinfo once a minute to check if bitcoind was working. Gavin Andresen suggested using 'help getinfo' to check if bitcoind was responding to RPC requests without acquiring any locks. Users running into the maximum-of-4-keepalive-requests issue were advised to run with -rpcthreads=11 or however many keepalive connections they needed to support. He also suggested that the rpc code should be smarter, and making the last rpc thread ignore keepalive and always disconnecting should be a simple patch.The context highlights a log from Bitcoin where the `getinfo` RPC function takes more than two seconds to return. This delay is caused by various factors such as receiving a block, committing transactions to the coin database, and setting a new best chain. The author suggests ideas to reduce the time taken by `getinfo`, including closing and reopening the database asynchronously, removing unnecessary options from BDB, and experimenting with an optional boolean parameter for `getinfo` that could skip gathering information that may prolong the call.Jeff Garzik and Olivier discuss network activity during a test and the duration of locks being held. It is suggested that the lock contention with other threads may be causing the long lock time. Olivier modifies the code to measure how long it takes to acquire the locks and finds that it can take over 6 seconds in some cases. Jeff Garzik forwards the email to the Bitcoin-development mailing list.The context also includes reports of issues with bitcoind not responding to RPC calls without any suspicious activity in the logs. These problems occur on various backends, indicating that it is not specific to one node. The issue of RPC hanging is mentioned, and the complexity associated with IsConfirmed/Ismine is highlighted as a possible cause. Suggestions are made to use alternative methods like sendmany instead of sendToAddress to address these issues.There are discussions about the four RPC thread limit introduced in version 0.8.2 of Bitcoin and the support for RPC keepalive. It is noted that building with more RPC threads can resolve the issue of exhausting all four threads and preventing further connections.In September 2013, a user reported an issue where bitcoind stops responding to RPC calls when transactions are sent every 20 seconds or less. This problem is unrelated to other reported issues and is suspected to be caused by the four RPC thread limit. Another user observed similar problems with bitcoind stopping responding to RPC calls without any suspicious activity in the log. This issue occurs on various backends, suggesting it is not specific to one node.A member of the mailing list raises concerns about bitcoind stopping responses to RPC calls without any suspicious activity in the log and low CPU usage. This issue is observed in versions 0.8.2 and 0.8.5 and occurs multiple times per day on various backends. The issue is raised to seek input from others who may be experiencing similar problems.Overall, the context highlights various issues and discussions related to the RPC functionality in Bitcoin, including suggestions for improvements, reports of problems with bitcoind not responding to RPC calls, and possible solutions and workarounds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_homomorphic-coin-value-validatable-but-encrypted-Re-smart-contracts-possible-use-case-yes-or-no-.xml b/static/bitcoin-dev/Oct_2013/combined_homomorphic-coin-value-validatable-but-encrypted-Re-smart-contracts-possible-use-case-yes-or-no-.xml index 7da8385945..179bad482c 100644 --- a/static/bitcoin-dev/Oct_2013/combined_homomorphic-coin-value-validatable-but-encrypted-Re-smart-contracts-possible-use-case-yes-or-no-.xml +++ b/static/bitcoin-dev/Oct_2013/combined_homomorphic-coin-value-validatable-but-encrypted-Re-smart-contracts-possible-use-case-yes-or-no-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?) - 2023-08-01T05:57:40.705485+00:00 + 2025-10-11T21:42:00.199169+00:00 + python-feedgen Adam Back 2013-10-07 19:01:03+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?) - 2023-08-01T05:57:40.705485+00:00 + 2025-10-11T21:42:00.199298+00:00 - A recent update on homomorphic coins reveals that further math validation and a test implementation are required. The initial results for a 2.5kB homomorphic valued coin have been surprisingly positive. While coin splitting incurs a 2.5kB range proof, coin adding, full spending, and mining are free due to the inability of adding existing range-proofed and validated coins to overflow. Additionally, users have the option to add a homomorphically encrypted "0" value to balance out the coin taint.Adam Back, a developer, made an error in his efficient version of Zerocoin-esque in size/cost. He realized that the parameter 't' in the proof is related to bitcoin precision and coin representation, with 't=51' instead of 't=2'. This realization has led him to revert to the less efficient version or explore other creative ideas, such as the experimental Schoenmaker non-standard p, q non-EC one, in order to simplify the proof. Mark Friedenbach's input has prompted the documentation of the current state of homomorphic coins. Adam Back has been researching this topic for several months, intrigued by its unique payment privacy features, particularly in relation to auditable but commercially sensitive information. Although the cost of the efficient version is approximately twice that of the current coin size and verification cost, it offers performance advantages in other aspects.Necessary changes to Schnorr, the EC version of Schnorr-based proofs, allow for n of n multiparty signatures or k of n multiparty signatures. This improvement reduces the verification cost and signature size to that of one pair of ECS signatures. For n > 2, this modification proves to be a space and efficiency enhancement over the existing Bitcoin system.In addition to his research, Adam Back has shared his findings on Bitcointalk, encouraging further discussion and collaboration. His mistake regarding the 't' parameter has sparked the need to return to the less efficient version. However, there are ongoing efforts to explore alternative solutions to simplify the proof by changing coin representation.Furthermore, Mark Friedenbach suggests the possibility of conducting external audits of customer accounts without disclosing private data, which would have applications beyond taxation. He welcomes any proposed solutions or ideas in this regard. 2013-10-07T19:01:03+00:00 + A recent update on homomorphic coins reveals that further math validation and a test implementation are required. The initial results for a 2.5kB homomorphic valued coin have been surprisingly positive. While coin splitting incurs a 2.5kB range proof, coin adding, full spending, and mining are free due to the inability of adding existing range-proofed and validated coins to overflow. Additionally, users have the option to add a homomorphically encrypted "0" value to balance out the coin taint.Adam Back, a developer, made an error in his efficient version of Zerocoin-esque in size/cost. He realized that the parameter 't' in the proof is related to bitcoin precision and coin representation, with 't=51' instead of 't=2'. This realization has led him to revert to the less efficient version or explore other creative ideas, such as the experimental Schoenmaker non-standard p, q non-EC one, in order to simplify the proof. Mark Friedenbach's input has prompted the documentation of the current state of homomorphic coins. Adam Back has been researching this topic for several months, intrigued by its unique payment privacy features, particularly in relation to auditable but commercially sensitive information. Although the cost of the efficient version is approximately twice that of the current coin size and verification cost, it offers performance advantages in other aspects.Necessary changes to Schnorr, the EC version of Schnorr-based proofs, allow for n of n multiparty signatures or k of n multiparty signatures. This improvement reduces the verification cost and signature size to that of one pair of ECS signatures. For n > 2, this modification proves to be a space and efficiency enhancement over the existing Bitcoin system.In addition to his research, Adam Back has shared his findings on Bitcointalk, encouraging further discussion and collaboration. His mistake regarding the 't' parameter has sparked the need to return to the less efficient version. However, there are ongoing efforts to explore alternative solutions to simplify the proof by changing coin representation.Furthermore, Mark Friedenbach suggests the possibility of conducting external audits of customer accounts without disclosing private data, which would have applications beyond taxation. He welcomes any proposed solutions or ideas in this regard. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml b/static/bitcoin-dev/Oct_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml index 626745d933..0753c734e9 100644 --- a/static/bitcoin-dev/Oct_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml +++ b/static/bitcoin-dev/Oct_2013/combined_is-there-a-way-to-do-bitcoin-staging-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - is there a way to do bitcoin-staging? - 2023-08-01T04:55:26.435643+00:00 + 2025-10-11T21:42:06.585524+00:00 + python-feedgen Melvin Carvalho 2013-11-21 20:35:44+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - is there a way to do bitcoin-staging? - 2023-08-01T04:55:26.435643+00:00 + 2025-10-11T21:42:06.585676+00:00 - In a discussion thread from 2013, various ideas for improving the Bitcoin network were proposed. Adam Back suggested creating a live beta version of Bitcoin called "betacoin" for testing and development purposes. Alan Reiner and Peter Vessenes expressed interest in this idea, with the goal of speeding up Bitcoin development while maintaining its value and security. Meanwhile, Betacoin, a new cryptocurrency designed for faster transactions and lower fees, had already been introduced on the market, attracting interest and investment despite potential risks.The conversation also delved into reorganizing blockchain data into an authenticated tree indexed by TxOut script instead of tx-hash. This idea was put forth by Alan Reiner, who believed it could improve the efficiency of the network. Merge mining, where an alt-coin is mined alongside Bitcoin, using the same coins as Bitcoin main, was also discussed by Adam Back. Michael Gronager mentioned that he had already coded the authenticated data structure part and was considering incorporating p2pool style mining.Another topic of discussion was the use of Testnet as an alt-coin for testing non-standard transactions and developing new technologies and services. Dennison Bertram suggested that using Testnet as an alt-coin would provide a pseudo live environment for testing and incentivize people to try and exploit the system. The conversation also explored the advantages and limitations of using blockchain technology for notary and verification services.The conversation continued with various suggestions and proposals. Peter Todd proposed a "fair" merged mining system where miners would have to choose between mining an altcoin or Bitcoin to prove the sacrifice of potential Bitcoin earnings. Luke raised concerns about how this system would work for an altcoin whose price is independent of Bitcoin. Zooko expressed interest in implementing a "beta bitcoin blockchain," suggesting the creation of a common codebase for Bitcoin enthusiasts to experiment with.Adam Back asked if there was a way to experiment with new features without burdening the Bitcoin network. Merged mining and the use of an altcoin, such as bitcoin-staging, were suggested as possible solutions. Additionally, the reorganization of blockchain data into an authenticated tree indexed by TxOut script was discussed.Overall, these discussions revolved around finding ways to experiment with new features, ensure the sacrifice of potential Bitcoin earnings, and avoid diluting the value and parameters of Bitcoin. Merged mining and the use of altcoins like bitcoin-staging were considered as potential solutions to these challenges. 2013-11-21T20:35:44+00:00 + In a discussion thread from 2013, various ideas for improving the Bitcoin network were proposed. Adam Back suggested creating a live beta version of Bitcoin called "betacoin" for testing and development purposes. Alan Reiner and Peter Vessenes expressed interest in this idea, with the goal of speeding up Bitcoin development while maintaining its value and security. Meanwhile, Betacoin, a new cryptocurrency designed for faster transactions and lower fees, had already been introduced on the market, attracting interest and investment despite potential risks.The conversation also delved into reorganizing blockchain data into an authenticated tree indexed by TxOut script instead of tx-hash. This idea was put forth by Alan Reiner, who believed it could improve the efficiency of the network. Merge mining, where an alt-coin is mined alongside Bitcoin, using the same coins as Bitcoin main, was also discussed by Adam Back. Michael Gronager mentioned that he had already coded the authenticated data structure part and was considering incorporating p2pool style mining.Another topic of discussion was the use of Testnet as an alt-coin for testing non-standard transactions and developing new technologies and services. Dennison Bertram suggested that using Testnet as an alt-coin would provide a pseudo live environment for testing and incentivize people to try and exploit the system. The conversation also explored the advantages and limitations of using blockchain technology for notary and verification services.The conversation continued with various suggestions and proposals. Peter Todd proposed a "fair" merged mining system where miners would have to choose between mining an altcoin or Bitcoin to prove the sacrifice of potential Bitcoin earnings. Luke raised concerns about how this system would work for an altcoin whose price is independent of Bitcoin. Zooko expressed interest in implementing a "beta bitcoin blockchain," suggesting the creation of a common codebase for Bitcoin enthusiasts to experiment with.Adam Back asked if there was a way to experiment with new features without burdening the Bitcoin network. Merged mining and the use of an altcoin, such as bitcoin-staging, were suggested as possible solutions. Additionally, the reorganization of blockchain data into an authenticated tree indexed by TxOut script was discussed.Overall, these discussions revolved around finding ways to experiment with new features, ensure the sacrifice of potential Bitcoin earnings, and avoid diluting the value and parameters of Bitcoin. Merged mining and the use of altcoins like bitcoin-staging were considered as potential solutions to these challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_malleability-work-around-vs-fix-Re-0-8-5-with-libsecp256k1-.xml b/static/bitcoin-dev/Oct_2013/combined_malleability-work-around-vs-fix-Re-0-8-5-with-libsecp256k1-.xml index d69180404e..5b4517e2be 100644 --- a/static/bitcoin-dev/Oct_2013/combined_malleability-work-around-vs-fix-Re-0-8-5-with-libsecp256k1-.xml +++ b/static/bitcoin-dev/Oct_2013/combined_malleability-work-around-vs-fix-Re-0-8-5-with-libsecp256k1-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - malleability work-around vs fix (Re: 0.8.5 with libsecp256k1) - 2023-08-01T05:59:19.180789+00:00 + 2025-10-11T21:41:55.947007+00:00 + python-feedgen Adam Back 2013-10-10 15:06:03+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - malleability work-around vs fix (Re: 0.8.5 with libsecp256k1) - 2023-08-01T05:59:19.180789+00:00 + 2025-10-11T21:41:55.947149+00:00 - In a conversation, Adam Back discusses the issue of fixing ambiguity in the asn.1 level. He suggests that it is not necessary to address this ambiguity in order to have conditional payments using not yet broadcast txid outputs as inputs. He points out that even if a new crypto level malleability is discovered in ECDSA, it remains secure.In response to this conversation, Adam Back proposes a more generic and robust solution for fixing the issue. He suggests changing the txid from H(sig,inputs,outputs,script) to H(pubkey,inputs,outputs,script), or something similar. This change would ensure that the malleability of the signature mechanism does not affect the security of conditional payments.The context also discusses the use of deterministic ECDSA signatures, where k is calculated using H(d,m) instead of random values. This method is considered cool and necessary to avoid issues with RNG such as leaked partial bits or biases, which can compromise security.The signature verification relation is provided, involving the calculation of [H(m)s^-1G+rs^-1Q].x=?r. The discussion also addresses the issue of malleability and suggests that plugging the (r,s), (r,-s) specific case as a DSA-specific workaround may not fully address all malleability issues. It is proposed that ECS (schnorr) be added since it is simpler and more efficient.In conclusion, a more generic and robust solution is proposed by Adam Back to fix the issue of malleability in conditional payments. Changing the txid to H(pubkey,inputs,outputs,script) would ensure the security of these payments, regardless of any malleability in the signature mechanism. 2013-10-10T15:06:03+00:00 + In a conversation, Adam Back discusses the issue of fixing ambiguity in the asn.1 level. He suggests that it is not necessary to address this ambiguity in order to have conditional payments using not yet broadcast txid outputs as inputs. He points out that even if a new crypto level malleability is discovered in ECDSA, it remains secure.In response to this conversation, Adam Back proposes a more generic and robust solution for fixing the issue. He suggests changing the txid from H(sig,inputs,outputs,script) to H(pubkey,inputs,outputs,script), or something similar. This change would ensure that the malleability of the signature mechanism does not affect the security of conditional payments.The context also discusses the use of deterministic ECDSA signatures, where k is calculated using H(d,m) instead of random values. This method is considered cool and necessary to avoid issues with RNG such as leaked partial bits or biases, which can compromise security.The signature verification relation is provided, involving the calculation of [H(m)s^-1G+rs^-1Q].x=?r. The discussion also addresses the issue of malleability and suggests that plugging the (r,s), (r,-s) specific case as a DSA-specific workaround may not fully address all malleability issues. It is proposed that ECS (schnorr) be added since it is simpler and more efficient.In conclusion, a more generic and robust solution is proposed by Adam Back to fix the issue of malleability in conditional payments. Changing the txid to H(pubkey,inputs,outputs,script) would ensure the security of these payments, regardless of any malleability in the signature mechanism. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2013/combined_on-CDB-Rewrite-.xml b/static/bitcoin-dev/Oct_2013/combined_on-CDB-Rewrite-.xml index 623e2011a9..0bf29631e8 100644 --- a/static/bitcoin-dev/Oct_2013/combined_on-CDB-Rewrite-.xml +++ b/static/bitcoin-dev/Oct_2013/combined_on-CDB-Rewrite-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - on CDB::Rewrite() - 2023-08-01T05:57:52.749930+00:00 + 2025-10-11T21:41:24.080324+00:00 + python-feedgen Olivier Langlois 2013-10-04 03:23:49+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - on CDB::Rewrite() - 2023-08-01T05:57:52.749930+00:00 + 2025-10-11T21:41:24.080511+00:00 - The author of the context raises a concern about not being able to access https://bitcointalk.org. They then analyze the code for CDB:Rewrite() in the files db.h and db.cpp. It is observed that while the function is declared as 'bool static' in db.h, it is not declared as such in db.cpp. The author is unsure if this inconsistency is a problem or intentional.The focus then shifts to the usage of CDB:Rewrite(). It is found that the function is only called in wallet.cpp, specifically in CWallet::EncryptWallet(), but its return value is ignored. This raises the question of whether this is a deliberate design choice or an unnoticed bug. Although the function mostly succeeds when called, the author considers it a minor bug since the return value is disregarded over 99% of the time.The discussion continues with the observation that CWallet::EncryptWallet() is invoked by AskPassphraseDialog::accept() and WalletModel::setWalletEncrypted(), both of which are interested in the return value of CWallet::EncryptWallet(). The author speculates that this may be related to a previous issue with wallet encryption on bitcoin-qt 0.8.1.In conclusion, the author suggests exploring more "suspicious" code in their integrated development environment (IDE) during quiet moments. They find amusement in attempting to infer the meaning and intent behind the use of 'return 0' and 'return 1'. 2013-10-04T03:23:49+00:00 + The author of the context raises a concern about not being able to access https://bitcointalk.org. They then analyze the code for CDB:Rewrite() in the files db.h and db.cpp. It is observed that while the function is declared as 'bool static' in db.h, it is not declared as such in db.cpp. The author is unsure if this inconsistency is a problem or intentional.The focus then shifts to the usage of CDB:Rewrite(). It is found that the function is only called in wallet.cpp, specifically in CWallet::EncryptWallet(), but its return value is ignored. This raises the question of whether this is a deliberate design choice or an unnoticed bug. Although the function mostly succeeds when called, the author considers it a minor bug since the return value is disregarded over 99% of the time.The discussion continues with the observation that CWallet::EncryptWallet() is invoked by AskPassphraseDialog::accept() and WalletModel::setWalletEncrypted(), both of which are interested in the return value of CWallet::EncryptWallet(). The author speculates that this may be related to a previous issue with wallet encryption on bitcoin-qt 0.8.1.In conclusion, the author suggests exploring more "suspicious" code in their integrated development environment (IDE) during quiet moments. They find amusement in attempting to infer the meaning and intent behind the use of 'return 0' and 'return 1'. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_-BIP-draft-CHECKLOCKTIMEVERIFY-Prevent-a-txout-from-being-spent-until-an-expiration-time.xml b/static/bitcoin-dev/Oct_2014/combined_-BIP-draft-CHECKLOCKTIMEVERIFY-Prevent-a-txout-from-being-spent-until-an-expiration-time.xml index 0103c2c365..8e07ef2beb 100644 --- a/static/bitcoin-dev/Oct_2014/combined_-BIP-draft-CHECKLOCKTIMEVERIFY-Prevent-a-txout-from-being-spent-until-an-expiration-time.xml +++ b/static/bitcoin-dev/Oct_2014/combined_-BIP-draft-CHECKLOCKTIMEVERIFY-Prevent-a-txout-from-being-spent-until-an-expiration-time.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time - 2023-08-01T10:22:48.727877+00:00 + 2025-10-11T22:12:32.799123+00:00 + python-feedgen Gregory Maxwell 2014-10-09 06:40:59+00:00 @@ -123,13 +124,13 @@ - python-feedgen + 2 Combined summary - [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time - 2023-08-01T10:22:48.727877+00:00 + 2025-10-11T22:12:32.799377+00:00 - A proposal has been made to implement arbitrary logic in the Bitcoin network using a new opcode called CHECKLOCKTIMEVERIFY. This opcode would allow complex logic to be implemented, such as output being unable to be spent until a certain time and output only being able to be spent until a certain time. The proposed opcode is considered more flexible than the existing OP_CHECKLOCKTIMEVERIFY and can be used to achieve various use cases involving alternative key groups and time constraints.The conversation between Peter Todd and Luke Dashjr revolves around the implementation of this opcode. Luke asks if it can be used to build a script that can only be spent up until a specific block. Peter suggests creating a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator to achieve this functionality. They also discuss the implications of short maturity periods and the potential for mining centralization. Instead of destroying coins, Peter suggests sacrificing them to incentivize miners.Another email exchange between Gavin Andresen and Alan Reiner explores the concept of proof-of-burn as a method of funding transactions in Bitcoin. They discuss the advantages and disadvantages of using P2SH transactions for proof-of-burn schemes. Gavin explains that using P2SH can prevent miners from knowing the advantage of holding the first transaction until it's too late. They also touch upon the importance of revealing the redeeming script to ensure the validity of the sacrifice.In another discussion, Gavin Andresen notes that encoding the target height/time directly may lead to miners delaying the mining of the first transaction. He suggests reproducing the generation maturity rule by stating "cannot be spent until 100 blocks after the first transaction is mined." Short maturity periods are deemed appropriate for many use cases.Sergio Lerner suggests that applications and nodes should only broadcast transactions with OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value to avoid rejection by peers. There is a debate about banning peers that send transactions failing to verify OP_CHECKLOCKTIMEVERIFY, with Sergio expressing his dislike for this option. Another suggestion is for the sender to periodically check the height of their peers to ensure they are up to date with the blockchain.Gavin Andresen suggests deferring discussions on rolling out the proposal until there is a consensus on its benefits and risks. He emphasizes the importance of carefully considering the semantics and implementation details. The message supports the proposal but highlights the need for thorough evaluation before proceeding.Overall, the discussions revolve around the implementation and potential use cases of the proposed opcode CHECKLOCKTIMEVERIFY. Various ideas and concerns are raised, including mining centralization, scriptPubKey manipulation, proof-of-burn schemes, and broadcasting transactions with OP_CHECKLOCKTIMEVERIFY. 2014-10-09T06:40:59+00:00 + A proposal has been made to implement arbitrary logic in the Bitcoin network using a new opcode called CHECKLOCKTIMEVERIFY. This opcode would allow complex logic to be implemented, such as output being unable to be spent until a certain time and output only being able to be spent until a certain time. The proposed opcode is considered more flexible than the existing OP_CHECKLOCKTIMEVERIFY and can be used to achieve various use cases involving alternative key groups and time constraints.The conversation between Peter Todd and Luke Dashjr revolves around the implementation of this opcode. Luke asks if it can be used to build a script that can only be spent up until a specific block. Peter suggests creating a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator to achieve this functionality. They also discuss the implications of short maturity periods and the potential for mining centralization. Instead of destroying coins, Peter suggests sacrificing them to incentivize miners.Another email exchange between Gavin Andresen and Alan Reiner explores the concept of proof-of-burn as a method of funding transactions in Bitcoin. They discuss the advantages and disadvantages of using P2SH transactions for proof-of-burn schemes. Gavin explains that using P2SH can prevent miners from knowing the advantage of holding the first transaction until it's too late. They also touch upon the importance of revealing the redeeming script to ensure the validity of the sacrifice.In another discussion, Gavin Andresen notes that encoding the target height/time directly may lead to miners delaying the mining of the first transaction. He suggests reproducing the generation maturity rule by stating "cannot be spent until 100 blocks after the first transaction is mined." Short maturity periods are deemed appropriate for many use cases.Sergio Lerner suggests that applications and nodes should only broadcast transactions with OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value to avoid rejection by peers. There is a debate about banning peers that send transactions failing to verify OP_CHECKLOCKTIMEVERIFY, with Sergio expressing his dislike for this option. Another suggestion is for the sender to periodically check the height of their peers to ensure they are up to date with the blockchain.Gavin Andresen suggests deferring discussions on rolling out the proposal until there is a consensus on its benefits and risks. He emphasizes the importance of carefully considering the semantics and implementation details. The message supports the proposal but highlights the need for thorough evaluation before proceeding.Overall, the discussions revolve around the implementation and potential use cases of the proposed opcode CHECKLOCKTIMEVERIFY. Various ideas and concerns are raised, including mining centralization, scriptPubKey manipulation, proof-of-burn schemes, and broadcasting transactions with OP_CHECKLOCKTIMEVERIFY. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_About-watch-only-addresses.xml b/static/bitcoin-dev/Oct_2014/combined_About-watch-only-addresses.xml index fa4ea89516..2ce29c9b2f 100644 --- a/static/bitcoin-dev/Oct_2014/combined_About-watch-only-addresses.xml +++ b/static/bitcoin-dev/Oct_2014/combined_About-watch-only-addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - About watch-only addresses - 2023-08-01T10:29:20.650733+00:00 + 2025-10-11T22:12:05.163671+00:00 + python-feedgen mbde at bitwatch.co 2014-10-20 23:06:36+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - About watch-only addresses - 2023-08-01T10:29:20.651772+00:00 + 2025-10-11T22:12:05.163841+00:00 - In response to Flavien's inquiry, Wladimir confirms that watch-only addresses have been merged into Bitcoin Core and can be accessed through the "importaddress" RPC call. However, he advises caution when using the master version without development/debugging experience and recommends building it yourself if you want to test day-to-day development versions. He also mentions that there are currently no nightly builds available.Warren Togami Jr., a Bitcoin developer, shares his own branch of Bitcoin 0.9.3 which includes watch-only functionality and patches to clean it up from the master branch. Although it has not been heavily tested, it seems to work fine. Sipa's address index branch may be more suitable for cases where information about any address is required, and jmcorgan continues to maintain an up-to-date version. DexX7 also has his own branch for balance queries with additional RPC calls, but he recommends reviewing the changes before considering using it.Overall, watch-only addresses have been integrated into Bitcoin Core, but users are advised to exercise caution when using the master version without development/debugging experience. Warren Togami Jr. has created a branch with watch-only functionality and several patches, and there are alternative branches available for specific use cases. The release candidate for version 0.10 is expected in a few months, possibly by the end of the year. At present, there are no nightly builds available, as Warren stopped building them around June. 2014-10-20T23:06:36+00:00 + In response to Flavien's inquiry, Wladimir confirms that watch-only addresses have been merged into Bitcoin Core and can be accessed through the "importaddress" RPC call. However, he advises caution when using the master version without development/debugging experience and recommends building it yourself if you want to test day-to-day development versions. He also mentions that there are currently no nightly builds available.Warren Togami Jr., a Bitcoin developer, shares his own branch of Bitcoin 0.9.3 which includes watch-only functionality and patches to clean it up from the master branch. Although it has not been heavily tested, it seems to work fine. Sipa's address index branch may be more suitable for cases where information about any address is required, and jmcorgan continues to maintain an up-to-date version. DexX7 also has his own branch for balance queries with additional RPC calls, but he recommends reviewing the changes before considering using it.Overall, watch-only addresses have been integrated into Bitcoin Core, but users are advised to exercise caution when using the master version without development/debugging experience. Warren Togami Jr. has created a branch with watch-only functionality and several patches, and there are alternative branches available for specific use cases. The release candidate for version 0.10 is expected in a few months, possibly by the end of the year. At present, there are no nightly builds available, as Warren stopped building them around June. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_BIP-process.xml b/static/bitcoin-dev/Oct_2014/combined_BIP-process.xml index 39c8d67208..fff2a41ebb 100644 --- a/static/bitcoin-dev/Oct_2014/combined_BIP-process.xml +++ b/static/bitcoin-dev/Oct_2014/combined_BIP-process.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP process - 2023-08-01T02:34:33.599104+00:00 + 2025-10-11T22:12:09.416246+00:00 + python-feedgen odinn 2014-10-20 00:33:34+00:00 @@ -99,13 +100,13 @@ - python-feedgen + 2 Combined summary - BIP process - 2023-08-01T02:34:33.599104+00:00 + 2025-10-11T22:12:09.416471+00:00 - The email thread from 2011 discusses the proposal to improve the decision-making process and workflow for Bitcoin Improvement Proposals (BIPs). The aim is to distribute the decision-making process, reducing the bottleneck created by the Bitcoin Core team. To achieve this, the authors propose adhering to the guidelines set by BIP 1, which include not allowing technical changes to final BIPs without community consensus.In addition to this proposal, it is suggested to move the BIP discussion to a separate mailing list to alleviate the workload on the bitcoin-development list, which currently serves as a forum for both Bitcoin Core implementation concerns and global changes to Bitcoin in the form of BIPs. By separating the discussions, it would make the workflow smoother and more efficient.However, there are challenges with using GitHub pulls and issues for the BIP process. GitHub lacks multistage workflow capabilities, making it difficult when something needs to go through multiple steps. Additionally, there are issues with people failing to comment on BIPs, hindering the decision-making process.To address these challenges, the author suggests setting reasonable deadlines and implementing a default decision if no comments are received within that time frame. This would help motivate individuals to get involved in a timely manner.Overall, the goal is to create a more formal process for managing changes to the BIPs repository and improve the workflow for BIP discussions. By distributing the decision-making process and streamlining the communication channels, it would allow for more open discussion and collaboration within the Bitcoin community.In the same email thread, another proposal is made regarding the creation of BIPs as wiki pages. The suggestion is to use GitHub's Wiki feature as it supports MarkDown and allows for easy creation of a repository containing all finalized BIPs. This approach is considered more convenient than importing a mediawiki dump. It is also recommended that BIPs should only include images when necessary.Amir is suggested as a potential editor for the BIPs, pending his willingness. Furthermore, instead of having a specialized mailing list for Bitcoin ideas, it is proposed that discussions regarding potential BIPs take place on either the bitcoin-dev mailing list or the current platform.Gavin Andresen has already started some proposals on GitHub's Wiki feature, which is seen as a step in the right direction. The aim is to maintain a separate repository for similar proposals to keep them distinct from the core Bitcoin repository.The BIP process, created by Amir, is intended to formalize changes to Bitcoin. BIPs are used for changes that may impact every Bitcoin implementation. The author suggests minor changes to the BIP process, including having BIPs as wiki pages with the author having the final word in editing conflicts. The proposal recommends Amir as the BIP editor and suggests discussing new potential BIPs on either the given mailing list or the bitcoin-dev mailing list. 2014-10-20T00:33:34+00:00 + The email thread from 2011 discusses the proposal to improve the decision-making process and workflow for Bitcoin Improvement Proposals (BIPs). The aim is to distribute the decision-making process, reducing the bottleneck created by the Bitcoin Core team. To achieve this, the authors propose adhering to the guidelines set by BIP 1, which include not allowing technical changes to final BIPs without community consensus.In addition to this proposal, it is suggested to move the BIP discussion to a separate mailing list to alleviate the workload on the bitcoin-development list, which currently serves as a forum for both Bitcoin Core implementation concerns and global changes to Bitcoin in the form of BIPs. By separating the discussions, it would make the workflow smoother and more efficient.However, there are challenges with using GitHub pulls and issues for the BIP process. GitHub lacks multistage workflow capabilities, making it difficult when something needs to go through multiple steps. Additionally, there are issues with people failing to comment on BIPs, hindering the decision-making process.To address these challenges, the author suggests setting reasonable deadlines and implementing a default decision if no comments are received within that time frame. This would help motivate individuals to get involved in a timely manner.Overall, the goal is to create a more formal process for managing changes to the BIPs repository and improve the workflow for BIP discussions. By distributing the decision-making process and streamlining the communication channels, it would allow for more open discussion and collaboration within the Bitcoin community.In the same email thread, another proposal is made regarding the creation of BIPs as wiki pages. The suggestion is to use GitHub's Wiki feature as it supports MarkDown and allows for easy creation of a repository containing all finalized BIPs. This approach is considered more convenient than importing a mediawiki dump. It is also recommended that BIPs should only include images when necessary.Amir is suggested as a potential editor for the BIPs, pending his willingness. Furthermore, instead of having a specialized mailing list for Bitcoin ideas, it is proposed that discussions regarding potential BIPs take place on either the bitcoin-dev mailing list or the current platform.Gavin Andresen has already started some proposals on GitHub's Wiki feature, which is seen as a step in the right direction. The aim is to maintain a separate repository for similar proposals to keep them distinct from the core Bitcoin repository.The BIP process, created by Amir, is intended to formalize changes to Bitcoin. BIPs are used for changes that may impact every Bitcoin implementation. The author suggests minor changes to the BIP process, including having BIPs as wiki pages with the author having the final word in editing conflicts. The proposal recommends Amir as the BIP editor and suggests discussing new potential BIPs on either the given mailing list or the bitcoin-dev mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Bitcoin-Core-0-10-release-schedule.xml b/static/bitcoin-dev/Oct_2014/combined_Bitcoin-Core-0-10-release-schedule.xml index bcd195ba6c..7c0821210b 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Bitcoin-Core-0-10-release-schedule.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Bitcoin-Core-0-10-release-schedule.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.10 release schedule - 2023-08-01T10:33:19.491247+00:00 + 2025-10-11T22:12:11.543428+00:00 + python-feedgen Jeff Garzik 2014-10-27 11:37:47+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.10 release schedule - 2023-08-01T10:33:19.492245+00:00 + 2025-10-11T22:12:11.543605+00:00 - Melvin Carvalho suggested creating a Bitcoin Improvement Proposal (BIP) as a way to put forth ideas and proposals for the development of Bitcoin. The new REST interface was seen as a good starting point for further discussion, as it already exports information that is available in Bitcoin Core's internals. However, it will not be developed into a full-fledged block explorer. Feedback on the HTTP headers and form of the REST interface was welcomed, with plans to add last-modified and etag headers. There are also proposals to export UTXOs and rebuild the RPC server to something multithreaded.In an email conversation between Melvin and Wladimir, Melvin asked for documentation on the REST API for electronic coins, which he was also working on. Wladimir referred him to the opening post by Jeff Garzik, which contained some documentation on how to use the API. However, there was currently no write-up about the current functionality in the release notes. Melvin offered to help with documentation. Melvin also asked about the stability of version 1 of the API going forward and whether or not there would be support to develop this interface into something that would be W3C standards compliant. Wladimir responded saying that it's not too late to make changes to version 1 as it hasn't been merged yet. He mentioned that a W3C standard takes a long time to come through, but it may be more useful to have the API available rather than wait for the API to be standardized. Wladimir noted that they are only interested in exposing read-only, public data that is already available in Bitcoin Core's internals. They are not aiming to add a fully-fledged block explorer with address indexes, although that could be part of the standard if it allows implementations to support just a subset. Finally, Wladimir suggested that Melvin coordinate his efforts with Jeff Garzik and consider putting down some thoughts and proposals in a BIP.Another user named Luke Dashjr reached out to Wladimir, asking for his opinion on what is ready and not too risky to be included in version 0.10 of Bitcoin Core. Luke mentioned that they needed a bug fix for submitblock, CreateNewBlock, and miner_tests. He also suggested introducing CNodePolicy for putting isolated node policy code. Harmless changes including support for returning specific rejection reasons, support for BIP 23 block proposal, elaborating on signverify message dialog warning, and further commits to merge after the introduction of CNodePolicy were also proposed. The miners requested enabling customization of node policy for data carrier data size with a low-risk configuration change. Wladimir approved all the changes except for the full-blown "miner policy class," which he thought was best to wait for version 0.11.There is also a query related to current dust change handling and a suggested feature related to dusting in Bitcoin Core. Wladimir confirms that floating/smart fees have been merged into Core 0.10 via two GitHub pull requests. Wladimir proposed a plan for the release of Bitcoin 0.10, suggesting splitting off a 0.10 branch on November 18th and releasing 10.0rc1 on December 1st to start the Release Candidate cycle. The RC cycle would run until no critical problems are found, with the final release expected no later than January 2015. Major work that needed to be merged before November 18th included BIP62, Verification library, Gitian descriptors overhaul, Autoprune, adding "warmup mode" for RPC server, and adding unauthenticated HTTP REST interface.On October 26, 2014, a user named odinn inquired about transaction fee changes and txconfirmtarget in Bitcoin Core 0.10. In response, Wladimir confirmed that the floating/smart fees had been merged into Core 0.10 through two GitHub pull requests.In an email conversation, a user named Q asked for clarification regarding transaction fee changes and txconfirmtarget described in the release notes for Bitcoin Core 0.10. Wladimir responds to this by proposing a timeline for the release of 0.10, mentioning that any pending development for 0.10 should be merged before November 18th. Major work that he is aware of includes BIP62, Verification library, Gitian descriptors overhaul, Autoprune, adding "warmup mode" for RPC server, and adding unauthenticated HTTP REST interface. He encourages users to help along the development process by participating in testing and reviewing the mentioned pull requests, or just by testing master and reporting bugs and regressions.The Bitcoin Core developers are planning to release version 0.10 of the software by January 2015. In order to meet this deadline, major developments that have already been proposed need to be merged before November 18th. The delay in the release of version 0.10 was 2014-10-27T11:37:47+00:00 + Melvin Carvalho suggested creating a Bitcoin Improvement Proposal (BIP) as a way to put forth ideas and proposals for the development of Bitcoin. The new REST interface was seen as a good starting point for further discussion, as it already exports information that is available in Bitcoin Core's internals. However, it will not be developed into a full-fledged block explorer. Feedback on the HTTP headers and form of the REST interface was welcomed, with plans to add last-modified and etag headers. There are also proposals to export UTXOs and rebuild the RPC server to something multithreaded.In an email conversation between Melvin and Wladimir, Melvin asked for documentation on the REST API for electronic coins, which he was also working on. Wladimir referred him to the opening post by Jeff Garzik, which contained some documentation on how to use the API. However, there was currently no write-up about the current functionality in the release notes. Melvin offered to help with documentation. Melvin also asked about the stability of version 1 of the API going forward and whether or not there would be support to develop this interface into something that would be W3C standards compliant. Wladimir responded saying that it's not too late to make changes to version 1 as it hasn't been merged yet. He mentioned that a W3C standard takes a long time to come through, but it may be more useful to have the API available rather than wait for the API to be standardized. Wladimir noted that they are only interested in exposing read-only, public data that is already available in Bitcoin Core's internals. They are not aiming to add a fully-fledged block explorer with address indexes, although that could be part of the standard if it allows implementations to support just a subset. Finally, Wladimir suggested that Melvin coordinate his efforts with Jeff Garzik and consider putting down some thoughts and proposals in a BIP.Another user named Luke Dashjr reached out to Wladimir, asking for his opinion on what is ready and not too risky to be included in version 0.10 of Bitcoin Core. Luke mentioned that they needed a bug fix for submitblock, CreateNewBlock, and miner_tests. He also suggested introducing CNodePolicy for putting isolated node policy code. Harmless changes including support for returning specific rejection reasons, support for BIP 23 block proposal, elaborating on signverify message dialog warning, and further commits to merge after the introduction of CNodePolicy were also proposed. The miners requested enabling customization of node policy for data carrier data size with a low-risk configuration change. Wladimir approved all the changes except for the full-blown "miner policy class," which he thought was best to wait for version 0.11.There is also a query related to current dust change handling and a suggested feature related to dusting in Bitcoin Core. Wladimir confirms that floating/smart fees have been merged into Core 0.10 via two GitHub pull requests. Wladimir proposed a plan for the release of Bitcoin 0.10, suggesting splitting off a 0.10 branch on November 18th and releasing 10.0rc1 on December 1st to start the Release Candidate cycle. The RC cycle would run until no critical problems are found, with the final release expected no later than January 2015. Major work that needed to be merged before November 18th included BIP62, Verification library, Gitian descriptors overhaul, Autoprune, adding "warmup mode" for RPC server, and adding unauthenticated HTTP REST interface.On October 26, 2014, a user named odinn inquired about transaction fee changes and txconfirmtarget in Bitcoin Core 0.10. In response, Wladimir confirmed that the floating/smart fees had been merged into Core 0.10 through two GitHub pull requests.In an email conversation, a user named Q asked for clarification regarding transaction fee changes and txconfirmtarget described in the release notes for Bitcoin Core 0.10. Wladimir responds to this by proposing a timeline for the release of 0.10, mentioning that any pending development for 0.10 should be merged before November 18th. Major work that he is aware of includes BIP62, Verification library, Gitian descriptors overhaul, Autoprune, adding "warmup mode" for RPC server, and adding unauthenticated HTTP REST interface. He encourages users to help along the development process by participating in testing and reviewing the mentioned pull requests, or just by testing master and reporting bugs and regressions.The Bitcoin Core developers are planning to release version 0.10 of the software by January 2015. In order to meet this deadline, major developments that have already been proposed need to be merged before November 18th. The delay in the release of version 0.10 was - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_DS-Deprecation-Window.xml b/static/bitcoin-dev/Oct_2014/combined_DS-Deprecation-Window.xml index a28d805627..ac99699337 100644 --- a/static/bitcoin-dev/Oct_2014/combined_DS-Deprecation-Window.xml +++ b/static/bitcoin-dev/Oct_2014/combined_DS-Deprecation-Window.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - DS Deprecation Window - 2023-08-01T10:34:15.122397+00:00 + 2025-10-11T22:12:30.675101+00:00 + python-feedgen Tom Harding 2014-11-06 23:50:53+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - DS Deprecation Window - 2023-08-01T10:34:15.122397+00:00 + 2025-10-11T22:12:30.675294+00:00 - A new section called "Confidence to include tx1" has been added to the GitHub repository for dgenr8's out-there project. The section discusses a potential attack on miners, in which a miner excludes any transaction that was first seen less than 30 seconds ago or double spent less than 30 seconds after it was first seen. The post mentions that if a miner were to perform this action, they should expect five of 10,000 nodes to delay their block. Hal Finney and Tom Harding commented on the idea, with Finney stating that it would need careful analysis and Harding suggesting that it may be possible to quantify and target the risk of including tx1.Gregory Maxwell has proposed an attack on Bitcoin in which a malicious miner can flood other miners with orthogonal double spends that he doesn't mine himself. This attack is based on transmitting three transactions to two miners at the same time, creating a situation where Miner A knows about tx1a before Miner B, and Miner B delays his block until he knows about tx1a. The attacker tries to create a conflict that only affects everyone else except Miner A. However, Miner A can neutralize his risk by excluding any tx1 known to be double-spent. The success of the attack depends on the timing between the malicious transactions. If they are sent 10 seconds apart, the attack has little chance of success. It will be possible to quantify and target the risk of including tx1a based on the time gap to tx2.In an online discussion on Bitcoin forums, user Tom Harding expressed caution about miners including a double-spend in their block. He mentioned several factors that could mitigate the risk, such as the time offset from the first spend received and most other nodes having seen the transaction. Another user named Matt raised concerns about the proposal, and two other users replied with additional insights.In an email conversation, Tom Harding acknowledged that without double-spend relay, a miner would not be able to detect conflicting transactions. He also stated that even with double-spend relay, the miner cannot be sure and may choose to include no transactions at all to be safe. This is because a malicious miner can flood the network with orthogonal double spends.In a conversation between Matt and Tom Harding, it was discussed that without double-spend relay, miners will not know about conflicting transactions. Tom plans to add first-double-spends relay according to a specific proposal. However, if a miner includes a double-spend in their block, they have to be very careful. They hope that only a small fraction of the network will delay their block based on the time offset from the first spend they received. Additionally, most other nodes should see their transaction. The best course of action for a miner is to exclude fast transactions and connect to everyone on the network to look for double-spends.The delay in relaying/accepting blocks based on local information is considered a bad idea as it can lead to the splitting of the network. Miners are incentivized to connect with everyone on the network and look for double-spends to avoid being delayed. Tom Harding proposed a solution to improve the ability of bitcoin users to rely on unconfirmed transactions without the need for hard or soft forks. The proposal has not been implemented yet, and feedback from Bitcoin Dev is appreciated. 2014-11-06T23:50:53+00:00 + A new section called "Confidence to include tx1" has been added to the GitHub repository for dgenr8's out-there project. The section discusses a potential attack on miners, in which a miner excludes any transaction that was first seen less than 30 seconds ago or double spent less than 30 seconds after it was first seen. The post mentions that if a miner were to perform this action, they should expect five of 10,000 nodes to delay their block. Hal Finney and Tom Harding commented on the idea, with Finney stating that it would need careful analysis and Harding suggesting that it may be possible to quantify and target the risk of including tx1.Gregory Maxwell has proposed an attack on Bitcoin in which a malicious miner can flood other miners with orthogonal double spends that he doesn't mine himself. This attack is based on transmitting three transactions to two miners at the same time, creating a situation where Miner A knows about tx1a before Miner B, and Miner B delays his block until he knows about tx1a. The attacker tries to create a conflict that only affects everyone else except Miner A. However, Miner A can neutralize his risk by excluding any tx1 known to be double-spent. The success of the attack depends on the timing between the malicious transactions. If they are sent 10 seconds apart, the attack has little chance of success. It will be possible to quantify and target the risk of including tx1a based on the time gap to tx2.In an online discussion on Bitcoin forums, user Tom Harding expressed caution about miners including a double-spend in their block. He mentioned several factors that could mitigate the risk, such as the time offset from the first spend received and most other nodes having seen the transaction. Another user named Matt raised concerns about the proposal, and two other users replied with additional insights.In an email conversation, Tom Harding acknowledged that without double-spend relay, a miner would not be able to detect conflicting transactions. He also stated that even with double-spend relay, the miner cannot be sure and may choose to include no transactions at all to be safe. This is because a malicious miner can flood the network with orthogonal double spends.In a conversation between Matt and Tom Harding, it was discussed that without double-spend relay, miners will not know about conflicting transactions. Tom plans to add first-double-spends relay according to a specific proposal. However, if a miner includes a double-spend in their block, they have to be very careful. They hope that only a small fraction of the network will delay their block based on the time offset from the first spend they received. Additionally, most other nodes should see their transaction. The best course of action for a miner is to exclude fast transactions and connect to everyone on the network to look for double-spends.The delay in relaying/accepting blocks based on local information is considered a bad idea as it can lead to the splitting of the network. Miners are incentivized to connect with everyone on the network and look for double-spends to avoid being delayed. Tom Harding proposed a solution to improve the ability of bitcoin users to rely on unconfirmed transactions without the need for hard or soft forks. The proposal has not been implemented yet, and feedback from Bitcoin Dev is appreciated. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Death-by-halving-pro-active-proposals-.xml b/static/bitcoin-dev/Oct_2014/combined_Death-by-halving-pro-active-proposals-.xml index 1b28c7d7a3..0783ef5050 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Death-by-halving-pro-active-proposals-.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Death-by-halving-pro-active-proposals-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Death by halving (pro-active proposals) - 2023-08-01T10:35:24.185672+00:00 + 2025-10-11T22:12:47.687390+00:00 + python-feedgen Jeff Garzik 2014-10-29 17:25:19+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Death by halving (pro-active proposals) - 2023-08-01T10:35:24.186670+00:00 + 2025-10-11T22:12:47.687567+00:00 - A future use of the chain discussed on a Bitcoin forum involves securing other chains through merged-mining. This concept relies on obtaining chain hashes from a miner and receiving payment from the chain. The user envisions a future where one block secures 10,000 chains. In October 2014, Bitcoin core developer Jeff Garzik and Sergio Lerner brainstormed solutions to mitigate the impact of subsidy halving. They proposed incentivizing SHA-256 merge-mining instead of discouraging alt-coins based on SHA-256. Additionally, they suggested creating a donation pool where miners would contribute 1% of their revenue to compensate miners during the first month after the reward halving. These measures would result in a 20% increase in block earnings for that period.The author of the post suggests proactive measures to address the challenges posed by subsidy halving on mining. They propose merged-mining as a means to boost miners' profits and offset reduced rewards. Rather than discouraging alt-coins, the author advocates for encouraging merge-mining on SHA-256. Another proposal is the establishment of a donation pool, wherein miners would donate 1% of their revenue to support fellow miners in the initial month following the reward halving. By implementing this scheme, block earnings would see a 20% surge throughout that timeframe.The author acknowledges that convincing miners to participate in these initiatives may be challenging. However, they propose an automated approach using nLockTime freeze of transactions with high fees, eliminating the need for a trusted third party. By doing so, miners would not need to rely on the willingness of others to contribute to the donation pool. In conclusion, the author invites further proposals to address the potential consequences of subsidy halving on mining operations. 2014-10-29T17:25:19+00:00 + A future use of the chain discussed on a Bitcoin forum involves securing other chains through merged-mining. This concept relies on obtaining chain hashes from a miner and receiving payment from the chain. The user envisions a future where one block secures 10,000 chains. In October 2014, Bitcoin core developer Jeff Garzik and Sergio Lerner brainstormed solutions to mitigate the impact of subsidy halving. They proposed incentivizing SHA-256 merge-mining instead of discouraging alt-coins based on SHA-256. Additionally, they suggested creating a donation pool where miners would contribute 1% of their revenue to compensate miners during the first month after the reward halving. These measures would result in a 20% increase in block earnings for that period.The author of the post suggests proactive measures to address the challenges posed by subsidy halving on mining. They propose merged-mining as a means to boost miners' profits and offset reduced rewards. Rather than discouraging alt-coins, the author advocates for encouraging merge-mining on SHA-256. Another proposal is the establishment of a donation pool, wherein miners would donate 1% of their revenue to support fellow miners in the initial month following the reward halving. By implementing this scheme, block earnings would see a 20% surge throughout that timeframe.The author acknowledges that convincing miners to participate in these initiatives may be challenging. However, they propose an automated approach using nLockTime freeze of transactions with high fees, eliminating the need for a trusted third party. By doing so, miners would not need to rely on the willingness of others to contribute to the donation pool. In conclusion, the author invites further proposals to address the potential consequences of subsidy halving on mining operations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Decreasing-block-propagation-time.xml b/static/bitcoin-dev/Oct_2014/combined_Decreasing-block-propagation-time.xml index a3a9c09598..dc287f061e 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Decreasing-block-propagation-time.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Decreasing-block-propagation-time.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Decreasing block propagation time - 2023-08-01T10:22:59.767011+00:00 + 2025-10-11T22:12:26.427029+00:00 + python-feedgen Matt Corallo 2014-10-02 04:46:43+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Decreasing block propagation time - 2023-08-01T10:22:59.767011+00:00 + 2025-10-11T22:12:26.427155+00:00 - In a Bitcoin-development mailing list, a user named Rebroad raised a query regarding the implementation of an idea mentioned in an article found at https://bitcointalk.org/index.php?topic=145066.0. The user expressed their admiration for the idea but sought clarification on the factors that were hindering its implementation. They also inquired whether coding or writing a Bitcoin Improvement Proposal (BIP) was necessary for progressing with the idea. Responding to this query, another user named Matt acknowledged that the idea being discussed was a variation of one previously mentioned on the Bitcointalk forum. However, Matt did not provide any additional details or links pertaining to the earlier discussion. It is worth mentioning that the email concluded with an advertisement for EventLog Analyzer, a tool designed to facilitate compliance with PCI DSS 3.0 standards.The provided link directs to a discussion forum where the author seeks information about the proposed idea's implementation and expresses interest in understanding the reasons behind any delays. Additionally, the author wonders whether coding the idea or creating a Bitcoin Improvement Proposal is a prerequisite. Notably, no further context or details are provided in the given text. 2014-10-02T04:46:43+00:00 + In a Bitcoin-development mailing list, a user named Rebroad raised a query regarding the implementation of an idea mentioned in an article found at https://bitcointalk.org/index.php?topic=145066.0. The user expressed their admiration for the idea but sought clarification on the factors that were hindering its implementation. They also inquired whether coding or writing a Bitcoin Improvement Proposal (BIP) was necessary for progressing with the idea. Responding to this query, another user named Matt acknowledged that the idea being discussed was a variation of one previously mentioned on the Bitcointalk forum. However, Matt did not provide any additional details or links pertaining to the earlier discussion. It is worth mentioning that the email concluded with an advertisement for EventLog Analyzer, a tool designed to facilitate compliance with PCI DSS 3.0 standards.The provided link directs to a discussion forum where the author seeks information about the proposed idea's implementation and expresses interest in understanding the reasons behind any delays. Additionally, the author wonders whether coding the idea or creating a Bitcoin Improvement Proposal is a prerequisite. Notably, no further context or details are provided in the given text. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Fwd-Bug-24444-Named-Curve-Registry-adding-secp256k1-.xml b/static/bitcoin-dev/Oct_2014/combined_Fwd-Bug-24444-Named-Curve-Registry-adding-secp256k1-.xml index f3ea3e33fc..c9077496a3 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Fwd-Bug-24444-Named-Curve-Registry-adding-secp256k1-.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Fwd-Bug-24444-Named-Curve-Registry-adding-secp256k1-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: [Bug 24444] Named Curve Registry (adding secp256k1) - 2023-08-01T10:25:24.252520+00:00 + 2025-10-11T22:12:28.552661+00:00 + python-feedgen Melvin Carvalho 2014-10-14 08:57:58+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Fwd: [Bug 24444] Named Curve Registry (adding secp256k1) - 2023-08-01T10:25:24.252520+00:00 + 2025-10-11T22:12:28.552826+00:00 - On October 13, 2014, Melvin Carvalho filed an issue related to adding secp256k1 into Web Crypto API. The addition of secp256k1 will be implemented natively in some web browsers. If there is any feedback from crypto implementers, they can add comments to the thread provided. Myron Davis reopened the issue and mentioned that secp256k1 is supported in several SSL/TLS libraries such as Botan, NSS, openssl, LibreSSL, PolarSSL, and JSSE. Davis also talked about how secp256k1 curve has some great advantages compared to the three other curves which do not define how they were generated. The curve has had lots of hardware and software supporting it. With the discovery of backdoors in NIST's random number generator, Davis would like to see a determined parameter curve instead of a "random" curve option. The email thread includes links to related bugs on Curve25519 and some MS Research curves that generated far more discussion.This is an issue filed for adding secp256k1 into Web Crypto API, which will be implemented natively in some web browsers. Myron Davis has requested to look at it again as secp256k1 is supported in several SSL/TLS libraries including Botan, NSS, openssl, LibreSSL, PolarSSL and JSSE. The other three curves have parameters that do not define how they were generated. On the other hand, the secp256k1 curve has advantages in faster signature verification and how the values were determined for the curve. With the discovery of backdoor's in NIST's random number generator, there is a need for a determined parameter curve instead of a "random" curve option. If there is any feedback from crypto implementers, readers can add comments to the thread provided. 2014-10-14T08:57:58+00:00 + On October 13, 2014, Melvin Carvalho filed an issue related to adding secp256k1 into Web Crypto API. The addition of secp256k1 will be implemented natively in some web browsers. If there is any feedback from crypto implementers, they can add comments to the thread provided. Myron Davis reopened the issue and mentioned that secp256k1 is supported in several SSL/TLS libraries such as Botan, NSS, openssl, LibreSSL, PolarSSL, and JSSE. Davis also talked about how secp256k1 curve has some great advantages compared to the three other curves which do not define how they were generated. The curve has had lots of hardware and software supporting it. With the discovery of backdoors in NIST's random number generator, Davis would like to see a determined parameter curve instead of a "random" curve option. The email thread includes links to related bugs on Curve25519 and some MS Research curves that generated far more discussion.This is an issue filed for adding secp256k1 into Web Crypto API, which will be implemented natively in some web browsers. Myron Davis has requested to look at it again as secp256k1 is supported in several SSL/TLS libraries including Botan, NSS, openssl, LibreSSL, PolarSSL and JSSE. The other three curves have parameters that do not define how they were generated. On the other hand, the secp256k1 curve has advantages in faster signature verification and how the values were determined for the curve. With the discovery of backdoor's in NIST's random number generator, there is a need for a determined parameter curve instead of a "random" curve option. If there is any feedback from crypto implementers, readers can add comments to the thread provided. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Fwd-death-by-halving.xml b/static/bitcoin-dev/Oct_2014/combined_Fwd-death-by-halving.xml index 8e93cdccd8..a578a90278 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Fwd-death-by-halving.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Fwd-death-by-halving.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: death by halving - 2023-08-01T10:35:08.967822+00:00 + 2025-10-11T22:12:34.923703+00:00 + python-feedgen Ferdinando M. Ametrano 2014-10-28 22:43:08+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Fwd: death by halving - 2023-08-01T10:35:08.967822+00:00 + 2025-10-11T22:12:34.923869+00:00 - In an email exchange on October 28, 2014, Gregory Maxwell corrected a previous statement about the cost per block for Bitcoin mining, stating that the actual cost per block is closer to $2500 USD rather than $100 USD. This clarification helped to avoid any misunderstandings regarding the true cost of mining Bitcoin.Another user thanked Maxwell for his insights into the halving process of Bitcoin and acknowledged the time he spent addressing the issue.Thomas Zander called out an individual in an email exchange on October 28, 2014, for not having read through the archives where certain ideas had been discussed and a consensus reached. The individual responded by explaining that they hadn't started the thread and requested a link to the discussion instead of being dismissed harshly.During a discussion thread on October 28, 2014, Ferdinando M. Ametrano expressed surprise at the lack of consideration for basic economic principles in mining. Another participant cautioned against dismissing Ametrano's thoughts as a rejection of broader economic considerations, explaining that these had already been discussed and agreed upon in previous archives. The responder defended the community's decision not to rehash old arguments, emphasizing that this did not mean established economic principles were being ignored.A user named Neil suggested in an email conversation that a halving in Bitcoin's block reward is economically similar to a halving in price. The predictability of the halving can cause miners to alter their buying behavior significantly, reducing hashpower on the day. Miners may purchase less hardware as they approach the revenue drop, expecting it to pay for itself before the halving. Rational miners would cease purchasing unprofitable hardware as margins become low. The focus would shift towards cost-effective hash power, and older units would not be replaced as they break. Either cost-effective hardware needs to appear or difficulty would stall before the halving occurs.Neil also pointed out in another email conversation that a halving in Bitcoin's price is economically similar to a halving of the block reward. As fees consume a larger portion of mining revenue, there is less room for profits. Neil expressed concern about the lack of consideration for basic economic principles in Bitcoin mining and warned about the potential for an oligopoly or monopoly in the future.In an email conversation between Jérémie Dubois-Lacoste and Ferdinando M. Ametrano, Dubois-Lacoste argued that repeated discussions on a topic do not make it irrelevant. However, he acknowledged that discussions can become pointless when no new information is presented. Ametrano responded by emphasizing that every post on the topic consumes the time of many people and encouraged Dubois-Lacoste to refine his posts for greater productivity. He disagreed with Dubois-Lacoste's assertion that Bitcoin mining is not a serious concern and provided calculations to support his argument.The author of the context discussed the economic implications of a halving in price versus a halving in rewards for Bitcoin mining. The author noted that as block rewards are cut in half, fees become a larger portion of miners' revenue. Coincidentally, the price of Bitcoin had also decreased by 50% from July to October 2014. However, the author did not believe this decrease in price was significant enough to cause a corresponding drop in mining difficulty.The discussion surrounding the relevance of halving in Bitcoin continues, with some arguing that past incidents do not guarantee a disturbance-free future. Changing environmental conditions and the increasing dominance of for-profit companies in mining make this argument relevant. It is important to discuss the potential impact of halving on the mining market rather than dismissing it outright. While encouraging investment in mining infrastructure through halving has its benefits, the security of the system and the economic incentives of miners must also be considered. The complexity of the Bitcoin system cannot be reduced to just the subsidy schedule.The context also includes a discussion thread where the author expresses their opinion that a proposed change related to the subsidy schedule of Bitcoin is a waste of time. The author argues that there is more complexity to the system than just the subsidy schedule and raises questions about what makes Bitcoin secure and the boundaries of its effectiveness. The answer lies in proofs of work produced by miners, as they have economic incentives to play by the rules rather than perform attacks.Overall, the context covers various discussions and exchanges related to the cost per block for Bitcoin mining, the economic implications of halving in rewards or price, the consideration of basic economic principles, the ongoing discussion on the relevance of halving, and the complexity of the Bitcoin system beyond just the subsidy schedule. 2014-10-28T22:43:08+00:00 + In an email exchange on October 28, 2014, Gregory Maxwell corrected a previous statement about the cost per block for Bitcoin mining, stating that the actual cost per block is closer to $2500 USD rather than $100 USD. This clarification helped to avoid any misunderstandings regarding the true cost of mining Bitcoin.Another user thanked Maxwell for his insights into the halving process of Bitcoin and acknowledged the time he spent addressing the issue.Thomas Zander called out an individual in an email exchange on October 28, 2014, for not having read through the archives where certain ideas had been discussed and a consensus reached. The individual responded by explaining that they hadn't started the thread and requested a link to the discussion instead of being dismissed harshly.During a discussion thread on October 28, 2014, Ferdinando M. Ametrano expressed surprise at the lack of consideration for basic economic principles in mining. Another participant cautioned against dismissing Ametrano's thoughts as a rejection of broader economic considerations, explaining that these had already been discussed and agreed upon in previous archives. The responder defended the community's decision not to rehash old arguments, emphasizing that this did not mean established economic principles were being ignored.A user named Neil suggested in an email conversation that a halving in Bitcoin's block reward is economically similar to a halving in price. The predictability of the halving can cause miners to alter their buying behavior significantly, reducing hashpower on the day. Miners may purchase less hardware as they approach the revenue drop, expecting it to pay for itself before the halving. Rational miners would cease purchasing unprofitable hardware as margins become low. The focus would shift towards cost-effective hash power, and older units would not be replaced as they break. Either cost-effective hardware needs to appear or difficulty would stall before the halving occurs.Neil also pointed out in another email conversation that a halving in Bitcoin's price is economically similar to a halving of the block reward. As fees consume a larger portion of mining revenue, there is less room for profits. Neil expressed concern about the lack of consideration for basic economic principles in Bitcoin mining and warned about the potential for an oligopoly or monopoly in the future.In an email conversation between Jérémie Dubois-Lacoste and Ferdinando M. Ametrano, Dubois-Lacoste argued that repeated discussions on a topic do not make it irrelevant. However, he acknowledged that discussions can become pointless when no new information is presented. Ametrano responded by emphasizing that every post on the topic consumes the time of many people and encouraged Dubois-Lacoste to refine his posts for greater productivity. He disagreed with Dubois-Lacoste's assertion that Bitcoin mining is not a serious concern and provided calculations to support his argument.The author of the context discussed the economic implications of a halving in price versus a halving in rewards for Bitcoin mining. The author noted that as block rewards are cut in half, fees become a larger portion of miners' revenue. Coincidentally, the price of Bitcoin had also decreased by 50% from July to October 2014. However, the author did not believe this decrease in price was significant enough to cause a corresponding drop in mining difficulty.The discussion surrounding the relevance of halving in Bitcoin continues, with some arguing that past incidents do not guarantee a disturbance-free future. Changing environmental conditions and the increasing dominance of for-profit companies in mining make this argument relevant. It is important to discuss the potential impact of halving on the mining market rather than dismissing it outright. While encouraging investment in mining infrastructure through halving has its benefits, the security of the system and the economic incentives of miners must also be considered. The complexity of the Bitcoin system cannot be reduced to just the subsidy schedule.The context also includes a discussion thread where the author expresses their opinion that a proposed change related to the subsidy schedule of Bitcoin is a waste of time. The author argues that there is more complexity to the system than just the subsidy schedule and raises questions about what makes Bitcoin secure and the boundaries of its effectiveness. The answer lies in proofs of work produced by miners, as they have economic incentives to play by the rules rather than perform attacks.Overall, the context covers various discussions and exchanges related to the cost per block for Bitcoin mining, the economic implications of halving in rewards or price, the consideration of basic economic principles, the ongoing discussion on the relevance of halving, and the complexity of the Bitcoin system beyond just the subsidy schedule. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Increasing-regularity-of-block-times-.xml b/static/bitcoin-dev/Oct_2014/combined_Increasing-regularity-of-block-times-.xml index b2a8a05a9d..0460d9b6f0 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Increasing-regularity-of-block-times-.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Increasing-regularity-of-block-times-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Increasing regularity of block times? - 2023-08-01T10:35:39.239977+00:00 + 2025-10-11T22:12:13.666727+00:00 + python-feedgen Rusty Russell 2014-10-31 03:31:12+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Increasing regularity of block times? - 2023-08-01T10:35:39.239977+00:00 + 2025-10-11T22:12:13.666903+00:00 - In an email thread on October 30, 2014, Rusty Russell proposed an algorithm to limit confirmation latency in Bitcoin by allowing weaker blocks after a certain time. He asked if anyone had considered this before or knew of any flaws. Gregory Maxwell responded by stating that irregularity is required for convergence, as exact intervals would cause fragmentation and prevent convergence. He also mentioned that the variance allows the network to converge. Bitcoin testnet has implemented a rule that allows lower difficulty blocks after a delay of 20 minutes, but it is not secure. It was noted that at least one altcoin has copied this behavior and been exploited. If faster evidence of the network working on a particular transaction set is needed, mechanisms like the p2pool sharechain can provide it. Citations were promised to be provided later.The Bitcoin testnet is a network that allows developers to experiment with new features and test their applications without risking actual bitcoins. On October 30th, 2014, Rusty Russell proposed an algorithm to limit confirmation latency by allowing weaker blocks after a certain time. He shared the details of his proposal via a blog post. Jeff Garzik, a Bitcoin core developer and open source evangelist, signed off the email chain with his signature information.In a forum post, Rusty Russell shared his thoughts on an algorithm to limit confirmation latency by allowing weaker blocks after a certain time. He wondered if anyone had considered this before or if there were any flaws in the scheme. For more details on how this algorithm would work, Russell provided a link to his website where he outlines the "gory details" of the process. 2014-10-31T03:31:12+00:00 + In an email thread on October 30, 2014, Rusty Russell proposed an algorithm to limit confirmation latency in Bitcoin by allowing weaker blocks after a certain time. He asked if anyone had considered this before or knew of any flaws. Gregory Maxwell responded by stating that irregularity is required for convergence, as exact intervals would cause fragmentation and prevent convergence. He also mentioned that the variance allows the network to converge. Bitcoin testnet has implemented a rule that allows lower difficulty blocks after a delay of 20 minutes, but it is not secure. It was noted that at least one altcoin has copied this behavior and been exploited. If faster evidence of the network working on a particular transaction set is needed, mechanisms like the p2pool sharechain can provide it. Citations were promised to be provided later.The Bitcoin testnet is a network that allows developers to experiment with new features and test their applications without risking actual bitcoins. On October 30th, 2014, Rusty Russell proposed an algorithm to limit confirmation latency by allowing weaker blocks after a certain time. He shared the details of his proposal via a blog post. Jeff Garzik, a Bitcoin core developer and open source evangelist, signed off the email chain with his signature information.In a forum post, Rusty Russell shared his thoughts on an algorithm to limit confirmation latency by allowing weaker blocks after a certain time. He wondered if anyone had considered this before or if there were any flaws in the scheme. For more details on how this algorithm would work, Russell provided a link to his website where he outlines the "gory details" of the process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Malleable-booleans.xml b/static/bitcoin-dev/Oct_2014/combined_Malleable-booleans.xml index 618600292a..5602a54e8d 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Malleable-booleans.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Malleable-booleans.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Malleable booleans - 2023-08-01T10:25:48.591859+00:00 + 2025-10-11T22:12:24.297021+00:00 + python-feedgen Peter Todd 2014-10-14 19:45:18+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Malleable booleans - 2023-08-01T10:25:48.591859+00:00 + 2025-10-11T22:12:24.297156+00:00 - In a discussion on the Bitcoin-dev forum, Pieter Wuille argues that requiring canonical bool testing for all boolean-using opcodes would save a significant amount of bytes. He suggests that if a script author fails to properly 'bool-ize' every boolean-using path that can have non-minimal encodings, one can always create a nVersion=1 transaction manually to spend the output and prevent loss of funds. However, he acknowledges an opposing argument that there may not be many use cases where BOOLAND and BOOLOR are applied to unsanitized input from scriptSig.Pieter Todd adds to the conversation by stating his intention to only allow 0 and 1 as booleans, resulting in script failure if any other stack element is evaluated as a boolean. This applies to inputs to OP_IF and OP_NOTIF, inputs to OP_BOOLAND and OP_BOOLOR, and the resulting final element on the stack for validity. His goal is to ensure that there is an equivalent non-malleable script for every possible script.Pieter Wuille, a Bitcoin developer, discovers another type of malleability while working on a BIP62 implementation. He notes that any byte array with non-zero bytes in it (except for the highest bit of the last byte) is interpreted as true and anything else as false in the code for dealing with booleans. However, this interpretation of booleans is inconsistent and scripts using booleans as inputs will be inherently malleable. In response, Wuille proposes changing BIP62 to require interpreted booleans to be of minimal encoded size to solve the problem.Another developer, Peter Todd, comments that relying on BIP62 for specialty contract applications is risky and argues that having canonical bool testing in every boolean-using opcode saves a lot of bytes. In an email thread, Thomas Zander raises a concern about the inherent malleability of scripts that use booleans as inputs. Pieter Wuille had previously mentioned this issue. Zander gives an example of assigning "2" to a native C++ bool, resulting in neither true nor false being hit when checked. However, Wladimir clarifies that C++ booleans are protected against this and provides code to demonstrate it. The code prints 'It is true' and also shows how `bool(something)` can be used as an equivalent of x != 0.In another email thread, Thomas Zander asks about rejecting a script where a boolean value is not explicitly set to zero or one. While the context of Zander's question is unclear, enforcing strict boolean values in programming is a common practice that improves code reliability and readability.Overall, the discussions revolve around the malleability issues with scripts using booleans as inputs. Proposed solutions include requiring minimal encoded size for interpreted booleans and enforcing strict boolean values in programming. These changes aim to improve the reliability and consistency of Bitcoin scripts. 2014-10-14T19:45:18+00:00 + In a discussion on the Bitcoin-dev forum, Pieter Wuille argues that requiring canonical bool testing for all boolean-using opcodes would save a significant amount of bytes. He suggests that if a script author fails to properly 'bool-ize' every boolean-using path that can have non-minimal encodings, one can always create a nVersion=1 transaction manually to spend the output and prevent loss of funds. However, he acknowledges an opposing argument that there may not be many use cases where BOOLAND and BOOLOR are applied to unsanitized input from scriptSig.Pieter Todd adds to the conversation by stating his intention to only allow 0 and 1 as booleans, resulting in script failure if any other stack element is evaluated as a boolean. This applies to inputs to OP_IF and OP_NOTIF, inputs to OP_BOOLAND and OP_BOOLOR, and the resulting final element on the stack for validity. His goal is to ensure that there is an equivalent non-malleable script for every possible script.Pieter Wuille, a Bitcoin developer, discovers another type of malleability while working on a BIP62 implementation. He notes that any byte array with non-zero bytes in it (except for the highest bit of the last byte) is interpreted as true and anything else as false in the code for dealing with booleans. However, this interpretation of booleans is inconsistent and scripts using booleans as inputs will be inherently malleable. In response, Wuille proposes changing BIP62 to require interpreted booleans to be of minimal encoded size to solve the problem.Another developer, Peter Todd, comments that relying on BIP62 for specialty contract applications is risky and argues that having canonical bool testing in every boolean-using opcode saves a lot of bytes. In an email thread, Thomas Zander raises a concern about the inherent malleability of scripts that use booleans as inputs. Pieter Wuille had previously mentioned this issue. Zander gives an example of assigning "2" to a native C++ bool, resulting in neither true nor false being hit when checked. However, Wladimir clarifies that C++ booleans are protected against this and provides code to demonstrate it. The code prints 'It is true' and also shows how `bool(something)` can be used as an equivalent of x != 0.In another email thread, Thomas Zander asks about rejecting a script where a boolean value is not explicitly set to zero or one. While the context of Zander's question is unclear, enforcing strict boolean values in programming is a common practice that improves code reliability and readability.Overall, the discussions revolve around the malleability issues with scripts using booleans as inputs. Proposed solutions include requiring minimal encoded size for interpreted booleans and enforcing strict boolean values in programming. These changes aim to improve the reliability and consistency of Bitcoin scripts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Proposal-for-extra-nonce-in-block-header.xml b/static/bitcoin-dev/Oct_2014/combined_Proposal-for-extra-nonce-in-block-header.xml index 97f16aee03..88d5a67eaa 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Proposal-for-extra-nonce-in-block-header.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Proposal-for-extra-nonce-in-block-header.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposal for extra nonce in block header - 2023-08-01T09:05:29.704021+00:00 + 2025-10-11T22:12:45.563965+00:00 + python-feedgen Timo Hanke 2014-10-18 18:25:59+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Proposal for extra nonce in block header - 2023-08-01T09:05:29.705063+00:00 + 2025-10-11T22:12:45.564124+00:00 - In 2014, Timo Hanke proposed a Bitcoin Improvement Proposal (BIP) to address the issue of miners finding cheap and non-standard ways to generate new work in the Bitcoin protocol. The proposal suggests reassigning two bytes from the version field of the block header to a new extra nonce field. This would allow miners to create new work without altering the transaction tree while protecting the version and timestamp fields in the block header.Currently, the extra nonce is part of the coinbase field of the generation transaction, which is always the first transaction of a block. By incrementing the extra nonce, a miner has to hash the coinbase transaction and recalculate the left-most branch of the merkle tree all the way to the merkle root. However, as the cost of pre-hashing decreases with the advancement of ASIC technology, miners are incentivized to find cheaper ways to create new work.The proposal suggests reducing the range of version numbers from 2^32 to 2^16 and designating the third and fourth bytes of the block header as legitimate space for an extra nonce. This would significantly reduce the incentive for miners to abuse the shortened version number. Additionally, this change would greatly reduce the bandwidth requirements of a blind pool protocol, as only the block header would need to be submitted to the miner.Old versions of the client will still accept blocks with the new extra nonce arrangement but will alert the user to upgrade. There is no need to introduce a new block version number or phase out old block versions. Overall, this proposal aims to provide miners with a cost-effective method of creating new work while maintaining the integrity of the Bitcoin protocol. 2014-10-18T18:25:59+00:00 + In 2014, Timo Hanke proposed a Bitcoin Improvement Proposal (BIP) to address the issue of miners finding cheap and non-standard ways to generate new work in the Bitcoin protocol. The proposal suggests reassigning two bytes from the version field of the block header to a new extra nonce field. This would allow miners to create new work without altering the transaction tree while protecting the version and timestamp fields in the block header.Currently, the extra nonce is part of the coinbase field of the generation transaction, which is always the first transaction of a block. By incrementing the extra nonce, a miner has to hash the coinbase transaction and recalculate the left-most branch of the merkle tree all the way to the merkle root. However, as the cost of pre-hashing decreases with the advancement of ASIC technology, miners are incentivized to find cheaper ways to create new work.The proposal suggests reducing the range of version numbers from 2^32 to 2^16 and designating the third and fourth bytes of the block header as legitimate space for an extra nonce. This would significantly reduce the incentive for miners to abuse the shortened version number. Additionally, this change would greatly reduce the bandwidth requirements of a blind pool protocol, as only the block header would need to be submitted to the miner.Old versions of the client will still accept blocks with the new extra nonce arrangement but will alert the user to upgrade. There is no need to introduce a new block version number or phase out old block versions. Overall, this proposal aims to provide miners with a cost-effective method of creating new work while maintaining the integrity of the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Proposed-BIP-status-changes.xml b/static/bitcoin-dev/Oct_2014/combined_Proposed-BIP-status-changes.xml index 9e700c5239..62b756b81e 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Proposed-BIP-status-changes.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Proposed-BIP-status-changes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed BIP status changes - 2023-08-01T10:26:14.555817+00:00 + 2025-10-11T22:12:22.174070+00:00 + python-feedgen Luke Dashjr 2014-10-16 06:46:21+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Proposed BIP status changes - 2023-08-01T10:26:14.556864+00:00 + 2025-10-11T22:12:22.174218+00:00 - In October 2014, a debate arose on the Bitcoin development mailing list regarding the discussion of changes to Bitcoin Improvement Proposals (BIPs). Wladimir, a prominent figure in the cryptocurrency community, argued that BIP changes should be discussed on the mailing list to ensure community consensus, as outlined in BIP1. This discussion highlighted the importance of community involvement and open dialogue in the development of cryptocurrency protocols. The adherence to established guidelines, such as BIP1, promotes transparency and collaboration within the community.The world of cryptocurrencies recognizes the significance of BIP changes, which necessitate community consensus. According to BIP1, discussions regarding these changes should be held on the mailing list to ensure alignment among participants. Consequently, holding BIP discussions through GitHub pull requests is deemed inappropriate. Wladimir's statement regarding the appropriate forum for BIP discussions serves as a guiding principle for the community, enabling informed decision-making regarding project direction.On October 15, 2014, Wladimir proposed that several BIPs be moved to the Final state, as they had already been implemented and fixed. These BIPs include BIP 14, BIP 21, BIP 22, BIP 31, BIP 34, BIP 35, and BIP 37. Luke questioned this suggestion, expressing curiosity as to why the discussion was not taking place through a GitHub pull request instead of cluttering the mailing list.Wladimir announced on October 15, 2014, that several Bitcoin Improvement Proposals (BIPs) should be considered for their final state. These BIPs had already been implemented and fixed, requiring a new BIP amendment for any changes. The mentioned BIPs encompass various aspects, such as BIP Protocol Version and User Agent (BIP 14), URI Scheme (BIP 21), getblocktemplate - Fundamentals (BIP 22), Pong Message (BIP 31), Block v2, Height in coinbase (BIP 34), mempool message (BIP 35), and Bloom filtering (BIP 37). It is important to note that these BIPs have been widely implemented and are now considered fixed, necessitating future changes to be made through new BIP amendments. Wladimir sought feedback from the community on this announcement, confirming the successful implementation and standardization of these BIPs within the Bitcoin community.To summarize, the provided context revolves around the implementation and fixed status of Bitcoin Improvement Proposals (BIPs). Any modifications to these BIPs would require a new amendment. The mentioned BIPs, including BIP 14, BIP 21, BIP 22, BIP 31, BIP 34, BIP 35, and BIP 37, have already been widely implemented and are now considered standard within the Bitcoin community. The author seeks community feedback on whether these BIPs should be categorized as final. It is crucial to acknowledge that any changes to these BIPs would necessitate new amendments. 2014-10-16T06:46:21+00:00 + In October 2014, a debate arose on the Bitcoin development mailing list regarding the discussion of changes to Bitcoin Improvement Proposals (BIPs). Wladimir, a prominent figure in the cryptocurrency community, argued that BIP changes should be discussed on the mailing list to ensure community consensus, as outlined in BIP1. This discussion highlighted the importance of community involvement and open dialogue in the development of cryptocurrency protocols. The adherence to established guidelines, such as BIP1, promotes transparency and collaboration within the community.The world of cryptocurrencies recognizes the significance of BIP changes, which necessitate community consensus. According to BIP1, discussions regarding these changes should be held on the mailing list to ensure alignment among participants. Consequently, holding BIP discussions through GitHub pull requests is deemed inappropriate. Wladimir's statement regarding the appropriate forum for BIP discussions serves as a guiding principle for the community, enabling informed decision-making regarding project direction.On October 15, 2014, Wladimir proposed that several BIPs be moved to the Final state, as they had already been implemented and fixed. These BIPs include BIP 14, BIP 21, BIP 22, BIP 31, BIP 34, BIP 35, and BIP 37. Luke questioned this suggestion, expressing curiosity as to why the discussion was not taking place through a GitHub pull request instead of cluttering the mailing list.Wladimir announced on October 15, 2014, that several Bitcoin Improvement Proposals (BIPs) should be considered for their final state. These BIPs had already been implemented and fixed, requiring a new BIP amendment for any changes. The mentioned BIPs encompass various aspects, such as BIP Protocol Version and User Agent (BIP 14), URI Scheme (BIP 21), getblocktemplate - Fundamentals (BIP 22), Pong Message (BIP 31), Block v2, Height in coinbase (BIP 34), mempool message (BIP 35), and Bloom filtering (BIP 37). It is important to note that these BIPs have been widely implemented and are now considered fixed, necessitating future changes to be made through new BIP amendments. Wladimir sought feedback from the community on this announcement, confirming the successful implementation and standardization of these BIPs within the Bitcoin community.To summarize, the provided context revolves around the implementation and fixed status of Bitcoin Improvement Proposals (BIPs). Any modifications to these BIPs would require a new amendment. The mentioned BIPs, including BIP 14, BIP 21, BIP 22, BIP 31, BIP 34, BIP 35, and BIP 37, have already been widely implemented and are now considered standard within the Bitcoin community. The author seeks community feedback on whether these BIPs should be categorized as final. It is crucial to acknowledge that any changes to these BIPs would necessitate new amendments. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Request-for-review-testing-headers-first-synchronization-in-Bitcoin-Core.xml b/static/bitcoin-dev/Oct_2014/combined_Request-for-review-testing-headers-first-synchronization-in-Bitcoin-Core.xml index beacd6f454..e54f7684a9 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Request-for-review-testing-headers-first-synchronization-in-Bitcoin-Core.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Request-for-review-testing-headers-first-synchronization-in-Bitcoin-Core.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Request for review/testing: headers-first synchronization in Bitcoin Core - 2023-08-01T10:25:07.562632+00:00 + 2025-10-11T22:12:37.050912+00:00 + python-feedgen Rebroad (sourceforge) 2014-10-16 05:05:58+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Request for review/testing: headers-first synchronization in Bitcoin Core - 2023-08-01T10:25:07.562632+00:00 + 2025-10-11T22:12:37.051061+00:00 - A developer named Edmund has made improvements to Pieter Wuille's headers-first synchronization pull request for Bitcoin Core. The code updates are available on Github at https://github.com/rebroad/bitcoin/ and the branch is "sipa-headersfirst8-patches". Edmund has improved the code by tracking the block as it downloads and avoiding node stalling due to many blocks being added to the ActiveTip. Additionally, he has added code ready to adapt the window size for download and make it prefer downloading from faster nodes.Pieter Wuille's headers-first synchronization changes the way the best chain is discovered, downloaded, and verified. It allows for parallel block downloading, no more stalled downloads, much more robustness against unresponsive or slow peers, removes a class of DoS attacks related to peers feeding low-difficulty valid large blocks on a side branch, reduces the need for checkpoints in the code, no orphan blocks stored in memory anymore, and is a major step towards an SPV mode using the reference codebase.The code is available as a GitHub pull request (https://github.com/bitcoin/bitcoin/pull/4468) or packaged on http://bitcoin.sipa.be/builds/headersfirst, where binaries can be found to test with. There are known issues such as very slow downloading at the beginning of sync, blocks will be stored on disk out of order, and the block index database will now hold headers for which no block is stored on disk. However, if fully synced, it may still be possible to go back to an earlier version.In an email exchange between Wladimir and Geir Harald Hansen on October 12, 2014, Pieter Wuille had announced that orphan blocks would no longer be stored in memory, reducing memory usage during sync. When Geir asked if this change would slow down reorgs after a fork, Wladimir responded by explaining that orphan blocks are blocks whose parent is not known and in the case of a reorganization, the client jumps to a new best chain, for which the original tip and the new best tip and all their parents must already be known. Geir then apologized for his confusion earlier regarding shorter sides of forks being orphaned.Pieter Wuille has developed a change in Bitcoin Core which he refers to as headers-first synchronization. This new method of syncing the blockchain brings with it several advantages that include much faster sync on typical network connections, no more stalled downloads, and being much more robust against unresponsive or slow peers. Further to this, headers-first removes a class of DoS attacks that have been related to peers feeding low-difficulty valid large blocks on a side branch. According to Pieter, headers-first is a major step towards an SPV mode using the reference codebase. The headers-first synchronization works by replacing the single-peer blocks download by a single-peer headers download (which typically takes seconds/minutes) and verification, and simultaneously fetching blocks along the best known headers chain from all peers that are known to have the relevant blocks. Downloading is constrained to a moving window to avoid unbounded unordering of blocks on disk (which would interfere with pruning later). At the protocol level, headers-first increases the minimally supported version for peers to 31800 (corresponding to bitcoin v3.18, released in December 2010), as earlier versions did not support the getheaders P2P message. The code is available as a Github pull request, or packaged on http://bitcoin.sipa.be/builds/headersfirst where users can also find binaries to test with.There are some known and unknown issues. In an email exchange between Aaron Voisine of breadwallet.com and Pieter Wuille, a large change that Wuille has been working on for Bitcoin Core, headers-first synchronization, was discussed. This mode of operation changes the way the best chain is discovered, downloaded, and verified, and has several advantages including parallel block downloading, no more stalled downloads, more robustness against unresponsive or slow peers, and reduces the need for checkpoints in the code. Additionally, it removes a class of DoS attacks related to peers feeding low-difficulty valid large blocks on a side branch, reduces memory usage during sync, and is a major step towards an SPV mode using the reference codebase. Wuille explained that technically, headers-first synchronization works by replacing the single-peer blocks download by a single-peer headers download and verification, while simultaneously fetching blocks along the best-known headers chain from all peers that have the relevant blocks. The code is available as a github pull request, or packaged on http://bitcoin.sipa.be/builds/headersfirst, where binaries can be tested with. Known issues include slow downloading at the start of the sync (especially before all headers are processed), blocks being stored on disk out of order (making it incompatible with some tools or other programs), and the block index database holding headers for which no block is stored 2014-10-16T05:05:58+00:00 + A developer named Edmund has made improvements to Pieter Wuille's headers-first synchronization pull request for Bitcoin Core. The code updates are available on Github at https://github.com/rebroad/bitcoin/ and the branch is "sipa-headersfirst8-patches". Edmund has improved the code by tracking the block as it downloads and avoiding node stalling due to many blocks being added to the ActiveTip. Additionally, he has added code ready to adapt the window size for download and make it prefer downloading from faster nodes.Pieter Wuille's headers-first synchronization changes the way the best chain is discovered, downloaded, and verified. It allows for parallel block downloading, no more stalled downloads, much more robustness against unresponsive or slow peers, removes a class of DoS attacks related to peers feeding low-difficulty valid large blocks on a side branch, reduces the need for checkpoints in the code, no orphan blocks stored in memory anymore, and is a major step towards an SPV mode using the reference codebase.The code is available as a GitHub pull request (https://github.com/bitcoin/bitcoin/pull/4468) or packaged on http://bitcoin.sipa.be/builds/headersfirst, where binaries can be found to test with. There are known issues such as very slow downloading at the beginning of sync, blocks will be stored on disk out of order, and the block index database will now hold headers for which no block is stored on disk. However, if fully synced, it may still be possible to go back to an earlier version.In an email exchange between Wladimir and Geir Harald Hansen on October 12, 2014, Pieter Wuille had announced that orphan blocks would no longer be stored in memory, reducing memory usage during sync. When Geir asked if this change would slow down reorgs after a fork, Wladimir responded by explaining that orphan blocks are blocks whose parent is not known and in the case of a reorganization, the client jumps to a new best chain, for which the original tip and the new best tip and all their parents must already be known. Geir then apologized for his confusion earlier regarding shorter sides of forks being orphaned.Pieter Wuille has developed a change in Bitcoin Core which he refers to as headers-first synchronization. This new method of syncing the blockchain brings with it several advantages that include much faster sync on typical network connections, no more stalled downloads, and being much more robust against unresponsive or slow peers. Further to this, headers-first removes a class of DoS attacks that have been related to peers feeding low-difficulty valid large blocks on a side branch. According to Pieter, headers-first is a major step towards an SPV mode using the reference codebase. The headers-first synchronization works by replacing the single-peer blocks download by a single-peer headers download (which typically takes seconds/minutes) and verification, and simultaneously fetching blocks along the best known headers chain from all peers that are known to have the relevant blocks. Downloading is constrained to a moving window to avoid unbounded unordering of blocks on disk (which would interfere with pruning later). At the protocol level, headers-first increases the minimally supported version for peers to 31800 (corresponding to bitcoin v3.18, released in December 2010), as earlier versions did not support the getheaders P2P message. The code is available as a Github pull request, or packaged on http://bitcoin.sipa.be/builds/headersfirst where users can also find binaries to test with.There are some known and unknown issues. In an email exchange between Aaron Voisine of breadwallet.com and Pieter Wuille, a large change that Wuille has been working on for Bitcoin Core, headers-first synchronization, was discussed. This mode of operation changes the way the best chain is discovered, downloaded, and verified, and has several advantages including parallel block downloading, no more stalled downloads, more robustness against unresponsive or slow peers, and reduces the need for checkpoints in the code. Additionally, it removes a class of DoS attacks related to peers feeding low-difficulty valid large blocks on a side branch, reduces memory usage during sync, and is a major step towards an SPV mode using the reference codebase. Wuille explained that technically, headers-first synchronization works by replacing the single-peer blocks download by a single-peer headers download and verification, while simultaneously fetching blocks along the best-known headers chain from all peers that have the relevant blocks. The code is available as a github pull request, or packaged on http://bitcoin.sipa.be/builds/headersfirst, where binaries can be tested with. Known issues include slow downloading at the start of the sync (especially before all headers are processed), blocks being stored on disk out of order (making it incompatible with some tools or other programs), and the block index database holding headers for which no block is stored - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Reworking-the-policy-estimation-code-fee-estimates-.xml b/static/bitcoin-dev/Oct_2014/combined_Reworking-the-policy-estimation-code-fee-estimates-.xml index 1e973d468d..e25996166e 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Reworking-the-policy-estimation-code-fee-estimates-.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Reworking-the-policy-estimation-code-fee-estimates-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reworking the policy estimation code (fee estimates) - 2023-08-01T10:33:47.607838+00:00 + 2025-10-11T22:12:07.290826+00:00 + python-feedgen Peter Todd 2014-10-29 20:08:48+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Reworking the policy estimation code (fee estimates) - 2023-08-01T10:33:47.607838+00:00 + 2025-10-11T22:12:07.290980+00:00 - Alex Morcos has discovered issues with the existing code for estimating fees in Bitcoin transactions. The current code estimates high fees based on limited data and only has a failsafe limit of 100mBTC/tx. This can lead to wallets being emptied quickly and exchanges losing significant amounts of money due to an exploit. To address this, a user-configurable failsafe limit is suggested, as well as a more sophisticated approach that takes into account the coin-age of observed transactions.Gavin Andresen and Alex Morcos discuss the fee estimation logic in Bitcoin. Gavin proposes a default threshold percentage of 80% to avoid complaints about slow confirmations. Alex suggests making the threshold percentage tunable through an RPC call. However, Gavin is cautious about adding too many options to the RPC interface and suggests using a command-line or bitcoin.conf option for the default percentage. The discussion also includes real-world test data indicating that even the highest fee rate transactions only have a 90% confirmation rate in one block, making it challenging to guarantee a greater than 90% chance of confirmation.The conversation between Alex and Gavin continues via email, discussing the idea of using a default fee estimation threshold for Bitcoin transactions. Alex suggests making the 90% number an argument to an RPC call, allowing users to specify their desired certainty. Gavin believes that a default percentage of 80% would be more suitable to avoid slow transaction complaints. He suggests setting the default percentage as a command-line or bitcoin.conf option instead of adding multiple parameters to the RPC interface.The new code proposed by Alex for fee estimation in Bitcoin aims to provide accurate estimates based on the prevailing transaction rates. It returns higher rates due to sorting and the fact that very few transactions are placed with such small fees. To give correct low answers, the new code requires frequent super low feerate transactions. Alex suggests specifying a default percentage (possibly 80%) and making the 90% number an argument to an RPC call to facilitate building more complex logic on top of the fee estimation.Gavin and Alex discuss the functioning of the fee market in Bitcoin transactions. Gavin agrees with Alex's approach, noting that hard-coded fees prevent the existence of a functioning fee market. The current git HEAD code suggests a fee of 10,000 satoshis/kb for a 90% chance of confirmation in the next block. However, Gavin raises concerns about the time it takes for Alex's code to gather enough data for accurate fee estimation, particularly for a 90% confirmation in 20 blocks. He suggests making the 90% number an argument to the RPC call with a default of 80% to simplify building more complex logic on top of it.In summary, Alex Morcos has identified issues with the existing code for estimating fees in Bitcoin transactions and proposes a new approach. The discussion between Alex and Gavin Andresen revolves around finding the best approach to fee estimation, including suggestions for user-configurable failsafe limits and a more sophisticated method that considers the coin-age of observed transactions. They also discuss the functionality of a fee market and the challenges of gathering enough data for accurate fee estimation. The proposed solutions involve making the threshold percentage tunable through an RPC call or setting it as a command-line/bitcoin.conf option. 2014-10-29T20:08:48+00:00 + Alex Morcos has discovered issues with the existing code for estimating fees in Bitcoin transactions. The current code estimates high fees based on limited data and only has a failsafe limit of 100mBTC/tx. This can lead to wallets being emptied quickly and exchanges losing significant amounts of money due to an exploit. To address this, a user-configurable failsafe limit is suggested, as well as a more sophisticated approach that takes into account the coin-age of observed transactions.Gavin Andresen and Alex Morcos discuss the fee estimation logic in Bitcoin. Gavin proposes a default threshold percentage of 80% to avoid complaints about slow confirmations. Alex suggests making the threshold percentage tunable through an RPC call. However, Gavin is cautious about adding too many options to the RPC interface and suggests using a command-line or bitcoin.conf option for the default percentage. The discussion also includes real-world test data indicating that even the highest fee rate transactions only have a 90% confirmation rate in one block, making it challenging to guarantee a greater than 90% chance of confirmation.The conversation between Alex and Gavin continues via email, discussing the idea of using a default fee estimation threshold for Bitcoin transactions. Alex suggests making the 90% number an argument to an RPC call, allowing users to specify their desired certainty. Gavin believes that a default percentage of 80% would be more suitable to avoid slow transaction complaints. He suggests setting the default percentage as a command-line or bitcoin.conf option instead of adding multiple parameters to the RPC interface.The new code proposed by Alex for fee estimation in Bitcoin aims to provide accurate estimates based on the prevailing transaction rates. It returns higher rates due to sorting and the fact that very few transactions are placed with such small fees. To give correct low answers, the new code requires frequent super low feerate transactions. Alex suggests specifying a default percentage (possibly 80%) and making the 90% number an argument to an RPC call to facilitate building more complex logic on top of the fee estimation.Gavin and Alex discuss the functioning of the fee market in Bitcoin transactions. Gavin agrees with Alex's approach, noting that hard-coded fees prevent the existence of a functioning fee market. The current git HEAD code suggests a fee of 10,000 satoshis/kb for a 90% chance of confirmation in the next block. However, Gavin raises concerns about the time it takes for Alex's code to gather enough data for accurate fee estimation, particularly for a 90% confirmation in 20 blocks. He suggests making the 90% number an argument to the RPC call with a default of 80% to simplify building more complex logic on top of it.In summary, Alex Morcos has identified issues with the existing code for estimating fees in Bitcoin transactions and proposes a new approach. The discussion between Alex and Gavin Andresen revolves around finding the best approach to fee estimation, including suggestions for user-configurable failsafe limits and a more sophisticated method that considers the coin-age of observed transactions. They also discuss the functionality of a fee market and the challenges of gathering enough data for accurate fee estimation. The proposed solutions involve making the threshold percentage tunable through an RPC call or setting it as a command-line/bitcoin.conf option. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Something-people-are-forgetting-about-the-Gentoo-Luke-jr-censorship-issue.xml b/static/bitcoin-dev/Oct_2014/combined_Something-people-are-forgetting-about-the-Gentoo-Luke-jr-censorship-issue.xml index a48da512ad..b7f0f45318 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Something-people-are-forgetting-about-the-Gentoo-Luke-jr-censorship-issue.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Something-people-are-forgetting-about-the-Gentoo-Luke-jr-censorship-issue.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Something people are forgetting about the Gentoo / Luke-jr censorship issue - 2023-08-01T10:24:27.411045+00:00 + 2025-10-11T22:12:03.040635+00:00 + python-feedgen Thomas Zander 2014-10-10 19:02:38+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Something people are forgetting about the Gentoo / Luke-jr censorship issue - 2023-08-01T10:24:27.411045+00:00 + 2025-10-11T22:12:03.040803+00:00 - In 2014, Mike Hearn, a former Bitcoin developer, addressed the issue of Linux distributions modifying Bitcoin Core's software while packaging it. He acknowledged that this was not unique to Bitcoin Core and that other projects had faced similar challenges. Hearn suggested that building good relationships with distro packagers could be the best solution. He also noted that Linux distros distributing apps licensed under GPL are required by law to offer the sources of the thing they build and distribute as binary. This allows users to check the difference with upstream.Hearn proposed trademarking the name of a project and enforcing 'clean' packaging as a possible solution to prevent Linux distros from altering software. He cited Firefox and Chrome as examples of projects that have successfully implemented this approach. However, he highlighted that this method would only be effective for binary distributions, not source-based distributions like Gentoo.Luke Dashjr, a contributor to Bitcoin Core, has made changes to the software to address user expectations. However, it is anticipated that similar issues may arise in the future with other Linux distributions. Trademarking the project name and ensuring "clean" packaging has proven successful with projects like Firefox and Chrome to ensure users know what they are getting. Renaming a project and creating a package under a new name could be a better solution for end-users and allow the fork to grow into something else, making it more usable for people on other distros. Although Bitcoin is already trademarked, Bitcoin Core is not, and the author intends to follow the same approach with another project called Lighthouse.Jeff Garzik, a Bitcoin core developer and open-source evangelist at BitPay, stated that there are no plans to add a blacklist to Bitcoin Core. This statement addresses concerns about a potential blacklist being added to the platform and dismisses it as a troll issue. Bitcoin Core is an open-source project serving as the reference implementation for the Bitcoin network. Garzik's statement reassures users about the platform's future direction, emphasizing the importance of remaining vigilant against trolls and misinformation campaigns surrounding Bitcoin and other cryptocurrencies.A developer named Luke-Jr expressed a desire to add code that could censor certain network traffic, such as SatoshiDice transactions, due to concerns about them being a denial of service. However, this could have legal implications. The ability to filter specific types of network traffic might make users legally liable for using it to filter illegal content, potentially endangering Bitcoin users. Law enforcement might attempt to enforce its use. To defend against law enforcement pressure, it is preferred not to include or even write and publish such filtering code. A developer from the Freenet Project requested someone to add this comment to the Gentoo bugtracker account. 2014-10-10T19:02:38+00:00 + In 2014, Mike Hearn, a former Bitcoin developer, addressed the issue of Linux distributions modifying Bitcoin Core's software while packaging it. He acknowledged that this was not unique to Bitcoin Core and that other projects had faced similar challenges. Hearn suggested that building good relationships with distro packagers could be the best solution. He also noted that Linux distros distributing apps licensed under GPL are required by law to offer the sources of the thing they build and distribute as binary. This allows users to check the difference with upstream.Hearn proposed trademarking the name of a project and enforcing 'clean' packaging as a possible solution to prevent Linux distros from altering software. He cited Firefox and Chrome as examples of projects that have successfully implemented this approach. However, he highlighted that this method would only be effective for binary distributions, not source-based distributions like Gentoo.Luke Dashjr, a contributor to Bitcoin Core, has made changes to the software to address user expectations. However, it is anticipated that similar issues may arise in the future with other Linux distributions. Trademarking the project name and ensuring "clean" packaging has proven successful with projects like Firefox and Chrome to ensure users know what they are getting. Renaming a project and creating a package under a new name could be a better solution for end-users and allow the fork to grow into something else, making it more usable for people on other distros. Although Bitcoin is already trademarked, Bitcoin Core is not, and the author intends to follow the same approach with another project called Lighthouse.Jeff Garzik, a Bitcoin core developer and open-source evangelist at BitPay, stated that there are no plans to add a blacklist to Bitcoin Core. This statement addresses concerns about a potential blacklist being added to the platform and dismisses it as a troll issue. Bitcoin Core is an open-source project serving as the reference implementation for the Bitcoin network. Garzik's statement reassures users about the platform's future direction, emphasizing the importance of remaining vigilant against trolls and misinformation campaigns surrounding Bitcoin and other cryptocurrencies.A developer named Luke-Jr expressed a desire to add code that could censor certain network traffic, such as SatoshiDice transactions, due to concerns about them being a denial of service. However, this could have legal implications. The ability to filter specific types of network traffic might make users legally liable for using it to filter illegal content, potentially endangering Bitcoin users. Law enforcement might attempt to enforce its use. To defend against law enforcement pressure, it is preferred not to include or even write and publish such filtering code. A developer from the Freenet Project requested someone to add this comment to the Gentoo bugtracker account. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_The-Bitcoin-Freeze-on-Transaction-Attack-FRONT-.xml b/static/bitcoin-dev/Oct_2014/combined_The-Bitcoin-Freeze-on-Transaction-Attack-FRONT-.xml index b4058b26b9..0a680f36d2 100644 --- a/static/bitcoin-dev/Oct_2014/combined_The-Bitcoin-Freeze-on-Transaction-Attack-FRONT-.xml +++ b/static/bitcoin-dev/Oct_2014/combined_The-Bitcoin-Freeze-on-Transaction-Attack-FRONT-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The Bitcoin Freeze on Transaction Attack (FRONT) - 2023-08-01T10:24:04.550724+00:00 + 2025-10-11T22:12:15.791664+00:00 + python-feedgen Mike Hearn 2014-10-08 10:19:10+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - The Bitcoin Freeze on Transaction Attack (FRONT) - 2023-08-01T10:24:04.551727+00:00 + 2025-10-11T22:12:15.791836+00:00 - The discussion revolves around the rationality of miners in the Bitcoin network. It is suggested that prioritizing short-term profits over the overall health of the system can lead to potential attacks on the network. However, as the mining arms race slows down, miners may become more settled in their approach.In an email exchange, Gregory Maxwell discusses the potential issue of anonymous double-spends in Bitcoin. He proposes a method to prevent double-spends by locking fraudulent spends one block higher and relying on miners to choose to take kickback payments. If someone were to modify bitcoind to make this choice automatic, then DECOR+ would be the only solution to avoid anonymous double-spends with chained kickbacks.Sergio Lerner proposes a solution to the freeze problem in cryptocurrency transactions called "FRONT" or automatic fee-sharing. However, he notes that this solution creates the risk of double-spending through a process called "CHAKIDO." The ability for miners to roll forward fees does not make this situation any worse since transactions can also roll forward fees.Tom Harding and Sergio Lerner discuss rational self-interest in Bitcoin mining. Lerner argues that competing for high-fee transactions would be the most profitable strategy, but Harding points out that this strategy only works if one miner has a fixed advantage. The solution to this problem is the DECOR+ protocol, which shares block rewards between miners at the same height until coinbase maturity is over.The context discusses an ORBS attack or an attempt to form an ad-hoc coalition for a fork. The worry about times when block subsidy is low is unwarranted as the cost of proof-of-work creates a lower bound to the incentive that needs to be offered. Disallowing the implementation of rational mining is not a viable option, as anyone can implement whatever optimization they think is profitable and within the rules.In an email thread, Alex Mizrahi proposes a solution to sharing unusually large transaction fees without the need for protocol changes. However, Sergio Lerner points out that this solution could be used for an attack called CHAKIDO. Sergio suggests alternative protections to address this issue.The problem of creating an arbitrary fee can arise due to a bug or accident in defective wallet software. Miners could be incentivized to collect these huge fees, which might provide a higher incentive than the block subsidy on the trunk. This could trigger a long battle of ad-hoc coalitions. Addressing the known bug of the signature hash would have positive effects for resource-limited hardware wallets.The discussion is about the stability of a blockchain system when the block size is lower than the offered demand, resulting in a backlog. The poster expresses skepticism that such a situation can ever be stable because people typically do not want their transactions to be stuck in the backlog. An idea from TierNolan suggests that a miner who owns 1/N of the total hashrate must choose between two strategies based on the last known block's claimed large transaction fee.Jorge Timón discusses the eventual disappearance of mining subsidies for Bitcoin and how transaction fees will become higher than these subsidies. He proposes a hypothetical scenario where Bitcoin would have initially come with a set of nlocktimed transactions that pay fees for each block from the start until the subsidy disappears.In an email exchange, the idea of formalizing the proportion of "rational" vs "honest"/"altruistic" participants in the network is discussed. It is suggested that if there is a significant amount of honest hashrate refusing to aid greedy behavior, then such a strategy becomes a loser even for purely greedy participants. The email exchange also touches on income tradeoffs for different amounts of altruism and convergence problems that may arise if altruistic participants attempt to punish forkers.Gregory Maxwell points out tools that could be helpful for Bitcoin transactions. He suggests using the BLS short signature scheme to help secure transactions. He explains how this scheme can prevent censorship and provide anti-censorship properties.Sergio Lerner shares a vulnerability in the Bitcoin protocol called "The Freeze on Transaction Problem." Some tools are discussed to address this problem, such as locktime on normal transactions, block commitments in transactions, and fee forwarding. However, these tools do not completely solve the concern. Sergio suggests formalizing the analysis of the proportion of the network that is rational versus honest or altruistic.In an email exchange, it is pointed out that the freeze on transaction problem is non-existent currently because of preventive measures implemented in the latest versions of bitcoind. The best solution is for the community to cooperate and share high transaction fees. Alternatively, modifying the Bitcoin protocol to automatically share fees in a sliding window could provide a way for miners to cooperate anonymously.Overall, the discussions highlight various challenges and potential solutions related to rationality of miners, double-spending, transaction fees, network stability, and vulnerability in the Bitcoin protocol. 2014-10-08T10:19:10+00:00 + The discussion revolves around the rationality of miners in the Bitcoin network. It is suggested that prioritizing short-term profits over the overall health of the system can lead to potential attacks on the network. However, as the mining arms race slows down, miners may become more settled in their approach.In an email exchange, Gregory Maxwell discusses the potential issue of anonymous double-spends in Bitcoin. He proposes a method to prevent double-spends by locking fraudulent spends one block higher and relying on miners to choose to take kickback payments. If someone were to modify bitcoind to make this choice automatic, then DECOR+ would be the only solution to avoid anonymous double-spends with chained kickbacks.Sergio Lerner proposes a solution to the freeze problem in cryptocurrency transactions called "FRONT" or automatic fee-sharing. However, he notes that this solution creates the risk of double-spending through a process called "CHAKIDO." The ability for miners to roll forward fees does not make this situation any worse since transactions can also roll forward fees.Tom Harding and Sergio Lerner discuss rational self-interest in Bitcoin mining. Lerner argues that competing for high-fee transactions would be the most profitable strategy, but Harding points out that this strategy only works if one miner has a fixed advantage. The solution to this problem is the DECOR+ protocol, which shares block rewards between miners at the same height until coinbase maturity is over.The context discusses an ORBS attack or an attempt to form an ad-hoc coalition for a fork. The worry about times when block subsidy is low is unwarranted as the cost of proof-of-work creates a lower bound to the incentive that needs to be offered. Disallowing the implementation of rational mining is not a viable option, as anyone can implement whatever optimization they think is profitable and within the rules.In an email thread, Alex Mizrahi proposes a solution to sharing unusually large transaction fees without the need for protocol changes. However, Sergio Lerner points out that this solution could be used for an attack called CHAKIDO. Sergio suggests alternative protections to address this issue.The problem of creating an arbitrary fee can arise due to a bug or accident in defective wallet software. Miners could be incentivized to collect these huge fees, which might provide a higher incentive than the block subsidy on the trunk. This could trigger a long battle of ad-hoc coalitions. Addressing the known bug of the signature hash would have positive effects for resource-limited hardware wallets.The discussion is about the stability of a blockchain system when the block size is lower than the offered demand, resulting in a backlog. The poster expresses skepticism that such a situation can ever be stable because people typically do not want their transactions to be stuck in the backlog. An idea from TierNolan suggests that a miner who owns 1/N of the total hashrate must choose between two strategies based on the last known block's claimed large transaction fee.Jorge Timón discusses the eventual disappearance of mining subsidies for Bitcoin and how transaction fees will become higher than these subsidies. He proposes a hypothetical scenario where Bitcoin would have initially come with a set of nlocktimed transactions that pay fees for each block from the start until the subsidy disappears.In an email exchange, the idea of formalizing the proportion of "rational" vs "honest"/"altruistic" participants in the network is discussed. It is suggested that if there is a significant amount of honest hashrate refusing to aid greedy behavior, then such a strategy becomes a loser even for purely greedy participants. The email exchange also touches on income tradeoffs for different amounts of altruism and convergence problems that may arise if altruistic participants attempt to punish forkers.Gregory Maxwell points out tools that could be helpful for Bitcoin transactions. He suggests using the BLS short signature scheme to help secure transactions. He explains how this scheme can prevent censorship and provide anti-censorship properties.Sergio Lerner shares a vulnerability in the Bitcoin protocol called "The Freeze on Transaction Problem." Some tools are discussed to address this problem, such as locktime on normal transactions, block commitments in transactions, and fee forwarding. However, these tools do not completely solve the concern. Sergio suggests formalizing the analysis of the proportion of the network that is rational versus honest or altruistic.In an email exchange, it is pointed out that the freeze on transaction problem is non-existent currently because of preventive measures implemented in the latest versions of bitcoind. The best solution is for the community to cooperate and share high transaction fees. Alternatively, modifying the Bitcoin protocol to automatically share fees in a sliding window could provide a way for miners to cooperate anonymously.Overall, the discussions highlight various challenges and potential solutions related to rationality of miners, double-spending, transaction fees, network stability, and vulnerability in the Bitcoin protocol. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_Two-Proposed-BIPs-Bluetooth-Communication-and-bitcoin-URI-Scheme-Improvements.xml b/static/bitcoin-dev/Oct_2014/combined_Two-Proposed-BIPs-Bluetooth-Communication-and-bitcoin-URI-Scheme-Improvements.xml index 85d0d7c131..c3d323d212 100644 --- a/static/bitcoin-dev/Oct_2014/combined_Two-Proposed-BIPs-Bluetooth-Communication-and-bitcoin-URI-Scheme-Improvements.xml +++ b/static/bitcoin-dev/Oct_2014/combined_Two-Proposed-BIPs-Bluetooth-Communication-and-bitcoin-URI-Scheme-Improvements.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements - 2023-08-01T10:27:34.037467+00:00 + 2025-10-11T22:12:20.037544+00:00 + python-feedgen Peter D. Gray 2015-02-06 19:06:07+00:00 @@ -63,13 +64,13 @@ - python-feedgen + 2 Combined summary - Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements - 2023-08-01T10:27:34.037467+00:00 + 2025-10-11T22:12:20.037726+00:00 - The Bitcoin community is seeking a person-to-person payment protocol for Bluetooth Low Energy (BLE) that is resistant to spoofing and vandalism. The author proposes using EC signing of nonces to develop a rock-solid P2P protocol. They suggest modifying the "commit protocol" based on RedPhone, using a 6-digit decimal confirmation code for easier display on vending machines and small screens.The verification of bitcoin payments on the breadwallet app for Apple devices is faster than on Android, possibly due to a more optimized signature verification algorithm. The slower verification process on Android may be because it is being verified in Java instead of C++, but this can potentially be fixed. X.509 cert chains are mentioned as bloated, but even with their size, the transfer time should not take several seconds over Bluetooth.Bluetooth Low Energy (BLE) is designed for always-on broadcast "beacons" with low power requirements. It is commonly used to trigger other mechanisms like classical Bluetooth or HTTPS connections. BLE can be used in Bitcoin payments to download payment requests and upload payment messages, while actual data transfer occurs over Bluetooth, Wifi, or the internet. The challenge lies in how the wallet can download the right payment request, which is a tough UI problem to solve.In an email exchange, Andreas Schildbach and Eric Voskuil discuss the advantages of Bluetooth Low Energy (BLE) over Bluetooth. BLE uses less power and has lower bandwidth but greater range and lower connection latency, making it suitable for payment purposes. However, the transfer of larger files may reduce the benefits of BLE. The size of signed payment requests can be significant, so speed is important.Andy Schroder raises concerns about discussing certain issues on the mailing list and suggests finding a more appropriate place for discussion.The proposed Bluetooth payment protocol implementation could be more secure with a lower range. BLE offers lower power usage and lower bandwidth, making it suitable for payment purposes. However, the connection may be slow when including the whole certificate chain. The author suggests improvements to the Bluetooth communication scheme and the general payment protocol.Andy Schroder introduces two proposed BIPs for implementing the payment protocol using Bluetooth connections. These proposals are modeled after Andreas Schildbach's Android Bitcoin Wallet's Bluetooth capability, which uses BLE technology. The author highlights the need for further discussion on various aspects of Bluetooth implementation. They also mention known issues that can be improved, such as inconsistency in connection header messages, unauthenticated Bluetooth connection, and lack of acknowledgement failure message in the payment protocol.The discussion explores whether BIPs should document how things should work or how they actually work. The need for informational BIPs and an efficient process for them is emphasized.SSL encryption on Bluetooth connections is suggested but considered complicated. Alternative PKIs and the issue of HTTP base failure signal are discussed. Merge avoidance and the trustworthiness of HTTPS are mentioned. The possibility of providing a full-fledged WiFi connection for customers is explored, requiring a sophisticated proxy server to allow access only to Bitcoin nodes. The dedicated blockchain radio is also discussed.In an email exchange between Mike Hearn and Andy Schroder, the issues with the existing Bluetooth payment protocol are discussed. They highlight the use of an unauthenticated Bluetooth connection and the lack of acknowledgement failure message. The conversation also touches on data storage in QR codes and the limit of offline transactions. The need for a lightweight library for ECDH key agreement and AES+HMAC encryption is mentioned. The discussion further explores the need for dedicated blockchain access and the challenges of providing a full-fledged WiFi connection.The author of this email discusses the implementation of the payment protocol using Bluetooth connections and introduces two proposed BIPs. The use of Bluetooth is important because it allows for payments to be made in areas with limited or no internet access. The proposed BIPs are based on Andreas Schildbach's Android Bitcoin Wallet's Bluetooth capability and include an additional parameter in the bitcoin: URI scheme for including a hash of the payment request.The author seeks feedback from wallet developers and others on these proposals, as widespread Bluetooth support among wallets is crucial. They provide links to copies of the proposed BIPs and a video demonstration showcasing the features using Schildbach's wallet and a fuel pump.There are known issues with the Bluetooth communication scheme and general payment protocol that the author and Andreas would like feedback on. These issues include inconsistencies in connection header messages, unauthenticated Bluetooth connections that are vulnerable to man-in-the-middle attacks, lack of acknowledgement failure message in the payment protocol, and the increasing size of QR codes when using a backwards compatible URL.Possible alternatives to the proposed solution are suggested, such as reversing the order of parameter numbers in the payment_url or creating a new payment_url_multi field for future use. The author concludes by inviting comments and suggestions from readers. 2015-02-06T19:06:07+00:00 + The Bitcoin community is seeking a person-to-person payment protocol for Bluetooth Low Energy (BLE) that is resistant to spoofing and vandalism. The author proposes using EC signing of nonces to develop a rock-solid P2P protocol. They suggest modifying the "commit protocol" based on RedPhone, using a 6-digit decimal confirmation code for easier display on vending machines and small screens.The verification of bitcoin payments on the breadwallet app for Apple devices is faster than on Android, possibly due to a more optimized signature verification algorithm. The slower verification process on Android may be because it is being verified in Java instead of C++, but this can potentially be fixed. X.509 cert chains are mentioned as bloated, but even with their size, the transfer time should not take several seconds over Bluetooth.Bluetooth Low Energy (BLE) is designed for always-on broadcast "beacons" with low power requirements. It is commonly used to trigger other mechanisms like classical Bluetooth or HTTPS connections. BLE can be used in Bitcoin payments to download payment requests and upload payment messages, while actual data transfer occurs over Bluetooth, Wifi, or the internet. The challenge lies in how the wallet can download the right payment request, which is a tough UI problem to solve.In an email exchange, Andreas Schildbach and Eric Voskuil discuss the advantages of Bluetooth Low Energy (BLE) over Bluetooth. BLE uses less power and has lower bandwidth but greater range and lower connection latency, making it suitable for payment purposes. However, the transfer of larger files may reduce the benefits of BLE. The size of signed payment requests can be significant, so speed is important.Andy Schroder raises concerns about discussing certain issues on the mailing list and suggests finding a more appropriate place for discussion.The proposed Bluetooth payment protocol implementation could be more secure with a lower range. BLE offers lower power usage and lower bandwidth, making it suitable for payment purposes. However, the connection may be slow when including the whole certificate chain. The author suggests improvements to the Bluetooth communication scheme and the general payment protocol.Andy Schroder introduces two proposed BIPs for implementing the payment protocol using Bluetooth connections. These proposals are modeled after Andreas Schildbach's Android Bitcoin Wallet's Bluetooth capability, which uses BLE technology. The author highlights the need for further discussion on various aspects of Bluetooth implementation. They also mention known issues that can be improved, such as inconsistency in connection header messages, unauthenticated Bluetooth connection, and lack of acknowledgement failure message in the payment protocol.The discussion explores whether BIPs should document how things should work or how they actually work. The need for informational BIPs and an efficient process for them is emphasized.SSL encryption on Bluetooth connections is suggested but considered complicated. Alternative PKIs and the issue of HTTP base failure signal are discussed. Merge avoidance and the trustworthiness of HTTPS are mentioned. The possibility of providing a full-fledged WiFi connection for customers is explored, requiring a sophisticated proxy server to allow access only to Bitcoin nodes. The dedicated blockchain radio is also discussed.In an email exchange between Mike Hearn and Andy Schroder, the issues with the existing Bluetooth payment protocol are discussed. They highlight the use of an unauthenticated Bluetooth connection and the lack of acknowledgement failure message. The conversation also touches on data storage in QR codes and the limit of offline transactions. The need for a lightweight library for ECDH key agreement and AES+HMAC encryption is mentioned. The discussion further explores the need for dedicated blockchain access and the challenges of providing a full-fledged WiFi connection.The author of this email discusses the implementation of the payment protocol using Bluetooth connections and introduces two proposed BIPs. The use of Bluetooth is important because it allows for payments to be made in areas with limited or no internet access. The proposed BIPs are based on Andreas Schildbach's Android Bitcoin Wallet's Bluetooth capability and include an additional parameter in the bitcoin: URI scheme for including a hash of the payment request.The author seeks feedback from wallet developers and others on these proposals, as widespread Bluetooth support among wallets is crucial. They provide links to copies of the proposed BIPs and a video demonstration showcasing the features using Schildbach's wallet and a fuel pump.There are known issues with the Bluetooth communication scheme and general payment protocol that the author and Andreas would like feedback on. These issues include inconsistencies in connection header messages, unauthenticated Bluetooth connections that are vulnerable to man-in-the-middle attacks, lack of acknowledgement failure message in the payment protocol, and the increasing size of QR codes when using a backwards compatible URL.Possible alternatives to the proposed solution are suggested, such as reversing the order of parameter numbers in the payment_url or creating a new payment_url_multi field for future use. The author concludes by inviting comments and suggestions from readers. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_bitcoinj-0-12.xml b/static/bitcoin-dev/Oct_2014/combined_bitcoinj-0-12.xml index 043c392388..354373ee07 100644 --- a/static/bitcoin-dev/Oct_2014/combined_bitcoinj-0-12.xml +++ b/static/bitcoin-dev/Oct_2014/combined_bitcoinj-0-12.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoinj 0.12 - 2023-08-01T10:23:23.425948+00:00 + 2025-10-11T22:12:17.913677+00:00 + python-feedgen Mike Hearn 2014-10-04 13:26:39+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - bitcoinj 0.12 - 2023-08-01T10:23:23.425948+00:00 + 2025-10-11T22:12:17.913831+00:00 - The author of BitcoinJ has stated that stealth addresses and SPV do not mix well, and therefore there are no plans to support them. Instead, a description of how to achieve something similar with the payment protocol has been provided. The author's focus will be on fully launching Lighthouse and crowdfunding for decentralization/crypto-related projects, rather than working on major feature work on bitcoinj. If the author were to undertake a big project, it would involve refactoring the wallet so that it doesn't store transactions directly, only unspent outputs. This is because scalability limits have been identified as the top user-reported problem with the current design.On October 3, 2014, version 0.12 of bitcoinj was released by Mike Hearn. Bitcoinj is a widely used Bitcoin library that powers multiple wallets and other Bitcoin-related projects. This release includes notable enhancements such as hierarchical and deterministic (HD) wallets, support for multisig wallets, faster ECDSA, an integrated Tor mode, and various API improvements. The update also includes upgrades to the GUI wallet, which can be seen in a tutorial video. Additionally, bug fixes, cleanups, minor tweaks, and new APIs have been implemented. The documentation has been significantly expanded to cover encryption, watching wallets, HD wallets, and multisig/married wallets. A new document and accompanying screencast demonstrate how to extend the WalletTemplate app and create a native/bundled package that eliminates the need for Java installation. Some method names have been updated, and the package name has been changed to org.bitcoinj.Mike Hearn expressed his satisfaction and admiration for the capabilities of bitcoinj in the announcement of version 0.12. He mentioned that just reading the release notes gives one ideas for new applications. The updated library opens up numerous possibilities for developers to build applications using this technology. Wladimir congratulated Mike on the release, highlighting the library's popularity and its usage by various Android wallets, desktop wallets, and other projects.Version 0.12 of bitcoinj includes HD wallets with full support for BIP32 and BIP39 after 8 months of work. The release also incorporates various HD wallet structures, including BIP44. This update emphasizes the use of hierarchical and deterministic wallets, which adhere to the BIP32 specification. It introduces support for mnemonic codes (BIP 39) and integrates Tor using the Orchid library. Multisig wallets are now supported, and improvements have been made to the GUI wallet. The new HD wallets significantly enhance privacy by eliminating the reuse of change and receive addresses. Bitcoinj version 0.12 has been extensively utilized by multiple Android and desktop wallets, academic research projects, blockchain.info, Circle, Lighthouse, CryptoCorp, biteasy, BlueMatt's relay network, bitpos, and numerous altcoin wallets. 2014-10-04T13:26:39+00:00 + The author of BitcoinJ has stated that stealth addresses and SPV do not mix well, and therefore there are no plans to support them. Instead, a description of how to achieve something similar with the payment protocol has been provided. The author's focus will be on fully launching Lighthouse and crowdfunding for decentralization/crypto-related projects, rather than working on major feature work on bitcoinj. If the author were to undertake a big project, it would involve refactoring the wallet so that it doesn't store transactions directly, only unspent outputs. This is because scalability limits have been identified as the top user-reported problem with the current design.On October 3, 2014, version 0.12 of bitcoinj was released by Mike Hearn. Bitcoinj is a widely used Bitcoin library that powers multiple wallets and other Bitcoin-related projects. This release includes notable enhancements such as hierarchical and deterministic (HD) wallets, support for multisig wallets, faster ECDSA, an integrated Tor mode, and various API improvements. The update also includes upgrades to the GUI wallet, which can be seen in a tutorial video. Additionally, bug fixes, cleanups, minor tweaks, and new APIs have been implemented. The documentation has been significantly expanded to cover encryption, watching wallets, HD wallets, and multisig/married wallets. A new document and accompanying screencast demonstrate how to extend the WalletTemplate app and create a native/bundled package that eliminates the need for Java installation. Some method names have been updated, and the package name has been changed to org.bitcoinj.Mike Hearn expressed his satisfaction and admiration for the capabilities of bitcoinj in the announcement of version 0.12. He mentioned that just reading the release notes gives one ideas for new applications. The updated library opens up numerous possibilities for developers to build applications using this technology. Wladimir congratulated Mike on the release, highlighting the library's popularity and its usage by various Android wallets, desktop wallets, and other projects.Version 0.12 of bitcoinj includes HD wallets with full support for BIP32 and BIP39 after 8 months of work. The release also incorporates various HD wallet structures, including BIP44. This update emphasizes the use of hierarchical and deterministic wallets, which adhere to the BIP32 specification. It introduces support for mnemonic codes (BIP 39) and integrates Tor using the Orchid library. Multisig wallets are now supported, and improvements have been made to the GUI wallet. The new HD wallets significantly enhance privacy by eliminating the reuse of change and receive addresses. Bitcoinj version 0.12 has been extensively utilized by multiple Android and desktop wallets, academic research projects, blockchain.info, Circle, Lighthouse, CryptoCorp, biteasy, BlueMatt's relay network, bitpos, and numerous altcoin wallets. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_cryptographic-review-requested.xml b/static/bitcoin-dev/Oct_2014/combined_cryptographic-review-requested.xml index 6723895efb..52462a6bfd 100644 --- a/static/bitcoin-dev/Oct_2014/combined_cryptographic-review-requested.xml +++ b/static/bitcoin-dev/Oct_2014/combined_cryptographic-review-requested.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - cryptographic review requested - 2023-08-01T10:20:13.759645+00:00 + 2025-10-11T22:12:39.175789+00:00 + python-feedgen Pavol Rusnak 2014-10-22 14:56:37+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - cryptographic review requested - 2023-08-01T10:20:13.759645+00:00 + 2025-10-11T22:12:39.175936+00:00 - On September 23, 2014, Mem Wallet raised a question about the use of deterministic nonces for ECIES and the potential consequences. The recipient of the email responded by stating that while using deterministic nonces for signatures is acceptable, they should not be used for ECIES unless they are high-quality random bytes. Unit test vectors were mentioned as a possible exception to this rule.In a separate email conversation on October 22, 2014, Chris D'Costa expressed concerns about ensuring that the public key received for encrypting a message is not from a Man-In-The-Middle (MITM) attacker. Pavol Rusnak asked if this was the same problem with PGP.In another email exchange on September 23, 2014, Mem Wallet and Pavol Rusnak discussed a proposed change to BIP44 to include identity keys for structured wallets. Mem Wallet suggested creating a new BIP to describe the HD paths used for ECIES, referring to a working implementation available at http://memwallet.info/btcmssgs.html. Pavol Rusnak agreed that the implementation seemed complete and proposed pushing it as a new BIP for review and standardization.The provided context mentions a proposal for a standardized ECIES scheme for Bitcoin communication, which also includes a proposed change to BIP44. The scheme allows for secure messaging using a Bitcoin wallet without requiring additional software. It enables address owners to prove ownership privately to other address holders without the need for secure communication channels.The scheme described in the document uses CompactSize format for serialization and assumes familiarity with the Bitcoin compact signature format. The sender's address is included for signature validation. The scheme employs HMAC_SHA256 for MAC and PBKDF2 for KDF, with specific iterations and salt values. AES with 256-bit keys and CFB mode with a 128-bit feedback buffer are used for encryption. No padding or envelope is used.The compact_signed_message and compact_unsigned_message formats are explained, along with the inputs for the SendMessage and ReceiveMessage functions. Test vectors are provided in different formats, including WIF, base58_check, C-style UTF-8 string literals, and Base64.It is mentioned that compliant implementations should use random nonces from a cryptographically strong DRBG. The context includes a cryptographic address and a signing address, and the implementation can be found on memwallet.info/btcmssgs.html. The credit for the implementation goes to 76NPRHE2g5pSvbLgP8fEEtBvfPB4zte56veXdxXfaXcsQwRjZB (1Lk96ASyr3k6ZoTFGLrUgxGuctNKF24V5q), with acknowledgments to bitaddress.org, brainwallet.org, and other contributors who have simplified cryptocurrency and Bitcoin coding in JavaScript. 2014-10-22T14:56:37+00:00 + On September 23, 2014, Mem Wallet raised a question about the use of deterministic nonces for ECIES and the potential consequences. The recipient of the email responded by stating that while using deterministic nonces for signatures is acceptable, they should not be used for ECIES unless they are high-quality random bytes. Unit test vectors were mentioned as a possible exception to this rule.In a separate email conversation on October 22, 2014, Chris D'Costa expressed concerns about ensuring that the public key received for encrypting a message is not from a Man-In-The-Middle (MITM) attacker. Pavol Rusnak asked if this was the same problem with PGP.In another email exchange on September 23, 2014, Mem Wallet and Pavol Rusnak discussed a proposed change to BIP44 to include identity keys for structured wallets. Mem Wallet suggested creating a new BIP to describe the HD paths used for ECIES, referring to a working implementation available at http://memwallet.info/btcmssgs.html. Pavol Rusnak agreed that the implementation seemed complete and proposed pushing it as a new BIP for review and standardization.The provided context mentions a proposal for a standardized ECIES scheme for Bitcoin communication, which also includes a proposed change to BIP44. The scheme allows for secure messaging using a Bitcoin wallet without requiring additional software. It enables address owners to prove ownership privately to other address holders without the need for secure communication channels.The scheme described in the document uses CompactSize format for serialization and assumes familiarity with the Bitcoin compact signature format. The sender's address is included for signature validation. The scheme employs HMAC_SHA256 for MAC and PBKDF2 for KDF, with specific iterations and salt values. AES with 256-bit keys and CFB mode with a 128-bit feedback buffer are used for encryption. No padding or envelope is used.The compact_signed_message and compact_unsigned_message formats are explained, along with the inputs for the SendMessage and ReceiveMessage functions. Test vectors are provided in different formats, including WIF, base58_check, C-style UTF-8 string literals, and Base64.It is mentioned that compliant implementations should use random nonces from a cryptographically strong DRBG. The context includes a cryptographic address and a signing address, and the implementation can be found on memwallet.info/btcmssgs.html. The credit for the implementation goes to 76NPRHE2g5pSvbLgP8fEEtBvfPB4zte56veXdxXfaXcsQwRjZB (1Lk96ASyr3k6ZoTFGLrUgxGuctNKF24V5q), with acknowledgments to bitaddress.org, brainwallet.org, and other contributors who have simplified cryptocurrency and Bitcoin coding in JavaScript. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_death-by-halving.xml b/static/bitcoin-dev/Oct_2014/combined_death-by-halving.xml index 8ea0f5ea4e..6ea2328f9c 100644 --- a/static/bitcoin-dev/Oct_2014/combined_death-by-halving.xml +++ b/static/bitcoin-dev/Oct_2014/combined_death-by-halving.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - death by halving - 2023-08-01T10:32:39.656934+00:00 + 2025-10-11T22:12:41.295920+00:00 + python-feedgen Ferdinando M. Ametrano 2014-10-28 20:17:58+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - death by halving - 2023-08-01T10:32:39.657992+00:00 + 2025-10-11T22:12:41.296103+00:00 - The article discusses the profitability of Bitcoin mining after the reward halving event. It introduces the concept of Miner Income Multiple (MIM), which is the ratio between the total revenue a miner receives and the cost of electricity spent on mining (C_e). The author presents a theorem stating that if a miner's MIM is less than 0.5 before the subsidy halving, and if bitcoin and electricity prices remain the same, then mining will no longer be profitable after the halving.The worst-case scenario is when a miner's MIM is close to zero before the halving, leading to approximately half of all hashpower dropping out. The article estimates that the long-term MIM will be less than 50% when the ratio of the cost of electricity to the cost of hardware (f) is greater than 1. To illustrate this point, the author uses the example of Spondoolies Tech's SP35 Yukon unit, which costs $4000 and consumes 3.5 KW, with a useful lifetime of more than two years. Based on these numbers, the total expenditures on electricity for this device will be at least $6135, resulting in an f value greater than 1.5 and an MIM lower than 0.5.Despite the concerns raised about the profitability of mining after the reward halving, the author suggests that there is hope that it won't be critical as long as the hashpower drop remains below 50% in the equilibrium break-even situation. However, there is a potential threat of the hashrate dropping by more than 50% immediately after the halving due to the slow difficulty update. This poses a real challenge for miners and highlights the need for timely adjustments to maintain profitability.In conclusion, the article analyzes the impact of the reward halving on Bitcoin mining profitability. It introduces the concept of MIM and presents a theorem indicating that mining may no longer be profitable if the MIM falls below 0.5. The author discusses the potential scenarios and presents an example to illustrate the calculations. While there is hope that the hashpower drop will not exceed 50% in the equilibrium break-even situation, the immediate post-halving period poses a real threat due to slow difficulty updates. 2014-10-28T20:17:58+00:00 + The article discusses the profitability of Bitcoin mining after the reward halving event. It introduces the concept of Miner Income Multiple (MIM), which is the ratio between the total revenue a miner receives and the cost of electricity spent on mining (C_e). The author presents a theorem stating that if a miner's MIM is less than 0.5 before the subsidy halving, and if bitcoin and electricity prices remain the same, then mining will no longer be profitable after the halving.The worst-case scenario is when a miner's MIM is close to zero before the halving, leading to approximately half of all hashpower dropping out. The article estimates that the long-term MIM will be less than 50% when the ratio of the cost of electricity to the cost of hardware (f) is greater than 1. To illustrate this point, the author uses the example of Spondoolies Tech's SP35 Yukon unit, which costs $4000 and consumes 3.5 KW, with a useful lifetime of more than two years. Based on these numbers, the total expenditures on electricity for this device will be at least $6135, resulting in an f value greater than 1.5 and an MIM lower than 0.5.Despite the concerns raised about the profitability of mining after the reward halving, the author suggests that there is hope that it won't be critical as long as the hashpower drop remains below 50% in the equilibrium break-even situation. However, there is a potential threat of the hashrate dropping by more than 50% immediately after the halving due to the slow difficulty update. This poses a real challenge for miners and highlights the need for timely adjustments to maintain profitability.In conclusion, the article analyzes the impact of the reward halving on Bitcoin mining profitability. It introduces the concept of MIM and presents a theorem indicating that mining may no longer be profitable if the MIM falls below 0.5. The author discusses the potential scenarios and presents an example to illustrate the calculations. While there is hope that the hashpower drop will not exceed 50% in the equilibrium break-even situation, the immediate post-halving period poses a real threat due to slow difficulty updates. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2014/combined_side-chains-2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml b/static/bitcoin-dev/Oct_2014/combined_side-chains-2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml index 90b7c2c195..6a74d80384 100644 --- a/static/bitcoin-dev/Oct_2014/combined_side-chains-2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml +++ b/static/bitcoin-dev/Oct_2014/combined_side-chains-2-way-pegging-Re-is-there-a-way-to-do-bitcoin-staging-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?) - 2023-08-01T10:30:50.336112+00:00 + 2025-10-11T22:12:43.423170+00:00 + python-feedgen odinn 2014-11-03 19:38:27+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?) - 2023-08-01T10:30:50.336112+00:00 + 2025-10-11T22:12:43.423323+00:00 - The provided context includes a PGP signed message with a hash value of SHA512, containing links to two cryptography-related websites: IACR and DES. The first link leads to the proceedings of Eurocrypt 2002, a conference on cryptology, while the second link directs to the accepted papers for Asiacrypt 2014, another cryptographic conference. Within these links, there is a message from Andrew Poelstra mentioning a "false proof" without further explanation. The authenticity and integrity of the message are confirmed by the signature at the end.The discussion revolves around the distinction between hardness and likelihood of successful attack. It is explained that fraudulent transfers can occur without reorganization if an attacker produces a fake SPV proof. This type of attack does not require the attacker to own coins. However, in the absence of reorganization, the false proof will be invalidated by proof of longer work on the real chain.There is a conversation between Alex Mizrahi and an unknown person discussing the security model of sidechains. It is argued that anyone with sufficient hashpower can unlock a locked coin on the parent chain by producing an SPV proof. However, if the majority of sidechain miners continue working on the honest chain, a reorg proof can be submitted during the contest period to invalidate this "unlockment" on the parent chain. The security model of sidechains relies on the assumption that an attacker won't control a majority of the network.The article explains the concept of miners in blockchain technology and how they prove computational work to achieve stable consensus on the blockchain history. Sidechains are discussed, where anyone with sufficient hashpower can unlock a locked coin on the parent chain by producing an SPV proof. This eliminates the incentive for miners to behave honestly in sidechains as they only receive transaction fees as rewards. The security of sidechains is compared to Bitcoin's security, relying on the assumption that an attacker won't control a majority of the network.In a mailing list discussion, Alex Mizrahi criticizes a paper on sidechains as "wishful thinking," arguing that it is based on the assumption that Bitcoin's decentralized mining model is secure, which he believes may not always be true. The paper discusses hashpower attacks and reorganizations and suggests longer contest periods for transfers to make fraudulent transfers more difficult.A paper on side-chains, two-way pegs, and compact SPV proofs has been written by Blockstream, Andrew Poelstra, and Andrew Miller. However, minimal discussion of the paper's contents has occurred, other than Peter Todd's reaction on Reddit. The paper suggests that sidechains will be secure because they use DMMS (distributed market-based mechanism security), which is also used by alt-coins but not as secure as Bitcoin. The authors mention a problem with hashpower attack resistance that needs to be solved before the proposal is viable.Adam Back and his co-authors published a paper on side-chains, two-way pegs, and compact SPV proofs. The paper outlines how Bitcoin can be moved into and out of a side-chain to achieve interoperability. There is a discussion about Satoshi's whitepaper and terminology related to Bitcoin, altcoins, altchains, and blockchains. Two-way pegging is discussed as a way to enable interoperability between Bitcoin and side-chains using SPV proofs of burn. The concept of a beta network is also proposed to test new features before implementing them on the main network.Daniel Murrell posted a paper on a mailing list and requested feedback on his website. Bryan Bishop responded, suggesting that the frequency of these messages should be toned down. Jeff Garzik, a Bitcoin core developer, also participated in the discussion. The main topic of discussion is the paper and side-chains.In an email exchange, Daniel Murrell apologized for posting his paper to a mailing list and advertising it on his website. Bryan Bishop responded, suggesting that Murrell should tone down the frequency of his posts. The discussion focuses on the paper and side-chains.A person named Daniel Murrell sent a message stating that he was not trying to monetize his website but simply wanted to create something useful. Another user named Bryan responded, suggesting toning down the frequency of posts. Bryan's contact information was included in the message.The email thread discusses enabling blockchain innovations with pegged sidechains. A paper by Adam Back and other authors describes how Bitcoin can be moved into and out of side chains with different parameters or experimental features. Greg Maxwell proposed a compact way to do 2-way pegging using SPV proofs. Private chains are also discussed as a possibility for higher scaling while retaining Bitcoin security properties.The Bitcoin community has developed a process called 2-way pegging, allowing users to move Bitcoin between the main blockchain and side chains with different parameters or experimental features. The discussion involves several Bitcoin experts, including Greg Maxwell, Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach. 2014-11-03T19:38:27+00:00 + The provided context includes a PGP signed message with a hash value of SHA512, containing links to two cryptography-related websites: IACR and DES. The first link leads to the proceedings of Eurocrypt 2002, a conference on cryptology, while the second link directs to the accepted papers for Asiacrypt 2014, another cryptographic conference. Within these links, there is a message from Andrew Poelstra mentioning a "false proof" without further explanation. The authenticity and integrity of the message are confirmed by the signature at the end.The discussion revolves around the distinction between hardness and likelihood of successful attack. It is explained that fraudulent transfers can occur without reorganization if an attacker produces a fake SPV proof. This type of attack does not require the attacker to own coins. However, in the absence of reorganization, the false proof will be invalidated by proof of longer work on the real chain.There is a conversation between Alex Mizrahi and an unknown person discussing the security model of sidechains. It is argued that anyone with sufficient hashpower can unlock a locked coin on the parent chain by producing an SPV proof. However, if the majority of sidechain miners continue working on the honest chain, a reorg proof can be submitted during the contest period to invalidate this "unlockment" on the parent chain. The security model of sidechains relies on the assumption that an attacker won't control a majority of the network.The article explains the concept of miners in blockchain technology and how they prove computational work to achieve stable consensus on the blockchain history. Sidechains are discussed, where anyone with sufficient hashpower can unlock a locked coin on the parent chain by producing an SPV proof. This eliminates the incentive for miners to behave honestly in sidechains as they only receive transaction fees as rewards. The security of sidechains is compared to Bitcoin's security, relying on the assumption that an attacker won't control a majority of the network.In a mailing list discussion, Alex Mizrahi criticizes a paper on sidechains as "wishful thinking," arguing that it is based on the assumption that Bitcoin's decentralized mining model is secure, which he believes may not always be true. The paper discusses hashpower attacks and reorganizations and suggests longer contest periods for transfers to make fraudulent transfers more difficult.A paper on side-chains, two-way pegs, and compact SPV proofs has been written by Blockstream, Andrew Poelstra, and Andrew Miller. However, minimal discussion of the paper's contents has occurred, other than Peter Todd's reaction on Reddit. The paper suggests that sidechains will be secure because they use DMMS (distributed market-based mechanism security), which is also used by alt-coins but not as secure as Bitcoin. The authors mention a problem with hashpower attack resistance that needs to be solved before the proposal is viable.Adam Back and his co-authors published a paper on side-chains, two-way pegs, and compact SPV proofs. The paper outlines how Bitcoin can be moved into and out of a side-chain to achieve interoperability. There is a discussion about Satoshi's whitepaper and terminology related to Bitcoin, altcoins, altchains, and blockchains. Two-way pegging is discussed as a way to enable interoperability between Bitcoin and side-chains using SPV proofs of burn. The concept of a beta network is also proposed to test new features before implementing them on the main network.Daniel Murrell posted a paper on a mailing list and requested feedback on his website. Bryan Bishop responded, suggesting that the frequency of these messages should be toned down. Jeff Garzik, a Bitcoin core developer, also participated in the discussion. The main topic of discussion is the paper and side-chains.In an email exchange, Daniel Murrell apologized for posting his paper to a mailing list and advertising it on his website. Bryan Bishop responded, suggesting that Murrell should tone down the frequency of his posts. The discussion focuses on the paper and side-chains.A person named Daniel Murrell sent a message stating that he was not trying to monetize his website but simply wanted to create something useful. Another user named Bryan responded, suggesting toning down the frequency of posts. Bryan's contact information was included in the message.The email thread discusses enabling blockchain innovations with pegged sidechains. A paper by Adam Back and other authors describes how Bitcoin can be moved into and out of side chains with different parameters or experimental features. Greg Maxwell proposed a compact way to do 2-way pegging using SPV proofs. Private chains are also discussed as a possibility for higher scaling while retaining Bitcoin security properties.The Bitcoin community has developed a process called 2-way pegging, allowing users to move Bitcoin between the main blockchain and side chains with different parameters or experimental features. The discussion involves several Bitcoin experts, including Greg Maxwell, Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_-BIP-Normalized-transaction-IDs.xml b/static/bitcoin-dev/Oct_2015/combined_-BIP-Normalized-transaction-IDs.xml index 6843c0f165..0a6214f261 100644 --- a/static/bitcoin-dev/Oct_2015/combined_-BIP-Normalized-transaction-IDs.xml +++ b/static/bitcoin-dev/Oct_2015/combined_-BIP-Normalized-transaction-IDs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP] Normalized transaction IDs - 2023-08-01T16:41:42.999183+00:00 + 2025-10-11T22:09:06.529638+00:00 + python-feedgen Christian Decker 2015-11-06 14:52:49+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - [BIP] Normalized transaction IDs - 2023-08-01T16:41:43.000706+00:00 + 2025-10-11T22:09:06.529826+00:00 - In an email exchange, Jorge Timón and Christian Decker discuss the issue of malleability in Bitcoin transactions. They argue that there is confusion between conflicting spends and signature malleability, and Segregated Witnesses could solve the latter. However, they agree that a good migration plan for Bitcoin needs to be found.The discussion highlights that wallets are addressing malleability in acceptable ways but face problems with second and third level malleability. For example, if an unconfirmed transaction's ID changes due to malleability, subsequent transactions become invalid. Additionally, certain types of contracts are not fully safe due to malleability.The authors disagree on the significance of "signature malleability," with one asserting its importance and the other suggesting it is not problematic.A proposed solution involves creating a new public key type, address type, and signature type to prevent double spending via simultaneous equation. However, this solution does not enforce no pubkey reuse and may put pressure on transactional storage.Luke Dashjr and an anonymous speaker discuss the issue of "signature malleability." While one believes it is not a problem, the other argues that segregated witnesses can solve it and be useful in practical cases. They also note the importance of looking at scriptPubKeys instead of transaction IDs.In a Bitcoin-dev mailing list conversation, confusion arises regarding the term "malleability" and its scope. Some argue that it only applies to signature malleability, while others argue that conflicting spends should also be addressed. Ultimately, it is agreed upon that all forms of malleability should be addressed in any practical solution.Luke Dashjr and Christian Decker discuss the issue of malleability in Bitcoin. They discuss the problem of single signers double-spending their outputs and the limitations of segregated witnesses in solving this issue. They also discuss the definition of malleability and its implications for Bitcoin transactions.The conversation discusses a solution for the normalization issue in the Bitcoin network. The proposed solution involves having a connected component of upgraded nodes that relay both the transaction and associated external scripts. Non-upgraded nodes will only parse the classical transaction, dropping the external script. To ensure this solution works, a long rollout phase before activation is suggested.Christian Decker proposes a solution for malleability in Bitcoin transactions, involving piggybacking external scripts onto normal messages. Non-upgraded nodes will ignore the external script. Luke Dashjr suggests enforcing no-address-reuse rule on received payments to make an anti-malleable wallet. However, this does not address the issue of double spending unconfirmed outputs.Luke Dashjr and Christian Decker discuss the idea of having empty scriptsigs and shipping signatures in external scripts. The proposal uses on-the-fly normalization, but a better solution is sought. Luke suggests making wallets add more outputs to unconfirmed transactions instead of spending unconfirmed change.Christian Decker discusses piggybacking external scripts onto normal messages in Bitcoin transactions. Non-upgraded nodes will read the entire message but only parse the classical transaction, ignoring the external script. He is open to suggestions for a better solution. A possible upgrade for wallets is also mentioned.Christian Decker provides an update on the proposed Bitcoin Improvement Proposal (BIP), mentioning changes made to the proposal. He expresses doubt about fixing malleability and asks about the perfect properties for such a fix. Luke Dashjr argues that wallets should add more outputs to unconfirmed transactions. Gregory Maxwell cautions against overselling certain ideas.The discussions on normalized transaction IDs within smart contracts continue. Suggestions are made regarding treating singlesig transactions as 1-of-1 transactions and using Schnorr signatures. The bitmap of flags could be replaced with a simple version number. However, caution is advised in overselling these ideas.In an email thread, Christian Decker comments on the scenario of a single signer re-ordering the outputs and inputs of a transaction. He believes that even with a canonical ordering, this action could still occur. Luke argues that wallets should add more outputs to unconfirmed transactions.In 2015, Christian Decker proposed a new implementation for normalized transaction IDs and storing them with coin state. However, Luke Dashjr expressed concern that this proposal doesn't completely close malleability and suggested specifying flags upfront in the UTXO-creating transaction to allow for fully malleability-proof wallets. He also pointed out that the flag to control whether the opcode behaves as VERIFY or not must be mandatory to guarantee successful evaluation on non-updated clients.The discussion revolves around the issue of malleability in Bitcoin transactions. While some believe that specifying flags upfront in the UTXO-creating transaction could allow for implementation of fully malleability-proof wallets, others argue that the use of non-sighash_all flags still poses a threat to the security of transactions. Signer malleability is also a concern needing consideration, and it is suggested that wallets should actively CoinJoin, bump fees on, etc any pending transactions in the background to prevent these 2015-11-06T14:52:49+00:00 + In an email exchange, Jorge Timón and Christian Decker discuss the issue of malleability in Bitcoin transactions. They argue that there is confusion between conflicting spends and signature malleability, and Segregated Witnesses could solve the latter. However, they agree that a good migration plan for Bitcoin needs to be found.The discussion highlights that wallets are addressing malleability in acceptable ways but face problems with second and third level malleability. For example, if an unconfirmed transaction's ID changes due to malleability, subsequent transactions become invalid. Additionally, certain types of contracts are not fully safe due to malleability.The authors disagree on the significance of "signature malleability," with one asserting its importance and the other suggesting it is not problematic.A proposed solution involves creating a new public key type, address type, and signature type to prevent double spending via simultaneous equation. However, this solution does not enforce no pubkey reuse and may put pressure on transactional storage.Luke Dashjr and an anonymous speaker discuss the issue of "signature malleability." While one believes it is not a problem, the other argues that segregated witnesses can solve it and be useful in practical cases. They also note the importance of looking at scriptPubKeys instead of transaction IDs.In a Bitcoin-dev mailing list conversation, confusion arises regarding the term "malleability" and its scope. Some argue that it only applies to signature malleability, while others argue that conflicting spends should also be addressed. Ultimately, it is agreed upon that all forms of malleability should be addressed in any practical solution.Luke Dashjr and Christian Decker discuss the issue of malleability in Bitcoin. They discuss the problem of single signers double-spending their outputs and the limitations of segregated witnesses in solving this issue. They also discuss the definition of malleability and its implications for Bitcoin transactions.The conversation discusses a solution for the normalization issue in the Bitcoin network. The proposed solution involves having a connected component of upgraded nodes that relay both the transaction and associated external scripts. Non-upgraded nodes will only parse the classical transaction, dropping the external script. To ensure this solution works, a long rollout phase before activation is suggested.Christian Decker proposes a solution for malleability in Bitcoin transactions, involving piggybacking external scripts onto normal messages. Non-upgraded nodes will ignore the external script. Luke Dashjr suggests enforcing no-address-reuse rule on received payments to make an anti-malleable wallet. However, this does not address the issue of double spending unconfirmed outputs.Luke Dashjr and Christian Decker discuss the idea of having empty scriptsigs and shipping signatures in external scripts. The proposal uses on-the-fly normalization, but a better solution is sought. Luke suggests making wallets add more outputs to unconfirmed transactions instead of spending unconfirmed change.Christian Decker discusses piggybacking external scripts onto normal messages in Bitcoin transactions. Non-upgraded nodes will read the entire message but only parse the classical transaction, ignoring the external script. He is open to suggestions for a better solution. A possible upgrade for wallets is also mentioned.Christian Decker provides an update on the proposed Bitcoin Improvement Proposal (BIP), mentioning changes made to the proposal. He expresses doubt about fixing malleability and asks about the perfect properties for such a fix. Luke Dashjr argues that wallets should add more outputs to unconfirmed transactions. Gregory Maxwell cautions against overselling certain ideas.The discussions on normalized transaction IDs within smart contracts continue. Suggestions are made regarding treating singlesig transactions as 1-of-1 transactions and using Schnorr signatures. The bitmap of flags could be replaced with a simple version number. However, caution is advised in overselling these ideas.In an email thread, Christian Decker comments on the scenario of a single signer re-ordering the outputs and inputs of a transaction. He believes that even with a canonical ordering, this action could still occur. Luke argues that wallets should add more outputs to unconfirmed transactions.In 2015, Christian Decker proposed a new implementation for normalized transaction IDs and storing them with coin state. However, Luke Dashjr expressed concern that this proposal doesn't completely close malleability and suggested specifying flags upfront in the UTXO-creating transaction to allow for fully malleability-proof wallets. He also pointed out that the flag to control whether the opcode behaves as VERIFY or not must be mandatory to guarantee successful evaluation on non-updated clients.The discussion revolves around the issue of malleability in Bitcoin transactions. While some believe that specifying flags upfront in the UTXO-creating transaction could allow for implementation of fully malleability-proof wallets, others argue that the use of non-sighash_all flags still poses a threat to the security of transactions. Signer malleability is also a concern needing consideration, and it is suggested that wallets should actively CoinJoin, bump fees on, etc any pending transactions in the background to prevent these - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_-no-subject-.xml b/static/bitcoin-dev/Oct_2015/combined_-no-subject-.xml index a09c8867b3..01137e8933 100644 --- a/static/bitcoin-dev/Oct_2015/combined_-no-subject-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_-no-subject-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - (no subject) - 2023-08-01T05:01:33.099019+00:00 + 2025-10-11T22:09:04.402719+00:00 + python-feedgen Btc Drak 2016-10-17 13:13:25+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - (no subject) - 2023-08-01T05:01:33.099019+00:00 + 2025-10-11T22:09:04.402874+00:00 - On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. 2016-10-17T13:13:25+00:00 + On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_-patch-Switching-Bitcoin-Core-to-sqlite-db.xml b/static/bitcoin-dev/Oct_2015/combined_-patch-Switching-Bitcoin-Core-to-sqlite-db.xml index 93450aecf3..e273139b53 100644 --- a/static/bitcoin-dev/Oct_2015/combined_-patch-Switching-Bitcoin-Core-to-sqlite-db.xml +++ b/static/bitcoin-dev/Oct_2015/combined_-patch-Switching-Bitcoin-Core-to-sqlite-db.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [patch] Switching Bitcoin Core to sqlite db - 2023-08-01T16:45:02.908700+00:00 + 2025-10-11T22:08:13.403387+00:00 + python-feedgen Jorge Timón 2015-11-20 14:15:20+00:00 @@ -147,13 +148,13 @@ - python-feedgen + 2 Combined summary - [patch] Switching Bitcoin Core to sqlite db - 2023-08-01T16:45:02.909734+00:00 + 2025-10-11T22:08:13.403624+00:00 - The discussions focused on the issue of consensus failures in Bitcoin. There are two types of consensus failures to consider: Type 1, where one implementation says "yes" or "no" while the other says "I don't know," and Type 2, where one implementation says "yes" and the other says "no" due to a bug. It was suggested that multiple competing implementations should be used to address these issues. In the event of a Type 2 failure, it was proposed that Core should accept a rogue transaction that creates more bitcoins and allow other implementations to fork away from it. The conversation also touched on the classification of consensus failures and the philosophical aspects of Bitcoin governance.In another discussion, the use of RocksDB as a replacement for LevelDB in Bitcoin was mentioned. While RocksDB is optimized for big databases running on multiple cores, concerns were raised about its suitability for spinning disks. The reliability of LevelDB was also discussed, with participants expressing their intention to explore alternative options due to bugs and reliability issues. Despite its challenges, LevelDB has remained popular among Bitcoin developers for its simplicity and ease of use.The importance of UTXO storage in Bitcoin was emphasized, as the choice of database technology can impact consensus protocol failure. Consistency between all nodes was deemed more important than having "right" UTXO storage. Inconsistencies in database behavior can lead to inconsistencies in consensus state and potential theft. The need for vigilance in identifying possible errors and ensuring equivalence under all inputs was highlighted.Bitcoin Unlimited explored the concept of "meta-cognition" to decentralize development and promote bottom-up governance. The conversation discussed the challenges of using multiple database technologies in Bitcoin and the potential for inconsistencies in determining the validity of transactions across nodes.Jeff Garzik has started working on an implementation to replace LevelDB with SQLite. The implementation is still a work in progress and needs further testing. It has been suggested that instead of implementing it as a replacement, multiple backends should be supported to allow for migration. The author also recommends considering LMDB as an alternative, but notes its limitations on 32-bit systems requiring over 2gb of storage.Overall, the Bitcoin project is actively exploring alternatives to the unmaintained LevelDB database. Jeff Garzik's implementation to replace LevelDB with SQLite is currently underway, but still needs further testing and refinement. The goal is to find a maintained and reliable alternative to LevelDB. 2015-11-20T14:15:20+00:00 + The discussions focused on the issue of consensus failures in Bitcoin. There are two types of consensus failures to consider: Type 1, where one implementation says "yes" or "no" while the other says "I don't know," and Type 2, where one implementation says "yes" and the other says "no" due to a bug. It was suggested that multiple competing implementations should be used to address these issues. In the event of a Type 2 failure, it was proposed that Core should accept a rogue transaction that creates more bitcoins and allow other implementations to fork away from it. The conversation also touched on the classification of consensus failures and the philosophical aspects of Bitcoin governance.In another discussion, the use of RocksDB as a replacement for LevelDB in Bitcoin was mentioned. While RocksDB is optimized for big databases running on multiple cores, concerns were raised about its suitability for spinning disks. The reliability of LevelDB was also discussed, with participants expressing their intention to explore alternative options due to bugs and reliability issues. Despite its challenges, LevelDB has remained popular among Bitcoin developers for its simplicity and ease of use.The importance of UTXO storage in Bitcoin was emphasized, as the choice of database technology can impact consensus protocol failure. Consistency between all nodes was deemed more important than having "right" UTXO storage. Inconsistencies in database behavior can lead to inconsistencies in consensus state and potential theft. The need for vigilance in identifying possible errors and ensuring equivalence under all inputs was highlighted.Bitcoin Unlimited explored the concept of "meta-cognition" to decentralize development and promote bottom-up governance. The conversation discussed the challenges of using multiple database technologies in Bitcoin and the potential for inconsistencies in determining the validity of transactions across nodes.Jeff Garzik has started working on an implementation to replace LevelDB with SQLite. The implementation is still a work in progress and needs further testing. It has been suggested that instead of implementing it as a replacement, multiple backends should be supported to allow for migration. The author also recommends considering LMDB as an alternative, but notes its limitations on 32-bit systems requiring over 2gb of storage.Overall, the Bitcoin project is actively exploring alternatives to the unmaintained LevelDB database. Jeff Garzik's implementation to replace LevelDB with SQLite is currently underway, but still needs further testing and refinement. The goal is to find a maintained and reliable alternative to LevelDB. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-Core-0-11-1-release-candidate-2-available.xml b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-Core-0-11-1-release-candidate-2-available.xml index 6d65a4826b..b91ec257ad 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-Core-0-11-1-release-candidate-2-available.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-Core-0-11-1-release-candidate-2-available.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.11.1 release candidate 2 available - 2023-08-01T16:35:10.199971+00:00 + 2025-10-11T22:09:10.778367+00:00 + python-feedgen Wladimir J. van der Laan 2015-10-14 09:31:33+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.11.1 release candidate 2 available - 2023-08-01T16:35:10.199971+00:00 + 2025-10-11T22:09:10.778518+00:00 - Bitcoin Core versions 0.11.1 and 0.10.3 have been released, with the aim of improving security and trust in the software. Gitian builds are being used to ensure that the binaries distributed are produced from verified source code. Version 0.11.1 includes bug fixes and improvements such as changes to transaction relaying, better handling of orphaned blocks, and an increase in the default number of outbound connections. Version 0.10.3 is a maintenance release with security fixes and backports from the 0.11.x branch.The release of these versions comes at a time when the Bitcoin community is still debating the block size issue. Some users advocate for a larger block size limit to allow for more transactions per block, while others argue that this would centralize the network. The Bitcoin Core development team has not taken a stance on the issue, but they prioritize security and stability. The release of Bitcoin Core versions 0.11.1 and 0.10.3 demonstrates the commitment to improving the protocol's security and reliability. By using gitian builds, users can be confident that the code they are running is exactly what the developers intended, with no unauthorized changes or additions.In addition, Bitcoin Core version 0.11.1 release candidate 2 has been announced, providing a new minor version release with security fixes. Users are encouraged to upgrade or downgrade if necessary. This latest version addresses a buffer overflow issue in the XML parser during initial network discovery and disables upnp by default to prevent future libupnpc vulnerabilities. The minimum relay fee default has also increased from `0.00001` to `0.00005`. 2015-10-14T09:31:33+00:00 + Bitcoin Core versions 0.11.1 and 0.10.3 have been released, with the aim of improving security and trust in the software. Gitian builds are being used to ensure that the binaries distributed are produced from verified source code. Version 0.11.1 includes bug fixes and improvements such as changes to transaction relaying, better handling of orphaned blocks, and an increase in the default number of outbound connections. Version 0.10.3 is a maintenance release with security fixes and backports from the 0.11.x branch.The release of these versions comes at a time when the Bitcoin community is still debating the block size issue. Some users advocate for a larger block size limit to allow for more transactions per block, while others argue that this would centralize the network. The Bitcoin Core development team has not taken a stance on the issue, but they prioritize security and stability. The release of Bitcoin Core versions 0.11.1 and 0.10.3 demonstrates the commitment to improving the protocol's security and reliability. By using gitian builds, users can be confident that the code they are running is exactly what the developers intended, with no unauthorized changes or additions.In addition, Bitcoin Core version 0.11.1 release candidate 2 has been announced, providing a new minor version release with security fixes. Users are encouraged to upgrade or downgrade if necessary. This latest version addresses a buffer overflow issue in the XML parser during initial network discovery and disables upnp by default to prevent future libupnpc vulnerabilities. The minimum relay fee default has also increased from `0.00001` to `0.00005`. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-Core-0-12-0-release-schedule.xml b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-Core-0-12-0-release-schedule.xml index 7a719c5f55..07275876df 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-Core-0-12-0-release-schedule.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-Core-0-12-0-release-schedule.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.12.0 release schedule - 2023-08-01T16:16:06.482460+00:00 + 2025-10-11T22:08:53.770044+00:00 + python-feedgen Btc Drak 2015-10-01 09:17:52+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.12.0 release schedule - 2023-08-01T16:16:06.482460+00:00 + 2025-10-11T22:08:53.770233+00:00 - In a Bitcoin developer email thread in October 2015, Marcel Jamin questioned the versioning of Bitcoin and its alignment with SemVer specifications. Another developer responded by explaining that Bitcoin does follow the SemVer standard, using the format a.b.c, with major releases represented by a new second digit and maintenance releases indicated by a third digit change. The email thread sheds light on the technical aspects of Bitcoin development and emphasizes the importance of adhering to industry standards.In a bitcoin-dev mailing list discussion in 2015, Wladimir J. van der Laan, Bitcoin Core's lead maintainer, addressed the versioning of Bitcoin software not following the Semantic Versioning (SemVer) specification. Van der Laan mentioned that only critical bug fixes would be included in the feature freeze for version 0.12 and that postponing the release for consensus changes was not ideal. He also acknowledged the idea of decoupling consensus changes from major releases to avoid release date drift. The conversation concluded with the suggestion of creating a 0.12.1 release if necessary.On September 24th, 2015, van der Laan announced a feature freeze for Bitcoin Core 0.12 on December 1st of that year. Luke Dashjr responded by expressing concern about postponing the release and the potential delay it could cause in developing, testing, and reviewing new code. Dashjr also highlighted the issue of release date drift due to changes needing to be added. Van der Laan clarified that the feature freeze meant only critical bug fixes could be made to version 0.12 but acknowledged the benefits of decoupling consensus changes from major releases. He suggested the possibility of a 0.12.1 release if needed.In another discussion on the Bitcoin-dev mailing list, Luke Dashjr initiated a conversation about the consensus freeze for the upcoming Bitcoin Core release. Dashjr recommended postponing the consensus freeze until after the HK workshop in case a hardfork was decided on. He also questioned whether the consensus freeze had been entirely decoupled from the release process, considering that old versions required an update as well. The discussion did not provide specific information about the outcome or decision regarding the consensus freeze.During this ongoing discussion around updates to the Bitcoin protocol in September 2015, a member expressed their belief that consensus rule changes could be minor releases if they were not ready in time for a major release. Luke Dashjr raised concerns about the absence of a "Consensus freeze" and suggested postponing it until after the HK workshop in case a hardfork was decided on. The conversation aimed to address various aspects of the Bitcoin protocol development.Wladimir J. van der Laan announced a feature freeze on the Bitcoin protocol for December 1, 2015, via bitcoin-dev on September 24, 2015. However, Luke questioned the absence of a "Consensus freeze" and proposed delaying it until after the HK workshop in case a hardfork was decided on. Luke also raised concerns about the potential decoupling of the consensus freeze from the release process, as old versions would still require an update.According to a post by Wladimir J. van der Laan on the Bitcoin development mailing list, the next major release of Bitcoin Core, 0.12.0, is planned for the end of 2015. The proposed schedule includes opening Transifex translations for 0.12 on November 1st, finalizing and closing translation for 0.10, and implementing a feature freeze and translation string freeze on December 1st. In January, the plan is to split off the `0.12` branch from `master`, start the RC cycle, tag and release `0.12.0rc1`, and begin merging for 0.13 on the master branch. The final release of version 0.12.0 is expected on February 1st, 2016. Due to events such as Scaling Bitcoin Hongkong and end-of-year festivities in December, pre-RC bugfixes and polishing will be postponed.The Bitcoin Core team is preparing for the next major release, 0.12.0, by the end of the year. The proposed schedule involves opening Transifex translations for 0.12 on November 1st, with a soft translation string freeze to avoid unnecessary changes. On December 1st, a feature and translation string freeze will take place. In January, the team plans to split off the `0.12` branch from `master`, initiate the RC cycle, tag and release `0.12.0rc1`, and begin merging for 0.13 on the master branch. The final release of version 0.12.0 is anticipated for February 1st. As many team members will be occupied with events like Scaling Bitcoin Hongkong and end-of-year festivities in December, pre-RC bugfixes and polishing tasks will be deferred 2015-10-01T09:17:52+00:00 + In a Bitcoin developer email thread in October 2015, Marcel Jamin questioned the versioning of Bitcoin and its alignment with SemVer specifications. Another developer responded by explaining that Bitcoin does follow the SemVer standard, using the format a.b.c, with major releases represented by a new second digit and maintenance releases indicated by a third digit change. The email thread sheds light on the technical aspects of Bitcoin development and emphasizes the importance of adhering to industry standards.In a bitcoin-dev mailing list discussion in 2015, Wladimir J. van der Laan, Bitcoin Core's lead maintainer, addressed the versioning of Bitcoin software not following the Semantic Versioning (SemVer) specification. Van der Laan mentioned that only critical bug fixes would be included in the feature freeze for version 0.12 and that postponing the release for consensus changes was not ideal. He also acknowledged the idea of decoupling consensus changes from major releases to avoid release date drift. The conversation concluded with the suggestion of creating a 0.12.1 release if necessary.On September 24th, 2015, van der Laan announced a feature freeze for Bitcoin Core 0.12 on December 1st of that year. Luke Dashjr responded by expressing concern about postponing the release and the potential delay it could cause in developing, testing, and reviewing new code. Dashjr also highlighted the issue of release date drift due to changes needing to be added. Van der Laan clarified that the feature freeze meant only critical bug fixes could be made to version 0.12 but acknowledged the benefits of decoupling consensus changes from major releases. He suggested the possibility of a 0.12.1 release if needed.In another discussion on the Bitcoin-dev mailing list, Luke Dashjr initiated a conversation about the consensus freeze for the upcoming Bitcoin Core release. Dashjr recommended postponing the consensus freeze until after the HK workshop in case a hardfork was decided on. He also questioned whether the consensus freeze had been entirely decoupled from the release process, considering that old versions required an update as well. The discussion did not provide specific information about the outcome or decision regarding the consensus freeze.During this ongoing discussion around updates to the Bitcoin protocol in September 2015, a member expressed their belief that consensus rule changes could be minor releases if they were not ready in time for a major release. Luke Dashjr raised concerns about the absence of a "Consensus freeze" and suggested postponing it until after the HK workshop in case a hardfork was decided on. The conversation aimed to address various aspects of the Bitcoin protocol development.Wladimir J. van der Laan announced a feature freeze on the Bitcoin protocol for December 1, 2015, via bitcoin-dev on September 24, 2015. However, Luke questioned the absence of a "Consensus freeze" and proposed delaying it until after the HK workshop in case a hardfork was decided on. Luke also raised concerns about the potential decoupling of the consensus freeze from the release process, as old versions would still require an update.According to a post by Wladimir J. van der Laan on the Bitcoin development mailing list, the next major release of Bitcoin Core, 0.12.0, is planned for the end of 2015. The proposed schedule includes opening Transifex translations for 0.12 on November 1st, finalizing and closing translation for 0.10, and implementing a feature freeze and translation string freeze on December 1st. In January, the plan is to split off the `0.12` branch from `master`, start the RC cycle, tag and release `0.12.0rc1`, and begin merging for 0.13 on the master branch. The final release of version 0.12.0 is expected on February 1st, 2016. Due to events such as Scaling Bitcoin Hongkong and end-of-year festivities in December, pre-RC bugfixes and polishing will be postponed.The Bitcoin Core team is preparing for the next major release, 0.12.0, by the end of the year. The proposed schedule involves opening Transifex translations for 0.12 on November 1st, with a soft translation string freeze to avoid unnecessary changes. On December 1st, a feature and translation string freeze will take place. In January, the team plans to split off the `0.12` branch from `master`, initiate the RC cycle, tag and release `0.12.0rc1`, and begin merging for 0.13 on the master branch. The final release of version 0.12.0 is anticipated for February 1st. As many team members will be occupied with events like Scaling Bitcoin Hongkong and end-of-year festivities in December, pre-RC bugfixes and polishing tasks will be deferred - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-NG-whitepaper-.xml b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-NG-whitepaper-.xml index eb6c369b58..a8431c121a 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-NG-whitepaper-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-NG-whitepaper-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin-NG whitepaper. - 2023-08-01T16:38:14.268302+00:00 + 2025-10-11T22:08:04.903292+00:00 + python-feedgen Emin Gün Sirer 2015-11-09 18:33:27+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - Bitcoin-NG whitepaper. - 2023-08-01T16:38:14.269303+00:00 + 2025-10-11T22:08:04.903517+00:00 - On October 14, 2015, a conversation took place among Bitcoin developers regarding the use of microblocks in the Bitcoin-NG protocol. One issue raised was the lack of a mechanism to punish individuals involved in a double spend in a microblock that occurs in a key block, which reorganizes away the first transaction. It was suggested that users should wait before accepting a transaction to ensure no key-block was missed. Additionally, an attacker could continuously double spend by immediately mining a key block after sending a transaction and creating a microblock that double-spends the previous transaction.The confirmation time for microblocks may not need to be a full key-block, but it should be long enough for the attacker to lose more fees than the value of their double-spend. There was also discussion about the implementation of Bitcoin-NG and its compatibility with Bitcoin and Blockstream-like sidechains. It was suggested that NG could support privacy measures such as stealth sends or confidential transactions. NG could potentially be implemented as a feature in Bitcoin Core that users can activate or deactivate. Concerns were raised about managing and protecting information in the NG scheme, including references to previous blocks, current GMT times, cryptographic hashes of ledger entries, and cryptographic signatures of headers. The question of whether NG can support privacy measures remains unanswered.The Bitcoin-NG protocol aims to address scalability challenges faced by Bitcoin by increasing throughput and reducing latency without changing Bitcoin's trust model or open architecture. The whitepaper provides detailed information on the protocol, which involves electing a "leader" who vets future transactions. There are two options for the overlay-NG that runs on top of Bitcoin: significantly reduce observed latency or increase bandwidth once everyone is on board. Microblocks in Bitcoin-NG contain ledger entries and a header, but they do not affect the weight of the chain because they do not contain proof of work. The actual leader in NG is a key, not a specific node.Bob McElrath proposed that shutting down Bitcoin-NG could be done by identifying the current leader and launching a DDoS attack on them. Emin Gün Sirer countered this by explaining that Bitcoin-NG is designed to mitigate DDoS attacks by dynamically migrating the leader within the network. He also mentioned that defenses against DDoS attacks on miners can be applied to Bitcoin-NG as well. The success of Matt Corallo's high-speed bitcoin relay network has contributed to the rarity of such attacks.Ittay responded to a discussion on double-spending issues, suggesting that fraud proof could eliminate the attacker's revenue. He compared it to an attacker sacrificing an entire block for double-spending in the current system. The whitepaper provides more detailed insights into the topic.Bitcoin-NG is a technique specifically designed to tackle scalability challenges faced by Bitcoin. This approach increases throughput while reducing latency without compromising Bitcoin's open architecture or trust model. The creators of Bitcoin-NG do not intend to compete commercially with Bitcoin or Blockstream-like sidechains but rather see it as complementary. They aim to advance blockchain technology and inspire further innovations. Feedback from the community is encouraged. One comment suggests considering a miner's ability to choose the key block time to generate more miniblocks.In an email conversation, Emin Gün Sirer discusses the difficulties of resolving double-spending issues solely through fraud proofs. He refers to a whitepaper that provides technical details on this matter. The topic was also discussed in a -wizards thread. Fidelity-bonded ledgers are recommended for a system reliant on fraud proofs and threats.Overall, Bitcoin-NG offers a potential solution to scalability challenges in Bitcoin with its increased throughput and reduced latency. However, there are still concerns regarding the implementation and privacy measures of the protocol. The conversation among developers highlighted the need for further discussion and analysis to address potential issues such as double spending in microblocks. 2015-11-09T18:33:27+00:00 + On October 14, 2015, a conversation took place among Bitcoin developers regarding the use of microblocks in the Bitcoin-NG protocol. One issue raised was the lack of a mechanism to punish individuals involved in a double spend in a microblock that occurs in a key block, which reorganizes away the first transaction. It was suggested that users should wait before accepting a transaction to ensure no key-block was missed. Additionally, an attacker could continuously double spend by immediately mining a key block after sending a transaction and creating a microblock that double-spends the previous transaction.The confirmation time for microblocks may not need to be a full key-block, but it should be long enough for the attacker to lose more fees than the value of their double-spend. There was also discussion about the implementation of Bitcoin-NG and its compatibility with Bitcoin and Blockstream-like sidechains. It was suggested that NG could support privacy measures such as stealth sends or confidential transactions. NG could potentially be implemented as a feature in Bitcoin Core that users can activate or deactivate. Concerns were raised about managing and protecting information in the NG scheme, including references to previous blocks, current GMT times, cryptographic hashes of ledger entries, and cryptographic signatures of headers. The question of whether NG can support privacy measures remains unanswered.The Bitcoin-NG protocol aims to address scalability challenges faced by Bitcoin by increasing throughput and reducing latency without changing Bitcoin's trust model or open architecture. The whitepaper provides detailed information on the protocol, which involves electing a "leader" who vets future transactions. There are two options for the overlay-NG that runs on top of Bitcoin: significantly reduce observed latency or increase bandwidth once everyone is on board. Microblocks in Bitcoin-NG contain ledger entries and a header, but they do not affect the weight of the chain because they do not contain proof of work. The actual leader in NG is a key, not a specific node.Bob McElrath proposed that shutting down Bitcoin-NG could be done by identifying the current leader and launching a DDoS attack on them. Emin Gün Sirer countered this by explaining that Bitcoin-NG is designed to mitigate DDoS attacks by dynamically migrating the leader within the network. He also mentioned that defenses against DDoS attacks on miners can be applied to Bitcoin-NG as well. The success of Matt Corallo's high-speed bitcoin relay network has contributed to the rarity of such attacks.Ittay responded to a discussion on double-spending issues, suggesting that fraud proof could eliminate the attacker's revenue. He compared it to an attacker sacrificing an entire block for double-spending in the current system. The whitepaper provides more detailed insights into the topic.Bitcoin-NG is a technique specifically designed to tackle scalability challenges faced by Bitcoin. This approach increases throughput while reducing latency without compromising Bitcoin's open architecture or trust model. The creators of Bitcoin-NG do not intend to compete commercially with Bitcoin or Blockstream-like sidechains but rather see it as complementary. They aim to advance blockchain technology and inspire further innovations. Feedback from the community is encouraged. One comment suggests considering a miner's ability to choose the key block time to generate more miniblocks.In an email conversation, Emin Gün Sirer discusses the difficulties of resolving double-spending issues solely through fraud proofs. He refers to a whitepaper that provides technical details on this matter. The topic was also discussed in a -wizards thread. Fidelity-bonded ledgers are recommended for a system reliant on fraud proofs and threats.Overall, Bitcoin-NG offers a potential solution to scalability challenges in Bitcoin with its increased throughput and reduced latency. However, there are still concerns regarding the implementation and privacy measures of the protocol. The conversation among developers highlighted the need for further discussion and analysis to address potential issues such as double spending in microblocks. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-URI-for-multiple-addresses-without-using-URLs.xml b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-URI-for-multiple-addresses-without-using-URLs.xml index 6b3ac00bf1..4489feadb8 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-URI-for-multiple-addresses-without-using-URLs.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-URI-for-multiple-addresses-without-using-URLs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin URI for multiple addresses without using URLs - 2023-08-01T16:46:20.311116+00:00 + 2025-10-11T22:08:30.401554+00:00 + python-feedgen Andreas Schildbach 2015-10-27 09:12:52+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Bitcoin URI for multiple addresses without using URLs - 2023-08-01T16:46:20.311116+00:00 + 2025-10-11T22:08:30.401707+00:00 - In a recent query posted on the bitcoin-dev community, a member named Will White was interested in creating a website that would allow his bitcoin wallet program to donate to multiple addresses simultaneously. Rather than including a URL and having the wallet locate the information, he wanted to send his wallet a Uniform Resource Identifier (URI) containing all the necessary details. Seeking advice on the matter, Will White wondered if it was possible to simplify the process by using BIP70 payment requests.BIP70 payment requests provide a solution to Will White's query by allowing users to specify multiple scripts or addresses to pay along with their corresponding amounts. These payment requests can be transmitted through various methods such as NFC, Bluetooth, HTTP(S), and Mail. To gain a deeper understanding of payment requests, interested individuals can refer to the following link: https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests.Will White's query on the bitcoin-dev platform revolves around the feasibility of sending a URI with all the necessary information to make donations to multiple addresses at once. Instead of relying on BIP71, which requires including a URL for the wallet to access the information, Will White aims to streamline the process. Hence, he is seeking guidance from the bitcoin-dev community regarding the possibility of implementing this idea within the context of BIPs. 2015-10-27T09:12:52+00:00 + In a recent query posted on the bitcoin-dev community, a member named Will White was interested in creating a website that would allow his bitcoin wallet program to donate to multiple addresses simultaneously. Rather than including a URL and having the wallet locate the information, he wanted to send his wallet a Uniform Resource Identifier (URI) containing all the necessary details. Seeking advice on the matter, Will White wondered if it was possible to simplify the process by using BIP70 payment requests.BIP70 payment requests provide a solution to Will White's query by allowing users to specify multiple scripts or addresses to pay along with their corresponding amounts. These payment requests can be transmitted through various methods such as NFC, Bluetooth, HTTP(S), and Mail. To gain a deeper understanding of payment requests, interested individuals can refer to the following link: https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests.Will White's query on the bitcoin-dev platform revolves around the feasibility of sending a URI with all the necessary information to make donations to multiple addresses at once. Instead of relying on BIP71, which requires including a URL for the wallet to access the information, Will White aims to streamline the process. Hence, he is seeking guidance from the bitcoin-dev community regarding the possibility of implementing this idea within the context of BIPs. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-network-simulation-testing-.xml b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-network-simulation-testing-.xml index 70d21ed10a..b6926d25e9 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Bitcoin-network-simulation-testing-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Bitcoin-network-simulation-testing-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin network simulation testing? - 2023-08-01T16:30:38.811700+00:00 + 2025-10-11T22:08:36.773588+00:00 + python-feedgen Pindar Wong 2015-10-09 22:06:47+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Bitcoin network simulation testing? - 2023-08-01T16:30:38.811700+00:00 + 2025-10-11T22:08:36.773760+00:00 - Byron Gibson, the CoS of MirrorX and a software developer, expressed his interest in collaborating with others using simulators like Shadow and BTCSim to test proposed changes to Bitcoin. He mentioned his capability to run a simulator on multiple nodes on AWS/GCE but emphasized the need for experiments that benefit from a controlled environment. However, Nina K shared her experience with running Shadow and highlighted its limitations in collecting accurate statistics when used with Tor. Andrew Miller also acknowledged the importance of simulators but noted that Shadow has its own set of limitations.In the conversation on the bitcoin-dev mailing list, Byron Gibson asked if anyone is using simulators like Shadow or BTCSim to test proposed changes to Bitcoin. Nina K responded that she had been using Shadow but found that running it with Tor slowed down her machine, potentially affecting the accuracy of collected stats. She questioned if others faced the same issue or if there was an adjustment that could be made. It was noted that while running Shadow may slow down the machine, the virtual time it uses does not affect the collected statistics. However, compared to abstract simulators, running Shadow can be unpleasant unless one has a fast machine.Nina K's experience with Shadow was shared in an email response to Byron Gibson's inquiry about the use of simulators. She believes simulators are important for testing proposed changes but pointed out that Shadow has limitations, particularly when used with Tor. Running Shadow with Tor significantly slows down her computer, making it impossible for the collected stats to be accurate. She asked if this was a common experience and if any adjustments could be made.Byron Gibson's initial query about simulators like Shadow and BTCSim was posted on the Bitcoin-dev mailing list. The two mentioned simulators are free and open-source software tools used to simulate and test blockchain protocols. Shadow simulates large-scale networks of nodes, making it suitable for testing scalability, while BTCSim tests Bitcoin node behavior in various scenarios. These simulators help identify vulnerabilities and bugs in proposed changes to the Bitcoin protocol before implementation. Byron provided links to his personal website and Keybase profile, indicating his involvement in software development and potential work related to Bitcoin. Although the purpose of his inquiry was not explicitly stated, it is clear that he wants to use simulators to test proposed changes to the Bitcoin protocol and learn more about their capabilities and limitations. 2015-10-09T22:06:47+00:00 + Byron Gibson, the CoS of MirrorX and a software developer, expressed his interest in collaborating with others using simulators like Shadow and BTCSim to test proposed changes to Bitcoin. He mentioned his capability to run a simulator on multiple nodes on AWS/GCE but emphasized the need for experiments that benefit from a controlled environment. However, Nina K shared her experience with running Shadow and highlighted its limitations in collecting accurate statistics when used with Tor. Andrew Miller also acknowledged the importance of simulators but noted that Shadow has its own set of limitations.In the conversation on the bitcoin-dev mailing list, Byron Gibson asked if anyone is using simulators like Shadow or BTCSim to test proposed changes to Bitcoin. Nina K responded that she had been using Shadow but found that running it with Tor slowed down her machine, potentially affecting the accuracy of collected stats. She questioned if others faced the same issue or if there was an adjustment that could be made. It was noted that while running Shadow may slow down the machine, the virtual time it uses does not affect the collected statistics. However, compared to abstract simulators, running Shadow can be unpleasant unless one has a fast machine.Nina K's experience with Shadow was shared in an email response to Byron Gibson's inquiry about the use of simulators. She believes simulators are important for testing proposed changes but pointed out that Shadow has limitations, particularly when used with Tor. Running Shadow with Tor significantly slows down her computer, making it impossible for the collected stats to be accurate. She asked if this was a common experience and if any adjustments could be made.Byron Gibson's initial query about simulators like Shadow and BTCSim was posted on the Bitcoin-dev mailing list. The two mentioned simulators are free and open-source software tools used to simulate and test blockchain protocols. Shadow simulates large-scale networks of nodes, making it suitable for testing scalability, while BTCSim tests Bitcoin node behavior in various scenarios. These simulators help identify vulnerabilities and bugs in proposed changes to the Bitcoin protocol before implementation. Byron provided links to his personal website and Keybase profile, indicating his involvement in software development and potential work related to Bitcoin. Although the purpose of his inquiry was not explicitly stated, it is clear that he wants to use simulators to test proposed changes to the Bitcoin protocol and learn more about their capabilities and limitations. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_CHECKSEQUENCEVERIFY-We-need-more-usecases-to-motivate-the-change.xml b/static/bitcoin-dev/Oct_2015/combined_CHECKSEQUENCEVERIFY-We-need-more-usecases-to-motivate-the-change.xml index df03d51cc2..81c29e15fb 100644 --- a/static/bitcoin-dev/Oct_2015/combined_CHECKSEQUENCEVERIFY-We-need-more-usecases-to-motivate-the-change.xml +++ b/static/bitcoin-dev/Oct_2015/combined_CHECKSEQUENCEVERIFY-We-need-more-usecases-to-motivate-the-change.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CHECKSEQUENCEVERIFY - We need more usecases to motivate the change - 2023-08-01T16:30:25.033312+00:00 + 2025-10-11T22:08:28.275734+00:00 + python-feedgen Jorge Timón 2015-10-19 10:43:05+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - CHECKSEQUENCEVERIFY - We need more usecases to motivate the change - 2023-08-01T16:30:25.034316+00:00 + 2025-10-11T22:08:28.275916+00:00 - On October 16, 2015, Rusty Russell expressed his dissatisfaction with the lack of control over bitcoind's perception of time, making it difficult to conduct blackbox testing. Gavin informed him about the setmocktime function, which Rusty was pleased with.BTC Drak found BIP68 impractical for blackbox testing and suggested a feature request to address this issue. The discussions revolved around the interblock interval in the Bitcoin blockchain and the need for shorter intervals in sidechains like Liquid. Two alternatives were proposed: moving the flag bit indicating use of seconds to bit 23 and reserving bits 17-22 for higher granularity, or putting the units flag in the least significant bit. Adam Back proposed the use of 1-minute blocks if security arguments for limitations on IBLT or fountain codes are found.The email thread also discussed the use of nSequence in BIP68 and proposals for its use in discouraging miners from reorging chains and implementing proof-of-stake blocksize voting. It was decided to use 16 bits for the sequence number in both block and time versions of BIP68, allowing for a resolution of 512 seconds. Rusty Russell proposed changing BIP68 to use 16 bits for the sequence number in both block and time versions. Peter Todd asked for other proposals for implementing this feature via nSequence, and Gregory Maxwell suggested discouraging miners from reorging chains and proof-of-stake blocksize voting.Peter Todd raised concerns about the review process for BIP68 and BIP112, suggesting that the overall design needs to be evaluated as a single unit. Joseph Poon emphasized the need for a relative CLTV and suggested implementing it via nSequence. Mark Friedenbach discussed decreasing granularity as a soft-fork and suggested keeping the highest possible precision. Peter Todd expressed concerns about the implementation of a feature via nSequence and asked for other proposals.The discussion on the bitcoin-dev mailing list revolved around the use of nSequence in BIPs 68, 112, and 113. Peter Todd suggested implementing applications requiring relative CLTV via nSequence. Alex Morcos proposed increasing granularity by reducing the resolution of time-based sequence number locks. The use of RCLTV and OP_CSV in lightning commitment transactions was also discussed. Peter Todd expressed concerns about whether implementing a relative CLTV mechanism using nSequence is the best approach. Anthony Towns discussed the differences between RCLTV and CLTV and suggested that OP_CRLTV alone works fine for BIP68 use cases.Anthony Towns and Peter Todd discussed the implementation of relative CLTV using nSequence in Bitcoin transactions. Todd explained the use of RCLTV/OP_CSV in Lightning commitment transactions and the drawbacks of using absolute CLTV. Peter Todd has requested further work on the rationale for implementing relative lock-time via nSequence in a post to the Bitcoin development mailing list.The purpose of implementing relative lock-time via nSequence is to enforce a delay between publishing the commitment transaction and spending the output in lightning commitment transactions. This delay allows the counterparty to prove that the commitment was revoked and claim the outputs as a penalty. The use of absolute CLTV instead of RCLTV would result in unwanted delays in claiming funds when no cheating is occurring. RCLTV allows for longer availability of a channel, but funds can still be reclaimed quickly in case of problems.While the CHECKSEQUENCEVERIFY (CSV) semantics for BIP68 and BIP112 are mostly ready, implementing relative lock-time without using nSequence may cause a one-year delay for deployment. To avoid this delay, a suggested compromise is to make BIP68 optional by indicating it with a bit in tx nVersion. This would allow for the deployment of relative lock-time without further delays while not permanently limiting future upgrades.BIP112 provides an example called "Escrow with Timeout" which demonstrates the need for relative CLTV. However, there is a lack of clear justification for implementing this feature via nSequence. The proposed new nSequence semantics revolve around a "Consensus-enforced tx replacement" mechanism, using a bidirectional payment channel as an example. However, it is argued that a bidirectional payment channel can be implemented using CLTV alone. The Bitcoin community needs to provide more justifications for this complex soft-fork that limits future upgrades before deploying it. It is crucial to document the semantics and use-cases thoroughly to avoid mistakes similar to the failed feature that led to the creation of nSequence.The CHECKSEQUENCEVERIFY (CSV) semantics, defined by BIP68 and BIP112, introduce a relative CHECKLOCKTIMEVERIFY. CSV defines the behavior for the previously undefined nSequence field, which is the only free-form field in the transaction serialization format that can be utilized for future upgrades. Adding new fields to the serialization format is challenging due to the significant system-wide impact of the required hard-fork. Therefore, it is important to carefully justify the new 2015-10-19T10:43:05+00:00 + On October 16, 2015, Rusty Russell expressed his dissatisfaction with the lack of control over bitcoind's perception of time, making it difficult to conduct blackbox testing. Gavin informed him about the setmocktime function, which Rusty was pleased with.BTC Drak found BIP68 impractical for blackbox testing and suggested a feature request to address this issue. The discussions revolved around the interblock interval in the Bitcoin blockchain and the need for shorter intervals in sidechains like Liquid. Two alternatives were proposed: moving the flag bit indicating use of seconds to bit 23 and reserving bits 17-22 for higher granularity, or putting the units flag in the least significant bit. Adam Back proposed the use of 1-minute blocks if security arguments for limitations on IBLT or fountain codes are found.The email thread also discussed the use of nSequence in BIP68 and proposals for its use in discouraging miners from reorging chains and implementing proof-of-stake blocksize voting. It was decided to use 16 bits for the sequence number in both block and time versions of BIP68, allowing for a resolution of 512 seconds. Rusty Russell proposed changing BIP68 to use 16 bits for the sequence number in both block and time versions. Peter Todd asked for other proposals for implementing this feature via nSequence, and Gregory Maxwell suggested discouraging miners from reorging chains and proof-of-stake blocksize voting.Peter Todd raised concerns about the review process for BIP68 and BIP112, suggesting that the overall design needs to be evaluated as a single unit. Joseph Poon emphasized the need for a relative CLTV and suggested implementing it via nSequence. Mark Friedenbach discussed decreasing granularity as a soft-fork and suggested keeping the highest possible precision. Peter Todd expressed concerns about the implementation of a feature via nSequence and asked for other proposals.The discussion on the bitcoin-dev mailing list revolved around the use of nSequence in BIPs 68, 112, and 113. Peter Todd suggested implementing applications requiring relative CLTV via nSequence. Alex Morcos proposed increasing granularity by reducing the resolution of time-based sequence number locks. The use of RCLTV and OP_CSV in lightning commitment transactions was also discussed. Peter Todd expressed concerns about whether implementing a relative CLTV mechanism using nSequence is the best approach. Anthony Towns discussed the differences between RCLTV and CLTV and suggested that OP_CRLTV alone works fine for BIP68 use cases.Anthony Towns and Peter Todd discussed the implementation of relative CLTV using nSequence in Bitcoin transactions. Todd explained the use of RCLTV/OP_CSV in Lightning commitment transactions and the drawbacks of using absolute CLTV. Peter Todd has requested further work on the rationale for implementing relative lock-time via nSequence in a post to the Bitcoin development mailing list.The purpose of implementing relative lock-time via nSequence is to enforce a delay between publishing the commitment transaction and spending the output in lightning commitment transactions. This delay allows the counterparty to prove that the commitment was revoked and claim the outputs as a penalty. The use of absolute CLTV instead of RCLTV would result in unwanted delays in claiming funds when no cheating is occurring. RCLTV allows for longer availability of a channel, but funds can still be reclaimed quickly in case of problems.While the CHECKSEQUENCEVERIFY (CSV) semantics for BIP68 and BIP112 are mostly ready, implementing relative lock-time without using nSequence may cause a one-year delay for deployment. To avoid this delay, a suggested compromise is to make BIP68 optional by indicating it with a bit in tx nVersion. This would allow for the deployment of relative lock-time without further delays while not permanently limiting future upgrades.BIP112 provides an example called "Escrow with Timeout" which demonstrates the need for relative CLTV. However, there is a lack of clear justification for implementing this feature via nSequence. The proposed new nSequence semantics revolve around a "Consensus-enforced tx replacement" mechanism, using a bidirectional payment channel as an example. However, it is argued that a bidirectional payment channel can be implemented using CLTV alone. The Bitcoin community needs to provide more justifications for this complex soft-fork that limits future upgrades before deploying it. It is crucial to document the semantics and use-cases thoroughly to avoid mistakes similar to the failed feature that led to the creation of nSequence.The CHECKSEQUENCEVERIFY (CSV) semantics, defined by BIP68 and BIP112, introduce a relative CHECKLOCKTIMEVERIFY. CSV defines the behavior for the previously undefined nSequence field, which is the only free-form field in the transaction serialization format that can be utilized for future upgrades. Adding new fields to the serialization format is challenging due to the significant system-wide impact of the required hard-fork. Therefore, it is important to carefully justify the new - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Compatibility-requirements-for-hard-or-soft-forks.xml b/static/bitcoin-dev/Oct_2015/combined_Compatibility-requirements-for-hard-or-soft-forks.xml index 7d58204452..aed91b7a61 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Compatibility-requirements-for-hard-or-soft-forks.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Compatibility-requirements-for-hard-or-soft-forks.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Compatibility requirements for hard or soft forks - 2023-08-01T16:47:10.879812+00:00 + 2025-10-11T22:09:00.153987+00:00 + python-feedgen jl2012 at xbt.hk 2015-11-03 05:32:18+00:00 @@ -55,13 +56,13 @@ - python-feedgen + 2 Combined summary - Compatibility requirements for hard or soft forks - 2023-08-01T16:47:10.879812+00:00 + 2025-10-11T22:09:00.154132+00:00 - A strategy for the safe use of Bitcoin involves creating an informational BIP (Bitcoin Improvement Proposal). The guidelines for this proposal include increasing transaction version numbers when possible, considering transactions with unknown/large version numbers as unsafe to use with locktime, and providing reasonable notice before implementing changes. Non-opt-in changes should only be made to protect the network's integrity. Transactions that can be validated without overburdening the network are considered safe to use, even if they are non-standard. However, an OP_CAT script that requires terabytes of RAM to validate is not considered "reasonable." While these guidelines have generally been well-received, there may be disagreements over what constitutes "protecting the integrity of the network" and "reasonable notice."Gavin Andresen shared his opinion on the guidelines, agreeing with them but noting potential disagreements over what constitutes "reasonable notice" and "protects the integrity of the network." He suggested that if Bitcoin were perfect, any valid transaction would remain valid until spent regardless of protocol changes. However, there are cases where this guarantee cannot be met, and it is difficult to determine if these cases pose a real problem in practice. To address these issues, he proposed implementing non-pathological backward compatibility and treating unhandled cases as bugs until triggered.On November 1, 2015, Tier Nolan discussed guidelines for Bitcoin transaction version numbers. According to the guidelines, version numbers will be increased when possible, but transactions with unknown or large version numbers should not be used with locktime. Non-opt-in changes will only be made to protect the network's integrity, and reasonable notice must be given before implementing any changes. Locked transactions that can be validated without burdening the network are considered safe, even if they are non-standard. However, an OP_CAT script requiring terabytes of RAM to validate is deemed unreasonable. Gavin Andresen responded positively to these guidelines but acknowledged potential disagreements over "reasonable notice."In a Bitcoin-dev mailing list, Tier Nolan suggested giving at least one year's notice to prevent people from losing their money. It was also noted that bitcoin nodes can validate blocks going back to the genesis block, preserving old consensus rules in current code bases. While validating input scripts according to past consensus rules is feasible, handling output may be more challenging. It was proposed that if every consensus rule change had been accompanied by a version number bump, old versions could have been phased out without invalidating signed-but-unbroadcast transactions.The term "locked transaction" may refer to a P2SH output. Justus Ranvier raised concerns about OP_CAT scripts in the UTXO set and the possibility of locked transactions paying to such scripts with lost private keys, potentially making outputs unspendable. There were discussions on preventing rule changes that permanently disable spendability of outputs and the question of who should decide Bitcoin usage standards. Miners were identified as the decision-makers, not developers. Additionally, the question of how close Bitcoin developers want to sail towards being administrators of a virtual currency was posed.The threshold of reasonableness for OP_CAT scripts, which require terabytes of RAM to validate, was discussed in a Bitcoin-dev thread. Concerns were raised about the presence of such scripts in the UTXO set, worth approximately $5 billion. The need to justify not changing the meaning of someone else's outputs and the role of Bitcoin developers as administrators of a virtual currency were debated. It was highlighted that miners have the power to collectively vote on disabling specific UTXOs and changing acceptance rules.Rusty Russell emphasized the importance of clear notification and non-standard transaction invalidation in the future. He suggested that surpassing the benchmark of "reasonable certainty" would involve adding redundancies like OP_CHECKSIG and widespread notification of change. Gavin Andresen raised questions about the requirement of validating one-megabyte transactions under new rules, expressing concern about the potential confiscation of funds in cases where expensive-to-validate transactions with lockTime exist. The benchmark for "reasonable certainty" was proposed as a transaction that would never have been generated by any known software.The author questioned the definition of "short-term changes to the Bitcoin protocol" as a moderation rule and raised the question of whether any one-megabyte transaction valid under existing rules should also be valid under new rules. Arguments were presented regarding expensive-to-validate transactions with lockTime in the future and the unlikelihood of such transactions existing. It was suggested that the requirement should only apply to valid 100,000-byte transactions under old consensus rules. Gavin Andresen implemented BIP101/Bitcoin XT with support for any "non-attack" 1MB transaction. 2015-11-03T05:32:18+00:00 + A strategy for the safe use of Bitcoin involves creating an informational BIP (Bitcoin Improvement Proposal). The guidelines for this proposal include increasing transaction version numbers when possible, considering transactions with unknown/large version numbers as unsafe to use with locktime, and providing reasonable notice before implementing changes. Non-opt-in changes should only be made to protect the network's integrity. Transactions that can be validated without overburdening the network are considered safe to use, even if they are non-standard. However, an OP_CAT script that requires terabytes of RAM to validate is not considered "reasonable." While these guidelines have generally been well-received, there may be disagreements over what constitutes "protecting the integrity of the network" and "reasonable notice."Gavin Andresen shared his opinion on the guidelines, agreeing with them but noting potential disagreements over what constitutes "reasonable notice" and "protects the integrity of the network." He suggested that if Bitcoin were perfect, any valid transaction would remain valid until spent regardless of protocol changes. However, there are cases where this guarantee cannot be met, and it is difficult to determine if these cases pose a real problem in practice. To address these issues, he proposed implementing non-pathological backward compatibility and treating unhandled cases as bugs until triggered.On November 1, 2015, Tier Nolan discussed guidelines for Bitcoin transaction version numbers. According to the guidelines, version numbers will be increased when possible, but transactions with unknown or large version numbers should not be used with locktime. Non-opt-in changes will only be made to protect the network's integrity, and reasonable notice must be given before implementing any changes. Locked transactions that can be validated without burdening the network are considered safe, even if they are non-standard. However, an OP_CAT script requiring terabytes of RAM to validate is deemed unreasonable. Gavin Andresen responded positively to these guidelines but acknowledged potential disagreements over "reasonable notice."In a Bitcoin-dev mailing list, Tier Nolan suggested giving at least one year's notice to prevent people from losing their money. It was also noted that bitcoin nodes can validate blocks going back to the genesis block, preserving old consensus rules in current code bases. While validating input scripts according to past consensus rules is feasible, handling output may be more challenging. It was proposed that if every consensus rule change had been accompanied by a version number bump, old versions could have been phased out without invalidating signed-but-unbroadcast transactions.The term "locked transaction" may refer to a P2SH output. Justus Ranvier raised concerns about OP_CAT scripts in the UTXO set and the possibility of locked transactions paying to such scripts with lost private keys, potentially making outputs unspendable. There were discussions on preventing rule changes that permanently disable spendability of outputs and the question of who should decide Bitcoin usage standards. Miners were identified as the decision-makers, not developers. Additionally, the question of how close Bitcoin developers want to sail towards being administrators of a virtual currency was posed.The threshold of reasonableness for OP_CAT scripts, which require terabytes of RAM to validate, was discussed in a Bitcoin-dev thread. Concerns were raised about the presence of such scripts in the UTXO set, worth approximately $5 billion. The need to justify not changing the meaning of someone else's outputs and the role of Bitcoin developers as administrators of a virtual currency were debated. It was highlighted that miners have the power to collectively vote on disabling specific UTXOs and changing acceptance rules.Rusty Russell emphasized the importance of clear notification and non-standard transaction invalidation in the future. He suggested that surpassing the benchmark of "reasonable certainty" would involve adding redundancies like OP_CHECKSIG and widespread notification of change. Gavin Andresen raised questions about the requirement of validating one-megabyte transactions under new rules, expressing concern about the potential confiscation of funds in cases where expensive-to-validate transactions with lockTime exist. The benchmark for "reasonable certainty" was proposed as a transaction that would never have been generated by any known software.The author questioned the definition of "short-term changes to the Bitcoin protocol" as a moderation rule and raised the question of whether any one-megabyte transaction valid under existing rules should also be valid under new rules. Arguments were presented regarding expensive-to-validate transactions with lockTime in the future and the unlikelihood of such transactions existing. It was suggested that the requirement should only apply to valid 100,000-byte transactions under old consensus rules. Gavin Andresen implemented BIP101/Bitcoin XT with support for any "non-attack" 1MB transaction. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Composite-priority-combining-fees-and-bitcoin-days-into-one-number.xml b/static/bitcoin-dev/Oct_2015/combined_Composite-priority-combining-fees-and-bitcoin-days-into-one-number.xml index 38f2c689f2..414678115f 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Composite-priority-combining-fees-and-bitcoin-days-into-one-number.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Composite-priority-combining-fees-and-bitcoin-days-into-one-number.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Composite priority: combining fees and bitcoin-days into one number - 2023-08-01T16:46:37.502574+00:00 + 2025-10-11T22:08:41.026826+00:00 + python-feedgen Luke Dashjr 2015-10-29 00:55:53+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Composite priority: combining fees and bitcoin-days into one number - 2023-08-01T16:46:37.502574+00:00 + 2025-10-11T22:08:41.026951+00:00 - In a Bitcoin development discussion on October 28, 2015, Jonathan Toomim emphasized the importance of maintaining an easy-to-modify and customizable node policy. He argued against simplifying code in a way that would make policies harder to configure, specifically mentioning the default policy of reserving 5% of space. Toomim suggested implementing an API that is calibrated on the whole mempool and includes a method for calculating priority scores for transactions.However, Luke Dashjr disagreed with Toomim's proposal, stating that communicating policies as simple numbers would be more complicated for policy-writers compared to the current system. In an email exchange between Dashjr and Toomim, they discussed the idea of using an abstract API that could make it easier to write a reserved-space algorithm within the priority API scheme.Toomim also expressed his opinion on assigning block space based on bitcoin-days destroyed (BDD) and fees. He found this approach awkward and believed it would complicate code writing, maintenance, and execution due to the need for separate code paths for dealing with a constrained resource like the mempool and CNB. He reiterated the importance of easy modification and customization of node policy and argued against sacrificing simplicity in other code areas if it makes policies harder to configure.The process of assigning block space based on BDD and fees has faced criticism for its complexity, requiring two code paths. One alternative suggested is eliminating BDD priority altogether, but another idea proposes creating a conversion rate between BDD and fees to create a composite priority metric. This would involve using the equation sum(fees) = sum(BDD) * conversionRate * BDDweight to calculate the conversion rate, with the relative weight of BDD versus fees set by a policy statement from the command line. To optimize this process, the sum of mempool fees and BDD would be stored and updated as transactions enter or leave the mempool, with recalculations occurring when a new block is found to minimize drift. 2015-10-29T00:55:53+00:00 + In a Bitcoin development discussion on October 28, 2015, Jonathan Toomim emphasized the importance of maintaining an easy-to-modify and customizable node policy. He argued against simplifying code in a way that would make policies harder to configure, specifically mentioning the default policy of reserving 5% of space. Toomim suggested implementing an API that is calibrated on the whole mempool and includes a method for calculating priority scores for transactions.However, Luke Dashjr disagreed with Toomim's proposal, stating that communicating policies as simple numbers would be more complicated for policy-writers compared to the current system. In an email exchange between Dashjr and Toomim, they discussed the idea of using an abstract API that could make it easier to write a reserved-space algorithm within the priority API scheme.Toomim also expressed his opinion on assigning block space based on bitcoin-days destroyed (BDD) and fees. He found this approach awkward and believed it would complicate code writing, maintenance, and execution due to the need for separate code paths for dealing with a constrained resource like the mempool and CNB. He reiterated the importance of easy modification and customization of node policy and argued against sacrificing simplicity in other code areas if it makes policies harder to configure.The process of assigning block space based on BDD and fees has faced criticism for its complexity, requiring two code paths. One alternative suggested is eliminating BDD priority altogether, but another idea proposes creating a conversion rate between BDD and fees to create a composite priority metric. This would involve using the equation sum(fees) = sum(BDD) * conversionRate * BDDweight to calculate the conversion rate, with the relative weight of BDD versus fees set by a policy statement from the command line. To optimize this process, the sum of mempool fees and BDD would be stored and updated as transactions enter or leave the mempool, with recalculations occurring when a new block is found to minimize drift. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Crossing-the-line-Was-Re-Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml b/static/bitcoin-dev/Oct_2015/combined_Crossing-the-line-Was-Re-Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml index 17e1202a16..17523ab02f 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Crossing-the-line-Was-Re-Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Crossing-the-line-Was-Re-Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!] - 2023-08-01T16:27:55.579763+00:00 + 2025-10-11T22:08:32.526514+00:00 + python-feedgen Gregory Maxwell 2015-10-02 16:37:07+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!] - 2023-08-01T16:27:55.579763+00:00 + 2025-10-11T22:08:32.526689+00:00 - In a Bitcoin development discussion, the origin of the term "simplified payment verification" (SPV) was debated. Mike Hearn claimed to have coined the term in a forum post in 2011, but another member pointed out that anyone who used the term SPV was technically "coining" it. The discussion then shifted to the definition of an SPV client and whether header-only clients without fraud detection mechanisms are considered incomplete implementations according to Satoshi's original definition. It was suggested that eventually, SPV clients should be able to detect any rule violation on the blockchain, including block size.The terminology around SPV clients was also discussed, with Satoshi referring to them as "client only mode" and Jeff Garzik calling them "headers only client". Hearn introduced the term "SPV clients" in a post on bitcointalk.org, but at that time, nobody used the term "SPV wallet" to refer to apps like BreadWallet or libraries like bitcoinj.However, some members of the Bitcoin community have accused Hearn of making false statements and attempting to harm and divide the community through his actions, such as the contentious Bitcoin XT fork. There is a debate about whether Hearn should be expelled from the Bitcoin-devs mailing list, with suggestions for a cooling-off period before any further action is taken.On Reddit, there is a suggestion to implement a cooling-off period before taking any further action. Some members feel that Hearn has crossed the line multiple times, while others believe that no action should be taken as they do not agree with TaoEffect.com and there is no consensus.The writer of an email expresses concern about the noise level and drama within the community list and suggests temporary bans based on circumstances rather than focusing on specific personalities. They address a post made by Hearn regarding false and damaging statements about Bitcoin, questioning whether he has crossed a line that would result in expulsion from the community. They ask for thoughts from the community and provide links to evidence of Hearn's behavior and claims.Hearn has been accused of making false and damaging statements about Bitcoin, including claiming to have coined the term SPV. He has also attempted to gain control of Bitcoin through the Bitcoin XT fork. Some members believe that Hearn should be expelled from the community, but it is unclear if there is a consensus on this matter. Hearn's actions have caused division and harm within the Bitcoin community for several years. 2015-10-02T16:37:07+00:00 + In a Bitcoin development discussion, the origin of the term "simplified payment verification" (SPV) was debated. Mike Hearn claimed to have coined the term in a forum post in 2011, but another member pointed out that anyone who used the term SPV was technically "coining" it. The discussion then shifted to the definition of an SPV client and whether header-only clients without fraud detection mechanisms are considered incomplete implementations according to Satoshi's original definition. It was suggested that eventually, SPV clients should be able to detect any rule violation on the blockchain, including block size.The terminology around SPV clients was also discussed, with Satoshi referring to them as "client only mode" and Jeff Garzik calling them "headers only client". Hearn introduced the term "SPV clients" in a post on bitcointalk.org, but at that time, nobody used the term "SPV wallet" to refer to apps like BreadWallet or libraries like bitcoinj.However, some members of the Bitcoin community have accused Hearn of making false statements and attempting to harm and divide the community through his actions, such as the contentious Bitcoin XT fork. There is a debate about whether Hearn should be expelled from the Bitcoin-devs mailing list, with suggestions for a cooling-off period before any further action is taken.On Reddit, there is a suggestion to implement a cooling-off period before taking any further action. Some members feel that Hearn has crossed the line multiple times, while others believe that no action should be taken as they do not agree with TaoEffect.com and there is no consensus.The writer of an email expresses concern about the noise level and drama within the community list and suggests temporary bans based on circumstances rather than focusing on specific personalities. They address a post made by Hearn regarding false and damaging statements about Bitcoin, questioning whether he has crossed a line that would result in expulsion from the community. They ask for thoughts from the community and provide links to evidence of Hearn's behavior and claims.Hearn has been accused of making false and damaging statements about Bitcoin, including claiming to have coined the term SPV. He has also attempted to gain control of Bitcoin through the Bitcoin XT fork. Some members believe that Hearn should be expelled from the community, but it is unclear if there is a consensus on this matter. Hearn's actions have caused division and harm within the Bitcoin community for several years. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Design-Competition.xml b/static/bitcoin-dev/Oct_2015/combined_Design-Competition.xml index 87a5c844fd..996e4e42e3 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Design-Competition.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Design-Competition.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Design Competition - 2023-08-01T16:27:10.245229+00:00 + 2025-10-11T22:08:17.650919+00:00 + python-feedgen odinn 2015-10-01 04:38:50+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Design Competition - 2023-08-01T16:27:10.245229+00:00 + 2025-10-11T22:08:17.651100+00:00 - Lykke Corp, a trading platform for foreign exchange, is funding a Bitcoin-related competition aimed at building a trading platform that allows participants to settle their trades through the blockchain via colored coins. The competition, which will initially focus on foreign exchange, aims to create a community-driven effort rather than proprietary technology. The use of a sidechain is suggested but not required for trade reconciliation. Participants in the competition will receive 2 million Lykke coins ($8,000 USD) allocated for core development over the next three months. More details on the requirements can be found on the Lykke website. Richard Olsen, CEO of Lykke, encourages questions to be asked during an online briefing event or over email.In response to the announcement of the competition, one member of the bitcoin-dev mailing list questions why the funds are not being used to fund Core development instead. Another member suggests that the Bitcointalk Altcoin section would be the best place for announcements regarding such projects. The original poster expresses their desire for a dedicated mailing list that is not solely focused on digital cash systems and welcomes discussions about 2.0 projects. Benjamin, another member of the mailing list, believes there is room for a better board/list for new 2.0 projects and offers to help build it.The competition, announced by Richard Olsen, seeks participants to build a trading platform using colored coins on the blockchain for settling trades. The competition is community-driven and contributions will be made available under an MIT license on Github. Although the use of a sidechain is suggested, it is not mandatory. The competition will initially focus on foreign exchange, with other assets to follow. Interested parties can attend an online briefing event or visit www.lykkex.com for more information. Contributions will be made available under an MIT license on Github to foster a community-driven project.In a post on Bitcoin-dev, Eric Lombrozo highlights the issue of finding developers for new services in the Bitcoin ecosystem. While some proposals receive significant interest if made by well-known individuals, others are dismissed as spam or ridiculed if coming from unknown sources. The author suggests creating a list where people can discuss proposed and ongoing projects and look for developers to hire.Overall, the discussion revolves around the need for a more open mailing list for Bitcoin and the announcement of a Bitcoin trading platform competition. The competition aims to build a trading platform for foreign exchange and other assets using colored coins and potentially a sidechain. The contributions made will be available under an MIT license on Github. Participants will have the opportunity to settle their trades through the blockchain. 2015-10-01T04:38:50+00:00 + Lykke Corp, a trading platform for foreign exchange, is funding a Bitcoin-related competition aimed at building a trading platform that allows participants to settle their trades through the blockchain via colored coins. The competition, which will initially focus on foreign exchange, aims to create a community-driven effort rather than proprietary technology. The use of a sidechain is suggested but not required for trade reconciliation. Participants in the competition will receive 2 million Lykke coins ($8,000 USD) allocated for core development over the next three months. More details on the requirements can be found on the Lykke website. Richard Olsen, CEO of Lykke, encourages questions to be asked during an online briefing event or over email.In response to the announcement of the competition, one member of the bitcoin-dev mailing list questions why the funds are not being used to fund Core development instead. Another member suggests that the Bitcointalk Altcoin section would be the best place for announcements regarding such projects. The original poster expresses their desire for a dedicated mailing list that is not solely focused on digital cash systems and welcomes discussions about 2.0 projects. Benjamin, another member of the mailing list, believes there is room for a better board/list for new 2.0 projects and offers to help build it.The competition, announced by Richard Olsen, seeks participants to build a trading platform using colored coins on the blockchain for settling trades. The competition is community-driven and contributions will be made available under an MIT license on Github. Although the use of a sidechain is suggested, it is not mandatory. The competition will initially focus on foreign exchange, with other assets to follow. Interested parties can attend an online briefing event or visit www.lykkex.com for more information. Contributions will be made available under an MIT license on Github to foster a community-driven project.In a post on Bitcoin-dev, Eric Lombrozo highlights the issue of finding developers for new services in the Bitcoin ecosystem. While some proposals receive significant interest if made by well-known individuals, others are dismissed as spam or ridiculed if coming from unknown sources. The author suggests creating a list where people can discuss proposed and ongoing projects and look for developers to hire.Overall, the discussion revolves around the need for a more open mailing list for Bitcoin and the announcement of a Bitcoin trading platform competition. The competition aims to build a trading platform for foreign exchange and other assets using colored coins and potentially a sidechain. The contributions made will be available under an MIT license on Github. Participants will have the opportunity to settle their trades through the blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Dev-list-s-stance-on-potentially-altering-the-PoW-algorithm.xml b/static/bitcoin-dev/Oct_2015/combined_Dev-list-s-stance-on-potentially-altering-the-PoW-algorithm.xml index a363c4a632..adc638e07c 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Dev-list-s-stance-on-potentially-altering-the-PoW-algorithm.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Dev-list-s-stance-on-potentially-altering-the-PoW-algorithm.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dev-list's stance on potentially altering the PoW algorithm - 2023-08-01T16:28:36.298031+00:00 + 2025-10-11T22:08:21.898111+00:00 + python-feedgen Milly Bitcoin 2015-10-02 23:19:11+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Dev-list's stance on potentially altering the PoW algorithm - 2023-08-01T16:28:36.298031+00:00 + 2025-10-11T22:08:21.898306+00:00 - The bitcoin community has been engaged in a debate about changing the proof-of-work (PoW) function and how it could potentially protect against ASIC/FPGA optimization. Some suggest gradually introducing new hash algorithms through ongoing competitions to create an ASIC-resistant PoW, while others argue that hardware optimization cannot be completely prevented. The term "ASIC-resistance" has been criticized as an absurd term coined to promote altcoins.In response to concerns about centralization caused by hoarding of mining ASICs, restarting mining with a new algorithm has been proposed as a potential solution. However, economists should be consulted on these claims rather than developers. It is also noted that changing the language of Core to prevent developer centralization was suggested as a joke.Discussions have taken place on the bitcoin-dev mailing list regarding the feasibility of protecting against ASIC/FPGA optimization. It is argued that guaranteeing such protection is impossible, as anything that can be done with software can also be done with hardware. However, BIP99 suggests the use of "anti-miner hardforks" to restart the ASIC and mining market if centralization becomes an issue.A recently published paper proposes an asymmetric memory-hard PoW algorithm that could potentially alter the bitcoin PoW protocol to protect against ASIC/FPGA optimization. This algorithm addresses the limitations of the Cuckoo cycle algorithm. However, there are also papers demonstrating the impossibility of protecting against ASIC/FPGA optimization. The author seeks clarification on the stance of core developers regarding potential changes to the bitcoin PoW protocol.Overall, the debates surrounding the PoW function and ASIC/FPGA optimization highlight the need for careful consideration and analysis. While some propose solutions to enhance decentralization and protect against centralization caused by hoarding of mining ASICs, others emphasize the challenges and limitations involved. The discussions raise questions about the stance of core developers on potentially altering the bitcoin PoW protocol and the implications for mining centralization and decentralization. 2015-10-02T23:19:11+00:00 + The bitcoin community has been engaged in a debate about changing the proof-of-work (PoW) function and how it could potentially protect against ASIC/FPGA optimization. Some suggest gradually introducing new hash algorithms through ongoing competitions to create an ASIC-resistant PoW, while others argue that hardware optimization cannot be completely prevented. The term "ASIC-resistance" has been criticized as an absurd term coined to promote altcoins.In response to concerns about centralization caused by hoarding of mining ASICs, restarting mining with a new algorithm has been proposed as a potential solution. However, economists should be consulted on these claims rather than developers. It is also noted that changing the language of Core to prevent developer centralization was suggested as a joke.Discussions have taken place on the bitcoin-dev mailing list regarding the feasibility of protecting against ASIC/FPGA optimization. It is argued that guaranteeing such protection is impossible, as anything that can be done with software can also be done with hardware. However, BIP99 suggests the use of "anti-miner hardforks" to restart the ASIC and mining market if centralization becomes an issue.A recently published paper proposes an asymmetric memory-hard PoW algorithm that could potentially alter the bitcoin PoW protocol to protect against ASIC/FPGA optimization. This algorithm addresses the limitations of the Cuckoo cycle algorithm. However, there are also papers demonstrating the impossibility of protecting against ASIC/FPGA optimization. The author seeks clarification on the stance of core developers regarding potential changes to the bitcoin PoW protocol.Overall, the debates surrounding the PoW function and ASIC/FPGA optimization highlight the need for careful consideration and analysis. While some propose solutions to enhance decentralization and protect against centralization caused by hoarding of mining ASICs, others emphasize the challenges and limitations involved. The discussions raise questions about the stance of core developers on potentially altering the bitcoin PoW protocol and the implications for mining centralization and decentralization. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Fwd-Bitcoin-Core-0-12-0-release-schedule.xml b/static/bitcoin-dev/Oct_2015/combined_Fwd-Bitcoin-Core-0-12-0-release-schedule.xml index 3f8cc91617..daed61402f 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Fwd-Bitcoin-Core-0-12-0-release-schedule.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Fwd-Bitcoin-Core-0-12-0-release-schedule.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fwd: Bitcoin Core 0.12.0 release schedule - 2023-08-01T16:28:19.149913+00:00 + 2025-10-11T22:08:00.654967+00:00 + python-feedgen Luke Dashjr 2015-10-01 20:20:22+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Fwd: Bitcoin Core 0.12.0 release schedule - 2023-08-01T16:28:19.149913+00:00 + 2025-10-11T22:08:00.655154+00:00 - On October 1, 2015, Marcel Jamin questioned the readiness of bitcoin for production use. He listed his expectations for the upcoming 1.0 release, including practical API implementation, a user-friendly GUI, and a safe wallet. Luke also contributed to the discussion. In a conversation between Wladimir J. van der Laan and Marcel Jamin, the topic of Bitcoin protocol's version numbering was discussed. Jamin suggested that the $3.5 billion market cap and companies building on top of Bitcoin indicate that the 1.0.0 tag is overdue. Van der Laan explained that most investment in Bitcoin is not in the Bitcoin Core software and version numbers are not used as a signaling mechanism. The block/transaction versions are at v3/v1 respectively, and the highest network protocol version is 70011. This is due to considerations of software maturity and potential arguments.Marcel Jamin asked why Bitcoin Core software remains at version 0.11.1. Wladimir responded that most investment is not in the Core software but in things built on top of it. The assumption is that the network/protocol will not go down, relying on trust in the node software for consensus. However, this does not mean all implementation issues have been resolved. Version numbers are not used as a signaling mechanism, and questions about software maturity could lead to unproductive arguments.Wladimir explains in a separate discussion that software versions are incrementally numbered every half year without using them as a signaling mechanism. Using versioning as a signaling mechanism would invite questions about software maturity and potentially pointless arguments. Despite claims that Bitcoin is not following semantic versioning, the investments being made and the $3.5 billion market cap suggest that the 1.0.0 tag is overdue. However, this is not an important topic at present due to stress levels.Marcel Jamin's question on Bitcoin's relevance was raised on October 1st, 2015. Despite the challenges of fluctuating value and competition from other cryptocurrencies, Bitcoin remains relevant due to its decentralized nature and versatility. Bitcoin operates on a peer-to-peer network, making it resistant to manipulation or censorship. It can be used for various transactions and exchanged for other cryptocurrencies or traditional currencies. While facing competition, Bitcoin's established reputation and large user base give it an advantage.Marcel Jamin also questioned why Bitcoin versioning does not follow the SemVer spec. Btc Drak explained that they do follow the spec using a.b.c for major versions, with 0.12.0 as the next major version. Maintenance releases are labeled as 0.12.1 and so on, while release candidates are labeled as 0.12.0-rc1. Further information from an attached HTML file was not available. 2015-10-01T20:20:22+00:00 + On October 1, 2015, Marcel Jamin questioned the readiness of bitcoin for production use. He listed his expectations for the upcoming 1.0 release, including practical API implementation, a user-friendly GUI, and a safe wallet. Luke also contributed to the discussion. In a conversation between Wladimir J. van der Laan and Marcel Jamin, the topic of Bitcoin protocol's version numbering was discussed. Jamin suggested that the $3.5 billion market cap and companies building on top of Bitcoin indicate that the 1.0.0 tag is overdue. Van der Laan explained that most investment in Bitcoin is not in the Bitcoin Core software and version numbers are not used as a signaling mechanism. The block/transaction versions are at v3/v1 respectively, and the highest network protocol version is 70011. This is due to considerations of software maturity and potential arguments.Marcel Jamin asked why Bitcoin Core software remains at version 0.11.1. Wladimir responded that most investment is not in the Core software but in things built on top of it. The assumption is that the network/protocol will not go down, relying on trust in the node software for consensus. However, this does not mean all implementation issues have been resolved. Version numbers are not used as a signaling mechanism, and questions about software maturity could lead to unproductive arguments.Wladimir explains in a separate discussion that software versions are incrementally numbered every half year without using them as a signaling mechanism. Using versioning as a signaling mechanism would invite questions about software maturity and potentially pointless arguments. Despite claims that Bitcoin is not following semantic versioning, the investments being made and the $3.5 billion market cap suggest that the 1.0.0 tag is overdue. However, this is not an important topic at present due to stress levels.Marcel Jamin's question on Bitcoin's relevance was raised on October 1st, 2015. Despite the challenges of fluctuating value and competition from other cryptocurrencies, Bitcoin remains relevant due to its decentralized nature and versatility. Bitcoin operates on a peer-to-peer network, making it resistant to manipulation or censorship. It can be used for various transactions and exchanged for other cryptocurrencies or traditional currencies. While facing competition, Bitcoin's established reputation and large user base give it an advantage.Marcel Jamin also questioned why Bitcoin versioning does not follow the SemVer spec. Btc Drak explained that they do follow the spec using a.b.c for major versions, with 0.12.0 as the next major version. Maintenance releases are labeled as 0.12.1 and so on, while release candidates are labeled as 0.12.0-rc1. Further information from an attached HTML file was not available. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Incentives-to-run-full-nodes.xml b/static/bitcoin-dev/Oct_2015/combined_Incentives-to-run-full-nodes.xml index 0b091f10fc..13ba5905d3 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Incentives-to-run-full-nodes.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Incentives-to-run-full-nodes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Incentives to run full nodes - 2023-08-01T15:28:03.532194+00:00 + 2025-10-11T22:08:38.901039+00:00 + python-feedgen odinn 2015-10-04 06:59:27+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Incentives to run full nodes - 2023-08-01T15:28:03.532194+00:00 + 2025-10-11T22:08:38.901217+00:00 - In a recent discussion on the bitcoin-development mailing list, a user named Odinn brought attention to a protocol concept called ABIS that enables the decentralization and expansion of a giving economy. Odinn referenced a post from 2013 about microdonations and incentives for running full nodes. He also mentioned new developments in Bytecoin, which implemented microdonations successfully and could potentially be applied to Bitcoin. The email thread then shifted to the security of using Simplified Payment Verification (SPV) mode. Some participants argued that SPV is not secure, as Sybil attacking the IP address space is easier than acquiring hashing power to create false confirmations. However, others pointed out that the failure model is not specific to SPV and could apply to full nodes as well.Joseph Poon emphasized the vulnerability of SPV nodes compared to full nodes in an attack scenario. He explained that with SPV, it is possible to create a transaction that spends from non-existent coins and construct an SPV proof to send funds to the victim. This attack can be "overloadable" as the attacker is never out of money. In contrast, full nodes require the attacker to sign and spend real outputs they control, and there is a chance that the victim will eventually recover their funds in a reorganization. Poon also highlighted that attackers can target thousands of people simultaneously with less hashpower using SPV validation. Although he acknowledged that some threats can be mitigated, he believed that running a full node offers stronger security, especially when handling significant amounts of money.Peter Todd echoed concerns about the security of Hearn-style SPV mode and the limited effectiveness of volunteers running full nodes. He argued that Sybil attacking the IP address space is easier than acquiring enough hashing power for false confirmations, making Hearn-style SPV similar to trusting anyone with substantial hashing power. The discussion then debated whether full nodes would fare better against attackers with significant hashing power, with some suggesting that the failure model is not exclusive to SPV.Satoshi Nakamoto acknowledged in a separate discussion the changes that have occurred in the Bitcoin network since its early days, such as the unexpected impact of pooled mining on security. Balancing competition and security remains a challenge, and there is a need for better incentives for users to run nodes beyond altruism. Peter Todd argued that incentivizing full nodes is not a priority. He reiterated concerns about the security of Hearn-style SPV mode and the limited contribution of volunteers running full nodes. Todd proposed that having peers as validating nodes primarily optimizes bandwidth, while the best incentive for validation lies in immediate failure when not validating. Gregory Maxwell's proposal for blocks to commit to separate merkle trees, one valid and one invalid, was mentioned as an example of ensuring active validation. Todd's embedded consensus ideas rely on proof-of-publication and/or anti-replay functionality, with validation becoming the responsibility of individuals or trusted parties.Overall, these discussions shed light on the security challenges associated with SPV mode and the role of full nodes in enhancing Bitcoin's security. The participants recognize the need for further exploration of incentives and protocols to ensure the integrity and reliability of the network. 2015-10-04T06:59:27+00:00 + In a recent discussion on the bitcoin-development mailing list, a user named Odinn brought attention to a protocol concept called ABIS that enables the decentralization and expansion of a giving economy. Odinn referenced a post from 2013 about microdonations and incentives for running full nodes. He also mentioned new developments in Bytecoin, which implemented microdonations successfully and could potentially be applied to Bitcoin. The email thread then shifted to the security of using Simplified Payment Verification (SPV) mode. Some participants argued that SPV is not secure, as Sybil attacking the IP address space is easier than acquiring hashing power to create false confirmations. However, others pointed out that the failure model is not specific to SPV and could apply to full nodes as well.Joseph Poon emphasized the vulnerability of SPV nodes compared to full nodes in an attack scenario. He explained that with SPV, it is possible to create a transaction that spends from non-existent coins and construct an SPV proof to send funds to the victim. This attack can be "overloadable" as the attacker is never out of money. In contrast, full nodes require the attacker to sign and spend real outputs they control, and there is a chance that the victim will eventually recover their funds in a reorganization. Poon also highlighted that attackers can target thousands of people simultaneously with less hashpower using SPV validation. Although he acknowledged that some threats can be mitigated, he believed that running a full node offers stronger security, especially when handling significant amounts of money.Peter Todd echoed concerns about the security of Hearn-style SPV mode and the limited effectiveness of volunteers running full nodes. He argued that Sybil attacking the IP address space is easier than acquiring enough hashing power for false confirmations, making Hearn-style SPV similar to trusting anyone with substantial hashing power. The discussion then debated whether full nodes would fare better against attackers with significant hashing power, with some suggesting that the failure model is not exclusive to SPV.Satoshi Nakamoto acknowledged in a separate discussion the changes that have occurred in the Bitcoin network since its early days, such as the unexpected impact of pooled mining on security. Balancing competition and security remains a challenge, and there is a need for better incentives for users to run nodes beyond altruism. Peter Todd argued that incentivizing full nodes is not a priority. He reiterated concerns about the security of Hearn-style SPV mode and the limited contribution of volunteers running full nodes. Todd proposed that having peers as validating nodes primarily optimizes bandwidth, while the best incentive for validation lies in immediate failure when not validating. Gregory Maxwell's proposal for blocks to commit to separate merkle trees, one valid and one invalid, was mentioned as an example of ensuring active validation. Todd's embedded consensus ideas rely on proof-of-publication and/or anti-replay functionality, with validation becoming the responsibility of individuals or trusted parties.Overall, these discussions shed light on the security challenges associated with SPV mode and the role of full nodes in enhancing Bitcoin's security. The participants recognize the need for further exploration of incentives and protocols to ensure the integrity and reliability of the network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml b/static/bitcoin-dev/Oct_2015/combined_Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml index 5ad2cbf3eb..6d7bd5a08f 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Let's deploy BIP65 CHECKLOCKTIMEVERIFY! - 2023-08-01T16:21:21.415012+00:00 + 2025-10-11T22:08:26.148419+00:00 + python-feedgen digitsu at gmail.com 2015-10-13 00:08:49+00:00 @@ -375,13 +376,13 @@ - python-feedgen + 2 Combined summary - Let's deploy BIP65 CHECKLOCKTIMEVERIFY! - 2023-08-01T16:21:21.416010+00:00 + 2025-10-11T22:08:26.148754+00:00 - The email thread discusses the potential risks associated with a soft fork in the Bitcoin network. The effectiveness of an attack depends on the percentage of hash power that did not upgrade. Even with just 5% hash power and ~30% of nodes running the old version, a "damaging soft fork" still poses a high risk to someone receiving payments via an SPV client. The original emailer questions the significance of the risks posed by such an attack, as executing a double spend maliciously would be difficult due to the unpredictability of when a block would occur.There is a proposal to introduce a new flag in Core, called --scriptchecks=[all,standardonly,none], which would prioritize correctness by default and allow nodes to opt into pseudo-SPV behavior of a soft fork if desired. The advantages and disadvantages of hard forks and soft forks are discussed, with some arguing for a hard fork to avoid problems with SPV wallets during the rollout period. However, others believe that soft forks have a demonstrated track record of delivering new features with minimal problems.The deployment of BIP65 CHECKLOCKTIMEVERIFY in Bitcoin is also discussed. Mike Hearn expresses concerns about using a soft fork to implement this feature, suggesting that it should be a hard fork instead. Other participants emphasize the need for consensus before making any decisions. The conversation delves into the issues of miner adoption, the vulnerability of a soft fork, and the potential for double-spending attacks.The discussion highlights the complexities and trade-offs involved in implementing changes to the Bitcoin network, particularly in the context of soft forks and hard forks. The importance of upgrading full nodes and the risks associated with not doing so are emphasized. The conversations also touch on topics such as SPV wallets, the implementation of P2SH, and the advantages of communication and mitigation strategies.Overall, the discussions provide insights into different perspectives on the deployment of BIP65 CHECKLOCKTIMEVERIFY, the advantages and risks of soft forks versus hard forks, and the challenges faced in implementing changes in Bitcoin software. The email exchanges between Bitcoin developers touch on various topics related to upgrading Bitcoin software, the concept of consensus, and potential risks and solutions for SPV clients during soft forks. In addition, there are references to other email exchanges discussing topics such as the definition of a "working" full node, the risks and benefits of soft forks and hard forks, and the implications for SPV clients. The discussions highlight the need for refinement and adjustment of proposed changes, as well as the importance of developer consensus in the Bitcoin community.In a bitcoin-dev mailing list, Peter Todd expressed concerns about the delay in deploying CheckLockTimeVerify (CLTV) due to waiting for nVersion bits and CHECKSEQUENCEVERIFY. He suggested rolling out CLTV+CSV (CheckSequenceVerify) together by the 0.12 release if possible. However, if CSV is not ready, they would proceed with CLTV alone. The related pull requests for CSV are now ready for final review, and if that happens soon, CLTV+CSV would be rolled out together before 0.12.On September 27th, 2015, in an email exchange, a user named jl2012 expressed support for the deployment of BIP65 (CLTV) and asked about the possibility of backporting it to version 0.9. Peter Todd stated that he could backport it to 0.9 but wanted to hear from miners as to why they were still on v0.9.x.There was agreement with Peter's points, stating that BIP65 should be deployed immediately instead of waiting for the 0.12 schedule, as it would take too long. Some mining pools hinted at adopting BitcoinXT by the end of 2015, and earlier deployment of BIP65 would provide them with a patched version ready when they switch. Gavin also agreed to support BIP65 in XT. There was a question about backporting BIP65 to 0.9, similar to what happened during the deployment of BIP66.Peter Todd argued that CLTV should be deployed on v0.10.3 and IsSuperMajority() soft-fork on v0.11.1. He highlighted the benefits of CLTV for payment channels, making implementations simpler and more secure by removing malleability vulnerability. Todd emphasized that the implementation of the opcode has been peer-reviewed and thoroughly tested, and the deployment code has been copied from the successful BIP66. He believed that the risk of CLTV failing to get miner adoption is low and waiting for nVersion bits and CHECKSEQUENCEVERIFY would significantly delay deployment.Overall, the emails discuss various perspectives on the addition of CLTV to the Bitcoin protocol, the use of soft forks versus hard forks, and the concerns and solutions related to SPV wallets and node preparation for the upcoming soft fork. Peter Todd advocated for the deployment of CLTV and IsSuperMajority() soft-f 2015-10-13T00:08:49+00:00 + The email thread discusses the potential risks associated with a soft fork in the Bitcoin network. The effectiveness of an attack depends on the percentage of hash power that did not upgrade. Even with just 5% hash power and ~30% of nodes running the old version, a "damaging soft fork" still poses a high risk to someone receiving payments via an SPV client. The original emailer questions the significance of the risks posed by such an attack, as executing a double spend maliciously would be difficult due to the unpredictability of when a block would occur.There is a proposal to introduce a new flag in Core, called --scriptchecks=[all,standardonly,none], which would prioritize correctness by default and allow nodes to opt into pseudo-SPV behavior of a soft fork if desired. The advantages and disadvantages of hard forks and soft forks are discussed, with some arguing for a hard fork to avoid problems with SPV wallets during the rollout period. However, others believe that soft forks have a demonstrated track record of delivering new features with minimal problems.The deployment of BIP65 CHECKLOCKTIMEVERIFY in Bitcoin is also discussed. Mike Hearn expresses concerns about using a soft fork to implement this feature, suggesting that it should be a hard fork instead. Other participants emphasize the need for consensus before making any decisions. The conversation delves into the issues of miner adoption, the vulnerability of a soft fork, and the potential for double-spending attacks.The discussion highlights the complexities and trade-offs involved in implementing changes to the Bitcoin network, particularly in the context of soft forks and hard forks. The importance of upgrading full nodes and the risks associated with not doing so are emphasized. The conversations also touch on topics such as SPV wallets, the implementation of P2SH, and the advantages of communication and mitigation strategies.Overall, the discussions provide insights into different perspectives on the deployment of BIP65 CHECKLOCKTIMEVERIFY, the advantages and risks of soft forks versus hard forks, and the challenges faced in implementing changes in Bitcoin software. The email exchanges between Bitcoin developers touch on various topics related to upgrading Bitcoin software, the concept of consensus, and potential risks and solutions for SPV clients during soft forks. In addition, there are references to other email exchanges discussing topics such as the definition of a "working" full node, the risks and benefits of soft forks and hard forks, and the implications for SPV clients. The discussions highlight the need for refinement and adjustment of proposed changes, as well as the importance of developer consensus in the Bitcoin community.In a bitcoin-dev mailing list, Peter Todd expressed concerns about the delay in deploying CheckLockTimeVerify (CLTV) due to waiting for nVersion bits and CHECKSEQUENCEVERIFY. He suggested rolling out CLTV+CSV (CheckSequenceVerify) together by the 0.12 release if possible. However, if CSV is not ready, they would proceed with CLTV alone. The related pull requests for CSV are now ready for final review, and if that happens soon, CLTV+CSV would be rolled out together before 0.12.On September 27th, 2015, in an email exchange, a user named jl2012 expressed support for the deployment of BIP65 (CLTV) and asked about the possibility of backporting it to version 0.9. Peter Todd stated that he could backport it to 0.9 but wanted to hear from miners as to why they were still on v0.9.x.There was agreement with Peter's points, stating that BIP65 should be deployed immediately instead of waiting for the 0.12 schedule, as it would take too long. Some mining pools hinted at adopting BitcoinXT by the end of 2015, and earlier deployment of BIP65 would provide them with a patched version ready when they switch. Gavin also agreed to support BIP65 in XT. There was a question about backporting BIP65 to 0.9, similar to what happened during the deployment of BIP66.Peter Todd argued that CLTV should be deployed on v0.10.3 and IsSuperMajority() soft-fork on v0.11.1. He highlighted the benefits of CLTV for payment channels, making implementations simpler and more secure by removing malleability vulnerability. Todd emphasized that the implementation of the opcode has been peer-reviewed and thoroughly tested, and the deployment code has been copied from the successful BIP66. He believed that the risk of CLTV failing to get miner adoption is low and waiting for nVersion bits and CHECKSEQUENCEVERIFY would significantly delay deployment.Overall, the emails discuss various perspectives on the addition of CLTV to the Bitcoin protocol, the use of soft forks versus hard forks, and the concerns and solutions related to SPV wallets and node preparation for the upcoming soft fork. Peter Todd advocated for the deployment of CLTV and IsSuperMajority() soft-f - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Lightning-Network-s-effect-on-miner-fees.xml b/static/bitcoin-dev/Oct_2015/combined_Lightning-Network-s-effect-on-miner-fees.xml index 4e3f80b491..1fe8adbab5 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Lightning-Network-s-effect-on-miner-fees.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Lightning-Network-s-effect-on-miner-fees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Lightning Network's effect on miner fees - 2023-08-01T16:36:58.573115+00:00 + 2025-10-11T22:08:51.646362+00:00 + python-feedgen Daniel Stadulis 2015-10-15 03:35:59+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Lightning Network's effect on miner fees - 2023-08-01T16:36:58.573115+00:00 + 2025-10-11T22:08:51.646547+00:00 - The Lightning Network is an off-chain solution for Bitcoin transactions that can be used for smaller, predictable transactions. It makes economic sense to use the Lightning Network for transactions where the fee to include the transaction on the blockchain is more than the Time Value of Money of the encumbered funds on the Lightning Nodes. By minimizing the set of costs/externalities to the minimum necessary to conduct a series of transactions, there will be less transactions on the mainchain, which means less fees collected by the miners.The effect of the Lightning Network on fees is hard to predict, as it depends on user behavior around the dynamics of bid-side demand of fees. New classes of transactions will be possible that aren't possible today, and the market effect of 'instant' transactions after a network-joining-intro period will have on Bitcoin's utility/price/adoption is yet to be seen. Blockchain data scientists could study the effect of the fee market when high-volume exchanges unexpectedly halted trading.Regarding the block reward, idle hashing power becomes more of a threat in market scenarios where chain-extending PoW is scarce. If there isn't a convincing economic reason for a large majority of hashing power to be bolstering PoW defense on the main blockchain, the necessary number of block confirmation will go up, and there will be non-negligible mining power idle ready to defend actors' preferred chain. Large-value transactions that will be on the blockchain have more flexible time-settlement tolerance, and Lightning Network hot wallets are not an ideal place to store large quantities of BTC. Users that don't expect to be actively using the Lightning Network should prefer confirmed UTXOs for long-term cold storage.Paul Sztorc discusses how Lightning Network (LN) transactions are a substitute for on-chain transactions, leading to lower demand and fees for on-chain transactions. However, LN transactions cannot happen without periodic on-chain transactions. The demand for all Bitcoin transactions is influenced by various factors, including the form of money that trading partners will use. Supporting a higher rate of high-quality Bitcoin transactions is uncertain but will likely increase trading fees. If Bitcoin transactions' demand grows so high that we need the lightning network, there should be plenty of on-chain transactions for miners to collect fees from. The incentives of everyone involved in the lightning network are not clear, and it is unclear whether enforcing a percentage of fees collected by payment hubs to be spent as miner fees would make sense. There is a debate about whether the Lightning Network (LN) will lower fees for on-chain transactions or not. Paul Sztorc believes that LN transactions are a substitute good for on-chain transactions, so demand for on-chain transactions will decrease, leading to lower fees. On the other hand, LN transactions cannot take place without periodic on-chain transactions, so they are also perfect complements. The demand for all Bitcoin transactions, including LN and others, is affected by innumerable factors, one of which is the question of which form of money trading partners will use. Supporting a higher rate of higher-quality Bitcoin transactions may increase trading fees.S7r agrees with this theory that if Bitcoin transactions demand grows high enough to need the lightning network, there should be plenty of on-chain transactions for miners to collect fees from. However, the incentives of everyone involved in the lightning network, such as payment channel endpoints, hub operators, and miners, have not been fully seen yet. It might make sense to enforce a percentage of the fees collected by payment hubs to be spent as miner fees, regardless of whether the transactions from that hub go on the main chain or not.Paul Sztorc argues that Lightning Network (LN) transactions are a substitute for on-chain transactions. Therefore, the demand for on-chain transactions will decrease as a result of LN, leading to lower fees. However, LN and on-chain transactions are also perfect complements since LN transactions cannot take place without periodic on-chain transactions. The demand for all Bitcoin transactions is a function of various factors, including which form of money trading partners will use. By supporting a higher rate of higher-quality Bitcoin transactions, the net result is highly uncertain but may increase trading fees.The hashing power of Bitcoin is not related to scalability and decentralization but rather security. Having less decentralized big hashing power is preferable to having less hashing power. If Bitcoin transactions demand grows so high that we require the lightning network, there should be plenty of on-chain transactions for miners to collect fees from. However, the incentives of everyone involved in the lightning network are unknown at this point. It might make sense to enforce a percentage of the fees collected by payment hubs to be spent as miner fees, regardless of whether the transactions from that hub go on the main chain or not.In a discussion on the Bitcoin-dev mailing list, Paul Sztorc pointed out that Lightning Network (LN) transactions cannot take place without periodic on-chain transactions. As such, while LN is a complementary technology to Bitcoin, it still relies on the underlying blockchain to function. Additionally, 2015-10-15T03:35:59+00:00 + The Lightning Network is an off-chain solution for Bitcoin transactions that can be used for smaller, predictable transactions. It makes economic sense to use the Lightning Network for transactions where the fee to include the transaction on the blockchain is more than the Time Value of Money of the encumbered funds on the Lightning Nodes. By minimizing the set of costs/externalities to the minimum necessary to conduct a series of transactions, there will be less transactions on the mainchain, which means less fees collected by the miners.The effect of the Lightning Network on fees is hard to predict, as it depends on user behavior around the dynamics of bid-side demand of fees. New classes of transactions will be possible that aren't possible today, and the market effect of 'instant' transactions after a network-joining-intro period will have on Bitcoin's utility/price/adoption is yet to be seen. Blockchain data scientists could study the effect of the fee market when high-volume exchanges unexpectedly halted trading.Regarding the block reward, idle hashing power becomes more of a threat in market scenarios where chain-extending PoW is scarce. If there isn't a convincing economic reason for a large majority of hashing power to be bolstering PoW defense on the main blockchain, the necessary number of block confirmation will go up, and there will be non-negligible mining power idle ready to defend actors' preferred chain. Large-value transactions that will be on the blockchain have more flexible time-settlement tolerance, and Lightning Network hot wallets are not an ideal place to store large quantities of BTC. Users that don't expect to be actively using the Lightning Network should prefer confirmed UTXOs for long-term cold storage.Paul Sztorc discusses how Lightning Network (LN) transactions are a substitute for on-chain transactions, leading to lower demand and fees for on-chain transactions. However, LN transactions cannot happen without periodic on-chain transactions. The demand for all Bitcoin transactions is influenced by various factors, including the form of money that trading partners will use. Supporting a higher rate of high-quality Bitcoin transactions is uncertain but will likely increase trading fees. If Bitcoin transactions' demand grows so high that we need the lightning network, there should be plenty of on-chain transactions for miners to collect fees from. The incentives of everyone involved in the lightning network are not clear, and it is unclear whether enforcing a percentage of fees collected by payment hubs to be spent as miner fees would make sense. There is a debate about whether the Lightning Network (LN) will lower fees for on-chain transactions or not. Paul Sztorc believes that LN transactions are a substitute good for on-chain transactions, so demand for on-chain transactions will decrease, leading to lower fees. On the other hand, LN transactions cannot take place without periodic on-chain transactions, so they are also perfect complements. The demand for all Bitcoin transactions, including LN and others, is affected by innumerable factors, one of which is the question of which form of money trading partners will use. Supporting a higher rate of higher-quality Bitcoin transactions may increase trading fees.S7r agrees with this theory that if Bitcoin transactions demand grows high enough to need the lightning network, there should be plenty of on-chain transactions for miners to collect fees from. However, the incentives of everyone involved in the lightning network, such as payment channel endpoints, hub operators, and miners, have not been fully seen yet. It might make sense to enforce a percentage of the fees collected by payment hubs to be spent as miner fees, regardless of whether the transactions from that hub go on the main chain or not.Paul Sztorc argues that Lightning Network (LN) transactions are a substitute for on-chain transactions. Therefore, the demand for on-chain transactions will decrease as a result of LN, leading to lower fees. However, LN and on-chain transactions are also perfect complements since LN transactions cannot take place without periodic on-chain transactions. The demand for all Bitcoin transactions is a function of various factors, including which form of money trading partners will use. By supporting a higher rate of higher-quality Bitcoin transactions, the net result is highly uncertain but may increase trading fees.The hashing power of Bitcoin is not related to scalability and decentralization but rather security. Having less decentralized big hashing power is preferable to having less hashing power. If Bitcoin transactions demand grows so high that we require the lightning network, there should be plenty of on-chain transactions for miners to collect fees from. However, the incentives of everyone involved in the lightning network are unknown at this point. It might make sense to enforce a percentage of the fees collected by payment hubs to be spent as miner fees, regardless of whether the transactions from that hub go on the main chain or not.In a discussion on the Bitcoin-dev mailing list, Paul Sztorc pointed out that Lightning Network (LN) transactions cannot take place without periodic on-chain transactions. As such, while LN is a complementary technology to Bitcoin, it still relies on the underlying blockchain to function. Additionally, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Liquid.xml b/static/bitcoin-dev/Oct_2015/combined_Liquid.xml index ede6e1736b..a746cf4907 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Liquid.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Liquid.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Liquid - 2023-08-01T16:35:20.420480+00:00 + 2025-10-11T22:08:45.276950+00:00 + python-feedgen Adam Back 2015-10-13 20:52:39+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Liquid - 2023-08-01T16:35:20.420480+00:00 + 2025-10-11T22:08:45.277121+00:00 - In an email thread from October 2015, Benjamin expresses surprise and confusion over Blockstream's announcement to implement sidechains for exchanges. He questions the relevance of Bitcoin to existing financial institutions and the use of terms like "settlement" and "capital requirements" in relation to Bitcoin. Benjamin also wonders if Blockstream now has commercial products and raises concerns about the launch partners mentioned in the announcement.Daniel responds by clarifying that Benjamin's questions are misplaced as he is conflating Bitcoin with Blockstream/Liquid. He explains that Blockstream does have commercial products and that implementing sidechains for exchanges was always part of their plan.Adam suggests that Benjamin read a Reddit thread on Liquid to find answers to his questions. He also notes that the email thread is off-topic for bitcoin-dev as it pertains to Bitcoin development.Overall, the email thread discusses Blockstream's implementation of sidechains for exchanges, highlighting questions and confusion regarding Bitcoin's relevance to financial institutions, market liquidity, capital requirements, and Blockstream's commercial products and launch partners. 2015-10-13T20:52:39+00:00 + In an email thread from October 2015, Benjamin expresses surprise and confusion over Blockstream's announcement to implement sidechains for exchanges. He questions the relevance of Bitcoin to existing financial institutions and the use of terms like "settlement" and "capital requirements" in relation to Bitcoin. Benjamin also wonders if Blockstream now has commercial products and raises concerns about the launch partners mentioned in the announcement.Daniel responds by clarifying that Benjamin's questions are misplaced as he is conflating Bitcoin with Blockstream/Liquid. He explains that Blockstream does have commercial products and that implementing sidechains for exchanges was always part of their plan.Adam suggests that Benjamin read a Reddit thread on Liquid to find answers to his questions. He also notes that the email thread is off-topic for bitcoin-dev as it pertains to Bitcoin development.Overall, the email thread discusses Blockstream's implementation of sidechains for exchanges, highlighting questions and confusion regarding Bitcoin's relevance to financial institutions, market liquidity, capital requirements, and Blockstream's commercial products and launch partners. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Mailing-List-Moderation-Now-Active-.xml b/static/bitcoin-dev/Oct_2015/combined_Mailing-List-Moderation-Now-Active-.xml index 7b0ddec5ac..4c1e5ae1a0 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Mailing-List-Moderation-Now-Active-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Mailing-List-Moderation-Now-Active-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mailing List Moderation Now Active. - 2023-08-01T16:43:51.827336+00:00 + 2025-10-11T22:08:34.650384+00:00 + python-feedgen Mike Hearn 2015-10-28 10:26:56+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Mailing List Moderation Now Active. - 2023-08-01T16:43:51.827336+00:00 + 2025-10-11T22:08:34.650568+00:00 - Gavin Andresen expresses frustration with the moderation policy on an unknown platform, describing it as a disaster. He mentions that several messages, including his own and those from Sergio Damian Lerner, have already been rejected. These rejected messages cover topics such as a bug, CLTV, censorship of technical discussion, and complaints about censorship. Gavin concludes his post with a bewildered "WTF?" remark.On October 22, 2015, Rusty Russell announces on bitcoin-dev that all rejected posts will be forwarded to a public viewing list. However, these forwarded messages are not readable and only contain a message stating that an embedded message was scrubbed, along with a non-text attachment named signature.asc.A user on the Bitcoin subreddit asks if block size discussions are acceptable under the rule that posts must concern the near-term development of the Bitcoin core code or Bitcoin protocol.The Bitcoin Development Mailing List has implemented new moderator rules to increase productivity and improve interactions among developers. The moderation period will last for three months, after which there will be an on-list discussion to determine whether it should continue or change. Appeals regarding moderation decisions should be directed to Jeff, the final decision-maker. All rejected posts will be forwarded to a public viewing list.Currently, there are five moderators: BtcDrak, G1lius, Kanzure, Johnathan, and the author of the post. They represent Asia, Europe, and the US and have no connection to each other. The moderation rules include no offensive posts or personal attacks, and posts must pertain to the near-term development of the Bitcoin core code or Bitcoin protocol. Additionally, posts must contribute to Bitcoin development. Encouraged topics include patches, pull request notifications, BIP proposals, academic paper announcements, and consequential discussions. Conversely, discouraged topics include shower thoughts, wild speculation, jokes, non-technical Bitcoin issues, rehashing settled topics without new data, and moderation concerns. Detailed patch discussions are recommended on GitHub PR, while meta-discussions are better suited for bitcoin-discuss.All subscribers start off as moderated, with the mod bit cleared when they post. However, it can be set again if a violation is noticed or reported. The moderators recognize that mistakes may occur and ask subscribers for patience. 2015-10-28T10:26:56+00:00 + Gavin Andresen expresses frustration with the moderation policy on an unknown platform, describing it as a disaster. He mentions that several messages, including his own and those from Sergio Damian Lerner, have already been rejected. These rejected messages cover topics such as a bug, CLTV, censorship of technical discussion, and complaints about censorship. Gavin concludes his post with a bewildered "WTF?" remark.On October 22, 2015, Rusty Russell announces on bitcoin-dev that all rejected posts will be forwarded to a public viewing list. However, these forwarded messages are not readable and only contain a message stating that an embedded message was scrubbed, along with a non-text attachment named signature.asc.A user on the Bitcoin subreddit asks if block size discussions are acceptable under the rule that posts must concern the near-term development of the Bitcoin core code or Bitcoin protocol.The Bitcoin Development Mailing List has implemented new moderator rules to increase productivity and improve interactions among developers. The moderation period will last for three months, after which there will be an on-list discussion to determine whether it should continue or change. Appeals regarding moderation decisions should be directed to Jeff, the final decision-maker. All rejected posts will be forwarded to a public viewing list.Currently, there are five moderators: BtcDrak, G1lius, Kanzure, Johnathan, and the author of the post. They represent Asia, Europe, and the US and have no connection to each other. The moderation rules include no offensive posts or personal attacks, and posts must pertain to the near-term development of the Bitcoin core code or Bitcoin protocol. Additionally, posts must contribute to Bitcoin development. Encouraged topics include patches, pull request notifications, BIP proposals, academic paper announcements, and consequential discussions. Conversely, discouraged topics include shower thoughts, wild speculation, jokes, non-technical Bitcoin issues, rehashing settled topics without new data, and moderation concerns. Detailed patch discussions are recommended on GitHub PR, while meta-discussions are better suited for bitcoin-discuss.All subscribers start off as moderated, with the mod bit cleared when they post. However, it can be set again if a violation is noticed or reported. The moderators recognize that mistakes may occur and ask subscribers for patience. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Memory-leaks-.xml b/static/bitcoin-dev/Oct_2015/combined_Memory-leaks-.xml index c509c94bea..1813ac8bec 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Memory-leaks-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Memory-leaks-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Memory leaks? - 2023-08-01T16:36:18.332240+00:00 + 2025-10-11T22:08:55.893181+00:00 + python-feedgen Rusty Russell 2015-10-23 06:41:49+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Memory leaks? - 2023-08-01T16:36:18.332240+00:00 + 2025-10-11T22:08:55.893419+00:00 - On October 13, 2015, a discussion about high memory usage in Bitcoin nodes took place on the bitcoin-dev mailing list. Jonathan Toomim raised the issue of his running bitcoind processes using around 3GB of RAM, even though the mempool was under control. He restarted the process and noticed that the memory usage became more reasonable. Another user reported a similar problem with 35 GB of RSS usage, sparking speculation that CreateNewBlock() and getblocktemplate might be the cause. Tom Zander suggested accurately measuring memory usage on Linux and shared a script for this purpose.The conversation also touched upon the need to investigate possible memory leaks, caches, and fragmentation as potential causes of the high memory usage. Valgrind was mentioned as a possible tool for detecting memory leaks, although it did not provide promising results at the time. The suggestion to run bitcoind in valgrind with the --leak-check=full option for 10 minutes was given. It was also noted that leaks may not be the only explanation, as caches and fragmentation could contribute to the observed memory usage.The issue of high memory usage in Bitcoin nodes was further discussed, with suggestions to mitigate mempool growth by setting the -mintxfee flag. It was mentioned that this would be the default in future versions. Version 0.12.0 was planned to include better mempool management and more precise reporting.The email thread also included discussions about cross-posting confusion and warnings against trolling behavior. Various topics related to memory usage were touched upon, such as accurately measuring memory on Linux, investigating memory leaks, and the potential impact of caches and fragmentation.Overall, the conversation revolved around identifying the cause of high memory usage in Bitcoin nodes, exploring possible solutions, and sharing insights and experiences related to memory management in the Bitcoin ecosystem.In addition to the above discussion, there were other instances where users experienced high memory usage in running bitcoind processes, even though the mempool was under control. Restarting the processes resulted in a significant drop in memory usage. The issue seemed to occur with both Bitcoin Core 0.10.1 and Bitcoin XT 0.11B, leading to speculation about a memory leak in the minrelaytxfee code path. Users observed that their running bitcoind processes were using over 3 GB of RAM despite the mempool being under control. Accurate reporting of memory pool usage in newer versions of bitcoind reflects real memory usage.One user named odinn reported excessive memory consumption on three machines running Debian and p2pool, with two running XT and one running Core. They mentioned the resident set size of bitcoind and requested information on mempool size and total bitcoind resident set size from other users.The anomalous scaling of memory usage in bitcoin was also noted, along with concerns about the unlikely transaction size of 15 kB per transaction and an increase in the size of an unidentified file. There were requests for information on the memory usage of Task Manager for the bitcoin process.The discussions highlighted the need to investigate memory leaks, caches, and fragmentation as potential causes of high memory usage. The minrelaytxfee code path was identified as a possible source of the memory leak. 2015-10-23T06:41:49+00:00 + On October 13, 2015, a discussion about high memory usage in Bitcoin nodes took place on the bitcoin-dev mailing list. Jonathan Toomim raised the issue of his running bitcoind processes using around 3GB of RAM, even though the mempool was under control. He restarted the process and noticed that the memory usage became more reasonable. Another user reported a similar problem with 35 GB of RSS usage, sparking speculation that CreateNewBlock() and getblocktemplate might be the cause. Tom Zander suggested accurately measuring memory usage on Linux and shared a script for this purpose.The conversation also touched upon the need to investigate possible memory leaks, caches, and fragmentation as potential causes of the high memory usage. Valgrind was mentioned as a possible tool for detecting memory leaks, although it did not provide promising results at the time. The suggestion to run bitcoind in valgrind with the --leak-check=full option for 10 minutes was given. It was also noted that leaks may not be the only explanation, as caches and fragmentation could contribute to the observed memory usage.The issue of high memory usage in Bitcoin nodes was further discussed, with suggestions to mitigate mempool growth by setting the -mintxfee flag. It was mentioned that this would be the default in future versions. Version 0.12.0 was planned to include better mempool management and more precise reporting.The email thread also included discussions about cross-posting confusion and warnings against trolling behavior. Various topics related to memory usage were touched upon, such as accurately measuring memory on Linux, investigating memory leaks, and the potential impact of caches and fragmentation.Overall, the conversation revolved around identifying the cause of high memory usage in Bitcoin nodes, exploring possible solutions, and sharing insights and experiences related to memory management in the Bitcoin ecosystem.In addition to the above discussion, there were other instances where users experienced high memory usage in running bitcoind processes, even though the mempool was under control. Restarting the processes resulted in a significant drop in memory usage. The issue seemed to occur with both Bitcoin Core 0.10.1 and Bitcoin XT 0.11B, leading to speculation about a memory leak in the minrelaytxfee code path. Users observed that their running bitcoind processes were using over 3 GB of RAM despite the mempool being under control. Accurate reporting of memory pool usage in newer versions of bitcoind reflects real memory usage.One user named odinn reported excessive memory consumption on three machines running Debian and p2pool, with two running XT and one running Core. They mentioned the resident set size of bitcoind and requested information on mempool size and total bitcoind resident set size from other users.The anomalous scaling of memory usage in bitcoin was also noted, along with concerns about the unlikely transaction size of 15 kB per transaction and an increase in the size of an unidentified file. There were requests for information on the memory usage of Task Manager for the bitcoin process.The discussions highlighted the need to investigate memory leaks, caches, and fragmentation as potential causes of high memory usage. The minrelaytxfee code path was identified as a possible source of the memory leak. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Mike-Hearn-who-coined-the-term-SPV-is-Satoshi.xml b/static/bitcoin-dev/Oct_2015/combined_Mike-Hearn-who-coined-the-term-SPV-is-Satoshi.xml index 59aee1fd14..d788de8d01 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Mike-Hearn-who-coined-the-term-SPV-is-Satoshi.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Mike-Hearn-who-coined-the-term-SPV-is-Satoshi.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Mike Hearn, who coined the term SPV is Satoshi - 2023-08-01T16:34:38.544822+00:00 + 2025-10-11T22:08:07.027781+00:00 + python-feedgen Sriram Karra 2015-10-09 04:22:32+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Mike Hearn, who coined the term SPV is Satoshi - 2023-08-01T16:34:38.544822+00:00 + 2025-10-11T22:08:07.027918+00:00 - On October 9th, 2015, Boris Neklabaro shared a link on the Bitcoin-dev mailing list. The link directed users to a website that required the use of Tor Browser, an encrypted and anonymous web browser. The context does not provide any details about the purpose or content of the website.However, it is important to note that the link to the website was also provided without the requirement of using Tor Browser. This alternate link allowed users to access the website without the need for encryption or anonymity.In summary, the context presents a link to an interesting website that can be accessed through Tor Browser. However, it is also possible to access the website without Tor Browser through the provided alternate link. No further information is given regarding the nature or content of the website. 2015-10-09T04:22:32+00:00 + On October 9th, 2015, Boris Neklabaro shared a link on the Bitcoin-dev mailing list. The link directed users to a website that required the use of Tor Browser, an encrypted and anonymous web browser. The context does not provide any details about the purpose or content of the website.However, it is important to note that the link to the website was also provided without the requirement of using Tor Browser. This alternate link allowed users to access the website without the need for encryption or anonymity.In summary, the context presents a link to an interesting website that can be accessed through Tor Browser. However, it is also possible to access the website without Tor Browser through the provided alternate link. No further information is given regarding the nature or content of the website. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_New-BIP32-structure-for-P2SH-multisig-wallets-BIP-45-.xml b/static/bitcoin-dev/Oct_2015/combined_New-BIP32-structure-for-P2SH-multisig-wallets-BIP-45-.xml index df035445a3..4d0e320b48 100644 --- a/static/bitcoin-dev/Oct_2015/combined_New-BIP32-structure-for-P2SH-multisig-wallets-BIP-45-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_New-BIP32-structure-for-P2SH-multisig-wallets-BIP-45-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New BIP32 structure for P2SH multisig wallets [BIP-45] - 2023-08-01T16:29:01.179451+00:00 + 2025-10-11T22:09:02.277787+00:00 + python-feedgen Jean-Pierre Rupp 2015-10-05 19:36:05+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - New BIP32 structure for P2SH multisig wallets [BIP-45] - 2023-08-01T16:29:01.179451+00:00 + 2025-10-11T22:09:02.277932+00:00 - The discussion revolves around the use of extended public keys in multisig arrangements following the BIP-45 specification. It is mentioned that using the same derivation for all multi-signature accounts simplifies the workflow, but it becomes harder to restore the wallet if all information except for the mnemonic and extended public keys is lost.In an email exchange, Jean-Pierre Rupp expresses concern about a privacy issue in BIP-45. He explains that reusing the same set of public keys allows all cosigners to monitor each other's multi-signature activity. Matias Alejo Garcia responds, stating that each party can see the transaction history of the shared wallet but should use different xpubs for other wallets.The context includes a PGP signed message discussing the use of extended public keys in multisig arrangements. It suggests Pedro participating in a 2-of-2 cosigning arrangement with a merchant, using the same extended public key derived from path m/45'. The message discusses the difference between using m/i'/45' and m/45' within a BIP45 wallet like Copay.A multisig account is explained as an agreement between cosigners requiring a set number of signatures. It follows the BIP-45 specification, and each cosigner's address public key is obtained from the master key's derivation path. Reusing the same set of extended public keys is not required or recommended by BIP45. Each signing party needs the extended public keys of all other parties, and they can see the transaction history of the shared wallet.On October 4, 2015, Thomas Kerin suggests amending BIP45, but he is informed that BIPs are not amended after the fact. Instead, it may be best to write a new BIP specifying a "pseudorandom & deterministic path generation for HD/multi-signature accounts."A developer raises concerns about the privacy issue caused by reusing public keys in multi-signature addresses restored from a seed. A possible solution is proposed, involving sorting and hashing the public keys to build a derivation path. However, it is noted that unless users establish a single co-signing account, this scheme will result in public key reuse and privacy degradation.The context also mentions the author reviewing BIP-45 and identifying a privacy issue with using the same extended public key for all multi-sig activity. They suggest including privacy and security degradation due to increased public key reuse in the BIP-45 document. They propose a solution involving sorting and hashing public keys to avoid sharing them.The email concludes with an invitation for feedback on the team's approach to building Copay, a multisignature P2SH HD wallet. The team outlines their assumptions and general address generation procedure. They also discuss lexicographically sorting public keys and the need for a non-hardened version of the purpose for the path. 2015-10-05T19:36:05+00:00 + The discussion revolves around the use of extended public keys in multisig arrangements following the BIP-45 specification. It is mentioned that using the same derivation for all multi-signature accounts simplifies the workflow, but it becomes harder to restore the wallet if all information except for the mnemonic and extended public keys is lost.In an email exchange, Jean-Pierre Rupp expresses concern about a privacy issue in BIP-45. He explains that reusing the same set of public keys allows all cosigners to monitor each other's multi-signature activity. Matias Alejo Garcia responds, stating that each party can see the transaction history of the shared wallet but should use different xpubs for other wallets.The context includes a PGP signed message discussing the use of extended public keys in multisig arrangements. It suggests Pedro participating in a 2-of-2 cosigning arrangement with a merchant, using the same extended public key derived from path m/45'. The message discusses the difference between using m/i'/45' and m/45' within a BIP45 wallet like Copay.A multisig account is explained as an agreement between cosigners requiring a set number of signatures. It follows the BIP-45 specification, and each cosigner's address public key is obtained from the master key's derivation path. Reusing the same set of extended public keys is not required or recommended by BIP45. Each signing party needs the extended public keys of all other parties, and they can see the transaction history of the shared wallet.On October 4, 2015, Thomas Kerin suggests amending BIP45, but he is informed that BIPs are not amended after the fact. Instead, it may be best to write a new BIP specifying a "pseudorandom & deterministic path generation for HD/multi-signature accounts."A developer raises concerns about the privacy issue caused by reusing public keys in multi-signature addresses restored from a seed. A possible solution is proposed, involving sorting and hashing the public keys to build a derivation path. However, it is noted that unless users establish a single co-signing account, this scheme will result in public key reuse and privacy degradation.The context also mentions the author reviewing BIP-45 and identifying a privacy issue with using the same extended public key for all multi-sig activity. They suggest including privacy and security degradation due to increased public key reuse in the BIP-45 document. They propose a solution involving sorting and hashing public keys to avoid sharing them.The email concludes with an invitation for feedback on the team's approach to building Copay, a multisignature P2SH HD wallet. The team outlines their assumptions and general address generation procedure. They also discuss lexicographically sorting public keys and the need for a non-hardened version of the purpose for the path. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Proposed-list-moderation-policy-and-conduct.xml b/static/bitcoin-dev/Oct_2015/combined_Proposed-list-moderation-policy-and-conduct.xml index 6a965572b5..a233574081 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Proposed-list-moderation-policy-and-conduct.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Proposed-list-moderation-policy-and-conduct.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed list moderation policy and conduct - 2023-08-01T16:39:22.353137+00:00 + 2025-10-11T22:08:19.773736+00:00 + python-feedgen odinn 2015-10-15 08:38:35+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Proposed list moderation policy and conduct - 2023-08-01T16:39:22.353137+00:00 + 2025-10-11T22:08:19.773866+00:00 - In the bitcoin-dev mailing list, there has been a discussion about the need for participants to disclose any potential conflicts of interest they may have. This is important in order to maintain transparency and trust within the project. However, there has been some concern about the use of labels such as "Bitcoin maximalist" which limit the extent of discourse and can lead to name-calling. Some participants believe that anyone who is not a Bitcoin maximalist may have a conflict of interest if they are involved in Bitcoin development.This issue has caused dissatisfaction among users and investors, as they need to trust that developers are working towards the success of Bitcoin. It has been suggested that the mailing list would be better off without a policy document enforced by moderators. The idea is to keep the protocol free of financial censorship, which extends to language as well. People should be able to express themselves freely, even if others on the list disagree with them.Jeff Garzik, a participant in the bitcoin-dev mailing list, has emphasized the importance of disclosing conflicts of interest related to employment or other projects. He believes that over-disclosure is better than under-disclosure when it comes to perceived conflicts of interest. Garzik also discussed the term "Bitcoin maximalist" and how it has become an insult. He argues that anyone involved in Bitcoin development who is not a Bitcoin maximalist could potentially have a conflict of interest if they work for a company that competes with Bitcoin.The author of a message on the mailing list expressed concerns about the lack of an objective measure of what is considered "on-topic." They believe that someone will always call something "off topic" regardless of how relevant it actually is. The proposed list moderation policy aims to facilitate constructive discussions related to the technical development of the bitcoin protocol. However, the author argues that the current language of the policy needs further discussion and refinement. They suggest removing the enforcement and moderator sections and instead having an "about" section that outlines the purpose of the list and how participants are expected to treat each other.Luke Dashjr, another participant in the bitcoin-dev mailing list, suggested that only development-related discussions should be allowed on the list. Off-topic threads would be directed to other venues. He also expressed concern about discussions of conduct on the list, as it can create noise and distract from technical discussions.In October 2015, Jeff Garzik provided guidelines for etiquette on the forum. He emphasized the importance of being polite and providing helpful documentation or directing someone to more appropriate venues when they ask for help. He also stressed the need for conversations to remain focused and on-topic, and if a topic needs to be changed, a new thread should be started. At the time, there were no other venues provided for off-topic threads. Disclosing potential conflicts of interest seemed futile for anyone not exclusively associated with a single company or organization. Discussing conduct on the list was considered off-topic noise.The bitcoin-dev mailing list aims to facilitate constructive discussions related to the technical development of the bitcoin protocol and Bitcoin Core reference implementation. The proposed policy serves to maintain a welcoming and collaborative environment. It includes guidelines for being friendly, patient, civil, considerate, assuming good faith, respecting time and attention, and disclosing potential conflicts. Failure to observe the code may result in reprimand, probation, or removal from the list. The policy is enforced through direct contact, on-list discussion, or reaching out to moderators. Moderators are selected from various projects and roles to avoid any bias.Other resources that provide guidance for good behavior include Producing OSS by Karl Fogel, RFC 1855, and the Ubuntu Code of Conduct. The policy was inspired by codes of conduct used in other projects such as GNOME, Mozilla, and Ubuntu. 2015-10-15T08:38:35+00:00 + In the bitcoin-dev mailing list, there has been a discussion about the need for participants to disclose any potential conflicts of interest they may have. This is important in order to maintain transparency and trust within the project. However, there has been some concern about the use of labels such as "Bitcoin maximalist" which limit the extent of discourse and can lead to name-calling. Some participants believe that anyone who is not a Bitcoin maximalist may have a conflict of interest if they are involved in Bitcoin development.This issue has caused dissatisfaction among users and investors, as they need to trust that developers are working towards the success of Bitcoin. It has been suggested that the mailing list would be better off without a policy document enforced by moderators. The idea is to keep the protocol free of financial censorship, which extends to language as well. People should be able to express themselves freely, even if others on the list disagree with them.Jeff Garzik, a participant in the bitcoin-dev mailing list, has emphasized the importance of disclosing conflicts of interest related to employment or other projects. He believes that over-disclosure is better than under-disclosure when it comes to perceived conflicts of interest. Garzik also discussed the term "Bitcoin maximalist" and how it has become an insult. He argues that anyone involved in Bitcoin development who is not a Bitcoin maximalist could potentially have a conflict of interest if they work for a company that competes with Bitcoin.The author of a message on the mailing list expressed concerns about the lack of an objective measure of what is considered "on-topic." They believe that someone will always call something "off topic" regardless of how relevant it actually is. The proposed list moderation policy aims to facilitate constructive discussions related to the technical development of the bitcoin protocol. However, the author argues that the current language of the policy needs further discussion and refinement. They suggest removing the enforcement and moderator sections and instead having an "about" section that outlines the purpose of the list and how participants are expected to treat each other.Luke Dashjr, another participant in the bitcoin-dev mailing list, suggested that only development-related discussions should be allowed on the list. Off-topic threads would be directed to other venues. He also expressed concern about discussions of conduct on the list, as it can create noise and distract from technical discussions.In October 2015, Jeff Garzik provided guidelines for etiquette on the forum. He emphasized the importance of being polite and providing helpful documentation or directing someone to more appropriate venues when they ask for help. He also stressed the need for conversations to remain focused and on-topic, and if a topic needs to be changed, a new thread should be started. At the time, there were no other venues provided for off-topic threads. Disclosing potential conflicts of interest seemed futile for anyone not exclusively associated with a single company or organization. Discussing conduct on the list was considered off-topic noise.The bitcoin-dev mailing list aims to facilitate constructive discussions related to the technical development of the bitcoin protocol and Bitcoin Core reference implementation. The proposed policy serves to maintain a welcoming and collaborative environment. It includes guidelines for being friendly, patient, civil, considerate, assuming good faith, respecting time and attention, and disclosing potential conflicts. Failure to observe the code may result in reprimand, probation, or removal from the list. The policy is enforced through direct contact, on-list discussion, or reaching out to moderators. Moderators are selected from various projects and roles to avoid any bias.Other resources that provide guidance for good behavior include Producing OSS by Karl Fogel, RFC 1855, and the Ubuntu Code of Conduct. The policy was inspired by codes of conduct used in other projects such as GNOME, Mozilla, and Ubuntu. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml b/static/bitcoin-dev/Oct_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml index e3d6d85bb9..43891900d2 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed new policy for transactions that depend on other unconfirmed transactions - 2023-08-01T15:15:59.869443+00:00 + 2025-10-11T22:08:24.023301+00:00 + python-feedgen Taariq Lewis 2015-10-08 06:10:37+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Proposed new policy for transactions that depend on other unconfirmed transactions - 2023-08-01T15:15:59.869443+00:00 + 2025-10-11T22:08:24.023513+00:00 - The proposed policy limits on unconfirmed transaction chains in Bitcoin Core are currently under discussion among developers. The existing limits for descendant packages are 1000 transactions and 2500kb total size, while for ancestor packages, the limits are 100 transactions and 900kb total size. However, there is a proposal to change these limits to 25 transactions and 100kb total size for both types of packages. It is important to note that these proposed limits are not a change to consensus rules and can be adjusted on an individual node basis in Bitcoin Core.In addition to the proposed limits on unconfirmed transaction chains, Alex Morcos has put forward a set of requirements for accepting new transactions into the mempool and relaying them. The aim of this policy is to limit the size of the mempool and ensure that a new transaction can cover the costs of any dependent transactions it may displace. Four new policy limits have been proposed, all of which can be configured using command line settings. In April and May of this year, these proposed limits would have affected less than 2% of transactions entering the mempool. However, during a stress test period, as many as 25% of transactions would have been impacted.The reason for reducing the limits on unconfirmed transaction chains is primarily due to concerns about mempool congestion and relay fee boosting attacks. The current limits for ancestor packages are 100 transactions and 900kb total size, while for descendant packages, the limits are 1000 transactions and 2500kb total size. The proposed new limits for both types of packages would be 25 transactions and 100kb total size. It is worth noting that these limits do not alter consensus rules and can be customized for each individual node using Bitcoin Core.Alex Morcos has made significant proposals to decrease the current policy limits on unconfirmed transaction chains. The existing limits for ancestor packages are 100 transactions and 900 kilobytes of total size, while for descendant packages, the limits are 1000 transactions and 2500 kilobytes of total size. The proposed new limits for both types of packages are 25 transactions and 100 kilobytes of total size. These limits can be adjusted at the command line level on each node that utilizes Bitcoin Core.To ensure a smooth and efficient transaction process, certain limits have been established. The first limit restricts transactions larger than 100 kilobytes from being accepted. This ensures that the size of transactions remains within a reasonable range. The second limit focuses on the fee rate, disallowing transactions with a fee rate equal to or less than 1 satoshi per byte. This encourages users to attach an appropriate fee, which helps prioritize their transactions. The third limit aims to prevent transaction flooding attacks by rejecting transactions that would cause the mempool's total size to exceed 300 megabytes. This safeguard protects the network from becoming overwhelmed by a large number of transactions. Lastly, the fourth limit maintains the policy that all transactions in the mempool should be mineable in the next block. To achieve this, transactions will not be accepted if the total size of all unconfirmed ancestor transactions is too large. By default, this limit is set at 1 megabyte.It is important to note that these limits would have affected less than 2% of transactions entering the mempool in April or May of this year. However, during the stress test period from July 6th to July 14th, up to 25% of the transactions would have been impacted. For those interested in the technical details, the code to implement these changes can be found in pull request 6557, which is based on pull request 6470. These pull requests contain the necessary modifications to enforce the aforementioned limits and enhance the overall transaction process. 2015-10-08T06:10:37+00:00 + The proposed policy limits on unconfirmed transaction chains in Bitcoin Core are currently under discussion among developers. The existing limits for descendant packages are 1000 transactions and 2500kb total size, while for ancestor packages, the limits are 100 transactions and 900kb total size. However, there is a proposal to change these limits to 25 transactions and 100kb total size for both types of packages. It is important to note that these proposed limits are not a change to consensus rules and can be adjusted on an individual node basis in Bitcoin Core.In addition to the proposed limits on unconfirmed transaction chains, Alex Morcos has put forward a set of requirements for accepting new transactions into the mempool and relaying them. The aim of this policy is to limit the size of the mempool and ensure that a new transaction can cover the costs of any dependent transactions it may displace. Four new policy limits have been proposed, all of which can be configured using command line settings. In April and May of this year, these proposed limits would have affected less than 2% of transactions entering the mempool. However, during a stress test period, as many as 25% of transactions would have been impacted.The reason for reducing the limits on unconfirmed transaction chains is primarily due to concerns about mempool congestion and relay fee boosting attacks. The current limits for ancestor packages are 100 transactions and 900kb total size, while for descendant packages, the limits are 1000 transactions and 2500kb total size. The proposed new limits for both types of packages would be 25 transactions and 100kb total size. It is worth noting that these limits do not alter consensus rules and can be customized for each individual node using Bitcoin Core.Alex Morcos has made significant proposals to decrease the current policy limits on unconfirmed transaction chains. The existing limits for ancestor packages are 100 transactions and 900 kilobytes of total size, while for descendant packages, the limits are 1000 transactions and 2500 kilobytes of total size. The proposed new limits for both types of packages are 25 transactions and 100 kilobytes of total size. These limits can be adjusted at the command line level on each node that utilizes Bitcoin Core.To ensure a smooth and efficient transaction process, certain limits have been established. The first limit restricts transactions larger than 100 kilobytes from being accepted. This ensures that the size of transactions remains within a reasonable range. The second limit focuses on the fee rate, disallowing transactions with a fee rate equal to or less than 1 satoshi per byte. This encourages users to attach an appropriate fee, which helps prioritize their transactions. The third limit aims to prevent transaction flooding attacks by rejecting transactions that would cause the mempool's total size to exceed 300 megabytes. This safeguard protects the network from becoming overwhelmed by a large number of transactions. Lastly, the fourth limit maintains the policy that all transactions in the mempool should be mineable in the next block. To achieve this, transactions will not be accepted if the total size of all unconfirmed ancestor transactions is too large. By default, this limit is set at 1 megabyte.It is important to note that these limits would have affected less than 2% of transactions entering the mempool in April or May of this year. However, during the stress test period from July 6th to July 14th, up to 25% of the transactions would have been impacted. For those interested in the technical details, the code to implement these changes can be found in pull request 6557, which is based on pull request 6470. These pull requests contain the necessary modifications to enforce the aforementioned limits and enhance the overall transaction process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Public-Debate-Challenge.xml b/static/bitcoin-dev/Oct_2015/combined_Public-Debate-Challenge.xml index 7b83df3342..ac89190cb9 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Public-Debate-Challenge.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Public-Debate-Challenge.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Public Debate Challenge - 2023-08-01T16:34:03.787672+00:00 + 2025-10-11T22:08:15.527264+00:00 + python-feedgen NotMike Hearn 2015-10-07 16:09:06+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Public Debate Challenge - 2023-08-01T16:34:03.787672+00:00 + 2025-10-11T22:08:15.527475+00:00 - On a Bitcoin development mailing list, Venzen Khaosan challenged Mike Hearn to a public debate about Bitcoin. However, Peter Todd disagreed with the off-topic discussion and stated that there was no consensus. He proposed two options to resolve the issue. In response, NMH questioned Peter's motives and challenged him to a public debate on Bitcoin with certain conditions. Peter's reply was dismissive, telling them to go away.Venzen Khaosan publicly challenged Mike Hearn to a debate on a Bitcoin development mailing list. However, Peter Todd deemed the email off-topic and inappropriate, telling Khaosan to "go away."The behavior of this disruptive individual is causing disturbance in the mentioned area, despite the efforts of others to maintain a positive environment. This person appears to lack basic moral standards and is acting irresponsibly. Such behavior is unacceptable and must be addressed promptly to prevent further disruption. It is important to recognize the negative impact such behavior can have on the community as a whole. The actions of one individual can affect the experiences of many others, leading to a decline in overall satisfaction and well-being.To create a safe and positive environment, it is necessary for individuals, institutions, and authorities to take responsibility and implement regulations and standards that ensure the protection and well-being of all members. By working together and taking collective action, a better world can be created for ourselves and future generations.In conclusion, it is regrettable that one individual is causing problems in the mentioned area. However, by recognizing the impact of such behavior and taking appropriate action, further damage can be prevented, and a healthier, happier community can be promoted. It is the responsibility of everyone to work together towards this goal and create a better world for all.Additionally, Venzen Khaosan has challenged Mike Hearn to a public debate on the topic of Bitcoin. The debate will consist of three sessions of five minutes each, with two-minute breaks in between. Each speaker is allowed to make one statement in each session that does not exceed two minutes. The event will take place in a public venue with an international audience and an arbiter will be agreed upon.To protect himself from Hearn's "official" friends, Khaosan plans to start the event when he appears on an event panel without prior announcement. He believes he has the debating resources to show Hearn as an intellectual lightweight if he participates. However, Paddy, another member of the Bitcoin development community, suggests keeping such public debates off-list, allowing the mailing list to focus solely on new developments in the community. 2015-10-07T16:09:06+00:00 + On a Bitcoin development mailing list, Venzen Khaosan challenged Mike Hearn to a public debate about Bitcoin. However, Peter Todd disagreed with the off-topic discussion and stated that there was no consensus. He proposed two options to resolve the issue. In response, NMH questioned Peter's motives and challenged him to a public debate on Bitcoin with certain conditions. Peter's reply was dismissive, telling them to go away.Venzen Khaosan publicly challenged Mike Hearn to a debate on a Bitcoin development mailing list. However, Peter Todd deemed the email off-topic and inappropriate, telling Khaosan to "go away."The behavior of this disruptive individual is causing disturbance in the mentioned area, despite the efforts of others to maintain a positive environment. This person appears to lack basic moral standards and is acting irresponsibly. Such behavior is unacceptable and must be addressed promptly to prevent further disruption. It is important to recognize the negative impact such behavior can have on the community as a whole. The actions of one individual can affect the experiences of many others, leading to a decline in overall satisfaction and well-being.To create a safe and positive environment, it is necessary for individuals, institutions, and authorities to take responsibility and implement regulations and standards that ensure the protection and well-being of all members. By working together and taking collective action, a better world can be created for ourselves and future generations.In conclusion, it is regrettable that one individual is causing problems in the mentioned area. However, by recognizing the impact of such behavior and taking appropriate action, further damage can be prevented, and a healthier, happier community can be promoted. It is the responsibility of everyone to work together towards this goal and create a better world for all.Additionally, Venzen Khaosan has challenged Mike Hearn to a public debate on the topic of Bitcoin. The debate will consist of three sessions of five minutes each, with two-minute breaks in between. Each speaker is allowed to make one statement in each session that does not exceed two minutes. The event will take place in a public venue with an international audience and an arbiter will be agreed upon.To protect himself from Hearn's "official" friends, Khaosan plans to start the event when he appears on an event panel without prior announcement. He believes he has the debating resources to show Hearn as an intellectual lightweight if he participates. However, Paddy, another member of the Bitcoin development community, suggests keeping such public debates off-list, allowing the mailing list to focus solely on new developments in the community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Reusable-payment-codes.xml b/static/bitcoin-dev/Oct_2015/combined_Reusable-payment-codes.xml index 37a84fa9a8..54ed863823 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Reusable-payment-codes.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Reusable-payment-codes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Reusable payment codes - 2023-08-01T12:16:22.615116+00:00 + 2025-10-11T22:08:09.153203+00:00 + python-feedgen Justus Ranvier 2015-10-23 15:57:14+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - Reusable payment codes - 2023-08-01T12:16:22.615116+00:00 + 2025-10-11T22:08:09.153445+00:00 - In October 2015, there was a discussion on the bitcoin-dev mailing list about Bitcoin Improvement Proposal (BIP) version 1. Luke Dashjr disagreed with adopting the proposal as is because multi-push OP_RETURN outputs were not standard transactions and could not be relied upon for network relay. He suggested waiting for additional capabilities to be deployed in the network before specifying a version 2 payment code. Justus Ranvier argued that version 1 payment codes were designed to be deployable without requiring network-level changes and acknowledged that multi-push OP_RETURN outputs would be standard in v0.12.0 of Bitcoin.Luke Dashjr expressed concerns about the "notification address" requirement in a proposal, as it would lead to address reuse and blockchain spam. He suggested using a single zero-value OP_RETURN output with two pushes instead. Justus Ranvier acknowledged that this portion of the proposal was not ideal but emphasized the goal of making the proposal usable on as many mobile/light wallets as possible. Dashjr argued that BIPs should not be designed around current software and that software upgrades are necessary regardless.There was also an email exchange regarding BIP 63, where Peter Todd expressed his inclination to shelve work on it due to other priorities. Several people offered to send donations to advance the BIP, but no donation address was posted. Todd suggested that someone else could take up the work if interested.Justus Ranvier shared an RFC on April 24, 2015, for a new type of Bitcoin address called a payment code. Payment codes are SPV-friendly alternatives to stealth addresses that positively identify senders to recipients and require less blockchain data storage. They can be publicly advertised without compromising financial privacy. Luke Dashjr expressed concerns about the "notification address" requirement in the proposal, suggesting an alternative approach using a single zero-value OP_RETURN output with two pushes.The concept of identity in relation to payment codes was discussed, with the understanding that it refers to a specific extended public/private key pair rather than conventional personal information. The discussion also touched on privacy concerns in SPV clients and suggested measures such as connecting exclusively through Tor and using varying bloom filters to enhance privacy.Brian Deery expressed worries about payment codes, particularly regarding the explicit tying of identities to them and the potential for identity linkage in bloom filter clients. There were suggestions for improving privacy in SPV clients by using multiple peers, filtering subsets of addresses, and varying the addresses being monitored.One of the main challenges with payment codes is that they rely on making dust payments to a constantly reused address, which undermines the privacy it aims to provide. This method also doubles the data sent for one-time anonymous donations. To address these issues, Brian suggests some ideas such as using even or odd DER encoding to save bytes and deriving the chain value from the x value to save more bytes. Another suggestion is to encode the "x value" into the signature's R value to make the transaction appear like a standard bitcoin transaction and eliminate the need for op_return.In terms of privacy, Brian proposes the concept of a common meeting point where the receiver of the payment code would trial-decode all payment codes sent to a pre-specified dead drop address, such as a charity address. This would require more effort from the receiver but would provide privacy regarding the number of people interacting with them.The proposed payment code scheme establishes a shared chain once and does not require reestablishment, improving upon the stealth address proposal. However, there is no solution presented for scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses.Overall, payment codes offer SPV-friendly alternatives to stealth addresses with features like sender identification and automatic transaction refunds. They require less blockchain data storage compared to stealth addresses but face challenges in terms of privacy and data efficiency. The provided link contains an RFC detailing the payment code proposal. 2015-10-23T15:57:14+00:00 + In October 2015, there was a discussion on the bitcoin-dev mailing list about Bitcoin Improvement Proposal (BIP) version 1. Luke Dashjr disagreed with adopting the proposal as is because multi-push OP_RETURN outputs were not standard transactions and could not be relied upon for network relay. He suggested waiting for additional capabilities to be deployed in the network before specifying a version 2 payment code. Justus Ranvier argued that version 1 payment codes were designed to be deployable without requiring network-level changes and acknowledged that multi-push OP_RETURN outputs would be standard in v0.12.0 of Bitcoin.Luke Dashjr expressed concerns about the "notification address" requirement in a proposal, as it would lead to address reuse and blockchain spam. He suggested using a single zero-value OP_RETURN output with two pushes instead. Justus Ranvier acknowledged that this portion of the proposal was not ideal but emphasized the goal of making the proposal usable on as many mobile/light wallets as possible. Dashjr argued that BIPs should not be designed around current software and that software upgrades are necessary regardless.There was also an email exchange regarding BIP 63, where Peter Todd expressed his inclination to shelve work on it due to other priorities. Several people offered to send donations to advance the BIP, but no donation address was posted. Todd suggested that someone else could take up the work if interested.Justus Ranvier shared an RFC on April 24, 2015, for a new type of Bitcoin address called a payment code. Payment codes are SPV-friendly alternatives to stealth addresses that positively identify senders to recipients and require less blockchain data storage. They can be publicly advertised without compromising financial privacy. Luke Dashjr expressed concerns about the "notification address" requirement in the proposal, suggesting an alternative approach using a single zero-value OP_RETURN output with two pushes.The concept of identity in relation to payment codes was discussed, with the understanding that it refers to a specific extended public/private key pair rather than conventional personal information. The discussion also touched on privacy concerns in SPV clients and suggested measures such as connecting exclusively through Tor and using varying bloom filters to enhance privacy.Brian Deery expressed worries about payment codes, particularly regarding the explicit tying of identities to them and the potential for identity linkage in bloom filter clients. There were suggestions for improving privacy in SPV clients by using multiple peers, filtering subsets of addresses, and varying the addresses being monitored.One of the main challenges with payment codes is that they rely on making dust payments to a constantly reused address, which undermines the privacy it aims to provide. This method also doubles the data sent for one-time anonymous donations. To address these issues, Brian suggests some ideas such as using even or odd DER encoding to save bytes and deriving the chain value from the x value to save more bytes. Another suggestion is to encode the "x value" into the signature's R value to make the transaction appear like a standard bitcoin transaction and eliminate the need for op_return.In terms of privacy, Brian proposes the concept of a common meeting point where the receiver of the payment code would trial-decode all payment codes sent to a pre-specified dead drop address, such as a charity address. This would require more effort from the receiver but would provide privacy regarding the number of people interacting with them.The proposed payment code scheme establishes a shared chain once and does not require reestablishment, improving upon the stealth address proposal. However, there is no solution presented for scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses.Overall, payment codes offer SPV-friendly alternatives to stealth addresses with features like sender identification and automatic transaction refunds. They require less blockchain data storage compared to stealth addresses but face challenges in terms of privacy and data efficiency. The provided link contains an RFC detailing the payment code proposal. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_The-new-obfuscation-patch-GetStats.xml b/static/bitcoin-dev/Oct_2015/combined_The-new-obfuscation-patch-GetStats.xml index 171868eedb..09c1ac640c 100644 --- a/static/bitcoin-dev/Oct_2015/combined_The-new-obfuscation-patch-GetStats.xml +++ b/static/bitcoin-dev/Oct_2015/combined_The-new-obfuscation-patch-GetStats.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - The new obfuscation patch & GetStats - 2023-08-01T16:34:18.258525+00:00 + 2025-10-11T22:08:58.017610+00:00 + python-feedgen Daniel Kraft 2015-10-08 05:14:50+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - The new obfuscation patch & GetStats - 2023-08-01T16:34:18.258525+00:00 + 2025-10-11T22:08:58.017756+00:00 - James O'Beirne has confirmed a bug in the recently merged "obfuscation" patch for Bitcoin's CLevelDBWrapper. The bug involves obfuscating the content of the "chainstate" LevelDB by XOR'ing it against a random key. While CLevelDBWrapper's Read/Write methods handle most use cases, there is a question regarding whether iterating over the database should also be handled. In particular, it has been suggested that the obfuscation key should be applied during iteration in CCoinsViewDB::GetStats. James has filed a fix for the issue on GitHub at https://github.com/bitcoin/bitcoin/pull/6777. To prevent any future regressions, James will also be writing tests. Daniel, who reported the bug, expressed gratitude for the quick fix and had planned to submit a patch if the issue turned out to be an oversight. It is worth noting that Daniel's signature block includes links to his website, OpenPGP key, and Namecoin ID.The author of a message is seeking clarification about the recently merged "obfuscation" patch for Bitcoin's CLevelDBWrapper. The patch obfuscates the "chainstate" LevelDB by XOR'ing it with a random key. The author wonders if the obfuscation should also be applied during iteration over the database. Specifically, they question whether the obfuscation key should be applied before line 119 in txdb.cpp during iteration in CCoinsViewDB::GetStats. They are unsure if this was an oversight or if there is a specific reason why the obfuscation key does not need to be applied during iteration. The author is reaching out to the community for help before opening a Github ticket. 2015-10-08T05:14:50+00:00 + James O'Beirne has confirmed a bug in the recently merged "obfuscation" patch for Bitcoin's CLevelDBWrapper. The bug involves obfuscating the content of the "chainstate" LevelDB by XOR'ing it against a random key. While CLevelDBWrapper's Read/Write methods handle most use cases, there is a question regarding whether iterating over the database should also be handled. In particular, it has been suggested that the obfuscation key should be applied during iteration in CCoinsViewDB::GetStats. James has filed a fix for the issue on GitHub at https://github.com/bitcoin/bitcoin/pull/6777. To prevent any future regressions, James will also be writing tests. Daniel, who reported the bug, expressed gratitude for the quick fix and had planned to submit a patch if the issue turned out to be an oversight. It is worth noting that Daniel's signature block includes links to his website, OpenPGP key, and Namecoin ID.The author of a message is seeking clarification about the recently merged "obfuscation" patch for Bitcoin's CLevelDBWrapper. The patch obfuscates the "chainstate" LevelDB by XOR'ing it with a random key. The author wonders if the obfuscation should also be applied during iteration over the database. Specifically, they question whether the obfuscation key should be applied before line 119 in txdb.cpp during iteration in CCoinsViewDB::GetStats. They are unsure if this was an oversight or if there is a specific reason why the obfuscation key does not need to be applied during iteration. The author is reaching out to the community for help before opening a Github ticket. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_This-thread-is-not-about-the-soft-hard-fork-technical-debate.xml b/static/bitcoin-dev/Oct_2015/combined_This-thread-is-not-about-the-soft-hard-fork-technical-debate.xml index 68e9cffd8d..f4e942c1d1 100644 --- a/static/bitcoin-dev/Oct_2015/combined_This-thread-is-not-about-the-soft-hard-fork-technical-debate.xml +++ b/static/bitcoin-dev/Oct_2015/combined_This-thread-is-not-about-the-soft-hard-fork-technical-debate.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - This thread is not about the soft/hard fork technical debate - 2023-08-01T16:33:13.088651+00:00 + 2025-10-11T22:08:11.278751+00:00 + python-feedgen Sergio Demian Lerner 2015-10-07 00:04:53+00:00 @@ -231,13 +232,13 @@ - python-feedgen + 2 Combined summary - This thread is not about the soft/hard fork technical debate - 2023-08-01T16:33:13.091653+00:00 + 2025-10-11T22:08:11.278955+00:00 - In an email conversation on the bitcoin-dev mailing list, Sergio denies using any four-letter words on IRC and questions the trustworthiness of IRC IDs. He requests Venzen to provide a link where an impostor said something to him in Sergio's name. Sergio expresses skepticism towards the characters mentioned in the email and considers them just regular people.The email conversation between Milly Bitcoin and Russ discusses the copyright notice of Bitcoin's code. Milly argues that the "copyright notice refers to the fact that each contributor owns copyright to his own contributions." However, Russ disagrees and explains that the legal owner is identified by the "c" in a circle (©). He cites Nolo and USPTO sources to support his argument. The conversation does not provide much detail on Bitcoin itself, rather it focuses on the copyright notice of Bitcoin's code and how it should be correctly displayed.On the bitcoin-dev mailing list, a proposal was made to implement dual modes in Bitcoin Improvement Proposal (BIP) 65. Some users support BIP 65, while others do not. The proposal suggests that both versions can run alongside each other and users can switch back and forth between them. However, additional constraints on transaction validation will be imposed to ensure that transactions made in a specific way will always look valid to non-CheckLockTimeVerify (CLTV) users but will require CLTV rules to be followed by CLTV users. SPV clients can choose to only connect to nodes which are non-CLTV. The discussion turned tense when some users resorted to name-calling, but eventually the proposal to implement dual modes was presented as a solution to the debate and the mailing list ended on a harmonious note.A new member of the bitcoin-dev community is reading through threads to educate themselves on the group ethos and etiquette. They found it difficult to understand some of the conversations, which may be intentional to maintain exclusivity. The new member wants to contribute their knowledge to the hardfork debate but is unsure if there is a more appropriate place to do so.Meanwhile, Mike Hearn supports a hard fork instead of a soft fork in regards to CLTV deployment. He believes hard forks are cleaner and have other desirable properties, while soft forks pose real financial risks. Despite controversy surrounding the consensus rules, Hearn predicts that Core maintainers will ignore it and do CLTV as a soft fork anyway.Venzen Khaosan challenges Mike Hearn to a public debate in Hong Kong. He accuses Hearn of being "too stupid" to handle client funds and the innovation behind Bitcoin, and promises to dismantle his "intellectual bankruptcy" in front of the world. Hearn had been raising objections to the implementation of CheckLockTimeVerify (CLTV) as a soft fork and argued that it should be implemented as a hard fork instead. Venzen Khaosan offers to debate an unnamed "eloquent guy" in the bitcoin community, stating that he will remove the person from their high horse and close their voice in Bitcoin for good. He mentions that he will go for the psychological throat first.The message is a response to Sergio Demian Lerner's post on Bitcoin-dev mailing list. The author accuses Lerner, along with Gavin Andresen and Mike Hearn, of breaching consensus in the community. The author criticizes Lerner for not having an issue with Hearn's actions and suggests that this speaks poorly of him. The author also criticizes Hearn's bitcoinj code and accuses him of harming the public while working for the NSA. The author concludes by suggesting that Lerner should not speak for someone else and should instead speak for himself.The debate on whether or not to implement BIP65 in Bitcoin has caused discord among community members. However, a solution has been proposed that can satisfy both sides. By imposing additional constraints on transaction validation, transactions made in a specific way will always look valid to non-CLTVers but will not be valid for CLTVers unless the CLTV rules are followed. This way, both versions can run alongside each other and people can switch back and forth between them. SPV clients can choose to connect only to nodes that are non-CLTV. Some people have expressed disappointment and frustration with the childish behavior and name-calling in the discussion.In an email thread on the bitcoin-dev mailing list, Steven Pine accused Mike of being a "concern troll" and a bully. Milly Bitcoin criticized the use of the term "troll" as unprofessional and suggested using the word "cultist" instead. The term "concern troll" is often used to describe someone who pretends to be concerned about an issue to disrupt a conversation. Meanwhile, "troll" is a term often used to describe someone who deliberately posts inflammatory comments online. The conversation continued on the mailing list.In a discussion on the bitcoin-dev mailing list, there was confusion over the terminology related to Bitcoin's Core developers. Luke Dashjr 2015-10-07T00:04:53+00:00 + In an email conversation on the bitcoin-dev mailing list, Sergio denies using any four-letter words on IRC and questions the trustworthiness of IRC IDs. He requests Venzen to provide a link where an impostor said something to him in Sergio's name. Sergio expresses skepticism towards the characters mentioned in the email and considers them just regular people.The email conversation between Milly Bitcoin and Russ discusses the copyright notice of Bitcoin's code. Milly argues that the "copyright notice refers to the fact that each contributor owns copyright to his own contributions." However, Russ disagrees and explains that the legal owner is identified by the "c" in a circle (©). He cites Nolo and USPTO sources to support his argument. The conversation does not provide much detail on Bitcoin itself, rather it focuses on the copyright notice of Bitcoin's code and how it should be correctly displayed.On the bitcoin-dev mailing list, a proposal was made to implement dual modes in Bitcoin Improvement Proposal (BIP) 65. Some users support BIP 65, while others do not. The proposal suggests that both versions can run alongside each other and users can switch back and forth between them. However, additional constraints on transaction validation will be imposed to ensure that transactions made in a specific way will always look valid to non-CheckLockTimeVerify (CLTV) users but will require CLTV rules to be followed by CLTV users. SPV clients can choose to only connect to nodes which are non-CLTV. The discussion turned tense when some users resorted to name-calling, but eventually the proposal to implement dual modes was presented as a solution to the debate and the mailing list ended on a harmonious note.A new member of the bitcoin-dev community is reading through threads to educate themselves on the group ethos and etiquette. They found it difficult to understand some of the conversations, which may be intentional to maintain exclusivity. The new member wants to contribute their knowledge to the hardfork debate but is unsure if there is a more appropriate place to do so.Meanwhile, Mike Hearn supports a hard fork instead of a soft fork in regards to CLTV deployment. He believes hard forks are cleaner and have other desirable properties, while soft forks pose real financial risks. Despite controversy surrounding the consensus rules, Hearn predicts that Core maintainers will ignore it and do CLTV as a soft fork anyway.Venzen Khaosan challenges Mike Hearn to a public debate in Hong Kong. He accuses Hearn of being "too stupid" to handle client funds and the innovation behind Bitcoin, and promises to dismantle his "intellectual bankruptcy" in front of the world. Hearn had been raising objections to the implementation of CheckLockTimeVerify (CLTV) as a soft fork and argued that it should be implemented as a hard fork instead. Venzen Khaosan offers to debate an unnamed "eloquent guy" in the bitcoin community, stating that he will remove the person from their high horse and close their voice in Bitcoin for good. He mentions that he will go for the psychological throat first.The message is a response to Sergio Demian Lerner's post on Bitcoin-dev mailing list. The author accuses Lerner, along with Gavin Andresen and Mike Hearn, of breaching consensus in the community. The author criticizes Lerner for not having an issue with Hearn's actions and suggests that this speaks poorly of him. The author also criticizes Hearn's bitcoinj code and accuses him of harming the public while working for the NSA. The author concludes by suggesting that Lerner should not speak for someone else and should instead speak for himself.The debate on whether or not to implement BIP65 in Bitcoin has caused discord among community members. However, a solution has been proposed that can satisfy both sides. By imposing additional constraints on transaction validation, transactions made in a specific way will always look valid to non-CLTVers but will not be valid for CLTVers unless the CLTV rules are followed. This way, both versions can run alongside each other and people can switch back and forth between them. SPV clients can choose to connect only to nodes that are non-CLTV. Some people have expressed disappointment and frustration with the childish behavior and name-calling in the discussion.In an email thread on the bitcoin-dev mailing list, Steven Pine accused Mike of being a "concern troll" and a bully. Milly Bitcoin criticized the use of the term "troll" as unprofessional and suggested using the word "cultist" instead. The term "concern troll" is often used to describe someone who pretends to be concerned about an issue to disrupt a conversation. Meanwhile, "troll" is a term often used to describe someone who deliberately posts inflammatory comments online. The conversation continued on the mailing list.In a discussion on the bitcoin-dev mailing list, there was confusion over the terminology related to Bitcoin's Core developers. Luke Dashjr - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Versionbits-BIP-009-minor-revision-proposal-.xml b/static/bitcoin-dev/Oct_2015/combined_Versionbits-BIP-009-minor-revision-proposal-.xml index 8fef6e9112..0ad0f36c24 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Versionbits-BIP-009-minor-revision-proposal-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Versionbits-BIP-009-minor-revision-proposal-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Versionbits BIP (009) minor revision proposal. - 2023-08-01T16:26:12.381254+00:00 + 2025-10-11T22:08:43.151101+00:00 + python-feedgen Rusty Russell 2015-10-02 01:22:14+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Versionbits BIP (009) minor revision proposal. - 2023-08-01T16:26:12.381254+00:00 + 2025-10-11T22:08:43.151286+00:00 - Gregory Maxwell and Rusty Russell had a discussion about the possibility of requiring a bit to be set during the soft fork activation period. This would allow thin clients to reject blocks from non-upgraded miners. However, they decided against this proposal as it would cause warnings on older clients. Instead, they focused on upgrading versionbits and opened a PullReq for the "keep setting bit until activation" proposal.The conversation also explored the idea of making a BIP deployment optional but recommended for the first time. This would help collect valuable data to identify faulty implementations and bugs. It was suggested that a more sophisticated signaling mechanism could be introduced in the future to provide informative messages to end-users regarding changes and direct them to resources for learning about new features.There was a suggestion to require setting the bit for a period of time after rule enforcement begins, without actually enforcing the bit. This would allow thin clients to approach these blocks with skepticism. However, implementing this later would trigger warnings on older clients who would see the bit as representing a new soft fork. The simplest solution proposed was to have miners continue setting the bit for another 2016 blocks, which could potentially become a consensus rule if necessary.Gregory Maxwell argued that the bit can be easily checked by thin clients to reject blocks from non-upgraded miners post-switch. A middle ground solution was proposed to require setting the bit for a period of time after rule enforcement begins, but only enforce the validity of the block under new rules. However, this would add another state and trigger warnings on older clients if implemented later. Miners would need to keep setting the bit for another 2016 blocks to implement this solution, which could become a consensus rule if needed. Rusty concluded the discussion with a humorous quote.The context also discusses the challenge of determining whether miners are enforcing new rules without relying on someone mining a block that breaks the rule. Hard forks come with greater risks and disruptions, so the author suggests that an awareness campaign can help address concerns about older clients. The Version Bits mechanism is not a 'voting' system but a deployment mechanism for uncontroversial changes, measuring adoption before activation. It is most useful for adding default settings in product releases. The author emphasizes the importance of smooth transitions and acknowledges the reality that explicit acknowledgment of enforcement may not be possible.Rusty Russell raised the issue that the current BIP has miners turning off the bit as soon as it's locked in, making network adoption less visible. He suggested that miners should keep setting the bit for another 2016 blocks after activation and have a consensus rule that rejects blocks without the bit. This would "force" upgrades on the last remaining miners. However, this immediate bit forcing was seen as an advantage of versionbits over prior work.In another discussion, Pieter and Eric noted that miners turn off the bit as soon as it's locked in, which reduces network adoption visibility. Rusty did not propose an alternative suggestion but mentioned that miners should keep setting the bit for 2016 blocks after activation. If this idea proves successful, they can proceed with it. According to BIP-0009, software should begin by setting the bit in all mined blocks until it is resolved. If the bit is set in 1916 or more of the 2016 blocks within a retarget period, it becomes 'locked-in,' and miners should continue setting the bit for visibility. The consensus rules related to the locked-in soft fork will be enforced in the second retarget period, allowing the remaining 5% to upgrade. At the activation block and after, miners should stop setting the bit, which can potentially be reused for a different soft fork. 2015-10-02T01:22:14+00:00 + Gregory Maxwell and Rusty Russell had a discussion about the possibility of requiring a bit to be set during the soft fork activation period. This would allow thin clients to reject blocks from non-upgraded miners. However, they decided against this proposal as it would cause warnings on older clients. Instead, they focused on upgrading versionbits and opened a PullReq for the "keep setting bit until activation" proposal.The conversation also explored the idea of making a BIP deployment optional but recommended for the first time. This would help collect valuable data to identify faulty implementations and bugs. It was suggested that a more sophisticated signaling mechanism could be introduced in the future to provide informative messages to end-users regarding changes and direct them to resources for learning about new features.There was a suggestion to require setting the bit for a period of time after rule enforcement begins, without actually enforcing the bit. This would allow thin clients to approach these blocks with skepticism. However, implementing this later would trigger warnings on older clients who would see the bit as representing a new soft fork. The simplest solution proposed was to have miners continue setting the bit for another 2016 blocks, which could potentially become a consensus rule if necessary.Gregory Maxwell argued that the bit can be easily checked by thin clients to reject blocks from non-upgraded miners post-switch. A middle ground solution was proposed to require setting the bit for a period of time after rule enforcement begins, but only enforce the validity of the block under new rules. However, this would add another state and trigger warnings on older clients if implemented later. Miners would need to keep setting the bit for another 2016 blocks to implement this solution, which could become a consensus rule if needed. Rusty concluded the discussion with a humorous quote.The context also discusses the challenge of determining whether miners are enforcing new rules without relying on someone mining a block that breaks the rule. Hard forks come with greater risks and disruptions, so the author suggests that an awareness campaign can help address concerns about older clients. The Version Bits mechanism is not a 'voting' system but a deployment mechanism for uncontroversial changes, measuring adoption before activation. It is most useful for adding default settings in product releases. The author emphasizes the importance of smooth transitions and acknowledges the reality that explicit acknowledgment of enforcement may not be possible.Rusty Russell raised the issue that the current BIP has miners turning off the bit as soon as it's locked in, making network adoption less visible. He suggested that miners should keep setting the bit for another 2016 blocks after activation and have a consensus rule that rejects blocks without the bit. This would "force" upgrades on the last remaining miners. However, this immediate bit forcing was seen as an advantage of versionbits over prior work.In another discussion, Pieter and Eric noted that miners turn off the bit as soon as it's locked in, which reduces network adoption visibility. Rusty did not propose an alternative suggestion but mentioned that miners should keep setting the bit for 2016 blocks after activation. If this idea proves successful, they can proceed with it. According to BIP-0009, software should begin by setting the bit in all mined blocks until it is resolved. If the bit is set in 1916 or more of the 2016 blocks within a retarget period, it becomes 'locked-in,' and miners should continue setting the bit for visibility. The consensus rules related to the locked-in soft fork will be enforced in the second retarget period, allowing the remaining 5% to upgrade. At the activation block and after, miners should stop setting the bit, which can potentially be reused for a different soft fork. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_Why-not-checkpointing-the-transactions-.xml b/static/bitcoin-dev/Oct_2015/combined_Why-not-checkpointing-the-transactions-.xml index a0c2f6a9c8..26db91ad4d 100644 --- a/static/bitcoin-dev/Oct_2015/combined_Why-not-checkpointing-the-transactions-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_Why-not-checkpointing-the-transactions-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Why not checkpointing the transactions? - 2023-08-01T16:34:54.556447+00:00 + 2025-10-11T22:08:02.778217+00:00 + python-feedgen jl2012 at xbt.hk 2015-10-09 04:16:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Why not checkpointing the transactions? - 2023-08-01T16:34:54.556447+00:00 + 2025-10-11T22:08:02.778431+00:00 - A developer has raised a question on the Bitcoin mailing list about the need for the network to retain every transaction since its inception. The developer suggests that instead of starting from scratch with each transaction, nodes could rely on a small working "transaction log". This would enable companies to use transactional information from devices like PDAs or relay information to satellites without having to store every historical transaction indefinitely.Responders to the query have pointed out that in a trustless system like Bitcoin, all transactions need to be confirmed by the entire blockchain to ensure their validity. However, they clarify that downloading the entire blockchain does not necessarily mean it has to be stored entirely. They propose the implementation of Simplified Payment Verification (SPV), which would allow users to validate and download only the portions of the blockchain that they are interested in.In a separate discussion, an experienced database engineer is curious about the inner workings of Bitcoin's architecture, specifically regarding its transaction structure. The engineer notes that bitshares 2.0, a cryptocurrency platform, is adopting a transaction structure similar to relational database management systems (RDBMS) that have been using this method for over three decades.The engineer questions why the Bitcoin network replays every single transaction from the beginning and stores that information on each core node. They suggest that it would be more efficient to maintain a checkpointed state and only store new transactions. The engineer proposes that the responsibility of backing up historical transactions could be left to "historical" nodes or collectors, allowing the network to operate with greater efficiency and speed. By reducing the transactional workload and discarding the burden of previous transactions, the engineer believes Bitcoin could become a highly decentralized system that is resistant to disruptions.Furthermore, the engineer suggests that integrating a small ODBC (Open Database Connectivity) or JDBC (Java Database Connectivity) connector on the Bitcoin client could enable traditional RDBMS systems to handle the heavy load. This would allow the Bitcoin core to rely on everyone at a level that would be difficult for anyone to disrupt, thanks to the limited amount of transactional data being processed.The engineer concludes by acknowledging that these are just initial thoughts and emphasizes their commitment to researching the Bitcoin code further. 2015-10-09T04:16:50+00:00 + A developer has raised a question on the Bitcoin mailing list about the need for the network to retain every transaction since its inception. The developer suggests that instead of starting from scratch with each transaction, nodes could rely on a small working "transaction log". This would enable companies to use transactional information from devices like PDAs or relay information to satellites without having to store every historical transaction indefinitely.Responders to the query have pointed out that in a trustless system like Bitcoin, all transactions need to be confirmed by the entire blockchain to ensure their validity. However, they clarify that downloading the entire blockchain does not necessarily mean it has to be stored entirely. They propose the implementation of Simplified Payment Verification (SPV), which would allow users to validate and download only the portions of the blockchain that they are interested in.In a separate discussion, an experienced database engineer is curious about the inner workings of Bitcoin's architecture, specifically regarding its transaction structure. The engineer notes that bitshares 2.0, a cryptocurrency platform, is adopting a transaction structure similar to relational database management systems (RDBMS) that have been using this method for over three decades.The engineer questions why the Bitcoin network replays every single transaction from the beginning and stores that information on each core node. They suggest that it would be more efficient to maintain a checkpointed state and only store new transactions. The engineer proposes that the responsibility of backing up historical transactions could be left to "historical" nodes or collectors, allowing the network to operate with greater efficiency and speed. By reducing the transactional workload and discarding the burden of previous transactions, the engineer believes Bitcoin could become a highly decentralized system that is resistant to disruptions.Furthermore, the engineer suggests that integrating a small ODBC (Open Database Connectivity) or JDBC (Java Database Connectivity) connector on the Bitcoin client could enable traditional RDBMS systems to handle the heavy load. This would allow the Bitcoin core to rely on everyone at a level that would be difficult for anyone to disrupt, thanks to the limited amount of transactional data being processed.The engineer concludes by acknowledging that these are just initial thoughts and emphasizes their commitment to researching the Bitcoin code further. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_extension-blocks-sidechains-fractional-coin-cap-demurrage-Re-Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml b/static/bitcoin-dev/Oct_2015/combined_extension-blocks-sidechains-fractional-coin-cap-demurrage-Re-Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml index 082dd5d5d6..75019faeca 100644 --- a/static/bitcoin-dev/Oct_2015/combined_extension-blocks-sidechains-fractional-coin-cap-demurrage-Re-Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml +++ b/static/bitcoin-dev/Oct_2015/combined_extension-blocks-sidechains-fractional-coin-cap-demurrage-Re-Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - extension-blocks/sidechains & fractional/coin-cap/demurrage (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!) - 2023-08-01T16:33:41.954898+00:00 + 2025-10-11T22:08:49.524737+00:00 + python-feedgen Venzen Khaosan 2015-10-07 10:13:15+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - extension-blocks/sidechains & fractional/coin-cap/demurrage (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!) - 2023-08-01T16:33:41.954898+00:00 + 2025-10-11T22:08:49.524862+00:00 - The email thread also discusses the potential implications of extension blocks on the Bitcoin price and market. It is suggested that in a fee market crunch, speculators would trade an extended block in one direction while hedging in the opposite direction in case it gets rejected. This could create a new chart pattern and contrarian price motion. The speculative public may initially trade in the same direction, but arbitrage and futures markets perspectives would go the opposite way.Additionally, it is predicted that as the community's illusion of non-interdependence fades, the Bitcoin price will tend towards parity with the US dollar, which is considered the most powerful fiat currency. The inverse correlation between Bitcoin and traditional currencies may strengthen as the majority world transitions from paper to digital currencies.However, there are concerns raised about the current deflationary environment and the behavior of buying coffee with XT bitcoins. It is argued that this is small-minded behavior and that Bitcoin should be seen as a store of value rather than a means of everyday transactions. In this context, Mike Hearn is criticized as an economic imbecile and it is suggested that he should be removed from the Bitcoin space.Overall, the discussion explores the possibility of soft-fork increases in the total number of Bitcoins through extension blocks or sidechains. It provides insights into the potential consequences for users, the Bitcoin market, and the future value of the cryptocurrency. 2015-10-07T10:13:15+00:00 + The email thread also discusses the potential implications of extension blocks on the Bitcoin price and market. It is suggested that in a fee market crunch, speculators would trade an extended block in one direction while hedging in the opposite direction in case it gets rejected. This could create a new chart pattern and contrarian price motion. The speculative public may initially trade in the same direction, but arbitrage and futures markets perspectives would go the opposite way.Additionally, it is predicted that as the community's illusion of non-interdependence fades, the Bitcoin price will tend towards parity with the US dollar, which is considered the most powerful fiat currency. The inverse correlation between Bitcoin and traditional currencies may strengthen as the majority world transitions from paper to digital currencies.However, there are concerns raised about the current deflationary environment and the behavior of buying coffee with XT bitcoins. It is argued that this is small-minded behavior and that Bitcoin should be seen as a store of value rather than a means of everyday transactions. In this context, Mike Hearn is criticized as an economic imbecile and it is suggested that he should be removed from the Bitcoin space.Overall, the discussion explores the possibility of soft-fork increases in the total number of Bitcoins through extension blocks or sidechains. It provides insights into the potential consequences for users, the Bitcoin market, and the future value of the cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_merged-multisig-inputs.xml b/static/bitcoin-dev/Oct_2015/combined_merged-multisig-inputs.xml index 73bea83f2a..cd5d4a2bb5 100644 --- a/static/bitcoin-dev/Oct_2015/combined_merged-multisig-inputs.xml +++ b/static/bitcoin-dev/Oct_2015/combined_merged-multisig-inputs.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - merged multisig inputs - 2023-08-01T16:34:31.602318+00:00 + 2025-10-11T22:08:47.400124+00:00 + python-feedgen Gregory Maxwell 2015-10-08 20:03:49+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - merged multisig inputs - 2023-08-01T16:34:31.602318+00:00 + 2025-10-11T22:08:47.400297+00:00 - In October 2015, Boris Neklabaro inquired about the possibility of merging two Unspent Transaction Outputs (UTXOs) and spending from multiple Pay-to-Script-Hash (P2SH) inputs. He also asked if it was feasible to combine inputs from P2SH and Pay-to-Public-Key-Hash (P2PKH) in a single transaction. The response to these queries affirmed that it is indeed possible.To understand this, one must delve into the technical aspects of Bitcoin transactions. A UTXO refers to an output from a previous transaction that has not been spent as input for another transaction. In order to merge two UTXOs, both outputs must be owned by the same address. On the other hand, spending from multiple P2SH inputs is feasible because P2SH allows for the use of more complex scripts as locking conditions for transactions. Consequently, it is possible to have multiple P2SH inputs controlled by the same address.Likewise, combining inputs from P2SH and P2PKH in a single transaction is also possible. P2PKH involves sending funds directly to a public key hash and is a simpler form of Bitcoin transaction. Although it may appear less secure than P2SH, it remains a valid transaction method.Therefore, while merging UTXOs necessitates ownership of both outputs by the same address, spending from multiple P2SH inputs and combining inputs from P2SH and P2PKH in a single transaction are both feasible within the technical framework of Bitcoin transactions. 2015-10-08T20:03:49+00:00 + In October 2015, Boris Neklabaro inquired about the possibility of merging two Unspent Transaction Outputs (UTXOs) and spending from multiple Pay-to-Script-Hash (P2SH) inputs. He also asked if it was feasible to combine inputs from P2SH and Pay-to-Public-Key-Hash (P2PKH) in a single transaction. The response to these queries affirmed that it is indeed possible.To understand this, one must delve into the technical aspects of Bitcoin transactions. A UTXO refers to an output from a previous transaction that has not been spent as input for another transaction. In order to merge two UTXOs, both outputs must be owned by the same address. On the other hand, spending from multiple P2SH inputs is feasible because P2SH allows for the use of more complex scripts as locking conditions for transactions. Consequently, it is possible to have multiple P2SH inputs controlled by the same address.Likewise, combining inputs from P2SH and P2PKH in a single transaction is also possible. P2PKH involves sending funds directly to a public key hash and is a simpler form of Bitcoin transaction. Although it may appear less secure than P2SH, it remains a valid transaction method.Therefore, while merging UTXOs necessitates ownership of both outputs by the same address, spending from multiple P2SH inputs and combining inputs from P2SH and P2PKH in a single transaction are both feasible within the technical framework of Bitcoin transactions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2015/combined_on-rough-consensus.xml b/static/bitcoin-dev/Oct_2015/combined_on-rough-consensus.xml index a418db3e3d..912ad353e8 100644 --- a/static/bitcoin-dev/Oct_2015/combined_on-rough-consensus.xml +++ b/static/bitcoin-dev/Oct_2015/combined_on-rough-consensus.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - on rough consensus - 2023-08-01T16:33:29.422508+00:00 + 2025-10-11T22:09:08.653075+00:00 + python-feedgen Adam Back 2015-10-07 10:42:08+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - on rough consensus - 2023-08-01T16:33:29.422508+00:00 + 2025-10-11T22:09:08.653228+00:00 - Bitcoin participants can enhance their ability to remain on a valuable and censorship-resistant blockchain by embracing the concept of "rough consensus." This idea is rooted in the principles of the Internet Engineering Task Force (IETF), which emphasizes the rejection of hierarchical authority and decision-making through voting. Instead, rough consensus encourages open debate and the incorporation of feedback until objections are satisfactorily addressed.To achieve rough consensus within the IETF, objections are thoroughly debated, and strong objections are considered by the working group chair. The chair's role is to steer discussions towards productive interaction and determine when rough consensus has been reached. It is important to note that consensus does not require unanimous agreement or complete satisfaction with a chosen solution. Instead, it signifies that everyone is sufficiently content with the solution, having no specific objections against it.When someone objects to a proposal, it is crucial to inquire about the reasons behind their objection. Consensus is achieved when these objections are either addressed through appropriate changes or deemed insignificant. If this process fails, rough consensus can still be attained by ensuring that all issues are acknowledged, even if they are not fully accommodated. The working group chair must carefully evaluate the technical implications of not accommodating an objection and provide a reasoned explanation to the person raising the issue.Consensus-building without relying on voting prevents manipulation of the system and encourages the consideration of important minority views. The chair's focus should be on addressing outstanding technical objections rather than simply counting votes. Even if no one continues to advocate for a particular issue, it must not be disregarded. Rough consensus serves as a safeguard against making decisions with unforeseen long-term consequences.While Bitcoin Core is not an IETF working group, its developers can learn from the principles of rough consensus. By effectively communicating with the economic majority and ensuring clarity in their work, they can contribute to the functioning and improvement of the system. In conclusion, as Lao Tzu stated, defending with love provides security in the pursuit of rough consensus. For further insights into forming useful rough consensus, references such as "The Tao of the IETF" and RFC 7282 are recommended. 2015-10-07T10:42:08+00:00 + Bitcoin participants can enhance their ability to remain on a valuable and censorship-resistant blockchain by embracing the concept of "rough consensus." This idea is rooted in the principles of the Internet Engineering Task Force (IETF), which emphasizes the rejection of hierarchical authority and decision-making through voting. Instead, rough consensus encourages open debate and the incorporation of feedback until objections are satisfactorily addressed.To achieve rough consensus within the IETF, objections are thoroughly debated, and strong objections are considered by the working group chair. The chair's role is to steer discussions towards productive interaction and determine when rough consensus has been reached. It is important to note that consensus does not require unanimous agreement or complete satisfaction with a chosen solution. Instead, it signifies that everyone is sufficiently content with the solution, having no specific objections against it.When someone objects to a proposal, it is crucial to inquire about the reasons behind their objection. Consensus is achieved when these objections are either addressed through appropriate changes or deemed insignificant. If this process fails, rough consensus can still be attained by ensuring that all issues are acknowledged, even if they are not fully accommodated. The working group chair must carefully evaluate the technical implications of not accommodating an objection and provide a reasoned explanation to the person raising the issue.Consensus-building without relying on voting prevents manipulation of the system and encourages the consideration of important minority views. The chair's focus should be on addressing outstanding technical objections rather than simply counting votes. Even if no one continues to advocate for a particular issue, it must not be disregarded. Rough consensus serves as a safeguard against making decisions with unforeseen long-term consequences.While Bitcoin Core is not an IETF working group, its developers can learn from the principles of rough consensus. By effectively communicating with the economic majority and ensuring clarity in their work, they can contribute to the functioning and improvement of the system. In conclusion, as Lao Tzu stated, defending with love provides security in the pursuit of rough consensus. For further insights into forming useful rough consensus, references such as "The Tao of the IETF" and RFC 7282 are recommended. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Oct_2016/combined_-no-subject-.xml b/static/bitcoin-dev/Oct_2016/combined_-no-subject-.xml index 8dc8d2661d..e8621808a2 100644 --- a/static/bitcoin-dev/Oct_2016/combined_-no-subject-.xml +++ b/static/bitcoin-dev/Oct_2016/combined_-no-subject-.xml @@ -2,7 +2,7 @@ 2 Combined summary - (no subject) - 2025-09-26T16:01:41.821712+00:00 + 2025-10-11T22:15:05.812270+00:00 python-feedgen Btc Drak 2016-10-17 13:13:25+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - (no subject) - 2025-09-26T16:01:41.821881+00:00 + 2025-10-11T22:15:05.812451+00:00 2016-10-17T13:13:25+00:00 On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem. diff --git a/static/bitcoin-dev/Oct_2016/combined_1-Year-bitcoin-dev-Moderation-Review.xml b/static/bitcoin-dev/Oct_2016/combined_1-Year-bitcoin-dev-Moderation-Review.xml index 4380e67c2f..4b0ae01b28 100644 --- a/static/bitcoin-dev/Oct_2016/combined_1-Year-bitcoin-dev-Moderation-Review.xml +++ b/static/bitcoin-dev/Oct_2016/combined_1-Year-bitcoin-dev-Moderation-Review.xml @@ -2,7 +2,7 @@ 2 Combined summary - 1 Year bitcoin-dev Moderation Review - 2025-09-26T16:01:39.710917+00:00 + 2025-10-11T22:15:03.688948+00:00 python-feedgen Dave Scotese 2016-10-10 15:34:17+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - 1 Year bitcoin-dev Moderation Review - 2025-09-26T16:01:39.711075+00:00 + 2025-10-11T22:15:03.689087+00:00 2016-10-10T15:34:17+00:00 A member of the bitcoin-dev mailing list, Jeremy Rubin, has raised concerns about the moderation policy and its impact on the community. According to Rubin, since the implementation of moderation, there has been a noticeable decline in the number of messages posted daily, making the community less accessible. He suggests that people may be self-censoring out of fear of being moderated as trolling or spam, which is reducing the value of the list. Henning Kopp agrees with Rubin's assessment and emphasizes the need to keep non-development talk off the developer list. This discussion highlights the importance of communication channels in the development process and how excessive moderation can hinder communication and the exchange of ideas within a community.Jeremy, a member of the Bitcoin development team, questions whether the moderation on the bitcoin-dev mailing list is stifling discussion and diminishing the list's value. While recognizing the potential benefits of moderation, he argues that it may have gone too far, discouraging people from writing emails due to the fear of being moderated. Jeremy believes that the rate of moderated posts does not accurately reflect the "chilling effect" of moderation, which reduces email activity and limits valuable communication within the community. He suggests that the community should collectively address this issue in order to restore open communication.Another member of the community, Henning Kopp, agrees that non-development talk should be kept off the bitcoin-dev mailing list but proposes finding a way to revitalize the bitcoin-discuss list, which has not gained enough contributors. The suggestion is made that bitcoin-discuss should have an opt-out system instead of opt-in, raising questions about the subscription counts for both bitcoin-dev and bitcoin-discuss. The author of the message requests this information from the moderators, although their specific reason for wanting it is unclear. The choice between an opt-in and opt-out system can impact the number of subscribers to a group or mailing list.In summary, Jeremy Rubin initiates a discussion on the impact of moderation on the bitcoin-dev mailing list, expressing concerns about decreased email activity and self-censorship. He suggests reopening the communication channel while acknowledging the need to keep non-development talk separate. The suggestion of an opt-out system for the bitcoin-discuss list is also raised, raising questions about subscription counts for both lists. Overall, this discussion highlights the importance of effective communication channels and the potential consequences of excessive moderation within a community. diff --git a/static/bitcoin-dev/Oct_2016/combined_About-ASICBoost.xml b/static/bitcoin-dev/Oct_2016/combined_About-ASICBoost.xml index 87b5237e7b..6e45b5ad26 100644 --- a/static/bitcoin-dev/Oct_2016/combined_About-ASICBoost.xml +++ b/static/bitcoin-dev/Oct_2016/combined_About-ASICBoost.xml @@ -2,7 +2,7 @@ 2 Combined summary - About ASICBoost - 2025-09-26T16:01:35.484320+00:00 + 2025-10-11T22:14:59.441940+00:00 python-feedgen Gregory Maxwell 2016-10-02 23:27:20+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - About ASICBoost - 2025-09-26T16:01:35.484472+00:00 + 2025-10-11T22:14:59.442095+00:00 2016-10-02T23:27:20+00:00 In an email dated October 2, 2016, Bitcoin developer Matt Corallo expressed concerns about the Bitcoin Foundation's potential disregard for Bitcoin's future centralization. He criticized the idea of asking the foundation to pay a license fee to avoid holding the rest of the Bitcoin mining community hostage. Corallo also mentioned the lack of transparent licensing and transparency in public discussions after the patent had been filed. However, he acknowledged that they cannot change the past and instead suggested focusing on collaboration for the future.The Bitcoin Foundation's lack of transparency regarding licensing has come under fire after they failed to license a patent from Sergio Lerner. In 2013, Lerner reached out to the foundation asking if they would license his patent on fair terms. The foundation declined, stating that it did not believe the proprietary patent would be significant. The lack of transparent licensing has raised concerns about centralization pressure and the potential harm it could cause Bitcoin in the long-term. Matt Corallo has criticized the foundation for its handling of the situation, suggesting that their disregard for future centralization is worrying.In a message to the bitcoin-dev mailing list, Matt Corallo criticized anonymous miner "Satoshi Nakamoto" for not showing concern towards centralization pressure and its potential long-term harm to Bitcoin. However, it was revealed that Sergio had privately expressed concerns about centralization pressure and reached out to the BCF in 2013 to license his patent which would make its user(s) 30% more effective than others under "fair" terms. The BCF responded by encouraging him to seek the patent as they didn't think it would be a big deal.The Bitcoin community is concerned about unnecessary entanglements of consensus code with patents. Sergio Demian Lerner had proposed an extra nonce space BIP and had already applied for the ASICBOOST patent without disclosing it in the BIP nor in the Bitcoin Core pull request. The BIP proposal does not increase or decrease the entanglement of Bitcoin consensus code with any patents and AsicBoost is possible with or without adoption of that BIP proposal. The rationale behind the BIP proposal was to eliminate incentives to mess with the merkle root and, in the extreme case, to mine empty blocks. The concern is that this might be happening again as Lerner proposed a new sidechain BIP. It is great that Lerner has now committed to looking into the Defensive Patent License which seems likely to mitigate some of the patent concerns.In an email thread on the Bitcoin-dev mailing list, Sergio Demian Lerner asked Peter Todd to explain his views on a patent for hardware design for ASICs. Lerner notes that there are at least three similar patents filed by major Bitcoin ASIC manufacturers in three different countries. Todd responds that the comparison is misleading and he is not aware of any other patents on Bitcoin-specific ASIC technology which are practically enforceable or which the owners have indicated they wish to enforce. Of the two patents which Lerner pointed out which were filed on essentially the same optimization that ASICBoost covers, Todd says that Lerner's predates both of them, invalidating both the Spondoolies one and the AntMiner one. Todd claims that only Lerner's patent is practical and likely to be enforced in the vast majority of the world. Todd believes that optimizations to the hashing algorithm are not themselves "attacks" on Bitcoin. But only when they are used in a rent-seeking fashion to push for more centralization and lower miner revenue do they become so. One of the biggest advantages of SHA256 in the context of mining is exactly that it is a relatively simple algorithm, allowing for fewer large algorithmic optimizations. This opens the doors to more competition in the ASIC market than if only few people had the knowledge (or a patent) to build efficient ASICs. Todd claims that while the high-end ASIC-manufacturing industry is highly-centralized, making it worse by limiting those who can build Bitcoin ASICs from anyone with access to such a fab to only those who can, additionally, negotiate for patent rights and navigate the modern patent system, is far from ideal. Todd criticizes Lerner's proposal for a hard fork, with the only argument given as to why it should happen being that he thought there was an attack, but couldn't yet "really tell if they could affect Bitcoin". Instead of following up with more information, as he indicated he would, he went and patented the optimizations and has gone on rent-seeking behavior since. Todd concludes that if Lerner had acted in a way which indicated even the slightest regard for centralization pressure and the harm it can do to Bitcoin in the long-term, then he doesn't think many would be blaming him.The context is a discussion about the implementation of ASICBoost in Bitcoin, which was proposed as a way to improve mining efficiency. The author shares that they had shared their findings with some core developers prior to the BIP proposal, but it is unclear if they kept it secret or shared it with diff --git a/static/bitcoin-dev/Oct_2016/combined_BIP-2-revival-and-rework.xml b/static/bitcoin-dev/Oct_2016/combined_BIP-2-revival-and-rework.xml index f3774da54f..46869772a3 100644 --- a/static/bitcoin-dev/Oct_2016/combined_BIP-2-revival-and-rework.xml +++ b/static/bitcoin-dev/Oct_2016/combined_BIP-2-revival-and-rework.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 2 revival and rework - 2025-09-26T16:01:46.045239+00:00 + 2025-10-11T22:15:10.060528+00:00 python-feedgen Tom Zander 2016-10-16 14:56:36+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - BIP 2 revival and rework - 2025-09-26T16:01:46.045394+00:00 + 2025-10-11T22:15:10.060689+00:00 2016-10-16T14:56:36+00:00 In a discussion on whether work can be released under public domain and CC-BY-SA, Marco Falke and Tom Zander had differing views. Zander believed that it is not possible to dual-license something under both CC-BY-SA and public domain because all licenses are based on having copyright, whereas public domain means the lack of copyright. Zander preferred copyleft licenses for BIPs. Tom Zander suggested that BIPs should be licensed as public domain with a CC-BY option. It was pointed out that while BIP 1 requires public domain or OPL, it does not forbid other licenses. Similarly, BIP 2 allows for other acceptable licenses but does not recommend them. Despite the goal of no longer allowing public domain as the only copyright option, BIP 2 does not forbid releasing work under public domain in jurisdictions where it is recognized as legal. Many BIP authors have previously chosen public domain as the only option.On October 15, 2016, Tom Zander and Marco Falke discussed the licensing of BIPs. Zander had dual-licensed BIP 134 under OPL and CC-BY-SA for future acceptance of CC-BY-SA without needing permission from all authors to remove the OPL. Falke pointed out that BIP 2 does not allow public domain as the only copyright option, to which Zander responded that public domain was never the only option.In an email exchange between Tom Zander and Luke Dashjr, they discussed licensing options for BIPs. Zander suggested public domain (CC0) or a CC-BY option, while Dashjr added MIT/BSD licenses. Dashjr explained that BIP 1 only allows OPL and public domain, so BIP 2 can be available under OPL until it activates. Dashjr clarified that CC0 and public domain are different. Dashjr was asked to reach out to the community to ensure BIP 2 has been heard and discussed. France and Germany do not recognize public domain, while GPL is valid anywhere copyright laws exist.On October 15, 2016, a discussion took place on the Bitcoin development mailing list regarding the licensing of BIPs. Marco Falke suggested licensing BIPs under CC0 with a CC-BY option, while Tom Zander disagreed and suggested a requirement for "Share alike" and an optional "Attribution." It was argued that more restrictive licenses are not suitable for BIPs and that the BIP repository is not the place to promote open access. BIP 2 allows for such licenses but does not recommend them. Clarity around proposed changes and reasoning was encouraged. The discussion concluded with the suggestion to move forward with BIP 2 if there were no objections.In a conversation on the Bitcoin Development mailing list about licensing for BIPs, it was suggested that "Share alike" be required and "Attribution" be optional. However, it was pointed out that there is no Creative Commons license option that requires Share Alike and allows Attribution as an option. CC0, MIT/BSD, or CC-BY were proposed as suitable licenses for BIPs. The suitability of more restrictive licenses and promoting open access in the BIP repository were also discussed. BIP 2 allows for such licenses but does not recommend them. The email thread concluded with the suggestion to move forward with BIP 2 if there were no objections.Luke Dashjr announced that the Open Publication License (OPL) will no longer be acceptable for BIPs. He recommended replacing OPL with one or two Creative Commons licenses, with the choice between CCO and BY-SA licenses alongside public domain. The Open Publication License, created in 1999, was superseded by Creative Commons licenses. Luke-jr made updates to BIP 2, replacing BIP 1, and introduced changes such as the acceptance of non-image auxiliary files, required email addresses for authors, and disallowing Markdown format. The updated BIP 2 was open for review with the aim of completion by Christmas. diff --git a/static/bitcoin-dev/Oct_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml b/static/bitcoin-dev/Oct_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml index 005b985384..1d1e21ca3f 100644 --- a/static/bitcoin-dev/Oct_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml +++ b/static/bitcoin-dev/Oct_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP draft: OP_CHECKBLOCKATHEIGHT - 2025-09-26T16:01:27.037329+00:00 + 2025-10-11T22:14:50.951077+00:00 python-feedgen Nathan Cook 2016-10-05 02:15:36+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - BIP draft: OP_CHECKBLOCKATHEIGHT - 2025-09-26T16:01:27.037533+00:00 + 2025-10-11T22:14:50.951242+00:00 2016-10-05T02:15:36+00:00 A proposal has been made for a new opcode, OP_CHECKBLOCKATHEIGHT, in the Bitcoin scripting system. This opcode aims to tackle the problem of re-issuing bitcoin transactions when the coins they spend have been conflicted or double-spent. The proposal sparked a discussion among developers on the bitcoin-dev mailing list.Some developers expressed concerns about the complexity and potential risks of the opcode. They argued that the added complexity may not be worth the reward of protecting Bitcoiners from untrusted creditors. There were also concerns about the impact on fungibility and the risk of invalidation caused by blockchain reorganizations.Luke Dashjr, the developer who proposed the opcode, provided examples to illustrate how it could solve the problem of double-spending. One example involved Alice sending Bob BTC using a specific UTXO, but Fred double-spends that UTXO, invalidating Alice's transfer. Without the new opcode, Alice could send Bob a different UTXO, but there is a risk of both UTXOs being mined, resulting in Bob receiving more BTC than intended. With the new opcode, Alice can create a transaction that is only valid in the blockchain where Fred's double-spend has been confirmed. If that block is reorganized out, the transaction becomes invalid, ensuring that Bob receives only the original UTXO or a revised transaction if the double-spend is confirmed again.The discussion also touched upon other aspects related to the proposed opcode. There were suggestions to prevent overuse of the opcode and enforce a maximum survivable reorg to ensure sensible handling of exposed coins. Concerns were raised about the impact on mempool handling and the potential for persistent chain forks.Overall, the proposed opcode aims to address the issue of double-spending and conflicts in bitcoin transactions. It introduces a new way for users to create transactions that are only valid in specific blockchain scenarios, ensuring that the intended recipient receives the correct amount of BTC without the risk of loss due to blockchain reorganizations. However, there are ongoing discussions and debates among developers about the complexity and potential risks associated with implementing this opcode.The proposal has been put forward by Luke-Jr, who is seeking feedback from the community on whether this approach is a good idea. It is currently uncertain whether this proposal will be accepted and implemented by the Bitcoin community. However, if accepted, the proposed opcode could potentially provide a solution to the issue of double-spending that has plagued the Bitcoin network in the past. Overall, this BIP presents an interesting and innovative approach to addressing the problem of double-spending in the Bitcoin network. While its acceptance and implementation are yet to be determined, it is worth considering as a potential solution to this long-standing issue. diff --git a/static/bitcoin-dev/Oct_2016/combined_Could-a-sidechain-protocol-create-an-addressable-Internet-of-Blockchains-and-facilitate-scaling-.xml b/static/bitcoin-dev/Oct_2016/combined_Could-a-sidechain-protocol-create-an-addressable-Internet-of-Blockchains-and-facilitate-scaling-.xml index 4b4f0e5b75..69eb649828 100644 --- a/static/bitcoin-dev/Oct_2016/combined_Could-a-sidechain-protocol-create-an-addressable-Internet-of-Blockchains-and-facilitate-scaling-.xml +++ b/static/bitcoin-dev/Oct_2016/combined_Could-a-sidechain-protocol-create-an-addressable-Internet-of-Blockchains-and-facilitate-scaling-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Could a sidechain protocol create an addressable "Internet of Blockchains" and facilitate scaling? - 2025-09-26T16:01:33.370861+00:00 + 2025-10-11T22:14:57.320558+00:00 python-feedgen Natanael 2016-10-12 01:28:46+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Could a sidechain protocol create an addressable "Internet of Blockchains" and facilitate scaling? - 2025-09-26T16:01:33.371012+00:00 + 2025-10-11T22:14:57.320714+00:00 2016-10-12T01:28:46+00:00 Sidechains are a tool for scaling Bitcoin by transferring them from the main blockchain to external blockchains. However, the current approach keeps sidechains isolated from each other, requiring a slow transfer back to the mainchain. To address this, a proposed protocol for addressable blockchains aims to create an Internet of Blockchains by using a shared proof of work. This protocol would allow Bitcoins to be moved into a master sidechain called Angel, which sits at the top of a tree of blockchains.In this system, each blockchain has its own unique address similar to an IP address, and the Angel blockchain acts as a registrar, keeping a public record of every blockchain and its properties. Creating a new blockchain is as simple as including a createBlockchain transaction in an Angel block with specified parameters like block creation time and size limit.Mining in the Angel blockchain follows a standardized format, creating hashes that enable different blockchains to contribute to the same proof of work. Child blockchains inherit security from their parents without the same level of PoW difficulty. This means that if a child attempts a double spend by withdrawing to a parent after spending on the child, it will be instantly visible. Child nodes can then broadcast proof of the double spend to parent chain nodes, preventing them from mining on those blocks.The Angel blockchain allows for a free market approach, allowing different approaches and use cases such as privacy, high transaction volume, and Turing completeness to coexist seamlessly alongside each other. Bitcoin serves as the standard medium of exchange for these complementary blockchains.Another concept to achieve infinite scaling is compressing validation data maximally to enable Turing completeness for multiple interacting chains or "namespaces". This rolling blockchain uses Zero-knowledge proofs for secure pruning and preserves the entire history. Each chain is registered under a unique name and defines its own external API and rules for updating its data.Programs (transactions) can be transformed into a "diff" on the blockchain state with accompanying Zero-knowledge proofs. These proofs can be chained, allowing groups of users on a chain to create a proof for their changes, which is then compressed and sent to miners who generate a proof for the root. However, interaction between many chains can make validation inefficient, requiring more client interaction.The ideal scenario would involve creating a Lightning Network equivalent for processing programs in near real-time and quickly settling on changes to commit to the root. Programs would need to be designed for networking so that servers can negotiate their APIs across all chains until they have a complete set of changes without conflicts to commit.Overall, the proposed protocol for addressable blockchains and the Angel blockchain aim to enable scaling Bitcoin infinitely by allowing different blockchains to coexist and interact seamlessly, while preserving security and decentralization. diff --git a/static/bitcoin-dev/Oct_2016/combined_DPL-is-not-only-not-enough-but-brings-unfounded-confidence-to-Bitcoin-users.xml b/static/bitcoin-dev/Oct_2016/combined_DPL-is-not-only-not-enough-but-brings-unfounded-confidence-to-Bitcoin-users.xml index 25feb1973c..fec4bfee01 100644 --- a/static/bitcoin-dev/Oct_2016/combined_DPL-is-not-only-not-enough-but-brings-unfounded-confidence-to-Bitcoin-users.xml +++ b/static/bitcoin-dev/Oct_2016/combined_DPL-is-not-only-not-enough-but-brings-unfounded-confidence-to-Bitcoin-users.xml @@ -2,7 +2,7 @@ 2 Combined summary - DPL is not only not enough, but brings unfounded confidence to Bitcoin users - 2025-09-26T16:01:48.158839+00:00 + 2025-10-11T22:15:12.187005+00:00 python-feedgen Tom Zander 2016-10-15 10:01:32+00:00 @@ -37,10 +37,11 @@ + 2 Combined summary - DPL is not only not enough, but brings unfounded confidence to Bitcoin users - 2025-09-26T16:01:48.159001+00:00 + 2025-10-11T22:15:12.187153+00:00 2016-10-15T10:01:32+00:00 In an email conversation on the bitcoin-dev list, Daniel Robinson and Tom Zander discussed the potential advantages of the Defensive Patent License (DPL) over unilateral patent disarmament. Zander pointed out that the DPL could be more effective than MIT/BSD licenses because it creates an incentive for other companies to adopt it as well. This is important because MIT/BSD licenses allow companies to take without giving back, which doesn't build a community. Copyleft allows people to embrace and take, but if they extend they have to give back.The discussion on the bitcoin-dev mailing list has centered around the role of patents in the technology industry. While non-practicing entities are a known issue, companies also obtain patents to prevent competition and produce competing products. Obtaining a patent for defensive purposes can make it difficult for others to obtain patents on the same subject matter. However, several people have noted that patent applications are more effective than defensive publication at getting prior art under the noses of patent examiners.One user argues that pledging not to use patents offensively defeats the point of owning patents, which is to use them offensively either to prevent competition or get licensing fees. Defensive patents are useless against litigants who do not produce or make anything and whose "product" is patent lawsuits. Another user expresses concern about the Defensive Patent License (DPL) v1.1 and how it may pose a threat to Bitcoin users. Companies that join the DPL can enforce their patents against anyone who has chosen not to join, meaning most individuals cannot and will not hire patent attorneys to advise them on what benefits they are resigning. The DPL is revocable by the signers, so if Bitcoin Core ends up using any DPL-covered patent, the company owning the patent can later force all new Bitcoin users to pay royalties.A solution proposed by one user is to grant everyone an irrevocable license for the content of emails or BIPs. However, there is a problem with defining "Bitcoin users," as different forks and versions of Bitcoin may exist. Another suggestion is to change the Bitcoin Core license to an Apache2/LGPL3 dual license to ensure the copyright license also has anti-patent protections. The discussion highlights the complex issue of patents in the technology industry and the need for careful consideration when obtaining and utilizing them.The context of the conversation is related to a proposal made by an individual for a Bitcoin Improvement Proposal (BIP) that had the effect of benefiting their ASICBOOST patent without disclosing it. The individual denies the accusation and explains that the BIP actually protects the network from stealth Shared-Nonce mining. The rejection of the BIP has made the Bitcoin network less secure, as it is unclear to what extent the mining method is in use. The ASICBOOST patent, according to the individual, protects Bitcoiners from mining centralization, and they have no control over the company that owns the technology. The individual proposes a community crowdfund to license the technology and put it into the public domain.The email thread discusses the potential advantage of a dedicated Bitcoin-related defensive patent pool, similar to Linux's Open Invention Network. The idea is to strategically deploy patent licenses to encourage cooperation and punish aggressors. Additionally, it is suggested that changing the Bitcoin Core license to something like Apache2/LGPL3 dual license could ensure the copyright license also has anti-patent protections. The use of Apache2.0 license for new releases and contributions can be feasible, while already-existing code and previous releases will remain under the MIT license. The discussion also highlights the benefits of using Apache2.0 license, which contains an explicit patent license grant and terminates that license if the licensee asserts a claim alleging that the covered work infringes a patent.The Defensive Patent License (DPL) has been criticized for being dangerous for Bitcoin users, as it allows companies that join DPL to enforce their patents against anyone who has not joined. Furthermore, the license is revocable by signers, which could lead to new Bitcoin users being forced to pay royalties. However, a dedicated Bitcoin-related defensive patent pool, similar to Linux's Open Invention Network, could strategically deploy patent licenses to incentivize cooperation and punish aggressors. Additionally, changing the Bitcoin Core license to something like an Apache2/LGPL3 dual license could ensure the copyright license also has anti-patent protections. The Apache 2.0 license contains an explicit patent license grant and terminates that license if the licensee asserts a claim alleging that the covered work infringes a patent. This might be an effective deterrent against bringing patent claims based on alleged infringement in Bitcoin Core. Upgrading to the Apache license for new releases and contributions would be feasible, leaving already-existing code and previous releases under the MIT license (a copyright "soft-fork").In a Bitcoin development discussion, Sergio Demian Lerner expressed his concerns about the Defensive Patent License (DPL) v1.1. He stated that it is diff --git a/static/bitcoin-dev/Oct_2016/combined_Defensive-Patent-License-Offer-Notice.xml b/static/bitcoin-dev/Oct_2016/combined_Defensive-Patent-License-Offer-Notice.xml index 28ad80ca3c..f11621539b 100644 --- a/static/bitcoin-dev/Oct_2016/combined_Defensive-Patent-License-Offer-Notice.xml +++ b/static/bitcoin-dev/Oct_2016/combined_Defensive-Patent-License-Offer-Notice.xml @@ -2,7 +2,7 @@ 2 Combined summary - Defensive Patent License Offer Notice - 2025-09-26T16:01:37.597596+00:00 + 2025-10-11T22:15:01.566059+00:00 python-feedgen greg misiorek 2016-10-13 13:03:45+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Defensive Patent License Offer Notice - 2025-09-26T16:01:37.597726+00:00 + 2025-10-11T22:15:01.566189+00:00 2016-10-13T13:03:45+00:00 Peter Todd, a Bitcoin Core developer, has made a significant declaration regarding his patents. He has declared himself and any technology companies he controls as "Defensive" by committing to offer a Defensive Patent License (DPL) for any of his patents, whether they exist currently or in the future, to any DPL User. It is worth noting that neither Peter Todd nor any companies under his control currently have any patents.The announcement was made on Peter Todd's website, petertodd.org, and includes a link to the transaction ID (txid) of a Bitcoin transaction containing the message. This adds transparency and verifiability to his commitment. It is important to highlight that Peter Todd is offering only a specific version of the DPL based on the advice of his lawyer. The inclusion of the language "all technology companies I control" is to prevent any complications with non-technology companies he may control in the future. Examples of such non-technology companies include family real-estate holding companies and the non-profit caving group he is a part of.As of now, Peter Todd only controls one company, which he considers a "technology company". This company is the numbered company through which he conducts all his consulting work. Therefore, the offer mentioned above applies to this company. Furthermore, if Peter Todd gains control of any other technology companies in the future, the same offer will apply to them.For those interested in contacting Peter Todd, he can be reached at the email address "pete@petertodd.org". His commitment to offering a Defensive Patent License demonstrates his dedication to promoting an open and collaborative approach to technological advancements within the Bitcoin community. diff --git a/static/bitcoin-dev/Oct_2016/combined_Drivechain-proposal-using-OP-COUNT-ACKS.xml b/static/bitcoin-dev/Oct_2016/combined_Drivechain-proposal-using-OP-COUNT-ACKS.xml index 9e3dc41a59..95b8573e28 100644 --- a/static/bitcoin-dev/Oct_2016/combined_Drivechain-proposal-using-OP-COUNT-ACKS.xml +++ b/static/bitcoin-dev/Oct_2016/combined_Drivechain-proposal-using-OP-COUNT-ACKS.xml @@ -2,7 +2,7 @@ 2 Combined summary - Drivechain proposal using OP_COUNT_ACKS - 2025-09-26T16:01:24.925422+00:00 + 2025-10-11T22:14:48.827257+00:00 python-feedgen Johnson Lau 2016-10-25 17:45:20+00:00 @@ -73,10 +73,11 @@ + 2 Combined summary - Drivechain proposal using OP_COUNT_ACKS - 2025-09-26T16:01:24.925672+00:00 + 2025-10-11T22:14:48.827450+00:00 2016-10-25T17:45:20+00:00 The discussion revolves around proposals to improve the Bitcoin protocol through a softfork. One proposal suggests using an unused code instead of OP_NOPx, while another considers a new witness version and additional field in the witness. There are concerns about limited coinbase space and potential poll space shortage.Sergio Demian Lerner has proposed a segwit-based and soft-forked opcode called OP_COUNT_ACKS to count acknowledgement tags in coinbase fields. The proposal aims to achieve zero risk of invalidating a block, strong protection from DoS attacks, and minimum block space consumption. Lerner will discuss the design at the Scaling Bitcoin event.The proposed system includes a new opcode that counts acks and nacks tags in coinbase fields and pushes the totals onto the script stack. Concerns were raised about the validity of transactions and the potential for double-spending. Transactions redeeming outputs containing or referencing OP_COUNT_ACKS are not broadcast by the network and can only be included by miners.There is a discussion about encumbrances on the proposal that could prevent its use in the Bitcoin project. Suggestions are made to resolve patent concerns, such as voluntary disclosure of patents with a free license or adopting a defensive patent strategy. Concerns are also raised about the validity of transactions being dependent on the block they are included in.The context also mentions the implementation of decentralised sidechains and the process of redemption from a side chain. It is noted that the speaker's understanding of sidechain developments may be incomplete.In another email thread, it is discussed whether Rootstock's proposal is encumbered by patents or pending patents. Suggestions are made for Rootstock to adopt a legally binding patent pledge or license to ensure their developments remain free and open. The purpose of the list is emphasized as technical discussion, not political disagreements.There is a conversation between Sergio Demian Lerner and Peter Todd about a down vote on Lerner's Rootstock proposal. Lerner suggests that Rootstock adopt a legally binding patent pledge/license, such as the Defensive Patent License (DPL), to continue collaborating. Todd raises concerns about Rootstock's prior behavior regarding patents and suggests guarantees to prevent offensive use of patents.Sergio Demian Lerner, Bitcoiner and RSK co-founder, has proposed a drivechain in the BIP draft that he hopes will be used as the foundation for new 2-way-pegged blockchains. This drivechain aims to expand the use cases of Bitcoin by allowing it to be taken to new niches and tested in different scenarios. The drivechain is designed with various key properties in mind, such as ensuring no risk of invalidating a block, minimizing additional computation during blockchain management and re-organization, offering strong protection against DoS attacks, consuming minimal block space, and eliminating the risk of cross-secondary chain invalidation.Lerner's proposal comes after expressing concerns over proposals from individuals or colleagues who have a history of patenting Bitcoin consensus relevant technology. He believes that this behavior poses a serious threat to decentralization and suggests that it needs to be addressed in a convincing and legally binding manner. To move forward, he proposes exploring Blockstream's patent pledges. However, Lerner NACKed the proposal due to its history of patenting. The proposal specifically pertained to drivechains which RSK (also known as Rootstock) intends to use for their two-way pegged blockchain implementation.In light of the approaching ScalingBitcoin event, Lerner saw it as an opportune time to publish the proposal on drivechains. While the full BIP and reference implementation can be found on GitHub, it should be noted that the code is still unaudited. Lerner will be available at ScalingBitcoin to discuss the design rationale, potential improvements, changes, and ideas related to the proposed drivechain. diff --git a/static/bitcoin-dev/Oct_2016/combined_On-going-work-Coin-Selection-Simulation.xml b/static/bitcoin-dev/Oct_2016/combined_On-going-work-Coin-Selection-Simulation.xml index e94ec445e6..8682800d98 100644 --- a/static/bitcoin-dev/Oct_2016/combined_On-going-work-Coin-Selection-Simulation.xml +++ b/static/bitcoin-dev/Oct_2016/combined_On-going-work-Coin-Selection-Simulation.xml @@ -2,7 +2,7 @@ 2 Combined summary - On-going work: Coin Selection Simulation - 2025-09-26T16:01:22.809236+00:00 + 2025-10-11T22:14:46.701881+00:00 python-feedgen Murch 2016-10-21 14:09:57+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - On-going work: Coin Selection Simulation - 2025-09-26T16:01:22.809406+00:00 + 2025-10-11T22:14:46.702024+00:00 2016-10-21T14:09:57+00:00 Murch, a Master's thesis student, has developed a Coin Selection Simulator and re-implemented multiple coin selection strategies of prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin). He invites interested parties to take a look at his work, which includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation. Murch has analyzed the Coin Selection problem and created a framework to simulate wallet behavior on the basis of a sequence of payments. He plans to publish the simulation code around Scaling Bitcoin or after he turns in his thesis.Murch also addresses a question from Daniel Weigl regarding why Mycelium generates a very big UTXO set for 5460sat. Murch explains that his simulation of the Mycelium coin selection adds small change outputs to the fee but got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Therefore, the results in the table might be slightly too big, but likely indicative of the actual Mycelium behavior. Murch assumes that Mycelium doesn't create small change outputs but rather hardly ever spends them when received. Murch believes that Mycelium appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up.A researcher, Murch, has analyzed the Coin Selection problem and re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. As part of this research, Murch created a framework to simulate wallet behavior on the basis of a sequence of payments. The simulation results are presented in a two-page description along with three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Murch also invited feedback and requested another sequence of incoming and outgoing payment amounts to run the simulation on. In response to Murch's email, Daniel Weigl, from Mycelium, inquired about the behavior of Mycelium coin selection algorithm. Murch clarified that Mycelium selects UTXO in a FIFO approach, but prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems to be the likely reason for Mycelium's small UTXO build-up. BreadWallet uses a very similar FIFO approach, but doesn't prune which causes their average UTXO set to be much smaller. A balanced approach between these two approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, who is compiling his Master's thesis about Coin Selection, has created a framework to simulate wallet behavior on the basis of a sequence of payments. He re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF containing a two-page description of his ongoing work includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Daniel Weigl asked about Mycelium's large UTXO set for 5460sat (=TransactionUtils.MINIMUM_OUTPUT_VALUE). Murch replied that his simulation did add small change outputs to the fee, but he got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Murch corrected the boundary in his simulation now and will update his simulation results before Scaling Bitcoin. Regarding Mycelium, Murch stated that it doesn't create small change outputs but rather hardly ever spends them when received. It appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up. A balanced approach between BreadWallet's and Mycelium's approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, a researcher, has compiled his Master's thesis about Coin Selection and his presentation proposal to Scaling Bitcoin has been accepted. In his thesis, he analyzed the Coin Selection problem, created a framework to simulate wallet behavior on the basis of a sequence of payments, and re-implemented multiple coin selection strategies of prominent Bitcoin wallets such as Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF contains a two-page diff --git a/static/bitcoin-dev/Oct_2016/combined_Start-time-for-BIP141-segwit-.xml b/static/bitcoin-dev/Oct_2016/combined_Start-time-for-BIP141-segwit-.xml index 66ff7c6f82..a43ffdc711 100644 --- a/static/bitcoin-dev/Oct_2016/combined_Start-time-for-BIP141-segwit-.xml +++ b/static/bitcoin-dev/Oct_2016/combined_Start-time-for-BIP141-segwit-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Start time for BIP141 (segwit) - 2025-09-26T16:01:29.149122+00:00 + 2025-10-11T22:14:53.074980+00:00 python-feedgen Jorge Timón 2016-10-17 13:31:07+00:00 @@ -113,10 +113,11 @@ + 2 Combined summary - Start time for BIP141 (segwit) - 2025-09-26T16:01:29.149336+00:00 + 2025-10-11T22:14:53.075138+00:00 2016-10-17T13:31:07+00:00 In a recent discussion on the Bitcoin-dev mailing list, concerns were raised about the safety and implementation of the SegWit upgrade. Tom Zander pointed out that if any issues occurred after deployment, all transactions made during that time would become everyone-can-spent transactions, resulting in real people losing real money. He emphasized the importance of ensuring proper miner support before activation to avoid this risk.However, there was debate over whether a longer grace period would actually make the network safer. Some members argued that companies would not roll out their updates until lock-in is confirmed, while others believed that many wallets already had code ready and tested but had not yet released it. The discussion also touched upon the amount of code and changes in SegWit, with Zander expressing concern that it was a dangerous change in Bitcoin. However, another member pointed out that SegWit had undergone extensive testing and review on various testnets.There were also discussions about the status of wallet developer updates for SegWit support. Some developers had already worked on SegWit support, but concerns were raised about inadequate testing and vetting. In addition, there were concerns about potential network splits and the need for an extended "fallow period" to ensure safety. However, some members dismissed these concerns and insisted that the safety period should not be extended.The discussion also mentioned the controversy surrounding the implementation of SegWit and the objections raised by some members. Despite this, most underlying libraries have already been adapted or are being adapted for SegWit. However, since SegWit is not yet live on mainnet, most libraries cannot release their SegWit supported versions until it is released as final. Companies are already planning to update their services for SegWit, but the actual state of wallet readiness may not be accurately reflected.Overall, the discussion on the Bitcoin-dev mailing list revolved around the safety measures for deploying SegWit, concerns about potential issues, and the readiness of wallet developers to support SegWit. There were differing opinions on the need for a longer grace period and the risks associated with the changes in SegWit. The debate highlighted the complexity and controversy surrounding the implementation of this upgrade.Tom Zander, a developer, has raised concerns about the deployment of SegWit, stating that using BIP9 to shorten the grace period is risky. He argues that once deployed, the feature cannot be rolled back, potentially turning all transactions into everyone-can-spend transactions. Zander believes that there is no need to use BIP9 and that stalling the process for two months does not improve security.In response, developer Jorge Timón argues that changing BIP9's initial date would not benefit those who have not yet started working on supporting SegWit. Zander suggests that if the reason for the short activation timespan is the use of BIP9, then it should not be used at all.There are objections to the implementation of SegWit due to its long wait time and the fact that some wallets are taking a "wait and see" approach. The majority of wallets are not ready for SegWit, leading to reservations about investing resources in adding support for a feature that may not be activated. Flexible Transactions has been proposed as a safer alternative, but its activation is dependent on whether it is locked in.The deployment of Segregated Witness (SegWit) has faced objections, with some wallets adopting a cautious approach. This is because most wallets are not prepared for SegWit activation, and they may not want to allocate resources to a feature that may never be activated. Flexible Transactions has been suggested as an alternative, but it remains uncertain which option will ultimately be activated.Bitcoin Core's 0.13.1 release includes segregated witness for Bitcoin mainnet after extensive testing. Setting BIP 141's start time to November 15, 2016, was proposed, following the recommendation to set the versionbits start time a month in the future. Activation on the network requires passing this date, a full retarget window of 2016 blocks with 95% signaling the version bit (bit 1 for BIP141), and a fallow period of another 2016 blocks.SPV wallets will continue to function normally without upgrading, as full nodes will provide transactions in a format they understand. However, end users may want to upgrade to benefit from lower transaction fees. Tom Zander suggests a minimum of two months for the fallow period, as this upgrade affects both businesses and end users.Gavin Andresen conducted a survey on how long it would take businesses and individuals to upgrade to a new release, with no one responding that it would take more than two weeks. He believes that those running their own validation code should be able to mitigate any risks associated with SegWit activation. While there have been objections to the implementation of SegWit, several wallets are close to finishing their support.In a discussion on the bitcoin-dev mailing list diff --git a/static/bitcoin-dev/Oct_2016/combined_The-Soft-Fork-Deception.xml b/static/bitcoin-dev/Oct_2016/combined_The-Soft-Fork-Deception.xml index c3648d0e4e..94b21b3f0e 100644 --- a/static/bitcoin-dev/Oct_2016/combined_The-Soft-Fork-Deception.xml +++ b/static/bitcoin-dev/Oct_2016/combined_The-Soft-Fork-Deception.xml @@ -2,7 +2,7 @@ 2 Combined summary - The Soft Fork Deception - 2025-09-26T16:01:43.931045+00:00 + 2025-10-11T22:15:07.937145+00:00 python-feedgen Andrew C 2016-10-28 15:28:35+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - The Soft Fork Deception - 2025-09-26T16:01:43.931203+00:00 + 2025-10-11T22:15:07.937277+00:00 2016-10-28T15:28:35+00:00 The email thread discussing soft forks in Bitcoin Core reveals a misconception that soft forks do not require users to upgrade software. However, this is not entirely accurate, as miners and users who wish to utilize old rules are no longer able to do so under tightened rules implemented through soft forks. This can lead to network splits and the creation of two separate coins. The thread mentions the BIP 66 hard fork, which occurred due to greedy miners engaging in SPV mining rather than "sloppy deployment" by developers. The upcoming Segregated Witness (SegWit) soft fork is also discussed, raising questions about whether non-SegWit transactions will still validate blocks and whether miners mining non-SegWit blocks will be disregarded. One proposal suggests removing previously "soft forked" rules for non-SegWit transactions and requiring them only for SegWit transactions, making SegWit optional. However, this would necessitate a hard fork and result in functionality loss and various bug fixes. Amidst the conversation, Andrew proposes creating a new client called Bitcoin Authentic if his proposal does not gain traction. Other participants in the thread show little interest in this idea. Overall, the discussion highlights the need for clarity regarding the impact of soft forks on software upgrades, concerns about the upcoming SegWit soft fork, and proposals for alternative approaches to implementing new features. diff --git a/static/bitcoin-dev/Oct_2016/combined_The-use-OP-COUNT-ACKS-for-paying-for-a-common-good-for-miners.xml b/static/bitcoin-dev/Oct_2016/combined_The-use-OP-COUNT-ACKS-for-paying-for-a-common-good-for-miners.xml index 481d8aae7d..28f3a3f4d6 100644 --- a/static/bitcoin-dev/Oct_2016/combined_The-use-OP-COUNT-ACKS-for-paying-for-a-common-good-for-miners.xml +++ b/static/bitcoin-dev/Oct_2016/combined_The-use-OP-COUNT-ACKS-for-paying-for-a-common-good-for-miners.xml @@ -2,7 +2,7 @@ 2 Combined summary - The use OP_COUNT_ACKS for paying for a common good for miners - 2025-09-26T16:01:31.258443+00:00 + 2025-10-11T22:14:55.199132+00:00 python-feedgen Jorge Timón 2016-10-03 06:17:25+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - The use OP_COUNT_ACKS for paying for a common good for miners - 2025-09-26T16:01:31.258613+00:00 + 2025-10-11T22:14:55.199265+00:00 2016-10-03T06:17:25+00:00 In October 2016, Sergio Demian Lerner proposed a use case for OP_COUNT_ACKS in Bitcoin. This feature would allow users to pay miners for various services that they can provide as a group for the common good. These services could range from smoothing fee payments over multiple blocks to jointly purchasing better internet service in order to improve bandwidth and reduce latency between miners.To utilize this feature, users can send bitcoins to a script that contains OP_COUNT_ACKS. The script requires 51% of miners' approval for the transaction. Additionally, users can add a special text tag, such as "FOR-MINERS-TO-BUY-X", to these outputs. By doing so, users can effectively send bitcoins to miners and request the majority of them to vote on the proposal. If the proposal is accepted, a transaction will be created to redeem the funds.The implementation of OP_COUNT_ACKS and its associated crowdfunding system could potentially address the tragedy of the commons problem that Bitcoin may face in the long term. It allows users to collectively crowdfund the mining of the following n blocks, ensuring the sustainable growth and operation of the Bitcoin network. With this system, users have the ability to financially support miners and incentivize their participation in providing valuable services for the Bitcoin community.Overall, OP_COUNT_ACKS presents an innovative solution for users to pay for services provided by miners for the common good. By utilizing this feature, Bitcoin users can contribute to the long-term sustainability and development of the Bitcoin network. diff --git a/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-21.xml b/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-21.xml index 31d767fec3..df93302fb6 100644 --- a/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-21.xml +++ b/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-21.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 29, Issue 21 - 2025-09-26T15:31:51.264700+00:00 + 2025-10-11T21:40:20.314075+00:00 python-feedgen Scott Roberts 2017-10-13 13:57:33+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 29, Issue 21 - 2025-09-26T15:31:51.264844+00:00 + 2025-10-11T21:40:20.314245+00:00 2017-10-13T13:57:33+00:00 The email conversation on the Bitcoin-dev mailing list covers a wide range of topics related to Bitcoin. One important topic discussed is the relationship between mining infrastructure and the price of Bitcoin. ZmnSCPxj argues that mining follows price, while Ilansky believes the opposite. However, it is noted that biases away from ZmnSCPxj's viewpoint reveal the need for a more responsive difficulty algorithm.The discussion then turns to the possibility of a fork clone using a faster difficulty to attack Bitcoin's slow difficulty if it reaches a comparable price. This would lower the value of Bitcoin until it forks to fix the difficulty. It is emphasized that hardforks require massive coordination efforts that cannot be feasibly done within a month. The current price ratio suggests that there is no immediate need for a new difficulty algorithm.The email conversation also explores the deflationary nature of Bitcoin and the potential for it to become a constant value coin. The role of good developers in determining the long-term value of Bitcoin is highlighted, along with the importance of miners, hodlers, and users. The idea of using a faster responding difficulty to prevent miners from bullying smaller coins is discussed, but the risks of hardforks are also acknowledged.Lastly, the debate centers on whether increasing the quantity of the coin is necessary to maintain a constant value and the potential economic distortions this may cause. It is argued that expanding the coin quantity is needed to keep the value constant, which goes against the conception of Bitcoin as having a fixed limit and becoming deflationary. However, it is noted that hardforks require significant coordination efforts and that fewer back-incompatible changes to a coin are generally preferable.Overall, the email conversation provides valuable insights into various factors that impact Bitcoin's ecosystem and its future trajectory. The discussion touches on mining infrastructure, difficulty algorithms, deflationary qualities, the role of developers, and the implications of expanding the coin quantity. diff --git a/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-24.xml b/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-24.xml index 03c797ac91..a76b1c7b41 100644 --- a/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-24.xml +++ b/static/bitcoin-dev/Oct_2017/combined_bitcoin-dev-Digest-Vol-29-Issue-24.xml @@ -2,7 +2,7 @@ 2 Combined summary - bitcoin-dev Digest, Vol 29, Issue 24 - 2025-09-26T15:31:49.153981+00:00 + 2025-10-11T21:40:18.191826+00:00 python-feedgen Mark Friedenbach 2017-10-20 18:55:55+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - bitcoin-dev Digest, Vol 29, Issue 24 - 2025-09-26T15:31:49.154135+00:00 + 2025-10-11T21:40:18.192005+00:00 2017-10-20T18:55:55+00:00 The bitcoin-dev mailing list is currently discussing the possibility of decreasing the block time for Bitcoin in order to improve scalability. The current block time of ten minutes was chosen by Satoshi as a compromise between confirmation time and wasted work due to chain splits. However, with advancements in technology and the absence of a precise formula to determine the optimal rate, there is speculation about whether the block time could be reduced further.While shorter block times would result in more chain splits, it may be possible to go lower than ten minutes without significant issues. It is important to note that reducing the block interval comes with several centralizing downsides. One concern is the potential for reduced security due to a high stale rate. When blocks take time to propagate through the network, if one miner mines a block while another miner simultaneously mines a different block before the first block propagates, the second block becomes wasted and does not contribute to network security. This issue is compounded when the block interval is short enough for the stale rate to be high. Additionally, there is a risk of centralization where mining pools with more hash power have a higher chance of producing stale blocks. This means that blockchains producing blocks quickly are likely to give one mining pool de facto control over the mining process.Another consideration when reducing the block time is the need to decrease the block size accordingly. In a hypothetical scenario with a five-minute block time, there would be twice the block space available for miners to include transactions. This could lead to the blockchain growing at a faster rate, which is detrimental to decentralization. Furthermore, reducing the block time may cause transaction fees to decrease, making it cheaper for spammers to bloat the UTXO (Unspent Transaction Output) sets.There have been various proposals to address the downsides of faster blocks, with one notable suggestion being the "Greedy Heaviest Observed Subtree" (GHOST) protocol. This protocol aims to overcome the security and centralization concerns associated with reducing block time. Additionally, it is worth mentioning that the Lightning teams have made significant progress in point-of-sale support, providing an alternative solution to scalability.While the goal for Bitcoin may be to eventually achieve a block time of one second or less, current technology is not yet developed enough to support this level of speed due to the limitations imposed by the speed of light. However, there have been efforts to mitigate potential issues, such as the development of a script to prevent a "sybil attack" from 2x. The efficacy and ethical implications of this script are subjects of debate within the community. diff --git a/static/bitcoin-dev/Oct_2018/combined_Generalised-taproot.xml b/static/bitcoin-dev/Oct_2018/combined_Generalised-taproot.xml index b7b6c4a3cf..e4f3c88618 100644 --- a/static/bitcoin-dev/Oct_2018/combined_Generalised-taproot.xml +++ b/static/bitcoin-dev/Oct_2018/combined_Generalised-taproot.xml @@ -2,7 +2,7 @@ 2 Combined summary - Generalised taproot - 2025-09-26T16:03:22.952330+00:00 + 2025-10-11T22:17:17.575101+00:00 python-feedgen Pieter Wuille 2018-10-24 02:22:24+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Generalised taproot - 2025-09-26T16:03:22.952499+00:00 + 2025-10-11T22:17:17.575262+00:00 2018-10-24T02:22:24+00:00 Pieter Wuille, a Bitcoin Core developer, has introduced a new construction called "g'root" to address the issue of recursive-taproot-without-revealing-intermediary-scripts. This structure combines the concepts of Pedersen Commitments and taproot, resulting in an equation that combines private keys, hashes of additional conditions, and alternative spending methods.The g'root construction eliminates the distinction between pay-to-pubkey and pay-to-script constructions, providing an easy way to create a softfork-safe cross-input aggregation system. It also ensures that any future cross-input signature aggregation system only applies to companion keys that are not susceptible to potential changes in the scripting language.Wuille suggests deploying schnorr/taproot/mast initially, followed by the addition of graftroot/aggregation. Finally, the deployment of generalised taproot alongside graftroot/aggregation is recommended.In addition to this proposal, there is another suggestion for recursive taproot that utilizes Pedersen Commitments. By combining the taproot structure with a second generator in the curve, it becomes possible to create a pubkey point that can be spent either through direct signing or by revealing additional conditions.To maintain secrecy, the proposal allows users to hide whether there are any lower layers until the merkle-tree of scripts is reached. Furthermore, it enables the non-disclosure of conditions corresponding to any keys other than the one being spent with.This proposal is as space-efficient as basic taproot and potentially more efficient than using a merkle tree with taproot when there are three spending paths.To summarize, Pieter Wuille's "g'root" construction and the proposal for recursive taproot with Pedersen Commitments aim to enhance the functionality and efficiency of Bitcoin transactions. These proposals suggest deploying different components such as schnorr/taproot/mast and graftroot/aggregation in a phased manner to ensure a smooth transition. diff --git a/static/bitcoin-dev/Oct_2019/combined_Block-Batch-Filters-for-Light-Clients.xml b/static/bitcoin-dev/Oct_2019/combined_Block-Batch-Filters-for-Light-Clients.xml index 474f06006d..1d8076ff9d 100644 --- a/static/bitcoin-dev/Oct_2019/combined_Block-Batch-Filters-for-Light-Clients.xml +++ b/static/bitcoin-dev/Oct_2019/combined_Block-Batch-Filters-for-Light-Clients.xml @@ -2,7 +2,7 @@ 2 Combined summary - Block Batch Filters for Light Clients - 2025-09-26T15:27:16.193115+00:00 + 2025-10-11T21:28:55.759253+00:00 python-feedgen Jonas Schnelli 2019-10-11 15:44:54+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - Block Batch Filters for Light Clients - 2025-09-26T15:27:16.193255+00:00 + 2025-10-11T21:28:55.759409+00:00 2019-10-11T15:44:54+00:00 The conversation discusses the limitations of BIP 157 compared to BIP 37 in terms of applying filters to mempool and checking zero confirmation transactions. The light client can only process unconfirmed transactions by loading the entire mempool transaction flow, which raises concerns about DOS and fingerprinting. To address this, a possible solution is suggested, which involves retrieving a complete compact filter of the entire mempool using a maximum size ordered by feerate. This filter could be dynamically constructed and updated based on time intervals rather than every new transaction in the mempool. The process includes generating a mempool filter, connecting to the peer, requesting the filter, processing it for relevant transactions, and sending getdata for those transactions. After the initial retrieve, the light client inspects all new transactions received from peers (filterless unconfirmed tx detection). Alternatively, the mempool filter can be requested again after a timeout if the previous process consumes too much bandwidth. The goal is to make the light client process more efficient without compromising privacy and security.The Block Batch Filters draft has been improved, unlocking the ability to filter unconfirmed transactions for SPV nodes using BIP 157 instead of BIP 37, which had privacy leaks. This allows light clients that refused to use BIP 37 to process unconfirmed transactions by loading the entire mempool transaction flow. Additionally, the Mempool Transaction Filters draft proposes a future consensus layer soft-fork to incorporate block filters commitment into block validation rules, protecting light nodes from payment hiding attacks. This method also reduces bandwidth consumption compared to block filters and downloading full blocks for affected addresses.The updated version of the draft for BIP block batch filters can be found on the Bitaps Github page. It includes changes such as a return to Golomb coding and a simpler, more effective schema implementation. The total filter size is smaller than BIP 158, with estimated savings of over 20%. The filter is deterministic and could potentially be committed as a commitment in coinbase transactions in the future. The GCS parameters are flexible to maintain necessary FPS, and the filter has been split into two parts - unique elements and duplicated elements - with the latter encoded more effectively. However, there are still questions about the optimal range for batch, the need for SIP hash instead of using the first 64 bits from pub key/script hash, and whether unique/duplicated elements should be downloaded separately or if filter types should be added for these purposes. Feedback and discussions on these topics are welcome.Aleksey Karpov also shared a draft of a BIP for compact probabilistic block filters as an alternative to BIP 158. While BIP 158 has a low false positive rate, a higher false positive rate filter could achieve lower bandwidth while syncing the blockchain. However, BIP 158 does not support filter batching due to the design of its parameters for siphash and Golomb coding. The proposed alternative uses delta coding and splits data into two bit string sequences, compressing the second sequence with two rounds of the Huffman algorithm. This method has an effectiveness rate of about 98% compared to Golomb with optimal parameters. Batching block filters significantly reduces their size, and separating filters by address type allows lite clients to avoid downloading redundant information without compromising privacy. The recommended strategy for lite client filters download is to get the biggest filter (smallest blocks/size rate) for a blocks range, then, in case of a positive test, get medium filters to reduce the blocks range, followed by getting block filters for the affected range and downloading affected blocks over TOR. An implementation in Python can be found on GitHub.Tamas Blummer also shared his thoughts on the use of filters in deciding whether to download newly announced blocks. He believes that whole chain scans would be better served with plain sequential reads in map-reduce style. Many clients do not care about filters for blocks before the birth date of their wallet's keys, so they skip over the majority of history, resulting in greater savings than any aggregate filter. Blummer wishes for a filter commitment as it could unlock more utility than marginal savings through a more elaborate design.In conclusion, there are ongoing developments and discussions regarding the limitations of BIP 157, the improvements to the Block Batch Filters draft, and the proposed alternative compact probabilistic block filters. The aim is to make the light client process more efficient while ensuring privacy and security. Feedback and input on these matters are encouraged. diff --git a/static/bitcoin-dev/Oct_2019/combined_OP-CAT-was-Re-Continuing-the-discussion-about-noinput-anyprevout.xml b/static/bitcoin-dev/Oct_2019/combined_OP-CAT-was-Re-Continuing-the-discussion-about-noinput-anyprevout.xml index 9e101c2b4b..78050065a0 100644 --- a/static/bitcoin-dev/Oct_2019/combined_OP-CAT-was-Re-Continuing-the-discussion-about-noinput-anyprevout.xml +++ b/static/bitcoin-dev/Oct_2019/combined_OP-CAT-was-Re-Continuing-the-discussion-about-noinput-anyprevout.xml @@ -2,7 +2,7 @@ 2 Combined summary - OP_CAT was Re: Continuing the discussion about noinput / anyprevout - 2025-09-26T15:27:07.612358+00:00 + 2025-10-11T21:28:53.629139+00:00 python-feedgen Andrew Poelstra 2019-10-09 16:56:51+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - OP_CAT was Re: Continuing the discussion about noinput / anyprevout - 2025-09-26T15:27:07.612566+00:00 + 2025-10-11T21:28:53.629306+00:00 2019-10-09T16:56:51+00:00 The conversations surrounding the development of Bitcoin have focused on various opcodes and approaches to improve efficiency, address limitations, and enable new possibilities for protocol building. One proposal suggests encoding `SIGHASH` on public keys by using either 33-byte or 34-byte representations, which would allow operations like `OP_CHECKSIG` to determine the sighash algorithm based on the public key rather than the signature.Another topic of discussion has been the limitations of Merkle trees in Bitcoin blocks, specifically in determining whether a hash represents a subnode or a leaf transaction. To address this, there is a proposal to implement tagged SHA256 as a new opcode, which could help solve the issue.There have also been considerations about the usefulness and efficiency of OP_CAT, an opcode that concatenates stack values. Concerns have been raised regarding its efficiency and behavior when allocating new memory and copying existing data. Suggestions have been made to set maximum output size limits for OP_CAT, ranging from 64 bytes to 256 bytes, as a way to reduce worst-case behavior.The Lightning-dev mailing list has seen discussions about replacing OP_CAT with OP_SHA256STREAM, which would allow unlimited data concatenation using the streaming properties of a SHA256 hash function. The advantages and disadvantages of this proposal have been explored, including the tension between generic-use components and specific-use components. However, it is noted that OP_SHA256STREAM would become unusable if SHA256 is ever compromised.Various individuals have shared their opinions on OP_CAT versus other options like SHA256STREAM in email threads. Additionally, conversations have revolved around scriptless scripts, adaptor signatures, and paying for a merkle path without validating it on-chain.Throughout these discussions, participants emphasize the need for basic tools and opcodes like OP_CAT to facilitate the development of future protocols on Bitcoin. They also highlight the importance of designing layer 2 protocols first and then adapting layer 1 accordingly.In summary, the conversations surrounding Bitcoin's development involve evaluating the benefits and trade-offs of different opcodes and approaches. The focus is on improving efficiency, addressing limitations, and enabling new possibilities for protocol building. Notably, developments such as the introduction of new opcodes and the proposed `OP_SETPUBKEYSIGHASH` are significant for enhancing the security and privacy of Bitcoin transactions. diff --git a/static/bitcoin-dev/Oct_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap-appendium.xml b/static/bitcoin-dev/Oct_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap-appendium.xml index 01f55c455d..f435c4c405 100644 --- a/static/bitcoin-dev/Oct_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap-appendium.xml +++ b/static/bitcoin-dev/Oct_2020/combined_Detailed-protocol-design-for-routed-multi-transaction-CoinSwap-appendium.xml @@ -2,7 +2,7 @@ 2 Combined summary - Detailed protocol design for routed multi-transaction CoinSwap appendium - 2025-09-26T15:37:11.509537+00:00 + 2025-10-11T21:47:25.434668+00:00 python-feedgen ZmnSCPxj 2020-10-03 13:31:58+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Detailed protocol design for routed multi-transaction CoinSwap appendium - 2025-09-26T15:37:11.509670+00:00 + 2025-10-11T21:47:25.434817+00:00 2020-10-03T13:31:58+00:00 The email conversation between Chris and ZmnSCPxj discusses the incentives against post-coinswap-theft-attempt, even with K=0. The extra miner fee paid by Bob acts as a disincentive for theft. In the v2 protocol, each CoinSwap party knows a different version of the contract transactions, allowing Alice to identify the correct fidelity bond. ZmnSCPxj appreciates this observation and will further consider it.A new version of the CoinSwap protocol has been released, offering a secure and private method for exchanging cryptocurrencies. This protocol incorporates staggered timelocks, hash preimages, and anti-DOS features to ensure that parties can retrieve their coins in case of an abort while maintaining privacy. The protocol includes multi-transaction CoinSwaps, routed CoinSwaps, liquidity market, private key handover, and fidelity bonds.Routed CoinSwaps are a feature of the protocol, involving one market taker and two makers, but can be extended to include more makers. Funding transactions pay into 2-of-2 multisig addresses, while contract transactions may spend from the 2-of-2 multisig outputs. To prevent attacks like low miner fees or intentional transaction abortion, parties must refuse to sign a contract transaction if the corresponding funding transaction pays greater miner fees than the attacker's.Collateral payments are suggested to deter post-coinswap-theft-attempts. The v2 design of CoinSwap is explained in detail using three parties: Alice, Bob, and Charlie. The taker (Alice) does not need collateral payments and can fully spend their entire wallet in one set of CoinSwaps. Contract transactions have different versions depending on who knows them. The table of balances before and after a coinswap demonstrates that everyone receives their money back and pays their own miner fees.However, a successful CoinSwap with a post-CoinSwap-theft-attempt results in Bob losing K bitcoins and an extra miner fee, while Charlie gains K bitcoins. The document provides a thorough analysis of possible attacks, deviations from the protocol, miner fees, and vulnerabilities of RBF. Parties must monitor the network and be prepared to respond with their own sweep using a preimage.The reaction of blacklisting both fidelity bonds by Alice may not be the most appropriate approach, as one maker could use it to blacklist another (and themselves). Overall, the CoinSwap protocol aims to offer a secure, private, and efficient means of exchanging cryptocurrencies between parties. diff --git a/static/bitcoin-dev/Oct_2020/combined_Progress-on-Miner-Withholding-FPNC.xml b/static/bitcoin-dev/Oct_2020/combined_Progress-on-Miner-Withholding-FPNC.xml index 0171087620..67f6611347 100644 --- a/static/bitcoin-dev/Oct_2020/combined_Progress-on-Miner-Withholding-FPNC.xml +++ b/static/bitcoin-dev/Oct_2020/combined_Progress-on-Miner-Withholding-FPNC.xml @@ -2,7 +2,7 @@ 2 Combined summary - Progress on Miner Withholding - FPNC - 2025-09-26T15:37:15.709887+00:00 + 2025-10-11T21:47:27.558211+00:00 python-feedgen Mike Brooks 2020-10-09 00:16:40+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - Progress on Miner Withholding - FPNC - 2025-09-26T15:37:15.710044+00:00 + 2025-10-11T21:47:27.558397+00:00 2020-10-09T00:16:40+00:00 In a discussion on the bitcoin-dev mailing list, Mike Brooks agrees with Pieter Wuille's concerns about the impact of the FPNC idea on CPU consumption and the electorate. He argues that the "getdata" message is a problem for operators and suggests that the threshold for a patch may be too high. Mike believes that FPNC can rebalance incentives and resolve abuses that reshape the electorate, leading to a more decentralized and fair network than the current "first seen" approach.Pieter Wuille responds to Mike, pointing out that Greg Maxwell is not part of the conversation and clarifying that the discussion mainly revolves around a DoS attack report, which was ultimately a mistake.The discussion thread focuses on two proposed changes to address the issues of miner withholding attacks and network decentralization. The current problem is that miners have an incentive to withhold blocks to gain an advantage in calculating the next block, resulting in a centralized network and transaction delays. The proposed solution involves rebalancing selfish-mining incentives, faster block creation times, and implementing FPNC. However, ZmnSCPxj warns about the reintroduction of selfish mining attacks if FPNC is implemented, making it a hard NAK. Despite the risks, proponents argue that the proposed changes will benefit the network and users.The article explains that the miner withholding attack is a significant issue in the Bitcoin network, leading to centralization and delays in transactions. FPNC is proposed as a solution, introducing a floating-point fitness value for each block to enable fair disagreement resolution and reduce the incentive to withhold blocks. By speeding up block formation time and maintaining inflation targets, the impact of malignant miners can be mitigated. The proposed changes aim to reduce unfair advantages given to large mining pools and promote honest mining practices.The author discusses the miner withholding attack and FPNC, highlighting the unintended incentive it creates for miners to hold onto blocks. Withholding blocks gives major mining pools an unfair advantage, contributes to centralization, and delays transactions. The proposed solution, FPNC, is considered a hard NAK due to the risk of reintroducing selfish mining attacks. The author suggests raising the threshold to 33% as a potential solution.Mike Brooks reveals that the idea for FPNC came from a conversation with ZmnSCPxj regarding re-org stability. After discussing with ZmnSCPxj and Greg Maxwell, it was agreed that the current problems facing the network are more significant than theoretical ones. Pieter Wuille clarifies that the discussion primarily revolves around a DoS attack report that turned out to be a mistake. diff --git a/static/bitcoin-dev/Oct_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml b/static/bitcoin-dev/Oct_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml index ce7f96888d..eae2101c8f 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Inherited-IDs-A-safer-more-powerful-alternative-to-BIP-118-ANYPREVOUT-for-scaling-Bitcoin.xml @@ -2,7 +2,7 @@ 2 Combined summary - Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin - 2025-09-26T16:03:35.617045+00:00 + 2025-10-11T22:18:27.696195+00:00 python-feedgen jlspc 2021-10-10 22:03:38+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin - 2025-09-26T16:03:35.617210+00:00 + 2025-10-11T22:18:27.696378+00:00 2021-10-10T22:03:38+00:00 In a recent email exchange, John responded to Anthony Towns' gratitude for reviewing his paper on Inherited IDs (IIDs) and clarified some misunderstandings. Despite the use of an operator in certain protocols, John emphasized that IIDs remain trust-free since the operator cannot control funds or hinder others from receiving their rightful share. Moreover, the simulation of IIDs with anyprevout is not feasible due to its lack of a covenant mechanism, which is crucial for unconditional ownership transfer.John's paper highlights the fundamental functionality of IIDs, namely the ability to facilitate "update-forest" and "challenge-and-response" operations. These features enable the secure transfer of channel ownership in a trust-free manner using a single transaction. By utilizing this approach, IIDs can eliminate the need for watchtowers and create factories with an unlimited number of parties and channels. Importantly, these achievements are made possible by implementing a safer change to Bitcoin compared to the support provided for floating transactions.During a conversation between John Law and ZmnSCPxj, ZmnSCPxj presents a counterargument regarding the necessity of on-chain transactions for updating a factory's set of channels. ZmnSCPxj asserts that factories can already be created without relying on Taproot technology. This can be achieved by initially creating an n-of-n output for the funding transaction, which can then be split through an off-chain transaction. To modify the set of channels, participants simply create and sign an alternate transaction that spends the original output to a new n-of-n output involving the same participants. Subsequently, they broadcast this transaction to update the channel configuration. ZmnSCPxj describes this process as akin to a "no updates" factory, as it bypasses the closing transaction of the previous factory by initiating a new one.Overall, John's response sheds light on the capabilities of IIDs and their potential to revolutionize the way channels are managed and ownership is transferred. Meanwhile, ZmnSCPxj introduces an alternative perspective on the concept of factories and challenges the necessity of on-chain updates. diff --git a/static/bitcoin-dev/Oct_2021/combined_Taproot-testnet-wallet.xml b/static/bitcoin-dev/Oct_2021/combined_Taproot-testnet-wallet.xml index 7254822c8b..e132977e8a 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Taproot-testnet-wallet.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Taproot-testnet-wallet.xml @@ -2,7 +2,7 @@ 2 Combined summary - Taproot testnet wallet - 2025-09-26T16:03:52.583378+00:00 + 2025-10-11T22:18:29.820915+00:00 python-feedgen Prayank 2021-10-15 14:12:23+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Taproot testnet wallet - 2025-09-26T16:03:52.583549+00:00 + 2025-10-11T22:18:29.821061+00:00 2021-10-15T14:12:23+00:00 The email discusses the implementation of Bitcoin's Taproot addresses in bitcoinj and the need for testing against a wallet that can receive to P2TR and spend back. The author shares a transaction they did days ago which creates a P2TR output and provides detailed steps taken for the transaction. They suggest adding test vectors in BIP 86 for TPRV as suggested by Anthony Towns in a previous email.On October 15th, 2021, Anthony Towns posted on the bitcoin-dev forum discussing whether any testnet faucets would accept bech32m addresses directly. Although unsure, he mentioned that the same process works with testnet. It is noted that there are faucets that accept such addresses, including Bitcoin Faucet, but they require the use of a bech32 checksum instead of bech32m.Bitcoin Core users can create a taproot-capable wallet following several steps. Firstly, they need to have or create a descriptor wallet with descriptors=true using the createwallet RPC command. Secondly, they should import a taproot descriptor in the form "tr(KEY)", where KEY can be a tprv.../* or any other supported key expression. Thirdly, they can get a new address with addresstype=bech32m. It is mentioned that this process is currently somewhat cumbersome, especially prior to taproot activating on mainnet.To create a taproot-capable wallet in Bitcoin Core using the master branch, there are five steps involved. First, users should create a descriptor wallet using the command 'bitcoin-cli -signet -named createwallet wallet_name=descwallet descriptors=true load_on_startup=true'. Second, they need to get the associated bip32 tprv private key using 'TPRV=$(bitcoin-cli -rpcwallet=descwallet -signet listdescriptors true | jq '.descriptors | .[].desc' | sed 's/^.*(//;s/[)/].*//' | uniq | head -n1)'. Note that this step requires an updated version of bitcoin-cli due to PR#21500. Third, users should construct the taproot descriptor per BIP 86 using 'DESC="tr($TPRV/86'/1'/0'/0/*)"' and 'CHK="$(bitcoin-cli -rpcwallet=descwallet -signet getdescriptorinfo "$DESC" | jq -r .checksum)"'. Fourth, import the descriptor using 'bitcoin-cli -rpcwallet=descwallet -signet importdescriptors "[{\"desc\": \"$DESC#$CHK\", \"active\": true, \"timestamp\": \"now\", \"range\": [0,1000], \"next_index\": 1}]"'. Finally, get an address using 'bitcoin-cli -rpcwallet=descwallet -signet getnewaddress '' bech32m'.Andreas Schildbach via bitcoin-dev is trying to finish off bitcoinj's implementation for sending to taproot addresses. They are requesting a testnet wallet that can receive to P2TR and spend back in order to complete this task. Despite their efforts, they have been unable to obtain a taproot address from Bitcoin Core 22.0. Pieter has responded to Andreas' request by providing instructions on how to construct a taproot-capable wallet in Bitcoin Core. This involves having or creating a descriptor wallet with descriptors=true, importing a taproot descriptor (of the form "tr(KEY)") as active descriptor with active=true, where KEY can be a tprv.../* or any other supported key expression, and getting a new address with addresstype=bech32m. Pieter has also provided a taproot address for testing purposes: tb1p84x2ryuyfevgnlpnxt9f39gm7r68gwtvllxqe5w2n5ru00s9aquslzggwq. If testnet coins are sent there, Pieter has requested an email address to return them.The individual working on implementing bitcoinj's sending feature for taproot addresses is requesting a testnet wallet that can receive to P2TR and spend back. They have been unable to obtain a taproot address from Bitcoin Core 22.0 and are seeking assistance. They do not care about the safety of their testnet coins, so there is no need to worry about compromised private keys. diff --git a/static/bitcoin-dev/Oct_2021/combined_Wednesday-s-second-BIP-process-meeting.xml b/static/bitcoin-dev/Oct_2021/combined_Wednesday-s-second-BIP-process-meeting.xml index 94f7961342..1fabc928d8 100644 --- a/static/bitcoin-dev/Oct_2021/combined_Wednesday-s-second-BIP-process-meeting.xml +++ b/static/bitcoin-dev/Oct_2021/combined_Wednesday-s-second-BIP-process-meeting.xml @@ -2,7 +2,7 @@ 2 Combined summary - Wednesday’s second BIP process meeting - 2025-09-26T16:03:33.503502+00:00 + 2025-10-11T22:18:25.574571+00:00 python-feedgen Prayank 2021-10-06 04:02:55+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Wednesday’s second BIP process meeting - 2025-09-26T16:03:33.503692+00:00 + 2025-10-11T22:18:25.574744+00:00 2021-10-06T04:02:55+00:00 The recent BIP process meetings focused on various topics related to Bitcoin Improvement Proposals (BIPs). One of the main issues discussed was the concern about having too many BIPs of varying quality, similar to what Ethereum has experienced. Storing BIPs in multiple repositories was considered impractical as it would be difficult to monitor and maintain them all. The participants acknowledged the desire for greater decentralization but emphasized the importance of having a centralized repository for easier management.The discussions also touched upon the motivations behind introducing alternative parallel processes to the BIPs, such as BOLTs and SLIPs. While anyone is free to set up their own repositories or parallel processes, there was a need to prevent unnecessary splintering and ensure that important documents are properly BIPed. Concerns were raised about the absence of certain BIPs, like BIP 48, and whether Lightning BOLTs should be treated as BIPs in the future.Kalle Alm's proposal for BIP extensions received support from the participants, but further clarity on their usage was requested. It was suggested that using dates or short extension names instead of numbers would be more effective and avoid confusion.The participants agreed that further discussion should take place on the #bitcoin-dev Libera IRC channel. Progress is expected on an update to BIP 3 in the coming weeks and months. Efforts were made to increase participation in the meetings, including reaching out to Christopher and utilizing social media platforms.However, it was noted that influential developers who had previously advocated for decentralization were not present at the meetings, and there has been no follow-up on the mailing list. Decentralization was seen as necessary only in cases where there were issues with Luke Dashjr.Overall, the BIP process meetings provided valuable insights and highlighted the need for balancing decentralization with practicality. Further discussions and updates are anticipated in the near future. diff --git a/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml b/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml index 8846de7447..de31d6dd25 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Does-Bitcoin-require-or-have-an-honest-majority-or-a-rational-one-re-rbf-Jeremy-Rubin-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) - 2025-09-26T15:29:40.538755+00:00 + 2025-10-11T21:31:05.509808+00:00 python-feedgen Peter Todd 2022-10-20 22:52:03+00:00 @@ -18,10 +18,11 @@ + 2 Combined summary - Does Bitcoin require or have an honest majority or a rational one? (re rbf) (Jeremy Rubin) - 2025-09-26T15:29:40.538903+00:00 + 2025-10-11T21:31:05.509934+00:00 2022-10-20T22:52:03+00:00 John Carvalho expresses concerns about replace-by-fee (RBF) and its potential negative impact on Bitcoin transactions. Although only a small percentage of transactions currently use RBF, the risk it poses is immeasurable. Transactions can be replaced without warning, making it difficult for merchants to effectively monitor and enforce acceptance of zero-conf (0conf) transactions.Carvalho argues that responsible 0conf acceptance is rational and trusting, as it mitigates exposure to double-spends and limits their size per block. He suggests that occasional double-spending is less costly than experiencing delayed checkout processes. However, if the remaining 71% of transactions also become subject to replaceability, relying on ignoring the risk becomes an unsustainable approach.The fact remains that merchants cannot rely on having seen all transactions being considered by miners for their block templates, nor can they guarantee receiving replacements before the original transaction is included in a block. The unstable gentlemen's agreement of "first-seen" is bound to fail eventually. Additionally, propping up the illusion of reliable payment promises hampers price discovery of blockspace and complicates protocol development.To address this, the context proposes converging on the inevitable outcome and facilitating replaceability for all transactions. This would involve reassessing business approaches in light of Bitcoin's natural modus operandi and embracing the uncertainty of the gossip system. By doing so, the band-aid can be ripped off rather than perpetually suffering from uncertainty.Peter Todd counters Carvalho's concerns by highlighting the use of RBF in his OpenTimestamps calendars for optimal fee discovery. Replacements account for approximately 95% of OpenTimestamps transactions mined. Todd also notes that at least 97.21% of hashing power supports opt-in RBF. He questions whether this indicates that almost all hashing power is irrational.Todd further mentions that Electrum has implemented an undo button using RBF successfully. Additionally, rejecting blocks containing double-spends could lead to severe consensus problems, despite the fact that it should be implemented.In summary, the context delves into the debate surrounding 0conf acceptance and RBF assurances in Bitcoin transactions. Carvalho argues for responsible 0conf acceptance, highlighting the risks of RBF and the potential impact on merchants. Todd counters with examples of successful RBF implementations and questions the rationality of opposing its use. The context ultimately raises the question of which approach, preferring blocks with replaced transactions or rejecting them, is more likely for the node set. diff --git a/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml b/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml index 8c62942647..08cac94f98 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Ephemeral-Anchors-Fixing-V3-Package-RBF-againstpackage-limit-pinning.xml @@ -2,7 +2,7 @@ 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T15:29:34.181876+00:00 + 2025-10-11T21:30:59.132872+00:00 python-feedgen Greg Sanders 2023-03-13 16:38:25+00:00 @@ -82,10 +82,11 @@ + 2 Combined summary - Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning - 2025-09-26T15:29:34.182055+00:00 + 2025-10-11T21:30:59.133046+00:00 2023-03-13T16:38:25+00:00 On February 4th, 2023, Greg Sanders announced that he switched to OP_TRUE on the Bitcoin Improvement Proposal (BIP) and implementation after receiving negative feedback. In response to his announcement, Peter Todd thanked him and reviewed the updated tests for the OP_TRUE case, which were available on GitHub. Todd suggested that many of the test cases did not need to be changed to OP_2 as they were not related to standardness.In an email chain, Greg Sanders expresses his lack of persuasion towards certain ideas and mentions that he has fixed tests for the OP_TRUE case. He provides a link to the Github repo where the tests can be viewed. Another individual responds by saying that after looking through the tests, they believe that not all cases need to be changed to OP_2 as they are not related to standardness. The email thread ends with a signature attachment from Peter Todd, whose website is also linked in the email.The conversation between Greg Sanders and Peter Todd revolves around the use of OP_TRUE as the canonical anyone-can-spend output. While Sanders feels that OP_TRUE is the obvious way to do this, Todd believes that scripts should leave just a single OP_TRUE on the stack at the end of execution, in order to avoid malleability issues. Currently, this is not implemented as a rule. However, Todd suggests that using OP_TRUE as the canonical output would ensure adherence to this standardness rule and prevent the need for special-cased workarounds. Todd has also fixed up tests for the OP_TRUE case on Github.In an email exchange, Greg Sanders suggests using OP_TRUE as the canonical anyone-can-spend output to ensure scripts leave just a single OP_TRUE on the stack at the end of execution, reducing malleability in certain circumstances where scriptSig provides an OP_TRUE. He notes that although this isn't currently implemented as a rule, it could be in a future upgrade. Leaving an OP_2 on the stack wouldn't achieve this and would require a special-cased workaround. By using OP_TRUE, it plays better with other standardness rules and avoids potential issues.In a discussion involving Peter Todd and Greg Sanders regarding the use of OP_2 as a means to avoid changing unit tests in Bitcoin Core, Todd expressed his dislike for the idea, stating that it would result in unnecessarily obscure code. He suggested using OP_TRUE instead, which results in a 1 on the stack and plays better with other standardness rules. Todd also noted that the use of OP_2 may require special cases in certain implementations of other standardness rules. Sanders had previously checked the proposal and found that it fails several standardness tests in unit/functional tests in Bitcoin Core. It is unclear what other standardness rules are being referred to in the discussion.Greg Sanders reported that the use of OP_2 fails several standardness tests in Bitcoin Core. This idea was proposed by Luke Jr in 2017 and later arrived at by Sanders independently. However, the use of OP_2 seems unnecessarily obscure just to avoid changing some unit tests. There is a better way to do this using OP_TRUE which results in a 1 on the stack and plays better with other standardness rules. The use of OP_2 may require special cases in certain implementations of other standardness rules. Peter Todd's signature is attached to the email.The context is a discussion between Greg Sanders and Peter Todd regarding the standardness tests in unit/functional tests in Bitcoin Core. It is mentioned that OP_2 was an idea proposed by Luke Jr in 2017 for similar reasons and Greg arrived at the same conclusion independently. In response to Peter's question about changing test vectors, Greg clarifies that he would have to change tests that test something is non-standard. The context does not provide any further information or links to external sources.On January 27, 2023, Greg Sanders via bitcoin-dev proposed the Ephemeral Anchors idea and wrote up a short draft BIP, which can be found on Github. The pull request on Github has been refreshed on top of the latest V3 proposal, but the BIP itself remains unaffected. In response to the proposal, Peter Todd asked for clarification on why OP_2 is used instead of OP_TRUE, as OP_TRUE is often used in test vectors. Greg Sanders responded on February 2, 2023, stating that he had to change test vectors everywhere for principled reasons.On January 27th, 2023, Greg Sanders wrote a draft BIP of the Ephemeral Anchors idea and shared it with the bitcoin-dev community. The proposal can be found on Github at https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki. A pull request has also been made at https://github.com/bitcoin/bitcoin/pull/26403. The BIP suggests using OP_2 instead of OP_TRUE in test vectors to diff --git a/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 9b16ba77c2..90ca8e2936 100644 --- a/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Oct_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -2,7 +2,7 @@ 2 Combined summary - On a new community process to specify covenants - 2025-09-26T15:29:36.297707+00:00 + 2025-10-11T21:31:01.258800+00:00 python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -106,10 +106,11 @@ + 2 Combined summary - On a new community process to specify covenants - 2025-09-26T15:29:36.297874+00:00 + 2025-10-11T21:31:01.258979+00:00 2022-10-07T15:33:12+00:00 The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest diff --git a/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml b/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml index a20eee8776..0ef410c4c8 100644 --- a/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml +++ b/static/bitcoin-dev/Oct_2022/combined_On-mempool-policy-consistency.xml @@ -2,7 +2,7 @@ 2 Combined summary - On mempool policy consistency - 2025-09-26T15:29:29.953882+00:00 + 2025-10-11T21:30:54.882912+00:00 python-feedgen email at yancy.lol 2022-11-10 14:38:27+00:00 @@ -138,10 +138,11 @@ + 2 Combined summary - On mempool policy consistency - 2025-09-26T15:29:29.954060+00:00 + 2025-10-11T21:30:54.883095+00:00 2022-11-10T14:38:27+00:00 The discussion on the bitcoin-dev mailing list revolves around various attack vectors and issues related to transaction replacement in Bitcoin. One scenario involves Alice double-spending the same inputs at a low feerate, causing a stalemate where neither Bob nor Alice can spend the UTXOs. Another scenario sees Alice spamming the network with a double spend, beating out the alternative transaction before it is seen by the rest of the network.Opt-in RBF is suggested as a solution for the first scenario, allowing Bob to create a replacement transaction with a higher fee. However, opt-in RBF does not resolve the second scenario as Alice can still spam the network. Full-RBF, on the other hand, ensures that the higher fee-paying transaction replaces the lower fee one, regardless of who saw it first. There are limitations in the current mempool implementation that can make it difficult to evaluate which transaction pays the higher fee. However, these limitations are likely to be fixable, and even without fixing them, Alice would need more money to carry out attacks with full-RBF.The conversation also touches on the importance of incentivized predictability in designing protocols like Bitcoin. Full-RBF improves the situation by ensuring transaction replacement based on fees, but deeper network-wide predictability can have additional benefits that are not easily predicted.Another email thread discusses the implications of implementing a full-RBF policy for transaction replacement. The technicalities of how full-RBF transactions replace previous ones and the interplay between different mempool policies are discussed. While adding a full-RBF config flag may increase code complexity, it is considered worth accommodating both types of transaction policies.There is also a discussion about the limitations of opt-in RBF in preventing denial-of-service attacks in coinjoins, dual funding, and DLCs. The concern is raised that if Alice spams the network with an alternative transaction double-spending her input, it can cause problems for others who have already populated their mempool with the original transaction.The conversation also touches on the issue of biased views and the need for finding common ground in discussions about transaction policies. Different participants express their opinions, with some advocating for a world without zeroconf practices and others cautioning against imposing optional features that may affect existing use cases.Furthermore, there is a discussion about the design complexity and security concerns related to transaction-relay protocol developers. The paradigm of having specific policy rules for each use case is explored, but concerns are raised about potential interference between different sets of policy rules and discrepancies with miners' incentives.In addition, the article explores the benefits and feasibility of enabling full-RBF on the network. The author argues that while a maximal RBF policy might be useful, it currently faces limitations due to transaction relay and incentive compatibility issues. The idea of non-replacement policies and their potential benefits for certain use cases like zeroconf or fee bumping behavior is also discussed.Overall, the discussions highlight the challenges and considerations involved in transaction replacement and the need for further exploration and understanding of the implications of different policies in Bitcoin.---Bitcoin Core's transaction-relay propagation rules and mempool policies are being discussed in an email thread on the bitcoin-dev mailing list. The main goal of these policies is to relay transactions from users to miners and pre-validate and distribute block data throughout the network. However, there is a debate about whether a standard set of policy rules can satisfy all use cases.Some participants argue that allowing more heterogeneity in policy rules might be necessary for future Bitcoin Core development. They believe that a "one-size-fits-all" approach may not be ideal and that different use cases should be supported to improve the overall functionality of the network.The discussion also touches on the issue of transaction failure rates and how they can impact transaction propagation. It is suggested that a 5% failure rate may not be terrible if retries are easy and likely to succeed. However, finding an efficient and decentralized way to detect and rectify failures remains a challenge.Another topic of discussion is the adoption of more permissive policies by nodes and the implications for lightweight clients. It is estimated that if only 30% of nodes have a permissive policy, lightweight clients would need to connect to over 50 randomly selected nodes to ensure one transaction per year fails to propagate initially.Overall, the email thread explores various aspects of transaction-relay policies, including user choice, network safety, code complexity, and the potential impact on zero confirmation transactions and multiparty protocols. While there are differing opinions, the consensus seems to lean towards maintaining the current relay policy and allowing users to opt-in to replace-by-fee (RBF) rather than enforcing full RBF for all transactions.---In a recent discussion on the bitcoin-dev mailing list, there were debates surrounding policy rules and the need for clear design goals and principles for transaction-relay propagation rules. While decentralization, privacy, and efficiency remain important, it is acknowledged that advanced Bitcoin applications may require different policies targeted at specific use cases. The discussion also touched upon diff --git a/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml index 7d9d3b59f8..66f148b7cc 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Packaged-Transaction-Relay.xml @@ -2,7 +2,7 @@ 2 Combined summary - Packaged Transaction Relay - 2025-09-26T15:29:38.417333+00:00 + 2025-10-11T21:31:03.385614+00:00 python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -70,10 +70,11 @@ + 2 Combined summary - Packaged Transaction Relay - 2025-09-26T15:29:38.417519+00:00 + 2025-10-11T21:31:03.385806+00:00 2022-10-10T22:05:38+00:00 The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. diff --git a/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml b/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml index 6132e74098..17959508fa 100644 --- a/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml +++ b/static/bitcoin-dev/Oct_2022/combined_Trustless-Address-Server-Outsourcing-handing-out-addresses.xml @@ -2,7 +2,7 @@ 2 Combined summary - Trustless Address Server ? Outsourcing handing out addresses - 2025-09-26T15:29:32.066230+00:00 + 2025-10-11T21:30:57.008795+00:00 python-feedgen Ruben Somsen 2022-10-01 10:18:49+00:00 @@ -14,10 +14,11 @@ + 2 Combined summary - Trustless Address Server ? Outsourcing handing out addresses - 2025-09-26T15:29:32.066384+00:00 + 2025-10-11T21:30:57.008933+00:00 2022-10-01T10:18:49+00:00 In an email exchange on the bitcoin-dev mailing list, Ruben and Peter discussed various topics related to Bitcoin addresses. Ruben suggested that distributing xpubs could potentially reduce the gap limit for generated addresses since there would be less reason to expect a gap if those addresses are used by the same person. He shared a link to a related thread for further reference.Peter contributed to the discussion by highlighting some points worth considering. He mentioned that handing out xpubs can create a quadratic gap limit problem, where wallets need to scan multiple xpubs and their receive addresses. However, in the Lightning network, this issue can be avoided by utilizing Lightning addresses that employ plus addresses. This alternative approach proves to be effective in addressing the problem.Another topic of discussion was the need for an expiry date on layer 1 addresses to ensure that the receiver still possesses the corresponding keys. Peter pointed out that the Lightning network offers a solution to this concern as well.Furthermore, the conversation delved into the possibility of using a deterministic path that doesn't separate receive and change addresses. Satoshi's original wallet concept proposed an ever-growing key pool with a 100 address gap, which may serve as a potential solution to the gap limit problem.As the discussion continued, the idea of incorporating invoice functionality into wallets arose. This feature would allow wallets to issue fresh addresses even if they haven't been used, while also providing a configurable gap limit. Additionally, embedding a sunset date in the address format, similar to PGP keys, was suggested as a means to enable address expiry for layer 1 addresses.Overall, these discussions surrounding xpubs, invoice functionality, and address expiration are crucial considerations for businesses and individuals engaged in Bitcoin transactions. The Lightning network presents viable solutions to some of these concerns, and concepts such as an ever-growing key pool and configurable gap limits show promise in addressing the gap limit problem. diff --git a/static/bitcoin-dev/Oct_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml b/static/bitcoin-dev/Oct_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml index 913499522d..8fbce4a76e 100644 --- a/static/bitcoin-dev/Oct_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml +++ b/static/bitcoin-dev/Oct_2023/combined_OP-Expire-and-Coinbase-Like-Behavior-Making-HTLCs-Safer-by-Letting-Transactions-Expire-Safely.xml @@ -2,7 +2,7 @@ 2 Combined summary - OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely - 2025-09-26T14:22:21.526749+00:00 + 2025-10-11T21:40:13.939441+00:00 python-feedgen Peter Todd 2023-11-14 19:50:04+00:00 @@ -105,10 +105,11 @@ + 2 Combined summary - OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely - 2025-09-26T14:22:21.526909+00:00 + 2025-10-11T21:40:13.939649+00:00 2023-11-14T19:50:04+00:00 The discussion addresses technical challenges within the Lightning Network, such as managing outdated states and transaction fees. It is recognized that while security could be improved, keeping transaction fees to a minimum relative to the channel's total value is essential for economic viability. diff --git a/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-OP-CAT.xml b/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-OP-CAT.xml index b221233a94..84e09f7039 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-OP-CAT.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Proposed-BIP-for-OP-CAT.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposed BIP for OP_CAT - 2025-09-26T14:22:17.263896+00:00 + 2025-10-11T21:40:11.815361+00:00 python-feedgen Anthony Towns 2023-10-27 18:32:13+00:00 @@ -85,10 +85,11 @@ + 2 Combined summary - Proposed BIP for OP_CAT - 2025-09-26T14:22:17.264071+00:00 + 2025-10-11T21:40:11.815584+00:00 2023-10-27T18:32:13+00:00 The email introduces a draft BIP proposing the activation of the OP_CAT opcode in Bitcoin tapscript. The proposed opcode allows for the concatenation of two values on the stack, providing a general-purpose way to combine objects in tapscript. This enhances the functionality and expressiveness of tapscript, enabling the construction and evaluation of merkle trees and other hashed data structures. diff --git a/static/bitcoin-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml b/static/bitcoin-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml index 3f3869f53b..184ea66404 100644 --- a/static/bitcoin-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml +++ b/static/bitcoin-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml @@ -2,7 +2,7 @@ 2 Combined summary - Removing channel reserve for mobile wallet users - 2025-09-26T14:21:47.287672+00:00 + 2025-10-11T21:40:09.681142+00:00 python-feedgen ziggie 2023-10-24 09:12:19+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Removing channel reserve for mobile wallet users - 2025-09-26T14:21:47.287833+00:00 + 2025-10-11T21:40:09.681317+00:00 2023-10-24T09:12:19+00:00 The email discusses the review of an implementation called lnd and mentions that it currently checks that the reserve is at least the dust limit, which the sender finds reasonable. However, with the proposed protocol update, this requirement will need to be modified. The sender expresses anticipation for the Blip, which is likely a reference to an upcoming communication or announcement related to the protocol update. diff --git a/static/bitcoin-dev/Sept_2012/combined_Announcement-libcoin.xml b/static/bitcoin-dev/Sept_2012/combined_Announcement-libcoin.xml index 44beb990fa..52d97fc771 100644 --- a/static/bitcoin-dev/Sept_2012/combined_Announcement-libcoin.xml +++ b/static/bitcoin-dev/Sept_2012/combined_Announcement-libcoin.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.669593+00:00 + 2025-10-11T21:58:22.326541+00:00 + python-feedgen Martinx - ジェームズ 2012-09-12 23:27:32+00:00 @@ -207,13 +208,13 @@ - python-feedgen + 2 Combined summary - Announcement: libcoin - 2023-08-01T03:02:33.670592+00:00 + 2025-10-11T21:58:22.326743+00:00 - In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, 2012-09-12T23:27:32+00:00 + In the email thread, Michael Gronager discusses his Libcoin project with Thiago Martins. They talk about the possibility of making Libcoin the official Bitcoin and syncing it with the mainline Bitcoin. Thiago expresses interest in using Libcoin with P2Pool and integrating it into the Diaspora* Project. He asks for help regarding compiling libcoin and encounters an error related to a missing file. Martinx thanks Michael for creating libcoin but reports compatibility issues with compiling it under Ubuntu 11.04.Michael announces the release of libcoin, a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. He highlights its features such as being chain agnostic, having faster block chain downloads, and being a drop-in replacement for the bitcoin client. The build system of libcoin supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows using CMake. The license for libcoin is LGPL v. 3, allowing for use in both open source and commercial projects. Michael also provides support to Martinx for compiling libcoin and advises upgrading the boost library to avoid conflicts.Thiago seeks clarification on running multiple instances of bitcoind and encounters issues with default accounts not being listed. Michael suggests using btcd along with btc and upgrading the boost library to fix the issues. Thiago also mentions problems with authentication for certain commands. Michael explains that username and password need to be set up to access those commands.Throughout the conversation, contact information for Michael Gronager, including his name, address, mobile number, email id, and website link, is repeated. There is also contact information provided for Peter J. Vessenes, CEO of CoinLab, including his name and mobile number. Additionally, there is a sponsored advertisement for trying Windows Azure for free for 90 days and a link to subscribe/unsubscribe from the Bitcoin-development mailing list.Thiago reported an issue with the 'listaccounts' command in bitcoind, where his default account was missing from the output. Michael advised him to set up a username/password for accessing commands that require authentication and suggested upgrading the libboost-dev-all library to version 1.46.1.In another thread, Thiago encountered errors while compiling libcoin under Ubuntu 11.04. Michael recommended upgrading libboost-dev-all to resolve the issue.Michael announced the release of the libcoin cryptocurrency library, which is based on the bitcoin/bitcoin "Satoshi" client. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. The code has been refactored to encapsulate classes, remove globals, and adopt a pure asynchronous approach. Libcoin supports builds on Linux, Mac OS X, and Windows using CMake. The license is LGPL v. 3, allowing use in open-source and commercial projects.Thiago had trouble starting bitcoind on high ports, but Michael explained that a username/password needed to be set up to access those commands. Michael also provided contact information for further queries.Martinx faced difficulties compiling libcoin on Ubuntu 11.04, and Michael suggested upgrading the libboost-dev-all library. Martinx mentioned successfully compiling other cryptocurrencies from sources.Ceptacle released the first version of the libcoin cryptocurrency library, which is chain agnostic and maintains all chain-specific settings from a single class (Chain). It supports builds on multiple platforms and can be used for research and educational purposes. Michael's contact details and links to the libcoin wiki, Twitter page, and download page were provided.A new cryptocurrency library called libcoin, based on the Bitcoin client, has been released by Ceptacle. The libcoin/bitcoind client can be used on the same files and scripts as the bitcoin/bitcoind client without modification, offering a 100% compatible drop-in replacement. Additionally, the libcoin/bitcoind downloads the entire blockchain 3.5 times faster than the bitcoin/bitcoind client, taking less than 90 minutes on a modern laptop.The Satoshi client code in libcoin has been completely refactored, properly encapsulating classes and removing all globals, with functionalities divided into logical units and libraries. The build system is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. Libcoin is chain agnostic, meaning that all chain specific settings are maintained from a single class (Chain). It supports various chains, including Bitcoin, Testnet, Namecoin, Litecoin etc. The libcoin license is LGPL v. 3, meaning it can be used under both commercial and open-source licenses with improvements required to be fed back into the libcoin library.Ceptacle, the company behind libcoin, is a technology company based in Copenhagen, Denmark. The company is headed by Michael Gronager who serves as the Director. Ceptacle's official website is http://www.ceptacle.com/, - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2012/combined_Atomic-coin-swapping-.xml b/static/bitcoin-dev/Sept_2012/combined_Atomic-coin-swapping-.xml index 0004cc875a..3c75323c9f 100644 --- a/static/bitcoin-dev/Sept_2012/combined_Atomic-coin-swapping-.xml +++ b/static/bitcoin-dev/Sept_2012/combined_Atomic-coin-swapping-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Atomic coin swapping? - 2023-08-01T03:55:16.159184+00:00 + 2025-10-11T21:58:24.451752+00:00 + python-feedgen Jorge Timón 2012-09-22 18:24:45+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Atomic coin swapping? - 2023-08-01T03:55:16.160135+00:00 + 2025-10-11T21:58:24.451958+00:00 - On September 22, 2012, a discussion between Mike Hearn and Jeff Garzik took place regarding the signing of input scripts in Bitcoin transactions. Hearn pointed out that signing input scripts would render it impossible to construct a transaction because signatures cannot sign themselves. He further explained that including scriptSigs in the signed data would result in the newly calculated signature for one input breaking the signatures for all others. Garzik acknowledged that he was missing the crucial piece, SIGHASH_ALL, and updated his post with a concrete example to recreate it. In an email conversation on the same day, Jorge Timón expressed interest in transitive/multi-hop transactions using Ripple and colored coins. He wondered why this was not possible. Garzik responded, stating that the missing piece for achieving such transactions was SIGHASH_ALL. He then updated his post with a detailed example and instructions for programmers to recreate it. Garzik, the founder of exMULTI, Inc., is actively involved in addressing these issues.The context explains why signing input scripts in Bitcoin transactions is not feasible. Signatures cannot sign themselves, and including scriptSigs in the signed data would disrupt the signatures for other inputs. Therefore, signing input scripts along with the rest of the transaction data is not possible.In the email conversation, Timón expresses interest in transitive/multi-hop transactions with colored coins and questions the inability to sign input scripts. Garzik responds by highlighting the need for a new SIGHASH_* type to achieve their goals. He also presents a problem he is working on involving the atomic transfer of coins between two parties with approval from both parties. Garzik wonders if this can be done within the current bitcoin system and suggests that a new SIGHASH_* type may be necessary.Garzik mentions colored coins and their potential use in distributed bonds in a forum post on Bitcointalk. He discusses a specific problem involving the transfer of a 1-satoshi colored coin from Alice to Bob, followed by a transfer of 100 BTC from Bob to Alice. These steps must occur as an atomic unit, requiring both parties to approve the transfer through appropriate signatures. Garzik questions the possibility of achieving this within the current bitcoin system and proposes the need for a new SIGHASH_* type. He provides links to further information on colored coins and distributed bonds and mentions his pursuit of pybond to address this issue. 2012-09-22T18:24:45+00:00 + On September 22, 2012, a discussion between Mike Hearn and Jeff Garzik took place regarding the signing of input scripts in Bitcoin transactions. Hearn pointed out that signing input scripts would render it impossible to construct a transaction because signatures cannot sign themselves. He further explained that including scriptSigs in the signed data would result in the newly calculated signature for one input breaking the signatures for all others. Garzik acknowledged that he was missing the crucial piece, SIGHASH_ALL, and updated his post with a concrete example to recreate it. In an email conversation on the same day, Jorge Timón expressed interest in transitive/multi-hop transactions using Ripple and colored coins. He wondered why this was not possible. Garzik responded, stating that the missing piece for achieving such transactions was SIGHASH_ALL. He then updated his post with a detailed example and instructions for programmers to recreate it. Garzik, the founder of exMULTI, Inc., is actively involved in addressing these issues.The context explains why signing input scripts in Bitcoin transactions is not feasible. Signatures cannot sign themselves, and including scriptSigs in the signed data would disrupt the signatures for other inputs. Therefore, signing input scripts along with the rest of the transaction data is not possible.In the email conversation, Timón expresses interest in transitive/multi-hop transactions with colored coins and questions the inability to sign input scripts. Garzik responds by highlighting the need for a new SIGHASH_* type to achieve their goals. He also presents a problem he is working on involving the atomic transfer of coins between two parties with approval from both parties. Garzik wonders if this can be done within the current bitcoin system and suggests that a new SIGHASH_* type may be necessary.Garzik mentions colored coins and their potential use in distributed bonds in a forum post on Bitcointalk. He discusses a specific problem involving the transfer of a 1-satoshi colored coin from Alice to Bob, followed by a transfer of 100 BTC from Bob to Alice. These steps must occur as an atomic unit, requiring both parties to approve the transfer through appropriate signatures. Garzik questions the possibility of achieving this within the current bitcoin system and proposes the need for a new SIGHASH_* type. He provides links to further information on colored coins and distributed bonds and mentions his pursuit of pybond to address this issue. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2012/combined_Bitcoin-Testing-Project.xml b/static/bitcoin-dev/Sept_2012/combined_Bitcoin-Testing-Project.xml index 49d323946e..70b8e38944 100644 --- a/static/bitcoin-dev/Sept_2012/combined_Bitcoin-Testing-Project.xml +++ b/static/bitcoin-dev/Sept_2012/combined_Bitcoin-Testing-Project.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Testing Project - 2023-08-01T03:56:40.402090+00:00 + 2025-10-11T21:58:15.956761+00:00 + python-feedgen Arklan Uth Oslin 2012-10-03 16:11:39+00:00 @@ -107,13 +108,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Testing Project - 2023-08-01T03:56:40.402090+00:00 + 2025-10-11T21:58:15.956958+00:00 - Steve, a Bitcoin developer, is looking to create a QA environment that will enhance testing and allow testers to excel. He believes that Git is too developer-centric for organizing testing, but acknowledges its compatibility with a large amount of software. The linking between bugs, requirements, fixes, re-tests, and regression test plans is deemed vital. Steve also mentions the need to organize testing campaigns, assign tests, work units, and relevant documentation/scripts/ideas.Currently, there are four potential places to report bugs - Jenkins (and unit tests), Git, the mailing list, and forums such as Bitcointalk. However, Github has become the authoritative place to report issues. Failed tests are reported on Github by the pull tester. There are currently 232 issues on Github, classified into categories like "Bug," "Improvement," "GUI," and "Wallet." Github issues can be easily referred to in commits using #123 with automatic linking. While other bug reporting systems may exist, Wladimir, another Bitcoin developer, does not see the value in switching to another system.In an email, Steve expresses his desire to shift away from Bettermeans and focus on test-driven development with a strong emphasis on requirements management and automation. He has been developing rudimentary requirement sets, basic requirement tracking, and stress tests to prove the requirements. Steve has installed open-source applications like Mantis, SalomeTMF, and Bugzilla to evaluate the best workflow process. He is finalizing workflow flow diagrams and welcomes anyone interested in helping or reviewing the processes to reach out via email.In September 2012, Wladimir and Daniel F discuss the addition of a developer resources page to bitcoin.org. Wladimir agrees to write the page, which would link to an editable and expandable wiki page for developer resources. They decide that adding a direct link to the developer resources page on the main site makes sense since the front page already has wiki links.On September 26th, 2012, Wladimir proposes creating a page on bitcoin.org that would link to a wiki page of developer resources. He acknowledges the potential for disagreement but suggests being pragmatic. This separate page would provide an easy link from the main site while still allowing for editable and expandable content.Bitcoin developer Matt Corallo discusses the usefulness of pulltester and Jenkins, stating that both run the same set of scripts. He suggests keeping them and improving if necessary. Corallo also proposes creating a page that links all the developer resources for Bitcoin development, including information on checking out the source code, contribution guidelines, where to ask development problems, and which bugs to solve first. While willing to write this page, he acknowledges that it may spark discussions about what should be included on bitcoin.org.In another email, Steve requests help with reviewing processes or even just encouragement. Another person responds, expressing limited availability but providing encouragement and emphasizing the importance of more testing. The email thread includes a promotional message for a Live Security Virtual Conference covering endpoint security, mobile security, and malware threats. It also mentions the Bitcoin-development mailing list.Overall, the discussion revolves around testing tools and methodologies in the context of Bitcoin development. Steve is seeking to create a conducive QA environment, while Wladimir and Daniel F discuss adding a developer resources page to bitcoin.org. Matt Corallo emphasizes the usefulness of pulltester and Jenkins and proposes linking all developer resources. The emails highlight the importance of testing and invite assistance and reviews from interested parties. 2012-10-03T16:11:39+00:00 + Steve, a Bitcoin developer, is looking to create a QA environment that will enhance testing and allow testers to excel. He believes that Git is too developer-centric for organizing testing, but acknowledges its compatibility with a large amount of software. The linking between bugs, requirements, fixes, re-tests, and regression test plans is deemed vital. Steve also mentions the need to organize testing campaigns, assign tests, work units, and relevant documentation/scripts/ideas.Currently, there are four potential places to report bugs - Jenkins (and unit tests), Git, the mailing list, and forums such as Bitcointalk. However, Github has become the authoritative place to report issues. Failed tests are reported on Github by the pull tester. There are currently 232 issues on Github, classified into categories like "Bug," "Improvement," "GUI," and "Wallet." Github issues can be easily referred to in commits using #123 with automatic linking. While other bug reporting systems may exist, Wladimir, another Bitcoin developer, does not see the value in switching to another system.In an email, Steve expresses his desire to shift away from Bettermeans and focus on test-driven development with a strong emphasis on requirements management and automation. He has been developing rudimentary requirement sets, basic requirement tracking, and stress tests to prove the requirements. Steve has installed open-source applications like Mantis, SalomeTMF, and Bugzilla to evaluate the best workflow process. He is finalizing workflow flow diagrams and welcomes anyone interested in helping or reviewing the processes to reach out via email.In September 2012, Wladimir and Daniel F discuss the addition of a developer resources page to bitcoin.org. Wladimir agrees to write the page, which would link to an editable and expandable wiki page for developer resources. They decide that adding a direct link to the developer resources page on the main site makes sense since the front page already has wiki links.On September 26th, 2012, Wladimir proposes creating a page on bitcoin.org that would link to a wiki page of developer resources. He acknowledges the potential for disagreement but suggests being pragmatic. This separate page would provide an easy link from the main site while still allowing for editable and expandable content.Bitcoin developer Matt Corallo discusses the usefulness of pulltester and Jenkins, stating that both run the same set of scripts. He suggests keeping them and improving if necessary. Corallo also proposes creating a page that links all the developer resources for Bitcoin development, including information on checking out the source code, contribution guidelines, where to ask development problems, and which bugs to solve first. While willing to write this page, he acknowledges that it may spark discussions about what should be included on bitcoin.org.In another email, Steve requests help with reviewing processes or even just encouragement. Another person responds, expressing limited availability but providing encouragement and emphasizing the importance of more testing. The email thread includes a promotional message for a Live Security Virtual Conference covering endpoint security, mobile security, and malware threats. It also mentions the Bitcoin-development mailing list.Overall, the discussion revolves around testing tools and methodologies in the context of Bitcoin development. Steve is seeking to create a conducive QA environment, while Wladimir and Daniel F discuss adding a developer resources page to bitcoin.org. Matt Corallo emphasizes the usefulness of pulltester and Jenkins and proposes linking all developer resources. The emails highlight the importance of testing and invite assistance and reviews from interested parties. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2012/combined_Large-backlog-of-transactions-building-up-.xml b/static/bitcoin-dev/Sept_2012/combined_Large-backlog-of-transactions-building-up-.xml index 2e4c7817c7..ad60a18c30 100644 --- a/static/bitcoin-dev/Sept_2012/combined_Large-backlog-of-transactions-building-up-.xml +++ b/static/bitcoin-dev/Sept_2012/combined_Large-backlog-of-transactions-building-up-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Large backlog of transactions building up? - 2023-08-01T03:55:35.411086+00:00 + 2025-10-11T21:58:20.203815+00:00 + python-feedgen Gregory Maxwell 2012-09-25 17:52:10+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Large backlog of transactions building up? - 2023-08-01T03:55:35.411086+00:00 + 2025-10-11T21:58:20.203980+00:00 - In a discussion between Jorge Timón, Jeff Garzik, and Gregory Maxwell, the focus is on transactions that have not yet been included in the blockchain. Garzik suggests implementing a deterministic lifetime for transactions to initiate recovery procedures and prevent "zombie" transactions from wasting resources without confirmation. However, Timón questions whether the chain can enforce this and why clients cannot delete these transactions.Maxwell explains that there are bursts of unusual transactions flooding the network, which some miners intentionally exclude. He also mentions that double-spending transactions are not stored, resulting in large chains. These transactions rely on their parent, which is dropped due to rule violations. The software keeps them as orphans until their parent arrives. Maxwell proposes maintaining a cache of rejected transaction IDs to consult for orphan transactions' parents, but it would need to be dropped during reorganizations.Garzik and Maxwell further discuss the issue of mempool size and the disconnect between what miners mine and what relayers relay. Garzik's public nodes currently have over 2200 pending transactions in their mempool, leading to clutter over time. Burst of weird transactions, double-spends, and sustained loads are intentionally excluded by many miners. They agree that a patch and a consensus on a specific number are needed to address this issue.In a mailing list, Mike Hearn expresses his concern about the increasing number of pending transactions that do not get cleared into blocks. He asks if anyone has long-term logs containing the pool size and timestamps to track this trend. Hearn realizes that they forgot to enable timestamps in their own nodes' logs, making it difficult to analyze the situation. They report having one node with 4000 transactions in the mempool, while only a few hundred are being cleared in blocks despite current transaction rates.Jeff Garzik also acknowledges the high number of pending transactions in his public nodes, suggesting that all mempool implementations should limit the lifetime of a transaction to a specific number of blocks. He provides reasons for this, including retransmission by bitcoin clients, the need for a deterministic lifetime for recovery procedures, and preventing zombie transactions from occupying memory without confirmation. Garzik believes that there is no strong opposition to these points and proposes writing a patch and establishing a consensus on an appropriate number for the network.Overall, the discussion revolves around the challenges posed by unconfirmed transactions, bursts of unusual transactions, mempool size, and the need for implementing measures to prevent resource wastage and improve transaction confirmation efficiency. 2012-09-25T17:52:10+00:00 + In a discussion between Jorge Timón, Jeff Garzik, and Gregory Maxwell, the focus is on transactions that have not yet been included in the blockchain. Garzik suggests implementing a deterministic lifetime for transactions to initiate recovery procedures and prevent "zombie" transactions from wasting resources without confirmation. However, Timón questions whether the chain can enforce this and why clients cannot delete these transactions.Maxwell explains that there are bursts of unusual transactions flooding the network, which some miners intentionally exclude. He also mentions that double-spending transactions are not stored, resulting in large chains. These transactions rely on their parent, which is dropped due to rule violations. The software keeps them as orphans until their parent arrives. Maxwell proposes maintaining a cache of rejected transaction IDs to consult for orphan transactions' parents, but it would need to be dropped during reorganizations.Garzik and Maxwell further discuss the issue of mempool size and the disconnect between what miners mine and what relayers relay. Garzik's public nodes currently have over 2200 pending transactions in their mempool, leading to clutter over time. Burst of weird transactions, double-spends, and sustained loads are intentionally excluded by many miners. They agree that a patch and a consensus on a specific number are needed to address this issue.In a mailing list, Mike Hearn expresses his concern about the increasing number of pending transactions that do not get cleared into blocks. He asks if anyone has long-term logs containing the pool size and timestamps to track this trend. Hearn realizes that they forgot to enable timestamps in their own nodes' logs, making it difficult to analyze the situation. They report having one node with 4000 transactions in the mempool, while only a few hundred are being cleared in blocks despite current transaction rates.Jeff Garzik also acknowledges the high number of pending transactions in his public nodes, suggesting that all mempool implementations should limit the lifetime of a transaction to a specific number of blocks. He provides reasons for this, including retransmission by bitcoin clients, the need for a deterministic lifetime for recovery procedures, and preventing zombie transactions from occupying memory without confirmation. Garzik believes that there is no strong opposition to these points and proposes writing a patch and establishing a consensus on an appropriate number for the network.Overall, the discussion revolves around the challenges posed by unconfirmed transactions, bursts of unusual transactions, mempool size, and the need for implementing measures to prevent resource wastage and improve transaction confirmation efficiency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2012/combined_Segmented-Block-Relaying-BIP-draft-.xml b/static/bitcoin-dev/Sept_2012/combined_Segmented-Block-Relaying-BIP-draft-.xml index 2fd598db0b..972d9c9817 100644 --- a/static/bitcoin-dev/Sept_2012/combined_Segmented-Block-Relaying-BIP-draft-.xml +++ b/static/bitcoin-dev/Sept_2012/combined_Segmented-Block-Relaying-BIP-draft-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Segmented Block Relaying BIP draft. - 2023-08-01T03:54:30.781205+00:00 + 2025-10-11T21:58:13.830468+00:00 + python-feedgen Matthew Mitchell 2012-09-13 20:24:35+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Segmented Block Relaying BIP draft. - 2023-08-01T03:54:30.781205+00:00 + 2025-10-11T21:58:13.830617+00:00 - The email discussions revolve around proposals and discussions related to block downloads, Merkle trees, and the scalability of Bitcoin. One proposal suggests parallelizing block downloads by requesting level-3 hashes and downloading transactions from different peers. This is compared to another suggestion of fetching the entire txid list first and then downloading unknown transactions. The use of Merkle trees in Bitcoin is mentioned as a way to validate segments of a block and save data transfer. It is clarified that only the level for segment roots needs to be downloaded. The importance of Merkle trees in verifying data integrity and belonging to a set is emphasized.There is a disagreement between Gregory Maxwell and Matthew Mitchell on the usefulness of using tree levels in Bitcoin. Gregory questions the value of obtaining a particular tree level, while Matthew argues that it allows for verifying segments without downloading all transaction hashes. The discussion also touches on the importance of Bloom filtering and the potential impact of proposed changes on decentralization and mining economics.Another email conversation involves Gregory questioning the value of reducing the size of bitcoin transactions by removing inventory vectors. He suggests using off-chain transactions instead. The conversation also covers Open Transactions, Ripple, and the strengths and limitations of Bitcoin, Open Transactions, and Ripple.In another email exchange, proposals are made to simplify the protocol for downloading Bitcoin transactions and allow requests for any level of the Merkle tree. The concerns about block size, scarcity, fees, and the economic motivation for mining are discussed. There is a recommendation to discuss these issues well in advance to avoid potential problems. The writer suggests a simpler protocol for Bitcoin transactions and raises questions about the block size limit. They express concerns about large fees deterring transactions and recommend discussing these issues ahead of time to prevent last-minute complications.In 2012, Matt Corallo discusses the idea of segmenting blocks but concludes that it would add little value unless block sizes were unrealistically large. He argues against removing the block size cap, citing the compromise of economic promises and network security. He believes that a simpler design is more prudent for Bitcoin.In another message thread from 2012, Matthew Mitchell expresses skepticism about segmenting blocks to improve block relay times. He argues that it wouldn't make a significant difference unless block sizes were exceptionally large. Luke-Jr suggests that improving block propagation lies more in implementation than protocol. The discussion also mentions the need for further research on the benefits and costs of distributing missing transactions.Overall, the email discussions cover various proposals, disagreements, and concerns related to block downloads, Merkle trees, scalability, and the future of Bitcoin. On September 10, 2012, Matthew Mitchell proposed a draft for improving the block relaying and validation in Bitcoin's blockchain. The aim was to do it in parallel and eliminate redundancy, which would be more beneficial for larger block sizes. He shared a link to his proposal on the Bitcoin Wiki page. However, according to one response, most of the problem with block propagation lies in implementation rather than protocol.The discussion revolves around the addition of six new messages in the Bitcoin protocol. Two of them, getseginv and seginv, help in learning about the segments of a block that a node has. The other two, gettreelevel and treelevel, are used to receive a level of the merkle tree. The remaining two, getsegment and segment, allow nodes to download arbitrary segments of blocks. These messages enable nodes to relay segments of blocks before receiving the entire block, which was not possible previously.It is suggested that distributing missing transactions on an as-needed basis could be a possible improvement at the protocol level. However, there has been no research on this yet. The number of segments could be calculated by node software using measurements of download speeds, latency times, the number of connections, and how likely redundancy is to occur.In a discussion on Bitcoin development, Matthew Mitchell shared a branch with his implementation of parts of the header+ v stuff in conjunction with his bloom filter stuff. He admits that it is pretty simple and susceptible to issues like getting stuck or DoS attacks, but in theory, it works. Gregory Maxwell responded to Mitchell's proposal for improving block relaying and validation by asking why it focuses on sending the hash tree when the block header, transaction list, and transactions a node doesn't already know (usually just the coinbase) are sufficient.Lastly, the Bitcointalk topic related to this discussion is mentioned. A BIP draft has been created by Matthew Mitchell proposing a solution to improve block relaying and validation in Bitcoin. The proposal suggests that block relaying and validation can be done in parallel, which will remove redundancy. This approach is particularly beneficial for larger block sizes. The draft can be found on the Bitcoin wiki page. 2012-09-13T20:24:35+00:00 + The email discussions revolve around proposals and discussions related to block downloads, Merkle trees, and the scalability of Bitcoin. One proposal suggests parallelizing block downloads by requesting level-3 hashes and downloading transactions from different peers. This is compared to another suggestion of fetching the entire txid list first and then downloading unknown transactions. The use of Merkle trees in Bitcoin is mentioned as a way to validate segments of a block and save data transfer. It is clarified that only the level for segment roots needs to be downloaded. The importance of Merkle trees in verifying data integrity and belonging to a set is emphasized.There is a disagreement between Gregory Maxwell and Matthew Mitchell on the usefulness of using tree levels in Bitcoin. Gregory questions the value of obtaining a particular tree level, while Matthew argues that it allows for verifying segments without downloading all transaction hashes. The discussion also touches on the importance of Bloom filtering and the potential impact of proposed changes on decentralization and mining economics.Another email conversation involves Gregory questioning the value of reducing the size of bitcoin transactions by removing inventory vectors. He suggests using off-chain transactions instead. The conversation also covers Open Transactions, Ripple, and the strengths and limitations of Bitcoin, Open Transactions, and Ripple.In another email exchange, proposals are made to simplify the protocol for downloading Bitcoin transactions and allow requests for any level of the Merkle tree. The concerns about block size, scarcity, fees, and the economic motivation for mining are discussed. There is a recommendation to discuss these issues well in advance to avoid potential problems. The writer suggests a simpler protocol for Bitcoin transactions and raises questions about the block size limit. They express concerns about large fees deterring transactions and recommend discussing these issues ahead of time to prevent last-minute complications.In 2012, Matt Corallo discusses the idea of segmenting blocks but concludes that it would add little value unless block sizes were unrealistically large. He argues against removing the block size cap, citing the compromise of economic promises and network security. He believes that a simpler design is more prudent for Bitcoin.In another message thread from 2012, Matthew Mitchell expresses skepticism about segmenting blocks to improve block relay times. He argues that it wouldn't make a significant difference unless block sizes were exceptionally large. Luke-Jr suggests that improving block propagation lies more in implementation than protocol. The discussion also mentions the need for further research on the benefits and costs of distributing missing transactions.Overall, the email discussions cover various proposals, disagreements, and concerns related to block downloads, Merkle trees, scalability, and the future of Bitcoin. On September 10, 2012, Matthew Mitchell proposed a draft for improving the block relaying and validation in Bitcoin's blockchain. The aim was to do it in parallel and eliminate redundancy, which would be more beneficial for larger block sizes. He shared a link to his proposal on the Bitcoin Wiki page. However, according to one response, most of the problem with block propagation lies in implementation rather than protocol.The discussion revolves around the addition of six new messages in the Bitcoin protocol. Two of them, getseginv and seginv, help in learning about the segments of a block that a node has. The other two, gettreelevel and treelevel, are used to receive a level of the merkle tree. The remaining two, getsegment and segment, allow nodes to download arbitrary segments of blocks. These messages enable nodes to relay segments of blocks before receiving the entire block, which was not possible previously.It is suggested that distributing missing transactions on an as-needed basis could be a possible improvement at the protocol level. However, there has been no research on this yet. The number of segments could be calculated by node software using measurements of download speeds, latency times, the number of connections, and how likely redundancy is to occur.In a discussion on Bitcoin development, Matthew Mitchell shared a branch with his implementation of parts of the header+ v stuff in conjunction with his bloom filter stuff. He admits that it is pretty simple and susceptible to issues like getting stuck or DoS attacks, but in theory, it works. Gregory Maxwell responded to Mitchell's proposal for improving block relaying and validation by asking why it focuses on sending the hash tree when the block header, transaction list, and transactions a node doesn't already know (usually just the coinbase) are sufficient.Lastly, the Bitcointalk topic related to this discussion is mentioned. A BIP draft has been created by Matthew Mitchell proposing a solution to improve block relaying and validation in Bitcoin. The proposal suggests that block relaying and validation can be done in parallel, which will remove redundancy. This approach is particularly beneficial for larger block sizes. The draft can be found on the Bitcoin wiki page. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2012/combined_separate-out-blockchain-db-and-wallet-to-two-dirs-.xml b/static/bitcoin-dev/Sept_2012/combined_separate-out-blockchain-db-and-wallet-to-two-dirs-.xml index 0edcfd291f..b05d933d80 100644 --- a/static/bitcoin-dev/Sept_2012/combined_separate-out-blockchain-db-and-wallet-to-two-dirs-.xml +++ b/static/bitcoin-dev/Sept_2012/combined_separate-out-blockchain-db-and-wallet-to-two-dirs-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - separate out blockchain db and wallet to two dirs? - 2023-08-01T03:54:57.619149+00:00 + 2025-10-11T21:58:18.080856+00:00 + python-feedgen Jeff Garzik 2012-09-14 07:40:55+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - separate out blockchain db and wallet to two dirs? - 2023-08-01T03:54:57.619149+00:00 + 2025-10-11T21:58:18.081038+00:00 - In an email conversation between Wladimir and Jeff Garzik on September 14, 2012, it was discussed that the current limitations with BerkelyDB prevent the feasibility of having multiple wallets within one 'environment'. The databases are all located in one directory, but the introduction of LevelDB and a custom format for the wallets will make it possible to have multiple wallets or a wallet in the block chain in separate directories. This feature is frequently requested but constrained by the database at the moment.Scott Howard and Wladimir had an email thread where a proposal was made to move the >2 GB db to $HOME/.cache/bitcoin while keeping the wallet and other config files in $HOME/.bitcoin. The reasoning behind this proposal is to allow backups to skip the .cache directory and align with the freedesktop.org XDG Base Directory Specification. However, due to BerkelyDB limitations, this proposal is currently not feasible as all the databases are within one 'environment' which is a single directory. It was suggested that with the introduction of LevelDB for the block chain and a custom format for wallets, new configurations such as multiple wallets and wallets in block chain in separate directories will be possible.The Linux systems primarily follow the Filesystem Hierarchy Standard (FHS), which can be modified by different distributions. On the other hand, BSD systems usually adhere to the traditional hierarchy and may add directories like /home and /opt as needed. The choice between these approaches is left to the user. Since Bitcoin is not an X app and does not have a user-agnostic system daemon for processing blocks separately from user wallet operations, it is recommended that until a solution is found, the files remain split up somewhere under .bitcoin rather than in /var or elsewhere. The author also jokingly seeks assistance in determining where to place their messages, indicating some confusion about the file system hierarchy.A suggestion to place the blockchain in /var/lib/bitcoin by default is made by a longtime Linux user, although they acknowledge not being a formal sysadmin. However, due to the lack of easy separation of files without detachdb and the absence of a user-agnostic system daemon, it is advised to keep the blockchain split up under .bitcoin for now instead of placing it in /var or any other location.In an email thread from September 14, 2012, grarpamp proposes creating a feature ticket to address the sysadmin problem related to the blockchain. It is recommended to avoid hardcoding paths and instead make all paths specifiable in Bitcoin's config file, with the location itself specifiable on the command line. Peter Vessenes agrees with this idea and suggests that the blockchain should be placed in /var/lib/bitcoin by default. He clarifies that he is not a formal sysadmin but has extensive experience with Linux. The email thread concludes with Peter providing his contact information as CEO of CoinLab.To address the sysadmin issue mentioned, it is suggested to create a feature ticket on Github. It is important to note that XDGBDS is not considered canonical, and hardcoding paths should be avoided. Instead, all paths can be specified in the Bitcoin config file, and the location of the config file itself can be specified on the command line.A Debian user has proposed moving the >2 GB db to $HOME/.cache/bitcoin while keeping the wallet and other config files in $HOME/.bitcoin. This would enable backups to skip the .cache directory and adhere to the freedesktop.org XDG Base Directory Specification. Personal information and settings would remain in .bitcoin/, while everything that can be rebuilt would be stored in .cache/bitcoin/. The proposal is open for consideration and feedback from the Bitcoin community. 2012-09-14T07:40:55+00:00 + In an email conversation between Wladimir and Jeff Garzik on September 14, 2012, it was discussed that the current limitations with BerkelyDB prevent the feasibility of having multiple wallets within one 'environment'. The databases are all located in one directory, but the introduction of LevelDB and a custom format for the wallets will make it possible to have multiple wallets or a wallet in the block chain in separate directories. This feature is frequently requested but constrained by the database at the moment.Scott Howard and Wladimir had an email thread where a proposal was made to move the >2 GB db to $HOME/.cache/bitcoin while keeping the wallet and other config files in $HOME/.bitcoin. The reasoning behind this proposal is to allow backups to skip the .cache directory and align with the freedesktop.org XDG Base Directory Specification. However, due to BerkelyDB limitations, this proposal is currently not feasible as all the databases are within one 'environment' which is a single directory. It was suggested that with the introduction of LevelDB for the block chain and a custom format for wallets, new configurations such as multiple wallets and wallets in block chain in separate directories will be possible.The Linux systems primarily follow the Filesystem Hierarchy Standard (FHS), which can be modified by different distributions. On the other hand, BSD systems usually adhere to the traditional hierarchy and may add directories like /home and /opt as needed. The choice between these approaches is left to the user. Since Bitcoin is not an X app and does not have a user-agnostic system daemon for processing blocks separately from user wallet operations, it is recommended that until a solution is found, the files remain split up somewhere under .bitcoin rather than in /var or elsewhere. The author also jokingly seeks assistance in determining where to place their messages, indicating some confusion about the file system hierarchy.A suggestion to place the blockchain in /var/lib/bitcoin by default is made by a longtime Linux user, although they acknowledge not being a formal sysadmin. However, due to the lack of easy separation of files without detachdb and the absence of a user-agnostic system daemon, it is advised to keep the blockchain split up under .bitcoin for now instead of placing it in /var or any other location.In an email thread from September 14, 2012, grarpamp proposes creating a feature ticket to address the sysadmin problem related to the blockchain. It is recommended to avoid hardcoding paths and instead make all paths specifiable in Bitcoin's config file, with the location itself specifiable on the command line. Peter Vessenes agrees with this idea and suggests that the blockchain should be placed in /var/lib/bitcoin by default. He clarifies that he is not a formal sysadmin but has extensive experience with Linux. The email thread concludes with Peter providing his contact information as CEO of CoinLab.To address the sysadmin issue mentioned, it is suggested to create a feature ticket on Github. It is important to note that XDGBDS is not considered canonical, and hardcoding paths should be avoided. Instead, all paths can be specified in the Bitcoin config file, and the location of the config file itself can be specified on the command line.A Debian user has proposed moving the >2 GB db to $HOME/.cache/bitcoin while keeping the wallet and other config files in $HOME/.bitcoin. This would enable backups to skip the .cache directory and adhere to the freedesktop.org XDG Base Directory Specification. Personal information and settings would remain in .bitcoin/, while everything that can be rebuilt would be stored in .cache/bitcoin/. The proposal is open for consideration and feedback from the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_An-app-store-and-non-network-transaction-fees.xml b/static/bitcoin-dev/Sept_2013/combined_An-app-store-and-non-network-transaction-fees.xml index d49332357b..b7ccb52473 100644 --- a/static/bitcoin-dev/Sept_2013/combined_An-app-store-and-non-network-transaction-fees.xml +++ b/static/bitcoin-dev/Sept_2013/combined_An-app-store-and-non-network-transaction-fees.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - An "app store" and non-network transaction fees - 2023-08-01T05:52:22.255329+00:00 + Combined summary - An "app store" and non-network transaction fees + 2025-10-11T22:11:01.402229+00:00 + python-feedgen Wendell 2013-10-18 11:56:09+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 - Combined summary - An "app store" and non-network transaction fees - 2023-08-01T05:52:22.255329+00:00 + Combined summary - An "app store" and non-network transaction fees + 2025-10-11T22:11:01.402379+00:00 - A v1 API for managing pledges using Bitcoin has been released. The announcement was made by Wendell on the BitcoinTalk forum, stating that there are currently no fees and only basic features available. Mike Hearn expressed interest in the idea. Contact information for grabhive.com, Twitter, and a GPG key were provided.To use Bitcoin for managing pledges, people can either use a dedicated app or a wallet with the right features. Each option has its own pros and cons. bitcoinj makes it easy to create a new GUI wallet app written in Java. Programming contracts can be done through the link provided for Working With Contracts on the bitcoinj wiki.On Sep 5, 2013, Mike Hearn and Wendell discussed the idea of using assurance contracts to fund a public good. They referred to the 5-step model for assurance contracts described on the Bitcoin wiki and used the example of "Facebook contact synchronization" with a target of 50 BTC. However, they had no experience with the required scripting language. Wendell asked for an example and clarification on donor requirements, to which Hearn responded that it was a bit complicated and required software development. He also suggested that assurance contracts could be a good way to fund complex projects.The email conversation also discussed the idea of a voting system for features using Bitcoin, where users vote by sending funds to a corresponding address. Assurance contracts were considered as a funding method for complex projects. However, implementing these ideas would require significant software development. The conversation then shifted to the potential burden on users if the Bitcoin network were to start relaying blocks. It was pointed out that mobile and tablet devices have different capabilities and limitations compared to desktop computers and laptops. Running Bitcoin software in the background on these devices could negatively impact battery life and bandwidth usage. One solution suggested was using a separate device, such as a Raspberry Pi, to donate to the network without affecting the performance of the primary device.In another email conversation, Mike Hearn and an unknown recipient discussed various aspects of an app store for Bitcoin. Mike suggested thinking of the app store as a set of affiliate schemes, where businesses must have an affiliate scheme in place to be placed into the apps section. Users who refer a lot of users to that business will receive referral bonuses. The apps should be online so businesses can retain control of their features and brand. Hive also plans to have a submission/review process to ensure user experience continuity and monitor potential exploits. They plan to have a public repository for applications maintained by them. One downside is that technical judgment may be distorted if projects heavily push certain businesses due to income dependence. Another alternative funding model suggested was allowing users to bid on assurance contracts for feature development. This would allow the community to direct development and feel directly involved. However, no recurring income could support future endeavors. The use of bitcoinj with an integrated VM for the app's framework was also discussed. It was noted that relying on random end-users donating CPU time or bandwidth to the network is not ideal.In the same email exchange, Wendell proposed a new approach to monetizing apps, where businesses would need to have an affiliate scheme in place to be placed in the apps section. App developers could earn referral bonuses from businesses when they refer users to them through their app. This funding model is compatible with openness but can distort technical judgment. Another alternative funding model suggested was allowing users to bid on assurance contracts for feature development, which would allow the community to direct development and feel directly involved. The use of bitcoinj with an integrated VM was discussed, with the main advantage being SPV. However, any schemes relying on random end-users donating CPU time or bandwidth to the network may not be feasible. Bitcoin might become more like Tor, with relays run on dedicated servers by people with knowledge and community involvement.The OS X wallet Hive has an integrated application platform that allows new users to discover Bitcoin businesses such as exchanges, merchants, and games. The locally hosted HTML/JS applications feature stripped-down UIs displayed in a mobile-proportioned WebKit frame inside of Hive itself. Transaction requests within apps trigger native Cocoa dialogue boxes for a secure experience. The team hopes to sustain themselves via small fees on transactions within the app platform but wants to be as ethical and decentralized as possible. Tracking user behavior and sending bills or having users send micro-transactions are not favored approaches. The team plans to release everything as free software under a GPL license, including the app store and the apps themselves. They will be using bitcoinj with an integrated VM for the time being due to SPV, but they would prefer to support the network more through ideas like partial UTXO sets. The team will be attending a conference in Amsterdam on the 27th of this month for further discussions. 2013-10-18T11:56:09+00:00 + A v1 API for managing pledges using Bitcoin has been released. The announcement was made by Wendell on the BitcoinTalk forum, stating that there are currently no fees and only basic features available. Mike Hearn expressed interest in the idea. Contact information for grabhive.com, Twitter, and a GPG key were provided.To use Bitcoin for managing pledges, people can either use a dedicated app or a wallet with the right features. Each option has its own pros and cons. bitcoinj makes it easy to create a new GUI wallet app written in Java. Programming contracts can be done through the link provided for Working With Contracts on the bitcoinj wiki.On Sep 5, 2013, Mike Hearn and Wendell discussed the idea of using assurance contracts to fund a public good. They referred to the 5-step model for assurance contracts described on the Bitcoin wiki and used the example of "Facebook contact synchronization" with a target of 50 BTC. However, they had no experience with the required scripting language. Wendell asked for an example and clarification on donor requirements, to which Hearn responded that it was a bit complicated and required software development. He also suggested that assurance contracts could be a good way to fund complex projects.The email conversation also discussed the idea of a voting system for features using Bitcoin, where users vote by sending funds to a corresponding address. Assurance contracts were considered as a funding method for complex projects. However, implementing these ideas would require significant software development. The conversation then shifted to the potential burden on users if the Bitcoin network were to start relaying blocks. It was pointed out that mobile and tablet devices have different capabilities and limitations compared to desktop computers and laptops. Running Bitcoin software in the background on these devices could negatively impact battery life and bandwidth usage. One solution suggested was using a separate device, such as a Raspberry Pi, to donate to the network without affecting the performance of the primary device.In another email conversation, Mike Hearn and an unknown recipient discussed various aspects of an app store for Bitcoin. Mike suggested thinking of the app store as a set of affiliate schemes, where businesses must have an affiliate scheme in place to be placed into the apps section. Users who refer a lot of users to that business will receive referral bonuses. The apps should be online so businesses can retain control of their features and brand. Hive also plans to have a submission/review process to ensure user experience continuity and monitor potential exploits. They plan to have a public repository for applications maintained by them. One downside is that technical judgment may be distorted if projects heavily push certain businesses due to income dependence. Another alternative funding model suggested was allowing users to bid on assurance contracts for feature development. This would allow the community to direct development and feel directly involved. However, no recurring income could support future endeavors. The use of bitcoinj with an integrated VM for the app's framework was also discussed. It was noted that relying on random end-users donating CPU time or bandwidth to the network is not ideal.In the same email exchange, Wendell proposed a new approach to monetizing apps, where businesses would need to have an affiliate scheme in place to be placed in the apps section. App developers could earn referral bonuses from businesses when they refer users to them through their app. This funding model is compatible with openness but can distort technical judgment. Another alternative funding model suggested was allowing users to bid on assurance contracts for feature development, which would allow the community to direct development and feel directly involved. The use of bitcoinj with an integrated VM was discussed, with the main advantage being SPV. However, any schemes relying on random end-users donating CPU time or bandwidth to the network may not be feasible. Bitcoin might become more like Tor, with relays run on dedicated servers by people with knowledge and community involvement.The OS X wallet Hive has an integrated application platform that allows new users to discover Bitcoin businesses such as exchanges, merchants, and games. The locally hosted HTML/JS applications feature stripped-down UIs displayed in a mobile-proportioned WebKit frame inside of Hive itself. Transaction requests within apps trigger native Cocoa dialogue boxes for a secure experience. The team hopes to sustain themselves via small fees on transactions within the app platform but wants to be as ethical and decentralized as possible. Tracking user behavior and sending bills or having users send micro-transactions are not favored approaches. The team plans to release everything as free software under a GPL license, including the app store and the apps themselves. They will be using bitcoinj with an integrated VM for the time being due to SPV, but they would prefer to support the network more through ideas like partial UTXO sets. The team will be attending a conference in Amsterdam on the 27th of this month for further discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_BIP0039-Mnemonic-code-for-generating-deterministic-keys.xml b/static/bitcoin-dev/Sept_2013/combined_BIP0039-Mnemonic-code-for-generating-deterministic-keys.xml index 79bcff8f9d..7169ff6030 100644 --- a/static/bitcoin-dev/Sept_2013/combined_BIP0039-Mnemonic-code-for-generating-deterministic-keys.xml +++ b/static/bitcoin-dev/Sept_2013/combined_BIP0039-Mnemonic-code-for-generating-deterministic-keys.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP0039 Mnemonic code for generating deterministic keys - 2023-08-01T05:54:31.160072+00:00 + 2025-10-11T22:11:14.143098+00:00 + python-feedgen slush 2013-10-24 19:46:57+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - BIP0039 Mnemonic code for generating deterministic keys - 2023-08-01T05:54:31.160072+00:00 + 2025-10-11T22:11:14.143274+00:00 - Pieter Wuille proposed a Proof of Work (PoW) concept in 2012, which was not pushed as a standard. Slush found the concept to be smart but pointed out its lack of bidirectionality and ability to convert between mnemonic and seed. Jorge Timón raised concerns about removing offensive words from the mnemonics, arguing that these words have a greater emotional impact and are more memorable. However, Slush suggested adding a swearword dictionary to bip39, but it may not gain popularity.The author questions the effectiveness of removing offensive words from mnemonics, proposing that generally offensive words, especially when combined with each other, could optimize the "maximum unforgettableness" criterion. This proposal goes against the trend of removing offensive words and may not be well-received by users.Changes have been made to the BIP39 wordlist, including removing offensive words, resolving duplicities, and implementing an algorithm for detecting similar characters. Slush expressed satisfaction with the new list and requested constructive feedback for the final round. The implementation also includes password protection and seed hardening using Rijndael cipher. The goal is to finalize the project for use in Trezor and by other developers who want to implement the algorithm into clients compatible with Trezor.Pieter proposed a superior system to BIP39, which has built-in configurable difficulty and checksums. The system allows for the use of any dictionary/language/text generator, as the software on the other side doesn't need to use the same dictionary. However, it cannot encode arbitrary data. Slush made changes to the BIP39 wordlist, removing offensive words and implementing an algorithm for detecting similar characters. Password protection of seed and seed hardening using Rijndael cipher were also added.The Bitcoin community has reflected on the BIP39 wordlist and made changes to improve it. Offensive words have been removed, and an algorithm has been implemented to detect words with similar characters. Duplicities have been resolved, making the wordlist more satisfactory. Password protection of seed and seed hardening using Rijndael cipher have also been added. The algorithm will be used in Trezor, and other wallet developers want to implement it into clients compatible with Trezor.The email thread discusses the wordlist used in python-mnemonic. Offensive words have been removed, but concerns have been raised about potentially offensive or threatening word combinations. Changes have been made to replace offensive words, and suggestions have been made to rate words for potential offensiveness and use neutral nouns. The email ends with an advertisement for ServiceNow and a link to join the Bitcoin-development mailing list.In an email exchange, Matthew Mitchell expressed concern about potentially offensive words in the wordlist. Pavol Rusnak revisited the wordlist and replaced approximately 67 offensive words. The changes aimed to improve the overall tone and sensitivity of the list towards different audiences.Andreas Petersson suggested using NLP to generate a grammatically correct sentence out of 128 random bits that humans could remember. He also mentioned encoding information in word selection and syntax tree choice. However, this idea required a larger wordlist and had complexity limitations due to running on embedded devices.The developers of a cryptocurrency wallet are open to changes in their wordlist and will accept pull requests replacing potentially offensive words with more neutral ones. Concerns were raised about rude or offensive word combinations, and suggestions were made to use mechanical turk time to rate words for offensiveness and use neutral nouns instead of place names with political complications.In an email conversation, Mark Friedenbach commented on how image display problems persisted on Wikipedia due to add-ons blocking certain URLs. This highlights the importance of avoiding potential filtering issues when designing systems. The conversation also touched on the challenges of troubleshooting situations where rude word combinations may cause confusion.The author expresses a desire to combine an NLP engine with a mnemonic code generator to output a short, humorous story as a passphrase. This idea was explored further, and another individual expressed interest in encoding the key within the story itself. The goal is to make passphrases more memorable while maintaining security.In an email exchange, Matthew Mitchell expressed concern about potentially offensive words in a project. Pavol Rusnak encouraged Mitchell to come up with wordlist enhancements, acknowledging that the wordlist is not perfect. Rusnak emphasized the importance of providing good alternatives for every word removed from the list.Slush sent an email announcing the finalization of the draft and reference implementation of BIP39. The proposal aims to standardize the algorithm across various clients and fix design problems of the existing Electrum mnemonic algorithm. BIP39 is seen as a complement to BIP32, allowing users to easily backup and share their wallet across multiple clients. The email also includes an advertisement for ServiceNow and information about the Bitcoin-development mailing list.In a discussion about wordlists used in BIPs, concerns were raised about potentially offensive or threatening word combinations. Slush explained 2013-10-24T19:46:57+00:00 + Pieter Wuille proposed a Proof of Work (PoW) concept in 2012, which was not pushed as a standard. Slush found the concept to be smart but pointed out its lack of bidirectionality and ability to convert between mnemonic and seed. Jorge Timón raised concerns about removing offensive words from the mnemonics, arguing that these words have a greater emotional impact and are more memorable. However, Slush suggested adding a swearword dictionary to bip39, but it may not gain popularity.The author questions the effectiveness of removing offensive words from mnemonics, proposing that generally offensive words, especially when combined with each other, could optimize the "maximum unforgettableness" criterion. This proposal goes against the trend of removing offensive words and may not be well-received by users.Changes have been made to the BIP39 wordlist, including removing offensive words, resolving duplicities, and implementing an algorithm for detecting similar characters. Slush expressed satisfaction with the new list and requested constructive feedback for the final round. The implementation also includes password protection and seed hardening using Rijndael cipher. The goal is to finalize the project for use in Trezor and by other developers who want to implement the algorithm into clients compatible with Trezor.Pieter proposed a superior system to BIP39, which has built-in configurable difficulty and checksums. The system allows for the use of any dictionary/language/text generator, as the software on the other side doesn't need to use the same dictionary. However, it cannot encode arbitrary data. Slush made changes to the BIP39 wordlist, removing offensive words and implementing an algorithm for detecting similar characters. Password protection of seed and seed hardening using Rijndael cipher were also added.The Bitcoin community has reflected on the BIP39 wordlist and made changes to improve it. Offensive words have been removed, and an algorithm has been implemented to detect words with similar characters. Duplicities have been resolved, making the wordlist more satisfactory. Password protection of seed and seed hardening using Rijndael cipher have also been added. The algorithm will be used in Trezor, and other wallet developers want to implement it into clients compatible with Trezor.The email thread discusses the wordlist used in python-mnemonic. Offensive words have been removed, but concerns have been raised about potentially offensive or threatening word combinations. Changes have been made to replace offensive words, and suggestions have been made to rate words for potential offensiveness and use neutral nouns. The email ends with an advertisement for ServiceNow and a link to join the Bitcoin-development mailing list.In an email exchange, Matthew Mitchell expressed concern about potentially offensive words in the wordlist. Pavol Rusnak revisited the wordlist and replaced approximately 67 offensive words. The changes aimed to improve the overall tone and sensitivity of the list towards different audiences.Andreas Petersson suggested using NLP to generate a grammatically correct sentence out of 128 random bits that humans could remember. He also mentioned encoding information in word selection and syntax tree choice. However, this idea required a larger wordlist and had complexity limitations due to running on embedded devices.The developers of a cryptocurrency wallet are open to changes in their wordlist and will accept pull requests replacing potentially offensive words with more neutral ones. Concerns were raised about rude or offensive word combinations, and suggestions were made to use mechanical turk time to rate words for offensiveness and use neutral nouns instead of place names with political complications.In an email conversation, Mark Friedenbach commented on how image display problems persisted on Wikipedia due to add-ons blocking certain URLs. This highlights the importance of avoiding potential filtering issues when designing systems. The conversation also touched on the challenges of troubleshooting situations where rude word combinations may cause confusion.The author expresses a desire to combine an NLP engine with a mnemonic code generator to output a short, humorous story as a passphrase. This idea was explored further, and another individual expressed interest in encoding the key within the story itself. The goal is to make passphrases more memorable while maintaining security.In an email exchange, Matthew Mitchell expressed concern about potentially offensive words in a project. Pavol Rusnak encouraged Mitchell to come up with wordlist enhancements, acknowledging that the wordlist is not perfect. Rusnak emphasized the importance of providing good alternatives for every word removed from the list.Slush sent an email announcing the finalization of the draft and reference implementation of BIP39. The proposal aims to standardize the algorithm across various clients and fix design problems of the existing Electrum mnemonic algorithm. BIP39 is seen as a complement to BIP32, allowing users to easily backup and share their wallet across multiple clients. The email also includes an advertisement for ServiceNow and information about the Bitcoin-development mailing list.In a discussion about wordlists used in BIPs, concerns were raised about potentially offensive or threatening word combinations. Slush explained - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_Blockchain-archival.xml b/static/bitcoin-dev/Sept_2013/combined_Blockchain-archival.xml index 842566d65c..b2f6b2a860 100644 --- a/static/bitcoin-dev/Sept_2013/combined_Blockchain-archival.xml +++ b/static/bitcoin-dev/Sept_2013/combined_Blockchain-archival.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Blockchain archival - 2023-08-01T05:53:46.957246+00:00 + 2025-10-11T22:10:59.267783+00:00 + python-feedgen Jeff Garzik 2013-09-08 04:13:48+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Blockchain archival - 2023-08-01T05:53:46.957246+00:00 + 2025-10-11T22:10:59.267935+00:00 - In a discussion on the concept of trust-free solutions in Bitcoin, it is argued that balance-at-point-in-time can solve the issue of being completely trust-free and reduce storage requirements. However, it is pointed out that it still requires bootstrapping into trust by an earlier dataset, creating a chain that is not entirely trust-free. There are discussions on UTXO snapshotting, which is similar to balance-at-point-in-time but not deemed trust-free.To have a completely trust-free solution, one must verify all data from genesis through $now. However, it's not necessary for all Bitcoin wallets to download and verify all those gigabytes of data because SPV mode serves that purpose. The need for Bitcoin to grow beyond an interesting experiment into global everyday use is also discussed, taking the average punter into account.The current concept of Bitcoin addresses as single-use destinations doesn't fit with people's mindset. People perceive addresses as the equivalent of jars where they can store their coins. Wallets, on the other hand, are like boxes where people keep some of their jars in, and only the person with the right key can open the jar and take its contents. The ability to specify the address to send from is considered essential and a missing feature of the QT client. Intra-wallet transfers with an "also discard the sending address" would be a way of stopping any further use of that address.When balance-at-point-in-time is implemented, it could shrink the storage for all other Bitcoin users who choose not to have a full transaction set. The sender also mentions the need to verify the ability to send Bitcoin using balance-at-point-in-time efficiently. To do so, it's only necessary to know that the sender has the specified amount of Bitcoin, not all previous transactions that led to that state. This will increase efficiency as Bitcoin grows.There is also a discussion on the need for an archival system for the Bitcoin protocol to avoid the blockchain becoming too big to download. It is suggested that balance-at-point-in-time summaries could be a simple solution, enabling new adopters to get up and running in minutes rather than days. Bitcoin-Qt 0.9 is expected to have this work incorporated to enable quick usability and background verification of the history.The question of consolidating addresses and wallets is raised, but it is clarified that addresses are single-use destinations that point to a wallet, which is private and unknown to the network.Overall, the discussions focus on finding trust-free solutions in Bitcoin, the need for an archival system to prevent the blockchain from becoming too large, and the importance of addressing user mindset and efficiency as Bitcoin grows. 2013-09-08T04:13:48+00:00 + In a discussion on the concept of trust-free solutions in Bitcoin, it is argued that balance-at-point-in-time can solve the issue of being completely trust-free and reduce storage requirements. However, it is pointed out that it still requires bootstrapping into trust by an earlier dataset, creating a chain that is not entirely trust-free. There are discussions on UTXO snapshotting, which is similar to balance-at-point-in-time but not deemed trust-free.To have a completely trust-free solution, one must verify all data from genesis through $now. However, it's not necessary for all Bitcoin wallets to download and verify all those gigabytes of data because SPV mode serves that purpose. The need for Bitcoin to grow beyond an interesting experiment into global everyday use is also discussed, taking the average punter into account.The current concept of Bitcoin addresses as single-use destinations doesn't fit with people's mindset. People perceive addresses as the equivalent of jars where they can store their coins. Wallets, on the other hand, are like boxes where people keep some of their jars in, and only the person with the right key can open the jar and take its contents. The ability to specify the address to send from is considered essential and a missing feature of the QT client. Intra-wallet transfers with an "also discard the sending address" would be a way of stopping any further use of that address.When balance-at-point-in-time is implemented, it could shrink the storage for all other Bitcoin users who choose not to have a full transaction set. The sender also mentions the need to verify the ability to send Bitcoin using balance-at-point-in-time efficiently. To do so, it's only necessary to know that the sender has the specified amount of Bitcoin, not all previous transactions that led to that state. This will increase efficiency as Bitcoin grows.There is also a discussion on the need for an archival system for the Bitcoin protocol to avoid the blockchain becoming too big to download. It is suggested that balance-at-point-in-time summaries could be a simple solution, enabling new adopters to get up and running in minutes rather than days. Bitcoin-Qt 0.9 is expected to have this work incorporated to enable quick usability and background verification of the history.The question of consolidating addresses and wallets is raised, but it is clarified that addresses are single-use destinations that point to a wallet, which is private and unknown to the network.Overall, the discussions focus on finding trust-free solutions in Bitcoin, the need for an archival system to prevent the blockchain from becoming too large, and the importance of addressing user mindset and efficiency as Bitcoin grows. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_Faster-databases-than-LevelDB.xml b/static/bitcoin-dev/Sept_2013/combined_Faster-databases-than-LevelDB.xml index 1e07903bca..885f76635c 100644 --- a/static/bitcoin-dev/Sept_2013/combined_Faster-databases-than-LevelDB.xml +++ b/static/bitcoin-dev/Sept_2013/combined_Faster-databases-than-LevelDB.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Faster databases than LevelDB - 2023-08-01T05:55:44.134431+00:00 + 2025-10-11T22:10:50.772085+00:00 + python-feedgen Mark Friedenbach 2013-09-17 17:08:54+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - Faster databases than LevelDB - 2023-08-01T05:55:44.135431+00:00 + 2025-10-11T22:10:50.772220+00:00 - In a post on the Bitcoin development mailing list, Mark Friedenbach expressed his desire to abstract out the UTXO and block databases to allow for different key/value stores as backends. He mentioned HyperDex and Sophia as potential options, with HyperDex being a distributed, fault-tolerant version of LevelDB and Sophia being a competitor to LevelDB. Mike Hearn responded, noting that while LevelDB is fast, there are alternatives like HyperLevelDB and Sophia that may offer better performance.Hearn stated that HyperLevelDB is a forked version of LevelDB with changes to locking and compaction, making it potentially faster. Sophia, on the other hand, claims to completely outperform LevelDB in benchmarks, particularly in random reads, which are essential for UTXO lookups. Sophia boasts 438,084 random reads/sec compared to LevelDB's 167,476 random reads/sec.Moving on to Bitcoin wallet formats, Hearn expressed his opinion in 2013 about the lack of development in creating better wallet formats. He highlighted the limitations of the current Hierarchical Deterministic (HD) wallet, including privacy concerns and the potential loss of funds due to human error. Several alternatives have emerged over the years, such as MAHDW and Blockstream Green Wallet, offering enhanced privacy features and improved user interfaces.However, the adoption of these new wallet formats has been slow, possibly due to compatibility concerns, difficulty in migrating funds, or a lack of awareness about the benefits. While progress has been made since Hearn's comment, there is still room for improvement in Bitcoin wallet formats to ensure the security and usability of funds in the long run.Additionally, in an email exchange from 2013, Hearn discussed the performance of LevelDB and its competitors. He explored HyperLevelDB but found it slower for the database sizes they were using at the time. Sophia, another competitor to LevelDB, claims to outperform it in benchmarks, specifically in random reads. However, Hearn did not delve into the specifics or attempt to replicate the results himself. It's worth noting that as of 2021, Bitcoin Core still uses BerkeleyDB for the wallet.In another discussion, the use of BerkeleyDB for the Bitcoin wallet and the libdb4.8++-dev dependency was questioned. Hearn shared his knowledge about alternative options like HyperLevelDB and Sophia, which are claimed to be faster than LevelDB. He explained the differences between them, including finer-grained locking and changes to compaction. Sophia, written in C and BSD licensed, claims to perform significantly better than LevelDB, with 438,084 random reads/sec on SSD-based machines compared to LevelDB's 167,476 random reads/sec. On the other hand, HyperLevelDB appears to excel in random writes.While LevelDB is a fast key-value storage library, it may not be the ultimate solution for performance. HyperLevelDB and Sophia offer potential improvements, with Sophia claiming a significant edge over LevelDB in benchmarks. The choice between these alternatives depends on factors such as read/write requirements and specific use cases. 2013-09-17T17:08:54+00:00 + In a post on the Bitcoin development mailing list, Mark Friedenbach expressed his desire to abstract out the UTXO and block databases to allow for different key/value stores as backends. He mentioned HyperDex and Sophia as potential options, with HyperDex being a distributed, fault-tolerant version of LevelDB and Sophia being a competitor to LevelDB. Mike Hearn responded, noting that while LevelDB is fast, there are alternatives like HyperLevelDB and Sophia that may offer better performance.Hearn stated that HyperLevelDB is a forked version of LevelDB with changes to locking and compaction, making it potentially faster. Sophia, on the other hand, claims to completely outperform LevelDB in benchmarks, particularly in random reads, which are essential for UTXO lookups. Sophia boasts 438,084 random reads/sec compared to LevelDB's 167,476 random reads/sec.Moving on to Bitcoin wallet formats, Hearn expressed his opinion in 2013 about the lack of development in creating better wallet formats. He highlighted the limitations of the current Hierarchical Deterministic (HD) wallet, including privacy concerns and the potential loss of funds due to human error. Several alternatives have emerged over the years, such as MAHDW and Blockstream Green Wallet, offering enhanced privacy features and improved user interfaces.However, the adoption of these new wallet formats has been slow, possibly due to compatibility concerns, difficulty in migrating funds, or a lack of awareness about the benefits. While progress has been made since Hearn's comment, there is still room for improvement in Bitcoin wallet formats to ensure the security and usability of funds in the long run.Additionally, in an email exchange from 2013, Hearn discussed the performance of LevelDB and its competitors. He explored HyperLevelDB but found it slower for the database sizes they were using at the time. Sophia, another competitor to LevelDB, claims to outperform it in benchmarks, specifically in random reads. However, Hearn did not delve into the specifics or attempt to replicate the results himself. It's worth noting that as of 2021, Bitcoin Core still uses BerkeleyDB for the wallet.In another discussion, the use of BerkeleyDB for the Bitcoin wallet and the libdb4.8++-dev dependency was questioned. Hearn shared his knowledge about alternative options like HyperLevelDB and Sophia, which are claimed to be faster than LevelDB. He explained the differences between them, including finer-grained locking and changes to compaction. Sophia, written in C and BSD licensed, claims to perform significantly better than LevelDB, with 438,084 random reads/sec on SSD-based machines compared to LevelDB's 167,476 random reads/sec. On the other hand, HyperLevelDB appears to excel in random writes.While LevelDB is a fast key-value storage library, it may not be the ultimate solution for performance. HyperLevelDB and Sophia offer potential improvements, with Sophia claiming a significant edge over LevelDB in benchmarks. The choice between these alternatives depends on factors such as read/write requirements and specific use cases. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_GB-V04.xml b/static/bitcoin-dev/Sept_2013/combined_GB-V04.xml index 5f0723e2b1..47d773c163 100644 --- a/static/bitcoin-dev/Sept_2013/combined_GB-V04.xml +++ b/static/bitcoin-dev/Sept_2013/combined_GB-V04.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - GB V04 - 2023-08-01T05:52:58.612026+00:00 + 2025-10-11T22:10:52.893018+00:00 + python-feedgen Mike Hearn 2013-09-05 08:27:06+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - GB V04 - 2023-08-01T05:52:58.612026+00:00 + 2025-10-11T22:10:52.893154+00:00 - On September 4, 2013, the release of Secure Instant Messenger version 04, also known as GoldBug, was announced by Randolph D. on the Bitcoin-development mailing list. The software is designed to offer secure communication through instant messaging and comes with various features such as end-to-end encryption, voice and video chat options, file transfer, and group chat capabilities. GoldBug is an open-source software available for free download on Windows, Linux, and macOS platforms.GoldBug provides strong security measures to protect user information and privacy. It follows a decentralized architecture that ensures no central servers are involved in the communication process. This decentralized approach enhances security by minimizing the risk of data breaches. Additionally, the software allows users to create anonymous accounts and integrates with the Tor network to further enhance their anonymity.The latest version of GoldBug, V04, introduces several updates to improve stability, performance, and compatibility. It offers enhanced support for multiple languages and better compatibility with various operating systems. Furthermore, the software now supports additional network protocols such as I2P and Freenet, allowing users to connect securely with others on these networks.Overall, Secure Instant Messenger (GoldBug) is a reliable and secure messaging tool that provides end-to-end encryption and other advanced features for secure communication. Users can download the latest version of the software from Sourceforge.net and enjoy its improved functionality and performance. 2013-09-05T08:27:06+00:00 + On September 4, 2013, the release of Secure Instant Messenger version 04, also known as GoldBug, was announced by Randolph D. on the Bitcoin-development mailing list. The software is designed to offer secure communication through instant messaging and comes with various features such as end-to-end encryption, voice and video chat options, file transfer, and group chat capabilities. GoldBug is an open-source software available for free download on Windows, Linux, and macOS platforms.GoldBug provides strong security measures to protect user information and privacy. It follows a decentralized architecture that ensures no central servers are involved in the communication process. This decentralized approach enhances security by minimizing the risk of data breaches. Additionally, the software allows users to create anonymous accounts and integrates with the Tor network to further enhance their anonymity.The latest version of GoldBug, V04, introduces several updates to improve stability, performance, and compatibility. It offers enhanced support for multiple languages and better compatibility with various operating systems. Furthermore, the software now supports additional network protocols such as I2P and Freenet, allowing users to connect securely with others on these networks.Overall, Secure Instant Messenger (GoldBug) is a reliable and secure messaging tool that provides end-to-end encryption and other advanced features for secure communication. Users can download the latest version of the software from Sourceforge.net and enjoy its improved functionality and performance. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_More-appropriate-XDG-menu-category-for-bitcoin-qt.xml b/static/bitcoin-dev/Sept_2013/combined_More-appropriate-XDG-menu-category-for-bitcoin-qt.xml index 9a7ef2cbdf..13ff36e91d 100644 --- a/static/bitcoin-dev/Sept_2013/combined_More-appropriate-XDG-menu-category-for-bitcoin-qt.xml +++ b/static/bitcoin-dev/Sept_2013/combined_More-appropriate-XDG-menu-category-for-bitcoin-qt.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - More appropriate XDG menu category for bitcoin-qt - 2023-08-01T05:33:47.583262+00:00 + 2025-10-11T22:11:09.896254+00:00 + python-feedgen Kip Warner 2013-09-15 18:28:19+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - More appropriate XDG menu category for bitcoin-qt - 2023-08-01T05:33:47.583262+00:00 + 2025-10-11T22:11:09.896440+00:00 - In September 2013, Matt Corallo announced the release of version 0.8.5 of Bitcoin, after a delay for which he apologized. This new version included a new category and could be downloaded from the Bitcoin Github repository. Kip Warner, a software engineer, expressed gratitude to Matt for the update and shared his contact information, with a preference for OpenPGP encrypted/signed mail.Following this, Kip Warner proposed refining the "Office" category in the bitcoin-qt application's XDG desktop integration to "Finance" in a mailing list post. He pointed out that XDG's menu specification allowed for such a modification. Although acknowledging his limited knowledge of Git, he suggested modifying the line in bitcoin-qt.desktop to read "Categories=Office;Finance;" However, he did not provide a patch himself.In response, Matt announced the pull request at https://github.com/bitcoin/bitcoin/pull/2999, which included the implementation of the new category. The discussion regarding this change took place on the Bitcoin-development mailing list.The bitcoin-qt application's XDG desktop integration currently places itself under the "Office" menu category on certain desktop environments. However, there is a suggestion to refine this categorization to "Finance" based on XDG's menu specification. This would allow for a more specific classification. The proposed modification to the bitcoin-qt.desktop file is to include the line "Categories=Office;Finance." The author of the proposal apologized for not providing the patch himself due to his limited knowledge of Git. 2013-09-15T18:28:19+00:00 + In September 2013, Matt Corallo announced the release of version 0.8.5 of Bitcoin, after a delay for which he apologized. This new version included a new category and could be downloaded from the Bitcoin Github repository. Kip Warner, a software engineer, expressed gratitude to Matt for the update and shared his contact information, with a preference for OpenPGP encrypted/signed mail.Following this, Kip Warner proposed refining the "Office" category in the bitcoin-qt application's XDG desktop integration to "Finance" in a mailing list post. He pointed out that XDG's menu specification allowed for such a modification. Although acknowledging his limited knowledge of Git, he suggested modifying the line in bitcoin-qt.desktop to read "Categories=Office;Finance;" However, he did not provide a patch himself.In response, Matt announced the pull request at https://github.com/bitcoin/bitcoin/pull/2999, which included the implementation of the new category. The discussion regarding this change took place on the Bitcoin-development mailing list.The bitcoin-qt application's XDG desktop integration currently places itself under the "Office" menu category on certain desktop environments. However, there is a suggestion to refine this categorization to "Finance" based on XDG's menu specification. This would allow for a more specific classification. The proposed modification to the bitcoin-qt.desktop file is to include the line "Categories=Office;Finance." The author of the proposal apologized for not providing the patch himself due to his limited knowledge of Git. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_New-Output-Script-Type.xml b/static/bitcoin-dev/Sept_2013/combined_New-Output-Script-Type.xml index 03ab4f1b85..68eb959bd0 100644 --- a/static/bitcoin-dev/Sept_2013/combined_New-Output-Script-Type.xml +++ b/static/bitcoin-dev/Sept_2013/combined_New-Output-Script-Type.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New Output Script Type - 2023-08-01T05:55:20.746009+00:00 + 2025-10-11T22:10:55.016780+00:00 + python-feedgen Jeff Garzik 2013-09-14 01:10:08+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - New Output Script Type - 2023-08-01T05:55:20.746009+00:00 + 2025-10-11T22:10:55.016918+00:00 - In September 2013, a proposal was put forward on the Bitcoin-development mailing list to introduce a new payment type called "embed_hash." The purpose of this proposal was to enable the embedding of data in the blockchain as a hash, separate from normal Bitcoin addresses. The idea behind this separation was to enhance the core Bitcoin payments system.The proposal suggested creating a script with a single 20 byte push data, offering optimization opportunities and avoiding the need for indexing Bitcoin addresses that are currently used for data indexing. Jeff Garzik, a Senior Software Engineer at BitPay, provided context for the proposal and shared links to sources supporting the concept of embedding data in the blockchain as a hash.The email thread discussed existing services like Proof of Existence and sx-embed-addr, which enable the embedding of data in the blockchain as a hash. To support this feature, the author proposed the creation of the "embed_hash" payment type, which would be unspendable. By separating this type of Bitcoin usage from the core payment system, improvements could be made.To illustrate the concept further, the author mentioned websites such as www.proofofexistence.com and code repositories like https://github.com/spesmilo/sx/blob/master/src/sx-embed-addr, which facilitate the embedding of data in the blockchain as a hash. The proposed "embed_hash" payment type would utilize a script with a single 20 byte push data, providing optimization options and eliminating the need to index Bitcoin addresses used for data indexing.By implementing the "embed_hash" payment type and separating it from regular Bitcoin addresses, the proposal aimed to improve the overall functionality and efficiency of the core Bitcoin payments system. However, it is worth noting that the email thread ended with an unrelated advertisement for ServiceNow's IT transformation services. 2013-09-14T01:10:08+00:00 + In September 2013, a proposal was put forward on the Bitcoin-development mailing list to introduce a new payment type called "embed_hash." The purpose of this proposal was to enable the embedding of data in the blockchain as a hash, separate from normal Bitcoin addresses. The idea behind this separation was to enhance the core Bitcoin payments system.The proposal suggested creating a script with a single 20 byte push data, offering optimization opportunities and avoiding the need for indexing Bitcoin addresses that are currently used for data indexing. Jeff Garzik, a Senior Software Engineer at BitPay, provided context for the proposal and shared links to sources supporting the concept of embedding data in the blockchain as a hash.The email thread discussed existing services like Proof of Existence and sx-embed-addr, which enable the embedding of data in the blockchain as a hash. To support this feature, the author proposed the creation of the "embed_hash" payment type, which would be unspendable. By separating this type of Bitcoin usage from the core payment system, improvements could be made.To illustrate the concept further, the author mentioned websites such as www.proofofexistence.com and code repositories like https://github.com/spesmilo/sx/blob/master/src/sx-embed-addr, which facilitate the embedding of data in the blockchain as a hash. The proposed "embed_hash" payment type would utilize a script with a single 20 byte push data, providing optimization options and eliminating the need to index Bitcoin addresses used for data indexing.By implementing the "embed_hash" payment type and separating it from regular Bitcoin addresses, the proposal aimed to improve the overall functionality and efficiency of the core Bitcoin payments system. However, it is worth noting that the email thread ended with an unrelated advertisement for ServiceNow's IT transformation services. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_Payment-Protocol-BIP-70-71-72.xml b/static/bitcoin-dev/Sept_2013/combined_Payment-Protocol-BIP-70-71-72.xml index 70e6ea6644..4a32c0dbff 100644 --- a/static/bitcoin-dev/Sept_2013/combined_Payment-Protocol-BIP-70-71-72.xml +++ b/static/bitcoin-dev/Sept_2013/combined_Payment-Protocol-BIP-70-71-72.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol: BIP 70, 71, 72 - 2023-08-01T05:29:54.664873+00:00 + 2025-10-11T22:10:57.143877+00:00 + python-feedgen Peter Todd 2013-09-26 06:37:19+00:00 @@ -171,13 +172,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol: BIP 70, 71, 72 - 2023-08-01T05:29:54.664873+00:00 + 2025-10-11T22:10:57.144056+00:00 - In a series of discussions among Bitcoin developers, various topics related to payment protocols, wallet functionality, and the use of URIs for transactions were explored. One topic of discussion was the potential for a Man-in-the-Middle (MITM) attack on the HTTPS protocol, which could exploit flaws in the SSL PKI infrastructure and harm Bitcoin. It was suggested that implementing a payment protocol using the SSL PKI infrastructure could help identify weaknesses and motivate improvements.The possibility of MITM attacks in the context of Bitcoin URIs was also raised, with some companies using data loss prevention products with MITM capability. While the incentive for governments or large corporations to carry out such attacks may be low, detecting transactions could be more useful than meddling with them. Difficulties in using QR codes, especially under low light conditions, were also discussed, prompting suggestions for alternative approaches such as short URLs.The conversation touched on the security risks related to certificate authorities and MITM attacks, with HTTPS being seen as protective against certain attacks but not those involving scanning QR codes in person. The need for trust in HTTPS was debated, with one developer arguing that seeing a partner in person should eliminate the need for a certificate. However, concerns about the subversion of certificate authorities and the potential theft of funds due to broken certificates were also raised.Developers explored ways to make QR codes more scannable and reduce their size. Suggestions included changing parameters and exploring the use of BIP70 once available. The importance of HTTPS and the potential benefits of using the payments protocol were emphasized.The flexibility of the BIP72 specification was updated to allow for more options in processing transactions. Existing point-of-sale systems were identified as potential beneficiaries of the payments protocol, although concerns were raised about compatibility issues. The debate over Bitcoin URIs and the potential advantages of payment URIs was discussed, with considerations for proper payment infrastructure and the inclusion of 'SHOULDs' and 'MAYs' instead of 'MUSTs' in the specification.Additional discussions centered on wallet functionality, including concerns about wallets without P2P protocol support and the handling of locked inputs. The responsibility of confirming transactions and preventing their announcement to the network was also debated.Overall, these discussions demonstrate the ongoing development and considerations within the Bitcoin community regarding payment protocols, wallet functionality, and the use of URIs for transactions. Various suggestions were made to enhance security, improve scannability, and ensure backward compatibility. 2013-09-26T06:37:19+00:00 + In a series of discussions among Bitcoin developers, various topics related to payment protocols, wallet functionality, and the use of URIs for transactions were explored. One topic of discussion was the potential for a Man-in-the-Middle (MITM) attack on the HTTPS protocol, which could exploit flaws in the SSL PKI infrastructure and harm Bitcoin. It was suggested that implementing a payment protocol using the SSL PKI infrastructure could help identify weaknesses and motivate improvements.The possibility of MITM attacks in the context of Bitcoin URIs was also raised, with some companies using data loss prevention products with MITM capability. While the incentive for governments or large corporations to carry out such attacks may be low, detecting transactions could be more useful than meddling with them. Difficulties in using QR codes, especially under low light conditions, were also discussed, prompting suggestions for alternative approaches such as short URLs.The conversation touched on the security risks related to certificate authorities and MITM attacks, with HTTPS being seen as protective against certain attacks but not those involving scanning QR codes in person. The need for trust in HTTPS was debated, with one developer arguing that seeing a partner in person should eliminate the need for a certificate. However, concerns about the subversion of certificate authorities and the potential theft of funds due to broken certificates were also raised.Developers explored ways to make QR codes more scannable and reduce their size. Suggestions included changing parameters and exploring the use of BIP70 once available. The importance of HTTPS and the potential benefits of using the payments protocol were emphasized.The flexibility of the BIP72 specification was updated to allow for more options in processing transactions. Existing point-of-sale systems were identified as potential beneficiaries of the payments protocol, although concerns were raised about compatibility issues. The debate over Bitcoin URIs and the potential advantages of payment URIs was discussed, with considerations for proper payment infrastructure and the inclusion of 'SHOULDs' and 'MAYs' instead of 'MUSTs' in the specification.Additional discussions centered on wallet functionality, including concerns about wallets without P2P protocol support and the handling of locked inputs. The responsibility of confirming transactions and preventing their announcement to the network was also debated.Overall, these discussions demonstrate the ongoing development and considerations within the Bitcoin community regarding payment protocols, wallet functionality, and the use of URIs for transactions. Various suggestions were made to enhance security, improve scannability, and ensure backward compatibility. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_Simple-contacts-exchange-was-Social-network-integration-brainstorm-.xml b/static/bitcoin-dev/Sept_2013/combined_Simple-contacts-exchange-was-Social-network-integration-brainstorm-.xml index 6bd242f226..bcc7619347 100644 --- a/static/bitcoin-dev/Sept_2013/combined_Simple-contacts-exchange-was-Social-network-integration-brainstorm-.xml +++ b/static/bitcoin-dev/Sept_2013/combined_Simple-contacts-exchange-was-Social-network-integration-brainstorm-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Simple contacts exchange (was: Social network integration (brainstorm)) - 2023-08-01T05:53:26.900268+00:00 + 2025-10-11T22:11:05.648630+00:00 + python-feedgen Mike Hearn 2013-09-17 12:36:29+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - Simple contacts exchange (was: Social network integration (brainstorm)) - 2023-08-01T05:53:26.901271+00:00 + 2025-10-11T22:11:05.648806+00:00 - Wendell is exploring ways to automatically exchange contact details between Bitcoin wallets in order to promote the use of identifiable names and photos instead of long, hard-to-verify addresses. One suggestion involves inserting a data lookup hash into the transaction, allowing the recipient to see the sender's name and photo. However, concerns were raised about storing this data on dedicated servers that could be coerced into giving up information or altering the system. To address these concerns, different solutions were proposed, including encrypting the data and using the transaction hash itself for the lookup. The goal is to find a decentralized way to store the data without relying on dedicated servers.In addition to the discussion on exchanging contact details, there was also a conversation about the payment protocol and the need for signed certificates. It was explained that the payment protocol is designed to simplify transactions and identity verification between parties. The sender submits a payment containing their own identity details, while the recipient vends a PaymentRequest containing theirs. This allows wallets to understand how to complete the transaction. There was also mention of the option to extend the payment protocol to support other forms of Public Key Infrastructure (PKI).Overall, Wendell and the community are seeking feedback on the payment protocol and exploring various options to improve usability and security. They aim to find decentralized solutions to exchange contact details and ensure cryptographic proof of identity, while also considering the implications and challenges associated with implementing such features. 2013-09-17T12:36:29+00:00 + Wendell is exploring ways to automatically exchange contact details between Bitcoin wallets in order to promote the use of identifiable names and photos instead of long, hard-to-verify addresses. One suggestion involves inserting a data lookup hash into the transaction, allowing the recipient to see the sender's name and photo. However, concerns were raised about storing this data on dedicated servers that could be coerced into giving up information or altering the system. To address these concerns, different solutions were proposed, including encrypting the data and using the transaction hash itself for the lookup. The goal is to find a decentralized way to store the data without relying on dedicated servers.In addition to the discussion on exchanging contact details, there was also a conversation about the payment protocol and the need for signed certificates. It was explained that the payment protocol is designed to simplify transactions and identity verification between parties. The sender submits a payment containing their own identity details, while the recipient vends a PaymentRequest containing theirs. This allows wallets to understand how to complete the transaction. There was also mention of the option to extend the payment protocol to support other forms of Public Key Infrastructure (PKI).Overall, Wendell and the community are seeking feedback on the payment protocol and exploring various options to improve usability and security. They aim to find decentralized solutions to exchange contact details and ensure cryptographic proof of identity, while also considering the implications and challenges associated with implementing such features. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_Social-network-integration-brainstorm-.xml b/static/bitcoin-dev/Sept_2013/combined_Social-network-integration-brainstorm-.xml index 35c8bbca0d..34fa69be7d 100644 --- a/static/bitcoin-dev/Sept_2013/combined_Social-network-integration-brainstorm-.xml +++ b/static/bitcoin-dev/Sept_2013/combined_Social-network-integration-brainstorm-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Social network integration (brainstorm) - 2023-08-01T05:53:15.155469+00:00 + 2025-10-11T22:11:07.773526+00:00 + python-feedgen Mats Henricson 2013-09-05 11:02:11+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Social network integration (brainstorm) - 2023-08-01T05:53:15.155469+00:00 + 2025-10-11T22:11:07.773674+00:00 - The Trsst project is focused on enabling content monetization through micro payments of digital crypto-currency. Each user account on the platform functions as a digital wallet, allowing authors to receive payments whenever their content is consumed, shared, or liked. In an effort to make Bitcoin more user-friendly, Wendell suggests the idea of watermarking addresses into social network profile pictures to connect them to personal profiles. This would enable users to send Bitcoin to any Facebook user who has configured their profile correctly.To implement this approach, a Java library exists that can implement watermarking capable of surviving social network recompression. However, due to Facebook's lack of support for most apps, many have disappeared over time. Despite this, Blockchain.info offers the ability to send 'coin via Facebook, and Bitcoins With Friends is another available option.A potential solution to watermarking images on social media platforms is suggested: creating a mobile app with API access to read and write the user's profile picture. This would allow the app to periodically check if the image has changed and rewatermark and reupload the highest resolution available. However, this manual process may not be suitable for everyone and could result in the loss of comments or likes on the primary photo or lead to duplicates. The ability to read the user's watermarked address does not require API access or an account. It is recommended to encode a short URL containing a payment request rather than using an actual Bitcoin address or key, as social network photos have limited stegod data capacity due to compression. Users would also need to rotate their key periodically at the hosting site.Mike Hearn proposed the idea of watermarking images with Bitcoin addresses to establish connections between social networking profiles without the need for API access. Although the process would be manual and undone every time a user changes their profile image, it could still serve as a useful way to organize Bitcoin around people and organizations in a familiar manner. While most apps have vanished due to Facebook's lack of support, Blockchain.info offers the option to send 'coin via Facebook, and Bitcoins With Friends is another available choice. The thread is open for discussion on additional ideas to simplify Bitcoin usage. 2013-09-05T11:02:11+00:00 + The Trsst project is focused on enabling content monetization through micro payments of digital crypto-currency. Each user account on the platform functions as a digital wallet, allowing authors to receive payments whenever their content is consumed, shared, or liked. In an effort to make Bitcoin more user-friendly, Wendell suggests the idea of watermarking addresses into social network profile pictures to connect them to personal profiles. This would enable users to send Bitcoin to any Facebook user who has configured their profile correctly.To implement this approach, a Java library exists that can implement watermarking capable of surviving social network recompression. However, due to Facebook's lack of support for most apps, many have disappeared over time. Despite this, Blockchain.info offers the ability to send 'coin via Facebook, and Bitcoins With Friends is another available option.A potential solution to watermarking images on social media platforms is suggested: creating a mobile app with API access to read and write the user's profile picture. This would allow the app to periodically check if the image has changed and rewatermark and reupload the highest resolution available. However, this manual process may not be suitable for everyone and could result in the loss of comments or likes on the primary photo or lead to duplicates. The ability to read the user's watermarked address does not require API access or an account. It is recommended to encode a short URL containing a payment request rather than using an actual Bitcoin address or key, as social network photos have limited stegod data capacity due to compression. Users would also need to rotate their key periodically at the hosting site.Mike Hearn proposed the idea of watermarking images with Bitcoin addresses to establish connections between social networking profiles without the need for API access. Although the process would be manual and undone every time a user changes their profile image, it could still serve as a useful way to organize Bitcoin around people and organizations in a familiar manner. While most apps have vanished due to Facebook's lack of support, Blockchain.info offers the option to send 'coin via Facebook, and Bitcoins With Friends is another available choice. The thread is open for discussion on additional ideas to simplify Bitcoin usage. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_Some-current-turbulence-on-the-Bitcoin-network-DB-corruption-errors-on-start-from-Bitcoin-qt-Bitcoind.xml b/static/bitcoin-dev/Sept_2013/combined_Some-current-turbulence-on-the-Bitcoin-network-DB-corruption-errors-on-start-from-Bitcoin-qt-Bitcoind.xml index 136cb3bf86..a31a2c604c 100644 --- a/static/bitcoin-dev/Sept_2013/combined_Some-current-turbulence-on-the-Bitcoin-network-DB-corruption-errors-on-start-from-Bitcoin-qt-Bitcoind.xml +++ b/static/bitcoin-dev/Sept_2013/combined_Some-current-turbulence-on-the-Bitcoin-network-DB-corruption-errors-on-start-from-Bitcoin-qt-Bitcoind.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Some current turbulence on the Bitcoin network: DB corruption errors on start from Bitcoin-qt / Bitcoind - 2023-08-01T05:53:59.801673+00:00 + 2025-10-11T22:10:48.647871+00:00 + python-feedgen Gregory Maxwell 2013-09-09 23:25:50+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Some current turbulence on the Bitcoin network: DB corruption errors on start from Bitcoin-qt / Bitcoind - 2023-08-01T05:53:59.801673+00:00 + 2025-10-11T22:10:48.648014+00:00 - A helpful write-up on the BitcoinTalk forum provides step-by-step instructions for users looking for a workaround on Windows. The workaround is specific to the Windows operating system and caution should be exercised when making changes to system settings. Gregory Maxwell, a Bitcoin developer, has a patch available for review regarding the cryptocurrency's blockchain vulnerability. The patch can be found at https://github.com/bitcoin/bitcoin/pull/2982 and more information will be provided once it has been fully reviewed by other developers. Until then, Maxwell suggests using the checklevel=2 workaround as a temporary solution. Passengers are advised to return to their seats and fasten their seat-belts as all Bitcoin-qt / Bitcoind nodes are currently experiencing an issue. After restarting, nodes report "coin database inconsistencies found" and prompt users with "Do you want to rebuild the block database now?" Reindexing will not solve this issue, which was introduced by version 0.8.0. However, it is only local and does not carry any forking risk. To work around this problem, users should specify the command-line or configuration file argument -checklevel=2 to Bitcoind or Bitcoin-qt. This issue will persist until no more than 288 blocks after 256818, unless another trigger transaction is added to the blockchain. A patch will be released soon to fix the problem completely. 2013-09-09T23:25:50+00:00 + A helpful write-up on the BitcoinTalk forum provides step-by-step instructions for users looking for a workaround on Windows. The workaround is specific to the Windows operating system and caution should be exercised when making changes to system settings. Gregory Maxwell, a Bitcoin developer, has a patch available for review regarding the cryptocurrency's blockchain vulnerability. The patch can be found at https://github.com/bitcoin/bitcoin/pull/2982 and more information will be provided once it has been fully reviewed by other developers. Until then, Maxwell suggests using the checklevel=2 workaround as a temporary solution. Passengers are advised to return to their seats and fasten their seat-belts as all Bitcoin-qt / Bitcoind nodes are currently experiencing an issue. After restarting, nodes report "coin database inconsistencies found" and prompt users with "Do you want to rebuild the block database now?" Reindexing will not solve this issue, which was introduced by version 0.8.0. However, it is only local and does not carry any forking risk. To work around this problem, users should specify the command-line or configuration file argument -checklevel=2 to Bitcoind or Bitcoin-qt. This issue will persist until no more than 288 blocks after 256818, unless another trigger transaction is added to the blockchain. A patch will be released soon to fix the problem completely. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_bitcoind-stops-responding.xml b/static/bitcoin-dev/Sept_2013/combined_bitcoind-stops-responding.xml index 1b50d635ba..fc2db164a7 100644 --- a/static/bitcoin-dev/Sept_2013/combined_bitcoind-stops-responding.xml +++ b/static/bitcoin-dev/Sept_2013/combined_bitcoind-stops-responding.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - bitcoind stops responding - 2023-08-01T05:56:46.167168+00:00 + 2025-10-11T22:11:03.524934+00:00 + python-feedgen Jeff Garzik 2013-10-04 15:05:29+00:00 @@ -67,13 +68,13 @@ - python-feedgen + 2 Combined summary - bitcoind stops responding - 2023-08-01T05:56:46.167168+00:00 + 2025-10-11T22:11:03.525090+00:00 - In an email chain on October 4th, 2013, Gavin Andresen suggested a patch to make the RPC code in Bitcoin smarter by making the last rpc thread ignore keepalive and always disconnect. Currently, the HTTP server code paths use blocking I/O, so RPC is multi-threaded to work around this issue. Jeff Garzik tried a multi-threaded approach using boost::asio, but it resulted in messy code that required more lines of code per boost async action. The goal is to make the code truly async I/O, and Jeff believes that a single thread with async I/O is likely sufficient for even heavy uses of RPC.In an email correspondence on October 1, 2013, slush reported an issue where one process was frequently calling getinfo every second as a fallback to possibly misconfigured blocknotify, and another process was calling getinfo once a minute to check if bitcoind was working. Gavin Andresen suggested using 'help getinfo' to check if bitcoind was responding to RPC requests without acquiring any locks. Users running into the maximum-of-4-keepalive-requests issue were advised to run with -rpcthreads=11 or however many keepalive connections they needed to support. He also suggested that the rpc code should be smarter, and making the last rpc thread ignore keepalive and always disconnecting should be a simple patch.The context highlights a log from Bitcoin where the `getinfo` RPC function takes more than two seconds to return. This delay is caused by various factors such as receiving a block, committing transactions to the coin database, and setting a new best chain. The author suggests ideas to reduce the time taken by `getinfo`, including closing and reopening the database asynchronously, removing unnecessary options from BDB, and experimenting with an optional boolean parameter for `getinfo` that could skip gathering information that may prolong the call.Jeff Garzik and Olivier discuss network activity during a test and the duration of locks being held. It is suggested that the lock contention with other threads may be causing the long lock time. Olivier modifies the code to measure how long it takes to acquire the locks and finds that it can take over 6 seconds in some cases. Jeff Garzik forwards the email to the Bitcoin-development mailing list.The context also includes reports of issues with bitcoind not responding to RPC calls without any suspicious activity in the logs. These problems occur on various backends, indicating that it is not specific to one node. The issue of RPC hanging is mentioned, and the complexity associated with IsConfirmed/Ismine is highlighted as a possible cause. Suggestions are made to use alternative methods like sendmany instead of sendToAddress to address these issues.There are discussions about the four RPC thread limit introduced in version 0.8.2 of Bitcoin and the support for RPC keepalive. It is noted that building with more RPC threads can resolve the issue of exhausting all four threads and preventing further connections.In September 2013, a user reported an issue where bitcoind stops responding to RPC calls when transactions are sent every 20 seconds or less. This problem is unrelated to other reported issues and is suspected to be caused by the four RPC thread limit. Another user observed similar problems with bitcoind stopping responding to RPC calls without any suspicious activity in the log. This issue occurs on various backends, suggesting it is not specific to one node.A member of the mailing list raises concerns about bitcoind stopping responses to RPC calls without any suspicious activity in the log and low CPU usage. This issue is observed in versions 0.8.2 and 0.8.5 and occurs multiple times per day on various backends. The issue is raised to seek input from others who may be experiencing similar problems.Overall, the context highlights various issues and discussions related to the RPC functionality in Bitcoin, including suggestions for improvements, reports of problems with bitcoind not responding to RPC calls, and possible solutions and workarounds. 2013-10-04T15:05:29+00:00 + In an email chain on October 4th, 2013, Gavin Andresen suggested a patch to make the RPC code in Bitcoin smarter by making the last rpc thread ignore keepalive and always disconnect. Currently, the HTTP server code paths use blocking I/O, so RPC is multi-threaded to work around this issue. Jeff Garzik tried a multi-threaded approach using boost::asio, but it resulted in messy code that required more lines of code per boost async action. The goal is to make the code truly async I/O, and Jeff believes that a single thread with async I/O is likely sufficient for even heavy uses of RPC.In an email correspondence on October 1, 2013, slush reported an issue where one process was frequently calling getinfo every second as a fallback to possibly misconfigured blocknotify, and another process was calling getinfo once a minute to check if bitcoind was working. Gavin Andresen suggested using 'help getinfo' to check if bitcoind was responding to RPC requests without acquiring any locks. Users running into the maximum-of-4-keepalive-requests issue were advised to run with -rpcthreads=11 or however many keepalive connections they needed to support. He also suggested that the rpc code should be smarter, and making the last rpc thread ignore keepalive and always disconnecting should be a simple patch.The context highlights a log from Bitcoin where the `getinfo` RPC function takes more than two seconds to return. This delay is caused by various factors such as receiving a block, committing transactions to the coin database, and setting a new best chain. The author suggests ideas to reduce the time taken by `getinfo`, including closing and reopening the database asynchronously, removing unnecessary options from BDB, and experimenting with an optional boolean parameter for `getinfo` that could skip gathering information that may prolong the call.Jeff Garzik and Olivier discuss network activity during a test and the duration of locks being held. It is suggested that the lock contention with other threads may be causing the long lock time. Olivier modifies the code to measure how long it takes to acquire the locks and finds that it can take over 6 seconds in some cases. Jeff Garzik forwards the email to the Bitcoin-development mailing list.The context also includes reports of issues with bitcoind not responding to RPC calls without any suspicious activity in the logs. These problems occur on various backends, indicating that it is not specific to one node. The issue of RPC hanging is mentioned, and the complexity associated with IsConfirmed/Ismine is highlighted as a possible cause. Suggestions are made to use alternative methods like sendmany instead of sendToAddress to address these issues.There are discussions about the four RPC thread limit introduced in version 0.8.2 of Bitcoin and the support for RPC keepalive. It is noted that building with more RPC threads can resolve the issue of exhausting all four threads and preventing further connections.In September 2013, a user reported an issue where bitcoind stops responding to RPC calls when transactions are sent every 20 seconds or less. This problem is unrelated to other reported issues and is suspected to be caused by the four RPC thread limit. Another user observed similar problems with bitcoind stopping responding to RPC calls without any suspicious activity in the log. This issue occurs on various backends, suggesting it is not specific to one node.A member of the mailing list raises concerns about bitcoind stopping responses to RPC calls without any suspicious activity in the log and low CPU usage. This issue is observed in versions 0.8.2 and 0.8.5 and occurs multiple times per day on various backends. The issue is raised to seek input from others who may be experiencing similar problems.Overall, the context highlights various issues and discussions related to the RPC functionality in Bitcoin, including suggestions for improvements, reports of problems with bitcoind not responding to RPC calls, and possible solutions and workarounds. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_smart-contracts-possible-use-case-yes-or-no-.xml b/static/bitcoin-dev/Sept_2013/combined_smart-contracts-possible-use-case-yes-or-no-.xml index 9e264395ee..70f7aca38d 100644 --- a/static/bitcoin-dev/Sept_2013/combined_smart-contracts-possible-use-case-yes-or-no-.xml +++ b/static/bitcoin-dev/Sept_2013/combined_smart-contracts-possible-use-case-yes-or-no-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - smart contracts -- possible use case? yes or no? - 2023-08-01T05:56:16.440574+00:00 + 2025-10-11T22:11:16.266708+00:00 + python-feedgen Mark Friedenbach 2013-09-29 17:49:00+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - smart contracts -- possible use case? yes or no? - 2023-08-01T05:56:16.440574+00:00 + 2025-10-11T22:11:16.266913+00:00 - In a discussion on the bitcoin-dev mailing list, the topic of external audits of customer accounts without revealing private data is raised. It is suggested that this could be useful beyond taxation. Examples of anonymity in taxation, such as with certain types of investments in Swiss banks, are mentioned. The idea of applying similar methods to Bitcoin is proposed, and it is recommended to discuss this topic on the Bitcoin Talk forum.Another discussion on the Bitcoin development mailing list revolves around taxation and donations. The focus is on voluntary donations going to the correct place and being verified by an oracle. The uncertainty of regulatory environments in different regions and the need to pay capital gains and sales taxes are discussed. The issue of how donations are spent, with 80% going towards administration rather than their intended purpose, is raised. Suggestions are made to fix this issue so that everyone benefits, including the business person who wishes to contribute, the government that receives more revenue, and the fire department that can use the funds for its work. Different viewpoints on donating directly to specific causes or paying taxes are presented.In another email thread, Neil Fincham expresses his desire to keep philosophy and tax evasion out of discussions related to Bitcoin development. Gavin Andresen agrees and suggests focusing on technical issues that can be solved through writing code. The conversation centers around a use case and whether it is technically feasible using smart contracts. Information about October webinars on Code for Performance is shared as well.The Bitcoin protocol and code are noted to have centralized risks or choke points that could undermine its peer-to-peer nature. Technical solutions, such as advanced cryptography and byzantine networking argument, are suggested to address these issues. The preference is to focus on ideas that have reached the stage of having a BIP, while early-stage speculative ideas can be discussed on bitcointalk.org's technical thread. The acceptance of significantly anonymous taxation in some cases is mentioned, and the possibility of similar methods for Bitcoin is proposed. The importance of keeping the mailing list for technical discussions related to writing code is emphasized.Overall, the discussions on the mailing lists revolve around taxation, donations, regulatory environments, and the dissatisfaction with how funds are typically spent. Different perspectives on voluntary donations, direct contributions to specific causes, and the use of smart contracts are presented. The desire to keep the focus on technical issues related to Bitcoin development is also highlighted. 2013-09-29T17:49:00+00:00 + In a discussion on the bitcoin-dev mailing list, the topic of external audits of customer accounts without revealing private data is raised. It is suggested that this could be useful beyond taxation. Examples of anonymity in taxation, such as with certain types of investments in Swiss banks, are mentioned. The idea of applying similar methods to Bitcoin is proposed, and it is recommended to discuss this topic on the Bitcoin Talk forum.Another discussion on the Bitcoin development mailing list revolves around taxation and donations. The focus is on voluntary donations going to the correct place and being verified by an oracle. The uncertainty of regulatory environments in different regions and the need to pay capital gains and sales taxes are discussed. The issue of how donations are spent, with 80% going towards administration rather than their intended purpose, is raised. Suggestions are made to fix this issue so that everyone benefits, including the business person who wishes to contribute, the government that receives more revenue, and the fire department that can use the funds for its work. Different viewpoints on donating directly to specific causes or paying taxes are presented.In another email thread, Neil Fincham expresses his desire to keep philosophy and tax evasion out of discussions related to Bitcoin development. Gavin Andresen agrees and suggests focusing on technical issues that can be solved through writing code. The conversation centers around a use case and whether it is technically feasible using smart contracts. Information about October webinars on Code for Performance is shared as well.The Bitcoin protocol and code are noted to have centralized risks or choke points that could undermine its peer-to-peer nature. Technical solutions, such as advanced cryptography and byzantine networking argument, are suggested to address these issues. The preference is to focus on ideas that have reached the stage of having a BIP, while early-stage speculative ideas can be discussed on bitcointalk.org's technical thread. The acceptance of significantly anonymous taxation in some cases is mentioned, and the possibility of similar methods for Bitcoin is proposed. The importance of keeping the mailing list for technical discussions related to writing code is emphasized.Overall, the discussions on the mailing lists revolve around taxation, donations, regulatory environments, and the dissatisfaction with how funds are typically spent. Different perspectives on voluntary donations, direct contributions to specific causes, and the use of smart contracts are presented. The desire to keep the focus on technical issues related to Bitcoin development is also highlighted. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2013/combined_the-XBT.xml b/static/bitcoin-dev/Sept_2013/combined_the-XBT.xml index 7bcdd124c7..60cd1940d4 100644 --- a/static/bitcoin-dev/Sept_2013/combined_the-XBT.xml +++ b/static/bitcoin-dev/Sept_2013/combined_the-XBT.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - the XBT - 2023-08-01T05:55:57.807310+00:00 + 2025-10-11T22:11:12.019986+00:00 + python-feedgen Jeff Garzik 2013-09-18 10:48:30+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - the XBT - 2023-08-01T05:55:57.807310+00:00 + 2025-10-11T22:11:12.020120+00:00 - In September 2013, there was a conversation between Johnathan Corgan and Jeff about the approval of the proposed XBT standard by ISO. Jeff simply responded with a "No," but there is no further information provided about what XBT is or why its approval matters to ISO.During the same month, Ron shared an article with his colleagues discussing the legitimacy of Bitcoin gaining a market-based ISO currency code. The article explains that Bitcoin has its own ISO currency code, XBT, which was proposed at the time but had not been approved by ISO yet. Ron questioned if there had been any updates on the proposal's approval status.Bitcoin, being a decentralized digital currency, has gained market-based legitimacy with its own ISO currency code according to the provided link. The recognition by the International Organization for Standardization (ISO) is a significant step towards increasing the credibility and mainstream adoption of Bitcoin in financial institutions and markets.The ISO currency code is a three-letter code used worldwide to represent currencies. Its purpose is to standardize the trading and exchange of currencies across international borders. With the addition of XBT in the ISO currency codes, Bitcoin can now be easily identified and tracked by financial institutions and traders globally.This move by ISO highlights the growing acceptance of cryptocurrencies in the global economy. It indicates that Bitcoin is gradually gaining market-based legitimacy, which could lead to increased investor confidence and stability in the cryptocurrency market.In summary, Bitcoin's recognition by ISO with its own currency code of XBT is a significant development in the cryptocurrency market. This recognition will help standardize the trading and exchange of Bitcoin and increase its credibility in financial institutions and markets globally. Furthermore, this move signifies the growing acceptance of cryptocurrencies in the global economy. 2013-09-18T10:48:30+00:00 + In September 2013, there was a conversation between Johnathan Corgan and Jeff about the approval of the proposed XBT standard by ISO. Jeff simply responded with a "No," but there is no further information provided about what XBT is or why its approval matters to ISO.During the same month, Ron shared an article with his colleagues discussing the legitimacy of Bitcoin gaining a market-based ISO currency code. The article explains that Bitcoin has its own ISO currency code, XBT, which was proposed at the time but had not been approved by ISO yet. Ron questioned if there had been any updates on the proposal's approval status.Bitcoin, being a decentralized digital currency, has gained market-based legitimacy with its own ISO currency code according to the provided link. The recognition by the International Organization for Standardization (ISO) is a significant step towards increasing the credibility and mainstream adoption of Bitcoin in financial institutions and markets.The ISO currency code is a three-letter code used worldwide to represent currencies. Its purpose is to standardize the trading and exchange of currencies across international borders. With the addition of XBT in the ISO currency codes, Bitcoin can now be easily identified and tracked by financial institutions and traders globally.This move by ISO highlights the growing acceptance of cryptocurrencies in the global economy. It indicates that Bitcoin is gradually gaining market-based legitimacy, which could lead to increased investor confidence and stability in the cryptocurrency market.In summary, Bitcoin's recognition by ISO with its own currency code of XBT is a significant development in the cryptocurrency market. This recognition will help standardize the trading and exchange of Bitcoin and increase its credibility in financial institutions and markets globally. Furthermore, this move signifies the growing acceptance of cryptocurrencies in the global economy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_-ann-Bitcoin-Core-0-9-3-has-been-released.xml b/static/bitcoin-dev/Sept_2014/combined_-ann-Bitcoin-Core-0-9-3-has-been-released.xml index 2e7f41139b..cfd6f392ed 100644 --- a/static/bitcoin-dev/Sept_2014/combined_-ann-Bitcoin-Core-0-9-3-has-been-released.xml +++ b/static/bitcoin-dev/Sept_2014/combined_-ann-Bitcoin-Core-0-9-3-has-been-released.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [ann] Bitcoin Core 0.9.3 has been released - 2023-08-01T10:21:19.037511+00:00 + 2025-10-11T21:44:54.497375+00:00 + python-feedgen Peter Todd 2014-09-27 19:39:23+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - [ann] Bitcoin Core 0.9.3 has been released - 2023-08-01T10:21:19.037511+00:00 + 2025-10-11T21:44:54.497556+00:00 - Melvin Carvalho commended the individuals who assisted in translating Bitcoin documentation on Transifex. He also expressed his curiosity about a specific change in the Bitcoin code, which involved increasing the IsStandard() scriptSig length. Peter Todd, the individual responsible for the change, eliminated the limitations on the number of public keys for P2SH CHECKMULTISIG outputs. Previously, there were restrictions that prevented multisig scriptPubKey's requiring more signatures from running out of scriptSig space, even though a 1-of-12 P2SH could be spent in a standard transaction. The increase in scriptSig space only allows for signatures, meaning that not much has changed in terms of "stuffing data in the blockchain." Additionally, utilizing more outputs is easy and inexpensive. In the main.cpp file, the limit for the largest standard txin was raised to 1650 bytes.Bitcoin Core version 0.9.3 has been released, focusing solely on bug fixes and updated translations. It is strongly recommended that users upgrade to this release. Users can report any bugs they encounter using the issue tracker at Github. Instructions for upgrading have been provided for those currently using an older version. However, cautionary warnings have also been issued regarding downgrading, as the 'chainstate' in this release may not always be compatible with previous versions. The release notes outline changes in RPC, Protocol and network code, Wallet, GUI, and Miscellaneous categories. The increase in IsStandard() scriptSig length has also been implemented. Recognition has been given to the contributors of this release, as well as those who aided in translation on Transifex.Bitcoin Core version 0.9.3 has been released, bringing with it updated translations and solely focusing on bug fixes. Users are highly encouraged to upgrade their systems to this latest release. For those running an older version, the process involves shutting it down and then running the installer on Windows, or copying over /Applications/Bitcoin-Qt on Mac, or bitcoind/bitcoin-qt on Linux. If upgrading from version 0.7.2 or earlier, the blockchain files will be re-indexed for the first time. However, it is important to note that the 'chainstate' in this release may not always be compatible with previous versions. In such cases, users should run the old release with the -reindex option to rebuild the chainstate data structures when switching back to a 0.8.x release. The new release includes several updates, such as resolving a segfault issue on getblock if it fails to read a block from disk in RPC. In Protocol and network code, the release no longer polls showmyip.com as it no longer exists. In Wallet, it checks that the redeemScript size does not exceed the 520-byte limit, and provides warnings for redeemScripts that are too long while loading the wallet. In GUI, it fixes the display of unicode characters on MacOSX. OpenSSL has been upgraded to version 1.0.1i, and miniupnpc has been upgraded to version 1.9.20140701. Numerous contributors, including Andrew Poelstra, Cory Fields, Gavin Andresen, Jeff Garzik, Johnathan Corgan, Julian Haight, Michael Ford, Pavel Vasin, Peter Todd, phantomcircuit, Pieter Wuille, Rose Toomey, Ruben Dario Ponticelli, shshshsh, Trevin Hofmann, Warren Togami, Wladimir J. van der Laan, and Zak Wilcox, have played key roles in bringing about this release. The contributions of all those who assisted in translating on Transifex are also greatly appreciated. 2014-09-27T19:39:23+00:00 + Melvin Carvalho commended the individuals who assisted in translating Bitcoin documentation on Transifex. He also expressed his curiosity about a specific change in the Bitcoin code, which involved increasing the IsStandard() scriptSig length. Peter Todd, the individual responsible for the change, eliminated the limitations on the number of public keys for P2SH CHECKMULTISIG outputs. Previously, there were restrictions that prevented multisig scriptPubKey's requiring more signatures from running out of scriptSig space, even though a 1-of-12 P2SH could be spent in a standard transaction. The increase in scriptSig space only allows for signatures, meaning that not much has changed in terms of "stuffing data in the blockchain." Additionally, utilizing more outputs is easy and inexpensive. In the main.cpp file, the limit for the largest standard txin was raised to 1650 bytes.Bitcoin Core version 0.9.3 has been released, focusing solely on bug fixes and updated translations. It is strongly recommended that users upgrade to this release. Users can report any bugs they encounter using the issue tracker at Github. Instructions for upgrading have been provided for those currently using an older version. However, cautionary warnings have also been issued regarding downgrading, as the 'chainstate' in this release may not always be compatible with previous versions. The release notes outline changes in RPC, Protocol and network code, Wallet, GUI, and Miscellaneous categories. The increase in IsStandard() scriptSig length has also been implemented. Recognition has been given to the contributors of this release, as well as those who aided in translation on Transifex.Bitcoin Core version 0.9.3 has been released, bringing with it updated translations and solely focusing on bug fixes. Users are highly encouraged to upgrade their systems to this latest release. For those running an older version, the process involves shutting it down and then running the installer on Windows, or copying over /Applications/Bitcoin-Qt on Mac, or bitcoind/bitcoin-qt on Linux. If upgrading from version 0.7.2 or earlier, the blockchain files will be re-indexed for the first time. However, it is important to note that the 'chainstate' in this release may not always be compatible with previous versions. In such cases, users should run the old release with the -reindex option to rebuild the chainstate data structures when switching back to a 0.8.x release. The new release includes several updates, such as resolving a segfault issue on getblock if it fails to read a block from disk in RPC. In Protocol and network code, the release no longer polls showmyip.com as it no longer exists. In Wallet, it checks that the redeemScript size does not exceed the 520-byte limit, and provides warnings for redeemScripts that are too long while loading the wallet. In GUI, it fixes the display of unicode characters on MacOSX. OpenSSL has been upgraded to version 1.0.1i, and miniupnpc has been upgraded to version 1.9.20140701. Numerous contributors, including Andrew Poelstra, Cory Fields, Gavin Andresen, Jeff Garzik, Johnathan Corgan, Julian Haight, Michael Ford, Pavel Vasin, Peter Todd, phantomcircuit, Pieter Wuille, Rose Toomey, Ruben Dario Ponticelli, shshshsh, Trevin Hofmann, Warren Togami, Wladimir J. van der Laan, and Zak Wilcox, have played key roles in bringing about this release. The contributions of all those who assisted in translating on Transifex are also greatly appreciated. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_BIP43-Purpose-code-for-voting-pool-HD-wallets.xml b/static/bitcoin-dev/Sept_2014/combined_BIP43-Purpose-code-for-voting-pool-HD-wallets.xml index 3d95a34d9a..f50471787c 100644 --- a/static/bitcoin-dev/Sept_2014/combined_BIP43-Purpose-code-for-voting-pool-HD-wallets.xml +++ b/static/bitcoin-dev/Sept_2014/combined_BIP43-Purpose-code-for-voting-pool-HD-wallets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP43 Purpose code for voting pool HD wallets - 2023-08-01T10:16:06.974259+00:00 + 2025-10-11T21:44:50.243559+00:00 + python-feedgen Bryan Bishop 2014-09-26 02:32:44+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - BIP43 Purpose code for voting pool HD wallets - 2023-08-01T10:16:06.974259+00:00 + 2025-10-11T21:44:50.243756+00:00 - In September 2014, Gregory Maxwell sent an email seeking feedback on a proposal regarding the attachment of files through sourceforge. However, non-subscribed users faced difficulties accessing the file due to an HTTP 500 error. Bryan's contact information was also included in the email.Alan, in a Bitcoin-development mailing list, expressed support for BIP43 and suggested the addition of a "Purpose" node to identify different tree structures in a wallet file. He proposed a non-hardened first-layer derivation for common trees and a "No-collision mode" for multisig BIP32 trees. These changes could be implemented by modifying the BIP43 "Purpose" index and allowing wallet software to recognize and react to the Purpose node for various tree structures. Alan believed that adding an extra layer between the root and the important tree nodes would provide flexibility to BIP32 as a whole.Gregory Maxwell discussed the broken process of the BIP (Bitcoin Improvement Proposals) process, specifically regarding informational BIPs. He argued that proposals requiring action from others should not be grouped with purely informational proposals. Maxwell clarified that the informational BIPs were only proposed to support the intent of BIP43. Justus Ranvier was included in the email chain, and his public key ID was provided.On August 19, 2014, Justus Ranvier sent an email attaching two draft information BIPs. He requested feedback from the recipients both privately and on the list. No additional commentary was provided in the email.The HD multisig structure to be used for Bitcoin wallets used in voting pools will reserve two purpose codes. Two draft information BIPs were documented - one for wallets suitable for storing bulk bitcoin deposits and another for storing colored coin deposits. The primary difference is that bulk deposit wallets use cold storage and allow significant administrative overhead, while colored coin wallets do not use cold storage because they must be generated on the fly. The email mentioned an HTML attachment, but no details were provided about its content. Justus Ranvier signed off the message with his public key ID. 2014-09-26T02:32:44+00:00 + In September 2014, Gregory Maxwell sent an email seeking feedback on a proposal regarding the attachment of files through sourceforge. However, non-subscribed users faced difficulties accessing the file due to an HTTP 500 error. Bryan's contact information was also included in the email.Alan, in a Bitcoin-development mailing list, expressed support for BIP43 and suggested the addition of a "Purpose" node to identify different tree structures in a wallet file. He proposed a non-hardened first-layer derivation for common trees and a "No-collision mode" for multisig BIP32 trees. These changes could be implemented by modifying the BIP43 "Purpose" index and allowing wallet software to recognize and react to the Purpose node for various tree structures. Alan believed that adding an extra layer between the root and the important tree nodes would provide flexibility to BIP32 as a whole.Gregory Maxwell discussed the broken process of the BIP (Bitcoin Improvement Proposals) process, specifically regarding informational BIPs. He argued that proposals requiring action from others should not be grouped with purely informational proposals. Maxwell clarified that the informational BIPs were only proposed to support the intent of BIP43. Justus Ranvier was included in the email chain, and his public key ID was provided.On August 19, 2014, Justus Ranvier sent an email attaching two draft information BIPs. He requested feedback from the recipients both privately and on the list. No additional commentary was provided in the email.The HD multisig structure to be used for Bitcoin wallets used in voting pools will reserve two purpose codes. Two draft information BIPs were documented - one for wallets suitable for storing bulk bitcoin deposits and another for storing colored coin deposits. The primary difference is that bulk deposit wallets use cold storage and allow significant administrative overhead, while colored coin wallets do not use cold storage because they must be generated on the fly. The email mentioned an HTML attachment, but no details were provided about its content. Justus Ranvier signed off the message with his public key ID. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_BIP72-amendment-proposal.xml b/static/bitcoin-dev/Sept_2014/combined_BIP72-amendment-proposal.xml index b0317a0ec4..a1e7beb66f 100644 --- a/static/bitcoin-dev/Sept_2014/combined_BIP72-amendment-proposal.xml +++ b/static/bitcoin-dev/Sept_2014/combined_BIP72-amendment-proposal.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP72 amendment proposal - 2023-08-01T10:18:40.714137+00:00 + 2025-10-11T21:45:05.119312+00:00 + python-feedgen Andreas Schildbach 2014-09-15 07:43:32+00:00 @@ -71,13 +72,13 @@ - python-feedgen + 2 Combined summary - BIP72 amendment proposal - 2023-08-01T10:18:40.714137+00:00 + 2025-10-11T21:45:05.119500+00:00 - In an email exchange, Aaron Voisine proposed that BIP72 should require signed payment requests from the same domain as the merchant. He suggested that merchants could store their signed payment requests on their payment processors' servers, providing a better user experience by showing the actual merchant instead of just the payment processor. However, he did not think it was necessary for BIP72 to require HTTPS, as HTTP is commonly used and the proposed spec allows for other transports like Bluetooth.The conversation also discussed a more efficient approach to adding another field to PaymentRequest that contains an ECC signature calculated using the public key that hashes to the address in the URI. This would involve adding another marker param like &s to the end of the URL. However, there are several downsides to this approach including complexity and concerns about re-purposing the BIP21 address. The discussion also touched on the length of the URL and the possibility of truncating the SHA256 hashes to save characters.Another topic of discussion was the importance of the length of a hash in PaymentDetails/PaymentRequest. It was suggested that including the hash length in the PaymentDetails/PaymentRequest is necessary to prevent a MITM attacker from truncating the hash to lower security.The conversation then moved on to discussing the use of hash functions in generating QR codes for payment requests. There were debates about the optimum length of the hash, with suggestions to leave it open for experimentation. Different hash functions were evaluated, including SHA1, Murmur, and MD5. The discussion also touched on the use of certificates in verifying website authenticity and the potential issues with X.509.A separate discussion focused on whether signed payment requests should be from the same domain and require HTTPS as per BIP72. The proposal suggested adding another marker parameter to the URL and another field to PaymentRequest containing an ECC signature calculated using the public key that hashes to the address in the URI. Upgraded wallets would then expect to find the PaymentDetails signed with the address key. However, there were concerns raised about the complexity of signing and the potential issues with re-purposing the BIP21 address.BitPay tested the impact of adding more bytes to QR codes and found that it made them harder to scan in low-light environments. This was in response to a suggestion that Base64 encoding of SHA256 was overkill and that HTTPS should provide enough security. Adding a hash to QR codes was deemed to make them bloated and harder to scan.Overall, the discussions centered on improving the PaymentRequest system by adding an ECC signature to the URL and PaymentRequest, determining the optimum length of the hash, and considering the scannability of QR codes. There were also debates about the use of certificates, the need for HTTPS, and the limitations of existing hash functions. 2014-09-15T07:43:32+00:00 + In an email exchange, Aaron Voisine proposed that BIP72 should require signed payment requests from the same domain as the merchant. He suggested that merchants could store their signed payment requests on their payment processors' servers, providing a better user experience by showing the actual merchant instead of just the payment processor. However, he did not think it was necessary for BIP72 to require HTTPS, as HTTP is commonly used and the proposed spec allows for other transports like Bluetooth.The conversation also discussed a more efficient approach to adding another field to PaymentRequest that contains an ECC signature calculated using the public key that hashes to the address in the URI. This would involve adding another marker param like &s to the end of the URL. However, there are several downsides to this approach including complexity and concerns about re-purposing the BIP21 address. The discussion also touched on the length of the URL and the possibility of truncating the SHA256 hashes to save characters.Another topic of discussion was the importance of the length of a hash in PaymentDetails/PaymentRequest. It was suggested that including the hash length in the PaymentDetails/PaymentRequest is necessary to prevent a MITM attacker from truncating the hash to lower security.The conversation then moved on to discussing the use of hash functions in generating QR codes for payment requests. There were debates about the optimum length of the hash, with suggestions to leave it open for experimentation. Different hash functions were evaluated, including SHA1, Murmur, and MD5. The discussion also touched on the use of certificates in verifying website authenticity and the potential issues with X.509.A separate discussion focused on whether signed payment requests should be from the same domain and require HTTPS as per BIP72. The proposal suggested adding another marker parameter to the URL and another field to PaymentRequest containing an ECC signature calculated using the public key that hashes to the address in the URI. Upgraded wallets would then expect to find the PaymentDetails signed with the address key. However, there were concerns raised about the complexity of signing and the potential issues with re-purposing the BIP21 address.BitPay tested the impact of adding more bytes to QR codes and found that it made them harder to scan in low-light environments. This was in response to a suggestion that Base64 encoding of SHA256 was overkill and that HTTPS should provide enough security. Adding a hash to QR codes was deemed to make them bloated and harder to scan.Overall, the discussions centered on improving the PaymentRequest system by adding an ECC signature to the URL and PaymentRequest, determining the optimum length of the hash, and considering the scannability of QR codes. There were also debates about the use of certificates, the need for HTTPS, and the limitations of existing hash functions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_Bitcoin-development-Digest-Vol-40-Issue-9.xml b/static/bitcoin-dev/Sept_2014/combined_Bitcoin-development-Digest-Vol-40-Issue-9.xml index d1f5a9444b..48511bb787 100644 --- a/static/bitcoin-dev/Sept_2014/combined_Bitcoin-development-Digest-Vol-40-Issue-9.xml +++ b/static/bitcoin-dev/Sept_2014/combined_Bitcoin-development-Digest-Vol-40-Issue-9.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin-development Digest, Vol 40, Issue 9 - 2023-08-01T10:19:49.606173+00:00 + 2025-10-11T21:45:02.994890+00:00 + python-feedgen Vitalik Buterin 2014-09-23 19:57:10+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Bitcoin-development Digest, Vol 40, Issue 9 - 2023-08-01T10:19:49.606173+00:00 + 2025-10-11T21:45:02.995023+00:00 - Based on the given context, it appears that there was a conversation between two individuals discussing a proposal called "No-Collision" mode for Multisig BIP32 Wallets. The goal of this proposal is to prevent accidental address re-use and make it easy to identify which devices were used for each transaction in the overall wallet history. Justus Ranvier initially suggested calling this arrangement a "voting pool wallet," but Alan Reiner wanted to make the work public and requested Ranvier to recap or link their work.Ranvier provides links to their work on sourceforge and Github, indicating that they have been publicly sharing their ideas since January 2014 and are currently implementing it in btcwallet. Ranvier expresses frustration with the BIP numbering process, which can pigeonhole proposals. They explain that they have resolved this issue by changing the naming scheme for their proposals and purpose codes to no longer rely on centrally-allocated numbers.In addition to the discussion on the "No-Collision" mode proposal, the email contains an advertisement for an EventLog Analyzer that helps achieve PCI DSS 3.0 compliance. The ad mentions the ability to comply with requirements 10 and 11.5 and provides a link to download a white paper. It should be noted that this advertisement appears to be unrelated to the rest of the email.The final section of the email provides information regarding a mailing list for Bitcoin development, including a link to subscribe/unsubscribe. 2014-09-23T19:57:10+00:00 + Based on the given context, it appears that there was a conversation between two individuals discussing a proposal called "No-Collision" mode for Multisig BIP32 Wallets. The goal of this proposal is to prevent accidental address re-use and make it easy to identify which devices were used for each transaction in the overall wallet history. Justus Ranvier initially suggested calling this arrangement a "voting pool wallet," but Alan Reiner wanted to make the work public and requested Ranvier to recap or link their work.Ranvier provides links to their work on sourceforge and Github, indicating that they have been publicly sharing their ideas since January 2014 and are currently implementing it in btcwallet. Ranvier expresses frustration with the BIP numbering process, which can pigeonhole proposals. They explain that they have resolved this issue by changing the naming scheme for their proposals and purpose codes to no longer rely on centrally-allocated numbers.In addition to the discussion on the "No-Collision" mode proposal, the email contains an advertisement for an EventLog Analyzer that helps achieve PCI DSS 3.0 compliance. The ad mentions the ability to comply with requirements 10 and 11.5 and provides a link to download a white paper. It should be noted that this advertisement appears to be unrelated to the rest of the email.The final section of the email provides information regarding a mailing list for Bitcoin development, including a link to subscribe/unsubscribe. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_Does-anyone-have-anything-at-all-signed-by-Satoshi-s-PGP-key-.xml b/static/bitcoin-dev/Sept_2014/combined_Does-anyone-have-anything-at-all-signed-by-Satoshi-s-PGP-key-.xml index fbfb98228b..e86b373990 100644 --- a/static/bitcoin-dev/Sept_2014/combined_Does-anyone-have-anything-at-all-signed-by-Satoshi-s-PGP-key-.xml +++ b/static/bitcoin-dev/Sept_2014/combined_Does-anyone-have-anything-at-all-signed-by-Satoshi-s-PGP-key-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Does anyone have anything at all signed by Satoshi's PGP key? - 2023-08-01T10:19:08.983633+00:00 + 2025-10-11T21:44:58.748070+00:00 + python-feedgen Justus Ranvier 2014-09-15 18:06:06+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Does anyone have anything at all signed by Satoshi's PGP key? - 2023-08-01T10:19:08.983633+00:00 + 2025-10-11T21:44:58.748244+00:00 - In a series of email exchanges from 2014, the use of PGP Web of Trust (WoT) for identity verification is criticized. Jeff Garzik argues that a person's behavioral signature is more relevant and suggests that the online entity known as Satoshi's PGP signature would be fine if a pattern of use was established. The debate revolves around the effectiveness of in-person identity vetting versus online behavioral characteristics.Gregory Maxwell expresses concerns about the possibility of email servers replacing public keys and signatures. He requests that the discussion move to another list as it is off-topic. Matt Whitlock points out that simply attaching a public key to emails could allow the server to replace it, resulting in verification issues. The conversation shifts to the detection capabilities of publicly archived mailing lists and the flaws in PGP and its security measures.Thomas Zander suggests including a Bitcoin public key in his email signature as proof of identity. However, it is pointed out that email servers can replace the public key, causing verification problems. Signing messages becomes necessary to ensure the correct public key is used.The use of PGP for identity verification is deemed useless and "stupid geek wanking" by some. It is argued that a decentralized identity management system is needed, allowing the creation of new anonymous IDs when more security is required. The value of in-person vetting of identity is acknowledged but seen as frustrating. Guidelines suggest not trusting or signing an untrusted PGP or GPG key without verifying the person's identity in real life.The relevance of in-person vetting of identity within the Bitcoin community is debated. Jeff Garzik argues that the currency's development relies on code and electronic messages, making real-world identity irrelevant. He dismisses PGP WoT as useless and believes a person's behavioral signature is what matters. Brian Hoffman agrees that in-person vetting can be frustrating but insists on its undeniable value.The conversation also touches on psycho-analytical views on making love and the concept of PGP WoT. The trustworthiness of PGP keys is questioned, with guidelines suggesting in-person verification. The debate revolves around whether PGP is an effective tool for identity verification, with different opinions on its usefulness.The discussion includes Peter Todd questioning whether Satoshi ever used PGP and Thomas Zander pointing out the importance of trusted identity verification for using PGP or GPG keys effectively. The reliability of PGP for identifying Satoshi is questioned due to the lack of evidence.There is no evidence that Satoshi Nakamoto ever signed any private emails or forum posts with PGP, according to Jeff Garzik. This is consistent with information from other sources, including a tweet by Peter Todd. The claim that "Satoshi PGP signed everything" is doubted, and it is speculated that Satoshi may have created the PGP key only for security-related purposes.In an email communication, Peter Todd states that there is no evidence that Satoshi Nakamoto ever signed any communications with PGP. He questions the widely held belief that everything was signed but mentions the possibility of occasional signatures related to releases. Jeff Garzik is mentioned in the email as well.In a recent email, 'peter' states that there is no evidence that Satoshi Nakamoto ever cryptographically signed any communications. This contradicts the claim that "Satoshi PGP signed everything." An attachment of a signature file is included, but its relation to the previous statement is unclear. 2014-09-15T18:06:06+00:00 + In a series of email exchanges from 2014, the use of PGP Web of Trust (WoT) for identity verification is criticized. Jeff Garzik argues that a person's behavioral signature is more relevant and suggests that the online entity known as Satoshi's PGP signature would be fine if a pattern of use was established. The debate revolves around the effectiveness of in-person identity vetting versus online behavioral characteristics.Gregory Maxwell expresses concerns about the possibility of email servers replacing public keys and signatures. He requests that the discussion move to another list as it is off-topic. Matt Whitlock points out that simply attaching a public key to emails could allow the server to replace it, resulting in verification issues. The conversation shifts to the detection capabilities of publicly archived mailing lists and the flaws in PGP and its security measures.Thomas Zander suggests including a Bitcoin public key in his email signature as proof of identity. However, it is pointed out that email servers can replace the public key, causing verification problems. Signing messages becomes necessary to ensure the correct public key is used.The use of PGP for identity verification is deemed useless and "stupid geek wanking" by some. It is argued that a decentralized identity management system is needed, allowing the creation of new anonymous IDs when more security is required. The value of in-person vetting of identity is acknowledged but seen as frustrating. Guidelines suggest not trusting or signing an untrusted PGP or GPG key without verifying the person's identity in real life.The relevance of in-person vetting of identity within the Bitcoin community is debated. Jeff Garzik argues that the currency's development relies on code and electronic messages, making real-world identity irrelevant. He dismisses PGP WoT as useless and believes a person's behavioral signature is what matters. Brian Hoffman agrees that in-person vetting can be frustrating but insists on its undeniable value.The conversation also touches on psycho-analytical views on making love and the concept of PGP WoT. The trustworthiness of PGP keys is questioned, with guidelines suggesting in-person verification. The debate revolves around whether PGP is an effective tool for identity verification, with different opinions on its usefulness.The discussion includes Peter Todd questioning whether Satoshi ever used PGP and Thomas Zander pointing out the importance of trusted identity verification for using PGP or GPG keys effectively. The reliability of PGP for identifying Satoshi is questioned due to the lack of evidence.There is no evidence that Satoshi Nakamoto ever signed any private emails or forum posts with PGP, according to Jeff Garzik. This is consistent with information from other sources, including a tweet by Peter Todd. The claim that "Satoshi PGP signed everything" is doubted, and it is speculated that Satoshi may have created the PGP key only for security-related purposes.In an email communication, Peter Todd states that there is no evidence that Satoshi Nakamoto ever signed any communications with PGP. He questions the widely held belief that everything was signed but mentions the possibility of occasional signatures related to releases. Jeff Garzik is mentioned in the email as well.In a recent email, 'peter' states that there is no evidence that Satoshi Nakamoto ever cryptographically signed any communications. This contradicts the claim that "Satoshi PGP signed everything." An attachment of a signature file is included, but its relation to the previous statement is unclear. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_From-block-0-to-block-72499-the-Merkle-root-is-the-same-as-the-coinbase-transaction-id-Why-is-that-.xml b/static/bitcoin-dev/Sept_2014/combined_From-block-0-to-block-72499-the-Merkle-root-is-the-same-as-the-coinbase-transaction-id-Why-is-that-.xml index e995d21453..7e06d4e5f4 100644 --- a/static/bitcoin-dev/Sept_2014/combined_From-block-0-to-block-72499-the-Merkle-root-is-the-same-as-the-coinbase-transaction-id-Why-is-that-.xml +++ b/static/bitcoin-dev/Sept_2014/combined_From-block-0-to-block-72499-the-Merkle-root-is-the-same-as-the-coinbase-transaction-id-Why-is-that-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - From block 0 to block 72499 the Merkle root is the same as the coinbase transaction id. Why is that? - 2023-08-01T10:19:18.404064+00:00 + 2025-10-11T21:44:52.366911+00:00 + python-feedgen Peter Todd 2014-09-20 16:24:16+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - From block 0 to block 72499 the Merkle root is the same as the coinbase transaction id. Why is that? - 2023-08-01T10:19:18.404064+00:00 + 2025-10-11T21:44:52.367065+00:00 - On September 20, 2014, Peter Grigor raised a question regarding the similarity between the Merkle root and the coinbase transaction ID from block 0 to block 72499 in Bitcoin. This similarity is due to the functioning of the merkle tree algorithm. In this algorithm, all the transaction IDs (txids) are added to a vector called vMerkleTree. However, during the early blocks, there was only one transaction known as the coinbase transaction and no other transactions. As a result, the for loop in the algorithm never executes because the size of vtx (the vector containing transactions) is always equal to 1.In a discussion on the Bitcoin-development mailing list, Peter Grigor explains that only specific transactions in the Bitcoin blockchain have associated Coinbase transactions and nothing else. When a tree has only one item, the merkle root is simply the hash of that item. Unfortunately, the context does not provide any additional information regarding this topic. 2014-09-20T16:24:16+00:00 + On September 20, 2014, Peter Grigor raised a question regarding the similarity between the Merkle root and the coinbase transaction ID from block 0 to block 72499 in Bitcoin. This similarity is due to the functioning of the merkle tree algorithm. In this algorithm, all the transaction IDs (txids) are added to a vector called vMerkleTree. However, during the early blocks, there was only one transaction known as the coinbase transaction and no other transactions. As a result, the for loop in the algorithm never executes because the size of vtx (the vector containing transactions) is always equal to 1.In a discussion on the Bitcoin-development mailing list, Peter Grigor explains that only specific transactions in the Bitcoin blockchain have associated Coinbase transactions and nothing else. When a tree has only one item, the merkle root is simply the hash of that item. Unfortunately, the context does not provide any additional information regarding this topic. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_New-opcodes-and-transaction-version-numbers-was-relax-the-IsStandard-rules-for-P2SH-transactions-.xml b/static/bitcoin-dev/Sept_2014/combined_New-opcodes-and-transaction-version-numbers-was-relax-the-IsStandard-rules-for-P2SH-transactions-.xml index 7e602d5a43..882abfff9b 100644 --- a/static/bitcoin-dev/Sept_2014/combined_New-opcodes-and-transaction-version-numbers-was-relax-the-IsStandard-rules-for-P2SH-transactions-.xml +++ b/static/bitcoin-dev/Sept_2014/combined_New-opcodes-and-transaction-version-numbers-was-relax-the-IsStandard-rules-for-P2SH-transactions-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions') - 2023-08-01T10:21:58.503901+00:00 + 2025-10-11T21:44:56.621951+00:00 + python-feedgen Peter Todd 2014-09-29 05:35:26+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions') - 2023-08-01T10:21:58.503901+00:00 + 2025-10-11T21:44:56.622077+00:00 - In a discussion about adding new opcodes to P2SH, Alan Reiner suggested updating the address format to include a transaction version number. However, Peter Todd argued that this would require new addresses for each new opcode, which goes against the purpose of P2SH. He also pointed out that when a wallet creates a transaction, the scriptPubKeys in the outputs are determined by the receiver(s) and are not executed until they are spent. Therefore, the wallet does not need to be concerned with the contents of those scriptPubKeys. Additionally, determining which version number to use becomes difficult when there are multiple recipients.Peter Todd further criticized Satoshi's implementation of a per-block sigop limit, stating that it computes the limit based on all scriptSigs and scriptPubKeys in the block, even though the latter are not executed. This allows for blocks that pass the sigop limit but execute expensive signature operations by having scriptSigs spending txouts with large numbers of sigops in their scriptPubKeys. While P2SH improves on this situation by counting the sigops in redeemScripts towards the limit, it misses the opportunity to count all sigops in all scriptSigs directly.In an email thread from September 28th, 2014, Peter Todd suggests upgrading the address format to indicate that senders must use a transaction with an increased version number to solve a specific issue. However, he acknowledges that creating new addresses for every new opcode would defeat the purpose of P2SH. Another developer proposes a single update to the address format that includes a transaction version number, prompting sending software to apply that version to the payment transaction. While this may work for soft forks, there are potential subtleties and safety concerns to consider.The discussion revolves around the process of soft forks bumping version numbers in Bitcoin. There is consensus that this is the preferred method, and Gavin Andresen's proposal on Github has been suggested to become an informational BIP. However, one user highlights an issue with the proposal regarding the unclear definition of "use" for a new opcode. If scriptPubKey evaluation is based on the transaction version number of the creating transaction, non-upgraded clients sending funds to a P2SH address with a redeemScript using a new opcode may create scriptPubKeys that can be spent by anyone. Conversely, if scriptPubKey evaluation is based on the version of the spending transaction, outputs using the new opcode can be easily spent.The assertion that "P2SH should have been done by upgrading the tx version #" for future opcode upgrades is incorrect. Additionally, the "Relax IsStandard rules for P2SH transactions" pull request is incomplete as it does not blacklist the usage of upgradable NOPx opcodes. This could lead to non-upgraded nodes accepting and mining transactions that are now invalid, resulting in false confirmations. To address this issue, a pull request has been created to specifically blacklist the NOPx opcodes if they are executed.Furthermore, the "Blockchain Rule Update Process" gist should be rewritten to state that new opcodes will be enabled for all scripts through the block nVersion upgrade mechanism. BIP62 proposes increasing the transaction version number to indicate the sender's desire for anti-malleability rules to be applied. This usage of tx version numbers is appropriate as the creator of the transaction wants the anti-malleability rules applied, while the person creating the scriptPubKey being spent does not care. The new owners of the txouts being created typically do not care how they were created. 2014-09-29T05:35:26+00:00 + In a discussion about adding new opcodes to P2SH, Alan Reiner suggested updating the address format to include a transaction version number. However, Peter Todd argued that this would require new addresses for each new opcode, which goes against the purpose of P2SH. He also pointed out that when a wallet creates a transaction, the scriptPubKeys in the outputs are determined by the receiver(s) and are not executed until they are spent. Therefore, the wallet does not need to be concerned with the contents of those scriptPubKeys. Additionally, determining which version number to use becomes difficult when there are multiple recipients.Peter Todd further criticized Satoshi's implementation of a per-block sigop limit, stating that it computes the limit based on all scriptSigs and scriptPubKeys in the block, even though the latter are not executed. This allows for blocks that pass the sigop limit but execute expensive signature operations by having scriptSigs spending txouts with large numbers of sigops in their scriptPubKeys. While P2SH improves on this situation by counting the sigops in redeemScripts towards the limit, it misses the opportunity to count all sigops in all scriptSigs directly.In an email thread from September 28th, 2014, Peter Todd suggests upgrading the address format to indicate that senders must use a transaction with an increased version number to solve a specific issue. However, he acknowledges that creating new addresses for every new opcode would defeat the purpose of P2SH. Another developer proposes a single update to the address format that includes a transaction version number, prompting sending software to apply that version to the payment transaction. While this may work for soft forks, there are potential subtleties and safety concerns to consider.The discussion revolves around the process of soft forks bumping version numbers in Bitcoin. There is consensus that this is the preferred method, and Gavin Andresen's proposal on Github has been suggested to become an informational BIP. However, one user highlights an issue with the proposal regarding the unclear definition of "use" for a new opcode. If scriptPubKey evaluation is based on the transaction version number of the creating transaction, non-upgraded clients sending funds to a P2SH address with a redeemScript using a new opcode may create scriptPubKeys that can be spent by anyone. Conversely, if scriptPubKey evaluation is based on the version of the spending transaction, outputs using the new opcode can be easily spent.The assertion that "P2SH should have been done by upgrading the tx version #" for future opcode upgrades is incorrect. Additionally, the "Relax IsStandard rules for P2SH transactions" pull request is incomplete as it does not blacklist the usage of upgradable NOPx opcodes. This could lead to non-upgraded nodes accepting and mining transactions that are now invalid, resulting in false confirmations. To address this issue, a pull request has been created to specifically blacklist the NOPx opcodes if they are executed.Furthermore, the "Blockchain Rule Update Process" gist should be rewritten to state that new opcodes will be enabled for all scripts through the block nVersion upgrade mechanism. BIP62 proposes increasing the transaction version number to indicate the sender's desire for anti-malleability rules to be applied. This usage of tx version numbers is appropriate as the creator of the transaction wants the anti-malleability rules applied, while the person creating the scriptPubKey being spent does not care. The new owners of the txouts being created typically do not care how they were created. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml b/static/bitcoin-dev/Sept_2014/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml index 2f4ea88d33..ea8c0301c2 100644 --- a/static/bitcoin-dev/Sept_2014/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml +++ b/static/bitcoin-dev/Sept_2014/combined_Payment-Protocol-Proposal-Invoices-Payments-Receipts.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Payment Protocol Proposal: Invoices/Payments/Receipts - 2023-08-01T04:10:51.910113+00:00 + 2025-10-11T21:44:45.993898+00:00 + python-feedgen Vezalke 2014-09-17 19:28:08+00:00 @@ -351,13 +352,13 @@ - python-feedgen + 2 Combined summary - Payment Protocol Proposal: Invoices/Payments/Receipts - 2023-08-01T04:10:51.912154+00:00 + 2025-10-11T21:44:45.994210+00:00 - In a series of discussions on the Bitcoin-development mailing list, various topics related to Bitcoin payment protocols were addressed. One discussion focused on the implementation of a "pass around" method, which was considered simpler and easier to implement for experts in the early stages. Another topic discussed was the launch of Crypto-Games.net, an online gambling platform designed specifically for slot machine betting using cryptocurrencies like Bitcoin, Litecoin, and Dogecoin.The need for a secure and private messaging system as the first step in implementing a payment protocol was emphasized by Stephen Pair. A proposal suggested using signed and authenticated "invoices" and "receipts" with X.509 certificates as an identity system for merchants. The proposal also covered multi-signature wallet scenarios and the use of Protocol Buffers as an encoding format.The debate between binary and text formats in the Bitcoin protocol was addressed, with arguments for both sides. The advantages of JSON for accessibility were acknowledged, but concerns were raised about maintaining field order and complexity. The discussion highlighted the lack of compelling arguments for text formats and the need for further research before making a final decision.Other discussions covered topics such as the migration to textual representation, the use of root CAs in the system, and the challenges of confirming the validity of addresses displayed on computer screens. There were also proposals for extending the protocol, handling payment failures, and ensuring the security of paying invoices with Bitcoin.Ensuring consistency and security in Bitcoin transactions is a top priority for sellers. The use of Certificate Authorities (CAs) plays a crucial role in verifying website or server identities and establishing secure connections. In a discussion on November 26, 2012, Mike Hearn emphasized the need for consistency in Bitcoin transactions and suggested supporting all CAs used by popular browsers. However, he expressed a preference for user-accepted certificates at the operating system level to address potential restrictions. The goal was to establish secure communication between users and servers.The limitations of X.509 for the web were also discussed, particularly regarding delegation and the potential undermining of the benefits of chained certificates. To enhance security for payment processors, the proposal suggests issuing a new certificate specifically for signing Bitcoin transactions. It is recommended to redefine the certificate chain part of the protocol to allow for the introduction of new minimal certificate formats with desired features. Compatibility issues may arise for old clients encountering unfamiliar invoice cert types, so the suggestion is made to include a protocol version number when downloading invoices to ensure safe utilization of new invoice features.In addition to certificate discussions, the Bitcoin development community is considering various new features for the digital currency. This includes switching from JSON to a binary format for more efficient and secure data transfer. Another proposed feature is the ability for merchants to cover transaction processing fees. Three potential methods are suggested for implementing this feature, such as adding a 'maxfee' field to the invoice, altering the transaction selection code used by Bitcoin miners, and signing Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag.Another protocol proposal involves utilizing protocol buffer-based formats for signed, authenticated "invoices" and "receipts." Invoices serve as payment requests from merchants to customers and contain outputs specifying where Bitcoins are to be sent. These invoices must include one or more DER-encoded X.509 certificates identifying the merchant, validated according to [RFC5280]. Authenticated identities are linked to invoices, which also include a description of the payment, refund details, and a cryptographically signed receipt that serves as proof-of-payment during disputes with merchants. Merchants will incorporate this proposal into their checkout process, while customers receive SignedInvoice, authorize payment, and create the Payment message, which is then submitted to the site's payment URI.After the payment transaction is validated and broadcasted, a SignedReceipt is returned, indicating either a "You win" or "You lost" memo. The Bitcoin development community is also exploring the possibility of using the Online Certificate Checking Protocol (OCSP) to check for revoked certificates. However, concerns exist regarding the effectiveness of this approach, as it may introduce delays or false-positive rejections if the OCSP endpoint experiences downtime or becomes overwhelmed.Overall, the discussions revolve around improving security and authentication in Bitcoin invoice payments, exploring different identification types, clarifying terminology, and considering alternative approaches to achieve the desired functionality. The Bitcoin development community is actively seeking feedback from other developers to refine these proposals and ensure the continued growth and security of the digital currency. 2014-09-17T19:28:08+00:00 + In a series of discussions on the Bitcoin-development mailing list, various topics related to Bitcoin payment protocols were addressed. One discussion focused on the implementation of a "pass around" method, which was considered simpler and easier to implement for experts in the early stages. Another topic discussed was the launch of Crypto-Games.net, an online gambling platform designed specifically for slot machine betting using cryptocurrencies like Bitcoin, Litecoin, and Dogecoin.The need for a secure and private messaging system as the first step in implementing a payment protocol was emphasized by Stephen Pair. A proposal suggested using signed and authenticated "invoices" and "receipts" with X.509 certificates as an identity system for merchants. The proposal also covered multi-signature wallet scenarios and the use of Protocol Buffers as an encoding format.The debate between binary and text formats in the Bitcoin protocol was addressed, with arguments for both sides. The advantages of JSON for accessibility were acknowledged, but concerns were raised about maintaining field order and complexity. The discussion highlighted the lack of compelling arguments for text formats and the need for further research before making a final decision.Other discussions covered topics such as the migration to textual representation, the use of root CAs in the system, and the challenges of confirming the validity of addresses displayed on computer screens. There were also proposals for extending the protocol, handling payment failures, and ensuring the security of paying invoices with Bitcoin.Ensuring consistency and security in Bitcoin transactions is a top priority for sellers. The use of Certificate Authorities (CAs) plays a crucial role in verifying website or server identities and establishing secure connections. In a discussion on November 26, 2012, Mike Hearn emphasized the need for consistency in Bitcoin transactions and suggested supporting all CAs used by popular browsers. However, he expressed a preference for user-accepted certificates at the operating system level to address potential restrictions. The goal was to establish secure communication between users and servers.The limitations of X.509 for the web were also discussed, particularly regarding delegation and the potential undermining of the benefits of chained certificates. To enhance security for payment processors, the proposal suggests issuing a new certificate specifically for signing Bitcoin transactions. It is recommended to redefine the certificate chain part of the protocol to allow for the introduction of new minimal certificate formats with desired features. Compatibility issues may arise for old clients encountering unfamiliar invoice cert types, so the suggestion is made to include a protocol version number when downloading invoices to ensure safe utilization of new invoice features.In addition to certificate discussions, the Bitcoin development community is considering various new features for the digital currency. This includes switching from JSON to a binary format for more efficient and secure data transfer. Another proposed feature is the ability for merchants to cover transaction processing fees. Three potential methods are suggested for implementing this feature, such as adding a 'maxfee' field to the invoice, altering the transaction selection code used by Bitcoin miners, and signing Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag.Another protocol proposal involves utilizing protocol buffer-based formats for signed, authenticated "invoices" and "receipts." Invoices serve as payment requests from merchants to customers and contain outputs specifying where Bitcoins are to be sent. These invoices must include one or more DER-encoded X.509 certificates identifying the merchant, validated according to [RFC5280]. Authenticated identities are linked to invoices, which also include a description of the payment, refund details, and a cryptographically signed receipt that serves as proof-of-payment during disputes with merchants. Merchants will incorporate this proposal into their checkout process, while customers receive SignedInvoice, authorize payment, and create the Payment message, which is then submitted to the site's payment URI.After the payment transaction is validated and broadcasted, a SignedReceipt is returned, indicating either a "You win" or "You lost" memo. The Bitcoin development community is also exploring the possibility of using the Online Certificate Checking Protocol (OCSP) to check for revoked certificates. However, concerns exist regarding the effectiveness of this approach, as it may introduce delays or false-positive rejections if the OCSP endpoint experiences downtime or becomes overwhelmed.Overall, the discussions revolve around improving security and authentication in Bitcoin invoice payments, exploring different identification types, clarifying terminology, and considering alternative approaches to achieve the desired functionality. The Bitcoin development community is actively seeking feedback from other developers to refine these proposals and ensure the continued growth and security of the digital currency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_Proposal-No-Collision-mode-for-Multisig-BIP32-Wallets.xml b/static/bitcoin-dev/Sept_2014/combined_Proposal-No-Collision-mode-for-Multisig-BIP32-Wallets.xml index 39709ff0ab..64bbdb5e29 100644 --- a/static/bitcoin-dev/Sept_2014/combined_Proposal-No-Collision-mode-for-Multisig-BIP32-Wallets.xml +++ b/static/bitcoin-dev/Sept_2014/combined_Proposal-No-Collision-mode-for-Multisig-BIP32-Wallets.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - Proposal: "No-Collision" mode for Multisig BIP32 Wallets - 2023-08-01T10:19:36.218439+00:00 + Combined summary - Proposal: "No-Collision" mode for Multisig BIP32 Wallets + 2025-10-11T21:45:11.493390+00:00 + python-feedgen Justus Ranvier 2014-09-23 17:07:58+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 - Combined summary - Proposal: "No-Collision" mode for Multisig BIP32 Wallets - 2023-08-01T10:19:36.219438+00:00 + Combined summary - Proposal: "No-Collision" mode for Multisig BIP32 Wallets + 2025-10-11T21:45:11.493613+00:00 - Alan Reiner requested a recap and link for a discussion provided by Justus Ranvier on the Open Transactions wiki. The BIP numbering process was criticized, and Open-Transactions resolved this by changing their proposal naming scheme and purpose codes. Justus Ranvier expressed disappointment in not being mentioned in Alan's work, which they shared in January and have been publicly documenting since then. In response, Alan asked Justus to recap/link the information for inclusion. Alan clarified that he receives many emails and nine months is a long time in this field, so he didn't want Justus to assume any negative intentions. Alan emphasized that he has no problem giving credit where it is due.In September 2014, Alan Reiner asked for suggestions to change the name "No-Collision Mode." Justus Ranvier proposed calling it a "voting pool wallet" since that was its original application. Justus also requested that Reiner mention their work, as they had publicly documented it since sharing it with him in January. Justus questioned whether implementing the idea in btcwallet made it unmentionable. The message included a PGP signature and an attachment of public key ID 0x38450DB5.The proposal is for a BIP related to multisig wallets based on BIP32. It suggests having N internal chains and N external chains for an M-of-N multisig wallet. Each party is assigned a chain based on the lexicographic ordering of their wallet's root public key, ensuring no duplication of addresses. This system provides built-in bookkeeping and allows easy identification of transaction responsibility. An alternative suggestion is assigning each "device" a pair of chains, such as in a 2-of-3 scenario with a CFO having a "watch-only" version of the wallet. The document linked in the proposal contains visual descriptions of the concept.Overall, Justus Ranvier's contributions and concerns regarding the BIP proposal and the implementation of "No-Collision Mode" were discussed, with Alan Reiner requesting a recap/link to include Justus's work. 2014-09-23T17:07:58+00:00 + Alan Reiner requested a recap and link for a discussion provided by Justus Ranvier on the Open Transactions wiki. The BIP numbering process was criticized, and Open-Transactions resolved this by changing their proposal naming scheme and purpose codes. Justus Ranvier expressed disappointment in not being mentioned in Alan's work, which they shared in January and have been publicly documenting since then. In response, Alan asked Justus to recap/link the information for inclusion. Alan clarified that he receives many emails and nine months is a long time in this field, so he didn't want Justus to assume any negative intentions. Alan emphasized that he has no problem giving credit where it is due.In September 2014, Alan Reiner asked for suggestions to change the name "No-Collision Mode." Justus Ranvier proposed calling it a "voting pool wallet" since that was its original application. Justus also requested that Reiner mention their work, as they had publicly documented it since sharing it with him in January. Justus questioned whether implementing the idea in btcwallet made it unmentionable. The message included a PGP signature and an attachment of public key ID 0x38450DB5.The proposal is for a BIP related to multisig wallets based on BIP32. It suggests having N internal chains and N external chains for an M-of-N multisig wallet. Each party is assigned a chain based on the lexicographic ordering of their wallet's root public key, ensuring no duplication of addresses. This system provides built-in bookkeeping and allows easy identification of transaction responsibility. An alternative suggestion is assigning each "device" a pair of chains, such as in a 2-of-3 scenario with a CFO having a "watch-only" version of the wallet. The document linked in the proposal contains visual descriptions of the concept.Overall, Justus Ranvier's contributions and concerns regarding the BIP proposal and the implementation of "No-Collision Mode" were discussed, with Alan Reiner requesting a recap/link to include Justus's work. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_SPV-clients-and-relaying-double-spends.xml b/static/bitcoin-dev/Sept_2014/combined_SPV-clients-and-relaying-double-spends.xml index 7ba9d854f1..fe2dfad642 100644 --- a/static/bitcoin-dev/Sept_2014/combined_SPV-clients-and-relaying-double-spends.xml +++ b/static/bitcoin-dev/Sept_2014/combined_SPV-clients-and-relaying-double-spends.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - SPV clients and relaying double spends - 2023-08-01T10:20:55.617889+00:00 + 2025-10-11T21:45:07.243733+00:00 + python-feedgen Tom Harding 2014-09-28 02:55:44+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - SPV clients and relaying double spends - 2023-08-01T10:20:55.617889+00:00 + 2025-10-11T21:45:07.243913+00:00 - During a discussion in September 2014, Aaron Voisine suggested that nodes should relay double-spends to alert the network about such attempts. This would be beneficial for Simplified Payment Verification (SPV) clients who cannot detect double-spends on their own. However, there was a concern about flooding the network with millions of spends of the same output(s), which could overwhelm slower connections. To prevent this, it was proposed that after two attempts to spend the same output, no further transactions spending that output should be relayed. Additionally, it was suggested that nodes should send reject messages, such as BIP61, to indicate which transactions they believe to be invalid but are still relaying. This would increase the cost of performing a 0 confirmation double spend attack on an SPV client. However, these measures could still be vulnerable to sybil attacks. The ongoing discussion can be found on the Bitcoin-development mailing list. 2014-09-28T02:55:44+00:00 + During a discussion in September 2014, Aaron Voisine suggested that nodes should relay double-spends to alert the network about such attempts. This would be beneficial for Simplified Payment Verification (SPV) clients who cannot detect double-spends on their own. However, there was a concern about flooding the network with millions of spends of the same output(s), which could overwhelm slower connections. To prevent this, it was proposed that after two attempts to spend the same output, no further transactions spending that output should be relayed. Additionally, it was suggested that nodes should send reject messages, such as BIP61, to indicate which transactions they believe to be invalid but are still relaying. This would increase the cost of performing a 0 confirmation double spend attack on an SPV client. However, these measures could still be vulnerable to sybil attacks. The ongoing discussion can be found on the Bitcoin-development mailing list. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_Small-update-to-BIP-62.xml b/static/bitcoin-dev/Sept_2014/combined_Small-update-to-BIP-62.xml index b2db88c993..af3d43d18d 100644 --- a/static/bitcoin-dev/Sept_2014/combined_Small-update-to-BIP-62.xml +++ b/static/bitcoin-dev/Sept_2014/combined_Small-update-to-BIP-62.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Small update to BIP 62 - 2023-08-01T09:52:51.137865+00:00 + 2025-10-11T21:44:48.120624+00:00 + python-feedgen Pieter Wuille 2014-09-13 22:45:14+00:00 @@ -79,13 +80,13 @@ - python-feedgen + 2 Combined summary - Small update to BIP 62 - 2023-08-01T09:52:51.137865+00:00 + 2025-10-11T21:44:48.120821+00:00 - On September 8, 2014, Pieter Wuille made changes to the Bitcoin Improvement Proposal (BIP) repository, specifically altering the order of rules and adding reference documentation. He later sent another pull request on September 12, 2014, focusing on compressed or uncompressed public keys. During discussions with Gregory Maxwell, concerns were raised about the lack of specificity in rule 4 of BIP 62. Wuille agreed to address this issue by making updates to the text. The conversation also touched upon additional consensus rules and their limitations. In response, Wuille sent a new pull request for BIP 62, clarifying the limitations of the rules and reordering them.In another discussion about BIP 62, Gregory Maxwell expressed concerns about the lack of specificity in rule 4. Wuille acknowledged the issue and planned to make necessary changes. They also discussed the reordering of rules and the presence of inherently malleable scriptPubkeys. During a conversation about cryptographic protocols, Gregory Maxwell explained the properties of the DSA nonce and why duplicating the verifier's generation of k is impossible. He emphasized that attackers are not bound by protocols unless prevented and that proving a specific nonce generation scheme without revealing the private key is unreasonable. In a discussion about BIP 62, Mike Hearn questioned the necessity of rule 4. Wladimir explained that non-push operations in scriptSig can lead to malleability, which the rule aims to prevent. Aaron Voisine and Gregory Maxwell debated the effectiveness of deterministic signing and randomness-free signature systems in relation to the DSA nonce and its implications for Bitcoin transactions.Pieter Wuille sent a pull request to modify BIP 62, making two new rules mandatory for old-style transactions. He explained the rationale behind this change and stressed the importance of strict DER compliance for signatures. In a separate conversation, Wuille discussed the absence of non-DER signatures in recent blocks with an unidentified individual.Mike Hearn and Pieter discussed potential changes to Bitcoin's consensus rules, including the necessity of rule 4 and the significance of backwards compatibility. The author of the context questioned the reasoning behind rule 4 and expressed a preference for preserving compatibility until older versions are phased out. Wuille subsequently sent a pull request to modify BIP 62, removing the requirement for bug-for-bug compatibility with OpenSSL and suggesting investigating non-DER signatures in blocks before making any changes.Furthermore, Pieter Wuille, a Bitcoin Core developer, has proposed a change to the Bitcoin protocol to support Discrete Log Contracts (DLCs) on the network. DLCs are smart contracts that enable trustless, non-custodial financial agreements between parties. The proposed change introduces a new opcode, OP_DLC, which would facilitate the execution of DLCs without altering the underlying Bitcoin infrastructure. The suggested modifications also enhance the Bitcoin scripting language, enabling complex contract logic.To ensure successful implementation, Wuille is actively seeking comments and feedback from the Bitcoin community. He has shared a draft of the proposed changes on the Bitcoin development mailing list, inviting developers and stakeholders to review and provide input. By incorporating DLCs into the Bitcoin protocol, Wuille believes it will expand the possibilities of decentralized finance and smart contract applications on the network. This includes prediction markets where users can bet on real-world events and decentralized derivatives trading without centralized intermediaries. Overall, the proposal aims to enhance the functionality and versatility of the Bitcoin network through the introduction of support for Discrete Log Contracts. 2014-09-13T22:45:14+00:00 + On September 8, 2014, Pieter Wuille made changes to the Bitcoin Improvement Proposal (BIP) repository, specifically altering the order of rules and adding reference documentation. He later sent another pull request on September 12, 2014, focusing on compressed or uncompressed public keys. During discussions with Gregory Maxwell, concerns were raised about the lack of specificity in rule 4 of BIP 62. Wuille agreed to address this issue by making updates to the text. The conversation also touched upon additional consensus rules and their limitations. In response, Wuille sent a new pull request for BIP 62, clarifying the limitations of the rules and reordering them.In another discussion about BIP 62, Gregory Maxwell expressed concerns about the lack of specificity in rule 4. Wuille acknowledged the issue and planned to make necessary changes. They also discussed the reordering of rules and the presence of inherently malleable scriptPubkeys. During a conversation about cryptographic protocols, Gregory Maxwell explained the properties of the DSA nonce and why duplicating the verifier's generation of k is impossible. He emphasized that attackers are not bound by protocols unless prevented and that proving a specific nonce generation scheme without revealing the private key is unreasonable. In a discussion about BIP 62, Mike Hearn questioned the necessity of rule 4. Wladimir explained that non-push operations in scriptSig can lead to malleability, which the rule aims to prevent. Aaron Voisine and Gregory Maxwell debated the effectiveness of deterministic signing and randomness-free signature systems in relation to the DSA nonce and its implications for Bitcoin transactions.Pieter Wuille sent a pull request to modify BIP 62, making two new rules mandatory for old-style transactions. He explained the rationale behind this change and stressed the importance of strict DER compliance for signatures. In a separate conversation, Wuille discussed the absence of non-DER signatures in recent blocks with an unidentified individual.Mike Hearn and Pieter discussed potential changes to Bitcoin's consensus rules, including the necessity of rule 4 and the significance of backwards compatibility. The author of the context questioned the reasoning behind rule 4 and expressed a preference for preserving compatibility until older versions are phased out. Wuille subsequently sent a pull request to modify BIP 62, removing the requirement for bug-for-bug compatibility with OpenSSL and suggesting investigating non-DER signatures in blocks before making any changes.Furthermore, Pieter Wuille, a Bitcoin Core developer, has proposed a change to the Bitcoin protocol to support Discrete Log Contracts (DLCs) on the network. DLCs are smart contracts that enable trustless, non-custodial financial agreements between parties. The proposed change introduces a new opcode, OP_DLC, which would facilitate the execution of DLCs without altering the underlying Bitcoin infrastructure. The suggested modifications also enhance the Bitcoin scripting language, enabling complex contract logic.To ensure successful implementation, Wuille is actively seeking comments and feedback from the Bitcoin community. He has shared a draft of the proposed changes on the Bitcoin development mailing list, inviting developers and stakeholders to review and provide input. By incorporating DLCs into the Bitcoin protocol, Wuille believes it will expand the possibilities of decentralized finance and smart contract applications on the network. This includes prediction markets where users can bet on real-world events and decentralized derivatives trading without centralized intermediaries. Overall, the proposal aims to enhance the functionality and versatility of the Bitcoin network through the introduction of support for Discrete Log Contracts. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_cryptographic-review-requested.xml b/static/bitcoin-dev/Sept_2014/combined_cryptographic-review-requested.xml index 711b652c72..6de9d81a1d 100644 --- a/static/bitcoin-dev/Sept_2014/combined_cryptographic-review-requested.xml +++ b/static/bitcoin-dev/Sept_2014/combined_cryptographic-review-requested.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - cryptographic review requested - 2023-08-01T10:20:13.759645+00:00 + 2025-10-11T21:45:09.368752+00:00 + python-feedgen Pavol Rusnak 2014-10-22 14:56:37+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - cryptographic review requested - 2023-08-01T10:20:13.759645+00:00 + 2025-10-11T21:45:09.368933+00:00 - On September 23, 2014, Mem Wallet raised a question about the use of deterministic nonces for ECIES and the potential consequences. The recipient of the email responded by stating that while using deterministic nonces for signatures is acceptable, they should not be used for ECIES unless they are high-quality random bytes. Unit test vectors were mentioned as a possible exception to this rule.In a separate email conversation on October 22, 2014, Chris D'Costa expressed concerns about ensuring that the public key received for encrypting a message is not from a Man-In-The-Middle (MITM) attacker. Pavol Rusnak asked if this was the same problem with PGP.In another email exchange on September 23, 2014, Mem Wallet and Pavol Rusnak discussed a proposed change to BIP44 to include identity keys for structured wallets. Mem Wallet suggested creating a new BIP to describe the HD paths used for ECIES, referring to a working implementation available at http://memwallet.info/btcmssgs.html. Pavol Rusnak agreed that the implementation seemed complete and proposed pushing it as a new BIP for review and standardization.The provided context mentions a proposal for a standardized ECIES scheme for Bitcoin communication, which also includes a proposed change to BIP44. The scheme allows for secure messaging using a Bitcoin wallet without requiring additional software. It enables address owners to prove ownership privately to other address holders without the need for secure communication channels.The scheme described in the document uses CompactSize format for serialization and assumes familiarity with the Bitcoin compact signature format. The sender's address is included for signature validation. The scheme employs HMAC_SHA256 for MAC and PBKDF2 for KDF, with specific iterations and salt values. AES with 256-bit keys and CFB mode with a 128-bit feedback buffer are used for encryption. No padding or envelope is used.The compact_signed_message and compact_unsigned_message formats are explained, along with the inputs for the SendMessage and ReceiveMessage functions. Test vectors are provided in different formats, including WIF, base58_check, C-style UTF-8 string literals, and Base64.It is mentioned that compliant implementations should use random nonces from a cryptographically strong DRBG. The context includes a cryptographic address and a signing address, and the implementation can be found on memwallet.info/btcmssgs.html. The credit for the implementation goes to 76NPRHE2g5pSvbLgP8fEEtBvfPB4zte56veXdxXfaXcsQwRjZB (1Lk96ASyr3k6ZoTFGLrUgxGuctNKF24V5q), with acknowledgments to bitaddress.org, brainwallet.org, and other contributors who have simplified cryptocurrency and Bitcoin coding in JavaScript. 2014-10-22T14:56:37+00:00 + On September 23, 2014, Mem Wallet raised a question about the use of deterministic nonces for ECIES and the potential consequences. The recipient of the email responded by stating that while using deterministic nonces for signatures is acceptable, they should not be used for ECIES unless they are high-quality random bytes. Unit test vectors were mentioned as a possible exception to this rule.In a separate email conversation on October 22, 2014, Chris D'Costa expressed concerns about ensuring that the public key received for encrypting a message is not from a Man-In-The-Middle (MITM) attacker. Pavol Rusnak asked if this was the same problem with PGP.In another email exchange on September 23, 2014, Mem Wallet and Pavol Rusnak discussed a proposed change to BIP44 to include identity keys for structured wallets. Mem Wallet suggested creating a new BIP to describe the HD paths used for ECIES, referring to a working implementation available at http://memwallet.info/btcmssgs.html. Pavol Rusnak agreed that the implementation seemed complete and proposed pushing it as a new BIP for review and standardization.The provided context mentions a proposal for a standardized ECIES scheme for Bitcoin communication, which also includes a proposed change to BIP44. The scheme allows for secure messaging using a Bitcoin wallet without requiring additional software. It enables address owners to prove ownership privately to other address holders without the need for secure communication channels.The scheme described in the document uses CompactSize format for serialization and assumes familiarity with the Bitcoin compact signature format. The sender's address is included for signature validation. The scheme employs HMAC_SHA256 for MAC and PBKDF2 for KDF, with specific iterations and salt values. AES with 256-bit keys and CFB mode with a 128-bit feedback buffer are used for encryption. No padding or envelope is used.The compact_signed_message and compact_unsigned_message formats are explained, along with the inputs for the SendMessage and ReceiveMessage functions. Test vectors are provided in different formats, including WIF, base58_check, C-style UTF-8 string literals, and Base64.It is mentioned that compliant implementations should use random nonces from a cryptographically strong DRBG. The context includes a cryptographic address and a signing address, and the implementation can be found on memwallet.info/btcmssgs.html. The credit for the implementation goes to 76NPRHE2g5pSvbLgP8fEEtBvfPB4zte56veXdxXfaXcsQwRjZB (1Lk96ASyr3k6ZoTFGLrUgxGuctNKF24V5q), with acknowledgments to bitaddress.org, brainwallet.org, and other contributors who have simplified cryptocurrency and Bitcoin coding in JavaScript. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2014/combined_replace-by-fee-v0-9-3-release.xml b/static/bitcoin-dev/Sept_2014/combined_replace-by-fee-v0-9-3-release.xml index 0bb12f0263..3403ec2531 100644 --- a/static/bitcoin-dev/Sept_2014/combined_replace-by-fee-v0-9-3-release.xml +++ b/static/bitcoin-dev/Sept_2014/combined_replace-by-fee-v0-9-3-release.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - replace-by-fee v0.9.3 release - 2023-08-01T10:21:28.439958+00:00 + 2025-10-11T21:45:00.872014+00:00 + python-feedgen Luke Dashjr 2014-09-28 17:03:50+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - replace-by-fee v0.9.3 release - 2023-08-01T10:21:28.439958+00:00 + 2025-10-11T21:45:00.872161+00:00 - During a discussion on Bitcoin's development mailing list, Tom Harding raised the question of how nodes could verify double-spend alerts independently. Harding shared issue #4570 as an example, which relays the first double-spend as an alert. To further illustrate his point, Harding has been maintaining a real-time list of relayed double-spend transactions on http://respends.thinlink.com.Peter Todd responded to Harding's query by mentioning that he recently ported his replace-by-fee branch to the v0.9.3 release. He added that this new version includes a scriptSig size limit increase, which introduces a new category of double-spending exploit. However, Todd noted that he would require at least another week before he could incorporate this exploit into his replace-by-fee toolkit.In response to Luke's question, there was no mention of a version compatible with CPFP (Child-Pays-for-Parent). 2014-09-28T17:03:50+00:00 + During a discussion on Bitcoin's development mailing list, Tom Harding raised the question of how nodes could verify double-spend alerts independently. Harding shared issue #4570 as an example, which relays the first double-spend as an alert. To further illustrate his point, Harding has been maintaining a real-time list of relayed double-spend transactions on http://respends.thinlink.com.Peter Todd responded to Harding's query by mentioning that he recently ported his replace-by-fee branch to the v0.9.3 release. He added that this new version includes a scriptSig size limit increase, which introduces a new category of double-spending exploit. However, Todd noted that he would require at least another week before he could incorporate this exploit into his replace-by-fee toolkit.In response to Luke's question, there was no mention of a version compatible with CPFP (Child-Pays-for-Parent). - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_-BIP-Draft-BIP-Acceptance-Process.xml b/static/bitcoin-dev/Sept_2015/combined_-BIP-Draft-BIP-Acceptance-Process.xml index b12c531842..1d5fddd35c 100644 --- a/static/bitcoin-dev/Sept_2015/combined_-BIP-Draft-BIP-Acceptance-Process.xml +++ b/static/bitcoin-dev/Sept_2015/combined_-BIP-Draft-BIP-Acceptance-Process.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP/Draft] BIP Acceptance Process - 2023-08-01T15:59:58.337872+00:00 + 2025-10-11T21:54:26.340230+00:00 + python-feedgen Dave Scotese 2016-01-19 06:07:52+00:00 @@ -87,13 +88,13 @@ - python-feedgen + 2 Combined summary - [BIP/Draft] BIP Acceptance Process - 2023-08-01T15:59:58.337872+00:00 + 2025-10-11T21:54:26.340446+00:00 - The current process for Bitcoin Improvement Proposals (BIPs) lacks clarity and there is a proposal to improve it. One suggestion is to have committees that review and indicate acceptance of BIPs, but there are debates and concerns surrounding this idea. Luke Dashjr argues against the committee proposal and suggests a specification based on BIP 123 instead. He questions the requirement for 1% stake for each segment of the Bitcoin ecosystem, citing privacy violations and time consumption.The proposed process aims to include more voices and gain a clearer idea of acceptance than the current process allows. The committee structures would be fluid, allowing users to reorganize at any time. However, there are debates about how different groups would prove their stake and express their positions. There is also a discussion about the definition of "accepted" and whether it should be binding on client authors. It is suggested that a BIP could be "greenlighted" by the community, but it's unclear if this would guarantee implementation.Overall, there is a need to improve the BIP process to ensure clear and fair acceptance of proposals. Some aspects of the current process need polishing, especially around "workflow states," but introducing committees may not be the best solution. The goal is to develop a process that gathers meaningful information to guide decisions without forcing anything on implementors or users. Peer review and open discussions are seen as important filtering mechanisms for proposals.It is important to note that the BIP process is separate from the implementation and adoption of proposals in Bitcoin software such as Bitcoin Core. Consensus rule changes are usually documented as BIPs, but their adoption and implementation depend on the wider ecosystem.In conclusion, the discussion highlights the need for a better process to accept BIPs in Bitcoin. Various proposals and concerns have been raised, including the role of committees, proving stake, expressing positions, and defining acceptance. The aim is to ensure a fair and transparent process that includes diverse voices and avoids unnecessary bureaucracy. 2016-01-19T06:07:52+00:00 + The current process for Bitcoin Improvement Proposals (BIPs) lacks clarity and there is a proposal to improve it. One suggestion is to have committees that review and indicate acceptance of BIPs, but there are debates and concerns surrounding this idea. Luke Dashjr argues against the committee proposal and suggests a specification based on BIP 123 instead. He questions the requirement for 1% stake for each segment of the Bitcoin ecosystem, citing privacy violations and time consumption.The proposed process aims to include more voices and gain a clearer idea of acceptance than the current process allows. The committee structures would be fluid, allowing users to reorganize at any time. However, there are debates about how different groups would prove their stake and express their positions. There is also a discussion about the definition of "accepted" and whether it should be binding on client authors. It is suggested that a BIP could be "greenlighted" by the community, but it's unclear if this would guarantee implementation.Overall, there is a need to improve the BIP process to ensure clear and fair acceptance of proposals. Some aspects of the current process need polishing, especially around "workflow states," but introducing committees may not be the best solution. The goal is to develop a process that gathers meaningful information to guide decisions without forcing anything on implementors or users. Peer review and open discussions are seen as important filtering mechanisms for proposals.It is important to note that the BIP process is separate from the implementation and adoption of proposals in Bitcoin software such as Bitcoin Core. Consensus rule changes are usually documented as BIPs, but their adoption and implementation depend on the wider ecosystem.In conclusion, the discussion highlights the need for a better process to accept BIPs in Bitcoin. Various proposals and concerns have been raised, including the role of committees, proving stake, expressing positions, and defining acceptance. The aim is to ensure a fair and transparent process that includes diverse voices and avoids unnecessary bureaucracy. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_-BIP-Proposal-New-sendheaders-p2p-message.xml b/static/bitcoin-dev/Sept_2015/combined_-BIP-Proposal-New-sendheaders-p2p-message.xml index 883459d710..4686f1ba56 100644 --- a/static/bitcoin-dev/Sept_2015/combined_-BIP-Proposal-New-sendheaders-p2p-message.xml +++ b/static/bitcoin-dev/Sept_2015/combined_-BIP-Proposal-New-sendheaders-p2p-message.xml @@ -1,8 +1,9 @@ - + 2 - Combined summary - [BIP Proposal] New "sendheaders" p2p message - 2023-08-01T16:16:48.614604+00:00 + Combined summary - [BIP Proposal] New "sendheaders" p2p message + 2025-10-11T21:54:22.094522+00:00 + python-feedgen Peter Todd 2015-09-24 19:27:57+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 - Combined summary - [BIP Proposal] New "sendheaders" p2p message - 2023-08-01T16:16:48.615599+00:00 + Combined summary - [BIP Proposal] New "sendheaders" p2p message + 2025-10-11T21:54:22.094690+00:00 - During a discussion on the bitcoin-dev mailing list, the topic of improving block announcement on the Bitcoin network was raised. The idea of unilaterally switching to sending headers instead of full blocks was suggested by Tier Nolan. However, Suhas Daftuar pointed out that this solution may not work for all network participants, including users running older versions of Bitcoin Core and non-Bitcoin Core software.Peter Todd proposed enabling the behavior based on advertised p2p network version, but Suhas Daftuar argued that other software on the network might prefer to bump up their protocol version in the future without having to opt-in to receiving headers-announcements for blocks. It was mentioned that inv-based block announcements are not going away, and forcing all software on the network to upgrade to support headers announcements seems too drastic.In response to the discussion, a pull request was implemented to allow nodes to opt-in to direct downloading of blocks upon receiving headers messages, while nodes that do not implement block downloading in response to headers announcements should continue to receive inv's. This solution aimed to address the concerns raised by Suhas Daftuar regarding compatibility with different versions of Bitcoin Core and non-Bitcoin Core software.Further, Suhas Daftuar proposed a new optional peer-to-peer message called "sendheaders" to improve the way blocks are announced on the network. This p2p message would allow nodes to announce blocks with headers messages instead of inv's, eliminating a round trip in network communication and facilitating more efficient propagation of reorgs. The proposal ensures backward compatibility, so older clients remain fully compatible and interoperable after the change.The draft BIP for this proposal is available on GitHub, and the implementation of the BIP can be found on bitcoin's GitHub repository. By introducing the "sendheaders" message, nodes have the option to use headers messages for block announcements, which can lead to more efficient block propagation and reduced latency. The proposal aims to reduce the amount of state in the protocol and improve overall network performance.In summary, a discussion among developers on the bitcoin-dev mailing list focused on improving block announcement on the Bitcoin network. While the idea of unilaterally switching to sending headers instead of full blocks was suggested, concerns were raised regarding compatibility with older versions of Bitcoin Core and non-Bitcoin Core software. In response, a pull request was implemented to allow nodes to opt-in to direct downloading of blocks upon receiving headers messages. Additionally, Suhas Daftuar proposed a new optional peer-to-peer message called "sendheaders" to improve block announcement efficiency. The proposal is aimed at reducing network latency and improving overall performance while ensuring backward compatibility. The draft BIP for this proposal can be found on GitHub, and the implementation is available on bitcoin's GitHub repository. 2015-09-24T19:27:57+00:00 + During a discussion on the bitcoin-dev mailing list, the topic of improving block announcement on the Bitcoin network was raised. The idea of unilaterally switching to sending headers instead of full blocks was suggested by Tier Nolan. However, Suhas Daftuar pointed out that this solution may not work for all network participants, including users running older versions of Bitcoin Core and non-Bitcoin Core software.Peter Todd proposed enabling the behavior based on advertised p2p network version, but Suhas Daftuar argued that other software on the network might prefer to bump up their protocol version in the future without having to opt-in to receiving headers-announcements for blocks. It was mentioned that inv-based block announcements are not going away, and forcing all software on the network to upgrade to support headers announcements seems too drastic.In response to the discussion, a pull request was implemented to allow nodes to opt-in to direct downloading of blocks upon receiving headers messages, while nodes that do not implement block downloading in response to headers announcements should continue to receive inv's. This solution aimed to address the concerns raised by Suhas Daftuar regarding compatibility with different versions of Bitcoin Core and non-Bitcoin Core software.Further, Suhas Daftuar proposed a new optional peer-to-peer message called "sendheaders" to improve the way blocks are announced on the network. This p2p message would allow nodes to announce blocks with headers messages instead of inv's, eliminating a round trip in network communication and facilitating more efficient propagation of reorgs. The proposal ensures backward compatibility, so older clients remain fully compatible and interoperable after the change.The draft BIP for this proposal is available on GitHub, and the implementation of the BIP can be found on bitcoin's GitHub repository. By introducing the "sendheaders" message, nodes have the option to use headers messages for block announcements, which can lead to more efficient block propagation and reduced latency. The proposal aims to reduce the amount of state in the protocol and improve overall network performance.In summary, a discussion among developers on the bitcoin-dev mailing list focused on improving block announcement on the Bitcoin network. While the idea of unilaterally switching to sending headers instead of full blocks was suggested, concerns were raised regarding compatibility with older versions of Bitcoin Core and non-Bitcoin Core software. In response, a pull request was implemented to allow nodes to opt-in to direct downloading of blocks upon receiving headers messages. Additionally, Suhas Daftuar proposed a new optional peer-to-peer message called "sendheaders" to improve block announcement efficiency. The proposal is aimed at reducing network latency and improving overall performance while ensuring backward compatibility. The draft BIP for this proposal can be found on GitHub, and the implementation is available on bitcoin's GitHub repository. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_-BIP-Proposal-Version-bits-with-timeout-and-delay-.xml b/static/bitcoin-dev/Sept_2015/combined_-BIP-Proposal-Version-bits-with-timeout-and-delay-.xml index 9d2e4b5116..897fcd6e17 100644 --- a/static/bitcoin-dev/Sept_2015/combined_-BIP-Proposal-Version-bits-with-timeout-and-delay-.xml +++ b/static/bitcoin-dev/Sept_2015/combined_-BIP-Proposal-Version-bits-with-timeout-and-delay-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP Proposal] Version bits with timeout and delay. - 2023-08-01T16:05:50.849173+00:00 + 2025-10-11T21:54:39.088843+00:00 + python-feedgen Tom Harding 2015-09-30 23:41:51+00:00 @@ -103,13 +104,13 @@ - python-feedgen + 2 Combined summary - [BIP Proposal] Version bits with timeout and delay. - 2023-08-01T16:05:50.850128+00:00 + 2025-10-11T21:54:39.089009+00:00 - In a discussion on the bitcoin-dev forum, Tier Nolan expressed his belief that the 75% rule should be maintained in softfork proposals to ensure miner compliance with new rules. Rusty Russell agreed with Nolan's point but emphasized simplicity and aligning with established dates. They proposed a solution where miners can set a bit, and if 75% of the blocks in the last 2016 blocks have the bit set, it moves to a tentative stage. If 95% of the blocks have the bit set, it moves to a locked-in stage. In the locked-in stage, miners do not set the bit for at least 10080 blocks and reject blocks that don't follow the new rule.The discussion also covered the effects of soft forks on Simplified Payment Verification (SPV) clients and buggy miners. They recommended that SPV clients monitor the version field and consider block forks when they occur. An email proposal suggested maintaining the 75% rule and outlined the process for moving through different stages based on block consensus. It also stressed the importance of including a timeout in softfork proposals and counting in blocks for accuracy.Another document proposed changing the semantics of the 'version' field in Bitcoin blocks to allow multiple backward-compatible changes to be deployed simultaneously. The version field would be interpreted as a bit vector, with each bit representing an independent change. A state would be associated with each softfork proposal, transitioning after each retarget period to locked-in, activated, or failed. The use of bit flags would enable multiple soft forks to be deployed at once.The proposed Version bits with timeout and delay suggested changes to the version field in Bitcoin blocks, allowing multiple backward-compatible changes to be deployed in parallel. Each bit in the version field represents an independent change that can be tallied every retarget period. A state is associated with each soft fork proposal, transitioning to locked-in, activated, or failed after each retarget period. The lock-in threshold determines when miners should stop setting the associated bit, and after another retarget period, the rules related to the locked-in soft fork are enforced. The proposal also highlighted the importance of including a timeout and allowing flexibility for future soft forks. This mechanism allows for multi-stage soft forks, conflicting soft forks, detection of buggy clients, and time for warnings and software upgrades. 2015-09-30T23:41:51+00:00 + In a discussion on the bitcoin-dev forum, Tier Nolan expressed his belief that the 75% rule should be maintained in softfork proposals to ensure miner compliance with new rules. Rusty Russell agreed with Nolan's point but emphasized simplicity and aligning with established dates. They proposed a solution where miners can set a bit, and if 75% of the blocks in the last 2016 blocks have the bit set, it moves to a tentative stage. If 95% of the blocks have the bit set, it moves to a locked-in stage. In the locked-in stage, miners do not set the bit for at least 10080 blocks and reject blocks that don't follow the new rule.The discussion also covered the effects of soft forks on Simplified Payment Verification (SPV) clients and buggy miners. They recommended that SPV clients monitor the version field and consider block forks when they occur. An email proposal suggested maintaining the 75% rule and outlined the process for moving through different stages based on block consensus. It also stressed the importance of including a timeout in softfork proposals and counting in blocks for accuracy.Another document proposed changing the semantics of the 'version' field in Bitcoin blocks to allow multiple backward-compatible changes to be deployed simultaneously. The version field would be interpreted as a bit vector, with each bit representing an independent change. A state would be associated with each softfork proposal, transitioning after each retarget period to locked-in, activated, or failed. The use of bit flags would enable multiple soft forks to be deployed at once.The proposed Version bits with timeout and delay suggested changes to the version field in Bitcoin blocks, allowing multiple backward-compatible changes to be deployed in parallel. Each bit in the version field represents an independent change that can be tallied every retarget period. A state is associated with each soft fork proposal, transitioning to locked-in, activated, or failed after each retarget period. The lock-in threshold determines when miners should stop setting the associated bit, and after another retarget period, the rules related to the locked-in soft fork are enforced. The proposal also highlighted the importance of including a timeout and allowing flexibility for future soft forks. This mechanism allows for multi-stage soft forks, conflicting soft forks, detection of buggy clients, and time for warnings and software upgrades. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime.xml b/static/bitcoin-dev/Sept_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime.xml index e675e57710..fc09ea5105 100644 --- a/static/bitcoin-dev/Sept_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime.xml +++ b/static/bitcoin-dev/Sept_2015/combined_-BIP-draft-CHECKSEQUENCEVERIFY-An-opcode-for-relative-locktime.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime - 2023-08-01T15:11:20.666401+00:00 + 2025-10-11T21:54:32.709228+00:00 + python-feedgen Rusty Russell 2015-09-18 01:21:19+00:00 @@ -139,13 +140,13 @@ - python-feedgen + 2 Combined summary - [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime - 2023-08-01T15:11:20.667398+00:00 + 2025-10-11T21:54:32.709466+00:00 - In a discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed changing the rules regarding sequence numbers in Bitcoin transactions. He created two new repositories, one of which inverts the sequence number and interprets it as a fixed-point number, allowing for up to five-year relative lock times using blocks or up to approximately two-year relative lock times using seconds. The other repository inverts the sequence number with nSequence=1 meaning one block relative lock-height and nSequence=LOCKTIME_THRESHOLD meaning one second relative lock-height. Friedenbach also discussed the maximum time required for relative lock-times, suggesting a maximum of one year. He questioned whether there are any use cases that would require more than a year of lock time.Rusty Russell agreed with Friedenbach's suggestion and emphasized simplicity. He mentioned that reserving the remaining half of the number space for future purposes and leaving the top two bits for those who are paranoid would be a good approach.Eric Lombrozo commented that he would prefer replacing the entire nSequence field with an explicit relative lock-time with clear semantics.Gregory Maxwell suggested representing one block with more than one increment to leave additional space for future signaling or allow higher resolution numbers for a share chain commitment.In another discussion, Rusty Russell proposed an IsStandard() rule that would ensure nSequence is either 0xFFFFFFFF or 0 to avoid issues with soft forks. However, it was pointed out that this rule is not necessary since BIP68 is not active for version 1 transactions and no existing wallets would be affected.There was also a discussion on transaction finality and the proposal code named BIP112. It was suggested to use the "sequence" field instead of the "version" field, as it is associated with transaction finality. It was also mentioned that chaining transactions and extending the relative locktime could be a way to delay confirmation in cases where the clock start is uncertain.Overall, the discussions revolved around improving sequence numbers and relative lock-times in Bitcoin transactions, considering different use cases and future implications.In a discussion on the bitcoin-dev mailing list, Gregory Maxwell proposed the idea of representing one block with more than one increment, which would provide additional space for future signaling or higher resolution numbers for a sharechain commitment. However, there had been no prior discussion of this idea. Another participant in the thread suggested using 600 increments to make it more similar to timestamps. The discussion also touched on the inversion of nSequence and preserving existing semantics in Bitcoin transactions.Tom Harding posted a message regarding an idea for preserving existing semantics in a Bitcoin transaction, but another member requested clarification as they couldn't follow the logic. Mark Friedenbach expressed his indifference towards the issue of bit inversion and explained that he implemented it to preserve existing semantics, even if they were not commonly used. Jorge Timón raised an issue with this implementation on GitHub, and a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core was announced.Joseph Poon and Mark Friedenbach discussed the inversion of nSequence in mempool transaction selection via email. Poon mentioned his indifference to the issue but expressed concern about technical debt and noted that transactions with shorter relative locks have higher priority. The group ultimately agreed to remove the inversion for ease of use and mental calculation.The bitcoin-dev community engaged in a discussion regarding a proposed change to the Bitcoin Improvement Proposals. The proposal involved changing how transactions are selected in the mempool to prioritize those with shorter relative locks. Some developers were indifferent to the issue, while others expressed concern over technical debt. Joseph Poon suggested noting the information for those who wish to write code for mempool transaction selection, regardless of their opinion.Btc Drak provided an update on the bitcoin-dev mailing list regarding a new pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core. The pull request can be found on Github, labeled as pull request number 179. Another pull request for a BIP was also submitted and can be found on Github, labeled as pull request number 6564.The writer expressed their displeasure towards the inversion of nSequence to preserve existing semantics. They argued that these semantics were not enforceable by consensus and suggested using nMaturity instead. The writer emphasized the importance of moving forward without technical debt and believed that clearer documentation could be achieved through this decision.The context discussed the assumed malleability-fix CHECKSIG2 version of lightning, which allows for outsourcing monitoring and response to bad behavior. It was noted that this requires users' wallets to be online. The proposal also mentioned the need for mitigations against a systemic supervillain attack but did not include provisions for it. The scenario of a hub turning evil and cheating its users out of their bonds was discussed, along with potential ways to protect against such behavior. However, automating the process and determining reasonable metrics proved challenging.Joseph Poon suggested that Lightning needs mitigations for a systemic supervillain attack, while Mark Friedenbach didn't think the risk 2015-09-18T01:21:19+00:00 + In a discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed changing the rules regarding sequence numbers in Bitcoin transactions. He created two new repositories, one of which inverts the sequence number and interprets it as a fixed-point number, allowing for up to five-year relative lock times using blocks or up to approximately two-year relative lock times using seconds. The other repository inverts the sequence number with nSequence=1 meaning one block relative lock-height and nSequence=LOCKTIME_THRESHOLD meaning one second relative lock-height. Friedenbach also discussed the maximum time required for relative lock-times, suggesting a maximum of one year. He questioned whether there are any use cases that would require more than a year of lock time.Rusty Russell agreed with Friedenbach's suggestion and emphasized simplicity. He mentioned that reserving the remaining half of the number space for future purposes and leaving the top two bits for those who are paranoid would be a good approach.Eric Lombrozo commented that he would prefer replacing the entire nSequence field with an explicit relative lock-time with clear semantics.Gregory Maxwell suggested representing one block with more than one increment to leave additional space for future signaling or allow higher resolution numbers for a share chain commitment.In another discussion, Rusty Russell proposed an IsStandard() rule that would ensure nSequence is either 0xFFFFFFFF or 0 to avoid issues with soft forks. However, it was pointed out that this rule is not necessary since BIP68 is not active for version 1 transactions and no existing wallets would be affected.There was also a discussion on transaction finality and the proposal code named BIP112. It was suggested to use the "sequence" field instead of the "version" field, as it is associated with transaction finality. It was also mentioned that chaining transactions and extending the relative locktime could be a way to delay confirmation in cases where the clock start is uncertain.Overall, the discussions revolved around improving sequence numbers and relative lock-times in Bitcoin transactions, considering different use cases and future implications.In a discussion on the bitcoin-dev mailing list, Gregory Maxwell proposed the idea of representing one block with more than one increment, which would provide additional space for future signaling or higher resolution numbers for a sharechain commitment. However, there had been no prior discussion of this idea. Another participant in the thread suggested using 600 increments to make it more similar to timestamps. The discussion also touched on the inversion of nSequence and preserving existing semantics in Bitcoin transactions.Tom Harding posted a message regarding an idea for preserving existing semantics in a Bitcoin transaction, but another member requested clarification as they couldn't follow the logic. Mark Friedenbach expressed his indifference towards the issue of bit inversion and explained that he implemented it to preserve existing semantics, even if they were not commonly used. Jorge Timón raised an issue with this implementation on GitHub, and a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core was announced.Joseph Poon and Mark Friedenbach discussed the inversion of nSequence in mempool transaction selection via email. Poon mentioned his indifference to the issue but expressed concern about technical debt and noted that transactions with shorter relative locks have higher priority. The group ultimately agreed to remove the inversion for ease of use and mental calculation.The bitcoin-dev community engaged in a discussion regarding a proposed change to the Bitcoin Improvement Proposals. The proposal involved changing how transactions are selected in the mempool to prioritize those with shorter relative locks. Some developers were indifferent to the issue, while others expressed concern over technical debt. Joseph Poon suggested noting the information for those who wish to write code for mempool transaction selection, regardless of their opinion.Btc Drak provided an update on the bitcoin-dev mailing list regarding a new pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core. The pull request can be found on Github, labeled as pull request number 179. Another pull request for a BIP was also submitted and can be found on Github, labeled as pull request number 6564.The writer expressed their displeasure towards the inversion of nSequence to preserve existing semantics. They argued that these semantics were not enforceable by consensus and suggested using nMaturity instead. The writer emphasized the importance of moving forward without technical debt and believed that clearer documentation could be achieved through this decision.The context discussed the assumed malleability-fix CHECKSIG2 version of lightning, which allows for outsourcing monitoring and response to bad behavior. It was noted that this requires users' wallets to be online. The proposal also mentioned the need for mitigations against a systemic supervillain attack but did not include provisions for it. The scenario of a hub turning evil and cheating its users out of their bonds was discussed, along with potential ways to protect against such behavior. However, automating the process and determining reasonable metrics proved challenging.Joseph Poon suggested that Lightning needs mitigations for a systemic supervillain attack, while Mark Friedenbach didn't think the risk - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_2015-09-24-bitcoin-dev-Weekly-Development-Meeting-Minutes.xml b/static/bitcoin-dev/Sept_2015/combined_2015-09-24-bitcoin-dev-Weekly-Development-Meeting-Minutes.xml index 8e85a2df48..fd18f8ae49 100644 --- a/static/bitcoin-dev/Sept_2015/combined_2015-09-24-bitcoin-dev-Weekly-Development-Meeting-Minutes.xml +++ b/static/bitcoin-dev/Sept_2015/combined_2015-09-24-bitcoin-dev-Weekly-Development-Meeting-Minutes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - 2015-09-24 #bitcoin-dev Weekly Development Meeting Minutes - 2023-08-01T16:17:07.661693+00:00 + 2025-10-11T21:55:34.309579+00:00 + python-feedgen Wladimir J. van der Laan 2015-09-28 18:26:14+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - 2015-09-24 #bitcoin-dev Weekly Development Meeting Minutes - 2023-08-01T16:17:07.661693+00:00 + 2025-10-11T21:55:34.309751+00:00 - In September 2015, a Bitcoin development meeting took place, attended by developers such as luke-jr, CodeShark, sipa, morcos, sdaftuar, dstadulis, jtimon, wumpus, jgarzik, kanzure, gmaxwell, cfields, and gavinandresen. Daniel Stadulis, one of the attendees, shared the minutes of the meeting via email with the rest of the participants. Wladimir responded to this email, expressing gratitude for sharing the minutes and suggesting that they be posted on the wiki as well.The meeting, known as the #bitcoin-dev Weekly Development Meeting, was held on September 24, 2015, from 19:00-20:00 UTC. Detailed minutes and IRC chat logs from the meeting can be found on bitcoinstats.com. Various topics were discussed during the meeting, including libconsensus and refactoring, goals for the upcoming 0.12 release, the BIP process, and ongoing projects. One of the key discussions revolved around the readiness of libsecp256k1 for the 0.12 release, with participants suggesting the need for a native OSX travis build. It was also proposed that the libsecp256k1 validation PR should be put forward once all currently-in-pipeline API changes are merged. Other topics addressed included OP_CHECKSEQUENCEVERIFY, mempool limiting, version bits, and splitting off script base classes/execution for use in consensus.At the end of the meeting, action items were assigned to the attendees. These included reviewing mempool pulls for concept, ensuring libsecp256k1 has a native OSX travis build, proposing the libsecp256k1 validation PR, reviewing BIP 68 and specific pull requests, and assigning a versionbits BIP number to gmaxwell. The discussion on mempool limiting was postponed to the next meeting scheduled for October 1, 2015.To document the minutes and conclusions of the meeting, a Google Doc was created. The minutes were initially shared via email by Daniel Stadulis and subsequently considered for posting on the wiki as suggested by Wladimir. 2015-09-28T18:26:14+00:00 + In September 2015, a Bitcoin development meeting took place, attended by developers such as luke-jr, CodeShark, sipa, morcos, sdaftuar, dstadulis, jtimon, wumpus, jgarzik, kanzure, gmaxwell, cfields, and gavinandresen. Daniel Stadulis, one of the attendees, shared the minutes of the meeting via email with the rest of the participants. Wladimir responded to this email, expressing gratitude for sharing the minutes and suggesting that they be posted on the wiki as well.The meeting, known as the #bitcoin-dev Weekly Development Meeting, was held on September 24, 2015, from 19:00-20:00 UTC. Detailed minutes and IRC chat logs from the meeting can be found on bitcoinstats.com. Various topics were discussed during the meeting, including libconsensus and refactoring, goals for the upcoming 0.12 release, the BIP process, and ongoing projects. One of the key discussions revolved around the readiness of libsecp256k1 for the 0.12 release, with participants suggesting the need for a native OSX travis build. It was also proposed that the libsecp256k1 validation PR should be put forward once all currently-in-pipeline API changes are merged. Other topics addressed included OP_CHECKSEQUENCEVERIFY, mempool limiting, version bits, and splitting off script base classes/execution for use in consensus.At the end of the meeting, action items were assigned to the attendees. These included reviewing mempool pulls for concept, ensuring libsecp256k1 has a native OSX travis build, proposing the libsecp256k1 validation PR, reviewing BIP 68 and specific pull requests, and assigning a versionbits BIP number to gmaxwell. The discussion on mempool limiting was postponed to the next meeting scheduled for October 1, 2015.To document the minutes and conclusions of the meeting, a Google Doc was created. The minutes were initially shared via email by Daniel Stadulis and subsequently considered for posting on the wiki as suggested by Wladimir. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_AT-T-ISPs-making-Bitcoin-Core-near-impossible-to-use-as-a-full-node-via-hidden-private-dynamic-IPs-not-by-specifically-blocking-8333-or-Bitcoin-as-stated-in-original-email.xml b/static/bitcoin-dev/Sept_2015/combined_AT-T-ISPs-making-Bitcoin-Core-near-impossible-to-use-as-a-full-node-via-hidden-private-dynamic-IPs-not-by-specifically-blocking-8333-or-Bitcoin-as-stated-in-original-email.xml index ea6b3c3b7f..481260af29 100644 --- a/static/bitcoin-dev/Sept_2015/combined_AT-T-ISPs-making-Bitcoin-Core-near-impossible-to-use-as-a-full-node-via-hidden-private-dynamic-IPs-not-by-specifically-blocking-8333-or-Bitcoin-as-stated-in-original-email.xml +++ b/static/bitcoin-dev/Sept_2015/combined_AT-T-ISPs-making-Bitcoin-Core-near-impossible-to-use-as-a-full-node-via-hidden-private-dynamic-IPs-not-by-specifically-blocking-8333-or-Bitcoin-as-stated-in-original-email.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - AT&T/ISPs making Bitcoin Core near impossible to use as a full node via hidden private dynamic IPs, not by specifically blocking 8333 or Bitcoin as stated in original email - 2023-08-01T16:01:34.031256+00:00 + 2025-10-11T21:55:42.805863+00:00 + python-feedgen Bastiaan van den Berg 2015-09-04 13:47:41+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - AT&T/ISPs making Bitcoin Core near impossible to use as a full node via hidden private dynamic IPs, not by specifically blocking 8333 or Bitcoin as stated in original email - 2023-08-01T16:01:34.031256+00:00 + 2025-10-11T21:55:42.805993+00:00 - Zach G starts an email thread by pointing out that AT&T does not offer a public static IP without payment. It is unclear which aspect of bitcoin development he is referring to. The sender of this email encountered difficulties in opening ports for Bitcoin on their AT&T network. This was due to the fact that AT&T Uverse customers are only given a private dynamic IP, which is hidden from the internet. Consequently, it becomes impossible to send requests.The suggested solution to this problem is to switch to a public static IP and allow incoming traffic. However, AT&T does not provide a public static IP without payment. This limitation has led to only 37 nodes using AT&T worldwide. Such a low number indicates the extreme difficulty faced by individuals trying to use Bitcoin Core as a full node on AT&T.Unfortunately, other major Internet Service Providers (ISPs) also engage in similar practices, causing a decline in the number of Bitcoin nodes overall. In light of these security measures, the author emphasizes the need for the community to educate users on how to navigate such obstacles when utilizing Bitcoin Core. Without proper education and awareness, the decline in node numbers is likely to persist. 2015-09-04T13:47:41+00:00 + Zach G starts an email thread by pointing out that AT&T does not offer a public static IP without payment. It is unclear which aspect of bitcoin development he is referring to. The sender of this email encountered difficulties in opening ports for Bitcoin on their AT&T network. This was due to the fact that AT&T Uverse customers are only given a private dynamic IP, which is hidden from the internet. Consequently, it becomes impossible to send requests.The suggested solution to this problem is to switch to a public static IP and allow incoming traffic. However, AT&T does not provide a public static IP without payment. This limitation has led to only 37 nodes using AT&T worldwide. Such a low number indicates the extreme difficulty faced by individuals trying to use Bitcoin Core as a full node on AT&T.Unfortunately, other major Internet Service Providers (ISPs) also engage in similar practices, causing a decline in the number of Bitcoin nodes overall. In light of these security measures, the author emphasizes the need for the community to educate users on how to navigate such obstacles when utilizing Bitcoin Core. Without proper education and awareness, the decline in node numbers is likely to persist. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_AT-T-has-effectively-banned-Bitcoin-nodes-by-closing-port-8333-via-a-hidden-firewall-in-the-cable-box.xml b/static/bitcoin-dev/Sept_2015/combined_AT-T-has-effectively-banned-Bitcoin-nodes-by-closing-port-8333-via-a-hidden-firewall-in-the-cable-box.xml index fdd909e311..96ddde0696 100644 --- a/static/bitcoin-dev/Sept_2015/combined_AT-T-has-effectively-banned-Bitcoin-nodes-by-closing-port-8333-via-a-hidden-firewall-in-the-cable-box.xml +++ b/static/bitcoin-dev/Sept_2015/combined_AT-T-has-effectively-banned-Bitcoin-nodes-by-closing-port-8333-via-a-hidden-firewall-in-the-cable-box.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - AT&T has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box - 2023-08-01T15:53:37.880958+00:00 + 2025-10-11T21:55:02.449787+00:00 + python-feedgen Dan Bryant 2015-09-01 14:44:44+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - AT&T has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box - 2023-08-01T15:53:37.881960+00:00 + 2025-10-11T21:55:02.449937+00:00 - The legality of setting up a full node for Bitcoin from home is a contentious issue, with many ISPs prohibiting the network services that a full node would provide. Comcast, for example, forbids off-premise network "services," while AT&T claims implicit admin rights to all "equipment" connecting to their network. To overcome these restrictions, using a VPN can offer privacy and flexibility in opening or closing ports. However, it may be beneficial for those with an AT&T landline but not using their standard internet/TV offering to switch to a local ISP to potentially avoid blockage, censorship, and have a better privacy policy.Various observations show that different ISPs retain user data for varying periods of time. TWC and Comcast store IP and other information for at least six months, Verizon retains data for 18 months, Qwest/Century for one year, Cox for six months, and AT&T retains data for more than a year. These data retention policies raise concerns about privacy.A specific user's struggle to open port 8333, crucial for running a full node, uncovered that their internet was being routed through a DVR/cable box with a firewall. The customer service representative refused to disable the firewall, asserting their control over their own equipment. This incident exemplifies a potential reason behind the decline in Bitcoin nodes, as ISPs effectively censor the network.The message advises individuals who have an AT&T landline but do not use their standard internet/TV offering to check with local small ISPs regarding their port policies. It is recommended to find an ISP that allows port forwarding for TCP and UDP to a specific port number (SOMEPORTNUMBER) and keeps port 8333 open. Additionally, if an individual has Fiber-to-the-Node (FTTN) service provided by a local ISP contracted with AT&T, even if the local ISP has its own privacy policy, AT&T's data retention policies still apply. To enhance privacy and bypass censorship, the message suggests using a VPN or setting up one's own VPN connection. Running Tor through the VPN is also mentioned as an option.The email includes an excerpt from Zach G via bitcoin-dev, who experienced difficulties opening port 8333 for an entire year. After extensive communication with AT&T, it was discovered that the internet was being routed through a DVR/cable box with a firewall. AT&T refused to disable the firewall, citing their ownership of the equipment. This situation could be contributing to the decline in Bitcoin nodes, as ISPs are censoring the network without customer knowledge.Another individual had similar issues with Comcast involving a different port, leading them to testify in federal court as part of a class-action lawsuit against the ISP. The solution for this person was to switch to a business account, which allows firewall configuration and unblocked ports. It cost an additional $10 per month. Bitnodes.io is suggested as a resource to identify any ISPs blocking nodes. The writer has been successfully running a node through their business account.In another case, the author struggled to open port 8333 throughout the year, despite various attempts. The port appeared open on the router and computer, but it remained closed. Contacting AT&T revealed that the internet was routed through a DVR/cable box with a firewall, explaining the closed port. However, AT&T refused to disable the firewall, claiming their ownership of the equipment. The author believes this could be a cause for the decline in Bitcoin nodes, as ISPs censor the cryptocurrency without informing customers. To obtain a satisfactory response, the author had to escalate the issue to AT&T headquarters and threaten to remove the equipment from the wall.Overall, the context highlights the challenges faced when setting up a full node for Bitcoin due to ISP restrictions, data retention policies, and the refusal of some ISPs to disable firewalls on their equipment. These issues have led to difficulties in opening ports necessary for running nodes and potential censorship of Bitcoin by ISPs. The message provides recommendations such as using a VPN, seeking alternative local ISPs, or switching to business accounts to overcome these challenges. 2015-09-01T14:44:44+00:00 + The legality of setting up a full node for Bitcoin from home is a contentious issue, with many ISPs prohibiting the network services that a full node would provide. Comcast, for example, forbids off-premise network "services," while AT&T claims implicit admin rights to all "equipment" connecting to their network. To overcome these restrictions, using a VPN can offer privacy and flexibility in opening or closing ports. However, it may be beneficial for those with an AT&T landline but not using their standard internet/TV offering to switch to a local ISP to potentially avoid blockage, censorship, and have a better privacy policy.Various observations show that different ISPs retain user data for varying periods of time. TWC and Comcast store IP and other information for at least six months, Verizon retains data for 18 months, Qwest/Century for one year, Cox for six months, and AT&T retains data for more than a year. These data retention policies raise concerns about privacy.A specific user's struggle to open port 8333, crucial for running a full node, uncovered that their internet was being routed through a DVR/cable box with a firewall. The customer service representative refused to disable the firewall, asserting their control over their own equipment. This incident exemplifies a potential reason behind the decline in Bitcoin nodes, as ISPs effectively censor the network.The message advises individuals who have an AT&T landline but do not use their standard internet/TV offering to check with local small ISPs regarding their port policies. It is recommended to find an ISP that allows port forwarding for TCP and UDP to a specific port number (SOMEPORTNUMBER) and keeps port 8333 open. Additionally, if an individual has Fiber-to-the-Node (FTTN) service provided by a local ISP contracted with AT&T, even if the local ISP has its own privacy policy, AT&T's data retention policies still apply. To enhance privacy and bypass censorship, the message suggests using a VPN or setting up one's own VPN connection. Running Tor through the VPN is also mentioned as an option.The email includes an excerpt from Zach G via bitcoin-dev, who experienced difficulties opening port 8333 for an entire year. After extensive communication with AT&T, it was discovered that the internet was being routed through a DVR/cable box with a firewall. AT&T refused to disable the firewall, citing their ownership of the equipment. This situation could be contributing to the decline in Bitcoin nodes, as ISPs are censoring the network without customer knowledge.Another individual had similar issues with Comcast involving a different port, leading them to testify in federal court as part of a class-action lawsuit against the ISP. The solution for this person was to switch to a business account, which allows firewall configuration and unblocked ports. It cost an additional $10 per month. Bitnodes.io is suggested as a resource to identify any ISPs blocking nodes. The writer has been successfully running a node through their business account.In another case, the author struggled to open port 8333 throughout the year, despite various attempts. The port appeared open on the router and computer, but it remained closed. Contacting AT&T revealed that the internet was routed through a DVR/cable box with a firewall, explaining the closed port. However, AT&T refused to disable the firewall, claiming their ownership of the equipment. The author believes this could be a cause for the decline in Bitcoin nodes, as ISPs censor the cryptocurrency without informing customers. To obtain a satisfactory response, the author had to escalate the issue to AT&T headquarters and threaten to remove the equipment from the wall.Overall, the context highlights the challenges faced when setting up a full node for Bitcoin due to ISP restrictions, data retention policies, and the refusal of some ISPs to disable firewalls on their equipment. These issues have led to difficulties in opening ports necessary for running nodes and potential censorship of Bitcoin by ISPs. The message provides recommendations such as using a VPN, seeking alternative local ISPs, or switching to business accounts to overcome these challenges. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_AT-T-has-effectively-banned-Bitcoin-nodes-via-utilizing-private-subnets-.xml b/static/bitcoin-dev/Sept_2015/combined_AT-T-has-effectively-banned-Bitcoin-nodes-via-utilizing-private-subnets-.xml index bfcb4fac15..61154a9bc5 100644 --- a/static/bitcoin-dev/Sept_2015/combined_AT-T-has-effectively-banned-Bitcoin-nodes-via-utilizing-private-subnets-.xml +++ b/static/bitcoin-dev/Sept_2015/combined_AT-T-has-effectively-banned-Bitcoin-nodes-via-utilizing-private-subnets-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - AT&T has effectively banned Bitcoin nodes via utilizing private subnets. - 2023-08-01T15:55:35.584544+00:00 + 2025-10-11T21:55:27.934981+00:00 + python-feedgen hurricanewarn1 at aol.com 2015-09-02 20:31:05+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - AT&T has effectively banned Bitcoin nodes via utilizing private subnets. - 2023-08-01T15:55:35.584544+00:00 + 2025-10-11T21:55:27.935115+00:00 - A debate has arisen among Bitcoin users regarding AT&T's impact on Bitcoin nodes. One user claims that AT&T effectively banned Bitcoin nodes by using private subnets, leading to a worldwide decline in node numbers. However, another user refutes these claims, stating that AT&T's default network configuration did not cause any problems for Bitcoin nodes and accuses the first user of being uninformed about computer networking. Despite this, the first user insists that his accusations are true and that he has confirmed them with AT&T technicians.The first user suggests that the community needs to speak up and educate others about the issue to improve node numbers. Another internet user shares their experience with local ISPs who contract with AT&T to provide internet services in areas where old-style DSL has been phased out. The internet services provided by the local ISP is essentially AT&T FTTN, which means everything is subject to AT&T data retention policy. To protect privacy, the user suggests using a VPN or setting up Tor to run through the VPN.The same issues with AT&T were also faced by a Bitcoin user who struggled to get port 8333 open for Bitcoin Core due to firewall restrictions imposed by AT&T. After several hours of phone calls and messaging with AT&T, he found out that the internet was being routed through a DVR/cable box with a firewall, and AT&T refused to turn off the firewall. The user believes this could be a driving force behind the decline in Bitcoin nodes and suggests that ISPs are censoring Bitcoin without informing their customers.In conclusion, while one user claims that AT&T banned Bitcoin nodes, another user refutes these claims, suggesting that the first user is uninformed about computer networking. However, both users agree that there are issues with AT&T's policies that could negatively impact Bitcoin users and nodes. It is recommended that Bitcoin users take steps to protect their privacy when using AT&T services, such as using a VPN or Tor, and to educate others about these issues. 2015-09-02T20:31:05+00:00 + A debate has arisen among Bitcoin users regarding AT&T's impact on Bitcoin nodes. One user claims that AT&T effectively banned Bitcoin nodes by using private subnets, leading to a worldwide decline in node numbers. However, another user refutes these claims, stating that AT&T's default network configuration did not cause any problems for Bitcoin nodes and accuses the first user of being uninformed about computer networking. Despite this, the first user insists that his accusations are true and that he has confirmed them with AT&T technicians.The first user suggests that the community needs to speak up and educate others about the issue to improve node numbers. Another internet user shares their experience with local ISPs who contract with AT&T to provide internet services in areas where old-style DSL has been phased out. The internet services provided by the local ISP is essentially AT&T FTTN, which means everything is subject to AT&T data retention policy. To protect privacy, the user suggests using a VPN or setting up Tor to run through the VPN.The same issues with AT&T were also faced by a Bitcoin user who struggled to get port 8333 open for Bitcoin Core due to firewall restrictions imposed by AT&T. After several hours of phone calls and messaging with AT&T, he found out that the internet was being routed through a DVR/cable box with a firewall, and AT&T refused to turn off the firewall. The user believes this could be a driving force behind the decline in Bitcoin nodes and suggests that ISPs are censoring Bitcoin without informing their customers.In conclusion, while one user claims that AT&T banned Bitcoin nodes, another user refutes these claims, suggesting that the first user is uninformed about computer networking. However, both users agree that there are issues with AT&T's policies that could negatively impact Bitcoin users and nodes. It is recommended that Bitcoin users take steps to protect their privacy when using AT&T services, such as using a VPN or Tor, and to educate others about these issues. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Adjusted-difficulty-depending-on-relative-blocksize.xml b/static/bitcoin-dev/Sept_2015/combined_Adjusted-difficulty-depending-on-relative-blocksize.xml index fedb810944..1c2a1177bd 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Adjusted-difficulty-depending-on-relative-blocksize.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Adjusted-difficulty-depending-on-relative-blocksize.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Adjusted difficulty depending on relative blocksize - 2023-08-01T15:13:59.755806+00:00 + 2025-10-11T21:54:24.216756+00:00 + python-feedgen Tom Harding 2015-09-09 19:53:10+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Adjusted difficulty depending on relative blocksize - 2023-08-01T15:13:59.755806+00:00 + 2025-10-11T21:54:24.216941+00:00 - The discussion on the bitcoin-dev mailing list revolves around the "flexcap" proposal by Greg Maxwell and Mark Friedenbach, which suggests adjusting the difficulty of mining Bitcoin based on the relative size of individual blocks to the average block size of the previous period. The concern is that any change in difficulty that is not in response to observed block production rate will unavoidably change the money supply schedule. Changing the reward can reduce the time-frame of the effect, but there is still an impact. The proposal aims to increase the block size as usage grows, but this would also result in longer confirmation times.There are concerns about possible attacks on the system and the impact on miners who invest in equipment to mine the blocks. It is suggested that dynamically adjusting the maximum block size would be simpler than fluctuating the difficulty based on transaction volume and fees paid. There is also a question raised about whether rich individuals and institutions could manipulate the difficulty by buying or selling BTC, affecting the exchange rate and miners' profitability.In response to the proposal, Jakob Rönnbäck suggests adjusting the difficulty of individual blocks based on their relative size to the average block size of the previous difficulty period. This would allow for an increase in block size as usage grows, but it would also result in longer confirmation times. Anthony Towns argues against this suggestion, stating that dynamically adjusting the maximum block size would be simpler. He raises concerns about potential attacks on the system and double-spends.The conversation includes references to the flexcap proposal by Greg Maxwell and Mark Friedenbach, which was discussed on the Bitcoin Development mailing list in May 2015. Adam Back provides links to the discussion threads for further reference. Jakob Rönnbäck expresses gratitude for finding the information he was looking for.Overall, the discussion centers around the idea of adjusting the difficulty and block size in response to changes in usage and transaction volume. There are various concerns and suggestions raised regarding the feasibility and potential impacts of these proposals. The conversation takes place on the bitcoin-dev mailing list, which is a platform for developers to discuss technical issues concerning Bitcoin. 2015-09-09T19:53:10+00:00 + The discussion on the bitcoin-dev mailing list revolves around the "flexcap" proposal by Greg Maxwell and Mark Friedenbach, which suggests adjusting the difficulty of mining Bitcoin based on the relative size of individual blocks to the average block size of the previous period. The concern is that any change in difficulty that is not in response to observed block production rate will unavoidably change the money supply schedule. Changing the reward can reduce the time-frame of the effect, but there is still an impact. The proposal aims to increase the block size as usage grows, but this would also result in longer confirmation times.There are concerns about possible attacks on the system and the impact on miners who invest in equipment to mine the blocks. It is suggested that dynamically adjusting the maximum block size would be simpler than fluctuating the difficulty based on transaction volume and fees paid. There is also a question raised about whether rich individuals and institutions could manipulate the difficulty by buying or selling BTC, affecting the exchange rate and miners' profitability.In response to the proposal, Jakob Rönnbäck suggests adjusting the difficulty of individual blocks based on their relative size to the average block size of the previous difficulty period. This would allow for an increase in block size as usage grows, but it would also result in longer confirmation times. Anthony Towns argues against this suggestion, stating that dynamically adjusting the maximum block size would be simpler. He raises concerns about potential attacks on the system and double-spends.The conversation includes references to the flexcap proposal by Greg Maxwell and Mark Friedenbach, which was discussed on the Bitcoin Development mailing list in May 2015. Adam Back provides links to the discussion threads for further reference. Jakob Rönnbäck expresses gratitude for finding the information he was looking for.Overall, the discussion centers around the idea of adjusting the difficulty and block size in response to changes in usage and transaction volume. There are various concerns and suggestions raised regarding the feasibility and potential impacts of these proposals. The conversation takes place on the bitcoin-dev mailing list, which is a platform for developers to discuss technical issues concerning Bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_BIP-100-repo.xml b/static/bitcoin-dev/Sept_2015/combined_BIP-100-repo.xml index efb449daa2..23a9431e24 100644 --- a/static/bitcoin-dev/Sept_2015/combined_BIP-100-repo.xml +++ b/static/bitcoin-dev/Sept_2015/combined_BIP-100-repo.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 100 repo - 2023-08-01T15:55:57.634446+00:00 + 2025-10-11T21:54:58.193877+00:00 + python-feedgen odinn 2015-09-03 06:41:20+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - BIP 100 repo - 2023-08-01T15:55:57.634446+00:00 + 2025-10-11T21:54:58.194030+00:00 - On September 2, 2015, Jeff Garzik sent an email to the bitcoin-dev mailing list sharing that he has created a repository containing the full text of BIP 100 discussion document in markdown format. The purpose of this repository is to check the BIP 100 formal specification before submitting it to the upstream bips.git repo. However, the previous email failed to include the link to the repository, so Garzik provides it in this message.The conversation within the email exchange discusses the concept of "votes" in relation to Bitcoin and the potential implementation of a fee market. It is unclear whether the voting process would be semi-automatic or fully automated. The number of options and values for votes can influence outcomes. The participants also discuss the newly introduced 1 MB floor in the bitcoin block size limit proposal. Luke Dashjr suggests combining certain rules and modifying the voting process to require 50% to set the limit floor. He questions why the new size limit votes must use 11 bytes of coinbase and suggests increasing the coinbase length to allow for 100 bytes in addition to the pushed height and size-vote. In a separate email exchange, Luke expresses concerns about the power to decrease the hard limit in the proposed BIP100. He suggests that miners have the ability to lower the block size locally or collectively without needing a vote. Luke also provides suggestions for improving BIP100, including combining rules, modifying the voting system, and increasing the coinbase length. Overall, Jeff Garzik's proposal aims to set a new 1 MB floor in the Bitcoin Improvement Proposal 100 (BIP 100) repository on GitHub. This would allow for future adjustments to the block size limit. However, some members of the community express concerns about the proposed limit being too high. Garzik suggests using a numeric value pushed after height instead of 11 bytes of coinbase for voting on the block size limit. He also proposes increasing the coinbase length to allow for additional bytes. Additionally, Garzik suggests combining rules to make it clear that the limit remains a part of the consensus protocol and modifying the voting process to require 50% to set the limit floor. In conclusion, Jeff Garzik opens a repository containing the full text of BIP 100 discussion document in markdown format on September 2, 2015. The purpose of this repository is to check the BIP 100 formal specification before submitting it to the upstream bips.git repo. The link to the repository can be found at https://github.com/jgarzik/bip100. 2015-09-03T06:41:20+00:00 + On September 2, 2015, Jeff Garzik sent an email to the bitcoin-dev mailing list sharing that he has created a repository containing the full text of BIP 100 discussion document in markdown format. The purpose of this repository is to check the BIP 100 formal specification before submitting it to the upstream bips.git repo. However, the previous email failed to include the link to the repository, so Garzik provides it in this message.The conversation within the email exchange discusses the concept of "votes" in relation to Bitcoin and the potential implementation of a fee market. It is unclear whether the voting process would be semi-automatic or fully automated. The number of options and values for votes can influence outcomes. The participants also discuss the newly introduced 1 MB floor in the bitcoin block size limit proposal. Luke Dashjr suggests combining certain rules and modifying the voting process to require 50% to set the limit floor. He questions why the new size limit votes must use 11 bytes of coinbase and suggests increasing the coinbase length to allow for 100 bytes in addition to the pushed height and size-vote. In a separate email exchange, Luke expresses concerns about the power to decrease the hard limit in the proposed BIP100. He suggests that miners have the ability to lower the block size locally or collectively without needing a vote. Luke also provides suggestions for improving BIP100, including combining rules, modifying the voting system, and increasing the coinbase length. Overall, Jeff Garzik's proposal aims to set a new 1 MB floor in the Bitcoin Improvement Proposal 100 (BIP 100) repository on GitHub. This would allow for future adjustments to the block size limit. However, some members of the community express concerns about the proposed limit being too high. Garzik suggests using a numeric value pushed after height instead of 11 bytes of coinbase for voting on the block size limit. He also proposes increasing the coinbase length to allow for additional bytes. Additionally, Garzik suggests combining rules to make it clear that the limit remains a part of the consensus protocol and modifying the voting process to require 50% to set the limit floor. In conclusion, Jeff Garzik opens a repository containing the full text of BIP 100 discussion document in markdown format on September 2, 2015. The purpose of this repository is to check the BIP 100 formal specification before submitting it to the upstream bips.git repo. The link to the repository can be found at https://github.com/jgarzik/bip100. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_BIP-100-specification.xml b/static/bitcoin-dev/Sept_2015/combined_BIP-100-specification.xml index 0a22899a4d..226cf53803 100644 --- a/static/bitcoin-dev/Sept_2015/combined_BIP-100-specification.xml +++ b/static/bitcoin-dev/Sept_2015/combined_BIP-100-specification.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - BIP 100 specification - 2023-08-01T15:57:54.790290+00:00 + 2025-10-11T21:55:00.325065+00:00 + python-feedgen Btc Drak 2015-09-04 15:40:26+00:00 @@ -83,13 +84,13 @@ - python-feedgen + 2 Combined summary - BIP 100 specification - 2023-08-01T15:57:54.791291+00:00 + 2025-10-11T21:55:00.325236+00:00 - There has been a recent change in the Bitcoin protocol that reduces the block size to 2MB. This change is likely due to concerns about an increase in the attack vector if BIP101's allowance for larger block sizes were implemented. Simon Liu suggested grabbing code from BIP101, which permits block messages greater than 2MB while retaining the current limit of 2MB on other network messages. The 32MB limit was patched a few months ago and can be found on Github. The limit is designed to keep message sizes small enough that they can be serialized in memory. There is discussion about lifting the 32MB limit and having the ceiling auto-raise according to a factor starting one year from now. The delay time could also be longer depending on how long it takes to fix the message size issue across all implementations.A suggestion has been made to grab some code from BIP101, which permits block messages larger than 2MB while retaining the current limit of 2 MB imposed on other network messages. The 32 MB limit was patched a few months ago and can be viewed on GitHub. The limit is in place to keep message sizes small enough to be serialized in memory. It has been suggested that the 32 MB ceiling should be auto-raised according to an exponential factor starting in 2017. The factor could be 1.5, and the delay time could be longer if it takes longer to fix the message size issue across all implementations.The 32MB limit has been set in the code to keep message size small enough for serialization in memory. A suggestion was made to lift the limit and implement an auto-raise ceiling according to an exponential factor starting from a year from now. The hard limit ceiling should be 32 MB till 2016-2017 and then it should be 32*((currentYear-2018)*1.5) MB after that. The factor could be 2 as in BIP-101 but a more conservative approach is suggested. The delay time can also be increased if needed.A discussion was held regarding the hardLimit range, which floats between 1-32M, inclusive. It was questioned if the 32MB limit still exists anywhere in the code since it reinstates a legacy limitation. It was explained that the message size limit aims to minimize storage required per peer and if a 32MB block size is required, each network input buffer must be at least 32MB, which makes it difficult for a node to support a large number of peers. It was suggested that sending messages containing only part of a block will make it possible to receive parts of a block from multiple sources. It was suggested that using MB resolution instead of byte resolution would use up fewer bytes in the coinbase. Even with the +/- 20% rule, miners can vote for the nearest MB. Abstains were suggested to count for the status quo, and votes that are out of range should be clamped.Regarding the new hardLimit, votes were suggested to sort from lowest to highest for the last 12,000 blocks. Blocks that do not have a vote are considered a vote for the status quo. Votes are limited to +/- 20% of the current value. The raise value is defined as the vote for the 2400th highest block (20th percentile), and the lower value is defined as the vote for the 9600th highest block (80th percentile). If the raise value is higher than the status quo, the new limit is set to the raise value. If the lower value is lower than the status quo, the new limit is set to the lower value. Otherwise, the size limit remains unchanged.In a message to the bitcoin-dev mailing list, Dave Scotese raised the issue of varying interpretations of the term "1M" in relation to bytes used by different people within the industry. He believes that "megabyte" should be used to refer specifically to 2^20 (1,048,576) bytes and that "Kb" should always mean 1024 bytes, rather than being rounded up or down. To clarify the situation, he suggested that the spec needed to nail down these details. The IEC standard, meanwhile, is to use the prefix MiB for 2^20 bytes.The Bitcoin community is currently discussing the implementation of BIP 100, a hard fork that would allow for an increase in block size. However, some members of the community are questioning why certain topics are being avoided in these discussions. One member suggests focusing on functionality rather than deployment methodologies to ensure a quick inclusion of the proposal.The discussion also delves into the proposed 75% rule, which some argue is meaningless since there are no invalid Version 4 blocks. There is also a debate about the unclear implication threshold, with one member advocating for a high threshold of 95% to prevent attacks on the original fork, while another argues for a lower threshold of 2015-09-04T15:40:26+00:00 + There has been a recent change in the Bitcoin protocol that reduces the block size to 2MB. This change is likely due to concerns about an increase in the attack vector if BIP101's allowance for larger block sizes were implemented. Simon Liu suggested grabbing code from BIP101, which permits block messages greater than 2MB while retaining the current limit of 2MB on other network messages. The 32MB limit was patched a few months ago and can be found on Github. The limit is designed to keep message sizes small enough that they can be serialized in memory. There is discussion about lifting the 32MB limit and having the ceiling auto-raise according to a factor starting one year from now. The delay time could also be longer depending on how long it takes to fix the message size issue across all implementations.A suggestion has been made to grab some code from BIP101, which permits block messages larger than 2MB while retaining the current limit of 2 MB imposed on other network messages. The 32 MB limit was patched a few months ago and can be viewed on GitHub. The limit is in place to keep message sizes small enough to be serialized in memory. It has been suggested that the 32 MB ceiling should be auto-raised according to an exponential factor starting in 2017. The factor could be 1.5, and the delay time could be longer if it takes longer to fix the message size issue across all implementations.The 32MB limit has been set in the code to keep message size small enough for serialization in memory. A suggestion was made to lift the limit and implement an auto-raise ceiling according to an exponential factor starting from a year from now. The hard limit ceiling should be 32 MB till 2016-2017 and then it should be 32*((currentYear-2018)*1.5) MB after that. The factor could be 2 as in BIP-101 but a more conservative approach is suggested. The delay time can also be increased if needed.A discussion was held regarding the hardLimit range, which floats between 1-32M, inclusive. It was questioned if the 32MB limit still exists anywhere in the code since it reinstates a legacy limitation. It was explained that the message size limit aims to minimize storage required per peer and if a 32MB block size is required, each network input buffer must be at least 32MB, which makes it difficult for a node to support a large number of peers. It was suggested that sending messages containing only part of a block will make it possible to receive parts of a block from multiple sources. It was suggested that using MB resolution instead of byte resolution would use up fewer bytes in the coinbase. Even with the +/- 20% rule, miners can vote for the nearest MB. Abstains were suggested to count for the status quo, and votes that are out of range should be clamped.Regarding the new hardLimit, votes were suggested to sort from lowest to highest for the last 12,000 blocks. Blocks that do not have a vote are considered a vote for the status quo. Votes are limited to +/- 20% of the current value. The raise value is defined as the vote for the 2400th highest block (20th percentile), and the lower value is defined as the vote for the 9600th highest block (80th percentile). If the raise value is higher than the status quo, the new limit is set to the raise value. If the lower value is lower than the status quo, the new limit is set to the lower value. Otherwise, the size limit remains unchanged.In a message to the bitcoin-dev mailing list, Dave Scotese raised the issue of varying interpretations of the term "1M" in relation to bytes used by different people within the industry. He believes that "megabyte" should be used to refer specifically to 2^20 (1,048,576) bytes and that "Kb" should always mean 1024 bytes, rather than being rounded up or down. To clarify the situation, he suggested that the spec needed to nail down these details. The IEC standard, meanwhile, is to use the prefix MiB for 2^20 bytes.The Bitcoin community is currently discussing the implementation of BIP 100, a hard fork that would allow for an increase in block size. However, some members of the community are questioning why certain topics are being avoided in these discussions. One member suggests focusing on functionality rather than deployment methodologies to ensure a quick inclusion of the proposal.The discussion also delves into the proposed 75% rule, which some argue is meaningless since there are no invalid Version 4 blocks. There is also a debate about the unclear implication threshold, with one member advocating for a high threshold of 95% to prevent attacks on the original fork, while another argues for a lower threshold of - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Bitcoin-Core-0-12-0-release-schedule.xml b/static/bitcoin-dev/Sept_2015/combined_Bitcoin-Core-0-12-0-release-schedule.xml index 2da070f801..52b60dbfef 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Bitcoin-Core-0-12-0-release-schedule.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Bitcoin-Core-0-12-0-release-schedule.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Core 0.12.0 release schedule - 2023-08-01T16:16:06.482460+00:00 + 2025-10-11T21:55:23.687996+00:00 + python-feedgen Btc Drak 2015-10-01 09:17:52+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Core 0.12.0 release schedule - 2023-08-01T16:16:06.482460+00:00 + 2025-10-11T21:55:23.688150+00:00 - In a Bitcoin developer email thread in October 2015, Marcel Jamin questioned the versioning of Bitcoin and its alignment with SemVer specifications. Another developer responded by explaining that Bitcoin does follow the SemVer standard, using the format a.b.c, with major releases represented by a new second digit and maintenance releases indicated by a third digit change. The email thread sheds light on the technical aspects of Bitcoin development and emphasizes the importance of adhering to industry standards.In a bitcoin-dev mailing list discussion in 2015, Wladimir J. van der Laan, Bitcoin Core's lead maintainer, addressed the versioning of Bitcoin software not following the Semantic Versioning (SemVer) specification. Van der Laan mentioned that only critical bug fixes would be included in the feature freeze for version 0.12 and that postponing the release for consensus changes was not ideal. He also acknowledged the idea of decoupling consensus changes from major releases to avoid release date drift. The conversation concluded with the suggestion of creating a 0.12.1 release if necessary.On September 24th, 2015, van der Laan announced a feature freeze for Bitcoin Core 0.12 on December 1st of that year. Luke Dashjr responded by expressing concern about postponing the release and the potential delay it could cause in developing, testing, and reviewing new code. Dashjr also highlighted the issue of release date drift due to changes needing to be added. Van der Laan clarified that the feature freeze meant only critical bug fixes could be made to version 0.12 but acknowledged the benefits of decoupling consensus changes from major releases. He suggested the possibility of a 0.12.1 release if needed.In another discussion on the Bitcoin-dev mailing list, Luke Dashjr initiated a conversation about the consensus freeze for the upcoming Bitcoin Core release. Dashjr recommended postponing the consensus freeze until after the HK workshop in case a hardfork was decided on. He also questioned whether the consensus freeze had been entirely decoupled from the release process, considering that old versions required an update as well. The discussion did not provide specific information about the outcome or decision regarding the consensus freeze.During this ongoing discussion around updates to the Bitcoin protocol in September 2015, a member expressed their belief that consensus rule changes could be minor releases if they were not ready in time for a major release. Luke Dashjr raised concerns about the absence of a "Consensus freeze" and suggested postponing it until after the HK workshop in case a hardfork was decided on. The conversation aimed to address various aspects of the Bitcoin protocol development.Wladimir J. van der Laan announced a feature freeze on the Bitcoin protocol for December 1, 2015, via bitcoin-dev on September 24, 2015. However, Luke questioned the absence of a "Consensus freeze" and proposed delaying it until after the HK workshop in case a hardfork was decided on. Luke also raised concerns about the potential decoupling of the consensus freeze from the release process, as old versions would still require an update.According to a post by Wladimir J. van der Laan on the Bitcoin development mailing list, the next major release of Bitcoin Core, 0.12.0, is planned for the end of 2015. The proposed schedule includes opening Transifex translations for 0.12 on November 1st, finalizing and closing translation for 0.10, and implementing a feature freeze and translation string freeze on December 1st. In January, the plan is to split off the `0.12` branch from `master`, start the RC cycle, tag and release `0.12.0rc1`, and begin merging for 0.13 on the master branch. The final release of version 0.12.0 is expected on February 1st, 2016. Due to events such as Scaling Bitcoin Hongkong and end-of-year festivities in December, pre-RC bugfixes and polishing will be postponed.The Bitcoin Core team is preparing for the next major release, 0.12.0, by the end of the year. The proposed schedule involves opening Transifex translations for 0.12 on November 1st, with a soft translation string freeze to avoid unnecessary changes. On December 1st, a feature and translation string freeze will take place. In January, the team plans to split off the `0.12` branch from `master`, initiate the RC cycle, tag and release `0.12.0rc1`, and begin merging for 0.13 on the master branch. The final release of version 0.12.0 is anticipated for February 1st. As many team members will be occupied with events like Scaling Bitcoin Hongkong and end-of-year festivities in December, pre-RC bugfixes and polishing tasks will be deferred 2015-10-01T09:17:52+00:00 + In a Bitcoin developer email thread in October 2015, Marcel Jamin questioned the versioning of Bitcoin and its alignment with SemVer specifications. Another developer responded by explaining that Bitcoin does follow the SemVer standard, using the format a.b.c, with major releases represented by a new second digit and maintenance releases indicated by a third digit change. The email thread sheds light on the technical aspects of Bitcoin development and emphasizes the importance of adhering to industry standards.In a bitcoin-dev mailing list discussion in 2015, Wladimir J. van der Laan, Bitcoin Core's lead maintainer, addressed the versioning of Bitcoin software not following the Semantic Versioning (SemVer) specification. Van der Laan mentioned that only critical bug fixes would be included in the feature freeze for version 0.12 and that postponing the release for consensus changes was not ideal. He also acknowledged the idea of decoupling consensus changes from major releases to avoid release date drift. The conversation concluded with the suggestion of creating a 0.12.1 release if necessary.On September 24th, 2015, van der Laan announced a feature freeze for Bitcoin Core 0.12 on December 1st of that year. Luke Dashjr responded by expressing concern about postponing the release and the potential delay it could cause in developing, testing, and reviewing new code. Dashjr also highlighted the issue of release date drift due to changes needing to be added. Van der Laan clarified that the feature freeze meant only critical bug fixes could be made to version 0.12 but acknowledged the benefits of decoupling consensus changes from major releases. He suggested the possibility of a 0.12.1 release if needed.In another discussion on the Bitcoin-dev mailing list, Luke Dashjr initiated a conversation about the consensus freeze for the upcoming Bitcoin Core release. Dashjr recommended postponing the consensus freeze until after the HK workshop in case a hardfork was decided on. He also questioned whether the consensus freeze had been entirely decoupled from the release process, considering that old versions required an update as well. The discussion did not provide specific information about the outcome or decision regarding the consensus freeze.During this ongoing discussion around updates to the Bitcoin protocol in September 2015, a member expressed their belief that consensus rule changes could be minor releases if they were not ready in time for a major release. Luke Dashjr raised concerns about the absence of a "Consensus freeze" and suggested postponing it until after the HK workshop in case a hardfork was decided on. The conversation aimed to address various aspects of the Bitcoin protocol development.Wladimir J. van der Laan announced a feature freeze on the Bitcoin protocol for December 1, 2015, via bitcoin-dev on September 24, 2015. However, Luke questioned the absence of a "Consensus freeze" and proposed delaying it until after the HK workshop in case a hardfork was decided on. Luke also raised concerns about the potential decoupling of the consensus freeze from the release process, as old versions would still require an update.According to a post by Wladimir J. van der Laan on the Bitcoin development mailing list, the next major release of Bitcoin Core, 0.12.0, is planned for the end of 2015. The proposed schedule includes opening Transifex translations for 0.12 on November 1st, finalizing and closing translation for 0.10, and implementing a feature freeze and translation string freeze on December 1st. In January, the plan is to split off the `0.12` branch from `master`, start the RC cycle, tag and release `0.12.0rc1`, and begin merging for 0.13 on the master branch. The final release of version 0.12.0 is expected on February 1st, 2016. Due to events such as Scaling Bitcoin Hongkong and end-of-year festivities in December, pre-RC bugfixes and polishing will be postponed.The Bitcoin Core team is preparing for the next major release, 0.12.0, by the end of the year. The proposed schedule involves opening Transifex translations for 0.12 on November 1st, with a soft translation string freeze to avoid unnecessary changes. On December 1st, a feature and translation string freeze will take place. In January, the team plans to split off the `0.12` branch from `master`, initiate the RC cycle, tag and release `0.12.0rc1`, and begin merging for 0.13 on the master branch. The final release of version 0.12.0 is anticipated for February 1st. As many team members will be occupied with events like Scaling Bitcoin Hongkong and end-of-year festivities in December, pre-RC bugfixes and polishing tasks will be deferred - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Bitcoin-Days-Destroyed-as-block-selection-heuristic.xml b/static/bitcoin-dev/Sept_2015/combined_Bitcoin-Days-Destroyed-as-block-selection-heuristic.xml index 0c9ea0822d..148805348a 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Bitcoin-Days-Destroyed-as-block-selection-heuristic.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Bitcoin-Days-Destroyed-as-block-selection-heuristic.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin Days Destroyed as block selection heuristic - 2023-08-01T16:04:49.324544+00:00 + 2025-10-11T21:54:13.604468+00:00 + python-feedgen Dave Scotese 2015-09-12 18:55:03+00:00 @@ -35,13 +36,13 @@ - python-feedgen + 2 Combined summary - Bitcoin Days Destroyed as block selection heuristic - 2023-08-01T16:04:49.324544+00:00 + 2025-10-11T21:54:13.604627+00:00 - The Bitcoin transaction fee is calculated based on the sum of input age weighted by value and divided by transaction size in bytes. Vincent Truong expressed concerns about how this could alter the prioritization of transactions in order to win, potentially resulting in a bad outcome for Bitcoin's fungibility.The proposal suggests a new policy aimed at improving the way transactions are prioritized by miners. The suggested heuristic involves comparing the Bitcoin Days Destroyed (BTCDD) of two valid blocks and choosing the one with the best BTCDD, but only for transactions that are already in the mempool. This policy would benefit Bitcoin in terms of increased stability, motivating miners to add transactions, decreasing the utility of any global private network of nodes intended to spread selfishly-mined blocks, and motivating miners to stay well-connected so that they get transactions quickly. However, the proposal is not a consensus rule and everyone would be free to ignore it.The proposal suggests a new heuristic for miners to choose between two valid blocks they receive, which is to compare the BTCDD (Bitcoin Days Destroyed) of transactions already present in their mempool and weigh it so that older transactions are more important. This would increase bitcoin stability by making it easier for clients to decide which block is valid when they see two competing with each other, motivating miners to add transactions instead of mining empty blocks, decreasing the utility of any global private network of nodes intended to spread selfishly-mined blocks, and motivating miners to stay well-connected so that they get transactions quickly.The discussion revolves around the proposal made by Dave Scotese via bitcoin-dev mailing list. He proposed a more sophisticated method of choosing which of two block solutions to accept instead of using the 'first-seen' block. There is confusion about how to determine which of 2 blocks with the same height is newer. It is also discussed whether miners would benefit from running the proposed policy in the long run or not. There is always a default, and if miners don't have any overriding reason to change, they'll likely stick to it. Any changed logic is non-binding. If miners don't use the proposed policy, users won't benefit from running that policy themselves either. They will still have to wait for block confirmation to reduce the chances of a successful double-spend attack with each new confirmation.In an email thread titled "Alternate tie-breaker proposal" on the Bitcoin-dev mailing list, Christophe Biocca and Jorge Timón discuss Dave Scotese's proposal for a more sophisticated method of choosing which of two block solutions to accept. Biocca believes that it is not necessary since miners would not benefit from running this policy in the long run, and users would still have to keep waiting for block confirmations to reduce the chances of a successful double-spend attack. Timón points out that there is already a criterion to choose between two blocks: the one with more work in valid blocks on top of it. However, the issue of determining which of two blocks with the same height is "newer" remains unclear.Dave has proposed a new method of choosing between two block solutions. He suggests that instead of using the first-seen block, a more sophisticated tie-breaker should be used. This new heuristic could lead miners to safely mine a sibling block instead of a child block when a new block with the most work is seen and there are no ties. However, it also opens up the possibility for miners to double-spend some confirmed transactions and orphan a small non-empty block whenever the block confirming them is easily replaced. This could lower the security of 1-conf transactions. The risk can be measured and is sometimes very small, but this issue can be fixed by preferring non-empty blocks to empty ones or only switching if the new block doesn't double spend transactions in the old one. Jorge Timón states that there is already a criterion to choose between two block solutions: the one with more work (in valid blocks) on top of it.In a discussion on the bitcoin-dev mailing list, Dave Scotese proposes a more sophisticated method for choosing which of two block solutions to accept. Rather than relying on the first-seen block, he suggests using the criterion of the one with more work (in valid blocks) on top of it. This proposal aims to improve the security and efficiency of the bitcoin network.The proposal suggests a sophisticated method for choosing between two block solutions by computing a weighted sum of bitcoin-days-destroyed (BTCDD), where transactions received earlier are given higher weights. This method avoids allowing miners to use private transactions to manipulate the blockchain and also makes empty blocks less attractive. The proposal was posted on the stackexchange bitcoin site, and after addressing objections and problems, no significant issues were found. While some may argue that empty blocks and selfish mining aren't harmful to Bitcoin, proponents of the proposal are encouraged to collaborate on an implementation. 2015-09-12T18:55:03+00:00 + The Bitcoin transaction fee is calculated based on the sum of input age weighted by value and divided by transaction size in bytes. Vincent Truong expressed concerns about how this could alter the prioritization of transactions in order to win, potentially resulting in a bad outcome for Bitcoin's fungibility.The proposal suggests a new policy aimed at improving the way transactions are prioritized by miners. The suggested heuristic involves comparing the Bitcoin Days Destroyed (BTCDD) of two valid blocks and choosing the one with the best BTCDD, but only for transactions that are already in the mempool. This policy would benefit Bitcoin in terms of increased stability, motivating miners to add transactions, decreasing the utility of any global private network of nodes intended to spread selfishly-mined blocks, and motivating miners to stay well-connected so that they get transactions quickly. However, the proposal is not a consensus rule and everyone would be free to ignore it.The proposal suggests a new heuristic for miners to choose between two valid blocks they receive, which is to compare the BTCDD (Bitcoin Days Destroyed) of transactions already present in their mempool and weigh it so that older transactions are more important. This would increase bitcoin stability by making it easier for clients to decide which block is valid when they see two competing with each other, motivating miners to add transactions instead of mining empty blocks, decreasing the utility of any global private network of nodes intended to spread selfishly-mined blocks, and motivating miners to stay well-connected so that they get transactions quickly.The discussion revolves around the proposal made by Dave Scotese via bitcoin-dev mailing list. He proposed a more sophisticated method of choosing which of two block solutions to accept instead of using the 'first-seen' block. There is confusion about how to determine which of 2 blocks with the same height is newer. It is also discussed whether miners would benefit from running the proposed policy in the long run or not. There is always a default, and if miners don't have any overriding reason to change, they'll likely stick to it. Any changed logic is non-binding. If miners don't use the proposed policy, users won't benefit from running that policy themselves either. They will still have to wait for block confirmation to reduce the chances of a successful double-spend attack with each new confirmation.In an email thread titled "Alternate tie-breaker proposal" on the Bitcoin-dev mailing list, Christophe Biocca and Jorge Timón discuss Dave Scotese's proposal for a more sophisticated method of choosing which of two block solutions to accept. Biocca believes that it is not necessary since miners would not benefit from running this policy in the long run, and users would still have to keep waiting for block confirmations to reduce the chances of a successful double-spend attack. Timón points out that there is already a criterion to choose between two blocks: the one with more work in valid blocks on top of it. However, the issue of determining which of two blocks with the same height is "newer" remains unclear.Dave has proposed a new method of choosing between two block solutions. He suggests that instead of using the first-seen block, a more sophisticated tie-breaker should be used. This new heuristic could lead miners to safely mine a sibling block instead of a child block when a new block with the most work is seen and there are no ties. However, it also opens up the possibility for miners to double-spend some confirmed transactions and orphan a small non-empty block whenever the block confirming them is easily replaced. This could lower the security of 1-conf transactions. The risk can be measured and is sometimes very small, but this issue can be fixed by preferring non-empty blocks to empty ones or only switching if the new block doesn't double spend transactions in the old one. Jorge Timón states that there is already a criterion to choose between two block solutions: the one with more work (in valid blocks) on top of it.In a discussion on the bitcoin-dev mailing list, Dave Scotese proposes a more sophisticated method for choosing which of two block solutions to accept. Rather than relying on the first-seen block, he suggests using the criterion of the one with more work (in valid blocks) on top of it. This proposal aims to improve the security and efficiency of the bitcoin network.The proposal suggests a sophisticated method for choosing between two block solutions by computing a weighted sum of bitcoin-days-destroyed (BTCDD), where transactions received earlier are given higher weights. This method avoids allowing miners to use private transactions to manipulate the blockchain and also makes empty blocks less attractive. The proposal was posted on the stackexchange bitcoin site, and after addressing objections and problems, no significant issues were found. While some may argue that empty blocks and selfish mining aren't harmful to Bitcoin, proponents of the proposal are encouraged to collaborate on an implementation. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Bitcoin-mining-idea.xml b/static/bitcoin-dev/Sept_2015/combined_Bitcoin-mining-idea.xml index 8a8d3832f5..b5fd0c5a77 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Bitcoin-mining-idea.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Bitcoin-mining-idea.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Bitcoin mining idea - 2023-08-01T16:17:45.125285+00:00 + 2025-10-11T21:55:13.067569+00:00 + python-feedgen Jeff Garzik 2015-09-30 00:10:57+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Bitcoin mining idea - 2023-08-01T16:17:45.125285+00:00 + 2025-10-11T21:55:13.067743+00:00 - The bitcoin-dev mailing list, created in 2011, was originally intended for highly technical discussions and to avoid philosophical debates. However, Bitcoin has evolved over time, leading to an expanded group of stakeholders. It is now crucial for the list's description to clearly outline the topics that can be discussed, ensuring relevant and focused conversations. The aim is to address the issue of off-topic noise that is hindering productivity. A separate discussion list is being considered as an outlet for non-technical discussions.In September 2015, a discussion arose regarding statements about a developer's personal character being considered off-topic on the bitcoin-dev list. Jonathan Toomim argued that such comments should not be discussed, but acknowledged that enforcing this rule would result in a significant percentage of discussions being deemed off-topic. This suggests that personal attacks or comments about developers' characters were common at that time.On September 29, 2015, Jeff Garzik, a prominent member of the bitcoin development community, deemed a topic off-topic for the mailing list. In response, Milly Bitcoin accused Garzik of acting with authority and attempting to bully others, suggesting that he should focus on reviewing his company's handling and security measures related to bitcoin. Making statements about a developer's personal character was also noted as off-topic for the list.Another post on the bitcoin-dev list in September 2015 sought a partner to develop a gamified bitcoin mining app. The author was looking for someone knowledgeable in cryptography and the bitcoin code base. Although there was some interest, the ideal candidate had not been found yet. Interested individuals were instructed to contact the author via email.The author of a different post responded to claims that certain topics on the bitcoin-dev list were off-topic. They argued that the list's subject was broad enough to encompass various topics and accused certain individuals of making up their own rules without proper authority or guidelines. The author suggested that a more precise description may be necessary if the discussion is to be limited in any way beyond the current official description.Additionally, Neil Haran proposed building a massive rock paper scissors tournament using bitcoin-qt. Each player would participate in a best-of-five tournament each round, with players randomly matched against each other. The number of rounds would correspond to the depth of a binary tree. Neil believed that he could get millions of people playing in this tournament and offered a cash prize. However, Lauri Love advised Neil not to solicit interest in advance, but rather share the idea first and allow people to volunteer their interest and assistance if they found it compelling.In summary, the bitcoin-dev mailing list has undergone changes over time, prompting the need for a clear description of acceptable topics. There have been discussions about personal attacks, off-topic noise, and the potential creation of a separate list for non-technical conversations. The list has also seen posts seeking partners for app development and proposals for large-scale tournaments using bitcoin-qt. 2015-09-30T00:10:57+00:00 + The bitcoin-dev mailing list, created in 2011, was originally intended for highly technical discussions and to avoid philosophical debates. However, Bitcoin has evolved over time, leading to an expanded group of stakeholders. It is now crucial for the list's description to clearly outline the topics that can be discussed, ensuring relevant and focused conversations. The aim is to address the issue of off-topic noise that is hindering productivity. A separate discussion list is being considered as an outlet for non-technical discussions.In September 2015, a discussion arose regarding statements about a developer's personal character being considered off-topic on the bitcoin-dev list. Jonathan Toomim argued that such comments should not be discussed, but acknowledged that enforcing this rule would result in a significant percentage of discussions being deemed off-topic. This suggests that personal attacks or comments about developers' characters were common at that time.On September 29, 2015, Jeff Garzik, a prominent member of the bitcoin development community, deemed a topic off-topic for the mailing list. In response, Milly Bitcoin accused Garzik of acting with authority and attempting to bully others, suggesting that he should focus on reviewing his company's handling and security measures related to bitcoin. Making statements about a developer's personal character was also noted as off-topic for the list.Another post on the bitcoin-dev list in September 2015 sought a partner to develop a gamified bitcoin mining app. The author was looking for someone knowledgeable in cryptography and the bitcoin code base. Although there was some interest, the ideal candidate had not been found yet. Interested individuals were instructed to contact the author via email.The author of a different post responded to claims that certain topics on the bitcoin-dev list were off-topic. They argued that the list's subject was broad enough to encompass various topics and accused certain individuals of making up their own rules without proper authority or guidelines. The author suggested that a more precise description may be necessary if the discussion is to be limited in any way beyond the current official description.Additionally, Neil Haran proposed building a massive rock paper scissors tournament using bitcoin-qt. Each player would participate in a best-of-five tournament each round, with players randomly matched against each other. The number of rounds would correspond to the depth of a binary tree. Neil believed that he could get millions of people playing in this tournament and offered a cash prize. However, Lauri Love advised Neil not to solicit interest in advance, but rather share the idea first and allow people to volunteer their interest and assistance if they found it compelling.In summary, the bitcoin-dev mailing list has undergone changes over time, prompting the need for a clear description of acceptable topics. There have been discussions about personal attacks, off-topic noise, and the potential creation of a separate list for non-technical conversations. The list has also seen posts seeking partners for app development and proposals for large-scale tournaments using bitcoin-qt. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Build-win64-Package-mingw-w64-dev-has-no-installation-candidate.xml b/static/bitcoin-dev/Sept_2015/combined_Build-win64-Package-mingw-w64-dev-has-no-installation-candidate.xml index e52e72a050..0e69b54a3c 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Build-win64-Package-mingw-w64-dev-has-no-installation-candidate.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Build-win64-Package-mingw-w64-dev-has-no-installation-candidate.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Build: win64: Package 'mingw-w64-dev' has no installation candidate - 2023-08-01T16:17:21.297066+00:00 + 2025-10-11T21:54:34.832973+00:00 + python-feedgen Roy Osherove 2015-09-29 06:09:36+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Build: win64: Package 'mingw-w64-dev' has no installation candidate - 2023-08-01T16:17:21.297066+00:00 + 2025-10-11T21:54:34.833128+00:00 - During an email conversation between Joseph Bisch and Roy Osherove, it was observed that the TeamCity setup was using Ubuntu Trusty for builds, while Travis CI was employing Ubuntu Precise. This difference in operating systems led to an issue where the mingw-w64-dev package was only available in Precise. The email mentioned that the package had been divided into mingw-w64-x86-64-dev and mingw-w64-i686-dev, both of which needed to be used with Ubuntu Trusty. Relevant links to pages regarding these packages and operating systems were shared in the email.A user is attempting to recreate the Travis CI build system using TeamCity in order to gain a better understanding of bitcoin builds. However, they are encountering difficulties in acquiring mingw dev during the Windows builds, as they receive an error message stating "Package 'mingw-w64-dev' has no installation candidate". The user has attempted to use the same export environment variables as the Travis script and even tried implementing the Travis script within TeamCity, but the problem persists. The PPA (Personal Package Archive) appears to be importing correctly during the build process. The agent is running on a docker image based on Ubuntu.The user has shared the complete log of the failed build and is seeking suggestions as to why it works on Travis but not on the TeamCity build agent. They also mention that the same issue arises in the win32 build. In conclusion, the user expresses gratitude to everyone involved and provides their contact details. 2015-09-29T06:09:36+00:00 + During an email conversation between Joseph Bisch and Roy Osherove, it was observed that the TeamCity setup was using Ubuntu Trusty for builds, while Travis CI was employing Ubuntu Precise. This difference in operating systems led to an issue where the mingw-w64-dev package was only available in Precise. The email mentioned that the package had been divided into mingw-w64-x86-64-dev and mingw-w64-i686-dev, both of which needed to be used with Ubuntu Trusty. Relevant links to pages regarding these packages and operating systems were shared in the email.A user is attempting to recreate the Travis CI build system using TeamCity in order to gain a better understanding of bitcoin builds. However, they are encountering difficulties in acquiring mingw dev during the Windows builds, as they receive an error message stating "Package 'mingw-w64-dev' has no installation candidate". The user has attempted to use the same export environment variables as the Travis script and even tried implementing the Travis script within TeamCity, but the problem persists. The PPA (Personal Package Archive) appears to be importing correctly during the build process. The agent is running on a docker image based on Ubuntu.The user has shared the complete log of the failed build and is seeking suggestions as to why it works on Travis but not on the TeamCity build agent. They also mention that the same issue arises in the win32 build. In conclusion, the user expresses gratitude to everyone involved and provides their contact details. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_CI-Build-for-Bitcoin-Some-Basic-Questions-about-Gitian-and-other-stuff.xml b/static/bitcoin-dev/Sept_2015/combined_CI-Build-for-Bitcoin-Some-Basic-Questions-about-Gitian-and-other-stuff.xml index 0d872e374e..3bed0b8398 100644 --- a/static/bitcoin-dev/Sept_2015/combined_CI-Build-for-Bitcoin-Some-Basic-Questions-about-Gitian-and-other-stuff.xml +++ b/static/bitcoin-dev/Sept_2015/combined_CI-Build-for-Bitcoin-Some-Basic-Questions-about-Gitian-and-other-stuff.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - CI Build for Bitcoin - Some Basic Questions about Gitian and other stuff - 2023-08-01T16:15:02.529131+00:00 + 2025-10-11T21:55:04.571588+00:00 + python-feedgen Jonas Schnelli 2015-09-24 09:18:16+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - CI Build for Bitcoin - Some Basic Questions about Gitian and other stuff - 2023-08-01T16:15:02.530131+00:00 + 2025-10-11T21:55:04.571757+00:00 - The core developers of Bitcoin are responsible for manually uploading Gitian builds to bitcoin.org. Users who choose to run a pre-compiled version of Bitcoin Core are advised to verify the binary against the available Gitian signatures. The signatures can be found in the signature repository at https://github.com/bitcoin/gitian.sigs. PGP Pubkeys for verification can be found at https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-downloader, and instructions for verifying Bitcoin Core can be found at https://www.reddit.com/r/Bitcoin/wiki/verifying_bitcoin_core.A discussion between Mark Friedenbach and Roy Osherove in September 2015 revealed that there is no build server where Gitian builds are automatically done and made available on bitcoin.org. This manual process ensures the integrity of the builds. Quorum signatures for the Gitian builds can be found on the GitHub page for gitian.sigs. Roy Osherove inquired about the availability of a public server to view the Gitian builds and quorum verifications. However, Mark Friedenbach explained that the binaries on bitcoin.org are built using the Gitian process and signed by a quorum of developers, and Travis-CI is not considered a trusted platform. Therefore, there is no public server for viewing the Gitian builds or quorum verifications.A discussion on the bitcoin-dev mailing list also touched upon the topic of reproducible builds using TeamCity. Roy Osherove sought clarification on whether all platforms need to be supported and if Gitian is necessary. Mark Friedenbach responded by emphasizing that the binaries on bitcoin.org are built using Gitian and signed by a quorum of developers. Meanwhile, Travis-CI is used to ensure successful compilation and testing on all supported platforms, but the produced binaries are not trusted. Consequently, there is no public server available for viewing Gitian builds or quorum verifications.In his quest to create a reproducible build of Bitcoin and Bitcoin-XT using TeamCity, Roy Osherove requested feedback and suggestions. He questioned the necessity of all flavors of builds and the requirement for Gitian. Osherove's own build can be accessed at http://btcdev.osherove.com:8111/. He welcomed input on whether all platforms need to be supported and if Gitian is truly necessary. Osherove expressed openness to ideas for additional features that people would like to see in the build. 2015-09-24T09:18:16+00:00 + The core developers of Bitcoin are responsible for manually uploading Gitian builds to bitcoin.org. Users who choose to run a pre-compiled version of Bitcoin Core are advised to verify the binary against the available Gitian signatures. The signatures can be found in the signature repository at https://github.com/bitcoin/gitian.sigs. PGP Pubkeys for verification can be found at https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-downloader, and instructions for verifying Bitcoin Core can be found at https://www.reddit.com/r/Bitcoin/wiki/verifying_bitcoin_core.A discussion between Mark Friedenbach and Roy Osherove in September 2015 revealed that there is no build server where Gitian builds are automatically done and made available on bitcoin.org. This manual process ensures the integrity of the builds. Quorum signatures for the Gitian builds can be found on the GitHub page for gitian.sigs. Roy Osherove inquired about the availability of a public server to view the Gitian builds and quorum verifications. However, Mark Friedenbach explained that the binaries on bitcoin.org are built using the Gitian process and signed by a quorum of developers, and Travis-CI is not considered a trusted platform. Therefore, there is no public server for viewing the Gitian builds or quorum verifications.A discussion on the bitcoin-dev mailing list also touched upon the topic of reproducible builds using TeamCity. Roy Osherove sought clarification on whether all platforms need to be supported and if Gitian is necessary. Mark Friedenbach responded by emphasizing that the binaries on bitcoin.org are built using Gitian and signed by a quorum of developers. Meanwhile, Travis-CI is used to ensure successful compilation and testing on all supported platforms, but the produced binaries are not trusted. Consequently, there is no public server available for viewing Gitian builds or quorum verifications.In his quest to create a reproducible build of Bitcoin and Bitcoin-XT using TeamCity, Roy Osherove requested feedback and suggestions. He questioned the necessity of all flavors of builds and the requirement for Gitian. Osherove's own build can be accessed at http://btcdev.osherove.com:8111/. He welcomed input on whether all platforms need to be supported and if Gitian is truly necessary. Osherove expressed openness to ideas for additional features that people would like to see in the build. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Design-Competition.xml b/static/bitcoin-dev/Sept_2015/combined_Design-Competition.xml index a7d9bce67e..523a7aa676 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Design-Competition.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Design-Competition.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Design Competition - 2023-08-01T16:27:10.245229+00:00 + 2025-10-11T21:54:36.965027+00:00 + python-feedgen odinn 2015-10-01 04:38:50+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Design Competition - 2023-08-01T16:27:10.245229+00:00 + 2025-10-11T21:54:36.965196+00:00 - Lykke Corp, a trading platform for foreign exchange, is funding a Bitcoin-related competition aimed at building a trading platform that allows participants to settle their trades through the blockchain via colored coins. The competition, which will initially focus on foreign exchange, aims to create a community-driven effort rather than proprietary technology. The use of a sidechain is suggested but not required for trade reconciliation. Participants in the competition will receive 2 million Lykke coins ($8,000 USD) allocated for core development over the next three months. More details on the requirements can be found on the Lykke website. Richard Olsen, CEO of Lykke, encourages questions to be asked during an online briefing event or over email.In response to the announcement of the competition, one member of the bitcoin-dev mailing list questions why the funds are not being used to fund Core development instead. Another member suggests that the Bitcointalk Altcoin section would be the best place for announcements regarding such projects. The original poster expresses their desire for a dedicated mailing list that is not solely focused on digital cash systems and welcomes discussions about 2.0 projects. Benjamin, another member of the mailing list, believes there is room for a better board/list for new 2.0 projects and offers to help build it.The competition, announced by Richard Olsen, seeks participants to build a trading platform using colored coins on the blockchain for settling trades. The competition is community-driven and contributions will be made available under an MIT license on Github. Although the use of a sidechain is suggested, it is not mandatory. The competition will initially focus on foreign exchange, with other assets to follow. Interested parties can attend an online briefing event or visit www.lykkex.com for more information. Contributions will be made available under an MIT license on Github to foster a community-driven project.In a post on Bitcoin-dev, Eric Lombrozo highlights the issue of finding developers for new services in the Bitcoin ecosystem. While some proposals receive significant interest if made by well-known individuals, others are dismissed as spam or ridiculed if coming from unknown sources. The author suggests creating a list where people can discuss proposed and ongoing projects and look for developers to hire.Overall, the discussion revolves around the need for a more open mailing list for Bitcoin and the announcement of a Bitcoin trading platform competition. The competition aims to build a trading platform for foreign exchange and other assets using colored coins and potentially a sidechain. The contributions made will be available under an MIT license on Github. Participants will have the opportunity to settle their trades through the blockchain. 2015-10-01T04:38:50+00:00 + Lykke Corp, a trading platform for foreign exchange, is funding a Bitcoin-related competition aimed at building a trading platform that allows participants to settle their trades through the blockchain via colored coins. The competition, which will initially focus on foreign exchange, aims to create a community-driven effort rather than proprietary technology. The use of a sidechain is suggested but not required for trade reconciliation. Participants in the competition will receive 2 million Lykke coins ($8,000 USD) allocated for core development over the next three months. More details on the requirements can be found on the Lykke website. Richard Olsen, CEO of Lykke, encourages questions to be asked during an online briefing event or over email.In response to the announcement of the competition, one member of the bitcoin-dev mailing list questions why the funds are not being used to fund Core development instead. Another member suggests that the Bitcointalk Altcoin section would be the best place for announcements regarding such projects. The original poster expresses their desire for a dedicated mailing list that is not solely focused on digital cash systems and welcomes discussions about 2.0 projects. Benjamin, another member of the mailing list, believes there is room for a better board/list for new 2.0 projects and offers to help build it.The competition, announced by Richard Olsen, seeks participants to build a trading platform using colored coins on the blockchain for settling trades. The competition is community-driven and contributions will be made available under an MIT license on Github. Although the use of a sidechain is suggested, it is not mandatory. The competition will initially focus on foreign exchange, with other assets to follow. Interested parties can attend an online briefing event or visit www.lykkex.com for more information. Contributions will be made available under an MIT license on Github to foster a community-driven project.In a post on Bitcoin-dev, Eric Lombrozo highlights the issue of finding developers for new services in the Bitcoin ecosystem. While some proposals receive significant interest if made by well-known individuals, others are dismissed as spam or ridiculed if coming from unknown sources. The author suggests creating a list where people can discuss proposed and ongoing projects and look for developers to hire.Overall, the discussion revolves around the need for a more open mailing list for Bitcoin and the announcement of a Bitcoin trading platform competition. The competition aims to build a trading platform for foreign exchange and other assets using colored coins and potentially a sidechain. The contributions made will be available under an MIT license on Github. Participants will have the opportunity to settle their trades through the blockchain. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Dynamic-limit-to-the-block-size-BIP-draft-discussion.xml b/static/bitcoin-dev/Sept_2015/combined_Dynamic-limit-to-the-block-size-BIP-draft-discussion.xml index c37e10b6f6..57660a293d 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Dynamic-limit-to-the-block-size-BIP-draft-discussion.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Dynamic-limit-to-the-block-size-BIP-draft-discussion.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Dynamic limit to the block size - BIP draft discussion - 2023-08-01T16:03:07.802781+00:00 + 2025-10-11T21:55:30.058919+00:00 + python-feedgen Washington Sanchez 2015-09-09 13:10:43+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Dynamic limit to the block size - BIP draft discussion - 2023-08-01T16:03:07.802781+00:00 + 2025-10-11T21:55:30.059065+00:00 - The proposal suggests setting a "triggering level" for an increase in block size, indicating an increase in transaction volume that would fill up blocks. The appropriate triggering level is difficult to determine and consists of three parameters: evaluation period, capacity, and threshold. A period of 4032 blocks was selected for the evaluation period, a capacity level of 60% was chosen, and a threshold of 2000 blocks or ~50% was selected. If 2000+ nodes have a block size >= 60%, this indicates a real increase in transaction volume, and a block size increase of 10% is triggered.The author of this proposal suggests a trigger level for an increase in the block size. This level is set at 60% full to reflect an underlying trend towards filling blocks. Determining the appropriate triggering level is difficult and consists of three parameters: evaluation period, capacity, and threshold. The author selected a period of 4032 blocks, a capacity level of 60%, and a threshold of 2000 blocks or ~50%. If 2000+ nodes have a block size >= 60%, this is an indication that real transaction volume has increased and we're approaching a time where block could be filled to capacity without an increase. The block size increase, 10%, is triggered.In a discussion around the proposal of a dynamic limit on the block size, Gavin Andresen and another individual's favorable stance was revealed. However, Corey Fields, a Bitcoin Core developer, stated that he was unclear on what problem(s) this proposal was trying to solve. Fields suggested implementing simple rules such as specifying a maximum block size based on the average block size over the last N blocks or implementing an absolute maximum block size that increases by a maximum of 3.45 times every year. He questioned the need for centralized decision-making in determining how full blocks "should" be and justifying why these specific growth limits were chosen.The author expresses their support for a technical approach to block scaling rather than a political one. They criticize BIP100 for giving too much power to miners and consider BIP101's attempt to predict technological progression in the future as flawed. The author suggests that a dynamic limit on block size would be favorable, but worries about the potential need for a hard fork in the future and the difficulty of upgrading embedded firmware. They propose a plan where the maximum block size decreases by 10% every 4032 blocks if a minimum of 2500 blocks has a size greater than the previous maximum block size. The author also identifies the risks of a selfish mining attack and suggests that unbounded growth is undesirable.The conversation is about the possibility of a selfish mining attack on the Bitcoin network. It is mentioned that such an attack would be possible but unlikely due to economic disincentives. However, one concern raised is the lack of a mechanism to lower the block size, which could make the network vulnerable to this type of attack. The proposal for a dynamic limit on the block size is discussed, with questions about what variables should be adjusted to make it more acceptable to Core developers like Gavin and Adam Back. In response, Adam Back clarifies that he was referring to the risk that excess block size could be used to amplify selfish mining instead of collecting transaction fees.According to Adam Back, a selfish mining attack could potentially be used to amplify the impact of excess block-size in a system that has no means to reduce it. In this scenario, an attacker with enough hashrate could take advantage of the free transaction space created by excess block-size and use it to perform a selfish mining attack. However, such an attack would have to be sustained for at least 2000 blocks over a period of 4 weeks in order to achieve a mere 10% increase in the block size.The maximum block size is one that can be filled at zero-cost by miners, which allows for some selfish-mining related attacks. A selfish mining attack would have to be performed for at least 2000 blocks over a period of 4 weeks to achieve a meager 10% increase in the block size. If the goal is to increase block size to push out smaller miners, they will have to perform this attack over the course of years and destroy any economic incentives they have for mining in the first place. However, if the goal is to simply drive up fees to gain acceptance into the block, nothing stops a miner from doing so. Developers cannot predict the appropriate block size for the next 20 years just as it is impossible to predict the appropriate hash rate to secure the network. Both need to adjust dynamically to the scale/adoption of the network. Miners already control block size through soft caps. The only reason for reducing the max block limit other than technology availability is if it is believed that this will produce the fee market, which is more of an economic discussion than a technology scaling discussion. If blocksize can only increase, then it's like a market that 2015-09-09T13:10:43+00:00 + The proposal suggests setting a "triggering level" for an increase in block size, indicating an increase in transaction volume that would fill up blocks. The appropriate triggering level is difficult to determine and consists of three parameters: evaluation period, capacity, and threshold. A period of 4032 blocks was selected for the evaluation period, a capacity level of 60% was chosen, and a threshold of 2000 blocks or ~50% was selected. If 2000+ nodes have a block size >= 60%, this indicates a real increase in transaction volume, and a block size increase of 10% is triggered.The author of this proposal suggests a trigger level for an increase in the block size. This level is set at 60% full to reflect an underlying trend towards filling blocks. Determining the appropriate triggering level is difficult and consists of three parameters: evaluation period, capacity, and threshold. The author selected a period of 4032 blocks, a capacity level of 60%, and a threshold of 2000 blocks or ~50%. If 2000+ nodes have a block size >= 60%, this is an indication that real transaction volume has increased and we're approaching a time where block could be filled to capacity without an increase. The block size increase, 10%, is triggered.In a discussion around the proposal of a dynamic limit on the block size, Gavin Andresen and another individual's favorable stance was revealed. However, Corey Fields, a Bitcoin Core developer, stated that he was unclear on what problem(s) this proposal was trying to solve. Fields suggested implementing simple rules such as specifying a maximum block size based on the average block size over the last N blocks or implementing an absolute maximum block size that increases by a maximum of 3.45 times every year. He questioned the need for centralized decision-making in determining how full blocks "should" be and justifying why these specific growth limits were chosen.The author expresses their support for a technical approach to block scaling rather than a political one. They criticize BIP100 for giving too much power to miners and consider BIP101's attempt to predict technological progression in the future as flawed. The author suggests that a dynamic limit on block size would be favorable, but worries about the potential need for a hard fork in the future and the difficulty of upgrading embedded firmware. They propose a plan where the maximum block size decreases by 10% every 4032 blocks if a minimum of 2500 blocks has a size greater than the previous maximum block size. The author also identifies the risks of a selfish mining attack and suggests that unbounded growth is undesirable.The conversation is about the possibility of a selfish mining attack on the Bitcoin network. It is mentioned that such an attack would be possible but unlikely due to economic disincentives. However, one concern raised is the lack of a mechanism to lower the block size, which could make the network vulnerable to this type of attack. The proposal for a dynamic limit on the block size is discussed, with questions about what variables should be adjusted to make it more acceptable to Core developers like Gavin and Adam Back. In response, Adam Back clarifies that he was referring to the risk that excess block size could be used to amplify selfish mining instead of collecting transaction fees.According to Adam Back, a selfish mining attack could potentially be used to amplify the impact of excess block-size in a system that has no means to reduce it. In this scenario, an attacker with enough hashrate could take advantage of the free transaction space created by excess block-size and use it to perform a selfish mining attack. However, such an attack would have to be sustained for at least 2000 blocks over a period of 4 weeks in order to achieve a mere 10% increase in the block size.The maximum block size is one that can be filled at zero-cost by miners, which allows for some selfish-mining related attacks. A selfish mining attack would have to be performed for at least 2000 blocks over a period of 4 weeks to achieve a meager 10% increase in the block size. If the goal is to increase block size to push out smaller miners, they will have to perform this attack over the course of years and destroy any economic incentives they have for mining in the first place. However, if the goal is to simply drive up fees to gain acceptance into the block, nothing stops a miner from doing so. Developers cannot predict the appropriate block size for the next 20 years just as it is impossible to predict the appropriate hash rate to secure the network. Both need to adjust dynamically to the scale/adoption of the network. Miners already control block size through soft caps. The only reason for reducing the max block limit other than technology availability is if it is believed that this will produce the fee market, which is more of an economic discussion than a technology scaling discussion. If blocksize can only increase, then it's like a market that - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_ERRATA-CORRIGE-Short-Theorem.xml b/static/bitcoin-dev/Sept_2015/combined_ERRATA-CORRIGE-Short-Theorem.xml index 239ca4c21b..523d3e6317 100644 --- a/static/bitcoin-dev/Sept_2015/combined_ERRATA-CORRIGE-Short-Theorem.xml +++ b/static/bitcoin-dev/Sept_2015/combined_ERRATA-CORRIGE-Short-Theorem.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - ERRATA CORRIGE + Short Theorem - 2023-08-01T15:52:27.236265+00:00 + 2025-10-11T21:54:17.850050+00:00 + python-feedgen Daniele Pinna 2015-09-01 08:52:46+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - ERRATA CORRIGE + Short Theorem - 2023-08-01T15:52:27.236265+00:00 + 2025-10-11T21:54:17.850199+00:00 - In an email exchange on the bitcoin-dev mailing list, Daniele Pinna clarified his previous assertions about the revenue per unit hash advantage for miners. He pointed out that while his paper showed a decrease in the advantage with the block reward, this does not necessarily mean that the real revenue per unit hash advantage also decreases. Pinna believes that the orphaning factor used in the calculations is incorrect or incomplete. Peter Todd agreed with Pinna's clarification and shared a link to his own math proof, which demonstrated that larger miners earn more money per unit hashing power.Peter Todd, a developer of the Bitcoin software, wrote an email in 2015 discussing his math proof that showed larger miners earn more money per unit hashing power. He provided a link to his proof and stated that he did not believe anyone was arguing otherwise. Another participant in the discussion, Dpinna, had claimed that his paper showed the advantage of larger miners decreased as the block reward diminished or total fees increased. Peter considered this claim reasonable but did not verify the math. The email exchange occurred on the bitcoin-dev mailing list.On August 30, 2015, Daniele Pinna posted a theorem on the bitcoin-dev mailing list. According to the theorem, all hashrates generate revenue per unit of hash, with larger hashrates generating more revenue. Pinna argued that an optimal hashrate exists where the average revenue for each hash in service is maximized. This balance stems from the fact that larger miners must mine larger blocks, which carry a higher orphan risk. If a large miner chooses to mine a seemingly "sub-optimal" block size identical to a smaller miner, they will both carry identical orphan risks and win identical amounts whenever they successfully mine a block. However, this contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash decreases. This theorem suggests that the marginal profit curve increases monotonically with miner hashrate. Peter Todd supported Pinna's argument by sharing a link to his own math proof, which also demonstrated that larger miners earn more money per unit hashing power. Todd disproved all conclusions of Pinna's work and emphasized that centralization pressures will always be present. The email exchange also includes a digital signature.In summary, the author presents a theorem stating that larger miners generate more revenue per unit of hash. This balance is due to the fact that larger miners must mine larger blocks, which carry a higher orphan risk. If a large miner chooses a seemingly "sub-optimal" block size identical to a smaller miner, they will earn the same revenue per unit of hash. This contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash decreases. The theorem implies that the marginal profit curve increases monotonically with miner hashrate. It disproves the author's conclusions and suggests that centralization pressures will always be present, as orphan risks favor larger hashrate miners leading to greater revenues per unit of hash. 2015-09-01T08:52:46+00:00 + In an email exchange on the bitcoin-dev mailing list, Daniele Pinna clarified his previous assertions about the revenue per unit hash advantage for miners. He pointed out that while his paper showed a decrease in the advantage with the block reward, this does not necessarily mean that the real revenue per unit hash advantage also decreases. Pinna believes that the orphaning factor used in the calculations is incorrect or incomplete. Peter Todd agreed with Pinna's clarification and shared a link to his own math proof, which demonstrated that larger miners earn more money per unit hashing power.Peter Todd, a developer of the Bitcoin software, wrote an email in 2015 discussing his math proof that showed larger miners earn more money per unit hashing power. He provided a link to his proof and stated that he did not believe anyone was arguing otherwise. Another participant in the discussion, Dpinna, had claimed that his paper showed the advantage of larger miners decreased as the block reward diminished or total fees increased. Peter considered this claim reasonable but did not verify the math. The email exchange occurred on the bitcoin-dev mailing list.On August 30, 2015, Daniele Pinna posted a theorem on the bitcoin-dev mailing list. According to the theorem, all hashrates generate revenue per unit of hash, with larger hashrates generating more revenue. Pinna argued that an optimal hashrate exists where the average revenue for each hash in service is maximized. This balance stems from the fact that larger miners must mine larger blocks, which carry a higher orphan risk. If a large miner chooses to mine a seemingly "sub-optimal" block size identical to a smaller miner, they will both carry identical orphan risks and win identical amounts whenever they successfully mine a block. However, this contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash decreases. This theorem suggests that the marginal profit curve increases monotonically with miner hashrate. Peter Todd supported Pinna's argument by sharing a link to his own math proof, which also demonstrated that larger miners earn more money per unit hashing power. Todd disproved all conclusions of Pinna's work and emphasized that centralization pressures will always be present. The email exchange also includes a digital signature.In summary, the author presents a theorem stating that larger miners generate more revenue per unit of hash. This balance is due to the fact that larger miners must mine larger blocks, which carry a higher orphan risk. If a large miner chooses a seemingly "sub-optimal" block size identical to a smaller miner, they will earn the same revenue per unit of hash. This contradicts the assumption that an optimal hashrate exists beyond which the revenue per unit of hash decreases. The theorem implies that the marginal profit curve increases monotonically with miner hashrate. It disproves the author's conclusions and suggests that centralization pressures will always be present, as orphan risks favor larger hashrate miners leading to greater revenues per unit of hash. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Fill-or-kill-transaction.xml b/static/bitcoin-dev/Sept_2015/combined_Fill-or-kill-transaction.xml index f5df350b59..db24885527 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Fill-or-kill-transaction.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Fill-or-kill-transaction.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Fill-or-kill transaction - 2023-08-01T16:11:01.346247+00:00 + 2025-10-11T21:55:15.190918+00:00 + python-feedgen Jorge Timón 2015-09-22 17:45:00+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Fill-or-kill transaction - 2023-08-01T16:11:01.346247+00:00 + 2025-10-11T21:55:15.191085+00:00 - The discussions surrounding the implementation of a "fill-or-kill" system in Bitcoin transactions revolve around finding a consensus on how to ensure transaction safety, validity, and ease of use. One proposal suggests requiring OP_MATURITY 100 in all scriptPubKeys of the expiry transaction to make them as reorg-safe as coinbase transactions, but this may not work well with p2sh. Another proposal is to implement a "treat like Coinbase" flag in the UTXO set when creating the output. Some developers argue for using accurate terminology, such as nExpiryTime instead of fill or kill, to facilitate learning and understanding.There is also a discussion about the maturity requirement for these transactions. Dropping the 100 block maturity requirement could resolve delays in receiving funds, making the system more appealing to recipients. However, another developer points out that this would not make the transactions as safe as mined bitcoins, which have additional requirements and costs.In terms of implementation, suggestions include repurposing a small range of nLockTime or adding a new nKillTime field to the transaction. However, the latter would require a hardfork. Other alternatives discussed involve embedding nKillTime data within other unused fields or utilizing per-input nKillTime and nLockTime with nSequence.A fill-or-kill system can be implemented by utilizing the unused range in Satoshi's implementation of nLockTime. This involves introducing two new parameters, nLockTime2 and nKillTime, which determine the functionality of the system. The resolution for this system is four blocks or 2048 seconds, with a maximum confirmation window of 8188 blocks or 16,769,024 seconds. Activation of the system is achieved by setting a bit flag in the transaction nVersion.It should be noted that the growth of nLockTime will never catch up with nLockTime2. For height-based nLockTime2, the lock time with the new rule must be 1-2048 seconds later than the original rule for every nLockTime2 value greater than or equal to 720,000, resulting in a soft fork. Similarly, for time-based nLockTime2, confirmation is not allowed until a specific median time-past, also requiring a soft fork.To customize transaction confirmation times, users can set their desired values for nLockTime2 and nKillTime. However, compatibility issues arise with height-based OP_CLTV, necessitating the creation of a new OP_CLTV2 to verify both nLockTime and nLockTime2.The height-based nLockTime2 will eventually overflow in 55 years, which would require a hard fork to implement a more effective fill-or-kill system. Alternatively, if a hard fork does not occur, a new tx nVersion could be used to restart the system for another 55 years.In summary, a fill-or-kill system can be established by leveraging the unused range in Satoshi's nLockTime implementation through the use of nLockTime2 and nKillTime parameters. However, compatibility issues arise with height-based OP_CLTV, necessitating the creation of a new OP_CLTV2. Additionally, the height-based nLockTime2 will eventually overflow, potentially leading to a necessary hard fork for system improvement. 2015-09-22T17:45:00+00:00 + The discussions surrounding the implementation of a "fill-or-kill" system in Bitcoin transactions revolve around finding a consensus on how to ensure transaction safety, validity, and ease of use. One proposal suggests requiring OP_MATURITY 100 in all scriptPubKeys of the expiry transaction to make them as reorg-safe as coinbase transactions, but this may not work well with p2sh. Another proposal is to implement a "treat like Coinbase" flag in the UTXO set when creating the output. Some developers argue for using accurate terminology, such as nExpiryTime instead of fill or kill, to facilitate learning and understanding.There is also a discussion about the maturity requirement for these transactions. Dropping the 100 block maturity requirement could resolve delays in receiving funds, making the system more appealing to recipients. However, another developer points out that this would not make the transactions as safe as mined bitcoins, which have additional requirements and costs.In terms of implementation, suggestions include repurposing a small range of nLockTime or adding a new nKillTime field to the transaction. However, the latter would require a hardfork. Other alternatives discussed involve embedding nKillTime data within other unused fields or utilizing per-input nKillTime and nLockTime with nSequence.A fill-or-kill system can be implemented by utilizing the unused range in Satoshi's implementation of nLockTime. This involves introducing two new parameters, nLockTime2 and nKillTime, which determine the functionality of the system. The resolution for this system is four blocks or 2048 seconds, with a maximum confirmation window of 8188 blocks or 16,769,024 seconds. Activation of the system is achieved by setting a bit flag in the transaction nVersion.It should be noted that the growth of nLockTime will never catch up with nLockTime2. For height-based nLockTime2, the lock time with the new rule must be 1-2048 seconds later than the original rule for every nLockTime2 value greater than or equal to 720,000, resulting in a soft fork. Similarly, for time-based nLockTime2, confirmation is not allowed until a specific median time-past, also requiring a soft fork.To customize transaction confirmation times, users can set their desired values for nLockTime2 and nKillTime. However, compatibility issues arise with height-based OP_CLTV, necessitating the creation of a new OP_CLTV2 to verify both nLockTime and nLockTime2.The height-based nLockTime2 will eventually overflow in 55 years, which would require a hard fork to implement a more effective fill-or-kill system. Alternatively, if a hard fork does not occur, a new tx nVersion could be used to restart the system for another 55 years.In summary, a fill-or-kill system can be established by leveraging the unused range in Satoshi's nLockTime implementation through the use of nLockTime2 and nKillTime parameters. However, compatibility issues arise with height-based OP_CLTV, necessitating the creation of a new OP_CLTV2. Additionally, the height-based nLockTime2 will eventually overflow, potentially leading to a necessary hard fork for system improvement. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Hash-of-UTXO-set-as-consensus-critical.xml b/static/bitcoin-dev/Sept_2015/combined_Hash-of-UTXO-set-as-consensus-critical.xml index 8110f2c386..d9d0ece8ec 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Hash-of-UTXO-set-as-consensus-critical.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Hash-of-UTXO-set-as-consensus-critical.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Hash of UTXO set as consensus-critical - 2023-08-01T16:13:07.536002+00:00 + 2025-10-11T21:55:25.810890+00:00 + python-feedgen Justus Ranvier 2015-09-21 17:15:12+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - Hash of UTXO set as consensus-critical - 2023-08-01T16:13:07.536002+00:00 + 2025-10-11T21:55:25.811051+00:00 - In an email conversation, Justus Ranvier raised several questions regarding the definition of honest and malicious miners, as well as the concept of the "best valid chain." He questioned whether extending the chain with an empty block is always a malicious act and whether a miner with 49% hashing power would be considered honest for doing the same. There were blind spots in distinguishing between honest and malicious blocks, and it was suggested that empty blocks indicate malice while rebroadcasted transactions from the mempool indicate honesty. The inability to distinguish between these blocks is a significant issue that needs to be addressed.A 51% attack occurs when the majority of mining power is controlled by malicious miners who can mine empty blocks on top of the best chain. Bitcoin relies on the majority of mining power being honest to function effectively. However, if a fork exists due to a disagreement in the network where mining power is split between two camps, each mining peacefully on their own chain, it is not problematic. Miners mining invalid blocks are no longer relevant to the Bitcoin consensus. Light clients face challenges in distinguishing between valid and invalid chains, but simple proofs could potentially solve this problem.Rune Kjær Svendsen proposed including UTXO set hashes in newly created blocks to allow new nodes to verify new transactions without retrieving the entire blockchain history. This would save bandwidth and ease the initial syncing process for Bitcoin Core nodes. While there are concerns about the security implications of relying on UTXO set commitments, Svendsen argues that it would not reduce the protocol's security.The discussions also touched on the scalability issues of validating the full blockchain history and ways to alleviate this burden for new nodes joining the network. One proposal suggests hashing the UTXO set and storing it on disk, along with a copy of the UTXO set at that time. This would increase the difficulty for an attacker with hidden hashing power to overwrite a year's worth of blocks. However, there are concerns that an attacker with over 50% of the network hashrate could rewrite history. Before considering mechanisms for UTXO set commitments, it is crucial to discuss the reasonableness of reducing the security model.Overall, the discussions highlighted the need to address the distinction between honest and malicious miners, the ability to distinguish between different types of blocks, the inclusion of UTXO set hashes in newly created blocks, and the potential implications for Bitcoin's security model. Patrick Strateman questioned the proposal to use UTXO set commitments, as it may reduce the current security model by allowing an attacker with more than 50% of the network hashrate to create an unlimited number of bitcoins. However, Svendsen suggested a solution where newly mined blocks include the UTXO set hash of the chain up until the previous block, which would save bandwidth and allow new nodes to acquire the UTXO set in a trustless manner. This approach maintains Bitcoin's security model while easing the initial syncing process for nodes. 2015-09-21T17:15:12+00:00 + In an email conversation, Justus Ranvier raised several questions regarding the definition of honest and malicious miners, as well as the concept of the "best valid chain." He questioned whether extending the chain with an empty block is always a malicious act and whether a miner with 49% hashing power would be considered honest for doing the same. There were blind spots in distinguishing between honest and malicious blocks, and it was suggested that empty blocks indicate malice while rebroadcasted transactions from the mempool indicate honesty. The inability to distinguish between these blocks is a significant issue that needs to be addressed.A 51% attack occurs when the majority of mining power is controlled by malicious miners who can mine empty blocks on top of the best chain. Bitcoin relies on the majority of mining power being honest to function effectively. However, if a fork exists due to a disagreement in the network where mining power is split between two camps, each mining peacefully on their own chain, it is not problematic. Miners mining invalid blocks are no longer relevant to the Bitcoin consensus. Light clients face challenges in distinguishing between valid and invalid chains, but simple proofs could potentially solve this problem.Rune Kjær Svendsen proposed including UTXO set hashes in newly created blocks to allow new nodes to verify new transactions without retrieving the entire blockchain history. This would save bandwidth and ease the initial syncing process for Bitcoin Core nodes. While there are concerns about the security implications of relying on UTXO set commitments, Svendsen argues that it would not reduce the protocol's security.The discussions also touched on the scalability issues of validating the full blockchain history and ways to alleviate this burden for new nodes joining the network. One proposal suggests hashing the UTXO set and storing it on disk, along with a copy of the UTXO set at that time. This would increase the difficulty for an attacker with hidden hashing power to overwrite a year's worth of blocks. However, there are concerns that an attacker with over 50% of the network hashrate could rewrite history. Before considering mechanisms for UTXO set commitments, it is crucial to discuss the reasonableness of reducing the security model.Overall, the discussions highlighted the need to address the distinction between honest and malicious miners, the ability to distinguish between different types of blocks, the inclusion of UTXO set hashes in newly created blocks, and the potential implications for Bitcoin's security model. Patrick Strateman questioned the proposal to use UTXO set commitments, as it may reduce the current security model by allowing an attacker with more than 50% of the network hashrate to create an unlimited number of bitcoins. However, Svendsen suggested a solution where newly mined blocks include the UTXO set hash of the chain up until the previous block, which would save bandwidth and allow new nodes to acquire the UTXO set in a trustless manner. This approach maintains Bitcoin's security model while easing the initial syncing process for nodes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Improving-Blocksize-Communication-Through-Markets.xml b/static/bitcoin-dev/Sept_2015/combined_Improving-Blocksize-Communication-Through-Markets.xml index 6e377bea88..3350189837 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Improving-Blocksize-Communication-Through-Markets.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Improving-Blocksize-Communication-Through-Markets.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Improving Blocksize Communication Through Markets - 2023-08-01T16:13:17.885193+00:00 + 2025-10-11T21:55:44.927549+00:00 + python-feedgen Isidor Zeuner 2015-09-20 11:41:52+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - Improving Blocksize Communication Through Markets - 2023-08-01T16:13:17.885193+00:00 + 2025-10-11T21:55:44.927701+00:00 - Isidor is questioning the need for another side-chain to address the Bitcoin block size issue. He argues that the market can already determine the acceptance of Bitcoins based on the client versions of blocks they come from, allowing the market to rectify any discrepancies. Isidor believes that holding a conference in Montreal to solve a global issue like this centralizes Bitcoin. To learn more about the project and its technical details, Isidor directs readers to the project page and GitHub README.The author of an email wonders if people are tired of hearing about block size issues and suggests it's time to move on from these discussions. They propose that while scalability is important, other features should be discussed instead. The author also questions the amount of money spent on conferences and proposes a more direct way of accessing information.The author introduces their solution to improving the discussion around block size issues and references a method advocated by Hal Finney seven years ago. This solution has already been coded into the author's own project, Truthcoin. However, they invite competent C++ developers to have a 30-minute conversation with them and potentially complete the coding in just one weekend.For more details about the project, including information on the Bitcoin Block Size website and technical specifics available on GitHub, readers can refer to the provided links. Additionally, the author has created a Slack channel for further discussions on the topic. 2015-09-20T11:41:52+00:00 + Isidor is questioning the need for another side-chain to address the Bitcoin block size issue. He argues that the market can already determine the acceptance of Bitcoins based on the client versions of blocks they come from, allowing the market to rectify any discrepancies. Isidor believes that holding a conference in Montreal to solve a global issue like this centralizes Bitcoin. To learn more about the project and its technical details, Isidor directs readers to the project page and GitHub README.The author of an email wonders if people are tired of hearing about block size issues and suggests it's time to move on from these discussions. They propose that while scalability is important, other features should be discussed instead. The author also questions the amount of money spent on conferences and proposes a more direct way of accessing information.The author introduces their solution to improving the discussion around block size issues and references a method advocated by Hal Finney seven years ago. This solution has already been coded into the author's own project, Truthcoin. However, they invite competent C++ developers to have a 30-minute conversation with them and potentially complete the coding in just one weekend.For more details about the project, including information on the Bitcoin Block Size website and technical specifics available on GitHub, readers can refer to the provided links. Additionally, the author has created a Slack channel for further discussions on the topic. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Instant-exchange-rates-URI-scheme.xml b/static/bitcoin-dev/Sept_2015/combined_Instant-exchange-rates-URI-scheme.xml index 0dc444d617..d49bc2ed97 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Instant-exchange-rates-URI-scheme.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Instant-exchange-rates-URI-scheme.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Instant exchange rates URI scheme - 2023-08-01T16:08:27.224305+00:00 + 2025-10-11T21:55:38.556986+00:00 + python-feedgen John Bailon 2015-09-15 15:02:57+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Instant exchange rates URI scheme - 2023-08-01T16:08:27.224305+00:00 + 2025-10-11T21:55:38.557158+00:00 - A proposal has been made for a Bitcoin Improvement Proposal (BIP) to create a standard URI scheme that would enable wallet operators to implement instant exchange or pegging to other currencies, cryptocurrencies, or asset classes. The proposal suggests including parameters in the wallet address that would provide supplementary information for a proposed transaction. For example, a wallet operator that instantly exchanges bitcoin to gold could present a wallet address with encoded parameters such as currency, rate, and timestamp of when the rate loses validity.This proposal aims to allow wallet operators to communicate with each other and abstract bitcoin rates from end users. By including relevant information in the wallet address, such as the currency, rate, and expiration date, the sending wallet can present up-to-date exchange rates to the user. This would benefit end users of instant exchange wallets by providing them with accurate and timely information.To illustrate how this would work, consider a scenario where Alice wants to send JPY 10,000 to Bob, who has a JPY pegged wallet. Alice's wallet can scan Bob's wallet and retrieve information such as Bob's BTC address, Bob's wallet currency, and the price of BTC. With this information, Alice's wallet can calculate the amount of BTC she needs to send to Bob to complete the transaction. Additionally, Alice's wallet can also show the equivalent amount in USD, which is the amount she needs to pay to Bob's wallet.The proposal suggests using the bitcoin address as an example, but the concept can be applied to other currencies, cryptocurrencies, or asset classes. By implementing this standard URI scheme, wallet operators can ensure interoperable communication of rates and other pertinent information. This would simplify the process for users and provide a seamless experience when using instant exchange or pegging services.In summary, the proposal suggests a BIP for a standard URI scheme that allows wallet operators to implement instant exchange or pegging to other currencies, cryptocurrencies, or asset classes. By including parameters in the wallet address, such as currency, rate, and expiration date, wallet operators can provide up-to-date exchange rates to users. This proposal aims to benefit end users of instant exchange wallets and enable wallet operators to communicate with each other effectively. 2015-09-15T15:02:57+00:00 + A proposal has been made for a Bitcoin Improvement Proposal (BIP) to create a standard URI scheme that would enable wallet operators to implement instant exchange or pegging to other currencies, cryptocurrencies, or asset classes. The proposal suggests including parameters in the wallet address that would provide supplementary information for a proposed transaction. For example, a wallet operator that instantly exchanges bitcoin to gold could present a wallet address with encoded parameters such as currency, rate, and timestamp of when the rate loses validity.This proposal aims to allow wallet operators to communicate with each other and abstract bitcoin rates from end users. By including relevant information in the wallet address, such as the currency, rate, and expiration date, the sending wallet can present up-to-date exchange rates to the user. This would benefit end users of instant exchange wallets by providing them with accurate and timely information.To illustrate how this would work, consider a scenario where Alice wants to send JPY 10,000 to Bob, who has a JPY pegged wallet. Alice's wallet can scan Bob's wallet and retrieve information such as Bob's BTC address, Bob's wallet currency, and the price of BTC. With this information, Alice's wallet can calculate the amount of BTC she needs to send to Bob to complete the transaction. Additionally, Alice's wallet can also show the equivalent amount in USD, which is the amount she needs to pay to Bob's wallet.The proposal suggests using the bitcoin address as an example, but the concept can be applied to other currencies, cryptocurrencies, or asset classes. By implementing this standard URI scheme, wallet operators can ensure interoperable communication of rates and other pertinent information. This would simplify the process for users and provide a seamless experience when using instant exchange or pegging services.In summary, the proposal suggests a BIP for a standard URI scheme that allows wallet operators to implement instant exchange or pegging to other currencies, cryptocurrencies, or asset classes. By including parameters in the wallet address, such as currency, rate, and expiration date, wallet operators can provide up-to-date exchange rates to users. This proposal aims to benefit end users of instant exchange wallets and enable wallet operators to communicate with each other effectively. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Is-it-possible-for-there-to-be-two-chains-after-a-hard-fork-.xml b/static/bitcoin-dev/Sept_2015/combined_Is-it-possible-for-there-to-be-two-chains-after-a-hard-fork-.xml index b18f2e96fe..681947c850 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Is-it-possible-for-there-to-be-two-chains-after-a-hard-fork-.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Is-it-possible-for-there-to-be-two-chains-after-a-hard-fork-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Is it possible for there to be two chains after a hard fork? - 2023-08-01T16:25:20.438095+00:00 + 2025-10-11T21:55:51.300453+00:00 + python-feedgen Jorge Timón 2015-09-30 16:14:42+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - Is it possible for there to be two chains after a hard fork? - 2023-08-01T16:25:20.438095+00:00 + 2025-10-11T21:55:51.300630+00:00 - The discussion on the mailing list focuses on the incorrect belief that users must follow the hashrate majority in Bitcoin. It is argued that market forces dictate that hashrates will follow users instead. If users are unhappy with hardfork rules, they may choose not to upgrade, leading to a split between two chains. Speculators may sell both A-coins and B-coins during this period of uncertainty. Miners can continue mining old coins as long as there is demand for them, even if the new rules chain has a majority of users and miners. The discussion about these issues should take place on Github or the bitcoin-dev thread linked from the BIP.Gavin Andresen initiated a thread discussing the possibility of two chains persisting after a hard fork. He expressed confusion and requested clarification on the matter. Allen Piscitello responded by stating that mining empty blocks is not considered fraud and asked for clear definitions of terms like "honest miner" and "fraud." Mike Hearn added to the discussion, pointing out that running a full node does not protect against a dishonest miner majority committing fraud, which is mentioned in the Bitcoin white paper. Andresen suggested moving the discussion to a more general list and emphasized the importance of miners following the rules of the protocol.The debate revolves around the concept of honest miners and fraud in Bitcoin mining. It is highlighted that the security assumption of Bitcoin is based on a supermajority of miners being honest. However, it is also acknowledged that miners are not infallible and may make misjudgments or change their decisions based on new information. The discussion emphasizes that relying on miners' honesty is necessary even if one runs a full node. Instances of accidental consensus forks are cited as evidence of miners' economic rationality and desire for Bitcoin's success.The discussion also touches on the feasibility of hard forks in the Bitcoin network. It is noted that at a threshold of 75%, it only takes 25.01% of hashpower to report but not enforce the fork, which can cause the majority hashpower to remain on the old chain. However, for upgraded clients to reject the old chain, the threshold needs to be at 95%. The potential risks and challenges associated with hard forks are highlighted, including the possibility of significant loss in value and transaction backlog for the smaller fork.In conclusion, the ongoing discussion addresses various aspects related to the security assumption of Bitcoin, the concept of honest miners, the possibility of hard forks, and the potential implications of splits in the Bitcoin network. It underscores the importance of understanding these issues and engaging in informed discussions to ensure the stability and integrity of the cryptocurrency. 2015-09-30T16:14:42+00:00 + The discussion on the mailing list focuses on the incorrect belief that users must follow the hashrate majority in Bitcoin. It is argued that market forces dictate that hashrates will follow users instead. If users are unhappy with hardfork rules, they may choose not to upgrade, leading to a split between two chains. Speculators may sell both A-coins and B-coins during this period of uncertainty. Miners can continue mining old coins as long as there is demand for them, even if the new rules chain has a majority of users and miners. The discussion about these issues should take place on Github or the bitcoin-dev thread linked from the BIP.Gavin Andresen initiated a thread discussing the possibility of two chains persisting after a hard fork. He expressed confusion and requested clarification on the matter. Allen Piscitello responded by stating that mining empty blocks is not considered fraud and asked for clear definitions of terms like "honest miner" and "fraud." Mike Hearn added to the discussion, pointing out that running a full node does not protect against a dishonest miner majority committing fraud, which is mentioned in the Bitcoin white paper. Andresen suggested moving the discussion to a more general list and emphasized the importance of miners following the rules of the protocol.The debate revolves around the concept of honest miners and fraud in Bitcoin mining. It is highlighted that the security assumption of Bitcoin is based on a supermajority of miners being honest. However, it is also acknowledged that miners are not infallible and may make misjudgments or change their decisions based on new information. The discussion emphasizes that relying on miners' honesty is necessary even if one runs a full node. Instances of accidental consensus forks are cited as evidence of miners' economic rationality and desire for Bitcoin's success.The discussion also touches on the feasibility of hard forks in the Bitcoin network. It is noted that at a threshold of 75%, it only takes 25.01% of hashpower to report but not enforce the fork, which can cause the majority hashpower to remain on the old chain. However, for upgraded clients to reject the old chain, the threshold needs to be at 95%. The potential risks and challenges associated with hard forks are highlighted, including the possibility of significant loss in value and transaction backlog for the smaller fork.In conclusion, the ongoing discussion addresses various aspects related to the security assumption of Bitcoin, the concept of honest miners, the possibility of hard forks, and the potential implications of splits in the Bitcoin network. It underscores the importance of understanding these issues and engaging in informed discussions to ensure the stability and integrity of the cryptocurrency. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml b/static/bitcoin-dev/Sept_2015/combined_Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml index 37fee73343..b954bf5a34 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Let-s-deploy-BIP65-CHECKLOCKTIMEVERIFY-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Let's deploy BIP65 CHECKLOCKTIMEVERIFY! - 2023-08-01T16:21:21.415012+00:00 + 2025-10-11T21:54:53.939617+00:00 + python-feedgen digitsu at gmail.com 2015-10-13 00:08:49+00:00 @@ -375,13 +376,13 @@ - python-feedgen + 2 Combined summary - Let's deploy BIP65 CHECKLOCKTIMEVERIFY! - 2023-08-01T16:21:21.416010+00:00 + 2025-10-11T21:54:53.939972+00:00 - The email thread discusses the potential risks associated with a soft fork in the Bitcoin network. The effectiveness of an attack depends on the percentage of hash power that did not upgrade. Even with just 5% hash power and ~30% of nodes running the old version, a "damaging soft fork" still poses a high risk to someone receiving payments via an SPV client. The original emailer questions the significance of the risks posed by such an attack, as executing a double spend maliciously would be difficult due to the unpredictability of when a block would occur.There is a proposal to introduce a new flag in Core, called --scriptchecks=[all,standardonly,none], which would prioritize correctness by default and allow nodes to opt into pseudo-SPV behavior of a soft fork if desired. The advantages and disadvantages of hard forks and soft forks are discussed, with some arguing for a hard fork to avoid problems with SPV wallets during the rollout period. However, others believe that soft forks have a demonstrated track record of delivering new features with minimal problems.The deployment of BIP65 CHECKLOCKTIMEVERIFY in Bitcoin is also discussed. Mike Hearn expresses concerns about using a soft fork to implement this feature, suggesting that it should be a hard fork instead. Other participants emphasize the need for consensus before making any decisions. The conversation delves into the issues of miner adoption, the vulnerability of a soft fork, and the potential for double-spending attacks.The discussion highlights the complexities and trade-offs involved in implementing changes to the Bitcoin network, particularly in the context of soft forks and hard forks. The importance of upgrading full nodes and the risks associated with not doing so are emphasized. The conversations also touch on topics such as SPV wallets, the implementation of P2SH, and the advantages of communication and mitigation strategies.Overall, the discussions provide insights into different perspectives on the deployment of BIP65 CHECKLOCKTIMEVERIFY, the advantages and risks of soft forks versus hard forks, and the challenges faced in implementing changes in Bitcoin software. The email exchanges between Bitcoin developers touch on various topics related to upgrading Bitcoin software, the concept of consensus, and potential risks and solutions for SPV clients during soft forks. In addition, there are references to other email exchanges discussing topics such as the definition of a "working" full node, the risks and benefits of soft forks and hard forks, and the implications for SPV clients. The discussions highlight the need for refinement and adjustment of proposed changes, as well as the importance of developer consensus in the Bitcoin community.In a bitcoin-dev mailing list, Peter Todd expressed concerns about the delay in deploying CheckLockTimeVerify (CLTV) due to waiting for nVersion bits and CHECKSEQUENCEVERIFY. He suggested rolling out CLTV+CSV (CheckSequenceVerify) together by the 0.12 release if possible. However, if CSV is not ready, they would proceed with CLTV alone. The related pull requests for CSV are now ready for final review, and if that happens soon, CLTV+CSV would be rolled out together before 0.12.On September 27th, 2015, in an email exchange, a user named jl2012 expressed support for the deployment of BIP65 (CLTV) and asked about the possibility of backporting it to version 0.9. Peter Todd stated that he could backport it to 0.9 but wanted to hear from miners as to why they were still on v0.9.x.There was agreement with Peter's points, stating that BIP65 should be deployed immediately instead of waiting for the 0.12 schedule, as it would take too long. Some mining pools hinted at adopting BitcoinXT by the end of 2015, and earlier deployment of BIP65 would provide them with a patched version ready when they switch. Gavin also agreed to support BIP65 in XT. There was a question about backporting BIP65 to 0.9, similar to what happened during the deployment of BIP66.Peter Todd argued that CLTV should be deployed on v0.10.3 and IsSuperMajority() soft-fork on v0.11.1. He highlighted the benefits of CLTV for payment channels, making implementations simpler and more secure by removing malleability vulnerability. Todd emphasized that the implementation of the opcode has been peer-reviewed and thoroughly tested, and the deployment code has been copied from the successful BIP66. He believed that the risk of CLTV failing to get miner adoption is low and waiting for nVersion bits and CHECKSEQUENCEVERIFY would significantly delay deployment.Overall, the emails discuss various perspectives on the addition of CLTV to the Bitcoin protocol, the use of soft forks versus hard forks, and the concerns and solutions related to SPV wallets and node preparation for the upcoming soft fork. Peter Todd advocated for the deployment of CLTV and IsSuperMajority() soft-f 2015-10-13T00:08:49+00:00 + The email thread discusses the potential risks associated with a soft fork in the Bitcoin network. The effectiveness of an attack depends on the percentage of hash power that did not upgrade. Even with just 5% hash power and ~30% of nodes running the old version, a "damaging soft fork" still poses a high risk to someone receiving payments via an SPV client. The original emailer questions the significance of the risks posed by such an attack, as executing a double spend maliciously would be difficult due to the unpredictability of when a block would occur.There is a proposal to introduce a new flag in Core, called --scriptchecks=[all,standardonly,none], which would prioritize correctness by default and allow nodes to opt into pseudo-SPV behavior of a soft fork if desired. The advantages and disadvantages of hard forks and soft forks are discussed, with some arguing for a hard fork to avoid problems with SPV wallets during the rollout period. However, others believe that soft forks have a demonstrated track record of delivering new features with minimal problems.The deployment of BIP65 CHECKLOCKTIMEVERIFY in Bitcoin is also discussed. Mike Hearn expresses concerns about using a soft fork to implement this feature, suggesting that it should be a hard fork instead. Other participants emphasize the need for consensus before making any decisions. The conversation delves into the issues of miner adoption, the vulnerability of a soft fork, and the potential for double-spending attacks.The discussion highlights the complexities and trade-offs involved in implementing changes to the Bitcoin network, particularly in the context of soft forks and hard forks. The importance of upgrading full nodes and the risks associated with not doing so are emphasized. The conversations also touch on topics such as SPV wallets, the implementation of P2SH, and the advantages of communication and mitigation strategies.Overall, the discussions provide insights into different perspectives on the deployment of BIP65 CHECKLOCKTIMEVERIFY, the advantages and risks of soft forks versus hard forks, and the challenges faced in implementing changes in Bitcoin software. The email exchanges between Bitcoin developers touch on various topics related to upgrading Bitcoin software, the concept of consensus, and potential risks and solutions for SPV clients during soft forks. In addition, there are references to other email exchanges discussing topics such as the definition of a "working" full node, the risks and benefits of soft forks and hard forks, and the implications for SPV clients. The discussions highlight the need for refinement and adjustment of proposed changes, as well as the importance of developer consensus in the Bitcoin community.In a bitcoin-dev mailing list, Peter Todd expressed concerns about the delay in deploying CheckLockTimeVerify (CLTV) due to waiting for nVersion bits and CHECKSEQUENCEVERIFY. He suggested rolling out CLTV+CSV (CheckSequenceVerify) together by the 0.12 release if possible. However, if CSV is not ready, they would proceed with CLTV alone. The related pull requests for CSV are now ready for final review, and if that happens soon, CLTV+CSV would be rolled out together before 0.12.On September 27th, 2015, in an email exchange, a user named jl2012 expressed support for the deployment of BIP65 (CLTV) and asked about the possibility of backporting it to version 0.9. Peter Todd stated that he could backport it to 0.9 but wanted to hear from miners as to why they were still on v0.9.x.There was agreement with Peter's points, stating that BIP65 should be deployed immediately instead of waiting for the 0.12 schedule, as it would take too long. Some mining pools hinted at adopting BitcoinXT by the end of 2015, and earlier deployment of BIP65 would provide them with a patched version ready when they switch. Gavin also agreed to support BIP65 in XT. There was a question about backporting BIP65 to 0.9, similar to what happened during the deployment of BIP66.Peter Todd argued that CLTV should be deployed on v0.10.3 and IsSuperMajority() soft-fork on v0.11.1. He highlighted the benefits of CLTV for payment channels, making implementations simpler and more secure by removing malleability vulnerability. Todd emphasized that the implementation of the opcode has been peer-reviewed and thoroughly tested, and the deployment code has been copied from the successful BIP66. He believed that the risk of CLTV failing to get miner adoption is low and waiting for nVersion bits and CHECKSEQUENCEVERIFY would significantly delay deployment.Overall, the emails discuss various perspectives on the addition of CLTV to the Bitcoin protocol, the use of soft forks versus hard forks, and the concerns and solutions related to SPV wallets and node preparation for the upcoming soft fork. Peter Todd advocated for the deployment of CLTV and IsSuperMajority() soft-f - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Let-s-kill-Bitcoin-Core-and-allow-the-green-shoots-of-a-garden-of-new-implementations-to-grow-from-its-fertile-ashes.xml b/static/bitcoin-dev/Sept_2015/combined_Let-s-kill-Bitcoin-Core-and-allow-the-green-shoots-of-a-garden-of-new-implementations-to-grow-from-its-fertile-ashes.xml index 59119b517d..9f21ff84f5 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Let-s-kill-Bitcoin-Core-and-allow-the-green-shoots-of-a-garden-of-new-implementations-to-grow-from-its-fertile-ashes.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Let-s-kill-Bitcoin-Core-and-allow-the-green-shoots-of-a-garden-of-new-implementations-to-grow-from-its-fertile-ashes.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes - 2023-08-01T15:53:58.792916+00:00 + 2025-10-11T21:54:15.726964+00:00 + python-feedgen s7r 2015-09-01 22:06:35+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes - 2023-08-01T15:53:58.793915+00:00 + 2025-10-11T21:54:15.727102+00:00 - The discussion revolves around the idea of creating multiple implementations for Bitcoin Core, emphasizing the need to carefully balance gains and risks. Centralized mining is seen as a bigger problem than full nodes running Bitcoin Core software. Peter R suggests the creation of multiple implementations, similar to Bitcoin XT, with each group incentivized to remain compatible with other implementations. This would allow for creative destruction and prevent consensus with Bitcoin Core.Wladimir, the lead developer of Bitcoin Core, suggests that experiments should be done on sidechains or altcoins instead of forking the Bitcoin chain. He argues that forking would unnecessarily complicate matters, especially if multiple forks gained their own users. He clarifies that alternative implementations like btcd and obelisk are not the same as deliberate rule changes seen in Bitcoin XT.Chris D'Costa agrees that experimenting with the Bitcoin network on the live network or testnet would not be appropriate. He suggests creating a Bitcoin fork for unrestricted experimentation, similar to sidechains, which could provide valuable insights for future Core updates. Elements Alpha is mentioned as a technical sandbox for such experimentation.Peter R suggests an unstable Bitcoin fork allowing for experimentation, different from an altcoin. However, the lack of incentive poses a problem. Adam Back disagrees, stating that incompatible versions of consensus code competing on the network would not work. He encourages analyzing and validating proposals through testing and proposing well-validated upgrade mechanisms.The email thread discusses the risks of upgrading Bitcoin's consensus code and emphasizes the importance of everyone upgrading to the same consensus rule change. It proposes creating multiple implementations of Bitcoin Core with different scaling solutions, but discourages encouraging nodes or miners to "vote" by running different consensus rules, as it can create compatibility issues and politicize the topic.In an email conversation, Peter R inquires about Bitcoin-B associated with Blockstream. Blockstream responds that they have no interest in maintaining a separate implementation of Bitcoin at this time, as it would have negative value. Confusion arises between alternative implementations and the destructive bifurcation of the Bitcoin ledger.Creating multiple implementations would involve forking Bitcoin Core, with each group integrating innovation from other groups if desired. The idea of never reaching consensus with Bitcoin Core is suggested to encourage new implementations to fork and implement their preferred scaling solution. Users would select the winning solution based on the code they choose to run, promoting the decentralized spirit of Bitcoin. Decentralization in development is discussed to reduce dependency on Core, but convincing users to adopt new implementations poses a challenge due to the quality and popularity of Bitcoin Core. 2015-09-01T22:06:35+00:00 + The discussion revolves around the idea of creating multiple implementations for Bitcoin Core, emphasizing the need to carefully balance gains and risks. Centralized mining is seen as a bigger problem than full nodes running Bitcoin Core software. Peter R suggests the creation of multiple implementations, similar to Bitcoin XT, with each group incentivized to remain compatible with other implementations. This would allow for creative destruction and prevent consensus with Bitcoin Core.Wladimir, the lead developer of Bitcoin Core, suggests that experiments should be done on sidechains or altcoins instead of forking the Bitcoin chain. He argues that forking would unnecessarily complicate matters, especially if multiple forks gained their own users. He clarifies that alternative implementations like btcd and obelisk are not the same as deliberate rule changes seen in Bitcoin XT.Chris D'Costa agrees that experimenting with the Bitcoin network on the live network or testnet would not be appropriate. He suggests creating a Bitcoin fork for unrestricted experimentation, similar to sidechains, which could provide valuable insights for future Core updates. Elements Alpha is mentioned as a technical sandbox for such experimentation.Peter R suggests an unstable Bitcoin fork allowing for experimentation, different from an altcoin. However, the lack of incentive poses a problem. Adam Back disagrees, stating that incompatible versions of consensus code competing on the network would not work. He encourages analyzing and validating proposals through testing and proposing well-validated upgrade mechanisms.The email thread discusses the risks of upgrading Bitcoin's consensus code and emphasizes the importance of everyone upgrading to the same consensus rule change. It proposes creating multiple implementations of Bitcoin Core with different scaling solutions, but discourages encouraging nodes or miners to "vote" by running different consensus rules, as it can create compatibility issues and politicize the topic.In an email conversation, Peter R inquires about Bitcoin-B associated with Blockstream. Blockstream responds that they have no interest in maintaining a separate implementation of Bitcoin at this time, as it would have negative value. Confusion arises between alternative implementations and the destructive bifurcation of the Bitcoin ledger.Creating multiple implementations would involve forking Bitcoin Core, with each group integrating innovation from other groups if desired. The idea of never reaching consensus with Bitcoin Core is suggested to encourage new implementations to fork and implement their preferred scaling solution. Users would select the winning solution based on the code they choose to run, promoting the decentralized spirit of Bitcoin. Decentralization in development is discussed to reduce dependency on Core, but convincing users to adopt new implementations poses a challenge due to the quality and popularity of Bitcoin Core. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Long-term-vision-for-bitcoind-was-libconsensus-and-bitcoin-development-process-.xml b/static/bitcoin-dev/Sept_2015/combined_Long-term-vision-for-bitcoind-was-libconsensus-and-bitcoin-development-process-.xml index 6d91a12299..43a3940032 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Long-term-vision-for-bitcoind-was-libconsensus-and-bitcoin-development-process-.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Long-term-vision-for-bitcoind-was-libconsensus-and-bitcoin-development-process-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Long-term vision for bitcoind (was libconsensus and bitcoin development process) - 2023-08-01T16:14:01.670159+00:00 + 2025-10-11T21:54:19.971880+00:00 + python-feedgen Eric Lombrozo 2015-09-23 00:10:50+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Long-term vision for bitcoind (was libconsensus and bitcoin development process) - 2023-08-01T16:14:01.670159+00:00 + 2025-10-11T21:54:19.972033+00:00 - Eric Lombrozo proposed a long-term plan for bitcoind in 2015, which involved several steps. The first step was to define an API for libconsensus, which would support an abstract DB model, track chain state, provide query mechanisms for blocks and transactions with optional pruning and indexing, expose a subscription mechanism for events such as NEW_TIP, REORG, etc., and contain a script interpreter. This library could be developed alongside Bitcoin Core without major changes to the core itself.The second step in the plan was to develop a peer services library that handles peer discovery and relay tasks. This library would use libconsensus for validation functionality and as a datastore for the consensus state, but maintain its own database for peer history and statistics.The third step involved providing high-level calls and pub/sub mechanisms for API/RPC. Additionally, the wallet was suggested to be split into a separate process that connects to the stack via the API/RPC layer.Jorge Timón supported this long-term vision and proposed that bitcoind becomes a subtree of bitcoin-wallet, which already includes bitcoin-qt. He also suggested that upper layers should be migrated to C++11. This architecture was believed to maximize the number of people who can contribute safely to the project.In a Bitcoin development mailing list, Wladimir J. van der Laan shared his vision for Bitcoind as a P2P node with validation and blockchain store. The idea was to have data sources that could be subscribed to or pulled from. Another contributor agreed with the long-term plan and suggested two steps for its implementation. The first step involved moving Libconsensus to a subtree, including libsecp256k1 as an internal subtree. The second step was to make Bitcoind a subtree of bitcoin-wallet. The proposed architecture had bitcoin-qt on top of bitcoin-wallet, which is on top of bitcoind and other components like bitcoin-cli and bitcoin-tx. Finally, bitcoind would be on top of libconsensus, which would be on top of libsecp256k1.The goal of this proposed architecture was to maximize the number of people who can safely contribute to the project. It was considered to align with the long-term vision shared by most contributors. However, criticisms and feedback for the plan were welcomed. 2015-09-23T00:10:50+00:00 + Eric Lombrozo proposed a long-term plan for bitcoind in 2015, which involved several steps. The first step was to define an API for libconsensus, which would support an abstract DB model, track chain state, provide query mechanisms for blocks and transactions with optional pruning and indexing, expose a subscription mechanism for events such as NEW_TIP, REORG, etc., and contain a script interpreter. This library could be developed alongside Bitcoin Core without major changes to the core itself.The second step in the plan was to develop a peer services library that handles peer discovery and relay tasks. This library would use libconsensus for validation functionality and as a datastore for the consensus state, but maintain its own database for peer history and statistics.The third step involved providing high-level calls and pub/sub mechanisms for API/RPC. Additionally, the wallet was suggested to be split into a separate process that connects to the stack via the API/RPC layer.Jorge Timón supported this long-term vision and proposed that bitcoind becomes a subtree of bitcoin-wallet, which already includes bitcoin-qt. He also suggested that upper layers should be migrated to C++11. This architecture was believed to maximize the number of people who can contribute safely to the project.In a Bitcoin development mailing list, Wladimir J. van der Laan shared his vision for Bitcoind as a P2P node with validation and blockchain store. The idea was to have data sources that could be subscribed to or pulled from. Another contributor agreed with the long-term plan and suggested two steps for its implementation. The first step involved moving Libconsensus to a subtree, including libsecp256k1 as an internal subtree. The second step was to make Bitcoind a subtree of bitcoin-wallet. The proposed architecture had bitcoin-qt on top of bitcoin-wallet, which is on top of bitcoind and other components like bitcoin-cli and bitcoin-tx. Finally, bitcoind would be on top of libconsensus, which would be on top of libsecp256k1.The goal of this proposed architecture was to maximize the number of people who can safely contribute to the project. It was considered to align with the long-term vision shared by most contributors. However, criticisms and feedback for the plan were welcomed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Named-Bitcoin-Addresses.xml b/static/bitcoin-dev/Sept_2015/combined_Named-Bitcoin-Addresses.xml index 703b538ff3..c14ed9933f 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Named-Bitcoin-Addresses.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Named-Bitcoin-Addresses.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Named Bitcoin Addresses - 2023-08-01T16:04:08.416867+00:00 + 2025-10-11T21:54:49.692314+00:00 + python-feedgen Kristov Atlas 2015-09-11 15:13:18+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Named Bitcoin Addresses - 2023-08-01T16:04:08.416867+00:00 + 2025-10-11T21:54:49.692505+00:00 - The proposal to assign unique names to Bitcoin addresses has faced criticism due to concerns over privacy and security. It is widely known that reusing Bitcoin addresses can compromise both privacy and security, making it essential to avoid such practices. Maintaining a registry of all addresses on one's computer could also present scalability challenges and unnecessary complexity for most network participants. To address the issue of complex and difficult-to-memorize Bitcoin addresses, some suggest developing a name registry system off-chain, connected to bip47 reusable payment codes.This proposed naming convention involves users of the system selecting names from a directory. The names would be sorted based on their first character and total length, allowing for efficient binary search through the data. Once a name is verified and broadcasted to the network, it becomes available for use. However, skepticism remains regarding the potential privacy and security implications of this approach.The problem of complex Bitcoin addresses that are challenging to memorize and share is well-known. In response, the idea of assigning unique names to Bitcoin addresses has been put forward. This proposal involves creating a new address with a user-chosen name, which is then broadcasted to the network for availability verification. The client ensures that the name is valid and not already taken before confirming the transaction. When sending money to a named address, the recipient's wallet references the same directory as the sender's wallet to locate the desired name's OP_RETURN output. If found, the wallet extracts information from the transaction and uses the sending address to complete the Bitcoin transfer. Various solutions for this issue are available on GitHub, with the recommended practice being the use of BIP-70 for sending payment requests.On September 10, 2015, a member of the Bitcoin developer community proposed a solution to the challenge of complex and hard-to-memorize Bitcoin addresses. The suggestion involved assigning unique names to addresses, aiming to simplify sharing and improve user-friendliness. The proposal outlined how a user, such as Bob, could create a named address by entering their preferred name into their wallet and verifying its availability through a directory of previously chosen names. Once verified, Bob's client would send a transaction to an address without a private key but visible on the blockchain, with the name appended as an OP_RETURN output. Alice, for instance, could then easily send Bitcoin to Bob's named address using a binary search method to confirm name availability. The proposal aimed to establish a fully verifiable and independent approach to assigning names to Bitcoin addresses, enhancing usability.Bitcoin addresses can be complex and daunting for new users to memorize and share. To provide a more user-friendly experience, a method has been proposed to assign unique names to Bitcoin addresses. With this named address, users can easily remember it and minimize the risk of sending Bitcoin to the wrong recipient. Creating a named Bitcoin address involves entering the desired name into the wallet, which then checks for availability by referencing a directory of previously chosen names. If the name is available, a transaction with 1 satoshi and a small fee is sent to an address without a private key, with the name appended as an OP_RETURN output. After confirmation, the named address is ready to use.When someone wants to send Bitcoin to a named address, their client consults the same directory and employs a binary search method to locate the OP_RETURN output associated with the desired name. Upon finding the name, the client uses the address linked to that transaction to complete the Bitcoin transfer. This proposed method is entirely verifiable and does not rely on third parties. It offers a solution to the issue of complex Bitcoin addresses and has the potential to enhance the overall user experience. Feedback and inquiries regarding this proposal are encouraged. 2015-09-11T15:13:18+00:00 + The proposal to assign unique names to Bitcoin addresses has faced criticism due to concerns over privacy and security. It is widely known that reusing Bitcoin addresses can compromise both privacy and security, making it essential to avoid such practices. Maintaining a registry of all addresses on one's computer could also present scalability challenges and unnecessary complexity for most network participants. To address the issue of complex and difficult-to-memorize Bitcoin addresses, some suggest developing a name registry system off-chain, connected to bip47 reusable payment codes.This proposed naming convention involves users of the system selecting names from a directory. The names would be sorted based on their first character and total length, allowing for efficient binary search through the data. Once a name is verified and broadcasted to the network, it becomes available for use. However, skepticism remains regarding the potential privacy and security implications of this approach.The problem of complex Bitcoin addresses that are challenging to memorize and share is well-known. In response, the idea of assigning unique names to Bitcoin addresses has been put forward. This proposal involves creating a new address with a user-chosen name, which is then broadcasted to the network for availability verification. The client ensures that the name is valid and not already taken before confirming the transaction. When sending money to a named address, the recipient's wallet references the same directory as the sender's wallet to locate the desired name's OP_RETURN output. If found, the wallet extracts information from the transaction and uses the sending address to complete the Bitcoin transfer. Various solutions for this issue are available on GitHub, with the recommended practice being the use of BIP-70 for sending payment requests.On September 10, 2015, a member of the Bitcoin developer community proposed a solution to the challenge of complex and hard-to-memorize Bitcoin addresses. The suggestion involved assigning unique names to addresses, aiming to simplify sharing and improve user-friendliness. The proposal outlined how a user, such as Bob, could create a named address by entering their preferred name into their wallet and verifying its availability through a directory of previously chosen names. Once verified, Bob's client would send a transaction to an address without a private key but visible on the blockchain, with the name appended as an OP_RETURN output. Alice, for instance, could then easily send Bitcoin to Bob's named address using a binary search method to confirm name availability. The proposal aimed to establish a fully verifiable and independent approach to assigning names to Bitcoin addresses, enhancing usability.Bitcoin addresses can be complex and daunting for new users to memorize and share. To provide a more user-friendly experience, a method has been proposed to assign unique names to Bitcoin addresses. With this named address, users can easily remember it and minimize the risk of sending Bitcoin to the wrong recipient. Creating a named Bitcoin address involves entering the desired name into the wallet, which then checks for availability by referencing a directory of previously chosen names. If the name is available, a transaction with 1 satoshi and a small fee is sent to an address without a private key, with the name appended as an OP_RETURN output. After confirmation, the named address is ready to use.When someone wants to send Bitcoin to a named address, their client consults the same directory and employs a binary search method to locate the OP_RETURN output associated with the desired name. Upon finding the name, the client uses the address linked to that transaction to complete the Bitcoin transfer. This proposed method is entirely verifiable and does not rely on third parties. It offers a solution to the issue of complex Bitcoin addresses and has the potential to enhance the overall user experience. Feedback and inquiries regarding this proposal are encouraged. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_On-bitcoin-dev-list-admin-and-list-noise.xml b/static/bitcoin-dev/Sept_2015/combined_On-bitcoin-dev-list-admin-and-list-noise.xml index fd23a20a87..1daa8170ac 100644 --- a/static/bitcoin-dev/Sept_2015/combined_On-bitcoin-dev-list-admin-and-list-noise.xml +++ b/static/bitcoin-dev/Sept_2015/combined_On-bitcoin-dev-list-admin-and-list-noise.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - On bitcoin-dev list admin and list noise - 2023-08-01T16:25:41.503163+00:00 + 2025-10-11T21:55:36.432238+00:00 + python-feedgen Pavel Janík 2015-09-29 17:59:18+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - On bitcoin-dev list admin and list noise - 2023-08-01T16:25:41.503163+00:00 + 2025-10-11T21:55:36.432429+00:00 - The bitcoin-dev mailing list is facing concerns about noise and off-topic discussions. Some suggest that the maintainer should take charge and make decisions on how Core does things, rather than having heated debates. Pavel Janík highlights the confusion between the maintainer of Bitcoin Core and the moderator of the mailing list. One proposed solution is for maintainers to declare how Core operates and end debates to prevent circular conversations. However, this technique is not being utilized by Wladimir, which should be addressed. Allowing random people to dismiss valid objections with red cards only exacerbates user frustration.The bitcoin-dev mailing list was originally intended for discussing ongoing development issues related to the protocol and bitcoin core, not for holding the development community accountable or venting frustrations. Some developers have switched to digest-only or unsubscribed due to concerns that the list could become a platform for PR and populist venting, expanding its scope and decreasing its utility. There are worries that it may become difficult for an average somewhat technical person to hold the development community accountable or have their voice heard. The line on debates over bitcoin philosophy and broader context being considered off-topic is also questioned.The main concern revolves around the potential censorship of one of the last uncensored forums for technical Bitcoin discussion with wide viewership. This forum is seen as a means for the average somewhat technical person to hold the Bitcoin development community accountable and be heard. However, there is uncertainty regarding who will determine what is considered "off-topic" by list admins. Despite these concerns, it only takes a short amount of time each day to read the forum while enjoying coffee.In an IRC discussion, it was mentioned that the bitcoin-dev list has become too noisy, with debates over bitcoin philosophy and broader context leading to grumpy list admins declaring them as "off-topic." To address this issue, it is proposed to narrow the focus of the list to near-term technical changes to the bitcoin protocol and its implementations, such as bitcoin core and btcd. However, it is also suggested that there should be a designated place for discussions to be redirected, hence the proposal for a second list called bitcoin-tech-discuss or simply 'bitcoin' with a more general rubric. This split has proven successful in IRC, reducing noise and maintaining productivity. The overall goal is to increase productivity by focusing on technical discussions related to bitcoin development while providing a separate platform for broader discussions. 2015-09-29T17:59:18+00:00 + The bitcoin-dev mailing list is facing concerns about noise and off-topic discussions. Some suggest that the maintainer should take charge and make decisions on how Core does things, rather than having heated debates. Pavel Janík highlights the confusion between the maintainer of Bitcoin Core and the moderator of the mailing list. One proposed solution is for maintainers to declare how Core operates and end debates to prevent circular conversations. However, this technique is not being utilized by Wladimir, which should be addressed. Allowing random people to dismiss valid objections with red cards only exacerbates user frustration.The bitcoin-dev mailing list was originally intended for discussing ongoing development issues related to the protocol and bitcoin core, not for holding the development community accountable or venting frustrations. Some developers have switched to digest-only or unsubscribed due to concerns that the list could become a platform for PR and populist venting, expanding its scope and decreasing its utility. There are worries that it may become difficult for an average somewhat technical person to hold the development community accountable or have their voice heard. The line on debates over bitcoin philosophy and broader context being considered off-topic is also questioned.The main concern revolves around the potential censorship of one of the last uncensored forums for technical Bitcoin discussion with wide viewership. This forum is seen as a means for the average somewhat technical person to hold the Bitcoin development community accountable and be heard. However, there is uncertainty regarding who will determine what is considered "off-topic" by list admins. Despite these concerns, it only takes a short amount of time each day to read the forum while enjoying coffee.In an IRC discussion, it was mentioned that the bitcoin-dev list has become too noisy, with debates over bitcoin philosophy and broader context leading to grumpy list admins declaring them as "off-topic." To address this issue, it is proposed to narrow the focus of the list to near-term technical changes to the bitcoin protocol and its implementations, such as bitcoin core and btcd. However, it is also suggested that there should be a designated place for discussions to be redirected, hence the proposal for a second list called bitcoin-tech-discuss or simply 'bitcoin' with a more general rubric. This split has proven successful in IRC, reducing noise and maintaining productivity. The overall goal is to increase productivity by focusing on technical discussions related to bitcoin development while providing a separate platform for broader discussions. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Open-Block-Chain-Licence-BIP-xxxx-Draft.xml b/static/bitcoin-dev/Sept_2015/combined_Open-Block-Chain-Licence-BIP-xxxx-Draft.xml index 1afd563613..4c64d50327 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Open-Block-Chain-Licence-BIP-xxxx-Draft.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Open-Block-Chain-Licence-BIP-xxxx-Draft.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Open Block Chain Licence, BIP[xxxx] Draft - 2023-08-01T15:54:54.719781+00:00 + 2025-10-11T21:55:17.314483+00:00 + python-feedgen Milly Bitcoin 2015-09-02 20:58:38+00:00 @@ -95,13 +96,13 @@ - python-feedgen + 2 Combined summary - Open Block Chain Licence, BIP[xxxx] Draft - 2023-08-01T15:54:54.719781+00:00 + 2025-10-11T21:55:17.314679+00:00 - The discussion revolves around the proposal for a blockchain license to supplement the existing MIT License. One participant, Warren Togami Jr., expresses skepticism about the need for such a license, citing U.S. copyright doctrine and questioning the legal protection of databases. The issue of ownership and licensing of the Bitcoin blockchain is debated, with suggestions made on who should be assigned rights to the blockchain. There are concerns about the centralization of a decentralized system and the potential legal issues surrounding licensing after the fact.The draft BIP is shared for further evaluation and discussion. Additional points raised include the lack of defined rights for Bitcoin users and the public domain status of the Bitcoin blockchain. The need for clarity and guidance in the BIP discussion process is emphasized. There are also discussions on copyright ownership, licensing of transactions, and the potential problems that may arise.Ahmed Zsales proposes that miners be the main beneficiaries of licensing, but there are concerns about the practicality and legal implications of this approach. Overall, further investigation and study are recommended to determine the feasibility and necessity of a blockchain license.In a discussion on the bitcoin-dev mailing list, Ahmed Zsales suggested that a blockchain license is required for the Bitcoin network. This generated interest and led to a previous discussion in 2012 which was shared by Bryan Bishop. The group also considered references to protections for private keys while they remain under your control and whether or not finding private keys attached to coins and moving the funds constituted theft. However, the decision was made not to include anything specific in the draft license to keep it simple, relying instead on generic definitions of rights to private transaction data which would cover private keys.Ahmed Zsales sent a message to the bitcoin-dev mailing list on September 1, 2015 suggesting that the Bitcoin network needed a blockchain license. This topic was previously discussed in 2012 on bitcointalk.org. Bryan, who signed off on the email, provided his website and phone number for further contact.It has been suggested that a blockchain license is necessary to supplement the existing MIT License, which is believed to only cover the core reference client software. However, before obtaining a license, it is important to determine the entity that holds the MIT License, as just posting a notice does not necessarily make it true. Additionally, there may not even be a valid license on the software in question. If a blockchain license were to be obtained, it is unclear what entity would hold this license and who would make that decision. If the developers themselves were to decide, it would suggest that they own the blockchain, which may not be consistent with the current situation. Therefore, it is recommended to consult a lawyer before proceeding with any licensing agreements.According to the message, there is a belief that the network requires a blockchain license in addition to the existing MIT License, which only covers the core reference client software. However, replacing or amending the existing MIT License is not within the scope of the draft BIP. The rationale and details of the draft BIP for discussion and evaluation can be found in a document shared via Google Drive. The message was signed by someone named Ahmed. 2015-09-02T20:58:38+00:00 + The discussion revolves around the proposal for a blockchain license to supplement the existing MIT License. One participant, Warren Togami Jr., expresses skepticism about the need for such a license, citing U.S. copyright doctrine and questioning the legal protection of databases. The issue of ownership and licensing of the Bitcoin blockchain is debated, with suggestions made on who should be assigned rights to the blockchain. There are concerns about the centralization of a decentralized system and the potential legal issues surrounding licensing after the fact.The draft BIP is shared for further evaluation and discussion. Additional points raised include the lack of defined rights for Bitcoin users and the public domain status of the Bitcoin blockchain. The need for clarity and guidance in the BIP discussion process is emphasized. There are also discussions on copyright ownership, licensing of transactions, and the potential problems that may arise.Ahmed Zsales proposes that miners be the main beneficiaries of licensing, but there are concerns about the practicality and legal implications of this approach. Overall, further investigation and study are recommended to determine the feasibility and necessity of a blockchain license.In a discussion on the bitcoin-dev mailing list, Ahmed Zsales suggested that a blockchain license is required for the Bitcoin network. This generated interest and led to a previous discussion in 2012 which was shared by Bryan Bishop. The group also considered references to protections for private keys while they remain under your control and whether or not finding private keys attached to coins and moving the funds constituted theft. However, the decision was made not to include anything specific in the draft license to keep it simple, relying instead on generic definitions of rights to private transaction data which would cover private keys.Ahmed Zsales sent a message to the bitcoin-dev mailing list on September 1, 2015 suggesting that the Bitcoin network needed a blockchain license. This topic was previously discussed in 2012 on bitcointalk.org. Bryan, who signed off on the email, provided his website and phone number for further contact.It has been suggested that a blockchain license is necessary to supplement the existing MIT License, which is believed to only cover the core reference client software. However, before obtaining a license, it is important to determine the entity that holds the MIT License, as just posting a notice does not necessarily make it true. Additionally, there may not even be a valid license on the software in question. If a blockchain license were to be obtained, it is unclear what entity would hold this license and who would make that decision. If the developers themselves were to decide, it would suggest that they own the blockchain, which may not be consistent with the current situation. Therefore, it is recommended to consult a lawyer before proceeding with any licensing agreements.According to the message, there is a belief that the network requires a blockchain license in addition to the existing MIT License, which only covers the core reference client software. However, replacing or amending the existing MIT License is not within the scope of the draft BIP. The rationale and details of the draft BIP for discussion and evaluation can be found in a document shared via Google Drive. The message was signed by someone named Ahmed. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Problem-compiling-bitcoin-core.xml b/static/bitcoin-dev/Sept_2015/combined_Problem-compiling-bitcoin-core.xml index a61a9dd0c8..2538bc49f6 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Problem-compiling-bitcoin-core.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Problem-compiling-bitcoin-core.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Problem compiling bitcoin-core - 2023-08-01T16:02:04.583775+00:00 + 2025-10-11T21:55:47.050783+00:00 + python-feedgen LinuXperia 2015-09-07 18:35:31+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - Problem compiling bitcoin-core - 2023-08-01T16:02:04.583775+00:00 + 2025-10-11T21:55:47.050923+00:00 - In an email conversation dated September 7th, 2015, LinuXperia reached out for help on the Bitcoin-dev mailing list to compile Bitcoin Core on their Ubuntu Linux machine. They had followed standard procedures by running "./autogen.sh" and "./configure," but encountered a build error. Sriram Karra, a member of the mailing list, responded by pointing out that the Boost libs were not being found and questioned why LinuXperia was attempting to build with a custom lib directory.LinuXperia shared their configuration command, which included specifying CPPFLAGS and LDFLAGS for the custom lib directory. The error message indicated undefined references to various Boost functions, such as boost::filesystem::path_traits::dispatch(), boost::thread::physical_concurrency(), boost::program_options::to_internal(), boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(), and boost::filesystem::detail::copy_file().It was suggested that LinuXperia may have used the wrong build option, which should have been "--with-gui=no." This could be the reason for the undefined references to Boost libraries. The conversation emphasized the importance of following the correct build options and dependencies when compiling Bitcoin Core.BTC Drake and ChinaTinte also reached out directly to LinuXperia after seeing the initial post and were able to help him solve the problem. Eventually, LinuXperia successfully built bitcoin-core from sources and expressed gratitude towards everyone who assisted, including the bitcoin developers.The email thread concluded by providing links to the Bitcoin-dev mailing list and instructions for signing up. Overall, the conversation highlighted the significance of ensuring the accurate build options and dependencies to overcome build errors in compiling Bitcoin Core on Ubuntu Linux machines. 2015-09-07T18:35:31+00:00 + In an email conversation dated September 7th, 2015, LinuXperia reached out for help on the Bitcoin-dev mailing list to compile Bitcoin Core on their Ubuntu Linux machine. They had followed standard procedures by running "./autogen.sh" and "./configure," but encountered a build error. Sriram Karra, a member of the mailing list, responded by pointing out that the Boost libs were not being found and questioned why LinuXperia was attempting to build with a custom lib directory.LinuXperia shared their configuration command, which included specifying CPPFLAGS and LDFLAGS for the custom lib directory. The error message indicated undefined references to various Boost functions, such as boost::filesystem::path_traits::dispatch(), boost::thread::physical_concurrency(), boost::program_options::to_internal(), boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(), and boost::filesystem::detail::copy_file().It was suggested that LinuXperia may have used the wrong build option, which should have been "--with-gui=no." This could be the reason for the undefined references to Boost libraries. The conversation emphasized the importance of following the correct build options and dependencies when compiling Bitcoin Core.BTC Drake and ChinaTinte also reached out directly to LinuXperia after seeing the initial post and were able to help him solve the problem. Eventually, LinuXperia successfully built bitcoin-core from sources and expressed gratitude towards everyone who assisted, including the bitcoin developers.The email thread concluded by providing links to the Bitcoin-dev mailing list and instructions for signing up. Overall, the conversation highlighted the significance of ensuring the accurate build options and dependencies to overcome build errors in compiling Bitcoin Core on Ubuntu Linux machines. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Proposal-to-add-the-bitcoin-symbol-to-Unicode.xml b/static/bitcoin-dev/Sept_2015/combined_Proposal-to-add-the-bitcoin-symbol-to-Unicode.xml index 6e047d2a7c..aec7cfba43 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Proposal-to-add-the-bitcoin-symbol-to-Unicode.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Proposal-to-add-the-bitcoin-symbol-to-Unicode.xml @@ -1,29 +1,43 @@ - + 2 Combined summary - Proposal to add the bitcoin symbol to Unicode - 2023-08-01T16:01:49.328366+00:00 - - Ken Shirriff 2015-09-08 21:05:07+00:00 - - - Danny Thorpe 2015-09-08 20:28:41+00:00 - - - Peter Todd 2015-09-06 23:26:54+00:00 - - - Andreas Schildbach 2015-09-05 18:48:57+00:00 - - - Richard Moore 2015-09-05 14:58:18+00:00 - - - Theo Chino 2015-09-05 14:26:19+00:00 - - - Ken Shirriff 2015-09-05 14:11:27+00:00 - + 2025-10-11T21:54:41.185361+00:00 + python-feedgen + + + [bitcoin-dev] Proposal to add the bitcoin symbol to Unicode Ken Shirriff + 2015-09-05T14:11:00.000Z + + + Theo Chino + 2015-09-05T14:26:00.000Z + + + Richard Moore + 2015-09-05T14:58:00.000Z + + + Andreas Schildbach + 2015-09-05T18:48:00.000Z + + + Peter Todd + 2015-09-06T23:26:00.000Z + + + Danny Thorpe + 2015-09-08T20:28:00.000Z + + + Ken Shirriff + 2015-09-08T21:05:00.000Z + + + [bitcoin-dev] Fwd: " Theo Chino + 2017-06-20T22:13:00.000Z + + @@ -31,13 +45,13 @@ - python-feedgen + 2 Combined summary - Proposal to add the bitcoin symbol to Unicode - 2023-08-01T16:01:49.328366+00:00 + 2025-10-11T21:54:41.186431+00:00 - Ken Shirriff, a member of the Bitcoin community, has proposed the addition of the B-with-vertical-bars bitcoin symbol to the Unicode standard. Currently, the use of the bitcoin symbol in text is inconvenient due to its absence from Unicode. The proposal aims to avoid confusion with the Thai baht currency symbol, which also uses a B with a single vertical bar. However, there is a suggestion to use the already available B-with-horizontal-bar (Ƀ) symbol in Unicode instead. This symbol is already included in the Unicode glyph set and is available on most Unicode enabled devices. The argument against this suggestion is that using the Thai baht currency symbol for Bitcoin would lead to further confusion.Shirriff believes that adding the bitcoin symbol to Unicode is important to avoid confusion with other symbols and enable everyone to use the standard symbol. He has successfully proposed a new character for Unicode before and believes that this proposal has a good chance of succeeding. However, he hopes to receive endorsement from Bitcoin developers to help the Unicode Committee realize the importance of adding this symbol.The full proposal can be found at http://righto.com/bitcoin-unicode.pdf. By adding the bitcoin symbol to Unicode, it will become much more convenient for users to incorporate the symbol in text. Shirriff has requested support from the bitcoin-dev group and provided contact information for Richard Moore, founder of Genetic Mistakes Software Inc., in the email thread. A link to the Bitcoin symbol page on en.bitcoin.it/wiki is also provided.In response to Shirriff's proposal, Theo Chino has sent an email asking how he can join and support the effort to have the bitcoin symbol added to Unicode. Shirriff believes that including the common B-with-vertical-bars bitcoin symbol in Unicode will make using the symbol in text more convenient. He has confidence in the success of this proposal based on his previous experience in proposing a new character for Unicode. The proposal can be found at http://righto.com/bitcoin-unicode.pdf. Shirriff has reached out to the bitcoin-dev group for their endorsement, as support from Bitcoin developers will help the Unicode Committee recognize the importance of adding this symbol.Bitcoin enthusiasts are facing difficulties in using the bitcoin symbol in text due to its absence from the Unicode standard. In response, Ken Shirriff has written a proposal to add the bitcoin symbol to Unicode. He believes that with endorsement from Bitcoin developers, the Unicode Committee will understand the significance of adding this symbol. The proposal can be found at http://righto.com/bitcoin-unicode.pdf. Shirriff also suggests running the proposal by the bitcoin-dev group for their support. 2015-09-08T21:05:07+00:00 + Ken Shirriff, a member of the Bitcoin community, has proposed the addition of the B-with-vertical-bars bitcoin symbol to the Unicode standard. Currently, the use of the bitcoin symbol in text is inconvenient due to its absence from Unicode. The proposal aims to avoid confusion with the Thai baht currency symbol, which also uses a B with a single vertical bar. However, there is a suggestion to use the already available B-with-horizontal-bar (Ƀ) symbol in Unicode instead. This symbol is already included in the Unicode glyph set and is available on most Unicode enabled devices. The argument against this suggestion is that using the Thai baht currency symbol for Bitcoin would lead to further confusion.Shirriff believes that adding the bitcoin symbol to Unicode is important to avoid confusion with other symbols and enable everyone to use the standard symbol. He has successfully proposed a new character for Unicode before and believes that this proposal has a good chance of succeeding. However, he hopes to receive endorsement from Bitcoin developers to help the Unicode Committee realize the importance of adding this symbol.The full proposal can be found at http://righto.com/bitcoin-unicode.pdf. By adding the bitcoin symbol to Unicode, it will become much more convenient for users to incorporate the symbol in text. Shirriff has requested support from the bitcoin-dev group and provided contact information for Richard Moore, founder of Genetic Mistakes Software Inc., in the email thread. A link to the Bitcoin symbol page on en.bitcoin.it/wiki is also provided.In response to Shirriff's proposal, Theo Chino has sent an email asking how he can join and support the effort to have the bitcoin symbol added to Unicode. Shirriff believes that including the common B-with-vertical-bars bitcoin symbol in Unicode will make using the symbol in text more convenient. He has confidence in the success of this proposal based on his previous experience in proposing a new character for Unicode. The proposal can be found at http://righto.com/bitcoin-unicode.pdf. Shirriff has reached out to the bitcoin-dev group for their endorsement, as support from Bitcoin developers will help the Unicode Committee recognize the importance of adding this symbol.Bitcoin enthusiasts are facing difficulties in using the bitcoin symbol in text due to its absence from the Unicode standard. In response, Ken Shirriff has written a proposal to add the bitcoin symbol to Unicode. He believes that with endorsement from Bitcoin developers, the Unicode Committee will understand the significance of adding this symbol. The proposal can be found at http://righto.com/bitcoin-unicode.pdf. Shirriff also suggests running the proposal by the bitcoin-dev group for their support. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Proposed-minor-change-to-BIP-01-to-use-a-PR-for-request-assignment.xml b/static/bitcoin-dev/Sept_2015/combined_Proposed-minor-change-to-BIP-01-to-use-a-PR-for-request-assignment.xml index 0ecd462ce1..b01e76b092 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Proposed-minor-change-to-BIP-01-to-use-a-PR-for-request-assignment.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Proposed-minor-change-to-BIP-01-to-use-a-PR-for-request-assignment.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed minor change to BIP 01 to use a PR for request assignment - 2023-08-01T15:58:57.808647+00:00 + 2025-10-11T21:55:21.563670+00:00 + python-feedgen Eric Lombrozo 2015-09-04 18:41:52+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Proposed minor change to BIP 01 to use a PR for request assignment - 2023-08-01T15:58:57.808647+00:00 + 2025-10-11T21:55:21.563832+00:00 - Eric suggested implementing a special label to indicate number requests in response to Gregory Maxwell's proposal to change the process for requesting number assignments for Bitcoin Improvement Proposals (BIPs). Maxwell proposed opening a pull request with the BIP text, without a number, as a mechanism for requesting number assignment. This change was necessary because the current process outlined in BIP01 is outdated and was written when a different solution was used for storing and presenting BIPs. Maxwell requested that any responses be strictly directed to his question and that a new thread be started for a different subject.The provided context is a PGP signed message from Douglas Roark, a Senior Developer at Armory Technologies, Inc. The message includes an "ACK" which typically stands for acknowledgement, but its specific meaning is unclear without additional information. The rest of the message contains encrypted text, likely using the SHA512 hash function. The signature attached to the message ensures that it has not been tampered with since it was signed by Douglas Roark. The signature includes a link to GPGTools, which is a software suite used for encryption and digital signatures.In an email exchange from September 4, 2015, Marco Pontello expressed his inability to see any issues with the current process for requesting number assignments. However, he requested more details on the topic. The email thread discussed the use of GitHub for BIPs and how it has caused confusion with numbering assignments. It was mentioned that a WIKI page used to be the preferred method, but the switch to GitHub had some benefits despite the numbering issue. The email concluded with a reflection on the need to address the issue earlier and a reminder to learn from the experience.Overall, Gregory Maxwell proposed changing the process for requesting number assignments for BIPs due to the outdated nature of the current process. He suggested opening a pull request with the BIP text, using the author's name and an index as the number, as the new mechanism for requesting number assignments. This change would address difficulties in auditing assignments and make the process more auditable. The email exchange also highlighted the confusion caused by using GitHub for BIPs and discussed the benefits and drawbacks of this platform compared to the previous method of using a WIKI page. The importance of addressing the numbering issue earlier was emphasized, and it was suggested to learn from this experience moving forward. 2015-09-04T18:41:52+00:00 + Eric suggested implementing a special label to indicate number requests in response to Gregory Maxwell's proposal to change the process for requesting number assignments for Bitcoin Improvement Proposals (BIPs). Maxwell proposed opening a pull request with the BIP text, without a number, as a mechanism for requesting number assignment. This change was necessary because the current process outlined in BIP01 is outdated and was written when a different solution was used for storing and presenting BIPs. Maxwell requested that any responses be strictly directed to his question and that a new thread be started for a different subject.The provided context is a PGP signed message from Douglas Roark, a Senior Developer at Armory Technologies, Inc. The message includes an "ACK" which typically stands for acknowledgement, but its specific meaning is unclear without additional information. The rest of the message contains encrypted text, likely using the SHA512 hash function. The signature attached to the message ensures that it has not been tampered with since it was signed by Douglas Roark. The signature includes a link to GPGTools, which is a software suite used for encryption and digital signatures.In an email exchange from September 4, 2015, Marco Pontello expressed his inability to see any issues with the current process for requesting number assignments. However, he requested more details on the topic. The email thread discussed the use of GitHub for BIPs and how it has caused confusion with numbering assignments. It was mentioned that a WIKI page used to be the preferred method, but the switch to GitHub had some benefits despite the numbering issue. The email concluded with a reflection on the need to address the issue earlier and a reminder to learn from the experience.Overall, Gregory Maxwell proposed changing the process for requesting number assignments for BIPs due to the outdated nature of the current process. He suggested opening a pull request with the BIP text, using the author's name and an index as the number, as the new mechanism for requesting number assignments. This change would address difficulties in auditing assignments and make the process more auditable. The email exchange also highlighted the confusion caused by using GitHub for BIPs and discussed the benefits and drawbacks of this platform compared to the previous method of using a WIKI page. The importance of addressing the numbering issue earlier was emphasized, and it was suggested to learn from this experience moving forward. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml b/static/bitcoin-dev/Sept_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml index 053fb60aaa..b2845b3466 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Proposed-new-policy-for-transactions-that-depend-on-other-unconfirmed-transactions.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Proposed new policy for transactions that depend on other unconfirmed transactions - 2023-08-01T15:15:59.869443+00:00 + 2025-10-11T21:54:51.815001+00:00 + python-feedgen Taariq Lewis 2015-10-08 06:10:37+00:00 @@ -39,13 +40,13 @@ - python-feedgen + 2 Combined summary - Proposed new policy for transactions that depend on other unconfirmed transactions - 2023-08-01T15:15:59.869443+00:00 + 2025-10-11T21:54:51.815145+00:00 - The proposed policy limits on unconfirmed transaction chains in Bitcoin Core are currently under discussion among developers. The existing limits for descendant packages are 1000 transactions and 2500kb total size, while for ancestor packages, the limits are 100 transactions and 900kb total size. However, there is a proposal to change these limits to 25 transactions and 100kb total size for both types of packages. It is important to note that these proposed limits are not a change to consensus rules and can be adjusted on an individual node basis in Bitcoin Core.In addition to the proposed limits on unconfirmed transaction chains, Alex Morcos has put forward a set of requirements for accepting new transactions into the mempool and relaying them. The aim of this policy is to limit the size of the mempool and ensure that a new transaction can cover the costs of any dependent transactions it may displace. Four new policy limits have been proposed, all of which can be configured using command line settings. In April and May of this year, these proposed limits would have affected less than 2% of transactions entering the mempool. However, during a stress test period, as many as 25% of transactions would have been impacted.The reason for reducing the limits on unconfirmed transaction chains is primarily due to concerns about mempool congestion and relay fee boosting attacks. The current limits for ancestor packages are 100 transactions and 900kb total size, while for descendant packages, the limits are 1000 transactions and 2500kb total size. The proposed new limits for both types of packages would be 25 transactions and 100kb total size. It is worth noting that these limits do not alter consensus rules and can be customized for each individual node using Bitcoin Core.Alex Morcos has made significant proposals to decrease the current policy limits on unconfirmed transaction chains. The existing limits for ancestor packages are 100 transactions and 900 kilobytes of total size, while for descendant packages, the limits are 1000 transactions and 2500 kilobytes of total size. The proposed new limits for both types of packages are 25 transactions and 100 kilobytes of total size. These limits can be adjusted at the command line level on each node that utilizes Bitcoin Core.To ensure a smooth and efficient transaction process, certain limits have been established. The first limit restricts transactions larger than 100 kilobytes from being accepted. This ensures that the size of transactions remains within a reasonable range. The second limit focuses on the fee rate, disallowing transactions with a fee rate equal to or less than 1 satoshi per byte. This encourages users to attach an appropriate fee, which helps prioritize their transactions. The third limit aims to prevent transaction flooding attacks by rejecting transactions that would cause the mempool's total size to exceed 300 megabytes. This safeguard protects the network from becoming overwhelmed by a large number of transactions. Lastly, the fourth limit maintains the policy that all transactions in the mempool should be mineable in the next block. To achieve this, transactions will not be accepted if the total size of all unconfirmed ancestor transactions is too large. By default, this limit is set at 1 megabyte.It is important to note that these limits would have affected less than 2% of transactions entering the mempool in April or May of this year. However, during the stress test period from July 6th to July 14th, up to 25% of the transactions would have been impacted. For those interested in the technical details, the code to implement these changes can be found in pull request 6557, which is based on pull request 6470. These pull requests contain the necessary modifications to enforce the aforementioned limits and enhance the overall transaction process. 2015-10-08T06:10:37+00:00 + The proposed policy limits on unconfirmed transaction chains in Bitcoin Core are currently under discussion among developers. The existing limits for descendant packages are 1000 transactions and 2500kb total size, while for ancestor packages, the limits are 100 transactions and 900kb total size. However, there is a proposal to change these limits to 25 transactions and 100kb total size for both types of packages. It is important to note that these proposed limits are not a change to consensus rules and can be adjusted on an individual node basis in Bitcoin Core.In addition to the proposed limits on unconfirmed transaction chains, Alex Morcos has put forward a set of requirements for accepting new transactions into the mempool and relaying them. The aim of this policy is to limit the size of the mempool and ensure that a new transaction can cover the costs of any dependent transactions it may displace. Four new policy limits have been proposed, all of which can be configured using command line settings. In April and May of this year, these proposed limits would have affected less than 2% of transactions entering the mempool. However, during a stress test period, as many as 25% of transactions would have been impacted.The reason for reducing the limits on unconfirmed transaction chains is primarily due to concerns about mempool congestion and relay fee boosting attacks. The current limits for ancestor packages are 100 transactions and 900kb total size, while for descendant packages, the limits are 1000 transactions and 2500kb total size. The proposed new limits for both types of packages would be 25 transactions and 100kb total size. It is worth noting that these limits do not alter consensus rules and can be customized for each individual node using Bitcoin Core.Alex Morcos has made significant proposals to decrease the current policy limits on unconfirmed transaction chains. The existing limits for ancestor packages are 100 transactions and 900 kilobytes of total size, while for descendant packages, the limits are 1000 transactions and 2500 kilobytes of total size. The proposed new limits for both types of packages are 25 transactions and 100 kilobytes of total size. These limits can be adjusted at the command line level on each node that utilizes Bitcoin Core.To ensure a smooth and efficient transaction process, certain limits have been established. The first limit restricts transactions larger than 100 kilobytes from being accepted. This ensures that the size of transactions remains within a reasonable range. The second limit focuses on the fee rate, disallowing transactions with a fee rate equal to or less than 1 satoshi per byte. This encourages users to attach an appropriate fee, which helps prioritize their transactions. The third limit aims to prevent transaction flooding attacks by rejecting transactions that would cause the mempool's total size to exceed 300 megabytes. This safeguard protects the network from becoming overwhelmed by a large number of transactions. Lastly, the fourth limit maintains the policy that all transactions in the mempool should be mineable in the next block. To achieve this, transactions will not be accepted if the total size of all unconfirmed ancestor transactions is too large. By default, this limit is set at 1 megabyte.It is important to note that these limits would have affected less than 2% of transactions entering the mempool in April or May of this year. However, during the stress test period from July 6th to July 14th, up to 25% of the transactions would have been impacted. For those interested in the technical details, the code to implement these changes can be found in pull request 6557, which is based on pull request 6470. These pull requests contain the necessary modifications to enforce the aforementioned limits and enhance the overall transaction process. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Quick-Bitcoin-Pre-Christmas-modest-blocksize-max-increase.xml b/static/bitcoin-dev/Sept_2015/combined_Quick-Bitcoin-Pre-Christmas-modest-blocksize-max-increase.xml index 04164738b3..6d243d5b03 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Quick-Bitcoin-Pre-Christmas-modest-blocksize-max-increase.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Quick-Bitcoin-Pre-Christmas-modest-blocksize-max-increase.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Quick Bitcoin/Pre-Christmas modest blocksize max increase - 2023-08-01T16:06:09.932904+00:00 + 2025-10-11T21:55:57.673836+00:00 + python-feedgen phm 2015-09-16 11:23:52+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Quick Bitcoin/Pre-Christmas modest blocksize max increase - 2023-08-01T16:06:09.932904+00:00 + 2025-10-11T21:55:57.673973+00:00 - Jason Livesay, a member of the Bitcoin Development team, has proposed building a new system to maintain the brand momentum, network, and business investment of Bitcoin. He suggests packaging this new system, referred to as QuickBitcoin or qbtc, with the bitcoin core client. The purpose of this system is to enable more/faster transactions while working on top of traditional bitcoins. Jason believes that the development team should focus solely on technical issues.Although some members have already started working on such a system, its future prospects are not very promising. Retail spending still accounts for a small percentage of Bitcoin transactions, and there are no indications of any significant changes in retail spending this Christmas compared to last year.A member of the Bitcoin-dev mailing list received an email proposing a short-term modest blockchain increase before the winter shopping rush. The proposal also suggests adopting a new system for fast transactions due to technical scaling limitations. This new system, called QuickBitcoin or qbtc, would build upon traditional Bitcoins but offer a mechanism for more/faster transactions. The goal is to scale Bitcoin while maintaining the strength of its existing network, community, and branding.However, the recipient of the email did not find the proposal to add anything substantial to the ongoing discussion and recommended reading more emails from the mailing list.After studying the issues, it has been recommended to implement a short-term modest blockchain increase, ranging between 2mb-5mb, before the winter shopping rush. However, due to fundamental technical limitations of scaling, a new system needs to be adopted for fast transactions, which will ultimately settle with traditional bitcoins.To ensure brand momentum, network stability, and business investment, the best approach forward is seen as building an additional system re-using the bitcoin name. This new system, known as QuickBitcoin or qbtc, would be bundled with the bitcoin core client and work on top of traditional bitcoins, providing a mechanism for more/faster transactions. The specific mechanism does not have to be perfect, as long as it is reasonably secure and useful, and accepted by the community. This strategy is believed to be the most effective way to scale bitcoin while maintaining the strength of its existing network, community, and branding.From the perspective of the public, this new system could simply continue to be called bitcoin. 2015-09-16T11:23:52+00:00 + Jason Livesay, a member of the Bitcoin Development team, has proposed building a new system to maintain the brand momentum, network, and business investment of Bitcoin. He suggests packaging this new system, referred to as QuickBitcoin or qbtc, with the bitcoin core client. The purpose of this system is to enable more/faster transactions while working on top of traditional bitcoins. Jason believes that the development team should focus solely on technical issues.Although some members have already started working on such a system, its future prospects are not very promising. Retail spending still accounts for a small percentage of Bitcoin transactions, and there are no indications of any significant changes in retail spending this Christmas compared to last year.A member of the Bitcoin-dev mailing list received an email proposing a short-term modest blockchain increase before the winter shopping rush. The proposal also suggests adopting a new system for fast transactions due to technical scaling limitations. This new system, called QuickBitcoin or qbtc, would build upon traditional Bitcoins but offer a mechanism for more/faster transactions. The goal is to scale Bitcoin while maintaining the strength of its existing network, community, and branding.However, the recipient of the email did not find the proposal to add anything substantial to the ongoing discussion and recommended reading more emails from the mailing list.After studying the issues, it has been recommended to implement a short-term modest blockchain increase, ranging between 2mb-5mb, before the winter shopping rush. However, due to fundamental technical limitations of scaling, a new system needs to be adopted for fast transactions, which will ultimately settle with traditional bitcoins.To ensure brand momentum, network stability, and business investment, the best approach forward is seen as building an additional system re-using the bitcoin name. This new system, known as QuickBitcoin or qbtc, would be bundled with the bitcoin core client and work on top of traditional bitcoins, providing a mechanism for more/faster transactions. The specific mechanism does not have to be perfect, as long as it is reasonably secure and useful, and accepted by the community. This strategy is believed to be the most effective way to scale bitcoin while maintaining the strength of its existing network, community, and branding.From the perspective of the public, this new system could simply continue to be called bitcoin. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml b/static/bitcoin-dev/Sept_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml index 79e11e1c35..5ea999bb79 100644 --- a/static/bitcoin-dev/Sept_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml +++ b/static/bitcoin-dev/Sept_2015/combined_RFC-BIP-URI-scheme-for-Blockchain-exploration.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC - BIP: URI scheme for Blockchain exploration - 2023-08-01T15:44:07.597614+00:00 + 2025-10-11T21:55:32.185612+00:00 + python-feedgen Marco Pontello 2015-11-18 12:31:46+00:00 @@ -131,13 +132,13 @@ - python-feedgen + 2 Combined summary - RFC - BIP: URI scheme for Blockchain exploration - 2023-08-01T15:44:07.597614+00:00 + 2025-10-11T21:55:32.185816+00:00 - A proposed new URI scheme for blockchain exploration has been submitted by Marco Pontello. The purpose of this URI scheme is to enable users to handle all requests for details about blocks, transactions, and addresses on a blockchain explorer with their preferred tool, whether it be a web service or a local application. Currently, Bitcoin clients typically point to an arbitrary blockchain explorer when the user looks for transaction details, and sometimes resorting to cut-and-paste is necessary. The same happens with posts and messages that reference specific transactions or blocks, if they provide links at all.The proposed URI follows a simple form: "blockchain:" followed by the block or transaction ID. The proposal suggests that keeping it simple should be practical enough, and blockchain explorers can apply the same disambiguation rules they are already using to process the usual search box. From the perspective of a wallet developer or other tool that needs to show blockchain references, using this scheme means they can simply make it a blockchain link and be done with it without worrying about any specific blockchain explorer or providing a means for the user to select one.The proposal also discusses improving the syntax of blockchain URLs. Participants suggest different approaches, such as making the chain part optional or using the "authority" component of the URL to identify the chain. There is also discussion about allowing well-known chains to register names as alternatives to the hash syntax. The use of the genesis block hash as a method for identifying a reference to a transaction is proposed, along with the idea of using name constants as a simpler alternative.Overall, the goal of the proposal is to create a standard URI scheme for blockchain exploration that all explorers would understand. This would provide users with the convenience of using their preferred explorer and simplify the process for wallet developers and other tools that need to show blockchain references. 2015-11-18T12:31:46+00:00 + A proposed new URI scheme for blockchain exploration has been submitted by Marco Pontello. The purpose of this URI scheme is to enable users to handle all requests for details about blocks, transactions, and addresses on a blockchain explorer with their preferred tool, whether it be a web service or a local application. Currently, Bitcoin clients typically point to an arbitrary blockchain explorer when the user looks for transaction details, and sometimes resorting to cut-and-paste is necessary. The same happens with posts and messages that reference specific transactions or blocks, if they provide links at all.The proposed URI follows a simple form: "blockchain:" followed by the block or transaction ID. The proposal suggests that keeping it simple should be practical enough, and blockchain explorers can apply the same disambiguation rules they are already using to process the usual search box. From the perspective of a wallet developer or other tool that needs to show blockchain references, using this scheme means they can simply make it a blockchain link and be done with it without worrying about any specific blockchain explorer or providing a means for the user to select one.The proposal also discusses improving the syntax of blockchain URLs. Participants suggest different approaches, such as making the chain part optional or using the "authority" component of the URL to identify the chain. There is also discussion about allowing well-known chains to register names as alternatives to the hash syntax. The use of the genesis block hash as a method for identifying a reference to a transaction is proposed, along with the idea of using name constants as a simpler alternative.Overall, the goal of the proposal is to create a standard URI scheme for blockchain exploration that all explorers would understand. This would provide users with the convenience of using their preferred explorer and simplify the process for wallet developers and other tools that need to show blockchain references. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml b/static/bitcoin-dev/Sept_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml index 56c20e0297..363d6f9e68 100644 --- a/static/bitcoin-dev/Sept_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml +++ b/static/bitcoin-dev/Sept_2015/combined_RFC-HD-Bitmessage-address-derivation-based-on-BIP-43.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - RFC: HD Bitmessage address derivation based on BIP-43 - 2023-08-01T14:09:53.705304+00:00 + 2025-10-11T21:54:47.561027+00:00 + python-feedgen Jorge Timón 2015-09-06 02:09:52+00:00 @@ -43,13 +44,13 @@ - python-feedgen + 2 Combined summary - RFC: HD Bitmessage address derivation based on BIP-43 - 2023-08-01T14:09:53.705304+00:00 + 2025-10-11T21:54:47.561164+00:00 - In September 2015, a discussion took place on the Bitcoin-dev mailing list regarding the maintenance of competing registries for different companies and P2P chains. Some argued that the current centralized registries were acceptable as long as they didn't rely on having only one registry or having the same values for the same chains. However, others believed that BIP44's centralized registry control by a single company was not acceptable and proposed using a code deterministically generated from the chain ID instead. This proposal was seen as retro-compatible and provided securely unique IDs without the need for a centralized registry. It was suggested to start a Chain IDs BIP.The BIP repository made a decision to move part of the standard to a separate repository due to the constant updates unrelated to Bitcoin proper. On September 5th, 2015, a conversation between Jorge Timón and Justus Ranvier on the bitcoin-dev mailing list addressed concerns about delegating the BIP-43 namespace management to a specific company (SatoshiLabs). Justus questioned the benefit of this delegation and proposed using purpose codes matching the BIP number instead. He also expressed concerns with BIP44's centralized registry control and suggested using a code deterministically generated from the chain ID as a solution.Luke Dashjr, a Bitcoin Core Developer, expressed concerns about polluting the BIP repository with non-Bitcoin related specifications in response to a proposal to add HD generation of keypairs from a single seed for non-conflicting uses. Justus Ranvier countered by stating that intentionally making a useful technology less useful due to difficulties in assigning non-colliding numbers was a strange approach to software engineering. Justus Ranvier is associated with the Open Bitcoin Privacy Project, which promotes financial privacy and anonymity through the use of Bitcoin.On June 30, 2015, Justus Ranvier proposed a Bitmessage address derivation method based on BIP-43 developed by Monetas. This method allows Bitmessage users to generate addresses from a seed, providing eternal key backups and enabling future use cases. Monetas proposed this method as a BIP to reserve a purpose code. The proposal was made on the bitcoin-dev mailing list and included links to the relevant GitHub pages and contact details.Overall, the discussions on the bitcoin-dev mailing list revolved around the management of purpose codes, registry control, and the benefits and drawbacks of different approaches to maintain competing registries for different companies and P2P chains. 2015-09-06T02:09:52+00:00 + In September 2015, a discussion took place on the Bitcoin-dev mailing list regarding the maintenance of competing registries for different companies and P2P chains. Some argued that the current centralized registries were acceptable as long as they didn't rely on having only one registry or having the same values for the same chains. However, others believed that BIP44's centralized registry control by a single company was not acceptable and proposed using a code deterministically generated from the chain ID instead. This proposal was seen as retro-compatible and provided securely unique IDs without the need for a centralized registry. It was suggested to start a Chain IDs BIP.The BIP repository made a decision to move part of the standard to a separate repository due to the constant updates unrelated to Bitcoin proper. On September 5th, 2015, a conversation between Jorge Timón and Justus Ranvier on the bitcoin-dev mailing list addressed concerns about delegating the BIP-43 namespace management to a specific company (SatoshiLabs). Justus questioned the benefit of this delegation and proposed using purpose codes matching the BIP number instead. He also expressed concerns with BIP44's centralized registry control and suggested using a code deterministically generated from the chain ID as a solution.Luke Dashjr, a Bitcoin Core Developer, expressed concerns about polluting the BIP repository with non-Bitcoin related specifications in response to a proposal to add HD generation of keypairs from a single seed for non-conflicting uses. Justus Ranvier countered by stating that intentionally making a useful technology less useful due to difficulties in assigning non-colliding numbers was a strange approach to software engineering. Justus Ranvier is associated with the Open Bitcoin Privacy Project, which promotes financial privacy and anonymity through the use of Bitcoin.On June 30, 2015, Justus Ranvier proposed a Bitmessage address derivation method based on BIP-43 developed by Monetas. This method allows Bitmessage users to generate addresses from a seed, providing eternal key backups and enabling future use cases. Monetas proposed this method as a BIP to reserve a purpose code. The proposal was made on the bitcoin-dev mailing list and included links to the relevant GitHub pages and contact details.Overall, the discussions on the bitcoin-dev mailing list revolved around the management of purpose codes, registry control, and the benefits and drawbacks of different approaches to maintain competing registries for different companies and P2P chains. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Scaling-Bitcoin-conference-micro-report.xml b/static/bitcoin-dev/Sept_2015/combined_Scaling-Bitcoin-conference-micro-report.xml index f166cedfc1..632d0ce5cc 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Scaling-Bitcoin-conference-micro-report.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Scaling-Bitcoin-conference-micro-report.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Scaling Bitcoin conference micro-report - 2023-08-01T16:09:59.803224+00:00 + 2025-10-11T21:55:49.176512+00:00 + python-feedgen Milly Bitcoin 2015-09-21 11:45:41+00:00 @@ -179,13 +180,13 @@ - python-feedgen + 2 Combined summary - Scaling Bitcoin conference micro-report - 2023-08-01T16:09:59.803224+00:00 + 2025-10-11T21:55:49.176731+00:00 - The bitcoin-dev mailing list has been discussing various issues related to Bitcoin's direction and governance. One major concern is the perceived control that developers and miners have over the decision-making process, which has led to speculation about the future of Bitcoin. The lack of clarity and resolution on important topics, such as the block size debate, has left Bitcoin in a state of uncertainty.In one email thread, the conversation veers off-topic and delves into discussions about gun control and piracy, which are not directly related to Bitcoin development. The sender argues that Bitcoin lacks a support system like marijuana or guns, making it vulnerable to legal attacks. They suggest that if Bitcoin had its own support system, it would be better equipped to defend itself.The threat model of Bitcoin is also a topic of discussion, with debates about the potential threats faced by the cryptocurrency. Some argue that governments pose a significant threat and could potentially launch a 51% attack to end Bitcoin usage in their territories. Others believe that the best defense against government interference is popularity and growth.There are ongoing debates within the bitcoin-dev community about increasing the block size limit to address scalability issues. Different proposals and metrics, such as BTCDaysDestroyed and net-UTXO, have been considered. However, there is no consensus on the exact numbers or the need for a second hard fork in the future.Despite the disagreements, the participants hope that these conversations will lead to concrete proposals that can be tested and implemented. They look forward to the upcoming Hong Kong workshop where these proposals can be further discussed and simulated. 2015-09-21T11:45:41+00:00 + The bitcoin-dev mailing list has been discussing various issues related to Bitcoin's direction and governance. One major concern is the perceived control that developers and miners have over the decision-making process, which has led to speculation about the future of Bitcoin. The lack of clarity and resolution on important topics, such as the block size debate, has left Bitcoin in a state of uncertainty.In one email thread, the conversation veers off-topic and delves into discussions about gun control and piracy, which are not directly related to Bitcoin development. The sender argues that Bitcoin lacks a support system like marijuana or guns, making it vulnerable to legal attacks. They suggest that if Bitcoin had its own support system, it would be better equipped to defend itself.The threat model of Bitcoin is also a topic of discussion, with debates about the potential threats faced by the cryptocurrency. Some argue that governments pose a significant threat and could potentially launch a 51% attack to end Bitcoin usage in their territories. Others believe that the best defense against government interference is popularity and growth.There are ongoing debates within the bitcoin-dev community about increasing the block size limit to address scalability issues. Different proposals and metrics, such as BTCDaysDestroyed and net-UTXO, have been considered. However, there is no consensus on the exact numbers or the need for a second hard fork in the future.Despite the disagreements, the participants hope that these conversations will lead to concrete proposals that can be tested and implemented. They look forward to the upcoming Hong Kong workshop where these proposals can be further discussed and simulated. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Short-review-of-previously-proposed-exotic-SIGHASH-types.xml b/static/bitcoin-dev/Sept_2015/combined_Short-review-of-previously-proposed-exotic-SIGHASH-types.xml index 12210312da..222ed39f09 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Short-review-of-previously-proposed-exotic-SIGHASH-types.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Short-review-of-previously-proposed-exotic-SIGHASH-types.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Short review of previously-proposed exotic SIGHASH types - 2023-08-01T15:51:47.413315+00:00 + 2025-10-11T21:55:55.547747+00:00 + python-feedgen Peter Todd 2015-09-01 06:54:42+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Short review of previously-proposed exotic SIGHASH types - 2023-08-01T15:51:47.413315+00:00 + 2025-10-11T21:55:55.547905+00:00 - In a bitcoin-dev email thread, Bryan Bishop provided a review of proposed and exotic SIGHASH types. Among them was the SIGHASH_MULTIPLE and petertodd's suggestion of SIGHASH_DONT_SIGN_TXID to make OP_CODESEPARATOR more useful. Another idea presented was the "meta sighash" which involves using code to build up the signature with OP_CODESEPARATOR. The email also included a digital signature attachment from Peter Todd.On August 30th, 2015, Bryan Bishop posted a message on bitcoin-dev regarding a proposal for new SIGHASH types. The proposed types include SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, SIGHASH_WITHOUT_INPUT_TXID, SIGHASH_WITHOUT_INPUT_INDEX, SIGHASH_WITHOUT_INPUT_SEQUENCE, SIGHASH_WITHOUT_OUTPUT_SCRIPTPUBKEY, SIGHASH_WITHOUT_OUTPUT_VALUE, SIGHASH_WITHOUT_INPUTS, SIGHASH_WITHOUT_OUTPUTS, SIGHASH_WITHOUT_INPUT_SELF, SIGHASH_WITHOUT_OUTPUT_SELF, SIGHASH_WITHOUT_TX_VERSION, and SIGHASH_WITHOUT_TX_LOCKTIME. A link to the proposal can be found in the post. Another user thanks Bishop for his summary of the proposal but expresses concern that it may not allow for fine adjustment for each input and output separately, which raises questions about whether the proposal truly enables any seen or unforeseen use case of the CTransactionSignatureSerializer.There have been multiple previously-proposed and exotic SIGHASH types. Some of these include SIGHASH_MULTIPLE, SIGHASH_LIST, and SIGHASH_WITHINPUTVALUE, which were discussed on bitcointalk.org. Another proposed type is SIGHASH_NOINPUT, which is mentioned in a paper about the Lightning Network and also has commits on Github. There are also proposals for SIGHASH_NORMALIZED and SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY. Furthermore, there have been suggestions for new types such as SIGHASH_SIGN_STACK_ELEMENT, SIGHASH_DONT_SIGN_TXID, SIGHASH_DANGEROUSLYPROMISCUOUS, SIGHASH_DOUBLE, SIGHASH_NLOCKTIMEVERIFY, SIGHASH_SUM, and even SIGHASH_UNICORN. These different types could potentially be useful for different purposes. 2015-09-01T06:54:42+00:00 + In a bitcoin-dev email thread, Bryan Bishop provided a review of proposed and exotic SIGHASH types. Among them was the SIGHASH_MULTIPLE and petertodd's suggestion of SIGHASH_DONT_SIGN_TXID to make OP_CODESEPARATOR more useful. Another idea presented was the "meta sighash" which involves using code to build up the signature with OP_CODESEPARATOR. The email also included a digital signature attachment from Peter Todd.On August 30th, 2015, Bryan Bishop posted a message on bitcoin-dev regarding a proposal for new SIGHASH types. The proposed types include SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, SIGHASH_WITHOUT_INPUT_TXID, SIGHASH_WITHOUT_INPUT_INDEX, SIGHASH_WITHOUT_INPUT_SEQUENCE, SIGHASH_WITHOUT_OUTPUT_SCRIPTPUBKEY, SIGHASH_WITHOUT_OUTPUT_VALUE, SIGHASH_WITHOUT_INPUTS, SIGHASH_WITHOUT_OUTPUTS, SIGHASH_WITHOUT_INPUT_SELF, SIGHASH_WITHOUT_OUTPUT_SELF, SIGHASH_WITHOUT_TX_VERSION, and SIGHASH_WITHOUT_TX_LOCKTIME. A link to the proposal can be found in the post. Another user thanks Bishop for his summary of the proposal but expresses concern that it may not allow for fine adjustment for each input and output separately, which raises questions about whether the proposal truly enables any seen or unforeseen use case of the CTransactionSignatureSerializer.There have been multiple previously-proposed and exotic SIGHASH types. Some of these include SIGHASH_MULTIPLE, SIGHASH_LIST, and SIGHASH_WITHINPUTVALUE, which were discussed on bitcointalk.org. Another proposed type is SIGHASH_NOINPUT, which is mentioned in a paper about the Lightning Network and also has commits on Github. There are also proposals for SIGHASH_NORMALIZED and SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY. Furthermore, there have been suggestions for new types such as SIGHASH_SIGN_STACK_ELEMENT, SIGHASH_DONT_SIGN_TXID, SIGHASH_DANGEROUSLYPROMISCUOUS, SIGHASH_DOUBLE, SIGHASH_NLOCKTIMEVERIFY, SIGHASH_SUM, and even SIGHASH_UNICORN. These different types could potentially be useful for different purposes. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Torrent-style-new-block-propagation-on-Merkle-trees.xml b/static/bitcoin-dev/Sept_2015/combined_Torrent-style-new-block-propagation-on-Merkle-trees.xml index 1241de8087..5558eaf33a 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Torrent-style-new-block-propagation-on-Merkle-trees.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Torrent-style-new-block-propagation-on-Merkle-trees.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Torrent-style new-block propagation on Merkle trees - 2023-08-01T16:15:27.056369+00:00 + 2025-10-11T21:55:53.424873+00:00 + python-feedgen Tier Nolan 2015-09-24 08:52:34+00:00 @@ -15,13 +16,13 @@ - python-feedgen + 2 Combined summary - Torrent-style new-block propagation on Merkle trees - 2023-08-01T16:15:27.056369+00:00 + 2025-10-11T21:55:53.425013+00:00 - On September 24, 2015, Jonathan Toomim from Toomim Bros initiated a discussion on the Bitcoin-dev mailing list regarding the current block propagation algorithm used in Bitcoin. The algorithm involves a node mining a block and notifying its peers about the new block using an "inv" message. Peers respond by requesting the block using a "getdata" [hash] message. The node then sends out the block to all eight peers simultaneously. Once a peer completes the download, it verifies the block and proceeds to the next step.Currently, mining pools connect to the "fast relay network," which is designed for efficient block distribution. Miners run both a normal full node and a relay node on the same computer. The full node informs the relay node whenever it receives a new transaction, and the relay node requests the full transaction. The relay node shares information about the transaction with its relay peers, but only provides the hash and a 4-byte key. Each relay node maintains a mapping of transaction IDs to keys for each peer, removing entries once the transaction is included in a block. When a block is discovered, the local node sends it to the relay node, which forwards it to all peers in a compact form. The block is sent as a list of keys, and full transactions are only sent for unknown transactions. Upon receiving a block, the relay node verifies the proof-of-work (POW) but does not perform transaction validation. It forwards the block to the local full node for validation. This prevents a denial-of-service attack where invalid blocks could be sent to the relay node, causing it to be kicked by the local full node. If all transactions are already known, the relay node can forward a block with just 4 bytes per transaction, further optimizing the process.A proposal was made on the Bitcoin-dev mailing list to improve the block propagation algorithm. The existing algorithm is slow and requires a peer to possess the full block before uploading it to other peers. The proposed algorithm draws inspiration from Bittorrent and suggests that a seed node will mine a block, notify peers about the new block, and send out the block header. Leech peers will then verify the block header, request specific rows of the transaction Merkle tree, and receive leaves from the seed node. After confirming POW and hash/data integrity, leeches start sharing chunks of data instead of waiting for the complete block. The proposed algorithm is more complex but offers bandwidth-saving opportunities and optimization by caching transactions and reconstructing the transaction order. However, it may not always yield better performance when the bandwidth to ping latency ratio is high compared to the block size.In another discussion on the Bitcoin-dev mailing list, user jtoomim proposed the idea of using a protocol for parallelized and decentralized resource supply. Although the specific resources referred to by jtoomim are unclear, this proposal has the potential to enhance efficiency and distribution of these resources. The discussion regarding this proposal is ongoing. 2015-09-24T08:52:34+00:00 + On September 24, 2015, Jonathan Toomim from Toomim Bros initiated a discussion on the Bitcoin-dev mailing list regarding the current block propagation algorithm used in Bitcoin. The algorithm involves a node mining a block and notifying its peers about the new block using an "inv" message. Peers respond by requesting the block using a "getdata" [hash] message. The node then sends out the block to all eight peers simultaneously. Once a peer completes the download, it verifies the block and proceeds to the next step.Currently, mining pools connect to the "fast relay network," which is designed for efficient block distribution. Miners run both a normal full node and a relay node on the same computer. The full node informs the relay node whenever it receives a new transaction, and the relay node requests the full transaction. The relay node shares information about the transaction with its relay peers, but only provides the hash and a 4-byte key. Each relay node maintains a mapping of transaction IDs to keys for each peer, removing entries once the transaction is included in a block. When a block is discovered, the local node sends it to the relay node, which forwards it to all peers in a compact form. The block is sent as a list of keys, and full transactions are only sent for unknown transactions. Upon receiving a block, the relay node verifies the proof-of-work (POW) but does not perform transaction validation. It forwards the block to the local full node for validation. This prevents a denial-of-service attack where invalid blocks could be sent to the relay node, causing it to be kicked by the local full node. If all transactions are already known, the relay node can forward a block with just 4 bytes per transaction, further optimizing the process.A proposal was made on the Bitcoin-dev mailing list to improve the block propagation algorithm. The existing algorithm is slow and requires a peer to possess the full block before uploading it to other peers. The proposed algorithm draws inspiration from Bittorrent and suggests that a seed node will mine a block, notify peers about the new block, and send out the block header. Leech peers will then verify the block header, request specific rows of the transaction Merkle tree, and receive leaves from the seed node. After confirming POW and hash/data integrity, leeches start sharing chunks of data instead of waiting for the complete block. The proposed algorithm is more complex but offers bandwidth-saving opportunities and optimization by caching transactions and reconstructing the transaction order. However, it may not always yield better performance when the bandwidth to ping latency ratio is high compared to the block size.In another discussion on the Bitcoin-dev mailing list, user jtoomim proposed the idea of using a protocol for parallelized and decentralized resource supply. Although the specific resources referred to by jtoomim are unclear, this proposal has the potential to enhance efficiency and distribution of these resources. The discussion regarding this proposal is ongoing. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_URI-scheme-for-signing-and-verifying-messages.xml b/static/bitcoin-dev/Sept_2015/combined_URI-scheme-for-signing-and-verifying-messages.xml index af44a58fbb..1c1faf105d 100644 --- a/static/bitcoin-dev/Sept_2015/combined_URI-scheme-for-signing-and-verifying-messages.xml +++ b/static/bitcoin-dev/Sept_2015/combined_URI-scheme-for-signing-and-verifying-messages.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - URI scheme for signing and verifying messages - 2023-08-01T16:06:30.601741+00:00 + 2025-10-11T21:55:19.438618+00:00 + python-feedgen Arthur - bitcoin-fr.io 2015-09-15 13:21:56+00:00 @@ -27,13 +28,13 @@ - python-feedgen + 2 Combined summary - URI scheme for signing and verifying messages - 2023-08-01T16:06:30.601741+00:00 + 2025-10-11T21:55:19.438791+00:00 - Luke Dashjr expressed concerns about the current signed message system in Bitcoin, stating that it is commonly used in insecure cases where it doesn't work properly. He suggested that a new method should be developed to avoid using the same key for signing transactions. Additionally, he mentioned that addresses are losing their importance due to the payment protocol, so designing an entire authentication system may be necessary. Arthur from bitcoin-fr.io proposed a URI scheme to make it easier for users to access existing tools, including the current signing process. However, Luke Dashjr cautioned against making the existing signatures even easier, as it could increase overall risk and make incompatible uses more accepted. Instead, he recommended focusing on satisfying existing use cases with a safe signature first. Regarding privacy concerns, Luke explained that the signed message only proves that the person who received payment with the address agrees to a given message/contract. It does not prove that they still have the bitcoins received. This is because the UTXO representing the bitcoins in the wallet is not associated with the address itself and can be redeemed by the wallet for unrelated transactions. While there are some good use cases for the current signed messages, they appear to be in the minority. Implementing any URI-based signing could actually make them more difficult. In September 2015, Arthur proposed the idea of a URI scheme to request or verify a signature as easily as requesting payment using a bitcoin URI scheme (BIP0021). He suggested that this could become available in most bitcoin clients that support message signing/verifying and payment URLs. To gain consensus, he proposed going through a BIP and presented his idea publicly before drafting a BIP and reference implementation. Luke Dashjr responded by suggesting that the whole signed message process needs to be rethought, as it is commonly used in insecure cases and does not work for proving ownership or sending bitcoins. He also noted that using the same key for signing transactions is not ideal. Arthur's proposal for the URI scheme aims to simplify the process of requesting and verifying signatures, similar to the BIP0021 bitcoin URI scheme for requesting payments. He suggests that it should require manual approval from the user, similar to BIP0021, and could use the same format or a different one. Bouquet plans to post a topic on the Bitcointalk forum for further discussion. 2015-09-15T13:21:56+00:00 + Luke Dashjr expressed concerns about the current signed message system in Bitcoin, stating that it is commonly used in insecure cases where it doesn't work properly. He suggested that a new method should be developed to avoid using the same key for signing transactions. Additionally, he mentioned that addresses are losing their importance due to the payment protocol, so designing an entire authentication system may be necessary. Arthur from bitcoin-fr.io proposed a URI scheme to make it easier for users to access existing tools, including the current signing process. However, Luke Dashjr cautioned against making the existing signatures even easier, as it could increase overall risk and make incompatible uses more accepted. Instead, he recommended focusing on satisfying existing use cases with a safe signature first. Regarding privacy concerns, Luke explained that the signed message only proves that the person who received payment with the address agrees to a given message/contract. It does not prove that they still have the bitcoins received. This is because the UTXO representing the bitcoins in the wallet is not associated with the address itself and can be redeemed by the wallet for unrelated transactions. While there are some good use cases for the current signed messages, they appear to be in the minority. Implementing any URI-based signing could actually make them more difficult. In September 2015, Arthur proposed the idea of a URI scheme to request or verify a signature as easily as requesting payment using a bitcoin URI scheme (BIP0021). He suggested that this could become available in most bitcoin clients that support message signing/verifying and payment URLs. To gain consensus, he proposed going through a BIP and presented his idea publicly before drafting a BIP and reference implementation. Luke Dashjr responded by suggesting that the whole signed message process needs to be rethought, as it is commonly used in insecure cases and does not work for proving ownership or sending bitcoins. He also noted that using the same key for signing transactions is not ideal. Arthur's proposal for the URI scheme aims to simplify the process of requesting and verifying signatures, similar to the BIP0021 bitcoin URI scheme for requesting payments. He suggests that it should require manual approval from the user, similar to BIP0021, and could use the same format or a different one. Bouquet plans to post a topic on the Bitcointalk forum for further discussion. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Versionbits-BIP-009-minor-revision-proposal-.xml b/static/bitcoin-dev/Sept_2015/combined_Versionbits-BIP-009-minor-revision-proposal-.xml index aae2fc2276..4f2efddd0c 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Versionbits-BIP-009-minor-revision-proposal-.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Versionbits-BIP-009-minor-revision-proposal-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Versionbits BIP (009) minor revision proposal. - 2023-08-01T16:26:12.381254+00:00 + 2025-10-11T21:55:08.821923+00:00 + python-feedgen Rusty Russell 2015-10-02 01:22:14+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Versionbits BIP (009) minor revision proposal. - 2023-08-01T16:26:12.381254+00:00 + 2025-10-11T21:55:08.822077+00:00 - Gregory Maxwell and Rusty Russell had a discussion about the possibility of requiring a bit to be set during the soft fork activation period. This would allow thin clients to reject blocks from non-upgraded miners. However, they decided against this proposal as it would cause warnings on older clients. Instead, they focused on upgrading versionbits and opened a PullReq for the "keep setting bit until activation" proposal.The conversation also explored the idea of making a BIP deployment optional but recommended for the first time. This would help collect valuable data to identify faulty implementations and bugs. It was suggested that a more sophisticated signaling mechanism could be introduced in the future to provide informative messages to end-users regarding changes and direct them to resources for learning about new features.There was a suggestion to require setting the bit for a period of time after rule enforcement begins, without actually enforcing the bit. This would allow thin clients to approach these blocks with skepticism. However, implementing this later would trigger warnings on older clients who would see the bit as representing a new soft fork. The simplest solution proposed was to have miners continue setting the bit for another 2016 blocks, which could potentially become a consensus rule if necessary.Gregory Maxwell argued that the bit can be easily checked by thin clients to reject blocks from non-upgraded miners post-switch. A middle ground solution was proposed to require setting the bit for a period of time after rule enforcement begins, but only enforce the validity of the block under new rules. However, this would add another state and trigger warnings on older clients if implemented later. Miners would need to keep setting the bit for another 2016 blocks to implement this solution, which could become a consensus rule if needed. Rusty concluded the discussion with a humorous quote.The context also discusses the challenge of determining whether miners are enforcing new rules without relying on someone mining a block that breaks the rule. Hard forks come with greater risks and disruptions, so the author suggests that an awareness campaign can help address concerns about older clients. The Version Bits mechanism is not a 'voting' system but a deployment mechanism for uncontroversial changes, measuring adoption before activation. It is most useful for adding default settings in product releases. The author emphasizes the importance of smooth transitions and acknowledges the reality that explicit acknowledgment of enforcement may not be possible.Rusty Russell raised the issue that the current BIP has miners turning off the bit as soon as it's locked in, making network adoption less visible. He suggested that miners should keep setting the bit for another 2016 blocks after activation and have a consensus rule that rejects blocks without the bit. This would "force" upgrades on the last remaining miners. However, this immediate bit forcing was seen as an advantage of versionbits over prior work.In another discussion, Pieter and Eric noted that miners turn off the bit as soon as it's locked in, which reduces network adoption visibility. Rusty did not propose an alternative suggestion but mentioned that miners should keep setting the bit for 2016 blocks after activation. If this idea proves successful, they can proceed with it. According to BIP-0009, software should begin by setting the bit in all mined blocks until it is resolved. If the bit is set in 1916 or more of the 2016 blocks within a retarget period, it becomes 'locked-in,' and miners should continue setting the bit for visibility. The consensus rules related to the locked-in soft fork will be enforced in the second retarget period, allowing the remaining 5% to upgrade. At the activation block and after, miners should stop setting the bit, which can potentially be reused for a different soft fork. 2015-10-02T01:22:14+00:00 + Gregory Maxwell and Rusty Russell had a discussion about the possibility of requiring a bit to be set during the soft fork activation period. This would allow thin clients to reject blocks from non-upgraded miners. However, they decided against this proposal as it would cause warnings on older clients. Instead, they focused on upgrading versionbits and opened a PullReq for the "keep setting bit until activation" proposal.The conversation also explored the idea of making a BIP deployment optional but recommended for the first time. This would help collect valuable data to identify faulty implementations and bugs. It was suggested that a more sophisticated signaling mechanism could be introduced in the future to provide informative messages to end-users regarding changes and direct them to resources for learning about new features.There was a suggestion to require setting the bit for a period of time after rule enforcement begins, without actually enforcing the bit. This would allow thin clients to approach these blocks with skepticism. However, implementing this later would trigger warnings on older clients who would see the bit as representing a new soft fork. The simplest solution proposed was to have miners continue setting the bit for another 2016 blocks, which could potentially become a consensus rule if necessary.Gregory Maxwell argued that the bit can be easily checked by thin clients to reject blocks from non-upgraded miners post-switch. A middle ground solution was proposed to require setting the bit for a period of time after rule enforcement begins, but only enforce the validity of the block under new rules. However, this would add another state and trigger warnings on older clients if implemented later. Miners would need to keep setting the bit for another 2016 blocks to implement this solution, which could become a consensus rule if needed. Rusty concluded the discussion with a humorous quote.The context also discusses the challenge of determining whether miners are enforcing new rules without relying on someone mining a block that breaks the rule. Hard forks come with greater risks and disruptions, so the author suggests that an awareness campaign can help address concerns about older clients. The Version Bits mechanism is not a 'voting' system but a deployment mechanism for uncontroversial changes, measuring adoption before activation. It is most useful for adding default settings in product releases. The author emphasizes the importance of smooth transitions and acknowledges the reality that explicit acknowledgment of enforcement may not be possible.Rusty Russell raised the issue that the current BIP has miners turning off the bit as soon as it's locked in, making network adoption less visible. He suggested that miners should keep setting the bit for another 2016 blocks after activation and have a consensus rule that rejects blocks without the bit. This would "force" upgrades on the last remaining miners. However, this immediate bit forcing was seen as an advantage of versionbits over prior work.In another discussion, Pieter and Eric noted that miners turn off the bit as soon as it's locked in, which reduces network adoption visibility. Rusty did not propose an alternative suggestion but mentioned that miners should keep setting the bit for 2016 blocks after activation. If this idea proves successful, they can proceed with it. According to BIP-0009, software should begin by setting the bit in all mined blocks until it is resolved. If the bit is set in 1916 or more of the 2016 blocks within a retarget period, it becomes 'locked-in,' and miners should continue setting the bit for visibility. The consensus rules related to the locked-in soft fork will be enforced in the second retarget period, allowing the remaining 5% to upgrade. At the activation block and after, miners should stop setting the bit, which can potentially be reused for a different soft fork. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Weak-block-thoughts-.xml b/static/bitcoin-dev/Sept_2015/combined_Weak-block-thoughts-.xml index 3ce30cbcf2..8507f749d2 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Weak-block-thoughts-.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Weak-block-thoughts-.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Weak block thoughts... - 2023-08-01T16:14:43.630929+00:00 + 2025-10-11T21:54:11.478594+00:00 + python-feedgen Jonathan Toomim (Toomim Bros) 2015-09-28 13:30:22+00:00 @@ -75,13 +76,13 @@ - python-feedgen + 2 Combined summary - Weak block thoughts... - 2023-08-01T16:14:43.631929+00:00 + 2025-10-11T21:54:11.478770+00:00 - The concept of 'weak blocks' has gained attention in various forums, including the Bitcoin forum, Linux Foundation mailing lists, and Bitcoin Wizards logs. Proposed by Rusty, weak blocks aim to improve the efficiency of block propagation in the Bitcoin network. Discussions and proposals on weak blocks have been ongoing for years, and recently, they have gained further traction at ScalingBitcoin events.Weak blocks function by pre-announcing blocks before solving the proof-of-work puzzle. These blocks are then rapidly validated by peers, resulting in quicker block propagation once a full-difficulty block is found. Miners are incentivized to include fee-paying transactions in their blocks instead of mining empty ones. While miners can attempt to avoid validation work by utilizing a weak block announced by someone else, they would still need to mine empty blocks between finding a full block and the next weak block announcement from a fully-validating miner.The introduction of weak block announcements provides transaction creators with insights into the likelihood of their transactions being confirmed in the next block. If implemented correctly, weak blocks should not significantly increase bandwidth or CPU usage. Multiple weak blocks at any given time are likely to contain the same transactions, minimizing resource strain. Furthermore, weak blocks have the potential to increase revenue for miners by encouraging the creation of blocks with fee-paying transactions.For those interested in learning more about weak blocks, transcripts from Scaling Bitcoin discussions on this subject can be found online. Weak blocks offer a promising solution to enhance mining efficiency and mitigate the risk of DoS attacks within the Bitcoin network. 2015-09-28T13:30:22+00:00 + The concept of 'weak blocks' has gained attention in various forums, including the Bitcoin forum, Linux Foundation mailing lists, and Bitcoin Wizards logs. Proposed by Rusty, weak blocks aim to improve the efficiency of block propagation in the Bitcoin network. Discussions and proposals on weak blocks have been ongoing for years, and recently, they have gained further traction at ScalingBitcoin events.Weak blocks function by pre-announcing blocks before solving the proof-of-work puzzle. These blocks are then rapidly validated by peers, resulting in quicker block propagation once a full-difficulty block is found. Miners are incentivized to include fee-paying transactions in their blocks instead of mining empty ones. While miners can attempt to avoid validation work by utilizing a weak block announced by someone else, they would still need to mine empty blocks between finding a full block and the next weak block announcement from a fully-validating miner.The introduction of weak block announcements provides transaction creators with insights into the likelihood of their transactions being confirmed in the next block. If implemented correctly, weak blocks should not significantly increase bandwidth or CPU usage. Multiple weak blocks at any given time are likely to contain the same transactions, minimizing resource strain. Furthermore, weak blocks have the potential to increase revenue for miners by encouraging the creation of blocks with fee-paying transactions.For those interested in learning more about weak blocks, transcripts from Scaling Bitcoin discussions on this subject can be found online. Weak blocks offer a promising solution to enhance mining efficiency and mitigate the risk of DoS attacks within the Bitcoin network. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Weekly-development-meetings-on-IRC-schedule.xml b/static/bitcoin-dev/Sept_2015/combined_Weekly-development-meetings-on-IRC-schedule.xml index 110c39483b..9efc4fc4a1 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Weekly-development-meetings-on-IRC-schedule.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Weekly-development-meetings-on-IRC-schedule.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Weekly development meetings on IRC: schedule - 2023-08-01T16:13:41.852042+00:00 + 2025-10-11T21:55:06.694018+00:00 + python-feedgen Micha Bailey 2015-09-24 15:33:06+00:00 @@ -23,13 +24,13 @@ - python-feedgen + 2 Combined summary - Weekly development meetings on IRC: schedule - 2023-08-01T16:13:41.852042+00:00 + 2025-10-11T21:55:06.694158+00:00 - Bitcoin developers held a discussion in September 2015 regarding the timing of their weekly IRC meetings. Vincent Truong suggested a meeting time from 23:00 to 00:00 UTC which could accommodate participants from the US and Asia, but it may not be convenient for everyone. Another proposal was made by Jl2012 to review the timing on a weekly or monthly basis using a doodle vote. Wladimir J. van der Laan took the initiative to create a shared Google Calendar for the meetings, scheduling them on Thursdays at 19:00-20:00 UTC starting from September 24, 2015, with the timezone set as Reykyavik (Iceland), which is UTC+0. This calendar can be added to personal calendars, displaying the meeting time in the respective time zones.Initially, there were concerns raised by participants from Asia and Australia about the inconvenience of the meeting time due to the time difference. In response, it was suggested to shift the meeting time to 23:00 to 00:00 UTC, which would be more feasible for people in Asia. However, it was acknowledged that accommodating everyone's preferences is challenging, and a monthly meeting at a suitable time might be a better solution. The proposed time change was open for feedback specifically from individuals in Asia and Australia.The introduction of weekly IRC meetings for Bitcoin developers was met with agreement from the group. A shared Google Calendar was created, indicating that the meetings will take place every Thursday from 7:00-8:00 PM UTC, starting on September 24th. To address the concerns of participants located in China, Japan/Korea, and Australia, it was suggested to review the timing of the meetings on a weekly or monthly basis to ensure inclusivity. Additionally, there were requests for an agenda to be published before each meeting, particularly for those who need to wake up during inconvenient hours to participate. The IRC channel for bitcoin-dev is logged at bitcoinstats.com.In summary, a weekly IRC meeting has been scheduled for Bitcoin developers on Thursdays from 7:00-8:00 PM UTC starting from September 24th. A shared Google Calendar has been created to display the meeting time in different time zones. The initial timing of the meetings may not be ideal for participants in Asia and Australia, leading to suggestions of reviewing the timing regularly. Furthermore, there were requests for publishing an agenda before each meeting to determine its relevance for attendees, especially for those who need to make adjustments to their sleep schedules. The adoption of the weekly IRC meetings was positively received, and a suitable time slot was determined through the Doodle site. The first meeting will take place on September 24th, and the shared Google Calendar can be added to individual calendars to view the meeting time in respective time zones with the help of the provided button. 2015-09-24T15:33:06+00:00 + Bitcoin developers held a discussion in September 2015 regarding the timing of their weekly IRC meetings. Vincent Truong suggested a meeting time from 23:00 to 00:00 UTC which could accommodate participants from the US and Asia, but it may not be convenient for everyone. Another proposal was made by Jl2012 to review the timing on a weekly or monthly basis using a doodle vote. Wladimir J. van der Laan took the initiative to create a shared Google Calendar for the meetings, scheduling them on Thursdays at 19:00-20:00 UTC starting from September 24, 2015, with the timezone set as Reykyavik (Iceland), which is UTC+0. This calendar can be added to personal calendars, displaying the meeting time in the respective time zones.Initially, there were concerns raised by participants from Asia and Australia about the inconvenience of the meeting time due to the time difference. In response, it was suggested to shift the meeting time to 23:00 to 00:00 UTC, which would be more feasible for people in Asia. However, it was acknowledged that accommodating everyone's preferences is challenging, and a monthly meeting at a suitable time might be a better solution. The proposed time change was open for feedback specifically from individuals in Asia and Australia.The introduction of weekly IRC meetings for Bitcoin developers was met with agreement from the group. A shared Google Calendar was created, indicating that the meetings will take place every Thursday from 7:00-8:00 PM UTC, starting on September 24th. To address the concerns of participants located in China, Japan/Korea, and Australia, it was suggested to review the timing of the meetings on a weekly or monthly basis to ensure inclusivity. Additionally, there were requests for an agenda to be published before each meeting, particularly for those who need to wake up during inconvenient hours to participate. The IRC channel for bitcoin-dev is logged at bitcoinstats.com.In summary, a weekly IRC meeting has been scheduled for Bitcoin developers on Thursdays from 7:00-8:00 PM UTC starting from September 24th. A shared Google Calendar has been created to display the meeting time in different time zones. The initial timing of the meetings may not be ideal for participants in Asia and Australia, leading to suggestions of reviewing the timing regularly. Furthermore, there were requests for publishing an agenda before each meeting to determine its relevance for attendees, especially for those who need to make adjustments to their sleep schedules. The adoption of the weekly IRC meetings was positively received, and a suitable time slot was determined through the Doodle site. The first meeting will take place on September 24th, and the shared Google Calendar can be added to individual calendars to view the meeting time in respective time zones with the help of the provided button. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Weekly-development-meetings-on-IRC.xml b/static/bitcoin-dev/Sept_2015/combined_Weekly-development-meetings-on-IRC.xml index 14fa1b7b2a..8aa815c85d 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Weekly-development-meetings-on-IRC.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Weekly-development-meetings-on-IRC.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Weekly development meetings on IRC - 2023-08-01T16:11:38.830673+00:00 + 2025-10-11T21:55:10.945625+00:00 + python-feedgen Wladimir J. van der Laan 2015-09-22 14:03:02+00:00 @@ -91,13 +92,13 @@ - python-feedgen + 2 Combined summary - Weekly development meetings on IRC - 2023-08-01T16:11:38.830673+00:00 + 2025-10-11T21:55:10.945812+00:00 - To determine the most popular time for the meeting, a Doodle poll was created by Jonasschnelli and preferences for days and times were requested. The results of the poll showed that Thursday from 19:00 to 20:00 UTC was the most convenient time for attendees. The conversation also touched on the topic of timezones and daylight saving time (DST). Btc Drak jokingly suggested the idea of hardforking time to improve it, but Gregory Maxwell pointed out that there is little global consistency regarding DST usage, making it difficult to use timezones that observe DST. Matt Corallo suggested using Google Calendar's timezone option, but noted that UTC is not available as an option. Btc Drak then suggested using Iceland time (UTC without DST) as an alternative.The inconvenience caused by clock-changing was also discussed, and the suggestion to quote an actual timezone of a specific area to avoid this inconvenience was mentioned. Tonal time was brought up as a consistent alternative. In addition to the discussion about meeting times and timezones, the email sent by someone offering their tech services for free included links to their projects, such as Litmocracy, Meme Racing, and webmastering The Voluntaryist, which now accepts Bitcoin. The email concluded with a quote from Satoshi Nakamoto, emphasizing the importance of playing by the rules for profitability.Overall, the main focus of the conversation was finding a suitable time for a regular developer meeting in #bitcoin-dev. The developers aimed to accommodate different timezones, address the challenges posed by DST, and make use of options available in Google Calendar. The objective of establishing a regular meeting time was to encourage more people to attend and facilitate discussions of current issues within the Bitcoin community. 2015-09-22T14:03:02+00:00 + To determine the most popular time for the meeting, a Doodle poll was created by Jonasschnelli and preferences for days and times were requested. The results of the poll showed that Thursday from 19:00 to 20:00 UTC was the most convenient time for attendees. The conversation also touched on the topic of timezones and daylight saving time (DST). Btc Drak jokingly suggested the idea of hardforking time to improve it, but Gregory Maxwell pointed out that there is little global consistency regarding DST usage, making it difficult to use timezones that observe DST. Matt Corallo suggested using Google Calendar's timezone option, but noted that UTC is not available as an option. Btc Drak then suggested using Iceland time (UTC without DST) as an alternative.The inconvenience caused by clock-changing was also discussed, and the suggestion to quote an actual timezone of a specific area to avoid this inconvenience was mentioned. Tonal time was brought up as a consistent alternative. In addition to the discussion about meeting times and timezones, the email sent by someone offering their tech services for free included links to their projects, such as Litmocracy, Meme Racing, and webmastering The Voluntaryist, which now accepts Bitcoin. The email concluded with a quote from Satoshi Nakamoto, emphasizing the importance of playing by the rules for profitability.Overall, the main focus of the conversation was finding a suitable time for a regular developer meeting in #bitcoin-dev. The developers aimed to accommodate different timezones, address the challenges posed by DST, and make use of options available in Google Calendar. The objective of establishing a regular meeting time was to encourage more people to attend and facilitate discussions of current issues within the Bitcoin community. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Yet-another-blocklimit-proposal-compromise.xml b/static/bitcoin-dev/Sept_2015/combined_Yet-another-blocklimit-proposal-compromise.xml index f6003f740b..518683efb9 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Yet-another-blocklimit-proposal-compromise.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Yet-another-blocklimit-proposal-compromise.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Yet another blocklimit proposal / compromise - 2023-08-01T16:03:38.803961+00:00 + 2025-10-11T21:54:43.311692+00:00 + python-feedgen Jorge Timón 2015-09-11 18:17:19+00:00 @@ -31,13 +32,13 @@ - python-feedgen + 2 Combined summary - Yet another blocklimit proposal / compromise - 2023-08-01T16:03:38.803961+00:00 + 2025-10-11T21:54:43.311855+00:00 - In a discussion about Bitcoin security, Marcel Jamin suggests that increasing network connection requirements might decrease mining centralization. However, he argues that not being well connected with other miners is a problem for the rest of the miners, rather than Chinese miners who are the majority in terms of hashrate. Adam Back notes that full nodes play an important role in enforcing consensus rules and ensuring decentralization, and it is important to make it reasonably convenient to run full nodes for decentralization security.Back clarifies that the 8MB cap proposed by Chinese miners was due to current network infrastructure limitations, not a lack of interest in scaling. In a 2015 email, he discussed the importance of maintaining economically dependent full nodes for Bitcoin security. He argued that it is crucial to define what "reasonably convenient" means in order to ensure decentralization security. Additionally, he suggested that node operators likely have headroom for larger blocks and increasing network connection requirements may even decrease mining centralization.Back also addressed the proposal for an 8MB block size cap from Chinese miners, clarifying that it was due to limitations in current network infrastructure and what they felt would remain fair to all miners and node operators worldwide. He proposed a plan to gradually increase the block size from 2-4-8MB over a 4-year time frame, with a hard fork upgrade once everyone in the network has upgraded.The importance of economically dependent full nodes in maintaining Bitcoin security through consensus rules is emphasized in this email exchange. This ensures decentralization of policy and is different from miner full nodes. It is crucial that running full nodes remain convenient to maintain decentralization security. The Chinese miners' proposed 8MB cap was not meant to be a permanent solution but rather a limit based on current infrastructure. Back suggests a 2-4-8MB growth over four years, with economically dependent full nodes upgrading after a hard-fork upgrade.In another part of the email exchange, Marcel proposes assessing the technical possibility of block limits without driving up node costs too much. However, concerns are raised about further increasing mining centralization. The overlap between those who want to run serious mining operations and those who cannot afford an above-average internet connection is argued to be small. The discussion began with Marcel Jamin proposing an assessment of the current block limit to determine what is technically possible without increasing the cost of running a node too much. However, concerns were raised about the risk of further mining centralization. In response to this, someone suggested that the overlap between people who want to run a serious mining operation and those who cannot afford an above-average internet connection is very small.On September 9, 2015, Marcel Jamin proposed assessing the current technical possibility of block limits without increasing costs of running a node too much. It was suggested that most systems with a full node have some capacity left. However, there were concerns about the risk of further increasing mining centralization.The proposal suggests assessing the technical possibility of increasing the block limit without driving up the cost of running a full node too much. The determined block size limit will be set at the next reward halving and then doubled at every halving thereafter, reaching a hard limit of 8GB. This doubling every four years is expected to stay within technological growth predictions. The proposal is considered a compromise between Pieter's and Gavin's proposals, with an initial increase to start the growth and reaching 8GB in 2056 if starting with 8MB. The start date is set around mid-2016. The proposal suggests a simple and predictable approach where the block subsidy halves and the block size limit doubles. It may make sense to update the limit more often in-between based on a block's timestamp or for each difficulty period. 2015-09-11T18:17:19+00:00 + In a discussion about Bitcoin security, Marcel Jamin suggests that increasing network connection requirements might decrease mining centralization. However, he argues that not being well connected with other miners is a problem for the rest of the miners, rather than Chinese miners who are the majority in terms of hashrate. Adam Back notes that full nodes play an important role in enforcing consensus rules and ensuring decentralization, and it is important to make it reasonably convenient to run full nodes for decentralization security.Back clarifies that the 8MB cap proposed by Chinese miners was due to current network infrastructure limitations, not a lack of interest in scaling. In a 2015 email, he discussed the importance of maintaining economically dependent full nodes for Bitcoin security. He argued that it is crucial to define what "reasonably convenient" means in order to ensure decentralization security. Additionally, he suggested that node operators likely have headroom for larger blocks and increasing network connection requirements may even decrease mining centralization.Back also addressed the proposal for an 8MB block size cap from Chinese miners, clarifying that it was due to limitations in current network infrastructure and what they felt would remain fair to all miners and node operators worldwide. He proposed a plan to gradually increase the block size from 2-4-8MB over a 4-year time frame, with a hard fork upgrade once everyone in the network has upgraded.The importance of economically dependent full nodes in maintaining Bitcoin security through consensus rules is emphasized in this email exchange. This ensures decentralization of policy and is different from miner full nodes. It is crucial that running full nodes remain convenient to maintain decentralization security. The Chinese miners' proposed 8MB cap was not meant to be a permanent solution but rather a limit based on current infrastructure. Back suggests a 2-4-8MB growth over four years, with economically dependent full nodes upgrading after a hard-fork upgrade.In another part of the email exchange, Marcel proposes assessing the technical possibility of block limits without driving up node costs too much. However, concerns are raised about further increasing mining centralization. The overlap between those who want to run serious mining operations and those who cannot afford an above-average internet connection is argued to be small. The discussion began with Marcel Jamin proposing an assessment of the current block limit to determine what is technically possible without increasing the cost of running a node too much. However, concerns were raised about the risk of further mining centralization. In response to this, someone suggested that the overlap between people who want to run a serious mining operation and those who cannot afford an above-average internet connection is very small.On September 9, 2015, Marcel Jamin proposed assessing the current technical possibility of block limits without increasing costs of running a node too much. It was suggested that most systems with a full node have some capacity left. However, there were concerns about the risk of further increasing mining centralization.The proposal suggests assessing the technical possibility of increasing the block limit without driving up the cost of running a full node too much. The determined block size limit will be set at the next reward halving and then doubled at every halving thereafter, reaching a hard limit of 8GB. This doubling every four years is expected to stay within technological growth predictions. The proposal is considered a compromise between Pieter's and Gavin's proposals, with an initial increase to start the growth and reaching 8GB in 2056 if starting with 8MB. The start date is set around mid-2016. The proposal suggests a simple and predictable approach where the block subsidy halves and the block size limit doubles. It may make sense to update the limit more often in-between based on a block's timestamp or for each difficulty period. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_Your-Gmaxwell-exchange.xml b/static/bitcoin-dev/Sept_2015/combined_Your-Gmaxwell-exchange.xml index 6677e3ccbe..1da99a7c87 100644 --- a/static/bitcoin-dev/Sept_2015/combined_Your-Gmaxwell-exchange.xml +++ b/static/bitcoin-dev/Sept_2015/combined_Your-Gmaxwell-exchange.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - Your Gmaxwell exchange - 2023-08-01T15:49:46.075445+00:00 + 2025-10-11T21:54:45.435735+00:00 + python-feedgen Justus Ranvier 2015-09-02 18:51:08+00:00 @@ -115,13 +116,13 @@ - python-feedgen + 2 Combined summary - Your Gmaxwell exchange - 2023-08-01T15:49:46.076445+00:00 + 2025-10-11T21:54:45.435945+00:00 - In an email to the bitcoin-dev mailing list, Justus Ranvier outlined three essential properties that bitcoin users should have. Firstly, they should own their bitcoins and retain exclusive control over their balances. Secondly, their fraction of the bitcoin ledger must not be diluted. Lastly, users should be able to spend their coins without requiring permission from a third party. However, these properties are only possible if the system remains decentralized. Both miner and full node over-centralization could result in permission requirements to submit transactions, transactions being reversed without consent, and dilution of users' fractions of the ledger. Without decentralization, bitcoin is just an inefficient ledger database, and all of its attractive properties are derived from spreading responsibility as widely globally as possible.In a discussion on decentralized bitcoin development, Eric Voskuil argues against the idea of forking as a means of achieving decentralization. He believes that true decentralization requires actually doing so, and that even forking is a major commitment. He also notes that common consensus check code is available in several bitcoin implementations, and that the claim that this is outrageously difficult is misleading. In response to Voskuil's comments, another participant in the discussion argues that there is no requirement for there to be multiple interpretations of the consensus code, citing the existence of libbitcoinconsensus. They question why Bitcoin's survival would be predicated on reimplementation. Finally, Voskuil acknowledges that these issues apply to Bitcoin Core as well as other implementations.In an email exchange on the Bitcoin-dev mailing list, Monarch made a comment about the difficulty of software development with regards to decentralized bitcoin development. Dave Collins responded by stating that there have not been any btcd mainnet forks since it came out of alpha and that common consensus check code is now available in several bitcoin implementations. He claims that this is just engineering work that needs to get done if Bitcoin is to survive. Monarch then clarified that his comment was not intended as an attack against any specific software but rather to highlight the difficulty of working on decentralized bitcoin development. He noted that the use of CPP and OpenSSL can make it difficult to infer behavior and that there are likely more problems lurking in the transaction environment. However, these issues affect the Satoshi client as much as other implementations and do not support the premise that alternative implementations are inherently more difficult to develop.In a discussion on the bitcoin-dev mailing list, Dave Collins was curious about btcd mainnet forks that had occurred since it came out of alpha. However, he noted that there haven't been any such forks yet, although he didn't rule out the possibility of one happening in the future. He also clarified that his point was not to attack btcd, but rather to emphasize the difficulty of software development in this space.Collins pointed out that Bitcoin Core itself had experienced actual forks on the mainnet during the same period. He acknowledged that no developer is perfect and that mistakes are bound to happen from time to time. The bigger picture, however, is that the overall development process for cryptocurrency is challenging due to the complexity of the technology involved.One of the issues with developing cryptocurrency software is that it's difficult to know what behavior is inferred by the use of CPP and OpenSSL. Collins noted that the recent DER encoding consensus failure highlighted this fact. Additionally, there are likely other problems lurking in the transaction environment, which can be easy to overlook given how complex Bitcoin script can be. Overall, the conversation underscored the challenges that developers face when working with these cutting-edge technologies.The person asking the question in this context is interested to know about the supposed btcd mainnet forks that have occurred due to a consensus failure since it came out of alpha. The answer states that there hasn't been one so far, but there might be in the future, just as it can happen with Bitcoin Core as well. A potential instance was found due to fuzzing, which prompted an audit of the code base and resulted in improved test coverage in Bitcoin Core. However, Bitcoin Core has had actual forks on mainnet during the same period.The author believes that the community needs to take the reality seriously that an infrastructure built on a single implementation is incredibly fragile and prone to unintentional hard forks regardless of the existence of alternative implementations. The absence of real disaster prevention measures for unintentional incompatibilities between different versions of the same implementation adds to this fragility. It is mentioned that several improvements such as improved test coverage and more robust and modular code have already been made after the incident and that it has not ended poorly by any means.Furthermore, the post made by Monarch via bitcoin-dev is also referred to, where they state that even heroic attempts at making consensus-compatible re-implementations have ended rather poorly. Bitcoin-ruby and btcd have collectively had numerous consensus failures, some only recently found by fuzzing the scripting environment. There are more failures than publicly disclosed, and almost any failure can be leveraged to split the network and steal money.The 2015-09-02T18:51:08+00:00 + In an email to the bitcoin-dev mailing list, Justus Ranvier outlined three essential properties that bitcoin users should have. Firstly, they should own their bitcoins and retain exclusive control over their balances. Secondly, their fraction of the bitcoin ledger must not be diluted. Lastly, users should be able to spend their coins without requiring permission from a third party. However, these properties are only possible if the system remains decentralized. Both miner and full node over-centralization could result in permission requirements to submit transactions, transactions being reversed without consent, and dilution of users' fractions of the ledger. Without decentralization, bitcoin is just an inefficient ledger database, and all of its attractive properties are derived from spreading responsibility as widely globally as possible.In a discussion on decentralized bitcoin development, Eric Voskuil argues against the idea of forking as a means of achieving decentralization. He believes that true decentralization requires actually doing so, and that even forking is a major commitment. He also notes that common consensus check code is available in several bitcoin implementations, and that the claim that this is outrageously difficult is misleading. In response to Voskuil's comments, another participant in the discussion argues that there is no requirement for there to be multiple interpretations of the consensus code, citing the existence of libbitcoinconsensus. They question why Bitcoin's survival would be predicated on reimplementation. Finally, Voskuil acknowledges that these issues apply to Bitcoin Core as well as other implementations.In an email exchange on the Bitcoin-dev mailing list, Monarch made a comment about the difficulty of software development with regards to decentralized bitcoin development. Dave Collins responded by stating that there have not been any btcd mainnet forks since it came out of alpha and that common consensus check code is now available in several bitcoin implementations. He claims that this is just engineering work that needs to get done if Bitcoin is to survive. Monarch then clarified that his comment was not intended as an attack against any specific software but rather to highlight the difficulty of working on decentralized bitcoin development. He noted that the use of CPP and OpenSSL can make it difficult to infer behavior and that there are likely more problems lurking in the transaction environment. However, these issues affect the Satoshi client as much as other implementations and do not support the premise that alternative implementations are inherently more difficult to develop.In a discussion on the bitcoin-dev mailing list, Dave Collins was curious about btcd mainnet forks that had occurred since it came out of alpha. However, he noted that there haven't been any such forks yet, although he didn't rule out the possibility of one happening in the future. He also clarified that his point was not to attack btcd, but rather to emphasize the difficulty of software development in this space.Collins pointed out that Bitcoin Core itself had experienced actual forks on the mainnet during the same period. He acknowledged that no developer is perfect and that mistakes are bound to happen from time to time. The bigger picture, however, is that the overall development process for cryptocurrency is challenging due to the complexity of the technology involved.One of the issues with developing cryptocurrency software is that it's difficult to know what behavior is inferred by the use of CPP and OpenSSL. Collins noted that the recent DER encoding consensus failure highlighted this fact. Additionally, there are likely other problems lurking in the transaction environment, which can be easy to overlook given how complex Bitcoin script can be. Overall, the conversation underscored the challenges that developers face when working with these cutting-edge technologies.The person asking the question in this context is interested to know about the supposed btcd mainnet forks that have occurred due to a consensus failure since it came out of alpha. The answer states that there hasn't been one so far, but there might be in the future, just as it can happen with Bitcoin Core as well. A potential instance was found due to fuzzing, which prompted an audit of the code base and resulted in improved test coverage in Bitcoin Core. However, Bitcoin Core has had actual forks on mainnet during the same period.The author believes that the community needs to take the reality seriously that an infrastructure built on a single implementation is incredibly fragile and prone to unintentional hard forks regardless of the existence of alternative implementations. The absence of real disaster prevention measures for unintentional incompatibilities between different versions of the same implementation adds to this fragility. It is mentioned that several improvements such as improved test coverage and more robust and modular code have already been made after the incident and that it has not ended poorly by any means.Furthermore, the post made by Monarch via bitcoin-dev is also referred to, where they state that even heroic attempts at making consensus-compatible re-implementations have ended rather poorly. Bitcoin-ruby and btcd have collectively had numerous consensus failures, some only recently found by fuzzing the scripting environment. There are more failures than publicly disclosed, and almost any failure can be leveraged to split the network and steal money.The - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_block-size-pay-with-difficulty.xml b/static/bitcoin-dev/Sept_2015/combined_block-size-pay-with-difficulty.xml index dbf2d80fe6..6a5fe4a965 100644 --- a/static/bitcoin-dev/Sept_2015/combined_block-size-pay-with-difficulty.xml +++ b/static/bitcoin-dev/Sept_2015/combined_block-size-pay-with-difficulty.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - block size - pay with difficulty - 2023-08-01T15:58:36.230519+00:00 + 2025-10-11T21:54:28.464728+00:00 + python-feedgen Gregory Maxwell 2015-09-03 19:17:07+00:00 @@ -51,13 +52,13 @@ - python-feedgen + 2 Combined summary - block size - pay with difficulty - 2023-08-01T15:58:36.230519+00:00 + 2025-10-11T21:54:28.464901+00:00 - In an email conversation between Jorge Timón and Greg, they discuss a proposal by BtcDrak to use increased nBits to vote for permanently raising the block size. Jeff had previously made arguments against this proposal, but it appears that his arguments only apply to BtcDrak's proposal and not to Greg's original proposal where the block size is only increased for that specific block. The email ends with a request for everyone to speak specifically in order to catch important details like this.The conversation is about the feasibility of a difficulty penalty scheme in Bitcoin. Jeff Garzik appears to be of the opinion that such a scheme is not workable due to the unpredictability it would introduce to the block size and fee environment, making planning difficult for businesses. Gregory Maxwell disagrees with this assertion, arguing that most of the difficulty-based adjustments have small limits on the difficulty change and wouldn't cause significant changes in interblock times relative to orphaning. He also notes that pay-for-size schemes have been successfully used in some altcoins without adverse effects. The discussion also touches on proposals by BtcDrak and Greg Maxwell for increasing block size, with the former proposing permanent increases through voting while the latter suggests temporary increases only for specific blocks. The debate highlights the importance of predictability and stability in Bitcoin's markets and systems.Jeff Garzik advises against schemes that propose to pay with difficulty or hashpower to change block size. He argues that miners have a straightforward incentive: to deploy new hashpower as soon as possible. Requiring out-of-band collusion or idle hashpower on hand to change block size is both unrealistic and potentially harmful to the block size and fee market. Instead, Garzik suggests researching neutral, forward-looking incentives like pay-to-future-miner.In an email thread dated September 3, 2015, Jeff Garzik expressed concerns about the implementation of pay-with-diff for Bitcoin. He pointed out that users and miners would face difficulty in creating a stable block size and fee environment with this model. This would lead to unpredictability and chaos which are not good for markets and systems. The conclusion was either "not get used" or "volatility." Garzik also explained that paying with difficulty requires some amount of collusion if there is no idle hash power. Any miner paying with a higher difficulty would have to either self-increase their own difficulty at the possible opportunity cost of losing an entire block's income to another miner who doesn't care about changing the block size. The potential loss does not economically compensate for size increase gains in most cases when considering the variability of blocks and the associated fee income. The proposed scheme suggests increasing block size fast with difficulty over a narrow window. While the odds of producing a block are slightly reduced, the block produced if successful is more profitable, but only if there is a good supply of transactions that pay real fees comparable to those already taken. This trade-off exists currently with respect to orphaning risk, and miners still produce large blocks, with producing a larger block meaning greater utility despite the greater chance of not being successful due to orphaning. The risk from orphaning can be traded off for centralization advantage or by miners bypassing validation, issues which at least so far, we have no reason to believe exist for size-mediated schemes. Mining is not a race, and increasing difficulty does not put a miner at an expected return disadvantage compared to others as long as the income increases proportionally. Pay-for-size schemes have been successfully used in some altcoins without the effects that were suggested.The discussion focuses on the challenges of implementing pay-with-diff, which would require miners to adjust their hashing difficulty in order to change the block size. One issue is the need for collusion among miners, unless there is idle hashpower available, which is unlikely. The potential loss does not economically compensate for size increase gains in most cases, when considering the variability of blocks and associated fee income. In addition, businesses will face challenges in planning due to the unpredictability and volatility of the block size and fee environment. The conclusion is that pay-with-diff will either not be used or lead to radical short-term changes in block size and fees, making it difficult for all players to reason and plan.In a discussion amongst Bitcoin developers, the topic of paying with difficulty for increasing block size was brought up. It was noted that paying with a higher difficulty requires either idle hashpower or risking losing an entire block's income to another miner who doesn't care about changing the block size. The potential loss does not economically compensate for the gains in block size increase. The discussion continued on to say that miners have more to lose by paying with difficulty than they gain unless there is collusion amongst the entire network with ~90% certainty. In such a case, the network can collectively agree to increase the block period until the globally desired block size is reached. However, pay-with-difficulty will either not get used or lead to radical short-term block size and fee volatility. Overall 2015-09-03T19:17:07+00:00 + In an email conversation between Jorge Timón and Greg, they discuss a proposal by BtcDrak to use increased nBits to vote for permanently raising the block size. Jeff had previously made arguments against this proposal, but it appears that his arguments only apply to BtcDrak's proposal and not to Greg's original proposal where the block size is only increased for that specific block. The email ends with a request for everyone to speak specifically in order to catch important details like this.The conversation is about the feasibility of a difficulty penalty scheme in Bitcoin. Jeff Garzik appears to be of the opinion that such a scheme is not workable due to the unpredictability it would introduce to the block size and fee environment, making planning difficult for businesses. Gregory Maxwell disagrees with this assertion, arguing that most of the difficulty-based adjustments have small limits on the difficulty change and wouldn't cause significant changes in interblock times relative to orphaning. He also notes that pay-for-size schemes have been successfully used in some altcoins without adverse effects. The discussion also touches on proposals by BtcDrak and Greg Maxwell for increasing block size, with the former proposing permanent increases through voting while the latter suggests temporary increases only for specific blocks. The debate highlights the importance of predictability and stability in Bitcoin's markets and systems.Jeff Garzik advises against schemes that propose to pay with difficulty or hashpower to change block size. He argues that miners have a straightforward incentive: to deploy new hashpower as soon as possible. Requiring out-of-band collusion or idle hashpower on hand to change block size is both unrealistic and potentially harmful to the block size and fee market. Instead, Garzik suggests researching neutral, forward-looking incentives like pay-to-future-miner.In an email thread dated September 3, 2015, Jeff Garzik expressed concerns about the implementation of pay-with-diff for Bitcoin. He pointed out that users and miners would face difficulty in creating a stable block size and fee environment with this model. This would lead to unpredictability and chaos which are not good for markets and systems. The conclusion was either "not get used" or "volatility." Garzik also explained that paying with difficulty requires some amount of collusion if there is no idle hash power. Any miner paying with a higher difficulty would have to either self-increase their own difficulty at the possible opportunity cost of losing an entire block's income to another miner who doesn't care about changing the block size. The potential loss does not economically compensate for size increase gains in most cases when considering the variability of blocks and the associated fee income. The proposed scheme suggests increasing block size fast with difficulty over a narrow window. While the odds of producing a block are slightly reduced, the block produced if successful is more profitable, but only if there is a good supply of transactions that pay real fees comparable to those already taken. This trade-off exists currently with respect to orphaning risk, and miners still produce large blocks, with producing a larger block meaning greater utility despite the greater chance of not being successful due to orphaning. The risk from orphaning can be traded off for centralization advantage or by miners bypassing validation, issues which at least so far, we have no reason to believe exist for size-mediated schemes. Mining is not a race, and increasing difficulty does not put a miner at an expected return disadvantage compared to others as long as the income increases proportionally. Pay-for-size schemes have been successfully used in some altcoins without the effects that were suggested.The discussion focuses on the challenges of implementing pay-with-diff, which would require miners to adjust their hashing difficulty in order to change the block size. One issue is the need for collusion among miners, unless there is idle hashpower available, which is unlikely. The potential loss does not economically compensate for size increase gains in most cases, when considering the variability of blocks and associated fee income. In addition, businesses will face challenges in planning due to the unpredictability and volatility of the block size and fee environment. The conclusion is that pay-with-diff will either not be used or lead to radical short-term changes in block size and fees, making it difficult for all players to reason and plan.In a discussion amongst Bitcoin developers, the topic of paying with difficulty for increasing block size was brought up. It was noted that paying with a higher difficulty requires either idle hashpower or risking losing an entire block's income to another miner who doesn't care about changing the block size. The potential loss does not economically compensate for the gains in block size increase. The discussion continued on to say that miners have more to lose by paying with difficulty than they gain unless there is collusion amongst the entire network with ~90% certainty. In such a case, the network can collectively agree to increase the block period until the globally desired block size is reached. However, pay-with-difficulty will either not get used or lead to radical short-term block size and fee volatility. Overall - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_libconsensus-and-bitcoin-development-process.xml b/static/bitcoin-dev/Sept_2015/combined_libconsensus-and-bitcoin-development-process.xml index 5db1db60db..14e0679b25 100644 --- a/static/bitcoin-dev/Sept_2015/combined_libconsensus-and-bitcoin-development-process.xml +++ b/static/bitcoin-dev/Sept_2015/combined_libconsensus-and-bitcoin-development-process.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - libconsensus and bitcoin development process - 2023-08-01T16:08:08.707004+00:00 + 2025-10-11T21:55:40.679418+00:00 + python-feedgen Jeff Garzik 2015-09-29 13:04:09+00:00 @@ -59,13 +60,13 @@ - python-feedgen + 2 Combined summary - libconsensus and bitcoin development process - 2023-08-01T16:08:08.707004+00:00 + 2025-10-11T21:55:40.679609+00:00 - There has been a discussion among Bitcoin developers about the best approach to large-scale refactoring in Bitcoin development. The consensus is that such projects should occur over a short period of time and have a written plan beforehand. Concerns were raised about the seemingly random nature of libconsensus refactoring pull requests (PRs) and the impact they can have on downstream developers. It was suggested that developers require more links or "hooks" to see the missing aspects in the development process.Jorge Timón, the developer working on libconsensus, responded by stating that he had communicated his plans for libconsensus multiple times but acknowledged that there was still work to be done to help people understand his proposals and structure his pull requests more effectively. He consolidated three small consensus-related PRs into one with the hope that it would be merged relatively fast.Gavin Andresen proposed a plan to separate consensus code into libconsensus, which is important for less risky and wider contributions. The library will provide full consensus validation for Script, Block Headers, Transactions, and Blocks. Jorge Timón responded to concerns about the seemingly random stream of refactors for libconsensus without any apparent plan or end, stating that just because someone doesn't understand the changes proposed doesn't mean they are random. He described his plan for libconsensus and tried creating big pull requests for people to see the big picture, but nobody wanted to read it. Instead, he had smaller one-little-step PRs that were part of a longer branch.The need for more links or hooks for developers to see the plan, order, and sense in the endless stream of libconsensus refactoring PRs was discussed. Jeff Garzik pointed out that complex code changes with longer development cycles than simple code movement patches keep breaking. He suggested making a plan and not seeing a five-year stream of random consensus code movement patches causing lots of downstream developer headaches. Developers were encouraged to imagine several different ways people might try to find this description in the future and make them work.In a discussion on the Bitcoin-dev mailing list, it was suggested that companies can maintain forks of Bitcoin Core unnecessarily when a different architecture could do what they need without including new logic in the codebase itself. The goal is to have a more modular, reusable, and maintainable codebase where new functionality can be plugged in easily. However, bitcoind's design is still too monolithic and adding a new feature requires the code to be touched all over the place, potentially breaking base node functionality. Therefore, if possible, functionality should be built without changing bitcoind's code at all. An example of this is Monero's 'simplewallet', which communicates with the node software and remembers where it was in the chain. An index could be implemented entirely externally in a similar way while fully handling reorgs.Jeff Garzik highlighted the negative impact of refactors, stating that branches of the source tree are being maintained by various developers. He emphasized the need to understand why these branches are being maintained and what features they have that Bitcoin Core doesn't. He suggested that if refactoring were accelerated and scheduled to be performed in a one-week sprint, the long-term developer impact would be much less. This approach can be compared to "ripping the band-aid off quickly rather than slowly".The importance of well-coordinated refactoring efforts in Bitcoin Core was discussed. While refactoring can be disruptive in the short term, it can make it easier for downstream developers to add and merge changes in the longer term. To address issues with refactoring, the author suggests scheduling move-only changes and documenting them in a way that helps other developers rebase properly. The author also proposes a plan for three major kinds of refactoring: code moves, code style, and structural optimization and consolidation. The author recommends having a "refactoring fortnight" where the bulk of code move-only refactoring plus code style changes can be done. Refactoring should be merged quickly, but only on a schedule so it doesn't cause major disruption to others. The author also emphasizes the negative impact of complex code changes with longer development cycles than simple code movement patches.Overall, the discussion highlights the need for better planning and coordination in large-scale refactoring efforts in Bitcoin development. It emphasizes the importance of clear communication, proper documentation, and scheduling of refactoring activities to minimize disruptions and ensure smooth integration of changes.Bitcoin Core, the codebase for the Bitcoin network, requires extensive modularization to improve its structure. However, this process needs careful planning and consideration for downstream projects and contributors. Continual refactoring can cause issues, such as pull requests getting stuck in "rebase hell" and creating stress for contributors. To mitigate these problems, refactoring should be merged quickly but on a schedule that minimizes disruption. There are three types of refactoring: code moves, code style changes, and structural optimization and consolidation. Code moves and code style changes are easy to review and merge, while the 2015-09-29T13:04:09+00:00 + There has been a discussion among Bitcoin developers about the best approach to large-scale refactoring in Bitcoin development. The consensus is that such projects should occur over a short period of time and have a written plan beforehand. Concerns were raised about the seemingly random nature of libconsensus refactoring pull requests (PRs) and the impact they can have on downstream developers. It was suggested that developers require more links or "hooks" to see the missing aspects in the development process.Jorge Timón, the developer working on libconsensus, responded by stating that he had communicated his plans for libconsensus multiple times but acknowledged that there was still work to be done to help people understand his proposals and structure his pull requests more effectively. He consolidated three small consensus-related PRs into one with the hope that it would be merged relatively fast.Gavin Andresen proposed a plan to separate consensus code into libconsensus, which is important for less risky and wider contributions. The library will provide full consensus validation for Script, Block Headers, Transactions, and Blocks. Jorge Timón responded to concerns about the seemingly random stream of refactors for libconsensus without any apparent plan or end, stating that just because someone doesn't understand the changes proposed doesn't mean they are random. He described his plan for libconsensus and tried creating big pull requests for people to see the big picture, but nobody wanted to read it. Instead, he had smaller one-little-step PRs that were part of a longer branch.The need for more links or hooks for developers to see the plan, order, and sense in the endless stream of libconsensus refactoring PRs was discussed. Jeff Garzik pointed out that complex code changes with longer development cycles than simple code movement patches keep breaking. He suggested making a plan and not seeing a five-year stream of random consensus code movement patches causing lots of downstream developer headaches. Developers were encouraged to imagine several different ways people might try to find this description in the future and make them work.In a discussion on the Bitcoin-dev mailing list, it was suggested that companies can maintain forks of Bitcoin Core unnecessarily when a different architecture could do what they need without including new logic in the codebase itself. The goal is to have a more modular, reusable, and maintainable codebase where new functionality can be plugged in easily. However, bitcoind's design is still too monolithic and adding a new feature requires the code to be touched all over the place, potentially breaking base node functionality. Therefore, if possible, functionality should be built without changing bitcoind's code at all. An example of this is Monero's 'simplewallet', which communicates with the node software and remembers where it was in the chain. An index could be implemented entirely externally in a similar way while fully handling reorgs.Jeff Garzik highlighted the negative impact of refactors, stating that branches of the source tree are being maintained by various developers. He emphasized the need to understand why these branches are being maintained and what features they have that Bitcoin Core doesn't. He suggested that if refactoring were accelerated and scheduled to be performed in a one-week sprint, the long-term developer impact would be much less. This approach can be compared to "ripping the band-aid off quickly rather than slowly".The importance of well-coordinated refactoring efforts in Bitcoin Core was discussed. While refactoring can be disruptive in the short term, it can make it easier for downstream developers to add and merge changes in the longer term. To address issues with refactoring, the author suggests scheduling move-only changes and documenting them in a way that helps other developers rebase properly. The author also proposes a plan for three major kinds of refactoring: code moves, code style, and structural optimization and consolidation. The author recommends having a "refactoring fortnight" where the bulk of code move-only refactoring plus code style changes can be done. Refactoring should be merged quickly, but only on a schedule so it doesn't cause major disruption to others. The author also emphasizes the negative impact of complex code changes with longer development cycles than simple code movement patches.Overall, the discussion highlights the need for better planning and coordination in large-scale refactoring efforts in Bitcoin development. It emphasizes the importance of clear communication, proper documentation, and scheduling of refactoring activities to minimize disruptions and ensure smooth integration of changes.Bitcoin Core, the codebase for the Bitcoin network, requires extensive modularization to improve its structure. However, this process needs careful planning and consideration for downstream projects and contributors. Continual refactoring can cause issues, such as pull requests getting stuck in "rebase hell" and creating stress for contributors. To mitigate these problems, refactoring should be merged quickly but on a schedule that minimizes disruption. There are three types of refactoring: code moves, code style changes, and structural optimization and consolidation. Code moves and code style changes are easy to review and merge, while the - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_push-tx-fuzzing.xml b/static/bitcoin-dev/Sept_2015/combined_push-tx-fuzzing.xml index a69ea5e978..2893969cb6 100644 --- a/static/bitcoin-dev/Sept_2015/combined_push-tx-fuzzing.xml +++ b/static/bitcoin-dev/Sept_2015/combined_push-tx-fuzzing.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - push tx fuzzing - 2023-08-01T15:55:18.322653+00:00 + 2025-10-11T21:54:56.070201+00:00 + python-feedgen Manuel Aráoz 2015-09-01 18:22:51+00:00 @@ -19,13 +20,13 @@ - python-feedgen + 2 Combined summary - push tx fuzzing - 2023-08-01T15:55:18.322653+00:00 + 2025-10-11T21:54:56.070421+00:00 - In an email exchange on September 1, 2015, Monarch shared two ideas with Kristov for fuzzing bitcoin transactions. The first idea involved random bit flipping from valid transactions, while the second idea included random transaction script generators, including generators from a grammar, a stochastic grammar, and a random sequence of opcodes. Manuel expressed interest in contributing to the project and shared links to his past experiments on fuzzing.Wladimir J. van der Laan responded to Monarch's email and commented on blockchain.info's problems with validation. He pointed out that blockchain.info was not using a full validating node, which led to issues such as improper signature verification and loose coinbase transaction relaying. These problems resulted in instant banning from connected nodes. Wladimir suggested that there is potential for fun with fuzzing those APIs.In a Bitcoin developer forum, Monarch raised concerns about nodes that do not validate transactions before broadcasting them. This lack of validation made them of minimum concern to the P2P network. Blockchain.info experienced problems related to this as they were not using a full validating node underneath. This led to improper verification of signatures and panic when it seemed like a massive number of old coins were being spent on their site. They were also relaying loose coinbase transactions, which caused an instant ban from connected nodes. Wladimir mentioned that there is potential for mischief with fuzzing those APIs.In the same forum thread, Kristov Atlas expressed interest in developing a fuzzer for push tx APIs but couldn't find one after a brief search. He asked if anyone had found otherwise or was engaged in writing one. Jonas Nick provided two links to Bitcoin Consensus Test Cases and his blog post on fuzzing Bitcoin Consensus. According to Nick, the only implementations with significant network presence are btcd and Bitcoin Core. Fuzzing these services should be sufficient if they validate transactions using either of the two. Atlas had also mentioned two implementations based on Insight that use Bitcoin Core for validation. If these implementations don't validate transactions before broadcast, they won't make it beyond a single hop through the P2P network and are of minimal concern.The writer of this message is seeking a fuzzer for push tx APIs that can send random data and fuzz specific aspects of the transaction format. They have conducted a brief search but haven't found one. The writer lists several endpoints they would like to test, such as https://live.blockcypher.com/btc-testnet/pushtx/, https://insight.bitpay.com/tx/send, https://blockchain.info/pushtx, and others. The desired fuzzer should be capable of fuzzing valid and invalid script formats and changing the order of op codes, among other things. The writer is also open to recommendations on how such a fuzzer should be structured. Finally, the writer invites anyone interested in collaborating to contact them via private message. 2015-09-01T18:22:51+00:00 + In an email exchange on September 1, 2015, Monarch shared two ideas with Kristov for fuzzing bitcoin transactions. The first idea involved random bit flipping from valid transactions, while the second idea included random transaction script generators, including generators from a grammar, a stochastic grammar, and a random sequence of opcodes. Manuel expressed interest in contributing to the project and shared links to his past experiments on fuzzing.Wladimir J. van der Laan responded to Monarch's email and commented on blockchain.info's problems with validation. He pointed out that blockchain.info was not using a full validating node, which led to issues such as improper signature verification and loose coinbase transaction relaying. These problems resulted in instant banning from connected nodes. Wladimir suggested that there is potential for fun with fuzzing those APIs.In a Bitcoin developer forum, Monarch raised concerns about nodes that do not validate transactions before broadcasting them. This lack of validation made them of minimum concern to the P2P network. Blockchain.info experienced problems related to this as they were not using a full validating node underneath. This led to improper verification of signatures and panic when it seemed like a massive number of old coins were being spent on their site. They were also relaying loose coinbase transactions, which caused an instant ban from connected nodes. Wladimir mentioned that there is potential for mischief with fuzzing those APIs.In the same forum thread, Kristov Atlas expressed interest in developing a fuzzer for push tx APIs but couldn't find one after a brief search. He asked if anyone had found otherwise or was engaged in writing one. Jonas Nick provided two links to Bitcoin Consensus Test Cases and his blog post on fuzzing Bitcoin Consensus. According to Nick, the only implementations with significant network presence are btcd and Bitcoin Core. Fuzzing these services should be sufficient if they validate transactions using either of the two. Atlas had also mentioned two implementations based on Insight that use Bitcoin Core for validation. If these implementations don't validate transactions before broadcast, they won't make it beyond a single hop through the P2P network and are of minimal concern.The writer of this message is seeking a fuzzer for push tx APIs that can send random data and fuzz specific aspects of the transaction format. They have conducted a brief search but haven't found one. The writer lists several endpoints they would like to test, such as https://live.blockcypher.com/btc-testnet/pushtx/, https://insight.bitpay.com/tx/send, https://blockchain.info/pushtx, and others. The desired fuzzer should be capable of fuzzing valid and invalid script formats and changing the order of op codes, among other things. The writer is also open to recommendations on how such a fuzzer should be structured. Finally, the writer invites anyone interested in collaborating to contact them via private message. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2015/combined_python-bitcoinlib-v0-5-0rc1-OpenSSL-crashes-on-OSX-and-Arch-Linux-should-be-fixed.xml b/static/bitcoin-dev/Sept_2015/combined_python-bitcoinlib-v0-5-0rc1-OpenSSL-crashes-on-OSX-and-Arch-Linux-should-be-fixed.xml index 27088386c7..4f0847aff5 100644 --- a/static/bitcoin-dev/Sept_2015/combined_python-bitcoinlib-v0-5-0rc1-OpenSSL-crashes-on-OSX-and-Arch-Linux-should-be-fixed.xml +++ b/static/bitcoin-dev/Sept_2015/combined_python-bitcoinlib-v0-5-0rc1-OpenSSL-crashes-on-OSX-and-Arch-Linux-should-be-fixed.xml @@ -1,8 +1,9 @@ - + 2 Combined summary - python-bitcoinlib-v0.5.0rc1 - OpenSSL crashes on OSX and Arch Linux should be fixed - 2023-08-01T16:02:27.345642+00:00 + 2025-10-11T21:54:30.586000+00:00 + python-feedgen Peter Todd 2015-09-27 14:51:41+00:00 @@ -11,13 +12,13 @@ - python-feedgen + 2 Combined summary - python-bitcoinlib-v0.5.0rc1 - OpenSSL crashes on OSX and Arch Linux should be fixed - 2023-08-01T16:02:27.345642+00:00 + 2025-10-11T21:54:30.586173+00:00 - Peter Todd, a prominent figure in the Bitcoin community, has officially released v0.5.0 of python-bitcoinlib on Github. This release comes after the successful testing of the release candidate (v0.5.0rc1) with no reported issues. Python-bitcoinlib is a Python interface that allows users to interact with Bitcoin and other cryptocurrency-related tools using the JSON-RPC API. It aims to simplify Bitcoin programming for both beginners and advanced users.The new release includes several features and improvements. One notable addition is support for P2SH multi-sig transactions, which enhances the security and flexibility of Bitcoin transactions. Additionally, the update introduces BIP32 hierarchical deterministic key generation, making it easier to manage and secure private keys. The release also includes various bug fixes, ensuring a more stable and reliable experience for users.On September 6, 2015, Peter Todd made the announcement via email on the Bitcoin-dev mailing list, notifying the community about the release of v0.5.0. This communication channel allows developers and enthusiasts to stay updated on the latest developments and advancements in the Bitcoin ecosystem.In addition to the official release, a new release candidate (v0.5.0rc1) was also made available. This release candidate addresses significant OpenSSL-related crashes on OSX and Arch Linux, providing a fix for these issues. The release notes highlight other changes in this version, including new RPC calls such as getbestblockhash, getblockcount, and getmininginfo. Furthermore, the update enables signing and verification of Bitcoin Core compatible messages with pubkey recovery, enhancing the cryptographic capabilities of the library. Other improvements include Tox tests for enhanced testing procedures and Sphinx docs for improved documentation.The update also includes bug fixes, one of which resolves an issue where getinfo() did not work properly when disablewallet=1. These bug fixes contribute to a more seamless user experience by resolving known issues and improving the overall stability of the library.The release notes emphasize the importance of confirming that the new release candidate addresses any previously experienced OpenSSL-related crashes on OSX or Arch Linux. This request ensures that users can provide feedback and help validate the effectiveness of the solution in resolving these specific issues.Overall, the release of v0.5.0 of python-bitcoinlib brings several new features, improvements, and bug fixes to the Python interface for Bitcoin programming. With its aim to simplify Bitcoin development and cater to users of all levels, this release contributes to the ongoing evolution and enhancement of the Bitcoin ecosystem. 2015-09-27T14:51:41+00:00 + Peter Todd, a prominent figure in the Bitcoin community, has officially released v0.5.0 of python-bitcoinlib on Github. This release comes after the successful testing of the release candidate (v0.5.0rc1) with no reported issues. Python-bitcoinlib is a Python interface that allows users to interact with Bitcoin and other cryptocurrency-related tools using the JSON-RPC API. It aims to simplify Bitcoin programming for both beginners and advanced users.The new release includes several features and improvements. One notable addition is support for P2SH multi-sig transactions, which enhances the security and flexibility of Bitcoin transactions. Additionally, the update introduces BIP32 hierarchical deterministic key generation, making it easier to manage and secure private keys. The release also includes various bug fixes, ensuring a more stable and reliable experience for users.On September 6, 2015, Peter Todd made the announcement via email on the Bitcoin-dev mailing list, notifying the community about the release of v0.5.0. This communication channel allows developers and enthusiasts to stay updated on the latest developments and advancements in the Bitcoin ecosystem.In addition to the official release, a new release candidate (v0.5.0rc1) was also made available. This release candidate addresses significant OpenSSL-related crashes on OSX and Arch Linux, providing a fix for these issues. The release notes highlight other changes in this version, including new RPC calls such as getbestblockhash, getblockcount, and getmininginfo. Furthermore, the update enables signing and verification of Bitcoin Core compatible messages with pubkey recovery, enhancing the cryptographic capabilities of the library. Other improvements include Tox tests for enhanced testing procedures and Sphinx docs for improved documentation.The update also includes bug fixes, one of which resolves an issue where getinfo() did not work properly when disablewallet=1. These bug fixes contribute to a more seamless user experience by resolving known issues and improving the overall stability of the library.The release notes emphasize the importance of confirming that the new release candidate addresses any previously experienced OpenSSL-related crashes on OSX or Arch Linux. This request ensures that users can provide feedback and help validate the effectiveness of the solution in resolving these specific issues.Overall, the release of v0.5.0 of python-bitcoinlib brings several new features, improvements, and bug fixes to the Python interface for Bitcoin programming. With its aim to simplify Bitcoin development and cater to users of all levels, this release contributes to the ongoing evolution and enhancement of the Bitcoin ecosystem. - + \ No newline at end of file diff --git a/static/bitcoin-dev/Sept_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml b/static/bitcoin-dev/Sept_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml index 48e67b7f05..4e0bcac593 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Attack-by-modifying-non-segwit-transactions-after-segwit-is-accepted-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Attack by modifying non-segwit transactions after segwit is accepted ? - 2025-09-26T16:00:40.513122+00:00 + 2025-10-11T22:14:29.706835+00:00 python-feedgen Johnson Lau 2016-09-01 11:29:29+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Attack by modifying non-segwit transactions after segwit is accepted ? - 2025-09-26T16:00:40.513287+00:00 + 2025-10-11T22:14:29.706972+00:00 2016-09-01T11:29:29+00:00 In a recent discussion on Reddit, Johnson Lau clarified that there is no real attack in the segwit code and explained how a check in the code can prevent potential vulnerabilities. The subject of the thread had a question mark, indicating that clarification was being sought from the community rather than asserting the existence of a vulnerability. The complexity of the segwit code was acknowledged by Sergio Demian Lerner, with key parts of the consensus code spread across source files.Johnson Lau's clarifications were appreciated by the community, and he emphasized that adding witness data to a non-segwit script is invalid according to consensus. He shared a pull request that detects such violations early and bans the peer. Another approach proposed by Lau is to run the scripts of all incoming transactions, which is feasible as the unspent transaction outputs (utxos) have already been fetched, making validation easier.The consensus in the Bitcoin community is that adding witness data to a non-segwit script is considered invalid. This consensus is highlighted in a code snippet on Github's bitcoin repository. A new pull request has been made to detect any violations of this consensus early and ban the peer responsible. Additionally, another suggested approach is to run the scripts of all incoming transactions, taking advantage of the fact that utxos have already been fetched during the validation process.The potential for malicious nodes to modify non-segwit transactions after segwit activation was discussed in a recent thread on Bitcoin Improvement Proposals (BIP). It was suggested that a malicious node could re-format a non-segwit transaction into a segwit transaction with up to 400 Kbytes of segwit witness program data, resulting in both transactions having the same hash. However, due to low fees per byte, such a modified transaction would likely not be properly relayed by the network. An attacker could still modify the original transaction by adding segwit witness program data up to the point of relaying the transaction, successfully preventing it from being mined.Another concern is that an attacker could encode arbitrary data, such as virus signatures or illegal content, into passing non-segwit transactions. One proposed solution is to increase the transaction version to 3 for segwit transactions, ensuring that a non-segwit transaction cannot be converted into a segwit transaction without changing the transaction hash. However, this solution does not address all potential problems, as transactions with a mixture of segwit and non-segwit inputs could still be vulnerable to the same attack, even if they are version 3.To mitigate these issues, a simple check could be added to the IsStandardTX() function to prevent witness programs from having a stack element length greater than the maximum script element size (MAX_SCRIPT_ELEMENT_SIZE). However, a more long-term solution would be to introduce a field for each input or the entire transaction that specifies the maximum size of the witness stack in bytes (maxWitnessSize).Overall, the discussion revolves around the complexities of the segwit code and various approaches to prevent potential attacks or vulnerabilities. It underscores the importance of raising questions and seeking clarification from the community when necessary. The provided links to relevant code and pull requests serve as valuable references for further exploration of the topic. diff --git a/static/bitcoin-dev/Sept_2016/combined_BIP-2-revival-and-rework.xml b/static/bitcoin-dev/Sept_2016/combined_BIP-2-revival-and-rework.xml index 9fb1ec2e11..62f2f4d3aa 100644 --- a/static/bitcoin-dev/Sept_2016/combined_BIP-2-revival-and-rework.xml +++ b/static/bitcoin-dev/Sept_2016/combined_BIP-2-revival-and-rework.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP 2 revival and rework - 2025-09-26T16:00:51.258358+00:00 + 2025-10-11T22:14:40.327428+00:00 python-feedgen Tom Zander 2016-10-16 14:56:36+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - BIP 2 revival and rework - 2025-09-26T16:00:51.258556+00:00 + 2025-10-11T22:14:40.327597+00:00 2016-10-16T14:56:36+00:00 In a discussion on whether work can be released under public domain and CC-BY-SA, Marco Falke and Tom Zander had differing views. Zander believed that it is not possible to dual-license something under both CC-BY-SA and public domain because all licenses are based on having copyright, whereas public domain means the lack of copyright. Zander preferred copyleft licenses for BIPs. Tom Zander suggested that BIPs should be licensed as public domain with a CC-BY option. It was pointed out that while BIP 1 requires public domain or OPL, it does not forbid other licenses. Similarly, BIP 2 allows for other acceptable licenses but does not recommend them. Despite the goal of no longer allowing public domain as the only copyright option, BIP 2 does not forbid releasing work under public domain in jurisdictions where it is recognized as legal. Many BIP authors have previously chosen public domain as the only option.On October 15, 2016, Tom Zander and Marco Falke discussed the licensing of BIPs. Zander had dual-licensed BIP 134 under OPL and CC-BY-SA for future acceptance of CC-BY-SA without needing permission from all authors to remove the OPL. Falke pointed out that BIP 2 does not allow public domain as the only copyright option, to which Zander responded that public domain was never the only option.In an email exchange between Tom Zander and Luke Dashjr, they discussed licensing options for BIPs. Zander suggested public domain (CC0) or a CC-BY option, while Dashjr added MIT/BSD licenses. Dashjr explained that BIP 1 only allows OPL and public domain, so BIP 2 can be available under OPL until it activates. Dashjr clarified that CC0 and public domain are different. Dashjr was asked to reach out to the community to ensure BIP 2 has been heard and discussed. France and Germany do not recognize public domain, while GPL is valid anywhere copyright laws exist.On October 15, 2016, a discussion took place on the Bitcoin development mailing list regarding the licensing of BIPs. Marco Falke suggested licensing BIPs under CC0 with a CC-BY option, while Tom Zander disagreed and suggested a requirement for "Share alike" and an optional "Attribution." It was argued that more restrictive licenses are not suitable for BIPs and that the BIP repository is not the place to promote open access. BIP 2 allows for such licenses but does not recommend them. Clarity around proposed changes and reasoning was encouraged. The discussion concluded with the suggestion to move forward with BIP 2 if there were no objections.In a conversation on the Bitcoin Development mailing list about licensing for BIPs, it was suggested that "Share alike" be required and "Attribution" be optional. However, it was pointed out that there is no Creative Commons license option that requires Share Alike and allows Attribution as an option. CC0, MIT/BSD, or CC-BY were proposed as suitable licenses for BIPs. The suitability of more restrictive licenses and promoting open access in the BIP repository were also discussed. BIP 2 allows for such licenses but does not recommend them. The email thread concluded with the suggestion to move forward with BIP 2 if there were no objections.Luke Dashjr announced that the Open Publication License (OPL) will no longer be acceptable for BIPs. He recommended replacing OPL with one or two Creative Commons licenses, with the choice between CCO and BY-SA licenses alongside public domain. The Open Publication License, created in 1999, was superseded by Creative Commons licenses. Luke-jr made updates to BIP 2, replacing BIP 1, and introduced changes such as the acceptance of non-image auxiliary files, required email addresses for authors, and disallowing Markdown format. The updated BIP 2 was open for review with the aim of completion by Christmas. diff --git a/static/bitcoin-dev/Sept_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml b/static/bitcoin-dev/Sept_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml index 94500d0515..04e336d9fa 100644 --- a/static/bitcoin-dev/Sept_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml +++ b/static/bitcoin-dev/Sept_2016/combined_BIP-draft-OP-CHECKBLOCKATHEIGHT.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP draft: OP_CHECKBLOCKATHEIGHT - 2025-09-26T16:00:38.362603+00:00 + 2025-10-11T22:14:27.582249+00:00 python-feedgen Nathan Cook 2016-10-05 02:15:36+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - BIP draft: OP_CHECKBLOCKATHEIGHT - 2025-09-26T16:00:38.362773+00:00 + 2025-10-11T22:14:27.582453+00:00 2016-10-05T02:15:36+00:00 A proposal has been made for a new opcode, OP_CHECKBLOCKATHEIGHT, in the Bitcoin scripting system. This opcode aims to tackle the problem of re-issuing bitcoin transactions when the coins they spend have been conflicted or double-spent. The proposal sparked a discussion among developers on the bitcoin-dev mailing list.Some developers expressed concerns about the complexity and potential risks of the opcode. They argued that the added complexity may not be worth the reward of protecting Bitcoiners from untrusted creditors. There were also concerns about the impact on fungibility and the risk of invalidation caused by blockchain reorganizations.Luke Dashjr, the developer who proposed the opcode, provided examples to illustrate how it could solve the problem of double-spending. One example involved Alice sending Bob BTC using a specific UTXO, but Fred double-spends that UTXO, invalidating Alice's transfer. Without the new opcode, Alice could send Bob a different UTXO, but there is a risk of both UTXOs being mined, resulting in Bob receiving more BTC than intended. With the new opcode, Alice can create a transaction that is only valid in the blockchain where Fred's double-spend has been confirmed. If that block is reorganized out, the transaction becomes invalid, ensuring that Bob receives only the original UTXO or a revised transaction if the double-spend is confirmed again.The discussion also touched upon other aspects related to the proposed opcode. There were suggestions to prevent overuse of the opcode and enforce a maximum survivable reorg to ensure sensible handling of exposed coins. Concerns were raised about the impact on mempool handling and the potential for persistent chain forks.Overall, the proposed opcode aims to address the issue of double-spending and conflicts in bitcoin transactions. It introduces a new way for users to create transactions that are only valid in specific blockchain scenarios, ensuring that the intended recipient receives the correct amount of BTC without the risk of loss due to blockchain reorganizations. However, there are ongoing discussions and debates among developers about the complexity and potential risks associated with implementing this opcode.The proposal has been put forward by Luke-Jr, who is seeking feedback from the community on whether this approach is a good idea. It is currently uncertain whether this proposal will be accepted and implemented by the Bitcoin community. However, if accepted, the proposed opcode could potentially provide a solution to the issue of double-spending that has plagued the Bitcoin network in the past. Overall, this BIP presents an interesting and innovative approach to addressing the problem of double-spending in the Bitcoin network. While its acceptance and implementation are yet to be determined, it is worth considering as a potential solution to this long-standing issue. diff --git a/static/bitcoin-dev/Sept_2016/combined_Completing-the-retirement-of-the-alert-system.xml b/static/bitcoin-dev/Sept_2016/combined_Completing-the-retirement-of-the-alert-system.xml index b0038c4917..6f819dfa78 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Completing-the-retirement-of-the-alert-system.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Completing-the-retirement-of-the-alert-system.xml @@ -2,7 +2,7 @@ 2 Combined summary - Completing the retirement of the alert system - 2025-09-26T16:00:36.212775+00:00 + 2025-10-11T22:14:25.458707+00:00 python-feedgen Gregory Maxwell 2016-09-10 15:36:38+00:00 @@ -49,10 +49,11 @@ + 2 Combined summary - Completing the retirement of the alert system - 2025-09-26T16:00:36.212936+00:00 + 2025-10-11T22:14:25.458850+00:00 2016-09-10T15:36:38+00:00 In a Bitcoin development discussion, Johnson Lau suggested publishing the private key a few months after the final alert. Andrew C questioned why they would wait so long to publish it and suggested publishing it a few days after the final alert instead. However, another participant in the discussion responded that they needed to ensure the revocation message was widely distributed before making the private key public.The context of this conversation is unclear, but it is likely related to discussions around potential security vulnerabilities in the Bitcoin network. There are several possible reasons why Lau may have suggested waiting to publish the key. One explanation could be that it allows time for any remaining users who have not updated their software to do so before the key is made public. Another possibility is that it gives developers time to create patches or other solutions to address any issues that may arise after the alert is disabled. Additionally, waiting a few months could help ensure that all nodes on the network have had a chance to disable the alert and are no longer affected by its presence.Bitcoin Core has removed the alert system, which was a centralized facility that allowed trusted parties to send messages to be displayed in wallet software and remotely trigger the software to stop transacting. The system had some potential uses but also had issues that made it problematic. It was a frequent source of misunderstanding about the security model and effective governance. Furthermore, the system was not scalable to different software vendors, and no one could tell who created a message. Additionally, there was good reason to believe that the key was compromised. Due to these issues, the alert system has been deactivated, and Gregory Maxwell via Bitcoin-dev plans to send a triggering alert in the future and disclose the private key in public to eliminate any further potential of reputation attacks and diminish the risk of misunderstanding the key as some special trusted source of authority.Overall, the email chain and discussions highlight the importance of careful planning and communication when it comes to managing security risks in complex systems like Bitcoin. It is crucial to address potential vulnerabilities and ensure the widespread distribution of important messages before implementing changes or disclosing sensitive information. The removal of the alert system and the plans for deactivating the key demonstrate a proactive approach to protecting the integrity and reputation of the Bitcoin network. diff --git a/static/bitcoin-dev/Sept_2016/combined_Interpreting-nTime-for-the-purpose-of-Bitcoin-attested-timestamps.xml b/static/bitcoin-dev/Sept_2016/combined_Interpreting-nTime-for-the-purpose-of-Bitcoin-attested-timestamps.xml index b9edf4ec08..80cf3ec4e6 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Interpreting-nTime-for-the-purpose-of-Bitcoin-attested-timestamps.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Interpreting-nTime-for-the-purpose-of-Bitcoin-attested-timestamps.xml @@ -2,7 +2,7 @@ 2 Combined summary - Interpreting nTime for the purpose of Bitcoin-attested timestamps - 2025-09-26T16:00:49.144381+00:00 + 2025-10-11T22:14:38.204035+00:00 python-feedgen Tom Harding 2016-09-19 19:53:46+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Interpreting nTime for the purpose of Bitcoin-attested timestamps - 2025-09-26T16:00:49.144568+00:00 + 2025-10-11T22:14:38.204165+00:00 2016-09-19T19:53:46+00:00 In an email conversation, Peter Todd corrected his suggestion regarding the catch-up formula and provided a new probability formula to determine whether honest miners can build a chain N blocks long before dishonest miners. The new formula is CDF[Erlang(N, q) - Erlang(N, 1-q), 0]. He also offered assistance with numeric calculations. A digital signature was attached to the email.On bitcoin-dev, Tom Harding pointed out that the probability of dishonest miners finding N blocks in a row immediately differs from the probability of them building a chain N blocks long, considering the random walk. In response, Peter Todd suggested using Satoshi's formula from bitcoin.pdf, section 11, which yields different results. If a timestamp contains only a block height instead of actual block headers, there is no risk if the Bitcoin node is in sync with the most-work chain. However, if the verifier is not in sync, an attacker can sybil attack the verifier's node to make them believe that blocks with invalid timestamps are part of the most-work chain. This case is similar to a payee being sybil attacked, requiring the same analysis. It is important to note that timestamps should not include block headers of allegedly confirming blocks, as this is a weak proof due to the ease of creating a block. OpenTimestamps does not include block headers in timestamps, but it is worth mentioning explicitly.In a message on bitcoin-dev, Peter Todd discusses the probability of dishonest miners finding N blocks in a row immediately. He explains the need for the probability of building a chain N blocks long, taking the random-walk into account. He suggests using Satoshi's formula from bitcoin.pdf, section 11, which produces different results compared to the previous method. A q value of .5 is considered totally insecure as both factions will eventually possess a chain of length N anchored at x during the wild reorg melee.The discussion revolves around timestamps in OpenTimestamps. One person suggests considering earlier blocks, while another argues that timestamps are proofs of existence prior to a specific time and cannot have a "wrong order" in timestamp proofs. OpenTimestamps verifies plausible dates for various use cases, such as timestamped git commits. An example is provided with the date on the git commit, a date for the PGP signature, and a third date for the Bitcoin timestamp. Peter Todd's contact information is given at the end of the email.The author proposes a scheme for interpreting the nTime fields in block headers for timestamping purposes using the Bitcoin blockchain. The purpose is to provide evidence of a message's existence before a certain point in time. The algorithm defines time T as the maximum nTime out of the N blocks confirming the timestamp, including the first block committing the timestamp. Max_offset represents the maximum expected nTime offset from an honest miner. Dishonest miners can create an invalid timestamp if they find all N blocks, but if an honest miner finds any block, the nTime field will be set correctly. UI considerations include not displaying timestamps until local time surpasses the timestamp and rounding up the timestamp to the nearest day for display. diff --git a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml index 9441eab84b..e594297ae2 100644 --- a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml +++ b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-OP-IF-and-OP-NOTIF-malleability-in-P2WSH.xml @@ -2,7 +2,7 @@ 2 Combined summary - New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH - 2025-09-26T16:00:46.994558+00:00 + 2025-10-11T22:14:36.080669+00:00 python-feedgen Russell O'Connor 2016-09-05 14:55:10+00:00 @@ -89,10 +89,11 @@ + 2 Combined summary - New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH - 2025-09-26T16:00:46.994737+00:00 + 2025-10-11T22:14:36.080853+00:00 2016-09-05T14:55:10+00:00 Suppose we have a marginal fee rate of 50 satoshis per byte. Reducing the size of the witness data by 1 byte is equivalent to a replace by fee that increases the fee by 50 satoshis. In both cases, miners get an extra potential of 50 satoshis in revenue. Replacing witness data with smaller witness data can pay for its own relay cost as much as RBF can, simply by requiring that the smaller witness be small enough to cover the same RBF threshold. BIP125 and mempool eviction both require the replacing transaction to have a higher fee, to compensate for the cost of relaying the replaced transaction(s).Johnson Lau, a member of the bitcoin-dev community, has proposed a restriction for segwit OP_IF argument as a policy. He is seeking more feedback from users of OP_IF to ACK or NACK his proposal. It is expected that Lightning network would use OP_IF frequently. Rusty, another member of the community, mentions that his current scripts use OP_IF and OP_NOTIF only after OP_EQUAL, except for one place where they use OP_EQUAL...OP_EQUAL...OP_ADD OP_IF. However, he notes that there will be no effect on the c-lightning implementation either way.The Bitcoin script validity rules are proposed to change in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts. This would result in the argument for OP_IF and OP_NOTIF being exactly an empty vector or 0x01, or the script evaluation fails immediately. The policy has received a few concept ACKs. A BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts. The proposed changes affect the combination of "OP_SIZE OP_IF" or "OP_DEPTH OP_IF". With this policy/softfork, you need to use "OP_SIZE OP_0NOTEQUAL OP_IF" or "OP_DEPTH OP_0NOTEQUAL OP_IF", or reconstruct your scripts. This is a softfork on top of BIP141. It is enforced as a relay policy by the reference client since the first release of BIP141. Users must not create P2WSH scripts that are incompatible with this BIP to avoid risks of fund loss.In a bitcoin-dev email, Sergio Demian Lerner raised concerns about transactions sent to IoT devices, which may be rejected if their witness program is too large for the device's implementation-imposed limit. This can result in the loss of bitcoins as the private key is stored on the device, rendering it unable to accept the cloned transaction. Lerner suggests invalidating transactions with a higher witness size than expected by the sender. The design of segwit means that resource constrained devices don't need to receive witness data to verify lite-client merkle-path proofs, which are useless for lite-clients anyway.In a discussion on the bitcoin-dev mailing list, Sergio Demian Lerner suggested that the real problem with witness data size is that it is not signed. However, Gregory Maxwell pointed out that this is not possible for the general case as you may not know the witness size in advance. Maxwell believes fees are not the problem, but rather the fact that the maximum witness size may be changed by a miner which could cause issues for devices like IoT or side-chains that have certain restrictions on transaction sizes they can accept. He proposes that if the witness size is higher than the expected size by the sender, the transaction becomes invalid.The issue at hand is that witness data size is not signed, leading to potential malleability issues and problems for systems with hard limits on the size of witness programs they can accept. A proposed solution is to soft-fork and add an opcode OP_PROGSIZE that pushes the size of the segwit program being evaluated onto the stack, which would allow scripts to take action based on the size. This would prevent an attacker from creating a clone of a transaction with a witness ECDSA signature longer than 0x50 bytes. The discussion also touches on workarounds for current behavior and the need to enforce MINIMALIF in some cases, with the suggestion to make it a relay policy first before considering a softfork.On August 17, 2016, Luke Dashjr and Johnson Lau discussed a workaround for the issue of malleability in Bitcoin transactions. The suggested code to replicate the original behavior was deemed ugly by Dashjr, who argued that it was unnecessary in most real-world use cases. He proposed simplifying the code by replacing "OP_SIZE OP_IF" with "OP_SIZE OP_0NOTEQUAL OP_IF", as OP_SIZE must return a valid MINIMALDATA number. However, Lau noted that diff --git a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-dummy-stack-element-malleability.xml b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-dummy-stack-element-malleability.xml index 73526827d2..d9a2ad4918 100644 --- a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-dummy-stack-element-malleability.xml +++ b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Dealing-with-dummy-stack-element-malleability.xml @@ -2,7 +2,7 @@ 2 Combined summary - New BIP: Dealing with dummy stack element malleability - 2025-09-26T16:00:29.762858+00:00 + 2025-10-11T22:14:19.075201+00:00 python-feedgen Johnson Lau 2016-09-04 12:29:37+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - New BIP: Dealing with dummy stack element malleability - 2025-09-26T16:00:29.763023+00:00 + 2025-10-11T22:14:19.075414+00:00 2016-09-04T12:29:37+00:00 The discussion revolves around the bundling of two independent softforks in one release, raising concerns about increased testing and maintenance burdens. Testing is required for four scenarios: both softforks not activated, only NULLDUMMY activated, only SEGWIT activated, and both activated. A significant percentage of miners are hard-coding the block version number, which poses risks to the softfork transition as miners may not enforce what they signal. Bundling two independent softforks would double the risks, with NULLDUMMY alone deemed not worth the associated risks.On September 2, 2016, at 1:10 PM, Tom Harding via bitcoin-dev questioned the rationale behind bundling the two independent softforks together, suggesting that miners should have the opportunity to vote on them separately. The proposed BIP (Bitcoin Improvement Proposal) by Johnson Lau, introduced on September 1st, 2016 at 9:40 PM, suggests deploying a BIP using "version bits" BIP9 with the name "segwit" and using bit 1, employing the same parameters as BIP141 and BIP143. However, concerns were raised regarding why this fix should be bundled with segwit and whether independent voting should be allowed, as this fix has value beyond segwit.On September 2, 2016, Johnson Lau announced the deployment of BIP9 using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The BIP9 starttime and timeout for Bitcoin mainnet are still to be determined, while for Bitcoin testnet, the starttime is midnight May 1, 2016 UTC, and the timeout is midnight May 1, 2017 UTC. The reference client has been generating compatible signatures since its inception, and the null dummy rule has been enforced as relay policy by the reference client since v0.10.0. No transactions violating this requirement have been added to the chain since at least August 2015. It should be noted that for all scriptPubKey types in actual use, non-compliant signatures can easily be converted into compliant ones, except for cases where conversion is not possible.The proposed changes to the Bitcoin transaction validity rules are outlined in this BIP, aimed at addressing the malleability issue of extra stack elements for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Signature malleability allows any relay node on the network to alter the signature in transactions without requiring access to relevant private keys, posing a security concern. The "NULLDUMMY" consensus rule is introduced to address this issue, requiring the dummy element to be an empty byte array, resulting in false evaluation if anything else is used. This BIP will be deployed using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The reference client has been generating compatible signatures from the beginning, and the null dummy rule has been enforced as relay policy by the reference client since v0.10.0. An implementation for the reference client can be found at https://github.com/bitcoin/bitcoin/pull/8636.In summary, the discussion highlights concerns about bundling two independent softforks together, increasing testing and maintenance burdens. Questions were raised regarding the need for independent voting and whether the proposed fix has value beyond segwit. Johnson Lau announced the deployment of BIP9 using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The proposed changes aim to address the malleability issue of extra stack elements for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY through the introduction of the "NULLDUMMY" consensus rule. The reference client has been generating compatible signatures and enforcing the null dummy rule since v0.10.0, with no transactions violating the requirement added to the chain since at least August 2015. diff --git a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Low-S-values-signatures.xml b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Low-S-values-signatures.xml index fe94304380..c4e43457fd 100644 --- a/static/bitcoin-dev/Sept_2016/combined_New-BIP-Low-S-values-signatures.xml +++ b/static/bitcoin-dev/Sept_2016/combined_New-BIP-Low-S-values-signatures.xml @@ -2,7 +2,7 @@ 2 Combined summary - New BIP: Low S values signatures - 2025-09-26T16:00:34.063107+00:00 + 2025-10-11T22:14:23.330043+00:00 python-feedgen Johnson Lau 2016-09-02 08:28:14+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - New BIP: Low S values signatures - 2025-09-26T16:00:34.063279+00:00 + 2025-10-11T22:14:23.330212+00:00 2016-09-02T08:28:14+00:00 BIP146 proposes changes to the Bitcoin transaction validity rules in order to address signature malleability related to ECDSA signature encoding. This malleability allows relay nodes on the network to alter signatures without needing access to private keys. The BIP introduces two new rules: LOW_S and NULLFAIL. LOW_S restricts the S value inside ECDSA signatures to be at most half of the curve order, with strict DER encoding. If a signature fails the Low S value check and is not an empty byte array, the entire script will evaluate to false immediately. NULLFAIL requires that if an OP_CHECKSIG returns a FALSE value, the relevant signature must be an empty byte array. If an OP_CHECKMULTISIG returns a FALSE value, all signatures passing to this OP_CHECKMULTISIG must be empty byte arrays. The NULLDUMMY rule has been removed from BIP146 and will become another softfork implemented along with segwit. This revision of BIP146 adds the newly implemented NULLFAIL rules which should cover all special cases. The LOW_S softfork may be deployed later due to some undocumented behavior discovered. However, NULLFAIL will be implemented as a policy rule in 0.13.1, but the softfork won't be deployed in 0.13.1.Recently, the BIP146 was updated to include NULLDUMMY as part of the softfork. The update can be found on the Github page of Bitcoin Improvement Proposals (BIPs). This trivial softfork aims to fix malleability related to the extra stack element consumed by CHECKMULTISIG(VERIFY). It is considered important as it prevents attackers from replacing the stack element with any value, which could have serious implications. The inclusion of NULLDUMMY in BIP146 addresses this issue and enhances the security of the cryptocurrency system. This update demonstrates the continuous improvement made to the Bitcoin protocol to enhance security and prevent malicious attacks.On August 16, 2016, there was a discussion between Luke Dashjr and Johnson Lau regarding the ECDSA verification process for signatures passed to operators like OP_CHECKSIG and OP_CHECKMULTISIG. These operators perform verifications on pubkey/signature pairs in reverse order from the top of the stack. If a signature fails the IsLowDERSignature check, it is not processed. However, there is ambiguity in the reference to "the IsLowDERSignature check" as it is not clearly defined. Dashjr points out that the IsLowDERSignature function in Bitcoin Core is not directly called, but he will clarify this.A new Bitcoin Improvement Proposal (BIP) has been proposed to make low S value signatures a consensus rule. The proposal aims to restrict signatures to using low S values to fix malleability issues. ECDSA signatures are malleable, but restricting the S value helps prevent invalidation by taking the negative of the number S. The BIP states that every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY must use an S value between certain limits with strict DER encoding. The BIP will be deployed using version bits BIP9, likely in v0.13.1. The implementation for the reference client can be found on Github. This proposal also reduces transaction malleability, providing additional benefits to the Bitcoin system. diff --git a/static/bitcoin-dev/Sept_2016/combined_On-going-work-Coin-Selection-Simulation.xml b/static/bitcoin-dev/Sept_2016/combined_On-going-work-Coin-Selection-Simulation.xml index 88d391ea48..afa0267b84 100644 --- a/static/bitcoin-dev/Sept_2016/combined_On-going-work-Coin-Selection-Simulation.xml +++ b/static/bitcoin-dev/Sept_2016/combined_On-going-work-Coin-Selection-Simulation.xml @@ -2,7 +2,7 @@ 2 Combined summary - On-going work: Coin Selection Simulation - 2025-09-26T16:00:31.909188+00:00 + 2025-10-11T22:14:21.197836+00:00 python-feedgen Murch 2016-10-21 14:09:57+00:00 @@ -33,10 +33,11 @@ + 2 Combined summary - On-going work: Coin Selection Simulation - 2025-09-26T16:00:31.909336+00:00 + 2025-10-11T22:14:21.197994+00:00 2016-10-21T14:09:57+00:00 Murch, a Master's thesis student, has developed a Coin Selection Simulator and re-implemented multiple coin selection strategies of prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin). He invites interested parties to take a look at his work, which includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation. Murch has analyzed the Coin Selection problem and created a framework to simulate wallet behavior on the basis of a sequence of payments. He plans to publish the simulation code around Scaling Bitcoin or after he turns in his thesis.Murch also addresses a question from Daniel Weigl regarding why Mycelium generates a very big UTXO set for 5460sat. Murch explains that his simulation of the Mycelium coin selection adds small change outputs to the fee but got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Therefore, the results in the table might be slightly too big, but likely indicative of the actual Mycelium behavior. Murch assumes that Mycelium doesn't create small change outputs but rather hardly ever spends them when received. Murch believes that Mycelium appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up.A researcher, Murch, has analyzed the Coin Selection problem and re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. As part of this research, Murch created a framework to simulate wallet behavior on the basis of a sequence of payments. The simulation results are presented in a two-page description along with three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Murch also invited feedback and requested another sequence of incoming and outgoing payment amounts to run the simulation on. In response to Murch's email, Daniel Weigl, from Mycelium, inquired about the behavior of Mycelium coin selection algorithm. Murch clarified that Mycelium selects UTXO in a FIFO approach, but prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems to be the likely reason for Mycelium's small UTXO build-up. BreadWallet uses a very similar FIFO approach, but doesn't prune which causes their average UTXO set to be much smaller. A balanced approach between these two approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, who is compiling his Master's thesis about Coin Selection, has created a framework to simulate wallet behavior on the basis of a sequence of payments. He re-implemented multiple coin selection strategies of prominent Bitcoin wallets including Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF containing a two-page description of his ongoing work includes preliminary simulation results and three figures showing the simulated wallets' UTXO compositions at the end of the simulation.Daniel Weigl asked about Mycelium's large UTXO set for 5460sat (=TransactionUtils.MINIMUM_OUTPUT_VALUE). Murch replied that his simulation did add small change outputs to the fee, but he got the boundary wrong. Instead of the 5460, he dropped at the dust boundary which calculates to 4440 in his simulation. Murch corrected the boundary in his simulation now and will update his simulation results before Scaling Bitcoin. Regarding Mycelium, Murch stated that it doesn't create small change outputs but rather hardly ever spends them when received. It appears to select UTXO in a FIFO approach, but after the selection, prunes by removing the smallest selected UTXO until the excess beyond the spending target is minimized. This post-selection step seems the likely reason for Mycelium's small UTXO build-up. A balanced approach between BreadWallet's and Mycelium's approaches might be that instead of pruning all small inputs, a few of the small inputs could be allowed to be selected to slowly drain low-value UTXO out of the wallet by spending them over time.Murch, a researcher, has compiled his Master's thesis about Coin Selection and his presentation proposal to Scaling Bitcoin has been accepted. In his thesis, he analyzed the Coin Selection problem, created a framework to simulate wallet behavior on the basis of a sequence of payments, and re-implemented multiple coin selection strategies of prominent Bitcoin wallets such as Bitcoin Core, Mycelium, Breadwallet, and Android Wallet for Bitcoin. The PDF contains a two-page diff --git a/static/bitcoin-dev/Sept_2016/combined_Proposed-BIP-1-change-removing-OPL-licensing-option-.xml b/static/bitcoin-dev/Sept_2016/combined_Proposed-BIP-1-change-removing-OPL-licensing-option-.xml index 4558224f67..25af4687bd 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Proposed-BIP-1-change-removing-OPL-licensing-option-.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Proposed-BIP-1-change-removing-OPL-licensing-option-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposed BIP-1 change removing OPL licensing option. - 2025-09-26T16:00:27.618264+00:00 + 2025-10-11T22:14:16.952603+00:00 python-feedgen Peter Todd 2016-09-27 19:17:07+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Proposed BIP-1 change removing OPL licensing option. - 2025-09-26T16:00:27.618401+00:00 + 2025-10-11T22:14:16.952733+00:00 2016-09-27T19:17:07+00:00 In a Bitcoin developer email thread, Peter Todd expressed concerns about the Open Patent License (OPL) being more restrictive than the Bitcoin Core license and its potential impact on shipping documentation with code. He acknowledged that different licenses for documentation and code are common practice but emphasized that the issue lies in the OPL's significant restrictions. Peter suggested considering Luke's BIP2 revival proposal as a more formal solution. Tom, in response, recommended dual-licensing documentation with a code-oriented license if it includes example code. He also announced that his own BIP is now dual-licensed under the Creative Commons license. Peter appreciated the suggestion and agreed that CC-BY-SA is a suitable license for this purpose.A revision to BIP-1 proposes removing the option to license work under the OPL. The OPL contains clauses that allow licensors to prohibit print publication and creation of modified versions without their approval. These attribution requirements are considered too restrictive by Debian, leading them to not consider the OPL acceptable for works included in their distribution. Only two BIPs, BIP145 and BIP134, have used the OPL. It is noted that the OPL is significantly more restrictive than the Bitcoin Core license, which poses challenges if documentation cannot be shipped with the code.The proposal to revise BIP-1 aims to eliminate the option to license work under the OPL due to its problematic clauses. Instead, it suggests incorporating a permissive 2-clause BSD license as an alternative. The author of the proposal questions whether those involved in the project were aware of these clauses when including them. They believe that the OPL hinders a transparent, public, and collaborative process for developing interoperability standards. The project that created the OPL has recommended using Creative Commons licenses since 2007 as a more suitable alternative. diff --git a/static/bitcoin-dev/Sept_2016/combined_Requesting-BIP-assignment-Flexible-Transactions-.xml b/static/bitcoin-dev/Sept_2016/combined_Requesting-BIP-assignment-Flexible-Transactions-.xml index fff950434c..a7b03d184b 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Requesting-BIP-assignment-Flexible-Transactions-.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Requesting-BIP-assignment-Flexible-Transactions-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Requesting BIP assignment; Flexible Transactions. - 2025-09-26T16:00:42.661554+00:00 + 2025-10-11T22:14:31.829899+00:00 python-feedgen Tom 2016-09-23 13:17:52+00:00 @@ -97,10 +97,11 @@ + 2 Combined summary - Requesting BIP assignment; Flexible Transactions. - 2025-09-26T16:00:42.661721+00:00 + 2025-10-11T22:14:31.830065+00:00 2016-09-23T13:17:52+00:00 There are ongoing discussions in the Bitcoin community about options for serializing transactions. Two options being considered are Protocol Buffers (protobuf) and Compact Message Format (CMF). CMF is already used in Bitcoin Classic transactions and offers advantages such as reusing var-int parsing and better error reporting. Additionally, CMF is more compact and requires less tool support than protobuf.There is a suggestion to use Protobuf based on a BIP (Bitcoin Improvement Proposal), as it is compact, binary, and flexible. The payment protocol already uses Protobuf, making it an attractive option for further implementation. Protobuf also has good tool support.In an email exchange between Peter Todd and Tom, the issue of serializing transactions in a certain order is discussed. Tom believes that if the order of tokens is not fixed, it could lead to multiple interpretations of data, which is not allowed. Peter Todd suggests using a "Some/None" flag to mark whether optional data has been omitted, instead of fixed token orders. This suggestion is already addressed in the spec, which uses a generic concept where each field is given a name. Peter Todd also suggests extending the merkle tree down into transaction inputs and outputs.Tom, a member of the bitcoin-dev mailing list, requests a BIP number for his Flexible Transactions (FT) specification. He is advised to open a pull request on the bitcoin/bips repository after further discussion. The new version of 'script' (version 2) simplifies the data signed to be equivalent to the transaction-id. However, some functionality is lost, leading to questions about replacing SIGHASH_SINGLE and SIGHASH_ANYONECANPAY. It is suggested to add the ability to use only a hash of the prevout's scriptPubKey in the input. The token ScriptVersion is currently not allowed, but addressing block-malleability by extending the merkle tree to include the hash of v4 transactions alone is proposed.In another bitcoin-dev email thread, Tom discusses the serialization order of tokens in transactions and the need for a fixed order to avoid multiple interpretations. He suggests using a flag for optional data. Compatibility with existing software and extending the merkle tree into transaction inputs and outputs are also discussed.Tom formally requests the assignment of a BIP number for his FT spec, titled "Flexible Transactions." The proposal aims to make Bitcoin's transactions more flexible and easier to extend while fixing malleability issues and resolving technical debt. It introduces a new version number (4) and defines the use of Compact Message Format (CMF) for data following the version bytes. The proposal allows for new features to be added more cleanly in the future and shows that signatures can be removed from transactions with minimal software upgrades. The proposal specifies the serialization order for well-formatted transactions and includes changes to Bitcoin-script. The reference implementation can be found in Bitcoin Classic beta releases, but the deployment process is yet to be determined. diff --git a/static/bitcoin-dev/Sept_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml b/static/bitcoin-dev/Sept_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml index 1c621de6d4..fb35a208c7 100644 --- a/static/bitcoin-dev/Sept_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml +++ b/static/bitcoin-dev/Sept_2016/combined_ScalingBitcoin-2015-Retarget-Call-For-Proposals-Now-Open.xml @@ -2,7 +2,7 @@ 2 Combined summary - ScalingBitcoin 2015: Retarget - Call For Proposals Now Open - 2025-09-26T16:00:25.472532+00:00 + 2025-10-11T22:14:14.828277+00:00 python-feedgen Matt Corallo 2016-09-01 00:56:08+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - ScalingBitcoin 2015: Retarget - Call For Proposals Now Open - 2025-09-26T16:00:25.472667+00:00 + 2025-10-11T22:14:14.828514+00:00 2016-09-01T00:56:08+00:00 The Scaling Bitcoin 2016: Retarget conference has extended its deadline for submissions to September 9th. This year, the conference is offering rolling acceptance in an effort to respond to most proposals before September 23rd. The conference defines "scaling" broadly, encompassing topics such as improving Bitcoin throughput, layer 2 ideas, security and privacy, incentives and fee structures, testing, simulation and modeling, network resilience and latency, fungibility, anti-spam measures, block size proposals, and mining concerns.The Call for Proposals (CFP) was opened on August 2nd and can be found on the scalingbitcoin.org website. Interested parties who wish to submit their proposals have until September 2nd to do so. After the submission deadline, applicants will be notified of their acceptance status by September 23rd. The Scaling Bitcoin 2016: Retarget conference will take place in Milan on October 8th and 9th. For more information and to access the CFP, interested individuals can visit the scalingbitcoin.org website. diff --git a/static/bitcoin-dev/Sept_2016/combined_Simple-tx-ID-malleability-fix-opcode-proposal-OP-TXHASHVERIFY.xml b/static/bitcoin-dev/Sept_2016/combined_Simple-tx-ID-malleability-fix-opcode-proposal-OP-TXHASHVERIFY.xml index aa9408eedb..2e2cf74f2e 100644 --- a/static/bitcoin-dev/Sept_2016/combined_Simple-tx-ID-malleability-fix-opcode-proposal-OP-TXHASHVERIFY.xml +++ b/static/bitcoin-dev/Sept_2016/combined_Simple-tx-ID-malleability-fix-opcode-proposal-OP-TXHASHVERIFY.xml @@ -2,7 +2,7 @@ 2 Combined summary - Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY - 2025-09-26T16:00:44.846311+00:00 + 2025-10-11T22:14:33.954110+00:00 python-feedgen Nick ODell 2016-09-17 22:34:43+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY - 2025-09-26T16:00:44.846494+00:00 + 2025-10-11T22:14:33.954291+00:00 2016-09-17T22:34:43+00:00 Rune K. Svendsen has proposed a solution to address transaction ID malleability in the bitcoin-dev mailing list. The solution involves introducing a new opcode called OP_TXHASHVERIFY. This opcode would only work if added as the very first operation in a scriptSig. If the hash of the transaction with all OP_TXHASHVERIFY operations removed does not match what has been pushed on the stack, the operation will be aborted.To protect against tx ID malleability, one would need to calculate the tx ID of the transaction and add "0x32 $TX_HASH OP_TXHASHVERIFY" to the beginning of the scriptSig for each input they wish to protect. This solution adds 34 bytes per input. However, it is considered a simple and valuable solution until something better becomes available, such as Segwit.Matt Corallo pointed out that the tx hash in the construction is not signed, which means someone could manipulate a transaction by updating the hash in the scriptSig. Another issue raised by Nick is the circular dependency between Hash1 and Hash2. Rune replied that there is a solution, but it complicates the operation.Overall, the proposed solution by Rune K. Svendsen offers a way to create transactions that are immune to transaction ID malleability. It involves adding a new opcode called OP_TXHASHVERIFY to the scriptSig. Although there are some concerns raised, the solution is seen as valuable in addressing tx ID malleability until a better solution, like Segwit, becomes available. Feedback on the proposal is requested. diff --git a/static/bitcoin-dev/Sept_2017/combined_Fast-Merkle-Trees.xml b/static/bitcoin-dev/Sept_2017/combined_Fast-Merkle-Trees.xml index c883bd35ae..8f82d047a2 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Fast-Merkle-Trees.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Fast-Merkle-Trees.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fast Merkle Trees - 2025-09-26T15:48:33.560112+00:00 + 2025-10-11T21:57:50.446698+00:00 python-feedgen Johnson Lau 2017-09-12 11:44:48+00:00 @@ -41,10 +41,11 @@ + 2 Combined summary - Fast Merkle Trees - 2025-09-26T15:48:33.560258+00:00 + 2025-10-11T21:57:50.446882+00:00 2017-09-12T11:44:48+00:00 In an email exchange on the bitcoin-dev mailing list, Mark Friedenbach discussed a potential attack on Bitcoin's hash trees. The attack involves creating a script that appears safe but is actually controlled by the attacker. Friedenbach presented two possible scripts and suggested modifying the scheme to use a different initialization vector (IV) for hash tree updates to prevent such attacks. However, another user responded with an example of a MAST branch that requires only a few bytes of collision, indicating that the attack may not be as difficult as initially thought.The email thread also discusses the vulnerability of third-party scripts in general. The attack described involves finding a collision between innocuous and malign scripts using different hash functions. Friedenbach explained the procedure for getting a collision and suggested that multi-party wallet level protocols should require a 'delinearization' step to prove the safety of a construct.In response to Russell O'Connor's query about a security breach in the Bitcoin Improvement Proposal (BIP) tree structure, Friedenbach expressed uncertainty about the possibility of conducting the attack described using the specified tree structure. He believes that breaking SHA256 completely would be necessary to accomplish the attack. O'Connor expressed concern about the lack of distinction between leaf nodes and internal nodes in the design, which could lead to vulnerabilities. He suggested using a different IV for the fast hash of internal nodes to mitigate this risk.Peter Todd agreed with O'Connor's proposal for a fast hash for internal nodes, but cautioned against creating new hash functions using custom IVs. He suggested using bog-standard SHA256 with a fixed first block to allow optimized implementations to start with a fixed midstate. Todd clarified that using custom IVs results in a hash function equivalent to prefixing the data with the padded version of the fixed string and using a regular SHA256 hash.The design of fast Merkle trees does not distinguish between leaf nodes and internal nodes, allowing for validation of paths longer than 32 branches. However, this lack of distinction poses a security risk. O'Connor demonstrated how counterparty could include specially crafted "scripts" masquerading as leaves, allowing them to reveal malicious code at a deeper level. O'Connor suggested using a fixed IV value for the fast hash of internal nodes to address this vulnerability.In a recent email, O'Connor proposed that the fast hash for internal nodes should use a fixed value that is the SHA-256 hash of a fixed string. However, it is noted that new hash functions should generally not be created by using custom IVs. Instead, bog-standard SHA256 should be used with a fixed first block.Overall, the discussions revolve around the potential attack on Bitcoin's hash trees, the vulnerability of third-party scripts, and the need for modifications in the design of fast Merkle trees to prevent attacks and address security risks. The provided links contain additional information and code related to these topics. diff --git a/static/bitcoin-dev/Sept_2017/combined_Fwd-Compressed-headers-stream.xml b/static/bitcoin-dev/Sept_2017/combined_Fwd-Compressed-headers-stream.xml index 0303aa0908..9a38bfded1 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Fwd-Compressed-headers-stream.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Fwd-Compressed-headers-stream.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fwd: "Compressed" headers stream - 2025-09-26T15:48:48.301651+00:00 + 2025-10-11T21:57:56.823220+00:00 python-feedgen Peter Todd 2017-09-04 14:06:44+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - Fwd: "Compressed" headers stream - 2025-09-26T15:48:48.301810+00:00 + 2025-10-11T21:57:56.823363+00:00 2017-09-04T14:06:44+00:00 In a discussion on the bitcoin-dev mailing list, Gregory Maxwell highlighted various methods to reduce the number of bytes required for block headers. These techniques involve minimizing changes to the bits field, setting the timestamp to be slightly higher than the previous one, and recognizing that the block version is typically one of the last few. However, these improvements offer only a constant factor reduction in size.The compact SPV proofs, outlined in the appendix of the sidechains whitepaper, introduce logarithmic scaling proofs but solely validate total work, not validity. OpenTimestamps aims to establish a framework for trusted validity attestations, as timestamping via proof-of-work presents security concerns due to the potential manipulation of block times by miners. It is crucial to comprehend the associated risks before implementing compact SPV proofs. Additionally, there may be an opportunity to enhance initial download bandwidth by including a known-good sum-merkle-tree tip hash with the software.Riccardo Casatta expressed his belief in an email to bitcoin-dev that Bitcoin headers represent the most vital data globally, with an anticipated increase in demand. He proposed optimizing transmitted data when sending a continuous stream of block headers by eliminating the transmission of previous hashes after the first header. The receiver can calculate the previous hash by double hashing the previous header, which is necessary for verifying the proof of work. This approach could potentially save approximately 40% in bandwidth when transmitting a lengthy sequence of block headers.However, another participant in the discussion countered this suggestion by mentioning alternative ways to reduce bytes in the block headers field, such as avoiding changes to the bits field every 2016 blocks or only including the timestamp if it surpasses the median of the last 11 blocks. These optimizations also provide only a constant factor reduction in size. The contributor recommended exploring the compact SPV proofs described in the appendix of the sidechains whitepaper for logarithmic scaling proofs. diff --git a/static/bitcoin-dev/Sept_2017/combined_Fwd-Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml b/static/bitcoin-dev/Sept_2017/combined_Fwd-Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml index 676c75de2b..951a3e83a3 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Fwd-Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Fwd-Sidechain-headers-on-mainchain-unification-of-drivechains-and-spv-proofs-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs) - 2025-09-26T15:48:46.187568+00:00 + 2025-10-11T21:57:54.700273+00:00 python-feedgen ZmnSCPxj 2017-09-10 05:33:06+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs) - 2025-09-26T15:48:46.187734+00:00 + 2025-10-11T21:57:54.700445+00:00 2017-09-10T05:33:06+00:00 In an email exchange, Bitcoin developers Paul and ZmnSCPxj discuss the concept of sidechains with merge mining and WT^ validity voting. Paul expresses concern that this approach would cause sidechain headers on mainchain (SHOM) to become mere extension blocks and inherit negative properties. He also disagrees with the idea that the power to determine the validity of a sidechain should rest with the economic majority rather than the miners, as he believes a 51% miner-group could manipulate transactions. However, ZmnSCPxj argues that if a miner rejects a bribe to prioritize their desired hash on the sidechain, it implies they value their hash more than the bribe. They both agree that some miners prioritize short-term profits over long-term interests, based on observations in Bcash and Bitcoin.The discussion also delves into the vulnerability of SHOM sidechains to collapse from theft attempts. While potential thieves may be disincentivized by understanding the dollar-auction irrationality, the problem lies in relying on rational behavior from thieves. Additionally, Paul raises concerns about the weakness of the side-to-main peg in SHOM and suggests that capping withdrawals further weakens its usefulness. They explore the possibility of deploying sidechains initially as federated pegs, with a potential transition to drivechain/sidechain-headers-on-mainchain at a later stage. This transition would involve moving controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes. Sergio supports this idea, but Paul sees it as a lack of faith in the design. Both parties agree that sidechains should only be softforked and never hardforked.The email thread also touches upon the mechanism supporting sidechains, which can facilitate any financial system, including centralized non-blockchain systems. ZmnSCPxj emphasizes the importance of not allowing permissioned methods for starting sidechains, while expressing support for an economic bond or proof-of-burn as a starting point. The discussion concludes with references to the specification for WT^ layout and available documentation on the topic.Overall, the email exchange presents both agreements and disagreements related to sidechains, highlighting concerns about regression to extension blocks, control over validity, miner behavior, security vulnerabilities, side-to-main peg strength, deployment strategies, and the inclusivity of different financial systems. diff --git a/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32.xml b/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32.xml index 59deef71e8..3318f6672c 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Proposal-Extended-serialization-format-for-BIP-32.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposal: Extended serialization format for BIP-32 - 2025-09-26T15:48:37.770818+00:00 + 2025-10-11T21:57:52.572841+00:00 python-feedgen shiva sitamraju 2017-09-12 12:06:40+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - Proposal: Extended serialization format for BIP-32 - 2025-09-26T15:48:37.770971+00:00 + 2025-10-11T21:57:52.573015+00:00 2017-09-12T12:06:40+00:00 The Bitcoin-dev mailing list recently had two discussions. The first discussion focused on Merkle branch verification and tail-call semantics for generalized MAST. Johnson Lau and Mark Friedenbach discussed the design concerns, including the use of "unclean stake" which is invalid in BIP141. They also discussed SigOp counting and suggested a unified global limit that combines all factors. In the second discussion, Thomas Voegtlin proposed an extended serialization format for BIP-32 wallets. Shiva Sitamraju expressed concerns about the privacy implications of the birth-date field and the complete derivation path. Thomas replied that different versions do not have the same address as per bip173. The debate also included whether the OutputType field should be present only if depth==0x00 or at all times. Andreas Schildbach, Pavol Rusnak, and Thomas Voegtlin shared their opinions on the issue.Another discussion focused on Mark Friedenbach's proposal to update the fast Merkle-tree spec to use a different IV. This would prevent attacks where innocent scripts could be replaced by malicious ones. The attack requires a collision between double-SHA256(innocuous) and fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) || r1) || r0).There was also talk about whether to add an extended serialization format for BIP-32 wallets. Suggestions were made to add an OutputType field for wallets that do not follow BIP43, while others suggested omitting the field in cases where script types are mixed. Thomas Voegtlin suggested that this value should be user visible, as users need to combine several master public keys when creating wallets with multisig scripts.It was noted that good security for Bitcoin is not defined by constant upgrading, and efforts should be put into backporting fixes/workarounds. Altcoin maintainers were encouraged to contribute back to their upstream to help keep up with security fixes. Sergio Demian Lerner mentioned the policy of publishing vulnerabilities in Bitcoin only after more than 80% of the nodes have upgraded.Overall, the discussions on the Bitcoin-dev mailing list covered various topics such as Merkle branch verification, tail-call semantics, serialization format for BIP-32 wallets, trust in scripts, and preventing attacks on MAST policy. Different perspectives were shared, and suggestions were made to improve the design and security of Bitcoin. diff --git a/static/bitcoin-dev/Sept_2017/combined_Proposal-bip32-version-bytes-for-segwit-scripts.xml b/static/bitcoin-dev/Sept_2017/combined_Proposal-bip32-version-bytes-for-segwit-scripts.xml index 35681295e3..80e689b0cb 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Proposal-bip32-version-bytes-for-segwit-scripts.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Proposal-bip32-version-bytes-for-segwit-scripts.xml @@ -2,7 +2,7 @@ 2 Combined summary - Proposal: bip32 version bytes for segwit scripts - 2025-09-26T15:49:28.299577+00:00 + 2025-10-11T21:58:05.321409+00:00 python-feedgen Luke Dashjr 2017-09-07 19:02:17+00:00 @@ -45,10 +45,11 @@ + 2 Combined summary - Proposal: bip32 version bytes for segwit scripts - 2025-09-26T15:49:28.299745+00:00 + 2025-10-11T21:58:05.321551+00:00 2017-09-07T19:02:17+00:00 On September 5th, 2017, a discussion took place on the Bitcoin-dev forum regarding the serialization format of HD seeds. Kabuto Samourai addressed a possible miscommunication between Luke and Thomas regarding the encoding of {x,y,z}{pub,prv} distinctions when exporting a root master HD seed. They argued that this encoding is unnecessary as the root seed should derive all paths for all coins. However, they suggested that changing the serialization version bytes is appropriate and essential when exporting/importing an account-level seed for watch-only and receive address generation to avoid loss of funds. Luke proposed revisiting a proposal he made in March that handles not only simple HD seeds but also multisig HD and similar cases.Pavol Rusnak, the CTO of SatoshiLabs, suggested using a child number field instead of a fingerprint in the serialization format. He believed that it would be desirable to use the same seed for all different script formats. If he were designing the format today, he would drop the fingerprint and expand the child number to the full BIP32 path. The benefit of this proposal is that the depth already exists, so it is known how long the BIP32 path would be. The proposal included using 4 byte version bytes, 1 byte depth, depth * 4 bytes bip32 path, 32 bytes, and 33 bytes.The email thread also discussed expanding the number of version prefixes to eliminate ambiguity regarding P2SH scripts. Thomas Voegtlin expressed concerns about reaching consensus and the need for extra safeguards if this change were to be implemented. He proposed the "xyz" proposal as a simpler solution that would require minimal changes to existing software. However, Kabuto argued that separating P2SH from P2PKH may not have strong benefits due to the infinite possibilities of P2SH scripts.Another proposal was made to develop a new standard based on Bech32 for including the key or wallet birthdate. Thomas Voegtlin suggested using additional version bytes to indicate the type of output script used with the public keys. He recommended that this change should be visible to users, and he proposed prefixes such as xpub/xprv for P2PKH or P2SH, ypub/yprv for (P2WPKH or P2WSH) nested in P2SH, and zpub/zprv for P2WPKH or P2WSH. It was argued that xpub/xprv serialization should not be used to encode how these keys are used, but the existence of version bytes used to signal whether keys will be used on testnet or mainnet goes against this argument. Without signaling the script type in the version bytes, developers might resort to using "dirtier tricks" such as the bip32 child number field in combination with bip43/bip44/bip49.In the ongoing debates within the Bitcoin development community, Luke Dashjr suggested using the same seed for all different script formats, while Thomas Voegtlin disagreed with this view. Voegtlin argued that wallets must implement all script formats to ensure users can recover their funds from their mnemonic seed. He also disagreed with Dashjr's statement that xpub/xprv are already being used for both P2PKH and P2SH, highlighting that this has resulted in users receiving coins on addresses they do not control.The discussion also touched upon the use of xpub/xprv serialization to encode how keys are used. Voegtlin argued that this should be done instead of just considering it a format for keys. Dashjr, on the other hand, suggested using the child number field instead of version bytes for signaling the script type. The conversation shed light on the ongoing debates regarding key management and storage practices within the Bitcoin development community.In a forum post, Thomas Voegtlin provided a table of different prefixes and their corresponding descriptions related to P2PKH or P2SH and (P2WPKH or P2WSH) nested in P2SH. Pavol Rusnak, as the CTO of SatoshiLabs, responded to an argument regarding xpub/xprv serialization, stating that he was fine with it, but it is unclear which specific proposal he was referring to.The recommendation for BIP32 extended public/private keys is to use version bytes that indicate the user-visible xpub/xprv prefix. Different version bytes are suggested for other networks, such as tpub/tprv for testnet. The proposed changes aim to inform the receiving utility about the exact derivation method used for pubkeys, ensuring that third parties handling xpubs do not require additional information from users. The ongoing discussions reflect efforts to improve key management and storage practices while considering the challenges faced by wallet implementations and the need for consensus within the Bitcoin development community. diff --git a/static/bitcoin-dev/Sept_2017/combined_Why-the-BIP-72-Payment-Protocol-URI-Standard-is-Insecure-Against-MITM-Attacks.xml b/static/bitcoin-dev/Sept_2017/combined_Why-the-BIP-72-Payment-Protocol-URI-Standard-is-Insecure-Against-MITM-Attacks.xml index ac29cd04fc..ed712058d0 100644 --- a/static/bitcoin-dev/Sept_2017/combined_Why-the-BIP-72-Payment-Protocol-URI-Standard-is-Insecure-Against-MITM-Attacks.xml +++ b/static/bitcoin-dev/Sept_2017/combined_Why-the-BIP-72-Payment-Protocol-URI-Standard-is-Insecure-Against-MITM-Attacks.xml @@ -2,7 +2,7 @@ 2 Combined summary - Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks - 2025-09-26T15:49:15.670350+00:00 + 2025-10-11T21:58:01.071779+00:00 python-feedgen Andreas Schildbach 2017-09-30 15:33:01+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks - 2025-09-26T15:49:15.670512+00:00 + 2025-10-11T21:58:01.071945+00:00 2017-09-30T15:33:01+00:00 The BIP-70 payment protocol used through BIP-72 URI's has been a topic of debate due to security concerns. Payment QR codes do not cryptographically commit to the identity of the merchant, allowing hijackers to redirect payments if they acquire an SSL certificate that a wallet accepts. However, HTTPS assumes secure certificates. Instead of using the payment protocol, some prefer to email or print bitcoin addresses on invoices.There is a need for a new BIP to replace BIP-72, which is considered dangerous in its current form. The current https principles are seen as outdated, particularly the concept of certificates tied to a domain. The author suggests evolving it into certificates tied to an entityID managed by a blockchain system. The author also argues against specifying things for Bitcoin like the web, as browsers can do better.Using the payment protocol means paying to a secure endpoint rather than an address. It offers benefits such as preventing address reuse, eliminating the need for mempool synchronization among non-miners, and improving privacy by enabling light clients to know when a transaction is coming in. Implementing the payment protocol widely is key to scaling.The BIP-70 payment protocol has overhead and requires back and forth communication, making it less preferable compared to emailing or printing bitcoin addresses. The BIP-72 URI's used by the payment protocol are insecure, as payment QR codes do not commit to the merchant's identity. This allows a man-in-the-middle attacker to redirect payments. Deprecating BIP-72 and introducing a new BIP is necessary.Wallets should use the bitcoin address for integrity checks to mitigate risk. The BIP could be enhanced by deriving the bitcoin address from the merchant pub key and hash, enabling independent generation of addresses by both customers and merchants. Wallets may discard important information when using the payment protocol, giving MITM attackers another chance to redirect payments. Off-the-shelf SSL libraries with infrequently updated root certificates are commonly used by wallets.In conclusion, the BIP-70 payment protocol has security concerns and requires improvement. BIP-72 should be deprecated and replaced with a new BIP. Android Wallet for Bitcoin includes a parameter that adds a hash commitment to the payment request, but it is not part of the standard itself. The discussion on the Bitcoin development mailing list highlights the need for addressing these issues. diff --git a/static/bitcoin-dev/Sept_2017/combined_cleanstack-alt-stack-softfork-improvements-Was-Merkle-branch-verification-tail-call-semantics-for-generalized-MAST-.xml b/static/bitcoin-dev/Sept_2017/combined_cleanstack-alt-stack-softfork-improvements-Was-Merkle-branch-verification-tail-call-semantics-for-generalized-MAST-.xml index 2b092c5f63..1d7074f0dd 100644 --- a/static/bitcoin-dev/Sept_2017/combined_cleanstack-alt-stack-softfork-improvements-Was-Merkle-branch-verification-tail-call-semantics-for-generalized-MAST-.xml +++ b/static/bitcoin-dev/Sept_2017/combined_cleanstack-alt-stack-softfork-improvements-Was-Merkle-branch-verification-tail-call-semantics-for-generalized-MAST-.xml @@ -2,7 +2,7 @@ 2 Combined summary - cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) - 2025-09-26T15:49:05.110222+00:00 + 2025-10-11T21:57:58.948456+00:00 python-feedgen Luke Dashjr 2017-09-21 16:33:16+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) - 2025-09-26T15:49:05.110374+00:00 + 2025-10-11T21:57:58.948601+00:00 2017-09-21T16:33:16+00:00 On September 21, 2017, a discussion took place regarding the understanding of SigAgg, a softfork that aggregates signatures on bitcoin transactions. The possibility of old clients comprehending the aggregation produced by new clients was debated. It was suggested that more witness space could be utilized to store (pubkey, message) pairs, enabling old clients to understand the aggregation. However, this approach was deemed counterproductive as it defeated the purpose of aggregation.It was clarified that since SigAgg is a softfork, old clients would not be able to understand it. An alternative solution was proposed, which involved implying stack items if the Script engine is designed to support it upfront. This would allow the engine to behave as if it were non-verify while maintaining backward compatibility. When questioned about how an OP_MUL could be derived from an OP_NOP, it was explained that new clients would execute it as an OP_MUL and inject pops/pushes when sending the transaction to older clients. This suggested approach would likely need to be part of a MAST-like softfork to be feasible.Johnson Lau addressed the issue of OP_RETURNTRUE not working well with signature aggregation in a message on the Bitcoin development mailing list. Signature aggregation combines (pubkey, message) pairs in a transaction and verifies them with one signature. However, for old nodes, the script terminates at OP_RETURNTRUE, thereby preventing the collection of the (pubkey, message) pair. Lau proposed transforming OP_RETURNTRUE into OP_17 via a softfork. This would enable new nodes to collect the (pubkey, message) pair and attempt to aggregate it with other pairs, potentially resulting in a hardfork.Luke Dashjr countered that this issue should be addressed by signature aggregation itself, rather than relying on modifying OP_RETURNTRUE. Dashjr suggested setting up signature aggregation upfront and having the Script verify the inclusion of keys in the aggregation. Another suggestion made by Dashjr was to create any opcode with an OP_NOP. For instance, if an OP_MUL is desired, an OP_MULVERIFY could be introduced, which would verify if the 3rd stack item is the product of the top 2 stack items.During the discussion session, the idea of maintaining tail-call semantics through the use of the alt stack for transferring arguments to the policy script was proposed. Additionally, a question arose regarding whether this could be considered a bug in the cleanstack rule. The participants also deliberated on the notion of replacing all NOPs and unallocated opcodes with a new OP_RETURNTRUE implementation in future versions of Script. This would cause the program to immediately exit, potentially performing semantic checks on the remaining script. The advantage of this approach is that it allows for softforking in any new opcode, not limited to the -VERIFY opcode variants that have been introduced. Old nodes would always succeed immediately upon encountering an undefined opcode, granting the new opcode the ability to perform any action from that point onward. It should be noted that while this approach is similar to CVE-2010-5141, it shouldn't be exploitable as signatures are no longer treated as scripts themselves. diff --git a/static/bitcoin-dev/Sept_2017/combined_hypothetical-Could-soft-forks-be-prevented-.xml b/static/bitcoin-dev/Sept_2017/combined_hypothetical-Could-soft-forks-be-prevented-.xml index 4c6e05e826..1f43283c5c 100644 --- a/static/bitcoin-dev/Sept_2017/combined_hypothetical-Could-soft-forks-be-prevented-.xml +++ b/static/bitcoin-dev/Sept_2017/combined_hypothetical-Could-soft-forks-be-prevented-.xml @@ -2,7 +2,7 @@ 2 Combined summary - hypothetical: Could soft-forks be prevented? - 2025-09-26T15:49:17.784040+00:00 + 2025-10-11T21:58:03.195086+00:00 python-feedgen Daniel Wilczynski 2017-09-18 06:40:18+00:00 @@ -53,10 +53,11 @@ + 2 Combined summary - hypothetical: Could soft-forks be prevented? - 2025-09-26T15:49:17.784185+00:00 + 2025-10-11T21:58:03.195247+00:00 2017-09-18T06:40:18+00:00 In a discussion on the bitcoin-dev mailing list, the topic of preventing soft forks in cryptocurrency software is explored. Daniel Wilczynski suggests that built-in wipeout protection would be a better solution to protect the majority from threatening a minority with a wipeout in the event of a soft fork scenario. This can be achieved through automated consensus critical checkpoints or other mechanisms. However, implementing built-in wipeout protection would turn soft forks into hard forks.The conversation also delves into the possibility of creating an un-soft-forkable cryptocurrency. Andrew Poelstra suggests that designing for maximal fungibility and transaction structures that minimize interaction with the blockchain could minimize the surface for transaction censorship. Simone Bronzini proposes a simple cryptocurrency where only the public key and amount are indicated in the transaction output, but acknowledges that it could still potentially be soft-forked. The primary goal of this thought experiment is to prevent new functionality from being added arbitrarily.ZmnSCPxj argues that it is impossible to prevent soft forks entirely. They provide examples of anyone-can-spend scripts that are currently disallowed from propagation but could still be included in a block by a miner. ZmnSCPxj also notes the possibility of miners running secret soft-forking code. The only way to prevent soft forks is to hard fork against them. Adam Back expresses concern about the potential manipulation of consensus rule changes through political means. He seeks solutions to prevent the tyranny of the majority that could undermine network-wide consensus rule changes.The article mentions that soft forks create a new class of transactions that interact with DAOs. Ethereum, for example, can't soft fork and always has to hard fork. Dan Libby is interested in the possibility of a cryptocurrency with immutable consensus rules. Soft forks rely on anyone-can-spend transactions, and removing them could effectively prevent soft forks. It is also possible to programmatically avoid/ban soft forks.The discussion on preventing soft forks continues, with Adam Back and ZmnSCPxj pointing out the practical challenges of banning anyone-can-spend outputs and the possibility of miners running soft-forking code secretly. Soft forks apply further restrictions on Bitcoin, while hard forks do not. The only way to prevent a soft fork is to hard fork against it. The goal of creating an un-soft-forkable cryptocurrency is discussed, but it is noted that preventing new functionality may be the primary objective of this thought experiment.In conclusion, preventing soft forks entirely is considered impractical, as there are too many potential scriptPubKey options. Soft forks can apply further restrictions on a cryptocurrency, and miners can run soft-forking code without the rest of the community knowing. Hard forking against a soft fork is the only way to prevent it. The possibility of creating a cryptocurrency with immutable consensus rules is explored, with considerations for fungibility and minimizing interaction with the blockchain. However, the feasibility of preventing soft forks and the practicality of implementing these ideas are also questioned. diff --git a/static/bitcoin-dev/Sept_2018/combined_-bitcoin-core-dev-Bitcoin-Core-update-notice.xml b/static/bitcoin-dev/Sept_2018/combined_-bitcoin-core-dev-Bitcoin-Core-update-notice.xml index dccc9a733d..d8093df56b 100644 --- a/static/bitcoin-dev/Sept_2018/combined_-bitcoin-core-dev-Bitcoin-Core-update-notice.xml +++ b/static/bitcoin-dev/Sept_2018/combined_-bitcoin-core-dev-Bitcoin-Core-update-notice.xml @@ -2,7 +2,7 @@ 2 Combined summary - [bitcoin-core-dev] Bitcoin Core update notice - 2025-09-26T15:55:58.837936+00:00 + 2025-10-11T22:04:53.510042+00:00 python-feedgen Gregory Maxwell 2018-09-22 04:59:53+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - [bitcoin-core-dev] Bitcoin Core update notice - 2025-09-26T15:55:58.838079+00:00 + 2025-10-11T22:04:53.510198+00:00 2018-09-22T04:59:53+00:00 In a recent Bitcoin-dev mailing list, a user expressed concerns about the hype surrounding the need to upgrade to Bitcoin Core version 0.16.3 immediately. Another user clarified that the bugfix has already been backported to earlier versions and that the announcement on the Bitcoin Core site is clear. However, it is still recommended to upgrade to the latest version to avoid potential issues. Running older versions can lead to network exploitable crashes, which can result in double-spends and long valid forks. The recommendation to upgrade to the latest version comes from the need to protect people from harm.The bug fix for CVE-2018-17144 was released in Bitcoin Core version 0.16.3. This update is highly recommended for all network participants. The patch can also be backported to earlier versions, but the backported versions are still undergoing the Gitian build process and have not been released yet. There has been some hype and hysteria surrounding the immediate upgrade to version 0.16.3, which has been discussed on forums and Reddit. However, efforts to correct this misinformation have not been seen yet.For those who build from source, the fixed versions of the 0.14, 0.15, 0.16, 0.17, and master branches are available on GitHub. Despite the availability of the bugfix in earlier versions and the option to build from source, the urgency to upgrade to version 0.16.3 has not been addressed adequately, and there is a lack of effort to correct the misinformation being spread on forums and Reddit. diff --git a/static/bitcoin-dev/Sept_2018/combined_-bitcoin-discuss-Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml b/static/bitcoin-dev/Sept_2018/combined_-bitcoin-discuss-Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml index e117bc2056..9d02b31073 100644 --- a/static/bitcoin-dev/Sept_2018/combined_-bitcoin-discuss-Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml +++ b/static/bitcoin-dev/Sept_2018/combined_-bitcoin-discuss-Proposal-to-replace-full-blockchain-with-recent-history-plus-UTXO-Set.xml @@ -2,7 +2,7 @@ 2 Combined summary - [bitcoin-discuss] Proposal to replace full blockchain with recent history plus UTXO Set - 2025-09-26T15:56:15.840605+00:00 + 2025-10-11T22:04:55.633800+00:00 python-feedgen CryptAxe 2018-09-26 00:00:03+00:00 @@ -13,10 +13,11 @@ + 2 Combined summary - [bitcoin-discuss] Proposal to replace full blockchain with recent history plus UTXO Set - 2025-09-26T15:56:15.840750+00:00 + 2025-10-11T22:04:55.633955+00:00 2018-09-26T00:00:03+00:00 The Bitcoin mailing list recently discussed a proposal to replace the full blockchain with a UTXO (Unspent Transaction Output) set. This idea suggests that a UTXO block set type could be appended onto the valid chain at certain intervals, containing only the validated UTXO set up to a specific height. By doing this, full nodes would be relieved of the need to store the entire blockchain, leading to significant storage savings and making it easier to run a full node.However, implementing this proposal has consensus implications, and there are some bugs that need to be addressed. The email provides links to an implementation of UTXO loading as well as a script for the open-source Game-of-Life software Golly. In addition, a video was shared demonstrating the game playing out into an apron-shaped image.To encourage participation, the author of the proposal offers a reward of $50 worth of bitcoin to anyone who can provide them with a UTXO Set from the bitcoin client. The goal is to create a recognizable checkpoint for the Bitcoin blockchain, which would facilitate the adoption of full nodes by more people in the future.Overall, the proposal aims to improve the efficiency of running full nodes by replacing the full blockchain with a UTXO set recognizable at a certain block height. This could potentially save storage space and make it easier for more individuals to participate in the Bitcoin network. diff --git a/static/bitcoin-dev/Sept_2018/combined_Selfish-Mining-Prevention.xml b/static/bitcoin-dev/Sept_2018/combined_Selfish-Mining-Prevention.xml index 50a704cd9e..b89d90d38b 100644 --- a/static/bitcoin-dev/Sept_2018/combined_Selfish-Mining-Prevention.xml +++ b/static/bitcoin-dev/Sept_2018/combined_Selfish-Mining-Prevention.xml @@ -2,7 +2,7 @@ 2 Combined summary - Selfish Mining Prevention - 2025-09-26T15:56:20.135707+00:00 + 2025-10-11T22:04:57.756715+00:00 python-feedgen Andrew 2018-09-18 20:26:16+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - Selfish Mining Prevention - 2025-09-26T15:56:20.135890+00:00 + 2025-10-11T22:04:57.756879+00:00 2018-09-18T20:26:16+00:00 The conversation on the Bitcoin-dev mailing list focused on the 51% problem and potential solutions. Zawy expressed concerns about Andrew's proposal, suggesting that using an average of 144 past blocks to determine a certain parameter could help reduce mining fluctuations. He also mentioned the possibility of issuing too many or too few coins depending on the long-term rise of this parameter. Zawy proposed increasing difficulty instead of reward as an alternative solution, but Eric disagreed, stating that SHA256 is ASIC-friendly, making it difficult for prime number computations to switch quickly to Bitcoin mining.Zawy clarified that his post was addressing not only selfish mining and 51% attacks but also other types of attacks that aim to drive away mining competition. He suggested giving users more control over how their fees are spent by allocating a portion of fees to miners based on hashrate conditions and returning the remaining part to users for future fee payments.Eric mentioned that merge mining could help smooth out hashrate fluctuations, but even without merge mining, there might not necessarily be a destructive feedback loop. The share of a miner's hash power is determined by capital investment rather than the newness of the investment. Higher efficiency mining does not reduce energy consumption, and proof-of-memory (space) shifts energy costs to hardware manufacture and shipment.Users have the ability to set a target hashrate for Bitcoin mining, and as long as the hashrate is rising, miners will gradually receive reserve fees. If the hashrate remains stable or decreases, users get the reserve fees back. However, there is a limit on the hashrate for each level of mining rewards based on demand. Once the hashrate becomes sufficiently large, new miners may not join due to their small share of the hashrate.Merge mining and proof of space are seen as potentially efficient methods in the future, although educating people to use fewer resources falls outside the scope of the Bitcoin software protocol.The 51% problem is a significant concern in the world of cryptocurrency. It amplifies oscillations and motivates miners to exacerbate the problem until a limit is reached. Solutions to this problem include selfish mining prevention and pollution, but these are not actively discussed in the Bitcoin community. Another solution is to increase difficulty instead of reward, which would have a similar effect from a miner's perspective. Andrew proposed a solution involving "reserve fees" that would be paid to miners if the hashrate rises, aiming to prevent selfish mining and other attacks.Damian Williamson expressed concerns about incentivizing increased global resource consumption and its potential harm to the environment. However, Andrew argued that centralization of energy does more harm than total energy consumption and suggested that Bitcoin could help decentralize power and potentially reduce global energy usage.Andrew's proposal for selfish mining prevention involves adding "reserve fees" to transactions. Users can specify a fraction of the fee to be held in reserve for a certain period. If the hashrate rises, the reserve fees will be paid to miners, incentivizing them to maintain a stable hashrate and avoid driving out competition. Damian emphasized the importance of stifling greed and making mining more decentralized and competitive. He suggested approaches unrelated to Andrew's proposal that focus on addressing greed. While Andrew agreed that preventing greed should be a priority, he believes his proposal can work well alongside a dynamic difficulty adjustment algorithm.Andrew proposed adding "reserve fees" to Bitcoin mining as a solution to prevent selfish mining attacks and collusion. These reserve fees would be a fraction of the total fee held in reserve for a specific period. If the hashrate increases, the reserve fees would be paid to miners, encouraging them to maintain a stable hashrate and avoid driving out competition. This proposal requires a soft fork and is voluntary for users. The validation resource requirements for this change are small, and it would be especially important as fees become more significant in the future.Andrew's proposal for selfish mining prevention involves adding "reserve fees" to transactions. The reserve fees would be a fraction of the total fee that is held in reserve for a specific period. If the hashrate rises, the reserve fees will be paid to miners, incentivizing them to maintain a stable hashrate and avoid driving out competition. This proposal is voluntary and requires a soft fork. While there are concerns about increased global resource consumption, Andrew argues that centralization of energy does more harm than total energy consumption and that Bitcoin could help decentralize power and potentially decrease global energy usage.Damian Williamson expressed concerns about the proposed solution incentivizing increased global resource consumption and its potential harm to the environment. He emphasized the need to stifle greed and make mining more decentralized and competitive. Damian suggested focusing on approaches unrelated to Andrew's proposal that address greed. Although Andrew agreed with the importance of preventing greed, he believes his proposal can work well alongside a dynamic difficulty adjustment algorithm.Another developer, Eric, suggested an alternative solution called Helper Blocks, which assigns one satoshi from the unspent transaction output set with the ability diff --git a/static/bitcoin-dev/Sept_2018/combined_URI-scheme-with-optional-bech32-address.xml b/static/bitcoin-dev/Sept_2018/combined_URI-scheme-with-optional-bech32-address.xml index 50c8b62c27..31699c0e16 100644 --- a/static/bitcoin-dev/Sept_2018/combined_URI-scheme-with-optional-bech32-address.xml +++ b/static/bitcoin-dev/Sept_2018/combined_URI-scheme-with-optional-bech32-address.xml @@ -2,7 +2,7 @@ 2 Combined summary - URI scheme with optional bech32 address - 2025-09-26T15:55:46.016991+00:00 + 2025-10-11T22:04:51.385432+00:00 python-feedgen shiva sitamraju 2018-09-25 06:59:48+00:00 @@ -17,10 +17,11 @@ + 2 Combined summary - URI scheme with optional bech32 address - 2025-09-26T15:55:46.017144+00:00 + 2025-10-11T22:04:51.385584+00:00 2018-09-25T06:59:48+00:00 A proposal has been shared on Reddit regarding the adoption of bech32 QR codes in the Bitcoin network. While QR code adoption is considered important, bech32 QR codes are not backward compatible, leading many merchants and exchanges to opt for P2SH address QR codes instead. The proposed solution suggests using a URI format that includes both bech32 and P2SH address options. This would allow wallets to autopay using the lower transaction fee associated with bech32 addresses.The rationale behind this proposal is to increase the usage of bech32, which would create a network effect and potentially lead to widespread adoption of bech32 QR codes. To implement this solution, a team of developers is working on a walleting application capable of generating bech32 and P2WPKH-nested-in-P2SH addresses.One challenge faced by the team is that the payee cannot know in advance the technological capabilities of the payer. To address this, the proposal suggests encoding both bech32 and P2SH addresses in a Bitcoin URI. Legacy wallets would only see the P2SH address, while new wallets would be able to see and use the bech32 address for transactions.To maintain compatibility with BIP21, the 'path' field of the URI can be used for the P2WPKH-nested-in-P2SH address, while a new field (e.g., 'bech32') can be introduced for the bech32 address. It is assumed that wallets utilizing this scheme would monitor incoming transactions on both addresses. The order of attributes in the URI should not matter, as clients would check all attributes with the same name. However, it remains unclear if there are any precedents for the multiple use of an attribute in URI schemes.The team acknowledges that their proposal may not be entirely novel and asks if anyone has already proposed something similar. They also seek feedback on any major drawbacks to their proposal. diff --git a/static/bitcoin-dev/Sept_2019/combined_Block-Batch-Filters-for-Light-Clients.xml b/static/bitcoin-dev/Sept_2019/combined_Block-Batch-Filters-for-Light-Clients.xml index 0a71bbe095..77f9b40468 100644 --- a/static/bitcoin-dev/Sept_2019/combined_Block-Batch-Filters-for-Light-Clients.xml +++ b/static/bitcoin-dev/Sept_2019/combined_Block-Batch-Filters-for-Light-Clients.xml @@ -2,7 +2,7 @@ 2 Combined summary - Block Batch Filters for Light Clients - 2025-09-26T15:38:56.744385+00:00 + 2025-10-11T21:49:16.006232+00:00 python-feedgen Jonas Schnelli 2019-10-11 15:44:54+00:00 @@ -29,10 +29,11 @@ + 2 Combined summary - Block Batch Filters for Light Clients - 2025-09-26T15:38:56.744547+00:00 + 2025-10-11T21:49:16.006429+00:00 2019-10-11T15:44:54+00:00 The conversation discusses the limitations of BIP 157 compared to BIP 37 in terms of applying filters to mempool and checking zero confirmation transactions. The light client can only process unconfirmed transactions by loading the entire mempool transaction flow, which raises concerns about DOS and fingerprinting. To address this, a possible solution is suggested, which involves retrieving a complete compact filter of the entire mempool using a maximum size ordered by feerate. This filter could be dynamically constructed and updated based on time intervals rather than every new transaction in the mempool. The process includes generating a mempool filter, connecting to the peer, requesting the filter, processing it for relevant transactions, and sending getdata for those transactions. After the initial retrieve, the light client inspects all new transactions received from peers (filterless unconfirmed tx detection). Alternatively, the mempool filter can be requested again after a timeout if the previous process consumes too much bandwidth. The goal is to make the light client process more efficient without compromising privacy and security.The Block Batch Filters draft has been improved, unlocking the ability to filter unconfirmed transactions for SPV nodes using BIP 157 instead of BIP 37, which had privacy leaks. This allows light clients that refused to use BIP 37 to process unconfirmed transactions by loading the entire mempool transaction flow. Additionally, the Mempool Transaction Filters draft proposes a future consensus layer soft-fork to incorporate block filters commitment into block validation rules, protecting light nodes from payment hiding attacks. This method also reduces bandwidth consumption compared to block filters and downloading full blocks for affected addresses.The updated version of the draft for BIP block batch filters can be found on the Bitaps Github page. It includes changes such as a return to Golomb coding and a simpler, more effective schema implementation. The total filter size is smaller than BIP 158, with estimated savings of over 20%. The filter is deterministic and could potentially be committed as a commitment in coinbase transactions in the future. The GCS parameters are flexible to maintain necessary FPS, and the filter has been split into two parts - unique elements and duplicated elements - with the latter encoded more effectively. However, there are still questions about the optimal range for batch, the need for SIP hash instead of using the first 64 bits from pub key/script hash, and whether unique/duplicated elements should be downloaded separately or if filter types should be added for these purposes. Feedback and discussions on these topics are welcome.Aleksey Karpov also shared a draft of a BIP for compact probabilistic block filters as an alternative to BIP 158. While BIP 158 has a low false positive rate, a higher false positive rate filter could achieve lower bandwidth while syncing the blockchain. However, BIP 158 does not support filter batching due to the design of its parameters for siphash and Golomb coding. The proposed alternative uses delta coding and splits data into two bit string sequences, compressing the second sequence with two rounds of the Huffman algorithm. This method has an effectiveness rate of about 98% compared to Golomb with optimal parameters. Batching block filters significantly reduces their size, and separating filters by address type allows lite clients to avoid downloading redundant information without compromising privacy. The recommended strategy for lite client filters download is to get the biggest filter (smallest blocks/size rate) for a blocks range, then, in case of a positive test, get medium filters to reduce the blocks range, followed by getting block filters for the affected range and downloading affected blocks over TOR. An implementation in Python can be found on GitHub.Tamas Blummer also shared his thoughts on the use of filters in deciding whether to download newly announced blocks. He believes that whole chain scans would be better served with plain sequential reads in map-reduce style. Many clients do not care about filters for blocks before the birth date of their wallet's keys, so they skip over the majority of history, resulting in greater savings than any aggregate filter. Blummer wishes for a filter commitment as it could unlock more utility than marginal savings through a more elaborate design.In conclusion, there are ongoing developments and discussions regarding the limitations of BIP 157, the improvements to the Block Batch Filters draft, and the proposed alternative compact probabilistic block filters. The aim is to make the light client process more efficient while ensuring privacy and security. Feedback and input on these matters are encouraged. diff --git a/static/bitcoin-dev/Sept_2021/combined_BIP-extensions.xml b/static/bitcoin-dev/Sept_2021/combined_BIP-extensions.xml index fa9c74a1cd..1faf9c7802 100644 --- a/static/bitcoin-dev/Sept_2021/combined_BIP-extensions.xml +++ b/static/bitcoin-dev/Sept_2021/combined_BIP-extensions.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP extensions - 2025-09-26T16:02:40.758878+00:00 + 2025-10-11T22:16:56.316467+00:00 python-feedgen Anthony Towns 2021-09-15 14:34:54+00:00 @@ -21,10 +21,11 @@ + 2 Combined summary - BIP extensions - 2025-09-26T16:02:40.759012+00:00 + 2025-10-11T22:16:56.316614+00:00 2021-09-15T14:34:54+00:00 The discussion among Bitcoin developers on the bitcoin-dev mailing list revolves around the status of Bitcoin Improvement Proposals (BIPs). While some developers argue that BIPs become "standards" once incorporated into the Bitcoin ecosystem, others disagree, stating that calling them "standards" could be misleading. They emphasize that a proposal remains a proposal until accepted as a standard by the community.The debate then shifts to improving BIPs. One proposed solution is creating BIP extensions instead of modifying existing ones long after review, which can lead to contention. BIP extensions are separate proposals that extend an existing BIP. However, concerns are raised that this approach may hinder the BIP process and encourage contentiousness.As an alternative, it is suggested to separate draft BIPs from those in Active/Final status. A new BIP would be marked as a "Draft" until authors are satisfied with the text, at which point it becomes a Final status BIP without modification. The suggestion is to avoid making modifications outside of drafts unless absolutely necessary. Only minor updates should be allowed, such as adding additional info in Acknowledgements or See also sections, including Superseded-By links, and updating specific tables designed for updates.In conclusion, the focus of the discussion is on ensuring comprehensive evaluation and review of proposals before accepting them as standards within the Bitcoin ecosystem. Some developers propose creating BIP extensions to minimize contention, while others advocate for separating draft BIPs from those in Active/Final status, limiting modifications, and allowing only minor updates.A member named Michael Folkson is advocating for a revision to BIP 2, which is being discussed in the "BIP process meeting" thread. The plan is to modify pull request #1015 or another relevant pull request based on collective decisions.Karl-Johan Alm proposes that changes to BIPs of the second and third type should be done as BIP extensions. These extensions are independent proposals that do not require approval from the original author. By opting for extensions instead of modifying existing BIPs long after review, the community can be assured that a BIP will mostly remain unchanged. This approach allows modifications to be judged solely on their merits and provides a path to propose changes even if authors become inactive.Bitcoin Improvement Proposals (BIPs) start as ideas and are discussed on the BIPs repository list before being assigned a number by editors and merged. Once widely supported, a BIP becomes a standard. BIPs may be modified for spelling errors, clarifications, or to add missing content such as an activation strategy. Changes falling into the second and third categories should be done as BIP extensions, unless they are free from contention. These extensions are considered independent proposals and do not require the original author's approval. An extension that extends a BIP XXX is referred to as BIP-XXX-Y.Karl-Johan Alm proposes changes to BIPs to be made as BIP extensions in an email to the bitcoin-dev mailing list. He suggests that this approach gives the community confidence that a BIP will mostly remain unchanged and enables evaluations of modifications based on their merits alone. It also provides a pathway to propose modifications even if authors become inactive. Federico Berrone supports Alm's proposal and recommends adding additional information separately to declutter BIPs and enhance proposal comprehension without modifying the original proposal. diff --git a/static/bitcoin-dev/Sept_2021/combined_BIP-process-meeting-Tuesday-September-14th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml b/static/bitcoin-dev/Sept_2021/combined_BIP-process-meeting-Tuesday-September-14th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml index f21c238023..d9c77c6b95 100644 --- a/static/bitcoin-dev/Sept_2021/combined_BIP-process-meeting-Tuesday-September-14th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml +++ b/static/bitcoin-dev/Sept_2021/combined_BIP-process-meeting-Tuesday-September-14th-23-00-UTC-on-bitcoin-dev-Libera-IRC.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC - 2025-09-26T16:02:47.083024+00:00 + 2025-10-11T22:16:58.439414+00:00 python-feedgen Michael Folkson 2021-09-14 15:43:59+00:00 @@ -25,10 +25,11 @@ + 2 Combined summary - BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC - 2025-09-26T16:02:47.083163+00:00 + 2025-10-11T22:16:58.439600+00:00 2021-09-14T15:43:59+00:00 The bitcoin-dev mailing list is currently discussing ways to enhance the Bitcoin Improvement Proposal (BIP) process. Prayank suggests that BIPs are proposals shared on the mailing list and anyone can create directories for them. They propose documenting a proposal, opening a pull request in the bitcoin/bips repository, assigning a number, and merging it before sharing it on the mailing list. Michael recommends using the Git version control system in the repository for easier editing and revision. He also suggests using bots to notify maintainers and contributors of pull requests. Additionally, he suggests creating a BIP Gallery with text and image galleries to promote engagement with the BIP process.The discussion also touches upon the perception of authority and the use of the same organization on GitHub, which some find misleading. ACKs/NACKs are deemed important in discussions related to proposals. The goal is to provide clarity and improve software while maintaining the current state of affairs.Further suggestions include using the Git version control system instead of relying solely on the mailing list for edits and revisions. It is proposed to create a BIP directory linking to proposals shared on the mailing list, allowing updates without altering the original post. Concerns about having a central repository for BIPs are addressed by emphasizing the limited ability of BIP editors to unilaterally merge contentious code changes. A bot in the bitcoin/bips repository could help notify maintainers and contributors regarding pull requests.A previous attempt at a BIP Gallery was made but was not well-received by many. However, an informational BIP could complement the standard BIP for new implementers or casual readers.In summary, the ongoing discussion on the bitcoin-dev mailing list focuses on improving the BIP process. Suggestions include utilizing the Git version control system, creating a BIP directory, and implementing a bot for notifications. The idea of a BIP Gallery is explored, and there are considerations regarding authority perception and the use of the same organization on GitHub. The ultimate objective is to enhance clarity and software development while maintaining the existing framework. diff --git a/static/bitcoin-dev/Sept_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml b/static/bitcoin-dev/Sept_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml index 0a3537b8dc..6af35fdf8d 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Braidpool-Proposal-for-a-decentralised-mining-pool.xml @@ -2,7 +2,7 @@ 2 Combined summary - Braidpool: Proposal for a decentralised mining pool - 2025-09-26T16:02:17.584553+00:00 + 2025-10-11T22:16:54.191776+00:00 python-feedgen pool2win 2021-09-13 08:03:42+00:00 @@ -61,10 +61,11 @@ + 2 Combined summary - Braidpool: Proposal for a decentralised mining pool - 2025-09-26T16:02:17.584699+00:00 + 2025-10-11T22:16:54.191931+00:00 2021-09-13T08:03:42+00:00 The issue of a malicious miner cheating other miners of their reward is discussed in the context. The problem arises as the bitcoin block is used as the sentinel to mark the shares from DAG that need to be rewarded. A proposed solution is to have the hub broadcast a "sentinel" to mark out the point in logical time up to which shares will be rewarded.A proposal is made to reward miners for creating valid blocks, but concerns are raised about rogue miners avoiding referencing other miners' shares to keep rewards for themselves. Two methods are suggested for resolving conflicts between conflicting versions of the DAG: using the longest chain or the one with more work. However, both methods present issues such as the potential for bad hashers to create low-difficulty shares and then mine and publish higher-difficulty shares without sharing the reward.In an email exchange, questions are raised about the proposal that every share can reference multiple previous shares. Concerns are expressed about rogue miners not referencing any shares from other miners to avoid sharing the reward. Doubts are also raised about how conflicts between different valid states will be resolved.A discussion on the Bitcoin-dev mailing list focuses on the centralization of Braidpool's payout server, which is seen as a single point of failure. Suggestions are made to use multiple hubs to reduce the risk of a single point of failure. One idea presented is a Lightning model where multiple hubs offer liquidity to the network, and the winning hasher elects one of the hubs to receive the payout. It is acknowledged that getting something working now may be more beneficial than waiting for a perfect solution.ZmnSCPxj points out that Braidpool's payout server remains a single central point of failure despite claims of using Tor hidden service to protect against DDoS attacks. Multiple hubs are suggested as a preferable solution, with Chris Belcher's proposal for using payment channels mentioned as a potential construction for multiple hubs. It is acknowledged that more ideas for decentralization may emerge as Braidpool is built.The benefits of Stratum v2 and its comparison to other mining methods are discussed. It is noted that mining pools still have the ability to reject negotiations and censor payments. Suggestions are made to use Stratum v2 in combination with other technologies, such as discreet log contracts.Braidpool is viewed as an improvement to P2Pool in making a peer-to-peer pool work on a larger scale. It offers transparent views of shares received by the pool, allowing miners to verify reward calculations. It also offers payouts over a one-way channel, unlike P2Pool. Braidpool prepares for future attacks on centralized mining pools while attracting miners to the platform now.In a discussion on centralized mining control and payment censorship, concerns are raised about the control of transaction selection and potential censorship. The use of Lightning Network (LN) for payouts is suggested as a way to mitigate these issues, but the advantages of Braidpool over an idealized version of centralized mining with independent transaction selection are questioned.A comparison is made between a decentralized mining pool using BetterHash or Stratum v2 with LN-based payouts and a centralized mining pool. The advantages of a decentralized pool are highlighted, including the ability for miners to choose their own transactions and prevent any single entity from having control over the selection process.Pool2win proposes a decentralized solution to the problems faced by P2Pool. The proposal aims to provide lower variance for smaller miners and enable a futures market for hash rates. The solution uses a DAG of shares replicated at all miners to compute rewards, with payouts made via one-way payment channels by an anonymous hub communicating through Tor's hidden services. Comparisons to Stratum v2 are not provided.The Pool2Win team develops Braidpool, a decentralized mining pool aimed at overcoming issues faced by P2Pool and enabling a futures market for hash rates. The pool offers lower variance for smaller miners, allows miners to build their own blocks, and provides transparent views of shares received by the pool. Rewards are paid out via one-way payment channels using Tor's hidden services to prevent cheating. The team also provides details on trading hash rate. The ultimate goal is to provide a more efficient and fair mining experience while contributing to Bitcoin's decentralization. diff --git a/static/bitcoin-dev/Sept_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml b/static/bitcoin-dev/Sept_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml index 53005a0c0e..002d131d1f 100644 --- a/static/bitcoin-dev/Sept_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml +++ b/static/bitcoin-dev/Sept_2021/combined_Reminder-on-the-Purpose-of-BIPs.xml @@ -2,7 +2,7 @@ 2 Combined summary - Reminder on the Purpose of BIPs - 2025-09-26T16:02:15.470247+00:00 + 2025-10-11T22:16:52.068508+00:00 python-feedgen Prayank 2021-09-15 09:50:34+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - Reminder on the Purpose of BIPs - 2025-09-26T16:02:15.470404+00:00 + 2025-10-11T22:16:52.068655+00:00 2021-09-15T09:50:34+00:00 During a recent meeting, the suggestion to decentralize the Bitcoin Improvement Proposals (BIPs) process was made in response to the lack of participation and discussion. The proposal aims to create multiple BIP directories to reduce dependency on one repository or a few individuals. While documentation is important, the focus should be on implementation.An example was given to demonstrate this point. Greg Maxwell proposed a solution to the mirroring issue of decentralized BIPs. He suggested assigning each BIP a genesis transaction ID that moves in time on the blockchain and mirrors the evolution in Git using commit hashes. This would provide a definitive HEAD of a BIP and its history, which can be reconstructed from any one transaction. Commit trees can be mirrored and hosted on popular sites like Github or Gitlab. The proposal also includes assigning BIP numbers in the Bitcoin repository and requiring spending money on transactions to prevent sybil attacks.David A. Harding recommended changes to the BIP process. His recommendations include adding more BIP editors, seeking the resignation of Luke Dashjr as BIP editor, and treating protocol documents outside the BIPs repository as first-class BIP documentation. He proposed an alternative to the BIPs system where anyone writing protocol documentation can post their idea to the mailing list and assign themselves a unique decentralized identifier starting with "bip-". Implementations of BIPs would link to the relevant protocol documentation. Harding's proposal aims to address issues such as users considering documents in the BIPs repo as authoritative and development teams wanting control over their own documentation.Matt Corallo criticized the BIP process, calling it a failure. W.J. van der Laan suggested decentralizing the process and adding more editors to address the bottleneck in open pull requests. Corallo also expressed frustration towards the community for irrational debates and ignoring input. The debate highlighted the need for a more decentralized approach to the BIP process.Luke Dashjr responded to accusations of deliberately refusing changes to BIPs. He denied the claims and stated that he follows the currently-defined process neutrally, despite being harassed by certain advocates. Dashjr proposed adding Kalle Alm as a BIP editor, but Antoine Riard suggested that the BIP editorship should have its own repository and follow procedural forms.Overall, there is ongoing discussion and debate about the BIP process and how it can be improved to better serve the Bitcoin community.In recent years, there has been a significant increase in the use of artificial intelligence (AI) in various industries. AI is a branch of computer science that focuses on creating intelligent machines capable of performing tasks that typically require human intelligence. It involves the development of algorithms and models that allow computers to learn from and adapt to data.One industry that has greatly benefited from the use of AI is healthcare. AI has the potential to revolutionize healthcare by improving diagnosis, treatment, and patient care. For example, AI algorithms can analyze large amounts of medical data to identify patterns and make predictions, helping doctors make more accurate diagnoses and develop personalized treatment plans. AI can also be used to monitor patients remotely, providing timely intervention and reducing the need for hospital visits.Another area where AI is making a significant impact is transportation. Self-driving cars, powered by AI technology, have the potential to reduce accidents and improve road safety. These cars are equipped with sensors and cameras that allow them to navigate and make decisions based on real-time data. AI algorithms enable the car to interpret the environment and react accordingly, ensuring a smooth and safe ride.AI is also being used in the finance industry to automate processes and enhance decision-making. For instance, AI-powered chatbots can assist customers with basic banking tasks, such as checking account balances or transferring funds. AI algorithms can also analyze financial data to detect fraud and identify investment opportunities. Additionally, AI can help financial institutions streamline operations and improve customer service through personalized recommendations.The retail industry has also embraced AI to enhance customer experience and optimize business operations. AI-powered recommendation systems analyze customer preferences and behavior to provide personalized product suggestions. This not only improves customer satisfaction but also increases sales. AI can also be used to automate inventory management, pricing strategies, and supply chain optimization, leading to cost savings and improved efficiency.In conclusion, AI is revolutionizing various industries, including healthcare, transportation, finance, and retail. Its ability to analyze large amounts of data, make predictions, and automate processes is transforming how these industries operate. As AI technology continues to advance, it is expected to have an even greater impact in the future, driving innovation and improving efficiency across multiple sectors. diff --git a/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml b/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml index c0bf402cce..557450f32b 100644 --- a/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml +++ b/static/bitcoin-dev/Sept_2022/combined_BIP-Proposal-Wallet-Labels-Export-Format.xml @@ -2,7 +2,7 @@ 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2025-09-26T15:27:50.414334+00:00 + 2025-10-11T21:29:04.262175+00:00 python-feedgen Craig Raw 2022-09-26 08:23:18+00:00 @@ -86,10 +86,11 @@ + 2 Combined summary - BIP Proposal: Wallet Labels Export Format - 2025-09-26T15:27:50.414535+00:00 + 2025-10-11T21:29:04.262394+00:00 2022-09-26T08:23:18+00:00 The proposed standard aims to create a defined format for transferring labels that users have applied to transactions, addresses, inputs, or outputs in their wallets. The format uses the comma-separated values (CSV) format, which is widely supported. Each record in the CSV file consists of two fields: the reference to a transaction, address, input, or output, and the label applied to that reference. The proposal suggests using ZIP compression for the CSV file, with optional AES encryption.Some feedback on the proposal includes suggestions for improvements, such as adding a version byte to the header line, making the header line mandatory, and using an unsigned 32-bit integer for the second column. There are also suggestions to remove the optional encryption feature and not include input and output types in the export to avoid privacy leaks. Instead, commentators suggest adding a third column for item type identification.Despite disagreement on the use of CSV as a standard format, the goal of the proposal is to create a standardized format for importing and exporting wallet labels. The proposed format is a simple two-column CSV file, aiming to make label management more accessible to users and ensure compatibility between different wallet implementations. Feedback on the proposal is appreciated, and further improvements may be made based on the feedback received.The use of CSV for transferring labels between wallet applications is motivated by its wide accessibility and integration with existing processes and tools like Excel. However, there is some disagreement about using CSV, with suggestions to use JSON instead due to concerns about CSV compatibility and parsing effort. Despite this disagreement, the proposal aims to create a standard for importing and exporting labels from a wallet, regardless of the chosen data format.The proposal specifies a two-column CSV format, where the first column contains the reference to a transaction, address, input, or output, and the second column contains the label. The CSV file can be compressed using ZIP and optionally encrypted using AES. Importing applications may truncate labels if necessary, while exporting applications may omit records with no labels or labels of zero length.The proposal seeks to make label management accessible to users without technical expertise and reduce file size while ensuring compatibility. The discussion on the Bitcoin-dev mailing list provides insight into ongoing development work on the Bitcoin protocol and the collaborative nature of the Bitcoin development community.There is some disagreement about using CSV as the standard format for transferring labels, with suggestions to use JSON instead. One commenter suggests including descriptors in the format for advanced users. In response to a question about SLIP-0015, it is stated that SLIP-0015 has different design goals and limitations compared to the proposed BIP.The proposal allows for ZIP compression and optional AES encryption of the CSV file. The password for encryption should be the textual representation of the wallet's extended public key. The aim of this proposal is to create a standard for exporting and importing labels from a wallet, avoiding lock-in to a specific application, and making label management accessible to non-technical users.Feedback on the proposal is requested, and a reference implementation is yet to be determined. Suggestions for additions and changes to the format include adding a version byte, making the header line mandatory, requiring double quotes around the label, and writing a more robust importer algorithm. The proposal aims to standardize the export and import of labels using a simple CSV format. diff --git a/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml b/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml index 1bc22ff5c4..b365588513 100644 --- a/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml +++ b/static/bitcoin-dev/Sept_2022/combined_On-a-new-community-process-to-specify-covenants.xml @@ -2,7 +2,7 @@ 2 Combined summary - On a new community process to specify covenants - 2025-09-26T15:27:46.114195+00:00 + 2025-10-11T21:29:00.014385+00:00 python-feedgen Antoine Riard 2022-10-07 15:33:12+00:00 @@ -106,10 +106,11 @@ + 2 Combined summary - On a new community process to specify covenants - 2025-09-26T15:27:46.114395+00:00 + 2025-10-11T21:29:00.014579+00:00 2022-10-07T15:33:12+00:00 The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape. While higher-bandwidth communication channels like invite-only events may facilitate deeper discussions, they come at the cost of openness and context archiving, which are essential in the Bitcoin ecosystem.The email then discusses the difficulty of finding consensus on covenant designs and attracting experienced developers to invest diff --git a/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml b/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml index d87b68c34d..8e174ec148 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Packaged-Transaction-Relay.xml @@ -2,7 +2,7 @@ 2 Combined summary - Packaged Transaction Relay - 2025-09-26T15:27:52.561312+00:00 + 2025-10-11T21:29:06.386317+00:00 python-feedgen eric at voskuil.org 2022-10-10 22:05:38+00:00 @@ -70,10 +70,11 @@ + 2 Combined summary - Packaged Transaction Relay - 2025-09-26T15:27:52.561508+00:00 + 2025-10-11T21:29:06.386513+00:00 2022-10-10T22:05:38+00:00 The email conversation on the bitcoin-dev mailing list revolves around the issue of stuck transactions caused by the minimum fee rate policy and proposes a solution through package relay. The objective is to propagate incentive-compatible transactions for mining, even if they don't meet the minimum feerate alone.The discussion raises questions about the complexity of solutions, the potential impact of covenants, and the predictability of pre-signed transaction rejection by nodes. Matt Corallo's thoughts are also mentioned, emphasizing the need for parent transactions to be relayed along with their higher feerate children. The email further explores the implications of changing transaction order in a package and the potential for attack vectors such as front running or MEV. It concludes that any policy beyond what is published via the protocol will cause problems.The proposed Package Relay Proposal aims to optimize transaction packaging and prevent orphaned transactions. It suggests that each node should package transactions for its peers based on individual fee rates, eliminating dead-ending packages. The proposal requires an additional INV element type and provides guidelines for creating minimal packages. Concerns about bandwidth waste in nodes with different policy rules are addressed by suggesting methods like including a hash of the package wtxids in the initial announcement or limiting v1 packages to transactions with few parents. The use of BIP 152 shortids to save bandwidth is discussed, but there are concerns about computational complexity.The concept of transaction packages in Bitcoin is thoroughly explored in the email thread. The proposal aims to propagate incentive-compatible transactions, addressing various questions about multiple pre-signed transactions, the impact of covenants, and transaction rejection due to insufficient fees. The discussion also delves into the potential complexities and challenges of implementing transaction packages, including the creation of minimal packages and the avoidance of predictable orphans. Bandwidth waste, dishonest peer announcements, and the use of BIP 152 shortids are also considered. The participants provide feedback and suggestions, discussing different aspects of the proposal and highlighting the technical details involved in its implementation.In a bitcoin-dev discussion, the Package Relay Proposal is scrutinized, focusing on propagating incentive-compatible transactions despite not meeting the minimum feerate alone. The proposed packaged transaction relay model involves nodes packaging transactions based on peer.feerate and maintaining a transaction DAG with tx.feerate to prevent dead-ending packages. Topological rule concerns in version 1 package relay and potential bandwidth waste from using BIP 152 shortids are brought up. Suggestions to remove fee and weight information from pkginfo, address dishonest peer announcements, and add versioning to individual protocols are discussed. The conversation sheds light on optimizing package relay while minimizing complexity and maintaining network integrity. diff --git a/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml b/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml index 24f9196a03..11433fb46a 100644 --- a/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml +++ b/static/bitcoin-dev/Sept_2022/combined_Transcript-Online-Socratic-on-MuSig2.xml @@ -2,7 +2,7 @@ 2 Combined summary - Transcript: Online Socratic on MuSig2 - 2025-09-26T15:27:43.963988+00:00 + 2025-10-11T21:28:57.890167+00:00 python-feedgen Michael Folkson 2022-09-12 16:00:52+00:00 @@ -18,10 +18,11 @@ + 2 Combined summary - Transcript: Online Socratic on MuSig2 - 2025-09-26T15:27:43.964122+00:00 + 2025-10-11T21:28:57.890334+00:00 2022-09-12T16:00:52+00:00 In a conversation between Ali Sherief and Michael Folkson, the issue of theft and online connectivity with signature generation is discussed. Michael explains that generating a signature requires private keys, which raises concerns about security and theft. However, he suggests that using multisig arrangements can prevent loss of funds in case of theft of a single private key. Additionally, he mentions that key aggregation multisig increases interactivity requirements.Michael clarifies that while there isn't a concept of a "lite node" in signature generation, it makes more sense in the realm of verification. He gives an example of Liquid, where currently 11 signatures go onchain when funds are moved. However, if Liquid used a key aggregation scheme like FROST, only a single signature would be required onchain. He also suggests the possibility of increasing the number of signatures or implementing a nested MuSig/FROST scheme for added security.Ali contacts Michael regarding the detailed and comprehensive Socratic transcript, which covers various problems including theft and offline issues. Ali inquires if any research has been done that doesn't involve a trade-off between theft and online connectivity. While ROAST and Liquid provide solutions, they rely on centralized nodes. Ali proposes the idea of decentralizing federated nodes into "lite nodes" managed by each service wanting payment, creating a threshold signature from multiple subscribers paying simultaneously.On August 11th, an online Socratic session was held featuring Tim Ruffing and Elizabeth Crites, discussing topics related to MuSig(2), FROST, ROAST, and more. The transcript of the session can be found on btctranscripts.com, and the video is available on YouTube. A reading list has also been compiled, containing resources on MuSig(2), FROST, and ROAST. During the discussion, participants covered various subjects, including BIP340, handling x-only public keys in MuSig2, the proposed TLUV covenant opcode, the history and improvements of MuSig, comparisons between MuSig2 and FROST for multisig schemes, the absence of proofs of possession in MuSig2, and the current state of the draft MuSig2 BIP.Although the session was lengthy (approximately 2.5 hours), it offered valuable insights into these topics, making the transcript or video useful for anyone interested in the discussed subjects. Jonas Nick also tweeted that the MuSig2 BIP is nearing a stable version 1.0, which will be beneficial for those implementing it. All relevant sources and links have been provided for further reference. diff --git a/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml b/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml index 7624edd444..f07dea2b67 100644 --- a/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml +++ b/static/bitcoin-dev/Sept_2022/combined_joinstr-coinjoin-implementation-using-nostr.xml @@ -2,7 +2,7 @@ 2 Combined summary - joinstr: coinjoin implementation using nostr - 2025-09-26T15:27:48.263868+00:00 + 2025-10-11T21:29:02.139302+00:00 python-feedgen alicexbt 2022-09-10 10:17:37+00:00 @@ -26,10 +26,11 @@ + 2 Combined summary - joinstr: coinjoin implementation using nostr - 2025-09-26T15:27:48.264041+00:00 + 2025-10-11T21:29:02.139494+00:00 2022-09-10T10:17:37+00:00 A developer named alicexbt has created a proof-of-concept python script to implement coinjoin using nostr, a decentralized network based on cryptographic keypairs. This implementation utilizes several Bitcoin Core wallet and RPC commands and requires the python-nostr library for coordination between peers. The process involves 5 peers coordinating to create, sign, and broadcast a coinjoin transaction. Each step of the process is published as an event using a nostr relay, and users can use multiple relays simultaneously to avoid trusting a single relay. However, there is a vulnerability of denial of service in the implementation, where a malicious user can register multiple outputs with the same secret, causing an ongoing free denial of service attack without attribution or defense.To address this issue, PR #24058 (basic support BIP-322) can be implemented to add proof of ownership. Instead of clients sending descriptors to the relay and then verifying them using `scantxoutset`, they can send `txid:out` with a message signed with the address, verify using `verifymessage`, and then use `gettxout` to retrieve the value. That way, only the owner can send the UTXO. The cryptographic scheme mentioned as an alternative to blind signatures isn't implemented yet, as it requires a NIP and at least one relay using it.The author plans to continue developing coinjoin transactions on signet for a few weeks until there is a stable release with no bugs. Custom relays are supported by Nostr, examples include paying a fee to register for a round, subscribing with a time limit, or using invite-only relays. The author will run a free and open nostr relay for this project and try to fix the DoS issues before a mainnet version is released for the python script (for nerds) and android app (for all users).The email is sent using Proton Mail secure email, and the author invites opinions on the experiment. The email thread is part of the bitcoin-dev mailing list hosted by lists.linuxfoundation.org. The author credits Fiatjaf, Andrew Chow, Jeff Thibault, and existing coinjoin implementations for their contributions. The author also mentions the creation of an Android app for joinstr in the coming week.Overall, the developer's message provides insights into a coinjoin implementation using Nostr, the challenges and limitations of the current system, and potential improvements to make it more secure. The email includes relevant links to GitHub repositories and provides event IDs and a Coinjoin transaction ID for reference. diff --git a/static/bitcoin-dev/Sept_2023/combined_Concern-about-Inscriptions-.xml b/static/bitcoin-dev/Sept_2023/combined_Concern-about-Inscriptions-.xml index 500244f2e9..e107477505 100644 --- a/static/bitcoin-dev/Sept_2023/combined_Concern-about-Inscriptions-.xml +++ b/static/bitcoin-dev/Sept_2023/combined_Concern-about-Inscriptions-.xml @@ -2,7 +2,7 @@ 2 Combined summary - Concern about "Inscriptions" - 2025-09-26T14:30:16.434293+00:00 + 2025-10-11T21:57:22.762083+00:00 python-feedgen vjudeu at gazeta.pl 2023-09-06 08:00:53+00:00 @@ -57,10 +57,11 @@ + 2 Combined summary - Concern about "Inscriptions" - 2025-09-26T14:30:16.434464+00:00 + 2025-10-11T21:57:22.762233+00:00 2023-09-06T08:00:53+00:00 The email thread discusses the concept of cut-through transactions in the Bitcoin blockchain. Cut-through involves removing inscriptions from transaction chains while preserving the payment information. It is argued that cut-through is useful for scaling when there are only a few transactions, but it becomes less efficient when all transactions need to be included. The idea of implementing cut-through is seen as a natural consequence of enabling full Replace-By-Fee (RBF) transactions, which would lead to mempool-level batching.The discussion also revolves around the impact of cut-through on inscriptions. While cut-through can prove transaction chains using cryptography, it does not eliminate the presence of transactions in the blockchain. Full archival nodes still contain all the inscription data and can provide it to those who need it. It is compared to running pruned nodes in Bitcoin, where some nodes do not store all the data but can still access it from full archival nodes.Another topic brought up in the email thread is the suggestion of reducing the blocksize limit to address concerns about blockchain size increases and promote activity on the lightning network. It is proposed that the blocksize limit may have been increased unnecessarily in the past, and now it is worth considering a smaller blocksize to encourage more usage of the lightning network. The lightning network is seen as a potential solution to handle increased transaction volume while minimizing the growth of the blockchain.Inefficiencies and costs related to proof-of-secret-key schemes are also discussed. It is mentioned that reusing k values in ECDSA allows for data encoding in both k and the entire secret key, which can be exploited for encoding data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging and expensive.The email thread includes discussions on various topics related to the Bitcoin protocol. One of these topics involves adding a proof-of-work requirement to a public key on an open relay server protocol to deter spammers or scammers. The difficulty of embedding information in a public key is mentioned, particularly when considering the need for mobile devices to generate keys quickly.The email also touches on the issue of Bitcoin script exploits and vulnerabilities caused by the insertion of arbitrary data. Two strategies, Ordisrespector and Ordislow, are proposed as potential solutions to address these vulnerabilities. Ordisrespector allows node operators to opt-in to a self-defense mechanism against aggression via inserted arbitrary data, while Ordislow increases the coercion cost of mining entities relative to cooperation cost by delaying block propagation and requiring inserted arbitrary data in blocks.The inefficiency and costliness of proof-of-secret-key schemes are highlighted, with examples of how ECDSA can be exploited to encode data in signatures or public keys. Limiting the storage of arbitrary data in systems relying on secret keys is considered challenging.The email thread also delves into the topic of inscription attacks and spam prevention in the Mimblewimble protocol. It is noted that range proofs in the protocol already prove knowledge of blinding factors in Pedersen commitments, eliminating the need for additional padding to prevent the encoding of spam. Pure Mimblewimble blockchains are seen as highly resistant to inscription and spam attacks.There is a mention of a project called STAMPS that embeds image data in multisig outputs, which increases the size of the UTXO set compared to other methods. Pay-to-Contact protocols are suggested as a way to tweak a pubkey with a small blob of data, allowing for the production of a signature proving knowledge of the private key.The email raises concerns about banning arbitrary data in programming and its consequences. It is argued that if arbitrary data is banned, actors will find ways to encode their data within sets of public keys. Public key data is indistinguishable from random data, making it difficult to determine if a given public key is used for encoding data or serving its intended purpose. Examples of how governments attempt to censor internet protocols and users adapt by tunneling their data through innocent-looking channels are mentioned.The email also mentions the ongoing struggle between decentralization and centralization in the Bitcoin system. It is suggested that incrementing the cost of operating a regular Bitcoin node could lead to reduced network decentralization and vulnerability to central entity control. The central entity does not necessarily have to be a government.Overall, the email thread covers various discussions related to block sizes, blockchain size increases, lightning network usage, proof-of-secret-key schemes, inscription attacks, spam prevention, and the struggle between decentralization and centralization in the Bitcoin system. From 43e90c80444b9d958e4e7dba27364bb352f196fa Mon Sep 17 00:00:00 2001 From: jrakibi Date: Sun, 12 Oct 2025 00:01:19 +0100 Subject: [PATCH 5/5] cleanup: remove testing artifacts and debug code - Restore production-ready state for threading features --- .github/workflows/xmls_gen_cron_job.yml | 40 +------------------------ src/gpt_utils.py | 9 ++---- 2 files changed, 3 insertions(+), 46 deletions(-) diff --git a/.github/workflows/xmls_gen_cron_job.yml b/.github/workflows/xmls_gen_cron_job.yml index 452d1f4265..e1dc3e5791 100644 --- a/.github/workflows/xmls_gen_cron_job.yml +++ b/.github/workflows/xmls_gen_cron_job.yml @@ -3,22 +3,6 @@ on: schedule: - cron: "0 1 * * *" # every day at 01:00 AM UTC workflow_dispatch: - inputs: - from_year: - description: 'Start year for processing range (e.g., 2020). If not specified, uses default 90 days.' - required: false - default: '' - type: string - to_year: - description: 'End year for processing range (e.g., 2024). If not specified, processes only from_year.' - required: false - default: '' - type: string - update_threading_only: - description: 'Only update threading structure without generating new files' - required: false - default: false - type: boolean repository_dispatch: permissions: @@ -34,9 +18,6 @@ jobs: ES_USERNAME: ${{ secrets.ES_USERNAME }} ES_PASSWORD: ${{ secrets.ES_PASSWORD }} ES_INDEX: ${{ secrets.ES_INDEX }} - FROM_YEAR: ${{ github.event.inputs.from_year }} - TO_YEAR: ${{ github.event.inputs.to_year }} - UPDATE_THREADING_ONLY: ${{ github.event.inputs.update_threading_only }} steps: - uses: actions/checkout@v2 @@ -68,25 +49,6 @@ jobs: if git diff --staged --quiet; then echo "No changes to commit" else - if [ "${{ github.event.inputs.update_threading_only }}" = "true" ]; then - COMMIT_MSG="Updated XML files with threading structure (threading update only)" - if [ -n "${{ github.event.inputs.from_year }}" ]; then - if [ -n "${{ github.event.inputs.to_year }}" ]; then - COMMIT_MSG="$COMMIT_MSG for years ${{ github.event.inputs.from_year }}-${{ github.event.inputs.to_year }}" - else - COMMIT_MSG="$COMMIT_MSG for year ${{ github.event.inputs.from_year }}" - fi - fi - git commit -m "$COMMIT_MSG" - elif [ -n "${{ github.event.inputs.from_year }}" ]; then - if [ -n "${{ github.event.inputs.to_year }}" ]; then - COMMIT_MSG="Updated XML files for years ${{ github.event.inputs.from_year }}-${{ github.event.inputs.to_year }} with threading structure" - else - COMMIT_MSG="Updated XML files for year ${{ github.event.inputs.from_year }} with threading structure" - fi - git commit -m "$COMMIT_MSG" - else - git commit -m "Updated newly generated XML files with threading structure" - fi + git commit -m "Updated newly generated xml files" git push fi diff --git a/src/gpt_utils.py b/src/gpt_utils.py index ae96f7d9db..7ec3ed2005 100644 --- a/src/gpt_utils.py +++ b/src/gpt_utils.py @@ -275,13 +275,8 @@ def gpt_api(body, custom_prompt=None): def create_summary(body, custom_prompt=None): - # TEMPORARILY DISABLED: AI calls commented out for threading testing - # summ = gpt_api(body, custom_prompt) - # return summ - - # Return placeholder summary for threading tests (no AI tokens used) - logger.info("🧪 AI DISABLED: Using placeholder summary for threading testing") - return f"[THREADING TEST] Placeholder summary for testing. Original body length: {len(body) if body else 0} characters. No AI tokens used." + summ = gpt_api(body, custom_prompt) + return summ def generate_chatgpt_summary_for_prompt(summarization_prompt, max_tokens):